Figure 9: Information path for the CAN Transport Protocols errors during transmission

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: AUTOSAR-Schichtenarchitekturmodell (BSW-Stack-Diagramm) mit semantischem Annotations-Overlay für Fehlersignalisierungs- und Kontrollpfade (Detection, Notification, Recovery).
• Technischer Zweck: Spezifikatorische Darstellung der Informations- und Fehlerpropagierungswege bei Übertragungsfehlern im CAN-Transport-Protokoll (CanTp, ISO 15765-2) während der Sendephase (Transmission).
• Funktionale Einordnung: Erläutert die Trennung zwischen Fehlererkennung auf Transportebene, Fehlersignalisierung an den Default Error Tracer (Det) und der Wiederherstellungsinitiierung (Error Recovery) auf Protokoll- bzw. Applikationsebene (Dcm) im AUTOSAR Classic BSW-Kommunikationsstack.

2. Komponenten, Entitäten & Schnittstellen

Dargestellte Module nach Architekturschichten:

• System Services:
  • DET (Default Error Tracer): Benachrichtigungsinstanz (Notification-Ziel); Erfassung von Entwicklungs- und Laufzeitfehlern des BSW-Stacks.
  • DEM (Diagnostic Event Manager): Diagnosespeicher und Event-Tracking für Produktionsfehler (im dargestellten Pfad nicht direkt adressiert).
  • FIM (Function Inhibition Manager): Deaktivierung von Softwarekomponenten basierend auf Dem-Status.
• Communication Services:
  • CanTp (CAN Transport Protocol): Erkennungsinstanz (Detection). Segmentierung, Reassemblierung und Flusssteuerung (ISO 15765-2).
  • PduR (PDU Router): Vermittlungsinstanz für I-PDUs zwischen Transportschicht und Anwendern (Routingpfad).
  • Dcm (Diagnostic Communication Manager): Wiederherstellungsinstanz (Recovery initiator). Zuständig für UDS-Protokoll (ISO 14229-1) und Diagnose-Sitzungsverwaltung.
  • Kontextmodule (nicht im Fehlerpfad aktiv): AUTOSAR COM, IPDU multiplexer (IPduM), Com. Manager (ComM), CAN State Manager (CanSM), Generic NM Interface (Nm), CAN NM (CanNm).
• Communication Hardware Abstraction:
  • CAN Interface (CanIf), CAN Transceiver Driver (CanTrcv), Driver for ext. CAN ASIC.
• Communication & I/O Drivers / Hardware:
  • CAN Driver (Can), SPIHandler Driver, DIO Driver, interner/externer CAN-Controller.

Schnittstellen und funktionale Beziehungen:

• CanTp → DET: Direkter Berichtsweg für Entwicklungs- und Laufzeitfehler (Det_ReportError / Det_ReportRuntimeError).
• CanTp → PduR → Dcm: Aufsteigender Bestätigungspfad über standardisierte PduR-Transportprotokoll-APIs (<User>_TpTxConfirmation).

3. Dynamisches Verhalten & Sequenzablauf

1. Fehlererkennung (Detection - Roter Punkt im CanTp):
   • Das CanTp stellt während der laufenden Übertragung einer segmentierten oder unsegmentierten Botschaft einen Protokoll- oder Timeout-Fehler fest:
     • Überschreitung des Timers N_As (Transmit Confirmation Timeout von CanIf).
     • Überschreitung des Timers N_Bs (Timeout beim Warten auf einen Flow Control Frame).
     • Empfang ungültiger oder unerwarteter Flow-Control-Parameter (z. B. FS = OVFLW, ungültiges BS/STmin, inkonsistente Sequenznummern).
     • Abbruch durch Puffer-Überlauf/Fehlschlag des oberen Puffers (BUFREQ_E_NOT_OK via PduR_CanTpCopyTxData).
     • Erreichen von N_WFTmax (maximale Anzahl aufeinanderfolgender Wait-Frames überschritten).
2. Benachrichtigung (Notification - Rote Pfeile):
   • Fehlerüberwachung (DET): CanTp meldet den erkannten Übertragungs- bzw. Laufzeitfehler an das DET (z. B. via Det_ReportRuntimeError mit Modul- und Fehler-ID wie CANTP_E_COMM).
   • Protokollschicht: CanTp ruft die PDU-Router-Rückruffunktion PduR_CanTpTxConfirmation(PduId, E_NOT_OK) auf. Das PduR leitet den Status transparent an das Dcm weiter (Dcm_TpTxConfirmation(PduId, E_NOT_OK)).
3. Wiederherstellung (Recovery initiator - Grüner Punkt im Dcm):
   • Das Dcm empfängt E_NOT_OK für die laufende Diagnoseantwort.
   • Dcm initiiert den Wiederherstellungsmechanismus gemäß UDS-Spezifikation (ISO 14229-1):
     • Freigabe interner Diagnosepuffer.
     • Zurücksetzen des P2/P2*-Timers bzw. Abbruch der Transaktion.
     • Gegebenenfalls Wechsel in den Default-Session-Zustand bei kritischen Übertragungsabbrüchen.
     • Bereitschaft für neue Request-Anfragen des Testers herstellen.

4. Normative Relevanz & Entwickler-Hinweise

• PduR-Routing-Konfiguration:
  • Das Routing im PduR muss bidirektional konsistent für Tp-Kommunikation zwischen CanTp und Dcm konfiguriert sein (PduRCanTpTxConfirmation mapped auf Dcm_TpTxConfirmation).
• Keine automatische Re-Transmission im CanTp:
  • Das AUTOSAR-CanTp führt bei Übertragungsfehlern auf TP-Ebene keine autonome Wiederholung durch. Die Verantwortung für Re-Transmissions oder Session-Timeouts liegt strikt bei der übergeordneten Instanz (Dcm).
• DET-Fehlerprotokollierung:
  • Da die Signalisierung an das DET gerichtet ist, müssen Entwickler sicherstellen, dass entsprechende Runtime-Error-Hooks im DET konfiguriert sind, um Übertragungsabbrüche im Test- und Feldbetrieb zu erfassen.
• Synchronisationssperren & Pufferfreigabe:
  • Entwickler müssen sicherstellen, dass Dcm bei Erhalt von E_NOT_OK in Dcm_TpTxConfirmation den gesperrten TX-Puffer unmittelbar freigibt, um Pufferlecks bei Kommunikationsstörungen (z. B. Bus-Off oder Kabelbruch) zu verhindern.