機能安全規格IEC61508と自動車の電子制御系に関する安全規格ISO26262の概念について詳しく解説されている。
自分自身、機能安全ということばがどうしてもすっきり理解できずもやもやしていたが、この記事を読んですっきりした。
だいたい、「機能」と「安全」の結びつきが直感的にイメージできない。Safety は functional ではない、安全は機能的に実現するのではなく、あらゆる使用環境、ハザードを想定してシステム全体で確保するものだと思っていたから、どうしても機能安全(functional safety)ということばがしっくりきていなかった。その疑問点をこの特集記事はクリアにしてくれている。
この記事がいいところは規格の内容を解説するだけでなく、規格の策定メンバーにインタビューして規格が作られた時代背景や思惑にまで突っ込んで書かれてところだ。
【日経エレクトロニクス 2011.1.10 p44 機能安全、素朴な疑問より引用】
機能安全(functional safety)の「機能」とは、制御対象（プラント、EUC: equipment under control)や制御器（コントローラ）を監視する安全装置の役割のことを意味します。通常、安全装置（安全関連系(SRS: safety-related system)にはコンピュータが使われ、いざ制御器に故障などが発生した場合は、このコンピュータが制御対象を停止したり、ユーザーに警告を出したりします。安全装置があることによって実現されているこうした安全性のことを、特に「機能安全」と呼んでいます。機能安全とは、いわばマイコンなどを使った安全装置による安全対策といえます。なお、安全性そのものは、こうした電子的な安全装置の付加によって担保するだけでなく、危機源（ハザード）そのものの設計上の除去（本質安全）や、危機構造的なフィルセーフ機構（構造安全）などによっても担保するのが一般的です。機能安全によって実現できる安全性は、包括的な安全性の、あくまでも一部でしかないといえます。IEC自身も機能安全について、「Functional safety is the part of the overall safety」と明記しています。【引用終わり】
この特集記事には IEC61508策定時の裏話が書かれている。 IEC61508 はバックグラウンドとなる理論的体系や支柱がほとんどないまま、1990年代初頭に「ともかくPLCなどの電子的な安全装置に関する規格を作らねば」という欧州企業の意向によって策定が始まったというのだ。そして、根拠は後付けでいいからというスタンスが強かったという。何からの裏付けや蓄積を経た上で策定される通常の規格とは真逆の順序で作られたらしい。
機能安全規格のIEC61508と特に強く批判してきたのが、米国を中心とする安全の専門家やソフトウェア工学の専門家だという。ソフトウェアの安全設計の権威であるMITのナンシー・レブソン教授がIEC61508に批判的だというのは知っていたが、米国の多くの専門家が批判的だというのは知らなかった。
IEC61508に対する批判は主に次の4点に集約されている。
- 安全性の規格でありながら、定量的な故障検出率といった確率論に重きを置きすぎている。
- 故障率低減のための複雑な機構の導入が、かえってシステム全体の安全性を損なう危険性に配慮していない。
- 部品ごとに安全性の認証を与え、認証を得た部品の採用によって安全を担保しようとしている。
- バックグラウンドとなる理論的体系や支柱がなく、規格が膨大で分かりにくい。
あー、それだ。そう、何年も前から自分はこの規格を読んでいてそう思っていたのだ。特に3つめの部品単位での安全性の認証のところ。日経エレの進藤記者、分かりやすく明確に書いてくれてありがとう。この記事読んでいて「がってん」ボタンを何回も押してしまったよ。
さて、IEC61508はそもそも、化学プラント、原子力産業、工作機械などの産業用機器を対象に作られた。だからそこ、ハザード事象が発現したときに、安全装置があることによって実現されているこうした安全性のことを「機能安全」と言ったのだ。
機能安全の説明でよく踏切の例が挙げられる。踏切ではなく高架橋を作ることによって通行者の安全を確保するのが本質安全で、踏切という安全装置によって安全を確保するのが機能安全。
ちなみに、自分がこの機能安全ということばに違和感を覚え続けていたのは、日頃から安全の確保はハザード分析やリスク分析から始まるということが当たり前だと思っていたからだ。
システムを取り巻く環境にあるハザードやリスクを分析して、それらのリスクを受容できるまで低減するのことが重要と教わってきた。リスクを軽減するための手段は、設計上の対策かもしれないし、表記上の対策かもしれないが、手段が先になることはない。
機能安全の規格は安全装置によって安全を確保する狭義の Safety という意味合いが強いということがこの記事を読んでよく分かった。本質安全に対する安全装置による安全（=機能安全）と考えると非常にすっきりする。
そして、安全は安全装置の設置という狭い考えではなく、システム全体を踏まえた包括的な安全性の実現を考える必要がある。
折しも、昨日今日とWOCS 2011（クリティカルソフトウェアワークショップ）が開催され、MITのナンシー・レブソン教授が基調講演に登壇された。その後、トヨタ自動車の川名氏、電通大の西氏、JAXAの片平氏も含めて、口々に「認証されたツールや部品を組み合わせることで安全を確保できると思ってはいけない」と語っていた。
なお、日経エレの特集記事を読んでいただければ分かるように ISO26262 は IEC61508の問題点をアンチテーゼとして、クルマドメインに合うようにかなりカスタマイズしている。
ISO26262がDIS（Draft International Standard）と呼ばれるドラフト段階のときに、「リスクの高いコンポーネントは形式手法を強く推奨する」という記述があった。これを見た、ツールベンダーや規格認証機関は「形式手法は絶対に使わないといけない」というニュアンスをクルマドメインの人たちに伝え恐怖をあおった。
ところが、FDIS（Final Draft International Standard）では、選択肢を複数に増やしてかつ、代替えの方法でも可という表現に変わっている。わざわざそうしたのは、ソフトウェア部品の信頼性を高めることがシステム全体の安全につながるかのような誤解が開発の現場に蔓延するのをなんとか防ごうとしたからである。
このように ISO26262 は IEC61508で指摘された問題点の多くを積極的に改善してきている。規格の策定委員の一人であるトヨタ自動車の川名氏は「選択肢が増え曖昧さが加味されたことによって骨抜きになったと思う人もいるかもしれない」とWOCS2011で語っていたが、そんなことはない。技術者が「安全を確保するのはどうしたらいいのか」「自分達がやってきた方法は安全にどれくらい寄与しているのか」と正面から考えるきっかけを作ったくれたのだ。
そうではなくて、形式手法を使えばよいとか、規格認証を取れたツールを使ったり、プロセス認証を取ったサプライヤーにソフトウェアを開発委託すれば、安全なシステムを作れるなどと考える者を減らすのを助けてくれたのだと考えて欲しい。
自分は、システムの安全を考えるときには、必ずどんなリスクを回避しようとしているのかを常に思い浮かべて欲しいと思う。例えばクルマなら次のようなことだ。
- 衝突したのにエアバッグが開かない
- 衝突回避のための超音波センサに泥が付いた。
- パワーウインドウに子供の手や首が挟まった。
- エンジンがオーバーヒートしたらどんなときにも止めていいか。
- バッテリ切れのときにブレーキは働くか。
上記のようなリスクを回避するのに、形式手法やメモリ保護、カバレッジ100%のテストはプラスの効果を与えると思うが、安全を確保できているという確固たる根拠にはならない。安全を確保するには想定したリスクをどのようにして安全設計によって回避できるのかを説明しなければいけない。
ソフトウェアは電子部品のようにランダムな故障はしない。Systematic Failure （決定論的故障） といった問題の起こし方をする。想定しきれなかった、テストしきれなかったバグによって問題は起こる。そのようなバグを完全にゼロにすることはソフトウェアの場合困難であると認識しつつ、ハザードが発現しないためにはどうしたらよいのかを考え、できるだけ完全に近づけようと努力する。
日本のソフトウェア技術者は世界でも最高レベルの品質を持つ製品を世に送り出してきたのだから、なぜ、それができたのかをよく考えて、その強み・ノウハウを殺すことなく、グローバルな世界に対して説明責任も果たせるようにならないといけない。
規格の翻弄されるのではなく、自分達が安全を実現するためにやっていることを規格を使ってどうどうと説明するにはどうしたらよいかを考えればよい。
0 件のコメント:
コメントを投稿