自動運転データの閉鎖とエンジニアリングの詳細な分析

1 クローズドループコンセプトとR&Dクローズドループ

私たちは毎日、クローズドループを扱っています。携帯電話の画面を指でタップすると、携帯電話のシステムが選択したコンテンツを表示します。これはインタラクティブなクローズドループであり、携帯電話を使用している間、このクローズドループは継続します。アルゴリズムは、特定の短い動画に費やした時間を分析し、ユーザーの興味を推測して、ユーザーが好みそうな短い動画をプッシュするという閉ループを形成します。この閉ループは動作し続け、最終的にアルゴリズムはあなたの興味をしっかりと把握します。

実際、私たちは製品設計、マーケティング、研究開発などあらゆる面でクローズドループについて頻繁に言及しています。

製品の設計と開発、ユーザーへのリリース、そして設計をさらに改善するためのフィードバックの収集が、閉じたループを形成します。

マーケティング活動の開催、広告の掲載、広告効果データの収集と分析、そのデータに基づいたマーケティング手法や広告デザインの改善、広告チャネルの最適化もクローズドループを形成します。

ディープラーニングアルゴリズムのトレーニングプロセス中、勾配降下法の各反復、損失関数の偏差計算、およびバックプロパゲーション後の次の勾配降下法の計算も閉ループになります。

アジャイル開発における 2 週間の反復はそれぞれ PDCA (計画、実行、確認、調整) のクローズドループです。各 PI (プログラム増分) には複数の反復が含まれており、PI 自体はより大きな PDCA クローズドループです。

クローズドループの概念は広く使用されています。これをよりよく理解し、適用するために、その一般化された概念を整理してみましょう。

1.1 閉ループの抽象概念

学術的には、「閉ループ」という厳密な概念はサイバネティクスの分野で生まれました。より抽象的な定義は、システムの動作を正確に制御したい場合、システムの出力に基づいて入力を修正し、より正確な制御精度を実現するということです。システムの出力が入力側の計算にインポートされ、連続した往復サイクルを形成するため、閉ループと呼ばれます。

図1 制御システム

一般的な例を挙げると、マウスを画面上の目的の位置に移動させたいとします。手でマウスを動かすと、私たちの目は現在の位置と目的の位置を観察し、脳がその 2 つの位置の偏差を計算して、マウスポインターの移動方向と速度を制御します。移動プロセスの最初の部分が高速化され、目標位置付近で微調整が行われます。目で観察されたマウスの新しい偏差は脳に送られ、手が移動した距離を計算します。この閉ループプロセスは、マウスがターゲット位置に到達するまで継続されます。単純に見えますが、非常に一般的なプロセスです。自動運転の車両制御アルゴリズムと長距離ミサイルの誘導は同様のプロセスです。

これらの例から、閉ループを構成するいくつかの重要な概念（閉ループターゲット、偏差定義、フィードバックループ）を抽象化します。

クローズドループターゲット

すべての「閉ループ」には「ターゲット」があります。「ターゲット」とは、この閉ループ理論が達成する必要のある目標として理解できます。これがこのクローズドループの役割です。たとえば、「計画された軌道をたどるように車両を制御する」や「画像内の人物を正しく識別する」などです。

テストクローズドループの場合、テスト対象の特定のオブジェクトがこのクローズドループのターゲットになります。

R&D プロセスのクローズドループの場合、R&D の目標がクローズドループのターゲットになります。

定義からの逸脱

各閉ループには入力から出力への順方向パスがあり、出力結果は予想される結果から直接偏差するため、この偏差を明確に定義する必要があります。複数の閉ループ反復の目的は、この偏差を減らすことです。

図2 閉ループの特性

フィードバックループ

フィードバックループは、フォワードパスの出力に基づいて入力を変更するメカニズムです。

概念の抽象化

制御理論とディープラーニングアルゴリズムに精通している人は、これらの概念に非常に精通しているでしょう。たとえば、ディープラーニングアルゴリズムでは、これらの概念は「損失関数」や「バックプロパゲーション」などの用語で呼ばれます。この記事の目的は、特定のアルゴリズムの原理を説明することではなく、自動運転システム開発のエンジニアリングを説明することです。このエンジニアリングプロセスは、一連の閉じたループで構成されています。

これらのクローズドループには、特定のテクノロジを開発するプロセス、テスト方法、特定のアルゴリズムを実行する原則などがあります。しかし、ある特定のプロセスが閉ループを形成する限り、上記の抽象的な概念を要約することができ、特定のコンテキストにおける抽象的な概念の具体的な現れを推論することができます。

1.2 R&Dクローズドループ

前述のように、「クローズドループ」は多くの分野、特に自動運転システムの研究開発と運用に登場し得る非常に一般的な概念です。この記事のテーマをより正確に説明するために、まず誤解されやすい概念を明確にしましょう。ここではまず、「開発クローズドループ」と「ランタイムクローズドループ」を区別します。

1.2.1 R&Dクローズドループとランタイムクローズドループ

これを具体的な例で説明してみましょう。

自動運転の最も基本的な機能は「レーンセンタリング」、つまり車線がある場合に車両を車線の中央線に沿って走行させることです。この機能には、車線認識のための視覚認識アルゴリズムと横方向の車両制御アルゴリズムという 2 つの主要な技術があります。

図3 車線維持機能図

その「ランタイムクローズドループ」とは、車両の走行中にカメラが前方の道路の画像を収集し、車線を識別して適切な座標系に変換し、車線内の車両の現在位置を推定し、制御アルゴリズムが車線情報、車両の位置情報、車両自身の速度、方向などの情報を受信して、ステアリングホイールの角度やトルクを制御することです。閉じたループ全体が何度も繰り返し動作して、車両を中央に保ちます。

この閉ループの動作目的は、「車両を中央に保つ」ことです。閉ループの偏差は、車線の中心線からの車両の方向の偏差として定義されます。フィードバックループは、偏差に基づいて計算された横方向の制御コマンドに基づいて、車両の状態が変化するように制御します。

「R&D クローズドループ」とは、この「ランタイムクローズドループ」を開発するための R&D、テスト、および統合のプロセスです。上記のランタイムループには、2 つの独立した R&D ループを設計できます。1 つは、認識アルゴリズムの開発とテスト、視覚画像からの車線線の計算、および他の手段 (シミュレーションシステムなど) によって取得された車線線の真の値に基づいて計算が正しいかどうかを確認するために使用されます。この R&D ループは繰り返し反復され、アルゴリズムを継続的に改善します。もう 1 つの R&D ループは、車線線の真の値を取得し、横方向制御アルゴリズムの開発とテストのみを行います。これら 2 つの R&D クローズドループは、独立して実行し、その後統合することができます。

プロトタイプシステムと生産開発

プロトタイプシステムを作りたいだけなら、実はそれほど複雑ではありません。 2 メガピクセルのフロントビューカメラ (ISP 内蔵) を使用し、カメラの内部および外部パラメータ、産業用コンピューター (GPU 搭載 x86)、および有線制御の車両をキャリブレーションできます。車線認識畳み込みニューラルネットワークに関する論文やオープンソースアルゴリズムは数多くあり、参照可能で、単純な横方向制御のデモレベルを達成するのは比較的簡単です。

しかし、何万台もの車両に搭載できる量産システムが必要な場合は、物事はそれほど単純ではありません。少なくとも次のような困難が考えられます。

カメラのISP性能により、さまざまな環境でより良い画質を出力できます。
車線認識アルゴリズムの精度、特に車線が不明瞭な場合、雨天や雪天の場合
車線認識アルゴリズムは車線の曲率を正確に識別できますか?
異なる車速における横方向制御アルゴリズムの安定性
さまざまなコーナリング状況における横方向制御アルゴリズムの安定性
画像取得から制御コマンド実行までの遅延は十分に小さく、安定していますか?

システム全体を車両組み込みプラットフォームに移植する場合、その他のエンジニアリング上の課題があります。

ディープラーニングアルゴリズムを実行できる適切な組み込みプロセッサを選択する
ディープラーニングアルゴリズムモデルをターゲットの組み込みプロセッサに変換すると、演算子が欠落したり、精度が低下したり、実行が過度に遅延したりすることはありますか?
ディープラーニングアルゴリズムは、特定の組み込みプラットフォーム向けに最適化する必要があります。コストを削減する必要がありますか? 指摘できますか? メモリ帯域幅を最大限に活用するにはどうすればよいですか? キャッシュヒット率を向上させるにはどうすればよいですか?
視覚アルゴリズムの動作をサポートするソフトウェアアーキテクチャを設計する方法と、異なるモジュール間で通信する方法
視覚アルゴリズムが実行される OS はソフトリアルタイムシステムであることが多いのに対し、車両制御アルゴリズムはハードリアルタイム OS で実行されることがよくあります。視覚アルゴリズムは極端な場合にはフレームが失われますが、制御アルゴリズムはどのようにしてエラーを許容できるのでしょうか。
ECUと車両システムの電源管理システム、ネットワーク管理システム、診断システム間の接続
デバッグモード、ファクトリーモード、OTA モードなどを含む ECU の更新とアップグレード。

これには、ハードウェアの設計とテストの複雑さは考慮されていません。ハードウェアでは、放熱、耐衝撃性、電磁両立性、耐久性などの一連の問題も考慮する必要があります。したがって、量産可能なシステムを実装することは、プロトタイプシステムを開発するよりもはるかに複雑です。プロトタイプシステムの開発には、路上でのデモンストレーション用に車両を制御できるようにアルゴリズムを機能させる少数の主要エンジニアのみが必要です。しかし、これは大量生産のエンジニアリングにはまだ程遠いものです。

プロトタイプシステムは、上記の困難な問題を一時的に無視し、非常に理想的な動作条件下でコア機能を直接実証することができます。プロトタイプシステムの開発では、すべてのリンクをカバーする大規模なR＆Dクローズドループ、ISPを内蔵したカメラ、産業用コンピューターで実行される視覚アルゴリズム、制御アルゴリズム、および最も理想的な道路環境のみを使用でき、車両上で直接デバッグできます。

R&Dのクローズドループの解体

しかし、エンジニアリングの量産開発においては、閉じた研究開発ループ内で上記の困難をすべて解決することは不可能です。さらに、さまざまな困難が及ぶ技術分野も大きく異なります。どちらもディープラーニングアルゴリズムに関連していますが、NVIDIA の GPU を使用してアルゴリズムをトレーニングすることと、特定の組み込みプラットフォーム上でアルゴリズムを移植および最適化することは、ほぼ完全に異なる分野です。

したがって、研究開発においては、上記のような技術的な困難を異なる研究開発のクローズドループに分割する必要があります。それぞれの重要な技術ポイントを、閉じた研究開発ループ内で独立して開発および最適化できるようにします。各 R&D クローズドループの目標は、できるだけ少ない技術的なポイントに焦点を当てることです。

各 R&D クローズドループは独立して進化し、テストされます。最終的に、それらは統合されて完全なシステムを形成します。システム全体の運用中に問題が発生した場合、問題が発生した独立した閉ループまで遡って再現、解決、再テストできる必要があります。次に、統合後の検証を実行します。これはエンジニアリングです。

エンジニアリングとは、合理的なロジックに従って複雑なシステムを分解し、標準化された分析、設計、開発を実行できる適切な規模のチームに分割し、最終的に完全なシステムに統合するプロセスです。最後に、その重要な機能は、繰り返し可能なプロセス、予測可能な結果、追跡可能な問題、および自動化されたプロセスです。

この記事の焦点は、R&D プロセスのエンジニアリングにあるため、R&D クローズドループに基づいて議論します。各 R&D クローズドループの対象は、多くの場合、全体的な自動運転操作のクローズドループ内の特定のリンクです。閉じた研究開発ループが運用中にオープンループになる可能性もあります。

1.2.2 最小変数の原理

こんな話を聞いたことがあるかもしれません。大きな工場に大きな機械がありました。ある日突然、何かが故障し、機械の生産が停止しました。多くの修理工が雇われましたが、誰も修理できませんでした。最終的に、社長は最も有名な整備士を見つけました。彼はあちこちを叩き、ついに位置を決め、角度を選び、ハンマーで叩くと、機械は正常に動き始めました。そして彼は「一万元」を提示した。その理由は、「ハンマーを振るだけでは1元の価値しかないが、特定の場所、特定の角度、特定の力でハンマーを打つと、9,999元の価値がある。これがテクノロジーの価値だ」というものだ。

この話が真実かどうかは別として、これはある現象を物語っています。つまり、人々は問題に遭遇すると、たとえある程度の費用がかかったとしても、一撃で問題を解決できる技術専門家の存在を期待するのです。

これに何度も遭遇しました。自動運転の研究開発チームの20人以上が車を取り囲みました。さまざまな技術部門やさまざまな仕事の人が交代でやって来て試してみましたが、問題を解決することができませんでした。チームリーダーは、前の物語の上司のように、問題がどこにあるのか、そしてそれをどのように修正すればよいのかを指摘できるような有能な人材を望んでいるに違いありません。

しかし、物語が物語である理由は、それがただ美しい願いであるからです。

この話と比べて、私は別の事実の方が好きです。 AとBの間の電話回線が切断されているため、保守担当者はまずAとBの中間点Cに行き、ACとBCが通話できるかどうかを確認します。 AC はクリアだが BC はクリアでない場合は、BC の中間点に進み、同様のテストを完了します。 AB 間の距離がどれだけ長くても、この方法を使用すると、対数関数の形で障害点にすばやく収束できることがはっきりとわかります。

2 番目のストーリーは、プロセスが繰り返し可能で、結果が予測可能で、問題が追跡可能であるというエンジニアリングの特性に完全に当てはまります。一定の時間枠内で問題を見つけて解決できることはわかっています。多くの場合、問題を発見することは、それを解決するよりもはるかに困難です。 1つ目の話は運に左右される部分が大きいです。そういう才能のある人がいるかどうか、その才能のある人が問題を解決するのにどれくらいの時間がかかるか、今回解決できたとしても次回は解決できるかどうか、そういったことは全く予測不可能です。

実際、閉ループシステムに 2 つ以上の変数がある場合、どの変数が問題の原因であるかを特定するのは困難です。

1 つの変数を分析するときは、他の変数の影響を可能な限り分離するように努める必要があります。したがって、R&D のクローズドループを分解する場合、それぞれの小さなクローズドループが全体的な問題領域内の 1 つの変数のみを対象とすることを期待します。ストーリー 2 と同様に、AC セグメントをテストする場合、BC セグメントの影響を受けません。これには、他の変数を正確に制御したり、分離したりする能力が必要になることが多く、これは他の変数のデータシミュレーション (モック) を提供することで特定のアプリケーションに反映されます。自動運転の研究開発では、これはさまざまな形式のインザループシミュレーションと呼ばれることがよくあります。

1.2.3 R&Dクローズドループ間の関係

一般的に言えば、自動運転データのクローズドループに対する私たちの理解は、専門的なデータ収集車両を運転したり、量産車両を通じてデータを収集したりして、さまざまなアルゴリズムを改善し、運転シナリオで発生するさまざまな問題を発見して解決し、自動運転システムを改善し、自動運転機能のクローズドループ反復を形成することです。

この理解自体に間違いはありませんが、このような複雑なシステムの場合、適切な階層的分解がなく、複雑なシステム全体を直接議論すると、エンジニアリングの問題ではなく形而上学的な問題を議論していることになります。

大規模な R&D クローズドループは、相互に関連する一連の小さなクローズドループで構成されます。いくつかは階層的な関係であり、大きな閉じたループの中に小さな閉じたループがあります。

図4 車両制御アルゴリズム開発の閉ループ進化

異なる小さな閉ループも互いに接続されています。具体的な例を見てみましょう。

上の図は、車両制御アルゴリズムを開発する際に考えられる 4 つの閉ループ (A、B、C、D) を示しています。

通常、車両制御アルゴリズムのプロトタイプを開発する場合、「クローズドループ B」が直接使用されます。このクローズドループでは、モデルベース開発モードを使用して制御アルゴリズムが開発されます。アルゴリズムモデルの構築には、MATLAB+Simulink がよく使用されます。モデルによって生成された C コードは、ラピッドプロトタイピングデバイス (dSpace AutoBox など) でコンパイルされ、実行されます。ラピッドプロトタイピングデバイスは車両バスに接続され、車両のワイヤ制御システムを通じて車両の動作を制御します。

補足: モデルベース開発について

これはローコード開発アプローチです。 MATLAB は数学解析ソフトウェアです。数学計算の需要が高い専攻（応用数学、自動制御など）では、大学時代から MATLAB に組み込まれたシンプルなスクリプト言語を使用して数学計算や表示を行っています。 Simulink は MATLAB のプラグインとして存在し、ビジュアルプログラミング環境を提供します。さまざまな既成の機能実装が組み込まれており、ユーザーはこれらのモジュールを視覚的に組み立てるだけで、独自のアルゴリズムのアイデアを実現できます。基本的に、制御アルゴリズムエンジニアは学校から実際の仕事まで、このように学びます。こうすることで、C 言語でのプログラミングに多くの時間を費やすことなく、制御理論を現実のシナリオに適用することに集中できます。 C 言語に精通している自動車組み込みエンジニアのほとんどは、オペレーティングシステムや車両コントローラーハードウェアとのやり取り方法のみに関心があり、制御理論には精通していません。結局のところ、すべての分野が単純というわけではなく、誰もが分野横断的な知識を習得するのに十分なエネルギーを持っているわけではありません。 MATLAB + Simulink を使用することで、制御アルゴリズムエンジニアが作成したビジュアルアルゴリズム (制御モデル) を、高品質の C コードに自動的に変換できます。これにより、2 つの分野間のギャップが埋まり、両方の分野の専門家が得意分野に集中できるようになります。 Simulink のビジュアル開発は、より専門的な関数ライブラリと、より豊富で柔軟な表現を提供することを除けば、子供向けプログラミング言語 Scratch の作業モードと本質的に同じです。興味があれば、Scratch 用の C コードジェネレーターを作成することは完全に可能です。

補足：ラピッドプロトタイピング装置について

MATLAB + Simulink を使用して記述された可視化モデルは、最終的には C コードに変換され、コンパイルされて実行される必要があります。自動制御システムは組み込みリアルタイムコンピューティングプラットフォーム上で実行されることが多いため、これらの C コードは RTOS システム上で実行され、さまざまなフィールドバスを介して他のデバイスと対話する必要があります。これは組み込み開発の分野であり、自動制御を学ぶ学生は組み込み開発にも精通している必要があります。両方の分野に精通することは困難であり、結局のところ、時間は限られています。ラピッドプロトタイピング装置は、この問題を解決することを目的としています。このデバイスは、カスタム標準組み込みハードウェアとそれに適合するリアルタイムオペレーティングシステムを使用して構築されています。このデバイス上で C コードをコンパイルして実行するためのツールチェーンも提供されています。機器が完成すると、その入力および出力機能も決定されます。制御アルゴリズムエンジニアは Simulink を使用して作業するため、このデバイスの開発者は、デバイスの入力と出力を Simulink 上でドラッグアンドドロップできるモジュールに制御する機能を慎重に設計しました。制御アルゴリズムエンジニアは、Simulink 上のこれらのモジュールを使用して、独自のアルゴリズム部分に接続します。この方法では、実際の制御アクションを完了するには Simulink で作業するだけで済みます。モデルを C コードに変換し、コンパイルして、この標準組み込みハードウェアに展開するプロセスはすべて、デバイス開発者が提供するツールによって自動的に完了します。モデル開発者はこれを気にする必要はなく、自分の制御領域のテクノロジーにのみ集中する必要があります。量産される組み込み機器は、一般的に特定のプロジェクト向けに設計されており、機能や性能が十分であれば、コストは低ければ低いほど良いです。サポートする Simulink モジュールを開発するのは、なおさら不可能です。ラピッドプロトタイピング装置は、多くのインターフェースを積み重ねることができ、高性能なハードウェアと便利な開発ツールチェーンを提供し、可能な限り幅広いプロジェクトに適用できるようにすることを目的としています。もちろん、価格も高価です。しかし、開発に必要なのが少量のバッチだけであれば、コストは重要な要素ではなく、利便性が最も重要です。このような装置は、開発の初期段階での問題を解決し、時間を節約し、制御アルゴリズムエンジニアが他のエンジニアの作業に頼ることなく、早期のプロトタイプ開発に迅速に取り組むことを可能にします。そのため、ラピッドプロトタイピング装置と呼ばれています。

ただし、「閉ループ B」には実際の車両が必要です。車両が準備できていない場合やリソースが不足している場合は、まず「閉ループ A」を使用できます。この閉ループでは、車両の代わりにソフトウェアシミュレーションツールを使用します。シミュレーションソフトウェアは、シミュレートされた車両 (自車) の動的パラメータを設定し、自車の周囲の環境の真の値と道路環境の真の値を与えることができます。このように、制御アルゴリズムの開発者は車両を離れてデスクトップ上で最初に開発することができ、認識結果は真の値を使用することになり、変数を減らすことと同等になります。

「クローズドループ C」と「クローズドループ A」の違いは、ラピッドプロトタイピング装置が削除され、制御アルゴリズムモデルによって生成された C コードを実行するために MCU 開発ボードが使用されることです。これを使用して、制御アルゴリズムモデルが C コードに変換された後に正しいかどうかを確認できます。このMCUは量産で使用する予定のチップですが、量産ハードウェアの開発にはまだ時間がかかります。メーカーが提供する開発ボードを使用して、すぐにテスト環境を構築できます。少なくとも次の理由によりエラーが発生する可能性があります。

Simulink モデルを C コードに変換するときにエラーが発生します。モデルを調整する必要がある可能性があります。
MCUの性能がラピッドプロトタイピング装置よりも悪く、これまで発見されなかった問題（クローズドループA）が発生する
モデルで生成したC言語コードをRTOSに組み込むとバグが発生します。これは将来の量産開発で発生する問題であり、この段階で事前に発見できます。

「クローズドループ C」と比較すると、「クローズドループ D」ではシミュレーションが実際の車両に置き換えられ、クローズドループに実際の車両のダイナミクス要素を追加することと同等になります。

次の表には、4 つの閉ループのそれぞれのターゲットと、各閉ループの変数と不変変数 (真の値) がリストされています。

表1 制御アルゴリズムの各閉ループの比較

A から B へのプロセスと A から C へのプロセスでは、それぞれ異なる変数が追加されていることがわかります (スマートセンサーによって提供される認識結果は信頼できると想定しています)。これら 2 つの変数は D に一緒に表示されます。

ただし、閉ループ D はまだ終わりにはほど遠いです。閉ループに関連付けられた 4 つのステップは、主に車両制御アルゴリズムのテストに使用されます。スマートセンサーも自社開発の認識アルゴリズムに置き換える必要があり、MCU 開発ボードは大量生産されたハードウェアに置き換える必要があります。したがって、これら 4 つの関連する閉ループは、より大きな閉ループの一部にすぎず、より高レベルのクローズドループに統合する必要があります。

この例から、R&D クローズドループのいくつかの特徴がわかります。

R&Dクローズドループの独立性

各 R&D クローズドループは独立して動作できる必要があります。独立して動作できるかどうかも、R&D クローズドループを設計する際に考慮しなければならない境界条件です。独立した操作を前提として、変数自体の正確性のテストに集中できるように、閉ループに最小限の変数を与えるようにします。

ただし、閉ループを形成するには、特定のデータまたはプロセスが必要です。たとえば、上記の例の閉ループ A の場合、シミュレートされた車と車の周囲の環境情報が必要です。解決策は、シミュレートされたデータを提供することです。簡単なシミュレーションデータは自分で作成することもできます。これは、ソフトウェアテストプロセスでも一般的な方法です。自動運転システムのシミュレーションデータは比較的複雑であり、多くの場合、シミュレーションツールを通じて実装する必要があります。

したがって、シミュレーションツールの目的は、独立して動作する閉ループのシミュレーションデータ (モックデータ) を提供することです。目的の異なる閉ループには、シミュレーションツールによって提供されるシミュレーションデータに対する要件が異なります。たとえば、上に示した閉ループ A では、車両ダイナミクスモデルが正確かどうか、および車両周囲の真値データのみが考慮されています。レンダリングが美しくリアルであるかどうかは、この閉ループにとってあまり重要ではありません。

R&Dクローズドループのつながりと進化

この変数をテストする際に他の変数の影響を分離するために、閉じた R&D ループに最小限の数の変数を配置します。しかし、私たちの最終的な目標は、すべての変数を最大の閉ループに統合し、適切に機能させることです。

変数を追加するプロセスは累積的であり、一度に 1 つずつ追加するのが最適です。変数が追加されるたびに、上記の例の「A が B に進化」、「A が C に進化」、「B+C = D」のプロセスと同様に、新しい閉じたループが形成されます。この段階的な追加プロセスは、閉じたループ間の接続、または元のクローズドループの進化に相当します。閉ループ進化のステップが小さいほど、問題が発生した場所を見つけやすくなります。

加算の逆順での減算の順序は、障害が発生したときに問題を特定する方法とまったく同じです。

ABC をスキップして直接 D に進むことはできますか? もちろん可能です。しかし問題は、事前の検証なしに非常に多くの変数が統合されているため、閉ループ D が最終的に正しく動作する可能性が非常に低いことです。これはプロジェクトの遅延に反映されており、いつ完了するかは誰にもわかりません。さらに、障害が発生した場合、診断のために変数を分離するテスト環境がありません。

3 つの閉ループ ABC の存在は、実際には閉ループ D の障害検出のための技術的な手段を提供します。数学的に言えば、3 つの閉ループ ABC の成功確率は、閉ループ D の成功の事前確率です。この事前確率を使用して、ベイズの確率法則に従って、閉ループ D の成功確率を計算できます。

ABC クローズドループがなければ、クローズドループ D の成功は完全に運次第になります。繰り返しますが、私たちに必要なのはエンジニアリングの確実性であり、絶対に必要な場合を除いて、流れを変えるために専門家は必要ありません。私たちが望むのは、混乱の中で「敗北の時に任務を引き受け、危険の中で命令に従う」ような賢者に期待するのではなく、最初から一群の平凡な人々が王の威厳ある道を歩むことです。工学に奇跡を期待することはできません！

R&Dクローズドループのレベル

R&D クローズドループには、連続的な進化だけでなく、レベルもあります。最大のクローズドループは、このセクションの冒頭で述べたとおり、専門的なデータ収集車両を運転したり、量産車両を通じてデータを収集したりして、さまざまなアルゴリズムを改善し、運転シナリオで発生するさまざまな問題を発見して解決し、自動運転システムを改善し、自動運転機能のクローズドループ反復を形成することです。この大きな閉ループは、複数の内部サブ閉ループで構成されています。

自動運転技術には、エンジニアリングの分野において多くのまったく異なる専門技術が関わっています。認識アルゴリズムと制御アルゴリズムは、まったく異なる技術方向です。認識アルゴリズムにおける異なるセンサーのアルゴリズム原理もまったく異なります。フロントフュージョンとポストフュージョンの技術ルートも大きく異なります。また、オペレーティングシステムとミドルウェアは上記のアルゴリズムとは関係ありません。

さまざまな分野のこれらのテクノロジーは、それぞれ独立したクローズドループ内で開発および検証され、最終的に最大のクローズドループにまとめられます。各技術分野の特性に応じて、各サブクローズドループ内にさらに小さなクローズドループをネストすることができます。単一のクローズドループでは、独立した製品を生成することもできます。これは、自社で開発することも、既存の成熟した製品から購入することもできます。

閉ループの階層的分解は、本質的に、完全な自動運転システムを構成するさまざまなサブ製品の可能な境界を定義します。サブ製品の境界を分割することで、異なるチームが独立して並行して開発活動を完了できるようになり、成熟した製品を購入することでシステム全体の研究開発と構築をスピードアップすることもできます。

1.3 テストとシミュレーションのクローズドループ

規模の大小を問わず、独立した各 R&D クローズドループは、このクローズドループの主な R&D コンテンツに対して、エンジニアリング的に実現可能なテスト方法とテスト環境も提供する必要があります。自動運転システムのソフトウェアとハードウェアは異種プラットフォームであることが多く、機能統合が困難です。テスト方法は一般的なソフトウェアテストよりも複雑で、テストツールへの依存度が高く、さまざまなインザループシミュレーションシステムを使用する必要があります。

図 5 は、さまざまなレベルのテストとシミュレーションの範囲と進化を示しています。レベル、ツール、実行者の観点からテストとシミュレーションについて説明します。

ユニットテストとモジュールテスト

ユニットテストは主に機能レベルのテストを指します。理論的には、型のすべての独立した関数またはメンバー関数には、対応する単体テストコードが必要です。ユニットテストの重要性はいくら強調してもし過ぎることはありません。単体テストでは、コードカバレッジとブランチカバレッジを評価する必要があります。どちらも100％に達する必要があります。つまり、コードのすべての行と可能なすべてのブランチは、単体テストプログラムによって実行されています。

単体テストは、ソフトウェアアーキテクチャの合理性にも重要な役割を果たしていますが、これについてはめったに言及されていません。その理由は、関数の粒度でソフトウェアアーキテクチャのテスト可能性をテストできるためです。

すべての関数の効果的なテストコードを作成することはできません。関数が2,000行を持っているなど、あまりにも多くのことをしている場合、単体テストを行うことは基本的に不可能です。

したがって、すべての関数に対して単体テストコードを書き込むことができる場合、ターゲットコードは関数レベルで最適化されることを余儀なくされます。関数機能は可能な限り単純である必要があります。可能な限り純粋な関数を記述する必要があります。関数コードは長すぎるべきではありません。

ネガティブな例を見ることができます：「10,000を超えるグローバル変数を備えたトヨタ事件は、巨大なバグベースを作成しました。」

関数レベルのユニットテストは、異なる入力条件下での関数の出力の正しさをチェックすることに焦点を当てています。また、この関数が内部的に状態を節約しない場合が最善です（純粋な関数）。このテストの範囲は少し大きく、複数の関数（または複数のコードファイル）が連携し、一般的に言えば、このスコープを機能モジュールと呼ぶ必要があります。モジュールは、より大きな粒度の関数として理解できます。モジュールには、公開された通話インターフェースと、観察可能な外部応答もあります。

プログラミング言語の観点から見ると、モジュールは、Pythonモジュール、Rustモジュール、Javaパッケージ、C ++の複数のクラスのセット、またはC言語の高度な相関関係を持つ1つ以上のコードファイルと同等です。

モジュールテストの焦点は、モジュールの応答が異なる入力条件下で正しいかどうか、およびモジュールの内部状態が正しいかどうかです。

単体テストとモジュールテストは、一般に、C ++さびを記述するために使用されるGTESTなどの特定の単位テストフレームワークを使用して記述できます。また、コードがコーディング標準に準拠しているかどうかを確認し、コードの環状複雑さを確認し、潜在的なコードエラーを分析するさまざまなコードチェックツールもあります。

ユニットテストとモジュールテストの作家は、機能モジュールまたはそのチームメンバーを開発するプログラマーです。一般的に言えば、プログラマーが毎回コードを送信する前に、関連するモジュールのユニットテストとモジュールテストコードを実行して渡すことができるはずです。すべてのコードの変更について、すべてのモジュールに関連付けられた単位テストコードを再実行する必要があります。

通常、テストフレームワークの機能に応じて、ユニットテストとモジュールテストのシミュレーションデータは、外部からロードできます。

残念ながら、ユニットテストとモジュールのテストは非常に重要です。その理由は単純で、プロジェクトはきつすぎて時間がありません。単体テストの欠如は、コードの操作に影響を与えません。これは、一部の状況がテストされていないことを意味します。

サブシステム

モジュールの上にはサブシステムがあります。サブシステムは、「ビデオ取得サブシステム」、「車両識別サブシステム」、「駐車パス計画サブシステム」、「ユーザーインタラクションサブシステム」など、特定の側面を完了できる機能システムを表します。 Linuxカーネルのドライバー、アプリケーションレイヤー上の独立したプロセスまたはSOAサービス、MCU RTOに関連する1つ以上のタスク、CP AutosarのSWCなどが存在する場合があります。

モジュールテストと同様に、サブシステムには一般に、外部入力に応じて正確性をチェックする必要がある内部状態があります。

サブシステムは、個別にテストできる必要があります。つまり、テストループで独立して実行および検証することができます。次に、より多くのシステムをテストループに1つずつ追加し、最終的にシステム全体を形成します。

サブシステムテストとモジュールテストの違いは、モジュールテストのアクセスインターフェイスが一般にAPIレベルにあることです。つまり、モジュールのAPI関数がテストフレームワークによって直接呼び出されることです。サブシステムのインターフェイスは、多くの場合、他のサブシステムとの相互作用であり、さまざまなネットワーク（Can、Flexray、Ethernetなど）または共有メモリやセマフォなどのプロセス間通信メカニズムを介して行われます。

これは、サブシステムテストがモジュールテストと同じツールを使用できないことを意味します。サブシステムテストには、シミュレーションデータを提供するだけでなく、シミュレーションデータをサブシステムに送信する方法とサブシステムの応答結果を検出する方法も必要です。

サブシステムテストでは、一般に、いくつかの特別なツールの購入といくつかのツールの開発が必要です。購入したツールには、多くの場合、バスシミュレーションクラス（カヌーなど）があります。 Ecutestなどの全体的な自動テストフレームワークもあります。ロボットフレームワークなどのオープンソースの代替品もあります。自己開発ツールは、購入したツールを接続したり、特定のデバイスまたはサブシステムインターフェイスのドライバーを開発できる必要があります。

「公開および購読」デザインパターンは、サブシステムテストに重要です。「公開および購読」モデルはメッセージプロデューサーと消費者を分離しているため、サブシステムをテストすると、サブシステムが同時にデータを送信する必要があることを簡単にシミュレートできます。

自律運転、Baidu Cyber RT、DDS、またはSOAの一部/IPの基本的なプロトコルで一般的に使用されるミドルウェアROS/ROS2であるかどうかにかかわらず、それらはすべてパブリッシュサブスクライブモデルをサポートしています。

均質で不均一な

自律運転システムは不均一なシステムです。ハードウェアには、高リアルタイムMCUと高性能の多機能SOCチップが含まれます。 MCUはRTOSシステムを実行し、LinuxまたはQNXがある場合はRTOSシステムを実行することもできます。 SOCには、一般的なCPU、レンダリング用のGPU、数学計算用のDSP、および各パートのソフトウェア実装方法も異なります。

ユニットテスト、モジュールテスト、さらにはCPUベースのサブシステムをX86開発デバイスでテストできます。ただし、サブシステムに組み込みプラットフォーム用の専用機器が含まれる場合、その真の効果、特にそのパフォーマンスは、ターゲット組み込みプラットフォームでのみテストできます。通常、それをループでプロセッサと呼びます。

したがって、テストループおよびテストツールシステム全体では、組み込みプラットフォームのサポートを検討する必要があります。

図5テストとシミュレーションの種類

xループで

不均一サブシステムの統合テストが非常に特別であることを除いて、上記のテストの概念は一般的なソフトウェアテストとそれほど違いはありません。自律運転システムのテストで特別なのは、さまざまな形のループ内テストです。

セクション1.2.3の閉ループAは、ループ（MIL）の典型的なモデルであり、閉ループCはループ（SIL）のソフトウェアであり、実行のソフトウェアコードを生成します。

重要なポイントは、Simulinkモデルが迅速なプロトタイピング機器で直接実行され、シミュレーションソフトウェアがセンサーの真の値データを直接提供することです。言い換えれば、シミュレーションソフトウェアは、実際の真理値を入力として直接送信するためのシーンアニメーションをレンダリングします。

前述の不均一なサブシステム統合テストは、ループインプロセッサテストの一種です（PIL、ループのプロセッサ）。不均一サブシステムの統合は、複数のサブシステムを徐々に統合できます。視覚アルゴリズムがターゲット組み込みプラットフォームプロセッサでも実行され、視覚データがシミュレーションソフトウェアから抽出され、ネットワークを介して埋め込みプラットフォームに送信される場合、PILとMILのハイブリッドモードです。この時点で、シミュレーションソフトウェアによってレンダリングされた画像は、埋め込みプラットフォームで実行されている視覚アルゴリズムが画像に基づいてターゲットを認識し、それをSimulinkモデルに送信します。純粋なMILと比較して、この映画はより多くのコンテンツをシミュレーションクローズドループに統合します。

ループの標準ハードウェア（HIL、ループのハードウェア）は、正式な大量生産ECUハードウェアを使用することであり、データとECUハードウェアの対話は実際の車と同じでなければなりません。車両の周りの環境は、ECU自体の観点からシミュレーションを通じてシミュレーションされていますが、シミュレーションテスト環境にあるのか、実際の車にあるのかを判断することはほとんど不可能です。このようにして、テスト環境全体が実際の車両に近いです。

PILテストでは、元の画像データが必要な場合、画像データは一般にビデオファイルを再生し、ネットワーク上でターゲット埋め込みプラットフォーム（ECU）に送信されます。このようにして、ECU取得モジュールもテストクローズドループに統合されています。もちろん、このビデオデータをシミュレーションソフトウェアからECUビデオポートに記入するには、特別なハードウェア機器が必要です。これがHil Mountが行うことです。

ループの車両（VIL、ループ中の車両）は実際には非常に近いものですが、HIL機器の完全なセットは、コントロールアルゴリズムの実行は、シミュレーションソフトウェアの動的モデルではなく、実際の物理的な車両の制御システムに基づいている必要があります。シミュレーションソフトウェアは、シミュレーションされたシーンをECUに注入します。これは、VilとHILの違いは、実際の車両制御システムを使用していることです。

表2に、さまざまなテストとシミュレーションの定義と説明を示します。

表2さまざまなテストとシミュレーションタイプの比較

2製品レベルの閉ループ

前の章では、R＆Dの閉ループについて説明し、R＆Dとの相乗効果とテストシミュレーションについて焦点を当てています。この章では、製品の観点から説明します。

自律的な運転システムは非常に複雑なシステムです。これは非常に複雑であり、従来の意味での製品マネージャーが開発されるシステムを正確に定義できません。私は2年間の採用の後、自動運転の製品マネージャーを募集したい企業に会いました。一部のJDは、製品マネージャーにほぼすべての要件を持っています。これは、上海人民広場の叔母の結婚要件に非常に似ています。

なぜ自律運転の分野にある製品が定義するのがそんなに難しいのですか？単一の製品ではないため、一連のソフトウェアとハードウェアのサブ製品で構成される高度に複合製品であり、同時に「車両」のより複雑な製品に組み立てられます。その後、車両は無限の可能な交通シナリオで移動します。言い換えれば、自律運転製品は、少なくとも内部構成の複雑さ、アセンブリ環境の複雑さ、使用シナリオの複雑さなど、複数の複雑さによって重ねられています。

この製品を分析するときは、複数のマルチレベルのサブプロダクトに分解し、各サブ製品を分析し、各サブプロダクトが完全なシステムを形成する方法を分析する必要があります。各サブ製品には、独自の懸念、技術分野、および独自の独立した進化方向があります。サブ製品には複数の代替オプションがあります。

私の他の記事「ソフトウェアアーキテクチャとインテリジェントな駆動ドメインコントローラーの実装」（パート2）では、製品の分解に関連する2つの写真を描きました。「図6ソフトウェアアーキテクチャの鳥の航空ビュー」は、3次元の分析と各レイヤーの関数については、自動運転ドメインコントローラー内のソフトウェア構成を示しています。この記事では、これに基づいて内部サブ製品の分解を分析します。「図7レベル4の製品アーキテクチャ」は、図6に基づいて自律運転ツールチェーンシステムに拡張され、自律運転との相関関係に3階建ての階層分解を内側に実行します。この記事では、ツールチェーンシステムにもっと注意を払います。

図6ソフトウェアアーキテクチャの鳥の航空ビュー

図7レベル4製品アーキテクチャ

2.1製品の各層の独自性

図6の水平方向の「階層」ディメンションでは、各レイヤーの各ドメイン（パフォーマンスドメインまたはリアルタイムドメイン）には、独自のユニーク性があります。

「製品」の概念

「製品」の概念の定義が必要です。一般的に、私たちが理解している「製品」は、コーヒーマシン、携帯電話、車、ブラウザ、音楽プレーヤー、WeChatアプリなどのソフトウェア製品などのエンドユーザーの観点から見られます。

図8に示すように、製品の概念を抽象化します。

「車」を製品と見なし、その特性は「100 kmの加速時間、大きな音声制御スクリーン、バレット駐車機能、自動レーン変更機能」などです。「ステアリングホイール、ダッシュボード、ブレーキ、アクセラレータ」などのインタラクティブなインターフェイスを提供します。

「埋め込まれたLinux」は、「さまざまな周辺のスケジューリング、メモリ管理、情報セキュリティ、通信機能など」です。

これらの2つの例が非常に異なっている領域ですが、どちらも製品です。

図8製品の概念の例

図9に示すように、製品のインタラクティブなインターフェイス、特性、および特定の技術分野はすべて製品の意味合いであり、製品の機能と外部相互作用方法を決定します。しかし、製品には独自の拡張概念もあります。

図9製品概念の意味と拡張

製品の拡張には、少なくとも市場のポジショニング、適用可能な機会などが含まれており、製品にはある程度の独立性も必要です。いわゆる独立は、その設計、研究開発、販売が他の製品から独立して実行できることを意味します。たとえば、テーブルを独立して販売することはできますが、テーブルの脚だけを販売することはできません。

製品の意味合いと拡張も密接に関連しています。たとえば、製品の独立性は、その外部相互作用インターフェイスと密接に関連しています。

製品の独立性

自律運転システム内のサブ製品の構成は非常に複雑であるため、各サブ製品の独立性を拡大することが非常に重要です。各サブ製品は比較的独立したチームによって開発でき、一部のサブ製品は市場から直接購入でき、さまざまなサプライヤーの製品に置き換えることができます。

自動車OEMのサプライチェーン管理のお気に入りは、同じ部品の複数のサプライヤーがいることです。単一のサプライヤーが供給できない場合は、生産の停滞を避け、価格の良い交渉の位置もあります。

SAICは、本質的にこの製品の独立の問題である独自の「魂」を習得する必要があると述べました。自動運転システムにはドメインコントローラーハードウェアとさまざまなセンサーハードウェアが必要ですが、本質的にはソフトウェア集約型製品です。内部コンポーネント（ソフトウェアサブプロダクト）のセグメンテーションは、元のハードウェアコンポーネントほど明確ではありません。主にテクノロジー企業のサプライヤーは、ソフトウェアとハードウェアソリューションを統合するか、少なくともソフトウェアに全体的なソリューションを提供する傾向があります。 Automotive OEMSは、ソフトウェアとハードウェアを分離できることを望んでおり、同時に、ソフトウェア構成の独立したサブ製品に分割することをお勧めします。

製品の意味合いの「特定の技術分野」は、製品の独立性の特性を反映することもできます。図6の製品の技術分野は大きく異なり、関連するR＆D担当者の専門的スキルも大きく異なり、開発方法とテスト方法も非常に異なります。たとえば、埋め込みシステムのLinux開発をカスタマイズしているエンジニアは、Linuxのアプリケーションの開発に熟練しているエンジニアとは非常に異なるスキルを持っています。したがって、これらのさまざまな製品には、独立して設計および開発するために、さまざまなスキルと背景のチームが必要です。

オペレーティングシステムレベルの製品を定義するためにユーザーレベルの製品を設計するプロダクトマネージャーを見つけると、彼は有能ではありません。オペレーティングシステムで非常に経験がある専門家に、自律運転の特定の機能とシナリオを定義するように依頼しました。また、多くの知識を追加する必要があります。つまり、時間がかかることを意味します。

2.2国境を越えた製品進化ルート

サブ製品の独立性により、図6の製品が独立して進化し、完全な顧客配信製品に組み合わせることができます。

水平に階層化された製品の進化経路

図10は、各レイヤーの生成物の進化方向の可能性を示しています。たとえば、「コンピューティングプラットフォーム」では、X86の産業制御コンピューターまたはXavierキットを使用して、R＆Dの初期段階で必要なソフトウェア機能をすぐに開発できます。

対応するオペレーティングシステムのレイヤーでは、Ubuntuは開発者の環境を一貫させるために直接使用します。自動運転のSOCチップのパフォーマンスがより強く、より多くのコアになると、対応する仮想化テクノロジーとコンテナテクノロジーも最初に開始し、次に将来の製品に使用できます。

図10水平層状製品進化ルート

ミドルウェアレイヤーでは、一般に、ROSまたはROS2に基づいた最初のプロトタイプシステムの開発に慣れています。次に、Adaptive AutosarやBaidu Cyberrtなどの大量生産に使用できるミドルウェアに頼ります。

垂直製品ポートフォリオパス

図10の各層は、左から右への単一層の積の進化ルートです。ただし、製品の単一層は、完全な自律運転システムを構成することはできません。製品全体を統合する前に、製品の特定の層が成熟するまで待つことは不可能です。代わりに、システム統合が早ければ早いほど良いことを願っています。

図11は、それぞれが上から下までのルートを介して、可能な製品統合の組み合わせであるさまざまなシステム全体の統合ルートを示しています。

パス①および②は、セクション1.2.3の「閉ループA」および「閉ループB」に正確に対応しています。

PATHは、R＆D、オペレーティングシステム、およびコンピューティングプラットフォームの初期段階でのプロトタイプシステムシミュレーションです。自律運転のスタートアップが資金を調達するために使用する初期のシステムのほとんどは、このようなものです。

PATHは、典型的なハードウェアインループシミュレーションシステムであり、ハードウェアからオペレーティングシステムとミドルウェアまで、すでに製品ベースのソリューションです。

PATHは、すべて大量生産された製品です。最終的なターゲット製品は異なるため、各層で使用されるサブ製品も異なります。 PATH⑦は、リング中のシミュレーションシステムです。

ニーズに応じて、さまざまな統合パスを設計することもでき、各パスは実際に独立した製品開発閉ループを移動します。通常、私たちは最も単純なパスから始まり、徐々に変数を増やして、大量生産と配信の最終製品形式を達成します。

図11垂直製品ポートフォリオパス

製品計画の閉ループのアイデア

水平層化は、製品の各層の相対的な独立性によって決定され、垂直の組み合わせは完全なシステムを形成するための避けられない要件です。一般的に、製品を計画する場合、企業は最終製品フォームにもっと注意を払い、結局のところ、最終製品を商業的に配信する必要があります。

このようにして、現時点では適切な中間サブプロダクトがないか、サブ製品機能が配信要件を満たしておらず、再選択および適応する必要があるか、またはより多くの研究開発時間が必要であり、プロジェクトの進行が遅れることがわかります。したがって、製品を計画する場合、企業はサブ製品の計画に完全に注意を払い、水平方向と垂直の両方の視点からそれらを包括的に検討する必要があります。

水平方向の視点は、このサブ製品自体の開発を表しています。独立して描かれました。

垂直方向の視点は、サブ製品の進化における各ステップの機能的計画と優先度の設定に影響します。各垂直パスには異なる目的がありますが（一部はテストクローズドループであり、一部は最終配信閉ループです）、完全なフルプロセス閉ループです。中間サブプロダクトの縦方向の経路の要件は、この縦方向の経路の閉ループが動作できるようにすることです。したがって、サブ製品の水平発達ステップは、複数の垂直パスの要件と一致し、調整する必要があります。これは、サブ製品のロードマップを計画する場合、垂直統合因子を同時に考慮する必要があることを意味します。

サブ製品が未熟であるか、大量生産要件をまだ満たしていない場合、垂直パスを可能にするために、早期の交換を求めなければなりません。この段階でのサブプロダクトは大量生産に使用することはできませんが、上位レベルの製品の開発をうまくサポートしています。同時に、サブプロダクトのこの層の開発をスピードアップし、代替の一時的なソリューションの次のステップに向けて準備します。

水平方向と垂直方向の分解と組み合わせは、各層のサブ製品を独立して設計および開発できるようにし、すべての層を並列に開発し、垂直パスを介して徐々に統合できるようにすることです。したがって、サブ製品計画を含む、適切に設計された製品計画は、エンジニアリングの実装プロセス全体の迂回を回避できます。

3データ駆動型の閉ループ

高度な自律運転が徐々に現実に入ると、データクローズドループの概念がますます重要になり、多くの自律的な運転R＆D企業とOEMが独自のデータクローズドループシステムを確立したいと考えています。ただし、データのクローズドループと呼ばれる状態について明確な声明を発表することは、しばしば困難です。

ここには無視できる重要な概念があります。

前の2つの章では、R＆Dとテストのクローズドループと製品計画のクローズドループについて説明します。これは、製品とR＆Dの観点からの閉ループシステムです。ただし、大きな閉ループであろうと、小さな閉ループを介してデータを駆動する必要があります。データクローズドループがデータ駆動型のクローズドループであると言う正しい方法。

データの全体的なクローズドループについて明確に説明することは困難です。異なるタイプの閉ループの場合、異なる閉ループターゲットのため、データの流れも非常に異なります。データ駆動型の閉ループを分析するには、次の問題を明確にする必要があります。

データのクローズドループコンテキストのデータとは何か（データの概念）
クローズドループで必要なデータとデータの関数は何ですか
データの生成方法
使用前にデータの処理方法
知覚データ、真の値を取得する方法（グラウンドトゥルース）
データフローをサポートするためにデータの流れと閉ループにどのように流れるか、どのツールが必要ですか

この章では、最初に基本的な「データ概念モデル」を分析し、次にそのデータがいくつかの典型的なケースを介して閉ループの実行をどのように駆動するかを分析します。

3.1データの概念モデル

データ駆動型の閉ループについて説明しているので、まず「データ」の概念を明確にしましょう。この記事に記載されている「データ」は、自動運転システムの研究開発と運用に関連する情報要素を指します。この概念モデルを理解することにより、データの生成、処理、使用方法を理解しやすくなります。

この図の象徴的なセマンティクスは、UMLクラス図に基づいています。「ミドルウェアとSOA」のセクション3.1.1の簡単な説明を参照してください。写真のライトブルーボックスにはデータ概念モデルがあり、周辺は特定のデータカテゴリと関連するツールプラットフォームです。

多くの側面からのデータの属性を説明できます。別の観点から、これらの懸念は、「何が、どこから来たのか、どこに行くのか」に関するデータに関する3つの質問を説明しています。

分類に関しては、自転車データまたは環境データに分割された自転車との関係など、データにはさまざまな分類方法があります。画像データ、レーダー信号などに分割されています。

図12データの概念モデル

写真のライトブルーボックスにはデータコンセプトモデルがあり、一部の特定のデータフォームは周辺の左側にリストされていますが、他の赤は関連するツールプラットフォームです。左側の特定のデータフォームはセマンティックレベルのみを描画しますが、各タイプのデータには、コンセプトモデルのセマンティック改善、生産方法、使用方法などの概念の具体的な表現があります。図のレイアウトは表現するのが容易ではなく、後で詳しく説明します。

ここでは、最初に「セマンティック階層」の概念に焦点を当てます。これは、自動運転システムのデータの非常にコア属性です。

セマンティック階層

「セマンティクス」とは、特定の情報媒体から抽出する高次情報の意味です。たとえば、新聞には、インクが新聞を読むと、セマンティック抽出であるインク分布の意味を得ることができます。 NLP（自然言語理解）は、テキストからセマンティクスを自動的に抽出するコンピューターと見なすことができます。

セマンティクスは階層的であり、セマンティック階層の標準化された定義はありません。

「ゼロオーダーセマンティクス」は、セマンティクスのない元の物理的信号です。カメラの元のピクセルポイントコレクション、LIDARのポイントクラウド、およびレーダーによって受信された電磁信号後の元のデータなどがサンプリングされています。

「第1レベルのセマンティック」レベルは、元の物理信号に基づいて計算される属性機能であり、「何、何、はい/いいえ」という明確な意味を持っています。たとえば、速度、距離、場所など。測定単位または物理的な寸法。

“二级语义”是在一级语义上的进一步加工，有一下几种可能情况

两个2级语义的组合，如车在某个车道，两个传感器的后融合。
时空两个维度同时具备，如历史轨迹，目标跟踪。

“三级语义” 对目标意图的识别与判断，如当前行为意图，行为预测，轨迹预测

“四级语义”多个交通参与者在特定道路环境下一段时间内的行为

举例来说，摄像头输出的一帧图像，如下图：

图13 非法掉头的示例场景

图像本身实质上是YUV 或RGB 格式保存的一段二进制数据，记录里每一个像素点的光学采样值。这是没有任何语义信息的，是零级语义。

通过人眼识别或者AI 算法识别，我们从这一帧图像中提取出一辆乘用车、车道双黄线、还有“禁止掉头”的交通标志，这是几个独立的一级语义，互相之间没有关联起来。

根据车辆和车道线的相对位置，我们可以车辆压线，这是两个一级语义的组合。可以认为是二级语义。继续叠加双黄线的交通规则信息，可以认为车辆已经非法压线了；再叠加禁止掉头的语义，可以认为这是非法掉头。

假如对向车道有一辆车正在向图上的白车行驶过来，我们能测出其速度。那我们还能作出预测，这两辆车可能会相撞。这已经不是多个独立的一级语义叠加了，而是多个目标可能的关联分析，这可以认为是三级语义了。

图12中并没有画三级之上的高层语义，本文也不打算去定义更高层的语义，第三级语义的定义也值得商榷。因为语义分层的目的体现在工程上是给不同算法的能力划定边界，分层的方式也确定的各层算法独立进行闭环测试的闭环分解方法。比如，我可以单独为某个零级提升到一级语义的算法设计测试闭环，同时还可以直接提供一级的真值给另一个算法，它负责提取出二级语义。所以你完全可以根据你的算法集和的规划去定义自己的语义分级规则。语义分层是为了可以进行工程化的闭环测试。

语义提升

前面例子中从低级语义逐步提取到高级语义的过程就是语义提升。（图12中零级语义和一级语义中有一根线连接到“语义提升”，这在UML语义中表示关联类，就是说“语义提升”是跟两个高低语义层级相关）。人眼在看图13 时这个语义提升的过程是瞬间完成，人也不会意识到会有这个逐级提升的过程。但是在计算机来执行语义提升的时候，确实不同的类型的数据，不同层级的提升方法都有很大的差别。

图12中画出来三种语义提升的方式，人工智能(AI) ，人工标注，数字信号处理，还可以有更多的语义提升方式。这三个是比较具有典型性，数字信号处理主要是在对雷达原始数据的处理上，已经发展了很多年，图像和激光雷达点云采用深度学习等人工智能技术成为了主流。“人工标注”实际上就是一种语义提升的方式，它一样可以用在不同的语义层级之间。

“语义提升”对于低级语义来说是数据的使用方式，对于高级语义来说，是数据的生产方式。最直接的数据生产方式就是“数据采集”，直接采集原始数据。

真值系统

目前感知层面的深度学习主要是以监督学习为主，监督学习就需要数据的真值来进行训练。不同类型的数据，不同类型的算法训练，其真值形式也有很大差别。产生真值的系统称为“真值系统”。我们在设计生产用于AI 训练数据的同时，也必须设计获取其真值系统。

真值系统至少有三种：

人工标注
用更高精度的测量工具的结果作为低精度工具的真值
仿真软件直接输出真值

第1种就是靠人力去标注，比如百度就建设有上万人的标注基地，为很多自动驾驶公司提供标注服务。第2种，比如我们可以用激光雷达算法输出的结果作为视觉算法的真值，前提是激光雷达算法的精度足够。仿真软件的真值是可以直接输出的，这在我们设计测试闭环的时候非常有用，可以让我们在算法成熟之前就建立起算法或其它软件模块的测试闭环。

为数据生产服务的工具平台

各级语义数据的生产，算法的开发，离不开一系列的工具平台的支持。清楚了数据的抽象概念模型，也就能更清楚的理解工具平台的作用。相关的工具平台如图12所示：

数据采集系统要支持各种传感器数据车身数据的实施采集，支持每天10T 级别的数据采集量，还要保证各种数据的时钟同步。

数据标注需要标注工具与平台，提供各种类型的数据标注功能、支持标注质检，支持成千上万人分布式工作、对任务和人员进行调度管理。

要为各种不同类型的数据，提供符合算法要求的真值系统。

AI 训练平台要能支持成百上千的计算卡进行分布式训练。

测试仿真平台要能利用各种语义层级的数据形成多样化的测试闭环。

需要一个统一的数据管理平台对数据从导入、存储、清洗、加工、筛选、利用进行全生命周期的管理。

这些相关的工具平台也会在后文的合适章节单独进行论述。

3.2 假设的系统方案

AEB （Autonomous Emergency Braking）是典型的L1功能，就是自动紧急制动，避免撞上前方的车辆、行人或其他障碍物，或者至少降低速度后，减少撞击之后的伤害。当然这只是非常简单的描述，详细的功能描述可以写出500页出来，这里不多说。

我们假设一个能支持AEB 功能的系统方案，包含简明的软硬件架构，这个方案有最足够的传感器和足够的计算能力，不过我们只关注AEB 一个功能。但尽可能穷举出所有可以细分的工程环节，包含各独立子产品开发、分步集成、仿真测试、量产后根据回传数据持续迭代等。

这个系统方案不会出现在任何企业的实际产品中，因为方案的硬件配置只实现一个AEB 功能从成本来说太不划算，过于细分的工程环节只用于开发一个功能太过奢侈。

这个案例的意义在于可以提供一个方法论模板，让我们先不陷入复杂的自动驾驶功能里，而是从开发单一功能的视角分析工程化过程，让功能尽量简单，以凸显工程化的脉络。在后续叠加更多的自驾功能时，其实就是在这个模板的各个环节横向增加内容，而工程化的原理还是一样的。

我们假设的AEB 功能的系统方案，关键硬件组成：

写真

旁注：部分使用Smart Sensor简化HiL 实现

方案中雷达使用Smart Senor ,直接输出检测到的目标列表。此案例先关注在视觉算法上。实际产品可以直接把雷达信号处理运行在ECU中的MCU 上，MCU 要负责对雷达回波的物理信号进行采样。但这样在对ECU进行HiL 测试时要模拟雷达回波，难度很大。此案例雷达用Smart Sensor 以简化后面的说明。
smart sensor 在这里指的是直接输出感知结果的器件。比如mobile eye 的摄像头，芯片算法镜头都集成在一个设备里，通过can 输出。毫米波雷达也很多是这样供货，雷达器件里面集成了芯片算法，can输出目标列表信息。L2的开发很多就是这样选传感器，还可以把ACC这些功能直接运行在雷达的CPU某个核心上。这些都算smart sensor.
L2.5往上会逐步倾向于把这些算法的执行放在集中的域控制器上。传感器就只做物理信号捕捉，就不那么smart了

然后我们还有专业采集车，专业采集车上安装一个64线的激光雷达，输出点云(零级语义)。

3.3 各层级数据语义的独立研发闭环

图14 算法的语义层级划分，这张图中把AEB 功能可能涉及到的各种算法按照语义层级进行划分。这是一个工程化视角，并不是一个算法实现原理的视角。这里所谓工程化视角，是指可以比较方便的把每个算法单独开发，单独测试。

比如雷达目标和摄像头目标都是一级语义数据，我们需要这两个一级语义数据做的融合算法。可以直接在仿真软件上做传感器模拟，基于仿真软件输出的一级语义进行开发。这样我们可以在雷达算法和摄像头算法都不具备的情况下，先进行融合算法的开发。

好的仿真软件，可以提供各级语义的模拟数据，可以在模拟数据上加噪音，同时还能直接提供真值。这些可以满足各层算法的前期开发需要。

所以各种算法的独立开发再逐步集成的过程，是沿着语义层级的边界进行的。下面我们梳理一下图14中各层级的算法。每个算法我们会关注其要达到的目的、语义层级、以及数据来源、和真值数据产生的方式。这篇文章不会关注具体算法的实现原理。

图14 算法的语义层级划分

3.3.1 “0级语义处理”独立开发闭环

ISP 算法独立开发闭环

最典型的0级语义处理是ISP（图像信号处理）算法。摄像头传感器输出的图像质量会受到环境的明暗程度、相机的对焦、曝光时长等很多方面的影响。视觉算法的效果重度依赖摄像头获取的图像质量。尤其现在自动驾驶系统安装量越来越多的摄像头，ISP算法的重要性就很突出了。

ISP 算法一般由专用芯片来执行（或者ISP 硬件模块集成在某个SoC）中，算法根据情况还会对镜头或Sensor进行反馈控制。常见的ISP算法至少包含“格式转换、3A(自动白平衡，自动对焦，自动曝光）、噪点消除、宽动态(WDR)、白平衡调整、颜色校正、锐度调整”等。

旁注：关于ISP 算法能力

有三类厂商非常看中ISP 算法能力。一类是摄像头厂商，为了便于销售往往把ISP 芯片集成在摄像头内部，调试好图像效果后整体出售，这样客户也方便。另一类是视觉算法开发厂商，因为算法严重依赖ISP 效果，所以他们会非常看中ISP 的效果，要么与摄像头厂商深度合作，要么自己参与研发。第三类是用于自动驾驶的SoC 芯片厂商。因为自动驾驶系统需要很多摄像头，如果把摄像头中的ISP 芯片放在SoC 内部，可以大大降低摄像头的成本。SoC 芯片厂商为了让芯片有竞争力，也会开发ISP算法。具体项目中，ISP 的能力具体由谁来提供是一个重要的待决策事项。

摄像头的畸变矫正算法、传感器的前融合算法也都属于0级语义的处理，理论上都可以采取类似的处理方式，但是具体算法还是有各自的差别。

3.3.2 “0->1语义提升”独立开发闭环

激光雷达算法独立开发闭环

激光雷达可以生成3D点云，线数越多，点云越稠密。相对摄像头和毫米波雷达，更能精确的测量物体在3D空间中的位置和形状。所以基于点云可以做一系列的感知算法，包括目标检测、分类、跟踪、语义分割、SLAM 定位等等。

本AEB案例的系统方案主要使用视觉方案，不使用激光雷达，但是一个良好的激光雷达算法可以协助进行视觉数据的自动化标注，也就是将激光雷达算法的输出作视觉算法训练使用的真值。所以本例的专业采集车配备激光雷达。

旁注：关于仿真软件的传感器模拟

交通场景仿真软件是可以知道整个场景的真值信息的，包括场景中的建筑物、道路、各种车辆、行人等交通参与者，其位置、速度、行为都是仿真软件都是知道其绝对真值的。我们看到的逼真的3D视觉效果就是根据真值渲染出来的。相当于仿真软件具备了完全的上帝视角。我们要模拟一个真实车辆上的摄像头，就需要在仿真软件的自车对应位置设置一个同样参数的摄像头。参数包括安装的位置、摄像头的像素、FOV，畸变效果等等。仿真软件还要在其全知全能的上帝视角中，过滤出该摄像头“应该”能看到的局部场景信息并输出。输出可以有0级语义或1级语义。对应摄像头，0级语义就是符合摄像头参数允许范围内“看”到的局部图像。仿真软件要根据真值渲染出这个局部图像输出。输出1级语义就是从全场景真值中过滤出这个局部的真值。其他传感器的模拟也是类似原理。只是不同传感器的0级语义模拟时，要根据局部真值转换成该传感器对应的信息形式。所以仿真软件中一个模拟的传感器本质上是整个场景信息的一个过滤器。

视觉算法独立开发闭环

对本例的AEB 功能来说，视觉算法主要做的工作是目标识别与分类、目标跟踪、视觉测速、车道线识别等等。下表列出了四种不同的数据来源方式来完成视觉算法开发。

这四个方案都可以支持视觉算法独立的进行开发和训练。但从左到右，是从原型系统到真正量产可用的过程。数据量越来越大，需要的资源也越来越多，成本也越来越高。体现了一个单体算法开发从起步到真正实用的过程。

旁注：关于联合标注

数据采集的时候如果同时采集激光雷达数据和视觉数据，只要两个传感器数据的时间戳能够做好同步，并标定好相机和雷达之间的位置关系参数，那么标注激光雷达数据的同时是可以连带视觉图像数据一起标注的，称为联合标注。如图15所示是联合标注工具。我们可以看到在激光雷达点云上标注的车辆，同时在左后相机上也被标注出来。因为点云是3D 空间，所以可以在三视图上对标注框做更精细的调节，转换到视觉图像上，就是一个贴合非常好3D Bounding Box。这样我们为激光雷达数据标注真值数据时，可以同步标注图像数据的真值。

图15 激光雷达与视觉的联合标注（图片由百度标注团队提供）

3.3.3 “1-2级的语义提升”独立开发闭环

此AEB案例中，1级到2级到语义提升算法可以包括：

后融合算法：根据毫米波雷达输出的目标和视觉算法输出的目标。

目标跟踪算法：在连续多帧数据中跟踪单个或多个目标

基于车道线的车体定位：判断车辆与车道的关系

主要目标选择算法：从多个目标中筛选当前最重要的关键目标

这些算法的数据方案基本类似，如下表：

3.3.4 “2->3 级语义提升”独立开发闭环

轨迹预测与行为预测的独立开发闭环

AEB 功能对于选定的主要目标，要判断其危险性，需要做“轨迹预测”和“行为预测”。我们认为这是2级到3级到语义提升。

旁注：关于“轨迹预测”和“行为预测”

“轨迹预测”和“行为预测”在AEB 中并不是必须的，目前实际量产的AEB 功能，多数并没有做，或者并没有明确的有这两个模块。一般在AEB 功能的“危险程度评估”阶段，会对主要目标的速度和方向做一些判断，并不会去做较长时间（比如5秒以上）的轨迹预测。因为AEB 功能如果需要被触发，从触发到执行的时间非常短，从预警(声音)到舒适性制动再到紧急制动的过程一般会在0.5-3秒内完成。从保守的安全性考虑，决策时不考虑目标未来的轨迹和行为，会减少漏报的可能性。如果能在足够的数据支持下增加“轨迹预测”和“行为预测”理论上可以减少误报率(幽灵刹车)。所以这两个算法的开发应该作为AEB 功能持续改进时的切入点，而不是一开始的重点。Level 4 以上高阶自动驾驶中“轨迹预测”和“行为预测”的重要性就非常大了。

3.3.5 “2和3级语义利用”的独立开发闭环

对于本例的AEB 功能来说，“2和3级感知语义的利用”就是基于它们执行车辆的控制的行为“舒适性制动”和“紧急制动”。

这正好是“图4 车辆控制算法开发闭环演进”说阐述的内容。

3.3.6 独立闭环与执行环境

图16算法开发的独立闭环与执行环境

通过上面的分析，我们可以发现一个特点，各层以及层级之间语义提升的算法可以独立开发，但是可以在不同的执行环境中开发，从便捷的仿真环境，逐步到更贴近真实场景的实车环境。

仿真环境数据和真值获取方便，便于建立初始研发闭环。实车环境跟真实量产的执行环境最为接近。

如图16所示，几个不同语义层级的算法都可以独立进行开发（对低级语义的数据需求使用替代性方案），同时还可以在不同的执行环境中运行，包括纯软仿真环境、HiL台架、 ViL 仿真、实车环境等等。如前文所述，每种环境的数据来源、真值方案各有不同。完成从原型开发逐步向量产质量的过渡。

各种环境都需要一定的IT 底座进行支持，越接近量产，数据规模越大，IT 底座的资源也越多。同时需要一系列的工具链支持，包括仿真软件、台架系统、采集系统等等。

3.4 智能驾驶系统集成的一般原理

各算法模块能够独立进行开发和测试了，那么下一步就是如何进行集成。

3.4.1 集成的三个维度

可以从三个纬度去考虑集成过程，为了能小粒度的准确的表述集成的演进路线，我再把每个纬度分层三段，如图17：

算法串接（单体算法局部闭环全程闭环）
执行平台（原型平台、工程平台、量产平台）
数据规模（少量数据、大量数据、海量数据）

图17 三个纬度看待系统的集成

本文会出现“执行平台”和“执行环境”两个概念，这里做一下定义。“执行平台”是自动驾驶算法和软件的运行平台，包括硬件平台(MCU + SoC)、操作系统、中间件等。“执行环境”是执行平台及其所运行的外在环境，外在环境包括传感器、车辆以及交通场景。外在环境主要有实车道路环境与仿真环境两类，也有实车+仿真道路的模式(ViL)。

3.4.2 算法串接

“算法串接”很容易理解，图14中列出的多个算法可以连接在一起。比如，我们在仿真环境开发毫米波雷达与视觉的融合算法，两个一级语义的数据都可以由仿真软件给出，那么这个研发闭环就是“融合算法在仿真环境下的单体闭环”，实现的是1->2级语义的提升。

如果把视觉算法加入这个闭环，也就是让仿真软件输出渲染图片，用训练好的深度学习模型进行推理，计算得到车道信息和目标列表，再跟雷达目标进行融合，这样就把0->1, 1->2 两级语义提升连接在了一起。但还没有完成全部AEB 的流程，所以只是“局部闭环”。

局部闭环是一个逐步叠加的过程，一个个算法模块或功能单元逐步被纳入到执行平台中，直到把图14中的所有算法连接在一起，形成仿真环境下的从感知到控制执行的全流程，称为“全程闭环”。

3.4.3 执行平台

如果系统都集成是在仿真环境下执行的。整个过程完全没有使用任何将来会安装在车上的元器件。那么这执行平台只是一个“原型平台”。对应与图16中的“全仿真执行环境”平面层。

“原型平台”不光可以基于仿真建立，在实车环境也可以。我们可以用两个Smart Sensor（内置算法直接输出目标信息摄像头和雷达器件）提供一级语义来开发融合算法，这是单体闭环。如果去掉视觉Smart Sensor,换上我们自己选用或开发的“摄像头+ISP+视觉算法”提供视觉目标，这就到了局部闭环。我们再加上控制算法，使用快速原型设备控制真实车辆，就可以形成全程闭环。（参见1.2.3中的闭环B）如果视觉算法运行在x86 工控机上，那这个执行平台也没有任何用于量产的元器件。

我们接着对上面的执行平台进行改造。我们去掉快速原型设备，如果我们自己的设备(ECU/域控制器/计算平台/智能大脑等等目前流行的各种叫法) 还未就绪，那么可以使用已选定的MCU 的开发板运行实时域程序，用选定的AI 芯片的开发板运行视觉算法（参见1.2.3中的闭环D），这时候，整个执平台中就有了我们用于量产的元器件，我们认为它是一个初步的“工程平台”。

工程平台也是一个逐步累积的过程，比如我们用自己的计算平台设备的样件替换掉了前面两个开发板，这就往前跟进一步了。最终我们的执行平台就是正式量产的计算平台设备，成为“量产平台”。

各执行平台都可以基于仿真来运行（参见1.2.3中的闭环C），量产平台一样可以基于仿真来运行，一般意义上的HiL 测试就是这种模式。ViL 测试既可以基于原型平台，也可以基于量产平台。

3.4.4 数据规模

说到数据闭环，数据规模是大家最关心的事情。因为无论是采集、存储、脱敏，还是数据的清洗、筛选、标注、训练，一旦上了规模，都是大把大把真金白银的投入。假如我们准备了100量专业采集车，配备全套传感器，全国采集了上千万公里的数据(这投入已经是10亿人民币量级了)，然后发现某个数据没有时间戳~~~~ 芭比Q 了

这里我把数据规模分为“少量数据、大量数据、海量数据”，这里不必纠结于字眼，多少本来就是相对的概念。名称只是一个代号，重要的是数据规模划分的逻辑。

少量数据

图17中把“算法串接、执行平台”的各自三段画在“少量数据”的平面上，也是为了表示“少量数据”的重要性。这个重要性就是“基于少量数据快速建立起'单体算法、局部闭环、全程闭环'分别在'原型环境和工程环境'的执行能力”。

我们可以通过仿真软件，提取数据建立基于仿真的算法串接闭环，包括算法串接的三个阶段。我们也可以用简化版本的采集车，先采集少量数据做算法验证，采集车也需要迭代到一个完整版本。即便有完整版本的采集车，也可以只是先采集少量初始数据，到底是多少，看你项目需要达到的目的，几万公里不多，几千公里不少。

但这些数据的目的是为了“建立原型环境和工程环境的执行能力”，这些能力体现在至少以下方面：

算法串接的各种局部组合到全程闭环都能在原型环境和工程环境运行起来（只关注能否运行，不关注准确性）
工程环境的各种形态可运行能力经过了实际数据的检验
工程环境的各种形态能对不同的算法串接组合做自动化测试
工程环境执行中产生的日志数据可以进行回放，便于分析问题
为采集到的数据建立了标准的处理流程，基于各种数据处理工具（数据脱敏、清洗、筛选、标注、训练），建立了数据生产并推动算法提升的能力
建立了可弹性扩展的IT 基础设施，弹性体现在算力、存储等方面，也就是IT 基础架构具备，可以随时扩容

简单来说，就是“用少量数据建数据处理能力，为大量数据驱动做准备”。

大量数据

数据处理能力建立并得到验证，就可以投入大量资金去提升数据规模。这个时候只要资金够，就可以投入几百台采集车，获取上亿里程的数据。用数据去驱动各种算法快速成熟可用。所以少量数据的时候关注点是算法可执行，大量数据阶段关注的是算法的正确性和执行性能。这个阶段完成，整个系统具备了量产装车的可行性。

膨大なデータ

但是就算有几百台采集车，司机驾驶行为的多样性依然不够；上亿里程，也不能覆盖所有的长尾场景。这时候就需要通过量产车辆在合适的时机触发数据采集，回传数据到数据处理平台。

假设有10万量产车具备数据回传到能力，只要设置了合适的采集触发规则，我们就可以针对特定的兴趣点（感兴趣的环境、自车行为、交通场景等）获取海量数据。这个海量不仅仅体现在数据容量上，更体现在数据多样性上，10万不同的司机，遍布在几乎所有可能的道路环境，发生任何事情都不奇怪。

一般来说，我们会把通过大量数据验证的软硬件系统部署到量产车上，但是以“影子模式”运行。也就是全部的传感器都开启、所有涉及的的计算都正常执行，但是到控制车辆的最后一步放弃执行，改为触发数据回传。

这样通过海量数据挖掘出长尾场景，这些场景的数据经过加工后，可以在合适的工程环境中回放，分析、复现问题并验证修复的结果。改进后的软件OTA 到量产车辆，再重复这样的循环。经过一段时间的迭代，长尾场景的数量收敛到一定程度，相同触发条件下的数据回传量也会减少，那么在合适的时机，就可以在量产车上关闭影子模式，真正启用功能的执行。

综上所述，数据规模三个阶段的作用，总结来说就是以下三点：

用少量数据尽快建立起“单体算法、局部闭环、全程闭环”分别在“原型环境和工程环境”的执行能力，并能进行自动化回归测试。
基于专业采集获取的大量数据，驱动上述执行能力组合，快速迭代，达到量产装车的基本要求，保证影子模式能够执行
利用量产环境回传海量数据，并进行分析处理，提取长尾场景，补充训练、测试并改进系统，最终实现在量产车上启用功能。

3.5 AEB 功能的系统集成路径

上一节是一般意义的系统集成原理。现在我们回到我们的样例AEB 功能开发，看如何进行整体的系统集成。我们先基于少量数据，在“算法串接”和“执行平台”两个维度上进行集成。

图18显示了整个集成的过程。为了能在一页图上能放得下，我们还省略了一些更细节的步骤，不过图上显示的部分已经足够说明整体的集成思路了。

因为整幅图比较复杂，自定义了一套符号体系来表达，说明如下：

图上的实体符号有三类，“算法闭环”、“执行平台”和“工具集”。算法闭环的三个几段用三种颜色做了区分。每个算法闭环下有其依托的执行平台。整幅图从上到下分了三个区域以区分“原型环境、工程环境、量产环境”。工具集分为“仿真工具集”和“实车工具集”，以不同颜色区分，布局在图上两侧。

图18 理想化的AEB 集成（虽然图很复杂，但仍只是实际集成过程的简化表示）

图上的连接线三类，一类表示算法闭环的串接关系，一类表示执行环境如何使用工具集，一类表示工具集之间的关系。连线附近有关于其意义的文字说明。可以参见图例来识别符号含义。为了便于后文说明，算法闭环和工具集上有数字角标，用于在后文陈述中对其引用。

整张图主要有三条线索，“算法串接”和“执行平台演进”两条线索本身就是我们前面说的集成过的两个维度。另一条线索是“工具集的变化”主要体现了集成过程中不同阶段的测试环境和测试方法。这三条线索是交叉行进的，虽然图上的布局尽量体现了从上到下从原型开发到量产的过程，但依然在中间会出现很多交叉的过程，这也是感觉复杂的原因。我们理解集成过程时，也要顺着这三条线索去分析。我们从上到下，依次来说明（后续内容建议阅读时打开另一个页面，显式图18，随时对照）。

原型开发阶段

原型阶段的A1 （视觉算法） A2（后融合、目标跟踪、主目标选择）和A3（控制算法）三者之间是可以完全独立进行开发的。A1使用的是0级语义数据，A2使用的是1级语义数据，A3使用的是1级和2级语义数据。A1和A2都可以在T1、T2这两个工具集下进行闭环测试，T1、T2分别提供了仿真和实车的测试环境，提供算法需要的0级语义或1级语义。A1、A2、A3是典型的以语义分层为边界做的划分，使得各层算法可以独立、并行的进行开发和测试。

A1和A2串接起来成为A4，直接实现从0级语义到2级语义的提升。A3、A4串接起来形成A5。A5就已经是从感知到控制的全程闭环了。

A1~A5的执行平台虽然都算原型平台，但是也是有差别的。A1，A2，A4可以直接在PC 上进行开发，开发环境的建立成本会低很多。A3和A5涉及到对车辆的控制，一般都需要MBD (Model Based Development) 工具链和快速原型设备支持（参见1.2.3）。

A1~A5都可以在仿真测试环境或实车测试环境运行。同样的功能和执行平台能在两个不同的测试环境，一方面可以利用仿真降低研发成本提高效率，一方面方便建立自动化测试体系。

大多数自动驾驶系统的开发都是从原型阶段开始的，原型阶段的最终形态一般就是在在改装好的车辆后备箱安装一大堆设备，以x86工控机作为计算平台，驱动车辆演示一些自动驾驶功能。多数公司前期融资时就是这样的状态，但实际上这仅仅只是一个漂亮的Demo，距离工程化的量产，还差的非常非常远。

工程化阶段

工程化阶段的核心目标，直观来说，就是把原型阶段车辆后备箱里的那一大堆设备都扔掉。这要求硬件上要用能耗比高的计算平台替换掉工控机，要求具有高AI 运算能力、高实时性，还要能满足车载设备抗振、耐高低温、电磁兼容等要求。软件上从操作系统到中间件到自动驾驶软件架构，也有非常多的技术难点需要克服。同时，软硬件还要能满足汽车功能安全要求。所以工程化落地能否合理有序的推进，同时辅以一系列测试手段保证产品的质量，是自动驾驶技术能否落地的关键环节之一。

图18演示的工程化阶段的步骤仍然被高度简化了，但可以用来阐述一般性原理。具体到实际项目要做专门的工程化路径设计。

A5到A6的工程化动作是把快速原型设备替换为量产的MCU 平台来执行实时域的计算。相当于1.2.3节中的闭环B 演进到闭环D。A5和A6的仿真测试环境和实车测试环境是一样的。这也是符合最少变量原理，每次演进步骤尽可能做最小的改变。

A4到A7的工程化步骤是讲PC 平台替换为车载计算平台，这其实是一个很大的工程化动作。内部还可以进一步拆分层更小的步骤，比如A1，A2包含的4个算法可以单独向A7的执行环境移植，图上没有做这更细粒度的拆分。

A4和A7都不是全程闭环，因为没有对接车辆控制算法。A7的测试环境可以有很多种，技术人员从芯片的开发板开始，逐步迭代自己的硬件平台和基础软件，最终形成相对完整的计算平台。密集开发阶段，可能每个开发人员桌面都会有一个样件，专注调试自己负责对模块。

图18画的A7与T4形成的测试环境是比较接近开环测试（不包含车辆控制）能达到的最大测试跨度。T4是PiL（处理器在环）测试台架，主要测试软件和算法在目标嵌入式平台上的行为。PiL 比HiL 简单，可以包含仿真软件，也可以不包含仿真软件，这样成本很低，就可以在PiL 台架上同时支持多路目标设备，方便进行并行执行多个用例的自动化测试。

A6和A7 集成在一起就成为A8，A8在目标计算平台上运行完整的感知到控制的闭环。A8可以在HiL 台架（T5）上进行测试，也可以将HiL 台架小型化后再车上进行ViL 测试（T6），也可以直接实车测试（T7）。ViL 和实车测试录制的日志数据，应该可以在HiL 和PiL 台架上进行回放，用于分析和定位问题。

量产阶段

A8进一步工程化到量产装车的正式产品A9。A9与A8相比，增加的比较重要的特性在几方面：

A9要支持一定的OTA 能力，方便更新软件A9要与车辆环境深度集成并进行严格测试，比如电源管理、网络管理等。而A8只需要关心自动驾驶相关的功能、 A9需要能支持影子模式与数据回传。A10的产品形态并不是安装在车上，但是也把它放在了量产阶段，因为这就是它这种运行模式的最终形态。A10直接从A4进化而来，执行平台从PC换成了云平台。A10所依赖的执行环境T9为轻量化的云仿真平台。它不需要做0级语义的支持，这意味着不会做视觉的渲染输出，会大大降低单个仿真实例对计算资源的需求。一般来说，T9的渲染只需将1级及以上语义信息以线框图的形式呈现出来。比如我们经常能看到Apollo 开发平台仿真的渲染画面。

图19 场景渲染的线框图形式（图片来源于Apollo 官网）

T9的重要作用在于对场景的复现与测试，也就是在三级及以上语义基础上，验证对车辆行为的规划与控制。比如我们再A9回传到数据中发现了一个“鬼探头”的场景，就可以在T9仿真环境中设计复现这个场景，并将它加入到每日例行的回归测试中。

T9的另一个重要作用是并行仿真，后文详述。

3.6 仿真及测试工具链分析

可以看到，图18中包含了很多仿真和测试的工具链，这些工具链的存在对完成整个系统的工程化有非常重要的作用，以下简要列出来仿真及测试工具链在“工程化、高效率、一致性、可测性、精确性、可靠性”等方面的作用：

实现工程化的分阶段测试。研发不同阶段提供的测试环境T1~T9 ，也为出现问题时提供回溯分析的平台。
提高效率，节省研发资源。能在仿真上做的开发和测试就尽量在仿真上先做，至少先把算法或功能的流程通路先跑通，省得在实车测试出现这方面问题，就能节省实车测试时间。
验证不同环境下的一致性。对于能同时在仿真环境和实车环境执行的研发阶段，如A1~A6，A8 ，保证执行平台一致，仅需关注测试环境的不同。就可以在仿真环境中提早发现问题。也可以把实车环境的问题在仿真环境进行复现。
通过仿真系统模拟部分必须的数据，使得局部或全程系统达到可测性，尤其某些危险场景实车测试很难进行，就只能进行仿真测试。
软件系统的可靠性是需要持续不断的回归测试来支持的。理论上只要有代码（或AI模型)的更新，都应该执行回归测试。每次变更之后都要将之前的测试用例都重新测试一遍。必须要建立自动化测试机制才能高效率高频次的执行测试动作。大多数自动化测试只能在仿真环境进行。仿真是解决自动化测试的关键武器。
不同算法都必然有精确性的要求，这需要测试机制能够对算法的精确性提供测试和度量的方式。

分析和设计测试环境时，可以从以上几方面进行考虑。图18中T1到T9的测试环境都会体现上面几个特性的组合。但T1~T9也不能完全涵盖全部可能的测试环境，需要根据产品和项目的需求设计合适的测试环境。

同时从T1到T9各自的用途和侧重点有不同，产生的数据和对数据的利用方式也有不同。我们也可以从数据的语义层级出发对测试环境进行分析。

下面我们对几个重点的仿真和测试环境从“工程化、高效率、一致性、可测性、精确性、可靠性”以及与数据的关系方面进行一些分析。

3.6.1 纯软件仿真

图18中T1和T3是纯软件仿真。A1+T1 使用的是0级语义的图像数据，A2+T1 使用的是1级语义，不需要图像数据。这两个组合首先解决的首要问题是提高效率。尤其在开发前期，车辆环境还不具备的时候就可以进行开发。一台车辆从采购到改装至少两个月，还要找专业的有工程车测试资质的测试员来开，多个团队等着排队用车，会消耗很多时间在等待上。

要让T1具备对A1和A2 的可测性，要求T1的仿真软件具备“传感器模拟”能力和良好的“真值输出接口”。

传感器模拟

我们先区分两个仿真中的两个概念“地图”和“场景”。“地图”代表一个交通环境中的静态部分，包括道路结构(含桥梁隧道)、交通标志、静态障碍物等等。“场景”表示“地图”加上一段时间内交通参与者的行为，交通参与者包含自车（EGO Car）、其它车辆、行人信号灯状态变换等等。简单说，“地图”是静态的，“场景”是动态的。这两个词的意思或许在其它地方与这个定义有差别，但在本文，就是表示这个意思。

那么当一个仿真软件加载并运行一个场景时，它是有一个上帝视角，知道场景中所有事物（包括地图中的静态物体和场景中的所有参与者）的状态的。传感器模拟实质上是给这个全知全能的上帝视角增加一个过滤器。比如一个前置摄像头，给定了横向和纵向的视场角后，它就过滤掉这个视场角之外的环境信息，只把视场角内的环境数据输出出来。这就是传感器模在环境语义上的本质含义。

对于类似于A1和A2的开发需求，要看重仿真软件的传感器模拟能力。包括能够支持的传感器类型，每种传感器能够模拟的物理参数范围，执行性能上要能同时设置大量传感器而没有明显的延迟等等。

上帝视角的场景信息至少是一级语义，所以传感器模拟输出一级语义是非常自然的，反而输出0级语义（图像或点云或雷达信号），反而要经过额外的数据处理或渲染。

关于仿真软件的渲染效果

人们很容易关注仿真软件的3D 实时渲染效果，毕竟这是很容易被直接看到的，高逼真度类似游戏的场景渲染，确实很震撼。但从语义层级来讲，这是零级语义，仅仅在需要使用图像数据的闭环测试中需要，比如HiL 测试。

对于直接利用一级及以上语义进行开发的闭环（如A2和A3），是不会利用渲染图景，对渲染效果自然也就没有要求，反而往往会更关注仿真软件的传感器模拟能力，真值的结构定义、输出API形式。要对车辆进行控制的研发闭环，会关注仿真软件中自车的动力学模拟能力是否足够逼真。

支持三级语义（涉及自车之外的其他交通参与者的研发闭环），更希望仿真软件能够提供除自车之外，对其它交通参与者行为的控制能力，包括AI 控制或提供编程控制的接口。

一级及以上语义的研发闭环，对渲染的要求只要能让人看清语义含义就行，可以简单到只需要使用线框图显示就足够了，这样不需要高性能的渲染设备，还可以直接在浏览器中高性能的展现，也方便在渲染画面中附注各种方便开发人员进行分析的信息。

高逼真度的3D 实时渲染效果需要高性能显卡支持，研发人员在桌面端或许有需求。当不适合用于成百上千场景的并行仿真，并行仿真中本来也没人去看渲染的结果，并行仿真只需要记录日志数据，如果有需要（比如分析仿真中发现到的错误），只要能将日志数据以线框图的形式回放分析就可以了。

真值的定义和输出接口

仿真软件自身拥有的上帝视角，有场景中所有事物的真值数据。但是这个真值的数据结构如何定义，真值数据如何输出并不是一个容易的设计。

真值数据结构体现了描述复杂的交通环境的能力，我们也把这个交通环境的数据表达形式成为“环境模型”。开放仿真接口（Open Simulation Interface）定义了一套环境模型表达的数据结构，使用proto buffer 的格式定义，可以从GitHub上获取。

图20 是分析OSI 定义中所有文件的依赖关系而绘制出来的依赖图，A --->B表示A 依赖于B。可以看到，所有代表传感器检测到的环境信息的数据文件是依赖于代表真值的数据文件的。这也从侧面说明了，仿真软件输出的模拟传感器检测到的环境数据，是根据真值推算出来的（把传感器当过滤器，输出部分环境真值数据，根据必要还可以加噪声）。

B ,代表A 依赖于B)" title="图片" style="width: 677px; visibility: visible;" data-type="block">图20 开放仿真文件依赖分析(A --->B ,代表A 依赖于B)

代表上帝视角的真值数据本身也非常复杂，毕竟要描述“整个世界”.

图21 开放仿真接口的真值定义

图21 是开放仿真接口的真值定义（根据OSI 定义文件逆向生成，高清图请单独索取），包括车道、车道边界、静态物体、动态物体、交通标志、地面标志等等。

OSI 的定义出来的比较晚，大多数仿真软件还没有支持，所以各仿真软件都有各自的真值和模拟传感器输出的数据格式。所以为A1和A2类似的开发阶段，需要考场仿真软件真值的表达能力。还有真值和模拟传感器的数据的方式也会影响开发的难易程度，值得关注。

动力学仿真

图18中A3、A5（原型阶段的全程闭环）和A6（工程化阶段的第一个全程闭环）都使用了T3作为仿真环境。T3主要是在T1的基础上增加了车辆动力学模拟。一般自动驾驶仿真软件都会提供一定的车辆动力学模拟能力，预置一些典型车型的动力学基本参数。用户也可以根据已知的参数来在仿真系统上创建新的动力学参数车型。

T3首先解决的需求也是提高效率和可测性。让车辆未就绪时能支持控制算法的开发。T3跟T5（HiL 台架测试环境）是有很大差别的。T3主要靠软件解决问题，尽量不涉及昂贵的硬件。T3对准确性的要求低，但同时也要求成本低。软件仿真的优势就是可以同时开启很多实例，让不同组别的人可以同时工作。甚至每个开发人员都可以在桌面启动一个仿真测试的开发闭环。测试组也可以同时进行测试闭环的开发，自动化测试的搭建。所以要求单授权的采购成本低才能采购较多的授权。

而T5 HiL 台架测试会追求高精度，不仅仅动力学模型参数准确、实际执行效果也跟要适配的车辆高度一致，动力学模型也要放在高性能的实时机上执行，支撑的软件也会非常昂贵。这样的系统一般来说不可能会采购很多实例。

纯软件仿真工具的选择原则

纯仿真软件（T1和T3）的重点在提高效率和提供可测性，并尽可能降低成本以采购尽量多的授权。同时在准确性上的要求应有所让步。

0级语义的精确性不是T1的目标。满足T1要求的仿真系统，需要有较好的渲染效果，但是不用追逐过于逼真的渲染效果，因为再逼真的效果，也是计算机生成的，跟物理摄像头拍摄还是有很大出入，尤其在人眼看不到的细节上，人眼看不到的内容，也许对算法上敏感的。而为获取逼真渲染效果的投入与其产出并不成正比。

动力学模型的准确性也不是T3的核心目标，T3需要的是低成本下的动力学模型支持。只要测试闭环能建立起来，实际对动力学效果到T2（实车上）进行测试。

所以在选择仿真软件时，尤其要注意以下几点：

警惕对渲染效果的过度宣传，确认你是否需要并值得为其付费
这个阶段不要过度追求高精度的动力学模型
根据自己需要的语义层级、传感器类型谨慎选择仿真软件的功能模块

总之就是要在满足核心目标（提高效率和实现可测性）的前提下，尽可能降低成本而采购足够多的授权。一个所有功能齐备、渲染精美、动力学模型高精度的仿真软件，单个授权上百万了，抵得上一辆豪车了，如果不能买多个授权，开发团队和测试团队不能同时使用，也就谈不上效率了，还不如多配几台车算了。

同时为了能基于不同层级的语义做各层算法的并行开发，要特别关注仿真软件对不同层级语义的定义能力、真值的定义能力、数据格式规范、以及API是否便利。

3.6.2 处理器在环仿真

1.3节已经提到PiL（处理器在环），也就是图18中的T4。

图22 各AI芯片平台

PiL 测试首要解决的问题是一致性。原型阶段的所有软件都没有在我们的最终目标硬件上运行。更直接到说法，原型阶段大多数都是在x86平台上开发，在车上也是用x86工控机，工控机上安装Nvidia的显卡来运行深度学习算法。但是在量产阶段，我们需要所有软件运行在车载专用计算平台，CPU 以Arm 为主，AI 模块各芯片有自己的专用设计。

图22列出来目前比较知名的一些AI 芯片平台。可以看到，虽然大家在训练阶段都使用Nvidia的GPU 或计算卡，但是在推理阶段，训练得到的AI模型在向不同的嵌入式平台移植时都需要做一下模型的转换、嵌入式的优化工作。需要保证移植和优化完成后，算法的执行结果仍然和最初训练出来的一样。

除了感知类的AI 算法外，控制算法原型阶段在快速原型设备上运行，工程阶段要在高实时MCU 上运行，也需要保证一致性。嵌入式系统的基础软件环境与工控机也不同，也需要验证软件在运行环境变更后，其行为是否一致。

日常开发可以用计算平台样件，为了方便做自动化测试，一般通过PiL 台架来执行。PiL 台架上包括电源、电压范围、软件的更新都可以通过程序进行控制。方便自动化测试用例的部署和执行。以太网、Can总线、LVDS 线束等也可以设计层可以通过程序控制其中断与连接，这样可以模拟故障的注入。

PiL 台架可以支持视频注入到嵌入式平台的摄像头数据捕获接口（一般是LVDS 接口），这样可以把嵌入式平台的视频捕获模块也纳入到测试回路中，这是T1、T3 仿真测试环境无法实现的，T1、T3的渲染数据只能通过以太网发送，是测试不到视频捕获模块的。如果PiL 台架不包含仿真软件，还可以直接回放视频文件作为视频源，这样也可以将实车路采的视频数据在PiL 台架上进行回放。

3.6.3 硬件在环仿真

具体的硬件在环测试的原理和设计很多文章有论述，这里不做详细说明，只对其与其他测试手段的区别进行说明。

在PiL基本上解决了一致性的前提下，HiL 主要目标是可靠性和可测性，同时兼具精确性。能够达到这几点，是由设计HiL 测试的几个基本原则决定的：

待测设备的所有外部接口数据交换方式要尽可能跟实车一样
完成从感知到控制执行的全程闭环
测试场景通过仿真来实现
全系统能够程序控制自动化

对于第1点，我们想达到的效果是让待测设备貌似不知道自己当前是在车上还是在测试台架上。因为所以的外部接口的数据交换都是跟车上一样。比如在摄像头数据输入上，也需要通过视频注入的方式，让视频捕捉设备以跟车上同样的方式获取图像数据（0级语义模拟）。也可能某些传感器的0级语义模拟非常困难，很难做到很精确，或者成本太高（比如雷达回波），那么部分传感器数据使用1级语义。但总的来说，是倾向于全部使用原始的0级语义数据。

这样就将待测设备的全部软硬件都纳入到了测试闭环中，相对于其它跳过某些环节的测试手段而言，这是最完整的测试闭环（上文第2点），这是能验证系统可靠性的一个基本前提。同时与自动化测试相配合，可以在测试频次、测试时间上提高数量级，对可靠性验证有很大帮助。

虽然是全程闭环，但是交通场景是仿真的，这也就意味着一些危险的场景能够以较低的成本被进行测试，达到较好的可测性。

因为感知到0级语义（图像、点云等）是仿真出来的，经过训练的感知算法对这些数据会有非常好的效果。这可以推导出两个结论：

HiL 测试中感知算法对仿真场景非常准确，能给后续的决策规划提供较好的依据
HIL 测试实际上测试不了实际感知算法的精确性（但能助力形成全程闭环过程）

在这两个前提下，如果我们提高车辆动力学模型的精确性，就能非常好的测试控制算法的精确性。因此HiL 测试的仿真软件要求能够具有非常精确的设置和调整动力学模型的能力，同时使用高性能的实时机（硬件和操作系统都是以高实时为目标进行设计）来执行动力学模型，保证其执行机制跟实车环境高度一致。这也是HiL 测试系统价格昂贵的重要原因之一。

这与4.5.1中对动力学模型的要求是不一样的。4.5.1的纯软件仿真是以效率为主，要求低成本获取足够多的软件授权提高前期的开发效率，可以牺牲部分动力学模型的精确性。本节的HiL 测试确是要以控制算法的精确性为主要目标之一，以高成本实现一个测试台架。

ViL 测试（图18的T6）可以看成是HiL测试的小型化，整套测试环境（仿真软件、传感器注入能力）都被安装到车上。去掉HiL 测试中运行动力学模型的实时机，替换为真实的汽车执行机制。这样就在HiL 基础上，对控制执行的测试直接使用真实的实车设备，进一步提高了测试的精确性。因为依旧使用仿真场景，所以仍然具有跟HiL一样的可测性，但是一定程度上牺牲了自动化测试能力。

3.6.4 影子模式与云化并行仿真

前面我们用软仿真快速构建初步的研发闭环，在利用PiL 测试环境逐步从原型阶段向工程化阶段转换。HiL 测试实现了工程化阶段最完整的仿真闭环，ViL测试得到更精确车辆控制效果。我们也可以通过实车（T7）来复现某个单个场景（使用假人、模型车等道具）。到这一步，对单个场景的工程化能力建设到了极致。我们可以在这一系列工程化阶段中把算法、软件迭代得越来越好，但还有一个关键点问题：场景覆盖度不够。

这体现在两方面：

如何发现大量的长尾场景
如何对大量场景进行回归测试

第1点难在“如何发现未知的问题”，第2点是“如何提高测试效率”的问题。T1~T8都是针对少量场景的测试，是无法应对段时间内执行成千上万测试场景的需求的。

为了解决这两个问题，衍生出对应的解决方案，分别是影子模式和并行仿真。

量产车的影子模式

图18的T8是量产车，如果把刚刚开发完成对AEB 功能部署到量产车，会出现两类大问题，漏报和误报。

漏报就是应该紧急刹车的时候没有刹车，会影响行车安全，造成重大的人身伤亡事故。但是如果为了减少漏报，将相关触发条件的阈值放得较为宽松，就会出现大量的误报，就是俗称的“幽灵刹车”，严重影响驾驶体验。

影子模式就是用来解决这个问题。其基本原理很简单，当我们的AEB 功能实际装车后，会让所有相关的传感器、算法逻辑、AEB 功能的触发都正常运行。但是在功能触发后，应该实际执行紧急刹车动作的时候，停止执行。同时把触发时间点前后一段时间的传感器数据、自车的状态数据、驾驶员的驾驶行为数据等信息，加密脱敏后回传到云端进行分析。这里有几个关键点：

触发数据记录规则的设定与更新
数据记录与回传能力
软件OTA 能力

设定数据触发的规则是为了找到尽可能多的漏报和误报的场景。所有影子模式下功能被触发的场景，一般都应该记录下来。这里会有大量的误报场景。甚至可以在初期将相关阈值调低一些，以获取较多的触发场景进行分析。然后调整规则，让误报逐步减少。但减少误报可能会增加漏报。

漏报的触发规则可以是检测到车辆撞击、驾驶员紧急刹车，所以漏报后的数据回传是一个亡羊补牢的过程，每一个漏报可能是一个悲伤的故事。

触发规则的设计是为了找到对算法改进有用的数据。所以往往会针对算法的能力弱点进行设计。比如根据不同传感器获取了不一致的结果时，一定有一个是有问题的，这可以是一个触发规则。或者算法对隧道的效果较差，也设定进入隧道前开始触发数据记录（根据定位数据触发）。也就是说触发规则的定义应该可以非常灵活。

在车载终端执行触发规则时，可以选用合适的规则引擎工具，具体规则可以由算法专家根据需要编写，再下发到车端。

数据记录和回传到能力也是影子模式的关键。量产车与专业采集车不一样，受限于存储与计算资源，并不能记录太长时间的数据。一般来讲软件设计时会在内存中时刻更新一个时间窗口内的数据，包括传感器数据（0级语义的原始数据和各级语义提升后的数据），规划决策的关键数据、软件运行中的关键日志信息、车辆总线数据等。数据记录被触发时，才会把内存中的数据写入持久化存储。如果遇到严重事故，数据落盘可能会失败。这些数据来源与不同的模块，如何统一记录需要做好设计。数据回传通道一般会利用智能座舱域的对外网络通讯能力。所以数据记录和回传能力是要在车辆开发阶段就进行专门设计的。

根据回传数据修正的算法和软件需要能更新到车辆上，所以车辆必须要有OTA 能力，至少对相关的自动驾驶软件部分具有OTA 能力。

另外数据记录触发规则的OTA 和整个自动驾驶软件的OTA 是两回事。前者简单很多，是为了更好的采集数据而调整采集规则，应该与软件的OTA 分开处理。

从影子模式和正常功能启用模式并不是非此即彼的，可以有中间状态。比如某些非常确定的场景可以实际执行控车动作，而其他场景保持影子模式执行。逐步迭代更新到完全功能启用模式。

这里说句题外话，量产车从影子模式切换到完全功能启用的过程时间是不一定的，可能几个月，也可能一两年。但是这个切换的过程大多数情况下用户是不太清楚的。所以从负责任的角度看，车辆销售时应该避免夸大自动驾驶功能，尤其像AEB 这种与人身安全密切相关的功能，避免给用户过高的预期，而降低了驾驶的警惕性，尤其是在车型量产前期。但为了新车型销售，往往会把自动驾驶功能作为宣传卖点，这里就有利益冲突。总之，在现阶段，用户驾驶时不要过度依赖自动驾驶功能，还是要专注驾驶、警惕危险，保证自身的安全。

基于云的并行仿真

基于云的并行仿真解决的是对大量场景高效率的全覆盖测试的问题。要准确理解这句话，我们只需回答以下几个问题：

大量场景从哪来，是个什么量级
为什么其他仿真形式不能满足大量场景的测试要求
基于云的并行仿真测试重点是什么，哪些能力不在它的测试覆盖范围内。

如前文所述，本文对场景的定义是“在特定的静态道路交通环境下（地图），多个交通参与者在一段时间内的行为及相互影响”。

设想如下场景。

场景:1：“一辆车顺畅的通过一个空无一人的路口”。
场景2：“一辆车通过路口时，前方车辆遇到红灯停下，本车也停下。绿灯后跟随前车通过路口”。这至少有两个交通参与者，红绿灯的状态变化也是场景的一部分。
场景3“车辆行进时突然有侧方来车，避让不及相撞”。

这些交通参与者的行为可以有无穷无尽的组合，还可以发生在不同的地图上。原型阶段和工程化阶段开发时我们只需针对少量典型场景进行开发和测试，重点是验证感知的准确性，控制执行的准确性。但在工程阶段后期和量产阶段，我们需要找到足够多的有可能会使得功能失效的场景。影子模式就是用来发现这些场景的重要手段。

如果把上述场景称为“基准场景”，根据关注的自动驾驶功能的复杂度，我们可以设计出成百上千，乃至更多的基准场景，当然我们需要尽量选择对现实交通有代表意义到场景。每个基准场景可以有多个参数。必如上面的场景3，我们至少可以设计几个参数，自车的初始速度，初始时刻位置，感知系统发现另一辆车的时间，另一辆车也可以有初始位置，和初始速度，这就是5个参数。交通参与者越多，参数也会越多。假设每个参数有5个可选值，那就是25个参数组合就是一个可被测试的场景，这里称为“特化场景”。如果有1000个基准场景，每个有25个特化场景，这就有2.5万个特化场景。这个数字就非常大了。

HiL测试能否对这些特化场景进行测试？答案是肯定的，而且可以做到非常精确。假设我们有一个完全自动化的HiL测试台架，5分钟完成一个特化场景的测试，一刻不停的进行测试，要完成2.5万特化场景的测试要将近三个月。就算有足够的预算可以多添置几个HiL台架，也是无法应对指数增长的特化场景数量的。所以不能指望HiL完成海量场景的测试。

要短时间内完成海量场景的测试，一方面要大大提高并行能力，一方面要降低单个场景测试的资源需求。首先降低资源需求的方式是仿真过程中不对零级语义数据做模拟，也就是不做视觉渲染，不做点云生成等，直接使用一级（含）之上的语义。其次是简化车辆动力学模拟。HiL测试是包含了基于真实车辆动力学模型的控制算法的。我们给线控系统下指令希望车辆加速度降低到多少，这是由运行在实时机上的动力学模型根据真实的车辆发动机参数模拟执行最后达到的。但在云仿真中，我们要求车辆加速度到某个数值，它就自然到了，怎么到的不用关心，上帝之手帮你搞定，这就是一个非常简化的动力学模型。

这样单个场景的仿真需要的资源大大降低，也就有了大量低成本复制测试闭环，达到并发测试的目的。但也意味着我们不会测试感知算法，不会测试控制算法，实际上测试的是各种规划和决策算法。

轻量化后的测试闭环非常适合部署在云平台上，不测试时不需要占用太多计算资源。需要测试时临时开启大量资源并行执行，测试完成后释放资源。

3.6.5 各种测试方式的对比

图18的T1~T9是各种不同的测试环境，我们不能指望一种测试环境可以达到所有的测试目的，而是要在不同的研发阶段，在测试条件和成本等诸多因素的约束下，使用恰当的测试方式达到特定的目的。

下表总结了各种测试环境的关注重点。

我们可以看到，软仿真阶段重点是让研发和测试团队能够尽快的建立基本的开发和测试闭环，对硬件设备的依赖尽可能少。T2因为是全程闭环，所以比T1增加了对渲染和动力学模型的要求，但是对精确度要求不高。

PiL 测试重点解决一致性，可以通过在测试台台上部署多个设备，提供自动化测试的并行度。然后HiL 和ViL继续增加精确性上的测试能力，但是因为较高的设备成本，一般只有少量的整套测试设备，测试成本较高。

到这一步已经可以完成对单个场景的高精度测试。然后通过云仿真建立大量场景并发测试的能力，通过影子模式采集数据挖掘基准场景，基准场景参数化后生成的海量场景通过云仿真进行高效率并发测试。测试中发现的重点场景可以再进行HiL或ViL 的高精度测试。

这样多种测试环境的组合使用，就构建了全方位的工程化测试能力。如果所有测试环境都完成了自动化测试能力的构建，并在各个测试阶段进行回归测试，就能很好的保证算法和软件的质量，这也是提高工程化能力的重要手段。

3.7 数据如何驱动

3.4.4阐述数据规模时提到，少量数据的作用是“快建立起'单体算法、局部闭环、全程闭环'分别在'原型环境和工程环境'的执行能力”。对应到图18，也就是原型阶段和工程阶段A1~A8、T1~T7的内容。这部分执行能力建立起来后，工程阶段的数据驱动才具备了前提条件。

工程阶段的数据驱动体现在两个方面：

采集的数据经过处理后（清洗、筛选、标注、检索）用于算法的开发，先在原型系统中进行验证，工程化环境具备后，也可以在工程化环境中进行验证。
具备了逐级递进的工程化仿真及测试环境后，可以利用第N级仿真环境作为第N+1测试环境的日志数据回放平台。回溯分析N+1级测试的问题，并在第N 级仿真环境中建立可以进行自动化回归测试的测试用例。

下面分别说明。

获取对算法改进有效的数据

第1条很容易理解，尤其对于感知算法，目前普遍使用监督学习方式，根据采集的数据和真值进行训练，数据越多越好。需要针对不同的传感器、不同的算法类型选择合适的数据和获取真值的方式。这里的难点是对如何对数据进行管理，其核心就是通过一系列技术手段找到对算法改进有效的数据。

对于监督学习而言，典型问题领域使用哪种神经网络结构已经被业界研究的差不多了。在算法设计上的革命性改进很多年才有一两次。多数算法都是根据已有的论文实现，算法效果的优劣实际上比拼的是数据。

无论是哪种算法前期数据的有效性是最明显的。当算法效果提升到一定程度之后，就需要找到对算法改进有效的数据。因为只有这些数据才是具有“驱动性”的数据。

而要找到这些数据，一靠数据规模，足够多的数据找到有用的数据几率就会越大；二要依靠数据挖掘的手段。为了达到更好的挖掘效果，要从数据采集开始，到后续数据处理的各个环节，为后续能更好的进行数据挖掘做准备。这就是数据管理平台的作用。

数据回溯分析

数据驱动的第2层含义就是基于测试数据的回溯分析。图18中我们画了好几条标注为“回放日志”或“场景复现”的连接线。比如T5 HiL台架的测试、T6 ViL 测试和T7量产车的测试，其测试执行时采集到的日志数据，我们都可以在T4 PiL台架上进行日志回放执行。

假设我们在T7样车上进行AEB 功能测试，测试场景是过马路时检测到行人紧急制动。在测试场使用假人和真实车辆进行测试。当某个参数组合（车辆的速度，行人出现的时机）下，10次测试会出现1次测试失败，车辆撞倒了假人，造成一定伤害。

我们可以通过在PiL 台架或者专用的日志可视化工具中（如：ROS的rviz 工具，图18中的T1.5）中回放日志，分析错误所在。感知算法的各个环节、软件代码等都有可能出现错误。无论错误在哪，假如我们发现并修复了错误，那么怎么进行验证。

最直接的办法就是在到测试场上执行同样车测试场景。这里就有两个问题：

频繁的在测试场进行实车测试，成本高昂，效率非常低。
没法保证每次实车测试的执行环境完全一样。

就算不考虑测试成本的问题，第2条也让确认Bug已经被修复非常困难。而且Bug的发生率是10次偶发1次。修复后就是测试100次都正确也不能认为Bug 已经解决，因为可能这100次测试都没有达到Bug 的触发条件。

这种情况下，至少有两种解决方案。

将出现错误的那次测试的实车数据在PiL 台架上进行回放执行。这个执行与纯观看日志数据的结果不一样，PiL 上的回放执行是可以直接将录制日志中的视频图像数据直接注入的计算平台的视频捕捉接口，各算法和软件尽可能的运行只到错误出现的那个时间点。在这个时间点，验证bug 修复前后同的执行结果。这个数据回放是开环的，如果bug 修复成功，该时间点后的日志时间就无意义了。
另一种方法就是在HiL 台架上复现出错误的场景。同样的场景使用bug修正前和修正后的不同版本软件进行测试，比较执行结果。这个测试时闭环的。

工程阶段，专业采集车可以运行数百万公里并采集数据。我们可以分析提取大量的片段数据，每个应该触发或者不应该触发某个动作的执行。可以把这些片段数据在PiL 台架上进行测试，验证与我们的期望是否一致。

到量产阶段，影子模式根据设定的规则回传大量不同场景的日志数据。但是量产车与专业采集车相相比，采集到的日志数据种类和数量都会少很多，一般达不到能在PiL台架进行回放的条件。跟多的是分析场景，在HiL/ViL 上进行高精度场景复现，验证代码在这些仿真场景下的行为。或者在轻量化的云仿真平台进行复现、修复、再验证。

3.8 高阶功能的闭环拓展

前文用AEB 来举例子，只是为了在尽量单一的功能下，突出工程化的方法论。下面我们尝试将这个工程化的分析方法应用到更多的功能开发，以两个例子作为说明。

3.8.1 Level 2.5自动车道变更功能

自动驾驶的功能分级里有一个Level 2.5 的说法。大意就是Level3达不到，但功能又明显超过了Lever 2 的范围，还有称为Level 2.9 的，含义不言而喻。当然也有人认为L1~L5这种自动驾驶能力的分级方式本身就不对。

3.8.1.1 L2.5是一个核心技术能力的临界点

不过从工程化的角度看，L2.5 的功能点是一个核心技术能力的临界点，非常关键的临界点。L2.5的典型功能就是“自动变道”，可以分为“人触发自动变道”和“完全自动变道”。为什么说它是核心技术能力的临界点？至少有两个原因：

首先，从算法角度看，从这个功能开始要做路径规划了。之前L1、L2的功能只需要在某个时机对车辆运动实施横向或纵向的影响就行。但是变道不行，规划到控制的设计方式跟L2有很大不同，难度也增大很多，倒逼对感知能力的要求也高了很多。

第二，从工程化角度看，自动变道的可能场景更多了（当然，这个对算法的要求高了很多）。L2的ACC、AEB、TJA 等功能，每个功能基准场景20个左右就能覆盖到绝大多数现实情况了。但是变道的场景就复杂多了，涉及多个车道，道路结构有多种可能，多个车道都可能有车，交通参与者变多，组合形式多样。枚举出200个以上意思的基准场景是完全可以做到的。更多的场景意味着要更多的数据、更严格的测试，这都是工程化的难度。

之所以还有个“人触发变道”功能，说白了就是功能太难做不出来，先做个简单的。人来判断变道的触发时机，这样就排除了大量场景，相应对感知算法到要求也被降低了。整体从算法到工程化的难度都降低了。

3.8.1.2 工程化与数据驱动

我们使用本章的方法论，来看看“完全自动变道”功能进行工程化开发的方法。并与前文AEB 的工程化方法相对照。

首先我们要分析出来涉及的各种算法，按照语义层级进行分割。按语义层级分割我们可以很方便的分析出哪些算法可以同时一起开发，高层级的算法可以使用仿真软件输出的低级语义。可以分析出算法需要的数据和真值，可以先通过仿真软件获取某些算法的数据集和真值。

图14中的所有算法基本上都会继续使用。为了换道，侧方的摄像头和毫米波雷达（一般是角雷达）是必须的，要观察后方来车，也需要后向的摄像头，以及后雷达。增加的算法至少有：

侧方和后方都需要有对应的视觉算法，完成目标识别、分类、跟踪等
基于前后摄像头、前后雷达、侧方摄像头和角雷达进行360度目标融合
车辆的行为预测和轨迹预测不再是可选的，而是必须的。
要根据其他车辆的当前轨迹和预测轨迹来规划自车的形行驶路径
控制车辆按照规划的路径行驶

原型阶段的扩展

我们对照图18来分析在“完全自动变道”功能下的扩展。

首先对A1进行扩展，原来的A1主要是前置摄像头的视觉算法（目标检测和分类、目标跟踪、车道线识别、还有基于视觉的测速等等），现在要新增后向摄像头、侧方摄像头的视觉算法，也要涵盖前视视觉算法的内容，但是摄像头安装角度不一样，看到的数据风格还是有差别，需要补充这些角度的数据进行训练。不过T1和T2环境一样可以为这部分开发进行服务。

A2是基于1级语义开发的算法。新功能下同样可以找出需要基于1级语义开发的算法，比如“选择对变道动作有影响的目标”，“360度目标融合”等等。

A3在AEB 的例子中是直接使用1级语义的数据完成控制算法的开发。这个控制算法里面其实隐含了好几级算法步骤。先要根据两车的距离和相对速度计算出对本车的速度规划（一段时间内的速度变化），然后算出对应的加速度变化，再转成对刹车和油门踏板的控制执行。因为这几个阶段经常都是同时在一个算法模块里完成，所以常常放在一起称为控制算法。但在“完全自动变道”的案例中，A3应该会被拆解成明确的两个算法步骤“轨迹规划”（也有叫“路径规划”的）和“轨迹执行”，也有可能在具体算法设计时做更精细的拆解。但这两个步骤都同AEB 例子的A3一样，利用1级语义进行开发和测试，可以在T2和T3环境进行测试验证。

A4代表的是几个算法的局部串接，相对AEB 案例，“完全自动变道”的案例的单体算法更多，在这一步可以设计更多的串接组合，但串接的基本原理和测试环境仍然是一致的。

A5是原型阶段的最终形态，经过前面的逐级开发和串联，到这一步从感知到控制执行全部闭环（运行时闭环）连接在一起。AEB 案例和完全自动变道案例只是功能复杂度不同，在开发过程中所属阶段和测试环境也是一致的。

两个案例在工程化阶段的分析与上文原型阶段的分析类似，这里不再赘叙。

场景的挖掘

相较于AEB 案例，完全自动变道功能因为传感器更多，涉及的场景更复杂，相应数据规模也会大很多。传感器配置齐全专业采集车能提供丰富的感知数据用于训练。从这些数据中我们也能挖掘出自动变道的场景。

专业采集车采集数据的过程中，驾驶员也会存在变道的情况。编写相应的检索算法分析采集到的数据（例如：提取40公里以上速度时驾驶员拨转向杆，过段时间又拨正的场景，再进一步分析）。这些数据里至少提供了三个算法的真值：

变道的时机
变道的轨迹规划
变道的控制执行

这些数据可以作为工程化阶段开发的数据来源，人工或自动的方式提取场景信息。因为专业采集是各种传感器数据非常完备，我们甚至可以通过在PiL 台架上回放数据，来验证我们判断变道时机的算法是否正确。数据回放时可以回放1级语义的数据，也可以回放0级语义的数据来把更多算法纳入到测试执行中。

同理，在配置了足够传感器的量产车辆上，我们可以为“完全自动变道”功能设置影子模式执行。可以在用户拨转向杆时，触发数据记录（包括拨杆前一段时间的数据），到用户拨正时结束。也可以在我们的算法认为应该触发转向时开始记录（这时候用户没有主动执行变道动作），但是不执行变道动作。这两种触发方式，前者可能是我们判断变道的时机过于保守，后者可能是过于激进。这些数据回传后都可以用于我们进行场景分析，调整算法的规则或阈值，发现感知算法的问题点等等。

较多数量的基准场景参数化后产生的庞大的特化场景，就需要轻量的云仿真来进行测试验证。这些设施我们在前面的AEB 案例中已经就绪。

可以看到，虽然“完全自动变道”功能比AEB 案例复杂很多，但是整个工程化的原理和工具是通用的。只是在横向纬度进行扩充，变得更“胖”了。如果我们在AEB 开发中就建立好了这一整套工程化设施，就能为新的功能开发带来便利，在架构一致的前提下在量的维度进行扩充。

3.8.2 Level 4的工程化

有了前面AEB 和完全自动变道两个例子，我们再来看Level 4 自动驾驶的工程化之路也就会比较清晰了。

Level 4 自动驾驶在原型阶段，对应与图18的A1、A2的部分（0->1级语义提升和基于1级语义的算法，1->2级语义提升）依然存在。但是涉及的传感器更多，对应与这个阶段的算法也会更多，这需要算法专家根据具体的传感器配置和整体的算法架构去规划。不过这个步骤对应的测试环境依然可以是图中的T1、T2。

对应与A3的部分，与完全自动变道功能一样，也要拆分为“规划”与“执行”两个部分。但是规划部分的复杂度会远远超过自动变道功能中的实现。因为场景的空间范围、时间跨度、交通参与者的类型和数量都有很大的扩充。如何对这个阶段的“规划”与“执行”进行定义、设计和实现，是Level 4自动驾驶的一个关键技术难点。但是其测试环境依然可以基于T2、T3来进行。(我在另一篇文章《智能驾驶域控制器的软件架构及实现(下)》的4.3节，叙述了一个多级规划与执行的机制，可以参考，有助于理解这一部分的复杂度)。

在工程化阶段的实现机制依然跟前面两个例子一样，但是单体算法和局部闭环的数量会多很多，需要逐个设计其测试方式。测试环境依然是T4~T7。

但是在量产阶段，Level4自动驾驶跟之前的例子就会有很大不同。

一方面L4的影子模式是不能简单的在量产车上部署的。因为量产的Level4车辆没有驾驶员，所以算法必须执行所有的控车任务，不能像之前例子一样，只触发数据记录，不具体控车。也就是说出了事故之后的“漏报”数据可以记录并回传，但是没法用影子模式解决“误报”问题。解决的办法就是在量产之前有很长一段时间，使用人类安全员坐在驾驶位上，随时准备“接管”车辆。“接管”动作本身就是一个数据记录的触发器。

另一方面，云端的并行仿真变得极为重要，不可替代。前面AEB 和自动变道的例子中，云端并行仿真如果没有，基本上也能完成开发，只是测试不充分。但是在Level4中却是必不可少的。同时功能上不仅仅是简单的复现预设的场景，还要能让场景中除了自车之外的交通参与者也具备一定智能，这样才能主动生成无限的场景组合。才能以低成本的方式通过仿真积累数十亿公里的驾驶里程，发掘更多的长尾场景。

这两个方面都在我们图18的量产阶段中都有定义，但是规模大小又上了一个数量级。我们可以看到Level 4 自动驾驶的工程化原理依然是与之前示例一样的，但是数据规模比L2和L2.5功能的工程化有了数量级上的提升。

正因为这个阶段是Level4自动驾驶工程化的必经路径，所以当我们看到路上带安全员的Level4的车辆在运行时，并不意味着其Level4驾驶能力就很好了，也可能只是刚刚开始。这个阶段的开发投入巨大，也需要很长时间点积累，对数据驱动闭环的IT 基础设施和工具链都有很高的要求。

3.9 升维还是降维

自动驾驶领域人们常讨论的一个问题是“升维还是降维？”。也就是说是从Level1、Level2开始逐步升级到Level4以上的自动驾驶能力；还是反过来，先具备Level4的技术能力，然后消减功能和硬件配置，以较低成本向下实现功能量产。

这一节我们从工程化的角度对此问题进行分析。

3.9.1 自动驾驶的核心技术

自动驾驶的核心技术是什么，我的总结是两个，算法能力和工程化能力。

算法能力涵盖了各种传感器感知算法、融合算法、定位算法、规划算法以及控制执行算法等。感知算法又与相应的传感器技术密切相关。考核算法能力的基本目标就是能完整原型阶段的完整运行时闭环，也就是图18中的A5。这个阶段验证了预期功能在原型系统上的可行性。

工程化能力决定了预期功能是否可以从原型车走向大规模量产。搭建一个自动驾驶原型车和大规模量产的工程难度完全不在一个数量级。原型车我们可以不计成本（毕竟数量少），用高配的硬件设备，对可靠性要求也不高，反正随时出问题可以随时去解决。原型车也不用管AEC-Q100等规范要求，天气冷的地方别去，天热了拉一个空调排风口到后备箱就行。但是量产车辆要控制成本，一辆车的寿命是10多年，对零部件长生命周期的可靠性的要求非常高，否则车辆召回会带来重大的经济损失。在中国销售的车辆，必须能适应南北气候的不同，东北零下30度的气温，大多数原型车都会趴下。

3.9.2 工程化能力的体现

自动驾驶的工程化的能力至少可以现在以下几个方面：

硬件系统的工程化
软件工程化
测试工程化
数据工程化
与车辆工程的集成

如果进行更专业的仔细分析，还能有更多。同时还需要一系列用来满足这些工程化能力的工具链体系。

硬件系统的工程化的体现最典型的就是一系列汽车零部件的质量标准，抗振的标准、电磁兼容性标准、散热的标准等等，我们常说的AEC-Q100标准是对集成电路的，包含了对芯片的七个大类别共45项各种类型的测试。现在自动驾驶的计算平台已经妥妥地是一台高性能计算机了，板级的精密度已经接近智能手机了，实际对设计和工艺的复杂度比手机还高。这样一个设备要在车上颠簸10年以上，还要保证高可靠性，这在汽车行业也是从来没有过的事情。

相比硬件工程化还有很多硬性标准可以度量，软件的工程化更难度量。软件不比硬件，有时候质量差一些，功能一样能正常运转，只是问题被掩盖的更深。而软件的工程化，从需求管理和跟踪、概要设计和详细设计到编码实现和测试，是需要一系列的文档体系去管控研发过程的。常用的度量软件工程化的手段如ISO9000标准、CMMI 能力成熟度认证、功能安全过程认证，也是在检查这些文档。

自动驾驶和智能座舱之外车载软件，功能复杂度和整体的代码量其实要低两个数量级，还有可能完全按照规范要求完成全部文档化跟踪。但是自动驾驶相关软件如果严格文档化，导致的研发周期拖长几乎是不可接受的。直接结果就是有人写文档就没人编码了。这也导致了软件的工程化建设更为困难。

所以自动驾驶的软件工程化要在质量和效率之间做平衡。这个平衡不是说牺牲质量换效率，而是说对于这些创新技术的研发，要在研发初期重效率，然后逐步提高对质量的管控能力，而不是一开始就要质量标准卡着软件研发无法寸进。这也是考验每一个自动驾驶软件研发团队进行工程化量产开发的难点。

关于测试的工程化，前文图18基本上都是讲这方面，不再赘述。

数据工程化较少被提及，算法研究时一般都是基于处理得非常规整的数据进行。但是现实中我们用专业采集车采集的数据规模庞大，充斥着大量无效、重复的数据。要找到对我们算法改进有用的数据并非易事。我们会在后续文章中对此进行讨论、

3.9.3 影响工程化难度的因素

哪些因素会影响自动驾驶工程化的难度呢。

速度快慢

车速一旦慢下来，实时性要求就会被降低，很多软硬件的要求就会被降低了。工程化难度就会下降。比如自动清洁车5-10km 的时速，那对感知算法的帧率要求可以降低到每秒15帧（每帧行进距离不到20厘米）。软件也不用基于高实时的操作系统和中间件，用ROS就完全可以满足。

载人与否

如果不载人，很多为了功能安全的设计就可以大大简化。行驶也不需要考虑人的舒适性，控制算法开发也可以得到简化。典型的如清洁车、洒水车、无人矿车、无人农用车、无人卡车等。

成本高低

如果量产车能承受较高的成本，自动驾驶系统的工程化难度也能降低。比如一辆无人重卡售价可能到上百万，那么10万元一套的自动驾驶系统就是可以接受的。但是15万左右的乘用车，可能就需要把成本压缩到2万以内甚至更低，还要达到工程化就难了。

アプリケーションシナリオ

应用场景应该是对工程化难度影响最大的。前文谈到，从Level2.5功能开始，场景的复杂度大大增加，到Level4,会有无数的长尾场景需要被发掘和适配，所以对数据驱动有着非常现实的要求。

我们也可以换一个思路，如果不能挖掘出所有的长尾场景，那就把这些场景消灭掉。所以我们看到封闭园区的L4低速摆渡车、城市固定路线的大巴车、封闭园区内固定线路的矿车、港口的无人卡车、封闭农场的农用车等等。这些场景通过“封闭园区”、“固定线路”的方式圈定了可能出现的交通场景的范围，以此来降低工程化过程的难度。

3.9.4 升维vs 降维

核心算法的难度和工程化难度是实现自动驾驶的关键难点。图23将常见的自动驾驶产品（或应用场景）在这两个纬度上进行了一个分布，便于比较。这只是一个粗略的示意图，两个轴也没有精确到比例尺含义，仅仅是相对位置提供一点参考意义。

我们可以看到，Robotaxi是在两个纬度上都是最难的。在原型阶段实现各种算法能力已经很不容易了，要到大规模量产应用还要克服很多工程化的难题。正因为这样，以Robotaxi 为目标的开发团队，要么做到原型阶段就很难继续，要么在努力工程化的过程中，通过自主研发或整合其它工具，构建了最完善的自动驾驶研发工具链体系。

很多企业为了能尽快具备量产能力，也会选择先专注于工程化难度较低的应用场景。比如无人矿车、封闭园区的无人巴士等。

已经有L4研发能力的企业，希望能把L4研发过程中建立的技术能力用来进行L2.5~L3级别的开发,实现“降维打击”。

图23 两个纬度的自动驾驶产品分布

老牌的Tier1企业，因为具备了比较丰富的L1/L2的工程化经验，往往会选择以L2研发能力为出发点向右上方攀登，与降维对应，一般称为“升维”。究竟谁更能成功呢，众说纷纭。

其实从本文重点突出的工程化角度来看，“升维”和“降维”之争很容易就能分辨清楚。

对于具备了L1/L2工程化量产能力的企业来说，如果在开发过程中并没有建立起本文所说的数据驱动的工程化体系（图18所描述的全套环境和工具链），那么它在走向高阶自动驾驶的过程中将面临两个纬度的挑战，之前工程化能力在新的挑战中有作用但作用有限。典型的，就是之前基于黑盒子芯片加感知算法来实现L2功能的团队。反之如果在L2的研发中建立了完善的基于数据驱动的工程化工具链，那么就是需要重点突破算法能力，工程化能力是在“量”上进行扩充，难度相对较小。

对于具备了L4开发能力的团队，如果仅仅是搭建了几台原型车，能在有限区域中做一些演示。没有完善的工程化能力和工具链，即便做L2/L3 量产开发，也没有明显的优势。反之如果在L4的开发中，建立了完整的数据驱动的工具链并且采集了大量的数据。那么在转而开发低阶自动驾驶功能时，一方面算法难度会降低，一方面可以从已经采集的数据中挖掘有用的数据，工程化的工具链体系也是现成的，这样才具有“降维打击”的能力。反而是要在成本控制上做更多的努力。

所以不是简单的“升维”和“降维”，要看具体的两方面技术能力的储备。

3.9.5 自动驾驶的路权

有些地方开始有无人的有轨电车（上海张江线，成都璧山云巴），这些场景逐渐可以被无人驾驶的大巴来实现。这里面其实隐含了一个路权的问题。从有轨车辆中我们比较容易观察到路权的作用。

高铁作为有轨车辆独占了路权，城市的有轨电车是跟其它车辆共享路权，但是有轨电车有优先权。乘用车的Level4特别是Robotaxi 之所以会产生大量的长尾场景，就是因为自动驾驶车辆在和人类驾驶的车辆在平等地共享路权，某些情况下甚至是在争抢路权。虽然有交通规则存在，但是这个规则过于宽泛。比如交通规则只会规定两个车道直接是否可以变道。但是什么情况下变道却是人独立做出判断，每个人的驾驶习惯都可能不同。所以人的行为的太多可能性导致了场景的复杂度。

从路权的角度看，那就把自动驾驶车辆的路权和人类驾驶车辆的路权分开就好了。封闭园区就是自动驾驶车辆独占了路权、固定线路是没有铺设物理轨道的“有轨”，实质是提高了该路线自动驾驶车辆的路权优先级。如果在这些自动驾驶车辆具备路权优势的道路上部署路侧的传感器和AI 能力，给车辆提供环境信息，一方面能减少车辆的成本，另一方面车跟路就能协同工作。场景的复杂度进一步降低，意味着工程化难度也被降低。

所以，从工程化落地的现实角度看，自动驾驶的发展很大程度上将会是自动驾驶车辆对人类驾驶车辆在路权上的挤出，先有部分道路只允许自动驾驶车辆运行，最后发展到把人类驾驶的车辆彻底赶出去。就像汽车赶走了马车一样。

在当前火热的自动驾驶发展过程中，工程化能力确实不如核心算法那么耀眼夺目，但它确实是自动驾驶技术真正走进人们生活的关键难点。负责工程化的大量工程师们可能没有算法科学家、算法专家那样崇高的头衔和漂亮的履历，但他们确实是在一点点的克服各种工程难题，让自动驾驶技术早日走进现实。好比在新冠疫情中，特效药和疫苗代表核心算法，隔离管控、流调等管理手段代表工程化，两者都要做好、互相配合才能得到最完美的结果。

4 結論

本文先论述了自动驾驶的研发闭环和产品闭环，在此基础上继续论述了数据驱动闭环的基本原理以及自动驾驶工程化的方法论。

我们知道，自动驾驶是一个庞大的产业链，从第2章的图11中的各层子产品角度看，每个子产品方向背后就可能有很多不同的公司在开发。同样，图18中的各种工程化工具链也有各种供应商。

有的企业可能擅长原型阶段的算法研究，但是在工程化落地方面缺少资金、数据和经验；有的企业可能对Level2方面有很好的工程化经验，但是对Level2.5 及以上的技术缺少算法积累。汽车OEM 有资金上的优势和理论上最好的数据采集通道（量产车），但是在如何构建整套IT 系统并利用数据上缺少经验；以算法起步的企业有较好的算法研究能力却缺少足够多数据来源。所以产业链上下游的紧密合作才能有利于自动驾驶系统真正的走向工程化落地。

目前自动驾驶行业内都非常强调“自研”或者“全栈自研”。排除掉宣传因素来看，一个企业完成所有的技术栈和工具链是不现实的，或许只有极少数企业能够覆盖到大多数的技术栈。一方面技术积累和团队培养的时间周期会很长，会在竞争中失去先机；另一方面整个行业的人才资源也不足以支持这么多企业去完成“全栈自研”。

所以，从Tier2,Tier1到OEM，每个企业都应该找到适合自己的“自研”之路。芯片企业最熟悉自己芯片的AI 能力，可以开发基础的算法以及算法模型转换到工具链；擅长硬件设计的企业可以使用合适的芯片做出计算平台并集成好操作系统，以硬件Tier1 的身份向多家OEM 提供硬件计算平台或域控制器。软件Tier1开发完整的功能适配不同的硬件平台，同硬件Tier1 合作向OEM 完成功能交付。OEM 可以把自主研发的重点放在工程化能力的建设上（图18中的工程化阶段和量产阶段），这部分需要大量的投资以建立数据驱动的能力，而数据通道本来就是OEM 的固有优势。OEM 另外要重视的是数据如何能够被充分的利用，自己使用的同时开放给算法企业和软件Tier1使用。

<<: アンビエントコンピューティングが次の大きなトレンドになる理由

>>: AI検出器の仕組みの概要