誘導語の対称性を利用し 一人HAZOPを組み合わせた 効率的な安全分析作業
想定外をなくすためのHAZOPのすすめ
名古屋市工業研究所 小川清,斉藤直希,渡部謹二
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
概要 • 背景
• 1,想定外をなくす
• 2.HAZOPの展開 • 視点の違い • 図の利用 • 設計指針の利用 • 一人HAZOP
• まとめ • 付録1 物事への適用例 • 付録2 進め方の例
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
背景 " JAXAの安全分析,形式手法などの取り組み
" 利用者視点での分析 " 設計の最初の段階 " 利用者(顧客)と設計者の情報交換を円滑に
" 安全関連系の設計の体系化をどう図るか " 設計者と利用者の両方の参加 " 図,言語,数式の変換 " 何処まで,いつまで分析するかの終了判断
" 名古屋市工業研究所 " 名古屋地区の公的試験研究機関 " 他の組織が実施していないことに挑戦
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
課題
" 分析をしたことがないソフトウェア技術者
" 初期段階は分析と設計は一体の行動 " 分析しながら設計 " 設計しながら分析
" 最終利用段階の制約条件,試験条件を知らない
" 最終製品の仕様,制約条件(初期条件,境界条件など)が不明
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
プロセス改善ナビゲーションガイド ベストプラクティス編
• 改善10事例
• JAXAの独立検証(IV&V)がその1つ • IEC61508関連取り組み • 形式手法 • 試験方法 • 分析方法
• HAZOPを検証系で利用
• IPA/SEC www.ipa.go.jp ダウンロード可能
• 委員:JAXA,トヨタ自動車,デンソー,アドヴィックス/アイシン精機,日本電気,三菱電機,新日鉄ソリューションズ,マイクロソフト,ブラザー工業,情報数理研究所,日新システムズ,大和コンピュータ,富士ゼロックス,アイエックスナレッジ,NTTデータ,住友電気工業,HBA,コンピータジャパン,同志社大学,PM Academy,砂塚コンサルティングサービス,松原友夫,名古屋市工業研究所
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
HAZOP
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
" Hazard Analysis and Operability Study(障害分析と運用研究) " 誘導語を使って設計意図,利用意図からの外れ(逸脱)を洗い出す
" 図を使うことに価値がある。 " 消費者を始めとして利害関係者が参画 " 流れに着目
" 電流,信号・情報の流れ。
" FTA, FMEAは製造現場では普及 " FTA,FMEでは見つからないものを見つける
" JAXAでは特定の工程で実施している " FTA, FMEAと同様の使い方ができるのでは。
誘導語における対称性
" 無(no)は存在していることに対する反対(対称)
" 逆(reverse)は方向が反対(対称)
" 量(quantity), 質(quality), 時間(time), 順番(order) " 大(more)小(less),類(as well as)部(part of),早
(early)遅(late),前(before)後(after)
" 発想しにくい概念 " その他(other than)だけ対称な概念でない。 " 質は単位系を利用する。
" 質の増大は創造的(無理しない。 " 時間なら同時
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
1. 想定外をなくす
" HAZOPの設計の初期段階の焦点
" 説明責任として「想定外でした」ということがないよう.
" ありえないことを想定して考え「外れ」として記録. " ありえないことを誘導語を使って記述する " ありえないこと言ってみると,それよりはありえることは考えてよいことが分かる
" ありえないことに対応してあると,ありえることにも対応できることがある
" 例題として昇降機の扉
1
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
事例:昇降機の扉 " 昇降機の扉に各種検出機能の仕様を検討中
" 昇降機扉に誘導語を適用 " 1階の扉の外にいる利用者 " 上行きだけで,ボタンは上だけ " 到着を示すランプあり
" 外れ(想定外)を列挙
" 原因,予防/検出方法,対策を思いついたら記録しておく
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
外れ(逸脱)の見つけ方
• 流れでなく,ものから始めてみる – 流れの分析でものの分析と混ざることがある – ものの分析を先にしておけば,流れの分析で焦点が絞れる – 物と事がうまく分離できるとは限らない(付録1参照)
• 作業(行動)を書いててみる。 • 書いたことに誘導語をあてはめてみる。
• 誘導語の対称性に着目する • 外れの対称性,対策の対称性 • 前後(before/after)と質(as well as)がやや難解
• 単位系を利用する • その単位に該当する物事がないか。
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
なぜ(原因:cause)
" 思いつくことをひとまずあげる " 本当にそうかどうかは模擬試験,実験などによる " 外れの対称性に注目した原因の検討 " 原因の対称性に基づいた外れの想定
" 1つの外れに複数の原因があることもある " 原因ごとにどうするか(対策)を考える
" 1つの事が,複数の外れの原因になっていることがある " 作業表上は事ごとに同じ原因も入れる
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
どうする(対策)
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
" 予防 " 対称性に着目
" 発生原因の初期条件を除去 " 発生原因の境界条件を除去
" 人と危険源を隔離
" 事後(中)対策 " 被害の度合を小さくする " 被害の回数を減らす " 人を防御する装置を付加
前後(before/after) " 同時に起きるて欲しいことは,前と後の両方を考えることができる。
" 2つの事象が逆転したのなら,前か後かだけで考えることもできる
" 前にあるべきものが後になったのか,後にあるべきものが前になったのかの原因で2つに区分することもある
" 視点の違いとして,どちらも記載して,対策をそれぞれ別に立てる
" Early/lateとは検出/検証方法(形式検証等)が異なる場合があるので別に分類
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
質(As well as/Part of)
" 時刻で,同時に起こらないとよいことが同時に起こったらas well as。
" 時間で期間対応が一部分だけならearly,lateで分類するよりPart of
" 例:「週末を除く」
" 単位系について優先順位を考える。 " 機械系なら,力,圧力,エネルギー(振動,騒音)など
" 電子系なら,熱,電磁波など " 光学系なら,明るさ,
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
2.HAZOPの展開
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
" 視点の違い
" 図(写真)の利用 " 視点の違いによって見え方が違うことを理解しやすい " 単純化(モデル) " 利用者の理解
" 設計指針の利用
" 一人HAZOP
2.1 視点の違い 視点1ではBはAの部分集合,緑色はB
視点2ではAはBの部分集合,緑色はA
誤解:自分は正しく相手が間違い
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
ずれ
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
• 視点1,視点2から見える部分集合と,横から見ている部分集合との間にはずれが生じる
• 物理的には屈折率などさらに複雑
• 論理<幾何<物理(複雑度)
視点の違いの対策
" 類語辞書の作成 " 概念の上下関係(is-a, a-si) " 所有関係(has-a) " 利用関係(use-a)
" 言い換え " 同義語 " 大和言葉,漢語,カタカナ語 " 略号のフルスペル
" 相互に見えないものの確認
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
2.2 図の利用 " 利用者が分かる図にする
" 現物がない場合
" 図による設計 " 概念の包含関係 " 階層構造化 " 関係の明確化 " 時間,順番の明確化
" 図と言語の往復による成熟 " 数式(形式検証)との間も利用 " UMLの道具で書く(道具た対応)
" 設計,仕様の一部としても使う。 " 状態遷移はすべて書く。 " 時系列は順序に関して。 " 刻時図は時刻,同時に集中。
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
利用者が分かる図を書く
" 利用者が見えるところを図にする " UMLでは利用事例図(use case chart)
" 利用者が気が付いていないかもしれないことを1つ足してみる
" 利用時の品質(quality in use)を参考にする " B: 利用時の要件(requirements): 検証
(Verification) " A: 意図した利用(intended use):妥当性確認(Validation)
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
2.3 設計指針の利用
" ユニバーサルデザイン(万能設計)
" 形の設計指針
" 論理設計 " STARC RTL設計スタイルガイド(HDL/ASIC, FPGA) " MISRA-C/C++(プログラミング言語/CPU)
" 対称性を軸に設計指針を分類して活用
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
2.4 一人HAZOP 誘導語と図を見ながらありえないことを「外れ」に列記すると思わぬことに気が付くことがある 人に言うのは恥ずかしい事でも,自分で妄想するだけならいろいろ考えられる 最初に自分が考えたことが全体の表の中で残って行ったり,統合されていくことにより,全体の分析について理解が進む 責任を持って作業をする訓練になる 利用者視点は設計能力が高くなくても担当できる 誘導語と図を見ながらありえないことを「外れ」に列記する
紙でやっていて欄が足りなけれ足す ありえないことでもよい 思いついたことは必ず書く 経験に基づいても,妄想に基づいてもどちらでもよい 事について記述してから,物について記述する 事前,事後(初期条件,境界条件)を記述する 3つの設計指針を使う
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
分析をどこまでやるか
• すべての誘導語に対する外れを書き出す • 原因と対策は一つずつ
• 思いついていない外れを1つ見つける • 対称性に目をつける
• 一人HAZOPを2時間やる • 試験・検証項目を網羅的に出す
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
HAZOPのまとめ " 初期段階は想定外をなくすのに集中
" 既存の設計指針を3つ以上使う
" 誘導語を減らすのではなく,埋めてみる努力をしてみる
" 対称性に着目し,対称でないところに鍵が存在
" 数式などで検証できるような仕様をめざす
" 過去の失敗事例は整理しておく
" 図を有効活用する
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
全体のまとめ • 初期段階では予想していない想定外が一つでも出れば成功
• 昇降機の場合は,出入り口が床にある場合 • 信号機の場合は,台風などで横に向いた場合
• 視点の違いの確認 • 図の利用
• 状態遷移図,時系列図,刻時図を使うと有効
• 分析結果から検証,試験事例を作成 • 複数の手法を使う
• FMEAをやってから,HAZOP • 設計者を中心にFTAを作る • HAZOPで出た課題を形式手法で検証
• 見るとやるとで大違い • ものを分析してから事を分析した方が混じることが少なくなる • 最初は網羅性を高めることより,枠を埋めて出発点を作る。 • 外れを考えることにより,制約条件,初期条件などを洗い出す
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
今後の課題 • システム設計規模による作業量の見積もり • システムの過渡現象への対応 • 事前分析の徹底と事後分析の組み合わせ
• 設計審査(Design Review),故障,安全分析(FMEA,FTA),なぜなぜ分析,4M5Eなどとの
効率的な組合せ
• モデル(状態遷移等の設計)に基づく検証 • モデル記述(MATLAB, UML, XML),形式記述による検証(Z, VDM, SPIN, Event-B, UPPAAL, Alloy, CSP, Coq)
• 設計,分析,検証・試験を同時進行する場合に対応
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
参考文献 • Safeware, Nancy,翔永社, 2009 • HAZOP and HAZAN, Trevor A. Kletz ,1983 • 5ゲン主義入門,古畑 友三,日科技連出版社 ,1996 • 4M5E http://www.n-iinet.ne.jp/4m5e.htm • FMEA,FTA実施法,鈴木順二郎,日科技連,1982 • もの・こと・ことば,廣松渉,筑摩書房, 2007 • なぜなぜ分析徹底活用術,小倉仁志,JIPMソリューション, 1997 • MISRA-C解説書,SESSAME/MISRA-C研究会日本規格協会,2004/2006 • RTL設計スタイルガイド Verilog-HDL編,VHDL編, STARC, 2003/2006 • 組込みシステム開発事例集,産業技術連携推進会議情報電子部会組込み技術研究会 ,工業調査会, 2006
• プロセス改善ナビゲーションガイドベストプラクティス編,IPA/SEC, オーム社,2008 • デジタル設計工学の基礎の検討,小川清,第6回ディペンダブルシステムシンポジウム,産業技術総合研究所システム検証研究センター,2009
• 関連資料 http://i-chi.ne.jp/blog/?key=21516 hazopブログ • ESC: http://www.esc-jpromo-activesafety.com/
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
謝辞
" 本研究は,(株)日本機能安全のご指導に基づいています。
" 名古屋大学,産業総合研究所,北海道立工業試験場,(株)ヴィッツ,東海ソフト(株),(株)サニー技研はじめ,機能安全対応車載プラットフォーム開発参加の皆様のご協力に基づいています。
" 資料作成は,(株)セブンワイズの方に
協力いただいています。
" 200名を超える各種HAZOP関連セミナ
参加の皆様に感謝します。
" 写真: Canon EOS Kiss X2 by O.M.
" twitter@kaizen_nagoya, #wocs2011
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
付録1 物(もの)事(こと)への適用例
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
本発表への期待,資料(もの),発表(こと),成果へのHAZOPの実施 • 人:主催者,発表者,参加者 • 物事:期待,資料,発表,成果
付録2. 進め方の例
• 参加者の能力が分からないとき,作業の1回目は前提を設けずに,自由に発想する。
• 参加者の能力を見極め,お互いに気がつかないところを探す。
• 考え方,意見は否定せずに記録する。
• 間違いにきがついたら,消さないで,横棒で見えるように消す。
• 事前準備は重要 • 演習などを実施するとよい
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
HAZOP演習例
HAZOPの概要説明 10分
一人HAZOP 20分
班活動 座長と記録担当5分 自己紹介 5分 順番に統合 35分
分類 追加事項を加える
ふりかえりと報告 15分(5グループの場合)
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
HAZOPの手順
• 準備作業としての一人HAZOP
• 役割の確認 – 座長,記録担当,開発側,利用側,安全の専門家
• 検討対象の記述(事前作業) – 利用事例図,時系列図,状態遷移図,を書く(補足する)
• 事項(処理変数)の洗い出し
• 現象(誘導語)の特定
• 繰り返し
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
事前準備
• 一人HAZOPを全員に実施する – 参加者の能力,経験の把握
– 無駄作業の排除
• システムへの要求,必要な制約条件を出す – 具体的な処理内容を特定
• うまくいく処理方法と,うまくいかない処理方法を区分する
• 結果 – 妥当な要求であることを確認できる(分析) – 妥当な設計であることを確認できる(設計) – 試験事例(test case)を出す(評価)
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
実践作業
" グループに分かれる(作業表を電子または紙で配布) " 座長と記録担当を決める
" 課題の図を一つ書く " 入出力,状態を考える " 想定外の事を考える " 測定,試験方法を考える " 防御方法,対策を考える " 頻度/致命度を考える
" ふりかえり 5分 " よかっことを一つづつ言う
" 分析結果でよかったこと " 作業で気が付いたことなど
" 報告 15分(1班3分から5分) " 分析結果で自分が思いつかなかった事 " 作業で普段気が付かなかった事 " ふりかえりの紹介 " その他なんでも時間内ならOK
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
作業原則
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
" 書いたことは消さない " 後で分類を変えることはあるが無駄ではない " 勘違いだった場合もどういう勘違いかを記録 " 利用者の発言を設計者が否定しない " 分類を変えるだけでよいのでは?
" 一つの誘導語を深堀してもいいし,まんべんなくせめてもよい
" 外れは必ず書く " なし,原因だけ,検出方法だけ,対策だけなどの部分だけの記載でよい
" 設計にない事項は仕様を追加してもよい " 右の方の欄に<仕様追加>として記載
班HAZOP " 一人HAZOPの結果を順次確認 " 時間内に全部を確認することを優先 " 分からないところを聞く
" 誘導語の分類を変えてもよい " 同一のもの,類似のものを分類
" 表現が少しでも違えば残す " 事象が分析対象外の場合は何の分析に有用かを記録
" 出た発言は消さない. " 議論の途中で思いついたことは発言し記録 " 内容が分らなかったり,調査が必要なことは担当者名を記載
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp
外れの再分類
• 論理が飛躍していることがある – 原因から結論に論理が飛躍していると気がついた場合は,間の論理を追記する
• 原因と結果が逆転していることがある – 誰の視点で見ているかを補足するとよいかもしれない
• 原因と対策が逆転していることがある – 考え方と実現方法を分けて書いたほうがよいかもしれない
• 人間に関する事項(たとえば教育)は,複雑に原因が入り組んでいる – 人間に関する事項は一見,同じ原因にたどり着くことがある。 – 対応策の十分性を考える際に,他に原因があることを確認するとよい
20110118 ogawa.kiyoshi(saito.naoki,watabe.kinji)@nmiri.city.nagoya.jp