機能安全のバカ

機能安全は安全について間違った認識を植え付ける元凶となっている。これは事実だ。だから、表題で機能安全のバカと書いた。

先日、あるソフトウェアミドルウェアメーカーがソフトウェアを売り込みに来た。営業技術という肩書きだったと思う。

「この商品はISO26262の機能安全の認証を取っているんですよ。」という。そして、IEC62304の認証も取る予定ですと来たから、「IEC 62304 の対象は医療機器ソフトウェアだから、部品で認証を取ることはできない。」と指摘した。

寝耳に水だったようで、キョトンとされてしまった。IEC 62304 医療機器ソフトウェア－ソフトウェアライフサイクルプロセスは、ISO 13485 と ISO 14971 を引用規格としている。引用規格というの参照しているという意味ではなくて、IEC 62304 に適合するということは、引用規格にも適合していることを求めるということだ。

ISO 13485 は ISO 90001 の医療機器バージョンだから、まあよいとして、ISO 14971 は医療機器のリスクマネジメントの規格であり、医療機器の世界で誰もが知っている規格だ。

ISO 14971 のリスクマネジメントでは、当該医療機器に関して意図する使用を定め、そこから想定される危害や危険状態を分析し、リスクを評価して、対策する。

要するに何をするものかを最初に定義せずして、リスク分析はできない。それなのに機能安全バカは、何に使うものかを想定せずに IEC 62304 に適合できると言う。

ようするに、ペースメーカに使うも体温計に使うのも同じように安全を実現できると言っているのと同じだ。じゃあ、車の場合は、どんな部分に使っても認証取っていれば安全で事故には結び付かないのかと思う。

これは、IEC 61508 や ISO 26262 が高いSIL, ASIL に対して、ツールやソフトウェアアイテムの認証を推奨したことの弊害だ。

その結果、信頼性と安全性を混同する輩を生み出し、「信頼性が高ければ安全なんです」とのたまう営業員を作り出した。

このしっぺ返しは、自動車業界で5年後、10年後に必ずやってくる。電気自動車や自動運転が実用化されるようになれば、信頼性と安全性が異なることから来る複雑で原因が分かりにくい事故が増えてきて、機能安全が誤解を生む弊害を作ってきたことが分かるに違いないと思っている。


これに関連する話題で　IPA が「つながる世界のセーフティ&セキュリティ設計入門」という冊子を出した。ダイジェスト版が公開されている。

ここにも機能安全に偏った記述がある。

p20  (3) セーフティ機能とセキュリティ機能の高信頼化の重要性

前述のリスク低減プロセスにおいて、STEP1の本質的安全設計やリスク回避後、STEP2 でセーフティ機能とセキュリティ機能によりリスク対応する場合、その機能自体が故障したり、誤動作したりするようではリスクを低減できません。そのため、セーフティ機能とセキュリティ機能に対しては、より品質の高い設計が必要となります。

セーフティをセキュリティを分けていることはよいとして、セーフティやセキュリティの対策を機能と捉え、それらは高品質設計で実現できるように書いてある。それが機能安全かぶれの思考だ。

セーフティは目標や状態のことであって機能ではない。この冊子はIEC/ISO Guide 51 を参照しているにもかかわらず、セーフティの定義が正しく理解されていない。

セーフティ（安全）とは，〔ISO/IEC GUIDE 51:1999〕※1　によれば，『受容できないリスクがないこと』と定義される。すなわち，セーフティ（安全）は受け入れ不可能なリスクから解放されていることであり「受容できないリスクがない」または「許容可能リスク」が達成されていることをもって「安全」と規定される。

安全はリスクを経由して定義され，リスクはその時代，社会の情勢，環境によっても変化するため安全の尺度を一定にすることはできず，絶対的な安全を定義することはできない。そのため，製品，プロセスまたはサービスは相対的に安全であるとしか言えない。

安全は，リスクを許容可能なレベルまで低減させることで達成される。許容可能なリスクは，使用者の利便性，目的適合性，費用対効果，並びに関連社会の慣習のように諸要因とのバランスで決定される。したがって，許容可能なリスクは常に見直す必要がある。技術及び知識の両面の開発が進み，製品，プロセスまたはサービスの使用と両立して，最小リスクを達成できるような改善が経済的に実現可能になったときは，特に見直しが必要である。

これを説明するのにいつも上記のスライドを使っている。

機能安全に毒されている人間は安全を機能で実現できるという方向に持って行こうとしていて、得意のソフトウェアの品質向上プロセスのアプローチに引き込もうとする。

p12 のペースメーカの誤動作の例では、、「健康や生命に関わるために故障時にも止まることが許されないものも存在します。その場合は通常のセーフティよりも強化された二重、三重の対策が求められることもあります。」などと書かれているが、通常のセーフティよりも強化された・・・というところが、セーフティとリスクの関係について理解できていない。

「健康や生命に関わるために故障時にも止まることが許されないものも存在します。」これは正しい。しかし、その後の「その場合は通常のセーフティよりも強化された・・・」がいけない。

医療機器のリスク分析では最初に意図する使用（Intended Use）を定義し、それを元に Hazard（危害の潜在的な源） や Hazardous Situation（危険状態） や Harm（危害） を想定する。

この際にペースメーカが止まるという危険状態の危害として、患者の死が想定され、設計上の対策として問題発生時には定時ペーシングを確保するような対策が取られる。

「健康や生命に関わるために故障時にも止まることが許されないものも存在する。」というフレーズは、リスクに対する対策は想定されたリスクによって変わるので、リスク対策を決め打ちしてはいけないことを注意するために使うフレーズなのに、その意味を十分に理解せずに、「対策は足らなければ強化すればよい」と言ってしまっている。

リスクは危害の重大度や危険状態が発生したり、危険状態が危害に至る頻度（確率）で評価するのであって、リスク対策を先に考えてはいけない。なぜなら、リスクが許容できるかどうかは「使用者の利便性」「目的適合性」「費用対効果」などの諸要因のバランスで変わってしまうからだ。最初に機能を持ってくると、進化した技術の適用やアーキテクチャを見直す対策などが飛んでしまう危険性がある。

「通常のセーフティ」とか「二重、三重の対策」といった言葉が出てくるのは、安全は機能で実現できるという思い込みがあり、リスク分析の概念が十分に理解されていないからだと思われる。

原発も同じ。安全対策に焦点を当てるのではなく、危害の重大度と危険状態や危害に至る発生確率を考えないといけない。安全対策を強化すれば、安全が実現できると主張することで、結果的に危害の大きさから、人びとの目をそむけてしまう。

まず考えなければいけないのは、危害の大きさと、危害状態に至る確率や危険状態が危害に至る確率だ。

原発の場合、危害が破滅的であることが分かっている。危険状態に至る、危険状態から危害に至る確率はゼロでないことが実際に事故が起こったことで分かった。まずは、初心に返って危害がいかに大きいかということと、危害の発生確率、頻度が変わったことをどう考えるのかを評価しなければいけない。

安全対策に焦点が当たってしまうと、事故が起こったら安全対策を強化すればよいと考えてしまい、危害の潜在的源を取り除くという思考を遠ざけてしまう。

安全対策にばかり視点がいくと、危害の大きさの認識が薄れてしまうことがお分かりだろうか。

だから、機能安全はたちが悪いのだ。

リスクコントロール手段はそれを追加したことによって発生するリスクを考慮をリスクマネジメントの中で求められる。（ISO 14971より）　

実際にそういうことがあるからだ。よかれと思ってリスクコントロール手段を追加したら、別な問題が起こってしまうということがある。

リスコントロール手段を冗長設計だけしかないと思っているとこういう思考になる。冗長設計はシステムの複雑性を生み、テストケースを増やし、システマティック故障を起こしやすくなるため、場合によっては冗長設計はやめてシンプルな構造にして信頼性を高める設計を採る場合もある。

総じて、ソフトウェアの品質向上プロセスで推そうと考える人達は、リスク分析やリスクベースドアプローチの概念が抜け落ちている。

p6 セーフティとセキュリティの設計の見える化の必要性

本書でいう「セーフティとセキュリティ設計の見える化」とは、複雑になりがちな安全対策やセキュリティ対応などを、第三者にエビデンスを使って論理的に説明できるようにすることを指します。見える化の目的としては、設計開発支援、第三者認証や国際規格の取得などが挙げられます。

結局、この人達は、利用者の安全が真の目的ではなく、設計開発支援や段三者認証をやりたいからこういう読み物を作ったんでしょということだ。

安全やリスクマネジメントとソフトウェアを絡めて研究する学問が成熟していないから、こういうものが出てくるんだなと思う。

アカデミアの皆さんにはそういう研究分野を立ち上げて欲しいと切に願う。

P.S.

本文と全く関係ない話・・・

10年前に書いて日経BP社から出した本「組込みソフトウェアエンジニアを極める」は絶版になり、「リアルタイムOSから出発して組込みソフトエンジニアを極める」として再版した。

Amazon の読者感想で下記のような記述があり、著者としてそういう風に考えてもらえたのがとてもうれしかった。

開発年数の浅い私(2年目)ですが、少しずつ出来ることから実戦していこうと思いました。
また、上手くいかなかったときや落ち込んだとき、この本を読み返して、モチベーションを高めています。

そう思ったら、最初の本を書いたときに、この本を紹介するサイトを作って日経BPのサイトにおいてもらったものがまだ残っていることを思い出した。

たまたま、読み返したら良く出来ていたので、みなさんにも紹介したい。

この紹介サイトは登場人物が本の物語の中で、それぞれ視点で何を考えていたのかをザッピングできるような仕掛けや、本を出版するまでの著者の日記などが書かれていて、今考えるとよくこんなサイト作ったなと我ながら関心した。（本の紹介サイドは全部自作で制作費はかかっていない）