Протокол dlms cosem что это

Эффективное применение DLMS/COSEM в больших системах с ограниченными ресурсами

Győző Kmethy – исполнительный директор и президент ассоциации DLMS – и Milan Kozole – председатель технического комитета ассоциации DLMS – в своей статье «Efficiency of DLMS/COSEM for large systems with constrained resources» рассказывают о способах и средствах эффективного использования стека DLMS/COSEM, позволяющие до 10 раз сократить объем передаваемых данных и уменьшить количество информационных обменов между клиентом и сервером.

Введение

DLMS/COSEM – это ведущий мировой стандарт (IEC/EN 62056, EN 13757), регламентирующий обмен данными с интеллектуальными устройствами. В настоящее время применяется, преимущественно, в интеллектуальных системах учёта потребления. Как правило такие системы состоят из головной подсистемы, которая собирает данные с миллионов устройств, а также управляет этими устройствами, используя для этих целей различные среды передачи данных.

DLMS/COSEM включает в себя три основные составляющие: (1) объектная модель COSEM, с помощью которой описывается функциональность конечного устройства; (2) прикладной уровень DLMS, который определяет сервисы для доступа к объектам COSEM; и (3) коммуникационные профили, которые определяют то, как эти сервисы могут быть переданы через различные среды передачи данных. Кроме того, DLMS/COSEM основан на клиент-серверной архитектуре, где головная подсистема выполняет роль клиента, посылающего запросы конечному устройству, а конечное устройство – роль сервера, посылающего ответы на запросы клиента.

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

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

Способы повышения эффективности DLMS/COSEM

Способы повышения эффективности DLMS/COSEM определены, как на уровне объектной модели COSEM, так и на прикладном уровне DLMS. Все они приведены в табл. 1.

Таблица 1 – Способы повышения эффективности DLMS/COSEM

Различные способы могут быть скомбинированы для достижения максимальной эффективности с учетом характеристик устройств и сетей передачи данных. Далее будет приведено краткое описание каждого способа повышения эффективности. Более подробная информация доступна в BlueBook, в которой описана объектная модель COSEM, и в GreenBook, в которой описан протокол прикладного уровня DLMS.

Разделение значений на динамические и статические

Объекты COSEM представляют данные, которые содержатся в атрибутах и включают в себя:

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

Значения, полученные в результате вычислений или измерений, как правило являются динамическими, поэтому их приходиться передавать довольно часто. Метаданные, как правило статичны, поэтому их достаточно передать один раз, или во всяком случае передавать не так часто.

Разделение значений на динамические и статические значительно повышает эффективность за счёт сокращения объема передаваемых данных.

Агрегирование данных

Данный способ позволяет собрать любую комбинацию данных (значений атрибутов) в одном атрибуте. Таким образом доступ к данным может быть осуществлен за один вызов сервиса DLMS, что позволяет сократить количество сообщений при обмене данными. Агрегирование данных доступно c:

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

Когда данные уже агрегированы, может потребоваться выбрать только часть данных, например, для того чтобы получить только те данные, которые интересны именно сейчас или восстановить потерянные данные. Селективная выборка может быть абсолютной, например, когда указан временной интервал или диапазон записей, или относительной, например, относительно текущего времени или текущей записи. Селективная выборка доступна в объектах классов «Profile generic», «Data protection» и «Compact data».

Использование NULL-data сжатия

В разработке находится более совершенный способ, так называемое delta-array сжатие. Оно также применимо для передачи массивов данных и позволяет динамически использовать максимально короткий тип данных в зависимости от изменения значения.

Оба способа значительно сокращают размер сообщений.

Использование данных типа compact-array

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

Использование интерфейсного класса «Compact data»

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

Агрегирование сервисов

Сервисы DLMS – это средства для доступа к атрибутам и методам объекта COSEM. Запросы содержат ссылку на атрибут или метод, а ответы – результат операции. Запросы и ответы также могут содержать данные.

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

Использование составных сообщений

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

Рисунок 1 — Составные сообщения

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

На втором этапе возможно сжатие данных с применением алгоритма V.44.

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

Использование предустановленных и неразрывных ассоциаций приложений

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

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

Рисунок 2 — Схема сеанса связи с явно установленным и предустановленным логическим соединением

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

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

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

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

Использование инициативных сообщений

В DLMS/COSEM определены два вида операций, как показано на рис. 3:

Рисунок 3 — Операции ЗАПРОС-ОТВЕТ и инициативные сообщения

Для отправки инициативных сообщений используется сервис DataNotification и применяется способ повышения эффективности, описанный в разделе «Использование составных сообщений».

Использование широковещательных и многоадресных сообщений

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

Кроме того, они могут применяться вместе с механизмом передачи образа «прошивки», который используется для загрузки и активации нового образа «прошивки» в группе устройств. Он позволяет восстанавливать потерянные блоки данных и гарантирует идентичность переданного и принятого образов «прошивок».

Заключение

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

Источник

Знакомство со стеком DLMS/COSEM для микроконтроллеров семейства MSP430 компании Texas Instruments

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

Стек DLMS/COSEM от компании TI имеет следующие особенности:

Загрузка и распаковка

Стек DLMS/COSEM доступен по адресу (http://www.ti.com/tool/dlmsobj-eval), для его загрузки необходимо иметь учетную запись TI. Сам стек упакован в дистрибутив под названием DLMS-4.0.6-windows-installer. После его установки, в папке установки будет лежать zip-папка «DLMS_Object» в которой находятся файлы стека.

Библиотека состоит из следующих файлов:

Запуск проекта

В этой части мы запустим демонстрационный проект и посмотрим, как представляются объекты COSEM. Для этого, открываем файл dlms_obj.eww в IAR for MSP430 и выбираем требуемый микроконтроллер, в нашем случае это MSP430F67791.

Собираем проект и программируем контроллер. Открываем программу DLMSDirector и добавляем новое устройство со следующими параметрами:

Нажимаем кнопку «ОК». Затем в дереве «Devices» выбираем наше устройство, нажимаем кнопку «Connect» и … получаем вот такую ошибку:

Исправляется она легко, открываем файл uart_comms.c проекта dlms_obj.eww и в строке 132 видим, что при конфигурировании UART была допущена «опечатка»:

Правильная строка должна иметь вид:

После исправления, связь с прибором учета успешно устанавливается, в результате чего становится доступной кнопка «Read», а в статусной строке мы видим «Ready»:

Для загрузки информации с прибора учета нажимаем кнопку «Read». Процесс этот не быстрый, поэтому придется чуть-чуть подождать. В результате получаем дерево из объектов COSEM:

В данном стеке, в открытом доступе, по умолчанию, отображается пять объектов:

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

Для доступа к прибору учета в режиме низкой секретности необходимо использовать следующие настройки (Пароль по умолчанию — 00000000):

В этом режиме доступно гораздо больше объектов COSEM:

Добавление нового объекта COSEM

Для добавления нового объекта открываем файл config.c проекта dlms_obj.eww, находим структуру:

и добавляем в нее следующую строку:

Meter_Sr_No указывает на следующую структуру:

Вот и все процедуры по созданию нового объекта. Результат:

Источник

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 позволяет создавать унифицированные драйверы, посредством которых, становится возможным связываться с приборами учета разных типов от различных производителей.

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

Источник

Обзор протоколов передачи данных приборов учета для Российского рынка

Усиление государственного регулирования в области энергосбережения (ФЗ 261 и другие нормативные акты) и сложность экономической ситуации в России стимулирует собственников к учету и экономии ресурсов. Соответственно увеличивается охват хозяйственой деятельности различных субъектов экономики приборами учета, и у каждого такого субъекта встает задача выбора наиболее подходящих ему приборов учета. Критерии такого выбора могут быть самыми разными. Если у субъекта стоит задача автоматического сбора показаний счетчиков в единый центр учета энергоресурсов, то такие счетчики должны быть оснащены цифровым интерфейсом для передачи данных. В существующих решениях по построению распределенных АСКУЭ основной упор делается на выбор физической среды передачи данных от счетчика на верхний уровень (PLC-технология передачи по силовой линии, радиоканал, проводная связь RS 485, Ethernet и др.). Вместе с тем имеет определенное значение и используемый протокол передачи данных. Несмотря на это, в настоящее время российские производители приборов учета не придерживаются какой-либо общепризнанной системы в выборе протоколов, вследствие чего наблюдается целый «зоопарк» разнообразных протоколов у производителей приборов учета. Это затрудняет их интеграцию в АСКУЭ. Учет используемых протоколов при осознанном выборе приборов может оказаться полезным для хозяйствующего субъекта. В настоящей статье приводится обзор широко используемых и перспективных протоколов передачи данных приборов учета, используемых в России и Европе. В обзоре рассматриваются протоколы, отвечающие российским/европейским стандартам, и не рассматриваются частные фирменные разработки, из-за их ограниченной сферы применения.

Протокол Modbus

Начнем с вездесущего протокола Modbus [1]. Он используется в самых разных областях автоматизации, в том числе и в приборах учета электричества, газа, воды и тепла. Широко распространен как за рубежом, так и в России. Этот протокол основан на архитектуре ведущий/ведомый, может использоваться для передачи данных через последовательные интерфейсы RS 485/422/232, а также через сети TCP/IP. Типы данных – однобитовые (Coils) и целочисленные (Registers). К достоинствам данного протокола относится открытость, простота, массовое распространение, дешевизна технологии. Тем не менее, для задач учета этот протокол подходит не в полной мере.

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

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

Протокол DLMS/COSEM

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

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

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

Однако у DLMS/COSEM есть и весомые недостатки:

Протокол M BUS

Далее рассмотрим протокол M BUS (ГОСТ Р ЕН 1434-3-2011, EN1434-3, EN13757) [2]. Сферой его применения являются преимущественно учет тепла и воды, также возможен учет электричества и газа. Он широко распространен в Европе, в России он тоже набирает популярность. Архитектура шины ведущий/ведомый. Используется стандартный телефонный кабель, шина полудуплексная, допустимые скорости передачи данных 300…9600 бит/с. Число устройств в сети — до 250 ед. Дальность работы в стандартной конфигурации до 1000 м. Логическая единица передается уровнем 36 В, с возможностью потребления от линии тока до 1,5 мА, логический ноль передается напряжением 24 В на master устройстве. Мастер передает данные меняя напряжение на линии: логической «1» соответствует 36 В, логической «0» 12…24 В. Ведомое устройство передает данные нагружением линии: в пассивном состоянии (логическая «1») ток нагрузки на линию связи должен быть ≤ 1,5 мА и не меняться в отсутствие передачи. Для передачи логического «0» ведомое устройство увеличивает ток потребления до 11…20 мА. Соответственно мастер отслеживает изменение тока нагрузки, определяя логическую «1» как неизменный ток, а увеличение тока потребления — как логический «0». Стандарт тщательно оптимизирован для пониженного потребления и позволяет обходиться без отдельного внешнего источника питания конечного устройства, используя внутреннюю батарею и питание от самой линии, также отсутствует необходимость соблюдения полярности. Специфицирован также вариант M Bus для беспроводных сетей — Wireless M Bus (частота устройств 868,95 МГц).

Протокол хорошо проработан, его несомненными достоинствами являются:

ГОСТ Р МЭК 60870-5

Хорошо разработанным является набор протоколов по ГОСТ Р МЭК 60870-5 «Устройства и системы телемеханики. Часть 5. Протоколы передачи» (IEC 60870-5) [3]. Он используется, как правило, при интеграции систем телемеханики и учета электроэнергии. Например, при мониторинге состояния сетей 0,4/10 кВ. Он распространен за рубежом и несколько ограниченно в России. Это хорошо проработанный ряд стандартов, охватывающий разные уровни сетевого взаимодействия: начиная от физического уровня и кончая прикладным уровнем. На физическом уровне используется асинхронный интерфейс (UART). Диапазон скорости 300…9600 бод. Поддерживается также работа со стандартными сетями TCP/IP (Ethernet и модемное соединение). Возможно шифрование данных. Раздел 60870-5-102 является обобщающим стандартом по передаче интегральных параметров в энергосистемах. Стандарт 60870-5-104, например, может использоваться при передаче данных по Ethernet, а стандарт 60870-5-101 — при передаче данных через GSM/GPRS модем.

В качестве замечаний можно высказать следующее:

Стандарт PLC (IEC 61344)

Сферой применения стандарта PLC (IEC 61344) [4, 5] преимущественно является сбор данных с электросчетчиков. Также иногда допускается подключение расходомеров, теплосчетчиков, газовых корректоров. Распространен стандарт, как за рубежом, так и в России. Среда передачи данных — электросети среднего (4…30 кВ) и низкого напряжения (0,2…0,4 кВ). Для передачи данных используются различные виды модуляции электрического сигнала (S FSK, SS-FFH, OFDM, DCSK). Существуют сети PLC-I и PLC-II. Сети PLC-I могут выполнять статистические функции, то есть сбор и обработку информации за определенные временные отрезки, на основании которой производятся анализ и расчеты за потребленные виды энергии. АСКУЭ, построенная на базе оборудования PLC-II, кроме возможности статистического учета, может выполнять оперативно-измерительные функции, то есть в режиме, приближенном к режиму реального времени, отслеживать потребление и качество энергоносителей. Также через PLC-II можно управлять нагрузкой (включать/отключать потребителей). Основное назначение оборудования PLC-I — построение недорогой АСКУЭ бытовых потребителей. При необходимости получения более широкого набора данных необходимо развертывать более дорогие сети PLC-II. На большинстве объектов связь для PLC-I обеспечивается на расстоянии 400…800 м; на новых сетях, выполненных самонесущим проводом, — до 1000 метров. Для увеличения этого расстояния требуются ретрансляторы. Применение ретрансляторов увеличивает расстояние уверенного приема в 1,5…1,8 раза.

К достоинствам этого способа связи относятся:

Заметим, что стоит отличать собственно стандарт PLC (IEC 61344) и PLC-технологию передачи данных по силовой линии. Указанная PLC–технология используется не только стандартом IEC 61344, но стандартами DLMS\COSEM, KNX, LonWorks и некоторыми другими.

Стандарт Euridis

В заключение в качестве достаточно нового зарубежного протокола рассмотрим Euridis (IEC 62056-31). Сферой его применения является учет электричества. Распространен он довольно ограниченно — преимущественно Франция, Северная Африка. В качестве среды передачи используется витая пара, длина линии — до 500 м, число устройств в сети — до 100 ед., скорость передачи — 1200 бит/с. Для связи используется асинхронная, полудуплексная, двунаправленная передача данных. В качестве положительных сторон данного протокола отметим наличие процедуры аутентификации для защиты данных и невысокую стоимость оборудования.

К недостаткам протокола отнесем:

Краткая оценка протоколов

Протокол Euridis, распространен только в отдельных регионах. Его применение ограничивается электроэнергетикой.

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

ГОСТ Р МЭК 60870-5 предоставляет достаточно гибкий набор протоколов, что кроме преимуществ вносит и дополнительные сложности: разные производители приборов учета/УСПД могут поддерживать разные протоколы, что затрудняет их интеграцию в единую си¬стему. Хотя применение этого стандарта в настоящее время ограниченно преимущественно электроэнергетикой, в этой сфере у него сильные позиции.

Протокол M BUS является весьма перспективным, для него разработаны законченные АСКУЭ, создана Open Metering System — европейская инициатива, преследующая цель унифицировать сбор данных с приборов учета ресурсов на основе шины M BUS. Успехом завершились усилия по интеграции шины KNX и M BUS, что позволяет строить за¬конченные решения по автоматизации зданий. Заметим все же, что в протоколе M BUS соответствие передаваемых данных типам измерений и измерительным каналам не регламентировано, что требует индивидуальной настройки считывающего устройства верхнего уровня (наподобие УСПД) под конкретный прибор учета.

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

Применение стандарта PLC является хорошим и недорогим способом для построения систем учета электроэнергии.

Заключение

Таким образом, ни один из существующих протоколов не является единственным кандидатом на роль универсального протокола для всех приборов учета. Что же делать системному интегратору, собирающемуся строить АСКУЭ с централизованным сбором данных?

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

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

Использование приборов учета с M BUS полностью оправдано для жилищного строительства премиум-сегмента (офисные «интеллектуальные» здания, дорогостоящие коттеджи). При этом система учета на M BUS может быть гармонично интегрирована в существующую систему автоматизации на основе европейской шины KNX, что обеспечит полную и прозрачную автоматизацию сверху донизу. Можно M BUS использовать и для обычного жилья, но здесь тормозящим фактором выступит не слишком большая распространенность этого протокола, и как следствие, привязка в дальнейшем к раз выбранному вендору.

Если стоит задача мониторинга и учета электроэнергии на оптовом и розничном рынках (например, мониторинг трансформаторных подстанций), то следует обратить особое внимание на решения на основе протоколов ГОСТ Р МЭК 60870-5. Эти протоколы хорошо приспособлены для решения этой задачи. Та¬кой протокол может быть использован при передаче данных от электросчетчиков/УСПД на верхний уровень (SCADA-система, АСКУЭ).

При сборе данных о потребленном электричестве с низового уровня (с электросчетчиков) предпочтителен протокол PLC, когда прокладка кабеля с данными (RS 485, Ethernet) невозможна (порча интерьера помещения) или дорогостояща (большие расстояния).

Список литературы

Источник