Figure 7.2: Controller State Machine

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Zustandsautomat (State Machine / Statechart Diagram).
• Technischer Zweck & Einordnung:
  • Definiert den normativen hardwarenahen Lebenszyklus und die Betriebsmodi eines einzelnen CAN-Controllers innerhalb des MCAL-Treibers (Can, Modul-ID 80).
  • Dient als Zustandsreferenz für die Steuerung durch das CAN-Interface (CanIf) bzw. den CAN State Manager (CanSM).
  • Trennt die globale Modul-Initialisierung (Can_Init() / Can_DeInit()) von den individuellen logischen Betriebszuständen der einzelnen Hardware-Controller.

2. Komponenten, Entitäten & Schnittstellen

• Zustände (Can_ControllerStateType gemäß SWS_Can_00259):
  • UNINIT (CAN_CS_UNINIT): Grundzustand nach Reset oder vollständiger De-Initialisierung. Hardware-Register befinden sich im Reset-/Power-Down-Zustand; Interrupts sind maskiert, Clocks ggf. gegated.
  • STOPPED (CAN_CS_STOPPED): Controller ist konfiguriert und initialisiert, jedoch logisch vom CAN-Bus getrennt (kein Senden, kein Empfangen, keine ACKs auf dem Bus). Dies ist der deterministische Einstiegszustand nach der Initialisierung.
  • STARTED (CAN_CS_STARTED): Operativer Betriebszustand. Der Controller nimmt vollumfänglich an der Buskommunikation teil (Tx/Rx aktiv, ACK-Erzeugung, Fehler-Frames).
  • SLEEP (CAN_CS_SLEEP): Energiesparmodus des Controllers mit aktivierter Wake-up-Erkennung (sofern hardwareseitig unterstützt).
• Trigger & Schnittstellenfunktionen:
  • Modul-APIs: Can_Init(ConfigPtr), Can_DeInit() (SWS_Can_00408).
  • Controller-Modus-API: Can_SetControllerMode(Controller, Transition) (SWS_Can_00174) mit Zielzuständen CAN_CS_STARTED, CAN_CS_STOPPED, CAN_CS_SLEEP.
  • Asynchrone Rückmeldung: CanIf_ControllerModeIndication(Controller, ControllerMode).
• Kardinalitäten:
  • 1 : n Beziehung zwischen dem CAN-Treiber-Modul und den physikalischen CAN-Controllern. Der Zustand jedes Controllers wird unabhängig verwaltet, während Can_Init und Can_DeInit treiberweit wirken.

3. Dynamisches Verhalten & Sequenzablauf

• Initialisierungssequenz:
  1. PowerON reset führt in den Pseudozustand UNINIT.
  2. Aufruf von Can_Init() überführt alle konfigurierten CAN-Controller synchron von UNINIT nach STOPPED.
• Modusübergänge im Betrieb:
  • STOPPED -> STARTED: Aufruf von Can_SetControllerMode(Controller, CAN_CS_STARTED). Aktiviert Rx/Tx-Puffer und Bit-Timing-Logik.
  • STARTED -> STOPPED: Aufruf von Can_SetControllerMode(Controller, CAN_CS_STOPPED). Bricht laufende Tx-Übertragungen ab und unterdrückt Rx.
  • STOPPED -> SLEEP: Aufruf von Can_SetControllerMode(Controller, CAN_CS_SLEEP). Versetzt den Controller in den Sleep-Modus.
  • SLEEP -> STOPPED: Aufruf von Can_SetControllerMode(Controller, CAN_CS_STOPPED) (z. B. nach Wake-up-Event via CAN-Transceiver/Busaktivität).
• Invariante der Moduswechsel (Verbotene Direktpfade):
  • Es existiert keine direkte Transition zwischen STARTED und SLEEP. Ein Übergang in oder aus dem Schlafmodus muss zwingend über den Zwischenzustand STOPPED geführt werden (STARTED ↔ STOPPED ↔ SLEEP).
• Selbst-Transitionen (Idempotenz):
  • Die Schleifen an STOPPED und SLEEP stellen sicher, dass ein erneuter Request auf den bereits aktiven Zustand idempotent behandelt wird (liefert E_OK, führt ggf. die Mode-Indication aus).
• De-Initialisierung:
  • Can_DeInit() ist ausschließlich aus den Zuständen STOPPED oder SLEEP zulässig und überführt den Controller zurück nach UNINIT.
  • Eine De-Initialisierung direkt aus STARTED ist verboten.

4. Normative Relevanz & Entwickler-Hinweise

• Asynchronität & Hardware-Latenz:
  • Zustandswechsel via Can_SetControllerMode() sind hardwarebedingt oft asynchron (Warten auf Bus-Idle, Synchronisation auf Bit-Grenzen oder Bestätigung des Freeze-/Init-Modes im Silizium).
  • Treiber-Implementierer müssen die Umschaltung entweder über Polling (mit harter Timeout-Begrenzung) oder über Interrupts abwickeln und den erfolgreichen Wechsel via CanIf_ControllerModeIndication() signalisieren.
• Vorbedingungen für Can_DeInit() (SWS_Can_00408):
  • Bevor Can_DeInit() aufgerufen werden darf, müssen alle Controller des CAN-Treibers in STOPPED oder SLEEP sein.
  • Befindet sich mindestens ein Controller im Zustand STARTED, muss der Aufruf abgewiesen und bei aktiviertem DET der Fehler CAN_E_TRANSITION gemeldet werden.
• Puffer-Bereinigung bei STARTED -> STOPPED:
  • Beim Verlassen von STARTED müssen ausstehende Transmit-Requests in Hardware-Mailboxen sicher abgebrochen werden (Hardware Transmission Cancellation).
  • Für stornierte Frames dürfen keine CanIf_TxConfirmation()-Callbacks generiert werden.
• Fehlerbehandlung (DET):
  • Aufrufe von Can_SetControllerMode() im Zustand UNINIT führen zwingend zu CAN_E_UNINIT.
  • Illegale Transitionsanfragen (z. B. Direktanforderung STARTED -> SLEEP) müssen mit CAN_E_TRANSITION zurückgewiesen werden.