Figure 9.2: Sequence diagram of Dem_ClearDTC

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML 2.x Sequenzdiagramm (Interaktionsdiagramm).
• Architektur-Kontext: AUTOSAR Classic Platform (ab Release R18-10 / R4.4.0), 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 zustandsbehaftete Entkopplung von Filter-/Zieldefinition (Dem_SelectDTC), Abfrage des Selektionsergebnisses (Dem_GetDTCSelectionResultForClearDTC) und asynchroner Aktionsausführung (Dem_ClearDTC innerhalb einer Schleife) ü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_GetDTCSelectionResultForClearDTC(Std_ReturnType, uint8):
      • Normative C-Signatur: Std_ReturnType Dem_GetDTCSelectionResultForClearDTC(uint8 ClientId).
      • Zweck: Dient der Überprüfung des Selektionsstatus vor dem Auslösen des Löschvorgangs.
    • Dem_ClearDTC(Std_ReturnType, uint8):
      • Normative C-Signatur: Std_ReturnType Dem_ClearDTC(uint8 ClientId).

3. Dynamisches Verhalten & Sequenzablauf

1. Diagnose-Trigger (Request: ClearDTCInformation(DTC)):
   • Das Generic Scan Tool sendet den Löschauftrag über das Bussystem an das Dcm.
2. Vorselektion des DTC (Dem_SelectDTC):
   • Dcm ruft synchron die API Dem_SelectDTC(...) auf dem Dem auf, um den zu löschenden DTC bzw. die DTC-Gruppe und den Ziel-Speicherursprung für die gegebene ClientId zu konfigurieren.
   • Dem bestätigt den Empfang via Return-Message.
3. Prüfung des Selektionsergebnisses (Dem_GetDTCSelectionResultForClearDTC):
   • Dcm fragt synchron das Ergebnis der Selektion beim Dem ab (Dem_GetDTCSelectionResultForClearDTC).
   • Dem quittiert mit dem Selektionsstatus (z. B. DEM_DTC_OK).
4. Asynchroner Löschvorgang in Polling-Schleife (loop Dem_ClearDTC):
   • Dcm führt das UML-Interaktionsfragment loop aus und ruft zyklisch Dem_ClearDTC(ClientId) auf.
   • Solange interne Bereinigungsschritte (z. B. RAM-Invalidierung und NvM-Schreiboperationen) laufen, meldet Dem DEM_CLEAR_PENDING.
   • Die Schleife endet, sobald Dem DEM_CLEAR_OK oder einen Fehlercode liefert.
5. UDS-Abschlussquittung (Positive or negative response()):
   • Dcm übermittelt die abschließende Antwort an das Scan Tool (Positivquittung 0x54 bzw. NRC bei Fehlern).

4. Normative Relevanz & Entwickler-Hinweise

• Prüfpflicht des Selektionsstatus (ab R18-10 / R4.4.0):
  • Vor dem Aufruf von Dem_ClearDTC muss das Dcm das Selektionsergebnis explizit über Dem_GetDTCSelectionResultForClearDTC validieren. Nur bei erfolgreicher Selektion (DEM_DTC_OK) darf der Löschvorgang gestartet werden; andernfalls bricht Dcm ab und antwortet mit NRC 0x31 (RequestOutOfRange).
• Polling-Architektur & Loop-Fragment:
  • Das loop-Fragment verdeutlicht die asynchrone Schnittstellenarchitektur von Dem_ClearDTC. Dcm muss die Funktion im Polling aufrufen, solange DEM_CLEAR_PENDING zurückgegeben wird, ohne die Ausführung blockierend anzuhalten.
• Multi-Client-Architektur:
  • Vor jedem Löschvorgang muss zwingend Dem_SelectDTC für die zugewiesene ClientId aufgerufen werden. Die Zuordnung zwischen Dcm und Dem erfolgt über die konfigurierte ClientId.
• Asynchrones NvM-Verhalten & P2-Timer:
  • Während der loop-Abarbeitung muss Dcm bei zeitaufwendigen NvM-Operationen NRC 0x78 (ResponsePending) senden, um P2/P2*-Timeout-Verletzungen am Tester zu verhindern.
• Parallelzugriff & Sperrkonzepte:
  • Konkurrierende Aufrufe während eines aktiven Löschvorgangs werden vom Dem mit DEM_CLEAR_BUSY abgewiesen und vom Dcm auf NRC 0x21 (BusyRepeatRequest) abgebildet.