日経ものづくり 2006年10月号に シンドラーのエレベータの検証記事が掲載された。2006年6月，東京都港区のマンションで起きたエレベータでの事故の原因はまだ分かっていないが、日経ものづくりの記事ではエレベータの構造や安全装置のしくみなど、かなり深いところまで掘り下げておりいろいろと勉強になった。【特集 －事故は語る－「シンドラーの波紋」 記事の内訳】
Part 1 総論
相次ぐ事故に共通する課題
再発防止に三つの視点
Part2 安全装置の裏側
トビラが閉じずに動くカゴ
想定外の事態で表れた弱点
Part3 軽視された保守
自覚のなさが高めるリスク
業者間の責任分担を明確に
Part4 生かせぬ教訓
埋もれてしまう不具合情報
分析と公開が予防のカギ
【引用おわり】
自分が興味があるのは、エレベータの構造とハードウェアデバイス、そしてエレベータの詳細な要求仕様である。これらが分かればエレベータの制御ソフトウェアをどのように作ればいいかだいたい分かる。
組込み機器はユーザーとして使う立場に立てば、その機器の表に出ている制御仕様はだいたい分かる。ソフトウェアの価値である顕在的価値と潜在的価値のうち、顕在的価値の部分は、外に見えているところからその中身を予測できる。
しかし、組込み機器の潜在的価値を構成している「使いやすさ」や「安全性」「保守性」などの部分は、外側からではよく分からない。よく分からないのだが、「使いやすさ」「安全性」「保守性」に使われているハードウェアデバイスがシステムとどのように結合しているのかが分かると、ソフトウェアがどんな制御をしているのかもある程度想像できる。
今回、日経ものづくりの記事で再確認したのは、安全装置に関しては「かご側のトビラ確認スイッチ」「乗り場側のトビラ確認スイッチ」「モータ」「電磁ブレーキ」の関係がベースにあるということだ。
戸開走行しないための安全機能は、かご側のトビラと乗り場側のトビラが両方とも閉じているときのみ、電磁ブレーキを解除し、モータを回転させてよいということだ。
2006年6月の事故では、かご側のトビラと乗り場側のトビラが両方開いてるにも関わらず、電磁ブレーキが効かずにモータが回転してしまった。電磁ブレーキの摩耗の疑いがあるようだが、電磁ブレーキが摩耗していたとしても、それとは別に、トビラの開閉のセンシングを誤り、モータを積極的に回転させなければ事故は起こらないことから、どう考えても運転制御プログラムが怪しい。
そう考えていたら、ソフトウェアの不具合を誘発しそうな要因があることが今回の記事でわかった。それは、戸開走行の例外処理だ。
【戸開走行する例外処理も－「シンドラーの波紋」より引用－】
実は、安全制御装置にはトビラが開いた状態でも電源を投入するようにバイパスが設置されているときがある。それが、再床合わせ装置を持つエレベータの場合だ。
再床合わせとは、ロープの伸びなどによってカゴの床面と乗り場側トビラの床面に発生した段差を調整すること。乗り場の床とカゴの床に段差があった場合に、つまづいたりして危険だからだ。主に、ロープが長い高層エレベータや積載容量が大きいエレベータで採用される。
【引用おわり】
要するに、トビラが開いたときでも再床合わせゾーンの範囲内であれば電磁ブレーキを解除し、エレベータをゆっくりと走行させる。この際には、一種の戸開走行となる。ただし、この例外仕様の安全対策として、再床合わせゾーンを越えてドアゾーンを外れると安全装置がモータへの通電を遮断し、エレベータを制止する。
この再床合わせの戸開走行のソフトウェアは危険を伴う例外的な処理であり、他のソフトウェアに比べて、より慎重により正確に作り込まなければならない。
ここで組込みソフトエンジニアとして思うのは、安全面から考えたときのこの例外処理が他の処理より重要度が高いということを示すのは以外に難しいということだ。
安全装置がハードウェアデバイスとして、メインCPUの制御から独立している場合、その機能や役割は外から見えやすい。メインCPUとのインターフェースも明確であり、安全装置単体としてのテストもしやすい。しかし、安全をつかさどる制御ソフトウェアがその他のソフトウェアと一緒になってしまっていると、その重要性の高いソフトウェアをマーキングして「ここが装置の安全性を確保するためのソフトウェアですよ」と強調したくても、外からその重要性を分からせる方法がないのだ。
結局、ソースリストを追いかけることでしか問題があるのかないのか分からないということになりがちだ。
たとえば仮に、モータを制御する関数の中身が以下のようになっていたとしよう。
void driveMotor（ 命令 ）
{
/* モータを止める処理 */
if ( 命令 == STOP) {
モータを止める;
電磁ブレーキON；
}
/* モータを正転させる処理 */
else if ( 命令 == UP ) {
status = getCageStates();
if ( status != open ) {
電磁ブレーキを解除;
モータを正転させる;
}
}
/* モータを逆転させる処理 */
else if ( 命令 == DOWN ) {
status = getCageStates();
if ( status != open ) {
電磁ブレーキを解除;
モータを逆転させる;
}
}
}
ようするに、モータを正転、逆転させるという処理に入ってから、ドアが開いていないかどうかをチェックしている。安全のための同じ処理が複数点在してしまっている。
一方、安全確認のソフトウェアはモータ処理とは独立させて監視させたり、モータ制御の関数を呼ぶ前にチェックをし、そのチェックがOKにならなければモータを制御させないという作り方もできる。
問題なのは、ソフトウェアの場合、目的を達成するための方法（プログラムの作り方）はいくつもあり、どのようなプログラミングをしているのかは、外からはよく見えないということだ。
上記のプログラミング構造に、戸開走行の例外処理を追加し、 "SLOWUP" や "SLOWDOWN" などの制御を追加し、付け足し付け足しでシステムを完成させたとしたらどうだろう。
関数の複雑性は増し、テストから漏れるパスが生まれる可能性も出てくる。
試行錯誤でソフトウェアシステムを作り上げる怖さはここにある。外見では同じように動くソフトウェアであっても、潜在的価値の低いソフトウェアはある。ソフトウェアエンジニアがそうしたいと思っていなくても、試行錯誤でソフトウェアを作り上げることで、なかなか到達しにくい部分に爆弾を作り込んでしまうことはあるのだ。
この危険は排除するために、メインCPU（制御プログラム）とは独立した、安全機能の装置を設ける方法はある。しかし、このような独立した安全装置は確実にコストアップにつながるので経済性を優先させようとした場合、取り除いてメインプログラムの中に入れればいいという判断になりやすい。
そうすると、安全機能は外から見えなくなり、キチンと機能しているかどうかわかりにくくなる。
日経ものづくりの記事では、制御装置のプログラムミスの可能性を示唆しているものの、どのようなミスの可能性があったかについては言及していない。国土交通省のエレベータワーキングチームでは、安全装置の独立化と安全制御プログラムに関しては第3者の専門家によって認証・確認する体制を構築することを提言しているらしいが、第3者の専門家による認証・確認というのはたぶん機能しないと思う。
なぜなら、第3者の専門家が安全性に関してお墨付きを与えるということはおそらくできないからだ。安全機能のためのソフトウェアの独立性や完全性は、同じCPUで動いている他のソフトウェアの影響を絶対に受けないという保証ができないだけに、どんなときでもキチンと動くということを証明するのは難しい。スレッド（タスク）を動的に生成しているシステムでメモリリークなどの影響を受けないことを保証することは非常に難しい。
不確定要素がある中で、第3者が安全性を保証することはできない。安全性の検証や妥当性確認は装置を組み上げてユーザーに提供するメーカが行うしかない。完成された部品をシステムに組み込む場合は、それがハードウェアであってもソフトウェアであってもその部品が仕様どおりに動くかどうかを検証することはできても、システムに組み込んだ後の安全性を保証することはできない。
実は、日経ものづくりの記事を読んだ後に感じたのは、「これだけ詳細な内容を記者はよく調べたなあ」という感想と「これだけ詳細な記事の中でソフトウェアについてはほとんど突っ込まれていない」という印象だ。
日経ものづくりは生産や機械設計といった話題が得意分野の雑誌だけに、ソフトウェアにメスを入れろということ自体ムリなのかもしれないが、分かったのはやっぱりソフトウェアは見えにくいということなのだ。探偵のようにエレベータを調べまくった記者もソフトウェアの中身までには切り込むことができない。この見えない世界の中で何が行われているのかは、ソフトウェアエンジニアしか知らない。
だから、ソフトウェアエンジニアが口を閉ざしてしまうと、ソースリストから問題の原因を探るしかない。事故が起こりやすいソフトウェアであればあるほど、構造が複雑であり問題を起こすカラクリを解きほぐすことが難しい。
安全をコントロールするソフトウェアの独立性を高め、その機能や性能の検証が容易になるようにしておかなければいけない。
そして、ソフトウェアモジュールを動かすベースである、オペレーティングシステムの検証は十分に行い、リスクがないことを確認しておく必要がある。
組込みソフトウェアの安全性を高めるための技術はある。それはなんだろうと思った方は『組込みソフトエンジニアを極める』の第4章－品質の壁を越える－を読んでいただければと思う。
以前書いた「シンドラーの事故を再発防止するためにエンジニアは何をすべきか」の記事も参照されたし。
0 件のコメント:
コメントを投稿