MUNIK解读ISO26262:功能安全验证和确认V3.0

（Verification and validation）

——原创文章，文章内所有内容文字资料，版权均属本公众号所有，任何媒体、网站、公众号或个人未经本公众号授权不得转载、转贴、引用或以其他方式复制发布 、发表。已经本公众号授权的媒体、网站、公众号、个人，在下载使用时必须注明来源，违者本公众号将依法追究相关责任.

 

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

回到知识分享，请点击链接：MUNIK中国-技术分享

 

摘要：

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

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

“V模型”可以简单概括为：1、确定需求；2、实现需求；3验证需求。对于确定需求和实现需求集中在“V模型”的左边，验证需求集中“V模型”的右边。在本文主要对右边展开说明，即安全验证（safety verification）和安全确认（safety validation），它们帮助确保汽车电子系统在设计、开发和生产过程中满足严格的安全要求，并提供了验证和确认的方法和流程来确保安全目标的实现和合规性。

1、安全验证与确认

安全验证和确认是两个独立但相互关联的功能安全活动，验证贯穿于安全生命周期中的每一个执行阶段，通过使用各种技术和方法来验证系统实际的安全性能，这可能包括进行仿真、模拟、测试和评估等活动，以验证系统设计和实现的安全性。而确认是对整个开发过程中执行的安全性活动进行评估和确认，包括确保安全性目标得到满足，安全性要求得到实现，安全性分析得到验证，以及确认采取的安全措施的有效性。验证与确认在系统/硬件/软件阶段形象化如下图二所示：

 

 

图二：验证与确认在系统/硬件/软件阶段形象化图

2、安全验证

      关于安全验证之前公众号里有分享过文章“《功能安全之验证活动》”，这篇文章对验证活动进行了全面总结。本文只简单归纳一下安全验证在系统/硬件/软件三个层级中具体的落实点。

2.1系统层级验证：

图三：系统层级的验证

系统集成和测试的目的包括但不限于：

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

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

●       接口实现的一致性与正确性；

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

●       鲁棒性水平。

2.2 硬件层级验证

图四：硬件层级的验证

硬件集成和验证的目的包括但不限于：

●       硬件安全要求实施的完整性和正确性；

●       硬件在环境和运行应力因素下的耐用性和鲁棒性。

2.3 软件层级

图五：软件层级的验证

      软件集成的验证是为了证明：

●       软件架构设计的符合性；

●       软硬件接口的符合性；

●       已定义的功能和特性；

●       支持功能的足够资源；

●       安全分析得到的安全措施的有效性；

此外，验证活动在测试中一定要分析测试环境与目标环境的差异性。如果存在应定义在后续目标环境测试中的附加测试。

3、安全确认

           根据安全确认的目的：

●提供证据,证明集成到目标车辆的相关项实现了其安全目标;

●提供证据,证明功能安全概念和技术安全概念对于实现相关项的功能安全是合适的。

可以得到安全确认在整车层面来执行的，由OEM来完成。只有当整车层的安全目标被满足了，才能说明由安全目标导出的功能安全需求和技术安全需求的实现是合适的。

图六：从安全目标到软硬件安全要求

3.1 安全确认的环境

不同类型的车辆在整车各方面参数不同，导致车辆的动态表现都有区别，因此对于和整车动态表现有必然联系的安全目标（如制动、驱动和转向等），都应该采用在整车层面的典型环境下进行安全确认。对于和整车环境无必然联系的安全目标（如HMI相关），在有充分的证据表明仿真环境准确性可信的情况下也可以选择仿真环境（如HIL）。

图七：定义安全确认环境的因素

3.2 安全确认的规范

  安全确认规范应包括:

a)相关项目的各种配置和校准参数。如果不可能对所有配置和校准参数的组合进行安全确认，可以选择一些合理的组合进行确认。

b)安全确认的流程、测试案例、驾驶操作和接受准则的定义；

c)所使用的设备的安全检查，以及必要的环境条件。

3.3 安全确认的执行

3.3.1 执行的方式

1)如果通过测试进行安全确认，则用于安全验证测试的要求也适用于安全确认测试。

2)按照规定的确认规范执行确认活动，记录确认结果，纠正在确认过程中发现的缺陷或问题，最终输出安全确认报告。

3.3.2 执行的范围

          安全确认应考虑一下方面：

●       确认人员在危险事件中的可控性，包括在正确操作和误操作下的可控性。

●       外部措施的有效性。

●       其他技术要素的有效性。

●       危害分析和风险评估中对ASIL有影响的技术假设。(例如：假设机械结构可以停止或减轻由电子系统故障引起的潜在危险，则应在整个车辆层面验证停止或减轻结构危险的影响。)

3.3.3 执行的方法

安全目标的确认不是只有测试这一种方式，而是可以使用以下方法的适当组合:

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

●       分析;（例如：FMEA、FTA、ETA）；

●       长期测试（例如车辆驾驶日程安排和受控测试车队）；

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

●       评审；

3.4 安全确认活动与评估

安全确认是通过测试、评估和分析整个开发过程中的安全性活动，确认集成到目标车辆的相关项实现了其安全目标，并提供最终的安全评估报告。安全确认通常包括以下活动：

图八 ：安全确认活动

           评估就是对安全确认的结果进行评估，可以聘请专家小组参与评估活动，具体的方式可采用评审检查的方式进行：对以上确认活动进行评估，确认系统的最终安全性，并出具评估报告。

总之，安全验证和确认是ISO 26262标准中非常重要的过程，通过验证和确认系统的安全性，可以确保汽车电子为人类生活提供更高的安全性能和保障。同时，安全验证和确认也需要在整个开发周期中进行持续的监控和更新。随着系统的演化和变化，任何涉及安全性的变更都需要进行相应的验证和确认，以确保系统的安全性得以维护和提高。