Figure 2: CAN Transport Layer interactions

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Schichtenmodell und PDU-Transformationsdiagramm (OSI Layer 3/4 Transport-/Netzwerk-Interaktionsmodell gemäß ISO 15765-2 / AUTOSAR ComStack).
• Technischer Zweck: Visualisierung der horizontalen Peer-to-Peer-Kommunikation und vertikalen Dienstschnittstellen des CAN Transport Layers (CanTp). Dargestellt wird die Transformation und Kapselung von Service Data Units (SDUs) zu Protocol Data Units (PDUs) zwischen PDU Router (PduR), CanTp, CAN Interface (CanIf) und dem physikalischen CAN-Bus.
• Funktionale Einordnung: Kapselung oberer Schichten (DCM, COM) vor den Limitierungen der klassischen CAN-Frame-Größe (max. 8 Byte Nutzdaten in AUTOSAR R4.0.3) durch Segmentierung, Reassemblierung und Flusssteuerung.

2. Komponenten, Entitäten & Schnittstellen

• Module / Schichten:
  • PduR (PDU Router): Übergelagerte Routing-Instanz; Quelle (Tx) bzw. Senke (Rx) unsegmentierter Nachrichten.
  • CanTp (CAN Transport Layer): Transportprotokoll-Engine nach ISO 15765-2; zuständig für Segmentierung, Session-Handling, Flusssteuerung und Reassemblierung.
  • CanIf (CAN Interface): Unterlagerte Hardware-Abstraktionsschicht für CAN-Controller und Transceiver.
• Dateneinheiten (SDUs & PDUs):
  • N-SDU (Network Service Data Unit): Vollständige, zusammenhängende Anwendungs- bzw. Diagnosenachricht (Payload zwischen PduR und CanTp, z. B. bis zu 4095 Bytes für ISO 15765-2).
  • N-PCI (Network Protocol Control Information): Protokollsteuerdaten des Transport-Layers (1 bis 3 Bytes Header für SF, FF, CF oder FC inkl. Längen- und Flusssteuerungsinformationen).
  • N-PDU (Network Protocol Data Unit): Horizontale PDU zwischen Sender- und Empfänger-CanTp. Entsteht durch Konkatenation von N-PCI und Daten-Payload (N-SDU-Fragment).
  • L-SDU (Data Link Layer Service Data Unit): Vertikale Dienstdateneinheit an der Schnittstelle CanTp ↔ CanIf. Aus Sicht des CanIf ist die übergebene L-SDU identisch mit der transportierten N-PDU.
• Schnittstellen-Beziehungen:
  • Vertikal: Dienstaufrufe und Callbacks zwischen PduR ↔ CanTp sowie CanTp ↔ CanIf.
  • Horizontal: Logische Peer-to-Peer-Verbindung via N-PDU (symbolisiert durch die strichpunktierte Linie zwischen den CanTp-Instanzen).

3. Dynamisches Verhalten & Sequenzablauf

• Senderpfad (Tx / Downlink, links):
  1. PduR stößt die Übertragung einer N-SDU via CanTp_Transmit() an.
  2. CanTp analysiert die Gesamtlänge und generiert die entsprechende N-PCI (Single Frame SF bei ≤ 7 Byte oder First Frame FF bei Multiframe).
  3. CanTp holt Datenfragmente über den PduR-Callback PduR_CanTpCopyTxData() ab und assembliert die N-PDU.
  4. Die N-PDU wird als L-SDU via CanIf_Transmit() an das CanIf übergeben.
  5. Quittierung von CanIf via CanTp_TxConfirmation(). Bei Multiframe folgt das Warten auf Flow Control (FC), danach zyklisches/getriggertes Senden von Consecutive Frames (CF). Nach vollständigem Versand erfolgt PduR_CanTpTxConfirmation().
• Empfängerpfad (Rx / Uplink, rechts):
  1. CanIf empfängt einen CAN-Frame und leitet die L-SDU via CanTp_RxIndication() an CanTp weiter.
  2. CanTp parst die N-PCI:
     • Bei FF oder SF fordert CanTp Puffer über PduR_CanTpStartOfReception() an.
     • Bei Multiframe generiert der Empfänger-CanTp selbstständig FC-Frames (N-PCI: Flow Status, Block Size, STmin) und sendet diese via CanIf_Transmit() zurück.
  3. Die Payload-Fragmente der N-PDU werden sequenziell über PduR_CanTpCopyRxData() in den Puffer des PduR geschrieben.
  4. Nach erfolgreichem Empfang aller Bytes signalisiert CanTp die Fertigstellung via PduR_CanTpRxIndication().
• Abbruchbedingungen & Fehlerpfade:
  • Protokoll-Timeouts nach ISO 15765-2 (N_Ar, N_As, N_Br, N_Bs, N_Cr, N_Cs).
  • Pufferüberlauf oder temporäre Ressourcenverknappung (BUFREQ_E_NOT_OK, BUFREQ_E_OVFL) bei PduR_CanTpStartOfReception() bzw. PduR_CanTpCopyRxData().
  • Sequenzfehler (ungültige Sequence Number in CF) führen zum sofortigen Session-Abbruch und zur Fehlermeldung an DET/DEM.

4. Normative Relevanz & Entwickler-Hinweise

• Keine interne Pufferung der Gesamt-SDU in CanTp:
  • CanTp allokiert keinen statischen Puffer für vollständige N-SDUs. Der Speicher liegt vollständig im PDU Router bzw. den Quellmodulen (z. B. DCM / COM TP-Buffer). Treiber- und Stack-Entwickler müssen sicherstellen, dass PduR_CanTpCopyTxData() und PduR_CanTpCopyRxData() reentrant und deterministisch innerhalb der Task-Kontexte bedient werden.
• Konfigurationsabgleich (Ecuc):
  • Jeder CanTpChannel erfordert die exakte Zuordnung von CanTpRxNSduId / CanTpTxNSduId (Richtung PduR) zu CanTpRxNPduId / CanTpTxNPduId (Richtung CanIf).
  • Fehlkonfigurationen der PDU-IDs an der Schichtgrenze führen zu Fehlleitungen oder Verwerfen im CanIf_RxIndication-Lookup.
• Scheduling und Latenzanforderungen:
  • CanTp_MainFunction() muss mit einer Zykluszeit betrieben werden, die klein genug ist, um das konfigurierte ST_min (Separation Time) und die N_xx-Timeouts präzise einzuhalten (typisch: 1 ms bis 5 ms Task).
• Release-Spezifikum (R4.0.3):
  • In R4.0.3 ist CanTp strikt auf Standard-CAN mit 8-Byte-Frames (CAN 2.0B) ausgelegt. CAN-FD-Unterstützung (Payload bis 64 Byte, veränderte N-PCI-Codierung) ist in diesem Release-Stand normativ noch nicht enthalten.