Figure 9.1: Process Busy Behavior

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm) mit kombinierten Fragmenten (alt-Branch für Fallunterscheidung) und Timing-Constraints ({0..P2ServerMax}, {0..P2*ServerMax}).
• Architektur-Kontext: AUTOSAR Classic Platform, BSW-Modul Dcm (Diagnostic Communication Manager).
• Technischer Zweck: Spezifikation des internen und externen Ablaufverhaltens bei verzögerter Diagnoseverarbeitung („Process Busy Behavior“) gemäß UDS (ISO 14229-1) / AUTOSAR DCM. Veranschaulicht das Zusammenspiel der internen DCM-Submodule (DSL, DSD, DSP) mit dem PDU Router (PduR) und einem externen Verarbeitungsmodul (External Module, z. B. SW-C via RTE oder BSW) beim Einhalten der P2- und P2\*-Server-Zeitschranken unter Verwendung der negativen Antwort NRC 0x78 (responsePending).

2. Komponenten, Entitäten & Schnittstellen

Akteure & Module (Lifelines)

• «module» PduR (PDU Router): Kommunikationsschnittstelle der BSW-Transportschicht zur Entkopplung der Busprotokolle (CanTp, FrTp, LinTp, DoIP) vom DCM.
• «module» Dsl (Diagnostic Session Layer): DCM-Subkomponente zur Verwaltung von Sitzungszuständen, Sicherheitsebenen, Kommunikationskanälen und Protokoll-Timern (P2_ServerMax, P2^*_ServerMax).
• «module» Dsd (Diagnostic Service Dispatcher): DCM-Subkomponente zur Anforderungsprüfung (Service-ID, Session-/Security-Validierung) und Verteilung der Serviceausführung an DSP oder externe Module.
• External Module: Anwendungs-SW-C (über AUTOSAR-Ports/RTE) oder weiteres BSW-Modul, welches die eigentliche Diagnosefunktionalität asynchron implementiert.
• «module» Dsp (Diagnostic Service Processing): DCM-Subkomponente zur Abwicklung standardisierter Diagnosedienste und interner Zustandsbestätigung.

Schnittstellen & Funktionsaufrufe

• Dcm_TpRxIndication(PduIdType, Std_ReturnType): Autorisierter Callback von PduR an Dsl zur Signalisierung eines vollständig empfangenen Diagnose-Requests.
• Data_Indication_functionality(): Modulinterne Schnittstelle zwischen Dsl und Dsd zur Übergabe des dekodierten Anforderungskontexts.
• <Module>_<DiagnosticService>(Std_ReturnType, Dcm_ExtendedOpStatusType, Dcm_MsgContextType**, Dcm_NegativeResponseCodeType**): Asynchrone Service-Aufrufschnittstelle von Dsd zum External Module. Übergibt Betriebsstatus (DCM_INITIAL, DCM_PENDING etc.), Pufferzeiger und NRC-Referenz.
• PduR_DcmTransmit(Std_ReturnType, PduIdType, const PduInfoType*): Std_ReturnType: BSW-API-Aufruf von Dsl an PduR zur Initiierung der Übertragung einer Diagnose-PDU (insb. NRC 0x78 oder finale Response).
• Dcm_TpTxConfirmation(PduIdType, NotifResultType): Callback von PduR an Dsl zur Quittierung der erfolgten PDU-Aussendung auf dem Bus.
• Data_Confirmation_functionality(): Modulinterne Benachrichtigung von Dsl an Dsd über den erfolgreichen Sendeabschluss.
• DspInternal_DcmConfirmation(Dcm_IdContextType, PduIdType, Dcm_ConfirmationStatusType): Modulinterne Quittierungsschnittstelle von Dsd an Dsp zur Finalisierung des Verarbeitungszyklus.

3. Dynamisches Verhalten & Sequenzablauf

Phase 1: Request-Eingang & Service-Triggerung (Request-Frame)

1. PduR meldet den vollständigen Empfang der Diagnoseanfrage via Dcm_TpRxIndication(...) synchron an die Dsl.
2. Dsl leitet den Request über Data_Indication_functionality() an die Dsd weiter.
3. Innerhalb des Zeitintervalls {0..P2ServerMax} ruft Dsd die Servicefunktion <Module>_<DiagnosticService>(...) des External Module auf.
4. Das External Module signalisiert verzögerte Bearbeitung (Rückgabewert DCM_E_PENDING über Std_ReturnType mit OpStatus DCM_INITIAL/DCM_PENDING).
5. Die Funktionsaufrufe kehren synchron zurück über Dsd an Dsl und schließen mit dem Return von Dcm_TpRxIndication() an PduR ab.

Phase 2: Verzweigung alt response?

Pfad A: [negative response: RC=0x78] (Busy / Response Pending)

• Bedingung: Die Bearbeitung im externen Modul dauert länger als P2_ServerMax bzw. der konfigurierte Vorhaltewert (DcmDspSessionP2ServerAdjust).
• Ablauf:
  1. Dsl triggert eigenständig vor Ablauf von P2_ServerMax die Aussendung einer NRC 0x78 (requestCorrectlyReceived-ResponsePending) über PduR_DcmTransmit(...).
  2. Nach Übertragung startet der Timer P2^*_ServerMax.
  3. Innerhalb des Intervalls {0..P2*ServerMax} kann die Dsl bei fortdauerndem Pending-Status zyklisch weitere NRC-0x78-PDUs über PduR_DcmTransmit(...) anstoßen (beschränkt durch DcmDspMaxNumRespPend).

Pfad B: [positive response] (Abschluss & Confirmation)

• Bedingung: Die Nutzdaten wurden vom External Module bereitgestellt, die finale (positive) Antwort wurde via PduR_DcmTransmit(...) gesendet und der Transportlayer hat den Sendevorgang abgeschlossen.
• Ablauf:
  1. PduR ruft nach erfolgreicher Übertragung Dcm_TpTxConfirmation(PduIdType, NotifResultType) auf Dsl auf.
  2. Dsl reicht die Bestätigung via Data_Confirmation_functionality() an Dsd weiter.
  3. Dsd ruft DspInternal_DcmConfirmation(Dcm_IdContextType, PduIdType, Dcm_ConfirmationStatusType) auf Dsp auf, um service-spezifische Nacharbeiten (z. B. Aktivieren neuer Sessions, Security-Level-Wechsel, Reset-Ausführung) endgültig scharfzuschalten.
  4. Die Bestätigungskette kehrt kaskadierend zurück bis zum Return von Dcm_TpTxConfirmation() an PduR.

4. Normative Relevanz & Entwickler-Hinweise

• Asynchrone Service-Abwicklung (Dcm_ExtendedOpStatusType):
  • Externe Service-Handler (SW-C / BSW) dürfen bei rechen- oder I/O-intensiven Aufgaben niemals den Kontext blockieren. Sie müssen mit DCM_E_PENDING zurückkehren.
  • Folgende Aufrufe erfolgen mit OpStatus = DCM_PENDING, der finale Aufruf zur Pufferfreigabe mit DCM_CONFIRMED_OK bzw. DCM_CANCEL.
• **P2 / P2\* Timing-Konfiguration:**
  • Konfigurationsparameter DcmDspSessionP2ServerMax und DcmDspSessionP2StarServerMax müssen konsistent mit den UDS-Vorgaben des OEM-Lastenhefts parametriert werden.
  • Das Delta DcmDspSessionP2ServerAdjust / DcmDspSessionP2StarServerAdjust muss die Latenzen des Transportprotokolls (z. B. CanTp FC-Wartezeiten) und des BSW-Schedulings kompensieren, damit die NRC 0x78 vor Tester-Timeout auf dem Bus erscheint.
• Pufferverwaltung (Dcm_MsgContextType):
  • Während des Status DCM_E_PENDING bleibt der DCM-Nachrichtenpuffer für diesen Diagnosekanal gesperrt.
  • Erst durch den Aufruf von DspInternal_DcmConfirmation bzw. nachfolgende Pufferfreigabe durch die DSL wird der Diagnosekanal für nachfolgende Requests freigegeben.
• Limitierung von Response Pendings:
  • Entwickler müssen DcmDspMaxNumRespPend beachten. Bei Überschreiten der maximal zulässigen Anzahl bricht der DCM die Ausführung eigenständig ab und sendet NRC 0x22 (conditionsNotCorrect) oder NRC 0x10 (generalReject).