Error handling and Diagnostic event management DEM
For this the DEM module offers means for:
- Processing the errors, for this it offers various algorithms (debounce counter, time base) that can be used maturating/qualifying a component behavior as passed or failed
- Storage of the Errors/DTC- Diagnostic Trouble codes in the nonvolatile memory
- Storage of the “environment conditions” that lead to the error(freeze frames and extended data records) that can be used to better understand why the error occurred and to help reproduce it if needed.
- Reporting of the DTC information to Dcm so that it can be passed to the tester, during service operation at the garage.
- Diagnostic Monitor: “A diagnostic monitor is a routine entity determining the proper functionality of a component. This monitoring function identifies a specific fault type (e.g. short to ground, open load, etc.) for a monitoring path.“
- Monitoring Paths: “A Monitoring Path represents the physical system or a circuit, that is being diagnosed (e.g. sensor input). Each monitoring path is associated to exactly one diagnostic event.“
- A ‘Diagnostic Event’ defines the atomic unit that can be handled by the Dem module
- The Dem receives the result(prePassed, preFailed, passed, failed) of a monitor from a SW-C, via the RTE, or from other BSW modules
- Each Event is represented by a unique EventID and it’s related EventName which is used to generate the so called “Symbolic Name” that abstracts the ID
The Status of a ‘Diagnostic Event’ represents the result of a monitor, and it is reflected in the DTCSatusByte. This is a bit packed byte of information used to determine the status of an event.
DTCStatusByte it is defined by ISO 14229 – 1 as:
Diagnostic Trouble Code – DTC
Diagnostic Trouble Codes are used to encode following information about a failure:
- Component that is failing
- Group of the failure (Powertrain, Chassis, BodyGroup, Network Communication,..)
- Type of failure (shortcut to ground, plausability,..)
A Diagnostic Trouble Codes can be linked with:
- one event or
- more events – combined events
Note: information about the failures linked with events that are assigned to any DTC can not be
retrieved by Diagnostic Tool, these can be used only internally(use callbacks to take any action)
A DTC is defined by following basic properties:
- Type of storage (immediate or during shutdown)
- Place where it is stored – Memory Destination see later on
- DTC format
DTC – format
- ISO 14229-1 (UDS)
- ISO 15031-6 (OBD)
- SAE J1939-73 (Serial Control and Communication Heavy Duty Vehicle Network)
- ISO 11992-4 (Interchange of digital information on electrical connections between towing and towed vehicles)
- Customer/Project Specific e.g. Service/EndOfLine Fault => Modules needs to be exchanged, vehicle needs to be fixed
Secondary Error Memory
- AUTOSAR 4.0 concept – till Dem 4.x.0.15.0 release
- Customer/Project Specific e.g. for “Debugging” Errors
- AUTOSAR 4.2 concept – till Dem 4.x.0.16.0 release
- User Defined Memories – configurable memories
Mirror Error Memory
- Cleared Events will move from Primary/Secondary to Mirror Memory. Info can be used for later analysis of field returns.
Permanent Error Memory
- OBD related, handling according legal requirement
Operation Cycle and Enable Condition Check
Operation Cycle check
- Check if the Ecu is in the correct Operation Cycle for the Event
- e.g.: Only during the ignition cycle it is allowed to process the event so after Ignition Off the reports will be ignored.
Enable Condition Check
- Check if the Event can be process according to its configured Enable conditions
- e.g. No other ECU DTC should be logged during under voltage…
Other DEM terms
Extended data record
Event memory overflow indication
AUTOSAR articles (for articles written in Romanian please select your language from right part of webpage)
Thank you for attention !
For questions please contact me on email: firstname.lastname@example.org.
Have a nice day !