4. TTC系统顶层架构视图

卫星遥测遥控（TTC）系统的顶层架构设计，不能只画一张“系统框图”就宣告完成。一个可落地的顶层架构，需要从四个互补的视角分别描述同一套系统：功能架构回答“系统要完成哪些功能、功能如何分解与交互”；物理架构回答“这些功能由哪些真实设备、单机、链路承载，装在哪里、怎么连接”；信息架构回答“遥测、遥控、测距、状态、时间等数据以什么格式、什么流向、什么速率在系统中流转”；运行架构回答“系统在发射准备、在轨正常、安全模式、故障恢复等不同阶段如何组织运行、由谁控制、按什么时序切换”。四者描述的是同一个系统的四个侧面，必须相互映射、彼此可追溯，否则设计就会出现“功能有、设备无”“设备有、数据不通”“数据通、运行没人管”的断裂。

四个视图的划分方法

划分的核心原则是“按关注点分离，按标识关联”。每个视图只回答自己那一类问题，但所有视图共享同一套标识体系，例如功能编号 FN-xx、设备编号 EQ-xx、数据流编号 DF-xx、运行模式编号 MD-xx。这样在一致性检查时，才能用编号做交叉比对，而不是靠人眼在几张图之间“找对应”。

功能架构通常采用功能分解树加功能交互矩阵。顶层功能可划分为：遥测采集与下传、遥控接收与分发、测距与测速、时间同步、链路管理、数据存储与回放、安全与告警。每个顶层功能再分解为子功能，例如“遥控接收与分发”可分解为上行信号捕获、解调译码、指令校验、指令分发、执行确认。功能之间用数据/控制接口连接，形成功能流。

物理架构采用分系统—单机—接口的层次结构。典型对象包括：星载遥测采集单元、遥控译码单元、发射机、接收机、天线、星务计算机、地面测控站、基带设备、测控中心服务器等。物理架构要标注设备安装位置（舱内/舱外）、供电关系、射频链路、总线类型（如1553B、CAN、RS-422）以及冗余配置（单机冗余、链路冗余）。

信息架构以数据流图或信息流矩阵表达。需要明确每类信息的源、宿、格式、周期/触发方式、速率、优先级。例如遥测帧周期、遥控指令码长、测距音频率、时间码格式。信息架构还要区分实时流与非实时流、上行与下行、业务数据与工程数据。

运行架构用状态机或模式—转换图表达。典型运行模式包括：发射前测试模式、入轨捕获模式、在轨正常模式、安全模式、轨道机动模式、故障恢复模式。每个模式定义进入条件、退出条件、主要活动、控制主体（星上自主/地面遥控）以及关键时序约束。

视图一致性检查的实操方法

四视图画完后，必须做一致性检查。检查不是“再看一遍”，而是按规则逐条比对。以下是一套可直接执行的检查流程，以某低轨遥感卫星TTC系统为例（参数为教学示例，非实测值）。

第一步：功能—物理覆盖检查。遍历功能架构中每个叶子功能，确认至少有一个物理设备承载它。例如功能“遥控指令校验”应映射到遥控译码单元中的校验模块；若某功能找不到承载设备，说明物理架构缺项。反之，遍历每个物理设备，确认它至少支撑一个已定义功能，避免出现“多余设备”。

第二步：信息—功能接口检查。每条数据流的两端必须对应已定义的功能端口。例如遥测帧数据流从“遥测采集”功能流向“发射机调制”功能，则信息架构中该数据流的源和宿必须能在功能架构中找到。若数据流指向一个未定义的功能，说明功能分解不完整。

第三步：运行—功能激活检查。每个运行模式必须声明它激活哪些功能、抑制哪些功能。例如“安全模式”应激活“遥测下传”和“遥控接收”，抑制“测距测速”和“大功率发射”。若某模式引用了未定义的功能，或某功能在所有模式中都未被激活，都是不一致。

第四步：物理—信息链路检查。信息架构中的每条数据流，必须能在物理架构中找到一条实际链路。例如“遥控指令分发”数据流要求从遥控译码单元经1553B总线到星务计算机，则物理架构中必须存在该总线连接和两端设备。若信息架构要求一条物理上不存在的链路，必须修改物理架构或调整信息流。

第五步：编号追溯与冲突消解。建立一张交叉引用表，行是功能编号，列是设备编号、数据流编号、模式编号，单元格填写“√”或“—”。检查每行是否至少有一个设备、每列是否至少被一个功能引用。发现冲突时，优先修改物理架构或信息架构，因为功能架构和运行架构通常由任务需求驱动，变更代价更高。

常见不一致类型与判断依据

一致性检查的最终产出，是一份视图一致性检查记录表，至少包含：检查项编号、涉及视图、涉及编号、问题描述、严重程度（高/中/低）、处理措施、责任人、关闭状态。这张表不是形式主义，而是顶层架构评审的输入。只有四视图在编号层面完全闭合，TTC系统的顶层架构才算真正“立得住”，后续的详细设计、接口定义和测试验证才有可靠基线。