Figure 9.9: Dcm to CanTp PDU transmission

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm für AUTOSAR Classic Platform BSW).
• Technischer Zweck: Spezifikation des standardisierten AUTOSAR Transport-Protokoll-(TP)-Sendepfads für segmentierte I-PDUs zwischen einer oberen Service-Schicht (Dcm), der Vermittlungsschicht (PduR) und der busspezifischen Transportschicht (CanTp).
• Funktionale Einordnung: Dargestellt wird das On-Demand-Pull-Prinzip des AUTOSAR TP-Buffer-Managements. Die Datenhaltung verbleibt im Dcm; CanTp ruft Payload-Fragmente während der Übertragung (z. B. nach Erhalt eines Flow Control Frames) sukzessive ab, ohne dass PduR oder CanTp den gesamten diagnostischen Datensatz puffern müssen.

2. Komponenten, Entitäten & Schnittstellen

Module / Akteure («module»)

• Dcm (Diagnostic Communication Manager): Obere Schicht (Upper Layer TP-User). Stellt Diagnosedaten bereit und verwaltet den linearen TX-Puffer.
• PduR (PDU Router): Stateless/Passthrough-Router für TP-Verbindungen. Übersetzt modulübergreifende PDU-IDs (1:1-Routing zwischen oberer und unterer Schicht).
• CanTp (CAN Transport Layer): Untere Schicht (Lower Layer TP-Provider). Führt Segmentierung (ISO 15765-2), Flow-Control-Auswertung und Frame-Timing (N_As, N_Bs, N_Cs) durch.

Schnittstellen & Datentypen

• Trigger-Interface:
  • PduR_<User:Up>Transmit(id, info) (konkret instanziiert als PduR_DcmTransmit): Initialer Sendeanstoß.
  • CanTp_Transmit(id, info): Übergabe der Gesamtlänge (info->SduLength) an CanTp; info->SduDataPtr ist hierbei typischerweise NULL_PTR (da TP-Daten erst via CopyTxData gepuffert werden).
  • Return: Std_ReturnType (E_OK / E_NOT_OK).
• Data-Provisioning-Interface (Streaming-Pull):
  • PduR_CanTpCopyTxData(...) → Dcm_CopyTxData(...):
    • id: PduIdType (modulspezifisch gemappt).
    • const PduInfoType*: Zielpuffer der CanTp (SduDataPtr) und angeforderte Segmentlänge (SduLength).
    • RetryInfoType*: Steuerung für Segment-Wiederholungen (TP_DATACONF, TP_DATARETRY).
    • PduLengthType*: Rückgabe der im Dcm verbleibenden Restdatenlänge.
    • Return: BufReq_ReturnType (BUFREQ_OK, BUFREQ_E_BUSY, BUFREQ_E_NOT_OK).
• Confirmation-Interface:
  • PduR_CanTpTxConfirmation(id, result) → Dcm_TpTxConfirmation(id, result):
    • result: Std_ReturnType (E_OK bei erfolgreicher Zustellung aller Frames inklusive Bestätigung, E_NOT_OK bei Timeout wie N_Ar/N_As-Verletzung oder abortiertem Flow Control).

3. Dynamisches Verhalten & Sequenzablauf

1. Sendeinitiierung (Synchron):
   • Dcm ruft synchron PduR_<User:Up>Transmit() auf.
   • PduR mappt die Dcm-TX-PduId auf die Ziel-CanTp-PduId und ruft synchron CanTp_Transmit() auf.
   • CanTp reserviert einen internen TX-Kanal (N-PDU-Verbindungskontext) und gibt sofort E_OK synchron über PduR an Dcm zurück.
2. Segmentiertes Kopieren der Nutzdaten (Asynchron / Event-getrieben):
   • Sobald CanTp sendebereit ist (z. B. nach Versand des First Frame [FF] und Empfang des Flow Control [FC] Continue-to-Send):
   • CanTp ruft PduR_CanTpCopyTxData() auf.
   • PduR leitet den Aufruf direkt an Dcm_CopyTxData() weiter.
   • Dcm kopiert die angeforderte Bytezahl (copy data()) in den von CanTp bereitgestellten Buffer und aktualisiert den Zeiger sowie die Restlänge (PduLengthType*).
   • Dcm_CopyTxData() kehrt mit BUFREQ_OK zurück; PduR reicht dies an CanTp durch.
   • Dieser Schritt wiederholt sich zyklisch für jedes folgende Consecutive Frame (CF) bis zum vollständigen Transfer der PDU.
3. Abschlussbestätigung (Asynchroner Callback):
   • Nach erfolgreicher Übertragung des letzten Segments (und Erhalt der CAN-Treiber-Bestätigung) ruft CanTp PduR_CanTpTxConfirmation() auf.
   • PduR leitet an Dcm_TpTxConfirmation(PduId, E_OK) weiter.
   • Dcm gibt die Diagnose-TX-Session bzw. den internen Puffer frei.

4. Normative Relevanz & Entwickler-Hinweise

• Pufferverwaltung & Reentrancy:
  • Dcm muss den TX-Puffer zwischen PduR_<User:Up>Transmit() und Dcm_TpTxConfirmation() zwingend sperren; eine vorzeitige Modifikation korrumpiert die CAN-Frames.
  • Dcm_CopyTxData() wird aus dem Kontext der CanTp (häufig Task- oder Interrupt-Ebene) aufgerufen. Die Implementierung muss reentrant sein und darf keine blockierenden Operationen enthalten.
• Fehlerbehandlung:
  • Gibt Dcm_CopyTxData() BUFREQ_E_BUSY zurück, muss CanTp den Übertragungsversuch entsprechend dem parametrierten Timeout pausieren.
  • Bei BUFREQ_E_NOT_OK bricht CanTp die Übertragung sofort ab, sendet kein weiteres CF und signalisiert Dcm_TpTxConfirmation(..., E_NOT_OK).
• Retry-Semantik (RetryInfoType):
  • Dcm unterstützt im AUTOSAR-Standard in der Regel keine Datenwiederholung (TP_DATARETRY). Der Parameter wird i. d. R. mit TpDataState = TP_DATACONF betrieben.
• Konfigurationsbindung (ARXML / BSW-Generierung):
  • Im PduR muss ein PduRRoutingPath mit PduRSrcPdu (Referenz auf Dcm) und PduRDestPdu (Referenz auf CanTp) definiert sein.
  • Das API-Mapping erfolgt über statischen Code/Makros (PduR_CanTp.h, PduR_Dcm.h); PduR arbeitet als reine Zero-Overhead-Routing-Schicht ohne eigene TP-Payload-Pufferung.