Figure 5: StartPreOS Sequence

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML 2.x Sequenzdiagramm (Interaktionsdiagramm mit kombiniertem opt-Fragment).
• Technischer Zweck & Einordnung: Spezifikation der normativen Phase STARTUP I (StartPreOS-Sequenz) des BSW-Moduls EcuM (ECU State Manager, AUTOSAR Classic R4.0.3). Das Diagramm definiert den deterministischen Bring-up-Ablauf von der Bare-Metal-Initialisierung (EcuM_Init) über die Post-Build-Konfigurationsvalidierung und Reset-Auswertung bis zur Übergabe der CPU-Kontrolle an das AUTOSAR OS via StartOS.

2. Komponenten, Entitäten & Schnittstellen

• Lebenslinien / Akteure:
  • «module» EcuM: Zentrales BSW-Zustandssteuerungsmodul der System Services; orchestriert die Pre-OS-Initialisierung.
  • Integration Code: OEM-/Plattform-spezifische Integrationsschicht (Callouts und BSW-Konfigurationscode außerhalb des generischen Moduls).
  • «module» Mcu: MCAL-Treiber (Microcontroller Unit Driver) zur Hardwarediagnose und Takt-/Reset-Abfrage.
  • «module» Os: AUTOSAR Operating System.
• Schnittstellen & Callouts:
  • EcuM_AL_DriverInitZero(): Callout zur Ausführung von Init Block 0 (Pre-Compile-Treiber ohne Konfigurationszeiger).
  • EcuM_DeterminePbConfiguration(EcuM_ConfigType*): Integrationsfunktion zur Lokalisierung/Bereitstellung der Post-Build-Konfigurationswurzel im Speicher.
  • EcuM_ErrorHook(uint16 reason): Kritischer Callout bei fatalen Konfigurationsfehlern (ECUM_E_CONFIGURATION_DATA_INCONSISTENT).
  • EcuM_AL_DriverInitOne(const EcuM_ConfigType*): Callout zur Ausführung von Init Block I (Post-Build-abhängige MCAL-/BSW-Treiber vor OS-Start).
  • Mcu_GetResetReason(): MCAL-API zur Abfrage des Hardware-Reset-Statusregisters; liefert Mcu_ResetType.
  • EcuM_SelectShutdownTarget(EcuM_TargetType, EcuM_ModeType) (bzw. Std_ReturnType EcuM_SelectShutdownTarget(EcuM_StateType, uint8)): Interne/Standard-Schnittstelle zur Festlegung des Default-Shutdown-Ziels.
  • StartOS(AppModeType): OSEK/AUTOSAR-OS-API zum Hochfahren des Schedulers mit DEFAULT_APP_MODE.
• Datenstrukturen & Literale:
  • EcuM_ConfigType: Wurzelstruktur der Post-Build-Konfiguration.
  • ECUM_E_CONFIGURATION_DATA_INCONSISTENT: Fester Fehlercode für inkonsistente Header, Prüfsummen oder Signaturen.
  • Mcu_ResetType: Enumeration hardwarebasierter Reset-Ursachen (z. B. Power-On, Watchdog, Software-Reset).
  • DEFAULT_APP_MODE: Normierter Standard-Startmodus des AUTOSAR OS.

3. Dynamisches Verhalten & Sequenzablauf

1. Phase Init Block 0:
   • Synchroner Aufruf von EcuM_AL_DriverInitZero() durch EcuM.
   • Initialisierung minimaler Hardware-Basics (z. B. Core-Register, Watchdog-Early-Refresh, Low-Level-Taktung), die zwingend erforderlich sind, bevor Konfigurationsdaten ausgewertet werden können.
2. PB-Konfigurationsauflösung:
   • EcuM ruft EcuM_DeterminePbConfiguration() auf, um den Zeiger auf die EcuM_ConfigType-Struktur zu ermitteln (z. B. aus reserviertem Flash-Bereich, Bootmanager-Übergabe oder festem Linker-Symbol).
3. Plausibilisierung:
   • Interne synchrone Validierung: Check consistency of configuration data() (Magic Number, Version Header, Hash/CRC).
4. Fehlerpfad (opt Configuration data inconsistent):
   • Falls Validierung fehlschlägt: Aufruf von EcuM_ErrorHook(ECUM_E_CONFIGURATION_DATA_INCONSISTENT).
   • Abbruchbedingung: "This call never returns!" – Der Integrationscode muss in eine Endlosschleife, einen sicheren Haltemodus oder einen gezielten Reset verzweigen. Der Systemstart wird unwiderruflich abgebrochen.
5. Phase Init Block I (Init Block 1):
   • Bei konsistenter Konfiguration: Aufruf von EcuM_AL_DriverInitOne(const EcuM_ConfigType*).
   • Initialisierung aller weiteren Pre-OS-Treiber (z. B. Port, DIO, externe Treiber), die Post-Build-Parameter benötigen, aber vor der OS-Aktivierung bereitstehen müssen.
6. Reset-Grund-Auswertung:
   • Abfrage über Mcu_GetResetReason().
   • Interne Zuordnung via Map reset reason to wakeup source(): Verknüpft die physische Reset-Ursache mit der entsprechenden logischen AUTOSAR-Wakeup-Source (z. B. ECUM_WKSOURCE_POWER).
7. Shutdown-Target-Initialisierung:
   • EcuM_SelectShutdownTarget(...) setzt das initiale Shutdown-Target (Default: meist ECUM_STATE_RESET oder ECUM_STATE_SLEEP), um einen definierten Zustand zu garantieren, falls vor Erreichen des Run-States abgebrochen wird.
8. OS-Start:
   • Synchroner Aufruf von StartOS(DEFAULT_APP_MODE).
   • Der EcuM gibt die Ablaufsteuerung vollständig an den OS-Kernel ab; dieser Aufruf kehrt im Normalbetrieb nicht zurück. Die weitere Initialisierung (Init Block II/III) erfolgt asynchron im StartupHook bzw. in nachgelagerten BSW-Tasks.

4. Normative Relevanz & Entwickler-Hinweise

• Ausführungskontext: Die gesamte Sequenz läuft im Reset-Kontext (Supervisor-/Privileged-Mode) bei typischerweise global gesperrten Interrupts. Es existieren noch kein OS-Task-Handling, kein Timer-Tick und keine Schichten oberhalb der Basis-Treiber (kein Dem, kein Det, kein SchM).
• Treiberrestriktionen in Init Block 0:
  • Module in EcuM_AL_DriverInitZero() dürfen ausschließlich Pre-Compile-Parameter verwenden (VARIANT-PRE-COMPILE). Jeder Zugriff auf Post-Build-Zeiger führt zu undefiniertem Verhalten.
• Fail-Safe im ErrorHook:
  • Da Det und Dem noch nicht initialisiert sind, darf EcuM_ErrorHook keine Standard-Fehlerprotokollierung verwenden. Der Integrator muss den Watchdog gezielt triggern oder die CPU in einem unendlichen Loop sperren, um unkontrollierte Ausführung mit korrupter Konfiguration zu verhindern.
• Konfigurationsvertrag Post-Build:
  • Der von EcuM_DeterminePbConfiguration zurückgegebene Zeiger muss zeiger- und typkompatibel zu den in EcuM_AL_DriverInitOne erwarteten Modulstrukturen sein und dauerhaft im adressierbaren Speicherbereich liegen.
• Wakeup-Source-Mapping:
  • Das Mapping von Mcu_ResetType zu Wakeup-Sources setzt eine lückenlose Parametrierung im EcuM-Modell (EcuMWakeupSource) voraus; nicht gemappte Hardware-Resets führen zu unvollständigem Startup-Tracking im State Manager.