皆さん、こんにちは。 ITアーキテクトの pppgana です。

前回の記事「機能安全とITシステム - クラウド型ガス漏れ検知器の例」では、家庭用ガス漏れ検知器をAWS上で実装するという思考実験の舞台を設定し、IEC 61508（JIS C 0508）の安全ライフサイクルのうち①ハザード分析・リスクアセスメント（IEC 61508 安全ライフサイクルのフェーズ1〜3）をなぞりました。

ハザード分析・リスクアセスメント（フェーズ1～3）では、ハザードの特定もリスクの見積もりも設計者の分析・判断の作業でどのような実装でも行うフェーズです。今回は"クラウド型”として実装しますので、クラウド障害が危険側故障の原因になりうること、サイバー攻撃による誤遮断・漏れの隠蔽の可能性など、クラウド型独自の初期事象を洗い出しました。

今回は、その続きとして②安全要求仕様・SIL割当（フェーズ4・5・9）に進みます。ハザード分析の結果から実際にSILを導出し、達成すべき定量目標を確定します。そして、その先で見えてくるクラウド型として実装する際の考慮事項にも触れていきます。

おさらい：思考実験の前提

前回整理した前提を、簡単に振り返っておきます。

EUC：各家庭のガス配管設備
EUC制御系：既設のガスメーター・マイコンメーター
E/E/PE安全関連系（今回の検討対象）：IoTゲートウェイ内蔵型ガス漏れ検知センサー、AWS上の判定ロジック（IoT Core・Lambda・DynamoDB）、IoTゲートウェイ内蔵型ガス遮断器
フェールセーフは現場の遮断器が自律的に担う（クラウドは「最後の砦」ではない）

安全ライフサイクルの5つの塊のうち、今回扱うのは②です。

①ハザード分析・リスクアセスメント：フェーズ1〜3（前回）
②安全要求仕様・SIL割当：フェーズ4・5・9（← 今回）
③設計・実装：フェーズ10
④検証・妥当性確認：フェーズ13
⑤運用・保守・変更管理：フェーズ14〜16

②安全要求仕様・SIL割当（フェーズ4・5・9）

前回洗い出したハザードから、実際にどれだけリスクを下げる必要があるかを見積もり、それを安全機能とSILに落とし込みます。

フェーズ4・5：全安全要求事項とその割当て

規格が求めること（JIS C 0508-1 7.5.1〜7.5.2、7.6.1〜7.6.2）

フェーズ4「全安全要求事項」の目的は、潜在危険及びリスク解析の結果から、必要な安全機能とその安全度を導き出し、これを仕様化することです（7.5.1）。ここで重要なのは、この段階で決まるのは、「全安全要求事項」の名の通り、システムを構成する個々のコンポーネントに対するSILではなく危険事象そのものに対する全体のリスク低減量だという点です。

規格（7.5.2.4）は、これを「許容リスクを達成するために必要なリスク軽減」または「許容リスクを満たすための許容危険事象率」のいずれかの観点で定めるとしています。
規格の言い方がすこしわかりにくいのですが、前者は「今のリスクを何分の1に下げる必要があるか」という軽減の倍率の観点で言及しており、もうひとつは「その危険事象は年間何回以下に抑えるべきか」という目標の頻度そのものを言っています。

フェーズ5「全安全要求事項の割当て」は、この全体の要求を、指定されたE/E/PE安全関連系や他リスク軽減措置に個別に割り当てるフェーズです（7.6.1.1）。各E/E/PE安全関連系が実施する安全機能ごとに、目標機能失敗尺度とそれに付随するSILがここで初めて割り当てられます（7.6.1.2）。

つまり規格は「全体の必要リスク低減量を決める」→「それを個々の系に分担させる」という2段階構造を取っています。規格では、この割当てのパターンがいくつか示されており、他リスク軽減措置とE/E/PE安全関連系が組み合わさって全体のリスク軽減を分担する形も、単一のE/E/PE安全関連系に全体を割り当てる形も、どちらも許容されます。「全安全機能は、複数の安全関連系にまたがって割り当ててよい」と明記されています。

ただし、複数の防護層に分担させてよいのは、それらが独立していると言える場合に限られます。規格（7.6.2.7）は独立とみなすための条件を挙げています。防護層間で故障が同時に起こる可能性が要求安全度に対して十分低いこと、機能的に異なっていること、異なった技術に基づくこと、共通の部品・電源などの供給システムを用いないこと、共通の運用・保全・テスト方法を用いないこと、です。これらを1つでも満たさない場合、規格（7.6.2.8）はその防護層を独立として扱うことを禁じ、共通原因故障を考慮した割当てを求めます。この「独立性」の考え方は、次回扱う共通原因故障（CCF）の議論の前提となります。今回は「共通原因故障(CCF)」というキーワードのみ記憶にとどめておいてもらえればと思います。

本稿での対応

安全機能の定義はシンプルです。「ガス漏れを検知したら、遮断弁を閉じる」。この安全機能を、前回定義したE/E/PE安全関連系（センサー・クラウド判定ロジック・遮断器）に割り当てます。

問題は「どれだけ信頼できる必要があるか」、つまりSILの決定です。ここからがフェーズ4・5の本題ですが、その前に確認しておくべきことがあります。

運用モードの確認（SIL決定の前提として）

規格（JIS C 0508-5 附属書A.5.0）は、安全機能の運用モードを、作動要求頻度に応じて低頻度作動要求モード・高頻度作動要求モード・連続モードの3つに区分しています。そして、どのモードかによって目標とする機能失敗尺度が変わります。低頻度作動要求モードなら ”PFDavg”（作動要求あたりの危険側機能失敗平均確率）、高頻度作動要求モードまたは連続モードなら "PFH"（単位時間あたりの危険側故障頻度）となります。

これは些細な違いではありません。これから使うSIL決定手法──リスクグラフ法もLOPAも──は、この運用モードの選択を暗黙の前提にしています。特にLOPAは「初期発生頻度（回/年）」「許容頻度（回/年）」という年あたりの事象数で計算を組み立てますが、これは低頻度作動要求モードのPFDavgの枠組みそのものです。もし高頻度・連続モードであれば、年あたりの事象数ではなく単位時間あたりの故障率（PFH）で計算し直す必要があり、以下で行うLOPAの数式はそのままでは成立しません。

そこで、SILを決定する前に運用モードを確認しておきます。第2回で触れたとおり、ガス漏れ検知システムは普段は待機しており、ガス漏れという滅多に起きない事象のときだけ作動します。これは低頻度作動要求モード（Low Demand Mode）に該当すると言えそうです。

この前提のもとで、以下のリスクグラフ法・LOPAはいずれもPFDavgを目標とする計算として進めます。

SILをどう導くか：リスクグラフ法

JIS C 0508-5（IEC 61508-5）の附属書Eには、SILを決定するための代表的な手法としてリスクグラフ法が示されています。4つのリスクパラメータの組み合わせから、必要なSILを導く方法です。
規格（附属書E.1）はこの手法について、定性的にも定量的にも用いることができるとしていますが、本稿でこれから使う表E.1ベースの使い方は定性的な方法に位置づけられます。各パラメータ（C・F・P・W）を数値ではなく段階（C1〜C4など）で選び、その組み合わせから直接SILを読み取る形だからです。

この「定性的」という性質には、規格自身が注意点を添えています（附属書E.3）。パラメータの選択が主観的になりやすく、かなりの判断が必要になること、そして残存リスクをパラメータ値の知識から数値として計算することはできない、という点です。数値で裏付けたい場合は、パラメータを校正（数値と紐付け）する必要がありますが、その校正には別途プロセスが要ります。本稿では校正を行わず、素朴な段階選択によるリスクグラフ法を使います。

規格の表E.1に定義されているパラメータを、今回のガス漏れ検知システムに当てはめてみます。

パラメータ	定義（規格）	クラウド型ガス漏れ検知システムの評価
C（危害の程度）	C1=軽傷〜C4=多数の死亡	爆発・中毒は複数の死亡に至りうる → C3
F（暴露頻度・時間）	F1=まれに〜F2=頻繁に〜永続的に	居住空間に人が継続的に滞在 → F2
P（回避可能性）	P1=条件によって回避可能 / P2=ほとんど不可能	匂いなどでガス漏れを認知できるため条件付きで回避可能と仮定 → P1
W（発生確率）	W1=低い〜W3=比較的高い	通常の設備管理を前提に → W2

Pパラメータの解釈が、実は最大の分かれ目です。ガス警報器が設置されていて在宅中であればP1（条件によって回避可能）に寄りますが、就寝中や長時間の不在を重視すればP2（ほとんど回避不可能）に寄ります。この前提の置き方次第で、後続のSILが変わってきます。まさに規格が指摘する「パラメータの選択が主観的になりやすい」という性質が、ここに表れています。

C3・F2・P1・W2という組み合わせをリスクグラフに当てはめると、

上図より、

目標：SIL 2

という結果が導かれます。

上記結論について2つ補足します。

ひとつは、規格自身が「校正済みリスクグラフはSILを保守的に（高めに）出す傾向がある」と明記していることです（JIS C 0508-5 附属書B.4）。各パラメータの範囲を最悪値で校正するため、平均的なアプリケーションでは実際に必要な水準よりSILが1段階高く出ることがある、というわけです。

もうひとつは、規格の序文にある一文です。「この規格群はいかなる安全機能についてもSILへの要求事項を規定することはなく、SILを決定する方法についても規定することはない」。つまりSILは規格から自動的に決まる数字ではなく、リスクアセスメントの前提次第で変わる、設計者の判断の産物だということです。

SIL決定の手法はリスクグラフ以外にもある

JIS C 0508-5には、リスクグラフ法（附属書E）以外にもSILを決定する手法がいくつか示されています。附属書Bには、これらの手法をどう選ぶかの指針がまとめられています。

附属書	手法	特徴
附属書D	定量的方法	許容リスクと現状リスクを実数値で見積もり、必要なリスク低減率からSILを導く。厳密だが故障率データが要る
附属書E	リスクグラフ法	C・F・P・Wの4パラメータの組み合わせでSILを導く。定性的で扱いやすいが保守的に出やすい
附属書F	防護層解析（LOPA）	初期発生原因の頻度と、既存の防護層（基本制御系・警報など）のリスク低減効果を掛け合わせ、必要な追加SILを半定量的に求める
附属書G	危険事象の過酷度行列	結果の過酷度と発生頻度を行列（マトリクス）に当てはめてSILを直接読み取る

規格（附属書B.1）は、どの手法を使うかは適用分野や状況によって異なるとしたうえで、複数の手法を併用してもよいと述べています。具体的には、まず簡易な手法でふるい分けを行い、そこでより高いSILの必要性が見えた場合には、別のより厳密な手法で確認する、という使い方です。

これは実務でもよく行われる進め方です。そこで本稿でも、リスクグラフ法で導いたSIL 2を、もう一つの手法「LOPA（防護層解析）」で確認してみます。

LOPAで確認する

LOPA（Layer of Protection Analysis）は、化学プラントなどで広く使われる半定量的な手法です。考え方はシンプルです。ある危険事象について、それを引き起こす初期原因の発生頻度と、その原因が実際に事故に至るのを防いでいる既存の「防護層」のリスク低減効果を掛け合わせ、それでもなお許容できないリスクが残るなら、その差分を新たな安全機能（SIS）に割り当てる、というものです。

今回のガス漏れ検知システムに当てはめてみます。数値は実データがないため、あくまで思考実験のための仮の見積もりであることをお断りしておきます。

影響事象・過酷度水準

影響事象は「ガス漏れによる爆発・中毒」で、複数の死亡に至りうる過酷度（リスクグラフのC3に相当）です。このクラスの事象に対する許容頻度を、仮に

許容頻度：10⁻⁴ / 年

と置きます。

初期発生原因とその頻度

配管の劣化・接続部の緩みなどによるガス漏れの発生頻度を、仮に

初期発生頻度：0.1 / 年（10年に1回程度）

と見積もります。

既存の防護層

新たに検討しているクラウド型検知システムとは別に、既存のガスメーター（マイコンメーター）には、異常な流量を検知して自動的に遮断する基本的な安全機構が組み込まれていることが一般的です。これを基本制御系（BPCS）に相当する防護層とみなし、そのPFDavgを仮に

既存防護層（マイコンメーターの異常遮断機能）：PFDavg = 0.1

とします。

中間結果の計算

既存の防護層だけを考慮した場合の残存頻度は、

0.1（初期発生頻度）× 0.1（既存防護層のPFDavg）＝ 0.01 / 年（10⁻²/年）

これを許容頻度（10⁻⁴/年）と比較すると、

10⁻² ÷ 10⁻⁴ ＝ 100倍

まだ100倍のリスク低減が不足しています。

必要な追加SIL

この不足分を、今回検討しているクラウド型ガス漏れ検知システム（E/E/PE安全関連系）に割り当てます。必要なPFDavgは、

10⁻⁴（許容頻度）÷ 10⁻²（既存防護層後の頻度）＝ 10⁻²

つまり、新たな安全機能に要求されるPFDavgは10⁻²以下。これは第2回で見た表に照らすと、

SIL 2（PFDavg 10⁻³以上10⁻²未満）

に該当します。

規格の割当てパターンとの対応

このLOPAの計算は、実は先ほど確認した規格の「全体→個別割当て」という構造そのものをなぞっています。全体の許容頻度（10⁻⁴/年）という全体の要求を出発点に、既存の防護層（マイコンメーターの異常遮断機能、EUC制御系側）と、新設のE/E/PE安全関連系（クラウド判定システム）という2つの層に分担させ、それぞれに個別のPFDavgを割り当てています。これはIEC61508-5 (JIS C 0508-5) の附属書Fで解説されている割当てパターンのうち、複数の防護層が組み合わさって全体のリスク軽減を分担する形に対応しています。

ただしこの分担が成立するには、2つの層が規格（7.6.2.7）の言う「独立」の条件──機能的に異なること、異なった技術に基づくこと、共通の部品・電源等を用いないこと──を満たしている必要があります。マイコンメーターの機械式・電子式の遮断機構と、クラウド上のソフトウェア判定は技術的に異なるため機能的独立性は主張しやすい一方、両者が同じ家庭の同じ電源から給電されている場合、共通原因故障の可能性が残ります。この「独立とみなせるか」という問いは、次回扱う共通原因故障（CCF）の議論に直結する論点です。ここでは、既存防護層と新設システムを単純に独立と仮定して計算を進めていることを明示しておきます。

リスクグラフ法との一致

リスクグラフ法とLOPA、異なる手法で導いた結果が、どちらもSIL 2という同じ着地点に収まりました。もちろん、これは今回仮に置いた数値同士がたまたま整合するように選んだ側面もあります。実務では、双方の前提（パラメータの解釈やデータの精度）が本当に妥当か、という検証にこそ意味があります。しかし、二つの異なる考え方から同じ目標にたどり着いたことは、この思考実験の前提として「SIL 2」を採用する根拠を、いくらか補強してくれるものだと思います。

なお、リスクグラフ法のPパラメータをP2（ほとんど回避不可能）と置けばSIL 3に上がりえますし、LOPAの初期発生頻度や既存防護層のPFDavgの見積もりを変えれば結果は当然変わります。本稿ではP1・上記の仮の数値を採用し、SIL 2を思考実験の目標として置くことにします。この前提の妥当性そのものを深掘りする議論は、本稿の主旨から外れるため、ここでは深入りしません。

フェーズ9：目標PFDavgの確定

規格が求めること（JIS C 0508-1 7.10.1〜7.10.2）

フェーズ9「E/E/PE系安全要求仕様」の目的は、各E/E/PE安全関連系に割り当てられた安全機能要求事項及び安全度要求事項を、詳細な仕様として規定することです（7.10.1）。この仕様には、安全機能の内容だけでなく、達成すべき定量的な目標値（SILに対応するPFDavgまたはPFH）が含まれます。

本稿での対応

SIL 2（低頻度作動要求モード）から、達成すべき定量目標が確定します。第2回で見た表を再掲します。

安全度水準	PFDavg（低頻度作動要求モード）
SIL 4	10⁻⁵ 以上 10⁻⁴ 未満
SIL 3	10⁻⁴ 以上 10⁻³ 未満
SIL 2	10⁻³ 以上 10⁻² 未満
SIL 1	10⁻² 以上 10⁻¹ 未満

本稿の前提（Low Demand・SIL 2）から、達成すべき目標は

PFDavg：10⁻³ 以上 10⁻² 未満

です。「作動要求が来たときに、1000回に1回未満しか失敗しない」という目標が、これで数字として確定しました。

ここで一点、今回のようなクラウド型システムに特有の含意を補足しておきます。規格（7.6.2.10）は、1つのE/E/PE安全関連系が異なるSILの複数の安全機能を実行する場合、実施上の独立性を示せない限り、その共有部分は最も高いSILの要求事項に従わなければならない、としています。今回想定しているクラウド判定システムは、多数の家庭の判定を同じLambda・DynamoDB基盤で処理する設計です。もし将来、家庭によって目標SILが異なる（例えばSIL 2の家庭とSIL 3の家庭が混在する）場合、共有される基盤全体がSIL 3相当の要求に従う必要が出てきます。これは、クラウドの「集約による効率化」というメリットと、機能安全の「独立性」という要求がぶつかる論点であり、頭の片隅に置いておきたいところです。

クラウド型特有の考慮事項：「可用性」と「安全性」は違う

「目標PFDavg 10⁻³〜10⁻²を達成した」と主張するには、それを計算で示さなければなりません。そしてその計算には、E/E/PE安全関連系を構成する各要素──センサー、AWS上の判定ロジック（IoT Core・Lambda・DynamoDB）、遮断器──それぞれの「危険側故障率 λ 」が必要です。本来はこれらすべての要素の故障率を積み上げて、はじめて系全体のPFDavgを計算できます。

このうち、センサーや遮断器は現場に設置する物理機器なので、メーカーが公表する故障率データ（FIT値など）を入手できる可能性があります。しかし、AWSのマネージドサービス（IoT Core・Lambda・DynamoDB）の危険側故障率といった数値は、私がしうる限りAWSから公開されていません。

「AWSの各サービスはSLAが定義されているじゃないのか？」と思われるかもしれません。しかしここに、ITと機能安全の世界の、最初の、そして本質的な考え方の違いがあります。

可用性は「安全度」ではないのです。

第1回で取り上げた、崖っぷちを走るバイクの思考実験を思い出してください。「滅多に壊れないが、壊れたときにどちらに倒れるか分からないバイク」と、「よく止まるが、止まるときは必ず安全側に倒れるバイク」。機能安全が問うのは後者の性質です。

99.95%の可用性は「システムが動いている時間の割合」を示しているにすぎません。それは「壊れにくさ」の指標であって、「壊れるとき、危険側に倒れる頻度」とはまったく別の話です。PFDavgの計算に必要なのは後者──危険側故障率 λ──であり、可用性SLAからこれを導くことはできません。

AWSの内部実装はブラックボックスです。マネージドサービスが「どう壊れるか」の危険側故障率を、私たちは知る術を持っていません。系を構成する要素のうち、クラウド部分だけが、この時点で計算に入れられないのです。

つまり、

「目標PFDavg 10⁻³〜10⁻²を「証明」するためのλが、系の一部（クラウド部分）だけ手に入らない。クラウドという実装形態を選んだ以上、なにがしか解決する必要がある」

という考えるべき壁にぶつかります。

まとめと次回予告

今回は、思考実験の②安全要求仕様・SIL割当（フェーズ4・5・9）を見てきました。

リスクグラフ法を使い、C3・F2・P1・W2という前提のもとでSIL 2を導いた。ただしSILは規格が自動的に決める数字ではなく、リスクアセスメントの前提次第で変わる判断の産物である
低頻度作動要求モードの前提から、目標PFDavg（10⁻³〜10⁻²）が数字として確定した
目標を「証明」しようとした場合、クラウド上で行う判定ロジックの危険側故障率λが手に入らないという、クラウド型として実装する際に固有の考慮事項が明らかになった。その根底には「可用性≠安全性」という、ITと機能安全の本質的な指標の違いがある

今回見てきた範囲で、安全を実現する度合いの目標が立ちました。「作動要求あたり1000回に1回未満の失敗確率」という数字です。しかし、それをどう達成し、どう証明するのかは、次回以降じっくり考えていこうと思います。

次回は、安全ライフサイクルの③設計フェーズに踏み込みます。単一の構成では目標に届かないとき、”冗長化”という手段があります。そこで登場するのが「MooNアーキテクチャ」、そして冗長化を考えるうえで見落とせない「共通原因故障（CCF）」と「危険側故障が検知されうるかどうか」の概念です。冗長化したはずのシステムが、なぜ同時に機能を失うことがあるのか。クラウドという実装形態は、その問いにどう向き合えるのか、次回検討していきたいと考えています。