機能安全編

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

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

（その他の自己診断（DiagnosticやSelf Test））
自己診断とは何か？をお話ししましたが、その他の自己診断をご紹介します。

劣化や外的ノイズで故障または誤動作するような場合は、前述のメモリや電圧検知素子の例のようなSafety Measureが考えられます。前回のメルマガのCommon Causeの説明に登場した、マイコンのクロック（水晶発信器）についての例も、これと類似のSafety Measureといえるでしょう。結果的に２つのクロックの周期を、常にマイコン内部で比較することと同じことですから、自己診断の仲間ともいえます。

このような故障は、ランダム故障と呼称しています。（詳しくは第二回のメルマガを参照下さい。）ランダム故障と対になる概念として、システマティック故障があります。システマティック故障は、アルゴリズムの間違いから、マニュアルの記載間違いまで、非常に広い範囲の概念なのでSafety Measureイッパツで全てを解決することは出来ません。形式手法の採用など、最初に決めたSafety Life Cycleの定義にのっとった丁寧な設計と、設計からライブラリ個々のテスト、コンポーネントテストなど、様々なテストの積み重ねが必要です。

とはいえ、システマティック故障に有効な手立てもあります。IEC-61508で紹介されている手法として、LPFS（Logical Program Flow Supervision）というものです。なんかすごそうな手法ですが、早い話、子供が夏休みに行う、駅のスタンプラリーみたいなものです。

必ずやらねばならない処理や、処理のルートに厳格な規定がある場合、その個々の処理を通るたびに「スタンプ」なり目印を値として保存し、最後に規定の値になったかどうか判定します。この手法は、メモリなどのランダム故障にも勿論有効です。

「この処理をしたら、実は、ある大切な処理を飛ばしてしまうバグがあった」という場合、LPFSをプログラムのあらゆるところに仕掛けておけば、自己診断として検知することが出来るわけです。信頼されないお父さんが、朝奥さんから「本当に今夜男性の同僚と食事に行くなら、写真にとってメールしなさい」といわれるようなものですね。ちょっとちがうか。

そのほかにも様々なSafety Measureを考えることが出来ます。電子回路や電子素子が複雑化し、かつ大規模化したとしても、Safety Measureを工夫することによってλDUを
λＤＤに変えてゆくことで、求めるレベルのPFDave／PFH、SFFを達成することができる様になります。

（自己診断（DiagnosticやSelf Test）のデメリット）
しかながら、自己診断（DiagnosticやSelf Test）は、搭載しているコンピュータに大きな負担を掛けます。うっかりすると本来の機能を実現する処理時間よりも、Self Testに掛かる時間のほうが多くなってしまいます。たとえば、メモリーのチェックをする、と一言でいっても、１バイトずつ１ギガバイトの空間を比較するなんて設計をしてしまっては、すごく高価で高速なプロセッサを搭載しても、処理時間の多くはメモリーチェックに使われている、なんてことになりかねません。

Safety Measureは決まった方法があるわけではありません。IEC-61508では、技法そのものを使うことはSILのレベルに応じて推奨はしていますが、それが安全達成のための担保であるとは決め付けていません。どのようなSafety Measureをどのように実装するのか、それはすべてSystem FMEAや、FTA、および次回以降でお話しするFMEDA（実際の回路の部品一つ一つを分析する作業。詳細設計の後に行います。）において、故障に対して適切処置がなされるかに掛かっています。
そこに設計上の工夫をする余地があるのです。

高速なCPUの能力を、下手なSafety Measureで台無しにしてしまうか、もしくは効率よく自己診断することで、CPUの能力を他のアプリケーションの演算にまわせるのか、技術者の腕の見せ所になります。

もうお判りのように、冒頭の起動戦士ガンダムSEEDでの、コーディネイタ（超人）の連中が、地球連合のモビルスーツに搭乗直後に行ったＯＳの変更は、Safety Measure特に自己診断（DiagnosticやSelf Test）に関することではなかったか、と思うのです。

なにせガンダムです。ロボット制御ですから、様々な部分で与えられるSafety Timeは非常に短いはずです。ミリ秒未満のSafety Timeでしょう。その短時間に全ての自己診断をしなければなりません。

ガンダムほどの制御システムですから、プログラムのメモリーエリアも膨大な大きさでしょう。その全てのビット化けをマイクロ秒単位で常に監視するのです。様々なセンサーの自己診断も、とほほなぐらい沢山あるはずです。下手な検知アルゴリズムでは、強烈なCPU負荷がかかるのではないでしょうか。

地球連合軍にとっては初のモビルスーツ開発です。おそらく残念なことに、彼らの自己診断プログラムにはベタな処理が多く、無駄にCPUの能力を消費していたのでしょう。

敵のコーディネイタは、奪ったガンダムを起動する前に、それらを違う手法に置き換えたり、または過剰なSafety Measureをはずすなどして、CPUの処理能力をアプリケーションの処理にまわせるようにしたのではないでしょうか。これは機能安全的には、アリです。

さらに、コーディネイタは、なにせ超人的な反射神経や洞察力を持っています。モビルスーツは、人が操りますから、「人間が検知してアクションする」という部分も多いはずです。この場合、前述のように、人の反応時間や筋肉を動かして操作する時間が、Safety Timeのなかでのシステムに与えられる時間的余裕を左右します。

コーディネイタほどの能力があれば、数百ミリ秒、システムに求められる処理時間に対して通常の人間よりも余裕を与えられるかもしれません。その分だけCPUの処理能力に余裕を与えることでしょう。

戦いながら対処した主人公キラ・ヤマトは、敵の様に中身をそっくり変更したのではなく、人間処理系に関する規定の制約時間などのパラメータを変更することで、モビルスーツの動作に関する処理にCPUの演算資源をまわしたのでしょう。これならば稼働中にでも出来るかもしれません。これも機能安全的には、完全にアリです。

このように、きちんと敵と戦うためには、十分な構想設計が大切なのです。作ってみてからすり合わせるのでは手遅れなのです。地球連合軍の開発部門に、是非このメルマガを読んでいただき、構想設計の大切さをご理解いただければと願う次第です。