これからプラント分野の機能安全（IEC-61511)に取り組む方を対象に、この規格がどのような取り組みなのかを知っていただくための連載です。要件の背景や具体的な取り組み例を知っていただき、本格的な勉強につなげていただければ幸甚です。
本記事は工業技術社月刊「計装」2017年4月号から連載した記事に一部追記し、編集部ご了解のもと掲載しています。掲載記事は本誌をご覧ください。＃9回は共通要因故障について解説します。
安全完全性の高いシステムの構築
本質的な安全設計で作り上げた安全や保護の仕組みと異なり、コンピュータや通信で実現した安全の仕組みは、２つの観点で信用ならないことをお話しました。システマティック故障とランダムハードウェア故障です。機能安全規格で対峙することになる領域です。前者は厳格なマネージメント体系を事前に取り決め、それを着実に遵守し不信頼の低減を狙います。後者は電子デバイスの故障の仕方を洗い出し、対策を機能仕様として盛り込みます。安全機能がちゃんと動かないかもしれない可能性を確率（PFD/PFH：危険側不動作確率）で表し、目標のレベルになるまで自己診断機能などの故障対策を組み込んでゆきます。今回は目標のPFD/PFHを達成するための多重化ついてお話しします。
1.多重化の効果を損なわせるもの
システムの信頼を向上させるため、サブシステムを二重化や三重化で構成することがあります。機能安全規格でもセンサー、ロジック演算部、アクチュエータそれぞれを多重化して評価するアプローチが示されています。多重化した際には、２種類の故障について考慮することが必要です。共通要因故障（CCF：Common Cause Failure）と潜在故障（Latent Failure）です。この２つは多重化の効果を低くしてしまう困った故障です。
「多重化したすべてに同時に発生する故障」を考えてみましょう。ここでは二重化したシステムを考えます。両方のサブシステムが同時に危険側に異常になれば、システム全体が危険な状態になっていると考えることができます。この瞬間に設備で緊急事態が発生すれば、このシステムが担う安全機能を働かせることができません。
２つのサブシステムが共に異常となる故障の原因として、「同じ原因で故障が発生」というケースと「異なる原因の故障が発生」というケースがあります。共通要因故障とは、名前の通り前者に分類される故障です。１つの故障が複数のサブシステムの障害となるケースです。このような故障が多重化の効果を低めることは納得できます。今回は共通要因故障について考えてみます。
2.共通要因故障
共通要因故障は２つの分類できます。
（図１）１つはシステマティック故障に基づくもの、もう１つはランダムハードウェア故障に基づくものです。前者はプログラムのバグなどが相当します。設計仕様が初めから間違っていたというのも当てはまるでしょう。ダイオードの極性を図面で書き間違えて製作してしまったシステムを単純に二つ用意し多重化した場合、ある特定の電圧で両方のサブシステムが同時に破損するかもしれません。システマティック故障とは人の行為に根差す故障ですから、ソフトウェアだけではなく、ハードウェアの設計間違いも含まれます。
では後者のランダムハードウエア故障、つまり劣化やノイズの影響は共通要因故障にならないのでしょうか？ そんなことはありません。極端な環境ストレスがあると、ランダムハードウェア故障も共通要因故障になる可能性があります。
たとえば両方サブシステムの電源を１つの電源タップから分離していた場合、雷サージの影響で両方が同時に壊れることもあるでしょう。本来は異なるタイミングで発生するはずの部品の劣化も、腐食性ガスなど極めて劣悪な環境では、完全に同時とまでいかずとも、修理や対処をする十分な時間がないという意味で、「おおむね同時に」壊れることもあるかもしれません。極端な環境ストレスに対応するには、設置環境（設置場所）を変えることで対処しなければなりません。
2.ネットワーク接続と共通要因故障
近年不可欠な制御セキュリティ（IoTセキュリティ）を鑑みた場合、ネットワークで接続するということは、その行為自体が共通要因故障発生源となります。
たとえばパケットストームというネットワーク障害があります。ルータなどのネットワーク装置も電子部品でできています。特にイーサネットの両端の部品（NIC：ネットワークインターフェースチップ）は、パソコンでもネットワーク機器でも同じようなICでできています。50歳以上の方はイーサネットのハブといえばコイルやトランスをイメージするかもしれませんが、現代のハブは正式にはネットワークスイッチと呼ばれ、NICで信号をデータ化して処理するコンピュータです。このNICが故障した場合、ネットワークに無用なデータパケットを大量に送信してしまうことがあります。これがストームです。
無用なパケットといっても、ネットワークに接続している受信側のコンピュータのNICは、受信すると直ちに管轄のCPUに割り込みを発生させ、受信したパケットの処理を依頼します。このため無効なパケットといえども大量に到来すると、制御システムやパネルコンピュータの処理速度に影響を与える可能性があります。DoS[1]攻撃のような現象です。
初めからネットワーク接続をした状態での運用を想定した制御システムでは、通信処理で割り込みを受けるCPUと、制御演算をするCPUを分離します。しかし、もともとも保守のためだけに使う想定のイーサネットポートを、「ここにつなげば、運転中のデータが吸い上げられるぜっ！」とばかりに、システムの運用開始後に改造して「お手軽にIoTしちゃった」場合、パケットストームの影響を受ける可能性は高くなります。
ネットワークを用いて制御システムや保護システムを結びつけることは、機能安全的に言えば共通要因故障の可能性を高めることにほかなりません。このためIEC 62443に基づくマネージメント計画や、リスクアセスメントを通し、ネットワークを分離階層化（Defense in Depth）することが不可欠になります。
3.多重化における共通要因故障の影響
IEC 61508 Part6 Annex D[2]には、サブシステムの共通性を評価するスコア表が提示されています。Yes／Noで答えてスコアを合計し、共通要因故障の割合を算出することができます。現実のシステムすべて当てはまるわけではありません。自分たちでどのような共通要因故障があるのかを分析することも大切です。
システムのPFD/PFHの算出では、多重化部分には共通要因故障割合を考慮します。（図２）「β（ベータ）ファクタ」と呼称します。たとえば、10 FIT（FIT：故障率１０-9/hr）のサブシステムが2つある場合、共通要因故障率はβ×10 FITあると考えます。前述のAnnex Dでは、センサーなどのβは、1％（0.01）から10％（0.1）としています。
同じ製品を単に２つ用意しただけでは、10％でしょうか。サブシステム１つあたり10 FITならば、1 FITが共通要因故障だと考えます。これは結構大きな数値です。共通要因故障（図２の点線部）は図の通り直列で加わるため、1 FITがそのままシステム全体の故障率に加算されます。
このβというパラメータに数学的な根拠はありません。βが表したいことは、二重化しても全体が二乗で小さくなるわけではないという点です。SILの階段はPFD/PFHが10倍1/10倍になっていますから、単純な多重化ではSILを1段階すらあげることができない、という設計思想を表現したものがβです。つまりセンサーやアクチュエータを単に２つ買ってきて並べても、それほど信頼性（安全完全性）は高まりませんよ、ということです。
多重化したシステムを開発している方にとって、両系ダウンというのは考えるだけでもぞっとする事態ですが、開発者人生では何度か経験するはずです。二乗で信頼性が高まるはずがないことは、経験則でも当てはまると思います。
多重化の効果を引き出すには、共通性がないもので多重化する、すなわち多様化（Diversity）が必要です。機能安全規格の重要な思想的柱の一つです。成り立ちや設置環境にDiversityがあれば、共通要因故障は小さくなるという考え方です。IEC 61508 Part6 Annex D[2]のスコア問答表では、サブシステムの共通性を様々な観点で問う構成になっています。
カッコよく聞こえますが、多様性を実現するには多大なコストがかかります。CPUや処理アルゴリズムを多様化すれば、設計やプログラミングを完全に複数回実施することとなります。電子部品を多様化すれば、量産効果に影響を与えるだけではなく、製品化直後の初期不良も複数倍経験することになります。多様性をどこまで図るか（許容するか）、純粋にそれは支払えるコストとのトレードオフ、経済の問題だともいえます。
次回は多重化の効果を低めてしまうもう一つの故障、潜在故障について取り上げます。
脚注
[1] DoS攻撃（Deny of Service）インターネットのホームページなどのサーバに対して、パケットを大量に送ることで正規の受信処理を妨げるセキュリティ攻撃。インターネットでは人が悪意をもって行うが、制御ネットワークでは機器が故障して同様な状況を引き起こすことがある。
[2] IEC, “IEC 61508-6 Ed 2.0 Functional safety of electrical/electronic/programmable electronic safety-related systems –Part 6: Guidelines on the application of IEC 61508-2 and IEC 61508-3,” Apr. 2010.
（株）制御システム研究所は、TUV-SUDの公式パートナー／機能安全エキスパートです。