機能安全に触れる機会があり、技術・手法群についてもとても勉強になりそうであったため、一つずつ理解していきたい
IEC 61508-3：2010 附属表A
IEC 61508-3：2010 附属表Aにおいて、要求安全度水準に従って採用すべき技術・手法が規定されている。
以下の表はIEC 61508-3：2010 附属表Aより引用
https://kikakurui.com/c0/C0508-3-2014-01.html
| 評価 | 説明 |
|---|---|
| HR | この安全度水準には、技法又は手段を使用することを強く推奨する。この技法又は手段を使用しない場合は、使用しない理論的根拠について、附属書Cを参照して安全計画時に詳述しなければならず、またアセッサと合意しなければならない。 |
| R | この安全度水準には、HR推奨より低い推奨事項としての技法又は手段が望ましい。 |
| — | 技法又は手段を使用することに関しては、推奨も反対もしない。 |
| NR | この安全度水準には、技法又は手段を使用することを積極的には推奨しない。この技法又は手段を使用する場合は、使用する理論的根拠について、附属書Cを参照して安全計画時に詳述しなければならず、またアセッサと合意することが望ましい。 |
表A.2−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計（7.4.3参照） の一部抜粋
https://kikakurui.com/c0/C0508-3-2014-01.html
| ID | 技法及び手段 | 参照先 | SIL 1 | SIL 2 | SIL 3 | SIL 4 |
|---|---|---|---|---|---|---|
| 1 | フォールト検出 | IEC 61508-7のC.3.1 | — | R | HR | HR |
| 2 | エラー検出コード | IEC 61508-7のC.3.2 | R | R | R | HR |
| 3a | 故障アサーションプログラミング | IEC 61508-7のC.3.3 | R | R | R | HR |
| 3b | ダイバースモニタリング（同一コンピュータ内で監視する機能を実装している機能的多様性） | IEC 61508-7のC.3.4 | — | R | R | — |
| 3c | ダイバースモニタリング（監視するコンピュータを監視されるコンピュータとは別の場所に設置している） | IEC 61508-7のC.3.4 | — | R | R | HR |
| 3d | 同一のソフトウェア安全要求仕様を実装する多様冗長 | IEC 61508-7のC.3.5 | — | — | — | R |
| 3e | 異なるソフトウェア安全要求仕様を実装する多様冗長 | IEC 61508-7のC.3.5 | — | — | R | HR |
| 3f | バックワードリカバリ | IEC 61508-7のC.3.6 | R | R | — | NR |
| 3g | ステートレスソフトウェア設計（又は限定ステート設計） | IEC 61508-7のC.2.12 | — | — | R | HR |
| 4a | 再試行/フォールト回復メカニズム | IEC 61508-7のC.2.14 | R | R | — | — |
| 4b | グレースフルデグラデーション | IEC 61508-7のC.3.8 | R | R | HR | HR |
IEC 61508-7：2010
IEC 61508-7：2010にて以下の定義が示されている
C.3.1 フォールト検出
注記 この技術及び手法は，JIS C 0508-3の表A.2で引用されている。
目的：故障に至る可能性があるシステムのフォールトを検出し，故障の結果を最小限に抑えるための対策の基礎を提供する。
説明：フォールト検出は，あるシステムが［チェックの対象である（サブ）システム内のフォールトによって発生する］誤り状態になっていないかどうかを確認する活動である。フォールト検出の主な目標は，正しくない結果の影響を阻止することである。並列要素と組になって動作し，自己の結果が正しくないと検出したとき制御を放棄するシステムであるため，セルフチェックと呼ばれる。
フォールト検出は，冗長性（主として，ハードウェアフォールトを検出する。JIS C 0508-2の附属書Aを参照。）及び多様性（ソフトウェアフォールト）の原理に基づく。結果の正確さを判定するためには，ある種の票決が要求される。適用できる特殊な手法としては，アサーションプログラミング，Nバージョンプログラミング及びダイバースモニタ技術がある。ハードウェア用には，追加のセンサ，制御ループ，誤り検査コードなどを導入する。
フォールト検出は，異なる段階での値領域又は時間領域，特に，物理的（温度，電圧など），論理的（誤り検出コード），機能的（アサーション）又は外部的（確からしさ確認），におけるチェックによって行う。これらの確認の結果は格納しておき，故障追跡を可能とするために，影響を受けるデータと結び付けてもよい。
複雑なシステムは，サブシステムで構成する。フォールト検出，診断及びフォールト補償の効率は，フォールトの伝ぱ（播）に影響を及ぼすサブシステム間の相互作用の複雑さによって異なる。
サブシステムが小さいほど，詳細なフォールト診断（誤り状態の検出）が可能となるため，フォールト診断は最小サブシステム水準において適用することが望ましい。
企業規模の統合情報システムでは，診断テスト情報を含め，安全システムの状態を，定期的に，他の管理システムへ送信することができる。異常を検出した場合，これを表示して，危険状態が増大する前に是正手段を起動するために用いることができる。最後に，このような異常を文書化しておくことによって，本当に事象が起こった場合に，その後の調査の手助けとすることができる。
参考文献： Dependability of Critical Computer Systems 1. F. J. Redmill, Elsevier Applied Science, 1988, ISBN 1-85166-203-0
https://kikakurui.com/c0/C0508-7-2017-01.html
詳説
フォールト検出は，冗長性（主として，ハードウェアフォールトを検出する。JIS C 0508-2の附属書Aを参照。）及び多様性（ソフトウェアフォールト）の原理に基づく。結果の正確さを判定するためには，ある種の票決が要求される。適用できる特殊な手法としては，アサーションプログラミング，Nバージョンプログラミング及びダイバースモニタ技術がある。ハードウェア用には，追加のセンサ，制御ループ，誤り検査コードなどを導入する。
https://kikakurui.com/c0/C0508-7-2017-01.html
多様性
B.1.4 多様性のあるハードウェア
注記 この技術及び手法は，JIS C 0508-2の表A.15，表A.16及び表A.18で引用されている。
目的：故障の割合及び種類が異なる種々の構成部品を用いて，EUCの運転中の決定論的原因故障を検出する。
説明：安全関連系の種々のチャネルには，異なる種類の構成部品を用いる。こうすることによって，共通原因故障（例えば，過電圧，電磁妨害）の確率が下がり，そのような故障を検出する確率が上がる。 要求される機能を実行するための別の手段，例えば，別の物理的原理がある場合，同じ問題を解くための他の方法を得ることができる。多様性には，幾つかの方法がある。機能多様性は，同じ結果を達成するために異なるアプローチを用いる。
参考文献： Guidelines for Safe Automation of Chemical Processes. CCPS, AIChE, New York, 1993, ISBN-10: 0-8169-0554-1, ISBN-13: 978-0-8169-0554-6
https://kikakurui.com/c0/C0508-7-2017-01.html
C.3.5 ソフトウェア多様性（ダイバースプログラミング）
注記 この技術及び手法は，JIS C 0508-3の表A.2で引用されている。
目的：システムの安全上，重大な故障を防止し，高い信頼性で運用を継続するために，プログラムの実行中，残留するソフトウェア設計フォールト及び実装フォールトを検出して，マスクする。
説明：ダイバースプログラミングにおいては，規定したプログラム仕様を，異なる設計でN個実装する。同じ入力値をN個のバージョンに与え，N個のバージョンが生成する結果を比較する。結果を妥当であるとみなす場合，その結果をコンピュータ出力に伝送する。
基本的要求事項は，N個のバージョンをある意味で相互に独立させ，これらが同一原因によって同時に故障を起こさないようにすることである。実際には，N個のバージョン手法の基礎となっているバージョンの独立性を達成及び実証することは，非常に困難な場合がある。
N個のバージョンは別々のコンピュータで並列に実行することもできるが，これに代わる方法として，全てのバージョンを同一コンピュータ上で実行し，その結果を内部票決にかけることもできる。適用する要求事項によっては，N個のバージョンについて種々の異なる票決手法を，次のように用いてもよい。
− システムが安全な状態をもつ場合，完全な一致（全てのNが一致する）を要求することが妥当であり，そうでないときには，システムを安全な状態に到達させる出力値を一つ用いる。単純なトリップシステムの場合，票決は安全方向へ偏らせることができる。この場合，安全動作としては，いずれかのバージョンがトリップを要求したときに，トリップすることになる。このアプローチは，通常は，二つのバージョンだけを用いる（N＝2）。
− 安全な状態をもたないシステムの場合，多数決による票決手段を採用することができる。全体的一致がない場合，正確な値を選択する機会を最大にするために，例えば，中央値をとる，一致が戻るまで出力を一時的に凍結する，などの確率的アプローチを用いてもよい。 この技術は，残留するソフトウェア設計フォールトを取り除くことも，仕様解釈上のエラーを避けることもできないが，これらが安全性に影響を及ぼす前に検出しマスクする手段を提供する。
参考文献： Modelling software design diversity−a review, B. Littlewood, P. Popov, L. Strigini. ACM Computing Surveys, vol 33, no 2, 2001 The N-Version Approach to Fault-Tolerant Software, A.Avizienis, IEEE Transactions on Software Engineering, vol. SE-11, no. 12 pp.1491-1501, 1985 An experimental evaluation of the assumption of independence in multi-version programming, J.C. Knight, N.G. Leveson. IEEE Transactions on Software Engineering, vol. SE-12, no 1, 1986 In Search of Effective Diversity: a Six Language Study of Fault-Tolerant Flight Control Software. A. Avizienis, M. R. Lyu and W. Schutz. 18th Symposium on Fault-Tolerant Computing, Tokyo, Japan, 27-30 June 1988, IEEE Computer Society Press, 1988, ISBN 0-8186-0867-6
https://kikakurui.com/c0/C0508-7-2017-01.html
多様性と冗長性の違い
2重化とは、同じものを2つ使うことです。冗長化とも言います。
多様性とは、異なる種類のものを複数（2つ以上）使うことです。異種冗長化とも言います。
https://www.fa.omron.co.jp/product/special/safetynavi/tips/safety_principle_04/
目的が違うと考えることができます。
冗長化とはシステムの可用性を高め、単一障害点を排除することが目的であるのに対して、多様性は共通原因故障に対抗してシステム全体の信頼性を高めることにあります。
しばしば冗長化するという際に、多様性の意味で使用されていることがあります。
例：このシステムはある事象を防ぐために二つの安全機能で冗長化している。
これは安全機能という意味で同じ機能を提供しているので冗長化と呼べる会話レベルの話で、厳密には機能を異なる方法で実現しているので多様化しているという方が正しいです。ですが、日常会話では分かりにくいので冗長化という言葉が好んで使われるということだと思います
票決
多数決のことを指していると推定される。二つのみではどちらかがフォールトしているかしか分からないので、フェールセーフに従ってシステムを停止させるしかない。一方で、３つ以上存在すれば異常値をマスクすることが可能で、可用性を高めることができる
A.1.4 多数決
注記 この技術及び手法は，JIS C 0508-2の表A.2，表A.3及び表A.4で引用されている。
目的：三つ以上のハードウェアチャネルの一つの故障を検出し，マスクする。
説明：多数決原理（2 out of 3，3 out of 3，又はm out of n）を用いた多数決回路を用いて故障を検出し，マスクする。多数決回路自体は，外部的にテストしてもよいし，自己監視技術を用いてもよい。
参考文献： Guidelines for Safe Automation of Chemical Processes. CCPS, AIChE, New York, 1993, ISBN-10: 0-8169-0554-1, ISBN-13: 978-0-8169-0554-6
https://kikakurui.com/c0/C0508-7-2017-01.html
アサーションプログラミング
C.3.3 故障アサーションプログラミング
注記 この技術及び手法は，JIS C 0508-2の表A.17並びにJIS C 0508-3の表A.2及び表C.2で引用されている。
目的：システムの安全上，重大な故障を防止し，高い信頼性で運用を継続するために，プログラムの実行中，残留するソフトウェア設計フォールトを検出する。
説明：アサーションプログラミング手法は，事前条件をチェックし（一連のステートメントが実行される前に，初期条件の妥当性をチェックする。），さらに，事後条件をチェックする（一連のステートメ 73 C 0508-7：2017 (IEC 61508-7：2010) ントを実行した後，結果をチェックする。）という概念に準拠している。事前条件又は事後条件のいずれかが満たされない場合，処理はエラーを報告する。
例
アサート＜事前条件＞；
アクション1；
：
：
アクションx；
アサート＜事後条件＞；参考文献： Exploiting Traces in Program Analysis. A. Groce, R. Joshi. Lecture Notes in Computer Science vol 3920, Springer Berlin / Heidelberg, 2006, ISBN 978-3-540-33056-1 Software Development−A Rigorous Approach. C. B. Jones, Prentice-Hall, 1980
https://kikakurui.com/c0/C0508-7-2017-01.html
プログラミングにおいて一般的なassertを指します
Nバージョンプログラミング
上記した”C.3.5 ソフトウェア多様性（ダイバースプログラミング） ”に等しい
ダイバースモニタ
C.3.4 ダイバースモニタ
注記 この技術及び手法は，JIS C 0508-3の表A.2で引用されている。
目的：安全性に悪影響を及ぼす，ソフトウェアに残留する仕様上及び実装上のフォールトに対して保護する。
説明：監視は，次の2種類の手法に分けることができる。
1) 同一コンピュータ内で，監視対象となる機能とこれを監視する機能との間の独立性をある程度保証している。
2) 監視機能と監視対象となる機能とが，個別のコンピュータにある。
ダイバースモニタは，別の仕様に従って独立したコンピュータ上に実装する外部モニタである。このダイバースモニタは，主コンピュータに対して必ずしも正しくなくてもよいが，安全な動作を確実にさせることだけに関心をもつ。ダイバースモニタは，主コンピュータを常時監視する。ダイバースモニタは，システムが潜在的に危険な状態になるのを防止する。さらに，モニタは主コンピュータが潜在的に危険な状態になりつつあることを検出した場合には，ダイバースモニタ又は主コンピュータのどちらかによって，システムを安全な状態に戻す必要がある。 ダイバースモニタのハードウェア及びソフトウェアは，適切なSILに従って分類し，認証を受けることが望ましい。
参考文献： Requirements based Monitors for Real-Time Systems, D. Peters, D. Parnas. IEEE Transactions on Software Engineering, vol. 28, no. 2, 2002
https://kikakurui.com/c0/C0508-7-2017-01.html
