AUTOSAR 4.3.1应用层错误处理详解

需积分: 19 81 浏览量更新于2024-07-15 收藏 975KB PDF 举报

本资源文档《AUTOSAR EXP: Application Level Error Handling》详细探讨了汽车行业中广泛采用的AUTOSAR（AUTomotive Open System ARchitecture）应用层错误处理机制。AUTOSAR CP（Controller Platform）Release 4.3.1版本的发布旨在提供一个全面的理解，涵盖了在汽车电子系统开发中如何有效管理和处理应用层错误。在AUTOSAR架构中，应用层错误处理是关键的一环，因为它确保系统的稳定性和可靠性。该文档首先概述了错误处理的重要性，它涉及到软件的健壮性、故障检测与隔离、数据一致性以及用户体验。在AUTOSAR平台中，错误处理策略可能包括错误报告、错误恢复、错误日志记录和错误预防等组件。文档深入剖析了以下几个主要部分： 1. **错误类型和分类**：文档介绍了不同类型的错误，如硬件故障、软件异常、通信问题等，并强调了如何对这些错误进行区分和优先级排序。 2. **错误报告**：详细阐述了错误报告机制，包括事件触发、事件格式、以及如何通过诊断接口向诊断服务传递错误信息。 3. **错误处理策略**：讨论了错误处理的几种常见策略，如冗余系统设计、故障切换、错误补偿以及使用错误码和错误状态机来管理错误流程。 4. **错误恢复**：讲解了如何在系统中实施恢复机制，包括自动恢复、人工干预和备份策略，确保在发生错误后能尽快恢复正常操作。 5. **错误记录与分析**：强调了日志记录的重要性，以及如何通过分析错误日志来识别模式、诊断问题并防止未来的错误重演。 6. **符合AUTOSAR标准**：文档确保所介绍的错误处理方法符合AUTOSAR经典平台规范，适用于4.3.1版本，同时也回顾了之前的版本变更，以便开发者了解历史沿革和最新最佳实践。 7. **编辑和修订历史**：展示了文档从4.0.3版本以来的多次修订，反映了AUTOSAR组织对错误处理标准的持续改进和完善。《AUTOSAR EXP: Application Level Error Handling》为AUTOSAR平台下的汽车电子系统开发人员提供了宝贵的指南，帮助他们设计和实现高效、可靠的错误处理方案，以应对复杂而严苛的汽车行业环境。

Explanation of Error Handling on Application Level

AUTOSAR CP Release 4.3.1

13 of 78 Document ID 378: AUTOSAR_EXP_ApplicationLevelErrorHandling

- AUTOSAR confidential -

5 Terms and definitions

5.1 Basic dependability terms

The fundamental concepts and terms of dependability used in this document are

adopted directly from [21]. This section contains a short overview of the main terms

and definitions used for dependable systems. It should be noted here that the word

“system” is used in a very wide sense in this context. A system can denote anything

from a single SW-C to a complete vehicle with multiple networks and ECUs.

However, as the document is aimed at application level error handling, a system in

the rest of the document should denote a software application, potentially consisting

of multiple SW-Cs, possibly mapped over a set of (distributed) ECUs.

The term dependability is defined as “the trustworthiness of a system such that

reliance can justifiably be placed on the service it provides”. This means that a

dependable system is one upon which the user (either human or non-human) can

place its trust in that the services provided by the system are correct. The

dependability of a system is characterized by a set of attributes, compromised by a

set of impairments, and achieved and analyzed by a set of means.

The dependability attributes characterize, and profile, the dependability of a given

system. Some examples of attributes are availability, reliability, safety, confidentiality,

integrity, and maintainability.

During the construction and the operation of a system (here used in a wide sense – a

system can be any bounded entity, such as an entire ECU or a single SW-C), events

may occur which reduce the trustworthiness of the system by introducing faults into

the system. A fault is a transient or permanent change of the system such that its

integrity deviates from the expected correct integrity. During system operation, faults

may prevent the system from providing its intended service. These faults may be

from an internal source (such as software defects) or an external source (such as

external disturbances or aging of components). The events that may reduce the

dependability of a system are referred to as the impairments of dependability.

The mere presence of faults is, however, not sufficient to reduce the dependability of

a system. A fault must be activated, i.e., the part of the system in which the fault is

located must be exercised in some way during system operation (e.g., faulty code

must be executed, defective memory locations must be read, etc.). If this happens,

the result may be an error. If a fault is viewed as a disease, an error can be said to

be a symptom of that disease. An error is defined as an erroneous (soft) state in the

system, i.e., the state is different from the state the system would have had if the fault

had not been present. An error which is activated may cause other errors to occur in

the system. This process is called error propagation.

If errors propagate beyond the system barrier, i.e., if they are visible to the

environment of the system, the error transforms into a failure, which means that the

system no longer provides its specified functionality.

The causality chain, fault  error  failure, is also recursive in nature. Thus, a failure

of one system is perceived as a fault by the enclosing system (i.e. the former is a

Explanation of Error Handling on Application Level

AUTOSAR CP Release 4.3.1

14 of 78 Document ID 378: AUTOSAR_EXP_ApplicationLevelErrorHandling

- AUTOSAR confidential -

sub-system of the latter). For instance, a failure in a specific software component can

be seen as a fault in the overall application (consisting of a set of SW-Cs).

Therefore, we get the following sequence:

… failure  fault  error  failure  fault …

The methods used to achieve and analyze the dependability of a system are called

the means of dependability. The purpose of this document is to document and

investigate the means provided by AUTOSAR for the disposal of application

developers for implementing error handling.

Note that this document covers mechanisms which are active during system

operation. It does not cover means such as processes and methodologies for

achieving functional safety, as these apply during system development rather than

system operation.

5.2 Fault Detection, Isolation and Recovery (FDIR)

The process of handling faults during system operation is often referred to as FDIR,

which stands for Fault Detection, Isolation, and Recovery.

Detection: The crucial first step in handling a fault is of course to become aware that

it has occurred. Without this detection, no further activities can be performed. When it

comes to detection, the original fault is often very hard to detect. What can be

detected are the effects of the fault, that is, errors. These are detected by monitoring

the state of the system.

Errors can manifest in different ways. The main manifestations are

1. erroneous values in the system (data errors),

2. erroneous execution time (timing errors),

3. erroneous sequence or execution order (program flow errors).

4. erroneous access to system resources, such as memory

Errors may propagate and generate consecutive faults which in turn may result in

new errors, e.g., an erroneous data value is used as a pointer and causes a memory

access violation, which may create an erroneous value in another data value if a

value is written to the erroneous memory location. Most mechanisms used for

detection of errors allows the system to perform some action to find out more

regarding the source of the error (isolation) and to issue corrective or compensating

actions (recovery). Ideally, detection is done before the error has propagated any

further, thus making it possible to stop further propagation. However, in most cases

additional recovery actions are needed, such as stopping the offending component or

reconfiguring to alternate functionality.

Isolation: Once a fault (or error) has been successfully detected, damage

assessment and damage control needs to be performed, i.e. there is a need for

isolation. During isolation, efforts are made to find the root cause for the erroneous

state in the system, and information (e.g. regarding the spread and cause of the

error) is gathered for subsequent use during error recovery. It may not always be

possible (or practical) to find the root cause of the erroneous state. Note that isolation

剩余77页未读，继续阅读

MCU-X

粉丝: 3

AUTOSAR 4.3.1应用层错误处理详解

AUTOSAR_SRS_BSWGeneral.pdf

AUTOSAR_SWS_E2ELibrary.zip

AUTOSAR_EXP_ApplicationLevelErrorHandling.zip

AUTOSAR_EXP_MacroEncapsulationofInterpolationCalls.pdf

AUTOSAR_EXP_SensorInterfaces.pdf

AUTOSAR_EXP_FCDesignUpdateAndConfigManagement.pdf

AUTOSAR_EXP_AIOccupantAndPedestrianSafety.pdf

AUTOSAR_EXP_FunctionalSafetyMeasures.pdf

AUTOSAR_EXP_ModeManagementGuide.pdf

AUTOSAR_EXP_SafetyOverview.pdf

最新资源