Figure 7.51: Buffer format used by Dem_GetNextFreezeFrameData

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Speicher- und PDU-Serialisierungs-Layout (Binary Buffer / Wire-Format).
• Funktionale Einordnung: Spezifikation des Byte-Layouts im Zielpuffer (DestBuffer), den der Diagnostic Event Manager (Dem) bei Aufruf der API Dem_GetNextFreezeFrameData an den Diagnostic Communication Manager (Dcm) übergibt.
• Architektur-Zweck:
  • Abbildung des Snapshot-Datensatzes für UDS Service 0x19 0x04 (ReadDTCInformation / reportDTCSnapshotRecordByDTCNumber) gemäß ISO 14229-1 sowie WWH-OBD (ISO 27145) bei Record 0x00 ([SWS_Dem_00576]).
  • Optimiertes Dem/Dcm-Interface: Im Gegensatz zum PID-Handling (OBD-II), bei dem der Dcm Header und PIDs assembliert, übernimmt der Dem die DID-Serialisierung autonom. Der Puffer enthält den vollständig formatierten Payload für die UDS-Response, sodass der Dcm ohne Restrukturierung (Zero-Copy / direkte Übergabe an PduR) agieren kann.

2. Komponenten, Entitäten & Schnittstellen

• Beteiligte BSW-Module:
  • Dem (Diagnostic Event Manager) – Datenquelle, Fault-Memory- und Freeze-Frame-Verwaltung.
  • Dcm (Diagnostic Communication Manager) – Aufrufer, UDS-Protokoll-Handler.
• APIs & Signaturen:
  • Dem_SelectFreezeFrameData(uint8 ClientId, uint8 RecordNumber) – Selektions- und Filter-API ([SWS_Dem_00630]).
  • Dem_GetNextFreezeFrameData(uint8 ClientId, uint8* DestBuffer, uint16* BufSize) – Datenbereitstellungs-API ([SWS_Dem_00071], [SWS_Dem_00074], [SWS_Dem_01272]).
• Buffer-Entitäten & Byte-Offsets:
  • Byte 0: RecordNum (1 Byte) – DTCSnapshotRecordNumber gemäß ISO 14229-1. Berechnet (z. B. fortlaufend 0x01) oder konfiguriert (z. B. erster Wert einer Sequenz; 0x00 für WWH-OBD).
  • Byte 1: Num of DIDs (1 Byte) – DTCSnapshotRecordNumberOfIdentifiers. Anzahl der im Snapshot enthaltenen DIDs.
  • Byte 2..3: 1st DID (2 Byte, Big-Endian / Network Byte Order) – 16-Bit Data Identifier.
  • Byte 4..j: Data #1 (Variable Länge) – Konkatenierte Nutzdaten des ersten DID, zusammengesetzt aus atomaren Datenelementen (Data element #1 bis Data element #N), abgebildet über DemDataElementClass.
  • Byte j..k: ... – Folgende DID- und Datenblöcke.
  • Byte k..(k+2): Nth DID (2 Byte, Big-Endian) – Letzter 16-Bit Data Identifier.
  • Byte (k+2)..n: Data #N (Variable Länge) – Nutzdaten des N-ten DID.
  • Byte 0..n: requested freeze frame record – Vollständiger Record-Container.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung / Selektion:
   • Dcm empfängt UDS-Request 0x19 0x04 mit DTC und RecordNumber.
   • Dcm ruft Dem_SelectFreezeFrameData(ClientId, RecordNumber) auf; der Dem initialisiert den internen Lesecursor für den adressierten DTC.
2. Datenauslese:
   • Dcm ruft synchron Dem_GetNextFreezeFrameData(ClientId, DestBuffer, &BufSize) auf.
   • Der Dem serialisiert RecordNum, Num of DIDs sowie alle konfigurierten DID/Data-Tupel sequenziell in DestBuffer.
   • Bei erfolgreicher Serialisierung schreibt der Dem die tatsächlich geschriebene Byte-Anzahl zurück in BufSize.
3. Rückgabewerte & Fehlerpfade:
   • E_OK: Datensatz vollständig geschrieben.
   • DEM_BUFFER_TOO_SMALL: Der über BufSize signalisierte Puffer reicht nicht für den gesamten Freeze Frame aus. Dcm bricht ab oder sendet NRC 0x14 (ResponseTooLong) bzw. 0x31 (RequestOutOfRange).
   • DEM_NO_SUCH_ELEMENT: Kein (weiterer) Freeze Frame Record für die Selektion vorhanden.
   • DEM_PENDING: Asynchroner NVRAM-Lesezugriff via NvM steht noch aus (sofern konfiguriert).

4. Normative Relevanz & Entwickler-Hinweise

• Puffer-Dimensionierung: Der Dcm-Puffer für UDS 0x19 0x04 muss mindestens dimensioniert sein mit: $$\text{BufSize}_{\text{min}} = 2 + \sum_{i=1}^{N} \left( 2 + \text{sizeof}(\text{Data}_i) \right) \text{ Bytes}$$
• Endianness & Alignment: DIDs sind strikt als 16-Bit Big-Endian zu encodieren. Zwischen DIDs und Datenelementen existiert kein automatisches Compiler-Padding; Daten liegen als packed byte stream vor.
• WWH-OBD Sonderbehandlung: Bei RecordNumber 0x00 erfordert [SWS_Dem_00576] die Bereitstellung des WWH-OBD-Freeze-Frames. Diese Funktion ist nur aktiv, wenn DemGeneral/DemOBDSupport konfiguriert ist.
• Konfigurationskonsistenz: Die interne Zusammensetzung von Data #X hängt direkt an den Parametern DemDidClass und DemDataElementClass. Werden Datenelemente via R-Port (DataServices_...) oder cals/swcs ausgelesen, müssen deren Längen exakt mit der im Dem konfigurierten Byte-Länge übereinstimmen, um Verschiebungen nachfolgender DIDs im Stream zu verhindern.