1. 星务计算机数据管理与日志记录概述

星务计算机（On-Board Computer，OBC）是航天器电子系统的核心处理单元，通常承担遥测采集、遥控指令解析、姿态与轨道控制律计算、任务调度、时间管理、总线通信以及数据存储与下传等职责。它并不等同于单一处理器芯片，而是由CPU模块、存储器、看门狗、总线接口、供电与复位管理等构成的完整机载计算系统。在整星架构中，星务计算机处于"信息中枢"位置：向下通过1553B、CAN、RS-422、SpaceWire等总线连接敏感器与执行机构，向上通过测控应答机与地面站交互，横向与数传、电源、热控等分系统交换状态数据。

数据管理与日志记录是星务计算机软件中两个紧密耦合但边界清晰的功能域。数据管理关注"数据在哪里、以什么格式存在、何时被读写、如何保证一致性"，其对象包括遥测参数、遥控指令、任务计划、轨道与姿态数据、分系统状态字等；日志记录关注"发生过什么、何时发生、由谁触发、结果如何"，其对象是事件记录、异常记录、操作审计记录和关键状态变迁记录。二者的关系可以概括为：数据管理维护"当前状态与业务数据"，日志记录维护"历史轨迹与因果证据"。当星上出现复位、总线超时或参数越界时，日志是定位根因的第一手材料，而数据管理则决定了这些日志能否被可靠写入、保存并在过境时下传。

典型星务计算机架构与数据流

一个典型的星务计算机采用分层架构：最底层是硬件与BSP（板级支持包），中间是实时操作系统（RTOS）或时间片调度内核，上层是应用任务。数据流通常沿三条主线运动：

• 采集链：敏感器/分系统 → 总线接口 → 驱动层 → 数据池（Data Pool）→ 遥测组帧 → 下行。
• 指令链：地面遥控 → 测控应答机 → 遥控解码 → 指令分发 → 执行机构/分系统，同时写入操作日志。
• 日志链：各任务事件 → 日志服务 → 环形缓冲区 → 非易失存储（FRAM/Flash/EEPROM）→ 过境下传。

这三条链共享同一套存储与总线资源，因此必须通过优先级、互斥和缓冲策略避免相互阻塞。例如，姿态控制任务对采集链的实时性要求最高，日志写入通常被安排在低优先级或空闲时段，但异常日志必须能够抢占写入，以保证关键证据不丢失。

数据管理与日志记录的任务边界

在实际工程中，数据管理与日志记录常被混为一谈，导致接口不清、责任不明。建议按以下边界划分：

需要强调的是，日志记录不是"打印调试信息"。星上日志必须满足可解析、可检索、可下传三个条件：每条记录应包含时间戳、事件类型、来源任务、参数快照和结果码；记录格式应在设计阶段冻结，避免因版本升级导致地面解析失败。对于资源受限的星务计算机，日志通常采用定长记录加环形覆盖策略，并预留"异常区"用于保存不可覆盖的关键事件。

一个可参考的日志记录格式示例

以下给出一个教学用的日志记录结构示例，字段可根据任务实际裁剪。假设星务计算机采用32位时间戳（单位：秒，相对星上零点），记录长度固定为32字节：

typedef struct {
    uint32_t timestamp;      // 星上时间，秒
    uint16_t event_id;       // 事件编号，如0x0101=总线超时
    uint8_t  source_task;    // 来源任务ID
    uint8_t  level;          // 0=INFO 1=WARN 2=ERROR 3=FATAL
    uint32_t param1;         // 参数快照1，如总线地址
    uint32_t param2;         // 参数快照2，如错误码
    uint8_t  reserved[16];   // 预留扩展
} log_record_t;              // 共32字节

写入时，日志服务从空闲队列取一条记录，填充字段后追加到环形缓冲区尾部；当缓冲区满时，覆盖最旧的非异常记录。地面解析时，按timestamp排序即可还原事件序列。判断日志是否完整，可检查记录中的event_id是否连续、时间戳是否单调递增、以及异常区是否有未下传记录。

综上，星务计算机的数据管理与日志记录是保障航天器长期可靠运行的基础能力。数据管理解决"状态对不对"，日志记录解决"过程清不清"。二者共享资源、互相支撑，设计时必须从架构层面明确数据流、优先级和存储策略，才能在资源受限、无人值守的星上环境中实现可追溯、可下传、可恢复的数据闭环。