引入ISO26262肯定会增加成本,流程上的文档是一回事,更重要的是,因为做功能安全分析时,极有可能枪毙掉原有的低成本方案,比如原有方案存在着无法克服的风险,所以对系统,架构和部件都有可能提高要求.
但是ISO26262的出发点就是要保证可以接受的安全,它已经对成本做了一些平衡,所以它在制定时也只是考虑了必须的要求.比如在BL21版本中,原来ASIL D的硬件故障率要求已经从10e-9降到10e-8.原来的故障率是计算得到的,新的故障率根据售后数据和实地经验调整过了,降低的硬件故障率也可以满足ASIL D的要求.
关于风险评估这一块,我正在酝酿如何写.
【 在 om 的大作中提到: 】
: 这个话题我也很感兴趣，已收藏博客。两三年前看过几遍draft版本的spec，此后一直没有时间再细细学习
: 我的感觉是，抛开功能安全的术语，26262是一个专门针对系统安全性的风险管控流程需求，是一个风险识别和控制的框架性协议。其中应用的方法并不是新鲜的东西，比如风险评级，采用了和FMEA类似的框架。合理定级需要有翔实的经验数据作为支撑，否则结果可能截然不同。就像我见过的很多FMEA，其实都是捣浆糊，瞎写一通
: Functional Safety把产品开发中的安全考虑单独拿出来讨论，的确是观念的进步，必将对最终产品的完善度有极大助益，而其中包含的业界积累也是汽车产业新进者学习开发思路的极好机会。不过，那一千五六百个work products也必将计入成本:P
: ...................
--
修改:moliye FROM 194.250.98.*
FROM 194.250.98.*