Understanding Autosar Error Types and Handling
Autosar, the standardized automotive software architecture, categorizes errors in BSW modules into five distinct types based on their life cycle states: development, runtime, transient, production, and extended production.
Development Errors
Development errors originate from bugs during software development. These errors disrupt regular ECU behavior and can lead to program flow interruption or ECU resets. Enabling development error detection through the configuration parameter <Ma>DevErrorDetect (where Ma is the Module Abbreviation) is crucial during initial BSW module integration. The first error to be validated typically relates to module initialization, resulting in a <MIP>_E_UNINIT (where MIP is the Module Implementation Prefix) report.
Development errors are reported to the Development Error Tracer (DET) using the API Det_ReportError, providing the BSW module ID and the error details. You can learn more about the DET in our post DET Overview (opens in a new tab).
Runtime Errors
Runtime errors are faults that don't impact the overall system behavior but trigger an error handler. These short-lived errors may involve actions by the ECU, such as calling the DEM module to store the error in an event memory and calling a callback implemented by an ECU integrator.
Reported via DET using the API Det_ReportRuntimeError, these errors cannot be switched off through configuration and have configurable callouts.
Transient Faults
Transient faults stem from hardware malfunctions, such as electromagnetic interference (EMI). These errors are transient and may reoccur throughout runtime. DET reports transient faults via Det_ReportTransientFault, and error handling is configurable through a callout.
Production Errors
Production errors are caused by aging hardware or poor production quality, among other reasons. For a hardware problem to be considered a production error, it needs to increase the emissions of the vehicle, limiting the diagnostic capabilities of the system, triggers safety mechanisms to prevent the error from causing more damage or if a repair action needs to take place to fix the issue. These errors are reported via the DEM, providing an entry directly in the primary event memory.
Production errors that stem from the same root cause should not be reported twice, meaning production errors should not limit their scope to a single BSW module, rather to the entire system.
Extended Production Errors
Similar to production errors, extended production errors provide additional information about issues but don't meet the criteria of production errors. Unlike production errors, they are reported to DEM but do not enter directly in the primary event memory, although they can be useful for root cause analysis and the ECU Integrator should consider implementing callbacks to perform actions based on them.
Production and extended production errors can only be switched off if they depend on optional configurations that have been disabled. The unique Event IDs are defined in Dem.h, and reporting is done using Dem_SetEventStatus with parameters EventID and EventStatus. For mor information about the DEM, please visit our post DEM Overview (opens in a new tab).
Stay tuned for further insights into Autosar!
Author: Micael Coutinho (opens in a new tab)
References:
© AutosarToday —@LinkedIn