A 　 特定の条件下で特定の機能を実行するように組み合わされた、相互に依存するコンポーネントのセットとして定義できます。 機械は、この意味で具体的で特に明確なシステムの例ですが、男性と女性がチームやワークショップや工場に関与するシステムは他にもあり、はるかに複雑で定義がそれほど簡単ではありません. 安全性 危険がないこと、または事故や危害のリスクがないことを示唆しています。 あいまいさを避けるために、 望ましくない出来事 採用されます。 多かれ少なかれ不幸な事件が発生する可能性がないという意味での絶対的な安全は達成できません。 現実的には、望ましくない事象が発生する確率をゼロにするのではなく、非常に低い確率を目指す必要があります。

特定のシステムは、実際に期待されるパフォーマンスに関してのみ、安全または安全でないと見なされる場合があります。 これを念頭に置いて、システムの安全レベルは次のように定義できます。期間"。 現在の関連で関心のある望ましくない出来事の例には、複数の死亡者、XNUMX 人または数人の死亡、重傷、軽傷、環境への損傷、生物への有害な影響、植物または建物の破壊、および重大な事故が含まれます。または限定的な物的または機器の損傷。

安全システム分析の目的

システムの安全性分析の目的は、望ましくない発生の確率に関係する要因を確認し、これらの発生がどのように発生するかを研究し、最終的にはその確率を下げるための予防策を開発することです。

問題の分析フェーズは、次の XNUMX つの主な側面に分けることができます。

1. の識別と説明 機能不全または不適応の
2. の識別 シーケンス 相互に（またはより「正常な」出来事と）組み合わさって、最終的に望ましくない出来事自体につながる機能障害と、その可能性の評価。

さまざまな機能障害とその結果が調査されると、システム安全アナリストは予防措置に注意を向けることができます。 この分野の研究は、以前の発見に直接基づいています。 この予防手段の調査は、システムの安全性分析の XNUMX つの主要な側面に従います。

分析方法

システムの安全性分析は、イベントの前または後に (アプリオリまたは事後) 実施することができます。 どちらの場合も、使用される方法は直接または逆のいずれかです。 事前分析は、望ましくない事態が発生する前に行われます。 アナリストは、そのような出来事を一定数取り上げ、それらに至るまでのさまざまな段階を発見しようと試みます。 対照的に、事後分析は、望ましくない事象が発生した後に実行されます。 その目的は、将来のためのガイダンスを提供することであり、具体的には、その後の事前分析に役立つ可能性のある結論を導き出すことです。

事前分析は事後分析よりもはるかに価値があるように見えるかもしれませんが、それはインシデントに先行するため、実際にはXNUMXつは補完的です. どの方法が使用されるかは、関連するシステムの複雑さと、対象についてすでにわかっていることによって異なります。 機械や産業施設などの具体的なシステムの場合、以前の経験は通常、かなり詳細なアプリオリ分析を準備するのに役立ちます。 ただし、その場合でも、分析は必ずしも確実ではなく、基本的に操作中に発生するインシデントの研究に基づく事後分析から利益を得ることが確実です。 勤務シフト、ワークショップ、工場など、人が関与するより複雑なシステムに関しては、事後分析がさらに重要です。 そのような場合、過去の経験は、詳細で信頼できる事前分析を可能にするのに必ずしも十分ではありません。

事後分析は、アナリストが問題のインシデントにつながった単一のプロセスを超えて、そのようなインシデントまたは類似のインシデントに合理的につながる可能性のあるさまざまな出来事を調べ始めると、アプリオリ分析に発展する可能性があります。

事後分析がアプリオリ分析になるもう XNUMX つの方法は、発生 (その防止が現在の分析の主な目的) ではなく、重大度の低いインシデントに重点が置かれる場合です。 技術的な問題、物的損害、潜在的または軽微な事故など、それ自体は比較的重要ではないこれらの事故は、より深刻な事態の警告サインとして識別できます。 このような場合、軽微なインシデントの発生後に分析が行われますが、まだ発生していないより重大なインシデントに関してはアプリオリな分析となります。

XNUMX つ以上のイベントのシーケンスの背後にあるメカニズムまたはロジックを調査するには、次の XNUMX つの方法が考えられます。

1. 　 直接または 帰納、メソッドは、その結果を予測するために原因から始まります。
2. 　 逆または 演繹的な、メソッドは結果を見て、原因に逆戻りします。

図 1 は、XNUMX つのボタン (B₁ とB₂) を同時に押して、リレー コイル (R) を作動させ、機械を始動します。 この例は、実際の用語で説明するために使用できます。 直接 & 逆 システムの安全性分析で使用される方法。

図 1. XNUMX ボタン制御回路

直接法

直接法アナリストは、(1) 障害、機能不全、および不適応を列挙し、(2) それらの影響を調査し、(3) それらの影響が安全に対する脅威であるかどうかを判断することから始めます。 図 1 の場合、次の障害が発生する可能性があります。

• 2 と 2´ の間のワイヤーの断線

• Cでの意図しない接触₁ (または C₂) 機械的ブロッキングの結果として

• B の偶発的な終了₁ (または B₂)

• 1 と 1' の間の短絡。

その後、アナリストはこれらの障害の結果を推測し、結果を表形式で示すことができます (表 1)。

表 1. XNUMX ボタン制御回路の考えられる機能不全とその結果

※システムの信頼性に直接影響する事象
** システムの安全レベルを著しく低下させる原因となる事象
***避けるべき危険な出来事

テキストと図 1 を参照してください。

表 1 では、システムの安全レベルを著しく低下させる、または危険な結果は、*** などの従来の記号で示すことができます。

注： 表 1 では、2 と 2' の間のワイヤーの断線 (図 1 に示されている) は、危険とは見なされない発生をもたらします。 システムの安全性に直接的な影響はありません。 ただし、そのようなインシデントが発生する確率は、システムの信頼性に直接影響します。

直接法は、シミュレーションに特に適しています。 図 2 は、プレス制御回路の安全性を調査するために設計されたアナログ シミュレータを示しています。 制御回路のシミュレーションにより、障害がない限り、回路が安全基準に違反することなく必要な機能を実際に確保できることを検証できます。 さらに、シミュレーターを使用すると、アナリストは回路のさまざまなコンポーネントに障害を導入し、その結果を観察して、適切に設計された (危険な障害がほとんどまたはまったくない) 回路と、設計が不十分な回路を区別できます。 この種の安全分析は、コンピューターを使用して実行することもできます。

図 2. プレス制御回路の研究用シミュレータ

逆の方法

逆の方法、アナリストは、望ましくない出来事、事件、または事故からさかのぼって、さまざまな以前の出来事に向かって、回避すべき出来事につながる可能性があるものを判断します。 図 1 で回避すべき最終的な事態は、意図しない機械の始動です。

• マシンの始動は、リレー コイル (R) の制御されていない起動によって引き起こされる場合があります。

• 次に、コイルの起動は、1 と 1' の間の短絡、またはスイッチ C の意図的でない同時の閉鎖から生じる可能性があります。₁ およびC₂.

• C の意図しない終了₁ Cの機械的遮断の結果である可能性があります₁ または、誤って B を押した場合₁. 同様の理由が C にも当てはまります。₂.

この分析の結果は、図 3 に示すように、ツリーに似た図で表すことができます (このため、逆の方法は「フォールト ツリー分析」として知られています)。

図 3. 考えられる一連のイベント

ダイアグラムは論理演算に従いますが、その中で最も重要なのは「OR」と「AND」演算です。 「OR」演算は、[X₁] は、[A] または [B] (または両方) が発生した場合に発生します。 「AND」演算は、[X₂] が発生する可能性がある場合、[C] と [D] の両方が発生している必要があります (図 4 を参照)。

図 4. XNUMX つの論理演算の表現

逆の方法は、特に化学、航空、宇宙、原子力産業において、具体的なシステムのアプリオリ分析で非常によく使用されます。 また、労働災害の調査方法としても非常に有用であることがわかっています。

それらは大きく異なりますが、直接法と逆法は補完的です。 直接法は一連の障害または機能障害に基づいているため、このような分析の価値は、最初に考慮されたさまざまな機能障害の関連性に大きく依存します。 この観点から見ると、逆の方法はより体系的であるように思われます。 どのようなタイプの事故やインシデントが発生する可能性があるかについての知識があれば、アナリストは理論上、この方法を適用して、それらを引き起こす可能性のあるすべての機能障害または機能障害の組み合わせに戻ることができます。 ただし、システムのすべての危険な動作が事前にわかっているとは限らないため、シミュレーションなどを適用した直接的な方法で発見することができます。 これらが発見されると、逆の方法でハザードをより詳細に分析できます。

システム安全解析の問題点

上記の分析方法は、システムの安全性を改善するための有用な結論に到達するために自動的に適用するだけでよい単なる機械的プロセスではありません。 それどころか、アナリストは仕事の過程で多くの問題に遭遇し、彼らの分析の有用性は、彼らがそれらの解決にどのように着手するかに大きく依存します. 発生する可能性のある典型的な問題のいくつかを以下に説明します。

検討するシステムとその動作条件を理解する

システムの安全性分析における基本的な問題は、調査対象のシステムの定義、その制限、およびそのシステムが存在する限り動作すると想定される条件です。

アナリストが考慮に入れているサブシステムがあまりにも限定的である場合、その結果、一連のランダムな予防措置が採用される可能性があります (すべてが特定の種類の発生を防止するように調整されている一方で、同様に深刻なハザードは無視または過小評価されている状況)。 ）。 一方、システムが特定の問題に関して包括的または一般的すぎると、概念と責任が過度に曖昧になり、分析が適切な予防措置の採用につながらない可能性があります。

研究対象のシステムを定義する問題を説明する典型的な例は、産業用機械またはプラントの安全性です。 この種の状況では、アナリストは、XNUMX 人または複数の人によって操作または制御されなければならないという事実を見過ごして、実際の機器のみを考慮したくなるかもしれません。 この種の単純化は有効な場合があります。 ただし、分析する必要があるのは、機械のサブシステムだけではなく、機器の寿命のさまざまな段階 (たとえば、輸送と取り扱い、組み立て、テストと調整、通常の操作など) における作業者と機械のシステム全体です。 、メンテナンス、分解、場合によっては破壊）。 各段階で、機械は特定のシステムの一部であり、その目的と機能および誤動作のモードは、他の段階のシステムとはまったく異なります。 したがって、各段階で良好な安全条件下で必要な機能を実行できるように設計および製造する必要があります。

より一般的に言えば、企業における安全研究に関しては、機械、ワークステーション、シフト、部門、工場、および企業全体など、いくつかのシステムレベルがあります。 どのシステム レベルが考慮されているかによって、考えられる機能不全のタイプと関連する予防措置はまったく異なります。 優れた予防政策では、さまざまなレベルで発生する可能性のある機能障害を考慮に入れる必要があります。

システムの動作条件は、システムが機能すると想定される方法、およびシステムが影響を受ける可能性のある環境条件に関して定義することができます。 この定義は、システムが動作する可能性が高い実際の条件を考慮して、十分に現実的でなければなりません。 非常に制限された動作範囲でのみ非常に安全なシステムでも、ユーザーが規定された理論上の動作範囲内に収まらない場合、それほど安全ではない可能性があります。 したがって、安全なシステムは、システムが機能する条件の合理的な変動に耐えるのに十分な堅牢性を備えている必要があり、オペレーター側の特定の単純だが予見可能なエラーを許容する必要があります。

システムモデリング

システムの安全性を分析するために、モデルの開発が必要になることがよくあります。 これにより、検討する価値のある特定の問題が発生する可能性があります。

従来の機械のような簡潔で比較的単純なシステムの場合、モデルは、材料コンポーネントとその機能 (モーター、トランスミッションなど) の記述、およびこれらのコンポーネントの相互関係からほぼ直接導き出すことができます。 考えられるコンポーネントの故障モードの数も同様に制限されています。

コンピューターやロボットなどの最新のマシンには、マイクロプロセッサや非常に大規模に統合された電子回路などの複雑なコンポーネントが含まれており、特別な問題が生じます。 この問題は、各チップに非常に多くの基本トランジスタがあり、さまざまな種類のソフトウェアが使用されているため、モデル化または考えられるさまざまな故障モードの予測に関して完全には解決されていません。

分析対象のシステムが人間の組織である場合、モデリングで遭遇する興味深い問題は、特定の非物質的または完全に物質的ではないコンポーネントの選択と定義にあります。 特定のワークステーションは、たとえば、作業者、ソフトウェア、タスク、機械、材料、および環境を含むシステムによって表すことができます。 (「タスク」コンポーネントを定義するのは難しいかもしれません。なぜなら、カウントされるのは規定されたタスクではなく、実際に実行されるタスクだからです)。

人間の組織をモデル化する場合、アナリストは検討中のシステムを情報サブシステムと XNUMX つまたは複数のアクション サブシステムに分解することを選択できます。 情報サブシステムのさまざまな段階 (情報の取得、送信、処理、および使用) における障害の分析は、非常に有益です。

複数レベルの分析に関連する問題

複数レベルの分析に関連する問題が発生することがよくあります。これは、アナリストが望ましくない出来事から始めて、時間的にますます遠く離れたインシデントに戻る可能性があるためです。 考慮される分析のレベルに応じて、発生する機能不全の性質は異なります。 予防措置についても同様です。 どのレベルで分析を停止し、どのレベルで予防措置を講じるべきかを判断できることが重要です。 例としては、異常な状態で機械を繰り返し使用することによって引き起こされた機械の故障に起因する事故の単純なケースがあります。 これは、オペレーターのトレーニングが不足しているか、作業の組織が不十分であることが原因である可能性があります。 考慮される分析のレベルに応じて、必要な予防措置は、より厳しい使用条件に耐えることができる別の機械による機械の交換、通常の条件下でのみ機械を使用すること、人員訓練の変更、または組織の再編成である可能性があります。仕事。

予防措置の有効性と範囲は、導入されるレベルによって異なります。 望ましくない出来事のすぐ近くでの予防措置は、直接的かつ迅速な影響を与える可能性が高くなりますが、その効果は限られている場合があります。 他方では、出来事の分析において合理的な範囲で逆方向に作業することによって、多くの事故に共通するタイプの機能障害を見つけることが可能になるはずです。 このレベルで講じられる予防措置は、範囲がはるかに広いものになりますが、その有効性は直接的ではない可能性があります。

分析にはいくつかのレベルがあることを念頭に置いて、予防行動には多数のパターンがあり、それぞれが予防作業の独自の役割を担っています。 これは非常に重要な点であり、現在検討中の事故の例に戻るだけでその事実を理解することができます。 マシンをより厳しい使用条件に耐えることができる別のマシンに置き換えることを提案すると、マシンに防止の責任が生じます。 機械を通常の状態でのみ使用することを決定することは、ユーザーに責任を負わせることを意味します。 同様に、責任は、人員のトレーニング、作業の編成、または同時に機械、ユーザー、トレーニング機能、および組織機能に課せられる場合があります。

どのレベルの分析においても、事故は多くの場合、いくつかの機能不全または不適応の組み合わせの結果であると思われます。 ある機能障害に対して対策を講じるか、複数の機能障害に対して同時に対策を講じるかによって、採用される予防措置のパターンは異なります。

戻る