JISC0511-2:2008 機能安全－プロセス産業分野の安全計装システム－第２部：ＪＩＳ　Ｃ　０５１１

C 0511-2：2008 (IEC 61511-2：2003)

（1）

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

ページ

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

1 適用範囲 ························································································································· 3

2 引用規格 ························································································································· 3

3 用語の略号及び定義 ·········································································································· 3

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

5 機能安全の管理 ················································································································ 4

5.1 目的 ···························································································································· 4

5.2 要求事項 ······················································································································ 4

6 安全ライフサイクル要求事項 ······························································································ 9

6.1 目的 ···························································································································· 9

6.2 要求事項 ····················································································································· 10

7 適合確認 ························································································································ 10

7.1 目的 ··························································································································· 10

8 プロセスの潜在危険及びリスク評価 ···················································································· 10

8.1 目的 ··························································································································· 10

8.2 要求事項 ····················································································································· 11

9 防護層への安全機能の割当て ····························································································· 13

9.1 目的 ··························································································································· 13

9.2 割当過程における要求事項······························································································ 13

9.3 安全度水準4にかかわる付帯要求事項 ··············································································· 15

9.4 防護層としての基本プロセス制御系に対する要求事項 ·························································· 15

9.5 共通原因，共通モード及び従属故障にかかわる要求事項 ······················································· 16

10 SIS安全要求仕様 ··········································································································· 17

10.1 目的 ·························································································································· 17

10.2 一般要求事項 ·············································································································· 17

10.3 SIS安全要求事項 ········································································································· 17

11 SISの設計及びエンジニアリング ······················································································ 18

11.1 目的 ·························································································································· 18

11.2 一般要求事項 ·············································································································· 18

11.3 故障検出時のシステム挙動にかかわる要求事項 ································································· 22

11.4 ハードウェア故障許容にかかわる要求事項 ······································································· 22

11.5 部品及びサブシステムの選択に関する要求事項 ································································· 24

11.6 フィールドデバイス ····································································································· 25

11.7 インタフェース ··········································································································· 26

11.8 保全又は試験設計要求事項 ···························································································· 28

C 0511-2：2008 (IEC 61511-2：2003) 目次

（2）

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

ページ

11.9 SIFの機能失敗確率 ······································································································ 28

12 ユーティリティソフトウェアの選択基準を含むアプリケーションソフトウェアの要求事項 ··········· 30

12.1 アプリケーションソフトウェアの安全サイクル要求事項 ····················································· 30

12.2 アプリケーションソフトウェアの安全要求事項 ································································· 34

12.3 アプリケーションソフトウェアの安全妥当性確認計画 ························································ 35

12.4 アプリケーションソフトウェアの設計及び開発 ································································· 35

12.5 アプリケーションソフトウェアのSISサブシステムとの統合 ··············································· 42

12.6 FPL及びLVLソフトウェア部分改修の手順 ····································································· 42

12.7 アプリケーションソフトウェアの適合確認 ······································································· 43

13 立会試験 (FAT) ············································································································ 44

13.1 目的 ·························································································································· 44

13.2 推奨事項 ···················································································································· 44

14 SISの設置及び引渡し ····································································································· 45

14.1 目的 ·························································································································· 45

14.2 要求事項 ···················································································································· 45

15 SIS安全妥当性確認 ········································································································ 45

15.1 目的 ·························································································································· 45

15.2 要求事項 ···················································································································· 45

16 SISの運用及び保全 ········································································································ 46

16.1 目的 ·························································································································· 46

16.2 要求事項 ···················································································································· 46

16.3 プルーフテスト及び検査 ······························································································· 46

17 SISの部分改修 ·············································································································· 47

17.1 目的 ·························································································································· 47

17.2 要求事項 ···················································································································· 47

18 SIS使用終了 ················································································································· 47

18.1 目的 ·························································································································· 47

18.2 要求事項 ···················································································································· 47

19 情報及び文書化の要求事項 ······························································································ 48

19.1 目的 ·························································································································· 48

19.2 要求事項 ···················································································································· 48

附属書A（参考）安全計装機能の作動要求時の失敗確率を計算する手法例 ······································ 49

附属書B（参考）典型的なSIS構成開発 ··················································································· 50

附属書C（参考）安全PLCのアプリケーション機能 ·································································· 54

附属書D（参考）SIS論理処理部のアプリケーションソフトウェア開発方法論の例··························· 56

附属書E（参考）安全で構成されたPE論理処理部のための外部構成診断の開発に関する例 ··············· 61

C 0511-2：2008 (IEC 61511-2：2003)

（3）

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

まえがき

この規格は，工業標準化法第12条第1項の規定に基づき，社団法人日本電気計測器工業会(JEMIMA)及

び財団法人日本規格協会(JSA)から，工業標準原案を具して日本工業規格を制定すべきとの申出があり，日

本工業標準調査会の審議を経て，経済産業大臣が制定した日本工業規格である。

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

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

抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査会は，このような特許

権，出願公開後の特許出願，実用新案権及び出願公開後の実用新案登録出願にかかわる確認について，責

任はもたない。

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

JIS C 0511-1 第1部：フレームワーク，定義及びシステム・ハードウェア・ソフトウェアの要求事項

JIS C 0511-2 第2部：JIS C 0511-1の適用指針

JIS C 0511-3 第3部：安全度水準の決定指針

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

日本工業規格 JIS

C 0511-2：2008

(IEC 61511-2：2003)

機能安全−プロセス産業分野の安全計装システム−

第2部：JIS C 0511-1の適用指針

Functional safety−

Safety instrumented systems for the process industry sector−

Part 2: Guidelines for the application of JIS C 0511-1

序文

この規格は，2003年に第1版として発行されたIEC 61511-2を基に，技術的内容及び対応国際規格の構

成を変更することなく作成した日本工業規格である。

安全計装システム（以下，“SIS”という。）は，プロセス産業において，安全計装機能の履行のために長

年にわたって使用されてきた。計装を安全計装機能として有効に使用するためには，その安全用の計装が

ある最低限の標準を満たすことが必要不可欠である。

この規格は，プロセス産業へのSISの適用を扱っている。また，SISと，プロセスの潜在危険及

びリスク評価が行われることを必要とする他の安全システムとのインタフェースも扱っている。

SISには，検出端，論理処理部及び操作端が含まれる。

この規格には，その適用の基礎となる“安全ライフサイクル”及び“安全度水準（以下，“SIL”という。）”

の二つの概念が含まれる。安全ライフサイクルは，この規格の概念の中心となる方法論である。

この規格は，最低限の標準を達成するために，安全ライフサイクル業務に関する一つの方法論を示して

いる。この方法論は，合理的で整合した技術的措置がとられるよう採択されたものである。この規格の目

的は，いかにしてJIS C 0511-1に準拠するかの指針を提供することである。

この規格は，各箇条及び各細分箇条がJIS C 0511-1の箇条番号と同一となるように編成してある（附属

書を除く。）。

C 0511-2：2008 (IEC 61511-2：2003)

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

適用範囲

この規格は，JIS C 0511-1で定義する安全計装機能及び関連するSISの仕様，設計，設置，運用及び保

全についての指針を示す。

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

IEC 61511-2:2003，Functional safety−Safety instrumented systems for the process industry sector−

Part 2: Guidelines for the application of IEC 61511-1 (IDT)

なお，対応の程度を表す記号(IDT)は，ISO/IEC Guide 21に基づき，一致していることを示す。

引用規格

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

引用規格は，その最新版（追補を含む。）を適用する。

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

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

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

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

electronic safety-related systems (IDT)

JIS C 0508-3 電気・電子・プログラマブル電子安全関連系の機能安全−第3部：ソフトウェア要求事

項

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

electronic safety-related systems−Part 3: Software requirements (IDT)

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

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

electronic safety-related systems−Part 4: Definitions and abbreviations (IDT)

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

適用指針

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

electronic safety-related systems−Part 6: Guidelines on the application of IEC 61508-2 and IEC

61508-3 (IDT)

JIS C 0511-1 機能安全−プロセス産業分野の安全計装システム−第1部：フレームワーク，定義及び

システム・ハードウェア・ソフトウェアの要求事項

注記対応国際規格：IEC 61511-1，Functional safety−Safety instrumented systems for the process

industry sector−Part 1: Framework, definitions, system, hardware and software requirements (IDT)

JIS C 0511-3 機能安全−プロセス産業分野の安全計装システム−第3部：安全度水準の決定指針

注記対応国際規格：IEC 61511-3，Functional safety−Safety instrumented systems for the process

industry sector−Part 3: Guidance for the determination of the required safety integrity levels (IDT)

用語の略号及び定義

この規格で用いる主な用語及び定義は，JIS C 0511-1による。

JIS C 0511-1の3.2.68（安全機能）及び3.2.71（安全計装機能）にかかわる指針を，次に示す。

3.2.68 安全機能は，特定の危険事象を防止することが望ましい。例えば，容器＃ABC456の10 MPaを超

C 0511-2：2008 (IEC 61511-2：2003)

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

える圧力を防ぐことが望ましい。安全機能は，次のいずれかの事項によって達成することができる。

a) 単独のSIS

b) 一つ以上のSIS及び／又は他の防護層

b)の場合，各SIS又は他の防護層は，安全機能を達成することができなければならず，かつ，全体の組

合せが必要なリスク軽減（プロセス安全目標）を達成しなければならない。

3.2.71 安全計装機能は，安全機能から得られ，関連したSILをもち，特定のSISによって実行される。例

えば，“容器＃ABC456の圧力が10 MPaに達するとき，弁＃XY123を5秒以内に閉ざす”SISの構成部品

は，一つ以上の安全計装機能によって使用することができることに留意する。

この規格群への適合

この規格では規定しない。

機能安全の管理

5.1

目的

JIS C 0511-1の箇条5の目的は，機能安全の目的が満たされていることを保証するために必要な管理業

務を実行するための要求事項を提供することにある。

5.2

要求事項

5.2.1

一般

5.2.1.1 この規格では規定しない。

5.2.1.2 組織が機能安全に必要な一つ以上の業務に責任を負い，かつ，その組織が品質保証手順に従って

機能しているときには，この箇条で記載するこれらの業務の多くは，品質保証目的のために既に実行され

ている。この場合には，機能安全の目的のために既に品質保証目的で実施済みの業務を繰り返す必要はな

い。このような場合には，品質保証手順を，それらが機能安全の目的を達成するために見直すことが望ま

しい。

5.2.2

組織及び人的資源

5.2.2.1 会社・サイト・プラント・プロジェクト内でSISに関連した組織構成を定義し，各構成要素の役

割及び責任を明確に理解及び伝達することが望ましい。組織構成内で個々の役割を，その記述及び目的を

含み確認することが望ましい。それぞれの役割には，明白な責任を規定することが望ましく，かつ，特定

の責任が認識されることが望ましい。さらに，各人がだれに報告するか，かつ，だれが任命するかを確認

することが望ましい。その意図は，組織の皆がSISに対する役割及び責任を理解していることを保証する

ことにある。

5.2.2.2 SISにかかわる安全ライフサイクルの取組を実行するのに必要な技能及び知識を確認することが

望ましく，それぞれの技能には，必要な能力レベルを定義することが望ましい。人的資源の能力は，それ

ぞれの技能に対して評価することが望ましく，技能ごとの人数も必要とされる。違いが認められる場合に

は，必要な能力のレベルが適切な時期に達成されることを可能にすべく開発計画を確立することが望まし

い。技能不足が生じる場合には，相応の資格のある経験豊富な人員を募集するか又は契約することになる。

5.2.3

リスク査定及びリスク管理

JIS C 0511-1の5.2.3の要求事項は，危険を同定し，リスクを査定し，かつ，必要なリスク軽減を確定す

ることである。これらの評価を行うのに利用可能な多数の異なる方法論がある。JIS C 0511-1は，特定の

方法論を是認するものではない。その代わりに，JIS C 0511-3にあるこの問題に関する多くの方法論を確

C 0511-2：2008 (IEC 61511-2：2003)

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

認することが望ましい。更なる指針については，8.2.1参照。

5.2.4

計画

この箇条の目的は，総合的なプロジェクト内で，適切な安全計画がライフサイクルの各フェーズ（例え

ば，技術設計，プラント運転）で，必要な業務のすべてに取り組まれることを保証することである。この

規格ではこれらの計画活動の特定の仕組みは必要としないが，これら業務の周期的な更新又は見直しを必

要とする。

5.2.5

実施及び監視

5.2.5.1 この細分箇条の目的は，効果的な管理手順が次の事項のために整備されることを保証することで

ある。

a) 潜在危険分析，リスク評価，他の評価，監査業務，適合確認業務及び妥当性確認業務から生じるすべ

ての推奨事項が，十分に解決されることを保証する。

b) SISが，その稼働寿命を通して安全要求仕様どおりに機能していることを明確にする。

5.2.5.2 このような状況において，供給者とは，コンポーネントの供給者と同様に設計契約業者及びメン

テナンス契約者を含める。

5.2.5.3 安全要求仕様 (SRS) を遵守していることを保証するために，SIS性能の見直しを定期的に行うこ

とが望ましい。例えば，SISにおける異なるコンポーネントの推定故障率が元の定義のままであることを

保証するために，定期的審査を行うことが望ましい。故障率が元来予期されているより悪い場合には，設

計の修正が必要である。同様に，SISの作動要求率を見直すことが望ましい。作動要求率が想定以上であ

るならば，SILの調整が必要である。

5.2.6

評価，監査及び改定

評価及び監査は，誤りを検出し，除去するためのツールである。以下でこれらの活動の明確な区別をす

る。

機能安全評価は，評価ライフサイクルフェーズで作った規定が安全を達成するのに十分であるかを評価

することを目的とする。機能安全の実現に責任のある人員によって取られた意志決定へ，評価者による判

定を下す。例えば，メンテナンスのための手順が適切であるかどうかに関して引渡し前に査定を行う。

機能安全監査員は，プロジェクト又はプラント記録から必要な手順が指定された頻度で，必要な能力を

もつ者によって使用されているかを決定する。監査員は，自らが考えている作業の妥当性で判断をする必

要はない。しかし，変更を行うのがよい場合は，監視結果を記録に含めることが望ましい。

多くの場合，査定者と監査者の仕事の間には，重複する箇所ができることに注意する。例えば，監査員

は，オペレータが必要な教育・訓練を受けているかを判断するだけでなく，更に教育・訓練が必要な能力

をもたらしているかを判断することが必要である。

5.2.6.1

機能安全評価

5.2.6.1.1 機能安全評価 (FSA) は，SISが安全計装機能とSILに関する要件を満たすことを証明する基本

である。システム開発プロセスの独立した評価を通して，合意された規格又は実例に準拠していることを

証明することが，この評価の基本的な目的である。SISの評価を，異なるライフサイクルの段階で必要と

することもある。有効な評価を行うために，評価チーム編成時にこの規格など何らかの指針に伴うこの評

価の適用範囲を定義する手順を開発することが望ましい。

次の項目は，機能安全評価に良い方法であると考えられる。

a) FSAに必要な評価と，それを行う評価者及びその能力範囲，更に評価によって作成される情報の範囲

のすべてを特定するFSAごとの計画を作成することが望ましい。

C 0511-2：2008 (IEC 61511-2：2003)

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

b) FSAでは他の基準及び実例を考慮することが望ましく，それらは企業の外部若しくは内部の規格，ガ

イド，手順又は行動規準の中に含まれることがある。FSA計画では，特定の評価・システム・応用分

野に対し何を評価するかを定義することが望ましい。

c) FSAの頻度は，異なるシステム開発で変わることがあるが，最小限として潜在的危険がシステムに現

れる以前に行うことが望ましい。会社には，また，ライフサイクルの末期に高価な作業のやり直しを

防ぐために工事・設置フェーズの前に評価を行うことが望ましい。

d) FSAの頻度及び厳格さには，次のようなシステム属性を考慮して定義することが望ましい。

1) 複雑性

2) 安全上の重要性

3) 類似システムにおける以前の経験

4) 設計上の特徴の標準化

e) 設計，設置，検証及び妥当性確認業務の十分な証拠は，評価の前に利用可能とすることが望ましい。

十分な証拠の有用性は，それ自身が評価基準になり得る。証拠によって，システム設計又は設置の現

在承認された状態を表すことが望ましい。

評価者の独立は，適切でなければならない。

g) 評価者は，経験と評価するシステムの技術と応用分野で適切な知識をもつことが望ましい。

h) FSAへの組織的で一貫した取組は，ライフサイクルを通して，かつ，システムにわたって維持するこ

とが望ましい。FSAは，主観的な業務である。したがって，詳細な指針は，チェックリストの使用に

よって，組織にとって何が受入可能なのかを定義し，できるだけ多くの主観性を取り除くことが望ま

しい。

FSAから作成した記録は，完全，かつ，その結論は，次のライフサイクルフェーズの開始以前に，SIS

の機能安全管理に責任がある者が同意することが望ましい。

5.2.6.1.2 プロジェクトチームから独立している者の必要性は，評価の客観性を増加させることにある。

才能（例えば，経験，格付けレベル，地位）をもつ上席有資格者が，当面の関心事を正しく知り，取り組

んでいることを保証するために必要である。規模の大きいプロジェクト又は評価チームには，プロジェク

トチームから独立している1人以上の上席者が必要になることがある。

会社内の組織と専門的技術によっては，独立評価者の必要条件は，外部組織を使用することによって満

たされなければならないことがある。逆に，当該プロジェクトに責任がある人々と管理及び他の人的資源

面で独立した，リスク評価とSISの適用に精通した内部組織をもつ会社は，その人的資源を使って独立し

た組織の要件を満たすことができるであろう。

5.2.6.1.3 評価の量は，プロジェクトの規模と複雑性によって変わる。同時に異なるフェーズの結果を評

価することができる場合がある。これは，稼働している工場での多少の変化の場合に該当する。

5.2.6.1.4 ある国では，安全ライフサイクルの段階3で行われる機能安全評価が，しばしばプリスタート

アップセーフティレビュー (PSSR) と呼ばれる。

5.2.6.1.5 この規格では規定しない。

5.2.6.1.6 この規格では規定しない。

5.2.6.1.7 評価チームは，評価するのに必要と思われる情報にはアクセスできるようにすることが望まし

い。これには潜在危険とリスク評価からの情報，設置，引渡し及び妥当性確認を通じての設計段階を含め

ることが望ましい。

5.2.6.2

監査及び改定

C 0511-2：2008 (IEC 61511-2：2003)

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

5.2.6.2.1 この細分箇条は，業務例を使用して，監査についての指針を与えることを目的としている。

a) 監査の分類 SIS監査は，工場管理，計装保守要員及び計装設計技師に有益な情報を与える。

これは，管理を前向きにし，SISの実現と有効性の程度を意識させることを可能にする。実行可能

な様々な監査方式がある。特定業務監査の実際の方式，適用範囲及び頻度によって，当該業務の安全

度に対し潜在的影響を与えることが望ましい。

監査方式には，次の事項を含める。

1) 第三者監査及び自己監査

2) 検査

3) 安全訪問（例えば，工場を巡回し問題調査をする。）

4) SIS査察（例えば，アンケート）

“監視及びチェック”と監査業務との間で区別をする必要がある。監視及びチェックでは，特定の

ライフサイクル業務の実績を評価する（例えば，コンポーネントを運用状態に戻す前に，管理者が保

守業務の完了をチェックする。）。対照的に，監査業務は，より包括的であり，安全ライフサイクルに

関するSISの総合的な実現に焦点を当てる。監査は，監視及びチェックプログラムが行われるかどう

かを決定することを含める。

監査及び検査は，会社・サイト・プラント・プロジェクト自身の要員によって実施するか（例えば，

自己監査），又は独立した部門（例えば，社外監査役，品質保証部，規制当局，顧客又は第三者機関）

によって実施することがある。

様々なレベルにおける管理者は，彼らのSISの実現の有効性の情報を獲得するために，関連した監

査の適用を望んでいることがある。監査からの情報を，適切に行われていなかった手順を特定するた

めに使用することで，手順の改良につながる可能性がある。

b) 監査戦略サイト・プラント・プロジェクトを実施する監査プログラムでは，活動継続プログラム，

第三者又は自己監査プログラム及び検査プログラムの実施を考慮してもよい。

活動継続プログラムを，前回のSISの性能及び監査結果，並びに最新の関心事及び優先度を反映す

るために，定期的に更新する。これらは，SISのすべてのサイト・プラント・プロジェクトに関連し

た業務及び側面を，適切な期間及び適切な範囲で網羅する。

監査の主な理由及び監査からの付加価値は，監査によってタイムリーに与えられる情報によって生

まれる。監査の目的は，SISの有効性を強化することにある（例えば，従業員又は一般人の負傷又は

死亡のリスクを最小限にする，安全文化の改善に寄与する，環境への物質の避けられる放出を防ぐこ

とに寄与する。）。

要約すれば，監査戦略は，様々な監査形式の組合せからなり，管理者側（顧客）によって決定され，

時宜を得た行動のために関連情報を管理者側までフィードバックする。

c) 監査のプロセス及びプロトコル監査の総合的な目的は，監査の遂行による最大の価値を達成するこ

とにある。すべての当事者（監査員，被任命者，工場長及び部門長など）が監査の必要性を理解し，

各監査に影響を及ぼす場合にだけこれが達成される。これらの目的を達成することへの取組の中で，

次の監査のプロセス及びプロトコルは，何らかの一貫性を確実にする一助となる可能性がある。それ

らは，次の五つの主要な監査プロセスに影響を及ぼす。

1) 監査戦略及び監査プログラムそれぞれの監査の目的を明確に定義し，また，当該監査グループは，

それぞれの監査グループの役割と責任とともに識別することが望ましい。

監査の戦略があることが望ましい。

C 0511-2：2008 (IEC 61511-2：2003)

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

監査のプログラムがあることが望ましい。

監査のプロセス，プログラム及び戦略実現の定期的なレビューをする。

2) 監査の準備及び事前の計画監査を始める前に，サイト・プラント・プロジェクトの上級管理者及

び／又は適切な監査計画者は，被任命者を特定することが望ましい。監査員と被任命者とは，初期

の段階で次の事項を議論し，理解し，同意することが望ましい。

− 監査の適用範囲

− 監査の時期

− 監査に必要な人員

− 監査又は監査基準の基礎

− 準備段階に特別な努力をそそぎ，工場の人員を含め，その結果，監査を成功させる機会を高める。

各段階で費やす時間の指針として，次の事項を適用することが望ましい。

− 監査の準備：30 %

− 監査の実施：40 %

− 監査結果の記録：20 %

− 監査のフォローアップ：10 %

監査員は，情報，手順，指示及びデータを集めたり，適切な場合には，チェックリストを用意し，

監査の準備をすることが望ましい。

監査員は，重大な所見・欠点を見つけた場合，監査の最中に監査の適用範囲が変更されてしまう

可能性について強調し，説明することが望ましい。

3) 監査の実施監査員は，決められた監査期間中の連続した数日内で，工場又はプロジェクト要員に

混乱が起こらないように監査を行う。

被任命者は，発見した事項を監査期間中に定期的にまとめておき，監査の終わりに予期しない結

果にならないようにすることが望ましい。

監査員は，オーナシップを達成するために，プラント要員にプロセス及び監査結果を学習させ，

理解させるために監査プロセスに含めることが望ましい。

監査を成功させるには，監査の進め方が重要である。監査員は，役立ち，建設的で，丁重で，集

中して，更に客観的になろうとすることが望ましい。

監査員は，合意された監査範囲及び進行表に従わなければならない。これを変える場合には，適

切な交渉が必要となる。

4) 監査結果の記録監査員は，監査の終わり又はその後で，最終報告書を発行する前に，最終会議を

開催することが望ましい。

管理者は，報告と答申の草案にコメントする機会を与え，かつ，必要に応じて正式な最終会議で

それらを議論することが望ましい。

報告結果に対処するためにサイト・プラント・プロジェクトから実行計画を要求するのは，正常

の慣行である。

5) 監査の継続（フォローアップ）監査レポートは，通常，行動計画形式の反応を必要とする。監査

員は，期日又は次の監査の適切な時期に，行動計画が満足できるかを検証する場合がある。

サイト・プラント・プロジェクトの履歴管理システムは，行動計画の実現をチェックするのに使

用されることがある。

それぞれの監査グループの監査答申の定期的な審査及び概要を考慮することが望ましく，その結

C 0511-2：2008 (IEC 61511-2：2003)

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

果を広範囲に知らせることが望ましい。

監査の結果と答申は，監査の頻度を見直すのに使用されることがあり，SISの管理者による見直

しの材料となる。

5.2.6.2.2 この項は，監査プロセスにおける変更管理が果たす役割を補強している。

5.2.7

SIS変更管理

5.2.7.1

要求事項

5.2.7.1.1 ライフサイクルを通して，装置のトレーサビリティを管理し維持するために，それぞれの装置

の形式及びバージョンを識別・管理し，履歴管理のメカニズムを確立することができる。安全ライフサイ

クルの可能な限り早期の段階で，重複しない識別子を各装置に与えることが望ましい。場合によっては，

まだ使用中の過去のモデル・版を維持し管理することも可能である。構成管理プログラムの初期段階には，

次の事項を含むことが望ましい。

構成管理システムには，次の事項を含んでもよい。

a) ライフサイクルのすべての段階ですべての装置を識別するための手順の提供

b) モデル・バージョンの重複しない識別子，ソフトウェア，供給者，日付，及び可能な場合は最初に指

定したモデル・バーションからの変更を含んだ各装置の構成状態

c) 故障観測及び監査から生じるすべての行動及び変化の識別及び履歴

d) 関連装置の状態及びモデル・バージョンを識別した，運用への投入時期の管理

e) 運転中のSISが不当に変更・修正されないことを保証するために設けた安全対策

一つの完成装置の特定のバージョンとともに構成している各ソフトウェア製品のバージョンの識別

g) 一つ以上のプラントで複数のSISを更新するための調整の提供

h) 運用への投入の文書化された認可

装置の運用への投入のための認可された署名リスト

ステージ・フェーズ装置は，構成管理の下で実現される。

k) 関連提出書類の管理

装置の各モデル・バーションの識別

− 機能仕様

− 技術仕様

m) SISの管理及び維持にかかわるすべての部門／組織が特定され，かつ，割り当てられ理解されている

責任

安全ライフサイクル要求事項

6.1

目的

プロセス施設で達成される機能安全は，満足のいくように実施される多くの業務に依存している。SIS

への組織的な安全ライフサイクルの取組を行う目的は，機能安全を達成するのに必要なすべての業務が行

われ，また，適切な順序で行われたことを他のものに立証できることを保証することにある。典型的なラ

イフサイクルをJIS C 0511-1の図8及び表2に規定している。JIS C 0511-1の箇条8〜箇条16にそれぞれ

のライフサイクルフェーズの要求事項を示している。

すべての要求事項が満たされれば，特定の業務が異なる順序で行われてもこの規格で認められる。安全

業務が通常のプロジェクトの手順によりうま（旨）く組み込むことを許容するならば，この手順変更は有

益となり得る。JIS C 0511-1の箇条6の目的は，異なる安全ライフサイクルが使用されている場合，ライ

C 0511-2：2008 (IEC 61511-2：2003)

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

フサイクルのそれぞれのフェーズの入出力が定義し，すべての必す（須）の要求事項を組み込んでいるこ

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

6.2

要求事項

6.2.1 重要な考慮すべき事柄は，使用されるSISの安全ライフサイクルをあらかじめ定義することである。

この業務の計画があらかじめ適切に計画されておらず，また，責任を負うすべての人々，部門及び組織が

合意に達していない場合には，経験上問題が起こりそうである。最良でも仕事が遅れるか，やり直しが必

要となり，最悪の場合，安全性が危うくなることがある。

6.2.2 要求事項ではないが，JIS C 0511-1の図8のどの箱をプロジェクトに適用するかを含め，プロセス

のプロジェクトライフサイクルに対し提案されているSIS安全ライフサイクルを初期の段階で割り付ける

のは，一般的に有効である。これを行うときには，安全ライフサイクル業務を始めるのに必要な情報をだ

れがその情報を提供できそうであるかとともに考慮に入れることが望ましい。場合によっては，設計段階

の末期までに特定の問題について的確な情報を決定することが可能でない場合がある。このような場合に

は，以前の経験に基づいて評価し，後日データの確認が必要になることがある。この場合には，安全ライ

フサイクルでこの事項について注意することが重要である。

6.2.3 安全ライフサイクルを計画する上でもう一つの重要な部分は，各段階で使用する手法を決定するこ

とである。独自の技能と経験をもつ人々又は部門を必要とする特殊な手法を用いることがしばしば必要と

なるので，そのような手法の決定が重要である。例えば，特定の業種における影響度は故障事象後の最大

圧力に依存していることがあり，これを決定できる唯一の方法は，プロセスのダイナミックなモデルを開

発することである。その結果，ダイナミックなモデル化のための情報の必す（須）条件が，設計プロセス

に重要な影響を与える。

適合確認

7.1

目的

適合確認の目的は，各安全ライフサイクルフェーズの業務が，適合確認計画によって決められているよ

うに，実際に行われ，当該フェーズの必要な出力が，文書，ハードウェア又はソフトウェアの形で作られ

ているか，また，その目的に適しているかを確実にすることである。

7.1.1

要求事項

7.1.1.1 JIS C 0511-1では，組織が検証のために自らの手順をもち，その手順が同様に行われることをいつ

も必要とするわけではないことを認めている。代わりに，この箇条は，すべての検証業務が使用する手順，

測定及び手法とともにあらかじめ計画していることを意図している。

7.1.1.2 この規格では規定しない。

7.1.1.3 安全ライフサイクルのすべてのフェーズで有効な検証が行われたことを立証できる結果を得るこ

とが重要である。

プロセスの潜在危険及びリスク評価

8.1

目的

ここでの総合的な目的は，安全なプロセスを確実にするために必要な関連した性能レベル（リスク軽減）

とともに，安全機能（例えば，防護層）の必要性を確立することである。単一層の故障が有害な結果を引

き起こさないか許容しないように，複数の安全層をもたせることはプロセスの分野で一般的である。典型

的な安全層をJIS C 0511-1の図9に示す。

C 0511-2：2008 (IEC 61511-2：2003)

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

8.2

要求事項

8.2.1 潜在危険及びリスク評価のための要件は，作業結果によってだけ特定される。安全機能及び関連の

性能レベルを明確に記述し，組織が有効と考えるどんな手法も使用することが可能であることを意味する。

潜在危険及びリスク評価には，（故障状態及び当然予期される誤用を含んだ）すべての予期できる状況の

下で，起こり得る潜在危険及び危険な事象を明確にすることが望ましい。

プロセス分野での典型的なプロジェクトでは，事前の潜在危険及びリスク評価は，基本的なプロセス設

計をする期間の早い時期に行う必要がある。この段階の想定では，本質安全原則及び優れた技術的手法（潜

在危険を軽減させるこの活動は，JIS C 0511規格群の適用範囲内ではない。）の適用によって，実行可能な

限り潜在危険は軽減されているものとする。SISにとって，この事前に潜在危険及びリスクを評価するこ

とは，SISを確立し，設計及び実行することに複雑な作業及び時間がかかるので重要である。この作業を

早期に行うもう一つの理由は，プロセス及び計装図が完了される前にシステム構築の情報が必要となるこ

とである。

プロセスフローダイアグラムが完成され初期のプロセスデータがすべて利用可能となった時点で，通

常は事前の潜在危険及びリスク評価を進めることを可能にする十分な情報が存在することになる。詳細設

計が進行するにつれて，潜在危険が更に導入されることを認識することが望ましい。したがって，最終的

な潜在危険及びリスク評価は，プロセス及び計装図が確定したときに必要になることもある。一般に，こ

の最終分析では，化学プラントの安全性評価の手法 (HAZOP) などの正式，かつ，完全に文書化された手

順が使用される。そこでは設計された安全層がプラントの安全性を確実にするために適切であることを確

認することが望ましい。この最終分析では，安全システムの故障が何か新しい潜在危険又は要求を持ち込

むかどうか考慮する必要がある。この段階で，何か新しい潜在危険が確定される場合には，新しい安全機

能を定義することが必要になることもある。もう一つのより起こりそうな結果は，事前段階で既に確認さ

れた潜在危険に至る，更なる事象を特定することである。その結果，最初の分析で確定した安全機能及び

性能要件を修正する必要があるかを検討することが望ましい。

潜在危険を特定するのに使用される手法は，考えられる適用業務による。プラットホーム (simple

off-shore wellhead towers) など，標準設計に広範囲な運用経験がある簡単なプロセスでは，個々の産業用の

チェックリスト（例えば，ISO 10418及びAPI RP 14Cの安全分析チェックリスト）を使用することが十分

となることもある。設計がより複雑になる，又は新しいプロセスが検討されている場合，より体系的なア

プローチが必要となることもある（例えば，IEC 60300-3-9:1995）。

注記適切な手法の選択に関する更なる詳細については，ISO 17776がある。

特定の故障事象の影響を考慮するときには，すべての起こり得る結果及びそれぞれの結果をもたらす故

障事象の頻度を分析することが望ましい。危険分析からの確かな結果を無視しても破棄してもならない。

設計以上の圧力に配管又は容器をさらすことが必ずしも壊滅的な格納の損失をもたらすとは限らない。多

くの場合，機器が設計以上の試験圧にさらされた場合の唯一の影響は，可燃性物質の漏出とこれによる火

災の可能性である。影響を評価する場合には，工場の機械的安全性に責任がある人々に相談する必要があ

る。最初の試験圧力を考慮に入れる必要があり，当初の設計が腐食許容量を含んでいるかどうか，また，

腐食管理プログラムが適切であるかどうかをも考慮に入れる必要がある。結果がそのような仮定に基づい

ている場合，関連する手順が安全管理システムに組み入れることができるように明記されていることが重

要である。影響を考慮する場合は，特定の潜在危険によって影響されそうな人員数が次の問題となる。多

くの場合，操作要員及び保全要員だけがまれに危険領域にいるので，結果を予測するときには，これらを

考慮に入れることが望ましい。例えば，潜在危険がスタートアップの間に生じ，要員がいつも存在すると

C 0511-2：2008 (IEC 61511-2：2003)

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

いう場合は，すべての場合において妥当とはならないので，この統計的手法を用いるときには注意が必要

である。また，事象を構築する際の兆候を調査する結果として，危険事象が発生する近くにいる人々の潜

在的な増加人員も検討することが望ましい。

SISに対する作動要求の潜在的な発生源を評価する際には，次の状況を含めることが望ましい。

起動操作，連続運用，停止，保全過誤，手動介入（例えば，手動制御），供給停止（例えば，空気，冷却

水，窒素，動力，蒸気，トレースヒーティングなど）作動要求の頻度を検討するときには，複雑な場合は

フォールトの木解析が必要になる場合がある。これは，厳しい結果が二つ以上の同時故障だけによって生

じる場合にしばしば必要となる。潜在危険の原因となるイベントのリスト及び各イベントに使用される頻

度に，オペレータエラーを含むかどうかの判断が必要である。当該業務が手順を進める判断である場合，

又は人の関与しない施設が不適切な業務を防ぐために提供されている場合，オペレータのエラーは考慮さ

れないことがあり得る。また，オペレータ業務による作動要求頻度の軽減及び低減に対する信ぴょう（憑）

性には注意が必要である。この信ぴょう（憑）性は，いかに迅速な対応が必要なのか，及び作業の複雑さ

などヒューマンファクターの問題によって制限することが必要とされる。オペレータがアラームの結果で

行動し，その要求されるリスク軽減が10倍以上の場合，システム全体は，JIS C 0511-1に従って設計する

必要がある。そして，安全機能を行うシステムは，潜在的な危険状態を検出する検出端，警報指示，人間

の応答，及び潜在危険を終了させるためのオペレータが使用する機器で構成される。10倍までのリスク軽

減は，JIS C 0511規格群に従う必要がないと主張できることに注意することが望ましい。このような主張

が行われる場合，人的要因の問題は，慎重に考える必要がある。リスク軽減のためにアラームを使用する

とき，アラームへの対処方法を文書化することが望ましく，オペレータは是正措置を取るのに十分な時間

があり，かつ，オペレータが予防処置を取れるよう訓練することを保証することが望ましい。

SISに関する要求頻度を低減させることによるリスク軽減方法として警報装置を使用することができる。

− 警報装置に使用する検出端は，制御不能がSIFへの要求につながる制御目的には使用しない。

− 警報装置に使用する検出端は，SISの一部として使用しない。

− BPCSと共通原因問題に主張されるリスク軽減に関する制限が考慮に入れられる。

SISのSIL確立に使用できる技法の例は，特定のアプリケーションに使用する方法を選択するときに考

慮する指針を含むJIS C 0511-3に示す。

リスク軽減が必要なことを確証するときには，プロセスの安全性と環境目標とをもつことが必要である。

これらは，特定のサイト又は事業会社に特有で，安全機能を付加しない場合の危険性レベルと比較するこ

とが可能である。リスク軽減の必要性を確立した後に，プロセスを安全な状態へ戻すのにどのような機能

を実行する必要があるかを考慮する必要がある。理論上，機能は，特定技術を参照することなく概括的な

言葉で記述されることがある。例えば，過圧力防護の場合では，機能は，規定値を超える圧力上昇の防止

として記述される。安全弁又はSISのどちらかがこの機能を実行できる。機能が上記のように記述される

場合，次のライフサイクルステップ（安全計装機能の防護層への割当て）で使用する技術の種類を選択す

る。実際には，選択したシステムの形式によって機能条件は異なり，場合によっては機能技術を組み合わ

せる場合がある。

概要すれば，潜在危険と危険分析については，次の事項を考慮に入れることが望ましい。

a) それぞれの明確にされた危険事象と，それを引き起こす事象シーケンス。

b) それぞれの危険事象が関連している事象シーケンスの影響と発生確率。これらは定量的又は質的に表

す。

c) それぞれの危険事象に必要なリスク軽減。

C 0511-2：2008 (IEC 61511-2：2003)

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

d) 潜在危険とリスクを軽減又は取り除くために実施する対策。

e) 想定される要求確率と機器故障率を含んだ，リスク分析中に行った予測。運用上の制約又は人的評価

も詳細に明示することが望ましい。

各SISライフサイクルフェーズで安全関連システムに関連する主要な情報の言及（例えば，検証及び

妥当性確認業務）。

潜在危険及びリスク危険分析を構成する情報と結果は文書化することが望ましい。

潜在危険とリスク評価は，様々な決定がなされ，入手可能な情報がより洗練されるにつれて，総合的な

SIS安全ライフサイクルの異なる段階で繰り返されることが必要になることもある。

8.2.2 BPCSの故障はプロセス産業の多くのアプリケーションで考える必要がある重要な一つの要因であ

る。BPCSの故障は，検出端，弁又は制御システムに起因する場合があることに注意することが望ましい。

プロセス産業に使用する制御システムは，冗長なプロセッサをもっていることがあるが，検出端及び弁

は，通常，非冗長化である。故障率をBPCSに割り当てるときには，重要な制約がある。JIS C 0511-1で

制限する危険な故障率は，この規格の要件に従ってシステムを実現しない場合，特定の潜在危険に関連し

て時間当たり10-5となる。この制限の理由は，下限の危険故障率を要求する場合，JIS C 0511-1の表4の

故障率の範囲にあるということである。この制限によって，JIS C 0511-1の必要条件を満たさないシステ

ムには高いレベルの信頼度が適用されない。

8.2.3 この規格では規定しない。

防護層への安全機能の割当て

9.1

目的

SIS及びその関連SILの必要性を決定するために，他にどんな防護層が存在するか（又は，存在する必

要性）及びそれらがどれほど多くの防護を提供するかを考えることは重要である。他の防護層を考慮した

後で，SIS防護層の必要性を決めることが望ましい。SIS防護層を必要とする場合，このSISの安全計装機

能のSILについて決定することが望ましい。

9.2

割当過程における要求事項

9.2.1 実際には，本質安全な設計又は他の技術システムを用いることに問題があるので，多くの場合SIS

に安全機能を割り当てている。

このような問題の例には，フレア容量の制限又は発熱反応に対する防護がある。安全弁のような従来の

やり方ではなく計器に基づいたシステムを使用する場合は，監督官庁に適切な理由によって支持される必

要がある。

上記のように，潜在危険，リスク評価及び割当ては，同時に発生する業務であることがあり，また，割

当ては，ある場合には潜在危険及びリスク評価の前に行われる。使用者の組織によって実用的であるとさ

れたものに基づき，安全層へ安全機能を割り当てる決定がよく行われる。例えば，安全弁を設置していて，

それらを他の日本工業規格などに従って設計及び設置している場合，これら安全弁はリスク軽減を達成す

るのに適切であると決定されることがある。SISは，安全弁の大きさ若しくは性能がアプリケーションに

対して不十分である場合，又は大気への放出が防止されなければならない場合，圧力だけを制限する。

9.2.2 この規格では規定しない。

9.2.3 安全機能を安全計装機能に割り当てる場合には，アプリケーションが作動要求モードか連続モード

であるかを考える必要がある。プロセス分野におけるアプリケーションの大部分は，作動要求がまれな作

動要求モードで運用している。そのような場合，JIS C 0511-1の表3が適切な尺度である。作動要求が頻

C 0511-2：2008 (IEC 61511-2：2003)

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

繁にある（例えば，1年当たり1回以上の）アプリケーションが存在し，危険側故障確率が主としてSIS

の故障率によって決定されるので，連続モードでとしてみなせるアプリケーションがある。そのような場

合，JIS C 0511-1の表4の適用が適切な尺度である。故障がすぐに危険をもたらすような連続モードのア

プリケーションはまれである。防護システムが制御システムのすべての故障モードにとって不十分である

場合，バーナ又はタービン速度制御が連続モードアプリケーションとなる。

JIS C 0511-1の表3は，SILをPFDavgで定義する。目標PFDavgは，必要なリスク軽減によって決定する。

必要とするリスク軽減は，SISのないプロセスの危険と許容リスクとの比較によって決定できる。JIS C

0511-3の手法を使用し，量的又は質的に決定することが可能である。

JIS C 0511-1の表4では，SIFを実行するための危険側故障頻度の目標の観点からSILを定義している。

これは，特定用途における故障結果を考慮に入れSISの許容できる故障率によって決定される。JIS C

0511-1の表4が必要なSILを決定するのに使用される場合，目標となるのは，SISの危険側故障頻度に基

づいている。JIS C 0511-1の表4を使用する場合，プルーフテスト間隔又は作動要求率を使用して，危険

側故障頻度を作動要求時の危険側故障確率として変換することは誤りである。これは，装置が正常である

かのように見えている間に，JIS C 0511-1の表4の不適切な変換をもたらして，安全機能のSIL要件の不

十分な指定となることがある。

作動要求時の平均機能失敗確率又は時間当たりの平均危険側故障頻度は，個々の構成要素又は下位シス

テムではなく，安全計装機能に適用する。構成要素又は下位システム（例えば，検出端，論理処理部，操

作端）には特定のSIFで使用する以外では，SILを割り当てることはできない。しかし，独立した最高の

SIL能力を主張することは可能である。

“潜在危険及びリスク評価”，及び“割当て”過程の結果では，安全計装機能のための（連続又は作動要

求の運用モードの）SIL要件とともに潜在的なSISを含んだ安全システムによって行われる機能を明確に

記載することが望ましい。これによってSIS安全要求事項仕様の基礎を形成することになる。安全を維持

するのを保証するために必要な機能を明確に記述することが望ましい。

この段階では，検出端及び弁の詳細な構成を指定する必要はない。構成を決めるのは複雑であり，特定

のシステムが検出端2oo3及び弁1oo2を必要とするかどうかは多くの要素に依存する。

9.2.4 JIS C 0511-1の表3及び表4が意味することを完全に理解する必要がある。特に，単一の安全計装

機能に要求することが可能なPFDavgは，10-5 (SIL 4) のリスク軽減に相当する10-5に制限される。信頼性解

析では，ランダムハードウェア故障によるPFDavgは10-5以下の達成が可能であることを示すが，JIS C

0511-1では，決定論的原因故障と共通モード故障が達成可能な実際の値を制限されると推定する。危険分

析が，そのような高いリスク軽減が必要であることを示す場合，プロセス分野におけるSIL 4の安全計装

機能を達成することの困難さに注意すべきことを強く推奨する。安全度の低い複数の独立したSISを使用

することに考慮を払うことが望ましい。

JIS C 0511-1の9.2.4の注記4に関して，次に示す。

複数のSISが，より高いレベルのリスク軽減（例えば，103以上）を達成するために使用されることがあ

る。より高いリスク軽減を達成するために複数のSISを使用する場合，それぞれのSISが独自に安全機能

を行うことができ，かつ，SIS間で十分な独立性があることが重要である。例えば，103のリスク軽減要求

の過圧力安全機能を達成するためにSIL 2圧力検出ループとSIL 1レベル検出ループとを組み合わせること

は，レベル検出端が高レベルを検出する以前に容器がその圧力制限を既に超過していることもあるため，

推奨できるものではない。

さらに，複数のSISを使用する場合には，共通原因故障を考慮することが望ましい。その上，表5で定

C 0511-2：2008 (IEC 61511-2：2003)

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

義した最小の故障許容要求を含むJIS C 0511-1で定義した他の要件のすべてを満たすことが望ましい。

複数のSISの結合が，より高いレベルのリスク軽減を達成するためにどう使用できるかを説明するには，

次の例を考慮する。

2oo3伝送器，2oo3論理処理部，及び1oo2操作端は3.05×10-4のPFDavg付きSISを作り出す。このSIS

は，およそ3.3×103のリスク軽減を実現する。

このような2台のシステムを一緒に使用することによって，10×106 (3.3×103×3.3×103) のリスク軽減

をもたらすと想定するのは不正確である。類似の技術を使用したり，同じ機能仕様，人的要因（例えば，

プログラミング，設置，保全）及び外部要因（例えば，腐食，詰まり，空気路の凍結，雷）から両システ

ムを設計するといった共通原因要素で，システムの改善は制限される。また，2台のシステム間で共有す

る構成要素も考慮する必要がある。

より実現可能な解決策としては，（潜在的な共通原因の問題を最小にするために）できるだけ多様な状態

で構成要素を使用する非冗長な第二のシステムを利用できることもある。

例えば，SISが単一のスイッチ，リレー論理及び単一の操作端を構成し，7.7×10-3のPFDavgをもつシス

テムを構成するとする。このシステムは，およそ1.3×102のリスク軽減を実現する。

ソフトウェアに基づいたSISを単一リレーSISと結合すると4.3×105 (3.3×103×1.3×102) の総合的な理

論上のリスク軽減が得られる。上記のように性能を結合するのが理論的に可能であるように見える一方（ど

ちらのSISもプロセス装置を停止することがあるので），もう一度，共通の原因要素を考慮に入れる必要が

あり，達成できるリスク軽減は，これらの要素によって幾分少なくなることがある。

9.3

安全度水準4にかかわる付帯要求事項

9.3.1 この規格では規定しない。

9.3.2 この規格では規定しない。

9.4

防護層としての基本プロセス制御系に対する要求事項

9.4.1 基本プロセス制御システムは，ある条件に従って防護層として特定されることがある。プロセスリ

スクを軽減するために基本プロセス制御システムで機能を実行する場合，軽減することを意図した特定し

たリスクに対してリスク軽減を基本プロセス制御システムに割り当てることが可能である。

9.4.2 JIS C 0511-1に準拠する必要なく，計装システムに対し10未満のリスク軽減が要求されることがあ

る。これは，JIS C 0511-1の要件をシステムに対して実施する必要なく，あるリスク軽減のために基本プ

ロセス制御システムを使用可能とする。どんな主張でも，基本プロセス制御システムの完全性（信頼性解

析又は性能データで決まる）及び構成，変更，運用並びに保全に用いる手順を考慮することによって正当

化することが望ましい。基本プロセス制御システムの機能にリスク軽減を割り当てる場合には，アクセス

保護と変更管理の提供を保証することが重要である。基本プロセス制御システム機能に対して主張するリ

スク軽減は，基本プロセス制御システム機能と発生原因との間の独立性の程度によって決定する。図2は，

基本プロセス制御システム機能と発生原因との独立性を示す。

C 0511-2：2008 (IEC 61511-2：2003)

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

図2−基本プロセス制御システム機能と発生原因との独立性

例えば，流量制御ループが発生原因である場合，この発生原因には，流量伝送器，制御機器，及び制御

弁が含まれる。基本プロセス制御システムの圧力制御ループへリスク軽減を割り当てるためには，圧力伝

送器は，独立した操作端（例えば，余剰ガス燃焼システムへの通気弁）を調節する独立したコントローラ

に接続することが望ましい。

9.4.3 この規格では規定しない。

9.5

共通原因，共通モード及び従属故障にかかわる要求事項

9.5.1 初期段階で考慮すべき重要な問題は，各層内の冗長部品間（例えば，同じ容器にある二つの圧力リ

リーフ弁間），安全層間又は安全層と基本プロセス制御システムとの間に共通原因故障が存在するかどうか

である。この例では，基本プロセス制御システム系の測定に伴う故障が当該SISに作動要求を引き起こす

ことがある場合，かつ，同一の特性をもつ装置を当該SIS内で使用する場合である。そのような場合，同

時に両方の装置の故障を引き起こす可能性のある確かな故障モードがあるかどうかを明らかにする必要が

ある。故障の共通原因を特定できる場合，次の処置を取ることが可能である。

a) 共通原因は，SIS又は基本プロセス制御システム系の設計を変えることによって軽減できる。多様性

設計及び物理的な分離は，共通原因故障の可能性を軽減させる二つの有効な手段である。通常，これ

は好ましい方法である。

b) 総合的なリスク軽減が適切であるかどうか決定する場合，共通原因となる事象の可能性を考慮するこ

とが望ましい。これには，防護システム故障と同様に作動要求の原因を含んで構成される故障の木解

析を必要とすることがある。そのような故障の木解析に共通原因故障を表すことができ，総合リスク

に及ぼすその効果が適切なモデリング方法を通して定量化することができる。

基本プロセス制御システムとSISとによって共有される任意の検出端又はアクチュエータは，共通原因

故障を導入しやすく，装置のこのような共有の手法は，この箇条で議論されることが望ましい。

9.5.2 共通原因，共通モード及び従属故障の発生の確からしさに関して評価が行われる場合には，次の事

項を検討する。評価の範囲，形式及び深さは，意図する機能のSILに依存する。共通原因，共通モード及

び従属故障の影響は，3以上のSILに対して支配的である。次の事項を考慮することが望ましい。

a) 防護層間の独立性故障モード影響分析は，単一の事象が一つ以上の防護層の故障又は基本プロセス

制御システム及び防護層の故障を引き起こす可能性があることを確証するために実施することが望ま

発生原因

リスク
軽減層

入力
カード1

入力
カード2

出力
カード1

出力
カード2

コント
ローラ
＃1

コント
ローラ
＃2

検出端A

検出端B

検出端C

検出端D

C 0511-2：2008 (IEC 61511-2：2003)

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

しい。その分析の深さと厳しさは，リスクに依存する。

b) 防護層間の多様性防護層と基本プロセス制御システムとの間が多様性であるべきであるが，常に達

成可能ではない。基本プロセス制御システム圧力制御ループの故障が作動要求を引き起こす場合の過

圧力防護が例となる。基本プロセス制御システム及びSISの双方で圧力を測定する必要があり，利用

可能な適当な機器には限界がある。異なる製造業者から機器を採用することで多様性は多少達成でき

るが，SIS及び基本プロセス制御システムの検出端が同種のフックアップを使用してプロセスに接続

する場合は，限られた量になるだろう。

c) 異なる防護層間の物理的な分離物理的な分離は，物理的な原因による共通原因故障の影響を軽減さ

せる。基本プロセス制御システム及びSISの測定接続場所には，精度及び応答時間のような機能的な

必要性に従って最大限物理的に分離することが望ましい。

10 SIS安全要求仕様

10.1 目的

SIS安全要求仕様の開発は，安全ライフサイクルの重要な活動の一つである。この仕様を通し，使用者

は安全計装機能 (SIF) をどのように設計し，SISに織り込むよう望んでいるかを定義することができる。

SISの最終妥当性確認は，この仕様を使用して実行する。

10.2 一般要求事項

10.2.1 SIS安全要求仕様は，単独の文書又は手順書，図面及び会社の標準実例を含む幾つかの文書の集合

であっても構わない。これらの要求は，ハザード並びにリスク評価チーム及び／又はプロジェクトチーム

自身によって開発してもよい。

10.3 SIS安全要求事項

10.3.1 JIS C 0511-1に示すように，安全計装機能が規定どおり機能するよう，プロジェクトの早い段階で

定義されなければならない多くの設計要求がある。

個々のサブシステムの安全要求仕様は，この全体の仕様から得られる。

安全要求仕様に関する検討事項は，次の事項である。

a) 最初に定義する必要のある項目は，SILを伴う安全計装機能である。安全計装機能の例としては，“高

圧の流入口弁を閉止することによって，反応装置を過度の圧力から保護する”ことがある。通常，機

能の概要には次の要素を含む。

1) 危険状態の開始を検出するのにどの測定が必要か。簡単な例として，指定値以上の昇圧を検出する

必要がある。何らかの対応をとるべき値は，通常操作範囲外であり，結果として危険状態を起こす

値よりも低いことが必要である。システムの反応と測定の精度には許容を必要とする。限度を設定

するに当たり，SIS設計と実施担当者との話し合いが必要である。

2) 危険状態を防ぐのに必要な処置。簡単な例として，特定時間内にリボイラーへのスチームの流量を

減らすことがある。リボイラーへのスチームの流動を遮断することが望ましいとの記述では，通常

十分ではないと注意することが望ましい。設計者は，操作の成功に何が必要かを知っておく必要が

ある。加熱において，例えば，流動を1分以内に10 %以下に減小すれば十分かもしれない。2〜3

秒以内に厳重な遮断をすることが必要になる場合もある，ということも他の例としてある。

3) 運用上，有益となることもある危険状態を予防するために不要な対応。そのような対応には，アラ

ームの提示，他の保護システムへの要求を減らすための，又はハザード要因が取り除かれた後に素

早いスタートアップを可能にする上流及び下流ユニットの遮断行動が含まれる。危険状態を予防す

C 0511-2：2008 (IEC 61511-2：2003)

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

るために必要な処置とこれらの不必要な処置とを切り離すことは，費用を削減し安全計装機能の境

界を必要な範囲におさえるために重要である。境界を広く設定しているほど，指定したインテグリ

ティレベルに関連する要求を満たすことを，全体の要求時失敗確率で示すことが困難となる。

4) 危険な状態を引き起こさないために必要な任意の特定のプロセスの状態又はSISの動作。

b) この仕様は，どの流動を起動・停止しなければならないか，どのプロセス弁を開閉しなければならな

いか，及び回転機器（ポンプ，コンプレッサ，アジテータなど）の運転状態など特定の機能としてプ

ロセスの安全状態を定義しなければならない。プロセスを安全状態に導くために，シーケンスが関係

する場合は，シーケンスを特定しなければならない。

注記操作端を定義する場合，多様性の利点を考慮しなければならない（例えば，高圧を軽減する

ために製品の流れの遮断及びスチームの遮断。）。

c) 望ましいプルーフテスト間隔は，SIS設計で考慮されるように，最初に定義することが望ましい。例

えば，プルーフテストを意図的なシャットダウン中に実行するのであれば（例えば，3年ごと），設計

においてもプルーフテスト間隔は1年以下で設計することが望ましい。

d) プロセスを安全な状態に手動操作できなければならない。例えば，オペレータが手動で，制御室又は

現場のいずれかで機器をシャットダウン可能にする要求がある場合は，これを規定しなければならな

い。手動のシャットダウンスイッチのSIS論理処理部からの独立要求も定義しなければならない。

e) シャットダウン後にプロセスを再起動するすべての要求を，規定しなければならない。例えば，使用

者によってはメイン制御パネル又は現場に電子リセットスイッチを備え，他の使用者はラッチ形のハ

ンドル付きソレノイドを使用する。リセット操作のように特定の要求がある場合は，安全要求仕様の

一部としなければならない。

誤トリップの目標頻度は，安全要求仕様の一部としなければならない。これはSIS設計の要因である。

g) SISとオペレータ間のインタフェースを十分に記述することが望ましいが，これにはアラーム（プレ

シャットダウンアラーム，バイパスアラーム，診断アラーム），グラフィック及びイベントシーケンス

の記録を含む。

h) プロセスが稼働している間に，SISをテスト又は整備するバイパスが必要な場合がある。キーロック

又はパスワードのような，デバイスをバイパスするための特定の要求があれば，安全要求仕様の一部

として特定することが望ましい。

故障状態検出時のSISの故障モードと反応を定義しなければならない。例えば，伝送器はトリップ状

態に向けて，又はトリップ状態から遠ざかる方向に故障するよう設計することが可能である。伝送器

がトリップ状態から遠ざかるように設計していれば，伝送器の故障時にオペレータがアラームを受け，

伝送器を修理するために必要な修正操作を早く行えるように訓練されていることが重要である。故障

状態の検出についての要求はJIS C 0511-1の11.3参照。

10.3.2 この規格では規定しない。

11 SISの設計及びエンジニアリング

11.1 目的

この箇条の目的はSISの設計の指針を与えることである。各SIFには，それ自身のSILがある。SISの

構成要素，例えば論理処理部は，異なるSILをもつ数個のSIFによって使用されることがある。

11.2 一般要求事項

11.2.1 この規格では規定しない。

C 0511-2：2008 (IEC 61511-2：2003)

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

11.2.2 この規格では規定しない。

11.2.3 この規格では規定しない。

11.2.4 JIS C 0511-1の箇条11は，SISの設計要求の幾つかを示す。重要な項目の一つに，SISとBPCS間

との独立がある。

SISは，次のa)〜d) に示す理由から通常BPCSと分ける。

a) 特に共通機器を共有する場合に，SISにおけるBPCSの影響を減らすため。例えば，BPCS及びSISが

シャットダウン用及び制御用に共通の弁を共有している場合，危険側故障が発生すると，弁をSISシ

ャットダウン機能実行に利用できない。

b) BPCSの変更，保全，試験及び文書化の柔軟性を維持するため。

注記1 通常SISにはBPCSよりも確固たる要求があるが，BPCSをSISに求めている同じ確固た

る要求の対象にするという目的ではない。しかし，制御されないBPCSの変更がSISの作

動要求増加の原因になることに注意することが望ましい。

c) SISの妥当性確認及び機能安全評価を促すため。

d) BPCSのプログラミング又はコンフィギュレーション機能へのアクセスは，BPCSがSISに結合してい

るのであれば，変更管理処理を満たすように制限する必要があるかもしれない。

共通機器の故障によってSISに対し作動要求を引き起こす場合，全体のハザード率が予想を満たすこと

を保証するため，解析を行うことが望ましい。全体のハザード率は，共通要素の危険側故障率と作動要求

の他の原因（SISの独立した部分の危険側故障を含んだ）とによるハザード率の合計である。

SISとBPCSとの分離は，同一技術又は異なる技術による分離がある。同一技術による分離とはBPCS

及びSIS両方に同じ技術を使用することであり，異なる技術による分離とは同じ又は異なる製造業者から

の異なる技術を使用することである。

ランダム故障に対し役立つ同一技術による分離と比べ，異なる技術による分離は，決定論的原因故障の

確率を減らし，かつ，共通原因故障の確率を減らすという利点がある。

SISとBPCSとの同一技術による分離は，保全エラーの可能性を減らすという理由から，設計及び保全

で幾つかの利点がある。これは特に，使用者の組織の枠内で，以前使用していなかった多種のコンポーネ

ントを選択するケースに当てはまる。

共通原因故障の原因及び影響を考慮し，かつ，その可能性を軽減することが望ましいが，SISとBPCS

との同一技術による分離を，SIL 1，SIL 2及びSIL 3アプリケーションに適用してもよい。共通原因故障の

例を，次のe)〜j) に示す。

e) 器具の接続及び導圧管のつまり

さび及び腐食

g) 環境的な原因によって起こるハードウェア故障

h) ソフトウェアエラー

電源装置及び電力源

ヒューマンエラー

多様性分離は決定論的原因故障（SIL 3及びSIL 4アプリケーションには特に重要な要因）の確率を減ら

し，共通原因故障の確率を減らすという更なる利点がある。

SISとBPCSとの分離が一般的に提供されるエリアは四つある。

1) フィールド検出端

2) 操作端

C 0511-2：2008 (IEC 61511-2：2003)

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

3) 論理処理部

4) 配線

BPCSとSISとの物理的分離が必要ない場合があるが，それには独立を維持し，かつ，該当する機器配

列及び手続きが次の事項によってSISが危険な影響を受けないと保証することが条件となる。

− BPCSの故障。

− BPCSに対して実行される作業。例えば，保全，運用，部分改修。

SISが危険な影響を受けないと保証する手続きが必要な場合，SISの設計者はk)〜m) に示す手続きを規

定する必要がある。

k) 現場検出端単一検出端をBPCS及びSIS両方に使用する場合，更なる検討及び分析を行わなければ

ならない。単一検出端の故障が危険な状態を招きかねないので，追加の検討及び分析は必要である。

例えば，BPCS及びSISの高レベルトリップの両方に同じレベル検出端を使用している場合，検出端

が低レベルで故障すると（すなわち，レベルコントローラのセットポイントよりも低くなると），アラ

ームが発生する可能性がある。検出端が低レベルで故障した結果，コントローラは弁を開く。同じ検

出端がSISに使われているため，結果として起こる高レベル状態は検出されない。

単一検出端をBPCS及びSIS機能両方に使用する場合，検出端診断によって，十分に危険側故障率

が軽減され，かつ，要求された時間内にSISがプロセスを安全な状態に置くことができる場合だけ，

通常，JIS C 0511-1の要求を満たせる。実際には，SIL 1アプリケーションでさえ，これを実現するこ

とは難しい。SIL 2，SIL 3又はSIL 4の安全計装機能には，要求安全度を満たすために，同一又は多様

性の冗長がある別のSIS検出端が，通常，必要である。

注記2 単一の分離したSIS検出端を使用する場合，適切なアイソレータを通してBPCSに信号を

再供給できるかもしれない。そのような構成は，BPCSとSIS検出端との信号比較を可能

にし，自己診断率の向上につながる。

冗長SIS検出端を使用する場合，検出端を適切なアイソレータを通してBPCSに接続してもよい。3

値の中間値のようなBPCSの適切なアルゴリズムは，SISの要求率を軽減することによって，安全を

高めることがある。

操作端検出端の場合と同じ方法で単一弁をBPCS及びSIS両方に使用する場合，更なる検討及び分

析が必要である。一般的には，弁の故障によってSISに要求を引き起こす場合，単一弁をBPCS及び

SIS両方に使用することは推奨しない。

単一弁をBPCS及びSIS両方に使用する場合，弁診断によって十分に危険側故障率が軽減され，か

つ，要求された時間内にSISがプロセスを安全な状態にできる場合だけ，通常，JIS C 0511-1の要求

を満たすことができる。

実際には，SIL 1アプリケーションにでさえこれを実現することは難しい。SIL 2，SIL 3又はSIL 4

の安全計装機能には，要求安全度を満たすために，同一又は多様性の冗長がある別のSIS弁が，通常

は必要になる。

単一弁をBPCS及びSIS機能両方に使用する場合，SISの動作がBPCSの動作より優先することを

保証するように設計することが望ましい。これは通常，アクチュエータにある電源を直接消すソレノ

イド弁に，SISを直接接続することによって実現できる（例えば，弁ポジショナとアクチュエータと

の間）。

冗長SIS弁を使用する場合，弁はSIS及びBPCS両方に接続してもよい。

注記3 冗長弁があっても，BPCS及びSIS弁の共通原因故障の考慮は重要である。

C 0511-2：2008 (IEC 61511-2：2003)

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

弁へ要求する追加事項を，次に示す。

− シャットオフ要求

− 同様のアプリケーションにおける弁の信頼性の経歴

− 弁の安全でない故障モード

− 弁の効力を低下させる運転手順（例えば，開いているバイパス弁）

− プルーフテストの要求

m) 配線非常時起動形システムでは，BPCS及び該当するフィールドデバイス配線は通常，SISと該当す

るフィールドデバイスとの配線から分けるが，これは，予告なしに安全機能を停止してしまう可能性

があるからである。このような種類のシステムのガイドラインは通常，分離した多導体ケーブル及び

SIS並びにBPCS専用のジャンクションボックスの設置を含む。配線を分離しない場合，SISを無効に

するメンテナンスの間に起こる潜在的なエラーを最小限に抑えるため，優れたラベリング及び保全手

続きを使用することが望ましい。

ケーブルサポートシステム（例えば，ケーブルトレイ，導管）は，その他の理由（例えば，電磁波

障害）によって分離が必要でなければ，非常時停止及び非常時起動システム両方に共通であってもよ

い。非常時起動システムでは，火災危険区域であるケーブルトレイに対し防耐火を追加することが望

ましい。

11.2.5 この規格では規定しない。

11.2.6 指針に関しては，11.8参照。

運転員，保守要員，監督者及び管理者全員が，安全なプラント操作に任務を負っている。しかし，時に

人間はエラーを犯し，任務を遂行できない場合があり，これは器具と機器が誤作動や故障をするのと同様

のことである。

よって，ヒューマンパフォーマンスはシステム設計要素の一つである。人間−機械インタフェース

(HMI) は，SISの状態を運転及び保守要員に伝達することにおいて特に重要である。

人間信頼性分析 (HRA) によって，人がエラーを犯す状況を識別し，過去の統計と行動研究に基づいた

エラー率の見積もりが与えられる。科学プロセスの安全リスクを導くヒューマンエラーの幾つかの例を次

に示す。

− 設計における検出されていないエラー

− 作業におけるエラー（例えば，誤った設定値）

− 不適当な保守（例えば，弁を不正な故障動作のある弁に取り替える。）

− 制御システムからの出力の校正，テスト又は解釈におけるエラー

− 緊急時の適切な対応の失敗

注記追加の指針については，次の参考文献を参照。

CCPS/AIChE Guidelines for Improved Human Performance in Process Safety, New York: American

Institute of Chemical Engineers (1994).

CCPS/AIChE Guidelines for Chemical Process Quantitative Risk Analysis (second edition), New York:

American Institute of Chemical Engineers (2000).

HSE Reducing error and influencing behaviour, HSG48, Health and Safety Executive, London (1999),

ISBN 07176 2452 8.

11.2.7 ここでは，トリップ状態の是正後すぐにSISが自動的に再起動すると引き起こる可能性のある潜在

危険について示す。各SIFでは，トリップ状態が是正されたらどのようにリセットを行うべきかを明確に

C 0511-2：2008 (IEC 61511-2：2003)

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

分析することが望ましい。通常，再起動は，オペレータの手動による動作のあとでだけ可能にすることが

望ましい。

11.2.8 SISの論理処理部及びBPCSの制御システム両方から独立している手動の手段によって，緊急の場

合，オペレータがシャットダウンを開始できるようになっている。手動シャットダウンの要求は，通常SRS

に定義する。

緊急停止装置は，潜在危険及びリスクアセスメントチームが必要であり，適切であるとみなすならば，

SIS PE論理処理部（例えば，順次停止が必要な場合）に接続することが可能である。

11.2.9 ここでは，SISとBPCS間だけでなく，SISと他の防護層との独立の必要性を指す（JIS C 0511-1

の図9参照）。

BPCSとSISの分離が不完全でも，ある状況下では容認できる場合がある。これは特に，共通機器の故

障がSISに対するデマンドを引き起こさないというケースに当てはまる。そのようなケースにおいては，

JIS C 0511-1に沿って，共通又は，共有機器をインプリメントする必要がある。

共通機器の故障によってSISに対しデマンドを引き起こすことができる場合，全体のハザード率が予想

を満たすということを保証するため，解析を行うことが望ましい。全体のハザード率は，SISの共通要素

の危険側故障と，他のデマンドの原因となったハザード率（SISの独立した部分の危険側故障を含んだ）

の合計である。共通機器の危険側故障に関連したハザードを立証するに当たり，次のケースを考慮するこ

とが望ましい。

a) 冗長構成の一つの要素をBPCSとして使用する場合，SISのパフォーマンスが故障した機器によって

低下していることを考慮しながら，共通機器の危険側故障によって起こるハザードを考慮する。

b) 共有器具に冗長性がない場合，SISが反応しないと想定し，共通機器の危険側故障によって起こるハ

ザードを考慮する。

11.2.10 BPCS及びSIS両方に共通要素を使用する場合の警告ガイドラインを提供する。注記の“十分に

低い”とは，他の独立した層のPFDを乗じた共有機器の危険側故障率を意味する。

11.2.11 電源喪失で安全状態でなくなる操作端の場合（例えば，非常時起動システム），安全状態を達成す

るためのローカルな手動の手段を提供することを考慮することが望ましい。

11.3 故障検出時のシステム挙動にかかわる要求事項

11.3.1 この規格では規定しない。

11.3.2 この規格では規定しない。

11.3.3 この規格では規定しない。

11.4 ハードウェア故障許容にかかわる要求事項

11.4.1 安全システム設計に対する従来形のアプローチは，ある故障状態一つによって意図した機能が損な

われることがないと保証することであった。1oo2又は2oo3のようなシステムの構成は，危険側故障が一

つでも存在する場合にも要求時では機能が作動するので，故障許容が1となる。ランダムハードウェア故

障に耐えられるよう十分に頑丈だと保証する安全システムの標準的なアプローチとして，そのようなシス

テムが使用された。故障許容構成は，共通原因故障は必ずしも同じ瞬間に起こるわけではないので，広い

範囲の共通原因故障（主にハードウェア）からの保護を与えた。

この規格は，プロセス産業が安全システムの一レベル以上のパフォーマンスを必要とし，かかわる特定

のアプリケーションのリスク軽減の必要性に応じてパフォーマンスを増大させながら，SILの概念を適応

してきたと認める。違うレベルのパフォーマンスが理由で，すべてのSILが故障許容だと想定するのは適

切ではない。あるSILに使用するため構成を選択する場合，ランダムハードウェア故障及び共通原因故障

C 0511-2：2008 (IEC 61511-2：2003)

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

両方に対して十分頑丈であると保証することは，一方で重要である。ランダムハードウェア故障に対して

の頑健性を保証するため，この規格では信頼性解析を行うことを要求する。

この規格のこの部分の要求では，構成に，ランダムハードウェア故障及び幾つかの共通原因故障に必要

な故障許容があると保証することを目的としている。必要な故障許容の範囲を決める場合，考慮すること

が望ましい要因を，次に示す。

− サブシステム内で使用するデバイスの複雑性。故障モードをはっきりと定義し，故障状態における動

作を判断し，かつ，現場体験による故障データが十分である場合，デバイスは共通原因故障の対象と

なりにくい。

− 故障状態が安全状態に導く範囲，又は特定の動作をとることができるように診断によって故障状態を

検出する範囲。

− 関係するアプリケーションのSILの要求。

JIS C 0508規格群を用意した委員会は，上記の要因を考慮し，JIS C 0508-2で故障許容の範囲を規定し

た。このセクター特有のプロセス分野の規格を用意した場合，フィールド装置及びPE論理処理部の故障

許容の要求を簡単にし，JIS C 0511-1の要求を代用として適応できることを検討した。

サブシステムの設計が有用性要件を満たすためにJIS C 0511-1の表5及び表6の記載内容より多くの構

成要素の冗長化を必要とする可能性があることに注意することが望ましい。

ハードウェア故障許容にかかわる要件は，SIFを実行するために必要となる各構成要素又はサブシステ

ムに適用できる。例えば，多くの冗長検出端を構成する検出端サブシステムの場合では，故障許容にかか

わる要件は，個々のセンサではなく，検出端サブシステム全体に適用する。

11.4.2 JIS C 0511-1の表5は，PE論理処理部に対する最小故障許容を定義している。故障許容にかかわ

る要件は，SISに必要なSIL及びサブシステムの安全側故障割合に依存する。論理処理部の安全側故障割

合に関する情報は，通常，PE論理処理部の業者から得ることができる。PE論理処理部がSFFの計算結果

の推測値によって使用されない場合，安全側故障割合の主張は，慎重に扱うことが望ましい。特に推測値

は，SFF計算で想定した境界及び環境が，考えられるアプリケーションに対し有効であることを確実にす

るために検証することが望ましい。これは，SFFは，サブシステムが励磁トリップ又は非励磁トリップで

あるかなどの多くの問題に依存するためである。データソース及びSFFの計算中に行われた推測値は，文

書化することが望ましい。SFFはランダムハードウェア故障だけに関連している。SFFを確立する場合，

初期故障及び経年故障を評価から除外するように，サブシステムがアプリケーションに対して適切に選択

され，的確に設置，引渡し，保守されていることを想定することが望ましい。SFFを決定するとき人的要

因は考慮する必要はない。

11.4.3 JIS C 0511-1の表6は，最初の列で必要なSIL要求制限のある検出端，操作端及び非PE論理処理

部の基本的な故障許容レベルを定義している。表6は，JIS C 0508-2で規定する60 %〜90 %のSFFをもつ

PE装置の要求事項に基づいている。この要件は，支配的な故障モードが安全状態か，又は危険側故障が検

出されるという仮定に基づいている。

11.4.4 この箇条では，PE論理処理部を除いたすべてのサブシステムのハードウェア故障許容をある条件

下で一つ下げてもよい。この条件は，弁又はスマート伝送器などの装置に適用し，JIS C 0508-2の非PE装

置への要件に沿うように決定論的原因故障が起こる可能性を軽減する。

11.4.5 ある場合には，JIS C 0508-2の故障許容にかかわる要求事項に従うことによって故障許容を軽減す

ることも可能である。このことは，サブシステムのSFFが90 %より高くなるように，信号の比較又は定期

的に予定される部分的作動試験のような付加的な診断を導入することによって達成できる。

C 0511-2：2008 (IEC 61511-2：2003)

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

11.5 部品及びサブシステムの選択に関する要求事項

11.5.1 目的

11.5.1.1 この規格では規定しない。

11.5.1.2 この規格では規定しない。

11.5.1.3 この規格では規定しない。

11.5.2 一般要求事項

11.5.2.1 SISに使用するコンポーネント及びサブシステム選択には幾つか検討事項がある。最初の選択肢

はコンポーネントがJIS C 0508-2及び JIS C 0508-3に沿って設計されている。二番目の選択肢は，同様の

サービス及び同様の環境における広範囲の使用で，信頼のおけるコンポーネント及びサブシステムを使用

することである。

どんなオプションを選んでも，当該部品又はサブシステムが次のすべてを満たすことを明示しなければ

ならない。

a) 安全計装機能の総合的な目標PFD又は目標となる危険側故障率を達成するために十分信頼性がある。

b) 構造上の制約条件を満たす。

c) 決定論的原因故障のがい（蓋）然性が十分低い。

c)の要件は，JIS C 0508-2及びJIS C 0508-3に準拠することによって，又は11.5における実績に基づく

要件によって満たすことができる。

11.5.2.2 この規格では規定しない。

11.5.2.3 この規格では規定しない。

11.5.2.4 この規格では規定しない。

11.5.3 実績に基づく部品及びサブシステムの選択に関する要求事項

11.5.3.1 JIS C 0508-2及びJIS C 0508-3に従って設計しているフィールドデバイス（検出端及び弁）は少

ない。よって，使用者と設計者は，実績と経験によって使用しているフィールドデバイスの使用に，より

依存しなければならない。

多くの使用者は各々の施設における使用を承認又は推奨する機器リストをもっている。彼らのBPCSに

おける広範囲な成功した運転経験に基づき，これらのリストは確立されている。希望どおりに動作してい

ない履歴のある検出端及び弁は削除されている。

通常，BPCSの承認又は推奨リストに載っている検出端及び弁は，JIS C 0511-1に規定する評価の対象と

なるSISに対し，実績があると考えることができる。計器類のこのリストは，装置のバージョンを含み，

使用者及び製造業者での現場からの報告を文書化し監視することによって維持することが望ましい。加え

て，製造業者は報告された故障及び変更で評価した変更プロセスももつことが望ましい。

そのようなリストが存在しないのであれば，機器が希望どおりに動作するように，使用者及び設計者は，

検出端及び弁の審査を行わなければならない。このため，他の使用者又は設計者と話し合い，彼らが同様

のアプリケーションに何を使用しているかを知ることが，必要となるかもしれない。

11.5.3.2 より複雑なデバイスでは，得られたアプリケーションの経験が適当であると立証することがより

難しくなる場合があることに注意することが望ましい。例えば，単純なラダーロジックを使用するPLCの

アプリケーションの実績経験による使用は，当該機器が複雑な計算やシーケンスに使用されるのであれば，

適切でないとされる場合もある。

一般的に，フィールド装置の動作形態が関連している局面は，論理処理部のものと異なる。

フィールド装置について，次のa)〜d) に示す項目が動作形態の一因となる。

C 0511-2：2008 (IEC 61511-2：2003)

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

a) 機能性（例えば，測定，動作）

b) 動作範囲

c) プロセスの属性（例えば，化学物質，温度，圧力の属性）

d) プロセス接続

論理処理部については，次のe)〜l) に示す項目が動作形態の一因となる。

e) ハードウェアのバージョンと構造

システムソフトのバージョンと構成

g) アプリケーションソフトウェア

h) 入出力構成

応答時間

プロセス需要レート

すべての装置については，次の項目が動作形態の一因となる。

k) 電磁環境両立性 (EMC)

環境条件

11.5.4 実績に基づいたFPLプログラマブル部品及びサブシステム（例えば，このフィールド機器）の選

択にかかわる要求事項

11.5.4.1 この規格では規定しない。

11.5.4.2 この規格では規定しない。

11.5.4.3 この規格では規定しない。

11.5.4.4 ここでは，FPLプログラマブルデバイスにSIL 3の能力を与えるときの追加的要件を説明してい

る。

11.5.4.5 ここでは，SIL 3の能力をもつFPLプログラマブルデバイスに安全手順書を強制する。

11.5.5 使用実績に基づくLVLプログラマブル部品及びサブシステム（例えば，論理処理部）の選択にか

かわる要求事項

11.5.5.1 ここでは，SIL 1又はSIL 2の能力をもつLVL PE論理処理部に対する追加要件を示す。SIL 3又

はSIL 4の能力をもつLVL PE論理処理部は，JIS C 0508-2及びJIS C 0508-3に従うことが望ましい。

11.5.5.2 この規格では規定しない。

11.5.5.3 この規格では規定しない。

11.5.5.4 この規格では規定しない。

11.5.5.5 ここでは，安全構成型PE論理処理部に対してSIL 1及びSIL 2を達成するための追加要件を示す。

さらに検討すべき事項については，附属書Dを参照。

11.5.5.6 ここでは，安全構成型PE論理処理部に対してSIL 2の能力を達成するための追加要件を示す。

11.5.5.7 ここでは，SIL 2の能力をもつLVLプログラマブルデバイスのために安全手順書を強制する。

11.5.6 FVLによるプログラム可能な部品及びサブシステム（例えば，論理処理部）選定にかかわる要求

事項

11.5.6.1 この規格では規定しない。

11.6 フィールドデバイス

11.6.1 この規格では規定しない。

11.6.2 この規格では規定しない。

11.6.3 この規格では規定しない。

C 0511-2：2008 (IEC 61511-2：2003)

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

11.6.4 この規格では規定しない。

11.7 インタフェース

SISへの使用者インタフェースは，運転員インタフェース及び保全・エンジニアリングインタフェース

である。SISと運転員表示器間とで交信する情報又はデータは，SIS関連又は情報提供のいずれかであるこ

とが可能である。

運転員の動作が安全計装機能の一部であるとき，この動作を行うのに必要なすべてをSIFの一部として

考慮することが望ましい。例えば，運転員にプロセスをシャットダウンしなければならないと告げる警報

が含まれる。この例では，シャットダウンスイッチ（シャットダウン動作を実行する方法）を，SIFの一

部として考慮することが望ましい。

SIFの一部でないデータ通信（例えば，SIF内にトリップ機能が認識された場合の，SIF検出端の実値の

表示）は，安全計装機能が損なわれないのであれば，BPCSに表示される場合がある（例えば，BPCS内の

読み出し専用アクセス）。

11.7.1 運転員インタフェースの要求事項

オペレータとSIS間とでの情報の交信に使用するオペレータインタフェースは，次の事項を含む場合が

ある。

− ビデオディスプレイ

− ランプ，プッシュボタン及びスイッチを含むパネル

− アナンシエータ（視覚及び聴覚の）

− プリンタ（コミュニケーションの唯一の方法であるべきではない。）

− 上記のあらゆる組合せ

a) ビデオディスプレイ表示するデータを参考情報として使うことが条件であるが，BPCSのビデオデ

ィスプレイを，SIS及びBPCS機能が共有する場合がある。さらに，SISによって安全に関する重要な情報

が表示される（例えば，運転員が安全機能の一部である場合）。

緊急時に運転員の動作が必要である場合，オペレータディスプレイの更新・再生割合は，安全要求仕様

に従って行わなければならない。

SISに関連するビデオディスプレイは，緊急時に不明確さ及び運転員の混乱の可能性を避けるように明

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

BPCSの運転員インタフェース及び関連するシステムは，安全計装機能及びBPCSの警報機能の事象を

自動的に記録するために使用する場合がある。

記録する状況には，次の事項を含む。

− SISの事象（例えば，トリップ及びトリップ前の出来事）

− SISがプログラム変更のためにアクセスされるとき

− 診断（例えば，差異など）

運転員が，警報及び／又は運用手順によって，SISの一部にあるバイパスの警告に気付くことは重要で

ある。例えば，SISの操作端のバイパスは（例えば，遮断弁），パネルボードの警報を鳴らすバイパス弁の

リミットスイッチ，又は運用手順で管理するためのバイパス弁のシール及びメカニカルロックを設置する

ことで検出できる。通常，これらのバイパスアラームをDCSから分離しておくことが望ましい。

b) パネルパネルはオペレータが簡単に手が届くような位置にあることが望ましい。

パネルは，押しボタン，ランプ，ゲージ（圧力計，温度計など）及び他の情報のレイアウトがオペレー

タにとって紛らわしくないよう設置されていることが望ましい。異なるプロセス装置又は機器のシャット

C 0511-2：2008 (IEC 61511-2：2003)

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

ダウンスイッチが似ていたりグループ化されていると，緊急時にストレスにさらされている運転員が違う

機器のシャットダウンを行ってしまうかもしれない。シャットダウンスイッチは，物理的に分離され，機

能がラベル付けされることが望ましい。すべてのランプをテストするための手段が用意されることが望ま

しい。

c) プリンタ及びロギング SISに接続しているプリンタが故障，電源が切れる，配線が外れる，用紙切

れ，又は誤作動しても安全機能が損なわれてはならない。

プリンタは，タイムスタンプ及びタグナンバを付けたイベント発生のシーケンス，診断，他の事象並び

にアラームを記録するために有益である。レポートフォーマッティングユーティリティが提供されること

が望ましい。

プリント内容をバッファリングする機能をもつ場合（情報を格納し，要求時又はスケジュールした指定

時刻にプリントする。），情報が失われないようにバッファの大きさを決めることが望ましく，いかなる状

況下でも，バッファメモリの容量不足が原因でSISの機能性が損なわれてはならない。

11.7.1.1 重大な情報を素早く伝えられるよう，オペレータには，一つのディスプレイ内に十分な情報を与

えることが望ましい。表示の整合性は重要であり，使用する警報規則及びディスプレイコンポーネントは，

BPCSディスプレイと整合することが望ましい。

ディスプレイレイアウトも重要である。一つのディスプレイに大量の情報があるレイアウトは，運転員

によるデータの誤解，間違った行動などを引き起こすおそれがあるので避けることが望ましい。混乱の可

能性を軽減するために，色，点滅表示及び適切なデータ間隔の使用によって，オペレータが重要な情報を

探し当てられるようにすることが望ましい。メッセージは明白，簡潔及び明確であることが望ましい。

ディスプレイは，オペレータが色覚障害者であってもデータを認識できるように設計することが望まし

い。例えば，赤又は緑で表示する代わりにグラフィックを埋めるか埋めないかによって示すこともできる。

11.7.1.2 この規格では規定しない。

11.7.1.3 この規格では規定しない。

11.7.1.4 この規格では規定しない。

11.7.1.5 この規格では規定しない。

11.7.2 保全・エンジニアリングインタフェースの要求事項

11.7.2.1 この規格では規定しない。

11.7.2.2 保全・エンジニアリングインタフェースは，SISをプログラム，テスト，保持する方法から成り

立っている。インタフェースは，次の機能に使用する装置である。

a) システムハードウェア構成

b) アプリケーションソフトウェア開発，文書化及びSISの論理処理部へのダウンロード

c) 変更，テスト及びモニタリングを行うためのアプリケーションソフトウェアへのアクセス

d) SISシステムリソース及び診断情報の表示

e) SISのセキュリティレベル及びアプリケーションソフトウェア変数へのアクセスの変更

保全・エンジニアリングインタフェースは，すべてのSISコンポーネント（例えば，入力モジュール，

プロセッサなど）の運転及び診断の状態を，コンポーネント間のコミュニケーションを含み，表示するこ

とが望ましい。

保全・エンジニアリングインタフェースは，アプリケーションプログラムをストレージバックアップメ

ディアにコピーする方法を供給することが望ましい。

保全・エンジニアリングを目的としてSISに接続しているパソコンは，パソコンが故障，電源が切断又

C 0511-2：2008 (IEC 61511-2：2003)

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

は配線が切断されても，安全機能が損なわれるべきではない。

11.7.2.3 この規格では規定しない。

11.7.2.4 この規格では規定しない。

11.7.3 通信インタフェースの要求事項

11.7.3.1 この規格では規定しない。

11.7.3.2 この規格では規定しない。

11.7.3.3 この規格では規定しない。

11.7.3.4 この規格では規定しない。

11.8 保全又は試験設計要求事項

11.8.1 SISの設計は，システムをどのように保守，テストするかを考慮することが望ましい。プロセスの

運転中にSISをテストする場合，配線の切断，ジャンパーの適用，又はソフトウェアレジスターの強制設

定をしないほうがよい。これらの手法を使用した場合，SISのインテグリティが損なわれるかもしれない

からである。システム設計では，検出端，論理処理部及び操作端の完全なシステムのテストを安全に達成

するために，SISの技術的及び手続上の要件を規定することが望ましい。

プロセスの運転中にSISをどのように保守するかを定義することは重要である。例えば，伝送器又は弁

を保守する場合，プロセスの安全を維持しながら，いかに誤トリップを発生させずに，保守部門がこれら

の機器を保守するか検討することが望ましい。

操作端のテスト期間の制限を，SIFのPFDavgの計算に考慮することを注意することが望ましい。

11.8.2 この規格では規定しない。

11.8.3 バイパスの設置は，SISのセキュリティレベルを下げる場合がある。セキュリティの低下は次の事

項によって，克服できる。

a) パスワード及び／又はキーロックスイッチを使用する。設計によっては，適切なバイパスを含むロッ

クキャビネットを組み込んでいる場合がある。

b) 配管のバイパスの明白な識別は，弁のポジションをシールする (sealing)，又は適切なポジションの重

要性を示す安全サインを設置するかのいずれかによって達成できる場合がある。

例えば，1oo2検出端の構成に対して，ある使用者は一度に両方の検出端をバイパスさせることを好むが，

他のものは，検出端ごとに別にバイパスさせるのを好む。両方の検出端をバイパスする場合，リスクが許

容範囲にとど（留）まるように適切な処置が必要となる。どちらも可能であるが，設計の早い時期に取り

組むことが望ましい。

同様に，プロセスの運転によっては，プロセス運転中の弁の動作は適さないし，更に，バイパスを弁の

周りに設置するのは非実用的かもしれない。このような場合には，設計時にSISのテストを実用的な範囲

で可能にすることが望ましく，すなわち，少なくともソレノイド弁によって可能にする。この場合，ソレ

ノイドの周りのバイパスの幾つかのタイプは，通常のアラーム，又はこのバイパス用の手順上の制御を伴

う設計に含むことができる。

11.8.4 この規格では規定しない。

11.9 SIFの機能失敗確率

11.9.1 SISの設計がランダムハードウェア故障に関連する性能を満たす保証が得られる手法の指針に関

して，使用者と設計者は，附属書Aを参照するとよい。

11.9.2 附属書 Aのほとんどの手法は，SISの自己診断率の定量化を要求する。診断は，安全又は危険側

故障をもたらすSISの故障状態を検出するために自動的に行うテストである。

C 0511-2：2008 (IEC 61511-2：2003)

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

ある特定の診断技術では，通常，可能な故障状態すべてを検出できるわけではない。診断の有効性評価

はどのような故障状態に対応できるかを示すために使われることがある。JIS C 0508-2の7.4.4.5及び

7.4.4.6は，診断項目を決めるための要求仕様を示す（自己診断率をどのように計算するかの例については，

JIS C 0508-6の附属書Cを参照。）。

SISの自己診断率の向上は，SILの要求を満たすために役に立つかもしれない。この場合，SISの故障確

率（作動要求モード）又は故障の頻度（連続モード）を計算するときに，自己診断率及び診断テストの期

間（診断テスト間隔）の両方を考慮しなければならない。更なる指針については，JIS C 0508-6の附属書

B又はISA TR 84.00.02を参照。

SISが唯一の防護層である状況下で，連続モードで運転する安全機能にSISを使用する場合，プロセス

又は基本プロセス制御システムで故障が発生したとき，SISのインテグリティを保証し，安全状態を確保

できるように，SISの故障状態を検出できる診断テスト間隔にすることが望ましい。

これを実現するために，診断テスト間隔及び安全状態を達成する応答時間の合計は，“プロセスの安全時

間”よりも短くすることが望ましい。プロセスの安全時間は，プロセス又は基本プロセス制御システム（危

険事象を引き起こす潜在性を伴う。）の故障発生と，安全計装機能が作動しない危険事象の発生との間の時

間帯として定義する。

共通コンポーネント（CPU，RAM，ROMなどの故障同様）の重大及び潜在的に重大な故障状態は，通

常，データ処理のほとんど全体を抑制しているので，単一出力ポイントの故障状態よりも更に広範囲に及

ぶ。高い故障確率の故障モードを，より強い自信を伴って検出できるようになる。さらに，故障モードの

検出可能性を考慮しなければならない。

それぞれの実装した診断については，テスト間隔及び故障状態検出時の結果的に取る動作が安全要求仕

様を満たしていることが望ましい。

製造業者が提供した機器で，“内蔵形”でない診断の場合は，外部構成による診断がSIFのSILを満たす

ためにシステム又はアプリケーションレベルで実装されてもよい。

決定論的原因エラー（ソフトウェアのバグに類似）を診断で検出することが不可能である場合がある。

しかし，決定論的原因故障を検出する適切な予防対策を実施してもよい。

診断は，次に示す様々な方法の組合せを使用して，実現してもよい。

a) 検出端

1) アップスケール又は，ダウンスケールへ完全に故障した検出端を検出するのに診断アラームが提供

されることがある。これを達成する一つの方法に，範囲外警報の使用がある。例えば，高温におけ

る冗長温度伝送器を伴うトリップアプリケーションは，下方向の範囲外警報を伝送器の故障又は伝

送器の断線の診断に使うことがある。

2) 冗長伝送器を使用する場合，アナログ値の比較によって，運転中に発生する異常を検出する。三つ

の伝送器が使用される場合，三つの読取値の真中が使用できる（中央値の選択）。適切に機能してい

ないデバイスによって平均値はゆがめられるため，中央値の選択は，平均値との比較よりも有利で

ある。各読取値の大きな偏差は，次の事項によって生じることがある。

− 導圧管の詰まり又は氷結

− パージ供給圧力の減小

− 温度計保護管のコーティング処理

− 接地工事又は電源に関する問題

− 出力値の固定による伝送器の無反応

C 0511-2：2008 (IEC 61511-2：2003)

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

3) 検出端の位置又は検出端の技術が原因による，プロセスの変化に対する検出端の反応のばらつきに

よって発生する誤報を防止するために，検出端に時間遅延が与えられる場合がある。例えば，冗長

の流量検出端によっては，1秒〜2秒の遅れがある。診断アラームを開始する目的で，冗長な検出端

の読み込みのモニタ及び標準的な偏差を計算するために，製造業者が幾つかのソフトウェアパッケ

ージを出している。

4) 検出端の診断のもう一つの方法は，関連する変数の比較である（例えば，フロー積算値とタンクレ

ベル変化，又は圧力と温度との関係）。

b) 操作端

1) 操作端からのフィードバックと要求した状態との比較（例えば，リミットスイッチ及びポジション

伝送器）は，予定どおりの動作が行われたかを確認するために行う場合がある。十分な時間遅延は，

動作途中の弁のアラームをフィルターするのに使用されることが望ましい（例えば，完全に開いた

状態から完全に閉じた状態）。弁が正常動作（例えば，バッチ動作）の一部として周期的に安全な状

態に変化する場合は，操作端からのフィードバックと要求した状態との比較は診断と考えられる。

2) スマート弁，アクチュエータ，ソレノイド及び／又はポジショナは，自己診断能力をもつことがあ

る。

c) 論理処理部安全用又はJIS C 0508規格群対応PE論理処理部は，様々な故障を対象とする診断機能

をもつ。種類及び範囲は，通常，安全手順書に示す。

d) 外部構成の診断この種の例として，ウォッチドッグタイマー及びエンドオブラインモニタが含まれ

る。

信頼性データの確かさに関するJIS C 0511-1の11.9.2 c)の注記に関する平均故障時間 (MTTF) は，蓄積

された運転時間(T)の間でサンプル部品に生じた故障数(n)を記録することによって，通常決定される。

MTTFの結果から信頼性水準は，χ二乗検定（信頼性，保全性及びリスク，D J Smith' ISBN 0 7506 5168 7

参照）によって得られる。これは，一般に，SISの信頼性の計算に使用するMTTFの値が，T/nとして計算

されたMTTFの値より更に低くなることを意味する。この減衰因子は，より高い必要な信頼水準及び観測

された故障の下限数に対して高くなる。しかし，一般に，信頼性のモデルが関連している他の不確実性源

と比べて，70 %の信頼水準では，減衰因子は，重要でないと推定するのが妥当である。

12 ユーティリティソフトウェアの選択基準を含むアプリケーションソフトウェアの要求事項

ここでは，次の事項を使用する場合，経験上SIL 3とSIL 2以下のアプリケーションソフトウェア設計方

法との間で，相違はあまりないので，区別していない。

1) FPLs 又はLVLsのいずれか，及び

2) JIS C 0511-1対応論理処理部，及び

3) 相当する安全手順書

異なるSILの試験及び検証には，相違があってもよい。12.7.2.3参照。

12.1 アプリケーションソフトウェアの安全サイクル要求事項

12.1.1 目的

12.1.1.1 この規格では規定しない。

12.1.2 要求事項

12.1.2.1 この規格では規定しない。

12.1.2.2 注記1及び注記2：JIS B 3503のラダーダイアグラム又はファンクションブロックダイアグラム

C 0511-2：2008 (IEC 61511-2：2003)

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

のような制約可変言語を，アプリケーションソフトウェアの設計，実施，適合確認(verification)及び妥当性

確認(validation)に使用する場合，図3に示すスタンダードなソフトウェアである“V”モデルの，二つのレ

ベルだけに適応すればよい。この場合，使用するファンクションブロック（複数）はJIS C 0508-3に準拠

していると想定し，次のように解釈する。

a) “アプリケーションソフトウェア構成の設計”は，ソフトウェア設計がハードウェア構成に一致する

ことを保証することによって，SIFそれぞれのソフトウェアに適応する。

b) “アプリケーションソフトウェア開発”は，JIS C 0508-3及びJIS C 0508-4に準拠する制約可変言語

を使用した，安全ロジックの設計及び実施として解釈する。

c) “アプリケーションソフトウェアテスト”は，適合確認(verification)及びアプリケーションソフトウェ

アのテストとして解釈する。

d) “アプリケーションソフトウェアのSISサブシステムとの統合”は，制約可変言語にインプリメント

されているそれぞれのプロセス安全機能の統合及び適合確認(verification)として解釈する。

JIS C 0508規格群のSIL 3に準拠するPLCを使ったアプリケーションソフトウェア開発のライフサイク

ルの例を，附属書Dに示す。

JIS C 0508規格群に準拠する制約可変言語を使用し，新しい“ファンクション”又は“ファンクション

ブロック”をインプリメントする場合（例えば，共通バーナーインターロックシーケンス，ポンプインタ

ーロックシーケンス）は，次のe)〜f) のように解釈する。

e) “V”モデルにおける“アプリケーションモジュール開発”は，新しい機能の設計及び実施として解

釈する。

“アプリケーションモジュールテスト”は，新しい機能の適合確認(verification)及びテストとして解釈

する。

新しい機能を完全可変言語で記述する場合は，ソフトウェアコードの開発が必要となるが，“V”モデル

（図3）が示すように，開発者はJIS C 0508-3に定義するすべてのライフサイクル工程及び手順に従うこ

とが望ましい。

C 0511-2：2008 (IEC 61511-2：2003)

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

コード開発&テスト
- FVLだけ ‒
JIS C 0508-3参照

SIS

安全要求仕様

アプリケーション

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

12.2

アプリケーション

モジュール開発

12.4.5

アプリケーション
モジュール試験

12.4.6

PESアプリ

ケーション

ソフトウエア

統合試験

12.5

妥当性確認
されたSIS

出力
適合確認

サブシステム

構成

アプリケーションソフ

トウェア構成設計

12.4.3及び12.4.4

SIS安全
妥当性確認

12.3

アプリケーショ
ンソフトウェア

開発 12.4.5

アプリケーション
ソフトウェア

試験 12.4.7

注記特に指示がない限り，この図の箇条番号は，JIS C 0511-1を引用している。

図3−ソフトウェア開発ライフサイクル（Vモデル）

12.1.2.3 この規格では規定しない。

12.1.2.4 ここでは，方法，技法及びツールの選択に関する検討事項を示す。

必要な品質をもつソフトウェアの一因となる可能性のある方法，技法及びツールを選択するには，アプ

リケーションソフトウェアに対して次の重要な品質パラメータを検討する。

a) 単純さ

b) 適切な解説及び自然言語のサポート

c) アプリケーションを反映する細分化

d) 試験範囲

e) サポートプロセスにかかわる人員の理解しやすさ

他の関連アプリケーションソフトウェアとのスタイルの共通性

重要なパラメータを特定する手法には，次の事項を含む。

g) 運用及び保全を含む利害関係者との議論

h) 現行方式及び工業規格のレビュー

製造業者の推薦のレビュー

前の経験の分析

k) 同輩との議論

次の検討事項を考慮して重要な品質パラメータ，最適化する方法，技法及びツールを選択する。

方法及び手法は，開発中のアプリケーションソフトウェアに故障状態を取り込むリスクを最小限にする

ように選択することが望ましい。次の検討事項を含めてよい。

C 0511-2：2008 (IEC 61511-2：2003)

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

明確な構文及び意味

m) アプリケーションへの適合

n) アプリケーション開発者による理解度

o) SIFに重要な特性の保証（例えば，ワーストケース実行時間）

p) 類似のアプリケーションでの成功例

q) 安全でない使用方法を制限することを目的とした規則と制約

ツールの選択では，その実用化において人的ミスを抑えるように方法及び手法を実行することが望まし

い。これには，次の検討事項を含めてよい。

r) 開発チームの適切なメンバーによるツールの熟知

類似のアプリケーションでのツールの成功例

ツールの危険な特質の使用を制限することを目的とした規則と制約

u) すべてのツール及びSISの正確なバージョンの文書化

v) 異なるツール間及びSISとの互換性

w) アプリケーションソフトウェアドキュメントを作成する能力

ライフサイクルフェーズの間に使用されるツールの代表例には，次の事項が含まれる。

x) アプリケーションコードジェネレータ

y) 構成管理

z) 静的分析器（例えば，タグネームチェッカー，スキャンタイムチェッカー）

aa) シミュレータ

ab) ソフトウェアテストプログラムを含むテストハーネス

ac) エンジニアリングワークステーション

考えられる他の方法，技法及びツールには，メトリクス測定（例えば，試験網羅度）及び機能の検証を

高める異なるツールの使用（例えば，連続したツール，バックツーバックツール）を含める。

ソフトウェアに既に存在する故障状態を明らかにし取り除くために，開発ライフサイクルを通じて検証

することが望ましい。代表的な手法を，12.7.2.3に示す。

ソフトウェアに残っている故障状態が容認できない結果に至らないことを保証するために，次の事項が

考えられる。

ad) オンラインチェックのテクニックと例外処理

ae) 製造業者施設外データベースの使用及びグローバルな故障状態報告

af) SIS故障報告及びプロセスにおける問題並びにそのSISへの影響を監視する。

ag) 他のシステムでの重要なSIS機能性の複製

ah) 教育・訓練過程中でSISアプリケーションソフトウェアの複製の使用。

SISのライフタイムを通じてソフトウェアを維持することを保証するために，次の事項を検討すること

が可能である。

ai) 変更管理用プログラム（JIS C 0511-1の箇条17参照）

aj) 継続した管理サポート及び保全に関する教育・訓練

ak) サポートツールの有用性及びSISのライフタイムを通じた開発プラットホーム

al) SISのライフタイムを通じて適切な人的資源及び技能を促進するために文書で十分に立証された，及

び好んで広く使用される方法

am) ソフトウェアの変更の効果を理解し，制限することを容易にするのを目的とした開発及びドキュメン

C 0511-2：2008 (IEC 61511-2：2003)

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

テーション規定の使用

an) 現状及び最新の文書

ao) オフラインで開発及びテストする能力

12.1.2.5 この規格では規定しない。

12.1.2.6 この規格では規定しない。

12.1.2.7 この規格では規定しない。

12.1.2.8 この規格では規定しない。

12.2 アプリケーションソフトウェアの安全要求事項

12.2.1 目的

12.2.1.1 この規格では規定しない。

12.2.2 要求事項

全体のSIS構成は，規定した安全計装機能に対し，追加の機能ソフトウェア要求を課すことがある。典

型的な例には，検出端の自己診断による危険側故障の検出時における特定の安全動作に加え，冗長検出端

のための1oo2選択ロジックがある。附属書Bの例に，適用する構成に起因する要求を示す。

アプリケーションソフトウェアには，PESが提供する診断に関する事項も考慮することが望ましく，論

理処理部の安全マニュアルが定義する適切な動作を取り入れるように開発することが望ましい。

それぞれの安全計装機能の安全要求の詳細は，通常，ロジックダイアグラム又は因果関係記述図を使用

して定義できる。多くの場合，論理処理部の製造業者によって提供されるプログラミング言語を，要求を

定義するために使用できる。使用できる典型的な言語は，ファンクションブロックダイアグラム又は因果

関係図である。選択された製造業者が提供する言語は，アプリケーションに適することが望ましい。製造

業者が提供する言語を，要求の詳細の定義に使用すると，他の形でのドキュメントから要求を置き換える

ときに生じるエラーを，しばしば避けることができる。コメントの自由な使用は，安全及び非安全機能並

びにすべての安全機能のSIL要求を明記するために与えることが望ましい。

機能安全要求仕様の詳細は，保護するプロセスのすべての運転モードにおける，すべての必要な機能を

含むことが望ましい。さらに，安全計装機能の周期的なテストが提供されることが望ましい。このために

通常，検出端及び操作端を，プロセスをシャットダウンせずにテストするための，メンテナンス強制書き

込みの機能を明らかにする必要がある。上のパラグラフに記述されているのと同じ方法論は，これらの要

求を文書化するのに使用できる。

複数のSISが安全計装機能の実装に使用される場合，どの機能をそれぞれのSISに実装するかを説明し

たドキュメントを提供されることが望ましい。複数のSISを同一の安全計装機能を実装するために使用す

るなら，それぞれのSISの相互作用及び独立を文書化することが望ましい。このドキュメントには，それ

ぞれのSISが提供することが望ましいと想定されるSILを含むことが望ましい。

追加の指針については，10.2.1及び10.3.1を参照。

12.2.2.1 この規格では規定しない。

12.2.2.2 アプリケーションソフトウェアの開発に先立ち，使用者は，安全計装機能及びそのSILに関して

ソフトウェア安全要求事項を特定するのに使用されるプロセスのリスク及び潜在危険を提供する。一度，

安全計装機能をソフトウェアで実現することを決めたら，ソフトウェア設計者に注意を促すための安全要

求仕様のいかなる矛盾，相違及び省略も明示することが望ましい。例えば，ソフトウェア内の安全計装機

能の実行順序が影響を及ぼすかもしれない。別の例では，電源停止に関連してアプリケーションソフトウ

ェアの応答が影響を及ぼすかもしれない。

C 0511-2：2008 (IEC 61511-2：2003)

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

12.2.2.3 アプリケーションソフトウェア安全要求事項は，SIF安全要求仕様に対し追跡可能な事項として

開発することが望ましい。処理する要素を，次に示す。

a) ユーザ定義SIFを実行するために必要な機能性とタイミング要件

b) プロセスと人とのソフトウェア・システム・インタフェース

c) アプリケーションソフトウェアによって提供するプロセスの潜在危険と機能性との関係

d) プロセスのセーフティ範囲内にとどまるために許されるアプリケーションソフトウェアの挙動の境界

（例えば，誤った入力状態を処理できない。）

e) 論理処理部内のユーティリティソフトウェアが許容できる機能性（例えば，安全論理及び入出力通信，

エラー処理，システム診断の優先順位）

アプリケーションソフトウェアを実行するハードウェアプラットホーム，システムソフト，ハードウ

ェア及びシステムソフトウェアの構成

g) ソフトウェアが一部分であるシステムの機能の結果としてプロセス内で主じる潜在危険（例えば，電

源を取り外すときの不適当なハードウェア故障モード）

h) 補助論理処理部のための安全手順書によって設計者が使用することができる方法及び手順に関する規

制

開発プロセスの後半段階で困難を避けるために，アプリケーションソフトウェア要件の達成を示すこと

を意図した戦略を考えることも重要である。

アプリケーションソフトウェアをSISで使用する場合，機能安全評価は，次の事項を含めてよい。

アプリケーションソフトウェア機能がプロセスの潜在危険要件を達成することを示す検査手法

アプリケーションソフトウェアが必要な機能を実施したこと，及びソフトウェアのどんな余分な機能

も危険状態をもたらさないことを示す機能試験

k) アプリケーションソフトウェアが必要な機能を必要なタイミングで実行したことを示す構造試験

アプリケーションソフトウェア機能が危険状態をもたらさないだろうということを示す機能的故障解

析及び影響度分析

m) 開発及び検証の管理したプロセスが適所にあり，正しいソフトウェアバージョンが使用中であること

を示す監査

12.2.2.4 この規格では規定しない。

12.2.2.5 この規格では規定しない。

12.2.2.6 この規格では規定しない。

12.3 アプリケーションソフトウェアの安全妥当性確認計画

追加の指針については，15.2参照。

12.3.1 目的

12.3.2 要求事項

12.3.2.1 この規格では規定しない。

12.4 アプリケーションソフトウェアの設計及び開発

12.4.1 目的

12.4.1.1 この規格では規定しない。

12.4.1.2 この規格では規定しない。

12.4.1.3 この規格では規定しない。

12.4.1.4 この規格では規定しない。

C 0511-2：2008 (IEC 61511-2：2003)

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

12.4.1.5 この規格では規定しない。

12.4.2 一般要求事項

SISに安全なアプリケーションソフトウェアを提供するための多くの手法がある。しかし，安全なアプ

リケーションソフトウェアを達成するために使用する手法にかかわらず，アプリケーションソフトウェア

開発の前に安全ライフサイクルステップが適切に実行されているとみなす［例えば，潜在危険及びリスク

評価，機能的な記述開発，設備（ハードウェア及びソフトウェア）の選択］。

施設に経験・支援もなく，又はトラブルシューティング能力もない場合，次の手法を実行する前に教育・

訓練及び運転経験（望ましくは，非安全アプリケーションにおける）をもつことが推奨される。この効果

を高めるために，同じ環境で同じ設備の他のPE論理処理部使用者との連携を確立することが望ましい。

この手法における信頼度は，SISアプリケーションでのPE論理処理部の使用を決定する重要な要因である。

次にSISのアプリケーションソフトウェアを開発する場合に考えられる項目を示す。

a) アプリケーションソフトウェアを各SIFに対してSILをもつ個別なSIFに分ける。

b) 各SIFのハードウェア構成を理解し，このハードウェアを各SIFアプリケーションソフトウェアに複

写する。

c) このことが過度な複雑化をもたらす場合は（アプリケーションソフトウェアを解釈する高度なプログ

ラマを要求することが多い。），アプリケーションソフトウェアを最適化しない。

d) 製造業者の指示（例えば，安全手順書）によるアプリケーションソフトウェア開発の手法を用いる。

e) 一つのSIFからのアプリケーションソフトウェアを他のどのSIFとも組み合わせない。

施設で教育・訓練が行われ，分かりやすくトラブルシューティングが可能なアプリケーションソフト

ウェア言語（例えば，形，関数）を使用する。

g) アプリケーションソフトウェアドキュメントにある機能的な記述と一致したアプリケーションソフト

ウェアの文書による説明を用意する。

h) アプリケーションソフトウェアをプロセスフローと一致したモジュール方式にする（例えば，最初の

モジュールがSIFと関連がないがSISで必要である共通アプリケーションソフトウェアであり，2番

目のモジュールがプロセスの入口への最初のSIFで，最後のモジュールがプロセスの出口の最後の

SIF）。

各アプリケーションソフトウェアモジュールを徹底的に検証（例えば，シミュレート，レビュー）し，

（ここでは事業並びに保全部門及びすべての後続のステップを含めた）2番目の独立した分析を得る。

プロセスサブシステムを構成するモジュールの組合せを徹底的に検証し，2番目の独立した分析を得

る。

k) SISアプリケーションソフトウェアを徹底的に検証する。

ハードウェアを調べるときには，アプリケーションソフトウェアを使用する（例えば，正しい検出端

又は操作端に接続した入出力を確認する。）。

m) プロセスの試運転（例えば，危険物なしでのプロセス運転）でのアプリケーションソフトウェアの試

験を含める。

n) 施設に引き継ぐ手順の間（例えば，引渡し），アプリケーションソフトウェアのサポートが可能である。

アプリケーションソフトウェア文書は，各SIF及びSILへのアプリケーションソフトウェアの適合性を

確定するために使用する。独立した分析は，アプリケーションソフトウェアがSILに適合していることを

確定するために行うことが望ましい。

JIS C 0508-3及びJIS C 0508-6は，代わりの手段及び追加的な指針を与える。

C 0511-2：2008 (IEC 61511-2：2003)

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

12.4.2.1 この規格では規定しない。

12.4.2.2 アプリケーションソフトウェアの設計及びテクニックの選択の指針は，SIL 3までの安全要求の

システムは，JIS C 0508規格群に準拠するシステムの一部として，製造業者の安全マニュアルに示す指示

（複数）に基づいて，設計されることが望ましい。SIL 4システムについては，開発者は更に，選択した方

法がJIS C 0508-3の要求に準拠することを確認することが望ましい。

アプリケーションソフトウェアテスト，適合確認の方法，テクニックの選択の指針，及びSIL 3までの

安全要求のシステムは，12.7に示す指針に基づいて適合確認することが望ましい。SIL 4システムに関して

は，更に，適合確認者は，選択した方法がJIS C 0508-3の要求に準拠することを確認することが望ましい。

12.4.2.3 この規格では規定しない。

12.4.2.4 一般に，試験をしやすくするために，アプリケーションソフトウェア統合試験仕様書を設計及び

製作段階の間に検討することが望ましい。

12.4.2.5 SISにおけるアプリケーションソフトウェアが，異なるSIL の安全計装機能を実装する場合，そ

れらの安全計装機能を明白に分離し，ラベル付けすることが望ましい。この結果，それぞれの安全計装機

能のソフトウェアは，冗長化構成の適切な検出端及び操作端を追跡することができる。また，機能（複数）

の機能性及び妥当性確認のテストを，SIL に相応させることができる。このラベリングによってSIF及び

SILを特定することが望ましい。

非安全及び安全計装機能のためには，分離したエリアのソフトウェアを使用することが望ましい。適切

な独立を立証する一つの方法は，次のすべてに準拠することである。

a) アプリケーションソフトウェアの安全計装機能をSIFアプリケーションコードとして明確にラベル付

けする。

b) アプリケーションソフトウェアの非安全計装機能を明確に分離する。

c) 安全計装機能の実施に使用するすべての変数をラベル付けする。

d) 非安全計装機能の実現に使用するすべてのアプリケーションコードを非安全計装機能コードとしてラ

ベル付けする。

e) 非安全変数及びSIF変数を使用するすべてのアプリケーションコードは，次の条件を満たす。

1) 非安全アプリケーションコード（プログラム，関数及びファンクションブロック）が，安全アプリ

ケーションコードを使用するSIF変数に書き込みしない。

2) 安全アプリケーションコードは，安全計装機能を実現する上で，任意の非安全変数に依存しない。

すべての安全アプリケーションソフトウェア（すなわち，コード及び変数）は，非安全ソフトウェア

の変更から保護される。

g) 安全及び非安全アプリケーションソフトウェアが，同一のリソース（例えば，CPU，オペレーティン

グシステムリソース，メモリ，バス）を共有する場合，安全アプリケーションソフトウェアの安全計

装機能（例えば，応答時間）は絶対に損なわれない。

理想的には，アプリケーションコード間（SIF及び非安全関連）とすべての変数（SIF及び非安全関

連）の相互作用は，アプリケーション開発ソフトウェアによって自動的に検査されることが望ましい。

この機能がない場合は，アプリケーションソフトウェア開発者並びにアプリケーションソフトウェア

の適合確認及び妥当性確認を実施する他の人員は，すべてのアプリケーションコードと関連する変数

が，上記の分離ルールに適合しているかどうか検査することが望ましい。

12.4.2.6 この規格では規定しない。

12.4.2.7 この規格では規定しない。

C 0511-2：2008 (IEC 61511-2：2003)

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

12.4.3 アプリケーションソフトウェア構成にかかわる要求事項

通常の論理処理部において可能なソフトウェア構造の種別は，かなり制限されているが，これはアプリ

ケーションプログラムの開発における主要なステップを見れば最もよく理解できる。開発者は通常，アプ

リケーションプログラムの開発及びテストにおいて次の主要なステップを実行する。

a) 入出力モジュール及びメモリ変数のデータ領域を構成する。

b) すべての入出力及びメモリ変数のタグ名を作成する。タグ名は，一貫性のある規則に従うことが望ま

しい。

c) メンテナンス強制書き込みの技法を定義する。使用者によっては，メンテナンス強制書き込みを開始

するため，デジタル入力点を通して配線されたスイッチを要求する。他の使用者は，ディスプレイス

テーションからSISへの管理されたデータ入力を使用する。いかなる場合でも，意図しない強制書き

込みを避けるために，安全な取扱いを保証しなければならない。メンテナンス強制書き込みを，通知

することが望ましい。

d) 検出端の診断，操作端の診断及び周期的なテストの原理を定義する。これは，検出端及び操作端の冗

長に依存する。この原理を慎重に定義する必要があり，テストの最中にアラームを適切に発生させる

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

e) SIS周辺の他のシステムに対する通信用変数を定義する。変数が，メモリ変数の場合，通信サブシス

テムからアクセスできるように，変数を適切なデータ領域に割り当てなければならない。SIS周辺の

他のシステムによって変更可能な変数を，慎重に定義することが望ましく，通常，メモリの特別な読

み込み／書き込み領域に置くことが望ましい。

イベントをどこでどのように記録するかを定義し，SISに対する影響を理解する。

g) カスタム関数及びカスタムファンクションブロックを開発する。アプリケーションプログラムで反復

性の操作をプログラム，テスト及び繰返し使用できるようにするために，これらを開発することが望

ましい。

注記関数，ファンクションブロック及びプログラムは，JIS B 3503に定義がある。

h) プログラム内に含む安全計装機能及びその他の機能を決定する。安全及び非安全機能を，別々のプロ

グラムに分け，安全のクリティカルなプログラムに重点を置くことが望ましい。機能を抑えてプログ

ラムを小さくすることも望ましい。

アプリケーションプログラムを開発する。アプリケーションプログラムの構成は，プロセスの構成と

一致していることが望ましい。例えば，化学プラントでは，それぞれのプロセス装置のアプリケーシ

ョンソフトウェアは，一緒にグループ化されることが望ましい。それぞれのプロセス装置内では，理

解及びメンテナンスを簡単にするために，機能ごとに機器間を分離することが望ましい。

すべてのアプリケーションプログラムの実行順番と望ましい実行率の範囲内で，ネットワーク及びロ

ジックの適切な実行順番を決める。アプリケーションプログラムの実行率は，ソフトウェア安全要求

仕様が要求するプロセス応答時間と矛盾していないことを確認する。

k) 開発環境のモニタリング能力を使用して（利用可能である場合），アプリケーションソフトウェアをテ

ストする。

アプリケーションソフトウェアを，論理処理部にダウンロードする。

m) 論理処理部のすべての入力と出力，アプリケーションソフトウェア，及びSIS周辺の他のシステムと

のインタフェースをテストする。

12.4.3.1 この規格では規定しない。

C 0511-2：2008 (IEC 61511-2：2003)

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

12.4.3.2 この規格では規定しない。

12.4.3.3 この規格では規定しない。

12.4.3.4 この規格では規定しない。

12.4.3.5 安全データ水準の適合確認の例を次に示す。

a) 範囲外入出力データの確認

b) 通信したアプリケーションデータの妥当性確認

c) タグ名の一貫性の確認，例えば，同一タグ名の重複使用の確認

d) 強制書き込みの妥当性確認，例えば，メンテナンス強制書き込みとスタートアップ強制書き込みの妥

当性確認

e) アラーム及びセットポイントの妥当性確認

12.4.4 支援ツール，取扱説明書及びアプリケーション言語にかかわる要求事項

開発環境とは，アプリケーションソフトウェアのコーディング，アプリケーションパラメータ及びイン

タフェースのコンフィギュレーション並びにアプリケーションソフトウェア実行のテスト及び監視をサポ

ートするツールのセットである。開発環境は，通常，次の機能をもつ。

a) コンフィギュレーションエディタ。このエディタで，入出力のサブシステム，入出力のメモリ変数及

びコミュニケーション機能を定義する。

b) 言語エディタ。アプリケーションプログラマは，これらのエディタで（安全及び非安全）システムに

必要なすべての機能を実行するプログラムを開発する。

c) 認証済みの関数及びファンクションブロックのライブラリ。これらの関数とファンクションブロック

は，アプリケーションプログラムで利用することができる。

d) カスタム関数及びカスタムファンクションブロックの開発能力。製造業者によっては，サポートして

いるアプリケーション言語で利用できるカスタム関数及びカスタムファンクションブロックを，使用

者が開発できるような開発環境を提供している。これらのカスタム関数及びカスタムファンクション

ブロックを，アプリケーションプログラムで使用する前に徹底的にテストすることが望ましい。

e) アプリケーションプログラムのスケジューリング機能。これらのスケジューリング機能は，望ましい

シーケンスの実行順序及び頻度を設定する。

ダウンロード能力。これは開発者が，アプリケーションソフトウェア，ファンクションブロックラ

イブラリ，変数データ及び他のコンフィギュレーション情報を，これらを実行する論理処理部ハード

ウェアにダウンロードできるようにする。

g) エミュレーション能力。製造業者によっては，開発環境をサポートするコンピューター上で，すべて

のアプリケーションプログラムをエミュレートする能力を備えた開発環境を提供している。この結果，

アプリケーションプログラムの徹底的なオフラインテストを，論理処理部にダウンロードする前に行

える。

h) プログラムモニタリング能力。モニタリング能力は，使用者が定義する画面上又はファンクションブ

ロックダイアグラム若しくはラダーダイアグラムのプログラム画面上で実行しているプログラムのデ

ータを，使用者が見られるようにする。開発環境は，エミュレータの実行をモニタする能力も提供す

る場合がある。更に，論理処理部において実行しているプログラムを，モニタすることが可能である。

論理処理部の診断ディスプレイ。これらのディスプレイは，システムの主要なプロセッサモジュール，

コミュニケーションモジュール及び入出力モジュールの状況を表示する。通常，それぞれのモジュー

ルのパス(pass)，フェイル，アクティブステータスを表示する。多くの場合，システムの故障状態に関

C 0511-2：2008 (IEC 61511-2：2003)

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

する，より詳細な情報を表示する。

12.4.4.1 この規格では規定しない。

12.4.4.2 この規格では規定しない。

12.4.4.3 この規格では規定しない。

12.4.4.4 実績のある及び／又は日本工業規格などに適合したアプリケーション言語変換器が好ましい。

12.4.4.5 この規格では規定しない。

12.4.4.6 この規格では規定しない。

12.4.4.7 安全手順書の例

この規格に準拠する安全アプリケーションに使用するコンポーネント及びデバイスは，設置，保守，コ

ンフィギュレーション，プログラミング及び運転すべてに関する認識されている様態の詳細を記述してい

る文書とともに提供されるべきであり，コンポーネント又はデバイスが，アプリケーションの安全要求仕

様を満たす場合，遵守されることが望ましい。

この文書は，しばしば，コンポーネントあるいはデバイスの“安全手順書”と呼ばれる。しかしこれは，

製造業者の標準設置，メンテナンス及びユーザマニュアルから成り，更にSIFアプリケーションにおける

使用に関する特徴，これらのアプリケーションにおける使用の制限，診断アラーム時に取るべき動作及び

認識されている故障モードを規定する，追加ドキュメントを伴う。また，コンポーネント及びデバイスを

SIFアプリケーションに使用する場合は利用するべきではない。機能，コンフィギュレーション及び／又

はプログラムのステートメントタイプを定義することが望ましい。

制約可変言語を使用したプログラミングは，グローバルなデータの使用を可能にする。したがって，安

全手順書は，データ変数の正しい使用を精査及びチェックするため，プログラミングツールの使い方に関

するプログラマにとっての指針となることが望ましい。他には，メモリマッピング，ステータスフラグの

チェック及び入力値に関するバリディティチェックを含むことがある。また，グループ内のプログラマが

類似の形式及びスタイルのプログラムを作成できるように，説明書及び例が安全手順書の一部として，又

はアプリケーション特有のドキュメントとして提供されることもある。これらの説明書には，アルゴリズ

ム又は関数が安全に影響する予想外の挙動をもたらせないように，プログラムで使用してはいけない特定

のアルゴリズム又は機能の詳細を含めることが望ましい。

プログラマは，安全手順書に定義した内容を超えたどんな推測もしないよう，例えば，当該安全手順書

から削除されるコンパイラの機能を使用しないように注意することが望ましい。理想的に，コンパイラ

は，これらの制限を実行するように構成されているであろう。

代表的な安全手順書の構成及び内容

表1に，JIS C 0511規格群に準拠する典型的な論理処理部のための代表的な安全手順書の構成及び主な

内容を示す。

C 0511-2：2008 (IEC 61511-2：2003)

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

表1−代表的な安全手順書の構成及び主な内容

箇条

主な内容

序文

一般情報，機器要求，マニュアル構成，規則，関連文書，リリース
履歴，用語集，製品概要

設置

サイト計画環境，プロセス接続，スタートアップ手順，シャットダ
ウン手順，アプリケーション修正，既に運転しているシステムへの
機能の実装

構成及びアプリケーション構
築

設計考慮事項a)，容量及びパフォーマンス，チュートリアル

ランタイムオペレーション

製品運転，操作概要，操作説明書

保全

予防的保全，ハードウェア表示，エラーメッセージ，アプリケーシ
ョン及びシステムアラーム，故障状態検出及び使用者による修理

付録

システムメッセージ，チェックリスト，アプリケーションの解決法

索引

安全メッセージの索引

注a) 設計考慮事項は，安全PLCの安全コンフィギュレーション及びプログラミングに関連し，コン

フィギュレーション及びアプリケーションすべての特徴を規定する。これらは，次の事項を含む
が，次の事項に限られているわけではない。
− 論理処理部処理時間，入出力更新レート，コミュニケーションレート，論理処理部操作シー

ケンス。

− システムアラームの取扱要求。
− コンフィギュレーション及びプログラミングの制限。

12.4.4.8 この規格では規定しない。

12.4.5 アプリケーションソフトウェア開発にかかわる要求事項

アプリケーションソフトウェアの開発を進める前に，次の事項を検査することが望ましい。

a) SIS論理処理部と関連する入出力モジュールは，JIS C 0511-1に準拠することが望ましい。

b) JIS C 0511-1に準拠するために必要となるすべての制限及び運用手順は，ユーザドキュメンテーショ

ン又は論理処理部の製造業者によって発行されたドキュメントに提供されることが望ましい。これら

のドキュメントは，一般に安全手順書と呼ばれる。

c) プログラマブル電子機器を活用している検出端及び操作端は，JIS C 0511-1に準拠することが望まし

い。

d) 周期的なオンラインテストを行う場合，メンテナンス強制書き込みの能力を，検出端及び操作端のテ

ストを行うために提供する場合がある。

アプリケーションソフトウェアは，通常，論理処理部製造業者又は知能型現場機器製造業者が提供する

プログラミング言語で書かれる。アプリケーションは，インストラクションリスト若しくはCのような完

全可変言語 (FPL)，ファンクションブロックダイアグラム若しくはラダーダイアグラムのような制約可変

言語 (LVL)，又は使用者が固定プログラムに必要とするデータを入力するだけの固定プログラム言語

(FPL) を使用して書かれる。

アプリケーションソフトウェアをFVLで書く場合，開発者はJIS C 0508-3の要求及びガイドラインに従

うことが望ましい。アプリケーションソフトウェアをLVL又はFPLで書く場合，開発者は，JIS C 0511-1

の要求及びガイドラインに従ってもよい。開発者は，論理処理部の製造業者が安全手順書で規定する制限

及び手順に従うことが望ましい。プログラミングガイドライン及びコーディングコンフィギュレーション

規則も，必要な場合は開発し，使用することが望ましい。

C 0511-2：2008 (IEC 61511-2：2003)

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

12.4.5.1 この規格では規定しない。

12.4.5.2 この規格では規定しない。

12.4.5.3 アプリケーションのグローバル変数の例には，プロセスのバッチ構成物質によって変化する高温

アラームのような安全アラームがある。

アプリケーションのグローバル定数の例には，防火システムに使用される可燃ガス高アラームの限界が

あり，例えば，20 %のLEL（爆発限界の下限界）がある。

12.4.5.4 この規格では規定しない。

12.4.5.5 この規格では規定しない。

12.4.5.6 この規格では規定しない。

12.4.6 アプリケーションソフトウェアモジュール試験にかかわる要求事項

アプリケーションソフトウェアのテストは，初めはシミュレータ上で，それから論理処理部のハードウ

ェア上で，設計及び要件仕様段階で作る仕様に対して行うことがある。初期段階でのテスト（設計仕様に

対するシミュレーション及びテスト）の目的は，次のとおりである。

a) ソフトウェアモジュールが必要な機能をもち，かつ，禁止動作を起こさないことを明示する。

b) 様々な状態及び実行段階で予期外の動作が起きた場合，ソフトウェアが正しく機能することを示す。

その後の試験段階（統合試験及び立会検査）の目的は，アプリケーションソフトウェアが，指定したハ

ードウェア及び定義した時間内で，その要件を実現することを示すことにある。

試験の最終段階，すなわち，総合システムが意図する環境で，意図するデバイス及びインタフェースを

もち，定義した運用手順で正しく動作することを立証することは，全体システムの設置及び引渡し後とな

る。

正式な試験の段階から，ソフトウェア機能及びコンフィギュレーションデータに及ぶすべての変更は，

定義した変更手順に従って厳密に実行されることが望ましい。

12.4.6.1 この規格では規定しない。

12.4.6.2 この規格では規定しない。

12.4.6.3 この規格では規定しない。

12.4.7 アプリケーションソフトウェア統合試験にかかわる要求事項

12.4.7.1 この規格では規定しない。

12.4.7.2 この規格では規定しない。

12.4.7.3 この規格では規定しない。

12.5 アプリケーションソフトウェアのSISサブシステムとの統合

12.5.1 目的

12.5.1.1 この規格では規定しない。

12.5.2 要求事項

12.5.2.1 統合テストは，SISの妥当性確認までのあらゆる工程で実施しても構わない。

12.5.2.2 この規格では規定しない。

12.5.2.3 この規格では規定しない。

12.6 FPL及びLVLソフトウェア部分改修の手順

12.6.1 目的

12.6.1.1 この規格では規定しない。

12.6.2 部分改修の要求事項

C 0511-2：2008 (IEC 61511-2：2003)

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

SISの運転中での部分改修は，可能な限り避けることが望ましい。運転中の部分改修を要求する場合，

完全な手順を文書化し，安全計画に沿って承認することが望ましい。

次のプロセスが，プログラマブルSISのすべての修正に対して推奨する。

a) 計画及びリソースプログラマブルSISの部分改修するプログラムを，管理，計画し，変更の実施が

安全であると保証するように適切なレベルまでリソースすることが望ましい。

b) 影響解析要求される部分改修は，システムの変更していない部分のあり得る影響すべてを含み，完

全な危険及びリスク評価が必要となる場合がある（安全影響解析）。

c) 設計設計の部分改修は，JIS C 0511-1に記述する，完全なライフサイクルプロセスに従うことが望

ましい。

d) 適合確認ハードウェア及びSISソフトウェアに対する，完全なオフライン（運転中でない）の適合

確認は，変更を実施する前に完了することが望ましい。

ソフトウェア変更の境界線を明白に線引きし管理できる場合，線引きした範囲内のアプリケーショ

ンソフトウェアだけを引渡し前に適合確認する必要がある。

e) 設置と引渡し変更の設置及び引渡しは，JIS C 0511-1で定義するSISの設置及び引渡しの手順に従

うことが望ましい。

適応テストの妥当性確認 (validation) システムの妥当性確認（因果関係テスト）は，運転中のシステ

ムに部分改修を適応する前に，システムの部分改修部分に実施する。

g) 人員トレーニング及び専門知識に基づき，部分改修を実施できると確認した人員だけに，部分改修

を実施する権限を与えることが望ましい。

h) オフラインでの部分改修アプリケーションソフトウェアの変更（部分改修）をオフラインで実行す

る場合，操作パラメータを含むアプリケーションソフトウェアの正しいバージョンを使用しているこ

とを検証することが望ましい。

12.6.2.1 この規格では規定しない。

12.7 アプリケーションソフトウェアの適合確認

12.7.1 目的

12.7.1.1 この規格では規定しない。

12.7.1.2 この規格では規定しない。

12.7.2 要求事項

アプリケーションソフトウェアの安全要求仕様は，次の事項を含む。

a) 安全計装機能要求（例えば，安全計装機能のSIL，ロジックフローダイアグラム因果関係図）

b) タイミングの制限（例えば，入力から出力の最小応答時間）

c) 構成上の制限（例えば，冗長要求，通信インタフェース，機能分離）

適合確認は，アプリケーションソフトウェア開発のそれぞれの工程で，特定の要求を満たしていると保

証する。

データの適合確認は，アプリケーションソフトウェア内で使用したデータが正しく，適切な範囲内でユ

ニークであることの確認を含む（例えば，TAG名がユニークに割り当てられている，データが後続の機能

によって誤用されない，アラームのセットポイントのような定数が有効で正しいということなど）。

認可されていない変更からの保護の適合確認は，メカニズムが存在するかどうかの適合確認，又は（例

えば，アクセスレベルをもったパスワードによる保護），これらのメカニズムが適切に活用しているかどう

かの適合確認(verification)を含むことが望ましい。

C 0511-2：2008 (IEC 61511-2：2003)

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

12.7.2.1 この規格では規定しない。

12.7.2.2 この規格では規定しない。

12.7.2.3 アプリケーションソフトウェア開発サイクルの（試験を含む）それぞれの異なったフェーズで，

検証によってフェーズが首尾よく完成したことを確認する。検証は，一般に，一人以上の検証チームが行

う。

先入観的思考によるエラーを抑えるために，検証は次の事項を含むことが望ましい。

a) SIL 1に関して，アプリケーション開発チームの別のメンバーによるピアレビュー

b) SIL 2に関して，アプリケーション開発のメンバー以外の人によるピアレビュー

c) SIL 3に関して，独立した部門のメンバーによるピアレビュー

ソフトウェア開発ツールがある自動検査機能［例えば，タグ（名前付き変数）の二度の使用のチェック］

を含む場合，検証チームは，ツールを適切に使用し，正しい結果を得ていることを確認することが望まし

い。

すべてのSILに関して，試験の適用範囲がすべてのアプリケーションソフトウェアSIFとSIS故障応答

を網羅していること（例えば，電源異常，プロセッサの故障，入力ハードウェアの故障，出力ハードウェ

アの故障，通信障害）が推奨される。しかし，ソフトウェアに残っているすべてのエラーを更に抑えるた

めに，より高いSILについては，次の追加試験の実施を推奨する。

d) SIL 2とSIL 3に関しては，内部構造（例えば，内部アルゴリズム，内部状態）に基づいた試験。

e) SIL 3に関しては，ストレス試験（例えば，入力変数及び内部変数の異常な範囲，入力，異常シーケン

ス，ローディングの異常な組合せ）。

すべてのSILに関して，検証及び試験に関するドキュメントは，検証及び試験が行われ，成功したこと

を示すのに十分であることが勧められる。また，より高いSILに関しては，次の事項を推薦する。

SIL 2及びSIL 3については，ドキュメントで検証及び試験の妥当性の評価をするのに十分である。

g) SIL 3では，ドキュメントは，独立している人が試験を繰り返し，達成した適用範囲をレビューするの

に十分であることが望ましい。

12.7.2.4 この規格では規定しない。

13 立会試験 (FAT)

13.1 目的

13.1.1 この規格では規定しない。

13.2 推奨事項

13.2.1 立会試験 (FAT) を行うのは，要求事項ではないが，FATは，かなり複雑なアプリケーションロジ

ック又は冗長ロジック（例えば，1oo2，2oo3，1oo2Dなど）をもつ安全計装機能を実行する論理処理部に

推薦される。

13.2.2 FATの最も重要な部分は，どのようにアプリケーションロジックをテストするか，また，各試験ス

テップで何を確認すべきかを定義した，明確でよく構成された試験手順を用意することである。

FATは，SIS運用に関する初期の教育・訓練を行うので，プロセスを操作する要員は，FATに出席する

ことが望ましい。また，しばしば，設計中では予期しない試験手順に良い提案又は強化を提供することも

ある。

13.2.3 この規格では規定しない。

13.2.4 この規格では規定しない。

C 0511-2：2008 (IEC 61511-2：2003)

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

13.2.5 FAT中に，インタフェースをテストすることが望ましい（例えば，BPCSとSISとのコミュニケー

ション）。

13.2.6 この規格では規定しない。

13.2.7 この規格では規定しない。

14 SISの設置及び引渡し

14.1 目的

14.1.1 この規格では規定しない。

14.2 要求事項

14.2.1 この規格では規定しない。

14.2.2 SISは，設計及び設置計画ごとに設置されることが望ましい。設計からのどんな逸脱も，設計要件

のすべてが，まだ満足していることを保証するためにプロジェクトチームとともに適切に見直すことが望

ましい。SISの適切な設置後，完全に引き渡され，妥当性確認業務を開始することが望ましい。

14.2.3 JIS C 0511-1では, 引渡しを単一のフェーズとして処理しているが，アプリケーション，プロジェ

クトチーム及びプロジェクトによって，引渡しが数段階で完了されることを要求している場合もある。

14.2.4 この規格では規定しない。

14.2.5 この規格では規定しない。

15 SIS安全妥当性確認

15.1 目的

15.1.1 SIS安全妥当性確認の目的は，SISが安全要求仕様で記載した要求事項を達成することを確認する

ことにある。妥当性確認業務は，SISを稼働させる前に完了させることが望ましい。

15.2 要求事項

15.2.1 この規格では規定しない。

15.2.2 この規格では規定しない。

15.2.3 この規格では規定しない。

15.2.4 SISが既に立会試験 (FAT) を終了している場合，このことは，妥当性確認の間，考慮に入れても

よい。妥当性確認チームは，アプリケーションソフトウェアのすべてが首尾よく試験され，FATの間に見

つけたすべての問題を修正してあることを保証するためにFATの結果をレビューすることが望ましい。

最終の妥当性確認のときにアプリケーションソフトウェアを繰り返しテストすることは不要である。こ

れは次の場合に適用する。

a) この手法が妥当性確認計画で予期され含まれていた。

b) アプリケーションソフトウェアがFATの間，安全要求仕様を満たすために検証されていた。

c) アプリケーションソフトバージョンがFATで試験されたのと同じバージョンであることが検証される。

しかし，出荷の損傷，格納時の損傷，及び取扱上の損傷がなく，すべての検出端及び操作端が正しく論

理処理部に接続され，安全計装機能が適切に作用し，オペレータインタフェースが必要情報の提供を保証

することは非常に重要である。SIS妥当性確認を要求するためにプルーフテストに相当する試験が強く勧

められる。これは，論理処理部及び現場で使用する要素の個別の試験が完全な終端間プルーフテストと同

等でないからである。

15.2.5 この規格では規定しない。

C 0511-2：2008 (IEC 61511-2：2003)

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

15.2.6 この規格では規定しない。

15.2.7 この規格では規定しない。

15.2.8 この規格では規定しない。

16 SISの運用及び保全

16.1 目的

この規格では規定しない。

16.2 要求事項

16.2.1 この規格では規定しない。

16.2.2 この規格では規定しない。

16.2.3 この規格では規定しない。

16.2.4 この規格では規定しない。

16.2.5 この規格では規定しない。

16.2.6 この規格では規定しない。

16.2.7 この規格では規定しない。

16.2.8 この規格では規定しない。

16.3 プルーフテスト及び検査

16.3.1 プルーフテスト

16.3.1.1 プルーフテスト間隔は，安全要求仕様で必要とされるように，必要に応じて，故障の平均確率を

達成するために選択されることが望ましい。

16.3.1.2 この規格では規定しない。

16.3.1.3 プルーフテストの頻度は，適切なメーカーの提言と良いエンジニアリング方式と一致していて，

以前の操業経験によって必要であることが決定した場合，より頻繁に行うことが望ましい。SIFのプルー

フテスト間隔の選択に使用する多くの戦略がある。

例えば，ある使用者は，プルーフテスト間隔を，維持費とテストの潜在的な影響を最小にするためにで

きるだけ長くしたがる。この場合，SISの設計は，設備の冗長化，診断適用範囲の増加，及び丈夫なコン

ポーネントとなることがある。そして，設計の終了後に，SIFに対して定義したSIL性能を達成させる最

大のテスト間隔を決定する設計につき，計算が行われることがある。この設計理念の欠点は，プラントの

各システムが異なるテスト間隔で実施され，より厳しい合法性への対応が必要となることがある。また，

性能曲線の一番低い性能に向けての設計が促されるかもしれない［例えば，PFDavg=10-1（SIL 1システム用）

として，又はPFDavg=10-2（SIL 2システム用）］。

他の使用者は，定義されたテスト間隔に基づいて，標準化することを，又は同じテスト間隔で，製造プ

ラントのすべてのシステムをテストすることを望んでいるかもしれない。例えば，毎年，各SIFのテスト

を望み，それに従って各SISを設計する。その結果，設計を始める前に，プルーフテスト間隔をあらかじ

め選択することによって，法人使用者は，ほとんどのアプリケーションに対してSILを満たす構成，構成

要素，及び診断適用範囲をあらかじめ選択できる。その法人規格で既に定義されたこれらの特徴によって，

ほとんどのアプリケーションに対して設計・エンジニアリングコストを削減する。この場合，必要なSIL

性能があらかじめ選択したプルーフテスト間隔を満たしていることを保証するために，計算がSISに対し

実行されることが望ましい。

プルーフテスト間隔の選択では，作動要求モードシステムのための要求率，テストするそれぞれのコン

C 0511-2：2008 (IEC 61511-2：2003)

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

ポーネントの故障率，及びシステム全体の性能要件を考慮することが望ましい。

注記操作端を作動することが実用的でない場合の使用では，次の手順を含むことが望ましい。

a) 装置が停止している間に操作端をテストする。

b) オンライン試験中可能な限り，出力（例えば，出力トリップリレー，シャットダウンソレノ

イド，部分的な弁の動き）を作動させることによって，SISをテストする。

c) 操作端のテスト期間のいかなる制限も，SIFのPFDavgの計算のときに考慮することが望まし

い。

16.3.1.4 この規格では規定しない。

16.3.1.5 この規格では規定しない。

16.3.1.6 この規格では規定しない。

16.3.2 検査

JIS C 0511-1で記載してあるように，SISの検査は，プルーフテストとは異なる。プルーフテストは，SIS

が適切に作動することを確実にし，目視検査は設置のときの機械的確実性を確認するために必要である。

通常，検査は，プルーフテストと同時に行われるが，必要に応じて，より頻繁に実施することが望まし

い。

16.3.3 プルーフテスト及び検査の文書化

所見の記録に対するプルーフテスト及び検査結果を文書化することは重要である。これらの結果の保管

期間については特定の要件はないが，一般に，コンポーネント故障の履歴があるかどうかを確認するため

に前の結果の再検討できる十分な数を保管する。

例えば，検出端がプルーフテストに失敗した場合，この検出端が過去の幾つかのテスト中で同様のプル

ーフテストに失敗したかどうか確認するために前のプルーフテストの結果のレビューを行うのは，良い慣

行である。履歴が繰り返し失敗していることを示す場合，異なる種類の検出端を使ったSISの再設計を考

慮することが望ましい。

17 SISの部分改修

17.1 目的

この規格では規定しない。

17.2 要求事項

17.2.1 この規格では規定しない。

17.2.2 この規格では規定しない。

17.2.3 この規格では規定しない。

17.2.4 この規格では規定しない。

17.2.5 この規格では規定しない。

17.2.6 この規格では規定しない。

18 SIS使用終了

18.1 目的

この規格では規定しない。

18.2 要求事項

18.2.1 この規格では規定しない。

C 0511-2：2008 (IEC 61511-2：2003)

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

18.2.2 この規格では規定しない。

18.2.3 この規格では規定しない。

18.2.4 この規格では規定しない。

18.2.5 この規格では規定しない。

19 情報及び文書化の要求事項

19.1 目的

19.1.1 この規格では規定しない。

19.2 要求事項

19.2.1 SISを実行するのに使用する情報及び文書のリストには，次の事項を含む。

a) 潜在危険及びリスク評価の結果

b) SILを決定するときに用いた仮定

c) 安全要求仕様

d) アプリケーション論理

e) 設計文書

部分改修情報及び／又は文書

g) 検証及び妥当性確認の記録

h) 引渡し及びSIS妥当性確認の手順

SIS運用手順

SIS保全手順

k) プルーフテスト手順

評価及び監査結果

19.2.2 この規格では規定しない。

19.2.3 この規格では規定しない。

19.2.4 この規格では規定しない。

19.2.5 この規格では規定しない。

19.2.6 この規格では規定しない。

19.2.7 この規格では規定しない。

19.2.8 この規格では規定しない。

19.2.9 この規格では規定しない。

C 0511-2：2008 (IEC 61511-2：2003)

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

附属書A

（参考）

安全計装機能の作動要求時の失敗確率を計算する手法例

序文

この附属書は，安全計装機能の作動要求時の失敗確率を計算する手法例について記載するものであって，

規定の一部ではない。

A.1 一般

ここでは，JIS C 0511-1に従って設計及び設置したSISの失敗確率を計算する多くの手法を示す。この

情報は参考情報であり，使用する唯一の評価手法として解釈することは望ましくない。

参照する方法論は，JIS C 0508-6の附属書B，IEC 61078，IEC 61025，IEC 61165及びISA TR 84.00.02

シリーズから引用している。

A.2 信頼性ブロック図手法

IEC 61078及びJIS C 0508-6の附属書Bでは，JIS C 0511-1及びこの規格に従って設計した安全計装機

能の失敗確率を計算する信頼性ブロック図の手法を説明する。

A.3 簡易方程式による手法

ISA TR 84.00.02-2では，JIS C 0511-1及びこの規格に従って設計した安全計装機能の失敗確率を計算す

る信頼性ブロック図の手法を説明する。

A.4 故障の木解析の手法

IEC 61025及びISA TR 84.00.02-3では，JIS C 0511-1及びこの規格に従って設計した安全計装機能の失

敗確率を計算する故障の木解析の手法を説明する。

A.5 マルコフモデルによる手法

IEC 61165及びISA TR 84.00.02-4では，JIS C 0511-1及びこの規格に従って設計した安全計装機能の失

敗確率を計算するマルコフモデルによる手法を説明する。

C 0511-2：2008 (IEC 61511-2：2003)

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

附属書B

（参考）

典型的なSIS構成開発

序文

この附属書は，典型的なSIS構成開発について記載するものであって，規定の一部ではない。

B.1

バックグラウンド

B.1.1 一般

JIS C 0511-1の要求事項を満たすSIS構成を開発する様々なステップを説明する例を，次に示す。SISエ

ンジニアリングは，運用指針及び慣行に従い，ここで概説する標準機器を使用する。

B.1.2 運用指針及び事例

過去において，安全アプリケーションは，“重要計装システム”と呼ばれていた。試験手順と同様にエン

ジニアリング規則，典型的な例及び最優良事例を開発した。

計器の冗長化及び設計事例と同様に，必要な安全計装機能及び防護層分析（JIS C 0511-3の附属書Fに

あるLOPA）をもつSILを決定する指針が存在する。

B.1.3 計装

安全アプリケーションのための計装 (SIS) では，作動要求時失敗確率 (PFD) を計算するために，診断

及び安全側故障割合 (SFF) に関する製造業者情報及びアプリケーションから収集した性能情報も使用す

る。

B.1.4 論理処理部

論理処理部のハードウェア，システムソフトウェア及び開発システムは，JIS C 0508規格群 SIL 3対応

であり，そのアプリケーションプログラム用の制約可変言語をもつ。

システムの安全手順書は，システムアプリケーション及びアプリケーションソフトウェア開発に関する

詳細な指針を示す。

使用者が任意に定義可能な標準的な安全機能（例えば，伝送器故障検出，1oo2，2oo3，出力安全強制書

き込みなどの冗長選択）は，アプリケーションプログラムテンプレートとして利用できる。テンプレート

は，使用者が開発する。

B.2

作業過程

B.2.1 一般

すべてのエンジニアリング業務は，事前に定義した全体のプロジェクト作業の過程で行う。SISの開発

には，それ自身の過程が存在する。個々のステップが全体の過程に割り付けされる。機能安全性評価を適

切な段階で実行する。

B.2.2 典型的なSISライフサイクルステップ

SISの適用を開発するには，次の典型的なステップが必要である。ここでは，ステップ3，ステップ4

及びステップ5のシステム構成に関連する部分についてだけ説明する。

C 0511-2：2008 (IEC 61511-2：2003)

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

ステップ

タイトル

業務

適用範囲

プロセス機器の定義

プロセス機器の機能安全要求事項

危険の潜在性の定義，防護レベル解析
(LOPA) の実施

システム安全要求事項の割当て

SIS構造設計

SIS内安全要求事項の割当て

SISハードウェアの識別

アプリケーションソフトウェアの開発

SISソフトウェアの設計

アプリケーションソフトウェアの検証及び
妥当性確認

SISの試験

設置

現場設置

引渡し

総合受入れ

運用

プロセスの運転

B.2.3 安全要求事項の割当て

LOPAからの利用可能な情報： SIS適用のための安全要求事項の仕様とSIL（例えば，各SIFのための

SIL）

SIL達成に使用されるモデル：

決定PFD：総合PFDは，SIL制限内にある（上記参照）。

簡易方法：冗長タイプ（例えば，1oo2）を含む標準の計装構成，利用可能な診断及びテスト間隔は，SIL

要求事項に関連するテーブルに表すことができる。このテーブルは経験によるデータ及び，施設の中の様々

なプロセスの適用の立証された設計に基づいている。ブロック図へ既知の要素データに代替のシステム構

成を結合すると，最適な選択が可能となる。

SIS構成要素仕様：すべてのシステム構成要素は，JIS C 0511-1で指定している立証された特性（例えば，

PFD，SFF，故障許容，指定SILの決定論的な要件）をもつ。

− 検出端及び操作端を，プロセスの適用のために適切に選択し，運用経験に従い，技術部門が様々な種

類の特徴を標準化する。

− 論理システム：検出端及び操作端の要件に従って入出力を指定する。論理処理部，アプリケーション

言語，開発ツール及び通信インタフェースは，承認した安全装置の一部である。オペレータインタフ

ェースはアプリケーション要件に適合できる。

B.2.4 SIS内の安全要求事項の割当て

この段階では，安全要求仕様のすべての機能をシステムの構成要素，機能又はソフトウェアに割り当て

る。安全度要求事項では，適切なSISのコンポーネント及び可能なSISの構成を決定する。

B.2.5 構成関連アプリケーションソフトウェア要求事項

SIS構成を選択した後，必要に応じて，検出端，論理処理部及び操作端の冗長化（例えば，1oo2）及び

／又は診断機能を実現するために，アプリケーションソフトウェアを指定する必要がある。

B.2.6 アプリケーションソフトウェアの開発

プログラミング言語は，機能ブロック図（制約可変言語）である。コード開発及びテストは，よく知ら

れたプロセスである。さらに，システム安全手順書で詳細に説明する安全機能プログラミングには制限が

検出端構成

論理システム及び

入出力

操作端構成

C 0511-2：2008 (IEC 61511-2：2003)

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

幾つかある。

B.3

例1

B.3.1 一般

ここで使用する例は，確かなシナリオによるものでなく，かつ，他の安全層による共通原因故障を検討

することを除外している。前述のSIS設計プロセスをいかに適用するかを立証する特別な構成となってい

る。

B.3.2 危険なシナリオ

蒸気加熱反応器の温度制御が異常となり，蒸気制御弁を完全に開ける。

B.3.3 SRS及びSIL

安全要求仕様：反応器圧が1 MPaを超える場合，発熱反応を避けるため，20秒以内に反応器ジャケットへ

の蒸気を閉じる。オペレータの動作は必要としない。必要なSILは3である。

B.3.4 システム構成

システムコンポーネント：圧力検出端構成，論理処理部構成，操作端構成。実績経験による使用の知能型

検出端は，論理システムの入力に直結する。

緊急遮断弁は，電磁弁と統合し，論理システムの出力に直結する。すべてのMTTFデータは，実際の運

用経験に基づく。

使用可能な計装：

a) 圧力検出端がJIS C 0511-1の11.4.4に準拠する：MTTF 105 h，DC＝70 %，SFF＝90 %，プルーフテス

ト間隔，毎年，MTTR＝8 h.

b) 緊急遮断弁がJIS C 0511-1の11.4.4に準拠する：MTTF 8×104 h，DC＝0 %，SFF＝60 %，ルーフテス

トを半年ごとに実施，MTTR＝8 h.

単一要素のPFD：

a) 検出端：2.2×10‒3（A.1参照）−許容できない

b) 論理処理部（冗長化）：1.3×10‒4，I/Oインタフェースを含む（認証書から）

c) 弁：2.41×10‒3（A.1参照）−許容できない

許容できる検出端の構成を見出す：1oo2の冗長化の選択

共通原因＝10 %，DC＝90 %（A.1参照）

1oo2検出端構成の新PFD：2.3×10‒4

JIS C 0511-1の表6及び11.4.4をチェックする。実際の故障許容＝1→SIL 3−許容できる

許容できる操作端の構成を見出す：1oo2の冗長化の選択

共通原因＝10 %（A.1参照）

1oo2操作端構成の新PFD：4.65×10−4

JIS C 0511-1の表6及び11.4.4をチェックする。実際の故障許容＝1→SIL 3−許容できる

PFDのチェック：検出端＋論理処理部＋操作端

(2.3＋1.3＋4.7)×10−4＝8.3×10−4＜10−3

B.3.5 付加的構成関連安全ソフトウェア

検出端構成ソフトウェア：上記の1oo2検出端について，信号選択ソフトウェアが，次の事項を生じた場合，

蒸気弁を閉じるようにプログラムしている。

a) 二つの検出端の一つが指定プロセス値を超えた状態を検出する場合

C 0511-2：2008 (IEC 61511-2：2003)

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

b) 診断機能が危険な故障を示す場合

操作端構成ソフトウェア：安全出力動作が安全プログラムで実行する場合，両方の蒸気弁出力はオフとな

る。

B.4

例2

B.4.1 一般

低いSILをもたらす結果及び類例

B.4.2 危険なシナリオ

蒸気加熱反応器の温度制御が異常となり，蒸気制御弁を完全に開ける。

B.4.3 SRS及びSIL

安全要求仕様：バッチ反応器圧が1 MPaを超える場合，発熱反応を避けるため，20秒以内に反応物質“A”

の反応器への供給を遮断する。オペレータの動作は必要としない。必要なSILは2である。

B.4.4 システム構成

システムコンポーネント：圧力検出端構成，論理処理部構成及び操作端構成。実績経験による使用の知能

型検出端を，論理システムの入力に直結する。緊急遮断弁を電磁弁と統合し，論理システムの出力に直結

する。すべてのMTTFデータは，実際の運用経験に基づく。

使用可能な計装：

− 圧力検出端がJIS C 0511-1の11.4.4に準拠する：MTTF 105 h，DC＝70 %，SFF＝90 %，プルーフテス

ト間隔，毎年，MTTR＝8 h

− 緊急遮断弁がJIS C 0511-1の11.4.4に準拠する：MTTF 2.5×104 h，DC＝0 %，SFF＝60 %，ルーフテ

ストを毎週 (168 h) 実施，MTTR＝8 h

単一要素のPFD：

a) 検出端： 2.2×10−3（A.1参照）−許容される

b) 論理処理部（冗長化）：1.3×10−4，I/Oインタフェースを含む（証明書から）

c) 弁：次を参照（公式については，A.1参照）

単一検出端のPFD：

a) 1oo1検出端構成のPFD：2.2×10−3

b) JIS C 0511-1の表6及び11.4.4をチェックする。実際の故障許容＝0→SIL 2−許容される

単一操作端のPFD：（公式については，A.1参照）

PFD = λD×tCE, λD＝1/(25 000×2), tCE＝168 / 2＋8

1oo1 操作端構成のPFD：1.84×10−3

JIS C 0511-1の表6及び11.4.4をチェックする。実際の故障許容＝0→SIL 2−許容される

PFD チェック：検出端＋論理処理部＋操作端

(2.2＋0.1＋1.8)×10−3＝4.1×10−3＜10−2

B.4.5 付加的構成関連安全ソフトウェア

操作端構成ソフトウェア：安全出力動作を安全プログラムで実行する場合，蒸気弁出力はオフとなる。さ

らに，弁が作動するたびに（バッチ当たり一度，通常8時間ごと）弁が安全状態であることを明示する監

視ソフトウェアがある。テストが失敗した場合，又は最後のテスト以来168時間以上が経過している場合，

論理処理部は安全な出力状態（緊急遮断弁は閉状態）となり，警報を発する。この自動テストでは，PFD

計算でプルーフテスト間隔を168時間に設定することができる。

C 0511-2：2008 (IEC 61511-2：2003)

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

附属書C
（参考）

安全PLCのアプリケーション機能

序文

この附属書は，安全PLCのアプリケーション機能について記載するものであって，規定の一部ではない。

ここでは，小規模な安全PLC（例えば，150未満の入出力）をSISアプリケーションで利用するとき，

インテグレータが考える幾つかの重要な段階の概要について示す。初期の設計計画の段階で，読者を支援

するために提示する。

安全PLCは，JIS C 0508規格群による認定SIS論理処理部である。特定の安全アプリケーションにおい

て，検出端及び操作端をSIS論理処理部に接続し，アプリケーションプログラムが実現する。SIS論理処

理部の故障に関連するすべての安全機能（例えば，オンラインチェック，時間管理）は，組込システムの

一部である。検出端及び操作端にとって必要なチェックは，アプリケーションソフトウェア内で行われる。

幾つかの機能に関しては，承認済機能ブロックが存在する。

すべての装置の安全度データ（例えば，PFD，SIL要求限界など）が存在する。論理処理部の安全度デ

ータは，論理処理部のマニュアルに記載している。

C.1 システム

SIS論理処理部は，安全アプリケーションに対して特別にデザインされたPLCであり，JIS C 0508規格

群のSIL 3まで準拠するタイプである。安全関連のプロセス信号及び他の安全PLCとの通信のための入出

力インタフェースをもち，かつ，安全関連でない信号及び通信のためのインタフェースももつ。システム

は，次からなる。

− 機能安全の特別なハードウェア上の特徴，特別なオペレーティングシステム及び故障管理の組込機

能をもつCPU（アプリケーションプログラミング及びソフトウェア統合において，冗長化は開発シ

ステムとして用意される。プログラマは，一つのCPUだけを扱う。）

− 制約可変言語（例えば，機能ブロック図）の開発システム

− 承認された機能ブロックがあるライブラリ

− 安全計装機能パラメータの特別な構成ツール

− ダウンロードされたランタイムアプリケーションソフトウェアがソースアプリケーションソフトウ

ェアと同一であることを確かめるツール

− 安全手順書

C 0511-2：2008 (IEC 61511-2：2003)

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

図C.1−論理処理部

C.2 作業過程

a) 安全要求仕様は，この規格に準拠する。幾つかの重要な検討事項を，次に示す。

1) すべての安全計装機能の仕様

2) アナログ入力範囲

3) 検出端及び操作端のオンライン診断の定義

4) 検出された故障モードの場合のシステム反応の記述

5) 安全計装機能パラメータの定義（例えば，最大サイクルタイム，比較入力の相違の最大許容時間）

6) 安全手順書の制限事項

b) アプリケーションソフトウェア安全要求仕様は，a)から導かれることが望ましい。

安全手順書には，論理処理部のハードウェア (PLC) に関する安全要求事項を記載する。制約事項と

しては，性能限界，記憶容量，応答時間のような項目を主として適用する。ソフトウェア構成及びコ

ード実現の制約事項を，安全手順書に記載する。それらは，PLCの開発システムに言及する。制限事

項の大部分は，制約可変言語の使用によって暗黙のうちに対応できる。

c) アプリケーションソフトウェア構成デザインアプリケーション構成デザインは，安全計装機能及び

プロセスに特定の運用モードを密接に反映することが望ましい。

d) アプリケーションソフトウェア開発アプリケーションソフトウェア開発は，既存の機能ブロックの

使用で容易になる。

e) 統合統合には，構成データ（例えば，入出力テーブル）及びアプリケーションソフトウェアのダウ

ンロード及び初期設定と異なるすべてのパラメータの設定を含む。

検証アプリケーションソフトウェアは，システムの統合の前又はシステム統合の後に検証する。開

発環境は，検証をサポートする。

操作端

論理処理部

検出端

C 0511-2：2008 (IEC 61511-2：2003)

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

附属書D
（参考）

SIS論理処理部のアプリケーションソフトウェア開発方法論の例

序文

この附属書は，SIS論理処理部のアプリケーションソフトウェア開発方法論の例について記載するもの

であって，規定の一部ではない。

この例では，SIS論理処理部のインテグレータが顧客の安全アプリケーションソフトウェアをどのよう

に開発するかを説明する。このソフトウェアは，通常，この附属書で示すシステム全体の統合プロセスの

一部として開発する。

安全アプリケーションソフトウェア開発方法論が重要視されるので，アプリケーションプログラムの開

発に使用したアプリケーションソフトウェア開発ツール，プログラミング言語及びコーディング標準につ

いて論じることが重要である。この議論の目的は，SIS論理に使用するソフトウェア開発ツール，プログ

ラミング言語及び関連言語翻訳プログラムに関する典型的な特徴例を提供することである。

SIS論理処理部には，多くのJIS B 3503言語をサポートするアプリケーションプログラミングソフトウ

ェア開発ツールがある。JIS B 3503では，PLCのはん（汎）用プログラミングのために多くの言語を定義

している。JIS B 3503では，安全の適用に対処しないため，次の事項を決定している。

a) プロセス分野に共通の制約可変言語を使用する。

b) 安全の適用に不適切な言語構築を取り除く。

c) コーディング標準を使用し，クリティカルな適用のための言語構築を更に制限する。

d) アクセス保護及びファイル保護の特徴を取り入れる。

e) JIS B 3503の機能，機能ブロック及びプロセス関連機能（例えば，アナログデータ処理，火災感知器

及びガス検出端）の認定ライブラリを供給する。

アプリケーションプログラミングソフトウェア開発ツール，ライブラリ及び言語翻訳プログラムの第

三者証明を提供する。

これら決定事項については，D.2で更に詳細に説明する。また，D.3でSIS論理処理部プログラマが使用

するコーディング標準の例について説明する。D.4では，ソフトウェア開発ツールのために考慮すべき追

加要件事項について論じる。

D.1 システム全体の統合プロセスの概要

多くの業務から構成するSIS論理処理部をもつ主要なSIS統合サービスは，次の事項を含む。

a) ハードウェアの統合これは，プロセス信号を論理処理部入出力モジュールに接続するための適切な

ターミネーションパネルのあるキャビネットにSIS論理処理部を設置することである。また，通常，

論理処理部及びフィールド装置用の電源と配電装置を含む。

b) アプリケーション論理の定義 SIS論理処理部統合サービスでは，顧客エンジニアと綿密な共同作業

によって，詳細な論理を定義することもある。それぞれの安全計装機能のアプリケーション論理は，

検出端及び操作端の冗長化を考慮に入れ，定義する。プロセスが稼働している間，SISを試験及び保

全するためのインタフェースも顧客の操作上の要求事項を満たすために定義する。付加的な重要でな

い論理も含むが，安全機能と同じ規格に対して厳密に分離し，設計している。

C 0511-2：2008 (IEC 61511-2：2003)

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

c) アプリケーションソフトウェアの実行及びハードウェア構成 SIS論理処理部のための安全認証アプ

リケーションソフトウェア開発パッケージは，SIS論理処理部入出力及び通信ハードウェアを構成す

るために使用する。各安全計装機能及びノンクリティカルなアプリケーションソフトウェアも実行し，

テストする。

d) 立会試験（工場出荷前受入試験）多くの顧客が工場受け入れ試験を実施し，ハードウェア及びアプ

リケーションソフトウェアが正しく操作することを工場へ出荷する以前にチェックする。顧客の技術

者及び他の運用要員がハードウェアとアプリケーションソフトウェアを完全に検査する。

e) SISの顧客サイトでの設置供給者による設置又は監督下での設置は，工場敷地で行う。

工場受入試験 SIS論理処理部に接続するための各検出端及び操作端インタフェースが適切に操作し

ているか，また校正されているかをチェックする。アプリケーションソフトウェア全体及び保全のた

めのバイパス機能のような項目は，再テストする。

g) アプリケーションソフトウェア及びハードウェアの部分改修最初の設置及び稼働の後のアプリケー

ションソフトウェア及びハードウェアの部分改修は，工場で承認した厳密な部分改修手順を用いて実

行する。

D.2 SIS論理処理部アプリケーション開発ソフトウェア

先に述べたように，SIS論理処理部は，JIS B 3503言語に基づいたアプリケーションソフトウェア開発

パッケージを使用した。このソフトウェアは，JIS B 3503の三つの言語，すなわち構造化テキスト，ラダ

ーダイアグラム及び機能ブロックをサポートする。コーディング標準が各言語に必要である。インストラ

クションリスト (IL) は，アセンブリ言語と同様であり，かつ，アプリケーションプログラマに適さない

ため含まれていない。これらは，JIS C 0508-7の表C.1と一致している。

JIS C 0508-3（7.4.4及び表A.3）及びJIS C 0508-7 (C.4) に概要が記述している要件と一致したJIS B 3503

の言語の定義に多くの追加制約を課している。これらには，次の事項を含む。

a) JIS B 3503では，20のデータタイプ（BOOL，SINT，INT，DINT，LINT，USINT，UINT，UDINT，

ULINT，REAL，LREAL，TIME，DATE，TOD，DT，STRING，BYTE，WORD，DWORD及びLWORD）

を定義している。八つの整数データタイプが単独であることに注意することが望ましい。また，これ

らのすべてのデータタイプのサポートは数十の変換と切捨て機能のサポートを必要とする。安全アプ

リケーションには，これらデータタイプの多くは必要ではない。サポートするデータタイプの数は11

に制限される。特定の言語に対して与えられる選ばれたデータタイプは，BOOL，INT，DINT，DWORD，

REAL，LREAL，STRING，TIME，DATE，TOD及びDTである。この決定は，言語サブセットを制

限するJIS C 0508規格群の規定と一致している（JIS C 0508-3の表A.3参照）。

b) JIS B 3503のグラフィック実行制御要素（例えば，無条件ジャンプ，条件ジャンプ，無条件リターン，

条件リターン）の使用は，ループ実行及び実行されるべき要素のバイパスを起こす可能性があるので，

サポートしていない（JIS C 0508-7のC.4.6参照）。

c) 多くの構造化テキスト言語ステートメント（例えば，FOR…END̲FOR, WHILE…END̲WHILE，

REPEAT…END̲REPEAT）は，ルーピングを起こす原因になるのでサポートしていない。

d) 複数のプログラムを同一のグローバル変数へ書き込めないように制限が言語に課せられている。多く

のプログラムがグローバル変数を読めるが，重複使用及び上書きを防ぐために，一つのプログラムだ

けがグローバル変数に書き込むことができる。さらに，複数の書き込みが誤ってプログラムされた場

合，アプリケーションプログラミングソフトウェアは，警告を発する。

C 0511-2：2008 (IEC 61511-2：2003)

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

e) プログラミングソフトウェアでは，プログラムにおけるすべての要素の実行順序を明確に定義するこ

とが望ましい。言語には，実行順序を決め，各実行可能な要素の実行順序を表示するアルゴリズムが

ある。

プログラミングソフトウェアでは，安全のクリティカルソフトウェア及び非安全のクリティカルソフ

トウェアを分離することが望ましい。プログラマは，ソフトウェアの種類を安全プログラムと非安全

プログラムに定義することができる。また，ソフトウェアは，安全及び非安全変数を定義することも

可能である。非安全プログラムは，安全変数に書き込むことはできない。

g) VAR̲IN̲OUT変数の使用は，ほとんどのアプリケーション使用者には非常に分かりにくいことが明ら

かになった。VAR̲IN̲OUT変数の使用については，完全に文書化する必要があり，プログラミング言

語によってサポートすることが望ましくない。

D.3 アプリケーションプログラマのためのコーディング標準

安全アプリケーションソフトウェアの開発を確実にするために，コーディング標準をアプリケーション

プログラマのために確立することが望ましい。次に，アプリケーションソフトウェアをこの特定の開発ソ

フトウェアを使って開発する場合のアプリケーションプログラマが使用する多くの指針を示す。

a) アプリケーションプログラマは，安全計装機能を実行するために制約可変言語（機能ブロック図又は

ラダーダイアグラム）を使用することが望ましい。これらの言語でさえ，制限されることが望ましい

（D.2参照）。

b) 構造化テキスト(ST)は，完全な可変性言語であり，その使用は，制限されることが望ましい。可能な

限り，その使用は，機能及び機能ブロックの実現だけに制限することが望ましい。プログラミングに

たん（堪）能でない操作員が安全プログラムを理解するように制限を加えることができる。

c) プログラムのサイズを妥当なサイズに制限することが望ましい。異なるプロセス装置に対する安全計

装機能は，別のプログラムで処理されることが望ましい。理想的には，プログラムは，一つのプロセ

ス装置に対して少数の安全計装機能を含めるにとどめることが望ましい。

d) エイリアシングは避けることが望ましい。例えば，プログラミングソフトウェアが配列をサポートす

る場合，この配列を使用するプログラムは，配列ポインタをチェックし，それが有効範囲にあること

を確認する。

e) アプリケーションプログラムが安全クリティカル論理と同様に非安全クリティカル論理を含む場合，

非安全クリティカル論理は，別のプログラムで処理することが望ましく，プログラムに組み込んでい

る分離規則を使用することが望ましい。

D.4 構成／プログラミングのための他の要求事項及び安全アプリケーションのためのランタイムシステ

ム

アプリケーションプログラミングソフトウェアには，SIS論理処理部の情報へのユーザアクセスを可能

にする多くの特徴がある。しかし，開発したソフトウェアのセキュリティを保証し，使用者がソフトウェ

アの適切な操作をチェックできることが必要である。次に，これらの特徴の幾つかを概説する。

a) プログラミングソフトウェアは，すべての使用者をその職務（例えば，経営者，工場管理者，プロジ

ェクト管理者，上級プログラマ，プログラマ，運転員）に相応した機能にだけ制限するセキュリティ

システムを提供する。各使用者は，名前及びパスワードでシステムにログインし，割り当てられた機

能レベルで作業を行うことができる。また，セキュリティシステムは，顧客会社が安全プログラムの

C 0511-2：2008 (IEC 61511-2：2003)

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

変更をサイトの数人に制限することを望む場合，安全プログラミングにユーザレベルを与え，非安全

プログラミングに別のレベルを与える。

b) 保護又はロックされた機能及びライブラリによって，プログラマは，それらにアクセスすることも変

更することもできない。これによって，正式な変更要求によって承認されない場合，認定又は完全に

試験されたライブラリは，変更できないことを保証する。セキュリティシステムによって，使用者は，

ライブラリにアクセスして変更ができる高レベルの人（通常，経営者又は工場管理者）を定義できる。

c) プログラミングソフトウェアは，開発されているプロジェクトのすべての要素のバージョン番号を提

供する。システム構成，機能，機能ブロック又はプログラムの変更は，その要素に対するバージョン

番号を変更することになる。これによって，使用者は，自己の文書が古いかどうかを直ちに知ること

ができ，変更した項目にだけ集中してテストすることができる。バージョンを比較する機能があり，

使用者は意図的でない変化を含むすべての変更内容をチェックできる。この比較機能には，グローバ

ルなタグネームデータベース及びプログラム実行リストの変更も含むことが望ましい。

d) ソフトウェアは，アプリケーションプロジェクトの複合ファイル構造に格納したすべてのデータスト

リームの周期的冗長チェックを計算し，チェックすることによって，ファイルセキュリティを提供す

る。

e) SIS論理処理部は，その診断情報へのアクセスを提供する。したがって，プログラマは，論理処理部

の状態に基づき適切な行動を取ることができる。

SIS論理処理部では，プログラマが適切な四則演算をチェックできるように算術例外を発生させるラ

ンタイム環境を提供する。

g) プログラミングソフトウェアには，プログラミングワークステーション上で開発したプログラムのす

べてをエミュレートする能力がある。これによって，プログラマは，開発したソフトウェアのすべて

をSIS論理処理部にロードする前にオフラインでチェックすることができる。この特徴は，システム

が稼働中にオンラインプログラムに対して変更を行う場合に義務付けることが望ましい。

h) ソフトウェアは，シミュレーションソフトウェアとのインタフェースとして使用可能なDDE（動的デ

ータ交換）をサポートする。これによって，アプリケーションソフトウェアを安全制御装置にロード

する前に，アプリケーションソフトウェアがオフラインテストできるようにする。

D.5 仮定

ここでは，アプリケーションソフトウェアの開発に使用するハードウェア及びソフトウェアに関連する

仮定について記述する。文書化及び手順についても記述する。

a) SIS論理処理部及びその関連入出力モジュールは，第三者が評価し，JIS C 0508規格群に適合する。

第三者が与えたJIS C 0508規格群認証の適用範囲は，SIL 3安全計装機能のコンポーネントとして使

用する。

b) 言語は，JIS B 3503の機能ブロック図 (FBD)，ラダーダイアグラム (LD) 及び構造化テキスト (ST) 言

語などの制約可変言語のサブセットである。アプリケーションライブラリにあるすべての機能及び機

能ブロックは，機能が安全に使用できるか，又は非安全だけに制限されるかを特定する属性をもつ。

安全属性で指定したアプリケーションプログラムの安全計装機能を実行するには，安全属性をもつ機

能及び機能ブロックだけが使用できる。非安全属性で指定したアプリケーションプログラムは，非安

全属性及び安全属性がある機能及び機能ブロックを使用できる。

c) サポートしているすべてのJIS B 3503プログラミング言語並びに安全属性のある各種機能のライブラ

C 0511-2：2008 (IEC 61511-2：2003)

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

附属書E

（参考）

安全で構成されたPE論理処理部のための外部構成診断の開発に関する例

序文

この附属書は，安全で構成されたPE論理処理部のための外部構成診断の開発に関する例について記載

するものであって，規定の一部ではない。

実績経験によって使用するPE論理処理部は，PE論理処理部の設計で十分な診断を明示することが望ま

しい。診断機能は，ソフトウェア又はハードウェアベースとすることが可能で，入力モジュール，基本プ

ロセッサ，出力モジュール及びコミュニケーションを含む論理処理部全体を網羅することが望ましい。

ここでは，安全構成のPE論理処理部診断で使用する基本構想を示す。

E.1

内部構成診断

工業プロセス分野のPE論理処理部は，内部構成の診断機能をもつ。これをこの附属書では，内部ウォ

ッチドッグタイマー (IWDT) と呼ぶ。IWDTは，PE論理処理部内で，製造業者が提供するソフトウェア，

ハードウェア及びコミュニケーション診断サブシステムを含む。

SIFアプリケーションのPE論理処理部は，PE論理処理部のすべての要素に診断機能を提供することが

望ましい。IWDTシステムは，入力カード又は出力カードの停止からシステム全体の停止に及ぶ使用者が

選択可能なオプションを提供することができる。IWDT診断では，論理処理部製造業者が最も重要である

と考える項目をチェックする。IWDTには，次に示す限界がある。

a) IWDTがその診断機能を実行不可能にする論理処理部と同じ原因によってIWDTが故障する潜在的共

通モード故障。

b) 実施によって，使用者に論理処理部故障状態に関連する診断情報を提供しないことがある。

c) 入出力，基本プロセッサ及びコミュニケーションを含むPE論理処理部全体をモニタできない。

d) アプリケーションソフトウェアモジュールと実行をモニタできない。

E.2

外部構成診断

a) IWDTに固有の制限事項として，安全計装機能を実行するPE論理処理部に外部のウォッチドッグタ

イマー (EWDT) を追加する必要がある。EWDTを使用しても，安全計装機能のためにIWDTの必要

性を排除しない。

b) 頻繁に使用されるEWDT装置の例は，周期パルスモニタ又は電子タイミングモニタである。最も基本

的な形式では，EWDTは，PE論理処理部アプリケーションソフトウェアのアプリケーションロジッ

クによって連続して起動される。一般に使用される概念は，必要な周期の方形波を発生させるために

幾つかの命令のグループ（キーメモリ位置に広く分離した）にプログラムすることである。この方形

波は，EWDTへの入力として使用される。図E.1は，PE論理処理部のパルス出力及びEWDTの出力

を示すタイムチャートである。

c) この方形波は，EWDT出力をオンに維持する正しいタイミングシーケンスでPE論理処理部出力をオ

ン／オフする。EWDTには，内蔵の調整可能なオンディレイ及びオフディレイタイマー機能が通常あ

ることに注意する。EWDTのオンディレイ及びオフディレイタイマー設定は，どちらの遅れもタイム

C 0511-2：2008 (IEC 61511-2：2003)

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

アウトを起こさないように設定される。EWDTがタイムアウトを起こす場合，EWDT出力は低下し，

SIFは停止及び／又は警報を発する。この方形波のパルスは，方形波発生器のアプリケーションプロ

グラムを変えることによって変化することができる。

d) EWDT診断を実行する場合に検討すべき設計上の追加的な特徴を，次に示す。

− SIFアプリケーションソフトウェアで使用するのと同じ命令セットで，EWDTのPE論理処理部の方

形波を発生させる。

− 専用のPE論理処理部が入力し，異常な操作を検出するために論理処理部入力バスの状態を監視す

る。

− トータルメモリの機能を最もよく監視するPE論理処理部の様々な記憶域にわたったEWDTプログ

ラムの分配。

− PE論理処理部のコミュニケーション診断を改良するためにPE論理処理部コミュニケーションシス

テムを通して発生した方形波の送信。

− リセットボタンの必要性。EWDTが起動時又は停止時にインターロックする場合，リセットボタン

が必要となる。リセット回路の開発時には，EWDT及びIWDTの双方を考慮する。

− テストボタンの必要性。テストボタンは，EWDTの機能を検証するのに好ましい。

− 専用のPE論理処理部が出力し，異常な操作を検出するために論理処理部出力バスの状態を監視す

る。

− 電気−機械式リレー接点から電子回路に対する誘導的相互作用を抑制するサージサプレッサ。

− 次に示すような追加的電源調整の要件の適用をレビューする。

− 不足電圧保護

− 電気雑音抑制

− 避雷

− EWDT及びIWDTの開始を決定できるような警報の発生