“Safeware” を基にした
組込みシステムの安全性の概要
第8回クリティカルソフトウェアワークショップ（WOCS2011） 2011/1/19（水）
自己紹介
• 身分 – ソフトウェア工学の研究者 » 電気通信大学 電気通信学部 システム工学科 » ちょっと「生臭い」研究／ソフトウェアテストやプロセス改善など – 先日までソフトウェアのよろず品質コンサルタント • 専門分野 – ソフトウェアテスト／プロジェクトマネジメント ／ＱＡ／ソフトウェア品質／ＴＱＭ全般／教育 • 共訳書 – 実践ソフトウェア・エンジニアリング／日科技連出版 – 基本から学ぶソフトウェアテスト／日経ＢＰ – ソフトウェアテスト293の鉄則／日経ＢＰ • もろもろ – TEF: テスト技術者交流会 / ASTER: テスト技術振興協会 – WACATE: 若手テストエンジニア向けワークショップ – SESSAME: 組込みソフトウェア管理者技術者育成研究会 – SQiP: 日科技連ソフトウェア品質委員会 – 情報処理学会 ソフトウェア工学研究会 / SE教育委員会 – ISO/IEC JTC1/SC7/WG26（ISO/IEC29119 ソフトウェアテスト）TEF: Software Testing Engineer’s Forum
• ソフトウェアテスト技術者交流会
– 1998年9月に活動開始 » 現在1700名強の登録 » MLベースの議論と、たまの会合 – http://www.swtest.jp/forum.html – お金は無いけど熱意はあるテスト技術者を 無償で応援する集まり – 「基本から学ぶソフトウェアテスト」や 「ソフトウェアテスト293の鉄則」の翻訳も手がける » ほぼMLとWebをインフラとした珍しいオンライン翻訳チーム – 技術別部会や地域別勉強会が実施されている » プリンタ、Web、AVなど » 東京、関西、九州、東海、札幌などASTER: Association of Software Test EngineeRing
• ソフトウェアテスト技術振興協会
– テストを軸にして、ソフトウェア品質向上に関する教育や 調査研究、普及振興を行うNPO法人 » 2006年4月に設立／理事・会員は無給 – ソフトウェアテストシンポジウム（JaSST）を開催している » 実行委員は手弁当／参加費は実費＋α » 毎年4Qに東京で開催／今年はのべ約1500名の参加者 » 今年は大阪・四国・札幌・九州・東海でも開催／会場はほぼ満席 – ソフトウェアテストの資格試験（JSTQB）を運営している » Foundation Levelは10373名の受験者・5694名の合格者（54.9%） » Advanced Level（テストマネージャ）は189名の受験者・19名の合格者（10.1%) – 各地でソフトウェアテストの教育を行っている » テストのスキル標準（test.SSF）をIVIAと共同で開発している » 札幌や大分などでテストの教育の実績がある » 勉強会の開催などを支援することで、地場の産業振興の定着を図る – アジア各国とテスト技術の交流（ASTA）を行っている – テスト開発方法論などの先端技術を研究開発している：智美塾SESSAME: 組込みソフトの育成研究会
• 組込みソフトウェア技術者管理者育成研究会
– Society for Embedded Software Skill Acquisition for Managers and Engineers
– 2000年12月に活動開始 » 200名強の会員／MLベースの議論と、月イチの会合 – http://www.sessame.jp/
• 中級の技術者を10万人育てる
– ＰＣソフトウェアのような「そこそこ品質」ではダメ » 創造性型産業において米国に劣り、コスト競争型産業でアジアに負ける » ハードウェアとの協調という点で日本に勝機があるはず – 育成に必要なすべてを開発する – オープンプロダクト／ベストエフォート » 文献ポインタ集、知識体系（用語集）、初級者向けテキスト、スキル標準など » 7つのワークグループ：組込みMOT・演習・MISRA-C・ETSS・子供・高信頼性SQiP：Software Quality Profession
• 名称：
– 日本科学技術連盟・ソフトウェア品質委員会• 目的
– SQiPは、ソフトウェア品質技術・施策の調査・研究・教育を通じて、 実践的・実証的なソフトウェア品質方法論を確立・普及することにより、 ソフトウェア品質の継続的な向上を目指す• ３つの視点
– ソフトウェア品質・実践・普及啓蒙• 主軸とする活動
１．実践的・実証的なソフトウェア品質方法論の確立 ２．ソフトウェア品質方法論の普及促進・資格認定 ３．ソフトウェア品質向上のための国際協力の推進• 活動方針
１．ソフトウェア品質追究の重要性訴求 ２．日本での実践的・実証的ソフトウェア品質方法論の形式知化 ３．グローバルな視野での活動 ４．新しい課題へのチャレンジSafeware翻訳プロジェクト
• 2009年11月に翻訳版が刊行した
– Nancy Leveson（MIT）著 – 翻訳チーム：松原友夫・片平真史（JAXA）・吉岡律夫（日本機能安全） ・青木美津江（電気通信大学） ・西康晴（電気通信大学） – 翔泳社 発行 第1部 リスクの性質 第1章 近代社会におけるリスク 第2章 コンピュータとリスク 第3章 事故の階層的考察 第4章 事故の根本原因 第5章 ヒューマンエラーとリスク 第6章 自動化システムにおける人間の役割 第2部 システム安全への序論 第7章 システム安全の基礎 第8章 システム安全の基本 第3部 定義とモデル 第9章 用語 第10章 事故とヒューマンエラーモデル 第4部 セーフウェアプログラムの要素 第12章 システムとソフトウェア安全プロセス 第13章 ハザード分析 第14章 ハザード分析モデルと技法 第15章 ソフトウェアハザードと要求分析 第16章 安全性のための設計 第17章 ヒューマンマシンインタフェースの設計 第18章 安全性の検証 付録 付録A．医療機器：Therac-25の歴史 付録B．航空宇宙：アポロ13号、DC-10型機、 チャレンジャー号 付録C 化学産業：セベソ、フリックスボロー、ボパール 付録D 原子炉事故:ウィンズケール、訳者の思い
• 現代の日本で頻発・再発する
社会的責任の重いシステムのトラブルを
少しでも減らしたい
– 日本が世界一安全・安心なものを創れる国になって欲しい• システム安全という途方もなく広くて困難な分野を
手がける人を増やしたい
– システム的な広範な視野を持つエンジニアを増やしたい – 困っている人は多いのだが、集まる場も少ない• 日本における固有の問題が少しでも改善されて欲しい
– 再発防止よりも犯人捜し / 安全性と信頼性の混同 / 適当に作られた ソフトウェアといい加減な原因究明 / 根本原因を分析・理解せず 手っ取り早くノウハウだけを手に入れようとすること訳者の思い
• 本書はマニュアル本ではありませんし、
特定の方法論を宣伝する本でもありません
– 考え方や原理原則について豊富に紙面が割かれている – 多くの対策や技法が幅広く含まれている – 実際の事故の事例が収録されている – 難しいものは「難しい」ときちんと書かれている – 可能な限り原文と対比できるよう留意した » その分、少し読みにくいかもしれませんテーマ（エピローグ/p.494）
• 単純さとインテリジェンス
– 安全をより確かなものにする最も効果的な方法は、 単純であることと、知的に処理できるシステムを構築することである• 安全性と信頼性の適切な区別
– 安全性と信頼性は別のものであって、混同してはならない• 定量化に惑わされない
– 確率論的リスクアセスメントに依存しすぎるのは賢明ではない ※説明責任 or 説明無責任？• 後付けの機能安全よりも上流での本質安全
– システムに安全を組み込むことは、 完成した設計に防護装置を加えるよりも、はるかに効果的である – 安全が、開発プロセスのより早い段階で考慮されるほど、 より良い結果が得られるテーマ（エピローグ/p.494）
• 多層的で広範な事故の根本原因分析
– 進歩するためには、事故を単純化しすぎるのを止め、事故の、 柔軟で複数の要素がからんでいるという本質を認めなければならない – 根本原因に手を付けずに、症状だけを放置しても、 事故の再発はほとんど防げない – 問題の数少ない側面だけに集中しても、望ましい効果は得られない – 特に、技術的問題にだけ注目して、管理上や組織上の欠陥を無視 したのでは、有効な安全プログラムは得られない• 責任を人間に押しつけても進歩しない
– 単に人間をコンピュータに置き換えても安全問題は解決しない ※オペレータに関する記述の多くは、 （自分よりも下流の）開発者にも当てはまる – 人間の「エラー」は人間の柔軟性と創造性に不可避に結びついている – 人間をコンピュータに置き換えるのではなく、むしろコンピュータを 用いて人間の能力を増強する方法に取り組むべきであるテーマ（エピローグ/p.494）
• 安全性は皆の問題
– 安全はシステムの問題であるので、異なる分野の専門家が 協同して働くことによってのみ解決することができる » 技術部門だけでなく、教育／人事部門や営業部門、財務部門もありうる – 特にソフトウェアは、システムの他の部分から孤立していては、 効率よく開発できない – ソフトウェア技術者は、システム安全の概念と技法を 理解しなければならない – 同時に、システム安全担当者は、より深くソフトウェア開発にかかわり、 システム安全のプロセスにソフトを取り込むようにしなければならない• ソフトウェア安全という概念は無い
– そのソフトウェアが動作するシステムという状況の中でのみ、 ソフトウェアの安全性を評価することができ – ソフトウェアを単独で見るだけでは 一片のソフトウェアの安全性も評価できないテーマ（エピローグ/p.494）
• 自己満足が最も危険
– 自己満足はおそらくシステムで最も重要なリスク要因であり、 それを最小にする安全文化が確立されなければならない ※居駒の同値原理：同じだ／同じはずだ／同じにしちゃおう• ハザード分析でリスクを明らかにすることが重要
– 事故につながる事象が予測できないからといって、 事故が予防できないということにはならない – ハザードは、通常分かっていて、しばしば、除去され、かなり低減される – 必要な機能性や費用の低さのような、他の目標とのトレードオフが 最も少ないために、（ハザードよりも）先行する事象を除去しようとする 決定がしばしば下される – 複雑な決定は科学を超越したものである – しかし、技術者には、上位の意志決定者のためにリスクを明らかにし、 自己満足または他の要因、または圧力が、意志決定において 当然の考慮されるべき工学上の問題または リスクを妨害しないようにする義務がある。テーマ（エピローグ/p.494）
われわれは
同じ過ちを繰り返さないよう、
過去から学ばなければならない
ソフトウェアの神話（2.2/p.26）
• 神話２
– ソフトウェアは簡単に変更できる• 神話４
– ソフトウェアの信頼性が高まれば、安全性も高まる• 神話５
– ソフトウェアを試験すること、 または形式的手法による検証技法を用いて ソフトウェアが正しいものであると「証明」することで、 すべてのエラーが除去できる ※上流を完璧に遂行すれば試験は確認にすぎない、 という思考も同じくらい危険である• 神話６
– ソフトウェアを再利用すれば安全性が高まる事故原因の階層モデル（3.4/p.49）
• レベル３：制約
– ある種の強制力となる制約 » 技術的および物理的条件、 社会力学と人間の行動、 管理システムと組織文化、 行政上や社会経済上の方針など• レベル２：条件
– 事象が発生しうる条件 » 自動車にはABSが搭載されていない、スピード超過、 雨で路面が濡れている、シートベルトをしていないなど• レベル１：事故発生メカニズム
– 事故発生のメカニズム・事象の連鎖 » 運転手がブレーキを踏んだ→自動車が横滑りして木にぶつかった →運転手が車外に投げ出されて負傷した事故の根本原因（4/p.53）
• 安全文化の欠陥
– 自信過剰と自己満足、安全への低い優先順位、 矛盾する目標への誤った解決 » リスクの過小評価、冗長性への過信、非現実的なリスクアセスメント、 低確率で過酷な事象の無視、無事故によるリスクの経年減少の仮定、 ソフトウェア関連リスクの過小評価、早期の警報や兆候の無視 ※重厚長大化、形骸化、官僚化、ドキュメント至上主義化、Ｎ施策化• 効果的でない組織構造
– 責任と権限の分散、独立性の欠如と安全担当部門の低い地位、 限定された情報伝達経路と貧困な情報の流れ ※マネジメントレベルが如実にものを言う• 効果的でない技術活動
– 表面的な安全活動、有効でないリスク制御、変更に対する評価の失敗、 情報の不足 » 根本的な設計欠陥の除去失敗、誤った仮定に基づいた安全対策、ハインリッヒの法則（7.1/p.131）
• 重傷１件
• 軽傷２９件
• ヒヤリハット３００件
• ニアミス数千件
ヒヤリハットを
（ヒヤリハットとして）
分析していますか？
数千
３００
２９ １セーフウェアプログラムの主な要素（第４部/p.217）
• 経営陣のコミットメント
• 安全方針の設定と目標の定義
• 責任、説明責任、および権限の定義
• 情報伝達経路の確立
• システム安全組織の設立
• ドキュメントの定義・安全情報システムの構築
• システム安全プログラム計画の策定
• ハザード分析
• システムの開発と安全性の組込み
• 安全性解析
• 試験・安全に関連する情報のまとめと保守・運用
ハザード分析プロセスのステップ（13.1.5/p283）
1. 目的の定義 2. 適用範囲の定義 3. 分析で使われる、システム、 システム境界、 および情報の定義と記述 4. ハザードの識別 5. データ収集（過去のデータ、 関連する規格および実施規定、 科学的な試験と実験結果など） 6. ハザードの潜在的影響（速効性 または遅延性）および、可能なら それらの起こりやすさ（定性的 または定量的）に基づく ハザードの定性的ランキング 7. 原因因子の識別 8. 予防措置あるいは是正措置と、 全般的な設計基準と 制御機器の識別 9. 費用の見積もりを含めた予防措置 あるいは是正措置の評価 10. 制御が正しく実行され 効果的であることの検証 11. 発生確率、経済的影響、 潜在的損失、および予防措置 あるいは是正措置の費用を含む、 選択された未解決ハザードの定量化 12. 残存リスクの定量化 13. 運用経験のフィードバックおよび評価ハザード分析モデルと技法（14/p.302）
• チェックリスト
• ハザード指数
• フォールトツリー解析（ＦＴＡ）
• ＭＯＲＴ解析
• イベントツリー解析（ＥＴＡ）
• 原因結果解析（ＣＣＡ）
• ＨＡＺＯＰ
• インタフェース分析
• 故障モード影響解析（ＦＭＥＡ）
• 障害ハザード分析
• 状態機械ハザード分析
ソフトウェア向けのガイドワードの例
頻度 範囲 設定 遅く 早く タイミング 遅い 速い 速度 あとで さきに 順序 ゼロ ない ある 限界 切り替え 挿入 不足 低い 下へ 切り離し 少なく たまに 低く 少なく 少なく 狭く 反復 遅く 並行に 短く 狭く 短く 遅く 超過 高い 上へ つなぐ 多く いつも 高く 多く 多く 広く 逆転 早く 同時に 長く 広く 長く 早く 負荷 方向 接続 回数 程度 頻度 拡張 期間 間隔 時間 時期 短い 長い 任意 必須 禁止 許容 急 緩 低速 高速 近い 遠い 距離 小さい 大きい 規模 小種 多種 種類 不足 余分 減少 増加 少ない 多い 数量 弱い 強い 強度 少ない 多い 最小限 最大限 低い 高い 狭い 広い 下限 上限 鈴木三紀夫さん（TIS）、ソフトウェア向けのガイドワードの例
代替 例外 通常 一部 全部 緊急時 非常時 平時 有事 無事 常例 準正常 特異 特殊 特別 非常 可変 異例 臨時 非通常 異常 並 普通 一般 尋常 定常 通例 定期 通常 正常 停止 起動 無効 有効 未完 完了 主要 詳細 基本 強制 任意 不正 公正 誤 正 従 主 部分 全体 例外 原則 鈴木三紀夫さん（TIS）、 秋山浩一さん （富士ゼロックス）システム安全の基本概念（8.2/p.146）
• 完成した設計に安全を加えるのではなく、
設計に安全を組み込むことを重視する
– 完成した設計に安全を加えるというアプローチは不具合を生みやすい ※機能安全よりも本質安全を目指す• サブシステムや構成要素としてではなく、
全体としてシステムを扱う
• ハザードを、単なる故障よりも広い意味で捉える
– 故障を防ぐ（信頼性を高める）のと、ハザードを防ぐ（安全性を高める）の とでは工学的手法は異なるし、時として互いに矛盾する。• 過去の経験や規格よりも、分析を重視する
– 事故が起こる前に、事故または事故に近い事態を予測し、防ごうとする ※過去の経験や規格を十二分に活かせる素地が無ければ 分析は机上の空論となるシステム安全の基本概念（8.2/p.146）
• 重視されるのは、定量的手法よりも定性的手法である
– 数値的な評価は、通常、暗黙の非現実的な仮定に基づいてなされる ※盲目的な定量化よりも、経験豊富で真摯な技術者による 技術の中身を理解した主観的判断の方が適切である：故障モードやDRBFM• システム設計におけるトレードオフと対立を重視する
– 絶対安全というものはなく、…めったに主な目標にもならない – リスク管理のトレードオフに関する、 意志決定のための情報提供に重点を置いている• システム安全は単なるシステム工学以上のものである
– システム安全の関心事は、政治的社会的なプロセス、管理者の興味や 態度、設計者や操作者の態度や動機、ヒューマンファクターと認知心理学、 事故調査における法律制度や情報の自由な交換の影響、 安全にかかわる従業員とシステムに対する認証と免許や許認可、 および世論などを含むところまで…広がっている安全のための設計（8.2/p.149）
１）ハザードの除去（本質安全）
– 置換／単純化／分離／特定のヒューマンエラーの除去 ／ハザードをもたらす物質または条件の低減 - ハザードの除去（16.3/p.387） ※ソフトウェア設計における責務の分割の問題だったりする２）ハザードの低減
– ロックアウト／ロックイン／インターロック - 防護壁（16.4.2/p.405） – 安全係数と安全マージン／冗長性／回復 ※冗長性は、単に異なる２つの部隊で開発すればいいというものではない - 故障の最小化（16.4.3/p.414）３）ハザードの制御
– 曝露の低減、隔離と封じ込め、防護システムとフェイルセーフ設計 » 受動的な制御対策は最も効果的で、能動的な制御装置はあまり望ましくない４）損失の低減
富士通の７つの設計原理
①単純原理
- 可能な限りシンプルにすること②同型原理
- 同じものは同じように実現すること - 例外を設けないこと③対称原理
- 対称にすること - 対になるものは対にすること④階層原理
- 階層関係、主従関係、前後関係、 本末関係などを崩さないこと⑤線形原理
- 特異点や閾値、組み合わせによる 特殊な振る舞いが無いこと⑥明証原理
- ロジックは直感的に 分かりやすくすること⑦安全原理
- 必然性のないところや 曖昧なところは安全サイドに 設計しておくこと要求分析のための完全性基準（15.4/p.350）
• 内部モデルと実際のモデルとのミスマッチを起こさない
– 安全な状態に（複数の経路で）行き来できなくてはいけない » 安全状態、初期化・状態、インターロック、縮退運転からの復帰、キャンセル• あらゆる場合で（不確定な場合でも）ふるまいを
明示的に決定できなくてはいけない
– その他、条件の逆、過剰な入力（想定以上の負荷）、不測の事態 » 有効期限、タイムアウト、デフォルト（キャンセル）• 防護策が無ければ、
ハザードをもたらさないようにしなくてはいけない
– 不可能なら、頻度および持続期間を削減する要求分析のための完全性基準（15.4/p.350）
• 分からないものがあってはならない
– 使われないセンサー、生成されえない正当な出力値、 オフライン時の入力 » 最小・最大（の負荷）、レイテンシ、プリエンプション• おかしなものを受け取らない、先に送らない、
無視しない、勝手に処理しない
– 異常入出力のマスク、ダウンしている経路の問い合わせ、 オペレータへの過負荷状態の通知、 オペレータからの確認応答の確認、フィードバック• バランスを崩してはいけない
– 出力頻度以上の入力頻度 – 出力に対するキャンセル訳者の思い
• 現代の日本で頻発・再発する
社会的責任の重いシステムのトラブルを
少しでも減らしたい
– 日本が世界一安全・安心なものを創れる国になって欲しい• システム安全という途方もなく広くて困難な分野を
手がける人を増やしたい
– システム的な広範な視野を持つエンジニアを増やしたい – 困っている人は多いのだが、集まる場も少ない• 日本における固有の問題が少しでも改善されて欲しい
– 再発防止よりも犯人捜し / 安全性と信頼性の混同 / 適当に作られた ソフトウェアといい加減な原因究明 / 根本原因を分析・理解せず 手っ取り早くノウハウだけを手に入れようとすることご清聴ありがとうございました
電気通信大学 西 康晴 nishi@se.uec.ac.jp
