Figure 3.2: Exemplary interactions of AP and CP

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Informatives Architekturschaubild / Domänen- und Datenflussdiagramm (funktionales Wirkkettendiagramm mit Zonenaufteilung).
• Kontext: AUTOSAR_AP_EXP_PlatformDesign, Kapitel 3 (Architecture overview / Exemplary interactions of AP and CP).
• Technischer Zweck: Darstellung der funktionalen Allokation und domänenübergreifenden Koexistenz von AUTOSAR Classic Platform (CP, Zone C) und AUTOSAR Adaptive Platform (AP, Zone A) im Anwendungsfall hochautomatisierten Fahrens (HAD / ADAS) inklusive Anbindung externer Backend-Dienste.

2. Komponenten, Entitäten & Schnittstellen

Entitäten der AUTOSAR Classic Platform (Domäne C)

• Sensor- & I/O-Ebene (Links):
  • C2C / C2I: V2X-Kommunikationsendpunkt (Car-to-Car, Car-to-Infrastructure) zur Erfassung kooperativer Fahrzeug-/Infrastrukturmeldungen.
  • camera, radar, lidar, ...: Mehrkanalige Umfeldsensorik (Objekterfassung, Rohdatenakquise, Vorverarbeitung).
  • inertial sensors, odometry, GPS, ...: Eigenbewegungs- und Lokalisierungssensorik (IMU, Raddrehzahlen/Odometrie, GNSS).
• Aktuatorik- & Sicherheitsregelung (Unten):
  • trajectory control: Regelung der Fahrzeugaktorik (Längs- und Querführung, Antrieb, Bremse, Lenkung) unter harten Echtzeitbedingungen.
  • safety function: Integrierter Sicherheitsprüfungs- und Fallback-Baustein (Safety-Cage/Checker) innerhalb der Trajektorienregelung.

Entitäten der AUTOSAR Adaptive Platform (Domäne A)

• environment, driver state and vehicle state perception: Rechenintensive Fusionsstufe zur Erstellung des konsolidierten Umfeld-, Fahrer- und Fahrzeugzustands (Deep Learning, SLAM, Fahrerbeobachtung, Multisensorfusion).
• maneuver- and trajectory planning: Planungsebene für Manöverentscheidungen sowie spatio-temporale Soll-Trajektoriengenerierung.

Externe Entität (Off-Board)

• authority, OEM, map, ... via backend: Cloud- und Flotteninfrastruktur (statische/dynamische HD-Karten, Verkehrs- und Flottendaten, behördliche Vorgaben/Geofencing).

Schnittstellen & Datenflüsse

• Backend → AP: IP-basierte WAN-Kommunikation zur Einspeisung von Kartendaten und Over-the-Air-Attributen in die Perception.
• CP (Sensoren/V2X) → AP: Übertragung bandbreitenintensiver Sensorströme und V2X-Daten über fahrzeuginterne Netze (typisch Automotive Ethernet via SOME/IP oder DDS) an die AP-Perception.
• AP-intern: environment and state model – strukturierte Umfeldrepräsentation/Freiraumgitter als Schnittstelle zwischen Perception und Trajektorienplanung (via ara::com / POSIX IPC / Shared Memory).
• AP → CP: trajectory – Soll-Trajektorie (Stützpunkte, Zeitstempel, Krümmung, Geschwindigkeits-/Beschleunigungsprofil) an die CP trajectory control.
• CP-intern (Sensoren → CP-Aktorik): Unabhängiger, direkter Sensorpfad von Radar/Lidar/Kamera und IMU/Odometrie/GPS zur safety function zur redundanten Verifikation ohne Abhängigkeit von der AP.

3. Dynamisches Verhalten & Sequenzablauf

1. Kontinuierliche Akquise (CP): Sensorik und V2X-Knoten erfassen zyklisch Rohdaten/Objektlisten mit harter Periodizität (1\,ms - 20\,ms) auf Mikrocontrollern der Classic Platform.
2. Duale Datenverteilung (CP → AP & CP):
   • Vollständiger Sensordatenstrom wird an die High-Performance-Recheneinheit (AP) übertragen.
   • Kritische Roh-/Basisdaten werden parallel und zeitsynchron direkt an die CP-eigene safety function geleitet.
3. Kontext-Anreicherung & Fusion (AP): Perception aggregiert Sensordaten mit asynchron empfangenen Backend-/Kartendaten und generiert zyklisch das environment and state model.
4. Trajektoriengenerierung (AP): Die Planungsinstanz berechnet prädiktive Zielpfade und serialisiert diese in ein Soll-Trajektorien-PDU/Event (trajectory).
5. Plausibilisierung & Fallback (CP safety function):
   • Die empfangene Trajektorie wird gegen die redundanten, nativen Sensordaten geprüft (Kollisionskorridore, dynamische Beschleunigungsgrenzen).
   • Bei Timeout der AP, Software-Absturz (POSIX-Ebene) oder unplausibler Trajektorie entzieht die safety function der AP die Führung und triggert ein deterministisches Minimal Risk Maneuver (MRM, z. B. Notbremsung).
6. Regelung (CP trajectory control): Nach erfolgreicher Validierung transformiert die Regelung die Trajektorie in direkte Aktor-Stellgrößen (Motormoment, Bremsdruck, Lenkwinkel).

4. Normative Relevanz & Entwickler-Hinweise

• Safety-Dekomposition (ISO 26262):
  • Das Schaubild visualisiert ein klassisches Doer-Checker-Muster (E2E-Safety-Architektur).
  • Die AP agiert als "Doer" mit hoher Rechenleistung (typisch ASIL B oder QM-Dekomposition für komplexe Algorithmen/KI).
  • Die CP agiert als unabhängiger "Checker" / Sicherheitskäfig auf ASIL-D-Niveau zur Beherrschung systematischer und zufälliger Fehler der AP.
• Kommunikations-Stack & Signal-to-Service:
  • Datenaustausch zwischen CP und AP erfordert standardisierte Protokolle (z. B. SOME/IP über ara::com auf AP-Seite und SoAd/SomeIpXf/LdCom auf CP-Seite).
  • Sensor-zu-Perception-Pfade erfordern Null-Kopier-Mechanismen oder Ethernet-AVB/TSN zur Begrenzung von Latenz und Jitter.
• Pufferung & Latenztoleranz:
  • Da AP-Planungszyklen unter Linux/QNX jitterbehaftet sind (20\,ms - 100\,ms), muss die CP-Trajektorienregelung interpolierende Puffer (Lookahead-Trajektorien) verwalten.
• Stack- & Modulkonfiguration:
  • CP: Konfiguration von WdgM (Supervision der AP-Heartbeats), PduR/EthIf für Ethernet-Durchsatz, sowie ASIL-D-konforme Treiberansteuerung von Aktoren via MCAL.
  • AP: Konfiguration von Execution Management (Startreihenfolge, Restart-Strategien für Perception/Planning), State Management und Deterministic Client (ara::exec) für reproduzierbare Trajektorienberechnung.