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

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

Step2：HCF（Hazard Causal Factor）の特定

　STPAに慣れてきても難しいのがStep2である。STPAでは、Step2における万能手法を提示していない。Step2の分析手法は分析者が工夫しなければならない。

　筆者は、鉄道システムに関して素人なので、図13と図14のような2つの絵を描きながら、何が起きたらハザードに至るか（これをハザードシナリオと呼ぶ）を考えた。

図13　踏切鳴動停止が早過ぎるハザードシナリオのイメージ（クリックで拡大）

図14　踏切鳴動停止指示がToo earlyとなるケース（クリックで拡大）

注意事項

　ここで、図13と図14を思い描くときの重要な注意点を記す。

　ハザードシナリオを説明するために図13、図14の順番で示したが、思考の過程は、図14が先で図13が後になる点に注意して欲しい。これは、STPAの思想に関わる重要なことである。

誤った思考過程

　まず、図13の「金属製看板が飛んできてセンサーが短絡する」というハザードシナリオを思い付き、その後、図14を使って非安全な状態になることを机上で確認する。

正しい思考過程

　まず、図14のように「制御の動作が非安全な状態」になる（UCAである）ことを机上で確認し、その後、何があったらそうなるかを考えた結果、図13のハザードシナリオを思い付く。

---

　誤った順番で行った場合、対象ドメインに精通した人、経験した人でなければハザードシナリオを容易に思い付くものではなく、その分析結果も既知の範囲、経験の範囲に限定され、網羅性に欠けたものになってしまいかねない。

　手順に従うことにより、図14のようなヒントを得て、そのヒントから図13のようなハザードシナリオを発想させるのがSTPAなのである。

　ここから、STAMP WorkbenchにHCFを入力していく。例えば、上記の「金属板が飛んできてCに接触し、さらに飛び去り、その後、列車がCに到達」といった状況はSTAMP Workbench のHCF表内のハザードシナリオ欄に記述する（図15）。

図15　STAMP Workbench操作画面：ハザードシナリオ/HCF表（クリックで拡大）

　STAMP WorkbenchではIDが自動割り当てされるので、HCFの追加／削除、あるいはUCAの追加／変更、コンポーネントの統合／分割／名称変更などがあっても、図表修正の手間はほとんどかからない。このため「もしかしたら、コントロールストラクチャーはこうあるべきではないか」と思ったら、何度でもすぐに試してみることが容易である。このような試行を繰り返すことは分析結果の質の向上につながるであろう。

　STAMP Workbenchのようなツールを使わずに、このStepまできてコントロールストラクチャーを変更するなどとなったら、おそらく分析者は手戻り作業の多さ、面倒臭さに頭を抱えてしまうであろう。そしてもしかしたら、STAMPのような手間のかかる分析はもうやりたくない、と感じてしまうかもしれない。

　煩わしい手作業はツールに任せ、人は考えることに専念し、STPAの有効性を享受できることを願う。STAMP Workbenchはとても便利なものと自負しているが、読者の皆さまが使ってみて改善の余地に気付かれたら、ぜひ下記の連絡先までご意見をいただきたい。

IPA 技術本部 ソフトウェア高信頼化センター

---

　「基礎から学ぶSTAMP/STPA」について3回の連続記事で解説してきた。これまで解説してきたように、STAMP/STPAは、安全性解析手法としては従来手法と考え方や手順がかなり異なる。そのため、従来手法に慣れた人にとって取っ付き難く感じられるかもしれない。しかしその一方で、読者の皆さまの日常の考え方に近いものではないかと筆者は捉えている。まずは、簡単な例で試していただきたい。

（連載完）

プロフィール

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

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

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