An article to introduce you to functional safety

Latest update time：2023-03-18

Reads：

introduction

An article to introduce you to functional safety

Security practices are becoming more standardized as various industries adopt a standardized set of practices during product development, design and testing. The automotive industry is no exception, and the functional safety standard ISO-26262 addresses the need for automotive-specific international standards for safety-critical components. ISO-26262 is a common functional safety standard for electrical and electronic (E/E) systems. This article will combine ISO-26262 to introduce functional safety from three aspects: what is functional safety, what is a functional safety engineer, and what does a functional safety engineer mainly do?

➡The main content of this article is divided into 2 parts (about 6500 words, 25 minutes to read)

What is functional safety

Background brief introduction

Due to the complexity of automobiles, the entire industry is working to provide component systems that meet safety requirements. For example, in a drive-by-wire throttle system, when the driver steps on the accelerator pedal and the sensor on the pedal sends a signal to the controller, the controller will comprehensively analyze signals such as engine speed, vehicle speed, pedal position, etc., and then send control instructions to the accelerator. ontology. Testing and validating things like drive-by-wire throttle systems is a challenge facing the automotive industry. The goal of ISO 26262 is to provide a unified safety standard for all automotive E/E systems.

The draft international standard for functional safety ISO-26262, which was born out of IEC-61508, was released in June 2009. Since the release of the draft, ISO-26262 has gained widespread attention in the automotive industry. Engineers view ISO-26262 as the state -of-the-art . The state of the art of a technology is the state of the art of developing a device or process at a particular time. Automakers are generally responsible for damages caused by product failure. ISO-26262 is a common standard in the automotive industry that provides a way to measure system safety.

Figure 1: Safety related systems

ISO-26262 uses V-Model to manage functional safety and standardize product development at the system, software and hardware levels. The ISO-26262 standard provides regulations and recommendations throughout the product development process – from the concept stage to product end-of-life. It details how to assign an acceptable risk level to systems and components and documents the entire testing process. Generally speaking, ISO 26262:

Provides the entire safety life cycle of the vehicle (management, development, production, operation, service, decommissioning) and supports the customization of necessary activities in these life cycle stages;
Provides a vehicle-specific risk-based approach to determine risk categories (ASIL) ;
Use ASIL to specify the necessary safety requirements for a project to achieve acceptable residual risk;
Provides requirements for verification and validation measures to ensure an adequate and acceptable level of safety;

Assessing Risk – Hazard Analysis and Risk Assessment (HARA)

When we have a clear definition of the newly developed model, the first shot of automotive functional safety was fired. We need to use HARA to identify and assess potential hazards. Generally speaking, OEM functional safety engineers will conduct a HARA analysis of vehicle-level functions to identify potential hazardous scenarios and determine the level of risk reduction required for each potential hazard. HARA considers the frequency and duration of exposure to potentially hazardous situations in a specific driving scenario (Exposure) , the amount of control required to correct the faulty behavior to mitigate the potential hazard (Controllability) , and the severity of the potential consequences if the faulty behavior occurs ( Severity) .

HARA is performed on characteristics at the vehicle level, not at the component or element level. For each potential hazard, a number of potential driving scenarios are considered. For example, in a forward collision mitigation system, the potential hazard of unintended braking will be assessed based on different driving scenarios, such as operating speed and driving conditions.

Assign a safety level - Functional Safety Integrity Level (ASIL)

During the HARA process, the OEM assigns an ASIL (Automotive Safety Integrity Level) level to each identified potential risk . ASIL is determined during the development process. Based on possible risks.

Figure 2: Functional safety level assessment

For example, if the speedometer of a certain car fails and no information is displayed from the start of the car, the scene can be classified as QM because the driver can easily perceive the failure and choose not to drive or drive very cautiously. In other words, the controllability of the scenario is very high, while the severity is very low. In contrast, if the vehicle cannot be controlled and the driver's brakes fail while driving at high speed, it can be classified as ASIL-D because the probability of serious injury is high .

To appropriately address these situations, ISO 26262 uses ASIL ratings to determine the rigor of development steps that suppliers must take and defines the requirements for a safety goal :

1. FIT rate (Failure In Time) : The FIT rate is the acceptable failure rate of a vehicle within a given time period. Vehicles must meet the FIT rate specified by the ASIL rating, but OEMs also have the flexibility to select FIT rates for the underlying components within the system.

2. Safety Concept : The safety concept determines how to detect faults and how to control faults. Systems with higher ASIL ratings require more stringent fault detection and response capabilities.

3. 安全要求（Safety Requirements）：安全要求规定了对任何给定故障的适当响应。比如，传感器检测到与内部安全相关的问题，如内存损坏，故障响应系统可能会在规定的时间内终止通过控制器的通信，以便向其他系统指示其故障状态。这是安全要求所描述的典型的安全机制——但故障响应系统并不总是恰当合适的。如：对于智驾功能，车辆可能采用故障操作系统，这要求冗余系统接管必要的时间，以使车辆处于最小的风险状态（比如，安全停车在路边）。对于系统故障，遵循严格的开发过程有助于增加该功能将以一种安全的方式运行的信心。

持续的测试和集成

汽车功能安全在整个开发过程中都采用了V模型。V模型要求，对于开发的每一步骤，在测试中都必须对应有一个相应的步骤。供应商定期评估其开发过程，以确保硬件和软件开发都遵循了所需要的步骤。

图3：V字开发模型

OEM，供应商或者独立的第三方公司对所有相关的工作产出物进行功能安全审核和评估，以确保功能安全的实现。功能安全需求一个全面的管理过程，以确保适当的监督和完整的系统集成。

什么是功能安全工程师，

功能安全工程师做什么？

关于什么是功能安全工程师？这个问题乍一看很好回答，但如果仔细思考下就会发现，想找到真实统一的答案却并不容易。比如拥有完善开发体系流程的大公司和初创的小公司，他们对功能安全工程师的定义大概率是不同的。思来想去，还是决定以一个新项目为例，来说明下什么是功能安全工程师以及在产品开发过程中功能安全工程师做什么。

报价阶段

1. 安全要求的分析与澄清：

功能安全工程师要对客户的安全输入进行分析，以确认公司内部产品的安全要求是否与客户匹配。通常会以会议的形式跟客户讨论和澄清相关安全要求。

2. 执行影响分析：

分析完客户的安全要求之后，一般功能安全工程师还会做影响分析，以确定公司内部的平台项目或者已经量产的其他客户项目是否有可以直接复用的功能，或者修改之后可以复用的功能。如果是全新的产品开发，则客户忽略影响分析。

3. 开发接口协议（DIA）责任划分：

弄清楚产品的开发边界之后，功能安全工程师要跟客户去确定每一方的开发责任范围，并明确开发过程中的产出物的责任方以及双方如何进行产出物的交互，双方对以上内容都打成一致后，DIA也就完成了。最后别忘了双方都需要在DIA上签字。

4. 准备项目功能安全计划和安全档案：

在报价阶段，功能安全工程师要根据项目的时间计划以及客户的安全输入来准备初版的项目功能安全计划（主要内容是计划管理和指导整个项目开发过程中的安全活动的执行，包含日期、关键节点、任务、可交付的成果、职责和资源等）以及安全档案（主要内容是与客户阐明所开发的产品已经按照ISO 26262的要求进行开发并实现了功能安全所准备的证据，包含产品开发各个阶段的关键产出物的记录，产出物的评审记录等）。

5. 准备评审会议：

以上内容都完成之后，功能安全工程师就可以跟审核员（Assessor）约评审会议了。在会上，审核员会根据功能安全工程师准备的证据对该项目的产品开发成熟度进行评估以确认是否满足当前的开发需要，以及是否有安全相关的风险，并输出当前阶段的评估报告。【注】：由于每家公司的开发流程不同，所以对功能安全评估次数要求也不同，但基本都会在项目的关键节点进行功能安全评估。

6. 相关项定义以及危害分析：

如果站在主机厂角度，功能安全工程师要完成所开发产品的相关顶定义（主要内容是在整车层面对相关项进行定义和描述，包括功能，及其与驾驶员、环境和其他相关项之间的依赖性和相互之间的影响），并对其进行危害分析和风险评估（主要是识别并分类由相关项中的功能异常表现引起的危害事件，以及定制防止危害事件发声或者减轻危害程度的安全目标及其安全等级，来避免不合理的风险），以便得出产品的顶层功能安全目标，以及功能安全概念，并打包发给供应商。

概念设计阶段

功能安全概念/要求开发： 功能安全工程师要完成功能安全概念/要求（FSC/FSRs）的开发。功能安全概念的主要目的如下：

1) 要根据功能安全目标定义产品的功能性或者降级的功能性行为；

2) 要根据功能安全目标定义关于合理地、及时地检测和控制相关故障的约束条件；

3) 要定义产品层面的策略或者是措施，以通过产品本身、司机或者外部的措施来实现故障容错或者减小对相关故障的影响；

4) 把功能安全要求分配给系统架构设计；

5) 确认功能安全概念并且定义号安全确认的准则；

图4：功能安全目标和安全要求层级

开发设计阶段

系统开发设计

1. 技术安全概念/要求开发：

功能安全工程师要完成（或者协助系统需求工程师完成） TSC/TSRs的开发。技术安全概念的主要目的如下：

a. 制定系统要素和接口关于功能、相关性、约束和属性方面实施中所需的技术安全要求；

b. 制定系统要素和接口实施安全机制的技术安全要求；

c. 制定在生产、运行、服务和报废中系统及其要素功能安全的相关要求；

d. 验证技术安全要求在系统层级是否符合功能安全要求并与功能安全要求一致；

e. 制定满足安全要求且不与非安全相关要求冲突的系统架构设计和技术安全概念；

f. 分析系统架构设计，防止故障并为生产和服务得出必要的安全相关特殊特性；

g. 按照各自的ASIL等级，验证系统架构设计和技术安全概念是否适用于满足安全要求；

图5：系统层面的产品开发

2. 安全机制的裁剪：

一般在产品设计初期，开发人员已经完成了关键芯片 （比如：Micro-controller, SBC, ASIC, Driver ICs, Intelligence Sensor等） 的选型。功能安全工程师在此阶段还要主导完成对芯片手册安全机制的裁剪活动，哪些是产品所必须用到的，哪些是可以裁剪的，并给出充分的理由。

3. 系统安全架构开发：

有了系统需求，系统架构，功能安全要求和技术安全要求后，功能安全工程师就可以开始设计（或者协助系统架构工程师设计）系统安全架构了。设计系统安全架构要注意以下几点：

a. 确保系统安全架构和前面阶段的系统架构设计的一致性；

b. 系统安全架构要能实现技术安全要求；（相应的安全要求和安全机制最好能体现在系统安全架构中）

c. 设计的系统安全架构能否被充分验证，预期的软硬件设计是否能满足此系统安全架构，是否方便于系统集成时测试的执行；

d. 设计时要充分考虑安全相关的内部和外部接口；

e. 如果此阶段需要进行ASIL等级的降级分解，要按照ASIL的要求进行分解；

4. 启动系统层面的安全分析：

有了完整的安全要求和系统安全架构之后，功能安全工程师就可以启动系统层面的安全分析（FMEA分析，FTA分析，DFA分析）了。执行安全分析的主要目的在于：提供证据证明系统设计实现了相应ASIL等级的功能安全要求、识别失效原因和故障影响、识别或者确认安全相关系统组件和接口。

a. FMEA分析 ：FMEA是一种定性的、归纳式的单点故障分析方法，主要是在早期检测和消除产品设计和制造过程中的薄弱点。

b. FTA分析 ：FTA是一种演绎式故障分析，它使用布尔逻辑来分析系统不期望的状态，以结合一系列较低级的事件。FTA的目标是分析在系统中发生的实际故障的路径，以定位系统故障的原因。

c. DFA分析 ：DFA的主要目的是通过分析潜在原因或者诱发因素，来确认设计中已经充分实现了要求的独立性 （Independence独立性是指在两个或者多个元素之间没有级联故障和共因故障，从而可能导致违背安全目标） ，或相互之间免于干扰 （FFI免于干扰是指在两个或者多个元素之间没有可能导致违反安全要求的级联故障） 。如果有必要的话，也可以制定相应安全措施，来减轻可能的相关失效。

图６：不同类型的相关性失效之间的关系

硬件开发设计

1. 硬件安全要求开发：

有了系统层面的安全要求、安全架构和安全分析的输入后，功能安全工程师就可以开始开发（或者协助硬件工程师开发）硬件安全要求了。硬件安全要求主要从分配给硬件的技术安全要求和系统架构设计中导出。

图７：硬件层面的产品开发

2. 硬件安全架构设计：

硬件安全架构设计主要是硬件架构师来负责，功能安全工程师协助支持，并支持做硬件架构的评审。硬件安全架构应尽量满足模块化、适当的粒度水平、简单性等特征。在硬件架构设计过程中，也可以参考ISO 26262第５部分中硬件架构的设计方法（Table1）。

图８－硬件架构设计原则

3. 软硬件接口列表（HSI）：

在硬件设计阶段，功能安全工程师还要协助硬件工程师完成软硬件接口列表的设计。在定义软硬件接口时，要考虑好以下的要素：

a. 存储器（RAM,ROM等）；

b. 总线接口（CAN, LIN等）；

c. 转换器　（A/D，D/A，ＰＷＭ）；

d. Ｉ/O口；

e. 看门狗（内狗，外狗）；

f. 多路转换器；

【注】：每家公司对HSI的责任划分也是不同的，有的可能要求系统工程师或者软件工程师主导HSI的定义。

图９：软硬件接口概览

4. 硬件安全分析：

功能安全工程师要协助硬件工程师进行硬件层面的安全分析，包括FMEA和FMEDA分析。

a. FMEA分析：硬件FMEA分析直接在系统FMEA分析的基础上继续对硬件组件进行分析就可以了。

b. FMEDA分析：FMEDA的计算，需要的输入比较多（如：安全目标，硬件失效率目标值，安全要求，安全架构，BOM表，Mission Profile，安全机制列表，SN29500的基础失效率等），有了这些输入就可以开始FMEDA的计算了，以检查所设计的硬件产品的三个指标值（SPFM，LFM，PMHF）是否满足相应ASIL等级的要求。

Figure 10: Hardware failure rate metric values

Software development and design

1. Development of software security requirements:

Similar to hardware development, with the input of technical safety requirements, system requirements and system architecture, hardware design specifications, software and hardware interface lists and software development environment, functional safety engineers can assist software requirements engineers to develop software safety requirements. Software security requirements generally originate from the technical security requirements assigned to the software or the requirements for software functions and characteristics (such as: the ability to safely perform related functions, related functions that enable the system to achieve or maintain a safe state, etc.) .

Figure 11: Product development at the software level

2. Software security architecture:

Software security architecture design is mainly the responsibility of software architects, with functional safety engineers assisting and supporting software architecture review activities. The design of software architecture should try to meet characteristics such as consistency, simplicity, verifiability, modularity, and maintainability. In software architecture design, you can also refer to the software architecture design methods in ISO 26262 Part 6 (Table2, Table3 and Table4) .

Figure 12: Software architecture design principles

3. Software unit design and implementation:

Software unit design and implementation are mainly the responsibility of software developers, and functional safety engineers can provide relatively limited support. Similar to software architecture design, software unit design should also try to meet characteristics such as consistency, maintainability, and verifiability. In the activities of software unit design and implementation, you can also refer to the software unit design method in ISO 26262 Part 6 (Table5, Table6) .

Figure 13: Design principles for software unit design and implementation

4. Software security analysis:

Functional safety engineers should assist software engineers in completing software safety analysis. Compared with hardware, there is no specific method for software security analysis. Some companies require software FMEA analysis; while some companies feel that using FMEA ideas to do software security analysis is not particularly suitable. In this case, a software key is usually used. Use the path analysis method to perform security analysis on software (the dynamic architecture and static architecture of the software are required to support the analysis) .

Test verification phase

Regarding the topic of testing at each stage, since few companies require functional safety engineers to perform testing activities, here we will only briefly talk about testing at each stage and what functional safety engineers do during the test verification stage.

Before each stage of testing begins, functional safety engineers should lead the tailoring activities of the ISO 26262 method. Functional safety engineers must work with system, software, hardware, and related test engineers to complete the tailoring of ISO 26262 methods, and sufficient and reasonable reasons must be given for the deleted methods. ("++" means that this method is highly recommended and generally cannot be cut out; "+" means that this method is recommended and can be cut if there are reasonable reasons; "o" means that this method is not recommended)

System test verification

Testing in the system phase generally includes the following types:

a) System function test: Verify whether the system function meets the system requirements

b) System integration testing: verify whether the interfaces between components meet the design requirements

c) DV test: DV is design verification, which verifies whether the product design meets the requirements. The DV test also includes environmental durability test, electromagnetic compatibility test, and electrical characteristics test.

d) PV test: PV is product verification, which mainly verifies whether the products produced on the production line meet the requirements. Generally, products after PV are qualified for mass production.

Hardware test verification

Testing in the hardware phase generally focuses on hardware functional testing, that is, testing based on relevant hardware requirements to confirm that the hardware circuit design is consistent with the hardware requirements.

Software testing verification

Testing at the hardware stage generally includes the following types:

a) Software functional testing: Verify whether the software implementation is consistent with the software requirements.

b) Software unit testing: Verify whether the unit design is consistent with the unit design requirements specification.

c) Software integration testing: Verify whether the integrated software meets software requirements and whether the interfaces between software components are consistent.

The above-mentioned system, hardware and software level testing and verification are respectively responsible for system, hardware and software test engineers. Functional safety engineers mainly focus on whether the relevant test results pass and whether the test coverage meets 100%. If there are test failures, will the test have any impact on the functional safety of the product? If there are any failed items, what are the retest results?

[Note]: Usually fault injection testing will be covered in functional testing, so fault injection testing is not separately included here. For some products, if the ASIC used has a safety manual, it is also necessary to perform fault injection testing on the tailored safety mechanism to ensure that the implemented safety mechanism meets the requirements.