Figure 7.6: AUTOSAR Adaptive Platform Boundary

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Informelles Systemgrenzen- und Prozessabstammungsdiagramm (System Boundary & Architectural Deployment Model).
• Technischer Zweck & funktionale Einordnung:
  • Spezifiziert die System- und Laufzeitgrenzen einer AUTOSAR Adaptive Instance auf einer logischen oder physischen Ausführungseinheit (A Machine) innerhalb der AUTOSAR Adaptive Platform (AP).
  • Definiert die Prozesshierarchie ausgehend vom POSIX-Kernel über den OS-Root-Init-Prozess bis hin zum Execution Management (EM, ara::exec) und den durch EM verwalteten Prozessen.
  • Verdeutlicht die Koexistenz von AUTOSAR-konformen Prozessen (Plattformdienste und Adaptive Applications) mit nativen, nicht durch AUTOSAR verwalteten Standard-POSIX-Prozessen auf derselben OS-Instanz.
  • Zeigt die Schichtung über Hardware (H/W) und optionaler Virtualisierungsebene (HyperVisor).

2. Komponenten, Entitäten & Schnittstellen

• H/W & HyperVisor:
  • Basis-Hardware und optionale Typ-1/Typ-2-Virtualisierungsschicht zur Partitionierung von Hardware-Ressourcen.
• A Machine & OS:
  • Virtuelle oder physische Recheneinheit mit einem POSIX-kompatiblen Betriebssystem (mindestens PSE51/PSE52 Realtime-POSIX-Subset).
• Init Process (PID 1):
  • Erste Userspace-Entität (z. B. systemd, SysV-Init oder proprietärer Microkernel-Init-Task). Startet plattformfremde OS-Prozesse sowie exklusiv das Execution Management.
• Process (nativ, außerhalb Adaptive Platform):
  • Plattformfremde Betriebssystem-Prozesse/Daemons, die direkt vom OS-Init verwaltet werden und außerhalb des deterministischen State- und Lifecycle-Managements von AUTOSAR liegen.
• AUTOSAR Adaptive Instance (Dashed Outer Boundary):
  • Begrenzung der logischen Instanz der Adaptive Platform auf der Machine, bestehend aus Plattformkern und gemanagten Applikationsprozessen.
  • AUTOSAR Adaptive Platform (Dashed Inner Boundary):
    • Execution Management (ara::exec): Zentraler Laufzeit-Orchestrator. Verwaltet den Lebenszyklus (Start, Überwachung, Beendigung) aller Applikationen und Funktionscluster basierend auf Machine- und Execution-Manifesten.
    • Adaptive Foundation and services: Funktionscluster der Plattform (z. B. Communication Management ara::com, Diagnostic Management ara::diag, Persistency ara::per, State Management ara::sm). Werden direkt von EM gestartet und überwacht.
  • Reporting Process:
    • Adaptive Application (AA), die gegen ara::exec gelinkt ist und die Laufzeitschnittstelle ara::exec::ExecutionClient aktiv bedient.
  • Non-Reporting Process:
    • Prozess unter Kontrolle des EM (z. B. Legacy-Code, 3rd-Party-Binaries oder spezialisierte Daemons), der keine Interaktion mit dem ExecutionClient durchführt.

3. Dynamisches Verhalten & Sequenzablauf

1. System-Bootstrapping:
   • Kernel initiiert den Userspace und startet den Init Process (PID 1).
   • Init Process erzeugt native OS-Dienste (Process) und fork/executiert das Execution Management.
2. Plattform-Initialisierung:
   • EM liest das Machine Manifest und das Execution Manifest ein.
   • EM startet die internen Plattform-Services (Adaptive Foundation and services) sowie definierte Core-Prozesse der initialen Function Group States (z. B. MachineState: Startup).
3. Applikations-Start & State Reporting:
   • Reporting Process: Nach dem OS-Prozessstart initialisiert die Applikation ihre Laufzeitumgebung und setzt über IPC den synchronen/asynchronen API-Aufruf ara::exec::ExecutionClient::ReportExecutionState(ExecutionState::kRunning) ab. EM quittiert dies und überwacht das Eintreffen innerhalb des im Manifest konfigurierten startupTimeout.
   • Non-Reporting Process: EM führt fork/exec aus; der Prozess gilt unmittelbar nach erfolgreicher OS-Rückmeldung als aktiv. Es erfolgt kein interner State-Handshake auf Applikationsebene.
4. Lifecycle-Überwachung & Beendigung:
   • Kontinuierliches Monitoring durch EM via POSIX-Signal-Mechanismen (SIGCHLD, waitpid) sowie optional über den Platform Health Management Cluster (ara::phm).
   • Geordneter Shutdown über SIGTERM (Reporting Processes können kTerminating melden) mit Fallback auf SIGKILL bei Überschreitung des terminationTimeout.

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Konfiguration (Process.reportingBehavior):
  • Für jeden im Modell deklarierten Prozess (ProcessToMachineMappingInstance) muss das Attribut reportingBehavior exakt festgelegt werden (reportsExecutionState vs. doesNotReportExecutionState).
  • Fehlerfalle: Ist ein Prozess fälschlicherweise als reportsExecutionState modelliert, ruft aber ReportExecutionState(kRunning) nicht vor Ablauf von startupTimeout auf, stuft EM den Prozessstart als fehlgeschlagen ein und erzwingt den konfigurierten Recovery-Pfad (z. B. Kill & Restart oder Transition in Safe State).
• Entwickler-Pflichten für Adaptive Applications:
  • Jede reguläre Adaptive Application muss den ExecutionClient instanziieren, sobald alle statischen Ressourcen (Memory, OS-Ressourcen, ara::com-Proxies/Skelette) allokiert sind, und zwingend kRunning melden.
• Ressourcen- und Privilegien-Isolation:
  • Native Prozesse unterliegen nicht der Scheduling-, cgroup- und IAM-Kontrolle (Identity and Access Management) des Execution Managements; Inter-Process Communication (IPC) zwischen nativen Prozessen und der Adaptive Platform muss restriktiv über OS-Zugriffsrechte (z. B. POSIX Capabilities, SELinux/AppArmor-Profile) abgesichert werden.