Figure 7.2: Overview of the AUTOSAR Adaptive Platform and external systems

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Verteilungsdiagramm (Deployment Diagram) mit physischen/logischen Hardwareknoten («device»), geschachtelten Laufzeitumgebungen («executionEnvironment») und typisierten Assoziationen.
• Technischer Zweck: Spezifikation der strukturellen und netzwerktechnischen Integration der AUTOSAR Adaptive Platform in den Fahrzeug- und Backend-Gesamtverbund (Vehicle-Kontext). Das Diagramm visualisiert Rechner-Topologien, Kommunikationsprotokolle («aracom,ethernet», «ethernet,DoIP», «internet», «ethernet»), Multi-Machine-Deployments sowie Daten- und Sicherheitssenken.
• Architektur-Einordnung: Verortet in AUTOSAR_EXP_SWArchitecture (Kapitel 7). Es dient als Referenztopologie für die Systembeschreibung (System Description), die Definition physischer Maschinen (Machine Manifest) sowie die Festlegung von Netzwerk- und Protokollgrenzen.

2. Komponenten, Entitäten & Schnittstellen

• Übergeordnete Systemgrenze Vehicle: Physischer Fahrzeugrahmen zur strikten Abgrenzung von On-Board-Knoten gegenüber Off-Board-Entitäten.
• On-Board-Knoten («device» mit geschachtelten «executionEnvironment»-Instanzen):
  • Machine (zentral): Repräsentiert das primäre High-Performance-Rechensystem (SoC/Prozessor) mit der Laufzeitumgebung Adaptive Platform (POSIX OS, ARA Functional Clusters).
  • Machine (sekundär): Weiterer Rechnerknoten mit Adaptive Platform, vernetzt über «aracom,ethernet» (0..* zu 0..*) zur Abbildung von Multi-Machine-Architekturen.
  • ECU (Classic Platform): Mikrokontrollerbasiertes Steuergerät mit der Laufzeitumgebung Classic Platform, angebunden über «aracom,ethernet» (0..* zu 0..*).
  • ECU (Third-Party Platform): Steuergerät mit Nicht-AUTOSAR-Stack (Third-Party Platform), angebunden über Standard-«ethernet» (0..* zu 0..*).
  • Data Repository: Zentraler Speicherknoten (Kardinalität 1 gegenüber 0..* Rechnern) mit den Ausführungsumgebungen Log Sink (Protokollierung via ara::log) und Security Event Sink (Erfassung von Security-Events via IdsM).
• Externe Knoten («device» außerhalb Vehicle):
  • Diagnostic Tester: Diagnose-Testerwerkzeug (Off-Board-Tester oder Bandende-Tester), verbunden über «ethernet,DoIP» (0..* zu 0..*).
  • Backend: OEM-Cloud- oder Flotteninfrastruktur, angebunden über «internet» (0..* zu 0..*).
  • Ad-Hoc Endpoint: Temporäre oder infrastrukturelle Endpunkte (z. B. V2X/C-V2X, Roadside Units, mobile Endgeräte), verbunden über eine unstereotypisierte Assoziation (0..* zu 0..*).
• Multiplizitäten & Kanten: Sämtliche Kommunikationspfade zu externen Systemen, Classic- und Third-Party-ECUs sowie weiteren Adaptive Machines weisen Kardinalitäten von 0..* zu 0..* auf; die Assoziation von Machine zum Data Repository ist mit 0..* zu 1 modelliert.

3. Dynamisches Verhalten & Sequenzablauf

Das Verteilungsdiagramm bildet eine statische Deployment-Topologie ab. Das dynamische Laufzeitverhalten operationalisiert sich über folgende parallele Protokoll- und Kommunikationspfade:

• Service-Orientierte Inter-Machine- und Inter-Platform-Kommunikation («aracom,ethernet»):
  • SOME/IP-Dienstaufrufe (Methoden, Events, Fields) und Service Discovery über Ethernet zwischen mehreren Adaptive Platform-Knoten sowie zwischen Adaptive Platform und Classic Platform (unter Nutzung von SOME/IP-Serialisierung und Signal-to-Service-Translation).
• Standard-Ethernet-Kommunikation («ethernet»):
  • IP-basierter Datenaustausch (z. B. TCP/UDP-Sockets, MQTT, HTTP oder proprietäre Middleware-Protokolle) mit der Third-Party Platform.
• Diagnosepfad («ethernet,DoIP»):
  • ISO 13400 (DoIP) Verbindungsaufbau vom Diagnostic Tester über TCP/IP zur Adaptive Platform, Weiterleitung der UDS-Nachrichten an ara::diag zur Diagnoseabwicklung und Firmware-Aktualisierung.
• Backend- und Ad-Hoc-Kommunikation («internet»):
  • Gesicherte TLS-Verbindungen (HTTPS, WebSockets, MQTT) über das offene Internet zum OEM-Backend für FOTA-Softwarepakete (ara::ucm) und Telemetrie.
  • Punkt-zu-Punkt- oder Broadcast-Datenaustausch mit dem Ad-Hoc Endpoint für kooperative Fahrfunktionen oder ad-hoc Diagnosesitzungen.
• Logging- und Security-Audit-Pfade:
  • Kontinuierliches oder filterbasiertes Streaming lokaler Diagnose- und Trace-Logs (ara::log) in die Log Sink.
  • Weiterleitung sicherheitsrelevanter Audit-Events und Angriffsmuster (Security Events) an die Security Event Sink zur zentralen Fahrzeug-Sicherheitsüberwachung.

4. Normative Relevanz & Entwickler-Hinweise

• Deployment-Modellierung im AUTOSAR-Metamodell:
  • Knoten müssen im Systemmodell als Machine bzw. EcuInstance deklariert werden. Die Zuweisung von Software-Komponenten erfolgt über entsprechende RootSwComponentPrototype- und Executable-Deployments in den System- und Machine-Manifesten.
• Netzwerk- und Interface-Konfiguration:
  • Die Stereotypen «aracom,ethernet» erzwingen konsistente SOME/IP-Service-Interfaces (ServiceInterface, ServiceInstanceDeployment) über Maschinen- und Plattformgrenzen hinweg.
  • Für «ethernet,DoIP» ist die DoIP-Kanalparametrierung (DoIpConfig, TCP/UDP-Port 13400, Routing Activation Keys) im Diagnose-Manifest von ara::diag zwingend abzustimmen.
• Multiplizitäten und Skalierbarkeit:
  • Die 0..*-Kardinalitäten unterstreichen moderne Multi-SoC- und Central-Compute-Architekturen. Entwickler müssen Netzwerktopologien (VLANs, TSN, Quality of Service) und dynamische Service Discovery auslegen.
  • Die Kardinalität 1 am Data Repository verlangt eine zentrale Ressourcendefinition im Fahrzeugnetzwerk, um Datenverlust bei hoher paralleler Last durch Logging- und Security-Streams mehrerer Knoten zu verhindern.