要求分析と安全設計との関係（機能安全の致命的な欠陥）

日本の組込み系のソフトウェアエンジニアに担当製品に対するユーザー要求は何かを聞くとすぐさま答えられないことが多い。

顧客の要求に基づき日々ソフトウェアを開発しているIT系のソフトウェア技術者には驚きかもしれないが、事実そうなのだ。

なぜ、組込み系のソフトウェアエンジニアは自分の製品のユーザー要求を答えられないのか。それは、過去の製品のソフトウェアを追加、修正しながら新しい製品を作っているから、大元のユーザー要求を把握していなくとも、製品開発が出来てしまうからだ。

継承するソフトウェアの中に基本機能、基本性能がすでに入っているから、付加機能を付け足すぶんには元の要求を知らなくても作業はできるのだ。

さながら、老舗旅館の旧館、新館、別館、アネックスといったようなもので、結果、継ぎ足しで成り立っている迷路のような構造になることもしばしばだ。

継ぎ足し、修正ばかりやっているソフト技術者はユーザー要求は即答できなくても、機能については詳しいし、饒舌に説明できる。

さて、この機能仕様ドリブンのソフトウェア設計は、安全を考慮しなければいけない機器にとっては、致命傷になる危険がある。

なぜか。ひとつはソフトウェアシステムが複雑化していった際に、機能同士が背反する関係になる可能性があるからだ。よかれと思って付けた付加的な機能が、基本機能に悪い影響を与えることがある。

医療機器の世界では、リスクコントロール手段を設計する際には、リスクコントロール手段によって生まれる新たばリスクを分析せよという規格要求がある。

例えば、異常を検出するハード・ソフトを追加して、異常検知したら装置を停止するようにしたとする。異常は滅多に起こらないから問題ないと考えて、十分な負荷試験をせずにリリースする。確率は低いものの、異常の誤検知が起こり正常なのにシステムが止まることがあったとすると、ユーザーからの大クレームになる。リスクコントロール手段を追加すると、何かしら別のリスクが生まれるのだ。

多くの自動車の部品屋さんは、自分の部品に故障検出回路を付けることが機能安全に貢献し、ASIL-D を満たせるのだと言っているようだが、それって本当に木を見て森を見ずだと感じる。故障検出回路という山火事検知装置に対処するソフトウェアを大量に追加することによって、森の複雑度はどんどん上がっていき、本当に火事が起こったときに消防隊が現場に行くための経路が分かりにくくなる、これが機能安全の致命的な欠陥だ。（何の危害を防止するためのリスコントロール手段か分かっていないで安全に貢献するはずだと思い込んで機能を追加しようとするとこうなる）

「これからは故障検出を追加してシステムを冗長にし、動作し続けることが重要だ」といった意見を聞くことがある。冗長設計は安全設計の方法のうちのフォールトトレランスに分類される。安全を実現するための方法の一つだが、欠点はシステムを複雑にする点だ。システムが複雑になると、レアなテストケースが出てきて、滅多に起こらないシーケンスで不具合が作り込まれる危険性が生まれる。ハードウェアならば安い部品を冗長化するよりも高信頼性部品を使って、シンプルな構造にする方を選ぶこともあるだろう。ソフトウェアならば、シンプルなアーキテクチャにして、テストしやすくするという選択肢もある。冗長化すればいいというもんではない。何を防ぎたいのかを頭に置いた上で、ハード・ソフト含めどんな安全設計が最適かを選ばないといけない。フォールトトレランスだけが解決策だと思っていると、システムの複雑化からくるリコールのリスクを負うことになる。

こういったシステムの複雑化に伴う問題を最小限に抑えるためには、システムに対するユーザー要求をしっかりと優先順位を付けて分析しておく必要がある。重要な要求とあってもなくてもよい付加的な要求は分けて認識しておかないといけない。そして安全に関する要求など、重要な要求は常に優先度の高い要求として認識しておく。要求の優先度を十分に理解した上で、アーキテクチャ設計を行い、安全アーキテクチャは機能を付加しても崩さないようにしないといけない。

複雑化の影響を自動車で言えば、プリクラッシュセーフティをエンジニアが基本機能に対する付加機能だと考えていると危ないなあと思う。

「障害物を認識したら、自動でブレーキを働かせるという機能を基本機能に付け加えて実装すればよい」と考えるのは危ないと思うのだ。

ユーザーが自動車に求めていることは何か。移動や物の運搬が真の目的なら、どこでもドアが発明されたら、自動車は必要なくなる。（論理が飛躍していると思ったらこちら「洗濯機メーカーは洗濯機を開発してはいけない」を参照のこと）

移動する（安全に移動する）ということはどういったことか。移動したいというユーザー要求はある。ただ、その裏側には安全に移動したいという潜在的な要求がある。移動する時に10回に1回怪我をするようなことはゴメンだと誰もが思うだろう。

安全に移動するという要求を実現する手段に自動車があると考えておくと、システムが複雑化して難しい判断に迫られたときに、答えが見えてくる。

さて、どこでもドアはまだ発明されないとして、移動、運搬をする際に、自分や他人や他の車、設備に損害を与えたくないと誰もが考える。特に、自分自身や他人を傷付けたくない。自動車は運動エネルギーを持って動くのでリスクの潜在的な源（ハザード）を持つ。

プリクラッシュセーフティ機能が稼働するシーンはさまざまある。自動ブレーキを働かせたことで、後続車両から追突されたら、結果的に搭乗者の安全は確保されないかもしれない。（「ISO 26262との向き合い方 (11) ASILの分解は本当に可能か」を参照のこと）

このケースでは「プリクラッシュセーフティ」という機能を実装することを目的にしてはいけない。安全に移動するという要求を満たすために何をすればよいのか、今の技術で何ができるのかを考える。機能より要求は上位にあり、要求はよっぽどのことがないと変わらないが、時代とともに技術は変わっていくので、要求を満たす技術はその時々で変化していく。技術やユーザーの意識の変化によって要求を満たせるレベルも変わっていく。

機能だけに着目していると、その上位にある要求が満たせていなかったり、要求のレベルが変わっていることに気が付かない。

また、機能を追加すればよいと考えていると、安全に対する優先順位が分からなくなってしまう。「機能」のことだけ考えていると、そのシステムに求められる本質的な要求が飛んでしまい、本質的な要求に背反するようなシステムを作り込みかねない。

障害物を発見したらブレーキを作動させるという機能を追加しようとすると、搭乗者の安全を確保するという要求が飛んでしまう。（通常は安全に寄与するが、別な条件では安全を脅かすというケースで、大抵は確率が低いから、事故が起きてから分かる。）

だから、ユーザー要求に基づいたバリデーションが大事なのだ。分業が進んでいる欧米のソフトウェア開発では、バリデーション、バリデーションとこればっかり言われることがある。少人数で人の入れ替わりがほどんどない日本の伝統的な組込みソフトウェア開発では、プロジェクトメンバーみんなが言われなくてもユーザー要求は常に頭の中にあるので、何を確認すれば妥当性を確認できるのか分かっていた。

問題が起こる確率は低いから、漏れなく妥当性を確認することに超したことはないが、必ず漏れはあるので、最も起きてはいけない問題から順にそれらが起きないことを確認していく。そうすれば、問題が起きても大問題ではなく、小問題に押さえ込むことができる。ゼロにしようと思うと穴が生まれる。

私は私、あなたはあなた、私が作った物の責任は私が取るが、あなたが作ったものは知らないというシステムでは、ユーザー要求に基づいた、妥当性確認を行わないと、要求と背反するような物になっている危険性がある。

大規模化したソフトウェアシステムにおいて、日本の多くの組込みソフトがトップダウンで十分な要求分析を経て開発されていないとすると、その危険性が増大する。

じゃあ、どうすれば良いかと言えば、今ある機能や性能を整理しながら、ボトムアップで要求がなんであったかを分析し、概ね要求が洗い出せたら、今度はトップダウンで機能を見直してみる。

こうすれば、アーキテクチャのリファクタリングもできる。

安全に関係しないところであれば、複雑になろうが結合が強かろうがいいだろう。しかし、安全に関わるアーキテクチャは要求がキチンと分析されていないと、機能追加で崩される危険がある。

崩そうと思って崩すのではないからたちが悪い。自動ブレーキの命令をソフトウェアが出せるようになったことで、ネットワーク越しでの自動ブレーキが可能になり、ハッカーにつけ込まれるかもしれない。

ナビの情報と自動ブレーキを組み合わせれば、便利な機能を付加できるかもしれない。しかし、そのお陰で自動車の基本機能や基本性能に悪い影響を与えるかどうかを考えないといけない。

その判断をするためには、システムに対する要求を正確に分析し、要求分析内容が常に確認されている（バリデーションされている）状態にしておかないといけない。

機能を追加してリリースすることがソフトウェア開発だと思っていると、システムが複雑化する中で安全を確保することはできない。

USのヘルスITの取り組み(10) インターオペラビリティ（相互運用性）

5.2 Identify, Develop and Adopt Standards and Best Practices
5.2 識別と開発、標準の採用とベストプラクティス

 The identification, development, and adoption of standards and best practices are a key aspect of a health IT framework that promotes innovation and protects patient safety.
 識別と開発、標準の採用とベストプラクティスは革新を促進し、患者安全を保護するヘルスITフレームワークのキーとなる側面です。

Consensus standards, developed through a collaborative, evidence-based, fair, open, and impartial process, provide requirements, specifications, guidelines or characteristics that can be used consistently to ensure that products, processes and services are fit for their purpose.

協力的で、証拠に基づいた、公正で、オープンで、公平な過程で開発された合意基準は製品、プロセス、およびサービスがそれらの目的に適しているのを保証するのに一貫して使用できる要件、仕様、ガイドラインまたは特性を提供します。

Best practices are processes or methods that have been demonstrated to deliver consistently superior results.
ベストプラクティスは、一貫して優れた結果を提供するために示されたプロセスまたは方法論です。

Like standards, best practices can be used to promote and maintain consistency and quality.
規格のように、ベストプラクティスは一貫性と品質を促進して、維持するの使うことができます。

Importantly, both standards and best practices allow health IT developers to vary their product design, function, features and development approach, and organizations to tailor their methods and processes to their needs.

重要なのは、規格とベストプラクティスの両方がヘルスIT開発者に彼らの方法とプロセスを彼らのニーズに適合させるように、プロダクトデザイン、機能、特徴、開発方法、および組織を変えることを許すということです。

Standards and best practices can set the minimum expectations necessary to achieve an acceptable level of performance and can serve as a guide for achieving performance excellence.

規格とベストプラクティスは（組織の）能力のレベルの受け入れを達成する必要な最小の期待をもたらすことができ、（組織の）能力の優れているところを達成するためのガイドとして役立ちます。

Many existing domestic and international consensus standards address key aspects of product quality, performance and safety, are relevant to health IT, and have been developed with the participation of FDA, ONC, FCC, AHRQ, other government agencies, and key health IT stakeholders.

多くの既存の国内的、そして、国際的な合意基準は、製品品質、性能、および安全といった重要側面に立脚しており、ヘルスITに関連していて、FDA、ONC、FCC、AHRQ、他の政府機関、および主要なヘルスITステークホルダが参加して開発しています。

A number of additional existing standards may be applicable to health IT including but not limited to those pertaining to quality management systems, risk management, interoperability, and software development, validation and lifecycle management.

いくつかの既存の標準は、品質管理システム、リスクマネジメント、インターオペラビリティとソフトウェア開発、バリデーションとライフサイクル管理に関係しているそれらを含むがこれに限らずヘルスITに適用できる場合があります。

ONC has responsibility for advancing the development, adoption, and implementation of health IT standards nationally through public and private collaboration.

ONCは公共のまた個別の協業を通して、全国においてヘルスIT標準の採用と実現を進めることに対する責任があります。

The HITECH Act established the Health IT Standards Committee, which serves as a forum for the participation of a broad range of stakeholders to provide input on the development, harmonization, and recognition of standards, implementation specifications, and certification criteria necessary for the development and adoption of a nationwide health IT infrastructure that allows for the electronic use and exchange of health information.

HITEC法は、ヘルスIT標準委員会を設立しました。そして、委員会は健康情報の電子使用と交換を考慮に入れる全国的健康IT基盤の開発と採用のために標準、実施仕様と必要な証明基準の開発、調和化と認知に関して入力を提供するステークホルダの幅広い範囲の参加のためのフォーラムとして用いられます。

5.2.1 Interoperability
5.2.1 相互運用性（インターオペラビリティ）

Interoperability supports improvements in safety, encourages innovation and facilitates new models of health care delivery by making the right data available to the right people at the right time across products and organizations in a way that can be relied upon and used by recipients.


相互運用性（インターオペラビリティ）は安全の実現を支えて、革新を促して、利用者が使い信頼できる方法で、製品や組織を超えて、適切な時刻情報で適切な人々に対して適切なデータを作ることによって、新しいヘルスケアを提供するモデルを促進します。

Interoperability permits electronic communication between software applications and across medical devices and electronic health records thereby supporting innovation that can only occur when the data is not “siloed” in one product, technology or system.

インターオペラビリティは、データが製品や技術やシステムに貯蔵されないということに対する革新を助けて、ソフトウェアアプリケーションと医療機器や電子健康記録を横断して電子的なコミュニケーションを可能にします。

In addition, it promotes system integration even when products from different vendors are used, and can improve data portability and patient safety.
これに加えて、異なるベンダーの製品が使われるときでも、システム・インテグレーションを促進して、データ携帯性と患者安全を改善することができます。

Errors in communication due to inadequate interoperability, such as the transmission of test results inaccurately or for the wrong patient, do occur and can lead to patient harm.

不十分なインターオペラビリティ（例えば不正確に、または、患者間違いの検査結果の伝送）のためのコミュニケーションにおけるエラーは、発生して、患者の有害事象につながる可能性があります。

Improved interoperability among health management health IT systems, medical devices and administrative systems could catalyze innovation in the health IT marketplace, better support emerging care models, and create greater marketplace competition and responsiveness to end-user needs.


健康管理健康ITシステム、医療装置と行政システムの間の改良されたインターオペラビリティは、ヘルスT市場で革新の触媒となることができて、よりよい新しいケアモデルをサポートし、より大きな市場競争とエンドユーザーニーズの反応を作り出すことができます。。

The Agencies have actively fostered the secure and seamless exchange of health information, but challenges remain.
関係政府機関は健康情報の安全でシームレスな交換を精力的に促進しましたが、まだ課題は残っています。

This risk-based health IT framework should promote interoperability and electronic information sharing between health IT products and across organizational boundaries.
このリスクベースのヘルスITフレームワークは組織境界を超えてヘルスIT製品との間で、共有される相互運用性と電子情報を促進するべきです。

The FDASIA Workgroup recommended that interoperability of health IT could be addressed, in part, through adoption of standards.
FDASIAワーキンググループは 標準の採用を通して、部分的に、ヘルスITのインターオペラビリティを推奨しました。

Standards-based interoperability could facilitate new and innovative health IT products and solutions tailored to address users’needs.
標準に基づいたインターオペラビリティは新しく革新的なヘルスIT製品とユーザーニーズに根ざして適合させたソリューションを提供することができます。

Fostering the development of interoperable products and systems, in part, requires the creation, validation, and recognition of common standards across product categories.
相互運用できる製品やシステムの開発の発展は、新たな創造、バリデーション及び製品カテゴリを横断した共通基準の認識を一部必要とします。

ONC has broad responsibility for adopting standards, implementation specifications, and certification criteria for health IT in conjunction with its voluntary certification program, as well as leading policy efforts to effectively encourage and coordinate nationwide health information exchange activities.
OCNには、全国的なヘルスインフォメーソンの情報交換活動を効果的にコーディネイトし、奨励するための政策活動と同様に、標準の採用、仕様の実装、自己認証プログラムに関連したヘルスITの適合の判定に対する広い責任があります。

ONC adopts standards for health IT through regulations and leverages public-private collaboration to identify and specify standards and implementation specifications that could be used through the Standards & Interoperability Framework activity.

ONCは、規制を通してヘルスITのための基準を受け入れ、標準化や相互運用フレームワーク活動を通して使うことのできる仕様の実装や、標準や実装仕様の特定のために公共と私企業のコラボレーションを促進します。

In 2012, FDA and the Association for the Advancement of Medical Instrumentation (AAMI) organized a summit that brought together hundreds of experts from many disciplines to further the goal of improving patient care and fostering innovation through interoperability.

2012年にFDAと医療器具開発協会(AAMI)は、インターオペラビリティを通した革新の促進と患者ケアの改良を目標として、多くの領域から何百人もの専門家を集め、サミットを開催しました。

FDA has since recognized a set of voluntary standards pertaining to interoperability and cybersecurity that will help medical device manufacturers create secure devices that work well together and with other health IT products and systems.

FDAは、以後、医療機器製造業者が他のヘルスIT製品やシステムとともに上手く働くセキュアなデバイスを作成するのを助ける、インターオペラビリティとサイバーセキュリティに関係する１セットの自主基準を推奨しました。

In February 2014, ONC co-hosted Health Care Innovation DC:
2014年2月に、ONCはHealth Care Innovation DCを共同開催しました:

Igniting an Interoperable Healthcare System, a conference to provide a venue for stakeholders to collaborate and partner on solutions to achieve interoperability in ways that improve patient care.

相互運用ヘルスケアシステム、患者ケアを発展させる方法において相互運用を達成するソリューション上の協業や提携のためのステークホルダの場を提供するカンファレンスでした。

The Agencies recommend that entities be identified to develop tests to validate interoperability, test product conformance with standards, and transparently share results of product performance to promote broader adoption of interoperable solutions.

関係政府機関は、相互運用の妥当性を確認するテストを開発し、規格に適合する検証プロダクツや、相互運用のソリューションを受け入れ基準を満たす製品性能結果の透明性高く共有することを推奨します。

Conformance with recognized consensus standards can be used to meet certain regulatory requirements.
認知された合意標準への適合は、規格要求を満たすことで表すことができます。

The concept of conformity assessments is discussed in more detail in Section 5.3.
さらに詳細にセクション5.3で適合性評価の概念について議論します。