リスクは装置全体で受容可能なレベルまで下げる

■　リチウムイオン電池の発火を防ぐ新技術、台湾で発明　■

発火や破裂を防ぐ新素材を採用したリチウムイオン電池が、早ければ2010年第1四半期に登場する。（ロイター）

という記事が itmedia のニュースに出ていた。そもそも、リチウムイオン電池は内部でプラス極とマイナス極がショートすると、電池内部の温度が一気に上がり発火したり破裂したりして危ない。よく、ニュースでパソコンから煙が出ているような画像が出ていたりする。リチウムイオン電池のメーカーは両極がショートしないようにくふうするのだか、製造の不良などでまれに事故が起こる。煙がでるのは非常にインパクトがあるので大騒ぎになるし、実際にかなりのエネルギーを内包しているので危ない。

そんな折、この新技術（素材） Stobaは電池のプラス極とマイナス極の間に置かれ、電池の温度がセ氏130度まで達すると 多孔質物質が保護膜に変わり、反応を遮断するという。

【リスクを下げるということ】

ここで考えて欲しいのは、リスクを下げる対策は電気、機械、ソフトどれでもいいということだ。機器を使うユーザーからすればリスクをゼロにしろとは言わないから、どんな方法でもいいのでリスクを許容以下に下げて欲しい。それが電気的対策でも、メカ的対策でも、ソフト的対策でもよい。

ところが、メカ、エレキ、ソフトのそれぞれのエンジニアがそれぞれのチームと密に連携できていないときに事故は起こる。それぞれのチームが他のチームで安全対策をしていると思い込んでしまっているときなどが危ない。

このリチウムイオン電池の発火を防ぐ新技術が仮に世の中に浸透したときのことを考える。仮にある機器のソフトウェアが何かしらの電池ショート時のリスクコントロール手段を実装していたとしよう。次の製品では、この Stoba 技術が採用されるので、ソフトの対策は外してもいいやと考えたとする。しかし、電池は取り外し可能で古い電池とコンパチだったら古いものも使える。

そうなると組み合わせによっては、ソフトウェアで実装したリスクコントロール手段が効かないということになる。事故が起こって初めて「あっ」ということになる。

システムが大きく、複雑になるとこのような複合的な原因によるリスクが増える。これまで、装置全体を把握できるエンジニアがそのリスクを抑えてきた場合、一人で全体を見渡せない状況になってきたら、システマティックにリスクを低減する方法を採用していかなければいけない。

あっちのチームがやってくれていると思うから大丈夫という感覚が、ユーザーを危険にさらすことになるのである。

ソフトウェアが凶器となる日

しばらく前のクローズアップ現代で車が電気自動車になると小さい会社でも簡単に車を作れるようになると言っていた。（10月28日放送 “自動車”激変　現場で何が。スタジオゲスト ：宮内　洋宜：日本総合研究所創発戦略センター研究員）

「簡単に」というのはどうかと思うが、少なくとも新規参入がまったく不可能、設計、製造の実績がなければ相当ハードルが高いという状況ではなくなるようである。

素人考えで想像するに、複雑なエンジン制御がいらなくなり、バッテリとモーター、制動機能とボディと、ソフトウェアがあれば取りあえず動くものが作れるような気がする。ようするに、個々の部品を部品メーカーから調達してつなげ、それらをコントロールするソフトウェアを作れば、車が作れる時代がくるのだ。

クリティカルソフトウェアの開発に携わっている自分としては、この予想される未来に大いなる危険を感じている。なぜなら、そのドメインに長く関わっていない組織が作る、もしくは機器がどんな使われ方をするのかよく知らない外部協力会社に発注したソフトウェアが凶器になる可能性があるからだ。

我々は日々ソフトウェアが制御する機器に囲まれて暮らしている。それらのソフトウェアがまともだからこそ安心して生活することができる。映画ではロボットが突然人間に反旗を翻すシーンがよくあるが、現実には潜在的に埋め込まれていたバグが複雑な条件がそろったことで発現して利用者を危険にさらすことはある。プログラマが悪意を持って不具合を埋め込んだのではなく、未熟な技術者が作ったソフトウェアが意図せずに暴走したか、もしくは熟達した技術者達のが作成したサブシステムを結合したときにシステム全体としては思いも寄らなかった問題が発生するのだ。

大きなエネルギーを扱う機器を作っている組織やエンジニアは、その機器が危ないことを知っており、仮にそこにバグが残留していたとしても、ユーザーリスクが許容できるレベルに抑えるようなソフトウェアのつくりかたをする。例えば、モーターの駆動制御が暴走してコントロールが効かなくなったときに、制動の命令が指示されたら、駆動系の制御を切り離して制動が最優先に動くようなシステムを作る。

モーターチームと制動チームがそれぞれ完璧な仕事をしても、それらを結合したときにどんなユーザーリスクがあるのかを考える分析者がいて、リスクをコントロールする手段を実装しないと、その車は危ない。

安全を確保するには、危険とその危険をコントロール手段の実装を組織が分析してシステマティックにやる方法と、一人一人のエンジニアがエンドユーザーの使用状況を思い浮かべながら品質を作り込む方法と両方がある。

電気自動車の製造に新規参入する人たちはそのどちらのノウハウも持っていない可能性がある。これは間違いなく危ない。ソフトウェアが凶器になる可能性がある。

しかも、事故が起こってもソフトウェアが原因だった場合、どこに問題があったのかを調査するのが難しいし再発防止策を立てるのが簡単ではない。

このような状況にならないようにするための教科書として最初に読むべきは、『セーフウェア 安全・安心なシステムとソフトウェアを目指して』である。この本には、過去にソフトウェアが原因で起こった事故がなぜ起こったのか、どうすれば再発防止できるのかについて書かれている。

この本については『組込みソフトウェアの安全設計』の記事を参照して欲しい。つい最近、原書である Safeware の邦訳本が翔泳社から出版された。本の内容についてはまた後日このブログで掘り下げていきたいと思う。

自分のソフトウェアが搭載されている機器の制御がおかしくなると利用者に危険がある場合、あなたが作ったソフトウェアはいずれ凶器になる日がくる。だから、そうならないための技術を身につける責務があなたにはあるのだ。