※告知が遅くなってすみません。本セミナーはすでに終了しました。
テュフズード社150周年記念イベントで講演します。講演テーマは、「Industry4.0取り組みのポイント ～セーフティ・セキュリティの融合～」です。テュフズード社は、ドイツが国家をあげて推進しているIndustrie4.0のSafety・Securityの分野の中心メンバーです。ドイツが目指すIndustrie4.0とはどのようなものか、CPS（Cyber Physical System）とはなにか、そしてセキュリティがどのように重要なのか、Safetyとどのような関係にあるのかを事例を挙げながらわかりやすく解説します。
機能安全連載 完結
おかげさまで、CQ出版 インターフェースでの機能安全連載が完結いたしました。ご購読いただいた皆様、ありがとうございました。2年にまたがる連載のため、インターフェース記事CDが2015年と2016年にまたがりますが、ぜひ通読をしてみてください。出版リクエストも編集部まで。（笑）
2015年8月号 #1回 ｢機能安全｣と｢本質安全｣
2015年9月号 #2回 ｢リスク｣｢安全｣用語の定義
2015年10月号#3回 ｢リスクマネージメント｣
2015年11月号#4回 ｢構想設計｣
2015年12月号#5回 ｢FMEA｣
2016年1月号 #6回 ｢購入部品のリスク評価｣
2016年2月号 連載お休み
2016年3月号 連載お休み
2016年4月号 #7回 「システムの安全性を診断する方法」①
2016年5月号 #8回「システムの安全性を診断する方法」②
2016年6月号 #9回「システムの安全性を高める多重化多様化」
2016年7月号 連載お休み
2016年8月号 #10回「機能安全は構想設計が大切」
2016年9月号 #11回「機能安全のソフトウェア開発」
2016年10月号#12回「プロセスとトレーサビリティ」
架空の恒星間宇宙船を例にもちいて機能安全を気楽に知ってもらおうというのがコンセプトです。
この連載では機能安全IEC-61508の設計開発プロセスに沿って解説を進めます。
システムが持つハードウェアの故障率を一般に「λ（Lambda）」で表します。λDUとは、「Dangerous Undetectable（検知できない危険側故障率）」を表します。なにかの危険リスクを低減するための保護システムがあった場合、そのシステムに故障が発生した場合、保護システムの役割を果たせず危険リスクの低減ができなくなるような故障を危険側故障と言います。そのような故障のうち、発生しても直ちに認知できない（故障したことが判らない）故障を「Undetectable」すなわち検知できない危険側故障といいます。
※2017年12月加筆
多くの企業が取り入れているISO-9001品質マネージメントシステムは、2015年9月15日、7年ぶりに改定されました。今回の改定の大きなポイントは、リスクベース思考（Risk-based thinking）が明示された点です。PDCAサイクルと組み合わさって、プロセスアプローチを支える重要な要素として扱われています[*1]。また「第6章Planning」など様々な条項で、「Risk（と機会）について検討すること」と要件に組み込まれています。以前のISO-9001 2008年度版においても、序文にもリスクという言葉は出てきますし「予防措置」が似たコンセプトだと言えなくもないですが、書きっぷりからして今回追加された新しい概念であると考えるべきです。
しかしながら具体的にどのようにしてリスクに向き合うのか、ISO-9001それ自体では詳しく触れられていません。必須要件でもありませんし、Annex Aに「必要なら他のガイドラインや規格を利用してもよい（しなくてもよい）」程度に書かれているのみです。しかし現代の企業活動において、「わが社では、QMSプロセスに、リスクマネージメントは必要ではない」と断言する方が無理があるでしょう。逆に「どこでも当たり前にやっている」と感じるのが普通です。ではなぜわざわざ大きく書き加えたのでしょう。
機能安全規格IEC-61508で登場するPFDは、システムの危険側不動作確率を表します。リスクを軽減するための「万一の為の仕組み」が、「イザ！というときにちゃんと動かないかもしれない確率=PFD」を求め、対策するリスクのレベルに応じて十分な信頼性を持つかを確認することが目的です。ここでは、このPFDの式がどのような背景で求められたのかを見てゆきます。
信頼性向上のためにシステムを二重化した場合、どのぐらい信頼性が上がるでしょうか。機能安全IEC-61508では、共通要因故障の存在のため、共通割合（βファクタ：0.01<β<0.1）の程度しか信頼度が上がらないと示しています。一方日本国内でのシステム二重化の評価では、二重化した場合のMTBFの計算式を用いることが多いです。
ここでは、機能安全で示している共通要因故障の存在の有無が、MTBFの値に与える影響を考えてゆきます。
機能安全に取り組むときに、プロジェクトチームにまず最初に必要となるものがFSM（Functional Safety Management plan）です。システムなど「モノ」そのものに対する要件ではなく、その「もの」を生み出す組織の枠組みに対して規格が求めていることに準拠していることを示す計画書です。ここでは、IEC-61508 Part1に示されているFSMへの要件のうち、多くの会社で持たないであろう要件と対応策を説明します。前もって自分たちでギャップ分析をして対策しておけば、審査機関のチェックもハードルが低くなります。是非活用してください。
最近のコメント