機能安全規格の要求を理解するためには、機能安全の本質を理解していることが大事です。国際安全規格を正しく活用すれば、安全性を立証するための強力なツールになるのです。
要求事項のポイントと認証プロセス
制御系のエンジニアに必要とされる知識として「機能安全」はすでに定着している。その必要性を感じ始めたのはEU関係のエンドユーザからの要求か、もしくは競合他社の動向がきっかけかも知れないが早急な対応が求められているということで相談の依頼が年々多くなっている。
しかしながら、その相談者に機能安全の予備知識がまったくない状態で打ち合わせを行うと議論がほとんど噛み合わないことがある。その原因は「最低限どんなことをすればよいか」と安易な答えだけを期待し「何をどのように設計するべきか」を自ら考える必要性を理解していないからである。自ら考えようとしない、つまり指示待ちタイプの人には機能安全要求を何度説明しても理解しにくいようである。規格書には適合を証明するための「決められた唯一の具体的方法」は指示されていない、その代わりに「取り入れるべき方策・技法」について示している。これは規格書の記述があいまいなのではなく意図的に明記を避けていると言った方が正しい。つまり「安全度水準」の定義を明確にし、その達成のために取り入れるべき方策・技法のガイダンスのみは示しているが具体的な解決方法はあえて示さず設計者に考えさせるようにしている。このことによりメーカー・設計者は技術的解決方法を自ら考え、その方法の合理性を理論的に立証することを求められる当然そこには設計責任も伴う。それこそが現在の国際安全規格の意図することでもある。（図１参照）この本質を理解していない人ほど「機能安全規格の要求はあいまい」とよく言うのである、あいまいどころか「積極的に」使いこなせば非常に便利な合理性証明ツール（安全性立証手段）になるはずである。
1. 要求全般と考え方
安全ライフサイクルに基づき、まずは目標とするSIL（安全度水準）の決定が必要だがリスクグラフもしくは半定量的（FTA, ETAなど）手法を用いてSILを決定する。一般的にはそもそもエンドユーザからの要求、業界内でSILが自ずと特定されている、あるいは既に製品規格のなかで機能ごとにSILが特定されている場合もある。
目標SILが決定すると次はそのアプリケーションの「安全状態」の定義を明確にしなければならない。つまりアプリケーションの特性・使用方法によって「安全状態」の定義は様々であり大きくは「止まる安全」か「止まらない安全」ということである。機械であれば多くの場合、駆動エネルギーの除去による停止が安全状態であるがプロセス産業、自動車などは状況が異なり故障発生時には冗長構成による運転の継続と故障箇所修理のための許容時間が計算上特定される。また、安全機能の役割は「安全状態への遷移」だが実はそれだけではない、「安全状態の維持」つまり安全状態に遷移した後は危険要因が除去され、かつ個別で意図的な起動要求がない限り自動復帰しないという状態維持機能も安全機能に求められる重要な役割である。
2. フォールトの分類と対処方策について
フォールトつまり安全機能を喪失させる可能性のある起因にはSystematic（決定論的）要因とRandom（偶発的）要因とがある。それらへの対処方策として以下の二種類の両方かもしくはどちらかを合理的に使用することになる。（図２参照）
| Fault avoidance（フォールト回避） |
| フォールトが導入されないよう事前に回避するための方策・技法を用いることである。要するにSystematic（決定論的）要因は因果関係が明確な現象であるからフォールトの原因をできるだけ減少させる方策を意図する。具体的には設計プロセスの厳格なマネジメント、有効なテストプランの作成や独立性が確保された者によるレビューなどがある。その方策については規格内に表形式で記載されておりSILに応じて方策の厳格さが変わる。 |
| Fault control（フォールト制御） |
|
複雑なシステム（半導体集積回路など）の場合、上記のようなフォールト回避方策だけでは全ての故障を防ぐのは現実的には不可能である。なのでもし何らかのフォールトが発生しても安全機能が喪失しないか、あるいは危険な状態にならないような設計が求められる。つまり冗長構成もしくは十分な外部・内部の診断機能によって対処する方策・技法を用いることである。これらも規格内に表形式で記載されておりSILに応じて使用すべき技法の厳格度が変わる。 それ以外にも多重チャンネルの場合に考慮されなければならない現象がCommon cause failure（共通原因故障）である。つまり単一事象（電源、EMC, 温度、湿度、振動、衝撃など）の原因によって冗長チャンネルが同時に安全機能を喪失する、つまり冗長性がなくなる現象であり対応策として以下が考えられる。 |
| Diversity（多様性）と Decoupling（分離） |
| 「多様性」とは各チャンネルごとに違う技術・部品・アルゴリズム・製造工程などを用いることで、冗長化されたチャンネルごとに異なった動作特性を持たせる考え方である。また同時にチャンネル間で故障が連鎖しないように電気的・機能的・温度的な「分離」についても十分な検討が必要である。要するに冗長性を成立させるためにはチャンネルごとの独立性が確保されなければならない。 |
3. 規格要求事項の分類
この61508規格には数多くの要求事項が記載されているが、それらを分かり易く分類すると以下の四つ（①、②、③、④）になる。（図３参照）
定性的な要求として
① ハードウェアへの要求
ハードウェアアーキテクチャの決定においては、目標SILとフォールト発生時に安全側となるフォールトの割合 (SFF) からアーキテクチャの制約を課している。つまりフォールに対し安全機能の動作する仕組みを１チャンネル構成あるいは多重チャンネル構成のどちらで実現するのかを判断しなければならない。たとえば安全機能を１チャンネル構成で設計した場合、目標SILを達成するためには高性能で高頻度の診断機能が必要となる。それに対し多重チャンネル構成で安全機能を実現する場合、診断機能の設計は比較的楽にはなるが部品コスト、実装面積の増大が問題になる。要するに、フォールトに対してどんな技法を軸に設計するかである。高診断もしくは冗長のどちらに重点をおいた設計にするかを十分に意識することである。また、”Idle current principle” という要求がある、これは安全状態というのはidle状態にて達成する、つまり供給電源が停止した状態でも達成されるような設計でなければならない。
また、一般的に良く使われているフェイルセーフの考え方は61508規格では方策として明示的には使用しない。理由はフェイルセーフの仕組みそのものが非安全関連部の一部に依存していることが多いためである。その場合はフェイルセーフ動作そのものが保証されないことになる、これはフェイルセーフの数を増やせば解決するわけでもはなく根本的な問題である。
② ソフトウェアへの要求
ソフトウェアへの要求は定性的な内容であって現時点では数値的指標による定量的要求というものは示されていない。だがソフトウェア開発プロセスでのフォールト導入の軽減手段の一つとしてソースコードの複雑度の管理（つまり、複雑にしない）の要求がある。その指標としてよく使われるのが循環的複雑度（通称：McCabe）で数値的な指標として使うことができる。ソフトウェアの全般的な要求事項はソフトウェア設計プロセス内で導入されるフォールトを可能な限り排除するということである。その方法として要求しているのが明確な開発プロセスの定義・分類とマネジメントである。規格書にはVモデル開発を示しているがこれは要求意図を理解するためのガイダンスと考えた方がよい。アジャイル型設計であってもソフトウェア安全要求仕様をトレースできる仕組みが確立されれば良いわけである。要するに重要なことはソフトウェアに求める安全要求仕様への正確なトレースである。特に診断機能には十分な検討が必要で診断機能のほとんどはハードウェアとソフトウェアのコンビネーションで実現されことからハードウェア性能・限界を良く理解したソフトウェア開発が必要である。そしてソフトウェア開発で使用するツール類に関しても厳しい要求がある、特に実行コードを直接生成するコンパイラ等は妥当性が十分に証明されその結果が文書化されていなければならない。妥当性が証明されていないツールの使用は非常にリスクが大きい、なぜなら問題のあるツールを使用すると製品がフィールドに出てから初めて製品の不具合が顕在化することになり、非常に大きな損害を被ることにもなる。いずれにしてもこれらツール類の妥当性をエンドユーザ自身で証明すること非常に難しい、できるだけツールメーカに要請するべきである。
③ 機能安全マネジメントへの要求
この要求も基本的にはフォールト導入の回避が目的である。設計プロセスにおける人的・組織的な問題を極力排除するための取り組みである。つまりこれは品質マネジメント（ISO 9001）とほぼ同様と考えてよい。すでに品質マネジメントシステムを導入しているのであれば、そのシステムをそのまま流用すれば良い。しかし品質の管理という概念と安全性の確保という概念とは全く同じではない、機能安全特有の要求は設計変更における安全度水準の維持である。つまり設計変更によって何が影響を受けるか（挙動、時間、診断率、故障確率、耐環境性能、文書類など）を見極める影響解析の実施と変更プロセスの文書化である。
定量的な要求として
④ 安全関連パラメータ（定量的数値の要求）
HFT, DC, CC, SFF, SC, PFD, PFHなど達成すべき具体的な数値の要求がある。例えば故障確率PFDやPFHなどを考えてみると算出のために構成部品の故障率λを使用するが本来それらは精緻な値ではない。ということはそれらを使った計算結果をもって厳密に安全性の合否判断をするのはおかしい。現実的に考えて安全性は明確に数値で判定できるほど単純なものではない、つまりこの確率計算結果がSILを決定づけるための大きな要素であると考えるべきではない。数値要求は規格の多数の要求事項の内の１つであって算出の必要性はあるが厳密な計算に多くの労力を費やすべきものではない。それよりはハードウェア、ソフトウェアのアーキテクチャ、診断機能、フォールトシナリオなどの検討に多くの時間と労力を費やすべきである。日本国内の機能安全関連のセミナーなどでは故障確率の計算に時間をかけるものが多いが注意した方が良い、上記の通りでその要求は全体の一部に過ぎず他にもっと重要な要求事項がたくさんある。
上記の全要求（①、②、③、④）に共通する文書化要求
安全機能の設計プロセスに関連する全情報の文書化を要求している。正確にかつ構造的な形式で記録し必ず作成者、承認者を明確にする。つまり責任者の所在を明確にすることを要求しており文書類の構成管理、履歴管理、トレーサビリティ、閲覧権限の管理方法などについてもルール化することを要求している。
４．認証プロジェクトのプロセス例
認証プロセスの概要と標準的プロジェクトの開始から認証書発行までの工程を示す。（図4参照）
4-1．コンセプトフェーズ
認証プロセスで最も慎重にそして時間をかけるべき重要なフェーズである。設計者はこのフェーズにおいて、ハードウェア安全要求仕様、ソフトウェア安全要求仕様、機能安全マネジメントシステムについて明確しその文書化が必要とある。一般的には以下の四つの文書を準備することになる。
| 1) SP: Safety Plan | 設計プロジェクトの機能安全マネジメントシステム（組織、担当責任者の適正能力、設計プロセス）を具体的に記述する。 |
| 2) V&V: Verification and Validation Plan | 設計プロセスの各フェーズでどのような検証や妥当性確認を実施するか、そしてどんなツールを使用するかについて具体的に記述する。 |
| 3) SRS: Safety Requirement Specification | どんな規格、安全度水準、安全状態、動作環境を想定しているかなど必要な安全要求仕様をブロック図レベルで記述する。 |
| 4) SC: Safety Concept | SRSを基にどのように安全機能を実現するか（特にアーキテクチャ、タイミング、診断技法、非安全関連部から安全関連部への影響回避方策など）をブロック図・状態遷移図レベルで具体的に記述する。ちなみにConceptをDesignに置き換えると理解し易い。 |
この４文書は最低限必要な文書であって、場合によってはその他補足文書が必要な場合もある。つまりこれらの文書情報より安全性に関する問題点、規格要求からの逸脱などの有無を評価検討する非常に重要なフェーズである。但し、このフェーズだけで認証されることはなく次のメインインスペクションフェーズのための事前確認の段階である。
4-2．メイン インスペクションフェーズ
このフェーズではコンセプト文書で記述されている安全仕様について実機を用いて実証試験を行う。このフェーズでの実施内容は以下の通りである。
| 1) 故障挿入試験（FIT: Fault Insertion Test） | 安全関連系の部品に意図的にフォールトを挿入し、その際の挙動・診断機能等を確認する。また集積回路の内部レジスタ、メモリに対しては意図的にエラーを挿入し診断機能の性能について実機確認を行う。 |
| 2) ソフトウェア検査 | プログラムフロー・状態遷移、コーディング、使用ツールの検査。 |
| 3) 機能安全マネジメントシステムの監査 | Safety Plan及びV&V Planの記載内容に基づく現場監査。 |
| 4) 環境試験（温度、湿度、振動、衝撃、EMC） | 規格要求に基づく環境試験、特にEMCは厳格なレベルのイミュニティ試験を実施する。一般的な環境試験との違いは設定環境下で安全機能の動作確認を実施する必要がある。 |
| 5) 安全関連パラメータの確認 | 危険側故障確率PFD, PFHや診断率DCなど数値的要素の妥当性確認。 |
| 6) 電気安全 | PCBレイアウトパターン間の絶縁・沿面距離の妥当性確認。 |
これ以外にもアプリケーションにより必要な場合は特定の試験が実施される。
4-3．認証フェーズ
コンセプト文書、安全関連のマニュアル、各種テストレポート及び安全関連パラメータの妥当性などを総合的にレビューし、目標SILの要求を満足していれば評価レポートの作成及び認証書の発行となる。認証書は認証機関ならどこでも発行可能なプライベート認証と、EU圏内で認定された通知機関（Notified Body）でしか発行できない法的効力を伴った認証（EC Type-Examination Certificate）とがあり、日本では後者のような認証書を発行できるのはテュフ ラインランドのような外資系認証機関に限られる。
最後に
機能安全認証の取得がどの程度のビジネスメリットを生み出すか、数年前までは先駆的な企業でも疑心暗鬼なところはあったようだが最近では間違いなくビジネスに繋がっている。その状況を受けてかこれまで及び腰であった企業も積極的に取り組みを始めている。しかしながら機能安全の考え方そのものに興味を持ち積極的に学ぼうというエンジニアは残念ながらまだ少数派である。一方、消極的な指示待ちタイプか、そもそも機能安全には懐疑的でできれば避けて通りたいというタイプのエンジニアがまだ多い。残念ながらこうなると適合証明に非常に時間がかかり無駄な設計に成りがちである。日本は品質向上では非常に積極的だったが安全性向上についてはあまり積極的ではない。やはり日本は強力な外圧がないと積極的になれないところは昔から変らない、ぜひ安全技術についても積極的に学び理解し取り組む風土・企業文化が醸成されてほしいものである。制御の分野は今後益々複雑化することは明らかであり、それに加えてセキュリティ対策や急速に開発が進んでいるAI（人工知能）に対し安全をどのように確保できるのかは避けられない大きな課題である。安全性を考慮したは設計とは本来どうあるべきか、それはハード・ソフト・人的要因に対し多面的な視点で考えることであり、そのためには少なくともIEC61508規格ぐらいは完全に理解しておかなければならない。
出典：「計測技術」(2016年10月号) 日本工業出版株式会社｜執筆：テュフ ラインランド ジャパン株式会社 和田昌士
お問い合わせ：インダストリー＆サイバーセキュリティ 機能安全（E-Mail: fsjapan@jpn.tuv.com）
更新日 : 2/13/2026