Hazop anzen21013
•Télécharger en tant que PPTX, PDF•
2 j'aime•1,369 vues
safety engineering symposium 2013 at Tokyo, 2013.7.4
Recommandé
Contenu connexe
En vedette
Similaire à Hazop anzen21013
Similaire à Hazop anzen21013 (20)
Plus de Kiyoshi Ogawa
Plus de Kiyoshi Ogawa (20)
Dernier
Dernier (8)
Hazop anzen21013
- 2. 2013年7月7日 2
- 3. 自動車の安全（愛知県は交通事故死日本1） 道路安全 衝突防止 機械・電気・ソフトウェアの連携 電気・ソフトウェア連携は機能安全規格が一部対応 機械・電気の設計を ISO 26262の審議 ISO/IEC JTC1 SC7からの国際のリエゾンとして参加 Automotive SPICEの基となるISO/IEC 15504 part2,6,9エディタ。 修整(tailoring)の必要性とHAZOPの大切さに JAXAの取り組み プロセス改善ナビゲーションガイドbest practice編
- 4. • 10 case studies. • JAXA(IV&V) • IEC61508 • Mathematical Method(formal) • Test Method • Analysis Method • FTA, FMEA and HAZOP • IPA/SEC www.ipa.go.jp downloadable by registrating Email address • Members：JAXA,Denso, Toyota, …. 2013年7月7日 4
- 6. FTA, FMEA, HAZOPの組み合わせ FTA FMEA HAZOP HAZOP HAZOP FTAは最上位事象 を起こさないよう な論理を検討。 HAZOPは上から、 下から、真ん中か らのいずれでも可。 FMEAは部品 （下）から故障 モードを洗い出す。
- 7. FMEA, FTAは設計の基本情報に依存 想定外をなくすためのHAZOPは設計情報 がない状態で始められる システムのいくつかの制約条件 システムのいくつかの機能 検討事例：津波対策、原子力発電所事故
- 9. FTA 結果（トップ事象）ｰ>原因（複数の基本 事象） ETA 原因（ある基本事象）ｰ>結果（トップ事 象） 図の妥当性確認のためにHAZOPの誘導語を適 用 早遅・前後・大小・無逆・部類などを確かめる 不備、誤り、不徹底、注意不足、ミスなどの抽象的 な言葉を、より具体的にする
- 11. ユニバーサルデザイン （万能設計） 形の設計指針 論理設計 STARC RTL設計スタイ ルガイド(HDL) MISRA-C/C++(プログラ ミング言語) 2013年7月7日 ogawa.kiyoshi(saito.naoki,watabe.kinji) @nmiri.city.nagoya.jp 11
- 14. ソフトウェア構成要素ごとのFMEA 言語: C言語（ライブラリを含む） OS: OSEK（モニタ、デバッガを含む） 通信規約：CAN 診断(diag) 応用(application)
- 15. ヨーロッパの自動車向けソフト ウェアに関する協議団体が作成 「Safer C」で指摘のあったC言語 規格の未定義、未規定、実装定義 などの移植（シミュレータと実 機）による振る舞いが異なるプロ グラムを回避 可読性、保守性などの問題となる 事項を「Cプログラミングの落とし 穴」などを参考に抽出 命名規則、タブなどの書式は含ま ない
- 16. K&R（デファクト）C言語の作者の文書 アメリカ規格（デジュール） ANSI X. 1989(C89):1999版からISO/IECの標準制定 と同時進行 国際規格:フリースタングィング環境(main無可)，ホ スト環境（main引数有） ISO/IEC 9899:1990(C90=ANSI C89), Ratinaleあり ISO/IEC 9899:1999(C99),Ratinaleあり ISO/IEC 9899:2011(C2011) 国内規格 JIS X 3010:1993(C90), JIS X 3010：2004(C99) www.jisc.go.jpで無償で閲覧可 2013/7/7 (c)kaizen@wh.commufa.jp, @kaizen_nagoya 16
- 17. 1.既存のコードを救うことが重要であり、既存の処理系を保護することは、重 要視しない。 2.可搬性のある原始プログラムが書けるようにする。 (高級アセンブラ的な使 い方による）可搬性がないプログラムを禁止してはならない。 3.(既存の仕様からの）暗黙の意味変更（quiet change)は極力避ける 4.規格は処理系の作成者とプログラマとの間の約束事を記述するものである。 5. 次のCの精神を遵守する. 1. プログラマを信頼する 2. プログラマが必要である事項を行うことを妨げない 3. 言語は小さく、コンパクトに保つ 4. 一つのオペレーティングシステムには唯一の方法を割り当てる たとえ可搬性が保障されない方法であったとしても、実行効率を上げる余地を 残しておく。 2013/7/7 (c)kaizen@wh.commufa.jp, @kaizen_nagoya 17
- 18. 3.4.3 undefined behavior: behavior, upon use of a non portable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). EXAMPLE An example of undefined behavior is the behavior on integer overflow. 3.4.4 unspecified behavior: use of an unspecified value, or other behavior where this International Standard provides two or more possibilities and imposes no further requirements on which is chosen in any Instance EXAMPLE An example of unspecified behavior is the order in which the arguments to a function are evaluated. 2013/7/7 (c)kaizen@wh.commufa.jp, @kaizen_nagoya 18
- 19. 工程FMEAと部品FMEAに分類 規則：Dir4.2 All usage of assembly language should be documented 工程:文書化していないアセンブラコードがある 影響：振る舞いの異なるCPUで動作がわからない Dir4.7 R If a function returns error information, then that error information shall be tested 製品：エラー情報を試験していない 影響：エラー情報に基づいた処理になっていない可 能性があり動作が保証できない
- 20. Dir4.9 A function should be used in preference to a function-like macro where they are interchangeable 工程:函数と思って使う間違う 影響：設計者の意図と異なる値を返す 対策：函数に書き換えて比較評価する 部品：ホワイトボックステストを書きに くい 影響： 対策：函数に書き換えて比較評価する
- 21. #include <stdio.h> #define absm(x) x>=0?x:-x intmain(intargc, constchar * argv[]){ inta=1, b=2; printf("%dn",absm(a-b)); return0; } 結果-3 2013/7/7 (c)kaizen@wh.commufa.jp, @kaizen_nagoya 21
- 22. ソフトウェアFMEAの故障モードを誘導語 付きブレインストーミングとして集計 設計指針で考えられる故障モードの具体 化、詳細化 MISRA-Cで検討した故障モードのNo, Reverse, other than, more, less, as well as, part of, early, late, before, after
- 23. The validity of values passed to library functions shall be checked no 値がない reverse 引数の並びが逆 引数の値が逆（0と1） 引数の値が上位と下位が逆(big endian とlittle endian) othher than 引数の順番がずれている 引数の型が違う 割り算で使う値に0が入っている more 上限値より大きい 16bitの値に32bitの値を渡そうとしてい る 下限値より小さい
- 25. MISRA-C 2012が, ISO/IEC 9899:1999年版 と1990年版に両対応して新規出荷 解説の検討と事例の確認に合わせて、ソ フトウェアFMEAとして展開 故障モードの詳細化のためにHAZOPを利 用 他の設計指針も同様に展開
- 26. HAZOP手法と安全分析全体の効果的な展開を図っ てきた 設計指針とFMEA, HAZOPの組み合わせを検討し た MISRA-CをソフトウェアFMEAの故障モード抽出に用 いた 規則を工程FMEAと製品FMEAに分類した 一つの規則が工程と製品の両方に展開できるものがあること が分かった 故障モード抽出の詳細化にHAZOPを利用した 他の設計指針も同程度に詳細化中 http://researchmap.jp/kaizen/HAZOP(は ぞっぷ)