Hirschmann, ruggedcom, phoenixcontact

При первых знакомствах с продукцией первых двух компаний все Fault/Alarm contacts/ports работают до 60V примеры

Физически они тянут 220 постоянки, и такое даже успешно практиковалось. Но в своих проектах я ставил пром реле. Ориентироваться при этом надо не на макс напряжение и ток, а на уровень напряжения для перехода с 0 в 1 и из 1 в ноль.

Стандарт для пром реле 24V?

Нет. Пром реле есть разные. 24 вольта в АСУ ПС считаются негласным стандартом, потому, что бы не разводить заопарк подгонял под 24.

Отлично, можно пару примеров реле которые ставятся в АСУ. Посмотреть их характеристики.

Спасибо за помощь

Фениксы ставили. Серию не помню. Документации уже нет род рукой.

Хм, два сообщения потерли...
Тут запрещены ссылки или вопросы по поиску документов IEC61850?
Огласите весь список правил, пожалуйста

Добрый день, коллеги!  Подскажите, кто-нибудь сталкивался с установкой двух битов в reason-for-inclusion  в отправленном отчете?  Например, в наборе лежит структурированный объект Pos.  в один момент времени меняется stVal и q. TrgOps (dchg=true, qchg=true).  Разрешено ли отправить один отчет с новыми значениями Pos(stVal, q, t),  а в reason-for--inclusion установить dchg+qchg) ?   прямых запретов в стандарте не нашел.

Хороший вопрос. Т.к. в отчёте передается FCD, то согласно структуре репорта (табл. 38, 7-2, 17.2.3.2.2.1) для каждой EntryData устанавливается свое поле ReasonCode. Как вариант, можно выдать 2 отчёта со своими ReasonCode. Тут ещё вопрос, как происходит событие, на которое реагирует устройство.

Давайте возьмем обобщенный сценарий. Просто принимаем в GOOSE или SV новое значение с новым качеством, которое потом отдаем с помощью RCB.

вариант с двумя репортами, конечно, напрашивается... но тогда для этих двух отчетов stVal q t  будут одинаковыми, а будут отличаться reason-for-inclusion (1 - dchg , 2 - qchg) и второй относительно первого уже смотрится странноватым, т.к. вся информация уже была передана. И в шаблонах PIXIT  информации о таком поведении не запрашивают..  Вот и хотел узнать — может кто-то сталкивался с дополнительными указаниями или был опыт приема/генерации таких отчетов

Сталкивался с такой ситуацией. В документации и в PIXIT тоже не нашел информации, согласен. Тут, как говорится, local issue. Если речь идёт о реакции на изменение двух атрибутов в структуре посредством обработки GOOSE, то какие ещё варианты можно предложить? Если бы, например, речь шла об FCDA в отчёте, то можно было спокойно выдать 2 отчёта и зафиксировать в каждом изменение одного из атрибутов. TimeOfEntry метка отчёта все равно вероятно будет одинакова, т.к. оба изменения будут зафиксированы за один цикл обработки.
Насколько я понимаю, структура FCD - это одна единица Entry data. Для нее будет один ReasonCode. Два раза одну и ту же структуру в отчёт включать.

Я остановился на варианте выдачи двух отчётов со своими sequence number, в таком случае. С одинаковыми TimeOfEntry и разными ReasonCode полями. М.б. кто-нибудь поправит, особенно интересно как в таком случае реагировать со стороны клиента.

Все в стандарте понятно написано. Взводите в ReasonCode соответствующего элеманта датасета(FCD) несколько битов если у вас несколько причин выдачи отчета.

Если в стандарте все понятно написано, почему людей постоянно возникают вопросы?)

тоже хотел бы знать ответ на этот вопрос)

вот не увидел прямого запрета и разрешения. ) Пойду искать дальше.  Буду признателен, если дадите прямую ссылку.