機能安全編

株式会社制御システム研究所　森本　賢一

2011.09.29
※記事執筆時は、三菱重工業株式会社　原動機事業本部に在籍

（Safety Protocol）
さて、前述のような「通信」というものに対する打ち手（=Safety Measure）をすべて自分達で開発し実装することは、骨が折れる作業です。時間も労力も、さらにお金も掛かる作業であることは間違いありません。

そこで機能安全のシステムを開発する場合、通信については既存のSafety Protocolを採用することで労力を削減することも選択肢として挙げられます。産業用の通信プロトコル、いわゆるField Busとして市販されているものは、Safetyに拡張されたオプションを持っており、IEC 61784-3にその考え方や、残存エラー率の計算結果などが掲載され、規格に準拠した例として挙げられていますので、それを使うのは手っ取り早いでしょう。

とはいえ、「機能安全規格準拠」と謳う機器や、通信スタックのライブラリなどはとても高価です。やっていることは、今回お話したとおり、プロトコルとしてタイムスタンプなどを『別に付加』したり、生成多項式を独自に多少触ったCRCを『別に付加したり』するぐらいで、技術的に猛烈に高度な「何か」をしているわけではありません。高いものを買うぐらいならば、労力はかかっても自前でつくる、というのも選択肢です。このような判断をするためにも、構想設計段階で、きちんと「通信」をモデル化し、評価検討する必要があるといえます。


（Black Channelと残存エラー率）
Black Channelの考え方を適用できれば、COTSとして市販の通信機器やデバイスが使用できるのは、とてもありがたい話だと思えます。しかし、そもそもの機能安全の骨である、PFD／PFHの議論にどうつながるのでしょうか？そう疑問に思われる方も多いかと思います。危険側不動作確率という確率を中心に据える機能安全の考え方において、考え方一つで不問になるのは、疑問が残ると思います。

Black Channelを主張するために自前で用意する「打ち手」には、タイムスタンプや宛先・送り先のような確定的なエラーへの対処と、ビット化けのような不確定なエラーに対する対処とがあります。前者については今回お話したとおりです。しかし後者の不確定なエラーに対する対処は、実際はもう少し複雑です。今回は『CRCなど』、と簡単に触れましたが、この部分が実は機能安全の指標、ＳＩＬと密接に関っています。


次回はこの不確定なエラーおよび残存エラー率について、機能安全で「通信」を使用する際に、どのような配慮が必要なのかについてお話します。

Archive

• 機能安全　～上流で設計すべきもうひとつの品質