STPAの分析を実際にやってみる：基礎から学ぶSTAMP/STPA（3）（3/6 ページ）

Step0（準備1）：アクシデント、ハザート、安全制約を識別する

　最初のステップとしてアクシデント、ハザート、安全制約の3つを決める。

　以下の分析を行った結果のSTAMP WorkbenchプロジェクトファイルはこのURLからダウンロードできるので、STAMP Workbenchでこのプロジェクトファイルを開いて操作しながら本稿を読み進むことをお勧めする。

⇒STAMP Workbenchプロジェクトファイルのサンプル

　STPA Handbookでは、このステップで「解析目的を定義する」としている。「解析目的を定義する」には、まず解析対象システムがどういうものであるかを明確にする必要がある。通常、このステップへのインプットとして、システムの「要求仕様書」がある。システム開発の構想段階のような超上流では、いまだ要求仕様書の体裁をなしていない場合もあるかと思う。ここでは、解析作業へのインプットとして、図4のような要求仕様が与えられたものとする。

図4　安全解析対象システム：単線の駅中間踏切制御システム（クリックで拡大）

要求仕様（基本的な動き）

• i.：警報開始センサー（A,B）で列車を検知すると踏切鳴動を開始させる
• ii.：警報終止センサー（C）で列車を検知すると一定時間後に鳴動を終止させる
• iii.：AからCに向かうとき、Bをマスクする
• iv.：BからCに向かうとき、Aをマスクする

　上記の要求仕様では、システム境界が不明瞭なので、どこまでを分析するのかが定まらない。そこで前提条件を設定して、システム境界を定義する。また、前提条件では、仕様についても仮に設定しなければ、安全か非安全かを区別できないこともあるので、分析しながら都度前提条件を追加／修正していくことになる。

　STAMP Workbenchでは、図5のような前提条件表に整理していく。

図5　STAMP Workbench操作画面：前提条件表（クリックで拡大）

　次に、対象システムにおける損失（Loss）は何かを定義する。STAMPでは、その損失が発生することをアクシデントと呼んでいる。そして、アクシデントに至る可能性のある状態をハザードと呼んでいる。安全制約とは、ハザードの裏返しである。

　STPA Handbookに示された損失の例は以下の通り。

1. 人命の喪失または人々への負傷
2. 車両の損失または損害
3. 車両外部のものの損失または損害
4. ミッションの喪失（例えば、輸送ミッション、監視ミッション、科学的ミッション、防衛ミッション、など）
5. 顧客満足度の損失
6. 機密情報の喪失
7. 環境の損失
8. 発電の損失

　これらのうち、どれにフォーカスして解析したいのかを識別する。

　STPA Handbookでは、システムレベルのハザードについて3つの基本的な基準を示している。

• ハザードは、システム状態または条件である（コンポーネントレベルの原因または環境状態ではない）
• ハザードは、いくつかの最悪ケースの環境で損失につながる
• ハザードは、防止されるべき状態または条件を言い表さなければならない

　上記をヒントにして、STAMP Workbenchの「アクシデント、ハザード、安全制約表」に記入していく（図6）。

図6　STAMP Workbench操作画面：アクシデントハザート安全制約表（クリックで拡大）

　IDはツールが自動的に付加する。自動的に付加されるIDとは別に独自のIDを付ける必要があれば、それぞれの文言の先頭にでも挿入するなど、ツール活用の工夫をすると良い。