О важности проведения испытаний на соответствие стандарту МЭК 61850. Мэк 61850 стандарт

61850 - это... Что такое МЭК-61850?

МЭК-61850 — Стандарт «Коммуникационные сети и системы подстанций»

История стандарта МЭК-61850

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

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

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

Каждый производитель строил систему на основе тех протоколов передачи данных, которые он считал наиболее подходящими для решения той или иной задачи. Использовались такие протоколы как 60870-101/103/104, Modbus, DNP3 и т. д. Некоторые из них стали более популярными, некоторые менее, но такое разнообразие решений приводило к отсутствию совместимости и взаимозаменяемости оборудования и усложнению процесса системной интеграции.

История создания МЭК-61850 началась еще в 1980-х годах в США в Детройте. На заводах, собирающих автомобили, были установлены роботы-сборщики, управление которыми производилось по протоколу MMS (англ.) (Manufacturing Message Specification). Использование этого протокола оказалось достаточно успешным и уже в 90-х годах он лег в основу UCA2 (Utility Communication Architecture), который активно применялся в Европе в электроэнергетике.

И наконец, в 2003 году появилась первая редакция стандарта МЭК-61850.

Область применения стандарта МЭК 61850 — системы связи внутри подстанции. Это набор стандартов, в который входят стандарт по одноранговой связи и связи клиент-сервер, стандарт по структуре и конфигурации подстанции, стандарт по методике испытаний, стандарт экологических требований, стандарт проекта. Полный набор стандартов имеет следующие разделы:

Разделы стандарта

EС 61850-1: Введение и общий обзор.

ЕС 61850-2: Глоссарий терминов.
ЕС 61850-3: Основные требования.
ЕС 61850-4: Управление системой и проектированием.
ЕС 61850-5: Требования связи к функциям и моделям устройств.
ЕС 61850-6: Язык описания конфигурации связи между микропроцессорными электронными устройствами подстанций.
ЕС 61850-7: Основная структура связи для оборудования подстанции и питающей линии (4 части).
ЕС 61850-8-1: Описание специфического сервиса связи (SCSM) — Описание передачи данных по протоколу MMS (ИСО/МЭК 9506 — Часть 1 и Часть 2) и по протоколу ИСО/МЭК 8802-3.
ЕС 61850-9-1: Описание специфического сервиса связи (SCSM) — Выборочные значения по последовательному ненаправленному многоточечному каналу передачи данных типа точка-точка.
ЕС 61850-9-2: Описание специфического сервиса связи (SCSM) — Выборочные значения по ИСО/МЭК 8802-3.
ЕС 61850-10: Проверка на совместимость.

Преимущества стандарта

Основным требованием к системе сбора данных в стандарте является обеспечение способности микропроцессорных электронных устройств к обмену технологическими и другими данными. Стандарт предъявляет следующие требования к системе:

Высокоскоростной обмен данными микропроцессорных электронных устройств между собой (одноранговая связь).
Привязка к подстанционной ЛВС.
Высокая надежность.
Гарантированное время доставки.
Функциональная совместимость оборудования различных производителей.
Средства поддержки чтения осциллограмм.
Средства поддержки передачи файлов.
Конфигурирование / автоматическое конфигурирование.
Поддержка функций безопасности.

МЭК 61850 является объектноориентированным протоколом, фокусированным на автоматизацию подстанций, и значительно расширяет возможности предшествующих стандартов МЭК. Из-за сложности программной реализации МЭК 61850, что включает реализацию целого ряда стандартов по передаче данных (MMS ISO 9506, стека протоколов ISO, GOOSE и GSSE), на рынке практически отсутствуют надежные готовые решения, позволяющие принимать данные с устройств, поддерживающих 61850.

Обзор стандарта МЭК-61850

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

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

Согласно этим требованиям, система описывается в понятной и стандартизованной форме. Вся информация о конфигурациях хранится в файлах определенного формата. Это приводит к тому, что разработка систем на базе 61850 проста и понятна.

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

Значительная часть стандарта посвящена протоколам передачи данных — MMS и GOOSE.

Передача данных в системах на базе МЭК-61850

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

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

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

Основными протоколами передачи данных, согласно стандарту МЭК-61850, являются протоколы MMS и GOOSE.

MMS используется для передачи данных от терминалов РЗА в SCADA систему для дальнейшей визуализации, а GOOSE — для обмена данными между терминалами.

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

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

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

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

Обслуживание таких систем по сравнению со стандартными в целом проще, хоть и предъявляет несколько иные требования к опыту персонала.

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

Еще одним недостатком систем, построенных на 61850, является повышенная стоимость микропроцессорного оборудования РЗА, однако, нужно помнить, что применение 61850 дает ряд преимуществ, именно поэтому, количество подстанций по всему миру, построенных на основе 61850, увеличивается.

Сбор данных с аппаратуры РЗА

В настоящий момент все основные производители аппаратуры РЗА (ABB, SIEMENS, ALSTOM, GE, SEL, ЭКРА, ИЦ "Бреслер", "Прософт-Системы") поддерживают 61850. Российские компании также не отстают от западных производителей и внедряют поддержку 61850 в производимую ими аппаратуру РЗА. Каждый производитель оборудования предлагает свои собственные решения по сбору и обработке данных. Однако большое количество системных интеграторов предпочитает использовать независимые SCADA системы.

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

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

Каждый из этих вариантов (использование решений от производителя и применение независимых решений) имеет свои достоинства и недостатки.

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

Так, например, если в систему построенную целиком на SIEMENS (включая программное обеспечение верхнего уровня) добавить терминал от ABB, то скорее всего технические специалисты столкнутся с определенными трудностями при интеграции этого терминала в SCADA.

Независимые поставщики программных решений обычно поддерживают оборудование различных производителей именно за счет 100 % поддержки 61850 с учетом специфической реализации протоколов стандарта у каждого производителя аппаратуры.

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

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

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

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

Ссылки

dic.academic.ru

О важности проведения испытаний на соответствие стандарту МЭК 61850

Такая проверка, будучи проведенной единожды, в перспективе позволит избежать:

Затягивания этапа наладки оборудования на объекте до полного устранения недочетов реализации МЭК 61850.
Необходимости пересмотра проектных решений в части информационного обмена между устройствами РЗА и в части их интеграции в АСУ ТП или отклонение от проектных решений в этой части.
Задержек сдачи объектов в эксплуатацию.

Приведем несколько примеров несоответствия деклараций производителя требованиям стандарта МЭК 61850, выявленных в ходе наладки реальных устройств и систем на энергообъектах. Срок устранения несоответствий, в зависимости от производителя, изменялся от одной недели до нескольких месяцев. Некоторые «наиболее ответственные» производители, будучи информированными о несоответствиях более полугода назад, до сих пор не заявили об обновлении базового программного обеспечения (ПО) своих изделий.

Итак, подборка всего лишь нескольких несоответствий:

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

Неверно определены типы данных для объектов управляющего блока

При передаче отчетов сервером (устройством РЗА) не производится изменение значения параметра EntryID, что приводит к невозможности выполнения ресинхронизации данных после потери связи между клиентом и сервером.

При передаче отчетов не изменяется значение EntryID

Для параметров BufTm и IntgPd управляющих блоков передачей отчетов при разработке неверно определен тип данных (INT8U вместо INT32U), что ограничивает предельное значение для этих параметров 255 мс. Становится невозможной агрегация событий в один отчет на интервале одного часа (стандарт МЭК 61850 регламентирует минимальное значение BufTm равное 3600000 мс, т.е. одному часу) и нецелесообразным становится использование функции периодической отправки данных сервером в адрес клиента.

Неверно определен тип данных для параметров BufTm и IntgPd

Неверный формат опционального поля reason-for-inclusion (причина включения объекта или атрибута данных в отчет), передаваемого в рамках отчета (битовая строка из 5 вместо 6 бит). Указанное может приводить к нарушению функциональной совместимости между клиентом и сервером.

Неверно определен формат поля reason-for-inclusion

Неправильное описание атрибутов данных в объектной модели устройства и в его файле ICD, приводящее к невозможности выполнения интеграции устройства РЗА в клиентские системы иного производителя, поддерживающие МЭК 61850.

Проверка соответствия устройств и систем требованиям стандарта МЭК 61850 сводится к проверке правильности реализации производителем:

коммуникационных сервисов, предусмотренных стандартом МЭК 61850;
объектной модели устройства и соответствующего ей файла ICD.

Стандарт МЭК 61850, предполагая необходимость проведения таких испытаний, описывает программу испытаний в главе 10. На сегодняшний день, выпущены первая [1] и вторая [2] редакции этой главы.

В связи с тем, что число проверок согласно МЭК 61850-10 достаточно велико, мировой опыт [3] говорит о необходимости использования специальных программно-аппаратных комплексов для проведения испытаний на соответствие требованиям стандарта МЭК 61850, которые в дальнейшем могут быть использованы для автоматизации процедур проверки соответствия и исключения ошибок, обусловленных влиянием человеческого фактора. В ходе тестирования такие комплексы производят передачу определенной последовательности тестовых сообщений в адрес испытуемого устройства и регистрируют ответы последнего. Для испытуемого устройства испытательная система представляет собой набор устройств, включенных с ним в одну локальную сеть и обменивающихся с ним данными. К примеру, если испытуемое устройство является сервером (например, устройством РЗА), то испытательная система выступает в роли комбинации клиентских систем (SCADA, OPC и др.) и других серверов (устройств РЗА).

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

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

Обладать способностью передачи сообщений, не соответствующих требованиям стандарта, и некорректной последовательности сообщений для проверки правильности реакции на них испытуемых устройств.

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

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

Считывать информационную модель устройства посредством коммуникационного протокола, сверять ее с информационной моделью, загруженной в формате SCL (System Configuration Language), а также с требованиями применимых стандартов.

МЭК 61850

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

PICS (Protocol Implementation Conformance Statement). В данном документе отражается полный перечень коммуникационных сервисов, поддерживаемых испытуемым устройством или системой.
MICS (Model Implementation Conformance Statement). В данном документе отражается состав объектной модели, реализованной в испытуемом устройстве.
TICS (Tissue Implementation Conformance Statement). В данном документе приводится перечень утвержденных недочетов стандарта МЭК 61850 и отражается факт их учета в испытуемом устройстве.

В дополнение к документам PICS/MICS производитель также предоставляет документ PIXIT (Protocol Implementation eXtra Information for Testing). В данном документе отражаются специфические характеристики коммуникационных возможностей испытуемого устройства, требования к которым стандартом не предъявляются, но информация о которых может быть полезна инженеру-испытателю в ходе проведения опытов.

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

На сегодняшний день ОАО «НТЦ ФСК ЕЭС» совместно с ООО «ТЕКВЕЛ» предлагает производителям пройти испытания на соответствие разработанных ими устройств и систем требованиям стандарта МЭК 61850. Испытательный стенд проверки соответствия оснащен специальным программным обеспечением iTest. Набор реализуемых в iTest сценариев обеспечивает возможность проведения испытаний на соответствие требованиям первой и второй редакций стандарта МЭК 61850. Сценарии испытаний разработаны в точном соответствии с методиками, принятыми международной группой пользователей стандарта МЭК 61850 (UCA International Users Group) и использующимися в аккредитованных независимых испытательных центрах.

ОАО «НТЦ ФСК ЕЭС» предлагает производителям провести испытания:

Предквалификационные испытания. В случае если в номенклатурном ряде устройств вашей компании есть устройства с поддержкой МЭК 61850, вы можете провести исследовательские испытания на соответствие стандарту с целью определения имеющихся недочетов реализации. По результатам испытаний ОАО «НТЦ ФСК ЕЭС» формирует подробный отчет с указанием всех недочетов и мероприятий, требующихся для их устранения.
Квалификационные испытания.В рамках проведения аттестации устройств с поддержкой МЭК 61850 для последующего применения на объектах ОАО “Россети” будут проводиться испытания данных устройств на соответствие стандарту МЭК 61850*.

* Проведение испытаний будет возможно после разработки и утверждения в ОАО “Россети” программы и методики испытаний, а также в случае включения подобных испытаний в перечень испытаний, необходимых к прохождению для последующей аттестации оборудования.

International standard. IEC 61850-10 – Communication networks and systems in substations. Part 10: Conformance Testing. First edition.
International standard. IEC 61850-10 – Communication networks and systems for power utility automation. Part 10: Conformance Testing. Second edition.
Bruce Muschlitz (EnerNex Corporation). IEC 61850 Conformance Testing: Goals, Issues and Status. DistribuTECH 2006, Tampa, Florida.
Eric A. Udren, W. Strabbing, D. Dolezilek. IEC 61850: Role of conformance testing in successful integration.

digitalsubstation.com

Актуальный состав стандарта МЭК 61850

Актуальный состав стандарта МЭК 61850 | Цифровая подстанция

Изображение: Международная электротехническая комиссия - www.iec.ch Актуальная компиляция стандарта МЭК 61850 включает в себя 21 документ (стандарты, технические отчеты, технические требования). Некоторые из документов уже имеют вторую редакцию, а некоторые только изданы в первой редакции (причем, совсем недавно).

На сегодняшний день во второй своей редакции в состав стандарта входят следующие документы:

МЭК 61850-1. Введение и общие положения
МЭК 61850-4. Системный инжиниринг и управление проектами
МЭК 61850-5. Требования к функциям и устройствам в части передачи данных
МЭК 61850-6. Язык описания конфигурации для обмена данными
МЭК 61850-7-1. Базовая структура коммуникаций – Принципы и модели
МЭК 61850-7-2. Базовая структура коммуникаций – Абстрактный интерфейс коммуникаций (ACSI)
МЭК 61850-7-3. Основная структура коммуникаций – Общие классы данных
МЭК 61850-7-4. Основная структура коммуникаций – Классы логических узлов и объектов данных
МЭК 61850-7-410. Основная структура коммуникаций – Гидроэлектростанции – Общие классы данных, классы логических узлов и объектов данных
МЭК 61850-8-1. Назначение на определенный коммуникационный сервис – Назначение на MMS и IEC 8802-3
МЭК 61850-9-2. Назначение на определенный коммуникационный сервис – Передача мгновенных значений по интерфейсу IEC 8802-3
МЭК 61850-10. Проверка соответствия МЭК 61850

В первой редакции выпущены следующие документы:

МЭК 61850-2. Термины и определения
МЭК 61850-3. Общие требования
МЭК 61850-7-420. Основная структура коммуникаций – Объекты малой генерации – Общие классы данных, классы логических узлов и объектов данных
МЭК 61850-7-510. Основная структура коммуникаций – Гидроэлектростанции – Руководящие указания по моделированию данных
МЭК 61850-80-1. Руководство по передаче информации из модели общих классов данных с использованием МЭК 60870-5-101 или МЭК 60870-5-104
МЭК 61850-90-1. Использование МЭК 61850 для организации связи между подстанциями
МЭК 61850-90-4. Руководящие указания по инжинирингу систем связи на подстанциях
МЭК 61850-90-5. Использование МЭК 61850 для передачи данных от устройств синхронизированных векторных измерений
МЭК 61850-90-7. Объектные модели для электростанций на базе фотоэлементов, аккумуляторов и других объектов с использованием инверторов

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам:

Ваш комментарий (необязательно):

digitalsubstation.com

e-urchin: МЭК 61850. Протокол GOOSE.

Макина Н.Г. МЭЭТ – 02 -15

МЭК 61850. Протокол GOOSE.

ВведениеВ течение последних лет, МЭК (международная электротехническая комиссия) TC57 утвердила стандарт МЭК 61850 – «Коммуникационные сети и системы подстанций».В настоящее время этот стандарт используется не только между верхним уровнем станции (который включает в себя SCADA, шлюзы для передачи данных в ЦУС и РДУ сервер времени и др.) и уровнем присоединения (терминалы РЗА (ИЭУ), измерительный трансформаторы тока и напряжения и др.), но также и для открытого общения с основным оборудованием.Стандарт МЭК 61850 содержит в себе три основных протокола передачи данных:1. MMS (Manufacturing Message Specification – стандарт МЭК 61850-8-1) – протокол передачи данных реального времени и команд диспетчерского управления между сетевыми устройствами и/или программными приложениями;2. GOOSE (Generic Object Oriented Substation Event – стандарт МЭК 61850-8-1) – протокол передачи данных о событиях на подстанции. Фактически данный протокол служит для замены медных кабельных связей, предназначенных для передачи дискретных сигналов между устройствами;3. SV (Sampled Values – стандарт МЭК 61850-9-2) – протокол передачи оцифрованных мгновенных значений от измерительных трансформаторов тока и напряжения (ТТ и ТН). Данный протокол позволяет заменить цепи переменного тока, соединяющие устройства РЗА с ТТ и ТН.

Рисунок 1 − Протоколы стандарта МЭК 61850

А также, МЭК 61850 содержит требования к информационной модели, которая должна быть реализована в устройствах, к языку конфигурирования и процессу инжиниринга систем. Четкое описание информационной модели устройств является одной из важных особенностей стандарта МЭК 61850, отличающей его от других стандартов информационного обмена в электроэнергетике. В соответствии с требованиями каждое физическое устройство должно содержать в себе логический сервер, в рамках которого заложена иерархическая модель, включающая одно или несколько логических устройств, в которых содержатся логические узлы. Каждый логический узел в свою очередь включает в себя элементы и атрибуты данных (рис. 2).

Рисунок 2 − Иерархическая информационная модель

Таблица 1 – Пример информационной модели устройства

LOGICAL-DEVICE (LD) (логическое устройство) - содержит информацию, которую производит и использует группа функций приложения, специфических для определенной области; функции определяют как логические узлы (LOGICAL-NODE).

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

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

DATA OBJECT (DO) (объект данных) – элемент данных

DATA ATTRIBUTES (DA) (атрибуты данных) – параметр данных, относящийся к их структурным свойствам, используемый для указания контекста данных или придания им смыслового значения.1.1 Протокол GOOSE1.1.1 Обмен логической информацией терминалами между собой и АРМ (автоматизированным рабочим местом) релейщика производится по протоколу GOOSE.GOOSE ( англ Generic Object Oriented Substation Event) (стандарт МЭК 61850-8-1) – протокол передачи данных о событиях на подстанции.GOOSE–сообщения, передаваемые через Ethernet, упаковываются в так называемые фреймы (Ethernet кадры) вместе с дополнительной информацией и передаются. Один такой фрейм состоят из заголовка, адреса получателя, адреса отправителя, типа и контрольной суммы, и, конечно же, из пользовательских данных. На рис. 3 показана структура фрейма.

Рисунок 3 – Формат стандартного Ethernet кадра Начинается с преамбулы (Preamble), которая используется для синхронизации приемопередатчиков. Далее идут MAC адреса приемника (Destination address) – адрес устройства, которому направляется сообщение, и источника (Source address) – уникальный адрес передающего интеллектуального устройства (ИЭУ). Идентификатор протокола (TPID, Tag Protocol Identifier) – указывает тип использованного протокола. Идентификатор сообщения (Ethertype)–указывает тип сообщений. Идентификатор положения (APPID, Application Identifier) – служит для разделения сообщений. Длина данных (Length) – суммарная длина полей APPID, Length, reserved 1, reserved 2 и APDU. Reserved 1 и reserved 2 – зарезервированные поля. Прикладной протокол данных (APDU, Application Protocol Data Unit) – содержит измерительную информацию. Контрольная сумма (Frame check sequence) – контрольное значение, вычисляемое по алгоритму CRC-32. С помощью контрольной суммы получатель может определить не был ли поврежден фрейм во время передачи. А на рис. 4 представлено реальное GOOSE–сообщение.

Рисунок 4 – Реальное GOOSE–сообщение

Рассмотрим GOOSE – сообщение. Как видно из рисунка, это сообщение послал терминал защиты среднего напряжения , вид защиты первая ступень МТЗ.AppID - видимая строка, которая представляет логическое устройство LD, в котором размещен блок управления GoCB. Значение атрибута AppID по умолчанию должно быть таким, как в объектной ссылке блока управления GoCB. Однако это значение может быть настроено на другое значение как часть конфигурации всей системы.Lenght – длина GOOSE – сообщения.ReservedGoosePdu – блок данных протокола.GoCBRef – ссылка блока управления GOOSE-событием.timeAllowedtolive разрешенное «время жизни» GOOSE-сообщения.DatSet - ссылка набора данных. Атрибут DatSet должен описывать объектную ссылку контролируемого набора данных DATA-SET, значения элементов которого (одного, подмножества или всех) должны включаться в отчет.goID – идентификатор GOOSE – сообщенияt – временная метка.Параметр t содержит момент времени, когда атрибут StNum был увеличен.StNum - номер состоянияПараметр StNum содержит счетчик, показания которого увеличиваются на единицу каждый раз, когда послано GOOSE-сообщение и зафиксировано изменение значения внутри набора данных DATA-SET, определяемого с помощью параметра DatSet.Исходное значение для параметра StNum должно равняться 1. Нулевое значение должно быть зарезервировано.SqNum - порядковый номерПараметр SqNum содержит счетчик, показания которого увеличиваются на единицу каждый раз, когда послано GOOSE-сообщение.Исходное значение для параметра SqNum должно равняться 1. Нулевое значение должно быть зарезервировано.Test – тестПараметр Test указывает при значении логической единицы (TRUE), что значения в сообщении не должны использоваться для эксплуатационных целей.ConfRev - версия конфигурацииАтрибут ConfRev представляет собой подсчет количества раз, когда конфигурация набора данных, имеющая ссылку, была изменена.NdsCom - требуется ввод в эксплуатациюПараметр NdsCom содержит атрибут NdsCom (взятый из блока управления GoCB) блока управления GoCB.numDatSetEntries – номер записи набора данныхallData: 1 item – всего данных: 1 элементstructure: 3 items – структура: 3 элементаData: boolean – (тип данных Boolean) говорит о несрабатывании (логический ноль или «false»).Data: bit-string – (тип данных bit-string (качество), говорит о качестве дискретного сигнала.Data: utc-time– (тип данных метка времени), говорит о времени изменения GOOSE–сообщения.Таким образом, в этом сообщении имеется в виду, что срабатывания первой ступени не произошло.Как известно, протокол GOOSE служит фактически для замены медных кабельных связей на подстанции.Раньше для передачи дискретных сигналов между терминалами РЗА использовались дискретные входы и выходные реле. Передача сигнала при этом осуществляется подачей оперативного напряжения посредством замыкания выходного реле одного терминала на дискретный вход другого терминала (далее такой способ передачи будем называть традиционным).Для разработки альтернативы цепям передачи сигналов между устройствами релейной защиты были проанализированы свойства информации, передаваемой между устройствами РЗА посредством дискретных сигналов:1. Возможность передачи сообщений сразу нескольким адресатам. При реализации некоторых распределенных функций РЗА требуется передача данных от одного устройства сразу нескольким;2. Требуется высокая вероятность доставки сообщения для реализации ответственных функций, таких как подача команды отключения выключателя от РЗА, обмен сигналами между РЗА при выполнении распределенных функций. Необходимо обеспечение гарантированной доставки сообщения как в нормальном режиме работы цифровой сети передачи данных, так и в случае ее кратковременных сбоев;3. Необходим контроль целостности канала передачи данных. Наличие функции диагностики состояния канала передачи данных позволяет повысить коэффициент готовности при передаче сигнала, тем самым повышая надежность функции, выполняемой с передачей указанного сообщения.4. Требуется высокая скорость передачи информации. Большая часть дискретных сигналов, передаваемых между устройствами РЗА, прямо или косвенно влияет на скорость ликвидации ненормального режима, поэтому передача сигнала должна осуществляться с минимальной задержкой;Перечисленные требования привели к разработке механизма GOOSE-сообщений, отвечающих всем предъявляемым требованиям.1.1.2 Принцип передачи GOOSE–сообщений Первое требование выполняется автоматически, так как это заложение в самом принципе передачи GOOSE-сообщений (рис. 6).Для адресации кадров на канальном уровне используются физические адреса сетевых устройств – MAC-адреса. При этом Ethernet позволяет осуществлять так называемую групповую рассылку сообщений (Multicast). В таком случае в поле MAC-адреса адресата указывается адрес групповой рассылки. Для многоадресных рассылок по протоколу GOOSE используется определенный диапазон адресов (рис. 5).

Рисунок 5 – Диапазон адресов многоадресной рассылки для GOOSE–сообщений Рисунок 6 – Принцип передачи GOOSE–сообщений Устройство-отправитель передает по сети Ethernet информацию в широковещательном диапазоне. В сообщении присутствует адрес отправителя и адреса, по которым осуществляется его передача, а также значение сигнала (например «0» или «1»). Устройство-получатель получит сообщение, а все остальные устройства его проигнорируют. Поскольку передача GOOSE-сообщений осуществляется в широковещательном диапазоне, т.е. нескольким адресатам, подтверждение факта получения адресатами сообщения отсутствует. По этой причине передача GOOSE-сообщений в установившемся режиме производится с определенной периодичностью. Рассмотрим реальной пример спонтанной передачи GOOSE-сообщений между терминалами защит. Период отправки сообщений в данной примере – 2 с, а минимальное время отправки сообщений 10 мс. 1. Рассмотрим рисунок 7, выделенная строчка 3934: срабатывания терминала не произошло (значение состояния stVal – «False», или «логический 0»), время изменения GOOSE-сообщения – 63.152468.

Рисунок 7 – Пример GOOSE–сообщения без срабатывания.

2. Далее рассмотрим рисунок 8, строчка 4072: произошло срабатывание терминала (значение состояния stVal – «True»), время изменения GOOSE-сообщения: 64.790562.

Рисунок 8 – Пример GOOSE–сообщения со срабатыванием.

А теперь, как видно на рисунке 9, после сообщения о срабатывании терминала, начинается повторная передача GOOSE–сообщений через 10 мс, 20 мс, 40 мс и т.д., до того момента, пока время между сообщениями не увеличится опять до времени периода отправки – 2 с.

Рисунок 9 – Пример спонтанной передачи GOOSE–сообщений.

Такая технология повторной передачи не только гарантирует получение адресатом сообщения, но также обеспечивает контроль исправности линии связи и устройств – любые неисправности будут обнаружены по истечении максимального периода передачи GOOSE-сообщений (с точки зрения эксплуатации практически мгновенно). В случае передачи сигналов традиционным образом неисправность выявляется либо в процессе плановой проверки устройств, либо в случае неправильной работы системы РЗА.Таким образом такая передача данных обеспечивает высокую вероятность доставки (отвечает второму требованию).1.1.3 Надежность передачи GOOSE-сообщенийДля того чтобы использовать GOOSE-сообщения для передачи дискретных сигналов между терминалами РЗА необходима достаточная надежность и быстродействие передачи GOOSE-сообщений. Надежность передачи GOOSE-сообщений обеспечивается следующим:1. протокол МЭК 61850 использует Ethernet-сеть, за счет этого выход из строя верхнего уровня АСУ ТП и любого из устройств РЗА не отражается на передаче GOOSE-сообщений оставшихся в работе устройств;2. терминалы РЗА имеют два независимых Ethernet-порта, при выходе одного из них из строя второй его полностью заменяет;3. сетевые коммутаторы, к которым подключаются устройства РЗА, соединяются в два независимых «кольца»;4. разные порты одного терминала РЗА подключаются к разным сетевым коммутаторам, подключенным к разным «кольцам»;5. каждый сетевой коммутатор имеет дублированное питание от разных источников;6. во всех устройствах РЗА осуществляется постоянный контроль возможности прохождения каждого сигнала, который позволяет автоматически определить не только отказы цифровой связи, но и ошибки параметрирования терминалов.Дополнительно увеличивает надежность то обстоятельство, что даже в случае отказа в передаче GOOSE-сообщения, устройство, принимающее сигнал, выдаст сигнал неисправности, а последнее принятое значение останется запомненным по умолчанию, пока персонал не примет необходимые меры для устранения неисправности.Дан участок электрической сети напряжением 10 кВ (рис. 10, а). Здесь, Т1 – терминал защиты ввода, Т2 - Т4 – терминалы защиты линии. От терминалов защиты линии к терминалам защиты ввода поступает сообщение, в теле которого сигнал «УРОВ».

Рисунок 10 – Пример участка сети

При возникновении КЗ на одной линии (рис. 10, б), метка состояния опции пуска защиты (stVal) меняется на «True», и если выключатель присоединения исправен, то защита сработает селективно, изолировав выключателем поврежденную линию. Но если выключатель присоединения неисправен, то через определенную выдержку времени должна сработать защита ввода и уже своим выключателем отключить весь ввод.

Рисунок 11 – Пример участка сети А теперь рассмотрим другой случай, оборвалась связь между терминалами защиты линии и ввода (рис. 10), то есть GOOSE-сообщение с сигналом «УРОВ» больше не поступает, тогда на терминале ввода запоминается то состояние «УРОВ», которое было последним, то есть «True». И ложного срабатывания защиты ввода не произойдет. 1.1.4 Быстродействие передачи GOOSE-сообщений В соответствии с требованиями действующего стандарта МЭК 61850-5 допустимое время передачи GOOSE-сообщения не более 3 мс (для сообщений, требующих быстрой передачи, например, для передачи сигналов срабатывания защит, пусков АПВ и УРОВ и т.п.). Другие нормативы времени для сигналов представлены в таблице 2. Таблица 2 – Нормированное время передачи сигналов Тип сигнала Макисмальное время передачи, мс Сигнал отключения, блокировки 3 Снятие блокировки, изменение состояния 10 Быстрые автоматические взаимодействия 20 Медленные автоматические взаимодействия 100 Команды оператора 500 Регистрация событий, сигнализация 1000 Файлы, журналы событий >1000

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

Рисунок 12 – Приоритетность передачи GOOSE–сообщений

ВыводИменно наличие инструмента GOOSE-сообщений позволяет значительно сократить расходы на кабельное хозяйство и монтажные работы, увеличить надежность передачи сигналов в части ЭМС, повысить масштабируемость системы РЗ и ПА в целом и т.д. Вместе с тем, несмотря на активное использование GOOSE-сообщений в отечественной энергетике, необходимо отметить ограниченность применения этого инструмента. По моему мнению, применение протокола МЭК 61850-8-1 – GOOSE уменьшило аппаратную надежность УРЗА. На данный момент, посредством GOOSE–сообщений отправляются только наименее ответственные сигналы.

iv-sp.blogspot.com

МЭК-61850 — WiKi

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

История

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

Каждый производитель строил систему на основе тех протоколов передачи данных, которые он считал наиболее подходящими для решения той или иной задачи. Использовались такие протоколы как IEC 60870-5-101/103/104, Modbus, DNP3 и т.д. Некоторые из них стали более популярными, некоторые менее, но такое разнообразие решений приводило к отсутствию совместимости и взаимозаменяемости оборудования и усложнению процесса системной интеграции.

История создания МЭК-61850 началась еще в 1980-х годах в США в Детройте. На заводах, собирающих автомобили, были установлены роботы-сборщики, управление которыми производилось по протоколу MMS (англ.). Использование этого протокола оказалось достаточно успешным и уже в 90-х годах он лег в основу UCA2 (Utility Communication Architecture), который активно применялся в Европе в электроэнергетике.

И наконец, в 2003 году появилась первая редакция стандарта МЭК-61850.