Figure 12: GoSleep Sequence

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Sequence Diagram).
• Technischer Zweck & Einordnung: Spezifiziert die vorbereitende Sequenz zum Übergang in den Schlafzustand (GoSleep Sequence) innerhalb der System Services des AUTOSAR Classic BSW (Release R4.0.3).
• Funktionale Einordnung: Definiert die deterministische Kopplung zwischen dem Basissoftware-Zustandsverwalter (EcuM), hardwarenahem Integrationscode, dem Regelsystem des Modemanagers (BswM) und dem AUTOSAR-OS zur Vorbereitung des Controller- bzw. Core-Sleeps.

2. Komponenten, Entitäten & Schnittstellen

• Lebenslinien & Akteure:
  • «module» EcuM: ECU State Manager (Instanz/Modul; trägt das UML-Dekompositionssymbol oo für verfeinerte Sub-Interaktionen).
  • Integration Code: Plattform- und ECU-spezifischer BSW-Callout-Code zur Hardware-Ansteuerung.
  • «module» :BswM: Basic Software Mode Manager (anonyme Modulinstanz).
  • «module» Os: AUTOSAR Operating System (System-Service-Modul mit Dekompositionssymbol oo).
• Schnittstellen & Parameter:
  • EcuM_EnableWakeupSources(EcuM_WakeupSourceType): Synchrones Callout an den Integrationscode zur Scharfschaltung der hardwareseitigen Aufweckpfade für das Ziel-Sleep-Level.
  • BswM_EcuM_CurrentWakeup(sources, ECUM_WKSTATUS_NONE): BSW-Inter-Modul-Indikation; übergibt die Bitmaske/ID der Wakeup-Quellen mit Status ECUM_WKSTATUS_NONE zur Neutralisierung vorheriger Wakeup-Ereignisse im Arbitrations-Kontext des BswM.
  • GetResource(RES_AUTOSAR_ECUM_<core#>): Standard-OS-API (OSEK/VDX- bzw. AUTOSAR-OS-Standard) zur Belegung einer kernspezifischen OS-Ressource.

3. Dynamisches Verhalten & Sequenzablauf

1. Status-Bereinigung am BswM (synchron):
   • EcuM meldet den Zustand aller zu aktivierenden Quellen mittels BswM_EcuM_CurrentWakeup(sources, ECUM_WKSTATUS_NONE) an den BswM. Dies setzt flüchtige oder vorherige Wakeup-Zustände zurück und verhindert Fehlarbitrierungen in anstehenden Modusregeln vor dem Scharfschalten der Quellen.
2. Aktivierung der Aufweckquellen (synchron):
   • EcuM ruft EcuM_EnableWakeupSources(EcuM_WakeupSourceType) auf. Der Integrationscode konfiguriert Treiber (z. B. ICU-Kanäle, Transceiver-Standby, externe Wake-up-Pins) für die Überwachung.
3. Scheduler-Sperre / Kritischer Abschnitt (synchron):
   • EcuM fordert über GetResource(RES_AUTOSAR_ECUM_<core#>) die kernexklusive Ressource an.
   • Wirkung: Hebt die Priorität der aufrufenden Task auf das definierte Ceiling-Level der Ressource an. Dies unterbindet Task-Wechsel/Preemption auf dem jeweiligen Kern vor dem eigentlichen Low-Power-Eintritt und schützt den anstehenden Sleep-Modusübergang vor inkonsistentem Task-Verhalten.

4. Normative Relevanz & Entwickler-Hinweise

• Callout-Implementierung (Integration Code):
  • Entwickler müssen in EcuM_EnableWakeupSources sicherstellen, dass ausschließlich diejenigen Hardware-Blöcke (z. B. CanTrcv, LinTrcv, Icu) wake-up-fähig geschaltet werden, die im aktuellen Sleep-Modus aktiv sein dürfen (Stromaufnahme-Budgetierung).
• BswM-Regelwerk:
  • Der Übergang der Wakeup-Quellen auf ECUM_WKSTATUS_NONE muss in den BswM-Mode-Arbitration-Tabellen berücksichtigt werden, damit keine unerwünschten Moduswechsel (Mode Requests) parallel zum Einschlafen ausgelöst werden.
• OS- & Multicore-Konfiguration (OsResource):
  • Für jeden im System aktiven Core (<core#>) muss im Os-Generierungsmodell eine Ressource nach dem Namensschema RES_AUTOSAR_ECUM_<core#> konfiguriert sein.
  • Das Ceiling-Level dieser Ressource muss mindestens der höchsten Task-Priorität entsprechen, die auf dem Core Zugriff auf EcuM-Dienste hat.
  • Nach Belegung der Ressource dürfen bis zum Verlassen des Schlafzustands bzw. bis zum Aufruf von ReleaseResource keine blockierenden OS-Systemaufrufe (z. B. WaitEvent) erfolgen.