安全分析の図的表現方法、及び設計文書と親和性の高いツールの提案

○ 田中伸明（ガイオ・テクノロジー株式会社）小川清（名古屋市工業研究所）

１．概要

システム設計と安全分析の関係を直感的に把握しやすくするために次の対策を提案する。
・システム設計図上への故障の連鎖の表示
・システム設計ツール上の安全分析機能の提供
上記対策を実現するHAZOP 向け安全分析用ツールを試作しISO/IEC 20741 [1]の評価項目を適用して評価することで本提案の有効性を確認した。また、既存ツール、及び設計文書との親和性があり、利用者にとって便利であることを確認した。

２．背景

安全関連系の開発では材料、機械、電気、ソフトウェアの異なる分野の専門家の知見の活用が必要である。IEC 61508、ISO 26262 等の機能安全規格の普及に伴い、車載機器等のコンピュータ組込み機器開発において従来主流だったハードウェア中心の安全分析に加え、システム、及びソフトウェアの安全分析が活発に行われるようになった。
また、システムの複雑化に伴いSysML 等の準形式手法の図法(以下準形式手法と呼ぶ)で設計を表現するMBSE (Model Based Systems Engineering)が普及しつつある。従来は汎用作図ツールを使い不定形の図で設計を表現することが多かったが、モデリングツールを用いて準形式手法でシステムの構造、振る舞いを表現するケースが増えつつある。

３．従来技術の課題

準形式手法で表現された設計に対して安全分析を行う際には、次の2 種類の方法が一般的である。
(a.1) 準形式手法の図を分析者が見つつ、スプレッドシート（Microsoft Excel 等）に安全分析の結果を記入する。図の構成要素とスプレッドシートの安全分析の項目の関係は、同一の識別子(ID)を付与して表現する。
(a.2) 準形式手法の図を安全分析専用ツールにインポートし、安全分析専用ツール内で安全分析を行う。
しかし上記の方法にはそれぞれ次のような課題があった。
(b.1) 準形式手法の図の構成要素(エレメント、機能)と、スプレッドシート上の故障の関連がID のみで表現されているので、直感的に把握/理解しにくい。
(b.2) 設計のモデルが準形式手法のモデリングツールと安全分析専用ツールの双方のモデルに保持されるため、モデル間の一貫性を維持する作業が困難になる。
特にMBSE を必要とするような大規模、かつ複雑なシステムの設計、分析の際には上位設計と分析を交互に繰り返すことが多く、故障と構成要素の関連の把握、及び一貫性の維持が困難になっていた。

４．本稿の提案

本稿では、前章で述べた課題を解決するために次の解決策を提案する。
(1) 解決策1: システム設計図上への故障の連鎖の表示
従来はFTA のツリー図、 FMEA の表に表示されていた安全分析結果(故障、安全目標侵害)をシステム設計又は安全設計の図面(機能ブロック図と呼ぶ)上に表示する。また、故障と故障が発生する構成要素の間の関係、及び故障と故障の関係（原因-結果の関係）をそれぞれ専用の関連線で表現す
る。（図1）
内部的にはFMEA、及びHAZOP が含む情報を図2 に示す構造で保持し、図2 のモデルを表示するための構成要素、関連をUML Profile を用いて表1 のように定義し、図の構成要素として追加する。
図１故障と構成要素の関連の図示
図２安全分析に関する情報のモデル
表１追加する構成要素、及び関連
種別親クラス stereotype 意味
構成要素 Class SElement エレメント
構成要素 Class SFunc 機能
構成要素 Class Malfunction 故障
構成要素 Class SGViolation 安全目標侵害
関連 Connector in 存在箇所を示す
関連 Connector causes 原因-結果関係
(2) 解決策2: システム設計ツール上への安全分析機能の統合
システム設計と安全分析の情報を常に一貫させるため、システム設計ツール（SysML モデリングツール）に図2 の構造の安全分析に関する情報も保持させ、システム設計ツール上で安全分析の情報の入力、表示を行う。

５．解決策を有効に機能させるための方策

前章で述べた2 件の解決策をより効果的に利用するため、及び解決策を適用する際に発生する問題をあらかじめ防止するために、次の機能を提供する。
(1) 関連する故障(指定した故障に起因する故障)の抽出
１つの製品の安全分析で扱う故障の数（部品ごとの故障の総数）は、数百～数千に及ぶことが多い。そのため、すべての故障を1 枚の図に描画することは現実的でない。そのため、実際の運用では1 枚の図には関連のある故障（せいぜい二十数個）のみを1 枚の図に表示し、複数枚の図で安全分析結果の全体を表現することが予想される。この運用を効率化するために、本提案では、指定した故障が原因となって発生する故障、安全目標侵害を再帰的に（芋づる式に）抽出し、1 枚の図に表示する機能を実装した。
(2) GUI 上でガイドワードを指定し故障を入力する機能マウスの右クリック操作（コンテキストメニュー）からガイドワードを選択することで、故障を追加できる機能を実装し、入力を容易化した。
(3) 外部ファイルとの連携、同期（スプレッドシート出力/CSV 入力）
スプレッドシートで作成された既存の安全分析の結果を利用するために、外部のスプレッドシート形式データとの連携機能（インポート、エクスポート）を実装した。

６．設計、実装

本提案のツールは、4 章で述べた機能をUMLProfile によるモデリングツールのカスタマイズにより実現し、5 章で述べた機能をモデリングツールのアドインとして開発し、実現した。

７．評価、検討

(1) 評価方法
本提案の方法論、及びツール導入の効果を、ソフトウェアエンジニアリングツール導入効果の評価のガイドラインであるISO/IEC 20741 の箇条10に示されている評価項目を適用して評価した。評価は名古屋市工業研究所が担当した。評価方法は下記の通りである。
 安全分析の経験のある技術者が本提案のツールを利用して1 つの設計例(仮想的なアンチロックブレーキシステム)に対して安全分析を行い、1 から5 の5 段階の順序尺度でISO/IEC 20741 箇条10 に示されている不可分副特性(Atomic sub-characteristics)を評定する。評定の集約方法は算術平均とする。
 評定の判断基準はSysML の図とスプレッドシートによる安全分析作業との相対評価とする。SysML の図とスプレッドシートを用いた安全分析と不可分副特性が同じ場合の評定を3 とし、本提案が大きく優れている場合の評定を5 とする。
(2) 評価結果
(2.1) 品質特性の傾向
本提案で述べた試作ツールを既存の製品と比較して評価したため、一般的なソフトウェア品質については低い評価となったが、ツールの機能面については高い評価が得られた(表２)。
特に、SysML モデリングツールと安全分析の連携の効率化により、既存の成果物、ツールとの統
合容易性(integrability)の評価が高い(表３)。
表２ツールの特性全般の評価
節タイトル評定
10.2
Characteristics related to software
engineering tool usage functionality 3.3
10.3 General quality characteristics 2.1
10.4
General characteristics not related to
quality 2.0
表３ツールの機能面の評価
項タイトル評定
10.2.2
Software engineering tool operation
environment characteristics 3.0
10.2.3
Software engineering tool integrability
characteristics 3.8
10.2.4
Software engineering tool application
characteristics 2.9
(2.2) 特徴的な効果
3 章で述べた課題の解決以外の効果として、6章(1)で述べた「指定した故障に起因する故障の抽出」の機能が安全分析結果の抜け漏れの発見、確認に有効であるとの評価が評価者から得られた。

８．目的達成に関する考察、今後の課題

解決策の目的達成に関する考察、及び今後の課題について述べる。
(1) 目的達成に関する考察
(1.1) 解決策1: システム設計図上への故障の連鎖の表示
本提案の図法、及びツールにより、設計の構成要素と故障の関係の理解が容易になり、解決策1の当初の目的は達成できた。
しかし、今回の試作ではSysML から派生させた独自の構成要素(表1)を用いて設計を表現する機能ブロック図を作図することを前提としており、既存のSysML の図に対して直接、安全分析を行う機能は実現しなかった。そのため、評価において既存のツール、又はデータとの統合容易性の評定は、最高の評定の5 とはならなかった。統合容易性をより高めるために、SysML の図に対して直接、安全分析を行う機能の実現などの改善策が必要である。
(1.2) 解決策2: システム設計ツール上への安全分析機能の統合
本試作では、SysML モデリングツール上に設計と安全分析のデータを統合し、設計と安全分析における変更を即時に他方に反映させ、常に一貫性を保つという目的を達成できた。
しかし、入力の容易性、ツールの可用性、ツールへの要員の習熟度を考えると、実用上はスプレッドシートを用いた安全分析との併用は不可避と思われる。本活動では、スプレッドシートとの間のデータのインポート、エクスポート機能は実現したが、実開発で使用する際は、たとえばリアルタイムでスプレッドシートとツールの間でデータの一貫性を維持する同期機構のような、より高度な一貫性維持の機能の実現、又は運用上の対策が必要になると思われる。
(2) 今後の課題
(2.1) システム設計と安全分析の図の組み合わせ方、及び複数図面間でのレイアウト変更反映前述した通り、今回の試行では1 枚の図の上に表示する故障を関心のあるもののみに留めて数を減らし、複数の図で安全分析結果を表現した。しかし、複数の図面上の構成要素のレイアウトを個々の図に対して人手で整える必要があり、図の数が大量になると、レイアウトを統一することは困難になる。
開発対象の規模が大きくなる場合は、表示をシステム設計と安全分析のレイヤーに分け、複数の図の間でシステム設計の構成要素のレイアウトを同じに保つ機能提供のような対策が必要になると思われる。
(2.2) 安全分析で扱う故障の粒度
本方式で故障の原因-結果の連鎖を機能ブロック図上に表示する場合、最初の故障から安全目標侵害までの経路にあるすべての構成要素に対応する故障間の関係を入力、表示すると、膨大な数の故障間の関係を扱うことになる。
FMEA、HAZOP による安全分析では、故障発生から安全目標侵害までの原因と結果の関係を部品単位で文書化せず、結果として生じる安全目標侵害の内容を詳細に記載することが多い。この省略は、開発の段階に応じて適切な粒度で安全分析を行うべきであるというISO 26262 などに示される規定にも沿っている。反対に、本提案の図法を用いてすべての部品単位での故障間の関係を過度に詳細に図示し、分析することは安全分析の粒度の観点で不適切と思われる。
今後は適用例を増やし、本提案に適した、故障及び故障間の関係の粒度の選択方法について、検討していく必要がある。

９．おわりに

安全分析の図的表現を改善するツールの評価/試用を通じて、本提案は従来の安全分析の結果の確認の効率化のために有効であることが分かった。
また、7 章(2.2)に示したように、当初想定した効果以外の効果も生まれることが分かった。また、安全分析をより効果的に行うために改善すべき点も発見できた。
今後は本活動を通じた知見をもとに図法、及びツールの改善を進めるとともに適用事例を増やし、本提案のより有効な利用方法を検討していきたい。

参考文献

[1] ISO/IEC 20741:2017, “Systems and software engineering – Guideline for the evaluation and selection of software engineering tools”.
[2] IEC 61882:2001, “Hazard and operability studies”.

追加資料

ガイオテクノロジーの田中伸明さんとのUML関連共同研究の動画
DECSoS 2020 presentation by Nobuaki Tanaka
https://www.youtube.com/watch?v=mm8lxZuAadA
https://www.youtube.com/watch?v=_OJ-l1WYGr4&t=28s

安全分析の図的表現方法、及び設計文書と親和性の高いツールの提案
https://qiita.com/kaizen_nagoya/items/048dfde781cace74e718

成功体験は語っても、成功体験に頼らないために。清水吉男・田中伸明・柏原一雄・佐々木眞一。仮説(153), 図(28)
https://qiita.com/kaizen_nagoya/items/d32adfaf7b2568bfd9d2