SNIP_CLASSIC_DEM_SECTION_08_Jan_2024

08 Jan 2024 page id: nik01 Integration and Runtime Aspects - Error Handling, Reporting and Diagnostic Error Classification (3) Report as „De elopment Error“ Report as „Runtime Error“ Report as „Production Error“ no yes Fundamental precondition violated? • to be fixed in development phase • and to be handled as an “assertion”, (i.e., terminate program flow) yes no Is the error relevant for (service/EOL) diagnostics? Errors caused by e.g. • software bugs • incorrect (SW) integration by the user • invalid (SW) configuration • bugs in the integration tools Errors that e.g. • lead to an increase of emissions and must be detected to fulfill applicable regulations. • limit the capability of any other OBD relevant diagnostic monitor. • require limp-home reactions, e.g., to prevent further damage to the hardware or customer perceivable properties. • Help to point the garage to a failed component for repair actions. hen reporting a “Development Error”, program flow terminates/ECU is reset 5acXjzUk R25-11 AUTOSAR_CP_EXP_LayeredSoftwareArchitecture 165 Error Type Main purpose Detection and reporting Configuration Detection mechanism Program flow Reported to Error Return Code Inform API caller about current state of an error Leave error reaction to calling module, which has more context to decide on proper error reaction During all life cycles none Event based (set condition only) continues To calling BSW module (synchronuously via API return code or asynchronuously via notification callback) Development Error Detect SW/integration issues early during development. During „Development“ only Module specific overall enabling/disabling of Detection + Reporting of development errors via pre-compile switch DevErrorDetect provides Callout for integration code in Det_ReportError Event based (set condition only) terminates DET (via Det_ReportError; integration code in Callout allows some preparation before ECU is reset) Runtime Error Detect errors during normal operation, e.g. systematic software faults, timing faults or hardware issues During all life cycles Always active provides Callout for integration code in Det_ReportRuntimeError Event based (set condition only) continues DET (via Det_ReportRuntimeError; integration code in Callout allows further reporting) Production Error Detect issues (and absense of issues) relevant e.g. for service/repair actions or system degradation During all life cycles <Ma>DemEventParameterRef s parameter allows to enable/disable the error Maturing/he aling (set/reset conditions) continues DEM (via Dem_SetEventStatus to the event memory) Integration and Runtime Aspects - Error Handling, Reporting and Diagnostic Error Classification Summary page id: nik02 5acXjzUk R25-11 AUTOSAR_CP_EXP_LayeredSoftwareArchitecture 166 Integration and Runtime Aspects - Error Handling, Reporting and Diagnostic Error Reporting via API Error reporting via API Informs the caller about failure of an operation by returning an error status. Basic return type Success: E_OK (value: 0) Failure: E_NOT_OK (value: 1) Specific return type If different errors have to be distinguished for production code, own return types have to be defined. Different errors shall only be used if the caller can really handle these. Specific development errors shall not be returned via the API. They can be reported to the Default Error Tracer (Det). Example: services of ADC driver Success: ADC_E_OK General error (service not accepted): ADC_E_NOT_OK ADC is busy with current conversion: ADC_E_BUSY page id: yaq12 5acXjzUk R25-11 AUTOSAR_CP_EXP_LayeredSoftwareArchitecture 167 Integration and Runtime Aspects - Error Handling, Reporting and Diagnostic Error Reporting – Introduction Error reporting via Diagnostic Event Manager (Dem) For reporting production / series errors. Those errors have a defined reaction depending on the configuration of this ECU, e.g.: ➢ Writing to error memory ➢ Disabling of ECU functions (e.g. via Function Inhibition Manager) ➢ Notification of SW-Cs The Diagnostic Event Manager is a standard AUTOSAR module which is always available in production code and whose functionality is specified within AUTOSAR. Error reporting via Default Error Tracer (Det) For reporting development/runtime errors. The Default Error Tracer is mainly intended for handling errors during development time but also for handling systematic errors in production code. Within the Default Error Tracer many mechanisms are possible, e.g.: ➢ Count errors ➢ Write error information to ring buffer in RAM ➢ Send error information via serial interface to external logger ➢ Infinite Loop, Breakpoint The detection and reporting of development errors to the Default Error Tracer can be statically switched on/off per module (preprocessor switch or different object code builds of the module) but not for Runtime errors. page id: oiuzt