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, standardisierter Fehlererfassung im Diagnosespeicher (Dem) und der Wiederherstellungsinitiierung (Error Recovery) auf Protokoll- bzw. Applikationsebene (Dcm) im AUTOSAR Classic BSW-Kommunikationsstack (R4.0.3).

2. Komponenten, Entitäten & Schnittstellen

Dargestellte Module nach Architekturschichten:

• System Services:
  • Dem (Diagnostic Event Manager): Fehlerspeicher und Event-Tracking für BSW- und Produktionsfehler.
  • DET (Default Error Tracer): Fangstelle für Entwicklungs- und Konfigurationsfehler (im Pfad nicht 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 → Dem: Direkter Berichtsweg via BSW-Serviceschnittstelle (Dem_SetEventStatus / Dem_ReportErrorStatus).
• 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):
   • Diagnosefehlerspeicher: CanTp meldet das spezifische Diagnose-Event synchron/asynchron an das Dem (z. B. Event-ID parametriert auf CANTP_E_COMM oder herstellerspezifische Fehler-IDs).
   • 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).
• Dem-Event-Mapping:
  • Jeder CanTpTxChannel muss bei aktivierter Fehlerüberwachung mit entsprechenden Dem-Events verknüpft sein (CanTpDemEventParameterRefs). Wird der Fehler im Dem dequalifiziert oder gefiltert, muss sichergestellt sein, dass das Dcm dennoch zwingend über den PduR-Pfad über den Fehlschlag informiert wird.
• 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.