Figure 7.1: Executable Lifecycle from deployment to execution

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Informelles Architektur- und Lebenszyklusdiagramm (Konzept- und Datenflussmodell) mit Trennung von Offboard- (Design/Integration) und Onboard-Domäne (Machine/Runtime).
• Technischer Zweck: Spezifiziert die Transformation von AUTOSAR Adaptive Platform (AP) Software-Artefakten aus der Build- und Integrationsphase über die Paketierung (SoftwareCluster) und Installation (SW Configuration Management / UCM) bis hin zur OS-Prozessinstanziierung und Laufzeitüberwachung durch das Execution Management (EM).
• Systemeinordnung: Dokumentiert das Zusammenspiel zwischen statischer Modellierung (ARXML-Manifeste), dynamischer Dateisystem-Ablage und Prozessausführung gemäß AUTOSAR AP R17-10 bis R24-11 (SWS Execution Management).

2. Komponenten, Entitäten & Schnittstellen

Offboard (Design, Development, Integration)

• Machine Manifest: ARXML-Beschreibungsdatei für maschinenspezifische Ressourcen (Hardware-Layout, OS-Konfiguration, Network-Bindings, Prozessordefinitionen).
• SoftwareCluster: Standardisierte Auslieferungseinheit (Deployment Unit für Update/Installation), bestehend aus:
  • executable (binary): Kompiliertes Binary (typischerweise ELF).
  • Application Manifest: Modellierung von Prozessen, Startup-Konfigurationen (StartupConfig), Execution-Dependencies und Ressourcenlimits.
  • Service Instance Manifest: Deployment-spezifische Service-Zuordnungen (z. B. SOME/IP-, IPC-Bindings).

Onboard (Machine)

• SW Configuration Management (UCM / ara::ucm): Onboard-Komponente für Empfang, Kryptographie-/Signaturprüfung, Entpackung und persistente Installation des SoftwareClusters.
• installed executable: Im Dateisystem abgelegte, verifizierte Binärdatei.
• processed manifests / data base: Durch das UCM geparste, validierte und für das EM optimierte Laufzeit-Konfigurationsdatenbank.
• Execution Management (EM / Functional Cluster): Zentraler Lifecycle-Manager. Orchestriert OS-Parameter, steuert Start/Stop-Sequenzen anhand der aktiven Function Groups und Execution States.
• OS (Operating System): POSIX-konformes Betriebssystem (PSE51-Subset oder erweitert, z. B. Linux/QNX), zuständig für Speicherisolation, Scheduling und Thread-Verwaltung.
• process (loaded executable instance): Aktive Instanz eines Executables im virtuellen Adressraum des OS. Die gestapelte Darstellung verdeutlicht die 1:n-Multi-Instanziierbarkeit eines Binaries (Modelled Process).
• other functional clusters: Standardisierte AP-Plattformdienste (z. B. ara::com, ara::per, ara::diag, ara::crypto).

Schnittstellen (APIs)

• Execution Management API: ara::exec::ExecutionClient zur Zustandsrückmeldung durch den Prozess sowie Schnittstellen zur Zustandsverwaltung (State Management).
• OS API: Standardisierte POSIX-C- bzw. C++-Systemschnittstellen (POSIX PSE51, Threading, Signale).
• APIs of other functional clusters: AUTOSAR Runtime for Adaptive Applications (ARA) C++ Schnittstellen.

3. Dynamisches Verhalten & Sequenzablauf

1. Deployment & Installation: Der Offboard gebündelte SoftwareCluster wird an das SW Configuration Management übertragen. Dieses verifiziert Authentizität/Integrität, schreibt das installed executable in den Speicher und persistiert die extrahierten Manifeste in der data base.
2. Plattform-Initialisierung: Nach Machine-Boot liest das Execution Management die Manifeste aus der Datenbank und konfiguriert OS-spezifische Parameter (z. B. Resource Groups, CPU-Affinities, Scheduling-Policies).
3. Instanziierung (Startup): Abhängig von den Function Group States instanziiert das EM über das OS (mittels fork/exec bzw. OS-spezifischen Loadern) das installed executable als einen oder mehrere isolierte process-Instanzen.
4. Laufzeitsynchronisation:
   • Der gestartete Prozess durchläuft seine interne Initialisierung.
   • Der Prozess meldet seinen betriebsbereiten Zustand synchron via ara::exec::ExecutionClient::ReportExecutionState(ExecutionState::kRunning) an das EM.
   • Das EM überwacht das Erreichen dieses Zustands gegen das im Application Manifest definierte startupTimeout.
5. Normalbetrieb: Der Prozess interagiert autonom über die entsprechenden ARA-APIs mit weiteren Functional Clusters und nutzt OS-APIs für interne Thread-/Ressourcenverwaltung.
6. Termination: Bei Zustandswechseln oder Fehlern signalisiert das EM die Terminierung (POSIX-Signal, z. B. SIGTERM). Reagiert der Prozess nicht innerhalb der definierten terminationTimeout-Frist, forciert das EM über das OS die Terminierung (SIGKILL).

4. Normative Relevanz & Entwickler-Hinweise

• Deterministisches State Reporting: Jeder als Modelled Process definierte Prozess muss zwingend ReportExecutionState(kRunning) absetzen. Bleibt dieser Aufruf aus oder überschreitet die Startup-Dauer das im Manifest konfigurierte Timeout, greift der Recovery-Mechanismus des EM (Prozessabbruch / Safe State).
• Multi-Instantiation & Reentrancy: Ein Executable kann über separate Application Manifests mehrfach als eigenständiger Prozess instanziiert werden. Entwickler dürfen keine statischen, globalen Ressourcen (z. B. feste Socket-Pfade, hardcodierte POSIX Shared Memory IDs oder statische Dateipfade) verwenden; alle Instanzressourcen müssen über das Manifest oder Port-Mapping parametriert werden.
• Self-Contained Threading: Das EM startet ausschließlich den Primärprozess (main()). Die Erzeugung weiterer Threads, deren Scheduling-Attribute und Überwachung liegen innerhalb des Prozesses über OS-APIs bzw. AUTOSAR OS-Wrapper.
• Prozess-Isolation: Prozesse besitzen keinen direkten Speicherzugriff untereinander; Interprozesskommunikation (IPC) darf architektonisch ausschließlich über ara::com oder dedizierte Functional Clusters erfolgen.