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

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世紀の大規模複雑化したシステムでは成り立たない。

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

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

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

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

P.S.

その後、米運輸安全委員会（NTSB）が、配車アプリ大手ウーバー（Uber）の自動運転車に女性歩行者がはねられ死亡した事故に関し、衝突の6秒前に車が歩行者を検知したものの、自動緊急ブレーキ（AEB）が作動しなかったことを2018年5月24日初期調査報告書で発表した。

自動運転システムは歩行者を検知した後、衝突の1.3秒前に緊急ブレーキが必要だと判定したが、事前にウーバーの技術者らがAEBシステムが作動しないよう設定していたとも指摘している。AEBを無効にした理由は「車体に不規則な挙動が生じる可能性を下げるため」とのこと。

ようするに機器やシステムの不具合というよりは、ヒューマンエラーだったということらしい。ただし、こういったヒューマンエラーも考慮してリスクマネジメントをしなければ事故はなくならない。

バリデーション（妥当性の確認）は、ヒューマンエラーを含めた使用環境を想定して行わなければならない。部品レベルの安全対策では、システムのエラーのすべてを防止することはできない。