機能安全に取り組むときに、プロジェクトチームにまず最初に必要となるものがFSM（Functional Safety Management plan）です。システムなど「モノ」そのものに対する要件ではなく、その「もの」を生み出す組織の枠組みに対して規格が求めていることに準拠していることを示す計画書です。ここでは、IEC-61508 Part1に示されているFSMへの要件のうち、多くの会社で持たないであろう要件と対応策を説明します。前もって自分たちでギャップ分析をして対策しておけば、審査機関のチェックもハードルが低くなります。是非活用してください。

もしもその会社の持つ業務標準や技術標準の図書が、ばっちり対応していれば特に新たなルールを設ける必要はありません。基本的にはISO-9001がベースになっていますから、日本の多くの企業は基礎があると考えてよいです。

すでにある会社のルールと、機能安全IEC-61508が求める要件のギャップを明らかにすることを、FSMギャップ分析といいます。FSMをしっかり組み立てずにリスク分析や設計・評価を実施した場合、審査の際にやり直しを求められることもあり得ます。まずはどのような不足があるのかギャップ分析をして現状を把握することが大切です。

※ご注意

日本の多くの企業が持つISO-9001は工場など受注生産プロセスに関する場合が多いです。機能安全では最初にその設備や機器のリスク分析からスタートしますから、いわば初期計画や基本設計・開発のフェーズも対象となります。プロトタイプ以降の量産プロセスはばっちりでも、開発フェーズの試行錯誤の図書がぜんぜん残ってない、の場合は要注意です。

なぜ仕事の仕方が大切か

システムの信頼性を評価するとき、システマティック故障とランダム故障について評価する必要があります。SILの表にあるようなPFD・PFHという確率は部品故障や劣化などのランダム故障の故障率を用いて算出されます。一方、「設計条件がそもそも違っていた」「原理が間違っていた」「プログラムのバグ」「マニュアルの記載ミス」などを原因とする故障や障害は、ランダムに起こるものではなくその条件が満たされれば必ず発生する障害であり、仕組み自体に組み込まれたものです。

システマティック故障の排除は、とにかくしっかりしたルールできちんと作る以外に方法はありません。設計する人の力量に制約を設けたり、複数の人で設計図を評価したり、また図書の書き方に制約を設けるなどもその範囲です。

このために機能安全では最初に組織の枠組みの構築から入るのです。このことを理解していれば、ソフトウェアの外注作業での調達ルールや外注先にまで話が及ぶ理由がわかると思います。

IEC-61508 Part1　５章６章７章

Part1は全部で８章ありますが、１章～４章は定義や参照図書について書いていますから５章からが中身です。８章はアセスメントについてですが、多くの場合アセスメントは審査機関にお願いするでしょうから流します。ということで、５，６，７章が自分たちの業務標準との差をチェックすべき部分です。

7章は下記の活動に対する要件が書いてあります。どんなプロジェクトでも活動No１～No１６の全部を一度に実施するケースはないでしょうから、自分たちが今回対象とする活動の部分に注目すればいいです。プラント計画ならばNo１～No５のあたり。コンピュータシステムならばNo９，No１０が対象になります。

No12以降は運用と保守に関する部分です。これは自分たちが担当する範囲について検討しておけばよいです。ここまで絞れば、ぐっと読む気がしてくると思います。

５章　図書について

これから行う活動のルールを記載する図書と、活動の結果生み出される図書があります。両方についてのルールがFSMで決まっているのかを確認します。

活動ルールの多くは会社がすでに持つ業務標準を参照することになります。ルールの参照および不足内容の追記をまとめ、Safety Planという図書を作成しておきます。すでにある業務標準の内容を改めて書き写す必要はありません。

活動の結果生み出される図書については、この段階で図書リストを作成しておきましょう。以降の章でも図書と活動は関連付けた管理を求めています。１つの図書にいろいろと入れるのではなく、活動ごとに図書を区別することが望ましいです。その理由は本稿の最後に出てきます。

加えて審査官もチェックしやすいです。図書の名称だけではなく、図書を番号で管理できるようにしておきましょう。

図書バージョンは数字１桁よりも、1.1.1などが望ましい

構成管理のところでも記載しますが、バージョン管理を詳細に行う必要があります。多くの企業では改訂番号は数字１桁だと思いますが、できれば３つの文字や数字で管理した方がいいです。評価チームの確認一回目却下、二回目パス、審査機関が確認中など、一つの図書が複数のフェーズで進行します。できれば、1.1.1のように確定版図書とマイナー改訂回数の区別できるようにしておくことが望ましいです。

検証結果やレビューコメントもモノづくりの一部

注意点はValidation、Verification、Assessmentなどの評価検証の結果の図書もしっかり図書として番号をとって図書リストに加えて管理することです。モノ作りの現場では、レビューやチェックの結果は、メールで通知して終わっているのではないでしょうか。図書リストには検証結果（レビューコメント）も図書としてリスト化しておいてください。

 できれば図書システムがあるのが望ましい

５章では適切なDocument Controlがあればいい、という記載なのですが図書はそのまま製造出荷する製品と一体となって構成管理を行うことになります。製品を出荷した段階で（厳密に言えば、審査が完了した段階で）対応する全図書の改定を凍結し、一旦全体を一つのバージョンとして保持します。

そのあとは変更管理に移りますが、このような管理を担当者それぞれが自分のPCで管理するのはかなり無理があります。また共有サーバのフォルダーなどで保存する場合、だれがいつ変更したのか、また複数の人間が変更をしないように排他処理ができるのかなども配慮が必要です。

できればDocument Controlと承認するシステムがあれば間違いないと思います。長いプロセスの最後の最後の審査の際に、ファイルを重複変更したことが発覚すれば積み上げてきた信頼も水の泡ですから。

６章　マネージメントについて

この章で求めているのは、「責任、リーダシップと調整」「決めるべき手順」「人的資源」です。順番に見てゆきましょう。

責任、リーダシップと調整

全体の機能安全ライフサイクルをけん引する人を明確にしなければなりません。もちろん部長さんや課長さんなど組織の長であってよいのですが、より具体的に機能安全の活動に注力しリーダシップを発揮するイメージです。

これは機能安全に限らずリスクマネージメント一般にいえるのですが、リスクという不確かな予測のためにコストを払って対策を地道に行うことはとても難しいことで、経営層も含めた全員の意思がなければ成り立たないと考えられるからです。つまり気を許せば、うやむやになってしまうのです。

また活動と活動の調整（Coordinating）をするのは誰かという要件も同じ背景があります。リスク分析で必要になったアクションは別な部門の所掌という場合があります。そのような時に自分の活動範囲内しか責任を持たない人ばかりならばうまくゆきませんよね。活動を横断的に調停する事務局的な役割が不可欠です。

加えてISO-9001QMSの品質宣言と同じように、組織のトップから順に機能安全に対するポリシーを配下に表明してゆきます。

なお規格の文言からは判りずらいのですが、QMSと同じく内部監査の仕組みを求められることがあります。FSMで取り決めたルールが守られているのかどうか責任を持つ者＝内部監査員というイメージです。

決めるべき手順

リスク分析の手順（リスクマネージメント）

リスクの定義（指標の定義、マトリクスの定義）、リスクを洗い出す手法、HAZOPを用いるならばガイドワードなど、リスク分析を実施するルールを文書化しします。残存リスク（最終的に許容するリスク）についても決めておきましょう。

機能安全のアセスメント手順

外部の審査機関を用いるならばその旨明確にし、どのようなタイミングで何をアセスメントしてもらうのかあらかじめ決めておきます。たとえばここではFSMを、ここではリスク分析を、ここでは要件定義を、ここではConceptをとう風にマイルストーンや、その際に審査されるべき図書も明確に決めておきます。

またモノづくりのすべての設計図書が審査対象になるのではありません。安全に関係する部分だけです。そういう意味でも、機能安全に関する情報がどこにあり網羅されているのかを明確にしておくことが必要なのです。

Validation and Verification（V&V）の手順

Validationとは妥当性評価のことです。Verificationとは検査検証のことです。どうも日本語的に同じように思えますよね。でも区別があります。いずれも大切なのは、設計の作成した図書をきちんと懐疑的な目でチェックすることです。

Verificationはどちらかといえば「ちゃんとやるべきことをしている」ことを確認するイメージです。たとえばプログラムであれば文法の確認や上流図書との整合、閾値など定数に錯誤はないかなどです。

Verificationの手順を作成するのは比較的容易です。１つはルールの準拠です。図書のフォーマットや用語の使用方法など決められたルールを守っているかの観点、次にトレーサビリティ。上流の図書の内容と矛盾していないか、参照している要件は正しいかなどです。ソフトウェアならばブラックボックステストのように、入力値に様々な値をいれるなど数学的な試験もこの範囲です。

もしも試験要領書ならば、テストケース抽出の根拠となる要件や解析があるのかその参照番号は正しいのかなど。前述のように、閾値や固定値の根拠もチェックします。このようなチェックポイントをルールとして記載しておけばよいです。

Validationはどちらかといえば「目的に合っているのか妥当なのか」に近いです。やるべきことはやっているようだ、しかし「本当にそれで安全なのか？」という疑いの目を持つイメージです。

大元の要件に対する試験ですから最終試験に相当します。システムや設備が組合わさって全体の機能を評価できる状態になって行うものです。まずは安全システムとして大元で設定した要件はすべて満たしているのかは確認が必要です。

審査官によっては「この製品はどうあるべきか」という観点でのプラスアルファの試験、追加試験をどこまでしっかり考え抜いたかを求めることがあります。

IEC-61508の記載ではValidationは最終的な機能の妥当性を確認する支援と位置づけられていますが、「求められていることの本質を確認する」という意味では、すべての活動においてVerificationと対になるべきものだと言えます。

その場合Validationの要領はVerificationの要領のようにシステマティックな作業にはなりません。どちらかといえば、対象の活動ごとに取り決めるのが良いでしょう。たとえば故障解析ならば、自社の過去のトラブル事例と比較して網羅できているのか、という観点やプログラムならば文法規約的には間違っていなくても、将来より修正ミスが起きにくい書き方とか、誤解を与える変数名ではないなども言えそうです。IEEEのシステム設計の標準などもより良いものをつくる観点・視点として評価に用いることもよいかもしれません。

（余談ですが）

どんな分野でも設計開発の技術者は専門性が高く多くは職人気質です。上記のような観点で問題を指摘した場合、「大きなお世話だ」ともめるかもしれません。だからこそ、V&Vチームには強い意志と実行力が必要です。批評家ではなくプロジェクトをけん引する意思を持つV&Vが望ましい。機能安全に準拠したシステム開発のかなめはV&Vチームの実行力だと考えてください。設計チームはV&Vチームを信頼して尊重し、そしてV&Vは単なる批評家で終わらぬよう、改善方法も時には一緒に考えながら取り組みます。

 IEC-61508では、Assessment組織はSILのレベルにより独立性の度合いを規定しています。SIL1ならば「違った個人が」SIL3ならば「異なる組織が」という具合です。一方V&Vチームの成り立ちには特に規定がありません。しかし上記のような担う役割を鑑みると、Assessment組織と同じ枠組みでの独立性が必要だと考えています。

  構成管理の手順

 構成管理とはソフトウェアの例がわかり易いです。様々なドライバやライブラリのバージョンがあって、それらがある特定の組み合わせで試験をして出荷されてゆく場合、その組み合わせの管理のことです。これをプログラムのソースコードだけではなく、ハードウェアの回路設計、アートワークに広げましょう。そしてひいては構想設計図書、そのV&V結果、故障解析などすべての図書のバージョンまでに広げます。

たとえば１つのシステムがあったとして、これに特定のバージョンをつけるとしましょう。この代表の番号には、内部の３枚の基板と１つのソフトウェアに対するバージョンがあるとしましょう。そうなるとそれを設計した時の図書には特定のバージョンがあるはずです。

このように最終的な製品の代表バージョンから、特定の図書の特定バージョンまでがパッケージになるように管理しておき、重要な試験が完了したらその構成パッケージを凍結します。製品出荷をしたら当然凍結を保持します。

将来製品に何かあった時、その製品がどのような試験をして、どのような結果で、その試験はどの設計図書に基づいたもので、どのような技術者がV&Vしてどのようなコメントを残したバージョンなのか、それが後で特定できるようにするのが、最終的な構成管理の目標です。

また上記の例では、基板とソフトウェアのように１対のものでありながら異なる設計プロセスを経由するものは、対になるバージョンは互いにどれなのかを認識しあえる必要があります。この部分でも構成管理は必要です。

FSMでは、この構成管理についてどの部位にどのようなバージョンを規定し、どのような組み合わせで全体バージョンとするのか、またその改訂方法などをルールとして規定します。

定期監査の手順

機能安全のプロセスは定期的に監査される必要があります。対象のシステムに変更があった場合はもちろんですが、変更がなされなくても「変更がなされなくてよい」という判断を適切にしているのかの確認が必要です。

FSMで規定する手順には、製品が出荷後にトラブルを発生した場合確実にその事態の情報が把握できる仕組みがあるか、その仕組みの要領を明確にするように求めています。そのような適切な仕組みが適切に回っていて、それでもなお「製品を改良する必要はない」と判断したエビデンスが残ることが必要です。

定期監査をどんな周期でどのように行うのかをルールとしてFSMで規定しておきます。通常はISO-9001と同様、年一回の内部監査と外部監査の組み合わせとなりますが、ISO-9001とはことなり、重大な変更が発生した場合は定期監査だけではなく必要に応じて設計開発と同レベルの監査が必要になる場合もあります。その程度や度合い、どのような場合にどのような監査が必要となるのかというルールも決めておきます。

変更管理

すべての試験に合格し量産出荷した製品は図書が凍結されています。それに対して新しいプロジェクトに対して成果を流用する場合や、システムの改良をする場合は新しいプロダクトを作るためのライフサイクルを始動する必要があります。すでに市場に出ているものを変更するのですから慎重なキックオフが必要です。

対象の製品に対して加える変更が、どのぐらいインパクトのある変更なのか分析することが必要です。ずばりImpact Analysisと言います。変更管理とは、どのようなルールで変更範囲を決定するのかを予め決めておくことです。

FSMを作っているということは、まだプロジェクトを開始する前だとおもますが、その段階ですでに将来完成したあとの変更についてルールを決めておく、ということになります。

変更管理のルールは上手に決めておく必要があります。電子システムならば、些細な抵抗部品の型式変更のレベルから、初期の要件の変更や、CPUなど重大部品の変更も様々です。どのレベルの変更はどのレベルの体制で、どのレベルまでのV&VやAssessmentをするのかもあらかじめ決めておきます。

私の経験では、未来のことだからと話を先送りにせず、FSMを決める段階でしっかりシステマティックな方法を決めておくことが、将来の作業軽減につながると考えています。

 人的資源

規定したそれぞれの活動に参加するメンバーの力量の定義です。その活動に参加できるのは、どのような技量のメンバーである必要があるのかを事前に決めます。このためには力量評価の基準が必要です。

ISO-9001の認証がある組織ならば、何らかの力量評価があると思います。基本はそれでOKなのですが、その力量評価の観点に機能安全の観点が含まれているのかどうかは必要な要素です。

力量評価に加えるべきこと

各活動にそぐう評価基準が必要です。機能安全の取組みは、リスク分析・障害解析の次に、設計作業、V&V作業、Assessment作業が大分類です。よってまずはその観点での経験や知識レベルを点数などにする必要があるでしょう。できれば過去の経験やその経験時の役割・技術範囲などが明確な基準であることが望ましいと書かれています。

つまりよくある力量基準の例「○○○を一人でできる」みたいな基準はやや評価が低いと言えます。そのようなルールでもFSMの審査に合格した話はあるようですから、まずは何かのルールを決めておくことでしょう。

教育・訓練と更新

つぎに当然その技量に満たないメンバーに対する訓練の規定です。リスク分析の経験なんてそうそう普通のモノづくりの現場ではありませんから、講習やワークショップなどでの訓練などを規定します。それを受けたら技量レベルが１上がるなどのルールを決めておきます。

関係者の能力評価の記録

機能安全プロジェクトに参加するメンバーは、上記のルールに基づいて予め審査されプロジェクトの責任者により参加を許可されなければなりません。その時各メンバーを評価したエビデンスは、図書として保存しておきます。

前述の構成管理を思い出してもらえれば、遠い将来製品が市場でなにか問題を起こした際は、どのような技量の人物が何をしたのかを確認できるようにしておくためです

外部の人的資源の活用

 メンバーの雇用形態には特に注意を払う必要はありません。作り上げたFSMの下で等しく管理されるのであれば、正社員でも派遣社員でも違いなく必要な能力評価を受け教育を受ければ活動に参加できます。

ただし請負発注による人的リソース確保の場合は注意が必要です。日本の取引における請負発注（受託業務）では、独立した業務管理がなされる必要があります。もしも請負契約なのに上記の派遣社員のように、プロジェクトのFSMで管理されプロジェクトの一員として加わってしまうと「みなし派遣契約」となる疑いが出てきます。

このような場合、受託側は受託側で機能安全のプロジェクトから機能安全の仕事を請け負えるだけの組織としての能力評価が必要になります。FSMすべてではないにしろ、請け負う業務に必要な各種のルールを持つ必要が出てきます。

とはいえFSMに準じるルールを取引先に構築してもらうのは現実的な話ではありません。発注と検収の内容を工夫して、自分たちのFSMのルールで安全性を担保できる仕組みを作ることでしょう。具体的にはV&Vのチェック事項を追加するとか、個人の能力評価を取引前に行うなどのルール作りが必要でしょう。

７章　各活動の要件について

組織のフレームワークとしての準備は上記の部分で終わりです。7章からは機能安全ライフサイクルの個々の活動についての要件となります。前述の図書リストをこの活動の区切りで作って頂けたなら、この7章の要求事項は、そのまま各活動から出力される図書の要記載内容だといえます。

そこで最初に挙げた図書リスト（図書名、図書番号）に、7章で要件にされている活動内容を図書の記載事項として組み込みます。もちろん対象となる活動に対してのみで構いません。ただしシステム開発の場合は、IEC-61508 Part2、Part3にもやるべき活動が記載されていますから、そちらも参照して図書リストを作成してください。

基本的には上記のように活動＝図書ととらえ、7章の内容を図書概要に組み込めば事足りますが、図書を作成するために必要なルールはFSMで事前に規定しておく必要があります。

たとえばなにか専用ツールを用いるならば、そのソフトウェアや内部のデータのバージョンなどを明確にしておきます。

準拠する規格についても事前に明記しておき審査官に申し出ます。それによって必要な試験が規定されているかなどのチェックに結び付くからです。

PFDの計算などで、機器の故障率やシステム内部の電子部品の故障率など、引用する国際規格についてもFSMで事前に明確にしておき、審査官に確認しておくことが望ましいです。特に部品の故障率などは、引用するデータが異なると結果に大きく響きます。

以上がFSMを構築する際に、おそらくどこの会社でもギャップとして挙げられるであろう部分について解説しました。7章はターゲットにする活動によって大きく異なりますから、まずは今回記載している範囲を早々に準備し、アセスメントを依頼する認証機関に見てもらいましょう。おそらく大きな山は越えていると思います。

ぜひ今回の記事を参考にしていただき、効率の良い認証プロセスを開始してください。