自動運転のセキュリティ確保 - 主流のミドルウェア設計について

国内外の新車メーカーの急速な台頭により、自動車の知能レベルは向上し続けています。車両の中央コンピューティング プラットフォームと自動運転ドメイン コントローラーは、引き続き人気が高まっています。

自動運転というと、Mobileye の視覚認識、地図、さまざまな計画アルゴリズム、制御、ビッグデータなどの AI 技術を思い浮かべる人が多いかもしれません。現在、ますます多くの OEM が、データをより効率的かつ正確に通信する方法に注目しています。自動運転のレベルが L2 から L2++、さらには L3/L4 に移行するにつれて、データ伝送の要件はますます高くなっています。ミドルウェアの開発とアプリケーションが突如として最前線に押し上げられました。 ミドルウェアについて話すときは、まずオペレーティング システム OS について話す必要があります。

オペレーティング システムは、広義の定義と狭義の定義に分けられます。

狭義のオペレーティング システムは誰もがよく知っています。モバイル デバイスの iOS や Android、車載システムの Linux や QNX はすべて狭義のオペレーティング システムであり、通常、カーネル、ファイル システム、ドライバー、およびカーネルに統合されたいくつかのプロトコル スタックが含まれます。

広範なオペレーティング システムには、通常、オペレーティング システム カーネル、ハードウェア ドライバー層、およびミドルウェアが含まれます。新エネルギー自動車メーカーがソフトウェア定義自動車時代の到来について語る中、チップ、オペレーティングシステム、ミドルウェア、アルゴリズム、頻繁に使用される新しいアプリケーションを真に習得できる者だけが、テクノロジーの最前線に留まることができます。その中で、幅広いオペレーティングシステムは中核をなすものであり、国内外のOEM間の自主的な研究開発競争の方向となっています。

図1. 広義と狭義のOSブロック図

ミドルウェアについての話に戻りましょう。ミドルウェアとは何でしょうか? 文字通り翻訳すると、中間層のコンポーネントを意味します。実際には、オペレーティング システム/基盤ソフトウェアとアプリケーション ソフトウェア間のブリッジです。システムソフトウェア全体は、ミドルウェアを通じて、異なるプロセッサアーキテクチャとチップ間でデータを共有できます。

成熟したミドルウェアのセットは、多くの場合、開発に飛躍的なメリットをもたらし、開発サイクルとシステムの安定性を大幅に短縮し、基盤となるハードウェアの違いを遮断し、統一された API インターフェイスを実現します。

図2 自動運転ミドルウェアアプリケーション

では、自動運転にはどのようなミドルウェアが必要なのでしょうか?低レイテンシ、高帯域幅、高同時実行性。

車両全体の機能領域の観点から見ると、自動運転は外部センサーデータを最も多く収集するモジュールです。車両周囲のさまざまな複雑な環境情報を継続的に検出するためには、ミリ波、カメラ、ライダーが連携して死角のない360度認識を実現する必要があります。また、セキュリティを確保するには、すべてのデータをほぼリアルタイムの速度で処理する必要があります。大量のデータをリアルタイムで処理するには、データ遅延を低く抑え、高性能なコンピューティング ユニットと高帯域幅のネットワーク通信が必要であり、異なるコア間でデータを簡単に共有できます。

図3 自動運転のための360度センサー認識の概略図

表1 センサーの一般的な帯域幅

上記の表から、自動運転機能が継続的に向上するにつれて、センサーの伝送データ帯域幅と伝送遅延に対する要件も増加していることがわかります。この需要に応えるため、業界内のさまざまな自動運転企業も、要件を満たす独自の自動運転ミドルウェアを開発しています。

アイセオリックス:

Bosch は、量産型 ADAS 市場で長年トップ 3 に数えられています。同社は、自動運転のための効率的なデータ転送をさらに緊急に必要としています。この目的のため、Michael Pöhnl のリーダーシップの下、中国語名「冰羚」、英語名「ICEORYX」で、自動運転専用のミドルウェア セットを開発しました。

前述の通り、自動運転に関わる大量の知覚データはシステム全体に素早く循環させる必要があるため、プロセス間通信（Inter Process Communication）という概念について触れなければなりません。最も一般的に使用されている Linux システムを例に挙げてみましょう。異なるプロセスが情報を送信または交換する場合、異なるプロセスの独立したアドレス空間により、データ転送時にデータが継続的にコピーされ、スタックが確立および解放されます。この価値を生成しないコピー プロセスは、多くのシステム リソースを無駄に占有し、予期しない遅延を引き起こします。

図4 プロセス間通信

上記の問題を解決するために、ICEORYX は、これまでの ADAS 量産プロジェクトで発生した問題を最適化する「ゼロコピー」メモリ共有テクノロジを設計しました。

この「ゼロコピー」方式では、定義済みのユニバーサルインターフェースを使用して、消費するデータ（画像の元の RGB またはレーザーポイントクラウドデータ）を ICEORYX が要求したメモリ空間に配置し、次に「カウンター」の概念を導入して、メモリ空間内の各データブロックが呼び出されたか解放されたかを記録します。カウンターが 0 の場合、データブロックを解放できることを意味します。この方法では、すべてのデータ呼び出しが共有メモリ領域で行われるため、各プロセスがデータを独自のプライベート ストレージにコピーする必要がなくなり、データ通信の効率が大幅に向上します。

以下はBoschの公式紹介資料からの写真です。共有メモリによるコピーは実は革新的な通信機構ではありませんが、ICEORYXではパブリッシュ/サブスクライブアーキテクチャとサービスディスカバリ、カウンターを組み合わせた機構を採用しています。コピーを回避する API を追加することで、真のゼロ コピー、つまり、単一のコピーを作成せずに発行者から加入者までエンドツーエンドのアプローチを実現します。

図5 ゼロコピー通信（参考1）

パブリッシャーは事前に適用されたメモリ ブロックにデータを書き込み、サブスクライバーはこれらのメモリ ブロックのリアルタイムの状態を受信し、どのメモリ ブロックが処理中であり、どのメモリ ブロックが解放されるかを知ることができます。サブスクライバーがデータ ブロックを読み取っている間に、パブリッシャーは時間的な干渉や遅延なしに再度書き込むことができます。これは、前のメモリ ブロックが読み取られている場合でも、パブリッシャーは以前に割り当てられた新しいメモリ ブロックで操作することを選択できるためです。

ICEORYX はオープンソースであり、Apache-2.0 ライセンスに基づいてライセンスされます。個人またはチームはソースコードを無料で使用できますが、ASIL-B または ASIL-D レベルの機能安全認証に合格する必要がある場合は、Bosch から関連する安全サービスも購入する必要があります。

現在、ICEORYX ミドルウェアの最大の課題は、OEM がそれを量産車両に迅速に搭載して市場に投入し、その価値を真にテストする必要があることです。さらに、レーザー点群データ、カメラRGGBフレーム、3Dミリ波レーダーターゲット情報、4Dミリ波レーダー点群情報、車両信号データなど、自動運転認識情報の種類が増えるにつれて、メモリブロックを効率的に申請して割り当てることも、真の「ゼロコピー」を実現するための前提条件であり、実際のプロジェクトでは継続的な磨きと最適化が必要です。

ROS2:

次に有名なROS2を見てみましょう。

ROS2について話すとき、まずROS（ロボットオペレーティングシステム）について話す必要があります。ROS2はROSから開発され、アップグレードされました。 ROS はもともと、3,000 を超える基本ライブラリ、柔軟なプロセス間通信メカニズム、低レベル ドライバー、ハードウェア抽象化などを含む、ロボットに適応するためのオープン ソース ソフトウェア システムとして開発されました。

前述のように、自動運転は非常に複雑で、安全性に対する要求も高く、車線検出、物体検出、障害物検出、意思決定、制御モジュールなどが含まれます。これらの異なる機能を持つモジュールを統合して、エンドツーエンドのシステムを形成する必要があります。そのため、適切なミドルウェア フレームワークを見つけるのは簡単ではありません。ROS は学術界やロボット業界で広く使用されており、柔軟なメッセージ メカニズムと豊富なデバッグ ツールを備えており、自動運転開発のニーズにぴったり合います。国内の自動運転の黄埔軍事アカデミーである Baidu が、初期の Apollo1.0/2.0 バージョンで ROS フレームワークを選択したことがわかりました。

しかし、実際の開発アプリケーションでは、開発者は自動運転への適応における ROS の欠点を発見しました。たとえば、ROS 通信遅延が大きすぎる場合、データをパブリッシュ ノードからサブスクライブ ノードにコピーする必要があります。これはロボット設計の障害にはならないかもしれませんが、自律走行システムのデータ伝送効率に大きく影響することは明らかです。さらに、ROS の単一のマスター ノード メカニズムもボトルネックになっています。すべてのサブノード通信は、単一の通信マスター ノードに依存する必要があります。マスターノードに障害が発生した場合、システム全体に影響が及びます。 ROS の明らかな欠陥を解決するために、Baidu Apollo はバージョン 3.5 以降、ROS に代わる自社開発の Cyber​​ RT フレームワークをリリースしました。

図6 マスター中心のROS相互作用メカニズム

ROS コミュニティと組織も欠点を認識し、2016 年末に ROS2 ベータ版を正式にリリースしました。新世代の ROS は、前世代の欠点を解決するために全体的なアーキテクチャの革新をもたらしました。

基盤となる ROS は、ROS 上のマスター モードをキャンセルする DDS (データ配信サービス) 通信メカニズムに基づいています。 DDS は、パブリッシュおよびサブスクライブ モデルに従ってグローバル データ ブロックを作成します。そうすると、データのすべての発行者または購読者はデータの参加者となり、グローバル データを読み書きできるようになります。同時に、ROS のトピック データ構造の概念も保持されます。

図7 トピックベースのパブリッシュ/サブスクライブプロセス

DDS のもう 1 つの重要な機能は、さまざまなシナリオでのさまざまなデータ転送のリアルタイム要件を満たす QoS (Quality of Service) をサポートしていることです。各データ転送は、QoS ポリシーを通じてさまざまなオプションで設定できます。ROS2 は、転送期限、信頼性転送、履歴情報などのポリシーをサポートしています。

図8 QoSポリシーをサポートするDDSメカニズム

もちろん、ROS2の全体的な安定性や応用事例は現時点ではROSに比べてはるかに劣りますが、上記のような特徴を持つROS2システムの登場を待ちたいと思います。

Zeekr Software and Electronics Center は、平等、多様性、共通の成長という価値観を堅持し、製品の究極を追求し続け、ユーザーに思いやりのある体験を提供します。当社は、中央コンピューティング、インテリジェント地域コントローラ、車両OTA、インテリジェントボディコントロール、車両ソフトウェアなどの分野から始めて、業界トップクラスの電子・電気アーキテクチャを構築し、スマート電気自動車を保護します。

現在、中央コンピューティングとゾーン コントローラ内で効率的な IPC 通信を開発しており、それを量産プロジェクトに適用しています。上記の共有メモリと DDS テクノロジに加えて、SOME/IP プロトコルも使用して、さまざまなサービス データ間の伝送効率を高めます。

図9 Zeekrミドルウェアのブロック図 

また、ZEEKR OSも集中的に開発・テストされており、中央コンピューティングSoCのコアミドルウェアとして、車両サービス（自動運転、車体電子制御、シャーシ、三電システム、スマートコックピットなどの機能の継続的な反復をサポート）を管理し、基本プラットフォーム、高度な階層化分離、分散管理を提供します。 ZEEKR OSを搭載した次世代3.0セントラルコンピューティングプラットフォームは、フルスタックの自社開発技術を採用し、効率的で安定した一連の車両ソフトウェアミドルウェアの構築に重点を置き、自動運転、SOA、車両OTAサービスに中核的な競争力と継続的なエンパワーメントを提供します。