これからプラント分野の機能安全（IEC-61511)に取り組む方を対象に、この規格がどのような取り組みなのかを知っていただくための連載です。要件の背景や具体的な取り組み例を知っていただき、本格的な勉強につなげていただければ幸甚です。
本記事は工業技術社月刊「計装」2017年4月号から連載した記事に一部追記し、編集部ご了解のもと掲載しています。掲載記事は本誌をご覧ください。＃6回は安全完全性達成のためのFSM（FSMS）について解説します。
安全完全性とシステマティック故障
前回は、「イザというときにちゃんと動作しないかもしれない確率」を用いて、ランダム故障の観点での安全完全性を評価することをお話ししました。プラントや設備計装のエンジニアの皆様は、電子部品の故障率から積み上げるのではなく、機器メーカが積み上げた機器の確率や故障率を用いて評価することになります。今回は、もう一つの要因、システマティック故障に関するお話です。
１．FSMS
機能安全は、「人が作り上げる安全の仕組みを、ライフサイクル全体を通し評価し維持すること。」です。人は必ず間違えるという立場に立てば、ライフサイクル全体を通しての管理運営ルールが必要になります。それがFSMS（Functional Safety Management System）です。
FSMSは、ISO-9001（QMS：Quality Management System）と重なる部分が多くあります。QMSでは各部門に品質管理責任者がおり、定期的に社内監査がなされるでしょう。機能安全も同様です。取り決めたFMSをきちんと実施するための責任者や、監査の組織も必要です。社内の教育基準に機能安全についての講座を設け、作業を担当できるかどうかの力量評価基準も必要です。
機能安全は、設計そのものを疑う活動です。図書をVerification（検証）する作業を、すべての設計図書の出図プロセスに加えます。Verificationとは、適切な記述をしているのかを検証する活動です。その図書の上流の図書との整合性や、もともとの要件（Requirement）との一致など、一貫性や整合性、記述ルールの順守を確認する作業です。どのようなVerificationを実施するのか、それもFSMSで規定すべき項目の一つです。
設計図書管理は、容易に改ざん（先祖戻りなどの間違いも含む）されない仕組みが必要です。Verification部隊から「間違っているぞ。ココ要修正！」と返送された図書と、改訂し再度のVerificationを依頼しようとする図書のバージョン記号が、同一だとしたらどうでしょうか。ファイルの取り違えによる記述内容の先祖返り、つまり「システマティック故障」の遠因になります。
TUV-SUDでは、お客様のQMSとFSMSのギャップ分析を、機能安全プロジェクトの最初に行います。FSMSの着手が遅れ、構想設計がスタートできないケースもあります。面倒でもまずはFSM作成工程やマイルストーンを、きちんと立ててスタートしましょう。
２．FSMが必要な設計部門とは？
さて、PLCやシステムを調達し、プラントや設備を設計するエンジニアリングの機能安全で、FSMSは必要でしょうか。
IEC-62061（FA設備全体の機能安全）の改訂や、2016年のIEC-61511改訂によって、PLCに搭載するアプリケーションプログラムの管理や検証、修正なども機能安全ライフサイクルの対象作業として明確化されました。（図１）
電子回路や基本ソフトウェア（C言語などで記述する組込みソフトウェアについてはすべて「IEC-61508を参照」となりましたので、IEC-61511＝計装制御エンジニアのための機能安全規格、という性格が顕著になっています。SISを調達し、PLCのロジックを作成する計装エンジニアリングの部隊にもFSMSは必要なのです。（IEC-61511-1 6.2.1）
機能安全に対する教育や、経験などの管理を図書化して実施することは、改訂前は「Should（べき）」でしたが、改訂で「Shall（しなければならない）」に修正されています。（IEC-61511-1 5.2.2.2）加えてそのFSMSはIEC-61508-1に準拠するようにと、念を入れて記述が追加されています。（IEC-61511-1 5.2.5.2）
もっとも、落ち着いて考えてみれば、当たり前のことではあります。ジャガイモを厳格に審査し安全性を認証する話と、それを使って「カレー」を衛生的に調理する調理師の審査は別な話です。最終的には１つの「料理」として完成するといえども、それぞれの評価は別な価値判断があります。安全なジャガイモはそれ自体が価値を持ちます。調理師免許はお店の評価に不可欠です。ごっちゃにしてはならんよ、ということです。
３．アプリケーションプログラム
システマティック故障に大きく関係する要素として、図書について先ほど触れました。PLCのラダープログラムも図書も、どちらも人の手による作品ですから、システマティック故障に大きく関与する要素です。
基本的な管理の要件は同じです。先ほど触れたVerificationも同様に必要です。IEC-61508にあるようなシステムの内部を開発するソフトウェア（Ｃ言語など）では、連結するライブラリ個々のバージョンの組み合わせ管理（構成管理）や、プログラムの書き方（コーディングルール）も重要な要素です。そのほか代表的な活動に、バージョン管理と変更管理があります。
PLCのラダープログラム（以下ロジックと呼ぶこととします。）でも、バージョン管理、構成管理や、変更管理は必要です。ロジックのバージョン管理は、設計図書の先祖返りを防ぐ話と同じです。制御システムが複数のPLCで構成されているのならば、ある試験を実施した時点、または引渡時点の、各PLCのロジックのバージョンが各々どうだったのかが大切になります。これは構成管理です。
変更管理とは、ロジックの変更を実施する手順です。機能安全の変更管理では、変更前の活動が重要です。その変更が安全にどう影響するのか評価をしてから、実際の関連する図書やロジックを変更します。影響度分析（Impact Analysis）といいます。（図２）
重要な点は、影響度分析の結果によっては、最初に行ったリスク分析に戻る点です。リスク分析や障害解析は「プロジェクトの初期に１回だけ」行えばよいというものではありません。本連載の＃３回に引用した爆発事故を例にしてお話しした通り、変更や修正が必要になるたび、初期の活動に立ち戻らねばなりません。
このために、初期のリスク分析時のディスカッションの内容はきちんと維持管理されている必要があるのです。そうしなければ、設備の計画時に行ったようなHAZOPなどのリスク分析を、最初からやり直さなければならなくなります。リスク分析の結果は、「リスクが高い」という結果だけを残しておくのではなく、その際に出た意見のうち「リスクが低い」と結論付けた結果も含め、ディスカッション全体を記録しておくことが大切です。初期のリスク分析だけではなく、システム設計時のFMEAやFMEDAなどの障害解析も同様です。
これはプラントにおける機能安全だけではなく、自動車や鉄道などすべての分野の機能安全に共通します。電子部品の生産中止による改造や、PLCなどの製品の世代交代などが安全に影響する機能安全では、リスク分析はライフサイクルとして製品や設備を使用する期間に継続的に維持されるべきものなのです。言い換えれば、機能安全の活動においてリスク分析の維持管理をおざなりにすることは、機能安全ライフサイクルの背骨を失うことと同義ともいえます。
安全にかかわる変更ではないのか、新たなリスクを生まないか、安全要件のどこを修正するべきなのか、その結果、どのような図書を改訂し、検証および試験（VerificationやValidation）をやり直すのか、あらかじめ全貌を把握してから、関係者で合意して実施します。機能安全は、リスク分析をベースにした設計開発のプロセスです。(IEC-61511-1 18.2.3)
上記に加え、IEC-61511-1の17章（SIS Modification）17.2.6には、「Modification（変更）の活動は、FSA（Functional Safety Assessment）がおわるまで、修正作業に着手してはならない」と書かれてあります。次回はFSAについてみてゆきます。
脚注
FSMS：Functional Safety Management System
(1) IEC, “IEC 61511-1 Ed 2.0 Functional safety – Safety instrumented systems for the process industry sector –Part 1: Framework, definitions, system, hardware and application programming requirements,” Feb. 2016.
(2) IEC, Functional safety of electrical/electronic/programmable electronic safety-related systems –Part 1: General Requirements, IEC 61508-1 Ed 2.0, Apr. 2010.
（株）制御システム研究所は、TUV-SUDの公式パートナー／機能安全エキスパートです。