B 9961：2008 (IEC 62061：2005)
（1）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
目 次
ページ
序文 ··································································································································· 1
1 適用範囲 ························································································································· 4
2 引用規格 ························································································································· 5
3 用語及び定義，略語 ·········································································································· 6
3.1 定義した用語（英語）のアルファベット順リスト ································································· 6
3.2 用語及び定義 ················································································································ 6
3.3 略語 ··························································································································· 14
4 機能安全の管理 ··············································································································· 15
4.1 目的 ··························································································································· 15
4.2 要求事項 ····················································································································· 15
5 安全関連制御機能（SRCF）の仕様作成に対する要求事項 ······················································· 16
5.1 目的 ··························································································································· 16
5.2 SRCFの仕様作成 ·········································································································· 16
6 安全関連電気制御システム（SRECS）の設計及び統合 ··························································· 19
6.1 目的 ··························································································································· 19
6.2 一般要求事項 ··············································································································· 19
6.3 内部フォールト検出時のSRECSの動きに対する要求事項 ····················································· 20
6.4 SRECSの系統的安全インテグリティに対する要求事項 ························································ 20
6.5 SRECSの選定 ·············································································································· 22
6.6 SRECSの設計及び開発 ·································································································· 23
6.7 サブシステムの実現 ······································································································ 27
6.8 診断機能の実現 ············································································································ 41
6.9 SRECSハードウェアの実現 ···························································································· 42
6.10 ソフトウェア安全要求仕様（SRS）の作成 ········································································ 42
6.11 ソフトウェアの設計及び開発 ························································································· 43
6.12 SRECSの統合及び試験································································································· 50
6.13 SRECSの据付け·········································································································· 51
7 SRECSの使用のための情報 ······························································································ 51
7.1 目的 ··························································································································· 51
7.2 据付け，使用及び保全のための文書化 ··············································································· 52
8 SRECSの妥当性確認 ······································································································· 52
8.1 目的 ··························································································································· 52
8.2 一般要求事項 ··············································································································· 53
8.3 SRECSの系統的安全インテグリティの妥当性確認 ······························································ 53
9 SRECSの変更 ················································································································ 54
B 9961：2008 (IEC 62061：2005) 目次
（2）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ページ
9.1 目的 ··························································································································· 54
9.2 変更の手順 ·················································································································· 54
9.3 構成管理手順 ··············································································································· 55
10 文書化 ························································································································· 56
附属書A（参考）SILの割付け ······························································································· 58
附属書B（参考）SRECS設計の例 ·························································································· 65
附属書C（参考）組込みソフトウェアの設計及び開発指針 ··························································· 72
附属書D（参考）電気･電子部品の故障モード ··········································································· 80
附属書E（参考）工業環境のSRECSに対して強化するJIS C 61000-6-2の電磁イミュニティレベル ····· 84
附属書F（参考）共通原因故障係数（β）の推定法 ···································································· 86
附属書JA（参考）この規格を理解するための基礎情報 ······························································· 88
附属書JB（参考）PFHDの計算式の考察など ············································································ 92
参考文献 ··························································································································· 107
B 9961：2008 (IEC 62061：2005)
（3）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
まえがき
この規格は，工業標準化法第12条第1項の規定に基づき，社団法人日本機械工業連合会(JMF)から，工
業標準原案を具して日本工業規格を制定すべきとの申出があり，日本工業標準調査会の審議を経て，厚生
労働大臣及び経済産業大臣が制定した日本工業規格である。
この規格は，著作権法で保護対象となっている著作物である。
この規格の一部が，特許権，出願公開後の特許出願，実用新案権又は出願公開後の実用新案登録出願に
抵触する可能性があることに注意を喚起する。厚生労働大臣，経済産業大臣及び日本工業標準調査会は，
このような特許権，出願公開後の特許出願，実用新案権又は出願公開後の実用新案登録出願に係る確認に
ついて，責任はもたない。
B 9961：2008 (IEC 62061：2005) 目次
（4）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
白 紙
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
日本工業規格 JIS
B 9961：2008
(IEC 62061：2005)
機械類の安全性−安全関連の電気・電子・
プログラマブル電子制御システムの機能安全
Safety of machinery−Functional safety of safety-related electrical, electronic
and programmable electronic control systems
序文
この規格は，2005年に第1版として発行されたIEC 62061を基に，技術的内容及び対応国際規格の構成
を変更することなく作成した日本工業規格である。
なお，この規格で側線又は点線の下線を施してある参考事項，並びに附属書JA及び附属書JBは，対応
国際規格にはない事項である。
自動化が進んだ結果として，機械の生産力増加及びオペレータの肉体的負荷の軽減が求められるように
なり，機械の安全関連電気制御システムSRECS（Safety-related electrical control systems）が機械の総合的安
全の達成に果たす役割が増加している。一方で，SRECS自体は，ますます複雑な電子技術を用いるように
なってきた。
最近までは，SRECSの関連規格もなく，電子制御技術の信頼性が低かったために，SRECSは，機械の
顕著な危険源に対する安全関連制御機能を果たす用途には積極的に用いられなかった。
この規格は，機械設計者，制御システムの製造業者及びインテグレータ，並びにSRECSの仕様作成，
設計及び妥当性確認に当たる人が利用することを想定している。この規格は，SRECSが，必要な性能を達
成するための要求事項及び実現手法を示す。
この規格は，IEC 61508規格群の枠組の中で，特に機械産業部門で適用する事項を規定する。この規格
は，機械の顕著な危険源（JIS B 9700-1の3.8参照）がもたらすリスクを低減するために用いる電気制御シ
ステムの仕様決定のために利用されることを意図している。
この規格は，機械産業部門において，機械のSRECSの機能安全を規定するために，機械産業部門特有
の枠組を示す。SRECSのライフサイクルの，安全要求事項割付段階から総合的安全妥当性確認段階を規定
している。さらに，SRECSライフサイクルの後半における，SRECSの安全な使用のための情報に対する
要求事項も規定している。
機械において，リスク低減方策の一部としてSRECSを用いる状況は多岐にわたる。危険区域へ人が接
近するときの安全のために，ガードが開かれるとすぐに機械の危険な運動を止めるように，電気制御シス
テムに信号を送るインタロック付きガードのシステムは，SRECS使用の典型例である。また，オートメー
ションシステムにおいて，電気制御システムは，機械の工程を正しく制御して制御システムの故障から直
接生じるリスクを緩和することによって安全に寄与している。
この規格は，次の事項に関する方法及び要求事項を規定する。
− SRECSが実行する各安全機能に，必要な安全インテグリティレベル（SIL）を割り付ける。
2
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 割り付けた安全機能及び安全インテグリティレベル（SIL）を満たすSRECSの設計を可能にする。
− ISO 13849-1:2006に従って設計された安全関連サブシステムをSRECSに統合する。
− SRECSの妥当性確認を行う。
この規格は，JIS B 9700-1に規定するリスク低減法，及びJIS B 9702に規定するリスクアセスメントの
原則に関連して用いることを意図している。SILを割り付ける方法の例を，附属書Aに示す。
この規格は，SRECSの偶発故障及び系統的故障の確率，並びに危害のひどさを考慮に入れて，SRECS
の性能を，意図するリスク低減に調和させる方策を示している。
図1に，この規格と他の関連規格との関係を示す。
この規格のほかに，ISO 13849-1:2006も，機械の安全関連制御システムの設計及び実現のための要求事
項を規定する機能安全規格である。いずれの規格も，その規格の適用範囲に従って関連する安全要求を満
たすために用いることができる。表1に，この規格及びISO 13849-1:2006の適用の推奨案を示す。
表1−この規格及びISO 13849-1:2006の適用の推奨案
安全関連性能を実現する技術方式
ISO 13849-1:2006
この規格
A
非電気的，例えば，液圧式
適用できる。
適用できない。
B
電気･機械的（electromechanical）部
品（例えば，リレー），又は非複雑
電子部品
PL e までの指定のアーキテクチャに
適用（注記1参照）。
SIL 3までのすべてのアーキ
テクチャに適用。
C
高複雑度電子システム，例えば，プ
ログラム式
PL d までの指定のアーキテクチャに
適用（注記1参照）。
同上
D
AとBとの複合
PL e までの指定のアーキテクチャに
適用（注記1参照）。
注記3参照
E
CとBとの複合
PL d までの指定のアーキテクチャに
適用（注記1参照）。
SIL 3までのすべてのアーキ
テクチャに適用。
F
CとA，又はCとA及びBとの複
合
注記2参照
注記3参照
注記1 指定のアーキテクチャは，ISO 13849-1:2006の附属書Bに示され，PLの定量化に関する簡単化した手法
が与えられている。
注記2 高複雑度電子システムには，ISO 13849-1:2006 に指定されるPL d までのアーキテクチャ又はこの規格に
よるすべてのアーキテクチャを用いることができる。
注記3 非電気的な制御システムには，サブシステムとしてISO 13849-1:2006に適合する部品を用いる。
注記 表1は，機械の安全関連システムに，この規格又はISO 13849-1:2006のいずれを適用するべき
かを規定している訳ではない。表1は，制御システムの技術方式と複雑性とに対応させて，こ
の規格及びISO 13849-1:2006の適用可能範囲を要約している。
3
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注a) PL： Performance Level（パフォーマンスレベル）の略称。
b) SRPCS： Safety-Related Parts of Control System（制御システムの安全関連部）の略称。
図1−この規格と他の関連規格との関係
機械の設計及びリスクアセスメント
JIS B 9700-1，機械類の安全性−設計のための基本概念，
一般原則−第1部：基本用語，方法論
JIS B 9702，機械類の安全性−リスクアセスメントの原則
機械に用いる電気･電子･プログラマブル電子制御システム（SRECS）設計のための方法論
安全関連制御機能及びシステム的手法に立脚
カテゴリに対応する
サブシステムの設計
JIS B 9705-1 (ISO 13849-1), 機械
類の安全性−制御システムの安
全関連部−第1部：設計のための
一般原則
ISO 13849-2, 機械類の安全性−
制御システムの安全関連部分−
第2部：妥当性確認
機械の電気的安全の側面
JIS B 9960-1, 機械類の安全性−機械
の電気装置−第1部：一般要求事項
SILに対応する
サブシステムの設計
IEC 61508（-1〜-7）, 電気･
電子･プログラマブル電子制
御システムの機能安全
JIS B 9961,
機械類の安全性−安全関連の電気･電子･プログラマ
ブル電子制御システムの機能安全
・定量的な安全性指標をSILで表現
・機械のSRECSのSIL割付け法
・アーキテクチャ志向
・系統的故障の回避･抑制の要求
・安全性指標をカテゴリ及びPLa)で表現
・定性的リスクグラフによるカテゴリ割付け
・アーキテクチャ志向
非電気的SRPCS b)
（機械式，液圧式など）
SRECSの設計目標
関連規格
：電気的安全の側面
：機能安全の側面
電気的SRPCS b)
4
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
1
適用範囲
この規格は，機械の安全関連電気制御システム（以下，SRECSという。）の設計，統合及び妥当性確認
のための要求事項及び推奨事項を規定する。この規格は，作動中には手で持ち運べない機械（協調して稼
動する機械群を含む。）に，安全機能を単独又は組み合わせて実行する制御システムに適用する。
注記1 この規格で用いる“電気制御システム”は，“電気･電子･プログラマブル電子（E/E/PE）制
御システム”を意味する。“SRECS”は，“安全関連の電気･電子･プログラマブル電子制御
システム”を意味する。
注記2 この規格では，高複雑度のプログラマブル電子式のサブシステム及びサブシステム要素の設
計は，IEC 61508-2及びIEC 61508-3の関連要求事項に従うことを想定している。この規格は，
このような高複雑サブシステム又はサブシステム要素に対しては，開発するより，むしろ使
用するための方法を提供する。
この規格はアプリケーション規格であって，技術的な進歩を制限又は阻止することは意図していない。
この規格は，人を危険源から保護するために他の規格又は規則が要求する事項（例えば，ガード，非電気
式インタロック，非電気式制御など）は含まない。機械には，その種類に応じて適切な安全を確保するた
めに特有の要求事項がある。
この規格は，
− 機械のすぐそばにいる人及び機械の使用に直接関係する人たちの傷害又は健康阻害のリスクを低減す
るための機能安全要求事項だけを扱う。
− 機械又は協調して稼動する機械群自体の危険源から生じるリスクだけを扱う。
注記3 他の危険源から生じるリスクを低減するための要求事項は，関連する規格で規定する。例え
ば，機械がプラントのプロセス工程の一部を担う場合，機械の機能安全要求事項は，プロセ
スの安全に関する限り，この規格以外の要求事項（例えば，IEC 61511）も満足することが望
ましい。
− 機械のための非電気式制御要素の性能要求事項は規定しない。
注記4 この規格の要求事項は，電気制御システムを対象とするが，枠組及び方法論は，非電気式制
御システムの安全関連部分にも適用できる。
− 電気制御装置自体から生じる電気の危険源は扱わない（例えば，感電については，JIS B 9960-1を参
照。）。
この規格の主な箇条の目的を，表2に示す。
表2−各箇条の概要及び目的
箇条番号及び項目
箇条の目的
4 機能安全の管理
SRECSが必要とする機能安全を達成するために必要な管理及び技術活動を規定する。
5 安全関連制御機能
（SRCF）の仕様作成に
対する要求事項
SRCFに対して次の要求仕様を決定する手順を規定する。
・ 機能要求仕様。
・ 安全インテグリティ要求仕様。
6 安全関連電気制御シ
ステム（SRECS）の設計
及び統合
安全要求仕様（SRS）に適合するSRECSを選定する基準，並びに，設計及び実現する方
法を規定する。
次の事項を含む。
・ システムアーキテクチャの選定。
・ 安全関連ハードウェア及びソフトウェアの選定。
・ ハードウェア及びソフトウェアの設計。
・ 設計したハードウェア及びソフトウェアがSRSを満たすことの検証。
5
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表2−各箇条の概要及び目的（続き）
箇条番号及び項目
箇条の目的
7 SRECSの使用のため
の情報
SRECSの使用のための情報に対する要求事項を規定する。
次の事項を含む。
・ 使用者マニュアル及び手順書の準備。
・ 保全マニュアル及び手順書の準備。
8 SRECSの妥当性確認 SRECSに適用する妥当性確認過程の要求事項を規定する。
次の事項を含む。
・ SRECSがSRSの要求事項を満たすことを確認するための検査及び試験。
9 SRECSの変更
SRECSの変更手順に関する要求事項を規定する。
次の事項を含む。
・ すべてのSRECSに対する変更は，変更前に適切にレビュー，検証する。
・ どのような変更であっても，変更後のSRECSのSRSは満たされる。
注記5 この規格の対応国際規格及びその対応の程度を表す記号を，次に示す。
IEC 62061:2005，Safety of machinery−Functional safety of safety-related electrical, electronic and
programmable electronic control systems (IDT)
なお，対応の程度を表す記号(IDT)は，ISO/IEC Guide 21に基づき，一致していることを示
す。
2
引用規格
次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部を構成する。
これらの引用規格のうちで，西暦年を付記してあるものは，記載の年の版を適用し，その後の改正版（追
補を含む。）には適用しない。西暦年の付記がない引用規格は，その最新版（追補を含む。）を適用する。
JIS B 9700-1:2004 機械類の安全性−設計のための基本概念，一般原則−第1部：基本用語，方法論
注記 対応国際規格：ISO 12100-1:2003, Safety of machinery−Basic concepts, general principles for
design−Part 1: Basic terminology, methodology (IDT)
JIS B 9700-2:2004 機械類の安全性−設計のための基本概念，一般原則−第2部：技術原則
注記 対応国際規格：ISO 12100-2:2003, Safety of machinery−Basic concepts, general principles for
design−Part 2: Technical principles (IDT)
JIS B 9702 機械類の安全性−リスクアセスメントの原則
注記 対応国際規格：ISO 14121, Safety of machinery−Principles of risk assessment (IDT)
JIS B 9705-1: 2000 機械類の安全性−制御システムの安全関連部−第1部：設計のための一般原則
注記 対応国際規格：ISO 13849-1:1999, Safety of machinery−Safety-related parts of control systems−
Part 1: General principles for design (IDT)
JIS B 9960-1 機械類の安全性−機械の電気装置−第1部：一般要求事項
注記 対応国際規格：IEC 60204-1, Safety of machinery−Electrical equipment of machines−Part 1:
General requirements (MOD)
JIS C 61000-6-2 電磁両立性−第6部：共通規格−第2節：工業環境におけるイミュニティ
注記 対応国際規格：IEC 61000-6-2, Electromagnetic compatibility (EMC)−Part 6-2: Generic standards
−Immunity for industrial environments (MOD)
ISO 13849-2:2003, Safety of machinery−Safety-related parts of control systems−Part 2: Validation
6
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
IEC 61508-2, Functional safety of electrical/electronic/programmable electronic safety-related systems−Part
2: Requirements for electrical/electronic/programmable electronic safety-related systems
IEC 61508-3, Functional safety of electrical/electronic/programmable electronic safety-related systems−Part
3: Software requirements
3
用語及び定義，略語
3.1
定義した用語（英語）のアルファベット順リスト
このリストは，日本工業規格として必要でないため削除。
3.2
用語及び定義
この規格で用いる主な用語及び定義は，次による。
3.2.1
機械類 (machinery)
連結された部品又は部分の組合せで，そのうちの少なくとも一つは適切な機械アクチュエータ，制御及
び動力回路を備えて動くものであって，特に材料の加工，処理，移動及びこん（梱）包といった特定の用
途に合うように結合されたもの。
また，“機械類”及び“機械”という用語は，全く同一の目的を達成するために完全な統一体として機能
するように配列され，制御される複数の機械の集合体に対しても用いる。
（JIS B 9700-1:2004の3.1による。）
3.2.2
機械制御システム (machine control system)
プロセス設備，他の機械要素，オペレータ，外部の制御設備などからの入力信号に反応して機械を意図
したように動かす出力信号を生成するシステム。
3.2.3
電気制御システム (electrical control system)
機械の運転制御，モニタ，インタロック，通信，防護及び安全関連制御機能［（以下，SRCFという。）
3.2.16参照。］などのために用いる機械制御システムが用いるすべての電気･電子･プログラマブル電子の部
分。
注記 SRCFは，非安全関連機能を実行する機械制御システムと独立して作動する場合と，統合して
作動する場合とがある。
3.2.4
安全関連電気制御システム [SRECS (safety-related electrical control system)]
機械の電気制御システムであって，それが故障するとリスクが直ちに増加することが有り得るもの。
注記 SRECSは，その部分が故障すると安全機能を低下又は喪失するようなすべての部分を含むもの
であり，電源回路と制御回路とで構成することができる。
3.2.5
サブシステム (subsystem)
SRECSアーキテクチャの中で最上位の構成要素であって，いずれのサブシステムが故障してもSRECS
のSRCFの故障をもたらすもの。
注記1 完全なサブシステムは，識別可能な複数のサブシステム要素から構成することができる。そ
れらのサブシステム要素が組み合わされて，サブシステムに割り当てられた機能ブロックを
7
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
実行する。
注記2 この定義は，JIS C 0508-4の，次の一般的な定義を限定したものである。“設計に従って相互
に作用する要素のセット。ここで，システムの要素はサブシステムと呼ぶ別のシステムであ
ってもよい。ハードウェア，ソフトウェア，及び人間の介在を含んでもよい。”。
注記3 この定義は，分解された構成要素のいずれの部分をも意味する一般的サブシステムの定義と
異なる。この規格では，サブシステムという用語は，厳格に定義した階層レベルをもつ。サ
ブシステムは，システムの最上位の区分レベルである。サブシステムをさらに分解した構成
要素は，“サブシステム要素”と呼ぶ。
3.2.6
サブシステム要素 (subsystem element)
サブシステムを構成する部分であって，一つの構成品又は複数の構成品のグループからなるもの。
3.2.7
低複雑度構成品 (low complexity component)
SRECSの構成品であって，
− 構成品の故障モードが明確に定まっており，
− フォールト発生時の構成品の動きが完全に把握されているもの。
（JIS C 0508-4の3.4.4を修正。）
注記1 低複雑度構成品は，フォールト状態の動きを，分析又は試験によって明確にできる。
注記2 電動機へのエネルギーを遮断するために，電磁リレーを介してコンタクタを作動させる1個
又は複数のリミットスイッチからなるサブシステム又はサブシステム要素は，この規格でい
う低複雑度構成品の例である。
3.2.8
高複雑度構成品 (complex component)
次のような構成品。
− 故障モードが明確に定まらない。又は，
− フォールト発生時の構成品の動きを完全に把握できない。
3.2.9
機能安全 (functional safety)
機械及び機械制御システムの安全の一部であって，SRECS，他技術安全関連システム1)及び外部のリス
ク低減設備2)の正しい作動に依存するもの（JIS C 0508-4の3.1.9を修正。）。
注記1 この規格は，SRECS機能の正しい作動に依存する機能安全だけを扱う。
注記2 JIS Z 8051では，安全を“受容できないリスクがないこと”と定義している。
注1) 他技術安全関連システムとは，例えば，油圧制御及び空圧制御の安全関連制御システムをいい，
この規格では，これらのシステムは扱わない。
2) 外部のリスク低減設備とは，例えば，防犯システム，防火システム，避難システムなどを指し，
この規格では扱わない。
3.2.10
（機械類の）危険源 [hazard (from machinery)]
傷害又は健康障害を引き起こす根源（JIS B 9700-1:2004の3.6を修正。）。
注記 危険源という用語は，予期される傷害若しくは健康障害の発生源又は性質を定義するために用
8
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
いる（例えば，感電の危険源，押しつぶしの危険源，切断の危険源，毒性による危険源，火災
の危険源などのように。）。
3.2.11
危険状態 (hazardous situation)
人が，危険源（単数又は複数）に暴露される（さらされる）状況（JIS B 9700-1:2004の3.9を修正。）。
3.2.12
保護方策 (protective measure)
リスクを低減するための方策（JIS B 9700-1:2004の3.18を修正。）。
3.2.13
リスク (risk)
危害の発生確率及びその危害のひどさの組合せ（JIS B 9700-1:2004の3.11による。）。
3.2.14
制御機能 (control function)
入力情報を評価し，出力情報又は出力動作を作り出す機能。
3.2.15
安全機能 (safety function)
故障がリスクの増加に直ちにつながるような機械の機能（JIS B 9700-1:2004の3.28による。）。
注記 この定義は，JIS C 0508-4及びJIS B 9705-1の定義と異なる。SRECSの安全機能は，機能故障
がリスクの増加に直ちにつながるようなSRECSの機能である。
3.2.16
安全関連制御機能（SRCF）[safety-related control function (SRCF)]
機械の安全状態を維持するように，又はリスクが直ちに増加しないように，SRECSが実行する制御機能
であって，指定の安全インテグリティレベルをもつ機能。
3.2.17
SRECS診断機能 (SRECS diagnostic function)
SRECS内のフォールトを検出し，指定の情報を出力する，又は指定の動きを作り出す機能。
注記 この機能はSRCFの危険側故障につながるフォールトを検出して，指定のフォールト反応機能
を始動する。
3.2.18
SRECSフォールト反応機能 (SRECS fault reaction function)
SRECS診断機能によってSRECS内のフォールトが検出されたときに始動される機能。
3.2.19
安全インテグリティ (safety integrity) 3)
SRECS又はそのサブシステムが，すべての規定条件下で，要求される安全機能を満足に実行する確率
（JIS C 0508-4の3.5.2を修正。）。
注記1 アイテムの安全インテグリティレベルが高いほど，アイテムが要求安全機能の実行に失敗す
る確率が低い。
注記2 安全インテグリティは，ハードウェア安全インテグリティ（3.2.20を参照）と系統的安全イ
ンテグリティ（3.2.22を参照）との構成要素に分けられる。
注3) インテグリティ（integrity）とは，必要な要素がすべて完全な状態で統合されている度合をいう。
9
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
integrityは，integral，integrationなどに通じる。integrityを，完全性，健全性などとする日本語
文献もある。
3.2.20
ハードウェア安全インテグリティ (hardware safety integrity)
SRECS又はそのサブシステムの安全インテグリティの一部であって，危険側ランダムハードウェア故障
確率及びアーキテクチャによる制約に依存する部分（JIS C 0508-4の3.5.5を修正。）。
3.2.21
ソフトウェア安全インテグリティ (software safety integrity)
SRECS又はそのサブシステムの系統的安全インテグリティの一部であって，プログラマブル電子システ
ムにおいて，ソフトウェアが，すべての規定条件下で規定の期間，その安全機能を達成する能力に関係す
る部分（JIS C 0508-4の3.5.3を修正。）。
注記 ソフトウェア安全インテグリティは，通常，精密には数量化できない。
3.2.22
系統的安全インテグリティ (systematic safety integrity)
SRECS又はそのサブシステムの安全インテグリティの一部であって，危険なモードにおける系統的故障
（3.2.45を参照）に対する抵抗力に関係する部分（JIS C 0508-4の3.5.4を修正。）。
注記1 系統的安全インテグリティは，通常，精密に数量化することができない。
注記2 系統的安全インテグリティの要求は，SRECS又はそのサブシステムのハードウェア及びソフ
トウェアの両方に適用される。
3.2.23
安全インテグリティレベル（SIL）(safety integrity level)
SRECSに割り当てる安全機能の安全インテグリティを指定するために，数字で表す3段階のレベル。安
全インテグリティレベル3（SIL 3）が最も高い安全インテグリティに対応し，安全インテグリティレベル
1（SIL 1）が最も低い安全インテグリティに対応する（JIS C 0508-4の3.5.6を修正。）。
注記 SIL 4は，通常，機械類のリスク低減要求には必要でないため，この規格では扱わない。SIL 4
に適用する要求事項に関してはIEC 61508-1及びIEC 61508-2を参照。
3.2.24
（サブシステムの）SIL付与限界 [SIL claim limit (for a subsystem)]
アーキテクチャによる制約及び系統的安全インテグリティを考慮して，SRECSサブシステムに与え得る
最高のSIL。
3.2.25
作動要求 (demand)
SRECSにSRCFの作動を要求する事象。
注記 作動要求の例を，次に示す。
− 人がESPE（電気的検知保護設備）の検出区域を越えて機械に接近する。
− 人がインタロック付きガードを開く。
− 機械の速度が規定値を超える。
− 機械可動部の可動範囲が規定値を超える。
3.2.26
低頻度作動要求モード (low demand mode)
10
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
SRECSへの作動要求頻度が，1年に1回以下，又はプルーフテスト頻度の2倍以下となる運転モード。
注記 IEC 61508-1及びIEC 61508-2の低頻度作動要求モードの要求事項だけに従って設計した装置
は，この規格が規定するSRECSの部分としての使用には適さない場合がある。機械類におい
ては，SRECSを低頻度作動要求モードで用いることはないと考えられる。
3.2.27
高頻度作動要求又は連続モード (high demand or continuous mode)
SRECSへの作動要求頻度が，1年に1回を超える，又はプルーフテスト頻度の2倍を超える運転モード
（JIS C 0508-4の3.5.12を修正。）。
注記1 低頻度作動要求モードは，機械類におけるSRECSに用いられるとは考えられない。したが
ってこの規格では，SRECSは高頻度作動要求又は連続モードで稼動するものと考える。
注記2 高頻度作動要求モードでは，作動要求があったときだけ機械を指定の状態に移行させるため
にSRCFが作動する。安全機能の作動要求があるまで，SRECSは機械に影響を与えない。
注記3 連続モードでは，安全機能が連続的に作動する。すなわち，SRECSは絶えず機械を制御して
おり，SRECS機能の危険側故障は直ちに危険源をもたらすことが有り得る。
3.2.28
PFHD (probability of dangerous failure per hour)
SRECS又はそのサブシステムが，1時間の間に危険側故障を起こす平均確率。
注記 PFHD を作動要求ごとの失敗確率PFDと混同してはならない。
3.2.29
目標故障率 (target failure value)
SRECS又はそのサブシステムが，安全インテグリティ要求を満たすために達成するべきPFHDの目標値。
1時間当たりの危険側故障確率で表す（JIS C 0508-4の3.5.13を修正。）。
3.2.30
フォールト (fault)
SRECS，サブシステム，又はサブシステム要素が，要求機能実行能力を低下する，又は喪失するような
異常状態（JIS C 0508-4の3.6.1を修正。）。
注記 faultの訳語として，JIS B 9700-1では“不具合（障害）”を用いている。JIS B 9704規格群では，
“障害（不具合）”を用いている。JIS C 0508規格群では，“フォールト”を用いている。この
規格では“フォールト”を用いる。
3.2.31
フォールトトレランス (fault tolerance)
SRECS，サブシステム，又はサブシステム要素が，フォールト又は故障が存在する状況で要求機能の実
行を継続できる能力（JIS C 0508-4の3.6.3を修正。）。
注記 共通原因故障に対しては，一般にフォールトトレランスを実現できない。
3.2.32
機能ブロック (function block)
SRCFの最小の構成要素。どの機能ブロックが故障してもSRCFの故障をもたらす。
注記1 この規格では，SRCFは機能ブロック（FB）の論理積（AND）である，すなわち，
F ＝ FB1 AND FB2 AND ……… AND FBn
注記2 機能ブロックのこの定義は，JIS B 3503ほかの規格に使われる定義とは異なる。
11
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
3.2.33
機能ブロック要素 (function block element)
機能ブロックの部分。
3.2.34
平均故障時間（MTTF) (mean time to failure)
故障するまでの平均時間の推定値（JIS Z 8115のR15による。）。
注記 MTTFは，通常，故障するまでの推定時間の平均値として表される。
3.2.35
アーキテクチャ (architecture)
SRECSのハードウェア要素及びソフトウェア要素の特定の構成法（JIS C 0508-4の3.3.5を修正。）。
3.2.36
アーキテクチャによる制約 (architectural constraint)
サブシステムに付与できるSILの上限値を制限する，アーキテクチャ関連の要求事項の組合せ。
注記 アーキテクチャによる制約は，6.7.6に規定する。
サブシステムの安全側故障比率（SFF）及びフォールトトレランスは，アーキテクチャによ
る制約の例である（6.7.6の表5及び表6参照）。
3.2.37
プルーフテスト (proof test)
SRECS及びサブシステム内の，フォールト及び劣化を検出し，必要ならば，SRECS及びそのサブシス
テムを新品又は新品同様状態に修復するために実行するテスト（JIS C 0508-4の3.8.5を修正。）。
注記 通常，プルーフテストによってサブシステムの残存寿命を新品同様に戻すことはできない。故
障修復後のハードウェアの偶発故障確率を新品に近くすることは可能と考えられる。
3.2.38
診断率 (diagnostic coverage)
自動的な診断テストによってSRECS又はサブシステムの危険側ハードウェア故障確率が減少する割合
（JIS C 0508-4の3.8.6を修正。）。
注記 診断率DCは，次の式を用いて算出される。
DC ＝ (Σ λDD ) / λDtotal
ここに，
λDD： 診断によって検出できる危険側ハードウェア故障の発生確
率
λDtotal： すべての危険側ハードウェア故障の発生確率
診断テストとは，連続又は一定間隔で自動的に行う故障検出テストをいう。この規格では，
診断によって危険側故障が検出されると，一般に次のフォールト反応が働き，検出された危険
側故障は，サブシステムを直接危険側故障に導くことがないものとする。
− フォールトトレランスをもたないSRECS又はサブシステムの場合
・ 直ちに機械及びSRECSの運転を停止する。
− フォールトトレランスをもつSRECS又はサブシステムの場合
・ 直ちに機械及びSRECSの運転を停止する。又は,
・ 故障の発生を通知する。残存系に依存して運転を続けながら故障系を修復する。
12
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
3.2.39
故障 (failure)
SRECS，サブシステム，又はサブシステム要素に，要求機能を実行する能力がなくなること（JIS C 0508-4
の3.6.4を修正，及びJIS B 9700-1:2004の3.32による。）。
注記1 故障には，偶発故障（ハードウェア）及び系統的故障（ハードウェア又はソフトウェア）が
ある。
注記2 故障には，永久故障及び一時故障がある。絶縁破壊，焼損による故障は永久故障である。電
磁妨害にさらされたときだけ制御機能が正しく作動しない故障は一時故障である。
注記3 failureには，“故障”のほかに“失敗”の意味もある。作動要求があったときに安全機能が正
しく作動しないことを安全機能の作動が失敗するという。
3.2.40
危険側故障 (dangerous failure)
SRECS，サブシステム，又はサブシステム要素を危険状態又は機能不能状態に導く潜在性をもつ故障（JIS
C 0508-4の3.6.7を修正。）。
注記1 故障が現実にサブシステムの危険側故障を招くかどうかは，サブシステムのチャネルアーキ
テクチャに依存することがある。例えば，安全性を改善するために多重チャネルをもつサブ
システムを用いる場合，一つのサブシステム要素の危険側ハードウェア故障がSRECS全体
を危険状態又は機能不能状態に導く可能性は少ない。
注記2 多重チャネルをもつサブシステムのPFHDは，サブシステムを構成するチャネル（サブシス
テム要素）のPFHDより小さくなり得るが，SRECSのPFHDは，SRECSを構成するどのサブ
システムのPFHDよりも小さくはなり得ない（このことは，この規格特有の“サブシステム”
の定義に由来する。3.2.5参照。）。
注記3 通常，危険側故障は，SRCFを実行する機能の現実故障又は潜在故障となる。
ここでいう潜在故障とは，その故障が直接サブシステムの安全制御機能を喪失させること
がないような危険側故障をいう。次の故障は，SRECS又はサブシステムの潜在故障である。
− 診断機能によって検出できる危険側故障。
− フォールトトレランスNをもつSRECS又はサブシステムにおいて，稼動開始後又はプ
ルーフテスト後に起こるN個以内の危険側故障。
3.2.41
安全側故障 (safe failure)
SRECS，サブシステム，又はサブシステム要素を危険状態又は機能不能状態に導く潜在性をもたない故
障（JIS C 0508-4の3.6.8を修正。）。
注記 安全側故障は，SRCFの現実故障を招くことも潜在故障を招くこともない。
3.2.42
安全側故障比率 (safe failure fraction)
サブシステムの全故障のうち，サブシステムが危険側故障にならない故障の割合。
注記 安全側故障比率（SFF）は，次の式を用いて計算される。
SFF =（ Σ λS ＋ Σ λDD ）/（ Σ λS ＋ Σ λD ）
=（ Σ λS ＋DC × Σ λD ）/（ Σ λS ＋ Σ λD ）
ここに，
λS： 安全側故障率
13
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
λDD： 診断機能によって検出できる危険側故障率
λD： 危険側故障率
ΣλS+ΣλD： 合計の故障率
SRECSの各サブシステムのDC（あれば）は，サブシステムのPFHD を計算するとき考慮に
入れる。SFFは，ハードウェア安全インテグリティ（6.7.7参照）をアーキテクチャによる制約
によって決定するとき考慮に入れる。
3.2.43
共通原因故障 (common cause failure)
一つ又は複数の事象に基因する故障であって，多重チャネルサブシステム（冗長系）の二つ以上のチャ
ネルに同時故障をもたらし，SRCFを故障に導くもの（JIS C 0508-4の3.6.10を修正。）。
注記 この定義は，JIS B 9700-1及びJIS Z 8115のF32の定義と異なる。
3.2.44
ランダムハードウェア故障 (random hardware failure)
時間に関して無秩序に発生し，ハードウェアの多様な劣化メカニズムから生じる故障（JIS C 0508-4の
3.6.5による。）。
3.2.45
系統的故障 (systematic failure)
何らかの原因に確定的（決定論的）に関係する故障であって，設計，製造プロセス，運転手順，文書又
は他の関連要因を変更しなければ除去できない故障（IEC 61508-4の3.6.6による。）。
注記1 変更を伴わない修理では，通常，系統的故障の原因を除去できない。
注記2 故障原因をシミュレートすることによって，系統的故障を誘発することができる。
注記3 系統的故障の原因の事例には，次の段階で起こす人間の過誤がある。
− 安全要求仕様［以下，SRS (Safety Requirements Specification)という。］の作成。
− ハードウェアの設計，製造，据付け及び／又は運転。
− ソフトウェアの設計及び／又は製造。
注記4 JIS C 0508-4の3.6.6及びJIS Z 8115のF29では，systematic failureの訳語に“決定論的原因
故障”を当てている。また，JIS Z 8115のF29では“決定論的原因故障（systematic failure）”
及び“再現可能故障（reproducible failure）”に同じ定義を与えている。
この規格では，系統的（systematic）という語を，しばしば，偶発的（random）の反意語と
して，系統的故障，系統的フォールト，系統的安全インテグリティなどのように用いる。系
統的とは，偶発的でなく，秩序，因果関係に従うという意味である。系統的故障は，非偶発
故障である。
3.2.46
アプリケーションソフトウェア (application software)
SRECS設計者が作成する，SRECS固有の用途に用いるソフトウェア。一般にSRECSの機能要求を満た
すための，論理シーケンス，入力･出力を適正に制御する限界値及び命令，計算，決定論理などを含む。
3.2.47
組込みソフトウェア (embedded software)
SRECS製造業者が製品に組み込むソフトウェアであって，SRECSの部分であり，通常，変更のために
アクセスできないソフトウェア。
14
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注記 ファームウェア又はシステムソフトウェアは，組込みソフトウェアの例である。
3.2.48
無制約可変言語（FVL）(full variability language)
多様な機能及びアプリケーションを実行する能力をもつ言語（IEC 61511-1の3.2.81.1.3を修正。）。
注記1 FVLを用いるシステムの典型的な例は，はん（汎）用コンピュータである。
注記2 FVLは，通常，組込みソフトウェアで使われ，アプリケーションソフトウェアに使われるこ
とはまれである。
注記3 FVLの例には，Ada，C，Pascal，指示リスト，アセンブラ言語，C++，Java，SQLなどがあ
る。
3.2.49
制約可変言語（LVL）(limited variability language)
SRSを実行するための，定義済みの，アプリケーション固有の，ライブラリ機能を結合する能力をもつ
言語（IEC 61511-1の3.2.81.1.2を修正。）。
注記1 LVLは，アプリケーションを実行する機能と，機能的に密接に対応している。
注記2 LVLの典型的な例を，JIS B 3503に示す。LVLには，ラダー図，機能ブロック図，シーケン
シャル ファンクション チャート（SFC）などがある。
注記3 LVLを用いるシステムの典型例には，機械制御用に構成したPLCがある。
3.2.50
安全関連ソフトウェア (safety-related software)
安全関連システムにおいて，安全機能を実行するために使われるソフトウェア。
3.2.51
検証 (verification)
SRECS，サブシステム，又はサブシステム要素が，関連仕様書の要求事項に適合することを検査（例え
ば，試験及び分析）によって確認すること（JIS C 0508-4の3.8.1及びIEC 61511-1の3.2.92を修正。）。
注記1 客観的証拠を提供するために，検証結果は文書化することが望ましい。
注記2 検証活動の例には，次のものがある。
− 検証対象が，各段階の目的及び要求事項に適合することを保証するために，各段階に固
有の入力を考慮に入れて，出力（すべての段階からの文書）をレビューする。
− 設計レビュー。
− 設計された製品が仕様に従って作動することを確かめるための試験。
− 統合試験。すべての部品が指定されたように協調して働くことを確認するために，異な
る部品を一つ一つ統合する試験及び環境試験を含む。
3.2.52
妥当性確認 (validation)
SRECSが特定アプリケーションの機能安全要求事項を満たすことを検査（例えば，試験，分析）によっ
て確認すること（JIS C 0508-4の3.8.2を修正。）。
3.3
略語
この規格では，次の略語を用いる。
15
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
CCF
Common Cause Failure(s)
共通原因故障
DC
Diagnostic Coverage
診断率
EMC
Electromagnetic Compatibility
電磁両立性
FB
Function Block
機能ブロック
FVL
Full Variability Language
無制約可変言語
I/O
Input/Output
入力／出力
LVL
Limited Variability Language
制約可変言語
PFHD
Probability of dangerous Failure per Hour
1時間当たりの危険側故障確率
MTTF
Mean Time To Failure
平均故障時間
MTTR
Mean Time To Restoration
平均修復時間
PTE
Probability of dangerous Transmission Error
伝送誤りの確率
SFF
Safe Failure Fraction
安全側故障比率
SIL
Safety Integrity Level
安全インテグリティレベル
SILCL
Safety Integrity Level (SIL) Claim Limit (for subsystems)
（サブシステムの）SIL付与限界
S-R
Safety Related
安全関連
SRECS
Safety-Related Electrical Control System
安全関連電気制御システム
SRCF
Safety-Related Control Function
安全関連制御機能
SRS
Safety Requirements Specification
安全要求仕様
SYS
System
システム
PLC
Programmable Logic Controller
プログラマブルコントローラ
4
機能安全の管理
4.1
目的
箇条4は，SRECSに要求される機能安全を達成するために必要な管理及び技術活動について規定する。
4.2
要求事項
4.2.1 すべてのSRECS開発プロジェクトにおいて，機能安全計画を作成し，文書化し，必要なとき更新
しなければならない。機能安全計画は，箇条5〜箇条9に規定する活動を管理する手順を含まなければな
らない。
注記1 機能安全計画の内容は，プロジェクトの特徴に応じた内容にすることが望ましい。
プロジェクトの特徴には，次のものがある。
− プロジェクトの大きさ。
− SRECSの複雑度。
− 設計及び技術の新規性。
− 設計の標準化の度合。
− SRECSの故障によって発生し得る被害の大きさ。
機能安全計画は，特に次のことを満たすものでなければならない。
a) 箇条5〜箇条9に規定する関連活動を明確にする。
b) 規定された機能安全要求事項を達成する方針及び方策を明確にする。
c) アプリケーションソフトウェア，開発，統合，検証及び妥当性確認において，機能安全を達成する方
策を明確にする。
d) 箇条5〜箇条9に規定する関連活動を実行又はレビューをする人，部門又は他の組織，及びリソース
を明確にする。
e) SRECSの機能安全に関係する情報を記録し，保存する手順及びリソースを明確化又は確立する。
16
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注記2 次のことを考慮することが望ましい。
− 危険源の識別（同定）結果及びリスクアセスメントの結果。
− SRCFを実行するために用いる装置及びその安全要求事項。
− 機能安全の維持に責任をもつ組織。
− 機能安全を達成し，維持するために必要な手順（SRECSを変更する場合も含む。）。
f)
構成管理の方針を記述する（9.3を参照）。これには組織関連事項，例えば，担当者及び組織構成を考
慮に入れる。
g) 検証計画を確立する。計画には，次の事項を含める。
− 検証を実施するタイミングの詳細。
− 検証を実行する人，部門又は団体の詳細。
− 検証方針及び検証技術の選定。
− 試験装置の選定及び使用。
− 検証活動の選定。
− 合格基準。
− 検証結果の評価に用いる手段。
h) 妥当性確認計画を確立する。計画には，次の事項を含める。
− 妥当性確認を実施するタイミングの詳細。
− 妥当性確認に供する機械の運転モード（例えば，正規運転モード及び設定モード）の詳細。
− SRECS妥当性確認で確認対象となる要求事項。
− 妥当性確認の技術方針（例えば，分析手法又は統計的試験）。
− 合格基準。
− 合格基準に達しなかった場合にとるべき措置。
注記3 妥当性確認計画には，SRECS及びそのサブシステムを全数試験，形式試験及び／又は抜取り
試験に供するかどうかを示すことが望ましい。
4.2.2 機能安全計画は，次の活動で生じるSRECS関連の問題点を迅速に追跡処理して，満足する解決を
得るように履行しなければならない。
− 箇条5〜箇条9で規定する活動。
− 検証活動。
− 妥当性確認活動。
5
安全関連制御機能（SRCF）の仕様作成に対する要求事項
5.1
目的
箇条5は，SRECSが実行するべきSRCFの要求仕様を作成するための手順について規定する。
5.2
SRCFの仕様作成
5.2.1
概要
5.2.1.1 JIS B 9700-1，JIS B 9700-2，及びJIS B 9702に規定するリスク低減手法を用いて，必要な安全機
能を決定する。
5.2.1.2 安全機能の全部又は一部をSRECSによって達成する場合は，SRECSのSRCF（3.2.16を参照）の
仕様を作成しなければならない。
5.2.1.3 SRCFの仕様は，次によって構成しなければならない。
17
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 機能要求仕様（5.2.3を参照）。
− 安全インテグリティ要求仕様（5.2.4を参照）。
これらの仕様は，SRS（安全要求仕様）として文書化しなければならない。
注記1 非電気的装置を電気的手段と組み合わせて安全機能を遂行する場合は，非電気的装置の目標
故障率はこの規格では考慮しない。電気的手段には，電気で作動するすべての装置又はシス
テムを含む。次のものは，電気的手段の範ちゅうに含まれる。
− 電気・機械複合部品（例えば，リレー，モータ）。
− プログラマブルでない電子装置。
− プログラマブル電子装置。
注記2 SRSは，構成管理手順の一部として，そのバージョンを管理しなければならない（9.3を参照）。
5.2.1.4 SRSは，意図する使用に対し，不足，矛盾がないことを検証しなければならない。
注記 このことは，例えば，点検，分析及びチェックリストによって検証できる。IEC 61508-7のB.2.6
を参照。
5.2.2
入手情報
各SRCFの機能要求仕様及び安全インテグリティ要求仕様を作成するために，次の情報を用いなければ
ならない。
− 機械のリスクアセスメントの結果。各危険源のリスクを低減するために必要であると結論されたすべ
ての安全機能を含む。
− 機械の運転特性。これには次のものがある。
・ 運転モード。
・ サイクルタイム。
・ 応答時間性能。
・ 環境条件。
・ 機械への人の介入（例えば，修理，設定及び清掃）。
− SRECSの設計に影響するすべてのSRCF関連情報。例えば，
・ SRCFで達成又は防止しようとする機械の動き。
・ 複数のSRCF間，及びSRCFと他の機能との間のすべてのインタフェース（機械の内外）。
・ SRCFに必要なフォールト反応機能。
注記 反復的なSRECS設計過程を始める前に入手できない情報，又は十分明確にできない情報も有
り得る。したがって，SRECSのSRSは設計過程中に更新が必要となることもある。
5.2.3
SRCFの機能要求仕様
5.2.3.1 SRCFの機能要求仕様には，実行する各SRCFの詳細を記述しなければならない。次のうちの該当
する項目を含める。
− SRCFを作動又は不作動にして運転する機械の条件（例えば，運転モード）。
− 相入れない動きを起こす機能が同時に作動したときの優先順位。
− 各SRCFの作動頻度。
− 各SRCFの要求応答時間。
− 他の機械機能とSRCFとのインタフェース。
− （例えば，入出力機器の）要求応答時間。
− 各SRCFの説明。
18
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− フォールト反応機能の説明，及び最初のフォールト反応が機械を止めることである場合は，再起動又
は運転継続に対する制約などの説明。
− 運転環境の説明（例えば，温度，湿度，ちり，化学物質及び機械的振動衝撃）。
− 試験及びその関連装置（例えば，試験装置及び試験アクセスポート）。
− SRCFの目的に用いる電気・機械複合部品の作動頻度及び／又は使用カテゴリ。
5.2.3.2 SRECSを工業地環境で用いることを意図する場合，電磁イミュニティレベルは，JIS C 61000-6-2
によるほか，附属書Eに示す強化イミュニティレベルをもつことが望ましい。他の電磁環境（例えば，住
宅地環境）で用いることを意図するSRECSは，他のEMC規格に基づくイミュニティレベル（例えば，JIS
C 61000-6-1による住宅地環境レベル）をもつことが望ましい。
注記1 他のEMC規格を用いてSRECSの電磁イミュニティレベルの仕様を決めるときは，そのEMC
規格に規定するレベルが，SRECS使用中に起こり得る電磁妨害に対して適切であるかどうか
を，起こる確率が低い妨害に対しても，検討する必要がある。
注記2 SRECSの機能安全のための電磁イミュニティ性能の基準は，6.4.3に規定する。
5.2.4
SRCFの安全インテグリティ要求仕様
5.2.4.1 必要なリスク低減を確実に達成するために，各SRCFの安全インテグリティは，リスクアセスメ
ントによって決定しなければならない。この規格では，各SRCFの安全インテグリティ要求は，PFHD（3.2.28
参照）の目標値によって定義する。
5.2.4.2 各SRCFの安全インテグリティ要求は，表3に示すSIL（附属書AにSIL割付けの方法例を示す。）
によって規定し，文書化しなければならない。
注記1 SRCFの要求安全インテグリティがSIL1未満である場合には，少なくともJIS B 9705-1のカ
テゴリBの要求事項を満たすことが望ましい。
表3−安全インテグリティレベルを定義するSRCFの目標PFHD
安全インテグリティレベル
PFHD
SIL 3
10−8 ≦ PFHD ＜ 10−7
SIL 2
10−7 ≦ PFHD ＜ 10−6
SIL 1
10−6 ≦ PFHD ＜ 10−5
注記2 SILは，表3に示すPFHDだけによって決められるものではない。アーキテクチャによる制
約（6.7.6参照）及び系統的安全インテグリティの要求事項（6.7.9参照）もSILの決定に関連
する。
注記3 SIL 3に要求されるPFHDは，連続稼動とすれば約1 000年〜10 000年に一度故障する確率で
ある。この規格は機械類を対象としており，これより低い故障率を要求するSIL 4は扱わな
い。
注記4 PFHD は，システムの危険側ランダムハードウェア故障率λD に1時間を乗じて，無次元数に
したものである（6.7.8.2の式参照。）。
注記5 PFHD は，SRECSが1時間の間にSRCFを失う確率である。高頻度作動要求モードにおいて
は，PFHDは，作動要求時に安全機能が作動しないことが1時間の間に起こる確率になる（JB.7
を参照。）。
5.2.4.3 製品規格がSRCFのSILを規定している場合は，5.2.4及び附属書Aによらず，製品規格の要求SIL
19
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
を優先して適用する。
6
安全関連電気制御システム（SRECS）の設計及び統合
6.1
目的
箇条6は，SRS（5.2参照）によって指定された安全機能要求及び安全インテグリティ要求を満たすSRECS
を，選定又は設計するための要求事項を規定する。
6.2
一般要求事項
6.2.1 SRECSは，この規格の関連要求事項を考慮に入れて，SRS（5.2参照），及び該当する場合は，ソフ
トウェアSRS（6.10参照）に適合するように設計しなければならない。
6.2.2 SRECS（ハードウェア及びソフトウェアの全アーキテクチャ，センサ，アクチュエータ，プログラ
マブル電子装置，組込みソフトウェア，アプリケーションソフトウェアなどを含む。）の選定又は設計は，
6.5（既製品の選定）又は6.6（新規設計）のいずれかによって行わなければならない。いずれの方法をと
るにしても，SRECSは次の要求事項を満たさなければならない。
a) ハードウェア安全インテグリティ要求。この要求は，次の項目で構成される。
− ハードウェア安全インテグリティに対するアーキテクチャによる制約（6.6.3.3を参照）の要求。
− PFHDの要求（6.6.3.2参照）。
b) 系統的安全インテグリティ要求（6.4参照）。この要求は，次の項目で構成される。
− 故障回避の要求。
− 系統的フォールト抑制の要求。
c) フォールト検出時のSRECSの動きに対する要求事項（6.3参照）。
d) 安全関連ソフトウェアの開発設計に対する要求事項（6.10及び6.11参照）。
6.2.3 SRECSは，人間の能力及びその限界を（合理的に予見可能な誤用を含めて）考慮に入れて，オペレ
ータ及び保全作業者の資質に適応するように設計しなければならない。すべてのオペレータインタフェー
スの設計は，人間的要素を適切に取り入れて（JIS B 9706-1，JIS B 9706-2及びJIS B 9706-3参照），予想
されるオペレータの技量及び知識に見合うように実施しなければならない。一般人がオペレータとなり得
る大量生産のサブシステムをSRECSに用いる場合は，特にこのことを重視しなければならない。
注記 オペレータ又は保全作業者の合理的に予見可能な過誤は，設計によって防止又は除去すること
が望ましい。これが不可能な場合は，オペレータが過誤を犯す可能性を最小にするために他の
手段（例えば，指令を実行するために2回の操作を必要とする方式）も適用することが望まし
い。
6.2.4 SRECSの保全及び試験を容易にすることを，SRECSの設計段階，統合段階で考慮しなければなら
ない。
6.2.5 SRECSの設計（自己診断機能及びフォールト反応機能の設計を含む。）は，文書化しなければなら
ない。この文書は，次の条件を満たすものでなければならない。
− 正確，完全，及び簡潔である。
− 意図する目的に適する。
− アクセスでき，保全できる。
− バージョン管理できる。
6.2.6 SRECSの設計，開発，及び実現の成果は，適切な段階において検証しなければならない。
20
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
6.3
内部フォールト検出時のSRECSの動きに対する要求事項
6.3.1 1以上のハードウェアフォールトトレランスをもつサブシステムにおいては，内部に危険側フォー
ルトを検出したときは，指定のフォールト反応機能が作動しなければならない。
SRECSの仕様によっては，機械の安全な運転を続けながら，サブシステムのフォールト部分を分離して
修理［オンライン修理4)］することができる。この場合，フォールト部分の修理がPFHDの計算（6.7.8参
照）に用いた最大時間以内に完了しなければ，安全状態を維持するために第二のフォールト反応が作動す
るようにしなければならない。
オンライン修理できるように設計する場合，フォールト部分の分離は，分離によってSRECSの安全イ
ンテグリティがSRSで指定したレベル以下に低下しない場合以外は実施してはならない。
ハードウェアフォールトトレランスを0にするようなフォールトの発生後に対しては，6.3.2の要求事項
を適用する。
注記 信頼性モデルで考える平均修復時間MTTR（JIS Z 8115のMM10を参照）には，診断テスト間
隔，修理時間，及び修理完了するまでのすべての遅延を考慮に入れる必要がある。
注4) オンライン修理とは，（例えば，多重系システムにおいて正常なサブシステムに依存して）シス
テムの稼動を続けながら故障サブシステムを修理することをいう。
6.7.8.2.5に示すサブシステムDは，オンライン修理に対応できるサブシステムの例である。
ただし，サブシステムDでオンライン修理する場合のPFHDの計算については， JB.6.3及び
JB.6.4を参照。
6.3.2 要求PFHDを達成するために診断機能を用いる場合で，かつ，サブシステムのハードウェアフォー
ルトトレランスが0である場合は，SRCFによって防止するべき危険状態が発生する前に，フォールト検
出及び指定のフォールト反応が作動しなければならない。
注記 6.7.8.2.4に示すサブシステムCは，この要求が適用されるサブシステムの例である。6.3.2は，
式(C)が有効であるための条件，すなわち，DCが有効となる条件を規定している。JB.5を参照。
例外 ハードウェアフォールトトレランスが0であっても，診断テスト頻度が作動要求頻度の100倍
を超えるような特定のSRCFを実行するサブシステムの場合には，6.3.2の要求を除外するが，
そのサブシステムの診断テスト間隔は，サブシステムのPFHDの要求値を満たすものとしなけ
ればならない。
6.3.3 SIL 3のSRCFに含まれるフォールト反応機能が作動したことによって機械が停止した後は，フォー
ルトが修理されるか取り除かれるまでは，SRECSを介して機械を正規運転すること（例えば，機械の再起
動を可能にして）が可能であってはならない。規定の安全インテグリティがSIL 2以下のSRCFにあって
は，フォールト反応機能が作動した後の機械の動き（例えば，正規運転の再起動）は，関連するフォール
ト反応機能の仕様書による（5.2.3を参照）。
6.4
SRECSの系統的安全インテグリティに対する要求事項
注記1 6.4の要求事項は，システムレベル（SRECSを実現するためにサブシステムが相互に接続さ
れたレベル）に適用する。サブシステムの実現に関する要求事項は，6.7.8を参照。
注記2 この規格は，系統的ハードウェア故障の回避（6.4.1）及び系統的フォールトの抑制（6.4.2）
を要求している。回避（avoidance）と抑制（control）とは，似ているが同じではない。回避
は，故障の原因を作らないことである。抑制は，故障原因が存在してもうまく処理して危険
側故障にならないようにすることである。
6.4.1
系統的ハードウェア故障回避のための要求事項
21
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
6.4.1.1 系統的ハードウェア故障を回避するために，次の方策を適用しなければならない。
a) SRECSは，機能安全計画（4.2参照）に従って設計し，実現する。
b) サブシステムの選定，組合せ，配置，組立て，及び据付け（ケーブル配線及び相互接続を含む）を適
切に行う。
c) SRECS製造業者の仕様書の範囲内でSRECSを用いる。
d) 部品製造業者のアプリケーション資料（例えば，カタログ，据付説明書，及び仕様書）及び適正な技
術手法を用いる（ISO 13849-2のD.1も参照。）。
e) 動作特性が同じで，互換性のあるサブシステムを用いる（ISO 13849-2のD.1も参照。）。
f)
SRECS自体を，JIS B 9960-1の7.2及び9.1.1に従って保護する。
g) JIS B 9960-1の9.4.3に従って機能接地の接続不良を防止する。
h) 文書化されていない部品作動モードは用いない（例えば，プログラマブル装置の予備レジスタ）。
i)
予見できるSRECSの誤使用，環境変化，及び改修を考慮する。
6.4.1.2 さらに，SRECSの複雑度及びSRECSが実行する機能のSILを考慮に入れて，次の技術及び／又
は方策の少なくとも一つを適用しなければならない。
a) SRECSハードウェアの設計レビュー（例えば，検査又はウォークスルー）を実施する。レビュー及び
／又は分析によって，仕様と実現結果とのどんな不一致も明確にする。
注記1 仕様と実現結果との不一致を見付け出し，それらを解決できるように，製品の実現段階，
製作段階及び使用段階に関する疑問点，又は潜在的な弱点を文書化する。この場合，検査
においては，設計者が受動的で検査担当者が能動的になり，ウォークスルーにおいては，
設計者が能動的で，検査担当者が受動的となることを考慮する。
b) シミュレーション又は分析の能力をもつCADなどの支援ツール，及び／又は設計手順を系統的に実
行するCADツール（入手可能な試験済みの既設計要素とともに）を用いる。
注記2 これらのツールのインテグリティは，特定の試験によって，又は広い用途で満足に作動し
た実績によって，又は特定のSRECSの設計成果を独立に検証することによって示すこと
ができる。6.11.3.4参照。
c) シミュレーションを行う。SRECSの設計を，機能の作動，正しい数値設計［dimensioning 5)］及びサ
ブシステム間の相互作用に関して，系統的に漏れなくシミュレートする。
例 個々のサブシステム又はサブシステム要素の振舞いをシミュレートでき，これらを相互接続し
たときの回路の反応を各サブシステム又はサブシステム要素の境界データを見ることによっ
て調べることができるなら，SRECSの機能は，ソフトウェアの振舞いモデルによってコンピ
ュータ上でシミュレートすることができる。
注5) dimensioningとは，機械的には寸法設定，強度設計などをいう。電気的には，電流･電圧容量
の設定などをいう。
6.4.2
系統的フォールトを抑制する方策
系統的フォールトを抑制するために，次の方策を適用しなければならない。
a) 停電時の安全原理の採用。SRECSは，電源が断たれたとき，機械の安全状態が，達成又は維持される
ように設計する。
b) サブシステムの一時的故障の影響を抑制する方策をとる。SRECSは，例えば，次のように設計する。
− 個々のサブシステム又はサブシステム部分への電源電圧の変化（例えば，停電及び電圧低下）が危
険を招かないような設計をする（例えば，モータを駆動する回路の電源が一時的に停電した後に復
22
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
電したとき，予期しない始動が発生してはならない。）。
注記1 JIS B 9960-1の関連部分も参照。特に，次のことを実施することが望ましい。
− 過電圧又は不足電圧は早く検出し，すべての出力データ（回路）を電源オフルーチ
ン又は予備電源への切替えルーチンによって安全な状態に切り換えることができる
ようにする。及び／又は，
− 必要な場合，過電圧又は不足電圧は早く検出し，内部の状態を不揮発性メモリに保
存できるように，また，すべての出力データ（回路）を電源オフルーチンによって
安全状態にする，又はすべての出力データ（回路）を電源オフルーチン又は予備電
源への切替えルーチンによって安全な状態に切り換えることができるようにする。
− 物理的な環境又はサブシステムからの電磁妨害の影響が危険を導かないような設計をする。
c) すべてのデータ通信プロセスから生じる誤り及びその他の影響（伝送誤り，繰返し，消去，挿入，再
順序付け，損壊，遅れ，及び偽装を含む。）を抑制する方策。
注記2 さらに詳しい情報をIEC 60870-5-1及びIEC 61508-2に示す。
注記3 偽装（masquerade）とは，メッセージの本当の内容が正確に識別されないことをいう。例
えば，偽装（見せかけ）によって非安全関連構成品からのメッセージが安全関連構成品か
らのメッセージとして間違って識別される。
d) インタフェース部分において危険側フォールトが発生するとき，このフォールトによって危険源が発
生する前に，フォールト反応機能が作動しなければならない。ハードウェアフォールトトレランスを
0にするフォールトが発生するときは，このフォールト反応は，推定MTTR［6.7.4.4.2 g) 参照］に相
当する時間が経過する前に作動しなければならない。
d)の要求事項は，サブシステムの入力，出力，及び統合中にケーブル接続を必要とするサブシステ
ムのその他のすべての部分（例えば，ライトカーテンの出力信号開閉器，ガードの位置検出器の出力
部）に適用する。
注記4 このことは，サブシステム又はサブシステム要素がそれ自身の出力上でフォールトを検出
することを要求してはいない。フォールト反応機能は，診断テストが実行された後に，続
いて作動する任意のサブシステムによって始動してもよい。
6.4.3
電磁イミュニティ
SRECSは，JIS C 61000-6-2及び附属書Eに示す電磁イミュニティ要求を満足するほかに，電磁妨害に
対する機能の安全性について次の性能基準を満足しなければならない。
− 不安全状態又は危険状態が生まれてはならない。及び，
− SRCFを失わない。又は，
− 危険が発生する前に機械の安全状態が維持又は達成されるならば，SRECSが実行するSRCFは一時的
又は永久的に阻害されてもよい。妨害が構成品の破壊をもたらす場合（部分破壊をもたらすような低
レベルの妨害も含む。）は，機能の安全性が影響を受けないことが保証（例えば，分析によって）され
なければならない。
注記 附属書Eに示すレベル以内のすべての電磁現象に対するSRECSの動きについて考慮すること
が望ましい。
6.5
SRECSの選定
SRSに規定される特定の機能をもつSRECSが既に市場に存在する場合は，その製品がSRSの要求事項
並びに6.3，6.4及び6.6.1に適合するならば，新規設計する代わりに既設計のSRECSを選定してもよい。
23
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注記 既設計のSRECSを選定することは，6.6による設計及び開発の代替手段である。
6.6
SRECSの設計及び開発
6.6.1
一般要求事項
6.6.1.1 SRECSは，SRECSのSRS（5.2参照）に従って設計･開発をしなければならない。
6.6.1.2 設計過程は，明確に構造化し，文書化しなければならない（6.6.2参照）。
6.6.1.3 要求の安全インテグリティを達成するために診断回路を用いる場合は，SRECSは，フォールト検
出時に，指定のフォールト反応機能（5.2及び6.3参照）を作動させなければならない。
6.6.1.4 SRECS又はSRECSの一部（サブシステム）が，SRCF及び他の非安全関連機能の両方を実行する
場合，SRCF及び他の機能の実行が十分に独立していること（他の機能のすべての故障がSRCFに影響し
ないこと）を示せないときは，SRECSのすべてのハードウェア及びソフトウェアを安全関連として取り扱
わなければならない。
注記 非安全関連部分と安全関連部分との間の従属故障の確率が，SRECSの安全インテグリティレベ
ルと同等であることを示すことによって，十分な独立性があることが確認される。
6.6.1.5 異なる安全インテグリティレベルの安全機能を実行するSRECS又はそのサブシステムは，それら
の安全機能の実行が十分に独立していることを示せない場合は，そのハードウェア及びソフトウェアは，
最も高い安全インテグリティレベルを満たさなければならない。
注記 異なる安全インテグリティレベルの安全機能を実行する各部分間の従属故障の確率がSRECS
の安全インテグリティレベルと同等であることを示すことによって，十分な独立性が実現され
ていることが確認される。
6.6.1.6 デジタルデータ伝送用途以外の相互接続（例えば，配線及びケーブル接続）は，それらが接続さ
れているサブシステムの一部であるとみなさなければならない［6.4.2 d)も参照］。
6.6.1.7 デジタルデータ伝送がSRECSの一部として使われる場合，それはSRCFのSIL目標値に応じてIEC
61508-2の関連要求事項を満足しなければならない。
6.6.1.8 SRECSの使用上の情報には，SRECSの有効寿命期間にわたって安全インテグリティレベルを維持
するために必要な技法及び方策を明記しなければならない。
6.6.2
設計及び開発の過程
SRECSの設計及び開発は，図2に示す過程のすべての段階を考慮に入れて，明確に定義した過程に従わ
なければならない。
注記 この規格は，SRS要求事項から始まる構造化設計過程をSRECSに適用することを求めている。
図3は，構造化設計過程の作業の流れ及び構造化設計の関連用語を示す。
6.6.2.1
システムアーキテクチャ設計
6.6.2.1.1 SRECSのSRSに規定される各SRCFは，例えば，図3に示すように，機能ブロック構造に分解
しなければならない。この構造は，次の内容からなる文書に記録しなければならない。
− 構造の説明。
− 各機能ブロックの安全要求事項（機能要求及びインテグリティ要求）。
− 各機能ブロックの入力，出力の定義。
注記1 機能分解は，機能ブロック構造がSRCFの機能要求及びインテグリティ要求を完全に表現す
るように行うことが望ましい。この過程は，機能ブロックの機能要求及びインテグリティ要
求をサブシステムに割り当て，一つのサブシステムに一つの機能ブロックの機能要求を完全
に割付け可能となるレベルまで適用することが望ましい。一つのサブシステムに一つ以上の
24
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
機能ブロックを割り当ててもよい。ただし，異なる機能及びインテグリティを与えようとす
る複数のサブシステムに同じ機能ブロックを割り当ててはならない。一つの機能ブロックの
機能要求を冗長サブシステム要素に割り当てる場合は，6.7.4を参照する。
注記2 各機能ブロックの入力及び出力は，転送する情報（例えば，スピード，ポジション，運転モ
ードなど）である。
注記3 機能ブロックは，SRCFの機能（3.2.16参照）を表すものであって，SRECSの診断機能（3.2.17
参照）は含まない。この規格では，診断機能はSRCFとは異なる構造をもつ別機能と考える
（6.8参照）。
6.6.2.1.2 機能ブロック構造に従って，SRECSアーキテクチャの概念設計を行わなければならない。
注記 アーキテクチャの概念設計は，SRECSアーキテクチャの開発者，装置の構成に責任をもつ部門，
及びソフトウェア開発者が協力しながら進めることが望ましい。ソフトウェア安全要求事項及
びこれを実現するソフトウェアアーキテクチャが確定するにつれて，SRECSハードウェアアー
キテクチャへの影響が生じることがある。したがって，SRECSアーキテクチャの設計者，サブ
システム納入者，ソフトウェア開発者，及び必要なら機械の設計者が緊密に協力することは，
系統的故障の可能性を低減することに寄与する。
6.6.2.1.3 各機能ブロックは，SRECSアーキテクチャ内のサブシステムに割り当てなければならない。一
つのサブシステムに複数の機能ブロックを割り当ててもよい。
6.6.2.1.4 各サブシステム及びそれに割り当てる機能ブロックは，明確に識別しなければならない。
6.6.2.1.5 アーキテクチャは，サブシステム間の相互関係の説明を付けて文書化しなければならない。
6.6.2.1.6 各機能ブロックの安全要求事項は，対応するSRCFのSRSから導き，次によって示さなければ
ならない。
− 機能要求（例えば，機能ブロックの入力情報，内部ロジック，及び出力）。
− 安全インテグリティ要求。
6.6.2.1.7 サブシステムのSRSは，そのサブシステムに割り当てる機能ブロックの安全要求でなければな
らない。複数の機能ブロックを割り当てる場合には，割り当てる機能ブロックの最も高いインテグリティ
要求を適用しなければならない（6.6.3参照）。これらの要求事項はサブシステムのSRSとして文書化しな
ければならない。
25
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図2−SRECSの設計及び開発作業の流れ
1. SRSが要求するSRCFに対して設計する
SRECSを特定する（5.2）。
6A. サブシステム機器を
選定する（6.7.3）。
6B. サブシステム機器を設
計・開発する（6.7.4）。
9. SRECSアーキテクチャを文書化する
（6.6.2.1.5）。
10. 設計したSRECSを製作する（6.9）。
7. 必要ならば，診断機能を設計する（6.8）。
8. 各SRCFを実行するアーキテクチャが達成
するSILを決定する（6.6.3）。
（要求事項を満たせない場合は
関連段階へ戻る。）
2. SRCFを機能ブロックに分解し（6.6.2.1.1），
SRECSアーキテクチャの概念設計を行う
（6.6.2.1.2）。
3. 各機能ブロックを詳細化する（6.6.2.1.6）。
4. 各機能ブロックをSRECSサブシステムに
割り付ける（6.6.2.1.3及び6.6.2.1.7）。
5. 検証する。
26
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図3−機能ブロックの安全要求事項をサブシステムへ割り付ける概念（6.6.2.1.1参照）
6.6.3
SRECSの安全インテグリティ推定に対する要求事項
6.6.3.1
一般事項
SRECSのSILは，SRECSが実行するSRCFごとに推定しなければならない。
SRECSのSILは，アーキテクチャによる制約，PFHD，及びSRECSを構成するサブシステムの系統的安
全インテグリティから決定しなければならない。付与できるSILの上限は，系統的安全インテグリティ及
びアーキテクチャによる制約に従う各サブシステムのSIL付与限界の最も低いレベルとするか，又はそれ
未満としなければならない。
6.6.3.2
ハードウェア安全インテグリティ
6.6.3.2.1 各SRCFのPFHDは，SRSが規定する目標PFHD以下にしなければならない。
注記 SILに対応するPFHDは，表3による。
6.6.3.2.2 各SRCFのPFHDを推定するときは，次のことを考慮しなければならない。
a) 対象とする各SRCFに関連するSRECSのアーキテクチャ。
注記 この要求は，サブシステムのどの故障モードが直列系（いかなる故障もそのSRCF実行の失
敗を招く。）に，どの故障モードが並列系（冗長系，すなわち，そのSRCFの実行が失敗する
ためには冗長系のすべてが故障する必要がある。）になるかを決めることを含む。
b) 各サブシステムが，割り当てられた機能ブロックの実行に失敗する確率の推定値（SRECSの危険側故
安全機能B
機能ブロックB2
機能ブロックB3
機能ブロックB1
機能ブロックA1
機能ブロックA2
機能ブロックA3
サブシステム2
サブシステム3
サブシステム1
割付け
概念的表現：
機能ブロック
（F = FB1 AND FB2 AND FB3）
現実的表現：
アーキテクチャ
安全機能A
SRECS
27
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
障を招くようなすべてのモードで。）。
6.6.3.2.3 PFHDの推定は，6.7.2.2［サブシステム間のデジタルデータ伝送プロセスが該当する場合はk)も
適用。］に規定する情報を用いて導いた各サブシステムのPFHDに基づくものでなければならない。システ
ムのPFHDは，SRCFを遂行するすべてのサブシステムのPFHDの和とし，該当する場合はデジタルデータ
伝送プロセスの危険側伝送誤り確率を含めなければならない。
PFHD ＝ PFHD1 ＋……… ＋ PFHDn ＋ PTE
注記1 この手法は，“いずれの機能ブロックの故障もSRCF（3.2.16を参照）の故障をもたらす”と
いう機能ブロックの定義（3.2.32参照）に基づいている。
注記2 デジタルデータ伝送以外の相互接続は，サブシステムの一部であるとみなす。
6.6.3.3
アーキテクチャによる制約
アーキテクチャによる制約に基づき，SRECSのSILは，SRCFを遂行する各サブシステムのSIL付与限
界（6.7.6参照）のうちで最も低い限界レベル以下のレベルとしなければならない。
注記 例えば，SRECSが二つの直列接続されたサブシステム（サブシステム1及びサブシステム2）
で構成され，各サブシステムのSFF及びフォールトトレランスが表4のとおりであると仮定す
る。SRECSの目標PFHDが8×10−8であるとする。それはSIL 3に相当する。しかしながら，
表5によればサブシステム2のアーキテクチャによる制約は，SRECSに付与できるSILをSIL 2
に制限する。
表4−この例で用いるサブシステム1及びサブシステム2の特性
サブシステム
ハードウェアフォー
ルトトレランス
SFF
アーキテクチャによる制約に基づく
SIL付与限界（表5参照）
1
1
95 ％
SIL 3
2
1
80 ％
SIL 2
6.6.3.4
系統的安全インテグリティ
SRECSに付与できるSILは，SRCFを遂行する各サブシステムの系統的安全インテグリティによるSIL
付与限界のうちで最も低い限界レベル以下とする。
注記 6.7.9に規定する方策は，6.7.4に従って実現されるサブシステムの系統的安全インテグリティに
対してSIL 3までの付与限界を与える。
6.7
サブシステムの実現
6.7.1
目的
6.7は，割り当てた機能ブロック（図3参照）のすべての安全要求事項を満たすサブシステムの実現につ
いて規定する。サブシステムの実現には，次の二つの方法がある。
− サブシステムの要求事項を十分満たす装置を選定して用いる。すなわち，割り当てた機能ブロックの
SRS及びこの規格の要求事項を満たす装置を選定する。
− 新規に設計及び開発を行う。機能ブロック要素を結合して，それらをどのように相互作用させるかを
設計する。
6.7.2
サブシステム実現に対する一般要求事項
6.7.2.1 サブシステムは，6.2のすべての要求事項を考慮に入れて，そのSRS（6.6.2.1.7参照）に従って，
選定（6.7.3参照）又は設計（6.7.4参照）することによって実現しなければならない。高複雑度構成品を
28
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
用いるサブシステムは，必要とするSILに応じてIEC 61508-2及びIEC 61508-3に適合しなければならな
い。
例外 IEC 61508-2及びIEC 61508-3に適合する高複雑度構成品をサブシステム要素として含むサブ
システム設計をする場合は，6.7.4.2.3を適用する。
6.7.2.2 各サブシステムについて次の情報を入手しなければならない。
a) SRCFを実行するサブシステムの機能及びインタフェースの仕様。
b) SRECSの危険側故障を招くすべての故障モードでの推定故障率（ハードウェアの偶発故障による。）。
注記1 電気･機械複合サブシステム（例えば，リレー）においては，故障率の推定は，製造業者発
表の作動可能回数及びデューティサイクル（5.2.3参照）を考慮することが望ましい。この
情報は，B10値（全体の10 ％が故障するまでの期待値）に基づくものとすることが望ま
しい（IEC 61810-2も参照。）。
c) サブシステムに関する次の制約。
− 偶発故障率の推定値が妥当性をもつための環境条件。
− 偶発故障率の推定値が妥当性をもつために，これを超えて使用してはならないサブシステムの寿命
時間。
d) 試験及び／又は保全の要求事項。
e) 必要ならば，DC及び診断間隔（T2）（注記2参照）。
注記2 e)は，サブシステムとは別扱いの診断機能にかかわる事項である。この情報は，SRECSの
信頼性モデルが，サブシステム内で実行される診断機能に関係するときだけ必要である。
f)
診断によるフォールト検出後の平均修復時間（MTTR）を導くために必要なすべての追加情報（例え
ば，修理時間）。
注記3 b)〜f) は，SRCFのPFHDを見積もるために必要である。
g) アーキテクチャによる制約に基づくSILCL（6.7.6参照）。
− SRECSに用いるサブシステムのSFFを導くために必要なすべての情報。
注記4 サブシステムの部品故障が，どのような故障モードで起こり得るかの情報が必要である。
サブシステムの部品故障モードに基づいて，サブシステム故障がSRECSに安全側故障を起
こすか，又は危険側故障を起こすかを決めることができる。
注記5 SFF推定の詳細については6.7.7参照。
− サブシステムのハードウェアフォールトトレランス。
h) 系統的故障を回避するためのサブシステム使用上の制限。
i)
次のことを考慮して，サブシステムを用いるSRCFに対して付与できる最も高い安全インテグリティ
レベル。
− サブシステムのハードウェア及びソフトウェアの設計及び実現の段階において，系統的フォールト
の誤入を防止する方策及び技術。
− サブシステムが系統的フォールトに耐えるようにする設計技術。
注記6 h) 及びi) は，アーキテクチャによる制約を踏まえてSRCFに対して付与できる最も高い
安全インテグリティレベルを決定するために必要である。これらの項目は，フォールト検
出及びハードウェアフォールトトレランスの観点からJIS B 9705-1のカテゴリ要求と結び
付けるために用いることもできる。
j)
6.11.3.2によるSRECSの構成管理を可能にするために，サブシステムのハードウェア及びソフトウェ
29
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
アの構成識別に必要な情報。
k) 該当する場合は，デジタルデータ伝送における危険側伝送誤りの確率。
6.7.3
既存（既設計）サブシステムを選定する場合の要求事項
6.7.3.1 SRSに規定するSRCFを実行する既存サブシステムが存在するときは，その製品がサブシステム
のSRS，6.4.3の要求事項，並びに6.7.3.2又は6.7.3.3の要求事項に適合するならば，新規に設計する代わ
りにこのような既設計サブシステムを選定してもよい。
6.7.3.2 高複雑度構成品を含むサブシステムは，必要とするSILに応じてIEC 61508-2及びIEC 61508-3
に適合しなければならない。
例外 IEC 61508-2及びIEC 61508-3に適合する高複雑度構成品を，サブシステム要素として用いるサ
ブシステムを設計する場合は6.7.4.2.3による。
6.7.3.3 低複雑度構成品だけで構成するサブシステムは，6.7.4.4.1，6.7.6.2，6.7.6.3，6.7.7，6.7.8及び6.8
の要求事項を満たさなければならない。
6.7.4
サブシステムの設計及び開発
6.7.4.1
目的
6.7.4.1.1 6.7.4は，第一に，割り当てた機能ブロックの安全要求事項を満たすサブシステムの設計につい
て規定する。
6.7.4.1.2 6.7.4は，第二に，サブシステムに割り当てたすべての機能ブロックの機能要求及び安全インテ
グリティ要求を満たすアーキテクチャの具体化について規定する。
6.7.4.2
一般要求事項
6.7.4.2.1 サブシステムは，そのSRSを満足するように設計しなければならない。
6.7.4.2.2 サブシステムは，次のa)〜c) の要求事項のすべてを満たすものとしなければならない。
a) ハードウェア安全インテグリティ要求。この要求は，次の事項からなる。
− SILに対するアーキテクチャによる制約（6.7.6参照）。及び，
− PFHDの要求事項（6.7.8参照）。
b) 系統的安全インテグリティ要求。この要求は，次の事項からなる。
− 故障回避の要求事項（6.7.9.1参照）及び系統的故障抑制の要求事項（6.7.9.2参照）。又は，
− 機器の性能を使用実績によって証明できる証拠。
この場合，サブシステムは，IEC 61508-2の関連要求事項（IEC 61508-2の7.4.7.5〜7.4.7.12参照）
を満たさなければならない。
c) フォールト検出時のサブシステムの動き（フォールト反応）に関する要求（6.3参照）。
6.7.4.2.3 サブシステムの設計において，SILCLに関連するIEC 61508-2及びIEC 61508-3のすべての関連
要求事項を満たす高複雑度構成品をサブシステム要素として用いる場合，その構成品は，サブシステム設
計の観点では低複雑度構成品とみなすことができる。それは，関連故障モード，フォールト検出時の動き，
推定故障率，及び他の安全関連情報が既知だからである。このような構成品は，その供給者が提供する使
用のための適切な情報に従って用いなければならない。
6.7.4.3
サブシステムの設計及び開発の過程
サブシステムの設計及び開発は，明確に定義した過程に従って行わなければならない。図4に示す過程
のすべての局面を考慮に入れなければならない。
30
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図4−サブシステムの設計及び開発作業の流れ（図2のボックス6B.参照）
6.7.4.3.1
サブシステムアーキテクチャの設計
6.7.4.3.1.1 サブシステムアーキテクチャの設計において，機能分解の過程は，機能ブロックの機能要求事
項を完全に満たすように機能ブロック要素が構成されるまで行うことが望ましい。この過程は，各機能ブ
ロック要素の機能要求事項をサブシステム要素に割付けできるレベルまで行うことが望ましい（図5参照）。
注記 サブシステムの設計及び開発作業の流れは，図4に示す。
6.7.4.3.1.2 サブシステムアーキテクチャは，各サブシステム要素及びそれらの相互関係を明確にして，文
書化しなければならない。必要な場合は，サブシステム要素に割り付けた機能ブロック要素に関連する情
報も文書化しなければならない。
サブシステム要素の内部構造に適合するサブシステムア
ーキテクチャを設計する（6.7.4.3.1.1）。
各サブシステム要素に対して，SRS（機能及びイ
ンテグリティ）を詳細化する（6.7.4.3.1.2）。
サブシステム要素として用いる
機器を選定する（6.7.4.4）。
サブシステム要素を設計及
び開発する。
サブシステム要素を組み合わせてサブシス
テムを構成し，文書化する（6.7.9）。
サブシステムが達成する安全性能を決定す
る（6.7.5）。
31
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図5−機能ブロックを分解してサブシステム要素に割り付ける概念
6.7.4.4
サブシステム要素の設計及び選定に対する要求事項
6.7.4.4.1 サブシステム要素は，意図する使用に適するものであって，関連規格があれば，それらに適合
しなければならない。
6.7.4.4.2 各サブシステム要素に関し，次の情報を入手しなければならない。
a) サブシステム要素の機能仕様。
b) サブシステム要素のインタフェース仕様（例えば，電気的特性）。
c) 故障のモード及び故障モード比率，並びに該当する場合（例えば，6.7.4.2.3に従って用いる高複雑度
構成品）は，DC及びPFHD 。
d) サブシステム要素に対する次の制約。
− c)で得た情報の妥当性を保証できる環境条件及び使用条件。
− c)で得た情報の妥当性を保証できるサブシステム要素の寿命時間。
e) 周期的なプルーフテスト及び／又は保全に関するすべての要求事項。
f)
診断に寄与する特徴（例えば，機械的連動接点の使用）。
g) 診断によるフォールト検出後のMTTRを導くために必要な，すべての追加情報（例えば，修理時間）。
h) 系統的故障を回避するために必要な，サブシステム要素の使用上のすべての制限。
i)
ハードウェアフォールトトレランス。
機能ブロック
機能ブロック要素1
機能ブロック要素2
サブシステム要素1
サブシステム要素2
概念的表現：
機能ブロック
（FB = FBe1 OR FBe2）
サブシステム
割付け
現実的表現：
アーキテクチャ
6.7.4.3.1を参照。
32
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
6.7.5
サブシステムの安全性能の決定
サブシステムの安全性能には，そのアーキテクチャによる制約（6.7.6）によるSILCL，系統的安全イン
テグリティ（6.7.9），及びPFHD（6.7.8）が関連する。
注記1 サブシステムのSILCLは，このサブシステムを用いるSRCFに付与できる最大のSILを制限
する。
注記2 SILCL，系統的インテグリティ，及びPFHDは，割り当てたSRCFを実行するSRECSサブシ
ステムが達成するSILを決定するために必要である。
6.7.6
サブシステムのハードウェア安全インテグリティ付与に対するアーキテクチャによる制約
6.7.6.1 ハードウェア安全インテグリティの付与において，SRCFに付与できる最高のSILは，SRCFを実
行するサブシステムのハードウェアフォールトトレランス及びSFFによって制限される。表5は，サブシ
ステムのハードウェアフォールトトレランス及びSFFを考慮に入れて，サブシステムを用いるSRCFに付
与できる最高のSILを規定している。表5に示すアーキテクチャによる制約を各サブシステムに適用しな
ければならない。これらのアーキテクチャによる制約に関して，次のa)，b)，c) を適用する。
a) ハードウェアフォールトトレランスがNであるということは，N＋1個の危険側フォールトが発生す
るとSRCFの失敗が起こり得ることを意味する（注記1参照）。ハードウェアフォールトトレランスの
決定には，自己診断のようなフォールトの影響を抑制する方策は関係しない（注記2参照）。
注記1 例えば，6.7.8.2.3のサブシステムB及び6.7.8.2.5のサブシステムDは，いずれもフォール
トトレランス1のサブシステムであるが，サブシステムBは，フォールトトレランスが0
になった後も運転を続ける（続けざるを得ない）が，サブシステムDは，フォールトトレ
ランスが0になったことを検出したら運転を停止することができる。
注記2 例えば，6.7.8.2.4のサブシステムCは，診断機能をもっているが，診断で検出できない危
険側故障によって安全制御機能を失うから，フォールトトレランスは0である。
b) 一つのフォールトが，続いて一つ又は複数のフォールト発生を直接引き起こす場合には，これらは一
つのフォールトとみなす。
c) ハードウェアフォールトトレランスを決定する場合，特定のフォールトの発生確率が，サブシステム
の安全インテグリティ要求に照らして非常に低いならば，このようなフォールトは除外（無視）して
もよい。そのようなフォールトを除外するときは，除外することの正当性を説明し，文書化しなけれ
ばならない（6.7.7も参照）。
6.7.6.2 表5のアーキテクチャによる制約は，SRCFの機能ブロックを実行するサブシステムごとに適用し
なければならない。
6.7.6.3 一つのサブシステム要素からなるサブシステムは，表5の要求事項を満たさなければならない。
特に，ハードウェアフォールトトレランスが0のサブシステムは，診断機能によって99 ％以上のSFFを
達成しなければならない。
注記 この要求事項は，アーキテクチャによる制約が，一つのサブシステム要素からなるサブシステ
ムのSILCLをSIL 3にすることが適切であることを正当化するために必要である。
一つのサブシステム要素からなるサブシステム（非冗長系）が，この規格の定義によるフォ
ールトトレランス1以上をもつことはないと考えられる。
33
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表5−サブシステムのアーキテクチャに基づくSILCL
安全側故障比率（SFF）
ハードウェアフォールトトレランス N（注記1参照）
0（注記3参照）
1
2
SFF ＜ 60 ％
許されない
SIL 1
SIL 2
60 ％ ≦ SFF ＜ 90 ％ SIL 1
SIL 2
SIL 3
90 ％ ≦ SFF ＜ 99 ％ SIL 2
SIL 3
SIL 3
（注記2参照）
99 ％ ≦ SFF
SIL 3
SIL 3
（注記2参照）
SIL 3
（注記2参照）
注記1 ハードウェアフォールトトレランスNは，N＋1個のフォールトが安全機能の失敗を起こし得ること
を意味する。
注記2 SIL 4は，この規格では考慮しない。SIL 4に関してはIEC 61508-1を参照。
注記3 例外については6.7.7を参照。
6.7.6.4 サブシステムがJIS B 9705-1:2000に従って設計され，ISO 13849-2:2003に従って妥当性確認され
ている場合，アーキテクチャによる制約に限っては，JIS B 9705-1の特定のカテゴリをもつサブシステム
は，表6に示すハードウェアフォールトトレランス及びSSFをもつとみなす。
注記1 必要なSILを達成するためには，PFHD及び系統的安全インテグリティの要求事項を満たす
ことも必要である。
表6−サブシステムのカテゴリに基づくSILCL
カテゴリ
左欄のカテゴリをもつサブシステムは，下欄に示す
特性をもつものとみなす。
アーキテクチャによる制約
に基づくSIL付与限界
ハードウェアフォール
トトレランス
SFF
1
0
＜ 60 ％
注記1参照
2
0
60 ％〜90 ％
SIL 1
3
1
＜ 60 ％
SIL 1
1
60 ％〜90 ％
SIL 2
4
2以上
60 ％〜90 ％
SIL 3（注記3参照）
１
＞90 ％
SIL 3（注記4参照）
注記1 JIS B 9705-1では，SFF＜60 ％のものがカテゴリ1及びカテゴリ2に格付けされることはないため，
JIS B 9705-1に従って設計されるサブシステムは，実際には60 ％以上のSFFを達成すると考えられる。
注記2 カテゴリ2でSFF＞90 ％は，JIS B 9705-1の設計要求事項によって達成されないと考えられる。
注記3 ハードウェアフォールトトレランスが2以上（複数のフォールト蓄積を許容）のカテゴリ4サブシス
テムの場合は，DCは90 ％以下であると考える。
注記4 ハードウェアフォールトトレランスが1である場合は，カテゴリ4には90 ％超（ただし，99 ％未満）
のSFFを必要とする。
注記5 JIS B 9705-1のカテゴリBは，SIL 1を達成するとは考えられない。
6.7.7
SFFの推定
6.7.7.1 アーキテクチャによる制約に基づいてSILCLを決定する必要があるときは，SFFを推定しなけれ
ばならない。
6.7.7.2 SFFを推定するには，すべての関連フォールト及びその故障モードを決定するために，分析（例
えば，フォールトツリー分析，故障モード及び影響解析）を実施しなければならない。故障が安全側故障
34
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
であるか危険側故障であるかは，SRECS及びそのSRCF（フォールト反応機能を含む。）に依存する。特
定のモードで故障する確率は，関連するフォールトの発生確率を基礎に，意図する使用法を考慮して決定
しなければならない。故障モード比率は，次の情報から導くことができる。
a) フィールドの使用実績から集めたもので，意図する使用に該当する信頼できる故障率データ。
b) 権威ある産業情報提供者（附属書Dの注記2参照）からの部品故障データで，意図する使用に該当す
るもの。
c) 附属書Dに示す故障モードデータ。
d) 試験及び分析の成果から得た故障率データ。
例外 ハードウェアフォールトトレランスが0で，危険側故障につながり得るフォールトの除外を
適用したサブシステムは，そのサブシステムのアーキテクチャによる制約に基づくSILCLは，
SFFの推定値にかかわらず，SIL 2を限度とする。
6.7.7.3 フォールト除外を適用したときは，除外することの正当性を（例えば，分析によって）示し，文
書化しなければならない。
注記 ISO 13849-2の3.3及び表D.5に従ってフォールトを除外することが許容される。
6.7.8 サブシステムPFHDに関する要求事項
6.7.8.1 一般要求事項
6.7.8.1.1 サブシステムのPFHDは，サブシステムSRSに規定した目標故障率又はそれ以下にしなければ
ならない（6.6.2.1.7参照）。
6.7.8.1.2 割り当てた機能ブロックを実行する各サブシステムのPFHDは，次のことを考慮に入れて見積も
らなければならない。
a) 割り当てた機能ブロックに対応するサブシステムのアーキテクチャ。
注記1 アーキテクチャの考慮には，サブシステムがハードウェアフォールトトレランスをもつか
どうかを決めることを含む。
b) すべての故障モードを考慮に入れて，サブシステムの危険側故障を起こす可能性がある各サブシステ
ム要素の故障のうち，診断によって検出できる故障の率（6.3参照）。
c) すべての故障モードを考慮に入れて，サブシステムに危険側故障を起こす可能性がある各サブシステ
ム要素の故障のうち，診断によって検出できない故障の率（6.3参照）。
d) 共通原因故障に対するサブシステムの感受性（注記2参照）。
注記2 フォールト検出のために冗長構成品比較を用いる場合，冗長構成品が同じモードで同時に
故障するときは，フォールト検出の失敗が起こり得る。このような失敗は，共通原因故障
比率をβで表す共通原因故障（CCF）によって発生することがある。
共通原因故障に対する感受性を見積もるための単純化手法を6.7.8.3に示す。ハードウェ
ア関連の共通原因故障の影響を数量化することに関するさらに詳しい説明としてIEC
61508-6の附属書Dも参照。
e) 診断テスト（3.2.38参照）のDC及び関連する診断テスト間隔。
f)
診断によって検出できない危険側フォールトを見つけるために行うプルーフテストの間隔，及び／又
は上記のb) 及びc) で得られる情報が妥当性を失わないために超えてはならないサブシステム要素の
使用時間。
g) サブシステムをオンライン修理するように設計する場合は，検出したフォールトを修理する時間。
注記3 最大修理時間は，修復時間（JIS Z 8115のMM10参照）の一部になる。修復時間には，フ
35
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ォールト検出に要する時間及び修理作業を実行できない期間も含む（故障確率を計算する
ためにMTTRがどのように使われるかを例示したIEC 61508-6の附属書Bを参照。）。修理
が特定の期間（例えば，機械が停止されて安全状態にある期間）にだけ実行可能である状
況では，修理作業を実行できない期間を（これが比較的大きいときは特に）漏れなく考慮
することが特に重要である。
注記4 サブシステムのPFHDを見積もるための単純化手法を6.7.8.2に示す。他の方法も利用可能
であり，どれが最も適切な方法であるかは状況に依存する。利用可能な方法には，次のも
のがある。
a) フォールトツリー分析（IEC 61508-7のB.6.6.5及びIEC 61025を参照。）。
b) マルコフモデル（IEC 61508-7のC.6.4及びIEC 61165-13を参照。）。
c) 信頼性ブロック線図（IEC 61508-7のC.6.5を参照。）。
注記5 共通原因故障及びデータ伝送プロセスによる故障は，ハードウェア構成品の実際の故障で
はない他の影響（例えば，電磁障害，デコーディング誤りなど）に基因することがある（6.7.9
参照）。
6.7.8.1.3 故障確率が作動回数に関連するサブシステムでは，関連するSRCFの作動頻度を用いて，これら
の回数データを時間データに変換しなければならない（5.2.3参照）。
6.7.8.1.4 1以上のハードウェアフォールトトレランスをもつサブシステムの診断テスト間隔は，サブシス
テムのPFHD要求を満たすことができる間隔としなければならない（6.3.1参照）。
注記 この診断テスト間隔は，最初の故障を，続いてサブシステムの安全機能が失われる故障が起こ
る前に検出でき，サブシステムのPFHDが目標値より小さくなるような間隔にすることが望ま
しい。例えば，6.7.8.2.5の式(D1)及び(D2)において，要求されるPFHDssDを満たすようなT2に
する。
6.7.8.1.5 ハードウェアフォールトトレランスをもたないサブシステムの診断テスト間隔は，6.3.2の要求
事項を満たすようなものでなければならない。
6.7.8.1.6 JIS B 9705-1に従って設計し，ISO 13849-2によって妥当性確認された低複雑度のサブシステム
が，アーキテクチャによる制約（6.7.6参照）及び系統的安全インテグリティ（6.7.9参照）を満たすとき
は，ハードウェア安全インテグリティを見積もるために，表7に示すPFHDの限度値を適用してよい。
36
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表7−カテゴリをもつサブシステムのPFHDの限度値
カテゴリ
左欄のカテゴリをもつサブシステムは下欄
の特性をもつと想定する。
サブシステムに付与できるPFHD限度値
（注記1参照）
ハードウェアフォール
トトレランス
DC
1
0
0 ％
製造業者データ又は一般的なデータ（附属書
D参照）を用いる。
2
0
60 〜 90 ％
PFHD ≧ 10−6
3
1
60 〜 90 ％
PFHD ≧ 2×10−7
4
2以上
60 〜 90 ％
PFHD ≧ 3×10−8
1
＞ 90 ％
PFHD ≧ 3×10−8
注記1 PFHD付与の限度値は，サブシステムのMTTF（サブシステム製造業者又は関連データ便覧から得
る。），SRSに規定されるテスト又は確認の頻度（この情報はISO 13849-2の3.5によるサブシステム
妥当性確認のためにも必要。），及びこの表に規定するDC（これらの値はJIS B 9705-1に記述される
カテゴリの要求事項に基づいている。）の関数である。
注記2 JIS B 9705-1のカテゴリBは，SIL 1を達成できると考えない。
6.7.8.2
サブシステムのPFHD推定の単純化手法
6.7.8.2.1
一般事項
6.7.8.2は，幾つかの基本サブシステムアーキテクチャのPFHDを推定するための単純化手法を記述し，
低複雑度サブシステム要素又は高複雑度サブシステム要素から構成されるサブシステムに使える公式を示
す。公式は，信頼性解析理論を単純化したものであって，推定は安全方向に偏るように意図されている。
これらの公式が有効となる前提条件は，1≫ λ × T1（T1 は，プルーフテスト間隔又はSRECSの寿命時間の
いずれか短い方とする。）で，サブシステムは高頻度作動要求モード又は連続モード（3.2.27参照）で運転
されるものとする。サブシステムのPFHDと診断機能との関係については，6.8.6に規定する。
注記1 この手法によって得られるサブシステムのPFHDには，精度上の限界がある。これを受け入
れ難い場合は，さらに正確なモデル化技術（6.7.8.1.1参照）を適用してもよい。
注記2 式(A)〜式(D)においては，サブシステム要素の故障率λは一定で，十分に低い（ 1 ≫ λ× T ）
と仮定している。したがって，次の基礎方程式を用いることができる。
λ = 1 / MTTF
作動回数で寿命を定義する電気･機械複合部品（例えば，リレー）に対しては，B10値とデ
ューティサイクルCを用いて次の式によって決定する（5.2.3参照）。
λ = 0.1 × C / B10
注記3 用いる記号の意味は，次による。
λ = λS + λD
ここに，
λS： 安全側故障率
λD： 危険側故障率
PFHD = λD × 1h： 1時間中に故障する平均確率。
λD = λDD + λDU： 危険側故障率
λDD = λD × DC： 診断によって検出できる危険側故障率。
λDU = λD (1−DC)： 診断によって検出できない危険側故障率。
DC： 診断率
37
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
T2： 診断テスト間隔
T1： プルーフテスト間隔又はSRECS寿命のいずれか短
い方。
β： 共通原因故障係数
注記4 式(A)〜式(D)の検証及び補足説明を，附属書JBに示す。
6.7.8.2.2
基本サブシステムアーキテクチャA：診断機能なし，フォールトトレランス0（図6参照）
このアーキテクチャでは，サブシステム要素のすべての危険側故障がSRCFの故障を引き起こす。サブ
システムAのPFHDは，全サブシステム要素のPFHDの和であって，次の式で与えられる。
λDssA = λDe1+……+λDen ································································ (A)
PFHDssA = λDssA × 1h
注記1 このような単純なサブシステムは，たとえPFHDがSILの要求を満たしてもSFFが60 ％未
満ではSILを付与することはできない（表5参照）。
図6−サブシステムAの論理的表現
注記2 図6は，サブシステムAのアーキテクチャの論理的表現であって，物理的実体を示すもので
はない。
6.7.8.2.3
基本サブシステムアーキテクチャB：診断機能なし，フォールトトレランス1（図7参照）
このアーキテクチャでは，一方だけのサブシステム要素の一つの故障によってサブシステムBがSRCF
を喪失することはない。二つのサブシステム要素が共に危険側故障にならなければSRCFが故障（失敗）
に至ることはない。アーキテクチャBにおいては，サブシステムのPFHDは，次の式で与えられる。
λDssB = (1−β)2 × λDe1 × λDe2 × T1 + β (λDe1+ λDe2 ) / 2 ································· (B)
PFHDssB = λDssB × 1h
サブシステム要素2
λDe2(1−β)
サブシステムB
共通原因故障a)
β(λDe1＋λDe2)/2
注a) 共通原因故障は，共通系チャネル（例えば，切換系）の故障ではない。このモデルで
は共通系を省略している。共通系チャネルの危険側故障率を無視できない場合は，こ
れを式(B)に加えなければならない。
サブシステム要素1
λDe1(1−β)
サブシステム要素n
λDen
サブシステムA
サブシステム要素1
λDe1
38
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図7−サブシステムBの論理的表現
注記 図7は，サブシステムBのアーキテクチャの論理的表現であって，物理的実体を示すものでは
ない。
6.7.8.2.4
基本サブシステムアーキテクチャC：診断機能付き，フォールトトレランス0（図8参照）
このアーキテクチャでは，診断によって検出できないサブシステム要素の危険側フォールトは，すべて
SRCFを危険側故障に導く。診断機能がサブシステム要素のフォールトを検出したときは，診断機能はフ
ォールト反応機能を作動させる（6.3.2参照）。診断が連続的に行われるとみなせる場合，サブシステムC
のPFHDは，次の式で与えられる（周期的診断の場合は，JB.5.2を参照。）。
λDssC = λDe1 (1−DC1) +...............+ λDen (1−DCn) ···································· (C)
PFHDssC = λDssC × 1h
図8−サブシステムCの論理的表現
注記 図8はサブシステムCアーキテクチャの論理的な表現であって，物理的な実体を示すものでは
ない。診断機能は，次のいずれによって実行してもよい（6.8.2参照。）。
− 診断を必要とするサブシステム。
− SRECSの他のサブシステム。
− 安全機能の遂行に関与しないサブシステム。
6.7.8.2.5
基本サブシステムアーキテクチャD：診断機能付き，フォールトトレランス1（図9参照）
このアーキテクチャでは，サブシステムDは，一方のサブシステム要素の一つの故障によってはSRCF
を喪失しない。
異なる設計のサブシステム要素を用いる場合
周期的診断を行い，最初の危険側故障を診断によって検出すると同時に運転を停止する場合，又は直ち
に故障を修復して運転を続けることを前提にする場合，サブシステムDのPFHDは，次の式で与えられる。
（その他の前提条件における計算式は，JB.6を参照。）
λDssD = (1−β)2 { [λDe1×λDe2 (DC1 + DC2) ]×T2 /2 + [ λDe1×λDe2 (2 − DC1 − DC2) ]×T1 /2 }
+ β ( λDe1+λDe2 ) /2 ······································································ (D1)
PFHDssD = λDssD ×1h
ここに，
λDe1： サブシステム要素1の危険側故障率
DC1： サブシステム要素1の診断率
λDe2： サブシステム要素2の危険側故障率
DC2： サブシステム要素2の診断率
同じ設計のサブシステム要素を用いる場合
サブシステムC
診断機能
サブシステム要素1
λDe1
サブシステム要素n
λDen
39
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
サブシステムのPFHDは，次の式で与えられる。
λDssD = (1−β)2 { λDe2 × DC × T2 + [λDe2 × (1− DC) ] × T1 } + β × λDe ············ (D2)
PFHDssD = λDssD × 1h
ここに，
λDe： サブシステム要素1及び2の危険側故障率
DC： サブシステム要素1及び2の診断率
図9−サブシステムDの論理的表現
注記1 図9は，サブシステムDのアーキテクチャの論理的表現であって，物理的実体を示すもので
はない。診断機能は次のいずれによって実行してもよい（6.8.2参照。）。
− 診断を必要とするサブシステム。
− SRECSの他のサブシステム。
− 安全機能の遂行に関与しないサブシステム。
注記2 このサブシステムのフォールト反応は，6.3.1に規定するように，関連する運転を終結するこ
とであると考えられる。フォールト反応が単にフォールトを報告するだけで，関連する運転
を続けながら，オンライン修理するように設計する場合は，最初のフォールト発生後のサブ
システムのPFHDを，残存アーキテクチャに対して新たに決定する必要がある（JB.6を参照。）。
6.7.8.3
共通原因故障（CCF）の影響を推定する単純化手法
6.7.8.3.1 CCFに対するサブシステムの感受性のデータは，サブシステムのPFHD（6.7.8.1参照）を見積も
るために必要である。
6.7.8.3.2 必要なPFHDを達成するために，サブシステムに冗長系アーキテクチャを用いる場合，CCFがそ
の冗長性の効果を損ねることがあるならば，共通原因の発生確率に基づくPFHDを，冗長性サブシステム
のPFHDに加えなければならない。
6.7.8.3.3 通常，CCFの発生確率は，用いる技術，アーキテクチャ，使用法及び環境の組合せに依存する。
附属書Fは，多くのタイプのCCFを回避するために有効である。
6.7.8.3.4 附属書Fは，CCFに対するサブシステムの感受性を低くする設計に用いる方策の有効性を推定
するために使えるスコア表及び関連する方法論を含んでいる。
注a) 共通原因故障は，共通系チャネル（例えば，切換系）の故障ではない。このモデ
ルでは共通系を省略している。共通系チャネルの危険側故障率を無視できない場
合は，これを式(D1)及び式(D2)に加えなければならない。
サブシステムD
サブシステム要素1
λDe1(1−β)
診断機能
サブシステム要素2
λDe2(1−β)
共通原因故障a)
β(λDe1＋λDe2)
40
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
6.7.9
サブシステムの系統的安全インテグリティに関する要求事項
サブシステムの系統的安全インテグリティによるSILCLは，6.7.9.1及び6.7.9.2を満たすとき，SIL 3ま
でとする。
注記 これらの要求事項は，サブシステム要素がサブシステムを実現するために相互に結合される場
合には，サブシステムレベルにおいて適用する。SRECSの実現に関係する他の要求事項につい
ては6.4を参照。
6.7.9.1
系統的故障を回避するための要求事項
6.7.9.1.1 次の方策を適用しなければならない。
a) 構成品の適切な選定，組合せ，配置，組立て，及び据付け（ケーブル配線及び相互接続を含む）を行
う。製造業者の説明資料を適用し，適正な技術手法を用いる。
b) 製造業者の仕様書及び据付要領書の指示の範囲内でサブシステム及びサブシステム要素を用いる。
c) 互換性ある作動特性をもつ構成品を用いる。
d) 指定の環境条件に耐えるように設計する。すべての予期される環境及びすべての予見可能な過酷な条
件，例えば，温度，湿度，振動，及び電磁妨害の条件下においても作動するように，サブシステムを
設計する（ISO 13849-2のD.1参照。）。
e) 適切な規格に適合し，故障モードが明確であるような構成品を用いる。特定の故障特性（例えば，非
対称故障モード）をもつ構成品を用いて，検出できないフォールトによるリスクを低減する。
f)
適切な材料及び適切な製造法を用いる。ストレス，耐久性，弾力性，摩擦，摩耗，腐食，温度，導電
性，絶縁耐力などに対して，適切な材料，製造法及び処理法を選定する。
g) 正しい数値設計［6.4.1.2の注5)を参照］及び形状設計を行う。例えば，応力，ひずみ，疲労，温度，
表面精度及び製造誤差の影響を考慮する。
6.7.9.1.2 さらに，サブシステムの複雑度を考慮に入れて，次の方策の一つ以上を適用しなければならな
い。
a) ハードウェア設計レビュー（例えば，検査又はウォークスルーによる。）を行う。レビュー及び／又は
分析によって仕様及び実現結果の不一致を明らかにする。
注記1 6.4.1.2の注記1を参照。
b) シミュレーション又は分析の能力をもつCADツールを用いる。これによって設計手順を系統的に実
行する。入手可能な試験済みの自動構成要素も含む。
注記2 6.4.1.2の注記2を参照。
c) シミュレーションを行う。機能の作動及び構成品の正しい数値設計［6.4.1.2の注5)を参照］の両方に
関して，サブシステム設計の系統的なシミュレーションを行う。
6.7.9.2
系統的故障を抑制するための要求事項
6.7.9.2.1 次の方策を適用しなければならない。
a) 絶縁破壊，停電，電圧変動，過電圧及び不足電圧の影響を抑制する方策。
サブシステムがSRECSの安全状態を達成又は維持できるように，絶縁破壊，停電，電圧変動，過
電圧及び不足電圧の状態に対するサブシステムの動きを前もって決定しなければならない。
注記1 6.4.2の注記1を参照。制御回路の電源電圧は，モニタすることが望ましい。指定範囲から
外れたら，電源オフ，又は予備電源への切替えをすることが望ましい。
b) 物理的環境（例えば，温度，湿度，水，振動，ほこり，腐食性物質，及び電磁妨害）の影響を抑制又
は回避する方策。
41
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
SRECSが機械の安全状態を達成又は維持できるように，物理的環境の影響に対するサブシステムの
動きを前もって決定しなければならない（JIS B 9960-1参照。）。
c) 温度変動が起こり得る場合は，温度上昇又は温度低下の影響を抑制又は回避する方策。
サブシステムは，例えば，サブシステムが仕様外の温度で稼動し始める前に温度超過を検出できる
ように設計することが望ましい。
注記2 さらに詳しい情報を，IEC 61508-7のA.10に示す。
6.7.9.2.2 さらに，系統的故障を抑制するために次の方策の一つ以上を適用しなければならない。
− オンラインモニタ6) による故障検出。
− 冗長ハードウェアの比較テスト。
− 多様なハードウェア。
− ポジティブモード7) の作動（例えば，ガードが開いたらリミットスイッチが押される。）。
− 非対称故障モード8)。
− ディレーティングによって信頼性を向上することが示せる場合は，適正な係数による余裕設計。
注6) オンラインモニタとは，SRECSの運転を続けながらモニタすることをいう。
7) ポジティブモードとは，力，信号などの伝達系に故障要素が介在する余地のないモードをいう。
8) 非対称故障モードとは，故障が特定のモードに偏る（例えば，ゲートが必ずオン側に故障する。）
故障モードをいう。
注記1 ディレーティングすることが適切である場合には，少なくとも1.5倍の余裕係数にすること
が望ましい。
注記2 さらに詳しい情報を，ISO 13849-2のD.3に示す。
6.7.10 サブシステムの組立て
サブシステムを構成するために，サブシステム要素は，6.7.4.3.1.2及び文書化された詳細設計に従って結
合しなければならない。
6.8
診断機能の実現
6.8.1 各サブシステムは，アーキテクチャによる制約（6.7.6）及びPFHD（6.7.8）の要求事項を満たすた
めに必要な診断機能を備えなければならない。
6.8.2 診断機能は，SRCFとは異なる構造をもつ別個の機能であるとみなす。診断機能は，次のいずれに
よって実行してもよい。
− 診断を必要とするサブシステム自体。
− SRECSの他のサブシステム。
− 安全機能の遂行に関与しないSRECSサブシステム。
注記 6.6.2.1.1の注記3も参照。
6.8.3 診断機能は，関連するSRCFに適用される次の事項を満たさなければならない。
− 系統的故障を回避するための要求事項（6.7.9.1参照）。及び，
− 系統的故障を抑制するための要求事項（6.7.9.2参照）。
6.8.4 SRCFのPFHDを見積もるときは，SRECS診断機能の故障確率を考慮に入れなければならない。
注記1 6.6.2.1.1の注記3も参照。
注記2 診断機能をテストするタイミングは，SRCFをテストするタイミングと異なってもよい。一
般に，診断機能のテスト間隔は，ハードウェアフォールトトレランス1をもつサブシステム
に適用する要求事項を満たすことが望ましい。
42
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注記3 SRCFの安全インテグリティに対する診断機能の寄与が確実に維持されるように，診断機能
の故障を検出し，故障に対して適切に反応するようにすることが望ましい。診断機能の故障
は，オンラインテスト，冗長ハードウェアの比較確認などによって検出できる。
6.8.5 SRECS診断機能，及び診断による故障検出･フォールト反応を明確に記述し，関連するSRCFの安
全インテグリティに対する診断機能の寄与を分析しなければならない。
6.8.6 サブシステムのPFHDを推定する単純化手法（6.7.8.2）を適用する場合，次のことを適用しなけれ
ばならない。
− SRECSのPFHDの要求値を達成するために診断機能を用いる場合で，かつ，サブシステムのハードウ
ェアフォールトトレランスが0の場合は，フォールトによる危険が発生する前に，指定されたフォー
ルト検出及びフォールト反応が行われなければならない。さらに，次のいずれかを満たさなければな
らない。
− SRECS診断機能は，診断用回路の偶発故障確率及び系統的安全インテグリティが，少なくともSRECS
のSRCFに指定された値と同じになるようにしなければならない。又は，
注記1 ハードウェア安全インテグリティに対するアーキテクチャによる制約は，診断機能の実現に
は適用しなくてよい。
− 診断用回路の危険側故障確率がSRCFのPFHDより大きい場合は，診断機能又は診断装置が正しく作
動していることを確認するテストを実行しなければならない。このような診断機能のテスト頻度はサ
ブシステムに適用するプルーフテストの10倍が必要であると想定される。
注記2 診断機能のテストは，可能な限り診断機能実行部分の100 ％の範囲に対して行うことが望ま
しい。
注記3 診断機能をSRECSのロジックソルバによって実行する場合は，診断機能の故障もSRCFの故
障として表れるため，診断機能だけの機能テストを行うことは必要でない。
注記4 診断機能のテストは，外部手段（例えば，試験装置）又はSRECSのロジックソルバに組み
込んだ内部の動的試験によって実行できる。
6.9
SRECSハードウェアの実現
SRECSは，SRECS設計文書に従って実現しなければならない。
6.9.1
SRECSの相互接続
6.9.1.1 SRECSは，SRECS SRSの関連規定，並びにJIS B 9960-1の導体，ケーブル及び配線に関する規定
の該当部分を満足するように相互接続しなければならない。
6.9.1.2 相互接続の導体及びケーブルの故障を回避，抑制するための方策を6.4.1及び6.4.2に従って実施
しなければならない。
6.10 ソフトウェア安全要求仕様（SRS）の作成
6.10.1 一般事項
安全機能を実行するSRECSの一部にソフトウェアを用いる場合は，ソフトウェアSRSを作成して，文
書化しなければならない。
6.10.2 要求事項
6.10.2.1 ソフトウェアSRSは，SRECSの仕様書及びアーキテクチャを基礎にして，各サブシステムに対
して作成しなければならない。
6.10.2.2 各サブシステムのソフトウェアSRSは，(1) SRCFに指定された安全要求事項，(2) SRECSアーキ
テクチャによる要求事項，及び(3) 機能安全計画（4.2参照）の要求事項から導いて作成しなければならな
43
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
い。これらの情報は，アプリケーションソフトウェア開発者に提供しなければならない。
6.10.2.3 アプリケーションソフトウェアのSRSは，要求安全インテグリティを達成するSRECSを設計で
き，実現でき，検証できるように，十分に詳しく記述しなければならない。
6.10.2.4 アプリケーションソフトウェアの開発者は，要求事項がソフトウェアSRSに適切に規定されて
いることを確認するためにソフトウェアSRSに含まれる情報をレビューしなければならない。ソフトウェ
ア開発者は，特に次のことを含めて，ソフトウェアSRSがこの規格に適合するようにしなければならない。
− SRCF。
− システムの構成又はアーキテクチャ。
− 能力（容量）及び応答時間性能。
− 装置及びオペレータとのインタフェース。
− SRSで指定した機械のすべての対象操作モード。
− 外部装置（例えば，センサ及び最終要素）の診断テスト。
6.10.2.5 ソフトウェアSRSは，次のように，構造化し，記述しなければならない。
− 明確，検証可能，保全可能，及び使用可能で，安全インテグリティレベルに見合う。
− SRECSのSRSまでさかのぼることができる。
− あいまいな用語及び記述がない。
6.10.2.6 ソフトウェアSRSは，適切なハードウェア選定が可能になるような情報を盛り込み，各サブシ
ステムの必要な特性を記述しなければならない。ソフトウェアを用いて実現するSRCFに対し，次の要求
事項を規定しなければならない。
− そのサブシステムに割り当てたすべての機能ブロックの論理（機能）。
− 各機能ブロックに割り当てた入力及び出力のインタフェース。
− 入力及び出力データのフォーマット及び数値の範囲，及びそれらと機能ブロックとの関係。
− 各機能ブロックの限界値を示す関連データ。例えば，最大応答時間，有り得ない数値を確認するため
の限界値。
− そのサブシステムがSRECS内の他の装置（例えば，センサ及び最終要素）を診断する機能。
− 機械が安全状態を達成又は維持できるようにする機能。
− フォールトの検出，通知，及び処理に関連する機能。
− オンライン又はオフラインのSRCF周期テストに関連する機能。
− 無許可のSRECS変更を防止する機能。
− 非安全関連機能とのインタフェース。及び，
− 受容能力及び応答時間性能。
注記 インタフェースには，オフライン及びオンラインのプログラマブル装置を含む。
6.10.2.7 ソフトウェアSRSの文書化には，必要性，適切性に応じて，ロジック図，機能ブロック図又は
シーケンス図のような手法も用いなければならない。
注記 IEC 61506，ISO/IEC 15910及びISO/IEC 9254にソフトウェアの文書化の指針が示されている。
6.11 ソフトウェアの設計及び開発
6.11.1 組込みソフトウェアの設計及び開発
サブシステムに用いる組込みソフトウェアは，要求SILに応じて，IEC 61508-3に適合しなければなら
ない。
注記1 6.7.3.2も参照。
44
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注記2 附属書Cは，SRECSのSRCFを実行する組込みソフトウェアの設計及び開発を支援すること
を意図している。
6.11.2 ソフトウェア上のパラメタ設定
6.11.2.1 ソフトウェアSRS（6.10参照）に記述される安全関連パラメタのうち，ソフトウェア上のパラメ
タ設定をSRECS設計の安全関連側面の一つとして考慮しなければならない。パラメタ設定は，SRECS又
は関連サブシステム供給者が納入した専用のツールを用いて行わなければならない。このツールは，固有
の識別（名称，バージョンなど）をもたなければならない。パラメタ設定ツールは，例えば，パスワード
の使用によって，無許可の変更を防止しなければならない。
6.11.2.2 パラメタ設定に用いるすべてのデータは，そのインテグリティを維持しなければならない。この
ことは，次の方策を適用して達成しなければならない。
− 有効な入力データ範囲を管理する。
− 伝送前の制御データ破壊を抑制する。
− パラメタ伝送過程の誤りの影響を抑制する。
− 不完全なパラメタ伝送の影響を抑制する。
− パラメタ設定に用いるツールのハードウェア及びソフトウェアの欠陥及び故障の影響を抑制する。
6.11.2.3 パラメタ設定に用いるツールは，次の要求事項を満たさなければならない。
− 正しいパラメタ設定のために，この規格が規定するすべてのサブシステム関連要求事項を満たす。又
は，
− 安全関連パラメタの設定に特別な手順を用いなければならない。
この手順には，次のいずれかによるSRECS入力パラメタの確認方法，及び設定後の確認方法（例
えば，熟練者による確認，及びパラメタ設定ツールによる自動試験による確認）を含むものでなけれ
ばならない。
− 変更したパラメタをパラメタ設定ツールに再送して確認する。
− パラメタのインテグリティを別の確認手段で確認する。
注記 この要求は，特にパラメタ設定に用いることを意図したものでない機器（例えば，パソコン又
は同等品）を用いてパラメタ設定を行う場合に特に重要である。
− 伝送･再伝送プロセスでエンコーディング･デコーディングに用いるソフトウェアモジュール，及び
SRECS使用者のために安全関連パラメタを視覚化するために用いるソフトウェアは，系統的故障を回
避するために，ダイバーシティを用いる。
6.11.2.4 ソフトウェア上のパラメタ設定の文書化においては，用いたデータ（例えば，事前に定義したパ
ラメタセット），及び，SRECS関連のパラメタ，パラメタ設定者，パラメタ設定日付などの関連事項を識
別するために必要な情報を示さなければならない。
6.11.2.5 ソフトウェア上のパラメタ設定に対して，次の検証を行わなければならない。
− 各安全関連パラメタが正しく設定されたことの検証（最小値，最大値，及び代表値）。
− 安全関連パラメタの有効性が確認をされたことの検証（例えば，無効データの検出によって）。
− 安全関連パラメタの無許可の変更が防止されていることの検証。
− パラメタ設定のためのデータ･信号の生成及び処理が，フォールトによってSRCFが失われない仕組み
になっていることの検証。
注記 この要求は，特にパラメタ設定に用いることを意図していない機器（例えば，パソコン又は同
等品）を用いてパラメタ設定を行う場合に特に重要である。
45
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
6.11.3 アプリケーションソフトウェアの設計及び開発
注記 6.11.3の規定は，IEC 61508-3に基づいている。
6.11.3.1 一般要求事項
6.11.3.1.1 IEC 61508-3の要求事項は，無制約可変言語（FVL）に適用する。制約可変言語（LVL）に基づ
くアプリケーションソフトウェアには，次の要求事項を適用しなければならない。
6.11.3.1.2 アプリケーションソフトウェアの開発中に実施した活動は，適切な段階で検証しなければなら
ない。
6.11.3.1.3 SRCFの要求SILを満足するために選定する設計方法及びアプリケーション言語は，適用上の
特徴として，次のことに適応するものでなければならない。
a) 抽象化，モジュール化，及びその他の特徴による複雑度の抑制 ソフトウェアは，可能な限り実証さ
れた論理関数を用いるものでなければならない。論理関数には，論理関数をリンクするためのユーザ
ライブラリ機能及び定義されたルールを含んでもよい。
b) 次の項目の表現
− 機能。理想的には論理の記述として，又はアルゴリズム的関数として。
− モジュール要素間の情報の流れ。
− シーケンス及びタイミングに関連する要求事項。
− タイミングの制約。
− データ構造及びそれらの特質（データの種類及び範囲の有効性を含めて。）。
c) 開発従事者の理解 アプリケーション機能の理解及びSRECSの技術的制約面の理解。
d) 検証及び妥当性確認 これには，アプリケーションソフトウェアの構造試験（ホワイトボックス），統
合アプリケーションプログラムの機能試験（ブラックボックス），並びに，SRECS及びそのアプリケ
ーションに固有のハードウェア構成との相互作用のインタフェース試験（グレーボックス）を含む。
e) 安全な変更
6.11.3.1.4 アプリケーションソフトウェアの検証では，試験を主な検証法にしなければならない。試験計
画は，次のことを明確にしなければならない。
− ソフトウェア及びハードウェアの統合検証の方針。
− 試験の区分け及び試験結果。
− 実行する試験のタイプ。
− 試験装置。ツール，支援ソフトウェア及び構成説明を含む。
− 試験の完了を判断する基準。
− 検証を実施する場所（例えば，工場又は納入先）。
− 外部機能に依存する部分。
− 必要な試験の量。
− 関連機能及び関連要求事項に対し検証漏れがない。
6.11.3.1.5 アプリケーションソフトウェアが，安全関連及び非安全関連制御機能の両方を実行する場合，
機能間の適切な独立性を設計で示せないときは，アプリケーションソフトウェアのすべてを安全関連とし
て扱わなければならない。
6.11.3.1.6 アプリケーションソフトウェアの設計には，アプリケーション階層におけるデータのインテグ
リティ確認及びデータの適切性確認（例えば，コミュニケーションリンクの確認，検出器入力の範囲確認，
及びデータパラメタの範囲確認）を含めなければならない。
46
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
6.11.3.1.7 制御の流れ及びデータの流れの自己モニタ機能を組込みソフトウェアに含められないときは，
それらの機能をアプリケーションソフトウェアの設計に含めなければならない。故障検出時は，安全状態
を達成又は維持するために適切な機能が作動しなければならない。
6.11.3.1.8 既開発のソフトウェアを設計の一部として用いる場合は，それらがソフトウェアのSRSを満足
させるために適切であることの正当性を示さなければならない。適切性は，新たに開発する安全関連ソフ
トウェアに類似するアプリケーションにおいて類似の機能を既開発ソフトウェアが満足に実行したという
証拠に基づいて示すか，又は新規開発と同じ検証及び妥当性確認手順を適用して示さなければならない。
既開発ソフトウェアは，使用実績のあるソフトウェア環境（例えば，オペレーティングシステム及びコン
パイラ類）からの制約を評価しなければならない。
6.11.3.1.9 アプリケーションソフトウェアを変更する場合は，すべての変更に対して，変更の影響を受け
るソフトウェアモジュールを識別する影響解析を行い，変更後もソフトウェアSRSを満たし続けることを
確認するために必要な再検証活動を行わなければならない。
6.11.3.2 ソフトウェアの構成管理
6.11.3.2.1 機能安全計画は，ソフトウェアの開発，統合，検証及び妥当性確認の方針を明確にしなければ
ならない。
6.11.3.2.2 ソフトウェア構成管理は，次のことを実施しなければならない。
− 要求のソフトウェア安全インテグリティの達成に必要なすべての作業が実施されたことを確認して保
証する。
− SRECSの安全インテグリティを維持するために必要な構成品目に関連するすべての文書を，正確に，
固有の識別を付けて，維持する。構成品目には，少なくとも次の事項を含まなければならない。
− 安全分析及び要求事項。
− ソフトウェア仕様及び設計文書。
− ソフトウェアソースコードモジュール。
− 試験計画及び試験結果。
− SRECSに組み込む既存のソフトウェアモジュール及びパッケージ。
− アプリケーションソフトウェアを作るため，試験するため，又はアプリケーションソフトウェア
に何らかの作業をするために用いるツール及び開発環境。
− 次のために，変更管理手順を適用する。
− 無許可の変更防止。
− 変更要求の文書化。
− 提案された変更の影響解析及び変更要求の承認又は拒絶。
− 許可されたすべての変更の詳細及び変更承認の文書化。
− ソフトウェア開発の適切な時点におけるソフトウェア構成の文書化。
− その後の監査を可能にするために，次の情報を文書化する。
− ソフトウェアの工程間引渡し状況。
− 変更の正当性説明及び変更の承認。
− 変更の詳細。
− アプリケーションソフトウェアの引渡しを正式に文書化する。引き渡されたソフトウェアの使用期間
をとおして保全及び変更を可能にするために，ソフトウェアのマスター及びすべての関連文書を維持
する。
47
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
6.11.3.3 ソフトウェアアーキテクチャに対する要求事項
注記1 ソフトウェアアーキテクチャは，システムソフトウェア及びアプリケーションソフトウェア
の主要な構成品及びサブシステムを定義し，また，それらを相互に接続する方法及び要求特
性を達成する方法を定義する。アプリケーションソフトウェアモジュールの例には，機械で
反復使用するアプリケーション機能，機械の入出力制御，割込み･禁止制御，データ妥当性確
認及びデータ範囲確認などのモジュールがある。
注記2 ソフトウェアアーキテクチャは，供給者から納入されたサブシステムアーキテクチャによっ
ても影響を受ける。
6.11.3.3.1 ソフトウェアアーキテクチャの設計は，SRECSのシステムアーキテクチャ及びサブシステム設
計の制約の中で，SRECSの要求SRSに基づいて行わなければならない。
6.11.3.3.2 ソフトウェアアーキテクチャの設計は，次のように行わなければならない。
a) SRECS及びその構成品の内部構造及び作動を包括的に記述する（注記参照）。
b) すべての識別されたソフトウェア構成品の仕様，並びに識別された構成品（ソフトウェア及びハード
ウェア）間の接続及び相互作用の説明を含める。
c) ブラックボックスでないすべての識別された構成品の内部設計及びアーキテクチャを含める。
d) SRECSに含まれるが，どのようなモードにおいても安全関連には使わないソフトウェアモジュールを
識別する。
注記 アーキテクチャの文書化は，SRECSに関して最新で完全であることが特に重要である。
6.11.3.3.3 アプリケーションソフトウェアの設計段階において，仕様を満たすために必要となる技術及び
方策を記述し，その正当性を示さなければならない。これらの技術及び方策は，SRECSの動きの予測を可
能にすることを目指し，SRECSの文書化で識別されたすべての制約と一貫していなければならない。
6.11.3.3.4 すべてのデータのインテグリティを維持するために用いる方策を記述し，その正当性を示さな
ければならない。このようなデータには，機械の入出力データ，通信データ，運転上のインタフェースデ
ータ，保全用データ，内部データベースなどがある。
6.11.3.4 支援ツール，使用者マニュアル，及びアプリケーション言語に対する要求事項
6.11.3.4.1 構成管理，シミュレーション，及び試験に用いるものを含め，適切なツールセットを選定しな
ければならない。SRECSの使用期間にわたって関連サービスを行う適切なツール（必ずしも最初のシステ
ム開発に使われるものではない。）を入手できるように配慮しなければならない。ツールの適切性の説明を
文書化しなければならない。
注記 開発ツールの選定は，ソフトウェア開発活動，組込みソフトウェア，及びソフトウェアアーキ
テクチャの性質に依存する。検証及び妥当性確認のために，コードアナライザ，シミュレータ
のようなツールが必要となることがある。
6.11.3.4.2 必要な場合，アプリケーションプログラム言語の構成部分（subset）を定義しなければならない。
6.11.3.4.3 アプリケーションソフトウェアは，SRECS及びサブシステム使用者マニュアルに含まれる既知
の，弱点及び制約を考慮に入れて設計しなければならない。
6.11.3.4.4 選定したアプリケーション言語は，次のことを満足しなければならない。
− トランスレータ及びコンパイラを用いて処理でき，目的に適すると評価されている。
− 完全に，明りょうに定義されているか，又は明りょうに定義された特徴だけに限定されている。
− アプリケーションの特性に合致する。
注記 アプリケーションの特性は，例えば，何らかの作動上の制約を意味する。
48
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− プログラミングの間違いを容易に検出できる特徴をもつ。及び，
− 設計方法に合致する特徴をもつ。
使用した言語に欠陥があれば，ソフトウェアアーキテクチャ設計の説明文書に記録しなければならない。
目的に対する言語の適切性は，指摘された言語の欠陥を是正するために必要な追加処置も含め，説明しな
ければならない。
6.11.3.4.5 アプリケーション言語の使用手順には，良好な構成手法を規定しなければならない。不安全な
はん（汎）用ソフトウェアの特徴（例えば，定義されていない言語要素，階層化されていない設計など）
を追放し，構成上の誤りを検出できる確認法を明確にして，アプリケーションプログラムを文書化する手
順を規定しなければならない。最小限，次の情報をアプリケーションプログラム文書に含めなければなら
ない。
a) 法人名（例えば，会社，作成者など。）。
b) 説明。
c) アプリケーション機能要求事項へのトレーサビリティ。
d) 標準ライブラリ機能へのトレーサビリティ。
e) 入力及び出力。
f)
構成管理。
6.11.3.5 アプリケーションソフトウェアの設計に対する要求事項
6.11.3.5.1 次の情報は，詳細なアプリケーションソフトウェア設計を開始する前に入手しなければならな
い。
− ソフトウェアSRS。
− ソフトウェアアーキテクチャ設計の説明。これには，次を含む。
− アプリケーションロジック及びフォールトトレランスの機能の識別。
− 入出力データのリスト。
− ソフトウェアモジュール。
− 用いる支援ツール。
− 定義したI/Oにアプリケーション機能をもたせるために，入手可能な材料を用いてアプリケーシ
ョンソフトウェアを構成する手順。
− ソフトウェアの安全性の妥当性確認計画。
6.11.3.5.2 アプリケーションソフトウェアは，次のことを達成するために構造化して作成しなければなら
ない。
− アプリケーション機能及びI/O制御データをモジュール化する。
− 機能（フォールトトレランスを含む。）及び内部構造の試験を容易にする。
− 適切なトレーサビリティをもたせ，アプリケーション機能及びそれに関連する制約の説明を準備する
ことによって，ソフトウェアの変更を安全に行う余裕度をもつ。
6.11.3.5.3 アプリケーションソフトウェアアーキテクチャの設計を記述する（6.11.3.5.1参照）とき，主要
な各構成品及びサブシステムは，次に基づいて，その設計を精ち（緻）にしなければならない。
− 設計を通して繰り返し用いる機能。
− アプリケーションソフトウェアモジュールの入出力情報マッピング。
− はん（汎）用ソフトウェア機能及びI/Oのマッピングによるアプリケーション機能の実現。
6.11.3.5.4 各アプリケーションソフトウェアモジュールの設計仕様，及び各モジュールに適用する構造試
49
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
験の仕様を明確にしなければならない。
6.11.3.5.5 アプリケーションプログラムがアプリケーションソフトウェアの指定された安全性を満足する
ことを保証するために，ソフトウェアとSRECSとの統合試験を適切に規定しなければならない。これに
は，次のことを考慮しなければならない。
− アプリケーションソフトウェアの分割。試験可能な統合セットになるまで分割する。
− 試験の区分。
− 実行する試験の種類。
− 試験環境，ツール，構成，及びプログラム。
− 試験の完了を判定する基準。
− 試験の失敗を修正する手順。
6.11.3.6 アプリケーションコードの開発に対する要求事項
6.11.3.6.1 アプリケーションソフトウェアは，次のことを満足しなければならない。
− 読みやすく，理解でき，試験可能である。
− 関連する設計原理を満たす。
− 安全計画の作成中に指定された関連要求事項を満たす。
6.11.3.6.2 アプリケーションソフトウェアは，指定された，設計，コーディング規則，及び安全計画の要
求事項に適合することを保証するためにレビューしなければならない。
注記 アプリケーションソフトウェアのレビューには，ソフトウェア検査，ウォークスルー，コード
分析，数学的証明などの技法を含む。これらの技法は，アプリケーションソフトウェアが関連
仕様を満足することを保証するために，試験及び／又はシミュレーションと組み合わせて用い
ることが望ましい。
6.11.3.7 アプリケーションモジュールの試験に対する要求事項
注記 アプリケーションソフトウェアがその試験仕様を正しく満足するか試験することは，検証活動
の一つである。アプリケーションソフトウェアモジュールがその関連仕様を満足することを保
証することの検証は，コードレビューと構造試験との組合せによって行う。
6.11.3.7.1 I/Oデータが正しいアプリケーションロジックにマッピングされていることを確認するために，
各入出力点の構成を，レビュー，試験，又はシミュレーションによって確認しなければならない。
6.11.3.7.2 意図した機能が正確に実行され，意図しない機能は実行されないことを判断するために，各ソ
フトウェアモジュールを，レビュー，シミュレーション，及び試験のプロセスによって確認しなければな
らない。
6.11.3.7.3 試験は，指定の試験対象モジュールに適し，次のことを保証できなければならない。
− すべてのブランチアプリケーションソフトウェアが確実に働く。
− 領域データが正しく使われる。
− シーケンスが正確に実行される（関連する同期条件を含めて）。
6.11.3.7.4 アプリケーションソフトウェアモジュールの試験結果は，文書化しなければならない。
6.11.3.7.5 ソフトウェアが評価済みである場合，又は良好に作動したという十分な実績があるときは，試
験の量を減らしてもよい。
6.11.3.8 アプリケーションソフトウェアの統合試験に対する要求事項
注記 ソフトウェアが正しく統合されたことを試験することは，検証活動の一つである。
6.11.3.8.1 アプリケーションソフトウェアの試験は，すべてのアプリケーションソフトウェアモジュール，
50
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
構成品及びサブシステムが，互いに（組込みソフトウェアとも相互して）正しく作用して，意図した機能
は実行し，安全機能を損ねる可能性をもつ意図しない機能は実行しないことを示さなければならない。
6.11.3.8.2 アプリケーションソフトウェア統合の試験結果は，文書化して次のことを記述しなければなら
ない。
− 試験結果。及び，
− 目標の試験基準が満たされたかどうか。
6.11.3.8.3 試験に失敗（不合格）した場合は，失敗の理由及び実施した修正を試験成績書に含めなければ
ならない。
6.11.3.8.4 アプリケーションソフトウェアの統合中にソフトウェアの変更又は修正を行った場合は，安全
影響解析を実施し，次のことを決定しなければならない。
− 影響を受けるすべてのソフトウェアモジュール。及び，
− 必要となる再検証及び再設計の活動。
6.12 SRECSの統合及び試験
注記 SRECSの統合は，通常，据付け前に行われるが，時には（例えば，アプリケーションソフトウ
ェア開発が据付け後まで完成しないとき），SRECS統合を据付け後まで実施できないことがあ
る。
6.12.1 一般要求事項
6.12.1.1 SRECSは，SRSに規定されたSRECS設計に従って統合しなければならない。SRECSは，SRECS
に組み入れたすべてのサブシステム及びサブシステム要素の統合活動の一部として，指定の統合試験法に
従って試験しなければならない。これらの試験によって，すべてのモジュールが正しく相互作用し，意図
した機能は実行し，意図しない機能は実行しないことを検証しなければならない。
6.12.1.2 安全関連アプリケーションソフトウェアとSRECSとの統合には，アプリケーションソフトウェ
アがハードウェア及び組込みソフトウェアプラットホームと互換性があり，機能及び安全インテグリティ
の要求を満足することを，保証するために設計開発段階で規定した試験を含めなければならない。
注記1 この要求事項は，すべての入力組合せを試験することを要求するものではない。すべての同
値類（equivalence classes。IEC 61508-7のB.5及びC.5.7参照。）を試験すれば十分である。
静的解析，動的解析又は故障解析によって試験のケース数を許容できるレベルまで減らすこ
とができる。構造化設計，又はロジック図，機能ブロック図，シーケンス図などの方法によ
る開発をすれば，試験及び検証が容易となる。
注記2 構造化設計又はこのような図式化手法を用いて，試験の件数及び深さを減らすことができる。
注記3 試験の件数及び深さを減らすために統計的証拠を用いることもできる。
6.12.1.3 SRECSの統合試験は，適切に文書化しなければならない。試験結果並びに設計開発段階で指定
した目的及び基準が満たされたかどうかを記述しなければならない。試験に失敗（不合格）した場合は，
失敗の理由を文書化し，修正を行い，再試験しなければならない。
6.12.1.4 統合及び試験の段階でSRECSの変更又は修正を行った場合は，影響解析を実施し，影響を受け
るすべての構成品を洗い出し，再検証しなければならない。
6.12.1.5 SRECS統合試験の段階では，次のことを文書化しなければならない。
a) 用いた試験仕様書のバージョン。
b) 統合試験の合格基準。
c) 供試SRECSのバージョン。
51
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
d) 用いたツール及び設備（校正データと共に）。
e) 各試験の結果。
f)
期待値と実現結果との不一致。
g) 不一致があったとき，実施した分析，及び試験を続けるか変更要求を出すかの決定。
6.12.2 SRECSの統合中に系統的安全インテグリティを決定する試験
6.12.2.1 フォールトを顕在化させ，アプリケーションソフトウェアとハードウェアとの統合中に失敗（故
障）を回避するための試験を行わなければならない。試験中，SRECSの規定された特性が達成されたかど
うかを調べるレビューを実施しなければならない。
6.12.2.2 次の試験を実施しなければならない。
a) 機能試験 SRECSの作動を特徴付ける適切なデータをSRECSに入力する。出力を観察し，それらの
応答を仕様書の規定と比較しなければならない。仕様書との不一致及び仕様書の不備を見つけた場合
は，文書化しなければならない。及び，
b) 動的試験 実際に用いる機能条件の下で振舞いを検証し，SRECSの機能仕様書を満足しなくなる不具
合を顕在化させ，SRECSの使用可能性及び強じん性を評価する。
注記 システム又はプログラムの機能は，指定の環境で，指定の試験データ（確立された判断基準
によって系統的にSRECSのSRSから導いたもの）を用いて実行する。これによってSRECS
の動きが顕在化され，仕様書との比較が可能になる。試験の目的は，SRECS及び／又はサブ
システムが，仕様書で要求されたすべての機能を正しく遂行するかを決定することである。
同値類を形成する手法は，ブラックボックス試験データを形成する手法の例である。入力デ
ータ空間は，特定の入力値範囲（同値類）に細分する。試験のケースは次のように分けられ
る。
− 許される範囲のデータに対する試験。
− 受け入れられない範囲のデータに対する試験。
− 範囲境界にあるデータに対する試験。
− 極限値に対する試験。及び，
− 上記の同値類の組合せ試験。
種々の試験活動（モジュール試験，統合試験，及びシステム試験）において試験のケース
を選定するために，他のデータ分類基準を用いることが効率的となることもある。
6.13 SRECSの据付け
6.13.1 目的
6.13は，SRECSが意図する使用に適し，妥当性確認を行えるようにするための据付けについて規定する。
6.13.2 要求事項
6.13.2.1 SRECSは，最終のシステム妥当性確認を実施できるように，機能安全計画［4.2.1 h)を参照］に
従って据付けしなければならない。
6.13.2.2 SRECS据付けに関する事項は，試験結果を含め，適切に記録しなければならない。試験に合格
しない部分があれば，不合格の理由を記録しなければならない。
7
SRECSの使用のための情報
7.1
目的
箇条7は，機械を使用及び保全する全期間を通して，SRECSに要求される機能安全を確実に維持するた
52
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
めの手順をSRECS使用者が確立するために必要なSRECSの使用上の情報について規定する。
7.2
据付け，使用及び保全のための文書化
注記1 JIS B 9700-2の6.に，装置附属文書の草案を作成するときに考慮するべき一般的情報を示す。
注記2 7.2に示す文書化要求項目には，据付け，使用及び保全以外の側面を満足させるために規定し
た事項も含まれる。
文書には，SRECSの据付け，使用及び保全のための情報を提供するために，次の事項を含めなければな
らない。
a) 装置，据付け，組立てについての包括的な説明。
b) SRECSの意図する使用，及び合理的に予見できる誤使用を防止する手段の説明。
c) 必要であれば，物理的な環境（例えば，照明，振動，雑音レベル，及び大気の汚染物）についての情
報。
d) 必要であれば，ブロック図。
e) 回路図。
f)
プルーフテスト間隔又は寿命。
g) SRECS機能と機械の非安全関連電気制御システムとの間の（相互接続図を含めて）相互作用（もしあ
るなら）の記述。
h) SRECS機能を機械の非安全関連電気制御システム機能から確実に分離するために必要な処置の説明。
i)
（例えば，手入力によるプログラミング，プログラム検証のために）SRECS機能を停止する必要があ
るときの安全維持を目的として備えた手段及び防護手段の説明。
j)
必要であれば，プログラミングに関する情報。
k) SRECSに適用する保全要求事項の記述。次のものを含む。
1) 機械の保全履歴を記録するためのログ。
2) SRECSの機能安全を維持するために実行するべきルーチン作業。一定寿命をもつ構成品の定期交換
を含む。
3) SRECSに障害又は故障が起きたときにとるべき保全手順。次のものを含む。
− フォールト診断及び修理のための手順。
− 修理後，正しい作動を確認する手順。
− 保全の記録要領。
4) 保全及び再立上げに必要なツール，並びにツール及び設備を保全するための手順。
5) 周期テスト，予防保全及び事後保全の仕様。
注記3 周期テストは，正しい作動を確認するため，及びフォールトを検出するために必要な機
能試験である。
注記4 予防保全は，SRECSの要求性能を維持するためにとる処置である。
注記5 事後保全には，特定のフォールト発生後に実施して，SRECSを設計どおりの状態に戻す
処置を含む。
8
SRECSの妥当性確認
注記 SRECSの妥当性確認は，機械全体の設計を検証する活動の一部となることもある。
8.1
目的
箇条8は，SRECSに適用する妥当性確認過程に対する要求事項を規定する。箇条8の要求事項は，SRS
53
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
に規定される要求事項をSRECSが確実に実行することを保証するための検査及び試験の要求を含む。
8.2
一般要求事項
8.2.1 SRECSの妥当性確認は，計画（4.2参照）に従って実行しなければならない。
注記1 妥当性確認は，据付け後まで完了できないことがある（例えば，アプリケーションソフトウ
ェアが据付け後まで完成しない場合）。
注記2 プログラマブルSRECSの妥当性確認は，ハードウェア及びソフトウェア両方の妥当性確認
からなる。ソフトウェアの妥当性確認に対する要求事項は，6.11.3に示す。
8.2.2 SRECSのSRSに規定された各SRCF（5.2参照），並びにSRECSの運転及び保全のすべての手順は，
試験及び／又は分析によって妥当性確認をしなければならない。
8.2.3 各SRCFに対し，SRECSの妥当性確認試験を適切に文書化しなければならない。次のことを記述し
なければならない。
a) 用いたSRECS妥当性確認計画書のバージョン及び試験に供したSRECSのバージョン。
b) 試験（又は分析）対象のSRCF。
SRECS妥当性確認計画の作成中に規定された要求事項の個別参照も示す。
c) 用いた設備及びツール。
校正データも付ける。
d) 各試験の結果。
e) 期待値と実現結果との不一致。
8.2.4 期待値と実現結果との不一致が発生した場合は，必要ならば，修正及び再試験を実施して，文書化
しなければならない。
8.3
SRECSの系統的安全インテグリティの妥当性確認
8.3.1 次の事項を適用しなければならない。
a) 仕様作成，設計及び統合の各段階における失敗（不具合）を顕在化させ，SRECSのソフトウェア及び
ハードウェアの妥当性確認段階における失敗（不具合）を回避するために，機能試験を行わなければ
ならない。この試験は，SRECSが過酷な環境影響から保護されるかどうか評価するための試験（例え
ば，検査又は試験）を含み，SRSに基づいて実施しなければならない。
注記1 6.12.2.1も参照。
b) SRECSが5.2.3.2を満足することを保証するための電磁妨害イミュニティ試験を行う。電磁妨害イミ
ュニティ試験は，SRECSが意図するアプリケーションの実行能力をもつことを分析によって示せると
きは，SRECSサブシステム又はサブシステム要素に対して実施しなくてもよい。
注記2 SRECSは，実施可能な限りすべての場合，典型的なアプリケーションプログラムを実装し，
すべての周辺装置との接続線（デジタル，アナログ，シリアル，及びバス，電源などのす
べてのインタフェース）に標準のノイズを加えることが望ましい。限界値を定量的に把握
するために，ノイズは少しずつ増加させることが望ましい。
c) 必要なSFFが90 ％以上である場合は，フォールト挿入試験を行わなければならない。これらの試験
では，SRECSハードウェアに実際にフォールトを起こさせるか，起こったようにシミュレートして，
フォールトに対するSRECSの反応を文書化しなければならない。
8.3.2 さらに，SRECSの複雑度及び割り当てたSILを考慮に入れて，次に示す分析的方法を一つ以上適用
しなければならない。
a) 静的分析及び故障分析を組み合わせて実施する。
54
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注記1 この組合せを用いることは，SRECS SRCFの割当SILがSIL1又はSIL 2の場合だけ適切で
あると考えられる。
注記2 詳しい情報をIEC 61508-7のB.6.4及びB.6.6に示す。
b) 静的分析，動的分析及び故障分析を組み合わせて実施する。
注記3 この組合せを，SIL1を割り当てたSRCFを実行するSRECSに用いることは推奨できない。
注記4 詳しい情報をIEC 61508-7のB.6.4，B.6.5及びB.6.6に示す。
c) シミュレーション及び故障分析を組み合わせて実施する。
注記5 この組合せを用いることは，SRECS SRCFの割当SILがSIL1又はSIL2の場合だけ適切で
あると考えられる。
注記6 詳しい情報をIEC 61508-7のB.3.6及びB.6.6 に示す。
8.3.3 さらに，SRECSの複雑度及び割り当てたSILを考慮に入れて，次の試験技法の一つ以上を適用しな
ければならない。
a) ブラックボックス試験 SRECS機能仕様に適合するために，実際に用いる機能条件下で故障を顕在化
させ，SRECSの利用性及び強じん性を評価するために，作動試験を実施する。
注記1 6.12.2.1も参照。
b) フォールト挿入試験 必要なSFFが90 ％以上である場合は，フォールト挿入試験を行わなければな
らない。これらの試験では，SRECSハードウェアに実際にフォールトを起こさせるか，起こったよう
にシミュレートし，フォールト反応の結果を文書化しなければならない。
c) 最悪ケース試験 分析的技法の適用（8.3.2参照）によって，規定された極限（すなわち，最悪）のケ
ースを評価するために，最悪ケース試験を行わなければならない。
注記2 SRECSの運転上の能力余裕及び構成品の定格余裕は，最悪条件の下で試験する。環境条件
は，許容限界値まで変化させる。SRECSの最も基本的な応答を点検して，SRSの要求事項
と比較する。
d) 運転実績の使用 SRECS妥当性確認段階のフォールトを回避する対策の一つとして，異なるアプリケ
ーションでの運転実績を妥当性確認試験に反映する。
注記3 6.12.2も参照。
9
SRECSの変更
9.1
目的
箇条9は，SRECSを，設計段階，統合段階及び妥当性確認段階（例えば，SRECSの据付け中及び立上
げ中）において変更するときに適用する変更手順について規定する。
9.2
変更の手順
9.2.1 SRECSの変更要求は，例えば，次のことから生じる。
− SRSの変更。
− 実際の使用条件の変更。
− 事例又は事故の経験。
− 加工材料の変更。
− 機械又は機械運転モードの変更。
注記 使用上の情報又は取扱説明書に従って行うSRECSへの介入（例えば，調整，設定，修理）は，
箇条9でいう変更とはみなさない。
55
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
9.2.2 SRECSの変更要求の理由は，文書化しなければならない。
9.2.3 変更要求の影響を，SRECSの機能安全に対する影響を確認するために分析しなければならない。
9.2.4 変更の影響解析及びSRECSの機能安全に対する影響は文書化しなければならない。
9.2.5 SRECSに影響するすべての変更は，そのハードウェア及び／又はソフトウェアの当該段階（例えば，
仕様決定，設計，統合，据付け，立上げ，妥当性確認など）へ回帰させなければならない。すべての後続
段階は，この規格がその段階に対して規定する手順に従って実行しなければならない。すべての関連文書
は，変更内容に応じて，修正し，改正し，再発行しなければならない。
9.2.6 変更を実施する前に，改正された文書に基づいて完全な実施計画を準備し，文書化しなければなら
ない。
9.3
構成管理手順
9.3.1 SRECSを変更する場合，次のことを考慮に入れて，構成管理手順を機能安全計画（4.2.1参照）に
従って実行しなければならない。
a) 各変更過程の計画。
b) 意思決定過程及びSRECSに関する決定事項の文書化。
c) 変更要求手順の時系列的文書化（例えば，ログブック）。これには，次のものを含める。
− SRECSの変更が影響すると考えられる危険源。
− 変更要求の記述（ハードウェア及び／又はソフトウェア）。
− 変更要求の理由（9.2.1参照）。
− 意思決定事項（及び各決定の承認）。
− 変更の影響解析。
− （各段階の）再検証及び再妥当性確認。
− 変更要求活動から影響を受けるすべての文書。
− 変更段階で実行した活動及びそれらに対する責任者及び責任組織。
d) 変更後の監査に必要となる次の情報の文書化。
− 構成状況。
− 工程間引渡し状況。
− すべての変更の正当性確認及びその承認。
− 変更の細目。
9.3.2 適切な変更管理過程の実施手順は，次の要求事項を考慮していなければならない。
a) SRECSの各バージョンの基礎形態を定義するための手順。
b) 基礎形態の全構成項目の定義。少なくとも次のものを含める。
1) 安全要求分析及び仕様決定。
2) 関連設計文書。
3) ハードウェアモジュール及び／又はソフトウェアモジュール。
4) 試験計画及び試験結果。
5) 検証報告及び妥当性確認報告。
6) SRECSに組み込む既存のソフトウェア構成品。
7) 製作及び試験に用いるツール及び開発環境。
8) SRECSのインテグリティを維持するために必要なすべての構成品目の固有の識別（識別は，正確に
維持する。）。
56
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
9) 次のことに適用する変更管理手順。
− 無許可の変更防止。
− 変更要求の文書化。
− 提案された変更要求の影響解析及び要求の承認又は拒絶。
− 許可したすべての変更の詳細の文書化。
− ハードウェア及び／又はソフトウェア開発の適切なポイントにおいて，構成の基礎形態を確立し
て，基礎形態の正当性を確認するための（部分的な）統合試験を文書化する。
− すべてのハードウェア及び／又はソフトウェアの基礎形態の構成及び構築（以前の基礎形態の再
構築を含めて）を保証する。
10) 影響解析 各変更の影響を解析する。この解析には適切な危険源分析も含め，SRECSの他のすべて
の変更活動を考慮に入れなければならない。
11) SRECSに影響を与えるすべての変更は，承認したら，SRECSハードウェア及び／又はソフトウェ
アの該当する段階（例えば，仕様決定，設計，統合，据付け，立上げ，及び妥当性確認）に回帰さ
せ，そこからすべての後続段階を，この規格の要求事項に従って遂行しなければならない。
12) 要求安全インテグリティが達せられたことを示すすべての必要な運転を実行する。
13) 必要な変更要求活動実施の正式認可は，影響解析の結果によらなければならない。
9.3.3 変更管理過程の文書化には，少なくとも9.3.1のa)〜d)，並びに変更に関連する組織上の要求事項及
び手順の文書化を含めなければならない。
10 文書化
10.1 文書は，次のことを満足しなければならない。
− 正確で，簡潔である。
− それを利用する人が理解しやすい。
− 意図する目的に適している。
− アクセスしやすく，維持しやすい。
10.2 SRECSの設計者は，使用者に関連する文書化と，SRECSの設計及び製作に関連する文書化とを区別
することが望ましい。
10.3 文書には，内容の範囲を示す題名又は名称を付けなければならない。
10.4 文書には，異なるバージョンを区別できるように改訂索引（バージョン番号）を付けなければなら
ない。
注記 文書管理に用いる手法に関しては，JIS Z 8245-1:2006にさらに詳しい情報の記載がある。
10.5 表8は，該当する場合に必要な情報及び文書化について規定する箇所を示す。
57
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表8−SRECSの情報及び文書化について規定する箇所
必要な情報
規定する箇所
機能安全計画
4.2.1
SRCFの要求仕様作成
5.2
SRCFの機能要求仕様
5.2.3
SRCFの安全インテグリティ要求仕様
5.2.4
SRECSの設計
6.2.5
構造化した設計過程
6.6.1.2
SRECS設計の文書化
6.6.1.8
機能ブロック構造
6.6.2.1.1
SRECS アーキテクチャ
6.6.2.1.5
サブシステムのSRS
6.6.2.1.7
サブシステムの実現
6.7.2.2
サブシステムアーキテクチャ（要素及び相互関係）
6.7.4.3.1.2
フォールトトレランス及びSFFを推定するときのフォールト除外
6.7.6.1 c)，
6.7.7.3
サブシステムアセンブリ
6.7.10
ソフトウェアSRS
6.10.1
ソフトウェア上のパラメタ設定
6.11.2.4
ソフトウェア構成管理項目
6.11.3.2.2
ソフトウェア開発支援ツールの適切性
6.11.3.4.1
アプリケーションプログラムの文書化
6.11.3.4.5
アプリケーションソフトウェアモジュールの試験結果
6.11.3.7.4
アプリケーションソフトウェア統合の試験結果
6.11.3.8.2
SRECS統合試験の文書化
6.12.1.3
据付け，使用及び保全のための文書化
7.2
妥当性確認試験の文書化
8.2.3，8.2.4
SRECS構成管理の文書化
9.3.1
58
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書A
（参考）
SILの割付け
序文
この附属書は，参考情報を提供するものであって，要求事項を規定するものではない。
A.1 一般事項
この附属書は，機械のSRCFに適用するリスク見積り及びSIL割付けのための定量的な手法の例を提供
する。SILの割付けに使える他の手法例は，IEC 61508-5に与えられている。
注記1 この附属書に述べる手法は，リスクを定量的に見積もる方法を用いており，機械のSRCFに
SILを割り付ける場合に一般的に用いられることを意図している。この手法を適用する場合
に特定の機械に用いるリスクパラメタ（A.2を参照）及び機械特有の危険源に関しては，
SRECSによるリスク低減にかかわる関係者との合意を得ることが望ましい。
注記2 多くの個別機械の規格（例えば，CENのC規格）において，機械制御システムの安全関連部
のカテゴリをJIS B 9705-1に従って選定するためのリスク見積りが実施されている。
簡単化のために，次に示すSILとカテゴリとの対応関係が一般的に用いられている。カテ
ゴリとSILとのさらに包括的なマッピングについては，検討中である。
要求カテゴリ1
要求SIL 1
要求カテゴリ2
要求カテゴリ3
要求SIL 2
要求カテゴリ4
要求SIL 3
各危険源に対して，SRECSが実行するべき各SRCFに対して，別々に安全インテグリティ要求を決定す
ることが望ましい。
図A.1は，SRECS機能の要求SILを見積もるために実施する特定危険源のリスクアセスメントの実務的
方法の一例である。この方法論は，SRECSの安全機能によって低減するべきリスクごとに実施することが
望ましい。図A.1は，この附属書の説明文と関連して用いることが望ましい。
59
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図A.1−SIL割付け作業の流れ
リスク見積りは，反復的作業である。1回以上繰り返して実施する必要がある。
図A.1は，リスク見積りのフィードバックのループを示している。反復が必要な理由は，SRCFを実行
する特定の保護方策を導入すると，それがリスクパラメタに影響する可能性があるからである（例えば，
保護用ライトカーテンを用いると，その保護効果を信じて人がより頻繁に危険源にアクセスするようにな
るなど。）。この場合，ライトカーテンが故障すると，オペレータはライトカーテンを導入する前より大き
なリスクにさらされるであろう。それゆえ，反復過程は同じ方法で繰り返すことが望ましいが，リスクパ
ラメタは，適宜変更する必要がある。
図A.1の反復過程の最後に推定されたSILが，SRCFに必要なSILである。
A.2 リスク見積り及びSIL割付け
A.2.1 危険源の同定
予見可能な誤使用による危険源も含め，SRCFによってリスク低減するべき危険源を同定し，表A.5の
危険源の欄にリストする。
A2.2
リスク見積り
SRCFの導入によって
リスクファクタが変
化するか？
SILの割付け
はしない
SRCFにSIL
割付け
No
Yes
Yes
No
リスクアセスメント
SRCFを用いてリス
ク低減をするか？
SIL割付けのための
リスク見積り
60
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図A.2に示すように，危険源ごとに，次の項目からリスクパラメタを決定し，リスク見積りを実施する。
− 危害のひどさ：Se
− その危害の発生確率：次の項目の関数として，
− 危険源に人が暴露する頻度及び継続時間：Fr
− 危険事象の発生確率：Pr
− 危害を回避又は限定できる可能性：Av
図A.2−リスク見積りに用いるパラメタ
表A.5に記入する推定値は，通常は，SRCFに対する最悪ケースに基づくことが望ましい。しかしなが
ら，例えば，回復不可能な傷害が起こり得るが，回復可能な傷害より十分低い確率である場合は，各傷害
のひどさのレベルを表の別々の行に記入することが望ましい。各行に対して異なるSRCFを用いるケース
が多いであろう。一つのSRCFで複数の行のリスクを低減する場合は，最も高い目標SILを用いることが
望ましい。
A.2.3 危害のひどさ（Se）
傷害又は健康障害のひどさレベルは，回復可能な傷害，回復不可能な傷害及び死亡という概念を尺度に
して見積もることができる。傷害の程度をベースにした表A.1から，傷害のひどさの適切な値を選択する。
4： 致命的又は回復不可能な重大傷害を意味する。もし治ったとしても，以前の仕事を続けることは
非常に難しい。
3： 重傷又は回復不可能な傷害を意味する。治った後に以前の仕事を続けることが可能である。手足
骨折のような回復可能ではあるが重い傷害を含めてもよい。
2： 医師の手当てを必要とする回復可能な傷害（ひどい裂傷，突き刺し，ひどい打撲傷など）を意味
する。
1： 応急処置で対処できる軽い傷害（すり傷，打撲傷など）を意味する。
表A.1の危害のひどさレベルの欄から適切な行を選択して，対応する番号を表A.5のSe欄に記入する。
表A.1−危害のひどさ（Se）の分類
傷害の程度
危害のひどさレベル（Se）
回復不可能：死亡，目又は腕の喪失
4
回復不可能：手足骨折，指の喪失
3
回復可能：医師の手当てを必要
2
回復可能：応急処置を必要
1
同定され
た危険源
によるリ
スク
起こり得る
危害のひど
さ：Se
（A2.3）
暴露の頻度及び継続時間：Fr
（A2.4.1）
危険事象の発生確率：Pr
（A2.4.2）
危害を回避又は限定できる確率：Av
（A2.4.3）
=
及び
その危害
が発生す
る確率
（A2.4）
（A.2.3）
（A.2.4）
（A.2.4.1）
（A.2.4.2）
（A.2.4.3）
61
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
A.2.4 危害の発生確率
危害の発生確率の3個のパラメタ（Fr，Pr及びAv）は，互いに独立に推測することが望ましい。SILの
割付けが不足側に傾かないように，各パラメタに対し最悪ケースの仮定をすることが望ましい。一般的に，
危害の発生確率を予測するときに適切な考察ができるように，タスクベースで分析することを推奨する。
A.2.4.1 暴露の頻度及び継続時間
暴露のレベル（頻度，継続時間）を決定するに当たって，次の事項を検討する。
− すべての運転モード（例えば，正規運転，保全）に基づいて，危険区域へのアクセスの必要性。及び，
− アクセスの性質（例えば，材料の手供給，設定など）。
暴露の平均間隔，すなわち，アクセスの平均頻度を見積もることが可能であることが望ましい。
また，暴露の継続時間を推定すること，例えば10分より長いかどうか，可能であることが望ましい。
継続時間が10分に満たない場合は，暴露のレベル値を1段下げてよい。ただし，暴露の頻度（間隔）が
1時間以下には適用しない。暴露の頻度（間隔）が1時間以下の場合は，継続時間がどんなに短くても，
暴露のレベルを下げてはならない。
注記 継続時間は，SRCFの保護の下で実行する活動と関係がある。電源断路及びエネルギー消費に
関するJIS B 9960-1及びJIS B 9714の要求事項を，主要な介入に対して適用することが望まし
い。
このファクタは，SRCFの故障に関する考察は含まない。
表A.2の暴露の頻度及び継続時間（Fr）から適切な値を選び，対応する数字を表A.5のFr欄に記入する。
表A.2−暴露レベル（Fr）の分類
暴露の頻度及び暴露継続時間から決まる暴露レベル（Fr）
暴露の頻度（間隔）
継続時間＞10分の場合の暴露レベル値
1時間以下
5
1時間超， 1日以下
5
1日超 2週間以下
4
2週間超 1年以下
3
1年超
2
A.2.4.2 危険事象の発生確率
危害の発生確率は，他のパラメタFr，Avとは独立に見積もることが望ましい。必要なSILよりも小さ
いSILを割り付けることのないように，各パラメタは最悪ケースを仮定することが望ましい。低すぎるSIL
割付けを防ぐために，危害の発生確率を推定するときに適切な考察ができるように，タスクベースで分析
することを強く推奨する。
パラメタFrは，次のことを考慮して見積もることができる。
a) 異なる運転モード（正規運転，保全，不具合探求など）における，危険源に関連する機械部分の動き
の予測可能性：
このことは，制御システム，特に予期しない起動に関して注意深い考察を必要とする。SRECSの保
護効果を勘定に入れてはならない。なぜなら，SRECSが故障したときにさらされるリスクを見積もる
必要があるからである。一般的に，機械又は処理する材料が予測できない動きをする傾向があるかど
うかを考察する必要がある。
機械の動きは予測できるもの，できないもの，多岐にわたるが，予期しない事象を軽視してはなら
62
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ない。
注記1 予測可能性は，機械の複雑度に関係することが多い。
b) 危険源に関連する機械部分への介入に関して，規定又は予見できる人の行動特性。これには次のこと
が関係する。
− ストレス（時間の制約，作業負荷，損傷の知覚限界などによる）。
− 危険な兆候への注意不足（スキル，訓練，経験，機械及び工程の複雑さなどに影響される。）。
これらの属性は，通常，SRECS設計者の直接影響下にある訳ではないが，タスク分析によって，す
べての状況に人の注意が働くことを合理的に仮定できないような活動（予期しない結果を含めて）が
見えるようになる。
通常の生産上の制約及び最悪ケースを反映するために，危険事象の発生確率の指標は，“とても高い”
（5）を選択することが望ましい。低い指標値を用いるときは，それを裏付ける理由（例えば，よく定
義された使用法，使用者の高い専門知識など）が必要である。
注記2 使用者に必要な又は期待するスキル，知識などは，すべて使用上の情報に記述することが
望ましい。
表A.3から危険事象発生確率（Pr）を選択し，該当する数字を表A.5のPr欄に記入する。
表A.3−発生確率（Pr）の分類
発生確率
発生確率の指標（Pr）
とても高い
5
起こりやすい
4
時々起こる
3
まれには起こる
2
無視できる
1
A.2.4.3 危害を回避又は限定できる確率（Av）
このパラメタは，危険源による危害を回避又は限定できるかというような，機械の設計及び意図する使
用法の側面を考慮に入れて，見積もることができる。
これらの側面には，例えば，次のことがある。
− 突然の，高速又は低速の危険事象の現れ。
− 危険から逃れるための空間の有無。
− 構成品又はシステムの性質。
例えば，ナイフは通常，鋭い。乳製品工場のパイプは通常，熱い。電気はその性質上，通常，危険
であるが見ることができない。
− 危険源（例えば，電気の危険）を認識できる可能性。
例えば，電気導体に電圧がかかっているか否かは目視では分からない。これを確認するためには測
定器を必要とする。騒音の大きい環境では，機械が始動する音が聞こえないことがある。
表A.4から危害を回避又は限定できる確率（Av）を選択し，該当する数字を表A.5のAv欄に記入する。
63
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表A.4−危害を回避又は限定できる確率（Av）の分類
危害を回避又は限定できる確率（Av）
不可能
5
まれには可能
3
かなり可能
1
A.2.5 予想危害のクラス（Cl）
各危険源の該当する危害のひどさのレベル（Se）に対して，Fr，Pr，及びAvの欄からポイントを合計し
て，その値を表A.5のCl欄に記入する。
表A.5−予想危害のクラス（Cl）を決定するために用いるパラメタ
一連番号
危険源
Se
Fr
Pr
Av
Cl
1
2
3
4
A.2.6 SIL割付け
表A.6を用いる。ひどさ（Se）の行が該当するClの列と交差するところを見て，リスク低減が必要かど
うかを判断する。濃い灰色部分はSRCFに目標として割り付けるべきSILを示す。薄い灰色部分は，SRECS
以外の方策（OM）を推奨することを示す。
表A.6−SIL割付けマトリクス
危害のひどさ
（Se）
クラス（Cl）
3〜4
5〜7
8〜10
11〜13
14〜15
4
SIL2
SIL2
SIL2
SIL3
SIL3
3
（OM）
SIL1
SIL2
SIL3
2
（OM）
SIL1
SIL2
1
（OM）
SIL1
例 ある危険源に対して，Se：3，Fr：4，Pr：5，Av：5と推定した。したがって，
Cl = Fr + Pr + Av = 4 + 5 +5 = 14
表A.6において，この危険源を低減するために用いるSRCFに割り付けるべきSILは，SIL 3で
ある。
図A.3は，この附属書を用いてSILの割付けを行った結果を記録するための文書化の例である。
64
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図A.3−SIL割付けに用いる見積表の例
リスクアセスメント及び安全方策
文書番号
構成番号
□初期リスクアセスメント
□中間リスクアセスメント
□フォローアップリスクアセスメント
対象製品：
作成者：
日付：
濃い灰色部分：安全方策必要
薄い灰色部分：安全方策推奨
危害のひどさ
クラス Cl
危害の頻度，継
続時間 Fr
危険事象
の発生確
率 Pr
回避の
可能性
Av
状態
Se
3〜4
5〜7
8〜10
11〜13
14〜15
致死，目又は
腕の喪失
4
SIL2
SIL2
SIL2
SIL3
SIL3
≦1時間
5
頻繁：5
回復不可能
指の喪失
3
(OM)
SIL1
SIL2
SIL3
＞1時間
≦1日
5
かなり：4
回復可能
医師の手当
2
(OM)
SIL1
SIL2
＞1日
≦2週
4
時々：3
不可
能：5
回復可能
応急処置
1
(OM)
SIL1
＞2週
≦1年
3
まれに：2
可能：3
＞1年
2
無視：1
可能性
有：1
一連番号
危険源番号
危険源
Se
Fr
Pr
Av
Cl
安全方策
SIL
コメント
65
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書B
（参考）
SRECS設計の例
序文
この附属書は，参考情報を提供するものであって，要求事項を規定するものではない。
B.1
一般事項
この規格で用いるSRECS設計の構造化手法では，SRCFに対する機能及びインテグリティ要求事項を，
複数のサブ機能に分解する。この過程は，IEC 61508規格群が規定する機能安全の技術的枠組を機械産業
部門内で実現するために用いる。図B.1は，SRECSの設計を機械と統合する段階で用いる重要な用語を説
明している。
この設計法を用いると，検証及び妥当性確認の過程によって，SRECSが箇条5のSRSを満たすことを
確認することができる。
次に示すSRECS設計例は，箇条6に規定する機能分解の原則及び指定のSRCFの実現法を明確に説明す
ることを意図している。この例は簡単化しており，現実の用例では必要となるかもしれない追加方策，例
えば，ホールド・ツゥ・ラン装置などは考慮していない。
図B.1−機能分解に用いる用語の図解
図B.1に示す用語は，一般に，設計過程を次の重要な二つの段階に区別することを意図している。
− SRECS設計段階 機械の設計者又は制御システムのインテグレータが実施する。
− サブシステム（及びサブシステム要素）設計段階 電気装置及び制御装置（例えば，コンタクタ，イ
ンタロックスイッチ，PLCなど）の供給者，及び機械設計者又は制御システムインテグレータが実施
する。
論理装置
入力
SRECS（3.2.4参照）
サブシステム（3.2.5参照）
サブシステム要素（3.2.6参照）
出力
66
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
B.2
SRECS設計の例
図B.2−例題の機械
この規格が用いる方法論では，SRCF要求仕様の決定及びそれらの機能を実行するSRECSの設計に対し
て，トップダウン式の構造化手法を用いる。
ステップ1： SRECSのSRSを決定する（箇条5参照）。
SRECS安全要求事項仕様決定段階で，次の情報を得る。
図B.3−SRCF要求仕様の作成
SRCFの要求仕様
（機能及びインテグリティの
要求）
SRCFの例
機能要求：ガードドアが開いているときは，軸の回
転速度は規定値を超えてはならない。
インテグリティ要求：SIL 2
67
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ステップ2： SRECSの設計及び開発（6.6.2参照）。
ステップ2.1： SRSに規定されたSRCFを機能ブロックの構造に分解する。
図B.4−機能ブロック構造へのSRCF分解
SRCFの要求仕様作成
（機能及びインテグリティ）
SRCFの例
機能要求：ガードドアが開いているときは，軸の回
転速度は規定値を超えてはならない。
インテグリティ要求：SIL 2
次のセンサを用意する。
− ガードドアの位置センサ
− 回転軸スピードセンサ
センサ出力をロジックソルバで処理する。
− ドア開放又は回転速度過大時にモータを外す信号
を出す。
− ロジックソルバの信号に従いモータ電源をスイッ
チオフにする。
機能ブロックに要求機能を割り付ける
SRECS概念設計
（機能要求及びインテグリティ要求
SIL 2に対して）
68
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ステップ2.2： 機能ブロックの構造は，SRECSアーキテクチャの初期概念である。各機能ブロックに対
する安全要求事項は，対応するSRCFのSRSから導く。
各機能ブロックを実現するサブシステム要素は，SRCFに割り付けたSILと少なくとも同じSILを実現
しなければならない。図B.5において，これはSIL 2と表記されている（FB1のSILCLを2としているな
ど）。
図B.5−SRECSアーキテクチャの初期概念
モータ電源ス
イッチング
FB4
SILCL 2
機能ブロック（FB）は，
安全関連機能のトップ
レベルの分解要素であ
って，いずれのFBの
故障も安全関連機能の
故障に帰結する。
入力
ロジックソルビング
アクチュエーション
機能ブロックに割り付けた機能及びインテグリティ要求
機能及びインテグリティの要求を，サブシステムに割り付ける。
回転軸スピー
ドセンシング
FB2 SILCL 2
ガード位置
センシング
FB1 SILCL 2
ロジックソ
ルビング
FB3
SILCL 2
69
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ステップ3： 各機能ブロックをSRECSアーキテクチャの中のサブシステムに割り当てる。
各サブシステムは，サブシステム要素で構成する。必要なら，フォールトを検出して適切なフォールト
反応（6.2を参照）を起こすための診断機能も含める。
SRECSアーキテクチャは，そのサブシステム及びそれらの相互関係によって表現することが望ましい。
この例では，SRECS及びそのサブシステムアーキテクチャの実現法には多くの選択肢がある。
例1（図B.6）： この例では，診断機能（D）は，各サブシステムの中に組み込まれる。
図B.6−診断機能をSS1〜SS4に内蔵するSRECSアーキテクチャ
SS1 SILCL2
D
スピードセンサ
SSE 2.1
スピードセンサ
SSE 2.2
SS2 SILCL2
D
コンタクタ
SSE 4.1
コンタクタ
SSE 4.2
サブシステム（SS）：
機能ブロックを実現するトップレベ
ルのアーキテクチャであって，いず
れのサブシステムが故障しても
SRECSの故障に帰結する。
サブシステム要素（SSE）：
サブシステムに割り付けられた機能
ブロック要素を実現するもの。
診断機能（D）：
安全関連制御機能から分離した機能
であって，次によって実現する。
− サブシステム内部
− SRECS内の他のサブシステム
− SRECS外部のサブシステム
割り付けた機能及びインテグリティ要求
SS3
SILCL2
SS4 SILCL 2
インタロックス
イッチ
SSE 1.1
インタロックス
イッチ
SSE 1.2
D
IEC
61508
規格群
による
PLC
D
70
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
例2（図B.7）：この例では，診断機能は，IEC 61508規格群の関連要求を満足するSS3（PLC）の中に組み
込む。
図B.7−診断機能をSS3に内蔵するSRECSアーキテクチャ
スピードセンサ
SSE 2.2
SS2 SILCL 2
IEC 61508規格群によるPLC
サブシステム（SS）：
機能ブロックを実現するト
ップレベルのアーキテクチ
ャであって，いずれのサブ
システムが故障しても
SRECSの故障に帰結する。
サブシステム要素（SSE）：
サブシステムに割り付けら
れた機能ブロック要素を実
現するもの。
診断機能（D）：
安全関連制御機能から分離
した機能であって，次によ
って実現する。
− サブシステム内部
− SRECS内の他のサブシ
ステム
割り付けた機能及びインテグリティ要求
SS3 SILCL 2
SS4 SILCL 2
インタロックスイ
ッチ SSE 1.1
インタロックスイ
ッチ SSE1.2
SS1 SILCL 2
D
D
D
スピードセンサ
SSE 2.1
コンタクタ
SSE 4.1
コンタクタ
SSE 4.2
71
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ステップ4：SRECSが達成するSILの推定（6.6.3参照）
SRECSに付与できるSILは，各サブシステムのSILCLのうちの最も低い値以下でなければならない。
SRECSのPFHDSRECSは，SRCFの遂行にかかわるすべてのサブシステムのPFHD（PFHD1〜PFHDn）の和で
あり，該当する場合は，デジタルデータコミュニケーションの危険側伝送誤り（PTE）を含めなければなら
ない。すなわち，
PFHDSRECS＝ PFHD1 ＋･････ ＋ PFHDn ＋ PTE
この例では，SRCFの目標故障率はSIL 2である。SIL 2は，表3（5.2.4.2参照）から，PFHDが10−6＞PFHD
≧10−7の範囲にあることである。各サブシステムのPFHDを図B.8に示すように仮定すると，すべてのサ
ブシステムのPFHDの合計は6×10−7と見積もることができ，SIL 2の条件を満たしている。したがって，
割り当てたSRCFをSIL 2のインテグリティで実行するためのすべての要求事項を満足するSRECS設計で
あることが示されたことになる。
図B.8−SRECSのPFHD の見積り
PFHDSRECS = (1×10−7)＋(2×10−7)＋(1×10−7)＋(2×10−7)
= 6×10−7
サブシステム1
ガードインタロ
ックスイッチ
PFHD =1×10−7
サブシステム2
スピードセンサ
PFHD =2×10−7
サブシステム3
PLC
（IEC 61508規
格群）
PFHD =1×10−7
サブシステム4
コンタクタ
PFHD =2×10−7
72
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書C
（参考）
組込みソフトウェアの設計及び開発指針
序文
この附属書は，参考情報を提供するものであって，要求事項を規定するものではない。
注記 この附属書は，IEC 61508-3の要求事項を満足するために必要な基本的な手法を示す。更なる
方策をしないで，この附属書だけによってIEC 61508-3への適合性が得られる訳ではない。
C.1 一般事項
この附属書は，SRECSのSRCFを実現する組込みソフトウェアの開発者及び設計者を支援することを意
図している。
ここに述べることの主な目的は，組込みソフトウェアの欠陥，及びシステムを危険側故障に導くような
予期しないソフトウェアの動きを防止することである。
これらの目的を満たすために，次の点に注意を払っている。
− SRECSのソフトウェア要素が，品質及び安全性を確保するために必要な主な特性（ソフトウェア要素
の指針）を記述する。
− ソフトウェア開発にかかわる技術活動及び技法を確立する。これらは，この種のソフトウェアを開発
する過程で設計者の手引きとして用いることができる（ソフトウェア開発過程の指針）。
− ソフトウェア評価のための基準となる枠組。これは，ソフトウェアの設計者及び／又は評価者が，ソ
フトウェア要素がSRECS又はSRECSサブシステムの安全要求を満たすかどうかを判断する助けにな
る。
この附属書は，組込みソフトウェア用のマイクロプロセッサに適用できるIEC 61508-3とも一貫性をも
つ基本的な指針を提供する。
C.2 ソフトウェア要素の指針
C.2は，SRECS又はSRECSサブシステムの組込みソフトウェアが，十分高い品質を保ち，安全に作動
するために満たすべき指針を提供する。このようなソフトウェア要素を得るために，多くの活動，体制及
び原則を確立することが望ましい。これは，可能な限り開発サイクルの早い段階で行うことが望ましい。
C.2.1 システムアーキテクチャとのインタフェース
ソフトウェアに対するハードウェアアーキテクチャによる制約のリストを定義し，文書化することが望
ましい。設計者は，機械又はシステムの安全に影響するハードウェア及びソフトウェアの相互作用の因果
関係を識別，評価して，ソフトウェア設計段階で考慮に入れることが望ましい。
注記 制約には，プロトコル及びフォーマット，入出力の頻度，立ち上がり及び立ち下がりのエッジ
又はレベル，逆ロジックを用いる入力データなどによる制約がある。これらの制約をリストす
ることによって，開発活動の最初にこれらを考慮に入れ，ソフトウェアをハードウェアに組み
込むとき，ソフトウェアがハードウェアに適合しないリスクを減らすことができる。
C.2.2 ソフトウェアの仕様作成
ソフトウェアの仕様作成に当たっては，次の点を考慮に入れることが望ましい。
73
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 有り得るすべての許容差又はマージンを考慮して，安全機能の性能基準（精度及び正確さ）及び時間
的な制約（応答時間）を定量的に記述する。
− システムの構成又はアーキテクチャ。
− ハードウェア安全インテグリティに関する指示（ロジックソルバ，センサ，アクチュエータなど）。
− ソフトウェア安全インテグリティに関する指示。
− メモリ容量及びシステム応答時間に関連する制約。
− オペレータと装置との間のインタフェース。
− ソフトウェアの自己モニタ及びソフトウェアによるハードウェアモニタに関する指示。
− システム作動中にすべての安全機能を確認することを要求する指示［例えば，オンラインテスト，短
時間に消滅する信号（fleeting signal）の捕そく（捉）時間，スキャンレートの一致などに関する指示］。
注記1 モニタに関する指示事項には，安全性目標及び運転上の制約（連続運転の継続時間など）を
考慮に入れた，ウォッチドッグ，CPUの負荷モニタ，ソフトウェアモニタのためのフィード
バック（出力から入力へ）などがある。ハードウェアモニタに関する指示事項には，CPU及
びメモリのモニタなどの指示，並びに安全機能検証のための指示，例えば，周期的に安全装
置の正しい作動を確かめる可能性に関する指示，を含めることが望ましい。
機能の要求事項は，機能モードごとに指定することが望ましい。一つのモードから他のモードへの移行
について規定することが望ましい。
注記2 機能モードには，正式モード，及び一つ又は複数の低品位モードがある。機能モードごとに
規定する目的は，非正式モードにおける予期しない動きを避けるためにすべての場面での動
きを規定することである。
C.2.3 既存のソフトウェア
既存のソフトウェアとは，当該システムのために特に開発したものでなく，他の開発ソフトウェアと統
合するソースモジュールのことである。これらには，過去のプロジェクトの設計者が開発したソフトウェ
ア，市場で入手できるソフトウェア（例えば，計算用モジュール，データ分類アルゴリズム）などがある。
この種のソフトウェア，特に市販ソフトウェアを扱うときは，設計者は，以前（市販ソフトウェアの開
発時）の要求事項を満足するために必要であったすべての要素へ常にアクセスできる訳ではない（例えば，
どんな試験が実施されたかは設計文書を見なければ分からない。）。評価者との調整ができるだけ早い段階
で必要である。
設計者は，評価者に既存のソフトウェアを用いることを示すことが望ましい。設計者は，既存のソフト
ウェアがSRECSの他のソフトウェア要素と同等のレベルをもっていることを実証することが望ましい。
この実証は，次のいずれかによることが望ましい。
a) 既存のソフトウェアに対して，他のソフトウェアと同じ検証活動を用いる。
b) 既存のソフトウェアが類似の実行環境で類似のシステム上で良好に作動した実績を示す（例えば，コ
ンパイラ又はソフトウェアアーキテクチャのフォーマットが異なるときの結果を評価することは必要
である。）。
注記1 既存のソフトウェアを用いることを示す目的は，この種のソフトウェアが起こし得る困難
な問題について可能な限り早い段階で評価者と協議をするためである。既存ソフトウェア
のソースモジュールを新規開発ソフトウェアと統合すると，それが新規開発ソフトウェア
と同じ厳格さで開発されたものでない場合には，不安全な異常作動の原因となりかねない。
既存のソフトウェアは，他のソフトウェアに適用するものと同じ構成管理及びバージョン管理によって
74
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
識別することが望ましい。
注記2 構成管理及びバージョン管理は，すべてのソフトウェア構成品に対して，それらの出所にか
かわらず実施することが望ましい。
C.2.4 ソフトウェア設計
ソフトウェア設計の記述には，次の事項を含むことが望ましい。
− 仕様を満たすために決定した構造を定義するソフトウェアアーキテクチャ。
− ソフトウェアアーキテクチャを構成するすべてのモジュールの入出力（例えば，内部／外部のデータ
ディクショナリの形で。）。
− 割込み。
− グローバルデータ。
− 各ソフトウェアモジュール（入出力，アルゴリズム，設計特異性など）。
− 用いるモジュール又はライブラリ。
− 用いる既存ソフトウェア。
ソフトウェアは，検証及び保全を容易にするために，モジュール形式にして，論理的に記述することが
望ましい。
− 各モジュール又はモジュールグループは，できれば，仕様書の機能に対応することが望ましい。
− モジュール間のインタフェースは，可能な限り単純にすることが望ましい。
注記 正しいソフトウェアアーキテクチャの一般的な特徴は，次のように要約できる：モジュールは，
機能との密着性が高く，その環境でのインタフェースが単純である。
ソフトウェアは，次のことを満たすことが望ましい。
− グローバル変数の数及び範囲を制限する。
− メモリ中のアレイのレイアウトを管理する（アレイのオーバフローを回避するため。）。
C.2.5 コーディング
ソースコードは，次のようにあることが望ましい。
− 読める，理解できる，そして試験できる。
− ソフトウェアモジュールの設計仕様を満たす。
− コーディングマニュアルに従う。
C.3 ソフトウェア開発過程の指針
C.3.1 開発過程：ソフトウェアライフサイクル
ソフトウェアライフサイクルの指針の目的は，ソフトウェア開発，特にこの開発に含まれる異なる技術
活動を組織化することである。
ソフトウェア開発のライフサイクルは，規定し，文書化することが望ましい（例えば，ソフトウェア品
質計画において。）。ライフサイクルは，すべての技術活動及びソフトウェア開発に必要十分な段階を含む
ことが望ましい。
ライフサイクルの各段階の要求事項は，基本的技術活動ごとに分割し，次の記述を含むことが望ましい。
− 入力（文書，標準など）。
− 出力（作成した文書，分析報告など）。
− 実行する活動。
− 実行する検証（分析，試験など）。
75
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
C.3.2 文書化：文書管理
文書化は，箇条10に従って実施することが望ましい。
C.3.3 構成及びソフトウェアの変更管理
構成管理及びそのためのバージョン管理は，承認を必要とする開発では不可欠である。
実際のところ，承認は，承認するべき構成部分を識別できるときだけ有効となる。構成管理には，構成
識別活動，変更管理，参照ポイントの確立，及びソフトウェア要素の実現が含まれる。関連データ（文書，
試験記録など）も構成管理の対象に含む。プロジェクトライフサイクルを通して，構成管理の主な目的は，
次のことを提供することである。
− 実行可能な一貫性あるコード再現のために使えるように物理的に保存できるように定義，管理された
ソフトウェア構成（後日のソフトウェア製造又は変更を考慮して）。
− 変更管理のためのベース。
− すべての問題が適切に分析され，承認された変更が正しく実行されることを保証する管理手段。
変更の理由は，例えば，次のことから生じる。
− 機能の安全性低下（規定値以下になったとき）。
− 系統的フォールトの経験。
− 安全法規の制定又は改正。
− 機械又はその使用法の変更。
− 総合的な安全要求事項の変更。
− 運転及び保全作業の分析結果（性能が目標レベル以下になったとき）。
C.3.4 構成管理及び保存管理
構成管理及び変更管理の手順は，定義し，文書化することが望ましい。この手順には，少なくとも次の
ことを含むことが望ましい。
− 構成を管理するべき品目。
少なくとも，ソフトウェア仕様，ソフトウェアの初期設計及び詳細設計，ソースコードモジュール，
妥当性確認試験の計画，手順及び結果を含む。
− 識別規則（ソースモジュール，ソフトウェアバージョンなどの）。
− 変更の取扱い規則（変更要求の記録など）。
各構成品目に発生した変更，及び変更に関連する要素のバージョンは，すべて識別できるようにするこ
とが望ましい。
注記1 この要求の目的は，各品目の開発履歴の追跡を可能にすることである。いつ，なぜ，どんな
変更がなされたかを識別する。
ソフトウェア構成管理は，個別のソフトウェアバージョンを正確に識別できるようにすることが望まし
い。構成管理は，機能安全を達成するために必要なすべての品目（及びそれらのバージョン）に及ぶこと
が望ましい。
ソフトウェア構成に含まれるすべての品目は，試験する前に，又は最終ソフトウェアバージョン評価の
ために評価者から要求される前に，構成管理手順に従って管理することが望ましい。
注記2 この要求の目的は，すべての要素が正しく構成された状態でソフトウェア評価手順が実施さ
れることを保証することである。その後に行うどんな変更も，評価者が識別できるように，
ソフトウェアのバージョン変更を必要とする。
ソフトウェア及び関連データを保存する手順（バックアップ及び指定期間保存ファイルの保存法）を確
76
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
立することが望ましい。
注記3 これらのバックアップ及び指定期間保存ファイルは，その機能のライフタイム期間中ソフト
ウェアを保全，修正するために用いることができる。
C.3.5 ソフトウェア変更管理
SRECSの機能安全性に影響を与えるようなソフトウェア変更には，すべて，変更管理及び構成管理のた
めに確立された規則を適用することが望ましい。機能の安全性を損なわずに変更できるようにすることを，
開発過程の最上流の必要ポイントにおいて考慮に入れる必要がある。
注記 特に，ソフトウェアを変更するときは，文書も更新し，すべての必要な検証活動を実施するこ
とが望ましい。このことは，ソフトウェアにどんな変更をした後でも，最初の属性がすべて保
持されることを保証する。
C.4 開発ツール
開発中に用いるツール（コンパイラ，リンカ，試験など）は，ソフトウェアバージョンと関連付けた文
書（例えば，バージョン管理文書）で識別（名称，参照番号，バージョンなどを。）することが望ましい。
注記 バージョンが異なるツールを用いると結果が異なることがある。ツールを正確に識別すること
によって，バージョンが変更された場合に，そのツールを用いる過程の連続性が得られる。
C.5 複製及び納入
C.5.1 実行コード作成
ソフトウェア作成中のどんな選択，変更も記録（例えば，バージョン管理シートで）することが望まし
い。これによって，ソフトウェアがいつ，どのように生成されたかが分かる。
C.5.2 ソフトウェアのインストール及び使用
設計者が気付き又は報告を受けた，SRCFにリンクする故障は，すべて記録し，分析することが望まし
い。
注記 このことは，設計者が，報告された安全関連故障をすべて知って，適切な対策をとることを意
味する（例えば，他の使用者に警告する，ソフトウェアを変更するなど）。
C.6 ソフトウェアの検証及び妥当性確認
検証活動の目的は，開発段階で作成したソフトウェア要素が，前の段階で確立された仕様に適合し，ま
た，適用規格又は規則に適合することを示すことである。また，検証及び妥当性確認は，ソフトウェア開
発中に混入した誤りを検出し，説明する手段にもなる。
この附属書で考慮する比較的小さなソフトウェアでは，試験が主な検証活動になるが，ソフトウェア検
証は，単なる一連の試験にとどまらない。レビュー及び分析のような他の活動も，これらが試験と結び付
くか否かにかかわらず，同様に検証活動であると考えられる。ある場合には（例えば，試験するとハード
ウェア構成品の劣化を起こすために試験を実行できない場合）レビュー及び分析を試験に換えることがで
きる。
C.7 検証及び妥当性確認の一般的な指針
ソフトウェア開発中の有効とみなされる段階で，評価者が，監査又は専門的審査によってソフトウェア
の適合性評価を実行できるようにすることが望ましい。
77
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ソフトウェアライフサイクルのすべての技術的側面は，評価者による評価対象である。評価者は，すべ
ての検証報告（試験，分析など）及びソフトウェア開発中に使われたすべての技術文書を調査することを
許されることが望ましい。
注記1 評価者の介入は，後段階で行うより，仕様作成段階から行うことが望ましい。なぜなら評価
者による決定の影響を小さくできるからである。プロジェクトの資金的及び人間的側面は評
価の対象外である。
注記2 ソフトウェア開発中に実行したすべての活動の十分な証拠を提供することは，適合性評価申
請人の利益になる。
注記3 評価者が意見を具申するために必要なことは，自由に調べ，使えるようにすることが望まし
い。
ソフトウェアの適合性評価は，特定の指定されたソフトウェアバージョンに対して行う。既に評価され，
前の評価者から最終意見を受けたソフトウェアを変更するときは，前回の評価を今回の評価者に開示し，
評価者が追加の評価活動を実施し，前回意見を更新できるようにすることが望ましい。
注記4 どんな変更によってもソフトウェアの動きが変わることが有り得る。したがって，評価者に
よる評価は，対象となる正しいソフトウェアバージョンに対してだけ適用できる。
C.8 検証及び妥当性確認のためのレビュー
作成したソフトウェアが仕様書に適合することを確認するために，分析活動及びソフトウェア設計の検
証を行うことが望ましい。
注記1 この要求の目的は，ソフトウェアの仕様及び設計（予備設計及び詳細設計）が一貫している
ことを保証することである。
外部機関による（評価者による）妥当性確認レビューを，妥当性確認の最終段階に実施することが望ま
しい。
注記2 これは，ソフトウェア要素が仕様を満足するかどうかを確認するために用いることができる。
各レビュー結果は，文書化し，保管することが望ましい。文書には，レビュー過程で決定したすべての
実施項目のリスト及びレビューの結論（次の活動に進むべきかについての決定）を含むことが望ましい。
レビューで決定した実施項目は，実施状況を監視することが望ましい。
C.9 ソフトウェア試験
C.9.1 一般的な妥当性確認
最初の試験シートを書く前に，試験計画の中で試験戦略を確立することが重要である。この方針には，
採用した実施方針及び試験の目的（試験範囲，試験環境，特定の試験技法，適用する合格基準など）を示
すことが望ましい。
試験の目的は，ソフトウェアのタイプ及び固有の属性に適応するものでなければならない。これらは，
行うべき試験のタイプ（機能試験，限界試験，限界外試験，性能試験，負荷試験，外部装置故障試験，及
び構成試験）を決定するものであり，また，試験がカバーする対象範囲（機能モード試験，安全機能試験，
仕様書の各要素の試験など）を決定するものである。
新しいソフトウェアバージョンの検証には，非回帰性確認試験を含むことが望ましい。
注記 非回帰性確認試験は，ソフトウェア上の変更が予期しないソフトウェアの動きを誘発しないこ
とを確認するために使われる。
78
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
C.9.2 ソフトウェア仕様書の検証：妥当性確認試験
これらの検証の目的は，目標システム環境におけるソフトウェアに付随する誤りを検出することである。
この種の検証によって検出される誤りには，次のものがある
・ 不正確な割込み処理メカニズム。
・ 不十分な実行時間。
・ 過渡的モード（起動中，入力中，性能低下モードにおける切り換え中など）で作動中のソフトウェ
アからの不正確な応答。
・ リソースへのアクセスの競合又はメモリの組織化の問題。
・ フォールト検出のための統合化試験不能。
・ ソフトウェアとハードウェアとのインタフェース誤り。
・ スタックのオーバフロー。
妥当性確認試験は，ソフトウェアの仕様を検証するための主要な部分である。
試験範囲は，トレーサビリティマトリクス上で明示し，次のことが保証されるようにすることが望まし
い。
− 仕様書の各要素（安全のメカニズムを含めて）が，妥当性確認試験によってカバーされる。
− すべての運転モードにおけるソフトウェアのリアルタイムの動きが検証される。
さらに，妥当性確認はシステムの運転状態と同じ状態で実施することが望ましい。
注記1 これによって，実運転でソフトウェアが期待されるように反応することが保証される。これ
は，ハードウェアを破壊するような試験条件の場合（例えば，構成品の物理的なフォールト
をシミュレートできない場合）だけに当てはまる。妥当性確認が意味をもつためには，シス
テム又はサブシステムの実運転状態（すなわち，ソフトウェア及びハードウェアの最終バー
ジョンが目標システムに組み込まれた状態）で実行することが望ましい。他の試験組合せは，
試験の効率を減少させ，試験結果の分析が必要になることがある。
妥当性確認結果は，少なくとも次の内容をカバーし，妥当性確認報告書に記録することが望ましい。
− 妥当性確認を実施したソフトウェア及びシステムのバージョン。
− 実行した妥当性確認試験（入力，出力，試験手順）の記述。
− 結果を実証又は評価するために使ったツール及び設備。
− 各妥当性確認試験の合否結果。
− 妥当性確認査定。見つかった不適合部分，安全に対する影響，妥当性確認結果を採用するかどうかの
決定。
妥当性確認報告は，納入したすべてのソフトウェアバージョンに対して利用可能であるべきであって，
納入した各ソフトウェア要素の最終バージョンに対応することが望ましい。
注記2 この報告は，試験が本当に実行され，そして結果が正しかった（又は仕様との差異を説明で
きる）ということを証明するために用いることができる。また，将来のソフトウェアバージ
ョン又は他のプロジェクトのために，後日試験をやり直すときに用いることもできる。この
報告書は，納入されたバージョンが，その最終バージョンで妥当性確認されたということを
保証する。この報告書によって，既存のコード（プログラム）を変更するときにすべての妥
当性確認をやり直すことを免除できる。ある場合には，影響解析によって，部分的な妥当性
確認の実施を正当化することができる。
C.9.3 ソフトウェア設計検証：ソフトウェア統合試験
79
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
この検証は，ソフトウェアモジュールの組合せが正しいか，及びソフトウェア構成品間の相互の関係が
正しいかを検証する。次の種類の誤りを見つけるために用いることができる。
・ 変数及び常数の不正な初期化。
・ パラメタ転送誤り。
・ 不正改造されたデータ。特にグローバルデータの不正改造。
・ 事象及び作動の不正シーケンス。
ソフトウェア統合試験は，次のことを検証できることが望ましい。
− ソフトウェア実行の正しいシーケンス。
− モジュール間のデータ交換。
− 性能基準との合致。
− グローバルデータの不正改造がない。
試験範囲は，トレーサビリティマトリクス上で明示し，実施する試験が，規定された試験目的に一致す
ることを示すことが望ましい。
統合試験の結果は，少なくとも次の内容を含み，ソフトウェア統合試験報告書に記録することが望まし
い。
− 統合ソフトウェアのバージョン。
− 実施した試験（入力，出力，手順）の記述。
− 統合試験の結果及びそれらの評価。
C.9.4 詳細設計の検証：モジュール試験
モジュール試験は，ソフトウェアモジュール，及びソフトウェアモジュールと詳細設計との適合性に焦
点を当てて行う。この活動は，大きくて複雑なソフトウェア要素には不可欠であるが，ここで論じる比較
的小さなソフトウェアに対しては推奨するにとどめる。この段階の検証手順によって，次の種類の誤りを
検出できる。
− ソフトウェア仕様を満たすことができないアルゴリズム。
− 不正なループオペレーション。
− 不正な論理決定。
− 有効な入力データの組合せを正確に計算できない。
− 誤データ又は不正改造データに対する不正応答。
− アレイ境界の侵害。
− 不正な計算シーケンス。
− 不十分な精度。
− アルゴリズムの精度又は性能。
各ソフトウェアモジュールは，モジュールが詳細設計段階で規定された機能を満たすことを検証するた
めに，入力データを用いる一連の試験に付すことが望ましい。
試験範囲は，規定された試験目的と試験結果との一致を示すトレーサビリティマトリクス上に示すこと
が望ましい。
80
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書D
（参考）
電気･電子部品の故障モード
序文
この附属書は，参考情報を提供するものであって，要求事項を規定するものではない。
D.1 概要
SRECS及びSRECSサブシステムの運転環境は，少なくともJIS B 9960-1に従うことが望ましい。しか
し，多くのサブシステム（例えば，AOPD：能動的光電保護装置）には，実際にはもっと面倒な使用環境
を指定する製品規格が適用される。
表D.1は，電気･電子部品の故障モード比率の例及び出典を示す。これらの値は，他の資料に示されるも
のと異なるかもしれない。一般に，用いる故障モードデータは，構成品の実際の使用条件を反映すること
が望ましい。
注記1 表D.1は，故障モードのすべてを含むリストではない。
注記2 故障率のデータは，サブシステム製造業者から入手することが望ましい。
表D.1−電気･電子部品の故障モード比率の例
部品
故障モード
典型的な故障モード比率（％）
スイッチ
操作時に強制開離するもの。
例えば，押しボタン，非常停止装置，
ポジションスイッチ，カム作動形ス
イッチ，及びセレクタスイッチ。
接点が開かない。
20
接点が閉じない。
80
電動式ポジションスイッチ，リミッ
トスイッチ，手動スイッチなど（強
制開離式でないもの）
接点が開かない。
50
接点が閉じない。
50
リレー
コイルが非励磁のときにすべての接
点が励磁状態の位置にとどまる。
25
コイルが励磁のときにすべての接点
が非励磁状態の位置にとどまる。
25
接点が開かない。
10
接点が閉じない。
10
切換接点において3接点が同時にシ
ョート。
10
NC接点とNO接点とが同時に閉状態
になる。
10
2回路の接点間のショート及び／又は
接点とコイルとのショート。
10
81
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表D.1−電気･電子部品の故障モード比率の例（続き）
部品
故障モード
典型的な故障モード比率（％）
サーキットブレーカ，差動形サーキ
ットブレーカ，及び漏電ブレーカ
コイルが非励磁のときにすべての接
点が励磁状態の位置にとどまる。
25
コイルが励磁のときにすべての接点
が非励磁状態の位置にとどまる。
25
接点が開かない。
10
接点が閉じない。
10
切換接点において3接点が同時にシ
ョート。
10
NC接点とNO接点とが同時に閉状態
になる。
10
2回路の接点間のショート及び／又は
接点とコイルとのショート。
10
コンタクタ
コイルが非励磁のときにすべての接
点が励磁状態の位置にとどまる。
25
コイルが励磁のときにすべての接点
が非励磁状態の位置にとどまる。
25
接点が開かない。
10
接点が閉じない。
10
切換接点において3接点が同時にシ
ョート。
10
NC接点とNO接点とが同時に閉状態
になる。
10
2回路の接点間のショート及び／又は
接点とコイルとのショート。
10
ヒューズ
過電流で切れない（回路ショート）。
10
導通不良。
90
近接スイッチ
出力回路の抵抗が永久的に過小。
25
出力回路の抵抗が永久的に過大。
25
電源系の不良。
30
機械的故障によるスイッチ機能不能。 10
切換接点において3接点が同時にシ
ョート。
10
温度スイッチ
接点が閉じない。
30
接点が開かない。
10
隣接する接点とのショート。
10
切換接点において3接点が同時にシ
ョート。
10
センサの故障。
20
検出特性又は出力特性の変化。
20
圧力スイッチ
接点が閉じない。
30
接点が開かない。
10
隣接する接点とのショート。
10
切換接点において3接点が同時にシ
ョート。
10
センサの故障。
20
検出特性又は出力特性の変化。
20
82
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表D.1−電気･電子部品の故障モード比率の例（続き）
部品
故障モード
典型的な故障モード比率（％）
電磁弁
励磁しない。
5
非励磁にならない。
15
スイッチング時間の変化。
5
漏れ。
65
その他の故障モード（注記4を参照）。 10
変圧器
各巻線の断線。
70
巻線間のショート。
10
巻線内のショート。
10
変圧比の変化。
10
インダクタ
導通不良。
80
ショート。
10
インダクタンスの無秩序変化。
10
抵抗器
導通不良。
80
ショート。
10
抵抗値の無秩序変化。
10
抵抗回路網
導通不良。
70
ショート。
10
接続点間のショート。
10
抵抗値の無秩序変化。
10
ポテンショメータ
個々の導通不良。
70
すべての接続点間のショート。
10
二つの接続移点間のショート。
10
抵抗値の無秩序変化。
10
キャパシタ
導通不良。
40
ショート。
40
容量値の無秩序変化。
10
tanδの変化。
10
ディスクリート半導体
接続点の導通不良
25
二つの接続点間のショート。
25
すべての接続点間のショート。
25
特性変化。
25
プログラムできない集積回路
（すなわち，1 000のゲート以下及
び／又は24ピン以下の複雑でない
オペアンプ，シフトレジスタ，ハイ
ブリッドモジュール）
接続点の導通不良。
20
二つの接続点間のショート。
20
スタックアット（stuck at）故障。
20
出力回路の寄生振動。
20
値の変化（例えば，アナログデバイス
の入力／出力電圧）。
20
フォトカップラ
各接続点の導通不良。
30
二つの入力接続点間のショート。
30
二つの出力接続点間のショート。
30
二つの入力，出力接続点間のショー
ト。
10
プラグ，ソケット及び多極コネクタ
隣接する2ピン間のショート。
10
接続導体と露出導電性部分との間の
ショート。
10
各ピンの導通不良。
80
83
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表D.1−電気･電子部品の故障モード比率の例（続き）
部品
故障モード
典型的な故障モード比率（％）
端子ブロック
隣接する端子間のショート。
10
各端子の導通不良。
90
注記1 このデータの出典には，次のものがある。
MIL-HDBK-217F (Notice 2)： 電子機器の信頼性予測（28-02-95），部品ストレス解析
MIL-HDBK-217F (Notice 2)： 電子機器の信頼性予測（28-02-95），附属書A，部品点数信頼性予測
SN 29500 Part 7： 部品故障率，リレーの予測値，1992年4月
SN 29500 Part 11： 部品故障率，コンタクタの予測値，1990年8月
SN 29500規格群は，次の機関から入手できる。
Siemens AG, CT SR SI
Otto-Hahn-Ring 6
D-81739 Munchen
注記2 ISO 13849-2の表D.5 から採用した電気の故障モード。機械的故障モード（ある場合は）は，ISO 13849-2
の附属書A，附属書B及び附属書Cから転載した。
注記3 多くの電気･電子部品，例えば，抵抗器及びコンデンサは，設計によっては，ここに示す値とは異なる故
障モード比率を示すことがある。
注記4 電磁弁のその他の故障モードには，次のものがある。
− 切換不能（ゼロ位置又は最終位置に固定）又は不完全な切換（無秩序な中間位置に固定）。
− （入力信号なしに）自然発生的にスイッチがイニシャル位置から変化する。
− 長い期間にわたる漏れ流量の変化。
− 取付け用ねじの破壊又は折損，並びに弁の破裂又は可動構成品の破壊。
− サーボ弁及び比例弁に制御できない振舞いを起こす空圧的又は液圧的な障害。
注記5 故障モード比率に関するその他の情報源として次のものがある。
− UTE C 80-810 RDF 2000：信頼性データハンドブック−電子部品，印刷基板及び電子機器の信頼性
予測の統一モデル。
− FMD-91, RAC 1991：故障モード･メカニズムの分布。
84
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書E
（参考）
工業環境のSRECSに対して強化するJIS C 61000-6-2の
電磁イミュニティレベル
序文
この附属書は，参考情報を提供するものであって，要求事項を規定するものではない。
E.1 工業環境で使用するSRECSの性能試験用に推奨する強化イミュニティレベルを，表E.1に示す。表
E.2及び表E.3は，表E.1を補足するものであって，試験信号の推奨周波数範囲を示す。
表E.1−SRECSに適用する電磁妨害及び強化イミュニティレベル
ポート（注記1を参照）
現象
規格
追加のSRECS性能試験用の強
化イミュニティレベル
（6.4.3参照）
エンクロージャ
静電気放電（ESD）
JIS C 61000-4-2
6 kV/8 kV接触／気中放電
（注記2参照）
電磁界
JIS C 61000-4-3
20 V/m (80 MHz〜1 GHz)
6 V/m (1.4 GHz〜2 GHz)
3 V/m (2 GHz〜2.7 GHz)
（表E.2参照）
定格電源周波数の電磁界
JIS C 61000-4-8
30 A/m（注記4及び注記5参照）
交流電源
電圧ディップ及び短時間停
電
JIS C 61000-4-11
0.5周期
30 ％低減（注記5参照）
電圧変動／停電
JIS C 61000-4-11
250周期
＞95 ％低減（注記5参照）
バースト
JIS C 61000-4-4
4 kV
サージ
JIS C 61000-4-5
線間1 kV及び／又は対地2 kV
（注記6参照）
RF伝導
JIS C 61000-4-6
10 V 指定周波数で
（表E.3及び注記3参照）
直流電源（注記7を参照） バースト
JIS C 61000-4-4
4 kV
サージ
JIS C 61000-4-5
線間1 kV及び／又は対地2 kV
（注記6参照）
RF伝導
JIS C 61000-4-6
10 V 指定周波数で
（表E.3及び注記3参照）
I/O信号／制御ライン
バースト
JIS C 61000-4-4
2 kV 3 m以下のラインに対して
サージ
JIS C 61000-4-5
対地2 kV
（注記8参照）
RF伝導
JIS C 61000-4-6
10 V 与えられた周波数で
（表E.3及び注記3参照）
機能接地
バースト
JIS C 61000-4-4
2 kV
85
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表E.1−SRECSに適用する電磁妨害及び強化イミュニティレベル（続き）
注記1 ポートは，SRECS及びそのサブシステムが外部の電磁環境とインタフェースする部分である。
注記2 放電レベルは，JIS C 61000-4-2に示す環境条件に従い，規定された静電気放電防止手順に従う作業者以外
の人が触れる可能性のある部分に印加する。静電気放電防止のために適切に訓練された要員だけがアクセ
スできる部分には加えない。
注記3 移動デジタル無線機からの電磁障害を防止するために信頼できる方策を使わない限り，強化した値を一般
の移動デジタル無線機で使われる周波数の範囲で加える。個々の場合，ISM周波数を考慮に入れる必要が
ある。
注記4 磁界の影響を受ける設備にだけ適用する。
注記5 強化した値は，機能の安全のために必要でないと考えられる現象に対しては適用しない。
注記6 イミュニティを達成するために外部の保護装置を用いてもよい。
注記7 直流電源回路網に接続していない設備／システムのポート間の直流結線は，I/O信号／制御ポートとして
扱う。
注記8 長いラインに対してだけ適用する。
注記9 参考規格は，IEC 61326-3。
注記10 製品規格（例えば，JIS B 9704-1）が，機能安全の観点から，特定のEMC現象に対して異なる試験レベル
を指定する場合，それらの異なる試験レベルをSRECSサブシステムに適用する。
表E.2−無線周波電磁界に対するイミュニティ試験の推奨周波数
システム
周波数（MHz）
GSM a)
890 〜 915
GSM
1 710 〜 1 785
GSM
1 890
UMTS b)
未定
トランシーバ
未定
ISM c)
433.05 〜 434.79
ISM
83.996 〜 84.004
ISM
167.992 〜 168.008
ISM
886.000 〜 906.000
注a) GSM（Global System for Mobile Communication）は，デジタル携帯電話に使われている無線通信方式の一つ。
ヨーロッパ及びアジアを中心に100か国以上で利用されている。
b) UMTS（Universal Mobile Telecommunication System）は，ヨーロッパの第3世代移動体通信システムである。
c) Industrial, Scientific, Medicalの頭文字。EMC規格では，産業用，科学用及び医療用機器をISM装置という。
表E.3−無線周波伝導妨害に対するイミュニティ試験の推奨周波数
システム
周波数（MHz）
ISM
6.765 〜 6.795
ISM
13.553 〜 13.567
ISM
26.957 〜 27.283
ISM
40.66 〜 40.70
86
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書F
（参考）
共通原因故障係数（β）の推定法
序文
この附属書は，参考情報を提供するものであって，要求事項を規定するものではない。
F.1
一般事項
この附属書は，サブシステム設計に適用できるCCF推定の簡単な定量的手法を提供する。
F.2
方法
提案されたサブシステム設計に対して，CCFからの保護のために設計で採用した方策の有効性を評価す
る。表F.1を用いて，適用する項目を識別し，合計得点を計算する。次に表F.2を用いて，合計得点から
パーセント値としての共通原因故障係数βを決定する。
表F.1−CCF推定のための判定基準
判定項目
番号
得点
隔離及び分離
各チャネルのSRECS信号ケーブルは，すべての場所で他のチャネルから分離して
配線されているか，又は十分にシールドされているか。
1a
5
情報のエンコーディング･デコーディングが使われる場合,信号伝送誤りの検出が
十分に行われるか。
1b
10
SRECSの信号ケーブル及び電源ケーブルは，すべての場所で分離されているか，
又は十分にシールドされているか。
2
5
サブシステム要素がCCFを生じることがある場合，それらは局部的なエンクロー
ジャに収納した物理的に別個のデバイスとして用いられるか。
3
5
ダイバーシティ及び冗長性
サブシステムは，異なる電気技術方式のチャネルを用いているか。例えば，一方を
プログラム式デバイス，他方を電磁リレーにするなど。
4
8
サブシステムは，異なる原理を用いる要素を使用しているか。例えば，ガードドア
における検出器として機械式のものと磁気式のものとを併用するなど。
5
10
サブシステムは，機能の作動及び故障モードが異なる要素を使用しているか。
6
10
サブシステム要素は，間隔1分以下の診断テスト機能をもつか。
7
10
複雑性，設計，及びアプリケーション
診断テストに用いるものを除き，サブシステムのチャネル間のクロス接続は防止さ
れているか。
8
2
査定及び分析
共通原因故障の原因を見つけるために，故障モード及び影響解析の結果を調べた
か，そして共通原因故障の原因を計画的に除去したか。
9
9
フィールドでの故障を分析し，設計にフィードバックしたか。
10
9
能力及びトレーニング
サブシステム設計者は，共通原因故障の原因及び結果を理解しているか。
11
4
環境の制御
サブシステム要素は，外部の環境制御なしに，常に試験時に適用した温度，湿度，
腐食，ほこり，振動などの範囲内で作動するか。
12
9
87
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表F.1−CCF推定のための判定基準（続き）
判定項目
番号
得点
サブシステムは，附属書Eで指定した限界までの（限度値を含む）電磁妨害から
の過酷な影響に耐えるか。
13
9
注記 選択的項目（番号1a及び1b）は，CCF回避への寄与が最も大きな項目の得点を採用することを意図して
いる。
表F.1を用いて，サブシステム設計に影響を与えると考えられる項目の得点を合計し，実現する設計の
総合得点を得る。特定の設計方策（例えば，シールドケーブルでなくフォトカップラを使用）によって同
等のCCF回避の寄与を得ることを示せるときは，その手段によって同等のCCF回避が得られるものとし
て得点を付与してよい。
この合計得点から，表F.2を用いて共通原因故障係数（β）を決定する。
表F.2−CCF係数（β）の推定
合計得点
共通原因故障係数（β）
＜35
10 ％ (0.1)
35− 65
5 ％ (0.05)
65− 85
2 ％ (0.02)
85−100
1 ％ (0.01)
得られたβの値は，6.7.8.1に規定されるPFHDの計算に用いる。
88
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書JA
（参考）
この規格を理解するための基礎情報
序文
この附属書は，参考情報を提供するものであって，要求事項を規定するものではない。
JA.1 SRECSの概念
この規格でいう“機能安全（functional safety）”とは，機械の安全の一部であり，機械安全全体のうち，
本質安全では達成できない部分を安全関連制御機能（SRCF）に依存して達成する安全のことである。
安全関連電気制御システム（SRECS）は，安全機能だけを実行する制御システム，並びに安全機能及び
安全以外の機能の両方を実行するシステムの総称である（図JA.1参照）。
図JA.1−SRECSの範囲（1）
広い意味の電気制御システムは，電子制御システム及びプログラマブル電子制御システムを含む。広い
意味の電子制御システムは，プログラマブル電子制御システムを含む。プログラマブル電子制御システム
とは，コンピュータを用いる制御システムのことである（図JA.2参照）。
図JA.2−SRECSの範囲（2）
JA.2 安全性及び信頼性
機能安全は，安全制御機能が正しく作動することによって達成されるので，安全制御機能が正しく作動
する確からしさ（度合）のことを“安全制御機能の安全性（safety）”，“安全制御機能の安全インテグリテ
ィ（safety integrity）”などという。
電気制御システム
電子制御システム
プログラマブル電子制御システム
安全機能だけを
実行する電気制
御システム
安全機能及び安全以外の機能
を実行する（2種の機能が独立
していない）電気制御システム
SRECS：安全関連電気制御システム
89
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
“安全制御機能の安全性”は，“安全制御機能の信頼性”に依存する部分が大きいが，安全性は信頼性と
同じではない。“制御機能の信頼性”は，主に制御システムのランダムハードウェア故障確率を問題にする
が，安全性の高い制御システムは，ランダムハードウェア故障確率を下げるだけでは達成されない。“制御
システムの安全性”には，ランダムハードウェア故障確率が低いことに加え，系統的故障（JA.3参照）が
少ないことが必要であり，さらに，制御システムが故障しても安全が失われないこと（フォールトトレラ
ンス）が重要である。この観点からは“制御機能の安全性”の方が“制御機能の信頼性”より広い概念で
ある。
一方，“制御機能の信頼性”は，危険を招く故障（この規格でいう危険側故障）だけでなく，生産機能を
阻害する故障（この規格でいう安全側故障を含む故障）も問題にする。これに対し，“制御機能の安全性”
は，生産機能の阻害は問題にせず，もっぱら危険を招く故障（危険側故障）だけを問題にする。この観点
からは，“制御機能の安全性”は，“制御機能の信頼性”より狭い概念である。
JA.3 安全インテグリティの概念
この規格は，制御システムの安全性を表す指標として安全インテグリティレベル（SIL）を用いる。この
規格は，制御システムの安全インテグリティレベルを，SIL 1〜SIL 3 に分類する。制御システムの安全イ
ンテグリティは，本来，特定の安全機能に対して定義するものであって，システムの安全インテグリティ
を論じる場合は，そのシステムが実行する安全機能を定義しないと意味がない。
制御システムの安全インテグリティは，ハードウェア安全インテグリティ及びソフトウェア安全インテ
グリティに分類できる。ハードウェア安全インテグリティは，これをさらに確率的安全インテグリティ及
び系統的（確定論的）安全インテグリティに分類できる。
安全インテグリティを構成する確率的要素及び系統的要素の例を，表JA.1に示す。フォールトトレラン
ス性，SFF，DC，共通原因故障は，これら自体には確率的要素はないが，システムのPFHDに影響するの
で，この附属書では，これらを確率的要素の範ちゅうに入れた。
表JA.1−制御機能（システム）の安全インテグリティ要素の例
確率的要素
系統的要素（3.2.22で定義）
（数値化不可能）
ハードウェア安全イ
ンテグリティ
（3.2.20で定義）
（6.6.3ほかで規定）
・ PFHD（6.7.8ほかで規定）
・ 部品の偶発故障率
・ アーキテクチャ（6.7.6で規定）
・ フォールトトレランス性
（3.2.31で定義。6.7.6ほかで規定）
・ SFF
（3.2.42で定義。6.7.7ほかで規定）
・ DC
（3.2.38で定義。6.7.8の計算に使用）
・ 共通原因故障
（3.2.43で定義。6.7.8の計算に使用）
・ 設計ミス
（6.4.1，6.4.2ほかで規定）
・ 製造ミス
（6.4.1，6.4.2ほかで規定）
・ 電磁イミュニティ
（6.4.3で規定）
・ フォールトの回避･抑制
（6.7.9ほかで規定）
ソフトウェア安全イ
ンテグリティ
（3.2.21で定義）
なし
・ ソフトウェアの設計･製造ミ
ス（6.10，6.11で規定）
・ アルゴリズムミス
・ プログラムミス
・ コンパイルミス
90
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
JA.4 この規格とIEC 61508（JIS C 0508）との関係
この規格は，IEC 61508規格群を基礎にしているが，IEC 61508規格群とは枠組が少し異なる。IEC 61508
規格群は，原子力プラント，化学プラントのような，極めて高い安全性を必要とする施設の安全制御シス
テムまでカバーしている。機械部門の安全性要求は，プラントなどの場合とは異なるので，機械の安全制
御システムには，IEC 61508規格群の規定のすべてが必要という訳ではない。この規格とIEC 61508規格
群との枠組の主な相違は，表JA.2による。
表JA.2−この規格とIEC 61508規格群との比較
比較事項
IEC 61508規格群
この規格
SILの範囲
SIL 1〜SIL 4を規定。
SIL 1〜SIL 3を規定。
（機械部門では，SIL 4の安全性は
要求されないと想定している。）
安全機能の作動要
求モード
次の二つを規定。
・ 低頻度作動要求モード
・ 高頻度作動要求又は連続モー
ド
高頻度作動要求及び連続モードだ
けを規定。
［機械部門では，通常，安全機能の
作動は高頻度（1年に1回以上）で
あると想定している。］
この規格は，IEC 61508規格群を引用している。ただし，箇条3の用語及び定義の出典としてはJIS C
0508-4を引用している。その理由は，引用する定義はIEC 61508-4及びJIS C 0508-4の間で実質的に等し
く，用語定義では，特に日本語表現の由来を示すことに意義があるからである。
JA.5 この規格とJIS B 9705-1（ISO 13849-1）との関係
JIS B 9705-1:2000（ISO 13849-1:1999対応）は，制御機能の安全性をカテゴリ（B，1，2，3及び4）で
表現している。故障は起こるものであるという前提で，制御機能の安全性（カテゴリ）を，主にフォール
トトレランス性（故障しても安全が保たれる性質）で分類している。
しかし，改正されたISO 13849-1:2006は，故障しないことの要求も強く反映する規格になった。PFHD
の要求を追加し，PFHDの値によってPLを定義している。PLには，構成チャネルの危険側平均故障時間
MTTFd，DCなどの要素も関係するが，PLは，究極的にシステムのPFHD によって表JA.3のように定義
される。
表JA.3−ISO 13849-1:2006におけるPLとPFHDとの対応
PL (performance level)
PFHD
PLに相当するSIL（参考）
PL a
10−5 ≦ PFHD ＜ 10−4
なし
PL b
3×10−6 ≦ PFHD ＜ 10−5
SIL 1（10−6 ≦ PFHD ＜ 10−5）
PL c
10−6 ≦ PFHD ＜ 3×10−6
PL d
10−7 ≦ PFHD ＜ 10−6
SIL 2（10−7 ≦ PFHD ＜ 10−6）
PL e
10−8 ≦ PFHD ＜ 10−7
SIL 3（10−8 ≦ PFHD ＜ 10−7）
JA.6 安全側故障比率
この規格では，安全側故障比率（SFF）は，SIL付与限界を制約する要素の一つである（表5参照）。
システム又はサブシステムのハードウェア安全インテグリティを高めるために，SFFを高めることが重
91
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
要である。そのために，この規格は，次の二つの設計技法を重視している。
a) 部品そのもののSFFを高める（部品故障の影響が安全側に作用するように設計する。）。
b) 危険側故障を検出し，検出したらシステムを安全側へ導く制御（フォールト反応）を行う。
a) の説明
部品故障には，その故障がシステムの安全機能喪失を導くもの（危険側故障）と，そうでないもの（安
全側故障）とがある。システムの安全インテグリティを高めるためには，要素が故障してもシステムが安
全に保たれる比率を高めることが有効である。この規格では，すべての故障が起こる率（分母）と安全側
故障数が起こる率（分子）との比をSFF（safe failure fraction: SFF）と定義する。SFFを高めることによっ
てサブシステムのPFHDを小さくすることができる（3.2.42参照）。
b) の説明
SFFを高めるために，部品そのものの故障が安全側故障となる比率を高めることが重要であるが，故障
を検出して，潜在的な危険側故障がサブシステムの危険側故障として顕在化しないように制御することも
大きな効果をもつ。危険側故障の発生を検出して，危険事象が起こる前に安全制御（例えば，運転停止）
を行うことができれば，検出した故障は，サブシステムレベルでは安全側故障とみなすことができる。
このための故障検出は，診断テストによって行われる。この規格では，部品の危険側故障を診断によっ
て検出できる割合を診断率（diagnostic coverage: DC）と定義し，サブシステムのPFHDを計算するときに
DCを勘定に入れる。診断によって検出できる危険側故障は，サブシステムレベルでは，実質的に安全側
故障とみなすことができるので，DCはSFFの一部となる。診断機能をもつ1チャネルシステムのSFFは，
次の式で与えられる。
SFF = ( λS + λD × DC ) / ( λS + λD )
= ( λS + λD × DC ) / λ
ここに，
λS： 安全側故障率
λD： 危険側故障率
λ： すべて（安全側及び危険側）の故障の率
DC： 診断率
プルーフテストは，診断で見逃した危険側故障を発見して修復するためのテストであって，SFFを高め
るものではない。
JA.7 フォールトトレランス
この規格では，フォールトトレランスも，サブシステムのSIL付与限界を制約する要素の一つである（表
5参照）。フォールトトレランスについては，JB.9に詳しい説明がある。
診断によって危険側故障を検出して，危険事象が起こる前に運転停止制御できることは，フォールトト
レランスをもつということとは異なる。
フォールトトレランスは，一般に冗長系によって実現できる。
92
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書JB
（参考）
PFHDの計算式の考察など
序文
この附属書は，サブシステムの危険側故障に関する事項を理解するための参考文書であって，要求事項
を規定するものではない。
JB.1 附属書JBの目的
この附属書の目的は，次のとおりである。
a) 6.7.8.2のPFHD 1) 計算式(A)，(B)，(C)，(D1)及び(D2)を検証する（JB.3〜JB.6）。
b) 自己診断とPFHDとの関係を確認する（JB.5〜JB.6）。
c) プルーフテストとPFHDとの関係を確認する（JB.4及びJB.6）。
d) 離散的作動要求モードにおけるPFHDの意味を考察する（JB.7）。
e) PFD 2) の計算式を示す（JB.8）。
f)
フォールトトレランスの概念を確認する（JB.9）。
PFHDは，連続モード 3) におけるリスク評価に用いることができる。
PFDは，離散的作動要求モード4) におけるリスク評価に用いることができる。
なお，PFHD及びPFDの計算法は，この附属書が示す方法だけに限るものではない。アーキテクチャ及
び前提条件が異なれば計算法も異なる。この附属書は，特定のアーキテクチャ（6.7.8.2）に対する特定の
前提条件下での計算法を示しているが，異なるアーキテクチャ及び異なる条件における計算のためにも参
考になると考える。
注1) PFHD (Probability of Dangerous Failure per Hour)は，SRECS又はそのサブシステムが，1時間の間
に危険側故障を起こす平均確率である。連続モードにおいて，サブシステムの危険側故障が直
ちに危険事象の発生を招くとすれば，PFHD は危険事象が1時間の間に発生する確率（無次元）
になる。
この規格では，PFHDと λDとの関係を，次のように定義している。
PFHD = λD × 1時間
2) PFD (Probability of Failure on Demand)は，離散的作動要求モードにおいて，作動要求があったと
きに安全制御機能が作動しない確率（無次元）である。IEC 61508規格群では，低頻度作動要
求モードのSILをPFDで定義している。
3) 連続モードとは，安全制御機能の作動要求が連続的に存在するモードである。すなわち，安全
制御機能が連続的に作動しなければならないモードである。例えば，自動車のハンドル機能は，
一瞬たりとも不作動，誤作動が許されないので，連続モードのSRCFである（自動車は，機械
ではないが。）。
4) 離散的作動要求モードとは，安全制御機能の作動要求が離散的（散発的）に起こるモードであ
る。例えば，自動車のブレーキは，離散的作動要求モードのSRCFである。人がブレーキを踏
むことが，安全制御機能に対する作動要求である。
この附属書では，高頻度作動要求モードと低頻度作動要求モードとを総称して離散的作動要
93
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
求モードという。
JB.2 自己診断及びプルーフテストのタイミング
サブシステムの危険側故障率 λD を小さくするために，自己診断及び／又はプルーフテストがしばしば
採用される。自己診断では，診断率DCに相当する割合（検出率）で危険側故障を検出する。診断によっ
て検出できない（1−DC）の割合の危険側故障は，プルーフテスト（行う場合）で100 ％検出して，修復
する。
記号の意味を，次のとおりとする。
T1：プルーフテスト間隔（時間）
T2：自己診断間隔（時間）（周期的診断の場合）
TD：作動要求間隔（時間）（離散的作動要求モードの場合）
T1，T2 及びTD のタイミングの概念を，図JB.1に示す。
この附属書では，いかなる場合も，T1 ＞ T2 である。例えば，T2 は秒単位から日単位以下の短い時間
であり，T1 は日単位から年単位以上の長い時間であると想定する。
TD は，離散的作動要求モードだけで取り扱う。連続モードでは考慮しない。TD には規則性がなく，TD
＞T2であると仮定する。TD とT1 との関係は，次の二つのケースに分けて考察する（JB.9）。
高頻度作動要求モード： T1 / 2 ＞ TD
低頻度作動要求モード： T1 / 2 ＜ TD
IEC 61508規格群では，低頻度作動要求モードの条件を，T1 / 2 ＜ TD，又は年1回以下としている。
図JB.1−T1，T2，及びTD のタイミングの概念
T2
T2
TD
T1
A：高頻度作動要求モード(T1 / 2 ＞ TD )
T1 / 2
プルーフテスト
プルーフテスト
T2 T2
TD
B：低頻度作動要求モード（T1 / 2＜TD ）
T2
T1
T1 / 2
プルーフテスト
プルーフテスト
94
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
JB.3 サブシステムA（フォールトトレランス0，診断機能なし）のPFHD（6.7.8.2.2参照）
JB.3.1 アーキテクチャ（図JB.2参照）
サブシステムAは，診断機能をもたない，フォールトトレランスが0の非冗長系アーキテクチャである。
図JB.2−サブシステムAの論理的表現
JB.3.2 PFHDの計算
サブシステムAは，診断機能をもたないから危険側故障を検出できない。すべての要素及び部品の危険
側故障がサブシステムの危険側故障（安全制御機能の喪失）につながるから，サブシステムAの危険側故
障率（1時間中に故障する確率）PFHDssA は，次の式(3-1)及び式(3-1)′で計算できる。
λDssA = λDe1 + ...+ λDen（1/時間） ········································· (3-1) (A)
PFHDssA = λDssA × 1時間（無次元） ···································· (3-1)′ (A)′
λDssA の次元は“1/時間”である。λDssA に1時間を乗じてPFHDssA としたのは，PFHDssA を無次元値にし
ただけのことである（以下，同様。）。
JB.3.3 プルーフテストの効果
プルーフテストは，故障を発見して修復を行うものである。プルーフテストによって故障を検出して修
復しても，その後の故障率が下がる訳ではないから，サブシステムAにおいては，プルーフテスト間隔
T1 は，PFHDssA に関与しない。
注記 サブシステムAを離散的作動要求モードで用いる場合は，T1 / 2 ＜ TDであれば，プルーフテス
トはPFDを下げる効果をもつ。この条件では，PFDを次の式で表すことができる（JB.8参照）。
PFDssA = λDssA × T1 / 2
JB.4 サブシステムB（フォールトトレランス1，診断機能なし）のPFHD（6.7.8.2.3参照）
JB.4.1 アーキテクチャ（図JB.3参照）
サブシステムBは，並列冗長系であって，フォールトトレランス1をもつ。サブシステムBが危険側故
障となるのは，二つのサブシステム要素の危険側故障が重なるときである。一方のサブシステム要素が故
障しても他方のサブシステム要素が健全であれば，サブシステムBの安全制御機能は維持される。しかし，
サブシステムBは，診断機能をもたないので，プルーフテストを行うまでは一つ目の故障が起こったこと
を知らずに運転をすることになる。
サブシステムBのプルーフテストに関して，次の三通りの方式が考えられる。
a) 設計寿命が尽きるまでプルーフテストを行わない［方式a)］。
b) T1 の間隔でプルーフテストを行い，テスト及び修復中は運転を休止する。故障を修復して，二つのサ
ブシステム要素が健全であることを確認してから運転を再開する（オフラインプルーフテスト）［方式
サブシステム要素1
λDe1
サブシステム要素n
λDen
サブシステムA（フォールトトレランス0，診断機能なし）
95
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
b)］。
c) T1 の間隔でプルーフテストを行い，テスト中及び修復中も健全なサブシステム要素に依存して運転を
継続する（オンラインプルーフテスト）［方式c)］。
サブシステムBのPFHD計算式は，プルーフテストの方式によって異なる。6.7.8.2.3に示す式(B)は，上
記のa) 及びb) に通用する式である。
図JB.3−サブシステムBの論理的表現
JB.4.2 方式a)及びb)のPFHD の計算
間隔T1で運転を休止するプルーフテストを行い，二つのサブシステム要素が健全であることを確認して
から運転を再開するという前提では，サブシステムBのPFHDssBは，次の式(4-1)及び式(4-1)′で与えられる。
(
)
(
)
項
第
項
第
2
2
/
1
1
De2
De1
1
De2
1
De
2
DssB
λ
λ
β
λ
λ
β
λ
+
+
×
×
×
−
=
T
（1/時間）····················· (4-1) (B)
時間
1
DssB
DssB
×
=λ
PFH
（無次元） ·················································· (4-1)' (B)'
式(4-1)にはプルーフテスト間隔T1 が関与しており，頻繁にプルーフテストを行うほどサブシステムB
の危険側故障率が小さくなる。プルーフテストを行わない場合は，設計寿命をT1 として計算する。
式(4-1)は，第1項及び第2項からなっている。第1項は，共通原因故障以外の危険側故障（以下，この
附属書では，文脈から明白な場合は，共通原因故障以外の故障を単に“故障”又は“危険側故障”と表記
する。）の1時間当たりの確率であり，第2項は危険側の共通原因故障の1時間当たりの確率である。
式(4-1)の第1項の説明
式(4-1)の第1項は，各サブシステム要素の共通原因故障以外の危険側故障が重なる1時間当たりの確率
を示している。サブシステム要素1の全危険側故障率から共通原因故障率を差し引いた値を近似的にλDe1
(1−β)とする。同様に，サブシステム要素2の共通原因故障以外の危険側故障率をλDe2 (1−β)とする。プルー
フテスト間隔T1 の間にサブシステム要素1又は2が共通原因故障以外の危険側故障を起こす確率（無次元）
は，λDe1 (1−β) T1，又はλDe2 (1−β) T1である。T1 の間に両方のサブシステム要素が共通原因故障以外の危険
側故障を起こす確率は，各要素の故障確率の積になるから，これは，λDe1 (1−β) T1 ×λDe2 (1−β) T1 となる。
これをT1で除せば，両方のサブシステム要素の共通原因故障以外の危険側故障が重なる1時間当たりの確
率になる。これが第1項である。
式(4-1)の第1項で，各サブシステム要素の共通原因故障以外の危険側故障を“1−β”倍で近似している
が，この近似によるλDssB の誤差は，両サブシステム要素が同じ危険側故障率をもつとき0であり，それ以
サブシステム要素1
λDe1(1−β)
サブシステム要素2
λDe2(1−β)
サブシステムB（フォールトトレランス1，診断機能なし）
共通原因故障
β(λDe1＋λDe2)/2
96
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
外では正である。近似の誤差がλDssBを大きく見積もる方向に偏るので，この近似は安全側に偏っている。
式(4-1)の第2項の説明
共通原因故障は，二つのサブシステム要素に同時に起こるので，共通原因故障が起こると直ちにサブシ
ステムBが危険側故障になる。共通原因故障係数βの定義によって，共通原因故障率は，各サブシステム
要素の危険側故障率の平均値に共通原因故障係数βを乗じたものである。これが第2項である。共通原因
故障に対してはフォールトトレランスがない。サブシステムBのフォールトトレランスが1であるといっ
ても，共通原因故障のフォールトトレランスは0である。
JB.4.3 方式c) のPFHD の計算
式(4-1)は，運転を休止してプルーフテストを行うこと（オフラインテスト）を前提にしている。
運転を休止せずにプルーフテストを行い，一方のサブシステム要素に起こった危険側故障を修復してい
る間（MTTR1 又はMTTR2 ）も他方のサブシステム要素に依存して（フォールトトレランス0の状態で）
運転を続ける場合（オンライン修理）は，サブシステムBの危険側故障率は，次の式(4-2)及び(4-2)′で与え
られる。
λDssB′ = (1−β)2 × λDe1 × λDe2 × ( T1 + MTTR1 + MTTR2 ) + β (λDe1 + λDe2 ) /2 （1/時間） ····· (4-2)
PFHDssB = λDssB′ × 1時間 （無次元）····························································· (4-2)′
ただし，方式c)の場合であっても，MTTR1 及びMTTR2 がT1に対して無視できるほど小さい場合（T1 が
半年以上でMTTR1 及びMTTR2 が1日以下の場合）には，当然，式(4-1)は有効である。
式(4-2)の第1項は，次のように説明できる。
サブシステム要素1が共通原因故障以外の危険側故障を起こす1時間当たりの確率は，(1−β) × λDe1 （1/
時間）である。よって，T1 の間にサブシステム要素1が故障する確率は，(1−β ) ×λDe1×T1である。サブシ
ステム要素1が，故障してから修復が完了するまでの平均時間は，T1 / 2+ MTTR1である。この平均ダウン
タイム中にサブシステム要素2が共通原因故障以外の危険側故障を起こす確率は，(1−β) × λDe2 × (T1 / 2+
MTTR1)（無次元）である。よって，サブシステム要素1が共通原因故障以外の危険側故障を起こし，続い
てT1+MTTR1の間にサブシステム要素2が共通原因故障以外の危険側故障を起こす1時間当たりの確率は，
これらの積をT1で除して，(1−β) × λDe1 × (1−β) × λDe2 × (T1 / 2+ MTTR1)（1/時間）となる。
同様に考えて，サブシステム要素2が先に共通原因故障以外の危険側故障を起こし，続いてサブシステ
ム要素1が共通原因故障以外の危険側故障を起こす1時間当たりの確率は，(1−β) ×λDe1 × (1−β) ×λDe2 × (T1 /
2+ MTTR2)（1/時間）となる。
サブシステムBが共通原因故障以外の危険側故障を起こす1時間当たりの確率は，これらの和であるか
ら式(4-2)の第1項となる。
式(4-2)の第2項は，式(4-1)の第2項と同じである。
JB.5 サブシステムC（フォールトトレランス0，診断機能あり）のPFHD（6.7.8.2.4参照）
JB.5.1 アーキテクチャ（図JB.4参照）
サブシステムCは，サブシステムAに診断機能を付けたものである。
サブシステムCは，診断によって危険側故障を検出でき，検出したら，直ちに運転停止などのフォール
ト反応が働くことを前提とする。
サブシステムCにおいては，診断によって検出できる危険側故障は，条件によってはサブシステムCの
危険側故障にならない。
サブシステムCの診断に関しては，次の二通りの方式が考えられる。
97
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
a) 連続診断（T2 = 0）とし，故障を検出したら直ちに運転を停止する。
b) 周期的診断（診断間隔T2）とし，故障を検出したら直ちに運転を停止する。
サブシステムCのPFHD計算は，診断の方式によって異なる。6.7.8.2.4に示す式(C)は，a) の場合に通用
する式である。
図JB.4−サブシステムCの論理的表現
JB.5.2 方式a)（連続診断）のPFHD の計算
診断を連続的に行う（T2 = 0）と仮定し，危険側故障を検出したら，直ちにフォールト反応によって100 ％
安全側（運転停止など）へ制御を行うものとすれば，診断によって検出できる危険側故障は，サブシステ
ムCの危険側故障にならない。したがって，連続診断で検出できる危険側故障は，サブシステムCの危険
側故障率に含めない。
DCの定義から，診断によって検出できない危険側故障がすべての危険側故障に対して占める比率は，
1−DCである。診断によって検出できない危険側故障だけが，サブシステムCの危険側故障になるので，
サブシステムCのPFHDは，次の式(5-1)及び式(5-1)′で計算できる。
λDssC = λDe1 (1−DC1) +…..+ λDen (1−DCn ) （1/時間）·································· (5-1) (C)
PFHDssC = λDssC × 1時間 （無次元） ················································· (5-1)′ (C)′
JB.5.3 方式b)（周期的診断）のPFHD の計算
周期的診断の場合は，診断によって検出できる故障であっても，故障が起こってからそれが検出される
まで（最大T2 ）の間は，サブシステムが安全機能を失ったまま運転を続けることになる。したがって，
T2の間に起こる検出できる危険側故障の率をサブシステムCの危険側故障率に加えなければならない。T2
という時間内に，検出できる危険側故障が起こる確率は，(λDe1 ×DC1 + ･･･････ + λDen ×DCn ) ×T2 （無次
元）である。1時間当たりの確率は，これをT2で除して，(λDe1 ×DC1 + ･･･････ + λDen ×DCn ) （1/時間）と
なる。
したがって，T2 が0でない場合のサブシステムCのPFHDは，次の式(5-2)及び式(5-2)′のようになる。
λDssC′ = λDe1 (1−DC1) + ･･･････ + λDen (1−DCn ) ＋ (λDe1 ×DC1 + ･･･････ + λDen ×DCn )
= λDe1 + ･･･････ + λDen （1/時間） ······················································· (5-2)
PFHDssC′ = λDssC′ × 1時間 （無次元） ······················································· (5-2)′
式(5-2)は，診断機能をもたないサブシステムAの式(3-1)と同じである。すなわち，周期的診断には，サ
ブシステムCのPFHDを下げる効果はない。
注記 サブシステムCを離散的作動要求モードで用いる場合は，周期的診断であってもT2 / 2 ＜ TD
サブシステム要素1
λDe1
サブシステム要素n
λDen
サブシステムC（フォールトトレランス0，診断機能あり）
診断機能
98
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
であれば診断によってPFDを下げる効果がある。この条件では，PFDを次の式で表すことが
できる（JB.9参照）。（JB.3.3の注記も参照。）
PFDssC = λDssA ×T2 / 2
JB.6 サブシステムD（フォールトトレランス1，診断機能あり）のPFHD（6.7.8.2.5参照）
JB.6.1 アーキテクチャ（図JB.5参照）
サブシステムDは，サブシステムBに診断機能を追加したものである。サブシステムDが危険側故障
になるのは，二つのサブシステム要素が，共に危険側故障（二重故障）になるときである。
サブシステムDは，診断に関連して，次の四通りの方式が考えられる。
a) T2 の間隔で診断を行う。一つ目の危険側故障を検出しても健全なサブシステム要素に依存して運転を
続ける。故障したサブシステム要素は直ちに修復する。MTTR（平均修復時間）がT2 に対して無視で
きるほど小さい（又は，一つ目の危険側故障の検出と同時に運転を停止し故障を修復してから運転を
再開する。）。
b) T2 の間隔で診断を行う。一つ目の危険側故障を検出しても健全なサブシステム要素に依存して運転を
続ける。故障したサブシステム要素は，一定の時間（MTTR）内に修復する。MTTRがT2 に対して無
視できないほど大きい。
c) 連続診断を行う。一つ目の危険側故障を検出しても運転を続ける。故障したサブシステム要素は検出
と同時に修復を完了する。MTTRが0とみなせるほど小さい。
d) 連続診断を行い，一つ目の危険側故障を検出しても運転を続ける。故障したサブシステム要素は一定
の時間（MTTR）内に修復する。
また，サブシステムDのプルーフテストに関連して，次の二通りの方式が考えられる。
e) T1 の間隔で，運転を休止するプルーフテスト（オフラインテスト）を行う。一つ目の危険側故障を検
出したら運転を停止する。その故障を修復して二つのサブシステム要素が健全であることを確認して
から運転を再開する。
f) T1 の間隔で，運転を休止しないプルーフテスト（オンラインテスト）を行う。一つ目の危険側故障を
検出しても運転を停止せず，故障したサブシステム要素の修復中（MTTR）も健全なサブシステム要
素に依存して運転を継続する。
サブシステムDのPFHDの計算式は，診断方式及びプルーフテスト方式によって異なる。6.7.8.2.5に示
す式(D1)は，上記のa) 及びe) の方式に通用する式である。
JB.6では，異なる設計のサブシステム要素を用いる場合のPFHD計算だけを扱う。同じ設計のサブシス
テム要素を用いる場合は，以後のすべての計算式において，λDe1 =λDe2，DC1 = DC2と置けば得られる。
99
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図JB.5−サブシステムDの論理的表現
JB.6.2 診断方式a)（周期的診断，MTTR = 0）及びプルーフテスト方式e)（MTTR = 0）のPFHD の計算
この場合，サブシステムDのPFHDは，次の式(6-1)及び式(6-1)′によって計算することができる。
(
)
(
)
(
)
）
（ケース
後半
項
第
）
（ケース
前半
項
第
2
1
}
2
/
2
1
1
2
/
{
1
1
2
1
De2
De1
2
2
1
2
De
De1
2
DssD
T
DC
DC
T
DC
DC
×
−
−
×
+
×
+
×
−
=
λ
λ
λ
λ
β
λ
(
)
項
第2
2
/
De2
De1λ
λ
β
+
+
（1/時間） ························································· (6-1) (D1)
PFHDssD = λDssD × 1時間 （無次元） ·····················································(6-1)′ (D1)′
ここに， λDe1： サブシステム要素1の危険側故障率
DC1： サブシステム要素1の診断率
λDe2： サブシステム要素2の危険側故障率
DC2： サブシステム要素2の診断率
サブシステムDの危険側故障率は，共通原因故障以外の危険側故障率と共通原因故障率との和である。
サブシステムDの共通原因故障以外の危険側故障率は，一方のサブシステム要素が共通原因故障以外の危
険側故障を起こし，この故障が残存している間に他方のサブシステム要素が共通原因故障以外の危険側故
障を起こす1時間当たりの確率である。共通原因故障率は，共通原因によって二つのサブシステム要素が
共に危険側故障を起こす1時間当たりの確率である。
式(6-1)は，第1項及び第2項から成り立っている。第1項は，(1−β)2が掛かる部分であって共通原因故
障以外の危険側故障率である。第2項はβが掛かる部分であって共通原因故障率である。
次に，式(6-1)の導き方を示す。
第1項の全体説明
式(6-1)の第1項は，共通原因故障以外の危険側故障がサブシステム要素1及びサブシステム要素2に重
なって起こる1時間当たりの確率を示している。
共通原因故障以外の危険側故障を，診断によって検出できるものと検出できないものの二つに分けて考
える。そうすると，サブシステムDの危険側故障の起こり方は，次のケース1a，ケース1b，ケース2a，
ケース2b の四通りになる。サブシステムDの共通原因故障以外の危険側故障は，この四通りの各ケース
が起こる1時間当たりの確率の和である。
サブシステムD（フォールトトレランス1，診断機能あり，プルーフテストあり）
共通原因故障
β(λDe1＋λDe2)/2
診断機能
サブシステム要素1
λDe1(1−β)
サブシステム要素2
λDe2(1−β)
100
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ケース1
先に，診断によって検出できる危険側故障が起こり，この故障が残存している間に次の危険側故障が他
方のサブシステム要素で起こる場合をケース1とする。ケース1は，次の二つのケースに分かれる。
ケース1a： 診断によって検出できる危険側故障がサブシステム要素1で先に起こる。
ケース1b： 診断によって検出できる危険側故障がサブシステム要素2で先に起こる。
ケース2
先に，診断によって検出できない故障が起こり，この故障が残存している間に次の危険側故障が他方の
サブシステム要素で起こる場合をケース2とする。ケース2は，次の二つのケースに分かれる。
ケース2a： 診断によって検出できない危険側故障がサブシステム要素1で先に起こる。
ケース2b： 診断によって検出できない危険側故障がサブシステム要素2で先に起こる。
第1項の前半（T2 が関与）は，ケース1（1a＋1b）の危険側故障率である。
第1項の後半（T1 が関与）は，ケース2（2a＋2b）の危険側故障率でである。
第1項前半の説明（ケース1）
第1項前半（ケース1）は，先に起きた検出できる危険側故障が，周期T2 の診断機能によって検出され，
運転が停止されるまでの時間T3 内に他方のサブシステム要素が危険側故障を起こす1時間当たりの確率
である。T3 は一定しないが，その平均値（平均ダウンタイム）はT2 / 2である（図JB.6参照。）。
ケース1の危険側故障率は，ケース1aの危険側故障率と，ケース1bの危険側故障率との和である。次
にケース1の危険側故障率を求める。
図JB.6−診断による故障検出タイミング
ケース1a
サブシステム要素1が，検出できる危険側故障を起こす1時間当たりの確率P1a1（1/時間）は，次の式(6-2)
で与えられる。
P1a1 = (1−β) × λDe1 × DC1 （1/時間） ··········································· (6-2)
t3の平均値T2 / 2の間にサブシステム要素2が危険側故障を起こす確率P1a2（無次元）は，次の式(6-3)
で与えられる。
P1a2 = (1−β) × λDe2 × T2 / 2 （無次元） ·········································· (6-3)
したがって，ケース1aが起こる1時間当たりの確率P1a（1/時間）は，次の式(6-4)で与えられる。
P1a = P1a1 × P1a2
= (1−β) × λDe1 × DC1 × (1−β) × λDe2 × T2 / 2
= (1−β)2 × λDe1 × λDe2 × DC1 × T2 / 2 （1/時間） ··························· (6-4)
ケース1b
ケース1bの危険側故障率は，ケース1aと同様に考えて，次の式(6-5)となる。
P1b = (1−β)2 × λDe1 × λDe2 × DC2 × T2 / 2 （1/時間） ··························· (6-5)
診断
診断
T2
T3
この間に他方のサブシステ
ムに危険側故障が発生する
と，サブシステムDが危険
側故障になる。
一つ目の，検出でき
る危険側故障発生
101
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ケース1（ケース1a＋ケース1b）
ケース1が起こる1時間当たりの確率は，ケース1a及びケース1bの確率の和であるから，次の式(6-6)
で与えられる。
P1 = (1−β)2 × λDe1 × λDe2 × (DC1＋DC2 ) × T2 / 2 （1/時間） ················· (6-6)
式(6-6)が，式(6-1)の第1項の前半である。
第1項後半の説明（ケース2）
第1項後半は，一方のサブシステム要素に一つ目の検出できない危険側故障が発生してから，プルーフ
テストが行われるまでの時間T4 内に他方のサブシステム要素が危険側故障を起こす1時間当たりの確率
である。T4 は一定しないが，その平均値（平均ダウンタイム）はT1 /2である（図JB.7参照）。
ケース2の危険側故障率は，ケース2aの危険側故障率とケース2bの危険側故障率との和である。
次にケース2の危険側故障率を求める。
図JB.7−プルーフテストによる故障検出タイミング
ケース2a
サブシステム要素1が，診断では検出できない危険側故障を起こす1時間当たりの確率P2a1（1/時間）
は，次の式(6-7)で与えられる。
P2a1 = (1−β) × λDe1 × (1−DC1) （1/時間） ······································· (6-7)
サブシステム要素1の平均ダウンタイム（T1 /2）中にサブシステム要素2が危険側故障を起こす確率P2a2
（無次元）は，次の式(6-8)で与えられる。
P2a2 = (1−β) × λDe2 × T1 / 2 （無次元） ·········································· (6-8)
したがって，ケース2a が起こる1時間当たりの確率P2a（1/時間）は，次の式(6-9)のようになる。
P2a = P2a1 × P2a2
= (1−β) × λDe1 × (1−DC1) × (1−β) × λDe2 × T1 / 2
= (1−β)2 × λDe1 × λDe2 × (1−DC1) × T1 / 2 （1/時間） ······················ (6-9)
ケース2b
ケース2bの危険側故障率は，ケース2aと同様に導かれて次の式(6-10)となる。
P2b = (1−β)2 × λDe1 × λDe2 × (1−DC2) × T1 / 2 （1/時間） ····················· (6-10)
ケース2（ケース2a +ケース2b）
ケース2の危険側故障率は，ケース2a及びケース2bの危険側故障率の和であるから，式(6-9)及び式(6-10)
の和であって，次の式(6-11)になる。
P2 = P2a + P2b
= (1−β)2 × λDe1 × λDe2 × (2−DC1−DC2) × T1 / 2 （1/時間） ·············· (6-11)
これが式(6-1)の第1項の後半である。
プルーフテスト
プルーフテスト
T1
T4
この間に他方のサブシス
テムに危険側故障が発生
すると，サブシステムD
が危険側故障になる。
診断によって検出できない
一つ目の危険側故障発生
102
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
第2項の説明
式(6-1)の第2項は，共通原因故障率である。共通原因故障は二つのサブシステムに同時に起こる。共通
原因故障率は，各サブシステム要素の危険側故障率の平均値に共通原因故障比率βを乗じたものである。
これが第2項である。
JB.6.3 診断方式b)（周期的診断，MTTR ≠ 0）及びプルーフテスト方式f)（MTTR ≠ 0）のPFHDの計算
式(6-1)は，MTTR = 0とみなせるオンライン修理（又はオフライン修理）を想定した式である。診断又は
プルーフテストによって一つ目の危険側故障を検出した後，これを修復している間（MTTR）も健全なサ
ブシステム要素に依存して運転を継続する場合は，式(6-1)の第1項の前半（診断関連部分）及び後半（プ
ルーフテスト関連部分）を変更しなければならない。
第1項前半（診断関連部分）の変更
診断の方式b) の場合は，診断によってサブシステム要素1の危険側故障を検出した後，これを修復し
ている間（MTTR1）もサブシステム要素2に依存して運転を続けるので，式(6-3)〜式(6-6)を次のように変
更する。
P1a2′ = (1−β) ×λDe2 (T2 / 2 + MTTR1)（無次元） ··················································· (6-3)′
P1a′ = P1a1 × P1a2′
={(1−β) × λDe1 × DC1 }× {(1−β) × λDe2 ×(T2 / 2 + MTTR1)}
= (1−β)2 × λDe1 × λDe2 × DC1 × (T2 / 2 + MTTR1 ) ············································· (6-4)′
P1b′ = (1−β)2 × λDe1 × λDe2 ×DC2 × (T2 / 2 + MTTR2 ) ··············································· (6-5)′
P1′ = P1a′ + P1b′
= (1−β)2 × λDe1 × λDe2 × {(DC1 + DC2 ) × T2 / 2 + (DC1 × MTTR1 + DC2 × MTTR2 )} ····· (6-6)′
式(6-6)′の値は，式(6-6)よりもMTTR1 及びMTTR2 が掛かる部分だけ大きい。
第1項後半（プルーフテスト関連部分）の変更
プルーフテストの方式f)（オンラインプルーフテスト）の場合で，サブシステム要素のMTTRがT1 / 2 に
対して無視できないほど大きいときは，式(6-8)〜式(6-11)を次のように変更する。
P2a2′= (1−β) × λDe2 × (T1 / 2 + MTTR1)（無次元） ················································· (6-8)′
P2a′ = P2a1 × P2a2
= (1−β) × λDe1 × (1−DC1) × (1−β) × λDe2 × (T1 / 2 + MTTR1)
= (1−β)2 × λDe1 × λDe2 × (1−DC1) × (T1 / 2 + MTTR1)（1/時間） ··························· (6-9)′
P2b′ = (1−β)2 × λDe1 × λDe2 × (1−DC2) ×( T1 / 2 + MTTR2)（1/時間）·························· (6-10)′
P2′ = P2a′ + P2b′
= (1−β)2 × λDe1 × λDe2 × {(2−DC1−DC2) × T1 / 2 + (1−DC1) × MTTR1 + (1−DC2) × MTTR2 }
（1/時間） ····························································································· (6-11)′
JB.6.4 診断方式c)（連続診断，MTTR = 0）及びプルーフテスト方式e)（MTTR = 0）のPFHDの計算
連続診断を行い，故障を検出したら直ちに故障を修復する（又は，運転を停止してオフライン修理する）
場合である。連続診断（T2 = 0）なので，ケース1の検出される危険側故障は，サブシステムDの危険側
故障につながらない。ケース2の診断では検出できない危険側故障だけが，サブシステムDの危険側故障
につながる。したがって，式(6-1)においてT2 = 0と置くことによって，次の式(6-1)′が得られる。
λDssD′= λDe1 × λDe2 (2 − DC1 − DC2) × T1 / 2 + β ( λDe1 + λDe2 ) / 2 （1/時間） ·············(6-1)′ (D1)′
JB.6.5 診断方式d)（連続診断，MTTR ≠ 0）及びプルーフテスト方式f)（MTTR ≠ 0）のPFHDの計算
連続診断を行い，故障修復をオンラインで行う場合（平均修復時間をMTTR1及びMTTR2とする。）であ
103
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
る。連続診断（T2 = 0）なので，ケース1の検出される危険側故障は，サブシステムDの危険側故障につ
ながらない。ケース2の危険側故障率は式(6-11)′で与えられる。よって，サブシステムDの危険側故障率
は，次のようになる。
λDssD ′′= (1−β)2 × λDe1 × λDe2 × {(2−2DC1 −2DC2 )T1 / 2 + (1−DC1) × MTTR1 + (1−DC2) × MTTR2 }
+ β ( λDe1 + λDe2 ) / 2 （1/時間） ································································· (6-1)′′ (D1)′′
JB.7 高頻度作動要求モードにおけるPFHDの意味
作動要求が離散的な場合には，サブシステムが危険側に故障してもすぐに危険事象が起こるとは限らな
い。作動要求があるまで危険事象は起こらない。
この規格は，高頻度作動要求モードに対するSILをPFHDで定義しているので，次に，高頻度作動要求
モードにおいて危険事象が起こる確率とサブシステムのPFHDとの関係を考察する。
高頻度作動要求モードにおいて，サブシステムによる安全制御機能の作動失敗が実際に起こる確率Pは，
作動要求が起こる確率P1と，作動要求時にサブシステムが危険側に故障している確率P2との積である。
P = P1 × P2 （無次元） ···························································· (7-1)
P1は，作動要求の頻度であるから，作動要求間隔をTDとすれば，
P1 = 1 / TD （1/時間） ······························································ (7-2)
P2は，TDの間にサブシステムが危険側に故障する確率であって，次の式で表される。
P2 = λD × TD （無次元）···························································· (7-3)
式(7-1)に，式(7-2)及び式(7-3)を代入すると，
P = (1 / Td ) × (λD × TD ) = λD (1/時間） ··········································· (7-4)
P × 1時間 = λD × 1時間 = PFHD （無次元） ································ (7-5)
式(7-5)によって，高頻度作動要求モードにおいて，1時間の間にサブシステムが安全機能の作動失敗を
起こす確率もPFHD であることが確認できた。これによって，この規格がサブシステムのSILを高頻度作
動要求モードに対してもPFHDで定義することが妥当であることを理解できる。
JB.8 PFDの計算式
JB.8.1 概説
この規格（本体）ではPFDを扱わない。低頻度作動要求モードを扱わないためである。しかし，作動要
求が離散的である場合は，PFDによってリスクの評価をしたい場合もあると考えられるため，以下，PFD
とPFHDとの関係を考察する。
サブシステムのPFDは，作動要求があったときにサブシステムが既に危険側に故障している確率である。
PFD計算式は，作動要求間隔TD とプルーフテスト間隔との大小関係によって異なる。PFDは，この条
件によって次の式(8-1)又は式(8-2)のいずれかによって計算できる。基本式の検証は，次のJB.8.2及びJB.8.3
で行う。
高頻度作動要求モード（T1 / 2 ＞ TD 又はプルーフテストなし）のPFD
次の式(8-1)による。
PFD = λD × TD ······································································ (8-1)
λD ×1時間 = PFHD と定義したから，
PFD = PFHD × TD / 1時間 （無次元） ········································ (8-1)′
JIS C 0508-1では，低頻度作動要求モードのSILをPFDで定義している。JIS C 0508-1の表2のSIL 1
104
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
の要求値を見ると，
高頻度作動要求又は連続モードのPFHD
10−6以上10−5未満
低頻度作動要求モードのPFD
（作動要求当たりの設計上の機能失敗平均確率）
10−2以上10−1未満
となっている。すなわち，PFDは，PFHD の10 000倍になっている。このことは，TD として10 000時間
を想定したことを意味すると思われる。10 000時間は，約1年（8 736時間）に相当する。IEC 61508規格
群では，高頻度作動要求モードと低頻度作動要求モードとを，TD が1年又はT1 / 2を超えるかどうかで区
別している。
低頻度作動要求モード（T1 / 2 ＜ TD ）のPFD
次の式(8-2)による。
PFD = λD × T1 / 2 ····································································· (8-2)
λD ×1時間 = PFHD と定義したから，
PFD = (PFHD× T1 / 2) / 1時間 （無次元） ··································· (8-2)′
JB.8.2 式(8-1)の検証
式(8-1)が成立する理由は，次のとおりである（図JB.1のA参照。）。
最初の作動要求は，サブシステムを立ち上げてからTD 時間後に発生する。最初の作動要求に失敗する
のは，TD 時間が経過したときにサブシステムが既に危険側故障を起こしている場合である。TD 時間の間
に危険側故障が発生する確率はλD ×TD である。よって，最初の作動要求に失敗する確率は式(8-1)で与えら
れる。
2番目の作動要求は，最初の作動要求に対する処理が済んでからTD 時間後に発生することになる。最
初の作動要求に失敗していた場合には，サブシステムAの故障を修復してから再立ち上げしたはずである
から，この場合に2番目の作動要求に失敗する確率は式(8-1)となる。最初の作動要求に成功していた場合
は，その時点でサブシステムの安全機能が正常であったことが確認されたことになる。サブシステムは，
正常な状態でリセットされてから次の作動要求を待っていたのだから，この場合も2番目の作動要求に失
敗する確率は式(8-1)で与えられる。
同様に，何番目の作動要求に失敗する確率も式(8-1)で与えられる。
JB.8.3 式(8-2)の検証
式(8-2)が成立する理由は，次のとおりである（図JB.1のB及び図JB.8を参照。）。
プルーフテストでは，危険側故障を漏れなく検出し，検出した場合は故障を修復してから再立ち上げす
るから，直前のプルーフテストから作動要求までの間にサブシステムの危険側故障が起こる確率がPFDに
なる。
テスト及び作動要求のタイミング関係を，図JB.8に例示する。図JB.8は，四通りの作動要求間隔を例
示している。作動要求間隔はT1 / 2よりも大きいがその間隔は一定でない。テストとテストとの間（T1時
間）に作動要求はないこともあり，最大1回の作動要求がある。
事例1では，間隔t1の間に起こった危険側故障が，作動要求時の機能失敗を招く。同様に，事例2，3，
4では，間隔t2，t3，t4の間に起こった危険側故障が，作動要求時の機能失敗を招く。各作動要求時の失敗
確率は
PFDn = λD × tn （無次元）
で与えられる。tnの平均値はT1 / 2であるから，平均の失敗確率は，
105
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
PFD = λD × T1 / 2（無次元）
となる。これが式(8-2)である。
以上の記述は，T1の間に起こる作動要求の分布が時間に対して一様であることを仮定したものである。
TDに一定の周期性がある場合には，さらに厳密な検証が必要であるが，作動要求の起こり方がどうであれ，
T1 / 2 ＜ TD である限り，PFDが
PFDmax = λD × T1 （無次元） ····················································· (8-3)
を超えることは有り得ない。機械の分野では，一般にTDには規則性がないと考えられるため，低頻度作動
要求モードの場合は，式(8-2)を適用しても大きな誤りを生じない。
図JB.8−作動要求及びプルーフテストのタイミング（T1 / 2 < TD）
JB.9 フォールトトレランスの概念
JB.9.1 フォールトトレランスの意味
この規格では，SRECS，サブシステム又はサブシステム要素が，故障が存在する状況で，要求された機
能を続行できる能力をフォールトトレランスという（3.2.31参照）。
ハードウェアフォールトトレランスがNであるということは，N＋1個目の故障が安全機能の喪失又は
失敗を起こし得ることを意味する（表5の注記1参照）。
サブシステムのPFHDが小さいほど安全制御システムの安全性が高いといえるが，PFHDだけでサブシス
テムの安全性を評価することはできない。いくらPFHDが小さくても，一つの危険側故障によって安全制
御機能が直ちに失われるようなサブシステムは，安全性が高いとはいえない。
例えば，冗長系にすることによって，危険側故障が一方のサブシステム要素に発生してもさらに次の危
険側故障が残存サブシステム要素に発生するまでは安全制御機能が失われないようなサブシステムでは，
最初の故障によってサブシステムが直ちに安全制御機能を失うことがないようにできる。
この附属書で考察するサブシステムA及びC は，非冗長系であって，フォールトトレランス0のサブ
プルーフテスト間隔
作動要求事例1
作動要求事例2
作動要求事例3
作動要求事例4
T1 /2
T1
T1
T1
T1
t1
t2
t3
t4
TD1
TD2
TD3
TD4
106
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
システムである。サブシステムC は，診断機能をもつが，診断によって危険側故障を検出できるが，検出
したら直ちに運転を停止し故障を内包したまま運転を続けることがない。よってフォールトトレランスが
0である。
サブシステムB及びDは，並列冗長系であって，一つの危険側故障によって直ちに安全機能を失うこと
がないから，フォールトトレランスが1である。
JB.9.2 フォールトトレランス対自己診断
一般には，フォールトトレランスをもつサブシステムの方がフォールトトレランスをもたないサブシス
テムより安全性が高いと考えられるが，常にそうとはいえない。例えば，サブシステムBの方がサブシス
テムCより常に安全性が高いとは一概にいえない。サブシステムBは，フォールトトレランス1をもつが，
診断機能をもたないため，一つ目の危険側故障によってフォールトトレランスが0になったことを知るこ
とができない。いつサブシステムの安全制御機能が失われるか分からない不安を抱えながら運転を続けな
ければならない。サブシステムCは，フォールトトレランスをもたないが，故障したら直ちに（T2以内に）
故障を検出して運転を停止するから，故障を知らずに運転を継続する時間は最大でもT2という短い時間に
限られる。フォールトトレランス0のサブシステムCが，フォールトトレランス1のサブシステムBより
安全性が低いとは一概にいえない。
また，フォールトトレランス数が同じであっても，サブシステムの安全性が同じであるとはいえない。
この規格では，サブシステムB及びサブシステムDのいずれもフォールトトレランスが1であるとみなさ
れるが，一般には，サブシステムDの方が，安全性が高い。
JB.9.3 フォールトトレランス対PFHD
フォールトトレランスが0になったとき，そのことを100 ％検出して，直ちに修復するなどの安全方策
をとれば，危険事象がいつ起こるかも知れないというリスクから完全に逃れることができる（修復中は逃
れられない。）。しかし，診断によって危険側故障を100 ％検出することは一般に困難である。フォールト
トレランスをもつサブシステムであっても，フォールトトレランスを失ったことを知らずに運転を続ける
確率を0にすることはできない。
この規格の6.7.8.2に示すサブシステムB及びサブシステムDのPFHDの計算式は，サブシステムのフォ
ールトトレランスが0になったことを知らずに（検出できずに），一つの危険側故障を抱えたまま運転を続
け，第2の危険側故障によってサブシステムが安全制御機能を失う確率を与えている。
6.7.8.2の式(A)，式(B)，式(C)，式(D1)で計算した各サブシステムのPFHD が同じであるとすれば，フォ
ールトトレランスの有無にかかわらず，サブシステムが，運転を開始してから安全制御機能を失う1時間
当たりの確率は同じである。
しかしそれでも，PFHD が同じなら，構造的にフォールトトレランス数の多いサブシステムの方がより
安全だとする考えがある。この規格では，SILを単にPFHDだけで決めるのではなく，フォールトトレラ
ンスも考慮して決めることになっている（表5参照）。
107
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
参考文献
JIS B 3503 プログラマブルコントローラ−プログラム言語
注記 対応国際規格：IEC 61131-3, Programmable controllers−Part 3: Programming languages (IDT)
JIS B 9714 機械類の安全性−予期しない起動の防止
注記 対応国際規格：ISO 14118:2000, Safety of machinery−Prevention of unexpected start-up (IDT)
JIS C 0508-1 電気・電子・プログラマブル電子安全関連系の機能安全−第1部：一般要求事項
JIS C 0508-4 電気・電子・プログラマブル電子安全関連系の機能安全−第4部：用語の定義及び略語
注記 対応国際規格：IEC 61508-4, Functional safety of electrical/electronic/programmable electronic
safety-related systems−Part 4: Definitions and abbreviations (IDT)
JIS C 61000-4-2 電磁両立性−第4部：試験及び測定技術−第2節：静電気放電イミュニティ試験
注記 対応国際規格：IEC 61000-4-2, Electromagnetic compatibility (EMC)−Part 4-2: Testing and
measurement techniques−Electrostatic discharge immunity test (IDT)
JIS C 61000-4-3 電磁両立性−第4-3部：試験及び測定技術−放射無線周波電磁界イミュニティ試験
注記 対応国際規格：IEC 61000-4-3, Electromagnetic compatibility (EMC)−Part 4-3: Testing and
measurement techniques−Radiated, radio-frequency, electromagnetic field immunity test (IDT)
JIS C 61000-4-4 電磁両立性−第4-4部：試験及び測定技術−電気的ファストトランジェント／バー
ストイミュニティ試験
注記 対応国際規格：IEC 61000-4-4, Electromagnetic compatibility (EMC)−Part 4-4: Testing and
measurement techniques−Electrical fast transient/burst immunity test (IDT)
JIS C 61000-4-5 電磁両立性−第4部：試験及び測定技術−第5節：サージイミュニティ試験
注記 対応国際規格：IEC 61000-4-5, Electromagnetic compatibility (EMC)−Part 4-5: Testing and
measurement techniques−Surge immunity test (MOD)
JIS C 61000-4-6 電磁両立性−第4-6部：試験及び測定技術−無線周波電磁界によって誘導する伝導
妨害に対するイミュニティ
注記 対応国際規格：IEC 61000-4-6, Electromagnetic compatibility (EMC)−Part 4-6: Testing and
measurement techniques−Immunity to conducted disturbances, induced by radio-frequency fields
(MOD)
JIS C 61000-4-8 電磁両立性−第4部：試験及び測定技術−第8節：電源周波数磁界イミュニティ試
験
注記 対応国際規格：IEC 61000-4-8, Electromagnetic compatibility (EMC)−Part 4-8: Testing and
measurement techniques−Power frequency magnetic field immunity test (MOD)
JIS C 61000-4-11 電磁両立性−第4部：試験及び測定技術−第11節：電圧ディップ，短時間停電及
び電圧変化に対するイミュニティ試験
注記 対応国際規格：IEC 61000-4-11, Electromagnetic compatibility (EMC)−Part 4-11: Testing and
measurement techniques−Voltage dips, short interruptions and voltage variations immunity tests
(MOD)
JIS C 61000-6-1 電磁両立性−第6部：共通規格−第1節：住宅，商業及び軽工業環境におけるイミ
ュニティ
108
B 9961：2008 (IEC 62061：2005)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注記 対応国際規格：IEC 61000-6-1, Electromagnetic compatibility (EMC)−Part 6-1: Generic standards
−Immunity for residential, commercial and light-industrial environments (MOD)
JIS Z 8051 安全側面−規格への導入指針
注記 対応国際規格：ISO/IEC Guide 51, Safety aspects−Guidelines for their inclusion in standards
(IDT)
JIS Z 8115 ディペンダビリティ（信頼性）用語
注記 対応国際規格：IEC 60050-191, International Electrotechnical Vocabulary. Chapter 191:
Dependability and quality of service (MOD)
JIS Z 8245-1:2006 技術文書マネジメント−第1部：原則及び方法
注記 対応国際規格：IEC 82045-1:2001, Document management−Part 1: Principles and methods (IDT)
ISO 13849-1:2006，Safety of machinery−Safety-related parts of control systems−Part 1: General principles
for design
IEC 60870-5-1，Telecontrol equipment and systems−Part 5: Transmission protocols−Section One:
Transmission frame formats
IEC 61025，Fault tree analysis (FTA)
IEC 61165-13，Application of Markov techniques
IEC 61508(all parts)，Functional safety of electrical/electronic/programmable electronic safety-related systems
IEC 61508-1，Functional safety of electrical/electronic/programmable electronic safety-related systems−Part
1: General requirements
IEC 61508-6，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 61508-7，Functional safety of electrical/electronic/programmable electronic safety-related systems−Part
7: Overview of techniques and measures
IEC 61810-2，Electromechanical elementary relays−Part 2: Reliability