Figure 30: Master Core Poll Sequence

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.x Sequenzdiagramm (Interaktionsdiagramm).
• Funktionaler Kontext: AUTOSAR Classic Platform (Release 4.0.3), Spezifikation des ECU State Managers (AUTOSAR_SWS_ECUStateManager, EcuM mit Flexible/Fixed Management).
• Systemische Einordnung: Detailablauf der Polling-basierten Schlaf-/Aufwachsequenz auf dem Master-Core (Master Core Poll Sequence) im Zustand ECUM_STATE_SLEEP. Das Diagramm spezifiziert das deterministische Zusammenspiel zwischen EcuM, Integration-Callouts, MCAL-Treibern, OS und BswM, wenn die ECU in einem Schlafmodus betrieben wird, in dem Wakeup-Events nicht (oder nicht ausschließlich) autark über asynchrone Hardware-Interrupts (ISRs) gemeldet werden, sondern zyklisches Polling erfordern. Es beinhaltet die anschließende Multicore-Synchronisation zur Reaktivierung von Slave-Cores.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Lebenslinien (Lifelines):
  • «module» EcuM: Zentraler BSW-Zustandsverwalter (System Services Layer). Steuert Schlafsequenz, Wakeup-Polling, Event-Pufferung und Multicore-Freigabe.
  • Integration Code: OEM-/Plattformspezifischer BSW-Callout-Layer. Kapselt hardwarespezifische Dispatcher-Logik (EcuM_CheckWakeup, EcuM_SleepActivity).
  • «module» Os: Operating System (System Services Layer). Bereitstellung von System-Interruptsperren (DisableAllInterrupts, EnableAllInterrupts).
  • «module» Mcu: Microcontroller Driver (MCAL). Hardware-Abstraktion zur Umschaltung des Systemtakts und der CPU-Stromsparmodi (Mcu_SetMode).
  • «module» Wakeup Source: MCAL-/Hardware-Treiber (z. B. Can, Lin, Fr, Icu, Gpt, interner AlarmClock-Timer), welche physikalische Wakeup-Ereignisse erfassen.
  • «module» :BswM: Basic Software Manager (System Services Layer). Schiedsrichter für Moduswechsel; empfängt Wakeup-Zustandsänderungen zur Regelauswertung via BswM-Actions/Rules.
• Schnittstellen & Parameter:
  • DisableAllInterrupts(), EnableAllInterrupts(): OSEK/AUTOSAR OS API.
  • Mcu_SetMode(Mcu_ModeType): MCAL-Treiberschnittstelle zur Aktivierung des spezifizierten Low-Power-/Halt-Modus.
  • EcuM_SleepActivity(): Integrations-Callout zur zyklischen Ausführung während des Polling-Zustands (z. B. Watchdog-Servicing).
  • EcuM_CheckWakeup(EcuM_WakeupSourceType): Integrations-Callout zur Weiterleitung des Abfragebefehls.
  • <Module>_CheckWakeup(): MCAL-spezifische Treiberschnittstelle (z. B. Can_CheckWakeup()).
  • EcuM_SetWakeupEvent(EcuM_WakeupSourceType): Asynchroner/synchroner Callback an den EcuM zur Registrierung erkannter Wakeup-Quellen.
  • EcuM_GetPendingWakeupEvents(EcuM_WakeupSourceType): Interne EcuM-Prüfung ausstehender Wakeup-Bitmasken.
  • BswM_EcuM_CurrentWakeup(sources, EcuM_WakeupStatusType): Benachrichtigung des BswM mit den Statuswerten ECUM_WKSTATUS_PENDING (Validierung erforderlich) bzw. ECUM_WKSTATUS_VALIDATED (keine Validierung erforderlich).
  • Signal SlaveCores to continue(): Inter-Core-Kommunikationsmechanismus (z. B. OS-Events, IPC, Shared Memory Flag / Core Release Barrier).

3. Dynamisches Verhalten & Sequenzablauf

1. Sleep Mode Entry (Vorbereitung):
   • EcuM sperrt alle System-Interrupts synchron via DisableAllInterrupts().
   • EcuM setzt den Low-Power-Modus über Mcu_SetMode(Mcu_ModeType) ab (die MCU wechselt in den Sleep/Reduce-Power-Zustand oder reduziert den Core-Takt).
   • EcuM reaktiviert die Interrupts synchron via EnableAllInterrupts().
2. Polling-Hauptschleife (loop WHILE no pending wakeup events):
   • Guard Condition: Die Schleife iteriert, solange keine Wakeup-Ereignisse ausstehen (no pending wakeup events).
   • Erweiterte Schleifenbedingung (Diagramm-Notiz): While (AlarmClockService Present AND EcuM_AlarmClock only pending event AND Alarm not expired). Wenn ausschließlich das Wakeup-Event der internen AlarmClock vorliegt, der konfigurierte Alarm-Timer aber noch nicht abgelaufen ist, verbleibt die Schleife aktiv.
   • Zyklus-Schritte:
     1. Ausführung von EcuM_SleepActivity() (Integration Code).
     2. Innere Schleife (loop FOR all wakeup sources that need polling):
        • EcuM ruft für jede polling-basierte Wakeup-Quelle den Callout EcuM_CheckWakeup(EcuM_WakeupSourceType) auf.
        • Der Integration Code delegiert synchron an die korrespondierende Treiberschnittstelle <Module>_CheckWakeup().
        • Bedingter Zweig (opt Wakeup detected): Stellt der Treiber ein physikalisches Wakeup fest, meldet er dies über EcuM_SetWakeupEvent(...) an den EcuM zurück.
     3. EcuM aktualisiert intern die anstehenden Events über EcuM_GetPendingWakeupEvents(...) zur Auswertung der Schleifenabbruchbedingung.
3. Post-Wakeup-Notifizierung an BswM (alt):
   • Sobald die Schleife terminiert (mindestens ein valides Event detektiert):
     • Pfad [Yes] (Wakeup-Quelle erfordert Validierung): EcuM meldet BswM_EcuM_CurrentWakeup(sources, ECUM_WKSTATUS_PENDING). Der BswM startet daraufhin die Validierungsphase (z. B. Protokoll-Frames abwarten).
     • Pfad [No] (Wakeup-Quelle erfordert keine Validierung): EcuM meldet BswM_EcuM_CurrentWakeup(sources, ECUM_WKSTATUS_VALIDATED) (im Vektortext als BswMEcuM_CurrentWakeup typographisch fehlerhaft abgebildet).
4. Multicore-Freigabe:
   • Der Master-Core führt die interne Aktion Signal SlaveCores to continue() aus. Zuvor angehaltene/schlafende Slave-Cores werden synchronisiert und setzen ihren Post-Sleep-Pfad fort.

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationsvertrag (ECUC):
  • Wakeup-Quellen müssen über den Parameter EcuMPollingWakeupSource = TRUE deklariert sein, um in die innere Polling-Schleife aufgenommen zu werden.
  • Das Attribut EcuMValidationTimeout bestimmt den Pfad im alt-Block: Bei Werten > 0 wird ECUM_WKSTATUS_PENDING an den BswM gesendet; bei = 0 wird direkt ECUM_WKSTATUS_VALIDATED signalisiert.
• Implementierungsanforderungen im Integration Code:
  • EcuM_CheckWakeup() muss als Switch/Demux implementiert werden, um die EcuM_WakeupSourceType-Bitmaske auf die konkreten Treiber-APIs (Can_CheckWakeup, Lin_CheckWakeup etc.) aufzulösen.
  • EcuM_SleepActivity() muss nicht-blockierend und deterministisch sein. Ein Überschreiten der Polling-Laufzeit führt zu erhöhtem Stromverbrauch und potenziellen Watchdog-Timeouts.
• Treiberanforderungen (MCAL/Transceiver):
  • Module, die Polling unterstützen, müssen reentrante/synchrone <Module>_CheckWakeup()-Funktionen bereitstellen und darin direkt EcuM_SetWakeupEvent() aufrufen, sofern Statusflags auf Controller- oder Transceiver-Ebene gesetzt sind.
• Multicore-Restriktionen:
  • Die Polling-Sequenz läuft ausschließlich auf dem Master-Core (Core mit der zugewiesenen EcuM-Master-Instanz).
  • Slave-Cores müssen sich vor dem Eintritt des Master-Cores in die Schleife in einem sicheren Ruhezustand (z. B. WFI/Halt via OS) befinden. Das Core-Signalisieren (Signal SlaveCores to continue()) erfordert zwingend deterministische Inter-Core-Mechanismen (z. B. Cross-Core-Interrupts / IOC).