【機能安全技術】信頼性確認／検証済ソフトウェア要素の使用（使用可能な場合）(IEC 61508-7)

機能安全に触れる機会があり、技術・手法群についてもとても勉強になりそうであったため、一つずつ理解していきたい

IEC 61508-3：2010 附属表A
IEC 61508-7：2010

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.4−ソフトウェア設計及び開発−詳細設計（7.4.5及び7.4.6参照）
https://kikakurui.com/c0/C0508-3-2014-01.html

技術及び手段(a)	参考文献	SIL 1	SIL 2	SIL 3	SIL 4
1a 構造化手法(b)	IEC 61508-7のC.2.1	HR	HR	HR	HR
1b 準形式手法(b)	表B.7	R	HR	HR	HR
1c 形式的設計手法及び精緻化手法(b)	IEC 61508-7のC.2.2及びC.2.4	– – –	R	R	HR
2 コンピュータ支援設計ツール	IEC 61508-7のB.3.5	R	R	HR	HR
3 防御的プログラミング	IEC 61508-7のC.2.5	– – –	R	HR	HR
4 モジュラーアプローチ	表B.9	HR	HR	HR	HR
5 設計及びコーディング基準	表B.1<br>IEC 61508-7のC.2.6	R	HR	HR	HR
6 構造化プログラミング	IEC 61508-7のC.2.7	HR	HR	HR	HR
7 信頼性確認/検証済ソフトウェア要素の使用<br>(使用可能な場合)	IEC 61508-7のC.2.10	R	HR	HR	HR
8 ソフトウェア安全要求仕様とソフトウェア設計との<br>間の前方トレーサビリティ	IEC 61508-7のC.2.11	R	R	HR	HR

IEC 61508-7：2010

IEC 61508-7：2010にて ”信頼性確認及び検証済みソフトウェア要素の使用” は以下の定義が示されている

C.2.10 信頼性確認及び検証済みソフトウェア要素の使用
注記この技術及び手法は，JIS C 0508-3の表A.2，表C.2，表A.4及び表C.4で引用されている。
目的：ソフトウェア設計及び要素の，新しいアプリケーションごとの大幅な妥当性確認又は設計し直しが必要になることを避ける。形式的又は厳格に検証されていないが，かなりの運用履歴がある設計を活用する。別のアプリケーションで検証済みであり，多数の適合確認証拠がある既存のソフトウェア要素を活用する。
説明：この手法は，ソフトウェア要素が決定論的設計フォールト及び／又は運用上の故障がほとんどないことを検証するものである。
最も初歩的な部分から複雑なシステムを構築することは，一般に不可能である。一般には，既に開発されて相当程度有用な機能を提供していて，更に新システムの相当部品の実装に再利用できるような主要サブアセンブリ（“要素”，JIS C 0508-4の3.4.5及び3.2.8参照）を利用することが必要となる。
良好に設計され，構成されたPE系は，明確に区別ができて，明確に規定された方法で相互に作用し合う幾つかのソフトウェア要素でできあがっている。このような，複数のアプリケーション内で再利用することができる一般的に応用可能なソフトウェア要素のライブラリを構築することで，複数のアプリケーションで共有できる設計の妥当性を確認するために必要な，多くの資源とすることができる。ただし，安全関連アプリケーションの場合，これら既存の要素を組み込んだ新システムが要求される安全度をもち，既存の要素の不正な挙動によって安全性が損なわれないという十分な信頼性があることが重要である。
次の二つの観点によって，既存の要素の挙動が正確に分かっているという信頼性を得ることができる。
− 要素の包括的な運用履歴を解析して，この要素が“実績による使用”をもつことを実証する。
− 要素の挙動について収集した多数の適合確認証拠を評価して，要素が，この規格の要求事項を満たすかどうかを判断する。
C.2.10.1 実績による使用
“実績による使用”（JIS C 0508-4の3.8.18参照）が，信頼性確認済みのソフトウェア要素が必要な安全度を実現していることの十分な根拠となることは非常にまれである。多くの実行可能な機能をもつ複雑な要素（例えば，オペレーティングシステム）の場合，要素のどの機能が実際に十分な使用実績をもつか確定することは不可欠である。例えば，フォールトを検出するための自己テストルーチンを備えている場合，運用期間中に故障が全く起こらなかった場合，フォールト検出のための自己テストルーチンに使用実績があると考えることはできない。
ソフトウェア要素は，次の判定基準を満たしている場合，使用実績があると判断できる。
− 仕様を変更していない。
− 種々のアプリケーションにおけるシステムがある。
− 1年以上の使用履歴がある。
− 運用時間は，安全度水準又は適切な作動要求数に従っている。非安全関連故障率が次の値を下回っていることを実証することができる。
・信頼水準95 %で作動要求（年間）当たり10−2未満であることの実証には，300回の運用（年間）を必要とする。
・信頼水準99.9 %で作動要求（年間）当たり10−5未満であることの実証には，690 000回の運用（年間）を必要とする。
注記1 上記の推定値の根拠となる数学的側面は，附属書Dを参照。類似の手法及び統計的アプローチは，B.5.4も参照。
− 運用経験を積むことによって作動要求プロフィールに対するソフトウェア要素の挙動についての知識 68 C 0508-7：2017 (IEC 61508-7：2010) が増すことを確実にするために，運用経験の全てをソフトウェア要素の機能についての既知作動要求プロフィールに関連付ける必要があるが，これを満足している。
− 安全関連故障がない。注記2 一つの状況において安全上重大でないかもしれない故障が，他の状況において安全上重大である場合，又はその逆の場合がある。ソフトウェア要素が判定基準を満たしていることの適合確認を可能にするために，次の事項を文書化する必要がある。
− バージョン番号を含め，各システム及びその要素の正しい識別（ソフトウェア及びハードウェアの両方について）
− 使用者の特定及び使用時間
− 運用時間
− 使用者利用システム及びアプリケーションの選択のための手順
− 故障を検出し登録するための手順及びフォールトを取り除くための手順
C.2.10.2 多数の適合確認証拠の評価
既存のソフトウェア要素（JIS C 0508-4の3.2.8参照）は，既に存在するものであって，現行のプロジェクト又は安全関連系（SRS）を対象として特に開発されたものではない。既存ソフトウェアは市販品かもしれないし，どこかの組織が旧製品又は旧システムのために開発したかもしれない。既存ソフトウェアは，この規格の要求事項に従って開発したものでも，そうでないものでもよい。
既存ソフトウェアを組み込んだ新システムの安全度を評価する場合，既存の要素の挙動を判断するために多数の適合確認証拠が必要となる。これらの証拠は，（1）要素供給業者自身がもつ，この要素の開発プロセスの文書及び記録，又は（2）新規安全関連系の開発業者若しくは第三者が行った追加認証活動によって作成若しくは補足作成されたものの場合がある。これらの証拠は，ソフトウェア要素の潜在的な再利用可能性及び限度を定義する，“準拠項目に対する安全マニュアル”である。
いずれの場合も，再利用する要素に全面的又は部分的に左右される特定安全機能の完全性の評価を可能にする，準拠項目に対する安全マニュアルというものが存在する（存在しない場合は作成する。）必要がある。このマニュアルがない場合，要素を安全関連で再利用する根拠がないという，安全側に立った結論が導かれる可能性がある（これは，この要素が個別の事例で証拠が不十分だったというだけで，どのような場合にも使用できないということではない。）。
この規格は，準拠項目に対する安全マニュアルの内容について，具体的な要求事項を用意している［JIS C 0508-2の附属書D（準拠項目に対する安全マニュアル），JIS C 0508-3の附属書D（適合品目の安全マニュアル−ソフトウェア要素の追加要求事項）並びにJIS C 0508-3の7.4.2.12及び7.4.2.13参照］。準拠項目に対する安全マニュアルは，内容を非常に簡単に示すものとして，次の点を取り上げている。
− 要素の設計が既知であり，文書化している。
− 要素が，文書化したテストによる系統的アプローチを用いて適合確認及び妥当性確認を受けており，要素の設計及びコードの全ての部分の見直しを行っている。
− 要素の未使用及び不要な機能によって，新システムがその安全要求事項を満たすことを妨げない。
− 新システム中の要素の，全ての信ぴょう（憑）性のある故障メカニズムを特定し，適切な軽減手段を実装している。
新システムの機能安全評価によって，再利用した要素は，要素の準拠項目の安全マニュアルの証拠及び 69 C 0508-7：2017 (IEC 61508-7：2010) 想定によって根拠を与えた能力の範囲を厳守して適用したことを確認する必要がある。
参考文献： Component-Based Software Development: Case Studies. Kung-Kiu Lau. World Scientific, 2004, ISBN 9812388281, 9789812388285 Software Reuse and Reverse Engineering in Practice. P. A. V. Hall (ed.), Chapman & Hall, 1992, ISBN 0-412-39980-6 Software criticality analysis of COTS/SOUP.P.Bishop, T.Clement, S.Guerra. In Reliability Engineering & System Safety, Volume 81, Issue 3, September 2003, Elsevier Ltd., 2003
https://kikakurui.com/c0/C0508-7-2017-01.html

詳説

近年ではプログラム全てを内製することは不可能であり、様々なソフトウェアを組み合わせて一つのアプリケーションを提供します。それらすべてのソフトウェアについて、正式に安全度水準が明記されていれば、それに従えばよいが、一般的に明記されていることは稀である。したがって、何らかの手段で既成ソフトウェアが安全度水準を満足していることを検証しなければならない。

その手段として、
・実績による使用
・多数の適合確認証拠の評価
が挙げられている。

なお、実績による使用の定義は以下に示されている

3.8.18
実績による使用（proven in use）
危険側の決定論的原因フォールトの可能性が十分に低いため，要素を使用する全ての安全機能がその要求安全度水準を達成できることを，要素の特定構成の運用実績に基づいて実証すること。
https://kikakurui.com/c0/C0508-4-2012-01.html

そもそも決定論的原因が定量化不可能であるため、プロセスによる保護としてソフトウェア設計プロセスが規定され、本章にあたるような設計技術が規定されている。プロセスの確証が得られていない場合や、改めて本ソフトウェアの決定論的原因の可能性が十分に低いことを検証するために、実績による使用と同様の定量評価を行うことができる