TOPページ > 例会 > 第5回例会議事内容

第5回例会議事内容

システムオブシステムズ研究会（第5回）報告

世話人　落水浩一郎

第5回システムオブシステムズ研究会を下記のとおり開催したので報告する．

記

日時：2018年5月18日　18:30～20:30

場所：銀座ビジネスセンター，〒104-0061　東京都中央区銀座6-6-1銀座風月堂ビル５階

出席者（順不同）：日下部　茂（長崎県立大），新谷　勝利 (新谷ITコンサルティング) ，

瀬尾　明志（日本ユニシス），堀雅和（インテック），

奈良　隆正（コンサル21世紀），方　学芬 (SRA先端技術研究所)，　

羽田裕（日本電気通信システム），艸薙　匠（東芝），

矢嶋　健一（JTB）落水　浩一郎（UIT，世話人)，

議事：

18:30～20:30　講演「“STAMP/STPAの最新の動向”日下部　茂（長崎県立大）」

およびSTAMP/STPA についての意見交換

日下部先生におまとめ頂いた、日下部先生による講演の概要と，質疑・意見交換の内容を

以下に記す．講演と質疑を通じて，STAMPモデルの考え方と，STPAの手順について，

理解をふかめることができた．

  • STAMPモデルとは

まず，背景を含めた概説が行われた． STAMP は，システム理論に基づいた新しい事故因果関係モデルである．ソフトウェア集約的なシステムが増加し，その安全性についての効果的な分析も求められている．しかしながら，ソフトウェアそのものは故障しないし，その利用や運用をする人や組織も故障はしない．そのようなソフトウェア集約的なシステムを，故障という観点で分析することには限界があることなどが説明された．STAMP/STPA では，システムのコンポーネントが故障していなくても，コンポーネント間の非安全な相互作用によっても事故が引き起こされ得るとし，コントロールの問題という観点で対象をモデル化し分析するものとして提唱されている．

図 1　基本的なSTAMPのモデル構成

基本的なSTAMPモデルの要素と構成例を図 1に示す．安全性のような創発性をコントロールする必要がある対象を，コントロール対象のプロセスとし，そのコントローラがコントロールのためのアクションを決定して発行し，その結果のフードバックを得ることを繰り返す． STAMP では，システムの安全制約を守れず，システムがハザード状態になることで望まない損失が発生することを，上記のようなモデル要素で表現されるコントロールストラクチャーを用いてモデル化，分析する．

STAMPとその分析法STPAの入門的解説は，文献[1]をはじめすでに複数のものがあるが，それらを読んで実際に自分でモデルの構築と分析を試みるとよくわからない点が出てくる，といった質問があった．例えば，図 1に示した基本的なモデルの構成要素について文献[1]では以下のように説明されているが，プロセスモデルの “belief” がわかりにくいとの質問があった．

「コントロールアルゴリズムは，コントローラの意思決定プロセスを表わし，コントールアクションを決定する．コントローラは，また，意思決定を行うために使われるコントローラ内部の信じていること(belief)を表すプロセスモデルを持つ．プロセスモデルは，コントロールアルゴリズムによって使用され，コントロール対象のプロセスについて信じていることやシステムまたは環境の他の関連のある側面を含むことができる．プロセスモデルは，コントロール対象のプロセスを観測するために使われるフィードバックによって部分的に更新できる．

図のどの時点でも，問題は発生する可能性がある．例えば，プロセスモデルは，現実と一致しない場合があり（例えば，コントローラが，飛行機が本当は上昇している時に降下していると考えたり，自動車が本当は後退(reverse)に入っている時に駐車(park)に入っていると考えたり，空港の滑走路が空いている，など），これは，非安全なコントロールアクションにつながる．センサの故障が，誤ったフィードバックを引き起こし，非安全な動作につながる可能性がある．ある設計では，必要なフィードバックが欠落しているかもしれないし，プロセスモデルの欠陥と非安全な動作をもたらすような遅延フィードバックを与えているかもしれない．不十分なプロセスモデルは，非安全なコントロールアクションを引き起こす可能性がある．コントローラのプロセスモデルが現実とは一致しない場合，プロセスモデルの欠陥が発生する」

講師から，「例えば，子供を引率する状況を考えてみたときに，子供に的確な指示を出すために指導者の頭に何が入っていないといけないか，といったもの．ある程度抽象的なレベルでも考えることができるし，指示を出す対象の子供の特性や，屋外でのキャンプや工場見学のような状況に関する情報などで特化した上で考えることもできる．」「STAMPは，意図的に緩くなっている側面もあり，機械的に実行できるような記述体系もないため，ある意味敷居が低い反面，記述の基準がわかりにくく感じる場合もあるかもしれない．また，モデル化と分析を複数回繰り返しながら洗練化することも想定されており，適宜見直されることもある．」といった説明があった．

STAMPでのコントローラとコントロール対象のプロセスの組み合わせは，機械-機械に限定されず，人間-人間，人間-機械，組織‐機械，などであってよく，実際に様々な組み合わせでのモデリングが行なわれ実績を上げている．STAMPに関する分析法(ツール)には図 2のようなものがあるが，代表的なものは後述のSTPAと，CASTである．STPA は，開発中に潜在的な事故の要因を分析し損失を未然に防ぐための事前の解析手法であり，CAST は，発生した事故/インシデントを評価し，関与していた原因因子を識別するための事後的な解析手法である．

図 2　STAMPと関連ツール(分析法)およびその利用プロセス
  • STAMP /STPA

STAMPに基づく分析法の最も代表的なものであるSTPA の紹介があった．現在も研究が続いている手法でもあり，その具体的な適用法には様々なバリエーションがあるが，最近発行されたハンドブックでは以下のような手順となっている[1]．

  1. 解析目的の定義，
  2. コントロールストラクチャーのモデル化，
  3. 非安全なコントロールアクションの識別，
  4. 損失シナリオの識別

アクシデントなどの用語の使い方は，分野，業界ごとに異なることが多く，ハンドブック[1]では混乱を避ける目的で「損失」という用語を用いている．

手順1　解析目的の定義

STAMP/STPAはトップダウンの手法で，まずモデリングの目的を定める必要がある．どのような損失をその解析で防ぐことを狙っているのか？ STPAを人命の喪失を防ぐような伝統的な安全目標に対して適用するのか？もしくは，セキュリティ，プライバシー，性能，及びその他のシステム特性に対して，より広く適用するのか？解析対象となるシステムは何か？システムの境界は何か？これら及び他の基本的な質問が，このステップで問われることになり，以下の手順からなる．

  1. 損失を識別
  2. システムレベルのハザードを識別
  3. システムレベルの安全制約を識別
  4. (オプション)　ハザードの精密化

STAMP では，(業界や分野で定義が異なる可能性のある用語である) 損失，システム，ハザード，安全制約は以下のように定義されている．

損失：利害関係者にとって価値のあるものを失うことに相当．損失には，利害関係者に受け入れられないような，人間の生命の喪失や人間の傷害，物的損害，環境汚染，ミッションの喪失，評判の喪失，機密情報の喪失もしくは漏洩，またはその他のものが含まれる．

システム：いくつかの共通の目標，目的，または，その達成のために，一体として合わせて動くコンポーネントの集合．システムには，サブシステムを含んでもよく，また，より大きなシステムの一部であってもよい．

ハザード：ハザードとは，最悪ケースの環境条件と組み合わさることで，損失につながるような，システム状態，または，条件の集合である．ハザードは対象システムの境界内のものであり，システムの範囲，範囲外の環境との境界が明確になっている必要がある．また，ハザードが実際に損失につながるのは，組み合わさる，最悪の環境条件の存在が必要である．

安全制約：システムレベルの制約は，ハザードを防ぐ（そして最終的に損失を防ぐ）ために満たす必要があるシステムの条件や動作を特定する．典型的には，ハザードが識別されると，それらを逆に反転して考える．トップダウンに考える場合，まず高レベルの安全制約が導かれることになる．最初からすべての安全制約が確定するとは限らず，分析の途中でも導出，修正され得る．

手順2　コントロールストラクチャーのモデル化

コントロールストラクチャーとよぶシステムのモデルを構築する．コントロールストラクチャーは，一連のフィードバックコントロールループとして，システムをモデル化し，機能的関係性及び相互作用を表現している．コントロールストラクチャーは，通常，非常に抽象的なレベルで始まり，システムの更に詳細な情報を表現するために，繰り返し改良されていく．図 1では最も単純な構成のものが示されていたが，一般的に，コントロールストラクチャーは階層的な構造となる．階層的なコントロールストラクチャーの縦軸には意味があり，システム内のコントロールと権限を示している．各エンティティは，その直下のエンティティ対するコントロールと権限を有し，かつ各エンティティは，同様にすぐ上位のエンティティからのコントロールと権限の対象となっている．

上向きの矢印はフィードバックを表しているのに対し，下向きの矢印はコントロールアクション(コマンド）を表している．これらの約束ごとは，複雑さを管理し，コントロールの関係やフィードバックループの識別を容易にする助けとなる．単にコントロールストラクチャー・ダイアグラムを描くことで，以前に発見されていない欠陥を，明らかにできるケースもある．例えば，安全なコントロールアクションを選ぶのに必要なフィードバックを持たないエンティティによってコントロールアクションが与えられるかもしれない，フィードバックがそれについて何かをする能力を持たないエンティティに与えられるかもしれない，競合を検知したり解決する能力を持たないコンポーネントへ複数のコントローラが競合するコマンドを与えることができるかもしれない，など．

手順3　非安全なコントロールアクションの識別

コントロールストラクチャーのコントロールアクションが最初のステップで定義された損失にどのようにつながり得るかを調べるために，非安全なコントールアクションを分析する．非安全コントロールアクション（UCA）は，ある特定のコンテキストと最悪の環境下で，ハザードにつながるコントロールアクションのことである．これらの非安全なコントールアクションは，以下の四つの側面があり，システムの機能要求や制約を作成するために使われる．

  • Not providing causes hazard : コントロールアクションが与えられないことがハザードにつながる．
  • Providing causes hazard :コントロールアクションが与えられることがハザードにつながる．
  • Too early, too late, or wrong order causes hazard : 潜在的には安全なコントロールアクションを，遅すぎて，早すぎて，または不適切な順序で与えることでハザードにつながる．
  • Stopping too soon or applying too long causes hazard : (連続的で非離散的なコントロールアクションにおいて) コントロールアクションの停止が早すぎる，もしくは適用が長すぎることがハザードにつながる．

手順4　損失シナリオの識別

システムで非安全なコントロールが発生する可能性のある理由を識別する．損失のシナリオは，典型的には，コントローストラクチャを右上と左下のように対角線で区切るようにして，２つのタイプを考慮する(図 3 参照)．

図 3　損失シナリオ識別の例
  1. なぜ，非安全なコントロールアクションが起こるのか？　間違ったフィードバック，不適切な要求，設計ミス，コンポーネントの故障，及びその他の要因が，どのように非安全なコントールアクションを引き起こし，最終的に損失につながり得るのか．
  2. なぜ，安全なコントロールアクションが与えられたとしても，不適切に実行される，または実行されず，ハザードに至るのか？

この手順は，対象領域の専門知識が必要となることが多くガイド化が難しいとされていたが，最新のハンドブック[1]では以前より詳細なものが示されている．

  • MITにおける国際会議他

最後に関連するツールや， 2018年3月にMITで開催されたSTAMPに関するワークショップの内容が紹介された[2]．ワークショップは年々参加者が増え，2018年3月は登録ベースで32か国，300人越えの参加者があった．主には，航空宇宙・防衛関係，次いで自動車関係であったが，医療機器，ヘルスケア，オイル・ガス，鉄道，化学，ヒューマンファクター，ロボット，セキュリティ，労働環境安全など様々な領域がカバーされていた．ソフトウェア工学関係も若干含まれていた．

文献

[1] Nancy G. Leveson, John P. Thomas著，白坂成功他訳，“STPA_Handbook_JPV02”,

http://psas.scripts.mit.edu/home/get_file2.php?name=STPA_handbook_japanese.pdf, 2018年5月18日確認

[2] STAMP Workshops, http://psas.scripts.mit.edu/home/stamp-workshops/, 2018年5月18日確認