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

Введение

В связи с закреплением протокола DLMS/COSEM в нашей стране в виде стандарта СТО Россетей [1] и ГОСТ [2] представляется возможным расширение его использования в отечественных приборах учета электроэнергии. Но, не касаясь целесообразности этого вопроса, нелишним и актуальным будет написание русскоязычного руководства по работе с данным протоколом для заинтересованных инженеров и программистов встроенных систем. Понимание тонкостей его работы позволит расширить круг разработчиков и инженеров, способных его поддерживать.

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

Руководствами для выполнения работы служили уже упомянутые стандарты Россетей и ГОСТ [1,2], а также описывающие стандарт DLMS/COSEM документы [3, 4] (Синяя и Зеленая книги). Так как тестирование проводились на коммуникационном профиле HDLC, то вся дальнейшая информация относится только к этому профилю.

1. Описание модели взаимодействия клиента и сервера

Протокол DLMS/COSEM уже несколько раз был освещен на хабре в статьях [5,6]. В них дан общий обзор уровней протокола [5] и детальный обзор модели COSEM, представляющей собой логическую модель прибора учета [6]. В данной работе будет более подробно рассмотрена работа нижележащих уровней (промежуточного и канального).

В соответствии со стандартом взаимодействие происходит в клиент-серверном режиме путем обмена запросами и ответами. Сервер (прибор учета) предоставляет, а клиент (система АСКУЭ) запрашивает определенный набор функционала, называемый сервисами (service). Примеры сервисов: COSEM-OPEN – сервис для установления соединения, COSEM-GET – сервис для получения данных с сервера.

Сервисы разделены на две большие группы: сервисы для установления соединения (AA – application association) и сервисы для обмена данными.

К сервисам для установления соединения относятся:

• COSEM-OPEN – установление соединения

• COSEM-RELEASE – завершение соединения

• COSEM-ABORT – принудительный разрыв соединения.

Именно их реализация рассмотрена в данной части.

К сервисам для обмена данными относятся:

• Использующие LN-имена: GET, SET, ACTION

• Использующие SN-имена: Write, Read, UnconfirmedWrite

На прикладном уровне обмена клиент формирует сервис-запрос, а сервер в ответ выдает сервис-ответ. Несмотря на то, что на стороне клиента и сервера эти запросы называются по-разному, фактически в сети они представляются одним кадром с данными. Например, сервис COSEM-OPEN описывается кадрами (примитивами - primitives):

• COSEM-OPEN.request,

• COSEM-OPEN.indication,

• COSEM-OPEN.responce,

• COSEM-OPEN.confirm,

Но в сети будет всего два пакета: AARQ (Application Association Request), который на стороне клиента будет играть роль COSEM-OPEN.request, а на стороне сервера - COSEM-OPEN.indication, и AARE (Application Association Response), который на стороне клиента будет играть роль COSEM-OPEN.confirm, а на стороне сервера - COSEM-OPEN. responce.

Для более детального погружения в содержимое данных кадров уровня необходимо знакомство с форматом хранения данных Basic Encoding Rules (BER encoding).

Правила Basic Encoding Rules (BER encoding)

BER - правила, описанные в международном стандарте ITU-T под номером X.690, регламентируют представление данных различных типов в единообразной форме для передачи по каналам связи. В соответствии со стандартом X.690 любой объект данных (число, строка байт, структура, массив) представляется последовательностью байт, состоящей из нескольких частей (блоков):

• идентификатор – блок, содержащий информацию о типе объекта;

• длина – блок, содержит информацию о длине следующего поля;

• значение – байты, хранящие значение объекта;

• завершающие байты (опциональный блок, и в нашем случае не используются).

Идентификатор (в стандарте DLMS/COSEM и ГОСТ он называется - тэг), как правило, занимает 1 байт, и побитовая раскладка этого байта выглядит следующим образом:

Биты класса (8 и 7 биты) определяют, является ли тип объекта универсальным (целое, вещественное и т.п.) или нет (например, программы при обмене используют свой тип данных)

Для универсальных типов номер тэга однозначно идентифицирует тип данных:

Примеры тэгов, описывающих универсальные типы:

02 – INTEGER – значением объекта является целое число (кол-во байт под число, а значит и его диапазон, определяется блоком длины);

04 – OCTET STRING значением объекта является строка байт. При этом после байта тэга идет блок, содержащий длину строки;

09 – REAL – значением объекта является вещественное число (4 байта)

и т.п. Полная таблица универсальных типов и соответствующих им номеров тэгов содержится в X.690.

Контекстнозависимый тип означает, что значение объекта определено контекстом обмена (например, строка OCTET STRING, которая содержит имя одной из сторон обмена). При этом в поле значения контекстнозависимого типа, как правило, содержится объект универсального типа вместе со своим описывающим тэгом.

Бит 6 тэга принимает значения: 0 –блок значения содержит ровно 1 экземпляр данного типа (например, одно целое число); 1 – может содержать произвольное количество значений данного типа (в т.ч. и 0).

Если номер тэга не укладывается в 5 бит, то тэг расширяется до 2-х байт. При этом старшие биты номера тэга располагаются во втором байте. Признаком двухбайтового тэга является значение 31 в номере тэга в первом байте. Такая ситуация довольно редка в стандарте DLMS, но некоторые тэги (например, в кадре AARQ) ее используют.

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

За блоком длины следует блок, содержащий само значение объекта.

Таким образом, например, целое число со значением 0xFFFF в формате BER будет закодировано последовательностью байт:

В качестве еще одного примера приведем объект: кадр прикладного уровня для установления соединения AARQ:

В данном примере байт тэга (0x60) имеет комбинацию битов 7 и 8 в виде 0-1 (определяемый приложением тип данных). Поэтому содержимое двадцати девяти байт значения будет определяться приложением COSEM-client, которое заполнит их в соответствии со стандартом COSEM.

Использование неуниверсальных типов данных (с отличающимися от нуля битами 7 и 8) позволяет создавать многоуровневые вложенные структуры из данных, закодированных в формате BER.

Рассмотрим, как пример, кадр AARQ для установления соединения без использования механизмов аутентификации.  Такое соединение соответствует режиму Публичный клиент по ГОСТ [1].

AARQ-pdu = [ 60 1D A1 09 06 07 60 85 74 05 08 01 01 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 7E 1F 04 B0 ]

Из рис.2 видно, что кадр представляет собой совокупность BER-объектов, каждый из которых характеризуется байтом тэга, идущим в блоке первым. Длина значения хранится в его втором байте, что позволяет отделять BER-объекты внутри кадра друг от друга.

3. Процедура установления соединения клиента и сервера

Данная процедура выполняется путем обмена кадрами AARQ и AARE по инициативе клиента. Каждый из них можно представить как совокупность BER-объектов, описываемых тэгами, хранящимися в первом байте каждого объекта.

При установлении соединения выбираются опции, влияющие на безопасность обмена:

• будет ли использована аутентификация или нет

• вариант аутентификации (с использованием хэширования или нет)

• будет ли использоваться шифрование при передаче данных

Стандартом предусмотрены три способа аутентификации:

• без аутентификации;

• слабая (low-level) аутентификация по паролю (клиент передает серверу свой пароль в незашифрованном виде);

• сильная (high-level) аутентификация с использованием протоколов MD5 или SHA-1 (клиент передает серверу свой пароль в зашифрованном виде).

Кадр AARQ представляет собой BER-объект с тэгом 0x60. Набор содержащихся в нем объектов зависит от способа аутентификации: без аутентификации и с аутентификацией.

Кадр AARQ без аутентификации (описаны только обязательные объекты):

В качестве имени контекста приложения клиент должен указать одну из заранее зафиксированных последовательностей, которые сервер должен опознать. Последовательность является вложенным блоком типа OBJECT_IDENTIFIER. Ключевое значение для последующего обмена имеет последний байт этой последовательности, который интерпретируется следующим образом: 1 – используются LN-имена, шифрование не используется; 2 – используются SN-имена, шифрование не используется; 3 – используются LN-имена, шифрование используется; 4 – используются SN-имена, шифрование используется.

Объект информации о клиенте в качестве значения содержит последовательность, которая является вложенным объектом типа OCTET_STRING. Содержимое данной строки проще описать примером. Возьмем следующую последовательность байт:

01 00 00 00 06 5F 1F 04 00 00 7E 1F 04 0B

01 – байт, показывающий, что данный блок является запросом (InitiateRequest)

00 – флаг, описывающий присутствие ключа шифрования (0 – нет ключа)

00 – флаг, описывающий присутствие байта, управляющего ответом (нужно ли серверу посылать кадр AARE) (0 – нет этого байта, и, по умолчанию, ответ нужен)

00 – флаг, описывающий присутствие блока, управляющего качеством передачи (0 – нет блока)

06 – текущая версия стандарта DLMS (06 = xDLMS)

5F 1F – тэг, описывающий идущий следом блок совместимости (conformance block). Здесь тот редкий случай, когда тэг занимает два байта, а не один. В блоке совместимости клиент указывает сервисы прикладного уровня COSEM, которые он поддерживает. За каждый поддерживаемый сервис отвечает выделенный бит. Раскладку битов можно найти в Geen Book [3].

04 – длина поля значения блока совместимости

00 – количество неиспользуемых бит в последнем байте блока совместимости

00 7E 1F – битовые поля, определяющие список поддерживаемых клиентом сервисов.

04 0В – максимальный размер блока данных в кадрах при обмене информацией (max-pdu-size).

В ГОСТ есть некоторые неточности в описании объекта информации о клиенте, поэтому за первоисточник брался Green Book.

В кадр AARQ с аутентификацией добавляются следующие необходимые объекты:

Имя механизма аутентификации представляет собой строку, в которой наиболее важным параметром является последний байт. Он определяет один из возможных методов аутентификации:

0 - без аутентификации

1 - слабая аутентификация

2 - сильная аутентификация (алгоритм не разглашается)

3 - сильная аутентификация (алгоритм MD5)

4 - сильная аутентификация (алгоритм SHA-1)

Фрагмент последовательности обмена с расшифровкой кадра AARQ приведен на рис.3.

Видно, что имя контекста приложения определяет обмен с помощью LN-адресации и без шифрования. Уровень аутентификации, определяемый полем имени механизма аутентификации – слабая аутентификация (1). Следовательно, пароль передается в явном виде. Блок поддерживаемых сервисов получен расшифровкой блока информации о клиенте (BE). В нем же определен максимальный размер кадра PDU, который клиент предлагает серверу.

В ответ на кадр AARQ, посланный клиентом, сервер отправляет кадр AARE. Кадр AARE представляет собой BER-объект с тэгом 0x61. Набор содержащихся в нем объектов также зависит от способа аутентификации.

Кадр AARE для режима с низкой безопасностью (без аутентификации или со слабой аутентификацией, и без шифрования):

В кадр AARE с сильной аутентификацией добавляются объекты:

Предусмотрено усложнение механизмов аутентификации, не включенное в стандарт. Для этого в поле Диагностика может быть записано значение 0x0E, что показывает необходимость дополнительных шагов. В случае неудачного соединения, причина ошибки может быть считана из объекта Диагностика.

Фрагмент последовательности обмена с расшифровкой кадра AARE приведен на рис.4.

Видно, что кадр AARE содержит то же имя контекста приложения, что и кадр AARQ (см. рис.2). В объекте результата процедуры аутентификации сервер передает код 0 (аутентификация принята). Вследствие этого объект диагностики не содержит дополнительной информации. Перечень сервисов, предлагаемый сервером, раскрыт по содержанию объекта информации о сервере (BE). Оттуда же получен максимальный размер кадра PDU, поддерживаемый сервером.

4. Сервисы для завершения соединения

Завершение соединения на прикладном уровне модели COSEM может быть либо обоюдным (используется сервис COSEM-RELEASE), либо принудительным (сервис COSEM-ABORT).

Для обоюдного завершения соединения используется обмен кадрами RLRQ (Release Request) и RLRE (Release Response). Структура данных кадров сходна с кадрами для установления соединения. Однако, есть важная особенность их использования: для коммуникационных профилей, использующих соединение типа “точка-точка” (например, HDLC), разрыв соединения на прикладном уровне (а значит и обмен кадрами RLRQ и RLRE) не требуется. Индикатором разрыва для обменивающихся сторон в этом случае служит закрытие соединения средствами нижележащих уровней. Но для профиля TCP-UDP использование завершения на прикладном уровне обязательно. Это связано с тем, что, если используется протокол UDP, то никакими другими средствами нельзя оповестить обменивающиеся стороны о завершении обмена.

В тех случаях, когда кадр RLRQ необходим, он содержит следующие объекты:

Состав кадра RLRE:

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

Заключение

В данной части рассмотрен процесс установления и разрыва соединения по протоколу DLMS\COSEM на прикладном уровне. Рассмотрена структура сервисных кадров и представление информации в них в виде объектов, закодированных в BER-кодировке. В следующей части будут рассмотрены сервисы для получения и передачи данных с прибора учета.

Список источников

1.     ГОСТ Р 58940-2020. Требования к протоколам обмена информацией между компонентами интеллектуальной системы учета и приборами учета. – Москва. – Стандартинформ. – 2020. – 101 с.

2.     СТО 34.01-5.1-006-2019 Приборы учета электрической энергии. Требования к информационной модели обмена данными. Стандарт организации ПАО «Россети». [Электронный ресурс]. URL:  http://www.rosseti.ru/investment/standart/corp_standart/doc/%D0%A1%D0%A2%D0%9E_34.01-5.1-006-2019.pdf (дата обращения 28.01.2022)

3.     DLMS User Association. COSEM Identification system and interface classes. Technical report. 8^th edition. – 2007. –  168 p. (Blue Book)

4.     DLMS User Association. DLMS\COSEM Architecture and protocols. Technical report. 6^th edition. – 2007. –  219 p. (Green Book)

5.     А. Мамаев. DLMS\COSEM – открытый протокол для обмена данными с приборами учета. Часть 1: краткий обзор. [Электронный ресурс] URL: https://habr.com/ru/post/302246/ (дата обращения 28.01.2022)

6.      А. Мамаев. DLMS\COSEM – открытый протокол для обмена данными с приборами учета. Часть 2:интерфейсные классы, модель прибора учета. [Электронный ресурс] URL: https://habr.com/ru/post/303606/ (дата обращения 28.01.2022)