Figure 7.1: Driver State

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Zustandsdiagramm (State Machine Diagram).
• Architektur-Kontext: AUTOSAR Classic Platform (CP), Microcontroller Abstraction Layer (MCAL), BSW-Modul Can (AUTOSAR_CP_SWS_CANDriver, Release R24-11).
• Funktionale Einordnung: Definiert den übergeordneten Lebenszyklus (Global Module State / Driver State) des gesamten CAN-Treibers. Dieser Zustand kapselt die Verfügbarkeit der Treiber-Infrastruktur und ist strikt zu unterscheiden von den individuellen Controller-Zuständen (CAN_CS_UNINIT, CAN_CS_STOPPED, CAN_CS_STARTED, CAN_CS_SLEEP).

2. Komponenten, Entitäten & Schnittstellen

• Zustände:
  • Initial (UML-Pseudozustand): Eintrittspunkt nach Hardware-Reset / Power-On.
  • CAN_UNINIT: Modul ist nicht initialisiert; Hardware-Register sind undefiniert bzw. im Reset-Zustand; Pufferstrukturen und Controller-Instanzen sind unkonfiguriert.
  • CAN_READY: Modul ist vollständig initialisiert, globale Datenstrukturen und Mailboxen sind allokiert; Treiber ist betriebsbereit.
• Schnittstellen (Transitions-Trigger / APIs):
  • Can_Init(const Can_ConfigType* ConfigPtr): Synchroner Treiber-Initialisierungsservice (SWS_Can_00246, SRS_SPAL_12057, SRS_Can_01041).
  • Can_DeInit(void): Synchroner Treiber-Deinitialisierungsservice (SWS_Can_91009, SWS_Can_91010, SRS_Can_01166).
• Kardinalitäten & Relationen:
  • Flache 1:1-Zustandsmaschine ohne hierarchische Unterzustände auf Treiberebene.
  • Orthogonal zu den Controller-Statemachines: Der Treiberzustand übersteuert alle untergeordneten Controller-Instanzen (kein Controller kann ohne CAN_READY betrieben werden).

3. Dynamisches Verhalten & Sequenzablauf

1. Systemstart / Reset:
   • Unkonditionierter Übergang vom Pseudozustand Initial nach CAN_UNINIT (SWS_Can_00245).
2. Initialisierungspfad (CAN_UNINIT → CAN_READY):
   • Trigger: Synchroner Aufruf von Can_Init().
   • Ablauf: Hardware-Register werden gemäß Can_ConfigType konfiguriert, Hardware-Objekte (HRH/HTH) initialisiert und alle zugeordneten Controller in den Zustand CAN_CS_STOPPED versetzt.
   • Guard / Fehlerbedingung: Wird Can_Init() im Zustand CAN_READY aufgerufen, wird bei aktivem CanDevErrorDetect der DET-Fehler CAN_E_TRANSITION gemeldet; die Re-Initialisierung wird abgewiesen.
3. Deinitialisierungspfad (CAN_READY → CAN_UNINIT):
   • Trigger: Synchroner Aufruf von Can_DeInit().
   • Abbruchbedingung / Guard (SWS_Can_91010): Alle im Treiber verwalteten CAN-Controller müssen sich im Zustand CAN_CS_STOPPED befinden. Befindet sich mindestens ein Controller im Zustand CAN_CS_STARTED oder CAN_CS_SLEEP, darf die Transition nicht stattfinden; DET meldet CAN_E_TRANSITION.
   • Fehlerbedingung (SWS_Can_91009): Aufruf von Can_DeInit() im Zustand CAN_UNINIT meldet DET CAN_E_TRANSITION (bzw. je nach Implementierung CAN_E_UNINIT).
4. Schutz operationaler APIs:
   • Alle regulären CAN-APIs (z. B. Can_SetControllerMode(), Can_Write(), Can_GetControllerMode(), Can_CheckWakeup(), Can_MainFunction_Write()) prüfen den Modulstatus. Im Zustand CAN_UNINIT verwerfen sie den Aufruf und melden CAN_E_UNINIT.

4. Normative Relevanz & Entwickler-Hinweise

• Orchestrierung (EcuM / BswM): Can_Init() darf ausschließlich durch den BSW-Initialisierungs-Sequenzer (EcuM / BswM) aufgerufen werden, bevor CanIf_Init() ausgeführt wird.
• Zustands-Semantik für Treiber-Entwickler:
  • CAN_READY bedeutet nicht, dass der CAN-Bus aktiv ist. Es signalisiert lediglich die statische Betriebsbereitschaft. Vor einer Datenübertragung (Can_Write) muss CanIf die individuellen Controller explizit über Can_SetControllerMode(Controller, CAN_CS_STARTED) aktivieren.
  • Das Treiberzustands-Flag muss reentrancy-sicher implementiert sein (insbesondere bei Multi-Core-MCALs, wenn Controller unterschiedlichen Cores zugeordnet sind).
• Shutdown- & Sleep-Restriktionen: Vor Aufruf von Can_DeInit() muss der State Manager (CanSM via CanIf) sicherstellen, dass alle Kanäle sauber gestoppt wurden. Ein direkter Shutdown-Versuch aus dem STARTED- oder SLEEP-Zustand scheitert an der normativen Guard SWS_Can_91010.