不止于模拟：让数字卫星成为持续验证资产

一套卫星软件，从上电启动到完成一次星地交互，要经过处理器、存储器、定时器、中断控制、总线接口、实时操作系统、驱动和业务任务等多个层次。任何一个环节存在偏差，都可能在系统联调阶段表现为启动停滞、通信异常、任务超时或状态不一致。

传统模式通常要等板卡、接口设备和联调环境逐步到位后，才能把这些层次真正串起来。此时软件已经积累了多个版本，问题也从单一模块扩散到系统链路：究竟是接口没有收到数据，还是中断没有产生？又或者是驱动没有读取？仅凭现象往往很难回答。

天目全数字实时仿真软件SkyEye（以下简称“SkyEye”）提供了另一条工程路径：在计算机中搭建处理器和关键硬件的行为级模型，直接加载原始可执行二进制，使RTOS、BSP和应用软件运行在虚拟目标系统中。由此，验证活动可以在真实硬件到位之前启动，并从“能否跑起来”逐步延伸到接口闭环、异常定位和自动化回归。

▲图1  星载计算机软硬件总体架构图

卫星软件通常具有接口类型多、任务周期严格、软硬件耦合深等特点。软件面对的是一组具有明确寄存器语义、时序关系和中断机制的硬件资源，只验证函数输入输出无法覆盖软件在目标系统中的完整行为。

另一方面，实物资源天然具有稀缺性。一套板卡或联调环境常常需要被多个团队、多个版本共享；一旦进入系统联调，任何一次环境调整都会影响其他任务。对于低概率故障，现场状态更难完整保存，串口打印和调试器介入还可能改变原有时序。

因此，卫星软件需要一种可以提前获得、按需复制并支持深度观测的目标运行环境。它既要保留目标软件对硬件的访问方式，也要能够提供物理设备不易提供的暂停、检查、重复执行和故障注入能力。

一套能够用于工程验证的数字卫星模拟器，需要实现“可运行、可交互、可观测”三个基本目标。

“可运行”，是指虚拟目标系统能够承载引导程序、RTOS、BSP和应用软件，支持处理器取指、内存访问、存储读取、定时和中断等基础行为，使目标软件沿原有启动路径进入工作状态。

“可交互”，是指模拟器能够提供1553B、RS422等通信接口的行为模拟，使外部测试激励可以进入虚拟设备，经驱动程序和业务逻辑处理后，形成遥测、状态或控制响应。

“可观测”，则要求验证人员能够分别查看SkyEye主机侧设备模型、虚拟机内RTOS与BSP以及应用软件的运行状态，从寄存器、内存、指令执行、设备访问和任务输出等不同层次寻找问题依据。

▲图2  SkyEye卫星模拟器总体架构

SkyEye首先承担的是虚拟硬件底座。通过对处理器、内存、Flash、定时器、中断控制器和板级设备的行为级建模，软件能够按照原有方式访问目标资源。对应用软件而言，它面对的仍然是寄存器、地址空间、中断和设备状态，而不是为测试临时改写的一组桩函数。

这种方法的重要价值是可以直接加载原始可执行二进制，引导程序、RTOS、BSP和应用保持既有形态，验证对象与目标交付物之间的差距更小。软件在虚拟环境中暴露的问题，也更容易沿着真实启动链和调用链进行分析。

对于FPGA等可编程逻辑，卫星模拟器更关注软件可见的外部行为，例如寄存器读写、数据缓存、状态变化、中断触发和数据通路，而不是复现底层门级实现。功能级建模既保留了软件交互所需的关键语义，也让模型能够围绕验证目标持续演进。

接口模型则连接数字卫星与外部测试环境。1553B、RS422等通信进入SkyEye后，可按照设备寄存器、缓存、状态位和中断关系传递给虚拟机内的软件；软件生成的结果再经模型送回外部，形成完整闭环。

因此，数字卫星模型并不追求对全部物理细节进行无差别复刻，而是围绕软件验证需求，准确呈现寄存器语义、状态转换、数据路径和中断关系等关键行为。

数字卫星的闭环验证从一次正常启动开始。SkyEye加载目标二进制，虚拟处理器从预定入口执行，引导程序完成基础初始化，RTOS建立任务和系统服务，BSP识别虚拟设备，随后业务任务进入周期运行。这个过程能够检验的不只是应用逻辑，还包括存储映射、设备初始化、中断链路和任务调度是否协调。

当外部测试环境发送一条遥控激励时，数据首先进入通信接口模型。模型按照目标设备的可见行为更新缓存、寄存器或状态，并在满足条件时产生中断。虚拟机内的驱动响应中断、读取数据，业务任务再完成解析、状态迁移和指令执行。

处理结果沿相反方向返回：应用形成遥测或状态数据，驱动写入接口设备，SkyEye模型捕获发送行为并输出到测试环境。至此，一条“激励进入—设备响应—软件处理—结果返回”的星地闭环才真正完成。

这条链路的意义在于，每个阶段都可以被独立观察。验证人员既能确认外部数据是否到达模型，也能检查中断是否触发、驱动是否读取、通信任务是否使用，以及返回数据是否经过正确接口输出。问题不再只是“通信不通”，而能被收敛到明确的层次和环节。

▲图3  从上电启动到星地通信的验证闭环

启动链验证： 检查处理器执行、存储读取、系统初始化、驱动加载和业务任务建立是否形成一致链路，避免将单条启动信息作为系统正常运行的唯一依据。

接口闭环验证： 通过向虚拟接口注入数据，检查设备状态变化、中断产生、驱动读取、应用处理和结果返回是否符合预期，提前发现接口映射、缓存语义和时序配合等问题。

白盒问题定位：利用寄存器与内存查看、指令流记录、地址监视、设备状态检查和GDB调试等手段，将“通信不通”“任务未响应”等外部现象收敛到具体层次。

自动化回归： 将启动、激励、等待、状态采集和结果检查编排为可重复执行的测试场景，使同一套数字卫星服务于多个软件版本。典型故障及其验证方法也可以保存下来，转化为后续版本的回归测试资产。

需要注意的是，不同层次的运行信息具有不同的证据边界：设备模型记录反映硬件行为，RTOS信息反映系统运行状态，应用输出反映业务执行结果。只有多层信息相互印证，才能形成可靠的验证结论。

▲图4  传统硬件联调与SkyEye全数字验证路径对比

当模型只服务一次问题定位时，它是一套调试环境；当模型、场景和判据能够随软件版本持续演进时，它就开始成为数字验证基础设施。未来的卫星模拟器将不再局限于单板和单节点，而会逐步连接更多分系统模型，在统一时间和接口关系下开展联合仿真。

验证内容也将从基本功能扩展到故障注入、代码覆盖率、实时性评估和持续集成。新的软件版本提交后，可以自动启动数字卫星、执行既有场景、采集状态并输出结果，让系统级验证成为研发流水线中的常态动作。

更重要的是，数字卫星会随着工程推进不断积累。启动链、设备模型、接口场景和问题判据不再散落在个人经验中，而是沉淀为可运行、可回放、可扩展的工程资产，为后续版本升级、维护验证和新任务适配提供基础。

从软件启动到星地闭环，从单次调试到持续回归，全数字仿真的方向正在变得清晰：让验证摆脱对单一物理环境的等待，让复杂问题拥有可观察、可复现、可验证的过程，并让每一次工程实践都成为下一次研发的起点。