小米SU7事故 官方数据证明官方设计有缺陷？

织里资讯

作者 | 王秋凤








现实有时间比想象还要有想象力。3月29日晚上，一辆小米标准版在德上高速公路池祁段行驶过程中，遭遇重大事故，车上3人全部死亡。隔了2天半，4月1日中午，小米官方对这件事的回应，突然冲上热搜第一。这次是不是买的热搜，需要大家自行判断。如果是的话，小米确实有些路径依赖了，舆论工具箱里不应只有流量一种。


官方开释的信息


小米官方称，当时高速事发路段施工修缮，用路障封闭本车道，改道至逆向车道。车辆检测障碍物后，发出提醒，并开始减速。随后驾驶员接管车辆进入人驾状态，持续减速并操控车辆转向，随后车辆与隔离带水泥桩发生碰撞，碰撞前系统最后可以确认的时速约为97km/h。





更应该关注的，并非电池爆燃和可否开门，因为时速97公里下的正向碰撞，什么能源方式和车门设计，已经不告急了。


我们更应该聚焦官方发布的时间-变乱轴，夺取找出缘故原由大概规律来。


接下来，我们全文抄录官方数据：




3月29日 22:27:17 NOA激活，车速116km/h


3月29日 22:28:17 轻度分心报警


3月29日 22:36:48 NOA发出脱手预警提示“请手握方向盘”


3月29日 22:44:24 NOA发出风险提示“请注意前方有障碍”，发出减速请求，并开始减速


3月29日 22:44:25 NOA被接管，进入人驾状态，方向盘往左转角22.0625度，制动踏板开度31%


3月29日 22:44:26 方向盘往右转角1.0625度，制动踏板开度38%


3月29日 22:44:26-28之间 车辆与水泥护栏发生碰撞


3月29日 22:44:28 车端Ecall触发


3月29日 22:44:39 车端Ecall接通，确认事故发生，并报警、呼叫120急救服务


3月29日 22:45:06 与车主取得联系，确认非车主驾驶


3月29日 22:47:15 调配120乐成


3月29日 约23时许 120抵达现场。




三点疑问


这内里蕴含的信息，哪怕有大概被遮掉的信息，对还原事态都价值非凡。信任官方数据的前提下，我们关注到以下3个告急的点：


第一，小米标准版没有AEB。不管他设置表上有没有，实际就是没有。


22:44:24提示风险，22:44:25就被人工接管，驾驶员反应是相当在线的。至于减速，2秒内从116km/h减到97km/h，大部分减速是人工完成的。因为被接管的刹那，制动踏板开度仍然只有31%（开度越大，刹车力度越大，但非线性对应关系）。


计谋上，不管人工照旧高速NOA，这么快的车速下，配合打一点方向（不能打大方向，否则姿态稳不住），同时应全力刹车。而全力刹车每秒应该能减25m/s左右。而实际上高速NOA并未采取这一计谋，让人狐疑。看来它并未将局面视作必须全力避免的情况。


这表明，SU7的AEB没有介入。


第二，传感器探测距离，不支持120km/h下的NOA。


SU7标准版没有激光雷达。摄像头探测距离莫衷一是，大致的说法是100米以内，但这和现场夜间照度有关。如果高速上照度不足，远光灯也射不了100米以上，116km/h的速度，折算成32.2m/s。100米的距离，3.1秒跑完。NOA系统没有能力在1秒内处理这个非结构化场景（修缮、封闭本车道、导引到其他车道），就只剩下2.1秒给人工了。这套规则显然不合理。


实际情况下，距离碰撞2秒的时间（未标精确碰撞时间点）才要求接管，驾驶员花1秒接管（已经很快了），剩下1秒。全力刹车的话，官方百公里时速刹车距离是33.5米。而时速116公里，刹停距离33.5*1.16=38.86米，是非常抱负化的。因为高速制动存在钝化效应。而且说实话，就是这个33.5米，也是专业人士在赛道上、非紧急情况下踩出来的。普通人慌乱时要是能达到这个水平，可以说比赛车手都厉害了。


如果现场这个驾驶员说天赋异禀行不行？不行。因为碰撞时速仍有97公里，人工接管时的时速至少在105公里以上。此时还剩1秒-3秒。如果取“时间前沿”（1秒），我们按照最守旧的97公里时速来算，距离障碍物只有26.9米，时速97公里，完全无法刹停。


如果取“时间后沿”（3秒），此时距离障碍物还有80.8米（仍按97公里时速），理论上可以刹停。


那么就引出第三个问题了，时间颗粒度问题。


即碰撞发生前的时间-变乱轴颗粒度非常精细，但到了碰撞的时间，官方就给出非常宽泛的2秒时间，以至于无法精确标定碰撞时间点。


一种大概，碰撞过程花了2秒，那么就满意时间前沿的说法，即当时情况下，只要NOA是这个工作方式，碰撞就无法避免。


另一种大概，车辆碰撞的瞬间，大电池和小电瓶均掉电，后台因此没收到精确数据。


第三种大概，官方故意“粗化”了碰撞时间颗粒度，避免引向一个唯一的结论——小米SU7标准版，在夜间不应该支持时速超过100公里以上的NOA。


具体结论如何，各位自行判断。


以上三点，并非一定就是小米的问题。小米如果希望自证的话，应该公布更具体的原始数据，比如传感器日志、制动系统相应曲线、重建现场动态图等。一方面有助于透明化调查过程，另一方面也可以重建对小米NOA技能的信心。





小米大概的失误


智驾系统在事故无法避免的情况下要求人工接管，是非常不负责任的。既然硬件能力上不支持，就不应该允许客户低照度下进入高速NOA。


虽然小米不大大概公布具体的算法逻辑，但我们料想，算法对非标障碍物的辨认存在短板。采取措施太晚，措施又不够坚决。发现不行，再让人工接管，已经于事无补。


和NOA的甩锅一样，官方声明也有甩锅嫌疑。官方字里行间大概暗示，NOA系统减速了，也提醒了，驾驶员没处理好。但实际情况是此时接手，神仙来了也难救。即算法未能给接管机制提供足够冗余。


还有个小细节，就是有人认为小电瓶没断电，Ecall可以或许接通。而Ecall实际上用的是备用电源，和小电瓶无关。


这也反映了小米对实车验证、数据闭环非常不足。高速修缮，属于长尾工况，低照度下高速，是常见工况（出现风雪雨雾等天气，也是常见的）。而高速上出现标准和非标障碍物，是必须要测试到的。


这个时间考验AEB阈值的时间就到了。效果AEB没有介入，系统相应延迟，导致未能把握时间窗充分降速。


小米此前因为自动泊车Bug，导致多辆车同一时间段失事故。官方并未给具体解释，因为舆论压力不大（好像没出现伤亡）。这次很难回避了，小米迄今的回应，很智慧地没给结论。但官方数据自己，已经透露了小米技能存在缺陷的大概性很大。


结 语


任何NOA，不管高速照旧城区，都需要增强场景泛化能力，提升对非标障碍物的辨认能力，这方面的验证是否充分，决定了NOA的体验，少数时间则是生与死的差别。机制上，应该给人工接管留下冗余时间。


小米应该将重点放在还原事态、优化技能上面。小米的流量打法，一直以来确实无往不利，若这种事也用流量打法，未免太过突破下限。小米应该不屑为之。

-E N D-

秋凤空间
无肇因之始，无自限之垣
品茗聚友，坐而论道。



来源：https://view.inews.qq.com/k/20250401A079VE00
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！