Figure 10.1: Startup of the AUTOSAR Runtime for Adaptive Applications

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.0 Sequenzdiagramm (Interaktionsdiagramm) mit kombinierten Fragmenten (ref für Sub-Szenarien, verschachtelte loop-Operatoren für Iterationen).
• Technischer Zweck: Spezifikation des sequenziellen Bootstrapping- und Aktivierungsablaufs der AUTOSAR Adaptive Platform (ARA – AUTOSAR Runtime for Adaptive Applications).
• Architektur-Kontext: Das Diagramm bildet den Phasenübergang vom POSIX-Betriebssystem-Kernel (Machine Boot) über die Foundation Functional Clusters (Execution Management EM, Platform Health Management PHM, State Management SM) bis hin zur geregelten Funktionsgruppen- und Applikationsinitialisierung (ara::core::Initialize()) ab.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Lebenslinien

• :Operating System: POSIX-konformes Betriebssystem (Prozessverwaltung, Kernel-/Init-Ebene, Prozess-Spawn via StartProcess()).
• EM: Execution Management (ara::exec): Zentraler Lifecycle-Manager; instanziiert Prozesse gemäß Execution Manifest, überwacht Ausführungszustände (ExecutionState) und führt Zustandswechsel von Funktionsgruppen aus.
• PHM: Platform Health Monitor (ara::phm): Sicherheitsrelevanter Funktionscluster für Alive-, Deadline- und Logical-Supervision; kontrolliert den Watchdog.
• :Watchdog Driver: Hardware-nahe Treiberschicht / Watchdog-Entity (zur Absicherung gegen System-Hang/Deadlocks).
• SM: State Management (ara::sm): Zustandsentscheidungsinstanz für Plattform- und Maschinenmodi; steuert Funktionsgruppen über das EM.
• :Core (ara::core): Basislaufzeitbibliothek der Adaptive Platform (Bereitstellung von Basistypen wie Result, Future sowie Initialisierungsroutinen).
• app: Adaptive Application: Betriebssystemprozess einer nutzer- oder plattformspezifischen Applikation, instanziiert im User Space.

Schnittstellen & Interaktionsprimitive

• StartProcess(): Schnittstelle zwischen EM und OS (POSIX fork/exec bzw. posix_spawn).
• ReportExecutionState(state): IPC-API (ara::exec::ExecutionClient), typisiert mit Rückgabewert ara::core::Result<void>.
• Enable(): Treiber-Aktivierungsaufruf des PHM an den Watchdog Driver.
• SetState(FunctionGroupState): Asynchroner Funktionsaufruf von SM an EM zur Anforderung eines Funktionsgruppen-Zustandswechsels; liefert ara::core::Future<void>.
• Initialize(): Prozesslokaler synchroner Initialisierungsaufruf (ara::core::Initialize()).
• GetProcessStates() / GetFunctionGroupStates(): Abfrage-APIs von SM an EM zur Verifikation der Zielzustände.

3. Dynamisches Verhalten & Sequenzablauf

1. Phase 1: Bootstrapping des Execution Managements (EM)
   • Das OS startet als ersten User-Space-Prozess das EM: Execution Management.
   • Architektur-Hinweis (TBC): Es besteht zu diesem Zeitpunkt eine funktionale Sicherheitslücke (Watchdog Gap), da die Watchdog-Überwachung erst nachgelagert aktiviert wird.
2. Phase 2: Initialisierung der Überwachungsinfrastruktur (PHM)
   • EM beauftragt das OS via StartProcess() mit dem Start des PHM: Platform Health Monitor.
   • PHM meldet ReportExecutionState(running) an das EM zurück.
   • PHM schärft die Sicherheitsüberwachung über :Watchdog Driver.Enable().
   • Entwurfsnotiz: EM selbst muss nachträglich über ein ProcessChanged-Event in die PHM-Supervision eingebunden werden.
3. Phase 3: Instanziierung des State Managements (SM)
   • EM fordert via StartProcess() den Start von SM: State Management an.
   • SM bestätigt seine Betriebsbereitschaft per ReportExecutionState(running).
4. Phase 4: Machine State Übergang („Startup“)
   • Ausführung der Referenzsequenz ref: Function Group State Transition(Startup).
   • Aktiviert den Zustand "Startup" der Machine State-Funktionsgruppe und startet die verbleibenden Plattform-Cluster.
5. Phase 5: Gestaffelter Applikations-Startup (Iterative Abarbeitung)
   • Outer Loop (loop all Function Groups):
     • SM fordert via SetState(FunctionGroupState) asynchron (Future) den Zustandswechsel einer Funktionsgruppe beim EM an.
   • Inner Loop (loop all Processes):
     • EM iteriert über alle Prozesse, die für diesen Zustand im Execution Manifest konfiguriert sind, und stößt StartProcess() am OS an.
     • Der Prozess app: Adaptive Application startet und führt zwingend als ersten Schritt synchron Initialize() an :Core aus.
     • Nach erfolgreicher Basisinitialisierung meldet der Prozess ReportExecutionState(running) an EM.
     • SM synchronisiert den Status fortlaufend über GetProcessStates().
   • Nach Durchlauf aller Prozesse validiert SM den Gesamtzustand der Gruppe via GetFunctionGroupStates().

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag für Applikations-Entwickler (main()-Lifecycle):
  • Vor jedem Zugriff auf funktionale Cluster (ara::com, ara::log, ara::diag etc.) muss zwingend ara::core::Initialize() aufgerufen werden. Vor Verlassen von main() ist korrespondierend ara::core::Deinitialize() erforderlich.
  • Unmittelbar nach der Initialisierung muss die Applikation über eine Instanz von ara::exec::ExecutionClient zwingend ReportExecutionState(ExecutionState::kRunning) absetzen.
  • Erfolgt dieser Aufruf nicht innerhalb des im Execution Manifest definierten Startup-Timeouts, deklariert das EM den Prozess als fehlerhaft und leitet die konfigurierte Recovery-Aktion (z. B. Prozess-Restart oder Transition in einen Safe State) ein.
• Asynchronitäts- und Concurrency-Handling:
  • SM-Zustandsänderungen (SetState) sind nicht-blockierend ausgelegt (ara::core::Future). Applikations- und Stack-Entwickler dürfen keine blockierenden Synchronisationen auf dem Main-Thread ausführen, sondern müssen Statusprüfungen asynchron handhaben.
• Safety & Timing (ISO 26262 Relevanz):
  • Die im Schaubild dokumentierte Lücke (Watchdog Gap) zwischen OS-/EM-Start und PHM.Enable() erfordert auf Systemebene (Safety Case) zwingend Kompensationsmaßnahmen: z. B. einen Hardware-Boot-Watchdog mit großzügigem Timeout im Bootloader oder eine Initialüberwachung durch einen Classic-AUTOSAR-Safety-Controller.
• Manifest-Konfiguration:
  • Die Startreihenfolge der Prozesse und deren Zuordnung zu Funktionsgruppen sind statisch im Execution Manifest (StartupConfig, ProcessExecutionScope, FunctionGroup) festgelegt. Laufzeit-Prozessstarts abseits dieser Konfiguration sind im Standard-AP-Paradigma unzulässig.