点群処理、SLAM、三次元ビジョン、高精度地図などのコンテンツを共有するための公開アカウントですので、どなたでもご参加いただけますので、ご興味のある方は[email protected]までご連絡ください。学生の皆さんは、積極的に共有したり、コミュニケーションしたりすることを歓迎します。
背景の紹介
自動車業界における AUTOSAR は、自動車の相手先商標製品製造業者 (OEM)、サプライヤー、その他の業界メンバーからなる国際コンソーシアムです。彼らは 2003 年に最初のリファレンス アーキテクチャ AUTOSAR Classic をリリースしました。その焦点は、基盤となるハードウェアの動的アプリケーションから独立することではありません。しかし、SOA と自動運転の重要性が高まる中、2018 年にリリースされた 2 番目の標準 Adaptive AUTOSAR はこれらのニーズに対応しています。
ただし、動的で柔軟な通信モデルへの移行に直面しているのは自動車業界が初めてではありません。同様の進化が物理システムやロボット工学の分野でも起こっています。この文脈では、広く使用されている ROS1 (オープンソースのセット (ソフトウェア アーキテクチャ開発用のライブラリとツールセット) は、リアルタイム、セキュリティ、クロスプラットフォームの相互運用性のニーズを満たすことができませんが、後継の ROS2 はこれらの欠点を解決し、サービス指向の通信を実装します。ROS2 は、ソフトウェアのパッケージングや通信の研究環境で広く使用されており、自動車の電気/電子アーキテクチャの分野でも応用されています。現在では、高度に接続された車両 (SOA) のコンテキストにおける ADAS 機能とサービス指向アーキテクチャに関して、機能安全規格 (ISO26262) と、電気および/または電子システムに必要な自動車安全性水準 (ASIL) を満たす認定ソリューションさえあります。 ）、解決すべき問題はまだたくさんあります。
これに関連して、この記事では次の 2 つのドキュメントを組み合わせます。
ジャクリーン・ヘンル、マーティン・ストフェル。将来の車両のためのアーキテクチャ プラットフォーム: ROS2 と Adaptive AUTOSAR の比較
Apex.AI レポート:Adaptive Autosar および ROS 2
図に示すように、ROS2 と Adaptive AUTOSAR が比較され、自動車の電気/電子アーキテクチャにおける適応性が研究されています。
Adaptive AUTOSAR 標準化アーキテクチャに基づく ROS2 の類似点と相違点を比較する以下の比較は、その長所と短所、標準を使用する理由、および最新の車両の将来対応の電気/電子アーキテクチャへの適合性を特定することを目的としています。
序文
アダプティブ AUTOSAR 仕様と ROS2 の主な違いは、 ROS がロボット工学の分野で 12 年間使用および検証されてきたため、ROS2 では「最初にコードを作成してから標準化する」方式を採用していることです。アダプティブ AUTOSAR 部分は最初から書かれており、 Adaptive AUTOSARは、SOME/IP3、DLT4、UDS5 などの実証済みのテクノロジーに基づいて、「最初に指定してからコードを生成する」アプローチを採用しています。
ROS2 は、データのログ記録、再生、視覚化、デバッグのための大規模なコミュニティとツールの点で優れています。Python や Java などの他の言語とバンドルすることもできます。ROS2 は、個別の適応型 AUTOSAR ではなく、共通のオープン ソース ツールを活用します。 Adaptive AUTOSAR はサービス指向の SOME/IP を使用しますが、ROS2 はデータ指向の DDS を使用します。前者は UDP と TCP の間でのみ切り替えることができ、後者は QoS (Quality of Service) を備えています。DDS の存在により、共有メモリ (SHM) とゼロコピー実装のおかげで、ROS2 でのデータ転送は非常に効率的かつ高速になります。
2020年6月に長期サポート第2弾としてROS2 バージョンFがリリースされましたが、現時点では個々の適応型AUTOSAR実装の進捗状況や最新の仕様(19.03)に準拠しているかは不明ですが、ほとんどの実装がベースとなっていることが分かります。 18.03仕様です。一方、適応型 AUTOSAR 仕様は、ソフトウェアの更新と構成管理、および DEXT 診断管理の点で ROS2 よりも優れています。両方のテクノロジには、最新の C++ における利点と課題があります。最大の課題は次のとおりです。
1. 標準例外処理
2. 静的コンテナ (文字列、ベクトル、マッピング)
3. メモリ管理
現時点での最良の要約は次のとおりです。Adaptive AUTOSAR は既存の車載インフラストラクチャとの互換性に優れ、ROS2 はアプリケーション開発に優れており、両方のテクノロジーが運用環境で共存できるのが理想的です。
ROS2とは
ROS フレームワークは、複雑なマルチセンサー、マルチアクチュエーター システム用のソフトウェア開発タスクを簡素化するために設計されたソフトウェア ツール、ライブラリ、プロトコル、および API のコレクションです。ほとんどの場合、ロボット フレームワークの使用によって、ソフトウェア開発の一般的なアーキテクチャ原則が決まります。たとえば、ソフトウェアが集中型か分散型か、リアルタイムか非リアルタイムかなどに関係なく、重要なコンポーネントはミドルウェアであり、ロボット フレームワークの多くのコンポーネントを結合するための鍵となります。ミドルウェアは自動運転車にソフトウェアノードを提供するものであり、通信インフラストラクチャです。ROS フレームワークの一般的な使用例は、システムの上位レベル (ソフトウェア) コンポーネントと下位レベル (ハードウェア) コンポーネントの間に基本的なインターフェイスを提供することです。これらのインターフェイスとコンポーネントには、オペレーティング システム (OS) 固有のさまざまなドライバーが含まれており、1 人の開発者が開発するには長い時間がかかる場合があります。主に Open Robotics と ROS2 技術運営委員会によって開発された ROS2 には数千のユーザーがおり、数百の自動運転およびロボット企業によって使用されています。ROS2 のアーキテクチャを次の図に示します。
アダプティブ AUTOSAR とは
Adaptive AUTOSAR は、正式に定義された用語であり、「AUTOSAR Runtime for Adaptive Applications (ARA)」と説明されています。サービスと API の 2 種類のインターフェイスを提供するプラットフォームは、サービスごとにグループ化され、アダプティブ アプリケーションの基盤を形成する機能クラスターで構成されています。オートサー」。実際、これは、次と呼ばれる機能クラスターで構成される別のロボット フレームワークです。 このフレームワークの仕様は、Autosar コンソーシアムによって開発されました。実際の実装は、Elektrobit、Vector、ETAS、Mathworks、Aubass などの企業によって実行されます。開発作業はコンソーシアムのメンバーによって行われ、仕様のみが公開されます。Adaptive Autosar は、アプリケーションのプログラミング用の古典的な Autosar に基づいています。シングルコアマイクロコントローラーの場合。
サービス指向アーキテクチャとそのアーキテクチャ プラットフォームへの影響
システムとしての自動車の電子/電気 (E/E) アーキテクチャには、機械コンポーネントだけでなくソフトウェア (SW) およびハードウェア (HW) コンポーネントも含まれます。従来の分散アーキテクチャは、HW と SW が多くの電子制御ユニット (ECU) 上で緊密に結合されていることを特徴としています。これに対し、サービス指向アーキテクチャでは、アプリケーションソフトウェアと実行ハードウェアを独立させ、疎結合アーキテクチャを実現するために、オペレーティングシステム（OS）とミドルウェアが重要な役割を果たします。ミドルウェア層は主に ECU 間の通信を担当します。したがって、ミドルウェアの要件には、車両アーキテクチャ全体内、またはクラウドやバックエンド インフラストラクチャとの抽象化および仮想化された通信の実行が含まれます。これらのシステム コンポーネント間の通信は、システム実行中に非常に重要です。開発期間は不明である可能性がある. したがって、コネクテッド システムでは通信は動的であり、リンクは実行時に柔軟に確立される必要がある. コネクテッド カーとサービス指向アーキテクチャで生成される大量のデータは、E/E における新しいプロトコルにつながっていますアーキテクチャとの統合。Adaptive AUTOSAR 仕様で指定されている動的通信用の車載リファレンス アーキテクチャとして、機能アプリケーションと POSIX 準拠のオペレーティング システムは、Adaptive Application Runtime Environment (ARA) と呼ばれるモジュール層から分離されています。下の写真を参照してください。
アダプティブAUTOSARの構造
ARA では、インターフェイスとサービスが定義され、オペレーティング システムのアクセスと通信ミドルウェアを指定して、イーサネットに基づくサービス指向アーキテクチャを実装します。Adaptive AUTOSAR の最初のバージョンでは、拡張可能なサービス指向 IP ミドルウェア (SOME/IP) が、対応する標準化されたアーキテクチャのミドルウェア プロトコルとして指定されました。自動車指向のミドルウェア ソリューションに加えて、DDS は自動車固有ではない代替手段です。Adaptive AUTOSAR にはバージョン 18 ～ 10 から DDS が含まれていますが、ROS2 は最初から DDS 上に構築されており、他のミドルウェアは提供しません。DDS の統合は、これは、自動車標準の Adaptive AUTOSAR を強化する、業界固有ではないミドルウェア ソリューションの例です。
ROS2の構造
この開発と並行して、ロボット アプリケーションに由来する ROS2 が自動車業界に参入しました。Adaptive AUTOSAR とは対照的に、ROS2 はオープン ソースであり、メンバーシップやライセンス料は必要ありません。ROS コミュニティによって提供される調整されていない実装は正式に認定されていません。適切ではありません。車両システムのリアルタイム アプリケーション向け。しかし、最近、車載ソフトウェア会社が開発した ROS2 ベースの商用リアルタイム オペレーティング システム (RTOS) が ASIL-D アプリケーションとして認定されたため、これらの開発に触発されて、ROS2 のアーキテクチャと適応型 AUTOSAR ベースのモジュール構造との比較を実施しました。以下の比較を行う。
Adaptive AUTOSAR と ROS2 は、実行ハードウェアとアプリケーションを分離する階層を提供します。これらのプラットフォームの全体構造を比較すると、Adaptive AUTOSAR アプリケーション プログラミング インターフェイス (API) のネーミングが、ROS2 の意図された機能の印象を与えていることがわかります。同じ程度に解釈するのは簡単ではないため、ROS2 のクライアント ライブラリと抽象 DDS レイヤーの範囲と内容を適応型 AUTOSAR アーキテクチャと比較する必要があります。Adaptive AUTOSAR は自動車業界の標準であるため、この業界における ROS2 の適用性を評価したいと考え、Adaptive AUTOSAR の機能と主要な利点に基づいて 2 つのプラットフォームを比較します。アダプティブ AUTOSAR アーキテクチャの中核は、機能セットによって提供されるアダプティブ API を含む ARA です。機能セットは、ARA およびイントラプラットフォーム アプリケーションにアクセスするための API を提供する Adaptive Platform Foundation または Adaptive Platform Services として分類され、アプリケーションとネットワークの観点からソフトウェア プラットフォームの動作を記述しますが、ソフトウェア設計をさらに指定するものではありません。相互にサービスを提供したり、非プラットフォーム サービスと対話したりできます。
Adaptive AUTOSAR アーキテクチャと ROS2 の違い
コミュニケーション管理
Adaptive AUTOSAR では、アプリケーションの通信と情報共有は、通信管理 (CM) API パッケージによって組織されます。このようにして、プラットフォームのさまざまなレベル間のサービス指向の通信が実装および監視されます。CM はまた、マシン内およびマシン間通信です。API では、実装されるミドルウェア プロトコルとして SOME/IP が指定されており、DDS はバージョン 18-10 で追加されました。DDS と SOME/IP は共通の特徴を持っていますが、重要な違いがあります。
SOME/IP はオブジェクト ベースのサービス指向通信を実装します。加入者のサービス クラスは開発プロセス中に事前に定義する必要があるため、ある程度静的です。対照的に、DDS は送信者と受信者を通じて動的に動作します。タイム ディスカバリは実装されます。動的なランタイム検出が可能になり、静的なサービス仕様が必要ないため、相互運用性と柔軟性が向上します。DDS は、リアルタイム トランスポート プロトコル (RTPS) に基づいたパブリッシュ/サブスクライブ機能を実装し、高度なデータ管理機能を提供することでこのトランスポート プロトコルを活用します。さらに、他のプロトコルを追加することもできます。SOME/IP では、ユーザー データグラム プロトコル (UDP) または伝送制御プロトコル (TCP) を使用して、公開情報をすべての加入者にブロードキャストできます。SOME/IP のイベント ドリブン通信では、データの現在のスナップショットを提供でき、フィールドベースの通信では、読み取り/書き込み権限と受信者のデータ履歴を使用してデータを転送できます。もう 1 つの機能は、メソッドベースのリモート プロシージャ コール (RPC) です。これにより、クライアントは要求に応じて特定の関数を起動し、データを含むメッセージを返すことができます。DDS では 3 つの通信方法が定義されています。トピックに基づいてメッセージをサブスクライバに送信することも、クライアントがサービスを呼び出して受信者に配信することもできます。3 番目のモードは 2 つのアプローチを組み合わせたものです。ターゲットが公開され、受信者に定期的に送信されるフィードバックがトリガーされます。
Adaptive AUTOSAR では、開発中、システム起動時、または実行時に通信パスとサービス定義を動的に確立できます。さらに、Adaptive AUTOSAR は信号ベースのネットワーク バインディングを指定し、対応する通信アプリケーションをサービス指向の通信アプリケーションに変換できるようにします。
ROS2 は rmw という名前のミドルウェア API を定義し、RTPS と組み合わせた DDS のアプリケーションに依存しない統合を可能にします。唯一のミドルウェア フレームワーク ソリューションとして、Adaptive AUTOSAR と ROS2 は両方ともゼロコピー機能を提供し、自動車業界で広く使用されています。標準化されたプロセス間通信。さらに、ROS2 の通信はノードを通じて組織され、各ノードがシステムに機能を提供し、パブリッシュ/サブスクライブ通信が分散型で実装され、適応型 AUTOSAR とは異なり、中間マスター ノードなしでノードが相互に検出します。ROS2 のノードは、設計時に統合されますが、サービス検出は実行時にのみ行われます。これは 2 つのプラットフォームの主な違いであり、アダプティブ AUTOSAR の CM により、動的通信が必要ない場合のオーバーヘッドの削減が可能になります。
執行管理
Adaptive AUTOSAR の API は、認証、アプリケーションの起動とシャットダウンなど、プラットフォームとアプリケーションのライフサイクル管理に関連する機能を実装します。EM はオペレーティング システムと対話し、実行時にアプリケーションをスケジュールします。これにより、アプリケーションは優先度別に整理され、実行チェックリストで関連する他のトピックが指定されます。これは、通信を通じてリソース割り当てを制御するだけでなく、特定のアプリケーション用にリソースを静的に設定する可能性を明確に定義しています。
ROS2 の実行管理は、rcl API の起動ファイルによって構成されます。実行は、エグゼキュータ (Executor) によって実装されます。この概念は、オペレーティング システムのスレッドを使用してコールバック関数、実行タイマー、サービス サーバー、およびアクション サーバーを実装することに基づいています。受信メッセージとイベントを処理します。ROS2 の標準エグゼキュータは決定性を保証しませんが、この目標を達成するために調整および最適化することができます。ただし、そのような調整は現在 ROS2 に基づく商用ソリューションでのみ見られ、標準のオープンソース実装の一部ではありません。さらに、ROS2 標準アクチュエータを使用する場合には他のリアルタイム性や効率性の問題も発生するため、自動車業界の要件を満たすにはまだ改善の余地があると思われます。
コアの種類
コア タイプ API パッケージは、アダプティブ プラットフォームのすべての機能クラスターに適用される基本要件を定義します。これには、ARA レイヤーに含まれるすべての共有ライブラリを初期化するための集中初期化関数が含まれています。各アダプティブ アプリケーションに対してこの関数をエントリ ポイントとして呼び出すことをお勧めします。 , さらに、エラー処理について説明し、エラー、違反、破損を区別します。エラーは適応関数の戻り値であり、通常は入力データによって引き起こされます。違反とは、回復できない適応プラットフォームの内部状態を指します。破損は、スタック、ヒープ、ハードウェアなどのシステム リソースの破損の結果です。アプリケーション開発者にとって、違反や破損はハードウェアの故障など、システム環境における重大な問題を示している可能性があるため、エラーは予期されるものにすぎません。さらに、コア タイプ API はアダプティブ プラットフォームで一般的に使用されるデータ型を定義し、プラットフォーム タイプ パッケージは整数、倍精度浮動小数点数、または浮動小数点などの標準型を記述し、コア タイプ パッケージは配列やベクトルなどのデータ型を定義します。さらに、例外またはエラーが発生した場合の戻りデータ型も定義します。
アダプティブ AUTOSAR と同様に、ROS2 のクライアント ライブラリ clcpp を最初に初期化する必要があります。クライアント ライブラリには、無効なノード名またはトピック名、不正な関数パラメータ、実行時エラーなどの不正な定義も含まれています。ただし、エラー、違反、破損の明確な区別は明示的には説明されていません。したがって、どのエラーがプロセス全体の中止または例外のスローを引き起こしたかを判断する方法はありません。
ROS2 アプリケーションは通常、メッセージ、サービス、操作などのインターフェイスを介して通信します。インターフェイスには複数のフィールドが含まれます。各フィールドにはフィールド タイプとフィールド名があります。組み込みフィールド タイプには、ブール、整数、文字、浮動小数点、倍精度が含まれます浮動小数点数と文字列。静的、境界付きまたは境界なしの動的配列、または境界付き文字列を定義するために使用できます。また、これらのタイプの組み合わせを使用してカスタム メッセージを作成できます。この点では適応型 AUTOSAR と同様です。
表現型状態転送（RESTful）
CM API パッケージはアダプティブ アプリケーション間のサービス指向の通信をカバーしますが、Representational State Transfer (RESTful) API パッケージは、リソース制約をあまり公開しないモバイル ドメインの RESTful サービスとは異なり、Web サービス ベースの通信オプションを提供します。自動車アプリケーション向けに最適化されており、低レイテンシで確定的なメモリと処理時間を提供します。CM パッケージの API はバイト レベルで正確に定義されているため、そのほとんどは静的データを扱いますが、RESTful API は通常、Uniform Resource Identifier (URI) と組み合わせて非同期処理で動的データを扱います。RESTful API の実装に関しては、現時点では ROS2 専用のパッケージはありません。ただし、ROS バージョンの Indigo または Kinetic については、ROSTful と呼ばれるパッケージが存在し、それを ROS2 パッケージとして移植できるかどうか、いつ移植できるかは予測できません。ROS2 で非同期データ処理を実装するもう 1 つの方法は、アクションを使用することです。クライアントはリモート プロシージャ コールと同様にアクションを呼び出し、複数のデータ パラメータを渡すことができます。その後、アクションはデータを処理し、完了時にコールバックを実行します。アクション Adaptive AUTOSAR の RESTful API に似ていますが、まったく同じではなく、ROS2 は RESTful API の特性を完全には満たしていません。
永続性
Adaptive AUTOSAR は、揮発性ストレージの使用に加えて、起動および点火後の情報の永続性を明示的に指定します。一方、ROS2 は、データの永続性に関して基礎となる DDS 実装によって制限されています。Cyclone DDS では、バージョン 0.9 より前では一時メモリと永続メモリは使用されないと述べています。現在のバージョン 0.8.2 は、データの揮発性ストレージのみをサポートしているため、 Adaptive AUTOSAR 永続化機能の要件を部分的に満たしていると考えられます。
時刻同期
時刻同期に関しては、Adaptive AUTOSAR と ROS2 はどちらも同様のアプローチを採用しています。Adaptive AUTOSAR では、マスター クロックとスレーブ クロックが同期され、通常は同期に Network Time Protocol (NTP) が使用されますが、Precision Time Protocol (PTP) が使用されます。は精度の高い代替手段であり、ROS2 ではメッセージを相互に同期したり、異なるクロックを選択して同期したりすることもでき、同じ PTP が最高の精度を達成するソリューションです。
プラットフォームの健全性管理
Adaptive AUTOSAR は、アプリケーションの時間制約、論理プログラム フロー、プラットフォーム ステータスを監視します。エラーが検出されると、ステータス管理モジュールに通知され、エラー処理方法が決定されます。さらに、プラットフォームの健全性管理はハードウェア ウォッチドッグと対話します。重大な障害が発生した場合にはウォッチドッグ応答をトリガーできますが、ステータス管理モジュールに通知するだけでは十分ではありません。ただし、プラットフォームの健全性管理と他の機能クラスター間のインターフェイスは情報のみを目的としており、標準化されていません。ROS2 では、これらの機能はデフォルトでは実装されていません。ただし、ROS2 のオープンソース ドキュメントによると、プラットフォームの健全性管理は実現できます。この機能は、たとえば、エラー発生時にログ機能を使用してさまざまな回復ルーチンをトリガーすることによって実現できます。
ID アクセス管理
Adaptive AUTOSAR Identity and Access Management (IAM) は、x.509 証明書を使用し、リソース アクセスの認証と認可を担当し、ECU 間および ECU 内のアクセス制御を提供します。ROS2 は、x.509 証明書を使用して、提供されている DDS セキュリティ プラグイン「DS:Access:Permission」の許可ファイルを使用してアクセス制御を実装します。ROS2 のアクセス制御と認可メカニズムは、DDS によって実装された「DDS:Auth:PKI-DH」プラグインによって提供される公開キー インフラストラクチャを使用します。2 つのプラットフォームの主な違いは、AUTOSAR が ECU 内で適応型認証と認可を提供することです。一方、ROS2 はこの点に関して明確な立場をとっておらず、現時点ではこの目的に利用できるチューニング オプションは見つかりません。
診断
Diagnostics API パッケージは、対応する ISO 14229-1 標準に準拠した統合診断サービス (UDS) の準拠実装を記述します。現在、イーサネットベースの Diagnostics over IP (DoIP) レイヤー上で機能を提供していますが、CAN などの従来の自動車ネットワークを含むように拡張されることが期待されています。ROS2 には UDS 準拠の診断機能が含まれていません。公式の ROS2 パッケージ インデックス フォルダーにはいくつかの診断パッケージが含まれていますが、それらは UDS に関連していないため、ISO 14229-1 標準に準拠していません。
ログとトレース
Adaptive AUTOSAR では、ロギングとトレースは、アプリケーションのロギングとトレース用の API を提供します。生成された情報は重大度に従って分類され、さまざまなケース (安全性とセキュリティのトピックなど) に関連付けることができます。AUTOSAR アライアンスは、ログ情報を表現するための標準プロトコルと、対応するデータ分析ツールを提供します。ROS2 の場合は、ロギングとセキュリティ ツールがあります。追跡ソフトウェアパッケージ。これらのほとんどはバイナリ パッケージの一部ではありませんが、必要に応じて統合できます。トレース パッケージは、ランタイムと実行データ、システムとコンポーネントの動作、およびそれらの分析を記録できます。ファイルを追跡するための分析ツールも推奨されます。ROS2 の主な欠点は、そのログ機能がリアルタイム要件に準拠しておらず、一部のログ エントリの信頼性に問題があることです。これらの問題が Adaptive AUTOSAR にも存在するかどうかは不明ですが、安全で信頼性の高い E/E アーキテクチャには確実に必要な要件です。
暗号化
暗号化プログラムに関しては、Adaptive AUTOSAR プラットフォームは、乱数生成、Advanced Encryption Standard、非対称暗号化 Rivest-Shamir-Adleman (RSA)、ハッシュ関数を含む暗号化スタック「ara::sec::crypto」へのインターフェイスを定義します。 、メディア アクセス コントロール アドレス (MAC)、およびキー交換メカニズム。AUTOSAR は、X.509 証明書などの暗号オブジェクトの処理もサポートします。ROS2 のセキュリティ機能は、「DDS:Crypto:AES-GCM-GMAC」と呼ばれる DDS 標準のセキュリティ プラグインに基づいており、暗号化、復号化、および暗号化を処理する公開キー インフラストラクチャである Advanced Encryption Standard のガロア カウンター モードを使用します。署名とハッシュ。DDS のすべてのセキュリティ機能はデフォルトで無効になっているため、ユーザーは ROS2 セキュリティ ツールを使用して有効にする必要があります。Adaptive AUTOSAR と ROS2 はどちらも同じ機能を提供しますが、ROS2 では手動でアクティブ化する必要があります。
状態管理
状態管理は、プラットフォームの健全性管理、診断管理、更新と構成の管理、ネットワーク管理などの他の Adaptive AUTOSAR プラットフォーム アプリケーションからイベントを受け取ります。これらのイベントには、実行マネージャーに状態遷移の実行を要求するための状態マネージャーへの入力としてのイベント タイプ、優先順位、およびアプリケーション ID が含まれます。たとえば、プラットフォームの健全性管理は、状態管理サービスを通じてエラー回復をトリガーできます。このサービスは、実行マネージャーに対応する機能を再起動するように要求します。また、診断管理は、システムを別の診断状態に切り替えるか、更新と構成管理を開始してシャットダウンするように要求できます。診断および更新中、ステータス管理はネットワーク管理を使用して、診断または更新中にネットワークの動作を維持します。
ROS2 には同様の診断機能や更新機能がありません。ただし、中断されたプロセスの回復は、サービス品質 (QoS) 機能を使用して実現できます。プロセスが使用不可であることを識別することで、回復メカニズムを開始できます。ただし、QoSオプションは基礎となる DDS 実装の一部であり、ROS2 の間接的な機能にすぎません。
更新と構成の管理
Adaptive AUTOSAR の更新および構成管理は、更新要求、更新自体、およびソフトウェアの変更を処理するインターフェイスです。無線更新 (OTA) の実装を担当し、インストールおよび更新プロセスとソフトウェア コンポーネントの削除および追跡を組み合わせます。この目的を達成するために。このサービスは、dpkg や Yellowdog Updater, Modified (YUM) などの Linux パッケージ マネージャーに似ており、承認されたソフトウェア更新のみを実行します。また、バリアント固有の構成と機能検証、および更新後のその他すべてのプロセスも可能になります。ROS2 には、継続的インテグレーション (CI) と継続的開発のための 2 つのパッケージがあります。Open Robotics によって提供されるビルド ファクトリ内の ROS2 スクリプトとテンプレート、および PR が発生したときに実行されるプル リクエスト (PR) ビルド パッケージとテスト パッケージです。 Linux 上でのみ動作し、リポジトリ間では動作しません。これらの制限を補うために、CI ビルド パッケージもあります。これは PR ビルドとは異なり、自動的に実行およびテストされません。また、そのテスト活動は更新されたコンポーネントに限定されず、すべてのプラットフォーム上のすべてのパッケージをテストします。時間の制約により、テストの範囲が制限される場合もあります。機能を更新するには、パッケージ管理者が継続的にパッケージをリリースする必要があります。全体として、この機能は Adaptive AUTOSAR サービスに似ているように見えます。
違いを要約する
上の表は、Adaptive AUTOSAR API 機能を備えた ROS2 の機能の概要を示しています。ただし、この文脈では、ROS と ROS2 はもともとロボット工学アプリケーション用のソリューションとして開発されたことを言及する価値があります。この出発点から、現在では自動運転ソリューションで利用可能です。
ROS/ROS2 の成功の理由の 1 つは、自動車エンジニアが AUTOSAR の代替案を探している可能性があることです。このプラットフォームの標準化内容は非常に大きく、仕様に準拠するために必要な作業負荷が特に高いと思われるためです。 AUTOSAR の経験がない方 開発者向け。標準への準拠に必要な労力の量は、ソフトウェア プロジェクトの規模に比例して不釣り合いに増加するという事実に加え、ROS/ROS2 ソリューションは、疎結合がリードするノードを使用して対話のための機能を実装するように明示的に設計された有望な代替手段であると思われます。モジュール性、拡張性、調整性が向上し、より迅速な開発が可能になります。
さらに、ROS2 は、アプリケーション開発タスクを簡素化するさまざまな機能を提供します。例としては、ノード内通信の実装に直接使用できる、事前定義されたロボット固有のメッセージ タイプがあります。さらに、ROS2 は、データを記録、再生、視覚化できる強力なコード デバッグ ツールを提供しており、たとえば、RQT-Graph はノード間の通信を表示して、システムの論理アーキテクチャをボトムアップから推測できます。もう 1 つの例は、センサー データと環境内の車両の位置を視覚化する RVIZ です。プラットフォームの開発方法に関しては、すべてモデルベースのアプローチに従っています。コーディングに関しては、Adaptive AUTOSAR プラットフォームでは、自動車業界の既存のガイドラインに基づいて、よりシンプルな分散システム構造を実現するための標準として C++14 を使用するためのガイドラインが定義されています。ROS2 のクライアント ライブラリは、API 使用の一貫性と適用性を確保するために使用されるコードのセットです。これらのライブラリを使用すると、ユーザーは ROS2 の概念にアクセスしてアプリケーションを構築できます。さまざまなプログラミング言語で使用できるクライアント ライブラリがあります。ROS2 ドキュメントには、一貫した製品の目標をサポートするコーディング スタイル ガイドも提供されています。
2 つのプラットフォームの主な違いの 1 つは、AUTOSAR 標準がオープンソースではないことです。ドキュメントにアクセスするには、標準の仕様と評価にも貢献している約 300 の組織からなるグローバル コンソーシアムのメンバーシップが必要です。ライセンス料がかかります。また、無料で利用できる AUTOSAR ライセンスのツールはありません。対照的に、ROS ライブラリと関連ドキュメントはオープン ソースであり、開発者コミュニティは、変更用にカスタマイズできる追加のパッケージとコード ライブラリを提供しています。AUTOSAR のもう 1 つの制限はドキュメントの品質が低いため、これは非常に重要です。一方で、オープンソースではない ROS2 ベースのソリューション、特に最近認定された非公開の自動車固有のソリューションもあります。その場合、オープンソースに関連するメリットが十分に享受できない可能性がありますが、自動車固有のソリューションは適応は有益であると思われ、ROS コミュニティが表 1 で特定された最も重要なギャップを埋めることができれば、ここで述べた利点により、ROS が自動運転領域から他の自動車領域に拡張できるようになり、成熟した AUTOSAR のフレームワークが形成される可能性があります。標準に代わる現実的な選択肢。
ROS2 のその他の主な利点
1. Adaptive Autosar コンポーネントはプロセスです。ROS2 では、コンポーネントはノードであり、プロセスは複数のノードを持つことができます。
2. Adaptive Autosar はアプリケーション層でのみ C++ を使用し、ROS2 プロトタイプは Python などの他の言語で記述することもできます。
3. Adaptive Autosar はデータの記録、再生、視覚化、またはデバッグ ツールを提供していません。特に大規模なデータの記録は完全に欠けているようです。
4. Adaptive Autosar はサービスベースの SOME/IP を使用し、ROS2 はデータベースの DDS を使用します。前者は UDP と TCP の間でのみ切り替えることができますが、後者には QoS (サービス品質) があります。
5. ROS2 にはオープンソース実装が 1 つだけあり、数千のユーザーが使用しています。Adaptive Autosar にはクローズドソースの実装が複数ありますが、それらは相互にほとんど互換性がありません。
6. ROS2 は、共有メモリやゼロコピー (RTI Connext Micro 経由) などの高性能データ転送プロトコルをサポートします。
7. ROS2 には、Velodyne VLP-16 HiRes などのデバイス ドライバーのリファレンス実装が含まれています。
8. ROS2 は、静的変換ライブラリ、認定数学ライブラリのいくつかの関数、トピック同期のための時間同期ライブラリなどのいくつかのツールを提供します。
結論
Adaptive AUTOSAR と ROS2 のアーキテクチャとコンテンツは、現在の自動車アーキテクチャ開発の課題に関連して説明されています。許可ベースの適応型プラットフォームは、自動車におけるサービス指向アーキテクチャへの傾向に合わせて特別に調整されていますが、オープンソース ROS2 は当初、次のようなユーザーを対象としていました。アダプティブ AUTOSAR で規定されているレイヤと API からアプリケーションを始め、ROS2 アーキテクチャと AUTOSAR プラットフォームのアダプティブ機能セットの対応度について説明します アダプティブ AUTOSAR は ROS2 よりも標準化されており、開発プロセスの標準も提供しています業界内の相互運用性と一貫した仕様により、プラットフォームは本質的に自動車要件、特に安全面を満たします。
ROS2 はそれほど多くのサービス、API、またはプロセス標準を指定していませんが、コミュニティは追加機能を備えたパッケージを提供しています。表 I の結論で指摘されているように、ROS2 は適応型 AUTOSAR の API およびサービス機能の一部を完全に満たすことができます。標準実装では自動車関連のすべての機能が提供されるわけではありませんが、パッケージやカスタム設定を追加することで調整できます。一方、Adaptive AUTOSAR には ROS2 によって部分的に実装された機能がありますが、Filling に追加のパッケージがあるかどうかは不明ですさらに、API のさまざまな部分で説明されているように、Adaptive AUTOSAR が提供する API には ROS2 実装では満たされていない分析に基づくギャップがあり、これらのギャップは場合によっては必須である場合があります (ネットワーク管理など)。 ROS2 に基づく商用バージョンの安全性認証は、対応する調整と設計により、自動車のサービス指向アーキテクチャ要件に準拠できることを示しています。これは、ROS2 の書き換え部分を明示的に参照しています。アダプティブ AUTOSAR と比較して、リアルタイム機能とメモリ管理を強化するオープンソース実装により、新規ユーザーは何の障壁もなくアーキテクチャ開発に ROS2 を使い始めることができます。
参考文献
【1】ジャクリーン・ヘンル、マーティン・ストフェル。将来の車両のためのアーキテクチャ プラットフォーム: ROS2 と Adaptive AUTOSAR の比較
【2】Apex.AIレポート：Adaptive AutosarとROS 2
さらに詳細なコンテンツについては、バックグラウンドで「Knowledge Planet」を送信し、Knowledge Planet に参加して詳細をご覧ください。
リソース
自動運転・測位関連のシェアリング
[点群論文の早読み] LIDAR に基づく走行距離計と 3D 点群マップでの測位方法
セマンティックセグメンテーションに基づくカメラの外部パラメータの調整
復習: 自動運転用パノラマ魚眼カメラの理論モデルと認識の紹介
Patchwork++: 点群に基づく高速かつ堅牢な地面セグメンテーション手法
PaGO-LOAM: 地上ベースの最適化された LIDAR オドメトリ
複数の LIDAR のキャリブレーション、位置決め、マッピングを同時に行うためのフレームワーク
動的な都市環境におけるロッドの抽出、マッピング、および長期的な位置特定
3D 点群セマンティック セグメンテーション用のアノテーション ツールと都市データセット
ソリッドステート LIDAR およびカメラ システムの自動キャリブレーション
LiDAR+GPS+IMU+ホイールスピードメーターのセンサーフュージョン測位ソリューション
まばらなセマンティックな視覚的特徴に基づいた道路シーンのマッピングと配置
自動運転における LIDAR に基づく車両の道路と歩道のリアルタイム検出 (コードオープンソース)
3D 点群セマンティック セグメンテーション用のアノテーション ツールと都市データセット
その他の記事もご覧いただけます:点群学習に関する過去の記事の概要
SLAM および AR 関連の共有
構造化 PLP-SLAM: 点、線、面を使用した単眼カメラ、RGB-D カメラ、および双眼カメラ向けの効率的なスパース マッピングおよび位置決めソリューション
オープンソースの最適化された F-LOAM ソリューション: 最適化された SC-F-LOAM に基づく
【オープンソースソリューション共有】ORB-SLAM3はオープンソースです！
[ペーパークイックリーディング] AVP-SLAM: 自動駐車システムにおけるセマンティック SLAM
[点群論文の早読み] StructSLAM: 構造化線特徴 SLAM
AR機器用単眼視覚慣性航法SLAMアルゴリズムのレビューと評価
SLAM の概要 (4) レーザーとビジョンの融合 SLAM
Kimera によるリアルタイム再構築のためのセマンティック SLAM システム
SLAM の概要 (3) - ビジョンと慣性航法、ビジョンとディープラーニング SLAM
拡張が簡単な SLAM フレームワーク - OpenVSLAM
Gao Xiang: 非構造化道路レーザー SLAM の課題
3D ビジョンと点群学習プラネット: 主にインテリジェント運転フルスタック関連技術を目的とした、3D/2D ビジョン技術の学習と共有のためのナレッジ プラネットは、実践的な技術を共有し、ナレッジ ポイントを要約し、コードの問題を解決し、最新の情報を共有し続けます。紙の提出、質問への回答など。Planet は、さまざまな分野で継続的な共有機能を持つ著名人を招待し、初心者に技術的な指導を提供し、躊躇することなく質問に答えます。同時に、Planet は有名企業と協力して、自動運転やマシンビジョンなどの関連求人情報や紹介機会をリリースし、学習や雇用において共有し、互いに助け合うことができる技術人材のクラスターを形成します。
上記内容に誤りがございましたら、コメントを残していただき、修正や交換を歓迎いたします。侵害がある場合は、削除するためにご連絡ください。
QRコードをスキャンします
私たちに従ってください
一緒に共有して学びましょう！アイデアを持ち、喜んで共有する友人がナレッジ プラネットに参加し、共有に新たな活力を注入してくれることを楽しみにしています。共有されるトピックには、3 次元ビジョン、点群、高精度地図、自動運転、ロボット、その他の関連分野が含まれますが、これらに限定されません。
共有・協力方法：WeChat「cloudpoint9527」（備考：名前+学校/企業+研究方向） 連絡先メールアドレス：[email protected]。
「見た目」をクリックすると、見た目が良くなります。
