Figure 4.2: Supported protocols

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Architekturschichten- und Komponentenmodell (Blockdiagramm) der AUTOSAR Adaptive Platform (ARA) mit expliziter Protokoll-Zuordnung (Protocol Mapping View).
• Technischer Kontext: Strukturierung der Laufzeitumgebung ARA (AUTOSAR Runtime for Adaptive Applications) zwischen der Betriebssystemebene (Base Software / POSIX OS) und den eigentlichen Applikationsprozessen (User Application). Es definiert die funktionale Gruppierung der Functional Clusters (FCs) und hebt die jeweils normativ unterstützten Kommunikations-, Diagnose-, Synchronisations- und Schnittstellenprotokolle hervor.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm gliedert das Gesamtsystem in drei horizontale Hauptschichten sowie vier Cluster-Klassen innerhalb von ARA:

1. User Application:
   • Beinhaltet die binaries/executables (Application), die als separate POSIX-Prozesse laufen.
2. AUTOSAR Runtime for Adaptive Applications (ARA):
   • OS-Abstraktion (vertikal links): POSIX PSE51 / C++ STL Operating System Interface – Schnittstelle zur Kapselung des OS-Zugriffs für Applikationen und Functional Clusters unter Einhaltung des PSE51-Minimalprofils.
   • Platform Foundation Functional Clusters (FCs) (Bibliotheken/Daemons im C++-Namespace ara::*):
     • Communication Management (Middleware): Unterstützt SOME/IP, S2S (Signal-to-Service), DDS und prozesslokales zero-copy IPC.
     • Execution Management (ara::exec): Prozess-Lebenszyklus, State Management Integration, Determinismus.
     • Diagnostic Management (ara::diag): On-/Off-Board-Diagnose via DoIP (ISO 13400), UDS (ISO 14229) und SOVD (Service-Oriented Vehicle Diagnostics, ASAM/ISO 13400-3).
     • Intrusion Detection System Manager (ara::idsm): Security-Event-Erfassung via standardisiertem IDS-Protokoll.
     • Network Management (ara::nm): Bus-Schlaf-/Wach-Zustände via UdpNM.
     • Persistency (ara::per): Key-Value- und File-Storage.
     • Time Synchronization (ara::tsync): Netzwerkweite Uhrzeitsynchronisation via gPTP (IEEE 802.1AS).
     • Cryptography (ara::crypto): Krypto-Primitiven, Zertifikats- und Key-Management.
     • Raw Data Stream (ara::rds): Low-Latency-Socket-Streaming via TCP und UDP.
     • Platform Health Management (ara::phm): Alive-, Deadline- und Logical-Supervision.
     • Log and Trace (ara::log): Standardisiertes Logging via DLT (Diagnostic Log and Trace).
     • Firewall (ara::fw): Paket- und Zustandsfilterung auf Netzwerkebene.
     • Core (ara::core): Grundtypen, Fehlertypen (ara::core::Result, ErrorCode), Memory- und String-Abstraktionen.
   • Platform Service FCs (Dienste via ara::com):
     • Update and Config Management (ara::ucm service): ECU-internes Software-Paket-Update.
     • State Management (ara::sm service): Koordination von Machine- und Function-States.
   • Standardized App/Interface FCs:
     • Sensor Interfaces (ara::adi::sensoritf service): Standardisierte Schnittstelle für Fahrerassistenz/Automated Driving gemäß ISO 23150.
   • Vehicle Service FCs:
     • Vehicle Update and Config Management (ara::vucm service): Fahrzeugweites OTA-Update- und Kampagnen-Management.
     • Automotive API Gateway (ara::aag): Standardisiertes Gateway für den Zugriff auf Fahrzeugdaten und -dienste via VISS (Vehicle Information Service Specification).
   • Erweiterbarkeit: Vertikale Auslassungspunkte (...) kennzeichnen die modulare Erweiterbarkeit der jeweiligen Cluster-Kategorien.
3. Base Software:
   • POSIX OS: Zugrundeliegendes Betriebssystem (z. B. Linux, QNX), das grundlegende Systemdienste wie Threading, Speicher- und Dateiverwaltung sowie Netzwerk-Sockets nach POSIX PSE51 bereitstellt.

3. Dynamisches Verhalten & Sequenzablauf

• Interprozess- und Netzwerkkommunikation: Applikationen interagieren über Communication Management (ara::com). Lokal erfolgt der Datenaustausch über prozesslokales zero-copy IPC. Über das Fahrzeug-Ethernet-Netzwerk werden Methoden und Events über SOME/IP oder DDS serialisiert, bzw. über Signal-to-Service (S2S) an Classic-Plattform-Gateways angebunden.
• Fahrzeug-API-Zugriff: Das neu eingeführte Automotive API Gateway (ara::aag) ermöglicht externen und fahrzeuginternen Clients den standardisierten Zugriff auf Fahrzeugdatenpunkte und -funktionen über das VISS-Protokoll.
• Diagnose und Systemüberwachung: Externe Diagnosetester kommunizieren über IP mit ara::diag via DoIP (ISO 13400) und UDS (ISO 14229) oder modern via SOVD. Sicherheitsrelevante Ereignisse werden erfasst und über das IDS-Protokoll an den idsm übermittelt.
• Netzwerkzustände und Synchronisation: Network Management koordiniert den Buszustand zyklisch über UdpNM. Die Taktsynchronisation erfolgt kontinuierlich über das gPTP-Protokoll (IEEE 802.1AS).
• Streaming und Logging: Sensor- und Rohdatenströme werden über ara::rds direkt über TCP oder UDP übertragen. Protokolldaten und Traces werden über das DLT-Protokoll an Logging-Tools exportiert.
• Sensor-Integration: ADAS-Sensordaten fließen strukturiert über Sensor Interfaces gemäß dem Standard ISO 23150 ein.
• Plattform- und Fahrzeugdienste: ara::ucm service, ara::sm service und ara::vucm service stellen serviceorientierte Schnittstellen über die Middleware bereit, um Systemzustände, lokale Software-Paket-Updates bzw. flottenweite OTA-Kampagnen zu steuern.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Protokollbindung: Die rot hinterlegten Boxen spezifizieren verbindliche Protokolle für konforme Implementierungen. Neu verankert ist VISS als normatives Protokoll für das Automotive API Gateway (ara::aag), neben den bestehenden Protokollen SOME/IP, S2S, DDS, zero-copy IPC, DoIP, UDS, SOVD, IDS, UdpNM, gPTP, TCP/UDP, DLT und ISO 23150.
• Schichten- und Schnittstellendisziplin:
  • Applikationen dürfen ausschließlich über standardisierte ara::*-C++-Schnittstellen oder die durch POSIX PSE51 / C++ STL definierten OS-Primitives auf Plattformressourcen zugreifen. Direkte Systemaufrufe an das POSIX OS, die das PSE51-Profil verletzen, sind normativ unzulässig.
  • Platform Foundation FCs stellen primär C++-Bibliotheken/lokale APIs bereit, während Platform Service FCs und Vehicle Service FCs als eigenständige Serverprozesse realisiert sind und ihre Dienste typisiert über ara::com zur Verfügung stellen.
• Erweiterbarkeit: Die mit Auslassungspunkten (...) versehenen Leerfelder deuten an, dass anwendungsspezifische oder künftige funktionale Cluster hinzugefügt werden können, solange sie das Schichtenmodell und die ARA-Konzepte respektieren.