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

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

Step 1：UCAの抽出

　UCA（Unsafe Control Action）を考えて入力する表はSTAMP Workbenchが自動生成してくれる（図10）。

図10　STAMP Workbench操作画面：UCA表（クリックで拡大）

　分析者は、コントロールストラクチャーをにらみながら考えに専念するわけだが、コントロールストラクチャーだけではコントロールアクションが非安全になるか否かの判断が難しい場合もある。そういう場合には対象システムに応じた工夫が必要になる。例えば、コントロールストラクチャーには時間情報が無い。そのため、コントロールアクションとコンポーネントの状態変化の関係を時系列に整理して非安全になるか否かを考えたい、と思ったら、時間的な順序関係を見易くするための工夫が必要である。

　図11は、単線の駅中間踏切制御システムのUCAおよびHCF（Hazard Causal Factor）を考え易くするために用いたものだ。以下の3つについて、1つの図の中で見えるようにした。

• 列車の到達／通過というイベント（入力）
• イベント発生を入力として得たコンポーネントが実行するコントロールアクション（制御）
• 制御対象コンポーネントの状態

図11　警報開始・停止指示の機能仕様（正常なケース）（クリックで拡大）

　ここで、制御対象コンポーネントの状態とは、制御される側の「実際」の状態である。「制御する側が認識している」制御される側の状態（これをプロセスモデルと呼ぶ）との差異を考えるときに役立つ。差異が生じたときにはUCAとなる可能性が有る。

　図11は正常なケースにおける機能仕様であり、図12は「鳴動開始指示」というコントロールアクションが遅れた（Too late）ケースである。このように図示してみると、警報が鳴動しない状態で列車が踏切に到達するのでハザードに至る、つまりUCAになることが分かり易い。

図12　警報鳴動開始指示が遅れるケース（クリックで拡大）

　多くの開発者にとってなじみ深い状態遷移図も、UCA識別、HCF特定に役に立つ場合が多いであろう。

　UCAを識別する際、何が起きたらこのコントロールアクションが遅れるか、といった原因は考えないように注意して欲しい。原因は次のStep2で考える。