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.
   • Erweiterbarkeit: Vertikale Auslassungspunkte (...) kennzeichnen die modulare Erweiterbarkeit der jeweiligen Cluster-Kategorien.
3. Base Software:
   • POSIX OS: Zugrundeliegendes Echtzeitbetriebssystem (z. B. Linux RT, QNX Neutrino, PikeOS) mit POSIX-PSE51-Konformität.

3. Dynamisches Verhalten & Sequenzablauf

Obwohl als statisches Komponentenmodell ausgeführt, diktieren die rot hinterlegten Protokoll-Bindings das dynamische Laufzeitverhalten:

• Service-Orientierte Interaktion (ara::com):
  • Asynchrone Publish/Subscribe-Ereignisse (Event) via SOME/IP oder DDS.
  • Synchrone oder Future-basierte (ara::core::Future) Methodenaufrufe (Request/Response) sowie Fire-and-Forget-Methoden.
  • Lokale Kommunikation wird transparent über zero-copy IPC (Shared Memory) unter Umgehung des Netzwerk-Stacks abgewickelt.
• Diagnosepfade (ara::diag):
  • Klassische Diagnose-Testeranfragen werden über DoIP/UDS entgegengenommen und auf interne Port-Interfaces dispatchet.
  • Moderne Cloud-/HPC-Diagnose erfolgt parallel asynchron über REST/WebSocket-basierte SOVD-APIs.
• Zeitsynchronisation (ara::tsync):
  • Kontinuierliche Hintergrundabwicklung des Pdelay- und Sync-Mechanismus nach IEEE 802.1AS (gPTP) zur Disziplinierung der lokalen Hardware- und POSIX-Clocks.
• Bulk Data Streaming (ara::rds):
  • Unterbrechungsfreier Transport großer Nutzlasten (Kamerabilder, Radar-Raw-Data) unter Umgehung der Service-Serialisierung via nativer TCP/UDP-Streams.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag & Entkopplung: Applikationen dürfen Protokolle (wie SOME/IP, UdpNM, gPTP) nicht direkt über native OS-Sockets ansprechen. Sämtliche Protokoll-Stacks sind hinter den abstrakten C++-Interfaces (ara::*) gekapselt. Einzige Ausnahme für raw Socket-Zugriff ist ara::rds.
• Prozess- und Fehlermodell:
  • FCs kommunizieren untereinander entweder über C++ In-Process-APIs (Foundation) oder als eigenständige Prozesse via ara::com-Services (Service FCs).
  • Kein C++-Exception-Handling im normativen API-Vertrag: Fehler müssen zwingend über monadische Typen (ara::core::Result<Value, ErrorCode>) verarbeitet werden.
• Konfiguration & Manifest-Bindung:
  • Jedes rot annotierte Protokoll erfordert ein korrespondierendes AUTOSAR-Manifest (Service Instance Deployment, SOME/IP Transformation Props, DoIP Routing, Machine Manifest für Network Endpoints).
• Plattform-Portabilität (PSE51): Entwickler von Treibern und Foundation-FCs müssen die Einhaltung des POSIX-PSE51-Subsets sicherstellen (Single Process, Multi-Threaded Modell pro Executable, deterministisches Scheduling via SCHED_FIFO/SCHED_RR).