部門を巻き込み 可能であればエンドユーザーもメンバーに加え多面的な意見集約が有効とされている ちなみに IEC61508 part5 には参考手法としてリスクマトリクスが紹介されているが 必ずしもこの手法を使用しなければならないということでもない 社内ですでに使われているものがあればそれを使用しても

Transcription

1 IEC 認証について機能安全と認証プロセス第 1 回 出典 : 計測技術 (2013 年 10 月号 ) 日本工業出版株式会社 特集付録 : 安全 PLC& 計器製品ガイド 1. はじめに テュフラインランドジャパン株式会社 機能安全シニアエキスパート 和田昌士 事故の回避 安全とは法律などの規制によって達成されると認識するべきではない 人間としての責任義務であると理解するべきである それは総合的に見て経済的な合理性もある これはある有名なドイツ人技術者のことばである 日本の技術者はこれをどのように受け取るだろうか 結局は製品の安全性は規格に適合していれば良いのであって理想と現実とは違うと言われそうである そもそも日本とヨーロッパとでは 安全文化 (Safety culture) が違う 例えば きっちりとしたメンテナンスと使用者への教育訓練で安全を確保しようとする文化と そもそも機械は故障するもの 人間は間違うものという前提で安全を考える文化である 後者がヨーロッパの考え方であり 設計思想もそれが前提となっている そして機能安全もこの考え方に基づいている 国際安全規格は基本概念として state-of-the-art つまり設計者に最善の技術 努力の投入を要求している しかし この最善の技術 努力の投入は 安全規格への適合 のことだと理解している日本の技術者が残念ながら非常に多い 規格適合は 最低限 として必要なのであって それに加えて設計者自身の思考努力を要求している 例えば リスク分析 (FMEA など ) の実施によってある現象による危険事象が想定可能であるが それは規格書の要求事項として特に明記されていないため対応する必要はないと判断するのは間違いである つまり規格要求に関わらず対応しなくて本当によいのかどうか設計者として考え議論するべきである 要は最終的な安全責任は 規格 にあるのではなく 組織 設計者本人 が担っているということだ これは機能安全による設計において理解しておくべき大切なポイントである 実際の認証プロセスにおいて検査官は常にそのことを念頭においてコンセプト評価そして実機検査を行っている 本稿では 機能安全の中心に位置する IEC 規格の認証取得において必要なこと 考え方 それと同時に日本国内で氾濫している誤った情報 解釈などについて述べる 2. 機能安全規格の導入 機能安全規格のみならず 現在の国際安全規格の基本概念は組織 設計者の事前責任を求めている つまり十分なリスク分析の実施を強く求めている 一般的に定性的もしくは半定量的なリスク分析は設計者のみで実施するだけでなく 製造 品質管理 販売などの他

2 部門を巻き込み 可能であればエンドユーザーもメンバーに加え多面的な意見集約が有効とされている ちなみに IEC61508 part5 には参考手法としてリスクマトリクスが紹介されているが 必ずしもこの手法を使用しなければならないということでもない 社内ですでに使われているものがあればそれを使用してもよい しかし注意しなければならないのは保守的なリスク見積もしくは重要リスクの見逃しなどがあれば その結果に基づいて設計された安全機能に致命的な問題点を内包してしまうことになる 或いは目標の安全度水準 (SIL) を決定する時に上記の分析手法に依らず 競合他社と同等もしくはそれ以上の水準を目標とするということでも構わない そういったケースが実際には多いのも事実である そしてそれと同時に参照すべき関連規格の有無を調べておくことも重要である つまり 規格適合は 1 つずつ順番に達成するのではなく できるだけ複数の規格を一度に考慮し網羅的な試験方法とワーストケースレベルによる試験を実施した方が時間 費用の大幅な節約になる このことは同時に考慮すべき規格要求 ガイドラインを設計に取り入れたことになり 事前責任を果たす点で非常に重要な意味を持つ 要するに 国際安全規格が要求しているのは 設計段階で安全な設計について十分に考え 考慮すべき要求 ガイドラインを最大限に取り入れることであり ひいてはこのことがビジネス上での優位性を確保することにもなる 次に IEC61508 機能安全規格に適合させるということを簡単に表したのが ( 第 1 図 ) である リスク分析の結果から安全度水準 (SIL) を決定すれば その後は規格書に記載されている SIL ごとの技法 方策を設計に取り入れることによって 要求事項 ( 回避 抑制方策 ) を満たしたことになる IEC61508 の要求事項は大きく分けると 機能安全マネジメント ハードウェア設計 ソフトウェア設計 そして定量的数値である安全関連パラメータ ( 自己診断率 機能失敗確率など ) の四つの要求区分がある 要求事項には必須項目もあれば選択可能項目もあり 必須項目であっても目標 SIL を十分達成できる論理的合理性を示せれば規格書の要求内容から部分的に逸脱することも認められている 第 1 図 IEC 適合の概念図

3 3. 機能安全規格 IEC61508 の状況 IEC61508 は多くの安全規格をカバーする傘のように例えられる 第 2 図のように影響を与えている多くの産業分野の規格が存在する そしてそれらの規格が改訂されるごとに IEC61508 の要求をそのまま導入 もしくは参照度合いが強くなっている 第 2 図 IEC と産業別機能安全規格 そこで EU 圏内での製品流通には指令 (Directive) 適合が必要となるわけだが IEC61508 単独では CE 適合にはならない そこで指令ごとに用意された整合規格 (Harmonized standard) と組み合わせて適合させることにより大きな意味を持つことになる その際にどの整合規格を使用するかは 市場 競合他社の動向などをよく考慮し決定しなければならない IEC61508 は初版の Edition 1 を発行後 約 10 年の改訂作業を経て 2010 年 4 月に Edition 2 が発行された 次の項目がその主な改訂内容である 設計に関わる要員の適正能力要求の強化 SIL4 割り当ての厳格化 セキュリティ ( 改ざん保護 ) の要求 ハードウェア適合ルート (Route 1H, Route 2H) の定義 SFF 計算における no part failure, no effect failure の定義 Systematic capability (SC1~SC4) の定義 適合アイテムの定義 (system, subsystem, element) 安全マニュアルへの記載事項の要求 集積回路 ASIC FPGA 等の要求 On chip redundancy の要求 既存ソフトウェアの要求 (Route 1S, Route 2S, Route 3S) 開発 評価用ツールの定義 (T1, T2, T3) その他 文章改訂など 例えば 安全向け集積回路 ASIC FPGA 等の要求事項には V モデルに沿った設計プロセスと決定論的原因故障 (Systematic failure) の回避に対して具体的な方策が示された しかしながら 偶発故障 (Random failure) に対する方策はこれまでのハードウェア設計時と同様の考慮が必要になる 集積回路は複雑度が増すにつれて以前よりもフォールトモデルおよびテストケースの特定がより難しくなってきている そのためには複雑なフォールト

4 モデルに対し意味のある診断技法および抑制方策が必要であり 特に内部診断機能の重要性が今後益々高まることになる 4. 第三者認証機関の位置づけ 第三者認証という仕組みはヨーロッパでは既に長い歴史があり 社会的な認識も根付いている 日本でも認知されつつあるが 基本的には規制 規定は国もしくは同等の機関が強制力をもって制定し これに従うことで製造 流通 販売の権利 機会が保障されて来た経緯がある これに対し 強制力のない自主的ルールではあるが 多くの人 組織がそれを遵守することにより事実上の強制力が生じ 遵守していない場合は何らかの社会的制裁を被るような制度 いわゆるデジュールスタンダードに対して日本はあまり積極的ではなかった 確かに人の安全 健康に関わる基本部分は強制力を持って規制されるべきだが それらの実現 解決方法は柔軟に自己責任において選択できて良いはずであり 今やそれは国際的な認識 かつ方向性でもある EU では安全設計の考え方や安全性立証の方法論などの議論も活発であり メーカーや大学研究機関と共に第三者認証機関も大きな役割を果たしている 国際認証機関 TÜV Rheinland の名称も IEC61508 part 7 初版の多くの箇所に記載されているように 40 年以上前から機能安全を研究し その研究成果が規格内で使用されている そういった EU の研究に比べて 残念ながら日本の意識はそこまで至っていない 一番の関心事は どうやれば認証が簡単に早く取得できるか ということのようだ しかし 日本でも一部の先駆的な企業は機能安全技術を設計の基本に据え その取り組みも非常に積極的である 要するに装置の信頼性向上はもちろん重要だが それだけでは十分な安全性は確保できない 第 3 図第三者認証機関の位置づけ概念図 しかし安全性を向上することは装置の信頼性向上に大きく寄与する そのことを設計者が良く理解し 安全設計に対する消極的な取り組み意識から脱却しなければならない 第 3 図はメーカー エンドユーザー 第三者認証機関の位置付けの相関関係を簡単に示したものである 第三者認証機関は 特定の業界団体あるいは企業の資本的関係において中立かつ独立な立場でなくてはならない そして エンドユーザーからの絶対的な信頼を得ることによって メーカーの信頼性を客観的に証明する責任を担っている 次回は 機能安全認証の取得プロセスと第三者認証機関の位置づけを掲載します 5. 機能安全認証の取得プロセス 実際の認証にはどのようなプロセスがあり どのようなドキュメントが必要か 機能安全規格 IEC 認証を例に概要を述べる 認証プロジェクトが初めてであれば 事前に機能安全のトレーニング ワークショップや技術ミーティングを実施することが多い 特に機能安全は難解な部分も多いだけに 設計者自身の理解は不可欠であり 認証プロセスの時間短縮のための大きなカギを握る 以下に標準的プロジェクトの開始から認証書発行まで

5 の工程を示す 認証機関では 時系列で以下のような 3 フェーズ ( 第 4 図 ) を設定している 第 4 図認証プロセス 事前準備 :( 技術ミーティング ワークショップ TUV 機能安全エンジニア資格 ) 1) コンセプトフェーズ ( ドキュメントレベルでの検査 ) 2) メインインスペクションフェーズ ( 実機を使った検査 ) 3) 認証フェーズ ( 最終確認と認証書発行手続き ) 5.1 コンセプトフェーズ 最も重要なフェーズである 設計者はこのフェーズにおいて 機能安全マネジメント ハードウェア設計 ソフトウェア設計の安全仕様について明確に文書化しておく必要がある 最低限必要な情報として 以下の 4 っのドキュメントを要求している 1)Safety Plan( 安全計画書 ) プロジェクトの機能安全マネジメント ( 組織 担当責任者の適正能力 安全設計での導入方策と技法 ) を具体的に記述したもの 2)V&V: Verification and Validation Plan( 検証 妥当性確認書 ) 設計プロセスの各フェーズで どんなツールで どのような検証 妥当性確認を実施し その結果をどのように文書化するのかを記述したもの 3)SRS: Safety Requirement Specification( 安全要求仕様書 ) どんな安全状態 システム 動作環境を想定しているかなど 必要な安全要求仕様を具体的に記述したもの

6 4)SC: Safety Concept( 安全コンセプト ) SRS を基にどのように安全機能を実現するか ( 特にタイミング 非安全関連部から安全関連部への影響回避方策など ) を具体的に記述したもの これらは必要最低限の情報を集約明示化したものであって その他にも必要な場合は 付随 付加するドキュメント類が存在する 5.2 メインインスペクションフェーズ このフェーズの本来の意味は コンセプトフェーズで記述されている仕様について 実機を使って実証 つまり検証および妥当性を確認することにある しかし このメインインスペクションフェーズの段階で もし問題点が見つかると 変更のために多大な時間と費用が必要となってしまう それを防ぐためにもコンセプトフェーズで十分な検討が必要である 以下がこのフェーズで実施される主要な項目である 1) 機能安全マネジメントシステムの監査 Safety Plan および V&V Plan の記載内容に基づいて監査を行う 2) 故障挿入試験 (FIT: Fault Insertion Test) 安全関連系に意図的にフォールトを挿入し その際の挙動 検出機能等を確認する 3) ソフトウェア検査ソフトウェアフロー コーディング 複雑度 使用ツールの検査 4) 環境試験 ( 温度 湿度 振動 EMC) 要求規定に基づく環境試験 EMC は厳格なイミュニティ試験 5) 電気安全 PCB レイアウトの絶縁 沿面距離の確認 これ以外にもアプリケーションにより必要な場合 特定の試験が実施される 5.3 認証フェーズ 上記フェーズにおけるドキュメント ( 安全仕様 マニュアル等 ) 各種テストレポートおよび安全関連パラメータの妥当性などをレビューし 要求事項および目標の安全度水準を満たしているかを総合的に判断する 問題が無ければ 最終レポートの作成および認証書の発行となる 認証書はどんな認証機関でも発行可能なプライベート認証と EU 圏内でノーティファイドボディ (Notified Body) として認定された認証機関でしか発行できない法的効力を伴った認証 (EC Type-Examination Certificate) とがある 現状日本で後者のような認証書を発行できるのは TÜV Rheinland のような一部の外資系認証機関に限られる おわりに IEC の初版が発行されてから 10 年以上が経過した 日本でもすでに多くの製品がこの規格の認証を受けているか あるいは認証へ向けての取り組みの最中である ところがその状況と共に この規格への誤った情報 解釈をよく耳にするようになった

7 おそらく間違った もしくは偏った理解をしているコンサルタント アドバイザが市場参入し 設計者がその話を鵜呑みにしているのであろう その傾向の一つとしては 機能安全マネジメントシステムへの偏重志向がある 確かに設計プロセスマネジメントは重要でかつ要求事項でもあるが 機能安全の要求事項は他にもいくつかあり ( 第 1 図参照 ) マネジメント要求はその内の一つに過ぎない だが これこそが機能安全の主要要求かのように強調し ハードウェア ソフトウェアのアーキテクチャや診断技法 共通原因故障など大切なことにほとんど考えが及んでいないケースが最近増えている 原因は アドバイスする側の安全設計に関する知識 経験不足とマネジメントや故障確率計算という 誰でも理解容易なことしか言わないためである そして高額のマネジメント認証取得を進めるケースもある だが製品メーカー自身が それに多額の費用と時間を費やすことはあまり合理的とは言えない このマネジメント偏重志向は 国際的な安全設計の考え方とは少し違う方向に向かわせている すでに QMS 認証を取得している企業であれば それをそのまま利用し 機能安全マネジメント部分を若干追加すれば良いだけであり それに不必要に多くの時間と費用をかけるべきではない また 当たり前だがエンジニアは技術の専門家であって法律家ではない だが 時々法律家のように規格解釈論を語る方がいる 機能安全規格は ぜひエンジニアとしての視点で見てほしい そうでなければ導入効果も薄れ矛盾だらけの設計になる 日本の機能安全の現状は規格解釈について語る機会は増えたが 実際の製品のハードウェア ソフトウェアの安全設計を理解し解析 評価できる能力を持った方は非常に少ない これからは単なる規格解釈ではなく 実際の安全設計について議論ができる環境がもっと必要なのではないだろうか 信頼性 安全性ということをよく理解し故障しても安全で かつ高品質な製品設計に我々も微力ながら貢献できれば幸いである 日刊工業出版ウェブサイト テュフラインランドジャパン株式会社