Figure 7.20: 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.
  • Os: Operating System – AUTOSAR-OS-Laufzeitumgebung.
  • 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(): Std_ReturnType: Initialer Scheduler-Startaufruf vor der BswM-Initialisierung mit explizit typisiertem Rückgabewert Std_ReturnType.
  • 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 Os, 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 → Os): 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 Sequenz ist normativ. SchM_Start() erfolgt vor BswM_Init. SchM_Init(...) und SchM_StartTiming(...) folgen nach der BswM-Schleife.
• Rückgabewert & Fehlerbehandlung: SchM_Start() liefert explizit den Rückgabetyp Std_ReturnType, dessen Status (z. B. E_OK) von EcuM zur Fehlerüberprüfung vor den nachfolgenden Schritten ausgewertet werden kann.
• Konfigurationsverknüpfung: SchM_Init und 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.