Leo'写后感’ '当要求功能安全时,我们在要求什么?’看似简单的问题,但是动起笔来竟然洋洋洒洒写了近万字才算给出了一个自己满意的答案,而且即使是这样,资深的同行朋友依旧能够指出其中的不足。不过,这篇文章浓缩了我多年的功能安全开发经验,对于想了解功能安全或者刚入行的朋友来说,我可以很自信地说这篇文章会是一个很好的参考,而且是在公众平台能找到的最好的回答。 如果你看完觉得有参考价值,欢迎关注公众号'Leo的底盘世界’,并帮忙点赞转发,这个'刚出生’的公众号需要你的支持来获得继续更新的动力,推出更多功能安全相关的文章。谢谢! 导语 大家好!我是Leo。 对从事电子电气相关工作的汽车工程师来说,功能安全已经不再陌生,在日常工作中经常会接触到功能安全相关的一些概念,比如'ASIL等级’,'安全目标Safety Goal’,'安全概念Safety Concept’等。但是当讨论诸如'某个信号能否满足ASIL D?’之类的问题时,可能会议室一半的人都在暗自发问:'怎样才算满足了ASIL D’? 作为一名功能安全工程师,收到过太多来自非功能安全工程师或者是刚入行不久的功能安全工程师类似的问题,这类问题都可以回归到一个最原始的问题:
本文将回答这个看似简单却至关重要的问题,试图讲清出功能安全开发的本质,作为功能安全入门的参考,欢迎大家留言讨论与指正。 文章结构安排 1 从规避股市风险讲起 (提炼降低风险的通用步骤) 2 功能安全与'风险识别’ 3 功能安全与'制定安全措施’ 4 功能安全与'验证安全措施的有效性’ 5 总结 6 引申 文章图片说明 ISO26262是功能安全的国际标准,GB/T 34590是功能安全的中国标准,为方便理解,本文从标准中的截图优先选择GB/T 34590。1 从规避股市风险讲起 通常大家在讨论功能安全时,会从功能安全的标准ISO26262讲起。但是我逐渐发现这样的做法有个不好的点,就是会让听众误以为功能安全是个横空出世的概念,功能安全的方法论也是个新的方法论。但是功能安全本质上也是在回答一个关于'如何降低风险’的问题,只不过分析的对象有针对性地变成了汽车的电气/电子系统(E/E系统)。而关于'如何降低风险’,这个问题早在很多行业或者领域都被回答过了,而且无论分析对象是什么,我们都可以抽象出相同的方法论(或步骤);更有意思的一个事实是,即使没有任何理论指导,我们在日常生活中就经常在不知不觉中运用着相同的方法论了。 这个结论听起来似乎有些不可置信?那接下来看一个生活中的案例就有体会了。 当听到股票跌破3000点的消息时,小A和小B都不约而同的打开了股票账户查看余额。当只是抱着玩一玩心态的小A发现自己只存了100元时,心态平和地接受了这个消息;而小B的账户还剩100万,这一消息让他警觉万分,一番市场走势分析下来,小B觉得应该马上离场及时止损。于是果断地选择了抛售。在接下来的几天里虽然股票偶有回升,但是小B相信自己的判断,忍住了买入的想法继续观望。一周后股票跌破2700点,小B为自己的决定感到庆幸。 这个案例中就包含了关于'如何降低风险’的通用的方法论,主要为三个步骤:
可以说,不论应对何种风险,都能提炼出同样的降低风险的步骤。功能安全开发也同样如此。 ISO26262中对 “Functional Safety 功能安全” 的定义如下: 不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险。 那我们接下来就顺着通用的方法论的三个步骤,逐个说明功能安全是如何执行的。 2 功能安全与'风险识别’ ISO26262将识别风险这一活动定义为'危害分析与风险评估’。 危害分析与风险评估可以继续细分为三步:
在这一过程中需要注意:应以能在整车层面观察到的条件或行为来定义危害。既然是以整车层面观察到的行为来定义危害,首先需要了解车辆所有可能的运动行为。从整车动力学的角度,汽车所有的运动行为可以通过下图中的X/Y/Z运动坐标系对应的六个自由度来表征。 车辆运动XYZ坐标系与六个自由度,图片来自J2980 而在每一个坐标系上,因为功能异常不当而可能产生的所有的整车异常表现(整车危害)也能被罗列出来。思路如下图所示。 整车危害分析示例,图片来自J2980 为什么要进行危害事件分类呢?和其他领域的安全设计追求的目标一样,功能安全关注的是不合理的风险(Unreasonable Risk)。我们分别来理解'Unreasonable’ 和'Risk’便可以得到答案。 'Unreasonable’ 没有100%安全的系统,有风险但是如果风险发生的概率极低,也是可以被接受的。比如飞机失事虽然历史上有发生,一旦发生就是灾难性的事故,但是在发生概率足够低的情况下,飞机依旧是受大众欢迎的出行选择方式。 'Risk’ 有危害(Hazard)不一定100%产生风险(Risk),比如如果汽车在高速上突然减速,但是减速度最大只有0.1g,那么驾驶员是充分可控的(这个减速度大小和纯电常见的滑行回收功能的减速度相当),对驾驶员以及周边车辆都没有会造成人员伤害的风险。 危害与风险的区别,图片来自网络 从这个角度,进行危害事件分类,旨在筛选出能造成不合理的风险的危害事件,进而将安全开发的工作重心集中在对造成不合理风险的潜在故障的限制或消除上。 早在2010年发布的标准ISO 12100'Safety of machinery —General principles for design — Risk assessment and risk reduction’中就指出了评估风险的通用的准则: 风险 = 危害能造成伤害的严重程度 * 危害造成伤害的概率 ISO26262遵循同样的风险评估准则,并通过三个指标来衡量衡量风险,具体对应如下: S (severity 严重度):危害发生对驾驶员或乘客或路人或周边车辆中人员会造成的伤害等级。评分表如下: E(Exposure 暴露概率):运行场景在日常驾驶过程中发生的概率。评分表如下: C (controllability 可控性):驾驶员或其他涉险人员控制危害以避免伤害的概率。评分表如下: 基于这三个指标的评分,即可确定汽车安全完整性等级(Automotive Safety Integrity Level, ASIL等级)。ASIL一共分为四个等级,D代表最高严格等级,即风险最高,A 代表最低严格等级,即风险最低。 如果相关项对应的危害事件的ASIL等级为ASIL A及以上,则功能安全开发需要予以考虑;对于QM(Quality Management 质量管理),只要按照企业流程开发就认为可以满足ISO26262要求,无需额外进行功能安全开发。 通过危害事件分类识别出的不合理的风险,正是功能安全开发所要避免的风险,这也是功能安全的开发目标。 ISO26262对导出安全目标(Safety Goal)的要求如下。 应将为危害事件所确定的ASIL等级分配给对应的安全目标。如果将类似的安全目标合并为一个安全目标,按照6.4.4.1,应将最高的ASIL等级分配给合并后的安全目标。 拿大家熟知的ACC(Adaptive Cruse Control)功能举例,假如ACC功能错误控制车辆减速,其危害分析与风险评估如下表所示。 ACC功能错误减速危害分析与风险评估示例 基于危害分析与风险评估结果,可以导出如下安全目标: SG: ACC应该避免非预期的减速, ASIL C 安全目标可以认为是整车层的功能安全需求,在确定了安全目标以及安全目标对应的安全接受准则以后,接下来便结合相关项(即所开发的电气电子产品)的架构将功能安全需求进一步拆解到组成相关项的要素(软件或者硬件)上,并进行功能安全设计。 先导出安全目标,再导出对相关项的软件或硬件的功能安全需求,截图来自GB/T 34590, 第3部分 3 功能安全与'制定安全措施’ 制定安全措施的前提,是找到引起功能异常的源头,道理很简单,只有清楚了'症结’,方能'对症下药’。 那么接下来的问题是:
借助ISO26262第10部分的说明图,我们很容易得出以下结论。 相关项分解示例,截图来自GB/T 34590, 第10部分 故障导致失效的示例,截图来自GB/T 34590, 第10部分 总结来说,相关项(电气电子产品)是由两类基础的要素软件和硬件组成的,功能的异常则是由软件或者硬件的故障造成的。软件和硬件的故障可以分为三类:
对于前两类统称为系统性故障,由它们导致的失效则称为'系统性失效’。后者则导致'随机硬件失效’。下面就这两类失效展开说明。 系统性失效(systematic failure):以确定的方式与某个原因相关的失效,只有对设计或生产流程、操作规程、文档或其他相关因素进行变更后才可能排除这种失效。 关键点: 1) 确定的方式:不同于随机硬件失效的不可预知性,系统失效的形式是确定的,只要满足相应条件就一定会发生。从另一个角度,系统性失效是可以复现的。 2) 排除:当找到造成失效的确定方式后,可以采取对应的措施(如修复软件bug,完善软件开发流程等)有效避免系统性失效。 随机硬件失效(random hardware failure):在硬件要素的生命周期中,非预期发生并服从概率分布的失效。 关键点: 1) 硬件要素:只有硬件才会产生这类失效,软件不会。 2) 非预期:尽管硬件的设计完全正确的,元器件也是符合质量标准的。但是却无法预知的故障,无法预知在哪里发生,以怎样的形式发生。 3) 服从概率分布:虽然失效的发生是非预期的,但是失效率可以在合理的精度范围内进行预测。也就是说硬件随机失效是可以进行定量评估的。 随机硬件失效与系统性失效举例 现在我们清楚了'症结’:引起功能异常的源头是要素故障引起的系统性失效或者随机硬件失效,而这也决定了定义的安全措施必须尊重这两类失效的本质区别,才能真正做到'对症下药’。 避免系统性失效的安全措施 无论是软件要素还是硬件要素,避免系统性失效都可以归为两点:
接下来就这两点展开讨论。 这一点主要取决于开发人员或者开发团队的know-how,比如对产品的了解程度以及对ISO26262方法论的理解程度等。当然,一些成熟的开发原则或指南有助于开发人员更好地展开安全措施的设计,这些方法落实越到位,软件或者硬件设计出现系统性失效的可能性必然越低,这也是为什么ASIL等级越高,ISO26262越推荐这些方法的应用。 ISO26262中对应用相关方法的推荐说明 比如对软件开发而言,遵循好的软件架构设计原则,能够保证软件的可靠性,也有利于开展软件层级的安全分析等活动。 截图来自GB/T 34590, 第6部分 对硬件开发同样如此,遵循一好的硬件架构设计原则能够保证硬件设计的可靠性,也有利于开展硬件层级的安全分析等活动。 截图来自GB/T 34590, 第5部分 举例来说,一个安全措施设计得再好,在落实到代码上出现了bug,一切都是白费,基于此,功能安全要求安全措施在实施阶段没有偏差。这一点主要取决于开发流程。以基于'V模型’ 的开发工作为例,完善的开发流程的体现为:
需要指出的是,保证以上两点,既体现在对开发者的要求上,也体现在对审核过程的要求上。 截图来自GB/T 34590 另外,开发工具的可靠性也会影响安全措施在实施时的偏差。举例来说,如果软件工程师使用的软件编译软件可靠性低,导致正确的代码在编译过程中出现问题,则可能使得软件中安全措施无效。基于此,ISO26262对开发所使用的软件工具的置信度也提出了要求,需要建立证据证明软件工具适合用于支持ISO26262要求的活动或任务。 工具评估与鉴定流程,截图来自GB/T 34590, 第8部分 最后必须强调一点,通过上面对避免系统性失效的方法的介绍,可以看出这些安全措施并不是新的东西,只不过在ISO26262中对它们进行了一些概念上的定义和要求上的细化。即使没有ISO26262,一些成熟的公司早已在自己的开发流程或者开发指南中体现了这些安全措施,因为说到底,避免系统性失效就是确保在设计的各个环节都合理可靠,ISO26262依旧符合这个安全思路。 要想限制随机硬件失效,首先要对ECU中的电子元器件进行分析,了解元器件的故障模式与失效率分布,以及在故障发生后对安全目标的影响。FMEDA (Failure Modes, Effects and Diagnostic Coverage Analysis) 作为对电子元器件的随机硬件故障的分析方法而被广泛熟知。FMEDA的第一步是识别出电子元器件的每一个故障模式对系统造成的影响,并由此将电子元器件分为两类:
截图来自GB/T 34590, 第5部分 任何一个电子元器件的故障,都可以基于故障模式对系统造成的失效影响归类为下表中的某个故障类型: 而为了达到限制随机硬件失效的目的,安全措施的设计方向通常包含三类:
4 功能安全与'验证安全措施的有效性’ 验证避免系统性失效相关的安全措施——安全确认 (Safety Validation) ISO26262中将安全确认的目的概括为:
由此可以看出,安全确认中的'确认’在于确认在安全措施的作用下,安全目标及对应的安全接受准则是否被满足。结合安全目标与软件或硬件层级的安全需求之间的关系可以看出,只有当整车层的安全目标被满足了,才能说明由安全目标导出的安全需求是合理且充分的。 安全确认的目标 在这里需要强调一个容易被误解的点,安全目标的确认不是只有测试这一种方式,而是可以使用以下方法的适当组合:
ISO26262中从两个维度对相关项的随机硬件失效提出了要求: 硬件架构的度量旨在实现以下目标:
单点故障度量 (Single-Point FaultMetric, SPFM) 单点故障度量反映了相关项通过安全机制覆盖或通过设计手段实现的对单点故障和残余故障的鲁棒性。高的单点故障度量值意味着相关项硬件的单点故障和残余故障所占的比例低,系统可靠性更高。 单点故障度量的计算公式为: 式中分母即安全相关的失效率总和。单点故障度量公式图示如下。 ISO26262中对单点故障度量的要求如下,对ASIL A的安全目标没有要求,对ASIL B的安全目标没有强制要求,对ASIL C和ASIL D的安全目标有强制要求。 潜伏故障度量 (Latent FaultMetric, LFM) 潜伏故障度量反映了相关项通过安全机制覆盖、通过驾驶员在安全目标违背之前识别或通过设计手段实现的对潜伏故障的鲁棒性。高的潜伏故障度量值意味着硬件的潜伏故障所占的比例低,系统可靠性更高。 潜伏故障度量的计算公式为: 式中分母即安全相关的失效率总和。潜伏故障度量公式图示如下。 ISO26262中对潜伏故障度量的要求如下,对ASIL A的安全目标没有要求,对ASIL B的安全目标没有强制要求,对ASIL C和ASIL D的安全目标有强制要求。 简单来说,对随机硬件失效导致违背安全目标的评估是用来确定违背安全目标的残余风险已经足够低。ISO 26262对这一评估推荐了两个方法:
因为在实际开发中所有的公司几乎都使用PMHF,所以本文只对PMHF展开说明,感兴趣的朋友可以参考ISO26262, part5了解第二种方法。 PMHF表示在汽车运行周期中每小时平均失效概率。ISO26262对PMHF的要求如下,这里必须强调下ISO26262对PMHF的要求的完整内容,以消除对PMHF的常见误解。 ISO26262对PMHF的要求 通过上面的需求可以看出,首先,PMHF的目标值不仅仅来自表格6,还有其他不同的来源,比如参考b)和c);其次,PMHF的定量目标值没有绝对的意义,仅有助于将一个新的设计与已有设计相比较。所以在实际开发中,千万不要将表格6视为必须满足的绝对标准来指导内部开发或者和合作方沟通。 5 总结 本文试图在说明一件事:
可以说,从功能安全开发的角度,所有的开发活动都是在通过实施这些步骤来避免或者降低E/E系统发生安全相关的系统性失效和随机硬件失效的概率,从而达到将风险降低到可接受的范围内的目的。 在这个通用的步骤的指导下,功能安全开发活动的要点可以总结如下。 没有ISO26262,流程体系完整的公司或者安全思维成熟的工程师,依旧可以找到不同的尽可能降低E/E系统发生故障造成的风险的方式,这是一个被忽略的事实。 但是,有了ISO26262,我们相当于有了一个更加系统更加完整的指南,而且这个指南标准化了企业内部合作以及不同的企业之间合作的'沟通语言’,规范了不同企业对安全措施的选择的方向。 个人觉得,以上两点是ISO26262对汽车行业的最大的意义。至于使用通用的'语言’,能够写出多么脍炙人口的'诗歌’,那就取决于公司或者工程师的know-how以及对功能安全方法论的运用。 值得指出的是,本文的全部讨论都是聚焦'功能安全开发,Safety Engineering’,ISO26262还对另一个维度'功能安全管理,Safety Management’提出了要求并给出了指南。'安全开发’和'安全管理’涵盖了ISO 26262这个系列标准的全部内容。 6 引申 不同的产品供应商如何对产品层级的功能安全需求进行裁剪,不同层级的供应商之间如何通力合作满足产品层级的功能安全需求,这又是一个很大的话题。 -end- |
|