Figure 4.3: The Automotive API Gateway Connecting VSS data to in-vehicle services.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: AUTOSAR Adaptive Platform (AP) Software-Architekturdiagramm / Komponenten- und Port-Konnektordiagramm (UML-Komponentenansicht).
• Technischer Zweck: Spezifikation der architektonischen Brücke zwischen standardisierten, fahrzeugexternen/-übergeordneten APIs (W3C/COVESA VISS – Vehicle Information Service Specification auf Basis von VSS – Vehicle Signal Specification) und den fahrzeuginternen, serviceorientierten AUTOSAR-Diensten.
• Funktionale Einordnung: Das Automotive API Gateway dient als Entkopplungs- und Transformationsschicht. Es schirmt die fahrzeuginterne, OEM-spezifische Service- und Netzwerk-Topologie (z. B. SOME/IP, IPC) gegen standardisierte Anwendungs-Clients ab und überführt VSS-definierte Datenpunkte in native AUTOSAR Adaptive Service Interfaces (ara::com).

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Komponenten:
  • VISS Client: Externer oder lokaler Service-Konsument (z. B. Infotainment-/IVI-Applikation, Cloud-Agent, Telematik-Dienst), der standardisierte VISS-Abfragen (HTTP REST, WebSocket, gRPC) absetzt.
  • Automotive API Gateway: Kapselnde Ausführungseinheit / Adaptive Application, bestehend aus:
    • VISS Interface: Protokolladapter und Server-Endpunkt zur Terminierung des VISS-Protokolls, Deserialisierung von JSON-/Payload-Formaten und Umsetzung auf interne Schnittstellenaufrufe.
    • Gateway SWC <Composite>: Als Composite ausgeprägte Software-Komponente (CompositionSwComponentType), welche die Transformationslogik strukturiert.
    • Mapping Application(s) (Programmed/Generated): Kernlogik innerhalb der Composite SWC; transformiert Datenformate, Skalierungen, Enums und Signalstrukturen zwischen VSS-Definitionen und fahrzeuginternen Diensten (kann manuell implementiert oder per Modell-Generatoren aus Transformationsregeln erzeugt sein).
  • Vehicle Internal: Fahrzeuginterne Service-Domäne.
  • Providing SWC: Mindestens zwei dargestellte funktionale Software-Komponenten (Atomic SWCs der Adaptive oder über Bridges angebundene Classic Platform), die primäre Fahrzeugfunktionen/Sensordaten bereitstellen.
• Ports, Interfaces & Stereotypen:
  • VSS-Seite (Standardisiert):
    • Vier P-Ports (PPortPrototype) an der linken Flanke der Gateway SWC <Composite>, typisiert als VSS Derived Service Interface (aus dem VSS-Katalog abgeleitete AUTOSAR ServiceInterface-Definitionen mit standardisierten Field-, Event- und Method-Strukturen).
    • Bidirektionale Assoziation zwischen VISS Client und VISS Interface sowie Weiterleitung zu den VSS-P-Ports.
  • Fahrzeuginterne Seite (OEM Proprietary):
    • Vier R-Ports (RPortPrototype) an der rechten Flanke der Gateway SWC <Composite>.
    • Vier korrespondierende P-Ports (PPortPrototype), verteilt auf die beiden Providing SWCs (jeweils 2 Ports pro SWC).
    • AssemblySwConnector: Gerichtete Port-Verbindungen von den fahrzeuginternen Providing SWC-P-Ports zu den R-Ports der Gateway-Komponente (Consuming-Beziehung des Gateways).
  • Demarkationsbereich: Die Klammer OEM Proprietary grenzt die internen Providing SWCs, deren herstellerspezifische Service Interfaces sowie die fahrzeugzugewandten R-Ports und Mapping-Definitionen explizit von den offenen VSS/VISS-Standardspezifikationen ab.

3. Dynamisches Verhalten & Sequenzablauf

• Lese- und Telemetriepfad (Sensorik / Field-Notifier / Ingress fahrzeugintern → VISS):
  1. Providing SWC aktualisiert einen internen Datenpunkt und emittiert diesen über seinen P-Port via ara::com (Event-Publish oder Field-Notifier).
  2. Der korrespondierende R-Port der Gateway SWC empfängt die Daten fahrzeugintern (typischerweise asynchron via Event-Subscription/Callback).
  3. Die Mapping Application transformiert den OEM-spezifischen Datentyp (z. B. herstellerspezifischer Bitvektor/Rohwert) in das Zielformat der VSS-Spezifikation (z. B. Fließkommawert, SI-Einheit, standardisiertes Struct).
  4. Die VSS-abgeleiteten P-Ports aktualisieren das entsprechende VSS-Field/Event.
  5. Das VISS Interface serialisiert den VSS-Datenpunkt (z. B. JSON-Payload) und versendet ihn synchron oder als Subscription-Stream an den VISS Client.
• Steuerungs- und Schreibpfad (Aktorik / RPC / Egress VISS → fahrzeugintern):
  1. VISS Client sendet einen Schreibbefehl (SET-Request) oder Methodenaufruf an das VISS Interface.
  2. Das VISS Interface validiert die VSS-Pfadsyntax und triggert den Methodenaufruf / Field-Setter am VSS-P-Port.
  3. Die Mapping Application führt Plausibilitätsprüfungen durch, konvertiert die VSS-Parameter in das proprietäre OEM-Datenformat und ruft die Methode/den Setter am entsprechenden R-Port auf.
  4. Aufruf wird über die ara::com-Infrastruktur an den P-Port der zuständigen Providing SWC delegiert.
  5. Rückgabewerte bzw. Fehlercodes (ara::core::ErrorCode) werden über die Mapping-Schicht auf VISS-Fehlercodes (z. B. HTTP/VISS Status 4xx/5xx) zurückgemappt.

4. Normative Relevanz & Entwickler-Hinweise

• Service-Interface-Generierung (VSS-to-ARXML):
  • Entwickler müssen VSS-Baumdefinitionen (vss-tools / YAML) über eine formale Transformations-Toolchain in AUTOSAR-ARXML-Dateien überführen (ServiceInterface mit Stereotypen für Field/Method/Event).
  • Die P-Ports des Gateways implementieren den generierten VSS-Skelett-Code (ara::com::Skeleton), während die R-Ports gegen die proprietären OEM-Proxies (ara::com::Proxy) binden.
• Entkopplung und Wartbarkeit:
  • Änderungen an fahrzeuginternen Bussystemen (CAN, LIN, FlexRay) oder internen SOME/IP-Interfaces erfordern lediglich die Anpassung der Mapping Application innerhalb des Gateways; das VSS-Interface und der VISS Client bleiben unverändert abwärtskompatibel.
• Access Control & Identity/Access Management (IAM):
  • Das VISS Interface bzw. das Gateway muss normative Sicherheitsprüfungen (Authentifizierung und feingranulare Autorisierung pro VSS-Signalpfad) durchführen, bevor Aufrufe an privilegierte fahrzeuginterne Providing SWCs durchgereicht werden.
• Performance- & Threading-Budgets:
  • Die Mapping Application liegt im kritischen Latenzpfad zwischen externen API-Anfragen und bordnetz-interner Kommunikation. Entwickler müssen auf nicht-blockierende Ausführung (asynchrone Futures/Promises in ara::com), threadsichere Pufferung und Zero-Copy-Strategien bei Datenkonversionen achten.