тк не всякий клиент такое переварит

Если клиента писали криворукие программисты, не читавшие стандарт, а расширения писали тоже не самые пряморукие разработчики, тоже не читавшие стандарт - то да, проблем не оберёшься. Сами видели многократно.

Совместимость все-таки на уровне CDC осуществляется, главное их не ломать :)

клиент мой очень строгих правил,
когда не в шутку занемог...

ему параметр я отправил,
а он переварить не смог

Вот тут соглашусь. Ибо подстраивание под кривые реализации стеков у других производителей уже надоело... 

Ну тогда да конечно, можно и так. Но такой реализации пока не у кого не видел. Да и как-то не красиво по мне, когда в одном объекте 2 одинаковых атрибута с разным fc. Все-же думаю проще пойти более простым путем и создать отдельный параметр.

Давайте смотреть на практике.  Как это переваривает клиент Сименса? Была ли у кого-нибудь такая реализация (т.е. не стандартные объекты, описанные в MICS)?  Аналогично и по другим вендорам.

можете использовать любой доступный атрибут, лишь бы там была нужная информация. Насчет индикации аварийного откл. - мы добавляли объект EmgTr, насчет самопроизвольного - на мой взгяд эта информация производная и не требует решения на уровне CSWI

Вот же сименс...

origin c FC=ST общий на DPC, дальше те, что пишутся - отдельно в каждой структуре SBOw, Oper, Cancel

Он, правда, с условным присутствием AC_CO_O, то есть не у всех может быть. Но вот у Сименса в CSWI он есть

Можно и доп. атрибутом, только когда есть стандартный, то решение не самое удачное, ибо будет вести к сложности применения этого атрибута. У каждого вендора свой атрибут => прикладное применение будет от вендора к вендору меняться => доп геморрой для наладчика. Если используются стандартные элементы, то один раз научился ими пользоваться (пусть сперва и сложнее) — дальше от проекта к проекту лепишь всё одинаково

Согласен) но имел ввиду любой origin для отчета (ST или CO), если по какой-то причине доступен только один

Ну да, а то, что в отчёт можно включить целиком Pos, и соответствующие origin'ы из него доставать уже когда он придёт просто по изменению stVal — тут целиком и полностью согласен.

Вот, кстати, может быть и проблема будет с доставанием атрибутов origin из Oper или SBOw, т.к. там у Сименса написано NOT-SUPPORTED, зато обычный origin вполне себе можно читать.

ну not-supported это значение Enum'a - все завсит от логики сервера, сбрасывать или нет значения атрибутов CO после успешного выполнения записи команды) имхл

а почему в боте SDDRFUF не находится?

Речь об этом?