Figure 11.1: Scenario: Start Platform with Supervision of Applications

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.0 Sequenzdiagramm mit Interaktionsfragmenten (opt, loop, ref).
• Funktionaler Kontext: Bootstrapping und koordinierte Initialisierungsphase der AUTOSAR Adaptive Platform (Release R22-11) während des Maschinenstarts (MachineState/Function Group State Startup).
• Architektonischer Zweck: Darstellung der Abhängigkeiten und der Prozess-Start-Kaskade von OS, Execution Management (EM), State Management (SM), Platform Health Management (PHM) und regulären Adaptive Applications (AA) inklusive Watchdog-Aktivierung und lokaler/globaler Überwachung vor dem Übergang in den Zustand Running.

2. Komponenten, Entitäten & Schnittstellen

• :Operating System: POSIX-konformes Betriebssystem; startet Low-Level-Dienste, Treiber und stellt den Prozess-Spawning-Mechanismus bereit.
• «aapFunctionalCluster» :Execution Management (ara::exec): Zentraler Lifecycle-Manager; instanziiert Prozesse gemäß Ausführungsmanifesten (Execution Manifests) und verarbeitet Zustandstransitionen.
• :WatchdogInterface: Hardware-nahe Abstraktionsschicht / Treiber zur Ansteuerung des physischen Plattform- oder System-Watchdogs.
• «aapFunctionalCluster» :State Management (ara::sm): Bestimmt den Systemzustand, triggert Function Group State Transitions und wertet deren Resultate aus.
• «aapFunctionalCluster» :Platform Health Management (ara::phm): Überwacht das Laufzeitverhalten (Alive-, Deadline-, Logical Supervision) von Prozessen und bedient den Watchdog.
• :Adaptive Application: Nutzerprozess/Applikation, definiert innerhalb einer Function Group.
• «aapFunctionalCluster» :Core (ara::core): Basis-Laufzeitumgebung (ara::core::Initialize(), ara::core::Deinitialize()).
• Schnittstellen & Interaktionspunkte:
  • enable(): Watchdog-Scharfschaltung durch das OS.
  • exec() / main(): POSIX-Prozessinstanziierung (fork/exec*) und Einsprungpunkt.
  • ReportExecutionState(kRunning): Synchroner/asynchroner IPC-Aufruf via ara::exec::ExecutionClient zur Bestätigung der Betriebsbereitschaft.
  • Offer(): Service-Bereitstellung (IPC/Skeleton) bzw. Triggerung der Schnittstellenfreigabe zwischen SM und PHM.
  • performSupervision() / AliveNotification(): Zyklische Evaluierung der Überwachungsregeln und Watchdog-Triggern.
  • ReportCheckpoint(): Melden von Checkpoints durch die AA über den ara::phm::SupervisedEntity-Client.
  • GetInitialMachineStateTransitionResult(): Abfrage des Transitionsstatus der Machine Function Group durch das SM.

3. Dynamisches Verhalten & Sequenzablauf

1. System-Initialisierung & Watchdog-Aktivierung:
   • :Operating System schärft die externe Überwachung via enable() an :WatchdogInterface.
   • Das OS instanziiert den Prozess von :Execution Management und startet dessen Kontrollfluss über main().
2. EM-Bootstrap & State Management Start:
   • :Execution Management führt intern SetState(Startup) aus, um die Machine Function Group auf den Start-Zustand zu setzen.
   • EM fordert über das OS per exec() den Prozess von :State Management an; das OS ruft dessen main() auf.
   • SM meldet seine Einsatzbereitschaft via ReportExecutionState(kRunning): Result an EM zurück.
3. Fragment opt (Startup Platform Health Management):
   • EM triggert über das OS (exec() → main()) den Start von :Platform Health Management.
   • PHM setzt umgehend eine initiale AliveNotification() an :WatchdogInterface ab.
   • PHM quittiert seine Einsatzbereitschaft via ReportExecutionState(kRunning): Result an EM.
   • SM interagiert mit PHM (Offer()), um Kommunikationsbeziehungen bzw. Health-Services freizugeben.
   • Fragment loop Supervision Loop: PHM führt kontinuierlich/zyklisch performSupervision() aus und refresht den Watchdog über AliveNotification().
4. Fragment opt (Startup Adaptive Application):
   • EM startet die zugeordnete :Adaptive Application über das OS (exec() → main()).
   • Die Applikation initialisiert die Adaptive Core Runtime via Initialize() an :Core.
   • Die Applikation meldet ihre Bereitschaft an EM (ReportExecutionState(kRunning): Result).
   • Zur Laufzeitüberwachung sendet die Applikation periodisch oder ereignisbasiert ReportCheckpoint() an das PHM.
5. Zustandstransitions-Abschluss & Folgezustand:
   • SM fragt bei EM das Ergebnis der initialen Transition via GetInitialMachineStateTransitionResult() ab.
   • Interaktionsreferenz ref: Bei erfolgreichem Abschluss aller Transitionsbedingungen verzweigt das System in die Sequenz Change Function Group State (Running).

4. Normative Relevanz & Entwickler-Hinweise

• Execution Client API-Vertrag (ara::exec): Jede Adaptive Application (einschließlich Plattform-Cluster wie SM und PHM) muss zwingend nach Abschluss aller prozessinternen Initialisierungen ara::exec::ExecutionClient::ReportExecutionState(ara::exec::ExecutionState::kRunning) absetzen. Unterbleibt dieser Aufruf innerhalb des im Execution Manifest definierten Start-Timeouts (startupTimeout), wertet EM den Prozessstart als fehlgeschlagen und leitet Recovery-Maßnahmen (z. B. Restart, Safe State) ein.
• Initialisierungspflicht (ara::core): Applikationscode darf keine funktionale AUTOSAR-API (z. B. ara::com, ara::phm) vor dem erfolgreichen Rücksprung von ara::core::Initialize() aufrufen; Ressourcenfreigabe muss vor Prozessende via ara::core::Deinitialize() erfolgen.
• PHM-Anbindung & Checkpoint Reporting: Wird ein Prozess im Manifest als überwachter Prozess (SupervisedEntity) deklariert, muss dieser innerhalb deterministischer Zeitschranken ReportCheckpoint() melden. Verspätete oder fehlende Meldungen führen in PHM zu Alive-, Deadline- oder Logical-Supervision-Fehlern, wodurch PHM die AliveNotification() an das :WatchdogInterface aussetzt oder Recovery-Aktionen via SM triggert.
• Timing-Restriktionen beim Bootstrapping: Die Kette aus enable() → PHM-Start → erste AliveNotification() muss zwingend unterhalb der Hardware-Watchdog-Timeout-Periode abgeschlossen sein, um Watchdog-Resets während der Systeminitialisierung auszuschließen.