1.4亿公里外的两次重启：赫拉探测器如何完成软件升级

今年7月8日，欧洲空间局（ESA）宣布，正在飞往双小行星系统的赫拉探测器完成了一次深空软件升级。

升级发生时，赫拉距离地球约1.4亿公里，正以超过12公里/秒的速度在太空中飞行。地面发出的指令，需要通过直径35米的深空天线对准特定空域发送，单程通信延迟接近8分钟。仅等待一次指令往返，便要接近16分钟。

软件上传完成后，任务团队还需要让整艘探测器重启两次，分别检查并行运行的两套处理器通道。历时两个多星期后，赫拉按计划恢复工作，开始为抵近小行星后的探测任务做准备。

对普通电子设备来说，软件升级通常只是点击确认、等待重启；但对一台已经飞到1.4亿公里外、无法接触也无法维修的航天器而言，每一次状态切换都必须慎之又慎。赫拉的这次升级，也让深空任务背后不太显眼的一环走到台前：航天器升空并不意味着软件开发结束，真正复杂的验证可能仍在继续。

▲赫拉探测器将携带两颗立方星前往迪迪莫斯和迪莫弗斯组成的双小行星系统，对NASA的DART撞击结果开展近距离调查。图源：ESA/Science Office

赫拉是ESA首个行星防御任务。它要前往由迪迪莫斯和迪莫弗斯组成的双小行星系统，对人类第一次主动改变小行星轨道的结果进行近距离调查。

2022年9月，NASA的DART探测器撞击了直径约151米的迪莫弗斯，使其绕直径约780米的迪迪莫斯运行的轨道发生改变。这次撞击证明，人类有可能通过动能撞击改变小行星轨道，但撞击究竟留下了怎样的撞击坑、小行星内部结构如何、能量传递效率有多高，仅凭地球上的远距离观测还无法完全回答。

赫拉将利用相机、激光雷达等设备对目标进行测量，并释放两颗立方星开展更近距离的探测。它需要在极弱引力环境中自主导航，还要维持主探测器、立方星与地面系统之间的通信。ESA将其自主能力比作自动驾驶汽车，这意味着飞行软件不仅要接收地面指令，还要根据传感器信息判断周围环境并执行相应动作。

但赫拉在2024年10月发射时，搭载的并不是执行小行星阶段任务所需的最终版软件。

这是任务窗口与研制进度之间的工程权衡：为了借助次年春季的火星飞掠调整轨道，赫拉必须按时出发；一旦错过窗口，抵达目标可能要多花数年。任务团队因此先让具备巡航能力的探测器升空，再利用漫长的飞行阶段继续完成软件开发和地面验证。

此次升级完成后，赫拉将进一步启用尚未投入工作的仪器，使用抵近小行星所需的自主导航功能，并为后续与两颗立方星建立星间链路做好准备。对赫拉而言，这不是一次普通的功能更新，而是从巡航阶段进入小行星探测阶段前的关键准备。

远程更新航天器软件，难点首先在于地面无法立即知道指令执行到了哪一步。

在近地设备上，操作人员可以连续观察状态、快速撤回命令，必要时还可以接触硬件排查问题。赫拉与地球之间接近8分钟的单程延迟，则把每一次操作都变成了漫长等待：指令发出后，地面团队要等它抵达探测器；探测器执行并返回遥测数据后，又要等待信号穿越同样遥远的距离。

更关键的是，升级最终需要通过重启生效。赫拉的星载计算机采用并行处理器通道提供冗余，两次重启用于依次检查不同通道。重启期间，地面暂时失去对航天器状态的直接确认，只能等待它在预定时间重新发回信号。ESA的七人核心操作团队守在控制室内，为未能按时恢复通信等情况做好准备。最终，两次重启均按计划完成。

冗余设计能够提高可靠性，但冗余系统本身也带来了更多需要验证的状态：

两套通道能否正确启动

任务数据能否保持一致

主备关系能否按预期切换

升级前后的软件能否与仪器、通信和姿态控制系统正确交互。

升级文件成功上传，只是过程中的一步；航天器能够在新软件下重新建立完整、稳定的工作状态，升级才算真正完成。

▲位于德国不来梅的赫拉航电测试台，是赫拉航天器的全尺寸硬件功能副本。飞行软件在这里完成地面运行与验证后，才被上传至深空中的探测器。图源：ESA，图片版权：OHB

在第一条更新指令发出之前，赫拉的软件已经在地面验证了一年半，累计占用50个测试日。ESA称，这是其任务控制中心开展过的最复杂的软件测试工作之一。

飞行软件被放入位于德国不来梅的赫拉功能副本中运行，围绕模拟的双小行星环境演练自主导航。测试平台还接入两颗立方星的真实副本，验证星间链路和多航天器交互。传感器输入、导航判断、控制指令、设备响应和遥测反馈由此形成完整闭环，经过反复演练后，升级指令才被发往1.4亿公里之外。

赫拉的地面测试过程说明，复杂装备的软件验证不能只盯着代码本身。

飞行软件最终运行在由处理器、存储器、总线、外设和操作系统共同构成的嵌入式环境中，任何一个接口、时序或设备状态发生变化，都可能沿着任务链影响最终结果。但真实硬件往往数量有限，部分设备交付较晚，实物平台也难以同时满足多个团队反复调试的需要。

天目全数字实时仿真软件SkyEye可对处理器、存储器、总线和外设等硬件资源进行硬件行为级建模，在通用计算平台上构建嵌入式数字样机，并运行与真实目标系统相同的二进制程序。研发人员可以观察软件启动、任务调度和设备访问过程，也可以利用状态快照、故障注入和自动化脚本，反复验证通信异常、外设故障、重启恢复等场景。

▲SkyEye界面图

对于航天器软件升级，这类虚拟环境还可以保留不同软件版本和硬件配置，持续执行回归测试，使验证不再完全受限于少量实物设备，并让问题更早暴露在设计和开发阶段。