功能安全一定要接地气
《功能安全量产落地的三座大山》系列文章陆续发布后,笔者收到了不少朋友的反馈,其中最让笔者触动的评价是:接地气。
功能安全并不是什么超越现今人类科技或知识范畴的“黑科技”,那为什么大家会觉得功能安全不接地气呢?笔者思来想去,认为跟ISO26262标准有很大的关系:
标准是一个体系,覆盖产品全生命周期,知识点太多,不容易上手;
标准里有很多专业名词术语,别说理解,光是记住它们就得费一番功夫;
标准里很多描述或解释常常是抽象的,晦涩难懂,让人不知所云。
我们改变不了标准,但我们可以改变自己:在和项目组成员交流讨论时尽量少用专业术语,而是要用通俗易懂的描述来表达功能安全的要求。基于此,笔者接下来准备用自己的语言来解释几个非常基础但却非常重要的问题。
功能安全到底在搞什么?
要回答这个问题,还是要从功能安全的定义说起。ISO 26262里对Functional Safety的定义是:“Absence of unreasonable risk due to hazards caused by malfunctioning behaviour of E/E systems”。确实挺抽象的,下面我们一起来拆解分析。
这个概念里有三个关键点,笔者已经标识出来了:
absence of unreasonable risk:也就是降低风险
功能安全方法论可以将unreasonable risk降低至tolerable risk,但是请注意绝对不会是零风险。也就是说,就算严格按照功能安全的要求进行开发,也不能保证彻底消除事故。只能说概率足够低,风险可接受。这个没什么奇怪的,我们都是人,不是神。只有神才能保证绝对的万无一失。
malfunctioning behavior:通俗的讲就是故障
由于各种各样的原因,比如需求错误、软件bug、硬件电子元器件损坏、EMC干扰等,故障是无法彻底消除的。当产品出现故障后,很可能引发安全事故,功能安全要研究的就是在这种情况下如何避免人员伤亡。
E/E systems:限定了功能安全的适用范围:电子电气系统
对于其它类型的产品故障,是无法用功能安全的方法论来处理的。举个例子:功能安全方法论不能完全覆盖动力电池的安全,因为动力电池系统除了电子电气之外,还有电化学,而且电化学恰好正是最主要的不安全因素。
现在我们可以知道:功能安全针对的是电子电气系统的故障,需要将这些故障造成人员伤亡的风险降低至合理水平(所谓合理水平,是通过ASIL等级来衡量的,详见后文论述)。这就是功能安全要做的事情。
功能安全到底要怎么搞?
前面我们已经明白了功能安全到底在搞什么,接下来我们讨论一下功能安全到底要怎么搞。
故障是功能安全应对的主题,所以从某种角度来说,功能安全是通过故障管理来降低风险的。故障管理包括:
故障避免(Fault Avoidance)
在产品开发过程中通过安全管理或安全设计尽量避免故障的产生,主要指的是“V”模型左侧的活动,比如安全需求的双向追溯。故障避免就好比通过锻炼、养生来提高体质,降低生病的可能性。不生病的话,自然就不需要治病。
故障消除(Fault Removal)
在产品开发过程中通过验证来发现故障、消除故障(在产品量产之前),主要指的是“V”模型右侧的活动,比如测试和评审。故障消除就好比定期体检,在疾病刚刚产生时就进行治疗。
故障诊断(Fault Detection)
故障诊断可能是大家最为熟悉的内容,因为安全机制绝大部分都是这种类型。故障诊断就好比生病了之后去医院检查,这个时候一般是不能继续正常工作了。
故障容错(Fault Tolerance)
诊断出故障之后我们都要进行故障处理,通常情况下是进入安全状态。但有的时候我们需要带病坚持工作,这就是故障容错。故障容错一般需要有备用的系统才能实现,也就是在故障产生后启用备用系统进行工作。
大家可以回想一下,功能安全标准里要求的各种任务、各项活动,是不是基本上都可以归到上述4种类型当中呢?所以说,功能安全并不神秘,所有的工作都是围绕故障管理这个核心来展开的。
ASIL到底是什么含义?
在笔者看来,ASIL是贯穿ISO 26262标准的主线。不管在产品生命周期的哪个阶段,不同的ASIL等级都分别对应着不同的流程/技术要求。究其缘由,是因为ASIL代表安全等级,而安全等级覆盖相应的风险等级。
ASIL最早出现在HARA里,是由S、E、C三个指标打分得到的。也就是说,风险有多大,ASIL等级就有多高,它们是对应的。如果我们严格按照标准执行,将ASIL等级对应的要求落实到位,那么该ASIL等级对应的风险就能被控制住,也就是降低到合理水平。
结束语
本文是《功能安全量产落地的三座大山》番外篇的最后一篇。之所以取这个标题,也是希望能够改变大家对功能安全不接地气的刻板印象。对功能安全从业人员来说,接地气、说人话非常重要。不要总是满口专业术语,听起来好像很高大上,实际上却会让人敬而远之。试想一下,如果别人都觉得功能安全不接地气,你又怎么在项目里实施呢?高高在上的功能安全是没有生命力的,只有平易近人的功能安全才有可能量产落地。
The End
说明:
* 文章仅代表作者个人观点,不代表'仨人谈起'立场