Figure 10.6: Use cases for the Automotive API Gateway

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Anwendungsfalldiagramm (Use Case Diagram) unter Verwendung des AUTOSAR-Adaptive-Profils (Stereotypen «aapUseCase», «aapTriggers», «aapParticipates»).
• Funktionale Einordnung: Spezifikation des Funktionsclusters Automotive API Gateway (AAG) innerhalb der AUTOSAR Adaptive Platform (AP, Release R24-11, AUTOSAR_AP_EXP_SWArchitecture).
• Technischer Zweck: Das Automotive API Gateway fungiert als zentraler Abstraktions- und Übersetzungslayer. Es entkoppelt standardisierte fahrzeugexterne sowie fahrzeuginterne Clients von der heterogenen fahrzeuginternen Steuergeräte- und Bus-Topologie. Datenabfragen und -manipulationen werden einheitlich gekapselt – unabhängig davon, ob die Ziel-Datenquelle auf der Adaptive Platform (AP) oder der Classic Platform (CP) realisiert ist.

2. Komponenten, Entitäten & Schnittstellen

Systemgrenzen (Boundaries)

• Adaptive Platform: Laufzeitumgebung der POSIX-basierten AUTOSAR-Schicht.
• Automotive API Gateway: Subsystem-Boundary des AAG-Clusters, das die Routing-, Transformations- und Vermittlungslogik kapselt.

Akteure (Actors)

• Onboard Client (from Actors): Fahrzeuginterner Konsument außerhalb des AAG (z. B. Infotainment/IVI, Cockpit-Domänenrechner oder autonome Fahrsysteme).
• Offboard Client (from Actors): Fahrzeugexterner Konsument (z. B. OEM-Cloud-Backend, Flottenmanagement-Server oder Werkstatt-/Diagnosetester).
• Adaptive Application (from Actors): Datenprovider/Server innerhalb der Adaptive Platform, angebunden über Service-orientierte Schnittstellen (ara::com).
• Classic Application (from Actors): Datenprovider/Server auf einem AUTOSAR Classic Steuergerät, angebunden über signalbasierte Netzwerke (CAN, LIN, FlexRay) oder Classic-SOME/IP.

Anwendungsfälle («aapUseCase») & Relationen

• Access Data (Basis-Use-Case): Abstrakte Generalisierung für sämtliche Datenzugriffsoperationen (Lesen, Schreiben, Subskribieren) auf Fahrzeugdaten (z. B. standardisiert via COVESA/W3C Vehicle Signal Specification – VSS).
• Access Data inside Adaptive Application: Spezialisierter Use Case (UML-Generalisierung auf Access Data), der den Zugriffspfad auf Datenstrukturen innerhalb von AP-Instanzen abbildet.
• Access Data inside Classic Application: Spezialisierter Use Case (UML-Generalisierung auf Access Data), der den Zugriffspfad auf Signale/Parameter in CP-ECUs abbildet.
• Stereotypen:
  • «aapTriggers»: Gerichtete Initiierung von Onboard Client und Offboard Client auf den Basis-Use-Case Access Data.
  • «aapParticipates»: Assoziation der Datenquellen (Adaptive Application und Classic Application) als teilnehmende Endpunkte an den jeweiligen spezialisierten Use Cases.

3. Dynamisches Verhalten & Sequenzablauf

Aus dem Use-Case-Modell leiten sich folgende operative Ausführungspfade ab:

1. Triggering:
   • Ein Client (Onboard Client oder Offboard Client) sendet eine Zugriffsanforderung (z. B. REST/HTTP, WebSocket, gRPC oder MQTT) an das Automotive API Gateway.
2. Protokoll- und Adress-Translation im Gateway:
   • Pfad AP (Access Data inside Adaptive Application): Das Gateway übersetzt die Anfrage in Service-orientierte Aufrufe über ara::com (Method-Call, Field-Get/Set oder Event-Subscription via SOME/IP bzw. POSIX Shared Memory IPC).
   • Pfad CP (Access Data inside Classic Application): Das Gateway fungiert als Signal-to-Service-Übersetzer. Die API-Anfrage wird auf PDU-/Signal-Ebene serialisiert (z. B. über ein integriertes Signal-to-Service-Mapping auf CAN/Ethernet oder über CP-SOME/IP-RTE-Schnittstellen).
3. Synchrones vs. asynchrones Verhalten:
   • Get/Set-Operationen: Werden gatewayintern über asynchrone Mechanismen (ara::core::Future / ara::core::Promise) abgearbeitet und synchron oder asynchron an den Client zurückgemeldet.
   • Event-/Sensor-Streaming: Subskriptionen etablieren persistente Datenströme; Änderungen an AP-Events oder CP-Signalen triggern asynchrone Push-Notifikationen an den Client.
4. Fehlerbehandlung:
   • Timeouts, ungültige Signalwerte (Signal-Invalidität/Qualitätsflags) oder Kommunikationsfehler auf Bus-Ebene werden durch das AAG in standardisierte Fehlercodes (z. B. HTTP 4xx/5xx oder API-spezifische Error-Objekte) transformiert.

4. Normative Relevanz & Entwickler-Hinweise

• Entkopplung der Schnittstellen: Applikations- und Backend-Entwickler greifen auf eine einheitliche API-Syntax zu; Kenntnisse über ECU-Netzwerktopologien, Busprotokolle (CAN/FlexRay/SOME/IP) oder PDU-Layouts sind für Clients nicht erforderlich.
• Konfigurationsanforderung (AP-Entwickler): Daten, die über das AAG exponiert werden sollen, müssen in den Adaptive-Manifesten (arxml) als Service-Interfaces modelliert und dem AAG-Deployment zugeordnet sein.
• Signal-to-Service-Mapping (Classic-Integration): Für Classic-ECUs erfordert die Umsetzung ein deterministisches Mapping zwischen signalbasierten PDUs (Com-Stack) und den API-Ressourcen des Gateways. Signallaufzeiten und Gateway-Jitter müssen bei harten Echtzeitanforderungen budgetiert werden.
• Sicherheits- & Zugriffsarchitektur (Security / IAM): Das AAG muss zwingend mit dem Identity and Access Management (IAM) der Adaptive Platform gekoppelt sein, um Berechtigungen von Offboard- vs. Onboard-Clients auf Datenebene abzusichern und unberechtigte Schreibzugriffe auf fahrrelevante Classic-Signale abzuwehren.