Порівняння комунікаційних протоколів DLMS/COSEM, SML і IEC 61850 для додатків інтелектуального обліку споживання

Технології зв'язку відіграють все більш важливу роль у зростаючому ринку 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) був розроблений в рамках проекту SyM2 (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-Запит може містити список так звані COSEM Attribute is invalid, однозначно визначають точні параметри, які повинні бути прочитані. Відповідь, в цьому випадку, містить список значень параметрів без повторення, асоційованого дескриптора.
  • 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


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

Req SML = 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 mapping service (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 communication to 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 specifications for synchronous modular meters,» Oct. 2009.
  15. VDE, «Lastenheft MUC — multi utility communication, версія 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 automation utility — 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 automation utility — 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.



Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.