Medical devices — Application of risk management to medical devices のリスク評価の定義について見て欲しい。
リスクは、危害の発生確率（the probability of occurrence of harm）と、危害の重大度（the consequences of that harm, that is, how severe it might be. ）により評価されるというのが ISO 14971 の考え方である。一般的にも、リスク = 発生確率 × 重大度 などと書かれる。
例えば、ハードウェア部品の故障による障害などでは、発生確率はすなわち部品の故障率となり、その部品が故障したときの被害の大きさが重大度となる。よって、故障率が非常に低い場合のリスクは低いと考える。
なぜなら、危害の発生確率は部品の故障率のように数値で示すことができないことも多々あり、また、危害の重大度は極めて主観的であり、時代や人々の考え方によって常に変化するパラメータであるからである。
このマトリクスでは濃い青の部分が半定量的な確率レベルと定性的な重大さのレベルにより、そのリスクは受容できないと判断されたエリアである。薄いブルーの部分は更なるリスク低減を検討すれば受容できるリスク、白い部分は受容できるリスクと判断している。
この表に出てくる「しばしば」や「時々」「わずかに」や、「軽微な」「きわどい」「重大な」といった評価指標は定性的と言いながらも主観的な表現だ。 発生確率が定量化できない、重大さのレベルが定量化できないので、半定量的もしくは定性的に評価しているのだ。その判定基準はその組織が積み重ねてきた事故データや判定者の経験的主観に依存している。
医療機器で実例を挙げてみよう。心拍は心臓右心房付近にある洞房結節から発生される電気的な刺激の発信がトリガーとなって起動される。この自発のペースメーカの機能に欠陥がある患者さんには、ペースメーカが植え込まれる。
ペースメーカにはさまざまな機能があるが、自発の心拍がたまに欠落するような場合は、ペースメーカは心拍が欠落したときにのみ心臓を刺激する。これをデマンドペーシングと呼ぶ。自発の心拍がまったくない場合は固定レートで心臓を刺激するこれを固定レートペーシングと呼ぶ。
障害の発生確率はハードウェアの場合部品の故障率で予測できると書いたが、ハードウェアであっても設計上のミスや、ソフトウェアのバグによる障害の発生は、その確率を予測することができない。このような故障、欠陥のことを Systematic Failure / Systematic Fault (決定論的故障/欠陥）と呼び、医療機器の世界では今のところ、Systematic Failure の発生確率は1、すなわち発生確率は考えずに、障害の重大さだけでリスクを評価することにしている。
「原子炉が制御不能になる」というリスクの発生確率は福島の原発事故が起こる前は「考えられない」だったかもしれない。しかし、起こってしまった今の評価はどうだろうか。「考えられない」「起こりそうにない」といった評価を日本国民は許さないだろう。
さて、「原子炉が制御不能になる」のリスク分析に話を戻そう。「原子炉が制御不能になる」のリスク評価は、現実に事故が起こったことで、発生確率の評価は厳しい方向に動いた。結果的に、リスクは受容できないという判断になった。
この場合、この後どうしたらよいだろうか。リスクコントロール手段の一つとして「原子力発電をしない」という選択肢がある。この対策を取れば、「原子炉が制御不能になる」というリスクからは解放される。現在の日本の状況がまさにこれに当たる。「原子炉が制御不能になる」というリスクの場合、重大さのレベルは破局的から下がることはないので、もしも、どうしても原子力発電を続けるのであれば新たなリスクコントロール手段によって、リスクを受容できるようになるのかどうかを判断しなければならない。
リスクマネジメントにより事故を未然に防ぐことができれば一番よいのだが、リスク対策は実際には発生してしまった事故に向き合うことで前進する。安全を本気で実現したいのなら、事故に正面から向き合うしかない。ただ、自組織の体験だけが必要なのではない。世の中で発生してしまった過去の事故、他社の事故も再発防止策を考えるのに役立つ。現実には事故を再発させない、再発させてはいけないという関係者共通の意志がリスクコントロールの進化を後押しするのである。
今回、リスク分析、リスクアセスメントを話題にしたのは理由がある。その理由を説明する前に次の2つの ISO 26262 に関連した各企業のプレスリリースを見ていただきたい。
これらのプレスリリースに強い違和感を感じるのは、これらのマイコンメーカーはおそらく自動車の具体的なリスク分析やリスクアセスメントに基づいてマイコンを設計したのではないだろうという点だ。特に「規格発行後はフェイルセーフ機能を搭載することが必要となります」というくだりはひどい。規格が発行されるから安全対策が必要などというのは、本末転倒も甚だしい。ISO 26262 は自動車メーカやサプライヤが自分達が分析、設計した安全対策を国際標準に基づいて説明するためにある。
このブログの特集記事で常に訴えているように、エンドユーザーに対して安全の責務を負っていない者は平気でそのような発言をする。医療機器ドメインではそんな売り込みのされ方をしたことはないから、自動車開発にまつわる市場の大きさがそういったセールストークを作り出すのだろう。
さて、これらのプレスリリースの前者は、「一部の機能が故障しても安全に制御するフェールセーフ機能を搭載している」と書いてあり、後者はDual Core Lockstep（デュアルコア・ロックステップ）：ロックステップを実行する２つのプロセッシングユニットの結果を随時比較して故障を検出する故障検出技術を搭載していると書いてある。
リスクを想定せずに安全設計はできない。なぜなら、すべてのリスクに有効なリスクコントロール手段など存在しないからだ。「一部の機能が故障しても安全に制御する」「故障を検出する機能を有する」という文言は一見どんなリスクにも効くように見えるが、ECU側でそれらの機能がリスクを低減するリスクコントロール手段になっていなければ意味がない。マイコンサイドはその機能がリスクを低減させると考えているのだろうが、具体的にどのようなリスクを低減することに効果があるのか分析しているとは思えない。
例えば、「高速走行中にブレーキが効かなくなる」というリスクに対してこれらのマイコンはどのように有効に働くのだろうか。カーブを高速走行中にブレーキアイテムに不具合が発生したことが分かったり、緊急処置としての補助プロセスが起動されたりしている間に車のコントロールが効かなくなってスピンし始めても、上記のようなマイコンの機能は車の制御を立て直すことができるのだろうか。そんなことはECUの設計者、自動車システム全体の設計者に聞いてくれと言うのだろう。リスク分析が行われずに、何にでも効くという部品を作っても意味がない。
この話は福島の原発事故とよく似ている。どんなに考え抜かれたリスクコントロール手段を準備していても、補助電源を用意していても、結局「原子炉が制御不能になる」というリスクを回避することはできなかった。まったく電源を使わない状態でも原子炉を冷やす手段は用意されていたが、オペレーションの問題もあって有効には働かなかった。
今回の記事で言いたいのは、リスク分析やリスクアセスメントをしないで、安全に効果があるなどと言うのはやめなさいということだ。部品の信頼性を高めることはできても、安全はリスクを想定しなければ効果を主張することはできない。リスクを想定しないで、安全をうたうのは間違いだ。
例えば、安全を確保するために十分に検証されたコンパイラを使ったとしよう。それで安全が確保されたのか。そんなはずはない、十分に検証されたコンパイラは決して、誤ったコードをはき出すことはないのか、どんなに複雑な条件であっても決定論的故障は起こさないのか。コンパイラの取り扱い説明書に誤記があって、それを信じて誤った使い方をした場合、それはコンパイラの不具合ではないと言うのか。コンパイラが完璧であったとして、ミドルウェアに問題があったらどうするのか。
コンパイラには関係ないユーザビリティに関するリスクは重要ではないのか。電源喪失時のリスクは考慮しないでいいのか。安全を確保するために必要なことを挙げたらきりがない。どんな些細なことも見逃さないように対策を始めたら、時間と工数は無限にかかる。したがって、有限な時間と工数で安全な商品やサービスを提供するためには、リスク分析、リスクアセスメントは欠かせない。ユーザーに対して最もリスクの高い障害のリスクコントロールから順番に対策を取っていかなければ、リスク対策は終わらない。
部品やツールの信頼性の検証活動は、システム全体のリスクコントロールのほんの一部でしかない。それだけに注力を注いでも、大元のリスクが大幅に軽減できるとは限らない。商品やシステムに責任を負うものは、それらをひっくるめてユーザーに降りかかるリスクを受容できるレベルまでコントロールしなければいけない。
自分はたまたまソフトウェアエンジニアでありながら、リスク分析、ハザード分析、リスクアセスメント、リスクコントロール手段の設計などを行いながら、商品の安全性と向き合ってきた。
【ISO 26262-2:2011 Part 2: Management of functional safety】
今回は ISO 26262-2 機能安全のマネジメント 5.2.2 安全ライフサイクルに関する注釈 を読み進んでいる。下記の図の説明となるので、図を手元に置きながら読んでもらった方がよいと思う。
※用語の定義の邦訳にあたり、ISO 26262 の全体像を説明する図も一部ことばを見直して Ver 1.01 としたので利用して欲しい。(ISO 26262 全体構造図 開くためのパスワードは"guild26262"）
(「セーフティライフサイクルの外観」開くためのパスワードは"guild26262"）
5.2.2 Explanatory remarks on the safety lifecycle
5.2.2 安全ライフサイクルに関する注釈
ISO 26262 specifies requirements with regard to specific phases and subphases of the safety lifecycle, but also includes requirements that apply to several, or all, phases of the safety lifecycle, such as the requirements for the management of functional safety.
ISO26262は、安全ライフサイクルの特定のフェーズとサブフェーズに関しての要求を定めまるが、安全ライフサイクルのフェーズ、機能安全のマネジメントのための要求などのようにいくつかの、またはすべてフェーズに適用される要求も含んでいる。
The key management tasks are to plan, coordinate and track the activities related to functional safety.
キーマネジメントタスクとは、機能安全に関連する活動を計画、調整、追跡することである。
These management tasks apply to all phases of the safety lifecycle.
これらのマネジメントタスクは安全ライフサイクルのすべてのフェーズに適用される。
The requirements for the management of functional safety are given in this part, which distinguishes:
つぎの部分で機能安全のマネジメントのための要求を与える:(部分は識別される)。
- overall safety management (see this clause);
- 全体的なセーフティマネジメント(この箇条を見よ)。
- safety management during the concept phase and the product development (see Clause 6);
- コンセプトフェーズ間のセーフティマネジメントと製品開発(箇条6を見よ)。
- safety management after the item's release for production (see Clause 7).
- 生産(箇条 7を見よ)のためのアイテムのリリースの後のセーフティマネジメント。
The following descriptions explain the definitions of the different phases and subphases of the safety lifecycle, as well as other key concepts:
以下の説明文では異なるフェーズの定義とセーフティライフサイクルのサブフェーズについて他の重要な考えと同様に説明する。:
a) The subphase:
a) サブフェーズ:
item definition
アイテム定義
The initiating task of the safety lifecycle is to develop a description of the item with regard to its functionality, interfaces, environmental conditions, legal requirements, known hazards, etc.
セーフティライフサイクルに関する開始タスクは、機能性、インタフェース、環境条件、法的要求、周知のハザードなどに関してアイテムの説明を作成することである。
The boundary of the item and its interfaces, as well as assumptions concerning other items, elements, systems and components are determined (see ISO 26262-3:2011, Clause 5).
アイテムとそのインタフェースの境界、および他のアイテムに関する仮定、要素、システム、およびコンポーネントは決められている。(ISO26262-3:2011を見よ。箇条 5)。
b) The subphase:initiation of the safety lifecycle
b）サブフェーズ：セーフティライフサイクルの開始
Based on the item definition, the safety lifecycle is initiated by distinguishing between either a new development, or a modification of an existing item.
アイテム定義に基づいて、セーフティライフサイクルは、新規開発か、既存アイテムの変更のどちらであるかを識別することによって開始される。
If an existing item is modified, the results of an impact analysis are used to tailor the safety lifecycle (see ISO 26262-3:2011, Clause 6).
既存アイテムが変更されているなら、インパクト分析の結果は、セーフティライフサイクルをテーラリングするのに使用される。(ISO26262-3:2011を見よ。箇条 6)。
c) The subphase:hazard analysis and risk assessment
c) サブフェーズ：ハザード分析とリスクアセスメント
After the initiation of the safety lifecycle, the hazard analysis and risk assessment is performed as given in ISO 26262-3:2011, Clause 7.
セーフティライフサイクルの開始の後、ハザード分析およびリスクアセスメントが ISO26262-3:2011、箇条7 によって実行される。
First, the hazard analysis and risk assessment estimates the probability of exposure, the controllability and the severity of the hazardous events with regard to the item.
まず最初に、ハザード分析とリスクアセスメントでは、アイテムに関して危険な事象の暴露の確率、コントローラビリティ、および重大度を推定する。
Together, these parameters determine the ASILs of the hazardous events.
これらのパラメータは危険な事象のASILを同時に決定する。
Subsequently, the hazard analysis and risk assessment determines the safety goals for the item, with the safety goals being the top level safety requirements for the item.
次に、ハザード分析とリスクアセスメントは、トップレベルの安全要求であるセーフティゴールとともに、そのアイテムのセーフティターゲットを決定する。
The ASILs determined for the hazardous events are assigned to the corresponding safety goals.
危険な事象のために決定するASILは対応するセーフティゴールに割り当てられる。
During the subsequent phases and subphases, detailed safety requirements are derived from the safety goals.
その後のフェーズとサブフェーズの間、詳細な安全要求がセーフティゴールから派生して得られる。
These safety requirements inherit the ASIL of the corresponding safety goals.
これらの安全要求は対応するセーフティゴールのASILを引き継ぐ。
d) The subphase:functional safety concept
d) サブフェーズ:機能安全コンセプト
Based on the safety goals, a functional safety concept (see ISO 26262-3:2011, Clause 8) is specified considering preliminary architectural assumptions.
セーフティゴールに基づいて、機能安全コンセプト(ISO26262-3:2011、箇条8を見よ)は予備的なアーキテクチャの仮定を考慮して明示される。
The functional safety concept is specified by functional safety requirements that are allocated to the elements of the item.
機能安全コンセプトはアイテムの要素に割り当てられる機能安全要求によって指定される。
The functional safety concept can also include other technologies or interfaces with external measures, provided that the expected behaviours thereof can be validated (see ISO 26262-4:2011, Clause 9).
また、機能安全コンセプトは、妥当性が確認され、予想された振る舞いを提供できるのであれば、外部計測を伴うインタフェースや他の技術を含むことができる。(ISO26262-4:2011を見よ。箇条9)。
The implementation of other technologies is outside the scope of ISO 26262 and the implementation of the external measures is outside the scope of the item development.
ISO26262のスコープの外に他の技術の実装がある。そして、外部計測の実装はアイテム開発のスコープの外側となる。
e) The phase:product development at the system level
e) システムレベルにおける製品開発
After having specified the functional safety concept, the item is developed from the system level perspective, as given in ISO 26262-4.
機能安全コンセプトを明示した後に、アイテムはISO26262-4で与えられるようにシステムレベル見地で開発される。
The system development process is based on the concept of a V-model with the specification of the technical safety requirements, the system architecture, the system design and implementation on the left hand branch and the integration, verification, validation and the functional safety assessment on the right hand branch.
システム開発プロセスはテクニカル安全要求によってVモデルの概念に基づいている。Vモデルの左手の枝にはシステムアーキテクチャ、システム設計、実装が、Vモデルの右側の枝には、結合、検証、バリデーション、および機能安全評価がある。
The hardware-software interface is specified in this phase.
ハードウェア-ソフトウェアインタフェイスはこのフェーズで指定される。
Figure 1 provides an overview of the subphases of the product development at the system level.
図1はシステムレベルで製品開発のサブフェーズに関する概要を提供する。
The product development at the system level incorporates validation tasks for activities occurring within other safety lifecycle phases, including
システムレベルの製品開発は他のセーフティライフサイクルフェーズの中で発生する次のような活動のためのバリデーションタスクを組み入れる。
- the validation of the aspects of the functional safety concept that are implemented by other technologies;
- 他の技術で実装される機能安全コンセプトの側面のバリデーション
- the validation of the assumptions concerning the effectiveness and the performance of external measures;
- 外部計測の有効性及び性能に関する仮定のバリデーション
- the validation of the assumptions concerning human response, including controllability and operational tasks.
- コントローラビリティ及びオペレーションを含む人間の応答に関する仮定のバリデーション
The release for production is the final subphase of the product development and provides the item’s release for series production (see ISO 26262-4:2011, Clause 11).
生産のためのリリースは、製品開発の最終的なサブフェーズであり、連続生産のためのアイテムリリースを提供する。(ISO26262-4:2011を見よ、箇条11)。
f) The phase:product development at the hardware level
f) フェーズ:ハードウェアレベルにおける製品開発
Based on the system design specification, the item is developed from the hardware level perspective (see ISO 26262-5).
システム設計仕様に基づいて、アイテムはハードウェアレベルの見地から開発される。(ISO26262-5を見よ）。
The hardware development process is based on the concept of a V-model with the specification of the hardware requirements and the hardware design and implementation on the left hand branch and the hardware integration and testing on the right hand branch.
ハードウェア開発過程はハードウェア要件の仕様でVモデルの概念に基づいている。左の枝ではハードウェア設計とインプリメンテーションが、右の枝ではハードウェアインテグレーションとテストがある。
Figure 1 provides an overview of the subphases of the product development at the hardware level.
図1はハードウェアレベルで製品開発のサブフェーズに関する概要を提供する。
g) The phase:product development at the software level
g) フェーズ:ソフトウェアレベルにおける製品開発
Based on the system design specification, the item is developed from the software level perspective (see ISO 26262-6).
システム設計仕様に基づいて、アイテムはソフトウェアレベルの見地から開発される(ISO26262-6を見よ)。
The software development process is based on the concept of a V-model with the specification of the software requirements and the software architectural design and implementation on the left hand branch, and the software integration and testing, and the verification of the software requirements on the right hand branch.
ソフトウェア要求の仕様、ソフトウェアアーキテクチャデザイン、およびインプリメンテーションが左手にあって、ソフトウェア統合、テスト、およびソフトウェア要求の検証が右手にあり、ソフトウェア開発プロセスはVモデルの概念に基づいている。
Figure 1 provides an overview of the subphases of the product development at the software level.
図1はソフトウェアレベルで製品開発のサブフェーズに関する概要を提供する。
h) Production planning and operation planning
h) 生産計画と運用計画
The planning for production and operation, and the specification of the associated requirements, starts during the product development at the system level (see ISO 26262-4).
製品開発の間、生産と運用のための計画立案、および関連要求の仕様はシステムレベルで始まる(ISO26262-4を見よ)。
The requirements for production and operation are given in ISO 26262-7:2011, Clauses 5 and 6.
ISO26262-7:2011箇条5と6 で生産と運用のための要求を与える。
i) The phase: production and operation, service and decommissioning
i) フェーズ:生産、運用、サービス、および廃棄
This phase addresses the production processes relevant for the functional safety goals of the item, i.e. the safety-related special characteristics, and the development and management of instructions for the maintenance, repair and decommissioning of the item to ensure functional safety after the item's release for production (see ISO 26262-7:2011, Clauses 5 and 6).
このフェーズは、アイテムの機能安全ゴールに関連した生産プロセスを扱う。すなわち、安全関連の特別な特性、保守や修理、開発、アイテムリリース後の機能安全を確実にするためのアイテムのデコンポジッションのための指示、訓練の開発やマネジメントなど。(ISO26262-7:2011を見よ、箇条5と6)。
j) Controllability
j) コントローラビリティ
In the hazard analysis and risk assessment (see ISO 26262-3:2011, Clause 7), credit can be taken for the ability of the driver, or the other persons at risk, to control hazardous situations.
ハザード分析とリスクアセスメント(ISO26262-3:2011を見よ、箇条7)で、危険な状態をコントロールするためのドライバーや危険に遭遇するその他の人々の技量の信頼度である。
The assumptions regarding the controllability in the hazard analysis and risk assessment and the functional and technical safety concept are validated during the safety validation (see Figure 2 and ISO 26262-4:2011, Clause 9).
ハザード分析とリスクアセスメントにおけるコントローラビリティに関する仮定と機能的でテクニカルなセーフティコンセプトは安全バリデーションの間で妥当性が確認される。(図2と ISO 26262-4:2011を見よ、箇条9)。
NOTE The exposure and the severity are factors that depend on the scenario.
ノート 暴露と重大度は、シナリオに依存する要素である。
The eventual controllability through human intervention is influenced by the design of the item and is therefore evaluated during the validation (see ISO 26262-4:2011, 9.4.3.2).
人間の介入の結果として起こるコントローラビリティは、アイテムのデザインによって影響を受ける。したがって、バリデーションの間、評価される(ISO26262-4: 2011、9.4.3.2を見よ)。
k) External measures
k) 外部手段
The external measures refer to the measures outside the item, as specified in the item definition (see Figure 2 and ISO 26262-3:2011, Clause 5), that reduce or mitigate the risks resulting from the item.
外部手段はアイテム定義で示される(図2とISO 26262-3:2011を見よ、箇条5)アイテムから生じるリスクを低減または緩和するアイテムの外側の手段を示す。
External measures can include not only additional in-vehicle devices such as dynamic stability controllers or run-flat tyres, but also devices external to the vehicle, like crash barriers or tunnel fire-fighting systems.
外部手段はダイナミック安定制御装置やランフラットタイヤなどの追加的な車内のデバイスだけではなく、中央分離帯やトンネル消防システムのように車の外部のデバイスも含むことができる。
The assumptions regarding the external measures in the item definition, the hazard analysis and risk assessment and the functional and technical safety concept are validated during the safety validation (see Figure 2 and ISO 26262-4:2011, Clause 9).
アイテム定義、ハザード分析、およびリスクアセスメントにおける外部手段と機能的でテクニカルな安全コンセプトに関する仮定はセーフティバリデーションの中で妥当性が確認される(図2とISO 26262-4:2011を見よ、箇条9)。
External measures can be considered in the hazard analysis and risk assessment.
ハザード分析とリスクアセスメントで外部手段を考慮できる。
However, if credit is taken from an external measure in the hazard analysis and risk assessment, that external measure cannot be considered as a risk reduction in the functional safety concept.
しかしながら、ハザード分析とリスクアセスメントの中で外部手段から信用を得るなら、その外部手段は機能安全コンセプトの中ではリスク軽減と見なすことはできない。
ISO 26262 also applies to those external measures that are in the scope of ISO 26262.
また、ISO26262はISO26262のスコープのある外部手段として適用される。
l) Other technologies
l) 他の技術
Other technologies, e.g. mechanical and hydraulic technologies, are those different from electrical and/or electronic technologies that are in the scope of ISO 26262.
他の技術(例えば、機械技術、流体技術)はISO 26262のスコープの中にある電気的な、そして/または、電子の技術とは異なる技術である。
These can be considered in the specification of the functional safety concept (see Figure 2 and ISO 26262-3:2011, Clause 8), during the allocation of safety requirements (see ISO 26262-3 and ISO 26262-4), or as an external measure.
これらは、安全要求(ISO26262-3とISO26262-4を見よ)の割り当ての間、または、外部手段において機能安全コンセプト(図2とISO 26262-3:2011を見よ、箇条8)の仕様を考慮することができる。
NOTE If an implementation in another technology is specified as an external measure, then it can be useful to repeat the hazard analysis and risk assessment to consider the associated risk reduction, which could potentially result in a reduced ASIL of a corresponding safety goal.
注意 もしも、他の技術の実装が外部手段によって指定されているのであれば、セーフティゴールに対応する潜在的に減少されたASILによって関連するリスクの軽減を考慮するハザード分析やリスクアセスメントを繰り返すことに役立つ。
