Dienstarchitektur definieren

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

Dienstpakete erstellen

In Dienstpaketen werden verwandte Diensteinheiten 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 voll qualifizierten Namen des Dienstpakets.

Dienstpakete werden mit VSIDL-Dateien (Vehicle Services Interface Definition Language) definiert (Dateien mit der Erweiterung .vsidl).

Das folgende Beispiel zeigt zwei Dienstpakete: ein Dienstpaket TirePressureMonitoring und ein Dienstpaket BodyControl:

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 Dienstpakets.

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 ändernden Zustand des Fahrzeugs, indem Daten an alle interessierten Komponenten gestreamt werden. Daten werden in Themen organisiert. Publisher senden Nachrichten zu Themen. Der Publisher sendet Nachrichten zu Themen, ohne zu wissen, 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 Aktion und Ergebnis 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 in einem Channel auf.

Diese Muster dienen zwar unterschiedlichen betrieblichen Anforderungen, haben aber eine gemeinsame strukturelle Eigenschaft: Beide verwenden benannte Kommunikationspfade – Themen für Pub/Sub und Channels für RPC –, um die Identität des Absenders vom Empfänger zu entkoppeln.

Publisher und Abonnenten deklarieren

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

Einem Dienstpaket einen Publisher hinzufügen

In den folgenden Beispielen wird ein Publisher zum Dienstpaket TirePressureMonitoring hinzugefügt:

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

service_bundle {
  name: "TirePressureMonitoring"

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

}

service_bundle {
  name: "BodyControl"

  ...
}

Wobei:

  • publisher Dienstnachricht veröffentlicht Nachrichten in einer Nachrichtenwarteschlange.
  • message Datenstruktur oder Nachrichtentyp, der in Protobuf definiert ist (Datei mit der Erweiterung .protobuf).
  • topic Eindeutige Kennung für das Veröffentlichungsthema. Es muss im Kleinbuchstaben-Bindestrich-Format vorliegen.
  • capacity Anzahl der Nachrichten, die die Veröffentlichungswarteschlange aufnehmen kann. Es muss eine gerade Zahl größer oder gleich 2 sein.

Einem Dienstpaket ein Abo hinzufügen

In den folgenden Beispielen wird ein Publisher zum Dienstpaket BodyControl hinzugefügt:

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:

  • subscriber Dienstpaket abonniert Themen.
  • message Datenstruktur oder Nachrichtentyp, der in Protobuf definiert ist (Datei mit der Erweiterung .protobuf).
  • topic Eindeutige Kennung für das Veröffentlichungsthema. Es muss mit dem Thema des Publishers übereinstimmen und im Kleinbuchstaben-Bindestrich-Format vorliegen.

RPC-Clients und ‑Server definieren

Remote-Prozeduraufruf (RPC) bietet Standortunabhängigkeit von Funktionsaufrufen. In diesem Muster dient der Channel als benannter Treffpunkt, an dem sich Client und Anbieter treffen. Indem das Framework auf den Channel und nicht auf eine bestimmte Dienstinstanz ausgerichtet ist, entkoppelt es die Absicht des Befehls vom physischen Standort der Implementierung.

Im folgenden Beispiel hostet das Dienstpaket CabinComfort einen ClimateControl-Server und das Dienstpaket BodyControl wird erweitert, um einen ClimateControl-Client zu hosten:

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

Wobei:

  • server gibt an, dass das Dienstpaket einen Server enthält, der einen RPC-Dienst bereitstellt (identifiziert durch service als ClimateControl).
  • client gibt an, dass das Dienstpaket einen Client enthält, der den Dienst ClimateControl aufruft.
  • channel ist der Name des RPC-Channels. Er muss im Kleinbuchstaben-Bindestrich-Format vorliegen und pro Dienst eindeutig sein.

In diesem Beispiel kann das Dienstpaket BodyControl Remoteprozeduraufrufe an das Dienstpaket CabinComfort senden, um das Klima der vorderen Zone der Kabine zu steuern.

Nächste Schritte

Nachdem Sie Ihre Architektur definiert haben, generieren Sie Middleware-Code.