Figure 9: Overview of the callbacks provided by the DCM

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Modulschnittstellen-Diagramm (Stereotyp class DCMCallbacks).
• Funktionale Einordnung: Dargestellt ist die Bereitstellung von Callback-Funktionen (Inbound-Schnittstellen) durch den Diagnostic Communication Manager (Dcm) im Communication Services Layer der AUTOSAR Classic BSW (Release R4.0.3). Das Diagramm definiert die vertikalen Integrationspunkte des DCM zu den Modulen PDU Router (PduR) für das transportprotokollbasierte Diagnosepuffer-Handling sowie Communication Manager (ComM) für die Synchronisation von Netzwerk- und Kommunikationsmodi.

2. Komponenten, Entitäten & Schnittstellen

• BSW-Module:
  • «module» Dcm: Realisierendes Kernmodul für Diagnoseprotokolle (UDS / OBD). Fungiert als Server für PDU- und Modus-Callbacks.
  • «module» _PduR (PduR): Client-Modul des BSW-Stacks; leitet I-PDUs / TP-Datenströme geroutet an den DCM weiter.
  • «module» ComM: Client-Modul für das Buskommunikations- und Modemanagement.
• Schnittstellen & Operationen:
  • «interface» Dcm_PduR (PduR-zu-DCM Transport-Interface):
    • Dcm_StartOfReception(): Signalisierung des Beginns einer TP-Segmentierung; initialisiert Pufferprüfung und -allokation.
    • Dcm_CopyRxData(): Synchrones Kopieren eintreffender Nutzdatenfragmente in den DCM-Empfangspuffer.
    • Dcm_RxIndication(): Abschluss- und Statusbenachrichtigung über die vollständige/abgebrochene PDU-Rezeption.
    • Dcm_CopyTxData(): Auslesen von Diagnoseresponse-Fragmenten aus dem DCM-Sendepuffer in den TP-Puffer.
    • Dcm_TxConfirmation(): Quittierung des Sendevorgangs (Erfolg oder Abbruch).
  • «interface» Dcm_ComM (Modusbenachrichtigungen):
    • Dcm_ComMNoComModeEntered(): Notification über Übergang in COMM_NO_COMMUNICATION.
    • Dcm_ComMSilentComModeEntered(): Notification über Übergang in COMM_SILENT_COMMUNICATION (Listen-Only).
    • Dcm_ComMFullComModeEntered(): Notification über Übergang in COMM_FULL_COMMUNICATION (Normalbetrieb).
• Beziehungen & Stereotypen:
  • Realisierung («realize»): Dcm implementiert beide Schnittstellen (Dcm_PduR und Dcm_ComM).
  • Abhängigkeit («optional»): _PduR hängt optional von Dcm_PduR ab. In Architekturen ohne PduR-Routing könnten TP-Module direkt anbinden; im AUTOSAR-Standard ist PduR der vorgesehene Vermittler.
  • Abhängigkeit (Usage / Dependency): ComM greift direkt auf Dcm_ComM zu.

3. Dynamisches Verhalten & Sequenzablauf

A. Diagnose-Empfangspfad (Rx via Dcm_PduR)

1. Verbindungsaufbau: Der zugrundeliegende Transport-Treiber (z. B. CanTp, DoIP) meldet eine Nachricht via PduR. PduR ruft synchron Dcm_StartOfReception(RxPduId, TpSduLength, ...) auf.
   • Verhalten: DCM validiert Pufferverfügbarkeit (TpDataState). Rückgabe: BUFREQ_OK (inkl. verfügbarer Puffergröße), BUFREQ_E_OVFL (Pufferüberlauf) oder BUFREQ_E_NOT_OK.
2. Datentransfer: Iterativer Aufruf von Dcm_CopyRxData() pro Datensegment. Daten werden blockierungsfrei in den DCM-Puffer kopiert.
3. Abschluss: PduR ruft Dcm_RxIndication(RxPduId, Result) auf (NTFRSLT_OK oder Fehlermeldung).
   • Bei Erfolg: Triggerung der internen asynchronen Verarbeitung (DSD/DSP) zur Service-Interpretation.

B. Diagnose-Sendepfad (Tx via Dcm_PduR)

1. Trigger: DCM startet die Antwortübertragung aktiv via PduR_DcmTransmit().
2. Datenausgabe: PduR/TP ruft synchron Dcm_CopyTxData() auf, um die Response byteweise/blockweise abzuholen.
3. Quittierung: Nach Übertragung auf dem Bus meldet Dcm_TxConfirmation(TxPduId, Result) den Endstatus. Erst hier gibt der DCM den Sendepuffer frei und setzt Session-/Protokoll-Timer zurück.

C. Modussteuerung (via Dcm_ComM)

• Getriggert durch externe Bus-Wakeups oder interne Applikationsanforderungen im ComM:
  • Dcm_ComMFullComModeEntered(): Aktiviert die vollständige Bearbeitung und das Senden von Responses auf dem betroffenen Kanal.
  • Dcm_ComMSilentComModeEntered(): Unterbindet das aktive Senden von Antworten; Reception bleibt aktiv.
  • Dcm_ComMNoComModeEntered(): Sofortiges Zurücksetzen laufender Diagnose-Kommunikation/Puffer auf dem Kanal; Diagnosesessions werden bei Kanalabschaltung standardmäßig in die Default-Session überführt (S3-Server-Timeout).

4. Normative Relevanz & Entwickler-Hinweise

• Pufferverwaltung & Reentrancy:
  • Dcm_CopyRxData() und Dcm_CopyTxData() laufen im Ausführungskontext des Lower Layers (häufig ISR- oder Task-Kontext des TP/PduR). Sie müssen reentrant bzgl. unterschiedlicher Pdu-IDs sein und dürfen weder blockieren noch dynamischen Heap-Speicher allokieren.
• Konfigurationsabgleich (BSW-Generierung):
  • PduR: Die generierten PduR_DcmRxIndication-, PduR_DcmCopyRxData- und Tx-Routen müssen exakt den symbolischen Pdu-IDs der DcmDslProtocolRxPdu / DcmDslProtocolTxPdu entsprechen.
  • ComM: Kanäle müssen konsistent auf DcmDslChannel-Instanzen gemappt sein. Unstimmigkeiten führen zu hängenden Dcm-Zuständen, wenn Mode-Notifications Kanäle referenzieren, die dem DCM unbekannt sind.
• Fehlerbehandlung:
  • Schlägt Dcm_StartOfReception() fehl (z. B. laufende Diagnoseanforderung mit Pufferkonflikt), bricht PduR/Tp die Übertragung sofort ab (BUFREQ_E_NOT_OK); es erfolgt kein nachfolgendes Dcm_RxIndication().