Figure 10: Possible links between NSduId and LSduId

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm (cd Data Model) zur Spezifikation des statischen Daten- und Metamodells im CAN Transport Layer.
• Architektur-Kontext: AUTOSAR Classic Platform, BSW-Modul CanTp (gemäß AUTOSAR_SWS_CANTransportLayer, Release R4.0.3, basierend auf ISO 15765-2).
• Technischer Zweck: Definition der strukturellen Abbildung zwischen logischen Transportprotokoll-Dateneinheiten der oberen Schichten (PduR, Dcm) und den physischen CAN-Frames der Sicherungsschicht (CanIf). Es formalisiert die Entkopplung und Kardinalitäten von Service Data Units (SDUs), Identifiern und Adressierungsinformationen (N_AI).

2. Komponenten, Entitäten & Schnittstellen

• Entitäten des Data Models:
  • N-SDU (Network Layer Service Data Unit): Zu übertragende Gesamtnutzlast (z. B. Diagnosenachricht oder segmentierte I-PDU) zwischen CanTp und oberen Schichten (PduR/Dcm).
  • NSduId (PduIdType): Konfigurierter, eindeutiger Identifikator der N-SDU an der oberen Modulschnittstelle.
  • N_AI (Network Address Information): Vollständige ISO 15765-2 Adressierungsinformation (bestehend aus Quelladresse N_SA, Zieladresse N_TA, Adresserweiterung N_AE und Adressierungsformat N_TAtype).
  • N_TA (Network Target Address): Logische Zieladresse des Übertragungsknotens.
  • N_AE (Network Address Extension): Erweiterte Adressinformation für Remote-Diagnose oder mixed-addressing Formate.
  • LSduId (PduIdType): Identifikator der Sicherungsschicht-PDU zur Referenzierung der CAN-Mailbox/PDU im CanIf.
  • L-SDU (Link Layer Service Data Unit): Einzelner CAN-Frame (Payload bis 8 Byte nach CAN 2.0 bzw. bis 64 Byte nach CAN FD) auf Treiberebene.
  • SF (Single Frame), FF (First Frame), CF (Consecutive Frame), FC (Flow Control): Konkrete Spezialisierungen der L-SDU gemäß ISO 15765-2 Protocol Control Information (N_PCI).
• Beziehungen und Kardinalitäten:
  • N-SDU [1] — [1] NSduId: 1:1-Assoziation; jede logische Nutzlast ist genau einer PDU-ID zugeordnet.
  • NSduId [1] — [1] N_AI: 1:1-Assoziation; jede N-SDU-Instanz besitzt genau eine definierte Adressierungskonfiguration.
  • N_AI [1] ◆— [0..1] N_TA: Komposition; N_TA existiert optional abhängig vom Adressierungsmodus (z. B. erforderlich bei Extended oder Mixed Addressing, entfällt bei Standard Addressing).
  • N_AI [1] ◆— [0..1] N_AE: Komposition; N_AE existiert nur bei konfiguriertem Mixed 11-Bit oder Mixed 29-Bit Addressing.
  • N_AI [1] ◆— [1..*] LSduId: Komposition; eine logische Verbindung adressiert mindestens eine (unsegmentiert/unidirektional) oder mehrere (segmentiert mit Flow Control) physische L-SDUs.
  • LSduId [1] — [1] L-SDU: 1:1-Assoziation zwischen PDU-ID und Frame-Instanz.
  • Vererbung (L-SDU △— {FC, SF, FF, CF}): Generalisierung/Spezialisierung; alle vier CAN-TP-Pakettypen sind Ausprägungen einer generischen L-SDU.
• Integritätsbedingungen (Constraints):
  • SF, FF und CF teilen sich zwingend dieselbe LSduId (Nutzdatenpfad der Übertragung).
  • FC nutzt zwingend eine andere, separate LSduId (Gegenrichtung für Quittierung und Flow Control).

3. Dynamisches Verhalten & Sequenzablauf

• Tx-Szenario (Segmentierte Übertragung):
  1. Trigger über CanTp_Transmit(NSduId, PduInfoPtr): Auflösung von NSduId zu N_AI.
  2. Abhängig von der Gesamtlänge serialisiert CanTp die Daten als SF oder leitet die Segmentierung via FF ein.
  3. Senden von FF über die Daten-LSduId mittels CanIf_Transmit(Data_LSduId, ...).
  4. Empfang des Gegenstellen-Status via CanTp_RxIndication(FC_LSduId, ...): Parsen der FC-Parameter (FS, BS, STmin).
  5. Asynchroner Versand der Folgepakete CF über dieselbe Daten-LSduId unter Einhaltung des STmin-Timers bis zum Abschluss oder BS-Intervall.
• Rx-Szenario (Segmentierter Empfang):
  1. Empfang von FF via CanTp_RxIndication(Data_LSduId, ...).
  2. Allokation des oberen Puffers via PduR_CanTpStartOfReception(...).
  3. Generierung und Versand des FC-Frames über die separate FC_LSduId via CanIf_Transmit(FC_LSduId, ...).
  4. Sukzessiver Empfang der CF-Frames über die Daten-LSduId.
• Fehler- und Abbruchbedingungen:
  • Timeout-Überwachung der Protokoll-Timer (N_As, N_Ar, N_Bs, N_Br, N_Cs, N_Cr).
  • Nichterfüllung der PDU-Zuordnung führt zur Meldung von CANTP_E_INVALID_RX_ID bzw. CANTP_E_INVALID_TX_ID an das Default Error Tracer Modul (Det).

4. Normative Relevanz & Entwickler-Hinweise

• AUTOSAR BSW-Konfiguration (ECUC-Parametrierung in CanTp):
  • Für jeden Vollduplex- oder segmentierten Halbduplex-Kanal müssen in CanTpConfig zwei separate PDU-Referenzen konfiguriert werden:
    • Tx-Kanal: CanTpTxNPdu (Referenz auf CanIfTxPdu für SF/FF/CF) und CanTpRxFcNPdu (Referenz auf CanIfRxPdu für FC).
    • Rx-Kanal: CanTpRxNPdu (Referenz auf CanIfRxPdu für SF/FF/CF) und CanTpTxFcNPdu (Referenz auf CanIfTxPdu für FC).
• Adressierungsmodi (CanTpAddressingFormat):
  • CANTP_STANDARD: CAN-ID transportiert Adressierung implizit; N_TA und N_AE sind inaktiv, Nutzlast im ersten Frame-Byte beginnt direkt mit N_PCI.
  • CANTP_EXTENDED / CANTP_MIXED: Erstes Datenbyte der L-SDU wird für N_TA bzw. N_AE reserviert. Dies reduziert die nutzbare Single-Frame-Payload von 7 auf 6 Bytes (CAN 2.0) und verschiebt die N_PCI-Dekodierung im Treiber/Stack um 1 Byte.
• CanIf-Demultiplexing:
  • Das Modul CanIf unterscheidet CAN-Frames rein über CAN-ID / Mailbox-Konfiguration und übergibt die vorkonfigurierte LSduId. Der CanTp-Parser muss SF, FF und CF anhand des N_PCI-Nibbles innerhalb derselben LSduId trennen; FC darf niemals auf der Daten-LSduId signalisiert werden.