符合ISO26262标准的软件测试解决实施方案

符合ISO26262标准的软件测试解决方案

随着汽车行业的迅速发展，汽车电子电器E/E系统在汽车中的作用不断提高，ECU开发所占用的时间和成本也越来越高。与此同时，越来越多的电子控制系统（例如车身稳定控制系统ESP，防抱死制动系统ABS，自适应前照明系统AFS等）具有与安全相关的功能，因此对ECU的安全要求也越来越高。为了减少产品的开发时间和成本，降低由于安全问题而导致的维护甚至召回的风险，越来越多的整车厂和供应商开始重视汽车领域的功能安全问题，ECU软件功能安全的问题也成为汽车行业迫切需要解决的问题，车辆功能安全标准ISO 26262就在这样的环境和需求下应运而生，并于2011年11月正式发布第一版本，该标准是当前汽车业中最流行、最复杂、也是最重要的一份标准。

ISO 26262的目标是通过避免汽车E/E 系统故障行为可能导致的危害来提高E/E系统的功能安全。ISO 26262采用车辆安全完整性等级（ASIL）来判断系统的功能安全程度，ASIL由ASIL A（最低）、ASIL B、ASIL C及ASIL D（最高）四个等级组成，ASIL等级越高表示系统的功能安全评估越严格,相应的表示系统正确执行安全功能，或者说的避免该功能出错的概率越高，即系统的安全可靠性越高。

ISO 26262标准的组成架构由十个规范和信息指导文件组成，其中ISO 26262—4/5/6阐述的是系统级/硬件级/软件级的产品开发，使用嵌套的V模型定义了每个开发阶段的过程以及相应的工作产品。本解决方案主要阐明了在软件级产品开发阶段如何去理解ISO 26262的要求，并且指出了在实际的软件开发过程中如何结合ISO 26262的软件测试生命周期，通过包括软件测试工作的执行以及过程控制等方面来确保ECU 软件质量满足ISO 26262软件级功能安全相应等级的要求。

基于V模式的ISO26262软件测试生命周期

如图所示，基于V模式的ISO 26262-6软件测试生命周期可以划分为五个阶段：

静态分析需求和功能需求：在软件级产品开发初始化阶段和软件安全需求规范制定阶段确定了一些基本的嵌入式软件静态分析需求和功能需求，这部分内容是以后设计和测试的基础；

架构验证：在软件架构设计阶段，我们可以使用人工分析的方式来验证和测试软件架构层的内容，但是有条件的话最好使用合适的架构设计工具，在设计的过程中同时进行架构验证；

静态测试：在软件单元设计和实现阶段同时进行静态测试，可以使用开发辅助工具来进行静态测试，这样不必因为静态测试的活动而改变开发流程。

动态测试：在软件单元测试阶段以及软件集成和测试阶段，使用合适的动态测试工具进行动态单元和集成测试，

功能验证：在软件安全需求验证阶段，要根据ISO 26262-6的要求进行功能验证，包括进行ECU网络环境测试和实车测试，必要的时候进行HIL测试。

因为在静态分析需求中所需要满足的方法基本上都是属于静态测试的范畴的，因此我们以ASIL A为例，将软件测试内容分为静态测试、动态测试和功能验证三部分（注：架构验证暂时未包含在内），见下表。

表中所列举的静态测试内容里面要求采取多种的测试方法，例如‘低复杂度的强制要求’一般需要通过满足一定的度量指标来实现，度量指标包括圈复杂度、嵌套深度等等，而‘使用语言的子集’在汽车行业一般选择MISRA-C，通过强制使用编码规范来排除未定义行为或者实现定义行为等危险用法，除此之外静态测试还要求一些其他的测试方法，例如如果要满足更高的安全完整性等级的话，静态测试内容还需要包括运行时错误检测等，一般需要使用可靠性测试性的测试。

ASIL A所要求的动态测试要求能够基于需求分析和设计测试用例，因此需要在开发过程中提供对需求管理的支持，同时要求能够针对函数或模块提供覆盖度分析等。如果是更高等级的ASIL的话可能还需要进行不同环境的测试，例如模型在环测试（MIL）和软件在环测试（SIL），并在必要的情况下进行MIL和SIL 的对比测试。

软件安全需求的测试环境需要根据ASIL等级来进行选取，并且至少要在一个以上不同环境内执行测试。ASIL A所要求的ECU网络测试包括了网络中各ECU之间的相互作用，目的是确保ECU之间没有引起功能故障的相互干扰，而实车测试则是在真正的ECU软件运行环境中进行测试的方式，根据功能安全需求规范来进行，可以最直观地反映出ECU软件是否能够满足定义的功能安全需求。当然在必要的时候还需要进行硬件在环测试（HIL），通过仿真控制系统中传感器和执行器的硬件(Hardware)电气特性，为嵌入式控制器构建起一个控制回路 (Loop)，从而可以方便的在其中模拟被控对象的工作环境，对ECU的算法进行功能验证和测试。

针对前面划分的ISO 26262所关注的静态测试、动态测试和功能验证的要求，下面我们就来看一下解决方案中如何来满足这些需求。

符合ISO26262标准的静态测试

在静态测试中，静态分析主要包括规则检测和质量度量；可靠性测试主要进行运行时错误的检测。

上面提到ASIL A中针对编码准则的需求以及其他ASIL等级所强烈推荐的例如使用风格指南等需求都是不需要运行源程序来检测，因此都属于静态分析的范畴，虽然这些需求也可以通过人工检查的方式实现，但一个好的静态分析工具几乎可以自动化地执行表1中所有的要求，通过静态分析工具来帮助我们检查和满足这些规定可以明显地帮助组织更有效率地实现ISO 26262静态分析的相关需求。

针对静态分析的需求，我们提供DAC这样一个工具，它的主要功能包括：可以自动化地地执行C代码及汇编代码的静态分析，支持包括MISRA-C1998和2004的规则检测；提供项目、文件和函数质量度量；

提供方便快捷的代码结构生成，高亮显示代码结构并生成报告文档等。

在静态测试中，除了规则检测和质量度量以外，还有一类错误我们称之为运行时错误，例如数组越界、标量溢出等。运行时错误顾名思义是程序运行的时候才会出现的错误，针对这样的错误，使用传统的测试方式只有在动态地运行测试用例的时候才有可能发现，但是现在的测试工具可以使用先进的代码分析技术，不需要真正去执行源代码，而是使用数学方法分析源代码，发现代码中在运行的时候可能会出现错误的地方，从而实现通过静态测试的方式来达到一定的动态测试的效果。因为运行时错误会直接影响的程序执行的可靠性，所以针对这类错误的测试我们也可以称之为可靠性测试。

针对可靠性测试的需求，我们提供澳大利亚的一个运行时错误监测工具Goanna。其模型检测技术可以对所有函数提供高效的路径覆盖，检查超过90种运行时错误，包括空指针引用、危险的指针运算、未初始化/未使用变量、冗余/不需要的代码、除零、内存泄露、缓冲区溢出、释放后使用、不一致的释放、滥用的虚拟成员调用、算术错误、32/64位兼容性等。

符合ISO26262标准的软件代码SIL测试

在准备和设计阶段，大部分都是属于静态测试的工作，它在确认设计或实现的不足时非常高效，但它