Международная электротехническая комиссия (МЭК) является основной международной организацией по стандартизации в области электрических, электронных технологий и всех связанных с этой областью технологий, включая разработку и производство датчиков температуры. МЭК была основана в Лондоне в 1906 г. Первым президентом МЭК был знаменитый британский ученый лорд Келвин. В ее состав входят представители 82 стран (60 стран - полноправные члены, 22 страны - ассоциированные члены). Россия, Украина и Белоруссия являются полноправными членами МЭК. Представители НК РФ входят в состав многих технических комитетов и рабочих групп МЭК. Стандарты по температурным датчиках разрабатываются в основном в рамках ТК 65В/РГ5 (SC 65B - Measurement and control devices, WG5 - Temperature sensors and instruments). На базе НК РФ МЭК создана Российская группа экспертов по температуре (РГЭ), задачей которой является активное участие в разработке стандартов МЭК по температуре. Подробности - в разделе РГЭ . Вся информация о действующих и вновь разрабатываемых стандартах МЭК получена с портала МЭК: www.iec.ch

Действующие стандарты:

Об участии Российских специалистов в разработке стандартов МЭК - в разделе

В 1881 г. состоялся первый Международный конгресс по электричеству, а в 1904 г. правительственными делегациями конгресса было решено создать специальную организацию по стандартизации в этой области. Как Международная электротехническая комиссия она начала работать в

Советский Союз являлся членом МЭК с 1922 г. Россия стала правопреемником СССР и представлена в МЭК Госстандартом РФ. Российская сторона принимает участие более чем в 190 технических комитетах и подкомитетах. Штаб-квартира находится в Женеве, рабочие языки – английский, французский, русский.

Основными объектами стандартизации являются: материалы для электротехнической промышленности (жидкие, твердые, газообразные диэлектрики, медь, алюминий, их сплавы, магнитные материалы); электротехническое оборудование производственного назначения (сварочные аппараты, двигатели, светотехническое оборудование, реле, низковольтные аппараты, кабель и др.); электроэнергетическое оборудование (паровые и гидравлические турбины, линии электропередач, генераторы, трансформаторы); изделия электронной промышленности (интегральные схемы, микропроцессоры, печатные платы и т.д.); электронное оборудование бытового и производствен­ного назначения; электроинструменты; оборудование для спутников связи; терминология.

Организационная структура МЭК представлена на рис. 1.6. Высшим руководящим органом МЭК является Совет. Основным координационным органом является Комитет действий, в подчинении которого работают комитеты по направления и консультативные группы: АКОС - консультативный комитет по вопросам электробезопасности электробытовых приборов, радиоэлектронной аппаратуры, высоковольтного оборудования и др.; АСЕТ - консультативный комитет по вопросам электроники и связи занимается, так же, как и АКОС, вопросами электробезопасности; КГЭМС – координационная группа по электромагнитной совместимости; КГИТ - координационная группа по технике информации; рабочая групп по координации размеров.

Рис. 1.6. Организационная структура МЭК ]

Группы могут быть постоянно действующими или создаваться по необходимости.

Структура технических органов МЭК, непосредственно разрабаты-вающих международные стандарты, аналогична структуре ИСО: это тех-нические комитеты (ТК), подкомитеты (ПК) и рабочие группы (РГ).

МЭК сотрудничает с ИСО, совместно разрабатывая руководства ИСО/МЭК и директивы ИСО/МЭК по актуальным вопросам стандартизации, сертификации, аккредитации испытательных лабораторий и методическим аспектам.

Самостоятельный статус в МЭК имеет Международный специальный комитет по радиопомехам (СИСПР), так как является совместным комитетом участвующих в нем заинтересованных международных организаций (создан в 1934 г.).

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

Так как СИСПР является комитетом МЭК, то в его работе принимают участие все национальные комитеты, а также ряд заинтересованных международных организаций. В качестве наблюдателей в работе СИСПР принимают участие Международный консультативный комитет по радиосвязи и Международная организация гражданской авиации. Высшим органом СИСПР является Пленарная ассамблея, собираемая раз в 3 года.

).
Члены рабочей группы 10 Технического комитета 57 «Управление электроэнергетическими системами и сопутствующие технологии обмена информацией» МЭК, занимающейся разработкой стандарта, Алексей Олегович Аношин и Александр Валерьевич Головин сегодня рассматривают основной протокол обмена сигналами - GOOSE.

СТАНДАРТ МЭК 61850
Протокол GOOSE

Протокол GOOSE, описанный главой МЭК 61850-8-1, является одним из наиболее широко известных протоколов, предусмотренных стандартом МЭК 61850. Дословно расшифровку аббревиатуры GOOSE - Generic Object-Oriented Substation Event - можно перевести как «общее объектно-ориентированное событие на подстанции». Однако на практике не стоит придавать большое значение оригинальному названию, поскольку оно не дает никакого представления о самом протоколе. Гораздо удобнее понимать протокол GOOSE как сервис, предназначенный для обмена сигналами между РЗА в цифровом виде.

ФОРМИРОВАНИЕ GOOSE-СООБЩЕНИЙ

В предыдущей публикации мы рассмотрели информационную модель устройства, организацию данных и остановились на формировании наборов данных - Dataset. Наборы данных используются для группировки данных, которые будут отправлять с использованием механизма GOOSE-сообщения. В дальнейшем в блоке управления отправкой GOOSE указывается ссылка на созданный набор данных. В таком случае устройство знает, какие именно данные отправлять (рис. 1).

Рис. 1. Формирование данных для GOOSE-сообщения

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

Передаваемый пакет GOOSE-сообщения содержит все текущие значения атрибутов данных, внесенных в набор данных. При изменении какого-либо из значений атрибутов устройство моментально инициирует посылку нового GOOSE-сообщения с обновленными данными (рис. 2).

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

По своему назначению GOOSE-сообщение призвано заменить передачу дискретных сигналов по сети оперативного тока. Рассмотрим, какие требования при этом предъявляются к протоколу передачи данных.

ЦИФРОВЫЕ КОММУНИКАЦИИ ВЗАМЕН АНАЛОГОВЫХ

Для разработки альтернативы цепям передачи сигналов между устройствами релейной защиты были проанализированы свойства информации, передаваемой между устройствами РЗА посредством дискретных сигналов:

Малый объем информации: между терминалами фактически передаются значения «истина» и «ложь» (или логический «ноль» и «единица»);
- Требуется высокая скорость передачи информации. Больша´я часть дискретных сигналов, передаваемых между устройствами РЗА, прямо или косвенно влияет на скорость ликвидации ненормального режима, поэтому передача сигнала должна осуществляться с минимальной задержкой;
- Требуется высокая вероятность доставки сообщения для реализации ответственных функций, таких как подача команды отключения выключателя от РЗА, обмен сигналами между РЗА при выполнении распределенных функций. Необходимо обеспечение гарантированной доставки сообщения как в нормальном режиме работы цифровой сети передачи данных, так и в случае ее кратковременных сбоев;
- Возможность передачи сообщений сразу нескольким адресатам. При реализации некоторых распределенных функций РЗА требуется передача данных от одного устройства сразу нескольким;
- Необходим контроль целостности канала передачи данных. Наличие функции диагностики состояния канала передачи данных позволяет повысить коэффициент готовности при передаче сигнала, тем самым повышая надежность функции, выполняемой с передачей указанного сообщения.

Перечисленные требования привели к разработке механизма GOOSE-сообщений, отвечающих всем предъявляемым требованиям.

ОБЕСПЕЧЕНИЕ СКОРОСТИ ПЕРЕДАЧИ ДАННЫХ

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

Аналогично в цифровых сетях передачи данных основную задержку вносит не столько передача сигнала по физической среде, сколько его обработка внутри устройства.

В теории сетей передачи данных принято сегментировать сервисы передачи данных в соответствии с уровнями модели OSI (табл. 1), как правило, спускаясь от «Прикладного», то есть уровня прикладного представления данных, к «Физическому», то есть к уровню физического взаимодействия устройств.

Таблица 1. Стандартная семиуровневая модель OSI

Модель OSI
Тип данных	Уровень (layer)	Функции
Данные	7. Прикладной (application)	Доступ к сетевым службам
	6. Представительский (presentation)	Представление и шифрование данных
	5. Сеансовый (session)	Управление сеансом связи
Сегменты	4. Транспортный (transport)	Прямая связь между конечными пунктами и надежность
Пакеты	3. Сетевой (network)	Определение маршрута и логическая адресация
Кадры	2. Канальный (data link)	Физическая адресация
Биты	1. Физический (physical)	Работа со средой передачи, сигналами и двоичными данными

В классическом представлении модель 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, по сравнению с остальными данными, передаваемыми по той же сети с использованием других протоколов, тем самым сводя к минимуму задержки как при обработке данных внутри устройств источников и приемников данных, так и при обработке их сетевыми коммутаторами.

ОТПРАВКА ИНФОРМАЦИИ НЕСКОЛЬКИМ АДРЕСАТАМ

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

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

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

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

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

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

ГАРАНТИРОВАННАЯ ДОСТАВКА СООБЩЕНИЙ И КОНТРОЛЬ СОСТОЯНИЯ КАНАЛА

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

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

Во-первых, в условиях отсутствия изменений в передаваемых атрибутах данных пакеты с GOOSE-сообщениями передаются циклически через установленный пользователем интервал (рис. 5а). Циклическая передача GOOSE-сообщений позволяет постоянно диагностировать информационную сеть. Устройство, настроенное на прием сообщения, ожидает его прихода через заданный интервал времени. В случае если сообщение не пришло в течение времени ожидания, принимающее устройство может сформировать сигнал о неисправности в информационной сети, оповещая диспетчера о возникших неполадках.

Во-вторых, при изменении одного из атрибутов передаваемого набора данных, вне зависимости от того, сколько времени прошло с момента отправки предыдущего сообщения, формируется новый пакет, который содержит обновленные данные. После чего отправка этого пакета повторяется несколько раз с минимальной выдержкой времени (рис. 5б), а интервал между сообщениями (в случае отсутствия изменений в передаваемых данных) вновь увеличивается до максимального.

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

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

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

Следует иметь в виду, что некоторые из заложенных механизмов обеспечения надежности передачи данных при их неправильном использовании могут приводить к негативному эффекту. Так, в случае выбора слишком короткого максимального интервала между сообщениями нагрузка на сеть увеличивается, хотя с точки зрения готовности канала связи эффект от уменьшения интервала передачи будет крайне незначительным.

При изменении атрибутов данных передача пакетов с минимальной выдержкой времени вызывает повышенную нагрузку на сеть (режим «информационного шторма»), которая теоретически может приводить к возникновению задержек при передаче данных. Такой режим является наиболее сложным и должен приниматься за расчетный при проектировании информационной сети. Однако следует понимать, что пиковая нагрузка очень кратковременна и ее многократное снижение, согласно проводившимся нами опытам в лаборатории по исследованию функциональной совместимости устройств, работающих по условиям стандарта МЭК 61850, кафедры РЗиАЭС НИУ МЭИ, наблюдается на интервале в 10 мс.

НАЛАДКА И ПРОВЕРКА

При построении систем РЗА на основе протокола GOOSE изменяются процедуры их наладки и тестирования. Теперь этап наладки заключается в организации сети Ethernet энергообъекта с включением в нее всех устройств РЗА, между которыми требуется осуществлять обмен данными. Для проверки того, что система настроена и включена в соответствии с требованиями проекта, становится возможным использование персонального компьютера со специальным предустановленным программным обеспечением (Wireshark, GOOSE Monitor и др.) или специального проверочного оборудования с поддержкой протокола GOOSE (РЕТОМ 61850, Omicron CMC).

Важно отметить, что все проверки можно производить, не нарушая предварительно установленные соединения между вторичным оборудованием (устройствами РЗА, коммутаторами и др.), поскольку обмен данными производится по сети Ethernet. При обмене дискретными сигналами между устройствами РЗА традиционным способом (подачей напряжения на дискретный вход устройства-приемника при замыкании выходного контакта устройства, передающего данные), напротив, часто требуется разрывать соединения между вторичным оборудованием для включения в цепь испытательных установок с целью проверки правильности электрических соединений и передачи соответствующих дискретных сигналов.

ВЫВОДЫ

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

ЛИТЕРАТУРА

1. Аношин А.О., Головин А.В. Стандарт МЭК 61850. Информационная модель устройства // Новости ЭлектроТехники. 2012. № 5(77).
2. Информационно-вычислительные сети: учебное пособие. Капустин Д.А., Дементьев В.Е. Ульяновск: УлГТУ, 2011.- 141 с.

Основной набор глав стандарта МЭК 61850 первой редакции был опубликован в 2002 – 2003 г.г. Позднее в 2003 – 2005 г.г. были опубликованы остальные главы первой редакции. Всего первая редакция насчитывала 14 документов. Позднее часть глав была переработана и дополнена, а также в стандарт были добавлены некоторые документы. Текущая редакция стандарта состоит уже из 19 документов, список которых приведен ниже.

• IEC/TR 61850-1 ed1.0
• IEC/TS 61850-2 ed1.0
• IEC 61850-3 ed1.0
• IEC 61850-4 ed2.0
• IEC 61850-5 ed1.0
• IEC 61850-6 ed2.0
• IEC 61850-7-1 ed2.0
• IEC 61850-7-2 ed2.0
• IEC 61850-7-3 ed2.0
• IEC 61850-7-4 ed2.0
• IEC 61850-7-410 ed1.0
• IEC 61850-7-420 ed1.0
• IEC/TR 61850-7-510 ed1.0
• IEC 61850-8-1 ed2.0
• IEC 61850-9-2 ed2.0
• IEC 61850-10 ed1.0
• IEC/TS 61850-80-1 ed1.0
• IEC/TR 61850-90-1 ed1.0
• IEC/TR 61850-90-5 ed1.0

Рассмотрим подробнее структуру стандарта и входящих в него документов. Но прежде всего определим терминологию, в соответствии с которой обозначаются документы.

Виды документов МЭК

В Международной электротехнической комиссии различают следующие виды документов:

• International Standard (IS) – Международный стандарт
• Technical Specification (TS) – Технические требования
• Technical Report (TR) – Технический отчёт

Международный стандарт (IS)

Международным стандартом является стандарт, официально принятый Международной организацией по стандартизации и официально опубликованный. Определение, данное во всех документах МЭК гласит «Нормативный документ, разработанный в соответствии с процедурами согласования, который был принят членами национальных комитетов МЭК ответственного технического комитета в соответствии с Главой 1 Директив ИСО/МЭК .

Существует два условия для принятия международного стандарта:

1. Две трети действующих членов технического комитета или подкомитета голосуют за принятие стандарта
2. Против принятия стандарта подано не более одной четверти от всего количества голосов.

Технические требования (TS)

Технические требования часто публикуются в тех случаях, когда стандарт находится в разработке или когда для официального принятия международного стандарта не достигнуто необходимое согласие.

Технические требования приближаются к Международному стандарту в части детализации и полноты, но ещё не прошли через все стадии утверждения из-за того, что не было достигнуто согласие, или потому что стандартизация сочтена преждевременной.

Технические требования схожи с Международным стандартом и являются нормативным документом, разрабатываемым в соответствии с процедурами согласования. Технические требования утверждаются двумя третями голосов действующих членом Технического комитета или Подкомитета МЭК.

Технический отчёт (TR)

Технический отчёт содержит информацию отличающуюся от той, что обычно публикуется в международных стандартах, например, данные, полученные из исследований, проведённых среди национальных комитетов, результаты работы других международных организаций или данные по передовым технологиям, полученные от национальных комитетов и имеющие отношение к предмету стандарта.

Технические отчёты носят чисто информативный характер и не выступают нормативными документами.

Утверждение технического отчёта производится простым большинством голосов действующих членом технического комитета или подкомитета МЭК.

Опубликованные главы стандарта МЭК 61850

Рассмотрим содержание глав стандарта по порядку, а также разрабатываемые документы.

IEC/TR 61850-1 ред. 1.0 Введение и общие положения

Первая глава стандарта выпущена в виде технического отчёта и служит введением в серию стандартов МЭК 61850. В главе описаны базовые принципы, положенные в основу системы автоматизации, работающей в соответствии с МЭК 61850. Первой главой стандарта определена трёхуровневая архитектура системы автоматизации, включающая уровень процесса, уровень присоединения и уровень станции. Изначально стандартом была определена лишь система автоматизации в рамках одного объекта и связи между несколькими ПС не были включены в модель. Позднее модель была расширена и на рис. 1 представлена архитектура системы связи, описанная второй редакцией стандарта, где предусмотрены также связи между подстанциями (см. рис. 1). Внутри каждого из уровней, а также между уровнями описана структура информационного обмена.

Рис. 1. Архитектура системы связи.

Перечень интерфейсов и их назначение также приведены в первой главе стандарта и описаны в таблице 1.

Таблица 1 – Определения интерфейсов

№	Интерфейс
1	Обмен сигналами функций защиты между уровнями присоединения и станции
2	Обмен сигналами функций защиты между уровнем присоединения одного объекта и уровнем присоединения смежного объекта
3	Обмен данными в в рамках уровня присоединения
4	Передача мгновенных значений тока и напряжения от измерительных преобразователей (уровень процесса) устройствам уровня присоединения
5	Обмен сигналами функций управления оборудованием уровня процесса и уровня присоединения
6	Обмен сигналами функций управления между уровнем присоединения и уровнем станции
7	Обмен данными между уровнем станции и удаленным рабочим местом инженера
8	Прямой обмен данными между присоединениями, в частности, для реализации быстродействующих функций, таких как оперативная блокировка
9	Обмен данными в рамках уровня станции
10	Обмен сигналами функций управления между уровнем станции и удаленным диспетчерским центром
11	Обмен сигналами функций управления между уровнями присоединения двух различных объектов, например, дискретными сигналами для реализации оперативной блокировки или другой автоматики

Кроме того, в первой главе МЭК 61850 впервые описаны:

• концепция моделирования данных;
• концепция наименования данных с представлением логических узлов, объектов и атрибутов данных;
• набор абстрактных коммуникационных сервисов;
• язык описания конфигурации системы (System Configuration description Language).

Описание вышеобозначенного представлено в достаточно сжатом виде и в первой главе предназначено лишь для ознакомительных целей.

IEC/TS 61850-2 ред. 1.0 Термины и определения

Вторая глава стандарта содержит глоссарий терминов, сокращений и аббревиатур, используемых в контексте автоматизации подстанций в серии стандартов МЭК 61850. Глава утверждена в формате Технических требований.

IEC 61850-3 ред. 1.0 Общие требования

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

Основная часть требований дана в форме ссылок на стандарт МЭК 60870-2, -4 и МЭК 61000-4.

Следует отметить, что одним из требований стандарта, например, является декларация производителем математического ожидания наработки до отказа (MTTF), а также описание методики, в соответствии с которой она рассчитана. Знание этого важного параметра позволит производить расчёт наработки отказа системы в целом.

IEC 61850-4 ред. 2.0 Системный инжиниринг и управление проектами

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

Документ также описывает базовые принципы выполнения проекта, наладки и испытаний. Кроме того, дана концепция распределения различных функций между программными и аппаратными инструментами. Более подробная информация по этой части дана в шестой главе.

IEC 61850-5 ред. 1.0 Требования к функциям и устройствам в части передачи данны х

Пятая глава стандарта детализирует концептуальные принципы разделения системы автоматизации на уровни, описанные в первой главе, а также даёт описание концепции использования логических узлов,предлагает их классификацию в соответствии с функциональным назначением Кроме того, в главе приведены примеры схем взаимодействия различных логических узлов при реализации ряда функций РЗА.

Здесь же упоминаются термины «функциональная совместимость» и «взаимозаменяемость». При этом сделан акцент на том, что стандарт не предполагает обеспечение взаимозаменяемости устройств, его назначение – обеспечить функциональную совместимость устройств. Эти два понятия часто путают при обсуждении стандарта МЭК 61850.

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

Стандарт нормирует полное время передачи сигнала, которое складывается из трёх составляющих:

• время кодирования поступившего от внутренней функции сигнала коммуникационным интерфейсом,
• время передачи сигнала по сети связи,
• время декодирования поступивших из сети связи данных и их передачи в функцию другого устройства.

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

Следует также отметить, что во второй редакции пятой главы, официальная публикация которой намечена на осень 2012, введена новая система классов производительности. Однако фактически требования к допустимым задержкам при передаче сигналов определенных видов не изменились.

IEC 61850-6 ред. 2.0 Язык описания конфигурации для обмена данными

Шестая глава стандарта описывает формат файлов для описания конфигураций устройств, задействованных в обмене данными по МЭК 61850. Главная задача общего формата обеспечить возможность конфигурирования устройства внешним программным обеспечением.

Указанный формат файлов описания известен как язык конфигурирования подстанций (SCL) и базируется на общепринятом в IT-среде языке разметки XML.

С целью определения чётких правил формирования файлов формата SCL, а также простоты проверки правильности их составления, была разработана XSD-схема, которая также описана в главе 6 и является неотъемлемой частью стандарта МЭК 61850.

Первоначальная версия схемы была опубликована вместе с первой редакцией главы 6 в 2007 году. Позднее схема претерпела ряд изменений, связанных, в частности, с исправлением ошибок и рядом дополнений в SCL-файлах, и в 2009 году была опубликована её новая редакция.

Таким образом, сейчас действуют две редакции схемы: 2007 и 2009 года, обычно именуемые как «первая» и «вторая» редакции. Несмотря на существующие между ними различия, предполагается, что устройства, совместимые со «второй редакцией» должны иметь обратную совместимость и с устройствами «первой редакции». На практике это происходит, к сожалению, не всегда. Тем не менее, это не мешает реализовать связь между устройствами, задавая каждому конфигурацию при помощи ПО производителя.

IEC 61850-7 Базовая структура коммуникаций

Стандарт МЭК 61850 определяет не только протоколы передачи данных, но и семантику, которой эти данные описаны. Седьмой раздел стандарта описывает подходы к моделированию систем и данных в виде классов. Все, входящие в седьмой раздел части взаимосвязаны между собой, а также с главами 5, 6, 8 и 9.

IEC 61850-7-1 ред. 2.0 Базовая структура коммуникаций – Принципы и модели

В разделе 7-1 стандарта введены базовые методы моделирования систем и данных, представлены принципы организации передачи данных и информационные модели, используемые в других частях МЭК 61850-7.

В данной главе описан принцип представления физического устройства со всеми имеющимися в нём функциями в виде набора логических устройств, состоящих, в свою очередь, из набора логических узлов. Также описана технология группировки данных в наборы данных с последующим назначением этих данных на коммуникационные сервисы.

В данной главе также дано описание принципов передачи данных, осуществляющихся по технологии «клиент-сервер» или «издатель-подписчик». Однако следует отметить, что данная глава, так же как и весь раздел 7 описывает лишь принципы и не описывает назначения сигналов на конкретные протоколы связи.

IEC 61850-7-2 ред. 2.0 Базовая структура коммуникаций – Абстрактный интерфейс коммуникаций (ACSI)

Глава 7-2 описывает так называемый «абстрактный коммуникационный интерфейс» для систем автоматизации электроэнергетических объектов.

В главе дано описание схемы классов и сервисов передачи данных. Концептуальная схема связей классов приведена на рис. 2. Подробнее описание этой схемы будет дано в одной из будущих публикаций в рамках рубрики.

Рис. 2. Схема связей классов.

В главе дано подробное описание свойств каждого из классов, а в разделе сервисов передачи данных представлена связь указанных классов с возможными сервисами, таким как отчёты, журналы событий, чтение/запись данных или файлов, многоадресная рассылка и передача мгновенных значений.

Таким образом главой в абстрактном виде подробно описана вся структура коммуникаций, начиная от описания самих данных, как класса, и заканчивая сервисами для их передачи. Однако, как уже сказано выше, всё это описание дано лишь в абстрактной форме.

IEC 61850-7-3 ред. 2.0 Основная структура коммуникаций – Общие классы данных

Как видно из рис. 2, каждый класс данных (DATA) включает в себя один или более атрибутов данных (DataAttribute). Каждый атрибут данных, в свою очередь, описан определенным классом атрибута данных. В главе 7-3 описаны все возможные классы данных и классы атрибутов данных.

Классы данных включают несколько групп:

• Классы для описания информации о состоянии
• Классы для описания измеренных значений
• Классы для управляющих сигналов
• Классы для дискретных параметров
• Классы для непрерывных параметров
• Классы для описательных данных

Описанные классы позволяют моделировать всевозможные данные в рамках системы автоматизации ПС с целью дальнейшего обмена этими данными между устройствами и системами.

По сравнению с первой главой, во второй были учтены корректировки в соответствии с Tissues , кроме того, были добавлены новые классы данных и атрибутов, потребовавшиеся в новых информационных моделях, построенных в соответствии с требованиями стандарта и использующимся за рамками систем автоматизации подстанций.

IEC 61850-7-4 ред. 2.0 Основная структура коммуникаций – Классы логических узлов и объектов данных

Настоящая глава стандарта описывает информационную модель устройств и функций, относящихся к подстанциям. В частности, она определяет имена логических узлов и данных для передачи данных между устройствами, а также определят взаимосвязь логических узлов и данных.

Имена логических узлов и данных, определенные главой 7-4, являются частью модели классов, предложенной в главе 7-1 и определенной главой 7-2. Имена, определенные в данном документе, используются для построения иерархических ссылок на объекты с целью дальнейшего обращения к данным при коммуникациях. В данной главе также применяются правила формирования имён, определённые главой 7-2.

Все классы логических узлов имеют наименования, состоящие из четырёх букв, причём первая буква в названии класса логического узла указывает на группу, к которой он относится (см. Табл. 3).

Таблица 3 – Перечень групп логических узлов

Указатель группы	Наименование группы
A	Автоматическое управление
B	Зарезервировано
C	Диспетчерское управление
D	Распределенные источники энергии
E	Зарезервировано
F	Функциональные блоки
G	Общие функции
H	Гидроэнергетика
I	Интерфейсы и архивирование
J	Зарезервировано
K	Механическое и неэлектрическое оборудование
L	Системные логические узлы
M	Учёт и измерения
N	Зарезервировано
O	Зарезервировано
P	Функции защиты
Q	Контроль качества электрической энергии
R	Функции защиты
S*	Диспетчерское управление и мониторинг
T*	Измерительные трансформаторы и датчики
U	Зарезервировано
V	Зарезервировано
W	Ветроэнергетика
X*	Коммутационные аппараты
Y*	Силовые трансформаторы и связанные функции
Z*	Иное электротехническое оборудование
* Логические узлы этих групп существуют в выделенных ИЭУ при условии что используется шина процесса. Если шина процесса не используются, то указанные логические узлы соответствуют модулям ввода/вывода и расположены в ИЭУ, подключенном медными связями к оборудованию и расположенном уровнем выше (например, на уровне присоединения) и представляют внешнее устройство по его входам и выходам (проекция процесса).

IEC 61850-7-410, -420 и -510

Стандарты МЭК 61850-7-410 и -420 являются расширениями главы 7-2 и содержат описания классов логических узлов и данных для гидроэлектростанций и малой генерации генерации.

Технический отчёт IEC/TR 61850-7-510 даёт пояснения по использованию логических узлов, определенных в главе 7-410, а также в других документах серии МЭК 61850, для моделирования комплексных функций управления на электрических станциях, включая гидроаккумулирующие станции с изменяемой скоростью.

IEC 61850-8-1 ред. 2.0 Назначение на определенный коммуникационный сервис – Назначение на MMS и IEC 8802-3

Как отмечалось выше, раздел 7 стандарта описывает только принципиальные механизмы передачи данных. Глава 8-1, в свою очередь, описывает методы обмена информацией по локальным сетям путём назначения абстрактных коммуникационных сервисов (ACSI) на протокол MMS и кадры ISO/IEC 8802-3.

Глава 8-1 описывает протоколы как для обмена данными, для которых критична временная задержка, так и данными, где задержка не критична.

Сервисы и протокол MMS работают на полной модели OSI поверх стека TCP, за счёт чего передача данных по этому протоколу осуществляется с относительно большими временными задержками, поэтому использование протокола MMS позволяет решать задачи по передаче данных, для которых не критична задержка. Например, этот протокол может использоваться для передачи команд телеуправления, сбора данных телеизмерений и телесигнализации, а также для отправки отчётов и журналов с удалённых устройств.

Помимо протокола MMS глава 8-1 описывает назначение данных, требующих быстрой передачи данных. Семантика этого протокола определена в МЭК 61850-7-2. Глава 8-1 описывает синтаксис протокола, определяет назначение данных кадры ИСО/МЭК 8802-3, а также определяет процедуры, относящиеся к использованию ИСО/МЭК 8802-3. Указанный протокол известен специалистам как протокол GOOSE. За счёт того, что данные в этом протоколе назначаются непосредственно в кадр Ethernet, минуя модель OSI и в обход стека TCP, передача данных в нём осуществляется с заметно меньшими задержками, по сравнению с MMS. Благодаря этому GOOSE может использоваться для передачи команд отключения выключателя от защиты и аналогичных быстрых сигналов.

IEC 61850-9-1 ред. 1.0 Назначение на определенный коммуникационный сервис – Передача мгновенных значений по последовательному интерфейсу

Данная глава описывала методы передачи мгновенных значений путем назначения данных на последовательный интерфейс по МЭК 60044-8. Однако в 2012 году указанная глава была исключена из серии стандартов МЭК 61850 и более не поддерживается.

IEC 61850-9-2 ред. 2.0 Назначение на определенный коммуникационный сервис – Передача мгновенных значений по интерфейсу IEC 8802-3

Глава 9-2 стандарта МЭК 61850 описывает методы передачи мгновенных значений от ТТ и ТН по интерфейсу IEC 8802-3, то есть определят назначение класса сервиса передачи мгновенных значений от измерительных ТТ и ТН МЭК 61850-7-2 на протокол ISO/IEC 8802-3.

Данная глава стандарта распространяется на измерительные трансформаторы тока и напряжения с цифровым интерфейсом, устройства сопряжения с шиной процесса и ИЭУ с возможностью приёма данных от ТТ и ТН в цифровом виде.

Фактически данная глава описывает формат кадра Ethernet в зависимости от того, какие данные на него назначены, то есть определят его взаимосвязь с классом данным согласно МЭК 61850-7-2 и описанием согласно МЭК 61850-6.

Первой редакцией главы 9-2 не были предусмотрены такие важные моменты, как обеспечение резервирования. Во второй редакции были учтены эти недостатки, в связи с чем формат кадра 9-2 был дополнен полями для меток протоколов резервирования PRP или HSR.

Спецификация IEC 61850-9-2LE

Первая редакция стандарта МЭК 61850-9-2 была опубликована в 2004 году, однако отсутствие в ней чётко прописанных требований по частотам выборок мгновенных значений и составу передаваемого пакета могло привести к потенциальной несовместимости решений разных производителей. Для того, чтобы способствовать развитию совместимых решений на базе протокола МЭК 61850-9-2 группой пользователе UCA в дополнение к стандарту была также разработана спецификация (получившая наименование «9-2LE»), которая конкретизировала состав передаваемого пакета данных, определила две стандартные частоты: 80 и 256 выборок за период промышленной частоты, то есть фактически установила стандартные требования к интерфейсу МЭК 61850-9-2 для всех устройств.

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

IEC 61850-10 ред. 1.0 Проверка соответствия

Десятая глава стандарта определяет процедуры испытаний соответствия устройств и программного обеспечения требованиям стандарта и спецификаций.

В частности, глава определяет методику проверки соответствия фактических задержек при формировании и обработке пакетов сообщений заявленным параметрам и требованиям стандарта.

IEC/TS 61850-80-1 ред. 1.0 Руководство по передаче информации из модели общих классов данных с использованием МЭК 60870-5-101 или МЭК 60870-5-104

Документ описывает назначение общих классов данных МЭК 61850 на протоколы МЭК 60870-5-101 и -104.

IEC/TR 61850-90-1 ред. 1.0 Использование МЭК 61850 для организации связи между подстанциями

Изначально стандарт МЭК 61850 был рассчитан на обеспечение передачи данных между устройствами лишь в рамках подстанции. Впоследствии предложенная концепция нашла применение и в других системах в электроэнергетике. Таким образом стандарт МЭК 61850 может стать основой для глобальной стандартизации сетей передачи данных.

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

Стандарт МЭК 61850 представляет базовые инструменты, однако для стандартизации протоколов передачи между объектами требуется ряд изменений. Технический отчёт 90-1 содержит обзор различных аспектов, которые должны быть приняты во внимание при использовании МЭК 61850 для обмена данными между ПС. Области, в которых требуется расширение существующих документов стандарта позднее будут включены в актуальные версии глав стандарта.

Одним из примеров необходимого расширения может служить передача GOOSE-сообщений между объектами. На сегодняшний день GOOSE-сообщения могут передаваться только в режиме широковещательной рассылки всем устройствам, включенным в локальную сеть, однако они не могут проходить через сетевые шлюзы. В главе 90-1 описаны принципы организации туннелей для передачи GOOSE-сообщений между разными локальными сетями объектов.

IEC/TR 61850-90-5 ред. 1.0 Использование МЭК 61850 для передачи данных от устройств синхронизированных векторных измерений в соответствии с IEEE C37.118

Основная цель технического отчёта 90-5 состояла в том, чтобы предложить метод передачи синхронизированных векторных измерений между PMU и системой СМПР. Данные, описанные стандартом IEEE C37.118-2005 передаются в соответствии с технологиями, предусмотренными МЭК 61850.

Однако помимо изначально поставленных задач данный отчёт также представляет профили для маршрутизации пакетов GOOSE (МЭК 61850-8-1) и SV (МЭК 61850-9-2).

Разрабатываемые документы МЭК 61850

Помимо рассмотренных документов в настоящее время рабочей группой 10, а также смежными рабочими группами разрабатываются ещё 21 документ, которые войдут в состав серии стандартов МЭК 61850.

Большая часть указанных документов будет опубликована в форме технических отчётов:

• IEC/TR 61850-7-5. Использование информационных моделей систем автоматизации подстанций.
• IEC/TR 61850-7-500. Использование логических узлов для моделирования функций систем автоматизации подстанций.
• IEC/TR 61850-7-520. Использование логических узлов объектов малой генерации.
• IEC/TR 61850-8-2. Назначение на веб-сервисы.
• IEC/TR 61850-10-2. Испытания на функциональную совместимость оборудования гидроэлектростанций.
• IEC/TR 61850-90-2. Использование стандарта МЭК 61850 для организации связи между подстанциями и центрами управления.
• IEC/TR 61850-90-3. Использование МЭК 61850 в системах мониторинга состояния оборудования.
• IEC/TR 61850-90-4. Руководящие указания по инжинирингу систем связи на подстанциях.
• IEC/TR 61850-90-6. Использование МЭК 61850 для автоматизации распределительных сетей.
• IEC/TR 61850-90-7. Объектные модели для электростанций на базе фотоэлементов, аккумуляторов и других объектов с использованием инверторов.
• IEC/TR 61850-90-8. Объектные модели для электромобилей.
• IEC/TR 61850-90-9. Объектные модели для батарей.
• IEC/TR 61850-90-10. Объектные модели для систем планирования режимов работы объектов малой генерации.
• IEC/TR 61850-90-11 Моделирование свободно программируемой логики.
• IEC/TR 61850-90-12. Руководящие указания по инжинирингу распределенных сетей связи.
• IEC/TR 61850-90-13. Расширение состава логических узлов и объектов данных для моделирования оборудования газотурбинных и паротурбинных установок.
• IEC/TR 61850-90-14. Использование стандарта МЭК 61850 для моделирования оборудования FACTS.
• IEC/TR 61850-90-15. Иерархическая модель объектов малой генерации.
• IEC/TR 61850-100-1. Функциональное тестирование систем, работающих по условиям стандарта МЭК 61850.

Заключение

Стандарт МЭК 61850, изначально разработанный для применения в рамках систем автоматизации подстанций, постепенно начинает распространяться и на системы автоматизации других объектов энергосистемы, о чем свидетельствует ряд недавно изданных и еще больший ряд готовящихся к публикации документов. Новая техника и новые технологии, развивающиеся «под флагом» интеллектуализации энергосистемы, сопровождаются их описанием в контексте стандарта МЭК 61850, в то время как разработка/модернизация других схожих по назначению стандартов не производится. Указанное позволяет сделать смелое предположение о том, что с каждым годом стандарт будет иметь большее практическое распространение.

Список литературы

1. http://www.iec.ch/members_experts/refdocs/governing.htm
2. http://tissue.iec61850.com
3. Implementation Guidline for Digital Interface to Instrument Transformers Using IEC 61850-9-2. UCA Internation Users Group. Modification Index R2-1. http://iec61850.ucaiug.org/implementation%20guidelines/digif_spec_9-2le_r2-1_040707-cb.pdf

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

Если рассмотреть аллегорию с учебным классом, которая хорошо подходит, то циклические протоколы вроде 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, источник данных был перезагружен, соединение с источником потеряно, запись значения форсирована, значение вне допустимых границ.

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

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

Протокол IEC 61850 MMS

MMS (Manufacturing Message Specification) - протокол передачи данных по технологии «клиент-сервер». Стандарт МЭК 61350 не описывает протокол MMS. Глава МЭК 61850-8-1 описывает лишь порядок назначения сервисов передачи данных, описанных стандартом МЭК 61850, на протокол MMS, описанный стандартом ИСО/МЭК 9506. Для того, чтобы лучше понять, что это означает, необходимо подробнее рассмотреть, каким образом стандарт МЭК 61850 описывает абстрактные коммуникационные сервисы и для чего это сделано.
Одной из основных идей, заложенных в стандарт МЭК 61850, является его неизменность со временем. Для того, чтобы это обеспечить, главы стандарта последовательно описывают сначала концептуальные вопросы передачи данных внутри и между энергообъектами, затем описывается так называемый «абстрактный коммуникационный интерфейс» и лишь на заключительном этапе описывается назначение абстрактных моделей на протоколы передачи данных.

Таким образом, концептуальные вопросы и абстрактные модели оказываются независимыми от используемых технологий передачи данных (проводные, оптические или радиоканалы), поэтому не потребуют пересмотра, вызванного прогрессом в области технологий передачи данных.
Абстрактный коммуникационный интерфейс, описываемый МЭК 61850-7-2. включает в себя как описание моделей устройств (то есть стандартизует понятия «логического устройства», «логического узла», «управляющего блока» и т.п.). так и описание сервисов передачи данных. Один из таких сервисов - SendGOOSEMessage. Помимо указанного сервиса, описывается ещё более 60 сервисов, стандартизирующих процедуру установления связи между клиентом и сервером (Associate, Abort, Release), считывания информационной модели (GetServerDirectory, GelLogicalDeviceDirectory, GetLogicalNodeDirectory), считывание значений переменных (GetAllDataValues, GetDataValues и т.д.), передачу значений переменных в виде отчётов (Report) и другие. Передача данных в перечисленных сервисах осуществляется по технологии «клиент-сервер».

Например, сервером в данном случае может выступать устройство релейной защиты, а клиентом - SCADA-система. Сервисы считывания информационной модели позволяют клиенту считать с устройства полную информационную модель, то есть воссоздать дерево из логических устройств, логических узлов, элементов и атрибутов данных. При этом клиент получит полное семантическое описание данных и их структуру. Сервисы считывания значений переменных позволяют считать фактические значения атрибутов данных, например, методом периодического опроса. Сервис передачи отчётов позволяет настроить отправку определенных данных при выполнении определенных условий. Одним из вариантов такого условия может быть изменение того или иного рода, связанное с одним или несколькими элементами из набора данных. Для реализации описанных абстрактных моделей передачи данных в стандарте МЭК 61850 описано назначение абстрактных моделей на конкретный протокол. Для рассматриваемых сервисов таким протоколом является MMS, описанный стандартом ИСО/МЭК 9506.

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, описанный главой МЭК 61850-8-1, является одним из наиболее широко известных протоколов, предусмотренных стандартом МЭК 61850. Дословно расшифровку аббревиатуры GOOSE - Generic Object-Oriented Substation Event - можно перевести как «общее объектно-ориентированное событие на подстанции». Однако на практике не стоит придавать большого значения оригинальному названию, поскольку оно не даёт никакого представления о самом протоколе. Гораздо удобнее понимать протокол GOOSE как сервис, предназначенный для обмена сигналами между устройствами РЗА в цифровом виде.

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

В модели данных стандарта МЭК 61850 указывается, что данные должны формироваться в наборы - Dataset. Наборы данных используются для группировки данных, которые будут отправляться устройством с использованием механизма GOOSE-сообщения. В дальнейшем, в блоке управления отправкой GOOSE указывается ссылка на созданный набор данных, в таком случае устройство знает, какие именно данные отправлять. Следует отметить, что в рамках одного GOOSE-сообщения может отправляться как одно значение (например, сигнал пуска МТЗ), так и одновременно несколько значений (например, сигнал пуска и сигнал срабатывания МТЗ и т.д.). Устройство-получатель, при этом, может извлечь из пакета лишь те данные, которые ему необходимы. Передаваемый пакет 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-сообщений

Передача сообщений нескольким адресатам в режиме Multicast, а также требования к высокой скорости передачи данных не позволяют реализовать при передаче GOOSE-сообщений получение подтверждений о доставке от получателей. Процедура отправки данных, формирования получающим устройством подтверждения, приём и обработка его устройством отправителем и последующая повторная отправка в случае неудачной попытки заняли бы слишком много времени, что могло бы привести к чрезмерно большим задержкам при передаче критических сигналов. В место этого для 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 предусматривает целый комплекс мер, направленных на обеспечение необходимых характеристик по быстродействию и надёжности при передаче ответственных сигналов. Применение данного протокола в сочетании с правильным проектированием и параметрированием информационной сети и устройств РЗА позволяет в ряде случаев отказаться от использования медных цепей для передачи сигналов, обеспечивая при этом необходимый уровень надёжности и быстродействия.

#MMS, #GOOSE, #SV, #870-104, #событийный, #протокол, #обмен