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