随着新能源汽车迅猛的发展，各类车型频频面世，同时辅助驾驶/自动驾驶等智驾功能也在不断迭代，使得整个汽车系统的复杂性越来越高，最终导致消费者不得不对如今的汽车质量和安全性提出质疑。
如何打破质疑？
那就不得不搬出我们的主题了**----功能安全。**
本文主要针对功能安全定义、测试用例开发及测试流程进行概念上的阐述与简要的介绍。
- 功能安全定义
不了解功能安全的过往，又怎知它的难得可贵呢？
从功能安全的提出到如今的标准成熟，可谓经历了一个漫长的发展历程，具体如图1所示：
图1-功能安全发展史
那功能安全到底是什么呢？
功能安全定义：Absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems（避免因电子电气系统故障而导致不合理的风险）。
通俗点理解：功能安全就是指汽车即使出现电子电气故障，但这个故障也是可控的，不会出现"车毁人亡"类的延伸风险。
既然已经知道功能安全的定义了，如果想要更深一步探索，那就不得不提及为其量身定制的专用标准------ISO26262。
图2-ISO26262图解
ASIL 分析主要由严重度（S）、暴露率（E）、可控性（C）三部分构成，其中所谓的暴露率是指事件场景的暴露率，而非功能失效本身的暴露率。
|-----------------------|---------------------------------|-------------------------------|
| | 定义 | 备注 |
| 严重度Severity（S） | 发生故障的严重程度 | S值越大则故障越严重，S值根据轻微到严重分为S0至S3四级 |
| 暴露率Exposure（E） | 故障发生的时长占平均运行时长的比例，用来表征故障发生的概率大小 | E值越大则故障发生的概率越大 |
| 可控性Controllability（C） | 故障发生以后，是否可以对故障状态加以控制 | C值越大则越难以控制 |
表1-S/E/C简介
分析出S/E/C数值有什么用呢？
分析至此也不难看出，一项需求发生故障之后的安全风险，可以用公式计算得出：
Risk=S * E * C
计算出此安全风险后，可依据此风险等级采取相对应的措施，从而避免因电子电气系统故障而导致不合理的风险。
|---------------------|---------|-----------|-----------|----------|
| 严重程度 | 可能性 | 可控性 |||
| 严重程度 | 可能性 | C1 （简单可控） | C2 （正常可控） | C3 （不可控） |
| S1 (轻度和中度损伤) | E1(非常低) | QM | QM | QM |
| S1 (轻度和中度损伤) | E2（低） | QM | QM | QM |
| S1 (轻度和中度损伤) | E3(中等) | QM | QM | A |
| S1 (轻度和中度损伤) | E4(高) | QM | A | B |
| S2 (严重且危及生命) (可能存活) | E1(非常低) | QM | QM | QM |
| S2 (严重且危及生命) (可能存活) | E2（低） | QM | QM | A |
| S2 (严重且危及生命) (可能存活) | E3(中等) | QM | A | B |
| S2 (严重且危及生命) (可能存活) | E4(高) | A | B | C |
| S3 (危及生命的致命伤) | E1(非常低) | QM | QM | A |
| S3 (危及生命的致命伤) | E2（低） | QM | A | B |
| S3 (危及生命的致命伤) | E3(中等) | A | B | C |
| S3 (危及生命的致命伤) | E4(高) | B | C | D |
表2-ASIL评级表
注：比如车辆的迈速表出了故障，车子启动开始就不显示任何信息，此场景可归类为QM，因为司机可以很容易的感知故障，并且选择不开车或者非常谨慎的驾驶，可以理解为，场景可控性非常高，严重程度很低；相比之下，如果车辆无法进行控制，驾驶员在高速行驶时刹车失灵的情况可以归类于ASIL-D，因为此时导致人严重受伤的概率很高。
- 功能安全测试用例开发
如何开发及编制测试用例呢？
依据所提供的功能安全文档，针对电子电气系统故障所采取的安全措施项，设计相关测试用例，以确保发生故障时正确响应，从而避免不合理的风险**。**
**功能安全文档：**包括软件需求文档、架构设计文档、单元设计文档等。
图3-功能安全文档概括及目标
**功能安全文档检查项：**属性是否完整、ASIL等级、FTTI时间、验证方法、验证准则、承接元素、安全机制描述和功能描述是否清晰等。
注：因为所有的测试用例开发源都在功能安全文档上，如果源头产生错误，那对后续的用例开发编制及测试会产生很大的影响，故在开始前需仔细检查。
功能安全文档检查无问题后，便可以开始着手开发编制测试用例。
- 仔细阅读和理解需求文档，识别关键功能和性能点，以及可能的边界条件和异常情况；
- 将整体需求划分为更小的、可测试的需求单元（或称为测试点）。对于每个测试点，明确前提条件、预期输出结果和可能的执行路径。根据功能安全需求，确定测试的范围，包括需要测试的功能点、测试的边界条件、预期的测试结果等；
- 根据测试范围，设计具体的测试用例。测试用例应覆盖所有可能的正常操作场景和异常场景，确保系统在不同情况下都能保持安全性能。
图4-功能安全测试点
|---------------|-------------------------------------------------------------------|
| 类别 | 简述 |
| 故障注入测试用例 | 汽车控制器故障注入测试用例是为了验证汽车控制器(ECU)在面临各种潜在故障情况下的鲁棒性和安全性。 |
| 边界值测试用例 | 边界值的取值依据输入的范围区间不同而有所不同，但是都需要用上点值、离点值和内点值，只是取点的位置不同，边界点分为上点、内点和离点。 |
| 失效模式和影响分析测试用例 | 根据失效模式和影响分析的结果，设计相应的测试用例，来验证系统在各种失效模式下的安全性能。 |
| 通信故障测试用例 | 测试系统在通信链路中出现故障或异常情况时的安全性能，例如节点丢失、信号延迟等。 |
| 人机界面测试用例 | 测试系统的人机界面是否符合人体工程学原理，以确保用户在操作系统时不会因为界面设计不当而引发安全问题。 |
表3-功能安全测试用例编制方法
注：功能安全测试用例是为了验证系统在发生故障或异常情况下的安全性能而设计的测试用例。
- 功能安全测试流程
**功能安全测试流程：**确认测试范围→覆盖测试需求→明确测试目标→分配测试环境→应用测试设备→采取测试方法→得到测试结果。
前三项流程上文已覆盖，便不过多的叙述，针对后续流程，我们逐一介绍。
分配测试环境：
因功能安全测试范围广泛且深入，且测试方法也较为复杂繁琐，故所需要的测试环境也多种多样。目前测试环境主要包括：单件测试环境、多件交互测试环境、整车级低压台架测试环境、整车级高压台架测试环境、实车测试环境等。
应用测试设备：
1、对于总线类故障注入测试项，推荐使用Vector总线采集和记录设备，如CANoe配合VN1640A/VN5650和总线记录仪GL5000系列；
2、对于电压、电源故障测试等测试项，可采用不同等级的电源模拟器进行调控测试；
3、对于节点丢失、信号延迟、CAN信息量过大导致丢包等通信异常测试项，可采用连接VT机箱、高压或低压BOB控制盒等进行操作测试。
采取测试方法：
以下通过一个应用实例，简单介绍一种测试方法。
安全目标：ACC激活时，只有驾驶员未踩刹车时，才可以输出大于0的推进扭矩。
安全状态：ACC关闭纵向控制。
测试用例：
|------------------|--------------|---------------------------|--------|------|
| 用例编号 | 初始状态 | 操作步骤 | 期望结果 | 测试环境 |
| FunctionSafety-1 | 车辆启动，进入ACC模式 | 使刹车踏板信号输出为有效值 | 推进扭矩=0 | 实车 |
| FunctionSafety-2 | 车辆启动，进入ACC模式 | 使刹车踏板信号输出为无效值（invalid） | 推进扭矩=0 | 实车 |
| FunctionSafety-3 | 车辆启动，进入ACC模式 | 使刹车踏板信号输出为无效值 （CRC错误） | 推进扭矩=0 | 实车 |
| FunctionSafety-4 | 车辆启动，进入ACC模式 | 使刹车踏板信号输出为无效值 （counter错误） | 推进扭矩=0 | 实车 |
| FunctionSafety-5 | 车辆启动，进入ACC模式 | 使刹车踏板信号丢失 | 推进扭矩=0 | 实车 |
表4-测试用例
测试方法：
- 将ECU搭载到实车上，连接CANoe等设备；
- 启动车辆，激活ACC，并检查实车无其他故障；
- 在ACC模式行驶过程中，通过CANoe注入刹车踏板信号的无效值等，检查ECU的功能表现与预期结果是否一致。
四、结语
本文主要从功能安全定义、测试用例开发及测试流程三个方面展开介绍，希望能对各位小伙伴理解功能安全理念和基本测试内容有一定的帮助，后续我们会根据实际项目推出更多更深入的针对功能安全应用实例的文章，敬请期待。