INFORMATION热门资讯

冰衡 > 观点 > ISO26262功能安全怎么在企业落地?

ISO26262功能安全怎么在企业落地?

冰衡咨询整理 244 人感兴趣 发表于:2021-03-01 10:49

什么是功能安全(Functional Safety)?

在这里先引用ISO 26262和GB/T 34590中的定义,从定义展开强调几个关键词。

1、 “E/E system”,电子电器架构
功能安全要讨论的对象是E/E架构设计,因此机械/液压/化学等设计都不在ISO 26262的研究范围。
2. “hazard”,危害
危害有很多类型,如人身伤害或者财产损失等等。功能安全里的危害仅仅指对驾驶员或者路人或周边车辆内人员(注意:不仅仅是驾驶员)造成的健康伤害。换句话说,功能安全开发目的是避免伤人,而不是避免你的损伤你的豪车,也不是避免你的豪车被偷。
3. “unreasonable”,不合理的
即“不可被接受的”。就像世界上没有永动机一样,世界上也没有100%安全的系统,因此功能安全追求的是将危害控制在可被接受的范围。而是否可被接受,需要从两个维度去衡量:危害的严重性和危害发生的频率。举例来说,飞机失事几乎无人生还,但是正因为飞机失事的概率非常低,所以不影响它成为最重要的交通工具之一;电动车窗发生卡滞故障的频率比较高,但是故障不会让人受伤,因此很多司机甚至只有等到下个月去4S店时才想起来维修它。但是,如果你的车突然在高速上自动加速,估计你马上停在紧急带,惊魂未定便马上打电话给4S店骂娘了,因为这种原本可以通过设计规避的故障是不可接受的。这也正是功能安全开发期望避免的故障。
补充一下,这里提到两个维度,危害的严重度和危害发生的频率。对功能安全有了解的朋友可能会疑惑 :不是有三个参数评价,S(severity 严重度),E(Exposure 曝光度),C(controllability 可控度)吗?
其实不冲突,第二个维度频率综合了E值和C值。怎么理解呢?“频率”指的是危害发生的频率,而“曝光度”指的是场景的曝光度。驾驶员的可控度是可以将高曝光度的场景下造成危害的频率降低的。举例来说,开高速的场景在日常生活中曝光度比较高,但是如果高速时发生意外加速,有些情况下通过驾驶员的制动干预是可以避免危害的,因此降低了危害发生的频率。



功能安全怎么在企业落地?

这个问题很大,无法进行全面的回答。一个原因是各个公司间的差异性,二是ISO 26262的范围太广,对整车完整生命周期都进行了功能安全的指导,除了我们熟知的V模型开发过程外,就连生产和报废阶段都考虑在内。在这里仅仅谈几点认识。

1、安全文化(safety culture)。

这个词初一听很虚,感觉像是喊口号。实际上安全文化体现在很多看得见的方面,比如:

· 成本和进度总是优先于安全和质量,还是安全是最高优先级?

· 是否确保了与功能安全相关的决策责任是可追溯的?

· 在所有层面(管理/开发/验证/审核)执行是否有明确的、可追踪的和受控的流程?

安全文化体现在公司的开发流程中。优秀的安全文化一定意味着企业有非常完善的开发流程。否则功能安全只是空中楼阁,落地无从谈起。同时,完善的流程也意味着要增加相应的岗位和工程师们的工作量,甚至是升级开发工具,开发成本也随之上升。

在这里强调一点,企业一定是将ISO 26262中对功能安全的需求融入公司已有的开发流程,而不是单独为功能安全开发制定一套开发流程。换句话说,功能安全需求是功能需求的一部分,和其他功能需求一样用同一套的开发流程来实现。

2. 人员配置。

首先说明,几乎不可能是由一个功能安全开发工程师同时负责系统/软件/硬件所有的功能安全开发,就算有这种万里挑一的全才,也得考虑如此庞大的工作量会不会把人才赶跑了。

一个完善的开发团队中通常定义三个角色:

· 系统功能安全工程师

· 软件功能安全工程师

· 硬件功能安全工程师

每个人负责下图中的一个V模型开发活动。

需要说明,这里的“系统”指的是某个E/E产品,比如转向控制系统EPS,稳定性控制系统ESP,电机控制系统MCU等。


功能安全工程师角色分工

不管对主机厂还是供应商,在一个客户项目中,很少说要从零开始开发一个全新的产品,一般都是基于现有的产品作为base进行开发,以满足新的项目需求,功能安全也是如此。围绕项目需求与base不同的部分进行功能安全开发,识别不同点的活动称作FSIA(functional safety impact analysis)。当功能安全是基于base来开发时,不管是对主机厂或供应商来说,这三个角色并不需要定义三个独立的工程师来做,这未免太奢侈,实际上也没必要。通常软/硬件功能安全工程师由软/硬件工程师兼任。

对软件功能安全开发而言,在软件开发流程完善和开发工具满足要求的前提下,在软件设计和验证过程中,功能安全需求和功能需求无需过分区别对待,有很多公司的软件开发流程本身就能保证符合ISO 26262中ASIL D的要求。因此功能安全对软件工程师增加的工作量主要体现在需求分析和输出文档,包括:

1、对系统层分配下来的安全需求进行可行性分析

2、对输入信号提安全需求

3、满足系统层或客户的文档需求

对硬件功能安全开发而言,通常一款硬件的设计周期很长,而且设计好后很多年不会更新,所以几乎不会在客户项目中重新开发硬件。基于此,项目中硬件功能安全开发就可以完全沿用base既有的开发,功能安全对硬件工程师增加的工作量主要是:

1、为系统安全工程师提供FTA分析需要的硬件component失效率数据(FMEDA)

2、满足系统层或客户的文档需求(如ECU FMEA分析报告)

只有系统功能安全开发需要定义一个专门的岗位,有些公司也称为“功能安全经理(product safety manager, PSM)”。主机厂和供应商对功能安全经理的职责定义侧重点有一些不同,这也是主机厂和供应商之间的合作模式决定的。主机厂侧重于定义需求并分配给供应商,供应商则侧重于实现需求。


主机厂端功能安全经理的工作职责一般包括但不限于:

1.计划和协调系统安全开发活动;

2.进行HARA分析,并结合HARA分析和系统架构定义功能安全概念(functional safety concept)和技术安全概念(technical safety concept);

3.将安全需求分配给对应的子系统,或者说分配给子系统的供应商;

4.负责协调子系统相互之间的功能安全需求的传递与澄清;

5.协助功能安全验证,比如创建整车test case和测试结果评估;

6.对子系统功能安全开发进行审核

供应商端功能安全经理的工作职责一般包括但不限于:

1.计划和协调系统安全开发活动;

2.基于HARA分析,根据安全需求和系统架构定义功能安全概念(functional safety concept)和技术安全概念(technical safety concept),对系统架构设计提出要求或建议;

3.将安全需求分配给对应的软件工程师(和硬件工程师);

4.完成系统功能安全设计的定量分析和定性分析,通常分别使用FTA和FMEA;

5.协助功能安全验证,比如创建整车test case和测试结果评估;

6.作为客户功能安全团队和功能安全审核团队的接口;

7.对软/硬件工程师提供功能安全开发建议和指导

一般来说,生产和报废阶段的功能安全活动不在系统功能安全工程师的职责范围内。比如生产阶段的功能安全通常是由plant manager(工厂经理)来执行,执行的依据则是已经包含了功能安全需求的生产流程。当产品release后交到工厂,就意味着功能安全工程师的工作完成了。

相信大家可以理解,为什么系统层的功能安全开发需要专门的人负责了,因为工作量实在有点大。尤其是现阶段国内功能安全开发的理念和方法论还没有到深入人心的程度,如果遇到客户不懂,软硬件工程师也不懂,那么光是对外交流和对内沟通就需要花大量的时间。如果一个项目足够大,客户新需求足够多,可能不止一个系统功能安全工程师。

于此同时,功能安全经理这个岗位对工程师的专业素质要求也很高,原则上需要有足够的软/硬件开发经验,这样才能胜任上到客户或供应商,下到软硬件工程师的交流工作。但是目前鉴于功能安全在企业还比较新,这方面的能力要求有适当放宽。

在这里也纠正一些同行对系统功能安全工作的误解。认为既然不用写代码,也不用画板子,那功能安全经理就只剩下流程和文档工作了。这话被功能安全经理听到他会伤心的,仿佛当年不被女神认可的感觉又回来了。诚然,功能安全的落地需要流程和文档来保证,但是功能安全开发的核心却是技术层面的东西而非流程。而功能安全的技术核心,体现在概念设计/系统分析/系统验证阶段对功能安全开发方法论的运用。


联系我们Contact Us

021-3177 6271

冰衡中国:上海市静安区平型关路108弄
37号品座5楼519室,邮编:200070

冰衡加拿大:7030 Woodbine Avenue,Suite 500,
Toronto, Ontario L3R 6G2, Canada,
电话: (+1) 647 655 9360,
邮箱: info@kraigglobal.com

客户反馈Feedback

了解更多Subscribe

微信二维码

关注冰衡官方微信

CopyRight © 冰衡咨询 版权所有 沪ICP备18032273号-4备案 本站由提供CDN加速服务