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

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

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

STPAの概要

　はじめに前回のおさらいをしよう。

　STAMP（Systems-Theoretic Accident Model and Processes：システム理論に基づくアクシデントモデル）は、「要素間の相互作用に潜む問題が顕在化したときに危険な状態になり、事故につながる」という考え方である。そして、STPA（System-Theoretic Process Analysis）は、STAMPの考え方に基づいて相互作用が正しく働かない条件を抽出／特定（原因究明）するという、新しい安全性解析手法である。

　STPAは、システム開発を行うときに用いるハザード分析手法という位置付けだ。前回で紹介した通り、旧来のハザード分析手法と比較し、複雑でソフトウェアの役割が大きなシステムの分析に適したものとされている。

　STPA実践の第一歩は、「対象システムを理解する」ことから始まる。対象システムのコントロールストラクチャーを確認した後、回避すべきアクシデント（システムにとっての損失）とハザード（危険な状態）を決めてSTAMPによるモデリングを行い、STPAの分析に着手する。

　STAMP/STPAによるモデリングは、以下の3つの要素を基にしている。

STAMPモデルの3要素

• 構成要素間の相互作用を表すコントロールストラクチャー
• コントロールする側がその対象プロセスをコントロールするアルゴリズムと対象プロセスを（抽象化して）表現したプロセスモデル
• 守るべき安全制約

　次にSTPAのプロセスを見てみよう。STPAのプロセス構成は、以下の4パートを包含している。

STPAのプロセス構成

• 分析やシステム開発に必要なシステムエンジニアリングの基盤を整える
• 非安全となる可能性があるコントロールアクションを識別する
• 識別した非安全なコントロールアクションを使って、安全要求や安全制約を求める
• ハザードをもたらす各コントロールアクションがどのように生じるかを分析する

　STAMP/STPAを提唱したマサチューセッツ工科大学（MIT） 教授のナンシー・レブソン（Nancy Leveson）氏は、「STPAはシステムなどの発展に伴い、トップダウンのアプローチで繰り返し行われるものである」としている。つまり、手順（手法）例として参照できるものはあるが、絶対的なものは存在しない。ハザード分析を行う目的や段階の違いも含め、STAMP/STPAの具体的な適用には、さまざまなバリエーションが考えられる。なお、STPAでは以下のようなハザード誘発要因によって危険な状態になり、条件がそろったときにハザードがアクシデントにつながると想定している。

ハザード誘発要因

• 対処されない環境外乱や環境条件
• 対処されなかったりコントロールされなかったりするコンポーネントの障害
• コンポーネント間の非安全な相互作用
• 適切に協調されていない複数のコントローラーによるコントロールアクション

　では、次から実際の手順（ステップ）を見ていこう。今回紹介する手順は、IPAが2015年に公開した『STAMP手法に関する調査報告書』を基にしている。同報告書の手順は以下の通りだ。

STPAの手順（例）

• ステップ0 準備1：アクシデント、ハザード、安全制約の識別
• ステップ0 準備2：コントロールストラクチャーの構築
• ステップ1：安全でないコントロールアクション（UCA）の抽出
• ステップ2：非安全なコントロールの原因の特定