Figure 9.4: CanTp to Dcm TP PDU reception

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm mit synchronen Funktionsaufrufen und Rückgabewerten).
• Architektur-Kontext: AUTOSAR Classic Platform (CP), Schichtenmodell der Basissoftware (BSW). Dargestellt ist das TP-basierte Routing (Transport Protocol) für segmentierte Diagnose- und Kommunikationsdaten (Large SDUs) von der Kommunikations-Treiberschicht (CanTp) über den zentralen Router (PduR) zum Diagnose-Kommunikationsmanager (Dcm).
• Funktionale Einordnung: Veranschaulicht den 1:1-Direktdurchlauf eines segmentierten I-PDU-Empfangs über Transportprotokoll-Schnittstellen ohne Gateway-Zwischenpufferung (Upper Layer = Dcm).

2. Komponenten, Entitäten & Schnittstellen

• Beteiligte BSW-Module (Akteure / Lifelines):
  • «module» CanTp: Transport-Layer-Modul für CAN (ISO 15765-2), zuständig für Segmentierung, Reassemblierung und Flow Control.
  • «module» PduR: PDU Router, agiert hier als zustandsloser/zustandsarmer Vermittler (Zero-Cost-/Routing-Schicht) und übersetzt CanTp-spezifische API-Signaturen in generische obere TP-Schnittstellen.
  • «module» Dcm: Diagnosesteuergerät (UDS / OBD), Endempfänger der reassemblierten Diagnosenachricht; stellt den linearen Empfangspuffer bereit.
• Schnittstellen & Funktionssignaturen (AUTOSAR TP API):
  • StartOfReception:
    • PduR_CanTpStartOfReception(id, info, TpSduLength, bufferSizePtr) → Dcm_StartOfReception(id, info, TpSduLength, bufferSizePtr)
    • Rückgabetyp: BufReq_ReturnType (BUFREQ_OK, BUFREQ_E_NOT_OK, BUFREQ_E_OVFL, BUFREQ_E_BUSY).
  • CopyRxData:
    • PduR_CanTpCopyRxData(id, info, bufferSizePtr) → Dcm_CopyRxData(id, info, bufferSizePtr)
    • Rückgabetyp: BufReq_ReturnType.
  • RxIndication:
    • PduR_CanTpRxIndication(id, result) → Dcm_TpRxIndication(id, result)
    • Rückgabetyp: void bzw. Statusübergabe via Std_ReturnType (E_OK, E_NOT_OK).
• Datenstrukturen:
  • PduIdType: Identifikator der I-PDU (ID-Mapping zwischen CanTp-Rx-PDU-ID und Dcm-Rx-PDU-ID via PduR-Routing-Table).
  • PduInfoType*: Zeiger auf Puffer (SduDataPtr) und Nutzdatenlänge (SduLength).
  • PduLengthType: Gesamtlänge der Nachricht bzw. verbleibende Puffergröße.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung / Pufferanforderung (StartOfReception):
   • Trigger: CanTp empfängt einen Single Frame (SF) oder First Frame (FF).
   • Aufruf: PduR_CanTpStartOfReception wird synchron durch CanTp aufgerufen. PduR mappt die PduIdType auf die Ziel-PDU des Dcm und ruft synchron Dcm_StartOfReception auf.
   • Dcm reserviert den linearen Diagnosepuffer anhand von TpSduLength und gibt BUFREQ_OK zusammen mit der verfügbaren Puffergröße (bufferSizePtr) zurück.
   • Rückmeldung propagiert synchron zurück an CanTp. Bei positivem Status sendet CanTp den Flow Control Frame (FC-CTS).
2. Segmentierte Datenübertragung (CopyRxData-Schleife):
   • Trigger: CanTp empfängt aufeinanderfolgende Consecutive Frames (CF) bzw. Datenbytes aus dem SF/FF.
   • Schleife (im Diagramm dreifach dargestellt für aufeinanderfolgende CFs):
     1. CanTp ruft synchron PduR_CanTpCopyRxData(...) auf.
     2. PduR leitet direkt an Dcm_CopyRxData(...) weiter.
     3. Lokale Aktion im Dcm: copy data() kopiert die Nutzdaten (info->SduDataPtr) in den Ziel-Diagnosepuffer und dekrementiert die verbleibende Puffergröße (bufferSizePtr).
     4. Dcm liefert BUFREQ_OK und aktualisierte Restpuffergröße synchron zurück an PduR und CanTp.
3. Abschluss & Validierung (RxIndication):
   • Trigger: Alle deklarierten Segmente wurden erfolgreich von CanTp reassembliert und kopiert.
   • Aufruf: CanTp signalisiert den erfolgreichen Abschluss via PduR_CanTpRxIndication(id, E_OK).
   • PduR delegiert synchron an Dcm_TpRxIndication(id, E_OK).
   • Dcm schließt den Empfang ab, startet die Protokoll-/Dienstvalidierung (z. B. UDS Service Handler) und quittiert die Rückkehr synchron über PduR an CanTp.
4. Fehler- und Abbruchpfade (Spezifikationslogik):
   • Gibt Dcm_StartOfReception BUFREQ_E_OVFL zurück, bricht CanTp den Vorgang mit Flow Control Overflow (FC-OVFL) ab.
   • Liefert Dcm_CopyRxData BUFREQ_E_NOT_OK, terminiert CanTp die Übertragung und signalisiert via PduR_CanTpRxIndication(id, E_NOT_OK) den Verbindungsabbruch.

4. Normative Relevanz & Entwickler-Hinweise

• Zero-Buffer-Routing im PduR: Der PDU Router allokiert in diesem TP-Szenario keinen eigenen Zwischenpuffer; er agiert als reine Wrapper-/Routing-Schicht. Das Routing erfolgt synchron im Kontext des CanTp-Interrupts bzw. der CanTp_MainFunction.
• Ausführungs- und Interrupt-Kontext: Da alle Calls synchron kaskadieren (CanTp → PduR → Dcm), darf Dcm_CopyRxData und Dcm_StartOfReception keine blockierenden Operationen, Mutex-Waits oder langwierige Berechnungen enthalten.
• ID-Mapping-Konfiguration (PduR_PBcfg.c / PduR_Cfg.h): Die Zuordnung der Quell-PDU-ID aus CanTp zur Ziel-PDU-ID im Dcm muss im Routing-Pfad (PduRRoutingPath, PduRDestPdu) als 1:1-Direktbeziehung ohne Gateway-FIFO konfiguriert sein (PDUR_DIRECT).
• Puffer-Konsistenz: Der Dcm muss gewährleisten, dass der Puffer zwischen Dcm_StartOfReception und Dcm_TpRxIndication gelockt bleibt und vor nebenläufigen Zugriffen geschützt ist.