機能安全について誤解されやすいこと

PFD/PFHはSIL計算の議論で最も支配的なパラメータです。しかし、それは対話を過度に支配するかもしれません。どちらの値もランダムなハードウェア障害に対処し、通常はFMEDAを使用して計算されます。どちらも、安全関連システムまたはサブシステムの危険な故障の確率を表します。しかし、これらはSILの決定に関与する計算が唯一だけでなく、ランダムなハードウェア障害が唯一の根拠ではないため、単独のデータとして独立して取り扱うことはできません。また、ハードウェアやソフトウェアの系統的な障害を回避し、制御することも重要です。系統的な能力を維持することは、安全関連系の開発中に使用された方法及び技術に反映されています。これらの方法と技法の厳密さは、系統的な故障や設計に固有の故障を回避する上で極めて重要です。PFD/PFHは、故障が危険な場合に故障の可能性を最小限に抑えるために重要な安全システムのハードウェアのランダムな故障を決定する一方で、系統的な能力を維持することは、それが最も必要とされるときに安全性を損なうであろう設計上の誤りが存在する可能性を最小限に抑えます。

システムインテグレータおよびプラントメーカは、制御システムおよび/またはユーティリティの一定の信頼性を確保することを考えて、サプライヤにSILを考慮した通常運用のための制御システムを納入するよう要求することがあります。しかし、安全機能(安全関連システムによって実行される)の目的は、可用性を増加させる目的ではなく、EUC(Equipment Under Control)を安全な状態に置くことです。

EUCの安全な状態は、危険度とリスク分析の結果であり、その異なる運用モードに依存します。この文脈において、筆者らは、フェイルセーフ・シナリオに関する戦略及びコンセプトに関する誤解、例えば、故障時にEUCを停止すること、及び故障時の動作シナリオ、即ち、EUCをできるだけ作動状態に維持すること、について頻繁に観測しました。実際、制御システムの信頼性の尺度としてSILを使用すると、詳細な計算に伴い不備な点が生じます。

ランダムハードウェア故障(および信頼性)は、故障率に基づいて計算されます。機能安全関に関して故障率とは、安全側故障と危険側故障に分けられます。PFD/PFH値の計算では、危険側故障(意図したとおりに実行する安全機能を妨げるような)のみが考慮されます。したがって、SILは、EUCを安全な状態にすることが要求され、安全機能が意図したとおりに実行される信頼性の尺度にしか過ぎませんし、制御システムの信頼性を反映している訳ではありません。

内部ウォッチドッグは、故障検出をし、故障があることを示す信号を出力するためだけに存在しているものではありません。ウォッチドッグは、考えられる欠陥のあるマイクロコントローラの一部であるため、自己診断率を提供するためにウォッチドッグに依存することはできません。また、多くのウォッチドッグは出力を提供せず、コントローラをリセットすることを目的としています。

IEC61508には、ハードウェア(ルート2H)とソフトウェア(ルート2S)の両方に実証済みの使用アプローチを使用する可能性が含まれています。SWでは、動作中に個々の故障を検出して報告されなければならない。すべての組合せの入力データ、実行シーケンスおよびタイミングを文書化する必要があります。各開発者は、実証済みの使用アプローチと比較して、技術と手段を用いて系統的能力を評価することで賛否を考慮する必要がありますが、SW(ルート2S)は実用的なアプローチではありません。

非安全部品/構成部品/設計要素は、しばしば安全系と混合されます。これは、複雑さとシステムコストを低減できる標準的なアプローチです。ただし、これを行うには、混合された安全度水準設計手法が使用されている場合に、干渉の自由度の証拠を提供する必要があります。解析には、非安全部分及び安全システムへの影響を含む詳細なハードウェア又はソフトウェア故障モード解析が含まれます。

安全クリティカルソフトウェアの開発において、自動化されたツールの使用は、今日、効率と安全性の点で最先端のものです。しかし、何度もこれらの誤った使われ方をしたツールの使用を見てきました。まず、単体テスト仕様書は、ソースコードのホワイトボックス分析のみならず、ソフトウェアユニット/モジュール仕様書に基づいて記載します。目的は、ソフトウェアユニットの機能的挙動をテストし、その挙動が安全仕様に沿っているかどうかを判断することです。ホワイトボックス分析は、この時点でも有用なツールですが、コードレベルで必要とされるテストカバレッジの証拠だけを提供するものではありません。

現代の複雑な安全関連システムでは、スマートセンサの使用がますます普及しています。センサーは、リスクレベルに対応するSILを持つか、設計者が全体の安全機能に干渉の自由度の証明を提供することが要求されます。複雑なスマートセンサーの故障モード(すなわち、論理処理ユニット、通信プロトコルなどを備えたもの)が、必要な診断範囲と故障検出/反応時間の範囲内で、何らかの外部安全ユニットによって診断され、緩和されることができるという仮定に基づいているので、それらのシステム設計は間違っています。

通常、電源は見落とされます。我々は、電源の保護/監視の欠落に関連する問題を散見します。安全規格では、過電圧/不足電圧の対策をどのように詳細に実施するかは規定されていませんが、SILレベルによっては、保護に適したメカニズムが整っている必要があります。最も一般的な見落としの1つは、HFT>1が要求される場合に過電圧保護に冗長性を実装しないことです。別の一般的に共通で見られるものは、例えば、より広い電圧範囲が使用可能である分離したコンポーネント(部品）の欠如です。供給電圧監視(スイッチオフのような必要な反応および安全状態を含みます)は、より広い電圧範囲で動作可能であり、それ自体が過電圧/不足電圧条件に影響されないコンポーネントによって分離したされるべきである。たとえ、短い持続時間の過電圧であっても、外見上明らかな損傷を受けることなく、マイクロコントローラの部品内部に恒久的な損傷を与える可能性があります。したがって、過電圧後のマイクロコントローラのリセットは適切な手段ではありません。しかし、不足電圧状態の後に、不足電圧が持続しない場合には、リセットはOKになる可能性があります。

過温度検出とそれぞれの反応(安全状態に入る、スイッチオフ、。..)は、指定された温度範囲外で操作されるコンポーネント(マイコンなど)では実行できません。また、過熱状態が続くか、スイッチオン中にすでに存在すると仮定しなければならないため、単純なリセットでも十分ではありません。低温は安全規格(EN50129など)では考慮されないこともありますが、アプリケーション条件(ユーザーマニュアルに記載)では、デバイスが指定された温度範囲(すべてのコンポーネントに対して)内でのみ駆動されるようにする必要があります。

SIL(Safety Integrity Level)の略語は、複数の規格で使用されています。しかし、それぞれの規格では、異なるプロセス、構造的、技術的要件に関するものです。規格の中には、ASIL(Automotive SIL)のように異なる略語を使用するものがあります。同じ略語(SIL)を使用しているものもあり、混乱や誤解の危険があります。

例えば、SIRF(Sicherheitsrichtlinie Fahrzeug;EBA)によって使用されるようなSASレベル(german:「Sicherheitsanforderungsstufe」for Safey Integrity Level)は、EN50128/EN50129によって使用されるSILレベル(「Safety Integrity Level)。SIRF(SAS)は、EN50129の付属書Eに記載されている手段の一部のみを使用し、組織的およびプロセス的な手段は少なく、ハザード率の定義された制限はありません。IEC61508の文脈におけるSILは、EN50129の文脈におけるSILとは異なります。SILを安全度レベルではなくソフトウェア・インテグリティ・レベルとして定義すると、複雑さが増すことがあります(EN50657などを参照)。

SILシステムを組み合わせるだけでは、システムのSILレベルを上げることはできません。たとえば、いくつかのSIL2システム/チャネルを組み合わせるだけではSILをSIL4に上げることはできません。また、いくつかのSIL2制御システムによってシステムレベルのSIL3に到達することもできません。たとえば、SIL2ソフトウェアプロセスは、SIL4に必要なものと同じように系統的なソフトウェア障害を防止しません。たとえば、IEC61508規格では、2つの独立したシステムがデュアルチャネル構造で使用されている場合、系統的能力を1ずつ増加させることができます。均一冗長性の場合、これは不可能です。他の規格(EN50129など)では、この可能性は提供されていません。

共通原因は、フォールトツリー解析(FTA)において良く忘れられます。同時にシステムのいくつかの部分に影響を与える可能性のある障害(電源喪失など)は、フォルトツリーの関連するすべての分岐で基本イベントとして含める必要があります。代替的なアプローチは、FTAツールで「ベータファクタ」を使用することによって共通原因を実装することです。

SIL(安全度水準)の定義は、何らかの種類のリスク分析/分類によって導出された起源にある機能に適用されます。システム/コンポーネントの場合、「SIL2コントローラ」、「SIL3ブレーキシステム」などのように文章を聞くのが一般的です。SIL用語の正しい使い方は、SILは特定の(安全)機能にのみ関連しています。どちらの機能がリスク分析のゴールから得たものですか? より正しい定義は、「システムはSILxまでの安全機能を実装する能力があります」ということです。つまり、規格のプロセス、構造的、技術的要件がシステムによって満たされていることになります。

システムの境界線を明確に定義することが重要です。安全システムの境界線は分析され、そして他のシステム部へのインターフェースとなりますが、プロジェクトの開始時に明確に定義されないことが多いです。それから、どのコンポーネントがシステムの一部であるかは明らかではありません。例えば、どのセンサ/アクチュエータのバリエーションが考慮されるべきか、などです。スコープを定義せずに安全解析を開始することは、スコープが変更されるたびに不要な解析の反復を受けることになります。

特定のSILに分類される安全機能に属する故障検出および監視ブロック(診断)に、別個のSILレベルのようなものはないです。一部の規格では、要求される完全性レベルを1下げることができますが、機能安全の観点からは、診断は安全機能の一部です。インテグリティ要件は、自己診断にも適用されます。さらなるでコンポジション(分解）分析は、完全性レベルを低減することを可能にしますが、通常、いかなる安全要件も除外することはできません。

システムの起動ごとに、一部の健全性診断/自己診断が実行されます(RAMテスト、フラッシュCRCチェック、出力テストなど)。これらのテストは非常に重要で、自己診断に関する議論や、安全解析における故障検出時間(テスト間隔)のために使用されます。ただし、運転条件が変わることがある場合もあります(新規プロジェクト、新規要件など)。定期的に電源を切っていたシステム、長時間電源を入れたままにしておいたシステム。例えば、近代的な鉄道システムは、今日では、毎朝再スタートすることなく、連続的に電源が入ることが多いです。このような場合、意図された診断手段は有効になりません。従って、安全解析によって必要とされる場合は、定期的な再起動を安全マニュアル、運転員の文書等に明示的に規定しなければなりません。