自動運転の安全上のリスクはどこから来るのでしょうか?

最近、当社の自動運転デビューがニュースで取り上げられており、ADS はついに謎の組織ではなくなりました。数年前のあまり良くなかったデモから今日の成熟した製品まで、コンセプトからデザインまで、あらゆる分野で何度も大きな衝撃と再構築を経験してきたと言っても過言ではありません。今振り返ってみると、これは革新的な製品を生み出すために非常に苦痛ではあったが必要なプロセスでした。

セキュリティ分野も例外ではありません。

このプロセスにより、私たちはすべての基準や規範を脇に置いて、「自動運転の安全上のリスクはどこから来るのか」と自問せざるを得なくなります。

この図は私たちの理解を大まかに表していると思います。

この図は、セキュリティ リスクの原因である、ユーザーの期待とシステム機能の乖離を直感的に表現しています。

低レベルの従来のADASについては、初めて使用すれば、たまに足を休めるためにしか使えないことがわかり、より高度な機能を備えていると誤解されることはありません。システム機能が低く、ユーザーの期待も低く、セキュリティも問題ではありません。問題はその製品が役に立たないことだ。

先進から自動運転まで、システム能力は高く、ユーザーの期待も高く、安全性も問題ない。問題は、そのような製品がまだ存在しないことだ。

問題は最低点から最高点へ至る過程です。現段階では、市場に出回っているすべての自動運転システムは、より継続的なユーザーエクスペリエンスを目指し、ユーザーの期待を高めようとしています。この登山プロセスではシステムリスクも蓄積されます。

ユーザーは、システムの単一点および短期的な機能に簡単に満足します。システムが小さな eDonkey をうまく回避すると、ユーザーはシステムが万能であると想定します。システムが1週間人間によって操作されないと、ドライバーのシステムへの信頼は劇的に高まり、携帯電話を見ながら居眠りし始める。ユーザーの期待は、システムの機能よりもはるかに速く増大するでしょう。

私たちの考慮と出発点はすべて、このギャップを埋めることです。

まず、従来の機能安全設計が不可欠である

本質的には、従来の機能安全設計により、システム機能外のリスク (グレーゾーン) をカバーできるようになります。

具体的には、次の 2 つのことが保証されます。まず、ドライバーはいつでも運転を引き継ぐことができます。第二に、公共の安全に対する避けられない危害を回避する。誰もが交通行動に対して期待を持っています。車の行動がごく短時間でこの期待を大きく乱した場合、人々が反応して時間内にそれを回避するのは困難です。

目的は同じですが、高度な自動運転の場合、この部分の設計は従来の ADAS とは大きく異なります。しかし、これはあくまでも機能安全の概念を新しい種類の ADS に適用したに過ぎません。これは業界の研究が徐々に成熟していく分野であると思うので、ここでは詳しく述べません。

第二に、適切なコア冗長性

業界でよく言及されるフェイルオペレーションは、L3 の定義に由来します。つまり、システムに障害が発生した場合、ドライバーが引き継ぐのに十分な時間 (通常は 10 秒) を与える必要があるということです。業界ではこの定義の矛盾については十分に議論されており、ここでの議論の焦点では​​ありません。重要なのは、SAE の L3 の厳密な定義により、フェイルオペレーションは完全な冗長性とほぼ同等となり、冗長設計の方向性から完全に逸脱しているということです。

興味深いことに、私は数日前に自動運転に関する討論会に出席し、主流の業界の間で明らかなコンセンサスを目にしました。つまり、L2/L3/L4 について議論する人はもうおらず、全員が都市部、一般的なシナリオ、ユーザー エクスペリエンスをターゲットにしているということです。では、冗長な設計は完全に無視できるということでしょうか?

問題は依然として、システムの機能とユーザーの期待のギャップにあります。ユーザーがシステムを十分に信頼している場合、システムを瞬時に乗っ取ることは難しくなります。これがシステム冗長性要件の根本です。

しかし一方で、冗長性は諸刃の剣でもあります。冗長性は、コストの増加、アーキテクチャの複雑化、および切り替えプロセスにおける無数の落とし穴を意味します。次の図を使用して、大手 OEM の自動運転システムの冗長アーキテクチャを確認できます。このアーキテクチャが実装されているかどうかはわかりません。私の意見では、このアーキテクチャは必ず失敗し、競争力がなくなります。

3番目に、「システムデリバリー」を再定義する

従来の製品開発プロセスでは、「SOP」の時点で、システムの機能、信頼性、セキュリティが高いレベルの成熟度に達していることを確認します。しかし、自動運転の特性上、「SOP」は製品開発の終わりを意味するものではありません。システム機能の継続的な改善のプロセスは、SOP の後に大部分発生します。これは、従来のセキュリティ設計の「システム思考」に破壊的な影響を及ぼします。つまり、SOP の前にすべての要件をリストし、V モデルに従って開発および提供するという従来のアプローチに従うことは、現実的でも必要でもありません。

「データ駆動型改善」という概念は自動運転の分野で非常に人気があり、この分野の主流プレーヤーが満場一致で認めるシステム進化の方向でもあります。セキュリティ設計において、この傾向に対処するには、まず各段階で主要な配信目標を特定できるようにする必要があります。同時に、データのクローズドループの適時性も非常に重要であり、これは当社の「データ駆動型改善」ソリューションが解決することを目指している問題でもあります。無視してはならないもう 1 つのポイントがあります。システムの立ち上げプロセスでは、システム全体のリスクを制御するために、人間とコンピューターの合理的なインタラクション設計が必要です。

これは、私が最も難しいと思う最後のポイントにもつながります。つまり、人間とコンピュータのインタラクション設計を通じて、ユーザーの期待とシステムの機能を可能な限り一致させるということです。

難しいのは、「ユーザーエクスペリエンス」と「ユーザーの期待」のバランスです。ユーザーエクスペリエンスの観点から、ユーザーが可能な限り邪魔されずに完全に解放されることを願っています。製品のセキュリティの観点から、ユーザーは常にシステム機能の限界を認識し、引き継ぐ準備をしておく必要があります。これら 2 つの要求により、人間とコンピュータのインタラクションの設計に非常に高い要求が課せられます。つまり、必要のないときにユーザーの邪魔をしないようにすること、リマインダーをできるだけ正確かつ直感的にすること、システム機能の進化に基づいて人間とコンピュータのインタラクションを継続的に調整および進化させることです。 。 。おそらく、この分野の設計の難しさや作業量はアルゴリズム開発ほど簡単ではないことに気づいていないかもしれません。

最後に、近年、従来の機能安全手法では新しい技術の開発に効果的に対応できないという不満の声をよく耳にします。これがこの問題を解決するための新しいアイデアのきっかけになれば幸いです。結局のところ、製品のユーザー エクスペリエンスは、自動運転トラックにおける重要な中核競争力であり、安全性は、このマラソン トラックで最後に笑うための保証でもあります。