Figure 1.1: Automotive API Gateway as a new Vehicle Service Functional Cluster in the Adaptive Platform architecture.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Schichtenbasiertes Architektur-Blockdiagramm (Layered Architecture Diagram) der AUTOSAR Adaptive Platform (AP) gemäß AUTOSAR-Spezifikation (Dokument: AUTOSAR_AP_EXP_AutomotiveAPI, Releases R24-11 / R25-11).
• Technischer Zweck & funktionale Einordnung:
  • Systemische Verortung des neu eingeführten Functional Clusters (FC) Automotive API Gateway (ara::aag) innerhalb der ARA-Schicht (AUTOSAR Runtime for Adaptive Applications).
  • Differenzierung der ARA-Funktionalblöcke in vier distinkte Cluster-Klassen:
    1. Platform Foundation Functional Clusters (lokale Bibliotheken/Basisfunktionalitäten im Prozesskontext),
    2. Platform Service Functional Clusters (maschinenlokale Systemdienste),
    3. Standardized App/Interface Functional Clusters (standardisierte Sensor-/Aktor-Abstraktionen),
    4. Vehicle Service Functional Clusters (netzwerk- und fahrzeugweite Dienste).
  • Das Automotive API Gateway (ara::aag) wird explizit der Domäne der Vehicle Service FCs zugeordnet (neben ara::vucm), um standardisierten fahrzeugweiten Zugriff auf Datenmodelle (z. B. COVESA Vehicle Signal Specification / VSS) und High-Level-APIs über standardisierte Service-Schnittstellen bereitzustellen.

2. Komponenten, Entitäten & Schnittstellen

Schichtenhierarchie (Top-Down):

1. User Application Layer:
   • Application: Adaptive Applications (AA) im User Space, die als eigenständige Betriebssystemprozesse mit eigenen Adressräumen ausgeführt werden.
2. AUTOSAR Runtime for Adaptive Applications (ARA):
   • Vertikale Schnittstellenabstraktion (OS-Interface):
     • POSIX PSE51 / C++ STL Operating System Interface: Schnittstellendefinition basierend auf IEEE 1003.13 PSE51 (Single Process Multi-Threaded Profile) und Standard C++ STL. Kapselt das Host-OS gegen direkte non-standardisierte Zugriffe ab.
   • Platform Foundation Functional Clusters (FCs) (Kern-Laufzeitbibliotheken):
     • Communication Management (ara::com): Serviceorientierte Middleware (SOME/IP, IPC).
     • Execution Management (ara::exec): Prozesslebenszyklus, State Client, Deterministic Execution.
     • Diagnostic Management (ara::diag): Diagnoseprotokollabstraktion (UDS via DoIP).
     • Intrusion Detection System Manager (ara::idsm): Erfassung von Security-Events (SEv).
     • Network Management (ara::nm): Teilnetz- und Buszustandsverwaltung.
     • Persistency (ara::per): Key-Value- und File-Storage.
     • Time Synchronization (ara::tsync): Synchronisierte Zeitbasen (IEEE 802.1AS / gPTP).
     • Cryptography (ara::crypto): PKI, Signaturprüfung, Verschlüsselung, CSPs.
     • Raw Data Stream (ara::rds): Optimierter Transport unstrukturierter Sensordatenströme.
     • Platform Health Management (ara::phm): Alive-, Deadline- und Logical Supervision.
     • Log and Trace (ara::log): Standardisiertes DLT-Logging.
     • Firewall (ara::fw): Transport- und Netzwerkpaketfilterung.
     • Core (ara::core): Primitivtypen, Fehlerbehandlung (ara::core::Result, ara::core::ErrorCode, ara::core::Span, ara::core::InstanceSpecifier).
   • Platform Service FCs (Maschinen-Services via ara::com):
     • Update and Config Management (ara::ucm service): Lokales Paket- und Software-Update-Handling.
     • State Management (ara::sm service): Zustandssteuerung für Function Groups und Machines.
   • Standardized App/Interface FCs:
     • Sensor Interfaces (ara::adi::sensoritf service): Standardisierte Roh- und Prozessdaten-Interfaces für Fahrerassistenz/Sensorik.
   • Vehicle Service FCs (Fahrzeugweite verteilte Dienste):
     • Vehicle Update and Config Management (ara::vucm service): Flotten- und fahrzeugweite Update-Orchestrierung.
     • Automotive API Gateway (ara::aag) (hervorgehoben): Gateway-Cluster zur Kapselung und Vermittlung von fahrzeugweiten Daten- und Funktions-APIs (Signal-to-Service-Translation, API-Projektion).
3. Base Software Layer:
   • POSIX OS: Zugrundeliegendes Echtzeit-Betriebssystem (z. B. QNX Neutrino, Linux mit RT-Patch, PikeOS) mit POSIX-PSE51-Subset.

3. Dynamisches Verhalten & Sequenzablauf

Das Architekturdiagramm stellt eine statische Komponenten- und Schichtenstruktur dar. Das implizierte Laufzeitverhalten gestaltet sich wie folgt:

• Lebenszyklus: ara::aag wird als System-Service-Prozess unter Kontrolle von ara::exec während der Initialisierungsphase einer definierten Function Group (z. B. MachineState oder ServiceMode) gestartet und durch ara::phm überwacht.
• Service-Interaktion (In-Vehicle):
  1. Application bindet über einen generierten Proxy (ara::com) an den von ara::aag bereitgestellten Service an (FindService / Subscribe / Method Call).
  2. ara::aag löst eingehende High-Level-API-Aufrufe (z. B. Zugriff auf standardisierte VSS-Fahrzeugpfade) über interne Übersetzungstabellen auf interne Signale, Platform Foundation FCs (ara::com, ara::crypto) oder externe Gateways auf.
  3. Rückmeldungen und Events erfolgen asynchron über ara::core::Future / ara::core::Result bzw. Publish/Subscribe-Event-Pipelines.
• Sicherheits- und Zugriffskontrolle: Jede Transaktion durch ara::aag unterliegt der Richtlinienprüfung via ara::crypto (Authentizität) und meldet sicherheitsrelevante Anomalien asynchron an ara::idsm.

4. Normative Relevanz & Entwickler-Hinweise

• Service- vs. Bibliothekscharakter:
  • Im Gegensatz zu Platform Foundation FCs (ara::per, ara::core), die als Header und statische/dynamische Link-Bibliotheken direkt in den Adressraum der AA gelinkt werden, ist ara::aag als eigenständiger Service-Daemon implementiert.
  • Der Zugriff durch Applikationsentwickler erfolgt ausschließlich über Service-Proxies via ara::com oder dedizierte IPC-Transporte.
• Konfigurationsanforderungen (ARXML & Manifeste):
  • Execution Manifest: Definition des Startverhaltens, der Ressourcenlimits und der Scheduling-Priorität für den ara::aag-Prozess.
  • Service Instance Manifest: Bereitstellung der ProvidedServiceInstance für ara::aag inklusive Endpoint-Binding (SOME/IP-Deployment, EventGroup- und Method-IDs) und Zugriffskontrollregeln (IAM / Identity and Access Management).
  • Adaptive Application Manifest: Entsprechende RequiredServiceInstance-Konfigurationen in den konsumierenden Applikationen.
• API-Design:
  • C++-Interface unter dem Namespace ara::aag.
  • Ausnahmslose Verwendung von ara::core::Result<ValueType, ara::core::ErrorCode> anstelle von C++-Exceptions (AUTOSAR C++14/C++20 Coding Guidelines, Rule A15-0-1).
• Target-Plattform & OS-Einschränkungen:
  • Keine Verwendung von POSIX-Calls außerhalb des PSE51-Umfangs innerhalb des ara::aag-Stacks, um Portabilität auf zertifizierten RTOS-Plattformen sicherzustellen.