これからプラント分野の機能安全に取り組む方を対象に、この規格がどのような取り組みなのかを知っていただくための連載です。要件の背景や具体的な取り組み例を知っていただき、本格的な勉強につなげていただければ幸甚です。
本記事は工業技術社月刊「計装」2017年4月号から連載した記事に一部追記し、編集部ご了解のもと掲載しています。掲載記事は本誌をご覧ください。＃5回は安全完全性という言葉の意味についてみてゆきます。
安全完全性（Safety Integrity）とは何だろう
機能安全は、「人が作り上げる安全の仕組みを、ライフサイクル全体を通し評価し維持すること。」と説明しました。人は必ず間違えるという立場に立てば、ライフサイクル全体を通しての管理運営のルール作りが必要です。それをFSMS（Functional Safety Management System）といいます。では、FSMSのもとで開発設計した安全システムが、どのぐらい安全なのか、どのように評価すればよいでしょうか。
1.信頼性と完全性
設備のリスク分析では、本質安全による安全対策が何よりも大切です。本質安全・本質的安全対策だけでは許容できるレベルにリスクが十分に下がらない場合、仕組みによる安全を検討します。その仕組みがコンピュータシステムで動作する機能である場合、その対象のシステムに必要な要件をまとめた規格が機能安全規格です。
システムの信頼性の高さは、システムが担う（軽減する）リスクの大きさに依存します。「その保護システムが、ちゃんと働かない場合」に、どのぐらいの災害につながる可能性があるのか、それが保護システムにもとめられる信頼性の目安になります。
ここで「信頼性」という言葉を使いましたが、機能安全では「安全完全性」という言葉を使います。決められた安全機能が確実に働くことに注目するからです。「信頼性」という言葉では、誤動作が少ないことなのか、長期的な保守サービスが充実していることなのかなど、商品としての全般的な価値と混同してしまいます。
機能安全で求める信頼性は、「あらかじめ想定したイザというときに、特定の安全機能が確実に働くこと」を指します。このため安全完全性という言葉を使います。この趣旨を踏まえていただければ、心中では「信頼性」と読み替えてもらっても差し支えありません。
２．目標の設定
設備機械のリスク分析から、安全機能の安全完全性の目標が決まります。目標は１～４の数値で示します。これをSIL（Safety Integrity Level）といいます。どのような（どのぐらいの）リスクに対して、SILの目標をいくつにするべきか、各分野の規格で触れられています。プラントでは、IEC 61511-3にある、表やLOPAという手法を用います。（図１）連載後半で解説します。
大切なことは、SILの目標値の主人公は「安全機能（Safety Function）」だということです。
たとえば、「〇〇タンク内の圧力が〇〇MPaより高くなれば、〇〇弁を開く」という安全機能をＡ機能とします。「〇〇熱交換器の出口温度が〇〇℃より高くなれば、燃料弁を閉じる」という安全機能をＢ機能とします。Ａ機能、Ｂ機能で異なるSILになることはあり得ます。A機能はSIL=2で、B機能はSIL=3、かもしれません。
リスク分析によって、ハザードとなる事象を洗い出し特定し、その個々の項目のリスクレベルを評価し、必要な対策を決め、その対策がコンピュータを用いた安全機能ならばSILを与えます。Excelの表ならば、１行にまとまるはずです。これが洗い出したハザードの数だけあるわけです。もちろん、安全機能が、複数のハザードの対策になっている場合もあります。できるだけ少ない安全機能で、多くのハザード項目の対策となるようにしておけば、あとあとの開発や設計の負担を軽減することができます。このため、プラント等、大規模で多くの安全機能が必要になる設備こそ、初期の設備に対するリスク分析で、安全機能を整理・統合しておくことが大切なのです。
３．SILを満たすシステムとは
安全機能に対してSILの値が決まったら、それを実現するために開発・設計を開始します。さて、そもそも安全完全性が高いシステムとは、どのようなものなのでしょうか。これが今回の主題です。機能安全では、安全完全性の高いシステムとは、２つの側面の故障が少ない（少なくなるように開発した）システムを指します。
１つは、「ランダム（ハードウェア）故障」、もう１つは「システマティック故障（系統故障）」です。
ランダム故障は、システムの電子部品に発生する劣化や単体不良などの偶発的な故障を指します。また雷によるノイズなど、外部の環境からの影響もランダム故障に含まれます。ある確率で「発生するだろう」ことは推測できるものの、「どこで（どの部品で）、いつ発生するのか」が確定しない故障です。
システマティック故障は、とても広い概念です。ソフトウェアのプログラムの記述ミス（バグ）は、典型的なシステマティック故障です。システマティック故障を「ソフトウェアプログラム固有の故障」としている解説もありますが、ハードウェア（電子回路）でも発生します。たとえばダイオードの極性の表記を、回路図で書き間違えれば、それはシステマティック故障です。また、仕様設定のミスや取扱説明書の間違いもシステマティック故障です。システマティック故障は、確率的に発生するのではなく、その間違いに関係する局面になれば、必ず故障として表面化します。
システマティック故障は人の活動に間違いの根源があります。したがって、関与する人間を厳しく管理することで低減を図ります。FSMSは、ライフサイクルを通して全体のシステマティック故障を低減するための方策の一部です。このため管理の在り方が、SILの値に応じて変化するものがあります。たとえばアセスメント（安全の評価作業）は、SILによって、個人の独立、組織の独立、と要求が厳しくなります。（図２）
４．ランダム故障に対する評価
ランダム故障は確率的に評価します。その安全機能に必要なセンサーから演算器、そして弁などのアクチュエータが、危険側故障によってちゃんと動作しないかもしれない確率を算出します。その確率の値が、SILのレベルに応じて要件（達成目標）となっています。（図３）
部品の故障は、「故障したらすぐに検知できる故障」と「故障したことがわからない故障」に分類することができます。検知できない故障は、時間とともにシステムの信頼性（安全完全性）を低下させます。つまり「ちゃんと働かないかもしれない可能性（危険側故障確率）」は、時間とともに増加するのです。これをあるレベルに抑え込むために、自己診断などの仕組みをシステムに組み込みます。これを、Safety MechanismとかSafety Measureと呼びます。
システムがどのようなSafety Mechanismを搭載しているのかは、PFD/PFHを算出するために不可欠な情報です。算出した確率が、システムに求められているSILの値よりも小さいことがランダム故障に対する評価基準となります。もう一つ、ランダム故障に関連した指標がありますが、それは別な機会に解説します。
５．機能安全の背骨
安全という極めて抽象的な達成目標を「特定の機能が確実に働く信頼性」の議論を置き換える点（話の転換）が機能安全という規格の背骨になっています。機能安全の達成が、本当の意味で設備の安全に結びつくためには、機能安全が実現しようとする「安全機能」が、設備が潜在的に持つ危険性および危険な事象（ハザード）を広く網羅的にカバーしていることが前提です。
逆にいえば、初期のリスク分析（ハザードの抽出）が十分でなければ、それは導かれる安全機能が不足していることにつながります。本当は１０個必要な安全機能があるのに、リスク分析が不十分なために、設定した安全機能が１つだけしかない場合、その安全機能を実現するシステムがたとえSIL3を達成していたとしても、その設備が「安全であるとはいえない」ことはご理解いただけるでしょう。
安全システムの安全完全性が高いから設備が安全になるのではなく、設備のリスク分析が網羅的で想定外が無いことが「前提」となって、機能安全によって実現された高い安全完全性のシステムが設備の安全性を主張する根拠となるのです。機能安全を達成したシステムが、設備を安全に導くのか、作業員がその機械やロボットを用いて安心して作業できるのか、それはシステム開発の機能安全達成の活動をスタートする前の、リスク分析、ハザードの抽出がどれだけ豊かにできていたのかに掛かっています。機能安全が設備や機械の安全性を実現する切り札（最先端）のような表現をする記事が世にありますが、切り札はあくまでもリスク分析の充実です。
同じ議論はPFD/PFH達成のための自己診断などのSafety Mechanismにもあてはまります。IEC-61508-2 Annex Aにはシステムが持つべきSafety Mechanismがまとめれていますが、それをやみくもに搭載しすればシステムの安全完全性（信頼性）が向上するのではなく、システムFMEAなどのシステムの障害解析が網羅的で充実しているのかが源流です。
リスク分析や障害解析には多くの時間がかかりますし、その一方ゴール（ここまでやればいい）や正解（これ以上はない）が明示的に決められない活動のため、「誰かがやればいい」とか「昔の先輩がやった結果をとりあえず踏襲する」と避けたくなります。一度やったら二度と振り返りたくない活動かもしれません。
しかし上記の通り機能安全だけではなく制御セキュリティにおいても源流はリスク分析です（Risk based Approach）。効率的にそして永続的に、多様性を維持しながらも属人的にならずに、定期的に繰り返し続けてゆくことが、設備や機械、そしてそれを守るためのシステムの安全完全性達成に必要なことです。
次回は、システマティック故障を低減するためのFSMSやソフトウェア作成ルールについてみてゆきます。
脚注
FSMS：Functional Safety Management System
（株）制御システム研究所は、TUV-SUDの公式パートナー／機能安全エキスパートです。