C 0508-3：2014 (IEC 61508-3：2010) 

（1） 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

目 次 

ページ 

序文 ··································································································································· 1 

1 適用範囲························································································································· 2 

2 引用規格························································································································· 5 

3 用語及び定義 ··················································································································· 6 

4 この規格への適合 ············································································································· 6 

5 文書化···························································································································· 6 

6 安全関連ソフトウェアの管理に関する追加要求事項 ································································ 6 

6.1 目的 ···························································································································· 6 

6.2 要求事項 ······················································································································ 6 

7 ソフトウェア安全ライフサイクル要求事項 ············································································ 7 

7.1 一般 ···························································································································· 7 

7.2 ソフトウェア安全要求仕様 ····························································································· 14 

7.3 システム安全のソフトウェアの妥当性確認計画 ··································································· 17 

7.4 ソフトウェア設計及び開発 ····························································································· 19 

7.5 プログラマブル電子装置統合（ハードウェア及びソフトウェア） ··········································· 31 

7.6 ソフトウェアの運用及び部分改修手順··············································································· 32 

7.7 ソフトウェアのシステム安全妥当性確認············································································ 32 

7.8 ソフトウェア部分改修 ··································································································· 34 

7.9 ソフトウェア適合確認 ··································································································· 35 

8 機能安全評価 ·················································································································· 40 

附属書A（規定）技法及び手段の選択の手引書 ········································································· 41 

附属書B（参考）詳細表 ······································································································· 50 

附属書C（参考）ソフトウェア決定論的対応能力の特性 ····························································· 55 

附属書D（規定）適合品目の安全マニュアル−ソフトウェア要素の追加要求事項 ····························· 89 

附属書E（参考）JIS C 0508-2とJIS C 0508-3との関係 ······························································ 92 

附属書F（参考）単一コンピュータ上のソフトウェア要素間の不干渉性を達成するための技法 ··········· 94 

附属書G（参考）データ駆動システムに付属するライフサイクルのテーラリングの手引書 ················· 99 

参考文献 ··························································································································· 103 

C 0508-3：2014 (IEC 61508-3：2010) 

（2） 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

まえがき 

この規格は，工業標準化法第14条によって準用する第12条第1項の規定に基づき，一般社団法人日本

電気計測器工業会（JEMIMA）及び一般財団法人日本規格協会（JSA）から，工業標準原案を具して日本工

業規格を改正すべきとの申出があり，日本工業標準調査会の審議を経て，経済産業大臣が改正した日本工

業規格である。 

これによって，JIS C 0508-3:2000は改正され，この規格に置き換えられた。 

この規格は，著作権法で保護対象となっている著作物である。 

この規格の一部が，特許権，出願公開後の特許出願又は実用新案権に抵触する可能性があることに注意

を喚起する。経済産業大臣及び日本工業標準調査会は，このような特許権，出願公開後の特許出願及び実

用新案権に関わる確認について，責任はもたない。 

JIS C 0508の規格群には，次に示す部編成がある。 

JIS C 0508-1 第1部：一般要求事項 

JIS C 0508-2 第2部：電気・電子・プログラマブル電子安全関連系に対する要求事項 

JIS C 0508-3 第3部：ソフトウェア要求事項 

JIS C 0508-4 第4部：用語の定義及び略語 

JIS C 0508-5 第5部：安全度水準決定方法の事例（改正予定） 

JIS C 0508-6 第6部：第2部及び第3部の適用指針（改正予定） 

JIS C 0508-7 第7部：技術及び手法の概観（改正予定） 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

日本工業規格          JIS 

C 0508-3：2014 

(IEC 61508-3：2010) 

電気・電子・プログラマブル電子安全関連系の 

機能安全−第3部：ソフトウェア要求事項 

Functional safety of electrical/electronic/programmable electronic 

safety-related systems-Part 3: Software requirements 

序文 

この規格は，2010年に第2版として発行されたIEC 61508-3を基に，技術的内容及び構成を変更するこ

となく作成した日本工業規格である。 

なお，この規格で点線の下線を施してある参考事項は，対応国際規格にはない事項である。 

電気及び／又は電子の要素から成るシステムは，その適用分野において，安全機能を果たすために長年

使用してきた。一般に，プログラマブル電子系と呼ばれるコンピュータを用いたシステムは，あらゆる適

用分野で，安全以外の機能を達成するために用いられているが，次第に安全機能の履行にも使用するよう

になった。コンピュータシステムの技術を，効果的かつ安全に活用するためには，意思決定を行うための

安全の考え方に関する十分な手引書が必須である。 

この規格群では，電気・電子・プログラマブル電子（以下，E/E/PEという。）の要素から成るシステム

が，安全機能を履行するための全ての安全ライフサイクル業務に対する包括的な扱い方について規定して

いる。この統一した扱い方は，全ての電気的な安全関連系にわたって，合理的かつ整合性がある技術指針

を展開するためのものである。主な目的の一つは，JIS C 0508（IEC 61508）規格群を基本とした適用分野

の製品規格などの制定を容易にし，促進することである。 

注記1 JIS C 0508（IEC 61508）規格群を基本とした適用分野の製品規格などの事例を，参考文献（JIS 

C 0511，JIS B 9961及びIEC 61800-5-2）に示す。 

多くの状況下では，安全性は，幾つかのシステムによって達成し，複数の技術（例 機械，液圧，空気

圧，E/E/PE技術）に依存している。したがって，いかなる安全対策においても，個々のシステム（例 セ

ンサ，制御機器，アクチュエータ）の要素だけでなく，全システムを構成する全ての安全関連系を考慮し

なければならない。このため，この規格群は，一義的にはE/E/PE安全関連系を対象とするが，更にその他

の技術を基本とした安全関連系を対象とする安全の枠組みも提供する。 

様々な適用分野において，E/E/PE安全関連系を使用した応用を，多岐にわたり，多様な潜在危険及びリ

スクが存在することによって生じる複雑さに対応するものとして認識している。いかなる適用においても，

要求する安全（達成）手段は，その適用に関わる多数の要因に依存する。この規格群は，包括的であるた

め，今後の適用分野の製品規格などの制定版及び既存規格の改正版において，個々の手段の形成を可能と

する。 

この規格群は，次の特徴をもつ。 

− 安全機能を遂行するためにE/E/PE系を使用する場合の，最初の概念から，設計，実装，運用及び保全

2 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

を経て廃却に至る全E/E/PE系及びソフトウェアの安全ライフサイクルフェーズを考慮する。 

− 急速に進歩する技術を念頭において作成した枠組みは，将来の展開に対応できる十分な耐力があり，

かつ，包括的である。 

− E/E/PE安全関連系に関して，適用分野の製品規格などを開発することを可能とする。この規格群の枠

組み内で適用分野の製品規格などを開発することによって，適用分野内及び適用分野間の一貫性（例 

基礎となる原理・原則，用語などの整合性）を高水準に導く。これは，安全上，かつ，経済上有益で

ある。 

− E/E/PE安全関連系に対して要求する機能安全の達成に必要な安全要求仕様を開発する方法論を，提供

する。 

− 安全度に関わる要求事項の決定に当たって，リスクを基本とした方法論を適用する。 

− E/E/PE安全関連系によって実装した安全機能に対して，安全度の目標水準を特定するための安全度水

準を導入する。 

注記2 この規格群は，いかなる安全機能についても安全度水準に対する要求事項を規定すること

はなく，また，安全度水準を決定する方法についても規定することはない。この規格群は，

むしろ，リスクに基づいた概念的枠組み及び技法の事例を提供するものである。 

− E/E/PE安全関連系が実現する安全度水準に対応した目標機能失敗尺度を設定する。 

− 単一のE/E/PE安全関連系が実現する安全機能に対して，目標機能失敗尺度の最小値を設定する。それ

らは，運用モードに応じて次による。 

− 低頻度作動要求モードの場合，作動要求時の危険側機能失敗時間平均確率（PFDavg）を10−5に設定

する。 

− 高頻度作動要求モード又は連続モードは，単位時間当たりの時間平均危険側故障頻度（PFH）を 

10−9［1/h］に設定する。 

注記3 単一のE/E/PE安全関連系とは，必ずしも単一チャネル構成を意味するものではない。 

注記4 複雑でないシステムについては，目標安全度をより小さな値で安全関連系の設計をするこ

とが可能であるが，これらの限界値は，現時点で比較的複雑なシステム（例 プログラマ

ブル安全関連系）に対して達成できるものを表しているものとみなしている。 

− 産業活動で得られた実際の経験に基づく専門的経験及び判断に基づいた決定論的原因フォールトの，

回避及び制御を設定する。決定論的原因故障の発生確率は一般的に数値化はできないが，安全機能に

関連した目標機能失敗尺度は，この規格に規定する要求事項を全て満たしている場合は，達成してい

るとみなしてもよい。 

− 決定論的安全度が，特定の安全度水準の要求事項に適合する信頼に対応する要素を提供する，決定論

的対応能力を導入する。 

− E/E/PE安全関連系に対して，機能安全を達成するために多岐にわたる原理，技法及び手段を適用する

が，“フェールセーフ”の概念は明示的には使用しない。ただし，“フェールセーフ”及び“固有（本

質）安全”の原理は，この規格の関連する要求事項に適合することを条件として適用してもよい。 

1 

適用範囲 

1.1 

この規格の適用範囲は，次による。 

a) JIS C 0508-1及びJIS C 0508-2を十分に理解した上でだけ，使用するように意図している。 

b) JIS C 0508-1及びJIS C 0508-2の適用範囲内で，安全関連系の一部を形成するソフトウェアか，又は

3 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

安全関連系を開発するために使用するソフトウェアに適用する。これらのソフトウェアを，安全関連

系ソフトウェアという（オペレーティングシステム，システムソフトウェア，通信ネットワーク内の

ソフトウェア，ヒューマン−コンピュータインタフェース機能及びファームウェア，並びにアプリケ

ーションプログラムを含む）。 

c) JIS C 0508-1及びJIS C 0508-2の適用範囲内で，安全関連系の開発及び構成に使用する支援ツールに

適用する特定要求事項について規定する。 

d) ソフトウェア安全機能及びソフトウェアの決定論的対応能力について規定する。 

注記1 ソフトウェア安全機能及びソフトウェアの決定論的対応能力が，E/E/PE安全関連系の仕様

（JIS C 0508-2の7.2を参照）の一部として既に規定している場合は，この規格では再度

規定する必要はない。 

注記2 ソフトウェア安全機能及びソフトウェアの決定論的対応能力の規定は，反復手順である。

図3及び図6を参照。 

注記3 文書化構成については，JIS C 0508-1の箇条5及び附属書Aを参照。文書化構成には，社

内手順及び個々の適用分野の作業慣行を考慮に入れてもよい。 

注記4 “決定論的対応能力”の定義については，JIS C 0508-4の3.5.9を参照。 

e) 安全関連ソフトウェア（ソフトウェア安全ライフサイクルモデル）の設計及び開発中に適用しなけれ

ばならない安全ライフサイクルフェーズ及び業務に関する要求事項を確立する。これらの要求事項は，

ソフトウェアのフォールト及び故障の回避及び管理のために，要求する決定論的対応能力に基づいて

等級付けする手段及び技法の利用を含む。 

f) 

E/E/PE系統合を実施する組織に提供する，ソフトウェア安全妥当性確認に関する情報に関する要求事

項について規定する。 

g) E/E/PE安全関連系の運用及び保全のために使用者が必要とするソフトウェアに関する情報及び手順

について，その作成に関する要求事項を規定する。 

h) 安全関連ソフトウェアの部分改修を実施する組織が満たさなければならない要求事項について規定す

る。 

i) 

JIS C 0508-1及びJIS C 0508-2と関連して，開発及び設計ツール，言語翻訳ツール，テスト及びデバ

ッグツール，変更管理ツールなど，様々な支援ツールに関する要求事項について規定する。 

注記5 JIS C 0508-2とJIS C 0508-3との関係を，図5及び附属書Eに示す。 

j) 

IEC 60601規格群に適合する医用機器には適用しない。 

1.2 

低複雑度E/E/PE安全関連系（JIS C 0508-4の3.4.3参照）の場合は当てはまることがないとしても，

JIS C 0508-1〜-4は基本安全規格である。これらは，基本安全規格として，IEC Guide 104及びISO/IEC 

Guide 51に記載のある原則に従った規格の制定において，原案作成委員会が使用するように意図している。

また，JIS C 0508-1〜-4は，独立した規格として使用することも意図している。この規格を水平展開でき

る安全機能は，IEC 60601規格群に適合する医用機器には適用しない。 

1.3 

個別の製品規格等の開発における責務の一つは，可能な限り，これらの開発段階において基本安全

規格群の活用を図ることにある。この関係から，この規格群及びIEC 61508規格群で規定する要求事項，

テスト方法及びテスト条件は，個別の製品規格等で特に引用されるか又は規定されることがない限り，個

別の製品規格等には適用しない。 

1.4 

図1にJIS C 0508規格群全体の枠組みを表示し，さらにE/E/PE安全関連系の機能安全の達成にJIS 

C 0508-3が果たす役割を示す。 

4 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

注記 この規格の対応国際規格及びその対応の程度を表す記号を，次に示す。 

IEC 61508-3:2010，Functional safety of electrical/electronic/programmable electronic safety-related 

systems−Part 3: Software requirements（IDT） 

なお，対応の程度を表す記号“IDT”は，ISO/IEC Guide 21-1に基づき，“一致している”こ

とを示す。 

技術的要求事項 

その他の要求事項 

第4部 

用語の定義 

及び略語 

第1部 
文書化 

箇条5及び 

附属書A 

第1部 

機能安全の管理 

箇条6 

第1部 

機能安全評価 

箇条8 

第5部 

安全度水準の決定

のための方法の例 

第6部 

第2部及び第3

部の適用指針 

第1部 

E/E/PE安全関連系に対する 

要求仕様 

7.10 

第7部 

技術及び手法の

概観 

第1部 

E/E/PE安全関連系の設置，引渡し及び 

安全妥当性確認 

7.13〜7.14 

第1部 

E/E/PE安全関連系の運用及び保全，修理，

部分改修及び改造，使用終了又は廃却 

7.15〜7.17 

第2部 

E/E/PE安全 

関連系の実現 

フェーズ 

第3部 

安全関連ソフト 

ウェアの実現 

フェーズ 

第1部 

E/E/PE安全関連系への 

安全度要求事項の割当て 

7.6 

第1部 

全体要求事項の作成 

（概念，適用範囲の定義，潜在危険及

びリスク解析） 

7.1〜7.5 

図1−この規格群（JIS C 0508規格群）の全枠組み 

5 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

図2−全安全ライフサイクル 

2 

引用規格 

次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部を構成する。これらの

引用規格のうちで，西暦年を付記してあるものは，記載の年の版を適用し，その後の改正版（追補を含む。）

は適用しない。西暦年の付記がない引用規格は，その最新版（追補を含む。）を適用する。 

JIS C 0508-1 電気・電子・プログラマブル電子安全関連系の機能安全−第1部：一般要求事項 

注記 対応国際規格：IEC 61508-1:2010，Functional safety of electrical/electronic/programmable 

electronic safety-related systems−Part 1: General requirements（IDT） 

JIS C 0508-2 電気・電子・プログラマブル電子安全関連系の機能安全−第2部：電気・電子・プログ

ラマブル電子安全関連系に対する要求事項 

1 

概念 

2 

全対象範囲の定義 

3 

潜在危険及びリスク解析 

4 

全安全要求事項 

5 

全安全要求事項の 

割当て 

全体計画 

6 

全運用 

及び 

保全計画 

7 

全安全 
妥当性 

確認計画 

8 

全設置 

及び 

引渡し計画 

9 

E/E/PE系安全要求仕様 

10 

E/E/PE安全関連系 

実現 

（E/E/PE系安全ライフサ

イクルを参照） 

12 

全設置及び引渡し 

13 

全安全妥当性確認 

14 

全運用，保全及び修理 

16 

使用終了又は廃却 

15 

全部分改修 

及び改造 

11 

他リスク軽減手段 

仕様及び実現 

適切な全安全 

ライフサイクルフェーズ

に戻る 

6 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

注記 対応国際規格：IEC 61508-2:2010，Functional safety of electrical/electronic/programmable 

electronic safety-related systems−Part 2: Requirements for electrical/electronic/programmable 

electronic safety-related systems（IDT） 

JIS C 0508-4 電気・電子・プログラマブル電子安全関連系の機能安全−第4部：用語の定義及び略語 

注記 対応国際規格：IEC 61508-4:2010，Functional safety of electrical/electronic/programmable 

electronic safety-related systems−Part 4: Definitions and abbreviations（IDT） 

IEC Guide 104:1997，The preparation of safety publications and the use of basic safety publications and group 

safety publications 

ISO/IEC Guide 51:1999，Safety aspects−Guidelines for their inclusion in standards 

3 

用語及び定義 

この規格群で用いる主な用語及び定義並びに略語は，JIS C 0508-4による。 

4 

この規格への適合 

この規格への適合の要求事項は，JIS C 0508-1の箇条4による。 

5 

文書化 

文書化の目的及び要求事項は，JIS C 0508-1の箇条5による。 

6 

安全関連ソフトウェアの管理に関する追加要求事項 

6.1 

目的 

目的は，JIS C 0508-1の6.1による。 

6.2 

要求事項 

6.2.1 

要求事項は，JIS C 0508-1の6.2によるほか，6.2.2及び6.2.3の追加要求事項による。 

6.2.2 

機能安全計画では，E/E/PE安全関連系によって実現する安全機能の安全度水準が必要とする，ソ

フトウェアの調達，開発，統合，適合確認，妥当性確認及び部分改修変更のための基本方針を，指定しな

ければならない。 

注記 この取組み方法の考え方は，E/E/PE安全関連系によって実現する各安全機能が要求する安全度

を考慮して，この規格をテーラリングするための機会として機能安全計画を用いることである。 

6.2.3 

ソフトウェア構成管理は，次による。 

a) ソフトウェアの変更を管理し，安全関連ソフトウェアに規定した要求事項を引き続き間違いなく満た

すように，ソフトウェア安全ライフサイクル全体にわたって業務上及び技術上の管理を行う。 

b) 要求するソフトウェアの決定論的対応能力を達成していることを実証するために，必要な作業の全て

を実施したことを保証する。 

c) E/E/PE安全関連系の安全度要求事項を満たすために必要な全ての構成品目を，正確かつ一意に識別し

ながら維持する。構成品目は，少なくとも次を含む。 

− 安全解析及び要求事項 

− ソフトウェア仕様及び設計文書 

− ソフトウェアソースコードモジュール 

− テスト計画及び結果 

7 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− 適合確認文書 

− E/E/PE安全関連系に組み込む既存のソフトウェア要素及びパッケージ。 

− E/E/PE安全関連系のソフトウェアの作成若しくはテスト，又はそのソフトウェアへの働きかけを行

うときに用いる全てのツール及び開発環境。 

d) 次のために，変更管理手順を適用する。 

− 許可していない部分改修を防止する。部分改修要請について文書化する。 

− 部分改修案の影響を解析し，要求を承認又は棄却する。 

− 承認した全部分改修の詳細，及びその承認を文書化する。 

− ソフトウェア開発における適切な時点で，構成ベースラインを確立し，そのベースラインの（部分

的）統合テストを文書化する。 

− ソフトウェアベースラインの全ての形成及び構築（初期のベースラインの再構築を含む）を保証す

る。 

注記1 業務上及び技術上の管理策の使用を指導し，実行するには，経営陣の意志決定及び権限が

必要となる。 

注記2 ある極端な例では，影響解析が非公式の評価を含むことがある。別の極端な例では，影響

解析が，理解又は実現に不備がある場合の全ての変更案の潜在的悪影響の厳密な形式的解

析を含むことがある。影響解析の手引書については，IEC 61508-7を参照。 

e) 実行するシステムに，正しいソフトウェア要素及びデータを正確にロードするための，適切な方法を

確実に導入する。 

注記3 これには，特定の目標ロケーションシステム及び一般的なシステムの検討を含むことがあ

る。ファームウェアなど，アプリケーション以外のソフトウェアは安全なローディング方

法が必要になることがある。 

f) 

あとで機能安全監査ができるように，構成ステータス（構成状況），リリースステータス（市場公開状

況），全部分改修の理由（影響解析を踏まえて）及びその承認，並びに部分改修の詳細を文書化する。 

g) 安全関連ソフトウェアのリリース（市場に公開したこと）を正式に文書化する。ソフトウェア及び全

ての関連文書，並びに使用しているデータのバージョンのマスタコピーは，リリースしたソフトウェ

アの運用期間中は保全及び部分改修ができるように保管しておかなければならない。 

注記4 構成管理の詳細については，IEC 61508-7を参照。 

7 

ソフトウェア安全ライフサイクル要求事項 

7.1 

一般 

7.1.1 

目的 

この箇条の要求事項の目的は，ソフトウェアの開発を，定義したフェーズ及び業務に組み込むことであ

る（表1及び図2〜図6を参照）。 

7.1.2 

要求事項 

7.1.2.1 

JIS C 0508-1の箇条6に従って，安全計画中にソフトウェアの開発に関する安全ライフサイクル

を選択し，指定しなければならない。 

7.1.2.2 

この箇条の全ての目的及び要求事項を満たしている場合，どのようなソフトウェアライフサイク

ルモデルを使用してもよい。 

7.1.2.3 

ソフトウェア安全ライフサイクルの各フェーズは，各フェーズに対して所定の適用範囲，引継ぎ

8 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

事項及び引渡し事項をもつ基本業務に分割しなければならない。 

注記 図2〜図4及び表1を参照。 

7.1.2.4 

ソフトウェア安全ライフサイクルが表1の要求事項を満たしている場合，安全度及びプロジェク

トの複雑さに対応するように，Vモデル（図6参照）をテーラリングしてもよい。 

注記1 この箇条の要求事項を満たしているソフトウェア安全ライフサイクルモデルは，プロジェク

ト又は組織の特定のニーズに合うように適切にテーラリングしてもよい。表1のライフサイ

クルフェーズの一覧表は，新たに開発した大規模なシステムに適している。小規模なシステ

ムでは，例えば，ソフトウェアシステム設計及びアーキテクチャ設計のフェーズを一つにま

とめたほうがよいこともある。 

注記2 ソフトウェア安全ライフサイクルをテーラリングするときに関連してくることがあるデータ

駆動システム（例えば，完全可変／制約可変言語，データ構成の範囲）の特徴については，

附属書Gを参照。 

7.1.2.5 

ソフトウェア安全ライフサイクルのテーラリングは，機能安全に基づいて正当化しなければなら

ない。 

7.1.2.6 

品質及び安全保証手順は，安全ライフサイクル業務に統合しなければならない。 

7.1.2.7 

ライフサイクルフェーズごとに，適切な技法及び手段を採用しなければならない。附属書A及び

附属書Bに，技法及び手段の選択の手引書，並びにIEC 61508-6及びIEC 61508-7の参照先を示している。

参照先であるIEC 61508-6及びIEC 61508-7は，決定論的安全度が求める特性を達成するための，専用技

法に関する推奨を示している。ただし，これらの推奨にある技法を選択したからといって，それだけで，

要求安全度が得られることを保証するわけではない。 

注記 決定論的安全度達成の成否は，次の要素に注意した上での技法の選択にかかっている。 

− 開発サイクル全体で，選択する方法，言語及びツールの整合性及び相補的な性質。 

− 開発者が，完全に理解した方法，言語及びツールを使用しているかどうか。 

− 方法，言語及びツールが，開発中に遭遇する固有の問題にうまく適合するかどうか。 

7.1.2.8 

ソフトウェア安全ライフサイクルにおける業務の結果は，文書化しなければならない（箇条5参

照）。 

注記 JIS C 0508-1の箇条5では，安全ライフサイクルフェーズの文書化した引渡し事項を規定して

いる。E/E/PE安全関連系の開発では，複数の安全ライフサイクルフェーズの引渡し事項が一つ

の独立した文書となることもあるが，複数のフェーズの文書化した引渡し事項を合体すること

もある。安全ライフサイクルフェーズの引渡し事項が，その使用目的に合致するということが

必須要求事項である。 

7.1.2.9 

ソフトウェア安全ライフサイクルのいずれかのフェーズで，先行するライフサイクルフェーズを

部分改修する必要が生じた場合は，影響解析で，どのソフトウェアモジュールが影響を受けるか，及び先

行する安全ライフサイクル業務のどれを繰り返さなければならないか，を決めなければならない。 

注記 ある極端な例では，影響解析が非公式のアセスメントを含むことがある。別の極端な例では，

影響解析が，理解又は実現に不備があることもある，全ての変更案の潜在的悪影響の厳密な形

式的解析を含むことがある。影響解析の手引書についてはIEC 61508-7を参照。 

9 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

図3−E/E/PE系安全ライフサイクル（実現フェーズ） 

図4−ソフトウェア安全ライフサイクル（実現フェーズ） 

10.5 

E/E/PE系の設置， 

引渡し， 

運用及び保全の手順 

10.1 

E/E/PE系設計 

要求仕様 

10.3 

ASIC及びソフトウェア

を含む，E/E/PE系の設計
及び開発（図3及びJIS C 

0508-2も参照） 

E/E/PE系安全ライフサイクル（実現フェーズ） 

10.2 E/E/PE系安全妥当性 

確認計画 

10.4 

E/E/PE系統合 

10.6 

E/E/PE系 

安全妥当性確認 

図2のボックス12へ 

図2のボックス14へ 

10 

E/E/PE安全関連系 

実現 

（E/E/PE系安全ライフ

サイクルを参照） 

各E/E/PE安全 

関連系に対して 

一つのE/E/PE 

安全ライフサイクル 

図2のボックス10 

ソフトウェア安全ライフサイクル(実現フェーズ) 

E/E/PE系安全 

ライフサイクル 

（図3参照） 

PE統合(ハードウェア 

及びソフトウェア) 

ソフトウェアの設計 

及び開発 

ソフトウェア 
安全要求仕様 

ソフトウェアの運用及び 

保全手順 

ソフトウェア関連システ

ム安全妥当性確認 

システム安全のソフト 

ウェアの妥当性確認計画 

図2のボックス14へ 

図2のボックス12へ 

図2のボックス14へ 

図2のボックス12へ 

10 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

図5−JIS C 0508-2とJIS C 0508-3との関係及び適用範囲 

図6−ソフトウェアの決定論的対応能力及び開発ライフサイクル（Vモデル） 

E/E/PE系 

設計要求仕様 

ソフトウェア
安全要求事項 

プログラマブルエレクトロ

ニクス統合(ハードウェア 

及びソフトウェア) 

ソフトウェア
設計及び開発 

プログラマブルエ

レクトロニクス 

設計及び開発 

非プログラマブル
ハードウェア設計

及び開発 

プログラマブル 

電子ハードウェア 

ハードウェア安全要求仕様 

JIS C 0508-3の

適用範囲 

E/E/PE系 

アーキテクチャ

非プログラマブル

ハードウェア 

E/E/PE 

系統合 

JIS C 0508-2の

適用範囲 

妥当性確認 

妥当性確認済 

ソフトウェア 

      引渡し事項 

      適合確認 

E/E/PE系 

安全要求仕様 

ソフトウェア
安全要求仕様 

E/E/PE系 

アーキテクチャ 

ソフトウェア・ 
アーキテクチャ 

ソフトウェア 

システム設計 

妥当性確認 

テスト 

モジュール 

設計 

コーディング 

モジュール 

テスト 

統合テスト 

(モジュール) 

統合テスト（コンポー
ネント，サブシステム
及びプログラマブルエ

レクトロニクス） 

11 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表1−ソフトウェア安全ライフサイクル−概要 

安全ライフ 

サイクルフェーズ 

目的 

範囲 

要求事
項の細
分箇条 

引継ぎ事項 

引渡し事項 

図4の 
ボック
ス番号 

標題 

10.1 

ソフトウェ
ア安全要求
仕様 

安全関連ソフトウェアの要求事項
を，ソフトウェア安全機能要求事
項及びソフトウェア決定論的対応
能力要求事項に関して指定する。 
 
要求する安全機能を履行するため
に必要な各E/E/PE安全関連系のソ
フトウェア安全機能要求事項を指
定する。 
 
各E/E/PE安全関連系について，そ
のE/E/PE安全関連系に割り当てら
れる各安全機能に規定した安全度
水準を達成するために必要なソフ
トウェアの決定論的対応能力要求
事項を指定する。 

PE系 
ソフトウェ
アシステム 

7.2.2 

割当て中に作成
するE/E/PE安
全要求仕様（JIS 
C 0508-1参照） 
 
E/E/PE系安全要
求仕様（JIS C 
0508-2参照） 

ソフトウェア安
全要求仕様 

10.2 

システム安
全のソフト
ウェアの妥
当性確認計
画 

システム安全のソフトウェアの妥
当性確認を実施するための計画を
作成する。 

PE系 
ソフトウェ
アシステム 

7.3.2 

ソフトウェア安
全要求仕様 

システム安全に
関してのソフト
ウェアの妥当性
確認計画 

10.3 

ソフトウェ
アの設計及
び開発 

アーキテクチャ 
 
要求安全度水準に関して，安全関
連ソフトウェアに規定している要
求事項を満たすソフトウェアアー
キテクチャを構築する。 
 
E/E/PE安全関連系のハードウェア
アーキテクチャによって決まるソ
フトウェアの要求事項を，管理下
にある機器の安全に関するE/E/PE
ハードウェア／ソフトウェア相互
作用の重要性も含めて評価する。 

PE系 
ソフトウェ
アシステム 

7.4.3 

ソフトウェア安
全要求仕様 
 
E/E/PE系ハード
ウェアアーキテ
クチャ設計（JIS 
C 0508-2参照） 

ソフトウェアア
ーキテクチャ設
計 
 
ソフトウェアア
ーキテクチャ統
合テスト仕様 
 
ソフトウェア
/PE統合テスト
仕様（JIS C 
0508-2が要求す
るものと同じ） 

12 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表1−ソフトウェア安全ライフサイクル−概要（続き） 

安全ライフ 

サイクルフェーズ 

目的 

範囲 

要求事
項の細
分箇条 

引継ぎ事項 

引渡し事項 

図4の 
ボック
ス番号 

標題 

10.3 

ソフトウェ
アの設計及
び開発 

支援ツール及びプログラミング言
語 
 
ソフトウェアの安全ライフサイク
ル全体において，要求安全度水準
の適合確認，妥当性確認，評価及
び部分改修を支援するための，言
語及びコンパイラ，ランタイムシ
ステムインタフェース，ユーザイ
ンタフェース並びにデータの形式
及び表現方法を含むツール群を選
択する。 

PE系 
 
ソフトウェ
アシステム 
 
支援ツール 
 
プログラミ
ング言語 

7.4.4 

ソフトウェア安
全要求仕様 
 
ソフトウェアア
ーキテクチャ設
計 

支援ツール及び
コーディング規
約 
 
開発ツールの選
択 

10.3 

ソフトウェ
アの設計及
び開発 

詳細設計及び開発 （ソフトウェア
システム設計） 
 
要求安全度水準に対する安全関連
ソフトウェアの要求事項を満た
し，解析及び検証が可能で安全に
部分改修できるソフトウェアの設
計及び実装を行う。 

ソフトウェ
アアーキテ
クチャ設計
の主要要素
及びサブシ
ステム 

7.4.5 

ソフトウェアア
ーキテクチャ設
計 
 
支援ツール及び
コーディング規
約 

ソフトウェアシ
ステム設計仕様 
 
ソフトウェアシ
ステム統合テス
ト仕様 

10.3 

ソフトウェ
アの設計及
び開発 

詳細コード実装 
 
要求安全度水準に対する安全関連
ソフトウェアの要求事項を満た
し，解析及び検証が可能で安全に
部分改修できるソフトウェアの設
計及び実装を行う。 

個別ソフト
ウェアモジ
ュール 

7.4.6 

ソフトウェアモ
ジュール設計仕
様 
 
支援ツール及び
コーディング規
約 

ソースコードリ
スト 
 
コード審査報告
書 

10.3 

ソフトウェ
アの設計及
び開発 

ソフトウェアモジュールテスト 
 
安全関連ソフトウェアの（要求す
るソフトウェア安全機能及びソフ
トウェアの決定論的対応能力に関
する）要求事項を達成しているこ
とを検証する。 
 
各ソフトウェアモジュールが意図
する機能を実行し，意図しない機
能を実行することがないことを示
す。 
 
PE系の構成が，ソフトウェアの決
定論的対応能力に関する要求事項
を満たしていることを，適切な範
囲でデータによって保証する。 

ソフトウェ
アモジュー
ル 

7.4.7 

ソフトウェアモ
ジュールテスト
仕様 
 
ソースコードリ
スト 
 
コード審査報告
書 

ソフトウェアモ
ジュールテスト
結果 
 
適合確認・テス
トしたソフトウ
ェアモジュール 

13 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表1−ソフトウェア安全ライフサイクル−概要（続き） 

安全ライフ 

サイクルフェーズ 

目的 

範囲 

要求事
項の細
分箇条 

引継ぎ事項 

引渡し事項 

図4の 
ボック
ス番号 

標題 

10.3 

ソフトウェ
アの設計及
び開発 

ソフトウェア統合テスト 
 
安全関連ソフトウェアの（要求す
るソフトウェア安全機能及びソフ
トウェアの決定論的対応能力に関
する）要求事項を達成しているこ
とを検証する。 
 
全てのソフトウェアモジュール，
要素及びサブシステムが正しく相
互に作用し合い，意図する機能を
実行し，意図しない機能を実行す
ることがないことを示す。 
 
PE系の構成が，ソフトウェアの決
定論的対応能力に関する要求事項
を満たしていることを，適切な範
囲でデータによって保証する。 

ソフトウェ
アアーキテ
クチャ 
 
ソフトウェ
アシステム 

7.4.8 

ソフトウェアシ
ステム統合テス
ト仕様 

ソフトウェアシ
ステム統合テス
ト結果 
 
検証・テストし
たソフトウェア
システム 

10.4 

プログラマ
ブル電子装
置統合 
 

（ハードウェ

ア及びソフ
トウェア） 

ソフトウェアを目標プログラマブ
ル電子ハードウェアに統合する。 
 
安全関連プログラマブル電子装置
のソフトウェア及びハードウェア
を，それらの両立性を保証し，目
標とする安全度水準の要求事項を
満たすようにして組み合わせる。 

プログラマ
ブル電子ハ
ードウェア 
 
統合ソフト
ウェア 

7.5.2 

ソフトウェアア
ーキテクチャ統
合テスト仕様 
 
ソフトウェアと
PEとの統合テ
スト仕様（第2
部でも要求） 
 
統合プログラマ
ブル電子装置 

ソフトウェアア
ーキテクチャ統
合テスト結果 
 
プログラマブル
電子装置統合テ
スト結果 
 
検証・テストし
た統合プログラ
マブル電子装置 

10.5 

ソフトウェ
アの運用及
び部分改修
手順 

運用及び部分改修中の，E/E/PE安
全関連系の機能安全の維持を保証
するための，ソフトウェアに関す
る必要な情報及び手順を提供す
る。 

同上 

7.6.2 

上記全てで関連
するもの 

ソフトウェア運
用及び部分改修
手順 

10.6 

ソフトウェ
ア関連シス
テム安全妥
当性確認 

統合システムが，安全関連ソフト
ウェアに規定する，目標安全度水
準の要求事項に適合していること
を保証する。 

同上 

7.7.2 

ソフトウェア関
連システム安全
妥当性確認計画 

ソフトウェア安
全妥当性確認結
果 
 
妥当性確認した
ソフトウェア 

14 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表1−ソフトウェア安全ライフサイクル−概要（続き） 

安全ライフ 

サイクルフェーズ 

目的 

範囲 

要求事
項の細
分箇条 

引継ぎ事項 

引渡し事項 

図4の 
ボック
ス番号 

標題 

− 

ソフトウェ
ア部分改修 

要求するソフトウェアの決定論的
対応能力の保持を保証する，妥当
性確認したソフトウェアの修正，
拡張又は改編を手引きする。 

同上 

7.8.2 

ソフトウェア部
分改修の手順 
ソフトウェア部
分改修の要請 

ソフトウェア部
分改修の影響解
析結果 
 
ソフトウェア部
分改修ログ 

− 

ソフトウェ
ア適合確認 

所定のソフトウェア安全ライフサ
イクルフェーズの引渡し事項のテ
スト及び評価を行い，そのフェー
ズの引継ぎ事項となる引渡し事項
及び基準に関しての正確さと一貫
性を保証する。 

フェーズに
よる 

7.9.2 

適切な適合確認
計画書（フェー
ズによる） 

適切な適合確認
報告書（フェー
ズによる） 

− 

ソフトウェ
アの機能安
全評価 

E/E/PE安全関連系が達成する機能
安全のソフトウェアに関して調査
し，判定に至る。 

上記の全て
のフェーズ 

8 

ソフトウェア機
能安全評価計画 

ソフトウェア機
能安全評価報告 

7.2 

ソフトウェア安全要求仕様 

注記 このフェーズは，図4のボックス10.1である。 

7.2.1 

目的 

7.2.1.1 

この箇条の要求事項の第1の目的は，ソフトウェア安全機能要求事項及びソフトウェアの決定論

的対応能力の要求事項に関して，安全関連ソフトウェアの要求事項を，規定することである。 

7.2.1.2 

この箇条の要求事項の第2の目的は，各E/E/PE安全関連系について，要求する安全機能を履行

するために必要なソフトウェア安全機能要求事項を，規定することである。 

7.2.1.3 

この箇条の要求事項の第3の目的は，E/E/PE安全関連系に割り当てた，それぞれの安全機能で規

定する安全度水準の達成に必要な各E/E/PE安全関連系について，ソフトウェアの決定論的対応能力に関す

る要求事項を，規定することである。 

7.2.2 

要求事項 

注記1 大半の場合，これらの要求事項は，一般的な組込みソフトウェアとアプリケーション専用ソ

フトウェアとの組合せによって達成する。これは，7.2.2.1〜7.2.2.13を満たす特徴を得るため

に要求する組合せである。一般的な組込みソフトウェアとアプリケーション専用ソフトウェ

アとの正確な区分は，選択したソフトウェアアーキテクチャ（7.4.3参照）によって異なる。 

注記2 この箇条の要求事項を実現するために適切な技法及び手段の選択については，ソフトウェア

安全要求仕様の次の特性（特性の解釈に関する手引書については附属書Cを，非形式の定義

についてはIEC 61508-7の附属書Fを参照）を検討することが望ましい。 

− ソフトウェアで対応する安全ニーズの完全性 

− ソフトウェアで対応する安全ニーズの正確性 

− 曖昧さの回避を含む，固有仕様フォールトの回避性 

− 安全要求事項の理解容易性 

15 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− ソフトウェアの安全以外の機能が安全機能へ危険な干渉を及ぼさない性質 

− 適合確認及び妥当性確認の基礎となる対応能力 

注記3 ソフトウェアで対応しなければならない安全ニーズは安全機能の集合であり，E/E/PE系の設

計によってソフトウェア機能に割り当てる安全度要求事項に該当する（システム安全ニーズ

の完全な集合は，ソフトウェアに依存しない安全機能も含む，より大きな集合である）。ソフ

トウェア安全要求仕様の完全性は，先行するシステムライフサイクルフェーズの有効性に大

きく依存する。 

7.2.2.1 

E/E/PE安全関連系に関して，安全関連ソフトウェアの要求事項を既に規定している場合（JIS C 

0508-2の箇条7参照）は，ソフトウェア安全要求事項を，再度規定する必要はない。 

7.2.2.2 

安全関連ソフトウェアの要求仕様は，E/E/PE安全関連系の特定の安全要求事項（JIS C 0508-2の

箇条7を参照）及び安全計画の要求事項（箇条6参照）から導き出さなければならない。この情報は，ソ

フトウェア開発者が利用できるようにしなければならない。 

注記1 この要求事項は，E/E/PE系の開発者とソフトウェアの開発者（JIS C 0508-2及びJIS C 0508-3）

との間に，重複又は繰返しがまったくないということを意味するものではない。安全関連ソ

フトウェアの要求事項及びソフトウェアアーキテクチャは厳密なものになるので，E/E/PE系

ハードウェアアーキテクチャに影響が出ることがあり，そのため，ハードウェア開発者とソ

フトウェア開発者との間の緊密な協力が不可欠である。図5を参照。 

注記2 ソフトウェア設計が以前からある再利用可能なソフトウェアを組み込んでいる場合，そのソ

フトウェアは，現行のシステム要求仕様を考慮せずに開発したものであってもよい。ソフト

ウェア安全要求仕様を満たすための，既存のソフトウェアに求められる要求事項については

7.4.2.12を参照。 

7.2.2.3 

安全関連ソフトウェアの要求仕様は，設計及び実行が，要求する安全度（独立性に関する要求事

項を含む，JIS C 0508-2の7.4.3参照）を達成し，機能安全の評価が実施できる程度に十分に詳細なもので

なければならない。 

注記 仕様の詳細レベルは，アプリケーションの複雑さによって変わることがある。機能的動作の適

切な仕様は，正確性，タイミング及び性能，容量，堅ろう（牢）さ，過負荷耐性，その他具体

的なアプリケーションの特徴的特性などに関する要求事項を含んでいてよい。 

7.2.2.4 

独立性を保つために，適切な共通原因故障分析を実施しなければならない。確実な故障メカニズ

ムを識別した場合は，有効な防護策をとらなければならない。 

注記 ソフトウェアの独立性の一面を達成するための技法については，附属書Fを参照。 

7.2.2.5 

ソフトウェア開発者は，要求事項を十分に指定していることを確認するために，7.2.2.2の情報を

評価しなければならない。ソフトウェア開発者は，特に，次の事項を考慮しなければならない。 

a) 安全機能 

b) システムの構成又はアーキテクチャ 

c) ハードウェア安全度要求事項（プログラマブル電子装置，センサ及びアクチュエータ）  

d) ソフトウェア決定論的対応能力要求事項 

e) 容量及び応答時間 

f) 

機器及びオペレータインタフェース，合理的に予測可能な誤使用を含む。 

注記 既存の何らかのアプリケーションとの両立性を考慮することが望ましい。 

7.2.2.6 

E/E/PE安全関連系の規定の安全要求事項で，まだ適切に定義していない場合，EUC（被制御機器），

16 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

E/E/PE系及び，E/E/PE系に接続するあらゆる機器又はシステムの関連する全ての運用モードについて，安

全関連ソフトウェアに関して規定する要求事項として詳述しなければならない。 

7.2.2.7 

ソフトウェア安全要求仕様では，ハードウェアとソフトウェアとの間の安全関連の制約又は関係

ある制約の全てを規定し，文書化しなければならない。 

7.2.2.8 

E/E/PEハードウェアアーキテクチャ設計が要求する範囲まで，考えられる複雑さの増大を考慮し

ながら，ソフトウェア安全要求仕様で次の事項を考慮しなければならない。 

a) ソフトウェア自己監視（例えば，IEC 61508-7参照） 

b) プログラマブル電子装置ハードウェア，センサ及びアクチュエータの監視 

c) システム稼働中の安全機能の定期テスト 

d) EUC運用時に，安全機能のテストが可能 

e) E/E/PE安全関連系の安全度要求事項を満たすために，プルーフテスト及び全ての診断テストを実行す

るソフトウェア機能。 

注記 上記の検討事項の結果，複雑さが増せば，アーキテクチャを再検討する必要が生じることがあ

る。 

7.2.2.9 

安全以外の機能を履行するためにE/E/PE安全関連系が必要となるときは，安全関連ソフトウェ

アに規定する要求事項で，その安全以外の機能を明確に規定しなければならない。 

注記 安全機能と安全以外の機能との不干渉に関する要求事項については，7.4.2.8及び7.4.2.9を参照。 

7.2.2.10 ソフトウェア安全要求仕様では，要求する製品の安全特性を明示しなければならないが，プロジ

ェクトの安全特性は安全計画で取り上げるので明示する必要はない（JIS C 0508-1の箇条6参照）。7.2.2.1

〜7.2.2.9を参照して，適宜，次の事項を規定しなければならない。 

a) ソフトウェア安全機能に関する次の要求事項 

1) EUCで安全状態を達成又は維持できるようにする機能 

2) プログラマブル電子装置ハードウェアのフォールトの検出，報知及び管理に関する機能 

3) センサ及びアクチュエータのフォールトの検出，報知及び管理に関する機能 

4) ソフトウェア自体のフォールトの検出，報知及び管理に関する機能（ソフトウェア自己監視） 

5) 安全機能のオンライン（すなわち，想定する運用環境での）定期テストに関する機能 

6) 安全機能のオフライン（すなわち，安全機能に関してEUCに頼っていない場合の環境での）定期テ

ストに関する機能 

7) PEシステムを安全に部分改修することを許可する機能 

8) 非安全関連機能へのインタフェース 

9) 容量及び応答時間特性 

10) ソフトウェアとPEシステム間のインタフェース 

注記1 インタフェースは，オフライン及びオンラインプログラミング設備を含む。 

11) 安全関連通信（JIS C 0508-2の7.4.11参照）。 

b) ソフトウェアの決定論的対応能力に関する次の要求事項 

1) 上記a) の各機能の安全度水準 

注記2 ソフトウェア要素への安全度の割当てに関する情報については，IEC 61508-5の附属書A

を参照。 

2) 機能間の独立性要求事項 

7.2.2.11 ソフトウェア安全要求事項を構成データが表現又は実現している場合，そのデータは次のように

17 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

なっていなければならない。 

a) システム安全要求事項との一貫性がある。 

b) その運用パラメータの許容範囲及び許可した組合せによって表現している。 

c) 基本となるソフトウェア（例えば，実行のシーケンス，ランタイム，データ構造など）と互換性が保

てる方法で定義している。 

注記1 このアプリケーションデータに関する要求事項は，特にデータ駆動アプリケーションに関す

るものである。このようなアプリケーションは，次のような特徴をもっている。すなわち，

ソースコードが事前に存在し，開発業務の主な目的は構成データが正しく，アプリケーショ

ンの要求する挙動を明示しているという保証を与えることである。データ項目間には複雑な

依存関係があり，データの妥当性は経時的に変化することがある。 

注記2 データ駆動システムの手引書については，附属書Gを参照。 

7.2.2.12 データがソフトウェアと外部システムとの間のインタフェースを定義している場合は，JIS C 

0508-2の7.4.11に加えて，次の性能特性を検討しなければならない。 

a) データ定義を整合させる必要性 

b) 無効な，範囲外の又は時間外の値 

c) 最大ローディング条件を含む応答時間及びスループット 

d) 最善及び最悪の実行時間及びデッドロック 

e) データ記憶容量のオーバフロー及びアンダフロー 

7.2.2.13 運用パラメータは，次のものから保護しなければならない。 

a) 無効な，範囲外の又は時間外の値 

b) 不正な変更 

c) 破損 

注記1 不正な変更の防止は，ソフトウェアによるものとソフトウェアによらないメカニズムの両方

を考慮して検討することが望ましい。不正なソフトウェアの変更に対する有効な防護が，例

えば，ストレスの多い状態で急に変更が必要になるときなど，安全に悪影響を及ぼすことが

あることに注意する。 

注記2 人が安全関連系の一部を形成することがあるが（JIS C 0508-1の箇条1参照），E/E/PE安全関

連系に関するヒューマンファクタに対する要求事項については，この規格では詳述しない。

ただし，人に関する次の考慮事項については，適宜，対応することが望ましい。 

− オペレータ情報システムには，運転員が慣れ親しんでいる，目で見て分かるレイアウト

及び用語を使用することが望ましい。明確で，理解しやすく，不必要な細かさ又は不必

要な表示のないものであることが望ましい。 

− 運転員の目にするEUCに関する情報は，EUCの物理的配置をしっかりと追随するもの

であることが望ましい。 

− 複数のディスプレイの内容を運転員が目にすることがある場合，及び／又は運転員が行

うと考えられる動作が結果を一目で見ることができないやりとりを伴うことがある場合，

表示する情報は，ディスプレイ又は動作シーケンスの各状態で，シーケンスのどの状態

に達したか，どの操作が実行可能であるか，考えられる結果のどれを選択できるかを自

動的に含むものであることが望ましい。 

7.3 

システム安全のソフトウェアの妥当性確認計画 

18 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

注記1 このフェーズは，図4のボックス10.2である。 

注記2 ソフトウェアは，通常，基本となるハードウェア及びシステム環境と切り離して妥当性確認

を行うことができない。 

7.3.1 

目的 

この箇条の要求事項の目的は，システム安全の安全関連ソフトウェアの妥当性確認計画を開発すること

である。 

7.3.2 

要求事項 

7.3.2.1 

ソフトウェアがその安全要求事項を満たしていることを実証するために用いる，手順上及び技術

上のステップについて，計画を策定しなければならない。 

7.3.2.2 システム安全のソフトウェアに関する妥当性確認計画では，次の事項を検討しなければならない。 

a) 妥当性確認をいつ行うかの詳細 

b) 妥当性確認実施担当者の詳細 

c) 次の事項を含む関連EUC運用モードの識別 

1) 設定及び調整を含む，使用準備 

2) 始動，教示（ロボット，自動機械などに人が作業方法を教える作業），自動，手動，半自動，定常状

態運用 

3) リセット，シャットダウン，保守 

4) 合理的に予測可能な異常状態，及び合理的に予測可能な運転員の誤操作 

d) 引渡しを開始する前に，EUCの各運用モードについて妥当性確認を必要とする安全関連ソフトウェア

の特定 

e) 妥当性確認の技術的方策（例えば，解析方法，統計的テストなど） 

f) 

e) に従い，各安全機能が，規定の安全機能要求事項及び，規定のソフトウェアの決定論的対応能力の

要求事項に適合していることを確認するために用いなければならない手段（技法）及び手順 

g) 妥当性確認業務を実施する際，必要となる環境（例えば，テスト用として，校正済ツール及び機器を

含むことがある。） 

h) 合否判定基準 

i) 

妥当性確認の結果，特に故障を評価するための方針及び手順 

注記 これらの要求事項は，JIS C 0508-1の7.8に規定する一般要求事項に基づいている。 

7.3.2.3 

妥当性確認では，その戦略の選択した論理的根拠を示さなければならない。安全関連ソフトウェ

アの妥当性確認の技術戦略には，次の情報を含めなければならない。 

a) 手動若しくは自動の技法，又はその両方の選択 

b) 静的若しくは動的の技法，又はその両方の選択 

c) 解析的若しくは統計的な技法，又はその両方の選択 

d) 客観的要因若しくは専門家の判断，又はその両方に基づく合否判定基準の選択。 

7.3.2.4 

安全度水準によって必要となる場合，安全関連ソフトウェアの妥当性確認手順の一部として，シ

ステム安全のソフトウェアの妥当性確認計画の適用範囲及び内容については，アセッサ又はアセッサを代

表する当事者との間で合意しておかなければならない（JIS C 0508-1の箇条8参照）。また，この手順では，

テスト中にアセッサが立ち会っていたことについても明言しなければならない。 

7.3.2.5 

ソフトウェア妥当性確認を達成するための合否判定基準は，次の事項を含んでいなければならな

い。 

19 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

a) シーケンスに加えて，必要となる入力信号及びそれらの値 

b) シーケンスに加えて，予想する出力信号及びそれらの値 

c) その他の合格判定基準。例えば，メモリ消費量，タイミング，値の許容差など。 

7.4 

ソフトウェア設計及び開発 

注記 このフェーズは，図4のボックス10.3である。 

7.4.1 

目的 

7.4.1.1 

この箇条の要求事項の第1の目的は，要求安全度水準に関して，安全関連ソフトウェアで規定す

る要求事項を満たすソフトウェアアーキテクチャを構築することである。 

7.4.1.2 

この箇条の要求事項の第2の目的は，E/E/PE安全関連系のハードウェアアーキテクチャによって

ソフトウェアに課した要求事項を，管理下にある機器の安全に関するE/E/PEハードウェア及びソフトウェ

ア相互作用の重要性も含めて評価することである。 

7.4.1.3 

この箇条の要求事項の第3の目的は，適合確認，妥当性確認，評価及び部分改修を補佐するソフ

トウェアの安全ライフサイクル全体で，要求安全度水準の言語及びコンパイラ，ランタイムシステムイン

タフェース，ユーザインタフェース，並びにデータ形式及び表現を含めた，適切な一組のツールを選択す

ることである。 

7.4.1.4 

この箇条の要求事項の第4の目的は，要求安全度水準で安全関連ソフトウェアで規定する要求事

項を満たし，解析及び妥当性確認が可能で，安全に部分改修することができるソフトウェアを設計し，実

現することである。 

7.4.1.5 

この箇条の要求事項の第5の目的は，安全関連ソフトウェアの要求事項を（要求するソフトウェ

ア安全機能及びソフトウェアの決定論的対応能力に関して）達成していることを検証することである。 

7.4.1.6 

この箇条の要求事項の第6の目的は，それが適切である限り，データによってPE系の構成が，

ソフトウェアの決定論的対応能力に関する規定の要求事項を満たしていることを確認することである。 

7.4.2 

一般要求事項 

7.4.2.1 

ソフトウェア開発の性質に応じて，7.4への適合責任は，安全関連プログラミング環境の供給者

［例えば，PLC（Programmable Logic Controller）の供給者］にあることもあれば，その環境の使用者（例

えば，アプリケーションソフトウェア開発者）にあることもあり，またその両者にあることもある。責任

分担は，安全計画時に決めなければならない（箇条6参照）。 

注記 実際の責任分担の決定に関連するシステム及びソフトウェアアーキテクチャの側面について

は，7.4.3を参照。 

7.4.2.2 

要求安全度水準及び安全機能専用の技術的要求事項に従って，選択する設計方法は，次の事項を

円滑にする特性をもつものでなければならない。 

a) 抽象化，モジュール化，複雑さを管理するその他の特徴 

b) 次のものの表現 

1) 機能性 

2) 要素間の情報フロー 

3) シーケンス及び時間関連情報 

4) タイミング制約 

5) 共有資源への同時処理及び同期アクセス 

6) データ構成，及びそれらの特性 

7) 設計の前提，及びそれらの依存関係 

20 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

8) 例外の取扱い 

9) 設計の前提（事前条件，事後条件，不変点）  

10) コメント（関係者又は第三者の当該ソフトウェアに対する所見，注釈など） 

c) 構成及び挙動の見方を含めて，設計について複数の見方を表現する能力 

d) 開発者，及び設計を理解する必要があるその他の人員による理解力 

e) 適合確認及び妥当性確認 

7.4.2.3 

最終安全関連系において，テスト可能性及び安全な部分改修の可能性について，これらの特性の

実装を円滑にするために，設計業務中に検討しなければならない。 

注記 例としては，機械類及びプロセスプラントの保全モードが挙げられる。 

7.4.2.4 

選択した設計方法は，ソフトウェア部分改修を容易にする機能をもたなければならない。そのよ

うな機能としては，モジュール化，情報隠匿，カプセル化などがある。 

注記 F.7を参照。 

7.4.2.5 

設計表現は，明確に定義した表記法又は明確に定義した機能に限定した表記法に基づくものでな

ければならない。 

7.4.2.6 

実行可能であれば，設計は，ソフトウェアの安全関連部分を簡易なものに保たなければならない。 

7.4.2.7 

ソフトウェア設計は，要求安全度水準に応じて，制御の流れ及びデータフローの自己監視を含ん

でいなければならない。故障を検出したときは，適切な措置を講じなければならない。 

7.4.2.8 

ソフトウェアが安全機能及び安全以外の機能の両方を履行する場合は，適切な設計手段によっ

て，安全以外の機能の故障が安全機能に悪影響を及ぼすことがないことを確証しなければ，ソフトウェア

全体を安全関連ソフトウェアとして取り扱わなければならない。 

7.4.2.9 

ソフトウェアが安全度水準の異なる安全機能を履行する場合は，設計において，安全度水準の異

なる安全機能間の適切な独立性を示すことができない限り，ソフトウェア全体をその最も高い安全度水準

に属するものとして取り扱わなければならない。独立性を時間域かつ空間的領域の両方で達成しているか，

又は独立性の侵害を制御しているかのいずれかを実証しなければならない。独立性の正当な根拠は文書化

しなければならない。 

注記 ソフトウェアの独立性を達成するための技法については，附属書Fを参照。 

7.4.2.10 ソフトウェア要素の決定論的対応能力が，そのソフトウェア要素が支援する安全機能の安全度水

準より低い場合，その要素は他の要素と組み合わせて使用し，組み合わせたものの決定論的対応能力が安

全機能の安全度水準と等しくなるようにしなければならない。 

7.4.2.11 決定論的対応能力が分かっているソフトウェア要素の組合せを用いて安全機能を実現している

場合，その要素の組合せには，JIS C 0508-2の7.4.3の決定論的対応能力の要求事項を適用しなければなら

ない。 

注記 一つ以上の要素によって支援している“エンドツーエンド安全機能”及び支援する要素の各々

の要素安全機能とを，確実に区別する。より高い決定論的対応能力を達成するために，二つの

要素を組み合わせる場合，ペアの要素のそれぞれが危険事象を防止又は軽減できるものである

ことが望ましい。ただし，ペアの要素が同一の要素安全機能をもつ必要はなく，ペアの要素の

それぞれが独立して，その組合せに求められている安全機能の全てを提供する必要はない。 

例 エンドツーエンド安全機能が“要求していない加速の防止”である電子エンジンスロットル制御

装置。エンドツーエンド安全機能は，二つのプロセッサによって実現する。一次制御装置の要素

安全機能は，スロットルの理想的要求及び応答挙動である。二次プロセッサの要素安全機能はダ

21 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

イバースモニタであり（IEC 61508-7のC.3.4参照），必要に応じて，非常停止に適用する。二つ

のプロセッサの組合せで，エンドツーエンド安全機能で“要求していない加速の防止”を達成す

るという高い信頼性を与える。 

7.4.2.12 既存のソフトウェア要素を再利用して，安全機能の全て又は一部を実現する場合，その要素は，

決定論的安全度に関して，次のa) 及びb) の両方の要求事項を満たさなければならない。 

a) 次の適合ルートのうちいずれか一つの要求事項に適合 

− ルート1S：適合開発。ソフトウェアの決定論的原因フォールトの回避及び制御のための，この規格

の要求事項への適合 

− ルート2S：使用における実証。要素を使用において実証しているという証拠を示す。JIS C 0508-2

の7.4.10参照 

− ルート3S：非適合開発の評価。7.4.2.13への適合 

注記1 ルート1S，2S及び3Sは，特にソフトウェア要素に依拠したJIS C 0508-2の7.4.2.2 c) の要素

の適合ルートである。ここに転載したのは，JIS C 0508-2を参照することを最小限にするた

めにすぎない。 

注記2 JIS C 0508-4の3.2.8を参照。既存のソフトウェアとは，市販のソフトウェア，又は旧製品若

しくは旧システム用にどこかの組織が開発したものである。既存のソフトウェアは，この規

格の要求事項に従って開発したものでもよいし，そうでないものでもよい。 

注記3 既存の要素に関する要求事項は，ランタイムライブラリ又はインタプリタに適用する。 

b) 既存のソフトウェア要素に全面的に，又は一部が依存している当該安全機能の評価が可能となるよう

な，要素についての十分に詳細で完全な記述をもつ安全マニュアル（JIS C 0508-2の附属書D及びこ

の規格の附属書D参照）を提供する。 

注記4 安全マニュアルは，要素提供者自身の文書及び要素提供者の開発プロセスの記録から取り出

したものでもよいし，安全関連系の開発者又は第三者が行う追加認定業務で作成又は補足し

たものでもよい。場合によっては，施行している法的条件（著作権，知的財産権など）に従

って，この箇条の要求事項を満たすために，妥当な仕様又は設計文書を作成する必要が生じ

ることもある。 

注記5 要素の正当な根拠は，安全計画時に開発してもよい（箇条6参照）。 

7.4.2.13 ルート3Sに適合するために，既存のソフトウェア要素は，次のa)〜i) の全ての要求事項を満た

さなければならない。 

a) 要素を新規に利用する場合のその要素のソフトウェア安全要求仕様は，この規格が同じ決定論的対応

能力をもつ安全関連要素に求めているものと同一の精度で文書化しなければならない。ソフトウェア

安全要求仕様には，新規のアプリケーションでその要素に適用し，7.2に規定する機能及び安全挙動を

含まなければならない。表A.1を参照。 

b) ソフトウェア要素の使用に関する正当化は，附属書Cの手引書を考慮しながら，参照しなければなら

ない箇条（すなわち，7.2.2，7.4.3，7.4.4，7.4.5，7.4.6，7.4.7，7.5.2，7.7.2，7.8.2，7.9.2及び箇条8）

で求められている安全特性について検討したという証拠を，提示しなければならない。 

c) 要素の設計は，要求仕様及び要求する決定論的対応能力への適合性を示すのに十分な程度の詳細さで，

文書化しなければならない。7.4.3，7.4.5，7.4.6並びに表A.2及び表A.4を参照。 

d) a) 及びb) で求めている証拠は，ソフトウェアとハードウェアとの統合に関するものでなければなら

ない。7.5及び表A.6を参照。 

22 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

e) 要素の設計及びコードの全ての部分の文書化したテスト及び見直しを含む決定論的アプローチを用い

て，要素が適合確認及び妥当性確認を受けたという証拠がなければならない。7.4.7，7.4.8，7.5，7.7

及び7.9，表A.5〜表A.7及び表A.9，並びに附属書Bの関連する表を参照。 

注記1 実際の運用経験を用いて，ブラックボックス及び確率論的テスト要求事項を満たしてもよ

い（表A.7及び表B.3参照）。 

f) 

ソフトウェア要素が，安全関連系で要求していない機能を提供している場合，要求していない機能の

ために，E/E/PE系がその安全要求事項を満たすことが妨げられることはないという証拠を，示さなけ

ればならない。 

注記2 この要求事項を満たす方法としては，次のものが挙げられる。 

− その機能をソフトウェア（ビルド）から取り除く 

− その機能を無効にする 

− 適切なシステムアーキテクチャ［例えば，パーティショニング，ラッパー，ダイバシ

ティ，アウトプットの信ぴょう（憑）性チェック］ 

− 広範なテスト 

g) ソフトウェア要素の全ての信ぴょう（憑）性のある故障メカニズムを特定し，適切な軽減策を導入し

たという証拠がなければならない。 

注記3 適切な軽減策としては，次のものが挙げられる。 

− 適切なシステムアーキテクチャ［例えば，パーティショニング，ラッパー，ダイバシ

ティ，アウトプットの信ぴょう（憑）性チェック］ 

− 例外処理 

h) 要素の使用計画では，ソフトウェア要素の構成，ソフトウェア及びハードウェアランタイム環境，並

びに，必要に応じて，コンパイル又はリンクシステムの構成を，明らかにしなければならない。 

i) 

要素の使用理由は，要素の適合項目安全マニュアルで定めている前提を遵守するアプリケーションだ

けで有効なものでなければならない（附属書D，及びJIS C 0508-2の附属書D参照）。 

7.4.2.14 この7.4.2は，それが妥当である限り，データ及びデータ生成言語に適用し，次のa)〜d) の要求

事項を満たさなければならない。 

注記 データ駆動システムの手引書については，附属書Gを参照。 

a) PEシステムが，専用のアプリケーション要求事項を満たすように，データによって構成される既存の

機能性から成る場合，アプリケーションソフトウェアの設計は，アプリケーションのコンフィギュア

ビリティ（構成の容易性），事前に配付した既存の機能，及びPE安全関連系の複雑さの程度に相応の

ものでなければならない。 

b) PEシステムの安全関連機能が相当程度，又は主に，構成データによって決められている場合，適切な

技法及び手段を採用して，構成データの設計，生成，ローディング及び部分改修時にフォールトの導

入を防ぎ，構成データが正しくアプリケーションロジックを明示するようにしなければならない。 

c) データ構成の仕様は，次による。 

1) アプリケーションデータを含めて，システムの機能要求事項に整合していなければならない。 

2) 完全でなければならない。 

3) 自己矛盾のないものでなければならない。 

4) データ構成を改変又は破壊から保護するものでなければならない。 

d) PEシステムが，専用のアプリケーション要求事項を満たすように，データによって構成される既存の

23 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

機能性から成る場合は，構成プロセス自体を適切に文書化しなければならない。 

7.4.3 

ソフトウェアアーキテクチャ設計の要求事項 

注記1 ソフトウェアアーキテクチャは，ソフトウェアの主要な要素及びサブシステム，それらをど

のように相互接続するか，並びに要求する属性，特に安全度をどのように達成するかを定義

している。ソフトウェア全体の挙動，及びどのようにソフトウェア要素がインタフェースし

て作用し合うかも定義している。主要なソフトウェア要素の例としては，オペレーティング

システム，データベース，EUC入出力サブシステム，通信サブシステム，アプリケーション

プログラム，プログラミングツール，診断ツールなどがある。 

注記2 産業分野によっては，ソフトウェアアーキテクチャは，機能説明又は機能設計仕様（ただし，

これらの文書にはハードウェアも含まれる）と呼ばれることもある。 

注記3 特にPLC（IEC 61508-6の附属書E参照）の使用者アプリケーションプログラミングでは，

ソフトウェアアーキテクチャが，製品の標準機能として供給者が提供する。供給者は，この

規格に従って，使用者に，製品が7.4の要求事項に適合していることを保証するように要求

している。使用者は，例えば，ラダーロジックなどの標準プログラミング能力を用いて，PLC

をアプリケーションに合わせてカスタマイズする。7.4.3〜7.4.8の要求事項も適用する。ソフ

トウェアアーキテクチャを定義し，文書化するための要求事項は，使用者がアプリケーショ

ン用のPLC（又は同等のもの）の選択に用いる情報と解釈できる。 

注記4 安全の観点からいうと，ソフトウェアアーキテクチャフェーズ（図4の10.3）は，ソフトウ

ェア用に基本安全対策を開発する段階である。 

注記5 この規格群及びIEC 61508の規格群は，E/E/PE安全関連系によって実施する安全機能の数値

的目標機能失敗尺度を設定しているが，決定論的安全度（JIS C 0508-4の3.5.6参照）は，通

常，定量化しておらず，ソフトウェア安全度（JIS C 0508-4の3.5.5参照）は，1〜4の信頼性

尺度における決定論的対応能力（JIS C 0508-4の3.5.9参照）として定義している。この規格

は，ソフトウェア故障が，ソフトウェアの具体的な使用に応じて安全なものにもなれば，安

全でないものにもなるものと認識している。システム又はソフトウェアアーキテクチャは，

アーキテクチャ上の制約によって，ある要素の安全でない故障を制限し，開発方法でこうし

た制約を考慮する必要がある。この規格は，要求する決定論的対応能力によって，定性的な

一貫した厳密さで，開発及び妥当性確認技法に適用する。 

注記6 この箇条の要求事項を実現するための適切な技法及び手段（附属書A及び附属書B参照）を

選択する場合，ソフトウェアアーキテクチャ設計の次の特性（特性の解釈の手引書について

はIEC 61508-7の附属書Cを，参考となる定義については附属書Fを参照。）を検討するこ

とが望ましい。 

− ソフトウェア安全要求仕様の完全性 

− ソフトウェア安全要求仕様の正確性 

− 固有設計フォールトの回避性 

− 単純さ及び理解容易性 

− 挙動の予測可能性 

− 検証及びテスト可能な設計 

− フォールトトレランス 

− 外部事象による共通原因故障に対する防護 

24 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

7.4.3.1 

ソフトウェア開発の性質に応じて，7.4.4に適合していることの責任は，複数の当事者で負うこと

ができる。責任分担については，安全計画時に文書化しなければならない（JIS C 0508-1の箇条6参照）。 

7.4.3.2 

ソフトウェアアーキテクチャ設計は，ソフトウェア供給者及び／又は開発者が定めて，詳述しな

ければならない。ソフトウェアアーキテクチャ設計は，次による。 

a) 要求安全度水準でソフトウェア安全要求仕様を満たすために，ソフトウェア安全ライフサイクルフェ

ーズ中に必要となる一組の統合した技法及び手段を選択し，その正当な根拠を示さなければならない

（7.1.2.7参照）。これらの技法及び手段には，（適宜）冗長性及び多様性を含めた，フォールトトレラ

ンス（ハードウェアに整合した）及びフォールト回避の両方についてのソフトウェア設計戦略を含め

なければならない。 

b) 要素又はサブシステムへのパーティショニングを基本にして，その一つ一つについて，次の情報を提

示しなければならない。 

1) 要素又はサブシステムは以前に検証したものかどうか。検証済のものであるならば，その適合確認

条件。 

2) 各要素又はサブシステムは，安全関連であるかどうか。 

3) 要素又はサブシステムのソフトウェアの決定論的対応能力。 

c) 全てのソフトウェアとハードウェア相互作用を定め，それらの重要度を評価し，詳述しなければなら

ない。 

注記 ソフトウェアとハードウェアとの相互作用が既にシステムアーキテクチャで決まっている場

合は，システムアーキテクチャを参照するだけで十分である。 

d) アーキテクチャの表現には，明確に定義した表記法又は，明確に定義した機能に限定した表記法を用

いなければならない。 

e) 全てのデータの安全度の維持に使用する設計機能を選択しなければならない。そのようなデータとし

ては，プラント入出力データ，通信データ，オペレータインタフェースデータ，保全データ及び内部

データベースデータがある。 

f) 

要求安全度水準で，ソフトウェアアーキテクチャがソフトウェア安全要求仕様を確実に満たすように，

適切なソフトウェアアーキテクチャ統合テストを規定しなければならない。 

7.4.3.3 

7.4.3.2の適用後，E/E/PE系安全要求仕様（7.2.2参照）に要求した変更があれば，その変更につ

いてE/E/PE開発者と合意し，その変更を文書化しなければならない。 

注記 ハードウェアアーキテクチャとソフトウェアアーキテクチャ（図5を参照）との間に重複があ

るのは避けられず，したがって，プログラマブル電子装置のハードウェアとソフトウェアとの

統合（7.5を参照）のためのテスト仕様などについては，ハードウェア開発者と打ち合わせる必

要がある。 

7.4.4 

プログラミング言語を含む支援ツールの要求事項 

注記 この箇条の要求事項を実現するための適切な技法及び手段を選択する場合（附属書A及び附属

書B参照），支援ツールの次の特性（特性の解釈の手引書についてはIEC 61508-7の附属書C

を，参考となる定義については附属書Fを参照。）を検討することが望ましい。 

− 要求するソフトウェア特性で，ツールがソフトウェアの製作を支援している度合い。 

− ツールの動作及び機能の明確さ。 

− アウトプットの正確さ及び再現性。 

7.4.4.1 

ソフトウェアオンライン支援ツールは，安全関連系のソフトウェア要素とみなさなければならな

25 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

い。 

注記 オンライン及びオフラインツールの例については，JIS C 0508-4の3.2.10及び3.2.11を参照。 

7.4.4.2 

ソフトウェアオフライン支援ツールは，ソフトウェア開発業務の凝集性部分として選択しなけれ

ばならない。 

注記1 ソフトウェア開発ライフサイクル要求事項については，7.1.2を参照。 

注記2 ソフトウェア開発を支援する適切なオフラインツールは，開発中にフォールトの導入又はフ

ォールトを検出できない可能性を低減することによって，ソフトウェアの完全性を高める目

的で使用することが望ましい。ソフトウェア開発ライフサイクルのフェーズに関係するツー

ルの例としては，次のものが挙げられる。 

a) ソフトウェア又は設計表現（文章又は図など）を，ある一つの抽象レベルから別のレベ

ルに変更する変換ツール又は翻訳ツール（トランスレータ）であり，設計精緻化ツール，

コンパイラ，アセンブラ，リンカ，バインダ，ローダ，コード生成ツールなどがある。 

b) 静的コードアナライザ，テストカバレッジモニタ，定理証明アシスタント，シミュレー

タなどの適合確認及び妥当性確認ツール。 

c) 稼働中のソフトウェアの維持及び監視に使用する診断ツール。 

d) 開発支援システムなどのインフラストラクチャツール。 

e) バージョン管理ツールなどの構成管理ツール。 

f) 

パラメータの定義及びシステム機能の例示に必要な，データを生成又は維持するアプリ

ケーションデータツール。このようなデータとしては，機能パラメータ，計器の範囲，

アラーム及びトリップレベル，故障時に適用する出力状態，地理レイアウトなどが挙げ

られる。 

注記3 オフライン支援ツールは，統合できるように選択することが望ましい。あるツールからのア

ウトプットが，次のツールに自動的に渡すインプットに適した内容及び形式を備えていて，

中間結果の手直しによるヒューマンエラーの入り込む可能性が小さくなるように協調して動

作していれば，ツールは統合しているといえる。 

注記4 オフライン支援ツールは，アプリケーション，安全関連系及び統合ツールセットの必要性及

び互換性があるように選択することが望ましい。 

注記5 E/E/PE安全関連系の存続期間全体にわたって必要なサービスを提供する，適切なツール（仕

様，設計，実現，文書化及び部分改修を支援するツール）については，その可用性を考慮す

ることが望ましい。 

注記6 選択したツールの使用者の力量に留意することが望ましい。力量要求事項については，JIS C 

0508-1の箇条6を参照。 

7.4.4.3 

オフライン支援ツールの選択については，その正当な根拠を示さなければならない。 

7.4.4.4 

クラスT2及びT3の全てのオフライン支援ツールは，そのツールの挙動及びそのツールの使い方

又は制約を明確に定義した仕様書又は製品文書を備えていなければならない。ソフトウェア開発ライフサ

イクル要求事項については7.1.2を，ソフトウェアオフライン支援ツールのカテゴリについてはJIS C 

0508-4の3.2.11を参照。 

注記 この“仕様書又は製品文書”は，ツールそのものの適合品目（附属書D及びJIS C 0508-2も参

照）についての安全マニュアルではない。適合品目の安全マニュアルは，履行可能な安全関連

系に組み込む既存の要素に関するものである。既存の要素をT3ツールによって生成してから

26 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

履行可能な安全関連系に組み込む場合，ツールの“仕様書又は添付文書”の関連情報（例えば，

機能パラメータの評価順序を保証していないという情報を，コンパイラの最適化に関する文書

に記載することがある。）は，適合品目安全マニュアルに記載して，組み込んだ要素全体又はそ

の一部に依存する具体的な安全機能の完全性の評価を可能にすることが望ましい。 

7.4.4.5 

クラスT2及びT3のオフライン支援ツールについては，ツールに定められる信頼性水準，及び実

行可能なソフトウェアに影響するツールの潜在的故障メカニズムを決めるための評価を，行わなければな

らない。このような故障メカニズムを発見した場合は，適切な軽減策をとらなければならない。 

注記1 潜在的ソフトウェアツール故障の影響を解析する一つの技法として，HAZOP法がある。 

注記2 軽減策の例としては，既に分っているバグの回避，ツール機能の限定使用，ツール出力のチ

ェック，同じ目的に使用する多様なツールの使用などが挙げられる。 

7.4.4.6 

クラスT3の各ツールについては，ツールがその仕様又は文書に適合しているという証拠を提供

しなければならない。証拠は，類似の環境及び類似のアプリケーション（当該組織又は他の組織）で使用

して成功したことを示す履歴と，7.4.4.7に規定するツールの妥当性確認の組合せでよい。 

注記1 バージョンの履歴は，ツールの成熟度の保証，及びツールを新しい開発環境で使用するとき

考慮しなければならないエラー又は曖昧さの記録となることがある。 

注記2 結果の正確性を判断するとき，T3のために挙げた証拠を，T2ツールにも使用してもよい。 

7.4.4.7 

ツールの妥当性確認の結果は文書化し，次の結果を盛り込まなければならない。 

a) 妥当性確認業務の経時的記録 

b) 使用するツール製品マニュアルのバージョン 

c) 妥当性確認を行うツール機能 

d) 使用するツール及び機器 

e) 妥当性確認業務の結果。文書化する妥当性確認結果には，ソフトウェアが妥当性確認に合格したか，

又は不合格の理由のいずれかを明記しなければならない。 

f) 

テストケース及びその後の解析結果 

g) 予想結果と実際の結果の相違点 

7.4.4.8 

7.4.4.6の適合の証拠がない場合は，ツールに起因するフォールトから生じる履行可能な安全関連

系の故障を制御する有効な措置がなければならない。 

注記 措置の一例としては，トランスレータによって履行可能な安全関連系に発生した故障の結果と

して，履行可能な安全関連系の故障の検出及び管理を可能にする多様な冗長コードの生成が，

ある。 

7.4.4.9 

統合ツールセットのツールの互換性を検証しなければならない。 

注記 あるツールからのアウトプットが，次のツールに自動的に渡すインプットに適した内容及び形

式を備えていて，中間結果の手直しによるヒューマンエラーの入り込む可能性が小さくなるよ

うに協調して動作していれば，ツールは統合しているといえる。IEC 61508-7のB.3.5を参照。 

7.4.4.10 選択したソフトウェア又は設計表現（プログラミング言語を含む）は，安全度水準で要求してい

る範囲で，次による。 

a) 場合によっては，国際又は国家標準を基準とする適合性評価を含めて，目的適合性に関して評価済み

のトランスレータを備えていなければならない。 

b) 定義した言語機能だけを使用しなければならない。 

c) アプリケーションの特徴と一致していなければならない。 

27 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

d) 設計又はプログラミングのミスを検出しやすい機能をもたなければならない。 

e) 設計方法に一致する機能をサポートしていなければならない。 

注記1 プログラミング言語は，ソフトウェア又は設計表現の一つのクラスである。トランスレータ

は，ソフトウェア又は設計表現（文章，図など）を，ある一つの抽象レベルから別のレベル

に変換する。トランスレータの例としては，設計精緻化ツール，コンパイラ，アセンブラ，

リンカ，バインダ，ローダ，コード生成ツールなどがある。 

注記2 トランスレータの評価は，特定のアプリケーションプロジェクトについて実行してもよいし，

アプリケーションのクラスについて実行してもよい。後者の場合，想定するツールの正しい

使い方に関して，ツールについての必要な全てのデータは（“仕様又は製品マニュアル”，

7.4.4.4参照），ツールの使用者が利用できることが望ましい。その場合，特定のプロジェクト

でのツールの評価は，ツールのプロジェクトへの一般的妥当性及び“仕様又は製品マニュア

ル”への適合性（すなわち，ツールの正しい使い方）のチェックに限定してよい。正しい使

い方は，特定のプロジェクト内での追加適合確認業務を含む。 

注記3 定義した基準に従ってトランスレータの目的適合性を評価するためには，一連の妥当性確認

（すなわち，あらかじめ正確な翻訳を行うことが判明しているテストプログラム集）を使用

してよい。これには機能及び非機能に関する要求事項を含むものであることが望ましい。機

能的なトランスレータ要求事項に関しては，動的テストが主要な妥当性確認技法となる。で

きれば，一連の自動テストを使用することが望ましい。 

7.4.4.11 7.4.4.10を完全に満たすことができない場合，言語の目的適合性，及び言語の特定した不備に対

処する追加措置は，正しいという根拠を示さなければならない。 

7.4.4.12 全ての安全関連ソフトウェア開発用のプログラミング言語は，妥当なプログラミング言語コーデ

ィング基準に従って使用しなければならない。 

注記 ソフトウェアの安全に関係するコーディング基準に関する手引書については，IEC 61508-7を

参照。 

7.4.4.13 プログラミング言語コーディング基準は，正しいプログラミングの方法を規定し，安全でない言

語機能（例えば，未定義の言語機能，構造化していない設計など）について記述し，コードの理解のしや

すさを促進し，適合確認及びテストを実施しやすいものにし，ソースコード文書化手順を規定しなければ

ならない。できれば，ソースコードには次の情報を記載する。 

a) 法人名（例えば，会社，作者など） 

b) 説明 

c) インプット及びアウトプット 

d) 構成管理履歴 

7.4.4.14 自動コード生成又は類似の自動翻訳を行う場合，開発支援ツールを選択する開発ライフサイクル

の時点で，安全関連系開発用自動トランスレータの適合性を評価しなければならない。 

7.4.4.15 クラスT2及びT3のオフライン支援ツールが構成ベースラインの項目を生成する場合は，構成

管理で，ツールに関する情報を構成ベースラインに確実に記録しなければならない。これには，特に次の

ものがある。 

a) ツール及びそのバージョンの識別 

b) ツールバージョンを使用している構成基準項目の識別 

c) 各構成ベースラインの項目のためのツールの使用法（選択したツールパラメータ，オプション及びス

28 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

クリプトを含む） 

注記 この箇条の目的は，ベースラインの再構築を可能にすることである。 

7.4.4.16 構成管理は，クラスT2及びT3のツールで，有効なバージョンだけを使用するように確認する

ものでなければならない。 

7.4.4.17 構成管理は，互いに，また安全関連系と互換性のあるツールだけを使用するように確認するもの

でなければならない。 

注記 安全関連系ハードウェアが，ソフトウェアツールに互換性の制約を課すことがある。例えば，

プロセッサエミュレータは，実際のプロセッサ電子装置の正確なモデルである必要がある。 

7.4.4.18 オフライン支援ツールの新バージョンが出るたびに，品質評価をしなければならない。この認定

は，次の事項に関する十分な証拠を提示している場合，以前の版について提示している証拠に基づいてよ

い。 

a) 機能差が（あれば），ツールセットの残りとのツール互換性に影響を及ぼさない。 

b) 新バージョンが，新しい重大で未知のフォールトを含んでいる可能性が薄い。 

注記 新バージョンが，新しい重大で未知のフォールトを含んでいる可能性が薄いことを示す証拠

は，変更点の明確な指摘，新バージョンで行った適合確認及び妥当性確認業務の解析，及び

新バージョンに関して他の使用者による既存の運用経験，に基づいたものでよい。 

7.4.4.19 ソフトウェア開発の性質に応じて，7.4.4に適合する責任は複数の当事者が負うものでよい。責

任分担は，安全計画時に文書化しなければならない（JIS C 0508-1の箇条6参照）。 

7.4.5 

詳細設計及び開発の要求事項−ソフトウェアシステム設計 

注記1 ここでいう詳細設計とは，ソフトウェアシステム設計，すなわち，アーキテクチャ内の主要

要素のソフトウェアモジュールのシステムへの分割，個々のソフトウェアモジュール設計及

びコーディングを意味するものと定義する。小規模なアプリケーションでは，ソフトウェア

システム設計とアーキテクチャ設計とを組み合わせてよい。 

注記2 詳細設計及び開発の性質は，ソフトウェア開発業務及びソフトウェアアーキテクチャ（7.4.3

を参照）の特性によって異なる。ラダーロジック，機能ブロックなど，ある種のプログラミ

ング言語の場合，詳細設計は，プログラミングというより構成作成と考えることができる。

それでもなお，構造化した方法でソフトウェアを設計することは，実践規範である。ここで

いう構造化した方法とは，安全関連部を他から（できる限り）切り離してソフトウェアをモ

ジュール構造に編成することである。これには，範囲チェック，その他のデータ入力ミスを

防止する機能を含み，以前に検証したソフトウェアモジュールの使用，将来のソフトウェア

部分改修を容易にする設計の提供を含む。 

注記3 この箇条の要求事項を実現するための適切な技法及び手段を選択する場合（附属書A及び附

属書B参照），設計及び開発について，次の特性（特性の解釈の手引書についてはIEC 61508-7

の附属書Cを，参考となる定義については附属書Fを参照。）を検討することが望ましい。 

− ソフトウェア安全要求仕様の完全性 

− ソフトウェア安全要求仕様の正確性 

− 固有設計フォールトの回避性 

− 単純さ及び理解容易性 

− 挙動の予測可能性 

− 検証及びテスト可能な設計 

29 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− フォールトトレランス又はフォールト検出 

− 共通原因故障の回避性 

7.4.5.1 

ソフトウェア開発の性質に応じて，7.4.5に適合する責任は，複数の当事者が負うものでよい。責

任分担は，安全計画時に文書化しなければならない（JIS C 0508-1の箇条6参照）。 

7.4.5.2 

次の情報，すなわち，E/E/PE安全関連系の要求仕様，ソフトウェアアーキテクチャ設計，及びシ

ステム安全のソフトウェアの妥当性確認計画は，詳細設計の開始前に利用できなければならない。 

7.4.5.3 

ソフトウェアは，モジュール方式，テスト可能性及び安全な部分改修への対応能力が得られるよ

うに作成しなければならない。 

7.4.5.4 

ソフトウェアアーキテクチャ設計の主要な要素及びサブシステムの一つひとつについて，設計の

精緻化は，ソフトウェアモジュール（すなわちソフトウェアシステム設計仕様）への分割に基づくもので

なければならない。各ソフトウェアモジュールの設計及び各ソフトウェアモジュールに適用する適合確認

を規定しなければならない。 

注記1 既存のソフトウェア要素については，7.4.2を参照。 

注記2 適合確認は，テスト及び解析を含む。 

7.4.5.5 

ソフトウェアシステムが，要求安全度水準でソフトウェア安全要求仕様を確実に満たすように，

適切なソフトウェアシステム統合テストを規定しなければならない。 

7.4.6 

コード実装の要求事項 

注記 安全度水準の要求する範囲で，ソースコードは，コードの次の特性（具体的な技法については

附属書A及び附属書Bを，特性の解釈に関する手引書については附属書Cを参照）をもたな

ければならない。 

− 読みやすく，理解しやすく，テストが可能である。 

− ソフトウェアモジュール設計に関する規定の要求事項を満たす（7.4.5参照）。 

− コーディング基準の規定の要求事項を満たす（7.4.4参照）。 

− 安全計画時に規定する全ての関連要求事項を満たす（箇条6参照）。 

7.4.6.1 

ソフトウェアコードの各モジュールをレビューしなければならない。コードを自動化ツールによ

って生成する場合は，7.4.4の要求事項を満たさなければならない。ソースコードが既存ソフトウェアの再

利用から成る場合は，7.4.2の要求事項を満たさなければならない。 

注記 コードレビューは，適合確認業務である（7.9参照）。コードレビューは，厳密さが強まる順に，

個人による，ソフトウェアウォークスルーによる（IEC 61508-7のC.5.15参照），又は形式検査

による（IEC 61508-7のC.5.14参照）コードの検査手段によって実施することができる。 

7.4.7 

ソフトウェアモジュールテストの要求事項 

注記1 ソフトウェアモジュールがそのテスト仕様を正しく満たすことを確認するテストは，適合確

認業務の一つである（7.9参照）。ここでは，コードレビューとソフトウェアモジュールテス

トとを組み合わせて，ソフトウェアモジュールがその関連仕様を満たすことを保証する。す

なわち，これが検証ということである。 

注記2 この箇条の要求事項を実現するための適切な技法及び手段を選択する場合（附属書A及び附

属書B参照），ソフトウェアモジュールテストについて，次の特性（特性の解釈の手引書は

IEC 61508-7の附属書Cを，参考となる定義は附属書Fを参照）を検討することが望ましい。 

− ソフトウェア設計仕様に関するテストの完全性 

− ソフトウェア設計仕様に関するテストの正確性（正常完了） 

30 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− 再現性 

− 正確に定義したテスト構成 

7.4.7.1 

各ソフトウェアモジュールは，ソフトウェアシステム設計（7.4.5を参照）時に開発したソフトウ

ェアモジュールテスト仕様で要求しているとおりに，検証しなければならない。 

注記 適合確認は，テスト及び解析を含む。 

7.4.7.2 

この適合確認では，各ソフトウェアモジュールがその想定した機能を実行し，想定外の機能を実

行することがないことを示さなければならない。 

注記1 このことは，全てのインプットの組合せのテストを意味するものではなく，また，全てのア

ウトプットの組合せのテストを意味するものでもない。全ての同値クラスのテスト又は構造

ベーステストで十分なこともある。境界値解析又は制御フロー解析で，テストケースの数を

許容できる数に減らすことができることもある。解析可能なプログラムは，要求事項を満た

しやすくする。これらの技法については，IEC 61508-7の附属書Cを参照。 

注記2 開発に形式手法，形式証明又はアサーションを使用する場合，このようなテストの適用範囲

を縮小することがある。これらの技法については，IEC 61508-7の附属書Cを参照。 

注記3 決定論的安全度は，通常，定量化していないが（JIS C 0508-4の3.5.6参照），統計的に妥当

な証拠に関連する全ての条件を満たしている場合，定量化した統計的証拠（例えば，統計的

テスト，信頼度成長）が受け入れられる。例えば，IEC 61508-7の附属書Dを参照。 

注記4 モジュールが十分に単純で，網羅的テストが実施できる場合，これは，適合性を実証する最

も有効な方法となる。 

7.4.7.3 

ソフトウェアモジュールテストの結果は，文書化しなければならない。 

7.4.7.4 

テストに不合格となった場合の是正処置手順を規定しなければならない。 

7.4.8 

ソフトウェア統合テストの要求事項 

注記 ソフトウェアを正しく統合していることを確認するテストは，適合確認業務の一つである（7.9

を参照）。 

7.4.8.1 

ソフトウェア統合テストは，設計及び開発フェーズ時に規定しなければならない（7.4.5参照）。 

7.4.8.2 

ソフトウェアシステム統合テスト仕様には，次の事項を記載しなければならない。 

a) 管理可能な統合セットへのソフトウェアの分割 

b) テストケース及びテストデータ 

c) 実施するテストの形式 

d) テスト環境，ツール，構成及びプログラム 

e) テストの完了を判定するためのテスト基準 

f) 

テストに不合格となった場合の是正処置の手順 

7.4.8.3 

ソフトウェアは，ソフトウェアシステム統合テスト仕様に規定するソフトウェア統合テストに従

って，テストを行わなければならない。これらのテストによって，全てのソフトウェアモジュール並びに

ソフトウェア要素及びサブシステムが正しく相互作用し，想定した機能を実行し，かつ，想定外の機能を

実行することのないことを示さなければならない。 

注記1 このことは，全てのインプットの組合せのテストを意味するものではなく，また，全てのア

ウトプットの組合せのテストを意味するものでもない。全ての同値クラスのテスト又は構造

ベーステストで十分なこともある。境界値解析又は制御フロー解析で，テストケースの数を

許容できる数に減らすことができることもある。解析可能なプログラムは，要求事項を満た

31 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

しやすくする。これらの技法については，IEC 61508-7の附属書Cを参照。 

注記2 開発に形式手法，形式証明又はアサーションを使用する場合，このようなテストの適用範囲

が縮小することがある。これらの技法については，IEC 61508-7の附属書Cを参照。 

注記3 決定論的安全度は，通常，定量化していないが（JIS C 0508-4の3.5.6参照），統計的に妥当

な証拠に関連する全ての条件を満たしている場合，定量化した統計的証拠（例えば，統計的

検定，信頼性成長）が受け入れられる。例えば，IEC 61508-7の附属書Dを参照。 

7.4.8.4 

ソフトウェア統合テストの結果は文書化し，テスト結果を記述し，さらに，目的及びテスト基準

が満たしたかどうかを文書化しなければならない。統合テストに不合格の場合は，不合格の理由を文書化

しなければならない。 

7.4.8.5 

ソフトウェア統合時にソフトウェアに部分改修があれば，その影響解析を行って，影響を受ける

全てのソフトウェアモジュールを判別し，必要な再適合確認及び再設計業務を決定しなければならない。 

7.5 

プログラマブル電子装置統合（ハードウェア及びソフトウェア） 

注記 このフェーズは，図4のボックス10.4である。 

7.5.1 

目的 

7.5.1.1 

この箇条の要求事項の第1の目的は，ソフトウェアを対象とするプログラマブル電子ハードウェ

アに統合することである。 

7.5.1.2 

この箇条の要求事項の第2の目的は，安全関連プログラマブル電子装置のソフトウェア及びハー

ドウェアの両立性を確保し，想定した安全度水準の要求事項を満たすようにそれらを組み合わせることで

ある。 

注記1 ソフトウェアとプログラマブル電子ハードウェアとが正しく統合していることを確認するた

めのテストは，適合確認業務の一つである（7.9を参照）。 

注記2 アプリケーションの性質によっては，これらの業務を7.4.8と組み合わせてもよい。 

7.5.2 

要求事項 

注記 この箇条の要求事項を実現するための適切な技法及び手段を選択する場合（附属書A及び附属

書B参照），統合について，次の特性（特性の解釈の手引書はIEC 61508-7の附属書Cを，参

考となる定義は附属書Fを参照）を検討することが望ましい。 

− 設計仕様に関する統合の完全性 

− 設計仕様に関する統合の正確性（正常完了） 

− 再現性 

− 正確に定義した統合構成 

7.5.2.1 

統合テストは設計及び開発フェーズ時（7.4.3参照）に規定し，安全関連プログラマブル電子装置

のハードウェアとソフトウェアとの両立性が確実に得られるようにしなければならない。 

注記 統合テストを開発するには，E/E/PE系の開発者との密接な協力が必要となることがある。 

7.5.2.2 

プログラマブル電子装置統合テスト仕様（ハードウェア及びソフトウェア）には，次の事項を明

記しなければならない。 

a) システムの統合レベルへの分割 

b) テストケース及びテストデータ 

c) 実施するテストの形式 

d) ツール，支援ソフトウェア及び構成説明を含むテスト環境 

e) テストの完了を判定するためのテスト基準 

32 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

7.5.2.3 

ソフトウェア／PE統合テスト仕様（ハードウェア及びソフトウェア）では，開発者がその構内

で実施できる業務と，使用者の現場に出向く必要のある業務とを区別しなければならない。 

7.5.2.4 

ソフトウェア／PE統合テスト仕様（ハードウェア及びソフトウェア）では，次の業務を区別し

なければならない。 

a) 目標プログラマブル電子ハードウェアへのソフトウェアシステムの組込み 

b) E/E/PE系統合，すなわち，プログラマブル電子ハードウェアに，センサ，アクチュエータのような入

出力機器の追加 

c) E/E/PE安全関連系のEUCへの適用 

注記 b) 及びc) は，JIS C 0508-1及びJIS C 0508-2で取り扱うものであり，ここでは，a) との関

連で，完全を期するために記載した。この二つの事項は，通常，ソフトウェア開発者の担当

するものではない。 

7.5.2.5 

ソフトウェアは，ソフトウェア/PE統合テスト仕様（ハードウェア及びソフトウェア）に従って，

安全関連プログラマブル電子ハードウェアと統合しなければならない。 

7.5.2.6 

安全関連プログラマブル電子装置（ハードウェア及びソフトウェア）の統合テスト時に統合シス

テムの変更があれば，その変更を影響解析しなければならない。影響解析では，影響を受ける全てのソフ

トウェアモジュールを判別し，必要な再適合確認業務を決定しなければならない。 

7.5.2.7 

テストケース及びそれらの予想する結果は，その後の解析のために文書化しなければならない。 

7.5.2.8 

安全関連プログラマブル電子装置（ハードウェア及びソフトウェア）の統合テストは文書化し，

テスト結果，並びに目的及びテスト基準を満たしたかどうかを，明記しなければならない。不合格の場合

は，不合格の理由を文書化しなければならない。その結果，ソフトウェアの部分改修又は変更を行った場

合は，影響解析を行い，影響を受ける全てのソフトウェア要素モジュールを判別し，必要な再適合確認及

び再設計業務を決定しなければならない。 

7.6 

ソフトウェアの運用及び部分改修手順 

注記 このフェーズは，図4のボックス10.5である。 

7.6.1 

目的 

この箇条の要求事項の目的は，E/E/PE安全関連系の運用及び部分改修中にE/E/PE安全関連系の機能安

全を確実に維持するために必要なソフトウェアに関する情報及び手順を，提供することである。 

7.6.2 

要求事項 

要求事項は，JIS C 0508-2の7.6及びこの規格の7.8に規定している。 

注記 この規格では，ソフトウェア（ハードウェアと異なり）は，保全することはできない。ソフト

ウェアは常に部分改修する。 

7.7 

ソフトウェアのシステム安全妥当性確認 

注記1 このフェーズは，図4のボックス10.6である。 

注記2 ソフトウェアは，通常，その基盤となるハードウェア及びシステム環境から引き離した状態

では妥当性確認することはできない。 

7.7.1 

目的 

この箇条の要求事項の目的は，統合したシステムが，要求安全度水準で，ソフトウェア安全要求仕様に

必ず適合するようにすることである。 

7.7.2 

要求事項 

注記 この箇条の要求事項を実現するための適切な技法及び手段を選択する場合（附属書A及び附属

33 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

書B参照），安全妥当性確認について，次の特性（特性の解釈の手引書はIEC 61508-7の附属書

Cを，参考となる定義は附属書Fを参照）を検討することが望ましい。 

− ソフトウェア設計仕様に関する妥当性確認の完全性 

− ソフトウェア設計仕様に関する妥当性確認の正確性（正常完了） 

− 再現性 

− 正確に定義した妥当性確認構成 

7.7.2.1 

安全妥当性確認計画で，安全関連ソフトウェアの要求事項への適合性をE/E/PE安全関連系（JIS C 

0508-2の7.7参照）に関して既に確立している場合は，妥当性確認を繰り返す必要はない。 

7.7.2.2 

妥当性確認業務は，システム安全のソフトウェアに関する妥当性確認計画に規定するとおりに実

施しなければならない。 

7.7.2.3 

ソフトウェア開発の性質に応じて，7.7への適合責任は複数の当事者が負うことがある。責任分

担は，安全計画時に文書化しなければならない（JIS C 0508-1の箇条6参照）。 

7.7.2.4 

システム安全のソフトウェアの妥当性確認結果は，文書化しなければならない。 

7.7.2.5 

ソフトウェア安全妥当性確認では，安全機能別に，次の結果を文書化しなければならない。 

a) 業務のシーケンスを遡及できるようにする，妥当性確認業務の経時的記録 

注記 テスト結果を記録するときは，業務のシーケンスを遡及できることが重要である。この要求

事項は業務のシーケンスが遡及できるものであることを重視するものであって，文書の時間

及び日付入りの記録を作成することを重視するものではない。 

b) 使用するシステム安全のソフトウェアの妥当性確認計画（7.3参照）のバージョン 

c) （テスト又は解析によって）妥当性確認する安全機能と合わせて，システム安全のソフトウェアの妥

当性確認計画の参照 

d) 校正データ，並びに校正に使用するツール及び機器 

e) 妥当性確認業務の結果 

f) 

予想結果と実際の結果との不整合 

7.7.2.6 予想結果と実際の結果との不整合が生じた場合，妥当性確認を続けるか，又は変更要請を出して

開発ライフサイクルの前の段階に戻るかどうかに関して行った解析及び決定事項を，システム安全のソフ

トウェア妥当性確認結果の一部として，文書化しなければならない。 

注記 7.7.2.2〜7.7.2.6の要求事項は，JIS C 0508-1の7.14の一般要求事項に基づいている。 

7.7.2.7 

システム安全の安全関連ソフトウェアの妥当性確認は，次の要求事項を満たさなければならな

い。 

a) テストは，ソフトウェアの主要な妥当性確認法でなければならない。妥当性確認業務を補足するため

に，解析，アニメーション及びモデリングを用いてもよい。 

b) ソフトウェアは，次のシミュレーションによって実行しなければならない。 

1) 通常動作時に出る入力信号 

2) 予想する事象 

3) システム動作を要求する望ましくない状態 

c) サプライヤ及び／又は開発者（若しくは適合性に責任を負う複数の当事者）は，製品がJIS C 0508-1

及びJIS C 0508-2の要求事項を満たすことができるように，システム安全のソフトウェアの妥当性確

認に関する文書化した結果，及び全ての関連文書を，システム開発者に提供しなければならない。 

7.7.2.8 

ソフトウェアツールは，7.4.4の要求事項を満たさなければならない。 

34 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

7.7.2.9 

システム安全の安全関連ソフトウェアの妥当性確認結果は，次の要求事項を満たさなければなら

ない。 

a) テストは，規定した安全関連ソフトウェアの全ての要求事項（7.2参照）を正確に満たし，ソフトウェ

アが想定外の機能を実行することがないことを，示さなければならない。 

b) テストケース及びそれらの結果は，安全度水準が要求する以降の解析及び独立した評価（JIS C 0508-1

の箇条8参照）用に文書化しなければならない。 

c) システム安全のソフトウェアの妥当性確認結果を示す文書には，ソフトウェアが妥当性確認に合格し

たか，又は妥当性確認に不合格となった理由のいずれかを，明記しなければならない。 

7.8 

ソフトウェア部分改修 

注記 このフェーズは，図4のボックス10.5である。 

7.8.1 

目的 

この箇条の要求事項の目的は，要求したソフトウェアの決定論的対応能力を維持することを確認しなが

ら，妥当性確認したソフトウェアに，訂正，改善又は改造を加えることである。 

7.8.2 

要求事項 

注記 この箇条の要求事項を実現するための適切な技法及び手段を選択する場合（附属書A及び附属

書B参照），ソフトウェア部分改修について，次の特性（特性の解釈の手引書はIEC 61508-7

の附属書Cを，参考となる定義は附属書Fを参照）を検討することが望ましい。 

− 要求事項に関する部分改修の完全性 

− 要求事項に関する部分改修の正確性 

− 固有設計フォールトの発生の回避性 

− 好ましくない挙動の回避 

− 検証及びテスト可能な設計 

− リグレッション（回帰）テスト及び適合確認の対象範囲 

7.8.2.1 

ソフトウェア部分改修を実施する前に，ソフトウェア部分改修手順を用意しておかなければなら

ない（JIS C 0508-1の7.16を参照）。 

注記1 7.8.2.1〜7.8.2.9は，主として，ソフトウェアの運用フェーズ中に起こる変更に適用する。こ

れらの箇条を，プログラマブル電子装置統合及び全般的設置及び引渡しフェーズ中に適用す

ることもある（JIS C 0508-1の7.13を参照）。 

注記2 部分改修手順モデルの一例を，JIS C 0508-1の図9に示す。 

7.8.2.2 

部分改修は，安全計画（箇条6参照）時に，規定の手順に従った，正式な部分改修の要請を受け

て初めて開始しなければならない。部分改修の要請の詳細については，次による。 

a) 影響を受ける可能性がある潜在危険 

b) 部分改修案 

c) 部分改修の理由 

注記 部分改修の要請は，例えば，次の理由から生じる。 

− 機能安全が安全要求仕様の求めているものよりも低い。 

− 決定論的原因フォールトが生じている。 

− 新しい又は改正した安全規制。 

− EUC又はその使い方に対する部分改修。 

− 安全要求事項全般に対する部分改修。 

35 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

− 運用及び保全性能の解析により，性能が目標を下回っていることを示す。 

− 定期的機能安全監査。 

7.8.2.3 

ソフトウェア部分改修案がE/E/PE安全関連系の機能安全に及ぼす影響について，次の目的で，

解析を実施しなければならない。 

a) 潜在危険及びリスク解析が必要かどうかを判定する。 

b) どのソフトウェア安全ライフサイクルフェーズを繰り返す必要があるかを決定する。 

7.8.2.4 

7.8.2.3で得た影響解析結果は，文書化しなければならない。 

7.8.2.5 

E/E/PE安全関連系の機能安全に影響を及ぼす全部分改修は，ソフトウェア安全ライフサイクルの

適切なフェーズに戻ることから開始しなければならない。それ以降の全てのフェーズは，この規格の要求

事項に従って，それぞれのフェーズで規定している手順に従って実施しなければならない。安全計画（箇

条6参照）には，それ以降の全ての業務について詳述しなければならない。 

注記 完全な潜在危険及びリスク解析を実行しなければならないことがある。その場合，E/E/PE安全

関連系によって実現している安全機能に現在規定しているものとは異なる安全度水準が必要と

なる可能性がある。 

7.8.2.6 

安全関連ソフトウェアの部分改修に関する安全計画は，JIS C 0508-1の箇条6の要求事項を満た

さなければならない。特に，次による。 

a) スタッフの識別，及びそれらの人員に要求する能力の詳述 

b) 部分改修の詳細仕様 

c) 適合確認計画 

d) 安全度水準の要求する範囲での，部分改修の再妥当性確認及びテストの適用範囲 

注記 アプリケーションの性質に応じて，特定分野の専門家の参加が重要となることがある。 

7.8.2.7 

部分改修は，計画どおりに実施しなければならない。 

7.8.2.8 

全部分改修の詳細は文書化し，次の事項に言及した部分を含んでいなければならない。 

a) 変更又は改造要求 

b) ソフトウェア部分改修案が機能安全に及ぼす影響を評価する影響解析の結果及び決定事項，並びにそ

の決定に関連する理由 

c) ソフトウェア構成管理履歴 

d) 正常な動作及び条件からの逸脱 

e) 部分改修業務によって影響を受ける全ての文書情報 

7.8.2.9 

全部分改修の詳細についての情報は，文書化しなければならない。その文書には，データの再適

合確認及び再妥当性確認，並びに結果を含めなければならない。 

7.8.2.10 要求した部分改修又は改造業務の評価は，影響解析の結果及びソフトウェアの決定論的対応能力

に基づかなければならない。 

7.9 

ソフトウェア適合確認 

7.9.1 

目的 

この箇条の要求事項の目的は，安全度水準の要求している範囲で，所定のソフトウェア安全ライフサイ

クルフェーズの引渡し事項をテストし，評価して，そのフェーズへの引継ぎ事項に関して正確性及び一貫

性を確認することである。 

注記1 この箇条では，複数の安全ライフサイクルフェーズに共通の，適合確認の一般的な側面につ

いて検討する。この箇条は，7.4.7（ソフトウェアモジュールテスト），7.4.8（ソフトウェア統

36 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

合）及び7.5（プログラマブル電子装置統合）にある適合確認のテスト要素について，追加の

要求事項を規定するものではない。これらは，それら自体が適合確認業務だからである。こ

の箇条は，ソフトウェア安全妥当性確認（7.7参照）に加えて，更に別の適合確認を要求する

ものでもない。この規格でいうソフトウェア妥当性確認とは，安全要求仕様への適合の実証

である。安全要求仕様自体が適切なものであるか否かのチェックは，その分野の専門家が行

う。 

注記2 ソフトウェアアーキテクチャに応じて，適合確認業務の責任は，ソフトウェアの開発及び部

分改修に関わる全ての組織間で分担してもよい。 

7.9.2 

要求事項 

注記 この箇条の要求事項を実現するための適切な技法及び手段を選択する場合（附属書A及び附属

書B参照），データ適合確認について，次の特性（特性の解釈の手引書はIEC 61508-7の附属書

Cを，参考となる定義は附属書Fを参照）を検討することが望ましい。 

− 事前のフェーズに関する適合確認の完全性 

− 事前のフェーズに関する適合確認の正確性（正常完了） 

− 再現性 

− 正確に定義した適合確認構成 

7.9.2.1 

ソフトウェア適合確認は，ソフトウェア安全ライフサイクルのフェーズ別に開発と同時に計画し

（7.3参照），文書化しなければならない。 

7.9.2.2 

ソフトウェア適合確認計画では，適合確認業務に用いる判定基準，技法及びツールを記載し，次

の事項を盛り込まなければならない。 

a) 安全度要求事項の評価 

b) 適合確認戦略，業務及び技法の選択及び文書化 

c) 適合確認ツール（テストハーネス，特殊テストソフトウェア，入出力シミュレータなど）の選択及び

利用 

d) 適合確認結果の評価 

e) 取った是正処置 

7.9.2.3 

ソフトウェア適合確認は，計画どおりに実施しなければならない。 

注記 適合確認のための技法及び手段の選択及び適合確認業務の独立性の度合いは多数の要因に依存

しており，（機能安全に関わる）グループ規格及び製品規格に規定していることもある。要因に

は，例えば，次の事項がある。 

− プロジェクトの規模 

− 複雑さの度合い 

− 設計の斬新さの度合い 

− 技術の斬新さの度合い 

7.9.2.4 

証拠は文書化し，適合確認対象のフェーズがあらゆる面で満足できる形で完了したことを示さな

ければならない。 

7.9.2.5 

適合確認が終わるたびに，適合確認文書は，次の事項を含まなければならない。 

a) 適合確認する項目の識別 

b) 適合確認を実施したときの情報の識別 

注記1 適合確認を実施するときに基準とした情報とは，直前のライフサイクルフェーズからのイ

37 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

ンプット，設計規格，コーディング基準，使用ツールなどであるが，これだけに限らない。 

c) 不適合がある場合，その情報 

注記2 不適合の例としては，問題への対応が貧弱な，ソフトウェアモジュール，データ構成，ア

ルゴリズムなどが挙げられる。 

7.9.2.6 

次のフェーズN＋1を正しく実行するために必要なソフトウェア安全ライフサイクルのフェーズ

Nから，全ての必須情報が得られなければならず，またその情報は検証しなければならない。フェーズN

からの引渡し事項は，次のものを含む。 

a) 次の事項に関する，フェーズNの仕様，設計又はコードの妥当性 

1) 機能性 

2) 安全度，性能，安全計画のその他の要求事項（箇条6参照） 

3) 次フェーズの開発者にとっての理解の容易性 

4) さらに実施する適合確認のためのテスト容易性 

5) さらなる進化を可能にする安全な部分改修 

b) フェーズNの設計を規定し，記述するための，フェーズNに規定した妥当性確認計画及び／又はテス

トの妥当性 

c) 次のものの間の不適合のチェック 

1) フェーズNで規定したテスト，及びその前のフェーズN−1で規定したテスト 

2) フェーズN内の引渡し事項 

7.9.2.7 

ソフトウェア開発ライフサイクル（7.1参照）の選択を経て，次の適合確認業務を実施しなけれ

ばならない。 

a) ソフトウェア安全要求事項の適合確認 

b) ソフトウェアアーキテクチャの適合確認 

c) ソフトウェアシステム設計の適合確認 

d) ソフトウェアモジュール設計の適合確認 

e) コードの適合確認 

f) 

データの適合確認 

g) タイミング性能の適合確認 

h) ソフトウェアモジュールテスト（7.4.7参照） 

i) 

ソフトウェア統合テスト（7.4.8参照） 

j) 

プログラマブル電子装置統合テスト（7.5参照） 

k) システム安全のソフトウェアの妥当性確認（7.7参照） 

注記 a)〜g) の要求事項については，7.9.2.8〜7.9.2.14を参照。 

7.9.2.8 

ソフトウェア安全要求事項の適合確認 ソフトウェア安全要求仕様の完成した後，ソフトウェア

設計及び開発の次のフェーズが始まる前に，次の適合確認を行う。 

a) ソフトウェア安全要求仕様が，機能性，安全度，性能，その他の安全計画の要求事項に関して，E/E/PE

系安全要求仕様（JIS C 0508-1の7.10及びJIS C 0508-2の7.2参照）を正しく満たすかどうかを検討

しなければならない。 

b) システムの安全のソフトウェアに関する妥当性確認計画が，ソフトウェア安全要求仕様を正しく満た

すかどうかを検討しなければならない。 

c) 次のものの間に不適合があるかどうかを，チェックしなければならない。 

38 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

1) ソフトウェア安全要求仕様と，E/E/PE系安全要求仕様（JIS C 0508-1の7.10及びJIS C 0508-2の7.2

参照）との間。 

2) ソフトウェア安全要求仕様と，システム安全のソフトウェアに関する妥当性確認計画との間。 

7.9.2.9 

ソフトウェアアーキテクチャの適合確認 ソフトウェアアーキテクチャ設計が完了した後，次の

適合確認を行う。 

a) ソフトウェアアーキテクチャ設計が，ソフトウェア安全要求仕様を正しく満たすかどうかを検討しな

ければならない。 

b) ソフトウェアアーキテクチャ設計で，規定した統合テストが適切であるかどうかを検討しなければな

らない。 

c) 各主要要素及びサブシステムの属性が，次の点に関して適切であるかどうかを検討しなければならな

い。 

1) 要求する安全性能の実現可能性 

2) さらに実施する適合確認のためのテスト容易性 

3) 開発及び適合確認チームによる読みやすさ 

4) さらに進化するための安全な部分改修 

d) 次のものの間に不適合がないことを，チェックしなければならない。 

1) ソフトウェアアーキテクチャ設計と，ソフトウェア安全要求仕様との間。 

2) ソフトウェアアーキテクチャ設計と，その統合テストとの間。 

3) ソフトウェアアーキテクチャ設計統合テストと，システム安全のソフトウェアに関する妥当性確認

計画との間。 

7.9.2.10 ソフトウェアシステム設計の適合確認 ソフトウェアシステム設計が完了した後，次の適合確認

を行う。 

a) ソフトウェアシステム設計（7.4.5参照）が，ソフトウェアアーキテクチャ設計を正しく満たすかどう

かを検討しなければならない。 

b) ソフトウェアシステム統合で規定したテスト（7.4.5参照）が，ソフトウェアシステム設計（7.4.5を参

照）を正しく満たすかどうかを検討しなければならない。 

c) ソフトウェアシステム設計仕様（7.4.5参照）の各主要要素の属性が，次の点に関して適切であるかど

うかを検討しなければならない。 

1) 要求する安全性能の実現可能性 

2) さらに実施する適合確認のためのテスト容易性 

3) 開発及び適合確認チームによる読みやすさ 

4) さらに進化するための安全な部分改修 

注記 ソフトウェアシステム統合テストは，ソフトウェアアーキテクチャ統合テストの一部として

規定してもよい。 

d) 次のものの間に不適合があるかどうかを，チェックしなければならない。 

1) ソフトウェアシステム設計仕様（7.4.5参照）と，ソフトウェアアーキテクチャ設計との間。 

2) ソフトウェアシステム設計仕様（7.4.5参照）と，ソフトウェアシステム統合テスト仕様（7.4.5参照）

との間。 

3) ソフトウェアシステム統合テスト仕様（7.4.5参照）と，ソフトウェアアーキテクチャ統合テスト仕

様（7.4.3参照）との間。 

39 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

7.9.2.11 ソフトウェアモジュール設計の適合確認 各ソフトウェアモジュールの設計が完了した後，次の

適合確認を行う。 

a) ソフトウェアモジュール設計仕様（7.4.5参照）が，ソフトウェアシステム設計仕様（7.4.5参照）を正

しく満たすかどうかを検討しなければならない。 

b) ソフトウェアモジュールテスト仕様（7.4.5参照）が，ソフトウェアモジュール設計仕様（7.4.5を参照）

に適切なものであるかどうかを検討しなければならない。 

c) 各ソフトウェアモジュールの属性が，次の点に関して適切であるかどうかを検討しなければならない。 

1) 要求する安全機能の実現可能性（ソフトウェア安全要求仕様参照） 

2) さらに実施する適合確認のためのテスト容易性 

3) 開発及び適合確認チームによる読みやすさ 

4) さらに進化するための安全な部分改修 

d) 次のものの間に不適合がないことを，チェックしなければならない。 

1) ソフトウェアモジュール設計仕様（7.4.5参照）と，ソフトウェアシステム設計仕様（7.4.5参照）と

の間。 

2) （各ソフトウェアモジュールについて）ソフトウェアモジュール設計仕様（7.4.5参照）と，ソフト

ウェアモジュールテスト仕様（7.4.5参照）との間。 

3) ソフトウェアモジュールテスト仕様（7.4.5参照）と，ソフトウェアシステム統合テスト仕様（7.4.5

参照）との間。 

7.9.2.12 コード適合確認 ソースコードは静的方法で検証し，ソフトウェアモジュール設計仕様（7.4.5

参照），要求するコーディング基準（7.4.4参照）及びシステム安全のソフトウェアに関する妥当性確認計

画への適合を確認しなければならない。 

注記 ソフトウェア安全ライフサイクルの初期のフェーズにおいて，適合確認は静的（例えば，検査，

見直し，形式証明など）である。コード適合確認には，ソフトウェア検査及びウォークスルー

などの技法がある。各ソフトウェアモジュールがその関連仕様を満たすと保証するのは，コー

ド適合確認とソフトウェアモジュールテストの結果との組合せである。それ以降は，テストが

適合確認の主要手段となる。 

7.9.2.13 データの適合確認は，次による。 

a) データ構成は検証しなければならない。 

b) アプリケーションデータは，次の点について検証しなければならない。 

1) データ構成との整合性 

2) アプリケーション要求事項を基準にした完全性 

3) 基礎となるシステムソフトウェアとの両立性（例えば，実行シーケンス，ランタイムなど） 

4) データ値の正確性 

c) 全ての運用パラメータは，アプリケーション要求事項を基準にして検証しなければならない。 

d) 全てのプラントインタフェース及び関連ソフトウェア（すなわち，センサ及びアクチュエータ並びに

オフラインインタフェース，7.2.2.12参照）は，次の点について，検証しなければならない。 

1) 予想するインタフェース故障の検出 

2) 予想するインタフェース故障の許容度 

e) 全ての通信インタフェース及び関連ソフトウェアは，次の事項の適切なレベルについて検証しなけれ

ばならない。 

40 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

1) 故障検出 

2) 破壊に対する防護 

3) データ妥当性確認 

7.9.2.14 タイミング性能の適合確認 時間域の挙動の予測可能性は検証しなければならない。 

注記 タイミング挙動とは，性能，リソース，応答時間，ワーストケース実行時間，スラッシング，

デッドロックフリー，ランタイムシステムなどである。 

8 

機能安全評価 

注記 この箇条の要求事項を実現するための適切な技法及び手段を選択する場合（附属書A及び附属

書B参照），機能安全評価について，次の特性（特性の解釈の手引書はIEC 61508-7の附属書C

を，参考となる定義は附属書Fを参照。）を検討することが望ましい。 

− この規格に関する機能安全評価の完全性 

− 設計仕様に関する機能安全評価の正確性（正常完了） 

− 特定した全ての問題の追跡可能な状態での終結 

− 変更後に評価を広範に手直しする必要なく機能安全評価を修正する能力 

− 再現性 

− 適時性 

− 正確に定義した構成 

8.1 

JIS C 0508-1の箇条8の目的及び要求事項は，安全関連ソフトウェアの評価に適用する。 

8.2 

適用分野の規格に特に規定のない限り，機能安全評価の実施担当者の最低限の独立性レベルは，JIS 

C 0508-1の箇条8に規定しているとおりでなければならない。 

8.3 

機能安全の評価は，表A.10の業務結果を利用してよい。 

注記 附属書A及び附属書Bから技法を選択しても，それだけで，要求する安全度の達成を保証する

わけではない（7.1.2.7参照）。アセッサは，次の事項も検討することが望ましい。 

− 全体の開発サイクル用に選択した方法，言語及びツールの整合性及び相補的性質。 

− 開発者が，完全に理解している方法，言語及びツールを用いているかどうか。 

− 方法，言語及びツールが開発中に遭遇する個々の問題に十分に対応するものであるかどう

か。 

41 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

附属書A 

（規定） 

技法及び手段の選択の手引書 

この附属書の表は，本体の幾つかの箇条に対応している。例えば，7.2（ソフトウェア安全要求仕様）は

表A.1に対応する。詳細を記載した附属書Bの表は，附属書Aの表の記入事項の幾つかを詳述したもので

ある。例えば，表B.2は，表A.5の動的解析及びテストについて詳述したものである。附属書A及び附属

書Bに示す個々の技法及び手段の概要については，IEC 61508-7を参照。表に示す各技法又は手段につい

ては，安全度水準（SIL）1〜4に対する推奨となる。これらの推奨事項は，次とする。 

HR 

この安全度水準には，技法又は手段を使用することを強く推奨する。この技
法又は手段を使用しない場合は，使用しない理論的根拠について，附属書C
を参照して安全計画時に詳述しなければならず，またアセッサと合意しなけ
ればならない。 

R 

この安全度水準には，HR推奨より低い推奨事項としての技法又は手段が望ま
しい。 

--- 

技法又は手段を使用することに関しては，推奨も反対もしない。 

NR 

この安全度水準には，技法又は手段を使用することを積極的には推奨しない。
この技法又は手段を使用する場合は，使用する理論的根拠について，附属書
Cを参照して安全計画時に詳述しなければならず，またアセッサと合意する
ことが望ましい。 

安全度水準に従って，適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は，

数字の後に1文字を付けて示す。代替又は等価の技法及び手段の一つだけを満たさなければならない。 

要求事項及び目的を満たしていれば，これ以外の技法及び手段を採用してもよい。技法の選択の手引書

については，附属書Cを参照。 

技法及び手段のランク付けは，JIS C 0508-2で使用している有効性の概念に関連している。この他の要

因が同等であるならば，HRとしてランク付けする技法は，ソフトウェア開発中に決定論的原因フォール

トの侵入防止の点で，又は（ソフトウェアアーキテクチャの場合に）実行中に明らかになるソフトウェア

の残存フォールトの管理の点で，Rとしてランク付けした技法よりも有効である。 

ソフトウェアの決定論的対応能力に影響する要因が多数ある場合は，全てのアプリケーションに対して

正しい技法と手段とを組み合わせるためのアルゴリズムを導出することは不可能である。ソフトウェアの

決定論的対応能力を達成するための，特定の技法を選択する理由に関する手引書を，附属書Cに示す。 

特定のアプリケーションで，適切な技法又は手段の組合せは，表の注に他の要求事項を記載していない

限り，選択した適切な技法又は手段を安全計画時に決めなければならない。 

表の解釈について，二つの実例の形式をとった最初の手引書をIEC 61508-6に記載している。 

42 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表A.1−ソフトウェア安全要求仕様（7.2参照） 

技法及び手段a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1a 

準形式手法 

表B.7 

R 

R 

HR 

HR 

1b 

形式手法 

IEC 61508-7の 

B.2.2，C.2.4 

--- 

R 

R 

HR 

2 

システム安全要求仕様とソフトウェア安全要
求仕様との間の前方トレーサビリティ 

IEC 61508-7の 

C.2.11 

R 

R 

HR 

HR 

3 

ソフトウェア安全要求仕様と感知した安全ニ
ーズとの間の後方トレーサビリティ 

IEC 61508-7の 

C.2.11 

R 

R 

HR 

HR 

4 

上記の技法及び手段を支援する適切なコンピ
ュータ支援仕様書作成ツール 

IEC 61508-7の 

B.2.4 

R 

R 

HR 

HR 

注記1 ソフトウェア安全要求仕様は，アプリケーションを反映する自然言語，及び任意の必要な数学的

表記法による問題記述を，常に要求する。 

注記2 この表は，ソフトウェア安全要求事項を規定するための追加の要求事項を，明確かつ的確に反映

している。 

注記3 表C.1を参照。 
注記4 3列目の参照先（これは規定ではなく参考）の“B.x.x”及び“C.x.x”は，技法及び手段の詳細

な説明がIEC 61508-7の附属書B及び附属書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手

段は，数字の後に1文字を付けて示す。代替又は等価の技法及び手段は，一つだけを満たすことを
意図している。代替技法を選択するときは，特定のアプリケーションにとって望ましい附属書C
に示す特性に従って，その正当な根拠を示すことが望ましい。 

43 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表A.2−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計（7.4.3参照） 

技法及び手段a) 

参照先 

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.3.7 

R 

R 

--- 

--- 

4b 

グレースフルデグラデーション 

IEC 61508-7の 

C.3.8 

R 

R 

HR 

HR 

5 

人工知能−フォールト修正 

IEC 61508-7の 

C.3.9 

--- 

NR 

NR 

NR 

6 

動的再構成 

IEC 61508-7の 

C.3.10 

--- 

NR 

NR 

NR 

7 

モジュラーアプローチ 

表B.9 

HR 

HR 

HR 

HR 

8 

信頼性確認及び検証済ソフトウェア要素の使用（利用
できる場合） 

IEC 61508-7の 

C.2.10 

R 

HR 

HR 

HR 

9 

ソフトウェア安全要求仕様及びソフトウェアアーキ
テクチャとの間の前方トレーサビリティ 

IEC 61508-7の 

C.2.11 

R 

R 

HR 

HR 

10 

ソフトウェア安全要求仕様及びソフトウェアアーキ
テクチャ間の後方トレーサビリティ 

IEC 61508-7の 

C.2.11 

R 

R 

HR 

HR 

11a 

構造化図表法b) 

IEC 61508-7の 

C.2.1 

HR 

HR 

HR 

HR 

11b 

準形式手法b) 

表B.7 

R 

R 

HR 

HR 

11c 

形式的設計手法及び精緻化手法b) 

IEC 61508-7の 

B.2.2及びC.2.4 

--- 

R 

R 

HR 

11d 

自動ソフトウェア生成 

IEC 61508-7の 

C.4.6 

R 

R 

R 

R 

12 

コンピュータ支援仕様書作成ツール 
コンピュータ支援設計ツール 

IEC 61508-7の 

B.2.4 

R 

R 

HR 

HR 

13a 

最大周期を保証した周期的挙動 

IEC 61508-7の 

C.3.11 

R 

HR 

HR 

HR 

13b 

タイムトリガアーキテクチャ 

IEC 61508-7の 

C.3.11 

R 

HR 

HR 

HR 

44 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表A.2−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計（7.4.3参照）（続き） 

技法及び手段a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

アーキテクチャ及び設計機能 

13c 

最大応答時間を保証したイベント駆動 

IEC 61508-7の 

C.3.11 

R 

HR 

HR 

--- 

14 

静的資源配分 

IEC 61508-7の 

C.2.6.3 

--- 

R 

HR 

HR 

15 

共有資源へのアクセスの静的同期化 

IEC 61508-7の 

C.2.6.3 

--- 

--- 

R 

HR 

注記1 表A.2に示す方法の幾つかは設計概念に関するものであり，それ以外は，どのように設計を表現するかに

関するものである。 

注記2 この表に示すフォールトトレランス（故障の管理）に関する手段は，JIS C 0508-2に示すプログラマブル電

子装置のハードウェアのアーキテクチャ及び故障の管理に関する要求事項と合わせて検討することが望ま
しい。 

注記3 表C.2を参照。 
注記4 グループ13の手段は，安全タイミング要求事項を課すシステム及びソフトウェアだけに適用する。 
注記5 手段14。動的オブジェクト（例えば，実行スタック又はヒープ上の）を使用すると，利用可能なメモリ及

び実行時間の両方に要求事項を課すことがある。a) 全ての動的変数及びオブジェクトに，ランタイム前に
十分なメモリを割り当てるか，又はメモリ割当てエラーのときに，安全状態を達成するようにしてあり，
b) 応答時間が要求事項を満たすようにしてあるコンパイラを使用している場合は，手段14を適用する必
要はない。 

注記6 手段4a。再試行フォールト回復は，どのようなSILにも適用できることが多いが，再試行回数には制限を

設けることが望ましい。 

注記7 3列目の参照先（これは規定ではなく参考）“B.x.x.x”及び“C.x.x.x”は，技法及び手段の詳細な説明がIEC 

61508-7の附属書B及び附属書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は，数

字の後に1文字を付けて示す。代替又は等価の技法及び手段は，一つだけを満たすことを意図している。代
替技法を選択するときは，特定のアプリケーションにとって附属書Cに示す望ましい特性に従って，その正
当な根拠を示すことが望ましい。 

b) グループ11，“構造化手法”。手段11aは，11bがSIL 3及び／又はSIL 4の領域に適していないときだけに使

用する。 

表A.3−ソフトウェア設計及び開発−支援ツール及びプログラミング言語（7.4.4参照） 

技法及び手段a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1 

適切なプログラミング言語 

IEC 61508-7の 

C.4.5 

HR 

HR 

HR 

HR 

2 

厳密に型付けしたプログラミング言語 

IEC 61508-7の 

C.4.1 

HR 

HR 

HR 

HR 

3 

言語サブセット 

IEC 61508-7の 

C.4.2 

--- 

--- 

HR 

HR 

4a 

認定したツール及びトランスレータ 

IEC 61508-7の 

C.4.3 

R 

HR 

HR 

HR 

4b 

ツール及びトランスレータ：使用によって信頼性が増
すもの 

IEC 61508-7の 

C.4.4 

HR 

HR 

HR 

HR 

注記1 表C.3を参照。 
注記2 3列目の参照先（これは規定ではなく参考）“C.x.x”は，技法及び手段の詳細な説明がIEC 61508-7の附属

書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は，数

字の後に1文字を付けて示す。代替又は等価の技法及び手段は，一つだけを満たすことを意図している。代
替技法を選択するときは，特定のアプリケーションにとって附属書Cに示す望ましい特性に従って，その正
当な根拠を示すことが望ましい。 

45 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表A.4−ソフトウェア設計及び開発−詳細設計（7.4.5及び7.4.6参照） 

（ソフトウェアシステム設計，ソフトウェアモジュール設計及びコーディングを含む） 

技法及び手段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 

IEC 61508-7の 

C.2.6 

R 

HR 

HR 

HR 

6 

構造化プログラミング 

IEC 61508-7の 

C.2.7 

HR 

HR 

HR 

HR 

7 

信頼性確認／検証済ソフトウェア要素の使用 

（使用可能な場合） 

IEC 61508-7の 

C.2.10 

R 

HR 

HR 

HR 

8 

ソフトウェア安全要求仕様とソフトウェア設計との
間の前方トレーサビリティ 

IEC 61508-7の 

C.2.11 

R 

R 

HR 

HR 

注記1 表C.4を参照。 
注記2 安全関連系用のオブジェクト指向ソフトウェア開発の妥当性については，依然として論議が重ねられてい

る。オブジェクト指向アーキテクチャ及び設計の手引書については，IEC 61508-7の附属書Gを参照。 

注記3 3列目の参照先（これは規定ではなく参考）“B.x.x”，“C.x.x”は，技法及び手段の詳細な説明がIEC 61508-7

の附属書B及び附属書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は，数

字の後に1文字を付けて示す。代替又は等価の技法及び手段は，一つだけを満たすことを想定している。代
替技法を選択するときは，特定のアプリケーションにとって附属書Cに示す望ましい特性に従って，その正
当な根拠を示すことが望ましい。 

b) グループ1，“構造化手法”。手段1aは，1bがSIL 3及び／又はSIL 4の領域に適していないときだけに使用

する。 

46 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表A.5−ソフトウェア設計及び開発−ソフトウェアモジュールテスト及び統合（7.4.7及び7.4.8参照） 

技法及び手段a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1 

確率的テスト 

IEC 61508-7の 

C.5.1 

--- 

R 

R 

R 

2 

動的解析及びテスト 

表B.3， 

IEC 61508-7の 

B.6.5 

R 

HR 

HR 

HR 

3 

データの記録及び解析 

IEC 61508-7の 

C.5.2 

HR 

HR 

HR 

HR 

4 

機能及びブラックボックステスト 

表B.3， 

IEC 61508-7の 

B.5.1及びB.5.2 

HR 

HR 

HR 

HR 

5 

性能テスト 

表B.6 

R 

R 

HR 

HR 

6 

モデルベーステスト 

IEC 61508-7の 

C.5.27 

R 

R 

HR 

HR 

7 

インタフェーステスト 

IEC 61508-7の 

C.5.3 

R 

R 

HR 

HR 

8 

テスト管理及び自動化ツール 

IEC 61508-7の 

C.4.7 

R 

HR 

HR 

HR 

9 

ソフトウェア安全要求仕様とモジュール統合テスト
仕様との間の前方トレーサビリティテスト 

IEC 61508-7の 

C.2.11 

R 

R 

HR 

HR 

10 

形式的適合確認 

IEC 61508-7の 

C.5.12 

--- 

--- 

R 

R 

注記1 ソフトウェアモジュール統合テストは，適合確認業務である（表B.9参照）。 
注記2 表C.5を参照。 
注記3 技法9。形式適合確認によって，必要なモジュール統合テストの量及び範囲が少なくなることがある。 
注記4 3列目の参照先（これは規定ではなく参考）“B.x.x”，“C.x.x”は，技法及び手段の詳細な説明がIEC 61508-7

の附属書B及び附属書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。 

表A.6−プログラマブル電子装置統合（ハードウェア及びソフトウェア）（7.5参照） 

技法及び手段a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1 

機能及びブラックボックステスト 

表B.3， 

IEC 61508-7の 

B.5.1及びB.5.2 

HR 

HR 

HR 

HR 

2 

性能テスト 

表B.6 

R 

R 

HR 

HR 

3 

ハードウェア／ソフトウェア統合に関するシステム
及びソフトウェア設計要求事項とハードウェア／ソ
フトウェア統合テスト仕様との間の前方トレーサビ
リティテスト 

IEC 61508-7の 

C.2.11 

R 

R 

HR 

HR 

注記1 プログラマブル電子装置統合は，適合確認業務である（表A.9参照）。 
注記2 表C.6を参照。 
注記3 3列目の参照先（これは規定ではなく参考）“B.x.x”，“C.x.x”は，技法及び手段の詳細な説明がIEC 61508-7

の附属書B及び附属書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。 

47 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表A.7−ソフトウェアのシステム安全妥当性確認（7.7参照） 

技法及び手段a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1 

確率的テスト 

IEC 61508-7の 

C.5.1 

--- 

R 

R 

HR 

2 

プロセスシミュレーション 

IEC 61508-7の 

C.5.18 

R 

R 

HR 

HR 

3 

モデリング 

表B.5 

R 

R 

HR 

HR 

4 

機能及びブラックボックステスト 

表B.3 

IEC 61508-7の 

B.5.1及びB.5.2 

HR 

HR 

HR 

HR 

5 

ソフトウェア安全要求仕様とソフトウェア安全妥当
性確認計画との間の前方トレーサビリティ 

IEC 61508-7の 

C.2.11 

R 

R 

HR 

HR 

6 

ソフトウェア安全妥当性計画とソフトウェア安全要
求仕様との間の後方トレーサビリティ 

IEC 61508-7の 

C.2.11 

R 

R 

HR 

HR 

注記1 表C.7を参照。 
注記2 3列目の参照先（これは規定ではなく参考）“B.x.x”，“C.x.x”は，技法及び手段の詳細な説明がIEC 61508-7

の附属書B及び附属書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。 

表A.8−部分改修（7.8を参照） 

技法及び手段a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1 

影響解析 

IEC 61508-7の 

C.5.23 

HR 

HR 

HR 

HR 

2 

変更したソフトウェアモジュールの再適合確認 

IEC 61508-7の 

C.5.23 

HR 

HR 

HR 

HR 

3 

影響を受けるソフトウェアモジュールの再適合確認 

IEC 61508-7の 

C.5.23 

R 

HR 

HR 

HR 

4a 

システム全体の再妥当性確認 

表A.7 

--- 

R 

HR 

HR 

4b 

リグレッション妥当性確認 

IEC 61508-7の 

C.5.25 

R 

HR 

HR 

HR 

5 

ソフトウェア構成管理 

IEC 61508-7の 

C.5.24 

HR 

HR 

HR 

HR 

6 

データ記録及び解析 

IEC 61508-7の 

C.5.2 

HR 

HR 

HR 

HR 

7 

ソフトウェア安全要求仕様とソフトウェア部分改修
計画（再適合確認及び再妥当性確認を含む）との間の
前方トレーサビリティ 

IEC 61508-7の 

C.2.11 

R 

R 

HR 

HR 

8 

ソフトウェア部分改修計画（再適合確認及び再妥当性
確認を含む）とソフトウェア安全要求仕様との後方ト
レーサビリティ 

IEC 61508-7の 

C.2.11 

R 

R 

HR 

HR 

注記1 表C.8を参照。 
注記2 技法グループ4。影響解析は，リグレッション妥当性確認の必要な一部である。IEC 61508-7を参照。 
注記3 3列目の参照先（これは規定ではなく参考）“C.x.x”は，技法及び手段の詳細な説明がIEC 61508-7の附属

書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は，数

字の後に1文字を付けて示す。代替又は等価の技法及び手段は，一つだけを満たすことを意図している。代
替技法を選択するときは，特定のアプリケーションにとって附属書Cに示す望ましい特性に従って，その正
当な根拠を示すことが望ましい。 

48 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表A.9−ソフトウェア適合確認（7.9参照） 

技法及び手段a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1 

形式的証明 

IEC 61508-7の 

C.5.12 

--- 

R 

R 

HR 

2 

仕様及び設計のアニメーション 

IEC 61508-7の 

C.5.26 

R 

R 

R 

R 

3 

静的解析 

IEC 61508-7の 

B.6.4 

表B.8 

R 

HR 

HR 

HR 

4 

動的解析及びテスト 

表B.2， 

IEC 61508-7の 

B.6.5 

R 

HR 

HR 

HR 

5 

ソフトウェア設計仕様とソフトウェア適合確認（デー
タ適合確認を含む）計画との間の前方トレーサビリテ
ィ 

IEC 61508-7の 

C.2.11 

R 

R 

HR 

HR 

6 

ソフトウェア適合確認（データ適合確認を含む）計画
とソフトウェア設計仕様との間の後方トレーサビリ
ティ 

IEC 61508-7の 

C.2.11 

R 

R 

HR 

HR 

7 

オフライン数値解析 

IEC 61508-7の 

C.2.13 

R 

R 

HR 

HR 

ソフトウェアモジュールテスト及び統合 

表A.5を参照 

プログラマブル電子装置統合テスト 

表A.6を参照 

ソフトウェアシステムテスト（妥当性確認） 

表A.7を参照 

注記1 便宜上，この表は，全ての適合確認業務をまとめて示している。ただし，これが，それ自体で適合確認業

務である表A.5及び表A.6の適合確認の動的テスト要素に，追加の要求事項を課すものではない。またこ
の表は，この規格では安全要求仕様への適合の実証（エンド−エンド適合確認）であるソフトウェア妥当
性確認（表B.7参照）に加えて，さらに別の適合確認テストを要求するものでもない。 

注記2 適合確認は，JIS C 0508-1，JIS C 0508-2及びJIS C 0508-3の境界にまたがる。したがって，安全関連系の

最初の適合確認は，それ以前のシステムレベル仕様に対するものである。 

注記3 ソフトウェア安全ライフサイクルの早期のフェーズにおける適合確認，例えば，検査，見直し，形式的証

明は静的である。コードを作成すると，動的テストが可能となる。適合確認に必要となるのは，これら2
種類の情報の組合せである。例えば，静的手段によるソフトウェアモジュールのコード適合確認には，ソ
フトウェア検査，ウォークスルー，静的解析，形式的証明などの技法が含まれる。動的手段によるコード
適合確認には，機能テスト，ホワイトボックステスト，統計的テストなどがある。各ソフトウェアモジュ
ールが関連仕様を満たしていることを保証するのは，これら2種類の証拠の組合せである。 

注記4 表C.9を参照。 
注記5 3列目の参照先（これは規定ではなく参考）“B.x.x”，“C.x.x”は，技法及び手段の詳細な説明がIEC 61508-7

の附属書B及び附属書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。 

49 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表A.10−機能安全評価（箇条8参照） 

評価／技法a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1 

チェックリスト 

IEC 61508-7の 

B.2.5 

R 

R 

R 

R 

2 

決定表又は真値表 

IEC 61508-7の 

C.6.1 

R 

R 

R 

R 

3 

故障分析 

表B.4 

R 

R 

HR 

HR 

4 

ダイバースソフトウェアの共通原因故障分析（ダイバ
ースソフトウェアを実際に用いる場合） 

IEC 61508-7の 

C.6.3 

--- 

R 

HR 

HR 

5 

信頼性ブロック図 

IEC 61508-7の 

C.6.4 

R 

R 

R 

R 

6 

箇条8の要求事項とソフトウェア機能安全評価計画
との間の前方トレーサビリティ 

IEC 61508-7の 

C.2.11 

R 

R 

HR 

HR 

注記1 表C.10を参照。 
注記2 3列目の参照先（これは規定ではなく参考）“B.x.x”，“C.x.x”は，技法及び手段の詳細な説明がIEC 61508-7

の附属書B及び附属書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。 

50 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

附属書B 

（参考） 

詳細表 

附属書Aで用いる関連表を，表B.1〜表B.9に記載する。 

表B.1−設計及びコーディング基準（表A.4の関連表） 

技法及び手段a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1 

エラーの可能性を少なくするためのコーディング基
準の使用 

IEC 61508-7の 

C.2.6.2 

HR 

HR 

HR 

HR 

2 

動的オブジェクトなし 

IEC 61508-7の 

C.2.6.3 

R 

HR 

HR 

HR 

3a 

動的変数なし 

IEC 61508-7の 

C.2.6.3 

--- 

R 

HR 

HR 

3b 

動的変数の追加時のオンラインチェック 

IEC 61508-7の 

C.2.6.4 

--- 

R 

HR 

HR 

4 

割込の制限使用 

IEC 61508-7の 

C.2.6.5 

R 

R 

HR 

HR 

5 

ポインタの制限使用 

IEC 61508-7の 

C.2.6.6 

--- 

R 

HR 

HR 

6 

再帰の制限使用 

IEC 61508-7の 

C.2.6.7 

--- 

R 

HR 

HR 

7 

高級言語のプログラムの中に非構造化制御フローが
ない 

IEC 61508-7の 

C.2.6.2 

R 

HR 

HR 

HR 

8 

自動型変換がない 

IEC 61508-7の 

C.2.6.2 

R 

HR 

HR 

HR 

注記1 手段2，3a及び5。（例えば，実行スタック又はヒープ上の）動的オブジェクトを使用する場合は，利用可

能なメモリ及び実行時間の両方に要求事項を課してもよい。a) 全ての動的変数及びオブジェクトに，ラン
タイム前に十分なメモリを割り当てるか，又はメモリ割当てエラーのときに，安全状態を達成するように
してあり，b) 応答時間が要求事項を満たすようにしてあるコンパイラを使用している場合は，手段2，3a
及び5を適用する必要はない。 

注記2 表C.11を参照。 
注記3 3列目の参照先（これは規定ではなく参考）“C.x.x.x”は，技法及び手段の詳細な説明がIEC 61508-7の附

属書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は，数

字の後に1文字を付けて示す。代替又は等価の技法及び手段は，一つだけを満たすことを意図している。代
替技法を選択するときは，特定のアプリケーションにとって附属書Cに示す望ましい特性に従って，その正
当な根拠を示すことが望ましい。 

51 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表B.2−動的解析及び動的テスト（表A.5及び表A.9の関連表） 

技法及び手段a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1 

境界値解析からのテストケース実行 

IEC 61508-7の 

C.5.4 

R 

HR 

HR 

HR 

2 

エラー推定からのテストケース実行 

IEC 61508-7の 

C.5.5 

R 

R 

R 

R 

3 

エラーシーディングからのテストケース実行 

IEC 61508-7の 

C.5.6 

--- 

R 

R 

R 

4 

モデルベーステストケース生成からのテストケース
実行 

IEC 61508-7の 

C.5.27 

R 

R 

HR 

HR 

5 

性能モデリング 

IEC 61508-7の 

C.5.20 

R 

R 

R 

HR 

6 

同値クラス及び入力分割テスト 

IEC 61508-7の 

C.5.7 

R 

R 

R 

HR 

7a 

構造テストの範囲（エントリ点）100 % b) 

IEC 61508-7の 

C.5.8 

HR 

HR 

HR 

HR 

7b 

構造テストの範囲（ステートメント）100 % b) 

IEC 61508-7の 

C.5.8 

R 

HR 

HR 

HR 

7c 

構造テストの範囲（分岐）100 % b) 

IEC 61508-7の 

C.5.8 

R 

R 

HR 

HR 

7d 

構造テストの範囲（条件，MC/DC）100 % b) 

IEC 61508-7の 

C.5.8 

R 

R 

R 

HR 

注記1 テストケースの解析は，サブシステムレベルにおけるものであり，また，仕様及び／又は仕様とコードに

基づくものである。 

注記2 表C.12を参照。 
注記3 3列目の参照先（これは規定ではなく参考）“C.x.x”は，技法及び手段の詳細な説明がIEC 61508-7の附属

書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。 

b) 100 %の範囲を達成できない場合は（例えば，防御的コードのステートメントの範囲），適切な説明を加える

ことが望ましい。 

表B.3−機能テスト及びブラックボックステスト（表A.5，表A.6及び表A.7の関連表） 

技法及び手段a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1 

原因結果図からのテストケース実行 

IEC 61508-7の 

B.6.6.2 

--- 

--- 

R 

R 

2 

モデルベーステストケース生成からのテストケース
実行 

IEC 61508-7の 

C.5.27 

R 

R 

HR 

HR 

3 

プロトタイピング及びアニメーション 

IEC 61508-7の 

C.5.17 

--- 

--- 

R 

R 

4 

同値クラス及び入力分割テスト。境界値解析を含む。 

IEC 61508-7の 

C.5.7 
C.5.4 

R 

HR 

HR 

HR 

5 

プロセスシミュレーション 

IEC 61508-7の 

C.5.18 

R 

R 

R 

R 

注記1 テストケースの解析は，ソフトウェアシステムレベルにおけるものであり，仕様だけに基づくものである。 
注記2 シミュレーションの完全性は，安全度水準，複雑さ及びアプリケーションに依存する。 
注記3 表C.13を参照。 
注記4 3列目の参照先（これは規定ではなく参考）“B.x.x.x”及び“C.x.x.x”は，技法及び手段の詳細な説明がIEC 

61508-7の附属書B及び附属書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。 

52 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表B.4−故障分析（表A.10の関連表） 

技法及び手段a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1a 

原因結果図 

IEC 61508-7の 

B.6.6.2 

R 

R 

R 

R 

1b 

事象の木解析 

IEC 61508-7の 

B.6.6.3 

R 

R 

R 

R 

2 

フォールトの木解析 

IEC 61508-7の 

B.6.6.5 

R 

R 

R 

R 

3 

ソフトウェア機能失敗解析 

IEC 61508-7の 

B.6.6.4 

R 

R 

R 

R 

注記1 ソフトウェアを最適な安全度水準に分類するためには，予備的な潜在危険解析を終えていることが望まし

い。 

注記2 表C.14を参照。 
注記3 3列目の参照先（これは規定ではなく参考）“B.x.x.x”は，技法及び手段の詳細な説明がIEC 61508-7の附

属書Bに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は，数

字の後に1文字を付けて示す。代替又は等価の技法及び手段は，一つだけを満たすことを意図している。代
替技法を選択するときは，特定のアプリケーションにとって附属書Cに示す望ましい特性に従って，その正
当な根拠を示すことが望ましい。 

表B.5−モデリング（表A.7の関連表） 

技法及び手段a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1 

データフロー図 

IEC 61508-7の 

C.2.2 

R 

R 

R 

R 

2a 

有限状態機械 

IEC 61508-7の 

B.2.3.2 

--- 

R 

HR 

HR 

2b 

形式手法 

IEC 61508-7の 

B.2.2，C.2.4 

--- 

R 

R 

HR 

2c 

タイムペトリネット 

IEC 61508-7の 

B.2.3.3 

--- 

R 

HR 

HR 

3 

性能モデリング 

IEC 61508-7の 

C.5.20 

R 

HR 

HR 

HR 

4 

プロトタイピング及びアニメーション 

IEC 61508-7の 

C.5.17 

R 

R 

R 

R 

5 

構成図 

IEC 61508-7の 

C.2.3 

R 

R 

R 

HR 

注記1 特定の技法がこの表に記載していない場合，それらを検討から除外していると考えないほうがよい。その

技法は，この規格に適合することが望ましい。 

注記2 確率の定量化は要求していない。 
注記3 表C.15を参照。 
注記4 3列目の参照先（これは規定ではなく参考）“B.x.x.x”及び“C.x.x.x”は，技法及び手段の詳細な説明がIEC 

61508-7の附属書B及び附属書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は，数

字の後に1文字を付けて示す。代替又は等価の技法及び手段は，一つだけを満たすことを意図している。代
替技法を選択するときは特定のアプリケーションにとって，附属書Cに示す望ましい特性に従って，その正
当な根拠を示すことが望ましい。 

53 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表B.6−性能テスト（表A.5及び表A.6の関連表） 

技法及び手段a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1 

アバランチ及びストレステスト 

IEC 61508-7の 

C.5.21 

R 

R 

HR 

HR 

2 

応答タイミング及びメモリ制約 

IEC 61508-7の 

C.5.22 

HR 

HR 

HR 

HR 

3 

性能要求事項 

IEC 61508-7の 

C.5.19 

HR 

HR 

HR 

HR 

注記1 表C.16を参照。 
注記2 3列目の参照先（これは規定ではなく参考）“C.x.x”は，技法及び手段の詳細な説明がIEC 61508-7の附属

書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。 

表B.7−準形式手法（表A.1，表A.2及び表A.4の関連表） 

技法及び手段a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1 

論理及び機能ブロック図 

注記1を参照 

R 

R 

HR 

HR 

2 

シーケンス図 

注記1を参照 

R 

R 

HR 

HR 

3 

データフロー図 

IEC 61508-7の 

C.2.2 

R 

R 

R 

R 

4a 

有限状態機械及び状態遷移図 

IEC 61508-7の 

B.2.3.2 

R 

R 

HR 

HR 

4b 

タイムペトリネット 

IEC 61508-7の 

B.2.3.3 

R 

R 

HR 

HR 

5 

エンティティ関連属性データモデル 

IEC 61508-7の 

B.2.4.4 

R 

R 

R 

R 

6 

メッセージシーケンスチャート 

IEC 61508-7の 

C.2.14 

R 

R 

R 

R 

7 

判定表又は真理値表 

IEC 61508-7の 

C.6.1 

R 

R 

HR 

HR 

8 

UML 

IEC 61508-7の 

C.3.12 

R 

R 

R 

R 

注記1 論理及び機能ブロック図，並びにシーケンス図については，JIS B 3503に規定する。 
注記2 表C.17を参照。 
注記3 3列目の参照先（これは規定ではなく参考）“B.x.x.x”及び“C.x.x.x”は，技法及び手段の詳細な説明がIEC 

61508-7の附属書B及び附属書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は，数

字の後に1文字を付けて示す。代替又は等価の技法及び手段は，一つだけを満たすことを意図している。代
替技法を選択するときは，特定のアプリケーションにとって附属書Cに示す望ましい特性に従って，その正
当な根拠を示すことが望ましい。 

54 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表B.8−静的解析（表A.9の関連表） 

技法及び手段a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1 

境界値解析 

IEC 61508-7の 

C.5.4 

R 

R 

HR 

HR 

2 

チェックリスト 

IEC 61508-7の 

B.2.5 

R 

R 

R 

R 

3 

制御フロー解析 

IEC 61508-7の 

C.5.9 

R 

HR 

HR 

HR 

4 

データフロー解析 

IEC 61508-7の 

C.5.10 

R 

HR 

HR 

HR 

5 

エラー推定 

IEC 61508-7の 

C.5.5 

R 

R 

R 

R 

6a 

形式的検査。具体的な基準を含む。 

IEC 61508-7の 

C.5.14 

R 

R 

HR 

HR 

6b 

ウォークスルー（ソフトウェア） 

IEC 61508-7の 

C.5.15 

R 

R 

R 

R 

7 

記号的実行 

IEC 61508-7の 

C.5.11 

--- 

--- 

R 

R 

8 

設計レビュー 

IEC 61508-7の 

C.5.16 

HR 

HR 

HR 

HR 

9 

ランタイムエラー挙動の静的解析 

IEC 61508-7の 

B.2.2，C.2.4 

R 

R 

R 

HR 

10 

ワーストケース実行時間解析 

IEC 61508-7の 

C.5.20 

R 

R 

R 

R 

注記1 表C.18を参照。 
注記2 3列目の参照先（これは規定ではなく参考）“B.x.x”及び“C.x.x”は，技法及び手段の詳細な説明がIEC 61508-7

の附属書B及び附属書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は，数

字の後に1文字を付けて示す。代替又は等価の技法及び手段は，一つだけを満たすことを意図している。代
替技法を選択するときは，特定のアプリケーションにとって附属書Cに示す望ましい特性に従って，その正
当な根拠を示すことが望ましい。 

表B.9−モジュラーアプローチ（表A.4の関連表） 

技法及び手段a) 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1 

ソフトウェアモジュールサイズの制限 

IEC 61508-7の 

C.2.9 

HR 

HR 

HR 

HR 

2 

ソフトウェアの複雑さ制御 

IEC 61508-7の 

C.5.13 

R 

R 

HR 

HR 

3 

情報隠蔽及びカプセル化 

IEC 61508-7の 

C.2.8 

R 

HR 

HR 

HR 

4 

パラメータ数制限及び固定数のサブプログラムパラ
メータ 

IEC 61508-7の 

C.2.9 

R 

R 

R 

R 

5 

サブルーチン及び関数における1入口点又は1出口点 

IEC 61508-7の 

C.2.9 

HR 

HR 

HR 

HR 

6 

完全に定義したインタフェース 

IEC 61508-7の 

C.2.9 

HR 

HR 

HR 

HR 

注記1 表C.19を参照。 
注記2 3列目の参照先（これは規定ではなく参考）“C.x.x”は，技法及び手段の詳細な説明がIEC 61508-7の附属

書Cに記載してあることを示す。 

注a) 安全度水準に従って，適切な技法及び手段を選択しなければならない。一つの技法で十分であることは，ま

ずない。適切な技法全てを検討しなければならない。 

55 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

附属書C 
（参考） 

ソフトウェア決定論的対応能力の特性 

C.1 序文 

ソフトウェア決定論的対応能力に影響する要因は多数あることから，どのようなアプリケーションにと

っても正しくなる技法と手段とを組み合わせたアルゴリズムを示すことは，不可能である。附属書Cの目

的は，次のとおりである。 

− 附属書A及び附属書Bから具体的な技法を選択するための手引書を示して，ソフトウェア決定論的対

応能力を達成する。 

− 附属書A及び附属書Bに明示的に記載していない技法を使用し，正当な論理的根拠を概説する。 

附属書Cは，附属書A及び附属書Bの表を補完する。 

C.1.1 附属書A及び附属書Bに関係する附属書Cの構成 

ソフトウェア安全ライフサイクルの各フェーズの引渡し事項を，次に示す各表の形式で定義する。例え

ば，ソフトウェア安全要求仕様を検討してみる。 

表A.1（ソフトウェア安全要求仕様）は，ソフトウェア安全要求仕様を開発するための具体的な技法を

推奨している。 

技法及び手段 

参照先 

SIL 1 

SIL 2 

SIL 3 

SIL 4 

1a 

準形式手法 

表B.7 

R 

R 

HR 

HR 

1b 

形式手法 

IEC 61508-7の 

B.2.2，C.2.4 

--- 

R 

R 

HR 

2 

システム安全要求事項とソフトウェア安全要求事項
との間の前方トレーサビリティ 

IEC 61508-7の 

C.2.11 

R 

R 

HR 

HR 

3 

安全要求事項と認識した安全ニーズとの間の後方 
トレーサビリティ 

IEC 61508-7の 

C.2.11 

R 

R 

HR 

HR 

4 

上記の適切な技法及び手段を支援するコンピュータ
支援仕様書作成ツール 

IEC 61508-7の 

B.2.4 

R 

R 

HR 

HR 

表C.1（決定論的安全度の特性−ソフトウェア安全要求仕様）は，ソフトウェア安全要求仕様が，次の

望ましい特性（これは正式なものではないがIEC 61508-7の附属書Fに定義している。）によって特徴づけ

られる。 

特性 

ソフトウェアで
対応する安全ニ
ーズの完全性 

ソフトウェアで
対応する安全ニ
ーズの正確性 

曖昧さの回避を
含む，固有仕様フ
ォールトの回避
性 

安全要求事項の
理解容易性 

ソフトウェアの
安全以外の機能
が安全機能へ危
険な干渉を及ぼ
さない性質 

適合確認及び妥
当性確認の基礎
となる対応能力 

表C.1は，これらの望ましい特性を達成する具体的な技法の有効性を，非公式ではあるが次の表の尺度

R1，R2及びR3でランク付けている。 

56 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

技法及び手段 

特性 

ソフトウェア
で対応する安
全ニーズの完
全性 

ソフトウェア
で対応する安
全ニーズの正
確性 

曖昧さの回避
を含む，固有
仕様フォール
トの回避性 

安全要求事項
の理解容易性 

ソフトウェア
の安全以外の
機能が安全機
能へ危険な干
渉を及ぼさな
い性質 

適合確認及び
妥当性確認の
基礎となる対
応能力 

1a 

準形式手法 

R1 

特定分野の専
門家が用いる
アプリケーシ
ョンフレンド
リな，又はそ
の分野固有の
規定方法及び
表記法 

R1 

特定分野の専
門家が用いる
アプリケーシ
ョンフレンド
リな，又はそ
の分野固有の
規定方法及び
表記法 
 

R2 

カバレッジ基
準に準拠した
仕様の適合確
認 

R1 

内部の不整
合，動作の未
記述又は数学
的に不整合な
表現の回避若
しくは検出を
助ける方法及
び表記法 
 

R2 

カバレッジ基
準に準拠した
仕様の適合確
認 
 

R3 

決定論的分析
及び／又は特
定の種類の固
有仕様フォー
ルトの系統的
回避に基づく
仕様の適合確
認 

R1 

誤解する機会
を制限する定
義した表記法 
 

R2 

仕様に複雑さ
の制限を適用 

− 

R2 

仕様の曖昧さ
を少なくする
定義した表記
法 

安全ソフトウェアの基本としてソフトウェア安全要求仕様に盛り込まれる信頼性は，それによってソフ

トウェア安全要求仕様の望ましい特性を達成する技法の厳密さに依存する。技法の厳密さは，正式なもの

ではないが，次の表のR1〜R3の尺度でランクづける。この場合，R1が最も厳密さが低く，R3が最も厳

密なものである。 

ある技法は，その技法が満たしている厳密さのレベルに応じて，特定の特性に関して複数のR1，R2及

びR3のランクの一つを達成すればよい。 

R1 

客観的な合否判定基準がないか，又は客観的な合否判定基準をごく限定している。
例えば，判断に基づくブラックボックステスト，実地テスト。 

R2 

要求する特性を達成しているという高水準の信頼性を与える，客観的な合否判定
基準がある（例外を明示し，その正当な根拠を示している）。例えば，カバレッジ
メトリクスのあるテスト又は解析技法，チェックリストのカバレッジ。 

R3 

要求する特性を達成していることを示す，客観的で系統的な推論がある。例えば，
形式的証明，特性を保証するアーキテクチャ上の制約に準拠しているという実証。 

− 

この技法は，この特性とは無関係である。 

57 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

次表の例では，準形式手法は，正確な表現を改善する制限した表記法を規定することで厳密さR1を達

成し，混乱の原因になるおそれのある仕様の複雑さを，更に制限することでR2を達成する。 

技法及び手段 

特性 

ソフトウェア
で対応する安
全ニーズの完
全性 

ソフトウェア
で対応する安
全ニーズの正
確性 

曖昧さの回避
を含む，固有
仕様フォール
トの回避性 

安全要求事項
の理解容易性 

ソフトウェア
の安全以外の
機能が安全機
能へ危険な干
渉を及ぼさな
い性質 

適合確認及び
妥当性確認の
基礎となる対
応能力 

1a 準形式手法 

− 

− 

− 

R1 

誤解する機会
を制限する定
義した表記法 
 

R2 

仕様に複雑さ
の制限を適用 

− 

− 

C.1.2 使用方法−1 

手引書としては，ソフトウェア安全要求仕様の開発に当たって望ましい特性を達成したと納得できるよ

うに実証することができれば，ソフトウェア安全要求仕様が，十分な決定論的安全度をもつソフトウェア

を開発するための適切な根拠であると裏づけられる。 

表C.1は，表A.1の各技法が，多かれ少なかれ，ソフトウェア安全要求仕様に関係する一つ以上の特性

を達成していることを，一般に示している。 

ただし，表A.1は具体的な技法を推奨しているが，これらの推奨は規定ではなく，附属書Aは，“ソフ

トウェアの決定論的対応能力に影響する要因が多数あることからすれば，任意のアプリケーションで正し

い技法と手段を組み合わせたアルゴリズムを決めることは不可能である”と明言していることに留意する

ことが重要である。 

実際に，ソフトウェア安全要求仕様を開発するときに用いる技法を，その技法固有の能力に加えて，い

つくかの実際的な制約（7.1.2.7参照）を受けながら選択する。そうした制約とは，次のようなものである。 

− 全開発サイクルで選択する方法，言語及びツールの一貫性並びに相補的な性質。 

− 開発者が完全に理解している方法，言語及びツールを使用しているか否か。 

− 方法，言語及びツールが，開発中に遭遇する具体的な問題に十分に適合しているか否か。 

表C.1は，ソフトウェア安全要求仕様ライフサイクルの望ましい特性を，特定の開発プロジェクトの実

際的な制約を同時に考慮しながら達成するときに用いる，表A.1の具体的な技法の相対的有効性の比較に

用いてもよい。 

例えば，形式手法は，適合確認及び妥当性確認に関して準形式手法（R2）よりも，よりよい基礎（R3）

となることができるが，他のプロジェクトの制約（例えば，高度なコンピュータ支援ツールの可用性又は

形式表記法の極めて専門的な表現力）が準形式アプローチのほうを望ましいとすることがある。 

このようにして，表C.1の望ましい特性は，ソフトウェア安全要求仕様開発用として表A.1の推奨する

代替技法の妥当で，実際的な比較の基礎となることができる。より一般的な言い方をすれば，特定のライ

フサイクルフェーズ用に附属書Aの推奨する複数の代替技法の中から理路整然とした選択を行うときは，

58 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

対応する附属書Cの表に記載した望ましい特性を検討すればよいということになる。 

しかし，決定論的な挙動の性質のために，附属書Cの特性は，最も高い厳密さで達成又は実証すること

ができないことがある点に注意しなければならない。その特性は，どちらかといえば，目指さなければな

らない目標である。その達成は，例えば，防御的設計と単純さなど，様々な特性間の二律背反を余儀なく

することもある。 

最後に，手引用として，R1/R2/R3基準の定義に加えて，厳密さの水準がR1からR3に向かって上がる

ことと，ソフトウェアの正確性に関する信頼性の向上との間に，非公式のリンクを設けておくと役立つ。

附属書Aが対応するSIL（安全度水準）を要求しているときは，一般的な，非公式の推奨として，次の最

低限の厳密さの水準を目標とすることが望ましい。 

安全度水準

（SIL） 

厳密さ R 

1及び2 

R1 

3 

R2，使用できる場合 

4 

使用可能な最高の厳密さ 

C.1.3 使用方法−2 

附属書Aは具体的な技法を推奨しているが，ライフサイクルフェーズの要求事項及び目的を満たしてい

れば，別の手段及び技法の適用も許す。 

既に指摘したように，決定論的対応能力に影響する要因は多数あり，どのような所定のアプリケーショ

ンでも望ましい特性を達成するように，技法を選択し，組み合わせるためのアルゴリズムを示すことは不

可能である。 

望ましい特性を達成するための有効な方法は複数ある場合もあるので，システム開発者が代わりとなる

証拠を提示できる可能性があることを認識することが望ましい。附属書Cの表に盛り込んだ情報は，附属

書Aの表に示したもの以外の技法の選択を正当化するための理路整然とした主張の基礎として使用するこ

とができる。 

C.2 決定論的安全度に関する特性 

表C.1〜表C.19，及びIEC 61508-7に示す手引書きは，決定論的安全度特性を達成し，説得力のある証

拠を生成するための具体的な技法を示している。ある方法が特性の達成に寄与しない場合は，次表にダッ

シュを記入して，それを示す。ある方法が，幾つかの特性には悪影響を及ぼし，他の特性には好影響を及

ぼす場合は，以下の関連する表に注記を付けて示す。 

59 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.1−決定論的安全度に関する特性−ソフトウェア安全要求仕様（7.2参照。表A.1の関連表） 

技法及び手段 

特性 

ソフトウェアで対応す
る安全ニーズの完全性 

ソフトウェアで対応す
る安全ニーズの正確性 

曖昧さの回避を含む，
固有仕様フォールトの

回避性 

安全要求事項の理解容

易性 

ソフトウェアの安全以
外の機能が安全機能へ
危険な干渉を及ぼさな

い性質 

適合確認及び妥当性確
認の基礎となる対応能

力 

1a 準形式手法 

R1 

特定分野の専門家が用
いる，アプリケーショ
ンフレンドリ又はその
分野固有の仕様規定手
法及び表記法 

R1 

特定分野の専門家が用
いる，アプリケーショ
ンフレンドリ又はその
分野固有の仕様規定手
法及び表記法 
 

R2 

カバレッジ基準に準拠 
した仕様の適合確認 

R1 

内部の不整合，動作の
未記述又は数学的に不
整合な表現の回避又は
検出を助ける手法及び
表記法 
 

R2 

カバレッジ基準に準拠
した仕様の適合確認 
 

R3 

系統的な分析，及び／
又は，内在するある種
の仕様フォールトの体
系的な回避に基づく仕
様の適合確認 

R1 

誤解を与えにくい表記
法の定義又は誤解しに
くい表記法の定義 
 

R2 

仕様の複雑さに制限を
適用 

− 

R2 

仕様の曖昧さを少なく
する表記法の定義 

5

9

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

60 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.1−決定論的安全度に関する特性−ソフトウェア安全要求仕様（7.2参照。表A.1の関連表）（続き） 

技法及び手段 

特性 

ソフトウェアで対応す
る安全ニーズの完全性 

ソフトウェアで対応す
る安全ニーズの正確性 

曖昧さの回避を含む，
固有仕様フォールトの

回避性 

安全要求事項の理解容

易性 

ソフトウェアの安全以
外の機能が安全機能へ
危険な干渉を及ぼさな

い性質 

適合確認及び妥当性確
認の基礎となる対応能

力 

1b 形式手法 

R1 

特定分野の専門家が用
いる，アプリケーショ
ンフレンドリ又はその
分野固有の仕様規定手
法及び表記法 

R1 

特定分野の専門家が用
いる，アプリケーショ
ンフレンドリ又はその
分野固有の仕様規定手
法及び表記法 
 

R2 

カバレッジ基準に準拠
した仕様の適合確認 
 

R3 

挙動の限定的側面での
正確性の保証 

R1 

内部の不整合，動作の
未記述又は数学的に不
整合な表現の回避又は
検出を助ける手法及び
表記法 
 

R2 

カバレッジ基準に準拠
した 
仕様の適合確認 
 

R3 

決定論的分析及び／又
は本質的な仕様フォー
ルトの特定種類の決定
論的アボイダンスに基
づく仕様の適合確認 

− 

注記：手法がアプリケ
ーションフレンドリで
もなく，特定分野専用
のものでもない場合
は，この特性の達成が
困難となってもよい。 

− 

R3 

仕様の曖昧さを少なく
する 

2 

システム安全要
求仕様とソフト
ウェア安全要求
仕様との前方ト
レーサビリティ 

R1 

ソフトウェア安全要求
仕様がシステム安全要
求仕様に対応するとい
う確信性 

− 

− 

− 

− 

− 

3 

ソフトウェア安
全要求仕様と感
知した安全ニー
ズ間との後方ト
レーサビリティ 

− 

R1 

ソフトウェア安全要求
仕様に不要な複雑さが
含まれていないという
確信性 

− 

R1 

被制御機器の安全要求
へのトレーサビリティ
は分かりやすさを高め
る 

R1 

R1 

6

0

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

61 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.1−決定論的安全度に関する特性−ソフトウェア安全要求仕様（7.2参照。表A.1の関連表）（続き） 

技法及び手段 

特性 

ソフトウェアで対応す
る安全ニーズの完全性 

ソフトウェアで対応す
る安全ニーズの正確性 

曖昧さの回避を含む，
固有仕様フォールトの

回避性 

安全要求事項の理解容

易性 

ソフトウェアの安全以
外の機能が安全機能へ
危険な干渉を及ぼさな

い性質 

適合確認及び妥当性確
認の基礎となる対応能

力 

4 

上記の技法及び
手段を支援する
適切なコンピュ
ータ支援仕様書
作成ツール 

R1 

被制御機器及びソフト
ウェア環境に関する特
定分野の知識のカプセ
ル化 
 

R2 

考慮しなければならな
い問題点のチェックリ
ストを定義し，その正
当な根拠を示し，かつ，
それを確認している場
合 

R1 

機能シミュレーション
技法 
 

R2 

定義し，正当な根拠を
示しているカバレッジ
基準に準拠した機能シ
ミュレーション 

R2 

関連する規則が守られ
ていることを確認する
ための意味及び構文の
チェック 

R1 

仕様のアニメーション
又はブラウジング 

R1 

安全機能及び安全以外
の機能の特定 

R1 

トレーサビリティ及び
カバレッジの支援 
 

R2 

トレーサビリティ及び
カバレッジの測定 

6

1

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

62 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.2−決定論的安全度に関する特性−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計（7.4.3参照。表A.2の関連表） 

技法及び手段 

特性 

ソフトウェア安
全要求仕様の完

全性 

ソフトウェア安
全要求仕様の正

確性 

固有設計フォー

ルトの回避性 

単純さ及び理解

容易性 

挙動の予測可能

性 

検証及びテスト

可能な設計 

フォールトトレ

ランス 

外部事象による
共通原因故障に

対する防護 

1 

フォールト検出 

− 

− 

− 

− 

この特性の達成
が困難になって
もよい 

R1 

論理的プログラ
ムフロー監視で
予測可能性に備
える 

− 

R1 

（カバレッジ目

標を定義し，そ
の正当な根拠を
示し，その目標
を満たしている
場合はR2） 

R1又は− 

2 

エラー検出コー
ド 

− 

− 

− 

− 

この特性の達成
が困難になって
もよい 

− 

この特性の達成
が困難になって
もよい 

− 

R1 

（カバレッジ目

標を定義し，そ
の正当な根拠を
示し，その目標
を満たしている
場合はR2） 
 
データ通信な
ど，具体的なア
プリケーション
領域に有効 

R1 

データ通信な
ど，具体的なア
プリケーション
領域に有効 

3a 故障アサーショ

ンプログラミン
グ 

− 

R2 

ポストアサーシ
ョンが詳細要求
仕様への適合性
をチェックして
もよい 

− 

R2 

プリアサーショ
ンがインプット
範囲を制限する 

R2 

ポストアサーシ
ョンによる期待
及び受容アウト
プットのチェッ
ク 

R2 

プリアサーショ
ンがインプット
範囲を制限し，
したがって要求
するテスト範囲
を制限する 

R3 

目標とする故障
に有効 

R3 

目標とする故障
に有効 

6

2

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

63 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.2−決定論的安全度に関する特性−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計（7.4.3参照。表A.2の関連表）（続き） 

技法及び手段 

特性 

ソフトウェア安
全要求仕様の完

全性 

ソフトウェア安
全要求仕様の正

確性 

固有設計フォー

ルトの回避性 

単純さ及び理解

容易性 

挙動の予測可能

性 

検証及びテスト

可能な設計 

フォールトトレラ

ンス 

外部事象による共
通原因故障に対す

る防護 

3b ダイバースモニ

タ法（同一コンピ
ュータ内で，監視
する機能と監視
される機能とが
独立） 

− 

− 

R2 

ダイバースモニ
タ法で最低限の
安全要求事項だ
けを実装する 

R2 

ダイバースモニ
タ法で暗示的ダ
イバシティを規
定する 

R2 

ダイバースモニ
タ法で，ごく簡
単に最低限の安
全要求事項だけ
を実現する 

R2 

ダイバースモニ
タ法で，最低限
の安全要求事項
だけを実現する 

R1 

（カバレッジ目標

を定義し，その正
当な根拠を示し，
その目標を満たし
ている場合はR2） 

R1 

（カバレッジ目標

を定義し，その正
当な根拠を示し，
その目標を満たし
ている場合はR2） 

3c ダイバースモニ

タ法（監視するコ
ンピュータと監
視されるコンピ
ュータ間を切り
離している） 

− 

− 

R2 

ダイバースモニ
タ法で最低限の
安全要求事項だ
けを実現する 

R2 

ダイバースモニ
タ法で暗示的ダ
イバシティを 
規定する 

R2 

ダイバースモニ
タ法で，ごく簡
単に最低限の安
全要求事項だけ
を実現する 

R2 

ダイバースモニ
タ法で最低限の
安全要求事項だ
けを実現する 

R1 

（カバレッジ目標

を定義し，その正
当な根拠を示し，
その目標を満たし
ている場合はR2） 

R1 

（カバレッジ目標

を定義し，その正
当な根拠を示し，
その目標を満たし
ている場合はR2） 

3d 同一のソフトウ

ェア安全要求仕
様を実装する多
様冗長性 

− 

− 

− 

− 

注記：同一の実
行可能ソフトウ
ェア内で行うな
らば，この特性
の達成が困難に
なってもよい 

− 

− 

R1 

一つのプログラム
の故障がそれ以外
のプログラムに悪
影響を及ぼさない
場合 
 

R2 

カバレッジ目標を
定義し，その正当
な根拠を示し，そ
の目標を満たして
いる場合 
 
要求仕様のフォー
ルトに対して防護
しない 

R1 

一つのプログラム
の故障がそれ以外
のプログラムに悪
影響を及ぼさない
場合 
 

R2 

カバレッジ目標を
定義し，その正当
な根拠を示し，そ
の目標を満たして
いる場合 
 
要求仕様のフォー
ルトに対して防護
しない 

6

3

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

64 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.2−決定論的安全度に関する特性−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計（7.4.3参照。表A.2の関連表）（続き） 

技法及び手段 

特性 

ソフトウェア安
全要求仕様の完

全性 

ソフトウェア安
全要求仕様の正

確性 

固有設計フォー

ルトの回避性 

単純さ及び理解

容易性 

挙動の予測可能

性 

検証及びテスト

可能な設計 

フォールトトレ

ランス 

外部事象による
共通原因故障に

対する防護 

3e 機能的多様冗長

性，それぞれ異な
るソフトウェア
安全要求仕様を
実現。このために
は一般に，それぞ
れ異なる物理的
原則でセンサが
稼働する必要が
ある 

− 

− 

R1 

− 

注記：同一の実
行可能ソフトウ
ェア内で行うな
らば，この特性
の達成が困難に
なってもよい 

− 

− 

R1 

一つのプログラ
ムの故障がそれ
以外のプログラ
ムに悪影響を及
ぼさない場合 

R1 

一つのプログラ
ムの故障がそれ
以外のプログラ
ムに悪影響を及
ぼさない場合仕
様フォールトに
対して防護する 

3f 

バックワードリ
カバリ 

− 

− 

− 

注記：この特性
の達成が困難に
なってもよい 

− 

− 

注記：この特性
の達成が困難に
なってもよい 

− 

R2 

R1 

（カバレッジ目

標を定義し，そ
の正当な根拠を
示し，その目標
を満たしている
場合はR2） 

3g ステートレス設

計（又は限定ステ
ート設計） 

R2 

安全要求事項も
状態がない又は
状態を制限して
いる 

R2 

安全要求事項も
状態がない又は
状態を制限して
いる 

R2 

安全要求事項も
状態がない又は
状態を制限して
いる 

R1 

R2 

考えられる状態
数について，制
限を定義し，そ
の正当な根拠を
示し，その制限
を満たしている
場合 

R1 

R2 

考えられる状態
数について，制
限を定義し，そ
の正当な根拠を
示し，その制限
を満たしている
場合 

R1 

R2 

考えられる状態
の適合確認及び
テストカバー率
を定義し，その
正当な根拠を示
し，その目標を
満たしている場
合 

R1 

これが自己回復
設計に至る場合 
 

R2 

自己回復のため
の目標を定義
し，その正当な
根拠を示し，そ
の目標を満たし
ている場合 

R1 

これが自己回復
設計に至る場合 
 

R2 

自己回復のため
の目標を定義
し，その正当な
根拠を示し，そ
の目標を満たし
ている場合 

6

4

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

65 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.2−決定論的安全度に関する特性−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計（7.4.3参照。表A.2の関連表）（続き） 

技法及び手段 

特性 

ソフトウェア安
全要求仕様の完

全性 

ソフトウェア安
全要求仕様の正

確性 

固有設計フォー

ルトの回避性 

単純さ及び理解

容易性 

挙動の予測可能

性 

検証及びテスト

可能な設計 

フォールトトレ

ランス 

外部事象による
共通原因故障に

対する防護 

4a 再試行フォール

ト回復メカニズ
ム 

− 

− 

− 

− 

この特性の達成
が困難になって
もよい 

− 

R1 

（カバレッジ目

標を定義し，そ
の正当な根拠を
示し，その目標
を満たしている
場合はR2） 

R1 

（カバレッジ目

標を定義し，そ
の正当な根拠を
示し，その目標
を満たしている
場合はR2） 

4b グレースフルデ

グラデーション 

− 

− 

− 

注記：この特性
の達成が困難に
なってもよい 

− 

− 

− 

R1 

カバレッジ目標
を定義し，その
正当な根拠を示
し，その目標を
満たしている場
合はR2 

R1 

カバレッジ目標
を定義し，その
正当な根拠を示
し，その目標を
満たしている場
合はR2 

5 

人工知能−フォ
ールト修正 

− 

− 

注記：この特性
の達成が困難に
なってもよい 

− 

注記：この特性
の達成が困難に
なってもよい 

− 

注記：この特性
の達成が困難に
なってもよい 

− 

注記：この特性
の達成が困難に
なってもよい 

− 

注記：この特性
の達成が困難に
なってもよい 

− 

− 

6 

動的再構成 

− 

− 

注記：この特性
の達成が困難に
なってもよい 

− 

注記：この特性
の達成が困難に
なってもよい 

− 

注記：この特性
の達成が困難に
なってもよい 

− 

注記：この特性
の達成が困難に
なってもよい 

− 

注記：この特性
の達成が困難に
なってもよい 

− 

− 

6

5

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

66 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.2−決定論的安全度に関する特性−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計（7.4.3参照。表A.2の関連表）（続き） 

技法及び手段 

特性 

ソフトウェア安
全要求仕様の完

全性 

ソフトウェア安
全要求仕様の正

確性 

固有設計フォー

ルトの回避性 

単純さ及び理解

容易性 

挙動の予測可能

性 

検証及びテスト

可能な設計 

フォールトトレ

ランス 

外部事象による
共通原因故障に

対する防護 

7 

モジュラー・アプ
ローチ 

− 

R1 

R2 

モジュール化の
目標を定義し，
その正当な根拠
を示し，その目
標を満たしてい
れば，R2を達成
する。それ以外
は，R1だけ達成
する 

R1 

特定の種類の本
質的設計フォー
ルトの回避が，
モジュール毎に
独立に検証でき
る場合 
 

R3 

特定の種類の本
質的設計フォー
ルトの回避が，
モジュール設計
に基づく厳密な
論拠によって裏
づけることがで
きる場合 

R1 

R2 

モジュール化目
標を定義し，そ
の正当な根拠を
示し，その目標
を満たしている
場合 

R1 

R2 

モジュール化目
標を定義し，そ
の正当な根拠を
示し，その目標
を満たしている
場合 

R1 

R2 

モジュール化目
標を定義し，そ
の正当な根拠を
示し，その目標
を満たしている
場合 

R1 

一つのモジュー
ルの故障に影響
を受けないモジ
ュールが，低減
／回復に貢献し
ている場合 
 

R3 

特定の故障に対
するトレランス
が厳密な推論に
よって裏づける
ことができる場
合 

R1 

複数のチャネル
に同時に影響を
及ぼす可能性の
ある外部事象に
影響を受けるお
それのあるモジ
ュールを特定
し，徹底的な適
合確認を受ける
場合 
 

R3 

特定の外部事象
に対する許容性
を，厳密な推論
によって裏づけ
ることができる
場合 

6

6

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

67 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.2−決定論的安全度に関する特性−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計（7.4.3参照。表A.2の関連表）（続き） 

技法及び手段 

特性 

ソフトウェア安
全要求仕様の完

全性 

ソフトウェア安
全要求仕様の正

確性 

固有設計フォー

ルトの回避性 

単純さ及び理解

容易性 

挙動の予測可能

性 

検証及びテスト

可能な設計 

フォールトトレ

ランス 

外部事象による
共通原因故障に

対する防護 

8 

信頼確認/検証
済ソフトウェア
モジュール及び
要素の使用（使
用できる場合） 

− 

R1 R2 R3 

要素の特定の安
全要求事項に対
する貢献が著し
く大きく，その
要素を正しく使
用している場合 

R1 R2 R3 

実績のある要素
を再利用する。
このような能力
は，その要素に
関して正当な根
拠を示さなけれ
ばならない 

R1 

モジュラー・ア
プローチは，複
雑さ全体を理解
しやすいユニッ
トに分解する 

R1 R2 R3 

実績のある要素
を再利用する 

− 

R1 R2 

フォールトトレ
ランス能力を，
その要素がすぐ
にもたらし，正
しく使用する場
合，又はフォー
ルトトレランス
層がその要素の
周囲に組み込ま
れる場合はR2 

R1 R2 

同時に複数のチ
ャネルに影響す
る可能性のある
外部事象に対す
る防護を，その
要素がすぐにも
たらし，正しく
使用する場合，
又は防御層がそ
の要素の周囲に
組み込まれる 
場合はR2 

9 

ソフトウェア安
全要求仕様とソ
フトウェアアー
キテクチャ間の
前方トレーサビ
リティ 

R1 
アーキテクチャ
がソフトウェア
安全要求事項に
対応していると
いう確信性 

− 

− 

− 

− 

− 

− 

− 

10 

ソフトウェアア
ーキテクチャと
ソフトウェア安
全要求仕様との
間の後方トレー
サビリティ 

− 

R1 

アーキテクチャ
が不要な複雑さ
を含んでいない
という確信性 

− 

− 

− 

− 

− 

− 

11a 構造化図表法 

− 

R1 

− 

R1 

（図表示のほう

が理解しやす
い） 

− 

R1 

（構造化設計は，

適合確認及びテ
ストがしやす
い） 

− 

− 

6

7

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

68 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.2−決定論的安全度に関する特性−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計（7.4.3参照。表A.2の関連表）（続き） 

技法及び手段 

特性 

ソフトウェア安
全要求仕様の完

全性 

ソフトウェア安
全要求仕様の正

確性 

固有設計フォー

ルトの回避性 

単純さ及び理解

容易性 

挙動の予測可能

性 

検証及びテスト

可能な設計 

フォールトトレ

ランス 

外部事象による
共通原因故障に

対する防護 

11b 準形式手法 

R1 

アプリケーショ
ンフレンドリ又
はその分野固有
の仕様規定手法
及び表記法 

R1 

アプリケーショ
ンフレンドリ又
はその分野固有
の仕様規定手法
及び表記法 

R2 

内部の不整合，
動作の未記述又
は数学的に不整
合な表現を検出
可能 

− 

R2 

（予測可能性の

証拠を提示す
る） 

R2 

（設計モデルの

内部不整合の証
拠を提示する） 

− 

− 

11c 形式的設計手法

及び精緻化手法 

R1 

アプリケーショ
ンフレンドリ又
はその分野固有
の仕様規定手法
及び表記法 

R1 

その特定分野に
適切な動作の正
確な制限事項を
規定する 

R3 

内部の不整合，
動作の未記述又
は数学的に不整
合な表現を検出
可能 

− 

注記：この特性
の達成が困難に
なってもよい 

R2 

予測可能性の証
拠を提示する 

R2 

− 

− 

11d 自動ソフトウェ

ア生成 

R1 

実行可能ソフト
ウェアを要求仕
様から，又は完
全であると判明
している設計か
ら自動的に生成
する場合 
 

R2 

生成ツールが適
切な開発経緯を
もつと判明して
いる場合 

R1 

実行可能ソフト
ウェアを要求仕
様から，又は正
しいと判明して
いる設計から自
動的に生成する
場合 
 

R2 

生成ツールが適
切な開発経緯を
もつと判明して
いる場合 

R1 

生成ツールが，
特定の固有設計
フォールトの回
避を保証してい
る場合 
 

R2 

生成ツールが適
切な開発経をも
つと判明してい
る場合 

− 

− 

− 

R1 R2 R3 

フォールトトレ
ランス能力を自
動的に生成する
場合 

− 

6

8

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

69 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.2−決定論的安全度に関する特性−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計（7.4.3参照。表A.2の関連表）（続き） 

技法及び手段 

特性 

ソフトウェア安
全要求仕様の完

全性 

ソフトウェア安
全要求仕様の正

確性 

固有設計フォー

ルトの回避性 

単純さ及び理解

容易性 

挙動の予測可能

性 

検証及びテスト

可能な設計 

フォールトトレ

ランス 

外部事象による
共通原因故障に

対する防護 

12 

コンピュータ支
援設計ツール，
及びコンピュー
タ支援仕様書作
成ツール 

R1 

被制御機器及び
ソフトウェア環
境に関する特定
分野の知識のカ
プセル化 
 

R2 

考慮すべき問題
点のチェックリ
ストを定義し，
その正当な根拠
を示し，それが
取り上げられて
いる場合 

R1 

後方要求仕様ト
レーサビリティ
の強制 
 
機能シミュレー
ション技法 
 

R2 

定義し，正当な
根拠を示してい
るカバレッジ基
準に準拠した機
能シミュレーシ
ョン 

R2 

関連する規則を
守っていること
を確認するため
の意味及び構文
のチェック 

R1 

アニメーション
及びブラウジン
グ 

− 

R2 

関連する規則を
が守っているこ
とを確認するた
めの意味及び構
文のチェック 

− 

− 

13a 最大周期を保証

した周期的挙動 

− 

仕様のタイミン
グ面に関しては
R1 
 

R3 

厳密な推論が最
大サイクル時間
を定めている場
合 

仕様のタイミン
グ面に関しては
R1 
 

R3 

厳密な推論が最
大サイクル時間
を定めている場
合 

− 

仕様のタイミン
グ面に関しては
R1 
 

R3 

厳密な推論が最
大サイクル時間
を定めている場
合 

仕様のタイミン
グ面に関しては
R1 
 

R3 

厳密な推論が最
大サイクル時間
を定めている場
合 

− 

− 

6

9

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

70 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.2−決定論的安全度に関する特性−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計（7.4.3参照。表A.2の関連表）（続き） 

技法及び手段 

特性 

ソフトウェア安
全要求仕様の完

全性 

ソフトウェア安
全要求仕様の正

確性 

固有設計フォー

ルトの回避性 

単純さ及び理解

容易性 

挙動の予測可能

性 

検証及びテスト

可能な設計 

フォールトトレ

ランス 

外部事象による
共通原因故障に

対する防護 

13b タイムトリガア

ーキテクチャ 

R3 

完全性は割り当
てによって保証
する（タイミン
グ特性に関して
だけ） 

R3 

正確性は割り当
てによって保証
する（タイミン
グ特性に関して
だけ） 

R3 

本質的タイミン
グフォールトを
基準とする厳密
な保証 

R1 

定義した表記法
で，誤解，アプ
ローチとしての
予測可能性が大
幅に減る 

R3 

悪い干渉：時間
域の完全分離，
干渉なし 

R3 

テスト及びシス
テムの確認に要
する労力が大幅
に減る 

R2 

フォールトトレ
ランスの透明な
実現 

R3 

外部割り込み
が，安全にとっ
て重大なタスク
の優先順位を定
めるタイムトリ
ガスケジュール
を妨害すること
ができない 

13c 最大応答時間を

保証したイベン
ト駆動 

− 

− 

− 

R1 

イベント駆動ア
ーキテクチャは
分かりやすさを
妨げてもよい 

R2 

イベント駆動ア
ーキテクチャは
分かりやすさを
妨げてもよい 

R1 

テストの予測可
能性が高まる 

− 

− 

14 

静的資源配分 

R1 

R1 

R1 

R1 

設計をより分か
りやすいものに
する 

R2 

資源の利用をア
ーキテクチャで
定義する 

R1 

テストの予測可
能性が高まる 

− 

− 

15 

共有資源へのア
クセスの静的同
期化 

− 

R1 

資源アクセスの
予測可能性が得
られる 

R1 

同期化の正確性
に関して，厳格
な推論で裏づけ
られている場合
はR3 

R1 

設計をより分か
りやすいものに
する 

R1 

同期化の正確性
に関して，厳密
な推論で裏づけ
られている場合
はR3 

− 

− 

− 

7

0

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

71 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.3−決定論的安全度に関する特性−ソフトウェア設計及び開発−支援ツール及びプログラミング言語（7.4.4参照，表A.3の関連表） 

技法及び手段 

特性 

要求するソフトウェア特性でソフ

トウェアの作成を支援 

ツールの動作及び機能の明確さ 

アウトプットの正確さ及び再現性 

1 

適切なプログラミング言語 

R2 

強い型付け，限定型変換の場合 
 

R3 

厳密な推論用に定義したセマンテ
ィクスの場合 

− 

− 

2 

厳密に型付けしたプログラミ
ング言語 

R2 

− 

− 

3 

言語サブセット 

R2 

選択するサブセットに依存 

R1 

R2 

選択するサブセットに依存 

4a 

認定ツール 

− 

R2 

R2 

4b 

ツール：使用によって信頼性
が増すもの 

R1 

検出したプログラムエラーのクラ
スを系統的に定義している場合 
 

R2 

ツール性能に関して客観的な妥当
性確認の証拠がある場合 

R1 

ツールサポートが問題ドメイン専
用でない場合 
 

R2 

ツールサポートが問題ドメインに
著しく特化している場合 

R1 

R2 

承諾者妥当性確認スイートなど，
ツール性能に関して客観的な妥当
性確認の証拠がある場合 

7

1

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

72 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.4−決定論的安全度に関する特性−ソフトウェア設計及び開発−詳細設計 

（ソフトウェアシステム設計，ソフトウェアモジュール設計及びコーディングを含む）（7.4.5及び7.4.6参照，表A.4の関連表） 

技法及び手段 

特性 

ソフトウェア安
全要求仕様の完

全性 

ソフトウェア安
全要求仕様の正

確性 

固有設計フォー

ルトの回避性 

単純さ及び理解

容易性 

挙動の予測可能

性 

検証及びテスト

可能な設計 

フォールトトレ
ランス及びフォ

ールト検出 

共通原因故障の

回避性 

1a 構造化手法 

R2 

R1 

R1 

− 

− 

R1 

構造化設計を，す
ぐに検証及びテ
ストが可能 

− 

− 

1b 準形式手法 

R2 

R2 

R2 

− 

R2 

R2 

− 

− 

1c 形式的設計及

び精緻化手法 

− 

R3 

R3 

− 

注記：この特性の
達成が困難にな
ってもよい 

R3 

予測可能性の証
拠を提示する 

R2 

− 

− 

2 

コンピュータ
支援設計ツー
ル 

R2 

意味及び構文チ
ェックを行って
関連規則を満た
していることを
確認するための
コンピュータ支
援仕様書作成ツ
ールに依存 

R1 

R2 

意味及び構文チ
ェックを行って
関連規則を満た
していることを
確認するための
コンピュータ支
援仕様書作成ツ
ールに依存 

− 

− 

R2 

テスト対象範囲
及び静的適合確
認をサポートす
るためのCASE
ツールに依存 

− 

− 

3 

防御的プログ
ラミング 

− 

− 

− 

− 

注記：この特性の
達成が困難にな
ってもよい 

− 

注記：この特性の
達成が困難にな
ってもよい 

− 

R1 

（カバレッジ目
標を定義し，その
正当な根拠を示
し，その目標を満
たしている場合
はR2） 

R1 

（カバレッジ目
標を定義し，その
正当な根拠を示
し，その目標を満
たしている場合
はR2） 

4 

モジュラーア
プローチ 

− 

− 

R1 

R1 

R1 

R1 

− 

− 

7

2

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

73 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.4−決定論的安全度に関する特性−ソフトウェア設計及び開発−詳細設計 

（ソフトウェアシステム設計，ソフトウェアモジュール設計及びコーディングを含む）（7.4.5及び7.4.6参照，表A.4の関連表）（続き） 

技法及び手段 

特性 

ソフトウェア安
全要求仕様の完

全性 

ソフトウェア安
全要求仕様の正

確性 

固有設計フォー

ルトの回避性 

単純さ及び理解

容易性 

挙動の予測可能

性 

検証及びテスト

可能な設計 

フォールトトレ
ランス及びフォ

ールト検出 

共通原因故障の

回避性 

5 

設計及びコー
ディング基準 

− 

− 

R1 

R1 

R1 

R1 

− 

− 

6 

構造化プログ
ラミング 

− 

R1 

R1 

R1 

R1 

R1 

− 

− 

7 

信頼性確認/検
証済ソフトウ
ェア要素の使
用（使用可能
な場合） 

− 

− 

R1 

実績のある要素
の再利用 

R1 

モジュラー・アプ
ローチは複雑さ
全体を理解しや
すいユニットに
分解 

R1 

要素の挙動は既
知 

− 

− 

− 

8 

ソフトウェア
安全要求仕様
とソフトウェ
ア設計との間
の前方トレー
サビリティ 

R1 

設計がソフトウ
ェア安全要求事
項に対応してい
るという確信性 

− 

− 

− 

− 

− 

− 

− 

7

3

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

74 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.5−決定論的安全度に関する特性−ソフトウェア設計及び開発−ソフトウェアモジュールテスト及び統合 

（7.4.7，7.4.8参照，表A.5の関連表） 

技法及び手段 

特性 

ソフトウェア設計仕様に関するテ

スト及び統合の完全性 

ソフトウェア設計仕様に関するテス

ト及び統合の正確性（正常完了） 

再現性 

正確に定義したテスト構成 

1 

確率的テスト 

R1 

（稼働プロファイルのカバレッジ目

標を定義し，その正当な根拠を示
し，それを満たしている場合はR2） 

R1 

（必要なアウトプットを定義し，その

正当な根拠を示し，それを満たしてい
る場合はR2） 

− 

− 

2 

動的解析及び
テスト 

R1 

（構造的カバレッジ目標を定義し，

その正当な根拠を示し，それを満た
している場合はR2） 

R1 

（必要なアウトプットを定義し，その

正当な根拠を示し，それを満たしてい
る場合はR2） 

− 

− 

3 

データの記録
及び解析 

− 

R1 

R1 

テスト手順の整合性を高める 

R2 

フォールト記録／テストログがソ
フトウェア基準の詳細を含んでい
る場合 

4 

機能及びブラ
ックボックス
テスト 

R1 

（稼働プロファイルのカバレッジ目

標を定義し，その正当な根拠を示
し，それを満たしている場合はR2） 

R1 

（必要なアウトプットを定義し，その

正当な根拠を示し，それを満たしてい
る場合はR2） 

− 

− 

5 

性能テスト 

− 

R1 

（必要なアウトプットを定義し，その

正当な根拠を示し，それを満たしてい
る場合はR2） 

− 

− 

6 

モデルベース
テスト（MBT） 

R2 

MBTは仕様及び設計の曖昧さを早
期に露出させ，MBTプロセスは要
求事項で始まる 
 

R3 

モデリングに厳密な推論を当ては
める場合は，テストケース生成

（TCG）を使用する 

R2 

結果及びリグレッションテストスイ
ートの評価はMBTの重要な特典であ
る 
 

R3 

厳密なモデリングアプローチを適用
する場合，対象範囲の客観的な証拠が
得られる可能性がある 

R3 

MBT（TCGと同じく）は生成す
るテストの自動実行を目指す 

R2 

MBTを自動実行する場合，テスト
構成を正確に定義しなければなら
ない。生成するテストの実行はブラ
ックボックステストに類似してお
り，ソースコードレベルのカバレッ
ジ測定と組み合わせられる可能性
がある 

7

4

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

75 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.5−決定論的安全度に関する特性−ソフトウェア設計及び開発−ソフトウェアモジュールテスト及び統合 

（7.4.7，7.4.8参照，表A.5の関連表）（続き） 

技法及び手段 

特性 

ソフトウェア設計仕様に関するテ

スト及び統合の完全性 

ソフトウェア設計仕様に関するテス

ト及び統合の正確性（正常完了） 

再現性 

正確に定義したテスト構成 

7 

インタフェー
ステスト 

− 

R1 

（必要なアウトプットを定義し，その

正当な根拠を示し，それを満たしてい
る場合はR2） 

− 

− 

8 

テスト管理及
び自動化ツー
ル 

R1 

（テストカバレッジ目標を定義し，

その正当な根拠を示し，それを満た
している場合はR2） 

− 

R1 

自動化で整合性が増す 

R2 

テストの再現性が得られる 

9 

ソフトウェア
安全要求仕様
とモジュール
統合テスト仕
様との間の前
方トレーサビ
リティ 

R1 

テスト仕様がソフトウェア安全要
求事項に対応しているという信頼
性 

− 

− 

R2 

テスト時の要求事項の明確な基準
の信頼性 

10  形式的適合確

認 

R3 

厳密な推論をテストケースの構築
に適用し，設計の全側面が動作した
ことを明示する場合 

R3 

全てのソフトウェア要求事項を満た
しているという客観的な証拠を出す 

R1 

支援ツールがない場合 
 

R2 

ツールの支援がある場合 

− 

7

5

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

76 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.6−決定論的安全度に関する特性−プログラマブル電子装置の統合（ハードウェア及びソフトウェア） 

（7.5参照，表A.6の関連表） 

技法及び手段 

特性 

設計仕様に関する統合の完全性 

設計仕様に関する統合の正確性 

（正常完了） 

再現性 

正確に定義した統合構

成 

1 

機能及び 
ブラックボックステスト 

R1 

（稼働プロファイルのカバレッジ目標を定義
し，その正当な根拠を示して，それを満たし
ている場合はR2） 

R1 

（必要なアウトプットを定義し，その
正当な根拠を示して，それを満たして
いる場合はR2） 

− 

− 

2 

性能テスト 

− 

R1 

（必要なアウトプットを定義し，その
正当な根拠を示して，それを満たして
いる場合はR2） 

− 

− 

3 

ハードウェア及びソフトウェ
ア統合に関するシステム，並び
にソフトウェア設計要求事項
とハードウェア及びソフトウ
ェア統合テスト仕様との間の
前方トレーサビリティ 

R1 

ハードウェア及びソフトウェア統合テスト仕
様が統合要求事項に対応しているという確信
性 

− 

− 

R2 

テスト時の要求事項の
明確な基準の信頼性 

7

6

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

77 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.7−決定論的安全度に関する特性−システム安全妥当性確認のソフトウェア（7.7参照，表A.7の関連表） 

技法及び手段 

特性 

ソフトウェア設計仕様に関する妥当

性確認の完全性 

ソフトウェア設計仕様に関する妥当性確

認の正確性（正常完了） 

再現性 

正確に定義した妥当性確

認構成 

1 

確率的テスト 

R1 

（稼働プロファイルのカバレッジ目標

を定義し，その正当な根拠を示し，そ
れを満たしている場合はR2） 

R1 

（必要なアウトプットを定義し，その正当

な根拠を示し，それを満たしている場合
はR2） 

− 

− 

2 

プロセスシミュレーション 

R1 

R1 

（必要なアウトプットを定義し，その正当

な根拠を示し，それを満たしている場合
はR2） 

− 

R2 

外部環境の定義をもたら
す 

3 

機能及びブラックボックステス
ト 

R1 

（稼働プロファイルのカバレッジ目標

を定義し，その正当な根拠を示し，そ
れを満たしている場合はR2） 

R1 

（必要なアウトプットを定義し，その正当

な根拠を示し，それを満たしている場合
はR2） 

− 

− 

4 

ソフトウェア安全要求仕様と，
ソフトウェア安全妥当性確認計
画との間の，前方トレーサビリ
ティ 

R1 

ソフトウェア安全妥当性確認計画が
ソフトウェア安全要求事項に対応し
ているという確信性 

− 

− 

R2 

テスト時の要求事項の明
確な基準の信頼性 

5 

ソフトウェア安全妥当性確認計
画と，ソフトウェア安全要求仕
様との間の，後方トレーサビリ
ティ 

− 

R1 

ソフトウェア安全妥当性確認計画が不要
な複雑さを含んでいないという確信性 

− 

R2 

テスト時の要求事項の明
確な基準の信頼性 

7

7

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

78 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.8−決定論的安全度に関する特性−ソフトウェア部分改修（7.8参照，表A.8の関連表） 

技法及び手段 

特性 

要求事項に関する部

分改修の完全性 

要求事項に関する部

分改修の正確性 

固有設計フォールト

の発生の回避性 

好ましくない挙動の

回避 

検証及びテスト可能

な設計 

リグレッションテスト及

び適合確認の対象範囲 

1 

影響解析 

− 

− 

− 

R1 

R1 

R1 

2 

変更したソフトウェア
モジュールの再適合確
認 

R1 

（客観的適合確認目

標の場合はR2） 

R1 

（客観的適合確認目

標の場合はR2） 

R1 

（客観的適合確認目

標の場合はR2） 

− 

− 

R1 R2 

（客観的適合確認目標 

の場合はR2） 

3 

影響を受けるソフトウ
ェアモジュールの再適
合確認 

R1 

（客観的適合確認目

標の場合はR2） 

R1 

（客観的適合確認目

標の場合はR2） 

R1 

（客観的適合確認目

標の場合はR2） 

− 

− 

R1 

（客観的適合確認目標 

の場合はR2） 

4a システム全体の再妥当

性確認 

R1 

（客観的適合確認目

標の場合はR2） 

R1 

（客観的適合確認目

標の場合はR2） 

− 

R1 

（客観的適合確認目

標の場合はR2） 

− 

R1 

（客観的適合確認目標 

の場合はR2） 

4b リグレッション妥当性

確認 

R1 

（客観的適合確認目

標の場合はR2） 

R1 

（客観的適合確認目

標の場合はR2） 

− 

R1 

（客観的適合確認目

標の場合はR2） 

− 

R1 

（客観的適合確認目標 

の場合はR2） 

5 

ソフトウェア構成管理 

− 

− 

− 

− 

− 

R1 

6 

データの記録及び解析 

R1 

R1 

− 

− 

− 

− 

7 

ソフトウェア安全要求
仕様と，ソフトウェア
部分改修計画（再適合
確認及び再妥当性確認
を含む）との間の，前
方トレーサビリティ 

R1 

ソフトウェア部分改
修計画（再適合確認
と及び再妥当性確認
を含む）がソフトウ
ェア安全要求事項に
対応しているという
確信性 

− 

− 

− 

− 

− 

8 

ソフトウェア部分改修
計画（再適合確認及び
再妥当性確認を含む）
と，ソフトウェア安全
要求仕様との間の，後
方トレーサビリティ 

− 

R1 

ソフトウェア部分改
修計画（再適合確認
及び再妥当性確認を
含む）が不要な複雑
さを含んでいないと
いう確信性 

7

8

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

79 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.9−決定論的安全度に関する特性−ソフトウェア適合確認（7.9参照，表A.9の関連表） 

技法及び手段 

特性 

事前のフェーズに関する適合確認の完

全性 

事前フェーズに関する適合確認の正確性 

（正常完了） 

再現性 

正確に定義した適合確

認構成 

1 

形式的証明 

− 

R3 

− 

− 

2 

仕様及び設計のアニメーション 

R1 

R1 

− 

− 

3 

静的解析 

− 

R1/R2/R3 

（厳密さは，言語サブセット強制から数学的形式

的解析までの範囲に及んでもよい） 

− 

− 

4 

動的解析及びテスト 

R1 

（構造的カバレッジ目標を定義し，その

正当な根拠を示し，それを満たしてい
る場合はR2） 

R1 

（必要なアウトプットを定義し，その正当な根拠

を示し，それを満たしている場合はR2） 

− 

− 

5 

ソフトウェア設計仕様と，ソフト
ウェア適合確認（データ適合確認
を含む）計画との間の，前方トレ
ーサビリティ 

R1 

ソフトウェア適合確認（データ適合確
認を含む）計画がソフトウェア安全要
求事項に対応しているという確信性 

− 

− 

R2 

テスト時の要求事項の
明確な基準の信頼性 

6 

ソフトウェア適合確認（データ適
合確認を含む）計画と，ソフトウ
ェア設計仕様との間の，後方トレ
ーサビリティ 

− 

R1 

ソフトウェア適合確認（データ適合確認を含む）
計画が不要な複雑を含んでいないという確信性 

− 

R2 

テスト時の要求事項の
明確な基準の信頼性 

7 

オフライン数値解析 

− 

R1 

健全な計算で予測する数値の正確性に関する信
頼性の向上 
 

（客観的な合否判定基準がある場合はR2。合否

判定基準を裏づける客観的な系統的推論に合わ
せて使用する場合はR3） 

− 

− 

7

9

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

80 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.10−決定論的安全度に関する特性−機能安全評価（箇条8参照。表A.10の関連表） 

技法及び手段 

特性 

この規格に関する機
能安全評価の完全性 

設計仕様に関する機
能安全評価の正確性

（正常完了） 

特定した全ての問題
の追跡可能な状態で

の終結 

変更後に評価を広範
に手直しする必要な
く機能安全評価を修

正する能力 

再現性 

適時性 

正確に定義

した構成 

1 

チェックリスト 

R1 

R1 

R1 

− 

R1 

− 

− 

2 

決定表又は真値表 

R1 

R2 

− 

− 

R2 

− 

− 

3 

故障分析 

R2 

R2 

R1 

（故障分析は，合意し

た故障リストを基準
にする） 

− 

R1 

（故障分析は，合意し

た故障リストを基準
にする） 

− 

− 

4 

ダイバースソフトウェ
アの共通原因故障分析

（ダイバースソフトウ

ェアを実際に用いる場
合） 

R2 

R2 

R1 

（CCF分析が合意し

たCCイニシエータ
リストを基準にして
いる場合） 

− 

R1 

（CCF分析が合意し

たCCイニシエータ
リストを基準にして
いる場合） 

− 

− 

5 

信頼性ブロック図 

R1 

R1 

− 

− 

− 

− 

− 

6 

この規格の箇条8の要
求事項と，ソフトウェ
ア機能安全評価計画と
の間の，前方トレーサ
ビリティ 

R1 

ソフトウェア機能安
全評価計画がこの規
格の箇条8の要求事
項に対応していると
いう確信性 

− 

− 

− 

− 

− 

− 

8

0

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

81 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

C.3 決定論的安全度に関する特性−詳細表 

表C.11−詳細特性−設計コーディング基準（表B.1の関連表） 

技法及び手段 

特性 

ソフトウェア安
全要求仕様の完

全性 

ソフトウェア安
全要求仕様の正

確性 

固有設計フォー

ルトの回避性 

単純さ及び理解

容易性 

挙動の予測可能

性 

検証及びテスト

可能な設計 

フォールトトレ
ランス及び／フ

ォールト検出 

共通原因故障の

回避性 

1 

エラーの可能性を少
なくするためのコー
ディング基準の使用 

− 

− 

R1 

R1 

選択した言語構
成要素の除外 

R1 

R1 

− 

− 

2 

動的オブジェクトな
し 

− 

− 

R1/R2/R3 

使用する言語に
依存 

− 

R1/R2/R3 

使用する言語に
依存 

R1/R2 

使用する言語に
依存 

− 

− 

3a 動的変数なし 

− 

− 

R1/R2/R3 

使用する言語に
依存 

− 

R1/R2/R3 

使用する言語に
依存 

R1/R2 

使用する言語に
依存 

− 

− 

3b 動的変数の追加時の

オンラインチェック 

− 

− 

R1/R2/R3 

使用する言語に
依存 

− 

R1/R2/R3 

使用する言語に
依存 

R1/R2 

使用する言語に
依存 

− 

− 

4 

割込の制限使用 

− 

− 

R1/R2 

使用する言語に
依存 

R1 

ロジック及び事
象発生順序の明
確さの向上 

R1/R2 

使用する言語に
依存 

R1/R2 

使用する言語に
依存 

− 

− 

5 

ポインタの制限使用 

− 

− 

R1/R2 

使用する言語に
依存 

R1 

ロジックの明確
さの向上 

R1/R2 

使用する言語に
依存 

R1/R2 

使用する言語に
依存 

− 

− 

6 

再帰の制限使用 

− 

− 

R1/R2 

使用する言語に
依存 

− 

R1/R2 

使用する言語に
依存 

R1/R2 

使用する言語に
依存 

− 

− 

7 

高級言語のプログラ
ムの中に非構造化制
御フローがない 

− 

− 

R1/R2 

使用する言語に
依存 

R1 

ロジックの明確
さの向上 

R1/R2 

使用する言語に
依存 

R1/R2 

使用する言語に
依存 

− 

− 

8 

自動型変換がない 

− 

R2 

丸め誤差を防ぐ 

R2 

丸め誤差を防ぐ 

R1 

R1 

− 

− 

− 

8

1

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

82 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.12−詳細特性−動的解析及びテスト（表B.2の関連表） 

技法及び手段 

特性 

ソフトウェア設計仕様に関するテ

スト及び適合確認の完全性 

ソフトウェア設計仕様に関するテスト及び適

合確認の正確性（正常完了） 

再現性 

正確に定義したテスト及び

適合確認の構成 

1 

境界値解析からのテス
トケース実行 

− 

R1 

（境界結果に客観的基準がある場合はR2） 

− 

− 

2 

エラー推定からのテス
トケース実行 

− 

R1 

− 

− 

3 

エラーシーディングか
らのテストケース実行 

− 

R1 

− 

− 

4 

モデルベーステストケ
ース生成からのテスト
ケース実行 

R2 

MBTプロセスは要求事項で始ま
り，ソフトウェア設計及び開発時
に早期のエラー発見が容易になる 
 

R3 

厳密な推論をモデリングに適用
し，TCG（テストケース生成）を
使用する場合 

R2 

結果及びリグレッションテストスイートの評
価がMBTの主要なメリットであり，更に，特
定の要求事項の結果の理解を容易にする 
 

R3 

厳密なモデリングアプローチを適用する場合，
カバレッジの客観的証拠が得られる可能性が
ある 

R3 

MBT（TCGを伴う）
は，生成するテストの
自動実行を目的とす
る 

R2 

MBTを自動化するときは，
テスト構成を正確に定義し
なければならない。生成する
テストの実行は，ソースコー
ドレベルのカバレッジ測定
と組み合わせられる可能性
があり，ブラックボックステ
ストと類似性がある 

5 

性能モデリング 

− 

R1 

（客観的性能要求事項がある場合はR2） 

− 

− 

6 

同値クラス及び入力分
割テスト 

R1 

（インプットデータプロファイル

を十分に定義し，構造が管理しや
すく単純である場合） 

R1 

（分割が非線形性を含まないような場合，すな

わち，クラスの全メンバーが真に等価である場
合） 

− 

− 

7 

構造化ベースのテスト 

− 

R1 

（R2は客観的な構造的カバレッジの目標） 

− 

− 

8

2

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

83 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.13−詳細特性−機能及びブラックボックステスト（表B.3の関連表） 

技法及び手段 

特性 

設計仕様に関するテスト，統合及び妥

当性確認の完全性 

設計仕様に関するテスト，統合及び妥当

性確認の正確性（正常完了） 

再現性 

正確に定義したテスト，統

合及び妥当性確認の構成 

1 

原因結果図からのテス
トケース実行 

R1 

R1 

− 

− 

2 

モデルベースのテスト
ケース生成からのテス
トケース実行 

R2 

MBTモデルベーステストは，システ
ム要求事項及び特定の機能のモデル
を用いた効率的なテストケース又は
テスト手順の自動生成であり，早期の
エラー発見及び特定の要求事項の理
解を容易にする 
 

R3 

厳密な推論をモデリングに適用し，
TCGを使用する場合 

R2 

MBTは（主に機能又は挙動の）要求事項
から導き出したシステムモデルに基づく 
 

R3 

厳密なモデリングアプローチを適用する
場合，カバレッジの客観的な証拠が得ら
れる可能性がある 

R3 

MBT（TCGを伴う）は，
生成するテストの自動
実行を目的とする 

R2 

MBTを自動化するときはテ
スト構成を正確に定義しな
ければならない 

3 

プロトタイピング／ア
ニメーション 

− 

R1 

− 

− 

4 

境界値解析を含む同値
クラス及びインプット
分割テスト 

R1 

（インプットデータプロファイルを十

分に定義し，構造が管理しやすく単純
である場合） 

R1 

（分割が非線形性を含んでいそうもない

場合，すなわち，クラスの全メンバーが
真に等価である場合） 

− 

− 

5 

プロセスシミュレーシ
ョン 

− 

R1 

− 

R2 

外部環境の定義を示す 

8

3

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

84 

C 0508-3：2014 (IEC 61508-3：2010) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。 

表C.14−詳細特性−故障分析（表B.4の関連表） 

技法及び手段 

特性 

この規格に関する
機能安全評価の完

全性 

設計仕様に関する機
能安全評価の正確性

（正常完了） 

特定した全ての問題の追

跡可能な状態での終結 

変更後に評価を広範に手直し
する必要なく機能安全評価を

修正する能力 

再現性 

適時性 

正確に定義

した構成 

1a 

原因結果図 

R2 

R2 

− 

− 

− 

− 

− 

1b 

事象の木解析 

R2 

R2 

− 

− 

− 

− 

− 

2 

フォールトの木解析 

R2 

R2 

− 

− 

− 

− 

− 

3 

ソフトウェア機能故
障分析 

R2 

R2 

− 

− 

− 

− 

− 

表C.15−詳細特性−モデリング（表B.5の関連表） 

技法及び手段 

特性 

ソフトウェア設計仕様に関する

妥当性確認の完全性 

ソフトウェア設計仕様に関する妥

当性確認の正確性（正常完了） 

再現性 

正確に定義した妥当性確認の構成 

1 

データフロー図 

− 

R1 

− 

− 

2a 

有限状態機械 

R3 

R3 

− 

− 

2b 

形式手法 

R3 

R3 

− 

− 

2c 

タイムペトリネット 

− 

R1 

− 

− 

3 

性能モデリング 

− 

R1 

− 

− 

4 

プロトタイピング及び
アニメーション 

− 

R1 

− 

− 

5 

構成図 

− 

R1 

− 

− 

8

4

C

 0

5

0

8

-3

：

2

0

1

4

 (I

E

C

 6

1

5

0

8

-3

：

2

0

1

0

) 

2019年7月1日の法改正により名称が変わりました。まえがきを除き、本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。