Событийные протоколы

Событийный протокол - своими словами

Если рассмотреть аллегорию с учебным классом, которая хорошо подходит, то циклические протоколы вроде Modbus, Profibus, Fieldbus - подобны опросу каждого из учеников последовательно. Даже если к устройству (ученику) нет никакого интереса. Событийные протоколы действуют иначе. Идет запрос не к каждому устройству сети (ученику) последовательно, а к классу в целом, затем собирается информация с устройства с измененным состоянием (ученика поднявшего руку). Таким образом, происходит сильная экономия сетевого трафика. Сетевые устройства не накапливают ошибки при некачественном соединении. С учетом того, что доставка события происходит с меткой времени, даже если есть некоторая задержка, мастер шины получает информацию о произошедших событиях на удаленных объектах.

История развития и внедрения событийных протоколов в автоматизации энергообъектов

Примером одной из первых успешных попыток стандартизации информационного обмена для промышленных контроллеров является протокол ModBus, разработанный компанией Modicon в 1979 г. В настоящее время протокол существует в трёх вариантах: ModBus ASCII, ModBus RTU и ModBus TCP; его развитием занимается некоммерческая организация ModBus-IDA. Несмотря на то, что ModBus относится к протоколам прикладного уровня сетевой модели OSI и регламентирует функции чтения и записи регистров, соответствие регистров типам измерений и измерительным каналам не регламентировано. На практике это приводит к несовместимости протоколов устройств разных типов даже одного производителя и необходимости поддержки большого количества протоколов и их модификаций встроенным программным обеспечением УСПД (при двухуровневой модели опроса - ПО сервера сбора) с ограниченной возможностью повторного использования программного кода. Учитывая избирательное следование стандартам производителями (использование нерегламентированных алгоритмов подсчёта контрольной суммы, изменение порядка следования байтов и т.п.), ситуация усугубляется ещё больше.

На сегодняшний день факт того, что ModBus не способен решить проблему протокольной разобщённости измерительного и контрольного оборудования для энергосистем, очевиден. Спецификация DLMS/COSEM (Device Language Message Specification), разработанная Ассоциацией пользователей DLMS (DLMS User Association) и переросшая в семейство стандартов IEC 62056, призвана обеспечить, как указано на официальном сайте ассоциации, "интероперабельную среду для структурного моделирования и обмена данными с контроллером". Спецификация разделяет логическую модель и физическое представление специализированного оборудования, а также определяет важнейшие концепции (регистр, профиль, расписание и т.п.) и операции над ними. Основным является стандарт IEC 62056-21, заменивший вторую редакцию IEC 61107.
Несмотря на более детальную по сравнению с ModBus проработку модели представления устройства и его функционирования, проблема полноты и '"чистоты" реализации стандарта, к сожалению, сохранилась. На практике опрос устройства с заявленной поддержкой DLMS одного производителя программой опроса другого производителя либо ограничен основными параметрами, либо попросту невозможен. Следует отметить, что спецификация DLMS, в отличие от протокола ModBus, оказалась крайне непопулярной среди отечественных производителей приборов учёта, в первую очередь, из-за большей сложности протокола, а также дополнительных накладных расходов на установку соединения и получение конфигурации устройства.
Полнота поддержки существующих стандартов производителями измерительного и контрольного оборудования недостаточна для преодоления внутрисистемной информационной разобщённости. Заявленная производителем поддержка того или иного стандартизированного протокола, как правило, не означает полную его поддержку и отсутствие привнесённых изменений. Образцом комплекса зарубежных стандартов является семейство стандартов IЕС 60870-5, созданных Международной электротехнической комиссией.
Различные реализации IЕС 60870-5-102 — обобщающего стандарта по передаче интегральных параметров в энергосистемах - представлены в устройствах ряда зарубежных производителей: Iskraemeco d.d. (Словения), Landis&Gyr AG (Швейцария), Circutor SA (Испания), EDMI Ltd (Сингапур) и др., но в большинстве случаев — только как дополнительные. В качестве основных протоколов передачи данных используются проприетарные протоколы или вариации DLMS. Стоит отметить, что IЕС 870-5-102 не получил широкого распространения ещё и по той причине, что некоторые производители приборов учета, в том числе отечественные, реализовали в своих устройствах модифицированные телемеханические протоколы (IEС 60870-5-101, IEС 60870-5-104), игнорируя данный стандарт.

Похожая ситуация наблюдается и среди производителей РЗА: при наличии действующего стандарта IEС 60870-5-103 зачастую реализуется ModBus-подобный протокол. Предпосылкой к этому, очевидно, стало отсутствие поддержки указанных протоколов большинством систем верхнего уровня. Телемеханические протоколы, описанные в стандартах IEС 60870-5-101 и IEС 60870-5-104, могут быть использованы при необходимости интеграции систем телемеханики и учёта электроэнергии. В связи с этим, они нашли широкое применение в системах диспетчеризации.
Технические спецификации протоколов автоматизации
В современных системах автоматизации, в результате постоянной модернизации производства, все чаще встречаются задачи построения распределенных промышленных сетей с использованием событийных протоколов передачи данных. Для организации промышленных сетей энергообъектов используется множество интерфейсов и протоколов передачи данных, например, IEC 60870-5-104, IEC 61850 (MMS, GOOSE, SV) и пр. Они необходимы для передачи данных между датчиками, контроллерами и исполнительными механизмами (ИМ), связи нижнего и верхнего уровней АСУ ТП.
Протоколы разрабатываются с учетом особенностей технологического процесса, обеспечивая надежное соединение и высокую точность передачи данных между различными устройствами. Наряду с надежностью работы в жестких условиях все более важными требованиями в системах АСУ ТП становятся функциональные возможности, гибкость в построении, простота интеграции и обслуживания, соответствие промышленным стандартам. Рассмотрим технические особенности некоторых из указанных выше протоколов.
Протокол IEC 60870-5-104

Стандарт IEC 60870-5-104 формализует инкапсуляцию блока ASDU из документа IEC 60870-5-101 в стандартные сети TCP/IP. Поддерживается как Ethernet, так и модемное соединение с использованием протокола РРР. Криптографическая безопасность данных формализована в стандарте IEC 62351. Стандартный порт TCP 2404.
Данный стандарт определяет использование открытого интерфейса TCP/IP для сети, содержащей, например, LAN (локальная вычислительная сеть) для устройства телемеханики, которая передает ASDU в соответствии с МЭК 60870-5-101. Маршрутизаторы, включающие маршрутизаторы для WAN (глобальная вычислительная сеть) различных типов (например, Х.25, Фрейм реле, ISDN и т.п.), могут соединяться через общий интерфейс ТСР/IР-LAN

Пример обшей архитектуры применения IEC 60870-5-104

Интерфейс транспортного уровня (интерфейс между пользователем и TCP) — это ориентированный на поток интерфейс, в котором не определяются какие-либо старт-стопные механизмы для ASDU (IEC 60870-5-101). Чтобы определить начало и конец ASDU, каждый заголовок APCI включает следующие маркировочные элементы: стартовый символ, указание длины ASDU вместе с полем управления. Может быть передан либо полный APDU, либо (для целей управления) только поля APCI.

Структура пакета данных протокола IEС 60870-5-104

При этом:

- APCI - Управляющая Информация Прикладного Уровня;
- ASDU - Блок Данных. Обслуживаемый Прикладным Уровнем (Блок данных Прикладного Уровня);
- APDU - Протокольный Блок Данных Прикладного Уровня.
- СТАРТ 68 Н определяет точку начала внутри потока данных.
Длина APDU определяет длину тела APDU, которое состоит из четырех байтов поля управления APCI плюс ASDU. Первый учитываемый байт - это первый байт поля управления, а последний учитываемый байт - это последний байт ASDU. Максимальная длина ASDU ограничена 249 байтами, т.к. максимальное значение длины поля APDU равно 253 байта (APDUmax=255 минус 1 байт начала и 1 байт длины), а длина поля управления - 4 байта.
Данный протокол передачи данных, в настоящий момент, де-факто является стандартным протоколом диспетчеризации для предприятий электроэнергетического сектора. Модель данных в данном стандарте развита более серьёзно, однако в нём не представлено никакое унифицированное описание энергообъекта.

Протокол DNP-3

DNP3 (Distributed Network Protocol) — это протокол передачи данных, используемый для связи между компонентами АСУ ТП. Был разработан для удобного взаимодействия между различными типами устройств и систем управления. Может применяться на различных уровнях АСУ ТП. Существует расширение Secure Authentication для DNP3 для безопасной аутентификации.
В России этот стандарт распространен слабо, однако некоторые устройства автоматизации все же поддерживают его. Долгое время протокол не был стандартизован, но сейчас он утвержден как стандарт IEEE-1815. DNP3 поддерживает и последовательные линии связи RS-232/485, и сети TCP/IP. Протокол описывает три уровня модели OSI: прикладной, канальный и физический. Его отличительной особенностью является возможность передачи данных как от ведущего устройства к ведомому, так и между ведомыми устройствами. DNP3 также поддерживает спорадическую передачу данных от ведомых устройств. В основу передачи данных положен, как и в случае с МЭК-101/104, принцип передачи таблицы значений. При этом с целью оптимизации использования коммуникационных ресурсов ведется посылка не всей базы данных, а только ее переменной части.
Важным отличием протокола DNP3 от рассмотренных ранее является попытка объектного описания модели данных и независимость объектов данных от передаваемых сообщений. Для описания структуры данных в DNP3 используется XML-описание информационной модели. DNP3 базируется на трех уровнях сетевой модели OSI: прикладном (оперирует объектами основных типов данных), канальном (предоставляет несколько способов извлечения данных) и физическом (в большинстве случаев используются интерфейсы RS-232 и RS-485). Каждое устройство имеет свой уникальный адрес для данной сети, представленный в виде целого числа от 1 до 65520. Основные термины:
- Outslation - ведомое устройство.
- Master - ведущее устройство.
- Frame (фрэйм) - пакеты, передаваемые и принимаемые на канальном уровне. Максимальный размер пакета 292 байта.
- Static data (постоянные данные) - данные, ассоциированные с каким-либо реальным значением (например, дискретным или аналоговым сигналом)
- Event data (событийные данные) - данные, ассоциированные с каким-либо значимым событием (например, изменения состояния. достижение значением пороговой отметки). Предоставляется возможность присоединения временной метки.
- Variation (вариация) - определяет, как интерпретируется значение, характеризуется целым числом.
- Group (группа) - определяет тип значения, характеризуется целым числом (например, постоянное аналоговое значение относится к группе 30, а событийное аналоговое значение к группе 32). Для каждой группы назначен набор вариаций, с помощью которых интерпретируются значения этой группы.
- Object (объект) - данные фрейма, ассоциированные с каким-то конкретным значением. Формат объекта зависит от группы и вариации.
Список вариаций приведен ниже.

Вариации для постоянных данных:

Вариации для событийных данных:

Флаги подразумевают под собой наличие специального байта со следующими информационными битами: источник данных on-line, источник данных был Флаги подразумевают под собой наличие специального байта со следующими информационными битами: источник данных on-line, источник данных был перезагружен, соединение с источником потеряно, запись значения форсирована, значение вне допустимых границ.

Заголовок фрейма:

Синхронизация - 2байта синхронизации, позволяющие получателю идентифицировать начало фрэйма. Длина - количество байт в оставшейся части пакета без учета октетов CRC. Контроль соединения - байт для координирования приема передачи фрэйма. Адрес назначения - адрес устройства, которому назначается передача. Исходный адрес - адрес устройства, осуществляющего передачу. CRC - контрольная сумма для байта заголовка. Раздел данных DNP3 фрэйма содержит (помимо самих данных) по 2 байта CRC для каждых 16 байт передаваемой информации. Максимальное количество байт данных (не включая CRC) для одного фрэйма - 250.

Протокол IEC 61850 MMS

MMS определяет:
- набор стандартных объектов, над которыми совершаются операции, которые должны существовать в устройстве (например: чтение и запись переменных, сигнализация о событиях и т.д.),
- набор стандартных сообщений. которыми осуществляется обмен между клиентом и севером для осуществления операций управления;
- набор правил кодирования этих сообщений (то есть как значения и параметры назначаются на биты и байты при пересылке);
- набор протоколов (правила обмена сообщениями между устройствами). Таким образом, MMS не определяет прикладных сервисов, которые, как мы уже увидели, определены стандартом МЭК 61850. Кроме того, протокол MMS сам по себе не является коммуникационным протоколом, он лишь определяет сообщения, которые должны передаваться по определенной сети. В качестве коммуникационного протокола в MMS используется стек TCP/IP.

Общая структура применения протокола MMS для реализации сервисов передачи данных в соответствии с МЭК 61850 представлена ниже.

Диаграмма передачи данных по протоколу MMS

Такая достаточно сложная, на первый взгляд, система в конечном счёте позволяет с одной стороны обеспечить неизменность абстрактных моделей (а, следовательно, неизменность стандарта и его требований), с другой - использовать современные коммуникационные технологии на базе IР-протокола. Однако следует отметить, что ввиду большого количества назначений, протокол MMS является относительно медленным (например, по сравнению с GOOSE), поэтому его применение для приложений реального времени нецелесообразно. Основное назначение протокола MMS - реализация функций АСУ ТП, то есть сбор данных телесигнализации и телеизмерений и передача команд телеуправления.
Для целей сбора информации протокол MMS предоставляет две основные возможности:
- сбор данных с использованием периодического опроса сервера(-ов) клиентом;
- передача данных клиенту сервером в виде отчетов (спорадически).
Оба этих способа востребованы при наладке и эксплуатации системы АСУ ТП, для определения областей их применения подробнее рассмотрим механизмы работы каждого.
На первом этапе между устройствами клиентом и сервером устанавливается соединение (сервис «Association»). Установку соединения инициирует клиент, обращаясь к серверу по его IР-адресу.

Механизм передачи данных «клиент-сервер»

Следующим этапом клиент запрашивает определенные данные у сервера и получает от сервера ответ с запрошенными данными. Например, после установки соединения клиент может запросить у сервера его информационную модель с использованием сервисов GetServerDirectory, GetLogicalDeviceDirectory, GetLogicalNodeDiretory. Запросы при этом будут осуществляться последовательно:
- после запроса GetServerDirectory сервер вернёт перечень доступных логических устройств.
- после отдельного запроса GelLogicalDeviceDirectory для каждого логического устройства сервер вернёт перечень логических узлов в каждом из логических устройств.
- запрос GetLogicalNodeDirectory для каждого отдельного логического узла возвращает его объекты и атрибуты данных.
В результате клиент считает и воссоздаст у себя полную информационную модель устройства-сервера. При этом фактические значения атрибутов ещё не будут считаны, то есть считанное «дерево» будет содержать лишь имена логических устройств, логических узлов, объектов данных и атрибутов, но без их значений. Третьим этапом может быть осуществлено считывание фактических значений всех атрибутов данных. При этом могут быть считаны, либо все атрибуты с использованием сервиса GetAllDataValues, либо лишь отдельные атрибуты с использованием сервиса GetDataValues. По завершении третьего этапа клиент полностью воссоздаст у себя информационную модель сервера со всеми значениями атрибутов данных. Следует отметить, что указанная процедура предполагает обмен достаточно большими объёмами информации с большим, зависящим от количества логических устройств логических узлов и числа объектов данных, реализуемых сервером, количеством запросов и ответов. Это также ведёт к достаточно высокой нагрузке на аппаратную часть устройства. Эти этапы могут осуществляться на этапе наладки SCADA-системы для того, чтобы клиент, считав информационную модель, мог обращаться к данным на сервере. Однако при дальнейшей эксплуатации системы регулярное считывание информационной модели не требуется. Равно как нецелесообразно постоянно считывать значения атрибутов методом регулярного опроса. Вместо этого может использоваться сервис передачи отчётов - Report. МЭК 61850 определяет два вида отчетов - буферизируемые и небуферизируемые. Основное отличие буферизируемого отчета от небуферизируемого заключается в том, что при использовании первого формируемая информация будет доставлена до клиента даже в том случае, если на момент готовности выдачи отчета сервером связь между ним и клиентом отсутствует (например, был нарушен соответствующий канал связи). Вся формируемая информация накапливается в памяти устройства и ее передача будет выполнена, как только связь между двумя устройствами восстановится. Единственное ограничение - объем памяти сервера, выделенный для хранения отчетов. Если за тот промежуток времени, когда связь отсутствовала, произошло достаточно много событий, вызвавших формирование большого числа отчетов, суммарный объем которых превысил допустимый объем памяти сервера, то некоторая информация все же может быть потеряна и новые формируемые отчеты «вытеснят» из буфера ранее сформированные данные, однако в этом случае сервер, посредством специального атрибута управляющего блока, просигнализирует клиенту о том, что произошло переполнение буфера и возможна потеря данных. Если же связь между клиентом и сервером присутствует — как при использовании буферизируемого, так и при использовании небуферизируемого отчета — передача данных в адрес клиента может быть немедленной по факту возникновении определенных событий в системе (при условии того, что интервал времени, за которой производится фиксация событий, равен нулю). Когда речь идет об отчетах, подразумевается контроль не всех объектов и атрибутов данных информационной модели сервера, а лишь тех, которые нас интересуют, объединенных в так называемые «наборы данных». Используя буферизируемый/небуферизируемый отчет, можно настроить сервер не только на передачу всего контролируемого набора данных, но и на передачу только тех объектов/атрибутов данных, с которыми происходят определенного рода события за предопределенный пользователем временной интервал.
Для этого в структуре управляющего блока передачей буферизируемых и небуферизируемых отчетов предусмотрена возможность задания категорий событий, возникновение которых необходимо контролировать и по факту которых будет производится включение в отчет только тех объектов/атрибутов данных, которых коснулись эти события. Различают следующие категории событий:
- изменение данных (dchg). При задании этого параметра в отчет будут включаться только те атрибуты данных, значения которых изменились, или только те объекты данных, значения атрибутов которых изменились.
- изменение атрибута качества (qchg). При задании этого параметра в отчет будут включаться только те атрибуты качества, значения которых изменились, или только те объекты данных, атрибуты качества которых изменились.
- обновление данных (dupd). При задании этого параметра в отчет будут включаться только те атрибуты данных, значения которых были обновлены, или только те объекты данных, значения атрибуты которых были обновлены. Под обновлением понимается, к примеру, периодическое вычисление той или иной гармонической составляющей и запись в соответствующий атрибут данных ее нового значения. Однако даже в том случае, если значение по результатам вычислений на новом периоде не изменилось, объект данных или соответствующий атрибут данных включаются в отчет.
Можно также настроить отчет на передачу всего контролируемого набора данных. Такая передача может быть выполнена либо по инициативе сервера (условие integrity), либо по инициативе клиента (general-interrogation). Если введено формирование данных по условие integrity, то пользователю также необходимо указать период формирования данных сервером. Если введено формирование данных по условию general-interrogation. сервер будет формировать отчет со всеми элементами набора данных по факту получения соответствующей команды от клиента.
Механизм передачи отчетов обладает важными преимуществами перед методом периодического опроса («polling»): существенно сокращается нагрузка на информационную сеть, сокращается нагрузка на процессор устройства-сервера и устройства-клиента, обеспечивается быстрая доставка сообщений о возникающих в системе событиях. Однако важно отметить, что всех достоинств использования буферизируемых и небуферизируемых отчетов можно достичь только лишь при правильной их настройке, что, в свою очередь, требует от персонала, выполняющего наладку оборудования, достаточно высокой квалификации и большого опыта.
Помимо описанных сервисов, протокол MMS также поддерживает модели управления оборудованием- формирование и передачу журналов событий, а также передачу файлов, что позволяет передавать, например, файлы аварийных осциллограмм. Указанные сервисы требуют отдельного рассмотрения. Протокол MMS является одним из протоколов, на который могут быть назначены абстрактные сервисы, описанные стандартом МЭК 61850-7-2. При этом появление новых протоколов не будет оказывать влияние на модели, описанные стандартом, обеспечивая, тем самым, неизменность стандарта со временем. Для назначения моделей и сервисов на протокол MMS используется глава МЭК 61850-8-1. Протокол MMS обеспечивает различные механизмы считывания данных с устройств, включая чтение данных по запросу и передачу данных в виде отчётов от сервера клиенту. В зависимости от решаемой задачи должен быть выбран правильный механизм передачи данных и должна быть выполнена соответствующая его настройка, что позволит эффективно применять весь набор коммуникационных протоколов стандарта МЭК 61850 на энергообъекте.

Протокол IEC 61850 GOOSE

Формирование GOOSE-сообщений

Передача GOOSE-сообщений

По своему назначению GOOSE-сообщение призвано заменить передачу дискретных сигналов по сети оперативного тока. Рассмотрим какие требования при этом предъявляются к протоколу передачи данных. Для разработки альтернативы цепям передачи сигналов между устройствами релейной зашиты были проанализированы свойства информации, передаваемой между устройствами РЗА посредством дискретных сигналов:
- малый объем информации - между терминалами фактически передаются значения «истина» и «ложь» (или логический «ноль» и «единица»);
- требуется высокая скорость передачи информации - большая часть дискретных сигналов, передаваемых между устройствами РЗА, прямо или косвенно влияет на скорость ликвидации ненормального режима, поэтому передача сигнала должна осуществляться с минимальной задержкой;
- требуется высокая вероятность доставки сообщения - для реализации ответственных функций, таких как подача команды отключения выключателя от РЗА, обмен сигналами между РЗА при выполнении распределенных функций, требуется обеспечение гарантированной доставки сообщения как в нормальном режиме работы цифровой сети передачи данных, так и в случае её кратковременных сбоев;
- возможность передачи сообщений сразу нескольким адресатам - при реализации некоторых распределенных функций РЗА требуется передача данных от одного устройства сразу нескольким;
- необходим контроль целостности канала передачи данных - наличие функции диагностики состояния канала передачи данных позволяет повысить коэффициент готовности при передаче сигнала, тем самым, повышая надёжность функции, выполняемой с передачей указанного сообщения.
Предъявленные требования привели к разработке механизма GOOSE-сообщений, отвечающих всем предъявляемым требованиям. В аналоговых цепях передачи сигналов основную задержку при передаче сигнала вносит время срабатывания дискретного выхода устройства и время фильтрации дребезга на дискретном входе принимающего устройства. Время распространения сигнала по проводнику в сравнении с этим мало.
Аналогично в цифровых сетях передачи данных основную задержку вносит не столько передача сигнала по физической среде, сколько его обработка внутри устройства. В теории сетей передачи данных принято сегментировать сервисы передачи данных в соответствии с уровнями модели OSI, как правило, спускаясь от «Прикладного», то есть уровня прикладного представления данных, к «Физическому», то есть уровню физического взаимодействия устройств. В классическом представлении модель OSI имеет всего семь уровней: физический, канальный, сетевой, транспортный, сеансовый, уровень представления и прикладной. Однако, реализуемые протоколы могут иметь не все из указанных уровней, то есть некоторые уровни могут быть пропущены.
Наглядно механизм работы модели OSI можно представить на примере передачи данных при просмотре WEB-страниц в сети Интернет на персональном компьютере. Передача содержимого страниц в Интернет осуществляется по протоколу HTTP (Hypertext Transfer Protocol), являющемуся протоколом прикладного уровня. Передача данных протокола HTTP обычно осуществляется транспортным протоколом TCP (Transmission Control Protocol). Сегменты протокола TCP инкапсулируются в пакеты сетевого протокола, которым в данном случае выступает IP (Internet Protocol). Пакеты протокола TCP составляют кадры протокола канального уровня Ethernet, которые в зависимости от сетевого интерфейса могут передаваться с использованием различного физического уровня. Таким образом данные просматриваемой страницы в сети Интернет, проходят, как минимум четыре уровня преобразования при формировании последовательности битов на физическом уровне, и затем столько же шагов обратного преобразования. Такое количество преобразований ведёт к возникновению задержек как при формировании последовательности битов с целью их передачи, так и при обратном преобразовании с целью получения передаваемых данных. Соответственно, для уменьшения времени задержек количество преобразований должны быть сведено к минимуму. Именно поэтому данные по протоколу GOOSE (прикладного уровня) назначаются непосредственно на канальный уровень - Ethernet, минуя остальные уровни.
Вообще, главой МЭК 61850-8-1 предусмотрено два коммуникационных профиля, которыми описываются все протоколы передачи данных, предусмотренные стандартом:
- Профиль «MMS»;
- Профиль «Non-MMS» (то есть не-MMS).
Соответственно, сервисы передачи данных могут быть реализованы с использованием одного из указанных профилей. Протокол GOOSE (равно как и протокол Sampled Values) относится именно ко второму профилю. Использование «укороченного» стека с минимальным количеством преобразований - это важный, однако не единственный, способ ускорения передачи данных. Также ускорению передачи данных по протоколу GOOSE способствует использование механизмов приоритезации данных. Так, для протокола GOOSE используется отдельный идентификатор кадра Ethernet - Ethertype, который имеет заведомо больший приоритет по сравнению с остальным трафиком, например, передаваемым с использованием сетевого уровня IP. Помимо рассмотренных механизмов, кадр Ethernet GOOSE-сообщения также может снабжаться метками приоритета протокола IEEE 802.1Q. а также метками виртуальных локальных сетей протокола ISO/IEC 8802-3. Такие метки позволяют повысить приоритет кадров при обработке их сетевыми коммутаторами. Подробнее эти механизмы повышения приоритета будут рассмотрены в последующих публикациях.
Использование всех рассмотренных методов позволяет значительно повысить приоритет данных, передаваемых по протоколу GOOSE, по сравнению с остальными данными, передаваемыми по той же сети с использованием других протоколов, тем самым, сводя к минимуму задержки как при обработке данных внутри устройств источников и приёмников данных, так и при обработке их сетевыми коммутаторами.

Отправка информации нескольким адресатам

Для адресации кадров на канальном уровне используются физические адреса сетевых устройств - МАС-адреса. При этом Ethernet позволяет осуществлять так называемую групповую рассылку сообщений (Multicast). В таком случае в поле МАС-адреса адресата указывается адрес групповой рассылки. Для многоадресных рассылок по протоколу GOOSE используется определенный диапазон адресов.

Диапазон адресов многоадресной рассылки для GOOSE-сообщений

Сообщения, имеющие значение «01» в первом октете адреса, отправляются на все физические интерфейсы в сети, поэтому фактически многоадресная рассылка не имеет фиксированных адресатов, а её МАС-адрес является скорее идентификатором самой рассылки, и не указывает напрямую на её получателей.

Таким образом МАС-адрес GOOSE-сообщения может быть использован, например, при организации фильтрации сообщении на сетевых коммутатора (МАС-фильтрации), а также указанный адрес может служить в качестве идентификатора, на который могут быть настроены принимающие устройства.
Таким образом передачу GOOSE-сообщений можно сравнить с радиотрансляцией: сообщение транслируется всем устройствам в сети, но для получения и последующей обработки сообщения устройство-приёмник должно быть настроено на получение этого сообщения.

Схема передачи GOOSE-сообщений

Интервал между отправками GOOSE-сообщений

В-третьих, в пакете GOOSE-сообщения предусмотрено несколько полей-счётчиков, по которым также может контролироваться целостность канала связи. К таким счётчикам, например, относится циклический счётчик посылок (sqNum), значение которого изменяется от 0 до 4 294 967 295 или до изменения передаваемых данных. При каждом изменении данных, передаваемых в GOOSE -сообщении, счётчик sqNum будет сбрасываться, также при этом увеличивается на 1 другой счётчик — stNum, также циклически изменяющийся в диапазоне от 0 до 4 294 967 295. Таким образом, при потере нескольких пакетов при передаче, эту потерю можно будет отследить по двум указанным счётчикам.

Наконец, в-четвертых, важно также отметить, что в посылке GOOSE, помимо самого значения дискретного сигнала, может также содержаться признак его качества, который идентифицирует определенный аппаратный отказ устройства-источника информации, нахождение устройства-источника информации в режиме тестирования и ряд других нештатных режимов. Таким образом, устройство-приемник, прежде чем обработать полученные данные согласно предусмотренным алгоритмам, может выполнить проверку этого признака качества. Указанное может предупредить неверную работу устройств-приемников информации (например, их ложную работу).
Следует иметь в виду, что некоторые из заложенных механизмов обеспечения надёжности передачи данных при их неправильном использовании могут приводить к негативному эффекту. Так, в случае выбора слишком короткого максимального интервала между сообщениями, нагрузка на сеть увеличивается, хотя, с точки зрения готовности канала связи, эффект от уменьшения интервала передачи будет крайне незначительным.
При изменении атрибутов данных, передача пакетов с минимальной выдержкой времени вызывает повышенную нагрузку на сеть (режим «информационного шторма»), которая теоретически может приводить к возникновению задержек при передаче данных. Такой режим является наиболее сложным и должен приниматься за расчётный при проектировании информационной сети. Однако следует понимать, что пиковая нагрузка очень кратковременна и её многократное снижение, согласно проводившимся нами опытам в лаборатории по исследованию функциональной совместимости устройств, работающих по условиям стандарта МЭК 61850, наблюдается на интервале в 10 мс.
При построении систем РЗА на основе протокола GOOSE изменяются процедуры их наладки и тестирования. Теперь этап наладки заключается в организации сети Ethernet энергообъекта. в которую будут включены все устройства РЗА. между которыми требуется осуществлять обмен данными. Для проверки того, что система настроена и включена в соответствии с требованиями проекта, становится возможным использование персонального компьютера со специальным предустановленным программным обеспечением (Wireshak, GOOSE Monitor и др.) или специального проверочного оборудования с поддержкой протокола GOOSE (PETOM 61850. Omicron CMC). Важно отметить, что все проверки можно производить не нарушая предварительно установленные соединения между вторичным оборудованием (устройствами РЗА, коммутаторами и др.), поскольку обмен данными производится по сети Ethernet. При обмене дискретными сигналами между устройствами РЗА традиционным способом (подачей напряжения на дискретный вход устройства-приемника при замыкании выходного контакта устройства, передающего данные), напротив, часто требуется разрывать соединения между вторичным оборудованием для включения в цепь испытательных установок с целью проверки правильности электрических соединений и передачи соответствующих дискретных сигналов. Таким образом, протокол GOOSE предусматривает целый комплекс мер, направленных на обеспечение необходимых характеристик по быстродействию и надёжности при передаче ответственных сигналов. Применение данного протокола в сочетании с правильным проектированием и параметрированием информационной сети и устройств РЗА позволяет в ряде случаев отказаться от использования медных цепей для передачи сигналов, обеспечивая при этом необходимый уровень надёжности и быстродействия.

Скачать ГОСТ 61850 международных стандартов Вы можете по ссылке

Автор: Тимофей Бусыгин (Московский Энергетический Институт)
#MMS, #GOOSE, #SV, #870-104, #событийныйпротокол, #скачать61850, #скачать61870-5-104