Многие инженеры автоматизации обращали внимание на «анархию протоколов», которая сложилась на рынке систем учета энергоресурсов. Количество протоколов, используемых в таких системах, равно (а скорее даже превышает) количеству производителей устройств – каждый из них использует собственный протокол обмена. При этом электросчетчики измеряют одни и те же параметры электросети, теплосчетчики - параметры теплосети, приборы используют одни и те же интерфейсы связи – но почему же протоколы у всех разные? Неужели нельзя использовать какой-либо стандартный протокол? О таком протоколе и пойдет речь в данной статье.
Главная причина того, что производители устройств систем учета разрабатывают собственные протоколы в том, что стандартные промышленные протоколы мало подходят для данной отрасли. Возьмем, к примеру, открытый и распространённый протокол Modbus. Он имеет целый ряд недостатков:
Не стандартизированы типы передаваемых данных – по протоколу идут 2 байтовые регистры, за которыми может скрываться что угодно, и как-либо идентифицировать получаемые данные невозможно.
Нет возможности передачи архивных данных. Да, есть возможность передачи файлов функцией 0x14, но она сложна в реализации и не очень хорошо подходит для передачи, например, часовых срезов.
Отсутствие хоть какой-то безопасности – в Modbus отсутствует аутентификация и шифрование, что является важным для систем учета.
Несмотря на это, ряд производителей используют транспорт Modbus в качестве протокола передачи данных – например компания Взлет. Но даже в этом случае используется собственная модификация протокола - например, для передачи архива используется нестандартная функция 65, с собственной структурой кадра.
Таким образом, использовать Modbus для систем учета не представляется возможным в полной мере. Необходим новый стандарт, который был бы изначально ориентирован на данную отрасль.
Впервые данной проблемой озаботились в Европе в конце 90-х годов. Для ее решения была создана ассоциация DLMS (Distribution Line Message Specification), со штаб-квартирой в городе Цуг (Швейцария).
Целью организации было разработать новый протокол, способный решать все задачи по передаче данных в системах учета и стать стандартом отрасли. Протокол получил название DLMS и имеет следующие особенности:
Возможность работы со всеми приборами учета – несмотря на то, что изначально протокол разрабатывался для учета электроэнергии, его функционал позволяет использоваться в системах учета воды, тепла и газа.
Фиксированная структура кадра, содержащая ряд дополнительных атрибутов – номер клиента, номер сервера, идентификатор сообщения. Это позволяет исключить «перепутывание» запросов, и сделать гибкую модель авторизации.
Различные варианты аутентификации – в зависимости от уровня подключения ограничивается доступ к тем или иным параметрам.
Современные механизмы шифрования – если обмен идет по не защищенным линиям связи, есть возможность зашифровать данные и исключить их перехват или подмену.
Объектно-ориентированный подход – в DLMS данные хранятся и передаются в виде объектов-классов (IC – interface class), которые имеют определенные атрибуты (шкала, единица измерения, время фиксации). Разные типы классов нацелены на хранение и передачу разных параметров устройства – абстрактных данных, текущих значений, значений с меткой времени (например, фиксация максимума мощности) или архивов.
Передача типа данных вместе со значением – при запросе возвращается не только значение, но также тип данных, в котором он представлен. Это позволяет производителю устройства хранить данные в удобном для него формате, а клиентскому ПО корректно идентифицировать полученные данные.
Возможность получения из устройства полного списка поддерживаемых параметров.
Жестко фиксированные идентификаторы параметров – это, пожалуй, главное преимущество протокола. Остановится на них подробнее.
Все параметры (объекты) прибора имеют специальный идентификатор – OBIS код. OBIS код представляет собой 6-значное число, разделенное точками (A.B.C.D.E.F), например - 1.0.31.7.0.255. Каждый из разрядов числа определяет какой-либо свойство параметра устройства. Например, атрибут A определяет вид энергии: 0 – абстрактные параметры (время, производитель), 1 – электроэнергия, 4 – тепло, 7 – газ и т.д. Атрибут C – назначение параметра, например, для электросчетчиков, 1 – положительная активная мощность по всем фазам, 34 – частота по фазе 1. Все эти параметры прописаны в стандарте, и производитель устройства обязан использовать для параметров прибора соответствующие им идентификаторы.
Что это означает на практике? К примеру, параметр электросчетчика – «ток фазы A», в стандарте за ним закреплен OBIS - 1.0.31.7.0.255, независимо от производителя устройства, параметр «ток фазы А» всегда будет иметь именно такой идентификатор. Таким образом можно включать приборы различных производителей в единую систему учета и не беспокоится об адресации параметров – они жестко унифицированы.
В настоящий момент стандарт DLMS активно применяется в системах учета в Европе, Азии, Ближнем Востоке и поддерживается большинством производителей устройств. Среди компаний поддерживающих протокол – ABB, Carlo Gavazzi, Honeywell, Socomec, Satec (всего свыше 1000 компаний).
В России стандарт DLMS в настоящий момент продвигается ПАО «Россети» - главным оператором электросетей России. Ее усилиями стандарт DLMS был переведен на русский язык (текст можно посмотреть здесь) и назван СПОДЭС – Спецификация Протокола Обмена Данными Электронных Счетчиков. По сути это все тот же протокол DLMS, но имеющий ряд небольших отличий (не противоречащих основному стандарту) - комбинация номеров клиент-сервер определяют уровень доступа к параметрам счетчика (публичный клиент, считыватель показаний, конфигуратор), добавлены ряд национальных параметров, не входящих в основной стандарт – коэффициенты реактивной мощности, напряжение прямой и обратной последовательности и т.д.
В настоящий момент в России счетчики электроэнергии с протоколом DLMS поддерживают компании Инкотекс, Энергомера, ИЭК, НПО «МИР». Также ряд компаний находятся в процессе поддержки протокола.
Поскольку на наших глазах происходит историческое событие, которое должно положить конец «анархии протоколов», мы также решили не оставаться в стороне и первыми в стране выпустить OPC сервер с поддержкой протокола DLMS/СПОДЭС – теперь данный протокол входит в перечень поддерживаемых Multi-Protocol MasterOPC сервера.
Чтобы подключить устройство с протоколом DLMS к Multi-Protocol MasterOPC нужно через контекстное меню добавить протокол и выбрать в списке протокол DLMS.
Однако создавать несколько десятков, а то и сотен параметров – трудоемкая задача, которую мы хотели максимально упростить. В случае с DLMS, изначально у нас был вариант сделать шаблонную конфигурацию, которая содержала бы основные теги (они, как упоминалось ранее, жестко фиксированы в стандарте). Однако, хоть OBIS коды и фиксированы, но типы данных и шкалу каждый производитель может использовать по своему усмотрению – один производитель передает напряжение как float число, а другой – как целое со смещением точки. Конечно, можно эти параметры прочитать при запуске сервера, но тогда увеличится время первого опроса. Кроме того, счетчики могут отличаться по составу тегов – бывают однофазные и трехфазные модели, с 4 тарифами и с 8 (и даже больше), с функциями анализатора качества сети и без них. Поэтому мы решили сделать более сложный в реализации, но более эффективный вариант – поскольку DLMS позволяет считывать состав тегов, и его атрибуты, была разработана утилита импорта, считывающая конфигурацию параметров прямо из устройства.
Для ее запуска необходимо вызвать контекстное меню устройства – Теги протокола (импорт).
Поскольку считывание параметров из устройства может занимать значительно время, мы реализовали возможность экспорта и импорта в Excel. Таким образом считав единожды теги из устройства, можно сохранить их в Excel файл, и впоследствии работать с ним. При этом, есть возможность с помощью Excel выполнить правку файла – исправить имена тегов, изменить их иерархию, локализовать комментарии, т.е. сделать собственный шаблон устройства, который максимально удовлетворяет вашей задаче.
Теперь необходимо отметить нужные вам теги, используя флаги в дереве и/или групповое выделение, а затем нажать на кнопку Импортировать. Теги перенесутся в ОРС сервер.
Мы протестировали наш OPC сервер с основными устройствами, представленными на российском рынке - IEC Star128/328, Инкотекс Меркурий 234, Энергомера СЕ308/СЕ208. Со всеми устройствами OPC работал стабильно, во всех режимах работы.
Подробная информация о DLMS MasterOPC Server представлена на странице продукта:
Скачать Multi-Protocol MasterOPC с поддержкой протокола DLMS можно здесь: