Dienstarchitektur definieren

Die Dienstarchitektur bezieht sich darauf, wie Dienste zusammengesetzt sind und wie sie mit anderen Komponenten im System kommunizieren.

Dienstpakete erstellen

In Service-Bundles werden zugehörige Service-Einheiten gruppiert, die zusammen bereitgestellt werden können. Die einzige erforderliche Eigenschaft für ein Dienstpaket ist ein Name. Zusammen mit dem Paketnamen bildet der Name den vollständig qualifizierten Namen des Dienst-Bundles.

Dienstbündel werden mit VSIDL-Dateien (Vehicle Services Interface Definition Language, Dateien mit der Erweiterung .vsidl) definiert.

Im folgenden Beispiel sind zwei Dienstbündel zu sehen: ein TirePressureMonitoring-Dienstbündel und ein BodyControl-Dienstbündel:

package: "com.android.sdv.sample.vsidl"

service_bundle {
  name: "TirePressureMonitoring"
}

service_bundle {
  name: "BodyControl"
}

Wobei:

• service_bundle kennzeichnet die Struktur als Dienstpaket.
• name ist der Name des Service-Bundles.

Messaging-Muster: Pub/Sub und RPC

Das SDV-Framework verwendet zwei primäre Messaging-Muster: Publish-Subscribe (Pub/Sub) und Remote-Prozeduraufruf (RPC).

In Pub/Sub reagiert das System auf den sich entwickelnden Zustand des Fahrzeugs, indem es Daten an alle interessierten Komponenten streamt. Die Daten sind in Themen unterteilt. Publisher senden Nachrichten zu Themen. Der Publisher sendet Nachrichten zu Themen, ohne wissen zu müssen, welche (oder wie viele) Abonnenten zuhören. Abonnenten erhalten Nachrichten zu Themen, ohne zu wissen, welche Publisher die Nachrichten gesendet haben.

Im Gegensatz dazu ist RPC für Aktionen und Ergebnisse konzipiert. Es wird verwendet, wenn der Aufrufer eine Anfrage initiiert, weil er sich für das spezifische Ergebnis oder die Bestätigung dieser Aktion interessiert. Der Aufrufer ruft eine bestimmte Methode auf einem Channel auf.

Diese Muster erfüllen zwar unterschiedliche betriebliche Anforderungen, haben aber eine gemeinsame strukturelle Eigenschaft: Beide basieren auf benannten Kommunikationspfaden – Themen für Pub/Sub und Kanäle für RPC –, um die Identität des Absenders vom Empfänger zu entkoppeln.

Publisher und Abonnent deklarieren

Publish/Subscribe ist ein Messaging-Muster, bei dem Absender von Nachrichten, sogenannte Publisher, die Nachrichten nicht direkt an bestimmte Empfänger, sogenannte Abonnenten, senden. Stattdessen kategorisieren Publisher Nachrichten in Themen. Abonnenten abonnieren ein oder mehrere Kommunikationsthemen und erhalten nur Nachrichten, die in diesen Themen veröffentlicht werden. Weitere Informationen zu Publish-Subscribe finden Sie unter Publish-Subscribe-Muster.

Verlag oder Webpublisher einem Servicepaket hinzufügen

Im folgenden Beispiel wird ein Publisher gezeigt, der dem TirePressureMonitoring-Dienstpaket hinzugefügt wurde:

package: "com.android.sdv.sample.vsidl"

service_bundle {
  name: "TirePressureMonitoring"

  publisher {
    message: "TirePressure"
    topic: "front-left"
    capacity: 10
  }

}

service_bundle {
  name: "BodyControl"

  ...
}

Wobei:

• Der publisher-Dienst veröffentlicht Nachrichten in einer Nachrichtenwarteschlange.
• message In Protobuf definierte Datenstruktur oder Nachrichtentyp (Datei mit der Erweiterung .protobuf).
• topic Eindeutige Kennung für das Thema der Publikation. Er muss in Kleinbuchstaben mit Bindestrichen geschrieben werden.
• capacity Anzahl der Nachrichten, die in der Veröffentlichungs-Warteschlange gespeichert werden können. Es muss eine gerade Zahl größer oder gleich 2 sein.

Abonnement für ein Dienstpaket hinzufügen

Das folgende Beispiel zeigt einen Publisher, der dem BodyControl-Service-Bundle hinzugefügt wurde:

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"
  }
}

Wobei:

• Das subscriber-Dienstpaket abonniert Themen.
• message In Protobuf definierte Datenstruktur oder Nachrichtentyp (Datei mit der Erweiterung .protobuf).
• topic Eindeutige Kennung für das Thema der Publikation. Sie muss zum Thema des Publishers passen und in Kleinbuchstaben mit Bindestrichen geschrieben werden.

RPC-Clients und ‑Server definieren

Remoteprozeduraufrufe (Remote Procedure Calls, RPCs) ermöglichen standortunabhängige Funktionsaufrufe. In diesem Muster dient der Channel als benannter Rendezvouspunkt, an dem sich Client und Anbieter treffen. Indem das Framework auf den Channel und nicht auf eine bestimmte Dienstinstanz ausgerichtet ist, wird die Absicht des Befehls vom physischen Standort der Implementierung entkoppelt.

Im folgenden Beispiel wird das Dienstbündel ClimateControl als Server und das Dienstbündel BodyControl als Client festgelegt:

package: "com.sdv.cc"

service_bundle {
  name: "ClimateControl"

  server {
    service: "SetTemperature"
    channel: "climate-control"
  }
}

service_bundle {
  name: "BodyControl"

  client {
    service: "SetTemperature"
    channel: "climate-control"
  }
}

Wobei:

• server gibt an, dass das Dienstbündel ein Server ist, der einen RPC-Dienst bereitstellt (durch service als SetTemperature identifiziert).
• client gibt an, dass das Dienstbündel ein Client ist, der den SetTemperature-Dienst aufruft.
• channel ist der Name des RPC-Channels. Er muss in Kleinbuchstaben mit Bindestrichen geschrieben und pro Dienst eindeutig sein.

In diesem Beispiel kann das BodyControl-Dienstpaket Remote Procedure Calls an das ClimateControl-Dienstpaket senden, um die Temperatur festzulegen.

Nächste Schritte

Nachdem Sie die Architektur definiert haben, generieren Sie den Middleware-Code.