リアルタイムでの冗長化通信による高信頼性電力グリッド

今日の世界において、電力グリッドは不可欠のリソースです。特に、分散型発電の運用増大や、ローカルインテリジェンスによる監視や制御がさらに求められるマイクロ電力グリッドの出現により、電気ネットワークの信頼性が何よりも重要になりました。ネットワークが安定したACを常時供給できることを保証するためには、電力グリッドのすべてのシステムが協調し、電圧、周波数、スイッチ装置の状態が定期的に分析されている必要があります。これらの要件から、高度な監視機能、および制御センターとサブステーションなど高価値のノード間でレイテンシの短い通信を常に利用可能なことにより、各システムの状態が綿密に監視されていることの保証が求められます。

電力グリッドインフラストラクチャの管理と、必要なレベルの制御および通信を提供するため、配電業界はIEC 61580規格を採用しました。IEC 61580を使用すると、Ethernet技術を基盤とするネットワークにより、サブステーションと電気サブシステムとの間で、電力状態の情報をデジタル信号により転送できます。電力グリッド運用者の要求がますます複雑化することに対応するため、IEC 61580規格は多くのタイムクリティカルなサービス、たとえばIEEE 1588同期、GOOSE（Generic Object Oriented System Event）、SV（Sampled Value）メッセージングなどを包含するように進化してきました。

図1：IEC 61580の主要な要素と、それらのEthernetとの関係

GOOSEプロトコルは、パブリッシュ-サブスクライブ型のメッセージングをサポートします。これは多くのITシステムで使用されている従来型のクライアント-サーバー形式の通信モデルに比べ、分散型の制御アプリケーションにより適しています。IEC 61580には、クライアント-サーバー型のメッセージングも別途用意されており、リモートステーションによるデバイス管理や、サブステーションやマイクロ電力グリッド内のノードへ直接アクセスが必要な他の状況で利用可能です。

GOOSEでは、各種の電気的要素のステータスに関するリアルタイムメッセージを、そのメッセージを必要とするデバイスに中継可能です。たとえば各リレーがステータス情報を発行するときには、情報に含まれる単一の識別子を使用して、その識別子に対応するオブジェクトに必要なステータスを報告します。他のリレーやデバイスは、対象のリレーにより送出されるステータスメッセージのストリームにサブスクライブできます。これは、ネットワーク全体へのマルチキャストと、受信側ノードでのフィルタ処理によって行われるため、発行側はサブスクライバがどのデバイスなのか、また、相手がメッセージを受信したかどうかを感知する必要はありません。最高のパフォーマンスを達成するため、GOOSEは一般に採用されているTCP/IPプロトコルを使用しません。その代わりに、GOOSEメッセージはEthernetフレーム内に直接埋め込まれます。同様にSVメッセージングによって、電圧の測定値など急激に変化する値のデータを、サブスクライブしているレシーバに対してマルチキャストできます。

IEC 61580には、IEEE 1588規格に従う時刻同期サービスが含まれています。この規格では、高精度のグランドマスタクロックから抽出されたタイミング信号を配信します。今日使用されているシステムの多くでは、このグランドマスタクロックはGPS（Global Positioning System）衛星から伝送される時刻信号を使用します。これらの衛星にはそれぞれ原子時計が内蔵されています。グランドマスタクロックは、スレーブクロックのツリーへ時刻データを供給します。スレーブクロックは境界クロック（ゲートウェイに設置され、GPS信号が受信できない場合は一時的にマスタとして動作するもの）と、同期が必要な各システムに内蔵されている通常のクロックに分類されます。タイミング情報は、一連のメッセージ交換により、このツリー内で波紋状に伝達されます。すべてのシステムが同期状態に維持されていることを保証するには、この動作を定期的に繰り返す必要があります。

このプロトコルは、タイムスタンプが含まれている同期メッセージをマスタクロックがスレーブへ送出することにより動作します。その少し後で、マスタクロックは、それ以後のタイムスタンプを含むフォローアップを送信します。スレーブは応答として、遅延推定を要請するメッセージをマスタへ返信し、これはその応答が送信された時刻を含む別の応答とともに提供されます。この処理の終了時に、スレーブには4つのタイムスタンプが存在し、そのうち3つはマスタから送信されたものです。スレーブはシーケンス内のタイミング情報を使用して、マスタと可能な限り正確に一致するよう、自分の内部クロックをどれだけ修正する必要があるかを判定します。 このプロトコルの結果として得られるタイミング同期は、ローカルエリアネットワークにおいては一般に数十ナノ秒単位の精度を持ちます。

IEC 61580インフラストラクチャの他の主要部品として、冗長化データ転送プロトコルがあります。PRP（Parallel Redundancy Protocol）はIEC 62439で標準化されたもので、デュアルポートの全二重Ethernet通信をサポートします。このプロトコルは、GOOSEやSVなど上位レイヤのアプリケーションプロトコルから参照できるMACレイヤインターフェースの下で、冗長化パケット処理の2つのストリームを提供します。一般に、Ethernet接続は異なるEthernetスイッチを経由し、スター型配線のネットワークトポロジを想定しています。

図2：PRP冗長化プロトコルでは、スター型配線のトポロジを想定しています

別の方法としてHSR（High-availability Seamless Redundancy）があり、これもIEC 62439に定義されています。HSRではリング型トポロジを採用し、各パケットは複製され、リングに沿って逆方向へ、宛先に向かって転送されます。リング型のアーキテクチャでは、パケットが宛先へ到着するまでに複数のノードを通過する必要がある場合、追加のスイッチやルータを使用する必要がなく、それによる遅延増大が発生しません。高度な通信コントローラでは、カットスルー転送を使用して、この遅延を最小化できます。この手法では、パケットを完全にデコードせず、宛先への転送を開始できます。

図3：HSR冗長化プロトコルは、リング型トポロジ用です

受信Ethernetメッセージに対して大量のフィルタ処理が必要なため、IEC 61580では制御アルゴリズムに利用可能な計算能力を減らすことができる高性能の処理機能が要求されています。これに対する回答の1つは、ネットワークレベルの分析を可能な限りオフロードし、ホストプロセッサは自身が注意すべきメッセージのみを扱えばいいようにすることです。マルチコアSoCを使用すると、この目標を達成できます。これらのSoCの一部には、専用のインテリジェントネットワークプロセッサが含まれています。例として、Texas Instruments製のAM572x Sitara組み込みマイクロプロセッサが挙げられます。評価ボードが利用可能で、製品のネットワーク機能を簡単に調べることができます。

AM572xは、ARM® Cortex®-A15プロセッサに基づいています。このマルチコアデバイスは、ホストプロセッサをCortex-M4で強化し、I/Oの多いタスクをオフロードするために使用できます。また、ネットワーク処理プロセッサのペアと、C66xアーキテクチャを基礎にしたデータ解析用のデジタル信号プロセッサも含まれています。AM572xのPRU-ICSSサブシステムは、ARMコアで利用可能なものに加え、それとは別の処理を行います。このユニットには2つのPRUが含まれており、それぞれに最高200MHzで実行される32ビットのRISCプロセッサと、ネットワークインターフェースが内蔵されています。2つの独立したインテリジェントコアが利用できるため、PRPおよびHSRをすぐにサポートできます。

PRUコア内のRISCプロセッサは、汎用アーキテクチャではありません。代わりにこのコアは、ネットワークフレームに出現する、パックされたメモリマップのデータ構造を処理するよう特別に設計されています。このコアには、厳しいリアルタイムの制約を持つアプリケーションをサポートするため、多くの機能が組み込まれています。PRUプロセッサでは、ある程度のパケットのフィルタ処理を実行できます。AM572xでは、Cortex-M4により、IEEE 1588、GOOSE、SVなどのプロトコルに利用できる余裕が、より多く存在します。

Cortex-M4を使用して、すべての受信マルチキャストパケットを分析し、それらのアプリケーションID（APPID）アドレスを比較して、Cortex-A15上で実行されているソフトウェアにより提供される有効なサブスクリプションを確認できます。これによって、M4はどのメッセージを上流へ渡す必要があるかを判定できます。他のパケットはドロップでき、メモリから消去されます。

図4：共有メモリIPCにより、IEC 61580の処理をCortex-M4や他のプロセッサにオフロードできます

このオフロードされた処理アーキテクチャでの主要な考慮事項は、それぞれのプロセッサが互いにどのように通信を行うかです。AM572xには、プロセッサから他のプロセッサへのメッセージ受け渡しを容易にするための共有メモリがあります。パケットを簡単にキューとして形成できるため、順番に書き込みと読み出しを行えます。主要な問題は、使用するプロトコルです。オプションの1つは、Cortex-A15上でLinuxを使用することです。これによって、オペレーティングシステムによりプロセス間通信用に提供されている、remoteprocやrpmsgなど標準のAPI（Application Programming Interfaces）を使用できます。

rpmsgメッセージ処理システムは、リモートプロセスにリンクされている、各通信チャンネルを反映する仮想デバイスを提供することによって動作します。チャンネルはテキストの名前により識別され、ローカルrpmsgアドレスとリモートrpmsgアドレスが存在します。ドライバがチャンネルのリスンを開始するとき、受信に使用されるコールバック関数が、固有の32ビットrpmsgローカルアドレスにバインドされます。受信メッセージが着信すると、rpmsgコアはそのメッセージを、宛先アドレスに応じて適切なドライバへディスパッチします。メッセージは、ドライバの受信ハンドラを呼び出すことでリレーされ、受信メッセージのペイロードが提供されます。この方法により、GOOSEおよびSVメッセージのフィルタ処理コードは、特定のAPPIDアドレスを持つメッセージを、Cortex-A15で実行されている別のハンドラへ渡すことができます。あるいは、これらをすべてグループ化し、共通メッセージプロセッサへリレーして、ホストプロセッサで分類することもできます。

TIのGitリポジトリで利用可能なオープンソースのIPC3.xライブラリには、Linux環境と、Cortex-M4およびDSPコアで利用可能なTI RTOSとの間でrpmsgの使用をサポートするためのソフトウェアが実装されています。IPC製品は、各種のTIデバイス間で同じAPIを提供し、ハードウェアスピンロック、プロセッサ間のメールボックス、MessageQ APIによるrpmsg互換のメッセージ受け渡しについて、デバイス固有のサポートを抽象化します。

結論

メッセージ受け渡しサポートとマルチプロセッシングにより、AM572xなどのデバイスは、電力グリッドインフラストラクチャ管理のミッションクリティカルなジョブ用に開発されたものなど、複雑なリアルタイム制御プロトコルを効率的にサポートできます。