GOOSE: одно сообщение со всеми сигналами или несколько сообщений с группами сигналов?
Вот пример реального проекта (устройства и сигналы намеренно переименованы), справа показан набор данных, передаваемых в GOOSE-сообщении, а слева — устройства, которые принимают сигналы из данного GOOSE-сообщения.
При этом можно видеть, что не все сигналы в GOOSE сообщении обрабатываются каждым из устройств: так, сигнал Signal1, включая его stVal и атрибут качества q передаётся всем устройствам IED2…IED9.
А вот остальные сигналы Signal2…Signal5 передаются только устройствам IED2 и IED 3.
В качестве альтернативного варианта решения проблемы можно было бы предложить разделить рассматриваемое GOOSE-сообщение на 2:
- GOOSE с данными только Signal1 — на него подписаны все IED.
- GOOSE с данными Signal2…Signal5 — на него подписаны IED2…IED3.
В таком случае, очевидно, возрастёт нагрузка на сетевой интерфейс принимающих устройств, так как придётся обрабатывать уже два GOOSE вместо одного, но зато (вероятно) снизится нагрузка на прикладном уровне, так как разбирать надо будет меньшее количество сигналов.
Интересно было бы получить комментарии коллег-разработчиков по следующим вопросам (с учётом специфики реализации своих терминалов):
- Если считать, что сеть “прозрачная”, то есть фильтрация трафика отсутствует: что лучше с точки зрения производительности устройств IED2…IED3 и IED4…IED9: иметь одно GOOSE-сообщение со всеми сигналами (как сделано в проекте) или поделить данные между 2 GOOSE-сообщениями (как предложено выше)?
- Если ввести фильтрацию трафика и ограничить приход неиспользуемых данных, то насколько это положительно скажется на производительности терминалов, которым не будут приходить “лишние” данные (в данном случае, это может быть выражено в том, что 2-e GOOSE-сообщение с данными Signal2…Signal5 будет приходить ТОЛЬКО на IED2…IED3) и сделает ли деление одного GOOSE-сообщения на 2 более целесообразным?
- Если приведенный пример (в силу не очень большого количества сигналов) не очень показателен, то при каком количестве сигналов (хотя бы порядок) вопрос становится актуальным?
На основании блога компании Теквел
Вопрос очень интересный и актуальный!
Если абстрагироваться от состояния сети и учесть только обработку GOOSE сообщений принимающими устройствами, то очевидно, что разбиение одного GOOSE сообщения на более рациональные, в данном случае, ведёт к ускорению обработки, а значит и производительности в целом.
Представьте, что у нас первый случай и мы имеем всего лишь одно большое GOOSE сообщение. Например, на отдельном промежутке времени у нас происходит срабатывание только состояний Signal4, при этом значение stNum у нашего GOOSE в этом случае каждый раз будет расти, что приводит к обработке этого сообщения в том числе и подписанными на него устройствами IED4-IED9, каждый раз, при генерации любого события на которые они не подписаны. А если конфигурация объекта составлена так, что значительно чаще будет срабатывать именно сигналы Signal3-Signal5, то оцените, сколько пустой проделанной работы по обработке и разбору этого сообщения будет у подписчиков устройств IED4-IED9?
Если рассматривать в этом ключе, конечно лучше грамотнее подходить к распределению передачи данных по GOOSE сообщениям ещё на этапе проектирования, и в данном случае воспользоваться вторым вариантом с разбиением одного большого GOOSE на более целевые. И не важно какая сеть, хоть «прозрачная», хоть нет, эффект от этого в любом случае будет положительный.
P.s.: Очевидно также, что возможны и частные случае (например, когда будет в 99% изменятся только Signal1), в которых не будет сильно заметен эффект от разбиения одного большого GOOSE сообщения. Но это всё уже зависит от специфики конкретного объекта.
Насколько я знаю, для приемника быстрее разобрать 1 Ehternet кадр, т.е. 1 Goose, чем много разных гусей, пусть и с небольшим количеством сигналов, т.к. раскодировать кадр тяжелее, чем просто считать биты из уже раскодированного.
В любом случае нужны цифры, оценки, и я сильно подозреваю, что разница будет минимальной для обоих случаев. Если это так, вопрос не актуальный. Нужно просто делать как удобнее всем, т.е. минимальное количество Goose.
Что именно значит “считать биты из уже раскодированного”? Как узнать что он уже “раскодирован” не разбирая его заголовок каждый раз вновь?
Я как раз и говорю, что не свой GOOSE нет смысла даже разбирать после первой нестыковки в заголовке (а она уже будет скорее всего на первом же параметре тела сообщения, т.е. атрибут “gocbRef”), отсюда и эффект, что времени на разбор затрачено практически совсем и не будет.
Да, в таком случае мы goose сразу откинем, но как сильно это отличается от варианты когда мы в большом goose добираемся до своего сигнала? Как сильно это отразится на производительности? Если разница минимальная (скорее всего), то смысла нет. Лучше уж делать удобнее для всех, проектировщиков, наладчиков, эксплуатации… Да и для анализа трафика легче.
Посмотрим с точки зрения издателя… Для него тоже будет быстрее закодировать один goose чем кучу. Но опять же, насколько легче =)
В моем первом сообщении как раз и рассмотрен случай когда эффект от разбиения в плане производительности будет просто огромным. И это далеко не частный случай. Скорее частный случай, это когда эффект будет минимальным.
Что значит огромный? Пожалуйста, приведите цифры. Попробуем оценить например с точки зрения РЗА, а лучше даже требований к времени передачи Goose.
Чтобы обработать GOOSE до атрибута “gocbRef” Нам необходимо разобрать всего 12 байт плюс длина “gocbRef”, в случае же полного разбора добавляем разбор всех остальных атрибутов, а это уже от 50-200 байт плюс “allData” (от 5 до 1400 байт).
Уже значительный эффект! А если учесть что данные будут изменяться как описано в моём первом сообщении, эффект растет в геометрической прогрессии!
Пример грубый, но наглядный.
Да, пример очень грубый. Не учтены:
– нагрузка на издателя которому нужно кодировать кучу goose
– производительность терминалов, из этого уже можно судить о том много или мало байт
– требования к допустимым задержкам.
Поэтому пример для специалиста не наглядный.
– Вопрос в данной теме поднимался именно со стороны подписчиков, поэтому я и старался отразить ситуацию именно с их стороны.
– Очень хорошо, конечно, если на объекте стоят терминалы, у которых с производительностью проблем не возникает. Но это ведь не отменяет лишнюю работу проделанную ими?
Вижу что Вы не согласны с моей точкой зрения. Могу тогда попросить привести пример Вашей точки зрения в цифрах о “минимальной разнице” по производительности?
Справедливо ) Цифры измерить смогу, но привести нет. Боюсь это коммерческая тайна, а при регистрации я указал настоящие имя и фамилию ) В любом случае мы с Вами дали хорошую начальную информацию для всех.
P.S. Если лишняя работа не существенна, то лучше сделать ставку на удобство.
Согласен, в случаях минимального эффекта, а такие случаи всё равно есть, можно больше внимания уделить удобству в решении этого вопроса, но я считаю, что только в таких ситуациях.
А так хотелось бы услышать больше мнений, так как вопрос очень интересный. Надеюсь коллеги поддержат нашу дискуссию, и картина станет более объективной.
Для MMS используется минимальное BER кодирование, то есть найти позицию конкретного элемента не прочитав предыдущих невозможно.
А для GOOSE сообщений кодирование осуществляется полями фиксированной длины (61850-8-1 A.3 Fixed-length encoded GOOSE message). Возможно найти конкретный сигнал не разбирая остальные.
Значит скорость разбора 2-х элементов из GOOSE сообщения длиной 2 элемента и GOOSE сообщения длиной 100 элементов будет одинаковой.
Денис, спасибо большое! Насколько я понял, в рассматриваемом случае вы исходите из того, что дальнейший анализ содержимого пакета делается только в том случае, если stNum по сравнению с предыдущим изменился. Думаю, это не универсальный алгоритм и полагаю, что это будет справедливо в отношении не всех производителей, но случай крайне полезный, спасибо ещё раз!
Алексей, Вы всё правильно поняли.
Просто для чего ещё нужен stNum, кроме как определять были ли изменения в интересующем нас DataSet?
Маловато исходных данных.
Во-первых, как часто могут изменяться сигнал 1 и сигналы 2-5?
Во-вторых, имеется ли логическая связь между сигналом 1 и каким-либо из сигналов 2-5, так что они обрабатываются в приемнике одним алгоритмом? Если, к примеру, есть пара сигналов “1 пуск” – “3 блокировка”, то надежнее ПМСМ их передавать в одном сообщении.
Вообще, если подумать, система передачи гусей несколько ущербна, поскольку разрушает (во всяком случае, позволяет разрушить) объектную модель данных: можно передать stval без данных качества, перемешать их, подменить. Если бы передавался целиком DO в объеме всех определенных DA с FC=ST,MX – было бы надежнее.
Пока не известно. Нет оснований полагать, что они будут изменяться очень часто, а также что будет существовать большая разница в частоте изменений.
Опять же, изначально это не задано, может есть, а может и нет. Но насколько я понял Вас, то если связь есть – лучше передать в одном GOOSE.
Не стоит рассматривать GOOSE сугубо в качестве замены проводных цепей передачи дискретных сигналов.
Свойства дискретного входа устройства РЗиА сильно отличаются от GOOSE, несмотря на то, что передают они один и тот же вид данных. Дискретный вход имеет собственное время срабатывания, значительно превышающее время доставки GOOSE при условии нормальной работы сети. Принято считать это недостатком ДВх, но не стоит забывать, что алгоритмы РЗиА это учитывают, что превращает недостаток просто в одно из свойств согласованной системы обработки информации.
Помимо этого, ДВх для РЗиА является по сути просто источником внешнего сигнала, тогда как при работе с GOOSE стоит все же говорить о распределенной системе обработки информации.
А теперь мы весело забываем обо всем и “улучшаем”, а на самом деле – изменяем – один компонент, создавая в результате опасность развала согласованной системы.
В приведенном мной выше примере с сигналами “Пуск” и “Блокировка”, конечно в алгоритме обработки должна быть выдержка времени, но в классической схеме ее минимальная величина будет отстроена от возможной разновременности, включая формирование исходных сигналов, их передачу, срабатывание дискретных входов, а также возможное попадание в разные программные циклы обработки. Теперь же, если сигналы переведены на GOOSE, надо учесть особенности их передачи, возможность потери данных, необходимость контроля quality и способ реагирования на его отклонение (может быть разный, в зависимости от алгоритма), и откинуть то, что было характерно для обычных дискретных входов.
Я о том, что надо рассматривать вопрос комплексно.
В настоящее время в рамках создания национального профиля IEC 61850 созданы три типа сигналов GOOSE.
I – сигналы РЗА, ПА, а также сигналы, блокирующие работу РЗА при неисправностях.
II – сигналы неисправности устройств, не влияющие на работоспособность или неправильную работу РЗА и электрооборудования.
III – сигналы положения разъединителей, ЗН, тележек выключателей и сигналы разрешения управления КА.
Можно разделить все сигналы на три GOOSE сообщения, для коммутатора будет обеспечена спокойная работа, но тогда терминал вынужден будет обрабатывать огромное количество ненужной информации. Если разбить на мелкие GOOSE ситуация будет противоположной.
Истина, наверное, где-то посередине. Её нужно найти и принять как стандарт.
Вариант 1. с попыткой разбить GOOSE по приёмникам
Вариант 2. количество GOOSE определяется количеством типов сигналов
С нашей точки зрения вопрос слишком обобщенный, чтобы дать конкретный ответ на него.
В данном примере видно, что у IED1 есть Сигнал1, который принимают все остальные устройства. Это значит, что IED2…IED9 будут обязаны принимать от него данные и работать над разбором сообщения. С этой точки зрения логично иметь одно сообщение со всеми сигналами. Так удобнее, в том числе, и отправителю.
Но с другой стороны, имеется один сигнал, который принимают все и три сигнала, которые принимает только IED2 и IED3.
Если считать, что вероятность изменения сигналов одинаковая, то, скажем, для IED4 процент полезной обработки такого сообщения будет всего лишь 25%.
Тогда логичнее разбить сообщение на два. Тут вариантов тоже может быть несколько.
Первый вариант – GOOSE1 – содержит только Сигнал1 и предназначено для IED2…IED9. Второе сообщение GOOSE2 содержит сигналы 2-4 и предназначено для IED2 и IED3.
Недостаток данного варианта в том, что IED2 и IED3 придется обрабатывать 2 сообщения, в которых вероятность получения «полезных» данных равна 100%. Тогда, для минимизации загрузки на обработку желательно во второе сообщение также поместить Сигнал1.
Получится GOOSE1(Сигнал 1), на которое подписаны IED4…9 и GOOSE2(Сигнал 1…4), на которое подписаны IED2 и IED3.
Все выше сказанное на самом деле может очень сильно зависеть от реализации обработки сообщений конкретного производителя, а также, учитывая «дискретность» логики устройств и закладываемый запас производительности, может свести на нет различия между этими способами. На наш взгляд, производительности устройств должна быть выполнена с некоторым запасом, чтобы проектировщик не ломал голову над такими особенностями.
По просьбе “Цифровой подстанции” высказываю мнение ООО “Прософт-Системы”:
Логичнее, чтобы подписчик получал только ту информацию, которая ему необходима для выполнения задач.
Но и издателю публиковать 100-тни GOOSE с набором по одному сигналу тоже не логично. Поэтому надо отталкиваться от задач, которые решаются с помощью GOOSE сообщений в проекте.
Что можно передавать в GOOSE сообщениях с контролеров присоединений/терминалов РЗА и тд., установленных на одном присоединении:
– Текущее положение коммутационных аппаратов
– Сигналы пуска защит
– Вычисляемые сигналы блокировок и т.д.
По этому же принципу и формировать наборы данных, устанавливая необходимые приоритеты и периоды следования.
Главное, чтобы это разбиение было указано в проекте иначе наладчики настроят так, как они «привыкли» и «нам кто-то так сказал», а под требования уже подстроятся производители.
Так же отмечаем, что для контроллеров нашего производства не критично большое количество Spam-трафика, так как на сетевых картах наших устройств реализована фильтрация Ethernet-пакетов по MAC адресу.