皆さん、こんにちは。

鉄道のお客様を担当して以来"安全"をITでどう担保するかに興味を持ち、国際規格を中心に色々勉強していますITアーキテクトの pppgana です。

前回の記事「機能安全とITシステム - クラウド型ガス漏れ検知器の例 (2) 」では、②安全要求仕様・SIL割当 (フェーズ4・5・9) を扱いました。リスクグラフ法とLOPA、性質の異なる2つの手法で確認した結果、目標は

SIL 2 (低頻度作動要求モード) 、目標PFDavg：10⁻³以上10⁻²未満

と確定しました。そして最後に、クラウド型として実装する際の考慮事項が見えてきました。E/E/PE安全関連系を構成する各要素のうち、センサーや遮断器は故障率データを入手できる可能性がある一方、今回構成するAWSの各サービス (IoT Core・Lambda・DynamoDB) の危険側故障率は公開されていないという点です。

今回は、安全ライフサイクルの "③設計・実装 (フェーズ10)" に進みます。「目標は立った。ではどう達成するか」という問いに向き合う回です。

おさらい：ここまでの前提

前回まで整理した前提は以下の通りです。

EUC：各家庭のガス配管設備
EUC制御系：既設のガスメーター・マイコンメーター
E/E/PE安全関連系：IoTゲートウェイ内蔵型センサー、AWS上の判定ロジック (IoT Core・Lambda・DynamoDB) 、IoTゲートウェイ内蔵型遮断器
フェールセーフは現場の遮断器が自律的に担う
目標：SIL 2 (Low Demand) 、PFDavg 10⁻³〜10⁻²未満

また、これまで以下の①～②のステップを見てきました。今回は③の設計・実装のフェーズに進みます。

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

フェーズ10：E/E/PE安全関連系の実現

フェーズ10「E/E/PE安全関連系：実現」の詳細な要求事項は、第1部ではなく「IEC 61508-2 / JIS C 0508-2 (ハードウェア要求事項) 」と「IEC 61508-3 / JIS C 0508-3 (ソフトウェア要求事項) 」に規定されています。第1部にはこのフェーズの存在と全体ライフサイクル上の位置づけが説明されており、具体的な設計要求はIEC 61508-2 / JIS C 0508-2 (ハードウェア要求事項) 」と「IEC 61508-3 / JIS C 0508-3 (ソフトウェア要求事項) 」に委ねるという構成です。

「全体」の目標を「各パーツ」に配分する

前回確定した目標PFDavg (10⁻³〜10⁻²、SIL2) は、E/E/PE安全関連系「全体」に対する目標でした。センサー、クラウド判定ロジック、遮断器を合わせた系全体としてこの数字を満たさなければならないというものです。

この「全体としての目標」を、個々のコンポーネント (サブシステム) にどう配分するかという工程が、今回の「③設計・実装：フェーズ10」の趣旨となります。

規格 (IEC 61508-2 / JIS C 0508-2 の 7.2) は、この配分の出発点として、安全機能を次のようなサブシステムに分解することを例示しています。

センサー (入力を担うサブシステム)
ロジックソルバー (判定を担うサブシステム)
アクチュエータ (出力を担うサブシステム)

今回のシステムに当てはめると、下図の赤色点線のような割り当てとなります。

そして規格は、各サブシステムのSILを決めるために、ハードウェア安全度 -- ランダムハードウェア故障に対する安全度 -- と、決定論的安全度 -- 決定論的原因故障 (システマティック故障) に対する安全度 -- の二つの軸に対して、それぞれ別に満たすことを求めています (7.4.2.2) 。ハードウェア安全度と決定論的安全度は、それぞれ達成すべき要求事項も、複数の要素を組み合わせるときの規則も異なります。この2つの軸の中身は、ロジックソルバーを掘り下げる次の節で詳しく見ていきます。＜上記で記載した、 "ランダムハードウェア故障" や "決定論的原因故障 (システマティック故障) " って何だったっけ？という方は、本ブログシリーズの第二回を見ていただければと思います＞

ここまでを踏まえ、「③設計・実装：フェーズ10」で取り組む内容は以下と定義できそうです。

「クラウド型ガス漏れ検知器の安全性をSIL2で満たすために、システムを構成するセンサー、ロジックソルバー (クラウド判定) 、遮断器のそれぞれは、単独でSIL2相当の水準を主張できるだろうか。」

本記事ではセンサー、ロジックソルバー (クラウド判定) 、遮断機のうち「ロジックソルバー (クラウド判定) 」部分にフォーカスして議論していこうと思います。

ガス漏れセンサーや遮断弁はエッジ側で従来の組み込み機器の技術によって実装されるコンポーネントで、機能安全の世界で長年実績のある領域であると想定できます。一方、この構図の中で唯一新しい要素である「ロジックソルバー (クラウド判定) 」部分は、事例が少ない領域で、まさにクラウドを使った実装で必要となるSILを達成できるのか、できないとしたら何がその妨げになるのかが、本ブログシリーズの核心です。

以降はこのロジックソルバー部分に焦点を絞って検討します。センサー・遮断器側の議論は、本稿では割愛していますのでご了承ください。

規格が定める5つの要求事項

規格 (7.4.2.2) は、E/E/PE安全関連系の設計が満たすべき要求事項を、a) から e) まで5つ挙げており、そのすべてを満たすことを求めています。

a) ハードウェアの安全度要求事項：アーキテクチャ上の制約 (7.4.4) と、ランダム故障の影響を定量化するための要求事項 (7.4.5)
b) 特殊なアーキテクチャ要求事項：オンチップ冗長を持つ集積回路 (IC) 等への要求 (附属書E)
c) 決定論的安全度及び／又は決定論的対応能力の要求事項：3つの適合ルートのいずれかで満たす
d) フォールト検出時のシステム動作の要求事項 (7.4.8)
e) データ通信プロセスの要求事項 (7.4.11)

この5つのうち、今回の思考実験に特に関わってくるのが a) と c) です。

a) はこの後取り上げる、MooNアーキテクチャや、HFT (ハードウェアフォールトトレランス) 、SFF (安全側故障割合) に関係する要求事項となります。 c) は、主にソフトウェアで実装される決定論的安全度に関する規定となり、ハードウェア部分とソフトウェア (ファームウェアやOS) 部分がパッケージングされてサービス提供される "クラウド" を考えるうえで重要な項目となります。

なお、e) の「データ通信プロセスの要求事項 (7.4.11) 」も、クラウド型のシステムにとっては本来見過ごせない項目です。センサーからクラウドへ、クラウドから遮断器へと、判定に関わるデータがネットワークを介してやり取りされる以上、通信の誤り検出・伝送エラー時の扱いは、まさにこの思考実験の核心に関わる論点です。ただし、この要求事項は通信の「タイミング」 (最悪応答時間の保証など) とも深く関係しており、④検証・妥当性確認 (フェーズ13) でクラウドの応答時間の不確実性を扱う際に、改めて正面から取り上げたいと思います。

a) ハードウェア安全度

構成部品に応じたタイプ定義 (タイプA/タイプB)

規格は、安全機能を構成する要素の特徴に応じ、タイプAとタイプBに分類しています (7.4.4.1.2、7.4.4.1.3) 。

タイプA：構成部品すべての故障モードが十分に定義されており、フォールト状態下の動作を完全に決定でき、検出できる／できない危険側故障率について十分に信頼できる故障データがある要素
タイプB：上記のいずれかを満たさない要素 (一つ以上の構成部品の故障モードが十分に定義されていない、動作を完全には決定できない、あるいは信頼できる故障データが不十分)

ざっくり言えば、タイプAはヒューズのように「壊れ方がすべて分かっている枯れた部品」、タイプBは「壊れ方が完全には把握しきれない、複雑またはブラックボックス的な要素」というイメージです。マイコンやソフトウェアを含む複雑な要素は、多くの場合タイプBに分類され、今回取り上げる「ロジックソルバー (クラウド判定) 」も "タイプB" に分類されそうです。

安全度を証明するためのアプローチ (ルート1Hとルート2H)

ハードウェアが目標とする安全度水準 (SIL) を満たしていることを証明するためのアプローチ方法としてルート1H・ルート2H (7.4.4) の二つが定義されています。

ルート1Hは、各要素の安全側故障割合 (SFF) とハードウェアフォールトトレランス (HFT) を、規格に掲載されている表に照らし合わせて、主張できる最高SILを求める方法です。タイプB は以下となります (IEC 61508-2 / JIS C 0508-2 の表3) 。

SFF＼HFT	0	1	2
60%未満	許容しない	SIL1	SIL2
60%以上90%未満	SIL1	SIL2	SIL3
90%以上99%未満	SIL2	SIL3	SIL4
99%以上	SIL3	SIL4	SIL4

また、複数のサブシステムを組み合わせたときの規則も定められています (7.4.4.2.3、7.4.4.2.4) 。

直列に組み合わせた場合 (センサー→ロジックソルバー→遮断器のように一本道でつながる場合) 、全体で主張できるSILは、最も弱いサブシステムのSILで決定される
並列に組み合わせた場合 (冗長チャンネルの場合) 、ハードウェアフォールトトレランスの数だけSILを底上げできる。

「一番弱い箇所が全体の足を引っ張る」というのが直列構成の宿命であり、それを補うために冗長化 (並列構成) が必要になるという理屈です。これが、後ほどStep 3で見るMooNアーキテクチャの、規格上の直接の根拠になります。

ルート2Hは、SILごとに要求される最小HFTを規格が直接指定した上で、フィールドフィードバックや規格に基づくデータ収集、専門家判断といった信頼性データを用いてランダムハードウェア故障の影響を定量化する方法です (7.4.4.3.3) 。

冗長化構成 (MooNアーキテクチャ) について

MooNアーキテクチャのMooNとは「M out of N」の略で、N個のチャンネルのうち、M個が正しく機能を果たせば、そのタスク (安全機能) は正しく遂行されたとみなすという構成を表す記法です。正式な定義はIEC 61508-4 / JIS C 0508-4の略語表 (表1) にあり、詳細な使い方はIEC 61508-6の附属書Bに規定されています。

たとえば上図の2oo3は「3つのチャンネルのうち、少なくとも2つが正常に稼働していればサブシステムとしても正常動作する構成」です。今回のような「危険を検知したら遮断する」トリップ系においては、「チャンネルが正しく機能を果たす」とは「そのチャンネルが危険を正しく検知・報告すること」を意味します。そのため、以降の本稿では実務上分かりやすい言い方として「N個のチャンネルのうち、M個が危険を検知したら安全動作する」という表現も使いますが、これは規格の一般的な定義 (M個が正しく機能する) を、トリップ系というこの思考実験の文脈に当てはめたものだとご理解ください。

先ほど確認したルート1Hの並列規則、「並列に組み合わせた場合、ハードウェアフォールトトレランスの数だけSILを底上げできる」という規則を、実際のアーキテクチャとして具体化したものが、まさにMooNです。HFTが0 (単一チャンネル、1oo1) ではSIL2しか主張できない場合でも、チャンネルを増やしてHFTを1・2と上げていけば、表3に従ってより高いSILを主張できる、という理屈が、MooNという構成の背景にあります。

1点注意ですがこの図におけるチャネルの多重化は、Webシステムなどで構成される「水平スケーリングクラスター」など、ITの冗長構成とは全く別の考え方の冗長構成となりますのでご注意ください。

c) 決定論的安全度

c) は、次の3つの適合ルートのいずれかを満たすことで達成できるとされています。

ルート1S：決定論的原因フォールトの回避・管理という、開発プロセスの厳密さで対応するルート (7.4.6・7.4.7、詳細はIEC 61508-3 / JIS C 0508-3)
ルート2S：使用実績による証明 (proven in use) というルート (7.4.10) 。十分な運用実績がある要素は、内部構造を厳密に解析しなくても、証拠文書によって安全性を認めてよいという考え方で、証拠の一つに「以前の使用において危険側故障率を超えていないこと」が求められます (7.4.10.2 b) )
ルート3S：既存ソフトウェア要素だけに適用される特別ルート

決定論的安全度側の達成度を表す指標が、「決定論的対応能力 (SC：Systematic Capability) 」です。SCは、IEC 61508-4 / JIS C 0508-4 (用語及び定義、3.5.9) で定義されています。「SC 1〜SC 4」という、SILと同じ4段階の尺度であり、ある要素が SC_n_ を持つとは、「その要素が、SIL_n_ の決定論的安全度を満たしていることを示す」ことを意味します。

コラム
より正確性を期すため説明を加えますと、IEC 61508-4/JIS C 0508-4 の3.5.10で「SILは安全機能全体を特徴付けるものであり、個別のサブシステムや要素はSILを持たない」と定めています。 SILはあくまで安全機能全体に付与されるものであり、個々のソフトウェア要素が持つのは、正確にはSCです。

この原則はソフトウェアに限った話ではなく、ハードウェア要素にも同様に当てはまります。 a) のハードウェア安全度においても、7.4.4のルート1H/2Hで定まるのは「主張できる最高SIL」という言い方が正確な言い方のようです

つまり、ハードウェア要素もソフトウェア要素も、どちらも「要素それ自体はSILを持たない」という同じ原則のもとにあり、それぞれ別の指標 (ハードウェア側は表2・表3で決まる主張可能SIL、ソフトウェア側はSC) で評価される、という対称的な構造になっています。

決定論的安全度側にも、ハードウェア側の並列規則と対をなす合成規則があります (7.4.3「必要な決定論的対応能力を達成するための要素の合成」) 。

7.4.3.2には、ある要素の決定論的原因フォールトが単独では安全機能の故障を引き起こさないが、同じくSC n のもう一つの要素と組み合わさったときにだけ故障を引き起こす場合、「十分な独立性が存在するなら、その2要素の組み合わせをSC (n+1) として扱ってよい」、と規定されています。

これを身近な例で考えると、ダブルチェックに似ています。1人がミスをしても、もう1人が違う視点で見ればミスに気づける、というのがダブルチェックの効果です。ただし、もし2人が同じマニュアルを使い、同じ思い込みを共有していたら、2人とも同じミスを見逃す可能性があります。ダブルチェックが本当に効くのは、2人が独立した視点・独立したやり方でチェックしている場合だけです。ただし、この底上げは一度きりです。合成前の要素はN＝1、2、3のいずれかで、組み合わせでSC2〜4まで底上げできますが、2度、3度のと要素を重ねてもSCを向上させることはできません (こちらもダブルチェックの効能に似てますね) 。

このように、ハードウェア側の冗長化 (HFTを積む) と対をなす形で、システマティック (ソフトウェア的) な対応能力の側にも「独立性のある要素を組み合わせて底上げする」という発想が、規格上、別建てで用意されています。この点は、後ほどStep 4で異種実装 (diverse redundancy) を扱う際に、改めて重要な意味を持ってきます。

ロジックソルバー (クラウド判定) の安全度検討

ここまでで、ハードウェア安全度・決定論的安全度という2つの軸と、それぞれの適合ルートが揃いました。これをクラウドというシステムに当てはめるにあたって、クラウドの責任共有モデルにもとづくレイヤー構造を考えてみましょう。

責任共有モデルで、クラウドを二層に分ける

AWSをはじめとする各クラウド事業者には「責任共有モデル (Shared Responsibility Model) 」という考え方があります。セキュリティを「Security of the Cloud (クラウド基盤そのもののセキュリティ、クラウド事業者の責任) 」と「Security in the Cloud (クラウド上に構築するもののセキュリティ、利用者の責任) 」に分けるモデルです。

今回検討するロジックソルバー (クラウド判定) も同じ発想で整理してみます。

Layer 1：Safety of the Cloud (クラウド基盤そのものの安全性、AWSの責任範囲)
Layer 2：Safety in the Cloud (クラウド上に構築するものの安全性、利用者の責任範囲)

Layer 1：Safety of the Cloud

Layer 1 はAWSの基盤そのもの (各クラウドサービスそのものを構成する物理サーバー、ネットワーク機器、Dyanmo DBやIoT Coreが用いているOS) で、私たちにとって完全にブラックボックスとなる部分です。さらにLayer1 には以下2つの性質が混在していると考えられます。

Layer 1a：物理インフラ (サーバープロセッサーやメモリー、ストレージ) 部分で、物理的に摩耗・劣化するランダムハードウェア故障の対象となります
Layer 1b : AWSが開発・運用するソフトウェア (Lambdaランタイム、ハイパーバイザー、OSなど) 部分で、決定論的原因フォールト (バグ) の対象となります

Layer 1a の物理レイヤーにおけるハードウェア安全度は、AWSから安全側故障割合 (SFF) が公開されない限りルート1Hで決めることはできません。一方、ルート2Hの考え方「フィールドフィードバックのような信頼性データに基づいて、ランダムハードウェア故障の影響を定量化する」ことは議論できる余地がありそうです。

同様に、Layer 1bにおいてもルート2S「使用実績による証明 (proven in use) 」の考え方を借りることにより、議論できそうに見えます。

Layer 1a、Layer 1b とも、現在の規格に従う限り 「ルート2H、ルート2Sの考え方に立脚することにより、安全度を証明しうる余地がある」 という言及にとどまりますが、以下Step1~Step4でクラウドの特徴を入れたアーキテクチャ洗練を行うことにより、この言及を強化していこうと思います。

Layer 2 : Safety in the Cloud

Layer 2 は今回我々が構成するクラウド上の判別ロジックそのものです。ここには”ハードウェア”といった要素が出てこないため、決定論的安全度のみを考慮して検討することになります。また、Layer 1b でとったルート2Sは「実績のある既存の要素」に適用される項目です。Layer 2は今回新しく構成するクラウド判定ロジックなので、取り得るルートはルート1Sのみとなりそうです。ルート1Sで考慮すべきことは開発プロセスの広大な範囲に及びますが、ここではLambda上で動く判定ロジックをどの言語で書くかという観点で規定をなぞってみましょう。

プログラム言語に関する規定はIEC 61508-3 / JIS C 0508-3 の附属書A 表A.3「ソフトウェア設計及び開発－支援ツール及びプログラミング言語」で、次の技法・手段が挙げられています。

技法及び手段	SIL1	SIL2	SIL3	SIL4
適切なプログラミング言語	HR	HR	HR	HR
厳密に型付けしたプログラミング言語	HR	HR	HR	HR
言語サブセット	ー	ー	HR	HR
認定したツール及びトランスレータ	R	HR	HR	HR
HR＝High Recommended、強く推奨。 R＝Recommended、推奨

「厳密に型付けしたプログラミング言語」は、SIL1〜4のすべてでHR (強く推奨) です。「言語サブセット」 (使用可能な文法・機能を制限すること) はSIL3・4でのみHRとされており、本稿の目標であるSIL2では必須ではありません。
この表を踏まえるとLambdaの実装言語として、Lambdaが標準でサポートするランタイムだとGo言語やC#などの型付けプログラミング言語を採用することが良さそうです。

ルート1Sの検討としてプログラミング言語の選定のみ軽く触れましたが、ルート1Sで考慮すべきことは設計方法などソフトウェア開発に関係するほぼすべてに及びます。長くなるのでそのあたりの検討は本稿では省略されていることに留意ください。

ロジックソルバー (クラウド判定) のアーキテクチャ検討

ここからは、前回確定した目標PFDavg (10⁻³〜10⁻²未満) を、実際にどう達成するかを、アーキテクチャをステップ毎に育てながら考えていきます。

Step 1：まずは単一チャンネル (1oo1) から

思考実験の出発点として、ロジックソルバー部分の最もシンプルな構成を置きます。

[ガスセンサー] → [判定ロジック（クラウド）] → [遮断弁]  
     入力 ×1              判定 ×1               出力 ×1

センサーが1つ、判定ロジックが1つ、遮断弁が1つ。冗長性のない構成です。この構成の弱点は明らかです。どこか1箇所が危険側に故障すれば、ガス漏れをそのまま見逃してしまいます。 単一系のままでは、目標PFDavgに届く見込みは薄いはずです。

「では冗長化すればいいのでは？」という考えに進む前に、一度立ち止まって、そもそも「故障」とは何かを分解しておく必要があります。

Step 2：故障を4つに分ける (λdd / λdu)

ある機器の故障率 (λ) は、2つの軸で4種類に分けられます。

	検出できる	検出できない
安全側の故障	λsd	λsu
危険側の故障	λdd	λdu

安全設計で主役になるのは、危険側の2つです。

λdd (危険側・検出できる)：故障してはいるが、自己診断でそれに気づける状態です。気づけるので、フェールセーフ動作 (遮断・アラーム・縮退) に移行できます。
λdu (危険側・検出できない)：故障していることに、システム自身が気づいていない状態です。次にガス漏れが起きたとき、初めてそれが露見します。これが最も避けたい故障です。

ここから、診断カバレッジ (DC) という指標が導かれます。

DC = λdd ÷  (λdd + λdu)

危険側故障のうち、自己診断で捕まえられる割合です。DCを上げるということは、λduをλdd側に移すことに他なりません。PFDavgの計算に主に効いてくるのは、実は捕まえられない側のλduです。診断を強化してλduを減らすことが、SIL達成の中心的な戦略になります。

この考え方を、Step 1の構成に組み込むと、図はこう育ちます。

[ガスセンサー] → [判定ロジック（クラウド）＋自己診断] → [遮断弁]

判定ロジックの中に「自己診断」という機能が追加されました。診断はλduを減らせますが、単一系のままでは、λduをゼロにはできません。 気づけない故障が起きたとき、それを補う相手がいないからです。ここで初めて、冗長化の必要性が動機として立ち上がります。単独のチャンネルでSIL2相当に届かないのなら、どのようにチャンネルを組み合わせれば届くのか。ここからが、いよいよMooNアーキテクチャの出番です。

Step 3：冗長化する (MooNアーキテクチャ)

「前提の整理」で確認したMooNアーキテクチャを、実際にこのシステムのロジックソルバー部分に当てはめてみます。ガス漏れ検知器なら「N個のセンサー系のうちM個が『漏れ』と判定したら遮断する」という構成です。ここで問題になるのは、NとMをどう選ぶかです。

N=2の場合を考えます。

1oo2：2つのうち、どちらか1つでも「漏れ」と判定すれば遮断します。

[Ch-A]─┐  
       ├─ OR ─→ [遮断弁]  
[Ch-B]─┘

2oo2：2つとも「漏れ」と判定して、初めて遮断します。

[Ch-A]─┐  
       ├─ AND ─→ [遮断弁]  
[Ch-B]─┘

同じ2チャンネルなのに、合意の条件を変えるだけで、性質が正反対になります。

1oo2：どちらか1つが見逃しても、もう1つが拾えば遮断できる。見逃し (危険側故障) に強い。ただし、どちらか1つが誤検知しただけで遮断してしまう。誤遮断 (安全側故障) には弱い。
2oo2：両方が一致しないと遮断しない。誤遮断には強い。しかし片方が見逃すと、遮断されない。見逃しには弱い。

第1回で扱った「安全側故障・危険側故障」という区別が、ここでMooNの設計選択として鮮やかに立ち現れます。安全性を優先するか、可用性 (誤遮断の少なさ) を優先するか、そのトレードオフをMを何にするかで調整しているわけです。

もう一段上の構成が 2oo3 (3チャンネルのうち2つが一致したら遮断、多数決) です。1チャンネルの見逃しにも、1チャンネルの誤検知にも、ある程度耐えられる、バランスの取れた構成として知られています。

ここまでは「チャンネルを何個並べ、何個の合意で動かすか」という、MooNそのものの設計でした。しかし、チャンネルをただ並べただけでは終わらない問題が、次に待っています。

Step 4：冗長化しただけでは終わらない (共通原因故障)

ここまでの議論には、一つ大きな勝手な前提（検討漏れ）があります。各チャンネルは故障する場合は互いに独立して故障するという前提をおいて議論しており、共倒れになるリスク要因について検討が抜けています。

現実には、複数チャンネルが同時に倒れることがあります。各チャネルを構成する機構の電源が遡ると同一変電所に依存していた場合、その変電所の障害が共倒れのリスクとなります。また、同じ設計のプロセッサー、同じソフトウェアを使っている場合、設計やソフトウェアに潜んでいたバグが同時に発現する可能性があります。さらに、各チャネルが同じシャーシに入っていると宇宙放射線などによるビットエラーが同時に発生する可能性も拭えません。これらの共倒れを引き起こす原因による故障が「共通原因故障 (CCF) 」です。CCFが起きれば、1oo2だろうと2oo3だろうと、冗長化の意味が消えてしまいます。

前回、LOPAの計算の中で「既存防護層とクラウド判定システムを独立と仮定した」と書きましたが、その独立性の条件 (規格7.6.2.7) を思い出してください。機能的に異なること、異なった技術に基づくこと、共通の部品・電源を使わないこと。これらを満たさなければ、独立とは扱えません。

クラウド型の思考実験で、この条件を満たすための代表的な手段が 異種実装 (diverse redundancy) です。同じコードを3つ並べるのではなく、たとえば：

Ch-A：Lambda (x86アーキテクチャ) - AZ1で実行
Ch-B：Lambda (Gravitonアーキテクチャ、ARM) - AZ2で実行
Ch-C：コンテナ (AMDプロセッサ) - AZ3で実行

同じソフトウェアバグや同じCPU固有の欠陥が、3チャンネル同時に起きる確率を下げる狙いです。CCFの起こりやすさを表す指標がβ係数で、異種実装はこのβを下げるための設計手段です。

ここは、組み込み機器と比べたときの、クラウドならではの利点が光る場面でもあります。

一つは、プロセッサーの多様性を選びやすいことです。組み込み機器で「センサーごとに異なる半導体メーカーのマイコンを採用する」となると、部品の選定・調達・個別の動作検証と、相応の設計コストがかかります。一方AWSでは、Lambdaの設定を1行変えるだけで、Graviton (ARM) かIntel Architecture (IA) かの異なるプロセッサーアーキテクチャを選択できます。EC2で構成する場合は、IAプロセッサーをさらにInterl製かAMD製かを選ぶことが可能となります。同じロジックを異なるアーキテクチャで動かす、という異種実装が、組み込みの世界よりずっと手軽に実現できます。

もう一つは、AWSのAvailability Zone (AZ) が地理的な多様性を確保できるように設計されていることです。AWSの公開資料 Fault Isolation Boundaries によれば、AZは停電・断水・光ファイバーの断線・地震・火災・竜巻・洪水といった、広域にわたる災害シナリオの影響を同時には受けないように設計されています。発電機や空調設備のような共通の障害点も、AZ間で共有しません。各チャネルを別AZに配置した場合、単なる「サーバーの配置場所を分ける」以上の意味を持ち、従来のオンプレミスでの実装と比べ桁違いに高い地理的独立性を手軽に組み込めます。

確かに、これらは「多様化・分散が実現しやすい」という設計上の利点であって、それを裏付ける定量的な危険側故障率データが公表されていない限り、ルート1Hによる実装は依然不可能です。それでも、規格が求める独立性の条件 (機能的に異なる、異なる技術に基づく、共通部品を使わない) を満たす設計そのものはクラウドの方が着手しやすいというのは、ルート2Hで実証する上でも念頭に置くべき価値だと考えています。

また、クラウドによる多様性は決定論的対応能力 (SC) の合成規則 (7.4.3.2) とも対応します。各チャンネルが独立した実装 (プロセッサーアーキテクチャの違い、デプロイするAZの違い) であれば、それぞれのチャンネルが持つ決定論的対応能力SC Nを、組み合わせてSC (N+1) 相当として扱える可能性があるということです。異種実装は、単にハードウェア的なCCF対策であるだけでなく、規格が定める決定論的安全度側の底上げの仕組みとしても、根拠を持つ設計手法だと言えます。

投票 (多数決) は、どこで行うべきか

ここで一つ、設計上の重要な選択が残っています。

3チャンネルの判定結果を集約し、最終的に遮断するかどうかを決める「投票」処理は、クラウドとEdge (現場) のどちらに置くべきでしょうか。

これまで確認してきた原則を振り返ります。

フェールセーフはクラウドではなく現場の遮断器が自律的に担う、という方針 (第3回で確定)
独立性の条件 (7.6.2.7) は、複数の防護層が「共通の部品・供給システムを用いない」ことを求めている

もし投票処理そのものをクラウド側に置いてしまうと、3チャンネルの判定結果は独立に生成されていても、それを集約する「最後の砦」が結局クラウドという単一の基盤に依存してしまいます。クラウド全体の障害が起きれば、投票プロセスごと機能を失いかねません。

そこで本稿では、各チャンネルの個別の判定 (漏れているか否か) はクラウド側 (Lambda等) で行うが、その3つの結果を集約して最終的に遮断するかどうかを決める多数決処理は、Edge側 (現場のIoTゲートウェイ内蔵遮断器) で行う、という設計方針を採用します。

[Ch-A判定 (クラウド) ]─┐  
[Ch-B判定 (クラウド) ]─┼─→ 判定結果を現場へ送信  
[Ch-C判定 (クラウド) ]─┘  
                          ↓  
              [Edge側 (遮断器) で2oo3D多数決]  
               (診断NGのChは投票から除外)   
                          ↓  
                      [遮断弁]

こうすることで、クラウドが完全に落ちても、現場に届いている (届いていた) 各チャンネルの判定結果だけで、Edge側が多数決を完結できます。これまで一貫して掲げてきた「クラウドを最後の砦にしない」という設計方針の、最も具体的な帰結だと考えています。

ここで一つ、注意しておきたいことがあります。

Edge側のフェールセーフ（ハートビート途絶時に自律的に閉じる仕組み）が担保するのは、あくまで「クラウドが沈黙する」故障モードに対してです。仮にEdge側の遮断器がSIL2相当の水準で作り込まれていたとしても、それだけで「クラウドがSIL1でも、系全体としてSIL2を主張できる」ということにはなりません。

故障モードを分けて考える必要があります。

クラウドが沈黙する場合（通信途絶・クラウド全体の障害）：ハートビートが届かなくなり、Edge側が自律的に閉じます。この経路では、クラウドの中身の正しさとは無関係に、遮断器自身のSILがそのまま効きます。
クラウドが沈黙せず、判定を間違える場合（センサーは正しく「漏れ」を報告しているのに、クラウド側の判定ロジックにバグや故障があり、遮断コマンドを出し損なう）：ハートビートは正常に届き続けるため、Edge側のフェールセーフは発動しません。この経路では、センサー→クラウド→遮断器という直列の1本道がそのまま安全機能の実体であり、直列合成の規則（7.4.4.2.3、最弱リンク）に従って、クラウドの判定ロジックのSILが、そのまま全体の上限を決めます。

つまり、Edge側のフェールセーフは「クラウドが黙る」ケースに対する独立した保護層であって、「クラウドが間違った答えを出しながら喋り続ける」ケースまでは救ってくれません。だからこそ、これまでの回で判定ロジック（ロジックソルバー）自体のSIL・SCを丁寧に検討してきたことには意味があります。Edge側のフェールセーフは安全網ではありますが、クラウド側の設計品質を免除してくれる免罪符ではないため、上記で見たクラウド側のSIL担保の議論は依然必要となります。

今回は詳細触れませんでしたが、フェーズ10の設計は「システム全体としてSILがいくつか」という単一の数字を求める作業ではなく、①のハザード分析(第3回) で洗い出した個々の故障モード・危険事象に立ち返り、それぞれにどの機構が効くのかを個別に検証していく作業が必要です。規格（7.4.8）も、危険側故障の検出可否とHFTの組み合わせごとに要求する挙動を書き分けており、この「故障モードごとに考える」姿勢は規格そのものの設計思想のようです。

まとめと次回予告

今回は、目標PFDavgをどう達成するかという問いに、アーキテクチャを育てながら向き合いました。

E/E/PE安全関連系「全体」の目標は、センサー・ロジックソルバー・アクチュエータという各サブシステムに配分される。センサー・遮断器はEdge側でSIL2以上を達成しうると仮定し、以降はロジックソルバー (クラウド) に焦点を絞った
規格 (7.4.2.2) はa) 〜e) の5つの要求事項を求めており、本稿ではa) ハードウェア安全度とc) 決定論的安全度に絞って検討した
クラウドの責任共有モデルになぞらえ、Layer 1 (Safety of the Cloud、AWS基盤) とLayer 2 (Safety in the Cloud、自作の判定ロジック) に整理した。Layer 1はさらに物理インフラ (Layer 1a、ルート2Hの発想) とAWSの運用ソフトウェア (Layer 1b、ルート2Sの発想) に分解できる
Layer 2は新規開発ソフトウェアのため、ルート1Sが適用対象になる。実装言語には、規格 (表A.3) が推奨する「厳密に型付けした言語」に適合するGoやC#が候補になる
単一チャンネル (1oo1) では目標に届かない。故障はλdd (検出できる) とλdu (検出できない) に分けられ、診断カバレッジ (DC) がλduを減らす鍵になる
MooNアーキテクチャは、Mを変えるだけで「見逃しに強い」「誤遮断に強い」という性質が反転する
冗長化しても、共通原因故障 (CCF) が起きれば意味が薄れる。異種実装 (diverse redundancy) は、ハードウェア側のCCF対策であると同時に、決定論的対応能力の底上げという意味でも規格上の根拠を持つ
個々の判定はクラウドで行うが、最終的な多数決 (投票) はEdge側で行うことで、クラウドを「最後の砦」にしない設計にする
クラウドを利用することにより、高い設計の独立性、地理的独立性を容易に担保しうる

次回予告

次回は④検証・妥当性確認 (フェーズ13) に進みます。設計したものが本当に目標を満たしているかをどう確認するのか、そしてクラウドの応答時間の不確実性がこのフェーズにどう影響するのかを見ていきます。

また、今回は深入りしませんでしたが、クラウド内部の実装そのものにも、まだ詰めるべき論点が残っています。たとえば、センサーからの入力を一度IoT Coreに集約してからLambdaに振り分ける構成は、3チャンネルの上流に単一の共有コンポーネントを置くことになり、独立性の条件 (7.6.2.7) と厳密には相性が良くありません。また、AWSのサービスには利用者がAZを指定して独立に動作するZonal Service (EC2など) と、内部的には複数AZに分散していても利用者からは1つのエンドポイントに見えるRegional Service (Lambda・IoT Coreなど) という区別があり、異種実装がどこまで独立性を担保できるかは、この区別を踏まえて改めて検討する必要があります。この「クラウド内部の実装をどう見直すか」という論点は、次回以降、掘り下げていきたいと思います。

個々のチャンネル設計の話が一段落したら、「クラウドをどう安全システムに位置づけるか」というアーキテクチャ全体の問いにも、改めて向き合っていきたいと思います。

これまでの記事はこちら