Figure 4.1: AP architecture logical view

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Logisches Schichten- und Säulenmodell (Blockarchitektur) der AUTOSAR Adaptive Platform (AP).
• Technischer Zweck: Statische Dekomposition der AP-Laufzeitumgebung (ARA) in vier funktionale Cluster-Domänen mit vertikaler OS-Schnittstellenabstraktion und Abgrenzung gegenüber Applikationsebene (User Application) und Basisbetriebssystem (Base Software / POSIX OS).
• Systemische Einordnung: Definiert die logische Plattformarchitektur gemäß AUTOSAR R23-11 (AUTOSAR_EXP_PlatformDesign). Führt eine viergliedrige Cluster-Taxonomie ein (Platform Foundation FCs, Platform Service FCs, Standardized App/Interface FCs, Vehicle Service FCs) und entkoppelt das POSIX OS als eigenständige Base Software von der ARA.

2. Komponenten, Entitäten & Schnittstellen

• User Application:
  • Application: Generalisierte Applikationsschicht, die funktionale Softwarekomponenten und fahrzeugbezogene Benutzeranwendungen zusammenfasst.
• AUTOSAR Runtime for Adaptive applications - ARA:
  • Operating System Interface (vertikale Randschicht):
    • POSIX PSE51 / C++ STL Operating System Interface: Standardisierte Schnittstelle zu Threads, Speicher und Dateisystem, die allen Funktionsclustern innerhalb der ARA vertikal zur Verfügung steht.
  • Platform Foundation Functional Clusters (FCs) (blau kodiert, API-orientiert):
    • ara::com (Communication Management): Service-Oriented Communication (SOC).
    • ara::exec (Execution Management): Prozesslebenszyklus, Scheduling und Zustandswechsel.
    • ara::diag (Diagnostic Management): UDS- und DoIP-basierte Diagnoseverarbeitung.
    • ara::idsm (Intrusion Detection System Manager): Erfassung von Security-Events.
    • ara::nm (Network Management): Zustandsmanagement von Netzwerk-Clustern (in Foundation überführt).
    • ara::per (Persistency): Schlüssel-Wert- und dateibasierte Datenspeicherung.
    • ara::tsync (Time Synchronization): Hochpräzise Uhrensynchronisation (IEEE 802.1AS).
    • ara::crypto (Cryptography): Kryptografische Algorithmen und Schlüsselmanagement.
    • ara::rds (Raw Data Stream): Streaming unstrukturierter oder echtzeitkritischer Rohdaten (z. B. Sensor-/Videoströme).
    • ara::phm (Platform Health Management): Überwachung von Alive-, Deadline- und logischen Abläufen.
    • ara::log (Log and Trace): Systemweites DLT-Logging.
    • ara::fw (Firewall): Paket- und Kommunikationsfilterung auf Netzwerkebene.
    • ara::core (Core): Basistypen, Result/ErrorCode-Fehlerbehandlung und Speicherinitialisierung.
  • Platform Service FCs (grau kodiert, plattformlokale Dienste):
    • ara::ucm service (Update and Config Management): Softwarepaket- und Konfigurationsaktualisierung.
    • ara::sm service (State Management): Systemzustands- und Funktionsgruppensteuerung.
  • Standardized App/Interface FCs (orange kodiert, standardisierte Fachdomänen-Schnittstellen):
    • ara:adi::sensoritf service (Sensor Interfaces): Standardisierte Schnittstelle zur Anbindung von Sensoren und ADAS/Sensor-Frameworks.
  • Vehicle Service FCs (grün kodiert, fahrzeugweite Dienste):
    • ara::vucm service (Vehicle Update and Config Management): Flotten- und fahrzeugweites Update- und Konfigurationsmanagement über mehrere Knoten hinweg.
• Base Software:
  • POSIX OS: Unterlagertes POSIX-konformes Betriebssystem zur Bereitstellung von Prozessisolation und Hardwaretreibern.

3. Dynamisches Verhalten & Sequenzablauf

• Schichten- und domänenübergreifende Interaktion:
  • Applikationen greifen über zwei distinkte Pfade auf Plattformfunktionen zu:
    1. Direkte In-Process-Aufrufe über statisch/dynamisch gelinkte C++-APIs in die Platform Foundation FCs (ara::core, ara::per, ara::crypto, ara::rds etc.).
    2. Serviceorientierte Aufrufe über ara::com zur Nutzung von Diensten der Platform Service FCs (ara::sm, ara::ucm), der Standardized App/Interface FCs (ara:adi::sensoritf) sowie der Vehicle Service FCs (ara::vucm).
  • ara::rds ermöglicht direkte Datentransportpfade für kontinuierliche Sensordatenströme unter Umgehung des klassischen RPC/Event-Overheads von ara::com.
• Prozess- und Systemkopplung:
  • Der Zugriff auf OS-Primitive (Threads, Mutexes, POSIX-Sockets) erfolgt durch alle ARA-Cluster konsistent über die linksseitig visualisierte Abstraktionsschicht POSIX PSE51 / C++ STL.
  • POSIX OS bildet als Teil der Base Software die unterlagerte Ausführungsumgebung, getrennt von der logischen ARA-Definition.

4. Normative Relevanz & Entwickler-Hinweise

• Taxonomie & Standardisierungsgrenzen:
  • Die Aufteilung in vier Cluster-Familien definiert unterschiedliche Verantwortungsbereiche: Foundation (knotenlokale Basisbibliotheken), Platform Services (knotenlokale Systemdaemons), Standardized App/Interface (domänenspezifische Sensorabstraktionen) und Vehicle Services (netzwerkweite Gesamtfahrzeug-Dienste).
  • Durch die Einführung von ara::rds wird die strikte Beschränkung auf ara::com für Hochdurchsatz-Sensordaten gelockert.
  • Der Wegfall von ara::iam verdeutlicht die Konsolidierung von Authentifizierungs- und Autorisierungsmechanismen auf OS- und Core-Ebene.
• Integrationsrichtlinien:
  • Die vertikale Auslassungssymbolik (⋮) in allen vier Säulen kennzeichnet offene Erweiterungspunkte für künftige Funktionscluster.
  • Applikationen dürfen keine Annahmen über proprietäre POSIX-Erweiterungen treffen; die Portabilität stützt sich strikt auf das PSE51-Profil und C++ STL.