Figure 7.8: PDU channel mode control

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Hierarchischer UML-Zustandsautomat (State Machine Diagram) mit Composite State (Superstate OFFLINE) und orthogonal/flach strukturierten Substates.
• Architektur-Kontext:
  • Modul: CAN Interface (CanIf), AUTOSAR Classic Platform (ECU Abstraction Layer / Communication Services).
  • Funktionale Einordnung: Verwaltung der Betriebszustände logischer CAN-PDU-Kanäle (CanIf_PduChannelModeType).
  • Zweck: Granulare, softwareseitige Steuerung der Sende- und Empfangspfade (Tx/Rx) logischer Kommunikationskanäle unabhängig vom physikalischen Zustand des CAN-Controllers (Can_ControllerStateType).

2. Komponenten, Entitäten & Schnittstellen

• Zustände und Pseudo-Zustände:
  • Initial Pseudostate (Schwarzer Kreis): Eintrittspunkt nach Modulinitialisierung (CanIf_Init).
  • Superstate OFFLINE: Hierarchischer Überzustand für alle Modi mit eingeschränkter Sendefunktion. Beinhaltet drei Substates:
    • Offline (CANIF_OFFLINE): Standardzustand; vollständige Deaktivierung aller Sende- und Empfangsaktivitäten.
    • Passive (CANIF_TX_OFFLINE): Listen-Only-Modus; Empfangspfad aktiv, Sendepfad blockiert.
    • Active (CANIF_TX_OFFLINE_ACTIVE): Simulierter Sendemodus; Empfangspfad aktiv, Sendeoperationen werden intern bestätigt, ohne physisch auf den Bus gesendet zu werden.
  • Zustand ONLINE (CANIF_ONLINE): Vollständiger bidirektionaler Kommunikationsmodus (Tx und Rx uneingeschränkt aktiv).
• Relevante Datentypen & Schnittstellen (API):
  • CanIf_PduModeType / CanIf_PduChannelModeType: Enum der Kanalbetriebsarten (CANIF_OFFLINE, CANIF_TX_OFFLINE, CANIF_TX_OFFLINE_ACTIVE, CANIF_ONLINE).
  • CanIf_SetPduMode(): Steuerungsschnittstelle, typischerweise aufgerufen durch den CAN State Manager (CanSM).
  • CanIf_GetPduMode(): Abfrageschnittstelle des aktuellen Kanalmodus.
  • Obere Schichten (Upper Layers): PduR, CanTp, CanNm, J1939Tp, Xcp.
  • Untere Schicht (Lower Layer): CanDrv (Can_Write).

3. Dynamisches Verhalten & Sequenzablauf

• Initialisierungssequenz:
  • Mit Aufruf von CanIf_Init() wechselt jeder PDU-Kanal deterministisch über den Initialübergang in den Subzustand Offline (CANIF_OFFLINE, [SWS_CANIF_00864]).
• Transitionen & Trigger:
  • Innerhalb des Superstates OFFLINE: Vollständige bidirektionale Übergänge zwischen den Substates (Offline ↔ Passive, Offline ↔ Active, Passive ↔ Active). Getriggert durch gezielte Anforderungen via CanIf_SetPduMode().
  • Zwischen OFFLINE und ONLINE:
    • Eintritt in ONLINE: Von jedem der drei Offline-Substates aus möglich, sofern der zugrunde liegende CAN-Controller im Zustand CAN_CS_STARTED ist.
    • Austritt aus ONLINE: Führt zurück in den Superstate OFFLINE (Zielsubstate abhängig vom Parameter in CanIf_SetPduMode()).
  • Controller-Zustandsänderung:
    • Wird CanIf_SetControllerMode(ControllerId, CAN_CS_SLEEP) ausgeführt, erzwingt das CanIf für den betroffenen Kanal synchron den Übergang nach CANIF_OFFLINE ([SWS_CANIF_00865]).
• Kanalverhalten pro Modus:
  • CANIF_OFFLINE ([SWS_CANIF_00073]):
    • Transmit-Requests (CanIf_Transmit()) werden sofort mit E_NOT_OK abgewiesen.
    • Alle zugehörigen Tx-Puffer im CanIf werden vollständig gelöscht.
    • Rx-Indication-Callbacks (<User_RxIndication>) an obere Schichten werden unterdrückt.
    • Tx-Confirmation-Callbacks (<User_TxConfirmation>) an obere Schichten werden unterdrückt.
  • CANIF_TX_OFFLINE (Passive):
    • Rx-Pfad ist aktiv: Eingehende Frames via CanIf_RxIndication() werden an die oberen Schichten gemeldet.
    • Tx-Pfad ist inaktiv: CanIf_Transmit() wird blockiert bzw. abgewiesen.
  • CANIF_TX_OFFLINE_ACTIVE (Active):
    • Rx-Pfad ist aktiv.
    • Tx-Pfad ist simuliert: CanIf_Transmit() wird akzeptiert (E_OK); die PDU wird nicht an den CanDrv (Can_Write()) weitergereicht, jedoch meldet das CanIf die erfolgreiche Übertragung via <User_TxConfirmation> an die oberen Schichten zurück.
  • CANIF_ONLINE:
    • Voller Kommunikationsbetrieb: Weiterleitung von Tx-Anfragen an den Treiber und Weiterleitung aller Rx-Indikationen/Tx-Bestätigungen an die Upper Layers.

4. Normative Relevanz & Entwickler-Hinweise

• Puffer-Bereinigung & Determinismus:
  • Beim Wechsel in CANIF_OFFLINE werden Puffer synchron verworfen ([SWS_CANIF_00073]). Entwickler müssen beachten, dass beim Re-Aktivieren (CANIF_ONLINE) keine Alt-PDUs verbleiben; gepufferte Daten gehen verloren.
• Fehlerbehandlung in oberen Schichten (Com, PduR):
  • Sendeschichten müssen den synchronen Rückgabewert E_NOT_OK bei CanIf_Transmit() verarbeiten, wenn sich ein Kanal in CANIF_OFFLINE oder CANIF_TX_OFFLINE befindet.
• Verwendungszweck CANIF_TX_OFFLINE (Passive):
  • Einsatz bei Diagnoseabläufen (z. B. UDS Service 0x28 CommunicationControl), Flashen über Bootloader/Software-Updates oder während Bus-Off-Recovery-Sequenzen, um Silent-Monitoring ohne Bus-Interferenz zu gewährleisten.
• Verwendungszweck CANIF_TX_OFFLINE_ACTIVE (Active):
  • Spezieller Modus zur Validierung, Software-in-the-Loop (SiL) oder End-of-Line (EOL)-Prüfungen. Verhindert Buslast, erlaubt jedoch das Ausführen von Upper-Layer-Zustandsautomaten, die auf Tx-Bestätigungen angewiesen sind (z. B. Timeouts in Com).
• Kopplung Controller- vs. PDU-Modus:
  • Der PDU-Modus ist eine logische Filterschicht. Ein Umschalten auf CANIF_ONLINE hat keine Wirkung auf den Bus, wenn der CAN-Controller nicht in CAN_CS_STARTED ist. Umgekehrt schlägt ein Senden bei CAN_CS_STARTED fehl, wenn der PDU-Modus in OFFLINE verharrt.