2012-01-20

ISO 26262との向き合い方 (8) リスク分析しないでいいの?

今回の記事は リスク分析、リスクアセスメントについての話題である。

最初に、医療機器ドメインのリスクマネジメントに関する国際規格である ISO 14971:2007
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、すなわち発生確率は考えずに、障害の重大さだけでリスクを評価することにしている。

※ISO 26262 では、リスクの評価に Controllability(ドライバや周辺の人々の障害の回避容易性)を考慮している。

もう一つ、リスク評価の例を考えてみたい。それは、「原子炉が制御不能になる」というリスクだ。不幸にも日本は昨年、「原子炉が制御不能になる」というリスクに対して「放射能が拡散し、人体に影響を与える。周辺に人が住めなくなる。」といった危害の重大度を実体験として経験してしまった。

「原子炉が制御不能になる」というリスクの発生確率は福島の原発事故が起こる前は「考えられない」だったかもしれない。しかし、起こってしまった今の評価はどうだろうか。「考えられない」「起こりそうにない」といった評価を日本国民は許さないだろう。

冒頭でリスクの評価は数式では表せないといったのは、このことだ。どんなに統計的な確率が低かったとしても、甚大な被害が発生してしまえば、リスクの評価は変わる。

一般的に時間がたつにつれてリスク評価は厳しい方に傾く。なぜなら、リスクコントロール手段が普及すると、人々はそのリスクコントロール手段を“当たり前に実装されているもの”と認識するようになるからである。過去に認識されていたリスクは現在ではブロックされていて当然であり、技術の進歩により機器の安全は進化していると考えるのが一般的な消費者の意識だ。機器を使っていて使い勝手の悪さや不具合を見つけると、どうしてこんなことが考慮されていないのかと消費者は怒りをあらわにする。しかし、そのレベルでリスク分析、リスク対策をしたら何千、何万というリスクコントロールを行わないといけないという作り手側の視点に立つことはない。問題が起これば、ユーザーにとってはその問題が今一番優先度の高い関心事なのだ。

起こってしまった問題を追求することはやりやすいが、同じレベルの問題を見つけ出し、発現しないようにする水平展開は簡単ではない。そのドメインに新規参入する企業や、新人の技術者は“当たり前に実装されているもの”の存在やメカニズムを知らないから、危険な製品を作ってしまう可能性がある。皮肉なことに、ユーザーは事故や不具合を体験することで、メーカーのリスクコントロール手段の存在を知ることがよくある。当たり前にできていることは、それが当たり前でなくなったときに、初めてその存在が分かるのだ。

だから、クリティカルな製品を開発する企業は、リスク分析、リスクアセスメント、リスクコントロール手段の設計と実装、検証、妥当性確認を行う義務を負っている。

さて、「原子炉が制御不能になる」のリスク分析に話を戻そう。「原子炉が制御不能になる」のリスク評価は、現実に事故が起こったことで、発生確率の評価は厳しい方向に動いた。結果的に、リスクは受容できないという判断になった。

この場合、この後どうしたらよいだろうか。リスクコントロール手段の一つとして「原子力発電をしない」という選択肢がある。この対策を取れば、「原子炉が制御不能になる」というリスクからは解放される。現在の日本の状況がまさにこれに当たる。「原子炉が制御不能になる」というリスクの場合、重大さのレベルは破局的から下がることはないので、もしも、どうしても原子力発電を続けるのであれば新たなリスクコントロール手段によって、リスクを受容できるようになるのかどうかを判断しなければならない。

リスクマネジメントにより事故を未然に防ぐことができれば一番よいのだが、リスク対策は実際には発生してしまった事故に向き合うことで前進する。安全を本気で実現したいのなら、事故に正面から向き合うしかない。ただ、自組織の体験だけが必要なのではない。世の中で発生してしまった過去の事故、他社の事故も再発防止策を考えるのに役立つ。現実には事故を再発させない、再発させてはいけないという関係者共通の意志がリスクコントロールの進化を後押しするのである。

具体的なリスクを想定しないで部品を作っちゃう人たち

今回、リスク分析、リスクアセスメントを話題にしたのは理由がある。その理由を説明する前に次の2つの ISO 26262 に関連した各企業のプレスリリースを見ていただきたい。

1) 機能安全規格に対応した電子制御ユニット向け車載用マイコンの製品化について

車載電子制御ユニットを対象とした機能安全規格「ISO26262」が今年中には発行される見込みです。規格発行後は電子制御ユニットの中核部品であるマイコンに対して、一部の機能が故障しても安全に制御する「フェールセーフ」機能を搭載することが必要となります。

2) HEV/EV用モータ制御を効率化する角度センサ(レゾルバセンサ)の特性をプログラマブルに補正できる高性能マイコン「V850E2/PJ4-E」を発売
~機能安全規格ISO26262にも対応し、HEV/EV用モータシステムの高い安全性かつ低コスト化に貢献~

今後自動車業界で適応されるISO26262(注2)に対応するため、高度な故障検出技術を搭載しており、モータ制御など高い安全性が求められるシステムに対応できます。

また、これら車の普及促進に向けたシステムコスト低減も強く求められると共に、ISO26262が発行され安全要求への対応が求められております。

  
これらのプレスリリースに強い違和感を感じるのは、これらのマイコンメーカーはおそらく自動車の具体的なリスク分析やリスクアセスメントに基づいてマイコンを設計したのではないだろうという点だ。特に「規格発行後はフェイルセーフ機能を搭載することが必要となります」というくだりはひどい。規格が発行されるから安全対策が必要などというのは、本末転倒も甚だしい。ISO 26262 は自動車メーカやサプライヤが自分達が分析、設計した安全対策を国際標準に基づいて説明するためにある。

このブログの特集記事で常に訴えているように、エンドユーザーに対して安全の責務を負っていない者は平気でそのような発言をする。医療機器ドメインではそんな売り込みのされ方をしたことはないから、自動車開発にまつわる市場の大きさがそういったセールストークを作り出すのだろう。

さて、これらのプレスリリースの前者は、「一部の機能が故障しても安全に制御するフェールセーフ機能を搭載している」と書いてあり、後者はDual Core Lockstep(デュアルコア・ロックステップ):ロックステップを実行する2つのプロセッシングユニットの結果を随時比較して故障を検出する故障検出技術を搭載していると書いてある。

リスクを想定せずに安全設計はできない。なぜなら、すべてのリスクに有効なリスクコントロール手段など存在しないからだ。「一部の機能が故障しても安全に制御する」「故障を検出する機能を有する」という文言は一見どんなリスクにも効くように見えるが、ECU側でそれらの機能がリスクを低減するリスクコントロール手段になっていなければ意味がない。マイコンサイドはその機能がリスクを低減させると考えているのだろうが、具体的にどのようなリスクを低減することに効果があるのか分析しているとは思えない。

例えば、「高速走行中にブレーキが効かなくなる」というリスクに対してこれらのマイコンはどのように有効に働くのだろうか。カーブを高速走行中にブレーキアイテムに不具合が発生したことが分かったり、緊急処置としての補助プロセスが起動されたりしている間に車のコントロールが効かなくなってスピンし始めても、上記のようなマイコンの機能は車の制御を立て直すことができるのだろうか。そんなことはECUの設計者、自動車システム全体の設計者に聞いてくれと言うのだろう。リスク分析が行われずに、何にでも効くという部品を作っても意味がない。

ところで、前者のマイコンの場合、下記のように書かれているから、ペースペーカが動かないというリスクには有効かもしれない。
専用の監視回路の導入により、内部状態の故障が即時に検出でき、故障発生箇所を絞り込むことが可能となります。そのため当社のマイコンは、最低限の機能を確保しながら動作を継続する「フェールオペレーショナル」が可能な電子制御システムへの組み込みに適しています。
複雑なプログラムであるデマンドペーシングが何らかの原因で効かなくなったときに、最低限の機能で固定レートのペーシングを続けることができるかもしれない。

しかし、よく考えて見て欲しい。そうであったとしてもペースメーカの電源の供給が絶たれれば、そのリスクコントロール手段はまったく意味をなさなくなる。

この話は福島の原発事故とよく似ている。どんなに考え抜かれたリスクコントロール手段を準備していても、補助電源を用意していても、結局「原子炉が制御不能になる」というリスクを回避することはできなかった。まったく電源を使わない状態でも原子炉を冷やす手段は用意されていたが、オペレーションの問題もあって有効には働かなかった。

今回の記事で言いたいのは、リスク分析やリスクアセスメントをしないで、安全に効果があるなどと言うのはやめなさいということだ。部品の信頼性を高めることはできても、安全はリスクを想定しなければ効果を主張することはできない。リスクを想定しないで、安全をうたうのは間違いだ。

機能安全はそもそも、部品単位での信頼性の向上が、システム全体の安全に貢献するかのように受け取られる傾向がある。

クリティカルな製品を作ってユーザーに対する責務を負う立場になれば分かることだが、安全を確保するためには、さまざまなことに気を配らないと目的は達成できない。

例えば、安全を確保するために十分に検証されたコンパイラを使ったとしよう。それで安全が確保されたのか。そんなはずはない、十分に検証されたコンパイラは決して、誤ったコードをはき出すことはないのか、どんなに複雑な条件であっても決定論的故障は起こさないのか。コンパイラの取り扱い説明書に誤記があって、それを信じて誤った使い方をした場合、それはコンパイラの不具合ではないと言うのか。コンパイラが完璧であったとして、ミドルウェアに問題があったらどうするのか。

コンパイラには関係ないユーザビリティに関するリスクは重要ではないのか。電源喪失時のリスクは考慮しないでいいのか。安全を確保するために必要なことを挙げたらきりがない。どんな些細なことも見逃さないように対策を始めたら、時間と工数は無限にかかる。したがって、有限な時間と工数で安全な商品やサービスを提供するためには、リスク分析、リスクアセスメントは欠かせない。ユーザーに対して最もリスクの高い障害のリスクコントロールから順番に対策を取っていかなければ、リスク対策は終わらない。

部品やツールの信頼性の検証活動は、システム全体のリスクコントロールのほんの一部でしかない。それだけに注力を注いでも、大元のリスクが大幅に軽減できるとは限らない。商品やシステムに責任を負うものは、それらをひっくるめてユーザーに降りかかるリスクを受容できるレベルまでコントロールしなければいけない。

自分はたまたまソフトウェアエンジニアでありながら、リスク分析、ハザード分析、リスクアセスメント、リスクコントロール手段の設計などを行いながら、商品の安全性と向き合ってきた。

ISO 26262の特集記事は、それらの経験を踏まえて、本当に安全を確保するにはエンジニアは何をやなければいけないのかを書いていきたいと思う。



【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によって関連するリスクの軽減を考慮するハザード分析やリスクアセスメントを繰り返すことに役立つ。

2012-01-03

ISO 26262との向き合い方 (7) 自動車ソフトの未来予想図

正月休みの間、自動車業界が直面するであろう安全ソフトウェアの問題(=自動車ソフトウェアの未来予想図)について二つのシナリオ考えてみた。まずは、これら未来のシナリオを読んでみていただきたい。





シナリオ1 電気自動車時代の不具合

2020年、電気自動車用の充電プラグは家庭やコンビニエンスストアにも普及が進み、郊外には電気スタンドもよく見かけるようになってきた。充電場所が増えるにつれて、それまで聞いたこともない電気自動車メーカー、ブランドの車も数多く現れてきた。電気自動車の販売価格帯は二極化しており、老舗の自動車メーカーの150万円以上のブランド車と、アジアのメーカーの100万円以下の車に人気が集中している。低価格電気自動車は安いものなら50~60万円で買えるようになり、都心の若い世代ではこのような低価格電気自動車を個人で購入するのではなく、電気自動車がシェアカーとして用意されているマンションを選ぶようになってきた。

電気自動車の普及の裏で、困っているのは自動車の新規登録を許可している日本の規制当局だ。申請数が多すぎて数をさばききれない。かといって5年前に締結されたTPP協定によって、外国メーカーの自動車の新規登録が遅れると協定違反となって国際司法裁判所に提訴されるようになったから、手続きを遅らせる訳にはいかない。だから手続きは粛々とこなしていかなければならない。職員は増やしたが経験が追いついていないため、細かい見落としはどうしても増えている。

許認可の問題だけでなく、新規参入の自動車メーカーが作った自動車そのものの不具合が原因の事故も確実に増えている。電子制御のブレーキが突然効かなくなる、アクセルが急加速する、モータが急停止するといった、日本の自動車メーカーが起こしたらトップニュースになるような不具合が当たり前のように起こるようになった。電気自動車では部品をサプライヤから買い集めて組み合わせるだけで簡単に完成品ができるようになり、自動車ドメインでの経験をほとんど持っていない企業の電気自動車製造販売の参入が急増したことが原因だ。アセンブリメーカーはできるだけ安く自動車を作ることが使命であるため、もっとも安くECUを供給できるサプライヤからハード、ソフトを買う。自動車業界ではプラットフォームの共通化が進んだことで、どこのECUを買ってきても表面上は問題なく動くようになった。非常にわかりにくいソフトウェアに起因した不具合があることなど気にもせず、新規参入のアセンブリメーカーは安いECUを供給するサプライヤに次々と切り替えるため、これまで発生していなかった問題がECUの切り替えとともに突然起こったりする。

自動車のソフトウェアの作り方がすり合わせから組み合わせに変わり、規格化された共通インタフェースの部品を共通プラットフォームに接続することで基本的な電気自動車の機能が実現できるようになった。しかし、一つ一つの部品を一から作ったことがない、それどころか一つ一つのデバイスの性能限界もよく分かっていないアセンブリメーカーには、突然発生したソフトウェア制御のブレーキの誤動作やアクセルの急加速といった原因がまったく分からないし、何をどうやって調べればよいのか見当もつかない。したがって、このような原因不明の事故を起こした新規参入の自動車メーカーの車は、最近、日本では急速に販売数を減らしている。日本でも自動車雑誌にリコール情報の分析データがワーストランキングと共に掲載されるようになった。一方アジアの国々では、それでも低価格の電気自動車はまだ人気がある。

事故を起こしたメーカーも ISO 26262 適合というフレコミのECUを使っていた。アセンブリメーカー自身もISO 26262 のプロセス認定を受けている。それでも事故が起こるのはシステム全体に対する安全管理ができていなかったからなのだ。日本の自動車メーカーが当然のようにできていた不具合の原因追及や再発防止策の立案、継続的な改善活動が新規参入のアセンブリメーカーにはできない。しかし、だからといってアセンブリメーカーを市場から排除しようとすると非関税障壁だと訴えられてしまう。そうなると日本の消費者は自分の安全を自分で守るしかなくなる。事故情報を分析することで自動車の価格と自分の安全を天秤にかけるしかない。家庭電化製品と同じように消費者はまず、自動車の安全情報のサイトで事故情報と既存ユーザーの評判をじっくり読んでから、販売店に向かうようになった。2020年、自動車は選択を誤ると安心して運転できない恐ろしい乗り物になった。

シナリオ2 高級車に搭載するインテリジェンス安全機能の落とし穴

早いスピードには危険が伴う
2020年、ハイエンドの自動車にはセーフティに関する要求のさらなる多様化が進んでいる。もう、高級車市場におけるしのぎの削り合いのテーマはアメニティではなくセーフティに変わりつつある。それは、安価な低価格電気自動車がさまざまな事故を起こしていることで消費者のセーフティへの関心や要求が高まっているからだ。しかし、すでに当たり前にできていることの安全性能の向上、信頼性のアップはアピールしてもインパクトがない。カタログを見ただけでは認知してもらえない。事故が他社より少ないことを強調するネガティブキャンペーンのCMは日本では受けが悪いから、消費者からのよい評判を意図的にSNSなどに流しながら安心、安全のブランドイメージを高めるようにしている。

しかし、それだけではライバルメーカーとの競争に勝てないため、自動車の安全性を新しい機能という目に見える形で表し、テレビコマーシャルで宣伝する作戦に出る。例えば、ナビゲーションシステムとブレーキの連動機能だ。

老舗の自動車会社Aは飛躍的に進化したVICSからの情報を使い、車一台一台の正確でリアルタイムな移動情報とナビゲーションシステムを融合させて、これまでにない安全機能を新たな売りとすることにした。前方に迫る十字路をナビゲーションシステムで認知し、左右から来る自動車の存在と速度を進化したVICSの情報から得て、直進する自分の車が横からくる車に追突されそうになったときには信号の赤青にかかわらずブレーキが自動的にかかる機能をナビゲーションシステムのサプライヤと共同開発した。この機能が正しく機能すれば十字路での衝突事故を避けられるようになる。

40代の会社経営者のBは1年前にこの新しい安全機能を搭載した車をA社の販売店から購入した。このオプション機能の搭載により購入価格は50万円もアップしたが、命には代えられない。Bは前の車に乗っていたとき、黄色信号が終わりかけの交差点に高速で進入し、横からきた車と接触事故を起こしそうになった経験がある。その後、家族と会社の部下から、自分一人の命ではないのだから本当に気をつけてくれと言われていたのだ。

この新しい機能があれば、左右がよく見えない信号のない交差点でも安心だ。交差点の手前で速度を落とさなくても、スッーと安全に通過できる。危ないときはこの車が自動的にブレーキをかけてくれるのだ。

その日Bは深夜、午前3時に県道を飛ばしていた。前日の夕方、翌日から始まる自社商品のイベントの準備でトラブルが発生し、急遽自ら陣頭指揮を執り問題の解決にあたらなければならなくなった。トラブルが解決し、イベントの準備がすべてが終わったのが午前2時半だった。眠いし早く家に帰って少しでも多く睡眠を取りたい。郊外の家に着くまであと5キロ。車の通りもほとんどなくなって、車は制限速度を30キロもオーバーしていた。「ああ、交差点の信号が黄色から赤に変わりかけている。」「でも、セーフティ機能があるからぶつかりそうになればブレーキがかかるし、ここはアクセル全開だ。」

その数秒後、交差点に入った瞬間にちょうど青信号になったばかりの左側の道路からきたCが運転する軽自動車に側面衝突した。Bの車のセーフティ機能は働かなかった。

この事故でBとCは大けがをした。もちろんBの信号無視が原因だった。その後自動車会社Aはなぜこの事故が発生したのか原因を突き止めるために、ECUとナビゲーションシステムに記録されていたデータログを徹底的に解析した。

原因は その日のその時間、VICSシステムがメインテナンスのため5時間ほど機能を停止しており、その情報にBが気がついていなかったからだということが分かった。実はナビゲーションシステムの取り扱い説明書にはこのことは注意として書かれており、実際VICSシステムの稼働中アイコンもそのときはナビの画面から消えていた。これまでBはVICSシステムの情報受信のアイコンなど気に留めたことなどなかった。

この件について、自動車会社Aがナビゲーションシステムの供給会社Dに厳しく問いただしたところ「何も間違った情報は送っていない。VICSが稼働中かどうかのステータスは正しく表示しているし、ブレーキシステムにも通信している。取り扱い説明書で表記上の対策もしている、できることはすべてやっているので我が社には過失はないと考えている。」という回答が返ってきた。

自動車会社Aのチーフエンジニアは頭を抱えた。これまでこんなことが起きたことはなかった。ブレーキシステムを担当するサプライヤはその機能と性能を隅々まで把握し、エンドユーザーに対して責任を感じながら完璧な仕事をしてきた。ところが、新しいセーフティ機能を次々に加えていった結果、自動車の安全機能がどんなときにも期待通りに働くのかどうか自信が持てなくなってきた。誰に聞いたら確信が持てるのか分からなくなってきた。それほど、システムは複雑化している。

昔の車作りのチームなら、VICSのサービスが提供されないことのリスクがどんなハザードにつながるのかチーフエンジニアの自分が気がつかなくても、誰かが気がついて対策を取っていた。それが今ではできなくなっている。リスクを分析して一つ一つのハザードに対するリスクコントロールの実装を確認していかないと、安全機能に関する確証が持てない。確実に自動車の作り方は変わってしまった。いや、変えないと安全な自動車を提供できなくなったのだ。事故が起こるたびに何十年もかけて築いてきた信用ががた落ちになる。10年前に導入した ISO 26262 は役に立たない形式的なものだと思っていたが、今初めて真剣に取り組まなければいけないと実感した。

2つのシナリオから考える自動車ソフトウェアの未来予想図

車には子供が乗っているかもしれない
上記の2つのシナリオはあながちありもしない空想ではないと考えている。TPP協定が締結されたら、日本にしかないガラパゴス的な非関税障壁は次々と訴えられる可能性がある。すぐさま国際標準に対応できるほど、日本はしっかりとした基盤を持っていない。言語の問題もあるが、国際標準を教えるよい教材、よいトレーナー、よいコンサルタントが不足しているし、それらに投資するという考え方も組織の中に醸成されていない。

また、欧米のやり方でこれまでの日本製品の品質が実現できるわけではないので、欧米の要求を日本向けにテーラリングしないといけないのに、日本人はそれが大の苦手ときている。

一番目のシナリオは電気自動車の普及にともない部品の組み合わせで自動車ができてしまうという話だった。ブラックボックスの部品の組み合わせで自動車が作られてしまうことで、システム全体としての安全が脅かされるという話は、共通プラットフォーム化、ECUの共通インタフェース化が進めば絶対に増加する。

中身が分からないブラックボックスのソフトウェア部品をハードウェア部品と同じ取り替え可能な部品として使い始めたら不具合は減らない。ISO 26262 への適合を目安にすることはできるが、ISO 26262 の要求に沿って作りましたという ECU ではリスクを回避できない。なぜなら、ISO 26262 はリスク分析の結果から考えたリスクコントロール手段をセーフティマネージャ(自動車メーカー)がサプライヤに要求し、安全を管理することでリスクを回避する。システム全体のリスクを分析しないで、お墨付きがあると差し出された ECU はそもそも想定されたリスクを受容できるまで低減できているという担保がない。どんな事故が起こる可能性があるかを分析しないで、オールマイティなセーフティ機能を実装することはできない。すべてのリスクに効果のあるリスクコントロール手段などない。危ない時に制御を止めなければいけないケースと動かし続けなければならないケースはどちらも存在する。だから、サプライヤだけではリスク分析はできないのだ。人や組織も含めた安全管理やシステム全体のリスク分析抜きに、ソフトウェアをハードウェアと同じように代替えできる部品と考えたら、その時点で安全は脅かされる。そのことにどれだけの自動車メーカーやサプライヤが気づいているかが心配だ。

二番目のシナリオは、安全機能を複雑化させたために起こるディスコミュニケーションの悪影響の結果だ。全体を見通せなくなった時点で古い日本の安全確保の方法論は力を失っていく。しかし、プロセスアプローチだけで安全が確保できるわけではないので、日本のプロジェクト向けの安全へのアプローチを規格をテーラリングしながら考えなければいけない。

このことは、CMMIのレベル5を取った、取らないといった話とは次元が全く違う。CMMI のレベル5を取った組織が、ソフトウェアの不具合を起こしたとしてもクライアントから嫌みを言われるだけだろう。CMMIは営業が仕事を取るための道具にはなっても、プロダクトアウトしたソフトウェアの信頼の証にはならない。

しかし、ISO 26262 への適合は安全や信頼の指標にならなければこの規格ができた意味がない。そうでなければ技術者が苦労して規格に適合するために積み重ねた努力が無駄になる。そして、規格適合が形骸化すれば上記のシナリオのように事故が起きたり人が死んだりするかもしれない。消費者から嫌みを言われて終わるレベルの話ではない。真剣に取り組まなければ人の命に関わる可能性があるのだ。

そういう気持ちを持ってエンジニアは規格適合に取り組んで欲しいと思っている。このことは自動車ドメインのエンジニアだけでなく、リスクを抱えた製品、クリティカルな製品に携わっているすべてのエンジニアに言いたい。2011年3月に日本で発生確率が極めて低いが、発生したときの被害の重大度が極めて大きい事故が起こった。リスクの大きさ = 発生確率 × 被害の重大度 という従来の安全工学の考え方を見直さなければいけないかもしれない。(ISO 26262ではハザードの評価において、発生確率と被害の重大度に加え、回避可能性の要素が考慮されている。)

被害の重大度が大きければ、ppmオーダーでもリスクは大きいと考えなければいけないのではないだろうか。また、発生確率が予測できないソフトウェアの不具合の場合、どうやってリスクを制御すればいいのかソフトウェアエンジニアが真剣に考えなければ、誰が安全な製品を作れるのだろうか。

あんな事故があっただけに、2012年、エンジニアはどうすれば事故の再発を防止できるのか、これから起こるかもしれない事故を未然に防ぐことができるのか、自分達の技術は事故の予防や再発防止のどのように役立つのかをよく考えて、安全という同じ目標、同じ価値観をもって日々の仕事に取り組む義務があると考えている。

ISO 26262-1:2011 Part1 Vocabulary(用語の定義)

ISO 26262-1 Part1 Vocabulary(用語の定義)
(「ISO 26262 用語の定義開くためのパスワードは"guild26262") 

ISO 26262-1 Part 1 Vocabulary では 142の用語の定義が記載されている。用語を正しく理解して規格を読み進むことは重要である。この142の用語の定義を邦訳したので参考にして欲しい。なお、この邦訳は突貫で作ったため間違いや用語同士での説明の不一致があるかもしれない。

そのような箇所を見つけられた方は是非連絡をして欲しい。多くの人のチェックを経て完成度を高めていきたいと思う。また、本資料を利用される方は 常にバージョンを確認して欲しい。間違いに気がついたら修正を加えてバージョンを上げていくつもりだからだ。

さて、142の用語を邦訳しながらあることに気がついた。それは、これらの用語はつぎの3種類に分類できるということだ。

【ISO 26262-1 で定義されている用語の分類】
  1. 安全・品質工学、規格適合に関する用語(43語)
  2. ソフトウェア工学に関する用語(30語)
  3. 自動車ドメインまたはISO26262特有の用語(69語)
邦訳の中では「安全・品質工学、規格適合に関する用語」は赤色に、「ソフトウェア工学に関する用語」は青色「自動車ドメインまたはISO26262特有の用語」は緑色に色分けしている。

分類は主観によるものなので異論もあるかと思うが、カウントしたら1が43語、2が30語、3が69語あった。これが示すことは何か読者の皆さんは分かるだろうか。

それは、ISO 26262 という規格は、安全工学・品質工学または国際規格への適合に関する知識を有する者、ソフトウェア工学の知識を有する者、自動車ドメインに造詣が深いまたはISO 26262 の規格策定に関わった者の3者が互いに協力しないと完全には理解できないということである。

ソフトウェア工学だけではダメだ
安全工学・品質工学の基礎があり、国際規格や規格適合の監査に慣れている者でも、ソフトウェア工学を深く知るものは少ない。また、ソフトウェア工学、特にプロセス改善の指導を得意とするものは、安全工学の知識を持っている者は少なく、規格適合の監査などの経験も少ないだろう。自動車ドメインの特殊な知識 ECU(電子制御ユニット)の仕組みも詳しくないと思う。一方、自動車ドメインの専門家でソフトウェア技術者の場合、安全工学は専門外だろうし、規格適合の監査は ISO 9001 くらいでしか受けたことがないだろう。(ISO 9001すら取得していない会社もあることだし)

よって、ISO 26262 に本気で取り組もうと思ったら、この3者が一つの目的、一つの目標に向かって協力しなければダメだ。それぞれの専門家が自分の強みを主張して、自分の専門分野に相手を引き込もうとしたり、相手が自分の専門領域のことを知らないことを「そんなことも知らないのか」と心の中で馬鹿にし出したりしたら、バラバラになって空中分解する。ついでに言うと、それまで知らなかったことを新しく知ったことで知ったかぶりをする者が出てきても調和は乱れる。

3者のディスコミュニケーションは相手が認知していない言葉を意識しないで使い始めたときから始まる。自分が知っている言葉を相手が知っているかどうか考えながらしゃべれる人は、主観と客観を自在に操れる人であり、世の中にそれほど多くは存在しない。ほとんどの人は自分が知っている言葉は相手も知っていると思って話をしてしまう。そして、日本人は奥ゆかしいから分からない言葉が出てきたところで、「その言葉の意味が分からないから教えて欲しい」となかなか言わない。

さて、コミュニケーションギャップの可能性を ISO 26262 の用語の例で考えて見よう。例えば、anomaly(異常)、 harm(危害)、 hazard(ハザード)、 severity(重大度)といって何のことだか、ソフトウェア工学や自動車ドメインの専門家はピンとくるだろうか。また、partitioning(パーティショニング)、baseline(ベースライン)、branch coverage(分岐カバレッジ)、 walk-through(ウォークスルー)について、規格適合コンサルタントはその意味を説明できるだろうか。また、ASILデコンンポジション、exposure(暴露)、redundancy(冗長性)について、正確に解説できる者はいるだろうか。

ちなみに、自分は最初の二群はキチンと説明できるが、最後の自動車ドメインや ISO 26262 特有の用語については自信がないところもある。

このように、分からない言葉が出てでて、そのままにしてしまうと人間は思考を停止してしまったり、自分の勝手な思い込みで解釈してしまったり、そもそも自分の専門分野でない、担当分野でないと考えることを放棄してしまったりする傾向がある。

そのような状況が現れ出すと、それは冒頭で紹介したシナリオ1やシナリオ2が始まったことを示す。ISO 26262-1 の用語集が示しているのは、この規格は3つの専門領域を合わせないと規格が目指している目標を達成できないということなのだ。セーフティマネージャが3つの領域を完全に理解することは難しいだろうが、それぞれの領域の担当は他の領域の知識を学習して、より多くのオーバーラップを持つことが求められる。そして、大事なのは安全という共通の目的、安全を確保するというエンドユーザにとっての価値を共通認識とすることだ。

自動車ドメインの場合は、上記の3つの専門領域の区分けとは別に、自動車メーカーとサプライヤという立場があるため、問題はより複雑であり、共通の目的、共通の価値観を持って規格への適合を達成するのはさらに困難を極めると予想される。

自分が考えるうまくいくシナリオは、はやり自動車メーカーにしてもサプライヤにしても、自動車ドメインの技術者が安全工学、品質工学、ソフトウェア工学について学習を重ね、それぞれの専門家からアドバイスをもらいながらも自分達が主導権を取って規格適合を進めていくという流れだ。なぜなら、規格適合を監査する者やプロセスコンサルタントは、なんだかんだ言っても自分達の仕事がエンドユーザーの命に関わっているとは考えていないだろうし、エンドユーザーの命に対してなんら責任もないからだ。しかし、自動車メーカーのエンジニアと、安全に関わるソフトウェア、ハードウェアを納品するサプライヤは違う。自分達には安全に関わる機能・性能に対して責任があると認識して仕事をしているだろう。何か事故が起これば他人からも責められるし、自分自身も責めてしまうのが日本のメーカーとサプライヤのエンジニアだ。その責任の範疇の中にいるのか外にいるのかの差はとてつもなく大きい。中にいる者は人の命を背負っているが、外にいる者はそこまでの責任は感じていない。

別な言い方をすると、そのような責任感が品質の向上に寄与するようなやり方を脱するために作られたのが ISO 26262 なのだが、現実には品質を心配する意識とプロセスアプローチの両方がないと安全は確保出来ないというのが自分の考えだ。ISO 26262 の形骸化が始まったら、安全の確保は危うくなると思っている。

規格適合は役に立たないと考えずに、たましいを入れて取り組くむには、ひとつ見方を変えればよい。ISO 26262 の適合という機会は、自分自身の幅を広げるまたとないチャンスだと考えればよいのだ。自分がブログサイトでこの特集記事を書いているのは、読んでくれる読者がいるからだけれども、それにもまして記事を書くことが自分自身の知識の幅を広げることにつながり、結果的には自分のドメインでも役に立つし、それまで気がついていなかったことがたくさんでてくることが分かっているからだ。

実際、ISO 26262 の用語の定義を邦訳して、医療機器ドメインでの解釈とかなり違うところがあることがわかった。例えば、ISO 26262-1 には validation や software validation に関することばの定義がない。 safety validation :セーフティゴールが満足され、達成されたことを試験やテストに基づいて保証すること、という簡単な説明しかない。なぜか。おそらく、自動車ドメインではユーザーインタフェースや、ユーザーのオペレーションに起因する不具合や事故がまだ、それほど多くないのだろう。それらが多くなって、ユーザビリティに対する対策の必要性が高まってくると、validation(妥当性確認)の解説はもっと長くなってくると思われる。(いずれくわしく説明をしたいと思う。)

逆に医療機器ドメインでは ASILデコンポジッションのような考え方がまだ確立していない。ハードウェアにしろ、ソフトウェアにしろ安全を確保するためのアーキテクチャに関する研究が進んでいない。

技術者は技術で安全に貢献できることがある
このように専門分野やドメインを超えて知識を深めていくと、今まで気がつかなかったことに気がつき、新しいアイディアが生まれる。そのアイディアが機器の安全につながるのであれば、自分や自分達が作る製品、商品の価値を高めることに貢献する。

そう考えれば、新しい分野を勉強する時間は自分をより高めることに有益であり、決して無駄ではないことが分かる。

2012年の新年を迎えて、まだまだ勉強すべきことは山ほどあると再認識したところである。