База знаний

Режим чтения файла

Часто задаваемые вопросы (FAQ)

(по состоянию на март 2006 г.)

A) Общие вопросы

B) Вопросы по спецификации DLMS/COSEM

C) Вопросы по сертификации соответствия

A) Общие вопросы

Что такое DLMS?

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

Позднее концепция была развита и стала Device Language Message Specification (Спецификация сообщений языка устройств) с целью создания среды взаимодействия для структурированного моделирования и обмена данными счетчиков. Поддерживаются такие приложения, как дистанционное считывание показаний счетчиков, дистанционное управление и услуги с добавленной стоимостью для учета любого вида энергии, такой как электричество, вода, газ или тепло.

Что такое COSEM?

COSEM означает COmpanion Specification for Energy Metering (Вспомогательная спецификация для учета энергии). Это интерфейсная модель взаимодействующего оборудования учета энергии, обеспечивающая представление о функциональности, доступной через интерфейсы связи. Моделирование использует объектно-ориентированный подход.

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

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

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

Первый атрибут любого объекта — это логическое имя, которое является частью идентификации объекта. Логическое имя вместе с class_id и version однозначно определяет смысл информации, представляемой любым интерфейсным объектом, независимо от производителя.

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

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

Ассоциация пользователей DLMS также определила стек протоколов, основанный на модели взаимодействия открытых систем (OSI), для передачи модели через последовательные интерфейсы, такие как оптические порты, интерфейсы токовой петли, модемы PSTN и GSM.

Что такое Ассоциация пользователей DLMS?

Ассоциация пользователей DLMS (DLMS UA) — это некоммерческая организация, расположенная в Женеве, Швейцария. Ее миссия — разрабатывать, продвигать и поддерживать спецификацию DLMS/COSEM. Она обеспечивает форум обмена информацией для пользователей, производителей, поставщиков систем, испытательных лабораторий и органов по стандартизации. Она также предоставляет схему сертификации и тестирования соответствия для измерительного оборудования, реализующего спецификацию. DLMS UA официально связана с IEC TC 13 WG 14.

Каковы преимущества DLMS/COSEM?

Основное преимущество DLMS/COSEM заключается в том, что он обеспечивает совместимость (интероперабельность).

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

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

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

Наличие тестирования соответствия, впервые в протоколах учета, значительно повышает вероятность интероперабельности, проверяя корректность реализации на уровне интерфейса и стека протоколов.

Чем DLMS/COSEM отличается от других стандартов обмена данными счетчиков?

Наиболее часто используемым стандартом для обмена данными счетчиков является протокол FLAG, стандартизированный для целей учета электроэнергии как IEC 61107 IEC TC 13. Другие широко используемые протоколы:

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

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

Где используется DLMS/COSEM?

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

Кто предоставляет измерительные системы DLMS/COSEM?

Статус на конец 2005 года. Реализации

Реализации – общие

Реализации – счетчики

Некоторые реализованные системы

Как я могу присоединиться к Ассоциации пользователей DLMS?

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

Присоединиться к Ассоциации пользователей DLMS очень легко через Интернет:

Управляющий комитет DLMS UA должен утвердить заявку. Когда она будет подтверждена, будет отправлен счет. Членство начинается, как только оплата будет зачислена.

Является ли DLMS/COSEM открытой спецификацией?

Спецификация DLMS/COSEM является открытой и доступна всем без дискриминации.

Спецификация DLMS/COSEM была разработана DLMS UA. Она включена в "Синюю книгу" и "Зеленую книгу" DLMS UA. Эти книги доступны всем членам DLMS UA.

Спецификация была предложена для международной стандартизации в IEC TC 13 для целей учета электроэнергии и в CEN TC 294 для целей учета коммунальных услуг, отличных от электроэнергии. Серия стандартов IEC 62056 – части 6-42, 6-46, 6-53, 6-61 и 6-62 была опубликована в начале 2002 года. Стандарт EN 13757-1 ожидается к четвертому кварталу 2002 года.

Кроме того, DLMS UA разработала и поддерживает схему тестирования и сертификации соответствия, обеспечивая равные условия тестирования реализаций. Это описано в "Желтой книге", которая также доступна членам DLMS UA.

Какие среды передачи данных поддерживаются?

В настоящее время стек протоколов, определенный в Зеленой книге, позволяет использовать DLMS/COSEM через прямое подключение через оптический или электрический порт, по коммутируемым или арендованным телефонным линиям и через сеть GSM.

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

Могу ли я использовать DLMS/COSEM через интернет?

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

Что такое xDLMS?

xDLMS — это расширение стандарта DLMS.

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

xDLMS — это элемент сервиса уровня приложений, обеспечивающий доступ к объектам COSEM. Он содержит несколько новых сервисов, в основном для поддержки ссылок по логическому имени (LN), и определяет дополнительные типы данных. Он определяет новый блок соответствия. Текущая версия xDLMS в DLMS — 6.

B) Вопросы по спецификации DLMS/COSEM

Подходит ли DLMS/COSEM для простых счетчиков?

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

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

На уровне модели единственным обязательным элементом является управляющее логическое устройство, которое может быть единственным. Оно должно содержать объект назначения SAP, содержащий SAP всех логических устройств. Каждое логическое устройство должно иметь объект, содержащий имя логического устройства, и текущий объект ассоциации, чтобы можно было получить список доступных объектов. Для простых устройств с небольшими ресурсами памяти могут быть определены предустановленные ассоциации. Управляющее логическое устройство должно поддерживать ассоциацию с публичным клиентом, позволяющую получать структуру неизвестного счетчика. Все остальное остается на выбор разработчика.

Ссылка по короткому имени или по логическому имени?

Любая информация, смоделированная COSEM, может быть доступна как атрибут или метод определенного интерфейсного объекта COSEM. Для доступа к атрибуту или методу необходимо сделать на них ссылку. В измерительном оборудовании (сервере) уровень приложений COSEM предоставляет два механизма доступа к атрибутам. Один называется ссылкой по короткому имени (SN), а другой — ссылкой по логическому имени (LN). Уровень приложений системы сбора данных (клиента) всегда использует ссылки по логическому имени.

При использовании ссылки SN атрибуты и методы каждого интерфейсного объекта сопоставляются с именованными переменными DLMS. Это делается во время проектирования счетчика. Каждая именованная переменная идентифицируется коротким именем, которое представляет собой 16-разрядное целое число без знака. Атрибут 1, логическое имя объекта, сопоставляется с именованной переменной DLMS, идентифицируемой базовым именем. За исключением нескольких специальных объектов, общих правил для присвоения базовых имен не определено. Все остальные атрибуты и методы объекта также сопоставляются с именованными переменными DLMS. Смещения между базовым именем и коротким именем, идентифицирующим другие атрибуты и методы, определены в определении каждого интерфейсного класса. Фактические значения коротких имен, таким образом, зависят от количества и типа созданных объектов и используемой стратегии сопоставления. Базовые имена, выделенные в измерительном оборудовании, могут быть получены путем чтения атрибута object_list объекта ассоциации SN. При использовании ссылки SN доступ к именованным переменным DLMS осуществляется с помощью стандартных сервисов DLMS READ и WRITE.

При использовании ссылки LN доступ к атрибутам и методам осуществляется через логическое имя объекта с указанием индекса(ов) атрибута(ов) и/или метода(ов). Логические имена определяются OBIS. При использовании ссылки LN доступ к атрибутам и методам осуществляется с помощью сервисов xDLMS GET/SET и ACTION.

Поскольку уровень приложений системы сбора данных (клиента) всегда использует ссылки LN, запросы сервисов LN сопоставляются с запросами сервисов SN элементом сервиса Short Name Mapper уровня приложений.

Ссылка SN унаследована от оригинального стандарта DLMS. Ссылка LN является результатом эволюции спецификации.

Какая из них лучше? Ответ: ни одна из них. Проще говоря, ссылка SN больше подходит для простых устройств, а ссылка LN — для сложных устройств. Использование коротких имен ограничивает возможное количество объектов внутри логического устройства. В зависимости от сложности интерфейсный объект занимает диапазон от 8 (Data) до 136 (Clock) коротких имен, начиная с базового имени. Весь доступный диапазон составляет 8192. Следовательно, максимальное количество объектов зависит от типа (сложности) используемых объектов и стратегии выделения базовых имен. С другой стороны, APDU для ссылок SN короче APDU для ссылок LN. При ссылке LN ограничение устанавливается только возможными именами OBIS (в принципе 255**6). Существует несколько расширенных функций, доступных только при ссылке LN. Однако это сделает программное обеспечение счетчика несколько более сложным.

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

Для чего предназначен верхний адрес HDLC?

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

В трехслойном, ориентированном на соединение, основанном на HDLC коммуникационном протоколе адресация выполняется на уровне MAC. Нижний адрес HDLC используется для адресации физического устройства, а верхний адрес HDLC — для адресации различных логических устройств внутри одного физического устройства. Прикладные ассоциации устанавливаются между Клиентом и Логическим Устройством на Сервере. Ассоциации идентифицируются парой адресов HDLC (адрес HDLC Клиента – нижний адрес HDLC/верхний адрес HDLC Сервера). Основанный на HDLC уровень канала передачи данных поддерживает структуру адресов нижний HDLC/верхний HDLC, используя механизм расширенной адресации, предоставляемый стандартом HDLC ISO/IEC 13239. Следует отметить, что для целей DLMS/COSEM в ISO/IEC 13239 был добавлен новый формат кадра типа 3, содержащий как исходный, так и целевой адреса.

В полном стеке протоколов OSI "Точка доступа к транспортным услугам" (TSAP) выполняет ту же роль, что и верхний адрес HDLC в трехслойном, ориентированном на соединение, основанном на HDLC стеке протоколов, используемом с COSEM. TSAP — это точка на транспортном уровне продукта на основе OSI, к которой можно получить доступ для целей адресации. Этот адрес может использоваться в дополнение к основной сетевой адресации.

Используя пример, не связанный с OSI, роль верхнего адреса HDLC аналогична "номеру порта". Компьютер, одно физическое устройство, запускает различные приложения, такие как веб-браузер, почта, FTP. Доступ к компьютеру можно получить с помощью его IP-адреса, а к различным приложениям — которые аналогичны логическим устройствам DLMS/COSEM — можно получить доступ с помощью их номеров портов. Многие знают, что назначенный номер порта для HTTP (World Wide Web) — 80, а стандартный порт для SMTP — 25.

Для чего предназначено управляющее логическое устройство?

Проще говоря, управляющее логическое устройство — это логическое устройство, которое должно всегда присутствовать в физическом устройстве, и для которого зарезервирован верхний адрес HDLC 0x01.

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

Согласно модели счетчика DLMS/COSEM, каждый набор измерительных данных обрабатывается логическим устройством, реализованным в физическом устройстве.

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

Управляющее логическое устройство должно иметь объект назначения SAP, который содержит список всех логических устройств и их адресов SAP внутри физического устройства. Управляющее логическое устройство должно поддерживать прикладную ассоциацию с публичным клиентом с самым низким уровнем безопасности. Адрес клиента 0x10 зарезервирован для публичного клиента. В случае ссылки LN объект назначения SAP имеет предопределенное логическое имя. В случае ссылки SN base_name назначения SAP предопределен как 0xFC00.

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

Для чего предназначен публичный клиент?

Цель публичного клиента — поддерживать получение структуры неизвестного счетчика.

Адрес клиента 0x10 зарезервирован для публичного клиента. Управляющее логическое устройство, имеющее зарезервированный верхний адрес HDLC 0x01, должно поддерживать прикладную ассоциацию с этим публичным клиентом с наименьшим уровнем безопасности. Адреса SAP всех логических устройств можно найти, прочитав объект назначения SAP. Список доступных объектов (в случае ссылки SN — с их базовыми именами) и права доступа к их атрибутам и методам можно получить, прочитав атрибут object_list прикладной ассоциации.

Что такое объекты ассоциации?

В DLMS/COSEM объекты ассоциации играют роль "привратника", контролируя доступ к информации в счетчике и предоставляя информацию о том, что доступно.

Поскольку существуют два метода ссылок, существуют также два типа объектов ассоциации: один для ссылок по короткому имени (SN) и один для ссылок по логическому имени (LN).

Хотя они выполняют одну и ту же задачу, объекты Ассоциации SN и Ассоциации LN немного отличаются.

Логическое имя текущего объекта ассоциации — 0.0.40.0.0.255. В случае ссылки SN base_name текущего объекта ассоциации — 0xFA00.

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

Как объект Ассоциации LN, так и объект Ассоциации SN имеют атрибут object_list, предоставляющий список интерфейсных объектов, "видимых" в данной ассоциации. В случае ссылки LN object_list предоставляет class_id, version, logical_name и права доступа к атрибутам и методам для каждого объекта. В случае ссылки SN object_list предоставляет base_name, class_id, version и logical_name каждого объекта. Чтобы получить права доступа, можно использовать метод get_attributes&methods. Могут использоваться права доступа по умолчанию (например, только чтение для атрибутов, нет доступа к методам).

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

Методы объекта Ассоциации LN поддерживают аутентификацию высокого уровня безопасности и позволяют добавлять объекты в object_list или удалять их.

Методы объекта Ассоциации SN поддерживают чтение объектов по их логическому имени, получение прав доступа, а также поддерживают процесс аутентификации высокого уровня безопасности.

Как подключиться к логическому устройству?

Существует две разные ситуации: первая — когда система сбора данных (клиент) знает структуру измерительного устройства (сервера), и вторая — когда устройство неизвестно клиенту.

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

Когда структура измерительного устройства известна, процесс следующий.

  1. Подключить физический уровень. При необходимости согласовать стек протоколов.
  2. Подключить уровень канала передачи данных, используя известный нижний адрес HDLC и известный верхний адрес HDLC выбранного логического устройства внутри физического устройства. При необходимости согласовать параметры уровня канала передачи данных.
  3. Установить прикладную ассоциацию, согласовать контекст приложения (ссылка SN или LN), контекст xDLMS и выполнить аутентификацию, используя известный пароль или секрет HLS.
  4. Получить доступ к выбранным атрибутам и методам, используя соответствующий набор сервисов. Это GET/SET/ACTION при использовании ссылки LN и READ/WRITE при использовании ссылки SN.
  5. Завершить соединение на уровне канала передачи данных — это также разорвет прикладную ассоциацию — и установить другую ассоциацию или завершить физическое соединение.

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

  1. Подключить физический уровень. При необходимости согласовать стек протоколов.
  2. Подключить уровень канала передачи данных, используя зарезервированный адрес публичного клиента (0x10), нижний адрес HDLC физического устройства и верхний адрес HDLC управляющего логического устройства (0x01). При необходимости согласовать параметры уровня канала передачи данных.
  3. Установить прикладную ассоциацию, согласовать контекст приложения (ссылка SN или LN) и контекст xDLMS. Аутентификация не требуется.
  4. Получить доступ к объекту назначения SAP (в случае ссылки LN логическое имя 0.0.41.0.0.255, в случае ссылки SN 0xFC00), чтобы получить список логических устройств и их SAP. Атрибут SAP_assignment_list предоставляет SAP каждого логического устройства с его logical_device_name. Когда используется ссылка по короткому имени, base_name объекта имени логического устройства COSEM — 0xFD00.
  5. Отключить уровень канала передачи данных и подключиться снова, используя адрес соответствующего клиента и верхний адрес HDLC выбранного логического устройства.
  6. Установить прикладную ассоциацию, согласовать контекст приложения (ссылка SN или LN), контекст xDLMS и выполнить аутентификацию (пароль или секрет HLS должен быть известен).
  7. Получить object-list из объекта ассоциации с правами доступа к атрибутам и методам.
  8. Просмотреть список и найти интересующие объекты в логическом устройстве.
  9. Получить доступ к выбранным атрибутам и методам, используя соответствующий набор сервисов. Это GET/SET/ACTION при использовании ссылки LN и READ/WRITE при использовании ссылки SN.
  10. Завершить соединение на уровне канала передачи данных — это также разорвет прикладную ассоциацию — и установить другую ассоциацию или завершить физическое соединение.

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

Что такое имя логического устройства?

logical_device_name используется для всемирно уникальной идентификации каждого логического устройства.

Это строка октетов длиной до 16 октетов. Первые три октета однозначно идентифицируют производителя устройства. Он назначается DLMS UA совместно с Ассоциацией FLAG. Производитель отвечает за гарантию уникальности следующих октетов (до 13 октетов). Имя логического устройства хранится в объекте назначения SAP или в объекте имени логического устройства COSEM — объекте данных или регистра с логическим именем 0.0.42.0.0.255. Когда используется ссылка по короткому имени, base_name объекта имени логического устройства COSEM — 0xFD00.

Какие функции безопасности поддерживает DLMS/COSEM?

DLMS/COSEM предоставляет расширенные функции безопасности, обеспечивая контролируемый доступ к данным, хранящимся в счетчике, с использованием различных уровней аутентификации.

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

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

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

Кроме того, может использоваться шифрование. Это обеспечивается элементом сервиса xDLMS уровня приложений.

Что такое имена OBIS?

OBIS означает Object Identification System (Система идентификации объектов). OBIS предоставляет стандартные идентификаторы для всех данных внутри измерительного оборудования, как измерительных значений, так и абстрактных значений. Имена OBIS используются для идентификации объектов COSEM, а также для идентификации данных, отображаемых на счетчике и передаваемых по линии связи в систему сбора данных.

Необходимость в стандартных системах идентификации была выявлена с появлением сложных многофункциональных счетчиков, когда приходилось считывать и передавать большое количество данных. Некоторые страны создали свои собственные стандарты, но большинство производителей использовали проприетарные системы. Одной из широко признанных систем была Система идентификации энергетических данных (EDIS), определенная в Германии. Эта система была взята за основу OBIS.

OBIS использует шесть групп значений в иерархической структуре. Группа значений A идентифицирует тип измеряемой энергии. A=0 идентифицирует абстрактные коды. Группа значений A имеет зарезервированное пространство для будущих расширений. Группа значений B идентифицирует измерительные каналы. Группа значений C идентифицирует измеряемую физическую величину, в то время как группа значений D идентифицирует методы обработки и коды, специфичные для страны. Группа значений E используется для идентификации тарифов или может использоваться для дальнейшей классификации. Группа значений F используется для идентификации исторических значений или может использоваться для дальнейшей классификации. Группы B-D имеют пространство кодов для идентификаторов, специфичных для производителя.

Стандартные коды для электричества, холодной воды, горячей воды, газа, отопления и охлаждения определены в Синей книге DLMS UA. Список полных стандартных кодов OBIS, действительных комбинаций стандартных значений в каждой группе, поддерживается DLMS UA. Список доступен на веб-сайте DLMS UA и регулярно обновляется. Инструмент тестирования соответствия DLMS/COSEM проверяет логическое имя каждого объекта, найденного в тестируемом счетчике, на основе этой таблицы.

Возможны ли объекты, специфичные для производителя?

DLMS/COSEM предоставляет богатый набор стандартных объектов для поддержки широкой функциональности измерительного оборудования. Однако, чтобы поддерживать инновации, могут быть определены и использованы объекты, специфичные для производителя. Они будут идентифицированы кодами OBIS, специфичными для производителя. Код OBIS является специфичным для производителя, если любая из групп значений B-D имеет значение от 128 до 254.

Чтобы сохранить интероперабельность, объекты, специфичные для производителя, не должны использоваться для цели, для которой определен стандартизированный объект. Чтобы позволить системе сбора данных интерпретировать объекты, специфичные для производителя, необходима дополнительная информация.

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

Какие элементы спецификации необходимо регистрировать?

Существует ряд элементов в спецификации, которые необходимо регистрировать.

Это следующие:

Услуги регистрации предоставляются DLMS UA. Списки зарегистрированных элементов доступны на веб-сайте DLMS UA в разделе "Documentation".

Как счетчик может сообщить о событии?

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

В случае использования трехслойного, ориентированного на соединение, основанного на HDLC стека протоколов процесс следующий.

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

Если физическое соединение не существует, оно инициируется сервером. Как только физическое соединение — включая сервис идентификации — выполнено, APDU EventNotification.request отправляется на канальный уровень, где он ожидает возможности отправки.

Сервер, обнаруживший событие, может находиться в многоточечной конфигурации. Когда клиент получает вызов, он должен выяснить, какой сервер в многоточечной сети звонил. Поэтому он устанавливает соединение DL, используя специальный нижний адрес HDLC — ВЫЗЫВАЮЩИЙ физический адрес (0x7E или 0x3FFE) и в качестве верхнего адреса HDLC — адрес управляющего логического устройства. Только физическое устройство, которое позвонило, ответит и установит соединение на канальном уровне.

Если сервер не имеет права говорить, клиент должен инициировать отправку ожидающего PDU. Это делается путем отправки пустого кадра UI на сервер с битом P/F, установленным в 1, давая серверу разрешение на отправку.

Ожидающий PDU отправляется в кадре UI, и при его приеме он передается процессу управляющего приложения клиента. Приложение клиента, в зависимости от содержимого EventNotification, может решить, что делать дальше.

С другими нижними уровнями, отличными от HDLC, авторизация на отправку ожидающего PDU EventNotification может быть другой.

C) Вопросы по сертификации соответствия

Как я могу протестировать свое устройство на соответствие?

DLMS UA предоставляет процесс тестирования соответствия. Основные элементы:

Процесс основан на самопроверке с использованием инструмента тестирования, разработанного DLMS UA.

CTT может быть приобретен любым членом DLMS UA у Euro DCS (http://www.eurodcs.de) на коммерческих условиях, согласованных DLMS UA.

Для получения дополнительной информации ознакомьтесь со страницами тестирования соответствия на этом веб-сайте.

Как получить отчеты о тестировании соответствия?

Отчеты о тестировании соответствия хранятся в DLMS UA, но не публикуются. Копии должны быть доступны у поставщика.

Как зарегистрировать свое устройство как соответствующее DLMS/COSEM?

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

Как поддерживается инструмент тестирования соответствия?

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

Как маркировать продукты после прохождения теста на соответствие?

После принятия отчета об испытаниях DLMS UA рекомендует, чтобы производитель размещал знак "DLMS/COSEM compliant" на своем продукте и в сопроводительной документации. Знак "DLMS/COSEM compliant" можно найти на веб-сайте тестирования соответствия DLMS UA.

Нужно ли повторно тестировать продукт, если я вношу улучшения после прохождения теста на соответствие?

Сертификат соответствия DLMS/COSEM действителен для продукта, указанного в сертификате. Функции продукта, прошедшего тестирование, перечислены в файлах PICS и PIXIT, которые являются частью отчета об испытаниях. Список объектов можно определить, просмотрев часть отчета об испытаниях, касающуюся списка объектов COSEM. Если во время улучшения продукта добавляются новые функции, которые ранее не тестировались, продукт должен быть повторно протестирован, чтобы можно было заявить о соответствии.

Нужно ли повторно тестировать конфигурации продуктов?

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

Примечание: Этот документ отвечает на некоторые часто задаваемые вопросы относительно спецификации DLMS/COSEM и ее использования. Он был составлен экспертами Ассоциации пользователей DLMS. Ответы на вопросы не предназначены для предоставления окончательного технического ответа, а скорее для информирования новых пользователей спецификации.

Отзывы приветствуются в виде комментариев к этому документу или новых вопросов для рассмотрения.

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