前言
1）文章题目起得吓人，但正文却“食之无味”，仅“管中窥豹/盲人摸象/坐井观天”地推测汽车电子研发工作；
2）正文按照标号1/2/3/4，以符合研发工程师强迫症的习惯；
3）行文追求朴素/简洁/凌厉的大实话和心里话，以符合研发工程师“外表朴素/内心艳丽/敏于行/讷于言”的特质；
4）结尾模仿相声的结尾（称作“攒底”），戛然而止，并鞠躬下台。
正文：
1、原有的设计已考虑到功能安全
举例：（引自ISO26262）
某Actuator control ECU需要实现的功能为：当乘车人员按下车内的按键，控制器接通执行器将车门打开。
此外，常识和经验会告诉我们：当高车速时，如果车门意外被打开，可能会发生危险。因此，控制器会采集车速传感器信号，当车速>15km/h时，为了保证乘车人员的安全，即使此时有人按下按键，车门也不会被打开。
框图如下：
上面的设计中，已经隐含了功能安全的设计，即车速>15km/h则车门不再打开。但是，如果控制器出现故障，意外地接通执行器将车门打开，怎么办？
2、让我们做得更好
在传统的设计环节中，因此功能安全分析环节。在相对充分和独立的角度，分析隐患因素（仅分析控制器内）如下：
1）车速信号采集出现问题怎么办？比如，实际车速>15Km/h了，但是控制器认为车速<15Km/h。此时一旦有人按下按键，会导致危险。
2）如果车速采集没有问题，实际车速也<15Km/h，但按键信号采集出现问题怎么办？比如，没有人按下按键，但控制器认为有人按下按键，而将车门打开。由于车速<15Km/h，危险性较上述低，但也存在风险。（注1：“风险分析和影响评估”可定性/定量分析此问题，本文不做展开，后续会有文章介绍）
3）如果车速和按键信号采集都没有问题，控制器故障怎么办？比如，实际车速<15km/h，也没有人按下按键（按键采集也没有错误），但控制器意外地接通执行器将车门被打开，依然会导致危险。
除了上面简单列举的故障外，还有很多种故障，如控制器内的MCU、switch等等都可能发生故障。如何才能将故障一网打尽，需要借助FMEA/FTA/马尔可夫链等分析方法，本文不做展开，后续会有文章介绍。
3、新设计让控制器更安全可靠
工程师粉墨化好妆后登场，如何安全而可靠呢？增加控制回路做冗余，框图如下：
上图粉色阴影处（粉墨嘛），增加一路switch作为冗余。这样可以保证，比如：Actuator control ECU意外地接通左边switch，则VS ECU可以保证右边switch是断开状态的，系统是安全的。
但是，工程师的强迫症会发问：如果Actuator control ECU和VS ECU都出现故障怎么办？
功能安全称之为多点故障，需要定量分析多点故障的失效率，通过设计保证多点故障下失效率低至规定值以下，即极小的概率。定量分析本文不做展开，后续会有文章介绍。
结尾：
有三个人将被依次执行死刑，分别是牧师、律师、工程师。
牧师第一个被推向绞刑架。侩子手拉动控制杆以抽出活板，但它失灵了。牧师宣称这是上帝的旨意，要求得到释放。于是他获得了自由。
接着，律师走向了绞刑架。侩子手再一次拉动了控制杆，但它仍然失灵。律师同样要求获得释放，因为他不能因为同一罪状被判两次死刑。于是他也获得了自由。
最后，轮到工程师了。他上去对脚手架仔细检查了一遍，在侩子手还没动手之前，他抬起头大声说，“啊哈，是这里出了故障！”。
谢谢大家！
文章评论（3条评论）
登录后参与讨论
关闭
站长推荐
/2 
/2
-
返回顶部
-
用户1663103 2015-1-16 17:18
dongbei06_409353400 2014-10-30 20:22
用户403664 2014-10-30 11:14