Figure 21: Master Core StartPostOS Sequence

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck & Einordnung: Spezifikation des standardisierten Bootstrap-Ablaufs der AUTOSAR Classic Platform (Release R4.0.3) in der Phase StartPostOS auf dem Master Core (EcuM_StartupTwo()). Es definiert die minimale, zwingend synchrone Übergabesequenz vom Betriebssystemstart (StartOS()) über die Basisdienste (SchM) bis zur Aktivierung des regelbasierten Zustandsmanagements (BswM).

2. Komponenten, Entitäten & Schnittstellen

• Teilnehmer (Lifelines mit Stereotyp «module»):
  • EcuM: ECU State Manager – Hauptinitiator und sequenzieller Koordinator der Boot-Phasen.
  • McOs: Multicore Operating System – AUTOSAR-OS-Laufzeitumgebung mit Multicore-Unterstützung.
  • SchM: Basic Software Scheduler – Laufzeitinfrastruktur zur Verwaltung von BSW-Hauptfunktionen (<Mod>_MainFunction) und BSW-spezifischen Exklusivbereichen (SchM_Enter_*, SchM_Exit_*).
  • BswM: Basic Software Mode Manager – Regelbasierte Zustandsmaschine zur weiteren Orchestrierung von BSW- und RTE-Zuständen.
• Interaktionsrahmen:
  • loop: Kombiniertes Fragment mit Bedingung loop over every BswM running in this core, das die Initialisierung aller BswM-Instanzen auf dem aktuellen Kern kapselt.
• Schnittstellen & Parameter:
  • GetCoreID(CoreIdType): OS-Systemaufruf zur Identifikation des physischen Ausführungskerns. Rückgabe/Typ: CoreIdType.
  • SchM_Init(const SchM_ConfigType*): Initialisierungsfunktion des BSW-Schedulers mit typisiertem Zeiger auf die Konfigurationsstruktur (const SchM_ConfigType*).
  • BswM_Init(const BswM_ConfigType *): Initialisierungs-API des BswM mit typisiertem Zeiger auf die BswM-Konfigurationsdatenstruktur.
• Beziehungscharakter: Punkt-zu-Punkt-Aufrufe ausgehend von EcuM mit synchronem Kontrollfluss und explizitem Kontrollrückfluss (Return-Pfeile); BswM_Init wird innerhalb des Schleifenrahmens iterativ ausgeführt.

3. Dynamisches Verhalten & Sequenzablauf

Der Ablauf erfolgt im Kontext eines OS-Autostart-Tasks oder des OS-Startup-Hooks auf dem Master-Core:

1. Core-Validierung (EcuM → McOs): Aufruf von GetCoreID(...) zur Verifikation, dass der aufrufende Kontext tatsächlich auf dem designierten Master-Core ausgeführt wird.
2. Scheduler-Initialisierung (EcuM → SchM): Aufruf von SchM_Init(const SchM_ConfigType*). EcuM übergibt den Konfigurationszeiger an den BSW-Scheduler als Grundvoraussetzung für Scheduler-Locking und zyklische BSW-Tasks.
3. Modus-Manager-Initialisierung (EcuM → BswM): Im Schleifenfragment loop over every BswM running in this core ruft EcuM für jede auf diesem Kern laufende BswM-Instanz sequenziell BswM_Init(const BswM_ConfigType *) auf.
4. Phasenabschluss: Mit Rückkehr des letzten BswM_Init() endet die statische Initiierung durch EcuM. Die weitere Initialisierung nachgelagerter BSW-Module sowie der RTE wird ab diesem Zeitpunkt dynamisch über BswM-Aktionslisten gesteuert.

4. Normative Relevanz & Entwickler-Hinweise

• Strikte Aufrufreihenfolge: Die Sequenz ist normativ. SchM_Init(...) darf erst nach gesicherter Core-Identifikation aufgerufen werden. BswM_Init(...) setzt zwingend einen initialisierten Scheduler voraus.
• Konfigurationsbindung: Sowohl SchM_Init als auch BswM_Init erwarten explizit typisierte Konfigurationszeiger (const SchM_ConfigType* bzw. const BswM_ConfigType *), die konsistent aus der EcuM-Gesamtkonfiguration bereitgestellt werden müssen.
• Multi-BswM-Unterstützung: Durch das loop-Fragment wird normativ festgeschrieben, dass auf einem Core mehrere BswM-Instanzen existieren können und sequenziell initialisiert werden müssen.
• Multicore-Spezifikum: Diese Sequenz gilt ausschließlich für den Master-Core. Slave-Cores durchlaufen eine separate StartPostOS-Sequenz.