まとめ：
SOA (サービス指向アーキテクチャ) のソフトウェア設計原則の 1 つはモジュール性です。
序文
SOA (サービス指向アーキテクチャ) のソフトウェア設計原則の 1 つはモジュール性です。モジュール化により、ソフトウェア システムの保守性とコードの再利用性が向上し、障害を切り分けることができます。たとえば、自動運転システムは、データ収集、状態推定、ミッション計画などの特定のタスク モジュールに分解できます。それぞれのタスクを完了するには、これらのモジュールは相互に情報を交換する必要があります。最新のオペレーティング システムでは、個々のモジュールを独立したソフトウェア プロセスにマップすると便利です。これらのプロセスは、同じコンピューティング デバイス上に配置することも、物理的に別個のコンピューティング デバイス上に配置することもできます。情報交換はプロセス間通信を通じて行われるため、プロセス間通信は深く研究された問題になります。
1. 通信ミドルウェア
ソフトウェア デファインド カーでは、アプリケーション間のクロスプロセスまたはクロスコア通信が解決する必要がある問題です。モジュラー アーキテクチャは開発者に利便性を提供しますが、通信ミドルウェアも必要になります。
通信ミドルウェアを使用しない場合、開発者はデータの形式、送信者、受信者を自分で定義する必要があります。ただし、サービス/データベースのパブリッシュおよびサブスクライブ パターン (SOME/IP や DDS など) を使用すると、開発者は、データが誰にどのように配信されるかに注意を払うことなく、どのデータが必要か、そしてデータがどこに配信されるべきかを明確にするだけで済みます。が送信されます。
データ中心は従来のメッセージ中心と比較されますが、本質的な違いは、通信ミドルウェアがどのようなデータが保存されているかを認識し、データの共有方法を制御できることです。従来のメッセージ中心のミドルウェアでは、プログラマはメッセージを送信するためのコードを記述する必要がありましたが、データ中心のミドルウェアでは、プログラマはデータを共有する方法のコードを記述するだけで、データ値を直接共有できます。
通信ミドルウェアは、ポイントツーポイント、メッセージ キュー、パブリッシュ/サブスクライブの 3 つの動作モードを採用でき、 SOME/IP と DDS は両方ともパブリッシュ/サブスクライブ モードを採用します。
パブリッシュ/サブスクライブ モデルでは、パブリッシャーとサブスクライバーはトピックを通じて関連付けられ、双方が相手の所在地を知る必要も、同時にオンラインである必要もありません。これにより、時間、空間、データ通信における通信当事者の多次元的な疎結合が実現されます。
さらに、信号指向の CAN と比較すると、DDS と SOME/IP は両方ともサービス指向の通信プロトコルです。2 つの違いは、シグナル指向のデータ転送は常にループで送信されるのに対し、サービス指向の通信は、クライアントが要求したとき、またはサーバーが特定の加入者に通知したときにのみクライアント/サーバー構成でデータが交換される点で異なります。 。これにより、帯域幅が決して無駄にならず、必要なとき、必要な場所でのみデータが通信/交換されることが保証されます。したがって、サービス指向の通信プロトコルはネットワーク負荷を大幅に軽減し、通信効率を向上させることができます。
ソフトウェア デファインド カーの時代では、車内のすべての呼び出し可能な機能はサービスとみなされ、さまざまなタイプの呼び出しインターフェイスが提供されます。これらのインターフェイスは次のように分類できます。
1. API インターフェース: さまざまな関数の呼び出しインターフェースを提供し、アプリケーションからシステム内の関数実装関数を呼び出すことができます。アプリケーションは、関連する API インターフェイスを呼び出すことで、機能的なサービスを提供および使用できます。
2. ファイル メソッド: システムの内部呼び出し機能を構成ファイルまたはデバイス ファイルの形式で提供します。これらのファイルは構成を通じて自動的に生成でき、有効な構成情報が含まれており、実行環境内の特定のプログラムによって読み取られて認識され、特定のサービスを実装できます。
3. システム ネイティブ サービス: システムの CPU とメモリの監視、アプリケーションの監視、システム リソースの分割など、オペレーティング システムと基本クラス ライブラリによって提供される操作機能。さらに、C++ や boost などの基本的なクラス ライブラリを呼び出すこともできます。
4. IPC インターフェイス: さまざまな IPC メカニズムは、ソケットや共有メモリなどのプロセス間通信メソッドの使用や、IPCF などの特定のコア間通信メソッドの使用を含む、システム内のプロセス間呼び出し機能を提供します。
5. プロトコル スタック インターフェイス: スケジューリング サービス、インターフェイスのカプセル化、SOME/IP、DDS、MQTT、HTTP などのネットワーク プロトコルのプロトコル変換を含む、ネットワーク プロトコル スタックを介したクロスプラットフォーム通話機能を提供します。
SOA（サービス指向アーキテクチャ）はインターネット分野では古くから使われてきましたが、自動車業界では比較的新しい概念です。Adaptive AutoSAR フレームワークでは、通信管理モジュールにはプロセス間通信とネットワーク プロトコル スタックが含まれます。
自動車アプリケーションのシナリオと通信要件の特殊性を考慮すると、多くのインターネット SOA テクノロジは自動車分野に直接適用できません。一般に、SOA 通信ミドルウェア システムのすべてのレベルは次の要件を満たす必要があります。
1.ローカル サービスとリモート サービス間の通信では、統一インターフェイス記述言語 (IDL) で定義されたファイルをコントラクトとして使用する必要があります。IDL は、特定のオペレーティング システムやプログラミング言語とは何の関係もない中立的なインターフェイス記述言語です。
2. SOA フレームワークの基礎となるコア機能には、サービス検出、メッセージのシリアル化、内部イベント/メッセージ処理、および送信機能という特性が必要です。アプリケーション、サービス、およびオペレーティング システムは、特にセンシング データの大規模データ スループット送信要件を満たすために、標準通信プロトコルまたはサービス インターフェイスを通じて相互に通信またはアクセスできます。SOME/IP プロトコル、DDS 仕様などの一般的な車内通信プロトコルをサポートする必要があります。サービスディスカバリ機能には不正なユーザーの盗聴や侵入を防ぐためのアクセス制御機能が必要であり、送信機能には通信データの安全性を確保するためのデータ暗号化や署名機能が必要です。
将来的には、自動車はより多くのインフラストラクチャに接続されるようになり、それらに接続するには、さまざまな通信プロトコルを使用する必要があります。
車載用SOA通信アーキテクチャ
HTTP、MQTT、SOME/IP、DDS などのプロトコルはすべて、SOA アーキテクチャで通信を実装するために使用されますが、それらはシナリオごとに異なる役割を担うだけです。たとえば、車内のノード間のサービス通信には SOME/IP プロトコルが使用され、インターネット モジュールとの通信には HTTP および MQTT が使用されます。これらは実装メカニズムに若干の違いがありますが、互換的に使用できます。
MQTT、DDS、AMQP、REST、CoAP などのプロトコルはすべて広く使用されており、各プロトコルには少なくとも 10 の異なるコード実装があります。これらはすべて、リアルタイムのパブリッシュ/サブスクライブ IoT プロトコルをサポートすると主張しています。ただし、具体的なシステム アーキテクチャの設計では、実際のシナリオでの通信要件を考慮し、適切なプロトコルを選択する必要があります。さまざまなプロトコルの特性を表に示します。
2. SOME/IP の概要
2011 年、BMW は SOME/IP (Scalable Service- Oriented Middleware over IP) プロトコルを設計および提案しました。SOME/IP はサーバー/クライアント サービス通信モデルを採用しており、拡張性が高くなります。SOME/IP プロトコルは、TCP/UDP 伝送プロトコル (車両イーサネット レイヤ 4 以降) の上で動作するアプリケーション層プロトコルです。イーサネット通信用のミドルウェアとして、アプリケーション層と IP 層の間のデータ対話を実現するため、オペレーティング システムから独立し、AUTOSAR および非 AUTOSAR プラットフォームと互換性があります。したがって、SOME/IP はハードウェア プラットフォーム、オペレーティング システム、プログラミング言語から独立できます。
SOME/IP プロトコル アーキテクチャ
SOME/IPは、主にサービスベースの通信方式、フットプリントの小ささ、AUTOSARとの互換性（他のミドルウェアは非互換）、拡張性（大小のプラットフォームに適している）、互換性 (AUTOSAR、OSEK、QNX、Linux など、車両で使用されるさまざまなオペレーティング システムで利用可能)。
SOME/IP は、AUTOSAR CP、AUTOSAR AP、および非 AUTOSAR プラットフォーム間の通信対話をサポートします。BMW が SOME/IP プロトコルを設計した後、AUTOSAR によって公式標準に組み込まれ、CP 仕様のリリースにより車載イーサネットで広く使用されるようになったことから、AUTOSAR CP が SOME の普及を促進したと言えます。 /IP。
AUTOSAR アーキテクチャでは、SOME/IP-SD モジュールは AUTOSAR BSW モード マネージャー モジュール (BswM) と AUTOSAR ソケット アダプター モジュール (SoAd) の間に配置されます。BswM モジュールはコモン モード リクエストとサービス リクエストの間の接続を提供し、SoAd モジュールはイーサネット スタックと SD モジュール間のサービス リクエストを処理します。SoAd でソケット接続テーブルを構成すると、他の ECU の SD モジュールによって送信されたユニキャスト メッセージおよびマルチキャスト メッセージを受信できます。
SOME/IP プロトコルの高いプラットフォーム スケーラビリティにより、異なるプラットフォーム間のデータ対話が実現できます。また、統合された SOME/IP 通信メカニズムは、異なるプラットフォーム間の通信の前提条件です。SOME/IP を異なるソフトウェア プラットフォーム上で実行し、車両全体のイーサネット上で SOA アーキテクチャの通信メカニズムを実現するために、AP 仕様にも SOME/IP が同時に導入されました。 CP と AP の間で実装されます。
非 AUTOSAR ソフトウェア プラットフォームと車載 CP および APECU の間の相互作用を促進するために、GENIVI System は CP/AP と相互作用するためのオープンソース vSOME/IP ソフトウェア ソース コードのセットも開発しました。ただし、vSOME/IP はオープンソースであるため、パフォーマンスが若干異なる可能性があるため、詳細な二次開発を行うためには、統一された仕様を制約する必要があります。現在、商用 SOME/IP 製品の世界最大のサプライヤーは Vector であり、vSOME/IP のオープンソース バージョンは GENIVI Association によって維持されています。
3. DDS の概要
DDS (Data Distribution Service) は、OMG (Object Management Group) によって発行された分散通信仕様です。1989 年に設立された OMG は、サプライヤー、エンド ユーザー、学術機関、政府機関が主導する国際的でオープンな非営利の技術標準アライアンスです。OMG ワーキング グループは、エンタープライズ統合標準の策定と、統合モデリング言語 SYSML、UML、ミドルウェア標準 CORBA、DDS などを含む、何千もの垂直産業に現実世界の価値を提供できる技術標準の開発に取り組んでいます。
DDS は、軍艦システムの複雑なネットワーク環境における大規模なソフトウェア アップグレード中の互換性の問題を解決するために、米国海軍システムで初めて使用されました。ROS2 と AUTOSAR による DDS の導入により、航空、航空宇宙、造船、国防、金融、通信、自動車などの分野で広く使用されています。
DDSの特徴:
1. データ中心性
DDS の最も重要な特徴は、他の多くの通信ミドルウェアとは異なり、データ中心であることです。DDS のデータ共有はトピックを単位として使用され、アプリケーションは他のコンテキスト情報に依存することなくトピックに含まれるデータ型を判断できます。同時に、DDS はユーザー定義の方法でデータを自動的に保存、公開、またはサブスクライブできるため、アプリケーションはローカル データにアクセスしているかのようにデータの書き込みまたは読み取りを行うことができます。
DDSデータセンター
2. グローバルデータスペース
DDS によって実装されるデータ共有は、抽象的なグローバル データ空間として理解でき、アプリケーションがどの開発言語で書かれているか、どのオペレーティング システムで実行されているかに関係なく、アクセスするのと同じように同じ方法でアクセスできます。ローカルストレージスペース。もちろん、グローバル データ空間は抽象的な概念にすぎず、実際の実装では、データは依然として各アプリケーションのローカル空間に個別に格納されます。システムの実行中、データはオンデマンドで送信または保存され、データの発行者はサブスクライバーが必要とするデータのみを送信し、サブスクライバーはローカル アプリケーションが現在必要とするデータのみを受信して保存します。
グローバルデータスペース
3. サービスの品質
DDS は、信頼性や障害処理などのデータ共有方法に対するユーザーのさまざまなニーズを満たす、非常に柔軟な QoS (サービス品質) ポリシーも提供します。より高度なデータ セキュリティ要件があるシステムの場合、DDS は、アプリケーション ID 認証、権限制御、データ暗号化などの洗練されたデータ セキュリティ制御も提供します。
4. 動的検出
SOME/IP-SD と同様に、DDS はデータ パブリッシャとサブスクライバに動的な検出メカニズムを提供します。つまり、通信ノードは動作中に自動的に相互に検出され、自動的に検出されるため、ユーザーは通信ノードのアドレスやその他の属性情報を手動で構成する必要がありません。関連する構成を完了し、プラグアンドプレイ機能を実現します。
5. スケーラブルなアーキテクチャ
DDS は、エッジ コンピューティング、フォグ コンピューティング、クラウド コンピューティングの分野に適用できます。エッジ コンピューティングでは、DDS によりデバイス間の高速リアルタイム通信を実現できます。中間システムでは、DDS は堅牢で信頼性の高い QoS とコンテンツ認識型の情報フローを提供します。DDS は、情報システムを統合し、各システムをクラウドに接続するための、スケーラブルな情報アクセスとデータ配信手段を提供します。
OMG DDS には、小型デバイスからクラウド コンピューティング システムなどの非常に大規模なシステムに至るまで、幅広いアプリケーションがあります。DDS は超高速でデータを送信し、数千のデータ オブジェクトを同時に管理できるため、非常に高い可用性とセキュリティを提供し、モノのインターネットに非常に適しています。標準の通信層を提供することにより、DDS は基礎となる複雑さを保護し、分散システムの開発を簡素化します。
スケーラブルなアーキテクチャ
6. セキュリティ
DDS は、システムやベンダーを超えて、ミッションクリティカルな産業用 IoT 環境に包括的なセキュリティ保護メカニズムを提供し、エッジ デバイスからクラウドに至るまでのセキュリティ ニーズをカバーします。
DDS は、認証、アクセス制御、データ暗号化、データ整合性などのセキュリティ メカニズムを提供し、データ配布のセキュリティを確保します。これらのセキュリティ メカニズムはピアツーピア アーキテクチャに実装されており、リアルタイム通信のパフォーマンスには影響しません。
現在、DDS は複数の車両ミドルウェア プラットフォームに導入されています。AUTOSAR AP は、DDS 標準ネットワーク バインディングを完全に統合しています。また、AUTOSAR CP 自体の標準仕様は DDS をサポートしていませんが、いくつかの回避策を使用して DDS を CP に統合することもできます。ROS2 と CyberRT の両方の最下層は、最も重要な通信メカニズムとしてオープンソース DDS を使用します。Xavier や Orin などの自動運転分野用の SOC チップも DDS インターフェイスを予約しています。OMG 組織の取締役会のメンバーとして、RTI は DDS 標準の策定を主導し、Connext と呼ばれる DDS ブランドを開発したため、Connext DDS とも呼ばれます。
商用 RTI DDS と比較して、オープン ソース DDS は OMG 公式標準に従って開発されていますが、ソース コードはオープンであり、主に Fast DDS と Open DDS が含まれます。
自動運転の分野では、RTI の元のコア チームのメンバーによってヨーロッパで設立された会社 eProsima が、Fast DDS と呼ばれる影響力のあるオープンソース DDS を立ち上げました。eProsima が Fast DDS のソース コードを公開すると、ユーザーはそれを GitHub から無料で直接ダウンロードできます。Fast DDS を使用するには、eProsima にサポート料金を支払う必要があります。
Open DDS は、セントルイスとフェニックスのオブジェクト コンピューティングの ACE/TAO チームによって開発されました。Fast DDS と類似点があります。どちらも RTPS に基づいています。どちらもデータ指向の通信フレームワークであり、同じ標準に従っています。このタイプのフレームワークの一般的な機能は、分散化、QoS メカニズムのサポート、およびリアルタイム通信であり、通常は protobuf などのシリアル化ツールにバインドされています。
オープンソース DDS は RTI の商用 DDS と競合しますが、オープンソース DDS にはいくつかの欠点もあります: オープンソース DDS を使用するための敷居が比較的高いです。たとえば、RTI DDS には 50 以上のサービス戦略がありますが、オープンソース DDS には 23 しかありません。パフォーマンスは前者よりもはるかに低く、RTI の DDS は ASIL-D 認定に合格していますが、オープンソースの DDS はまだこの認定レベルに達していません。
4. SOME/IP と DDS の比較
SOME/IP と DDS は、現在ドメイン制御で最も一般的に使用されている 2 種類の通信ミドルウェアであり、どちらもサービス指向の通信プロトコルであり、データ中心のパブリッシュ/サブスクライブ モデルを採用しています。
ただし、SOME/IP と DDS は多くの点で異なります。主な違いは次のとおりです。
1. 主な応用分野が異なる: SOME/IP は自動車分野向けに特別に開発され、自動車分野のニーズに合わせた一連の通信規格を定義し、自動車分野に長年深く関わってきましたが、DDS は自動車分野に特化して開発されました。は、より高い適応性を備えた産業レベルの強力なリアルタイム通信規格ですが、自動車/自動運転分野に適用する場合は特別な調整が必要です。
2. 異なる柔軟性とスケーラビリティ: SOME/IP と比較して、DDS には、コンテンツベースおよび時間ベースのフィルタリング、トランスポートに依存しない信頼性、永続性、存続可能性、遅延/デッドライン監視、拡張可能なタイプなど、多くの標準組み込み機能が導入されています。 。AUTOSAR AP が DDS と連携して通信フレームワークを構築すると、そのフレームワークは既存の API やアプリケーションと互換性があるだけでなく、信頼性、パフォーマンス、柔軟性、拡張性の点で重要な利点も得られます。
3. サブスクライバーとパブリッシャーの結合度が異なる: SOME/IP では、サブスクライバーは通常のデータ送信の前にパブリッシャーとのネットワーク接続を確立し、必要なサービスを提供するかどうかをパブリッシャーに問い合わせる必要があります。ノード間の通信にはまだ結合が存在します。DDS 標準では、各サブスクライバーまたはパブリッシャーは、独自のプログラムでセンサー データをサブスクライブまたはパブリッシュするだけで済み、接続について気にする必要はありません。したがって、DDS では、サービスの加入者側と発行者側がより完全に分離されます。
4. さまざまなサービス戦略: 優れたサービス品質 (QoS) は、SOME/IP と比較した DDS 標準の最も重要な機能です。SOME/IP の QoS は 1 つだけですが、RTI DDS とオープンソース DDS はそれぞれ 50 と 20 以上の QoS を提供しており、これらの QoS は基本的に、予測可能なほとんどのインテリジェント運転シナリオをカバーします。
5. さまざまなアプリケーションシナリオ: アプリケーションシナリオの観点から見ると、SOME/IP は車載ネットワークに適しており、IP ベースのネットワーク環境でのみ使用できますが、DDS は伝送方式に特別な制限がなく、ネットワークをサポートできます。共有メモリ、クロスコア通信、PCIe などの非 IP タイプのネットワークをベースとしています。さらに、DDS は完全な車両インターネット ソリューションも提供しており、その独自の DDS セキュリティおよび DDS Web 機能により、ユーザーはワンストップの「車両-クラウド-モバイル」ソリューションを提供します。
商用実装では、SOME/IP と DDS の間には直接的な競争関係がありますが、アプリケーション分野、柔軟性、サービス戦略の違いにより、OEM はニーズに応じて適切な通信ミドルウェアを選択でき、両方を同時に使用することもできます。時間。これが、AUTOSAR AP が SOME/IP と DDS の両方をサポートする理由です。
ソース | Che ターミナル