機能安全IEC61508について(2)

定性的な要求として

①　ハードウェアへの要求

ハードウェアアーキテクチャの決定においては、目標SILとフォールト発生時に安全側となるフォールトの割合 (SFF) からアーキテクチャの制約を課している。つまりフォールに対し安全機能の動作する仕組みを１チャンネル構成あるいは多重チャンネル構成のどちらで実現するのかを判断しなければならない。たとえば安全機能を１チャンネル構成で設計した場合、目標SILを達成するためには高性能で高頻度の診断機能が必要となる。それに対し多重チャンネル構成で安全機能を実現する場合、診断機能の設計は比較的楽にはなるが部品コスト、実装面積の増大が問題になる。要するに、フォールトに対してどんな技法を軸に設計するかである。高診断もしくは冗長のどちらに重点をおいた設計にするかを十分に意識することである。また、”Idle current principle” という要求がある、これは安全状態というのはidle状態にて達成する、つまり供給電源が停止した状態でも達成されるような設計でなければならない。

また、一般的に良く使われているフェイルセーフの考え方は61508規格では方策として明示的には使用しない。理由はフェイルセーフの仕組みそのものが非安全関連部の一部に依存していることが多いためである。その場合はフェイルセーフ動作そのものが保証されないことになる、これはフェイルセーフの数を増やせば解決するわけでもはなく根本的な問題である。

②　ソフトウェアへの要求

ソフトウェアへの要求は定性的な内容であって現時点では数値的指標による定量的要求というものは示されていない。だがソフトウェア開発プロセスでのフォールト導入の軽減手段の一つとしてソースコードの複雑度の管理（つまり、複雑にしない）の要求がある。その指標としてよく使われるのが循環的複雑度（通称：McCabe）で数値的な指標として使うことができる。ソフトウェアの全般的な要求事項はソフトウェア設計プロセス内で導入されるフォールトを可能な限り排除するということである。その方法として要求しているのが明確な開発プロセスの定義・分類とマネジメントである。規格書にはVモデル開発を示しているがこれは要求意図を理解するためのガイダンスと考えた方がよい。アジャイル型設計であってもソフトウェア安全要求仕様をトレースできる仕組みが確立されれば良いわけである。要するに重要なことはソフトウェアに求める安全要求仕様への正確なトレースである。特に診断機能には十分な検討が必要で診断機能のほとんどはハードウェアとソフトウェアのコンビネーションで実現されことからハードウェア性能・限界を良く理解したソフトウェア開発が必要である。そしてソフトウェア開発で使用するツール類に関しても厳しい要求がある、特に実行コードを直接生成するコンパイラ等は妥当性が十分に証明されその結果が文書化されていなければならない。妥当性が証明されていないツールの使用は非常にリスクが大きい、なぜなら問題のあるツールを使用すると製品がフィールドに出てから初めて製品の不具合が顕在化することになり、非常に大きな損害を被ることにもなる。いずれにしてもこれらツール類の妥当性をエンドユーザ自身で証明すること非常に難しい、できるだけツールメーカに要請するべきである。

③　機能安全マネジメントへの要求

この要求も基本的にはフォールト導入の回避が目的である。設計プロセスにおける人的・組織的な問題を極力排除するための取り組みである。つまりこれは品質マネジメント（ISO9001）とほぼ同様と考えてよい。すでに品質マネジメントシステムを導入しているのであれば、そのシステムをそのまま流用すれば良い。しかし品質の管理という概念と安全性の確保という概念とは全く同じではない、機能安全特有の要求は設計変更における安全度水準の維持である。つまり設計変更によって何が影響を受けるか（挙動、時間、診断率、故障確率、耐環境性能、文書類など）を見極める影響解析の実施と変更プロセスの文書化である。

定量的な要求として

④　安全関連パラメータ（定量的数値の要求）

HFT, DC, CC, SFF, SC, PFD, PFHなど達成すべき具体的な数値の要求がある。例えば故障確率PFDやPFHなどを考えてみると算出のために構成部品の故障率λを使用するが本来それらは精緻な値ではない。ということはそれらを使った計算結果をもって厳密に安全性の合否判断をするのはおかしい。現実的に考えて安全性は明確に数値で判定できるほど単純なものではない、つまりこの確率計算結果がSILを決定づけるための大きな要素であると考えるべきではない。数値要求は規格の多数の要求事項の内の１つであって算出の必要性はあるが厳密な計算に多くの労力を費やすべきものではない。それよりはハードウェア、ソフトウェアのアーキテクチャ、診断機能、フォールトシナリオなどの検討に多くの時間と労力を費やすべきである。日本国内の機能安全関連のセミナーなどでは故障確率の計算に時間をかけるものが多いが注意した方が良い、上記の通りでその要求は全体の一部に過ぎず他にもっと重要な要求事項がたくさんある。

上記の全要求（①、②、③、④）に共通する文書化要求

安全機能の設計プロセスに関連する全情報の文書化を要求している。正確にかつ構造的な形式で記録し必ず作成者、承認者を明確にする。つまり責任者の所在を明確にすることを要求しており文書類の構成管理、履歴管理、トレーサビリティ、閲覧権限の管理方法などについてもルール化することを要求している。