Figure 4.3: Safety features

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Schichtenmodell / Funktionsblock-Architekturdiagramm (Klassifikation: Functional Architecture Cluster Matrix) der AUTOSAR Adaptive Platform (ARA).
• Technischer Zweck & Einordnung: Das Diagramm aus AUTOSAR_AP_EXP_PlatformDesign (R23-11, Kap. 4) systematisiert die funktionalen Sicherheitsmechanismen (Safety Features, grün hinterlegt) gemäß ISO 26262 (bis ASIL D) innerhalb der adaptiven AUTOSAR-Laufzeitumgebung. Es verortet die Sicherheitsbausteine in den jeweiligen Functional Clusters (FCs) der Platform Foundation, der Platform Services sowie der horizontalen Betriebssystem-Abstraktion (POSIX PSE51 / C++ STL Interface) gegenüber dem unterlagerten POSIX OS und den übergeordneten User Applications.

2. Komponenten, Entitäten & Schnittstellen

Schichtenarchitektur (Top-Down):

1. User Application Layer:
   • Application: Ausführungsebene der adaptiven Applikationen (AAs), gekapselt in eigenen OS-Prozessen.
2. AUTOSAR Runtime for Adaptive Applications (ARA):
   • OS-Abstraktion (vertikale Flanke): POSIX PSE51 / C++ STL Operating System Interface – definiert die eingeschränkte, deterministische Schnittstelle zur Thread-, Memory- und Prozessverwaltung.
   • Platform Foundation Functional Clusters (FCs) (Bibliotheks- / Adressraum-getriebene Basiscluster):
     • Communication Management (ara::com): Enthält das Enabler-Feature Safe E2E Communication (End-to-End-Schutz für ereignis- und methodenbasierte Interprozess- und Inter-ECU-Kommunikation).
     • Execution Management (ara::exec): Realisiert "Authentic" boot, Resource Groups (Kryptografisch verifizierte Prozessstarts, Zuweisung von CPU-/Speicherbudgets via Resource Groups zur Wahrung von Freedom from Interference).
     • Persistency (ara::per): Bietet Safe Storage (Redundante, CRC-abgesicherte Ablage von Key-Value-Paaren und File-Streams gegen Flash-/FS-Korruption).
     • Time Synchronization (ara::tsync): Stellt Safe Time bereit (Synchronisation globaler Zeitbasen mit Integritäts- und Plausibilitätsprüfungen).
     • Platform Health Management (ara::phm): Realisiert Alive, Deadline, Logical Supervisions (Laufzeit- und Kontrollflussüberwachung von Programmsequenzen und Checkpoints).
     • Core (ara::core): Erzwingt Exception-less API design (Verzicht auf C++-Exceptions zugunsten von ara::core::Result<T, E> / ara::core::ErrorCode zur Laufzeit-Deterministik).
     • Weitere Foundation FCs (ohne expliziten Safety-Enabler-Tag): Diagnostic Management (ara::diag), Intrusion Detection System Manager (ara::idsm), Network Management (ara::nm), Cryptography (ara::crypto), Raw Data Stream (ara::rds), Log and Trace (ara::log), Firewall (ara::fw).
   • Platform Service FCs (Systemdienste als eigenständige Prozesse):
     • Update and Config Management (ara::ucm service): Bietet "Safe" update (Transaktionale, fehlertolerante A/B-Partitionierungs-Updates und Rollback-Mechanismen).
     • State Management (ara::sm service): Bietet Coordination of Degradation (Zentrale Koordination von Function-Group-Zuständen, Notlaufmodi und Übergang in den Safe State).
   • Standardized App/Interface FCs & Vehicle Service FCs:
     • Sensor Interfaces (ara::adi::sensoritf service): Standardisierte Schnittstellen für Sensordaten (z. B. ADAS/AD-Umfeld).
     • Vehicle Update and Config Management (ara::vucm service): Flotten- und Fahrzeug-weites Update-Management.
     • Automotive API Gateway (ara::aag): Fahrzeugweiter Dienst für standardisierte API-Gateways und externe Schnittstellenanbindungen.
3. Base Software Layer:
   • POSIX OS: Zertifiziertes Echtzeit-Betriebssystem (RTOS / Microkernel) mit Speicherschutz (MMU) und Prozessisolation.

3. Dynamisches Verhalten & Sequenzablauf

Obgleich als statische Clusterübersicht modelliert, bedingen die hervorgehobenen Sicherheits-Enabler eine gekoppelte Fehlererkennungs- und Reaktionskette:

1. Startphase (Authentic Boot & Partitionierung):
   • Das OS startet ara::exec. Dieses prüft die Authentizität der Binaries, weist Prozesse den im Execution Manifest deklarierten Resource Groups (CPU-Kerne, Cgroups, Scheduling-Policys SCHED_FIFO/SCHED_RR) zu und fährt Function Groups hoch.
2. Laufzeitüberwachung (Nominalbetrieb):
   • Applikationen senden Status-Checkpoints an ara::phm.
   • ara::phm evaluiert zyklisch:
     • Alive Supervision: Meldefrequenz innerhalb des Toleranzfensters?
     • Deadline Supervision: Einhaltung der maximalen Latenzen (WCET) zwischen zwei Checkpoints?
     • Logical Supervision: Gültigkeit der Übergänge im Kontrollflussgraphen?
   • Parallel sichert ara::com über E2E-Header (Counter, CRC) Daten gegen Übertragungs- und Pufferfehler ab.
3. Fehlereskalation & Degradation (Safety Reaction Loop):
   • Stellt ara::phm eine Verletzung fest, feuert es einen Health-Status an ara::sm (State Management).
   • ara::sm leitet asynchron die koordinierte Degradation ein (Coordination of Degradation): Herunterfahren nicht-kritischer Function Groups oder Umschaltung der Applikation in einen definierten Safe State / Notbetrieb.
4. Fehlertolerante Persistierung & Wartung:
   • Im Fehler- oder Shutdown-Pfad speichert ara::per Konfigurations- und Diagnosezustände fehlersicher (Safe Storage).
   • Softwareänderungen über ara::ucm erfolgen zweistufig (Staging → Verification → Activation); bei Validierungsfehlern erfolgt der automatische Fallback auf die vorherige funktionale Partition.

4. Normative Relevanz & Entwickler-Hinweise

• API-Design & Exception-Handling (ara::core):
  • Entwickler dürfen in ASIL-relevantem Adaptive-Code keine Standard-C++-Exceptions (throw, try-catch) nutzen (Konformität zu AUTOSAR C++14 Rule A15-0-1 / MISRA C++:2023).
  • Alle fehlgeschlagenen Operationen müssen über Monaden (ara::core::Result<ValueType, ErrorCode>) abgefragt und behandelt werden, um Stack-Unwinding-Latenzen zu eliminieren und WCET-Garantien zu erfüllen.
• Prozessisolation & Freedom from Interference (ara::exec):
  • Mixed-Criticality-Systeme (z. B. ASIL D neben QM) erfordern eine strikte Zuordnung zu Resource Groups im Manifest. Entwickler müssen Speicher-Limits (memoryMB) und CPU-Bandbreiten exakt budgetieren, um gegenseitiges Blockieren (Starvation) auszuschließen.
• Instrumentierungspflicht für PHM (ara::phm):
  • Sicherheitsrelevante Threads müssen explizit mit ara::phm::SupervisedEntity und ReportCheckpoint() instrumentiert werden.
  • Diskrepanzen zwischen Modell (Manifest-Konfiguration der Min/Max-Deadlines) und realer Thread-Ausführung führen zum sofortigen Eingriff durch das State Management.
• E2E-Absicherung (ara::com):
  • Die Datenintegrität auf Schnittstellenebene erfordert die Konfiguration von E2E-Protection-Profilen im ARXML-Servicedesign. Entwickler müssen den E2E-Status jedes empfangenen Samples vor der Weiterverarbeitung im Payload auswerten.
• Restriktion auf POSIX PSE51:
  • Direkte Systemaufrufe an das OS müssen auf das Single-Process-Multithread-Profil (PSE51) limitiert bleiben; fork(), exec() oder dynamisches Nachladen von Shared Libraries zur Laufzeit sind aus Safety-Gründen untersagt.