AUTOSAR Diagnostics: DEM Event Handling and DCM UDS Services

The problem

Every production ECU must detect faults, store diagnostic trouble codes with context and answer workshop testers through UDS. In AUTOSAR this is split between the Diagnostic Event Manager (DEM) and the Diagnostic Communication Manager (DCM). Getting debouncing, status bits and service behaviour right matters for warranty, emissions-style regulations and safe repair.

Objectives

• Define diagnostic events, debouncing and DTCs for an EV function.
• Implement DEM behaviour: status bits, operation cycles, freeze frames and aging.
• Implement DCM handling of key UDS services over ISO-TP on CAN.
• Report events from an application component through a DEM interface.
• Verify behaviour with a scripted UDS tester and fault injection.

What you need

Key concepts

DTC status byte

Eight bits defined by ISO 14229, including testFailed, testFailedThisOperationCycle, pendingDTC, confirmedDTC and testNotCompletedSinceLastClear, that together describe a fault's history.

Debouncing

Filtering raw monitor results with a counter or timer so a single noisy sample does not set a fault, while a persistent fault is reported quickly.

Operation cycle

A defined period, such as ignition on to off, over which faults are counted. Pending and confirmed status depend on failures across cycles.

ISO-TP

The ISO 15765-2 transport protocol that splits UDS messages longer than one CAN frame into first, consecutive and flow-control frames.

Step-by-step guide

1. 1

   Define events and DTCs

   Choose an EV function on the kit, such as a coolant temperature sensor read through the potentiometer as a stand-in for the sensor voltage. Define diagnostic events: sensor out of range high, out of range low, implausible rate of change and a CAN message timeout. Assign each a DTC number, a debounce method and thresholds, a confirmation threshold in operation cycles, an aging threshold and the freeze-frame data to capture, such as sensor value and supply voltage.

   Checkpoint: A diagnostic specification table with events, DTCs, debounce settings and freeze-frame contents.

2. 2

   Monitor in the application component

   Model the sensor monitoring as an AUTOSAR application component in Simulink: range and rate checks produce pre-passed or pre-failed results for each event every 10 ms. Report them through a DEM service interface, using the diagnostic blocks in AUTOSAR Blockset or a client-server port that maps to Dem_SetEventStatus. Generate code and implement the RTE call so it reaches your DEM on the STM32.

   Checkpoint: The generated component calls the DEM interface with correct event IDs as the potentiometer moves across thresholds.

3. 3

   Implement DEM status handling

   Write the DEM in C: counter-based debouncing per event, and on qualified results update the eight ISO 14229 status bits for the DTC. Implement operation cycle start and end, triggered by a keypad press or a CAN command that stands in for ignition. Implement pending after one failed cycle, confirmed after the configured number of cycles and aging that clears confirmed status after enough passing cycles. Unit-test status transitions on the PC.

   Checkpoint: PC unit tests reproduce a hand-written table of status byte values over a sequence of cycles.

4. 4

   Store freeze frames and persist data

   When a DTC is first confirmed, capture a freeze frame with the specified data and a timestamp or cycle counter. Store event memory entries in a small table and write them to the STM32 internal flash at the end of an operation cycle, using a simple two-page scheme with a checksum so a reset during a write does not corrupt the memory. Restore the event memory at start-up and verify the checksum.

   Checkpoint: Confirmed DTCs and freeze frames survive a reset and reappear with the same contents.

5. 5

   Implement ISO-TP on CAN

   Implement ISO-TP for one physical request and one response CAN identifier: single frames for short messages, and for long responses first frames, flow control handling with block size and separation time, and consecutive frames. Handle timeouts and wrong sequence numbers. Test against the Python can-isotp library on the PC by sending and receiving messages of 7, 8, 62 and 200 bytes.

   Checkpoint: Messages of each length pass both ways with correct contents and flow control.

6. 6

   Implement DCM services

   Implement a DCM that dispatches UDS requests: DiagnosticSessionControl (0x10) for default and extended sessions, TesterPresent (0x3E), ReadDataByIdentifier (0x22) for a few data identifiers such as software version and sensor value, ReadDTCInformation (0x19) with reportNumberOfDTCByStatusMask and reportDTCByStatusMask, reportDTCSnapshotRecordByDTCNumber, and ClearDiagnosticInformation (0x14) allowed only in the right session. Return correct negative response codes for unsupported services, wrong length and wrong session. Keep the service table data-driven so new services can be added without changing the dispatcher.

   Checkpoint: Each service returns a correct positive response and the expected negative response codes for invalid requests.

7. 7

   Add session and security rules

   Implement a session timeout that returns to the default session if TesterPresent stops. Add SecurityAccess (0x27) with a seed and key exchange using a simple documented algorithm for the exercise, required before clearing DTCs, and lock out after repeated wrong keys with a delay. Note that production systems use strong cryptographic key algorithms; the purpose here is the protocol behaviour. Show the session and security state on the LCD.

   Checkpoint: Clearing DTCs fails without unlocking, succeeds after a correct key and locks out after wrong keys.

8. 8

   Write the tester and fault scenarios

   Write a Python tester with udsoncan over can-isotp that runs scenarios: inject a short glitch that must not set a DTC, a persistent out-of-range fault over several operation cycles until confirmed, read DTCs and the freeze frame, heal the fault and check aging, and clear DTCs with security. Also stop a periodic CAN message from the PC to trigger the timeout event. Log every request and response.

   Checkpoint: A tester log showing each scenario's expected status bytes and responses, with pass or fail per step.

9. 9

   Measure timing and robustness

   Measure response times from request to response for each service and compare with the P2 server timing you configured. Measure DEM processing time per cycle with the DWT cycle counter. Send malformed requests, such as wrong lengths and unknown sub-functions, and back-to-back requests to check the DCM never hangs. Record flash and RAM use of the DEM and DCM. Run the tester continuously for an hour to check for memory leaks or stuck states.

   Checkpoint: A table of response times, cycle costs and robustness test results.

10. 10

    Report

    Document the diagnostic specification, DEM and DCM design, status bit behaviour, ISO-TP implementation, tester scenarios and measurements. Compare your implementation with a production AUTOSAR stack, where DEM and DCM are configured from ARXML in tools such as Vector DaVinci Configurator, and list the features you left out, such as multiple clients and full OBD support. Include the diagnostic specification table so the DTC behaviour can be reviewed against it.

    Checkpoint: A report with status-bit traces, tester logs and timing results, and the full source.

Testing & validation

• Status byte transitions matching the specification over several operation cycles.
• Short glitches filtered by debouncing; persistent faults confirmed.
• Freeze frames and event memory surviving a reset.
• Correct positive and negative UDS responses for all implemented services.
• Response times within the configured P2 timing.

Expected results

A working DEM and DCM on the STM32 kit that detects, debounces and stores faults with freeze frames and answers a scripted UDS tester over CAN.

Take it further

• Add RoutineControl (0x31) for a sensor self-test routine.
• Add DTC suppression through a function inhibition mechanism.
• Implement an event-related enable condition such as supply voltage in range.
• Write a small workshop tool that reads and explains DTCs.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.