TCP/IPだけではなぜ駄目なのか？安全通信が必要な理由

機能安全の基礎となる国際標準IEC 61508は「機能安全でデータ通信を扱う場合には安全通信を使うこと」を求めています。さらにその安全通信に対しては「通信エラーを漏れなく検出する仕組みを備えていること」を要件の一つとして求めています。一方、安全通信ではイーサネットやTCP/IPなどを通信の基盤として利用することも多くありますが、イーサネットやTCP/IPにおいても通信エラーを検出する仕組みはある程度用意されています。それにも関わらず、なぜ安全通信という形で、改めてエラー検出の仕組みを持つ必要があるのでしょうか。

安全通信が検出すべき通信エラーとは

まずは安全通信が検出する通信エラーを見てみましょう。IEC 61508のパート2では、安全通信が検出しなければならない通信エラーとして以下が列挙されています。

• Repetitions（メッセージの重複）
• Deletion（メッセージの消失）
• Insertion（メッセージの挿入）
• Resequencing（メッセージの順序不正）
• Corruption（メッセージの破損）
• Delay（メッセージの遅延）
• Masquerade（メッセージの仮装・偽装）※安全通信以外のメッセージを安全通信のメッセージとして受信

（IEC61508-2, 7.4.11 Additional requirements for data communicationsより）
また、上記のほか、機能安全フィールドバスの国際標準IEC 61784-3では、Addressing（メッセージの誤配・誤受信）も追加されています。

安全通信で認証取得のハードルを下げる

イーサネットではFCSというデータ破損を検出する仕組みがありますし、TCP/IPにもチェックサムやシーケンス番号などの仕組みがあるので、データ破損やメッセージの順序不正・消失などを検出できます。これらを上手く利用すれば、安全通信を使わずに済む、あるいは少なくとも安全通信の処理を減らせそうにも思われます。しかし実際にはそのようなことは行われません。その理由はいくつか考えられますが、中でも重要なのは「安全認証取得が難しくなる」という点です。

機能安全対応製品は、第三者認証機関による評価を受け安全認証を得ることで、安全性を客観的に示すことができます。安全認証の評価においては、対象を「安全関連部」と「非安全関連部」に分けて考え、特に安全関連部に対して徹底的に評価を行います。このとき、安全の処理がイーサネットやTCP/IPのエラーチェックに依存していると、イーサネットやTCP/IPまで安全関連部の一部とみなされてしまいます。そうなると評価の対象が広くなってしまいますし、そもそもイーサネットやTCP/IPについては外部で開発されたものを使用することも多く、それらについて評価に必要な情報を用意するのは簡単ではありません。結果的に、安全認証取得のハードルが大きく上がってしまいます。

下図は、この話を安全通信CIP Safetyのプロトコル構成との比較で表現したものです。

左は必要なエラーチェックをすべてCIP Safetyのレイヤーとして実装した場合です。赤い部分に安全関連部が集まっているので、評価の対象は赤い部分が中心になります。一方右側はイーサネットやTCP/IPのエラーチェック機能に依存する場合です。下位のレイヤーにも安全の処理が散らばり、評価対象がかなり大きくなります。このような事態を避けるために、機能安全では、必要なエラーチェックをすべて包含する「安全通信」をデータ通信に使うことにより、安全認証のハードルを下げていると言えます。

まとめ

機能安全製品の開発においては、設計者は様々なリスクに対して自らの判断で対策を講じていく責任があります。リスク対策の中身は各メーカーがノウハウとして蓄積している面もあり、有用な情報を得ることは容易ではありません。しかし通信エラーは、「安全通信」という形で対策が具体的に提示されている分、対策しやすいリスクだと言えます。安全通信の実現には様々な製品が各メーカーから提供されていますので、それらをうまく活用し、効率よくデータ通信のリスク対策を済ませましょう。

作成：HMSインダストリアルネットワークス株式会社