Figure 9.1: CanTrcv Dio Interaction

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm mit kombinierten Fragmenten vom Typ alt).
• Funktionaler Kontext: Veranschaulicht das Zusammenspiel zwischen System Management, Communication Stack und MCAL bei der Betriebsartenumschaltung (CanTrcv_TrcvModeType) eines pin-gesteuerten (DIO-basierten) CAN-Transceiver-Treibers gemäß AUTOSAR_CP_SWS_CANTransceiverDriver.
• Architektonische Einordnung: Dargestellt wird die kaskadierte Weitergabe von Kommunikationsanforderungen von der Steuerungs- und State-Machine-Ebene (EcuM, ComM, CanSM) über die Abstraktionsschicht (CanIf) und den Transceiver-Treiber (CanTrcv) bis hin zum MCAL-Treiber Dio zur physischen Pegelsteuerung externer Pins (z. B. EN, STB/NSTB).

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Module:
  • Integration Code: OEM-/Projekt-spezifischer Integrations- bzw. Callout-Code für das System-Shutdown-/Sleep-Handling.
  • «module» EcuM: ECU State Manager (System Management) zur Initialisierung, Wakeup-Auswertung und Koordination des Run/Sleep-Transitionszyklus.
  • «module» ComM: Communication Manager (Resource/Mode Management für Kommunikationskanäle).
  • «module» CanSM: CAN State Manager (Netzwerk-Zustandsverwaltung des CAN-Subsystems).
  • «module» CanIf: CAN Interface (Abstraktion der CAN-Controller- und Transceiver-Hardware).
  • «module» CanTrcv: CAN Transceiver Driver (spezifischer BSW-Treiber zur Konfiguration und Ansteuerung der Transceiver-Hardware, hier als DIO-gesteuerter Treiber implementiert).
  • «module» Dio: Digital IO Driver (MCAL-Modul für direkten Port-Pin-Zugriff).
  • «Peripheral» ETH Hardware (PHY): Physisches Transceiver-IC auf der Leiterplatte. (Hinweis auf Spezifikationsfehler: Im AUTOSAR-Originaldokument wurde der Akteur fälschlicherweise als ETH Hardware (PHY) benannt; gemeint und funktional dargestellt ist der externe CAN Transceiver Hardware IC).
• Schnittstellen / Aufrufe:
  • ComM_EcuM_WakeUpIndication(NetworkHandleType)
  • CanSM_RequestComMode(ComM_ModeType) (Werte: COMM_FULL_COMMUNICATION, COMM_NO_COMMUNICATION)
  • CanIf_SetTrcvMode(uint8 TransceiverId, CanTrcv_TrcvModeType OpMode)
  • CanTrcv_SetOpMode(uint8 TransceiverId, CanTrcv_TrcvModeType OpMode)
  • Dio_WriteChannel(Dio_ChannelType ChannelId, Dio_LevelType Level)
  • Hardware-Aktion: set/reset HW ports() (Pegelwechsel an den GPIO-Pins des Mikrocontrollers)
  • EcuM_AL_SwitchOff() (ECU State Manager AL Callout)

3. Dynamisches Verhalten & Sequenzablauf

Fragment 1: [Start CAN Network] (Transition nach NORMAL)

1. Trigger: Ein Wakeup-Ereignis wird registriert; EcuM meldet dies via ComM_EcuM_WakeUpIndication(NetworkHandleType) an ComM.
2. Modusanforderung: ComM fordert über CanSM_RequestComMode(COMM_FULL_COMMUNICATION) die Volllast-Kommunikation an.
3. Kanalabstraktion: CanSM weist CanIf an, den Transceiver-Modus umzuschalten: CanIf_SetTrcvMode(CANIF_TRCV_MODE_NORMAL).
4. Treiberdurchgriff: CanIf leitet den Aufruf direkt an CanTrcv_SetOpMode(CANIF_TRCV_MODE_NORMAL) weiter.
5. MCAL-Pinmanipulation: Zur Umschaltung in den Normalbetrieb führt CanTrcv zwei sequentielle Aufrufe von Dio_WriteChannel(Dio_ChannelType, Dio_LevelType) aus (z. B. Setzen von STB=HIGH und EN=HIGH), wodurch die MCU-Hardwareports umgeschaltet werden (set/reset HW ports()).
6. Rücklauf: Alle Funktionsaufrufe kehren synchron über die Aufruf-Kaskade zurück. Der Transceiver befindet sich im Modus NORMAL (Senden und Empfangen aktiv).

Fragment 2: [Stop & Sleep CAN Network] (Zweistufige Abschaltung: STANDBY gefolgt von SLEEP)

1. Phase 1: Umschaltung in STANDBY (Netzwerk-Deaktivierung)
   • ComM fordert Kommunikationsstopp via CanSM_RequestComMode(COMM_NO_COMMUNICATION).
   • CanSM ruft CanIf_SetTrcvMode(CANIF_TRCV_MODE_STANDBY) auf.
   • CanIf delegiert an CanTrcv_SetOpMode(CANIF_TRCV_MODE_STANDBY).
   • CanTrcv setzt über zwei Dio_WriteChannel()-Aufrufe die entsprechenden Pegel (z. B. STB=LOW, EN=LOW), um den Hardware-Transceiver in den energiesparenden STANDBY-Zustand zu versetzen.
   • Hardware ist in STANDBY (kein Tx/Rx; Wakeup-Detektion aktiv). Aufrufe kehren synchron zurück.
2. Phase 2: Transition nach SLEEP (ECU Shutdown)
   • Während des Herunterfahrens der ECU ruft der Integration Code den Callout EcuM_AL_SwitchOff() auf.
   • EcuM versetzt den Transceiver vor dem finalen Power-Off/Standby in den Modus SLEEP via CanIf_SetTrcvMode(CANIF_TRCV_MODE_SLEEP).
   • CanIf ruft CanTrcv_SetOpMode(CANIF_TRCV_MODE_SLEEP) auf.
   • CanTrcv generiert die spezifische Pegelsequenz via zweifachem Dio_WriteChannel() (z. B. definierte Flanke oder Haltepegel zur Aktivierung der internen Transceiver-Sleep-Logik).
   • Hardware ist im stromsparenden Modus SLEEP. Nach Rückkehr beendet EcuM_AL_SwitchOff() die Abschaltsequenz.

4. Normative Relevanz & Entwickler-Hinweise

• Synchrones API-Design: Das Diagramm spezifiziert eine rein synchrone Ausführungskette. CanTrcv_SetOpMode kehrt erst zurück, wenn die DIO-Kanäle geschrieben sind.
• Transceiver-Hardware-Einschwingzeiten (t_mode / t_silence): Da Dio_WriteChannel lediglich den Ausgangsbuffer des Microcontrollers umschaltet, der Transceiver-IC jedoch eine physikalische Einschwingzeit benötigt (z. B. von Standby/Sleep nach Normal), muss der Stack (insbesondere CanSM und CanIf) etwaige Mindestwartezeiten über synchrone Delays oder State-Machine-Polling/Timer abfangen, bevor CAN-Controller-Aktivitäten (Baudraten-Sync, Tx-Mailbox-Freigabe) gestartet werden.
• DIO-Kanal-Konfiguration: Der CanTrcv muss im BSW-Konfigurator (CanTrcvDioChannelAccess) auf exakt die symbolischen DIO-Kanal-Namen konfiguriert werden, die im MCAL-DIO-Container deklariert sind. Jeder Mode-Wechsel erfordert die korrekte Wahrheitstabelle für die Steuerpins (z. B. Mode-Pins M_0, M_1 bzw. $EN, \overline{NSTB}$).
• Fehler im AUTOSAR-Standard: Die Beschriftung des Hardware-Akteurs als «Peripheral» ETH Hardware (PHY) ist ein redaktioneller Artefakt im Standard (Copy-Paste aus der Ethernet-Transceiver-Spezifikation); die Implementierung steuert ausschließlich den CAN-Transceiver-Baustein an.