MUNIK解读ISO26262：功能安全之验证活动

回到本文的源头文章“ISO26262标准解读”，请点击链接：ISO26262 Functional Safety of Automotive汽车功能安全服务

0 导读

验证活动在功能安全领域中的重要程度不亚于开发活动，本文将为大家介绍功能安全的验证活动都包含哪些内容

首先，验证活动适用于以下安全生命周期阶段

--概念阶段

--产品开发阶段

--生产运行阶段

验证活动可以简单分为四类

1. 验证类型

1.1审查：各类安全活动工作成果的检查，组织相关人员以会议或其他形式对已建立的审查清单逐条评审，例如Verification Review和Confirmation Review

1.2分析：为了排除开发阶段有可能产生的系统性失效，会对设计输出进行各类分析活动。常见的有安全分析、DFA和FMEDA等

注：系统性失效是以确定的方式与某个原因相关的失效，只有对设计或生产流程、操作规程、文档或其他相关因素进行变更后才可能排除这种失效。

1.3仿真模拟：在设计阶段通过仿真工具搭建模拟的设计运行状态来验证设计方案的可行性与数据的准确性，常见的如EDA仿真工具等

1.4测试：通过样品来实际测试设计阶段的各项数据能否满足期望的功能性能，可以覆盖仿真无法实现的某些验证条目，并且数据更加真实可靠。对于随机硬件失效，通常用测试的方式来验证更具有说服力。

随机硬件失效：在硬件要素的生命周期中,发生的服从概率分布的不可预测的失效

2.验证内容

说完验证的类型，再来讲下验证活动一般涉及哪些内容

2.1验证计划

验证计划的意义在于能够让验证活动正确地、有序地、适时地执行。一个优秀的验证计划可以在最短时间内最大限度的利用可调配的资源，参与验证的人员只需根据计划按时完成分配给自己的任务即可，最终就能够准确得到期望的验证结果。

2.2验证规范

验证规范指导验证活动在什么环境下完成哪些验证项，通过什么方式以及需要达到怎样的标准，确保验证活动能够有效得出待验证项的结果。

2.2.1测试用例简介

测试用例的作用：为各类的测试目标建立规范的测试程序，测试项目类似的测试目标可共同完成某测试用例规范下的测试活动

测试用例必要信息：

测试用例的唯一识别（为测试用例建立编号以互相区分）；

待验证项的验证环境以及配置（使用测试用例的准备工作）；

测试用例的输入与输出类型；

测试用例期望的输出结果；

确定测试用例通过和不通过的准则等。

2.3验证报告

验证报告需要记录验证过程中出现的值得被记录的异常或现象；验证规范中定义的验证环境与特殊验证过程，以及用到的验证工具与验证方法；每项验证的输出数据及数据分析结果；验证通过或不通过的明确陈述，如果验证不通过，陈述应包含不通过的理由和对所验证工作成果进行修改的建议。

3.独立性要求

关于验证活动的执行人也是有特殊要求的，并不是任意成员即可担任。

就Confirmation Measure而言，不同的安全活动需要的人员独立性要求不尽相同。

例如：在ASILB的要求下，HARA（危害分析和风险评估）的执行人员独立要求为I3等级，而安全计划的执行人员独立性要求则为I1等级

注：独立性要求I0~I3由低到高

l                      I0：宜执行认可措施；但如果执行，应由与负责创建工作成果的人员不同的人员执行；

l                      I1：认可措施应由与负责创建工作成果的人员不同的人员执行；

l                      I2：认可措施应由独立于负责创建工作成果的团队的人员执行，即由不向同一个直接上级报告的人员执行；

l                      I3：认可措施应由在管理、资源和发布权限方面与负责创建对应工作产品的部门独立的人员执行。

4.总结

最后，还是要强调一次，对于功能安全来说验证活动的重要性甚至要略高于开发活动。一个车载产品的设计固然重要，但真正让它能在车辆上运行并且保障用户的安全靠的还是无数次验证迭代，最终形成一款符合功能安全要求的车载产品。