組込みソフトウェアに求められる安全対策

翔泳社さんが「組込みZine 」という情報サイトを立ち上げた。そちらに、『組込みソフトウェアに求められる安全対策』という記事を書いたので今回はそれを読んでいただきたい。この記事は第一回から第四回に分かれており、第一回目は「組込みソフトウェアに求められる安全対策」というテーマになっている。

さて、先日 ET2007の特別講演で、工学院大学 グローバルエンジニアリング学部 教授 畑村 洋太郎 氏の「危険学のすすめ」の講演を聴いた。

畑村先生はシンドラーのエレベータの事故の状況を現地までいって調べたそうで、その話を聞いてシンドラーのエレベータの事故でソフトウェアは関係していないかもしれないことが分かった。

事故現場のエレベータのブレーキは車のブレーキのように動いているものを止めるのではなく、止まっているときのその状態をホールドする役割だったらしい。そして、エレベータはかごと釣り合いをとるために釣り合い重りがつり下がっている。この重りの重さはエレベータの最大乗員の重量の1/2である。そうするとエレベータが静止しているときにホールドするブレーキが摩耗して抑えられないときに、乗員が一人しかいないと釣り合い重りの方が重いためにゆっくりとかごが上昇する。当時、事故にあった高校生は自転車に乗ったままだったため、自転車が半分エレベータから出たところでかごが上に上がってしまい釣り合い重りの重みで体が長時間圧迫されてしまったというのだ。

こうなると、ソフトウェアは内部ではかごが止まっていると認識しているので為す術がない。畑村先生の話が事実ならば、ブレーキの摩耗はエレベータシステムにとって非常に大きいリスクとなる。点検が十分でなければどのエレベータも危ないということになってしまう。

このリスクに対する安全対策はいろいろあるが、ソフトウェアでなんとかしようと思ったら「目」となるセンサーがいる。エレベータが物理的に動いているかどうかを検出するセンサを持っていれば、CPUが認識するかごの状態と実際のかごの状態に差異がないかどうか判定できる。

なにはともあれ、エレベータのブレーキの摩耗という一次故障でかごが動いてしまうという事故を起こしてしまうのは、システムとしての安全性が低いと言わざるを得ないだろう。実際にはそんなに簡単な原因ではなく複合要因で起きた事故なのかもしれないが、事故が起きた原因を調査した結果をオープンにしてもらわなければ事故の再発防止は進まない。

このことはソフトウェアの不具合についても同じことが言える。お客さんに迷惑をかけるような事故を起こしたら、それが起きた原因を追及して再発防止の対策を立てることが重要だ。ソフトウェアの場合、たったひとこと「バグ」とか個人のミスといった原因にされやすいが、そうではなく、開発工程のどこでどんな施策をとれば同じような問題を防止できるのかといった目で見ることが大切である。