安全設計のコンセプト
図1のソースレベルの分析と見比べれば分かるように、クラス図によるモデリングによって、安全装置としての機能の独立性や、センサやアクチュエータという外界との接点、エレベータの昇降機能の責務を負っているクラスの独立性が可視化されています。
このクラス図では、センサやアクチュエータがエレベータ昇降制御のクラスと安全システムのクラスからアクセスされています。センサやアクチュエータを昇降制御と安全システムで物理的にも独立させる場合もありますが、民生機器でコスト削減も求められているケースでは、この例のようにセンサやアクチュエータと共用することが多いと思います。
センサの共有をUMLで可視化したことによりセンサの誤動作や誤った情報の伝達はシステムの安全に大きな影響を与えるということが分かるようになりました。また、アクチュエータが共有されているため、エレベータ安全システムがシステムの異常を察知してモータを止め、ブレーキをかけているときに、もし、かご巻き上げコントローラがモータを動かせと命令してきても、モータドライバやブレーキアクチュエータはかご巻き上げコントローラの命令を無視してエレベータ安全システムからの指令を優先しなければいけないといったことがモデリングにより明らかになります。モデルをレビューすることで、矛盾した命令を受けたときは安全システムからの指示を優先して実行しなければいけないことに気がつきます。
ソースレベルで設計していった場合は、異常ケースのテストを繰り返しているときに上記の問題に気づき、アクチュエータの制御に例外処理を追加するような形で実装されることが多いでしょう。このような試行錯誤のアプローチを繰り返していると、本来の機能に傷を付けてしまう（デグレードしてしまう）可能性が高くなります。
これを防ぐためにデグレードしていないことを回帰テスト（リグレッションテスト）で確認することも大事ですが、そもそも安全システムに対して後々の変更が影響を及ぼしにくい設計にしておくことが、安全設計に関してより重要な施策となります。それが実現できれば、システムの基本機能がシンプルかつ確実に設計されていることが分かりやすくなり、かつ、安全ソフトウェアの働きが明確になるので、システム全体の安全性が検証しやすく、システムの妥当性を確認しやすくなります。
例外処理を安全設計のコンセプトを崩さず追加する
図5で示したカゴと乗り場の床のレベルを微調整する機能の追加を検討した結果を図6に示します。
図3、図4で作成したクラスに加えて、フロアレベルセンサクラスとフロアレベルアジャスタクラスが追加されています。フロアレベルアジャスタはこの例外処理を実現するための独立した責務を持ったクラスであり、エレベータマネージャに所属しています。また、フロアレベルセンサは再床合わせ処理で使用すると同時に、エレベータ安全システムもセンサの情報をgetするために関連を持っています。フロアレベルセンサは共用になっていますが、例外処理を追加してもエレベータ安全システムはエレベータの昇降の制御処理機能からは独立しているという点に注目してください。
そして、エレベータ安全システムクラスは、ドアが開いている状態で、かつ、フロアレベルセンサの情報からカゴが再床合わせゾーンから外れたときのみエレベータを緊急に止める処理が追加されます（もともとのエレベータ安全クラスから派生された再床合わせ用の安全クラスを作ることもできる）。これにより、基本のエレベータ安全クラスに対して、安全装置としての独立性を保ったまま、最小の修正で例外処理を追加することができました。
次回は、いよいよ最終回。安全ソフトウェアの実現と維持に向けた取り組みについて見ていきます。
