SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

安全ソフトウェアの設計

【第3回】安全アーキテクチャの可視化


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

 3回目となる今回は、ソフトウェアにおける安全アーキテクチャの可視化について見ていきます。

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

安全アーキテクチャの可視化

 ソフトウェアの安全設計で一番大事なのは、「安全ソフトウェアが、ソフトウェアシステムの中で、どのようなメカニズムで機能を発揮するのか」を可視化することです。そして、ソフトウェアエンジニアが可視化した安全ソフトウェアの動きや他のソフトウェアとの独立性を説明し、「安全ソフトウェアが、設計コンセプトの通りに動作するか」「設計に漏れや抜けはないか」を検証する必要があります。このときに、アイソレーションやシンプルデザインができていない場合は、安全が確保できているかどうかが怪しいということになります。安全ソフトウェアのアイソレーションやシンプルデザインが説明できないために、独立したハードウェアの安全装置を設けたり、メインCPUとは別のサブCPUに安全ソフトウェアを組み込むことはできますが、全体としては安全を担うソフトウェアが複雑で多岐に分散することになるため、リスクがなくなったことを示す労力はそれまで以上にかかることになります。

 一般的な組込み機器のように、安全確保のために使える時間やコストに限りがある場合では、中身がよく見えないソフトウェアシステムの外側に安易に安全装置を付け足すのではなく、安全ソフトウェアを他のソフトウェアからアイソレーションし、危険を制御するソフトウェアの構造、動作のメカニズムを極力シンプルにして、検証と妥当性確認をしやすくすることが大事です。

 図1や図2を見れば分かるようにプログラムのソースコードレベルで安全ソフトウェアのアイソレーションとシンプルデザインを示すのは至難の業です。仮にこのプログラムを作った設計者から納得のいく説明があったとしても、その設計者以外では安全ソフトウェアのアイソレーションとシンプルデザインの根拠を説明できないでしょう。これは、ソースコードよりも上位層の設計図が安全ソフトウェアを実装した技術者の頭の中だけにしか存在しないからです。

図1:ミスを誘発しやすい安全処理(再掲)
図1:ミスを誘発しやすい安全処理(再掲)
図2:インターロック機構を使った古いエレベータ(再掲)
図2:インターロック機構を使った古いエレベータ(再掲)

会員登録無料すると、続きをお読みいただけます

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

次のページ
UMLを使った安全設計の可視化

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
安全ソフトウェアの設計連載記事一覧

もっと読む

この記事の著者

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

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

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/3698 2009/03/16 18:38

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング