引言
在功能安全的开发、测试过程中概念阶段的活动一般都是由主机厂负责，而从系统开发到单元实现则是由供应商负责，对于供应商所做的一系列测试通常称为零部件级测试。根据ISO 26262功能安全标准的划分，功能安全在零部件阶段的测试包括：软件单元测试、软件集成测试、硬件集成测试、嵌入式软件测试、软硬件集成测试。本次主要探讨软件在零部件阶段的测试。

---

---

目前功能安全零部件测试的困难

1. 来自OEM的认可压力：随着主机厂对功能安全的重视和投入，主机厂越来越专业，审核要求也越来越严格，不仅要求过ISO 26262产品认证和流程认证，并且亲自下场对各输入物及详细内容进行审查。
2. 技术储备不足：大多数零部件供应商没有专门的功能安全团队，缺少功能安全开发能力和测试能力。
3. 资源不足：大部分零部件供应商缺少完整的测试工具链，各阶段测试人员配备不齐。

目前国内的功能安全标准正处于由国家推荐性标准逐渐向强制性标准过渡的时期，加之在新能源汽车出海的大趋势下，功能安全标准也正在加速与国际接轨。未来功能安全标准将成为汽车供应链厂商的准入门槛之一。那么执行满足功能安全标准要求的测试已是刻不容缓且必须解决的问题，下面将依据功能安全标准和公司在软件测试方面的积累提供满足功能安全测试的解决方案。

一、软件单元、集成测试

软件单元、集成的静态测试

静态测试是指在不运行软件的情况下，检查软件是否符合业内通用的编码规范/建模规范，像MISRA、MAB等，尽早发现软件的数据流/控制流问题，以及选用一些代码度量的约束，来提高软件质量。

基于MBD的静态分析

模型的静态分析主要是通过选择合适的建模标准和模型度量指标来进行验证，它的分析原理就是利用模型的一些属性和结构信息来推断代码的行为和可能存在的问题。对于模型生成的代码也需要做代码静态分析。

建模规范选择：在进行模型静态分析时，依据使用的建模工具和要求来选择建模规则。

1. 所有基于MBD的开发都需要选择MAB建模规范；
2. 使用了Simulink 和 Stateflow 的模型工具需要选择MISRA SLSF；
3. 使用了TargetLink的模型工具需要选择MISRA TL；
4. 如果需要符合ISO 26262对于模型的标准要求，需要选择定制的功能安全规范。

工具选择：对于模型的静态测试通常选用MES的MXAM工具，MXAM是一款高度自动化的静态分析工具，可支持多种模型类型的检查，并且提供了符合ISO 26262标准的检查规范。

手写代码的静态分析

代码的静态分析主要从编码规范的检查、程序流和数据流的分析、代码度量分析等三个维度展开。它的分析原理是对编写的代码进行逐行检查，寻找潜在的错误、漏洞和不符合规范的代码结构。

编码规范选择：在进行代码静态分析时，通常依据使用的语言和遵循的规则来选用编码规范。

1. C代码：通常选用最新的MISRA编码标准MISRA C 2023；
2. C++代码：
   a. 基于C++98/03开发选用MISRA C++ 2008；
   b. 基于C++11及C++14标准选用AUTOSAR；
   c. 基于C++17的标准选用MISRA C++ 2023；
3. 考虑信息安全时需要遵循CERT和CWE规范。

工具选择：对于代码的静态测试通常选用Helix QAC，它支持多种编码标准，以及拥有业界领先的编码规范覆盖度，拥有丰富的命令行，更容易实现自动化，方便与持续集成系统进行融合。

软件单元、集成的动态测试

动态测试通过实际执行代码来验证软件的行为和性能是否符合预期，动态测试可以发现静态测试中未被检测到的缺陷，确保软件安全需求及安全机制执行正确，无非预期的输出，并为软件接口的一致性和完整性提供证据。

软件单元的动态测试

测试范围：软件单元详细设计规范、软件单元接口文档。

测试方法：
基于需求的测试：使用不同输入来激发软件单元代码中的各种执行路径，验证输出符合预期，从而验证软件单元设计规范和分配的软件安全要求满足设计要求。
接口测试：考虑软件单元输入信号的无效/有效等价类和边界值，模拟输入检测输出的正确性，从而验证软件单元与接口文档的一致性、输出的正确性。
故障注入测试：故障注入测试一般要修改被测的软件单元（比如改变变量的值，引入代码突变或破坏CPU寄存器的值），主要用来验证软件单元的“故障检测及处理”功能的正确性，以及软件的鲁棒性。

软件集成的动态测试

测试范围：软件架构设计文档、细化的软硬件接口规范。

测试方法：
基于需求的测试：验证多个单元或组件集成后的软件功能，正向、反向的功能验证。用来验证分配给软件架构的软件要求，确保软件架构能够满足系统级别的需求
接口测试：考虑集成的组件、模块输入信号的有效/无效等价类和边界值，模拟输入检测输出的正确性，以检查单元和单元或组件和组件之间数据的一致性和完整性。
故障注入测试：注入任意的接口故障以测试安全机制（例如通过损坏软件接口），以测试与安全机制相关的软硬件接口的正确性。

资源使用测试的目的是确认在最坏的情况下，资源CPU、ROM、RAM等的使用情况。只有在目标硬件上执行软件测试或目标处理器的仿真器支持资源占用测试时，才能正确评估软件资源占用情况，一般可以在PIL和HIL测试阶段进行验证。

背靠背测试针对于基于MBD的开发，要求对模型生成的代码和模型进行等效性验证。

软件动态测试环境

模型动态测试环境MIL：TPT + MATLAB/Simulink
模型的动态测试主要是对模型的功能和接口进行测试，在TPT中选择平台和被测模型，工具可以自动获取接口信息并生成测试框架。测试框架中包含test driver和被测模型，test driver在测试执行期间与被测系统（SUT）进行交互，通过测试框架将测试用例定义的输入信号激励给到被测系统（SUT），再回采被测模型的输出结果并对其进行评估。

代码动态测试环境SIL：PC端+交叉编译链
将模型生成的代码或手写代码编译成能在目标机上运行的代码，在PC端进行验证。

a. 模型生成的代码：TPT/FUSION + MATLAB/Simulink
用于对模型生成的代码进行背靠背测试，使用TPT的FUSION DLL调用Simulink生成的代码，对模型和模型生成的代码进行相同的输入，对比测试输出结果。

b. 手写代码：VectorCAST + 交叉编译链
VectorCAST支持300+种交叉编译链，它可以调用交叉编译工具将源码编译成目标机上的可执行代码，可以自动解析源代码生成测试套件，测试人员能够根据测试套件使用工具提供的测试用例生成方法或手动创建测试用例，然后测试套件和测试用例会被传输到模拟器或者目标板执行测试，最终将执行的结果返回到上位机界面以供查看。

二、嵌入式软件测试

嵌入式软件测试主要是验证在目标环境执行时满足软件安全需求（SSR），以及不包含与功能安全相关的非预期功能和特性。

测试范围：软件安全需求（SSR）。

嵌入式软件测试环境

a. 目标板+调试器 + TPT：
TPT用来集成调试器，作为上位机可以进行测试用例设计及测试执行；调试器可直接访问内存，读取或修改寄存器、变量数值，以达到对软件内部输入输出参数的修改及监控，另外调试器还可以读取MCU中资源占用情况及各个函数的运行时间。

在嵌入式软件测试阶段，使用“目标板+调试器+TPT”的测试方案可以验证：
①　对接收到的外部故障反馈、输入信息进行处理；
②　与外部模块的数据通讯校验；
③　可以验证芯片的内置安全机制，比例处理器、内存、看门狗、程序流的监控等；
④　资源使用测试
三、软硬件集成测试
软硬件集成测试旨在证明所集成控制器的软件和硬件正确的交互。

测试范围：技术安全需求（TSR）、软硬件接口规范（HSI）。

三、软硬件集成测试环境

a. 控制器 + CANoe + VT System
在软硬件集成测试阶段，“控制器 + CANoe + VT System”可以被用来测试技术安全需求（TSR）的相关要求，包括：技术安全需求的验证、安全机制的验证、内部接口验证和外部接口验证等。

另外，该测试方案还可以用来补充嵌入式软件阶段的测试，使用“目标板+调试器 + TPT”的测试方案一般不能完全覆盖软件安全需求的测试，比如一些涉及到电压采集、外部通讯的收发和外部模块对自身故障的检测处理等，可以使用HIL的方案辅助验证。

b. 控制器 + TPT + CANoe + VT System + 调试器
该测试方案主要是在普通的HIL环境下集成了调试器，可以用来测试软硬件接口（HSI）。软硬件接口的测试主要是依据接口的描述和功能进行验证，已确认硬件可以被软件正确的控制和使用。

总结

ISO 26262标准对零部件阶段的测试从模型、代码到最后的ECU都提出了要求，每个阶段的测试重点各不相同，主要目的就是为了更快更好的查出软件问题，保证质量。北汇除了能够提供上述的测试解决方案，还可以提供对应的测试服务。如果有需要或想了解更多信息，欢迎您来联系我们。