STPAの第4ステップで忘れがちな「損失シナリオ識別」の詳細手順：今こそ知りたい！STAMP/STPAの勘所（5）（1/3 ページ）

より複雑なシステムの安全性解析の理論とその分析手法である「STAMP/STPA」を実践する上での勘所をTips形式で簡潔に分かりやすく説明する本連載。第5回は、STPA手順「第4のステップ：損失シナリオの識別」を失敗しないための重要ポイントとして、シナリオ作成の詳細手順について解説する。

[石井正悟，MONOist]

　システムとシステムがつながる、より複雑なシステムの安全性解析の理論としてSTAMPが注目され、その手法であるSTPAの普及が進んでいる。本連載はSTAMP/STPAを実践する際に役に立つと思われる勘所の幾つかをTipsの形式で簡潔に分かりやすく説明する。

⇒連載「今こそ知りたい！STAMP/STPAの勘所」のバックナンバーはこちら

　連載の最終回となる第5回は、STPA手順「第4のステップ：損失シナリオの識別」を失敗しないための重要ポイント、注意点について解説する。前回までは、各ステップにおいて幾つかある勘所の中から1つ、2つをピックアップして解説してきたが、今回は損失シナリオ識別のステップを詳細手順の流れに沿って次の順番で解説する。

• 詳細な潜在的原因の特定にはプロセスモデル、アルゴリズム、センサー、アクチュエーターの明示が役に立つ
• シナリオの起点となる抽象的なUCA／ハザード誘発要因を特定する
• シナリオ作成では2つのタイプを考慮する
• 創発的要因、複合要因を考慮したシナリオ作成が重要

損失シナリオを識別する

　第4のステップではUCA（Unsafe Control Action）に対する損失のシナリオを識別する（図1）。

図1　STPA第4のステップ「損失シナリオの識別」

　STAMPにおいて損失のシナリオは次のように定義されている。

損失のシナリオは、非安全なコントロールアクション及びハザードに至る可能性のある、因果関係要因を説明するものである。

A loss scenario describes the causal factors that can lead to the unsafe control actions and to hazards.

センサーとアクチュエーター、プロセスモデルとアルゴリズム

　第3のステップまでは、コントロールアクション（CA）とフィードバック（FB）について検討するが、FBが（例えばセンサーで）測定／検出する方法やCAが（例えばアクチュエーターで）実行される方法までは検討しない。つまり、第3のステップまでは原因を考えない。

　第3のステップまではCA、FBというコンポーネント間の相互作用に着目して分析を進める。そのため、CS図（制御構造図、Control Structure Diagram）にセンサーやアクチュエーターが入るとコンポーネント間の関係性が見づらくなってしまいかねないので、センサーやアクチュエーターを省略すると良い。また、コンポーネント内の事情であるプロセスモデルやアルゴリズムよりも、コンポーネント間の関係を見易くするため、やはりCS図にそれらを明示しない場合が多い。

　一方、第4のステップでは、抽象的なUCA／ハザード要因から始めて、非安全なCAおよびFBの特定の原因（個々の詳細な要因やその組み合わせ要因）を識別してシナリオを作成するので、センサーやアクチュエーターを含むようにCS図を変更すると役に立つ。同じく、アルゴリズムやプロセスモデルも明示すると、UCA／ハザードの誘発要因を見つけやすくなる。

※）慣れればこれらをCS図に明示しなくても意識するようになる。また、CS図に明示すると要因を発想する際に大きな助けになるが、その後、関係者に要因を説明する際には不要、と筆者は考えている。分析にモデリングツールを使えば表示／非表示を容易に切り替えられるのでお勧めする。

シナリオの起点を特定する

　第4のステップのタイトルは「損失シナリオの識別」となっている。「損失シナリオ」の定義に有る通り、シナリオはUCAおよびハザードの誘発要因を説明するためのものなので、UCA／ハザード誘発要因を特定する必要がある。しかし、むやみに詳細な誘発要因の洗い出しから始めるのではない。かといって、単に「さぁ、シナリオを作ろう」といわれてもどうして良いか悩むと思う。

　そこで、後述の2つのタイプのシナリオを考える起点となる抽象的なUCA／ハザード誘発要因を特定することから始めることをお勧めする。STPA Handbookには、シナリオを考える起点となり得る幾つもの（少なくない）ヒントが提示されているので、そこから該当しそうなものを選んでも良い。

　ここで、失敗しないための重要なポイントがある。上述の抽象的なUCA／ハザード誘発要因とは、いわばシナリオの大分類のようなものである。個々の詳細要因／潜在的原因ではない。以下に抽象度のさじ加減について例を示す。

• 「ドアが開いた状態で電車が発進して乗客が転落してケガをする」というUCAがあったとする。そのシナリオを考える起点となる抽象的なUCA／ハザード誘発要因の例である
  • 良い例：後述のシナリオタイプaの例
    • 制御対象のドアが開いているのにコントローラーはドアが閉まっていると認識していた（プロセスモデルと実際のプロセス状態の不一致）、というような抽象的なレベル
  • 悪い例：詳細な潜在的原因を特定
    • ドアセンサーからの開閉状態信号が通信経路の問題で抜け落ちた、というような詳細レベル
• 「電車が走行中にドアが開いて乗客が転落してケガをする」というUCAがあったとする。そのシナリオを考える起点となる抽象的なUCA／ハザード誘発要因の例である
  • 良い例：後述のシナリオタイプbの例
    • コントローラーがドア開を指示していないのにドアが開いた（制御経路または他コントローラーとのCA競合）
  • 悪い例：詳細な潜在的原因を特定）
    • 乗客が非常レバーに触れてドア開指示が出る。保護機能が無いまたは故障で働かない

　悪い例でも「乗客が非常レバーに触れたときに保護機能が働かず走行中にドアが開く」という複合要因を考慮したシナリオは特定されるものの、この例を起点にしても他の詳細要因や他のシナリオは出てこない。

　関連し得る詳細要因はシナリオを作成する過程で特定されるべきで、この順番を間違えないこと。これを間違えると複合要因や未知の要因に目が向かなくなってしまい、もはやSTAMPではなくなる。

　STPA Handbookでも「共通のミス（良くあるミス）を防止するためのヒント」として、「共通のミスの多くは、シナリオよりもむしろ、個々の因果関係要因を識別することにある」と強調している。

※）シナリオを考える起点となる抽象的なUCA／ハザード誘発要因を特定し、その抽象的な要因への対策を検討すると、未知の詳細要因を未知のまま対策検討できることにもなる。