Протокол dlms cosem сподэс что это

DLMS/COSEM – открытый протокол для обмена данными с приборами учета. Часть 1: краткий обзор

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

Решением данной проблемы является применение открытых протоколов, например, протоколов, соответствующих стандарту IEC 62056 (DLMS/COSEM).

Ссылки на опубликованные части серии публикаций

Общие сведения о стандарте IEC 62056 (DLMS/COSEM)

DLMS/COSEM это стек-ориентированный протокол базирующийся на концепциях модели OSI, регламентирующий обмен данными между приборами учета и системами сбора данных, в основе которого лежит клиент-серверная архитектура. Основополагающими спецификациями в этом стандарте являются DLMS и COSEM. Ниже приводится краткая характеристика этих спецификаций.

DLMS расшифровывается как Distribution Line Message Specification и представляет собой спецификацию прикладного уровня, которая не зависит от более низких уровней и как следствие от коммуникационных каналов. Эта спецификация была разработана для стандартизации сообщений, передаваемых по распределительным линиям. В такой нотации этот стандарт опубликован за номером IEC 61334-4-41. В последствии концепция DLMS претерпела изменения, а аббревиатура DLMS стала расшифровываться как Device Language Message Specification. Целью изменений стало обеспечение единой среды для структурного моделирования и обмена данными с приборами учета. В нынешнем виде, стандартом регламентируются: дистанционное считывание показаний с приборов учета, дистанционное управление, а также дополнительные сервисы для измерения любого вида энергоресурса (электричество, вода, газ, тепло).

COSEM расшифровывается как COmpanion Specification for Energy Metering и представляет собой спецификацию в которой отражена интерфейсная модель приборов учета, обеспечивающая представление их функциональных возможностей. Интерфейсная модель использует объектно-ориентированный подход.

В соответствии с COSEM, прибор учета представляет собой физическое устройство, состоящее из логических устройств. Каждое логическое устройство имеет уникальный идентификатор (в мировом масштабе), называемый логическим именем устройства. Информация, содержащаяся в каждом логическом устройстве, доступна посредством интерфейсных объектов. В свою очередь, доступ к интерфейсным объектам в рамках логического устройства осуществляется через объекты ассоциации. Объект ассоциации предоставляет информацию о ресурсах, имеющихся в логическом устройстве в зависимости от прав доступа.

Каждый интерфейсный объект состоит из атрибутов и методов. В атрибутах содержится информация об объекте и том функционале который он представляет. Например, для объекта, представляющего функционал «Измерение частоты электрической сети», в атрибутах будет отображаться информация о значении частоты (например, 50) и единице измерения (например, Гц). Методы, в свою очередь, позволяют изменять или просматривать значения. Например, можно сбросить значения определённых атрибутов использую метод Reset(), если таковой имеется в соответствующем интерфейсном объекте. Методы необязательно присутствуют в интерфейсных объектах.

Интерфейсные объекты, имеющие общие характеристики (одни и те же атрибуты и методы) составляют интерфейсный класс. Также справедливо и обратное, интерфейсные объекты являются экземплярами интерфейсного класса. Интерфейсный класс идентифицируется через два параметра: идентификатор класса (class_id) и версия (version). Стоит отметить что каждый интерфейсный объект, в рамках логического устройства является уникальным и однозначно идентифицирует информацию, независимым от производителя прибора учета способом, представленную этим объектом с помощью логического имени (первый атрибут любого интерфейсного объекта), идентификатора класса и его версии.

Отличие стандарта DLMS/COSEM от других стандартов обмена данными с приборами учета

Во-первых, DLMS/COSEM определяет интерфейсную модель, действительную для любого типа энергоресурса (электричество, газ, вода, тепло и др.). Каждый интерфейсный объект имеет стандартизованный уникальный идентификатор, по которому идентифицируются данные. Эта модель полностью независима от тех уровней протокола, которые осуществляют транспортировку данных. Вследствие чего система, построенная на базе протокола DLMS/COSEM открыта для расширения путем добавления новых интерфейсных классов и версий без изменения сервисов обеспечивающих доступ к интерфейсным объектам, сохраняя тем самым функциональную совместимость.

Во-вторых, определения интерфейсных классов стандартизуют ряд широко используемого функционала прибора учета: регистрация потребления (электроэнергии, тепла, воды, газа), тарифное планирование (реализация многотарифных приборов учета), измерение качества электроэнергии и др. Однозначная интерпретация данных гарантируется тем, что в атрибутах интерфейсного класса используются четко определенные типы (array, structure, boolean, integer, long и др.) информация о которых, если это необходимо, передается вместе с данными.

В-третьих, DLMS/COSEM обеспечивает контролируемый и безопасный доступ к информации внутри прибора учета для различных участников рынка энергоресурсов. DLMS/COSEM определяет три уровня доступа к прибору учета, открытый доступ (none), доступ по паролю (low level) и доступ с аутентификация (high level). Кроме того, информация, передаваемая по коммуникационным линиям может быть зашифрована, это также регламентируется стандартом.

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

В-пятых, в отличии от более старых протоколов, где (например, в случае использования IEC 61107) на каждый новый измерительный прибор были необходимы специальные драйверы для систем сбора данных, DLMS/COSEM позволяет создавать унифицированные драйверы, посредством которых, становится возможным связываться с приборами учета разных типов от различных производителей.

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

Источник

DLMS/COSEM – открытый протокол для обмена данными с приборами учета. Часть 2: интерфейсные классы, модель прибора учета

Ссылки на опубликованные части серии публикаций

Интерфейсные классы

Интерфейсные классы являются одним из ключевых элементов протокола DLMS/COSEM, обеспечивающие взаимодействия между системами сбора данных и приборами учета различных производителей. Другими словами, та самая интероперабельность систем сбора данных и приборов учета, т.е. способность взаимодействия друг с другом, достигается, в частности, за счет применения интерфейсных классов. Поскольку и система сбора данных и прибор учета имеют единое представление информации.

Прежде чем дать определение интерфейсному классу рассмотрим сначала его экземпляры, т.е. объекты COSEM. Объекты COSEM представляют собой набор атрибутов и методов. Атрибуты отражают характеристики объекта, а значения атрибутов могут влиять на поведение объекта. Первый атрибут (logical_name) любого объекта содержит в качестве значения логическое имя, которое идентифицирует объект. Методы объекта позволяют или просматривать, или изменять значения атрибутов.

Объекты имеющие общие характеристики (атрибуты и методы) составляют интерфейсный класс, т.е. интерфейсный класс дает описание характеристик, присущих всем объектам этого интерфейсного класса.

Выше сказанное иллюстрирует рисунок 1.

Рисунок 1 – Интерфейсный класс и его экземпляры

На рисунке 1 прибор учета содержит два регистра, т.е. два экземпляра интерфейсного класса «Register». Причем оба экземпляра представляют различную информацию, так объект COSEM с логическим именем представляет суммарное потребленное значение положительной активной энергии, а объект с логическим именем — суммарное потребленное значение положительной реактивной энергии. Значение этих параметров доступно при чтении атрибута value. Забегая вперед скажем, что логическое имя представляет собой OBIS код, о котором речь пойдет в конце данной публикации.

Обратиться к объекту COSEM и считать/записать определенный атрибут или выполнить определенный метод, можно двумя способами, либо через его логическое имя (LN referencing), либо через короткое имя (SN referencing).

Описание интерфейсных классов придерживается структуры, представленной на рисунке 2.

Рисунок 2 – Структура описания интерфейсного класса

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

Class name

Cardinality

Class_id

Version

Attributes

Logical name

Data type

Short name

Specific method

Тип метода: обязательный (m) или опциональный (o).

Пример интерфейсного класса «Register» приведен на рисунке 3, а его описание на рисунке 4.

Рисунок 3 – интерфейсный класс «Register»

Рисунок 4 — Описание интерфейсного класса «Register»

Все интерфейсные классы можно условно разделить на 12 групп, наименование этих групп, а также наименования классов, которые в них входят, приведены на диаграмме классов (рисунок 5 [кликабельный]).

Рисунок 5 — Диаграмма интерфейсных классов (кликабельный)

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

Модель прибора учета

В основе протокола DLMS/COSEM лежит клиент-серверная архитектура. Прибор учета выполняет роль сервера, а система сбора данных – роль клиента. Инициатором обмена информацией является система сбора данных, прибор учета лишь предоставляет требуемую информацию в ответ на запрос системы сбора данных. Однако, в определённых ситуациях сам прибор учета может инициировать обмен данными с системой сбора данных.

На рисунке 6 приведена модель прибора учета. Прибор учета представляет собой физическое устройство (COSEM physical device), в рамках которого есть, как минимум, одно логическое устройство (Management logical device). Использование нескольких логических устройств позволяет реализовать комбинированные приборы учета. Например, теплосчетчик с импульсным входом для измерения расхода воды.

Рисунок 6 – Модель прибора учета DLMS/COSEM

За адресацию как физических, так и логических устройств отвечают нижние уровни используемого стека протокола. Например, при использовании на канальном уровне протокола HDLC, адрес прибора учета представляется в виде последовательности байт, причем возможны три схемы адресации: однобайтовая (только адрес логического устройства), двухбайтовая (адрес логического и физического устройства, значение которых не превышает 127) и четырехбайтовая (адрес логического и физического устройства, значения которых превышает 127). Более подробная информация об адресации при использовании протокола HDLC находится в главе 8 зеленой книге.

Список видимых объектов COSEM находится в атрибуте object_list соответствующего объекта ассоциации.

Как было сказано ранее, в каждом физическом устройстве всегда есть хотя бы одно логическое устройство, которое называется логическое устройство управления (Management logical device). Оно имеет зарезервированный адрес (0x01) и поддерживает ассоциацию публичного клиента с самым низким уровнем секретности. Таким образом, логическое устройство управления всегда находится в открытом доступе.

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

Система идентификации объектов (OBIS код)

Группа A

Группа B

Группа С

Группа D

Группа E

Группа F

Значение этой группы определяет накопленные данные, идентифицируемые через значения групп A – E, в соответствии с различными расчетными периодами.

Значения стандартных OBIS кодов доступно для скачивания в виде excel-документа с официального сайта DLMS UA, более подробная информацию об OBIS находится в главе 7 голубой книге.

Источник

Что такое СПОДЭС и причём здесь прибор учёта электрической энергии

В октябре 2019 года вышла вторая версия спецификации СПОДЭС – корпоративного стандарта ПАО «Россети» СТО 34.01-5.1-006-2019 «Счетчики электрической энергии. Требования к информационной модели обмена данными», а в июле 2020 года Федеральное агентство по техническому регулированию и метрологии «Росстандарт» утвердило СПОДЭС в качестве национального стандарта Российской Федерации ГОСТ Р 58940-2020 «Требования к протоколам обмена информацией между компонентами интеллектуальной системы учета и приборами учета».

За один год СПОДЭС прошла путь от корпоративного стандарта до национального стандарта Российской Федерации. Однако и сегодня для многих СПОДЭС является тайной за семью печатями.

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

Содержание

Информационная модель прибора учёта электрической энергии

Если в «двух словах», то СПОДЭС – это информационная модель прибора учёта электрической энергии. Однако многие считают, что СПОДЭС это протокол, но это не так. Действительно, СПОДЭС определяет требования к протоколам передачи данных, но она не протокол.

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

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

СПОДЭС и стек DLMS/COSEM

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

Здесь есть два варианта, придумать что-то свое или взять готовое решение. Вы наверно уже догадались из названия подзаголовка, что при разработке СПОДЭС был выбран второй вариант, а именно стек DLMS/COSEM (IEC 62056).

Почему стек DLMS/COSEM? Потому что это открытый, стандартизированный набор протоколов для приборов коммерческого учёта, имеющий средства проверки на совместимость.

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

Объектная модель COSEM позволяет описать функциональность прибора учёта в виде объектов COSEM, являющимися экземплярами стандартных интерфейсных классов, описанных в Blue Book DLMS UA. Измеряемые и учитываемые параметры, журналы, паспортные данные, тарификация, управление нагрузкой абонента и многое другое представляется в виде объектов COSEM. Доступ к этим объектам осуществляется с помощью протокола прикладного уровня DLMS.

Cтек DLMS/COSEM имеет трёхуровневую сетевую модель: прикладной, промежуточный и физический уровни. Комбинация промежуточного и физического уровней образует коммуникационный профиль. На сегодняшний день определены шесть коммуникационных профилей:

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

Если ни один из стандартных коммуникационных профилей вас не устраивает, вы можете описать свой специализированный коммуникационный профиль. О том, как это сделать написано в стандарте IEC TS 62056-1-1:2016.

Стек DLMS/COSEM по природе своей избыточен и требует уточнений, например, какие именно использовать коммуникационные профили, какие использовать способы аутентификации при установлении соединения, как адресовать объекты COSEM, как защищать информацию и др. Все это уточняется в информационной модели прибора учёта. В нашем случае в СПОДЭС.

СПОДЭС

Документы СТО 34.01-5.1-006-2019 и ГОСТ Р 58940-2020 несколько различаются, поэтому для краткости СТО 34.01-5.1-006-2019 будем называть СПОДЭС СТО, а ГОСТ Р 58940-2020 – СПОДЭС ГОСТ.

В СПОДЭС СТО определен один коммуникационный профиль – это профиль на базе протокола HDLC (IEC 62056-7-6:2013). На физическом уровне используется интерфейс RS-485 и оптопорт. Оптопорт, в свою очередь, может поддерживать режим Mode E, позволяющий автоматически согласовывать скорость передачи данных в момент установления соединения. В СПОДЭС ГОСТ, в дополнение к коммуникационному профилю на базе протокола HDLC, прописали еще два коммуникационных профиля: TCP-UDP/IP (IEC 62056-9-7:2013) и PLC OFDM G3 (IEC 62056-8-5:2017). Первый применяется если обмен данными идет по каналам сотовой связи (GPRS, 3G, LTE) или если используется интерфейс Ethernet. Второй применяется, когда данные передаются по линиям электропередач.

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

Каждый прибор учёта, соответствующий спецификации СПОДЭС СТО имеет три типа соединения, через которые реализуется ограничение прав доступа. Все они приведены в таблице ниже.

Идентификатор клиента – это поле Client address (см п. 8.4.2.2 Green book DLMS UA 1000-2 Ed. 8.0) для коммуникационного профиля на базе протокола HDLC или Client side address (см п. 7.3.3.4 Green book DLMS UA 1000-2 Ed. 8.0) для коммуникационного профиля TCP-UDP/IP.

Для соединения типа Публичный клиент не применяется процедура аутентификации при установлении соединения и доступна только операция чтения (GET). Соединившись в этом режиме, максимум что вы можете сделать, это узнать серийный номер устройства и текущее время. Чтобы считать всю доступную информацию из прибора учёта необходимо использовать тип соединения Считыватель показаний. В этом случае, при установлении соединения применяется аутентификация по паролю и наряду с операцией чтения (GET), также становятся доступны селективная выборка (Selective Access), выполнение действий в приборе учёта (ACTION) и чтение данных блоками (GET with Block Transfer).

Конфигурирование прибора учёта разрешено только для соединения типа Конфигуратор. В этом случае, при установлении соединения применяется четырёхэтапная процедура аутентификации (см. п. 9.2.2.2.2.4 Green book DLMS UA 1000-2 Ed. 8.0), при которой пароль в явном виде не передается, в отличие от типа соединения Считыватель показаний. В четырёхэтапной процедуре аутентификации применяется алгоритм AES-128 и режим GMAC: mechanism_id(5).

Защита данных и проверка их подлинности осуществляет стандартным набором безопасности Security suite 0 (см. п. 9.2.3.7 Green book DLMS UA 1000-2 Ed. 8.0) только для соединений типа Считыватель показаний и Конфигуратор. При шифровании и аутентификации данных применяется алгоритм AES-128 в режиме GCM, а для передачи ключей – AES-128 key wrap.

В СПОДЭС ГОСТ поменяли алгоритмы шифрования и аутентификации, теперь вместо AES-128 в режиме GMAC применяется ГОСТ 34.12-2018 («Кузнечик») в режиме CMAC, вместо AES-128 в режиме GCM применяется ГОСТ 34.12-2018 («Кузнечик») в режиме CTR, а вместо AES-128 key wrap используется KExp15 и KImp15 определенные в Р 1323565.1.017-2018 на основе блочного шифра ГОСТ 34.12-2018 («Кузнечик»).

Также для типа соединения Считыватель показаний теперь обязательна аутентификация данных, а для Конфигуратора – аутентификация и/или шифрование. В СПОДЭС СТО это было опционально.

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

Особенности приборов учёта, которые соответствуют СПОДЭС:

В помощь программисту

Дорогой друг, если перед тобой стоит задача реализовать прибор учёта, соответствующий СПОДЭС, начни с изучения цветных книг ассоциации DLMS UA. В зеленой книге ты найдешь информацию о протоколе DLMS, способах аутентификации при установлении соединения, способах защиты конфиденциальных данных и описание коммуникационных профилей. В первую очередь смотри коммуникационный профиль на базе протокола HDLC, потому что он применяется в СПОДЭС и тестирование на совместимость реализовано только для него.

Кстати, протестировать свой прибор учёта можно с помощью Сертификационной утилиты. Если вдруг какой-то тест завершится неудачей, не отчаивайся и полистай желтую книгу DLMS UA. В ней ты найдешь описание тестов и узнаешь, как сделать так, чтобы тест был успешно пройден.

В голубой книге ты найдешь описание стандартных интерфейсных классов и описание OBIS-кодов.

После того как ты станешь уверенным знатоком стека DLMS/COSEM смело открывай спецификацию СПОДЭС и создавай самый лучший, интероперабельный прибор учёта электрической энергии.

Источник

Протокол DLMS/COSEM, СПОДЭС (ГОСТ Р 58940-2020)

Содержание

Описание

DLMS/COSEM – открытый протокол для обмена данными с приборами учета. На его основе был выпущен стандарт СПОДЭС (ГОСТ Р 58940-2020).

Настройка в веб-интерфейсе контроллера Wiren Board

Протокол поддерживается драйвером wb-mqtt-serial. Для некоторых устройств, работающих по протоколам DLMS/COSEM и СПОДЭС мы сделали готовые шаблоны, но если нужного устройства среди них нет, то вы можете настроить подключение самостоятельно.

Устройство без шаблона

Создайте новое устройство и заполните параметры подключения.

Параметры подключения

Поле	Описание
Slave id	Физический адрес устройства. Опрашивается логическое устройство с адресом 1.
DLMS client address	Адрес клиента. По умолчанию — 16, публичный клиент.
DLMS authentication mode	Тип аутентификации. ПО умолчанию — без аутентификации.
DLMS interface	Коммуникационный профиль. По умолчанию — HDLC.

Добавьте в устройство пользовательские каналы.

Генерация шаблона

В драйвере wb-mqtt-serial реализован анализ доступных объектов устройства и генерация шаблона.

Теперь добавьте новое устройство и выберите сгенерированный ранее шаблон.

Пример команд для генерации шаблона:

Источник