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

B 9961

:2008 (IEC 62061:2005)

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

ページ

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(参考)PFH

D

の計算式の考察など

92

参考文献

107

 


B 9961

:2008 (IEC 62061:2005)

(3)

まえがき

この規格は,工業標準化法第 12 条第 1 項の規定に基づき,社団法人日本機械工業連合会(JMF)から,工

業標準原案を具して日本工業規格を制定すべきとの申出があり,日本工業標準調査会の審議を経て,厚生

労働大臣及び経済産業大臣が制定した日本工業規格である。

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

この規格の一部が,特許権,出願公開後の特許出願,実用新案権又は出願公開後の実用新案登録出願に

抵触する可能性があることに注意を喚起する。厚生労働大臣,経済産業大臣及び日本工業標準調査会は,

このような特許権,出願公開後の特許出願,実用新案権又は出願公開後の実用新案登録出願に係る確認に

ついて,責任はもたない。


B 9961

:2008 (IEC 62061:2005)  目次

(4)

白      紙


  

日本工業規格

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)

  

−  割り付けた安全機能及び安全インテグリティレベル(SIL)を満たす SRECS の設計を可能にする。

−  ISO 13849-1:2006 に従って設計された安全関連サブシステムを SRECS に統合する。

− SRECS の妥当性確認を行う。

この規格は,JIS B 9700-1 に規定するリスク低減法,及び JIS B 9702 に規定するリスクアセスメントの

原則に関連して用いることを意図している。SIL を割り付ける方法の例を,

附属書 に示す。

この規格は,SRECS の偶発故障及び系統的故障の確率,並びに危害のひどさを考慮に入れて,SRECS

の性能を,意図するリスク低減に調和させる方策を示している。

図 に,この規格と他の関連規格との関係を示す。

この規格のほかに,ISO 13849-1:2006 も,機械の安全関連制御システムの設計及び実現のための要求事

項を規定する機能安全規格である。いずれの規格も,その規格の適用範囲に従って関連する安全要求を満

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

表 に,この規格及び ISO 13849-1:2006 の適用の推奨案を示す。

表 1−この規格及び ISO 13849-1:2006 の適用の推奨案

安全関連性能を実現する技術方式

ISO 13849-1:2006

この規格

A

非電気的,例えば,液圧式

適用できる。

適用できない。

B

電気・機械的(electromechanical)部

品(例えば,リレー)

,又は非複雑

電子部品

PL e までの指定のアーキテクチャに
適用(

注記 参照)。

SIL 3 までのすべてのアーキ
テクチャに適用。

C

高複雑度電子システム,例えば,プ
ログラム式

PL d までの指定のアーキテクチャに
適用(

注記 参照)。

同上

D A と B との複合 PL e

までの指定のアーキテクチャに

適用(

注記 参照)。

注記 参照

E C と B との複合 PL

までの指定のアーキテクチャに

適用(

注記 参照)。

SIL 3 までのすべてのアーキ
テクチャに適用。

F C と A,又は C と A 及び B との複

注記 参照

注記 参照

注記 1  指定のアーキテクチャは,ISO 13849-1:2006 の附属書 に示され,PL の定量化に関する簡単化した手法

が与えられている。

注記 2  高複雑度電子システムには,ISO 13849-1:2006  に指定される PL d  までのアーキテクチャ又はこの規格に

よるすべてのアーキテクチャを用いることができる。

注記 3  非電気的な制御システムには,サブシステムとして ISO 13849-1:2006 に適合する部品を用いる。

注記  表 は,機械の安全関連システムに,この規格又は ISO 13849-1:2006 のいずれを適用するべき

かを規定している訳ではない。

表 は,制御システムの技術方式と複雑性とに対応させて,こ

の規格及び ISO 13849-1:2006 の適用可能範囲を要約している。

 


3

B 9961

:2008 (IEC 62061:2005)

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

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 割付け法 
・アーキテクチャ志向 
・系統的故障の回避・抑制の要求

・安全性指標をカテゴリ及び PL

a)

で表現

・定性的リスクグラフによるカテゴリ割付け

・アーキテクチャ志向

非電気的 SRPCS

b)

(機械式,液圧式など)

SRECS

の設計目標

関連規格

:電気的安全の側面

:機能安全の側面

電気的 SRPCS

b)


4

B 9961

:2008 (IEC 62061:2005)

  

1

適用範囲

この規格は,機械の安全関連電気制御システム(以下,SRECS という。

)の設計,統合及び妥当性確認

のための要求事項及び推奨事項を規定する。この規格は,作動中には手で持ち運べない機械(協調して稼

動する機械群を含む。

)に,安全機能を単独又は組み合わせて実行する制御システムに適用する。

注記 1  この規格で用いる“電気制御システム”は,“電気・電子・プログラマブル電子(E/E/PE)制

御システム”を意味する。“SRECS”は,“安全関連の電気・電子・プログラマブル電子制御

システム”を意味する。

注記 2  この規格では,高複雑度のプログラマブル電子式のサブシステム及びサブシステム要素の設

計は,IEC 61508-2 及び IEC 61508-3 の関連要求事項に従うことを想定している。この規格は,

このような高複雑サブシステム又はサブシステム要素に対しては,開発するより,むしろ使

用するための方法を提供する。

この規格はアプリケーション規格であって,技術的な進歩を制限又は阻止することは意図していない。

この規格は,人を危険源から保護するために他の規格又は規則が要求する事項(例えば,ガード,非電気

式インタロック,非電気式制御など)は含まない。機械には,その種類に応じて適切な安全を確保するた

めに特有の要求事項がある。

この規格は,

−  機械のすぐそばにいる人及び機械の使用に直接関係する人たちの傷害又は健康阻害のリスクを低減す

るための機能安全要求事項だけを扱う。

−  機械又は協調して稼動する機械群自体の危険源から生じるリスクだけを扱う。

注記 3  他の危険源から生じるリスクを低減するための要求事項は,関連する規格で規定する。例え

ば,機械がプラントのプロセス工程の一部を担う場合,機械の機能安全要求事項は,プロセ

スの安全に関する限り,この規格以外の要求事項(例えば,IEC 61511)も満足することが望

ましい。

−  機械のための非電気式制御要素の性能要求事項は規定しない。

注記 4  この規格の要求事項は,電気制御システムを対象とするが,枠組及び方法論は,非電気式制

御システムの安全関連部分にも適用できる。

−  電気制御装置自体から生じる電気の危険源は扱わない(例えば,感電については,JIS B 9960-1 を参

照。

この規格の主な箇条の目的を,

表 に示す。

表 2−各箇条の概要及び目的

箇条番号及び項目

箇条の目的

4

  機能安全の管理 SRECS が必要とする機能安全を達成するために必要な管理及び技術活動を規定する。

5

  安 全 関 連 制 御 機 能

(SRCF)の仕様作成に

対する要求事項

SRCF に対して次の要求仕様を決定する手順を規定する。 
・  機能要求仕様。

・  安全インテグリティ要求仕様。

6

  安全関連電気制御シ

ステム(SRECS)の設計

及び統合 

安全要求仕様(SRS)に適合する SRECS を選定する基準,並びに,設計及び実現する方

法を規定する。

次の事項を含む。 
・  システムアーキテクチャの選定。

・  安全関連ハードウェア及びソフトウェアの選定。

・  ハードウェア及びソフトウェアの設計。 
・  設計したハードウェア及びソフトウェアが SRS を満たすことの検証。


5

B 9961

:2008 (IEC 62061:2005)

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

  

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)

実行する。

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

  

いる(例えば,感電の危険源,押しつぶしの危険源,切断の危険源,毒性による危険源,火災

の危険源などのように。

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)

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)

  

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

PFH

D

    (probability of dangerous failure per hour)

SRECS 又はそのサブシステムが,1 時間の間に危険側故障を起こす平均確率。

注記  PFH

D 

を作動要求ごとの失敗確率 PFD と混同してはならない。

3.2.29

目標故障率  (target failure value)

SRECS 又はそのサブシステムが,安全インテグリティ要求を満たすために達成するべき PFH

D

の目標値。

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  = FB

1

  AND  FB

2

  AND ……… AND  FB

n

注記 2  機能ブロックのこの定義は,JIS B 3503 ほかの規格に使われる定義とは異なる。


11

B 9961

:2008 (IEC 62061:2005)

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 

表 及び表 参照)。

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)

  

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  多重チャネルをもつサブシステムの PFH

D

は,サブシステムを構成するチャネル(サブシス

テム要素)の PFH

D

より小さくなり得るが,SRECS の PFH

D

は,SRECS を構成するどのサブ

システムの PFH

D

よりも小さくはなり得ない(このことは,この規格特有の“サブシステム”

の定義に由来する。3.2.5 参照。

注記 3  通常,危険側故障は,SRCF を実行する機能の現実故障又は潜在故障となる。

ここでいう潜在故障とは,その故障が直接サブシステムの安全制御機能を喪失させること

がないような危険側故障をいう。次の故障は,SRECS 又はサブシステムの潜在故障である。

−  診断機能によって検出できる危険側故障。

−  フォールトトレランス をもつ SRECS 又はサブシステムにおいて,稼動開始後又はプ

ルーフテスト後に起こる 個以内の危険側故障。

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)

λ

DD

診断機能によって検出できる危険側故障率

λ

D

危険側故障率

Σλ

S

λ

D

: 合計の故障率

SRECS の各サブシステムの DC(あれば)は,サブシステムの PFH

D 

を計算するとき考慮に

入れる。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)

  

注記  ファームウェア又はシステムソフトウェアは,組込みソフトウェアの例である。

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)

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

制約可変言語

PFH

D

 

Probability of dangerous Failure per Hour

1 時間当たりの危険側故障確率

MTTF Mean

Time

To

Failure

平均故障時間

MTTR 

Mean Time To Restoration

平均修復時間

P

TE

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

目的

箇条 は,SRECS に要求される機能安全を達成するために必要な管理及び技術活動について規定する。

4.2

要求事項

4.2.1

  すべての SRECS 開発プロジェクトにおいて,機能安全計画を作成し,文書化し,必要なとき更新

しなければならない。機能安全計画は,箇条 5∼箇条 に規定する活動を管理する手順を含まなければな

らない。

注記 1  機能安全計画の内容は,プロジェクトの特徴に応じた内容にすることが望ましい。

プロジェクトの特徴には,次のものがある。

−  プロジェクトの大きさ。

− SRECS の複雑度。

−  設計及び技術の新規性。

−  設計の標準化の度合。

− SRECS の故障によって発生し得る被害の大きさ。

機能安全計画は,特に次のことを満たすものでなければならない。

a)

箇条 5∼箇条 に規定する関連活動を明確にする。

b)

規定された機能安全要求事項を達成する方針及び方策を明確にする。

c)

アプリケーションソフトウェア,開発,統合,検証及び妥当性確認において,機能安全を達成する方

策を明確にする。

d)

箇条 5∼箇条 に規定する関連活動を実行又はレビューをする人,部門又は他の組織,及びリソース

を明確にする。

e) SRECS

の機能安全に関係する情報を記録し,保存する手順及びリソースを明確化又は確立する。


16

B 9961

:2008 (IEC 62061:2005)

  

注記 2  次のことを考慮することが望ましい。

−  危険源の識別(同定)結果及びリスクアセスメントの結果。

− SRCF を実行するために用いる装置及びその安全要求事項。

−  機能安全の維持に責任をもつ組織。

−  機能安全を達成し,維持するために必要な手順(SRECS を変更する場合も含む。

f)

構成管理の方針を記述する(9.3 を参照)

。これには組織関連事項,例えば,担当者及び組織構成を考

慮に入れる。

g)

検証計画を確立する。計画には,次の事項を含める。

−  検証を実施するタイミングの詳細。

−  検証を実行する人,部門又は団体の詳細。

−  検証方針及び検証技術の選定。

−  試験装置の選定及び使用。

−  検証活動の選定。

−  合格基準。

−  検証結果の評価に用いる手段。

h)

妥当性確認計画を確立する。計画には,次の事項を含める。

−  妥当性確認を実施するタイミングの詳細。

−  妥当性確認に供する機械の運転モード(例えば,正規運転モード及び設定モード)の詳細。

− SRECS 妥当性確認で確認対象となる要求事項。

−  妥当性確認の技術方針(例えば,分析手法又は統計的試験)

−  合格基準。

−  合格基準に達しなかった場合にとるべき措置。

注記 3  妥当性確認計画には,SRECS 及びそのサブシステムを全数試験,形式試験及び/又は抜取り

試験に供するかどうかを示すことが望ましい。

4.2.2

  機能安全計画は,次の活動で生じる SRECS 関連の問題点を迅速に追跡処理して,満足する解決を

得るように履行しなければならない。

−  箇条 5∼箇条 で規定する活動。

−  検証活動。

−  妥当性確認活動。

5

安全関連制御機能(SRCF)の仕様作成に対する要求事項

5.1

目的

箇条 は,SRECS が実行するべき SRCF の要求仕様を作成するための手順について規定する。

5.2

SRCF

の仕様作成

5.2.1

概要

5.2.1.1

  JIS B 9700-1JIS 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)

−  機能要求仕様(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)

  

−  フォールト反応機能の説明,及び最初のフォールト反応が機械を止めることである場合は,再起動又

は運転継続に対する制約などの説明。

−  運転環境の説明(例えば,温度,湿度,ちり,化学物質及び機械的振動衝撃)

−  試験及びその関連装置(例えば,試験装置及び試験アクセスポート)

− SRCF の目的に用いる電気・機械複合部品の作動頻度及び/又は使用カテゴリ。

5.2.3.2

  SRECS を工業地環境で用いることを意図する場合,電磁イミュニティレベルは,JIS C 61000-6-2

によるほか,

附属書 に示す強化イミュニティレベルをもつことが望ましい。他の電磁環境(例えば,住

宅地環境)で用いることを意図する 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 の安全インテグリティ要求は,PFH

D

3.2.28

参照)の目標値によって定義する。

5.2.4.2

  各 SRCF の安全インテグリティ要求は,

表 に示す SIL(附属書 に SIL 割付けの方法例を示す。)

によって規定し,文書化しなければならない。

注記 1 SRCF の要求安全インテグリティが SIL1 未満である場合には,少なくとも JIS B 9705-1 のカ

テゴリ B の要求事項を満たすことが望ましい。

表 3−安全インテグリティレベルを定義する SRCF の目標 PFH

D

安全インテグリティレベル

PFH

D

SIL 3

10

8

    ≦  PFH

D

  < 10

7

SIL 2

10

7

    ≦  PFH

D

  < 10

6

SIL 1

10

6

    ≦  PFH

D

  < 10

5

注記 2 SIL は,表 に示す PFH

D

だけによって決められるものではない。アーキテクチャによる制

約(6.7.6 参照)及び系統的安全インテグリティの要求事項(6.7.9 参照)も SIL の決定に関連

する。

注記 3 SIL

3 に要求される PFH

D

は,連続稼動とすれば約 1 000 年∼10 000 年に一度故障する確率で

ある。この規格は機械類を対象としており,これより低い故障率を要求する SIL 4 は扱わな

い。

注記 4  PFH

D 

は,システムの危険側ランダムハードウェア故障率 λ

D

に 1 時間を乗じて,無次元数に

したものである(6.7.8.2 の式参照。

注記 5  PFH

D 

は,SRECS が 1 時間の間に SRCF を失う確率である。高頻度作動要求モードにおいて

は,PFH

D

は,作動要求時に安全機能が作動しないことが 1 時間の間に起こる確率になる(JB.7

を参照。

5.2.4.3

  製品規格が SRCF の SIL を規定している場合は,5.2.4 及び

附属書 によらず,製品規格の要求 SIL


19

B 9961

:2008 (IEC 62061:2005)

を優先して適用する。

6

安全関連電気制御システム(SRECS)の設計及び統合

6.1

目的

箇条 は,

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 を参照)の要求。

−  PFH

D

の要求(6.6.3.2 参照)

b)

系統的安全インテグリティ要求(6.4 参照)

。この要求は,次の項目で構成される。

−  故障回避の要求。

−  系統的フォールト抑制の要求。

c)

フォールト検出時の SRECS の動きに対する要求事項(6.3 参照)

d)

安全関連ソフトウェアの開発設計に対する要求事項(6.10 及び 6.11 参照)

6.2.3

  SRECS は,人間の能力及びその限界を(合理的に予見可能な誤用を含めて)考慮に入れて,オペレ

ータ及び保全作業者の資質に適応するように設計しなければならない。すべてのオペレータインタフェー

スの設計は,人間的要素を適切に取り入れて(JIS B 9706-1JIS 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)

  

6.3

内部フォールト検出時の SRECS の動きに対する要求事項

6.3.1

  1 以上のハードウェアフォールトトレランスをもつサブシステムにおいては,内部に危険側フォー

ルトを検出したときは,指定のフォールト反応機能が作動しなければならない。

SRECS の仕様によっては,機械の安全な運転を続けながら,サブシステムのフォールト部分を分離して

修理[オンライン修理

4)

]することができる。この場合,フォールト部分の修理が PFH

D

の計算(6.7.8 

照)に用いた最大時間以内に完了しなければ,安全状態を維持するために第二のフォールト反応が作動す

るようにしなければならない。

オンライン修理できるように設計する場合,フォールト部分の分離は,分離によって SRECS の安全イ

ンテグリティが SRS で指定したレベル以下に低下しない場合以外は実施してはならない。

ハードウェアフォールトトレランスを 0 にするようなフォールトの発生後に対しては,6.3.2 の要求事項

を適用する。

注記  信頼性モデルで考える平均修復時間 MTTRJIS Z 8115 の MM10 を参照)には,診断テスト間

隔,修理時間,及び修理完了するまでのすべての遅延を考慮に入れる必要がある。

4)

  オンライン修理とは,(例えば,多重系システムにおいて正常なサブシステムに依存して)シス

テムの稼動を続けながら故障サブシステムを修理することをいう。

6.7.8.2.5

に示すサブシステム D は,オンライン修理に対応できるサブシステムの例である。

ただし,サブシステム D でオンライン修理する場合の PFH

D

の計算については,

 JB.6.3 及び

JB.6.4

を参照。

6.3.2

  要求 PFH

D

を達成するために診断機能を用いる場合で,かつ,サブシステムのハードウェアフォー

ルトトレランスが 0 である場合は,SRCF によって防止するべき危険状態が発生する前に,フォールト検

出及び指定のフォールト反応が作動しなければならない。

注記  6.7.8.2.4 に示すサブシステム C は,この要求が適用されるサブシステムの例である。6.3.2 は,

式(C)が有効であるための条件,すなわち,DC が有効となる条件を規定している。JB.5 を参照。

例外  ハードウェアフォールトトレランスが 0 であっても,診断テスト頻度が作動要求頻度の 100 倍

を超えるような特定の SRCF を実行するサブシステムの場合には,6.3.2 の要求を除外するが,

そのサブシステムの診断テスト間隔は,サブシステムの PFH

D

の要求値を満たすものとしなけ

ればならない。

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)

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)

  

電したとき,予期しない始動が発生してはならない。

注記 1  JIS B 9960-1 の関連部分も参照。特に,次のことを実施することが望ましい。

−  過電圧又は不足電圧は早く検出し,すべての出力データ(回路)を電源オフルーチ

ン又は予備電源への切替えルーチンによって安全な状態に切り換えることができる

ようにする。及び/又は,

−  必要な場合,過電圧又は不足電圧は早く検出し,内部の状態を不揮発性メモリに保

存できるように,また,すべての出力データ(回路)を電源オフルーチンによって

安全状態にする,又はすべての出力データ(回路)を電源オフルーチン又は予備電

源への切替えルーチンによって安全な状態に切り換えることができるようにする。

−  物理的な環境又はサブシステムからの電磁妨害の影響が危険を導かないような設計をする。

c)

すべてのデータ通信プロセスから生じる誤り及びその他の影響(伝送誤り,繰返し,消去,挿入,再

順序付け,損壊,遅れ,及び偽装を含む。

)を抑制する方策。

注記 2  さらに詳しい情報を IEC 60870-5-1 及び IEC 61508-2 に示す。

注記 3  偽装(masquerade)とは,メッセージの本当の内容が正確に識別されないことをいう。例

えば,偽装(見せかけ)によって非安全関連構成品からのメッセージが安全関連構成品か

らのメッセージとして間違って識別される。

d)

インタフェース部分において危険側フォールトが発生するとき,このフォールトによって危険源が発

生する前に,フォールト反応機能が作動しなければならない。ハードウェアフォールトトレランスを

0 にするフォールトが発生するときは,このフォールト反応は,推定 MTTR6.7.4.4.2 g)  参照]に相

当する時間が経過する前に作動しなければならない。

d)

の要求事項は,サブシステムの入力,出力,及び統合中にケーブル接続を必要とするサブシステ

ムのその他のすべての部分(例えば,ライトカーテンの出力信号開閉器,ガードの位置検出器の出力

部)に適用する。

注記 4  このことは,サブシステム又はサブシステム要素がそれ自身の出力上でフォールトを検出

することを要求してはいない。フォールト反応機能は,診断テストが実行された後に,続

いて作動する任意のサブシステムによって始動してもよい。

6.4.3

電磁イミュニティ

SRECS は,JIS C 61000-6-2 及び附属書 に示す電磁イミュニティ要求を満足するほかに,電磁妨害に

対する機能の安全性について次の性能基準を満足しなければならない。

−  不安全状態又は危険状態が生まれてはならない。及び,

− SRCF を失わない。又は,

−  危険が発生する前に機械の安全状態が維持又は達成されるならば,SRECS が実行する SRCF は一時的

又は永久的に阻害されてもよい。妨害が構成品の破壊をもたらす場合(部分破壊をもたらすような低

レベルの妨害も含む。

)は,機能の安全性が影響を受けないことが保証(例えば,分析によって)され

なければならない。

注記  附属書 に示すレベル以内のすべての電磁現象に対する SRECS の動きについて考慮すること

が望ましい。

6.5

SRECS

の選定

SRS に規定される特定の機能をもつ SRECS が既に市場に存在する場合は,その製品が SRS の要求事項

並びに 6.36.4 及び 6.6.1 に適合するならば,新規設計する代わりに既設計の SRECS を選定してもよい。


23

B 9961

:2008 (IEC 62061:2005)

注記  既設計の 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 の設計及び開発は,図 に示す過程のすべての段階を考慮に入れて,明確に定義した過程に従わ

なければならない。

注記  この規格は,SRS 要求事項から始まる構造化設計過程を SRECS に適用することを求めている。

図 は,構造化設計過程の作業の流れ及び構造化設計の関連用語を示す。

6.6.2.1

システムアーキテクチャ設計

6.6.2.1.1

  SRECS の SRS に規定される各 SRCF は,例えば,図 に示すように,機能ブロック構造に分解

しなければならない。この構造は,次の内容からなる文書に記録しなければならない。

−  構造の説明。

−  各機能ブロックの安全要求事項(機能要求及びインテグリティ要求)

−  各機能ブロックの入力,出力の定義。

注記 1  機能分解は,機能ブロック構造が SRCF の機能要求及びインテグリティ要求を完全に表現す

るように行うことが望ましい。この過程は,機能ブロックの機能要求及びインテグリティ要

求をサブシステムに割り当て,一つのサブシステムに一つの機能ブロックの機能要求を完全

に割付け可能となるレベルまで適用することが望ましい。一つのサブシステムに一つ以上の


24

B 9961

:2008 (IEC 62061:2005)

  

機能ブロックを割り当ててもよい。ただし,異なる機能及びインテグリティを与えようとす

る複数のサブシステムに同じ機能ブロックを割り当ててはならない。一つの機能ブロックの

機能要求を冗長サブシステム要素に割り当てる場合は,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)

図 2SRECS の設計及び開発作業の流れ

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)

  

図 3−機能ブロックの安全要求事項をサブシステムへ割り付ける概念(6.6.2.1.1 参照)

6.6.3

SRECS

の安全インテグリティ推定に対する要求事項

6.6.3.1

一般事項

SRECS の SIL は,SRECS が実行する SRCF ごとに推定しなければならない。

SRECS の SIL は,アーキテクチャによる制約,PFH

D

,及び SRECS を構成するサブシステムの系統的安

全インテグリティから決定しなければならない。付与できる SIL の上限は,系統的安全インテグリティ及

びアーキテクチャによる制約に従う各サブシステムの SIL 付与限界の最も低いレベルとするか,又はそれ

未満としなければならない。

6.6.3.2

ハードウェア安全インテグリティ

6.6.3.2.1

  各 SRCF の PFH

D

は,SRS が規定する目標 PFH

D

以下にしなければならない。

注記 SIL に対応する PFH

D

は,

表 による。

6.6.3.2.2

  各 SRCF の PFH

D

を推定するときは,次のことを考慮しなければならない。

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)

障を招くようなすべてのモードで。

6.6.3.2.3

  PFH

D

の推定は,6.7.2.2[サブシステム間のデジタルデータ伝送プロセスが該当する場合は k)も

適用。

]に規定する情報を用いて導いた各サブシステムの PFH

D

に基づくものでなければならない。システ

ムの PFH

D

は,SRCF を遂行するすべてのサブシステムの PFH

D

の和とし,該当する場合はデジタルデータ

伝送プロセスの危険側伝送誤り確率を含めなければならない。

PFH

D

  =  PFH

D1

    +………  +  PFH

Dn

    +  P

TE

注記 1  この手法は,“いずれの機能ブロックの故障も SRCF(3.2.16 を参照)の故障をもたらす”と

いう機能ブロックの定義(3.2.32 参照)に基づいている。

注記 2  デジタルデータ伝送以外の相互接続は,サブシステムの一部であるとみなす。

6.6.3.3

アーキテクチャによる制約

アーキテクチャによる制約に基づき,SRECS の SIL は,SRCF を遂行する各サブシステムの SIL 付与限

界(6.7.6 参照)のうちで最も低い限界レベル以下のレベルとしなければならない。

注記  例えば,SRECS が二つの直列接続されたサブシステム(サブシステム 1 及びサブシステム 2)

で構成され,各サブシステムの SFF 及びフォールトトレランスが

表 のとおりであると仮定す

る。SRECS の目標 PFH

D

が 8×10

8

であるとする。それは SIL 3 に相当する。しかしながら,

表 によればサブシステム 2 のアーキテクチャによる制約は,SRECS に付与できる SIL を SIL 2

に制限する。

表 4−この例で用いるサブシステム 及びサブシステム の特性

サブシステム

ハードウェアフォー

ルトトレランス

SFF

アーキテクチャによる制約に基づく

SIL 付与限界(表 参照)

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

は,割り当てた機能ブロック(

図 参照)のすべての安全要求事項を満たすサブシステムの実現につ

いて規定する。サブシステムの実現には,次の二つの方法がある。

−  サブシステムの要求事項を十分満たす装置を選定して用いる。すなわち,割り当てた機能ブロックの

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)

  

用いるサブシステムは,必要とする 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 及び診断間隔(T

2

注記 参照)。

注記 2  e)は,サブシステムとは別扱いの診断機能にかかわる事項である。この情報は,SRECS の

信頼性モデルが,サブシステム内で実行される診断機能に関係するときだけ必要である。

f)

診断によるフォールト検出後の平均修復時間(MTTR)を導くために必要なすべての追加情報(例え

ば,修理時間)

注記 3  b)∼f)  は,SRCF の PFH

D

を見積もるために必要である。

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)

アの構成識別に必要な情報。

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.16.7.6.26.7.6.36.7.76.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 参照)

。及び,

−  PFH

D

の要求事項(6.7.8 参照)

b)

系統的安全インテグリティ要求。この要求は,次の事項からなる。

−  故障回避の要求事項(6.7.9.1 参照)及び系統的故障抑制の要求事項(6.7.9.2 参照)

。又は,

−  機器の性能を使用実績によって証明できる証拠。

この場合,サブシステムは,IEC 61508-2 の関連要求事項(IEC 61508-2 の 7.4.7.57.4.7.12 参照)

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

c)

フォールト検出時のサブシステムの動き(フォールト反応)に関する要求(6.3 参照)

6.7.4.2.3

  サブシステムの設計において,SILCL に関連する IEC 61508-2 及び IEC 61508-3 のすべての関連

要求事項を満たす高複雑度構成品をサブシステム要素として用いる場合,その構成品は,サブシステム設

計の観点では低複雑度構成品とみなすことができる。それは,関連故障モード,フォールト検出時の動き,

推定故障率,及び他の安全関連情報が既知だからである。このような構成品は,その供給者が提供する使

用のための適切な情報に従って用いなければならない。

6.7.4.3

サブシステムの設計及び開発の過程

サブシステムの設計及び開発は,明確に定義した過程に従って行わなければならない。

図 に示す過程

のすべての局面を考慮に入れなければならない。


30

B 9961

:2008 (IEC 62061:2005)

  

図 4−サブシステムの設計及び開発作業の流れ(図 のボックス 6B.参照)

6.7.4.3.1

サブシステムアーキテクチャの設計

6.7.4.3.1.1

  サブシステムアーキテクチャの設計において,機能分解の過程は,機能ブロックの機能要求事

項を完全に満たすように機能ブロック要素が構成されるまで行うことが望ましい。この過程は,各機能ブ

ロック要素の機能要求事項をサブシステム要素に割付けできるレベルまで行うことが望ましい

図 参照)。

注記  サブシステムの設計及び開発作業の流れは,図 に示す。

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)

図 5−機能ブロックを分解してサブシステム要素に割り付ける概念

6.7.4.4

サブシステム要素の設計及び選定に対する要求事項

6.7.4.4.1

  サブシステム要素は,意図する使用に適するものであって,関連規格があれば,それらに適合

しなければならない。

6.7.4.4.2

  各サブシステム要素に関し,次の情報を入手しなければならない。

a)

サブシステム要素の機能仕様。

b)

サブシステム要素のインタフェース仕様(例えば,電気的特性)

c)

故障のモード及び故障モード比率,並びに該当する場合(例えば,6.7.4.2.3 に従って用いる高複雑度

構成品)は,DC 及び PFH

D

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)

  

6.7.5

サブシステムの安全性能の決定

サブシステムの安全性能には,そのアーキテクチャによる制約(6.7.6)による SILCL,系統的安全イン

テグリティ(6.7.9

,及び PFH

D

6.7.8)が関連する。

注記 1  サブシステムの SILCL は,このサブシステムを用いる SRCF に付与できる最大の SIL を制限

する。

注記 2 SILCL,系統的インテグリティ,及び PFH

D

は,割り当てた SRCF を実行する SRECS サブシ

ステムが達成する SIL を決定するために必要である。

6.7.6

サブシステムのハードウェア安全インテグリティ付与に対するアーキテクチャによる制約

6.7.6.1

  ハードウェア安全インテグリティの付与において,SRCF に付与できる最高の SIL は,SRCF を実

行するサブシステムのハードウェアフォールトトレランス及び SFF によって制限される。

表 は,サブシ

ステムのハードウェアフォールトトレランス及び SFF を考慮に入れて,サブシステムを用いる SRCF に付

与できる最高の SIL を規定している。

表 に示すアーキテクチャによる制約を各サブシステムに適用しな

ければならない。これらのアーキテクチャによる制約に関して,次の a),b),c)  を適用する。

a)

ハードウェアフォールトトレランスが であるということは,N+1 個の危険側フォールトが発生す

ると SRCF の失敗が起こり得ることを意味する(

注記 参照)。ハードウェアフォールトトレランスの

決定には,自己診断のようなフォールトの影響を抑制する方策は関係しない(

注記 参照)。

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

  表 のアーキテクチャによる制約は,SRCF の機能ブロックを実行するサブシステムごとに適用し

なければならない。

6.7.6.3

  一つのサブシステム要素からなるサブシステムは,表 の要求事項を満たさなければならない。

特に,ハードウェアフォールトトレランスが 0 のサブシステムは,診断機能によって 99  %以上の SFF を

達成しなければならない。

注記  この要求事項は,アーキテクチャによる制約が,一つのサブシステム要素からなるサブシステ

ムの SILCL を SIL 3 にすることが適切であることを正当化するために必要である。

一つのサブシステム要素からなるサブシステム(非冗長系)が,この規格の定義によるフォ

ールトトレランス 1 以上をもつことはないと考えられる。


33

B 9961

:2008 (IEC 62061:2005)

表 5−サブシステムのアーキテクチャに基づく SILCL

安全側故障比率(SFF)

ハードウェアフォールトトレランス  N

注記 参照)

0(注記 参照) 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 

注記 参照)

99  %  ≦ SFF

SIL 3  

SIL 3 

注記 参照)

SIL 3 

注記 参照)

注記 1  ハードウェアフォールトトレランス は,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 の特定のカテゴリをもつサブシステム

は,

表 に示すハードウェアフォールトトレランス及び SSF をもつとみなす。

注記 1  必要な SIL を達成するためには,PFH

D

及び系統的安全インテグリティの要求事項を満たす

ことも必要である。

表 6−サブシステムのカテゴリに基づく SILCL

カテゴリ

左欄のカテゴリをもつサブシステムは,下欄に示す

特性をもつものとみなす。

アーキテクチャによる制約

に基づく SIL 付与限界

ハードウェアフォール

トトレランス

SFF

1 0

< 60 %

注記 参照

2 0

60

%∼90  % SIL 1

3 1

< 60 % SIL 1

1 60

%∼90  % SIL 2

4 2 以上 60

%∼90  % SIL

3(注記 参照)

>90  % SIL

3(注記 参照)

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

  

であるか危険側故障であるかは,SRECS 及びその SRCF(フォールト反応機能を含む。

)に依存する。特

定のモードで故障する確率は,関連するフォールトの発生確率を基礎に,意図する使用法を考慮して決定

しなければならない。故障モード比率は,次の情報から導くことができる。

a)

フィールドの使用実績から集めたもので,意図する使用に該当する信頼できる故障率データ。

b)

権威ある産業情報提供者(

附属書 の注記 参照)からの部品故障データで,意図する使用に該当す

るもの。

c)

附属書 に示す故障モードデータ。

d)

試験及び分析の成果から得た故障率データ。

例外  ハードウェアフォールトトレランスが 0 で,危険側故障につながり得るフォールトの除外を

適用したサブシステムは,

そのサブシステムのアーキテクチャによる制約に基づく SILCL は,

SFF の推定値にかかわらず,SIL 2 を限度とする。

6.7.7.3

  フォールト除外を適用したときは,除外することの正当性を(例えば,分析によって)示し,文

書化しなければならない。

注記  ISO 13849-2 の 3.3 及び表 D.5 に従ってフォールトを除外することが許容される。

6.7.8

サブシステム PFH

D

に関する要求事項

6.7.8.1

一般要求事項

6.7.8.1.1

  サブシステムの PFH

D

は,サブシステム SRS に規定した目標故障率又はそれ以下にしなければ

ならない(6.6.2.1.7 参照)

6.7.8.1.2

  割り当てた機能ブロックを実行する各サブシステムの PFH

D

は,次のことを考慮に入れて見積も

らなければならない。

a)

割り当てた機能ブロックに対応するサブシステムのアーキテクチャ。

注記 1  アーキテクチャの考慮には,サブシステムがハードウェアフォールトトレランスをもつか

どうかを決めることを含む。

b)

すべての故障モードを考慮に入れて,サブシステムの危険側故障を起こす可能性がある各サブシステ

ム要素の故障のうち,診断によって検出できる故障の率(6.3 参照)

c)

すべての故障モードを考慮に入れて,サブシステムに危険側故障を起こす可能性がある各サブシステ

ム要素の故障のうち,診断によって検出できない故障の率(6.3 参照)

d)

共通原因故障に対するサブシステムの感受性(

注記 参照)。

注記 2  フォールト検出のために冗長構成品比較を用いる場合,冗長構成品が同じモードで同時に

故障するときは,フォールト検出の失敗が起こり得る。このような失敗は,共通原因故障

比率を β で表す共通原因故障(CCF)によって発生することがある。

共通原因故障に対する感受性を見積もるための単純化手法を 6.7.8.3 に示す。ハードウェ

ア関連の共通原因故障の影響を数量化することに関するさらに詳しい説明として IEC 

61508-6

附属書 も参照。

e)

診断テスト(3.2.38 参照)の DC 及び関連する診断テスト間隔。

f)

診断によって検出できない危険側フォールトを見つけるために行うプルーフテストの間隔,及び/又

は上記の b)  及び c)  で得られる情報が妥当性を失わないために超えてはならないサブシステム要素の

使用時間。

g)

サブシステムをオンライン修理するように設計する場合は,検出したフォールトを修理する時間。

注記 3  最大修理時間は,修復時間(JIS Z 8115 の MM10 参照)の一部になる。修復時間には,フ


35

B 9961

:2008 (IEC 62061:2005)

ォールト検出に要する時間及び修理作業を実行できない期間も含む(故障確率を計算する

ために MTTR がどのように使われるかを例示した IEC 61508-6 

附属書 を参照。)。修理

が特定の期間(例えば,機械が停止されて安全状態にある期間)にだけ実行可能である状

況では,修理作業を実行できない期間を(これが比較的大きいときは特に)漏れなく考慮

することが特に重要である。

注記 4  サブシステムの PFH

D

を見積もるための単純化手法を 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 以上のハードウェアフォールトトレランスをもつサブシステムの診断テスト間隔は,サブシス

テムの PFH

D

要求を満たすことができる間隔としなければならない(6.3.1 参照)

注記  この診断テスト間隔は,最初の故障を,続いてサブシステムの安全機能が失われる故障が起こ

る前に検出でき,サブシステムの PFH

D

が目標値より小さくなるような間隔にすることが望ま

しい。例えば,6.7.8.2.5 の式(D1)及び(D2)において,要求される PFH

DssD

を満たすような T

2

する。

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 参照)を満たすとき

は,ハードウェア安全インテグリティを見積もるために,

表 に示す PFH

D

の限度値を適用してよい。


36

B 9961

:2008 (IEC 62061:2005)

  

表 7−カテゴリをもつサブシステムの PFH

D

の限度値

カテゴリ

左欄のカテゴリをもつサブシステムは下欄

の特性をもつと想定する。

サブシステムに付与できる PFH

D

限度値

注記 参照)

ハードウェアフォール

トトレランス

DC 

1 0 0

製造業者データ又は一般的なデータ(

附属書

D

参照)を用いる。

2 0

60

∼ 90 %

PFH

D

≧ 10

6

3 1

60

∼ 90 %

PFH

D

≧  2×10

7

4 2 以上 60

∼ 90 %

PFH

D

≧  3×10

8

1

> 90 %

PFH

D

≧  3×10

8

注記 1  PFH

D

付与の限度値は,サブシステムの MTTF(サブシステム製造業者又は関連データ便覧から得

る。

,SRS に規定されるテスト又は確認の頻度(この情報は ISO 13849-2 の 3.5 によるサブシステム

妥当性確認のためにも必要。

,及びこの表に規定する DC(これらの値は JIS B 9705-1 に記述される

カテゴリの要求事項に基づいている。

)の関数である。

注記 2  JIS B 9705-1 のカテゴリ B は,SIL 1 を達成できると考えない。

6.7.8.2

サブシステムの PFH

D

推定の単純化手法

6.7.8.2.1

一般事項

6.7.8.2

は,幾つかの基本サブシステムアーキテクチャの PFH

D

を推定するための単純化手法を記述し,

低複雑度サブシステム要素又は高複雑度サブシステム要素から構成されるサブシステムに使える公式を示

す。公式は,信頼性解析理論を単純化したものであって,推定は安全方向に偏るように意図されている。

これらの公式が有効となる前提条件は,1≫ λ × T

1

T

1

  は,プルーフテスト間隔又は SRECS の寿命時間の

いずれか短い方とする。

)で,サブシステムは高頻度作動要求モード又は連続モード(3.2.27 参照)で運転

されるものとする。サブシステムの PFH

D

と診断機能との関係については,6.8.6 に規定する。

注記 1  この手法によって得られるサブシステムの PFH

D

には,精度上の限界がある。これを受け入

れ難い場合は,さらに正確なモデル化技術(6.7.8.1.1 参照)を適用してもよい。

注記 2  式(A)∼式(D)においては,サブシステム要素の故障率 λ は一定で,十分に低い( 1 ≫ λ× T  )

と仮定している。したがって,次の基礎方程式を用いることができる。

λ = 1 / MTTF

作動回数で寿命を定義する電気・機械複合部品(例えば,リレー)に対しては,B10 値とデ

ューティサイクル C を用いて次の式によって決定する(5.2.3 参照)

λ = 0.1 × C / B

10

注記 3  用いる記号の意味は,次による。

λ = λ

S

λ

D

ここに,

λ

S

安全側故障率

λ

D

危険側故障率

PFH

D

 = λ

× 1h: 1 時間中に故障する平均確率。

λ

D

 = λ

DD

 + λ

DU

危険側故障率

λ

DD

 = λ

D

 × DC: 診断によって検出できる危険側故障率。

λ

DU

 = λ

D

 (1−DC): 診断によって検出できない危険側故障率。

DC: 診断率


37

B 9961

:2008 (IEC 62061:2005)

T

2

診断テスト間隔

T

1

プルーフテスト間隔又は SRECS 寿命のいずれか短

い方。

β: 共通原因故障係数

注記 4  式(A)∼式(D)の検証及び補足説明を,附属書 JB に示す。

6.7.8.2.2

基本サブシステムアーキテクチャ A:診断機能なし,フォールトトレランス 0(図 参照)

このアーキテクチャでは,サブシステム要素のすべての危険側故障が SRCF の故障を引き起こす。サブ

システム A の PFH

D

は,全サブシステム要素の PFH

D

の和であって,次の式で与えられる。

λ

DssA

 = λ

De1

+……+λ

Den

   (A)

PFH

DssA

 = λ

DssA

 × 1h

注記 1  このような単純なサブシステムは,たとえ PFH

D

が SIL の要求を満たしても SFF が 60  %未

満では SIL を付与することはできない(

表 参照)。

図 6−サブシステム の論理的表現

注記 2  図 は,サブシステム A のアーキテクチャの論理的表現であって,物理的実体を示すもので

はない。

6.7.8.2.3

基本サブシステムアーキテクチャ B:診断機能なし,フォールトトレランス 1(図 参照)

このアーキテクチャでは,一方だけのサブシステム要素の一つの故障によってサブシステム B が SRCF

を喪失することはない。二つのサブシステム要素が共に危険側故障にならなければ SRCF が故障(失敗)

に至ることはない。アーキテクチャ B においては,サブシステムの PFH

D

は,次の式で与えられる。

λ

DssB

 = (1−β)

2

× λ

De1

× λ

De2

× T

1

β (λ

De1

λ

De2

) / 2  (B)

PFH

DssB

 = λ

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)

  

図 7−サブシステム の論理的表現

注記  図 は,サブシステム B のアーキテクチャの論理的表現であって,物理的実体を示すものでは

ない。

6.7.8.2.4

基本サブシステムアーキテクチャ C:診断機能付き,フォールトトレランス 0(図 参照)

このアーキテクチャでは,診断によって検出できないサブシステム要素の危険側フォールトは,すべて

SRCF を危険側故障に導く。診断機能がサブシステム要素のフォールトを検出したときは,診断機能はフ

ォールト反応機能を作動させる(6.3.2 参照)

。診断が連続的に行われるとみなせる場合,サブシステム C

の PFH

D

は,次の式で与えられる(周期的診断の場合は,JB.5.2 を参照。

λ

DssC

= λ

De1 

(1−DC

1

) +...............+ λ

Den 

(1−DC

n

)  (C)

PFH

DssC

    = λ

DssC

× 1h

図 8−サブシステム の論理的表現

注記  図 はサブシステム C アーキテクチャの論理的な表現であって,物理的な実体を示すものでは

ない。診断機能は,次のいずれによって実行してもよい(6.8.2 参照。

−  診断を必要とするサブシステム。

− SRECS の他のサブシステム。

−  安全機能の遂行に関与しないサブシステム。

6.7.8.2.5

基本サブシステムアーキテクチャ D:診断機能付き,フォールトトレランス 1(図 参照)

このアーキテクチャでは,サブシステム D は,一方のサブシステム要素の一つの故障によっては SRCF

を喪失しない。

異なる設計のサブシステム要素を用いる場合

周期的診断を行い,最初の危険側故障を診断によって検出すると同時に運転を停止する場合,又は直ち

に故障を修復して運転を続けることを前提にする場合,サブシステム D の PFH

D

は,次の式で与えられる。

(その他の前提条件における計算式は,JB.6 を参照。

λ

DssD

 = (1−β)

2

 { [λ

De1

×λ

De2

(DC

1

 + DC

2

) ]×T

2 

/2 + [ λ

De1

×λ

De2

(2 − DC

1

 − DC

2

) ]×T

1

/2 }

β ( λ

De1

+λ

De2

) /2  (D1)

PFH

DssD

 = λ

DssD

 ×1h

ここに,

λ

De1

サブシステム要素 1 の危険側故障率

DC

1

サブシステム要素 1 の診断率

λ

De2

サブシステム要素 2 の危険側故障率

DC

2

サブシステム要素 2 の診断率

同じ設計のサブシステム要素を用いる場合

サブシステム C

診断機能

サブシステム要素 1

λ

De1

サブシステム要素 n

λ

Den


39

B 9961

:2008 (IEC 62061:2005)

サブシステムの PFH

D

は,次の式で与えられる。

λ

DssD 

= (1−β)

2

 { λ

De

2

× DC × T

2

 + [λ

De

2 

× (1− DC) ] × T

1

 } + β × λ

De

  (D2) 

PFH

DssD

 = λ

DssD

 × 1h

ここに,

λ

De

サブシステム要素 1 及び 2 の危険側故障率

DC: サブシステム要素 1 及び 2 の診断率

図 9−サブシステム の論理的表現

注記 1  図 は,サブシステム D のアーキテクチャの論理的表現であって,物理的実体を示すもので

はない。診断機能は次のいずれによって実行してもよい(6.8.2 参照。

−  診断を必要とするサブシステム。

− SRECS の他のサブシステム。

−  安全機能の遂行に関与しないサブシステム。

注記 2  このサブシステムのフォールト反応は,6.3.1 に規定するように,関連する運転を終結するこ

とであると考えられる。フォールト反応が単にフォールトを報告するだけで,関連する運転

を続けながら,オンライン修理するように設計する場合は,最初のフォールト発生後のサブ

システムの PFH

D

を,残存アーキテクチャに対して新たに決定する必要がある(JB.6 を参照。

6.7.8.3

共通原因故障(CCF)の影響を推定する単純化手法

6.7.8.3.1

  CCF に対するサブシステムの感受性のデータは,サブシステムの PFH

D

6.7.8.1 参照)を見積も

るために必要である。

6.7.8.3.2

  必要な PFH

D

を達成するために,サブシステムに冗長系アーキテクチャを用いる場合,CCF がそ

の冗長性の効果を損ねることがあるならば,共通原因の発生確率に基づく PFH

D

を,冗長性サブシステム

の PFH

D

に加えなければならない。

6.7.8.3.3

  通常,CCF の発生確率は,用いる技術,アーキテクチャ,使用法及び環境の組合せに依存する。

附属書 は,多くのタイプの CCF を回避するために有効である。

6.7.8.3.4

  附属書 は,CCF に対するサブシステムの感受性を低くする設計に用いる方策の有効性を推定

するために使えるスコア表及び関連する方法論を含んでいる。

a) 

共通原因故障は,共通系チャネル(例えば,切換系)の故障ではない。このモデ

ルでは共通系を省略している。共通系チャネルの危険側故障率を無視できない場

合は,これを式(D1)及び式(D2)に加えなければならない。

サブシステム D

サブシステム要素 1

λ

De1

(1−

β

)

診断機能

サブシステム要素 2

λ

De2

(1−

β

)

共通原因故障

a) 

β

(

λ

De1

λ

De2

)


40

B 9961

:2008 (IEC 62061:2005)

  

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

b)

シミュレーション又は分析の能力をもつ CAD ツールを用いる。これによって設計手順を系統的に実

行する。入手可能な試験済みの自動構成要素も含む。

注記 2  6.4.1.2 の注記 を参照。

c)

シミュレーションを行う。機能の作動及び構成品の正しい数値設計[6.4.1.2 

5)

を参照]の両方に

関して,サブシステム設計の系統的なシミュレーションを行う。

6.7.9.2

系統的故障を抑制するための要求事項

6.7.9.2.1

  次の方策を適用しなければならない。

a)

絶縁破壊,停電,電圧変動,過電圧及び不足電圧の影響を抑制する方策。

サブシステムが SRECS の安全状態を達成又は維持できるように,絶縁破壊,停電,電圧変動,過

電圧及び不足電圧の状態に対するサブシステムの動きを前もって決定しなければならない。

注記 1  6.4.2 の注記 を参照。制御回路の電源電圧は,モニタすることが望ましい。指定範囲から

外れたら,電源オフ,又は予備電源への切替えをすることが望ましい。

b)

物理的環境(例えば,温度,湿度,水,振動,ほこり,腐食性物質,及び電磁妨害)の影響を抑制又

は回避する方策。


41

B 9961

:2008 (IEC 62061:2005)

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)及び PFH

D

6.7.8)の要求事項を満たすた

めに必要な診断機能を備えなければならない。

6.8.2

  診断機能は,SRCF とは異なる構造をもつ別個の機能であるとみなす。診断機能は,次のいずれに

よって実行してもよい。

−  診断を必要とするサブシステム自体。

− SRECS の他のサブシステム。

−  安全機能の遂行に関与しない SRECS サブシステム。

注記  6.6.2.1.1 の注記 も参照。

6.8.3

  診断機能は,関連する SRCF に適用される次の事項を満たさなければならない。

−  系統的故障を回避するための要求事項(6.7.9.1 参照)

。及び,

−  系統的故障を抑制するための要求事項(6.7.9.2 参照)

6.8.4

  SRCF の PFH

D

を見積もるときは,SRECS 診断機能の故障確率を考慮に入れなければならない。

注記 1  6.6.2.1.1 の注記 も参照。

注記 2  診断機能をテストするタイミングは,SRCF をテストするタイミングと異なってもよい。一

般に,診断機能のテスト間隔は,ハードウェアフォールトトレランス 1 をもつサブシステム

に適用する要求事項を満たすことが望ましい。


42

B 9961

:2008 (IEC 62061:2005)

  

注記 3 SRCF の安全インテグリティに対する診断機能の寄与が確実に維持されるように,診断機能

の故障を検出し,故障に対して適切に反応するようにすることが望ましい。診断機能の故障

は,オンラインテスト,冗長ハードウェアの比較確認などによって検出できる。

6.8.5

  SRECS 診断機能,及び診断による故障検出・フォールト反応を明確に記述し,関連する SRCF の安

全インテグリティに対する診断機能の寄与を分析しなければならない。

6.8.6

  サブシステムの PFH

D

を推定する単純化手法(6.7.8.2)を適用する場合,次のことを適用しなけれ

ばならない。

− SRECS の PFH

D

の要求値を達成するために診断機能を用いる場合で,かつ,サブシステムのハードウ

ェアフォールトトレランスが 0 の場合は,フォールトによる危険が発生する前に,指定されたフォー

ルト検出及びフォールト反応が行われなければならない。さらに,次のいずれかを満たさなければな

らない。

− SRECS 診断機能は,診断用回路の偶発故障確率及び系統的安全インテグリティが,少なくとも SRECS

の SRCF に指定された値と同じになるようにしなければならない。又は,

注記 1  ハードウェア安全インテグリティに対するアーキテクチャによる制約は,診断機能の実現に

は適用しなくてよい。

−  診断用回路の危険側故障確率が SRCF の PFH

D

より大きい場合は,診断機能又は診断装置が正しく作

動していることを確認するテストを実行しなければならない。このような診断機能のテスト頻度はサ

ブシステムに適用するプルーフテストの 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)

い。これらの情報は,アプリケーションソフトウェア開発者に提供しなければならない。

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 61506ISO/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)

  

注記 2  附属書 は,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)

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)

  

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)

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)

  

−  プログラミングの間違いを容易に検出できる特徴をもつ。及び,

−  設計方法に合致する特徴をもつ。

使用した言語に欠陥があれば,

ソフトウェアアーキテクチャ設計の説明文書に記録しなければならない。

目的に対する言語の適切性は,指摘された言語の欠陥を是正するために必要な追加処置も含め,説明しな

ければならない。

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)

験の仕様を明確にしなければならない。

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)

  

構成品及びサブシステムが,互いに(組込みソフトウェアとも相互して)正しく作用して,意図した機能

は実行し,安全機能を損ねる可能性をもつ意図しない機能は実行しないことを示さなければならない。

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)

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

目的

箇条 は,機械を使用及び保全する全期間を通して,SRECS に要求される機能安全を確実に維持するた


52

B 9961

:2008 (IEC 62061:2005)

  

めの手順を 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

目的

箇条 は,SRECS に適用する妥当性確認過程に対する要求事項を規定する。箇条 の要求事項は,SRS


53

B 9961

:2008 (IEC 62061:2005)

に規定される要求事項を 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)

  

注記 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.4B.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

目的

箇条 は,SRECS を,設計段階,統合段階及び妥当性確認段階(例えば,SRECS の据付け中及び立上

げ中)において変更するときに適用する変更手順について規定する。

9.2

変更の手順

9.2.1

  SRECS の変更要求は,例えば,次のことから生じる。

− SRS の変更。

−  実際の使用条件の変更。

−  事例又は事故の経験。

−  加工材料の変更。

−  機械又は機械運転モードの変更。

注記  使用上の情報又は取扱説明書に従って行う SRECS への介入(例えば,調整,設定,修理)は,

箇条 でいう変更とはみなさない。


55

B 9961

:2008 (IEC 62061:2005)

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)

  

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

  表 は,該当する場合に必要な情報及び文書化について規定する箇所を示す。


57

B 9961

:2008 (IEC 62061:2005)

表 8SRECS の情報及び文書化について規定する箇所

必要な情報

規定する箇所

機能安全計画

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)

  

附属書 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)

図 A.1SIL 割付け作業の流れ

リスク見積りは,反復的作業である。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)

  

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

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)

  

ない。

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

表 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.6SIL 割付けマトリクス

危害のひどさ

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

  

図 A.3SIL 割付けに用いる見積表の例

リスクアセスメント及び安全方策

文書番号 
構成番号 
□初期リスクアセスメント 
□中間リスクアセスメント 
□フォローアップリスクアセスメント

対象製品:             
作成者:               
日付:

濃い灰色部分:安全方策必要

薄い灰色部分:安全方策推奨 

危害のひどさ

クラス  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)

附属書 B

参考)

SRECS

設計の例

序文

この附属書は,参考情報を提供するものであって,要求事項を規定するものではない。

B.1

一般事項

この規格で用いる SRECS 設計の構造化手法では,SRCF に対する機能及びインテグリティ要求事項を,

複数のサブ機能に分解する。この過程は,IEC 61508 規格群が規定する機能安全の技術的枠組を機械産業

部門内で実現するために用いる。

図 B.1 は,SRECS の設計を機械と統合する段階で用いる重要な用語を説

明している。

この設計法を用いると,検証及び妥当性確認の過程によって,SRECS が箇条 の SRS を満たすことを

確認することができる。

次に示す SRECS 設計例は,

箇条 に規定する機能分解の原則及び指定の SRCF の実現法を明確に説明す

ることを意図している。この例は簡単化しており,現実の用例では必要となるかもしれない追加方策,例

えば,ホールド・ツゥ・ラン装置などは考慮していない。 

図 B.1−機能分解に用いる用語の図解

図 B.1 に示す用語は,一般に,設計過程を次の重要な二つの段階に区別することを意図している。

−  SRECS

設計段階  機械の設計者又は制御システムのインテグレータが実施する。

サブシステム(及びサブシステム要素)設計段階  電気装置及び制御装置(例えば,コンタクタ,イ

ンタロックスイッチ,PLC など)の供給者,及び機械設計者又は制御システムインテグレータが実施

する。

論理装置

入力

SRECS

3.2.4 参照)

サブシステム(3.2.5 参照)

サブシステム要素(3.2.6 参照)

出力


66

B 9961

:2008 (IEC 62061:2005)

  

B.2

SRECS

設計の例

図 B.2−例題の機械

この規格が用いる方法論では,SRCF 要求仕様の決定及びそれらの機能を実行する SRECS の設計に対し

て,トップダウン式の構造化手法を用いる。

ステップ 1:  SRECS の SRS を決定する(箇条 参照)。

SRECS 安全要求事項仕様決定段階で,次の情報を得る。

図 B.3SRCF 要求仕様の作成

SRCF

の要求仕様 

機能及びインテグリティの

要求)

SRCF

の例 

機能要求:ガードドアが開いているときは,軸の回

転速度は規定値を超えてはならない。

インテグリティ要求:SIL 2


67

B 9961

:2008 (IEC 62061:2005)

ステップ 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)

  

ステップ 2.2:  機能ブロックの構造は,SRECS アーキテクチャの初期概念である。各機能ブロックに対

する安全要求事項は,対応する SRCF の SRS から導く。

各機能ブロックを実現するサブシステム要素は,SRCF に割り付けた SIL と少なくとも同じ SIL を実現

しなければならない。

図 B.5 において,これは SIL 2 と表記されている(FB1 の SILCL を 2 としているな

ど)

図 B.5SRECS アーキテクチャの初期概念

モータ電源ス

イッチング

 
FB4

SILCL 2

機能ブロック(FB)は,

安全関連機能のトップ

レベルの分解要素であ

って,いずれの FB の

故障も安全関連機能の

故障に帰結する。

入力

ロジックソルビング

アクチュエーション

機能ブロックに割り付けた機能及びインテグリティ要求

機能及びインテグリティの要求を,サブシステムに割り付ける。

回 転 軸 ス ピ ー
ドセンシング

 
FB2 SILCL 2

ガ ー ド 位 置
センシング 
 
FB1 SILCL 2

ロジックソ

ルビング

 
FB3

SILCL 2


69

B 9961

:2008 (IEC 62061:2005)

ステップ 3:  各機能ブロックを SRECS アーキテクチャの中のサブシステムに割り当てる。

各サブシステムは,サブシステム要素で構成する。必要なら,フォールトを検出して適切なフォールト

反応(6.2 を参照)を起こすための診断機能も含める。

SRECS アーキテクチャは,そのサブシステム及びそれらの相互関係によって表現することが望ましい。

この例では,SRECS 及びそのサブシステムアーキテクチャの実現法には多くの選択肢がある。

例 1(図 B.6):  この例では,診断機能(D)は,各サブシステムの中に組み込まれる。

図 B.6−診断機能を SS1SS4 に内蔵する 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)

  

例 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

スピードセンサ

SSE 2.1

コンタクタ
SSE 4.1 

コンタクタ 
SSE 4.2 


71

B 9961

:2008 (IEC 62061:2005)

ステップ 4SRECS が達成する SIL の推定(6.6.3 参照)

SRECS に付与できる SIL は,各サブシステムの SILCL のうちの最も低い値以下でなければならない。

SRECS の PFH

DSRECS

は,SRCF の遂行にかかわるすべてのサブシステムの PFH

D

PFH

D1

PFH

Dn

)の和で

あり,該当する場合は,デジタルデータコミュニケーションの危険側伝送誤り(P

TE

)を含めなければなら

ない。すなわち,

PFH

DSRECS

=  PFH

D1

  +・・・・・  + PFH

Dn

  +  P

TE

この例では,SRCF の目標故障率は SIL 2 である。SIL 2 は,

表 35.2.4.2 参照)から,PFH

D

が 10

6

PFH

D

≧10

7

の範囲にあることである。各サブシステムの PFH

D

図 B.8 に示すように仮定すると,すべてのサ

ブシステムの PFH

D

の合計は 6×10

7

と見積もることができ,SIL 2 の条件を満たしている。したがって,

割り当てた SRCF を SIL 2 のインテグリティで実行するためのすべての要求事項を満足する SRECS 設計で

あることが示されたことになる。

 

図 B.8SRECS の PFH

D

の見積り

PFH

DSRECS

= (1×10

7

)+(2×10

7

)+(1×10

7

)+(2×10

7

)

                  = 6×10

7

サブシステム 1

ガードインタロ

ックスイッチ

PFH

D

=1×10

7

サブシステム 2

スピードセンサ

PFH

D

=2×10

7

サブシステム 3
 
PLC 
IEC 61508 
格群) 
 
PFH

D

=1×10

7

サブシステム 4

コンタクタ

PFH

D

=2×10

7


72

B 9961

:2008 (IEC 62061:2005)

  

附属書 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)

−  有り得るすべての許容差又はマージンを考慮して,安全機能の性能基準(精度及び正確さ)及び時間

的な制約(応答時間)を定量的に記述する。

−  システムの構成又はアーキテクチャ。

−  ハードウェア安全インテグリティに関する指示(ロジックソルバ,センサ,アクチュエータなど)

−  ソフトウェア安全インテグリティに関する指示。

−  メモリ容量及びシステム応答時間に関連する制約。

−  オペレータと装置との間のインタフェース。

−  ソフトウェアの自己モニタ及びソフトウェアによるハードウェアモニタに関する指示。

−  システム作動中にすべての安全機能を確認することを要求する指示[例えば,オンラインテスト,短

時間に消滅する信号(fleeting signal)の捕そく(捉)時間,スキャンレートの一致などに関する指示]

注記 1  モニタに関する指示事項には,安全性目標及び運転上の制約(連続運転の継続時間など)を

考慮に入れた,ウォッチドッグ,CPU の負荷モニタ,ソフトウェアモニタのためのフィード

バック(出力から入力へ)などがある。ハードウェアモニタに関する指示事項には,CPU 及

びメモリのモニタなどの指示,並びに安全機能検証のための指示,例えば,周期的に安全装

置の正しい作動を確かめる可能性に関する指示,を含めることが望ましい。

機能の要求事項は,機能モードごとに指定することが望ましい。一つのモードから他のモードへの移行

について規定することが望ましい。

注記 2  機能モードには,正式モード,及び一つ又は複数の低品位モードがある。機能モードごとに

規定する目的は,非正式モードにおける予期しない動きを避けるためにすべての場面での動

きを規定することである。

C.2.3

既存のソフトウェア

既存のソフトウェアとは,当該システムのために特に開発したものでなく,他の開発ソフトウェアと統

合するソースモジュールのことである。これらには,過去のプロジェクトの設計者が開発したソフトウェ

ア,市場で入手できるソフトウェア(例えば,計算用モジュール,データ分類アルゴリズム)などがある。

この種のソフトウェア,特に市販ソフトウェアを扱うときは,設計者は,以前(市販ソフトウェアの開

発時)

の要求事項を満足するために必要であったすべての要素へ常にアクセスできる訳ではない

(例えば,

どんな試験が実施されたかは設計文書を見なければ分からない。

。評価者との調整ができるだけ早い段階

で必要である。

設計者は,評価者に既存のソフトウェアを用いることを示すことが望ましい。設計者は,既存のソフト

ウェアが SRECS の他のソフトウェア要素と同等のレベルをもっていることを実証することが望ましい。

この実証は,次のいずれかによることが望ましい。

a)

既存のソフトウェアに対して,他のソフトウェアと同じ検証活動を用いる。

b)

既存のソフトウェアが類似の実行環境で類似のシステム上で良好に作動した実績を示す(例えば,コ

ンパイラ又はソフトウェアアーキテクチャのフォーマットが異なるときの結果を評価することは必要

である。

注記 1  既存のソフトウェアを用いることを示す目的は,この種のソフトウェアが起こし得る困難

な問題について可能な限り早い段階で評価者と協議をするためである。既存ソフトウェア

のソースモジュールを新規開発ソフトウェアと統合すると,それが新規開発ソフトウェア

と同じ厳格さで開発されたものでない場合には,

不安全な異常作動の原因となりかねない。

既存のソフトウェアは,他のソフトウェアに適用するものと同じ構成管理及びバージョン管理によって


74

B 9961

:2008 (IEC 62061:2005)

  

識別することが望ましい。

注記 2  構成管理及びバージョン管理は,すべてのソフトウェア構成品に対して,それらの出所にか

かわらず実施することが望ましい。

C.2.4

ソフトウェア設計

ソフトウェア設計の記述には,次の事項を含むことが望ましい。

−  仕様を満たすために決定した構造を定義するソフトウェアアーキテクチャ。

−  ソフトウェアアーキテクチャを構成するすべてのモジュールの入出力(例えば,内部/外部のデータ

ディクショナリの形で。

−  割込み。

−  グローバルデータ。

−  各ソフトウェアモジュール(入出力,アルゴリズム,設計特異性など)

−  用いるモジュール又はライブラリ。

−  用いる既存ソフトウェア。

ソフトウェアは,検証及び保全を容易にするために,モジュール形式にして,論理的に記述することが

望ましい。

−  各モジュール又はモジュールグループは,できれば,仕様書の機能に対応することが望ましい。

−  モジュール間のインタフェースは,可能な限り単純にすることが望ましい。

注記  正しいソフトウェアアーキテクチャの一般的な特徴は,次のように要約できる:モジュールは,

機能との密着性が高く,その環境でのインタフェースが単純である。

ソフトウェアは,次のことを満たすことが望ましい。

−  グローバル変数の数及び範囲を制限する。

−  メモリ中のアレイのレイアウトを管理する(アレイのオーバフローを回避するため。

C.2.5

コーディング

ソースコードは,次のようにあることが望ましい。

−  読める,理解できる,そして試験できる。

−  ソフトウェアモジュールの設計仕様を満たす。

−  コーディングマニュアルに従う。

C.3

ソフトウェア開発過程の指針

C.3.1

開発過程:ソフトウェアライフサイクル

ソフトウェアライフサイクルの指針の目的は,ソフトウェア開発,特にこの開発に含まれる異なる技術

活動を組織化することである。

ソフトウェア開発のライフサイクルは,規定し,文書化することが望ましい(例えば,ソフトウェア品

質計画において。

。ライフサイクルは,すべての技術活動及びソフトウェア開発に必要十分な段階を含む

ことが望ましい。

ライフサイクルの各段階の要求事項は,

基本的技術活動ごとに分割し,

次の記述を含むことが望ましい。

−  入力(文書,標準など)

−  出力(作成した文書,分析報告など)

−  実行する活動。

−  実行する検証(分析,試験など)


75

B 9961

:2008 (IEC 62061:2005)

C.3.2

文書化:文書管理

文書化は,箇条 10 に従って実施することが望ましい。

C.3.3

構成及びソフトウェアの変更管理

構成管理及びそのためのバージョン管理は,承認を必要とする開発では不可欠である。

実際のところ,承認は,承認するべき構成部分を識別できるときだけ有効となる。構成管理には,構成

識別活動,変更管理,参照ポイントの確立,及びソフトウェア要素の実現が含まれる。関連データ(文書,

試験記録など)も構成管理の対象に含む。プロジェクトライフサイクルを通して,構成管理の主な目的は,

次のことを提供することである。

−  実行可能な一貫性あるコード再現のために使えるように物理的に保存できるように定義,管理された

ソフトウェア構成(後日のソフトウェア製造又は変更を考慮して)

−  変更管理のためのベース。

−  すべての問題が適切に分析され,承認された変更が正しく実行されることを保証する管理手段。

変更の理由は,例えば,次のことから生じる。

−  機能の安全性低下(規定値以下になったとき)

−  系統的フォールトの経験。

−  安全法規の制定又は改正。

−  機械又はその使用法の変更。

−  総合的な安全要求事項の変更。

−  運転及び保全作業の分析結果(性能が目標レベル以下になったとき)

C.3.4

構成管理及び保存管理

構成管理及び変更管理の手順は,定義し,文書化することが望ましい。この手順には,少なくとも次の

ことを含むことが望ましい。

−  構成を管理するべき品目。

少なくとも,ソフトウェア仕様,ソフトウェアの初期設計及び詳細設計,ソースコードモジュール,

妥当性確認試験の計画,手順及び結果を含む。

−  識別規則(ソースモジュール,ソフトウェアバージョンなどの)

−  変更の取扱い規則(変更要求の記録など)

各構成品目に発生した変更,及び変更に関連する要素のバージョンは,すべて識別できるようにするこ

とが望ましい。

注記 1  この要求の目的は,各品目の開発履歴の追跡を可能にすることである。いつ,なぜ,どんな

変更がなされたかを識別する。

ソフトウェア構成管理は,個別のソフトウェアバージョンを正確に識別できるようにすることが望まし

い。構成管理は,機能安全を達成するために必要なすべての品目(及びそれらのバージョン)に及ぶこと

が望ましい。

ソフトウェア構成に含まれるすべての品目は,試験する前に,又は最終ソフトウェアバージョン評価の

ために評価者から要求される前に,構成管理手順に従って管理することが望ましい。

注記 2  この要求の目的は,すべての要素が正しく構成された状態でソフトウェア評価手順が実施さ

れることを保証することである。その後に行うどんな変更も,評価者が識別できるように,

ソフトウェアのバージョン変更を必要とする。

ソフトウェア及び関連データを保存する手順(バックアップ及び指定期間保存ファイルの保存法)を確


76

B 9961

:2008 (IEC 62061:2005)

  

立することが望ましい。

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

ソフトウェアライフサイクルのすべての技術的側面は,評価者による評価対象である。評価者は,すべ

ての検証報告(試験,分析など)及びソフトウェア開発中に使われたすべての技術文書を調査することを

許されることが望ましい。

注記 1  評価者の介入は,後段階で行うより,仕様作成段階から行うことが望ましい。なぜなら評価

者による決定の影響を小さくできるからである。プロジェクトの資金的及び人間的側面は評

価の対象外である。

注記 2  ソフトウェア開発中に実行したすべての活動の十分な証拠を提供することは,適合性評価申

請人の利益になる。

注記 3  評価者が意見を具申するために必要なことは,自由に調べ,使えるようにすることが望まし

い。

ソフトウェアの適合性評価は,

特定の指定されたソフトウェアバージョンに対して行う。

既に評価され,

前の評価者から最終意見を受けたソフトウェアを変更するときは,前回の評価を今回の評価者に開示し,

評価者が追加の評価活動を実施し,前回意見を更新できるようにすることが望ましい。

注記 4  どんな変更によってもソフトウェアの動きが変わることが有り得る。したがって,評価者に

よる評価は,対象となる正しいソフトウェアバージョンに対してだけ適用できる。

C.8

検証及び妥当性確認のためのレビュー

作成したソフトウェアが仕様書に適合することを確認するために,分析活動及びソフトウェア設計の検

証を行うことが望ましい。

注記 1  この要求の目的は,ソフトウェアの仕様及び設計(予備設計及び詳細設計)が一貫している

ことを保証することである。

外部機関による(評価者による)妥当性確認レビューを,妥当性確認の最終段階に実施することが望ま

しい。

注記 2  これは,ソフトウェア要素が仕様を満足するかどうかを確認するために用いることができる。

各レビュー結果は,文書化し,保管することが望ましい。文書には,レビュー過程で決定したすべての

実施項目のリスト及びレビューの結論(次の活動に進むべきかについての決定)を含むことが望ましい。

レビューで決定した実施項目は,実施状況を監視することが望ましい。

C.9

ソフトウェア試験

C.9.1

一般的な妥当性確認

最初の試験シートを書く前に,試験計画の中で試験戦略を確立することが重要である。この方針には,

採用した実施方針及び試験の目的(試験範囲,試験環境,特定の試験技法,適用する合格基準など)を示

すことが望ましい。

試験の目的は,ソフトウェアのタイプ及び固有の属性に適応するものでなければならない。これらは,

行うべき試験のタイプ(機能試験,限界試験,限界外試験,性能試験,負荷試験,外部装置故障試験,及

び構成試験)を決定するものであり,また,試験がカバーする対象範囲(機能モード試験,安全機能試験,

仕様書の各要素の試験など)を決定するものである。

新しいソフトウェアバージョンの検証には,非回帰性確認試験を含むことが望ましい。

注記  非回帰性確認試験は,ソフトウェア上の変更が予期しないソフトウェアの動きを誘発しないこ

とを確認するために使われる。


78

B 9961

:2008 (IEC 62061:2005)

  

C.9.2

ソフトウェア仕様書の検証:妥当性確認試験

これらの検証の目的は,

目標システム環境におけるソフトウェアに付随する誤りを検出することである。

この種の検証によって検出される誤りには,次のものがある

・  不正確な割込み処理メカニズム。

・  不十分な実行時間。

・  過渡的モード(起動中,入力中,性能低下モードにおける切り換え中など)で作動中のソフトウェ

アからの不正確な応答。

・  リソースへのアクセスの競合又はメモリの組織化の問題。

・  フォールト検出のための統合化試験不能。

・  ソフトウェアとハードウェアとのインタフェース誤り。

・  スタックのオーバフロー。

妥当性確認試験は,ソフトウェアの仕様を検証するための主要な部分である。

試験範囲は,トレーサビリティマトリクス上で明示し,次のことが保証されるようにすることが望まし

い。

−  仕様書の各要素(安全のメカニズムを含めて)が,妥当性確認試験によってカバーされる。

−  すべての運転モードにおけるソフトウェアのリアルタイムの動きが検証される。

さらに,妥当性確認はシステムの運転状態と同じ状態で実施することが望ましい。

注記 1  これによって,実運転でソフトウェアが期待されるように反応することが保証される。これ

は,ハードウェアを破壊するような試験条件の場合(例えば,構成品の物理的なフォールト

をシミュレートできない場合)だけに当てはまる。妥当性確認が意味をもつためには,シス

テム又はサブシステムの実運転状態(すなわち,ソフトウェア及びハードウェアの最終バー

ジョンが目標システムに組み込まれた状態)で実行することが望ましい。他の試験組合せは,

試験の効率を減少させ,試験結果の分析が必要になることがある。

妥当性確認結果は,少なくとも次の内容をカバーし,妥当性確認報告書に記録することが望ましい。

−  妥当性確認を実施したソフトウェア及びシステムのバージョン。

−  実行した妥当性確認試験(入力,出力,試験手順)の記述。

−  結果を実証又は評価するために使ったツール及び設備。

−  各妥当性確認試験の合否結果。

−  妥当性確認査定。見つかった不適合部分,安全に対する影響,妥当性確認結果を採用するかどうかの

決定。

妥当性確認報告は,納入したすべてのソフトウェアバージョンに対して利用可能であるべきであって,

納入した各ソフトウェア要素の最終バージョンに対応することが望ましい。

注記 2  この報告は,試験が本当に実行され,そして結果が正しかった(又は仕様との差異を説明で

きる)ということを証明するために用いることができる。また,将来のソフトウェアバージ

ョン又は他のプロジェクトのために,後日試験をやり直すときに用いることもできる。この

報告書は,納入されたバージョンが,その最終バージョンで妥当性確認されたということを

保証する。この報告書によって,既存のコード(プログラム)を変更するときにすべての妥

当性確認をやり直すことを免除できる。ある場合には,影響解析によって,部分的な妥当性

確認の実施を正当化することができる。

C.9.3

ソフトウェア設計検証:ソフトウェア統合試験


79

B 9961

:2008 (IEC 62061:2005)

この検証は,ソフトウェアモジュールの組合せが正しいか,及びソフトウェア構成品間の相互の関係が

正しいかを検証する。次の種類の誤りを見つけるために用いることができる。

・  変数及び常数の不正な初期化。

・  パラメタ転送誤り。

・  不正改造されたデータ。特にグローバルデータの不正改造。

・  事象及び作動の不正シーケンス。

ソフトウェア統合試験は,次のことを検証できることが望ましい。

−  ソフトウェア実行の正しいシーケンス。

−  モジュール間のデータ交換。

−  性能基準との合致。

−  グローバルデータの不正改造がない。

試験範囲は,トレーサビリティマトリクス上で明示し,実施する試験が,規定された試験目的に一致す

ることを示すことが望ましい。

統合試験の結果は,少なくとも次の内容を含み,ソフトウェア統合試験報告書に記録することが望まし

い。

−  統合ソフトウェアのバージョン。

−  実施した試験(入力,出力,手順)の記述。

−  統合試験の結果及びそれらの評価。

C.9.4

詳細設計の検証:モジュール試験

モジュール試験は,ソフトウェアモジュール,及びソフトウェアモジュールと詳細設計との適合性に焦

点を当てて行う。この活動は,大きくて複雑なソフトウェア要素には不可欠であるが,ここで論じる比較

的小さなソフトウェアに対しては推奨するにとどめる。この段階の検証手順によって,次の種類の誤りを

検出できる。

−  ソフトウェア仕様を満たすことができないアルゴリズム。

−  不正なループオペレーション。

−  不正な論理決定。

−  有効な入力データの組合せを正確に計算できない。

−  誤データ又は不正改造データに対する不正応答。

−  アレイ境界の侵害。

−  不正な計算シーケンス。

−  不十分な精度。

−  アルゴリズムの精度又は性能。

各ソフトウェアモジュールは,モジュールが詳細設計段階で規定された機能を満たすことを検証するた

めに,入力データを用いる一連の試験に付すことが望ましい。

試験範囲は,規定された試験目的と試験結果との一致を示すトレーサビリティマトリクス上に示すこと

が望ましい。


80

B 9961

:2008 (IEC 62061:2005)

  

附属書 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)

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

  

表 D.1−電気・電子部品の故障モード比率の例(続き)

部品

故障モード

典型的な故障モード比率(%)

電磁弁 

励磁しない。 5

非励磁にならない。 15

スイッチング時間の変化。 5

漏れ。 65

その他の故障モード(

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

表 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,附属書 及び附属書 から転載した。

注記 3  多くの電気・電子部品,例えば,抵抗器及びコンデンサは,設計によっては,ここに示す値とは異なる故

障モード比率を示すことがある。

注記 4  電磁弁のその他の故障モードには,次のものがある。

−  切換不能(ゼロ位置又は最終位置に固定)又は不完全な切換(無秩序な中間位置に固定)

−  (入力信号なしに)自然発生的にスイッチがイニシャル位置から変化する。

−  長い期間にわたる漏れ流量の変化。

−  取付け用ねじの破壊又は折損,並びに弁の破裂又は可動構成品の破壊。 
−  サーボ弁及び比例弁に制御できない振舞いを起こす空圧的又は液圧的な障害。

注記 5  故障モード比率に関するその他の情報源として次のものがある。

−  UTE C 80-810 RDF 2000:信頼性データハンドブック−電子部品,印刷基板及び電子機器の信頼性

                        予測の統一モデル。

−  FMD-91, RAC 1991:故障モード・メカニズムの分布。


84

B 9961

:2008 (IEC 62061:2005)

  

附属書 E

参考)

工業環境の SRECS に対して強化する JIS C 61000-6-2 の

電磁イミュニティレベル

序文

この附属書は,参考情報を提供するものであって,要求事項を規定するものではない。

E.1

  工業環境で使用する SRECS の性能試験用に推奨する強化イミュニティレベルを,

表 E.1 に示す。表

E.2

及び

表 E.3 は,表 E.1 を補足するものであって,試験信号の推奨周波数範囲を示す。

表 E.1SRECS に適用する電磁妨害及び強化イミュニティレベル

ポート(注記 を参照)

現象 

規格 

追加の SRECS 性能試験用の強
化イミュニティレベル 
6.4.3 参照)

エンクロージャ

静電気放電(ESD)

JIS C 61000-4-2

6 kV/8 kV 接触/気中放電 

注記 参照)

電磁界

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(注記 及び注記 参照)

交流電源

電圧ディップ及び短時間停

JIS C 61000-4-11 0.5

周期

30  %低減(注記 参照)

電圧変動/停電

JIS C 61000-4-11 250

周期

>95  %低減(

注記 参照)

バースト

JIS C 61000-4-4 4

kV

サージ

JIS C 61000-4-5

線間 1 kV 及び/又は対地 2 kV

注記 参照)

RF 伝導

JIS C 61000-4-6 10

V

指定周波数で

表 E.3 及び注記 参照)

直流電源(

注記 を参照)  バースト

JIS C 61000-4-4 4

kV

サージ

JIS C 61000-4-5

線間 1 kV 及び/又は対地 2 kV

注記 参照)

RF 伝導

JIS C 61000-4-6 10

V

指定周波数で

表 E.3 及び注記 参照)

I/O 信号/制御ライン

バースト

JIS C 61000-4-4

2 kV 3 m 以下のラインに対して

サージ

JIS C 61000-4-5

対地 2 kV

注記 参照)

RF 伝導

JIS C 61000-4-6 10

V

与えられた周波数で

表 E.3 及び注記 参照)

機能接地

バースト

JIS C 61000-4-4 

2 kV


85

B 9961

:2008 (IEC 62061:2005)

表 E.1SRECS に適用する電磁妨害及び強化イミュニティレベル(続き)

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

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

  

附属書 F

参考)

共通原因故障係数(β)の推定法

序文

この附属書は,参考情報を提供するものであって,要求事項を規定するものではない。

F.1

一般事項

この附属書は,サブシステム設計に適用できる CCF 推定の簡単な定量的手法を提供する。

F.2

方法

提案されたサブシステム設計に対して,CCF からの保護のために設計で採用した方策の有効性を評価す

る。

表 F.1 を用いて,適用する項目を識別し,合計得点を計算する。次に表 F.2 を用いて,合計得点から

パーセント値としての共通原因故障係数 β を決定する。

表 F.1CCF 推定のための判定基準

判定項目

番号

得点

隔離及び分離 

各チャネルの 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)

表 F.1CCF 推定のための判定基準(続き)

判定項目

番号

得点

サブシステムは,

附属書 で指定した限界までの(限度値を含む)電磁妨害から

の過酷な影響に耐えるか。

13 9

注記  選択的項目(番号 1a 及び 1b)は,CCF 回避への寄与が最も大きな項目の得点を採用することを意図して

いる。

表 F.1 を用いて,サブシステム設計に影響を与えると考えられる項目の得点を合計し,実現する設計の

総合得点を得る。特定の設計方策(例えば,シールドケーブルでなくフォトカップラを使用)によって同

等の CCF 回避の寄与を得ることを示せるときは,その手段によって同等の CCF 回避が得られるものとし

て得点を付与してよい。

この合計得点から,

表 F.2 を用いて共通原因故障係数(β)を決定する。

表 F.2CCF 係数(β)の推定

合計得点

共通原因故障係数(β

      <35 10

% (0.1)

35− 65

 5 % (0.05)

65− 85

 2 % (0.02)

85−100

1

% (0.01)

得られた β の値は,6.7.8.1 に規定される PFH

D

の計算に用いる。


88

B 9961

:2008 (IEC 62061:2005)

  

附属書 JA

参考)

この規格を理解するための基礎情報

序文

この附属書は,参考情報を提供するものであって,要求事項を規定するものではない。

JA.1

  SRECS の概念

この規格でいう“機能安全(functional safety)

”とは,機械の安全の一部であり,機械安全全体のうち,

本質安全では達成できない部分を安全関連制御機能(SRCF)に依存して達成する安全のことである。

安全関連電気制御システム(SRECS)は,安全機能だけを実行する制御システム,並びに安全機能及び

安全以外の機能の両方を実行するシステムの総称である(

図 JA.1 参照)。

図 JA.1SRECS の範囲(1

広い意味の電気制御システムは,電子制御システム及びプログラマブル電子制御システムを含む。広い

意味の電子制御システムは,プログラマブル電子制御システムを含む。プログラマブル電子制御システム

とは,コンピュータを用いる制御システムのことである(

図 JA.2 参照)。

図 JA.2SRECS の範囲(2

JA.2

  安全性及び信頼性

機能安全は,安全制御機能が正しく作動することによって達成されるので,安全制御機能が正しく作動

する確からしさ(度合)のことを“安全制御機能の安全性(safety)

“安全制御機能の安全インテグリテ

ィ(safety integrity)

”などという。

電気制御システム

電子制御システム

プログラマブル電子制御システム

安全機能だけを
実行する電気制
御システム

安全機能及び安全以外の機能

を実行する(2 種の機能が独立

していない)電気制御システム

SRECS

:安全関連電気制御システム


89

B 9961

:2008 (IEC 62061:2005)

“安全制御機能の安全性”は,

“安全制御機能の信頼性”に依存する部分が大きいが,安全性は信頼性と

同じではない。

“制御機能の信頼性”は,主に制御システムのランダムハードウェア故障確率を問題にする

が,安全性の高い制御システムは,ランダムハードウェア故障確率を下げるだけでは達成されない。

“制御

システムの安全性”には,ランダムハードウェア故障確率が低いことに加え,系統的故障(JA.3 参照)が

少ないことが必要であり,さらに,制御システムが故障しても安全が失われないこと(フォールトトレラ

ンス)が重要である。この観点からは“制御機能の安全性”の方が“制御機能の信頼性”より広い概念で

ある。

一方,

“制御機能の信頼性”は,危険を招く故障(この規格でいう危険側故障)だけでなく,生産機能を

阻害する故障(この規格でいう安全側故障を含む故障)も問題にする。これに対し,

“制御機能の安全性”

は,生産機能の阻害は問題にせず,もっぱら危険を招く故障(危険側故障)だけを問題にする。この観点

からは,

“制御機能の安全性”は,

“制御機能の信頼性”より狭い概念である。

JA.3

  安全インテグリティの概念

この規格は,制御システムの安全性を表す指標として安全インテグリティレベル(SIL)を用いる。この

規格は,制御システムの安全インテグリティレベルを,SIL 1∼SIL 3  に分類する。制御システムの安全イ

ンテグリティは,本来,特定の安全機能に対して定義するものであって,システムの安全インテグリティ

を論じる場合は,そのシステムが実行する安全機能を定義しないと意味がない。

制御システムの安全インテグリティは,ハードウェア安全インテグリティ及びソフトウェア安全インテ

グリティに分類できる。ハードウェア安全インテグリティは,これをさらに確率的安全インテグリティ及

び系統的(確定論的)安全インテグリティに分類できる。

安全インテグリティを構成する確率的要素及び系統的要素の例を,

表 JA.1 に示す。フォールトトレラン

ス性,SFF,DC,共通原因故障は,これら自体には確率的要素はないが,システムの PFH

D

に影響するの

で,この附属書では,これらを確率的要素の範ちゅうに入れた。

表 JA.1−制御機能(システム)の安全インテグリティ要素の例

確率的要素

系統的要素(3.2.22 で定義)

(数値化不可能)

ハードウェア安全イ
ンテグリティ

3.2.20 で定義)

6.6.3 ほかで規定)

・  PFH

D

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.16.4.2 ほかで規定)

・  製造ミス

6.4.16.4.2 ほかで規定)

・  電磁イミュニティ

6.4.3 で規定)

・  フォールトの回避・抑制

6.7.9 ほかで規定)

ソフトウェア安全イ

ンテグリティ

3.2.21 で定義)

なし

・  ソフトウェアの設計・製造ミ

ス(6.106.11 で規定)

・  アルゴリズムミス 
・  プログラムミス

・  コンパイルミス


90

B 9961

:2008 (IEC 62061:2005)

  

JA.4

  この規格と IEC 61508JIS 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 規格群を引用している。ただし,箇条 

用語及び定義の出典としては JIS C 

0508-4

を引用している。その理由は,引用する定義は IEC 61508-4 及び JIS C 0508-4 の間で実質的に等し

く,用語定義では,特に日本語表現の由来を示すことに意義があるからである。

JA.5

  この規格と JIS B 9705-1ISO 13849-1)との関係

JIS B 9705-1:2000

ISO 13849-1:1999 対応)は,制御機能の安全性をカテゴリ(B,1,2,3 及び 4)で

表現している。故障は起こるものであるという前提で,制御機能の安全性(カテゴリ)を,主にフォール

トトレランス性(故障しても安全が保たれる性質)で分類している。

しかし,改正された ISO 13849-1:2006 は,故障しないことの要求も強く反映する規格になった。PFH

D

の要求を追加し,PFH

D

の値によって PL を定義している。PL には,構成チャネルの危険側平均故障時間

MTTFdDC などの要素も関係するが,PL は,究極的にシステムの PFH

D 

によって

表 JA.3 のように定義

される。

表 JA.3ISO 13849-1:2006 における PL と PFH

D

との対応

PL (performance level)

PFH

D

 PL に相当する SIL(参考)

PL a

10

5

  ≦ PFH

D

  < 10

4

なし

PL b

3×10

6

  ≦  PFH

D

  < 10

5

 SIL

1(10

6

  ≦ PFH

D

  < 10

5

PL c

10

6

  ≦  PFH

D

  <  3×10

6

PL d

10

7

  ≦ PFH

D

  < 10

6

 SIL

2(10

7

  ≦  PFH

D

  < 10

6

PL e

10

8

  ≦ PFH

D

  < 10

7

 SIL

3(10

8

  ≦  PFH

D

  < 10

7

JA.6

  安全側故障比率

この規格では,安全側故障比率(SFF)は,SIL 付与限界を制約する要素の一つである(

表 参照)。

システム又はサブシステムのハードウェア安全インテグリティを高めるために,SFF を高めることが重


91

B 9961

:2008 (IEC 62061:2005)

要である。そのために,この規格は,次の二つの設計技法を重視している。

a)

部品そのものの SFF を高める(部品故障の影響が安全側に作用するように設計する。

b)

危険側故障を検出し,検出したらシステムを安全側へ導く制御(フォールト反応)を行う。

a) 

の説明

部品故障には,その故障がシステムの安全機能喪失を導くもの(危険側故障)と,そうでないもの(安

全側故障)とがある。システムの安全インテグリティを高めるためには,要素が故障してもシステムが安

全に保たれる比率を高めることが有効である。この規格では,すべての故障が起こる率(分母)と安全側

故障数が起こる率(分子)との比を SFF(safe failure fraction: SFF)と定義する。SFF を高めることによっ

てサブシステムの PFH

D

を小さくすることができる(3.2.42 参照)

b) 

の説明

SFF を高めるために,部品そのものの故障が安全側故障となる比率を高めることが重要であるが,故障

を検出して,潜在的な危険側故障がサブシステムの危険側故障として顕在化しないように制御することも

大きな効果をもつ。危険側故障の発生を検出して,危険事象が起こる前に安全制御(例えば,運転停止)

を行うことができれば,検出した故障は,サブシステムレベルでは安全側故障とみなすことができる。

このための故障検出は,診断テストによって行われる。この規格では,部品の危険側故障を診断によっ

て検出できる割合を診断率(diagnostic coverage: DC)と定義し,サブシステムの PFH

D

を計算するときに

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)

  

附属書 JB

参考)

PFH

D

の計算式の考察など

序文

この附属書は,サブシステムの危険側故障に関する事項を理解するための参考文書であって,要求事項

を規定するものではない。

JB.1

  附属書 JB の目的

この附属書の目的は,次のとおりである。

a)

6.7.8.2

の PFH

D

1)

  計算式(A),(B),(C),(D1)及び(D2)を検証する(JB.3JB.6)。

b)

自己診断と PFH

D

との関係を確認する(JB.5JB.6

c)

プルーフテストと PFH

D

との関係を確認する(JB.4 及び JB.6

d)

離散的作動要求モードにおける PFH

D

の意味を考察する(JB.7

e)

PFD

2)

  の計算式を示す(JB.8)。

f)

フォールトトレランスの概念を確認する(JB.9

PFH

D

は,連続モード

3)

  におけるリスク評価に用いることができる。

PFD は,離散的作動要求モード

4)

  におけるリスク評価に用いることができる。

なお,PFH

D

及び PFD の計算法は,この附属書が示す方法だけに限るものではない。アーキテクチャ及

び前提条件が異なれば計算法も異なる。この附属書は,特定のアーキテクチャ(6.7.8.2)に対する特定の

前提条件下での計算法を示しているが,異なるアーキテクチャ及び異なる条件における計算のためにも参

考になると考える。

1)

  PFH

D

 (Probability of Dangerous Failure per Hour)は,SRECS 又はそのサブシステムが,1 時間の間

に危険側故障を起こす平均確率である。連続モードにおいて,サブシステムの危険側故障が直

ちに危険事象の発生を招くとすれば,PFH

D

  は危険事象が 1 時間の間に発生する確率(無次元)

になる。

この規格では,PFH

D

と  λ

D

との関係を,次のように定義している。

PFH

D

 = λ

D 

× 1 時間

2)

  PFD (Probability of Failure on Demand)は,離散的作動要求モードにおいて,作動要求があったと

きに安全制御機能が作動しない確率(無次元)である。IEC 61508 規格群では,低頻度作動要

求モードの SIL を PFD で定義している。

3)

  連続モードとは,安全制御機能の作動要求が連続的に存在するモードである。すなわち,安全

制御機能が連続的に作動しなければならないモードである。例えば,自動車のハンドル機能は,

一瞬たりとも不作動,誤作動が許されないので,連続モードの SRCF である(自動車は,機械

ではないが。

4)

  離散的作動要求モードとは,安全制御機能の作動要求が離散的(散発的)に起こるモードであ

る。例えば,自動車のブレーキは,離散的作動要求モードの SRCF である。人がブレーキを踏

むことが,安全制御機能に対する作動要求である。

この附属書では,高頻度作動要求モードと低頻度作動要求モードとを総称して離散的作動要


93

B 9961

:2008 (IEC 62061:2005)

求モードという。

JB.2

  自己診断及びプルーフテストのタイミング

サブシステムの危険側故障率  λ

D

  を小さくするために,自己診断及び/又はプルーフテストがしばしば

採用される。自己診断では,診断率 DC に相当する割合(検出率)で危険側故障を検出する。診断によっ

て検出できない(1−DC)の割合の危険側故障は,プルーフテスト(行う場合)で 100  %検出して,修復

する。

記号の意味を,次のとおりとする。

T

1

:プルーフテスト間隔(時間)

T

2

:自己診断間隔(時間)

(周期的診断の場合)

T

D

:作動要求間隔(時間)

(離散的作動要求モードの場合)

T

1

T

2

  及び T

D

  のタイミングの概念を,図 JB.1 に示す。

この附属書では,いかなる場合も,T

1

  >  T

2

  である。例えば,T

2

  は秒単位から日単位以下の短い時間

であり,T

1

  は日単位から年単位以上の長い時間であると想定する。

T

D

  は,離散的作動要求モードだけで取り扱う。連続モードでは考慮しない。T

D

  には規則性がなく,T

D

T

2

であると仮定する。T

D

  と T

1

  との関係は,次の二つのケースに分けて考察する(JB.9)。

高頻度作動要求モード:  T

1

 / 2  >  T

D

低頻度作動要求モード:  T

1

 / 2  <  T

D

IEC 61508

規格群では,低頻度作動要求モードの条件を,T

1

 / 2  <  T

D

,又は年 1 回以下としている。

図 JB.1T

1

T

2

,及び T

D 

のタイミングの概念

 

T

2

T

2

T

D

T

1

A

:高頻度作動要求モード(T

/ 2 

  T

D 

)

T

1 

/ 2

プルーフテスト

プルーフテスト

T

2

    T

2

T

D

B

:低頻度作動要求モード(T

1

 / 2

T

D 

 

T

2

T

1

T

1 

/ 2

プルーフテスト

プルーフテスト


94

B 9961

:2008 (IEC 62061:2005)

  

JB.3

  サブシステム A(フォールトトレランス 0,診断機能なし)の PFH

D

6.7.8.2.2 参照)

JB.3.1

  アーキテクチャ(図 JB.2 参照)

サブシステム A は,

診断機能をもたない,

フォールトトレランスが 0 の非冗長系アーキテクチャである。

図 JB.2−サブシステム の論理的表現

JB.3.2

  PFH

D

の計算

サブシステム A は,診断機能をもたないから危険側故障を検出できない。すべての要素及び部品の危険

側故障がサブシステムの危険側故障(安全制御機能の喪失)につながるから,サブシステム A の危険側故

障率(1 時間中に故障する確率)PFH

DssA

  は,次の式(3-1)及び式(3-1)′で計算できる。

λ

DssA

 = λ

De1

 + ...+ λ

Den

(1/時間)   (3-1)   (A)

PFH

DssA

 = λ

DssA

 × 1 時間(無次元)   (3-1)′  (A)′

λ

DssA 

の次元は“1/時間”である。λ

DssA

に 1 時間を乗じて PFH

DssA 

としたのは,PFH

DssA 

を無次元値にし

ただけのことである(以下,同様。

JB.3.3

  プルーフテストの効果

プルーフテストは,故障を発見して修復を行うものである。プルーフテストによって故障を検出して修

復しても,その後の故障率が下がる訳ではないから,サブシステム A においては,プルーフテスト間隔

T

1

  は,PFH

DssA

  に関与しない。

注記  サブシステム A を離散的作動要求モードで用いる場合は,T

1 

/ 2

<  T

D

であれば,プルーフテス

トは PFD を下げる効果をもつ。この条件では,PFD を次の式で表すことができる(JB.8 参照)

PFD

ssA

 = λ

DssA

 × T

1 

/ 2

JB.4

  サブシステム B(フォールトトレランス 1,診断機能なし)の PFH

D

6.7.8.2.3 参照)

JB.4.1

  アーキテクチャ(図 JB.3 参照)

サブシステム B は,並列冗長系であって,フォールトトレランス 1 をもつ。サブシステム B が危険側故

障となるのは,二つのサブシステム要素の危険側故障が重なるときである。一方のサブシステム要素が故

障しても他方のサブシステム要素が健全であれば,

サブシステム B の安全制御機能は維持される。

しかし,

サブシステム B は,診断機能をもたないので,プルーフテストを行うまでは一つ目の故障が起こったこと

を知らずに運転をすることになる。

サブシステム B のプルーフテストに関して,次の三通りの方式が考えられる。

a)

設計寿命が尽きるまでプルーフテストを行わない[方式 a)]

b)  T

1

の間隔でプルーフテストを行い,テスト及び修復中は運転を休止する。故障を修復して,二つのサ

ブシステム要素が健全であることを確認してから運転を再開する(オフラインプルーフテスト)

[方式

サブシステム要素 1

λ

De1

サブシステム要素 n

λ

Den

サブシステム A(フォールトトレランス 0,診断機能なし)


95

B 9961

:2008 (IEC 62061:2005)

b)]。

c)

T

1 

の間隔でプルーフテストを行い,テスト中及び修復中も健全なサブシステム要素に依存して運転を

継続する(オンラインプルーフテスト)

[方式 c)]

サブシステム B の PFH

D

計算式は,プルーフテストの方式によって異なる。6.7.8.2.3 に示す式(B)は,上

記の a)  及び b)  に通用する式である。

図 JB.3−サブシステム の論理的表現

JB.4.2

  方式 a)及び b)の PFH

D

の計算

間隔 T

1

で運転を休止するプルーフテストを行い,二つのサブシステム要素が健全であることを確認して

から運転を再開するという前提では,

サブシステム B の PFH

DssB

は,

次の式(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)

にはプルーフテスト間隔

T

1 

が関与しており,頻繁にプルーフテストを行うほどサブシステム

B

の危険側故障率が小さくなる。プルーフテストを行わない場合は,設計寿命を

T

1 

として計算する。

(4-1)

は,第

1

項及び第

2

項からなっている。第

1

項は,共通原因故障以外の危険側故障(以下,この

附属書では,文脈から明白な場合は,共通原因故障以外の故障を単に“故障”又は“危険側故障”と表記

する。

)の

1

時間当たりの確率であり,第

2

項は危険側の共通原因故障の

1

時間当たりの確率である。

(

4-1

)

の第 項の説明

(4-1)

の第

1

項は,各サブシステム要素の共通原因故障以外の危険側故障が重なる

1

時間当たりの確率

を示している。サブシステム要素

1

の全危険側故障率から共通原因故障率を差し引いた値を近似的に

λ

De1

(1−β)

とする。同様に,サブシステム要素

2

の共通原因故障以外の危険側故障率を

λ

De2

(1−β)

とする。プルー

フテスト間隔

T

1

の間にサブシステム要素

1

又は

2

が共通原因故障以外の危険側故障を起こす確率

(無次元)

は,

λ

De1

(1−β)  T

1

,又は

λ

De2

(1−β)  T

1

である。

T

1 

の間に両方のサブシステム要素が共通原因故障以外の危険

側故障を起こす確率は,各要素の故障確率の積になるから,これは,

λ

De1

(1−β)  T

1

×

λ

De2

(1−β)  T

1 

となる。

これを

T

1

で除せば,両方のサブシステム要素の共通原因故障以外の危険側故障が重なる

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)

  

外では正である。近似の誤差が

λ

DssB

を大きく見積もる方向に偏るので,この近似は安全側に偏っている。

(

4-1

)

の第 項の説明

共通原因故障は,二つのサブシステム要素に同時に起こるので,共通原因故障が起こると直ちにサブシ

ステム

B

が危険側故障になる。共通原因故障係数

β

の定義によって,共通原因故障率は,各サブシステム

要素の危険側故障率の平均値に共通原因故障係数

β

を乗じたものである。これが第

2

項である。共通原因

故障に対してはフォールトトレランスがない。サブシステム

B

のフォールトトレランスが

1

であるといっ

ても,共通原因故障のフォールトトレランスは

0

である。

JB.4.3

  方式 c

)

の PFH

D 

の計算

(4-1)

は,運転を休止してプルーフテストを行うこと(オフラインテスト)を前提にしている。

運転を休止せずにプルーフテストを行い,一方のサブシステム要素に起こった危険側故障を修復してい

る間(

MTTR

1

又は

MTTR

2 

)も他方のサブシステム要素に依存して(フォールトトレランス

0

の状態で)

運転を続ける場合(オンライン修理)は,サブシステム

B

の危険側故障率は,次の式

(4-2)

及び

(4-2)′

で与え

られる。

λ

DssB

′ = (1−β)

2

 × λ

De1

 × λ

De2

 × ( T

1

 + MTTR

1

 + MTTR

2

 ) + β (λ

De1

 + λ

De2

) /2

1/

時間)

  (4-2)

PFH

DssB

 = λ

DssB

′ × 1

時間

(無次元)

  (4-2)′

ただし,方式

c)

の場合であっても,

MTTR

1 

及び

MTTR

2

T

1

に対して無視できるほど小さい場合(

T

1 

半年以上で

MTTR

1 

及び

MTTR

2 

1

日以下の場合)には,当然,式

(4-1)

は有効である。

(4-2)

の第

1

項は,次のように説明できる。

サブシステム要素

1

が共通原因故障以外の危険側故障を起こす

1

時間当たりの確率は,

(1−β) × λ

De1

1/

時間)である。よって,

T

1

の間にサブシステム要素

1

が故障する確率は,

(1−β  ) ×λ

De1

×T

1

である。サブシ

ステム要素

1

が,故障してから修復が完了するまでの平均時間は,

T

1

 / 2+ MTTR

1

である。この平均ダウン

タイム中にサブシステム要素

2

が共通原因故障以外の危険側故障を起こす確率は,

(1−β) × λ

De2

 × (T

1

 / 2+

MTTR

1

)

(無次元)である。よって,サブシステム要素

1

が共通原因故障以外の危険側故障を起こし,続い

T

1

+MTTR

1

の間にサブシステム要素

2

が共通原因故障以外の危険側故障を起こす

1

時間当たりの確率は,

これらの積を

T

1

で除して,

(1−β) × λ

De1

 × (1−β) × λ

De2

 × (T

1

 / 2+ MTTR

1

)

1/

時間)となる。

同様に考えて,サブシステム要素

2

が先に共通原因故障以外の危険側故障を起こし,続いてサブシステ

ム要素

1

が共通原因故障以外の危険側故障を起こす

1

時間当たりの確率は,

(1−β) ×λ

De1

 × (1−β) ×λ

De2

 × (T

1

 /

2+ MTTR

2

)

1/

時間)となる。

サブシステム

B

が共通原因故障以外の危険側故障を起こす

1

時間当たりの確率は,これらの和であるか

ら式

(4-2)

の第

1

項となる。

(4-2)

の第

2

項は,式

(4-1)

の第

2

項と同じである。

JB.5

  サブシステム C(フォールトトレランス 0,診断機能あり)の PFH

D

6.7.8.2.4 参照)

JB.5.1

  アーキテクチャ(図 JB.4 参照)

サブシステム

C

は,サブシステム

A

に診断機能を付けたものである。

サブシステム

C

は,診断によって危険側故障を検出でき,検出したら,直ちに運転停止などのフォール

ト反応が働くことを前提とする。

サブシステム

C

においては,診断によって検出できる危険側故障は,条件によってはサブシステム

C

危険側故障にならない。

サブシステム

C

の診断に関しては,次の二通りの方式が考えられる。


97

B 9961

:2008 (IEC 62061:2005)

a

)

連続診断(

T

2

 = 0

)とし,故障を検出したら直ちに運転を停止する。

b

)

周期的診断(診断間隔

T

2

)とし,故障を検出したら直ちに運転を停止する。

サブシステム

C

PFH

D

計算は,診断の方式によって異なる。6.7.8.2.4 に示す式

(C)

は,a

)

の場合に通用

する式である。

図 JB.4−サブシステム の論理的表現

JB.5.2

  方式 a

)

連続診断)の PFH

D

の計算

診断を連続的に行う(

T

2

 = 0

)と仮定し,危険側故障を検出したら,直ちにフォールト反応によって

100

安全側(運転停止など)へ制御を行うものとすれば,診断によって検出できる危険側故障は,サブシステ

C

の危険側故障にならない。したがって,連続診断で検出できる危険側故障は,サブシステム

C

の危険

側故障率に含めない。

DC

の定義から,診断によって検出できない危険側故障がすべての危険側故障に対して占める比率は,

1−DC

である。診断によって検出できない危険側故障だけが,サブシステム

C

の危険側故障になるので,

サブシステム

C

PFH

D

は,次の式

(5-1)

及び式

(5-1)′

で計算できる。

λ

DssC

 = λ

De1

 (1−DC

1

) +…..+ λ

Den

 (1−DC

n 

)

1/

時間)

(5-1)    (C) 

PFH

DssC

 = λ

DssC

 × 1

時間

(無次元)

   (5-1)′  (C)′

JB.5.3

  方式 b

)

周期的診断)の PFH

D

の計算

周期的診断の場合は,診断によって検出できる故障であっても,故障が起こってからそれが検出される

まで(最大

T

2 

)の間は,サブシステムが安全機能を失ったまま運転を続けることになる。したがって,

T

2

の間に起こる検出できる危険側故障の率をサブシステム

C

の危険側故障率に加えなければならない。

T

2

という時間内に,検出できる危険側故障が起こる確率は,

(λ

De1

 ×DC

1

 +

・・・・・・・

 + λ

Den

 ×DC

n 

) ×T

2

(無次

元)である。

1

時間当たりの確率は,これを

T

2

で除して,

(λ

De1

 ×DC

1

 +

・・・・・・・

 + λ

Den

 ×DC

n

)

1/

時間)と

なる。

したがって,

T

2 

0

でない場合のサブシステム

C

PFH

D

は,次の式

(5-2)

及び式

(5-2)′

のようになる。

λ

DssC

′ = λ

De1

 (1−DC

1

) +

・・・・・・・

 + λ

Den

 (1−DC

n

)

  (λ

De1

 ×DC

1

 +

・・・・・・・

 + λ

Den

 ×DC

n 

)

          = λ

De1

 +

・・・・・・・

 + λ

Den

1/

時間)

   (5-2)

PFH

DssC

′ = λ

DssC

′ × 1

時間

(無次元)

  (5-2)′

(5-2)

は,診断機能をもたないサブシステム

A

の式

(3-1)

と同じである。すなわち,周期的診断には,サ

ブシステム

C

PFH

D

を下げる効果はない。

注記  サブシステム

C

を離散的作動要求モードで用いる場合は,周期的診断であっても

T

2 

/ 2

  T

D

サブシステム要素

1

λ

De1

 

サブシステム要素

n

λ

Den

 

サブシステム C(フォールトトレランス 0,診断機能あり)

診断機能


98

B 9961

:2008 (IEC 62061:2005)

  

であれば診断によって

PFD

を下げる効果がある。この条件では,

PFD

を次の式で表すことが

できる(JB.9 参照)

JB.3.3 

注記も参照。)

PFD

ssC

 = λ

DssA

 ×T

2 

/ 2

JB.6

  サブシステム D(フォールトトレランス 1,診断機能あり)の PFH

D

6.7.8.2.5 参照)

JB.6.1

  アーキテクチャ(図 JB.5 参照)

サブシステム

D

は,サブシステム

B

に診断機能を追加したものである。サブシステム

D

が危険側故障

になるのは,二つのサブシステム要素が,共に危険側故障(二重故障)になるときである。

サブシステム

D

は,診断に関連して,次の四通りの方式が考えられる。

a

)  T

2 

の間隔で診断を行う。一つ目の危険側故障を検出しても健全なサブシステム要素に依存して運転を

続ける。故障したサブシステム要素は直ちに修復する。

MTTR

(平均修復時間)が

T

2 

に対して無視で

きるほど小さい(又は,一つ目の危険側故障の検出と同時に運転を停止し故障を修復してから運転を

再開する。

b

)  T

2

の間隔で診断を行う。一つ目の危険側故障を検出しても健全なサブシステム要素に依存して運転を

続ける。故障したサブシステム要素は,一定の時間(

MTTR

)内に修復する。

MTTR

T

2 

に対して無

視できないほど大きい。

c

)

連続診断を行う。一つ目の危険側故障を検出しても運転を続ける。故障したサブシステム要素は検出

と同時に修復を完了する。

MTTR

0

とみなせるほど小さい。

d

)

連続診断を行い,一つ目の危険側故障を検出しても運転を続ける。故障したサブシステム要素は一定

の時間(

MTTR

)内に修復する。

また,サブシステム

D

のプルーフテストに関連して,次の二通りの方式が考えられる。

e

)  T

1

の間隔で,運転を休止するプルーフテスト(オフラインテスト)を行う。一つ目の危険側故障を検

出したら運転を停止する。その故障を修復して二つのサブシステム要素が健全であることを確認して

から運転を再開する。

f

)  T

1 

の間隔で,運転を休止しないプルーフテスト(オンラインテスト)を行う。一つ目の危険側故障を

検出しても運転を停止せず,故障したサブシステム要素の修復中(

MTTR

)も健全なサブシステム要

素に依存して運転を継続する。

サブシステム

D

PFH

D

の計算式は,診断方式及びプルーフテスト方式によって異なる。6.7.8.2.5 に示

す式

(D1)

は,上記の a

)

及び e

)

の方式に通用する式である。

JB.6

では,異なる設計のサブシステム要素を用いる場合の

PFH

D

計算だけを扱う。同じ設計のサブシス

テム要素を用いる場合は,以後のすべての計算式において,

λ

De1

 =λ

De2

DC

1

 = DC

2

と置けば得られる。


99

B 9961

:2008 (IEC 62061:2005)

図 JB.5−サブシステム の論理的表現

JB.6.2

  診断方式 a

)

周期的診断,MTTR = 0)及びプルーフテスト方式 e

)

MTTR = 0

の PFH

D

の計算

この場合,サブシステム

D

PFH

D

は,次の式

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

PFH

DssD

 = λ

DssD

 × 1

時間

(無次元)

 (6-1)′  (D1)′

ここに,

  λ

De1

サブシステム要素

1

の危険側故障率

DC

1

: サブシステム要素

1

の診断率

λ

De2

サブシステム要素

2

の危険側故障率

DC

2

: サブシステム要素

2

の診断率

サブシステム

D

の危険側故障率は,共通原因故障以外の危険側故障率と共通原因故障率との和である。

サブシステム

D

の共通原因故障以外の危険側故障率は,一方のサブシステム要素が共通原因故障以外の危

険側故障を起こし,この故障が残存している間に他方のサブシステム要素が共通原因故障以外の危険側故

障を起こす

1

時間当たりの確率である。共通原因故障率は,共通原因によって二つのサブシステム要素が

共に危険側故障を起こす

1

時間当たりの確率である。

(6-1)

は,第

1

項及び第

2

項から成り立っている。第

1

項は,

(1−β)

2

が掛かる部分であって共通原因故

障以外の危険側故障率である。第

2

項は

β

が掛かる部分であって共通原因故障率である。

次に,式

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

  

ケース

1

先に,診断によって検出できる危険側故障が起こり,この故障が残存している間に次の危険側故障が他

方のサブシステム要素で起こる場合をケース

1

とする。ケース

1

は,次の二つのケースに分かれる。

ケース

1a

:  診断によって検出できる危険側故障がサブシステム要素

1

で先に起こる。

ケース

1b

:  診断によって検出できる危険側故障がサブシステム要素

2

で先に起こる。

ケース

2

先に,診断によって検出できない故障が起こり,この故障が残存している間に次の危険側故障が他方の

サブシステム要素で起こる場合をケース

2

とする。ケース

2

は,次の二つのケースに分かれる。

ケース

2a

:  診断によって検出できない危険側故障がサブシステム要素

1

で先に起こる。

ケース

2b

:  診断によって検出できない危険側故障がサブシステム要素

2

で先に起こる。

1

項の前半(

T

2

が関与)は,ケース

1

1a

1b

)の危険側故障率である。

1

項の後半(

T

1

が関与)は,ケース

2

2a

2b

)の危険側故障率でである。

第 項前半の説明(ケース 1

1

項前半(ケース

1

)は,先に起きた検出できる危険側故障が,周期

T

2

の診断機能によって検出され,

運転が停止されるまでの時間

T

3

内に他方のサブシステム要素が危険側故障を起こす

1

時間当たりの確率

である。

T

3

は一定しないが,その平均値(平均ダウンタイム)は

T

2

 / 2

である(

図 JB.6 参照。)。

ケース

1

の危険側故障率は,ケース

1a

の危険側故障率と,ケース

1b

の危険側故障率との和である。次

にケース

1

の危険側故障率を求める。

 
 
 

図 JB.6−診断による故障検出タイミング

ケース 1a

サブシステム要素

1

が,検出できる危険側故障を起こす

1

時間当たりの確率

P

1a1

1/

時間)は,次の式

(6-2)

で与えられる。

P

1a1

 = (1−β) × λ

De1

 × DC

1

1/

時間)

   (6-2)

t

3

の平均値

T

2

 / 2

の間にサブシステム要素

2

が危険側故障を起こす確率

P

1a2

(無次元)は,次の式

(6-3)

で与えられる。

P

1a2

 = (1−β) × λ

De2

 × T

2

 / 2

(無次元)

  (6-3)

したがって,ケース

1a

が起こる

1

時間当たりの確率

P

1a

1/

時間)は,次の式

(6-4)

で与えられる。

P

1a

 = P

1a1

 × P

1a2

 = (1−β) × λ

De1

 × DC

1

 × (1−β) × λ

De2

 × T

2

 / 2

      = (1−β)

2

 × λ

De1

 × λ

De2

 × DC

1

 × T

2

 / 2

1/

時間)

   (6-4)

ケース 1b

ケース

1b

の危険側故障率は,ケース

1a

と同様に考えて,次の式

(6-5)

となる。

P

1b

 = (1−β)

2

 × λ

De1

 × λ

De2

 × DC

2

 × T

2

 / 2

1/

時間)

   (6-5)

診断

診断

T

2

T

3

この間に他方のサブシステ

ムに危険側故障が発生する

と,サブシステム D が危険

側故障になる。

一つ目の,検出でき

る危険側故障発生


101

B 9961

:2008 (IEC 62061:2005)

ケース 1(ケース 1a+ケース 1b

ケース

1

が起こる

1

時間当たりの確率は,ケース

1a

及びケース

1b

の確率の和であるから,次の式

(6-6)

で与えられる。

P

1

 = (1−β)

2

 × λ

De1

 × λ

De2

 × (DC

1

DC

2

) × T

2

 / 2

1/

時間)

  (6-6)

(6-6)

が,式

(6-1)

の第

1

項の前半である。

第 項後半の説明(ケース 2

1

項後半は,一方のサブシステム要素に一つ目の検出できない危険側故障が発生してから,プルーフ

テストが行われるまでの時間

T

4 

内に他方のサブシステム要素が危険側故障を起こす

1

時間当たりの確率

である。

T

4 

は一定しないが,その平均値(平均ダウンタイム)は

T

1 

/2

である(

図 JB.7 参照)。

ケース

2

の危険側故障率は,ケース

2a

の危険側故障率とケース

2b

の危険側故障率との和である。

次にケース

2

の危険側故障率を求める。

 
 
 

図 JB.7−プルーフテストによる故障検出タイミング

ケース 2a

サブシステム要素

1

が,診断では検出できない危険側故障を起こす

1

時間当たりの確率

P

2a1

1/

時間)

は,次の式

(6-7)

で与えられる。

P

2a1

 = (1−β) × λ

De1

 × (1−DC

1

)

1/

時間)

  (6-7)

サブシステム要素

1

の平均ダウンタイム(

T

1

 /2

)中にサブシステム要素

2

が危険側故障を起こす確率

P

2a2

(無次元)は,次の式

(6-8)

で与えられる。

P

2a2

 = (1−β) × λ

De2

 × T

1

 / 2

(無次元)

  (6-8)

したがって,ケース

2a

が起こる

1

時間当たりの確率

P

2a

1/

時間)は,次の式

(6-9)

のようになる。

P

2a

 = P

2a1

 × P

2a2

      = (1−β) × λ

De1

 × (1−DC

1

) × (1−β) × λ

De2

 × T

1

 / 2

      = (1−β)

2

× λ

De1

× λ

De2

 × (1−DC

1

) × T

1

 / 2

1/

時間)

  (6-9)

ケース 2b 

ケース

2b

の危険側故障率は,ケース

2a

と同様に導かれて次の式

(6-10)

となる。

P

2b

 = (1−β)

2

 × λ

De1

 × λ

De2

 × (1−DC

2

) × T

1

 / 2

1/

時間)

  (6-10)

ケース 2(ケース 2a +ケース 2b

ケース

2

の危険側故障率は,

ケース

2a

及びケース

2b

の危険側故障率の和であるから,

(6-9)

及び式

(6-10)

の和であって,次の式

(6-11)

になる。

P

2

 = P

2a 

+

 

P

2b

      = (1−β)

2

 × λ

De1

 × λ

De2

 × (2−DC

1

DC

2

) × T

1

 / 2

1/

時間)

  (6-11)

これが式

(6-1)

の第

1

項の後半である。

プルーフテスト

プルーフテスト

T

1

T

4

 

この間に他方のサブシス

テムに危険側故障が発生

すると,サブシステム D

が危険側故障になる。

診断によって検出できない

一つ目の危険側故障発生


102

B 9961

:2008 (IEC 62061:2005)

  

第 項の説明

(6-1)

の第

2

項は,共通原因故障率である。共通原因故障は二つのサブシステムに同時に起こる。共通

原因故障率は,各サブシステム要素の危険側故障率の平均値に共通原因故障比率

β

を乗じたものである。

これが第

2

項である。

JB.6.3

  診断方式 b

)

周期的診断,MTTR 

 0

及びプルーフテスト方式 f

)

MTTR 

 0

の PFH

D

の計算

(6-1)

は,

MTTR

 = 0

とみなせるオンライン修理(又はオフライン修理)を想定した式である。診断又は

プルーフテストによって一つ目の危険側故障を検出した後,これを修復している間(

MTTR

)も健全なサ

ブシステム要素に依存して運転を継続する場合は,式

(6-1)

の第

1

項の前半(診断関連部分)及び後半(プ

ルーフテスト関連部分)を変更しなければならない。

第 項前半(診断関連部分)の変更

診断の方式 b

)

の場合は,診断によってサブシステム要素

1

の危険側故障を検出した後,これを修復し

ている間(

MTTR

1

)もサブシステム要素

2

に依存して運転を続けるので,式

(6-3)

∼式

(6-6)

を次のように変

更する。

P

1a2

′ = (1−β) ×λ

De2

 (T

2

 / 2 + MTTR

1

)

(無次元)

  (6-3)′

P

1a

′ = P

1a1

 × P

1a2

        ={(1−β) × λ

De1

 × DC

1

 }× {(1−β) × λ

De2

 ×(T

2

 / 2 + MTTR

1

)}

        = (1−β)

2

 × λ

De1

 × λ

De2

 × DC

1

 × (T

2

 / 2 + MTTR

1

 )  (6-4)′

P

1b

′ = (1−β)

2

 × λ

De1

 × λ

De2

 ×DC

2

 × (T

2

 / 2 + MTTR

2

 )  (6-5)′

P

1

′ = P

1a

′ + P

1b

      = (1−β)

2

 × λ

De1

 × λ

De2

 × {(DC

1

 + DC

2

 ) × T

2

 / 2 + (DC

1

 × MTTR

1

 + DC

2

 × MTTR

2

)}  (6-6)′ 

(6-6)′

の値は,式

(6-6)

よりも

MTTR

1 

及び

MTTR

2 

が掛かる部分だけ大きい。

第 項後半(プルーフテスト関連部分)の変更

プルーフテストの方式 f

)

(オンラインプルーフテスト)の場合で,サブシステム要素の

MTTR

T

1

 / 2

対して無視できないほど大きいときは,式

(6-8)

∼式

(6-11)

を次のように変更する。

P

2a2

′= (1−β) × λ

De2

 × (T

1

 / 2 + MTTR

1

)

(無次元)

  (6-8)′

P

2a

′ = P

2a1

 × P

2a2

        = (1−β) × λ

De1

 × (1−DC

1

) × (1−β) × λ

De2

 × (T

1

 / 2 + MTTR

1

)

        = (1−β)

2

× λ

De1

× λ

De2

 × (1−DC

1

) × (T

1

 / 2 + MTTR

1

)

1/

時間)

  (6-9)′

P

2b

′ = (1−β)

2

 × λ

De1

 × λ

De2

 × (1−DC

2

) ×( T

1

 / 2 + MTTR

2

)

1/

時間)

  (6-10)′

P

2

′ = P

2a

′ + P

2b

      = (1−β)

2

 × λ

De1

 × λ

De2

 × {(2−DC

1

DC

2

) × T

1

 / 2 + (1−DC

1

) × MTTR

1

 + (1−DC

2

) × MTTR

2 

}

1/

時間)

   (6-11)′

JB.6.4

  診断方式 c

)

連続診断,MTTR = 0)及びプルーフテスト方式 e

)

MTTR = 0

の PFH

D

の計算

連続診断を行い,故障を検出したら直ちに故障を修復する(又は,運転を停止してオフライン修理する)

場合である。連続診断(

T

2

 = 0

)なので,ケース

1

の検出される危険側故障は,サブシステム

D

の危険側

故障につながらない。ケース

2

の診断では検出できない危険側故障だけが,サブシステム

D

の危険側故障

につながる。したがって,式

(6-1)

において

T

2

 = 0

と置くことによって,次の式

(6-1)′

が得られる。

λ

DssD

′=  λ

De1

 × λ

De2

 (2 − DC

1

 − DC

2

) × T

1

 / 2 + β ( λ

De1

 + λ

De2

 ) / 2

1/

時間)

 (6-1)′  (D1)′

JB.6.5

  診断方式 d

)

連続診断,MTTR 

 0

及びプルーフテスト方式 f

)

MTTR 

 0

の PFH

D

の計算

連続診断を行い,故障修復をオンラインで行う場合(平均修復時間を

MTTR

1

及び

MTTR

2

とする。

)であ


103

B 9961

:2008 (IEC 62061:2005)

る。連続診断(

T

2

 = 0

)なので,ケース

1

の検出される危険側故障は,サブシステム

D

の危険側故障につ

ながらない。ケース

2

の危険側故障率は式

(6-11)′

で与えられる。よって,サブシステム

D

の危険側故障率

は,次のようになる。

λ

DssD 

′′= (1−β)

2

 × λ

De1

 × λ

De2

 × {(2−2DC

1 

−2DC

2

)T

1

 / 2 + (1−DC

1

) × MTTR

1

 + (1−DC

2

) × MTTR

2

}

β ( λ

De1

 + λ

De2 

) / 2

1/

時間)

  (6-1)′′  (D1)′′

JB.7

  高頻度作動要求モードにおける PFH

D

の意味

作動要求が離散的な場合には,サブシステムが危険側に故障してもすぐに危険事象が起こるとは限らな

い。作動要求があるまで危険事象は起こらない。

この規格は,高頻度作動要求モードに対する

SIL

PFH

D

で定義しているので,次に,高頻度作動要求

モードにおいて危険事象が起こる確率とサブシステムの

PFH

D

との関係を考察する。

高頻度作動要求モードにおいて,

サブシステムによる安全制御機能の作動失敗が実際に起こる確率

P

は,

作動要求が起こる確率

P

1

と,作動要求時にサブシステムが危険側に故障している確率

P

2

との積である。

P

 = P

1

 × P

2

(無次元)

  (7-1)

P

1

は,作動要求の頻度であるから,作動要求間隔を

T

D

とすれば,

P

1

= 1 / T

D

1/

時間)

  (7-2)

P

2

は,

T

D

の間にサブシステムが危険側に故障する確率であって,次の式で表される。

P

2

 = λ

D

× T

D

(無次元)

   (7-3)

(7-1)

に,式

(7-2)

及び式

(7-3)

を代入すると,

P

 = (1 / Td ) × (λ

D 

× T

D

) = λ

D

 (1/

時間)

   (7-4)

P

 × 1

時間

 = λ

D 

× 1

時間

 = PFH

D

(無次元)

  (7-5)

(7-5)

によって,高頻度作動要求モードにおいて,

1

時間の間にサブシステムが安全機能の作動失敗を

起こす確率も

PFH

D 

であることが確認できた。これによって,この規格がサブシステムの

SIL

を高頻度作

動要求モードに対しても

PFH

D

で定義することが妥当であることを理解できる。

JB.8

  PFD の計算式

JB.8.1

  概説

この規格(本体)では

PFD

を扱わない。低頻度作動要求モードを扱わないためである。しかし,作動要

求が離散的である場合は,

PFD

によってリスクの評価をしたい場合もあると考えられるため,以下,

PFD

PFH

D

との関係を考察する。

サブシステムの

PFD

は,作動要求があったときにサブシステムが既に危険側に故障している確率である。

PFD

計算式は,作動要求間隔

T

D

とプルーフテスト間隔との大小関係によって異なる。

PFD

は,この条

件によって次の式

(8-1)

又は式

(8-2)

のいずれかによって計算できる。

基本式の検証は,

次の JB.8.2 及び JB.8.3

で行う。

高頻度作動要求モード(T

1

 / 2 

  T

D

又はプルーフテストなし)の PFD

次の式

(8-1)

による。

PFD

 = λ

D

 × T

D

   

   (8-1) 

λ

D

 ×1

時間

  = PFH

D

と定義したから,

PFD

 = PFH

D 

× T

D

 / 1

時間  (無次元)

  (8-1)′

JIS C 0508-1

では,低頻度作動要求モードの

SIL

PFD

で定義している。JIS C 0508-1 

表 

SIL 1


104

B 9961

:2008 (IEC 62061:2005)

  

の要求値を見ると,

高頻度作動要求又は連続モードの PFH

D

 10

6

以上 10

5

未満

低頻度作動要求モードの PFD

(作動要求当たりの設計上の機能失敗平均確率)

10

2

以上 10

1

未満

となっている。すなわち,

PFD

は,

PFH

D 

10 000

倍になっている。このことは,

T

D 

として

10 000

時間

を想定したことを意味すると思われる。

10 000

時間は,約

1

年(

8 736

時間)に相当する。IEC 61508 規格

群では,高頻度作動要求モードと低頻度作動要求モードとを,

T

D

1

年又は

T

1

 / 2

を超えるかどうかで区

別している。

低頻度作動要求モード(T

1

 / 2 

  T

D

の PFD

次の式

(8-2)

による。

PFD

 = λ

D

 × T

1

 / 2  (8-2)

λ

D

 ×1

時間

  = PFH

D

と定義したから,

PFD

 = (PFH

D

× T

1

 / 2) / 1

時間  (無次元)

  (8-2)′

JB.8.2

  式

(

8-1

)

の検証

(8-1)

が成立する理由は,次のとおりである(

図 JB.1 の 参照。)。

最初の作動要求は,サブシステムを立ち上げてから

T

D 

時間後に発生する。最初の作動要求に失敗する

のは,

T

D 

時間が経過したときにサブシステムが既に危険側故障を起こしている場合である。

T

D 

時間の間

に危険側故障が発生する確率は

λ

D

 ×T

D

である。よって,最初の作動要求に失敗する確率は式

(8-1)

で与えら

れる。

2

番目の作動要求は,最初の作動要求に対する処理が済んでから

T

D

時間後に発生することになる。最

初の作動要求に失敗していた場合には,サブシステム

A

の故障を修復してから再立ち上げしたはずである

から,この場合に

2

番目の作動要求に失敗する確率は式

(8-1)

となる。最初の作動要求に成功していた場合

は,その時点でサブシステムの安全機能が正常であったことが確認されたことになる。サブシステムは,

正常な状態でリセットされてから次の作動要求を待っていたのだから,この場合も

2

番目の作動要求に失

敗する確率は式

(8-1)

で与えられる。

同様に,何番目の作動要求に失敗する確率も式

(8-1)

で与えられる。

JB.8.3

  式

(

8-2

)

の検証

(8-2)

が成立する理由は,次のとおりである(

図 JB.1 の 及び図 JB.8 を参照。)。

プルーフテストでは,危険側故障を漏れなく検出し,検出した場合は故障を修復してから再立ち上げす

るから,直前のプルーフテストから作動要求までの間にサブシステムの危険側故障が起こる確率が

PFD

なる。

テスト及び作動要求のタイミング関係を,

図 JB.8 に例示する。図 JB.8 は,四通りの作動要求間隔を例

示している。作動要求間隔は

T

1

 / 2

よりも大きいがその間隔は一定でない。テストとテストとの間(

T

1

間)に作動要求はないこともあり,最大

1

回の作動要求がある。

事例

1

では,間隔

t

1

の間に起こった危険側故障が,作動要求時の機能失敗を招く。同様に,事例

2

3

4

では,間隔

t

2

t

3

t

4

の間に起こった危険側故障が,作動要求時の機能失敗を招く。各作動要求時の失敗

確率は

PFD

n

 = λ

D

 × t

n

(無次元)

で与えられる。

t

n

の平均値は

T

1

 / 2

であるから,平均の失敗確率は,


105

B 9961

:2008 (IEC 62061:2005)

PFD

 = λ

D

 × T

1

 / 2

(無次元)

となる。これが式

(8-2)

である。

以上の記述は,

T

1

の間に起こる作動要求の分布が時間に対して一様であることを仮定したものである。

T

D

に一定の周期性がある場合には,さらに厳密な検証が必要であるが,作動要求の起こり方がどうであれ,

   

T

1

 / 2

  T

D

である限り,

PFD

PFD

max

 = λ

D

 × T

1

(無次元)

   (8-3)

を超えることは有り得ない。機械の分野では,一般に

T

D

には規則性がないと考えられるため,低頻度作動

要求モードの場合は,式

(8-2)

を適用しても大きな誤りを生じない。

図 JB.8−作動要求及びプルーフテストのタイミング(T

1

/

2

<

T

D

JB.9

  フォールトトレランスの概念

JB.9.1

  フォールトトレランスの意味

この規格では,

SRECS

,サブシステム又はサブシステム要素が,故障が存在する状況で,要求された機

能を続行できる能力をフォールトトレランスという(3.2.31 参照)

ハードウェアフォールトトレランスが

N

であるということは,

N

1

個目の故障が安全機能の喪失又は

失敗を起こし得ることを意味する(

表 の注記 参照)。

サブシステムの

PFH

D

が小さいほど安全制御システムの安全性が高いといえるが,

PFH

D

だけでサブシス

テムの安全性を評価することはできない。いくら

PFH

D

が小さくても,一つの危険側故障によって安全制

御機能が直ちに失われるようなサブシステムは,安全性が高いとはいえない。

例えば,冗長系にすることによって,危険側故障が一方のサブシステム要素に発生してもさらに次の危

険側故障が残存サブシステム要素に発生するまでは安全制御機能が失われないようなサブシステムでは,

最初の故障によってサブシステムが直ちに安全制御機能を失うことがないようにできる。

この附属書で考察するサブシステム

A

及び

C

は,非冗長系であって,フォールトトレランス

0

のサブ

プルーフテスト間隔

 

作動要求事例 1

 

作動要求事例 2

作動要求事例 3

作動要求事例 4

T

1

 /2

T

1

 

T

1

T

1

T

1

 

t

1

t

2

  t

3

t

4

T

D1

 

T

D2

 

T

D3

 

T

D4

 


106

B 9961

:2008 (IEC 62061:2005)

  

システムである。サブシステム

C

は,診断機能をもつが,診断によって危険側故障を検出できるが,検出

したら直ちに運転を停止し故障を内包したまま運転を続けることがない。よってフォールトトレランスが

0

である。

サブシステム

B

及び

D

は,並列冗長系であって,一つの危険側故障によって直ちに安全機能を失うこと

がないから,フォールトトレランスが

1

である。

JB.9.2

  フォールトトレランス対自己診断

一般には,フォールトトレランスをもつサブシステムの方がフォールトトレランスをもたないサブシス

テムより安全性が高いと考えられるが,常にそうとはいえない。例えば,サブシステム

B

の方がサブシス

テム

C

より常に安全性が高いとは一概にいえない。

サブシステム

B

は,

フォールトトレランス

1

をもつが,

診断機能をもたないため,一つ目の危険側故障によってフォールトトレランスが

0

になったことを知るこ

とができない。いつサブシステムの安全制御機能が失われるか分からない不安を抱えながら運転を続けな

ければならない。サブシステム

C

は,フォールトトレランスをもたないが,故障したら直ちに(

T

2

以内に)

故障を検出して運転を停止するから,故障を知らずに運転を継続する時間は最大でも

T

2

という短い時間に

限られる。フォールトトレランス

0

のサブシステム

C

が,フォールトトレランス

1

のサブシステム

B

より

安全性が低いとは一概にいえない。

また,フォールトトレランス数が同じであっても,サブシステムの安全性が同じであるとはいえない。

この規格では,サブシステム

B

及びサブシステム

D

のいずれもフォールトトレランスが

1

であるとみなさ

れるが,一般には,サブシステム

D

の方が,安全性が高い。

JB.9.3

  フォールトトレランス対 PFH

D

フォールトトレランスが

0

になったとき,そのことを

100

%検出して,直ちに修復するなどの安全方策

をとれば,危険事象がいつ起こるかも知れないというリスクから完全に逃れることができる(修復中は逃

れられない。

。しかし,診断によって危険側故障を

100

%検出することは一般に困難である。フォールト

トレランスをもつサブシステムであっても,フォールトトレランスを失ったことを知らずに運転を続ける

確率を

0

にすることはできない。

この規格の 6.7.8.2 に示すサブシステム

B

及びサブシステム

D

PFH

D

の計算式は,サブシステムのフォ

ールトトレランスが

0

になったことを知らずに(検出できずに)

,一つの危険側故障を抱えたまま運転を続

け,第

2

の危険側故障によってサブシステムが安全制御機能を失う確率を与えている。

6.7.8.2

の式

(A)

,式

(B)

,式

(C)

,式

(D1)

で計算した各サブシステムの

PFH

D

が同じであるとすれば,フォ

ールトトレランスの有無にかかわらず,サブシステムが,運転を開始してから安全制御機能を失う

1

時間

当たりの確率は同じである。

しかしそれでも,

PFH

D

が同じなら,構造的にフォールトトレランス数の多いサブシステムの方がより

安全だとする考えがある。この規格では,

SIL

を単に

PFH

D

だけで決めるのではなく,フォールトトレラ

ンスも考慮して決めることになっている(

表 参照)。


107

B 9961

:2008 (IEC 62061:2005)

参考文献

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)

  

注記

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