いまさら聞けない 機能安全入門：機能安全規格基礎（4/4 ページ）

[服部博行（ヴィッツ），MONOist]

導入のポイント・手順

導入支援

　機能安全規格に準拠した製品を開発する場合、規格書を読破し、対応することも不可能ではありませんが、この場合はそれ相応の時間と工数を必要とします。規格書では、要求項目については記載されていますが、方法や度合いに関することは一切記載されていません。そのため、これらすべてに対応することは至難の業といえるでしょう。

　また、機能安全規格への適合性は、「ISO/IEC 17000」シリーズが規定するとおり、第三者（登録認証機関）による「認証（Certification）」、第二者（取引先など）による「確認」、第一者による「自己適合宣言（自己宣言）」が可能です。

　ここからは、第三者（登録認証機関）による認証方法を前提として説明していきます。

　登録認証機関から認証を得るために、必要な項目の相談や実施内容のレビューを行い、すべて自力で対応する方法もありますが、そこには言語の問題や自社製品の内容をすべて開示するなどの問題も残ります。

　また、実績のある登録認証機関としてはドイツのTUV（テュフ）が有名ですが、残念なことに機能安全規格の認証で実績のある日本の登録認証機関（注）は存在しません……。そのため、コンサルタントや対応経験のある企業からの支援を受けることが、機能安全対応の一番の近道であると思います。実際、筆者らが実施している機能安全対応RTOS開発においては、国内のコンサルタント企業からの支援を受け、ドイツTUVへの実施内容レビューなど行っています。

※注：ドイツTUVは日本国内に日本法人を設立していますが、日本法人の主な役割は窓口業務であり、最終的な認証はドイツで行われます。

認証は2段階

　実際、認証は「コンセプトの認証」と「製品の認証」の2段階で実施されます。

　コンセプトの認証は、開発する製品のリスクが正しく抽出されているか、また、その結果から安全度水準が規定されているかなど、製品の安全に対するコンセプトについて検証されます。また、対象とする製品を開発する管理計画について、詳細な検証が実施されます。管理計画は規格が要求する要求項目事項を、いつ・どのように実現するか？ また、実施可否の判断基準は正しいか？ などについて判断します。

　このコンセプト認証は困難を極めるもので、この認証が得られれば、後は管理計画に従い開発や運用を実施するのみとなります。

　一方、製品認証は前述したコンセプト認証で合意したコンセプト、管理計画に基づき、開発や管理を実施し、製品開発を行います。その活動の結果、作成された各種ドキュメント、適合確認、監査結果などを基に製品が安全規格に順守して開発されているかどうかの確認が行われます。

　開発した製品が安全規格に順守しているかどうかの最終判断ですので、この認証が得られれば、機能安全に順守した製品の開発が完了したことになります。しかしながら、機能安全規格は製品出荷後の管理も規定されているので、製品認証取得後の活動も対象範囲となります。管理計画に記載されている運用・保守・廃棄は確実に実施する必要があります。

安全関連範囲を規定する

　IEC 61508に準拠した製品開発を実施する場合、製品すべてを安全に関する部位として範囲を規定しても構いません。しかし、対応する部位が大きければ大きいほど、作業量は指数的に膨れ上がり、製品を開発するのが困難になります。筆者らが欧州でレビューを行った際、担当者から「あなたたちが寝ずに頑張っても、この範囲・方法では実現できない。死人が出てしまいますよ」と警告を受けたことがあります。

　本当に安全を維持するためには“必要な部位”を特定し、その部位を障害から保護する、もしくはその部位が動作し続けるように対策を施すことが重要です。つまり、安全に必要な部位をなるべく小さい範囲で規定することが、IEC 61508に順守した製品を作るために必要な事項であるということです。

　確かに、「製品すべてについて安全規格を順守した開発が行われ、製品全体が安全認証を受けている」という点には大きな魅力を感じますが、それを実現するために膨大な工数や開発費を掛けるのも現実的ではありません（開発費を回収するために製品価格を跳ね上げてはモノは売れません）。機能安全規格に対応する範囲が大きければ大きいほど、製品価値は高まります。しかし、製品としての魅力（価格を含めて）を損なうことのないように、実現可能かつ製品として成立する範囲を適切に定める必要があります。

必要文書

　IEC 61508の認証を受ける際に必要となる文書がいくつかあります。また、認証は2段階認証だと前述しましたが、それぞれの認証についても異なる文書が必要となります。

＜コンセプトの認証＞
コンセプトの認証に必要となる主要な文書は以下の3種類です。

1. 安全コンセプト（SC：Safety Concept）
   開発する製品の安全コンセプトを記載する。
2. 安全要求仕様（SRS：Safety Requirement Specification）
   開発する製品が安全コンセプトを満たすために、必要となる安全要求仕様を規定する文書。
3. 機能安全管理計画（FSMP：Functional Safety Management Plan）
   開発する製品が安全要求仕様を満たすために必要となる人・組織・技術の管理を規定する文書。開発はこの管理計画に順守することが求められる。

＜製品の認証＞
製品認証には、機能安全管理計画に規定した開発を正しく実施したことを示すためのドキュメントが必要となります。具体的には、各開発フェイズでの入力ドキュメント、出力ドキュメント、検査計画と検査実施ドキュメント、適合確認シート、設計レビューシートなどです。

安全分析

　機能安全対策で技術的な難関は「安全分析」です。前述したコンセプト認証で要求される安全コンセプトや安全要求仕様を作成する時点で、開発する製品の安全分析が必要となります。この安全分析は、製品に潜む危険の抽出や製品が万一故障したときに発生する可能性のある危険事象を抽出して、それらの対策を施すための活動です。また製品の設計に着手し、ある程度構造設計が進んだ時点で「構造分析」などを行う場合もあります。このときは構造に着目し、設計構造から想定される危険事象を抽出して、その対策を施します。

　これらの安全分析は、通常「FTA（Fault Tree Analysis）」「FMEA（Failure Mode and Effect Analysis）」「HAZOP（Hazard and Operability Study）」の分析手法を用います。それぞれ、分析の対象や分析方法が異なり、対象物の特徴により適した分析手法を用いるのがよいと思います。しかし、これらの分析は基本的にシステムを対象としているため、ソフトウェア単体を分析するような場合などでは効率よく分析できるとは限りません。現在、筆者らが実施中の研究事業においては、これらの分析手法の長所を交ぜ合わせた手法を用いています。何度か分析を行うと効率のよい手法を見付けることができるので、最適な方法を検討してみてください。

参考：分析手法について

FTA：障害となる事例を基に、その障害が発生する要因を抽出する。

FMEA：システムを構成している要素を対象とし、考えられる故障と影響を抽出する。

HAZOP：対象となる機能の期待される振る舞いに対して、「ガイドワード」と呼ばれる事象を当てはめて原因と影響を抽出する。

---

　機能安全対策は、第1段階の“コンセプト認証”が重要です。ここでは、機能安全規格に従った開発プロセス・計画を立案・規定するため、このフェイズの良しあしが、機能安全対策の期間と費用を左右します。さらに、コンセプト認証では、SC、SRS、FSMPが重要となります。規格が要求する事項を盛り込んだ3つの規定文書が完了すれば、機能安全対策の折り返し地点に到達したといえるでしょう。

　また安全分析は、純粋に製品の安全性を高めるための活動につながります。安全分析には時間と費用は掛かりますが、分析結果からは安全に関する事項ばかりでなく、品質向上にも寄与する結果が得られる場合もあります。

　以上が、機能安全の基礎とその概要となります。最後までお付き合いいただき、ありがとうございました。本特集が機能安全への取り組みの一助になれば幸いです。