この規格 プレビューページの目次
※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。
序文
非推奨: 1 時間あたりの失敗確率
注記 1:古い意味の「 1 時間あたりの故障確率」は廃止され、「平均故障頻度」に置き換えられました。それにもかかわらず、機能安全規格の以前のバージョンとの一貫性を保つために、PFH は依然として使用されています。
3.1.25
危険なイベントの頻度
事故頻度
危険な事象（または事故）に関連する故障頻度（3.1.23）
3.1.26
危険なイベントの平均頻度
平均事故頻度
危険な事象（または事故）に関連する平均頻度（3.1.23）
3.1.27
平均稼働時間
勇気
稼働時間の予想
注記 1:稼働時間と停止時間の定義については、図 3 および ISO 14224 [ 15] または IEC 60050–191 [ 14] を参照。
[出典:IEC 60050 −191]
3.1.28
平均ダウンタイム
MDT
ダウンタイムの予想
注記 1:稼働時間と停止時間の定義については、図 3 および ISO 14224 [ 15] または IEC 60050–191 [ 14] を参照。
図 3 —アイテムの寿命にわたる一般的な動作の図
3.1.29
平均失敗時間
MTTF
アイテムが失敗するまでの予想時間
注記 1: MTTF は、伝統的に、修理不可能な品目の故障までの時間を表すために、または修理可能な品目の最初の故障までの時間を表すために使用されます。修理後にアイテムが新品同様であれば、その後の故障にも有効です (図 4 を参照)
注記 2:図 4 に示されているケースでは、MTTF は次の式で計算できます。
注記 3:故障率が一定の場合、次の関係が成り立ちます: MTTF = 1/ λ 。
注記 4:動作障害とスタンバイ障害が混在する図 3 のwhere 、注記 2 に記載されている式は無効になります。
注記 5: MTTF を品目の設計寿命と混同してはならない。
図 4 —寿命にわたるアイテムの動作の特定のケース
3.1.30
平均故障間隔
MTBF
修理可能なアイテムの連続故障間の予想時間
注記 1:図 4 に示されているケースでは、MTBF は、MTBF = MTTF+MTTRes の関係によって MTTF および MTTRes とリンクされています。より一般的には、MTBF = MUT+MDT によって MUT および MDT にもリンクされます。
図 5 — IEV 191 [ 14] 、IEC 61508 [ 2] 、および ISO/TR 12489 に基づく修理時間の分類
3.1.31
修理にかかる平均時間
MTTR
故障したアイテムの修復が完了するまでの予想時間
- 1)品目の故障が実際に発生してからその検出までに経過した時間 (3.1.35, MFDT を参照)
- 2)品目の故障の検出からその機能が回復するまでの経過時間 (3.1.33, MRT を参照)
注記 2: MTTR の頭字語は、IEC 60500–191 [ 14] または IEC 61508 [ 2] で平均復元時間として定義されています。これは ISO 14224 [ 15] や ISO 20815 [ 16] とは異なります。したがって、混同を避けるために、この技術レポートでは MTTR の代わりに MTTRes という頭字語が使用されます (3.1.32 を参照)
3.1.32
復元までの平均時間
MTTR
- •障害を検出するまでの時間 そして、
- •修復を開始するまでに費やした時間 そして、
- ・修復にかかる有効時間ｃ。そして、
- •コンポーネントが再び動作可能になるまでの時間 d
注記 1:図 5 は、IEC 61508 [ 2] 規格で定義されている時間 a, b, c および d が、IEC 60050-191 [ 14] 規格で定義されている遅延にどのように関連付けられているかを示しています。時間 b は a の終わりから始まります。時間 c は b の終わりから始まります。時間 d は c の終わりから始まります。
注記 2:図 5, 図 6, および図 7 は、この技術レポートで使用される MTTRes, MRT, および MART の定義の違いを理解するために使用できます。
図 6 —修復時間と、すぐに判明した品目の故障によるリスクの説明
3.1.33
MRI
全体の平均修理時間
- •修復を開始するまでに費やした時間 そして、
- ・修復にかかる有効時間ｃ。そして、
- •コンポーネントが再び動作可能になるまでの時間 d
注記 1:図 5, 図 6, および図 7 を参照。
注記 2:この技術報告書で使用される「修理」、「修理可能」、「修理済み」という用語は、特に指定がない限り、全体の修理時間に関連しています (図 5 を参照)
注記 3:デマンドモードで動作する安全システムに障害がある場合、保護された設備が安全な状態 (例えば、停止) になるとすぐに、リスクは解消されます。この場合 (図 6 および図 7 を参照)、確率計算に関して MTTS が MRT (3.1.36 を参照) に置き換わります。
注記 4:この定義は IEC 61508 [ 2] に準拠していますが、IEC 60050–191 には準拠していません。 [ 14]
3.1.34
平均アクティブ修復時間
マート
予想されるアクティブな修復時間
注記 1: MART は、c を修復するのに予想される有効時間です (図 5, 図 6, および図 7 を参照)
3.1.35
平均故障検出時間
MFDT
障害を検出するのに必要な予想時間
注記 1: MFDT は、図 5, 図 6, および図 7 の時間 a) です。
注記 2:即座に明らかになった障害の場合、MFDT はゼロに等しくなります。 (図 6 を参照) すぐに検出される障害については、通常は無視できます。 (図 6 を参照) 隠れた障害のテスト ポリシーに応じて異なります。この場合、それがアイテムのダウンタイムの主要部分である可能性があります (図 7 を参照)
図 7 —修復時間と、アイテムの隠れた故障によるリスクの説明
3.1.36
MTTS
安全な状態になるまでの平均時間
安全システムの危険な故障が検出された後、保護された設備が安全な状態に達するまでに必要な予想時間
例：
デマンドモードで動作している安全システムに危険な障害が明らかになった場合、障害の修復を行うのではなく安全な状態に到達することが決定される場合があり、これには時間がかかる場合があります。たとえば、MTTS が 8 時間とは、次のことを意味します。 、プロセスをシャットダウンするには平均して 8 時間かかります。シャットダウン後は安全な状態に達し、障害は危険ではなくなり、修復を完了するために費やされる残り時間を考慮する必要はありません。これを図 6, 図 7, 図 B.1 に示します。
注記 1: MTTS が保守手順として定義される場合、危険な事象の確率的計算のためにそれを考慮する必要がある。この場合、MTTS は確率計算に関して MRT (3.1.33 を参照) を置き換えます。相互に、確率計算を有効に保つために、実際の修復アクション中にこの MTTS が尊重されることを検証する必要があります。
注記 2: MTTS の役割は MPRT の役割に近い。違いは、MPRT が安全な状態に到達するために許可される最大継続時間であるのに対し、MTTS は危険な障害が明らかになったときに安全な状態に到達するために必要な TTS のランダムな継続時間の平均であることです (図 6 と図 7 を参照)この技術レポートで開発された手法は、決定論的な値 (MPRT) ではなく、平均ランダム値 (MTTRes, MRT, MTTS) に焦点を当てていますが、MPRT はペトリ ネットとモンテカルロ シミュレーションを使用することで簡単に処理できます。
3.1.37
最大許容修理時間
MPRT
リスクを解消するための措置を講じるまでに、障害を修復するために許容される最大時間
例：
デマンドモードで動作する安全システムに危険な障害が明らかになった場合、最大持続時間が経過したときに安全状態に達すると判断される場合があります。MPRT が 8 時間とは、たとえば、修理が 8 時間経過しても完了しない場合を意味します。 h, プロセスはシャットダウンされます。その後、安全な状態に達し、障害はもはや危険ではなくなり、修復を完了するために費やされる残りの時間を考慮する必要はありません。これを図 6, 図 7, 図 B.1 に示します。障害が複数の障害モードに起因する可能性がある場合、MPRT を使用すると、プロセスをシャットダウンすることなく、短い MRT 内でそれらを修復できます。
注記 1: MPRT が保守手順として定義される場合、危険な事象の確率的計算において MPRT を考慮する必要がある。逆に、確率計算を有効に保つために、実際の修復アクション中にこの MPRT が尊重されることが必要です。
注 2: MPRT の役割は MTTS の役割に似ています (0 を参照)違いは、MPRT は安全な状態に到達するために許可される最大継続時間であり、MTTS は危険な障害が明らかになったときに安全な状態に到達するために必要な平均継続時間であることです (図 6 と図 7 を参照)この技術レポートで開発された手法は、決定論的な値 (MPRT) ではなくランダム修復値 (MTTRes, MRT, MTTS) に焦点を当てていますが、MPRT はペトリ ネットとモンテカルロ シミュレーションを使用することで簡単に処理できます。
3.1.38
要求するまでの平均時間
MTTD
安全システムへの要求が発生するまでの予想時間
3.1.39
復元率
μ
失敗した項目の復元が、やり直していない場合にt とt +d t の間に終了する単位時間当たりの条件付き確率
注記 1:復元率が一定の場合、次の関係が成り立ちます: MTTRes = 1/ μ 。
注記 2: 「復元」速度は復元時間と関係があります。同様に、「修復」率は「全体の修復」時間との関係で定義でき、「アクティブ修復」率は「アクティブ修復」時間との関係で定義できます。
注記 3: 復元率には、障害の故障率と同じ数学的性質があります。
3.2 故障の分類
安全システムのさまざまな状態とさまざまな故障についての説明は、付録 B に記載されています。
3.2.1
失敗
要求どおりに実行する能力の喪失
注記 1:項目の故障はイベントであり、状態である項目の故障とは異なります (図 8 を参照)
[出典:IEC 60050 −191]
3.2.2
故障
要求されたとおりに実行できない
注記 1:項目の障害は状態であり、イベントである項目の障害とは異なります (図 8 を参照)
注記 2:品目の欠陥は、品目の故障、または仕様、設計、製造、保守などのライフサイクルの初期段階における欠陥に起因する可能性があります。
注記 3:限定用語は、仕様、設計、製造、保守、誤用などの障害の原因を示すために使用される場合があります。
注記 4:予防保守、その他の計画されたアクション、または外部リソースの不足により実行できないことは、障害にはなりません。
- 障害 x はステージ 1 で発生し、検出されない状態の障害 xにつながります。
- ステージ 2 の観点から、障害 xは既存の障害です。
- 障害 y はステージ 2 で発生し、検出されない状態の障害 x, yにつながります。
- ステージ 3 の観点からは、障害 x, y は既存の障害です。
- 等々。
図 8 —障害と障害の概念の関係
3.2.3
危険な失敗
安全でない失敗
所定の安全動作を妨げる傾向がある安全システムの故障
注記 1:これは、安全システムによって実行される特定の安全措置に関連したシステム的な障害であるため、この概念は棚上の個々の品目とは無関係です。
注記 2:図 B.1 を参照。
3.2.4
重大な危険な失敗
安全動作の完全な阻害につながる危険な故障 (つまり、保護されたシステムにとって危険な状況につながる)
注記 1:これは、安全システムによって実行される特定の安全措置に関連したシステム的な障害であるため、この概念は棚上の個々の品目とは無関係です。
注記 2:内部冗長性を備えた安全システムに属するコンポーネントの同じ障害は、それが発生したシステムの状態に応じて、危険または非常に危険な場合があります。
注記 3:検出されない重大な危険な故障 (例えば、定期テストによって明らかになった故障) は、安全性重大な故障と呼ばれることがあります (ISO 14224 [ 15] を参照)このような潜在的な故障の影響を受ける機器はプラント内で特定して監視することができ、定期テストで検出された安全上重要な故障の数と、それに対応して実行されたテストの数との比率（一般に「故障率」と呼ばれます）が使用されています。目的。危険な未検出の障害による平均的な非可用性 (PFDavg) の指標は、テスト レポートを使用して確立されます。このような故障率を他の信頼性の用語と混同しないことが重要です。
3.2.5
安全な失敗
特定の安全措置が優先される傾向にある安全システムの故障
注記 1:安全な障害の概念は、図 B.1 に示されています。
注記 2:障害は、特定の安全機能に関してのみ安全です。これは、安全システムによって実行される特定の安全措置に関連したシステム的な障害です。この概念は、棚上の個々の商品には無関係です。
注記 3:非クリティカルな安全故障は、基本的に安全機能の成功の確率を高めます。重要な安全障害は、必要でない場合に関連する安全アクションを開始します (擬似障害を参照)
3.2.6
擬似障害
タイミングを逸してアクションを引き起こす失敗
注記 1: 重大な安全障害 (図 B.1 を参照) は、安全システムに関連する典型的な擬似障害です。
注記 2:擬似障害は、必ずしも擬似トリップ (3.4.14) を意味するわけではありませんが、擬似トリップは常に擬似障害の結果です。
3.2.7
重大な安全上の失敗
安全システムの誤った故障。そのコンポーネントの安全な故障により、安全動作がトリガーされ、誤った安全動作が引き起こされる。
注記 1:クリティカルセーフ故障の概念を図 B.1 に示す。
注記 2:これは、安全システムによって実行される特定の安全措置に関連したシステム的な障害です。この概念は、棚上の個々の品目とは無関係です。
注記 3:安全システムに属するコンポーネントの同じ故障は、それが発生したシステム状態に応じて、安全である場合もあれば、偽の故障 (クリティカルセーフ) である場合もあります (たとえば、2oo3 に属するセンサーの安全な故障は、次の場合にのみ安全です) 1 番目の位置で発生する場合は重要です)
3.2.8
システム障害
全体的な失敗
システムの個々のコンポーネントの障害から単純に説明できない、システム レベルでの障害
注記 1:体系的/総合的原則は、アリストテレスによって「全体は部分の合計以上のものである」という言葉で簡潔に要約されています。
注記 2: コンポーネントには故障モードのみがあります。これらの故障モードは、コンポーネントが安全「システム」に実装されている場合にのみ、危険、安全、または擬似的なものになります。これが、危険な障害、安全な障害、または偽の障害が典型的なシステム障害である理由です。たとえば、バルブの「閉じ忘れ」の故障は、そのバルブが要求に応じて閉じる安全システムに属している場合にのみ危険です。それ以外の場合、この故障モードは問題になりません。
注記 3: 「体系的」障害 (すなわち、特定の条件が発生したときに決定論的に発生する、3.2.17 を参照) と「体系的」障害を混同してはならない。
3.2.9
胆力不全
突然の完全な失敗
注記 1:この用語は、突然停止するカタレクティック詩 (つまり、8 フィートではなく 7 フィートの詩) からの類推によって導入されました。その後、前触れもなく白内障が発生し、検査によって予測することは多かれ少なかれ不可能です。これは、段階的かつ不完全に発生する障害の逆です。
注記 2:カタレクティック故障は、一定の故障率 (指数法則) を持つ単純なコンポーネントの特徴です。コンポーネントは、突然、完全に、警告なしに故障するまで、永続的に「新品同様」のままです。信頼性エンジニアリングで使用される確率モデルのほとんどは、研究対象のシステムの個々のコンポーネントの触覚障害に基づいています (マルコフ手法など)
3.2.10
すぐに明らかになった失敗
明らかな失敗
検出された障害
明らかな失敗
発生するとすぐに運用担当者や保守担当者に明らかな障害
注記 1:すぐに明らかになった障害はすぐに現れますが、特定の診断テストによってすぐに検出される隠れた障害は、通常、すぐに明らかになった障害と見なされます。
注記 2:直ちに明らかになった障害の修復は、障害が発生した直後に開始される場合があります。
注記 3:定期テストによって検出された障害は、直ちに判明した障害とはみなされません。
3.2.11
隠れた失敗
失敗をカバーする
休止中の障害
明らかになっていない失敗
検出されない障害
運用担当者や保守担当者にはすぐには分からない障害
注記 1:隠れた障害は、発生しても現れません。隠れた故障が発生すると、特定のテスト (定期テストなど) または必要なときにその機能を実行できないアイテムによって明らかになる潜在的な故障が発生します。
注記 2:隠れた障害の修復は、それらが検出されない限り開始できません。障害が発生してから検出されるまでに費やされた未知の時間は、MTTRes に属します。
3.2.12
時間依存の故障
時間に応じて確率で発生する障害
注記 1:信頼性の低さF ( t ) は、時間依存の故障を記述する典型的な確率関数です。
3.2.13
需要による失敗
オンデマンドで発生する障害
γ、ψ
外部イベント (いわゆる「要求」) によって引き起こされる状態の変化による 1 つのアイテムの失敗
例 1:
サイコロを起動するときに 2 を取得することは、オンデマンドで発生するイベントです。この出来事が起こる確率は1/6です。それは経過時間には依存せず、要求自体 (つまり、サイコロが起動されるという事実) のみに依存します。
例 2:
状態が変化したときの電気機械式リレーの故障 (例: スプリングの破断) は、動作時間ではなく動作回数 (サイクル) に依存します (IEC 61810–2 [ 49] を参照)これは、リレーの故障についても同様です。電子機器のスイッチング時の過電圧やディーゼルエンジンの始動時のブロックなど、これらは需要（またはサイクル）による故障の典型的な例です。
注記 1:この技術報告書では、定期テストと実際の安全措置の要求という 2 種類の要求が考慮されています。定期テストによる故障の確率はγで示される定数であり、安全措置の 1 つの実際の要求による故障の確率はψで示される定数です。特定の時間間隔における障害の確率は、期間には依存せず、この間隔内で発生する要求またはテストの数に依存します。 γとψの使用については 7.3 で説明します。
注記 2:これを、低需要向けの機能安全規格[ 2] で使用される「オンデマンド障害の確率」(3.1.14 の注記 2 を参照) という用語に現れる「オンデマンド障害」と混同しないでください。ファッションセーフティシステム。これらの規格では、これは「要求が発生したときに観察される可能性が高い障害」を意味します。
3.2.14
よくある原因の失敗
CCF
ここで, 単一のイベントに起因するさまざまな項目の障害、これらの障害は相互に影響するものではありません
注記 1:障害は同時に発生するか、または短時間のうちに発生すると一般に認められています。
注記 2:共通原因障害は、共通モード障害につながる可能性があります。
注記 3:一般的な原因による障害は、システムの冗長性の効果を減少させます。
注記 4:明示的および暗黙的な CCF は 5.4.2 で定義されています。
3.2.15
コモンモード障害
CMF
異なるアイテムの障害が同じように発生する
注記 1: コモンモード障害にはさまざまな原因がある可能性があります。
注記 2:コモンモード障害は、一般的な原因による障害が原因である可能性があります。
3.2.16
ランダムな失敗
ランダムに発生する失敗
注記 1:偶発的な障害は、時間または需要に依存する可能性があります。発生するかどうかは確実に予測できませんが、対応する故障率 (3.1.18 を参照) または需要による故障の確率 (3.2.13 を参照) は予測可能な場合があり、これにより確率的計算が可能になります。
例：
予測不可能な障害の発生につながる障害メカニズムの例は次のとおりです。劣化メカニズムに起因するハードウェアのランダムな障害。日常業務のミス、注意力の欠如、ストレス、疲労などによって生じる人為的な偶発的な故障。
注記 2: 確率論的な観点から見ると、ランダム障害は、いくつかの条件が満たされたときに決定論的に (つまり、確率が 1 に等しい) 発生する系統的障害 (3.2.17 を参照) の逆です。
3.2.17
系統的な障害
特定の取り扱い、保管、または使用条件下で一貫して発生する故障
注記 1:システム障害の原因は、仕様、設計、製造、設置、運用、または保守に起因します。その発生は、取り扱い、保管、使用、またはメンテナンスの特定の条件によって促進されます (図 G.3 を参照)
注記 2:修正を行わない事後保守では、通常、障害の原因は除去されません。
注記 3:系統的障害は、障害原因の検証などで同じ条件を意図的に適用することによって再現できます (IEC 60050–191 ed3 [ 14] より)系統的障害は、ランダムではない障害です (3.2.16 を参照)
注記 4:動作中、系統的障害は系統的障害 (すなわち、システムの既存の状態) の現れです。
注記 5: 「バグ」と呼ばれるソフトウェアの系統的障害は、系統的障害の例です。これらは、既存のバグ (つまり、障害) が原因であり、入力データによってそれらがアクティブになるときに発生します。
注記 6:システム的障害とシステム的 (「システムレベルで」を意味する) 障害 (3.2.8 を参照) を混同してはならない。
[出典:IEC 60050‑191]
3.3 安全システムの類型
3.3.1
運転安全システムのデマンドモード
周囲環境から特定の要求を受けた場合にのみ安全動作が達成されるように設計された安全システム
注記 1:このようなシステムは、ほとんどの時間をスタンバイ状態に費やしますが、要求が発生するとすぐに動作できるようにする必要があります。
注記 2: このようなシステムには、隠れた障害が発生する可能性があります。一般に、対応する潜在的な障害を明らかにするために、診断テストと定期テストが実装されます。
注記 3:デマンド周波数が増加すると、オンデマンドモード安全システムは、動作システムの連続モードに同化される可能性があります。
3.3.2
連続モード動作安全システム
安全動作を永続的に達成するように設計された安全システム
注記 1:連続モード安全システムでは、安全システムが故障するとすぐに危険なイベントが発生します。これは図 B.1 に示されておりwhere システム状態「 ko 」と「危険なイベント」が 1 つの状態にまとめられています。
3.3.3
複数の安全システム
前のシステムが故障したときに次々と作動する複数のサブ安全システムで構成される安全システム
注記 1:産業プロセスでは、多くの場合、複数の安全システム (安全層) が実装されます。この場合、中間の安全層の障害により、隣接する成功した安全層に対する要求が引き起こされ、以下同様に続きます。事故は、要求が最終的な安全層まで伝達され、それが動作しなかった場合にのみ発生します。
3.4 メンテナンスの問題
3.4.1
メンテナンス
物品を必要な機能を実行できる状態に保持または復元することを目的とした、監督上の措置を含む、すべての技術的および管理的措置の組み合わせ。
注記 1: 保守には2 つの基本的なカテゴリーがあります。1 つは障害が発生した後に行われる事後保守、もう 1 つは障害が発生する前に行われる予防保守 (テスト、検査、状態監視、定期) です。 ISO 14224 [ 15] 、9.6 も参照してください。
注記 2:予防保守または事後保守カテゴリー・タイプの保守活動は、ISO 14224:2006 [ 15] の表 B.5 に示されています。
[出典:ISO 14224]
3.4.2
メンテナンスの概念
保守階層、契約レベル、保守レベル、保守サポート、およびそれらの相互関係の定義
注記 1:保守概念は、保守計画、サポート可能性要件の決定、および後方支援の開発の基礎を提供します。
注記 2: 保守階層とは、 where されたレベルの保守が実行される組織内の役職です (例: 現場、修理工場、製造施設)
[出典:IEC 60050‑191]
3.4.3
予防メンテナンス
午後
所定の間隔で、または所定の基準に従って実行され、アイテムの故障や機能低下の可能性を減らすことを目的としたメンテナンス
[出典:ISO 14224]
3.4.4
事後保全
故障検出後に復旧のためのメンテナンスを実施
注記 1: ソフトウェアの修正保守には、必ず何らかの変更が伴います。
注記 2:事後保全は、治癒保全と呼ばれることもあります。
[出典:IEC 60050‑191-46-06]
3.4.5
検出方法
障害を発見する方法またはアクティビティ
注記 1:検出方法の分類 (例: 定期テストまたは継続的状態モニタリング) は、ISO 14224:2006 [ 15] の表 B.4 に示されています。
3.4.6
メンテナンス計画
メンテナンスを実行するために必要なアクティビティ、手順、リソース、および時間スケールを含む、構造化され文書化された一連のタスク
注記 1:保守計画は、関連する確率的な結果を生み出すために徹底的に分析およびモデル化される必要があります。
注記 2:設計段階で確立された確率的予測結果は、検討された保守計画が運用中に完全に適用されない場合には無効になります。
注記 3:保守計画は、予防保守 (例: テスト) と事後保守 (例: ダウンタイムの最小化、失われた冗長性の復元) の両方のポリシーをカバーする必要があります。
注記 4:保守計画は、全体的な運用および保守計画の一部です。 「保守ポリシー」と呼ばれることもあります。
[出典:EN 13306]
3.4.7
テストポリシー
特定の安全システムの安全要件を達成するためにスケジュールされたさまざまなテスト操作 (周波数と手順) を説明する一連の手順
注記 1:関連する確率的な結果を生成するには、テストポリシーを徹底的に分析およびモデル化する必要があります。
注記 2:設計段階で確立された確率的予測結果は、検討されたテスト方針が運用中に完全に適用されない場合には無効になります。
3.4.8
定期テスト
実証試験
その間に発生する可能性のある潜在的な隠れた障害を検出するために、一定の時間間隔で実行される計画された操作
注記 1:診断テストでは検出されない安全システムの危険な隠れた故障は、定期的なテストによって検出される可能性があります。このようなテストは、機能安全を扱う規格 (IEC 61508 [ 2] など) では「プルーフテスト」と呼ばれています。
[出典:IEC 61508]
3.4.9
診断テスト
潜在的な隠れた障害を発生時にできるだけ早く検出するために、高頻度で実行される自動操作
注記 1:安全システムの危険な故障は一般に隠蔽されており、それらの大部分を検出するために診断テストが実装される場合があります。診断サイクルは通常短いため、診断テストによって検出された隠れた障害は、すぐに明らかになった障害と同化されます。
[出典:IEC 61508]
3.4.10
時間差テスト（冗長項目の）
複数の項目を同じテスト間隔で同時にではなくテストする
例：
図 9 は、2 つの項目 A と B の時間差テストを示しています。
図 9 — 2 つの冗長アイテム A と B で構成されるシステムのテストのスタガリングの例
3.4.11
冗長性
必要な機能を実行するための複数の手段の存在
注記 1:冗長性の目的は、必要な機能を実行する手段に 1 つまたは複数の障害が発生した場合にバックアップを提供することです。
注記 2:パッシブ (コールド) スタンバイ、アクティブ (ホット) スタンバイ、および混合の冗長性の定義は、ISO 14224 [ 15] 、C.1.2 に記載されています。
注記 3:冗長性は、(IEC 61508 [ 2] および IEC 61511 [ 3] では) 「フォールトトレランス」と呼ばれることもあります。
[出典:ISO 14224]
3.4.12
（安全機能の）スプリアス作動
必要のない安全機能の時機を逸した要求
注記 1:安全機能の誤った作動は、1 つまたは複数の安全故障の発生が原因である可能性があります。
3.4.13
（安全システムの）偽の動作
安全機能が誤って作動した結果
注記 1:擬似安全動作は必ずしも安全である必要はありません。偽のアクションの例としては、偽のトリップがあります。
3.4.14
旅行
通常の動作状態から完全停止までの機械の停止
- a)トリップ: シャットダウンは制御/監視システムによって自動的に作動します。
- •実際のトリップ: 制御システムの監視 (または計算) 値が事前に設定された制限値を超えた結果としてシャットダウンが作動します。
- •スプリアストリップ: 制御/監視システムの故障、または環境や人に起因する制御/監視システムのエラーに起因する予期せぬシャットダウン。
- b)手動停止: 機械はオペレータの意図した動作によって停止されます (ローカルまたは制御室から)
注記 2: 「装置トリップ」または「擬似トリップ」などの記述は、特に信頼性データまたはモデリングにおいて故障モードとして扱われる場合、(回転) 装置シャットダウンを引き起こす故障に対して使用される誤解を招く用語となる場合があります。故障メカニズム (ISO 14224 [ 15] の表 B.2 を参照) にはさまざまなタイプ (機械、計器など) があり、故障モード (そのうちの 1 つはスプリアストリップ) という用語と混同すべきではありません。故障モードは必ずしも機器関連の故障ではなく、機械的な故障である可能性があります。たとえば、回転機器に関する ISO 14224 [ 15] の表 B.6 の故障モードを参照してください。
[出典:ISO 14224]
3.4.15
信頼性データ
信頼性、保守性、保守サポート実績に関するデータ
注記 1:信頼性および保守性 (RM) データは、ISO 14224 [ 15] によって適用される用語です。
[出典:ISO 20815]
3.4.16
一般的な信頼性データ
同様の機器のファミリーを網羅した信頼性データ
注記 1:石油、石油化学、および天然ガス産業内のこれらの機器ファミリーを定義する機器境界および機器分類の詳細については、ISO 14224 [ 15] を参照。
注記 2:特定の機器に関するプラント固有のデータは、一般的な信頼性データベースの一部である可能性がありますが、一般的なデータとは大きく異なる可能性があるため、これらのデータと混合すべきではありません。
[出典:ISO 14224]
3.5 その他の用語
3.5.1
臨界状態
状態遷移モデルにおいて、特定の状態クラスに属し、失敗クラスの状態から 1 つの遷移だけ離れている状態。
注記 1:これは、マルコフ過程やペトリネットモデルなどに関連した数学的概念です。
例：
安全システムの状態は 2 つのクラスに分類できます。安全動作が利用可能な場合はクラス OK, 安全動作が禁止されている場合はクラス KO です。この場合、安全システムの故障に関する重大な状態はクラスOKに属し、クラスko への移行には 1 つの故障 (つまりイベント時) だけが必要です。
3.5.2
機能不全
アイテムの損傷または異常な機能
注記 1:この用語は、ギリシャ語の接頭語「dys」（すなわち、「困難を伴う」）とラテン語の「functio」（すなわち、与えられた目的を持った活動）から作られています。この用語は主に医療分野で使用されますが、現在では技術分野で「失敗」や「障害」よりも一般的な用語としてよく使用されています。
3.5.3
機能不全の分析
アイテムの機能不全を分析することを目的とした一連の活動
注記 1:これは、機能不全分析が、例えば、問題の発生確率を特定、分類、特徴づけ、評価することによって品目がどのように故障するかを分析することを目的としているのに対し、品目がどのように機能するかを分析することを目的とする機能分析に相当するものです。機能不全。
注記 2: 「機能不全」分析という用語は、「機能不全」分析の同義語としてよく使用されます。
3.5.4
形式的な言語
健全な数学的特性を備えた一連の単語、意味論、および論理規則
注記 1:プログラミング言語は、コンピュータ実行可能コードにコンパイルできる数学的特性を備えた形式言語の一例です。
注記 2: すべての信頼性モデルには、グラフィック要素の背後に基礎となる形式言語があります (たとえば、ブール モデルのバイナリ ロジック)
注記 3:産業システムの機能と機能不全をモデル化するために、特定の形式言語が開発されています (例: AltaRica [ 11] [12] )モデリングの強力さと数学的特性に応じて、イベント ツリー、フォールト ツリー、マルコフ グラフ、ペトリ ネット、事故シーケンスなどにコンパイルできます。それらの一部は、モンテカルロ シミュレーションに直接使用することもできます。
3.5.5
機能分析
アイテムが必要に応じてどのように機能するかを分析することを目的とした一連のアクティビティ
注記 1:これは、機能分析が、例えば品目に関連するさまざまな機能を特定し、分類し、特徴付けることによって品目がどのように機能するかを分析することを目的とするとき、これは、品目がどのように機能するかを分析することを目的とする機能不全分析に相当するものである。
注記 2: 「機能的」分析という用語は、「機能的」分析の同義語としてよく使用されます。ただし、「機能分析」という用語は複数の意味があるため、混乱を避けるためにこの技術レポートでは使用しません。
3.6 機器関連の用語
3.6.1
高信頼性保護システム
ヒップ
設計パラメータの超過から機器を保護するために十分に高い安全完全性 (3.2.1 を参照) を備えた非従来型の自律型安全計装システム
注記 1:機械的保護システムを記述する業界標準 (ISO 23251 [ 31] = API STD 521 [ 32] 、ISO 10418 [ 33] 、API RP 14C [ 58] など) からの逸脱は、HIPS として扱われます。安全計装システム (SIS) のみに依存する究極の保護は、必要な安全度水準 (SIL) に関係なく、HIPS として認定されます。
3.6.2
高信頼性圧力保護システム
ヒップス
HIPS は過圧からの保護のみを目的としています
注記 1:別の用語: 過圧保護システム (OPPS)
- •下流機器の最大圧力定格、または
- •適切なサイズの機械的圧力逃がし装置、または
- •同時に救済できるように廃棄システムを設計する。
3.6.3
HIPPSバルブ
HIPPS システムの最終要素として使用されるバルブ
3.6.4
海中隔離弁
SSIV
SIV
パイプライン/ライザーの漏れや破裂の影響を軽減するために、リスク評価に基づいて定められた制限時間内に閉じるバルブ
注記 1: SSIV は、作動バルブ (遠隔制御の海中バルブなど) または非作動バルブ (海中逆止弁) のいずれかにすることができます。作動したバルブは通常、フェイルセーフとして設計されています (つまり、バルブとアクチュエータ自体の外部に障害が発生した場合はすべて閉じ、閉じたままになります)
注記 2:フレキシブルライザーが海底坑口に直接接続されている場合、マスターバルブとウィングバルブが SSIV 機能を表すとみなされる場合があります。
[出典:ISO 14723]
3.6.5
地下安全弁
SSSV
作動時に制御されていない坑井の流れを防止する設計機能を備えた坑井頭の下の坑井に設置される装置
注記 1:これらの装置は、ワイヤーライン (ワイヤーライン回収可能) および/またはポンプダウン方式 (TFL-スルーフローライン) によって取り付けおよび回収することができ、またはチューブストリングの一体部分 (チューブ回収可能) とすることもできます。
3.6.6
表面制御式地下安全弁
SCSSV
SSSV は油圧、電気、機械、またはその他の手段によって地表から制御されます
注記 1: SCSSV は、DHSV (ダウンホール安全弁) と呼ばれることもあります。
[出典:ISO 14723]
3.6.7
地下制御式地下安全弁
SSCSV
井戸自体の特性によって作動するSSSV
注記 1: これらの装置は通常、SSCSV を介した差圧 (速度タイプ) または SSCSV の配管圧力 (高圧または低圧タイプ) によって作動します。
[出典:ISO 14723]
3.6.8
SSSVシステム設備
表面制御システム、制御ライン、SSSV, 安全弁ロック、安全弁着地ニップル、フローカップリング、その他のダウンホール制御コンポーネントを含むコンポーネント
[出典:ISO 10417]
Foreword
DEPRECATED:probability of failure per hour
Note 1 to entry: The old meaning “Probability of Failure per Hour” is obsolete and replaced by “average failure frequency”. Nevertheless PFH is still in use to keep the consistency with the previous versions of functional safety standards.
3.1.25
hazardous event frequency
accident frequency
failure frequency as 3.1.23 related to the hazardous event (or to the accident)
3.1.26
average hazardous event frequency
average accident frequency
average frequency as 3.1.23 related to of the hazardous event (or to the accident)
3.1.27
mean up time
MUT
expectation of the up time
Note 1 to entry: See Figure 3 and also ISO 14224[15] or IEC 60050–191[14] for definitions of up time and down time.
[SOURCE:IEC 60050 −191]
3.1.28
mean down time
MDT
expectation of the down time
Note 1 to entry: See Figure 3 and also ISO 14224[15] or IEC 60050–191[14] for definitions of up time and down time.
Figure 3 — Illustration of the general behaviour of an item over its lifetime
3.1.29
mean time to failure
MTTF
expected time before the item fails
Note 1 to entry: The MTTF is classically used to describe the time to failure for a non-repairable item or to the first failure for a repairable item. When the item is as good as new after a repair, it is also valid for the further failures (see Figure 4).
Note 2 to entry: In the cases illustrated by Figure 4, the MTTF may be calculated by the following formulae:
Note 3 to entry: The following relationship holds when the failure rate is constant: MTTF = 1/λ.
Note 4 to entry: In the case illustrated by Figure 3 where operating and stand-by failures are mixed, the formulae described in Note 2 to entry are no longer valid.
Note 5 to entry: The MTTF should not be mixed up with the design life time of the item.
Figure 4 — Particular cases of the behaviour of an item over its lifetime
3.1.30
mean time between failures
MTBF
expected time between successive failures of a repairable item
Note 1 to entry: In the cases illustrated in Figure 4, the MTBF is linked with MTTF and MTTRes by the following relationship: MTBF = MTTF+MTTRes. More generally It is also linked to the MUT and MDT by MTBF = MUT+MDT.
Figure 5 — Repair time taxonomies as per IEV 191[14] , IEC 61508[2] and ISO/TR 12489
3.1.31
mean time to repair
MTTR
expected time to achieve the repair of a failed item
- 1) the time elapsing from the actual occurrence of the failure of an item to its detection (cf. 3.1.35, MFDT);
- 2) the time elapsing from the detection of the failure of an item to the restoration of its function (cf. 3.1.33, MRT).
Note 2 to entry: The acronym MTTR is defined as the mean time to restore in the IEC 60500–191[14] or in the IEC 61508[2] . This is not the same as in ISO 14224[15] or ISO 20815[16] . Therefore, in order to avoid any mixed-up, the acronym MTTRes is used in this Technical Report instead of MTTR (cf. 3.1.32).
3.1.32
mean time to restoration
MTTRes
- • the time to detect the failure a; and,
- • the time spent before starting the repair b; and,
- • the effective time to repair c; and,
- • the time before the component is made available to be put back into operation d
Note 1 to entry: Figure 5 illustrates how the times a, b, c and d defined in the IEC 61508[2] standard are linked to the delays defined in the IEC 60050–191[14] standard. Time b starts at the end of a; time c starts at the end of b; time d starts at the end of c.
Note 2 to entry: Figure 5, Figure 6 and Figure 7 can be used to understand the differences between the definitions of MTTRes, MRT and MART used in this Technical Report.
Figure 6 — Illustration of the restoration time and of the risk exposure for immediately revealed failures of an item
3.1.33
MRT
mean overall repairing time
- • the time spent before starting the repair b; and,
- • the effective time to repair c; and,
- • the time before the component is made available to be is put back into operation d
Note 1 to entry: See Figure 5, Figure 6 and Figure 7.
Note 2 to entry: The terms “repair”, “repairable”, “repaired” used in this Technical Report, unless otherwise specified, are related to the overall repairing time (see Figure 5).
Note 3 to entry: When a safety system operating in demand mode is faulty, the risk disappears as soon as the protected installation is placed in a safe state (e.g. stopped). In this case (see Figure 6 and Figure 7) the MTTS replaces the MRT (see 3.1.36) with regard to the probabilistic calculations.
Note 4 to entry: This definition is in line with IEC 61508[2] but not with IEC 60050–191.[14]
3.1.34
mean active repair time
MART
expected active repair time
Note 1 to entry: The MART is the expected effective time to repair c, (see Figure 5, Figure 6 and Figure 7).
3.1.35
mean fault detection time
MFDT
expected time needed to detect a fault
Note 1 to entry: The MFDT is the time a) in Figure 5, Figure 6 and Figure 7.
Note 2 to entry: The MFDT is equal to zero for immediately revealed failure; (see Figure 6) generally negligible for quickly detected failures; (see Figure 6) depending of the test policy for the hidden failures. In this case it may be the main part of the item down time (see Figure 7).
Figure 7 — Illustration of the restoration time and of the risk exposure for the hidden failures of an item
3.1.36
MTTS
mean time to safe state
expected time needed for the protected installation to reach a safe state after a dangerous failure of a safety system has been detected
EXAMPLE:
When a dangerous fault is revealed for a safety system operating in demand mode, it may be decided to reach a safe state rather to undertake the repair of the fault and this may take some time: a MTTS of 8 h means, for example, that, on average, 8 h are needed to shut down the process. After the shut down, a safe state is reached, the fault is no longer dangerous and it is not necessary to take into account the remaining time spent to complete the repair. This is illustrated in Figure 6, Figure 7 and Figure B.1.
Note 1 to entry: When the MTTS is defined as a maintenance procedure it is necessary to take it into consideration for the probabilistic calculations of hazardous events. In this case the MTTS replaces the MRT (see 3.1.33) with regard to the probabilistic calculations. Reciprocally it is necessary to verify that this MTTS is respected during the actual repair actions in order to keep the probabilistic calculations valid.
Note 2 to entry: The role of the MTTS is close to the role of the MPRT. The difference is that the MPRT is a maximum duration allowed to reach a safe state when the MTTS is the average of the random duration of the TTS needed to reach the safe state when a dangerous fault is revealed (see Figure 6 and Figure 7). The methods developed in this Technical Report have been focused on average random values (MTTRes, MRT, MTTS) rather than on deterministic values (MPRT), but the MPRT can be easily handled by using Petri nets and Monte Carlo simulations.
3.1.37
maximum permitted repair time
MPRT
maximum time allowed to repair a fault before undertaking an action to make the risk disappearing
EXAMPLE:
When a dangerous fault is revealed for a safety system operating in demand mode, it may be decided to reach a safe state when a maximum duration has elapsed: a MPRT of 8 h means, for example, that if the repair is not completed after 8 h, the process is shut down. Then a safe state is reached, the fault is no longer dangerous, and it is not necessary to take into account the remaining time spent to complete the repair. This is illustrated in Figure 6, Figure 7 and Figure B.1. When the fault may result of several failure modes, the MPRT allows to repair those within short MRT without shutdown of the process.
Note 1 to entry: When a MPRT is defined as a maintenance procedure it is necessary to take it into consideration for the probabilistic calculations of hazardous events. Reciprocally it is necessary that this MPRT be respected during the actual repair actions in order to keep the probabilistic calculations valid.
Note 2 to entry: The role of the MPRT is close to the role of the MTTS (see 0). The difference is that the MPRT is a maximum duration allowed to reach a safe state and the MTTS is the average duration needed to reach the safe state when a dangerous fault is revealed (see Figure 6 and Figure 7). The methods developed in this Technical Report have been focused on random repair values (MTTRes, MRT, MTTS) rather than on deterministic values (MPRT), but the MPRT can be easily handled by using Petri nets and Monte Carlo simulations.
3.1.38
mean time to demand
MTTD
expected time before the demand on the safety system occurs
3.1.39
restoration rate
μ
conditional probability per unit of time that the restoration of a failed item ends between t and t+dt, provided that it was not finished over
Note 1 to entry: The following relationship holds when the restoration rate is constant: MTTRes = 1/μ.
Note 2 to entry: The “restoration” rate is in relationship with the restoration time. Similarly the “repairing” rate can be defined in relationship with the “overall repairing” time and the “active repair” rate in relationship with the “active repair” time.
Note 3 to entry: The restoration rate has the same mathematical properties for the restoration as the failure rate for the failures.
3.2 Failure classification
Explanations about the various states and the various failures of a safety system are developed in Annex B.
3.2.1
failure
loss of ability to perform as required
Note 1 to entry: A failure of an item is an event, as distinct from a fault of an item, which is a state (see Figure 8).
[SOURCE:IEC 60050 −191]
3.2.2
fault
inability to perform as required
Note 1 to entry: A fault of an item is a state, as distinct from a failure of an item which is an event (see Figure 8).
Note 2 to entry: A fault of an item may result from a failure of the item or from a deficiency in an earlier stage of the life cycle, such as specification, design, manufacture or maintenance.
Note 3 to entry: Qualifying terms may be used to indicate the cause of a fault, such as specification, design, manufacture, maintenance or misuse.
Note 4 to entry: Inability to perform due to preventive maintenance, other planned actions, or lack of external resources does not constitute a fault.
- The Failure x occurs at stage 1 and leads to the state Fault x which is not detected.
- from stage 2 point of view Fault x is a pre-existing fault.
- The Failure y occurs at stage 2 and lead to the state Faults x,y which is not detected.
- From stage 3 point of view Fault x,y is a pre-existing fault.
- and so on.
Figure 8 — Relationship between failure and fault concepts
3.2.3
dangerous failure
unsafe failure
failure of a safety system which tends to impede a given safety action
Note 1 to entry: This is a systemic failure in relationship with a given safety action performed by the safety system. Therefore this concept is irrelevant for an individual item on the shelves.
Note 2 to entry: See Figure B.1.
3.2.4
critical dangerous failure
dangerous failure leading to the complete inhibition of the safety action (i.e. leading to a dangerous situation for the protected system)
Note 1 to entry: This is a systemic failure in relationship with a given safety action performed by the safety system. Therefore this concept is irrelevant for an individual item on the shelves.
Note 2 to entry: The same failure of a component belonging to a safety system with internal redundancy may be dangerous or critical dangerous depending on the system state from which it occurs.
Note 3 to entry: The critical dangerous failures that are undetected (e.g. those revealed by periodic tests) are sometimes called safety critical failures (cf. ISO 14224[15]). The equipment subject to such potential failures can be identified within a plant and monitored, and the ratio between the number of safety critical failures detected by periodic tests and the corresponding number of tests performed (commonly called “failure fraction”) is being used for that purpose. This indicator of the average unavailability (PFDavg) due to dangerous undetected failures is established by using test reports. It is important not to mix such failure fraction with other reliability terms.
3.2.5
safe failure
failure of a safety system which tends to favour a given safety action
Note 1 to entry: The concept of safe failure is illustrated in Figure B.1.
Note 2 to entry: A failure is safe only with regard to a given safety function. This is a systemic failure in relationship with a given safety action performed by the safety system. This concept is irrelevant for an individual item on the shelves.
Note 3 to entry: The non-critical safe failures basically increase the probability of success of the safety function. The critical safe failures initiate the related safety actions when this is not needed (see spurious failures).
3.2.6
spurious failure
failure triggering an action in an untimely manner
Note 1 to entry: Critical safe failures (see Figure B.1) are the typical spurious failures related to safety systems.
Note 2 to entry: A spurious failure does not necessarily imply a spurious trip (3.4.14) but a spurious trip is always the result of a spurious failure.
3.2.7
critical safe failure
spurious failure of a safety system, due to safe failure(s) of its component(s), triggering the safety action and leading to a spurious safety action
Note 1 to entry: The concept of critical safe failure is illustrated in Figure B.1.
Note 2 to entry: This is a systemic failure in relationship with a given safety action performed by the safety system. This concept is irrelevant for an individual item on the shelves.
Note 3 to entry: The same failure of a component belonging to a safety system may be safe or spurious (critical safe) depending of the system state from which it occurs (e.g. the safe failure of a sensor belonging to 2oo3 is only safe when it occurs in 1st position. It is critical when it occurs in 2nd position).
3.2.8
systemic failure
holistic failure
failure at system level which cannot be simply described from the individual component failures of the system
Note 1 to entry: Systemic/holistic principles have been concisely summarized by Aristotle by “The whole is more than the sum of its parts”.
Note 2 to entry: Components have only failure modes. Those failure modes become dangerous, safe or spurious only when the components are implemented into a safety “system”. This is why dangerous, safe or spurious failures are typical systemic failures. For example the failure “fail to close” of a valve is dangerous only if it belongs to a safety system closing this valve on demand. Otherwise this failure mode does not matter.
Note 3 to entry: “Systematic” failures (i.e. occurring in a deterministic way when given conditions are encountered, see 3.2.17) and “systemic” failures should not be confused.
3.2.9
catalectic failure
sudden and complete failure
Note 1 to entry: This term has been introduced by analogy with the catalectic verses (i.e. a verse with seven foots instead of eight) which stop abruptly. Then, a catalectic failure occurs without warning and is more or less impossible to forecast by examining the item. It is the contrary of failures occurring progressively and incompletely.
Note 2 to entry: Catalectic failures characterize simple components with constant failure rates (exponential law): they remain permanently “as good as new” until they fail suddenly, completely and without warning. Most of the probabilistic models used in reliability engineering are based on catalectic failures of the individual component of the system under study (e.g. Markovian approach).
3.2.10
immediately revealed failure
overt failure
detected failure
evident failure
failure which is immediately evident to operations and maintenance personnel as soon as it occurs
Note 1 to entry: The immediately revealed failures show themselves immediately, but the hidden failures which are quickly detected by specific diagnostic tests are generally considered as immediately revealed failures.
Note 2 to entry: The repair of immediately revealed failures may begin immediately after they have occurred.
Note 3 to entry: The failures which are detected by periodic tests are not considered as immediately revealed failures.
3.2.11
hidden failure
covert failure
dormant failure
unrevealed failure
undetected failure
failure which is not immediately evident to operations and maintenance personnel
Note 1 to entry: Hidden failures do not show themselves when they occur. The occurrence of a hidden failure gives a latent fault which may be revealed by specific tests (e.g. periodic tests) or by the failure of the item to perform its function when required.
Note 2 to entry: The repair of hidden failures cannot begin as long as they have not been detected. The unknown times spent between the failures and their detections belong to the MTTRes.
3.2.12
time-dependent failure
failure occurring with a probability depending of the time
Note 1 to entry: The unreliability F(t) is a typical probability function describing time-dependent failures
3.2.13
failure due to demand
failure occurring on demand
γ, ψ
failure of one item due to a change of its state triggered by an external event (the so-called “demand”)
EXAMPLE 1:
Obtaining 2 when launching a dice is an event occurring on demand. The probability of this event is 1/6. It does not depend on the elapsing time but only of the demand itself (i.e. the fact that the dice is launched).
EXAMPLE 2:
The failure of an electromechanical relay (e.g. rupture of the spring) when it changes state depends on the number of operations (cycles) rather on the operating time (see IEC 61810–2[49] ) and this is the same for the failure of an electronic device due to over voltage when it is switched or the blocking of a diesel engine when it is started, etc.: these are typical examples of failures due to demands (or cycles).
Note 1 to entry: In this Technical Report two kinds of demand are considered: the periodic tests and the demand for an actual safety action. The probability of a failure due to periodic test is a constant number noted γ and the probability of a failure due to one actual demand of the safety action is a constant number noted ψ. Over a given time interval, those probabilities of failure do not depend on the duration but on the number of demands or tests occurring within this interval. The use of γ and ψ is explained in 7.3.
Note 2 to entry: This should not be confused with the “failure on demand” appearing in the term “probability of failure on demand” (see 3.1.14, Note 2 to entry) used in functional safety standards[2] for low demand mode safety systems. In those standards this means “failures likely to be observed when a demand occurs”.
3.2.14
common cause failures
CCF
failures of different items, resulting from a single event ここで, these failures are not consequences of each other
Note 1 to entry: It is generally accepted that the failures occur simultaneously or within a short time of each other.
Note 2 to entry: Common cause failures can lead to common mode failures.
Note 3 to entry: Common cause failures reduce the effect of system redundancy.
Note 4 to entry: Explicit and implicit CCF are defined in 5.4.2.
3.2.15
common mode failures
CMF
failures of different items, occurring in the same way
Note 1 to entry: Common mode failures may have different causes.
Note 2 to entry: Common mode failures can be due to common cause failures.
3.2.16
random failure
failure, occurring in a random way
Note 1 to entry: A random failure may be time or demand dependent. Whether it occurs or not is not predictable with certainty but the corresponding failure rate (see 3.1.18) or probability of a failure due to demand (see 3.2.13) may be predictable and this allows probabilistic calculations.
EXAMPLE:
Examples of failure mechanisms leading to unpredictable failure occurrence are: hardware random failures resulting from degradation mechanisms; human random failure resulting from error in routine operation, lack of attention, stress, tiredness, etc.
Note 2 to entry: From the probabilistic point of view, the random failures are the contrary of systematic failures (see 3.2.17) which occur in a deterministic way (i.e. with a probability equal to 1) when some conditions are met.
3.2.17
systematic failure
failure that consistently occurs under particular conditions of handling, storage or use
Note 1 to entry: The cause of a systematic failure originates in the specification, design, manufacture, installation, operation or maintenance. Its occurrence is precipitated by particular conditions of handling, storage, use or maintenance (see Figure G.3)
Note 2 to entry: Corrective maintenance without modification will usually not eliminate the failure cause.
Note 3 to entry: A systematic failure can be reproduced by deliberately applying the same conditions, e.g. in verifying the failure cause (from IEC 60050–191 ed3[14] ). Systematic failures are non-random failures (see 3.2.16).
Note 4 to entry: In operation, a systematic failure is a manifestation of a systematic fault (i.e. a pre-existing state of the system).
Note 5 to entry: The software systematic failures, called “bugs”, are example of systematic failures: they are due to pre-existing bugs (i.e. faults) and they occur when the input data activate them.
Note 6 to entry: Systematic and systemic (which means “at system level”) failures (see 3.2.8) should not be confused.
[SOURCE:IEC 60050‑191]
3.3 Safety systems typology
3.3.1
demand mode of operation safety systems
safety system designed to achieve its safety action only when receiving a specific request from its surrounding environment
Note 1 to entry: Such systems spend most of their time in stand-by position but need nevertheless to be ready to work as soon as a demand occurs.
Note 2 to entry: Such systems are subject to hidden failures. Diagnostic and periodic tests are generally implemented in order to reveal the corresponding latent faults.
Note 3 to entry: When the demand frequency increases, an on-demand mode safety system may be assimilated to a continuous mode of operation systems.
3.3.2
continuous mode of operation safety system
safety system designed to achieve its safety action permanently
Note 1 to entry: With a continuous mode safety system the hazardous event occurs as soon as the safety system fails. This is illustrated in Figure B.1 where the systems states “ko” and “hazardous event” are gathered into a single state.
3.3.3
multiple safety systems
safety system comprising several sub safety systems operating one after the other when the prior ones have failed
Note 1 to entry: Industrial processes often implement multiple safety systems (safety layers). In this case the failure of an intermediate safety layer provokes a demand on the proximate succeeding safety layer and so on. The accident occurs only if the demand is transmitted until the ultimate safety layer and it fails to operate.
3.4 Maintenance issues
3.4.1
maintenance
combination of all technical and administrative actions, including supervisory actions, intended to retain an item in, or restore it to, a state in which it can perform a required function
Note 1 to entry: There are two basic categories of maintenance: corrective maintenance done after a failure has occurred and preventive maintenance (testing, inspection, condition monitoring, periodic) done before a failure has occurred. See also ISO 14224[15] , 9.6.
Note 2 to entry: Maintenance activities of either preventive or corrective maintenance category type, is shown in ISO 14224:2006[15] , Table B.5.
[SOURCE:ISO 14224]
3.4.2
maintenance concept
definition of the maintenance echelons, indenture levels, maintenance levels, maintenance support, and their interrelationships
Note 1 to entry: The maintenance concept provides the basis for maintenance planning, determining supportability requirements and developing logistic support.
Note 2 to entry: A maintenance echelon is a position in an organization where specified levels of maintenance are to be carried out (e.g. field, repair shop, manufacturer facility).
[SOURCE:IEC 60050‑191]
3.4.3
preventive maintenance
PM
maintenance carried out at predetermined intervals or according to prescribed criteria and intended to reduce the probability of failure or the degradation of the functioning of an item
[SOURCE:ISO 14224]
3.4.4
corrective maintenance
maintenance carried out after fault detection to effect restoration
Note 1 to entry: Corrective maintenance of software invariably involves some modification.
Note 2 to entry: Sometimes the corrective maintenance is also called curative maintenance.
[SOURCE:IEC 60050‑191-46-06]
3.4.5
detection method
method or activity by which a failure is discovered
Note 1 to entry: A categorization of detection methods (e.g. periodic testing or continuous condition monitoring) is shown in ISO 14224:2006[15] , Table B.4.
3.4.6
maintenance plan
structured and documented set of tasks that include the activities, procedures, resources and the time scale required to carry out maintenance
Note 1 to entry: The maintenance plan should be thoroughly analysed and modelled to produce relevant probabilistic results.
Note 2 to entry: The forecasted probabilistic results established at the design stage are no longer valid if the maintenance plan which has been considered is not thoroughly applied in operation.
Note 3 to entry: The maintenance plan should cover policies for both preventive maintenance (e.g. testing) and corrective maintenance (e.g. minimize downtime, restore lost redundancy).
Note 4 to entry: The maintenance plan is part of an overall Operations and Maintenance plan. It is sometimes called “maintenance policy”.
[SOURCE:EN 13306]
3.4.7
test policy
set of procedures describing the various test operations (frequencies and procedures) scheduled to reach the safety requirements of a given safety system
Note 1 to entry: The test policy should be thoroughly analysed and modelled to produce relevant probabilistic results.
Note 2 to entry: The forecasted probabilistic results established at the design stage are no longer valid if the test policy which has been considered is not thoroughly applied in operation.
3.4.8
periodic tests
proof tests
planned operation performed at constant time interval in order to detect the potential hidden failures which may have occurred in the meantime
Note 1 to entry: The unsafe hidden failures of a safety system which are not detected by the diagnostic tests may be detected by periodic tests. Such tests are named “proof tests” in the standards dealing with functional safety (e.g. IEC 61508[2] ).
[SOURCE:IEC 61508]
3.4.9
diagnostic tests
automatic operations performed at high frequency in order to detect the potential hidden failures as soon as possible when they occur
Note 1 to entry: The unsafe failures of safety system are generally hidden and diagnostic tests may be implemented to detect the larger part of them. As the diagnostic cycle is normally short, the hidden failures detected by diagnostic tests are assimilated to immediately revealed failures.
[SOURCE:IEC 61508]
3.4.10
staggered testing (of redundant items)
test of several items with the same test interval but not at the same time
EXAMPLE:
Figure 9 shows staggered tests for two item A and B.
Figure 9 — Example of test staggering for a system made of two redundant items A and B
3.4.11
redundancy
existence of more than one means for performing a required function
Note 1 to entry: The aim of redundancy is to provide backup in case of one or several failures of the means performing a required function.
Note 2 to entry: Redundancy definitions for passive (cold) standby, active (hot) standby and mixed are given in ISO 14224[15] , C.1.2.
Note 3 to entry: Redundancy is sometimes (in IEC 61508[2] and IEC 61511[3]) called “fault tolerance”.
[SOURCE:ISO 14224]
3.4.12
spurious activation (of a safety function)
untimely demand of a safety function when this is not needed
Note 1 to entry: The spurious activation of a safety function may be due to the occurrence of one or several safe failures.
3.4.13
spurious action (of a safety system)
result of a spurious activation of a safety function
Note 1 to entry: A spurious safety action is not necessary safe. An example of spurious action is a spurious trip.
3.4.14
trip
shutdown of machinery from normal operating condition to full stop
- a) Trip: the shutdown is activated automatically by the control/monitoring system.
- • Real trip: the shutdown is activated as a result of a monitored (or calculated) value in the control system exceeding a pre-set limit.
- • Spurious trip: unexpected shutdown resulting from failure(s) in the control/monitoring system or error(s) imposed by on control/monitoring system originating from the environment or people.
- b) Manual shutdown: the machinery is stopped by an intended action of the operator (locally or form the control room).
Note 2 to entry: Sometimes statements like “equipment trip” or “spurious trip” can be misleading terminology used for failures causing (rotating) equipment shutdown, especially when it is treated as failure mode in reliability data or modelling. A failure mechanism (see Table B.2 of ISO 14224[15] ) can be of various types (e.g. mechanical, instrument) and should not be mixed with the term failure modes (of which one is spurious trip). Failure modes are not necessarily instrument-related failures, but could be mechanical failures. See for example failure modes in Table B.6 of ISO 14224[15] for rotating equipment.
[SOURCE:ISO 14224]
3.4.15
reliability data
data for reliability, maintainability and maintenance support performance
Note 1 to entry: Reliability and maintainability (RM) data is the term applied by ISO 14224[15] .
[SOURCE:ISO 20815]
3.4.16
generic reliability data
reliability data covering families of similar equipment
Note 1 to entry: See ISO 14224[15] for further details on equipment boundaries and equipment taxonomies that define these families of equipment within the petroleum, petrochemical and natural gas industries.
Note 2 to entry: Plant-specific data on specific equipment could be part of generic reliability databases, but could differ a lot from generic data and should not be mixed with those.
[SOURCE:ISO 14224]
3.5 Other terms
3.5.1
critical state
in a states-transitions model, state belonging to a given class of states and which is distant from the failure class of states by only one transition
Note 1 to entry: This is a mathematical concept in relationship with e.g. Markovian process or Petri nets models.
EXAMPLE:
The states of a safety system can be sorted out into two classes: class OK when the safety action is available and KO when the safety action is inhibited. In this case a critical state with regards to the safety system failure belongs to the class OK and only one failure (i.e. on event) is needed to have a transition to the class ko.
3.5.2
dysfunction
impaired or abnormal functioning of an item
Note 1 to entry: This term is built from the Greek prefix “dys” (i.e.” with difficulty”) and the Latin term “functio” (i.e. an activity with a given aim). Primarily used in the medical field, this term is now often used within the technological field as a more generic term than “failure” or “fault”.
3.5.3
dysfunctioning analysis
set of activities aiming to analyse the dysfunctions of an item
Note 1 to entry: This is the counterpart of the functioning analysis which aims to analyse how an item works when the dysfunctioning analysis aims to analyse how an item fails by e.g. identifying, sorting out, characterizing and/or evaluating the probability of occurrence of the dysfunctions.
Note 2 to entry: The term “dysfunctional” analysis is often used as a synonym of “dysfunctioning” analysis.
3.5.4
formal language
set of words, semantics and logical rules with sound mathematical properties
Note 1 to entry: Programming languages are an example of formal language with mathematical properties allowing them to be compiled into computer executable code.
Note 2 to entry: Every reliability model has an underlying formal language behind the graphical elements (e.g. the Binary logic for Boolean models).
Note 3 to entry: Specific formal languages have been developed to model the functioning and the dysfunctioning of industrial systems (e.g. AltaRica[11][12] ). According to their powerfulness of modelling and their mathematical properties they can be compiled toward event trees, fault trees, Markov graphs, Petri nets, accident sequences, etc. Some of them can also be directly used for Monte Carlo simulation.
3.5.5
functioning analysis
set of activities aiming to analyse how an item performs as required
Note 1 to entry: This is the counterpart of the dysfunctioning analysis which aims to analyse how an item fails when the functioning analysis aims to analyse how an item works by, e.g. identifying, sorting out and characterizing the various functions related to the item.
Note 2 to entry: The term “functional” analysis is often used as a synonym of “functioning” analysis. However, the term “functional analysis” which has several meanings is not used in this Technical Report to avoid confusion.
3.6 Equipment-related terms
3.6.1
high integrity protection system
HIPS
non-conventional autonomous safety instrumented system with sufficiently high safety integrity (see 3.2.1) to protect equipment against exceeding the design parameters
Note 1 to entry: Deviations from industry standards describing mechanical protection systems (e.g. ISO 23251[31] = API STD 521[32] , ISO 10418[33] , API RP 14C[58] ) are treated as HIPS. An ultimate protection relying solely on Safety Instrumented Systems (SIS) is qualified as HIPS, irrespective of its required Safety Integrity Level (SIL).
3.6.2
high integrity pressure protection system
HIPPS
HIPS exclusively devoted to protection against overpressure
Note 1 to entry: Alternative terminology: over pressure protection system (OPPS).
- • full pressure rating of downstream equipment, or
- • adequately sized mechanical pressure relief devices, or
- • design the disposal system for simultaneous reliefs.
3.6.3
HIPPS valve
valve used as a final element in a HIPPS system
3.6.4
subsea isolation valve
SSIV
SIV
valve which closes within a defined time limit derived from the risk assessment in order to reduce consequences of pipeline/riser leak or rupture
Note 1 to entry: The SSIV can be an actuated valve (e.g. remotely controlled subsea valve) or a non-activated valve (subsea check valve). An activated valve is normally designed as fail safe (i.e. closes and remains closed on all failures external to the valve and actuator themselves).
Note 2 to entry: Where the flexible risers are connected directly to the subsea wellhead, the master and wing valve may be considered to represent the SSIV function.
[SOURCE:ISO 14723]
3.6.5
subsurface safety valve
SSSV
device installed in a well below the wellhead with the design function to prevent uncontrolled well flow when actuated
Note 1 to entry: These devices can be installed and retrieved by wireline (Wireline retrievable) and/or pump down methods (TFL-Thru Flow Line) or be integral part of the tubing string (Tubing retrievable).
3.6.6
surface-controlled subsurface safety valve
SCSSV
SSSV controlled from the surface by hydraulic, electrical, mechanical or other means
Note 1 to entry: The SCSSV is sometimes called DHSV (downhole safety valve).
[SOURCE:ISO 14723]
3.6.7
subsurface-controlled subsurface safety valve
SSCSV
SSSV actuated by the characteristics of the well itself
Note 1 to entry: Note 1 to entry: These devices are usually actuated by the differential pressure through the SSCSV (velocity type) or by tubing pressure at the SSCSV (high or low pressure type).
[SOURCE:ISO 14723]
3.6.8
SSSV system equipment
components which include the surface-control system, control line, SSSV, safety valve lock, safety valve landing nipple, flow couplings and other downhole control components
[SOURCE:ISO 10417]