ESCL功能安全测试实战

lsekfe

概述
　　整车电子电器软硬件复杂性越来越高，电子系统失效可能导致的安全风险也随之提高，车辆的安全性受到了更大的挑战。本文依据ISO 26262从功能安全测试的角度出发，以ESCL为测试对应，阐述符合功能安全标准的测试实现过程，基于Vector VT System的HiL系统开发相关测试脚本实现测试。
　　ISO 26262简介
　　ISO 26262系列标准是对IEC 61508系列标准的改编，以满足道路车辆中电子电器系统的特定需求，但它不是一个可靠性标准，并没有为可接受失效概率设定准确的数字，其基于概率论的定量危害分析仅限适用于硬件。对于整个系统的危害分析及风险识别，是基于车辆的使用场景、使用环境、操作方式以及系统间的交互，识别出系统危害事件，并根据危害事件的严重度、暴露率以及可控性以确定汽车安全完整性等级(ASIL)。
图1为ISO 26262系列标准的整体结构。 ISO 26262系列标准基于V模型，作为产品开发不同阶段的参考过程模型，其定义了一整套功能安全管理体系，称为安全生命周期，可分为概念阶段、产品开发阶段以及开始生产后阶段。
　　在产品开发阶段，ISO26262-4中对产品的测试流程提出了要求和建议，包括硬件-软件集成测试、系统集成测试及车辆集成测试，并为不同级别的测试提供了参考。

　　为了恰当的定义集成测试的测试案例,应考虑集成的层面,使用如图2中所列的恰当的方法组合导出测试用例。

　　ESCL功能安全需求分析及用例设计
　　ESCL（Electronic Steering Column Lock）是车辆防盗系统的一部分，具备以下功能： ①认证许可通过后给转向管柱上锁； ②认证许可通过后给转向管柱解锁。影响到功能安全需求的功能模块主要是异常上锁，如车速异常时上锁、车辆行驶时异常上锁以及车辆动力系统信号异常时异常上锁。下面以此为例，根据功能安全需求（FSR）及技术安全需求（TSR），结合ISO26262给出的用例设计指导方法设计测试用例。
　　· 功能安全一：车辆动力系统信号异常时转向锁上锁禁止
　　安全状态：禁止上锁
　　功能安全等级：ASIL A
　　FTTI：200ms
　　功能安全逻辑实现方案：
　　1）ESCL对车辆动力系统报文进行Checksum和Rolling Counter校验
　　2）ESCL接收处理车辆动力系统报文信号
　　3）ESCL在接收到车辆动力系统报文信号异常的200ms内进入安全状态
　　4）ESCL在接收到上锁请求时，禁止执行上锁命令
　　通过以上功能实现分析，可以将测试点分解为车辆动力系统报文Checksum异常、Rolling counter异常、车辆动力系统信号丢失通讯等，根据ISO26262用例设计指导方法，通过以下测试设计方法、测试环境及测试方案完成需求验证，如下表1所示：

　　表1 车辆动力系统信号异常时转向锁上锁禁止测试方法
　　针对以上需求，以车速信号超过阈值的需求为例，编写测试用例示例如下：

　　表2 车辆动力系统信号异常时转向锁上锁禁止测试用例条目
　　· 功能安全二：车辆行驶/车速信号异常时转向锁上锁禁止
　　安全状态：禁止上锁
　　功能安全等级：ASIL D
　　FTTI：100ms
　　功能安全逻辑实现方案：
　　1）ESCL对车速报文进行Checksum和Rolling Counter校验
　　2）ESCL接收处理车速信号及车速信号安全等级信号
　　3）ESCL在接收到车辆行驶信号异常100ms内立即进入安全状态
　　4）ESCL在接收到上锁请求时，禁止执行上锁命令
　　通过以上功能实现分析，可以将测试点分解为车速报文Checksum异常、车速报文Rolling counter异常、车速信号安全等级异常、车辆行驶时、车速信号丢失等，根据ISO26262用例设计指导方法，通过以下测试设计方法、测试环境及测试方案完成需求验证：

　　表3 车辆行驶/车速信号异常转向锁上锁禁止测试方法
　　针对以上需求，以车速信号超过阈值及车速信号安全等级组合的需求为例，编写测试用例条目如下：

　　表4 车辆行驶/车速信号异常转向锁上锁禁止测试用例条目
　　ESCL功能安全测试方案及测试分析
　　前面已经基于功能安全需求及技术安全需求分析了相应的需求点并根据ISO 26262的指导方法结合ECU适用性开展了用例设计，以下将阐述测试脚本的实现及运行的载体给出相应的验证分析。
　　· 功能安全验证测试平台方案
　　北汇基于Vector VT System+CANoe打造的HIL测试验证平台，可仿真实体DUT测试所需的测试环境。通过VT System可实现硬线故障注入，通过CANoe信号仿真可实现报文信号的故障注入，通过CANoe Test模块与vTESTstudio的联合编程可实现用例的快速设计实现及自动化测试验证，本测试平台测试验证方案如图3所示。

图3 功能安全测试验证平台方案

　　· 功能安全测试脚本开发
　　· 需求一开发：车辆动力系统信号异常时转向锁上锁禁止
　　通过vTESTstudio图形化编辑器基于路径覆盖法编写测试脚本，编写设计框图如图4所示，编写完成并编译成功后可以自动生成用例条目，在CANoe中调取后呈现的用例条目如图5所示。

图4 车辆动力系统信号异常时转向锁禁止上锁脚本设计图

图5 车辆动力系统信号异常时转向锁禁止上锁测试用例条目

　　· 需求二开发：车辆行驶时转向锁上锁禁止测试脚本开发
　　除了以上用例设计方式，还可通过采用将测试元素参数化的方式，结合边界值法、等价类划分法取点，并通过正交实验序列图自动生成参数化序列，如图6所示，最终通过一条母体 case直接调用并生成多条测试用例条目，如图7所示，当然vTESTstudio还支持其他用例设计方法，此处不再一一赘述。

图6 测试元素参数化设计图

图7 车辆行驶禁止上锁测试用例条目

　　· 测试结果与分析
　　1）以车辆动力系统信号异常时转向锁上锁禁止需求为例进行测试，测试用例结果如下图8所示。

图8 动力系统信号异常时转向锁上锁禁止测试结果

　　针对以上测试结果以“PrpsnActvn信号丢失，200ms内进入安全状态，禁止执行闭锁”为例，结果分析如下图9所示。测试结果表明，信号丢失136.195ms后，ESCL进入安全状态，并禁止执行闭锁，符合功能安全需求，另外，CANoe自动生成的测试报告也可以清晰明确的看到测试步骤及结果。

图9 动力系统信号丢失时转向锁上锁禁止测试结果分析

图10 动力系统信号丢失时，转向锁上锁禁止测试报告显示分析

　　总结
　　基于功能安全的测试，是当前与网络安全同样热门的主题之一，为了验证车辆电子系统的设计实现是否满足了所制定的功能安全要求，完备的且具有深度的测试是重要的保障手段。与传统测试开发或无功能安全要求的测试开发比较来看，更需要具备对测试方法论的理解、有测试经验的支撑，同时尤其需要对功能安全需求（FSR）及技术安全需求（TSR），甚至对实现方案有深度的理解，才能达到理想的效果。本文以ESCL的功能安全测试开发为例抛砖引玉，北汇信息具备基于功能安全的测试实践和经验积累，期待交流分享及合作的机会。