Делали проверку один раз, понятно для души, не для официала.
были взяты два реле АББ ( если память не изменяет что то типа РЕФ615/630 ) пуск МТЗ раз пошёл через сухой контакт и через дигитальный вход второго реле на блокировку МТЗ, параллельно тот же сигнал пошёл гусем.

оба реле были синхринизированы и сигналы выведены на единый лист событий,

гусь прилител где то в 4-5мс, сухой контакт где то в 10-12мс.

При грамотной организации сети GOOSE cообщения доставляются быстрее, тем более на дискретных входах есть требование устанавливать программные фильтры 10 мс, к этому времени еще надо прибавить время работы выходных реле терминала.  Время доставки GOOSE важно проверять в полной схеме в "максимальном" режиме (когда их максимальное количество меняют свое состояние).

Согласно нашим измерениям, при "чистой" сети время передачи сообщения от одного терминала другому составляет от 3 до 6 мс, в зависимости от модели устройства/производителя. Но такое (чистая сеть) редко бывает и если бывает, то на маленьких объектах.

Еще один интересный момент - наличие в сети дополнительных сообщений, на получение которых терминал не настроен, а также дополнительных сообщений, на получение которых терминал настроен, никак не влияет на быстродействие передачи сообщения, если сигналы в дополнительных GOOSE не меняют своего состояния.

А вот если меняют (по факту возникновения события) - ситуация меняется. Так, если терминал подписан на 2 дополнительных GOOSE, то время передачи может возрастать в 4 и более раза. Если еще и сигналы в фоновых GOOSE меняют свое состояние, увеличение может быть еще большим.

В таких условиях, как обозначил Stepanov, важно правильно организовать сеть, настроить коммутаторы правильным образом. И потом это все правильно проверить.

Верно, сервис GOOSE назначается на канальный уровень (Ethernet).
Что касается структуры самого пакета - можно посмотреть здесь (по скриншотам видны байтики), а здесь тоже самое, но с PRP + еще видна структура 9-2 и отчетов (MMS).

GAV, Александр, а почему Вы ушли из журнала Релейщик?
И, пожалуйста, поменьше рекламируйте тут свой бизнес, а то я буду вынужден удалить эту тему.

Слава, для ДЗШ и УРОВ "гусей" пока нет, и вообще "гуси" редко используются.
Главное принцип - сформировать максимально возможный режим.

Проверка восстановления связи конечно нужно делать, но это совсем другая проверка, не относится к быстродействию, да и не понятно в этом случае на какие времена ориентироваться.

На Вашем опыте какое было замерено самое большое время передачи сигнала по GOOSE от одного терминала другому? При этом также интересно для этого случая замера знать о наличии других GOOSE на интерфейсах отправителя и приемника ("фоновых" и на которые они были подписаны/отправляли)? И менялись ли состояния сигналов в этих "других" GOOSE поступавших на отправителя и/или получателя?

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

А можно немного подробностей о железке, если не секретно. Дело в том, что в общем случае одно GOOSE-сообщение может "переносить" несколько сигналов (команд), тогда цифры 192 в части отправки и 256 в части приёма не такие и фантастические.

Возвращаясь к теме. Фрагмент доклада с СИГРЭ-2013 в г.Екатеринбург.

http://rzia.ru/extensions/hcs_image_uploader/uploads/70000/2500/72587/thumb/p18th3q5sa9nfpui152748v1dvj1.jpg
http://rzia.ru/extensions/hcs_image_uploader/uploads/70000/2500/72587/thumb/p18th3qlgign61gd156r1h0h1k0v2.jpg