Технологии связи играют всё более важную роль в растущем рынке AMI. Статья представляет собой полный анализ и сравнение четырех протоколов прикладного уровня, применяемых для интеллектуального учета потребления. Рассматриваются следующие протоколы: DLMS/COSEM, SML (Smart Message Language), а также MMS и SOAP отображение IEC 61850. В работе сделан акцент на использование этих протоколов совместно с TCP/IP стеком. Протоколы сначала сравниваются относительно качественных критериев, например, возможность синхронизации времени и др. После этого сравнивается размер сообщений и анализируется эффективность кодирования.

AMI (Advanced metering infrastructure) — это интегрированная система интеллектуальных приборов учета, коммуникационных сетей и систем управления данными, которая включает двухстороннюю связь между поставщиком услуг и потребителем.

I. Введение

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

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

Коммуникация в интеллектуальных приборах учета является предметом нескольких работ по стандартизации (например, [1]) и частью национальных дорожных карт, посвященных интеллектуальным сетям [2, 3]. Но до сих пор, большинство установленного AMI оборудования используют проприетарные протоколы, которые не соответствуют открытым или международным стандартам. В будущем, однако, необходимо сосредоточиться на открытых стандартах. Это позволит создать конкуренцию на свободном рынке и приведет к снижению стоимости оборудования.

В этой статье сравниваются четыре различных протокола прикладного уровня применяемые для интеллектуального учета потребления. Это протокол SML (Smart Message Language, IEC 62056-58 Draft) [4], DLMS/COSEM (IEC 62056-53 [5] и IEC 62056-62 [6]), а также MMS [7] и SOAP [8] отображение для стандарта IEC 61850.

Ранее, протоколы для интеллектуального учета потребления, уже были проанализированы с различных точек зрения. Так, в работе [9] представлен общий обзор наиболее распространённых протоколов для интеллектуального учета потребления на всех уровнях. В работе [11] DLMS/COSEM сравнивается с IEC 60870-5-104. В работе [12] приводится подробный анализ DLMS/COSEM. В данной статье впервые сравниваются протоколы DLMS/COSEM, SML и IEC 61850 по качественным критериям и эффективности кодирования.

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

II. Коммуникационная топология систем интеллектуального учета потребления

Для организации связи в AMI системах используют различные топологии сетей. Однако большинство топологий могут быть получены из общей формы, приведенной на рисунке 1. На этом рисунке приборы учета газа, электричества, воды, тепла соединяются с так называемым «домовым шлюзом», посредством которого реализуется интерфейс к внешнему миру. В большинстве случаев, этот шлюз фактически интегрируется в прибор учета электрической энергии. Отметит, что приборы учета газа, воды и тепла являются особенными в том плане, что они в основном питаются от автономных источников. Эта особенность должна учитываться при выборе коммуникационных протоколов для линии (b). Шлюз (или прибор учета электроэнергии) может соединяться с системой сбора данных на стороне поставщика услуг либо непосредственно через Интернет-соединение (с), либо через концентратор данных (d и e) – где d это как правило или силовая линия, или беспроводное решение среднего радиуса действия.


Рисунок 1 – Коммуникационная топология для интеллектуального учета потребления

Протоколы прикладного уровня, рассматриваемые в данной статье, могут использовать для обмена данными стек протоколов TCP/IP, поэтому они пригодны для организации связи посредством Интернет-соединения (с и e), а также могут быть применены для обмена данными в локальных сетях, таких как Ethernet и WiFi (a). Кроме того, часть рассматриваемых протоколов поддерживают обмен данными с использованием других протоколов нижнего уровня. DLMS/COSEM поддерживает обмен данными по протоколам UDP, HDLC, M-Bus, а также различным протоколам обмена данными по силовым линиям, например IEC 61334-5. SML поддерживает обмен данными по последовательным линия и протоколу M-Bus. MMS и SOAP не поддерживают дополнительных протоколов нижнего уровня.

III. Качественные критерии

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

А. Поддержка различных видов информации

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

• Результаты измерений. Естественно все рассматриваемые протоколы поддерживают передачу измеренных данных (энергия, мощность, напряжение, объем и др.). Но протоколы могут различаться своей поддержкой таких видов информации как:
  
  • Профили нагрузки. Прибор учета может хранить профили нагрузки (например, с разрешением 15 мин.). Поэтому протоколы должны иметь возможность передачи этих профилей, при необходимости с соответствующими метками времени;
  • Цифровая подпись. Результаты измерений могут быть подписаны цифровыми подписями, для того чтобы доказать целостность данных третьим лицам.
• Информация о синхронизации часов. Синхронизация времени важна для приборов учета, которые хранят профили нагрузки или для приборов учета, которые оперативно переключаются, на основе расписания, между тарифными регистрами.
• Обновление встроенного программного обеспечения. Поскольку шлюзы или приборы учета, а также их коммуникационные модули становятся все более сложными, то достаточно полезной выглядит функция удаленного обновления встроенного программного обеспечения, позволяющая исправить ошибки или добавить новый функционал.
• Информация о стоимости. Передача информации о стоимости может быть реализована несколькими способами. Анализ различных подходов по передаче тарифов и сравнение протоколов было сделано в работе [13]. В этой статье не анализируются протоколы относительно их тарифной поддержки.

B. Возможность инициативной передачи

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

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

С. Наличие интерфейсной объектной модели

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

D. Встроенные механизмы безопасности

Большинство установленных интеллектуальных приборов учета требуют большего внимания в части безопасности AMI систем. Протокол может иметь встроенные механизмы безопасности, например, шифрование или он может оставить эту процедуру для протоколов более низких уровней, например, TLS (Transport layer security).

IV. Качественный анализ

A. SML

SML (Smart Message Language) был разработан в рамках проекта SyM² (Synchronous Modular Meter) [14]. Протокол SML широко используется в Германии и является частью большой работы по стандартизации интеллектуального учета потребления [15]. До сих пор, SML редко используется за пределами Германии, однако такое положение дел может измениться, если усилия по продвижению SML протокола как международного стандарта окажутся успешными. Тем не менее, будет полезным сравнить международные стандарты DLMS\COSEM и IEC 61850 с протоколом SML. Так как подобное сравнение может привести к ценным улучшения рассматриваемых международных стандартов.

SML отличается от DLMS/COSEM и IEC 61850 тем, что он определяет сообщения, вместо определения интерфейсной объектной модели и сервисов доступа к ней. SML, для определения иерархической структуры сообщений, использует форму подобную ASN.1. Сообщения кодируются специальным шифром, который будет рассмотрен в пятом разделе. Может быть два типа сообщений, или запрос, или ответ. Однако сообщение типа «ответ» может быть послано без запроса. Таким образом, SML не следует строгим принципам клиент-серверной архитектуры и приборы учета могут выдавать инициативные сообщения.

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

SML не имеет встроенных механизмов безопасности за исключением простых полей «имя пользователя» и «пароль» в сообщениях SML. Для передачи данных по TCP/IP может использоваться протокол SSL/TLS.

B. DLMS/COSEM

DLMS (Device Language Message Specification) и COSEM (COmpanion Specification for Energy Metering) вместе образуют протокол прикладного уровня DLMS/COSEM [5] и интерфейсную модель для приложений учета [6]. Использую промежуточный уровень, определенный в [16], DLMS/COSEM может использоваться для передачи данных через TCP/IP и UDP/IP.

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

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

DLMS/COSEM поддерживает синхронизацию часов и передачу измерительных профилей. До сих пор DLMS/COSEM, описанный в [5] и [6] не поддерживает передачу цифровых подписей вместе с измерительными данными, а также не поддерживает загрузку новой версии встроенного программного обеспечения. Однако этот функционал будет поддержан в будущем. Уже сейчас имеются объекты для проведения операции обновления встроенного программного обеспечения, описанные в голубой книге 10 редакции. Поддержка цифровых подписей находится в работе, этим занимается организация DLMS UA.

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

C. IEC 61850

MMS и SOAP отображение IEC 61850 не различаются в плане поддержки качественных критериев, которые рассматриваются в данной работе. Поэтому все ниже сказанное будет справедливо для обоих протоколов.

IEC 61850 – это группа стандартов разработанная специально для использования в автоматизации подстанций. К настоящему времени стандарт был расширен, и теперь он покрывает управление гидроэлектростанциями [17], ветряные турбины [18] и другие распределённые энергетические ресурсы [19]. В работе [19] стандарты DLMS/COSEM и ANSI C12.19 упоминаются как стандарты, применяемые для коммерческого учета. IEC 61850 применяется там, где нет требований по коммерческому учету. Это различие между коммерческим учетом и другими типами учетов, как представляется, является больше политическим нежели техническим. Поскольку технических причин не использовать IEC 61850 в качестве протокола для коммерческого учета нет.

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

Интерфейсная объектная модель IEC 61850 состоит из свободно компонуемых логических устройств (LD). Логические устройства состоят из одного или нескольких логических узлов (LN). IEC 61850-7-4, для измерения, определяет логический узел MMRT. Совместно с сервисами ведения журналов и/или составления отчетов эти логические узлы могут быть использованы для передачи профилей нагрузки. Цифровые подписи не являются частью логического узла и поэтому не поддерживаются. Механизм обновления встроенного программного обеспечения также не поддерживается этим стандартом. Для синхронизации времени и MMS, и SOAP отображение используют протокол SNTP.

Когда используется MMS отображение, сервер может посылать данные без явного запроса, через механизм создания отчетов IEC 61850. Ассоциация и таким образом открытое соединение сокета TCP должны инициироваться клиентом заранее. SOAP отображение не поддерживает активное создание отчетов сервером.

Ни у MMS, ни у SOAP отображения нет встроенных механизмов безопасности. Этот функционал оставляют протоколу TLS/SSL, как рекомендуется в [20].

D. Сравнение

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

Таблица 1 – Сравнение протоколов SML, DLMS/COSEM и IEC 61850


DLMS/COSEM обладает тем преимуществом по сравнению с SML, что он уже является международным стандартом, который широко используется в Европе. Многочисленные команды работают над тем чтобы добавить недостающие опции к этому стандарту. Тот факт, что DLMS/COSEM определяет свой собственный механизм безопасности не обязательно является преимуществом. Поскольку функционал связанный с обеспечением безопасности ограничивается лишь применением шифрования с симметричным ключом. Если бы приборы учета объединяли свои результаты измерения с цифровыми подписями, то так или иначе, они бы нуждались в ассиметричных ключах и могли бы использовать те же пары ключей для SSL/TLS, если бы это было разрешено.

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

V. Анализ эффективности

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

A. Доступ к показаниям мгновенных значений

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

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

• SML определяет сообщение типа GetList для получения мгновенных значений измеряемых величин. Сообщение запроса содержит имена параметров или списков параметров, которые должны быть считаны. Ответ содержит запрашиваемый список значений. Буду проанализированы два сценария:
  
  • SML прибор учета или шлюз предварительно параметризируются со списком параметров, которые должны быть считаны вместе. Таким образом для того чтобы получить все параметры/значения, связанные с именем списка, достаточно будет отправить серверу имя этого списка.
  • Прибор учета или шлюз предварительно не параметризируются и для получения желаемых показаний необходимы явные запросы.
• DLMS/COSEM определяет сервис GET для получения мгновенных значений показаний. Get-Request может содержать список так называемые COSEM Attribute Descriptors, однозначно определяющие точные параметры, которые должны быть считаны. Ответ, в этом случае, содержит список значений параметров без повторения, ассоциированного дескриптора.
• IEC 61850 предлагает сервисы для управления и получения доступа к так называемым наборам данным. Таким образом набор данных, содержащий произвольное число точек данных, может быть создан динамически. Впоследствии набор данных может быть получен, достаточно эффективно, используя сервис GetDataSetValue.

Далее определяются размеры сообщений соответствующих запросов и ответов. Точнее, определяются уравнения, по которым рассчитывается размер TCP SDU (Service Data Unit) в зависимости от числа запрашиваемых измеренных значений. Несколько параметров в сообщениях запроса и ответа имеют переменную длину. По этой причине, всегда выбираются параметры с наиболее короткой длинной. Кроме того, используя рассматриваемые протоколы можно запросить достаточно большое число данных. Поэтому, для того чтобы сравнить протоколы, будет рассмотрен запрос для значений измерений в виде четырех байт целых чисел. Размер пакета определен частично из реализации фактических коммуникационных протоколов [21] и захвата трафика, а также частично, используя аналитические модели.

Для SML размер TCP SDU сообщений запроса и ответа рассчитывается следующим образом:

SML Req = SML TP V 1 + OpenReq + GetListReq + CloseReq + StuffedBits
SML Res = SML TP V 1 + OpenRes + GetListRes + CloseRes + StuffedBits

SML, потенциально, может быть использован с различными схемами кодирования, но на практике, используется только двоичное кодирование SML Binary Encoding. Для сценария с предварительно не параметризованными параметрами размер GetListReqPDU в байтах для передачи x значений, с применением двоичной кодировки SML Binary Encoding, может быть рассчитан следующим образом:

SML Req = 16 + 28 + 30x + 19 + 0
SML Res = 16 + 27 + 45x + 19 + 0

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

SML Req = 16 + 28 + 30 + 19 + 0
SML Res = 16 + 27 + (26 + 19x) + 19 + 0

Состав и размер TCP SDU DLMS/COSEM, при передаче x значений описывается следующими уравнениями:

DLMS Req = TCP Wrapper + GetReqWithList = 8 + (4 + 11x)
DLMS Res = TCP Wrapper + GetResWithList = 8 + (4 + 6x)

Состав и размер TCP SDU MMS:

MMS Req = RFC 1006 and ISO 8073 + ISO 8327 Session + ISO Presentation + MMS GetListReqPDU = 7 + 4 + 9 + 44
MMS Res = RFC 1006 and ISO 8073 + ISO 8327 Session + ISO Presentation + MMS GetListResPDU = 7 + 4 + 9 + (10 + 6x)

Состав и размер TCP SDU SOAP:

SOAP Req = SOAP Header + SOAP Req XML = 197 + 236
SOAP Res = SOAP Header + SOAP Res XML = 113 + (175 + 32x)

Полученные размеры сообщений приведены в таблице 2. Кроме того, размер ответного сообщения приведен в виде графика на рисунке 2. Из этого рисунка видно, что DLMS и MMS являются наиболее эффективными протоколами в плане размера сообщений. Однако не стоит забывать о том, что DLMS и IEC 61850 требуют наличия ассоциации для того, чтобы осуществить обмен сообщениями. В протоколе SML наличие ассоциации не требуется. Накладные расходы, связанные с установлением ассоциации не были учтены для этих расчетов. Однако ими можно пренебречь, если ассоциация устанавливается один раз и поддерживается в течении длительного периода времени.

Таблица 2 – Размер поля данных TCP в байтах как функция числа запрашиваемых значений (х).



Рисунок 2 – Размер ответного сообщения

B. Сравнение двоичных кодировок

Все протоколы, MMS, DLMS/COSEM и SML используют побайтовую двоичную кодировку для кодирования своих сообщений. В этом разделе сравниваются, непосредственно, кодировки.

Протокол MMS использует ASN.1 BER кодировку для кодирования сообщений. DLMS/COSEM также использует BER кодировку для сообщений ассоциации, однако после установления ассоциации, используются специальные правила кодирования, так называемые A-XDR, определенные в [22]. A-XDR правила были разработаны для сокращения объема информации, по сравнению с BER и применяются только для кодирования подмножества ASN.1. Протокол SML, в свою очередь, также определяет новые правила кодирования под название SML Binary Encoding. Цель всё та же что и у A-XDR – уменьшение размера сообщения по сравнению с BER. При использовании BER кодировки, обычно требуется один байт для поля, отвечающего за тип значения, и один байт для поля, содержащего информацию о длине закодированного значения. В случае SML Binary Encoding, при наличии возможности, тип и длинна кодируются в одном байте. В A-XDR, поля типов значений и длины вообще опускаются там, где это возможно.

Три рассмотренные двоичные кодировки сравниваются путем кодирования ответного сообщения MMS GetDataValues. В таблице 3 приведено количество байтов, необходимых для кодирования различных компонентов MMS сообщения.

Таблица 3 – Сравнение длин сообщений при различных кодировках (в байтах)


Как видно из таблицы 3, A-XDR требуется наименьшее количество байтов для кодирования пакета. A-XDR кодирует также эффективно как и BER, а в некоторых случаях, за исключением невыбранных дополнительных полей, даже лучше. SML Binary Encoding не кодирует с наименьшим числом байтов для всех случаев. Это связано с тем что, тэги в выборе кодируются как минимум с помощью двух байтов. Вся «эффективность» A-XDR и SML Binary Encoding связана с полями типов и длины. Фактические значения закодированы равным количеством байтов.

VI. Заключение

В этой работе были определенны наиболее значимые качественные критерии для протокола прикладного уровня применяемого для интеллектуального учета потребления. Сравнение протоколов DLMS/COSEM, SML и IEC 61850 показало, что нет единственного протокола, лучшего во всех аспектах. Анализ и сравнение размера сообщения показал, что DLMS и MMS IEC 61850 явно превосходят все остальные. И DLMS/COSEM, и SML используют специальные кодировки для более эффективного кодирования, по сравнению с BER, однако у SML Binary Encoding есть значительные недостатки при кодировании тегов выбора ASN.1 элементов. A-XDR делает хорошую работу в сокращении издержек вызванных полями типа и длинны.

В будущем было бы интересно сделать подобное сравнение для таких многообещающих протоколов, как ZigBee Smart Energy 2.0 и ANSI C12.19.

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

1. E. Commission, “M/441 EN, standardisation mandate to CEN, CENELEC and ETSI in the field of measuring instruments for the development of an open architecture for utility meters involving communication protocols enabling interoperability,” Mar. 2009.
2. NIST, “NIST framework and roadmap for smart grid interoperability standards, release 1.0,” 2010.
3. DKE, “Die deutsche normungsroadmap E-Energy/Smart grid,” Apr.2010.
4. S. P. Group, “Smart message language (SML) v. 1.03,” Dec. 2008.
5. “IEC 62056-53 — data exchange for meter reading, tariff and load control – part 53: COSEM application layer,” 2006.
6. “IEC 62056-62 — data exchange for meter reading, tariff and load control – part 62: Interface classes,” 2006.
7. “IEC 61850-8-1 ed1.0 — communication networks and systems in substations — part 8-1: Specific communication service mapping (SCSM) — mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC 8802-3,” May 2004.
8. “IEC 61400-25-4 ed1.0 — wind turbines — part 25-4: Communications for monitoring and control of wind power plants — mapping to communication profile,” 2008.
9. K. D. Craemer and G. Deconinck, “Analysis of state-of-the-art smart metering communication standards,” Leuven, 2010.
10. S. Mohagheghi, J. Stoupis, Z. Wang, Z. Li, and H. Kazemzadeh, “Demand response architecture: Integration into the distribution management system,” in Smart Grid Communications (SmartGridComm), 2010 First IEEE International Conference on, 2010, pp. 501–506.
11. A. Zaballos, A. Vallejo, M. Majoral, and J. Selga, “Survey and performance comparison of AMR over PLC standards,” Power Delivery, IEEE Transactions on, vol. 24, no. 2, pp. 604–613, 2009.
12. T. Otani, “A primary evaluation for applicability of IEC 62056 to a Next-Generation power grid,” in Smart Grid Communications (Smart- GridComm), 2010 First IEEE International Conference on, 2010, pp. 67–72.
13. S. Feuerhahn, M. Zillgith, and C.Wittwer, “Standardized communication of Time-of-Use prices for intelligent energy management in the distribution grid,” in VDE Kongress 2010 — E-Mobility, Leipzig, Germany, Nov. 2010.
14. SyMProjectGroup, “SyM — general specification for synchronous modular meters,” Oct. 2009.
15. VDE, “Lastenheft MUC — multi utility communication, version 1.0,” May 2009.
16. “IEC 62056-47 — data exchange for meter reading, tariff and load control – part 47: COSEM transport layers for IPv4 networks,” 2006.
17. “IEC 61850-7-410 ed1.0 — communication networks and systems for power utility automation — part 7-410: Hydroelectric power plants — communication for monitoring and control,” Aug. 2007.
18. “IEC 61400-25-2 ed1.0 — wind turbines — part 25-2: Communications for monitoring and control of wind power plants — information models,” Dec. 2006.
19. “IEC 61850-7-420 ed1.0 — communication networks and systems for power utility automation — part 7-420: Basic communication structure – distributed energy resources logical nodes,” Oct. 2009.
20. “IEC/TS 62351-1 ed1.0 — power systems management and associated information exchange — data and communications security — part 1: Communication network and system security — introduction to security issues,” May 2007.
21. “openMUC — software platform for energy gateways,” www.openmuc.org, 2011. [Online]. Available: www.openmuc.org
22. “IEC 61334-6 — distribution automation using distribution line carrier systems – part 6: A-XDR encoding rule,” 2000.