Rivian 软件更新导致信息娱乐系统变砖，修复并不明显

原文 ↗ Hacker News 讨论 ↗

近期 Rivian 推送的一次空中软件更新在一些车辆上把信息娱乐和显示系统软性变砖，车辆仍可驾驶，但没有屏幕、空调控制，某些情况下连车速表也看不到。评论者借此批评 Rivian 的更新流程，并强调嵌入式与汽车软件的既有最佳实践，例如分阶段推送、A/B 分区、看门狗以及稳健的回滚路径，这些都应当让此类故障能够恢复。更广泛地说，这一事件也引发了更大的争论：持续更新、高度联网的汽车，是否真的值得为此承担额外的复杂性与风险；相比之下，“傻瓜式”车辆采用更简单、连接更少的系统，是否更可取。

根本原因与技术故障模式

  • 评论者说 Rivian 确实在内部车队上测试了这次更新；故障很可能发生在发布/部署过程中（例如“手滑”式发布、错误的构建版本或密钥）。
  • 许多人猜测 OTA 包本身签名正确，但其中一个组件（信息娱乐二进制文件）用了测试/非生产密钥签名，而生产启动加载器拒绝了它。
  • 也有人认为 OTA 层验证的内容与各个子系统在启动时验证的内容不一致，导致显示栈软性变砖。

OTA 架构与保护措施

  • 大家普遍认为，健壮的 OTA 必须包含：
    • A/B（甚至三重）启动分区，以及在启动失败/部分启动失败时自动回滚。
    • 与真实系统进度挂钩的看门狗，而不只是一个定时滴答的守护进程。
    • 金色“恢复”镜像和经过测试的恢复路径。
    • 分阶段、随机化的分批推送，并通过遥测进行门控。
  • 一些工程师指出，这类模式在嵌入式/汽车领域已经存在几十年；这里的失败被视为流程/优先级问题，而不是技术难题未解决。

影响范围与安全性

  • 报道称关键驾驶功能（电机、刹车、灯、雨刷、摄像头）仍可工作；主要损失是信息娱乐系统，以及对部分车辆来说，仪表盘/车速显示和 HVAC 控制。
  • 也有人认为这仍然是安全问题（没有速度表、无法除霜、在极端天气下难以便捷调节空调）。
  • 关于此类事件是否会或应该触发召回、以及是否会引发保险方面的复杂问题，存在争论。

更广泛的争论：汽车中的 OTA 更新

  • 一派观点：汽车应该尽可能“定型”并离线；OTA 是不必要的风险，尤其当它能在一夜之间禁用关键功能时。
  • 另一派观点：OTA 对修复漏洞、安全/安保更新以及新功能很有价值（例如改进充电曲线、新驾驶模式、UX 修复），尤其是在服务中心稀少的情况下。
  • 许多人批评把“快速行动、打破常规”和 CI/CD 思维应用到安全相关系统上。

对比与行业背景

  • 有人将其与 Tesla、Polestar、BMW、Volvo、Ford 等进行对比；其中几家也有 OTA 问题，但通常较少出现全车队范围的变砖。
  • 很多人强烈认为，汽车厂商把信息娱乐系统做得过于复杂，应当优先使用 CarPlay/Android Auto 或更简单的“傻瓜式”界面，并尊重用户所有权、隐私和维修权。