广电计量技术分享 | ISO26262关于验证的要求

验证的基本形式

        验证是ISO26262中关于成果认可最重要的环节。

        ISO26262对验证（Verification）的定义是检查对象是否满足特定的要求，验证的形式包括了验证评审（verification review）、走查（walk-through），检查（inspection）、验证测试（verification testing）、模拟仿真（simulation）、原型机验证（prototyping）和分析（analysis包括安全分析、控制流程分析、数据流分析等等）。

        从验证本身的系统性和正式程度从小到大排序，验证的各个形式可以排为检查、走查、模拟仿真、原型机验证、分析、验证评审。

        验证在功能安全活动不同阶段的对象也有差异，比如在产品概念提出阶段，验证的对象主要为：依据危害风险评估导出的安全目标以及根据安全目标定义的功能安全概念，如场景危害识别是否适用、相关性定义是否正确、是否与其他相关项定义的危害和风险评估一致、危害事件是否覆盖实际应用等。如，在产品开发阶段，验证主要是针对硬件设计的架构，验证其需求规范、架构设计、模型或代码是否符合安全要求。

验证的基本程序

        验证以建立验证计划作为开始，如上述的产品各个开发阶段的验证都是从验证计划开始的。

 

验证计划要包括

        1）所需验证的对象：组成待验证的成果清单，要考虑成果的复杂性，进行适当的拆分；

        2）针对每个待验证的成果，确定相应的验证目的，确定验证目的时要充分借鉴前期的验证经验，如维修的历史数据、已经使用的经历等，这可以指导验证目的和制定的验证方法的剪裁；

        3）对工作成果采用什么样的验证方法，评审/检查/走查/测试/仿真/分析，验证方法最终要细化为“验证规范”作为验证支持依据，同时要保证验证方法是充分的，必要时要进行几种验证形式的组合；

        4）如果采用的是测试或者模拟作为验证方法，则要明确验证的环境和验证所需的设备，要充分考虑验证技术的成熟度，不能采用最新的未经过经验证明有效性的方法和设备进行验证；

        5）分配验证资源；

        6）验证过程中出现异常时，明确应该采取或建议采取的闭环活动；

        7）对于哪些已经经过验证后，进行了变更的成果，制定回归策略，即对验证计划的剪裁（是部分重复验证，还是全部重复验证）。

        对于验证方法的细化就形成了验证规范，验证规范最需要细化的是测试用例。

测试用例应具有

        1）测试用例的唯一识别性，即该测试应用到哪项成果，什么目的验证；

        2）测试用例针对的是哪个版本的工作成果；

        3）对验证目标采用何种预处理或配置，比如将MCU应用在什么场景下，配置什么功能或系统，如果对于通用型的要素，其会在很多场合应用，则需将要素置于一种通用的（覆盖多种应用场景的）条件下进行验证；

        4）环境条件，就是与测试过程或模拟过程相关的物理条件，比如温度。

        5）验证过程中要监测的行为，比如输出数据，可接受的范围，时间或容差的特性，测试时需要考核前后数据的变化趋势，就需要对初始值进行明确的定义；有可能存在不同的测试用例下，会存在多种预处理、配置或环境条件和规范，这时候可以采用一种明确能覆盖多种测试用例的验证配置进行验证。

        6）测试通过和不通过的判据。

测试用例可以根据测试设备和测试环境、逻辑和时序关系、所利用的资源进行分组，比如对于可以分为回归测试用例或者完整的测试用例。

        验证要求第二/三方验证，即不能用工作成果的完成人进行验证。验证完成后要对验证的结果进行评估。

验证结果评估需包括

        1）评估验证的成果是不是唯一的；

        2）评估验证计划和验证规范的完整性和适用性；

        3）评估验证过程中所用到的环境配置、验证工具及标定数据是否符合要求；

        4）评估验证结果与预期结果的一致性；

        5）综合给出验证通过或不通过，并对于不通过的给出具体的理由以及整改建议；

        6）如果存在验证过程未按照验证计划或规范执行，需要给出理由。

        单一层级的验证，比如只针对开发的硬件进行功能、性能等安全性的评估，并不能提供硬件满足安全要求的充分证据，比如：硬件与其他接口兼容性、硬件与其他已有硬件的匹配性、硬件对整车安全的贡献性、硬件开发的种种假设证明的有效性等等，这些都无法单独在硬件验证的层面进行评估。

        因此，为充分评估开发硬件的功能安全，往往要通过将硬件与软件、其他要素、系统甚至整车集成起来，按照“验证原型机测试”的标准去考核。ISO26262给出集成测试的相关规定。

 

集成与验证的相关规定

关于集成测试，某一开发的硬件要通过三个阶段集成至整车系统，完成安全目标的确认。

        集成测试是以软硬件集成为起点，而整车级的验证对安全目标是否达成是最具权威的。

        但是从集成的难度和所需要的资源的考虑，集集成阶段越高，集成验证的难度越高，占用资源越多，因此尽可能选择低阶段的集成策略。

        如何选择集成验证的策略：

        1）明确需要验证测试的目标，比如要验证安全机制对传感器的诊断，EDC对数据错误的诊断和控制等；

        2）定义这些承载这些测试目标的相关项和测试的要求（预期的行为，集成的等级），比如验证开发的硬件与接口的兼容性，就必须考虑硬件与系统的集成；

        3）确定了测试的目标和承载这些目标的相关项和测试要求，要进行梳理，确保每一条测试的目标都能够进行至少一次地验证，比如某项测试目标无法在软硬件集成阶段进行验证，则需要到系统集成阶段进行验证；

        4）要考虑硬件开发概念阶段是否采用了假设，如SEooC的开发，是基于应用假设为前提的，对这种假设需要在系统，甚至是整车的层面进行集成验证；

        5）如果系统集成时，存在多个可能的集成变体，即所谓的多配置，那么我们就要充分评估，在未来整车量产时，可能采用哪些系统配置，尽可能地包络这些系统配置（或形成系统的集合）完成系统级的验证。

        确定目标和相应的集成策略后，根据需要选择相对应的方法，ISO26262 part4 第7.4.2-7.4.4给出了三个集成阶段的测试方法，总体上包括：

A  鉴定式的测试

        1）功能和非功能的测试：对集成硬件的功能和性能对照规格书要求的测试；

        2）内外接口测试：包括模拟，数字输入输出测试、边界测试和等价类测试，评估接口功能兼容性、时序容错性。

B  仿真与试验相结合测试

        1）故障注入测试：采用特殊方法向运行中的测试对象注入故障，如骚扰、错误数据、延迟时序等；

        2）背靠背测试：在具有仿真模型和结果的情况下，采用实际试验对仿真模型和结果的差异进行评估和分析。

C  基于经验性测试

        1）错误猜测法测试：类似故障注入法，基于专家知识和经验数据预测被测对象可能错在的错误，然后设计评估方法去检查这些错误；

        2）来自现场经验的测试：直接从使用现场采集的数据，如试车时的运行数据；

3）长期测试：类似来自现场经验的测试，只是将普通用户作为测试者，收集实际使用条件下的数据。

D  鲁棒性测试

        1）资源使用测试：对集成系统所能容纳的最大负载，代码，功率等能力进行测试；

        2）压力测试：测试对象在高负载和恶劣环境下是否能够长期稳定运行的能力进行测试。