Safety over EtherCAT (FSoE)
イントロダクション
オープンプロトコルのSafety over EtherCAT (略称: FSoE; FailSafe over EtherCAT) はEtherCATの機能安全に関する通信層を定義しています。Safety over EtherCATはIEC 61508 SIL3の要件に適合し、安全情報と標準情報を同じ通信システム上で通信速度やサイクルタイムの制限無く通信することを可能としています。
Safety over EtherCATプロトコルの開発において以下の機能を重視しました：
- 安全度水準が IEC 61508 SIL3を満足すること
- 同一の通信システム上における安全と非安全情報の両立
- プロトコルの伝送システムとメディアへの非依存
- 安全プロセスデータ長がプロトコルによって制限されないこと
- 非常に短いフレーム長が可能なこと
- 通信速度やサイクルタイムによる制限がないこと
- 簡素な仕様により、少ない実装工数、高性能、短い反応時間を実現できること
既に数多くの企業がSafety over EtherCATを装置や工場で使用しています。EtherCAT Technology Groupの発展はEtherCAT技術が広く普及していることを示し、これはSafety over EtherCAT技術についても同様です。
2005年の初頭からSafety over EtherCATはバスシステムとは独立したプロトコルとしてオープン化されました。国際標準規格 IEC 61784-3 "Functional safety fieldbuses" のプロトコルへ提案はオープン技術であることを明確にしています。さらに、ETG Safety作業部会は安全ドライブプロファイル (Safety-Drive-Profile) をそのドライブに内蔵された安全機能の使用方法と機能パラメータの共通化のために規定しています。ETGは他の組織にもこのプロファイルが普及するように努めています。
安全フィールドバスシステム
オートメーションコンポーネントと通信システムのインテリジェントな安全ソリューションによって装置設計に安全技術を組み込むことが可能となります。このような統合の重要な要素は安全通信と標準通信を同一のフィールドバス上で送信できることです。これに対するEtherCATのソリューションがSafety over EtherCATプロトコルです。
利点：
|
 |
技術要件
安全関連のメッセージを送信するためのバスシステムのテストや認証に対する基本原理は国際標準規格IEC61784-3に規定されています。
このようなネットワークでは以下のような障害の発生を仮定しなければなりません：メッセージの破損、多重送信、入れ替わり、喪失、遅延、挿入、なりすまし及び不正なアドレス指定。
これらの障害を制御するためにSafety over EtherCATプロトコルは以下の機能があります：
|
 |
Safety over EtherCATプロトコルはドイツの技術調査機関 (TÜV Süd) により評価され、Safety over EtherCATデバイス間でプロセスデータを送信するプロトコルとしてIEC 61508 SIL 3までの認証を受けました。デバイスへのSafety over EtherCATプロトコルの実装は安全ターゲットの要件に適合しなければなりません。また、関連する製品固有の要件も考慮する必要があります。
Safety over EtherCATプロトコルに対する残余誤差確率の計算は、通信システムの障害検出メカニズムによるものではありません。伝送メディアは「ブラックチャネル」と見なされます。これはこのプロトコルが他の通信システム経由でも送信可能であることを表します。フィールドバスシステム、イーサネットまたは同様の伝送システム、光ファイバーケーブル、銅線ケーブルまたは無線接続など、どのような通信経路も使用可能です。例えば、モジュラーI/Oシステムコンポーネントの内部サブバスシステムや、安全マスターと安全スレーブ間の標準PLC経由の安全メッセージのルーティングに対して使用できます。
実装
"Simple is Safety" － これはSafety over EtherCAT仕様の中心となる考え方です。このため、仕様は非常に簡素であり、単純なメカニズムは安全度水準の要件を確実にします。技術の実装は極めて簡単です。実装の詳細はFSoE実装ガイド (FSoE Implementation Guide) に示されています。
EtherCATではシングルチャネルの通信システムを安全情報と標準情報の送信に使用します。安全フレームはEtherCATプロセスデータ内に含まれます。この「コンテナ」はデバイス内の安全アプリケーションレベルで解釈されます。
| 通信はシングルチャネルのままです。適切な手順を経て、フレームは6バイトの最小コンテナ長で全ての障害検出情報が含まれるように設計されています。このコンテナには1バイトの安全プロセスデータが含まれています。一方、プロトコルは安全プロセスデータに関して一切の制限を加えていません。これは、大量の安全プロセスデータを持つ安全コンポーネントも安全デバイスアプリケーションに対して必要なだけSafeData/CRC_x部を追加するだけでサポートされルことを意味します。 |  |
Safety over EtherCATはマスター・スレーブ関係を2つのデバイス間のSafety over EtherCATコネクションで使用します。各デバイスはそれ自身の新しいメッセージに一度返信するだけで、新しく有効なメッセージが返信されることを保証します。このようにマスターとスレーブ間の完全な送信経路が各サイクルごとに監視され、遅延時間の累積は除去されるか検出されます。通信システムへアクセスに対して適度な要件を課すことで時刻同期の厳しいタイミングは不要になります。すなわち、非常に「簡素(lean)」なプロトコル実装を可能とします。一方、パブリッシャー・サブスクライブ技術では時刻同期が安全レベルで必要になります。
| Safety over EtherCATコネクションの開始時に、ステートマシンはマスターとスレーブの両方で処理を行います。ここで再び、可能な限り実装を単純化するための単純な構造が焦点になります。状態遷移はマスターによって開始され、スレーブで確認応答されます。「データ」状態は安全I/Oデータを交換するための通常の動作状態です。デバイスの内1つが通信障害を検出した場合、リセット状態に変更し、その結果、コネクションをリセットします。 |  |
アプリケーション事例
安全と安全通信プロトコルの機能は製品への実装を通してのみ実証できます。Safety over EtherCAT機能を持つデバイスは2005年から提供されています。EtherCATは最初に安全プロトコルをサポートしたリアルタイム工業用イーサネットの通信システムの1つです。多くのETGメンバーがこの技術を各社のデバイスアーキテクチャに組み込んでいます。今日では数多くのアプリケーションが使用され、ユーザーやベンダーに幅広く受け入れられています。
スケーラブルな安全I/Oコンポーネントをシステム内で使用できます。追加の安全や非安全の入力や出力を柔軟に必要なだけ拡張できます。
| 安全ロジックもネットワーク内に組み込むことが可能です。このとき、制御PLCは安全拡張のない標準デバイスのまま使用でき、安全ロジックはネットワークセグメント内の安全デバイス内で処理されます。これによってコストを削減し、システム内の安全ロジックのスケーリングが可能となります。Safety over EtherCATと対応する安全スレーブデバイス間のメッセージが標準PLCを経由してルーティングされるだけです。もちろん、従来の安全PLCアーキテクチャもSafety over EtherCATでサポートされます。 |  |
| ブラックチャネルアプローチで装置部分の連結も可能です。Safety over EtherCATフレームは、例えば、EtherCAT Automation Protocol (EAP)を介して、プロセスコントロールレベルの標準通信経路を経由してルーティングされます。 |  |
