これからプラント分野の機能安全（IEC-61511)に取り組む方を対象に、この規格がどのような取り組みなのかを知っていただくための連載です。要件の背景や具体的な取り組み例を知っていただき、本格的な勉強につなげていただければ幸甚です。
本記事は工業技術社月刊「計装」2017年4月号から連載した記事に一部追記し、編集部ご了解のもと掲載しています。掲載記事は本誌をご覧ください。＃7回はFSAについて解説します。
FSA（Functional Safety Assessment）
前回は図書やアプリケーションプグラムに必要な、Verificationについてお話ししました。IEC-61511-1の17章（SIS Modification）17.2.6には、「Modification（変更）の活動は、FSA（Functional Safety Assessment）がおわるまで、修正作業に着手してはならない」と書かれてあります。今回はFSAとはどのような活動か見てゆきます。
1. FSAチームの構成や役割
上流の図書との整合性や要件からの一貫性、あらかじめ規定したルールの遵守などを、各図書（活動のアウトプット）に対して検査する活動を、前回Verificationと呼びました。これはどちらかといえば「決めた仕事をしたのか」という確認です。それに対しFSAは、有識者による審査の位置づけです。（IEC 61511-1 5.2.6.1.1）対象アプリケーションの技術的な知見、運用経験などを踏まえて精査する活動です。
FSAのメンバーは、各活動から独立していることが求められます。設計フェーズでは、そのプロジェクトの設計者本人は加わらないことを求めています。（IEC 61511-1 5.2.6.1.2）FSAのメンバーとして厳しい条件は設定されていません。対象のプロセス、アプリケーションに対する経験があるシニア技術者という設定です。
Verificationとの違いを鑑みれば、「このリスク分析のハザード抽出は少ないのではないか」とか「この安全機能の要件は抽象的すぎないか」など、安全ライフサイクルの全体を見越した、活動の不十分さを指摘することがFSAのメンバーに期待される役割です。
企業において実際は、複数のプロジェクトが同時進行していることでしょう。FSAだけに限りませんが、このようなメンバーをプロジェクトごとに固有に持つことは求めていません。設計部隊と独立性が担保できるのであれば、プロジェクト横断的に専門部隊を保有することでも構いません。必要な時に適宜、TUV-SUDのような認証機関に、Assessment Serviceをアウトソーシングするのも有用です。
FSAを実施する目安として、5つのステージが示されています。（図１）設備のリスク分析を終えた後、SISを設計した後、最終的な現場の据え付け試運転あとなどが実施のタイミングです。
２．FSA活動の継続性
FSAで確認すべき項目は、リスク分析や要件の定義からはじまる一連の活動や、FSAからの指摘事項の設計への反映状況、SISの最終的な評価試験の要領書など、機能安全としての背骨となるような活動に抜けがないか、活動全体を俯瞰してチェックすることが目的です。（IEC 61511-1 5.2.6.1.5）
連載の第３回目で取り上げた、インドJaipurの爆発火災＊１では、設備運用中の改造が、事故の拡大を防げない遠因になりました。その冒頭に示した、「Modification（変更）の活動は、FSA（Functional Safety Assessment）がおわるまで、修正作業に着手してはならない」（IEC 61511 17.2.6）は、そのような運用や保守のフェーズでの改造にあたってのFSAについて示しています。
このため、FSMS＊２に記載するFSAの計画の中では、運用や保守の段階でどのようにFSAを実施するのか、定期的なFSAにどのように取り組む計画なのか、必要ならば運転員や保守員への教育についても決めておくことになります。（IEC 61511-1 5.2.6.1.5）
このような計画をFSMSとして図書にすることで、プラント引き渡し後の運用や保守フェーズも含めた安全ライフサイクルの維持を目指します。
３．SISの設計とエンジニアリング
IEC 61511では2016年の改訂で、C言語で書くような組込みソフトウェアは範囲外（IEC 61508マター）となりました。ラダープログラムやファンクションブロックダイアグラム（FBD）のような制限言語での制御保護の回路記述を、アプリケーションプログラムと称して作業への要件を明確化しています。（IEC 61511-1 12. SIS application program development）
SISを構築するためには、アプリケーションプログラムの作成の前に、要件を明確にする必要があります。（IEC 61511-1 10. SIS safety requirements specification (SRS) ）ここで求められているのは、設備やプラントのリスク分析から導かれる、安全機能を実現するための必要条件を明確にすることです。安全機能の定義とは、センサー（S)、演算部（L)、アクチュエータ（A）それぞれがどのように動作するべきなのかを定義します。またそれらの機能が働くための全体条件や環境条件、達成すべき安全完全性のレベルなども、SRSを構成する要素です。
たとえば入出力信号に必要な計測レンジや精度はもとより、共に実施するProof TestのInterval、Safety Timeの規定（ハザードの検知から安全状態に移行するまでの許される時間の規定）などです。この規定は、機材の更新やセンサーの変更など、のちのち変更管理（Modification）をする際に実施するImpact Analysisの作業根拠になります。
前述のアプリケーションプログラムで実現すべき機能をまとめたものは、アプリケーションプログラム要件として、採用するシステムのアーキテクチャに基づいて記述します。（IEC 61511-1 10.3.5）アーキテクチャに基づくとは、ロジック回路の説明だけではなく時間的な動作シーケンスなど、前述の要件を満たすための数値的な制限を明確にします。たとえば必要な演算時間は、記載する回路のボリュームに依存するPLCを選定したならば、その制約を明確にします。
構築したSISは据付後評価試験で確認します。（IEC 61511-1 15. SIS safety validation）Validationとは、最初に設定した要件（SRS）を適切に実現しているのかを確認する試験です。プラント現地で実施する、警報や保護システムの試験、ユニットインターロック試験が対応します。SRSではおそらく反応時間が規定されているでしょう。その場合は模擬信号発生から動作までの時間計測もします。最初に決めた要件を実際の機材で確認するのがValidationです。もちろん試験に加えて、リスク分析や安全機能要件などの図書がそろっていることも確認します。
Validationでは、保護機能としての確認のほかデータの過負荷、冗長化部位の切り替えなど、システムの異常時の挙動も確認するような記述が追加されています。しかし現地の試験でシステムの故障を細かく模擬確認することはあまり現実的ではありません。今回の改訂で、FAT（Factory Acceptance Test）の実施が必須となりました。その結果を参照することができることになっています。
FATやValidation試験が適切に行われたかどうかを確認するFSAのタイミングが（図１）のStage-2およびStage-3に相当します。安全ライフサイクル全体の観測がFSAチームの役割ですので、FSAチームがリスク分析や安全要件など、プロジェクトで作成された図書に基づき、SISシステムが適切に構築され、各種評価試験が適切に行われたかを確認します。
以上のようなFSAの活動は、すべてFSMSで規定することになります。規定したFSMSと規格にギャップがないか確認する作業を、Functional safety auditと今回の改訂で呼ぶようになりました。略するとFSAになりややこしいですね。
前回に引き続き今回も、「人がつくる仕組み」に潜在するシステマティック故障の低減のための、FSMS、FSAなどの活動についてご説明しました。次回からはランダム故障の低減について解説してゆきます。
＊１：2009年のインドRajasthan州Jaipurのタンクターミナルの爆発火災。
作業員のバルブ操作の間違いでガソリンの漏洩が開始された。流出を遮断する電動弁があったが、利便性のため現場近くに操作パネルが移設されていたため、漏洩発覚後も遮断できず事故を拡大したと指摘されている。
＊２：IEC 61511改訂版では、FSMS（Functional Safety Management System）と称しているため、FSMSという呼称を用いる。これまでの連載で使用してきたFSMと同義である。
脚注
FSMS：Functional Safety Management System 機能安全に取り組むプロジェクトの活動の全貌を示した仕組み（およびそれを規定する社内標準群）。ISO 9001におけるQMS（Quality 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の公式パートナー／機能安全エキスパートです。