DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_ECUStateManager FIG-297343571c648701 918 × 1232 px 3 Release(s)

Figure 4: StartPreOS Sequence

SHA-256 Inhalts-Fingerabdruck: 297343571c64870107d953d6c0ddbd0ff0a22e799e61acdec731bee0d7088506
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

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(const EcuM_ConfigType*): Integrationsfunktion zur Lokalisierung/Bereitstellung der Post-Build-Konfigurationswurzel im Speicher (Übergabe als zeigerkonstanter Typ).
    • EcuM_ErrorHook(uint16 reason): Kritischer Callout bei fatalen Konfigurationsfehlern (ECUM_E_CONFIGURATION_DATA_INCONSISTENT).
    • EcuM_AL_DriverInitOne(): Callout zur Ausführung von Init Block I (Post-Build-abhängige MCAL-/BSW-Treiber vor OS-Start, parameterlos aufgerufen).
    • Mcu_GetResetReason(): MCAL-API zur Abfrage des Hardware-Reset-Statusregisters; liefert Mcu_ResetType.
    • EcuM_SelectShutdownTarget(Std_ReturnType, EcuM_ShutdownTargetType, EcuM_ShutdownModeType): Interne Standard-Schnittstelle zur Festlegung des Default-Shutdown-Ziels.
    • EcuM_LoopDetection(): Integrations-Callout zur Erkennung und Absicherung gegen unkontrollierte Reset-Schleifen vor dem OS-Start.
    • StartOS(AppModeType): OSEK/AUTOSAR-OS-API zum Hochfahren des Schedulers mit ECUM_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).
    • EcuM_ShutdownTargetType: Standardisierter Aufzählungstyp für Shutdown-Ziele.
    • EcuM_ShutdownModeType: Modustyp zur Spezifikation des Untermodus für das Shutdown-Target.
    • ECUM_DEFAULT_APP_MODE: Normierter Standard-Startmodus des AUTOSAR OS im EcuM.

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(const EcuM_ConfigType*) auf, um den Zeiger auf die konstante EcuM_ConfigType-Struktur zu ermitteln.
  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: Parameterloser Aufruf von EcuM_AL_DriverInitOne().
    • Initialisierung aller weiteren Pre-OS-Treiber (z. B. Port, DIO, externe Treiber), die vor der OS-Aktivierung bereitstehen müssen und auf die zuvor validierte Konfiguration zugreifen.
  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.
  8. Schleifenerkennung (Loop Detection):
    • Synchroner Aufruf von EcuM_LoopDetection() zur Integrationslogik vor dem Eintritt in das Betriebssystem.
  9. OS-Start:
    • Synchroner Aufruf von StartOS(ECUM_DEFAULT_APP_MODE).
    • Der EcuM gibt die Ablaufsteuerung vollständig an den OS-Kernel ab; dieser Aufruf kehrt nicht zurück.

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.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R4.2.2 → R4.3.1 normative Änderung Vorgänger: FIG-e00c88d6a6c5a705
  • EcuM_DeterminePbConfiguration: Dem Zeigerparameter wurde ein const-Qualifier hinzugefügt (const EcuM_ConfigType* statt EcuM_ConfigType*).
  • EcuM_AL_DriverInitOne: Der Konfigurationszeiger-Parameter const EcuM_ConfigType* entfällt; der Callout wird parameterlos (EcuM_AL_DriverInitOne()) ausgeführt.
R19-11 → R20-11 keine inhaltliche Änderung Nachfolger: FIG-dae2a59783f6a2ea

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

«module» | Os | «module» | Mcu | «module» | EcuM | Integration Code | Init Block I | opt Configuration data inconsistent | Init Block 0 | This call never returns! | EcuM_AL_DriverInitZero() | EcuM_DeterminePbConfiguration(const EcuM_ConfigType*) | Check consistency of configuration data() | EcuM_ErrorHook(ECUM_E_CONFIGURATION_DATA_INCONSISTENT) | EcuM_AL_DriverInitOne() | Mcu_GetResetReason(Mcu_ResetType) | Mcu_GetResetReason() | Map reset reason to wakeup source() | EcuM_SelectShutdownTarget(Std_ReturnType, EcuM_ShutdownTargetType, EcuM_ShutdownModeType) | EcuM_LoopDetection() | StartOS(ECUM_DEFAULT_APP_MODE)

Vorkommen in AUTOSAR-Releases (3)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R4.3.1 AUTOSAR_SWS_ECUStateManager S. 38 5 Figure 5: StartPreOS Sequence
R18-10_R4.4.0_R1.5.0 AUTOSAR_SWS_ECUStateManager S. 36 4 Figure 4: StartPreOS Sequence
R19-11 AUTOSAR_SWS_ECUStateManager S. 36 4 Figure 4: StartPreOS Sequence