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

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

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

ステップ2：非安全なコントロールの原因の特定

　UCA抽出したら、非安全なコントロールにつながるシナリオの原因を特定する。ただし、ステップ1とステップ2を完全に別のものとして逐次的に行う必要はない。一部のUCAを抽出した段階で、原因の分析を行う場合もある。ここでは、安全のために必要なコントロールアクションの不適切な実行を考慮する。

　このステップは、分析者の経験と考察を最も必要とするため、ステップ1よりも事前に設定できるガイドラインは少ない。しかし、可能性のあるハザードの原因を取り除いたり緩和したりするなど、安全制約を保つために必要な情報を分析する重要なステップだ。分析のポイントは、以下の2つに大別される。

1. どのようにして非安全なコントロール、ハザードにつながるかを分析する
2. 必要なコントロールアクションが与えられたにもかかわらず、適切に実行されない原因を分析する

図1　コントロールループで安全制約を破られる原因の例（クリックで拡大）

　図1は、コントロールループで食い違いが発生し、安全制約を破られる原因となり得るケースのヒントである。それぞれの「非安全なコントロールにつながるシナリオ」は以下の通りだ。

1. コントロールの入力か外部情報が欠けているか間違っている
2. 作成時の欠陥、プロセスの変更、誤った修正や適用など、不適切なコントロールアルゴリズムがある
3. 不整合、不完全、または不正確なプロセスモデルになっている。不適切な操作をしている。
4. コンポーネントの不具合。経年による変化がある
5. 不適切なフィードバック、あるいはフィードバックの喪失。フィードバックの遅れがある
6. 操作の遅れがある
7. 不適切または無効なコントロールアクション、コントロールアクションが喪失している
8. コントロールアクションの衝突。プロセス入力の喪失または誤りがある
9. 未確認、または範囲外の障害がある
10. システムにハザードを引き起こすプロセス出力がある

　分析によって得られたシナリオは、システムを保護するための「コントロールの識別」に用いられる。なお、保護のためのコントロールの設計は、STPAの解析結果を用いてドメインの専門家が行うのが一般的である。

　原因を特定する際の注意点は、従来の体系的な分析方法であるFMEA（Failure Mode and Effect Analysis）と混同しないことだ。FMEAは故障／不具合の防止を目的とした分析手法であるため、シナリオの一部分だけ取り上げるとFMEAでも分析できると勘違いしてしまうことがある。

　非安全なコントロールの原因を特定する目標は、ループ内のコンポーネントの故障や不適切な操作を見つけることだけではなく、非安全なコントロールにつながり得るシナリオや問題の組み合わせを見つけることである。

　よくあるソフトウェアや人間の間違いの例は、間違ったプロセスモデルによることが多い。こうした事態を避けるためには、「なぜプロセスモデルが間違ったのか」を考えることが大切だ。

---

　次回は「はじめてのSTAMP/STPA」で紹介した「踏切制御システム」の分析事例を用いて、実際に分析する際の注意点や勘所を示しながら、STAMP/STPAの分析で行うべき作業を詳細に解説する。

プロフィール

石井 正悟（いしい しょうご） IPA ソフトウェア高信頼化センター 調査役

京都大学理学部卒業後、東芝エンジニアリングを経て東芝ソリューションにて、OSカーネル、システムシミュレーション技術の研究開発に携わる。現在はIPAにて、STAMP、FRAMなどの安全性解析手法の調査研究に従事。

・IPA ソフトウェア高信頼化センター
https://www.ipa.go.jp/sec/