Figure 9.2: Sequence diagram of Dem_ClearDTC

I have launched the search in the repository to check for relevant specification text and will proceed once complete.

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML 2.x Sequenzdiagramm (Interaktionsdiagramm).
• Architektur-Kontext: AUTOSAR Classic Platform (Release R4.3.1), BSW Diagnostic Services Cluster (Service Layer).
• Technischer Zweck: Spezifikation des standardisierten Interaktionsablaufs zwischen externem Diagnose-Tester (Generic Scan Tool), dem Diagnostic Communication Manager (Dcm) und dem Diagnostic Event Manager (Dem) zur Ausführung des UDS-Dienstes 0x14 (ClearDiagnosticInformation). Das Diagramm visualisiert die mit AUTOSAR R4.3 eingeführte, zustandsbehaftete Entkopplung von Filter-/Zieldefinition (Dem_SelectDTC) und eigentlicher Aktionsausführung (Dem_ClearDTC) über ein Client-Id-basiertes Schnittstellenmodell.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & BSW-Module (Lifelines):
  • Generic Scan Tool: Externer UDS-Client / Diagnosetester gemäß ISO 14229-1 / ISO 15031-5.
  • «module» Dcm: AUTOSAR BSW-Modul Diagnostic Communication Manager (enthält das UML-Subsystem-Symbol für Composite Structures/Decomposition). Verarbeitet das Transportprotokoll (DoIP/CanTp) und entpackt die UDS-Servicedaten.
  • «module» Dem: AUTOSAR BSW-Modul Diagnostic Event Manager. Verwaltet den Fehlerspeicher (Primary, Mirror, UserDefined Memory) und steuert das Löschen der DTC-Statusbytes und Freeze Frames.
• Schnittstellen & Datenstrukturen:
  • Diagnoseprotokoll-Ebene (Tester ↔ Dcm):
    • Request: ClearDTCInformation(DTC) – UDS Service 0x14 mit 3-Byte-DTC-Parameter (oder Gruppen-DTC, z. B. 0xFFFFFF für alle DTCs).
    • Response: Positive or negative response() – UDS Service 0x54 (Positivquittung) bzw. 0x7F 0x14 [NRC] (Negativquittung).
  • BSW-Interne C-APIs (Dcm → Dem):
    • Dem_SelectDTC(Std_ReturnType, uint8, uint32, Dem_DTCFormatType, Dem_DTCOriginType):
      • Hinweis zum Tool-Rendering: Das Diagramm führt den C-Rückgabetyp (Std_ReturnType) fälschlicherweise als ersten formalen Parameter auf. Normative C-Signatur: Std_ReturnType Dem_SelectDTC(uint8 ClientId, uint32 DTC, Dem_DTCFormatType DTCFormat, Dem_DTCOriginType DTCOrigin)
      • Typen: ClientId (Referenz des aufrufenden Diagnose-Clients), DTC (32-Bit DTC-Code), Dem_DTCFormatType (DEM_DTC_FORMAT_UDS / DEM_DTC_FORMAT_OBD / etc.), Dem_DTCOriginType (z. B. DEM_DTC_ORIGIN_PRIMARY_MEMORY).
    • Dem_ClearDTC(Std_ReturnType, uint8):
      • Normative C-Signatur: Std_ReturnType Dem_ClearDTC(uint8 ClientId).

3. Dynamisches Verhalten & Sequenzablauf

1. Vorselektion / Layout-Anomalie im Standard (Dem_SelectDTC):
   • Darstellung im Diagramm: Dcm ruft Dem_SelectDTC(...) synchron auf dem Dem auf; Dem antwortet per Reply-Message (Std_ReturnType E_OK oder Fehlerwert).
   • Kritische Spezifikations-Anomalie: Im Schaubild ist dieser Aufruf oberhalb von Request: ClearDTCInformation(DTC) platziert. In einer realen UDS-Implementierung kann die Selektion erst nach Empfang des 0x14-Requests erfolgen, da der zu selektierende DTC und der Zielursprung aus dem Payload des Diagnose-Frames stammen. Die Platzierung im Vektor-Layout ist ein bekannter Zeichenfehler im EA-Modell der Spezifikation.
2. Diagnose-Trigger (Request: ClearDTCInformation(DTC)):
   • Das Scan Tool sendet den Löschauftrag über das Bussystem an das Dcm.
3. Auslösen des Löschvorgangs (Dem_ClearDTC):
   • Das Dcm ruft synchron die API Dem_ClearDTC(ClientId) auf. Es übergibt lediglich die zuvor konfigurierte ClientId; der Kontext (welcher DTC in welchem Speicher) ist im Dem durch Dem_SelectDTC bereits verankert.
4. Verarbeitung & Rückmeldung:
   • Dem quittiert den Aufruf an Dcm via Return-Message (E_OK, DEM_PENDING, DEM_CLEAR_BUSY, DEM_CLEAR_FAILED o. ä.).
   • Bei asynchroner Verarbeitung (z. B. Löschen von NVRAM-Blöcken im NvM) hält das Dcm die Verbindung ggf. über NRC 0x78 (RequestCorrectlyReceived-ResponsePending) offen, bis das Dem den Abschluss meldet.
5. UDS-Abschlussquittung:
   • Dcm übermittelt die positive Bestätigung (0x54) bzw. den entsprechenden NRC (z. B. 0x31 RequestOutOfRange, 0x22 ConditionsNotCorrect) an das Scan Tool.

4. Normative Relevanz & Entwickler-Hinweise

• Multi-Client-Architektur (ab R4.3):
  • Dcm und Dem dürfen keine zustandslosen Legacy-APIs mehr verwenden. Vor jedem Löschvorgang muss zwingend Dem_SelectDTC für die zugewiesene ClientId aufgerufen werden. Ein Aufruf von Dem_ClearDTC ohne vorherige Selektion führt zum DET-Fehler DEM_E_WRONG_CONDITION oder Rückgabewert DEM_CLEAR_FAILED.
• Konfigurationsabhängigkeiten (ARXML):
  • Im Dem-Modul muss unter DemGeneral/DemClient ein dedizierter Client konfiguriert sein, dessen ID mit der im Dcm konfigurierten DcmDslProtocolRow/DcmDemClientId exakt übereinstimmt.
• Asynchrones NvM-Verhalten:
  • Das Löschen von Ereignisspeichereinträgen erfordert RAM-Invalidierungen und anschließende Schreiboperationen auf NvM-Blöcke. Entwickler müssen die Dcm-P2-Timer (DcmDspClearDTC/DcmDspClearDTCP2ServerMax und P2*ServerMax) so kalibrieren, dass anstehende NvM-Jobs nicht zu Timeout-Verletzungen am Tester führen.
• Parallelzugriff & Sperrkonzepte:
  • Wenn während eines laufenden Löschvorgangs ein zweiter Request (oder ein OBD-Clear) eintrifft, blockiert das Dem konkurrierende Aufrufe für dieselbe Speicherinstanz mit DEM_CLEAR_BUSY. Die Software muss dieses Fehlerhandling robust abbilden (Mapped auf UDS NRC 0x21 BusyRepeatRequest).