4月底的北京车展可谓盛况空前，各个电动汽车厂家都推出了最新的车型，尤其是国内所谓“造车新势力”，俨然已经成为整个车展的焦点。再加上几位流量大佬的加持，一时间电动汽车吸睛无数，颇有点群雄逐鹿的架势，充分展示了国内电动汽车发展势头之迅猛。

在这种发展势头一片大好的局面下，我作为一名可靠性工程师还是隐隐感觉电动汽车可靠性存在着一些隐患，值得可靠性从业者关注。当我和业内同行聊起我的隐忧时，同仁们也同样存在这样的隐忧。

比如在网上看到，某厂家的一款新车在展示车辆的智驾系统时出现了屏幕死机的现象，颇为尴尬。而这种情况还好只是出现在展示时，如果是出现在车辆行驶过程中，将可能导致安全性事故。而前两天在和一位业内人士交流时，他也提到类似的问题，即车机系统黑屏的问题。因为原来我们在华为做手机可靠性时也遇到过类似的问题，于是就这个问题我们做了比较深入的探讨。

当然造成黑屏、凝屏、卡顿等一系列问题的原因是多方面的，包括硬件、软件、软硬件配合等等。但从目前的统计数据来看，软件原因占了绝大多数，尤其是软件的资源管理机制，包括CPU、内存、带宽等，当然这也是所有软件开发的一个共性问题。

谈到软件可靠性，大家首先关注的是软件的代码质量，即通常所说的bug。这个问题主要还是要靠我们的软件开发流程的规范化来保障，比如基本的编码规范、代码走读、检视，以及各层级的软件测试，变更管理等。但我认为这只是最基础的部分，目前更多的问题还在于我们对产品（软件）的使用场景分析不足，以及相应的后端的测试不足。

之前我写的另一篇有关冗余设计的文章中指出，问题往往不是出在冗余系统设计本身，而是我们对各种可能发生的、需要触发冗余保护的故障场景考虑不足，从而导致该设计没有起作用。汽车相对于手机，其用户的使用操作和环境场景更为复杂多样，因此我们在设计其中的软件系统时必须充分考虑可能出现的各种场景和场景组合，并辅以充分的测试验证。

但一谈到这儿，立刻就出现了另一个关键性问题：过紧的产品开发进度。记得以前跟另一位业内人士交流时，他曾提及某个车企，为了加快产品投放市场的时间，将新车的验证周期从4个月压缩到1个月，导致很多必要的可靠性验证测试无法进行。这似乎是个永恒的、无解的难题，我在企业干了几十年，我完全了解抢占市场先机的重要性，因此对此表示深深的理解；但我同时又是一名可靠性工程师，内心又不能认同和接受这样的一种做法，实在是矛盾。

其实在工程实践中的妥协到处存在，比如我们以前在做FMEA时，因为要分析的器件、信号过多，导致工作量巨大，因此按照失效率做了裁剪；我们的产品规模过大，无法进行规范的筛选，因此用高温老化替代；同样的，规模过大的物料全数检验通常是不可行的，只能用抽样的方式等等。但这种妥协一定是基于能够保障产品基本的可靠性的前提，并经过充分的分析论证，而不是简单的拍脑袋。尤其是对于涉及到人身安全的产品。

我在演讲报告中经常引用的一个案例：美国挑战者号航天飞机事故。这个事故从表面上看，由于一个小小的密封圈故障导致整个航天飞机出现灾难性的后果，但其实其背后也是存在着各种力量的博弈。由于当时的世界局势影响，挑战者号航天飞机必须在上面“规定的时间”完成发射，在这样的一个时间点前，则无法完成所有必需的可靠性验证测试，因此该项目的可靠性工程师拒绝在同意发射的文件上签字，而NASA的项目主管则把这位可靠性工程师叫到办公室对他说：你签不签字航天飞机都要按时发射，所以你最好还是签字。而最后，在没有充分的可靠性验证下，航天飞机还是按时发射了，结局大家也看到了。

因此，国内众多电动车厂家，在产品市场一派繁荣的形势下，更要正视产品的可靠性和安全性问题，而不能一味地抢市场，而忽视其它，最终遭到市场的反噬！而对于我们的可靠性工程师们，更是要坚守我们的职业底线，把好可靠性、安全性的关。