特斯拉仍然深陷于舆论漩涡。纵使业界呼吁理性看待特斯拉「刹车门」事件，但这场风波很难在短时间内消弭，包括说服大众的真相也很难一锤定音。
为了寻找真相，我们需要跨过两座大山。
第一座大山是数据。目前，特斯拉向媒体公开的数据不全。多方隔靴搔痒，也只能在迷雾中分析造成事故的可能原因。下一步，只有等待更全的行车数据，以及车内EDR的记录信息。
第二座大山是检测机构。在行业内，暂时还没有出台针对智能汽车检测的标准规范。同时，也很难找到有对应检测能力的第三方检测机构，他们既没有鉴定智能电动汽车的设备，也缺乏相应的鉴定标准。
在这件事情上，我们有可能既找不到「米」，也找不到「巧妇」。短期内，真相只会悬而未决。
EDR数据到底会不会说谎？
特斯拉“刹车门”，就事件定性而言，这是一场需要探明真相的交通事故。
事实上，在交通事故中，涉及到人、车、路、环境等多方面因素，我们需要获取准确、客观的车辆事故重建数据。
在欧美等国家，大部分车辆都会强制配备EDR。在我国，曾于2017年出台《机动车运行安全技术条件》细则，其中规定今后生产的车辆都需要配备EDR。
汽车EDR工作流程EDR是什么？全称是Event Data Recorder，即事故数据记录系统，一般整合于车辆内部，用于记录碰撞前后一系列动态数据。
在正常通电状态下，EDR将会不间断收集车辆行驶数据，并且覆盖掉原有的数据，处于一个动态记录的过程。当达到碰撞触发条件时，EDR将会自动冻结事故碰撞前后的数据，具体记录的数据包括车速、加速度、油门节气阀、加速踏板、刹车踏板等。
从机械时代进入智能电动时代，汽车正在从信息孤岛逐渐走向网联互通，完成一个从封闭到开放的演化过程，这更像一款电子产品了。
如果这只是一辆非常传统的汽车，EDR在事故鉴定中，势必会起到不可替代的作用。它本质上就是一个「黑匣子」，有没有踩刹车，刹车机械系统有没有问题，一目了然，EDR数据的全面性和可靠性已经得到了认可。
特斯拉Model S碰撞事故中的EDR数据在智能汽车的事故中，EDR提供的数据同样非常重要。追溯到2016年曾在美国发生的一起特斯拉碰撞事故，特斯拉Model S在驾驶辅助功能开启的状态下，撞上了一辆货车。
美国SCI根据EDR数据进行事故重建，得出的结论是，特斯拉Model S没有检测到前方有货车，所以碰撞预警系统和自动刹车系统没有生效，而驾驶员没有时刻关注路况，没有及时制动，在特斯拉驾驶辅助系统属于L2级别的前提下，驾驶员需要负全责。
来自于广东警官学院的一篇论文中，对这起典型的事故，提出了一些疑点。「根据SCI调查结果，驾驶员理论上有7.7秒可以发现前方的货车，但EDR数据显示并没有采取制动措施，这在传统事故中比较少见，不排除自动驾驶控制权反馈失误的可能性。」
EDR不易被篡改，呈现的数据是真实的。只是，在智能汽车的事故重建中，仅有EDR数据还不够全面。
需要补充的至少还有两大类数据，其一，驾驶员的行为记录，主要是驾驶员与车辆直接互动的情况，比如脚有没有在刹车上，并且施加了多少力；其二，关键事件记录，尤其是摄像头视频数据，理论上，要达到360度全方位记录，智能汽车完全可以做得到。
日前，有消息称，特斯拉正在开发一套线上信息系统，可以供用户自由查看车辆后台数据，预计年内即可上线。如果消息属实，特斯拉终于走出了开诚布公的重要一步。至于可查询的数据属于什么类别，是否能做到「全面、透明、直接」，以及能否反应出车辆的实际行驶状态，我们将持续保持关注。
软件定义汽车，我们很难抓到闯祸的幽灵吗？
一百多年来，汽车行业内生的变化总是趋于缓慢的。谈及变革，往往需要跨界新技术的狂暴式推动。
在过去，汽车工业首先是一个制造行业，我们最关心的是发动机、底盘。但近几年，行业内对智能汽车的理解不断加深，所以，软件的关注度上升了。
以前，并非没有软件的概念。比如控制发动机，也需要在ECU中编写控制代码，只是这样的控制比较简单，所以不容易浮现软件错误。而且，这些关键零部件一般是由Tier 1供应商提供的，他们专司其职，可以不断进行优化。
现在，汽车行业基本全盘押注于软件价值，各行业巨头不断成立软件部门。摩根士丹利研究中心认为，在未来汽车竞争中，车辆硬件价值下滑到40%，软件价值则上升到40%，内容和服务占20%。
从分布式到集中式，汽车一定会逐渐演变成电子产品。
只是，汽车比较特殊，在涉及行驶安全的问题上，基本要确保非常低的bug发生率。这是行业朝着「软件定义汽车」演变时，必然经历的技术挑战。
对于如何确保很低的bug发生率，一位行业内的软件工程师提到最多的一点就是「测试」。他们会根据最初的软件需求，在开发过程中不断完成循环测试与评价，最后在系统集成后继续进行对整个系统的测试。
看上去，测试更像一个「笨功夫」，不断循环，列举尽可能多的情况。为了提高效率，并非所有的测试都要在实车上进行，很多前期工作可以在模拟环境中进行。但为了确保安全，也需要在恶劣的工况中进行全面检测，这即是「三高试验」的意义所在。
软件出现问题，非常像闯祸的幽灵，很难被轻易抓住。由于诸多关键零部件是由Tier 1供应商提供的，与硬件结合的软件，同样由他们主导，主机厂未必清楚其中的细节。一旦出现bug，仍需要由供应商自查自检。
而如果像特斯拉这样的智能汽车出现问题，如果从底层代码查起，更是指数级放大的工作量。站在第三方检测机构的视角来看，目前他们能做的也只有场景复现，检查机械执行机构是否有问题。他们没有权限，更没有能力在代码的海洋中找bug。
这样的挑战将会长期存在，但问题已经刻不容缓了。据报道，在2013-2018年的汽车召回案例中，与汽车智能系统和功能相关的召回共有20次，涉及20.69万辆；涉及软件的召回次数109次，召回车辆191万辆，召回次数及数量均明显上升。
另据盖世汽车统计，2019年因软件问题引起的召回次数及数量不减。该年度，我国汽车市场因软件问题共展开22批次召回，涉及缺陷车辆累计39.46万辆。
这是一个相互掣肘的问题。一方面，我们拥抱智能汽车带来的新体验，另一方面，潜在的软件问题如幽灵一般，如果总是带来莫名其妙的安全威胁，智能汽车只会在质疑与不安中踌躇不前。
写在最后
智能电动车的趋势演变已成行业共识。在这个过程中，存在问题当然要直面问题，更需要有对应的解决方案。
非常重要的一点是，针对智能汽车检测的标准规范有必要快速建立起来。相关检测设备、方法，以及既懂汽车硬件又懂软件的交叉型人才，也需要迅速跟进。
更微妙的，是社会舆论对于智能电动车的态度。要么狂热追捧，要么疯狂踩踏，这都不是该有的理性态度。真相水落石出，还需要很长的时间，但这次事件对智能汽车标准漏洞的补齐，终究是大有裨益的。
