Figure 7.2: 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 (Software Package) und Installation (Update and 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 R18-03 (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).
• Software Package: Standardisierte Auslieferungseinheit (Deployment Unit für Update/Installation), bestehend aus:
  • executable (binary): Kompiliertes Binary (typischerweise ELF).
  • Execution Manifest: Modellierung von Prozessen, Startup-Konfigurationen (StartupConfig), Execution-Dependencies und Ressourcenlimits (ersetzt den Begriff Application Manifest).
  • Service Instance Manifest: Deployment-spezifische Service-Zuordnungen (z. B. SOME/IP-, IPC-Bindings).

Onboard (Machine)

• Update and Configuration Management (UCM): Onboard-Komponente für Empfang, Kryptographie-/Signaturprüfung, Entpackung und persistente Installation des Software Packages.
• 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: Das Offboard gebündelte Software Package wird an das Update and 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 aufbereiteten Konfigurationsdaten (processed manifests aus der data base), um Abhängigkeiten, Ressourcenlimits und Startreihenfolgen zu ermitteln.
3. Prozessinstanziierung: Anhand der Konfiguration und der aktiven Function Groups/States weist das Execution Management das OS an, die Binärdateien (installed executable) in den Arbeitsspeicher zu laden und als Prozesse (process (loaded executable instance)) auszuführen.
4. Laufzeit-Interaktion: Nach dem Start meldet der Prozess seinen Ausführungsstatus über die Execution Management API (ara::exec::ExecutionClient) an das Execution Management. Die Kommunikation mit anderen Plattformdiensten und dem Betriebssystem erfolgt über die jeweiligen API-Schnittstellen (OS API, APIs of other functional clusters).

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.