Адрес asdu что это
Канальный уровень добавляет к APDU контрольную информацию протокола канального уровня (LPCI), образовывая блок данных протокола канального уровня (LPDU). Этот уровень также подготавливает каждый октет в LPDU к отправке в виде асинхронных серийных символов, имеющих один стартовый бит (значение = 0), восемь битов данных (октет данных), один бит контроля четности и один бит окончания (значение = 1).
Для скорости передачи до 1,2 кбит/с используется модуляция FSK (кодирование со сдвигом широт), симметричная и требующая меньше памяти. Она подходит для большинства аналоговых каналов со звуковой частотой на линии передачи основного диапазона, высокочастотной линии ЛЭП и средств радиопередачи.
Для скорости передачи, превышающей 1,2 кбит/с, используются синхронные модемы. Более быстрые передачи, до 19,2 кбит/с, также возможны на линиях передачи данных прямого соединения, использующих концентраторы цифровых сигналов.
Кадр LPDU обеспечивает очень высокую целостность данных (целостность класса 12 стандарта IEC). В полученном кадре должно быть, по крайней мере, четыре ошибочных бита для того, чтобы произошла не диагностируемая ошибка кадра. Благодаря контролю четности не диагностируемая ошибка символа может произойти только при появлении как минимум двух ошибочных бит. Благодаря проверке контрольной суммы не диагностируемая ошибка контрольной суммы может произойти только при появлении как минимум двух ошибочных символов. Таким образом, для не диагностируемой ошибки кадра требуются четыре ошибочных бита.
Этот протокол может быть реализован в двух физических конфигурациях:
· многоточечная (шинная) конфигурация с передачей данных по принципу «клиент-сервер», где применяемый метод доступа к среде передачи данных это опрос;
· индивидуальные соединения со всеми удаленными станциями в типичной звездообразной конфигурации. Индивидуальные соединения позволяют устанавливать сбалансированный (полнодуплексный) доступ к среде обмена данными для канального протокола, делая возможным спонтанную отправку данных в обоих направлениях.
Этот протокол выполняет канальные функции. Однако практические соображения, в том числе более высокая стоимость, могут ограничить его использование.
В основу протокола, как и в предыдущем случае, положен обмен таблицами сигналов, причем типы данных, которыми осуществляется обмен, жестко фиксированы.
В целом протокол хорошо подходит для решения описанного выше спектра задач, однако обладает рядом недостатков:
· Передача данных осуществляется в два этапа:
1) Назначение индексированных коммуникационных объектов на прикладные объекты;
2) Назначение прикладных объектов на переменные в прикладной базе данных или программе. Таким образом, отсутствует семантическая связь (полностью или частично) между передаваемыми данными и объектами данных прикладных функций.
· Протоколы не предусматривают возможность передачи сигналов реального времени. При этом под сигналами реального времени понимаются данные, которые должны передаваться в темпе процесса с минимально возможными выдержками времени, к которым относятся, например, команды отключения, передача мгновенных значений токов и напряжений от измерительных трансформаторов. При передаче таких сигналов задержки в канале связи являются критическими.
Некоторые особенности реализации стандарта IEC-60870-5-104 в системе программирования контроллеров ISaGRAF: от теории к практике
Компания «ФИОРД», г. Санкт-Петербург
В США и в Европе в конце восьмидесятых годов начали разрабатываться унифицированные открытые протоколы для устройств и систем автоматизации (в первую очередь для телемеханики), наиболее известными из которых стали DNP3, UCA и стандарты серии IEC 60870. В чем была причина и движущая сила этого процесса? Дело в том, что на рынке сложилась ситуация параллельного использования множества несовместимых частнофирменных протоколов различных производителей. Аналогичная ситуация имела место и в Советском Союзе, а затем и в России, где получили распространение множество протоколов для телемеханики, таких, как ТМ-120, ТМ-320, ТМ-512, ТМ-800А, ВРТФ-3, КОМПАС-ТМ, АИСТ, ГРАНИТ, УТК-1, УТМ-7, АПТ-2, СКП, РКП, КМА и др. Это порождало серьезные проблемы совместимости при создании и сопровождении систем управления. В связи с этим назрела потребность в создании унифицированного открытого протокола для устройств и систем (в том числе систем телемеханики), позволяющего работать со всем разнообразием объектов автоматизации.
Таблица 1. Стандарты серии IEC 60870
Таблица 2. Стандарты ГОСТ Р МЭК 60870
В связи c рассмотрением особенностей драйвера IEC 60870-5-104 для ISaGRAF нам потребуется обсудить в общих чертах серию протоколов IEC 60870-5, углубиться в некоторые вопросы, важные для понимания реализованных возможностей. Особое внимание уделим стандарту (протоколу) IEC 60870-5-104, драйвер для которого в среде ISaGRAF и составляет предмет нашего рассмотрения. Этот обобщающий стандарт был издан в декабре 2000 года, приблизительно через шесть лет после публикации IEC 60870-5-101. В преамбуле к стандарту сказано, что правила настоящего стандарта представляют комбинацию прикладного уровня стандарта IEC 60870-5-101 и функций транспортного уровня, предусматриваемых TCP/IP. Внутри TCP/IP могут быть использованы различные типы сетей, включая Ethernet 802.3, X.25, FR (Фрейм реле), ATM (Режим асинхронной передачи) и ISDN (Цифровая сеть интегрированного обслуживания), как это показано на рис. 1 (фрагмент из стандарта).
Таблица 3. Сравнение сетевых моделей (стеков)
В результате стек протокола IEC 60870-5-104 имеет структуру, показанную в табл. 5.
На канальном уровне следует обратить внимание на понятия первичная (ведущая, мастер) и вторичная (ведомая, slave) станция. Термин «первичная станция» означает, что она (и только она) инициирует взаимодействие на канальном уровне. Ведомая станция ждет запроса от первичной станции и только после получения такового посылает в ответ какие-либо данные. Однако ведомая станция может выступать как первичная для станций следующего уровня в иерархической системе.
Процедуры передачи – небалансная и балансная. При небалансной процедуре передачи одна из станций всегда выступает как первичная станция, а все остальные станции как вторичные. При балансной передаче каждая станция может быть как первичной, так и вторичной.
Таблица 4. Избранные стандартные позиции TCP/IP в соответствии с RFC 2200
для протокола IEC 60870-5-104
Как я писал библиотеку под МЭК 870-5-104 на Arduino при помощи Wireshark
В этой статье я хотел бы рассказать о своем знакомстве с протоком передачи данных МЭК 870-5-104 со стороны контролируемого (slave) устройства путем написания простой библиотеки на Arduino.
Что такое МЭК 870-5-104 это и где применяется?
МЭК 60870-5-104 – протокол телемеханики, предназначенный для передачи сигналов ТМ в АСТУ, регламентирующий использование сетевого доступа по протоколу TCP/IP. Чаще всего применяется в энергетике для информационного обмена между энергосистемами, а также для получения данных от измерительных преобразователей (вольтметры, счетчики электроэнергии и прочее).
Стэк протокола МЭК 670-5-104:
Используемые материалы
Краткое описание этапов работы
Подготовка
Термины и сокращения
APCI — Управляющая Информация Прикладного Уровня может применяться как самостоятельный управляющий кадр (кадр U или кадр S).
ASDU — Блоки данных прикладного уровня, состоит из идентификатора блока данных и одного или более объектов информации, каждый из которых включает в себя один или более однородных элементов информации (либо комбинаций элементов информации).
APDU — Протокольный блок данных прикладного уровня.
ТС — телесигнализация.
ТИ — телеизмерения.
ТУ — телеуправление.
1. Установка TCP/IP соединение порт 2404
Контролирующая (master) станция инициализирует установку TCP соединения путем посылки TCP пакета с флагом (SYS). Соединение считается установленным, если в течение контрольного времени (t0) контролируемая станция (slave) выдала на свой уровень TCP/IP подтверждение «активного открытия» (SYS ACK). Контрольное время t0 называется «Тайм-аут установки соединения». Таймер t0 определяет, когда открытие отменяется и не определяет начало новой попытки соединения.
Взаимодействие с транспортным уровнем выполняет стандартная библиотека для плат Arduino «Ethernet.h». То есть первым делом необходимо установить TCP/IP соединение между контролируемой и контролирующей станциями. Для этого необходимо в скетче Arduino инициализировать устройство и создать сервер который будет ожидать входящие соединения через указанный порт.
Если загрузить этот скетч то будет происходить следующее:
Установка соединения, далее приходит пока неизвестный для Arduino пакет STARTDT act и по истечении определенного времени рвется соединение. Далее необходимо разобраться что такое STARTDT act.
2. Подтверждение запроса на передачу данных (STARTDT act/con)
В МЭК 670-5-104 существует 3 типа формата для передачи:
Таким образом далее необходимо считать байты полученные от контролирующей (master) станции и разобрать их.
Прочитав данные необходимо разобрать их и сформировать ответ.
Вот как выглядит посылка содержащая блок STARTDT в программе Wireshark, APDU блок U-формата, который состоит только из APCI.
APCI—Управляющая Информация Прикладного Уровня может применяться как самостоятельный управляющий кадр (кадр U или кадр S).
Вкратце можно сказать, что блок APCI определяет тип блока APDU и его длину. APCI состоит из следующих шести байтов:
1. Признак инициализации блока APDU переменной длины, начинающийся байтом START2 68h;
2. Длин APDU, в данном примере равна четырем байтам;
3. Байт управления в котором определяется тип APDU, в данном примере записано значение равное семи, что означает запрос на передачу данных;
4,5,6 Не используются.
Исходя из вышеописанного, перед тем как ответить, не мешало бы определить какой тип APDU нам послала контролирующая станция. Зная, что тип APDU записан третьим по порядку чтения блока APCI байтом, сохраню его в целочисленную переменную.
Примечание: Если будет получен пакет формата «I» то 3 байт в APCI будет также содержать значение младшего слова счетчика принятых пакетов, 
поэтому пришлось немного усложнить конструкцию определения типа APDU.
Из рисунка выше видно, что тип APDU соответствующий значению 7 это STARTDT act соответственно ответить необходимо таким же по структуре пакетом только значение типа должно иметь значение 11 (0b), что соответствует STARTDT con.
После обновления скетча наблюдаем следующий порядок обмена:
Установку соединения, запрос на передачу данных, подтверждение запроса и еще один новый пока неизвестный APDU формата I типа 1 C_IC_NA Act.
3. Запрос на общий опрос станции
APDU C_IC_NA_1 кроме блока APCI так же имеет блок ASDU (блок данных прикладного уровня), которые вместе формируют Протокольный Блок Данных Прикладного Уровня APDU.
Рассмотрим более подробно полученный APDU.
После обновления скетча наблюдаем следующий порядок обмена: 
Установку соединения, запрос на передачу данных, подтверждение, запрос на общий опрос станции от контролирующей станции, завершение инициализации, запрос на общий опрос станции в направление контролируемой станции, подтверждение общего опроса, пересылка значений всех доступных сигналов на контролирующей станции, завершение общего опроса и неизвестный APCI формата S.
Запрос опроса станции выдается в направлении контролируемой станции:
— если с контролируемой станции получен «КОНЕЦ ИНИЦИАЛИЗАЦИИ» или
— если центральная станция обнаруживает потерю канала (безуспешное повторение запроса канального уровня) и последующее восстановление его.
4. Подготовка и передача данных
APDU блок формата S, состоящий только из APCI предназначен для подтверждения принятого APDU I формата. Для S-формата 7 старших бит служебного поля байта 1 и байт 2 не задействованы, а байт 3 (7 старших бит) и байт 4 определяют текущий номер принятой посылки.
В данном случае блок S указывает на то, что контролирующая (master) станция готова к приему данных в течении определенного времени, не превышающего, тайм-аут t3 определенного на стороне контролирующей (master) станции. То есть контролирующая (master) станция говорит нам «я готова к приему данных!». Далее необходимо позаботиться о том какие данные передавать и откуда их брать.
Что можно передавать? Существует несколько видов информации определённых в МЭК 870-5- 104:
В данном примере рассматривается передача контрольной информации на примере 1, 11 и 13 функций (одноэлементная, измерение масштабируемое, измерение короткий формат с плавающей запятой). Данные формируются рандомно. Также необходимо учитывать, что у каждого передаваемого сигнала имеется байт качества.
Простой алгоритм определения качества сигнала:
Так же необходимо учесть, что для каждого сигнала имеется уникальный идентификатор IOA, в энергетике принято распределять эти адреса следующим образом:
И так получив APDU подтверждение S или I формата от контролирующей станции можно начать передавать имеющиеся в распоряжении данные, не забывая увеличивать номер передаваемого кадра. 
Загрузив скетч в Wireshark наблюдаем, что наконец-то началась передача данных. 
Далее привожу описание структуры ASDU M_SP_NA_1 одноэлементная индикация.
TypeId — вид информации.
SQ — классификатора переменной структуры.
Предусматриваются две структуры блоков данных:
1. Блок, содержащий i объектов информации, каждый из которых содержит по одному элементу информации (или по одной комбинации элементов); старший бит классификатора переменной структуры SQ (single/sequence) равен 0, остальные 7 битов задают число i.
2. Блок, содержащий один объект информации, который содержит j элементов либо одинаковых комбинаций элементов информации; старший бит (27 = 80h) классификатора SQ равен 1, остальные 7 битов задают число j.
CauseTx — причина передачи.
Addr — адрес слэйва (указывается при конфигурировании мастера).
IOA — адрес объекта информации, по этому адресу контролирующая станция будет привязывать свой тэг
SIQ — показатель качества передаваемого сигнала.
Структура ASDU блока функции M_ME_NB_1:
В ответ на полученные данные master будет отправлять блоки формата S и процесс зациклится до тех пор пока контролируемое(slave) устройство не перестанет передавать кадры.
5. Процедуры тестирования
Процедуры тестирования применяются с целью контроля за работоспособностью транспортных соединений. Процедура выполняется независимо от «активности» IP-соединения, если в течение контрольного времени t3 не было принято ни одного кадра (I, U, S). Время t3 является предметом согласования и называется «Тайм-аут для посылки блоков тестирования в случае долгого простоя». Процедура тестирования реализуется путем посылки тестового APDU (TESTFR =act), которое подтверждается принимаемой станцией с помощью APDU (TESTFR =con).
Если от контролирующей (master) станции придет APDU у которого в байте отвечающего за тип APDU значение равно шестидесяти сети (TESTFR) это говорит о том, что в течении времени t3 от контролируемой станции не было принято ни одного кадра (I, U, S), и если в течении времени t1 не ответить подтверждением то соединение будет разорвано.
Событийные протоколы. Обзор
Событийные протоколы в основном применяются на объектах электроэнергетики, а также системах дистанционного управления различных систем шлюзов и водоразделов. Применяются везде, где необходима удаленная диспетчеризация и управление сильно удаленных друг от друга объектов.
История развития и внедрения событийных протоколов в автоматизации энергообъектов
Похожая ситуация наблюдается и среди производителей РЗА: при наличии действующего стандарта 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
Протокол DNP-3
Вариации для постоянных данных:
Вариации для событийных данных:
Флаги подразумевают под собой наличие специального байта со следующими информационными битами: источник данных on-line, источник данных был перезагружен, соединение с источником потеряно, запись значения форсирована, значение вне допустимых границ.
Заголовок фрейма:
Протокол IEC 61850 MMS
Таким образом, концептуальные вопросы и абстрактные модели оказываются независимыми от используемых технологий передачи данных (проводные, оптические или радиоканалы), поэтому не потребуют пересмотра, вызванного прогрессом в области технологий передачи данных.
Абстрактный коммуникационный интерфейс, описываемый МЭК 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
Механизм передачи данных «клиент-сервер»
Протокол IEC 61850 GOOSE
Формирование GOOSE-сообщений
Передача GOOSE-сообщений
Использование всех рассмотренных методов позволяет значительно повысить приоритет данных, передаваемых по протоколу GOOSE, по сравнению с остальными данными, передаваемыми по той же сети с использованием других протоколов, тем самым, сводя к минимуму задержки как при обработке данных внутри устройств источников и приёмников данных, так и при обработке их сетевыми коммутаторами.
Отправка информации нескольким адресатам
Диапазон адресов многоадресной рассылки для GOOSE-сообщений
Сообщения, имеющие значение «01» в первом октете адреса, отправляются на все физические интерфейсы в сети, поэтому фактически многоадресная рассылка не имеет фиксированных адресатов, а её МАС-адрес является скорее идентификатором самой рассылки, и не указывает напрямую на её получателей.
Таким образом МАС-адрес GOOSE-сообщения может быть использован, например, при организации фильтрации сообщении на сетевых коммутатора (МАС-фильтрации), а также указанный адрес может служить в качестве идентификатора, на который могут быть настроены принимающие устройства.
Таким образом передачу GOOSE-сообщений можно сравнить с радиотрансляцией: сообщение транслируется всем устройствам в сети, но для получения и последующей обработки сообщения устройство-приёмник должно быть настроено на получение этого сообщения. 
Схема передачи GOOSE-сообщений
Передача сообщений нескольким адресатам в режиме Multicast, а также требования к высокой скорости передачи данных не позволяют реализовать при передаче GOOSE-сообщений получение подтверждений о доставке от получателей. Процедура отправки данных, формирования получающим устройством подтверждения, приём и обработка его устройством отправителем и последующая повторная отправка в случае неудачной попытки заняли бы слишком много времени, что могло бы привести к чрезмерно большим задержкам при передаче критических сигналов. В место этого для GOOSE-сообщений был реализован специальный механизм, обеспечивающий высокую вероятность доставки данных.
Во-первых, в условиях отсутствия изменений в передаваемых атрибутах данных, пакеты с GOOSE-сообщениями передаются циклически через установленный пользователем интервал. Циклическая передача GOOSE-сообщений позволяет постоянно диагностировать информационную сеть. Устройство, настроенное на приём сообщения, ожидает его прихода через заданные интервалы времени. В случае, если сообщение не пришло в течение времени ожидания, принимающее устройство может сформировать сигнал о неисправности в информационной сети, оповещая таким образом диспетчера о возникших неполадках.
Во-вторых, при изменении одного из атрибутов передаваемого набора данных, вне зависимости от того, сколько времени прошло с момента отправки предыдущего сообщения, формируется новый пакет, который содержит обновлённые данные. После чего отправка этого пакета повторяется несколько раз с минимальной выдержкой времени, затем интервал между сообщениями (в случае отсутствия изменений в передаваемых данных) вновь увеличивается до максимального. 
Интервал между отправками GOOSE-сообщений
Наконец, в-четвертых, важно также отметить, что в посылке GOOSE, помимо самого значения дискретного сигнала, может также содержаться признак его качества, который идентифицирует определенный аппаратный отказ устройства-источника информации, нахождение устройства-источника информации в режиме тестирования и ряд других нештатных режимов. Таким образом, устройство-приемник, прежде чем обработать полученные данные согласно предусмотренным алгоритмам, может выполнить проверку этого признака качества. Указанное может предупредить неверную работу устройств-приемников информации (например, их ложную работу).
Следует иметь в виду, что некоторые из заложенных механизмов обеспечения надёжности передачи данных при их неправильном использовании могут приводить к негативному эффекту. Так, в случае выбора слишком короткого максимального интервала между сообщениями, нагрузка на сеть увеличивается, хотя, с точки зрения готовности канала связи, эффект от уменьшения интервала передачи будет крайне незначительным.
При изменении атрибутов данных, передача пакетов с минимальной выдержкой времени вызывает повышенную нагрузку на сеть (режим «информационного шторма»), которая теоретически может приводить к возникновению задержек при передаче данных. Такой режим является наиболее сложным и должен приниматься за расчётный при проектировании информационной сети. Однако следует понимать, что пиковая нагрузка очень кратковременна и её многократное снижение, согласно проводившимся нами опытам в лаборатории по исследованию функциональной совместимости устройств, работающих по условиям стандарта МЭК 61850, наблюдается на интервале в 10 мс.
При построении систем РЗА на основе протокола GOOSE изменяются процедуры их наладки и тестирования. Теперь этап наладки заключается в организации сети Ethernet энергообъекта. в которую будут включены все устройства РЗА. между которыми требуется осуществлять обмен данными. Для проверки того, что система настроена и включена в соответствии с требованиями проекта, становится возможным использование персонального компьютера со специальным предустановленным программным обеспечением (Wireshak, GOOSE Monitor и др.) или специального проверочного оборудования с поддержкой протокола GOOSE (PETOM 61850. Omicron CMC). Важно отметить, что все проверки можно производить не нарушая предварительно установленные соединения между вторичным оборудованием (устройствами РЗА, коммутаторами и др.), поскольку обмен данными производится по сети Ethernet. При обмене дискретными сигналами между устройствами РЗА традиционным способом (подачей напряжения на дискретный вход устройства-приемника при замыкании выходного контакта устройства, передающего данные), напротив, часто требуется разрывать соединения между вторичным оборудованием для включения в цепь испытательных установок с целью проверки правильности электрических соединений и передачи соответствующих дискретных сигналов. Таким образом, протокол GOOSE предусматривает целый комплекс мер, направленных на обеспечение необходимых характеристик по быстродействию и надёжности при передаче ответственных сигналов. Применение данного протокола в сочетании с правильным проектированием и параметрированием информационной сети и устройств РЗА позволяет в ряде случаев отказаться от использования медных цепей для передачи сигналов, обеспечивая при этом необходимый уровень надёжности и быстродействия.
Testing of Goose Protocol of IEC61850 Standard in Protection IED
Summary of GOOSE Substation Communication
A technique for analysing GOOSE packets when testing relays in an IEC 61850-8-1 environment
A Detailed Analysis of the GOOSE Message Structure in an IEC61850
Standard-Based Substation Automation System
INTERNATIONAL STANDARD 60870-5-104
TECHNICAL REPORT IEC/TR61850-1
TECHNICAL SPECIFICATION IEC TS 61850-2
INTERNATIONAL STANDARD 61850-3
INTERNATIONAL STANDARD 61850-4
INTERNATIONAL STANDARD 61850-5
INTERNATIONAL STANDARD 61850-6
INTERNATIONAL STANDARD 61850-7-1
INTERNATIONAL STANDARD 61850-7-2
INTERNATIONAL STANDARD 61850-7-3
INTERNATIONAL STANDARD 61850-7-4
INTERNATIONAL STANDARD 61850-8-1
INTERNATIONAL STANDARD 61850-9-2
INTERNATIONAL STANDARD 61850-10
Technical Report Description and analysis of IEC 104 Protocol
TECHNICAL REPORTIEC TR 61850-90-6
Автор: Тимофей Бусыгин (Московский Энергетический Институт)
#MMS, #GOOSE, #SV, #870-104, #событийный, #протокол, #обмен, #скачать61850, #скачать61870-5-104
