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 und Exklusivbereichen.
  • 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 um den Aufruf von BswM_Init.
• Schnittstellen & Parameter:
  • GetCoreID(CoreIdType): OS-Systemaufruf zur Identifikation des physischen Ausführungskerns. Rückgabe/Typ: CoreIdType.
  • SchM_Start(): Initialer Scheduler-Startaufruf (parameterlos), ausgeführt vor der BswM-Initialisierung.
  • BswM_Init(const BswM_ConfigType *): Initialisierungs-API des BswM innerhalb der Schleife mit typisiertem Konfigurationszeiger.
  • SchM_Init(const SchM_ConfigType*): Scheduler-Initialisierung (nachgelagert nach der BswM-Schleife) mit typisiertem Zeiger const SchM_ConfigType*.
  • SchM_StartTiming(const SchM_ConfigType*): Aktivierungsfunktion für das SchM-Timing mit typisiertem Konfigurationszeiger const SchM_ConfigType*.
• Beziehungscharakter: Synchrone Punkt-zu-Punkt-Aufrufe von EcuM an McOs, SchM und BswM mit expliziten Return-Pfeilen; BswM_Init gekapselt im Schleifenrahmen.

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(CoreIdType) zur Verifikation des Master-Cores.
2. Scheduler-Start (EcuM → SchM): Aufruf von SchM_Start() zur Aktivierung grundlegender Scheduler-Funktionen vor der BswM-Initialisierung.
3. Modus-Manager-Initialisierung (EcuM → BswM): Schleife über alle BswM-Instanzen auf dem Kern (loop over every BswM running in this core): Aufruf von BswM_Init(const BswM_ConfigType *).
4. Scheduler-Initialisierung (EcuM → SchM): Aufruf von SchM_Init(const SchM_ConfigType*) nach Abschluss der BswM-Initialisierung.
5. Scheduler-Timing-Start (EcuM → SchM): Aufruf von SchM_StartTiming(const SchM_ConfigType*) zur Aktivierung der zeitgesteuerten Task- und Event-Mechanismen des Schedulers.
6. Phasenabschluss: Mit Rückkehr von SchM_StartTiming() endet die StartPostOS-Initialisierungssequenz des Master-Cores.

4. Normative Relevanz & Entwickler-Hinweise

• Strikte Aufrufreihenfolge: Die geänderte Sequenz ist normativ. SchM_Start() erfolgt vor BswM_Init. Die eigentliche Scheduler-Initialisierung SchM_Init(...) sowie SchM_StartTiming(...) dürfen erst nach der vollständigen Initialisierung aller BswM-Instanzen des Cores aufgerufen werden.
• Mehrstufiger Scheduler-Bootstrap: Die SchM-Inbetriebnahme ist dreistufig gegliedert in Start (SchM_Start), Konfigurationsinitialisierung (SchM_Init) und Timing-Aktivierung (SchM_StartTiming).
• Konfigurationsverknüpfung: Sowohl SchM_Init als auch SchM_StartTiming erhalten dieselbe Konfigurationsstruktur (const SchM_ConfigType*), während SchM_Start() parameterlos aufgerufen wird.
• Multicore-Spezifikum: Gilt ausschließlich für den Master-Core; die BswM-Initialisierung verbleibt in der kernspezifischen Iterationsschleife.