2018-04-13

ウーバーの自動運転事故について考える

2018年3月18日に米ライドシェアサービス大手のウーバー・テクノロジーズの自動運転車が、米アリゾナ州フェニックス近郊で試験運転中に起こした死亡事故のことは多くの人がすでにニュースで見たと思う。

ただ,なぜ,この事故が起こったのかという原因については,まだ十分な分析の結果が報道されていないようだ。

ただ,その中でも,Engajet の『自動運転Uberの死亡事故はLiDARの削減が原因か。高い車高も死角拡大の可能性』の記事は参考になった。

【『自動運転Uberの死亡事故はLiDARの削減が原因か。高い車高も死角拡大の可能性』より引用】

Uberの自動運転車が歩行者を検知できなかった原因について、ReuterはUberの自動運転車が搭載するLiDARの死角について報告しています。
2016年、Uberは自動運転のベース車両をセダン車のフォード・フュージョンからSUVのボルボXC90へと変更しました。このときLiDAR 7基、レーダー 7基、カメラ 20台で構成される自動運転システム用のセンサー群もLiDAR 1基、レーダー 7基、カメラ 7台へと大幅に変更されました。

自動運転車は、LiDARが発するレーザーパルスの反射、さらにレーダー、カメラによる視覚的(可視光)によって路上にある障害物を検知し、衝突を避けます。しかし、新しいUberの自動運転車は、以前のモデルが7つ搭載していたLiDARをルーフ上に1つしか搭載していません。

カーネギー・メロン大学交通センターで自動運転技術を10年以上にわたって研究してきたRaj Rajkumar氏は、現在のUberの自動運転車は、センサーの視野的に歩行者を完全に捉えられなくなっていると指摘します。

Uberの自動運転車が搭載するVelodyne製のLiDARセンサーは、その外観から1台でも360度周囲を完全に監視できるように見えます。ところが、VelodyneによるとLiDARは垂直方向の検出範囲が狭く、SUVのように車高の高いクルマのルーフ上ひとつだけでは車両周囲に約3mの死角ができてしまうとのこと。特に地面に近い高さ、たとえば歩行者の足元や自転車の車輪、小動物などの検出が難しくなります。

【引用終わり】

事故は夜起きたので,人と自転車が暗闇にいたときにはカメラでは関知することはできず,LiDAR と レーダー が障害物検知の頼りだったと思われる。ただし,Uber が自動運転のベース車両をセダンのフォード・フュージョンからSUVのボルボXC90 に変更した際に,LiDAR(英語:Light Detection and Ranging、Laser Imaging Detection and Ranging、「光検出と測距」ないし「レーザー画像検出と測距」)は7基から1基に削減されている。また,SUVの車高の高い車ではLiDARに死角があったのかもしれない。

今回のUberの自動運転車の事故の原因はソフトウェアではないかもしれないが,クリティカルなシステムに使用されているソフトウェアの安全は,このようなインシデントやアクシデントの再発を防止するスキームの中で成熟させていくべきものではないかと思う。

そう考えるときに,いつも引っ掛かるのが機能安全(きのうあんぜん、英: functional safety)ということば(概念)だ。

Wikipedia から引用すると機能安全の説明は次のようになる。

Wikipedia 機能安全 から引用】

機能安全(きのうあんぜん、英: functional safety)は「監視装置や防護装置などの付加機能によるリスク低減策」であり、安全方策(安全を確保する為の考え方)の1つである。人間、財産、環境などに危害を及ぼすリスクを、機能や装置の働きにより、許容可能なまでに低減する一つのやり方である。JIS C 0508(IEC 61508)は「被制御機器(EUC)及び被制御機器制御系の全体に関する安全のうち、電気・電子・プログラマブル電子安全関連系及び他のリスク軽減措置の正常な機能に依存する部分」と定義している。自動車の機能安全規格ISO 26262は、機能安全の対象を「電気電子(E/E)システムの機能不全のふるまい」 に限定している。→#自動車の機能安全

電気・電子・プログラマブル電子(Electrical・Electronic・Programmable Electronic)は、E/E/PE(またはE/E/PES)という略号を使用している。

機能安全は、本質安全という考え方と対比して説明される事ある。例えば踏切では、列車と道路を通行する車輌等との事故の危険がある。これを踏切に警報機や遮断機を設置して事故を防ぐのが機能安全である。これに対して,立体交差を設置することより危険を回避することが本質安全と言える。※1

安全を確保する為に交差しないというのが本質安全に基づいた考え方である。立体交差にするというのは、事故の原因が少なくなるので、機能安全の考え方を適用したものと言える。立体交差で鉄道が上か自動車道が上かで、物の落下や柵のつけ方によって事故の被害の大きさが変動することからも立体交差が本質安全ではないことが分かる。踏切に警報機や遮断機を設置するというのも、事故の可能性は無くなりはしないが、これらの機能や装置の働きにより、許容可能なまでに危険を低減できるので、機能安全の考え方を適用したものと言える。

※1 取り消し線部分は Wikipedia からの引用そのものであるが,解釈が誤っているという指摘があったので本ブログでは青字に修正した。

【引用終わり】

一方で,ISO/IEC Guide 51:1999(Safety aspects — Guidelines for their inclusion in
standards, 安全側面ーー規格への導入指針JIS Z8051)では,セーフティ(安全)を次のように説明している。
 セーフティ(安全)とは,〔ISO/IEC GUIDE 51:1999〕※1 によれば,『受容できないリスクがないこと』と定義される。すなわち,セーフティ(安全)は受け入れ不可能なリスクから解放されていることであり「受容できないリスクがない」または「許容可能リスク」が達成されていることをもって「安全」と規定される。
 安全はリスクを経由して定義され,リスクはその時代,社会の情勢,環境によっても変化するため安全の尺度を一定にすることはできず,絶対的な安全を定義することはできない。そのため,製品,プロセスまたはサービスは相対的に安全であるとしか言えない。
安全は,リスクを許容可能なレベルまで低減させることで達成される。許容可能なリスクは,使用者の利便性,目的適合性,費用対効果,並びに関連社会の慣習のように諸要因とのバランスで決定される。したがって,許容可能なリスクは常に見直す必要がある。技術及び知識の両面の開発が進み,製品,プロセスまたはサービスの使用と両立して,最小リスクを達成できるような改善が経済的に実現可能になったときは,特に見直しが必要である。
※この説明文は ISO/IEC Guide 51の2014年の改訂でなくなってしまったのだが,安全(セーフティ)を説明するための文章として優れていると思い,今でも引用している。

この説明を分かりやすく4つにまとめると次のようになる。

セーフティ(安全)とは
  1. セーフティ(安全)とは「受容できないリスクがないこと」である。
  2. 絶対的な安全を定義することはできない。安全は相対的な概念である。
  3. リスクが許容可能かどうかは「使用者の利便性」「目的適合性」「費用対効果」など諸要因のバランスで決定される。
  4. 世の中の技術開発が進んだら、リスクの許容可能性の見直しが必要である。
安全は相対的な概念であり,リスクが許容可能かどうかは諸要因のバランスで決定される。この部分が非常に重要だ。

Uber の自動運転システムの事故の場合,LiDAR 7基、レーダー 7基、カメラ 20台 の自動運転車を LiDAR 1基、レーダー 7基、カメラ 7台 の自動運転車に変更したことで,リスクの要因が変わったのかもしれない。この変更が経済的な要因を優先させたのだとすれば,それがトリガーとなって事故が起こったのかもしれない。

セーフティ(安全)は,意図する使用(Intended Use)を定義し,その使用環境から想定されるリスクを分析し,リスクを低減するための対策を立案し,検証し,妥当性を確認する

しかし,安全は相対的で諸要因のバランスで成り立っているので,システムの変更は相対的な安全を崩してしまう危険性がある。ソフトウェアの場合であれば,ソフトウェアのちょっとした変更が安全を実現しているリスクコントロール手段に影響を与え,安全アーキテクチャを崩してしまうかもしれない。

ソフトウェアのよる安全監視や安全装置が意図した動きをしないかどうかの確認は,異常状態を作り出さないと分からないこともあるだろう。だから,クリティカルシステムに対してアジャイルなソフトウェア開発,ソフトウェア変更を行う際には,安全アーキテクチャが崩れていないことを常に確認する必要がある。

さて,仮にUber の自動運転システムの事故がLiDAR を7基から1基に減らしたことにより,死角ができたのだとしたら,どのようにすれば事故は防げるだろうか。

それは,日中,夜間の環境条件で,障害物を感知する範囲を特定し,自動車の上限スピードで障害物を感知してから,障害物との衝突を回避するまでの時間を割り出し,それを実現するためのハード,ソフトの要件を定義する。障害物が止まっているとは限らないので,さまざまな条件を考慮しないといけない。

このように「障害物を検知し,自動で衝突を回避する」という要求に対して,ハード,ソフトの条件を出し,設計仕様に落とし,検証とバリデーションを行い,それらがトレースできているかどうか確認する,これを要求ごとに行っていく。

インシデントやアクシデントが発生した場合は,この流れのどこに問題があったのかを分析し,それをフィードバックする。これを積み重ねていくことで,相対的な安全を確保していく。

このようなシステム全体のリスクマネジメントのアプローチにより,システムに責任を持つ者がリスク低減のために必要な要件を定めて,リスクがコントロールされていることを確認し続けていれば,ハードウェアやソフトウェアの変更により,知らぬ間にリスクが許容できなくなっていること(ソフトウェアの場合ならデグレード)が起こっていないことを保証することができる。

しかし,機能安全(きのうあんぜん、英: functional safety)が「監視装置や防護装置などの付加機能によるリスク低減策」であり、安全方策(安全を確保する為の考え方)の1つであり,機能安全が個々のユニットの安全機能を積み重ねるボトムアップアプローチであるのなら,個々の部品単位で安全機能を搭載したものをアセンブリしたときに,システム全体が安全かどうかは分わかるだろうか。

なぜそう考えるかというと,ユニットの安全機能は,システム全体の安全から来た要求とは限らないと思うからだ。自動車部品の安全機能として,異常監視や冗長性の機能をよく見受けるが,それらの安全機能は例えば,障害物を検知して自動ブレーキをかけるという要求に対する直接的なリスクコントロール手段になっていない。別な言い方とすると,インシデントの再発防止のための取り組みではないということだ。意図する使用(Intended Use)から展開されていない安全機能は,どんなリスクにも効果があると考えて設計されていると思うが,そんな魔法の杖は存在しないし,ハードウェアやソフトウェアを組み合わせて作った複雑なシステムにおいては,特に有効でないケースも出てくる。

自動車の安全について,自動車メーカーがリスクを分析し,その観点から,サプライヤーに要求を突きつけるのは分かる。しかし,サプライヤーが機能安全への適合を自動車会社に上申して,その自動車が安全であると主張するのは,どうしても納得がいかない。

Uber の自動運転の事故は,ハードウェアとソフトウェアを組合せたシステムとしての事故として,原因分析する必要があるのではないか。

個々の部品の不良が原因となるというシチュエーションは1960年代のゼロディフェクトの考え方であり,個々の部品の信頼性を高めてシステムの安全を担保するという考え方は,21世紀の大規模複雑化したシステムでは成り立たない。

システムの複雑化による複合要因での事故は非常に多くなった。従って今回のような事故の再発防止は,システムを統合してユーザーに提供する自動車会社が旗を振って,根本原因を調査し,再発防止策を継承していく必要がある。

事故が起こるたびに,犯人捜しをしてサプライヤーの責任を追及しても,事故の再発防止にはつながらない。現代の事故は,そういった部品単位で起こるのではなく,複合要因で発生することの方が多いからだ。

複合要因で発生する事故に対しては,システムとしてトップダウンアプローチで,リスクコントロールを行う必要がある。その時の旗振りは 顧客に対してシステムの安全を保証する者でなければならない。それは,自動車の場合サプライヤーではなく,自動車メーカーだと思うのだ。

「安全を機能(ファンクション)で確保できると考えていると,複合要因の事故はなくならないぞ」と言いたい。

2018-03-18

2020年の医療機器ソフトウェアに求められる要件の予想

前回のブログ記事『ソフトウェア製品の認証は可能か?』で,医療機器では「基礎安全,基本機能,基本性能」「リスクマネジメント」「ソフトウェアライフサイクル」「ユーザビリティ」の4つについて正当性を示すことが規制当局から求められると書いた。

適合が求められる規格でこのことを表すとこの図のようになる。

専用のハードウェアにソフトウェアを搭載する医療機器の場合は,製品安全規格として IEC 60601-1 と,ソフトウェアライフサイクルプロセス規格として IEC 62304 が求められる。汎用のITプラットフォーム上で動作する医療機器ソフトウェアの場合は,製品安全規格として,IEC 82304-1と ソフトウェアライフサイクルプロセス規格 の IEC 62304 が求められる。(IEC 82304-1 は規制要件になるかどうかはまだ決まっていない)

IEC 82304-1 は 2018年3月1日に JIS T 82304-1 として日本語で参照できるようになった。この規格の目次は次のようになっている。

JIS T 82304-1 目次

  1. 目的及び適用範囲
  2. 引用規格
  3. 用語及び定義
  4. ヘルスソフトウェア製品の要求事項
  5. ヘルスソフトウェア-ソフトウェアライフサイクルプロセス
  6. ヘルスソフトウェア製品のバリデーション
  7. ヘルスソフトウェア製品の識別情報と附属文書
  8. ヘルスソフトウェア製品の市販後活動

箇条5 は IEC 62304 を参照しているので,IEC 82304-1 がソフトウェアライフサイクルプロセスの要求として IEC 62304 を呼んでいる形になっている。

ようするに,ライフサイクルプロセスの要求に加えて,製品の要求事項を明確にした上で,バリデーションの計画,実施,報告を行い,製品の識別情報や附属文書への記載内容を指定し,さらに,市販後の活動も行うことでヘルスソフトウェア製品の安全を実現しようとしている。

なお,IEC 82304-1 は規制対象と規制対象外の両方のヘルスソフトウェアを対象としているのに対し,現在の IEC 62304 Ed.1.1は規制対象の医療機器ソフトウェアのみがスコープとなっている。そこで,IEC 62304 は Ed.2 において,IEC 82304-1 と同様に,規制対象と規制対象外のヘルスソフトウェアにスコープを拡大しようとしている。

どちらの規格も製品安全やリスク低減を目的としているのだが,今や規制対象のヘルスソフトウェアだけでなく,規制に至らないヘルスソフトウェアに対しても必要な要件があるという考え方だ。

IEC 62304 Ed.2 は現在検討中であり,2000年までには策定されると予想される。そこで,2020年時点でのヘルスソフトウェアの規格体系を予想してみると次のようになる。

IEC 82304-1 は ヘルスソフトウェアのソフトウェアライフサイクルプロセス規格である IEC 62304 Ed.2 を箇条5で呼んでいる。IEC 62304 が Ed.2 になると一般要求事項として 品質マネジメント,リスクマネジメント,ユーザビリティを要求するようになると予想される。

品質マネジメントは規制対象の医療機器の場合は,ISO 13485(ISO 13485 は ISO 9001の医療機器版で文書化要求などが強化されている) を 規制対象外の場合は,ISO 9001でもよしとし,リスクマネジメントは ISO 14971 を,ユーザビリティは IEC 62366-1 で適合を示してもよいという方向性が検討されている。

ちなみに,ユーザビリティは 使いやすさを目的にしたユーザビリティではなく,ヘルスソフトウェア製品の使用に伴うリスクを特定しコントロールすつためにユーザビリティエンジニアリングを要求している。また,セキュリティに関してもヘルスソフトウェアの安全に影響する脅威を特定,評価し,対策することを求めている。

医療機器ソフトウェアについては 2020年に向けて「バリデーションを含む製品安全」「ソフトウェアライフサイクル」「品質マネジメント」「リスクマネジメント」「安全のためのユーザビリティ」「安全のためのセキュリティ」を求めることで,医療機器ソフトウェアの製品安全を確立しようとしている。

このブログで繰り返し主張しているように,ソフトウェアのプロセス要求だけで,ソフトウェアの製品安全を示すことは出来ず,いろいろな確度から安全について証明していく必要があるということだ。

セキュリティはソフトウェア製品がネットワークで他のソフトウェアとつながるようになって,また,ユーザビリティはユーザインタフェースがリッチになるに従って,使い方を間違うことで危害に至ることが増えてきたことが背景にある。

また,バリデーションやリスクマネジメントが重要視されてきたのは,システムを構成する個々のソフトウェア部品の信頼性を高めることでは,システム全体の安全性や信頼性を確保できないほど,ソフトウェアは大規模・複雑化していることを示している。

「バリデーションを含む製品安全」「ソフトウェアライフサイクル」「品質マネジメント」「リスクマネジメント」「安全のためのユーザビリティ」「安全のためのセキュリティ」ひとつひとつが規格に適合しているしていないということに着目するのではなく,そのシステムに対してどの要求がどのように安全に寄与しているのかをよく考えて,全体として安全を確かなものにするにはどこを強く抑えると効果的かを考えることが求められるようになる。

規格適合は過程であって目的ではない。このことを忘れてはいけない。

2018-01-08

ソフトウェア製品の認証は可能か?

先日,某所から「ソフトウェアの認証を行うとしたら,何を試験すればいいのか」という質問を受けた。まず,医療機器に搭載するソフトウェアや,そのものが医療機器となるソフトウェアのケースを説明し,その後,一般的なソフトウェアだったらどうなるのかと考えてみた。それが,この図だ。

規制対象となっている医療機器の場合,薬事申請する際にその医療機器の種類によって,基礎安全,基本機能,基本性能について申告をし,それらが規格を満たしていることの証明を提出しなければならない。それに加えて,リスク分析とその評価結果,リスクコントロール手段とそれを実施してエビデンス,ソフトウェアライフサイクルに関する要求,ユーザビリティに関する要求などを満たしていることを示し,最終的に妥当性の確認を行う。

ここで改めて,なぜソフトウェアを認証したいのかについて考えてみよう。そう聞かれるとおそらく,「ソフトウェアの品質を可視化したいから」とか「ユーザーが安心して使える指標にしたいから」という答えが返ってくるのではないかと思う。

で,ソフトウェアの品質って何だろうと思う。ISO/IEC 9126 のソフトウェアの品質特性を持ち出して,これらだという人がいるかもしれないが,それは違うだろう。
これらの特性は作る側の尺度であって,ソフトウェアを使う側の価値と相対しているとは思えない。
  • 機能性(functionality)
  • 信頼性(reliability)
  • 使用性(usability)
  • 効率性(efficiency)
  • 保守性(maintainability)
  • 移植性(portability)
ユーザーが知りたいのは,ソフトウェア(製品)の価値ではないか。製品の価値には2種類あって,顕在的な価値と潜在的な価値がある。顕在的な価値は,最初の図で言えば,基本機能や基本性能,ユーザビリティなどがそれに当たる。潜在的な価値は,(商品としての)安全性や信頼性だ。顕在的な価値は,製品のカタログやWEBサイトの説明にたいだい書いてある。潜在的な価値は,その通りに動くのか,また,不具合なく動き続けるのかがポイントとなる。ユーザーはソフトウェア(製品)の価値が高いか低いかを知りたいのだろう。ソフトウェア品質とソフトウェア(製品)の価値には相関があるようでいて,実はそうではないという側面もある。ソフトウェア品質はソフトウェア(製品)の価値の1つの側面でしかなく,しかも,ソフトウェアの価値を間接的にしか見ていないように思う。

ソフトウェア品質論の歴的推移を説明するときに毎度この図を使わせてもらっている。

そもそも,昔はソフトウェアについても不具合はゼロにしようという目標で品質論が語られてきたが,今ではそれは無理ということが分かってきたので,ソフトウェアの開発プロセスを管理することで,間接的にソフトウェアの品質を高めることが主流となってきた。

それでも,特に日本では価値や顧客満足を評価指標としてソフトウェアの品質が評価されることもあった。それが「当たり前品質」や「魅力的な品質」といった評価指標だ。

そもそも,ソフトウェア起因の障害は Systematic Failures/Faults (決定論的原因故障/障害)と呼ばれ,ソフトウェアのバグやソフトウェアに起因する問題やユーザーオペレーションが原因で発生する障害発生率率の予測が難しい故障/障害,出荷前の検査で発見することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。

とてもやっかいな障害だそしてSystematic Failures/Faults 決定論的原因故障/障害は開発のプロセス工程ライフサイクルの中で Systematic Failures/Faults の作り込みを防止し検証や妥当正確認によって発見・除去するしかないというのが一般的な考え方らしい

だから,ソフトウェアの理想的なプロセスを定義して,その通りのソフトウェアが開発されたかどうか,また,ソフトウェアの開発組織が定義したプロセスに対して,どれくらい成熟しているかを図ることが主流となっている。ソフトウェアの場合,ドメイン知識を持たない者が客観的に評価しようと思ったら,結局のところ開発プロセスが定義どおりに行われているかどうかを見るしかなかったのだろう。

しかし,ソフトウェア製品の評価の図をもう一度見て欲しい。ライフサイクルプロセスの評価はソフトウェア製品の評価の一部でしかない。しかも,間接的な評価指標だ。

基本機能や基本性能を評価せずして,ライフサイクルプロセスの評価だけを行って,ソフトウェア製品の価値が計れるはずがない。ソフトウェアが意図する機能や性能をテストせず,開発プロセスだけを評価して,ソフトウェア製品の価値が計れるはずがない。ソフトウェア開発プロセスの完成度,成熟度が高いということは,相対的に「ソフトウェア品質が高いだろう」と予想できるといっているに過ぎない。実際に,そのソフトウェアの性能が高い,機能が期待通りかとうかを直接証明している訳ではない。それらを証明するためには,そのドメイン,その製品に特化したテストとテストのエビデンスが必要となる。「テスト計画を立てること」「テストを実施すること」「テストカバレッジが高いこと」は間接的な評価であって,「何のテストをしたのか」「設定した評価指標は正しいのか」「テストケースの境界値は合っているか」といった機能や性能の直接的な評価ではない。

前者がソフトウェアの開発プロセスの適合を検査するときの間接的な品質検査であり,後者がソフトウェアの直接的な品質検査だ。ソフトウェアの価値を知るためには,どちらも必要でどちらもやった方がいいが,より重要なのは直接的な検査だと思う。

電気的な安全性や機械的な評価などとは異なり,ソフトウェアを評価するのは難しい,こうなっていれば安全とか,こうなっていれば価値が高いと断定できるような,評価指標がない。だからといって,何の評価指標もないとユーザーがそのソフトウェアを選んでいいのかわからないという問題がある。しかし,生死に関わるようなソフトウェアでなければ,問題が発覚したら,アップデートするという解決策がある。

クリティカルなソフトウェア製品をライフサイクルの評価でユーザーにアピールするケースがあるが,それだけでは本当に本質を示していないと思う。基本機能や基本性能,どのようなテストを行ったのかなど,顕在的な価値や潜在的な価値を推し量るための材料はいろいろあるはずだ。賢いユーザーはそういった指標によって,ソフトウェア製品を評価するのだと思う。

ちなみに,ソフトウェアの評価に,基本機能や基本性能のテストを含めてしまうと,ドメイン知識がない認証機関はその指標が本当に正しいのかどうか判断がつかない場合がある。特にソフトウェアの場合は,難しいだろう。

だから,第三者認証を商売にしたい者は,ソフトウェアの基本機能や基本性能のテストをやりたがらないし,そこを評価したくないのだ。ソフトウェアの開発プロセスの認証なら,ドメイン知識がなくてもできるので,そればかりやりたがる。

ソフトウェアの認証は基本,自分で評価基準を決めて,自己認証し,その内容に嘘がないかどうかだけを見るようにすればいいのだ。誰かにお墨付きをもらうと考えること自体に無理があると思う。

ソフトウェア(製品)については,ドメイン知識があるものしか評価できない側面が多いと思った方がよい。だから,第三者がソフトウェア(製品)を評価する際には,その製品の開発者がどのようなテスト計画やバリデーション計画を立てているのか,その戦略やコンセプトはどのようなものか,テストケースは適切か,エビデンスに虚偽はないかといった点を見る必要がある。それは標準的なソフトウェア開発プロセスに従って開発を行っているかどうかという視点とはちょっと違う。

ソフトウェア(製品)の評価者はそのソフトウェア(製品)は価値が高いのか低いのかという視点を持って評価する必要がある。商品の価値は「意図する使用=Intended Use」を理解しないと分からない。

そして,ソフトウェア(製品)の開発者は,ソフトウェア(製品)の真の価値を評価できるのは第三者認証機関ではなく,自分達だということを認識すべきだろう。

第三者認証機関が評価できるのはあくまでもソフトウェア(製品)の価値の一面でしかなく,全体を見渡して評価できるのは,ドメイン知識を持った自分達だということだ。