0. 标准要求
0.1 系统层级
0.2 硬件层级
0.3 软件层级
1. 验证的基本形式
验证是ISO26262中关于成果认可最重要的环节。
ISO26262对验证(Verification)的定义是检查对象是否满足特定的要求,验证的形式包括了
验证评审(verification review)、
走查(walk-through),
检查(inspection)、
验证测试(verification testing)、
模拟仿真(simulation)、
原型机验证(prototyping)和
分析(analysis包括安全分析、控制流程分析、数据流分析等等)。
其中关于验证方法的详细汇总及解释,可以参考下方文章;
ISO26262 Part1 之 Verification 的方法汇总
验证在功能安全活动不同阶段的对象也有差异
比如在产品概念提出阶段,验证的对象主要为:依据危害风险评估导出的安全目标以及根据安全目标定义的功能安全概念,如场景危害识别是否适用、相关性定义是否正确、是否与其他相关项定义的危害和风险评估一致、危害事件是否覆盖实际应用等。
如,在产品开发阶段,验证主要是针对硬件设计的架构,验证其需求规范、架构设计、模型或代码是否符合安全要求。
2. 验证的基本程序
验证以建立验证计划作为开始,如上述的产品各个开发阶段的验证都是从验证计划开始的。
3. 验证计划主要内容
1)所需验证的对象:组成待验证的成果清单,要考虑成果的复杂性,进行适当的拆分;
2)针对每个待验证的成果,确定相应的验证目的,确定验证目的时要充分借鉴前期的验证经验,如维修的历史数据、已经使用的经历等,这可以指导验证目的和制定的验证方法的剪裁;
3)对工作成果采用什么样的验证方法,评审/检查/走查/测试/仿真/分析,验证方法最终要细化为“验证规范”作为验证支持依据,同时要保证验证方法是充分的,必要时要进行几种验证形式的组合;
4)如果采用的是测试或者模拟作为验证方法,则要明确验证的环境和验证所需的设备,要充分考虑验证技术的成熟度,不能采用最新的未经过经验证明有效性的方法和设备进行验证;
5)分配验证资源;
6)验证过程中出现异常时,明确应该采取或建议采取的闭环活动;
7)对于哪些已经经过验证后,进行了变更的成果,制定回归策略,即对验证计划的剪裁(是部分重复验证,还是全部重复验证)。
4. 验证规范/测试用例
对于验证方法的细化就形成了验证规范,验证规范最需要细化的是测试用例。
1)测试用例的唯一识别性,即该测试应用到哪项成果,什么目的验证;
2)测试用例针对的是哪个版本的工作成果;
3)前提条件和配置:对验证目标采用何种预处理或配置,比如将MCU应用在什么场景下,配置什么功能或系统,如果对于通用型的要素,其会在很多场合应用,则需将要素置于一种通用的(覆盖多种应用场景的)条件下进行验证;
4)环境条件,就是与测试过程或模拟过程相关的物理条件,比如温度。
5)验证过程中要监测的行为,比如输出数据,可接受的范围,时间或容差的特性,测试时需要考核前后数据的变化趋势,就需要对初始值进行明确的定义;有可能存在不同的测试用例下,会存在多种预处理、配置或环境条件和规范,这时候可以采用一种明确能覆盖多种测试用例的验证配置进行验证。
6)测试通过和不通过的判据。
测试用例可以根据测试设备和测试环境、逻辑和时序关系、所利用的资源进行分组,比如对于可以分为回归测试用例或者完整的测试用例。
5. 验证结果评估
1)评估验证的成果是不是唯一的;
2)评估验证计划和验证规范的完整性和适用性;
3)评估验证过程中所用到的环境配置、验证工具及标定数据是否符合要求;
4)评估验证结果与预期结果的一致性;
5)综合给出验证通过或不通过,并对于不通过的给出具体的理由以及整改建议;
6)如果存在验证过程未按照验证计划或规范执行,需要给出理由。
单一层级的验证,比如只针对开发的硬件进行功能、性能等安全性的评估,并不能提供硬件满足安全要求的充分证据,比如:硬件与其他接口兼容性、硬件与其他已有硬件的匹配性、硬件对整车安全的贡献性、硬件开发的种种假设证明的有效性等等,这些都无法单独在硬件验证的层面进行评估。
因此,为充分评估开发硬件的功能安全,往往要通过将硬件与软件、其他要素、系统甚至整车集成起来,按照“验证原型机测试”的标准去考核。
ISO26262给出集成测试的相关规定汇总参考下方文章:
ISO26262 Part 4 之 系统及相关项集成
引用参考:
以上部分内容引用参考:https://mp.weixin.qq.com/s/rLMpvDLUNKNiuPdRgGHO7A
https://www.munik.com/newsinfo/6963855.html