「ASIL-Dを達成しています」の怪

最近，「ISO 26262 の ASIL D を達成しています」という汎用OSやソフトウェア部品の宣伝をネット上で見かける。

このような広告を見るたびに首をかしげたくなる。

左の図は，GHS（ヘルスソフトウェア推進協議会）のリスクマネジメントトレーニング講座で毎回使っているスライドだ。

Intended Use（意図する使用）が決まらないとリスク分析ができないという説明に使っている。

左の細長い木の棒は何に使うのでしょうか？という問いに対して，上がアイスキャンディーの棒で，下が医師が喉の奥を診るために使う舌圧子になるという説明だ。

ようするに，同じ形状，材料であっても，使用目的が変わるとアイスキャンディーの棒になったり，舌圧子（医療機器：電子機器でなくても Medical Device になる）になったりすることを説明している。

アイスキャンディの棒も舌圧子も滅菌はしているだろうが，医療機器とする場合は，法規制上のハードルも高くなる。舌圧子の場合，病気にかかっているかもしれない子供の口の中に入れるため，滅菌，包装，表面のなめらかさなどの要求が厳しくなる。裏返せば，「舌圧子が原因で菌に感染するリスク」「舌圧子が原因で口の中を傷付けるリスク」が想定され，そのリスクを受容するために求められる機能や性能を達成しないとリスクが残留してしまうということだ。

左の木の棒がソフトウェアだったらどうだろう。ソフトウェアは変更が容易なため，ソフトウェアを変更することによって Intended Use（意図する使用）が変わってしまうということはある。現在あるソフトウェアをユーザーの求めに応じて「使いやすくしたい」「より性能を高めたい」「より多くの機能を追加して付加価値を高めたい」と考え，実行することは良いことだが，それによってIntended Use（意図する使用）が変化し，予想していなかったリスクが潜在してしまうかもしれないことを考えているだろう。

例えば放射線治療器 Therac-25 は1980年台に死傷者6名を出すソフトウェア起因の事故を起こした。これらの事故の原因の１つに，コンソール画面上で各種の設定を行っている際に，途中で最初のモード選択が間違っていることに気付いたら，気付いた時点で修正をかけられるようにして欲しいという要望がユーザーからあった。その求めに応じて，ソフトウェアを変更したところ，コンソール上の設定値と，実際の機器の設定に不整合を発生させる不具合が生じて事故に至った。（IEC 62304 実践ガイドブック 2.1.2章で解説）

これは，ユーザインタフェースをソフトウェアで改善しようとしたところ，想定外の大きな新たなリスクを作り込んでしまった事例だ。

ソフトウェアシステムは規模が増大し，複雑化する一方だ。そのため，アーキテクチャ設計の重要性が再認識されているが，ソフトウェアの構造は見えにくいだけに，ぐちゃぐちゃなソフトウェアもたくさんある。

だからこそ，ソフトウェアの個々の部品の信頼性を積み上げて，システムの安全性を担保しようとすることには無理がある。ソフトウェアの個々の部品の信頼性を高める努力をしつつも，そこにも不具合があるかもしれないとい疑いを持って，システムが安全になるような設計をしなければならない。

だから，汎用のOTS/SOUPを取り上げて，それを使えばシステムが安全であるかのような主張はおかしいと思う。

なぜなら，その汎用部品が何に使われるのかによって，リスクは変わるからだ。リスクが変われば，リスクコントロール手段も変わる。システムにとって万能なリスクコントロールはない。

だから，汎用のOTS/SOUPができることは信頼性を高めることであって，安全性を高めることではない。

「想定した使用通りにちゃんと動きます」「こういった異常を想定した機能や性能を備えています」とは言えても，「このコンポーネントを使えば安全です」とは言えるはずがない。

信頼性が高いと自慢するOTSのテストのエビデンスを見せてもらったことも何度からある。確かに，大量のドキュメントを作っていることは分かる。しかし，テストシナリオが無限にあるようなOTS（例えばRTOS）では，テストの量だけならいくらでも増やせる。

問題は，テストケース，テストシナリオの質であったり，テスト設計者のテストに対するコンセプトが重要なのだ。OTSを使用する際に，ここは危ないとか，ここは注意しないといけないというケースをテストケースに組み入れているかどうかを見ないといけない。

だから，「OTSの設計プロセスが規格を満たしている」とか，「基準に適合している」と主張する会社の商品はかえって怪しいと思った方がよい。

それよりは，どんなテストをしているのか，どんなコンセプトでテストをしているのかといった，信頼性の根拠の中身を説明してくれる会社の製品を選んだ方がよいと思う。

自動車業界がこのことを身にしみて分かるようになるのは，おそらく2030年ごろではないかと予想している。その頃になると，電気自動車や水素自動車が普通になり自動運転だけでなく，さまざまな便利な機能が自動車に組み込まれるようになって，新規参入する企業も増え，汎用部品を組み合わせてアセンブリするだけの製造業者も増えるだろう。

そんな，機能がごちゃごちゃに組み合わさった状態では，「ASIL D の部品でござる」を主要な部分に使うだけではシステム全体の安全は確保できない。システムとしてどうやってリスクの高い部分と低い部分を分離するか（凝集度を高めて，結合度を下げるか）を考え，想定したリスクに対するリスクコントロール手段を実装するかが重要になるはずだ。

ようするに個々の部品の信頼性を高める個別最適の発想から，システム全体で安全を確保する全体最適の発想に考え方をシフトしていかないと，市場で発生するインシデントやアクシデントの追いつかなくなるのだ。

自動車業界は機械部品や電気部品の信頼性を高めることでシステムの安全性を担保する1960年台からある Zero-defect 的なやり方を2000年以降のソフトウェア開発にも無理矢理適用しようとしているように見える。「バグは１つでもあっては許さん！」「潔癖なソフトウェアを納品せよ！」といった感じ。

ソフトウェア技術者はもうとっくに限界に来ているやり方を無理強いされてさぞ苦労していると思う。その苦労もあと10年経つと限界だということが自動車メーカーも分かってきて，根本的に考え方を個別最適から全体最適の発想にシフトしないと安全は確保できないことが分かるようになると思う。