Shoeisha Technology Media

CodeZine(コードジン)

記事種別から探す

【第4回】安全ソフトウェアの実現と維持に向けた取り組み

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2008/08/21 16:00

 この連載では、これまで3回に渡って「組込みソフトウェアに求められる安全対策」「エレベータの安全ソフトウェア設計」「安全アーキテクチャの可視化」について説明してきました。最終回のテーマは、「安全ソフトウェアの実現と維持に向けた取り組み」です。

目次

安全ソフトウェアを取り巻く環境

 組込みソフトウェアにはセンシングやアクチュエータの制御を行うものが多く存在し、連載第2回では一例としてエレベータの制御の安全ソフトウェアについて考えました。また、第3回では、組込みソフトの安全設計にも電源デバイスが他のデバイスとの独立している様子に習って、安全ソフトウェアの他のモジュールからの「アイソレーション」と、安全ソフトウェアの検証をしやすくするために「シンプルデザイン」を目指すことを解説しました。

 また、これまで大きなエネルギーを扱ってこなかった携帯型の組込み機器でも、現在では人を死に至らしめるようなリスクを内在するようになっていることを、連載第1回で紹介しています。

電源デバイスの制御にもソフトウェアが介在

 AC電源から電気エネルギーの供給を受ける組込み機器の電源も、これまでは組込みソフトウェアからはアイソレートされており、組込みソフトウェアの不具合が電源デバイスに影響を与え、電気エネルギーを人や他の接続機器に放出するようなことはありませんでした。しかし、最新の電源デバイスでは、DSP(Digital Signal Processor)を組み込んで消費電力を下げたり利用効率をアップする細やかな制御を行うものもでてきました。電源デバイスの制御にもソフトウェアが介在するようになりつつあるということです。

 今のところ電源制御ソフトウェアは他のアプリケーションソフトウェアとは分離されていますが、今後経済性を優先させるために装置の中に高性能なCPUを一個だけ搭載し、電源制御ソフトウェアを含めたすべてのソフトウェアが一つのCPUの管理下に置かれるようになる可能性もあります。

ソフトウェアによる放射線過剰放射

 1980年代に、Therac-25(セラック25)という放射線治療器においてソフトウェアによる大きな事故が起きました。この事故では装置の開発者達が「機器の安全はソフトウェアでも十分に実現できる」と考え、経済性を優先させるためにハードウェアによる安全装置を外し、そのためハードウェアによる安全装置のために抑えられていたソフトウェアの不具合が発現しました。

 このとき、なぜ過度なエネルギー照射が起こるのか原因を突き止めるのに長い時間がかかり、付け焼き刃の対策で装置の使用を止めなかったために、Therac-25(セラック25)による犠牲者は6名にまで拡大してしまいました。この事故を調査した現マサチューセッツ工科大学のNancy Leveson教授は、事故調査を終えて次のような教訓を書き残しています。

Therac-25の事故調査を通じて分かったこと
  • ソフトウェアはどんなに慎重に作っても満足できるほどに完璧にはならないため、ソフトウェアがどんな動きをしたときでも、人命に危険が及ばないようにシステムを設計する必要がある(フェールセーフ、独立した安全装置の設置など)
  • ソフトウェアの信頼性をできるだけ高めるのは悪いことではないが、それでソフトウェアが安全になるわけではない。プログラマは要求を満たすようにコードを書くが、要求が正しいとは限らない。事故のほとんどは、プログラミングのエラーではなく、要求が間違っていたり、不完全であったりしたために起きている
  • われわれの目標は、だれもがこの経験を生かせるようにすることであり、装置のメーカーや他の人を批判することではない。間違いは、このメーカーにだけ起きたのではなく、残念ながら、安全が最優先されるべきその他のシステムにも、きわめて日常的に起きている
  • いくつかの出来事が複雑に絡み合って起きた事故が、一つの原因にされることが多すぎる。ほとんどの事故は、システム事故、つまり、さまざまな構成部分や機能が複雑に作用しあって起きるものだ。事故の原因を一つに特定することは、大きな間違いだ。

 経済性の優先、ソフトウェア開発効率の向上という目的のもと、組込みソフトウェア開発の世界でもプラットフォームの共通化や機能別にCPUを分散させるのではなく、高性能なCPUを少数使って制御を統合させる動きが強くなっています。

 自動車にはECU(Electric Control Unit)と呼ばれる電子制御ユニットが数多く搭載され、高級車には大小様々なCPUも100個以上使われています。トヨタは、今後ECUを4群に統合していく方針を表明していますが、一つのCPUが複数の機能を担うようになればなるほど、安全アーキテクチャ重要性は増し、安全アーキテクチャや安全ソフトウェアの可視化が重要になってきます。

 Nancy Leveson 教授が語ったTherac-25の事故調査から導き出された組込みソフトウェアの安全に関する教訓は、20年以上経過した現在でも生き続けています。というよりも、組込みソフトウェアの大規模・複雑化とCPUの統合化により、より危険性が加速されてきおり、組込みソフトエンジニアがソフトウェア開発を行っている際に常に考えていなければいけない重要な教訓となっています。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 酒井 由夫(サカイ ヨシオ)

    1987年よりクリティカルデバイスのソフトウェア開発に20年間従事する。おもに16bitのワンチップマイコンを使った信号処理、リアルタイム組込みシステムの開発を行い、製品の仕様立案からソフトウェア開発のプロセス管理、プロジェクトマネージメント、安全性・信頼性の検証、保守、ソフトウェア技術者教育など組...

バックナンバー

連載:安全ソフトウェアの設計
All contents copyright © 2005-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5