写在前面
本系列文章主要讲解道路车辆功能安全ISO26262标准的相关知识,希望能帮助更多的同学认识和了解功能安全标准。
若有相关问题,欢迎评论沟通,共同进步。(*^▽^*)
1. 道路车辆功能安全ISO 26262标准
3. ISO 26262-3 概念阶段
我们来具体看一下在概念阶段,ISO26262-3 对于项目定义、安全生命周期初始化和危险分析和风险评估的定义和要求。
一、项目定义
首先是项目定义阶段。项目定义,也就是对要进行研发的产品进行一个定义,进行一个描述。主要有两个目的:一个是定义和描述项目;一个是对项目有一个足够的理解,以便能够很好的完成安全生命周期中定义的每一个活动。
基于以上目的,要对项目进行明确、准确、正确的定义,就需要获得一些基本信息,ISO26262 中给出了一些建议如下:
1. 项目信息
- 项目的目的和功能
- 项目的非功能性要求,如操作要求、环境限制等
- 法规要求(特别是法律和法规),已知的国家和国际标准等
- 类似功能、系统或元素达到的行为
- 对项目预期行为的构想
- 已知的失效模式和风险在内的项目缺陷造成的潜在影响
2. 项目的边界条件以及相关项目之间的接口条件:
- 项目的所有元素
- 项目对其他项目或项目环境元素的相关影响
- 其他项目,元素和环境对本项目的要求
- 在系统或者包含的元素中,对功能的定位和分配
- 影响项目功能时,项目的运行情况
有了以上这些基本的信息,就可以对要进行的项目给出一个比较明确和具体的项目定义,明确项目的要求,从而使得对项目有一个足够的理解,能够指导后续工作,来很好的完成安全生命周期中定义的每一个活动。
二、项目的安全生命周期
那么,有了项目定义之后,就要确定项目的安全生命周期,对项目的安全生命周期进行初始化,也就是开始对项目的安全生命周期进行细化。而要进行细化,就要区分是项目是新产品研发还是既有产品的改造。
如果是全新的设备研发,则相关工作就得从安全生命周期的开始做起,项目定义之后就是项目危险分析和风险评估。
如果是既有产品的改造,那么从项目定义开始的这些流程都可以使用一些既有的文件对整个过程进行定制。
现有产品升级改造,就要注意以下一些问题:
1. 要做一个产品和使用环境的分析,以制定出预期更改,并评估这些更改产生的影响。
- 对项目的更改包括设计更改和执行更改。设计更改应该是由需求规范、功 能和性能的增加或者成本的优化所致,执行更改不能影响项目的规格和性能,但可以影响执行特征。执行更改可以由软故障更改,使用新的研发成果或生产工具所致。
- 如果配置数据和校准数据的更改会影响到产品的行为,则更改须考虑这些数据。
- 对产品环境的更改应该是由产品要使用的新的目标环境或由于其他相关产 品或元素升级而引发。
2. 要表述清楚产品使用的前后条件的差别,包括:
- 操作条件和操作模式
- 环境接口
- 安装特征,如:在车辆内部的位置,车辆的配置和变化等
- 环境条件的范围,如:温度,海拔,湿度,震动,EMC 和汽油标号等
3. 要明确给出产品变更的描述以及影响的范围。如果不能明确产品的变更和对环境 数据影响的改变,则相关影响的分析数据都要进行记录。
4. 影响到的服役产品,需要进行升级的,要进行逐一列出。
5. 定制的相关安全活动应符合各个应用生命周期阶段的要求,包括:
- 定制应基于影响分析的结果。
- 定制的结果应包括在符合 ISO26262-2 的安全计划中。
- 影响到的产品须返工,包括确认计划和验证计划。
确定了以上这些基本信息之后,对所要进行的产品研发或者设备更改工作就有了一个清晰明确的定义,对产品的预期使用功能、环境,以及与相关设备的接口也有了一个明确的定义,接下来就可以进行危险分析和风险评估了。
三、项目的危险分析和风险评估
在概念阶段,ISO26262-3 给出了对危险分析和风险评估的要求。
危险分析和风险评估的目的和之前的 ISO13849,IEC62061 等的标准一样,都是为了将设备存在的危险识别出来,并根据危险的程度按照一定的原则对其进行分类,从而针对不同的风险设定具体的安全目标,并最终减小或消除风险,避免未知风险的发生。
也正是因为这样,危险分析、风险评估和 ASIL 等级的确定只是和避免风险有关的安全目标相关。通过对危险情况的系统评估,考虑引发危险的影响因素——伤害的严重性,暴露于危险中的可能性和危险的可控性,来确定安全目标和 ASIL 等级。而这三个指标都是针对产品的功能行为的,所以做危险分析和风险评估时,并不一定先要知道设计细节。
无内部安全机制的项目应在危险分析和风险评估过程中进行评估,拟实施或在以前的项目中已经实施的安全机制不在危险分析和风险评估考虑。在一个项目中,提供充分独立的外部评估措施是非常有效的。例如,如果有足够独立的证据证明,电子稳定控制系统可以通过增加控制来减少在底盘系统的故障影响。此举的目的是证明要实施或已经实施的项目的安全机制成立为功能安全概念的一部分。
危险分析和风险评估的第一步是情形分析和危险识别,即通过相关的情况分析将产品存在的风险识别出来。这就要考虑可能引发危险的操作环境和操作模式,并且要考虑在正确使用时和可预见的误使用时的情况。基于这样的考虑,我们应该通过大量的技术来系统分析,
注意以下一些方面:
1. 准备一个用来进行评估的操作情况清单。
2. 系统的确定清单上的危险。主要可以通过诸如:头脑风暴,检查列表,历史记录,FMEA,产品矩阵,以及相关的领域研究等技术手段进行。
3. 风险应该用在车辆上可以被观察到的条件或影响来进行定义或描述。
4. 在相关操作条件和操作模式下危险事件的影响应该被明确说明。如:车辆电源系统故障可能导致丧失引擎动力,丧失转向的电动助力以及前大灯照明。
5. 如果在风险识别中识别出的风险超出了 ISO26262 的要求范围,则需给出合适的相应措施。当然,超出ISO26262 的风险可以不必分类分级。
完成风险的识别之后,就要对这些风险进行适当的分级,以便设定相应的安全目标,并按照不同的风险等级来采取合理的措施加以避免。
风险的分类主要是通过 3 个指标来考量,即:危险发生时导致的伤害的严重性、在操作条件下暴露于危险当中的可能性(危险所在工况的发生概率)、危险的可控性。
首先,来看伤害的严重性。这里的伤害是指危险事件发生时,对所有被卷入事件中的人的伤害,包括车上的司机和乘客,骑自行车的人,行人,其他车辆上的人员。伤害的严重性可以分为 4 个等级,即:S0,S1,S2,S3(对于伤害严重性的详细描述可以参考 ISO26262-3中附录 B 的内容,这里只做分级说明)。如下表:
级别 | S0 | S1 | S2 | S3 |
描述 | 无伤害 | 轻微或有限的伤害 | 严重或危及生命的伤害(可以幸存) | 危及生命的伤害(可能不能幸存)或致命伤害 |
其次,来看在操作条件下暴露于危险中的可能性。可能性被分为 5 个等级,即:E0,E1,E2,E3,E4,具体分级见下表。至于暴露值是选 E1 还是选 E2,主要看车辆在目标市场正常、合理的使用情况。这里要注意的是,评估暴露于危险中的可能性并不考虑在车上安装了多少个要评估的产品,且假设了所有的车上都安装了这个产品。对于那种认为不是每辆车都安装的产品,其相应的暴露在危险中的可能性会减小的说法也是错误的。
级别 | E0 | E1 | E2 | E3 | E4 |
描述 | 几乎不可能 | 可能性非常低 | 可能性低 | 中等可能性 | 可能性高 |
这里,E0 只用于在风险分析中一些建议性的情况,通常如果一个危险,人员暴露其中的可能性是 E0 级,则无需考虑 ASIL 等级。
再次,来看可控性。即危险事件能被司机或者其他交通参与人员进行控制并减小或者避免伤害的可能性。在 ISO26262 中,可控性被分为 4 个等级,即:C0,C1,C2,C3。但要注意,使用这个分级的条件是司机处于正常状态,即:不疲劳,有驾照,按照交通规则行驶,当然,其中要考虑可预见的误操作和误使用。四个级别为:
级别 | C0 | C1 | C2 | C3 |
描述 | 通常可控 | 简单可控 | 正常可控 | 很难控制或不可控 |
其中,C0 通常用于不影响车辆安全操作的情况。如果一个危险的可控性被评为 C0,则对其没有 ASIL 要求。
由此,根据以上的三个参数,即可确定风险分析中每个风险相应的 ASIL 等级(汽车安全完整性等级),具体确定方法如下表:
严重性等级 | 危险可能性等级 | 可控性等级 | ||
C1 | C2 | C3 | ||
S1 | E1 | QM | QM | QM |
E2 | QM | QM | QM | |
E3 | QM | QM | A | |
E4 | QM | A | B | |
S2 | E1 | QM | QM | QM |
E2 | QM | QM | A | |
E3 | QM | A | B | |
E4 | A | B | C | |
S3 | E1 | QM | QM | A |
E2 | QM | A | B | |
E3 | A | B | C | |
E4 | B | C | D |
ASIL 等级分为 A、B、C、D 四个等级,ASIL A 是最低的安全等级,ASIL D 是最高的安全等级。除了这四个等级 QM 表示与安全无关。
在风险分析过程中,要确保对每个危险事件,根据 S、E、C 和具体的操作条件和模式确定的 ASIL 等级不低于其安全目标的要求。同时,相似的安全目标也可以合并为一个安全目标,但要达到的 ASIL 等级应该是合并项目中最高的。如果安全目标可以被分解到具体的状态中,那么每个安全目标也要转换成达到安全目标的具体安全状态下的具体要求。
安全目标及其属性(ASIL)应按照 ISO26262-8:2011,第 6 条款规定。
要注意的是,危险分析、风险评估和安全目标都要进行审核,以保证对条件和危险分析完整,符合项目定义,并与相关的危险分析和风险评估一致。
由此,完成概念阶段的危险分析和风险评估,形成减少和防止危险发生的安全目标,并通过验证审核。
四、功能安全概念
做完危险分析和风险评估之后,在概念阶段,ISO26262-3 还给出了功能安全概念这个阶段。其主要目的是通过前面的危险分析和风险评估之后得出的安全目标来确定具体的功能安全要求,并将它们分配到初步的设计架构,或者外部减少危险的措施当中去,以确保满足相关的功能安全要求。
为了符合功能安全目标,功能安全概念给出了一些基本的安全机制和安全措施,以便于功能安全要求被很好的分配到系统架构的元素中去。这些主要的机制和措施如下:
——故障检测和失效缓解措施
——安全状态转换
——故障容错机制。即:故障不会直接导致违背安全目标,或者保持系统出于安全状态(降级或者没有降级)
——故障检测和为了将暴露时间减小到可接受的程度的司机警示装置
——逻辑仲裁:不同功能触发的多任务请求应该通过逻辑仲裁来选择最合适的控制
基于以上这些机制和措施,再根据之前的项目定义、危险分析和风险评估、安全目标的设定,以及考虑来自外部的一些预想架构、功能、操作模式及系统状态等,就可以开始考虑将功能安全要求进行适当的分配,指定 ASIL 等级,并将其合理的分配到子系统当中了。安全目标和功能安全要求的层次结构如下表所示:
图 安全目标和功能安全要求的层次结构
图 安全要求结构
在功能安全概念中,ISO26262 从功能安全要求的来源和功能安全的分配两个方面给出了一些建议和要求,具体如下:
1. 功能安全要求的来源:
- 功能安全要求应该从安全目标和安全状态来获得,并考虑预想架构、功能概念、操作模式和系统状态等。
- 要为每个安全目标设定至少一个功能安全要求。
- 每个功能安全要求都要考虑以下内容:
——操作模式
——故障容错时间间隔
——安全状态,过渡到安全状态是否符合设备要求
——急停操作间隔
——功能冗余
这项活动可以通过安全分析(如 FMEA,FTA,HAZOP),以制定一套完整有效的功能性安全要求的支持。
- 警示和降级
- 如果安全状态不能通过立即关闭来达到,则需指定一个紧急操作。
——这些动作应该在功能安全概念中详细描述
——驾驶员或者陷入危险中的人可以使用的手段或者控制要在功能安全概念中详细描述
2. 功能安全要求的分配:
- 研发安全架构概念
- 功能安全要求分配
——功能安全要求的分配应该基于项目预想架构的元素进行。
——分配过程中,ASIL 和功能安全要求考虑的内容信息都要继续传承。
——如果多个功能安全要求被分配到同一个架构元素,则这个架构元素应以这些功能安全要求的最高 ASIL 等级进行研发。
——如果项目由超过一个的系统组成,则对于每个独立系统和他们的接口的功能安全要求都要从考虑预想系统架构的功能安全要求中获得,而这些功能安全要求也都要被分配到系统中去。
——如果 ASIL 等级需要被拆解,则要符合 ISO26262-9 第五条款的要求。
——如果安全要求被分配到其他技术的元素中,则无需考虑 ASIL 等级。
- 如果功能安全概念依赖于其他技术的元素,则应考虑以下环节:
——靠其他技术执行的功能安全要求应该从其相应的元素中获得并分配到元素中去。
——明确与其他技术的接口的相关功能安全要求。
——有其他技术执行的功能安全要求要确保有具体的措施。
- 依赖于外部风险降低措施的功能安全概念应满足如下要求:
——应用于外面风险降低措施的功能安全要求应该从相应的外部风险降低措施中获得并分配到其中去。
——明确与外部风险降低措施的接口的功能安全要求
——如果外部风险降低措施由 E/E 系统构成,则功能安全要求可以用 ISO26262来进行评估。
——必须确保由外部风险降低措施执行的功能安全要求的正确执行。
- 功能安全概念应该按照 ISO26262-8 第九条款的要求来验证与安全目标的一致性和符合性。
- 项目安全确认的原则应该详细的写在功能安全概念中。
- 功能安全要求的审核应该阐明功能安全要求符合安全目标。
由此,按照流程完成以上的这些分析和审核之后,即完成了功能安全概念的阶段,最终会形成功能安全概念的结果和通过审核的功能安全要求。
以下给出了危险分析和风险评估的一般解释:
对于这种分析方法,风险(R)可在危险事件被描述为一个函数(F),与危险事件的发生频率(f),即通过的人的及时反应避免特定的伤害或损害能力,损害或损伤的可控性(C),以及潜在的严重程度(S)有关。
R = F(f,C,S)
发生的频率 f 有以下几个因素确定,一个需要考虑的因素是危险事件的频繁度和在危险事件涉及的人数。在 ISO26262 中,这个的度量是简化成暴露于危险中的可能性(E)。另一个因素是,有可能导致危险事件(故障率,λ)的产品故障率,故障率的特点是硬件随机故障和系统性故障:
f = E.λ
危险分析和风险评估用来设置功能安全要求,这样项目风险是可以避免的。ASILs 等级导出的危害分析和风险评估确定出项目的功能安全要求最小集合。
本文章是博主花费大量的时间精力进行梳理和总结而成,希望能帮助更多的小伙伴~ 🙏🙏🙏
后续内容将持续更新,敬请期待(*^▽^*)
欢迎大家评论,点赞,收藏→→→