Интересует вопрос формирования сигнала о неисправности передачи/приема GOOSE-сообщений (либо противоположный ему “Готовность GOOSE”) с целью использовании этого сигнала в логике устройства.

Насколько я понял (исходя из стандарта) GOOSE-сообщения периодически посылаются даже при отсутствии любых изменений. Интервалы времени между повторными посылками сообщения увеличиваются до предельного, определенного пользователем значения. В связи с этим возникли следующие вопросы: 

1. Что будет если время timeAllowedtoLive истекло? 
2. Обнуляются ли у приемника по истечению этого времени все принимаемые значения в значения по умолчанию?
3. Какими средствами стандарта фиксируется отсутствие приема GOOSE сообщения? Т.е. с помощью какого объекта данных, атрибута, сервиса, сетевой подсистемы или блока можно определить потерю связи по GOOSE?
4. Можно ли реализовать следующий способ получения сигнала “неисправность GOOSE”: У отправителя в набор данных для GOOSE сообщений кроме необходимых данных включить еще и данное-константу. Эта константа c типом BOOLEAN всегда будет “True”. У приемника мы фиксируем эту константу. Если она становится “False” (возврат в значение по умолчанию, при отсутствии принятого сообщения), то будет ли это свидетельствовать о наличии неисправности передачи GOOSE сообщений?

1. Поведение устройства при отсутствии очередного GOOSE-сообщения по истечении timeAllowedToLive описано в главе 8-1 стандарта: “Each message in the retransmission sequence carries a timeAllowedToLive parameter that informs the receiver of the maximum time to wait for the next retransmission. If a new message is not received within that time interval, the receiver shall assume that the association is lost”. То есть фактически в таком случае устройство должно вывести сигнал о потере связи. При этом следует иметь в виду, что для каждого терминала форма вывода и использования такого сигнала будет различной, и будет определяться конкретной реализацией и зависеть от той идеологии, которую вкладывает сам производитель. Это же, кстати, касается и самого атрибута TATL: у одних он будет постоянный всегда, у других же, он будет изменяться, при изменении интервала ретрансляции от minTime до maxTime при изменении какого-либо из атрибутов данных.
2. В отношении принимаемого GOOSE-сообщения ситуация обстоит несколько иначе – стандарт не регламентирует строгого поведения устройства при отказе передачи GOOSE-сообщения: “The handling and processing of received GOOSE messages, by the subscriber, is a local issue. It is recommended to describe the local behaviour for out-of-order state/sequence numbers in the PIXIT statement”. Буквально, поведение приёмника при отсутствии GOOSE-сообщения должно описываться в файле PIXIT, который является обязательным для всякого устройства, декларирующего поддержку МЭК 61850. Заглянем в такой файл для устройств серии Siprotec 7SJxxxx.



3. Видим, что в интересующем нас первом случае, объекты данных из полученного сообщения объявляются недействительными (invalid), однако в PIXIT не сказано, меняют ли они значения. На практике могу сказать – нет, не меняют. Они сохраняют те же значения, что и до отказа, меняется лишь флаг качества. На мой взгляд, это логично: откуда терминал может знать какое значение было «по умолчанию».
4. Как уже было отмечено раньше, каждый производитель самостоятельно определяет как обозначить отсутствие приёма того или иного сигнала. Как правило, для этих целей каждом сигналу в модели устройства соответствует и его флаг качества, по которому можно судить о том, принимается ли сообщение в данный момент, или произошёл отказ передачи. Например, если опять же, рассмотреть устройства Siemens, то для получения данных о неисправности передачи того или иного сигнала посредством GOOSE-сообщения, в диаграмме свободно-программируемой логики следует использовать элемент SI_GET_STATUS, DI_GET_STATUS или MV_GET_STATUS, соответственно, для однопозиционного, двухпозиционного сигналов, либо аналоговой величины. На выходе каждого из блоков помимо текущего значения (VALUE) можно снять флаг недействительного значения (NV), который далее может быть задействован в логических схемах для блокировки тех или иных функций и т. п.



В реализации такого способа нет необходимости, равно как и просто реализовать его нельзя. Причины этого описаны выше.