1. 航天器数据体系与信息流总体设计导论

航天器是一个在极端环境下自主运行、多学科深度耦合的复杂系统。它的功能实现,本质上依赖一条条数据在星上设备、星地链路与地面系统之间准确、及时、有序地流动。如果把航天器比作一个有机体,那么结构、热控、电源、推进是它的骨骼与器官,而数据体系与信息流就是它的神经系统——它决定了各分系统能否协同、地面能否知情、任务能否闭环。本课程讨论的,正是如何从总体层面设计这套"神经系统"。

课程定位:从分系统视角上升到总体视角

在航天器工程中,各分系统工程师通常关注本领域的数据:姿控关心陀螺、星敏、动量轮的遥测与控制指令,电源关心母线电压、蓄电池充放电状态,测控关心上行遥控与下行遥测的帧结构。这些工作各有其专业深度,但容易形成"数据孤岛"。总体设计者的职责,是把这些分散的数据需求统一到一张全局蓝图上:哪些数据必须采集、以什么频率采集、经过哪些处理、走哪条链路、在地面如何还原与使用。

因此,本课程的定位是总体级的数据与信息流设计,而非某一分系统的详细协议实现。它要求学习者既能理解各分系统的数据语义,又能站在任务全局做取舍与折中。课程后续将围绕数据分类与建模、信息流架构、链路预算、协议栈、时统与同步、故障与降级设计、地面段数据流等展开,最终形成一套可落地的总体设计方法。

核心术语:先建立共同语言

在展开设计之前,必须统一几个基础术语,避免后续讨论中概念漂移。

  • 数据(Data):对航天器状态、环境或任务的量化描述,如温度值、电压值、姿态角、开关状态。数据是信息的载体,本身不一定有直接决策意义。
  • 信息(Information):经过组织、关联或解释后,对判断和决策有意义的数据集合。例如,单路温度是数据,"某设备温度持续超过阈值"才是信息。
  • 遥测(Telemetry, TM):航天器向地面下传的状态与测量数据,通常按帧组织,包含同步字、帧计数、数据域与校验。
  • 遥控(Telecommand, TC):地面向航天器上注的指令数据,包括直接指令、间接指令、数据注入与软件上注。
  • 信息流(Information Flow):数据从产生、采集、处理、传输到消费的完整路径,包含方向、速率、时序与协议约束。
  • 数据体系(Data Architecture):对航天器全生命周期数据的分类、模型、接口、存储与治理规则的总体描述。

需要特别说明的是,遥测与遥控的方向约定:本文及后续图示中,上行指地面到航天器,下行指航天器到地面。这一约定在链路预算、频段选择和时延分析中必须保持一致。

设计边界:总体设计管什么、不管什么

明确边界是总体设计避免越界与遗漏的关键。数据体系与信息流总体设计通常负责以下内容:

  • 定义全器数据分类框架与命名规则,明确各类数据的采集、传输与存储要求;
  • 确定信息流总体架构,包括星上总线拓扑、星地链路划分、地面段数据流走向;
  • 分配数据速率、时延、误码率、优先级等总体指标到各分系统与链路;
  • 规定时统、同步、帧格式、协议栈的总体约束与接口标准;
  • 设计故障降级、数据保全与重构策略,确保关键信息在异常下仍可获取。

而以下内容通常不属于总体设计的直接职责,而是由分系统或专项团队完成:具体传感器的选型与电路设计、单机内部软件的数据结构、地面应用软件的界面与算法实现。总体设计给出的是接口、指标与约束,而非具体实现。

判断一项工作是否属于总体范畴,可以用一个简单标准:它是否影响两个以上分系统之间的数据交互,或是否影响全器级的数据完整性、实时性与安全性。若是,则应由总体统一协调。

总体设计在航天器工程中的位置

航天器工程通常按"任务分析—总体设计—分系统设计—单机研制—集成测试—发射运行"推进。数据体系与信息流总体设计处于总体设计阶段,与构型、轨道、能源、热控等总体专业并行,并向分系统设计输出接口数据单(ICD)与信息流要求。它上承任务需求(要传什么、多久传一次、地面怎么用),下启分系统实现(怎么采、怎么编帧、怎么发)。

下面的图给出了数据体系与信息流总体设计在工程链条中的位置,以及它与任务需求、分系统、地面段之间的输入输出关系。

数据体系与信息流总体设计在航天器工程中的位置 任务需求 观测/通信/科学目标 总体设计 轨道/构型/能源/热控/数据 分系统设计 姿控/电源/测控/载荷 数据体系与信息流总体设计 数据分类与建模 · 信息流架构 速率/时延/误码指标分配 时统与协议约束 · 降级策略 星上数据流 采集→总线→处理→存储 →下行发射 星地链路 上行遥控 / 下行遥测 测控站 · 中继 · 数传 地面段数据流 接收→解帧→处理→分发 →任务应用 约束与依据 任务剖面 · 可见性窗口 频段与功率 · 存储容量 安全与保密要求 输出成果 信息流图 · 接口数据单 数据字典 · 指标分配表 协议与时统规范

典型任务剖面:信息流随任务阶段变化

信息流设计不能只看静态结构,还要看它在任务剖面中的动态表现。以一颗低轨遥感卫星为例,一个典型轨道周期内的信息流大致经历以下阶段:

  1. 测控弧段:进入地面站可见范围后,建立上行遥控链路,注入指令与数据;同时下行遥测,地面确认星上状态。此阶段信息流以低速、高可靠为特征。
  2. 载荷工作弧段:卫星飞越目标区域,载荷开机采集图像或科学数据,数据先写入星上大容量存储器。此阶段信息流以高速采集与存储为主,下行链路可能关闭或低速维持。
  3. 数传弧段:进入数传站或中继卫星可见范围后,将存储的载荷数据高速下传。此阶段信息流以高码率、大容量为特征,对误码率与数据完整性要求高。
  4. 安全模式或异常阶段:当星上检测到故障时,信息流自动降级,优先保障关键遥测与安全指令通道,非关键数据暂停或丢弃。

可以看到,同一颗卫星在不同阶段的信息流方向、速率、优先级完全不同。总体设计必须为这些阶段分别定义数据流方案,并保证阶段切换时的数据不丢失、状态可追溯。例如,在示例设计中,某低轨遥感卫星的测控弧段遥测码率可设为 4 kbps,数传弧段载荷数据码率可设为 300 Mbps,两者通过不同的物理链路与协议栈实现,互不干扰。这些数值属于教学示例,实际任务需根据轨道、载荷与地面站条件重新计算。

任务剖面分析中容易忽略的一点是"阶段切换点":从载荷工作切换到数传,涉及存储器读写指针切换、链路建立与同步、地面站引导等一系列动作。总体设计应明确切换的触发条件、时序余量与异常回退策略,否则容易出现数据断点或重复下传。

本课程的学习路径