********************************************************************** セッション S23-d ワーク テーマ:実践! 機能安全 ~Safety Conceptを作ろう!~ コーディネータ:高野 裕之さん(東芝セミコンダクター&ストレージ社)、        武井 千春さん(名古屋大学 NCES)、        森川 聡久さん(ヴィッツ) 日時:2011/08/31 9:00 〜 12:00 参加人数:12名 ********************************************************************** (議事録本文) -9:00 講義開始- ◆会場の雰囲気 6-8人掛けのテーブルが8つほど並んでおり、4人が一組となって座る。 各テーブルには付箋とマジックペンが用意されている。 最終的に参加者12人と少人数のセッションとなった。 しかしながら、グループワーク中は参加者全員が模造紙を囲んでグループワークに積極的に取り組み、意見交換は活発なものとなった。 ◆タイムテーブル 9:00-9:10 イントロダクション、グループ分け 9:10-9:40 座学      Safety Conceptの構築方法について      例題システムの説明      グループワークの進行方法について 9:40-11:20 グループワーク 11:20-11:50 成果発表 11:50-12:00 セッションまとめ ◆セッションの目的・概要 目的: Safety Concept構築のためのエッセンスを取得する。 概要: 数人のグループでブレインストーミング 問題を列挙、解決しつつ、コストや可用性などの実製品に必要なほかの点も考慮する -発表:森川さん- ◆機能安全について 参加者がどの程度の認識を持っているか、挙手をお願いします 機能安全を実践されている方  3人 知識はあるがやったことのない方  6人 言葉を知ってる方  4人 ◆Safety Conceptの構築方法について 機能安全の基礎的な部分 IEC 61508  機能安全に関する国際規格 多くの規格は、安全のレベルを評価している  機能安全で考えなければならない問題として、壊れることを前提で考えないといけない 従来開発の問題点  「壊れないこと」を重視  テスト漏れなどでバグが発生することを考慮しない  また、プロセス面での対策がメイン  ハードウェアはいつか故障することが前提   それを考慮して安全なものにしましょう、というものが機能安全 前段階で安全策とはどんなのがあるのか?  ハザードを特定→リスクを評価  優先度を一番高くしなければならないのは、「本質安全設計」   そもそもリスクの無いものに作りかえること  保護装置やユーザに制限を設けること -> 機能安全 安全コンセプトとは?  システムや想定される状況から、H&R(Hazard Analysis and Risk Assessment)を分析  故障が発生した時に、必要なレベルの安全を達成できることを証明する  一番の肝の「分析」を注釈して紹介  FTA (Fault Tree Analysis)   トップダウン的に細かく見ていく手法  FMEA (Failure Mode and Effect Analysis)   末端の故障からシステム全体の故障を調べていく   荒いレベルでやろうとすると、人によって始点が違う  HAZOP(Hazard and Operability Studies)   ガイドワードを割り当てることによって危険かどうかを考える  知る位置でしりたい部分を完成したい   SFFという故障割合    SFF = 安全側故障率/全故障率    SIL(Safety Integrity Level=安全度水準)の目標レベルを達成するには、どれくらいにならないといけないかという指標    このSFFというのが故障の対策の仕方によって、変わっていきます    故障検出率(DC)を上げることによって、SFFは良くなっていく       DCが60%の簡単な方法だけ達成すればいいかと言えば、それでは不十分   達成しないといけないSILのレベルによって評価していかないといけない 安全分析にて考慮すべき故障パターン  系統的原因故障(バグ)とランダムHW故障    単一故障と多重故障   多重故障=複数の箇所が故障すること   規格によって要求されるレベルが変わる    IEC61508では単一故障のみ    ISO26262(自動車)は2重故障まで考えないといけない    BS EN 50129(鉄道系)だと3重故障まで    恒久故障と一時故障   恒久故障=ずっと壊れ続ける   一時故障=一時的に不具合が起きる    例:途中だけメモリ化けするが、次回には正常に動く      再起動すれば直る  従属故障   ある故障が原因で、別の箇所があわせて故障する    例:停電の影響でマイコンが故障する      さらにマイコンの影響で、別の部分が故障する  共通原因故障   一つの原因によって、複数の箇所が一度に故障する    例:二重化していても、同じシステム、電源を利用していることで起こる故障      ノイズの影響で2つのマイコンが同時に誤操作が起こる故障      安全系のある変数が化けて、変数を使った出力系が全て故障      同じ設計のソフトがあれば、同じ個所に故障が起こる  注:多重故障には二つの意味がある    いくつもの故障が同時に起こる場合は、考慮する必要はない    時間的にずれがあって、2つ3つの故障がある、ということについては考えなければならない     [質問]     考えなくてもよいというのは?      規格上はということです     規格上は、というのがよくわからないのですが      規格上定義されたSILを達成するために、そこまで努力する必要はないという話です      本質的にどうかという話とはまた別の話です      規格は最低ラインであり、それを満たすようなものという意味になります      企業さんで「それではだめだ」と思うのであれば、さらに基準を設けてやるのもいい 潜在故障  安全なケース   安全策で主機能の故障を検出する   安全機能に対して、異常を検出する  危険なケース   安全策が先に故障してしまうと、故障に気づけない可能性がある   例えば、安全策を二重にして、お互いを監視しあうような機構が必要 -発表:高野さん- ◆例題システムの説明 最終的にはドキュメンテーション化が必要なんですが 今回は、ざっくりと、「大丈夫だね」というレベルまで進めてもらいます 機能安全を実現するのに、全部機能安全でなくてもよい  全体が機能安全であれば、一部が本質安全でもよい 例題システム  身近な例として、IHクッキングヒータを用いる  実際の製品はもっと複雑ですが、デフォルメ化しています  IHクッキングヒータ   1.直流電流を供給する   2.設定された周波数で、電流方向を入れ替える   3.コイルの電磁誘導で電流を発生させる   4.鍋のジュール熱によって、鍋の中の具があったまる  残留バグは必ず残ってしまう   「バグがあっても、故障してもいいけど、人に危害を加えてはならない」   という観点で分析を行ってもらいます  不具合の例   周波数が故障して異常加熱が発生   途中の回路が故障   ごく短時間でも油が発火してしまう   そういった状況を想定してもらいます   本当はハザード分析の部分からやりたいのですが   安全分析という部分にフォーカスをあてて考えてもらいます   火災以外にも外部の要因が考えられるのですが(やけどなど)、扱いが難しいので省略して   トップハザードに指定された2つ(システム内部や具の火災)で   電気電子的な要因の不具合を考えてもらいます  クッキングヒータの内部火災の前提   曝され度    使用中、危険な事象が起こりうる時間がどれだけ続くか    クッキングヒータの場合、加熱中は常に起こりうるので高いと考えられます   回避困難度    不具合が発生した後、危険な状態を回避できるかどうか   安全状態への移行限界時間を仮定します ◆グループワークの進め方  スライドにあったIHヒータの設計図の検討を行う  最初のステップではシステムレベルの分析   大体のイメージをつかんでいただきたい   赤の付箋紙で誤動作について検討   関係性について検討   たとえば、全部ショートして発火する など   感覚でいいのでまとめてみる      あとでハード、ソフトの粒度で考えてもらい、関連性を考えてもらう ◆グループワークの内容  - テーブルごとに班を作る(4人1組でA、B、Cチームを構成)  - ボードにIHヒータの設計図  - 付箋に想定される問題を書き、設計図の問題が想定される部分に貼っていく  - 問題の安全策を検討し、付箋を貼っていく ◆グループワークの様子(議事録担当者が参加したAチームの場合) はじめに、動作フローに関する検討を赤い付箋を用いて行った。 検討例: SPC01 直流電流を供給する  過電流の発生による発火 SPC02 設定周波数で電流方向の入れ替え  周波数が異常に高くなる SPC03 電磁誘導で電流の発生  IHコイル自体が発熱して電熱線状態になる SPC04 鍋のジュール熱で温まる  鍋が異常に加熱する 続いて、ハードウェアおよびソフトウェアの設計図に対する検討を黄色の付箋を用いて行った。 検討例: レギュレータ  異常高電圧  低電圧系のみの故障 スイッチングパルス  パルスにノイズが発生して、正しい周波数で動作しない  スイッチングパルスS1、S2のいずれかのみが故障 コンデンサ  コンデンサ異常 コイル  コイルの異常抵抗  鍋が異常な高温になり、コイルに影響する  IHヒータで利用してはならない鍋を利用する ソフトウェア  ROMの異常(ビット化け)  スイッチシーケンスが01→10と推移するため、一時的に00や11となり危険 意見が出そろったあと、発生する問題の関連付けを行い、解決するべき問題の絞り込みを行った。 検討例:  周波数が異常に高くなる原因として、スイッチングパルスにノイズが乗る場合が想定できる  IHコイル自体が発熱する原因は、コイルの異常な抵抗が問題である 最後に、検討した問題について危険の回避策を青の付箋を用いて行った。 検討例: レギュレータ  バリスターを導入し、異常な電圧がかかると回路を切断してしまう 回路  フォトカプラ(絶縁体)を入れる  二重化 スイッチングパルス  フェライト・パスコン等でパルスノイズ対策をする コイル  異常発熱を感知する温度ヒューズの導入  冷却ファンの導入 ソフトウェア  CRCチェックを導入する  スイッチシーケンスにグレイコード(00→01→11→10)を導入する 検討する必要のない問題  コンデンサが故障すれば動作せず加熱されないため、機能安全である ◆成果発表 各チーム2名ずつに分かれ、1組が発表、もう1組が別のチームの発表を聞いて質疑を行うという形態がとられた。 Bチーム  動作フローと回路図の問題を部分ごとに列挙し、設計図ではなくブロック分けされた白い模造紙に付箋が貼られていた。  さらに、関連する付箋同士を線を引いて結びつけることで、共通の問題について検討が行われていた。  問題を解決するための対策法としては、  「温度センサを複数付け、監視を行い、フィードバックする」  「電流量を積算し、指定の範囲外となった場合は切断する」  と簡潔にまとめられていた。 Cチーム  想定される誤動作・故障が赤い付箋、その原因を白い付箋、対策を青い付箋でまとめられており、それぞれ設計図の該当箇所に貼られていた。  問題を解決する対策法としては、  「過電流・過電圧の監視を入れる(センサーを付ける)」  「燃えにくい・耐性に余裕のある素材を利用する」  「スイッチの同時誤動作を防ぐため、スイッチの調達先を分ける」  「鍋の異常加熱を監視する」  などとまとめられていた。 各チームともまとめの形式は異なったものだったが、結論は共通したものが多かった。 ◆まとめ 一つ一つを別々の問題と考えてしまうと、うまく解決できない それをしっかりと考慮した対策が各チームできていたと思います 実際の仕事の場面では分業があります  信頼性を考える場合、話し合いで解決しますが、部品屋だけでは解決できないことがあります   たとえば、コスト面など そのため、できないものはできないとはっきりと言ってしまうことが良いかもしれません 最終的に機能安全をユーザに押し付けるのも有りです  注意書きを大きく貼り付けるとか  それが一番良いソリューションかもしれません これから機能安全を考慮するときは自分がわかる範囲で、どういう危険があるのかを訓練すると良いと思います -12:00 講義終了-