Figure 35: CAN Controller or Transceiver Wakeup by Polling

1. Diagrammtyp & Architektur-Kontext

UML-Sequenzdiagramm mit kombinierten Fragmenten (loop, alt, opt) und sequenziell durchlaufenen Zustandsphasen des EcuM (GOSLEEP, SLEEP, WAKEUP I, WAKEUP VALIDATION). Es beschreibt die Software-Architektur und Ablauflogik im AUTOSAR-Standard (Releases R3.0.7 / R3.1.5) innerhalb des BSW-Moduls EcuM (ECU State Manager, System Services) zur Behandlung des Aufwachvorgangs eines Steuergeräts über Polling (zyklische Abfrage) von CAN-Controller oder CAN-Transceiver, wenn hardwareseitig keine Interrupt-Aufweckung genutzt wird oder verfügbar ist.

2. Komponenten, Entitäten & Schnittstellen

Beteiligte Instanzen und Schichten (von links nach rechts):

• OS::Os: AUTOSAR OS zur Steuerung des Schedulers über Ressourcensperren.
• «module» EcuM::EcuM: ECU State Manager zur Ablaufsteuerung der Schlaf- und Aufwachphasen.
• Generic Elements::ECU Firmware: Integratorspezifische Callout-Ebene und Plattform-Hooks.
• «module» Mcu::Mcu: Microcontroller Driver (MCAL) zur Takt- und Power-Mode-Umschaltung.
• «module» Icu::Icu: Input Capture Unit (MCAL), als Lebenslinie deklariert, im Polling-Pfad ohne Interaktion.
• «module» CanIf::CanIf: CAN Interface (Communication Abstraction) zur Treiber- und Transceiver-Abstraktion.
• «module» Can::Can: CAN Driver (MCAL).
• «module» CanTrcv::CanTrcv: CAN Transceiver Driver (Hardware Abstraction).
• «Peripheral» Hardware::CanController und «Peripheral» Hardware::CAN Transceiver Hardware: Hardware-Peripherieelemente (passiv ohne Nachrichtenflüsse dargestellt).

Schnittstellen und Operationen:

• OS-Dienste: GetResource(uint8), ReleaseResource(uint8)
• Mcu-Dienste: Mcu_SetMode(Mcu_ModeType)
• EcuM Callouts / Hooks: EcuM_EnableWakeupSources(EcuM_WakeupSourceType), EcuM_SleepActivity(), EcuM_CheckWakeup(EcuM_WakeupSourceType), EcuM_DisableWakeupSources(EcuM_WakeupSourceType)
• Treiber- und Abstraktionsschnittstellen: CanIf_CheckWakeup(uint8), Can_Cbk_CheckWakeup(uint8), CanTrcv_CB_WakeupByBus(uint8, Std_ReturnType)
• Wakeup-Meldung: EcuM_SetWakeupEvent(EcuM_WakeupSourceType)

3. Dynamisches Verhalten & Sequenzablauf

Sequenzablauf:

1. Phase GOSLEEP: EcuM ruft den Callout EcuM_EnableWakeupSources(EcuM_WakeupSourceType) auf (Voraussetzung: CanSM hat zuvor CanIf_SetControllerMode und CanIf_SetTransceiverMode ausgeführt). EcuM fordert über GetResource(uint8) die Scheduler-Ressource an, um Taskwechsel zu unterbinden.
2. Phase SLEEP: EcuM schaltet via Mcu_SetMode(Mcu_ModeType) in einen energiesparenden Modus mit reduzierter Taktfrequenz, in dem Softwarebefehle weiter zyklisch abgearbeitet werden.
3. Schleifenfragment loop WHILE no pending wakeup events:
   • EcuM führt zyklisch EcuM_SleepActivity() auf der ECU Firmware aus.
   • EcuM initiiert die Aufwachprüfung über EcuM_CheckWakeup(EcuM_WakeupSourceType) an die ECU Firmware, welche CanIf_CheckWakeup(uint8) aufruft.
   • Verzweigungsfragment alt Wakeup Device:
     • Bedingung [CAN Controller]: CanIf ruft Can_Cbk_CheckWakeup(uint8) am CAN-Treiber auf.
     • Bedingung [CAN Transceiver]: CanIf ruft CanTrcv_CB_WakeupByBus(uint8, Std_ReturnType) am CAN-Transceiver-Treiber auf.
   • Optionales Fragment opt Wakeup Detected: Wurde an Controller oder Transceiver ein Aufwachereignis detektiert, meldet CanIf dieses mit EcuM_SetWakeupEvent(EcuM_WakeupSourceType) an EcuM zurück. Damit ist ein Wakeup-Event anhängig und die Schleife terminiert.
4. Phase WAKEUP I: EcuM stellt über Mcu_SetMode(Mcu_ModeType) den Normaltakt wieder her, deaktiviert über EcuM_DisableWakeupSources(EcuM_WakeupSourceType) die Wakeup-Quellen und gibt über ReleaseResource(uint8) den OS-Scheduler frei.
5. Das System wechselt in die Phase WAKEUP VALIDATION.

4. Normative Relevanz & Entwickler-Hinweise

Normative Relevanz und Integrationshinweise:

• Betriebsmodus: Dargestellt ist der EcuM-Polling-Modus (Sleep mit CPU-Aktivität bei reduziertem Takt), der zwingend erforderlich ist, wenn Hardware-Peripherien keine autonomen Wakeup-Interrupts erzeugen können oder Sleep-Modi ohne Interrupt-Aufwachpfad gewählt wurden.
• Scheduler-Blockierung: Der Aufruf von GetResource stellt sicher, dass während der gesamten Polling-Schleife und des anschließenden Wiederhochfahrens keine normalen BSW- oder Anwendungs-Tasks interferieren; erst in WAKEUP I wird der Scheduler freigegeben.
• Release-Spezifika (AUTOSAR R3.x): Die Nomenklatur Can_Cbk_CheckWakeup und CanTrcv_CB_WakeupByBus sowie die Routing-Rolle von Generic Elements::ECU Firmware als Callout-Vermittler sind spezifisch für die R3-Linie und wurden in späteren AUTOSAR-Releases refaktoriert.
• Zustandsüberführung: Die Detektion über EcuM_SetWakeupEvent überführt den EcuM unmittelbar aus der Polling-Schleife in die Re-Initialisierungsphase WAKEUP I und die Validierungsphase WAKEUP VALIDATION.