基于ISO 26262功能安全标准的汽车电子系统测试方法(上)

摘要：本文针对汽车电子产品功能安全要求，从测试的角度详细分析了ISO 26262标准中的具体要求，包括ISO 26262对测试流程的规定，对硬件集成和测试的规定，对软件集成和测试的规定，以及对产品集成和测试的规定。

关键词：ISO 26262；汽车电子；测试

DOI：10.3969/j.issn.1005-5517.2013.4.005

ISO26262标准概述

功能安全标准（ISO26262）是从电子、电气及可编程器件功能安全基本标准IEC61508派生出来的，主要定位在汽车行业定的电气器件、电子设备、可编程电子器件等专门用于汽车领域的部件，旨在提高汽车电子、电气产品功能安全的国际标准。

ISO26262从2005年11月起正式开始制定，经历了大约6年左右的时间，已于2011年11月正式颁布，成为国际标准。中国也正在积极进行相应国标的制定。

ISO26262主要内容包括：

·提供了汽车生命周期（管理，研发，生产，运行，服务，拆解）和生命周期中必要的改装活动。

·提供了决定风险等级的具体风险评估方法（汽车安全综合等级，ASILs）。

·使用ASILs方法来确定获得可接受的残余风险的必要安全要求。

·提供了确保获得足够的和可接受的安全等级的有效性和确定性措施。

功能安全受研发过程（包括具体要求，设计，执行，整合，验证，有效性和配置），生产过程和服务流程以及管理流程的影响。

安全事件总是和通常的功能和质量相关的研发活动及产品伴随在一起。ISO26262强调了研发活动和产品的安全相关方面。

符合性要求

1）如果要宣称符合ISO26262，那必须是符合其每个要求，除非有如下情况之一：

·根据ISO26262-2中，对不适用的要求进行安全行为的裁剪：

·针对不符合项，提出其说明理由，并对理由根据ISO26262-2进行评估：

2）所有安全行为的输出物都在ISO26262中有明确的规定。

3）下文中出现的列举各测试方法的表中，有不同的序号表示方法：

·连续的序号，比如1.2.3：所有的方法应被用于对应的ASIL等级，如果出现所列表中之外的方法背用于测试，则需要进行说明。

·可选的序号，比如1a，1b，1c：可以选择某个或多个方法进行测试，并优先考虑更高推荐指数的方法。如果多个方法被组合选择用于测试，则需要进行说明。

4）针对ASIL的各级，表中的每个方法都有对应推荐指数：

·“++”：最高的推荐指数

·“+”：建议使用

·“0”：不建议使用或不需使用

测试概述

ISO 26262-8中的第9节描述了“Verification”的目标、要求和建议、工作输出等。Verification是用于确保实现与需求的一致性，在安全生命周期的几个阶段中都会用到。包括概念阶段、产品开发阶段、生成和运营阶段。本文主要描述在产品开发阶段中的测试环节中，需要用到的各种测试要求和建议。

测试计划

1）在测试执行前，都需要建立测试计划，其主要包括几部分：

·测试范围：用于测试的产品内容：

·测试方法：用于测试的各种方法：

·测试标准：测试通过或失败的标准：

·测试环境：如果需要用到各种测试环境，比如仿真环境等，需要进行说明：

·测试工具：用到的各种测试工具：

·出现异常后的对策：

·回归策略：在测试对象发生变更时，指定其如何进行回归测试，比如全部回归、部分回归、和其他测试案例一起回归等。

2）测试计划的制定还需考虑到以下几个方面：

·测试方法的完整性：

·测试对象的复杂度：

·测试经验：

·测试技术的成熟性和风险。

测试规格

1）测试规格需要选择和指定用于测试的方法，并包括测试案例、测试数据和测试对象。

2）每个测试案例需要包括：

·序号：唯一的ID

·测试对象的版本号

·测试对象的条件和配置：针对测试对象的不同配置，需要选择合理的测试案例进行测试

·测试环境

·输入值和顺序

·期望行为：报刊输出值、输出范围、功能表现等

3）测试案例需要根据测试方法来分类。针对每个测试方法，除了测试案例外，还需考虑以下几方面：

·测试环境：

·相关性：

·测试资源。

测试执行和测试报告

4）按照上述章节中制定的测试计划和测试规格，进行测试的执行。

5）针对测试结果，其测试报告需包括以下几个方面：

·测试对象的ID：

·测试计划和测试规格的引用：

·测试环境、测试工具、标定数据：

·测试结果和期望值的符合度：

·测试通过或失败的结论，如果失败，还需要指明失败原因和修改建议：

·针对没有执行的测试案例，说明原因。

ISO26262中的测试阶段

ISO26262中涉及到测试的阶段共包括“硬件集成和测试”、“软件集成和测试”、“产品集成和测试”这三部分。下面章节分别介绍这三部分的要求和建议。

硬件集成和测试

ISO26262中“Part 5：ProductDevelopment：HardwareLevel”针对产品开发的硬件部分提出了专门的集成和测试要求和建议。

1 硬件集成和测试需要按照安全计划和验证要求来按计划进行：

2 硬件集成和测试需要按照产品集成和测试计划来进行：

3 针对变更，需要按照标准规定中的变更管理来对测试策略进行影响分析：

4 测试的设备可以按照国际标准（比如ISO17025）或公司标准来进行标定：

5 硬件集成测试的测试案例需要按照表1的方法进行设计：

6 针对硬件安全需求，硬件集成和测试需要对其安全机制实现的完整性和正确性进行验证，其方法如表2所不。

7 硬件集成和测试需要按照表3的方法进行外部压力环境下的鲁棒性测试。

软件集成和测试

软件单元测试

软件单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。ISO26262中规定了其相对应的要求和建议：

1 软件单元测试需按照“ISO26262-8节9中”的验证要求来有计划的定义和执行。软件单元测试的对象是具体的软件实现单元，在基于模型的软件开发过程中，软件单元测试的对象是其单元模型。

2 软件单元测试需要按照表4中列的方法进行，以完成以下目标：

·检查是否符合软件单元设计的具体要求：

·检查是否符合软硬件接口要求：

·检查功能是否正确实现：

·检查是否有异常功能：

·检查软件实现的鲁棒性，比如错误处理效率等：

·检查功能所需资源的完整性。

3 软件单元测试中的测试案例需要按照下表5中的方法进行分析设计。

4 软件单元测试中，对于需求的覆盖度、代码的覆盖度都需要进行衡量，具体方法如表6所示。如果覆盖度不够，还需要增加其他测试案例。

·代码的覆盖度都可以借助一些软件工具来实现：

·如果是基于模型的开发，其软件单元测试需要利用类似的模型的结构化覆盖指标来衡量：

·如果通过代码的打桩来进行测试覆盖度的衡量，必须保证打桩的代码和正常的代码的执行功能是一致的：

·对于覆盖度衡量目标，都需要给出一个合理理由来表示其不同的级别，对于无法覆盖的代码，可以通过检查等其他方法来进行验证。

5 软件单元测试需要尽可能的在真实的目标环境上执行，如果利用其他环境，则需要评估其与真实环境的差异、源代码和目标代码的差异，分析设计测试案例，以便在接下来的测试阶段中得到执行。

·测试环境的不同，会导致源代码或目标代码的不一致，比如不同处理器的位数不一样，会导致编译后的目标代码不一致。

·如果能利用目标环境中的相同处理器来运行软件单元测试案例，那是最有效的，但如果不行，则可以用处理器模拟器来代替，否则软件单元测试只能在开发系统中进行测试。

·软件单元测试可以在不同的环境中执行，比如模型在环测试（MIL）、软件在环测试（SIL）、处理器在环测试（PIL）、硬件在环测试（HIL）等。

·在基于模型的开发系统中，软件单元测试可以在模型级别进行，但模型与代码的执行比较测试必须要做，以保证模型与自动生成的代码的结果一致性。

软件集成和测试

软件集成和测试主要对实现的各软件模块进行集成，并验证其嵌入式软件实现是否符合软件架构设计。该阶段的要求和建议如下：

1 软件集成计划应该描述层次化的集成单个软件单元进软件组件中，直到嵌入式软件完全集成，并且应该考虑如下：

·软件集成功能的相互关系：

·软件集成和软硬件集成的相互关系。

注意：对于基于模型的开发，可以先集成各模型，然后对集成好的模型进行自动代码生成以完成整体软件的集成。

2 软件集成测试根据ISO26262-8：2011，第9节计划，定义并且执行。软件集成测试的测试对象是软件组件。对于基于模型的开发，测试对象可以是和软件组件相关的模型。

3 软件集成测试需要按照表7的方法进行，以完成以下目标：

·检查集成的软件是否和软件架构设计一致：

·检查集成的软件是否满足软硬件接口规格：

·验证功能的正确性：

·检查其鲁棒性，比如错误检测、错误处理机制的有效性：

·检查是否有足够的资源来支持。

4 测试案例需要按照表8中的方法进行分析设计。

5 对于软件架构级别的需求测试覆盖度，可以用来衡量测试的完整性，以及用于证明没有设计之外的功能实现。如果有需要，可以增加新的测试案例，或者提供一个合理的理由说明。

6 为了评估测试案例的完整性，同时确保没有多余的功能，根据表9列出的指标需要衡量出其结构覆盖率。如果覆盖率不够高，要么需要添加额外的测试案例，或者提供一个合理的理由说明。例如，结构覆盖率的分析可以用于发现测试案例的不足、无用代码、无效代码或者多余功能等。

·结构覆盖率可以利用工具计算出来。

·如果是基于模型的开发，结构覆盖率可以通过模型级别的模型结构覆盖率来统一计算。

7 作为产品的一部分，嵌入式软件需要被验证其包含设计的所有功能。如果嵌入式软件包含了设计之外的功能（比如用于调试的代码），则这些功能需要被验证是不影响软件的安全需求的。如果这些设计之外的功能在真实产品中保证不会被激活执行，那也是符合这个要求的：否则删除这些功能，也需要按照需求变更流程来统一处理。

8 软件集成测试需要尽可能地在真实环境中运行，如果不行，则需要评估测试环境与真实环境的差异性，并针对这些差异，在后续的阶段的真实环境的测试中设计专门的案例来执行。

·测试环境的不同，会导致源代码或目标代码的不一致，比如不同处理器的位数不一样，会导致编译后的目标代码不一致。

·针对各种测试，需要建立合适的测试环境。比如目标处理器的测试环境、仿真处理器的测试环境、开发测试环境等。

·软件集成测试可以利用模型在环测试（MIL）、软件在环测试（SIL）、处理器在环测试（PIL）、硬件在环测试（HIL）等测试手段进行测试。

软件安全需求验证

本阶段的目标是验证嵌入式软件符合软件安全需求，其所规定的要求和建议如下：

1 软件安全需求的验证需要制定计划，定义再执行。

2 为了验证嵌入式软件实现了软件安全需求，表10列了所需的测试环境。注意：已有的测试案例，例如在软件集成测试阶段使用的可以重用。

3 对于软件安全需求实现的测试需要在目标硬件平台上完成。

4 软件安全需求验证的结果需要考虑下面这些因素来评估：

·和预期结果一致：

·软件安全需求的覆盖率：

·成功或失败的标准。

（未完待续）