DEENESPTFRRUARHIKOZHNL
AUTOSAR_CP_SWS_CANTransportLayer FIG-16c60d1d07ef198e 1053 × 665 px 6 Release(s)

Figure 7.4: Example of transmit process

SHA-256 Inhalts-Fingerabdruck: 16c60d1d07ef198eef0eae812ad8347a56df084d24d9c99cd32ce58c74db1524
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

1. Diagrammtyp & Architektur-Kontext

  • Diagrammtyp: Sequenzdiagramm / Interaktionsdiagramm (vereinfachte UML-Sequenzdarstellung mit Bus-Ereignismarkern).
  • Architektur-Kontext: AUTOSAR Classic Platform (R4.0.3), Communication Stack (ComStack). Dargestellt ist das Zusammenspiel zwischen dem PDU Router (PduR) als oberer Schicht und dem CAN Transport Layer (CanTp, ISO 15765-2) bei einer segmentierten Datentransmission (Payload-Länge = 50 Bytes > 8 Bytes CAN-Frame-Limit). Das Diagramm visualisiert das entkoppelte Pull-Verfahren zur Pufferbereitstellung via CopyTxData bis zum Transmit-Abschluss (TxConfirmation).

2. Komponenten, Entitäten & Schnittstellen

  • Akteure / Module:
    • PduR (PDU Router): Vermittler und Puffer-Koordinator der oberen Schichten (z. B. COM, DCM).
    • CanTp (CAN Transport Layer): Segmentierung, Reassemblierung und Flow-Control nach ISO 15765-2.
    • Untere Schicht / Bus (implizit via Ereignissymbole dargestellt): CanIf / CAN-Treiber / CAN-Bus.
  • Schnittstellen / Service-APIs:
    • CanTp_Transmit(PduIdType TxPduId, const PduInfoType* PduInfoPtr): Initiale synchrone Sendeanforderung durch die obere Schicht (mit Gesamtlänge 50 Bytes).
    • PduR_CanTpCopyTxData(PduIdType TxPduId, const PduInfoType* PduInfoPtr, const RetryInfoType* RetryInfoPtr, PduLengthType* AvailableDataPtr): Callback-Funktion der oberen Schicht. Dient dem bedarfsgesteuerten Kopieren von Segmentdaten in den TP-internen Puffer bzw. direkt zur Frame-Assemblierung.
    • PduR_CanTpTxConfirmation(PduIdType TxPduId, Std_ReturnType result): Asynchrone Abschlussmeldung der Transportsitzung (E_OK / NTFRSLT_OK).
  • Timer & Parameter:
    • N_Cs (Sender-seitiger Timeout): Zeitüberwachung zwischen der Anforderung/Bereitstellung der Daten (CopyTxData) und dem Senden des Consecutive Frames (CF) bzw. Bestätigung der Übertragung.

3. Dynamisches Verhalten & Sequenzablauf

  1. Phase 1 – Initialisierung der Übertragung & First Frame (FF):
    • PduR triggert CanTp_Transmit (PDU-ID, Länge = 50 Byte).
    • CanTp stellt fest, dass Segmentierung nötig ist (> 8 Bytes) und fordert unmittelbar synchron via PduR_CanTpCopyTxData die Nutzdaten für das erste Segment an.
    • CanTp assembliert und sendet das First Frame („Start sending data.“ an CanIf/Bus).
  2. Phase 2 – Flusskontrolle & N_Cs-Überwachung:
    • Nach dem First Frame (und intern empfangenem/ausgewertetem Flow Control Frame, hier abstrahiert) startet die consecutive Übertragungsphase unter Überwachung des ISO-15765-2-Timers N_Cs.
  3. Phase 3 – Segmentierte Übertragung (Consecutive Frames – CF):
    • Vor jedem Aussenden eines Folge-Frames (CF) ruft CanTp erneut PduR_CanTpCopyTxData auf, um die nächsten Bytes inkrementell abzurufen.
    • CanTp versendet den jeweiligen Consecutive Frame („Sending CF“).
    • Dieser Vorgang iteriert (symbolisiert durch die vertikalen Auslassungspunkte), bis alle 50 Bytes vollständig übermittelt wurden.
  4. Phase 4 – Transmit-Bestätigung:
    • Nach erfolgreicher Übertragung und Bestätigung des letzten CF auf dem Bus meldet CanTp den Gesamtabschluss über PduR_CanTpTxConfirmation(id, OK) an den PduR.
    • Die Transport-Session wird in CanTp freigegeben.

4. Normative Relevanz & Entwickler-Hinweise

  • Pull-Mechanismus statt Pre-Buffering: Der Entwickler der oberen Schicht (PduR / Dcm / Com) darf nicht davon ausgehen, dass die gesamten 50 Bytes bei Aufruf von CanTp_Transmit kopiert werden. CanTp fordert Daten häppchenweise exakt dann an, wenn der nächste Frame zur Übertragung ansteht.
  • API-Konformität CopyTxData:
    • Der übergebene Zeiger PduInfoPtr->SduDataPtr muss vom oberen Layer mit genau der Anzahl Bytes befüllt werden, die PduInfoPtr->SduLength anfordert.
    • AvailableDataPtr muss die verbleibende Restdatenmenge im Puffer der oberen Schicht zurückgeben.
    • Wenn der obere Puffer temporär leer ist (BUFREQ_E_BUSY), muss CanTp das Senden anhalten; läuft dabei der Timer N_Cs ab, bricht CanTp die Session mit Fehler ab (PduR_CanTpTxConfirmation(id, E_NOT_OK)).
  • Timing-Restriktion (N_Cs):
    • PduR_CanTpCopyTxData muss deterministisch und mit minimaler Latenz ausgeführt werden (typischerweise im Kontext der CanTp_MainFunction oder eines TxConfirmation-Interrupts), um N_Cs-Timeout-Verletzungen zu verhindern.
  • Reentrancy & Kontext: CanTp_Transmit ist nicht reentrant für dieselbe TxPduId. Der Puffer muss bis zum Eintreffen der PduR_CanTpTxConfirmation gelockt bzw. konsistent gehalten werden.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R20-11 → R21-11 keine inhaltliche Änderung Vorgänger: FIG-ebe9eeb7bdd95511

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Vorkommen in AUTOSAR-Releases (6)

Release Dokument Seite Nr. Bildunterschrift im Dokument
EXTERN AUTOSAR_SWS_CANTransportLayer S. 38 7.4 Figure 7.4: Example of transmit process
R21-11 AUTOSAR_SWS_CANTransportLayer S. 34 7.4 Figure 7.4: Example of transmit process
R22-11 AUTOSAR_SWS_CANTransportLayer S. 38 7.4 Figure 7.4: Example of transmit process
R23-11 AUTOSAR_CP_SWS_CANTransportLayer S. 35 7.4 Figure 7.4: Example of transmit process
R24-11 AUTOSAR_CP_SWS_CANTransportLayer S. 36 7.4 Figure 7.4: Example of transmit process
R25-11 AUTOSAR_CP_SWS_CANTransportLayer S. 36 7.4 Figure 7.4: Example of transmit process