序文
まず最初に、いくつかの小さな質問をしたいと思います。
- SOME / IPとは何か知っていますか？
- SOME / IPが関連する背景である理由を知っていますか？
- SOME / IPとSOAがどれほど密接に関連しているか知っていますか？
- SOME / IPは実際にどの程度正確に使用する必要がありますか？
今日は、これらの質問を一緒に調べて答えましょう。理解を容易にするために、この記事のトピックの概要は次のとおりです。
文章
一般的な紹介
前回の記事<OneArticleGetting Started Vehicle Ethernet Link>で紹介したように、車両イーサネットプロトコルスタックは、物理層、データリンク層、ネットワーク層、トランスポート層、およびアプリケーション層、その今日紹介されるコンテンツSOME/IPはアプリケーション層プロトコルです。
AUTOSARの説明によると、SOME / IPプロトコルの内容は、アプリケーション層のSOME / IP標準プロトコル、TP層のSOME / IP-SDプロトコル、およびSOME/IP-TPプロトコルの3つのサブプロトコルにさらに分割できます。これらの3つの部分は互いに補完し合い、SOME / IPプロトコルの内容全体を詳細に説明します。これは、SOME/IPプロトコルを研究する唯一の方法です。
SOME / IPプロトコルには多くの内容と複雑な関連性があるため、SOME / IPを段階的に理解できるようにするために、この記事では、スペースが限られているため、主にアプリケーション層のSOME/IP標準プロトコルについて説明します。 。みんなと共有してください、もっと注意を払ってください！
背景と動機
BMWは2011年に、サービス指向通信を実現できるミドルウェアのセットを開発および設計しました。このミドルウェアは、従来の信号指向通信とは異なり、効率性が高く、イーサネット通信の導入により、将来の車両の増大する通信ニーズにも大きく対応できます。 。
信号指向のデータ送信は、ネットワークがデータを必要とするかどうかに関係なく、常にループで送信されますが、サービス指向の通信方法は異なります。データを必要とする受信者がネットワーク内に少なくとも1つある場合にのみ、送信者はこれは一種の指向性のあるサービス通信方式の重要な利点です。
BMWは、このサービス指向通信をSOME / IP（フルネーム：スケーラブルなサービス指向MiddlewarE over IP）と呼んでいます。名前が示すように、このプロトコルはイーサネットと密接に関連しています。SOME / IPは、車載イーサネットプロトコルスタックに基づいて実行されるミドルウェアです。または、アプリケーション層ソフトウェアと呼ぶこともできます。
SOME / IPは、その人気と公式規格に含まれる予定であるため、AUTOSARによって徐々に受け入れられており、2014年にAUTOSAR4.Xに統合される予定です。いくつかの主要な開発ノードは次のとおりです。
- AUTOSAR 4.0-BMW SOME/IPメッセージの予備統合を完了しました。
- AUTOSAR 4.1-SOME/IP-SDとそのパブリッシュ/サブスクライブ機能のサポート。
- AUTOSAR4.2-シリアル化およびその他の関連する最適化のためのトランスフォーマーを追加します。
- AUTOSAR 4.3-いくつかのトランスフォーマーのバグを修正し、多数のUDPパケットおよびその他のSOME/IP-SD最適化のためのSOME/IP-TPプロトコルを追加します。
- 継続的な最適化。。。。。。
SOME/IPとは
前のセクションで説明したSOME/IPのフルネームとして、そのフルネームを使用してSOME/IPとは何かを理解しましょう。
-
スケーラブル
プロトコル設計の本来の目的の1つは、異なるハードウェアプラットフォーム、異なるオペレーティングシステムまたは組み込みファームウェア、および異なるアプリケーションソフトウェアを備えた異種デバイス間のスケーラビリティと相互運用性を実現することです。
-
サービス指向
サービス指向の基本プロトコルであることを示します。したがって、クライアント/サーバー構成では、クライアントが要求するか、サーバーが特定のサブスクライバーに通知する場合にのみデータが交換されます。これにより、帯域幅が無駄になることはなく、データは必要なときに必要な場所でのみ通信/交換されます。
-
ミドルウェア
ミドルウェアの一種でもあります。つまり、アプリケーション層に配置され、より具体的な操作とアプリケーションを処理するための独自の一般的なプロトコル層があります。
-
IP経由
また、イーサネットベースのプロトコルです。同様のハードウェアインターフェイスを使用して、最大100Mbpsの帯域幅を確保します。同時に、データは、TCP / IPまたはUDPプロトコルを使用して、ネットワークケーブルを介してミドルウェア（つまり、アプリケーション層）を介して通信されます。
クライアントがサーバーからのデータを必要とする場合、TCPプロトコルを使用してクライアントからデータを要求できます。サーバーがすべてのアクティブなサブスクライバーにデータを送信する必要がある場合は、UDPプロトコルを介してデータを送信できます。UDPプロトコルを介したデータ通信は、ユニキャスト、マルチキャスト、またはブロードキャストにすることができます。
下の図1に示すように、車載イーサネットプロトコルスタック内のSOME / IPの位置と、他のモジュールとの関係を明確に示しています。
では、AUTOSARプロトコルスタックでは、SOME / IPプロトコルの位置は何ですか？以下に示すように：
上の図からわかるように、SOME / IPプロトコルにはRTE、COM、PDUR、SOAdなどのAUTOSAR標準モジュールとの相互作用が含まれ、サービス検出用のSOME / IP-SDにはBswM、SD、SoAdモジュールとの相互作用が含まれます。SOME / IPプロトコルと各モジュールの相互作用については、以降の記事で説明します。これについて言及すると、SOME / IPプロトコルとAUTOSARプロトコルスタックの関係の全体的な概念がわかります。この記事は、あまり詳しく説明しません。
SOME / IPは元々、AUTOSARデバイスとの互換性を確保し、自動車のユースケースに必要な最大の機能を提供するための代替RPCメカニズムとして開発されましたが、ECUプロトコル間のクライアントサーバーシリアル化用に設計されたネットワーク層でもあります。
現在、このプロトコルは、 AUTOSAR、OSEK、GENIVIなどのさまざまなオペレーティングシステムに実装できます。また、オペレーティングシステムを実行しない組み込みファームウェアに実装することもできます。
カメラ、メインフレーム、テレマティクスデバイス、AUTOSARデバイス、さらにはインフォテインメントシステムなどの大型デバイスは、SOME/IPプロトコルを使用してECU間で効率的にメッセージを交換できます。Wireshark 3.2 SOME / IPのリリース以降、SOME / IPのサポートが公開されており、SOME/IPデータはWiresharkで解析できます。
要約すると、以下の表1に示すように、サービス指向の通信プロトコルとしてのSOME / IPの基本的な特性と、車載イーサネットプロトコルスタックに基づくアプリケーション層プロトコルを要約できます。IPプロトコルの5つの基本的な特性：
SOME/IPとSOAの関係
SOA
つまり、SOAはサービス指向アーキテクチャ（サービス指向アーキテクチャ）であり、もちろんソフトウェア設計の重要な方法でもあります。IT調査およびコンサルティング会社のGartnerが1996年に提唱した、それ自体は新しい概念ではありません。そしてそれは20年以上の間ITインターネット分野で人気がありました。
W3Cの定義によると、「SOAは、すべての機能が、定義された順序で呼び出すことができる明確に定義された呼び出し可能なインターフェイスを備えた独立したサービスとして定義されているアプリケーションアーキテクチャです。サービスはビジネスプロセスを形成します。
サービス：サービスは、コンポーネントよりも粒度の高い情報のコレクションであり、実際には、複数の関連するビジネス要件を実装する論理的な組み合わせが含まれ、各サービスが特定のプラットフォーム、アーキテクチャ、または技術ソリューションを使用できるようにします。
呼び出し可能なインターフェース：サービス指向インターフェースはコンポーネントインターフェースとは異なります。その実装は特定の言語や特定のプラットフォームとは関係がなく、さまざまな異種プラットフォームの相互作用を実現するのに非常に便利です。
連絡先と違い：
- まず第一に、SOME / IPはSOAではなく、SOAはSOME/IPではないことを明確にする必要があります。
- SOME / IP自体もサービス指向プロトコルであるため、SOME/IPはSOAを実装するための実行可能なプロトコルの選択にすぎないと一般に考えられています。
- 一般的に、メッセージベースの通信とRPC（リモートプロシージャコール）通信の両方でSOAを実装でき、SOME/IPはRPCフレームワークベースのプロトコルです。
- SOAはSOME/IPを介して実装できますが、SOA実装は必ずしもSOME/IPを使用する必要はありません。
SOME/IPプロトコル分析
次に、Xiao Tに、SOME/IPを分析してSOME/IPの謎を解き明かしてもらいましょう！、車載イーサネットのその後の学習のための強固な基盤を築くために。
相関識別子とリリースノート
以下の図2は、SOME/IPプロトコルのヘッダー構造を示しています。
上図でマークされているメッセージID、リクエストID、プロトコルバージョン、およびインターフェイスバージョンの詳細な説明は、以下の表2に示されています。
長さ
長さは上の図2に示すとおりであり、要求IDの先頭からSOME/IPメッセージの末尾までをカバーします。
メッセージタイプ
さまざまなメッセージタイプを識別するために使用されます。現在存在するタイプを以下の図3に示します。ここで、TPはパケット化されたメッセージを表し、AUTOSAR標準（R21-11）に従って次のように定義されています。
戻りコード
リターンコードは、メッセージが正常に処理されたかどうかを示すため、またはAUTOSAR（ R21-11 ）で定義されたリターンコードタイプについて以下の図4に示すように、リクエストのエラーコンテンツに対するフィードバックを提供するために使用されます。
SOME/IP通信メカニズム
SOME / IPプロトコル規格の詳細な定義を理解した後、データ伝送を実現するために車両ECUが従う必要のあるルールについて議論する必要があります。したがって、この部分に精通していると、車両イーサネットSOME/IPの開発とテストに役立ちます。重要に。
サービスディスカバリ
サービス検出の通信メカニズムは、SOME / IP-SDプロトコルを介して実現されます。主に、車両イーサネットの現在のサービスインスタンスの可用性とアクセス方法をクライアントに通知します。これは、サービスの検索とサービスの提供を通じて実現できます。
SOME / IPプロトコルを介してデータを送信する前に、車両ネットワーク全体に存在するサービス、サービスの可用性、およびクライアントがサーバーによって提供されるサービスに加入しているかどうかを知る必要があります。
SOME / IP-SDプロトコルも非常に重要な部分なので、ここではあまり詳しく説明しませんが、その基本的な機能とメカニズムを簡単に紹介します。SOME/IP-SDプロトコルの具体的な内容は別途紹介します。後で、お楽しみに！
以下の図5は、SOME / IP-SDの基本機能を示しており、クライアントとサーバー間の相互作用を示しています。
上の図からわかるように、SOME / IPサービス検出プロセスは、次の3つの基本的な手順に分けることができます。
- クライアントは、Find Serviceメッセージを送信することにより、車両ネットワークで利用可能なサービスインスタンスを検索します。
- サーバーはクライアントのサーバーの検索を受信した後、UDPを介してサービス提供応答を送信します。
- クライアントは、サブスクライブイベントグループを送信することにより、関連するイベントをサブスクライブします。
- サーバーは、クライアントがサブスクリプション条件を満たすかどうかをチェックし、満たす場合はACKを返し、満たさない場合はNACKを返します。
- クライアントが関連するイベントを正常にサブスクライブした後、サーバーは、イベント自体の属性に従って、イベントをサブスクライブしたクライアントを公開します。
リモートプロセスコール（RPC）
リモートプロセス呼び出しは、主に4つの通信モードに分けることができます。
-
要求/応答通信モードは、メソッドの1つとして要約できます。その基本的な通信モデルを以下の図6に示します。
最も一般的な通信方法の1つである要求/応答モデルとして、その主なタスクは、クライアントが要求情報を送信し、サーバーが要求を受信し、関連する処理を実行して、それに応じて応答することです。
-
Fire＆Forget通信モードは、方法の1つとして要約できます。
この通信モデルの主なタスクは、クライアントがサーバーに要求を送信することであり、サーバーは応答する必要がありません。これは、診断サービスの抑制肯定応答にいくらか似ています。
-
通知イベント通信モード。
この通信モードは、主にパブリッシュ/サブスクライブメッセージの内容を記述します。主なタスクは、クライアントがサーバーから関連するイベントグループにサブスクライブしていることを認識することです。サーバー上のイベントグループが発生したり、値が変更されたりした場合は、サブスクライブする必要があります。イベントグループ。更新されたコンテンツを投稿します。
-
リモートプロセス制御（フィールド）
アクセスプロセス通信メカニズムの主な目的は、アプリケーションのデータを取得および変更することです。主なタスクは、クライアントがゲッターを介してサーバーの値を取得し、セッターを介してサーバーの値を設定することを認識することです。
フィールドは、サービスの基本プロパティとして理解できます。これには、Getter、Setter、およびNotifierが含まれます。Getterはフィールドの値を読み取るメソッドであり、Setterはフィールドの値を変更するメソッドであり、Notifierはフィールドの値が変更されたときにトリガーされるイベントです。
図9フィールドのコミュニケーションモデル
上の図からわかるように、GetterとSetterの方法で要求/応答メカニズムを使用しています。ゲッターの要求メッセージでは、それは空のペイロードであり、応答メッセージのペイロードは取得される値です。セッター要求を使用する場合、要求メッセージのペイロードは設定される値です。設定が成功した場合、応答メッセージ本文では、ペイロードは設定の成功の値です。
同時に、サービスエンティティはSOME/IPプロトコルの非常に重要な概念であると結論付けることもできます。サービスエンティティは、フィールド、イベント、およびメソッドの任意の組み合わせにすることができます。
SOME/IPエラー処理メカニズム
通信プロセスには常にさまざまなエラーがあり、サービス指向アプリケーションプロトコルとしてのSOME / IPも例外ではありません。したがって、通信プロセスの問題をより効率的に特定するために、AUTOSARは一連のエラー処理メカニズムを策定しました。 SOME/IPプロトコルフォーマットの内容を確認します。
バージョン情報チェック、サービスIDなど、その他の障害情報をペイロードで詳細に定義できます。現在、SOME / IPは、構成に応じて選択できる次の2つのエラー処理メカニズムをサポートしています。
- メッセージタイプ0x80、応答情報、つまり、問題は応答メッセージのリターンコードを介して特定できます。
- メッセージタイプ0x81、明示的なエラーメッセージ。
以下の図10は、一般的なエラーを処理するSOME/IPの基本的なプロセスを示しています。
SOME / IPプロトコルスタックの実装方法について詳しく知りたい場合は、BMWが主導するGitHubのオープンソースコードを参照し、GitHubで「vsomeip」キーワードを検索して、対応するオープンソースコードを見つけて学習することができます。 。
vsomeipは、Linuxプラットフォームに基づくC++言語で開発されたSOME/IPプロトコルスタックであることに注意してください。
これを読んでいただきありがとうございます。また、エキサイティングで楽しみに値するSOME / IP（パート2）もお楽しみに！
よりエキサイティングなコンテンツを知りたい場合は、コードをスキャンして、次の公開アカウント「ADASとECUに関する私の見解」に従ってください。
