STAMP/STPAとは何か：基礎から学ぶSTAMP/STPA（1）（2/4 ページ）
システムとシステムがつながる、より複雑なシステムの安全性解析手法として注目を集めているのがSTAMP/STPAだ。本連載はSTAMP/STPAについて基礎から学ぶことを主眼とした解説記事となっている。第1回は、STAMP/STPAの生まれた理由や、従来手法との違い、実施の大まかな流れについて説明する。
STAMP/STPAは従来の手法と何が違うのか
では、STAMP/STPAと、従来の安全性分析手法の違いについて見ていこう。
トリッキーなのは、STAMP/STPAの考え方のベース（理論）が、従来手法とは異なることだ。そのため、システム安全分析の見識がある人ほど、難しく考えてしまう傾向にある。
従来の手法は「アクシデントはバグや構成機器の故障であると仮定する」という視点に立脚していた。代表的な従来のアクシデントモデルには、「ドミノモデル」や「スイスチーズモデル」があり、手法としてはFTA（Fault Tree Analysis：フォルトツリー解析）やFMEA（Failure Mode and Effect Analysis：故障モード影響解析）などが挙げられる。
なお、ドミノモデルとは、原因が結果を招き、その結果が次の原因となり次の結果を招くという、原因と結果の連鎖を表現するモデルを指す。根本原因の分析に使われる。また、スイスチーズモデルでは、リスク要因の漏れは壁があれば防げるが、穴があれば防ぎきれないという考え方が基礎になっている。リスク要因は穴から漏れることをスイスチーズ（の穴）に例えている。つまり、穴を防ぐことが対策となる。この場合、個々の穴をふさぐことで対策とする。
これらの手法は、相互作用が複雑なシステムにおける安全解析手法としては十分ではなく、新しいアクシデントモデルによる分析手法が必要とされた。それがSTPA/STAMPだ。
STAMP/STPAは「システム全体を俯瞰し、システムの安全を維持するためのコンポーネントには何があるのか」という視点に立脚する。そして、それぞれのコンポーネントが何をするかを示し、それらのコンポーネント間の相互作用に着目しながら網羅性を確保するというのがSTAMP/STPAの考え方だ。
ここからは簡素化した例として、ロケットと自動車を取り上げてみよう。
ロケットの場合
- ロケット：全ての操作がマニュアル通りでも事故は発生する
- ポイント：各機器の相互作用に着目しよう
従来手法では、アクシデントの原因は構成機器の故障や操作ミスだと捉えていた。そのため、各構成機器（装置）の安全性を確認すればアクシデントは防止できると考えられていたのである。しかし、構成機器の故障や操作ミスがなくてもアクシデントは発生する。これは「想定外事象」と呼ばれており、その原因特定は困難だとされていた（図2）。
この課題を解決するには、各機器の相互作用に着目し、安全機能を網羅的に確認する必要がある。構成機器の故障や操作ミスだけに捉われることなく、相互作用が働かない場合を想定し、安全を確保する必要がある。こうした考え方がSTAMPなのだ。
自動車の場合
- 自動車：運転手も“機能の1つ”
- ポイント：関連する全てを含めたものをシステムとして捉える
次に取り上げる自動車は、車両を構成するコンポーネントだけでなく、関連するもの全てを考慮するという事例だ。
まず、図3の（a）と（b）を見比べてほしい。図3（a）は従来の手法である。自動車システムを構成する要素となる機能ごとのコンポーネントに着目し、それらのコンポーネントを組み合わせた“自動車システム”の安全分析を徹底的に行っていた。言い換えれば、自動車を「コンポーネントの集合体」と捉えた、自動車中心の考え方である。
しかし、自動車はどのような環境で運転するか、どのような人間が運転するかによってその安全性は異なってくる。さらに、今後は自動運転機能や外部ネットワークと常時接続されるスマートコネクテッドカーなどが登場し、システムのさらなる複雑化／大規模化が進むことは間違いない。その時、自動車を機能中心の考え方で捉えては、外部環境の変化や他システムとの連携を網羅できない。自動車だけではなく、人間や環境、その他のシステムとの相互作用に着目しなければ、大丈夫とはいえなくなってきたのだ。
図3（b）はSTAMP/STPAの考え方を簡略化したものである。人間や外部環境など、運転に関係するもの全てを分析対象システムとして捉えるという考え方であり、複雑なシステムの安全分析に適していると期待されている。
Copyright © ITmedia, Inc. All Rights Reserved.