機能安全編

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

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

（COTS）
機能安全に準拠したシステムの構想設計における通信のモデル化では、さらに検討するべき大切な観点があります。

ケーブルやHUBなどの媒体のみならず、通信ドライバIC、FPGAのIPコア、またはコントローラに搭載するドライバやハンドラのライブラリなど、「通信」に関係する部分の多くは、市場に出回っている製品群を利用することがほとんどです。勿論それすらも機能安全のプロセスと精神で作り直すことも不可能ではありませんが、前述の通り現実的な話ではありません。

構想設計段階で、何を新たに開発し、何を流用するのか、その区別をあらかじめ十分吟味して決めておかないと、詳細な開発の過程で、また試作後の評価の段階で、設計のやり直しなど大きな後戻りを引き起こします。構想設計段階での通信のモデル化に際しては、機能安全として新たに設計開発する部分がどこで、既存の技術や製品を使用する（流用する）部分がどこなのかを明確にすることも大切です。

このような構想設計上のモデル化は、軍事・航空宇宙のみならず、産業用途やインフラなど高い信頼性を求められる装置（主に電子機器）に市販品を用いることを指す、COTS（Commercial Off-The-Shelf）という考え方、ポリシーに関係してきます。

機能安全の要否とは別に、産業用途では、「特に高い信頼性が必要」な一方、「できるだけコストを安くしたい」システムというのは多くあります。また今の時代、最先端で高性能の技術こそコンシューマ向けの市場が牽引している側面があり、COTSの考え方はどのような分野でも不可欠になってきているといえます。

そこで先ほどの図を、機能安全システムとして今回開発する部分と、COTSの部分を意識して修正してみます。



ハードウェアのみならず、ソフトウェアについてもモデル化する必要がある、とお話しましたが、それは、それらの「作り直せない部分」をできるだけ多く包含させ、「通信」というものを、塊として丸ごと扱えるようにするためでもあるのです。どうせ「通信」という塊で考えてゆくのですから、COTS部分を出来るだけ包含した方が、このあとの考察もしやすくなります。

これで一応「通信」についてのモデル化が終わったことになります。実はまだこの図は完成していないのですが、それはもう少し後でご説明します。これまでのところで、「通信」というものを塊と捕らえること、それをハードウェア、ソフトウェアの区別なく、COTSの観点も含めてモデル化することができました。


（通信のFailure Mode）
さてここで構想設計の「青写真」としての通信のモデル化のお膳立てが出来ました。では次にこの「通信」なるものが、どのような障害を起こす可能性があるのか考えてみましょう。図でいえば、前述の絵の灰色網掛け部、COTSの部分です。

通信ですから、当然情報が「届かない」という状況が考えられます。また「メッセージが化けた」という状況もあるでしょう。通信手法によっては、送った順番と異なる順番で相手に届くこともあるかもしれません。間違った宛先に届くこともあるかも知れませんね。

通信を介在させたアプリケーションプログラムを開発した方ならば、エラー処理としていくつも思い浮かぶことと思います。

このような「通信」の障害のおこり方については、IEC-61784-Part3や、IEC-62280（EN50156）に整理されています。以下の表はそれらの抜粋です。




「通信」というものを塊としてとらえ、上記のような障害をFailure Modeとして扱い、FMEAやFTAを行います。これらのFailure Mode（故障の状況）が発生した場合に、どのような事象が発生するのか、システムにとって問題となる事態につながらないのかを考えます。その際にはもちろん、その「通信」経路を使用する上流・下流のシステムの挙動を考慮して洗い出してゆきます。

その上で、問題となる事象が判明したら、それに対して適切な打ち手が存在するのか、本連載のこれまでの回でお話してきたとおり、一つ一つどのような事態になるのか、それが危険な事態に至るならば、どのような打ち手（=Safety Measure）を付け加えるのか考えてゆくわけです。このプロセスが構想設計の大切な要素でした。

たとえば、「メッセージが適切な順番でとどかない」という障害に対しては、「メッセージに送信の順番をつけて送ることで、メッセージの順番の入れ替わりをチェックできる様にする」というのも一つの手立てです。

順番だけではなく、伝達する時間に制約がある場合は、送り出した時刻をデータに付加して送信（タイムスタンプ）することも必要かもしれません。それによって、古いデータを排除したり、許容範囲外の遅延を検知したり、通信経路の障害を検知することを狙うわけです。

また「届け先が間違ってしまった」場合を考えるならば、メッセージのデータエリアの内部に、さらに送信元と送信先を付加して通信することで、適切な送受信メッセージなのか判断できるようにすることも考えられます。もしくは認証機構を持たせ、メッセージ送受信の度に互いに認証をし合い、相手を確認してからメッセージを送る、という方法も考えられるかもしれません。

いずれにせよ、このような打ち手（=Safety Measure）を、COTS部分の外側、つまり今自分たちが構想設計しこれから作ろうとしている部分に搭載させればよいのです。そのような「通信」の弱点をすべてCOTS部分の外側で手立てできるならば、内部についての詳細な解析や、不足する機能のカスタマイズが出来なくても、COTS部分を高い信頼性の用途で利用できることになります。




ＶＰＮなど暗号化をして通信の秘匿をはかる技術も、この発想の延長にあります。制御システムでは秘匿だけではく、遅延や１パケットの欠落も重大な障害に至る可能性があります。「信頼性」という言葉だけではなく、通信というものをきちんと自分達の使用目的に照らして分析することが大切です。