現役の機能安全検査官が、機能安全認証における認証プロセスを中心に、初心者の方にもわかりやすく解説しています。
※本記事は、2024年に執筆されたものです。
1. はじめに
機能安全規格IEC 61508 second editionが発行されてから約14年が経過した。その間、機械類に適用されるISO 13849-1等、IEC 61508の概念を基盤とする機能安全規格は、産業界への浸透を続けている。機能安全認証においては、安全 PLC（Programmable Logic Controller）等の完成品に留まらず、診断ソフトウェアやFPGAに用いるIP（Intellectual Property）等、完成品内部に組み込まれるコンポーネントに至るまで多種多様な認証品を目にする様になった。また、リチウム二次電池の規格IEC 62619においては、機能安全の実現についてIEC 61508が参照され、さらに、重機械の規格ではISO 13849-1への適合要求の追加が検討されている等、機能安全の広がりは益々加速している。これに伴ってか、近年、初めて機能安全規格への適合を検討する企業から、認証プロセスに関する相談をより一層受ける様になった。
本稿では、TÜV Rheinlandの機能安全認証における認証プロセスの概要と、検査員の立場から重要と考える点を述べる。
2．機能安全認証取得のプロセス
本稿では、当社の認証プロセスを、IEC 61508への適合における一般的なモデルケースにて概要を述べる。認証対象の規模や複雑度等によって調整される場合もあるが、当社の認証プロセスは、基本的に以下の四つフェーズ（第１図）で構成されている。
- コンセプトフェーズ
- テストプランフェーズ
- メインインスペクションフェーズ
- 認証フェーズ
各フェーズの審査過程で指摘となった事項は、当社によって指摘事項一覧（LOP：List Of Open Points）にまとめられ、適宜解決が求められる。
では、各フェーズにおいて、どのようなことが必要か順を追って説明していく。
2-1．コンセプトフェーズ
コンセプトフェーズは、機能安全管理計画、安全機能の仕様から診断を含む安全方策の要件に至るまで、規格の要求事項を満たす為の全方針を決定する重要なフェーズである。このフェーズでは、通常、コンセプト文書と呼ばれる以下の四つの文書の作成が必要となる。
（1）安全計画書（SP：Safety Plan）
安全ライフサイクルに関わる活動計画を記述する。安全ライフサイクルにおける各フェーズの定義や、フェーズ毎のインプット・アウトプットを決定する。また、要員、部署、組織の責任割り当てや、その適正能力の正当性、構成管理の方法などの記載も必要となる。
（2）検証・妥当性確認計画書（Verification and Validation Plan）
安全ライフサイクルの過程で、いつ、だれが、どのような検証・妥当性活動を実施するのかを記述する。IEC 61508では、主に人的ミスが要因となって発生するソフトウェアバグ・設計書の記載ミス等、原因と結果（故障）の因果関係が明確な故障を決定論的原因故障と呼ぶ。検証・妥当性確認活動は、この決定論的原因故障の回避において非常に重要な役割を持ち、例えば IEC 61508 Part 2 のAnnex BやIEC 61508 Part 3のAnnex Aに記載されている技法を考慮しながら、適切な活動計画を記載する必要がある。
（3）安全要求仕様書（SRS：Safety Requirement Specification）
安全要求仕様書は、機能安全に関わる前提条件、目標、仕様を記述する文書である。例えば、想定するシステム構成、EMCを含む動作環境の要件、安全機能の定義や反応時間の制約、インターフェース、達成すべき目標安全度水準を明確に記述する必要がある。一般的な開発では、外部仕様書がイメージとして近いかもしれない。
（4）安全コンセプト（SC：Safety Concept）
安全コンセプトは、安全要求仕様書に定義さ れた要求事項の実現方法を具体的に記述した文書である。例えば、内部アーキテクチャ、安全機能の実現方法、診断・過電圧保護・安全部と非安全部の分離方策の実現手段、各々の要件におけるハードウェア・ソフトウェアの役割分担を記載する。
後述するが、 この段階でFMEA （Failure Mode and Effects Analysis）などの適切な故障分析を行い、その分析結果に基づいて安全方策を記述する事が、安全コンセプトが規格要求への適合を論証する上で非常に重要となる。
2-2．テストプランフェーズ
テストプランフェーズでは、メインインスペクションフェーズにて実施される当社立ち合いの故障挿入試験（FIT：Fault Insertion Test）の試験プランや、EMC試験プラン、温湿度・振動衝撃などの環境試験プランの合意を行う。
（1）故障挿入試験プラン
故障挿入試験とは、想定されるハードウェアの故障を実際に模擬し、その際の挙動が問題ないか確認する試験である。CPUの故障など、ハードウェア基板の改造で模擬できない場合は、ソフトウェアにて故障を模擬する場合がある。
当社に回路図・部品表などの設計に関する文書を送付し、当社にて立ち合い試験で実施する故障挿入試験プランを作成する。この立ち合い試験は、安全ライフサイクルにおける妥当性確認の一環としてメーカー自ら実施する故障挿入試験の実施方法や、結果の確からしさをアセスメントする目的もある為、前述の資料に加えて、メーカーが作成した故障挿入試験プラン・レポートの提出が必要になる場合が多い。
（2）EMC試験・環境試験プラン
安全要求仕様にて定義されたEMC・環境条要件に基づいて、試験条件、判定基準、試験セットアップ等が記載されたEMC試験・環境試験プランの合意を実施する。
これら試験プランは、メーカーが作成した試験プランをレビューする方法と、メーカーから提供された情報を基に当社で試験プランを作成する方法の二つの手段があり、検査員とメーカーとの間で協議しながら、柔軟に選択可能である。
2-3．メインインスペクションフェーズ
メインインスペクションフェーズでは、コンセプトフェーズで決定した計画・コンセプトに基づいて実現された設計及び検証・妥当性確認結果を当社がアセスメントする。
（1）故障挿入試験
当社検査員がメーカーを訪問し、テストプランフェーズで合意した試験プランに沿って試験を行い、実機の挙動を確認する。
（2）ソフトウェア検査
当社検査員がメーカーを訪問し、ソフトウェアのアーキテクチャや、機能安全観点における重要な実装コードが、安全コンセプトや規格要求等に適合できているかの検査を行う。これに加えて、コーディング規約への準拠や複雑度（McCabe）の解析等、検証活動の適切性なども考慮される。
（3）機能安全マネジメント監査
当社検査員がメーカーを訪問し、安全計画書及び検証・妥当性確認計画書に従って、安全ライフサイクルの実現やマネジメントが行われたか監査を行う。例えば、計画した検証活動のエビデンスの確認が行われる。
（4）安全パラメータ計算結果審査
IEC 61508には、 安全パラメータ （SFF、 PFDavg、PFHなど）という定量化された数値の要求が存在する。これらの計算結果を、計算の根拠を示した文書と共に当社に提出し、机上検査を実施する。
（5）各種テスト結果の審査
テストプランフェーズで合意したEMC・環境試験の試験結果や、その他妥当性確認試験結果など、プロジェクトの複雑度や認証プロセスの過程で審査が必要と判断された各種試験結果の机上審査が行われる。この際、必要に応じて電気安全に関する安全性の証明も考慮する必要がある。
（6）ユーザーマニュアル審査
ユーザーに提供されるマニュアル類が、IEC 61508 Part 2/Part 3 Annex Dに記載されている要求事項への考慮も含め、適切な情報が記載されているかを机上審査する。
2-4．認証フェーズ
メインインスペクションフェーズまで全て完了し、各種審査結果に問題がなく、LOP内の全て指摘事項が解決されると認証フェーズに移行する。認証フェーズでは、当社検査員が審査結果のまとめた最終レポートを作成し、認証書の発行となる。
3. 認証プロセスにおける要点
3-1．コンセプトフェーズにおける故障分析
機能安全規格に製品を適合させる上で何をすれば良いかと問われた時、本稿の読者を含めた多くの方が、真っ先に想像するのは診断の実現ではないだろうか。診断は、ハードウェア（HW：Hardware）故障を制御する上で重要な機能である。しかしながら、ここで誤解してならない事は『診断は手段であって、目的ではない』という事である。目的の認識を見失うと、思わぬ決定論的原因故障（設計ミス）を引き起こす。例えば、デジタル入力回路の場合、動的パルスを入力して回路を動作させる診断を良く目にするが、その目的は千差万別である。もしかすると、信号の固着を検出したいかもしれないし、信号線同士やケーブルとの短絡を検出したいのかもしれない。この目的によっては、診断実施のタイミングや、故障検出と断定する判定基準など、診断の実装は全く異なるものとなる。
しかしながら、例えば、競合他社製品がパルス診断を実施しているからといった理由で自社の診断を考察してしまうと、どうしても手段にばかり目が行ってしまい、何を検出したいのか不明確なまま安全コンセプトを記述してしまう場合が多い。その結果、主張したい診断率（DC： Diagnostic Coverage）や、診断の網羅性・正当性を示すことが難しくなる。
このような現象を避けるために重要な事の一つが、故障分析の実施である。本稿では、FMEAを代表例として紹介する。今回のFMEAは、コンセプトフェーズで行うHWブロックレベルの FMEAの為、ブロックFMEAと呼称する。では、ブロックFMEAの概略を時系列で説明する。ブロックFMEAは、以下の三つステップで実施する。
（1）前提条件の明確化
安全機能及び安全状態の定義や、分析対象の動作条件を明確にする。例えば、入出力配線の状態、接続される負荷状態、動作モードの設定条件等がある。これらの条件の組み合わせを考慮し、網羅的な分析を実施する必要がある。
（2）HWブロック図の定義
HWのブロック図を定義し、分析対象及び粒度を明確にする。
（3）故障モードの特定と影響分析
前のステップで定義したHWブロック図に対して、IEC 61508 Part 2 Table A.1などを参考にしながら、故障モードを考察し、それぞれに対して、安全関連機能に対する影響、安全側・危険側の分類、危険側の場合は付加する安全方策（例：診断機能）を明確にする。
ブロックFMEAの様な故障分析の実施は、安全方策の目的が明確になり、検出可能な故障モードの網羅性や、安全コンセプトに記述した診断の正当性を示す証拠にもなり得る為、非常に重要なのである。
3-2．明確な仕様記述
機能安全規格の認証プロセスにおいて、メーカーが最初に実施するのが、安全要求仕様書等のコンセプト文書の審査である。この際、コンセプト文書に記述されている仕様の不明瞭さ指摘する場合も多い。私の経験上、その原因で最も多いと感じるのは、自然言語による仕様表現である。これは、自然言語による記述を否定する訳ではない。寧ろ、自然言語による記述が適切な場合も存在する。しかしながら、自然言語には、使用される言葉によっては意味が曖昧になる恐れがある事や、長文を記述すると理解が困難になる等、明確な仕様記述に適さない事がある。例えば、製品の安全に関わる動作モードを自然言語で記述する場合、第2図の例の様に長文化してしまう事が多く、遷移条件に抜けが発生してしまう懸念がある。
以下の例で言えば、電源投入時の初期状態の記述が不足している。これを自然言語の読解で発見するのは困難であろう。ここで、この様な懸念を解決する為の技法の一つが準形式手法による仕様記述である。準形式手法での記述は、IEC 61508でも推奨されている。準形式手法には、状態遷移図、シーケンス図、決定表等の様々な種類があるが、目的に応じて適切な技法を選択する事により、自然言語でデメリットであった曖昧さをある程度避ける事ができる。今回の例であれば、状態遷移図で記述する事により遷移条件の曖昧さを改善する事が可能である。
準形式手法の使用に限らないが、適切な技法による記述によって、仕様の曖昧さを取り除く事が重要である。
4. おわりに
冒頭にも述べた様に、今後、機能安全は様々な業界で益々の発展を遂げるであろう。また、発展と共に一層の複雑化が予想される。現在、欧州にてサイバーレジリエンス法（CRA： Cyber Resilience Act）の施行が迫っている事もあり、産業界も含めサイバーセキュリティの実現は、各メーカーの急務となっている。サイバーセキュリティは、セキュリティの脅威下においてもシステムの可用性が求められる。一方で、異常が発生した場合にシステムを安全な状態に制御する事を重要視するのが機能安全であり、安全状態の多くはシステムを停止状態にする事を意味する。したがって、両者の共存の実現は、非常に複雑な設計思想が求められる。
当社では、機能安全とサイバーセキュリティの両者の認証サービスを提供していると共に、日本語によるワークショップやトレーニングを随時開催している。これらのサービスを通じて、当社が微力ながら日本の機能安全とサイバーセキュリティの発展に貢献できれば幸いである。
出典：月刊「計測技術」（日本工業出版株式会社）2024年10月号の特集：機能安全と安全計装
機能安全と第三者認証機関 ＜機能安全規格の認証プロセスと要点＞ テュフ ラインランド ジャパン株式会社 前川 貴昭