STPAの手順を理解する：基礎から学ぶSTAMP/STPA（2）（2/4 ページ）

連載の第1回では「STAMP/STPAとは何か」「既存の分析手法と何が違うのか」に焦点を当て、分析手法の流れを紹介した。第2回は、STPAの実践手順を解説する。各ステップで「何をすべきか（What）」と、具体的に「どうすればよいのか（How）」を中心に紹介していく。

[石井正悟（IPA ソフトウェア高信頼化センター 調査役），MONOist]

ステップ0 準備1：アクシデント、ハザード、安全制約の識別

　最初のステップでは分析の目的を明確化するために「アクシデント」「ハザード」「安全制約」の3つを決める。これらを決めるのは、他のシステムエンジニアリングのハザード分析にも共通する。ただし、STAMP/STPAでのハザードの定義は、他の分析法とは異なっている可能性があることに注意したい。それぞれの定義は以下の通りだ。

アクシデント

　望んでもいないし計画もしていない、損失につながるようなイベントを指す。具体的には人命損失、けが、物損、環境汚染、ミッション喪失、経済的損失といったものである。STAMP/STPAでは安全工学の技法をできるだけ幅広く適用する意図で、アクシデントの種類も広域に網羅している。

ハザード

　システム（機器）を取り巻く環境が最悪な条件と重なることで、アクシデントにつながる状態を指す。この定義には、安全性と信頼性の混同を回避するために、単なる故障とハザードを区別し、分析可能な範囲を拡げるといった意図がある。ハザードが「コントロール対象のシステムの境界内のものである場合」と、「コントロール範囲外の環境が影響している場合」では、ハザードの“質”が異なるからだ。

安全制約

　ハザードが識別されると、そこからシステムを安全に保つための要件、もしくは制約を導くことができる。トップダウンで考える場合、まず高レベルの安全制約が導かれることになる。安全制約はこの段階で全て確定するとは限らず、STPAの実施によって導出、修正されることもある。

ステップ0 準備2：コントロールストラクチャーの構築

　アクシデント、ハザード、安全制約を考えるのは、アクシデントのモデルやハザードの解析法によらず、一般的な手順である。STAMP/STPAのユニークな点は、コントロールストラクチャーを構築することだ。システムのコンポーネントに機能を割り当てるといったことは一般のシステムエンジニアリングの活動でも行われている。しかし、システムの安全を維持するためにコンポーネント間のインタラクションがどのように連携しているのかをモデル化した「コントロールストラクチャー」というモデルを基に考える点が、既存手法と大きく異なる。

　多くの複合的で複雑なシステムにおいて、機能的な振る舞いに関する情報は、システムごとに点在している。そのため把握することが難しい。一方、STAMPのコントロールストラクチャーは、システムの安全を維持する仕組みをうまくグラフィカルにモデルとして表現しているため「共有資料」として役立てられる。