Figure 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.
  • 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.
• Schnittstellen & Parameter:
  • GetCoreID(CoreIdType): OS-Systemaufruf zur Identifikation des physischen Ausführungskerns. Rückgabe/Typ: CoreIdType.
  • SchM_Init(void): Initialisierungsfunktion des BSW-Schedulers (keine Parameter).
  • BswM_Init(const BswM_ConfigType *): Initialisierungs-API des BswM. Übergabeparameter: typisierter Zeiger auf die BswM-Konfigurationsdatenstruktur (Post-Build/Link-Time-Deskriptor).
• Beziehungscharakter: Reine Punkt-zu-Punkt-Aufrufbeziehungen (Master-Client-Muster), ausgehend von der EcuM-Lebenslinie mit synchronem Kontrollfluss und explizitem Kontrollrückfluss (Return-Pfeile).

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(). Schafft die Grundvoraussetzung für Scheduler-Locking und zyklische BSW-Tasks.
3. Modus-Manager-Initialisierung (EcuM → BswM): Aufruf von BswM_Init(ConfigPtr). EcuM übergibt den Zeiger auf das modulspezifische Konfigurationsset (const BswM_ConfigType *).
4. Phasenabschluss: Mit Rückkehr von BswM_Init() endet die statische Initiierung durch EcuM. Die weitere Initialisierung nachgelagerter BSW-Module (z. B. Com-Stack, NvM, Dem/Det) sowie der RTE wird ab diesem Zeitpunkt dynamisch über BswM-Aktionslisten (Action Lists / Rules) 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, da BswM-Aktionen bereits auf SchM-Ressourcensperren zugreifen können.
• Konfigurationsverknüpfung: Der Konfigurationszeiger für BswM_Init muss aus dem EcuM-Konfigurationscontainer (EcuMConfiguration / EcuMConfigSet) konsistent an BswM_ConfigType übergeben werden.
• Multicore-Spezifikum: Diese Sequenz gilt ausschließlich für den Master-Core. Slave-Cores durchlaufen die Slave Core StartPostOS Sequence, bei der keine erneute Initialisierung des BswM stattfindet; die Synchronisation erfolgt dort über Multicore-Barrieren bzw. Inter-Core-Events.
• Ausführungskontext: Im Gegensatz zur Pre-OS-Phase (EcuM_Init()) laufen diese Aufrufe bei aktivierten OS-Mechanismen. Der ausführende Task muss über entsprechende Berechtigungen für OS- und BSW-Dienste verfügen.