Журнал «ИСУП». (Информатизация и системы управления в промышленности)
ИТ, КИПиА, метрология, АСУ ТП, энергетика, АСКУЭ, промышленный интернет, контроллеры, экология, электротехника, автоматизации в промышленности, испытательные системы, промышленная безопасность

Некоторые особенности реализации стандарта IEC-60870-5-104 в системе программирования контроллеров ISaGRAF: от теории к практике

В статье рассматриваются особенности реализации компанией «ФИОРД» стандарта IEC 60870-5-104 в системе программирования контроллеров ISaGRAF. Основная область применения ISaGRAF с поддержкой 60870-5-104 – энергетика, а также трубопроводный транспорт и распределенные системы, требующие использования конфигурируемых протокольных шлюзов. Приводятся необходимые сведения базовых и обобщающих стандартов серии 60870 («Устройства и системы телемеханики») для того, чтобы, с одной стороны, была понятна техническая сторона разработки, а с другой стороны, была возможность согласовать параметры взаимодействия устройств различных производителей при реализации конкретных проектов (в соответствии с главой 9 в IEC 60870-5-104 «Возможность взаимодействия (совместимость)»). Отмечается, что поддержка в ISaGRAF двух современных стандартов IEC 61499 и IEC 60870-5-104 открывает уникальную возможность для отечественных производителей создавать ISaGRAF-контроллеры нового поколения для энергетики и других отраслей.

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

fiord.jpg



Открытые протоколы: IEC 60870, DNP3 и UCA

скачать pdf >>

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

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

pic1.jpg


Протокол 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

pic2.jpg


В Европе и в России наибольшее распространение получил стандарт IEC 60870. IEC 60870 – это серия стандартов, разработанная Техническим комитетом 57 (Рабочая группа 03) Международной электротехнической комиссии (МЭК, IEC – International Electrotechnical Commission) с целью обеспечить открытый протокол для передачи управляющих и информационных данных телемет­рии. Первоначально все стандарты в этой серии обозначались как IEC 870-xx, но впоследствии была добавлена приставка ‘60’ и стандарты стали обозначаться как IEC 60870-xx. Для простоты (и единообразия) будем в дальнейшем в тексте использовать обозначение стандартов в виде IEC 60870. Серия стандартов предназначена в первую очередь для приложений в энергетике, но широко используется и в других отраслях (например, в трубопроводном транспорте). Первые базовые стандарты в рамках IEC 60870 начали появляться с 1988 года и вылились в публикацию в 1995 году профиля IEC 60870-5-101, который «распространяется на устройства и системы телемеханики с передачей данных последовательными двоичными кодами для контроля и управления территориально распределенными процессами». По мере развития сетевых технологий IEC 60870-5 стал предусматривать использование протокола TCP/IP. В табл. 1 показана общая структура серии стандартов IEC 60870 с указанием года публикации. К этой информации следует добавить ссылки на соответствующие (идентичные) отечественные стандарты, которые приведены в табл. 2, а также немногочисленные книги по данной тематике [4, 5].

pic3.jpg

Рис. 1. Пример системы на базе IEC 60870-5-104

В связи 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. Сравнение сетевых моделей (стеков)

pic4.jpg



Протокольный стек IEC 60870-5

Протоколы серии 60870-5 основаны на трехуровневой модели, называемой «Архитектура повышенной производительности» (EPA, Enhanced Performance Architecture), определенной в МЭК 60870-5-3 и являющейся упрощенным вариантом семиуровневой модели ИСО/МЭК 7498-1. Архитектура EPA была разработана с целью получения более быстрого времени реакции для критической информации, но с ограниченными услугами (табл. 3). Обычно в модель EPA добавляют еще один уровень – «Процесс пользователя». Мотивация этого следующая: данный уровень добавляется, чтобы представить различные функции или процессы, которые должны быть обязательно определены, чтобы предусмотреть способность к взаимодействию между оборудованием системы телемеханики.

Протоколы в рамках IEC 60870-5-104 дополнительно к EPA включают сетевой и транспортный уровни ИСО/МЭК 7498-1, основанные на выборке из TCP/IP в соответствии с RFC 2200 (табл. 3, 4).
В результате стек протокола IEC 60870-5-104 имеет структуру, показанную в табл. 5.

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

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

Таблица 4. Избранные стандартные позиции TCP/IP в соответствии с RFC 2200
для протокола IEC 60870-5-104


pic5.jpg


Таблица 5. Стек протокола IEC 60870-5-104

pic6.jpg

Сервисные процедуры и примитивы – функции канального уровня, предоставляющие сервисы более высоким уровням. Существует три основных типа сервисов на канальном уровне: Send/no reply, Send/confirm, Request/respond. Send/no reply используется для рассылки широковещательных сообщений, send/confirm – для квитируемой посылки команд управления, request/respond – для получения данных от ведомой станции.

Таблица 6. Структура ASDU

pic9.jpg



Структура сообщения прикладного уровня в IEC 60870-5-104

Для дальнейшего изложения нам понадобится использовать несколько сокращений, используемых в стандарте IEC 60870-5-104:
- APCI – управляющая информация прикладного уровня.
- ASDU – блок данных прикладного уровня.
- APDU – протокольный блок данных прикладного уровня.

Кроме того, для краткости мы будем иногда использовать обозначение T101 для протокола IEC60870-5-101 и соответственно T104 для IEC 60870-5-104.
В T104 процессы прикладного уровня взаимодействуют посредством обмена APDU, состоящих из двух элементов – APCI и ASDU (рис. 2). Для задания начала и конца ASDU каждый заголовок APCI включает следующие маркировочные элементы: стартовый символ, указание длины ASDU и поля управления. Может быть передан либо полный APDU, либо только APCI (для целей управления).

Таблица 7. Значения стандартных идентификаторов типа

pic7.jpg



pic8.jpg
Рис. 2. APDU протокола IEC 60870-5-104

Стартовый символ ‘68H’ определяет точку начала внутри потока данных. Длина APDU определяет длину тела APDU, которое состоит из четырех байтов поля управления APCI плюс ASDU (максимум 249 байтов). Поле управления определяет управляющую информацию для защиты от потерь и дублирования сообщений, для указания начала и конца пересылки сообщений, а также для контроля транспортных соединений. Механизм счетчика поля управления определяется в соответствии с рекомендациями X-25 МСЭ-Т («Стык между ООД и АКД, работающих в пакетном режиме и подключенных к сети общего пользования с помощью выделенного канала»). Возможны три формата поля управления: передача информации с нумерацией (формат I), контроль с нумерацией (формат S) и управление без нумерации (формат U).
В общем случае ASDU имеет следующую структуру, показанную в табл. 6.

Таблица 8. Семантика обозначения идентификаторов типа

pic10.jpg


pic11.jpg

Рис. 3. Пример конфигурирования драйвера IEC 60870-5-104 Slave в ISaGRAF

Идентификатор типа однозначно определяет тип ASDU и занимает один байт. Он может принимать значения в диапазоне от 1 до 255: 1..127 – стандартные типы, 128..255 – зарезервированы для использования самостоятельно производителями (то есть значения в этом диапазоне не определяются стандартом). Стандартные идентификаторы типа можно разделить на несколько групп, как это показано в табл. 7.

Таблица 9. Реализованные в драйвере ISaGRAF стандартные идентификаторы типа ASDU

pic12.jpg


В стандарте, как правило, используется содержательная мнемоника для обозначения идентификаторов типа, которые имеют иерархическую структуру (см. табл. 8). Например, M_ME_TA_1 означает нормализованное (_xA) значение измеряемой величины (M_) с меткой времени (_Tx). 
Классификатор переменной структуры имеет длину один байт и определяет число объектов, одиночных, комбинации или последовательности элементов информации.

Причина передачи занимает один или два байта и имеет следующую структуру: код причины передачи (6 бит), бит P/N, бит T и байт опционального значения адреса инициатора. Код причины передачи может принимать значения от 1 до 63 (из них в стандарте определены только 47 значений), бит P/N – 0 (положительное) или 1 (отрицательное) подтверждение, T – 0 (не тест) или 1 (тест). Семантика причин передачи довольно разно­образна и может определять спорадическую и циклическую передачу, старт/рестарт, общий опрос, тестовый режим, синхронизацию времени, включение питания и другие виды причин передач.

pic13.jpg

Рис. 4. Коммуникационный ISaGRAF-контроллер ФИОРД-201Э для энергетики
с поддержкой протоколов IEC 60870-5-104 и Modbus RTU/TCP

Общий адрес ASDU – это адрес станции длиной 1 или 2 байта, который может быть структурирован, чтобы иметь возможность обращаться ко всей станции или к отдельному ее сектору. 
Адрес объекта информации может иметь длину от 1 до 3 байтов.

Набор элементов информации состоит из одиночного элемента информации (ЭИ), комбинации или последовательности ЭИ, которые определены в IEC 60870-5-4. Элементы информации могут содержать описатель качества, который состоит из битов (флагов) качества, которые устанавливаются независимо друг от друга и обеспечивают контролирующую станцию дополнительной информацией. Позиционные биты описателя качества сообщают о различных состояниях объекта информации, например, OV – значение находится вне заранее определенного диапазона значений, BL – значение блокировано для передачи локальным блокирующим устройством или автоматически, IV – недействительное значение, SB – значение поступает на вход или от оператора или от автоматического источника, NT – значение не обновлялось течение заданного промежутка времени или недоступно и так далее.


Реализация протокола IEC 60870-5-104 в ISaGRAF

Наконец мы в достаточной мере рассмотрели теоретическую часть вопроса и можем остановиться на конкретной реализации протокола IEC 60870-5-104 в среде инструментальной системы программирования контроллеров ISaGRAF [6] c целевой задачей ISaGRAF 5++ ACE Target [7]. Драйвер IEC 60870-5-104 поддерживает Slave составляющую протокола, в том числе циклическую, фоновую и спорадическую передачу данных. Настройка всех параметров драйвера осуществляется через XML-файл. Конфигурирование драйвера выполняется непосредственно в среде ISaGRAF Workbench через диалоговое окно «Монтаж ВВ/Выбор Устройства», в котором находится список простых устройств ISaGRAF (рис. 3).

Укажем некоторые конкретные характеристики реализованного драйвера:
Режим передачи прикладных данных: используется только режим 1 (младший байт передается первым), как определено в МЭК 60870-5-4 (подпункт 4.10).
Общий адрес ASDU: 2 байта. 
Адрес объекта информации: 3 байта, неструктурированный. 
Причина передачи: 2 байта (с адресом источника). Если адрес источника не используется, то он устанавливается в 0.
Максимальная длина APDU равна 253 (по умолчанию).
Выбор реализованных в драйвере стандартных идентификаторов типа ASDU показан в табл. 9.

Возможные комбинации идентификатора типа и причины передачи показаны в формуляре согласования приема / передачи данных согласно МЭК 60870-5-104, приведенном на сайте компании «ФИОРД» (http://download.fiordpro.ru/isagraf/isaiec104_compatib.pdf). В нем приняты следующие обозначения: черный прямоугольник – опция, не разрешенная в стандарте, серый прямоугольник – опция не требуется, пустой прямоугольник – сочетание в данной реализации не используется. Маркировка используемых сочетаний «Идентификатора типа» и «Причины передачи»: X – сочетание используется в направлении, как указано в стандарте; R – сочетание используется в обратном направлении; B – сочетание используется в стандартном и обратном направлениях.

Реализованные функции прикладного уровня: удаленная инициализация вторичной станции, циклическая передача данных, процедура чтения, спорадическая передача, опрос станции (общий и по группам), синхронизация времени, несколько команд прямой передачи команд, полный набор команд передачи интегральных сумм, процедура тестирования, фоновое сканирование.
Во всех случаях для связи по TCP/IP для связи между станциями используется порт 2404.

В качестве первичной составляющей (Master) протокола IEC 60870-5-104 могут использоваться различные продукты, например, такие: IECTest (РТСофт) или CybServer (Cybectec). Драйвер IEC 60870-5-104 Slave прошел тестирование специалистами филиала ГТ-ТЭЦ Энерго в составе ПЛК «ФИОРД-201Э» под управлением ОС Linux. «ФИОРД-201Э» (рис. 4) поддерживает протоколы 60870-5-104 и Modbus RTU/TCP. Также следует отметить, что в настоящее время специалистами компании «ФИОРД» разработан собственный драйвер IEC 60870-5-104 Master, который находится в стадии бета-версии.

Обратим внимание на еще одно очень перспективное применение ISaGRAF 5++ ACE Target с драйверами 60870-5-104 и Modbus RTU/TCP – использование его в качестве удобной программной платформы для создания шлюзов различной мощности и масштабируемой функциональности. Апробация такого шлюза была успешно проведена на аппаратных платформах MOXA и ПЛК «ФИОРД-101».


Заключение

Особую перспективность описываемой в статье разработке придает поддержка в ISaGRAF инновационного стандарта IEC 61499 [8], предназначенного для унификации правил создания распределенных приложений и применения функциональных блоков в системах управления. Объединенные усилия специалистов компаний ICS Triplex ISaGRAF (www.isagraf.com) и «ФИОРД» (www.fiord.com) обеспечивают поддержку в ISaGRAF двух современных протоколов IEC 61499 и IEC 60870-5-104, что открывает реальную возможность отечественным производителям создавать ISaGRAF-контроллеры нового поколения для энергетики и других отраслей.


Литература

1_Rogerio Dias Paulo (EFACEC Engenharia, S.A., Portugal), Functional Integration in Substation Automation Systems: System Tools and Interoperability. 
2_Karlheinz Schwarz, IEC 61850 beyond Substations – The Standard for the whole Energy Supply System. 
3_Neil Higgins, Valeriy Vyatkin, Nirmal-Kumar C Nair and Karlheinz Schwarz, Distributed Power System Automation with IEC 61850, IEC 61499 and Intelligent Control.
4_Gordon Clarke, Deon Reynders, Practical Modern SCADA Protocols: DNP3, 60870.5 and Related Systems, Newnes, 2004-09.
5_David Bailey, Edwin Wright, Practical SCADA for Industry, Newnes, 2003
6_Колтунцев А.В., Золотарев С.В. ISaGRAF 5 – основа для создания распределенных приложений в среде программируемых контроллеров на базе стандарта IEC61499 // Промышленные АСУ и контроллеры. 2008. № 12. 
7_А.В.Яковлев, А.В.Липовец, С.В. Золотарев, Расширения ISaGRAF 5: инновационные функциональные возможности, производительность и открытость // ИСУП. 2009. № 2.
8_А.В.Колтунцев, С.В. Золотарев. Среда программирования контроллеров ISaGRAF 5 и некоторые современные подходы построения распределенных систем управления в энергетике // Автоматизация и ИТ в энергетике. 2009. № 2.

Статья опубликована в журнале «ИСУП», № 4(28)_2010

С.В. Золотарев, к.т.н., ведущий эксперт, 
компания «ФИОРД», г. Санкт-Петербург,
тел.: +7(812) 323-6212,
e-mail: info@fiord.com