最初のステップとしてアクシデント、ハザート、安全制約の3つを決める。
以下の分析を行った結果のSTAMP WorkbenchプロジェクトファイルはこのURLからダウンロードできるので、STAMP Workbenchでこのプロジェクトファイルを開いて操作しながら本稿を読み進むことをお勧めする。
⇒STAMP Workbenchプロジェクトファイルのサンプル
STPA Handbookでは、このステップで「解析目的を定義する」としている。「解析目的を定義する」には、まず解析対象システムがどういうものであるかを明確にする必要がある。通常、このステップへのインプットとして、システムの「要求仕様書」がある。システム開発の構想段階のような超上流では、いまだ要求仕様書の体裁をなしていない場合もあるかと思う。ここでは、解析作業へのインプットとして、図4のような要求仕様が与えられたものとする。
上記の要求仕様では、システム境界が不明瞭なので、どこまでを分析するのかが定まらない。そこで前提条件を設定して、システム境界を定義する。また、前提条件では、仕様についても仮に設定しなければ、安全か非安全かを区別できないこともあるので、分析しながら都度前提条件を追加/修正していくことになる。
STAMP Workbenchでは、図5のような前提条件表に整理していく。
次に、対象システムにおける損失(Loss)は何かを定義する。STAMPでは、その損失が発生することをアクシデントと呼んでいる。そして、アクシデントに至る可能性のある状態をハザードと呼んでいる。安全制約とは、ハザードの裏返しである。
STPA Handbookに示された損失の例は以下の通り。
これらのうち、どれにフォーカスして解析したいのかを識別する。
STPA Handbookでは、システムレベルのハザードについて3つの基本的な基準を示している。
上記をヒントにして、STAMP Workbenchの「アクシデント、ハザード、安全制約表」に記入していく(図6)。
IDはツールが自動的に付加する。自動的に付加されるIDとは別に独自のIDを付ける必要があれば、それぞれの文言の先頭にでも挿入するなど、ツール活用の工夫をすると良い。
Copyright © ITmedia, Inc. All Rights Reserved.