成長するAMI市場で通信技術はますます重要な役割を果たしています。 この記事は、インテリジェントな消費アカウンティングに使用される4つのアプリケーションレベルのプロトコルの完全な分析と比較です。 次のプロトコルが考慮されます。DLMS/ COSEM、SML（スマートメッセージ言語）、およびMMSおよびSOAPマッピングIEC61850。作業は、TCP / IPスタックと組み合わせたこれらのプロトコルの使用に焦点を当てています。 プロトコルは、最初に定性的基準、たとえば時間同期の可能性などに関して比較されます。その後、メッセージのサイズが比較され、コーディング効率が分析されます。



AMI（高度な計測インフラストラクチャ）は、スマート計測デバイス、通信ネットワーク、およびデータ管理システムの統合システムであり、サービスプロバイダーと消費者間の双方向通信が含まれます。

I.はじめに

AMIシステムの数とサイズは急速に成長しています。 これらは、家庭に設置され、サービスプロバイダーとの双方向通信をサポートするスマートメータリングデバイスで構成されています。 このようなシステムの導入は、主に次の3つの目標の達成に関連しています。

1. 消費者に消費量とコストに関する情報を提供し、リソースのより経済的な使用に貢献します。
2. 高負荷の期間から低負荷の期間へのリソース使用の再分配。
3. 流通ネットワーク内の他のスマートグリッドアプリケーションですぐに使用できるインフラストラクチャを作成します。

スマートメータリングデバイスでの通信は、いくつかの標準化作業（ たとえば [1]）の対象であり、スマートグリッド専用の国内ロードマップの一部です[2、3]。 しかし、これまでのところ、インストールされているほとんどのAMI機器は、オープンまたは国際規格に準拠していない独自のプロトコルを使用しています。 ただし、将来的には、オープンスタンダードに焦点を当てる必要があります。 これにより、自由市場での競争が発生し、設備コストが削減されます。



この記事では、スマートメータリングに使用される4つの異なるアプリケーション層プロトコルを比較します。 このプロトコルは、SML（ スマートメッセージ言語、IEC 62056-58ドラフト ）[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と比較されています。 DLMS / COSEMの詳細な分析は、[12]に記載されています。 この記事は、品質基準とコーディング効率について、DLMS / COSEM、SML、およびIEC 61850プロトコルを比較した最初の記事です。



この記事は次のように構成されています。 2番目のセクションでは、スマートメータリングで使用される一般的なネットワークトポロジについて説明します。 問題のプロトコルを使用できる場所が示されています。 3番目のセクションでは、4番目のセクションでプロトコルを分析および比較する定性的基準について説明します。 5番目のセクションでは、検討中のプロトコルのメッセージサイズとコーディング効率を分析します。 結論は結論です。

II。 インテリジェントな消費量測定システムの通信トポロジー

AMIシステムで通信を整理するには、さまざまなネットワークトポロジが使用されます。 ただし、ほとんどのトポロジは、 図1に示す一般的な形式から取得できます。 この図では、ガス、電気、水、熱のメーターがいわゆる「ホームゲートウェイ」に接続されており、それを通じて外部の世界とのインターフェースが実現されています。 ほとんどの場合、このゲートウェイは実際に電力量計に統合されています。 ガス、水、熱のメーターは、主に自律的なソースから電力を供給されるという点で特別であることに注意してください。 この機能は、回線（ b ）の通信プロトコルを選択するときに考慮する必要があります。 ゲートウェイ（または電気メーター）は、インターネット接続（ c ）またはデータコンセントレーター（ dおよびe ）を介して、サービスプロバイダー側​​のデータ収集システムに接続できます。dは通常、電力線またはワイヤレスメディアソリューションです。アクションの半径。









図1-スマートメータリングの通信トポロジ



この記事で説明するアプリケーション層プロトコルは、データ交換にTCP / IPプロトコルスタックを使用できます。したがって、インターネット接続（ cおよびe ）を介した通信の整理に適しており、次のようなローカルネットワークでのデータ交換にも使用できますイーサネットおよびWiFi（ a ）。 さらに、検討中のプロトコルの一部は、他の低レベルプロトコルを使用したデータ交換をサポートしています。 DLMS / COSEMは、UDP、HDLC、M-Bus、およびIEC 61334-5などのさまざまな電力線通信プロトコルを介したデータ交換をサポートしています。 SMLは、シリアル通信とM-Busプロトコルをサポートしています。 MMSおよびSOAPは、追加の下位層プロトコルをサポートしていません。

III。 品質基準

このセクションでは、4番目のセクションでプロトコルを分析および比較する定性的基準について説明します。

A.さまざまな種類の情報のサポート

消費量のスマートメータリングに使用されるアプリケーション層プロトコルは、さまざまな種類の情報を送信するためのサポートに関して比較できます。 AMIシステムの場合、原則として、次の種類の情報を転送するには通信技術が必要です。

• 測定結果 。 当然、考慮されるすべてのプロトコルは、測定データ（エネルギー、電力、電圧、体積など）の送信をサポートします。 ただし、プロトコルは、次のような種類の情報のサポートが異なる場合があります。
  
  
  • プロファイルをロードします 。 メーターは、負荷プロファイルを保存できます（ たとえば 、15分の解像度で）。 したがって、プロトコルは、必要に応じて適切なタイムスタンプを使用してこれらのプロファイルを転送できる必要があります。
  • デジタル署名 。 データの整合性を第三者に証明するために、測定結果にデジタル署名することができます。
• クロック同期情報 。 時刻の同期は、負荷プロファイルを保存する計測デバイスや、スケジュールに基づいて料金表間で迅速に切り替える計測デバイスにとって重要です。
• ファームウェアの更新 。 ゲートウェイまたは計測デバイス、およびそれらの通信モジュールがますます複雑になっているため、エラーを修正したり新しい機能を追加したりできるリモートファームウェアアップデート機能は非常に便利に見えます。
• コスト情報 。 コスト情報の送信は、いくつかの方法で実装できます。 [13]で、関税の移転とプロトコルの比較に対するさまざまなアプローチの分析が行われました。 この記事では、関税サポートに関するプロトコルを分析していません。

B.プロアクティブな転送の可能性

アプリケーション層プロトコルは、厳密なクライアント/サーバー原則に従うことができます。この場合、接続または関連付けはクライアントのみによって確立されます。 サーバーはメーターのデータ（メーター自体など）を保存するデバイスであり、クライアントはこのデータにアクセスしたり、サーバーデバイスにパラメーターを設定したりするデバイスです。



プロトコルは、ピアツーピアの原則に基づくこともできます。この場合、情報が送信される2つのオブジェクトには同じ機会があります。 オブジェクトはいつでもクライアントまたはサーバーの役割を果たすことができます。 この原理により、測定デバイスはクライアントからの接続を必要とせずに他のデバイスにデータを送信できるため、プロトコルをより柔軟に使用できます。

C.インターフェイスオブジェクトモデルの可用性

クライアント/サーバーアーキテクチャ指向のプロトコルであるDLMS / COSEMおよびIEC 61850では、サーバーには、サーバーデバイス（ たとえば 、計測デバイス）を表すインターフェイスオブジェクトモデルと呼ばれるものが含まれています。 このモデルは、オブジェクト指向のアプローチを使用して構築され、クライアントの可視情報インターフェースとして機能します。 クライアントは、プロトコルを使用して標準化された方法でインターフェイスオブジェクトモデルを取得できるため、サーバーの正確な構造と機能について事前に知る必要がありません。 この場合、彼らはサーバーが自分自身を記述すると言います。 一方で、取得可能なインターフェイスオブジェクトモデルは、さまざまなモデルに自動的に一致するようにクライアントをプログラムできるという意味で、データ交換メカニズムを簡素化します。 一方、サーバーには常にインターフェイスオブジェクトモデルが含まれているため、このモデルはクライアントサーバー構造を統合します。

D.組み込みのセキュリティメカニズム

設置されているほとんどのスマートメータリングデバイスは、AMIシステムのセキュリティにより注意を払う必要があります。 プロトコルには、暗号化などのセキュリティメカニズムが組み込まれている場合があります。または、TLS（トランスポートレイヤーセキュリティ）などの低レベルプロトコル用にこの手順を残す場合があります。

IV。 定性分析

A. SML

SML（ スマートメッセージ言語 ）は、SyM ² （ 同期モジュラーメーター ）プロジェクトの一部として開発されました[14]。 SMLプロトコルはドイツで広く使用されており、スマート消費量測定の標準化に関する大規模な作業の一部です[15]。 これまで、SMLはドイツ以外ではめったに使用されていませんでしたが、SMLプロトコルを国際標準として推進する取り組みが成功すれば、これは変わる可能性があります。 ただし、国際DLMS \ COSEMおよびIEC 61850標準をSMLプロトコルと比較すると便利です。 そのような比較は、考慮される国際標準の価値ある改善につながる可能性があるためです。



SMLは、インターフェイスオブジェクトモデルとそのア​​クセスサービスを定義する代わりに、メッセージを定義するという点でDLMS / COSEMおよびIEC 61850と異なります。 SMLは、ASN.1に類似した形式を使用して、メッセージの階層構造を定義します。 メッセージは特別な暗号でエンコードされます。これについては、5番目のセクションで説明します。 2種類のメッセージ、要求、または応答があります。 ただし、リクエストなしで「応答」メッセージを送信できます。 したがって、SMLはクライアント/サーバーアーキテクチャの厳密な原則に従っておらず、計測デバイスはプロアクティブなメッセージを発行できます。



メッセージ形式は、負荷プロファイルと関連するデジタル署名の転送をサポートしています。 さらに、新しいファームウェアイメージとクロック同期を転送することもできますが、これらの手順は他の規格で説明されています（ たとえば 、[14]）。



SMLには、SMLメッセージの単純なユーザー名フィールドとパスワードフィールドを除き、セキュリティメカニズムが組み込まれていません。 SSL / TLSを使用して、TCP / IPを介してデータを送信できます。

B. DLMS / COSEM

DLMS（ デバイス言語メッセージ仕様 ）およびCOSEM（ エネルギー計測用のコンパニオン仕様 ）は、DLMS / COSEMアプリケーション層プロトコル[5]および計測アプリケーション用のインターフェースモデル[6]を一緒に形成します。 [16]で定義されている中間層を使用すると、DLMS / COSEMを使用して、TCP / IPおよびUDP / IPを介してデータを送信できます。



DLMS / COSEMは、厳密なクライアントサーバーアーキテクチャに基づいています。 サーバーは計測デバイスであり、クライアントは計測デバイスにアクセスするデバイスです。 クライアントは、たとえば、サービスプロバイダー側​​のゲートウェイまたはデータ収集デバイスです。 サーバーがゲートウェイに直接配置され、クライアントがサービスプロバイダーの側にある場合など、他のオプションも可能です。



実際の測定値を含む情報を交換する前に、いわゆる関連付けを確立する必要があります。 この操作はクライアントによって開始されます。 アソシエーションが確立された後、DLMSクライアントはサーバーにあるインターフェイスオブジェクトモデルにアクセスできます。 DLMSサーバーは、確立されると、明示的な要求なしでクライアントに通知を送信できます。



DLMS / COSEMは、クロック同期と測定プロファイルの転送をサポートしています。 これまで、[5]および[6]で説明されているDLMS / COSEMは、測定データとともにデジタル署名の送信をサポートしておらず、ファームウェアの新しいバージョンのダウンロードもサポートしていません。 ただし、この機能は将来サポートされる予定です。 現在、第10版のブルーブックに記載されているファームウェアの更新操作のオブジェクトがあります。 デジタル署名のサポートは作業中です。これはDLMS UAによって行われます。



DLMS / COSEMには、対称暗号化に基づく認証およびプライバシーサービスが含まれています。 ただし、このプロトコルはTLS / SSLをサポートしていないため、非対称キーを使用して上記のサービスを実装できます。 非対称暗号化のサポートは開発中です。CENELECの第13技術委員会の第2ワーキンググループがこれに取り組んでいます。

C. IEC 61850

IEC 61850のMMSおよびSOAPマッピングは、このペーパーで検討されている品質基準のサポートに関して違いはありません。 したがって、上記のすべてが両方のプロトコルに当てはまります。



IEC 61850は、変電所の自動化で使用するために特別に設計された標準のグループです。 今日まで、この標準は水力発電管理[17]、風力タービン[18]、およびその他の分散型エネルギー資源[19]を対象に拡大されています。 [19]では、DLMS / COSEMおよびANSI C12.19標準は、商業会計に使用される標準と呼ばれています。 IEC 61850は、商業会計の要件がない場合に適用されます。 商業会計と他の種類の会計のこの区別は、技術的というよりも政治的なもののようです。 商業会計のプロトコルとしてIEC 61850を使用しない技術的な理由はないため。



IEC 61850は、DLMS / COSEMと同じクライアント/サーバーアーキテクチャの原則に基づいて動作します。 サーバーには、標準化されたサービスからアクセス可能なインターフェイスオブジェクトモデルが含まれています。 これらのサービスがどの程度正確に転送されるかは、使用されるディスプレイ（MMSやSOAPなど）によって異なります。



IEC 61850インターフェイスオブジェクトモデルは、自由に構成可能なロジックデバイス（LD）で構成されています。 論理デバイスは、1つ以上の論理ノード（LN）で構成されます。 IEC 61850-7-4は、測定のために、MMRT論理ノードを定義します。 これらの論理ノードは、ロギングサービスやレポートサービスとともに、負荷プロファイルの転送に使用できます。 デジタル署名は論理ノードの一部ではないため、サポートされていません。 ファームウェア更新メカニズムもこの標準ではサポートされていません。 MMSとSOAPの両方のマッピングは、SNTPプロトコルを使用して時刻を同期します。



MMSマッピングを使用すると、サーバーはIEC 61850レポートエンジンを介して明示的な要求なしにデータを送信できるため、アソシエーション、したがってオープンTCPソケット接続はクライアントによって事前に開始する必要があります。 SOAPマッピングは、アクティブサーバーレポートをサポートしていません。



MMSマッピングもSOAPマッピングも、組み込みのセキュリティメカニズムを備えていません。 [20]で推奨されているように、この機能はTLS / SSLプロトコルに任されています。

D.比較

表1は、検討中のプロトコルの特定の定性的基準のサポートに関する情報を提供します。 SMLプロトコルと他の2つのプロトコルの主な違いは、SMLがインターフェイスオブジェクトモデルに基づいていないため、このプロトコルが機能レベルでの標準化を特に重要視していないことです。 一方では、これによりプロトコルの使用に柔軟性が与えられ、他方では、相互運用性を保証するために詳細（たとえば、デバイスでサポートされるメッセージタイプ）を他の標準で定義する必要があります。 SMLは、デジタル署名の転送をサポートする唯一のプロトコルです。



表1-SML、DLMS / COSEMおよびIEC 61850プロトコルの比較





DLMS / COSEMは、すでにヨーロッパで広く使用されている国際標準であるという点で、SMLより優れています。 多くのチームがこの標準に欠けているオプションを追加するために取り組んでいます。 DLMS / COSEMが独自のセキュリティメカニズムを定義しているという事実は、必ずしも利点ではありません。 セキュリティに関連する機能は、対称キーによる暗号化の使用によってのみ制限されるため。 メータリングデバイスが測定結果をデジタル署名と組み合わせた場合、何らかの方法で非対称キーが必要になり、許可されている場合はSSL / TLSに同じキーペアを使用できます。



IEC 61850は、他の規格と比較して、消費のスマートメータリングだけでなく、他のスマートグリッドアプリケーションにも使用できます。 ただし、現時点では、このプロトコルをスマートメータリングアプリケーションでより機能的にすることにほとんど関心がありません。

V.パフォーマンス分析

前のセクションでは、プロトコルは品質基準に関して分析されました。 このセクションでは、さまざまなプロトコルの有効性の分析を提供します。 特に、各プロトコルによって送信されたバイトの総数が考慮されます。 この場合、すべてのプロトコルが異なるメッセージ構造と異なる暗号化スキームを使用してさまざまなタイプの情報の転送をサポートするため、プロトコル比較は簡単なタスクではありません。 このため、1つの操作、つまり瞬時値の読み取り値へのアクセスを選択して、次のサブセクションのプロトコルを比較しました。その後、さまざまな暗号化スキームに特化したサブセクションがあります。

A.瞬時の測定値へのアクセス

瞬時の測定値を取得することは、すべてのプロトコルでサポートされている基本的な操作です。 このため、この操作が比較の基礎として選択されました。



最初に、各プロトコルの測定デバイスから読み取り値を取得するメカニズムについて説明し、次にそれらのメッセージのサイズを比較します。 問題の4つのプロトコルは、次の方法を使用して瞬時の読み取り値にアクセスします。

• SMLはGetListメッセージを定義して、瞬時の測定値を取得します。 要求メッセージには、読み取られるパラメーターの名前またはパラメーターのリストが含まれています。 応答には、要求された値のリストが含まれます。 2つのシナリオが分析されます。
  
  
  • SMLメーターまたはゲートウェイは、一緒に読み取らなければならないパラメーターのリストで事前パラメーター化されています。 したがって、リスト名に関連付けられているすべてのパラメーター/値を取得するには、このリストの名前をサーバーに送信するだけで十分です。
  • 計測デバイスまたはゲートウェイは事前にパラメーター化されておらず、目的の読み取り値を取得するには明示的な要求が必要です。
• DLMS / COSEMは、即時読み取り用のGETサービスを定義します。 Get-Requestには、いわゆるCOSEM属性記述子のリストが含まれている場合があります。これは、読み取る必要のある正確なパラメーターを一意に決定します。 この場合の答えには、関連する記述子を繰り返さずにパラメーター値のリストが含まれています。
• IEC 61850は、いわゆるデータセットの管理とアクセスのためのサービスを提供します。 したがって、任意の数のデータポイントを含むデータセットを動的に作成できます。 その後、GetDataSetValueサービスを使用して、データセットを非常に効率的に取得できます。

次に、対応する要求と応答のメッセージサイズが決定されます。 より正確には、式は、要求された測定値の数に応じてTCP SDU（ サービスデータユニット ）サイズを計算するために決定されます。 要求および応答メッセージのいくつかのパラメーターは可変長です。 このため、長さが最も短いパラメーターが常に選択されます。 さらに、問題のプロトコルを使用すると、十分な量のデータを要求できます。 したがって、プロトコルを比較するために、4バイトの整数形式の測定値のクエリを検討します。 パケットサイズは、実際の通信プロトコル[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バイナリエンコードのバイナリエンコードのみが使用されます。 以前にパラメーター化されていなかったパラメーターを使用したシナリオの場合、バイナリSMLバイナリエンコーディングを使用してx値を転送するためのGetListReqPDUのバイト単位のサイズは、次のように計算できます。



SMLリクエスト= 16 + 28 + 30x + 19 + 0

SML Res = 16 + 27 + 45x + 19 + 0



次の式は、パラメータが事前設定されたシナリオで有効です。



SMLリクエスト= 16 + 28 + 30 + 19 + 0

SML Res = 16 + 27 +（26 + 19x）+ 19 + 0



x値を送信するときのTCP SDU DLMS / COSEMの構成とサイズは、次の式で記述されます。



DLMS Req = TCP Wrapper + GetReqWithList = 8 +（4 + 11x）

DLMS Res = TCP Wrapper + GetResWithList = 8 +（4 + 6x）



TCP SDU MMSの構成とサイズ：



MMS Req = RFC 1006およびISO 8073 + ISO 8327セッション+ ISOプレゼンテーション+ MMS GetListReqPDU = 7 + 4 + 9 + 44

MMS Res = RFC 1006およびISO 8073 + ISO 8327セッション+ ISOプレゼンテーション+ MMS GetListResPDU = 7 + 4 + 9 +（10 + 6x）



TCP SDU SOAPの構成とサイズ：



SOAP Req = SOAPヘッダー+ SOAP Req XML = 197 + 236

SOAP Res = SOAPヘッダー+ SOAP Res XML = 113 +（175 + 32x）



受信したメッセージサイズを表2に示します 。 さらに、応答メッセージのサイズは、 図2のグラフ形式で示されています。 この図は、DLMSとMMSがメッセージサイズの観点から最も効果的なプロトコルであることを示しています。 ただし、DLMSとIEC 61850では、メッセージを交換するために関連付けが必要であることを忘れないでください。 SMLプロトコルでは、関連付けは必要ありません。 これらの計算では、関連付けの確立に関連するオーバーヘッドは考慮されませんでした。 ただし、アソシエーションが一度確立され、長期間維持される場合、それらは無視できます。



表2-要求された値の数（x）の関数としてのバイト単位のTCPデータフィールドサイズ。











図2-応答メッセージのサイズ

B.バイナリエンコーディングの比較

すべてのプロトコル、MMS、DLMS / COSEM、およびSMLは、バイトバイナリエンコーディングを使用してメッセージをエンコードします。 このセクションでは、エンコーディングを直接比較します。



MMSは、メッセージのエンコードにASN.1 BERエンコードを使用します。 DLMS / COSEMもアソシエーションメッセージにBERエンコーディングを使用しますが、アソシエーションが確立された後、[22]で定義された特別なエンコーディングルール、いわゆるA-XDRが使用されます。 A-XDRルールは、BERと比較して情報量を削減し、ASN.1のサブセットのコーディングにのみ適用されるように開発されました。 SMLプロトコルは、SMLバイナリエンコーディングと呼ばれる新しいエンコーディングルールも定義します。 目標はA-XDRと同じです-BERと比較してメッセージサイズを縮小します。 BERエンコードを使用する場合、通常、値のタイプを担当するフィールドには1バイト、エンコードされた値の長さに関する情報を含むフィールドには1バイトが必要です。 SMLバイナリエンコーディングの場合、可能であれば、タイプと長さは1バイトでエンコードされます。 A-XDRでは、値のタイプと長さのフィールドは通常、可能な限り省略されます。



検査された3つのバイナリエンコーディングは、MMS応答メッセージGetDataValuesをエンコードすることにより比較されます。 表3は、MMSメッセージのさまざまなコンポーネントをエンコードするために必要なバイト数を示しています。



表3-異なるエンコーディングのメッセージ長の比較（バイト単位）





表3からわかるように、A-XDRはパケットをエンコードするために最小限のバイト数を必要とします。 A-XDRはBERと同じくらい効率的にエンコードし、場合によっては、選択されていない追加フィールドを除き、さらに優れています。 SMLバイナリエンコーディングは、すべての場合に最小バイト数でエンコードするわけではありません。 これは、選択範囲内のタグが少なくとも2バイトでエンコードされているためです。 A-XDRおよびSMLバイナリエンコーディングのすべての「効率」は、タイプフィールドと長さフィールドに関連付けられています。 実際の値は、等しいバイト数でエンコードされます。

VI。 おわりに

この作業では、インテリジェントな消費アカウンティングに使用されるアプリケーションレベルのプロトコルの最も重要な定性的基準が決定されました。 DLMS / COSEM、SML、およびIEC 61850プロトコルの比較により、あらゆる面で最適な単一のプロトコルは存在しないことが示されました。 メッセージサイズの分析と比較により、DLMSおよびMMS IEC 61850が他のすべてより明らかに優れていることが示されました。 DLMS / COSEMとSMLはどちらも、BERよりも効率的なエンコードのために特別なエンコードを使用しますが、ASN.1要素選択タグをエンコードする場合、SMLバイナリエンコードには重大な欠点があります。 A-XDRは、タイプフィールドと長さフィールドによって生じるコストを削減する上で優れた役割を果たします。



将来的には、ZigBee Smart Energy 2.0やANSI C12.19などの有望なプロトコルについて同様の比較を行うことは興味深いでしょう。

参照資料

1. E.委員会、「M / 441 EN、相互運用性を可能にする通信プロトコルを含むユーティリティメーターのオープンアーキテクチャの開発のための測定器の分野におけるCEN、CENELEC、およびETSIの標準化指令」 2009年。
2. NIST、「NISTフレームワークとスマートグリッド相互運用性標準のロードマップ、リリース1.0」2010。
3. DKE、「Die deutsche normungsroadmap E-Energy / Smart grid」、2010年4月。
4. SPグループ、「スマートメッセージ言語（SML）v。 1.03、「12月 2008年。
5. 「IEC 62056-53-検針、料金、負荷制御のためのデータ交換-パート53：COSEMアプリケーション層」、2006年。
6. 「IEC 62056-62-検針、料金、負荷制御のためのデータ交換-パート62：インターフェースクラス」、2006年。
7. 「IEC 61850-8-1 ed1.0-変電所の通信ネットワークおよびシステム-パート8-1：特定の通信サービスマッピング（SCSM）-MMS（ISO 9506-1およびISO 9506-2）およびISO / IECへのマッピング8802-3、「2004年5月。
8. 「IEC 61400-25-4 ed1.0-風力タービン-パート25-4：風力発電所の監視と制御のための通信-通信プロファイルへのマッピング」、2008年。
9. KDクレーマーとG.デコニンク、「最先端のスマートメータリング通信標準の分析」、ルーベン、2010年。
10. S. Mohagheghi、J。Stoupis、Z。Wang、Z。Li、H。Kazemzadeh、「デマンドレスポンスアーキテクチャ：配信管理システムへの統合」、Smart Grid Communications（SmartGridComm）、2010 First IEEE International Conference on、2010 、pp。 501-506。
11. A. Zaballos、A。Vallejo、M。Majoral、およびJ. Selga、「PLC規格に対するAMRの調査とパフォーマンスの比較」、Power Delivery、IEEE Transactions on、vol。 24、いいえ。 2、pp。 604-613、2009。
12. T. Otani、「次世代電力グリッドへのIEC 62056の適用性に関する主要評価」、スマートグリッドコミュニケーション（Smart-GridComm）、2010年、最初のIEEE国際会議、2010年、pp。 67–72。
13. S. Feuerhahn、M。Zillgith、およびC. Wittwer、「配電網におけるインテリジェントなエネルギー管理のための使用時間価格の標準化された通信」、VDE Kongress 2010-E-Mobility、ライプツィヒ、ドイツ、11月 2010年。
14. SyMProjectGroup、「SyM-同期モジュラーメーターの一般仕様」、10月 2009年。
15. VDE、「ラステンヘフトMUC-マルチユーティリティ通信、バージョン1.0」2009年5月。
16. 「IEC 62056-47-メーターの読み取り、料金、負荷制御のためのデータ交換-パート47：IPv4ネットワークのCOSEMトランスポート層」、2006年。
17. 「IEC 61850-7-410 ed1.0-電力会社自動化のための通信ネットワークおよびシステム-パート7-410：水力発電所-監視および制御のための通信」 2007年。
18. 「IEC 61400-25-2 ed1.0-風力タービン-パート25-2：風力発電所の監視と制御のための通信-情報モデル」、12月 2006年。
19. 「IEC 61850-7-420 ed1.0-電力会社自動化のための通信ネットワークとシステム-パート7-420：基本的な通信構造-分散エネルギーリソース論理ノード」 2009年。
20. 「IEC / TS 62351-1 ed1.0-電力システム管理と関連情報交換-データと通信のセキュリティ-パート1：通信ネットワークとシステムのセキュリティ-セキュリティ問題の紹介」、2007年5月
21. 「OpenMUC-エネルギーゲートウェイ用のソフトウェアプラットフォーム」www.openmuc.org、2011年。[オンライン]。利用可能：www.openmuc.org
22. 「IEC 61334-6-配電線キャリアシステムを使用した配電自動化-パート6：A-XDRエンコーディングルール」2000