安全ソフトウェアの設計の指針
組込みソフトウェアの大規模・複雑化とCPUの統合化の傾向の中で安全ソフトウェアを設計するには、安全ソフトウェアの設計は将来に渡っても変更されない、もしくは変更が最小になるようにし、危険を伴う処理は極力制御がシンプルになるようにすることが必要です。そうすれば安全に関わる機能や性能が要求を満たしていることが検証しやすくなり、安全が確保されていることの妥当性が確認しやすくなります。
そして、ソフトウェアシステムの安全の堅牢性を検討するには、事故が起きるシチュエーションとシナリオを想定し、想定したシナリオが起こったとしても安全ソフトウェアがリスクを排除できるもしくは、リスクは発生しないことを証明します。
このような安全ソフトウェアを設計するための施策は、ユーザーも設計者も過ちを犯しやすい人間であることを意識した施策です。人間は過ちを犯しやすい上に忘れやすくもあります。このため、設計した安全ソフトウェアのアーキテクチャや安全設計の設計コンセプトをわかりやすく可視化することが重要です。
安全設計のコンセプトは簡単に変えてはいけない
ソフトウェアによる安全システムを実現するには、安全システムを設計するだけでなく実装まで行う必要があります。組込みシステムの場合、せっかく安全設計を行っても実装に至る工程で簡単にプログラムを変更できてしまうことに危険が潜んでいます。プログラムのちょっとした変更で安全設計のコンセプトが崩れてしまったのでは、安全システムを分析設計するのに時間をかけた意味がなくなってしまいます。
したがって、一度、確認した安全設計のモデルやアーキテクチャに関わるプログラムの変更を行うときは、安全設計のモデルに立ちもどって変更の正当性をチェックする必要があります。安全設計モデルが頻繁に変更されるようなら、最初に作ったモデルやアーキテクチャに何か問題があるに違いありません。このようなときは、一度冷静になって安全ソフトウェアのアイソレーションとシンプルデザインについて考え直します。
設計したモデルが実装に至る工程で、設計者の意図とは異なるもとににならないようにする方法として、モデル駆動開発という考え方があります。モデルをコードに変換する変換アーキテクチャを定め、人の手を介さずにコード生成まで自動で行ってしまおうという方法です。
いずれは組込みの世界でもこのようなモデル駆動開発が主流になる日がくるかもしれませんが、まだまだ時間はかかると思います。また、モデル駆動開発が主流になったとしても、設計コンセプトとなるモデルをエンジニアが簡単に変更してしまうようでは、安全設計のためにモデル駆動開発を導入した意味がなくなってしまいます。
安全システムの実装
組込みシステムでは、よかれと思って設計したモデルを実装に至る過程でメモリが足らなくなったり、CPUパフォーマンスが足りなくなったりして、当初のモデルを変更せざるを得ないことがあります。こういった場合でも、安易に安全設計のコンセプトを曲げてモデルを変更してはいけません。
システムの安全設計に関しては、性能要件を満たすことよりも、信頼性や検証のしやすさのメリットを取った方が製品全体の価値のバランスよい場合が多いと言えます（※1）。組込み機器を製造するメーカーが何十年もたってから起こった不具合に対しても社会的な責任を負う時代では、機器の安全性を担うソフトウェアが他の機能からアイソレートされシンプルな設計になっていることが大事になってきます。
※1 安全ソフトウェアのアイソレーションとシンプルデザインが実現できているのなら、モデルを変更しなければいけなくなることは滅多にありません。
