Figure 11.1: Scenario: Start Adaptive Platform with Supervision of Adaptive Applications

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML 2.x Sequenzdiagramm (Interaktionsdiagramm) mit kombinierten Fragmenten (opt, loop, ref).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Release R23-11; Spezifikationsdokument AUTOSAR_AP_EXP_SWArchitecture (Doc ID 982), Kapitel 11 (Start Adaptive Platform with Supervision of Adaptive Applications).
• Technischer Zweck: Spezifikation der standardisierten Boot- und Initialisierungssequenz der Adaptive Platform. Das Diagramm modelliert die kausale Kette vom Kernel-Start des POSIX-Betriebssystems über den Hochlauf der zentralen Functional Cluster (Execution Management, State Management, Platform Health Management) und hardwarenaher Watchdog-Pfade bis hin zur Prozessinstanziierung und Überwachung einer Adaptive Application im Machine Function Group State Startup.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Lifelines

• :Operating System (OS): POSIX-konformes Betriebssystem/Kernel; steuert Low-Level-Treiber, Prozessinstanziierung (fork/exec bzw. posix_spawn) und Thread-Scheduling.
• «aapFunctionalCluster» :Execution Management (EM): Zuständig für Deployment- und Lifecycle-Management von Prozessen, Startreihenfolgen und Zustandsüberwachung der Function Groups.
• :WatchdogInterface: Treiber- bzw. Hardwareabstraktion des System-Watchdogs zur Plattformüberwachung.
• «aapFunctionalCluster» :State Management (SM): Regelbasierte Kontrollinstanz für System-, Machine- und Function-Group-Zustände; initiiert Transitionen bei EM.
• «aapFunctionalCluster» :Platform Health Management (PHM): Instanz für Alive-, Deadline- und Logical-Supervision von Applikationen sowie Auslöser von Recovery-Aktionen.
• :Adaptive Application (AA): Betriebssystemprozess einer konkreten Adaptive Application, zugeordnet zum Function Group State Startup.
• «aapFunctionalCluster» :Core: Basiscluster (ara::core), stellt fundamentale Datentypen, Fehlerbehandlungsmechanismen (ara::core::Result, ara::core::ErrorCode) und Initialisierungsroutinen bereit.

Schnittstellen & Interaktionssignaturen

• OS-Level (mit Stereotyp «aapInformative»):
  • enable(): Scharfschalten des Hardware-Watchdogs durch das Betriebssystem (ohne Stereotyp).
  • «aapInformative» exec(): POSIX-Aufruf zur Instanziierung von Cluster-/Applikations-Binaries.
  • «aapInformative» main(): Eintrittspunkt der C++-Laufzeitumgebung des jeweiligen Prozesses.
• Execution Management Interface (ara::exec):
  • SetState(Startup): Interne Zustandsaktivierung der Machine Function Group auf den State Startup.
  • ReportExecutionState(kRunning): Zustandsmeldung des Prozesses an den ara::exec::ExecutionClient zur Bestätigung der abgeschlossenen Initialisierung (ohne Rückgabetyp-Annotation : Result).
  • GetInitialMachineStateTransitionResult(): Abfrage von SM an EM zur Evaluierung des Transitionsstatus der Machine Function Group in den Zielzustand.
• Platform Health Management Interface (ara::phm):
  • AliveNotification(): Zyklisches Triggern des Watchdogs durch PHM zur Quittierung der Plattformgesundheit.
  • Offer(): Service-Offering der PHM-Schnittstellen (via ARA-Kommunikationsinfrastruktur).
  • «aapInformative» performSupervision(): Interne Berechnungs- und Evaluierungsroutine der Überwachungsregeln in PHM (als informativ gekennzeichnet).
  • ReportCheckpoint(): Übermittlung definierter Checkpoint-IDs durch die Adaptive Application (ara::phm::SupervisedEntity::ReportCheckpoint()).
• Core API:
  • Initialize(): Aufruf von ara::core::Initialize() zum Bootstrapping der internen AP-Ressourcen des Prozesses.
• Referenz:
  • ref Change Function Group State (Running): Folgesequenz für den Übergang der Function Group vom Zustand Startup in Running.

3. Dynamisches Verhalten & Sequenzablauf

1. Bootstrap & Watchdog-Aktivierung:
   • Das :Operating System schließt seine herstellerspezifische Initialisierung ab und aktiviert via enable() das :WatchdogInterface.
   • Das OS erzeugt die Prozessinstanz von Execution Management und übergibt die Kontrolle an main().
2. Transition Machine State Startup & Hochlauf State Management:
   • EM führt den internen Methodenaufruf SetState(Startup) aus.
   • EM fordert das OS via exec() an, den Functional Cluster State Management zu spawnen.
   • Das OS ruft main() von SM auf.
   • Nach interner Initialisierung quittiert SM seine Betriebsbereitschaft deterministisch an EM via ReportExecutionState(kRunning): Result.
3. Optionales Fragment opt – Plattform-Überwachung (PHM):
   • EM veranlasst das OS via exec() zum Start von Platform Health Management.
   • OS ruft main() von PHM auf.
   • PHM setzt unmittelbar eine erste AliveNotification() an :WatchdogInterface ab, um einen Watchdog-Reset während der Hochlaufphase zu verhindern.
   • PHM meldet ReportExecutionState(kRunning): Result an EM.
   • PHM deklariert seine Dienstbereitschaft über Offer() gegenüber SM bzw. dem Gesamtsystem.
   • Sub-Fragment loop Supervision Loop: PHM tritt in eine endlose Überwachungsschleife ein:
     • Zyklische Ausführung von performSupervision().
     • Zyklische Aktualisierung des Watchdogs via AliveNotification().
4. Optionales Fragment opt – Adaptive Application Lifecycle & Supervision:
   • EM veranlasst das OS via exec(), die im Startup-Manifest deklarierte :Adaptive Application zu starten.
   • OS ruft main() der AA auf.
   • AA führt vor allen weiteren Operationen Initialize() gegen «aapFunctionalCluster» :Core aus (ara::core::Initialize()).
   • AA meldet nach erfolgreicher Initialisierung ReportExecutionState(kRunning): Result an EM.
   • AA sendet Checkpoint-Ereignisse via ReportCheckpoint() an PHM zur Laufzeitüberwachung.
5. Konsolidierung & Transition nach Running:
   • State Management synchronisiert sich mit EM über GetInitialMachineStateTransitionResult(), um zu verifizieren, dass alle für den State Startup konfigurierten Prozesse erfolgreich kRunning gemeldet haben.
   • Ist das Resultat positiv, initiiert SM die Sequenz Change Function Group State (Running) zur Aktivierung der regulären Betriebsfunktionen.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag ara::core::Initialize(): Jeder Prozess (FC und AA) muss zwingend ara::core::Initialize() zu Beginn von main() aufrufen, bevor eine andere ARA-API instanziiert oder genutzt wird.
• Execution State Reporting (kRunning):
  • Der Aufruf ara::exec::ExecutionClient::ReportExecutionState(ExecutionState::kRunning) ist strikt normativ.
  • Unterbleibt dieser Aufruf oder überschreitet die Ausführungszeit das im Execution Manifest konfigurierte Startup-Timeout (startupConfig.startupTimeout), deklariert EM die State-Transition als fehlgeschlagen und löst die konfigurierte Recovery Action aus.
• Watchdog-Timing-Kette: Das Zeitfenster zwischen enable() durch das OS und der ersten AliveNotification() durch PHM definiert die maximale Boot-Latenz. Treiber- und Stack-Entwickler müssen sicherstellen, dass die Hardware-Watchdog-Periode lang genug dimensioniert ist, um die Prozessstarts von EM und PHM ohne Auslösung zu überbrücken.
• Reihenfolge PHM-Offer vs. AA-Reporting: Applikationen dürfen ReportCheckpoint() erst aufrufen, wenn die IPC-/Service-Bindung zu PHM aktiv ist. Andernfalls schlägt der Checkpoint-Aufruf fehl oder wird verworfen.
• Restriktionen im Function Group State Startup: Applikationen, die im Startup-State laufen, müssen auf ein Minimum an Abhängigkeiten beschränkt sein (z. B. keine externen Netzwerkschnittstellen via ara::com, solange der Communication Cluster noch nicht im State Running aktiv ist).