104 Протокол передачи данных

104 Протокол передачи данных

Релейная защита • МЭК 61850

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

Александр Головин,
технический директор

Алексей Аношин,
исполнительный директор

ООО «ТЕКВЕЛ», г. Москва

ПРОТОКОЛЫ СВЯЗИ В ЭЛЕКТРОЭНЕРГЕТИКЕ
Предпосылки для создания стандарта МЭК 61850

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

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

Системы АСТУ

  1. Передача данных между локальными устройствами телемеханики (ТМ), устройствами РЗА и центральной приемопередающей станцией (ЦППС).
  2. Передача данных между объектом и диспетчерским центром.
  3. Передача данных между диспетчерскими центрами.

Системы учета

  1. Передача данных от приборов учета в устройства сбора и передачи данных (УСПД).
  2. Передача данных от УСПД на сервер.

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

В РЗА системы передачи информации могут выполнять следующие функции:

  1. Передача дискретных сигналов.
  2. Передача данных между устройствами РЗА и ЦППС.

Другим важным каналом передачи, общим как для систем РЗА, так и для систем АСТУ и учета, является канал, по которому осуществляется передача измерений от измерительных трансформаторов тока и напряжения. До последнего времени о внедрении цифровых протоколов связи на данном уровне речь не шла, однако, имея в виду появление протокола для передачи мгновенных значений тока и напряжения МЭК 61850-9-2, на проблемах этого информационного канала также стоит остановиться.

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

ПЕРЕДАЧА ИЗМЕРЕНИЙ ОТ ТТ И ТН

Передача сигналов от измерительных трансформаторов тока (ТТ) и напряжения (ТН) осуществляется по кабелям с медными жилами переменного тока и напряжения соответственно. Для данного способа характерны проблемы, о которых достаточно часто упоминается в литературе [1, 2]:

  • большая разветвленность и протяженность медных кабелей, приводящая к необходимости применения большого числа вспомогательного оборудования (испытательных блоков, клеммников и т.д.) и, как следствие, к повышению стоимости систем и сложности монтажа и наладки;
  • подверженность измерительных цепей воздействию элек­тромагнитных помех;
  • сложность или отсутствие возможности контроля исправности измерительного канала в темпе процесса, сложность поиска места повреждения;
  • влияние сопротивления измерительных цепей на точность измерений и необходимость согласования мощности ТТ/ТН с сопротивлением цепей и нагрузкой приемника.

ПЕРЕДАЧА ДИСКРЕТНЫХ СИГНАЛОВ МЕЖДУ УСТРОЙСТВАМИ

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

Такой способ передачи информации имеет следующие недостатки [3]:

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

ПЕРЕДАЧА ДАННЫХ МЕЖДУ РЗА И ЦППС

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

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

ПЕРЕДАЧА ДАННЫХ МЕЖДУ ЦППС ОБЪЕКТА И ДИСПЕТЧЕРСКИМ ЦЕНТРОМ

Передача данных между объектом и диспетчерским центром также ведется в цифровом формате. Обычно для этих целей используют протоколы МЭК 60870-101/104. Особенности реализации этих систем связи:

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

Обратимся к рис. 1, где приведена принципиальная схема организации передачи данных. Следует отметить большое количество проприетарных (фирменных) протоколов. Широкое распространение таких протоколов требует, во-первых, большого количества шлюзов (конвертеров), во-вторых, хорошей квалификации и опыта персонала в работе с различными протоколами. В конечном счете это ведет к усложнению системы и проблемам при эксплуатации и расширении.

Рис. 1. Принципиальная схема организации передачи данных

Охарактеризуем кратко показанные стандартные протоколы.

MODBUS

Modbus – один из наиболее распространенных сетевых протоколов для интеграции устройств РЗА в систему АСТУ, построенный на архитектуре «клиент–сервер». Популярность этого протокола во многом обусловлена его открытостью, поэтому большинство устройств поддерживают этот протокол.

Протокол Modbus может применяться для передачи данных по последовательным линиям связи RS-485, RS-433, RS-232, а также сети TCP/IP (Modbus TCP).

Стандарт Modbus состоит из трех частей, описывающих прикладной уровень протокола, спецификацию канального и физического уровней, а также спецификацию ADU для транспорта через стек TCP/IP.

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

МЭК 60870-5-101/103/104

МЭК 60870-5-101 – протокол телемеханики, предназначенный для передачи сигналов ТМ в АСТУ. Он также построен на архитектуре «клиент–сервер» и предназначен для передачи данных по последовательным линиям связи RS-232/485.

Протокол МЭК 60870-5-104 является расширением протокола 101 и регламентирует использование сетевого доступа по протоколу TCP/IP. Стандарты МЭК 60870-5-101/104 не подразумевают наличие семантической модели данных.
Протокол МЭК 60870-5-103 предназначен для обеспечения возможности интеграции в систему управления энергообъекта устройств РЗА. В отличие от стандартов МЭК 60870-5-101/104, он определяет семантику для фиксированного набора данных, формируемых устройствами РЗА. Одним из основных недостатков протокола МЭК 60870-5-103 является относительно невысокая скорость передачи данных.

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

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

Читайте также:  Баклажаны с ветчиной и сыром

В целом протоколы хорошо подходят для решения описанного выше спектра задач, однако обладают рядом недостатков [4]:

  • Передача данных осуществляется в два этапа:
    1. Назначение индексированных коммуникационных объектов на прикладные объекты;
    2. Назначение прикладных объектов на переменные в прикладной базе данных или программе. Таким образом, отсутствует семантическая связь (полностью или частично) между передаваемыми данными и объектами данных прикладных функций.
    3. Протоколы не предусматривают возможность передачи сигналов реального времени. При этом под сигналами реального времени понимаются данные, которые должны передаваться в темпе процесса с минимально возможными выдержками времени, к которым относятся, например, команды отключения, передача мгновенных значений токов и напряжений от измерительных трансформаторов. При передаче таких сигналов задержки в канале связи являются критическими. Отметим, что данный пункт не связан с возможностью синхронизации устройств с единым сервером времени, а касается именно вопросов скорости передачи данных между устройствами.

    В России этот стандарт распространен слабо, однако некоторые устройства автоматизации все же поддерживают его. Долгое время протокол не был стандартизован, но сейчас он утвержден как стандарт IEEE-1815.

    DNP3 поддерживает и последовательные линии связи RS-232/485, и сети TCP/IP. Протокол описывает три уровня модели OSI: прикладной, канальный и физический. Его отличительной особенностью является возможность передачи данных как от ведущего устройства к ведомому, так и между ведомыми устройствами. DNP3 также поддерживает спорадическую передачу данных от ведомых устройств.

    В основу передачи данных положен, как и в случае с МЭК-101/104, принцип передачи таблицы значений. При этом с целью оптимизации использования коммуникационных ресурсов ведется посылка не всей базы данных, а только ее переменной части.

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

    В [4] дано подробное сравнение протоколов, но мы в табл. 1 приведем краткие выдержки применительно к рассмотренным выше протоколам.

    Таблица 1. Протоколы передачи данных

    Параметр Протокол
    Modbus МЭК-101/103/104 DNP3
    Линии связи RS-232/485/422
    TCP/IP (Modbus TCP)
    RS-232/485/422
    TCP/IP (104)
    RS-232/485/422
    TCP/IP
    Архитектура Клиент – сервер Клиент – сервер Клиент – сервер
    Принцип передачи данных Обмен индексированными точками данных
    Спорадическая передача данных Нет Да Да
    Семантическая модель данных Нет Нет
    Базовая (103)
    Да
    Передача данных в режиме реального времени Нет Нет Нет

    ВЫВОДЫ ПО ПРОТОКОЛАМ

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

    Большое количество проприетарных протоколов приводит к усложнению процесса интеграции устройств в единую систему:

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

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

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

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

    ОСНОВНЫЕ ПОЛОЖЕНИЯ ПРИ СОЗДАНИИ МЭК 61850

    Работа над стандартом МЭК 61850 началась в 1995 году, причем изначально велась двумя независимыми, параллельно работающими группами [5]: одна из них, образованная UCA*, занималась разработкой общих объектных моделей подстанционного оборудования (GOMFSE); вторая, образованная в рамках технического комитета 57 МЭК, занималась созданием стандарта на протокол передачи данных для подстанций.

    Позднее, в 1997 году, работы обеих групп были объединены под эгидой рабочей группы 10 ТК 57 МЭК и вошли в основу стандарта МЭК 61850.

    В основе стандарта лежат три положения:

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

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

    На сегодняшний день МЭК 61850 состоит из 25 различных документов (в том числе разрабатываемых), которые охватывают широкий круг вопросов и делают его гораздо больше, чем просто спецификацией ряда коммуникационных протоколов. Отметим основные особенности стандарта [6]:

    • Определяет не только то, как должен производиться обмен информацией, но и то, какой информацией должен производиться обмен. Стандарт описывает абстрактные модели оборудования объекта и выполняемых функций. Информационная модель, лежащая в основе стандарта, представляется в виде классов объектов данных, атрибутов данных, абстрактных сервисов и описания взаимосвязей между ними.
    • Определяет процесс проектирования и наладки систем.
    • Определяет язык описания конфигурации системы (System Configuration description Language – SCL). Данный язык обеспечивает возможность обмена информацией о конфигурации устройств в стандартизованном формате между программным обеспечением различных фирм-производителей.
    • Описывает методики испытаний и приемки оборудования.

    Работая с МЭК 61850, необходимо понимать, что стандарт:

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

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

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

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

    ЛИТЕРАТУРА

    1. Баглейбтер О.И. Трансформатор тока в сетях релейной защиты. Противодействие насыщению ТТ апериодической составляющей тока КЗ // Новости ЭлектроТехники. 2008. № 5(53).
    2. Schaub P., Haywood J., Ingram D., Kenwrick A., Dusha G. Test and Evaluation of Non Conventional Instrument Transformers and Sampled Value Process Bus on Powerlink’s Transmission Network. SEAPAC 2011. CIGRE Australia Panel B5.
    3. Шевцов М. В. Передача дискретных сигналов между УРЗА по цифровым каналам связи // Релейщик. 2009. № 1.
    4. Schwarz K. Comparison of IEC 60870-5-101/-103/-104, DNP3, and IEC 60870-6-TASE.2 with IEC 61850 (электронный документ: http://bit.ly/NOHn8L).
    5. Brunner C., Apostolov A. IEC 61850 Brand New World. PAC World Magazine. Summer 2007.
    6. IEC 61850-1: Introduction and Overview.

    © ЗАО "Новости Электротехники"
    Использование материалов сайта возможно только с письменного разрешения редакции
    При цитировании материалов гиперссылка на сайт с указанием автора обязательна

    Читайте также:  Авито продажа сварочных аппаратов бу

    Компания «ФИОРД», г. Санкт-Петербург

    В США и в Европе в конце восьмидесятых годов начали разрабатываться унифицированные открытые протоколы для устройств и систем автоматизации (в первую очередь для телемеханики), наиболее известными из которых стали DNP3, UCA и стандарты серии IEC 60870. В чем была причина и движущая сила этого процесса? Дело в том, что на рынке сложилась ситуация параллельного использования множества несовместимых частнофирменных протоколов различных производителей. Аналогичная ситуация имела место и в Советском Союзе, а затем и в России, где получили распространение множество протоколов для телемеханики, таких, как ТМ-120, ТМ-320, ТМ-512, ТМ-800А, ВРТФ-3, КОМПАС-ТМ, АИСТ, ГРАНИТ, УТК-1, УТМ-7, АПТ-2, СКП, РКП, КМА и др. Это порождало серьезные проблемы совместимости при создании и сопровождении систем управления. В связи с этим назрела потребность в создании унифицированного открытого протокола для устройств и систем (в том числе систем телемеханики), позволяющего работать со всем разнообразием объектов автоматизации.

    Таблица 1. Стандарты серии IEC 60870

    Протокол DNP (Distributed Networking Protocol) с 1990 года разрабатывался в компании Westronic, Inc., которая после нескольких поглощений стала известна как GE Harris. В 1993 году права на третью версию протокола – DNP 3.0 перешли к DNP Users Group (www.dnp.org). Первоначально DNP3 позиционировался как протокол для последовательных каналов, но затем (в 1998 году) стал поддерживать работу по Ethernet (TCP или UDP). DNP разработан для взаимодействия между устройствами и системами управления в энергетической, нефтегазовой отраслях, в системах водоснабжения и безопасности. На сегодняшний день DNP3 наиболее популярен в Северной Америке, Австралии и Южной Африке. DNP3 базируется на варианте протокола IEC 60870-5 в том виде, каким он был в 1992 году. В частности, DNP3 использует ряд решений из IEC 60870-5-1 и -2. Например, на канальном уровне используется FT3 – один из четырех форматов фрейма IEC 60870-5. Отметим, что DNP3 поддерживается в среде ISaGRAF несколькими производителями PLC и RTU, например, компаниями Kingfisher (http://www.cse-semaphore.com) и MultiTrode (www.multitrode.com). Протокол UCA (Utility Communications Architecture, http://www.ucaiug.org/aboutUCAIug/default.aspx) начал разрабатываться в 1988 году под эгидой ERPI (Electric Power Research Institute, США) и IEEE (Institute of Electrical and Electronics Engineers). Впоследствии усилия этих организаций по разработке протокола UCA легли в основу стандарта IEC 61850 «Сети и системы связи на подстанциях». Многие ученые находят ряд близких концептуальных идей в IEC 61850 и IEC 61499 [1] (напомним, что стандарт IEC 61499 реализован в ISaGRAF 5) и поэтому предлагают использовать инструментальные средства, поддерживающие IEC 61499, для реализации подходов, предлагаемых в IEC 61850 [2,3].

    Таблица 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 со стороны контролируемого (slave) устройства путем написания простой библиотеки на Arduino.

    Что такое МЭК 870-5-104 это и где применяется?

    МЭК 60870-5-104 – протокол телемеханики, предназначенный для передачи сигналов ТМ в АСТУ, регламентирующий использование сетевого доступа по протоколу TCP/IP. Чаще всего применяется в энергетике для информационного обмена между энергосистемами, а также для получения данных от измерительных преобразователей (вольтметры, счетчики электроэнергии и прочее).

    Стэк протокола МЭК 670-5-104:

    Используемые материалы

    • плата Arduino UNO;
    • Ethernet shield (HR911105a);
    • в роли мастера МЭК 60870-5-104 будет выступать MicroScada от ABB;
    • Wireshark для анализа трафика.

    Краткое описание этапов работы

    Подготовка

    • Подключена плата Arduino к ПК;
    • Настроен соответствующим образом сетевой интерфейс;
    • Настроена контролирующая (master) станция (добавлена 104 линия и добавлено контролируемое (slave) устройство).

    Термины и сокращения

    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 типа формата для передачи:

    • I-формат для передачи данных телеметрии;
    • S-формат для передачи квитанций;
    • U-формат для передачи посылок установления связи и тестирования канала связи.

    После успешного «тройного рукопожатия» контролирующая (master) станция посылает APDU STARTDT (старт передачи данных). STARTDT инициирует для контролируемой (Slavе) станции разрешение передачи блоков ASDU (кадров I) в направлении контролирующей (master), для продолжения работы необходимо подтвердить STARTDT, если контролируемая (Slavе) станция готова к передаче блоков данных. Если контролируемая (slave) станция не подтверждает выполнение STARTDT то контролирующая (master) станция вызывает обязательное закрытие IP- соединения.

    Таким образом далее необходимо считать байты полученные от контролирующей (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. Запрос на общий опрос станции

    Команда опроса C_IC ACT запрашивает полный объем или заданный определенный поднабор опрашиваемой информации на КП. Поднабор (группа) выбирается с помощью описателя опроса QOI.
    Команда опроса станции требует от контролируемых станций передать актуальное состояние их информации, обычно передаваемой спорадически (причина передачи = 3), на контролирующую станцию с причинами передачи от до . Опрос станции используется для синхронизации информации о процессе на контролирующей станции и контролируемых станциях. Он также используется для обновления информации на контролирующей станции после процедуры инициализации или после того, как контролирующая станция обнаружит потерю канала (безуспешное повторение запроса канального уровня) и последующее восстановление его. Ответ на опрос станции должен включать объекты информации о процессе, которые запомнены на контролируемой станции. В ответ на опрос станции эти объекты информации передаются с идентификаторами типов , , , , , , , или и могут также передаваться в других ASDU с идентификаторами типов от до , , , от до и с причинами передачи — периодически/циклически, — фоновое сканирование или — спорадически.

    APDU C_IC_NA_1 кроме блока APCI так же имеет блок ASDU (блок данных прикладного уровня), которые вместе формируют Протокольный Блок Данных Прикладного Уровня APDU.

    Рассмотрим более подробно полученный APDU.

    • В первом байте указан тип 0 означающий, что это команда опроса;
    • Во втором длина APDU 14 байт;

    ASDU:

    • Первый байт в блоке ASDU определяет тип объекта информации, в данном случае C_IC_NA_1 (общий опрос станции);
    • Второй структуру блока данных;
    • Третий причину передачи (CauseTx), значение шесть означает запрос на активацию;
    • Четвертый общий адрес стануии;
    • Пятый адрес контролируемой (slave) станции;
    • С шестого по восьмой адрес объекта информации равен нулю;
    • Девятый информационный байт — QOI — описатель запроса, имеющий следующие значения:

    В ответ на C_IC_NA_1 необходимо ответить подтверждением на запрос, передать объекты информации о процессе, которые запомнены на контролируемой станции и завершить активацию.
    Для отправки подтверждения необходимо в ASDU C_IC_NA_1 записать в байт указывающий на причину передачи (CauseTX) значение равное 7, для оправки завершения активации необходимо записать в байт указывающий на причину передачи (CauseTX) значение равное 10.

    После обновления скетча наблюдаем следующий порядок обмена:

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

    Простой алгоритм определения качества сигнала:

    • Если используется замещение действующего сигнала то выставляются флаги BL(блокировка) и SB(замещение);
    • Если значение сигнала не изменялось в течении контрольного промежутка времени то выставляется флаг NT(не актуальное);
    • Если имеется признак неработоспособности узла или устройства более нижнего уровня (датчик или прочее) то выставляется флаг IV(не достоверное значение).

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

    • ТС-начиная с 4096;
    • ТИ-начиная с 8192;
    • ТУ-начиная с 20480.

    Для передачи значения сигналов в массив для отправки используется библиотека EEPROM:

    И так получив 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 не ответить подтверждением то соединение будет разорвано.

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