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

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Kontextdiagramm / Systemgrenzen-Diagramm (Package-/Komponenten-Sicht mit «flow»-Stereotypen).
• Technischer Zweck: Definition der primären Interaktions- und Systemgrenzen der AUTOSAR Adaptive Platform (AP) gegenüber On-Board- und Off-Board-Kommunikationspartnern, heterogenen Plattform-Stacks und Applikations-Entitäten.
• Architektur-Einordnung: Verortet in der konzeptionellen Architektur (AUTOSAR_EXP_SWArchitecture, Kapitel 7). Es dient als Fundament für die Protokoll- und Interoperabilitäts-Spezifikation zwischen dienstorientierten AP-Clustern (Functional Clusters / ARA) und signal- bzw. nachrichtenbasierten externen Systemen.

2. Komponenten, Entitäten & Schnittstellen

• Zentrale Systemgrenze:
  • AUTOSAR Adaptive Platform (UML-Package / Subsystem): Umfasst das POSIX-Betriebssystem (PSE51), die Functional Clusters der Adaptive Platform Foundation (u. a. ara::com, ara::exec, ara::diag, ara::ucm, ara::per, ara::crypto) sowie die Adaptive Platform Services.
• Externe Entitäten (UML «component»):
  • Diagnostic Client: On-Board-Tester oder Off-Board-Diagnosewerkzeuge zur Fehlerabfrage, Kalibrierung und Steuergeräte-Identifikation via DoIP (ISO 13400) / UDS (ISO 14229-5).
  • Backend: OEM-Cloud- bzw. Telematik-Infrastruktur für Over-the-Air-Updates (FOTA/OTA via ara::ucm), Flottenmanagement und Telemetriedaten-Austausch.
  • AUTOSAR Classic Platform: Ressourcenbeschränkte CP-Steuergeräte (Deep-Embedded ECUs), angebunden über fahrzeuginterne Busse (CAN/CAN-FD, LIN, FlexRay, Automotive Ethernet).
  • Third-party Platform: Nicht-AUTOSAR-Betriebsumgebungen auf demselben oder vernetzten SoCs (z. B. Linux/Yocto, Android Automotive, QNX, ROS 2 für ADAS/Infotainment).
  • Adaptive Application: Applikationsinstanzen (AAs). Trotz konzeptioneller Ausführung auf der Plattform als eigenständige Komponenten modelliert, um die Entkopplung über standardisierte Laufzeit-Schnittstellen (ARA – AUTOSAR Runtime for Adaptive) hervorzuheben.
• Beziehungen:
  • «flow» (UML InformationFlow Dependency): Sämtliche Kanten sind als bidirektionale, gestrichelte Informationsfluss-Abhängigkeiten modelliert. Sie spezifizieren symmetrischen Datenaustausch ohne Vorab-Festlegung auf einen spezifischen Transportkanal.

3. Dynamisches Verhalten & Sequenzablauf

Das statische Kontextdiagramm definiert keine temporale Ausführungssequenz. Das dynamische Laufzeitverhalten operationalisiert sich über folgende parallele Interaktionsmuster:

• Service-Orientierte Kommunikation (SOME/IP & IPC via ara::com):
  • Adaptive Application <-> AP: Lokale Interprozesskommunikation (POSIX Shared Memory / Unix Domain Sockets) über generierte C++14/17-Proxy/Skeleton-Klassen; Service-Discovery über den Plattform-Discovery-Daemon.
  • AP <-> AUTOSAR Classic Platform: SOME/IP-Events (Pub/Sub) und SOME/IP-Methods (Client/Server) oder Signal-to-Service-Translation über zentrale Gateway-Knoten.
• Diagnosepfad (ara::diag):
  • Diagnostic Client -> AP: DoIP-Verbindungsaufbau (TCP Port 13400), Routing Activation, Empfang von UDS-Messages, Weiterleitung durch den Diagnostic Manager an die registrierten Diagnostic Service Provider (AAs).
• Backend-Kommunikation (ara::ucm / Networking):
  • Asynchrone HTTPS/MQTT/WebSockets-Sitzungen über TLS; Übertragung signierter Software-Pakete (Software Package) an den Update and Configuration Manager (ara::ucm) mit anschließender Manifest-Verifikation und Orchestrierung durch ara::exec.
• Third-party Bridge:
  • Protokolladapter (z. B. DDS-zu-SOME/IP-Gateways, REST-Schnittstellen oder Inter-OS Shared Memory über Hypervisor-Virtualisierung).

4. Normative Relevanz & Entwickler-Hinweise

• ARA-Schnittstellenvertrag: Adaptive Applications dürfen Plattformdienste ausschließlich über die standardisierten ara::*-C++-Header ansprechen. Direkte POSIX-Syscalls an der Plattform vorbei (z. B. direktes Socket-Handling am OS) verletzen das Plattform-Sicherheitskonzept, die Portabilität und den Determinismus (ISO 26262 ASIL-Deklassierung).
• Manifest- und Modell-Konsistenz (ARXML):
  • Für die Interaktion mit der Classic Platform müssen Service Interfaces (SOME/IP) und Classic Signal-Mappings (System Description) konsistent definiert sein. Daten serialisieren strikt nach AUTOSAR-SOME/IP-Transformer-Spezifikation (Payload-Alignment, Big/Little Endianness).
  • Für das Backend müssen Software-Cluster- und Deployment-Manifeste für ara::ucm vollständig kompatibel zu den deklarierten Paketformaten aufgebaut sein.
• Diagnose-Integration: Externe Diagnosetester fordern die Implementierung von DoIP-Entitäten inkl. Vehicle Identification Number (VIN) und Logical Address Mapping. Entwickler von Diagnoseapplikationen müssen Ports an ara::diag anbinden und DEXT-Beschreibungen (Diagnostic Extract) bereitstellen.
• Security & Zugriffssteuerung: Kommunikationsflüsse über die Systemgrenze hinweg erfordern zwingend IAM (Identity and Access Management) Richtlinien, Authentifizierung (SecOC / TLS / IPsec) und Schlüsselverwaltung via ara::crypto.