今天插入一个被问及多次的话题,在这里做个分享和交流。
可能大家时常会看到、听到某某公司过了ASIL D的流程认证,取得ASIL B/C/D的产品级认证等,取得认证的组织自然是值得肯定的,尤其是产品级认证,这考验的不仅仅是安全负责人的能力,更多的是对组织成熟度的认可。
大家都知道ASIL A, B, C, D对相关项系统的安全要求越来越高,类似IEC61508里的SIL 1,2,3,4 或ISO13849里的PL(a,b,c,d,e),那么问题来了:
Q1: ASIL B和ASIL D在设计上区别是什么?区别有多大?
Q2: 做过ASIL D项目的”大神“是不是就比做过ASIL B的厉害?
这里先谈谈后面这个问题。我想借用《雪中悍刀行》里关于武学境界“一品四境”的论述来抛砖引玉一下。
小说中“一品四境”的概念大概是这样的:江湖中的高手到一品就代表第一梯队的“武力值”,但由于江湖门派众多,各自都有自己的“独门绝技”所以这一品又分四重境界,这四重境界由低到高依次为金刚境、指玄境、天象境和陆地神仙境,这四种境界又有各自对应的教派,如佛家进入一品就是金刚境,道家进入一品就是指玄境,儒家进入一品就是天象境,最后殊途同归更上一层都是陆地神仙境。
小说中的四种境界有点类似标准中的ASIL A, B, C, D四个等级,按里说境界越高武力值也就越高,但并非指玄境就敌不过陆地神仙境,一个身经百战后进入指玄境的选手可以轻松胜过仅通过悟道进入陆地神仙的选手,不能说指玄境的就干不过天象境的选手。
回到话题,做过ASIL B项目并将功能安全成功落地的安全负责人/工程师,当然也具备搭建、设计ASIL D系统的能力,反过来当然也是成立的。
但并不能说工作经历里有ASIL D标签的就比只做过ASIL B项目的厉害,毕竟产品不一样,就像上面四种境界对应不同的教派一样,都各有所长,你不能保证落地过ASIL D项目的就对所有的产品都了解,整车那么多个ECU,隔行如隔山,能落地的都值得肯定。
关于上面第一个问题,ASIL B和ASIL D在架构和具体实现上会有些差异,由于ASIL D的架构度量指标相较于ASIL B高出一个数量级,对于ASIL D的功能诊断和冗余将更加密集,因为ASIL D的设计需要覆盖更多的功能故障(失效模式)以达到所需的诊断覆盖率。
处理器自带的安全机制ASIL D几乎都需要用上,而ASIL B可以基于系统层面的设计进行一些裁剪。不同等级架构差异这块ISO26262没有给出指定的架构,能做到满足标准要求即可,如果想了解不同等级间架构设计上的差异可以参考ISO13849里针对不同PL的指定架构,或IEC61508中关于MooN的架构描述。
以上只是两者差异的一个简化的定性描述。
接下来看看标准对于两者在具体活动上的差异。
- ASIL B vs ASIL D之Part 2_功能安全管理
两者相关的活动在功能安全管理部分的差异如下:
Jet Note: 针对相关工作成果的认可措施,ASIL D的独立性要求更高,ASIL B要求另外一个人实施认可措施,此人可以是工作成果所在团队的成员,但ASIL D的工作成果要求另外的部门/团队/组织成员实施相关认可措施。针对软件工具的鉴定、功能安全的审核和评估,ASIL B是推荐实施,ASIL D是要求实施且需是另外部门/团队。关于对立性和认可措施的概念可参阅《ISO26262的功能安全管理(二)》一文。
- ASIL B vs ASIL D之Part 7_生产、运行、服务、报废
由于第7部分基本可由质量管理的要求,适用统一的标准流程要求及组织自定义的售后服务流程,如IATF16949, ISO9001。故此部分ASIL B和ASIL D 没有特别的差异。
- ASIL B vs ASIL D之Part 8_支持过程
两者相关的活动在支持过程部分的差异如下:
Jet Note: ASIL B和ASIL D相关的活动在支持过程部分的差异主要体现在需求的描述方式、工具鉴定方式及系统可靠性要求,对于通用的支持活动,如变更管理、配置管理、文档化等两者不存在差异。
- ASIL B vs ASIL D之Part 9_安全分析
两者相关的活动在安全分析部分的差异如下:
Jet Note:安全分析这块ASIL B和ASIL D的差异主要体现在要实施的安全分析的种类上,ASIL B做定性的、归纳分析即可,但ASIL D还要求定量和演绎分析,使对整个系统的分析更加全面。
- ASIL B vs ASIL D之两者在具体实施上的一些差异
两者相关的活动在具体实施过程中的一些差异小结如下:
综上来看,ASIL D相较于ASIL B安全相关的活动从流程、具体实现及定量和定性验证上都有更严苛的要求,这是从标准的方法论上来讲的,但这并不能代表有过ASIL D工作经验标签的人员就一定比只做过ASIL B项目的人员要更胜一筹,一码归一码,还是如本文开篇的观点那样,不管是ASIL B还是ASIL D,能落地的都值得肯定,安全在项目中能完美地落地才是检验组织及安全负责人的最具说服力的标准。
参考:
[1] ISO 26262-2:2018, Management of functional safety
[2] ISO 26262-3:2018, Concept phase
[3] ISO 26262-4:2018, Product development at the system level
[4] ISO 26262-5:2018, Product development at the hardware level
[5] ISO 26262-6:2018, Product development at the software level
[6] ISO 26262-7:2018, Production, operation, service and decommissioning
[7] ISO 26262-8:2018, Supporting processes
[8] ISO 26262-9:2018, Automotive safety integrity level (ASIL)-oriented and safety-oriented analyses
更多精彩内容欢迎关注微信公众号:功能安全落地漫谈