ISO/IEC Guide 51では、安全規格を策定するにあたりリスクアセスメントは下記4つの手順に従うのが望ましいとされている。ISO 26262では第3部　第7節ハザード分析およびリスクアセスメントでASILを用いたリスク評価手法が提供されている。

1 制約の決定

製品又はシステムから被害を受ける可能性のある使用者の同定、製品又はシステムの意図する使用、および合理的に予見可能な誤使用を同定する。
ISO 26262では状況分析時に本内容を考慮して動作状況や運転モードを分析することを求めている。

2 ハザードの特定

製品又はシステムの各使用段階(据付け、作動、メンテナンス、解体など)及び使用状況から生じるそれぞれのハザードを同定する。
ISO 26262では適切な手法を用いてハザードの抽出を行うことを求めており、HAZOPガイドワードを用いてアイテムの機能不全モードを同定していくケースがよく見られる。

3 リスクの見積もり

リスクは危険事象が発生した場合の危害の度合いと危害の発生確率の組合わせであると定義されているため、危害の度合いおよび発生確率を定量化してリスクを見積もる。
ISO 26262では危険事象はハザードと動作状況の組み合わせで決定するため、危険事象が発現した場合のリスクの度合いをSeverity、危険事象に至るシチュエーションに晒されている確率をExposure、ハザード発現時に危険事象の回避行動の成功見込みをControllabilityで見積もる。

4 リスクの評価

Guide 51では以下に挙げる設計段階の3ステップメソッドと使用段階の追加の方策の適用がリスク低減の原則とある。設計段階の3ステップメソッドとは「本質的安全設計」「ガードおよび保護装置」「最終使用者のための使用上の情報」の順番でリスク低減の方策を検討していくことである。

本質的安全設計とは、ハザードを除去する及び、またはリスクを低減するために行う、製品またはシステムの設計変更又操作特性を変更するなどの方策

ガード及び保護装置は、本質的安全設計によって合理的に危険源を除去できない、又はリスクを十分に低減することもできない場合に、人を保護するために使用する

最終使用者のための使用上の情報とは、設計者や供給者から提供された情報に沿ってリスクを低減する役割がある。

ISO 26262では安全分析の手法として演繹的分析、帰納的分析、定性的分析、定量的分析を適切に用いることが第9部8節で推奨されている。このうち定量的分析は決定論的原因故障、システマテック故障には適用されず、確率論的な故障、ランダムハードウェア故障の分析に用いられる。安全分析はアーキテクチャ設計を行ったのちに設計検証として実施することが要求されており、低いASIL(ASIL A,B)が付与された安全関連には帰納的分析が強く推奨、高いASIL(ASIL C,D)が付与された安全関連には帰納的および演繹的手法の適用が強く推奨されている。また安全分析は安全機構・安全要求を導出するためにも用いることができる。先述の安全に関する基本概念で推奨されているリスクアセスメントからリスク低減活動のプロセスを当てはめていただけば分かりやすい。リスクアセスメントとして安全目標侵害に至る要因を抽出して、安全目標が達成できるあるいは安全状態に遷移できる安全機構をリスク低減活動としてアーキテクチャに実装していく。あるいは現実的かつ有効な安全機構が設定できない場合は適切な安全方策により該当の安全関連を開発する方針を与えるものである。下表にISO 26262 第9部8節を参考に安全分析手法を分類したので参考していただきたい。

FMEAは自動車産業でもよく使われていることは周知のとおりで、特に自動車産業向け品質マネジメントシステム規格 IATF 16949においてはコアツールにあげられている。AIAGからFMEA実施のための参照マニュアル　Failure Mode Effect Analysis 4th Edition(翻訳版はジャパンプレクサスから出版されているFMEA第4版スタディガイドを参照)が出版されており、IATF 16949の認定を受けている企業で広く活用されている。またVDAからもFMEAのガイドラインが規格化されている。VDAのWebサイトからVDA Volume 4 Chapter　Product and Process FMEA(通称VDA 4)が購入可能である。双方にはFMEAの実施手法、危害度・発生頻度・検出性の定義など様々な違いがあったが、AIAGとVDAが共同でFMEAハンドブックを策定し、発行する動きがある。VDAからのアナウンスによれば2018年5月にリリースするとあるが、ドラフト最終版に対してコメントが多数あがっておりリリース計画からは遅れているようだ。

VDAからの事前のアナウンスによればFMEA実施手法についてはVDA 4で用いられている手法が大枠で採用されて、6つのステップでFMEAを進めていくことになる。(VDA FMEAでは5つのステップだったが1つステップが追加)

従来は、AIAG マニュアルに記載されているFMEAワークシートを用いて危険事象につながる故障モードを特定し、その潜在的リスクをRPNという定量値で示し、ある基準にもとづいたリスク分析を行ってRPNを低減する対象を決定、設計変更や評価によるリスク低減活動が実施されていた。しかしながらFMEAにおける分析結果の正当性を説明するにあたって、故障モードが機能失陥、車両挙動へと影響が伝播することを説明できる資料は存在せず開発者のスキルや知識に頼るケースが多かった。機能安全、ISO 26262で求められる安全分析のためにFMEAを使用した場合は、その分析結果の正当性を説明するために何らかの工夫が必要であった。

VDA-AIAG ハンドブックの6ステップFMEAでは説明性向上や分析効率向上が期待できる。分析対象のスコープを定義し、その製品の構造分析(システム構成の階層構造モデリング)、次に機能分析(構成要素への機能割付けと機能の階層構造モデリング)をしていく。ここまでがシステム分析工程であるが、ここまでの工程はアーキテクチャ設計工程で行われている静的、動的設計で包含されるはずであり、その結果を用いることが可能である。次に故障分析(構成要素の故障モード分析、故障影響の伝播構造モデリング)、リスク分析(定量的なリスク分析)、最適化(リスク低減の実施)とリスク低減工程が続く。構成要素に故障が発生した場合、その構成要素が持つ機能が失陥し、その機能を利用する上位の機能が失陥、と故障の伝播がシステム分析結果を用いて分析することができ、かつ故障の伝播を可視化できる。設計した結果の設計書や設計モデルが安全分析の対象になっていることが明白で、かつ安全分析結果が体系的にビジュアライズされるため検証性も上がる、その正当性説明が容易になるなど利点が多い。

また新しく安全要求が安全機構としてシステムに実装されているかを分析する側面としてMSR(Monitoring and System Response)が補足として導入される予定である。危害度、故障可能性、故障検出可能性を10段階で評価し、故障発生時の故障モニタリングとシステム応答が十分であるかを評価し、リスク低減に向けた最適化を行うことになる。MSRについてはアナウンス資料に誤記と思われる点も見られるためハンドブックがリリースされたのちに内容を確認して情報を更新したい。

複雑な相互作用をもつ大規模システムの安全分析はシステム構成要素の故障だけに着目する従来の手法では不十分であるとの見解から、マサチューセッツ工科大学(MIT)のNancy Leveson教授がSTAMP/STPA (System Theoretic Accident Model and Processes：システム理論に基づくアクシデントモデル　/ System Theoretic Process Analysis：システム理論に基づく安全解析手法) を提唱している。STAMP/STPAを活用する取り組みは昨今日本でも活発化しており、独立行政法人情報処理推進機構(IPA)や組込みシステム技術教会(JASA)からSTAMP/STPAの解説や活用事例をまとめたドキュメントが発行されているのでそちらを参考されるとよい。またIPA主催でSTAMP活用事例の講演が聴講できるSTAMPワークショップが2016年から開催されている。

STPAではSTAMP:アクシデントモデルに基づいてコントローラと非コントロールプロセスとの相互作用に着目したハザード分析を行っていく。手順としてはまず分析対象となるシステムのアクシデント、ハザード、安全制約を定義する。安全制約とはアクシデント、ハザードを回避するためにシステムが備えるべき安全特性や達成すべき安全要件と考えてよい。次にシステムを構成するコンポーネント(論理的、物理的構成は問わない)及びコンポーネント間の相互作用(コントロールアクションとフィードバックデータ)を分析した結果として、制御構造図(コントロールストラクチャー図)を作成する。ここまでが準備段階である。制御構造図からコントロールアクションに着目し、4つのガイドワードを利用してコントロールアクションが期待通りにならなかった場合に安全制約を違反するかを分析していく。この分析より安全制約違反に至る非安全コントロールアクション(UCA：Unsafe Control Action)を抽出していく。次のステップとして抽出されたそれぞれのUCAに13のガイドワードを当てはめていき、どのような事象が起こるとそのUCAが誘発されるか誘発要因(Hazard Causal Factor)を抽出していく。STPAとしての手順はここまでで、抽出されたHCFに対して適切な対策を行うことはリスク低減活動の一環として実施する必要がある。

実際に先述のVDA-AIAG FMEAとSTAPを実施してみると、いずれも上位のシステムレベルから下位のエレメントレベルへと安全分析をつなげていく演繹的アプローチであることが分かる。大規模システムにおいてVDA－AIAG FMEAを適用した場合に、故障分析のステップで故障の系統図(Failure Net)を体系的に構築していくことが難しい側面があり、出来上がった故障系統図の正当性を説明するにも工夫が必要かもしれない。一方STAPでは説明性を向上させる目的として制御構造図を分析対象の階層に合わせてなるべく簡潔に記述する(分析対象をなるべく絞り込む)ことを推奨しているため分析結果の正当性が説明しやすいと考えらる。基本的な分析はVDA-AIAG FMEAの6 STEPで行い、上流のシステムレベルの安全分析ではSTAPを活用してハザードに至るシナリオを記述、その結果をおFMEAの故障系統図に反映してコンポーネントレベルに分析をつなげていくと安全分析の正当性説明がしやすいかもしれない。今後の研究テーマとして取り組んでみたい。

ISO 26262:2011　第2部　第5.4節で、規格書を通しても最初の要求事項として「組織は機能安全の効果的な達成を支援し，奨励する安全文化を創出し，育成し，維持しなければならない。」と記述されている。冒頭で記述したセベソ事故やボパール事故に見られるように、いくら決まり事があっても形骸化されていて実施されない、安全機構が備わっていてもメンテナンス不足により機能しない、このようなことが現場で起きている組織において安全文化が醸成されていると言えるだろうか？また欧米では「人は間違う」「ものは必ず壊れる」を前提とし、技術で安全を確保していく傾向に対して、日本では品質と安全を同等のもの、努力により品質をあげることで安全も担保される傾向が根強く、この違いが安全文化へも影響していると考えられる

セーフティケースについて、ISO 26262:2011　第2部　第6節の中で「安全計画に従って開発される」「安全ライフサイクル中に生成される作業成果物を、漸次まとめることが望ましい」と要求事項が示され、その要求事項に対する作業成果物としてセーフティケースが定義されているが、具体的にセーフティケースがどのようなものであるかが不明確で、多くの企業では安全活動を行った結果作成される作業成果物をまとめたものがセーフティケースであるという解釈がされている。

一方でISO 26262:2011　第10部　第5.3節でセーフティケースの理解を深めるための記述がある。要約するとセーフティケースは3つの要素　要求(安全の達成)、論証、証拠(作業成果物)で構成され、セーフティケースに与えられる目的は意図した状況で運用された場合にアイテムに不合理なリスクが無い事を論証可能な状態とすることである。ISO 26262規格書で要求している作業成果物が記録されていたとしても、作業成果物を開発したメンバーが不在となったのちに製品に不合理がリスクが残っていないことが説明できる状態にないのであれば、作業成果物の集合体のセーフティケースは本来の目的を果たさないこととなる。

第10部　第5.3節にも記述があるが、こうした安全論証を支えるフレームワークとしてGoal Structure Notation(GSN)など、論拠をグラフィカルに表現する記法の利用が普及してきている。Goal Structure NotationはGoal Structure Notation Working Groupが運営しているホームページで詳しく紹介されている。GSNを利用するためのガイドラインとしてGSN Standard(現在の最新版はVersion2)が同Working Groupから発行されている。上位のコンセプト開発や、議論を得意とする欧米に比べて、テクノロジー開発を得意とする日本では主張することが苦手、慣れていない傾向があり、こういった体系的な論証技術を身に着けることが重要ではないだろうか。