>サイトトップへ >このカテゴリの一覧へ

C 0508-3

:2014 (IEC 61508-3:2010)

(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)

まえがき

この規格は,工業標準化法第 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 部:技術及び手法の概観(改正予定)


日本工業規格

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 0508IEC 61508)規格群を基本とした適用分野

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

注記 1  JIS C 0508IEC 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)

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

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

かつ,包括的である。

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

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

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

ある。

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

する。

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

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

準を導入する。

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

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

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

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

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

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

−  低頻度作動要求モードの場合,作動要求時の危険側機能失敗時間平均確率(PFD

avg

)を 10

5

に設定

する。

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

10

9

[1/h]に設定する。

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

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

とが可能であるが,これらの限界値は,現時点で比較的複雑なシステム(

例  プログラマ

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

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

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

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

るとみなしてもよい。

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

的対応能力を導入する。

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

が,

“フェールセーフ”の概念は明示的には使用しない。ただし,

“フェールセーフ”及び“固有(本

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

適用範囲 

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)

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

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

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

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

c)

JIS C 0508-1

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

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

d)

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

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

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

規定する必要はない。

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

図 及び図 を参照。

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

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

注記 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 との関係を,図 及び附属書 に示す。

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

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

C 0508-3

が果たす役割を示す。


4

C 0508-3

:2014 (IEC 61508-3:2010)

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

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 に基づき,

“一致している”こ

とを示す。

技術的要求事項

その他の要求事項

第  

用語の定義

及び略語

第  
文書化

箇条 及び

附属書 A

第  

機能安全の管理

箇条 6

第  

機能安全評価

箇条 8

第  

安全度水準の決定

のための方法の例

第  

第 部及び第 3

部の適用指針

第  

E/E/PE

安全関連系に対する

要求仕様

7.10 

第  

技術及び手法の

概観

第  

E/E/PE

安全関連系の設置,引渡し及び

安全妥当性確認

7.13

7.14 

第  

E/E/PE

安全関連系の運用及び保全,修理,

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

7.15

7.17 

第  

E/E/PE

安全

関連系の実現

フェーズ

第  

安全関連ソフト

ウェアの実現

フェーズ

第  

E/E/PE

安全関連系への

安全度要求事項の割当て

7.6 

第  

全体要求事項の作成

(概念,適用範囲の定義,潜在危険及

びリスク解析)

7.1

7.5

図 1−この規格群(JIS C 0508 規格群)の全枠組み 


5

C 0508-3

:2014 (IEC 61508-3:2010)

図 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 部:電気・電子・プログ

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

概念

全対象範囲の定義

潜在危険及びリスク解析

全安全要求事項

全安全要求事項の

割当て

全体計画

全運用

及び

保全計画

全安全 
妥当性

確認計画

全設置

及び

引渡し計画

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)

注記  対 応 国 際 規 格 : 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

用語及び定義 

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

この規格への適合 

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

文書化 

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

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

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)

−  適合確認文書

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

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

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

d)

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

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

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

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

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

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

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

る。

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

必要となる。

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

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

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

e)

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

確実に導入する。

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

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

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

f)

あとで機能安全監査ができるように,構成ステータス(構成状況)

,リリースステータス(市場公開状

況)

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

g)

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

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

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

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

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

7.1 

一般 

7.1.1 

目的 

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

る(

表 及び図 2∼図 を参照)。

7.1.2 

要求事項 

7.1.2.1

JIS C 0508-1

の箇条 に従って,安全計画中にソフトウェアの開発に関する安全ライフサイクル

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

7.1.2.2

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

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

7.1.2.3

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


8

C 0508-3

:2014 (IEC 61508-3:2010)

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

注記  図 2∼図 及び表 を参照。

7.1.2.4

ソフトウェア安全ライフサイクルが

表 の要求事項を満たしている場合,安全度及びプロジェク

トの複雑さに対応するように,V モデル(

図 参照)をテーラリングしてもよい。

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

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

表 のライフサイ

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

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

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

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

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

附属書 を参照。

7.1.2.5

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

ない。

7.1.2.6

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

7.1.2.7

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

附属書 及び

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

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

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

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

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

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

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

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

7.1.2.8

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

照)

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

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

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

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

必須要求事項である。

7.1.2.9

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

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

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

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

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

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


9

C 0508-3

:2014 (IEC 61508-3:2010)

図 3E/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

安全妥当性確認

図 のボックス 12 へ

図 のボックス 14 へ

10 

E/E/PE

安全関連系

実現

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

サイクルを参照)

各 E/E/PE 安全

関連系に対して

一つの E/E/PE

安全ライフサイクル

図 のボックス 10

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

E/E/PE

系安全

ライフサイクル

図 参照)

PE

統合(ハードウェア

及びソフトウェア)

ソフトウェアの設計

及び開発

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

ソフトウェアの運用及び

保全手順

ソフトウェア関連システ

ム安全妥当性確認

システム安全のソフト

ウェアの妥当性確認計画

図 のボックス 14

図 のボックス 12

図 のボックス 14 へ

図 のボックス 12 へ


10

C 0508-3

:2014 (IEC 61508-3:2010)

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

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

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)

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

安全ライフ

サイクルフェーズ

目的

範囲

要求事
項の細

分箇条

引継ぎ事項

引渡し事項

図 の 
ボック

ス番号

標題

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)

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

安全ライフ

サイクルフェーズ

目的

範囲

要求事
項の細

分箇条

引継ぎ事項

引渡し事項

図 の 
ボック

ス番号

標題

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)

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

安全ライフ

サイクルフェーズ

目的

範囲

要求事
項の細

分箇条

引継ぎ事項

引渡し事項

図 の 
ボック

ス番号

標題

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)

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

安全ライフ

サイクルフェーズ

目的

範囲

要求事
項の細

分箇条

引継ぎ事項

引渡し事項

図 の 
ボック

ス番号

標題

ソ フ ト ウ ェ

ア部分改修

要求するソフトウェアの決定論的

対応能力の保持を保証する,妥当
性確認したソフトウェアの修正,

拡張又は改編を手引きする。

同上

7.8.2 

ソフトウェア部

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

分改修の要請

ソフトウェア部

分改修の影響解
析結果

ソフトウェア部
分改修ログ

ソ フ ト ウ ェ
ア適合確認

所定のソフトウェア安全ライフサ
イクルフェーズの引渡し事項のテ

スト及び評価を行い,そのフェー

ズの引継ぎ事項となる引渡し事項
及び基準に関しての正確さと一貫

性を保証する。

フェーズに
よる

7.9.2 

適切な適合確認
計画書(フェー

ズによる)

適切な適合確認
報告書(フェー

ズによる)

ソ フ ト ウ ェ

ア の 機 能 安
全評価

E/E/PE

安全関連系が達成する機能

安全のソフトウェアに関して調査
し,判定に至る。

上記の全て

のフェーズ

ソフトウェア機

能安全評価計画

ソフトウェア機

能安全評価報告

7.2 

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

注記  このフェーズは,図 のボックス 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.17.2.2.13 を満たす特徴を得るため

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

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

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

安全要求仕様の次の特性(特性の解釈に関する手引書については

附属書 を,非形式の定義

については IEC 61508-7 

附属書 を参照)を検討することが望ましい。

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

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

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

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


15

C 0508-3

:2014 (IEC 61508-3:2010)

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

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

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

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

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

。ソフ

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

きく依存する。

7.2.2.1 E/E/PE

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

0508-2

の箇条 参照)は,ソフトウェア安全要求事項を,再度規定する必要はない。

7.2.2.2

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

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

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

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

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

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

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

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

図 を参照。

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

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

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

7.4.2.12

を参照。

7.2.2.3

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

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

なければならない。

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

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

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

7.2.2.4

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

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

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

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)

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 の箇条 参照)

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)

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

a)

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

b)

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

c)

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

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

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

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

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

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

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

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

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 の箇条 参照),E/E/PE 安全関

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

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

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

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

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

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

であることが望ましい。

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

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

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

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

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

7.3 

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


18

C 0508-3

:2014 (IEC 61508-3:2010)

注記 1  このフェーズは,図 のボックス 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 の箇条 参照)

。また,この手順では,

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

7.3.2.5

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

い。


19

C 0508-3

:2014 (IEC 61508-3:2010)

a)

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

b)

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

c)

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

7.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)の供給者]にあることもあれば,その環境の使用者(例

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

分担は,安全計画時に決めなければならない(箇条 参照)

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

は,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)

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

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

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

に属するものとして取り扱わなければならない。

独立性を時間域かつ空間的領域の両方で達成しているか,

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

しなければならない。

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

7.4.2.10

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

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

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

7.4.2.11

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

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

ない。

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

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

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

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

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

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

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

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


21

C 0508-3

:2014 (IEC 61508-3:2010)

イバースモニタであり(IEC 61508-7 の C.3.4 参照)

,必要に応じて,非常停止に適用する。二つ

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

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

7.4.2.12

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

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

a)

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

−  ルート 1

S

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

の要求事項への適合

−  ルート 2

S

:使用における実証。要素を使用において実証しているという証拠を示す。JIS C 0508-2

の 7.4.10 参照

−  ルート 3

S

:非適合開発の評価。7.4.2.13 への適合

注記 1  ルート 1

S

,2

S

及び 3

S

は,特にソフトウェア要素に依拠した 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 

附属書 及びこ

の規格の

附属書 参照)を提供する。

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

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

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

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

ることもある。

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

7.4.2.13

ルート 3

S

に適合するために,既存のソフトウェア要素は,次の a)i)  の全ての要求事項を満た

さなければならない。

a)

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

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

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

含まなければならない。

表 A.1 を参照。

b)

ソフトウェア要素の使用に関する正当化は,

附属書 の手引書を考慮しながら,参照しなければなら

ない箇条(すなわち,7.2.27.4.37.4.47.4.57.4.67.4.77.5.27.7.27.8.27.9.2 及び箇条 8

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

c)

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

文書化しなければならない。7.4.37.4.57.4.6 並びに

表 A.2 及び表 A.4 を参照。

d)  a)

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

ない。7.5 及び

表 A.6 を参照。


22

C 0508-3

:2014 (IEC 61508-3:2010)

e)

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

て,要素が適合確認及び妥当性確認を受けたという証拠がなければならない。7.4.77.4.87.57.7

及び 7.9

表 A.5∼表 A.7 及び表 A.9,並びに附属書 の関連する表を参照。

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

い(

表 A.7 及び表 B.3 参照)。

f)

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

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

ればならない。

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

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

−  その機能を無効にする

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

ティ,アウトプットの信ぴょう(憑)性チェック]

−  広範なテスト

g)

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

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

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

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

ティ,アウトプットの信ぴょう(憑)性チェック]

−  例外処理

h)

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

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

i)

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

けで有効なものでなければならない(

附属書 D,及び JIS C 0508-2 の附属書 参照)。

7.4.2.14

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

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

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

a) PE

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

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

ビリティ(構成の容易性)

,事前に配付した既存の機能,及び PE 安全関連系の複雑さの程度に相応の

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

b) PE

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

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

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

c)

データ構成の仕様は,次による。

1)

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

2)

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

3)

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

4)

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

d) PE

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


23

C 0508-3

:2014 (IEC 61508-3:2010)

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

7.4.3 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注記 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  この箇条の要求事項を実現するための適切な技法及び手段(附属書 及び附属書 参照)を

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

は IEC 61508-7 

附属書 を,参考となる定義については附属書 を参照。)を検討するこ

とが望ましい。

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

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

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

−  単純さ及び理解容易性

−  挙動の予測可能性

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

−  フォールトトレランス

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


24

C 0508-3

:2014 (IEC 61508-3:2010)

7.4.3.1

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

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

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 開発者と合意し,その変更を文書化しなければならない。

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

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

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

要がある。

7.4.4 

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

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

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

を,参考となる定義については

附属書 を参照。)を検討することが望ましい。

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

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

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

7.4.4.1

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


25

C 0508-3

:2014 (IEC 61508-3:2010)

い。

注記  オンライン及びオフラインツールの例については,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

の箇条 を参照。

7.4.4.3

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

7.4.4.4

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

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

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

0508-4

の 3.2.11 を参照。

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

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

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


26

C 0508-3

:2014 (IEC 61508-3:2010)

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

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

に記載することがある。

)は,適合品目安全マニュアルに記載して,組み込んだ要素全体又はそ

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

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)

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)

クリプトを含む)

注記  この箇条の目的は,ベースラインの再構築を可能にすることである。

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 の箇条 参照)

7.4.5 

詳細設計及び開発の要求事項−ソフトウェアシステム設計 

注記 1  ここでいう詳細設計とは,ソフトウェアシステム設計,すなわち,アーキテクチャ内の主要

要素のソフトウェアモジュールのシステムへの分割,個々のソフトウェアモジュール設計及

びコーディングを意味するものと定義する。小規模なアプリケーションでは,ソフトウェア

システム設計とアーキテクチャ設計とを組み合わせてよい。

注記 2  詳細設計及び開発の性質は,ソフトウェア開発業務及びソフトウェアアーキテクチャ(7.4.3

を参照)の特性によって異なる。ラダーロジック,機能ブロックなど,ある種のプログラミ

ング言語の場合,詳細設計は,プログラミングというより構成作成と考えることができる。

それでもなお,構造化した方法でソフトウェアを設計することは,実践規範である。ここで

いう構造化した方法とは,安全関連部を他から(できる限り)切り離してソフトウェアをモ

ジュール構造に編成することである。これには,範囲チェック,その他のデータ入力ミスを

防止する機能を含み,以前に検証したソフトウェアモジュールの使用,将来のソフトウェア

部分改修を容易にする設計の提供を含む。

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

属書 参照),設計及び開発について,次の特性(特性の解釈の手引書については IEC 61508-7

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

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

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

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

−  単純さ及び理解容易性

−  挙動の予測可能性

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


29

C 0508-3

:2014 (IEC 61508-3:2010)

−  フォールトトレランス又はフォールト検出

−  共通原因故障の回避性

7.4.5.1

ソフトウェア開発の性質に応じて,7.4.5 に適合する責任は,複数の当事者が負うものでよい。責

任分担は,安全計画時に文書化しなければならない(JIS C 0508-1 の箇条 参照)

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 

コード実装の要求事項 

注記  安全度水準の要求する範囲で,ソースコードは,コードの次の特性(具体的な技法については

附属書 及び附属書 を,特性の解釈に関する手引書については附属書 を参照)をもたな

ければならない。

−  読みやすく,理解しやすく,テストが可能である。

−  ソフトウェアモジュール設計に関する規定の要求事項を満たす(7.4.5 参照)

−  コーディング基準の規定の要求事項を満たす(7.4.4 参照)

−  安全計画時に規定する全ての関連要求事項を満たす(箇条 参照)

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  この箇条の要求事項を実現するための適切な技法及び手段を選択する場合(附属書 及び附

属書 参照),ソフトウェアモジュールテストについて,次の特性(特性の解釈の手引書は

IEC 61508-7

附属書 を,参考となる定義は附属書 を参照)を検討することが望ましい。

−  ソフトウェア設計仕様に関するテストの完全性

−  ソフトウェア設計仕様に関するテストの正確性(正常完了)


30

C 0508-3

:2014 (IEC 61508-3:2010)

−  再現性

−  正確に定義したテスト構成

7.4.7.1

各ソフトウェアモジュールは,ソフトウェアシステム設計(7.4.5 を参照)時に開発したソフトウ

ェアモジュールテスト仕様で要求しているとおりに,検証しなければならない。

注記  適合確認は,テスト及び解析を含む。

7.4.7.2

この適合確認では,各ソフトウェアモジュールがその想定した機能を実行し,想定外の機能を実

行することがないことを示さなければならない。

注記 1  このことは,全てのインプットの組合せのテストを意味するものではなく,また,全てのア

ウトプットの組合せのテストを意味するものでもない。全ての同値クラスのテスト又は構造

ベーステストで十分なこともある。境界値解析又は制御フロー解析で,テストケースの数を

許容できる数に減らすことができることもある。解析可能なプログラムは,要求事項を満た

しやすくする。これらの技法については,IEC 61508-7 

附属書 を参照。

注記 2  開発に形式手法,形式証明又はアサーションを使用する場合,このようなテストの適用範囲

を縮小することがある。これらの技法については,IEC 61508-7 

附属書 を参照。

注記 3  決定論的安全度は,通常,定量化していないが(JIS C 0508-4 の 3.5.6 参照),統計的に妥当

な証拠に関連する全ての条件を満たしている場合,定量化した統計的証拠(例えば,統計的

テスト,信頼度成長)が受け入れられる。例えば,IEC 61508-7 

附属書 を参照。

注記 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)

しやすくする。これらの技法については,IEC 61508-7 

附属書 を参照。

注記 2  開発に形式手法,形式証明又はアサーションを使用する場合,このようなテストの適用範囲

が縮小することがある。これらの技法については,IEC 61508-7 

附属書 を参照。

注記 3  決定論的安全度は,通常,定量化していないが(JIS C 0508-4 の 3.5.6 参照),統計的に妥当

な証拠に関連する全ての条件を満たしている場合,定量化した統計的証拠(例えば,統計的

検定,信頼性成長)が受け入れられる。例えば,IEC 61508-7 

附属書 を参照。

7.4.8.4

ソフトウェア統合テストの結果は文書化し,テスト結果を記述し,さらに,目的及びテスト基準

が満たしたかどうかを文書化しなければならない。統合テストに不合格の場合は,不合格の理由を文書化

しなければならない。

7.4.8.5

ソフトウェア統合時にソフトウェアに部分改修があれば,その影響解析を行って,影響を受ける

全てのソフトウェアモジュールを判別し,必要な再適合確認及び再設計業務を決定しなければならない。

7.5 

プログラマブル電子装置統合(ハードウェア及びソフトウェア) 

注記  このフェーズは,図 のボックス 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 

要求事項 

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

書 参照),統合について,次の特性(特性の解釈の手引書は IEC 61508-7 の附属書 を,参

考となる定義は

附属書 を参照)を検討することが望ましい。

−  設計仕様に関する統合の完全性

−  設計仕様に関する統合の正確性(正常完了)

−  再現性

−  正確に定義した統合構成

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)

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 

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

注記  このフェーズは,図 のボックス 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  このフェーズは,図 のボックス 10.6 である。

注記 2  ソフトウェアは,通常,その基盤となるハードウェア及びシステム環境から引き離した状態

では妥当性確認することはできない。

7.7.1 

目的 

この箇条の要求事項の目的は,統合したシステムが,要求安全度水準で,ソフトウェア安全要求仕様に

必ず適合するようにすることである。

7.7.2 

要求事項 

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


33

C 0508-3

:2014 (IEC 61508-3:2010)

書 参照),安全妥当性確認について,次の特性(特性の解釈の手引書は IEC 61508-7 の附属書

C

を,参考となる定義は

附属書 を参照)を検討することが望ましい。

−  ソフトウェア設計仕様に関する妥当性確認の完全性

−  ソフトウェア設計仕様に関する妥当性確認の正確性(正常完了)

−  再現性

−  正確に定義した妥当性確認構成

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 の箇条 参照)

7.7.2.4

システム安全のソフトウェアの妥当性確認結果は,文書化しなければならない。

7.7.2.5

ソフトウェア安全妥当性確認では,安全機能別に,次の結果を文書化しなければならない。

a)

業務のシーケンスを遡及できるようにする,妥当性確認業務の経時的記録

注記  テスト結果を記録するときは,業務のシーケンスを遡及できることが重要である。この要求

事項は業務のシーケンスが遡及できるものであることを重視するものであって,文書の時間

及び日付入りの記録を作成することを重視するものではない。

b)

使用するシステム安全のソフトウェアの妥当性確認計画(7.3 参照)のバージョン

c)

(テスト又は解析によって)妥当性確認する安全機能と合わせて,システム安全のソフトウェアの妥

当性確認計画の参照

d)

校正データ,並びに校正に使用するツール及び機器

e)

妥当性確認業務の結果

f)

予想結果と実際の結果との不整合

7.7.2.6

予想結果と実際の結果との不整合が生じた場合,妥当性確認を続けるか,又は変更要請を出して

開発ライフサイクルの前の段階に戻るかどうかに関して行った解析及び決定事項を,システム安全のソフ

トウェア妥当性確認結果の一部として,文書化しなければならない。

注記  7.7.2.27.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)

7.7.2.9

システム安全の安全関連ソフトウェアの妥当性確認結果は,次の要求事項を満たさなければなら

ない。

a)

テストは,規定した安全関連ソフトウェアの全ての要求事項(7.2 参照)を正確に満たし,ソフトウェ

アが想定外の機能を実行することがないことを,示さなければならない。

b)

テストケース及びそれらの結果は,安全度水準が要求する以降の解析及び独立した評価(JIS C 0508-1

の箇条 参照)用に文書化しなければならない。

c)

システム安全のソフトウェアの妥当性確認結果を示す文書には,ソフトウェアが妥当性確認に合格し

たか,又は妥当性確認に不合格となった理由のいずれかを,明記しなければならない。

7.8 

ソフトウェア部分改修 

注記  このフェーズは,図 のボックス 10.5 である。

7.8.1 

目的 

この箇条の要求事項の目的は,要求したソフトウェアの決定論的対応能力を維持することを確認しなが

ら,妥当性確認したソフトウェアに,訂正,改善又は改造を加えることである。

7.8.2 

要求事項 

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

書 参照),ソフトウェア部分改修について,次の特性(特性の解釈の手引書は IEC 61508-7

附属書 を,参考となる定義は附属書 を参照)を検討することが望ましい。

−  要求事項に関する部分改修の完全性

−  要求事項に関する部分改修の正確性

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

−  好ましくない挙動の回避

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

−  リグレッション(回帰)テスト及び適合確認の対象範囲

7.8.2.1

ソフトウェア部分改修を実施する前に,ソフトウェア部分改修手順を用意しておかなければなら

ない(JIS C 0508-1 の 7.16 を参照)

注記 1  7.8.2.17.8.2.9 は,主として,ソフトウェアの運用フェーズ中に起こる変更に適用する。こ

れらの箇条を,プログラマブル電子装置統合及び全般的設置及び引渡しフェーズ中に適用す

ることもある(JIS C 0508-1 の 7.13 を参照)

注記 2  部分改修手順モデルの一例を,JIS C 0508-1 の図 に示す。

7.8.2.2 

部分改修は,安全計画(箇条 参照)時に,規定の手順に従った,正式な部分改修の要請を受け

て初めて開始しなければならない。部分改修の要請の詳細については,次による。

a)

影響を受ける可能性がある潜在危険

b)

部分改修案

c)

部分改修の理由

注記  部分改修の要請は,例えば,次の理由から生じる。

−  機能安全が安全要求仕様の求めているものよりも低い。

−  決定論的原因フォールトが生じている。

−  新しい又は改正した安全規制。

− EUC 又はその使い方に対する部分改修。

−  安全要求事項全般に対する部分改修。


35

C 0508-3

:2014 (IEC 61508-3:2010)

−  運用及び保全性能の解析により,性能が目標を下回っていることを示す。

−  定期的機能安全監査。

7.8.2.3

ソフトウェア部分改修案が E/E/PE 安全関連系の機能安全に及ぼす影響について,次の目的で,

解析を実施しなければならない。

a)

潜在危険及びリスク解析が必要かどうかを判定する。

b)

どのソフトウェア安全ライフサイクルフェーズを繰り返す必要があるかを決定する。

7.8.2.4

7.8.2.3

で得た影響解析結果は,文書化しなければならない。

7.8.2.5 E/E/PE

安全関連系の機能安全に影響を及ぼす全部分改修は,ソフトウェア安全ライフサイクルの

適切なフェーズに戻ることから開始しなければならない。それ以降の全てのフェーズは,この規格の要求

事項に従って,それぞれのフェーズで規定している手順に従って実施しなければならない。安全計画(箇

条 参照)には,それ以降の全ての業務について詳述しなければならない。

注記  完全な潜在危険及びリスク解析を実行しなければならないことがある。その場合,E/E/PE 安全

関連系によって実現している安全機能に現在規定しているものとは異なる安全度水準が必要と

なる可能性がある。

7.8.2.6

安全関連ソフトウェアの部分改修に関する安全計画は,JIS C 0508-1 の箇条 の要求事項を満た

さなければならない。特に,次による。

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)

合)及び 7.5(プログラマブル電子装置統合)にある適合確認のテスト要素について,追加の

要求事項を規定するものではない。これらは,それら自体が適合確認業務だからである。こ

の箇条は,ソフトウェア安全妥当性確認(7.7 参照)に加えて,更に別の適合確認を要求する

ものでもない。この規格でいうソフトウェア妥当性確認とは,安全要求仕様への適合の実証

である。安全要求仕様自体が適切なものであるか否かのチェックは,その分野の専門家が行

う。

注記 2  ソフトウェアアーキテクチャに応じて,適合確認業務の責任は,ソフトウェアの開発及び部

分改修に関わる全ての組織間で分担してもよい。

7.9.2 

要求事項 

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

書 参照),データ適合確認について,次の特性(特性の解釈の手引書は IEC 61508-7 の附属書

C

を,参考となる定義は

附属書 を参照)を検討することが望ましい。

−  事前のフェーズに関する適合確認の完全性

−  事前のフェーズに関する適合確認の正確性(正常完了)

−  再現性

−  正確に定義した適合確認構成

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)

ンプット,設計規格,コーディング基準,使用ツールなどであるが,これだけに限らない。

c)

不適合がある場合,その情報

注記 2  不適合の例としては,問題への対応が貧弱な,ソフトウェアモジュール,データ構成,ア

ルゴリズムなどが挙げられる。

7.9.2.6

次のフェーズ N+1 を正しく実行するために必要なソフトウェア安全ライフサイクルのフェーズ

N

から,全ての必須情報が得られなければならず,またその情報は検証しなければならない。フェーズ N

からの引渡し事項は,次のものを含む。

a)

次の事項に関する,フェーズ N の仕様,設計又はコードの妥当性

1)

機能性

2)

安全度,性能,安全計画のその他の要求事項(箇条 参照)

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.87.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)

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)

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)

1)

故障検出

2)

破壊に対する防護

3)

データ妥当性確認

7.9.2.14

タイミング性能の適合確認  時間域の挙動の予測可能性は検証しなければならない。

注記  タイミング挙動とは,性能,リソース,応答時間,ワーストケース実行時間,スラッシング,

デッドロックフリー,ランタイムシステムなどである。

機能安全評価 

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

書 参照),機能安全評価について,次の特性(特性の解釈の手引書は IEC 61508-7 の附属書 C

を,参考となる定義は

附属書 を参照。)を検討することが望ましい。

−  この規格に関する機能安全評価の完全性

−  設計仕様に関する機能安全評価の正確性(正常完了)

−  特定した全ての問題の追跡可能な状態での終結

−  変更後に評価を広範に手直しする必要なく機能安全評価を修正する能力

−  再現性

−  適時性

−  正確に定義した構成

8.1

JIS C 0508-1

の箇条 の目的及び要求事項は,安全関連ソフトウェアの評価に適用する。

8.2

適用分野の規格に特に規定のない限り,機能安全評価の実施担当者の最低限の独立性レベルは,JIS 

C 0508-1

の箇条 に規定しているとおりでなければならない。

8.3

機能安全の評価は,

表 A.10 の業務結果を利用してよい。

注記  附属書 及び附属書 から技法を選択しても,それだけで,要求する安全度の達成を保証する

わけではない(7.1.2.7 参照)

。アセッサは,次の事項も検討することが望ましい。

−  全体の開発サイクル用に選択した方法,言語及びツールの整合性及び相補的性質。

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

−  方法,言語及びツールが開発中に遭遇する個々の問題に十分に対応するものであるかどう

か。


41

C 0508-3

:2014 (IEC 61508-3:2010)

附属書 A

(規定)

技法及び手段の選択の手引書

この附属書の表は,本体の幾つかの箇条に対応している。例えば,7.2(ソフトウェア安全要求仕様)は

表 A.1 に対応する。詳細を記載した附属書 の表は,附属書 の表の記入事項の幾つかを詳述したもので

ある。例えば,

表 B.2 は,表 A.5 の動的解析及びテストについて詳述したものである。附属書 及び附属

書 に示す個々の技法及び手段の概要については,IEC 61508-7 を参照。表に示す各技法又は手段につい

ては,安全度水準(SIL)1∼4 に対する推奨となる。これらの推奨事項は,次とする。

HR

この安全度水準には,技法又は手段を使用することを強く推奨する。この技
法又は手段を使用しない場合は,使用しない理論的根拠について,

附属書 C

を参照して安全計画時に詳述しなければならず,またアセッサと合意しなけ

ればならない。

R

この安全度水準には,HR 推奨より低い推奨事項としての技法又は手段が望ま

しい。

---

技法又は手段を使用することに関しては,推奨も反対もしない。

NR

この安全度水準には,技法又は手段を使用することを積極的には推奨しない。

この技法又は手段を使用する場合は,使用する理論的根拠について,

附属書

C

を参照して安全計画時に詳述しなければならず,またアセッサと合意する

ことが望ましい。

安全度水準に従って,

適切な技法及び手段を選択しなければならない。

代替又は等価の技法及び手段は,

数字の後に 1 文字を付けて示す。代替又は等価の技法及び手段の一つだけを満たさなければならない。

要求事項及び目的を満たしていれば,これ以外の技法及び手段を採用してもよい。技法の選択の手引書

については,

附属書 を参照。

技法及び手段のランク付けは,JIS C 0508-2 で使用している有効性の概念に関連している。この他の要

因が同等であるならば,HR としてランク付けする技法は,ソフトウェア開発中に決定論的原因フォール

トの侵入防止の点で,又は(ソフトウェアアーキテクチャの場合に)実行中に明らかになるソフトウェア

の残存フォールトの管理の点で,R としてランク付けした技法よりも有効である。

ソフトウェアの決定論的対応能力に影響する要因が多数ある場合は,全てのアプリケーションに対して

正しい技法と手段とを組み合わせるためのアルゴリズムを導出することは不可能である。ソフトウェアの

決定論的対応能力を達成するための,特定の技法を選択する理由に関する手引書を,

附属書 に示す。

特定のアプリケーションで,適切な技法又は手段の組合せは,表の注に他の要求事項を記載していない

限り,選択した適切な技法又は手段を安全計画時に決めなければならない。

表の解釈について,二つの実例の形式をとった最初の手引書を IEC 61508-6 に記載している。


42

C 0508-3

:2014 (IEC 61508-3:2010)

表 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 

附属書 及び附属書 に記載してあることを示す。

a)

安全度水準に従って,適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手

段は,数字の後に 1 文字を付けて示す。代替又は等価の技法及び手段は,一つだけを満たすことを
意図している。代替技法を選択するときは,特定のアプリケーションにとって望ましい

附属書 C

に示す特性に従って,その正当な根拠を示すことが望ましい。


43

C 0508-3

:2014 (IEC 61508-3:2010)

表 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)

表 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

附属書 及び附属書 に記載してあることを示す。

a)

安全度水準に従って,適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は,数

字の後に 1 文字を付けて示す。代替又は等価の技法及び手段は,一つだけを満たすことを意図している。代

替技法を選択するときは,特定のアプリケーションにとって

附属書 に示す望ましい特性に従って,その正

当な根拠を示すことが望ましい。

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 の附属

書 に記載してあることを示す。

a)

安全度水準に従って,適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は,数
字の後に 1 文字を付けて示す。代替又は等価の技法及び手段は,一つだけを満たすことを意図している。代

替技法を選択するときは,特定のアプリケーションにとって

附属書 に示す望ましい特性に従って,その正

当な根拠を示すことが望ましい。


45

C 0508-3

:2014 (IEC 61508-3:2010)

表 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 

附属書 を参照。

注記 3  3 列目の参照先(これは規定ではなく参考)

“B.x.x”

“C.x.x”は,技法及び手段の詳細な説明が IEC 61508-7

附属書 及び附属書 に記載してあることを示す。

a)

安全度水準に従って,適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は,数

字の後に 1 文字を付けて示す。代替又は等価の技法及び手段は,一つだけを満たすことを想定している。代

替技法を選択するときは,特定のアプリケーションにとって

附属書 に示す望ましい特性に従って,その正

当な根拠を示すことが望ましい。

b)

グループ 1,

“構造化手法”

。手段 1a は,1b が SIL 3 及び/又は SIL 4 の領域に適していないときだけに使用

する。


46

C 0508-3

:2014 (IEC 61508-3:2010)

表 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

附属書 及び附属書 に記載してあることを示す。

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

附属書 及び附属書 に記載してあることを示す。

a)

安全度水準に従って,適切な技法及び手段を選択しなければならない。


47

C 0508-3

:2014 (IEC 61508-3:2010)

表 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

附属書 及び附属書 に記載してあることを示す。

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 の附属

書 に記載してあることを示す。

a)

安全度水準に従って,適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は,数

字の後に 1 文字を付けて示す。代替又は等価の技法及び手段は,一つだけを満たすことを意図している。代

替技法を選択するときは,特定のアプリケーションにとって

附属書 に示す望ましい特性に従って,その正

当な根拠を示すことが望ましい。


48

C 0508-3

:2014 (IEC 61508-3:2010)

表 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-1JIS C 0508-2 及び JIS C 0508-3 の境界にまたがる。したがって,安全関連系の

最初の適合確認は,それ以前のシステムレベル仕様に対するものである。

注記 3  ソフトウェア安全ライフサイクルの早期のフェーズにおける適合確認,例えば,検査,見直し,形式的証

明は静的である。コードを作成すると,動的テストが可能となる。適合確認に必要となるのは,これら 2
種類の情報の組合せである。例えば,静的手段によるソフトウェアモジュールのコード適合確認には,ソ

フトウェア検査,ウォークスルー,静的解析,形式的証明などの技法が含まれる。動的手段によるコード

適合確認には,機能テスト,ホワイトボックステスト,統計的テストなどがある。各ソフトウェアモジュ
ールが関連仕様を満たしていることを保証するのは,これら 2 種類の証拠の組合せである。

注記 4  表 C.9 を参照。 
注記 5  3 列目の参照先(これは規定ではなく参考)

“B.x.x”

“C.x.x”は,技法及び手段の詳細な説明が IEC 61508-7

附属書 及び附属書 に記載してあることを示す。

a)

安全度水準に従って,適切な技法及び手段を選択しなければならない。


49

C 0508-3

:2014 (IEC 61508-3:2010)

表 A.10−機能安全評価(箇条 参照) 

評価/技法

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

箇条 の要求事項とソフトウェア機能安全評価計画

との間の前方トレーサビリティ

IEC 61508-7

C.2.11 

R R HR

HR

注記 1  表 C.10 を参照。 
注記 2  3 列目の参照先(これは規定ではなく参考)

“B.x.x”

“C.x.x”は,技法及び手段の詳細な説明が IEC 61508-7

附属書 及び附属書 に記載してあることを示す。

a)

安全度水準に従って,適切な技法及び手段を選択しなければならない。


50

C 0508-3

:2014 (IEC 61508-3:2010)

附属書 B

(参考)

詳細表

附属書 で用いる関連表を,表 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 の附

属書 に記載してあることを示す。

a)

安全度水準に従って,適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は,数
字の後に 1 文字を付けて示す。代替又は等価の技法及び手段は,一つだけを満たすことを意図している。代

替技法を選択するときは,特定のアプリケーションにとって

附属書 に示す望ましい特性に従って,その正

当な根拠を示すことが望ましい。


51

C 0508-3

:2014 (IEC 61508-3:2010)

表 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 の附属

書 に記載してあることを示す。

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

附属書 及び附属書 に記載してあることを示す。

a)

安全度水準に従って,適切な技法及び手段を選択しなければならない。


52

C 0508-3

:2014 (IEC 61508-3:2010)

表 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 の附

属書 に記載してあることを示す。

a)

安全度水準に従って,適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は,数
字の後に 1 文字を付けて示す。代替又は等価の技法及び手段は,一つだけを満たすことを意図している。代

替技法を選択するときは,特定のアプリケーションにとって

附属書 に示す望ましい特性に従って,その正

当な根拠を示すことが望ましい。

表 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

附属書 及び附属書 に記載してあることを示す。

a)

安全度水準に従って,適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は,数

字の後に 1 文字を付けて示す。代替又は等価の技法及び手段は,一つだけを満たすことを意図している。代
替技法を選択するときは特定のアプリケーションにとって,

附属書 に示す望ましい特性に従って,その正

当な根拠を示すことが望ましい。


53

C 0508-3

:2014 (IEC 61508-3:2010)

表 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 の附属

書 に記載してあることを示す。

a)

安全度水準に従って,適切な技法及び手段を選択しなければならない。

表 B.7−準形式手法(表 A.1,表 A.2 及び表 A.4 の関連表) 

技法及び手段

a)

参照先

SIL 1

SIL 2

SIL 3

SIL 4

1

論理及び機能ブロック図

注記 を参照 R  R HR HR

2

シーケンス図

注記 を参照 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

附属書 及び附属書 に記載してあることを示す。

a)

安全度水準に従って,適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は,数
字の後に 1 文字を付けて示す。代替又は等価の技法及び手段は,一つだけを満たすことを意図している。代

替技法を選択するときは,特定のアプリケーションにとって

附属書 に示す望ましい特性に従って,その正

当な根拠を示すことが望ましい。


54

C 0508-3

:2014 (IEC 61508-3:2010)

表 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

附属書 及び附属書 に記載してあることを示す。

a)

安全度水準に従って,適切な技法及び手段を選択しなければならない。代替又は等価の技法及び手段は,数
字の後に 1 文字を付けて示す。代替又は等価の技法及び手段は,一つだけを満たすことを意図している。代

替技法を選択するときは,特定のアプリケーションにとって

附属書 に示す望ましい特性に従って,その正

当な根拠を示すことが望ましい。

表 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 の附属

書 に記載してあることを示す。

a)

安全度水準に従って,適切な技法及び手段を選択しなければならない。一つの技法で十分であることは,ま

ずない。適切な技法全てを検討しなければならない。


55

C 0508-3

:2014 (IEC 61508-3:2010)

附属書 C 
(参考)

ソフトウェア決定論的対応能力の特性

C.1 

序文 

ソフトウェア決定論的対応能力に影響する要因は多数あることから,どのようなアプリケーションにと

っても正しくなる技法と手段とを組み合わせたアルゴリズムを示すことは,不可能である。

附属書 の目

的は,次のとおりである。

附属書 及び附属書 から具体的な技法を選択するための手引書を示して,ソフトウェア決定論的対

応能力を達成する。

附属書 及び附属書 に明示的に記載していない技法を使用し,正当な論理的根拠を概説する。

附属書 は,附属書 及び附属書 の表を補完する。

C.1.1 

附属書 及び附属書 に関係する附属書 の構成 

ソフトウェア安全ライフサイクルの各フェーズの引渡し事項を,次に示す各表の形式で定義する。例え

ば,ソフトウェア安全要求仕様を検討してみる。

表 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 

附属書 に定義している。)によって特徴づけ

られる。

特性

ソ フ ト ウ ェ ア で

対 応 す る 安 全 ニ

ーズの完全性

ソ フ ト ウ ェ ア で

対 応 す る 安 全 ニ

ーズの正確性

曖 昧 さ の 回 避 を

含む,固有仕様フ

ォ ー ル ト の 回 避

安 全 要 求 事 項 の

理解容易性

ソ フ ト ウ ェ ア の

安 全 以 外 の 機 能

が 安 全 機 能 へ 危
険 な 干 渉 を 及 ぼ

さない性質

適 合 確 認 及 び 妥

当 性 確 認 の 基 礎

となる対応能力

表 C.1 は,これらの望ましい特性を達成する具体的な技法の有効性を,非公式ではあるが次の表の尺度

R1

,R2 及び R3 でランク付けている。


56

C 0508-3

:2014 (IEC 61508-3:2010)

技法及び手段

特性

ソフトウェア

で対応する安
全ニーズの完

全性

ソフトウェア

で対応する安
全ニーズの正

確性

曖昧さの回避

を含む,固有
仕様フォール

トの回避性

安全要求事項

の理解容易性

ソフトウェア

の安全以外の
機能が安全機

能へ危険な干

渉を及ぼさな
い性質

適合確認及び

妥当性確認の
基礎となる対

応能力

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)

次表の例では,準形式手法は,正確な表現を改善する制限した表記法を規定することで厳密さ R1 を達

成し,混乱の原因になるおそれのある仕様の複雑さを,更に制限することで R2 を達成する。

技法及び手段

特性

ソフトウェア
で対応する安

全ニーズの完

全性

ソフトウェア
で対応する安

全ニーズの正

確性

曖昧さの回避
を含む,固有

仕様フォール

トの回避性

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

ソフトウェア
の安全以外の

機能が安全機

能へ危険な干
渉を及ぼさな

い性質

適合確認及び
妥当性確認の

基礎となる対

応能力

1a

準形式手法

− R1

誤解する機会
を制限する定

義した表記法

R2

仕様に複雑さ

の制限を適用

C.1.2 

使用方法−

手引書としては,ソフトウェア安全要求仕様の開発に当たって望ましい特性を達成したと納得できるよ

うに実証することができれば,ソフトウェア安全要求仕様が,十分な決定論的安全度をもつソフトウェア

を開発するための適切な根拠であると裏づけられる。

表 C.1 は,表 A.1 の各技法が,多かれ少なかれ,ソフトウェア安全要求仕様に関係する一つ以上の特性

を達成していることを,一般に示している。

ただし,

表 A.1 は具体的な技法を推奨しているが,これらの推奨は規定ではなく,附属書 は,“ソフ

トウェアの決定論的対応能力に影響する要因が多数あることからすれば,任意のアプリケーションで正し

い技法と手段を組み合わせたアルゴリズムを決めることは不可能である”と明言していることに留意する

ことが重要である。

実際に,ソフトウェア安全要求仕様を開発するときに用いる技法を,その技法固有の能力に加えて,い

つくかの実際的な制約(7.1.2.7 参照)を受けながら選択する。そうした制約とは,次のようなものである。

−  全開発サイクルで選択する方法,言語及びツールの一貫性並びに相補的な性質。

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

−  方法,言語及びツールが,開発中に遭遇する具体的な問題に十分に適合しているか否か。

表 C.1 は,ソフトウェア安全要求仕様ライフサイクルの望ましい特性を,特定の開発プロジェクトの実

際的な制約を同時に考慮しながら達成するときに用いる,

表 A.1 の具体的な技法の相対的有効性の比較に

用いてもよい。

例えば,形式手法は,適合確認及び妥当性確認に関して準形式手法(R2)よりも,よりよい基礎(R3)

となることができるが,他のプロジェクトの制約(例えば,高度なコンピュータ支援ツールの可用性又は

形式表記法の極めて専門的な表現力)が準形式アプローチのほうを望ましいとすることがある。

このようにして,

表 C.1 の望ましい特性は,ソフトウェア安全要求仕様開発用として表 A.1 の推奨する

代替技法の妥当で,実際的な比較の基礎となることができる。より一般的な言い方をすれば,特定のライ

フサイクルフェーズ用に

附属書 の推奨する複数の代替技法の中から理路整然とした選択を行うときは,


58

C 0508-3

:2014 (IEC 61508-3:2010)

対応する

附属書 の表に記載した望ましい特性を検討すればよいということになる。

しかし,決定論的な挙動の性質のために,

附属書 の特性は,最も高い厳密さで達成又は実証すること

ができないことがある点に注意しなければならない。その特性は,どちらかといえば,目指さなければな

らない目標である。その達成は,例えば,防御的設計と単純さなど,様々な特性間の二律背反を余儀なく

することもある。

最後に,手引用として,R1/R2/R3 基準の定義に加えて,厳密さの水準が R1 から R3 に向かって上がる

ことと,ソフトウェアの正確性に関する信頼性の向上との間に,非公式のリンクを設けておくと役立つ。

附属書 が対応する SIL(安全度水準)を要求しているときは,一般的な,非公式の推奨として,次の最

低限の厳密さの水準を目標とすることが望ましい。

安全度水準

(SIL)

厳密さ R

1

及び 2 R1

3 R2

,使用できる場合

4

使用可能な最高の厳密さ

C.1.3 

使用方法−

附属書 は具体的な技法を推奨しているが,ライフサイクルフェーズの要求事項及び目的を満たしてい

れば,別の手段及び技法の適用も許す。

既に指摘したように,決定論的対応能力に影響する要因は多数あり,どのような所定のアプリケーショ

ンでも望ましい特性を達成するように,技法を選択し,組み合わせるためのアルゴリズムを示すことは不

可能である。

望ましい特性を達成するための有効な方法は複数ある場合もあるので,システム開発者が代わりとなる

証拠を提示できる可能性があることを認識することが望ましい。

附属書 の表に盛り込んだ情報は,附属

書 の表に示したもの以外の技法の選択を正当化するための理路整然とした主張の基礎として使用するこ

とができる。

C.2 

決定論的安全度に関する特性 

表 C.1∼表 C.19,及び IEC 61508-7 に示す手引書きは,決定論的安全度特性を達成し,説得力のある証

拠を生成するための具体的な技法を示している。ある方法が特性の達成に寄与しない場合は,次表にダッ

シュを記入して,それを示す。ある方法が,幾つかの特性には悪影響を及ぼし,他の特性には好影響を及

ぼす場合は,以下の関連する表に注記を付けて示す。


59

C 0508-3

:2014 (IEC 61508-3:2010)

表 C.1−決定論的安全度に関する特性−ソフトウェア安全要求仕様(7.2 参照。表 A.1 の関連表) 

技法及び手段

特性

ソフトウェアで対応す

る安全ニーズの完全性

ソフトウェアで対応す

る安全ニーズの正確性

曖昧さの回避を含む,

固有仕様フォールトの

回避性

安全要求事項の理解容

易性

ソフトウェアの安全以

外の機能が安全機能へ

危険な干渉を及ぼさな

い性質

適合確認及び妥当性確

認の基礎となる対応能

1a

準形式手法 R1

特定分野の専門家が用

いる,アプリケーショ
ンフレンドリ又はその

分野固有の仕様規定手

法及び表記法

R1

特定分野の専門家が用

いる,アプリケーショ
ンフレンドリ又はその

分野固有の仕様規定手

法及び表記法

R2

カバレッジ基準に準拠 
した仕様の適合確認

R1

内部の不整合,動作の

未記述又は数学的に不
整合な表現の回避又は

検出を助ける手法及び

表記法

R2

カバレッジ基準に準拠
した仕様の適合確認

R3

系統的な分析,及び/

又は,内在するある種

の仕様フォールトの体
系的な回避に基づく仕

様の適合確認

R1

誤解を与えにくい表記

法の定義又は誤解しに
くい表記法の定義

R2

仕様の複雑さに制限を

適用

− R2

仕様の曖昧さを少なく

する表記法の定義

59

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


60

C 0508-3

:2014 (IEC 61508-3:2010)

表 C.1−決定論的安全度に関する特性−ソフトウェア安全要求仕様(7.2 参照。表 A.1 の関連表)(続き) 

技法及び手段

特性

ソフトウェアで対応す

る安全ニーズの完全性

ソフトウェアで対応す

る安全ニーズの正確性

曖昧さの回避を含む,

固有仕様フォールトの

回避性

安全要求事項の理解容

易性

ソフトウェアの安全以

外の機能が安全機能へ

危険な干渉を及ぼさな

い性質

適合確認及び妥当性確

認の基礎となる対応能

1b

形式手法 R1

特定分野の専門家が用

いる,アプリケーショ
ンフレンドリ又はその

分野固有の仕様規定手

法及び表記法

R1

特定分野の専門家が用

いる,アプリケーショ
ンフレンドリ又はその

分野固有の仕様規定手

法及び表記法

R2

カバレッジ基準に準拠
した仕様の適合確認

R3

挙動の限定的側面での

正確性の保証

R1

内部の不整合,動作の

未記述又は数学的に不
整合な表現の回避又は

検出を助ける手法及び

表記法

R2

カバレッジ基準に準拠
した

仕様の適合確認

R3

決定論的分析及び/又

は本質的な仕様フォー
ルトの特定種類の決定

論的アボイダンスに基

づく仕様の適合確認

注記:手法がアプリケ
ーションフレンドリで
もなく,特定分野専用

の も の で も な い 場 合

は,この特性の達成が
困難となってもよい。

− R3

仕様の曖昧さを少なく

する

2

システ ム安全 要

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

仕様と の前方 ト

レーサビリティ

R1

ソフトウェア安全要求
仕様がシステム安全要

求仕様に対応するとい

う確信性

3

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

知した 安全ニ ー

ズ間と の後方 ト
レーサビリティ

− R1

ソフトウェア安全要求

仕様に不要な複雑さが

含まれていないという
確信性

− R1

被制御機器の安全要求

へのトレーサビリティ

は分かりやすさを高め

R1 R1

60

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


61

C 0508-3

:2014 (IEC 61508-3:2010)

表 C.1−決定論的安全度に関する特性−ソフトウェア安全要求仕様(7.2 参照。表 A.1 の関連表)(続き) 

技法及び手段

特性

ソフトウェアで対応す

る安全ニーズの完全性

ソフトウェアで対応す

る安全ニーズの正確性

曖昧さの回避を含む,

固有仕様フォールトの

回避性

安全要求事項の理解容

易性

ソフトウェアの安全以

外の機能が安全機能へ

危険な干渉を及ぼさな

い性質

適合確認及び妥当性確

認の基礎となる対応能

4

上記の 技法及 び

手段を 支援す る

適切な コンピ ュ
ータ支 援仕様 書

作成ツール

R1

被制御機器及びソフト

ウェア環境に関する特
定分野の知識のカプセ

ル化

R2

考慮しなければならな

い問題点のチェックリ
ストを定義し,その正

当な根拠を示し,かつ,

それを確認している場

R1

機能シミュレーション

技法

R2

定義し,正当な根拠を
示しているカバレッジ

基準に準拠した機能シ

ミュレーション

R2

関連する規則が守られ

ていることを確認する
ための意味及び構文の

チェック

R1

仕様のアニメーション

又はブラウジング

R1

安全機能及び安全以外

の機能の特定

R1

トレーサビリティ及び

カバレッジの支援

R2

トレーサビリティ及び
カバレッジの測定

61

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


62

C 0508-3

:2014 (IEC 61508-3:2010)

表 C.2−決定論的安全度に関する特性−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計(7.4.3 参照。表 A.2 の関連表) 

技法及び手段

特性

ソフトウェア安

全要求仕様の完

全性

ソフトウェア安

全要求仕様の正

確性

固有設計フォー

ルトの回避性

単純さ及び理解

容易性

挙動の予測可能

検証及びテスト

可能な設計

フォールトトレ

ランス

外部事象による

共通原因故障に

対する防護

1

フォールト検出

この特性の達成

が困難になって

もよい

R1

論理的プログラ

ムフロー監視で

予測可能性に備
える

− R1

( カ バ レ ッ ジ 目

標を定義し,そ

の正当な根拠を
示し,その目標

を満たしている

場合は R2)

R1

又は−

2

エラー検出コ ー

この特性の達成
が困難になって

もよい

この特性の達成
が困難になって

もよい

− R1

( カ バ レ ッ ジ 目

標を定義し,そ

の正当な根拠を

示し,その目標
を満たしている

場合は R2)

デ ー タ 通 信 な

ど,具体的なア

プリケーション
領域に有効

R1

デ ー タ 通 信 な
ど,具体的なア

プリケーション

領域に有効

3a

故障アサーシ ョ

ンプログラミ ン

− R2

ポストアサーシ

ョンが詳細要求
仕様への適合性

をチェックして

もよい

− R2

プリアサーショ

ンがインプット
範囲を制限する

R2

ポストアサーシ

ョンによる期待
及び受容アウト

プットのチェッ

R2

プリアサーショ

ンがインプット
範囲を制限し,

したがって要求

するテスト範囲
を制限する

R3

目標とする故障

に有効

R3

目標とする故障

に有効

62

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


63

C 0508-3

:2014 (IEC 61508-3:2010)

表 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

カバレッジ目標を

定義し,その正当
な根拠を示し,そ

の目標を満たして

いる場合

要求仕様のフォー

ルトに対して防護
しない

63

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


64

C 0508-3

:2014 (IEC 61508-3:2010)

表 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

自己回復のため

の 目 標 を 定 義

し,その正当な
根拠を示し,そ

の目標を満たし

ている場合

64

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


65

C 0508-3

:2014 (IEC 61508-3:2010)

表 C.2−決定論的安全度に関する特性−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計(7.4.3 参照。表 A.2 の関連表)(続き) 

技法及び手段

特性

ソフトウェア安

全要求仕様の完

全性

ソフトウェア安

全要求仕様の正

確性

固有設計フォー

ルトの回避性

単純さ及び理解

容易性

挙動の予測可能

検証及びテスト

可能な設計

フォールトトレ

ランス

外部事象による

共通原因故障に

対する防護

4a

再試行フォー ル
ト回復メカニ ズ

この特性の達成
が困難になって

もよい

− R1

( カ バ レ ッ ジ 目

標を定義し,そ

の正当な根拠を
示し,その目標

を満たしている

場合は R2)

R1

( カ バ レ ッ ジ 目

標を定義し,そ

の正当な根拠を
示し,その目標

を満たしている

場合は R2)

4b

グレースフル デ

グラデーション

注記:この特性
の達成が困難に

なってもよい

− R1

カバレッジ目標
を定義し,その

正当な根拠を示

し,その目標を
満たしている場

合は R2

R1

カバレッジ目標
を定義し,その

正当な根拠を示

し,その目標を
満たしている場

合は R2

5

人工知能−フ ォ

ールト修正

注記:この特性
の達成が困難に

なってもよい

注記:この特性
の達成が困難に

なってもよい

注記:この特性
の達成が困難に

なってもよい

注記:この特性
の達成が困難に

なってもよい

注記:この特性
の達成が困難に

なってもよい

6

動的再構成

注記:この特性
の達成が困難に
なってもよい

注記:この特性
の達成が困難に
なってもよい

注記:この特性
の達成が困難に
なってもよい

注記:この特性
の達成が困難に
なってもよい

注記:この特性
の達成が困難に
なってもよい

65

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


66

C 0508-3

:2014 (IEC 61508-3:2010)

表 C.2−決定論的安全度に関する特性−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計(7.4.3 参照。表 A.2 の関連表)(続き) 

技法及び手段

特性

ソフトウェア安

全要求仕様の完

全性

ソフトウェア安

全要求仕様の正

確性

固有設計フォー

ルトの回避性

単純さ及び理解

容易性

挙動の予測可能

検証及びテスト

可能な設計

フォールトトレ

ランス

外部事象による

共通原因故障に

対する防護

7

モジュラー・アプ
ローチ

− R1

R2

モジュール化の
目標を定義し,

その正当な根拠

を示し,その目
標を満たしてい

れば,R2 を達成

する。それ以外
は,R1 だけ達成

する

R1

特定の種類の本

質的設計フォー

ルトの回避が,
モジュール毎に

独立に検証でき

る場合

R3

特定の種類の本
質的設計フォー

ルトの回避が,

モジュール設計
に基づく厳密な

論拠によって裏

づけることがで
きる場合

R1

R2

モジュール化目
標を定義し,そ

の正当な根拠を

示し,その目標
を満たしている

場合

R1

R2

モジュール化目
標を定義し,そ

の正当な根拠を

示し,その目標
を満たしている

場合

R1

R2

モジュール化目
標を定義し,そ

の正当な根拠を

示し,その目標
を満たしている

場合

R1

一つのモジュー

ルの故障に影響

を受けないモジ
ュールが,低減

/回復に貢献し

ている場合

R3

特定の故障に対
するトレランス

が厳密な推論に

よって裏づける
ことができる場

R1

複数のチャネル

に同時に影響を

及ぼす可能性の
ある外部事象に

影響を受けるお

それのあるモジ
ュ ー ル を 特 定

し,徹底的な適

合確認を受ける
場合

R3

特定の外部事象

に対する許容性

を,厳密な推論
によって裏づけ

ることができる

場合

66

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


67

C 0508-3

:2014 (IEC 61508-3:2010)

表 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

(構造化設計は,

適合確認及びテ

ス ト が し や す

い)

67

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


68

C 0508-3

:2014 (IEC 61508-3:2010)

表 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

フォールトトレ

ランス能力を自

動的に生成する
場合

68

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


69

C 0508-3

:2014 (IEC 61508-3:2010)

表 C.2−決定論的安全度に関する特性−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計(7.4.3 参照。表 A.2 の関連表)(続き) 

技法及び手段

特性

ソフトウェア安

全要求仕様の完

全性

ソフトウェア安

全要求仕様の正

確性

固有設計フォー

ルトの回避性

単純さ及び理解

容易性

挙動の予測可能

検証及びテスト

可能な設計

フォールトトレ

ランス

外部事象による

共通原因故障に

対する防護

12

コンピュータ支
援設計ツール,

及びコンピュー

タ支援仕様書作
成ツール

R1

被制御機器及び

ソフトウェア環

境に関する特定
分野の知識のカ

プセル化

R2

考慮すべき問題

点のチェックリ
ストを定義し,

その正当な根拠

を示し,それが
取り上げられて

いる場合

R1

後方要求仕様ト

レーサビリティ

の強制

機能シミュレー

ション技法

R2

定義し,正当な
根拠を示してい

るカバレッジ基

準に準拠した機
能シミュレーシ

ョン

R2

関連する規則を

守っていること

を確認するため
の意味及び構文

のチェック

R1

アニメーション

及びブラウジン

− R2

関連する規則を

が守っているこ

とを確認するた
めの意味及び構

文のチェック

13a

最大周期を保証

した周期的挙動

仕様のタイミン

グ面に関しては

R1

R3

厳密な推論が最
大サイクル時間

を定めている場

仕様のタイミン

グ面に関しては

R1

R3

厳密な推論が最
大サイクル時間

を定めている場

仕様のタイミン

グ面に関しては

R1

R3

厳密な推論が最
大サイクル時間

を定めている場

仕様のタイミン

グ面に関しては

R1

R3

厳密な推論が最
大サイクル時間

を定めている場

69

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


70

C 0508-3

:2014 (IEC 61508-3:2010)

表 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

70

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


71

C 0508-3

:2014 (IEC 61508-3:2010)

表 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

承諾者妥当性確認スイートなど,

ツール性能に関して客観的な妥当

性確認の証拠がある場合

71

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


72

C 0508-3

:2014 (IEC 61508-3:2010)

表 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 −

72

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


73

C 0508-3

:2014 (IEC 61508-3:2010)

表 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

設計がソフトウ

ェア安全要求事
項に対応してい

るという確信性

73

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


74

C 0508-3

:2014 (IEC 61508-3:2010)

表 C.5−決定論的安全度に関する特性−ソフトウェア設計及び開発−ソフトウェアモジュールテスト及び統合 

7.4.77.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

を自動実行する場合,テスト

構成を正確に定義しなければなら
ない。生成するテストの実行はブラ

ックボックステストに類似してお

り,ソースコードレベルのカバレッ
ジ測定と組み合わせられる可能性

がある

74

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


75

C 0508-3

:2014 (IEC 61508-3:2010)

表 C.5−決定論的安全度に関する特性−ソフトウェア設計及び開発−ソフトウェアモジュールテスト及び統合 

7.4.77.4.8 参照,表 A.5 の関連表)(続き) 

技法及び手段

特性

ソフトウェア設計仕様に関するテ

スト及び統合の完全性

ソフトウェア設計仕様に関するテス

ト及び統合の正確性(正常完了)

再現性

正確に定義したテスト構成

7

イ ン タ フ ェ ー

ステスト

− R1

(必要なアウトプットを定義し,その

正当な根拠を示し,それを満たしてい
る場合は R2)

8

テ ス ト 管 理 及
び 自 動 化 ツ ー

R1

(テストカバレッジ目標を定義し,

その正当な根拠を示し,それを満た

している場合は R2)

− R1

自動化で整合性が増す

R2

テストの再現性が得られる

9

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

と モ ジ ュ ー ル

統 合 テ ス ト 仕
様 と の 間 の 前

方 ト レ ー サ ビ

リティ

R1

テスト仕様がソフトウェア安全要

求事項に対応しているという信頼

− R2

テスト時の要求事項の明確な基準

の信頼性

10

形 式 的 適 合 確

R3

厳密な推論をテストケースの構築
に適用し,設計の全側面が動作した

ことを明示する場合

R3

全てのソフトウェア要求事項を満た
しているという客観的な証拠を出す

R1

支援ツールがない場合

R2

ツールの支援がある場合

75

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


76

C 0508-3

:2014 (IEC 61508-3:2010)

表 C.6−決定論的安全度に関する特性−プログラマブル電子装置の統合(ハードウェア及びソフトウェア) 

7.5 参照,表 A.6 の関連表) 

技法及び手段

特性

設計仕様に関する統合の完全性

設計仕様に関する統合の正確性

(正常完了)

再現性

正確に定義した統合構

1

機能及び

ブラックボックステスト

R1

(稼働プロファイルのカバレッジ目標を定義

し,その正当な根拠を示して,それを満たし
ている場合は R2)

R1

(必要なアウトプットを定義し,その

正当な根拠を示して,それを満たして
いる場合は R2)

2

性能テスト

− R1

(必要なアウトプットを定義し,その

正当な根拠を示して,それを満たして

いる場合は R2)

3

ハードウェア及びソフトウェ
ア統合に関するシステム,並び

にソフトウェア設計要求事項

とハードウェア及びソフトウ
ェア統合テスト仕様との間の

前方トレーサビリティ

R1

ハードウェア及びソフトウェア統合テスト仕

様が統合要求事項に対応しているという確信

− R2

テスト時の要求事項の

明確な基準の信頼性

76

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


77

C 0508-3

:2014 (IEC 61508-3:2010)

表 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

テスト時の要求事項の明

確な基準の信頼性

77

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


78

C 0508-3

:2014 (IEC 61508-3:2010)

表 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

ソフトウェア部分改

修計画(再適合確認
及び再妥当性確認を

含む)が不要な複雑

さを含んでいないと
いう確信性

78

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


79

C 0508-3

:2014 (IEC 61508-3:2010)

表 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)

79

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


80

C 0508-3

:2014 (IEC 61508-3:2010)

表 C.10−決定論的安全度に関する特性−機能安全評価(箇条 参照。表 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

この規格の箇条 の要

求事項と,ソフトウェ
ア機能安全評価計画と

の間の,前方トレーサ

ビリティ

R1

ソフトウェア機能安
全評価計画がこの規

格の箇条 の要求事

項に対応していると
いう確信性

80

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


81

C 0508-3

:2014 (IEC 61508-3:2010)

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

81

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


82

C 0508-3

:2014 (IEC 61508-3:2010)

表 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 は客観的な構造的カバレッジの目標)

82

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


83

C 0508-3

:2014 (IEC 61508-3:2010)

表 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

外部環境の定義を示す

83

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


84

C 0508-3

:2014 (IEC 61508-3:2010)

表 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

84

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


85

C 0508-3

:2014 (IEC 61508-3:2010)

表 C.16−詳細特性−性能テスト(表 B.6 の関連表) 

技法及び手段

特性

設計仕様に関するテスト及び統

合の完全性

設計仕様に関するテスト及び統合の正確性

(正常完了)

再現性

正確に定義したテスト及び統

合の構成

1

アバランチ及びストレス

テスト

− R1

(客観的目標を設定している場合は R2)

2

応答タイミング及びメモ

リ制約

− R1

(客観的目標を設定している場合は R2)

3

性能要求事項

− R1

(客観的目標を設定している場合は R2)

85

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


86

C 0508-3

:2014 (IEC 61508-3:2010)

表 C.17−詳細特性−準形式手法(表 B.7 の関連表) 

技法及び手段

特性

ソフトウェア

安全要求仕様

の完全性

ソフトウェア

安全要求仕様

の正確性

固有設計フ

ォールトの

回避性

理解しやす

い安全要求

事項

ソフトウェアの

安全以外の機能

が安全機能へ危
険な影響を及ぼ

さない性質

単純さ及び理解

容易性

挙動の予

測可能性

検証及び

テスト可

能な設計

フォールト

トレランス

及びフォー

ルト検出

外部事象によ

る共通原因故

障の回避性

1

論理及び機能ブ

ロック図

R2 R2 R2

− R1

R2

− R1

2

シーケンス図 R2

R2

R2

− R1

R2

− R2

3

データフロー図

R1 R1 R1

− R1

トランザクショ
ン処理に最適

− R1

4a

有限状態機械及
び状態遷移図

R2 R2 R2

− R1

事象発生順序の

数学的に完全な

仕様

R2

− R2

4b

タイムペトリネ
ット

R2 R2 R2

− R1

リアルタイムの

相互作用を特定

R2

− R2

5

エンティティ関

係属性データモ

デル

R1 R1 R1

− R1

− R1

6

メッセージシー
ケンスチャート

R2 R2 R2

− R1

R2

− R2

7

判定表又は真理
値表

R2 R2 R2

− R1

組合せロジック

R2

− R2

86

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


87

C 0508-3

:2014 (IEC 61508-3:2010)

表 C.18−決定論的安全度に関する特性−静的解析(表 B.8 の関連表) 

技法及び手段

特性

事前のフェーズに関する適

合確認の完全性

事前のフェーズに関する適合確認の正確性

(正常完了)

再現性

正確に定義した適合確認の構成

1

境界値解析

− R1

(境界結果に客観的基準がある場合は R2)

2

チェックリスト

− R1

− R1

3

制御フロー解析

− R1

4

データフロー解析

− R1

5

エラー推定

− R1

6a

形式的検査。専用の基準を含む R2

R2

− R2

6b

ウォークスルー(ソフトウェア)

 R1

R1

− R1

7

記号的実行

− R2

形式的に定義した事前条件及び事後条件で使用
し,数学的に厳密なアルゴリズムを用いたツール

によって実行する場合は R3

8

設計レビュー R2

R1

R2

(客観的性能要求事項がある場合)

− R2

9

ランタイムエラー挙動の静的解

− R1

数学的に厳密なアルゴリズムを用いたツールに

よって実行する場合,ある種のエラーでは R3

10

ワーストケース実行時間解析 R1

R3

− R2

87

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


88

C 0508-3

:2014 (IEC 61508-3:2010)

表 C.19−詳細特性−モジュラーアプローチ(表 B.9 の関連表) 

技法及び手段

特性

ソフトウェア

安全要求仕様

の完全性

ソフトウェア

安全要求仕様

の正確性

固有設計フォ

ールトの回避

単純さ及び理

解容易性

挙動の予測可

能性

検証及びテス

ト可能な設計

フォールトトレ

ランス及びフォ

ールト検出

共通原因故障

の回避性

1

ソフトウェアモジュールサイズ
の制限

− R1 R1 R1 R1  −

2

ソフトウェア複雑さ制御

− R1 R1 R1 R1  −

3

情報隠蔽及びカプセル化

− R1 R1 R1 R1  −

4

パラメータ数制限及び固定数の

サブプログラムパラメータ

− R1 R1 R1 R1  −

5

サブルーチン及び関数における

1

入口点又は 1 出口点

− R1 R1 R1 R1  −

6

完全に定義したインタフェース

− R2 R1 R1 R1  −

88

C 05

08-

3


2

014

 (IEC

 61

50
8

-3


20
10)


89

C 0508-3

:2014 (IEC 61508-3:2010)

附属書 D 
(規定)

適合品目の安全マニュアル−ソフトウェア要素の追加要求事項

D.1 

安全マニュアルの目的 

D.1.1

ある要素を一つ以上の別のシステム開発で再利用するとき,又は再利用する意図があるとき,その

要素の十分に詳しい,完全な説明(すなわち,機能,制約及び証拠)を添付することを確実にし,その要

素に全体的又は部分的に依存する特定の安全機能の完全性を,

評価できるようにする必要がある。

これは,

安全マニュアルによって実現しなければならない。

D.1.2

安全マニュアルは,JIS C 0508-2 

附属書 及びこの附属書の要求事項を満たす適切なものであれ

ば,要素の供給者の文書で構成してもよい。そうでなければ,安全関連系の設計の一部として作成するこ

とが望ましい。

D.1.3

安全マニュアルは要素の属性を定義しなければならないが,その属性には,利用するとき,インテ

グレータが知っていて考慮しなければならないハードウェアの制約及び/又はソフトウェアを含むことが

ある。特に安全マニュアルは,インテグレータに,その要素の特性,設計目的,挙動及び特徴を伝える手

段となる。

注記 1  安全マニュアル提供の範囲及び時期は,それを誰が利用するか,インテグレータの種類,そ

の要素の目的及びその要素を誰が提供し,維持するかに依存する。

注記 2  ソフトウェアを統合する人,部署又は組織を,インテグレータという。

D.2 

ソフトウェア要素の安全マニュアルの内容 

D.2.1 

安全マニュアルは,JIS C 0508-2 

附属書 が要求する情報のうち,ソフトウェア要素に関連する

全ての情報を含んでいなければならない。例えば JIS C 0508-2 

附属書 のハードウェア関連項目は,純

然たるソフトウェア要素とは無関係である。

D.2.2

ソフトウェア要素は識別し,必要な全ての使用説明をインテグレータに受け渡すようにしなければ

ならない。

注記  ソフトウェアの場合,これは,その要素を明確に識別し,その内容に変更箇所がないことを示

すことによって実証することができる。

D.2.3

要素の構成は,次による。

a)

ソフトウェア要素の構成,ソフトウェア及びハードウェアランタイム環境,並びに,必要ならばコン

パイル及びリンクシステムの構成は,安全マニュアルに記載しなければならない。

b)

ソフトウェア要素の推奨構成は安全マニュアルに記載し,安全用にその構成を使用しなければならな

い。

c)

安全マニュアルは,その要素を使用する正当な根拠の基である全ての前提を含んでいなければならな

い。

D.2.4

安全マニュアルには,次の事項を含めなければならない。

a) 

力量  要素のインテグレータに期待する,特定のアプリケーションツールの知識など,最低限の知識

を記載することが望ましい。

b)

その要素に割り当てた信頼性の度合い  その要素の認証の詳細,実施した独立の評価,インテグレー


90

C 0508-3

:2014 (IEC 61508-3:2010)

タが既存の要素に想定してもよい完全度などである。これは,その要素を設計したときの完全度,設

計プロセスで準拠した規格,及び要求する決定論的対応能力を支援して実現しなければならず,イン

テグレータに受け渡す制約を含むものであることが望ましい(要素の機能に応じて,ある要求事項を

満たすのは,システムの統合フェーズに限られるということがある。このような場合,そうした要求

事項は,インテグレータが作業を先に進めることができるように,明確にさせておかなければならな

い。応答時間及び性能に関する二つの要求事項は,そうした例に該当する。

注記  JIS C 0508-2 と異なり,JIS C 0508-3 は,適合品目の安全マニュアルに,ソフトウェア故障モ

ード又は定量的な故障率の記載を求めていない。なぜなら,ソフトウェアエラーの原因は,

JIS C 0508-2

附属書 のランダムハードウェア故障の原因と根本的に異なっているからで

ある。

c) 

インストール方法の説明  どのように既存の要素を統合システムにインストールするかの詳細,又は

参照箇所。

d) 

要素をリリースする理由  既存の要素が,未処理の不具合の除去,又は追加機能の組込みを受けてリ

リースしたかどうかの詳細。

e) 

未処理の不具合  未処理の不具合の詳細を,その不具合の説明,どのようにして発生するか,特定の

機能を使用する場合に,その不具合を軽減するためにインテグレータが考慮しなければならないメカ

ニズムと合わせて示すことが望ましい。

f) 

後方互換性  その要素が以前にリリースしたサブシステムとの互換性があるかどうかの詳細。互換性

がない場合は,従うべきアップグレード経路を提供するプロセスの詳細。

g) 

他のシステムとの互換性  既存の要素は,特別に開発したオペレーティングシステムに依存している

場合がある。そのような場合は,特別に開発したオペレーティングシステムのバージョンの詳細を示

すことが望ましい。

コンパイラ名及びバージョン,既存の要素の作成に使用したツール(名称及びバージョン)

,並びに

使用した既存の要素のテスト(この場合も名称及びバージョン)を含めたビルド基準も記載すること

が望ましい。

h) 

要素構成  既存の要素の名称及び説明の詳細を,バージョン・イシュー・部分改修の状態を含めて示

すことが望ましい。

i) 

変更管理  インテグレータが,ソフトウェアの制作者に変更要請を出すときの手続き。

j) 

満たしていない要求事項  規定しているが,要素の現行バージョンでは満たしていない要求事項が存

在するということがある。そのような場合は,その要求事項をインテグレータが検討できるように明

示することが望ましい。

k) 

設計安全状態  ある種の場合,システムアプリケーションのあらかじめ設計安全状態に移行するよう

に仕組んだ故障を受けて,要素が設計安全状態に戻ることがある。このような場合,インテグレータ

が検討できるように,設計安全状態の詳細な定義を記載することが望ましい。

l) 

インタフェースの制約  具体的な制約の詳細。特にユーザインタフェース要求事項を明らかにしなけ

ればならない。

m)

記載した脅威及び脆弱性に対して実装しているセキュリティ措置の詳細。

n) 

構成可能要素  構成方法又はその要素用にとられている方法,その使い方,及びその使用上の制約の

詳細を記載しなければならない。


91

C 0508-3

:2014 (IEC 61508-3:2010)

D.3 

適合品目の安全マニュアルの主張の正当な根拠 

D.3.1

適合品目安全マニュアルの主張は,適切な裏付けとなる証拠で正当な根拠を示さなければならな

い。JIS C 0508-2 の 7.4.9.7 を参照。

注記 1  主張している要素の安全性能は,十分な証拠で裏付けることが必須である。裏付けのない主

張は,その要素が寄与する安全機能の正確性及び安全度を確立する手助けとならない。

注記 2  裏付けとなる証拠は,要素供給者自身の文書及び要素供給者の開発プロセスの記録から取り

出してもよいし,安全関連系の開発者又は第三者による追加認定業務によって作成しても,

補足してもよい。

注記 3  証拠の提供には,商業上又は法的な制約が設けられていることがある(所有権又は知的財産

権など)

。こうした制約は,この規格の対象外である。

D.3.2

適合品目安全マニュアルの主張の正当な根拠を裏づける証拠は,要素安全マニュアルとは別のもの

である。

D.3.3

機能安全評価を円滑に行うための証拠を提示できない場合,その要素は E/E/PE 安全関連系には適

さない。


92

C 0508-3

:2014 (IEC 61508-3:2010)

附属書 E

(参考)

JIS C 0508-2

と JIS C 0508-3 との関係

表 E.1 及び表 E.2 は,ソフトウェアだけを取り扱う人が検討する必要のある JIS C 0508-2 の箇条がどれ

で,どの箇条は無視してよいかを見いだす手助けとなるものである。よく知られているように,大半の箇

条はハードウェアの問題に関わるものである。そのため,その点についてはここで繰り返さない。重要な

ソフトウェアはこの規格で取り上げてある。多数のソフトウェア関連要求事項は,大半がこの規格の要求

事項と重複するが,JIS C 0508-2 でも規定している。JIS C 0508-2 の知識が必要となるのは主に,ハード

ウェアとソフトウェアとの互換性を探るソフトウェア技術者である。JIS C 0508-2 の要求事項は,次のカ

テゴリにグループ分けする。

表 E.1JIS C 0508-2 の要求事項のカテゴリ 

ソフトウェア

ハードウェアを取り扱う規格使用者,及びソフトウェアを取り扱う
規格使用者の両方。

アプリケーション
ソフトウェア

オペレーティングシステムソフトウェア又はライブラリ機能では
なく,関連する安全機能だけを解決するためのソフトウェアを取り

扱う使用者。

システム

ソフトウェア

主にオペレーティングシステムソフトウェア,ライブラリ機能など

を取り扱う使用者。

ハードウェアだけ

ソフトウェアだけに関心をもつ使用者以外。

主にハードウェア

ソフトウェアに関連する部分は僅かである。

表 E.2JIS C 0508-2 の要求事項,及びソフトウェアとその種類の関係性 

JIS C 0508-2

要求事項

使用者にとって重要な取扱い対象

注記

7.2 

ソフトウェア

7.2.3.1 

アプリケーションソフトウェア

7.2.3.2

7.2.3.6 

ソフトウェア

7.2.3.3 

ハードウェアだけ

7.3 

ソフトウェア

7.3.2.2 f)

  ハードウェアだけ

7.4 

ソフトウェア

7.4.2.1

7.4.2.12 

ソフトウェア

7.4.2.13

7.4.2.14 

ハードウェアだけ

7.4.3.1

7.4.3.3 

ソフトウェア

7.4.3.4 

ハードウェアだけ

7.4.4 

ハードウェアだけ

7.4.5 

ハードウェアだけ

7.4.6 

ソフトウェア

7.4.6.7

  ハードウェアだけ

7.4.7 

ソフトウェア

7.4.7.1

の a)  及び b)

ハードウェアだけ

7.4.8 

ハードウェアだけ

7.4.9.1

7.4.9.3 

ソフトウェア

7.4.9.4

7.4.9.5 

ハードウェアだけ

7.4.9.6

7.4.9.7 

ソフトウェア


93

C 0508-3

:2014 (IEC 61508-3:2010)

表 E.2JIS C 0508-2 の要求事項,及びソフトウェアとその種類の関係性(続き) 

JIS C 0508-2

要求事項

使用者にとって重要な取扱い対象

注記

7.4.10 

ソフトウェア

主にシステムソフトウェア

7.4.11 

ハードウェアだけ

7.5 

ソフトウェア

7.6 

ソフトウェア

7.6.2.1 a) 

ハードウェア

7.6.2.4 

主にハードウェア

7.7 

ソフトウェア

7.7.2.3

7.7.2.4  主にアプリケ

ーションソフトウェア

7.8 

ソフトウェア

7.9 

主にアプリケーションソフトウェア

ソフトウェア

附属書 A.1 

主にハードウェア

附属書 A.2 及び表 

主にハードウェア

表 A.10  ソフトウェア

附属書 A.3 

主にハードウェア

表 A.16,表 A.17 及び表 A.18
ソフトウェアを一部含む

附属書 B,全ての表 

ソフトウェア

附属書 

ハードウェア

附属書 

ソフトウェア

D.2.3

  ハードウェアだけ

附属書 

ハードウェアだけ

附属書 

ハードウェアだけ


94

C 0508-3

:2014 (IEC 61508-3:2010)

附属書 F

(参考)

単一コンピュータ上のソフトウェア要素間の

不干渉性を達成するための技法

F.1 

序文 

単一のコンピュータシステム(一つ以上のプロセッサ,それらのプロセッサ間で共有するメモリ,他の

ハードウェアデバイスで構成。

)に搭載するソフトウェア要素間の実行の独立性は,多数の様々な方法で達

成し,実証することができる。この附属書には,不干渉性(異なる決定論的対応能力の要素間,同一の安

全機能を達成若しくは寄与するように設計している要素間,又は安全機能に役立つソフトウェアと同一コ

ンピュータ上の非安全関連ソフトウェアとの間。

)を達成するために用いることのできる,幾つかの技法を

示す。

注記  “実行の独立性”とは,複数の要素が互いに別の要素の実行挙動を妨害するようにして干渉し,

その結果,危険側故障が発生することがないことを意味する。この用語は,特に規格の他の要

求事項を満たすために,要素間で必要となる独立性の別の側面を識別するために使用する。

F.2 

挙動の領域 

実行の独立性は,空間域及び時間域の両方で達成し,実証することが望ましい。

空間:ある要素が使用するデータを,別の要素が変更してはならない。特に,非安全関連要素が変更して

はならない。

時間:ある要素は,利用可能なプロセッサ実行時間を占有しすぎて,又はある種の共有資源をロックして

別の要素の実行を阻んで,別の要素が正確に機能しなくなる原因となってはならない。

F.3 

原因分析 

実行の独立性を実証するために,設計案の分析を行って,空間域及び時間域で理論上は独立した(不干

渉)要素間の実行干渉について,考えられる全ての原因を識別することが望ましい。分析では,通常動作,

及び故障条件下の動作の両方を検討し,次の事項を検討に含めることが望ましい(ただし,これらだけに

限らない。

a)

ランダムアクセスメモリの共用

b)

周辺機器の共用

c)

プロセッサ時間の共用(二つ以上の要素を同一プロセッサによって実行する場合)

d)

設計全体を達成するために必要となる要素間通信

e)

ある要素の故障(オーバフロー,ゼロ除算例外又は誤ったポインタ計算など)が,その結果として別

の要素の故障を引き起こす可能性

次に,実行の独立性の達成及び正当な根拠は,これらの干渉の原因として特定したもの全てについて対

応するものでなければならない。

F.4 

空間域独立性の達成 

空間域独立性を達成し,実証するための技法には,次のものを含む。


95

C 0508-3

:2014 (IEC 61508-3:2010)

a)

それぞれ決定論的対応能力の異なる要素を含めて,異なる要素間のハードウェアメモリ保護の使用。

b)

ハードウェアメモリ保護のサポートを受けながら,各要素が独自の仮想メモリ空間と合わせて独自の

プロセスで実行することを可能にする,オペレーティングシステムの使用。

c)

ソフトウェア要素間から明示的又は黙示的なメモリ参照が行われないことを実証するための,次の手

法の使用。

−  厳密な設計解析

−  ソースコード解析

−  オブジェクトコード解析(可能性な場合)

これによって別の要素に属するデータを上書きするようになる(この場合は,ハードウェアメモリ

保護を利用しない。

d)

完全度の低い要素による不正な部分改修からの,完全度の高いデータのソフトウェアの保護。

データは,完全度の高い要素が,データの完全度が十分であると検証することができない限り,完

全度がより低い要素から完全度がより高い要素に受け渡さないようにすることが望ましい。

独立している必要のある要素間でデータの受け渡しを行わなければならない場合は,

共有メモリよりも,

メッセージ又はパイプのような片方向のインタフェースを使用することが望ましい。

注記  独立した要素は,互いにコミュニケーションを行わないようにすることが理想である。しかし,

システムの設計が,ある要素が別の要素にデータを送るように要求している場合,コミュニケ

ーションメカニズムの設計は,送る側の要素も受ける側の要素も故障することがないか,デー

タ送信が停止した場合又は遅れた場合に,両要素とも実行をブロックするようにすることが望

ましい。

磁気ディスクのような恒久的記憶装置にあるデータは,

ランダムアクセスメモリの一時データに加えて,

空間域の分割を検討しなければならない。例えば,オペレーティングシステムによるファイルアクセス保

護を使用すれば,ある要素が別の要素に属するデータ域に書き込むことを,防ぐことができる。

F.5 

時間域独立性の達成 

時間域独立性を達成するための技法には,次のものが含まれる。

a)

決定論的スケジューリング法。例えば,次のようなものがある。

−  周期的なスケジューリングアルゴリズム。各要素に,各要素のワーストケース実行時間解析によ

って裏づけられる定義した時間スライスを与え,各要素のタイミング要求事項を満たすことを静

的に実証する。

−  時間駆動アーキテクチャ。

b)

優先順位の逆転を回避する手段を付けて,リアルタイム実行部によって実現する厳密な優先順位を基

本とするスケジューリング。

c)

割り当てた実行時間又は期限を超過した場合に,ある要素の実行を中止する期間(このようなケース

については,潜在危険分析を行って,要素の停止が危険側故障につながらず,この技法を非安全関連

要素に採用することが最適であることを,示さなければならない)

d)

例えば,時間スライシングによって,どのプロセスもプロセッサ時間に欠乏することがないと保証す

るオペレーティングシステム。このようなアプローチが適用可能なのは,安全関連要素が満たさなけ

ればならないハードリアルタイム要求事項がなく,スケジューリングアルゴリズムがどの要素にも不


96

C 0508-3

:2014 (IEC 61508-3:2010)

当な遅れを招くことがないと,示す場合だけである。

要素間で資源(周辺機器など)を共有している場合は,別の要素によって共有資源をブロックしている

からといって,要素が誤った機能を発揮することがないことを保証するような設計でなければならない。

時間域不干渉を決定するときは,共有資源にアクセスするために必要な時間を考慮しなければならない。

F.6 

支援ソフトウェアに求められる要求事項 

空間域独立性若しくは時間域独立性又はその両方を得るために,オペレーティングシステム,リアルタ

イム実行部,メモリ管理,タイマー管理などのソフトウェアを使用する場合には,そのようなソフトウェ

アは,独立している必要のある任意の要素の中の,最高の決定論的対応能力をもつものでなければならな

い。

注記  このようなソフトウェアが,独立した要素の潜在的共通原因故障となることは,明らかである。

F.7 

ソフトウェアモジュールの独立性−プログラミング言語の側面 

次の

表 F.1 は,関連用語の参考となる定義である。

表 F.1−モジュール結合度−用語の定義 

用語

参考の定義

凝集度

一つのモジュール内のデータとサブプログラムとの間の結合の強さの尺度

結合度

モジュール間の結合の強さの尺度

カプセル化

内部(プライベート)データ及びサブプログラムを外部アクセスから隠すこと。主にオブジ
ェクト指向プログラムで使用する用語である。

独立性

ソフトウェア部分の非連結度の尺度。結合度を示す補語である。

モジュール

何かを実行し,独自のデータをもつことがある限定したソフトウェア部分。プログラミング
言語に従って,クラス,クラスの階層,サブプログラム,ユニット,モジュール,パッケー

ジなどと呼ばれる。

インタフェース

モジュールへのアクセスを行う,十分に定義したサブプログラムの一連のヘッド(出だしの

宣言文)

トランプデータ

別のモジュールに受け渡しするが,受ける側のモジュールで使用しないデータ

一般原則として,モジュール間の結合度が緩く,モジュール内の凝集度が高ければ,モジュールの独立

性は向上する。高い凝集度は,識別可能なユニットの機能が,コードを実装する識別可能なユニットに明

確に対応する状況を促し,結合度の緩いモジュールは,機能的に無関係なモジュール間で少ない相互作用

を促進し,したがって,高い独立性をもたらす。

通常,ある特定の機能の実行に使用するコード及びデータを寄せ集め,モジュール内で高い結合度を達

成することによって,緩いモジュール結合度が得られる。低い凝集度は,コード及びデータを任意に集め

られるようにするか,何らかのタイミングシーケンスによるか,又は制御フローの何らかのシーケンスが

もたらす。

モジュール結合度の幾つかの側面は区別することができる。

表 F.2 を参照。


97

C 0508-3

:2014 (IEC 61508-3:2010)

表 F.2−モジュール結合の種類 

結合度

定義

説明

理論的根拠

注記

イ ン タ フ

ェ ー ス 結
合,カプセ

ル化

十分に定義したサブ

プログラム集だけを
介した結合。

モジュ ール又 はそのデ

ータへ のアク セスはサ
ブプロ グラム を介して

だけ。変数の値の変更,

そのよ うな変 数の値に
関する質問,又はモジュ

ールが 要求す るその他

のサービスは,サブプロ
グラム 呼出を 介して実

行する。

モジュールのサブプログラ

ムのヘッド(シグネチャ)
は,利用可能なサービスを

説明する。

モジュールの変更を要求す
る場合,大量の変更は,当

該モジュール内で,他のモ

ジュールに影響を与えるこ
となく実施する。

緩い結合度をもたらし,一

般に推奨する。

主にオブジェクト指向プ

ログラム,クラス,クラ
スの階層,ライブラリの

パッケージ用であり,サ

ブ プ ロ グ ラ ム 用 で は な
い。

パ ラ メ タ
リ ス ト に

よ る デ ー

タ結合

パラメタリスト又は
サブプログラムの識

別子だけを介したデ

ータ転送。

サブプ ログラ ムのヘッ
ドに示す,変数又はオブ

ジェク トだけ を介した

モジュ ール又 はそのデ
ータへのアクセス。変数

の値の変更,そのような

変数の 値に関 する参照
は可視である。

サ ブ プ ロ グ ラ ム の ヘ ッ ド
は,そのサブプログラムの

呼出しに関与するデータ又

はオブジェクトを示す。 
緩い結合度をもたらし,一

般に推奨する。

オブジェクト指向プログ
ラムのクラス内では,こ

の原則は通常観察されな

い。ローカル変数には直
接アクセスする可能性が

ある。この原則を厳密に

守ると,トランプデータ
が出ることもある。この

種のデータが出ないよう

に,この原則は守らない
ほうがよい。

構造結合

データ転送は必要以
上に多くのデータを

含む。

要求す る機能 を実行す
るため に必要 となる以

上に,多くのデータを受

け側の サブプ ログラム
に転送する。

余分なデータは,別のモジ
ュールに,その目的を達成

するために必要ではない情

報を提供する。こうしたデ
ータは,モジュール間の協

調 を 誤 解 さ せ る こ と が あ

る。しかしながら,この使
用は非推奨ではない。

欠陥は一般に,簡単に是
正することができる。

制御結合

受け側モジュールで

直 接 制 御 を 行 う 結

合。

別のモ ジュー ルで分岐

反応だ けを引 き起こす

ことが できる データ転
送。多くのケースで,1

ビット の転送 に特徴が

ある。

直接的な動作を要求し,受

け側のサブプログラムに何

かをするように指示するた
め,上記の結合より密であ

る。取扱いには慎重を要し,

できれば避ける。一般には
推奨しない。

いつも回避できるとは限

らない。例えば,ある動

作 の 完 了 を 通 告 す る 場
合,又は,ある値の有効

性を通告する場合,必要

となることがある。

大 域 的 結

大域的データを介し
た結合。

モジュール群は,他のモ
ジュー ル群か ら直接ア

クセス 可能な データに

アクセス可能であるか,
又はあるモジュールは,

別のモ ジュー ルに属す

るデー タに直 接アクセ
ス可能である。

サ ブ プ ロ グ ラ ム の ヘ ッ ド
は,どのデータを,どこか

ら使用しているかを示さな

い。サブプログラムの機能
を理解し,コードの変更の

影響を予測することが困難

である。

一般に,これを使用する
ことは推奨しない。例外

的に,例えばトランプデ

ータを避けるために必要
となることがある。明確

に定義し,文書化したコ

ーディング基準に従うよ
うにして,ごく限定的に

使用する。


98

C 0508-3

:2014 (IEC 61508-3:2010)

表 F.2−モジュール結合の種類(続き) 

結合度

定義

説明

理論的根拠

注記

内容結合

他のモジュールに直

接ジャンプする,他
のモジュールの分岐

目標に影響するか,

又は他のモジュール
のデータに直接アク

セスする。

アセン ブリ言 語プログ

ラムで実現可能。高級言
語の全 てで実 現可能と

は限らない。プログラム

の実行を加速し,コーデ
ィング 業務を 減らすこ

とができる。

使用は推奨しない。結合し

ているモジュール群を理解
してはじめて,あるモジュ

ールを理解することができ

る。プログラムの理解及び
変更が極めて困難になる。

プログラミング言語によ

っては実現不能である。
常に回避する。

コードリーディング又はコードレビュー(7.9.2.12 参照)では,プログラムモジュールが緩い結合をして

いるかどうかを検証することが望ましい。この分析には,通常,モジュールの目的及びその動作の仕方に

ついての多少の理解が必要となる。したがって,適切な結合は,コード及びその文書を読むことによって

はじめて評価することができる。

コンテンツ結合は避けることが望ましい。

グローバル結合を使用してよいのは例外的な場合だけである。

制御結合及びプロシージャ結合は避けることが望ましい。できれば,モジュールはインタフェース結合(カ

プセル化)及び/又はデータ結合で結合することが望ましい。


99

C 0508-3

:2014 (IEC 61508-3:2010)

附属書 G 
(参考)

データ駆動システムに付属するライフサイクルのテーラリングの手引書

G.1 

データ駆動−システム部分及びアプリケーション部分 

多くのシステムは,二つの部分に分けて記述する。一つの部分は,基本となるシステム能力を与える。

もう一つの部分は,所定のアプリケーション専用の要求事項にシステムを適合させる。アプリケーション

部分は,システム部分を構成するデータの形式で書いてもよい。この附属書では,これを“データ駆動”

という。

ソフトウェアのアプリケーション専用部分は,多様なプログラミングツール及びプログラミング言語を

用いて開発してよい。これらの言語及びツールは,アプリケーションプログラムの書き方を制約すること

がある。

例えば,プログラミング言語が機能性(例えば,簡単なインターロックのラダーロジックの使用)シス

テム用の開発者及び構成者を支援する場合,アプリケーションソフトウェアプログラミング業務はかなり

単純なものとなる。ただし,プログラミング言語が開発者及び構成者に,複雑なアプリケーション挙動の

記述を許している場合,アプリケーションソフトウェアプログラミング業務は複雑なものとなる。ごく簡

単なアプリケーションソフトウェアを開発する場合,詳細設計は,プログラミングというよりは構成とな

ると考えてよい。

要求する安全度を達成するために必要な厳密さの程度は,開発者及び構成者が利用可能な構成の複雑さ

の度合い及びアプリケーションで表す挙動の複雑さに依存する。この点を,

図 G.1 の軸上で図解的に表す。

縦軸・横軸のそれぞれについて,複雑さを次のとおりクラス分けしている。

a) 

図 G.1 の横軸  言語の許す可変性は,次による。

−  固定プログラム

−  制約可変性(アプリケーションプログラムを,システム部分が解釈する“データ”とみる業界もあ

る)

−  完全可変性(通常,データ駆動とはみなさないが,この種のシステムは,アプリケーション開発用

に使用してもよく,完全を期すためにこの附属書に記載した)

b) 

図 G.1 の縦軸  アプリケーション構成能力は,次による。

−  限定的

−  完全

実際には,あるシステムは,レベルの異なる複雑さ及び構成能力を包含することがある。さらに,複雑

さは,二つの軸上に沿って伸縮を示すことがある。ソフトウェアライフサイクルのテーラリングを試みる

とき,関連する複雑さのレベルを特定し,テーラリングの度合いの正当な根拠を示すことが望ましい。

複雑さのレベルごとに,典型的なシステムのタイプの説明を次に示す。各タイプのシステムを実現する

ための推奨技法は,IEC 61508-7 に示している。


100

C 0508-3

:2014 (IEC 61508-3:2010)

図 G.1−データ駆動システムの複雑さの可変性 

複雑さの各クラスの典型的なシステムを,G.2 に記載する。

G.2 

制約可変性構成,及び限定的アプリケーション構成能力 

専用構成言語は,固定事前配付機能をもつ IEC 61508 に適合するシステムと併せて使用する。

構成言語は,プログラマがシステムの機能を改変することを許さない。その代わり,構成を,システム

がそのアプリケーションに調和できるように,多少の(データ)パラメータの調整に限定する。例えば,

スマートセンサ及び専用のパラメータが入るアクチュエータ,ネットワークコントローラ,シーケンスコ

ントローラ,データロギングシステム,スマート計測器などが挙げられる。

安全ライフサイクルをテーラリングする正当な根拠には,次のものが挙げられるが,これだけに限らな

い。

a)

このアプリケーション用の入力パラメータの仕様

b)

パラメータをオペレーティングシステムに正しく実装していることの適合確認

c)

入力パラメータの全組合せの妥当性確認

d)

構成時の特殊及び専用動作モードの検討

e)

ヒューマンファクタ又は人間工学

f)

インターロック,例えば,構成プロセスで動作インターロックが無効となることがないという確認

g)

不注意による再構成,例えば,キースイッチアクセス,保護装置

機能

事前配付機能

固定プログラム

制約可変性

限定的

完全可変性

アプリケーション

構成能力

制約可変性構成

完全アプリケーション

構成能力

(G.3)

制約可変性

プログラミング

完全アプリケーション

構成能力

(G.5)

完全機能

プログラミング及び構成

完全アプリケーション

構成能力

(G.7)

完全機能

プログラミング及び構成 
限定的アプリケーション

構成能力

(G.6)

制約可変性

プログラミング

限定的アプリケーション

構成能力

(G.4)

制約可変性構成

限定的アプリケーション

構成能力

(G.2)

完全


101

C 0508-3

:2014 (IEC 61508-3:2010)

G.3 

制約可変性構成,及び完全アプリケーション構成能力 

専用構成言語は,固定事前配付機能をもつ IEC 61508 に適合するシステムと併せて使用する。

構成言語は,プログラマがシステムの機能を改変することを許さない。その代わり,構成を,システム

がそのアプリケーションに調和できるように,広範な静的データパラメータの作成に限定する。例えば,

それぞれが一つ以上の属性をもつ,多数のデータエンティティを備えたデータで構成する航空管制システ

ムがある。データの基本的特徴は,明示的順序付け,オーダリング又は分岐構成子を含まず,アプリケー

ションの組合せ状態の表現を含まないことである。

G.2

に示す検討事項に加えて,安全ライフサイクルをテーラリングする正当な根拠には,次のものを含

めることが望ましいが,これだけに限らない。

a)

データ作成用自動ツール

b)

整合性チェック。例えば,データは自己親和性がある。

c)

ルールチェック。例えば,データの生成が定義した制約を満たしていることの確認。

d)

データ作成システムとのインタフェースの妥当性

G.4 

制約可変性プログラミング,及び限定的アプリケーション構成能力 

問題指向言語は,言語ステートメントが,限定的事前配付機能をもつシステムの使用者のアプリケーシ

ョン用語を含むか,又はその用語に類似している場合に,IEC 61508 に適合するシステムと併せて使用す

る。

これらの言語は,ユーザに,ハードウェア及びソフトウェア要素の範囲に基づいて,システムの機能を

自分固有の要求事項にテーラリングする限定的な柔軟性を認める。

制約可変性プログラミングの基本的特徴として,データが明示的シーケンシング,オーダリング又は分

岐構成子を含む場合があり,アプリケーションの組合せ状態を呼び出す場合がある。例えば,機能ブロッ

クプログラミング,ラダーロジック,スプレッドシート式システム,グラフィカルシステムなどがある。

G.3

に示す検討事項に加えて,次の要素を含めることが望ましいが,これだけに限らない。

a)

アプリケーション要求仕様

b)

このアプリケーション用として許している言語サブセット

c)

言語サブセットを組み合わせるための設計方法

d)

考えられるシステム状態の組合せに対応する適合確認用のカバレッジ基準

G.5 

制約可変性プログラミング,及び完全アプリケーション構成能力 

問題指向言語は,言語ステートメントが,限定的事前配付機能をもつシステムの使用者のアプリケーシ

ョン用語を含むか,又はその用語に類似している場合に,IEC 61508 に適合するシステムと併せて使用す

る。

制約可変性プログラミング,又は限定的アプリケーション構成能力との基本的な違いは,アプリケーシ

ョンの構成の複雑さである。例えば,グラフィカルシステム及び SCADA(Supervisory Control And Data

Acquisition

)ベースのバッチ制御システムなどがある。

G.4

に示す検討事項に加えて,次の要素を含めることが望ましいが,これだけに限らない。

a)

アプリケーションのアーキテクチャ設計

b)

テンプレートの規定

c)

個別テンプレートの適合確認


102

C 0508-3

:2014 (IEC 61508-3:2010)

d)

アプリケーションの適合確認及び妥当性確認

この規格に概説するライフサイクルの側面は,大半が不要なものだが(使用する言語に依存)

,最も低い

レベルのモジュール実装及びテストである。

G.6 

完全機能プログラミング及び構成,並びに限定的アプリケーション構成能力 

G.7

を参照。

G.7 

完全機能プログラミング及び構成,並びに完全アプリケーション構成能力 

これらのシステムには,この規格の全ライフサイクル要求事項を適用する。

システムの完全可変性部分は,汎用プログラミング言語若しくは汎用データベース言語,又は一般科学

的シミュレーションパッケージに基づいている。一般に,これらの部分は,システム資源配分を行い,リ

アルタイムマルチプログラミング環境を提供するオペレーティングシステムを装備したコンピュータシス

テムと併せて使用する。完全可変性言語で書かれるシステムの例としては,例えば,専用機械制御システ

ム,専用に開発したフライトコントロールシステム,安全関連サービスの管理用ウェブサービスなどがあ

る。


103

C 0508-3

:2014 (IEC 61508-3:2010)

参考文献

[1]  JIS C 0511

規格群  機能安全−プロセス産業分野の安全計装システム

注記  対応国際規格:IEC 61511 (all parts),Functional safety−Safety instrumented systems for the

process industry sector

(IDT)

[2]  JIS B 9961:2008

  機械類の安全性−安全関連の電気・電子・プログラマブル電子制御システムの機能

安全

注記  対応国際規格:IEC 62061:2005,Safety of machinery−Functional safety of safety-related electrical,

electronic and programmable electronic control systems

(IDT)

[3]  IEC 61800-5-2

,Adjustable speed electrical power drive systems−Part 5-2: Safety requirements−Functional

[4]  IEC 61508-5:2010

,Functional safety of electrical/electronic/programmable electronic safety-related systems−

Part 5: Examples of methods for the determination of safety integrity levels

[5]  IEC 61508-6:2010

,Functional safety of electrical/electronic/programmable electronic safety-related systems−

Part 6: Guidelines on the application of IEC 61508-2 and IEC 61508-3

[6]  IEC 61508-7:2010

,Functional safety of electrical/electronic/programmable electronic safety-related systems−

Part 7: Overview of techniques and measures

[7]  IEC 60601 (all parts)

,Medical electrical equipment

[8]  JIS B 3503:2012

  プログラマブルコントローラ−プログラム言語

注記  対応国際規格:IEC 61131-3,Programmable controllers−Part 3: Programming languages(MOD)