В октябре 2019 года вышла вторая версия спецификации СПОДЭС – корпоративного стандарта ПАО «Россети» СТО 34.01-5.1-006-2019 «Счетчики электрической энергии. Требования к информационной модели обмена данными», а в июле 2020 года Федеральное агентство по техническому регулированию и метрологии «Росстандарт» утвердило СПОДЭС в качестве национального стандарта Российской Федерации ГОСТ Р 58940-2020 «Требования к протоколам обмена информацией между компонентами интеллектуальной системы учета и приборами учета».
За один год СПОДЭС прошла путь от корпоративного стандарта до национального стандарта Российской Федерации. Однако и сегодня для многих СПОДЭС является тайной за семью печатями.
Общаясь в кругу тех, кто разрабатывал эту спецификацию, а также принимая участие в её разработке и сопровождении, у меня накопился определенный опыт, которым я хочу поделиться с вами и рассказать о спецификации СПОДЭС.
Содержание
- Информационная модель прибора учёта электрической энергии
- СПОДЭС и стек DLMS/COSEM
- СПОДЭС
- В помощь программисту
Информационная модель прибора учёта электрической энергии
Если в «двух словах», то СПОДЭС – это информационная модель прибора учёта электрической энергии. Однако многие считают, что СПОДЭС это протокол, но это не так. Действительно, СПОДЭС определяет требования к протоколам передачи данных, но она не протокол.
Спецификация СПОДЭС была разработана с целью обеспечить взаимозаменяемость приборов учёта электрической энергии разных производителей и достичь этой цели невозможно, создав лишь один протокол. Смотрите, для того чтобы приборы учёта стали функционально совместимыми необходимо определить перечень измеряемых и учитываемых параметров, стандартизировать журналы и коды событий, определить функционал общего назначения (паспортные данные, тарифные зоны, тарифное расписание, управление нагрузкой абонента, электронные пломбы и пр.), стандартизировать способы обеспечения информационной безопасности и определить среды, интерфейсы и протоколы передачи данных. Теперь вы видите, что стандартизация протокола, вернее протоколов, это всего лишь один из пунктов на пути к функциональной совместимости.
Если всё выше перечисленное свести в один документ, то мы получим ту самую информационную модель прибора учёта. По сути это будет некий виртуальный прибор учёта, с известным функционалом и способами обмена данными, «живущий» в наших умах. В реальности приборы учёта могут отличаться конструктивно, но они будут иметь один и тот же функционал, унифицированные интерфейсы связи и стандартизированный информационный обмен. Поэтому такие приборы учёта будут функционально совместимы и взаимозаменяемы.
СПОДЭС и стек DLMS/COSEM
Когда мы определили перечень измеряемых и учитываемых параметров, стандартизировали журналы и коды событий, определили функционал общего назначения, стоит задуматься о том, как это описать в устройстве и как передать эти данные в информационную систему.
Здесь есть два варианта, придумать что-то свое или взять готовое решение. Вы наверно уже догадались из названия подзаголовка, что при разработке СПОДЭС был выбран второй вариант, а именно стек DLMS/COSEM (IEC 62056).
Почему стек DLMS/COSEM? Потому что это открытый, стандартизированный набор протоколов для приборов коммерческого учёта, имеющий средства проверки на совместимость.
Любопытный читатель может ознакомиться с небольшой обзорной заметкой о стеке DLMS/COSEM, которая даст некоторое общее понимание этого набора протоколов.
Объектная модель COSEM позволяет описать функциональность прибора учёта в виде объектов COSEM, являющимися экземплярами стандартных интерфейсных классов, описанных в Blue Book DLMS UA. Измеряемые и учитываемые параметры, журналы, паспортные данные, тарификация, управление нагрузкой абонента и многое другое представляется в виде объектов COSEM. Доступ к этим объектам осуществляется с помощью протокола прикладного уровня DLMS.
Cтек DLMS/COSEM имеет трёхуровневую сетевую модель: прикладной, промежуточный и физический уровни. Комбинация промежуточного и физического уровней образует коммуникационный профиль. На сегодняшний день определены шесть коммуникационных профилей:
- IEC 62056-7-6:2013 – HDLC;
- IEC 62056-8-3:2013 – PLC S-FSK;
- IEC 62056-9-7:2013 – TCP-UDP/IP;
- IEC 62056-7-3:2017 – M-Bus;
- IEC 62056-8-5:2017 – PLC OFDM G3;
- IEC 62056-8-4:2018 – PLC OFDM PRIME;
Время от времени появляются новые коммуникационные профили, например, сейчас ведутся работы по разработке коммуникационного профиля для 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.
Каждый прибор учёта, соответствующий спецификации СПОДЭС СТО имеет три типа соединения, через которые реализуется ограничение прав доступа. Все они приведены в таблице ниже.
Тип соединения | |||
Публичный клиент | Считыватель показаний | Конфигуратор | |
Идентификатор клиента | 16 | 32 | 48 |
Криптографическая защита информации | Не применяется | Шифрование и/или аутентификация | Шифрование и/или аутентификация |
Уровень безопасности (Authentication mechanisms) |
Самый низкий (No security authentication) |
Низкий (Low Level Security authentication) |
Высокий (High Level Security authentication) |
Сервисы прикладного уровня |
|
|
|
Идентификатор клиента – это поле 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/COSEM можно в методических указаниях TK 26 МР 26.4.003-2019 «Информационная технология. Криптографическая защита информации. Использование российских криптографических механизмов для реализации обмена данными по протоколу dlms».
Также для типа соединения Считыватель показаний теперь обязательна аутентификация данных, а для Конфигуратора – аутентификация и/или шифрование. В СПОДЭС СТО это было опционально.
Подробную информацию о паспортных данных, текущих показаниях, учитываемых параметрах, структуре журналов, кодах событий смотрите в приложениях к СПОДЭС.
Особенности приборов учёта, которые соответствуют СПОДЭС:
- Функция стоп-кадра. Снятие показаний на единый момент времени
- Профиль нагрузки с регулируемым периодом записи
- Суточный и месячный журналы
- Журналы событий
- Журнал учета качества электроэнергии
- 8 тарифов + таблица специальных дней
- Корректировка часов, зимнее и летнее время
- Управление нагрузкой абонента: локальное и дистанционное
- Уведомления о событиях в ПУ
В помощь программисту
Дорогой друг, если перед тобой стоит задача реализовать прибор учёта, соответствующий СПОДЭС, начни с изучения цветных книг ассоциации DLMS UA. В зеленой книге ты найдешь информацию о протоколе DLMS, способах аутентификации при установлении соединения, способах защиты конфиденциальных данных и описание коммуникационных профилей. В первую очередь смотри коммуникационный профиль на базе протокола HDLC, потому что он применяется в СПОДЭС и тестирование на совместимость реализовано только для него.
Кстати, протестировать свой прибор учёта можно с помощью Сертификационной утилиты. Если вдруг какой-то тест завершится неудачей, не отчаивайся и полистай желтую книгу DLMS UA. В ней ты найдешь описание тестов и узнаешь, как сделать так, чтобы тест был успешно пройден.
В голубой книге ты найдешь описание стандартных интерфейсных классов и описание OBIS-кодов.
После того как ты станешь уверенным знатоком стека DLMS/COSEM смело открывай спецификацию СПОДЭС и создавай самый лучший, интероперабельный прибор учёта электрической энергии.