赞
踩
摘要:
ISO 26262将功能安全开发融入了广为熟知的“V模型”开发流程中。根据系统/硬件/软件三个层级的划分,ISO 26262共涉及三个“V模型”:
图一:“V模型”中的功能安全开发,截图来自ISO 26262
“V模型”可以简单概括为:1、确定需求;2、实现需求;3验证需求。对于确定需求和实现需求集中在“V模型”的左边,验证需求集中“V模型”的右边。在本文主要对右边展开说明,即安全验证(safety verification)和安全确认(safety validation),它们帮助确保汽车电子系统在设计、开发和生产过程中满足严格的安全要求,并提供了验证和确认的方法和流程来确保安全目标的实现和合规性。
安全验证和确认是两个独立但相互关联的功能安全活动,验证贯穿于安全生命周期中的每一个执行阶段,通过使用各种技术和方法来验证系统实际的安全性能,这可能包括进行仿真、模拟、测试和评估等活动,以验证系统设计和实现的安全性。而确认是对整个开发过程中执行的安全性活动进行评估和确认,包括确保安全性目标得到满足,安全性要求得到实现,安全性分析得到验证,以及确认采取的安全措施的有效性。验证与确认在系统/硬件/软件阶段形象化如下图二所示:
图二:验证与确认在系统/硬件/软件阶段形象化图
关于安全验证之前公众号里有分享过文章“《功能安全之验证活动》”,这篇文章对验证活动进行了全面总结。本文只简单归纳一下安全验证在系统/硬件/软件三个层级中具体的落实点。
2.1系统层级验证:
图三:系统层级的验证
系统集成和测试的目的包括但不限于:
2.2 硬件层级验证
图四:硬件层级的验证
硬件集成和验证的目的包括但不限于:
2.3 软件层级
图五:软件层级的验证
软件集成的验证是为了证明:
此外,验证活动在测试中一定要分析测试环境与目标环境的差异性。如果存在应定义在后续目标环境测试中的附加测试。
根据安全确认的目的:
●提供证据,证明集成到目标车辆的相关项实现了其安全目标;
●提供证据,证明功能安全概念和技术安全概念对于实现相关项的功能安全是合适的。
可以得到安全确认在整车层面来执行的,由OEM来完成。只有当整车层的安全目标被满足了,才能说明由安全目标导出的功能安全需求和技术安全需求的实现是合适的。
图六:从安全目标到软硬件安全要求
3.1 安全确认的环境
不同类型的车辆在整车各方面参数不同,导致车辆的动态表现都有区别,因此对于和整车动态表现有必然联系的安全目标(如制动、驱动和转向等),都应该采用在整车层面的典型环境下进行安全确认。对于和整车环境无必然联系的安全目标(如HMI相关),在有充分的证据表明仿真环境准确性可信的情况下也可以选择仿真环境(如HIL)。
图七:定义安全确认环境的因素
3.2 安全确认的规范
安全确认规范应包括:
a)相关项目的各种配置和校准参数。如果不可能对所有配置和校准参数的组合进行安全确认,可以选择一些合理的组合进行确认。
b)安全确认的流程、测试案例、驾驶操作和接受准则的定义;
c)所使用的设备的安全检查,以及必要的环境条件。
3.3 安全确认的执行
3.3.1 执行的方式
1)如果通过测试进行安全确认,则用于安全验证测试的要求也适用于安全确认测试。
2)按照规定的确认规范执行确认活动,记录确认结果,纠正在确认过程中发现的缺陷或问题,最终输出安全确认报告。
3.3.2 执行的范围
安全确认应考虑一下方面:
3.3.3 执行的方法
安全目标的确认不是只有测试这一种方式,而是可以使用以下方法的适当组合:
3.4 安全确认活动与评估
安全确认是通过测试、评估和分析整个开发过程中的安全性活动,确认集成到目标车辆的相关项实现了其安全目标,并提供最终的安全评估报告。安全确认通常包括以下活动:
图八 :安全确认活动
评估就是对安全确认的结果进行评估,可以聘请专家小组参与评估活动,具体的方式可采用评审检查的方式进行:对以上确认活动进行评估,确认系统的最终安全性,并出具评估报告。
总之,安全验证和确认是ISO 26262标准中非常重要的过程,通过验证和确认系统的安全性,可以确保汽车电子为人类生活提供更高的安全性能和保障。同时,安全验证和确认也需要在整个开发周期中进行持续的监控和更新。随着系统的演化和变化,任何涉及安全性的变更都需要进行相应的验证和确认,以确保系统的安全性得以维护和提高。
赞
踩
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。