サービス アーキテクチャとは、サービスの構成方法と、システム内の他のコンポーネントとの通信方法を指します。
サービス バンドルを作成する
サービス バンドルは、一緒にデプロイできる関連するサービス単位をグループ化します。サービス バンドルに必要なプロパティは名前だけです。この名前は、パッケージ名とともにサービス バンドルの完全修飾名を形成します。
サービス バンドルは、Vehicle Services Interface Definition Language（VSIDL）ファイル（拡張子が .vsidl のファイル）で定義されます。
次の例は、TirePressureMonitoring サービスバンドルと BodyControl サービスバンドルの 2 つのサービスバンドルを示しています。
package: "com.android.sdv.sample.vsidl"
service_bundle {
name: "TirePressureMonitoring"
}
service_bundle {
name: "BodyControl"
}
ここで
service_bundleは、構造をサービス バンドルとして識別します。nameは、サービス バンドルの名前です。
メッセージング パターン: Pub/Sub と RPC
SDV フレームワークでは、パブリッシュ / サブスクライブ（Pub/Sub）とリモート プロシージャ コール（RPC）の 2 つの主なメッセージ パターンが使用されます。
Pub/Sub では、システムは車両の状態の変化に反応し、関心のあるコンポーネントにデータをストリーミングします。データはトピックに整理されます。パブリッシャーはトピックにメッセージを送信します。パブリッシャーは、どの（または何人の）サブスクライバーがリッスンしているかを知る必要なく、トピックでメッセージを送信します。サブスクライバーは、どのパブリッシャーがメッセージを送信したかを正確に知ることなく、トピックに関するメッセージを受信します。
一方、RPC はアクションと結果を目的として設計されています。呼び出し元が特定の結果やアクションの確認を必要とするため、リクエストを開始する場合に使用されます。呼び出し元は、チャネルで特定のメソッドを呼び出します。
これらのパターンは運用上のニーズが異なりますが、共通の構造特性があります。どちらも、送信者の ID を受信者から切り離すために、名前付きの通信パス（Pub/Sub のトピックと RPC のチャネル）に依存しています。
パブリッシャーとサブスクライバーを宣言する
パブリッシュ / サブスクライブは、メッセージの送信者（パブリッシャー）がメッセージを特定の受信者（サブスクライバー）に直接送信しないメッセージング パターンです。代わりに、パブリッシャーはメッセージをトピックに分類し、サブスクライバーは 1 つ以上の通信トピックにサブスクライブして、それらのトピックに公開されたメッセージのみを受信します。パブリッシュ / サブスクライブの詳細については、パブリッシュ / サブスクライブ パターンをご覧ください。
サービス バンドルにニュース メディアを追加する
次の例は、TirePressureMonitoring サービス バンドルに追加されたパブリッシャーを示しています。
package: "com.android.sdv.sample.vsidl"
service_bundle {
name: "TirePressureMonitoring"
publisher {
message: "TirePressure"
topic: "front-left"
capacity: 10
}
}
service_bundle {
name: "BodyControl"
...
}
ここで
publisherサービス メッセージはメッセージをメッセージ キューにパブリッシュします。messageprotobuf で定義されたデータ構造またはメッセージ型（.protobuf拡張子のファイル）。topicパブリケーション トピックの一意の識別子。小文字のダッシュケースにする必要があります。capacityパブリッシュ キューが保持できるメッセージの数。2 以上の偶数である必要があります。
サービス バンドルに登録を追加する
次の例は、BodyControl サービス バンドルに追加されたパブリッシャーを示しています。
package: "com.android.sdv.sample.vsidl"
service_bundle {
name: "TirePressureMonitoring"
publisher {
message: "TirePressure"
topic: "front-left"
capacity: 10
}
}
service_bundle {
name: "BodyControl"
subscriber {
message: "com.android.sdv.sample.vsidl.TirePressure"
topic: "front-left"
}
}
ここで
subscriberサービス バンドルがトピックをサブスクライブします。messageprotobuf で定義されたデータ構造またはメッセージ型（.protobuf拡張子のファイル）。topicパブリケーション トピックの一意の識別子。パブリッシャーのトピックと一致し、小文字のダッシュケースにする必要があります。
RPC クライアントとサーバーを定義する
リモート プロシージャ コール（RPC）は、関数呼び出しの場所の独立性を提供します。このパターンでは、チャネルはクライアントとプロバイダが待ち合わせる名前付きのランデブー ポイントとして機能します。特定のサービス インスタンスではなくチャネルをターゲットにすることで、フレームワークはコマンドのインテントを実装の物理的な場所から切り離します。
次の例では、CabinComfort サービス バンドルが ClimateControl サーバーをホストし、BodyControl サービス バンドルが ClimateControl クライアントをホストするように拡張されています。
package: "com.sdv.cc"
service_bundle {
name: "CabinComfort"
server {
service: "ClimateControl"
channel: "front-climate-control"
}
}
service_bundle {
name: "BodyControl"
client {
service: "ClimateControl"
channel: "front-climate-control"
}
subscriber {
message: "com.android.sdv.sample.vsidl.TirePressure"
topic: "front-left"
}
}
ここで
serverは、サービス バンドルに、一部の RPC サービス（serviceでClimateControlとして識別される）を提供するサーバーが含まれていることを示します。clientは、サービス バンドルにClimateControlサービスを呼び出すクライアントが含まれていることを示します。channelは RPC チャネルの名前です。小文字のダッシュケースで、サービスごとに一意である必要があります。
この例では、BodyControl サービス バンドルが CabinComfort サービス バンドルにリモート プロシージャ コールを行い、キャビンのフロント ゾーンの温度を制御します。
次のステップ
アーキテクチャを定義したら、ミドルウェア コードを生成します。