JISC0508-7:2017 電気・電子・プログラマブル電子安全関連系の機能安全

C 0508-7：2017 (IEC 61508-7：2010)

（1）

ページ

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

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

2 引用規格························································································································· 4

3 用語，定義及び略語 ·········································································································· 5

附属書A（参考）E/E/PE安全関連系のための技術及び手法の概要：ランダムハードウェア故障の管理 ·· 6

附属書B（参考）E/E/PE安全関連系のための技術及び手法の概要：決定論的原因故障の回避 ············· 23

附属書C（参考）ソフトウェア安全度を達成するための技術及び手法の概要 ··································· 51

附属書D（参考）既存ソフトウェアのソフトウェア安全度を判定するための確率的アプローチ ·········· 105

附属書E（参考）ASICの設計のための技術及び手法の概要 ························································ 109

附属書F（参考）ソフトウェアライフサイクル各フェーズの特性の定義 ········································ 123

附属書G（参考）安全関連オブジェクト指向ソフトウェアの開発に関する指針······························· 129

参考文献 ··························································································································· 131

C 0508-7：2017 (IEC 61508-7：2010)

（2）

まえがき

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

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

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

業規格である。これによって，JIS C 0508-7: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-7：2017

(IEC 61508-7：2010)

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

機能安全−第7部：技術及び手法の概観

Functional safety of electrical/electronic/programmable electronic

safety-related systems-Part 7: Overview of techniques and measures

序文

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

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

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

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

用いられてきた。一般に，プログラマブル電子系（以下，PE系という。）と呼ばれるコンピュータを用い

たシステムは，あらゆる適用分野で，安全以外の機能を達成するために用いられているが，次第に安全機

能の履行にも用いられるようになった。コンピュータシステムの技術が，効果的，かつ，安全に活用され

るためには，意思決定を行うための安全の考え方に関する十分な手引書が必須である。

JIS C 0508（IEC 61508）規格群（以下，この規格群という。）では，電気・電子・プログラマブル電子

（以下，E/E/PEという。）の要素から成るシステムが，安全機能を履行するための全ての安全ライフサイ

クル業務に対する包括的な扱い方について規定している。この統一された扱い方は，全ての電気的な安全

関連系にわたって，合理的かつ整合性がある技術指針を展開するためのものである。主な目的の一つは，

この規格群を基本とした適用分野の製品規格などの制定を容易にし，促進することである。

注記1 この規格群を基本とした適用分野の製品規格などの事例を，参考文献（JIS B 9961，JIS C 0511

及びIEC 61800-5-2）に示す。

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

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

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

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

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

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

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

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

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

可能とする。

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

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

C 0508-7：2017 (IEC 61508-7：2010)

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

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

かつ，包括的である。

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

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

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

ある。

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

供する。

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

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

水準を導入する。

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

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

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

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

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

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

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

する。

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

を10−9（1/h）に設定する。

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

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

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

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

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

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

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

るとみなしてもよい。

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

的対応能力を導入する。

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

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

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

適用範囲

1.1

この規格は，附属書A〜附属書Gによって，JIS C 0508-2及びJIS C 0508-3に関連する様々な安全

技術及び手法についての概観を示す。

注記1 これらの附属書は，それぞれ次の事項について記載している。

C 0508-7：2017 (IEC 61508-7：2010)

− 附属書A JIS C 0508-2に規定するE/E/PE安全関連系のための技術及び手法のうち，ラ

ンダムハードウェア故障を管理するための事項

− 附属書B JIS C 0508-2及びJIS C 0508-3に規定するE/E/PE安全関連系のための技術及

び手法のうち，決定論的原因故障を回避するための事項

− 附属書C JIS C 0508-3に規定するE/E/PE安全関連系のための技術及び手法のうち，ソ

フトウェア安全度を達成するための事項

− 附属書D JIS C 0508-3に規定するE/E/PE安全関連系のための技術及び手法のうち，既

存ソフトウェアのソフトウェア安全度を判定するための確率的アプローチ

− 附属書E JIS C 0508-2に規定するE/E/PE安全関連系のための技術及び手法のうち，

ASICの設計のための事項

− 附属書F JIS C 0508-3に規定するE/E/PE安全関連系のための技術及び手法における，

ソフトウェアライフサイクル各フェーズの特性の定義

− 附属書G JIS C 0508-3に規定するE/E/PE安全関連系のための技術及び手法における，

安全関連オブジェクト指向ソフトウェアの開発に関する指針

各細分箇条に記載する参考文献は，方法及びツールに関する基本的な参考文献又は例としてみなすこと

が望ましく，最新技術を表していない場合もある。

1.2

JIS C 0508-1，JIS C 0508-2，JIS C 0508-3及びJIS C 0508-4は，基本安全規格であるが，低複雑度

E/E/PE安全関連系（JIS C 0508-4の3.4.3参照）には適用しない。これらの規格は基本安全規格として，各

専門委員会がIEC Guide 104及びISO/IEC Guide 51に記載する原則に従った規格の作成において用いるこ

とを意図している。さらに，これらの規格は，独立した規格として用いることも意図している。ただし，

この規格の横断的安全機能は，IEC 60601の規格群を適用する医用機器には適用しない。

1.3

適用可能な場合，規格の作成において基本安全規格を活用することは，各専門委員会の責務である。

したがって，専門委員会が作成する規格に具体的に引用されているか，又は含まれていない場合は，これ

らの基本安全規格の要求事項，テスト方法若しくはテスト条件は適用しない。

1.4

図1に，この規格群の第1部から第7部までの全体の枠組みフレームワークを示し，さらに，この

規格がE/E/PE安全関連系の機能安全の達成のために果たす役割を示す。

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

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

systems−Part 7: Overview of techniques and measures（IDT）

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

ことを示す。

C 0508-7：2017 (IEC 61508-7：2010)

図1−この規格群の全枠組み

引用規格

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

規格は，記載の年の版を適用し，その後の改正版（追補を含む。）は適用しない。

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

び略語

技術的要求事項

その他の要求事項

第4部

用語の定義

及び略語

第5部

安全度水準の決定の

ための方法の例

第1部

全安全要求事項の作成

（概念，適用範囲の定義，
潜在危険及びリスク解析）

7.1〜7.5

第1部
文書化

箇条5及び

附属書A

第1部

機能安全の管理

箇条6

第1部

機能安全評価

箇条8

第1部

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

安全要求仕様

7.10

第1部

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

安全要求事項の割当て

7.6

第1部

E/E/PE安全関連系の設置，

引渡し及び安全妥当性確認

7.13〜7.14

第1部

E/E/PE安全関連系の運用，

保全及び修理，部分改修

及び改造，並びに使用終了

又は廃却

7.15〜7.17

第6部

第2部及び第3部の

適用の指針

第7部

技術及び手法

の概観

第2部

E/E/PE安全

関連系の実現

フェーズ

第3部

安全関連ソフト

ウェアの実現

フェーズ

C 0508-7：2017 (IEC 61508-7：2010)

附属書A

（参考）

E/E/PE安全関連系のための技術及び手法の概要：

ランダムハードウェア故障の管理（JIS C 0508-2参照）

A.1 電気

全般：電気機械構成部品における故障を管理する。

A.1.1 オンライン監視による故障検出

注記この技術及び手法は，JIS C 0508-2の表A.2（電気部品），表A.3（電子構成部品），表A.7［I/O

装置及びインタフェース（外部通信）］及び表A.13（センサ）〜表A.18（決定論的原因故障を

管理するための技法及び手段の有効性）で引用されている。

目的：被制御機器（EUC）の通常（オンライン）運転に応答するE/E/PE安全関連系の挙動を監視すること

で，故障を検出する。

説明：ある状況において，故障は，EUCの（例えば）時間的挙動に関する情報を用いて検出できる。例え

ば，E/E/PE安全関連系の一部であるスイッチが，通常，EUCによって作動する場合，そのスイッチ

が期待した時間に状態を変えないときは，故障を検出したことになる。通常，故障の場所を特定す

ることは不可能である。

A.1.2 リレー接点の監視

注記この技術及び手法は，JIS C 0508-2の表A.2及び表A.14［操作端（アクチュエータ）］で引用さ

れている。

目的：リレー接点の故障（例えば，溶着）を検出する。

説明：強制接点（又は強制ガイド式接点）リレーは，その接点同士が強固に連結できるように設計されて

いる。1組のa接点とb接点とがある場合，a接点が溶着しているとき，リレーコイルへの電源供給

が停止してもb接点は閉じることができない。したがって，リレーコイルへの電源供給が停止した

ときのb接点の閉動作を監視することを，a接点が開動作したことの証明に用いてもよい。通常，b

接点を閉じることができない場合，a接点が故障したことを示す。したがって，a接点によって制御

される機械類における回路の監視は，安全な運転停止又は運転停止の継続を確実にするものである

ことが望ましい。

参考文献：

Zusammenstellung und Bewertung elektromechanischer Sicherheitsschaltungen für Verriegelungseinrichtungen.

F. Kreutzkampf, W. Hertel, Sicherheitstechnisches Informations- und Arbeitsblatt 330212, BIA-Handbuch.

17. Lfg. X/91, Erich Schmidt Verlag, Bielefeld.

http://www.bgia-handbuchdigital.de/330212

A.1.3 コンパレータ

注記この技術及び手法は，JIS C 0508-2の表A.2，表A.3及び表A.4（処理単位）で引用されている。

目的：独立処理装置又はコンパレータの（非同時）故障をできるだけ早く検出する。

C 0508-7：2017 (IEC 61508-7：2010)

説明：独立処理装置の信号を，定期的又は連続的にハードウェアコンパレータによって比較する。コンパ

レータ自体は，外部的にテストしてもよいし，自己監視技術を用いてもよい。プロセッサの挙動に

関して検出した差が故障メッセージとなる。

A.1.4 多数決

注記この技術及び手法は，JIS C 0508-2の表A.2，表A.3及び表A.4で引用されている。

目的：三つ以上のハードウェアチャネルの一つの故障を検出し，マスクする。

説明：多数決原理（2 out of 3，3 out of 3，又はm out of n）を用いた多数決回路を用いて故障を検出し，マ

スクする。多数決回路自体は，外部的にテストしてもよいし，自己監視技術を用いてもよい。

参考文献：

Guidelines for Safe Automation of Chemical Processes. CCPS, AIChE, New York, 1993, ISBN-10:

0-8169-0554-1, ISBN-13: 978-0-8169-0554-6

A.1.5 アイドル電流原理（非励磁トリップ）

注記この技術及び手法は，JIS C 0508-2の表A.16（環境上のストレス又は影響によって生じる決定

論的原因故障を管理するための技法及び手段）で引用されている。

目的：電源の遮断又は喪失があった場合に，安全機能を実行する。

説明：接点が開いても電流が流れない場合，安全機能を実行する。例えば，電動機の危険な動作を停止す

るためにブレーキを用いる場合，安全関連系の接点を閉じることによってブレーキを開き，安全関

連系の接点を開くことによってブレーキを閉じる。

参考文献：

Guidelines for Safe Automation of Chemical Processes. CCPS, AIChE, New York, 1993, ISBN-10:

0-8169-0554-1, ISBN-13: 978-0-8169-0554-6

A.2 電子システム

全般：半導体素子の故障を管理する。

A.2.1 冗長化ハードウェアによるテスト

注記この技術及び手法は，JIS C 0508-2の表A.3，表A.15（ハードウェア設計によって生じる決定

論的原因故障を管理するための技法及び手段），表A.16及び表A.18で引用されている。

目的：ハードウェア冗長性を用いて，すなわち，プロセス機能を実装するのに不要な追加のハードウェア

を用いて，故障を検出する。

説明：冗長化ハードウェアは，規定した安全機能を適切な頻度でテストするために用いることができる。

このアプローチは，通常，A.1.1又はA.2.2を実現するために必要である。

A.2.2 動的原理

注記この技術及び手法は，JIS C 0508-2の表A.3で引用されている。

目的：動的信号処理によって静的故障を検出する。

説明：本来は静的である信号（内部的又は外部的に生成されるもの）を強制的に変化させると，構成部品

の静的故障を検出する助けとなる。この技術は，電気機械構成部品に関わることが多い。

C 0508-7：2017 (IEC 61508-7：2010)

参考文献：

Elektronik in der Sicherheitstechnik. H. Jürs, D. Reinert, Sicherheitstechnisches Informations- und Arbeitsblatt

330220, BIA-Handbuch, Erich-Schmidt Verlag, Bielefeld, 1993.

http://www.bgia-handbuchdigital.de/330220

A.2.3 標準テストアクセスポート及び境界走査アーキテクチャ

注記この技術及び手法は，JIS C 0508-2の表A.3，表A.15及び表A.18で引用されている。

目的：ICの各ピンに起こることを管理及び観察する。

説明：境界走査（バウンダリスキャン）テストは，IC内部の回路テストポイントにどのようにアクセスす

るかという問題を解決することによって，ICのテストのしやすさを高めるIC設計技術である。コ

アロジック部及び入出力バッファから成る典型的な境界走査ICでは，そのコアロジック部と入出

力バッファとの間において，各ICピンに近接して，シフトレジスタステージが置かれる。各シフ

トレジスタステージは，境界走査セルに収容される。このセルは，ICの各入出力ピンに起こること

を，標準テストアクセスポートを経由して管理及び観察することができる。ICコアロジック部の内

部テストは，周囲の構成部品から受ける刺激からチップ上コアロジック部を隔離し，その後，内部

自己テストを実施することによって達成できる。これらのテストを，ICでの故障を検出するために

用いる。

参考文献：

IEEE 1149-1:2001，IEEE standard test access port and boundary-scan architecture, IEEE Computer Society,

2001, ISBN: 0-7381-2944-5

A.2.4 （不使用）

A.2.5 監視付き冗長化

注記この技術及び手法は，JIS C 0508-2の表A.3で引用されている。

目的：幾つかの機能ユニットを備え，それぞれのユニットの故障を検出するために挙動を監視し，挙動の

不一致を検出した場合は，安全状態への移行を開始させることによって，故障を検出する。

説明：安全機能は，複数のハードウェアチャネルによって実行する。これらのチャネルの出力を監視し，

フォールトを検出した場合（すなわち，全てのチャネルからの出力信号が同一ではない場合），安

全状態を開始させる。

参考文献：

Elektronik in der Sicherheitstechnik. H. Jürs, D. Reinert, Sicherheitstechnisches Informations- und Arbeitsblatt

330220, BIA-Handbuch, Erich-Schmidt Verlag, Bielefeld, 1993.

http://www.bgia-handbuchdigital.de/330220

Dependability of Critical Computer Systems 1. F. J. Redmill, Elsevier Applied Science, 1988, ISBN

1-85166-203-0

A.2.6 自動チェック機能付き電気・電子構成部品

注記この技術及び手法は，JIS C 0508-2の表A.3で引用されている。

目的：安全機能の周期的チェックによってフォールトを検出する。

C 0508-7：2017 (IEC 61508-7：2010)

説明：ハードウェアを，処理を開始する前にテストし，さらに，適切な間隔でテストを繰り返す。各テス

トが正常終了したときだけ，EUCは運転を継続する。

参考文献：

Elektronik in der Sicherheitstechnik. H. Jürs, D. Reinert, Sicherheitstechnisches Informations- und Arbeitsblatt

330220, BIA-Handbuch, Erich-Schmidt Verlag, Bielefeld, 1993.

http://www.bgia-handbuchdigital.de/330220

Dependability of Critical Computer Systems 1. F. J. Redmill, Elsevier Applied Science, 1988, ISBN

1-85166-203-0

A.2.7 アナログ信号監視

注記この技術及び手法は，JIS C 0508-2の表A.3及び表A.13で引用されている。

目的：測定した信号に対する信頼性を高める。

説明：選択が許される限り，アナログ信号を，デジタルオン又はオフの状態に優先して用いる。例えば，

トリップ又は安全な状態は，通常，信号レベル許容差の監視を伴うアナログ信号レベルによって表

す。この技術は，連続性の監視を行い，また，伝送器に対する信頼性を高め，さらに，伝送器のセ

ンシング機能に必要なプルーフテスト頻度を減らす。外部のインタフェース，例えば，インパルス

ラインもテストする必要がある。

A.2.8 ディレーティング

注記この技術及び手法は，JIS C 0508-2の7.4.2.13で引用されている。

目的：ハードウェア構成部品の信頼性を増す。

説明：ハードウェア構成部品は，システムの設計によって保証する，最大仕様定格を十分に下回る水準で

用いる。ディレーティングは，全ての通常動作条件の下で，各構成部品がこれらの耐用条件の上限

よりも十分に余裕のある状態で動作するための手法である。

A.3 演算処理装置

全般：演算処理装置における間違った結果を導く故障を認識する。

A.3.1 ソフトウェアによる自己テスト：パターンの数が限られている（単一チャネル）

注記この技術及び手法は，JIS C 0508-2の表A.4で引用されている。

目的：演算処理装置の故障をできるだけ早く検出する。

説明：ハードウェアは，特別な安全要求事項を全く考慮に入れない標準技術を用いて製作されている。故

障検出は，全面的に，複数の補完的データパターン（例えば，55 hex及びAA hex）を用いて自己テ

ストを実行する追加のソフトウェア機能によって実現する。

A.3.2 ソフトウェアによる自己テスト：ウォーキングビット（単一チャネル）

注記この技術及び手法は，JIS C 0508-2の表A.4で引用されている。

目的：演算処理装置の物理的記憶装置（例えば，レジスタ）及び命令デコーダの故障を，できるだけ早く

検出する。

説明：故障検出は，全面的に，物理的記憶装置（データ及びアドレスレジスタ）及び命令デコーダをテス

C 0508-7：2017 (IEC 61508-7：2010)

トするデータパターン（例えば，ウォーキングビットパターン）を用いて自己テストを実施する，

追加のソフトウェア機能によって実現する。ただし，診断カバー率は90 %にとどまる。

A.3.3 ハードウェアが対応する自己テスト（単一チャネル）

注記この技術及び手法は，JIS C 0508-2の表A.4で引用されている。

目的：故障検出の速度を高め，範囲を広げる専用のハードウェアを用いて，演算処理装置の故障をできる

だけ早く検出する。

説明：追加の専用ハードウェア装置によって，故障を検出するための自己テスト機能を支援する。これ

は，例えば，あるビットパターンの出力をウォッチドッグ原理に従って周期的に監視するハードウ

ェア装置であってもよい。

A.3.4 符号化処理（単一チャネル）

注記この技術及び手法は，JIS C 0508-2の表A.4で引用されている。

目的：演算処理装置の故障を，できるだけ早く検出する。

説明：演算処理装置は，特別な故障認識又は故障訂正回路技術を用いて設計することができる。これらの

技術は，今のところ，比較的単純な回路だけに適用されつつあるが，広範囲に用いられてはいない。

ただし，将来の展開の余地も排除しないことが望ましい。

参考文献：

Le processeur codé: un nouveau concept appliqué à la sécurité des systèmes de transports. Gabriel, Martin,

Wartski, Revue Générale des chemins de fer, No. 6, June 1990

Vital Coded Microprocessor Principles and Application for Various Transit Systems. P. Forin, IFAC Control

Computers Communications in Transportation, 79-84, 1989

A.3.5 ソフトウェアによる相互比較

注記この技術及び手法は，JIS C 0508-2の表A.4で引用されている。

目的：動的ソフトウェア比較によって，演算処理装置の故障をできるだけ早く検出する。

説明：二つの演算処理装置によって，データ（結果，中間結果及びテストデータを含む。）を相互に交換

する。データの比較を，各装置内のソフトウェアを用いて実施し，相違が生じた場合は故障メッセ

ージを生成する。

A.4 不変メモリの範囲

全般：不変メモリ内の情報の書き変わりを検出する。

A.4.1 ワード保護された複数ビットによる冗長化（例えば，拡張ハミングコードを用いたROMの監視）

注記1 この技術及び手法は，JIS C 0508-2の表A.5（不変メモリの範囲）で引用されている。

注記2 A.5.6及びC.3.2も参照。

目的：16ビットワード中の全ての単一ビット故障，全ての2ビット故障，幾つかの3ビット故障及び幾つ

かの全ビット故障を検出する。

説明：メモリの各ワードは，4以上のハミング距離をもつ拡張ハミングコードを生成するために，数ビッ

トの冗長ビット分だけ拡張する。1ワードを読むごとに，冗長ビットのチェックをすることで，改

C 0508-7：2017 (IEC 61508-7：2010)

ざんが起こっているかどうか判定できる。相違が生じた場合，故障メッセージを生成する。データ

ワードとそのアドレスとの連結のための冗長ビットを計算することによって，アドレス故障を検出

するためにも用いることができる。

参考文献：

Prüfbare und korrigierbare Codes. W. W. Peterson, München, Oldenburg, 1967

Error detecting and error correcting codes. R. W. Hamming, The Bell System Technical Journal 29 (2), 147-160,

1950

A.4.2 修正チェックサム

注記この技術及び手法は，JIS C 0508-2の表A.5で引用されている。

目的：全ての奇数ビット故障，すなわち，起こる可能性がある全てのビット故障の約50 %を検出する。

説明：チェックサムは，1ブロックメモリ内の全てのワードを用いる適切なアルゴリズムによって作成す

る。チェックサムは，追加の1ワードとしてROMに格納するか，又はチェックサムアルゴリズム

が前もって決めておいた値を確実に生成するようにするため，そのメモリブロックに追加の1ワー

ドを追加してもよい。その後のメモリテストにおいて，同じアルゴリズムを用いてチェックサムを

再び作成する。その結果を，格納した値又は決めておいた値と比較する。相違が生じた場合，故障

メッセージを生成する。

A.4.3 1ワード（8ビット）の署名

注記この技術及び手法は，JIS C 0508-2の表A.5で引用されている。

目的：1ワード内の全ての1ビット故障及び全ての複数ビット故障，並びに起こる可能性がある全てのビ

ット故障の約99.6 %を検出する。

説明：メモリブロックの内容を，巡回冗長検査（CRC）アルゴリズムを用いて，（ハードウェア又はソフ

トウェアのどちらかによって）1メモリワードに圧縮する。典型的なCRCアルゴリズムでは，ブロ

ックの内容全体をバイトシリアル又はビットシリアルのデータフローとして処理し，そのデータフ

ローにおいて，生成多項式の発生器を用いて連続的な多項式の除算を行う。除算の余りは圧縮した

メモリ内容を表す“署名”であり，メモリに格納する。署名はその後のテストで再び計算する。こ

の署名と既に格納したものとを比較する。相違が生じた場合，故障メッセージを生成する。

A.4.4 ダブルワード（16ビット）の署名

注記この技術及び手法は，JIS C 0508-2の表A.5で引用されている。

目的：1ワード内の全ての1ビット故障及び全ての複数ビット故障，並びに起こる可能性がある全てのビ

ット故障の約99.998 %を検出する。

説明：この手順では，CRCアルゴリズムを用いて署名を計算する。ただし，その結果の値の大きさは2ワ

ード以上とする。拡張した署名を，単一ワードの場合と同様に格納し，再計算する。これらの署名

を，比較する。格納した署名と再計算した署名との間に相違が生じた場合，故障メッセージを生成

する。

A.4.5 ブロック複製（例えば，ハードウェア又はソフトウェア比較による二重ROM）

注記この技術及び手法は，JIS C 0508-2の表A.5で引用されている。

C 0508-7：2017 (IEC 61508-7：2010)

目的：全てのビット故障を検出する。

説明：アドレス空間を，二つのメモリ内に複写する。第1のメモリは，通常の方法で操作する。第2のメ

モリは，同じ情報を収納しておき，第1のものと並行してアクセスする。出力を比較し，相違が生

じた場合は，故障メッセージを生成する。ある種のビットエラーを検出するためには，二つのメモ

リのいずれかのデータを反転して格納し，読み取るときに再び反転させる必要がある。

A.5 可変メモリの範囲

全般：アドレス指定，書き込み，格納及び読取り中の故障を検出する。

注記 JIS C 0508-2の表A.1（ランダムハードウェア故障を定量化するときに想定する又は安全側故障

割合の導出で考慮するフォールト又は故障）では，ソフトエラーを動作中に検出するフォール

ト又は安全側故障割合の導出で考慮するフォールトとして記載している。ソフトエラーの原因

は，（1）パッケージを構成する原子核の崩壊によるアルファ粒子，（2）中性子，（3）外部EMI

雑音及び（4）内部クロストークである。外部EMI雑音は，この規格群の他の要求事項で取り

扱っている。

アルファ粒子及び中性子の影響は，運用時の安全保全手法によって抑制することが望ましい。

ハードエラーに対して有効な安全保全手法は，ソフトエラーに対しては有効でない場合がある。

例えば，ウォークパス（walk-path），ガルパット（galpat）などのRAMテストは有効ではない

が，パリティ及び誤り訂正符号（ECC）を用いるメモリセルの繰返し読取り監視技術は有効で

ある。

ソフトエラーは，電磁放射事象が低電圧駆動半導体メモリセル，レジスタ，ラッチ又はフリ

ップフロップのデータ状態を逆転又は反転させるため，十分な電荷障害を引き起こす場合に発

生する。このエラーは，回路自体がこの放射によって恒久的な損害を受けないので，“ソフト”

と呼ばれる。ソフトエラーは，単一ビットアップセット（SBU），又は単一事象アップセット

（SEU）及び複数ビットアップセット（MBU）に分類されている。

妨害された回路がメモリセル又はフリップフロップのような格納素子である場合，この状態

は，次の（意図した）書き込み操作のときまで格納する。新しいデータは，正確に格納する。

組合せ回路では，このノードを駆動する構成部品から絶えずエネルギーが流れているので，こ

の影響はどちらかといえばグリッチといえる。配線及び通信線を接続する場合，この影響もグ

リッチとなる場合がある。ただし，容量が大きいために，アルファ粒子及び中性子の影響は無

視できるとみなす。

ソフトエラーは，いずれかの種類の可変メモリ，すなわち，DRAM，SRAM，マイクロプロ

セッサのレジスターバンク，キャッシュ，パイプライン，ADC，DMA，MMU，割り込みコン

トローラ，複雑なタイマなどのコンフィグレーションレジスタに関係することがある。アルフ

ァ粒子及び中性子粒子に対する感受性は，コア電圧及び形状の両方との関係によって決まる。

コア電圧が2.5 V，特に1.8 V未満の小形形状の場合，さらに評価を行い，より効果的な保護手

段をとる必要があろう。

ソフトエラー率は，（内蔵）メモリの場合，700 Fit/MBit〜1 200 Fit/MBitの範囲内にあると報

告されている［次のa)〜i) の文献及び資料を参照］。ただし，この数値は，デバイスを実装し

たシリコンプロセスからのデータと比較するための基準値である。最近まで，SBUが有力と考

えられてきたが，最新の予測［次のa) 参照］では，65 nm以下のシリコンプロセスの技術では

C 0508-7：2017 (IEC 61508-7：2010)

MBUの全体的ソフトエラー率（SER）が増えていると報告されている。

次の文献及び資料は，ソフトエラーについて詳述している。

a) Altitude SEE Test European Platform (ASTEP) and First Results in CMOS 130 nm SRAM. J-L.

Autran, P. Roche, C. Sudre et al. Nuclear Science, IEEE Transactions on Volume 54, Issue 4, Aug.

2007 Page(s): 1002-1009

b) Radiation-Induced Soft Errors in Advanced Semiconductor Technologies, Robert C. Baumann,

Fellow, IEEE, IEEE TRANSACTIONS ON DEVICE AND MATERIALS RELIABILITY, VOL. 5,

NO. 3, SEPTEMBER 2005

c) Soft errors' impact on system reliability, Ritesh Mastipuram and Edwin C Wee, Cypress

Semiconductor, 2004

d) Trends And Challenges In VLSI Circuit Reliability, C. Costantinescu, Intel, 2003, IEEE Computer

Society

e) Basic mechanisms and modeling of single-event upset in digital microelectronics, P. E. Dodd and L.

W. Massengill, IEEE Trans. Nucl. Sci., vol. 50, no. 3, pp. 583-602, Jun. 2003.

Destructive single-event effects in semiconductor devices and ICs, F. W. Sexton, IEEE Trans. Nucl.

Sci., vol. 50, no. 3, pp. 603-621, Jun. 2003.

g) Coming Challenges in Microarchitecture and Architecture, Ronen, Mendelson, Proceedings of the

IEEE, Volume 89, Issue 3, Mar 2001 Page(s): 325-340

h) Scaling and Technology Issues for Soft Error Rates, A Johnston, 4th Annual Research Conference

on Reliability Stanford University, October 2000

International Technology Roadmap for Semiconductors (ITRS), several papers.

A.5.1 RAMテストの“チェッカーボード”又は“マーチ”

注記この技術及び手法は，JIS C 0508-2の表A.6（可変メモリの範囲）で引用されている。

目的：主に静的ビット故障を検出する。

説明：0及び1のチェッカーボードパターンを，ビット指向メモリのセルに書き込む。その後，セルを，

一対ごとに，内容が同一で正しいことを確実にするために検査する。このような一対の最初のセル

のアドレスは可変であり，その対の2番目のセルのアドレスは，最初のアドレスをビット規模で反

転して形成する。最初の実行においては，メモリのアドレス範囲は可変アドレスから上位アドレス

に向かって実行し，2番目の実行においては，下位アドレスに向かって実行する。両方の実行は，

その後，最初の割当てを反転して繰り返す。相違が生じた場合は，故障メッセージを生成する。

RAMテスト“マーチ”においては，ビット指向メモリのセルは，一つの一様なビットストリーム

によって初期化する。最初の実行において，セルを昇順に検査する。各セルを内容が正しいかチェ

ックし，その内容を反転する。最初の実行において作成したバックグラウンドは，2番目の一連の

テストにおいて降順に，同じ方法で検査する。両方の最初の実行は，最初の割当てを反転して，3

番目又は4番目の実行において繰り返す。相違が生じた場合は，故障メッセージを生成する。

A.5.2 RAMテストの“ウォークパス”

注記この技術及び手法は，JIS C 0508-2の表A.6で引用されている。

目的：静的及び動的なビット故障，並びにメモリセル間のクロストークを検出する。

C 0508-7：2017 (IEC 61508-7：2010)

説明：テスト対象のメモリ範囲を，一つの一様なビットストリームによって初期化する。その後1番目の

セルを反転し，残りのメモリ領域を，バックグラウンドが正しいことを確実にするために検査する。

その後，1番目のセルを，元の値に戻すために再反転し，次のセルに対して全手順を繰り返す。バ

ックグラウンドの最初の割当てを反転して，“さまよえるビットモデル”の2回目の実行を行う。

相違が生じた場合は，故障メッセージを生成する。

A.5.3 RAMテストの“ガルパット”又は“透過ガルパット”

注記この技術及び手法は，JIS C 0508-2の表A.6で引用されている。

目的：静的ビット故障及び高い比率の動的結合を検出する。

説明：RAMテスト“ガルパット”においては，最初に，選択したメモリ範囲を一様に（すなわち，全て0

又は全て1に）初期化する。その後，テストする最初のメモリセルを反転し，残りの全てのセルを，

これらの内容が正しいことを確実にするために検査する。残りのセルの一つへの各読取アクセス後

に，反転したセルもチェックする。この手順を，選択したメモリ範囲内の各セルに対して繰り返す。

2回目の実行は，初期化の逆によって実施する。相違が生じた場合は，故障メッセージを生成する。

“透過ガルパット”のテストは，上記の手順を変化させたものである。すなわち，選択したメモ

リ範囲内の全てのセルを初期化しないで，現在の内容を変化させず，複数の組になったセルの内容

を比較するために署名を用いる。選択した範囲内のテスト対象の最初のセルを選択し，その範囲内

の残りの全てのセルの署名S1を計算し，格納する。その後，その被験セルを反転し，残りの全て

のセルの署名S2を再計算する（残りのセルの一つへの各読取アクセス後に，反転したセルもチェ

ックする。）。S2とS1とを比較し，相違が生じた場合は，故障メッセージを生成する。被験セルを，

元の内容を再確立するために再反転し，残りの全てのセルの署名S3を再計算し，S1と比較する。

相違が生じた場合は，故障メッセージを生成する。選択範囲内の全てのメモリセルを，同様にテス

トする。

A.5.4 RAMテストの“アブラハム”

注記この技術及び手法は，JIS C 0508-2の表A.6で引用されている。

目的：メモリセル間の縮退故障及び結合故障の全てを検出する。

説明：検出できるフォールトの比率は，RAMテストの“ガルパット”のものを超える。全メモリテスト

を実施するために要求される操作数は，メモリ中のセル数をnとする場合，約30 nである。メモリ

を分割し，各部分を別々の時間区分においてテストすることによって，実行サイクルからのメモリ

アクセスからはテストが“透明”になるようにすることができる。

参考文献：

Efficient Algorithms for Testing Semiconductor Random-Access Memories. R. Nair, S. M. Thatte, J. A.

Abraham, IEEE Trans. Comput. C-27(6), 572-576, 1978

A.5.5 1ビット冗長性（例えば，パリティビットによるRAM監視）

注記この技術及び手法は，JIS C 0508-2の表A.6で引用されている。

目的：テストするメモリ範囲内で起こる可能性がある全てのビット故障の50 %を検出する。

説明：メモリの各ワードを1ビット（パリティビット）で拡張し，各ワードは，そのビットを追加するこ

とで，論理1を偶数個又は奇数個もつワードとする。データワードのパリティは，読み取るごとに

C 0508-7：2017 (IEC 61508-7：2010)

チェックする。1の個数が違っていることを発見した場合，故障メッセージを生成する。偶数パリ

ティ又は奇数パリティの選択は，ゼロワード（0しかない）及びワンワード（1しかない）のどち

らかが故障の発生時に，より好ましくないものである場合は，そのより好ましくない方のワードが

有効コードとはならないように選択することが望ましい。パリティをデータワードとそのアドレス

との連結のために計算する場合，パリティは，アドレス指定故障を検出するために用いることもで

きる。

A.5.6 拡張ハミングコードによるRAM監視，又はエラー検出訂正コード（EDC）によるデータ故障の検

出

注記1 この技術及び手法は，JIS C 0508-2の表A.6で引用されている。

注記2 A.4.1及びC.3.2も参照。

目的：全ての奇数ビット故障，全ての2ビット故障，幾つかの3ビット故障及び幾つかの複数ビット故障

を検出する。

説明：ハミング距離を4以上とする拡張ハミングコードを作成するために，メモリへの各アクセスを数ビ

ットの冗長ビットだけ拡張する。データを読み取るごとに，冗長ビットをチェックすることで，改

ざんが起こったかどうかを判定することができる。相違が生じた場合は，故障メッセージを生成す

る。冗長ビットをデータとそのアドレスとの連結のために計算する場合，この手順をアドレス指定

故障を検出するために用いることもできる。

参考文献：

Prüfbare und korrigierbare Codes. W. W. Peterson, München, Oldenburg, 1967

Error detecting and error correcting codes. R. W. Hamming, The Bell System Technical Journal 29 (2), 147-160,

1950

A.5.7 ハードウェア又はソフトウェア比較及びリードライトテストが実施されるダブルRAM

注記この技術及び手法は，JIS C 0508-2の表A.6で引用されている。

目的：全てのビット故障を検出する。

説明：アドレス空間を，二つのメモリ内に複写する。第1のメモリは，通常の方法で操作する。第2のメ

モリは，同じ情報を収納しておき，第1のものと並行してアクセスする。出力を比較し，相違が生

じた場合は，故障メッセージを生成する。ある種のビットエラーを検出するためには，二つのメモ

リのいずれかのデータを反転して格納し，読み取るときに再び反転する必要がある。

A.6 I/O装置及びインタフェース（外部通信）

全般：入出力装置（デジタル，アナログ，シリアル又はパラレル）の故障を検出し，処理への許容できな

い出力を防止する。

A.6.1 テストパターン

注記この技術及び手法は，JIS C 0508-2の表A.7，表A.13及び表A.14で引用されている。

目的：静的故障（縮退故障）及びクロストークを検出する。

説明：これは，入出力装置のデータフローから独立した周期的テストである。このテストでは，観測値を

対応する期待値と比較するために，定義したテストパターンを用いる。テストパターン情報，テス

C 0508-7：2017 (IEC 61508-7：2010)

トパターン受信及びテストパターン評価は，全て，それぞれ独立させる必要がある。EUCが，テス

トパターンから許容できない影響を受けることは望ましくない。

A.6.2 コードの保護

注記この技術及び手法は，JIS C 0508-2の表A.7，表A.15，表A.16及び表A.18で引用されている。

目的：入出力データフローのランダムハードウェア故障及び決定論的原因故障を検出する。

説明：この手順は，決定論的原因故障及びランダムハードウェア故障の両方から入出力情報を保護する。

コード保護では，情報冗長性及び／又は時間冗長性に基づき，入出力装置のデータフロー従属故障

の検出を行う。典型的なものとしては，冗長情報を入力及び／又は出力データに重ね合わせる。こ

れによって，入出力回路の正しい動作を監視する手段を得る。多くの技術が可能であり，例えば，

搬送波信号をセンサの出力信号に重ね合わせてもよい。その後，ロジック装置によって，搬送波が

あるかどうかを確認してもよいし，ロジック装置と最終アクチュエータとの間を通過する信号の妥

当性を監視できるように，出力チャネルに冗長コードビットを追加してもよい。

A.6.3 マルチチャネルパラレルアウトプット

注記この技術及び手法は，JIS C 0508-2の表A.7で引用されている。

目的：ランダムハードウェア故障（縮退故障），外部からの影響によって発生する故障，タイミング故障，

アドレス指定故障，ドリフト故障及び一時故障を検出する。

説明：これは，ランダムハードウェア故障を検出するための，独立出力をもつデータフロー依存のマルチ

チャネルパラレル出力である。故障検出は，外部のコンパレータを介して実施する。故障が起こ

った場合，EUCはその電源を直接，遮断する。この手法は，診断テスト間隔内でデータフローが変

化した場合だけに有効である。

A.6.4 監視付きアウトプット

注記この技術及び手法は，JIS C 0508-2の表A.7で引用されている。

目的：個別故障，外部からの影響によって発生する故障，タイミング故障，アドレス指定故障，ドリフト

故障（アナログ信号用）及び一時故障を検出する。

説明：これは，定義された許容範囲（時間及び値）との適合性を確実にするための，独立した入力値に対

する，出力値のデータフロー依存の比較である。検出した故障は，必ずしも，欠陥を有する出力に

関わるとは限らない。この手法は，診断テスト間隔内でデータフローが変化した場合だけに有効で

ある。

A.6.5 インプット比較又は多数決

注記この技術及び手法は，JIS C 0508-2の表A.7及び表A.13で引用されている。

目的：個別故障，外部からの影響によって発生する故障，タイミング故障，アドレス指定故障，ドリフト

故障（アナログ信号用）及び一時故障を検出する。

説明：これは，定義された許容範囲（時間及び値）との適合性を確実にするための，独立した入力値のデ

ータフロー依存の比較である。“1oo2，2oo3又はこれ以上の冗長化”を用いる。この手法は，診断

テスト間隔内でデータフローが変化した場合だけに有効である。

C 0508-7：2017 (IEC 61508-7：2010)

A.7 データパス（内部通信）

全般：情報伝送における欠陥によって発生する故障を検出する。

A.7.1 1ビット追加によるハードウェアの冗長化

注記この技術及び手法は，JIS C 0508-2の表A.8［データパス（内部通信）］で引用されている。

目的：全ての奇数ビット故障，すなわちデータストリームにおいて起こる可能性がある全てのビット故障

の約50 %を検出する。

説明：バスを1ライン（ビット）だけ拡張し，この追加のライン（ビット）は，パリティチェックによっ

て故障を検出するために用いる。

A.7.2 複数ビット追加によるハードウェアの冗長化

注記この技術及び手法は，JIS C 0508-2の表A.8で引用されている。

目的：バス及びシリアル伝送リンクによる通信中の故障を検出する。

説明：バスを二つ以上のライン（ビット）だけ拡張し，これらの追加のライン（ビット）を，ハミングコ

ード技術によって故障を検出するために用いる。

A.7.3 二重化によるハードウェアの冗長化

注記この技術及び手法は，JIS C 0508-2の表A.8で引用されている。

目的：二つのバスの信号を比較することによって，通信中の故障を検出する。

説明：バスを二重にし，追加のライン（ビット）を故障を検出するために用いる。

A.7.4 テストパターンを用いる検査

注記この技術及び手法は，JIS C 0508-2の表A.8で引用されている。

目的：静的故障（縮退故障）及びクロストークを検出する。

説明：これは，データ経路のデータフロー非従属周期的テストである。このテストでは，観測値を対応す

る期待値と比較するために，テストパターンを定義して用いる。

テストパターン情報，テストパターン受信及びテストパターン評価は，全て，それぞれ独立させ

る必要がある。EUCが，テストパターンから許容できない影響を受けることは望ましくない。

A.7.5 伝送の冗長化

注記この技術及び手法は，JIS C 0508-2の表A.8で引用されている。

目的：バス通信における一時故障を検出する。

説明：情報を数回，順次伝送する。繰返しは，一時故障に対してだけに有効である。

A.7.6 情報の冗長化

注記この技術及び手法は，JIS C 0508-2の表A.8で引用されている。

目的：バス通信における故障を検出する。

説明：データをブロック単位で，ブロックごとに計算したチェックサムとともに送信する。その後，受信

側は，受信したデータのチェックサムを再計算し，その結果を受信したチェックサムと比較する。

C 0508-7：2017 (IEC 61508-7：2010)

A.8 電源

全般：電源の欠陥によって発生する故障を検出又は許容する。

A.8.1 安全遮断又は二次電源への切換えによる過電圧保護

注記この技術及び手法は，JIS C 0508-2の表A.9（電源）で引用されている。

目的：安全関連系を過電圧から保護する。

説明：パワーダウン処理による全ての出力の安全状態への切換え，又は二次電源（予備電源）への切換え

が十分間に合うように過電圧を検出する。

参考文献：

Guidelines for Safe Automation of Chemical Processes. CCPS, AIChE, New York, 1993, ISBN-10:

0-8169-0554-1, ISBN-13: 978-0-8169-0554-6

A.8.2 安全遮断又は二次電源への切換えによる電圧制御（二次制御）

注記この技術及び手法は，JIS C 0508-2の表A.9で引用されている。

目的：二次電圧を監視し，その電圧が規定範囲内でない場合，安全状態への移行を開始する。

説明：二次電圧を監視し，その電圧が規定範囲内でない場合，パワーダウンを開始するか，又は二次電源

への切換えを行う。

A.8.3 安全遮断又は二次電源への切換えによる電源断

注記この技術及び手法は，JIS C 0508-2の表A.9で引用されている。

目的：全ての安全重要情報を記憶して，電源を遮断する。

説明：内部状態を（必要ならば）不揮発性メモリで保存することができ，さらに，次のいずれかの事項が，

十分間に合うように早く，過電圧又は不足電圧を検出する。

− 全ての出力を電源断のための通常手順によって，安全状態への設定が可能になる。

− 全ての出力を電源断のための通常手順によって，安全状態への切換えが可能になる。

− 二次電源へ切り換わる。

A.9 時間的及び論理的プログラムシーケンス監視

注記この技術及び手法は，JIS C 0508-2の表A.15，表A.16及び表A.18で引用されている。

全般：欠陥を有するプログラムシーケンスを検出する。プログラムの個々の要素（例えば，ソフトウェア

モジュール，サブプログラム又はコマンド）が不正なシーケンス若しくは不正な時間で処理を実行

した場合，又はプロセッサのクロックが正しくない場合，欠陥を有するプログラムシーケンスが存

在する。

A.9.1 時間窓なしの個別の時間基準によるウォッチドッグ

注記この技術及び手法は，JIS C 0508-2の表A.10［プログラムシーケンス（ウォッチドッグ）］及び

表A.11（クロック）で引用されている。

目的：プログラムシーケンスの振舞い及び確からしさを監視する。

説明：コンピュータの挙動及びプログラムシーケンスの確からしさを監視するために，個別の時間間隔を

もつ外部タイミング要素（例えば，ウォッチドッグタイマ）を周期的にリセットする。プログラム

C 0508-7：2017 (IEC 61508-7：2010)

中にリセットの実行点を正しく置くことが重要である。ウォッチドッグタイマのリセットの実行は，

特定の1か所ではなく，最大実行間隔を指定する。

A.9.2 時間窓がある個別の時間基準によるウォッチドッグ

注記この技術及び手法は，JIS C 0508-2の表A.10及び表A.11で引用されている。

目的：プログラムシーケンスの振舞い及び確からしさを監視する。

説明：コンピュータの挙動及びプログラムシーケンスの確からしさを監視するために，個別の時間間隔を

もつ外部タイミング要素（例えば，ウォッチドッグタイマ）を周期的にリセットする。プログラム

中にリセットの実行点を正しく置くことが重要である。ウォッチドッグタイマには下限及び上限を

設定する。プログラムシーケンスの時間が期待値よりも長いか又は短い場合，緊急制御動作を行う。

A.9.3 プログラムシーケンスの論理監視

注記この技術及び手法は，JIS C 0508-2の表A.10及び表A.11で引用されている。

目的：プログラムの個々の部分の振舞い及び正しいシーケンスを監視する。

説明：プログラムの個々の部分の振舞い及び正しいシーケンスを，ソフトウェア（カウント手順，キー手

順）又は外部の監視装置を用いて監視する。プログラム中に確認点を正確に置くことが重要である。

A.9.4 プログラムシーケンスの時間的監視と論理的監視との組合せ

注記この技術及び手法は，JIS C 0508-2の表A.10及び表A.11で引用されている。

目的：プログラムの個々の部分の振舞い及び正しいシーケンスを監視する。

説明：プログラムのシーケンスを正しく実行している場合だけ，プログラムシーケンスを監視する時間的

監視装置（例えば，ウォッチドッグタイマ）をリセットする。

A.9.5 オンラインチェックによる時間的監視

注記この技術及び手法は，JIS C 0508-2の表A.10及び表A.11で引用されている。

目的：時間的監視機能のフォールトを検出する。

説明：時間的監視機能を始動時にチェックし，時間的監視機能が正しく働く場合だけ始動が可能となる。

例えば，（時間的監視として使う）熱センサを，始動時に加熱した抵抗器によってチェックするこ

とができる。

A.10 換気及び加熱

注記この技術及び手法は，JIS C 0508-2の表A.16及び表A.18で引用されている。

全般：安全関連系の場合，換気又は加熱の制御及び／又は監視。

A.10.1 温度センサ

目的：システムが仕様範囲外で運転を開始する前に，温度の上限又は下限の超過を検出する。

説明：温度センサが，E/E/PE安全関連系の最重要点における温度を監視する。温度が指定範囲から外れる

前に，緊急制御動作を行う。

C 0508-7：2017 (IEC 61508-7：2010)

A.10.2 ファン制御

目的：ファンの正しくない動作を検出する。

説明：ファンが正しく動作しているか監視する。ファンが正常に動作していない場合は，保全手段（根本

的手段，又は緊急制御動作）をとる。

A.10.3 温度ヒューズを介しての安全遮断の起動

目的：システムが温度仕様範囲外で動作する前に安全関連系を停止する。

説明：安全関連系を停止させるために，温度ヒューズを用いる。PE系の場合，この停止は，緊急制御動作

に必要な全ての情報を格納するパワーダウン処理によって開始する。

A.10.4 温度センサからの逸脱メッセージ及び条件付きアラーム

目的：安全関連系が温度仕様範囲外で動作していることを示す。

説明：温度を監視し，温度が指定範囲外の場合，アラームを出力する。

A.10.5 強制空冷の接続及び状態表示

目的：強制空冷によって過熱を防止する。

説明：温度を監視し，温度が指定の限界値よりも高くなったとき強制空冷を開始する。使用者には，その

状態を通知する。

A.11 通信及び大容量記憶装置

全般：外部情報源と大容量記憶装置との通信中の故障を管理する。

A.11.1 通信線からの電力線の分離

注記この技術及び手法は，JIS C 0508-2の表A.16で引用されている。

目的：大電流による通信線へのクロストークの誘導を最小限に抑える。

説明：電力線を，通信線から分離する。通信線上に電圧スパイクを誘導する可能性がある電界は，距離の

増加とともに減少する。

A.11.2 複数ラインの空間的分離

注記この技術及び手法は，JIS C 0508-2の表A.16で引用されている。

目的：複数ラインの大きな電流による相互クロストークの誘導を最小限に抑える。

説明：二重化信号を伝送するラインは互いに分離する。複数ライン上に電圧スパイクを誘導する可能性が

ある電界は，距離の増加とともに減少する。この手法によって，共通原因故障も減少する。

A.11.3 電磁イミュニティの増大

注記1 この技術及び手法は，JIS C 0508-2の表A.16及び表A.18で引用されている。

目的：安全関連系への電磁干渉を最小限に抑える。

説明：次のいずれかに対して安全関連系の電磁イミュニティを増強するために，遮蔽，フィルタなどの設

計技術を用いる。

− 電力線又は信号ラインから，放射又は伝導する可能性がある電磁妨害

C 0508-7：2017 (IEC 61508-7：2010)

− 静電放電の結果生じる可能性がある電磁妨害

注記2 安全関連系に対するイミュニティの要求事項，及び工業用途の安全関連系機能（機能安

全）を運用するように意図された機器に対するイミュニティの要求事項は，IEC

61326-3-1及びIEC 61326-3-2を参照。

参考文献：

IEC/TR 61000-5-2:1997，Electromagnetic compatibility (EMC)−Part 5: Installation and mitigation guidelines

−Section 2: Earthing and cabling

Principles and Techniques of Electromagnetic Compatibility, Second Edition, C. Christopoulos, CRC Press,

2007, ISBN-10: 0849370353, ISBN-13: 978-0849370359

Noise Reduction Techniques in Electronic Systems. H. W. Ott, John Wiley Interscience, 2nd Edition, 1988

EMC for Product Designers. T. Williams, Newnes, 2007, ISBN 0750681705

Grounding and Shielding Techniques in Instrumentation, 3rd edition, R. Morrison. Wiley-Interscience, New

York, 1986, ISBN-10: 0471838055, ISBN-13: 978-0471838050

A.11.4 相反信号伝送

注記この技術及び手法は，JIS C 0508-2の表A.7及び表A.16で引用されている。

目的：複数信号伝送ラインにおける同一誘導電圧を検出する。

説明：全ての二重化情報を，相反信号（例えば，論理1及び0）とともに伝送する。共通原因故障（例え

ば，電磁放射による）は，相反信号の比較器によって検出できる。

参考文献：

Elektronik in der Sicherheitstechnik. H. Jürs, D. Reinert, Sicherheitstechnisches Informations- und Arbeitsblatt

330220, BIA-Handbuch. 20. Lfg. V/93, Erich Schmidt Verlag, Bielefeld.

http://www.bgia-handbuchdigital.de/330220

A.12 センサ

全般：安全関連系のセンサの故障を管理する。

A.12.1 基準センサ

注記この技術及び手法は，JIS C 0508-2の表A.13で引用されている。

目的：センサの正しくない動作を検出する。

説明：プロセスセンサの動作を監視するために独立基準センサを用いる。プロセスセンサの故障を検出す

るために，基準センサによって全ての入力信号を適切な時間間隔でチェックする。

参考文献：

Guidelines for Safe Automation of Chemical Processes. CCPS, AIChE, New York, 1993, ISBN-10:

0-8169-0554-1, ISBN-13: 978-0-8169-0554-6

A.12.2 正作動スイッチ

注記この技術及び手法は，JIS C 0508-2の表A.13で引用されている。

目的：スイッチカムと接点との間の直接的機械的接続によって，接点を開く。

説明：正作動スイッチは，スイッチカムと接点との間の直接的機械的接続によって，その通常閉の接点を

C 0508-7：2017 (IEC 61508-7：2010)

開く。これは，スイッチカムが動作位置にあるときは，常に，スイッチ接点が確実に開いているこ

とを確実にする。

参考文献：

Verriegelung beweglicher Schutzeinrichtungen. F. Kreutzkampf, K. Becker, Sicherheitstechnisches

Informations- und Arbeitsblatt 330210, BIA-Handbuch. 1. Lfg. IX/85, Erich Schmidt Verlag, Bielefeld

A.13 操作端（アクチュエータ）

全般：安全関連系の操作端の故障を管理する。

A.13.1 監視

注記この技術及び手法は，JIS C 0508-2の表A.14で引用されている。

目的：アクチュエータの正しくない動作を検出する。

説明：アクチュエータの動作を監視する［例えば，リレーの正作動接点による監視（A.1.2参照）］。監視で

導入した冗長性は，緊急制御動作を開始させるために用いてもよい。

参考文献：

Guidelines for Safe Automation of Chemical Processes. CCPS, AIChE, New York, 1993, ISBN-10:

0-8169-0554-1, ISBN-13: 978-0-8169-0554-6

Zusammenstellung und Bewertung elektromechanischer Sicherheitsschaltungen für Verriegelungseinrichtungen.

F. Kreutzkampf, W. Hertel, Sicherheitstechnisches Informations- und Arbeitsblatt 330212, BIA-Handbuch.

17. Lfg. X/91, Erich Schmidt Verlag, Bielefeld

A.13.2 複数のアクチュエータの相互監視

注記この技術及び手法は，JIS C 0508-2の表A.14で引用されている。

目的：結果を比較することによって，アクチュエータのフォールトを検出する。

説明：複数のアクチュエータをそれぞれ，異なるハードウェアチャネルによって監視する。不一致が生じ

た場合，緊急制御動作を行う。

A.14 物理的環境に対する手法

注記この技術及び手法は，JIS C 0508-2の表A.16及び表A.18で引用されている。

目的：故障の原因となる物理的環境（水，ほこり及び腐食性物質）の影響を防止する。

説明：装置のきょう（筐）体を，予期される環境に耐えるように設計する。

参考文献：

JIS C 0920 電気機械器具の外郭による保護等級（IPコード）

C 0508-7：2017 (IEC 61508-7：2010)

附属書B

（参考）

E/E/PE安全関連系のための技術及び手法の概要：

決定論的原因故障の回避（JIS C 0508-2及びJIS C 0508-3参照）

注記この附属書の多くの技術はソフトウェアにも適用できるが，同一内容を附属書Cでは繰り返さ

ない。

B.1

一般的な手法及び技術

B.1.1 プロジェクトマネジメント

注記この技術及び手法は，JIS C 0508-2の表B.1（E/E/PE系設計要求仕様中の過失を回避するため

の技法及び手段）〜表B.6（決定論的原因故障を回避するための技法及び手段の有効性）で引

用されている。

目的：安全関連系を開発及びテストするための組織モデル，並びに規則及び手法を採用することによっ

て，故障を回避する。

説明：最も重要で最善の手法は，次の事項である。

− 組織モデルの作成，特に品質保証の手引に記載されている品質保証に関するもの

− 相互プロジェクト及びプロジェクト固有の指針における，安全関連系の作成及び妥当性確認の

ための規則及び手法の確立

幾つかの重要な基本原理を，次に記載する。

− 設計組織の定義

・組織単位の業務及び責任

・品質保証部門の権限

・開発からの品質保証（内部検査）の独立

− シーケンス計画（活動モデル）の定義

・内部検査及びこれらのスケジューリングを含め，プロジェクトの運用中に関わる全ての活動

の決定

・プロジェクトの更新

− 内部検査のための標準化したシーケンスの定義

・検査（検査理論）の計画，運用及び確認

・サブ製品のためのリリースの仕組み

・繰返し検査による安全維持

− 構成管理

・版の管理及び確認

・部分改修の影響の検出

・部分改修後の整合性検査

− 品質保証手法の定量的評価の導入

・要求事項の獲得

・故障の統計

C 0508-7：2017 (IEC 61508-7：2010)

− コンピュータ支援の汎用方法，ツール及び要員訓練の導入

参考文献：

JIS Q 9001 品質マネジメントシステム−要求事項

注記対応国際規格：ISO 9001:2008，Quality management systems−Requirements

JIS X 0145（規格群）情報技術−プロセスアセスメント

注記対応国際規格：ISO/IEC 15504 (all parts)，Information technology−Process assessment

CMMI: Guidelines for Process Integration and Product Improvement, 2nd Edition. M.B. Chrissis, M. Konrad, S.

Shrum, Addison-Wesley Professional, 2006, ISBN-10: 0-3212-7967-0, ISBN-13: 978-0-3212-7967-5

Guidelines for Safe Automation of Chemical Processes. CCPS, AIChE, New York, 1993, ISBN-10:

0-8169-0554-1, ISBN-13: 978-0-8169-0554-6

Dependability of Critical Computer Systems 1. F. J. Redmill, Elsevier Applied Science, 1988, ISBN

1-85166-203-0

B.1.2 文書化

注記1 この技術及び手法は，JIS C 0508-2の表B.1〜表B.6で引用されている。

注記2 JIS C 0508-1の箇条5（文書化）及び附属書A（文書の構成事例）も参照。

目的：開発中の各手順を文書化することによって，故障を回避し，システム安全の評価を容易にする。

説明：運用容量及び安全性，並びに開発において全ての当事者が行った注意事項は，評価時に実証する必

要がある。開発時の注意事項を示すため，及びあらゆる時点における安全性の証拠の適合確認を保

証するため，特別重要事項を文書化する。

重要な共通手法は，指針及びコンピュータ支援の導入である。次に例を示す。

− 次の事項を満たす指針

・グループ分け計画を規定する。

・内容のチェックリストを求める。

・文書の書式を決める。

− コンピュータ支援及び組織化されたプロジェクトライブラリの助けを借りた文書化の管理

個々の手法は，次による。

− 文書化における次のそれぞれの事項の分離

・要求事項

・システム（使用者による文書化）

・開発（内部検査を含む。）

− 安全ライフサイクルに従った開発文書化のグループ分け

− 文書を編集する際にその基礎とすることができる，標準化した文書化モジュールの定義

− 文書化の構成部分の明瞭な識別

− 公式な改訂版の更新

− 次に示す，明確で理解しやすい説明手段の選択

・決定のための形式的な表記法

・意図の紹介，正当化及び表現のための自然言語

・例を示すための図形表現

・図形要素の意味の定義

C 0508-7：2017 (IEC 61508-7：2010)

・専門語の語彙集

参考文献：

IEC 61506:1997，Industrial-process measurement and control−Documentation of application software

Guidelines for Safe Automation of Chemical Processes. CCPS, AIChE, New York, 1993, ISBN-10:

0-8169-0554-1, ISBN-13: 978-0-8169-0554-6

B.1.3 E/E/PE系安全機能の安全以外の機能からの分離

注記この技術及び手法は，JIS C 0508-2の表B.1及び表B.6で引用されている。

目的：システムの非安全関連部分が安全関連部分への好ましくない方法で影響を与えることを防止する。

説明：安全関連系と非安全関連系との分離が可能かどうかを，仕様内において決めることが望ましい。こ

れら二つの部分のインタフェースについて，明確な仕様を記述することが望ましい。明確に分離す

ることによって，安全関連系のテストのための労力を軽減することになる。

参考文献：

Guidelines for Safe Automation of Chemical Processes. CCPS, AIChE, New York, 1993, ISBN-10:

0-8169-0554-1, ISBN-13: 978-0-8169-0554-6

B.1.4 多様性のあるハードウェア

注記この技術及び手法は，JIS C 0508-2の表A.15，表A.16及び表A.18で引用されている。

目的：故障の割合及び種類が異なる種々の構成部品を用いて，EUCの運転中の決定論的原因故障を検出す

る。

説明：安全関連系の種々のチャネルには，異なる種類の構成部品を用いる。こうすることによって，共通

原因故障（例えば，過電圧，電磁妨害）の確率が下がり，そのような故障を検出する確率が上がる。

要求される機能を実行するための別の手段，例えば，別の物理的原理がある場合，同じ問題を解

くための他の方法を得ることができる。多様性には，幾つかの方法がある。機能多様性は，同じ結

果を達成するために異なるアプローチを用いる。

参考文献：

Guidelines for Safe Automation of Chemical Processes. CCPS, AIChE, New York, 1993, ISBN-10:

0-8169-0554-1, ISBN-13: 978-0-8169-0554-6

B.2

E/E/PE系設計要求仕様

全般：可能な限り，完全で，間違い及び矛盾がなく，かつ簡単に検証できる仕様を作成する。

B.2.1 構造化仕様

注記この技術及び手法は，JIS C 0508-2の表B.1及び表B.6で引用されている。

目的：部分的要求事項の階層構造を作成することによって，複雑さを軽減する。要求事項間のインタフェ

ース故障を回避する。

説明：この技術は，機能仕様を部分的要求事項に組み替えて，部分的要求事項間にできるだけ単純で目に

見える関係が存在するようにする。この解析は，小さく明白な部分的要求事項が区別されるように

なるまで継続的に詳細化する。最終詳細化の結果は，完全な要求事項の仕様の枠組みを定める部分

的要求事項の階層構造である。この方法は，部分的要求事項のインタフェースに重点を置くもので

C 0508-7：2017 (IEC 61508-7：2010)

あり，インタフェース故障を回避するために特に効果的である。

参考文献：

ESA PSS 05-02, Guide to the user requirements definition phase, Issue 1, Revision 1, ESA Board for Software

Standardisation and Control (BSSC), ESA, Paris, March 1995,

ftp://ftp.estec.esa.nl/pub/wm/wme/bssc/PSS0502.pdf

Structured Analysis and System Specification. T. De Marco, Yourdon Press, Englewood Cliffs, 1979, ISBN-10:

0138543801, ISBN-13: 978-0138543808

B.2.2 形式手法

注記1 具体的な形式手法の詳細は，C.2.4を参照。

注記2 この技術及び手法は，JIS C 0508-2の表B.1，表B.2（E/E/PE系の設計及び開発中のフォール

トの誘引を回避するための技法及び手段）及び表B.6で引用されている。

目的：形式手法によって，数学的推論の原則を，技術システムの仕様化及び実装に適用し，仕様化又は実

装の完璧さ，一貫性及び正確さを向上させる。

説明：形式手法は，仕様化及び／又は実装のフェーズで，システム説明書を作成する手段を提供する。こ

れらの形式的な説明書は，システム機能及び／又はシステム構造の数学的モデルである。

したがって，基礎システムの理解を深めるような明確なシステム説明書を作成できる（例えば，

オートマトンの全ての状態を，その初期状態，入力及びオートマトンの遷移方程式で記述する。）。

適切な形式手法の選択は，システム，その開発プロセス及び数学的モデルを使用できる範囲につ

いて完全な理解を要する，困難な作業である（注記3，注記4及び注記5参照）。

注記3 モデル（特性）の重要な定理は，シミュレーション，すなわち，選択されたシステム動

作の観察を超える信頼性を与えるシステムについての保証となる。

注記4 形式手法の不利な点として，次の点が考えられる。

− 抽象度の固定

− 所与の段階で関わりのある全ての機能性を把握することの限界

− 実装技術者がモデルを理解することの困難さ

− モデルを開発，解析及びシステムのライフサイクル全体にわたり保全するための，

非常な努力

− モデルの構築及び解析を支援するための効率的ツール入手の可能性

− モデルの開発及び解析の能力をもつスタッフの有無

注記5 形式手法コミュニティは，フォールトに対するシステム堅ろう（牢）性を強調しないで

システムの目標機能をモデル化することに明らかに注視している場合がある。したがっ

て，システム堅ろう（牢）性を含む個別の形式手法を選択する必要がある。

参考文献：

Formal Specification: Techniques and Applications. N.Nissanke, Springer-Verlag Telos, 1999, ISBN-10:

1852330023

B.2.3 準形式手法

注記1 JIS C 0508-3の表B.7（準形式手法）は，他の準形式ソフトウェア関連技術によって，この附

属書を拡張しており，この表の“参照先”は，次の項目を示している。

C 0508-7：2017 (IEC 61508-7：2010)

− 論理及び機能ブロック図：JIS B 3503参照

− シーケンス図：JIS B 3503参照

− データフロー図：C.2.2参照

− 有限状態機械及び状態遷移図：B.2.3.2参照

− タイムペトリネット：B.2.3.3参照

− エンティティ関連属性データモデル：B.2.4.4参照

− メッセージシーケンスチャート：C.2.14参照

− 判定表又は真理値表：C.6.1参照

目的：一部の間違い，脱落及び誤った挙動が検出できるように，仕様の部分を明確にかつ一貫性をもって

表現する。

注記2 この技術及び手法は，JIS C 0508-2の表B.1，表B.2及び表B.6並びにJIS C 0508-3の表A.1

（ソフトウェア安全要求仕様），表A.2（ソフトウェア設計及び開発−ソフトウェアアーキテ

クチャ設計），表A.4（ソフトウェア設計及び開発−詳細設計），表B.7（準形式手法），表C.1

（決定論的安全度に関する特性−ソフトウェア安全要求仕様），表C.2（決定論的安全度に関

する特性−ソフトウェア設計及び開発−ソフトウェアアーキテクチャ設計），表C.4（決定論

的安全度に関する特性−ソフトウェア設計及び開発−詳細設計）及び表C.17（詳細特性−準

形式手法）で引用されている。

参考文献：

JIS B 3503:2012 プログラマブルコントローラ−プログラム言語

B.2.3.1 一般事項

目的：設計が仕様に適合していることを証明する。

説明：準形式手法は，システムの開発におけるある段階，すなわち，仕様作成，設計又はコーディングに

おいて，システムの説明書を開発する手法を提供する。説明書は，場合によっては，機械によって

解析することができるか，又はシステムの挙動の様々な面を表示するためにアニメーション化する

ことができる。アニメーションは，システムが真の要求事項及び規定の要求事項を満たしているこ

との確信を高めることができる。

B.2.3.2及びB.2.3.3において，二つの準形式手法を説明する。

B.2.3.2 有限状態機械，及び状態遷移図

注記この技術及び手法は，JIS C 0508-3の表B.5（モデリング），表B.7，表C.15（詳細特性−モデ

リング）及び表C.17（詳細特性−準形式手法）で引用されている。

目的：システムの制御構造をモデル化する，適合確認する，規定する又は実装する。

説明：多くのシステムは，システムの状態，入力，及び動作によって説明することができる。したがって，

システムは，状態“S1”にあるとき，入力“I”を受けると，動作“A”を行い，状態“S2”に移動

する。全ての状態において全ての入力によるシステムの動作を説明することで，システムを完全に

説明することができる。この結果から得られるシステムのモデルは，有限状態機械（又は，有限状

態オートマトン）と呼ばれる。これは，システムが一つの状態から別の状態へどのように移動する

かを示す，いわゆる状態遷移図として，又は次元が状態及び入力であって，指定状態にあるときに

入力を受信したことによって起こる動作及び新状態をマトリックスセルが収容する，マトリックス

C 0508-7：2017 (IEC 61508-7：2010)

として描かれる場合がある。

システムが複雑であるか，又は自然構造をもっている場合，これは層状有限状態機械に反映する

ことができる。状態図は，ネスト化された状態（対象状態が，平行して展開でき，また，一部の点

では単一状態に再結合する可能性のある二つ以上のサブステートに分かれる。）が可能な状態遷移図

の一種である。これは，状態遷移表記の表現力を高めるものであるが，安全関連系では望ましくな

い余分な複雑さが加わる可能性がある。状態図は，形式（数学的）仕様をもつ。状態遷移図は，シ

ステム全体又はシステム内の一部の対象又は要素に適用できる。

有限状態機械として表現できる仕様又は設計は，次の事項について確認することができる。

− 完全性（システム又は対象は，それぞれの状態における，全ての入力の一つ一つに対して，一

つの動作及び新状態をもつ必要がある。）

− 一貫性（全ての状態及び入力の組合せに対して，唯一の状態遷移が可能である。）

− 到達性（一連の入力によって，ある状態からもう一方の状態へと変えることが可能か可能でな

いか。）

− 無限ループ又は行き止まり状態がないこと

これらは，重大なシステムの重要な特性である。これらのチェックを支援するツールは容易に開

発することができ，有限状態オートマトンに基づく各種モデル（形式言語，ペトリネット，マルコ

フ図など）が利用できる。有限状態機械の実装を適合確認する，又は有限状態機械のモデルをアニ

メーション化するために，テストケースを自動的に生成するアルゴリズムも存在する。状態遷移図

及び状態図は，図の作画及びチェックを可能とし，記述した状態機械を実装するコードを生成する

ためのツールによって，広い範囲で用いられている。

これらは，故障確率計算にも使用できる。B.6及びC.6を参照。

参考文献：

Introduction to Automata Theory, Languages, and Computation (3rd Edition). J. Hopcroft, R. Motwani, J.

Ullman, Addison-Wesley Longman Publishing Co, 2006, ISBN: 0321462254

Securisation des architectures informatiques. Jean-Louis Boulanger, Hermès−Lavoisier, 2009, ISBN:

978-2-7462-1991-5

B.2.3.3 タイムペトリネット

注記この技術及び手法は，JIS C 0508-3の表B.5，表B.7，表C.15及び表C.17で引用されている。

目的：システム挙動の関連面をモデル化し，解析及び再設計を通じて安全性及び運転時の要求事項を評価

し，可能な限り改善する。

説明：ペトリネットは，有限状態オートマトンの特殊な事例である。ペトリネットは，同時並行性を示

し，非同期挙動をもつ複数のシステムにおける情報及び制御のフローを表すのに適したグラフ理論

モデル群に属する。

ペトリネットは，場所及び遷移のネットワークである。場所は“マークを付けられる”ことも，

“マークを付けられない”こともある。遷移は，これに対する入力場所の全てにマークが付けられ

ているとき，“可能”となる。可能となった場合，遷移が発生することが許容される（必ずしも発生

しなくてよい。）。遷移が発生した場合，遷移に対する入力場所のマークが消され，それに代わって，

遷移からの各出力場所にマークが付けられる。

潜在危険は，モデルにおける個々の状態（マーキング）として表すことができる。ペトリネット

C 0508-7：2017 (IEC 61508-7：2010)

モデルは，システムのタイミング特性に合わせて拡張することができる。“古典的”なペトリネット

は制御フロー面に集中しているが，データフローをモデルに組み込むために幾つかの拡張が提案さ

れている。

これらは，故障確率計算をするために，モンテカルロシミュレーションの実施に当たって，非常

に効率的な支援もする。B.6.6.8参照。

参考文献：

Timed Petri Nets: Theory and Application. Jiacun Wang, Springer, 1998, ISBN 0792382706

Securisation des architectures informatiques. Jean-Louis Boulanger, Hermès−Lavoisier, 2009, ISBN:

978-2-7462-1991-5

B.2.4 コンピュータ支援仕様作成ツール

注記この技術及び手法は，JIS C 0508-2の表B.1及び表B.6並びにJIS C 0508-3の表A.1，表A.2，

表C.1及び表C.2で引用されている。

B.2.4.1 一般事項

目的：曖昧さ及び完全性の自動検出を容易にするために，形式仕様作成技術を用いる。

説明：この技術は，一貫性及び完全性を評価するために自動的に検査することができる，データベースの

形で仕様を作成する。仕様作成ツールは，使用者に対して規定されたシステムの様々な面をアニメ

ーション化することができる。一般に，この技術は，仕様の作成だけでなく，プロジェクトライフ

サイクルの設計及び他のフェーズの支援もする。仕様作成ツールは，B.2.4.2及びB.2.4.3に従って

分類できる。

B.2.4.2 特定の方法のためとして限定されないツール

目的：関連する部分とのつながり及び入力指示を与えることによって，使用者が優れた仕様を書く手助け

をする。

説明：仕様作成ツールは，使用者の定型業務の一部を引き継ぎ，プロジェクト管理を支援する。特別な仕

様作成方法論を強要するものではない。方法に関して比較的独立しているため，使用者は大幅な自

由が許されるが，仕様を作成する際に必要な専門化された支援に欠ける。このため，システムとの

融和がかなり難しい。

B.2.4.3 階層的解析を伴うモデル指向手順

目的：仕様の不完全さ，曖昧さ及び矛盾を避ける。例えば，動作の説明と様々な水準の抽象化におけるデ

ータとの間の一貫性を確実にすることによって，使用者が優れた仕様を書く手助けをする。

説明：この方法は，様々な水準の抽象化（精度）において，希望するシステム（構造化解析）を機能的に

表現する。このようなモデルは，数多く存在する。有限オートマトンは，離散又はデジタル系の展

開を記述するために広く利用されているモデルの一種である。微分方程式は概念的には似ているが，

連続又はアナログ系を対象としている。様々な水準における解析は，動作及びデータの両方に作用

する。曖昧さ及び完全性の評価は，階層水準間においても，同一水準の二つの機能ユニット（モジ

ュール）間においても可能である（例えば，システムモデルの状態は，初期状態，入力及びオート

マトンの遷移方程式で記述される。）

C 0508-7：2017 (IEC 61508-7：2010)

注記モデルに基づく記述の問題点は，抽象化の水準，所定の段階で関わりのある全ての機能性を把

握する限界，実務者がモデルを理解することの難しさ（構文読取りから理解に至る。），モデル

を開発，解析及びシステムのライフサイクル全体にわたる保全のための大変な努力，モデル構

築及び解析を支援する効率的ツール入手の可能性（こうしたツールの開発は，大変な努力を要

する仕事である。），並びにモデルの開発及び解析能力をもつスタッフの投入の可能性といえる。

参考文献：

System requirements analysis. Jeffrey O. Grady, Academic Press, 2006, ISBN 012088514X, 9780120885145

B.2.4.4 エンティティ関連属性データモデル

目的：システム内のエンティティ及びこれらの間の関係に焦点を当てることによって，使用者が優れた仕

様を書く手助けをする。

説明：希望のシステムは，オブジェクト及びこれらの関係の集合として説明できる。ツールを用いること

で，システムによってどの関係が解釈されるかの決定が可能となる。一般に，これらの関係を用い

ることによって，オブジェクトの階層構造，データフロー，データ間の関係，及びどのデータが製

造工程に従属するかを記述することができる。古典的な手順は，工程管理分野まで拡張されている。

検査能力及び使用者支援は，図示された関係の種類に依存する。一方，可能な表現方法が非常にた

くさんあるため，この技術の利用は複雑となる。

参考文献：

Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the

Product Development Cycle. Karl Eugene Wiegers, Microsoft Press, 2003, ISBN 0735618798,

9780735618794

B.2.4.5 誘因及び応答

目的：刺激・反応関係を明確にすることによって，使用者が優れた仕様を書く手助けをする。

説明：システムのオブジェクト間の関係を“誘因”及び“応答”という表記法で規定する。オブジェクト，

関係，特性及び構造を表す言語要素を含む，単純で容易に拡張できる言語を用いる。

B.2.5 チェックリスト

注記この技術及び手法は，JIS C 0508-2の表B.1，表B.2及び表B.6並びにJIS C 0508-3の表A.10

（機能安全評価），表B.8（静的解析），表C.10（決定論的安全度に関する特性−機能安全評価）

及び表C.18（決定論的安全度に関する特性−静的解析）で引用されている。

目的：詳細な要求事項を定めることなしに包括的なカバー率を確保するため，安全ライフサイクルフェー

ズによってシステムの全ての重要な側面に対して注意を向け，及び重要な評価を管理する。

説明：チェックリストは，それを実施する人が回答する1組の質問である。これらの質問の多くは，一般

的性質のものであり，アセッサは，これらの質問を，評価の対象となる個々のシステムに最も適し

ているものと解釈する必要がある。チェックリストは，全般的に全てのE/E/PE系安全及びソフトウ

ェア安全のライフサイクルフェーズに用いることができ，特に，機能安全評価を支援するツールと

して有用である。

妥当性確認を受けるシステムの広範囲のばらつきに対処するために，ほとんどのチェックリスト

は，多くの形式のシステムに適用できる質問を含んでいる。したがって，用いるチェックリストは，

C 0508-7：2017 (IEC 61508-7：2010)

取り扱うシステムに関係がなく，無視することが望ましい質問を含むこともある。同様に，具体的

に取り扱うシステムに対して，特に当てはまる質問を，標準的なチェックリストに補足する必要が

ある場合もある。

いずれの場合にも，チェックリストの使用は，その大半が，チェックリストを選択して適用する

技術者の専門的技術及び判断によって決まることは明らかである。したがって，選択したチェック

リストに関して，技術者による決定，及び追加又は必要以上の質問は，完全に文書化し，正当化す

ることが望ましい。目的は，チェックリストの適用を見直すことができること，及び異なる基準を

用いない限り同一結果が得られることを確実にすることである。

チェックリストを完成する上で，できる限り簡潔にすることが目標となる。広範囲にわたって正

当化が必要な場合は，追加の文書類を引用することによって，これを達成することが望ましい。各

質問に対する結果を文書化するために，合格，不合格及び未決，又はこれらに似た限られた応答の

一群を用いることが望ましい。この簡潔さは，チェックリスト評価の結果についての全般的結論に

到達するための手順を大幅に単純化する。

参考文献：

IEC 60880:2006，Nuclear power plants−Instrumentation and control systems important to safety−Software

aspects for computer-based systems performing category A functions

The Art of Software Testing, Second Edition. G. Myers et al., Wiley & Sons, New York, 2004, ISBN

0471469122, 9780471469124

Software Quality Assurance: From Theory to Implementation. Daniel Galin, Pearson Education, 2004, ISBN

0201709457, 9780201709452

JIS C 0452（規格群）電気及び関連分野−工業用システム，設備及び装置，並びに工業製品−構造化

原理及び参照指定

注記対応国際規格：IEC 61346 (all parts)，Industrial systems, installations and equipment and industrial

products−Structuring principles and reference designations

Guidelines for Safe Automation of Chemical Processes. CCPS, AIChE, New York, 1993, ISBN-10:

0-8169-0554-1, ISBN-13: 978-0-8169-0554-6

Risk Assessment and Risk Management for the Chemical Process Industry. H.R. Greenberg, J.J. Cramer, John

Wiley and Sons, 1991, ISBN 0471288829, 9780471288824

B.2.6 仕様の検査

注記この技術及び手法は，JIS C 0508-2の表B.1及び表B.6で引用されている。

目的：仕様の不完全さ及び矛盾を避ける。

説明：検査は，仕様の様々な品質を独立したチームによって評価する一般的技術である。検査チームは作

成者に質問を出し，作成者はこれらの質問に対して，満足のいくように回答する必要がある。調査

は，仕様の作成に関わらなかったチーム（可能な場合）が実施することが望ましい。要求する独立

性は，システムに要求する安全度水準によって決める。独立した検査者は，更に別の仕様を参照す

ることなく，システムの動作機能を議論の余地がない形に再構成することができる能力をもってい

ることが望ましい。さらに，検査者は動作及び組織的な手法の関連安全性及び技術面の全てをカバ

ーしていることを確認する必要がある。この手順は，これ自体が，実践上で非常に有効であること

が証明されている。

C 0508-7：2017 (IEC 61508-7：2010)

参考文献：

IEC 61160:2005，Design review

The Art of Software Testing, Second Edition. G. Myers et al., Wiley & Sons, New York, 2004, ISBN

0471469122, 9780471469124

Software Quality Assurance: From Theory to Implementation. D. Galin, Pearson Education, 2004, ISBN

0201709457, 9780201709452

B.3

E/E/PE系の設計及び開発

全般：仕様に従って安全関連系の安定した設計を行う。

B.3.1 指針及び規格の適合

注記この技術及び手法は，JIS C 0508-2の表B.2で引用されている。

目的：適用分野規格（この規格では規定していない。）に適合させる。

説明：安全関連系の設計では，指針に準拠することが望ましい。これらの指針は，第一に，事実上，故障

がない安全関連系を導くものであり，第二に，これ以降の安全妥当性確認を容易にするものである

ことが望ましい。指針は，汎用的に妥当でも，あるプロジェクトに固有のものでも，又は単一フェ

ーズに固有のものでもよい。

参考文献：

Guidelines for Safe Automation of Chemical Processes. CCPS, AIChE, New York, 1993, ISBN-10:

0-8169-0554-1, ISBN-13: 978-0-8169-0554-6

B.3.2 構造化設計

注記この技術及び手法は，JIS C 0508-2の表B.2及び表B.6で引用されている。

目的：部分的要求事項の階層構造を作成することによって，複雑さを軽減する。要求事項間のインタフェ

ース故障を回避する。適合確認を単純化する。

説明：ハードウェアを設計する場合には，具体的な基準又は方法を用いることが望ましい。例えば，次の

事項を要求する場合がある。

− 階層的に構造化した回路設計

− 製造後にテスト済みの回路部品の使用

同様に，ソフトウェアを設計するときに構造化チャートを用いることによって，ソフトウェアモ

ジュールの明確な構造を作り出すことができる。この構造は，モジュール間の互いの関わり方，モ

ジュール間でやりとりする正確なデータ及びモジュール間に存在する詳細制御を示す。

参考文献：

JIS C 0452（規格群）電気及び関連分野−工業用システム，設備及び装置，並びに工業製品−構造化

原理及び参照指定

注記対応国際規格：IEC 61346 (all parts)，Industrial systems, installations and equipment and industrial

products−Structuring principles and reference designations

Software Engineering for Real-time Systems. J. E. Cooling, Pearson Education, 2003, ISBN 0201596202,

9780201596205

Software Design. D. Budgen, Pearson Education, 2003, ISBN 0201722194, 9780201722192

C 0508-7：2017 (IEC 61508-7：2010)

An Overview of JSD, J. R. Cameron, IEEE Trans SE-12 No. 2, February 1986

Structured Development for Real-Time Systems (3 Volumes). P. T. Yourdon, P. T. Yourdon Press, 1985

Structured Development for Real-Time Systems (3 Volumes). P. T. Ward, S. J. Mellor, Yourdon Press, 1985

Applications and Extensions of SADT. D. T. Ross, Computer, 25-34, April 1985

Essential Systems Analysys. St. M. McMenamin, F. Palmer, Yourdon Inc, 1984

Structured Analysis (SA): A language for communicating ideas. D. T. Ross, Software Eng, Vol. SE-3 (1), 16-34

B.3.3 十分な実績のある構成部品の使用

注記この技術及び手法は，JIS C 0508-2の表B.2及び表B.6で引用されている。

目的：固有の特性をもつ構成部品を用いることによって，多数の初回フォールト及び未検出フォールトの

リスクを低減する。

説明：十分な実績のある構成部品の選定は，要素の信頼性に応じた安全性を考慮して（例えば，高い安全

要求事項に適合する，運用することによってテストした物理的装置の使用，又は安全なメモリだけ

への安全関連プログラムの格納），製造業者が実施する。メモリの安全性は，不正なアクセス及び

環境の影響（電磁両立性，放射など）並びに故障発生時の要素の応答を考慮したものである。

参考文献：

IEC 61163-1:2006，Reliability stress screening−Part 1: Repairable assemblies manufactured in lots

B.3.4 モジュール化

注記この技術及び手法は，JIS C 0508-2の表B.2及び表B.6で引用されている。

目的：サブシステム間のインタフェースに関わる複雑さを軽減し，故障を回避する。

説明：全てのサブシステムは，設計の全ての水準において明瞭に定義し，かつ，サイズを制限する（少数

の機能とする。）。サブシステム間のインタフェースは，可能な限り単純なものとし，横断的側面（す

なわち，共有データ，情報の交換）は最小限に抑える。個々のサブシステムの複雑さも制限する。

参考文献：

The Art of Software Testing, Second Edition. G. Myers et al., Wiley & Sons, New York, 2004, ISBN

0471469122, 9780471469124

Software Engineering for Real-time Systems. J. E. Cooling, Pearson Education, 2003, ISBN 0201596202,

9780201596205

Software Reliability−Principles and Practices. G. J. Myers, Wiley-Interscience, New York, 1976, ISBN-10:

0471627658, ISBN-13: 978-0471627654

B.3.5 コンピュータ支援設計ツール

注記この技術及び手法は，JIS C 0508-2の表B.2及び表B.6並びにJIS C 0508-3の表A.4及び表C.4

で引用されている。

目的：設計手順を，より系統的に実施する。既に利用可能でテスト済みの適切な自動構造要素を含む。

説明：コンピュータ支援設計ツール（CAD）は，これが利用できて，システムの複雑さによって正当化で

きる場合は，ハードウェア及びソフトウェアの両方の設計時に用いることが望ましい。これらのツ

ールの正当性は，特定のテスト，広範囲にわたる良好な使用実績，又は設計中の個々の安全関連系

に対するツールの出力に関する独立した適合確認によって実証することが望ましい。

C 0508-7：2017 (IEC 61508-7：2010)

支援ツールは，その統合度に合わせて選択することが望ましい。この意味で，ツールは，一方の

ツールからの出力が，その次のツールへの自動入力に適したコンテンツ及びフォーマットをもち，

これによって中間結果の再加工時にヒューマンエラーを持ち込む可能性を最小限に抑えるように協

働する場合，統合されているといえる。

参考文献：

Overview of Technology Computer-Aided Design Tools and Applications in Technology Development,

Manufacturing and Design. W. Fichtner, Journal of Computational and Theoretical Nanoscience, Volume 5,

Number 6, June 2008, pp. 1089-1105 (17)

The Electromagnetic Data Exchange: Much more than a Common Data Format. P.E. Frandsen et al. In

Proceeding of the 2nd European Conference on Antennas and Propagation. The Institution of Engineering

and Technology (IET), 2007, ISBN 978-0-86341-842-6

Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN

0321313798, 9780321313799

Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577,

9783827372574

B.3.6 シミュレーション

注記この技術及び手法は，JIS C 0508-2の表B.2，表B.5（E/E/PE系の安全妥当性確認中のフォール

トを回避するための技法及び手段）及び表B.6で引用されている。

目的：電気回路及び電子回路について，構成部品の機能的性能及び設計の正しさの両方を，系統的かつ完

全な検査を実施する。

説明：安全関連系回路の機能を，ソフトウェア挙動モデルを介して，コンピュータ上でシミュレーション

する。回路の各構成部品は，これ自体のシミュレーションされた挙動をもっており，これらを接続

した回路の応答は，各構成部品の限界データを確認することによって検査する。

B.3.7 検査（レビュー及び解析）

注記この技術及び手法は，JIS C 0508-2の表B.2及び表B.6で引用されている。

目的：仕様と実装との間の不一致を明らかにする。

説明：安全関連系に規定した機能を調査及び評価し，安全関連系が仕様の要求事項に適合していることを

確実にする。製品の実装及び使用に関する疑わしい点がある場合は，これらを解決するように文書

化する。ウォークスルーとは逆に，検査の実施においては，作成者は受動的であり，検査者は能動

的である。

参考文献：

IEC 61160:2005，Design review

Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN

0321313798, 9780321313799

Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577,

9783827372574

The Art of Software Testing, Second Edition. G. Myers et al., Wiley & Sons, New York, 2004, ISBN

0471469122, 9780471469124

C 0508-7：2017 (IEC 61508-7：2010)

ANSI/IEE 1028:1997，IEEE Standard for software reviews

Dependability of Critical Computer Systems 3. P. G. Bishop et al., Elsevier Applied Science, 1990, ISBN

1-85166-544-7

B.3.8 ウォークスルー

注記この技術及び手法は，JIS C 0508-2の表B.2及び表B.6で引用されている。

目的：仕様と実装との間の不一致を明らかにする。

説明：安全関連系の草案で規定した機能を調査し，評価して，安全関連系がこの仕様の要求事項に適合し

ていることを確実にする。製品の実現及び使用に関する疑わしい点及び潜在的弱点がある場合は，

これらを解決するように文書化する。検査とは逆に，ウォークスルーにおいては，作成者は能動的

であり，検査者は受動的である。

参考文献：

Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN

0321313798, 9780321313799

Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577,

9783827372574

ANSI/IEEE 1028:1997，IEEE Standard for software reviews

Dependability of Critical Computer Systems 3. P. G. Bishop et al., Elsevier Applied Science, 1990, ISBN

1-85166-544-7

Methodisches Testen von Programmen. G. J. Myers, Oldenbourg Verlag, München, Wien, 1987

B.4

E/E/PE系の運用及び保全手順

全般：安全関連系の運用及び保全中の故障を回避する手助けとなる手順を開発する。

B.4.1 運用及び保全指示書

注記この技術及び手法は，JIS C 0508-2の表B.4（E/E/PE系の運用及び保全手順の実施中のフォー

ルト及び故障を回避するための技法及び手段）で引用されている。

目的：安全関連系の運用及び保全中の間違いを避ける。

説明：使用指示書は，安全関連系の使用方法及び保全方法に関する必須情報を記載する。特別な場合，こ

れらの指示書には，安全関連系の据付方法全般についての例も含める。全ての指示は，容易に理解

できるようにする必要がある。複雑な手順及び依存関係を説明するためには，図表を用いることが

望ましい。

参考文献：

Guidelines for Safe Automation of Chemical Processes. CCPS, AIChE, New York, 1993, ISBN-10:

0-8169-0554-1, ISBN-13: 978-0-8169-0554-6

B.4.2 使いやすさ

注記この技術及び手法は，JIS C 0508-2の表B.4で引用されている。

目的：安全関連系の運用中の複雑さを軽減する。

説明：安全関連系の正しい運用は，ある程度は人間の操作によって決まる。安全関連系の開発者は，該当

C 0508-7：2017 (IEC 61508-7：2010)

するシステム設計及び作業場の設計を考慮することによって，次の事項を確実にする必要がある。

− 人間の操作の必要性を，絶対的最小限に制限する。

− 必要な操作はできる限り単純にする。

− オペレータの誤りから生じる危害の可能性を最小限に抑える。

− 操作装置及び指示装置は，人間工学的要求事項に従って設計する。

− 操作装置は単純で，十分なラベル表示によって，直感的に使用できるものとする。

− オペレータが，極端な状況においても，過度な緊張を強いられることがない。

− 被訓練使用者の知識水準及び動機付け状態に応じて，操作手順及び操作装置についての訓練を

行う。

B.4.3 保全のしやすさ

注記この技術及び手法は，JIS C 0508-2の表B.4で引用されている。

目的：安全関連系の保全手順を単純化し，有効な診断及び修理に必要な手法を設計する。

説明：予防保全及び修理は，多くの場合，困難な環境下で，期限に押されながら実施される。したがって，

安全関連系の開発者は，次の事項を確実にすることが望ましい。

− 安全関連保全処置は極力必要ではないようにし，理想的には，全く必要でないようにする。

− 不可避の修理のために，十分で，有効な，取り扱いやすい診断ツールを含め，ツールは全ての

必要なインタフェースを含むことが望ましい。

− 別の診断ツールを開発するか，又は入手が必要になった場合，これらを適時に入手できること

が望ましい。

B.4.4 運用の可能性の制限

注記この技術及び手法は，JIS C 0508-2の表B.4及び表B.6で引用されている。

目的：通常使用者による運用可能性を減少させる。

説明：このアプローチは，次の事項によって，運用可能性を減少させる。

− 運用を特別な運転モード内に制限する，例えば，キースイッチによる。

− 運転要素の数を制限する。

− 一般的に可能な運転モードの数を制限する。

参考文献：

Guidelines for Safe Automation of Chemical Processes. CCPS, AIChE, New York, 1993, ISBN-10:

0-8169-0554-1, ISBN-13: 978-0-8169-0554-6

B.4.5 熟練運転員だけによる運用

注記この技術及び手法は，JIS C 0508-2の表B.4及び表B.6で引用されている。

目的：誤用によって発生する運転時の故障を回避する。

説明：安全関連系の運転員は，安全関連系の複雑さ及び安全度水準に適した水準まで訓練する。訓練に

は，製造工程の背景の学習及び安全関連系とEUCとの間の関係を知ることが含まれる。

参考文献：

Guidelines for Safe Automation of Chemical Processes. CCPS, AIChE, New York, 1993, ISBN-10:

0-8169-0554-1, ISBN-13: 978-0-8169-0554-6

C 0508-7：2017 (IEC 61508-7：2010)

B.4.6 運転員の間違いに対する保護

注記この技術及び手法は，JIS C 0508-2の表B.4及び表B.6で引用されている。

目的：運転員の全ての種類の間違いからシステムを保護する。

説明：誤入力（値，時間など）を，確からしさのチェック又はEUCの監視によって検出する。これらの

装置を設計に組み込むためには，入力の種類を考え，どのような入力を許容するかを，非常に早い

段階で定める必要がある。

B.4.7 （不使用）

B.4.8 改変からの保護

注記この技術及び手法は，JIS C 0508-2の表A.17（決定論的運用フォールトを管理するための技法

及び手段）及び表A.18で引用されている。

目的：安全関連系を，技術的手段によるハードウェアの改変ができないように保護する。

説明：改変又は改ざんを，例えば，センサ信号についての確からしさのチェック，技術的処理による検出

及び自動的始動テストによって，自動的に検出する。改変を検出した場合，緊急制御動作を行う。

B.4.9 インプットの確認応答

注記この技術及び手法は，JIS C 0508-2の表A.17及び表A.18で引用されている。

目的：運転中の誤りを，EUCを作動させる前に運転員自身によって検出する。

説明：安全関連系経由のEUCへの入力を，運転員が誤操作を検出して訂正できるように，EUCに送る前

に運転員に送り通知する。システム設計では，異常な，非誘発性の人的動作と同様に，人間の反応

の速度上限又は下限及び方向を考慮することが望ましい。このことによって，例えば，運転員が予

期するよりも速くキーを押し，そのため，システムが2回のキーストロークを1回のキーストロー

クと読み違えたり，システム（ディスプレイ）の最初のキー操作に対する反応が遅すぎて，キーを

2回押してしまったりすることを避ける。重要データの入力の場合，同一キーストロークは，続け

て2回以上のときは有効でないものとすることが望ましい。すなわち，“enter”又は“yes”キーを

何回も押すことによって，システムの危険な動作に至らないようにする必要がある。

運転員が判断することができず，システムを待機させておくこともできない場合のために，多選

択肢をもつ質問（はい，いいえなど）を備えたタイムアウト手順を含むことが望ましい。

安全関連PE系を再起動できるようにする場合は，ソフトウェア及びハードウェアの両方におい

て，再起動を留意して設計しないと，システムを損傷させやすい。

B.5

E/E/PE系の統合

全般：統合フェーズ中の故障を回避し，このフェーズ及び以前のフェーズ中に起こった故障を明らかにす

る。

B.5.1 機能テスト

注記この技術及び手法は，JIS C 0508-2の表B.3（E/E/PE系の統合中のフォールトを回避するため

の技法及び手段）及び表B.5並びにJIS C 0508-3の表A.5（ソフトウェア設計及び開発−ソフ

トウェアモジュールテスト及び統合），表A.6［プログラマブル電子装置統合（ハードウェア及

C 0508-7：2017 (IEC 61508-7：2010)

びソフトウェア）］，表A.7（ソフトウェアのシステム安全妥当性確認），表C.5（決定論的安全

度に関する特性−ソフトウェア設計及び開発−ソフトウェアモジュールテスト及び統合），表

C.6［決定論的安全度に関する特性−プログラマブル電子装置の統合（ハードウェア及びソフト

ウェア）］及び表C.7（決定論的安全度に関する特性−システム安全妥当性確認のソフトウェア）

で引用されている。

目的：仕様作成及び設計フェーズ中の故障を明らかにする。実装中及びソフトウェアとハードウェアとの

統合中の故障を回避する。

説明：機能テスト中，システムの規定の特性を達成しているかどうかを確認するために，レビューを実施

する。システムには，通常，期待する動作を十分に特徴付ける入力データを与える。出力を観察し，

出力の応答を，仕様で規定したものと比較する。仕様からの逸脱及び仕様の不完全さの表れを文書

化する。

マルチチャネルアーキテクチャ用として設計した電子構成部品の機能テストには，通常，前もっ

て妥当性確認した対になる構成部品と一緒に製造時にテストした構成部品を含める。さらに，隠さ

れたままになってしまう共通モードフォールトを明らかにするために，構成部品は同じバッチの他

のパートナーとなる構成部品と組み合わせて，製造時にテストすることを推奨する。

さらに，システムの作業容量は，十分とする必要がある。C.5.20を参照する。

参考文献：

Software Testing and Quality Assurance. K. Naik, P. Tripathy, Wiley Interscience, 2008, Print, ISBN:

9780471789116 Online ISBN: 9780470382844

The Art of Software Testing, Second Edition. G. Myers et al., Wiley & Sons, New York, 2004, ISBN

0471469122, 9780471469124

Practical Software Testing: A Process-oriented Approach. I. Burnstein, Springer, 2003, ISBN 0387951318,

9780387951317

Dependability of Critical Computer Systems 3. P. G. Bishop et al., Elsevier Applied Science, 1990, ISBN

1-85166-544-7

B.5.2 ブラックボックステスト

注記この技術及び手法は，JIS C 0508-2の表B.3，表B.5及び表B.6並びにJIS C 0508-3の表A.5，

表A.6，表A.7，表C.5，表C.6及び表C.7で引用されている。

目的：実際の機能条件の下で動的挙動をチェックする。機能的仕様に適合しないような故障を明らかに

し，有用性及び堅固さを評価する。

説明：システム又はプログラムの機能を，確立した判断基準に従って仕様から系統的に導き出した規定の

テストデータを用いて，規定の環境で実行する。これによって，システムの挙動が明らかになり，

仕様との比較が可能になる。テストを導くに当たって，システムの内部構造についての知識は全く

必要ない。目的は，機能ユニットが，仕様で要求している全ての機能を正しく実施するかどうかを

判定することである。等価クラスを形成する技術は，ブラックボックステストデータのための判定

基準の一例である。入力データ領域は，仕様の助けを借りて，特定の入力値範囲（等価クラス）に

小分割する。その後，テストケースを，次の全ての事項から形成する。

a) 許容範囲からのデータ

b) 非許容範囲からのデータ

C 0508-7：2017 (IEC 61508-7：2010)

c) 範囲限界からのデータ

d) 極値

e) a)〜d)の組合せ

様々なテスト活動（モジュールテスト，モジュール統合テスト及びシステムテスト）におけるテ

ストケースを選択するためには，他の判定基準も有効としてもよい。例えば，妥当性確認の枠組み

内のシステムテストの判定基準として，“極端な運用条件”に依拠してもよい。

参考文献：

Software Testing and Quality Assurance. K. Naik, P. Tripathy, Wiley Interscience, 2008, Print, ISBN:

9780471789116 Online ISBN: 9780470382844

Essentials of Software Engineering. Frank F. Tsui, Orlando Karam. Jones & Bartlett, 2006, ISBN 076373537X,

9780763735371

The Art of Software Testing, Second Edition. G. Myers et al., Wiley & Sons, New York, 2004, ISBN

0471469122, 9780471469124

Systematic Software Testing. Rick D. Craig, Stefan P. Jaskiel. Artech House, 2002, ISBN 1580535089,

9781580535083

B.5.3 統計的テスト

注記この技術及び手法は，JIS C 0508-2の表B.3，表B.5及び表B.6で引用されている。

目的：安全関連系の動的挙動をチェックし，その有用性及び堅固さを評価する。

説明：このアプローチでは，実際の運転上の入力の期待される統計的分布，すなわち，運転プロフィール

に従って選択した入力データを用いて，システム又はプログラムをテストする。

参考文献：

A discussion of statistical testing on a safety-related application. S Kuball, J H R May, Proc. IMechE Vol. 221

Part O: J. Risk and Reliability, Institution of Mechanical Engineers, 2007

Practical Reliability Engineering. P. O'Connor, D. Newton, R. Bromley, John Wiley and Sons, 2002, ISBN

0470844639, 9780470844632

Dependability of Critical Computer Systems 3. P. G. Bishop et al., Elsevier Applied Science, 1990, ISBN

1-85166-544-7

Dependability of Critical Computer Systems 1. F. J. Redmill, Elsevier Applied Science, 1988, ISBN

1-85166-203-0

B.5.4 フィールドの実績

注記1 この技術及び手法は，JIS C 0508-2の表B.3，表B.5及び表B.6で引用されている。

注記2 同様な手法はC.2.10，確率的アプローチは附属書Dを参照。ただし，両方ともソフトウェア

面に関するものである。

目的：別のアプリケーションによるフィールドの実績を，E/E/PE系統合時及び／又はE/E/PE系安全妥当

性確認時のフォールトを回避するための手法の一つとして用いる。

説明：多数の異なるアプリケーションにおいて，十分な期間にわたって，全く故障が起こらないか，又は

重要でないフォールトしか起こらないことが実績によって示されていて，本質的な変更をしていな

い構成部品又はサブシステムを用いる。特に，多数の実行可能な機能をもつ複雑な構成部品（例え

C 0508-7：2017 (IEC 61508-7：2010)

ば，オペレーティングシステム，集積回路）の場合，開発者は，どの機能がフィールドの実績によ

って実際にテストされているかに注意する必要がある。例えば，フォールト検出のための自己テス

トの通常手順を考慮する。運用期間中にハードウェアの故障が全く起こらない場合は，通常手順は，

そのフォールト検出機能を一度も実行しなかったことになるため，その手順は（実際に）試された

ということにはならない。

フィールドの実績を適用するためには，次の要求事項を満たす必要がある。

− 変更されていない仕様

− 10システムの異なるアプリケーションでの運用実績

− 105時間の運用実績及び1年間以上の使用履歴

注記3 適用分野規格では，これと異なる数値を規定していることがある。

フィールドの実績は，ベンダー及び／又は運用会社の文書類によって実証される。この文書類は，

少なくとも，次の内容を含む必要がある。

− ハードウェアのバージョン管理も含め，システム及びその構成部品の正しい呼び方

− 使用者及び適用時間

− 運用時間

− 証明のために調達されたシステム及びアプリケーションの選定手順

− フォールト検出及びフォールト登録並びにフォールト除去の手順

参考文献：

JIS C 5750-3-2:2008 ディペンダビリティ管理−第3-2部：適用の指針−フィールドからのディペンダ

ビリティデータの収集

注記対応国際規格：IEC 60300-3-2:2004，Dependability management−Part 3-2: Application guide−

Collection of dependability data from the field

Guidelines for Safe Automation of Chemical Processes. CCPS, AIChE, New York, 1993, ISBN-10:

0-8169-0554-1, ISBN-13: 978-0-8169-0554-6

B.6

E/E/PE系の安全妥当性確認

全般：E/E/PE安全関連系が，E/E/PE系の安全要求仕様及びE/E/PE系設計要求仕様に適合していることを

証明する。

B.6.1 環境条件の下での機能テスト

注記この技術及び手法は，JIS C 0508-2の表B.5で引用されている。

目的：安全関連系が，典型的な環境による影響に対して保護されているかどうかを評価する。

説明：システムを様々な環境条件（例えば，JIS C 60068の規格群又はIEC 61000の規格群の規格に従う。）

に置き，安全機能の信頼性（及び上記規格との両立性）について評価する。

参考文献：

JIS C 60068-1 環境試験方法−電気・電子−通則及び指針

注記対応国際規格：IEC 60068-1:1988，Environmental testing−Part 1: General and guidance及び

Amendment 1 (1992)

IEC 61000-4-1:2006，Electromagnetic compatibility (EMC)−Part 4-1: Testing and measurement techniques−

Overview of IEC 61000-4 series

C 0508-7：2017 (IEC 61508-7：2010)

Dependability of Critical Computer Systems 3. P. G. Bishop et al., Elsevier Applied Science, 1990, ISBN

1-85166-544-7

B.6.2 サージイミュニティのテスト

注記この技術及び手法は，JIS C 0508-2の表B.5及び表B.6で引用されている。

目的：安全関連系のピークサージ受容力をチェックする。

説明：システムに典型的なアプリケーションプログラムをロードし，全ての周辺線路（デジタルインタフ

ェース，アナログインタフェース，シリアルインタフェース，バス接続，電源など）に，標準ノイ

ズ信号を与える。定量的に示すために，サージ限界に注意深く近づけることが大切である。機能が

失敗した場合は，選択したクラスのノイズに適合していないということになる。

参考文献：

JIS C 61000-4-5:2009 電磁両立性−第4-5部：試験及び測定技術−サージイミュニティ試験

注記対応国際規格：IEC 61000-4-5:2005，Electromagnetic compatibility (EMC)−Part 4-5: Testing and

measurement techniques−Surge immunity test

C37.90.1-2002，IEEE Standard for Surge Withstand Capability (SWC) Tests for Relays and Relay Systems

Associated with Electric Power Apparatus

B.6.3 （不使用）

B.6.4 静的解析

注記この技術及び手法は，JIS C 0508-2の表B.5及び表B.6並びにJIS C 0508-3の表A.9（ソフトウ

ェア適合確認），表B.8，表C.9（決定論的安全度に関する特性−ソフトウェア適合確認）及び

表C.18で引用されている。

目的：テスト対象のシステムにおいて，故障に至る可能性がある決定論的原因フォールトを，運用の初期

又は何年にもわたる運用の後のいずれかにおいて，回避する。

説明：この系統的で，コンピュータ支援が可能なアプローチでは，問題とする要求事項（例えば，構造指

針，システム仕様及び機器データシート）に関し，確実に完全性及び一貫性があって，曖昧さがな

いようにするために，プロトタイプシステムの具体的な静特性を検査する。静的解析には，再現性

がある。静的解析は，十分に定義された完成段階に到達したプロトタイプに適用する。ハードウェ

ア及びソフトウェアに関する静的解析には，次の事例がある。

− データフローの一貫性解析（例えば，データオブジェクトが，あらゆる場所において同じ値と

して解釈されるかどうかのテスト）

− 制御フロー解析（例えば，経路の決定，アクセス不能コードの決定）

− インタフェース解析（例えば，様々なソフトウェアモジュール間の変数伝送の調査）

− 変数の作成，参照，削除など，疑わしいシーケンスを検出するデータフロー解析

− テストが個々の指針（例えば，沿面距離及び空間距離，組立距離，物理的装置の配置，機械的

な影響を受けやすい物理的装置，導入実績がある物理的装置だけの使用）に従っている。

参考文献：

Static Analysis and Software Assurance. D. Wagner, Lecture Notes in Computer Science, Volume 2126/2001,

Springer, 2001, ISBN 978-3-540-42314-0

C 0508-7：2017 (IEC 61508-7：2010)

An Industrial Perspective on Static Analysis. B A Wichmann, A A Canning, D L Clutterbuck, L A Winsborrow,

N J Ward and D W R Marsh. Software Engineering Journal., 69-75, March 1995

Dependability of Critical Computer Systems 3. P. G. Bishop et al,. Elsevier Applied Science, 1990, ISBN

1-85166-544-7

B.6.5 動的解析及びテスト

注記この技術及び手法は，JIS C 0508-2の表B.5及び表B.6並びにJIS C 0508-3の表A.5，表A.9，

表B.2（動的解析及び動的テスト），表C.5，表C.9及び表C.12（詳細特性−動的解析及びテス

ト）で引用されている。

目的：完成度の進んだ状態におけるプロトタイプの動的挙動を検査することによって，仕様機能の失敗を

検出する。

説明：安全関連系の動的解析は，意図した運用環境の典型的な入力データを，運用可能な状態に近い安全

関連系プロトタイプに用いることによって実施する。安全関連系において観察した挙動が，要求す

る挙動に適合する場合，解析は満足できるものといえる。安全関連系に故障がある場合，修正して，

その後，新しい運用バージョンを再解析する必要がある。

参考文献：

The Concept of Dynamic Analysis. T. Ball, ESEC/FSE ʼ99, Lecture Notes in Computer Science, Springer, 1999,

ISBN 978-3-540-66538-0

Dependability of Critical Computer Systems 3. P. G. Bishop et al,. Elsevier Applied Science, 1990, ISBN

1-85166-544-7

B.6.6 故障解析

注記この技術及び手法は，JIS C 0508-2の表B.5及び表B.6で引用されている。

B.6.6.1 故障モード及び影響解析（FMEA）

目的：システムの構成部品の考えられる全ての故障源を系統的に調査し，システムの挙動及び安全性に対

するこれらの故障の影響を求めることによって，システム設計を解析する。

説明：解析は，通常，技術者が集まって行う。システムの各構成部品を順次解析して，その構成部品につ

いての一連の故障モード，これらの原因及び影響（局所的及びシステム全体の水準），検出手順並

びに推奨事項を定める。推奨事項に従って行動する場合，推奨事項を，実施する是正処置として文

書化する。

参考文献：

JIS C 5750-4-3:2011 ディペンダビリティマネジメント−第4-3部：システム信頼性のための解析技

法−故障モード・影響解析（FMEA）の手順

注記対応国際規格：IEC 60812:2006，Analysis techniques for system reliability−Procedure for failure

mode and effects analysis (FMEA)

Risk Assessment and Risk Management for the Chemical Process Industry. H.R. Greenberg, J.J. Cramer, John

Wiley and Sons, 1991, ISBN 0471288829, 9780471288824

Reliability Technology. A. E. Green, A. J. Bourne, Wiley-Interscience, 1972, ISBN 0471324809

C 0508-7：2017 (IEC 61508-7：2010)

B.6.6.2 原因結果図（因果解析）

注記この技術及び手法は，JIS C 0508-3の表B.3（機能テスト及びブラックボックステスト），表B.4

（故障分析），表C.13（詳細特性−機能及びブラックボックステスト）及び表C.14（詳細特性

−故障分析）で引用されている。

目的：基本事象の組合せの結果としてシステム内で発展する可能性がある事象のシーケンスを，コンパク

トな図式の形で解析しモデル化する。

説明：この技術は，フォールトの木解析と事象の木解析との組合せとしてみなすことができる。重要（起

因）事象から始めて，何らかの動作の成功及び失敗を記述するYES/NOゲートを用いて，因果グラ

フを前方向にトレースしていく。これによって，事故又は克服した状況のいずれかに導く事象シー

ケンスを構築することができる。次に，各故障について因果グラフ（すなわち，フォールトの木）

を作成する。さらに，事故的状況から出発して，後方向に戻り，この事故を最上位事象とするグロ

ーバルフォールトの木を作成する。前方向では，事象から起こる可能性がある結果が求められる。

グラフは，頂点からの幾つかの支線に沿う，伝ぱ（播）のための条件を記述する頂点記号を含むこ

とができる。さらに，時間遅延も含むことができる。これらの条件は，フォールトの木を用いて説

明することもできる。図式を更に簡潔なものにするために，伝ぱ（播）の線を論理記号と組み合わ

せることができる。因果図で使用のための一連の標準記号を定義する。これらの図式は，フォール

トの木を作成するために，及びある重要な結果が起こる確率を計算するために用いることができる。

事象の木を作成するためにも用いることができる。

参考文献：

IEC 62502，Analysis techniques for dependability−Event tree analysis (ETA)

The Cause Consequence Diagram Method as a Basis for Quantitative Accident Analysis. B. S. Nielsen, Danish

Atomic Energy Commission, Riso-M-1374, 1971

B.6.6.3 事象の木解析（ETA）

注記この技術及び手法は，JIS C 0508-3の表B.4及び表C.14で引用されている。

目的：起因事象後にシステム内で進展する可能性がある事象のシーケンスを，図式の形でモデル化し，こ

れによって，重大な結果がどのように起こるかを示す。事象の木を何もないところから構築するこ

とは難しく，因果図を用いると役に立つ。

説明：図式の頂点において，起因事象の後に続く事象の進展に関わるシーケンス条件を書く。解析の到達

目標である起因事象の下から線を描き始め，シーケンスの最初の条件まで描く。そこで，図式は“は

い”及び“いいえ”の枝に分岐し，将来の事象が，条件によってどのように決まるかを記述する。

これらの枝のそれぞれについて，同様の方法で次の条件に続ける。ただし，全ての条件が，全ての

枝に関係があるとは限らない。一つの枝はシーケンスの終端まで継続し，このように構成した木の

各枝には，起こる可能性がある結果を表す。シーケンス内の条件が独立している場合，事象の木は，

シーケンス内の条件の確率及び条件数を基に，様々な結果の確率を計算するために用いることがで

きる。条件が100 %独立していることはめったにないので，こうした計算は慎重に検討し，熟練し

た解析者が実施する必要がある。

参考文献：

IEC 62502，Analysis techniques for dependability−Event tree analysis (ETA)

Risk Assessment and Risk Management for the Chemical Process Industry. H.R. Greenberg, J.J. Cramer, John

C 0508-7：2017 (IEC 61508-7：2010)

Wiley and Sons, 1991, ISBN 0471288829, 9780471288824

B.6.6.4 故障モード影響及び致命度解析（FMECA）

注記この技術及び手法は，JIS C 0508-3の表A.10，表B.4，表C.10及び表C.14で引用されている。

目的：どの構成部品が設計又は運転中に特別な注意及び適切な管理手段を必要とするかを決めるために，

単一故障が傷害，損傷又はシステム劣化に結び付く可能性がある構成部品の致命度のランク付けを

する。

説明：この手法はFMEAに類似するものであるが，致命度を示すための欄は一つ又は複数あり，多くの方

法でランク付けすることができる。最も労力を必要とする手法は，米国自動車技術者協会（SAE）

の規格，ARP 926に記載されている。この手順において，構成部品の致命度数は，クリティカルモ

ードにおける各100万回の運転中に予期される，特定の種類の故障の数によって示される。致命度

数は，九つのパラメータの関数であり，これらのパラメータの大半は，測定する必要がある。致命

度を求めるための非常に簡単な手法は，構成部品故障の確率に，発生する可能性がある損害を乗じ

る方法であり，この手法は，単純なリスク要因評価に似ている。

参考文献：

JIS C 5750-4-3:2011 ディペンダビリティマネジメント−第4-3部：システム信頼性のための解析技

法−故障モード・影響解析（FMEA）の手順

注記対応国際規格：IEC 60812:2006，Analysis techniques for system reliability−Procedure for failure

mode and effects analysis (FMEA)

Software criticality analysis of COTS/SOUP. P. Bishop, T. Clement, S. Guerra. In Reliability Engineering &

System Safety, Volume 81, Issue 3, September 2003, Elsevier Ltd., 2003

Software FMEA techniques. P.L.Goddard. In Proc Annual 2000 Reliability and Maintainability Symposium,

IEEE, 2000, ISBN: 0-7803-5848-1

B.6.6.5 フォールトの木解析（FTA）

注記この技術及び手法は，JIS C 0508-3の表B.4及び表C.14で引用されている。

目的：潜在危険若しくは重大な結果に至る事象，又はこれらの事象の組合せを解析する手助けをし，最上

位事象の確率計算をする。

説明：潜在危険又は重大な結果の直接的な原因となる可能性がある事象（“最上位事象”）から始め，その

原因を特定するために解析を実施する。この解析は，論理演算子（and，orなど）を用いて，数ス

テップを経て行う。中間原因についても同様に解析を進め，基本事象に戻って解析を停止する。

この手法は，図表を使うもので，フォールトの木を描くために標準化されている記号を用いる。

解析の終了時，フォールトの木は，基本事象（一般に，構成部品の故障）を最上位事象（全体シス

テムの故障）にリンクさせる論理的機能を表す。この技術は，主として，ハードウェアシステムの

解析のためのものであるが，このアプローチをソフトウェア故障解析に適用する試みもなされてい

る。この技術は，定性的には故障解析のために（故障シナリオの同定：ミニマルカットセット又は

プライムインプリカント），半定量的に（確率によるランキングシナリオによって）及び定量的に

は，最上位事象の確率計算をするために，用いることができる（C.6参照）。

参考文献：

JIS C 5750-4-4:2011 ディペンダビリティマネジメント−第4-4部：システム信頼性のための解析技

C 0508-7：2017 (IEC 61508-7：2010)

法−故障の木解析（FTA）

注記対応国際規格：IEC 61025:2006，Fault tree analysis (FTA)

From safety analysis to software requirements. K.M. Hansen, A.P. Ravn, A.P, V Stavridou. IEEE Trans Software

Engineering, Volume 24, Issue 7, Jul 1998

B.6.6.6 マルコフモデル

注記ハードウェア安全度を解析するために，信頼性ブロック図に対してこの技術を用いる場合は，

IEC 61508-6のB.1を参照。

目的：状態遷移図によってシステムの挙動をモデル化し，確率論的システムパラメータ（例えば，非信頼

性，非可用性，MTTF，MUT，MDTなど）を評価する。

説明：これは，直接，図表で表した有限状態オートマトン（B.2.3.2参照）である。ノード（円）は状態を

表し，ノード間のエッジ（矢印）は状態間で発生した遷移（故障，修理など）を表す。エッジは，

対応する故障率又は修理率で重み付けする。一様マルコフ過程の基本特性は，未来が現在によって

だけ左右されることである。状態Nからこれに続く状態N＋1に左右されるが，これ以前の状態N-1

からは独立している。このことは，モデルの全ての確率論的法則が指数関数的であることを暗示し

ている。

故障事象，故障状態及び故障率は，システムの精細な記述ができるような方法で詳述できる。例

えば，検出又は未検出故障，より大きな故障の発現などである。プルーフテストの間隔は，一つの

フェーズの終了時（例えば，プルーフテスト直前）の状態の確率を用いて，次のフェーズの初期状

態（例えば，プルーフテスト完了後の各種状態の確率）を計算できる，いわゆるマルチフェーズマ

ルコフ過程を用いて適切にモデル化してもよい。

マルコフ技術は，構成部品の故障及び修理によって，冗長性の水準が時間とともに変動する多重

システムのモデル化に適している。その他の古典的手法（例えば，FMEA，FTAなど）は，対応す

る確率を計算するための単純な組合せ公式がないので，システムのライフサイクル全体にわたる故

障の影響をモデル化するために，そのまま適用することができない。

最も単純な事例では，システムの確率を記述する形式を文献で簡単に見つけるか，又は手作業で

計算することができ，より複雑な事例を処理するための簡易化手法（すなわち，状態数を減らす方

法）も幾つかある。

いずれの場合も，数学的に，一様マルコフ図は，一定係数をもつ線形微分方程式の単純かつ共通

集合にすぎない。このことは長い間解析され，強力なアルゴリズムが開発されており，これらの式

を処理するために利用されている。したがって，モデルのサイズが増えた場合，各種コンピュータ

ソフトウェアパッケージに実装されている上記アルゴリズムを用いると，効率がよくなる。

図のサイズは，構成部品の個数に合わせて指数関数的に増加する。これは，いわゆる組合せ的爆

発である。したがって，この技術は，小さなシステムの場合に限り，近似化せずに利用できる。

非指数関数的法則を取り扱う場合（半マルコフモデル），モンテカルロシミュレーション（B.6.6.8

参照）を用いることが望ましい。

参考文献：

IEC 61165:2006，Application of Markov techniques

The Theory of Stochastic Processes. R. E. Cox and H. D. Miller, Methuen and Co. Ltd., London, UK, 1963

Finite MARKOV Chains. J. G. Kemeny and J. L. Snell. D. Van Nostrand Company Inc, Princeton, 1959

C 0508-7：2017 (IEC 61508-7：2010)

The Theory and Practice of Reliable System Design. D. P. Siewiorek and R. S. Swarz, Digital Press, 1982

Sécurisation des architectures informatiques. Jean-Louis Boulanger, Hermès−Lavoisier, 2009, ISBN:

978-2-7462-1991-5

B.6.6.7 信頼性ブロック図（RBD）

注記1 この技術及び手法は，IEC 61508-6の附属書Bで用いられている。

注記2 C.6.4も参照。

目的：システム又は業務の運用に成功するために，発生しなければならない事象と満足されなければなら

ない条件との組合せを，図式的な形でモデル化する。これは解析手法というよりは，表現手法であ

る。

説明：解析の目標を，ブロック，ライン及び論理的接合部からなる成果経路として表す。成果経路は，図

式の一方の側から出発し，ブロック及び接合部を経由して，図式の反対側まで続く。ブロックは条

件又は事象であり，経路は，条件が真である場合又は事象が発生した場合，ブロックを通過する。

経路が接合部に達し，接合部のロジックを満たした場合，先を続ける。頂点に達した場合，全ての

引出線に沿って進んでもよい。図式を1本以上の成果経路が通過している場合，解析目標は適切に

動作している。

RBDは，モデル化されたシステムの構造的表現である。これは，一種の電気回路といえる。つま

り，電流が入力から出力に流れる経路が見つかることは，モデル化されたシステムが適切に動作し

ていることを示しており，回路が遮断された場合は，モデル化されたシステムが故障したことを示

す。このことから，モデル化されたシステムの故障を引き起こす各故障（すなわち，RBDが“遮断”

されている場所）の組合せを表す，最小限の遮断セット（ミニマルカットセット）という概念が生

まれる。

数学的には，RBDはフォールトの木に似ている。これは，（故障しているか又は動作しているか

の）個別の構成部品の状態を，（故障しているか又は動作しているかの）システム全体に連結する論

理的機能を表す。したがって，計算は，フォールトの木について説明したものに類似している。

参考文献：

IEC 61078:2006，Analysis techniques for dependability−Reliability block diagram and boolean methods

Sécurisation des architectures informatiques. Jean-Louis Boulanger, Hermès−Lavoisier, 2009, ISBN:

978-2-7462-1991-5

B.6.6.8 モンテカルロシミュレーション

注記この技術及び手法は，IEC 61508-6の附属書Bで用いられている。

目的：解析手法が実用可能でない場合に，乱数を発生させて実世界現象をシミュレーションする。

説明：モンテカルロシミュレーションは，次の2種類の問題点を解決するために用いる。

− 確率論的。乱数を確率論的現象の発生に利用する。

− 決定論的。数学的に，等価の確率論的問題（例えば，積分計算）に転換する。

モンテカルロシミュレーションの原理は，乱数を用いて，検討対象のシステムの挙動上の機能的

及び非機能的モデルをアニメーション化することにある。こうした挙動モデルは，状態遷移モデル

（マルコフ図，ペトリネット，形式言語など）によって与えられる。モンテカルロシミュレーショ

ンは，統計的結果を導き出すための大きな統計的サンプルを生成するために実行する。

C 0508-7：2017 (IEC 61508-7：2010)

モンテカルロシミュレーションを用いる場合，バイアス，許容差又はノイズが妥当な値を確実に

もつように注意する必要がある。これらは，シミュレーションから容易に得られる信頼期間を通じ

て管理する。解析手法とは異なり，モンテカルロシミュレーションは自己近似を行う。モデル簡易

化のために，無視できるような事象は特定する必要もなく，ただ出現しないだけである。

モンテカルロシミュレーションの一般原理は，初めに記述したとおりの問題に取り組むのではな

く，むしろその問題を再記述及び再公式化して，得られる結果ができるだけ正確なものとなるよう

にすることである。

モンテカルロシミュレーションは，SIL計算及び信頼性データの不確かさを考慮する場合に利用

してもよい。現在のコンピュータでは，SIL4計算を簡単に行うことができる。

参考文献：

Monte Carlo Methods. J. M. Hammersley, D. C. Handscomb, Chapman & Hall, 1979

Sécurisation des architectures informatiques. Jean-Louis Boulanger, Hermès−Lavoisier, 2009, ISBN:

978-2-7462-1991-5

B.6.6.9 フォールトの木モデル

注記1 ハードウェア安全度解析でこの技術を利用する場合は，IEC 61508-6を参照。

注記2 フォールトの木は，安全妥当性確認手段として上記に記載している（B.6.6.5参照）。フォー

ルトの木は，故障解析及び確率論的計算でも広く利用されている。

目的：系統的なトップダウン図式（因果関係）アプローチによって，基礎事象（故障モード）を最上位事

象（望まれない事象）とリンクさせる論理的機能を構築する。

説明：これは，解析者がモデルを段階的に作成することを支援する解析手法であり，同時に，確率論的計

算をするための数学的モデルでもある。次のことを可能にする。

− 故障シナリオ（ミニマルカットセット又はプライムインプリカント）の特定及び分別による

定性的解析

− シナリオを，その発生確率に応じてランキングすることによる半定量的解析

− 最上位事象の確率を計算することによる定量的解析

RBD（信頼性ブロック図）と同様に，フォールトの木は，（故障しているか又は動作しているか

の）個別の構成部品の状態を，（故障しているか又は動作しているかの）システム全体に連結する論

理的（ブール）機能を表す。したがって，構成部品が独立している場合，確率論的計算は，論理的

機能に適用する確率の基礎特性を適用するだけで行ってもよい。基本的に，真の（すなわち，定数

の）確率だけで動作する静的モデルであるため，この確率論的計算はそれほど簡単ではない。時間

依存確率は，慎重に扱わなければならない。例えば，定期的にプルーフテストを受ける構成部品か

らなる安全系のPFDavgはそのまま計算することはできないし，連続モードで動作する安全系のPFH

の場合計算は更に困難になる。したがって，基本となる数学を十分に理解している信頼できる技術

者だけが，この手法で非可用性又はPFD，及び非信頼性又はPFHの計算をすることが望ましい。

計算は，非常に単純なフォールトの木の場合，手作業で行ってもよいが，過去50年にわたり，複

雑な論理式を扱うために多くのアルゴリズムが開発及び実装されてきた。現時点での最新技術とし

ては，論理式をコンピュータメモリにコンパクトにコード化する技術であるBDD（二分決定図）が

利用されている。現時点では，工業規模のシステムについて，近似化をせずに確率的計算を行うこ

とが可能な唯一の手法である。速さも十分であり，モンテカルロシミュレーションによって不確か

C 0508-7：2017 (IEC 61508-7：2010)

さを扱える。

参考文献：

JIS C 5750-4-4:2011 ディペンダビリティマネジメント−第4-4部：システム信頼性のための解析技

法−故障の木解析（FTA）

注記対応国際規格：IEC 61025:2006，Fault tree analysis (FTA)

B.6.6.10 一般化確率ペトリネットモデル（GSPN）

注記1 ハードウェア安全度解析でこの技術を利用する場合は，IEC 61508-6を参照。

注記2 B.2.3.3では，ペトリネットを準形式手法として述べている。ペトリネットは，ハードウェア

安全度についても効率的に利用されている。

目的：モンテカルロシミュレーションに対する効率的支援を与えるために，モデル化された実際のシステ

ムにできるだけ近い挙動をする機能的及び非機能的モデルを図式的に構築する。

説明：これは，B.2.3.3で説明した非同期有限状態オートマトンであるが，安全系の非機能的挙動をモデル

化する場合，準形式妥当性確認を行ったときの優れた特性は，もはや存在しなくなる。いわゆるプ

レース（円で図示）は可能性のある状態を，いわゆる遷移（長方形で図示）は発生する可能性のあ

る事象を表している。プレースの表示に加えて（B.2.3.3参照），遷移の妥当性確認（有効化）のた

めにメッセージ又は述語を用いてもよく，遷移の妥当性確認からその発生までに経過した遅れは決

定論的でも，確率的でもよい。このために，ペトリネットは“一般化確率”ペトリネットと呼ばれ

る。

ペトリネットは，モンテカルロシミュレーションの支援として，非常に効率のよい柔軟な挙動モ

デルを構成する（B.6.6.8参照）。いずれにしても，モンテカルロシミュレーション自体の正確さは，

常に分かっているので，これを除いても，他の手法の限界（依存性，組合せ的爆発，非指数関数的

法則など）の全てを克服している。現在のコンピュータでは，SIL4の評価でも，もはや問題とはな

らない。

参考文献：

IEC 62551，Analysis techniques for dependability−Petri net modelling (CD1)

Sécurisation des architectures informatiques. Jean-Louis Boulanger, Hermès−Lavoisier, 2009, ISBN:

978-2-7462-1991-5

B.6.7 最悪条件解析

注記この技術及び手法は，JIS C 0508-2の表B.5及び表B.6で引用されている。

目的：環境条件と構成部品許容差との好ましくない組合せから生じる，決定論的原因故障を回避する。

説明：システム及び構成部品の設計寸法における動作時受容能力を，理論に基づき調査又は計算する。環

境条件を，最大許容限度値に変更する。システムの最も重要な各応答を検査して，仕様と比較する。

B.6.8 拡張機能テスト

注記この技術及び手法は，JIS C 0508-2の表B.5及び表B.6で引用されている。

目的：仕様作成及び設計，又は開発フェーズ中の故障を明らかにする。まれな入力又は規定していない入

力があった場合の安全関連系の挙動をチェックする。

説明：拡張機能テストでは，まれにしか起こらないものと予想されている入力条件（例えば，重大故障）

C 0508-7：2017 (IEC 61508-7：2010)

又は安全関連系の仕様外の入力条件（例えば，正しくない操作）に対する，安全関連系の機能的挙

動を見直す。まれな入力条件の場合，安全関連系の観察した挙動を，仕様の内容と比較する。安全

関連系の応答を規定していない場合, 観察した応答によって工場の安全を維持できるかどうかを確

認することが望ましい。

参考文献：

Software Testing and Quality Assurance. K. Naik, P. Tripathy, Wiley Interscience, 2008, Print ISBN:

9780471789116 Online ISBN: 9780470382844

The Art of Software Testing, Second Edition. G. Myers et al., Wiley & Sons, New York, 2004, ISBN

0471469122, 9780471469124

Dependability of Critical Computer Systems 3. P. G. Bishop et al,. Elsevier Applied Science, 1990, ISBN

1-85166-544-7

B.6.9 ワーストケース状況テスト

注記この技術及び手法は，JIS C 0508-2の表B.5及び表B.6で引用されている。

目的：最悪の場合の解析中に，規定する事例をテストする。

説明：システム及び構成部品の設計寸法における動作時受容能力を，最悪の場合の条件下でテストする。

環境条件を，最大許容限度値に変更する。システムの最も重要な各応答を検査して，仕様と比較す

る。

B.6.10 フォールト挿入テスト

注記この技術及び手法は，JIS C 0508-2の表B.5及び表B.6で引用されている。

目的：システムハードウェアにおけるフォールトを導入又はシミュレーションして，その応答を文書化す

る。

説明：これは，ディペンダビリティを評価する定性的手法である。できる限り，フォールトの位置及び種

類，並びに故障をどのように導入するか，を記述するために，詳細な機能ブロック，回路及び配線

図を用いることが望ましい。記述する事項には，例えば，様々なモジュールが電源を遮断する可能

性があること，電源，バス又はアドレスラインが開放又は短絡する可能性があること，構成部品又

はこれらのポートが開放又は短絡する可能性があること，リレーが開閉しなかったり間違ったタイ

ミングで開閉したりする可能性があることなどである。結果として起こるシステム故障は，例えば，

JIS C 5750-4-3の表1（一連の一般的な故障モードの例）及び表2（最終的な影響に関する故障の厳

しさの分類の事例）に示されるように分類する。原則として，単一定常状態フォールトを導入する。

ただし，フォールトが内蔵診断テストによって検知できない場合，又はフォールトが顕在化しない

場合，そのフォールトをシステム内に残しておくことで，2番目のフォールトの影響を考慮するこ

とができる。フォールトの数が数百に及ぶことは簡単に起こる可能性がある。

この作業は多くの専門分野にわたるメンバーによるチームが実施し，これに，システムのベンダ

ーも出席して協議することが望ましい。深刻な結果を伴う平均故障間運用時間を，計算又は推定す

ることが望ましい。計算した時間が短い場合，部分改修を実施することが望ましい。

参考文献：

JIS C 5750-4-3:2011 ディペンダビリティマネジメント−第4-3部：システム信頼性のための解析技

法−故障モード・影響解析（FMEA）の手順

C 0508-7：2017 (IEC 61508-7：2010)

附属書C
（参考）

ソフトウェア安全度を達成するための技術及び手法の概要

（JIS C 0508-3参照）

C.1 一般

この附属書に記載する技術の概要が完全，又は全てを網羅しているとはみなさないことが望ましい。

C.2 要求事項及び詳細設計

注記関連技術及び手法は，B.2に記載がある。

C.2.1 構造化図表法

注記この技術及び手法は，JIS C 0508-3の表A.2及び表A.4で引用されている。

C.2.1.1 一般

目的：構造化手法の主な目的は，ライフサイクルの初期の部分に注意を向けることによって，ソフトウェ

ア開発の質を高めることである。これらの方法は，正確かつ直感的な手順と表記法（コンピュータ

で支援される）との両方によって達成することを目標としており，要求事項及び実装機能を論理的

順序及び構造化された方式で定め，文書化することを狙いとしている。

説明：構造化手法としては様々なものが存在する。従来のデータ処理及びトランザクション処理のために

設計されたものもあり，プロセス制御及びリアルタイムアプリケーション（安全を重視する傾向に

ある）のために設計されたものもある。UML（統一モデル化言語，C.3.12参照）は，構造化表記の

例を多く含んでいる。

構造化手法は，基本的に，問題又はシステムを体系的に認識して分割するための，“思考ツール”

である。これらの方法の主な特徴を，次に示す。

− 大きな問題を管理可能な段階に分割する，論理的思考順序

− 環境及び要求するシステムを含め，システム全体の解析及び文書化

− 要求するシステムにおけるデータ及び機能の分割

− チェックリスト，すなわち，解析を必要とする事項の分類表

− 高度な知識を必要としない処理−単純，直感的又は実用的なもの

− 意図したシステムの図解モデルの開発に大きな重点を置いていることが多く，方法全体に対す

るCASEツール支援をもつ。

問題及びシステムエンティティ（例えば，処理及びデータフロー）を解析し，文書化するための

支援表記法は厳密になる傾向があるが，これらのエンティティが実施する処理機能を表現するため

の表記法は，略式となる傾向がある。ただし，幾つかの方法では，（数学的に）形式的な表記法を部

分的に用いる（例えば，正規表現又は有限状態機械）。厳密さを増すことによって，誤解の範囲を狭

めるばかりでなく，自動処理の範囲を提供することとなる。

構造化表記法の別の利点は，その可視性であり，使用者は，強力ではあるが言明されていない知

識に照らして，仕様又は設計を直感的にチェックすることができる。

C 0508-7：2017 (IEC 61508-7：2010)

ここでは，幾つかの構造化手法について更に詳しく説明する。

参考文献：

Software Engineering for Real-time Systems. J. E. Cooling, Pearson Education, 2003, ISBN 0201596202,

9780201596205

Software Design. D. Budgen, Pearson Education, 2003, ISBN 0201722194, 9780201722192

C.2.1.2 要求事項の制約表現（CORE）

目的：全ての要求事項が決定され，かつ，表現されていることを確実にする。

説明：このアプローチは，顧客又はエンドユーザと解析者との間の食い違いの橋渡しをすることを目的と

している。この方法は，数学的に厳密なものではなく，情報の疎通を支援するものである。すなわ

ち，COREは，仕様作成のためというよりも，要求事項の表現のために設計する。このアプローチ

は構造化されており，表現を様々な段階を経て詳細にする。CORE方法は，問題を広い観点から扱

うことを奨励し，システムを用いることになる環境についての知識及び様々な種類の使用者の種々

の観点を導入する。COREは，“基本設計”からの逸脱を認識するための指針及び方法を含む。逸脱

は訂正するか，又は明白に識別して文書化することができる。したがって，仕様は完全でなくても

よいが，未解決の問題及びリスクが高いエリアを検出し，後の設計において考慮する必要がある。

参考文献：

Software Engineering for Real-time Systems. J. E. Cooling, Pearson Education, 2003, ISBN 0201596202,

9780201596205

Requirements Engineering. E. Hull, K. Jackson, J. Dick. Springer, 2005, ISBN 1852338792, 9781852338794

C.2.1.3 ジャクソンシステム開発（JSD）

目的：リアルタイムシステムに特別な重点を置き，要求事項からコードまでのソフトウェアシステムの開

発をカバーする開発方法。

説明：JSDは，開発者がシステム機能の基礎となる実世界の挙動をモデル化し，要求する機能を決め，モ

デルに挿入し，結果としての仕様を目標環境において実現可能な仕様に変換する，段階的な開発手

順である。したがって，この手順では，従来の仕様作成，設計及び開発のフェーズを含むが，トッ

プダウンでない点で，従来の方法とは多少異なる立場をとる。

さらに，この方法では，実世界において製作するシステムに関わるエンティティを発見する初期

の段階に大きな重点を置き，これらのエンティティをモデル化して，これらのエンティティに何が

起こる可能性があるかをモデル化することに重点を置く。まず，“実世界”についてのこの解析がな

され，モデルを作成し，システムに要求する機能がこの実世界モデルにどれくらい適合するかを求

めるために，システムに要求する機能を解析する。結果としてのシステムモデルを，モデル内の全

てのプロセスの構造化記述を付け加えることによって補強し，その後，モデル全体を目標ソフトウ

ェア及びハードウェア環境で運用するプログラムに変換する。

参考文献：

Systems Analysis and Design. D. Yeates, A. Wakefield. Pearson Education, 2003, ISBN 0273655361,

9780273655367

An Overview of JSD. J. R. Cameron. IEEE Transactions on Software Engineering, SE-12, No. 2, February 1986

C 0508-7：2017 (IEC 61508-7：2010)

C.2.1.4 リアルタイムヨードン法

目的：リアルタイムシステムの仕様作成及び設計。

説明：この技術の根拠となっている開発手法では，開発中のシステムの3段階の展開を仮定している。第

1段階は，“基本的モデル”，すなわち，システムによって要求する挙動を説明するモデルの形成に

関わる。第2段階は，実装した場合，要求する挙動を具象化する構造及び機構を説明する実装モデ

ルの形成に関わる。第3段階は，ハードウェア及びソフトウェアのシステムの実際の形成に関わる。

これらの3段階は，おおまかには，従来の仕様作成，設計及び開発フェーズに対応するが，各段階

において開発者がモデル化活動に関わるということに重点が置かれる点が従来のものとは異なる。

基本的モデルを，次の二つの部分で構成する。

− システムとその環境間との境界についての説明，及びシステムが応答しなければならない外部

事象についての説明を含む環境モデル

− 事象に応答してシステムが行う形態変化を説明するスキーム，及びシステムが応答するために

保持しなければならないデータに関する記述を含む挙動モデル

さらに，実装モデルを個々の処理のプロセッサへの割当て及び処理のソフトウェアモジュールへ

の分解を取り扱う，サブモデルに分割する。

これらのモデルを得るために，この技術では，他のよく知られた多数の技術，すなわち，データ

フロー図，変換グラフ，構造化英語，状態遷移図及びペトリネットを組み合わせる。さらに，この

方法は，要求するシステム設計を，紙面上又は作成するモデルから機械的にシミュレーションする

技術を含む。

参考文献：

Real-time Systems Development. R. Williams. Butterworth-Heinemann, 2006, ISBN 0750664711,

9780750664714

Structured Development for Real-Time Systems (3 Volumes). P. T. Ward and S. J. Mellor. Yourdon Press, 1985

C.2.2 データフロー図

注記この技術及び手法は，JIS C 0508-3の表B.5及び表B.7で引用されている。

目的：プログラムを通過するデータフローを図の形で表す。

説明：データフロー図は，データ入力をどのように出力に変換するかを文書化するものであり，図式中の

各段階は明瞭な変換を表す。

データフロー図は，三つの構成部品で構成する。

− 注釈付き矢印変換部を出入りするデータフローを表し，注釈にはデータが何のデータである

かを記載する。

− 注釈付きバブル変換部を表す円，注釈には変換内容を記載する。

− 演算子（and，xor）これらの演算子は，注釈付き矢印をリンクするために用いる。

データフロー図中の各バブルは，入力を直ちに出力に変換する独立ブラックボックスと考えるこ

とができる。主な利点の一つは，これらの変換をどのように実装するかについての仮定を全く設け

ることなく，バブルが変換を示すことである。純粋なデータフロー図は，制御情報又はシーケンス

情報も含まないが，これは，リアルタイムヨードン法（C.2.1.4を参照）におけるように，表記法へ

のリアルタイム拡張によって補う。

データフロー図の作成のためには，システム入力を考慮して，システム出力に向かって作業する

C 0508-7：2017 (IEC 61508-7：2010)

ことが最善のアプローチである。各バブルは，明瞭な変換を表す必要がある。すなわち，出力は，

何らかの形で，入力とは異なっていることが望ましい。図式の全般的構造を決めるための規則は全

くなく，データフロー図を作成することは，システム設計の創造的な面の一つである。全ての設計

と同様に，これは，最終的な図式を作成するまでに初期の試みを何段階にもわたって詳細化する反

復手順である。

参考文献：

Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN

0321313798, 9780321313799

Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577,

9783827372574

JIS X 0121:1986 情報処理用流れ図・プログラム網図・システム資源図記号

注記対応国際規格：ISO 5807:1985，Information processing−Documentation symbols and conventions

for data, program and system flowcharts, program network charts and system resources charts

ISO/IEC 8631:1989，Information technology−Program constructs and conventions for their representation

C.2.3 構成図

注記この技術及び手法は，JIS C 0508-3の表B.5で引用されている。

目的：プログラムの構成を図の形で示す。

説明：構成図は，データフロー図を補足する表記法である。構成図はプログラミングシステム及び部品の

階層を記述し，これを木構造として図に表す。構成図は，データフロー図の要素を，プログラム単

位の階層としてどのように実装できるかを文書化する。

構造化チャートは，プログラムモジュール間の関係を，これらのユニットを起動する順序につい

ての情報は一切含まずに示す。構造化チャートは，次の四つの記号を用いて描く。

− モジュールの名前を付けた長方形

− 構造化を形成する，これらの長方形を接続する線

− 構造化チャート内の要素とやりとりできるデータの名前を付けた，丸付き矢印（白丸）（通常，

丸付き矢印は，チャート中の長方形を結ぶ線に平行に描く。）

− 構造化チャート内の一つのモジュールから他のモジュールへ送られる制御信号の名前を付け

た，丸付き矢印（黒丸）。丸付き矢印は，同様に二つのモジュールを結ぶ線に平行に描く。

自明ではないデータフロー図から，多数の異なる構造化チャートが導き出されることもある。

データフロー図は，システムにおける情報と機能との間の関係を表す。構造化チャートは，シス

テムの要素をどのように実装するか，その方法を表す。これらの技術は表現方法が異なるが，両方

ともシステムの全体像を表現している。

参考文献：

Software Design & Development. G. Lancaster. Pascal Press, 2001, ISBN 1741251753, 9781741251753

Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN

0321313798, 9780321313799

Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577,

9783827372574

C 0508-7：2017 (IEC 61508-7：2010)

C.2.4 形式手法

注記この技術及び手法は，JIS C 0508-3の表A.1，表A.2，表A.4及び表B.5で引用されている。

C.2.4.1 一般

目的：数学に基づく方法によるソフトウェアの開発。これには，形式的設計及び形式的なコーディング技

術が含まれる。

説明：形式手法は，システムの仕様作成，設計又は実装における一部の段階において，システムを記述し

ようとする手法である。結果としての記述は，様々なクラスの矛盾又は不正確さを検出するために

数学的解析を受けることができるように，厳密な表記法で表す。さらに，この記述は，場合によっ

ては，コンパイラによるソースプログラムの文法検査に似た厳密さで，機械によって解析したり，

記述対象のシステムの挙動の種々の面を表示するためにアニメーション化したりすることもでき

る。アニメーションを用いる場合，システムの規定された動作に対する認識が高まるため，形式的

に規定された要求事項に加えて，実際の要求事項に適合しているかどうかの確認ができる。

形式手法は，一般に，表記法（一般に，用いられている離散数学のある形式），その表記法による

記述を導き出す技術，及びその記述を種々の正確さを表す要素についてチェックするための各種解

析形式を提供する。

幾つかの形式手法，すなわち，CCS，CSP，HOL，LOTOS，OBJ，時相論理，VDM及びZについ

て，概要をC.2.4.2〜C.2.4.9で説明する。他の技術，例えば，有限状態機械及びペトリネット（附属

書B参照）は，これらの技術が使用時にどのくらい厳密に数学的根拠に準拠しているかによって，

形式手法とみなすこともできる。

参考文献：

Formal Specification: Techniques and Applications. N.Nissanke, Springer-Verlag Telos, 1999, ISBN

1852330023

The Practice of Formal Methods in Safety-Critical Systems. S. Liu, V. Stavridou, B. Dutertre, J. Systems

Software 28, 77-87, Elsevier, 1995

Formal Methods: Use and Relevance for the Development of Safety-Critical Systems. L. M. Barroca, J. A.

McDermid, The Computer Journal 35 (6), 579-599, 1992

How to Produce Correct Software−An Introduction to Formal Specification and Program Development by

Transformations. E. A. Boiten et al, The Computer Journal 35 (6), 547-554, 1992

C.2.4.2 通信システムの計算法（CCS）

目的：CCSは，同時通信プロセスのシステムの挙動を説明し，その理由付けをする手法である。

説明：CCSは，システムの挙動に関する数学的計算法である。システム設計を，順次に又は並行して動作

する独立プロセスのネットワークとしてモデル化する。プロセスは，ポート（CSPのチャネルに似

たもの）を経て通信することができ，通信は両方のプロセスの準備ができているときだけ行う。非

決定論をモデル化することができる。システム全体の高水準抽象説明（トレースとして知られてい

る。）から始め，その通信プロセスの全挙動が全システムに要求する全挙動となる通信プロセスの

構成へと，システムの段階的詳細化を実施することが可能である。同様に，ボトムアップ方式で作

業すること，プロセスを組み合わせること，及び結果としてのシステムの特性を構成規則に関連す

る推論規則を用いて推定することが可能である。

C 0508-7：2017 (IEC 61508-7：2010)

参考文献：

Communication and Concurrency. R. Milner. Pearson Education, 1989, ISBN 9780131150072

C.2.4.3 通信順次プロセス（CSP）

目的：CSPは，同時ソフトウェアシステム，すなわち，同時に動作する通信プロセスのシステムの仕様作

成のための技術である。

説明：CSPは，プロセスのシステムの仕様用の言語を提供し，プロセスの実装がシステムの仕様を満たし

ていることを検証するための証拠（トレース，すなわち事象の許容シーケンスとして記述される。）

を提供する。

システムを，順次に又は並行して構成する独立プロセスのネットワークとしてモデル化する。各

プロセスでは，プロセスで起こる可能性のある挙動の全てを明確に説明できる。プロセスは，チャ

ネルを経て通信する（同期する，又はデータを交換する。）ことができ，通信は両方のプロセスの準

備ができているときだけ行う。事象の相対タイミングはモデル化することができる。

CSPの背景にある理論は，INMOSトランスピュータのアーキテクチャに直接組み込まれており，

OCCAM言語を用いることによって，CSP規定システムをトランスピュータのネットワーク上にお

いて直接実装することが許される。

参考文献：

Communicating Sequential Processes: The First 25 Years. A. Abdallah, C. Jones, J. Sanders (Eds.). Springer,

2004, ISBN 3540258132, 9783540258131

C.2.4.4 上位論理（HOL）

目的：これは，ハードウェア仕様作成及び適合確認の基礎として意図している形式言語である。

説明：HOLとは，具体的な論理表記法及びこの表記法の機械支援システムのことであり，これらは両方

とも，ケンブリッジ大学のコンピュータ研究所で開発されたものである。この論理表記法は，ほと

んどチャーチの単純型理論から採用されており，機械支援システムは，コンピュータ処理可能な機

能の論理（LCF）システムに基づいている。

参考文献：

Higher-Order Computational Logic. J. Lloyd. In Computational Logic: Logic Programming and Beyond,

Lecture Notes in Computer Science, Springer Berlin / Heidelberg, 2002, ISBN 978-3-540-43959-2

C.2.4.5 時間的順序仕様記述用言語（LOTOS）

目的：LOTOSは，同時通信プロセスのシステムの挙動を説明し，その理由付けをする手法である。

説明：LOTOSは，CCSに基づくものであり，関連代数学CSP及びCIRCAL（回路計算法）からの追加の

特徴をもつ。これは，データ構造及び値表現の取扱いにおけるCCSの弱点を，CCSと抽象データ

型言語ACT ONEの特質とを組み合わせることによって克服している。LOTOSのプロセス記述の特

質は，抽象データ型の記述のために他の形式手法とともに用いることができる。

参考文献：

Model Checking for Software Architectures. R. Mateescu. In Software Architecture, Lecture Notes in Computer

Science, Springer Berlin / Heidelberg, 2004, ISBN 978-3-540-22000-8

ISO 8807:1989，Information processing systems−Open Systems Interconnection−LOTOS−A formal

C 0508-7：2017 (IEC 61508-7：2010)

description technique based on the temporal ordering of observational behaviour

C.2.4.6 OBJ

目的：実装に先立って，正確なシステム仕様に実装使用者フィードバック及びシステム妥当性確認を提供

する。

説明：OBJは，代数的仕様記述言語である。使用者は，要求事項を代数方程式の形で規定する。システム

の挙動面又は構造面は，抽象データ型（ADT）への作用の形で規定されている。ADTは，作用の挙

動は目に見えるが，実装の詳細は“隠されている”ADAパッケージに似ている。

OBJ仕様作成及びその後の段階的実装は，他の形式アプローチと同じ形式的証明技術に従う。さ

らに，OBJ仕様の作成における特徴はこれが実行可能であることから，仕様自体からシステムの妥

当性確認を直接的に達成できる。実行とは，本質的には特定の出力値を得るまで継続する等式への

代入（書換え）によって機能を評価することである。この実行可能性によって，計画中のシステム

のエンドユーザは，根拠となっている形式仕様作成技術に精通する必要なしに，システムの仕様作

成段階において，将来できあがるシステムの“概観”を得ることができる。

他の全てのADT技術の場合と同様に，OBJは，順次システムに，又は同時システムの順次面だ

けに適用できる。OBJは，小規模及び大規模工業用の両方の仕様作成に用いられてきている。

参考文献：

Software Engineering with OBJ: Algebraic Specification in Action. J. Goguen, G. Malcolm. Springer, 2000,

ISBN 0792377575, 9780792377573

C.2.4.7 時相論理

目的：安全性及び運転時の要求事項の直接的表現，並びにこれらの特性が後に続く開発段階においても維

持されることの形式実証。

説明：標準第一階の述語論理は，時間の概念を含まない。時相論理は，モーダル演算子（例えば，“今後

は”及び“最終的に”）を追加することによって，一階論理を拡張する。これらの演算子は，シス

テムについてのアサーションを修飾するために用いることができる。例えば，安全特性は，“今後

は”を保持することが必要になるかもしれないが，他の望まれるシステム状態では，他のある開始

状態から“最終的に”達成することが必要になるかもしれない。時間的論理式は，状態（挙動）の

シーケンスとして解釈される。何が“状態”を構成するかは，選択された記述水準によって異なる

が，システム全体，システムの一つの要素又はコンピュータプログラムのことを指すことがある。

定量化されている時間間隔及び制約条件は，時相論理では積極的に取り扱わない。絶対タイミン

グは，状態記述の一部として，追加の時間状態を作成することによって処理する必要がある。

参考文献：

Mathematical Logic for Computer Science. M. Ben-Ari. Springer, 2001, ISBN 1852333197, 9781852333195

C.2.4.8 VDM，VDM++ −ウィーン開発方法

目的：順次（VDM）及び同時リアルタイム（VDM++）プログラムの系統的な仕様作成及び実装。

説明：VDMは数学に基づく仕様作成技術であり，仕様の正確さを証明することができる方法によって実

装を詳細化するための技術である。

仕様作成技術は，モデルに基づくものである。すなわち，システム状態は，不変量（述部）を記

C 0508-7：2017 (IEC 61508-7：2010)

述する基礎となる集合論的構造の形でモデル化し，その状態に基づく動作は，動作の事前条件及び

事後条件をシステム状態の形で規定することによってモデル化する。システム不変量が維持されて

いることは，動作によって証明することができる。

仕様の実装は，システム状態を目標言語によるデータ構造の形で具体化すること，及び動作を目

標言語によるプログラムの形で詳細化することによって行う。具体化及び詳細化段階では，正確さ

を確立する証明義務が生じる。これらの義務を実行するかどうかは，設計者が決める。

VDMは，主として仕様作成段階において用いられているが，ソースコードに至る設計及び実装

段階において用いることもできる。これは，順次に構造化したプログラム，又は同時システムの順

次プロセスだけに適用できる。

VDMのオブジェクト指向同時リアルタイム拡張版であるVDM++は，ISO言語VDM-SL及びオ

ブジェクト指向言語であるスモールトークに基づく形式仕様記述言語である。

VDM++は，使用者が同時リアルタイムシステムをオブジェクト指向方式で形式規定することがで

きるように，広範囲の構造を提供する。VDM++において，完全な形式仕様を，クラス仕様の集合，

及び状況に応じて，作業空間で構成する。

VDM++のリアルタイム条件を，次に示す。

− メソッド本体に，現時点及びメソッド呼出時点の両方を表すため一時的表現式を与える。

− 適切な実装のための運用時間の上限（又は下限）を規定するためにメソッドに，時限後置表現

を加えてもよい。

− 時間連続変数を導入する。仮定及び影響の節を設けることによって，これらの時間の関数間の

関係（例えば，微分方程式）を指定してもよい。この特徴は，時間連続環境において動作する

システムの要求事項の規定に非常に有用であることが分かっている。詳細化手順は，これらの

種類のシステムについて，離散的ソフトウェアソリューションに至る。

参考文献：

ISO/IEC 13817-1:1996，Information technology−Programming languages, their environments and system

software interfaces−Vienna Development Method−Specification Language−Part 1: Base language

Systematic Software Development using VDM. C. B. Jones. Prentice-Hall. 2nd Edition, 1990

Conformity Clause for VDM-SL, G. I. Parkin and B. A. Wichmann, Lecture Notes in Computer Science 670,

FME'93 Industrial-Strength Formal Methods, First International Symposium of Formal Methods in Europe.

Editors: J. C. P. Woodcock and P. G. Larsen. Springer Verlag, 501-520

C.2.4.9 Z

目的：Zは，順次システムのための仕様記述言語表記法であり，開発者が，仕様に対して，Z仕様から実

行可能なアルゴリズムまでの正確さを証明可能な方法で進めることができる設計技術である。

Zは，主として仕様作成段階において用いられるが，仕様作成から設計及び実装に進めるための

方法が考案されている。Zは，データ指向順次システムの開発に最適である。

説明：仕様作成技術は，VDMと同様，モデルに基づくものである。すなわち，システム状態を，不変量

（述部）を記述する基となる集合論的構造の形でモデル化し，その状態に基づく動作は，動作の事

前条件及び事後条件をシステム状態の形で規定することによってモデル化する。システム不変量が

維持されていることは動作によって証明することができ，これによって，システム不変量の一貫性

を実証することができる。仕様の形式部分は，詳細化によって仕様を構造化することを可能とする

C 0508-7：2017 (IEC 61508-7：2010)

スキームに分割できる。

典型としては，Z仕様は形式Zと自然言語による非形式説明文とを混合したものである（形式Z

は読みやすさのために簡潔すぎる場合があるため，その目的を説明する必要があり，一方で非形式

の自然言語は曖昧かつ不正確になりやすい場合がある。）。

Zは，VDMとは違って，完全な方法というよりも表記法である。ただし，Zと結合して用いるこ

とができる関連方法（Bと呼ばれる。）が開発されている。B方法は，段階的詳細化の原理に基づい

ている。

参考文献：

Formal Specification using Z, 2nd Edition. D. Lightfoot. Palgrave Macmillan, 2000, ISBN 9780333763278

The B-Method. S. Schneider. Palgrave Macmillan, 2001, ISBN 9780333792841

C.2.5 防御的プログラミング

注記この技術及び手法は，JIS C 0508-3の表A.4で引用されている。

目的：プログラムの実行中に異常な制御フロー，データフロー又はデータ値を検出し，これらに対して事

前に決めた認容できる方法で対応するプログラムを作成する。

説明：プログラミング中，制御又はデータ異常がないかどうかをチェックするために，多くの技術を用い

ることができる。これらの技術は，誤ったデータ処理の可能性を低減するために，システムのプロ

グラミング中，最初から最後まで系統的に適用することができる。

防御的技術には，二つの重なり合うエリアがある。固有のエラーセーフソフトウェアは，これ自

体の設計上の欠点を包容するように設計する。これらの欠点は，設計若しくはコーディングの間違

い又は誤った要求事項による場合がある。幾つかの防衛的技術を，次に示す。

− 変数は，範囲をチェックすることが望ましい。

− 可能な場合，値は確からしさをチェックすることが望ましい。

− 手順のためのパラメータは，プロシジャー入口において，型，サイズ及び範囲をチェックする

ことが望ましい。

これらの最初の三つの推奨事項は，プログラムが取り扱う数値が，プログラム機能及び変数の物

理的意味の両面から妥当なものであることを確実にするための手助けとなる。

読取専用パラメータと読み書きパラメータとは，分離することが望ましく，これらへのアクセス

をチェックすることが望ましい。関数は，全てのパラメータを読取専用として扱うことが望ましい。

文字列定数は，書込可能でないことが望ましい。このことは，偶発的な上書き又は変数の誤用を検

出する手助けとなる。

フォールトトレラントソフトウェアは，これ自体の環境における故障を“予期”するか，又は公

称条件若しくは期待条件の範囲外で用いた場合，事前に定めた方法で動くように設計する。技術と

しては，次の事項を含む。

− 物理的重要性をもつ入力変数及び中間変数は，確からしさについてチェックすることが望まし

い。

− 出力変数の影響を，チェックすることが望ましく，そのチェックは，できる限り，関連システ

ム状態変化の直接的観察によることが望ましい。

− ソフトウェアは，予期されるハードウェアの存在及びアクセス可能性の両方を含む，ソフトウ

ェアの構成をチェックすることが望ましく，さらに，ソフトウェア自体が完全であることをチ

C 0508-7：2017 (IEC 61508-7：2010)

ェックすることが望ましい。このことは，保全手順後の完全性を維持するために特に重要であ

る。

防御的プログラミング技術の幾つか，例えば，制御フローシーケンスチェックは，外部故障にも

対処する。

参考文献：

Software Engineering for Real-time Systems. J. E. Cooling, Pearson Education, 2003, ISBN 0201596202,

9780201596205

Dependability of Critical Computer Systems: Guidelines Produced by the European Workshop on Industrial

Computer Systems, Technical Committee 7 (EWICS TC7, Systems Reliability, Safety, and Security).

Elsevier Applied Science, 1989, ISBN 1851663819, 9781851663811

C.2.6 設計及びコーディング基準

注記この技術及び手法は，JIS C 0508-3の表A.4で引用されている。

C.2.6.1 一般事項

目的：適合確認を容易にし，チーム主体の客観的アプローチを奨励し，更に標準設計手法を施行する。

説明：順守する規則は，プロジェクトの初めにおいて，参加者間で合意する。これらの規則を，用いる設

計開発方法（例えば，JSP，ペトリネットなど）及び関連するコーディング基準（C.2.6.2参照）で

構成する。

これらの規則は，開発，適合確認，評価及び保全を容易にするために定められる。したがって，

これらの規則では，利用可能なツール，特に解析及びリバースエンジニアリングツールを考慮す

ることが望ましい。

参考文献：

IEC 60880:2006，Nuclear power plants−Instrumentation and control systems important to safety−Software

aspects for computer-based systems performing category A functions

Verein Deutscher Ingenieure. Software-Zuverlassigkeit−Grundlagen, Konstruktive Massnahmen,

Nachweisverfahren. VDI-Verlag, 1993, ISBN 3-18-401185-2

C.2.6.2 コーディング基準

注記この技術及び手法は，JIS C 0508-3の表B.1（設計及びコーディング基準）で引用されている。

目的：安全関連コードのエラーの可能性を低減し，安全関連コードの適合確認を容易にする。

説明：次の表に示す原則は，安全関連コーディング規則が（どのようなプログラミング言語であっても），

どのようにJIS C 0508-3の規定要求事項に適合させ，かつ，どのように参考の“望ましい特性”（附

属書F参照）を実現するかを示すものである。利用可能な支援ツールを考慮することが望ましい。

C 0508-7：2017 (IEC 61508-7：2010)

JIS C 0508-3

要求事項及び推奨事項

コーディング基準の提案

モジュラーアプローチ
（表A.2の7及び表A.4の4）

ソフトウェアモジュールサイズの制限（表B.9の1）及びソフトウェアの複雑さ制御
（表B.9の2）。次に例を示す。
・ “ローカル”サイズ及び複雑さ測定及び限度の規定（モジュールの場合）
・ “グローバル”複雑さ測定及び限度の規定（全体的なモジュール組織）
・パラメータ数制限及び固定数のサブプログラムパラメータ（表B.9の4）

情報隠蔽及びカプセル化（表B.9の3）。例えば，特定の言語機能を用いる動機付け。

完全に定義したインタフェース（表B.9の6）。次に例を示す。
・関数の引数及び戻り値についての明確な規定
・関数の実行前後の状態，アサーション及びデータ型不変数の明確な規定をもつ故

障アサーションプログラミング（表A.2の3a）及びデータの適合確認（7.9.2.7）

コードの理解しやすさ
・コードの理解しやすさの

促進（7.4.4.13）

・読取りやすさ，理解しや

すさ，テスト可能性
（7.4.6）

有意で，明確な名称を推進する命名規則。例えば，混同を招きやすい名称の回避（例
えば，IOとl0）。

数値に付与する記号命名

ソースコード文書化手順及び指針（7.4.4.13）。次に例を示す。
・理由及び意味の説明（何がだけでなく）
・警告
・副次的影響

可能な場合，ソースコードに次の情報を含める（7.4.4.13）。
・法人名（例えば，会社，作者など）
・説明
・入力及び出力
・構成管理履歴
（モジュラーアプローチも参照）

適合確認及びテストのしやす
さ
・適合確認及びテストを容

易にする（7.4.4.13）。

・設計又はプログラミング

のミスの検出を容易にす
る（7.4.4.10）。

・形式的適合確認（表A.5

の10）

・形式的証明（表A.9の1）

次による。
・事前条件及び事後条件をチェックするための“クリティカル”ライブラリ関数に

対するラッパー

・特定のデータ要素又は機能の使用に対する制限を表現できる，言語機能を用いる

動機付け［例えば，const（定数）］

・支援ツールによる適合確認の場合，選択したツールの限度に適合するための規則

（より基本的目標の妨げとならない場合に限る。）

・再帰の制限使用（表B.1の6）及び循環従属に関するその他の形式の使用の制限
（モジュラーアプローチも参照）

C 0508-7：2017 (IEC 61508-7：2010)

JIS C 0508-3

要求事項及び推奨事項

コーディング基準の提案

規定した設計との適合性の静
的適合確認（7.9.2.12）

規定した設計概念又は制限事項の実装に対するコーディング指針。次に例を示す。
・最大周期を保証した周期的挙動に対するコーディング指針（表A.2の13a）
・タイムトリガアーキテクチャに対するコーディング指針（表A.2の13b）
・最大応答時間を保証したイベント駆動アーキテクチャに対するコーディング指

針（表A.2の13c）

・静的に決定した最大反復回数のループ（繰返し動作設計の無限ループの場合を除

く。）

・静的資源配分（表A.2の14）及び動的オブジェクトの回避（表B.1の2）に対す

るコーディング指針

・共有資源へのアクセスの静的同期化に対するコーディング指針（表A.2の15）
・割込の制限使用に適合するためのコーディング指針（表B.1の4）
・動的変数を回避するためのコーディング指針（表B.1の3a）
・動的変数の組込みに関するオンラインチェック（表B.1の3b）
・使用する他のプログラミング言語との互換性を確実にするためのコーディング

指針（7.4.4.10）

設計によるトレーサビリティを容易にする指針

言語サブセット（表A.3の3）
・安全でない言語機能を禁

止する（7.4.4.13）

・定義した言語機能だけを

用いる（7.4.4.10）

・構造化プログラミング

（表A.4の6）

・厳密に型付けしたプログ

ラミング言語（表A.3の2）

・非自動型変換（表B.1の8）

非構造化設計に導くような言語機能の排除。次に例を示す。
・ポインタの制限使用（表B.1の5）
・再帰の制限使用（表B.1の6）
・ C言語的なユニオンの使用の制限
・ Ada又はC++言語的な例外の使用の制限
・高級言語のプログラムの中に非構造化制御フローがない（表B.1の7）。
・サブルーチン及び関数における1入口点及び1出口点（表B.9の5）
・自動型変換がない。
・関数の引数及び戻り値からの自明でない副次的影響の使用の制限（例えば，静的

変数）

条件及びアサーションの全ての形態の評価に副次的影響がない。

コンパイラ固有の機能の使用の制限又は文書化した場合だけの使用。

誤解する可能性がある言語構造の使用の制限。

上記で制限したにもかかわらず，これらの言語機能を用いる場合に適用する規則。

C 0508-7：2017 (IEC 61508-7：2010)

JIS C 0508-3

要求事項及び推奨事項

コーディング基準の提案

正しいプログラミングの方法
（7.4.4.13）

該当する場合，次による。
・浮動小数点表記を必要に応じて，正しい順序で評価することを確実にするための

コーディング指針（例えば，“a−b＋c”は必ずしも“a＋c−b”にはならない。）

・浮動小数点比較の場合，厳密な等号ではなく，不等号（未満，以下，超及び以上）

だけを用いる。

・条件付きコンパイル及び“前処理”に関する指針
・戻り条件（成功又は失敗）の系統的チェック

実行可能なコードの作成の文書化，及び可能な場合は，自動化（メイクファイル）。

関数の引数及び戻り値からの自明ではない副次的影響の回避。こうした副次的影響が
存在する場合，これらを文書化するための指針。

演算優先順位が絶対的に明白でない場合，括弧でくくる。

発生しないと考えられる条件も捉える（例えば，C言語“switch”の“default”の場
合）。

重要モジュールに対して“ラッパー”を用いること。特に，事前条件，事後条件及び
戻り条件のチェック。

既知コンパイラエラー，及びコンパイラ評価によって設定されていた制限に適合する
ためのコーディング指針。

C.2.6.3 動的変数又は動的オブジェクトの禁止

注記この技術及び手法は，JIS C 0508-3の表A.2及び表B.1で引用されている。

目的：次の事項を排除する。

− メモリの望ましくない又は検出できないオーバレイ

− （安全関連）実行中のリソースのボトルネック

説明：この手法の場合，動的変数及び動的オブジェクトの実行時にメモリを割り当てて，絶対アドレスを

決める。割り当てたメモリの値及びそのアドレスは，割当ての瞬間におけるシステムの状態によっ

て異なる。すなわち，割り当てたメモリの値は，コンパイラ又は他のいかなるオフラインツールに

よってもチェックできない。

動的変数及びオブジェクトの個数，並びに新しい動的変数又はオブジェクトを割り当てるための

既存の自由メモリ空間は，割当ての瞬間におけるシステムの状態によって異なるため，変数又はオ

ブジェクトを割り当てるか又は用いるときにフォールトが起こる可能性がある。例えば，システム

が割り当てる位置における空きメモリの量が不十分である場合，他の変数のメモリ内容が意図せず

に上書きされる可能性がある。動的変数又はオブジェクトを用いない場合，これらのフォールトは

回避できる。

動的挙動を一部の静的解析によって正確に予測できないため（すなわち，プログラム運用に先立

って予測できない。），予測可能なプログラムの運用を保証できない場合，動的オブジェクトの使用

を制限する必要がある。

C 0508-7：2017 (IEC 61508-7：2010)

C.2.6.4 動的変数又は動的オブジェクト作成中のオンラインチェック

注記1 この技術及び手法は，JIS C 0508-3の表B.1で引用されている。

目的：動的変数及びオブジェクトに割り当てるメモリが，割当ての実行時に空きメモリであることを確認

し，実行時間中の動的変数及び動的オブジェクトの割当てが，既存の変数，データ又はコードに影

響を及ぼさないことをチェックする。

説明：この手法の場合，動的変数は，実行時にメモリに割り当てられ，絶対アドレスが決まる変数である

（この意味での変数は，オブジェクトインスタンスの属性でもある。）。

動的変数又は動的オブジェクトをメモリに割り当てる前に，（例えば，スタックあふれを回避する

ため，）メモリが確実に空きメモリであることをハードウェア又はソフトウェアによってチェックす

る。割当てができない場合（例えば，割り当てるアドレスにおけるメモリが十分でない場合），適切

な処置が必要である。一つの動的変数又は動的オブジェクトを用いた後（例えば，サブルーチンを

出た後），その動的変数又は動的オブジェクトに割り当てた全てのメモリを開放する必要がある。

注記2 代替手法は，メモリが全ての場合において十分であることを統計的に実証することであ

る。

C.2.6.5 割込の制限使用

注記この技術及び手法は，JIS C 0508-3の表B.1で引用されている。

目的：ソフトウェアを適合確認可能及びテスト可能に維持する。

説明：割込の使用を，制限することが望ましい。割込は，システムを簡略化する場合に用いてもよい。ソ

フトウェアによる割込処理は，実行中の関数の重要な部分（例えば，タイムクリティカル，データ

変更にとってクリティカル）の間，禁止することが望ましい。割込を用いる場合は，割込を禁止す

る最大時間を計算できるように，割込可能でない部分の最大演算時間を規定することが望ましい。

割込の使用及びマスキングは，完全に文書化することが望ましい。

C.2.6.6 ポインタの制限使用

注記この技術及び手法は，JIS C 0508-3の表B.1で引用されている。

目的：ポインタの範囲及び型を最初にチェックせずに，データにアクセスすることによって起こる問題を

回避する。ソフトウェアのモジュラーテスト及び適合確認を支援し，故障の影響を制限する。

説明：アプリケーションソフトウェアにおいて，ポインタ演算は，ポインタデータの型及び値の範囲が（ポ

インタ基準が正しいアドレス空間内にあることを確実にするために）アクセス前にチェックする場

合に限り，ソースコード水準において用いてもよい。アプリケーションソフトウェアのタスク間通

信は，タスク間の直接参照によって実施しないことが望ましい。データ交換は，オペレーティング

システムを経て実施することが望ましい。

C.2.6.7 再帰の制限使用

注記この技術及び手法は，JIS C 0508-3の表B.1で引用されている。

目的：サブルーチン呼出しの適合確認不可能かつテスト不可能な使用を避ける。

説明：再帰を用いる場合，再帰の深さを予測可能にする明確な基準が必要である。

C 0508-7：2017 (IEC 61508-7：2010)

C.2.7 構造化プログラミング

注記この技術及び手法は，JIS C 0508-3の表A.4で引用されている。

目的：実用上，プログラムを実行せずに解析することが可能であるように，プログラムを設計及び実装す

る。プログラムは，統計的にテスト不可能な挙動を，絶対最小量だけ含んでもよい。

説明：構造上の複雑さを最小限に抑えるために，次の原則を適用することが望ましい。

− プログラムを適切に小さいソフトウェアモジュールに分割し，これらのモジュールはできるだ

け連結を断ち，全ての相互作用が明白であることを確実にする。

− 構造化構成体，すなわち，シーケンス，反復及び選択を用いてソフトウェアモジュール制御フ

ローを構成する。

− ソフトウェアモジュールを通過すると考えられる経路の数を小さく保ち，入力及び出力のパラ

メータの関係をできるだけ単純に保つ。

− 複雑な分岐を避け，特に，高水準言語における無条件ジャンプ（goto）は避ける。

− 可能な場合は，ループ制約及び分岐を入力パラメータに関係付ける。

− 分岐及びループ決定の基礎として複雑な計算を用いることを避ける。

上記のアプローチを支援するプログラミング言語の特徴は，効率が絶対優先である場合（例えば，

安全クリティカルシステム）を除き，更に効率的である（と主張できる）他の特徴に対して優先し

て用いることが望ましい。

参考文献：

Concepts in Programming Languages. J. C. Mitchell. Cambridge University Press, 2003, ISBN 0521780985,

9780521780988

A Discipline of Programming. E. W. Dijkstra. Englewood Cliffs NJ, Prentice-Hall, 1976

C.2.8 情報隠蔽及びカプセル化

注記この技術及び手法は，JIS C 0508-3の表B.9（モジュラーアプローチ）で引用されている。

目的：データ又は手順への意図しないアクセスを防止し，これによって，良好なプログラム構造を支援す

る。

説明：全てのソフトウェア構成要素からの大域的なアクセスが可能なデータは，これらの要素のいずれか

が，不本意な又は不正な改変をする可能性がある。これらのデータ構造が変化した場合は，コード

の詳細な調査及び広範囲な部分改修が必要になる場合がある。

情報隠蔽は，このような困難を最小限に抑えるための一般的なアプローチである。重要なデータ

構造は“隠して”，定義済みの一連のアクセス手順によってだけ操作を可能とする。こうすることに

よって，残りのソフトウェアの機能的挙動に影響を及ぼすことなく，内部構造を部分改修すること

ができ，又は手順を更に追加することが許される。例えば，名前ディレクトリが，“挿入”，“削除”

及び“検索”というアクセス手順をもつとする。この場合，これらの手順を用いて，残っているソ

フトウェアの論理的挙動に影響を及ぼすことなく，（例えば，異なるルックアップ方法を用いるため

又はハードディスクに名前を格納するために）アクセス手順及び内部データ構造のプログラムを書

き換えることができる。

この関係においては，抽象データタイプの概念を用いることが望ましい。この概念の直接的支援

がない場合は，抽象化が不注意によって壊されていないことをチェックする必要があるかもしれな

い。

C 0508-7：2017 (IEC 61508-7：2010)

参考文献：

Concepts in Programming Languages. J. C. Mitchell. Cambridge University Press, 2003, ISBN 0521780985,

9780521780988

On the Design and Development of Program Families. D. L. Parnas. IEEE Trans SE-2, March 1976

C.2.9 モジュラーアプローチ

注記この技術及び手法は，JIS C 0508-3の表A.4及び表B.9で引用されている。

目的：ソフトウェアシステムを，システムの複雑さを制限するために小さな理解できる部分に分解する。

説明：モジュラーアプローチ又はモジュール化は，ソフトウェアプロジェクトの設計，コーディング及び

保全の各フェーズについての幾つかの規則を含む。これらの規則は，設計時に採用する設計方法に

よって異なる。ほとんどの方法は，次の規則を含む。

− 一つのソフトウェアモジュール（又は，同様に，サブプログラム）は，明確に定義した実行す

るタスク又は関数を一つだけもつことが望ましい。

− ソフトウェアモジュール間の接続は，制限し厳密に定義することが望ましく，一つのソフトウ

ェアモジュールの一貫性は強力でなければならない。

− サブプログラムの集合を作成し，この集合は幾つかの水準のソフトウェアモジュールを備える

ことが望ましい。

− サブプログラムのサイズは，ある規定値，典型的な値としては2〜4スクリーンサイズに制限す

ることが望ましい。

− サブプログラムは，唯一の入口点及び唯一の出口点をもつことが望ましい。

− ソフトウェアモジュールは，インタフェースを介して他のソフトウェアモジュールと通信する

ことが望ましい。大域変数又は共通変数を用いる場合，これらを十分に構造化し，アクセスを

制御し，各インスタンスにおいて正当化して用いることが望ましい。

− ソフトウェアモジュールの全てのインタフェースは，完全に文書化することが望ましい。

− ソフトウェアモジュールのインタフェースは，この関数に必要なパラメータだけを含むことが

望ましい。ただし，この推奨事項は，プログラミング言語がデフォルトのパラメータをもつか，

又はオブジェクト指向アプローチを採用する可能性があるため，複雑になることがある。

参考文献：

The Art of Software Testing, second edition. G. J. Myers, T. Badgett, T. M. Codd, C. Sandler, John Wiley and

Sons, 2004, ISBN 0471469122, 9780471469124

Software Engineering for Real-time Systems. J. E. Cooling, Pearson Education, 2003, ISBN 0201596202,

9780201596205

Concepts in Programming Languages. J. C. Mitchell. Cambridge University Press, 2003, ISBN 0521780985,

9780521780988

C.2.10 信頼性確認及び検証済みソフトウェア要素の使用

注記この技術及び手法は，JIS C 0508-3の表A.2，表C.2，表A.4及び表C.4で引用されている。

目的：ソフトウェア設計及び要素の，新しいアプリケーションごとの大幅な妥当性確認又は設計し直しが

必要になることを避ける。形式的又は厳格に検証されていないが，かなりの運用履歴がある設計を

活用する。別のアプリケーションで検証済みであり，多数の適合確認証拠がある既存のソフトウェ

C 0508-7：2017 (IEC 61508-7：2010)

ア要素を活用する。

説明：この手法は，ソフトウェア要素が決定論的設計フォールト及び／又は運用上の故障がほとんどない

ことを検証するものである。

最も初歩的な部分から複雑なシステムを構築することは，一般に不可能である。一般には，既に

開発されて相当程度有用な機能を提供していて，更に新システムの相当部品の実装に再利用できる

ような主要サブアセンブリ（“要素”，JIS C 0508-4の3.4.5及び3.2.8参照）を利用することが必要

となる。

良好に設計され，構成されたPE系は，明確に区別ができて，明確に規定された方法で相互に作

用し合う幾つかのソフトウェア要素でできあがっている。このような，複数のアプリケーション内

で再利用することができる一般的に応用可能なソフトウェア要素のライブラリを構築することで，

複数のアプリケーションで共有できる設計の妥当性を確認するために必要な，多くの資源とするこ

とができる。ただし，安全関連アプリケーションの場合，これら既存の要素を組み込んだ新システ

ムが要求される安全度をもち，既存の要素の不正な挙動によって安全性が損なわれないという十分

な信頼性があることが重要である。

次の二つの観点によって，既存の要素の挙動が正確に分かっているという信頼性を得ることがで

きる。

− 要素の包括的な運用履歴を解析して，この要素が“実績による使用”をもつことを実証する。

− 要素の挙動について収集した多数の適合確認証拠を評価して，要素が，この規格の要求事項を

満たすかどうかを判断する。

C.2.10.1 実績による使用

“実績による使用”（JIS C 0508-4の3.8.18参照）が，信頼性確認済みのソフトウェア要素が必要な安全

度を実現していることの十分な根拠となることは非常にまれである。多くの実行可能な機能をもつ複雑な

要素（例えば，オペレーティングシステム）の場合，要素のどの機能が実際に十分な使用実績をもつか確

定することは不可欠である。例えば，フォールトを検出するための自己テストルーチンを備えている場合，

運用期間中に故障が全く起こらなかった場合，フォールト検出のための自己テストルーチンに使用実績が

あると考えることはできない。

ソフトウェア要素は，次の判定基準を満たしている場合，使用実績があると判断できる。

− 仕様を変更していない。

− 種々のアプリケーションにおけるシステムがある。

− 1年以上の使用履歴がある。

− 運用時間は，安全度水準又は適切な作動要求数に従っている。非安全関連故障率が次の値を下回って

いることを実証することができる。

・信頼水準95 %で作動要求（年間）当たり10−2未満であることの実証には，300回の運用（年間）を

必要とする。

・信頼水準99.9 %で作動要求（年間）当たり10−5未満であることの実証には，690 000回の運用（年

間）を必要とする。

注記1 上記の推定値の根拠となる数学的側面は，附属書Dを参照。類似の手法及び統計的アプロ

ーチは，B.5.4も参照。

− 運用経験を積むことによって作動要求プロフィールに対するソフトウェア要素の挙動についての知識

C 0508-7：2017 (IEC 61508-7：2010)

が増すことを確実にするために，運用経験の全てをソフトウェア要素の機能についての既知作動要求

プロフィールに関連付ける必要があるが，これを満足している。

− 安全関連故障がない。

注記2 一つの状況において安全上重大でないかもしれない故障が，他の状況において安全上重大

である場合，又はその逆の場合がある。

ソフトウェア要素が判定基準を満たしていることの適合確認を可能にするために，次の事項を文書化す

る必要がある。

− バージョン番号を含め，各システム及びその要素の正しい識別（ソフトウェア及びハードウェアの両

方について）

− 使用者の特定及び使用時間

− 運用時間

− 使用者利用システム及びアプリケーションの選択のための手順

− 故障を検出し登録するための手順及びフォールトを取り除くための手順

C.2.10.2 多数の適合確認証拠の評価

既存のソフトウェア要素（JIS C 0508-4の3.2.8参照）は，既に存在するものであって，現行のプロジェ

クト又は安全関連系（SRS）を対象として特に開発されたものではない。既存ソフトウェアは市販品かも

しれないし，どこかの組織が旧製品又は旧システムのために開発したかもしれない。既存ソフトウェアは，

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

既存ソフトウェアを組み込んだ新システムの安全度を評価する場合，既存の要素の挙動を判断するため

に多数の適合確認証拠が必要となる。これらの証拠は，（1）要素供給業者自身がもつ，この要素の開発プ

ロセスの文書及び記録，又は（2）新規安全関連系の開発業者若しくは第三者が行った追加認証活動によっ

て作成若しくは補足作成されたものの場合がある。これらの証拠は，ソフトウェア要素の潜在的な再利用

可能性及び限度を定義する，“準拠項目に対する安全マニュアル”である。

いずれの場合も，再利用する要素に全面的又は部分的に左右される特定安全機能の完全性の評価を可能

にする，準拠項目に対する安全マニュアルというものが存在する（存在しない場合は作成する。）必要があ

る。このマニュアルがない場合，要素を安全関連で再利用する根拠がないという，安全側に立った結論が

導かれる可能性がある（これは，この要素が個別の事例で証拠が不十分だったというだけで，どのような

場合にも使用できないということではない。）。

この規格は，準拠項目に対する安全マニュアルの内容について，具体的な要求事項を用意している［JIS

C 0508-2の附属書D（準拠項目に対する安全マニュアル），JIS C 0508-3の附属書D（適合品目の安全マニ

ュアル−ソフトウェア要素の追加要求事項）並びにJIS C 0508-3の7.4.2.12及び7.4.2.13参照］。

準拠項目に対する安全マニュアルは，内容を非常に簡単に示すものとして，次の点を取り上げている。

− 要素の設計が既知であり，文書化している。

− 要素が，文書化したテストによる系統的アプローチを用いて適合確認及び妥当性確認を受けており，

要素の設計及びコードの全ての部分の見直しを行っている。

− 要素の未使用及び不要な機能によって，新システムがその安全要求事項を満たすことを妨げない。

− 新システム中の要素の，全ての信ぴょう（憑）性のある故障メカニズムを特定し，適切な軽減手段を

実装している。

新システムの機能安全評価によって，再利用した要素は，要素の準拠項目の安全マニュアルの証拠及び

C 0508-7：2017 (IEC 61508-7：2010)

想定によって根拠を与えた能力の範囲を厳守して適用したことを確認する必要がある。

参考文献：

Component-Based Software Development: Case Studies. Kung-Kiu Lau. World Scientific, 2004, ISBN

9812388281, 9789812388285

Software Reuse and Reverse Engineering in Practice. P. A. V. Hall (ed.), Chapman & Hall, 1992, ISBN

0-412-39980-6

Software criticality analysis of COTS/SOUP.P.Bishop, T.Clement, S.Guerra. In Reliability

Engineering & System Safety, Volume 81, Issue 3, September 2003, Elsevier Ltd., 2003

C.2.11 トレーサビリティ

目的：ライフサイクル段階の間で整合性を維持する。

説明：ライフサイクル活動から生まれたソフトウェアが，安全関連系の適切な運用に関する要求事項を確

実に満たせるように，ライフサイクル段階の間の整合性を確保することが重要である。ここでの重

要なコンセプトが，諸活動の間の“トレーサビリティ”という概念である。これは，基本的に，（1）

前段階で行った決定を後の段階で適切に実装しているか（前方トレーサビリティ），及び（2）後の

段階で行った決定が前段階の決定によって実際に必要かつ必須であるかを確認する影響解析であ

る。

前方トレーサビリティは，広い意味で，要求事項がライフサイクルの後の段階で適切に適応され

ているかをチェックすることである。前方トレーサビリティは，安全ライフサイクルの次の幾つか

の時点で役に立つ。

− システム安全要求事項から，ソフトウェア安全要求事項まで。

− ソフトウェア安全要求仕様から，ソフトウェアアーキテクチャまで。

− ソフトウェア安全要求仕様から，ソフトウェア設計まで。

− ソフトウェア設計仕様から，モジュール統合テスト仕様まで。

− ハードウェア又はソフトウェア統合に関するシステム及びソフトウェア設計要求事項から，ハ

ードウェア又はソフトウェア統合テスト仕様まで。

− ソフトウェア安全要求仕様から，ソフトウェア安全妥当性確認計画まで。

− ソフトウェア安全要求仕様から，ソフトウェア部分改修計画（再適合確認及び再妥当性確認を

含む。）まで。

− ソフトウェア設計仕様から，ソフトウェア適合確認（データ適合確認を含む。）計画まで。

− JIS C 0508-3の箇条8（機能安全評価）の要求事項から，ソフトウェア機能安全評価計画まで。

後方トレーサビリティは，広い意味で，全ての実装（広い状況で解釈して，コードの実装に限定

しない。）の決定が，相当の要求事項によって明確に根拠を与えていることをチェックすることであ

る。こうした根拠がない場合，実装は，安全関連系をより複雑化させる一方で，必ずしも真の要求

事項を適用していない不要なものが含まれる。後方トレーサビリティは，安全ライフサイクルの次

の幾つかの時点で役に立つ。

− 安全要求事項から，認識した安全ニーズ

− ソフトウェアアーキテクチャから，ソフトウェア安全要求仕様まで

− ソフトウェア詳細設計から，ソフトウェアアーキテクチャまで

− ソフトウェアコードから，ソフトウェア詳細設計まで

C 0508-7：2017 (IEC 61508-7：2010)

− ソフトウェア安全妥当性確認計画から，ソフトウェア安全要求仕様まで

− ソフトウェア部分改修計画から，ソフトウェア安全要求仕様まで

− ソフトウェア適合確認（データ適合確認を含む。）計画から，ソフトウェア設計仕様まで

参考文献：

Requirements Engineering. E. Hull, K. Jackson, J. Dick. Springer, 2005, ISBN 1852338792, 9781852338794

C.2.12 ステートレスソフトウェア設計（又は限定ステート設計）

注記この技術及び手法は，JIS C 0508-3の表A.2で引用されている。

目的：ソフトウェアの挙動の複雑さを制限する。

説明：一連のトランザクションを処理するソフトウェアプログラムを考える。つまり，これは一連の入力

を受け取り，各入力に応答して出力を生成する。プログラムは，その履歴の一部又は全部を“ステ

ート”の形で記憶し，将来の入力に対する応答方法を計算するときに，このステートを考慮に入れ

る場合がある。

特定の入力に対するプログラムの出力が，完全にこの入力によって決まる場合，プログラムは非

記憶，又はステートレスといわれる。各入力又は出力のトランザクションは，これ以前のトランザ

クションによって影響を受けず，かつ，特定の入力が必ずこれに伴った出力を生成するという意味

で，完成したものである。

これに対して，出力の計算においてプログラムがその特定の入力及び記憶しているステートの両

方を考慮する場合，異なる状況がことによって，同じ入力でも異なる出力を与えることがあるので，

プログラムはより複雑な挙動をする可能性がある。特定の入力に対する応答は，入力を受け取る状

況（すなわち，以前の入力及び出力）によって左右されることがある。一部のアプリケーション（特

に，通信）では，プログラムの挙動がステートの変化に対して非常に影響を受けやすいことがある

ので，これが不注意によるものか悪意をもって意図されたものかに関係なく，特に考慮する必要が

ある。

ステートレス（又は限定ステート）設計は，ソフトウェア設計でステート情報の利用を回避又は

最小限に抑えることでソフトウェア挙動の潜在的複雑さを最小限にしようとする一般的なアプロー

チである。

参考文献：

Introduction to Automata Theory, Languages, and Computation (3rd Edition). J. Hopcroft, R. Motwani, J.

Ullman, Addison-Wesley Longman Publishing Co, 2006, ISBN: 0321462254

Stateless connections. T. Aura, P Nikander. In Proc International Conference on Information and

Communications Security (ICICSʼ97), ed Yongfei Han. Springer, 1997, ISBN 354063696X,

9783540636960

C.2.13 オフライン数値解析

注記この技術及び手法は，JIS C 0508-3の表A.9で引用されている。

目的：数値計算の正確さを確実にする。

説明：数値の不正確さは，理想的関数及び数値を有限表現した結果，数学的関数の計算の中で発生するこ

とがある。関数をフーリエ系列のような無限系列の有限項目数で近似化した場合，切捨て誤差が生

じる。実際のコンピュータにおいて，実数を有限的な正確さをもって表示した場合，丸め誤差が生

C 0508-7：2017 (IEC 61508-7：2010)

じる。最も単純な計算以外のことを浮動小数点法で実行しようとする場合，計算の妥当性をチェッ

クして，アプリケーションが要求している正確さを実際に実現できることを確実にする必要がある。

参考文献：

Guide to Scientific Computing. P.R. Turner. CRC Press, 2001, ISBN 0849312426, 9780849312427

C.2.14 メッセージシーケンスチャート

注記この技術及び手法は，JIS C 0508-3の表B.7及び表C.17で引用されている。

目的：要求事項及びソフトウェアアーキテクチャ設計を含むソフトウェア開発の早い設計段階で，システ

ム要求事項を把握する支援をする。UML（C.3.12参照）では，この表記に対して，“システムシー

ケンス図”という名称を用いる。

説明：メッセージシーケンスチャートは，システムのアクター（設計段階に応じて，アクターは，人，コ

ンピュータシステム又はソフトウェア要素若しくはオブジェクトに対するものでもよい。）の間で

起こる通信という点から，システムの挙動を記述する図式的記述である。各アクターについて，垂

直の“ライフライン”を図上に引き，ライフライン間で矢印をメッセージを表すために用いる。メ

ッセージを受領したときのアクションは，ボックスとして，図に任意に示すことができる。一連の

シナリオ（望ましい挙動及び望ましくない挙動の両方を記述したもの）をまとめて，必要なシステ

ム挙動の仕様とする。これらのシナリオは複数の用途をもつ。これらによって，エンドユーザに対

してシステム挙動を実演することができる。これらによって，システムの実行可能な実装に変換す

ることができる。これらによって，テストデータのベースを形成することができる。

UMLは，分岐シナリオ及びループシナリオを可能にし，これによって，表記をよりコンパクトに

するような選択及び反復などの構成要素の形で，メッセージシーケンスチャートの本来のコンセプ

トに対する拡張要素を含んでいる。サブ図式を定義することもでき，複数の上位シーケンス図から

参照できる。タイマ及び外部事象も表現することができる。

参考文献：

“Message Sequence charts”, D. Harel, P. Thiagarajan. In UML for Real: Design of Embedded Real-Time

Systems. ed. L. Lavagno. Springer, 2003, ISBN 1402075014, 9781402075018

JIS X 4170 オープン分散処理−統一モデル化言語（UML）1.4.2版

注記対応国際規格：ISO/IEC 19501:2005，Information technology−Open Distributed Processing−

Unified Modeling Language (UML) Version 1.4.2

C.3 アーキテクチャ設計

C.3.1 フォールト検出

注記この技術及び手法は，JIS C 0508-3の表A.2で引用されている。

目的：故障に至る可能性があるシステムのフォールトを検出し，故障の結果を最小限に抑えるための対策

の基礎を提供する。

説明：フォールト検出は，あるシステムが［チェックの対象である（サブ）システム内のフォールトによ

って発生する］誤り状態になっていないかどうかを確認する活動である。フォールト検出の主な目

標は，正しくない結果の影響を阻止することである。並列要素と組になって動作し，自己の結果が

正しくないと検出したとき制御を放棄するシステムであるため，セルフチェックと呼ばれる。

C 0508-7：2017 (IEC 61508-7：2010)

フォールト検出は，冗長性（主として，ハードウェアフォールトを検出する。JIS C 0508-2の附

属書Aを参照。）及び多様性（ソフトウェアフォールト）の原理に基づく。結果の正確さを判定す

るためには，ある種の票決が要求される。適用できる特殊な手法としては，アサーションプログラ

ミング，Nバージョンプログラミング及びダイバースモニタ技術がある。ハードウェア用には，追

加のセンサ，制御ループ，誤り検査コードなどを導入する。

フォールト検出は，異なる段階での値領域又は時間領域，特に，物理的（温度，電圧など），論理

的（誤り検出コード），機能的（アサーション）又は外部的（確からしさ確認），におけるチェック

によって行う。これらの確認の結果は格納しておき，故障追跡を可能とするために，影響を受ける

データと結び付けてもよい。

複雑なシステムは，サブシステムで構成する。フォールト検出，診断及びフォールト補償の効率

は，フォールトの伝ぱ（播）に影響を及ぼすサブシステム間の相互作用の複雑さによって異なる。

サブシステムが小さいほど，詳細なフォールト診断（誤り状態の検出）が可能となるため，フォ

ールト診断は最小サブシステム水準において適用することが望ましい。

企業規模の統合情報システムでは，診断テスト情報を含め，安全システムの状態を，定期的に，

他の管理システムへ送信することができる。異常を検出した場合，これを表示して，危険状態が増

大する前に是正手段を起動するために用いることができる。最後に，このような異常を文書化して

おくことによって，本当に事象が起こった場合に，その後の調査の手助けとすることができる。

参考文献：

Dependability of Critical Computer Systems 1. F. J. Redmill, Elsevier Applied Science, 1988, ISBN

1-85166-203-0

C.3.2 エラー検出

注記この技術及び手法は，JIS C 0508-3の表A.2で引用されている。

目的：影響を受けやすい情報のエラーを検出して訂正する。

説明：nビットの情報に対して，r個のエラーを検出して訂正することを可能とする，kビットのコード化

ブロックを生成する。例として，ハミングコード及び多項コードの二つのタイプがある。

安全関連系において，あらかじめ定められた割合のエラーだけしか正しく訂正されないため，不

良データは，通常，訂正しようと試みるよりも廃棄することが必要になるということに留意するこ

とが望ましい。

参考文献：

Fundamentals of Error-correcting Codes, W. Huffman, V. Pless. Cambridge University Press, 2003, ISBN

0521782805, 9780521782807

C.3.3 故障アサーションプログラミング

注記この技術及び手法は，JIS C 0508-2の表A.17並びにJIS C 0508-3の表A.2及び表C.2で引用さ

れている。

目的：システムの安全上，重大な故障を防止し，高い信頼性で運用を継続するために，プログラムの実行

中，残留するソフトウェア設計フォールトを検出する。

説明：アサーションプログラミング手法は，事前条件をチェックし（一連のステートメントが実行される

前に，初期条件の妥当性をチェックする。），さらに，事後条件をチェックする（一連のステートメ

C 0508-7：2017 (IEC 61508-7：2010)

ントを実行した後，結果をチェックする。）という概念に準拠している。事前条件又は事後条件の

いずれかが満たされない場合，処理はエラーを報告する。

例

アサート＜事前条件＞；

アクション1；

：

アクションx；

アサート＜事後条件＞；

参考文献：

Exploiting Traces in Program Analysis. A. Groce, R. Joshi. Lecture Notes in Computer Science vol 3920,

Springer Berlin / Heidelberg, 2006, ISBN 978-3-540-33056-1

Software Development−A Rigorous Approach. C. B. Jones, Prentice-Hall, 1980

C.3.4 ダイバースモニタ

注記この技術及び手法は，JIS C 0508-3の表A.2で引用されている。

目的：安全性に悪影響を及ぼす，ソフトウェアに残留する仕様上及び実装上のフォールトに対して保護す

る。

説明：監視は，次の2種類の手法に分けることができる。

1) 同一コンピュータ内で，監視対象となる機能とこれを監視する機能との間の独立性をある程度

保証している。

2) 監視機能と監視対象となる機能とが，個別のコンピュータにある。

ダイバースモニタは，別の仕様に従って独立したコンピュータ上に実装する外部モニタである。

このダイバースモニタは，主コンピュータに対して必ずしも正しくなくてもよいが，安全な動作を

確実にさせることだけに関心をもつ。ダイバースモニタは，主コンピュータを常時監視する。ダイ

バースモニタは，システムが潜在的に危険な状態になるのを防止する。さらに，モニタは主コンピ

ュータが潜在的に危険な状態になりつつあることを検出した場合には，ダイバースモニタ又は主コ

ンピュータのどちらかによって，システムを安全な状態に戻す必要がある。

ダイバースモニタのハードウェア及びソフトウェアは，適切なSILに従って分類し，認証を受け

ることが望ましい。

参考文献：

Requirements based Monitors for Real-Time Systems, D. Peters, D. Parnas. IEEE Transactions on Software

Engineering, vol. 28, no. 2, 2002

C.3.5 ソフトウェア多様性（ダイバースプログラミング）

注記この技術及び手法は，JIS C 0508-3の表A.2で引用されている。

目的：システムの安全上，重大な故障を防止し，高い信頼性で運用を継続するために，プログラムの実行

中，残留するソフトウェア設計フォールト及び実装フォールトを検出して，マスクする。

説明：ダイバースプログラミングにおいては，規定したプログラム仕様を，異なる設計でN個実装する。

同じ入力値をN個のバージョンに与え，N個のバージョンが生成する結果を比較する。結果を妥当

C 0508-7：2017 (IEC 61508-7：2010)

であるとみなす場合，その結果をコンピュータ出力に伝送する。

基本的要求事項は，N個のバージョンをある意味で相互に独立させ，これらが同一原因によって

同時に故障を起こさないようにすることである。実際には，N個のバージョン手法の基礎となって

いるバージョンの独立性を達成及び実証することは，非常に困難な場合がある。

N個のバージョンは別々のコンピュータで並列に実行することもできるが，これに代わる方法と

して，全てのバージョンを同一コンピュータ上で実行し，その結果を内部票決にかけることもでき

る。適用する要求事項によっては，N個のバージョンについて種々の異なる票決手法を，次のよう

に用いてもよい。

− システムが安全な状態をもつ場合，完全な一致（全てのNが一致する）を要求することが妥当

であり，そうでないときには，システムを安全な状態に到達させる出力値を一つ用いる。単純

なトリップシステムの場合，票決は安全方向へ偏らせることができる。この場合，安全動作と

しては，いずれかのバージョンがトリップを要求したときに，トリップすることになる。この

アプローチは，通常は，二つのバージョンだけを用いる（N＝2）。

− 安全な状態をもたないシステムの場合，多数決による票決手段を採用することができる。全体

的一致がない場合，正確な値を選択する機会を最大にするために，例えば，中央値をとる，一

致が戻るまで出力を一時的に凍結する，などの確率的アプローチを用いてもよい。

この技術は，残留するソフトウェア設計フォールトを取り除くことも，仕様解釈上のエラーを避

けることもできないが，これらが安全性に影響を及ぼす前に検出しマスクする手段を提供する。

参考文献：

Modelling software design diversity−a review, B. Littlewood, P. Popov, L. Strigini. ACM Computing Surveys,

vol 33, no 2, 2001

The N-Version Approach to Fault-Tolerant Software, A.Avizienis, IEEE Transactions on Software Engineering,

vol. SE-11, no. 12 pp.1491-1501, 1985

An experimental evaluation of the assumption of independence in multi-version programming, J.C. Knight, N.G.

Leveson. IEEE Transactions on Software Engineering, vol. SE-12, no 1, 1986

In Search of Effective Diversity: a Six Language Study of Fault-Tolerant Flight Control Software. A. Avizienis,

M. R. Lyu and W. Schutz. 18th Symposium on Fault-Tolerant Computing, Tokyo, Japan, 27-30 June 1988,

IEEE Computer Society Press, 1988, ISBN 0-8186-0867-6

C.3.6 バックワードリカバリ

注記この技術及び手法は，JIS C 0508-3の表A.2で引用されている。

目的：一つ又は複数のフォールトがある状態において，正しい機能動作を提供する。

説明：フォールトを検出した場合，システムを，あらかじめその一貫性を証明されている初期の内部状態

にリセットする。この手法は，適切に定義したチェックポイントにおいて，内部の状態を頻繁に保

存することを意味する。これは，大域的に（データベース全体について）行ってもよいし，増分的

に（チェックポイント間の変化だけに）行ってもよい。その後，システムは，その間に起こった変

化を，日誌処理（動作の監査ロギング），補正（これらの変化の全ての影響をゼロにする。），又は

外部（手動）相互作用を用いることによって補正する必要がある。

参考文献：

Looking into Compensable Transactions. Jing Li, Huibiao Zhu, Geguang Pu, Jifeng He. In Software

C 0508-7：2017 (IEC 61508-7：2010)

Engineering Workshop, 2007. SEW2007. IEEE, 2007, ISBN 978-0-7695-2862-5

Software Fault Tolerance (Trends in Software, No. 3), M. R. Lyu (ed.), John Wiley & Sons, April 1995, ISBN

0471950688

C.3.7 再試行フォールト回復メカニズム

注記この技術及び手法は，JIS C 0508-3の表A.2で引用されている。

目的：検出したフォールト状態から，再試行メカニズムによって機能回復を試みる。

説明：フォールト又はエラー状態を検出した場合，同じコードを再実行することによって状況を回復する

ように試みる。再試行による回復によって，ソフトウェアのタイムアウト又はタスク監視動作の後

の，リブート及び再始動手順，又は小規模のリスケジューリング及び再起動タスクと同程度に完全

に行うことができる。再試行技術は，通信フォールト又はエラー回復で通常用いるもので，再試行

条件は，通信プロトコルエラー（チェックサムなど）又は通信受領応答タイムアウトからフラグを

立てることができるかもしれない。

参考文献：

Reliable Computer Systems: Design and Evaluation, D.P. Siewiorek, R.S. Schwartz. A.K. Peters Ltd., 1998,

ISBN 156881092X, 9781568810928

C.3.8 グレースフルデグラデーション

注記この技術及び手法は，JIS C 0508-3の表A.2で引用されている。

目的：故障の有無にかかわらず，重要度が小さい方のシステム機能を見放すことによって，重要度が大き

い方のシステム機能を有効状態に維持する。

説明：この技術は，システムにおいて実行する様々な機能に優先権を与える。設計では，全てのシステム

機能を実行するだけの資源が不足している場合，優先度が高い機能が，優先度が低い機能よりも優

先的に実行することを確実にする。例えば，エラーロギング及び事象ロギング機能は，システム制

御機能よりも優先度が低くてもよく，その場合，エラーロギングに関わるハードウェアが故障した

場合でも，システム制御は継続される。さらに，システム制御ハードウェアが故障したが，エラー

ロギングハードウェアが故障していない場合，エラーロギングハードウェアが制御機能を引き継ぐ

こともある。

この技術は，主としてハードウェアに適用する技術だが，ソフトウェアを含むシステム全体にも

適用することができる。ただし，このことは，最上部の設計フェーズから考慮に入れる必要がある。

参考文献：

Towards the Integration of Fault, Resource, and Power Management, T. Siridakis. In Computer Safety,

Reliability, and Security: 23rd International Conference, SAFECOMP 2004. Eds. Maritta Heisel et. al.

Springer, 2004, ISBN 3540231765, 9783540231769

Achieving Critical System Survivability Through Software Architectures, J.C. Knight, E.A. Strunk. Springer

Berlin / Heidelberg, 2004, 978-ISBN 3-540-23168-4

The Evolution of Fault-Tolerant Computing. Vol. 1 of Dependable Computing and Fault-Tolerant Systems,

Edited by A. Avizienis, H. Kopetz and J. C. Laprie, Springer Verlag, 1987, ISBN 3-211-81941-X

Fault Tolerance, Principle and Practices. T. Anderson and P. A. Lee, Vol. 3 of Dependable Computing and

Fault-Tolerant Systems, Springer Verlag, 1987, ISBN 3-211-82077-9

C 0508-7：2017 (IEC 61508-7：2010)

C.3.9 人工知能−フォールト修正

注記1 この技術及び手法は，JIS C 0508-3の表A.2で引用されている。

目的：メソッドとプロセスモデルとの組合せ，並びにある種のオンラインでの安全性及び信頼性解析を導

入することによって，非常に融通の利く方法で，潜在危険に反応できるようにする。

説明：フォールト予報（トレンドの計算），フォールト修正，保全及び監督動作は，人工知能（AI）に基

づくシステムによって，システムの多様なチャネルにおいて非常に効率がよい方法で支援してもよ

い。なぜならば，その場合，規則を仕様から直接導き出して，仕様に照らしてチェックできるかも

しれないからである。仕様に入り込む幾つかの共通のフォールトは，幾つかの設計及び実装規則を

事前に暗黙のうちに心にとどめることによって，特に，モデルとメソッドとの組合せを機能的又は

説明的な方式で適用するとき，このアプローチによって，有効に回避できる場合がある。

希望する安全度を満たすために，フォールトを修正し，故障の影響を最小限に抑えるようにメソ

ッドを選択する。

注記2 不良データを修正する場合の警告はC.3.2を，この技術に関して推奨しない事項はJIS C

0508-3の表A.2の項目5（人工知能−フォールト修正）を参照。

参考文献：

Fault Diagnosis: Models, Artificial Intelligence, Applications. J. Korbicz, J. Koscielny, Z. Kowalczuk, W.

Cholewa. Springer, 2004, ISBN 3540407677, 9783540407676

C.3.10 動的再構成

注記この技術及び手法は，JIS C 0508-3の表A.2で引用されている。

目的：内部フォールトが発生した状態においても，システムの機能性を維持する。

説明：システムのロジックアーキテクチャは，システムの使用可能な資源の1サブセットにマッピングで

きるようなものである必要がある。アーキテクチャは，物理的資源の故障を検出し，その後，ロジ

ックアーキテクチャを，機能し続けている制限した資源にマッピングし直すことができる必要があ

る。この考え方は，従来，故障したハードウェアユニットからの復旧に限られていたが，ソフトウ

ェアの再試行を可能とする十分な“実行時冗長性”がある場合，又は個々の隔離した故障をほとん

ど重要でないものにする十分な冗長データがある場合，故障したソフトウェアユニットにも適用で

きる。

この技術は，システム設計の第一段階において考慮する必要がある。

参考文献：

Dynamic Reconfiguration of Software Architectures Through Aspects. C. Costa et al. Lecture Notes in

Computer Science, Volume 4758/2007, Springer Berlin / Heidelberg, 2007, ISBN 978-3-540-75131-1

C.3.11 リアルタイムでの安全性及び性能：タイムトリガアーキテクチャ

注記1 この技術及び手法は，JIS C 0508-3の表A.2で引用されている。

目的：予測可能な挙動をもつ安全性が重要なリアルタイムシステムへの，フォールトトレランスを構成可

能にし，透明性のある実装を行う。

説明：タイムトリガ（時間駆動）アーキテクチャ（TTA）システムにおいては，全てのシステム活動を，

大域的に同期している時間基準で開始して，進行もこの時間基準に基づいている。それぞれのアプ

リケーションには，バス上に時間駆動した固定時間スロットを割り当て，スロットには，各アプリ

C 0508-7：2017 (IEC 61508-7：2010)

ケーションのジョブの間で交換するメッセージを納める。したがって，メッセージを，定義したス

ケジュールに従ってだけやりとりすることができる。その一方で，事象駆動システムにおいては，

システム活動が，時間内の予測できない時点での不特定事象によって動作している。TTAの重要な

利点を，次に示す（Scheidler, Heinerなどの参考文献を参照）。

− システムのテスト及び認証に必要な労力を大幅に減らす，構成可能性。

− アーキテクチャを安全が重要なアプリケーション用として高く推奨できるようにする，フォー

ルトトレランスの透明性のある実装。

− 分散型リアルタイムシステムの設計を容易にする，大域的同期化時間基準の提供。

時間駆動プロトコル［TTP/C（Kopetz, Hexel他の参考文献参照）］を用いて，メッセージ送信の時

期，及び受信メッセージが個別の電子モジュールに関連しているかどうかを決定する静的スケジュ

ールに従ってノード間通信を行う。また，時間の大域的概念（グローバルノーション）から導いた，

周期的時分割多重アクセス（TDMA）方式によってバスへのアクセスを管理する。

時間駆動プロトコルは，TTAノードのネットワーク（Rushbyの参考文献参照）において，次の4

種類の基本的サービス（コアサービス）を保証する（Kopetz，Bauerの参考文献参照）。

− 決定論的及び適時のメッセージ転送推測的に分かっている時間限界内に，送信要素の出力ポ

ートから，受信要素の入力ポートまでのメッセージ転送。コントロールエラーの伝ぱ（播）を

設計によって排除し，要素間の結合を最小限に抑える時間ファイアウォールインタフェースを

経由して利用できる時間駆動通信サービスがフォールトトレラントな転送サービスを提供する。

レイテンシー及びジッタを最小限に抑えたメッセージの適時な転送サービスは，リアルタイム

アプリケーションでコントロールの安定性を実現するために不可欠である。

− フォールトトレラントな時刻同期通信コントローラが，ホストサブシステムに送るフォール

トトレラントな大域時間基準を（数クロック間隔内の精度で）発生する。

− 故障しつつあるノードの一貫診断（メンバーシップサービス）通信コントローラによって，全

てのSRU（“最小交換可能ユニット”）に対して，同一クラスタ内の他の全てのSRUの状態を，

1 TDMAラウンド未満の待ち時間で知らせる。

− 強力なフォールト隔離フォールトを故意に発生させるホストサブシステム（そのソフトウェ

アを含む。）は，誤ったデータ出力を生成する可能性があるが，そのホストサブシステムがTTP/C

クラスタの残りの部分の適切な動作に何らかの干渉をすることは決してできない。通信コント

ローラの時間駆動された挙動によって，時間領域でのフェールサイレンスを保証する。

注記2 その他の時間駆動プロトコルとしては，フレックスレイ（FlexRay）及びタイムトリガード

イーサネット（TT-Ethernet）がある。

参考文献：

Time-Triggered Architecture (TTA). C. Scheidler, G. Heiner, R. Sasse, E. Fuchs, H. Kopetz, C. Temple. In

Advances in Information Technologies: The Business Challenge, ed. J-Y. Roger. IOS Press, 1998, ISBN

9051993854, 9789051993851

A Synchronisation Strategy for a TTP/C Controller. H. Kopetz, R. Hexel, A. Krueger, D. Millinger, A. Schedl.

SAE paper 960120, Application of Multiplexing Technology SP 1137, Detroit, SAE Press, Warrendale,

1996

The Time-Triggered Architecture. H. Kopetz, G. Bauer. Proceedings of the IEEE Special Issue on Modeling and

Design of Embedded Software, October 2002

C 0508-7：2017 (IEC 61508-7：2010)

An Overview of Formal Verification for the Time-Triggered Architecture. J. Rushby: Invited paper, Oldenburg,

Germany, September 9-12, 2002. Proceedings FTRTFT 2002, Springer LNCS 2469, 2002, ISBN

978-3-540-44165-6

C.3.12 UML

注記この技術及び手法は，JIS C 0508-3の表B.7で引用されている。

目的：複合系の希望する挙動をモデル化するための包括的表記法の一群を提供する。

説明：UML（統一モデル化言語）は，その名前のとおり，ソフトウェア開発に包括的支援を与えることを

意図した，要求事項及び設計の表記法のまとまりである。UMLの一部は，他の手法で最初に導入し

た表記法（システムシーケンス図，状態遷移図など）に基づいており，その他の表記法はUML独

自のものである。UMLはオブジェクト指向コンセプトに強く偏向しているが，一部の表記法は，オ

ブジェクト指向プログラミングに進む必要なく利用することができる。UMLは，市販されている多

数のCASEツールで支援されており，これらのツールの多くは，UMLモデルから自動的にコード

を生成することが可能である。

安全関連系の仕様及び設計に最も一般的に適用されているUML表記法を，次に示す。

− クラス図

− 使用事例

− 活動図

− 状態遷移図（状態図）

− システムシーケンス図

その他のUML表記法は，ソフトウェアアーキテクチャ設計（ソフトウェア構造）の表現に関連

しているが，ここでは具体的に記載しない。

状態遷移図はB.2.3.2に，システムシーケンス図をC.2.14に示す。その他の表記法は，C.3.12.1，

C.3.12.2及びC.3.12.3で説明する。

C.3.12.1 クラス図

クラス図は，ソフトウェアが処理する必要があるオブジェクトのクラスを定義する。クラス図は，従来

のエンティティ関連属性の図に基づくものであるが，オブジェクト指向設計に適応させてある。各クラス

（実行時オブジェクトとして知られる，一つ又は複数のインスタンスがある。）を長方形で表現し，クラス

の間の各種関係を，線（ライン）又は矢印で示す。それぞれのクラスが提供する動作又はメソッド，及び

各クラスの属性を，図に追加することができる。表現可能な関係は，要素数を含む参照関係（クラスAの

インスタンスは，クラスBの一つ又は複数のインスタンスを参照する。）及び追加可能なメソッド及び属

性との専門化関係（クラスXは，クラスYを精細化したものである。）の両方である。複数の継承を表記

することができる。

C.3.12.2 使用事例

使用事例は，個別のシナリオに対するシステムの望ましい挙動を，通常は，システムの使用者（人）及

び外部システムを含む外部アクターの観点から，テキスト記述したものである。所定の使用事例に含まれ

る予備サブシナリオを用いて，特にエラー対応事例における選択可能な挙動を表現してもよい。一群の使

用事例を作成して，システム要求事項の十分に完璧な仕様を作成することができる。仕様事例は，システ

C 0508-7：2017 (IEC 61508-7：2010)

ムシーケンス図，活動図などのより厳密なモデルを作成するための出発点とすることができる。

使用事例図は，システム及び使用事例アクターを図解的に表現するものであるが，厳密なものではなく，

使用事例のテキストだけが仕様にとって重要となる。

C.3.12.3 活動図

活動図は，順次及び反復の挙動を含むソフトウェア要素（オブジェクト指向設計では，オブジェクトの

ことが多い。）が実行する，意図した行動シーケンスを示す（部分的には，まるでフロー図のように見える

ことがある。）。活動図は，複数の要素の行動を並列的に記述することもでき，要素間の相互作用は図に矢

印で示す。ある活動が先に進む前に他の活動からの一つ又は複数の入力を待たなければならない同期点は，

ペトリネットのノードと同じ記号で表示する。

参考文献：

JIS X 4170 オープン分散処理−統一モデル化言語（UML）1.4.2版

注記対応国際規格：ISO/IEC 19501:2005，Information technology−Open Distributed Processing−

Unified Modeling Language (UML) Version 1.4.2

C.4 開発ツール及びプログラミング言語

C.4.1 厳密に型付けしたプログラミング言語

注記この技術及び手法は，JIS C 0508-3の表A.3（ソフトウェア設計及び開発−支援ツール及びプロ

グラミング言語）で引用されている。

目的：コンパイラによる高水準のチェックを可能とする言語を用いることによって，フォールトの確率を

下げる。

説明：厳密に型付けしたプログラミング言語でコンパイルする場合，例えば，手順の呼出し及び外部デー

タアクセスにおいて，変数型をどのように用いるかについて多くのチェックを行う。前もって定義

した規則に準拠しない使用法の場合，コンパイルは失敗し，エラーメッセージを生成する。

このような言語を用いることによって，通常，ユーザ定義データ型を基本言語データ型（例えば，

整数，実数）から定義することができる。これによって，ユーザ定義データ型は，その後，基本言

語データ型と全く同様に用いることができる。正しい型が用いられていることを確実にするために，

厳しいチェックが課せられる。これらのチェックは，プログラムが別々のコンパイル単位で作成し

た場合でも，プログラム全体にわたって課せられる。これらのチェックによって，プロシジャーの

引数の数及び型が，別々にコンパイルしたソフトウェアモジュールから参照された場合でも一致す

ることを確実にする。

厳密に型付けした言語は，通常，適切にプログラムを構造化するための容易に解析可能な制御構

造（例えば，“if.. then.. else”，“do.. while”など）などの良好なソフトウェアエンジニアリングの実

践規範の他の面も支援する。

厳密に型付けした言語の典型的な例には，Pascal，Ada及びModula 2がある。

参考文献：

Concepts in Programming Languages. J. C. Mitchell. Cambridge University Press, 2003, ISBN 0521780985,

9780521780988

C 0508-7：2017 (IEC 61508-7：2010)

C.4.2 言語サブセット

注記この技術及び手法は，JIS C 0508-3の表A.3で引用されている。

目的：プログラミングフォールトが作り込まれる確率を下げ，残留フォールトを検出する確率を高める。

説明：例えば，静的解析方法を用いて，エラーを起こしやすい，又は解析することが困難なプログラミン

グ構成要素を見つけ出すために，言語を調査する。その後，これらの構成要素を排除した言語のサ

ブセットを定義する。

参考文献：

Practical Experiences of Safety- and Security-Critical Technologies, P. Amey, A.J. Hilton. Ada User Journal,

June, 2004

Safer C: Developing Software for High-integrity and Safety-critical Systems. L. Hatton, McGraw-Hill, 1994,

ISBN 0077076400, 9780077076405

Requirements for programming languages in safety and security software standard. B. A. Wichmann. Computer

Standards and Interfaces. Vol. 14, pp 433-441, 1992

C.4.3 認証したツール及びトランスレータ

注記この技術及び手法は，JIS C 0508-3の表A.3で引用されている。

目的：ツールは，ソフトウェア開発の種々のフェーズにおいて開発者を支援するために必要である。可能

な限り，ツールは，出力の正確さに関して，ある程度の信頼水準が仮定できるように認証すること

が望ましい。

説明：ツールの認証は，一般に，独立機関，多くの場合，国家機関によって，独立して定められた判定基

準，典型的なものとしては国家規格又は国際規格に照らして実施する。理想的には，全ての開発フ

ェーズ（仕様作成，設計，コーディング，テスト及び妥当性確認）において用いるツール，及び構

成管理に用いるツールは認証を受けることが望ましい。

今のところ，コンパイラ（トランスレータ）だけが，正式に認証手順の対象となっている。認証

手順は，認証機関によって定められており，コンパイラ（トランスレータ）をAda及びPascalに関

する国際規格などに照合し検証する。

認証したツール及びトランスレータは，通常，これらの各言語又はプロセス規格に対してだけ認

証されたことを承知しておくことは重要である。これらは通常，全ての面での安全性が認証された

わけではない。

参考文献：

The certification of software tools with respect to software standards, P. Bunyakiati et al. In IEEE International

Conference on Information Reuse and Integration, IRI 2007, IEEE, 2007, ISBN 1-4244-1500-4

Certified Testing of C Compilers for Embedded Systems. O. Morgan. In: 3rd Institution of Engineering and

Technology Conference on Automotive Electronics. IEEE, 2007, ISBN 978-0-86341-815-0

The Ada Conformity Assessment Test Suite (ACATS), version 2.5, Ada Conformity Assessment Authority,

http://www. ic.org/compilerstesting.html, Apr. 2002

C.4.4 ツール及びトランスレータ：使用によって信頼性が増すもの

注記この技術及び手法は，JIS C 0508-3の表A.3で引用されている。

目的：ソフトウェアパッケージの開発，適合確認及び保全中に起こる可能性があるトランスレータ故障に

C 0508-7：2017 (IEC 61508-7：2010)

よる困難を回避する。

説明：トランスレータは，多くの先行プロジェクトにおいて不適切な性能を示す証拠がない場合に用いる。

運用経験がないトランスレータ又は重大な既知のフォールトをもつトランスレータは，ほかに正し

い性能の保証（例えば，C.4.4.1を参照）がない限り，使用を避けることが望ましい。

トランスレータが軽微な不完全さを示している場合，関連言語構成要素を記録し，安全関連プロ

ジェクト遂行中は注意深く避ける。

この作業の別の方法として，この言語の使用を，この言語が一般的に用いられている機能だけに

制限することがある。

不完全なトランスレータの使用に関する推奨事項は，多くのプロジェクトによる経験に基づいて

いる。不完全なトランスレータは，いずれのソフトウェア開発においても，重大な不利益をもたら

すことが示されている。このようなプログラムは，一般に安全関連ソフトウェアの開発を実行不可

能にする。

今のところ，ツール又はトランスレータの全ての部分について正確さを証明する方法は存在しな

いことも知られている。

C.4.4.1 ソースプログラムと実行可能コードとの比較

目的：PROMイメージを生成するために用いるツールが，PROMイメージにいかなるエラーも組み込んで

いないことをチェックする。

説明：構成要素の“オブジェクト”モジュールを得るために，PROMイメージをリバースエンジニアリン

グする。これらの“オブジェクト”モジュールは，リバースエンジニアリングによってアセンブリ

言語ファイルになっている。この，逆に生成したアセンブリ言語ファイルと，PROMイメージを生

成した元の実際のソースファイルとを，適切な技術を用いて比較する。

この技術の主な利点は，PROMイメージを生成するために用いるツール（コンパイラ，リンカな

ど）を，全てのプログラムに対して妥当性確認する必要があるわけではない，ということにある。

この技術では，安全関連系に用いている特定のソースファイルが正しく変換されていることを検証

する。

参考文献：

Demonstrating Equivalence of Source Code and PROM Contents. D. J. Pavey and L. A. Winsborrow. The

Computer Journal Vol. 36, No. 7, 1993

Formal demonstration of equivalence of source code and PROM contents: an industrial example. D. J. Pavey

and L. A. Winsborrow. Mathematics of Dependable Systems, Ed. C. Mitchell and V. Stavridou, Clarendon

Press, 1995, ISBN 0-198534-91-4

Assuring Correctness in a Safety Critical Software Application. L. A. Winsborrow and D. J. Pavey. High

Integrity Systems, Vol. 1, No. 5, pp 453-459, 1996

C.4.5 適切なプログラミング言語

注記この技術及び手法は，JIS C 0508-3の表A.3で引用されている。

目的：この規格群の要求事項をできるだけ支援するために，特に，防御的プログラミング，厳密な型付け，

構造化プログラミング，及び場合によってはアサーションを行う。選択するプログラミング言語は，

最小限の労力によって容易に検証可能なコードに変換できることが望ましく，プログラム開発，適

C 0508-7：2017 (IEC 61508-7：2010)

合確認及び保全が容易にできることが望ましい。

説明：言語は，完全かつ曖昧さがないように定義することが望ましい。言語は，プロセッサ及びプラット

フォーム機械指向であるよりも，ユーザ指向又は問題指向であることが望ましい。特殊目的言語よ

りも，広く用いられている言語又はこれらのサブセットの方が望ましい。

既に上記の機能に加え，言語は，次のことを提供することが望ましい。

− ブロック構造

− トランスレート時間検査

− ランタイム型及び配列の境界検査

言語は，次の事項を奨励するものであることが望ましい。

− 小さく，管理可能なソフトウェアモジュールの使用

− 特定のソフトウェアモジュール内のデータへのアクセス制限

− 変数サブレンジの定義

− その他のエラー抑制構成要素

システムの安全動作がリアルタイム制限条件に従う場合，言語は，例外及び割込の取扱いについ

て定めることが望ましい。

言語は，適切なトランスレータ，既存のソフトウェアモジュールの適切なライブラリ，デバッガ，

並びにバージョン管理及び開発の両方のためのツールによって支援することが望ましい。

この規格の発行時点において，オブジェクト指向言語を他の従来の言語に優先させる必要がある

かどうかは定かではない。

したがって，適合確認が困難になるため避けた方がよい機能は，次のとおりである。

− サブルーチン呼出しを除く，無条件ジャンプ

− 再帰

− ポインタ，ヒープ，又はあらゆる型の動的変数若しくはオブジェクト

− ソースコードレベルでの割込処理

− ループ，ブロック又はサブプログラムの，多重入口又は出口

− 暗黙の変数初期化又は宣言

− バリアントレコード及び共有変数

− 手続引数

低水準言語，特にアセンブリ言語は，言語のプロセッサ及びプラットフォーム向けの機械指向の

性質のために問題を抱えている。

望ましい言語特性は，言語の設計及び使用によって，実行が予測できるプログラムとなることで

ある。適切に定義されたプログラミング言語の場合，プログラムの実行が予測できることを確実に

するサブセットがある。多くの静的制約条件は，予測可能な実行を確実にする上で助けになる場合

があるが，このサブセットを静的に決めることは一般にできない。予測可能な実行を確実にするた

めには，一般的に配列インデックスが範囲内であること，及び数値オーバフローが起こらないこと，

などを証明する必要がある。

表C.1に，具体的なプログラミング言語に関する推奨事項を示す。

C 0508-7：2017 (IEC 61508-7：2010)

表C.1−個々のプログラミング言語に関する推奨事項

項目

プログラミング言語

安全度水準

SIL1

SIL2

SIL3

SIL4

ADA

サブセット付きADA

Java

サブセット付きJava（ガベージコレクションを含まない，又はアプリ
ケーションコードを長時間停止させないガベージコレクションを含
む。）。オブジェクト指向機能の利用は，附属書Gを参照。

PASCAL（注記5参照）

サブセット付きPASCAL

FORTRAN 77

サブセット付きFORTRAN 77

−

サブセット及びコーディング標準をもち，静的解析ツールを用いるC

C++（オブジェクト指向機能の利用は，附属書Gを参照）

−

サブセット及びコーディング標準をもち，静的解析ツールを用いる
C++（オブジェクト指向機能の利用は，附属書Gを参照）

アセンブラ

−

サブセット及びコーディング標準をもつアセンブラ

ラダー図

言語で定義されたサブセットをもつラダー図

機能ブロック線図

言語で定義されたサブセットをもつ機能ブロック線図

構造化テキスト

言語で定義されたサブセットをもつ構造化テキスト

手順機能チャート

言語で定義されたサブセットをもつ手順機能チャート

命令一覧表

−

言語で定義されたサブセットをもつ命令一覧表

注記1 推奨事項HR，R，−及びNRは，JIS C 0508-3の附属書A（技法及び手段の選択の手引書）に説明がある。
注記2 システムソフトウェアには，システムの一部として供給されるオペレーティングシステム，ドライバ，組込

機能及びソフトウェアモジュールが含まれる。このソフトウェアは，一般的に，安全システムベンダーによ
って供給される。言語サブセットは，実装時にフォールトが生じるような複雑な構造を避けるように，注意
深く選択することが望ましい。言語サブセットが正しく使用されているかを確認するために，チェックを実
施することが望ましい。

注記3 アプリケーションソフトウェアは，特定の安全用途のために開発されたソフトウェアである。多くの場合，

このソフトウェアは，エンドユーザ又はアプリケーションを請け負う供給者によって開発される。多数のプ
ログラミング言語が同じ推奨事項をもつ場合，開発者は，業界又は施設内の従業者が共通的に用いているプ
ログラミング言語を一つ選択することが望ましい。言語サブセットは，実装時にフォールトが生じるような
複雑な構造を避けるように，注意深く選択することが望ましい。言語サブセットが正しく使用されているか
を確認するために，チェックを実施することが望ましい。

注記4 上の表に示されていない言語は，除外されているとみなす必要はない。そのような言語であっても，この規

格群に従うことが望ましい。

注記5 フリーパスカルを含めて，パスカル言語の拡張版が幾つか存在する。パスカルに言及している場合は，この

拡張版も含む。

C 0508-7：2017 (IEC 61508-7：2010)

表C.1−個々のプログラミング言語に関する推奨事項（続き）

注記6 Javaは，実行時ガベージコレクタをもつように設計されている。ガベージコレクションを必要としない，Java

サブセットを定義することもできる。一部のJava実装は，プログラムの実行時に空きメモリを回復する進歩
したガベージコレクションを提供し，利用可能なメモリを使い切ってしまうまでは，一定期間，実行停止を
しないものもある。厳格な実時間処理が必要なアプリケーションは，どんな形式であっても，ガベージコレ
クションは用いないことが望ましい。

注記7 Java実装がJava中間コードの実行時インタプリタを必要とする場合，このインタプリタは，安全関連ソフト

ウェアの一部として，JIS C 0508-3の要求事項に従って取り扱う必要がある。

注記8 項目15〜24は，IEC 61131-3を参照する。

参考文献：

Concepts in Programming Languages. J. C. Mitchell. Cambridge University Press, 2003, ISBN 0521780985,

9780521780988

IEC 60880:2006，Nuclear power plants−Instrumentation and control systems important to safety−Software

aspects for computer-based systems performing category A functions

JIS B 3503:2012 プログラマブルコントローラ−プログラム言語

注記対応国際規格：IEC 61131-3:2003，Programmable controllers−Part 3: Programming languages

JIS X 3001-1:2009 プログラム言語Fortran−第1部：基底言語

注記対応国際規格：ISO/IEC 1539-1:2004，Information technology−Programming languages−Fortran

−Part 1: Base language

JIS X 3008:1994 プログラム言語Pascal

注記対応国際規格：ISO/IEC 7185:1990，Information technology−Programming languages−Pascal

ISO/IEC 8652:1995，information technology−Programming languages−Ada

JIS X 3010:2003 プログラム言語C

注記対応国際規格：ISO/IEC 9899:1999，Programming languages−C

ISO/IEC 10206:1991，Information technology−Programming languages−Extended Pascal

ISO/IEC 10514-1:1996，Information technology−Programming languages−Part 1: Modula-2, Base Language

ISO/IEC 10514-3:1998，Information technology−Programming languages−Part 3: Object Oriented Modula-2

JIS X 3014:2003 プログラム言語C++

注記対応国際規格：ISO/IEC 14882:2003，Programming languages−C++

ISO/IEC/TR 15942:2000，Information technology−Programming languages−Guide for the use of the Ada

programming language in high integrity systems

C.4.6 自動ソフトウェア生成

注記この技術及び手法は，JIS C 0508-3の表A.2で引用されている。

目的：ソフトウェア実装のエラーを起こしやすいタスクを自動化する。

説明：システム設計は，従来の実行可能コードよりも抽象度が高い水準のモデル（実行可能仕様）によっ

て記述する。モデルは，コードジェネレータによって，自動的に実行可能な形式に変換する。目的

は，エラーを起こしやすい手動コーディングタスクを排除することで，ソフトウェアの品質を向上

させることである。さらに，より高い抽象度において，より複雑な設計を行うことができるという

潜在的便益もある。

参考文献：

C 0508-7：2017 (IEC 61508-7：2010)

Embedded Software Generation from System Level Design Languages, H Yu, R. Domer, D. Gajski. In

“ASP-DAC 2004: Proceedings of the ASP-Dac 2004 Asia and South Pacific Design Automation

Conference, 2004”, IEEE Circuits and Systems Society. IEEE, 2004, ISBN 0780381750, 9780780381759

Transforming Process Algebra Models into UML State Machines: Bridging a Semantic Gap?. M.F. van Amstel

et al. In Theory and Practice of Model Transformations: First International Conference, ICMT. ed. A.

Vallecillo. Springer, 2008, ISBN 3540699260, 9783540699262

C.4.7 テスト管理及び自動化ツール

注記この技術及び手法は，JIS C 0508-3の表A.5で引用されている。

目的：ソフトウェア及びシステムのテストに対する系統的及び綿密なアプローチを奨励する。

説明：適切な支援ツールを用いることで，システム開発における労働集約的でエラーを起こしやすいタス

クを機械化し，テスト管理のための系統的アプローチの能力を提供する。支援が利用できることで，

正規テスト及び回帰テストの両方について，より綿密なアプローチを促進する。

参考文献：

Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing.

R.Black, John Wiley and Sons, 2002, ISBN 0471223980, 9780471223986

C.5 適合確認及び部分改修

C.5.1 確率的テスト

注記この技術及び手法は，JIS C 0508-3の表A.5，表C.15，表A.7及び表C.17で引用されている。

目的：調査したソフトウェアの信頼性特性についての定量的数値を得る。

説明：この方法は，ソフトウェア信頼性の統計的推定値をもたらす。この定量的数値は，関係する信頼水

準及び重要度を考慮している場合があり，次の確率を与えることができる。

− 作動要求当たりの故障確率

− 定められた時間内での故障確率

− エラー抑制の確率

これらの数値から他のパラメータ，例えば，次のパラメータを導き出してもよい。

− 無故障で実行する確率

− 残存する確率

− 可用性

− MTBF又は故障率

− 安全な実行の確率

確率的考察は，確率的テスト又は運用実績のいずれかに基づく。通常，テストケース又は運用の

観察事例の数は非常に多い。一般に，作動要求モードは，連続モードに比べ，テストに要する時間

ははるかに短い。

テストデータを与えてテスト結果を監視するためには，通常，自動化されたテストツールを用い

る。大規模なテストは，適切なプロセスシミュレーション用の周辺機器をもつ大形のホストコンピ

ュータによって実行する。テストデータは，決定論的原因故障及びランダムハードウェア故障の両

方の視点によって選択する。テストの全体管理によって，例えば，テストデータプロフィールを保

C 0508-7：2017 (IEC 61508-7：2010)

証する一方，ランダム選択によって，個々のテストケースを詳細に管理することができる。

個々のテストハーネス，テスト実行及びテスト管理を，上記のように詳細なテスト目的によって

決める。その他の重要な条件は，テスト評価が意図したテスト目的に適合する必要がある場合に，

満たさなければならない数学的前提条件によって決める。

テストオブジェクトの挙動についての確率的数値は，運用経験から導き出してもよい。同じ条件

を満たしている場合，テスト結果の評価について同じ数学的技術を適用することができる。

実際には，この技術を用いて極めて高い水準の信頼性を実証することは非常に困難である。

参考文献：

A discussion of statistical testing on a safety-related application. S Kuball, J H R May, Proc IMechE Vol. 221

Part O: J. Risk and Reliability, Institution of Mechanical Engineers, 2007

Estimating the Probability of Failure when Testing Reveals No Failures, W.K. Miller, L.J. Morell, et al.. IEEE

Transactions on Software Engineering, VOl. 18, NO.1, pp33-43, January 1992

Reliability estimation from appropriate testing of plant protection software, J. May, G. Hughes, A.D. Lunn. IEE

Software Engineering Journal, v10 n6 pp 206-218, Nov 1995 (ISSN: 0268-6961)

Validation of ultra high dependability for software based systems, B. Littlewood and L. Strigini. Comm. ACM

36 (11), 69-80, 1993

C.5.2 データの記録及び解析

注記この技術及び手法は，JIS C 0508-3の表A.5及び表A.8（部分改修）で引用されている。

目的：適合確認，妥当性確認，評価及び保全を容易にするために，ソフトウェアプロジェクトにおける全

てのデータ，決定事項及び論理的根拠を文書化する。

説明：次の内容を含む詳細文書類を，プロジェクトの期間中維持管理する。

− 各ソフトウェアモジュールについて実施したテスト

− 決定事項及びその論理的根拠

− 問題及びその解決策

プロジェクトの期間中及び終了時に，この文書類を解析して様々な情報を導き出すことができる。

特に，開発プロジェクト中に下される決定事項の論理的根拠を保全技術者に常に知らせるとは限ら

ないため，データ記録はコンピュータシステムを保全するために非常に重要となる。

参考文献：

Dependability of Critical Computer Systems 2. F. J. Redmill, Elsevier Applied Science, 1989, ISBN ISBN

1851663819, 9781851663811

C.5.3 インタフェーステスト

注記この技術及び手法は，JIS C 0508-3の表A.5で引用されている。

目的：サブプログラムのインタフェースのエラーを検出する。

説明：テストの詳細さ又は完全性に対する幾つかの水準は，実現可能である。次の事項に対するテスト

は，最も重要な水準である。

− 全てのインタフェース変数を，極端な値とする。

− 全てのインタフェース変数に対して，他のインタフェース変数を通常値としたまま，個別に極

端な値にする。

C 0508-7：2017 (IEC 61508-7：2010)

− 各インタフェース変数に対して，他のインタフェース変数を通常値としたまま，変域の全ての

値をとる。

− 全ての変数と全ての値とを組み合わせる（これは小さなインタフェースに対してだけ実行可能

である。）。

− 各サブルーチンの各呼出しに関わる定めた条件でテストする。

これらのテストは，正しくないパラメータ値を検出するアサーションをインタフェースが含まな

い場合，特に重要である。これらのテストは，既存のサブプログラムの新しい構成を生成した後に

おいて重要となる。

C.5.4 境界値解析

注記この技術及び手法は，JIS C 0508-3の表B.2，表B.3及び表B.8で引用されている。

目的：パラメータの限界値又は境界で起こる，ソフトウェアエラーを検出する。

説明：プログラムの入力領域は，等価関係によって，複数の入力クラスに分割できる（C.5.7を参照）。テ

ストは，クラスの境界値及び極端な条件について実施することが望ましい。テストでは，仕様で定

義する入力領域の境界値が，プログラムの境界値と一致することをチェックする。直接的及び間接

的変換においてゼロ値を用いる場合，エラーを起こすことがよくあるので，次の点に特別な注意が

必要である。

− ゼロ除数

− 空白ASCII文字

− 空スタック又はリスト要素

− フルマトリックス

− ゼロ表項目

通常，入力の境界値は，出力範囲の境界値に直接的に対応する。テストケースを，出力が限定さ

れた値となるように設定することが望ましい。また，出力が仕様の境界値を超えるように，テスト

ケースを指定することが可能かどうかを考慮する。

出力が一連のデータ，例えば印刷された表である場合，最初及び最後の要素，並びに要素がゼロ，

一つ又は二つの場合のリストには特に注意することが望ましい。

参考文献：

The Art of Software Testing, second edition. G. J. Myers, T. Badgett, T. M. Codd, C. Sandler, John Wiley and

Sons, 2004, ISBN 0471469122, 9780471469124

C.5.5 エラー推定

注記この技術及び手法は，JIS C 0508-3の表B.2及び表B.8で引用されている。

目的：一般的なプログラミングのミスを除去する。

説明：テスト経験，知見に基づく直感及びテストするシステムについての興味から，設計したテストケー

スセットに，幾つかの区分されていないテストケースを加えてもよい。

特殊な値又は値の組合せは，エラーを起こしやすいことがある。幾つかの興味深いテストケース

を，検査チェックリストから導き出すことができる場合がある。これによって，システムが十分に

堅固であるかどうかを考慮することができる場合がある。このような例として，フロントパネル上

のボタンの押され方が速すぎたり，頻繁すぎたりしても大丈夫か，二つのボタンが同時に押された

C 0508-7：2017 (IEC 61508-7：2010)

ら何が起こるか，などがある。

参考文献：

The Art of Software Testing, second edition. G. J. Myers, T. Badgett, T. M. Codd, C. Sandler, John Wiley and

Sons, 2004, ISBN 0471469122, 9780471469124

C.5.6 エラーシーディング

注記この技術及び手法は，JIS C 0508-3の表B.2で引用されている。

目的：一連のテストケースが十分かどうかを確認する。

説明：幾つかの知られた種類の間違いをプログラムに挿入（シーディング）し，そのプログラムをテスト

条件によるテストケースによって実行する。シーディングしたエラーが幾つかしか発見できない場

合，そのテストケースセットは十分とはいえない。シーディングしたエラーの総数に対する，発見

したシーディングされたエラーの比率は，実際のエラー総数に対する発見した実際のエラーの比率

の推定値である。これによって，残存エラー数及びそのために残されたテストの作業量を推定する

ことができる（次式を参照。）。

ここに， NFS：発見したシーディングエラー

NS：シーディングしたエラーの総数

NFR：発見した実際のエラー

NR：実際のエラー総数

シーディングした全てのエラーを発見した場合，そのテストケースセットが十分であること，又

はシーディングされたエラーがあまりにも発見しやすいものであったことを示す。この方法の限界

は，使用可能な結果を得るためには，間違いの種類及びシーディング位置が，実際のエラーの統計

的分布を反映するものでなければならないということである。

参考文献：

Software Fault Injection: Inoculating Programs Against Errors. J. Voas, G. McGraw. Wiley Computer Pub.,

1998, ISBN 0471183814, 9780471183815

Faluts, Injection Methods, and Fault Attacks. Chong Hee Kim, Jean-Jacques Quisquater, IEEE Design and Test

of Computers, vol. 24, no. 6, pp. 544-545, Nov., 2007

Fault seeding for software reliability model validation. A. Pasquini, E. De Agostino. Control Engineering

Practice, Volume 3, Issue 7, July 1995. Elsevier Science Ltd

C.5.7 同値クラス及び入力分割テスト

注記この技術及び手法は，JIS C 0508-3の表B.2及び表B.3で引用されている。

目的：最小限のテストデータを用いて，ソフトウェアを十分にテストする。テストデータは，ソフトウェ

ア実行に必要な入力領域を分割した区画を選定することによって得ることができる。

説明：このテスト戦略は，入力領域の一つの区画を決める，入力の同値関係に基づく。

テストケースを，あらかじめ規定した区画の全てをカバーするように選択する。一つ以上のテス

トケースを，各同値クラスから取り出す。

入力の区画を決めるためには，次の二つの基本的可能性がある。

C 0508-7：2017 (IEC 61508-7：2010)

− 仕様から導き出す同値クラス。仕様の解釈は，例えば，選択した値を同一方法で処理する入力

指向か，又は例えば，一連の値が同じ機能結果に至る出力指向のどちらかである。

− プログラムの内部構造から導き出す同値クラス。同値クラス結果は，プログラムの静的解析か

ら，例えば，同じ経路で実行する一連の値として決定する。

参考文献：

The Art of Software Testing, second edition. G. J. Myers, T. Badgett, T. M. Codd, C. Sandler, John Wiley and

Sons, 2004, ISBN 0471469122, 9780471469124

Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN

0321313798, 9780321313799

Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577,

9783827372574

Static Analysis and Software Assurance. D. Wagner, Lecture Notes in Computer Science, Volume 2126/2001,

Springer, 2001, ISBN 978-3-540-42314-0

C.5.8 構造テスト

注記1 この技術及び手法は，JIS C 0508-3の表B.2で引用されている。

目的：プログラム構造の幾つかのサブセットを実行するテストを適用する。

説明：プログラムの解析に基づき，大きな割合（大抵，あらかじめ目的として定められている。）を占め

るプログラムコードを実行するために，一連の入力データを選ぶ。コードカバレッジ（E.13参照）

は，要求する厳密さの水準によって次のように異なる。全てのケースにおいて，選択するカバレッ

ジメトリックを100 %目標とすることが望ましい。100 %の範囲を達成できない場合は，100 %を達

成できない理由をテスト報告書に文書化する（例えば，ハードウェアの問題が発生したときだけに

入力する防御的コード）。次に示す最初の4技術は，JIS C 0508-3の表B.2の推奨事項として特に記

述しており，テストツールによって広く支援されている。残りの技術も考慮に入れてもよい。

− エントリー点（コールグラフ）カバレッジ全てのサブプログラム（サブルーチン又は機能）

を1回以上（これは，最小限に厳格な構造的カバレッジ値である。）コールしていることを確実

にする。

注記2 オブジェクト指向言語には，動的ディスパッチングによって呼び出すことができる，

多様型の各種変異型（上書きされるサブプログラム）に適用する同一名のサブプロ

グラムが幾つかある。これらの場合，上書きされる全てのサブプログラムを個々に

テストすることが望ましい。

− ステートメントコード内の全てのステートメントを，1回以上実行したことを確実にする。

− 分岐全ての分岐の両端をチェックすることが望ましい。ただし，幾つかの種類の防衛的コー

ドに対しては実行が難しい場合がある。

− 複合条件複合条件付き分岐（すなわち，AND/ORによってリンクしている分岐）における，

全ての条件を実行する。MC/DC（modified condition/decision coverage，参考文献DO-178B）を参

照。

− LCSAJ 線形コードシーケンス及びジャンプは，ジャンプによって終了する，条件付きステー

トメントを含むコードステートメントの線形シーケンスである。多くの潜在的サブパスは，そ

の前のコードの実行によって課せられる入力データに対する制約のために，実行不可能となる。

C 0508-7：2017 (IEC 61508-7：2010)

− データフロー実行経路，例えば，同一変数を書き込み，かつ，読み込むパスを，データ使用

に基づいて選択する。

− 基礎パス全ての経路が含まれる，開始から終了までの有限パスの最小セットの一つ（この基

礎セットの中でパスの重なり合う組合せによって，プログラム部分を通るパスを形成すること

ができる。）。全ての基礎パスのテストは，エラー位置を突き止めるために有効であることが示

されている。

参考文献：

The Art of Software Testing, second edition. G. J. Myers, T. Badgett, T. M. Codd, C. Sandler, John Wiley and

Sons, 2004, ISBN 0471469122, 9780471469124

Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN

0321313798, 9780321313799

Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577,

9783827372574

RTCA, Inc. document DO-178B and EUROCAE document ED-12B, Software Considerations in Airborne

Systems and Equipment Certification, dated December 1, 1992

C.5.9 制御フロー解析

注記この技術及び手法は，JIS C 0508-3の表B.8で引用されている。

目的：不完全プログラム構造及び潜在的不良プログラム構造を検出する。

説明：制御フロー解析は，コードにおいて適正プログラミング規範に従わない，疑わしい部分を見つける

ための静的テスト技術である。プログラムを解析して有向グラフを作成し，このグラフは次の事項

について更に解析することができる。

− アクセス不可能なコード，例えば，コードのブロックを到達不可能にしておく無条件ジャンプ

− 結節付きコード。正しく構造化されたコードは，単一ノードに縮小する継続的なグラフによっ

て，単純化することが可能な制御グラフをもつ。逆に，不完全に構造化されたコードは，幾つ

かのノードが構成する一つの結節に縮小することができるだけである。

参考文献：

Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN

0321313798, 9780321313799

Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577,

9783827372574

C.5.10 データフロー解析

注記この技術及び手法は，JIS C 0508-3の表B.8で引用されている。

目的：不完全プログラム構造及び潜在的不良プログラム構造を検出する。

説明：データフロー解析は，制御フロー解析から得られる情報を，変数をコードの種々の部分において読

み出す，又は書き込むことに関する情報と組み合わせる静的テスト技術である。この解析では，次

の事項についてチェックすることができる。

− 値が割り当てられる前に，読み出される可能性がある変数。これは，新しい変数を宣言すると

きに常に値を割り当てることによって避けることができる。

C 0508-7：2017 (IEC 61508-7：2010)

− 複数回の書き込みにおいて，読み出しを伴わない書き込みが1回以上ある変数。これは，コー

ドが抜けていることを示す場合がある。

− 書き込みが行われるが，一度も読み出されない変数。これは，余分なコードを示す場合がある。

データフロー異常は，必ずしもプログラムフォールトに直接的に結び付くとは限らないが，この

異常を回避した場合，そのコードがフォールトを含む可能性は小さくなる。

参考文献：

Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN

0321313798, 9780321313799

Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577,

9783827372574

C.5.11 記号的実行

注記この技術及び手法は，JIS C 0508-3の表B.8で引用されている。

目的：ソースコードと仕様との間の一致を示す。

説明：プログラム変数を，全ての代入について左辺を右辺で置き換えた後に評価する。条件付き分岐及び

ループを，ブール式に変換する。最終結果は，各プログラム変数の記号表現である。この表現は，

プログラムが実データを与えられた場合に計算をする値の公式である。これを，期待する表現と対

照することができる。

記号的実行の関連用法としては，プログラムロジックによって，パスに対してテストデータを系

統的に発生させる方法がある。記号的実行の機能は，ソフトウェア要素テスト及びコード解析のた

めの機能を提供する統合ツールセットに組み込んでもよい。

参考文献：

Using symbolic execution for verifying safety-critical systems. A. Coen-Porisini, G. Denaro, C. Ghezzi, M.

Pezzé. Proceedings of the 8th European software engineering conference, and 9th ACM SIGSOFT

international symposium on Foundations of software engineering. ACM, 2001, ISBN:1-58113-390-1

Using symbolic execution to guide test generation. G. Lee, J. Morris, K. Parker, G. Bundell, P. Lam. In Software

Testing, Verification and Reliability, vol 15, no 1, 2005. John Wiley & Sons, Ltd

C.5.12 形式的証明（形式的適合確認）

注記この技術及び手法は，JIS C 0508-3の表A.5及び表A.9で引用されている。

目的：理論的かつ数学的なモデル及び規則を用いて，プログラムを抽象モデル化して，プログラムの正確

さを証明する。

説明：テストは，プログラムの正確さを調べるために通常使われる方法であるが，実際の値によるプログ

ラムの複雑さを考える場合，徹底的なテストは実現できないのが普通である。したがって，考えら

れるプログラム挙動の一部だけをテストによって調べることができるにすぎない。これに対して，

形式的適合確認は，考えられる全ての入力に対してプログラムが定義どおりに挙動することを確定

するために，数学的に表現したプログラムに数学的手法を適用する。

システムの形式的適合確認では，プログラム及び要求する挙動を，厳密な数学的意味をもつ言語

で抽象モデル化（すなわち，仕様化）する必要がある。仕様は完全なものでも，次のような特定の

プログラム特性に限定したものでもよい。

C 0508-7：2017 (IEC 61508-7：2010)

− 機能的な正確さに関する特性。すなわち，プログラムは個別の機能性を提示することが望まし

い。

− 安全特性（すなわち，ある不良挙動が決して発生しないことを示す。）及び活性特性（すなわち，

ある優れた挙動が必ず発生することを示す。）。

− タイミング特性。すなわち，ある挙動が特定の時間に発生することを示す。

形式的適合確認の結果，考えられる全ての入力に対する仕様に関してプログラムの抽象モデルが

正しい，すなわち，モデルが規定の特性を満たしているという厳密な論拠を得ることができる。

ただし，モデルの正確さがそのまま実際のプログラムの正確さを証明するものではなく，対象の

特性について，このモデルが実際のプログラムを正確に抽象しているかを明らかにするために，更

にステップが必要になる。実践的な対象のプログラム特性は，数学的（例えば，タイミング及びス

ケジューリング，明瞭で簡単なユーザインタフェース，又は形式言語で容易に表現できない全ての

特性若しくは設計オブジェクティブ）に形式化することができない。したがって，形式的適合確認

は，シミュレーション及びテストに完全に取って代わるのではなく，むしろ，全ての入力に対する

プログラムの正しい動作を支援する更なる証拠を提供することで，これらの技術を補足するもので

ある。形式的適合確認はプログラムの抽象モデルの正確さを確実にするが，テストは実際のプログ

ラムが期待どおりに挙動することを確実にする。

設計フェーズで形式的適合確認を採用することによって，設計フェーズの早い段階で重大なエラ

ー及びミスを発見することが可能になるため，開発時間を大幅に低減でき，これによって，設計と

テストとの間を往復する時間を減らすことができる。

実用化されている形式方法の幾つか，例えば，CCS，CSP，HOL，LOTOS，OBJ，時相論理，VDM

及びZをC.2.4に示す。

C.5.12.1 モデルチェック

モデルチェックは，リアクティブシステム及び並行システムの形式的適合確認を行う方法の一つである。

システムの挙動を記述する有限状態構造の場合，時相論理の公式として書き込んだ特性を，構造に対して

有効であるかどうかチェックする。効率的アルゴリズム（例えば，SPIN，SMV及びUPPAAL）を用いて，

構造の状態全体を自動的かつ包括的に詳細検討する。特性が有効でない場合は，反例を生成する。この反

例は，特性がいかにして構造内で邪魔されているかを示し，システムを調査する非常に有用な情報を含ん

でいる。モデルチェックは，従来の検査及びテストでは見逃したかもしれない“困難なバグ”を検出でき

る。

モデルチェックは，捉えにくい複雑さを解析するのに役立つ。これは，一部の低SILアプリケーション

で役に立つが，高SILアプリケーションに捉えにくい複雑さがある場合，注意が必要である。

参考文献：

Is Proof More Cost-Effective Than Testing? S. King, R. Chapman, J. Hammond, A. Pryor. IEEE Transactions

on Software Engineering, vol. 26 no. 8, August 2000

Model Checking. E. M. Clarke, O. Grumberg, and D. A. Peled. MIT Press, 1999, ISBN 0262032708,

9780262032704

Systems and Software Verification: Model-Checking Techniques and Tools. B. Berard, M. Bidoit, A. Finkel, F.

Laroussinie, A. Petit, L. Petrucci, Ph. Schnoebelen, and P. Mckenzie, Springer, 2001, ISBN 3-540-41523-8

Logic in Computer Science: Modelling and Reasoning about Systems. M.Huth and M. Ryan. Cambridge

C 0508-7：2017 (IEC 61508-7：2010)

University Press, 2000, ISBN 0521652006, 0521656028

The Spin Model Checker: Primer and Reference Manual. G. J. Holzmann. Addison-Wesley, 2003, ISBN

0321228626, 9780321228628

C.5.12.2 （規定なし）

C.5.13 複雑さ測定

注記この技術及び手法は，JIS C 0508-3の表B.9及び表C.19（詳細特性−モジュラーアプローチ）

で引用されている。

目的：ソフトウェア自体の特性から，又はソフトウェアの開発若しくはテスト履歴から，プログラムの属

性を予測する。

説明：これらのモデルは，ソフトウェアの構造特性を評価し，そのソフトウェアを，信頼性又は複雑さな

ど，望まれる属性に関係付ける。大半の手法は，評価するためにソフトウェアツールを必要とする。

適用可能な測定方法を，次に示す。

− グラフ理論的複雑さ。この手法は，トレードオフを評価するためにライフサイクルの初期にお

いて適用でき，その循環数が表すプログラム制御グラフの複雑さに基づいている。

− あるソフトウェアモジュールを作動させる多くの方法（アクセスしやすさ）。ソフトウェアモジ

ュールへのアクセスが多くなるほど，デバッグしやすくなる。

− ハルステッドのメトリックス。この手法では，演算子及びオペランドの数を数えることによっ

てプログラムの長さを計算する。これによって，将来の開発リソースを予測する場合の，比較

のためのベースラインを形成する複雑さ及びサイズの指標を得る。

− ソフトウェアモジュール当たりの開始及び終了の数。開始点及び終了点の数を最小限に抑える

ことが，構造化設計及びプログラミング技術の重要な特徴である。

参考文献：

Metrics and Models in Software Quality Engineering. S.H. Kan. Addison-Wesley, 2003, ISBN 0201729156,

9780201729153

C.5.14 形式的検査

注記この技術及び手法は，JIS C 0508-3の表B.8で引用されている。

目的：ソフトウェア要素の欠陥を明らかにする。

説明：形式的検査は，欠陥を発見するため及び作成者がソフトウェア生成物を改善できるようにするた

め，作成者と対等な技術者が実施する，ソフトウェア生成物を検査するための構造化したプロセス

である。作成者は，習熟段階で検査員にプログラム内容の概要説明をする以外は，検査プロセスに

加わらないことが望ましい。形式的検査は，ソフトウェア開発ライフサイクルのいずれかの段階で

作成する特定のソフトウェア要素について実施してもよい。

検査を行う前に，検査員は，検査対象の生成物を十分に知る必要がある。検査プロセスでの検査

員の役割を，明確に定義しておくことが望ましい。検査項目は用意しておくことが望ましい。ソフ

トウェア要素に要求する特性に基づき，開始基準及び終了基準を定義する。開始基準とは，検査を

実施する前に満たさなければならない基準又は要求事項である。終了基準は，特定のプロセスを完

了するために満たさなければならない基準又は要求事項である。

C 0508-7：2017 (IEC 61508-7：2010)

検査の間，検査を円滑に進める役割をもつ進行役が検査結果を正式に記録することが望ましい。

結果は，全ての検査員のコンセンサスを得ることが望ましい。欠陥は，a) 検収前に是正を必要とす

るもの，又はb) 所定の時間若しくはマイルストーンで是正を要するものに分類する。特定した欠

陥は，検査完了後に続いて是正するために，作成者に知らせることが望ましい。特定した欠陥の数

及び範囲に応じて，進行役はソフトウェア生成物を更に検査する必要があるかを決定する場合があ

る。

参考文献：

Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN

0321313798, 9780321313799

Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577,

9783827372574

The Art of Software Testing, second edition. G. J. Myers, T. Badgett, T. M. Codd, C. Sandler, John Wiley and

Sons, 2004, ISBN 0471469122, 9780471469124

Fagan, M. Design and Code Inspections to Reduce Errors in Program Development. IBM Systems Journal 15, 3

(1976): 182-211

C.5.15 ウォークスルー（ソフトウェア）

注記この技術及び手法は，JIS C 0508-3の表B.8で引用されている

目的：仕様と実装との間の不一致を明らかにする。

説明：ウォークスルーは，ソフトウェア要素の作成者が，対等な技術者との立会いの下で，ソフトウェア

要素内の欠陥を発見する目的で実施する，非形式技術である。これは，ソフトウェア開発ライフサ

イクルのいずれかの段階で作成する特定のソフトウェア要素について実施してもよい。

安全関連系が仕様に示す要求事項に適合していることを確実にするために安全関連系で規定した

機能を調査及び評価する。製品の実装及び使用に関して疑わしい点がある場合，解決できるように

文書化する。形式的検査と対照的に，作成者はウォークスルーに参加する。

参考文献：

Software Engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN

0321313798, 9780321313799

Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577,

9783827372574

The Art of Software Testing, second edition. G. J. Myers, T. Badgett, T. M. Codd, C. Sandler, John Wiley and

Sons, 2004, ISBN 0471469122, 9780471469124

C.5.16 設計レビュー

注記この技術及び手法は，JIS C 0508-3の表B.8で引用されている。

目的：ソフトウェア設計の欠陥を明らかにする。

説明：設計レビューは，設計要求事項及び設計の能力が設計要求事項を満たすことができるかを評価し，

問題点及びソリューションを特定するための，ソフトウェア設計の形式，文書化，包括的及び系統

的なソフトウェア設計の調査である。

設計レビューは，入力要求事項を基準として設計状態を評価する手段，及び更なる改善の可能性

C 0508-7：2017 (IEC 61508-7：2010)

を特定する手段となる。開発ライフサイクル活動が進み，主要な詳細設計マイルストーンに到達す

るのに応じて，設計レビューを行うことによって，全てのインタフェース面をレビューし，設計が

確実に要求事項を満たすように設計の検証を行うことを確実にし，最も適切な設計が安全要求事項

と整合していることを確実にすることが望ましい。こうしたレビューは，主として，設計者の作業

を検証することを意図しており，確認及び精緻化の活動として取り扱うことが望ましい。

“スニーク回路解析”などの厳密な検査技術は，想定外パス又はロジックフロー，意図しないア

ウトプット，不正タイミング，望ましくないアクションなどのような，ソフトウェアの不正挙動を

検出するために用いてもよい。

参考文献：

Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN

0321313798, 9780321313799

Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577,

9783827372574

The Art of Software Testing, second edition. G. J. Myers, T. Badgett, T. M. Codd, C. Sandler, John Wiley and

Sons, 2004, ISBN 0471469122, 9780471469124

IEC 61160: 2005，Design review

Space Product Assurance, Sneak analysis−Part 2: Clue list, ECSS-Q-40-04A Part 2. ESA

Publications Division, Noordwijk, 1997, ISSN 1028-396X,

http://www.everyspec.com/ESA/ECSS-Q-40-04A̲Part-2̲14981/

C.5.17 プロトタイピング及びアニメーション

注記この技術及び手法は，JIS C 0508-3の表B.3及び表B.5で引用されている。

目的：指定された制約条件に照らして，システムを実装する実行可能性をチェックする。誤解点を明確に

させるため，システムの仕様作成者の解釈を使用者に連絡する。

説明：システム機能の一つのサブセット，制約条件及び性能要求事項を選択する。高水準ツールを用い

て，一つのプロトタイプを製作する。この段階においては，ターゲットコンピュータ，実装言語，

プログラムサイズ，保守性，信頼性，可用性などの制約条件を考慮する必要はない。プロトタイプ

は使用者の判定基準に照らして評価し，システム要求事項はこの評価を考慮に入れて部分改修して

もよい。

参考文献：

Software Engineering for Real-time Systems. J. E. Cooling, Pearson Education, 2003, ISBN 0201596202,

9780201596205

C.5.18 プロセスシミュレーション

注記この技術及び手法は，JIS C 0508-3の表A.7，表C.7，表B.3及び表C.13で引用されている。

目的：ソフトウェアシステムの機能を，外界とのインタフェースとともに，実世界をいかなる点において

も全く変更させることなくテストする。

説明：テストを唯一の目的とする被制御機器（EUC）の挙動を模擬するシステムを作成する。

シミュレーションは，ソフトウェアだけでも，ソフトウェアとハードウェアとの組合せでもよい。

ただし，次の条件を満たす必要がある。

C 0508-7：2017 (IEC 61508-7：2010)

− インプットは，EUCを実際に据え付けたときに存在する入力と同等のものを備える。

− テスト下のソフトウェアからのアウトプットに対して，制御するプラントを忠実に再現する方

法で応答する。

− テスト下のシステムが対処しなければならない挙動不安定が生じるような，オペレータのイン

プットに対する備えをもつ。

ソフトウェアをテストする場合，シミュレーションは，インプット及びアウトプットを備えたタ

ーゲットハードウェアであってもよい。

参考文献：

EmStar：An Environment for Developing Wireless Embedded Systems Software. J Elson et al.

http://cens.ucla.edu/TechReports/9̲emstar.pdf

A hardware-software co-simulator for embedded system design and debugging. A. Ghosh et al. In Proceedings

of the IFIP International Conference on Computer Hardware Description Languages and Their

Applications, IFIP International Conference on Very Large Scale Integration, 1995. IEEE, 1995, ISBN

4930813670, 9784930813671

C.5.19 性能要求事項

注記この技術及び手法は，JIS C 0508-3の表B.6（性能テスト）で引用されている。

目的：ソフトウェアシステムの実証可能な性能要求事項を確立する。

説明：明白，暗黙の区別なく，全ての一般的で具体的な性能要求事項を規定するために，システム及びソ

フトウェアの両方の要求仕様の解析を実施する。

各性能要求事項を，次の事項を決めるために順番に調査する。

− 達成するための成功判定基準

− 成功判定基準に対する測定方法の有無

− このような測定の潜在的正確さ

− 測定値を推定することができるプロジェクト段階

− 測定を行うことができるプロジェクト段階

その後，性能要求事項，成功判定基準及び候補となる測定方法の一覧を得るために，各性能要求

事項の実行可能性を解析する。主目的を，次に示す。

− 各性能要求事項が，一つ以上の測定と関わりをもつ。

− 可能なら，開発のできるだけ早期において用いることができる，正確で効率のよい測定方法を

選択する。

− 必須の性能要求事項，任意の性能要求事項及び成功判定基準を規定する。

− 可能な場合，複数の性能要求事項に単一の測定方法を用いることが望ましい。

参考文献：

Software Engineering for Real-time Systems. J. E. Cooling, Pearson Education, 2003, ISBN 0201596202,

9780201596205

C.5.20 性能モデリング

注記この技術及び手法は，JIS C 0508-3の表B.2及び表B.5で引用されている。

目的：システムの動作能力が，規定した要求事項を十分満たすことを確実にする。

C 0508-7：2017 (IEC 61508-7：2010)

説明：要求仕様には，特定機能に対する処理時間及び応答要求事項を，恐らく全システムリソースの使用

に対する制約条件と組み合わせて考えることが含まれている。提案したシステム設計を，次の事項

によって，規定した要求事項と照合する。

− システム処理のモデル，及びシステム処理の相互作用を設計する。

− 各処理によるリソースの使用，例えば，プロセッサ時間，通信帯域幅，記憶装置などを決める。

− 平均及び最悪の場合の条件下での，システムへの要求頻度分布を決める。

− 個々のシステム機能についての平均及び最悪の場合の条件下での，処理時間及び応答時間を計

算する。

単純なシステムの場合は，解析的解決策で十分なこともあるが，より複雑なシステムの場合は，

正確な結果を得るために，何らかの形のシミュレーションが更に適切なことがある。

詳細モデルを作成する前に，全ての処理についてのリソース要求量を合計した，比較的単純な“リ

ソース予算”チェックを用いることができる。要求量が設計したシステム容量を超えた場合，設計

は実行不可能である。設計がこのチェックに合格した場合であっても，性能モデルは，リソース不

足のために極端な遅延及び応答時間となることを示す場合がある。このような状況を避けるために，

技術者は，リソース不足の確率が低減されるように，全リソースのある割合（例えば，50 %）でシ

ステムを設計することが多い。

参考文献：

Software Engineering for Real-time Systems. J. E. Cooling, Pearson Education, 2003, ISBN 0201596202,

9780201596205

C.5.21 アバランチ及びストレステスト

注記この技術及び手法は，JIS C 0508-3の表B.6で引用されている。

目的：テスト対象が通常の作業負荷に容易に耐えることを示すために，テスト対象に例外的に高い作業負

荷をかける。

説明：アバランチ及びストレステストに適用することができる，様々なテスト条件がある。幾つかのテス

ト条件を，次に示す。

− ポーリングモードで作業している場合，テスト対象への単位時間当たりのインプットを，通常

条件よりもはるかに多く，変化させる。

− オンデマンドで作業する場合，テスト対象への単位時間当たりの作動要求数を，通常条件より

も増やす。

− データベースのサイズが重要な役目を果たす場合，そのサイズを通常条件よりも大きくする。

− 影響を及ぼす装置は，それぞれ，これらの最大速度又は最小速度に設定する。

− 極端な事例の場合，全ての影響要因を，できるだけ同時に境界条件に入れる。

これらのテスト条件によって，テスト対象の時間挙動を評価することができ，負荷変化の影響を

観察することができる。さらに，内部バッファ，動的変数，スタックなどの正しい大きさを確認す

ることができる。

参考文献：

Software Engineering for Real-time Systems. J. E. Cooling, Pearson Education, 2003, ISBN 0201596202,

9780201596205

C 0508-7：2017 (IEC 61508-7：2010)

C.5.22 応答タイミング及びメモリ制約

注記この技術及び手法は，JIS C 0508-3の表B.6で引用されている。

目的：システムが時間的要求事項及びメモリ要求事項を満たすことを確実にする。

説明：システム及びソフトウェアについての要求仕様には，全システムリソースの使用に対する制約条件

と組み合わせた，特定機能についてのメモリ及び応答要求事項を含む。

平均及び最悪の場合の条件下における要求頻度分布を決めるために，解析を実施する。この解析

には，各システム機能についてのリソースの用途及び経過時間の推定値が必要となる。これらの推

定値は，幾つかの方法，例えば，既存システムとの比較，又はタイムクリティカルシステムのプ

ロトタイピング及びベンチマークの実施によって得ることができる。

C.5.23 影響解析

注記この技術及び手法は，JIS C 0508-3の表A.8（部分改修）で引用されている。

目的：ソフトウェアシステムの変更又は機能強化が，そのソフトウェアシステムの他のソフトウェアモジ

ュール及び他のシステムに及ぼす影響を求める。

説明：ソフトウェアの部分改修又は機能強化を実施する前に，その部分改修又は機能強化がそのソフトウ

ェアに及ぼす影響を求めるために，さらに，どのソフトウェアシステム及びソフトウェアモジュー

ルに影響を及ぼすかを求めるために，解析を実施することが望ましい。

解析が完了した後，そのソフトウェアシステムの再適合確認に関する決定が必要になる。この決

定は，影響を受けるソフトウェアモジュールの数，致命度及び変更の性質によって異なる。考えら

れる決定を，次に示す。

− 変更したソフトウェアモジュールだけを再適合確認する。

− 影響を受ける全てのソフトウェアモジュールを再適合確認する。

− システム全体を再適合確認する。

参考文献：

Requirements Engineering. E. Hull, K. Jackson, J. Dick. Springer, 2005, ISBN 1852338792, 9781852338794

C.5.24 ソフトウェア構成管理

注記この技術及び手法は，JIS C 0508-3の表A.8で引用されている。

目的：ソフトウェア構成管理とは，幾つかのグループになった開発製品を変更した場合，これらの製品の

グループの整合性を確実にすることである。構成管理は，一般に，ハードウェア及びソフトウェア

の両方の開発に適用する。

説明：ソフトウェア構成管理は，開発全体を通じて用いられる技術である（JIS C 0508-3の6.2.3参照）。

本質的に，この管理には，全ての重要な製品の全てのバージョンの作成，及び様々な製品の様々な

バージョン間の全ての関係の生成を文書化する必要がある。この結果から得た文書類によって，開

発者は，一つの製品（特に，要素のうちの一つ）の変更が他の製品に及ぼす影響を求めることがで

きる。特に，システム又はサブシステムは，要素バージョンの整合性がある組合せから，信頼でき

る形で再構築することができる。

参考文献：

Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN

0321313798, 9780321313799

C 0508-7：2017 (IEC 61508-7：2010)

Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577,

9783827372574

Software Configuration Management: Coordination for Team Productivity. W.A. Babich. Addison-Wesley, 1986,

ISBN 0201101610, 9780201101614

CMMI: guidelines for process integration and product improvement, Mary Beth Chrissis, Mike Konrad, Sandy

Shrum, Addison-Wesley, 2003, ISBN 0321154967, 9780321154965

C.5.25 リグレッション妥当性確認

注記この技術及び手法は，JIS C 0508-3の表A.8で引用されている。

目的：リグレッションテストから妥当な結論を導き出すことを確実にする。

説明：大きなシステム又は複雑なシステムのリグレッションテストは，通常，相当の労力及びリソースを

必要とする。可能な場合は，リグレッションテストを，システム開発における時点で直接的に影響

のあるシステム側面だけを対象とするように限定することが望ましい。この部分リグレッションテ

ストでは，部分テストの範囲について明確に理解し，テストしたシステム状態について妥当な結論

だけを導くことが重要である。

参考文献：

Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing.

R.Black, John Wiley and Sons, 2002, ISBN 0471223980, 9780471223986

C.5.26 仕様及び設計のアニメーション

注記この技術及び手法は，JIS C 0508-3の表A.9で引用されている。

目的：仕様の系統的検査によって，ソフトウェア適合確認を導く。

説明：実行可能コードよりも抽象的なソフトウェアの表現（すなわち，仕様又は高水準設計）を検査し

て，最終的な実行可能ソフトウェアの挙動を求める。この検査は，（高水準表現の性質及び抽象度

によって利用可能となった可能性に応じて）何らかの方法で自動化し，実行可能ソフトウェアの挙

動及び出力をシミュレーションする。このアプローチの一つの適用例は，後で実行可能ソフトウェ

アに適用でき，これによってテストプロセスをある程度まで自動化できるテスト（又は“オラクル”）

を生成することである。もう一つの適用例は，専門技術をもたない最終使用者でも，ソフトウェア

開発者が作業する仕様の詳細な意味をある程度理解できるように，ユーザインタフェースをアニメ

ーション化することである。これによって，両方の間に貴重な情報伝達方法を設ける。

参考文献：

Supporting the Software Testing Process through Specification Animation. T.Miller, P.Strooper. In Proceedings

of the First International Conference on Software Engineering and Formal Methods (SEFM'03), ed.

P.Lindsay. IEEE Computer Society, IEEE Computer Society, 2003, ISBN 0769519490, 9780769519494

B model animation for external verification. H.Waeselynck, S.Behnia, In Proceedings of the Second

International Conference on Formal Engineering Methods, 1998. IEEE Computer Society, 1998, ISBN

0-8186-9198-0

C.5.27 モデルベーステスト（テストケース生成）

注記この技術及び手法は，JIS C 0508-3の表A.5で引用されている。

100

C 0508-7：2017 (IEC 61508-7：2010)

目的：システムモデルからの効率的で自動的なテストケース生成を容易にし，再現性の高いテスト一式を

生成する。

説明：モデルベーステスト（MBT）は，テストケース生成（TCG）及びテスト結果評価のような，共通テ

ストタスクがテスト対象システム（アプリケーション）（SUT）のモデルに基づいているブラックボ

ックスアプローチである。通常，システムデータ及び使用者挙動は，有限状態機械，マルコフ過程，

判定表など（El-Far，2001，generalized）を利用してモデル化するだけにとどまらない。さらに，モ

デルベーステストをソースコード水準のテストカバレッジ測定値と組み合わせることができ，機能

モデルは既存のソースコードにベースをおくことができる。

モデルベーステストは，システム要求事項及び規定の機能性のモデルを用いて，効率的なテスト

ケース及び手順を自動的に生成することである（Software Tech，2009）。

テストは非常にコストがかかるので，自動的テストケース生成ツールの需要が大きくなっている。

したがって，モデルベーステストは，現在，非常に活発な研究分野になっており，利用可能なテス

トケース生成（TCG）ツールが数多く生まれている。これらのツールは，通常，モデルの挙動部分

からテスト一式を抽出しており，一定のカバレッジ要求事項を満たすことが保証されている。

モデルは，テスト対象システム（SUT）の希望する挙動の抽象的な部分的表現である。このモデ

ルからテストモデルを導き，抽象的なテスト一式を構築する。テストケースを，この抽象的なテス

ト一式から導き，システムを基準として実行する。テストは，システムモデルを基準としても実行

できる。テストケース生成（TCG）をもつモデルベーステスト（MBT）は，形式的手法の使用と強

い関係をもっているので，推奨事項は，安全度水準（SIL）と同じものとなる。つまり，より高い

SILに対してはHR（強く推奨する）となり，より低いSILに対しては不要となる。

一般的な具体的な活動を，次に示す。

− （システム要求事項からの）モデル構築

− 期待インプットの生成

− 期待アウトプットの生成

− テスト実行

− 実際のアウトプットと期待アウトプットとの比較

− これ以上のアクション（モデル修正，更に多くのテストの生成，ソフトウェアの信頼性及び品

質の推定）についての決定

テストは，使用者及びシステム挙動のモデルを表現するため，様々な方法及び技術によって導く

ことができる。次に例を示す。

− 判定表の利用

− 有限状態機械の利用

− グラマーの利用

− マルコフ連鎖モデルの利用

− 状態図の利用

− 定理証明

− 制約論理プログラミング

− モデルチェック

− 記号実行

− 事象フローモデルの利用

101

C 0508-7：2017 (IEC 61508-7：2010)

− リアクティブシステムテスト。並列階層有限オートマトンなど。

− その他

具体的には，モデルベーステストは，近年，安全クリティカル領域を目標としている。これによ

って，仕様及び設計における曖昧な点を早期に明らかにし，複数の非反復的な効率のよいテストの

自動的発生，リグレッションテスト一式の評価，並びにソフトウェア信頼性及び品質の評価に関す

る能力を与え，テスト一式の更新を容易にする。

徹底的な全体的検討をEI-Far（2001）及びSoftware Tech 2009で実施し，その他の詳細及び領域固

有の問題点は他の文献で検討する（次の参考文献を参照）。

参考文献：

T. Bauer, F. Böhr, D. Landmann, T. Beletski, R. Eschbach, Robert and J.H. Poore, From Requirements to

Statistical Testing of Embedded Systems Software Engineering for Automotive Systems−SEAS 2007,

ICSE Workshops, Minneapolis, USA

Eckard Bringmann, Andreas Krämer; Model-based Testing of Automotive Systems In: ICST, pp.485-493, 2008

International Conference on Software Testing, Verification, and Validation, 2008

Broy M., Challenges in automotive software engineering, International conference on Software engineering

(ICSE '06), Shanghai, China, 2006

I. K. El-Far and J. A. Whittaker, Model-based Software Testing. Encyclopedia of Software Engineering (edited

by J. J. Marciniak). Wiley, 2001

Heimdahl, M.P.E.: Model-based testing: challenges ahead, Computer Software and Applications Conference

(COMPSAC 2005), 25-28 July 2005, Edinburgh, Scotland, UK, 2005

Jonathan Jacky, Margus Veanes, Colin Campbell, and Wolfram Schulte, Model-based Software Testing and

Analysis with C#, ISBN 978-0-521-68761-4, Cambridge University Press 2008

A. Paradkar, Case Studies on Fault Detection Effectiveness of Model-based Test Generation Techniques, in

ACM SIGSOFT SW Engineering Notes, Proc. of the first int. workshop on Advances in model-based

testing A-MOST '05, Vol. 30 Issue 4. ACM Press 2005

S. J. Prowell, Using Markov Chain Usage Models to Test Complex Systems, HICSS '05: 38th Annual Hawaii,

International Conference on System Sciences, 2005

Mark Utting and Bruno Legeard, Practical Model-based Testing: A Tools Approach, ISBN 978-0-12-372501-1,

Morgan-Kaufmann 2007

Hong Zhu et al. (2008). AST '08: Proceedings of the 3rd International Workshop on Automation of Software

Test. ACM Press. ISBN 978-1-60558-030-2

Model-based Testing of Reactive Systems Advanced Lecture Series, LNCS 3472, Springer- Verlag, 2005, ISBN

978-3-540-26278-7

Model-based Testing, SoftwareTech July 2009, Vol. 12, No. 2, Software Testing: A Life Cycle Perspective,

http://www.goldpractices.com/practices/mbt/

C.6 機能安全評価

注記関連技術及び手法は，B.6にもある。

C.6.1 決定表（真理値表）

102

C 0508-7：2017 (IEC 61508-7：2010)

注記この技術及び手法は，JIS C 0508-3の表A.10及び表B.7で引用されている。

目的：明確で首尾一貫した仕様，並びに複雑な論理結合及び論理関係の解析を与える。

説明：この方法では，ブールプログラムの真理値変数間の論理関係を簡潔に説明する2次元表を用いる。

この方法は，簡潔さ及び表を用いるという特性から，コードで表現される複雑な論理結合の解析

手法として適している。

この方法は，仕様に対して適用可能である。

C.6.2 ソフトウェア潜在危険及び操作性の研究（CHAZOP，FMEA）

目的：提案した又は現存するシステムにおける安全上の潜在危険，これらの考えられる原因及び結果，並

びにこれらの発生機会を最小限に抑えるための推奨手法を求める。

説明：設計の構造的調査には，スケジュールに従って開かれる一連の会議を通じて，考慮中のシステム全

体に及ぶ専門知識をもつ技術者のチームが参加する。これらの技術者は，設計の機能面及びシステ

ムが実際にどのように動作するか（人間の行動及び保全を含め）の両方について検討する。リーダ

ーは，チームのメンバーに対して考えられる潜在危険を探り出すことに創造的であるように促し，

システムの各部分を，幾つかの見出し語，すなわち，“なし”，“もっと多く”，“もっと少なく”，“の

一部”，“より多く”（又は“と同様に”）及び“以外の”，と結合して示すことによって手順を進め

る。全ての適用する条件又は故障モードは，それぞれ，その実行可能性，どのようにこれが起こる

か，考えられる結果（潜在危険があるか），これをどのように回避できるか，及びその回避技術は

費用に値する価値があるか，について検討する。

潜在危険解析は，プロジェクト開発の多くの段階において実施することができるが，主要設計及

び操作性の決定に影響を与えるのに十分間に合う早期に実施すると最も有効である。

HAZOP技術はプロセス業界において発展してきたものであり，ソフトウェアアプリケーション

の場合，部分改修が必要である。種々の派生方法［又はコンピュータHAZOP（“CHAZOP”）］が提

案されており，これらは，一般に，システム及びソフトウェアアーキテクチャに系統的に適用する

ために，新しい見出し語及び／又は枠組みを導入している。

参考文献：

OF-FMEA: an approach to safety analysis of object-oriented software intensive systems, T. Cichocki, J. Gorski.

In Artificial Intelligence and Security in Computing Systems: 9th International Conference, ACS '2002. Ed.

J. Soldek. Springer, 2003, ISBN 1402073968, 9781402073960

Software FMEA techniques. P.L.Goddard. In Proc Annual 2000 Reliability and Maintainability Symposium,

IEEE, 2000, ISBN: 0-7803-5848-1

Software criticality analysis of COTS/SOUP.P.Bishop, T.Clement, S.Guerra. In Reliability Engineering &

System Safety, Volume 81, Issue 3, September 2003, Elsevier Ltd., 2003

C.6.3 共通原因故障分析

注記1 この技術及び手法は，JIS C 0508-3の表A.10で引用されている。

注記2 IEC 61508-6の附属書Dも参照。

目的：複数部品に同時に同じ故障が現れることによって，冗長性の利点を損なう可能性がある並列システ

ム又は並列サブシステムの潜在故障を決定する。

説明：プラントの安全性を担う目的のシステムは，ハードウェアの冗長性及び多数決手法を用いる場合が

103

C 0508-7：2017 (IEC 61508-7：2010)

ある。これは，データの正しい処理を妨げようとする構成部品又はサブシステムのランダムハード

ウェア故障を回避するためのものである。

なお，故障によっては，複数の構成部品又はサブシステムに共通のものもある。例えば，システ

ムが単一の部屋に据え付けられた場合，空気調節の欠点のために冗長性の利点が低減される可能性

がある。同じことが，システムに及ぼす他の外部の影響，例えば，火災，洪水，電磁妨害，航空機

の墜落及び地震についても言える。システムは，運用及び保全に関わる事象によっても影響を受け

る場合がある。したがって，運用及び保全に関して，十分，かつ，明確に文書化した手順を作成し，

運用要員及び保全要員を広範囲な知識にわたって訓練することが必須である。

内的影響も，共通原因故障の主要な要因である。共通原因故障は，共通又は同一構成部品，及び

これらのインタフェースの設計フォールト，並びに構成部品の老化によって起こる可能性がある。

共通原因故障解析では，そのような潜在共通故障がないかどうか，システムを調査しなければなら

ない。共通原因故障分析の方法としては，一般的な品質管理，デザインレビュー，独立チームによ

る適合確認及びテスト，並びに同様なシステムから得た経験のフィードバックによる実際の事故解

析がある。ただし，解析の範囲は，ハードウェアだけではない。冗長システムの幾つかのチャネル

においてソフトウェア多様性を用いる場合であっても，ソフトウェアアプローチにおいて，共通原

因故障，例えば，共通仕様のフォールト，を引き起こす可能性について何らかの共通性をもつこと

がある。

共通原因故障が全く同時には起こらない場合，ある故障が全てのチャネルに共通なものになる前

にその故障を検出することを可能にするために，複数チャネル間の比較方法による予防措置を講じ

ることができる。共通原因故障分析では，この技術を考慮に入れることが望ましい。

参考文献：

Reliability analysis of hierarchical computer-based systems subject to common-cause failures. L. Xing, L.

Meshkat, S. Donohue. Reliability Engineering & System Safety Volume 92, Issue 3, March 2007

C.6.4 信頼性ブロック図

注記1 この技術及び手法は，JIS C 0508-3の表A.10で引用されており，IEC 61508-6の附属書Bで

用いられている。

注記2 B.6.6.7も参照。

目的：システムの実行又はタスクの実行を成功させるために起こらなければならない一連の事象，及び満

たさなければならない一連の条件を，図式の形でモデル化する。

説明：解析の目標を，ブロック，線及びロジック接合部からなる成功パスとして表す。成功パスは，図式

の片側から始まり，幾つかのブロック及び接合部を経て，図式の別の側まで続ける。一つのブロッ

クは，一つの条件又は一つの事象を表し，パスは，その条件が真実である場合，又はその事象が起

こった場合，そのブロックを通過することができる。パスが一つの接合部に来て，その接合部の論

理を満たす場合，パスはつながる。パスが一つの頂点に到達した場合，パスはそこから出ていく全

ての線に沿って継続することができる。図式を通って一つ以上の成功パスが存在する場合，解析の

目標は正しく作用している。

参考文献：

JIS C 5750-4-4:2011 ディペンダビリティマネジメント−第4-4部：システム信頼性のための解析技

法−故障の木解析（FTA）

105

C 0508-7：2017 (IEC 61508-7：2010)

附属書D
（参考）

既存ソフトウェアのソフトウェア安全度を判定するための

確率的アプローチ

D.1 一般

この附属書では，既存ソフトウェアについて，運用経験に基づきソフトウェア安全度を求めるための確

率的アプローチの使用に関する初期指針を提供する。このアプローチは，オペレーティングシステム，ラ

イブラリモジュール，コンパイラ及び他のシステムソフトウェアの認証方法の一部として，特に適してい

るものと考えられる。この附属書では，何が可能かの指示を提供するが，ここに示す技術は，統計的解析

に精通している人々だけが用いることが望ましい。

注記この附属書では，IEEE 352で説明されている信頼水準（confidence level）という用語を用いる。

これと同等の重要度（significance level）という用語は，IEC 61164で用いられている。

ここに示す技術は，時間経過に伴うソフトウェアの安全度水準の向上を実証するためにも用いることが

できる。例えば，JIS C 0508-3の要求事項に従ってSIL1で作成したソフトウェアは，多数のアプリケーシ

ョンにおける，ある適切な期間にわたる満足できる運用の後では，SIL2を達成したものとみなしてもよい。

次の表D.1に，具体的な安全度水準の認証に要求される，経験に基づく無故障作動要求数又は無故障運

用時間を示す。この表は，D.2.1及びD.2.3に示す結果をまとめたものである。

運用経験は，統計的テストを補足するか，又は統計的テストに取って代わるために，D.2に示すように

数学的に取り扱うこともでき，幾つかの現場からの運用経験を組み合わせること（すなわち，取り扱った

作動要求数又は運用時間を加えることによって）もできるが，これは次の条件を全て満たす場合だけであ

る。

− E/E/PE安全関連系に用いる予定のソフトウェアバージョンは，運用経験を主張するバージョンと同一

である。

− 入力スペースの運用プロファイルが類似している。

− 故障について報告し，文書化する有効なシステムがある。

− 関連前提条件（D.2を参照）を満たしている。

表D.1−安全度水準に対する信頼のために必要な運用履歴

SIL

低頻度作動要求モード

高頻度作動要求モード又は連続モード

作動要求時の設計

機能実行の失敗確率

取り扱った作動要求数

1時間当たりの

危険側故障の確率

合計運用時間

1−α＝0.99

の場合

1−α＝0.95

の場合

1−α＝0.99

の場合

1−α＝0.95

の場合

10−5以上，10−4未満

4.6×105

3×105

10−9以上，10−8未満

4.6×109

3×109

10−4以上，10−3未満

4.6×104

3×104

10−8以上，10−7未満

4.6×108

3×108

10−3以上，10−2未満

4.6×103

3×103

10−7以上，10−6未満

4.6×107

3×107

10−2以上，10−1未満

4.6×102

3×102

10−6以上，10−5未満

4.6×106

3×106

注記1 “1−α”は，信頼水準を表す。
注記2 前提条件及びこの表がどのように導かれたかの詳細は，D.2.1及びD.2.3を参照。

106

C 0508-7：2017 (IEC 61508-7：2010)

D.2 統計的テストの公式及びその使用例

D.2.1 低頻度作動要求モードの簡易統計的テスト

D.2.1.1 前提条件

前提条件を，次に示す。

a) テストデータ分布は，オンライン運転中の作動要求に関する分布に等しい。

b) テスト運用は，故障の原因に関して，相互に統計的に独立している。

c) 起きる可能性があるいかなる故障を検出するための十分な機構が存在する。

d) テストケースの数 n＞100

e) n個のテストケース中，故障は全く起こらない。

D.2.1.2 結果

信頼水準1−αにおける機能失敗確率p（作動要求当たり）は，次の式で表すことができる。

≧

又は

≦−

D.2.1.3 例

低頻度作動要求モードの機能失敗確率の例を，表D.2に示す。

表D.2−低頻度作動要求モードの機能失敗確率

1−α

0.95

3/n

0.99

4.6/n

95 %の信頼水準のSIL3の作動要求時の機能失敗確率において，D.2.1.2の式を適用した場合，前提条件

下での30 000個のテストケースになる。表D.1に，各安全度水準についての結果を要約している。

D.2.2 低頻度作動要求モードの入力スペース（ドメイン）のテスト

D.2.2.1 前提条件

唯一の前提条件は，入力スペース（ドメイン）全体にわたって，ランダムな一様分布を与えるようにテ

ストデータを選択することである。

D.2.2.2 結果

目的は，テストする低頻度作動機能（例えば，安全遮断）のための入力の正確さのしきい値δに基づい

て，必要なテスト回数nを見つけることである。二つのテスト点の平均距離は，表D.3による。

表D.3−二つのテスト点の平均距離

ドメインの寸法

任意軸の方向の二つのテスト点の平均距離

δ /1

2/1n

δ=

3/1n

δ=

注記 kは，任意の正の整数となる。1，2及び3という値は，例にすぎない。

D.2.2.3 例

二つの変数A及びBだけによる，安全遮断を考慮する。入力ペアの変数A及びBを区切るしきい値を，

A又はBの測定範囲の1 %の正確さで正しく取り扱っていることが検証できている場合，A及びBのスペ

ースに要求する一様に分配されるテストケースの数は，次のとおりである。

107

C 0508-7：2017 (IEC 61508-7：2010)

n＝1/δ2＝104

D.2.3 高頻度作動要求モード又は連続モードの簡易統計的テスト

D.2.3.1 前提条件

前提条件を，次に示す。

a) テストデータ分布は，オンライン運転中の分布に等しい。

b) 無故障の確率についての相対減少は，考慮する時間間隔の長さに比例し，他の点では一定である。

c) 起きる可能性があるいかなる故障を検出するための十分な機構が存在する。

d) テストを，テスト時間tにわたって実施する。

e) テスト時間t中，故障は全く起こらない。

D.2.3.2 結果

機能失敗確率λ，信頼水準1−α及びテスト時間tの関係は，次の式で表すことができる。

λln

機能失敗確率は，平均故障間運用時間（MTBF）に間接的に比例する。

MTBF

注記この規格では，1時間当たりの機能失敗確率と1時間における故障率とを区別しない。厳密に

は，機能失敗確率Fは次の式によって故障率fに関わるが，この規格の適用範囲は，10−5未満

の故障率に関わるので，このような小さい値に対しては，F ≈ ftでよい。

F＝1−e−ft

D.2.3.3 例

機能失敗確率λ，信頼水準1−α及びテスト時間tの関係の例を，表D.4に示す。

表D.4−高頻度作動要求モード又は連続モードの機能失敗確率

1−α

0.95

3/t

0.99

4.6/t

平均故障間時間が，108時間以上であることを95 %の信頼水準で検証するためには，3×108時間のテス

ト時間，及び前提条件を満たすことが必要である。表D.1に，各安全度水準に要求するテスト時間を要約

している。

D.2.4 完全テスト

プログラムを，既知の数N個のボールを入れたつぼと考える。各ボールは，問題とする一つのプログラ

ム特性を表す。ボールを無作為に取り出し，検査後，元に戻す。全てのボールを取り出したとき，1回の

完全なテストが終了する。

D.2.4.1 前提条件

前提条件を，次に示す。

a) テストデータ分布は，N個のプログラム特性のそれぞれを，等しい確率でテストすると考える。

b) テスト運用は，相互に独立している。

c) 起こっている全ての故障を検出する。

d) テストケースの数 n>>N

108

C 0508-7：2017 (IEC 61508-7：2010)

e) n個のテストケース中，故障は全く起こらない。

テスト運用では，一つのプログラム特性をテストする（プログラム特性は，1回のテスト運用中にテ

ストできるものである）。

D.2.4.2 結果

全てのプログラム特性をテストする確率pを，次式で表す。

−

∑

−

(

又は

ここに，

(

−

実際には，n>>Nによって特徴付けられるため，この式の評価のためには，通常，最初の項だけが問題

となる。最後の因数によって，jが大きい全ての項は非常に小さくなる。このことは，表D.5においても

見ることができる。

D.2.4.3 例

数年間にわたって，幾つかの装置で用いられてきたプログラムを考慮する。合計で，7.5×106回以上実

行したものとする。各100回目の実行は，D.2.4.1の前提条件を満たすものと推定できる。ここで行った7.5

×104回の実行を，統計的評価に取り上げることができる。4 000回のテスト運用は，徹底的にテストを行

ったものと推定できる。この推定値を，安全側の値とする。表D.5によって，必ずしも全てをテストして

いないという確率は，2.87×10−5に等しい。

N＝4 000の場合のnによって決まる最初の項の値を，表D.5に示す。

表D.5−全てのプログラム特性をテストする確率

5×104

1−1.49×10−2＋1.10×10−4−…

7.5×104

1−2.87×10−5＋4×10−10−…

1×105

1−5.54×10−8＋1.52×10−15−…

2×105

1−7.67×10−19 ＋ 2.9×10−37−…

実際には，このような推定は，その値が安全側になるように行うことが望ましい。

D.3 参考文献

この附属書の技術に関する詳細情報：

IEC 61164:2004，Reliability growth−Statistical test and estimation methods

Verification and Validation of Real-Time Software, Chapter 5. W. J. Quirk (ed.). Springer Verlag, 1985, ISBN

3-540-15102-8

Combining Probabilistic and Deterministic Verification Efforts. W. D. Ehrenberger, SAFECOMP 92, Pergamon

Press, ISBN 0-08-041893-7

Ingenieurstatistik. Heinhold/Gaede, Oldenburg, 1972, ISBN 3-486-31743-1

IEEE 352:1987，IEEE Guide for general principles of reliability analysis of nuclear power generating station

safety systems

109

C 0508-7：2017 (IEC 61508-7：2010)

附属書E

（参考）

ASICの設計のための技術及び手法の概要

注記この附属書に含まれている技術及び手法の概要は，JIS C 0508-2の附属書F（ASIC の技法及び

手段−決定論的原因故障の回避）で引用されている。ただし，この附属書は，完全なものとも，

包括的なものともみなさないことが望ましい。

E.1

(V)HDLでの設計記述

目的：ハードウェア記述言語，例えば，VHDL又はVerilogによって，高次抽象度での機能記述をする。

説明：ハードウェア記述言語，例えば，VHDL又はVerilogによる高次抽象度での機能記述をする。適用す

るハードウェア記述言語は，機能及び／又はアプリケーションを指向した記述ができるものであり，

後の段階で実装の詳細から概念化することが望ましい。データフロー，分岐，算術演算及び／又は

論理演算は，ハードウェア記述言語の割当て及び演算子によって，適用ライブラリのロジックゲー

トで手動変換をせずに，実装することが望ましい。

注記簡略化のため，“ハードウェア記述言語による高次抽象度での機能記述”は，以下，(V)HDLと

いう。

参考文献：

IEEE VHDL, Verilog + Standard VHDL Design guide

E.2

回路図入力

目的：ベンダーライブラリのゲート及び／又はマクロを用いて回路図を描くことによって回路の機能記述

をする。

説明：回路図の入力によって，回路機能性を記述する。実現する機能は，AND，OR，NOTなどの基本的

ロジック回路を，複合算術関数及び論理関数からなるマクロとともにインポートし，次に，これら

を相互接続することで実装することが望ましい。複合回路は，機能的視点から区切ることが望まし

く，階層的に相互接続された異なる図面上に配分できるようにする。相互接続信号は一意的に定義

し，階層全体にわたって明確な信号名をもつことが望ましい。グローバル信号（ラベル）の使用は，

できるだけ避けることが望ましい。

E.3

構造化記述

注記 C.2.7及びE.12も参照。

目的：回路の機能性の記述は，容易に読み取れるように，すなわち，回路機能をシミュレーションしなく

ても記述に基づき直感的に理解できるように，構造化する。

説明：回路機能性を，(V)HDLを用いて，又は回路図入力によって記述する。容易に理解できるモジュー

ル構造が望ましい。各モジュールは，同じ方法で同様に実装し，明確に定義した二次機能によって，

容易に読取可能なように記述することが望ましい。機能の実装と相互接続の実装とは，厳密に使い

分けることが望ましい。すなわち，参照した複数のサブモジュールの実装によるモジュールは，参

照したサブモジュール間の明確な相互接続を含むが，回路ロジックは含まないことが望ましい。

110

C 0508-7：2017 (IEC 61508-7：2010)

E.4

使用実績のあるツール

目的：使用ツールの各種プロジェクトでの長期にわたる十分な実務使用によって，決定論的原因故障を回

避するために，使用実績のあるツールを適用する。

説明：ASIC及びFPGAを設計するために用いるツールの大半は複雑なソフトウェアで構成されており，

その適切な機能性に関して，全くフォールトを起こすことなく動作するとは考えられないし，誤っ

た運用によってフォールトが起こる可能性もかなりある。したがって，ASIC及びFPGAの設計で

は，次に示す“使用実績のある”特徴をもつツールだけを優先することが望ましい。

− 同等の複雑さをもつ各種プロジェクトにおいて，長時間にわたって，又は多数の使用者によっ

て，用いられてきたツールを適用する（対比できるソフトウェアバージョンのもの）。

− ASIC及びFPGAの各々の設計者が，ツールの操作について長期間の十分な経験をもつ。

− 既知の不具合及びその回避策について，情報（“バグリスト”によるバージョン管理）が得られ

るように，一般的に用いられている（十分な数の使用者がいる）ツールを利用する。この情報

は，設計フローに容易に組み込めるようにし，決定論的原因故障を回避する支援となる。

− 内部ツールデータベースの整合性チェック及び確からしさチェックによって，不良出力データ

を回避する。標準ツールは，一意のデータを用いているため，内部データベースの整合性，例

えば，合成配線ツールと配置配線ツールとの間のデータベース整合性，をチェックする。

注記整合性チェックは，用いるツールの特性に帰するものであり，設計者は，これに対し

て限定的な影響しか与えられない。したがって，手動による整合性チェックの可能性

が用意されている場合，設計者は，これを適切に用いることが望ましい。

E.5

(V)HDLシミュレーション

注記 E.6も参照。

目的：(V)HDLで記述した回路のシミュレーションによる機能適合確認を行う。

説明：回路全体又は各サブモジュールをシミュレーションすることで，機能の適合確認を行う。(V)HDL

シミュレータは，適用する入力スティミュラスの結果である回路状態の内部状態の変化によって生

じる，一連の出力を検出する。検出した出力シーケンスの適合確認は，前もってトレースされた出

力信号（波形）によって，又は設計プロセスでインストールするテストベンチと呼ばれる特殊環境

によって行う。選択したシミュレータは，正確な結果をもたらすために，及びシミュレータ自体又

はモデル化不良によって発生することがある信号の不良タイミング挙動（スパイク，トライステー

トトレーシング）をマスキングするために，“使用実績のある”特徴をもつことが望ましい。

E.6

モジュールレベルでの機能テスト

注記 E.5及びE.13も参照。

目的：“ボトムアップ”機能適合確認を行う。

説明：モジュールレベルでの，例えば，シミュレーションによる，実装した機能の適合確認を行う。テス

ト対象のモジュールを，“テストベンチ”と呼ばれる代表的な仮想テスト環境においてインポート

し，コードに含まれるテストパターンによってシミュレーションする。特殊事例がある場合は，こ

れらを全て含む規定の機能について十分に高いカバレッジを要求する。“テストベンチ”のコード

による出力シーケンスの自動適合確認を，出力信号の手動チェックに優先させることが望ましい。

111

C 0508-7：2017 (IEC 61508-7：2010)

E.7

最上位の機能テスト

注記 E.8も参照。

目的：ASICの回路全体を適合確認する。

説明：このテストによって，ASICの回路全体を適合確認する。

E.8

システム環境に埋め込まれた機能テスト

注記 E.7も参照。

目的：システム環境に埋め込まれた規定機能の適合確認。

説明：このテストは，例えば，回路基板又は他のところにある，他の全ての構成部品を備えたシステム環

境において，ASICの回路の機能性全体を適合確認する。タイミング挙動を含む機能性の正しさを

適合確認するために，回路基板上の全ての関連構成部品のモデル化，及び作成したモデルとのASIC

シミュレーションを行うことが望ましい。完全な機能テストは，故障が存在するときだけ作動する

モジュールのテストも含む。

E.9

非同期構成要素の制限使用

目的：合成時の代表的なタイミング問題点の回避，シミュレーション中の曖昧さの回避及びモデリング不

良による合成の回避をテスト可能な設計の観点から行う。

説明：組合せ論理で得た，SET及びRESET信号のような非同期構成要素は，合成時の影響を受けやすく，

スパイク又は逆タイミングシーケンスをもつ回路を生成するので，使用を避けることが望ましい。

同様に，モデリング不良は，合成ツールで適切に解釈されることはなく，シミュレーションの間，

曖昧な結果をもたらす。さらに，非同期構成要素は，十分にテストできないか，又は全くテスト不

能であるため，製造時テスト及びオンラインテストのテストカバレッジを実効的に低減させる。こ

のため，限定された数のクロック信号によって，完全に同期性をもつ設計を実装することが望まし

い。多相クロックをもつシステムでは，全てのクロックを1台の中央クロックで駆動することが望

ましい。順序ロジックのクロック入力は，組合せ論理を全く含まないクロック信号だけを供給する

ことが望ましい。順序セルの非同期SET及びRESET入力は，組合せ論理を全く含まない同期信号

だけを供給することが望ましい。マスターSET及びRESETは，二つのフリップフロップを用いて

同期化することが望ましい。

E.10 一次インプットの同期化及び準安定性の制御

目的：セットアップ及びホールドタイムの違反の結果として生じる曖昧な回路挙動を避ける。

説明：外部周辺デバイスからの入力信号は，一般に非同期的であり，その状態を任意に変えることができ

る。こうした信号を，例えば，フリップフロップのようなASIC及びFPGAの同期順次回路要素で

直接処理した場合，セットアップ及びホールドタイムの違反を引き起こし，ASIC及びFPGAの予

測不可能なタイミング及び機能的挙動を発生させる。最終的に，メモリ素子が準安定となる。した

がって，各非同期入力信号は，同期ASIC回路に関して同期化して，機能上の曖昧さを避けること

が望ましい。推奨する手法を，次に示す。

− 予測可能な機能的挙動を実現するために，入力信号を二つの連続したメモリ要素（フリップフ

ロップ）又は一部の等価回路と同期化することが望ましい。

− 各非同期入力信号は，基本的に，上記方法によって同期化することが望ましい。すなわち，各

112

C 0508-7：2017 (IEC 61508-7：2010)

非同期信号を上記のような同期回路と接続し，必要な場合，同期回路の出力を多重アクセスに

利用してもよい。

− 同期回路は，並行バス信号の安定テストのため，及びサンプリングポイント近くでのデータ整

合性を制御するために用いることが望ましい。

E.11 テスト可能な設計

注記1 E.31も参照。

目的：製造時テスト又はオンラインテストに対して高いテストカバレッジを実現するために，テスト不可

能又は十分なテストができないような構造を回避する。

説明：テスト可能な設計は，次の点を回避することで決まる。

− 非同期構成要素

− ラッチ及びオンチップトライステート信号

− ワイヤードAND又はワイヤードORロジック及び冗長性ロジック

サブ回路の組合せ深さは，テスト中，重要な役割を果たす。完全なテストを行うために必要なテ

ストパターンは，回路の組合せ深さに対して指数関数的に増加する。したがって，組合せ深さが大

きい回路は，適切な手法によっても十分なテストができない。

テスト可能な指向アプローチに沿った設計は，希望するテストカバレッジが実現できることを確

実にする。実際のテストカバレッジは設計プロセスでも非常に遅い段階で決定するので，“テスト可

能な設計”の問題を十分に検討しない場合，実現可能なテストカバレッジが大幅に減少して手間が

増えることになる。

注記2 テストカバレッジは，通常，検出した縮退フォールト率によって決まる。

E.12 モジュール化

注記 C.2.8，C.2.9及びE.3も参照。

目的：回路機能のモジュラー記述を行う。

説明：機能性全体を，限定的機能をもつ異なるモジュールに明確に区分けする。これによって，厳密に定

義したインタフェースをもつモジュールの透明性を確立する。全てのサブシステムは，設計の全て

の水準において，明瞭に定義し，かつ，サイズを制限する（少数の機能とする。）。サブシステム間

のインタフェースは，可能な限り単純なものとし，横断的側面（すなわち，共有データ，情報交換）

は最小限に抑える。個々のサブシステムの複雑さも制限する。

E.13 適合確認シナリオ（テストベンチ）のカバレッジ

目的：機能テスト中に適用した適合確認シナリオの定量的及び定性的評価を行う。

説明：機能テスト中に定義した適合確認シナリオの品質，すなわち，特殊ケースが存在する場合には，全

ての特殊ケースを含む規定した機能を適合確認するために適用するテストパターン（スティミュラ

ス）の品質を，定性的及び／又は定量的に文書化することが望ましい。定量的アプローチの間，実

現したテストカバレッジ及び適用した機能テストの深さを文書化することが望ましい。結果として

得たカバレッジは，それぞれのカバレッジメトリックの水準に適合していることが望ましい。全て

の例外事項は，文書化する。定性的アプローチの場合には，検証済みコードライン本数，指示又は

適合確認する回路コードのパス（“コードカバレッジ”）を推定することが望ましい。

113

C 0508-7：2017 (IEC 61508-7：2010)

注記排他的“コードカバレッジ”解析は，ハードウェア記述の並行性が高いため，限られた関

連性しかもたないので，徹底的なチェックによって正当化することになる。“コードカバレ

ッジ”は，一般に，カバーされていない機能コードを実証するために用いられる。

E.14 コーディング指針の監視

目的：コーディングスタイルを厳密に監視することによって，構文上及び意味論上正確な回路コードを生

成する。

説明：構文のコーディング規則は，読みやすいコードの作成に役立ち，バージョン管理を含むより優れた

文書化を可能にする。通常は，この文書化によって，命令ブロック又はモジュールを体系付けてコ

メントするための規則を記載することができる。

意味論的コーディング規則は，回路機能の曖昧な実装を含む不完全な合成を引き起こす構成要素

を回避することによって，代表的な実装問題を回避する助けとなる。通常の規則によって，例えば，

非同期構成要素又は予想外のタイミングシーケンスを発生する構成要素を回避する。一般に，ラッ

チの使用又はデータとクロック信号との結合が，曖昧さを導く。

ASIC開発プロセス中の決定論的原因設計フォールトを回避するために，設計指針を推奨する。コ

ーディングスタイルは，ある側面では設計効率を制限するが，その代わりに，ASIC開発プロセス中

の故障を回避するというメリットをもたらす。コーディングスタイルは，特に，次のような設計に

有効である。

− 典型的なコーディング欠陥又は故障の回避

− 曖昧な合成結果を生成する，問題となる構成要素の使用の制限

− テスト可能な設計

− コード使用の透明性及び容易性

コーディングスタイルの例

コーディングスタイルの例を，次に示す。

1) コードは，機能及び実装の詳細を理解するために，必要なだけのコメントを含めることが望ましい。

設計開始前に，使用する規約を定義する必要がある。定義した規約の適合性は，設計フェーズで確

認することが望ましい。この場合のコーディングスタイルは，次による。

1.1) 標準ヘッダは，履歴，仕様への相互参照，責任（担当），バージョン番号のような設計附属データ，

変更要求などを含める。

1.2) 容易に読み取れるテンプレートとする。同等プロセスは，同一手順によって記述する。すなわち，

回帰性プロセスに対して，前もって定義したテンプレートを用いる（if-then-elseなど）。

1.3) 的確で，可読性の高い命名規則とする。例えば，大文字と小文字との使い分け，接頭辞及び接尾

辞の使用，更にポート名，内部信号，定数，変数，負論理レベルの的確な識別（例えば，xxx̲n）

など。

1.4) モジュールサイズの制限及びモジュール当たりのポート数を，コードの可読性を向上するために

制限する。

1.5) 構造的及び防衛的なコード開発を行う。例えば，状態情報は，コードを容易に変更するために，

FSM（有限状態機械）にカプセル化（情報隠し）する。

1.6) レンジチェックなどの，確からしさチェックを実現する。

114

C 0508-7：2017 (IEC 61508-7：2010)

1.7) 次の制約条件及び指示を回避する。

− バス信号に対する昇順レンジ（xからyへ）の使用

− Verilogの“Disable”命令（goto命令に相当する。）

− 多次元アレイ（＞2），レコード

− 符号付き及び符号なしデータ型の組合せ。

2) 次による完全同期設計（クロックを中央クロックから導くことが認められている。）

2.1) モジュールの出力は同期化することが望ましく，テスト可能性及び静的タイミング解析も支援す

ることが望ましい。

2.2) ゲート付きのクロックは，特別な注意をもって取り扱うことが望ましい。

3) データとクロックとの結合を回避することによって，テスト可能性，レイアウト前後のデータ間の

再現性及びRTL（レジスタ転送レベル）挙動との適合性を向上させる。

4) 冗長性ロジックは，テストができないので，回避することが望ましい。

データとクロック信号との結合

冗長性ロジック

5) 組合せ論理におけるフィードバックループは，設計を不安定にし，テストができないので，回避す

ることが望ましい。

6) フルスキャン設計を推奨する。

7) ラッチを回避することによって，テスト可能性を向上させ，合成中のタイミング制約を小さくする。

8) マスターリセット及び全ての非同期入力は，二つの連続したメモリ要素（フリップフロップ）又は

等価回路（準安定）によって同期化することが望ましい。

9) マスターリセットを除き，非同期セット及びリセットを回避することが望ましい。

10) モジュールポートレベルでの信号の種類は，std̲logic 又はstd̲logic̲vectorであることが望ましい。

E.15 コードチェッカーの適用

目的：コードチェッカーツールによって，コーディング規則（“コーディングスタイル”）の適合確認を自

動的に行う。

説明：コードチェッカーの適用は，コーディングスタイルの順守及びオンラインでの文書作成を，かなり

の範囲にわたって自動的に支援する。ただし，自動的なコードチェッカーは，通常，コードの構文

及び意味論をチェックしている。したがって，このようなツールを適用する場合には，設計者が別

途実装して，評価しなければならないプロジェクト固有のコーディング規則によって，一般コーデ

ィング規則（“ツール固有”）を拡張することが望ましい。

E.16 防御的プログラミング

C.2.5を参照する。

115

C 0508-7：2017 (IEC 61508-7：2010)

E.17 シミュレーション結果の文書化

目的：規定した回路機能の適合確認のためのシミュレーションの成功に必要な全てのデータを文書化する。

説明：モジュール，チップ又はシステムの水準の機能シミュレーションに必要な全てのデータを十分に文

書化し，次の目的のために記録保管する。

− 後のフェーズにおいて，ターンキー方式でいつでもシミュレーションを繰り返すため。

− 規定した全ての機能の正確さ及び完全性を実証するため。

この目的のために，次に示すデータベースをアーカイブにすることが望ましい。

− 例えば，シミュレータ，対応するバージョンの合成ツール，必要なシミュレーションライブラ

リなど，適用するツールのソフトウェア一式を含むシミュレーションのセットアップ

− シミュレーションの時間に関する完全な詳細を備えたシミュレーションログファイル，適用す

るツール及びそのバージョン，並びに該当する場合は，完全な回避策報告書

− 特に，手動検査及び取得結果の文書類の場合，信号フローを含む全ての関連シミュレーション

結果

E.18 コード検査

注記1 C.5.14も参照。

目的：回路記述をレビューする。

説明：回路記述のレビューは，次によって実施することが望ましい。

− コーディングスタイルのチェック

− 記述した機能性の，仕様に基づく適合確認

− 防衛的コーディング，エラー及び例外処理のチェック

注記2 (V)HDLのシミュレーションを行わない場合，コード検査の完全さ及び達成した成果の

品質は，(V)HDLシミュレーションによって達成したものと同等の品質をもつことが望

ましい。

E.19 ウォークスルー

注記1 C.5.15も参照。

目的：ウォークスルーによって，回路記述をレビューする。

説明：コードウォークスルーは，プログラムに対する小さなテストケースセット，代表的な入力セット及

び対応する期待出力セットを選択するウォークスルーチームで構成する。次に，テストデータは，

プログラムのロジックを通じて，手動でトレースする。

注記2 独立した手法として，これは，非常に複雑度の低い回路だけに適用することが望ましい。

(V)HDLシミュレーションに失敗した場合であっても，ウォークスルーの完全性及び成

果の品質は，(V)HDLシミュレーションによって達成したものと同等の品質をもつこと

が望ましい。

参考文献：

IEC 61160:2005，Design review

E.20 妥当性確認済みソフトコアの適用

目的：妥当性を確認したソフトコアを適用することで，ソフトコア動作中の機能失敗を回避する。

116

C 0508-7：2017 (IEC 61508-7：2010)

説明：ベンダー側でソフトコアの妥当性確認をする場合，次の必要な事項を履行することが望ましい。

− 安全関連系の運用のためにソフトコアの妥当性確認を行い，計画対象システムと同等以上の安

全度水準をもつことが望ましい。

− ソフトコアの妥当性確認に必要な，全ての想定事項及び制限条件に従うことが望ましい。

− ソフトコアの妥当性確認に必要な全ての文書は，容易に入手できることが望ましい。E.17も参

照。

− 各ベンダー仕様を厳密に順守し，適合性の証拠を文書化することが望ましい。

E.21 ソフトコアの妥当性確認

注記 E.6も参照。

目的：設計ライフサイクル中にソフトコアの妥当性確認をすることによって，ソフトコア動作中の機能失

敗を回避する。

説明：ソフトコアが安全関連系での運用のために特に開発されたものでない場合，生成したコードは，全

てのソースコードに適用するものと同じ仮定で妥当性確認をすることが望ましい。すなわち，考え

られる全てのテストケースを定義し，実装することが望ましい。次に，機能の適合確認をシミュレ

ーションで得ることが望ましい。

E.22 タイミング制約をチェックするためのゲートネットリストのシミュレーション

目的：合成の間に実現したタイミング制約条件を，独立した適合確認で行う。

説明：ライン遅延及びゲート遅延のバックアノテーションを含む合成によって生成する，ゲートネットリ

ストによってシミュレーションを行う。高い比率でタイミング制約条件をカバーし，全ての最悪の

場合のタイミングパスを含めるように，回路を刺激するためのスティミュラスを導き出す。一般に，

E.6の“モジュールレベルでの機能テスト”又はE.7の“最上位の機能テスト”を実行するために

必要なスティミュラスは，スティミュラスを選択するための適切な基準となるが，機能テスト中十

分なテストカバレッジが達成できることが条件である。回路は，規定クロックレートを最大にして，

最良の場合及び最悪の場合の条件でテストする。

タイミング適合確認は，ターゲットライブラリのメモリ要素（フリップフロップ）のセットアッ

プ及びホールド時間を自動チェックして，回路機能の適合確認をすることで実施する。機能適合確

認は，主として，チップの出力を観察することで実施する。この適合確認は，回路の出力信号を適

切な基準モデル又は回路の(V)HDLソースコードと対比することで自動化できる。このテストは，

“リグレッションテスト”と呼ばれ，出力信号の手動チェックよりも望ましい。

注記この手法を適用することで，シミュレーションの間，実際にスティミュラスを受けたタイ

ミングパスのタイミング挙動だけが適合確認できる。したがって，一般的に，特別の手法

では，回路の完全なタイミング解析を提供することはできない。

E.23 伝ぱ（播）遅延の静的解析（STA）

目的：合成の間に実現したタイミング制約条件を，独立した適合確認で行う。

説明：静的タイミング解析（STA）は，バックアノテーションを考慮した合成ツールが生成したネットリ

スト（回路）の全てのパス，すなわち，合成ツールによる推定ライン遅延，及び実際のシミュレー

ションをしないゲート遅延を解析する。したがって，一般に，回路全体のタイミング定数を完全に

117

C 0508-7：2017 (IEC 61508-7：2010)

解析することができる。テスト対象回路は，規定のクロックレートを最大にした最良の場合及び最

悪の場合の条件で，該当するクロックジッタ及びデューティサイクルスキューを考慮して解析する。

非関連タイミングパスの数は，適切な設計技術を採用することによって，一定の最小数に限定でき

る。設計を開始する前に，容易に読取可能な結果をもたらす使用中の技術を調査，解析及び定義す

ることが望ましい。

注記 STAは，次の場合，既存の全てのタイミングパスを明確にカバーしていると想定できる。

a) タイミング制約条件を適切に規定している。

b) テスト対象回路は，STAツールによって解析できるタイミングパス，すなわち，一般に，完全

同期回路をもつケースだけを含んでいる。

E.24 シミュレーションによる標準モデルに基づくゲートネットリストの適合確認

目的：合成したゲートネットリストの機能等価性チェックを行う。

説明：合成ツールで生成したゲートネットリストをシミュレーションする。シミュレーションによる回路

の適合確認のために適用するスティミュラスは，E.6の“モジュールレベルでの機能テスト”及び

E.7の“最上位の機能テスト”で，それぞれ適用したスティミュラスと正確に一致する。機能の適

合確認は，主として，チップの出力を観察することで行う。この適合確認は，回路の出力信号を適

切な基準モデル又は回路の(V)HDLソースコードと対比することで自動化できる。このテストは，

“リグレッションテスト”と呼ばれ，出力信号の手動チェックよりも望ましい。

注記この手法を適用することで，シミュレーションの間，実際にスティミュラスを受けたパス

の機能的挙動だけを適合確認できる。したがって，テストカバレッジは，それぞれ，モジ

ュールレベル又は最上位での本来の機能テストと同様である。この手法を，形式的等価テ

ストで補足することもできる。いずれの場合も，(V)HDLソースコードの機能適合確認は，

合成ツールが最後に生成したネットリストを用いて行う。

E.25 ゲートネットリストと標準モデルとの比較（形式的等価テスト）

目的：シミュレーションから独立した，機能等価性チェックを行う。

説明：(V)HDLソースコードで記述した回路機能性と，合成によって生成したゲートネットリストの回路

機能性とを比較する。形式的等価原理に基づくツールは，回路の様々な表現形態，例えば，(V)HDL

記述又はネットリスト記述の機能等価性を適合確認することができる。この手法を適用することに

よって，機能シミュレーションが不要になり，独立した機能チェックが可能となる。適用したツー

ルが完全な等価性を証明できて，かつ，報告済みの全ての不一致が手動検査又は自動検査によって

評価された場合に限り，この手法を適用して成果を上げることができる。

注記この手法は，E.24と結び付けると効果的である。いずれの場合も，(V)HDLソースコード

の機能適合確認は，合成ツールで生成した最終ネットリストを用いて実施することが望ま

しい。

E.26 ベンダー要求事項及び制約のチェック

目的：ベンダー要求事項を確認して，製造時の故障を回避する。

説明：例えば，最小及び最大のファンイン及びファンアウト，最大ワイヤ長（ライン遅延），信号の最大

スルーレート，クロックスキューなどの，ベンダー要求事項及び制約条件を合成ツールによって慎

118

C 0508-7：2017 (IEC 61508-7：2010)

重にチェックすることによって，製品の信頼性を向上させる。製造工程に対する要求事項の重要性

のほかに，要求事項に対する違反も，シミュレーションで用いる適用モデルの妥当性に大きな影響

を与える。したがって，ベンダー要求事項及び制約条件に何らかの形で違反した場合，シミュレー

ション結果は不良となり，望ましくない機能性を生成する。

E.27 合成制約条件，結果及びツールの文書化

目的：最終ゲートネットリストを生成するための最適な合成に必要な，全ての制約条件を文書化する。

説明：全ての合成制約条件及び結果を文書化することは，次の理由から，不可欠である。

− 後のいずれかのフェーズで合成を再生成するため。

− 適合確認のために独立した合成結果を生成する。

基本的文書を，次に示す。

− 適用したツール及び合成ソフトウェア，これらの適用したバージョン，適用した合成ライブラ

リ，並びに定義した制約条件及びスクリプトを含む，合成セットアップ

− 時刻が注記された合成ログファイル，適用したバージョン付きツール及び合成の文書一式

− 推定時間遅延をもつ生成済みネットリスト［標準遅延フォーマット（SDF）ファイル］

E.28 使用実績のある合成ツールの適用

目的：ゲートネットリストにある回路に対する，(V)HDL記述のツールベースの変換を行う。

説明：ターゲットASICライブラリの適切なゲートと回路プリミティブとの結合によって，回路機能性の

(V)HDLソースコードのツールベースのマッピングを行う。希望する機能性を満たすために考えら

れる各種実装から選択した実装は，タイミング（クロック率）及びチップエリアのような合成制約

条件で得られる最適結果に依存する。

E.29 使用実績のあるターゲットライブラリの適用

注記 E.4も参照。

目的：不良ターゲットライブラリが引き起こす決定論的原因故障を回避する。

説明：ASICの開発において合成及びシミュレーションのターゲットライブラリは，共通データベースか

ら得られるため，独立したものではない。決定論的原因故障の代表的な例を，次に示す。

− 回路要素の実挙動とモデル化による挙動との間の曖昧さ

− 例えば，セットアップ及びホールドタイムの，不十分なモデル化

したがって，次に示す“使用実績のある”技術及びターゲットライブラリだけを，安全機能を果

たすASICの設計に用いることが望ましい。

− 相当する複雑さ及びクロックレートをもち，プロジェクトで相当長期間用いられてきたターゲ

ットライブラリ。

− ライブラリのモデル化の正確さが十分に期待できるように，十分長期間にわたって利用可能な

技術及びこれに対応するターゲットライブラリ

E.30 スクリプトに基づく手順

目的：結果の再現性を支援し，合成サイクルを自動化する。

説明：適用した制限条件の定義を含め，合成サイクルの自動化及びスクリプトベースの制御を行う。合成

119

C 0508-7：2017 (IEC 61508-7：2010)

制約条件一式の厳密な文書化のほかに，(V)HDLソースコードの変更後，同一条件によってネット

リストを再現することを支援する。

E.31 テスト構造の実装

目的：最終の製造時テストを保証するため，テスト可能なASICを設計する。

説明：テスト可能な設計は，様々なテスト構造の実装によって，容易にテスト可能な回路を生成できる。

このようなテスト構造の例を，次に示す。

− スキャンパススキャン技術では，フリップフロップの全て（フルスキャン設計）又はその一

部（部分スキャン設計）によって，単一チェーン，又はシフトレジスタのチェーンを構成する

複数チェーンの形に結合する。スキャンパスは，回路ロジック全体のテストパターンが自動的

に生成できるようにする。ツール生成テストパターンは，ATPG（“自動テストパターンジェネ

レータ”）と呼ばれる。スキャンパスの実装によって，回路のテスト可能性が大幅に向上し，妥

当な労力によって，テストカバレッジは98 %を超える。したがって，可能な場合は，フルスキ

ャンパスを実装することが望ましい。

− NANDツリー NANDツリーでは，回路の全ての一次入力をカスケード状に接続し，チェーン

を構築する。適切なテストパターン（“ウォーキングビット”）を適用することで，入力の切替

え挙動（タイミング及びトリガーレベル）をテストすることができる。NANDツリーは，一次

入力をそのまま特性化する手法である。回路の切替え挙動を他の方法ではテストできない場合，

このツリーの実装が望ましい。

− 内蔵自己テスト（BIST）回路の自己テスト，特に埋め込みメモリの自己テストは，オンチッ

プテストパターンジェネレータを実装することで非常に効率よく実施できる。BISTは，擬似ラ

ンダムテストパターンを適用し，実装した回路構造のシグネチャを評価することで，回路構造

を自動的に適合確認ができる。BISTは，特にメモリテスト用の追加手段とすることが望ましい。

スキャンパステストは，BISTで置き換えることができる。

− 自己消費電流テスト（IDDQテスト）スタティックCMOS回路は，主として，スイッチング

によって電流を消費する。したがって，絶対的に無欠陥の回路は，テストパターンが静止状態

に保持されている限り，無視できるほどの僅かな電流（漏れ電流1 μA未満）しか消費しない。

IDDQテストは非常に効果的で，2組のテストパターンを適用するだけで，50 %を超えるテス

トカバレッジを実現する。IDDQテストは，ATPGによって生成する合成テストパターンのほか

に，機能テストパターンにも適用できる。このテスト方法は，実際に非常に役に立ち，他のテ

ストではほとんど検出できないか，又は全く検出できない故障を検出することができる。した

がって，この手法は，正規の製造時テストに追加する形で適用することが望ましい。

− 境界走査（バウンダリスキャン） JTAG規格に準拠するプリント配線板の構成部品の相互接続

を適合確認するために実装する，テストアーキテクチャをいう。チップレベルでのモジュール

相互接続を適合確認するために，同じ方針を適用することもできる。境界走査（バウンダリス

キャン）は，主に，プリント配線板のテスト可能性を改善するために推奨されている。

E.32 シミュレーションによるテストカバレッジの推定

目的：製造時テスト中，実装したテストアーキテクチャによって，達成したテストカバレッジを決定す

る。

120

C 0508-7：2017 (IEC 61508-7：2010)

説明：スキャンパステスト，BIST，機能テストパターン，又はその他手法によって達成するテストカバレ

ッジは，フォールトシミュレーションで決定できる。フォールトシミュレーションの間，フォール

トを挿入した回路にテストパターンを適用する。適用したスティミュラスに対する回路のフォール

ト応答は，この挿入したフォールトに対応するため，テストカバレッジを引き上げる。フォールト

シミュレーションによって，縮退フォールト，“1縮退フォールト”及び“0縮退フォールト”，の

検出ができ，達成するテストカバレッジは適用したテストパターンの品質を表している。フォール

トシミュレーションは，一般に，スキャンパスの一部，例えば，部分スキャンパスの場合を除く，

ロジックに伴うフォールトを検出するために，非常に効果的に利用できる。

E.33 ATPGツールの適用によるテストカバレッジの推定

目的：合成テストパターン（スキャンパス，BIST）によって，製造時テストにおいて期待するテストカバ

レッジを決定する。

説明：現在，スキャンパスを実装した回路に対して，擬似ランダムテストパターン又はアルゴリズムテス

トパターンを発生する各種手順がある。ATPGなどの合成ツールは，合成の間に，未検出フォール

トの一覧表を作成する。これによって，テストカバレッジを推定することができ，適用したテスト

パターンで達成する下限を決定できる。このテストカバレッジは，スキャンパスでカバーする回路

ロジックに限定されることに注意することが重要である。メモリ，BIST又はスキャンパスが組み込

まれていない回路の一部などのモジュールは，テストカバレッジの推定を考慮していない。

E.34 適用ハードコアには使用実績があるといえる正当な根拠

目的：ハードコア適用中の決定論的原因故障を回避する。

説明：ハードコアは，通常，希望する機能性を表すブラックボックスとみなされ，希望する回路構成部品

を提供するターゲット技術のレイアウト基本データで構成されている。想定する機能故障は，標準

マイクロプロセッサ，メモリなどの個別部品と同様に取り扱う。適用したターゲット技術において，

用いるコアが使用実績がある構成部品とみなせる場合，このハードコアは，正しい機能性を適合確

認することなく用いることができる。この場合，回路の残りの部分を集中的に適合確認することが

望ましい。

E.35 妥当性確認済みハードコアの適用

注記 E.6も参照。

目的：ハードコア適用中の決定論的原因故障を回避する。

説明：コアは複雑な性質をもち，制約条件が想定されていることから，コアの妥当性確認は，(V)HDLソ

ースコードに基づく設計フェーズにおいて，ベンダーが実施することが望ましい。妥当性確認は，

適用する構成部品のコンフィグレーション及びターゲット技術に対してだけ正当性をもつことが

できる。

E.36 ハードコアのオンラインテスト

注記 E.13も参照。

目的：ハードコア適用中の決定論的原因故障を回避する。

説明：オンラインテストの適用によって，用いるハードコアの適切機能及び実装を適合確認する。この手

121

C 0508-7：2017 (IEC 61508-7：2010)

法を適用する場合，効率的なテストコンセプトが必要であり，適用したコンセプトの評価を文書化

することが望ましい。

E.37 設計ルールチェック（DRC）

目的：ベンダーの設計ルールを適合確認する。

説明：生成したレイアウト，例えば，最小ワイヤ長，最大ワイヤ長及びレイアウト構造の設置に関する幾

つかの規則などの，ベンダー設計規則について，適合確認する。DRCの完全かつ適切な実行は，詳

細に文書化することが望ましい。

E.38 レイアウト対回路図の適合確認（LVS）

目的：レイアウトの独立した適合確認を行う。

説明：LVSによって，レイアウトデータを基に回路機能を抽出し，抽出した回路接続と回路要素を入力し

たネットリストとを比較する。これによって，回路レイアウトが回路機能を規定するネットリスト

と等価であることを確認する。LVSの完全かつ適切な実行は，詳細に文書化することが望ましい。

E.39 使用実績が3年未満のプロセス技術に対する追加スラック（＞20 %）

目的：プロセス及びパラメータが激しく変動する場合であっても，実装した回路機能性の堅ろう（牢）性

を保証する。

説明：実回路挙動は，特に，微細構造（例えば，0.5 μm未満）の場合，物理的影響の重なり数によって決

まる。事実，詳細な知識が不足し，必要な簡易化ができないため，回路要素の厳密モデルが得られ

ない場合がある。幾何学的配置が微細になるにつれて，ライン遅延が更に支配的な役割を果たして

いる。配線に沿った信号遅延及び配線間のクロスカップリング容量は，比例以上に増大する。この

信号遅延は，ゲート遅延と比べて，もはや無視する訳にはいかない。推定されるライン遅延は，幾

何学的配置の微細化に伴うリスクの増大を表している。

したがって，製造時のパラメータの大きな変動又は正確なモデル化の欠如があっても，回路機能

の適切動作を保証するために，使用実績が3年未満のプロセスを用いて設計した回路の最小及び最

大タイミング制約条件に対して，十分なスラック（＞20 %）を設計に入れることが望ましい。

E.40 バーンインテスト

目的：製造する半導体チップの堅ろう（牢）性を保証し，初期故障を除去する。ベアチップ製品は，例え

ば，ウエハレベルではストレス方法などによって証明するが，バーンインでその堅ろう（牢）性を

証明する必要はない。

説明：バーンインテストは，最高許容使用温度（一般に，125 ℃）で実施することが望ましい。テスト期

間は，目標とするSIL水準又は指定のバーンイン推奨条件，例えば，ASIC製造業者の推奨条件に

よって決める。バーンインは，次の目的に利用できる。

− 初期故障の除去（故障率減少を伴うバスタブ曲線の始まり）

− 初期故障が製造中及びテスト中に既に除去済みであることの証明（すなわち，製造ラインから

出たデバイスは，既にバスタブ曲線の一定故障率の範囲内に入っている。）

122

C 0508-7：2017 (IEC 61508-7：2010)

E.41 使用実績のあるデバイスシリーズの適用

目的：製造する半導体チップの信頼性を保証する。

説明：安全設計を行う製造業者は，用いるプログラマブルデバイス技術及び関連する開発ツールについて

十分な適用経験をもつことが望ましい。

E.42 使用実績のある製造工程

目的：製造する半導体チップの信頼性を保証する。

説明：使用実績のある製造工程は，十分なシリーズ製品の生産経験をもつ。

E.43 製造工程の品質管理

デバイス製造工程中の品質手法及び管理メカニズムは，継続的な工程管理を確実にする。例えば，テス

ト構造の光学的若しくは電気的管理，温度湿度バイアス試験又は温度サイクル試験（JIS C 60068-2-1，JIS

C 60068-2-2などを参照）を実施する。

E.44 デバイスの製造品質合格

デバイス品質は，選択した部品応力テスト，例えば，温度湿度バイアス試験又は温度変更試験（JIS C

60068-2-1，JIS C 60068-2-2など参照）を実施して証明する。デバイス製造業者から，その証拠を入手する。

E.45 デバイスの機能品質合格

全てのデバイスについて，機能に関するテストを実施する。デバイス製造業者から，その証拠を入手す

る。

E.46 品質規格

ASIC製造業者は，十分な品質マネジメントを定めることが望ましい。例えば，ISO 9000認証，SSQA（標

準供給業者品質評価）などに基づいて，品質及び信頼性ハンドブックの中に文書化する。

123

C 0508-7：2017 (IEC 61508-7：2010)

附属書F

（参考）

ソフトウェアライフサイクル各フェーズの特性の定義

ソフトウェアライフサイクル各フェーズの特性の定義を，表F.1〜表F.10に示す。

表F.1−ソフトウェア安全要求仕様

［JIS C 0508-3の7.2（ソフトウェア安全要求仕様）及び表C.1参照］

番号

特性

定義

1.1

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

ソフトウェア安全要求仕様によって，安全ライフサイクルの初期フェーズ

から生じて，ソフトウェアに割り当てた全ての安全ニーズ及び制約条件に対
処する。

安全ニーズ及び制約条件は，通常，ソフトウェア安全要求仕様の活動への

入力で記述する。これには，ソフトウェアが実行してはならないこと，又は
回避しなければならないことについての仕様を含んでもよい。

1.2

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

ソフトウェア安全要求仕様によって，ソフトウェアに割り当てた安全ニー

ズ及び制約条件に対する適切な回答を提供する。

規定したことが全ての必要な条件において，実際に安全性を保証すること

を確実にすることが目的である。

1.3

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

ソフトウェア安全要求仕様の内部完全性及び整合性を取り扱う。
ここでは，ステートメントから生じる可能性がある全ての機能及び状況に

関する，全ての必要情報を提供し，矛盾したステートメント又は整合性のな
いステートメントは表明しない。

安全ニーズに関する完全性及び整合性に反する内部完全性及び整合性は，

ソフトウェア安全要求仕様だけに基づいて評価することができる。

1.4

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

ソフトウェア安全要求仕様は，これを読む必要がある全ての人が，以前か

らこのプロジェクトに関わっていない場合であっても，必要な知識があると
きには，過大な努力をせずに十分に理解可能である。

適合確認，及び可能な場合，部分改修を容易にすることは，重要な目的の

一つである。

1.5

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

ソフトウェア安全要求仕様は，EUCの安全性に必要のない要求事項を含ま

ない。

ソフトウェアの設計及び実装を不必要に複雑化させることを回避し，フォ

ールトのリスク，及び安全性に重要でない機能が安全性にとって重要なもの
を妨げたり，脅かしたりするようなリスクを減らすことが目的である。

1.6

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

ソフトウェア安全要求仕様によって，ソフトウェアがこの仕様自身を満た

しているという，客観的な証拠を生成するようなテスト及び調査をもたらす。

124

C 0508-7：2017 (IEC 61508-7：2010)

表F.2−ソフトウェアの設計及び開発：ソフトウェアアーキテクチャ設計

［JIS C 0508-3の7.4.3（ソフトウェアアーキテクチャ設計の要求事項）及び表C.2参照］

番号

特性

定義

2.1

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

ソフトウェアアーキテクチャ設計によって，ソフトウェア安全要求仕様が

提起する全ての安全ニーズ及び制約条件に対処する。

2.2

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

ソフトウェアアーキテクチャ設計によって，規定したソフトウェア安全要

求事項に対して適切な回答を提供する。

2.3

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

ソフトウェアアーキテクチャ設計及び設計文書は，規定したあらゆるソフ

トウェア安全要求事項からも独立していることが特定できるフォールトを含
まない。

このようなフォールトには，例えば，デッドロック，許可していないリソ

ースへのアクセス，リソースリーク，本質的欠陥（すなわち，設計自体から
生じる全ての状況への対処がない。）がある。

2.4

単純さ及び理解容易性
挙動の予測可能性

ソフトウェアアーキテクチャ設計によって，全ての規定した状況において，

ソフトウェアの機能に関して正確かつ厳密な予測ができる。

これらの状況には，特に，エラー状況及び故障状況を含む。
予測の可能性は，特に，機能が，設計者又は使用者による制御ができない

ような項目に基づいていないことを意味する。

2.5

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

ソフトウェアアーキテクチャ設計及び設計文書によって，規定した全ての

ソフトウェア安全要求事項が設計で適切に考慮されること，及び設計が本質
的フォールトをもたないということの信頼できる証拠を作成し，その作成を
容易にする。

検証可能性には，用いる検証技術に従って，簡易性，モジュール性，明瞭

性，テスト可能性，証明可能性などの派生特性を意味する場合がある。

2.6

フォールトトレランス

ソフトウェアアーキテクチャ設計によって，ソフトウェアにエラー（内部

エラー，操作者又は外部システムのエラー）が存在する場合にも，ソフトウ
ェアが安全に挙動することを保証する。

防衛的設計は，能動的でも，受動的でもよい。能動的防衛的設計には，エ

ラーの検出，報告及び封じ込め，グレースフルデグラデーション，正常動作
再開前の望ましくない副次的影響の除去などの機能を含む場合がある。受動
的防衛的設計には，ソフトウェアが特定のアクションを取らずに，特定タイ
プのエラー又は特定の条件（入力の急増，特定の日時）の侵入を許さないこ
とを保証する機能を含む。

2.7

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

ソフトウェアアーキテクチャ設計によって，共通原因故障モード及び故障

に対する効果的な予防措置を特定することを容易にする。

表F.3−ソフトウェアの設計及び開発：支援ツール及びプログラミング言語

［JIS C 0508-3の7.4.4（プログラミング言語を含む支援ツールの要求事項）及び

表C.3（決定論的安全度に関する特性−ソフトウェア設計及び開発−支援ツール及びプログラミング言語）参照］

番号

特性

定義

3.1

要求するソフトウェア特性で
ソフトウェアの作成を支援

エラー検出を行う手法，又はエラーを起こしやすい構造を排除する手法

3.2

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

ツールの動作の全側面を包括的にカバーし，フィードバックする規定

3.3

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

与える全ての入力に対する，ツール出力の整合性及び正確さ

125

C 0508-7：2017 (IEC 61508-7：2010)

表F.4−ソフトウェアの設計及び開発：詳細設計

［JIS C 0508-3の7.4.5（詳細設計及び開発の要求事項−ソフトウェアシステム設計），

7.4.6（コード実装の要求事項）及び表C.4参照］

番号

特性

定義

4.1

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

ソフトウェアの詳細設計及び製作の手法を採用することによって，結果と

して得られたソフトウェアが，ソフトウェアに割り当てた全ての安全ニーズ
及び制約条件に対処していることを確実にする。

4.2

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

ソフトウェアに割り当てた安全要求事項を，開発したソフトウェアが満た

していると主張するための具体的証拠をもつ。

4.3

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

開発したソフトウェアは，本質的フォールトをもたない。
このようなフォールトには，例えば，デッドロック，許可していないリソ

ースへのアクセス，リソースリークがある。

4.4

単純さ及び理解容易性
挙動の予測可能性

開発したソフトウェアの挙動は，客観的で，説得力のあるテスト及び解析

で予測可能である。

4.5

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

開発したソフトウェアは検証可能であり，テスト可能である。

4.6

フォールトトレランス及びフ
ォールト検出

技術及び設計によって，開発したソフトウェアにエラーが存在する場合で

あっても，安全に挙動する保証を与える。

4.7

共通原因故障の回避性

技術及び設計によって，共通原因故障モードを特定し，ソフトウェア故障

に対する効果的な予防措置を提供する。

表F.5−ソフトウェアの設計及び開発：ソフトウェアモジュールのテスト及び統合

［JIS C 0508-3の7.4.7（ソフトウェアモジュールテストの要求事項），

7.4.8（ソフトウェア統合テストの要求事項）及び表C.5参照］

番号

特性

定義

5.1

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

ソフトウェアテストによって，ソフトウェア設計仕様の全ての要求事項に

対処していることを確実にするために，ソフトウェア挙動を十分に調査する。

5.2

ソフトウェア設計仕様に関す
るテスト及び統合の正確性
（正常完了）

モジュールテストタスクを完了することによって，安全要求事項を満たし

ていると主張するための具体的証拠をもつ。

5.3

再現性

モジュールのテスト及び統合の一環として実施する個別の評価を繰り返し

て，整合性のある結果を得る。

5.4

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

モジュールのテスト及び統合は，正しいバージョンの要素及びソフトウェ

アを適用することで，主張できる結果を得る。この結果を，“出来上がった”
ソフトウェアの特定コンフィグレーションにリンクさせることができる。

126

C 0508-7：2017 (IEC 61508-7：2010)

表F.6−プログラマブル電子機器の統合（ハードウェア及びソフトウェア）

［JIS C 0508-3の7.5（プログラマブル電子装置統合）及び

表C.6（決定論的安全度に関する特性−プログラマブル電子装置の統合）参照］

番号

特性

定義

6.1

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

統合は，システム要素が，予見可能な全ての使用条件下及びシステム故障

時において，意図した機能を実行し，かつ，意図しない機能を実行しないこ
とを実証できるだけの，適切な深さ及びカバレッジを保証する。

これは，適合確認，目標とする設計水準及び統合の各側面（例えば，モジ

ュール間相互作用の完全性の適合確認）のために利用する原則を対象として
いる。

6.2

設計仕様に関する統合の正確
性（正常完了）

統合は，正確な仮定を基本とする。
正確な仮定には，例えば，期待する結果，検討した使用の条件，テスト環

境の代表性などの正確さがある。

統合タスクを完了することによって，安全要求事項を満たしているという

具体的証拠をもつ。

6.3

再現性

統合の一環として個別の評価を繰り返すことによって，整合性のある結果

を得る。

6.4

正確に定義した統合構成

統合は，正しいバージョンの要素及びソフトウェアを記述どおりに効果的

に適用することで，主張できる結果を伴った適切な保証を与える。この結果
を“出来上がった”ソフトウェアの特定コンフィグレーションにリンクさせ
ることができる。

表F.7−システム安全の妥当性のソフトウェア側面

［JIS C 0508-3の7.7（ソフトウェアのシステム安全妥当性確認）及び表C.7参照］

番号

特性

定義

7.1

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

ソフトウェアの妥当性確認によって，ソフトウェア設計仕様の全ての要求

事項に対応する。

7.2

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

ソフトウェアの妥当性確認タスクを完了することによって，安全要求事項

を満たしているという具体的証拠をもつ。

7.3

再現性

ソフトウェア妥当性確認の一環として実施する個別の評価を繰り返して，

整合性のある結果を得る。

7.4

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

次の事項を，明確で簡明に定義する。

・システム
・要求事項
・環境

127

C 0508-7：2017 (IEC 61508-7：2010)

表F.8−ソフトウェア部分改修

［JIS C 0508-3の7.8（ソフトウェア部分改修）及び

表C.8（決定論的安全度に関する特性−ソフトウェア部分改修）参照］

番号

特性

定義

8.1

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

部分改修は，機能，安全性，並びに技術上及び運用上の結果を十分理解し

た，正式な権限をもつ人が適切に承認する。

8.2

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

部分改修によって，規定する目的を達成する。

8.3

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

部分改修が，新しい決定論的原因フォールトを引き起こさないように実施

する。

このようなフォールトを引き起こす部分改修には，例えば，ゼロ除算，境

界外のインデックス又はポインタ，初期化していない変数の使用などがある。

8.4

好ましくない挙動の回避

部分改修は，ソフトウェア安全要求仕様に規定する制約条件に従って，回

避する必要がある挙動を導かないように実施する。

8.5

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

ソフトウェア設計は，部分改修の影響を徹底的に調査できるようなものと

する。

8.6

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

ソフトウェア設計は，部分改修後のソフトウェアが，引き続きソフトウェ

ア安全要求仕様を満たすことを実証するための，効果的かつ綿密なリグレッ
ションテストが可能なようなものとする。

表F.9−ソフトウェア適合確認

［JIS C 0508-3の7.9（ソフトウェア適合確認）及び表C.9参照］

番号

特性

定義

9.1

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

適合確認は，ソフトウェアが，ソフトウェア安全要求仕様の全ての関連要

求事項を満たすことが確実になるように実施する。

9.2

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

適合確認タスクを完了することによって，安全要求事項を満たしていると

いう具体的証拠をもつ。

9.3

再現性

適合確認の一環として実施する個別評価を繰り返して，整合性のある結果

を得る。

9.4

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

適合確認は，正しいバージョンの要素及びソフトウェアを適用することで，

主張できる結果を得る。この結果を“出来上がった”ソフトウェアの特定コ
ンフィグレーションにリンクさせることができる。

128

C 0508-7：2017 (IEC 61508-7：2010)

表F.10−機能安全評価

（JIS C 0508-3の箇条8及び表C.10参照）

番号

特性

定義

10.1

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

ソフトウェア機能安全評価に当たっては，明らかになった適合性の範囲，

行った判断，推奨する救済手法及びタイムスケール，到達した結論，検収，
条件付き検収又は拒否に対する推奨事項並びにこれらの推奨事項に対する時
間制約条件に関する明確なステートメントを作成する。

10.2

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

ソフトウェア機能安全評価タスクを完了することによって，安全要求事項

を満たしているという主張するための具体的証拠をもつ。

10.3

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

ソフトウェア機能安全評価の間に発生した問題点を取り上げた程度につい

て，明確なステートメントをもつ。

10.4

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

ソフトウェアの変更後にソフトウェア機能安全評価の一部が再評価でき，

改定した結論に到達できるように，ソフトウェア機能安全評価全体について
広範囲な改定をしなくとも，ソフトウェア機能安全評価の改定ができるよう
にする。

10.5

再現性

機能安全評価を，整合性があり，計画的で開かれたプロセスに基づき，特

定した個人及び文書で実施し，システムの提供者，使用者，保守者及び規制
者を含め，評価の判断の影響を受ける全ての人々が評価及び判断の基礎を調
査できるようにする。

機能安全評価は，独立した有能な人が評価の一部として実施した個別の評

価を反復してできるようにする。

10.6

適時性

機能安全評価は，ソフトウェア安全ライフサイクルフェーズとリンクした

適切な頻度で，少なくとも，特定した潜在危険の発生前に実施し，欠陥を適
時に報告する。

テスト，検査，解析などの結果は，評価決定への入力として必要になる場

合，実際に利用できるようにする。

10.7

正確に定義した構成

ソフトウェア機能安全評価は，その結果を，機能安全評価結果で実施する

特定のシステムコンフィグレーションにリンクできるようにする。

129

C 0508-7：2017 (IEC 61508-7：2010)

附属書G
（参考）

安全関連オブジェクト指向ソフトウェアの開発に関する指針

ソフトウェアの設計に対する，この規格の全ての推奨事項は，オブジェクト指向ソフトウェアにも適用

する。オブジェクト指向アプローチは，手続き型又は関数型アプローチとは異なる情報を提供するため，

特に配慮を必要とする推奨事項を，次に示す。

− クラス階層の理解，及び所定のメソッドを呼び出して実行するソフトウェア機能の特定（既存のクラ

スライブラリを用いる場合を含む。）

− 構造テスト（C.5.8及びJIS C 0508-3の表B.2参照）

オブジェクト指向ソフトウェア採用に関する情報手引を，表G.1及び表G.2に示す。これらの表は，JIS

C 0508-3の表A.2及び表A.4に規定する，より一般的な規範手引を補足している。

表G.1−オブジェクト指向ソフトウェアアーキテクチャ

番号

推奨事項

詳細

SIL1

SIL2

SIL3

SIL4

G1.1

アプリケーション領域の概念からアーキテクチャの各ク
ラスまでのトレーサビリティ

注記1

を参照

G1.2

適切なフレームの使用。一般に用いられるクラスと設計パ
ターンとの組合せ。
注記既存のフレーム及び設計パターンを用いる場合，事

前に開発されたソフトウェアの要求事項をこれら
のフレーム及びパターンに適用する。

注記2

を参照

注記1 アプリケーション領域からクラスアーキテクチャまでのトレーサビリティの重要性は低い。
注記2 次の例を参照する。

例1 意図する安全関連プロジェクトの一部として，同様のタスクを成功裏に解決し，プロジェクト参加者に

よく知られている，非安全関連プロジェクトのときから一つのフレームが存在する場合がある。このよ
うな場合，このフレームの使用が推奨される。

例2 安全関連プロジェクトの緊密に関連しているサブタスクを解決するために，異なるアルゴリズムが必要

になる場合がある。このような場合，アルゴリズム評価のために，戦略パターン（strategy pattern）を
選択してもよい。

例3 安全関連プロジェクトの一部が，内外のステークホルダに適切な警告を発する場合がある。このような

場合，これらの警告を体系付けるために，オブザーバパターン（observer pattern）を選択してもよい。
要求事項は，ライブラリには適用しない。

注記3 通常，派生した具体的クラスへのアクセスを提供するのは，抽象基本クラスである。

130

C 0508-7：2017 (IEC 61508-7：2010)

表G.2−オブジェクト指向詳細設計

番号

推奨事項

SIL1

SIL2

SIL3

SIL4

G2.1

各クラスは，目的を一つだけもつ。

G2.2

派生クラスが基本クラスの精細である場合に限り，継承（インヘリ
タンス）を用いる。

G2.3

継承の深さは，コーディング基準で制限する。

G2.4

動作（メソッド）のオーバーライドは，厳格な管理下で行う。

G2.5

インタフェースクラスに限り，複数のインヘリタンスを用いる。

G2.6

未知のクラスから継承する。

−

G2.7

再使用オブジェクト指向ライブラリが，この表の推奨事項を満たす
ことを適合確認する。

注記1 換言すれば，一つのクラスは，一つの責任をもつことで特性付けられる。すなわち，これらのデータに対し

て，データと運用とが緊密につながっていることに注意する。

注記2 オブジェクト間の循環的依存を避けるような注意が必要である。

表G.1及び表G.2で用いた用語などを，表G.3で参考として定義する。

表G.3−一部の指向に関する詳細用語

用語

定義（参考）

基本クラス

派生クラスをもつクラス。基本クラスは，上位クラス又は親クラスと呼ばれる場合がある。

派生クラス

別のクラス（基本クラス）から属性及び／又は運用を継承したクラス（属性及び運用のアセ
ンブリ）。派生クラスは，サブクラス又は子クラスと呼ばれる場合がある。

フレーム

プログラムの構造であって，多くの場合，特定のアプリケーションを充足するために事前に
開発されている。

オーバーライド

実行中の動作（メソッド，サブルーチン）を，同じシグネチャ及び継承階層をもつ別の動作
（メソッド，サブルーチン）で置き換えること。オブジェクト指向の言語又はプログラムの
特性であり，つまり実装多型性を意味する。

（動作の）シグネチャ動作（サブルーチン，メソッド）の名称，並びにパラメータ（引数）及びその型を示す。そ

の戻り型を含む場合もある。二つのシグネチャが同一の名称，並びに同一のパラメータの個
数及び型をもつ場合，これらのシグネチャは同等である。言語によっては，戻り型も等しい
必要がある。

131

C 0508-7：2017 (IEC 61508-7：2010)

参考文献

JIS B 9961 機械類の安全性−安全関連の電気・電子・プログラマブル電子制御システムの機能安全

注記対応国際規格：IEC 62061:2005，Safety of machinery−Functional safety of safety-related electrical,

electronic and programmable electronic control systems

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

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

safety-related systems−Part 1: General requirements

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

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

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

JIS C 0508-3 電気・電子・プログラマブル電子安全関連系の機能安全−第3部：ソフトウェア要求事項

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

safety-related systems−Part 3: Software requirements

JIS C 0511（規格群）機能安全−プロセス産業分野の安全計装システム

注記対応国際規格：IEC 61511 (all parts)，Functional safety−Safety instrumented systems for the process

industry sector

JIS C 60068-2-1 環境試験方法−電気・電子−第2-1部：低温（耐寒性）試験方法（試験記号：A）

注記対応国際規格：IEC 60068-2-1，Environmental testing−Part 2-1: Tests−Test A: Cold

JIS C 60068-2-2 環境試験方法−電気・電子−第2-2部：高温（耐熱性）試験方法（試験記号：B）

注記対応国際規格：IEC 60068-2-2，Environmental testing−Part 2-2: Tests−Test B: Dry heat

ISO 9000，Quality management systems−Fundamentals and vocabulary

IEC 60601 (all parts)，Medical electrical equipment

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

IEC 61326-3-1:2008，Electrical equipment for measurement, control and laboratory use−EMC requirements−

Part 3-1: Immunity requirements for safety-related systems and for equipment intended to perform

safety-related functions (functional safety)−General industrial applications

IEC 61326-3-2:2008，Electrical equipment for measurement, control and laboratory use−EMC requirements−

Part 3-2: Immunity requirements for safety-related systems and for equipment intended to perform

safety-related functions (functional safety)−Industrial applications with specified electromagnetic

environment

IEC 61800-5-2，Adjustable speed electrical power drive systems−Part 5-2: Safety requirements−Functional

IEC 62308:2006，Equipment reliability−Reliability assessment methods

IEC 81346-1:2009，Industrial systems, installations and equipment and industrial products−Structuring principles

and reference designations−Part 1: Basic rules

IEC/TR 61508-0:2005，Functional safety of electrical/electronic/programmable electronic safety-related systems

−Part 0: Functional safety and IEC 61508