ISO26262功能安全验证和确认

ISO 26262将功能安全开发融入了广为熟知的“V模型”开发流程中。根据系统/软件/硬件三个层级的划分，ISO 26262共涉及三个“V模型”：

“V模型”中的功能安全开发，截图来自ISO 26262

“V模型”可以简单概括为三步：

• 确定需求

• 实现需求

• 验证需求

在前面的系列文章中将重点放在了“V模型”的左边的功能安全活动上，本文将对右边展开说明，即功能安全验证（safety verification）和功能安全确认（safety validation）。

1. Verification (验证) 和validation (确认) 辨析

读者如果查英文字典会发现，verification和validation的释义十分接近，功能安全国标GB/ T 34590中将这两个词分别翻译成“验证”和“确认”，实际上单看这两个词还是会让读者产生含义重合的印象。因此在开始本文之前，有必要对这两个概念进行辨析。

维基百科上对这两个词的解释非常到位：

• Verification：Have we made what we were trying to make? （预期的事情有没有实现？）

• Validation: Are we trying to make the right thing? （做的事情是否正确？）

沿着这个思路理解功能按照开发中的概念，可以得到如下解释：

• Safety verification：验证功能安全需求有没有被实现？

• Safety validation: 确认功能安全需求提的对不对？即功能安全需求实现了是否确实能保证安全？

根据这样的解释可以发现功能安全验证（safety verification）和功能安全确认（safety validation）属于两个维度。接下来将分别从这两个维度来说明ISO 26262中的要求。

2. Safety verification （安全验证）

功能安全概念开发可以简单概括为：基于整车层的安全目标和相关项的系统架构和边界导出系统功能安全需求；进一步根据细化的软硬件架构分别导出软件功能安全需求和硬件功能安全需求。关于系统/硬件/软件三个层级的功能安全需求如何进行安全验证（safety verification）分别记录在标准中的第4/5/6部分，为便于理解，接下来将以中文版GB/ T 34590为参考对其进行一个总结。

2.1 系统层功能安全需求验证

系统层的功能安全需求验证主要是通过相关项的系统集成和测试实现。

• 相关项集成过程的第一个目标是测试每一条安全要求是否满足规范以及ASIL级别的要求。

• 相关项集成过程的第二个目标是验证涵盖安全要求的“系统设计”在整个相关项上是否得到正确实施。

相关项要素的集成按照系统化的方法进行，从软硬件集成开始，经过系统集成，最后完成整车集成，测试目标包括但不限于：

• 功能安全要求和技术安全要求的正确实施

• 安全机制正确的功能表现、准确性和时序

• 接口实现的一致性与正确性

• 安全机制的诊断或失效覆盖的有效性

• 鲁棒性水平

2.1.1. 软硬件集成测试

为了发现系统设计中的系统性故障，在软硬件集成过程中，应根据需求对应的ASIL等级使用下面表格中给出的可行的测试方法来实现。

2.1.2. 系统集成测试

为了发现系统集成中的系统性故障，应根据需求对应的ASIL等级使用下面表格中给出的可行的测试方法来实现。

2.1.3. 整车集成测试

为了探测整车集成期间的系统性故障，应根据需求对应的ASIL等级使用下面表格中给出的可行的测试方法来实现。

2.2. 硬件层功能安全需求验证

硬件层功能安全需求验证主要目的是验证硬件设计是否违背系统设计规范和硬件安全要求，从而保证硬件设计与硬件安全要求的一致性和完整性。

2.3. 软件层功能安全需求验证

软件层功能安全需求的开发主要体现在以下三个方面：

• 软件架构设计

• 软件单元设计

• 软件集成

软件层的安全验证也是基于这三个方面展开。

2.3.1. 软件架构设计的验证

软件架构设计的验证使用表6中所列出的软件架构验证方法来论证下述属性:

• 与软件安全要求的符合性

• 与目标硬件的兼容性

• 与设计指南保持一致

2.3.2. 软件单元设计的验证

软件单元设计的验证使用表9中所列出的软件架构验证方法来证明:

• 与软件安全要求的符合性

• 与目标硬件的兼容性

• 与设计指南保持一致

• 对软硬件接口规范的符合性

• 通过追溯性表明满足了分配给软件单元的软件安全要求

• 源代码与其设计规范的一致性

• 源代码与其编码指南的一致性

• 软件单元的实现与目标硬件的兼容性

  
  

• 

3. Safety validation（安全确认）

标准中将安全确认的目的概括为：

• 提供符合安全目标的证据及功能安全概念适合相关项的功能安全的证据。

• 提供安全目标在整车层面上是正确的、完整的并得到完全实现的证据。

由此可以看出安全确认中的“确认”在于确认安全目标及安全目标对应的安全标准(safety criteria)是否被满足。

结合到安全目标与安全需求之间的关系可以看出，只有当整车层的安全目标被满足了，才能说明由安全目标导出的安全需求如果实现了可以保证安全。这与文章开头阐述的安全验证和安全确认的概念相吻合。

• Safety verification：验证功能安全需求有没有被实现？

• Safety validation: 确认功能安全需求提的对不对？即功能安全需求实现了是否确实能保证安全？

安全确认的要求和要点可以从以下几个方面概括。

3.1. 安全确认的环境

不同的车型整车各方面参数不同，导致车辆的动态表现都有区别，因此对于和整车动态表现有必然联系的安全目标（如制动、驱动和转向等）都应该采用整车环境对相关项进行安全目标进行确认。

对于和整车环境无必然联系的安全目标（如HMI相关），在有充分的证据表明仿真环境准确性可信的情况下也可以选择仿真环境（如HiL）。

3.2. 安全验证的目标

通常来说，通过评估以下几个方面来确认安全目标是否被实现。

• 可控性

• 用于控制随机失效和系统性失效的安全措施的有效性

• 外部措施的有效性

• 其他技术要素的有效性

3.3. 安全验证的方式

在这里需要强调一个容易被误解的点，安全目标的确认不是只有测试这一种方式，而是可以使用以下方法的适当组合:

• 已定义了测试流程、测试案例和通过/未通过准则的可重复性测试(功能和安全要求的正向测试、黑盒测试、仿真、边界条件下的测试、故障注入、耐久测试、压力测试、高加速寿命测试、外部影响模拟)

• 分析;（如FMEA、FTA、ETA）

• 长期测试,例如车辆驾驶日程安排和受控测试车队

• 实际使用条件下的用户测试、抽测或盲测、专家小组

• 评审