汽车故障检测软件_汽车软件故障诊断系统之思考

几年前在一家汽车电子公司做软件开发工作时，科经理说:“汽车软件里有至少30%是用来做故障诊断系统管理的”，也就是DSM。可见故障诊断是很重要的事情，因为有些故障会影响到驾驶员和乘客安全。

所以，软件开发人员经常会思考一个问题“用户开车过程中，指从点火开始到熄火结束全过程，包括车辆静止时，当检测出故障时控制器软件该怎么继续控制车辆动作保证乘客或车辆安全？”

一，很重要的问题，用户是谁？

我们希望:在产品开发和测试阶段，能够检测出所有可能的故障并让控制器做出预期的响应。在卖给消费者后，永远不要再发生故障。

这是因为测试人员和消费者对故障的容忍度完全不一样。测试员期望能检测出任何故障，接受故障发生后的动作，比如硬件损坏，汽车抛锚等。然后读出故障记录后反馈给硬件设计人员更改方案。

消费者不一样，他压根就不接受故障的发生。哪怕故障发生后已经通过软件动作让乘客处于安全状态。一次高速抛锚的事情就可以让消费者对产品质量怀疑，两次三次那就直接放弃产品。在这个层次，对软件故障系统管理是达到了目的，然而对整车的机械和电子系统可靠性是失败的。例如，下图事件:

所以说，虽然汽车软件里有30%是用来做故障诊断管理的，但是我们期望这部分功能在90%的时间发生在开发测试阶段。在车辆售出后，最好就不要发生了。要实现这个目的至少有两个条件:

1.软件故障检测覆盖范围要足够广泛。

2.每次测试发生的故障都要找出根本原因并解决之，而不是忽略或屏蔽。

二，软件是为硬件服务的

虽然我的工作是软件开发，但是我坚持这个信条。随着autosar观念越来越流行，硬件，底层，应用层开发的独立性越来越好，有些模块开发可以关起门来自己玩。大家逐渐关心的只是互相间的接口而非整体，这是不好的现象。

软件不是自己玩着哈皮就行，你对硬件的服务功能做到位了没？还有哪些没有做？有没有什么特殊的工况不能检测出故障或者存储故障数据？这些是最重要的问题，其他的才是独属于软件的事情。

三，结尾

神舟飞船的逃逸塔是火箭飞行故障检测和响应系统，在开发测试阶段我们希望它百分之百成功。然而在正常的载人发射时，希望它永远不要起作用。

事实的确是这样！