功能安全介绍_功能安全 硬件

1

什么是功能安全

1

背景简介

由于汽车的复杂性，整个行业正在致力于提供符合安全要求的零部件系统。比如，线控油门系统，当驾驶员踩下油门踏板，踏板上的传感器向控制器发送信号时，控制器会综合分析如发动机转速、车辆速度、踏板位置等信号，然后将控制指令发送给油门本体。测试和验证线控油门系统等是汽车行业面临的一个挑战。ISO 26262的目标就是为所有汽车E/E系统提供一个统一的安全标准。

脱胎于IEC-61508的功能安全ISO-26262的国际标准草案于2009年6月发布。从草案发布开始，ISO-26262已经在汽车行业获得了广泛的关注。工程师将ISO-26262视为最先进的技术状态（state-of-the-art）。该技术的技术状态在特定时间是开发设备或流程的最高水准。汽车制造商一般要对因产品故障而造成的损害负责。ISO-26262在汽车行业是一个通用标准，它提供了一种衡量系统安全性的方法。

图1: 安全相关系统

ISO-26262使用V-Model来管理功能安全，并在系统、软件和硬件级别上规范产品的开发。ISO-26262标准提供了整个产品开发过程中的法规和建议——从概念阶段到产品报废阶段。它详细说明了如何为系统和组件分配一个可接受的风险级别，并对整个测试过程进行记录。一般来说，ISO 26262：

• 提供了汽车整个安全生命周期 （管理，开发，生产，运营，服务，退役），并支持在这些生命周期阶段中定制必要的活动；

• 提供了一种基于汽车特定风险的方法来确定风险类别（ASIL）;

• 使用ASIL来指定项目的必要安全要求，以实现可接受的残余风险；

• 提供了验证和确认措施的要求，以确保达到足够和可接受的安全水平；

2

评估风险——危害分析和风险评估（HARA）

当我们对新开发的车型有了清晰的定义后，也就打响了汽车功能安全的第一枪。我们需要用HARA来识别和评估潜在的危险。一般来讲， OEM的功能安全工程师会对车辆级的功能进行HARA分析，以识别潜在的危险场景，并确定每个潜在危险所需的风险降低水平。HARA考虑了在特定驾驶场景中暴露于潜在危险情况的频率和持续时间（Exposure），纠正故障行为以减轻潜在危险所需的控制量（Controllability），以及在故障行为发生时潜在后果的严重程度（Severity）。

HARA是在车辆层面的特性上进行的，而不是在零部件或者要素层面。对于每一个潜在的危险，都考虑了一些潜在的驾驶方案。比如：在前向碰撞缓解系统中，将根据不同的驾驶场景，如操作速度和驾驶条件，评估非预期制动的潜在危险。

3

分配安全等级——功能安全完整性等级（ASIL）

在HARA过程中，OEM为每个已识别的潜在风险分配了一个ASIL （Automotive Safety Integrity Level）等级。ASIL在开发过程中就已经确定了。根据可能存在的风险。

图2：功能安全等级评定

比如：如果某辆车的迈速表出了故障，从车子启动开始就不显示任何信息，场景可以归类为QM，因为司机可以很容易地感知故障，并且选择不开车或者非常谨慎的驾驶。换言之，场景的可控性非常高，而严重程度则很低。相比之下，如果车辆无法进行控制，驾驶员在高速行驶时刹车失灵的情况可以归类于ASIL-D，因为这时导致人严重受伤的概率很高。

为了适当地解决这些情况，ISO 26262使用ASIL评级来确定供应商必须采取的开发步骤的严格性，并定义了安全目标（safety goal）的要求：

1. FIT率（Failure In Time）: FIT率是车辆在给定时间段内可接受的故障率。车辆必须满足ASIL评级所规定的FIT率，但OEM也可以灵活地为系统内的基础组件选择FIT率。

2. 安全概念（Safety Concept）：安全概念决定如何检测顾故障及如何控制故障，具有更高ASIL评级的系统需要更严格的故障检测和响应能力。

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

4

持续的测试和集成

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

图3：V字开发模型

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

2

什么是功能安全工程师，

功能安全工程师做什么？

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

1

报价阶段

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

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

2. 执行影响分析：

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

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

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

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

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

5. 准备评审会议：

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

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

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

2

概念设计阶段

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

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

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

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

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

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

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

3

开发设计阶段

系统开发设计

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等级的要求。

图10：硬件失效率度量指标值

软件开发设计

1. 软件安全要求开发：

与硬件开发类似，有了技术安全要求、系统需求和系统架构、硬件设计规范、软硬件接口列表和软件开发环境的输入后，功能安全工程师就可以协助软件需求工程师来开发软件安全要求了。软件安全要求一般来源于分配给软件的技术安全要求或者软件功能和特性的要求（如：能够安全执行相关功能，能够使系统达到或者维持安全状态的相关功能等）。

图11：软件层面的产品开发

2. 软件安全架构：

软件安全架构设计主要是软件架构师来负责，功能安全工程师协助支持，并支持做软件架构的评审活动。软件架构的设计要尽量满足一致性、简单性、可验证性、模块化、可维护性等特征。在软件架构设计中也可以参考ISO 26262第６部分中软件架构设计的方法（Table2, Table3 和Table４）。

图12：软件架构设计原则

3. 软件单元设计和实现：

软件单元设计与实现主要由软件开发人员负责，功能安全工程师能提供的支持相对有限。与软件架构设计类似，软件单元设计也应尽量满足一致性、可维护性、可验证性等特性。在软件单元设计和实现的活动中，也可以参考ISO 26262第６部分中软件单元设计的方法（Table5, Table6）。

图13：软件单元设计和实现的设计原则

4. 软件安全分析：

功能安全工程师要协助软件工程师完成软件的安全分析。与硬件相比，软件安全分析没有特定的方法，有的公司要求做软件FMEA分析；而有的公司觉得用FMEA的思路来做软件安全分析也并不是特别合适，这时候通常采用一种软件关键路径分析的方法来对软件进行安全分析（需要软件的动态架构和静态架构来支持分析）。

4

测试验证阶段

对于各个阶段的测试话题，由于很少有公司要求功能安全工程师去执行测试活动，这里只简单聊一聊各个阶段的测试以及功能安全工程师在测试验证阶段要做些什么。

在各个阶段的测试开始之前，功能安全工程师要主导ISO 26262方法的裁剪活动。功能安全工程师要跟系统、软硬件和相关测试工程师一起，完成对ISO 26262方法的裁剪，被裁剪掉的方法要给出充分合理的理由。（“＋＋“代表高度推荐该方法，一般不能裁剪掉；“＋”代表推荐该方法，如果有合理的理由可以进行裁剪；“ｏ”代表不推荐该方法）

系统测试验证

系统阶段的测试一般包含以下几种：

a) 系统功能测试：验证系统功能是否满足系统要求

b) 系统集成测试：验证组件之间的接口是否满足设计要求

c) DV测试：DV是设计验证，验证产品设计是否满足要求，其中DV测试又包含环境耐久测试、电磁兼容测试、电气特性测试

d) PV测试：PV是产品验证，主要验证产线上生产出来的产品是否符合要求。一般PV之后的产品，就具备了批量生产的资格了。

硬件测试验证

硬件阶段的测试一般比较关注硬件功能测试，也就是基于相关硬件需求的测试，以确认硬件电路设计与硬件需求是一致的。

软件测试验证

硬件阶段的测试一般包含以下几种：

a) 软件功能测试：验证软件实现是否与软件需求一致。

b) 软件单元测试：验证单元设计是否与单元设计需求规范一致。

c) 软件集成测试：验证集成的软件是否满足软件需求，以及软件组件之间的接口是否一致。

上述系统、硬件和软件层面的测试验证分别由系统、硬件和软件测试工程师来负责。功能安全工程师主要关注相关的测试结果是否都通过，测试覆盖度是否满足100％。如果有测试失败项，该测试会不会对产品的功能安全有影响。如果有失效项，复测结果如何。

【注】：通常故障注入测试会涵盖在功能测试里，所以这里没有单独把故障注入测试拎出来。对于有些产品，如果用到的ASIC有安全手册，也需要对裁剪后的安全机制进行故障注入测试，以确保实现的安全机制满足要求。

3

参考文献

[1] ISO 26262:2018, Part1

[2] ISO 26262:2018, Part2

[3] ISO 26262:2018, Part3

[4] ISO 26262:2018, Part4

[5] ISO 26262:2018, Part5

[6] ISO 26262:2018, Part6

[7] ISO 26262:2018, Part9

[8] SEMANTIC SCHOLAR search, A free, AI-powered research tool for scientific literature