Curiosity 火星服役 13 年：老车没停，靠的是远程运维

Curiosity 已经在火星上工作了 13 年。

这辆 2012 年着陆的火星车，已经行驶近 37 公里，钻取并采样 42 块岩石，拍摄近 76.3 万张照片。更关键的是，它现在还在做地质、环境和辐射观测，科学产出并没有下降。

这件事有意思的地方，不是“车造得结实”这么简单。火星上没人能拧螺丝，JPL 能做的只有远程上传软件、改路线、改排程、少用高风险部件，再把越来越紧的电力分给最重要的任务。

我更在意的是：Curiosity 的长寿，说明深空任务真正难的不是发射那一刻，而是十几年后还能不能维护、取舍和继续相信这套系统。

13 年还在产出数据，反常点不是耐用

Curiosity 原定主任务早已结束。它能走到今天，和 RTG 供电有关。RTG 不靠太阳能板，所以它没有被火星尘暴直接卡死。

但 RTG 也不是无限电池。功率会随时间衰减，问题不是某天突然断电，而是每天少一点余量。到后期，少做一次加热、少跑一段路、少开一台仪器，都会变成任务选择。

目前 JPL 的判断是，Curiosity 至少有望工作到 2035 年前后。但功率衰减会逐步影响科学活动强度，尤其是在后续延长期任务里。

这对行星科学团队很实际。火星表面十多年连续观测很稀缺，环境、辐射和地质数据的时间跨度，本身就是资产。

对未来载人火星任务也是一样。人类要去火星，不能只关心火箭能不能到，还要知道设备在火星表面老化后会怎样工作、怎样降级、怎样继续交付数据。

真正的续命，是把故障变成可管理状态

Curiosity 最典型的一次补救，发生在车载计算机上。

它有 A/B 两套计算机。早期 A 机因为 NAND 存储异常，任务切到 B 机。后来 B 机又遇到无法挂载分区的问题，团队只好重新考虑那台长期不被信任的 A 机。

JPL 的做法很克制，也很冒险：放弃旧版飞行软件占用的两块 32MB NOR 存储，把合计 64MB 空间改造成 A 机文件系统。这套修复被称为 R-Hope。

64MB 在今天几乎小到可笑。但在火星上，它让 A 机在不到原始存储 1% 的条件下，重新具备“救生艇”价值。它不能让任务轻松，只是给团队留下诊断、转移数据和继续操作的余地。

轮子问题更直观。Curiosity 原本预期会压过沙地里的小石块，实际遇到的是埋在沙下、边缘锋利的大石头尖端。前轮被撕裂得更快，路线就必须改。

于是 JPL 调整行驶策略，包括避开更危险的地形、必要时倒车行驶。自拍也变少了，因为机械臂关节执行机构的使用次数同样有限。每动一次，都是消耗。

这对航天与机器人技术读者的启发很直接：可维护性不能等故障出现后再补。

如果你在做长期无人系统，需求阶段就该把遥测粒度、故障恢复分区、软件补丁通道、电力和热控状态暴露出来。否则十年后能不能救回来，很可能取决于操作员记不记得某个边角设计。

对关注深空任务工程运维的人来说，动作也很具体：评估任务时不要只看载荷、速度和算力。要看它能不能远程诊断，能不能安全降级，能不能在资源变少后继续交付核心数据。

和 Perseverance 对比，差别在任务取向

Curiosity 常被拿来和 2021 年着陆的 Perseverance 比。这个对比容易被说成“新车全面升级”。事实没那么简单。

两者主处理器都是 RAD750，内存规模也大体相近。Perseverance 的明显差异，是额外配置了视觉里程计处理器，更适合长距离自动驾驶。

这也是 Curiosity 留给后续火星车的关键经验：硬件指标重要，但十年后的操作员同样重要。

立项和采购时，如果只把钱花在载荷参数上，却没有提前给运维团队足够的数据接口和恢复工具，后期成本会变高。团队可能不得不推迟部分科学活动，把时间挪去排障、保守驾驶和电力调度。

接下来要看的，不是 Curiosity 会不会突然“失去科学能力”。目前没有这个结论。

更现实的观察点有三个：RTG 功率何时开始明显压缩科学活动；如果机械臂能力下降，任务会怎样转向远程成像、环境和辐射观测；预算会不会比硬件更早成为瓶颈。

预算这一点要谨慎。受访者的说法只是“也许瓶颈是预算”，不是已经确认经费削减。但深空任务活得越久，就越要和年度预算表一起生存。

Curiosity 这辆老车还在火星上干活。它靠的不是奇迹，而是一整套远程维护能力：能修一点算一点，能省一点是一点，能把风险往后推一点，就多拿回一批科学数据。