Figure 13: Network shutdown (CAN)

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.x Sequenzdiagramm (Interaktionsdiagramm) mit kombinierten Fragmenten (alt).
• Technischer Zweck: Spezifikation des geregelten Netzwerk-Shutdowns eines CAN-Kanals im AUTOSAR Classic Platform Communication Stack (AUTOSAR_SWS_COMManager, R4.0.3, Figure 11).
• Funktionale Einordnung: Dargestellt wird die koordinierte Deaktivierung der Kommunikation von COMM_FULL_COMMUNICATION über den Zwischenzustand COMM_SILENT_COMMUNICATION bis zur vollständigen Busruhe (COMM_NO_COMMUNICATION). Der ComM fungiert als Bindeglied zwischen Applikationsanforderungen (RTE/SW-C), Diagnose (Dcm), generischem Netzwerkmanagement (Nm), busspezifischem State Manager (CanSM) sowie dem ECU- und Mode-Management (EcuM/BswM).

2. Komponenten, Entitäten & Schnittstellen

Akteure & Module (Lifelines)

• «module» ComM: Zentraler Koordinator der Kommunikationsmodi (Kanal- und User-Zustände).
• «module» EcuM: ECU State Manager (Überwachung der Steuergeräte-Betriebsphase).
• «module» Dcm: Diagnostic Communication Manager (Überwachung/Freigabe aktiver Diagnosesitzungen).
• «module» BswM: Basic Software Mode Manager (Zentrale Regelauswertung und Moduskoordination).
• «module» Rte: Runtime Environment (Propagierung von Modusänderungen an Applikations-SW-Cs).
• VehicleModeManager: Applikative SW-C / Flotten-Zustandsmanager (stellt Kommunikationsanfragen).
• «module» Nm: Network Management Interface (Abstraktion der Zustände Network Mode, Prepare Bus-Sleep, Bus-Sleep).
• «module» CanSM: CAN State Manager (Steuerung des CAN-spezifischen Controllers/Transceivers via CanIf).

Schnittstellen & Interaktionsmuster

• Mode-Request-APIs (Client → ComM):
  • ComM_RequestComMode(User, COMM_NO_COMMUNICATION)
  • ComM_LimitChannelToNoComMode(Channel, Status:=TRUE)
• NM-Steuerung & Callbacks (ComM ↔ Nm):
  • Nm_NetworkRelease(NetworkHandle): Synchrone Freigabe des Netzwerks durch den ComM.
  • ComM_Nm_PrepareBusSleepMode(Channel): Asynchroner NM-Callback bei Eintritt in Prepare Bus-Sleep.
  • ComM_Nm_BusSleepMode(Channel): Asynchroner NM-Callback bei Eintritt in Bus-Sleep.
• Bus-SM-Steuerung & Bestätigung (ComM ↔ CanSM):
  • CanSM_RequestComMode(NetworkHandle, ComM_Mode): Modusanforderung an den CAN-Zustandsautomaten.
  • ComM_BusSM_ModeIndication(NetworkHandle, ComM_Mode): Asynchrone Vollzugsmeldung des CanSM an den ComM.
• Modus-Notifikationen (ComM → BSW / Applikation):
  • Rte_Ports_UserMode_P()[n].Switch_currentMode(...): RTE Mode Switch Notification.
  • BswM_ComM_CurrentMode(Network, ComM_Mode): Modus-Indikation an die BswM-Zustandsmaschine.
  • Dcm_ComM_SilentComModeEntered(uint8) / Dcm_ComM_NoComModeEntered(uint8): Statussynchronisation mit dem Diagnose-Stack.

3. Dynamisches Verhalten & Sequenzablauf

Phase 1: Initiierung des Shutdowns (alt Shutdown initiation)

• Pfad A (Regulärer Release): Letzter ComM-User entzieht Kommunikationsanforderung (ComM_RequestComMode(..., COMM_NO_COMMUNICATION)). Vorbedingung: Keine weiteren User fordern COMM_FULL_COMMUNICATION an und Dcm meldet keine aktive Diagnose (no DCM ActiveDiagnostics).
• Pfad B (Forciertes Herunterfahren): Aufruf von ComM_LimitChannelToNoComMode(Channel, TRUE) (z. B. bei Unterspannung oder durch den VehicleModeManager).

Phase 2: Freigabe des Bus-Netzwerkmanagements

1. ComM vollzieht internen Zustandswechsel: Switch to SUBS_COMM_READY_SLEEP state().
2. ComM ruft synchron Nm_NetworkRelease(NetworkHandle) auf; Nm quittiert mit E_OK.

Phase 3: Übergang nach COMM_SILENT_COMMUNICATION

1. Trigger: Nm-Timer läuft ab; Nm ruft ComM_Nm_PrepareBusSleepMode(Channel) auf.
2. ComM schaltet intern auf COMM_SILENT_COMMUNICATION.
3. ComM weist CanSM an: CanSM_RequestComMode(NetworkHandle, COMM_SILENT_COMMUNICATION).
4. ComM benachrichtigt parallel:
   • RTE: Rte_Ports_UserMode_P()[n].Switch_currentMode(RTE_MODE_ComModes_SILENT_COMMUNICATION).
   • BswM: BswM_ComM_CurrentMode(Network, COMM_SILENT_COMMUNICATION).
   • Dcm: Dcm_ComM_SilentComModeEntered(uint8).

Phase 4: Übergang nach COMM_NO_COMMUNICATION

1. Trigger: Nm meldet Busruhe via Callback ComM_Nm_BusSleepMode(Channel).
2. ComM wechselt intern auf COMM_NO_COMMUNICATION.
3. ComM fordert beim CanSM Modus COMM_NO_COMMUNICATION an (CanSM_RequestComMode).
4. Asynchrone Quittierung: CanSM signalisiert den vollzogenen Zustand über den Callback ComM_BusSM_ModeIndication(NetworkHandle, COMM_NO_COMMUNICATION).
5. ComM aktualisiert die Systemumgebung:
   • RTE: Switch_currentMode(RTE_MODE_ComModes_NO_COMMUNICATION).
   • BswM: BswM_ComM_CurrentMode(Network, COMM_NO_COMMUNICATION).
   • Dcm: Dcm_ComM_NoComModeEntered(uint8).

Phase 5: ECU-Shutdown-Entscheidung (Architektur-Hinweis laut Diagramm-Notiz)

• EcuM-Flex: BswM wertet die BswM_ComM_RequestMode()-Indikationen aus, um den zulässigen Zeitpunkt für das Herunterfahren des Steuergeräts zu bestimmen.

4. Normative Relevanz & Entwickler-Hinweise

• Entkopplung Applikation / Hardware: SW-Cs dürfen den CanSM niemals direkt ansprechen. Alle Netzanforderungen müssen über User-Mappings im ComM laufen; die tatsächliche Busabschaltung hängt zwingend von den Timern des CAN-NM ab.
• Bedeutung von COMM_SILENT_COMMUNICATION: In diesem Zwischenzustand (während Prepare Bus-Sleep) ist das Senden von Botschaften im CAN-Treiber/CanIf gesperrt, der Empfang bleibt aktiv (Vermeidung von Busfehlern durch noch sendende Knoten).
• Asynchronitäts-Falle: CanSM_RequestComMode quittiert den Aufruf synchron lediglich mit E_OK (Anforderung akzeptiert). Der ComM darf den Wechsel nach COMM_NO_COMMUNICATION erst nach Eintreffen von ComM_BusSM_ModeIndication() als abgeschlossen werten und an RTE/BswM melden.
• Diagnose-Blockade: Eine aktive Diagnosesitzung (Dcm ActiveDiagnostics) sperrt den Übergang in SUBS_COMM_READY_SLEEP. Der Netzwerk-Shutdown bleibt blockiert, bis der Dcm die Diagnoseverbindung freigibt.
• Protokollneutralität: Die gezeigte Sequenz ist prototypisch für CAN, gilt laut AUTOSAR-Spezifikation aber strukturell identisch für LIN, FlexRay und Ethernet (unter Verwendung des jeweiligen Bus State Managers LinSM, FrSM, EthSM).