Figure 3.1: Exemplary deployment of different platforms

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Schematisches System-Deployment- und Topologiediagramm (High-Level E/E-Fahrzeugnetzwerk- und Konnektivitätsarchitektur).
• Technischer Zweck & Einordnung: Entstammt dem Konzeptdokument AUTOSAR_AP_EXP_PlatformDesign (Kapitel 3, Architecture / Context). Es visualisiert die koexistente Multi-Plattform-Zielarchitektur moderner Kraftfahrzeuge: die funktionale und physikalische Aufteilung zwischen der AUTOSAR Adaptive Platform (AP), der AUTOSAR Classic Platform (CP), Non-AUTOSAR-Systemen (COTS/IVI/TCU), peripherer Sensorik/Aktorik sowie der externen Kommunikationsinfrastruktur (Cloud/V2X).

2. Komponenten, Entitäten & Schnittstellen

• Knoten A (Adaptive AUTOSAR Platform):
  • High-Performance Compute Units (HPC / Domain Controller), basierend auf Multi-Core-Mikroprozessoren (64-Bit POSIX OS, PSE51/PSE52).
  • Bereitstellung von rechenintensiven, dynamischen Workloads (z. B. Sensorfusion, Bahnplanung, ADAS) über das C++-basierte ara::*-Laufzeit-Framework.
• Knoten C (Classic AUTOSAR Platform):
  • Deep-Embedded Mikrocontroller (MCU, OSEK/VDX-kompatibles AUTOSAR OS).
  • Auslegung für harte Echtzeitanforderungen, statische Speicherallokation und funktionale Sicherheit bis ASIL D.
  • Frontknoten mit Kamerasymbol: Smart Sensor / Pre-Processing Controller (Anbindung an Sensorschnittstellen via CSI-2, LVDS, SPI oder Automotive Ethernet).
  • Heckknoten mit Knoten M: Aktor-Steuergerät zur direkten Ansteuerung mechatronischer Lasten (Elektromotor, Leistungselektronik, Inverter) über PWM, ADC, SPI oder Schnittstellen wie SENT.
• Knoten N (Non-AUTOSAR / IVI / COTS):
  • Standardbetriebssysteme (z. B. Linux, Android Automotive, QNX COTS).
  • Dachantennen-Knoten N: Telematics Control Unit (TCU) / Konnektivitäts-Gateway mit Mobilfunk-Transceiver.
  • Unterer Knoten N: Infotainment-Headunit (IVI), Fahrer-HMI oder Third-Party-Subsysteme ohne AUTOSAR-Basissoftware.
• In-Vehicle-Backbone (Horizontale Buslinie):
  • Heterogenes Bordnetzwerk. Typischerweise Automotive Ethernet (IEEE 802.3cg/bw/ch, 100BASE-T1 / 1000BASE-T1) als Backbone zwischen AP- und Gateway-Knoten; CAN-FD, LIN und FlexRay als deterministische Feldbusse zur Sensor-/Aktor- und CP-Anbindung.
• Externe Entitäten (V2X / Off-Board):
  • Internet / ETSI: Funkübertragungsstrecken (4G/5G Mobilfunk, ETSI ITS-G5, C-V2X PC5).
  • Backend Systems / Road-Side Infrastructure: OEM-Backend (Cloud-Server, Datenbanken für Flottenmanagement, OTA/UCM) und Road-Side Units (RSU für kooperative Infrastrukturdaten).

3. Dynamisches Verhalten & Sequenzablauf

Da es sich um ein statisches Topologie- und Bereitstellungsdiagramm handelt, definieren sich die dynamischen Pfade über die Kommunikationsflüsse:

• North-South-Fluss (Backend-to-Vehicle / Telematik):
  1. Backend/RSU sendet Daten via Mobilfunk/ETSI an die Antenneneinheit (TCU, Knoten N).
  2. Weiterleitung über den Ethernet-Backbone an die Adaptive Platform (Knoten A).
  3. Validierung (Signaturprüfung über ara::crypto), Entpacken und Prozessierung (z. B. durch ara::ucm für Software-Updates oder Navigations-/Routingdienste).
• East-West-Fluss (Inter-Platform & Cross-Domain IPC):
  • Service-to-Signal Gatewaying: Die Adaptive Platform kommuniziert serviceorientiert (ara::com via SOME/IP oder DDS). Die Classic Platform verarbeitet signalbasierte PDUs.
  • Transformation erfolgt im Gateway oder direkt im CP-Ethernet-Stack (SoAd, PduR, SomeIpXf / SOME/IP Transformer).
• Echtzeit-Regelkreis (Sense-Plan-Act):
  • Wahrnehmung: Front-Sensorik/Kamera erfasst Rohdaten → Vorverarbeitung in CP (C) oder Direkteinspeisung in AP (A).
  • Verarbeitung: Dynamische Algorithmen auf AP berechnen Trajektorien → Übermittlung aggregierter Sollwerte an CP (C).
  • Aktion: CP führt Sicherheitsplausibilisierung (ASIL D Watchdog/Safety-Gate) durch und bestromt die mechatronische Last (M).

4. Normative Relevanz & Entwickler-Hinweise

• E/E-Partitionierung & Allokation:
  • Applikationen mit dynamischem Speicherbedarf, komplexer Middleware (POSIX Threads, C++ Standardbibliothek) und wechselnden Deployments gehören auf die Adaptive Platform.
  • Hard Real-Time Loops (< 1\,ms Zykluszeit, Jitter im $\mu\text{s}$-Bereich), direkter HW-Registerzugriff (MCAL) und Fail-Operational-Basisfunktionen dürfen nicht auf AP verlagert werden, sondern verbleiben im Classic-Stack.
• Schnittstellenverträge & Transformation:
  • Der Datenaustausch zwischen AP und CP erfordert konsistente Systembeschreibungen (ARXML). Entwickler müssen zwingend auf kompatible SOME/IP-Datentypserialisierung (Alignment, Big/Little Endian, String-Codierung) und identisch konfigurierte End-to-End-(E2E)-Schutzprofile achten.
• Perimeter-Security & Trust Boundaries:
  • Knoten N (COTS/Telematik) stellt eine ungesicherte Vertrauensdomäne (Untrusted Boundary) dar. Direkter Zugriff auf den Aktor-CP-Knoten (C/M) ist architektonisch unzulässig.
  • Integration von Firewalling (Ethernet/IP), Transportverschlüsselung (IPsec, TLS, MACsec) sowie Signal-Authentifizierung (SecOC auf CP-Ebene) ist zwingende Voraussetzung für die Absicherung gegen V2X-basierte Angriffsvektoren.