登陆

功能安全标准ISO26262解析（7-12)

来源：燃云汽车

2020-03-24

4191

功能安全标准ISO26262解析（七）: 诊断覆盖率评估

ISO 26262-5 Annex D

An evaluation of the diagnostic coverage to produce a rationale for:

1) the compliance with the single-point fault and latent-fault metrics defined in Clause 8;

2) the compliance with the evaluation of the safety goal violations due to random hardware failures as defined in Clause 9.

诊断覆盖率评估用来使用在FMEDA和FTA中。

A guideline in order to choose appropriate safety mechanisms to be implemented in the E/E architecture to detect failures of elements.

诊断覆盖率评估有助于选择合适的安全机制。

该附录中给出了一个实例，用来对常规的电子电气系统中常规元器件的常规失效模式的诊断覆盖率，分为60%(低)、90%(中)和99%(高)。

功能安全标准ISO26262解析（八）: ASIL等级分解

ISO 26262-9 Clause 5 Requirements decomposition with respect to ASIL tailoring

The objective of this clause is to provide rules and guidance for decomposing safety requirements into redundant safety requirements to allow ASIL tailoring at the next level of detail.

本章节的目的是为安全需求分解提供规则和指导，以便于将需求分解为冗余的安全需求，并使得下一级别的ASIL裁剪成为可能。

The ASIL, as an attribute of the safety goal, is inherited by each subsequent safety requirement.

每一条安全需求都从安全目标继承ASIL等级。

The functional and technical safety requirements are allocated to architectural elements, starting with preliminary architectural assumptions and ending with the hardware and software elements.

通过最初的架构假设，功能性和技术性的安全需求被分配给架构的每一个硬件和软件模块。

During the allocation process, benefit can be obtained from architectural decisions and the existence of independent architectural elements. This offers the opportunity:

在ASIL等级分配的过程中，架构的决定性和架构中每个模块的独立存在性为我们提供了如下机会：

1) to implement safety requirements redundantly by these independent architectural elements;

通过使用这些独立的架构模块，来冗余地实现安全需求。

2) to assign a potentially lower ASIL to these redundant safety requirements.

为这些冗余的安全需求定义一个更低的ASIL等级。

If there is no independence between the elements, the ASIL of the safety goal is inherited by each requirement and element.

如果在模块之间没有独立性，那么每一条需求和每一个模块直接继承上一级的安全目标ASIL等级。

NOTE 1 ASIL decomposition is an ASIL tailoring measure that can be applied to the functional, technical, hardware or software safety requirements of the item or system.

ASIL等级分解是一种ASIL等级裁剪的方法，该方法可以使用在功能、技术、硬件以及软件的安全需求中。

NOTE 2 As a basic rule, the application of ASIL decomposition requires redundancy of safety requirements allocated to architectural elements that are sufficiently independent.

作为一个基本的原则，ASIL等级分级的使用要求安全需求的冗余性，该冗余性分配给足够独立的架构模块。

NOTE 3 In the case of use of homogenous redundancy(e.g. by duplicated device or duplicated software) the ASIL with respect to systematic failures of hardware and software cannot be reduced unless an analysis of dependent failures show sufficient independence of that the potential common causes lead to a safe state. Therefore, homogenous redundancy is in general not sufficient for reducing the ASIL due to the lack of independence between the elements.

使用同类的冗余方法，例如重复器件或者重复软件，基于缺少模块之间的独立性，ASIL等级不能降低。

ASIL decomposition may be performed in the following subphases: ISO 26262-3: Clause 8 "Functional safety concept", ISO 26262-4: Clause 7 "System design", ISO 26262-5: Clause 7 "Hardware design", and ISO 26262-6: Clause 7 "Software architectural design".

ASIL等级的分解可以在如下的几个子阶段被执行：功能安全概念阶段、系统设计阶段、硬件设计阶段和软件架构设计阶段。

1. Prerequisites

输入：

--- safety requirements at the applied system, hardware or software level

待进行需求分解的系统、硬件或者软件的安全需求

--- architectural information at the applied system, hardware or software level

待进行需求分解的系统、硬件或者软件的架构信息

ASIL decomposition shall be performed considering each allocated safety requirement of the element.

需求分解执行时应考虑对模块的每一条安全需求进行分解。

--- diverse redundancy is used to cope with both systematic failures and random hardware failures;

不同的冗余可以用来处理系统失效和随机硬件失效。

--- homogeneous redundancy is used to cope with random hardware failures only.

同类的冗余仅仅可以用来处理随机硬件失效。

总结：

1. 分解对象：每一条安全需求，每一个系统模块、硬件模块或软件模块

2. 实施阶段：功能安全概念阶段、系统设计阶段、硬件设计阶段、软件设计阶段

3. 分解原则：独立性

4. 分解方法：

功能安全标准ISO26262解析（九）: 系统部分

1. Initiation of product development at the system level 产品开发系统级别启动

The ojective of the initiation of the product development at the system level is determine and plan the functional safety activities during the individual subphases of system development.

系统启动的目的是决定并计划系统开发过程中每个子阶段的功能安全活动。

输入：functional safety concept 功能安全概念 ISO 26262-3：8.5.1

project plan 项目计划 ISO 26262-2: 6.5.2

safety plan 安全计划 ISO 26262-2: 6.5.1

functional safety assessment plan 功能安全评估计划 ISO 26262-2: 6.5.6

输出： validation plan 验证计划

item integration and testing plan 集成和测试计划

2. technical safety requirements 技术安全需求阶段

The technical safety requirements specification refines the functional safety concept considering the functional concept and the preliminary architectural design.

技术安全需求在考虑功能概念和最初版架构设计的前提下，完善功能安全概念。

The technical safety requirements describe how to implement the functional safety concept. It is intended to detail the item-level functional safety requirements into system-level technical safety requirements, down to the allocation to hardware and software elements.

技术安全需求描述如何实施功能安全概念。目标是细化条目级功能安全需求到系统级别技术安全需求，并将技术安全需求分配到硬件和软件模块。

输入：functional safety concept 功能安全概念

validation plan 验证计划

safety goals 安全目标 ISO 26262-3： 7.5.2

输出：techinical safety requirements specification 技术安全需求文档

system-level verification report系统级别验证报告

3. system design 系统设计阶段

1) technical safety concept 系统技术层面的功能安全概念

2) system design specification系统设计文档

3) allocation of technical safety requirements to hardware and software and other technologies

分配系统安全需求到硬件功能安全需求、软件功能安全需求和其他方面技术的功能安全需求

a. If requirements with different ASILs are allocated to the same architectural element, this element shall be developed in compliance with the highest ASIL.

当多个ASIL等级分配到同一个架构模块时，该模块应该按照最高级别的ASIL等级进行开发。

b. internal and external interfaces of safety-related elements shall be defined precisely, in order to avoid other elements having adverse safety-related effects on the safety-related elements.

与安全相关模块的内部和外部接口必须精确定义，以避免其他模块对安全相关模块产生不利于安全的影响。

c. measures for the avoidance of systematic failures

避免系统失效的方法

(i): deductive and inductive analysis to identify causes and effects of systematic failures shall be applied.

演绎法和归纳法用来识别系统失效的原因和结果。

NOTE 1 The purpose of these analyses is to assist in specifying the design. At this stage, qualitative analyses are likely to be appropriate and sufficient. Quantitative analyses can be performed if appropriate.

FTA和FMEA的目的是支持确切设计。在这个阶段，定性的分析看上去比较合适和充分。如果合适的话，也可以进行定量的分析。

NOTE 2 The analysis is conducted at an appropriate level of detail。

分析的详细程度需要合适。

(ii) well-trust 最大程度可以信任

To reduce the likelihood of failures associated with new designs, well-trusted design principles for automotive systems should be applied. These including the following:

为了降低新设计的失效可能性，最大程度可以信任的原则被使用在汽车系统中。包括：

（a） Re-use of well-trusted safety architecture;

（b）Re-use of well-trusted design principles or designs for elements, hardware and software components;;

（c） Re-use of well-trusted mechanisims for the detection and control of failures;

（d） Re-use of well-trusted or standardised interfaces.

(iii) Sources of systematic failures within the item iteself that could contribute to the violation of a safety goal should be identified and avoided.

可能造成违背安全目标的系统失效原因应指明，并避免。

(iv) Sources of adverse safety effects on the item from other systems outside the item shall be identified and avoided or else their consequences shall be mitigated.

可能对安全有影响的其他系统模块原因应指明并避免。

d. measures for control of random hardware failures during operation

控制硬件随机失效的方法

(i). Measures for detection and control, or control, of random hardware failures shall be specified with respect to the system design.

为了检测或控制硬件随机失效的方法应指明。

EXAMPLE 1 Specification of diagnostics features of the hardware and their usage by the software to detect random hardware failures.

例如，硬件的诊断特性和软件对该诊断特性的使用情况应说明。

(ii) The target vaules for both metrics of FMEDA shall be specified for final evaluation at the item level.

FMEDA的两种度量SPF, LMF目标值应指明。

(iii) The target value for final validation at item level shall be specified.

FTA的PMHF目标值应指明。

(iiii) Appropriate targets for failure rates and diagnostic coverage should be specified at element level in order to comply with the target values of the SPF, LMF, PMHF.

为了满足SPF、LMF、PMHF的目标值，失效率和诊断覆盖率的目标值应指明。

e. allocation to hardware and software

分配需求到硬件和软件

Every technical safety requirement shall be allocated to hardware, software or both, either directly or by further refinement.

每一条技术安全需求都应该被分配到硬件或/和软件，可以直接分配，或者进一步完善后分配。

f. Hardware software interface specification (HSI)

The HSI shall be specified during system design and shall be detailed during hardware development and software development.

HSI应在系统设计阶段说明，并在硬件和软件阶段进行细化。

HSI shall include hardware devices of the component that are controlled by software and hardware resources that support execution of software.

HSI应包括被软件控制的硬件元器件和支持软件运行的硬件源。

功能安全标准ISO26262解析（十）: HSI

Hardware software interface specification (HSI)

ISO 26262-4：7.4.6.1 The HSI shall be specified during system design and shall be detailed during hardware development and software development.

HSI应在系统设计阶段说明，并在硬件和软件阶段进行细化。

ISO 26262-4：7.4.6.2 HSI shall include hardware devices of the component that are controlled by software and hardware resources that support execution of software.

HSI应包括被软件控制的硬件元器件和支持软件运行的硬件源。

ISO 26262-4：7.4.6.3 The HSI specification shall include the following characteristics:

HSI应包括以下内容:

a) the relevant operating modes of hardware devices and relevant configuration parameters;

硬件元器件的工作模式和配置参数

EXAMPLE 1 Operating modes of hardware devices can be: default, init, test or advanced modes

工作模式包括缺省、初始化、测试及其他模式

EXAMPLE 2 Configuration parameters can be: gain control, band pass frequency or clock prescaler

配置参数包括增益控制、带通频率、时钟分频等

b) the hardware featues that ensure independence between elements and support software partitioning;

确保硬件元器件相互独立并支持软件分割的硬件特性

c) shared and exclusive use of hardware sources;

共用或独有的硬件源

EXAMPLE 3 Memory mapping, allocation of registers, timers, interrupts I/O ports

例如：内存映射、寄存器分频、时钟、I/O口中断

d) the access mechanism to hardware devices;

硬件访问机制

EXAMPLE 4 Serial, parallel, slave, master/slave

例如串行、并行、从器件、主从器件

e) the timing constraints defined for each service involved in the technical safety concept;

技术安全概念中包含的时序约束

f) the hardware diagnostic features shall be defined, example protection against over-current, short-circuit, over-temperature

硬件诊断特性，例如过流保护、短路保护、过温保护等

g) the diagnostic features concerning the hardware to be implemented by the software shall be defined.

为了让软件运行的硬件诊断特性

功能安全标准ISO26262解析（十一）: 安全机制

ISO 26262-4： 6.4.7

1. The safety mechanisms shall be specified by technical safety requirements including:

安全机制通过分析技术安全需求来制定，包括：

a) the measures related to the detection, indication and control of faults in the system itself (self-monitoring of the system or elements);

系统和模块的自我管理：检测、指示、控制系统本身错误有关的方法。

NOTE 1 This includes the self-monitoring of the system or elements to detect random hardware faults and, if appropriate, to detect systematic failures.

自我管理包括对系统或模块的随机硬件错误的检测及对系统失效的检测。

b) the measures related to the detection, indication and control of faults in external devices interacting with the system;

EXAMPLE External devices include other electronic control units, power supply or communication devices.

外部器件错误的检测、指示、控制方法，包括其他电子控制器、电源和通信器件。

c) the measures that enable the system to achieve or maintain a safe state;

NOTE 2 This includes prioritisation and arbitration logic in the case of conflicting safety mechanisms.

使系统达到并保持安全状态的方法，包括冲突发生时的优先级处理和仲裁逻辑。

d) the measures to detail and implement the warning and degradation concept;

细化并实施报警和降级概念。

e) the measures which prevent faults from being latent(6.4.10).

NOTE 3 These measures are usually related to tests of measures during power up (pre-drive checks), operation, power down (post-drive checks) and as part of maintenance.

阻止错误成为潜在错误的方法，通常包括上电检测、下电检测、工作时周期性检测等。

2. ISO 26262-4： 6.4.9

For each safety mechanism that enables an item to achieve or maintain a safe state the following shall be specified:

对于每个安全机制，制定安全机制内容的同时，还应该包括如下几个方面：

a) the transition to the safe state, including the requirements to control the actuators;

切换到安全状态的条件，包括控制执行器的需求；

b) the fault-tolerant time interval;

错误的容忍时间；

c) the emergency operation interval if the safe state can not be reached by immediately switching off;

如果不能通过立刻断电来达到安全状态，需要指明紧急操作的时间。

d) the measures to maintain the safe state.

保持安全状态的措施。

功能安全标准ISO26262解析（十二）: HARA分析

ISO 26262-3： Clause 7 (HARA) Hazard analysis and risk assessment 危害分析和风险评估

1. Objectives 目的

The objective of the hazard analysis and risk assessment is to identify and categorise the hazards of the item and formulate the safety goals related to the prevention or mitigation of these hazards, in order to avoid unreasonable risk.

危害分析和风险评估的目的是鉴别和分类项目的危害，形成为了防止或降低这些危害而必须满足的安全目标，以避免不合理的风险。

2. Hazards shall be defined in terms of the conditions or events that can be observed at the vehicle level.

危害的定义要基于在整车级别可以观测到的条件或事件。

The consequences of hazardous events shall be identified for relevant operational situations and operating modes.

危害事件的结果应根据不同的工作条件和工作模式在确定。

NOTE If a fault induces the loss of several functions of the item then the situation analysis and hazard identification considers the resulting hazards from the multifunctional degradation of the item or vehicle. For instance, a fault in the vehicle power supply may cause the simultaneous loss of the functions "engine torque","electrical power steering" and the "front lights".

如果一个错误使得相关项的几个功能缺失，那么条件分析和危害定义时需要考虑相关项的多个功能降低导致的危害。例如，车辆电源的错误可能导致如下几个功能同时丢失：引擎扭矩，电控，前灯等。

3. All hazards identified during the previous stage shall be classified. 对所有的危害进行分级

4. hazard分析方法及步骤

(1) item definition: 相关项定义

---说明系统的功能，可以附加简明扼要的解释

---说明系统的边界

---说明哪些功能不包含在系统内

以上说明可以是文字的格式，也可以是框图的格式。

(2) 驾驶场景定义：