3. 设备管理核心概念与数据模型

星务系统要管理星上设备，第一步不是写遥测遥控指令，而是把“设备”这件事描述清楚。设备管理的数据模型决定了后续遥测解析、指令编排、故障诊断和健康评估能否顺畅进行。本节围绕五个核心概念——设备标识、状态、模式、参数、健康度——以及支撑它们的设备字典与元数据设计方法展开。

设备标识：唯一、稳定、可追溯

设备标识是设备在星务系统中的“身份证”。它必须满足三个条件：全局唯一、长期稳定、可追溯。工程上通常采用分层标识，例如：

设备标识 = 分系统代码 + 设备类型代码 + 实例序号
示例：AOCS-GYRO-01  表示姿控分系统陀螺仪第1台
      PWR-BAT-02   表示电源分系统蓄电池组第2台

标识一旦分配，不应随设备状态、模式或参数变化而改变。若设备更换或升级，应保留原标识并附加版本或批次信息，而不是重新分配一个全新标识，否则历史遥测数据将无法关联。标识还应与遥测参数编号、指令目标地址建立映射关系，形成“标识—地址—参数”的索引链。

状态、模式与参数：三个不同层次

初学者容易把状态、模式和参数混为一谈。三者的区别在于：状态是设备当前所处的运行情形，通常是离散的、可枚举的；模式是设备被配置成的工作方式，往往由指令切换；参数是设备内部可测量或可设置的数值量，是连续或离散的具体数据。

以星上某载荷相机为例：

• 状态：关机、待机、成像、故障。状态反映“现在怎么样”。
• 模式：高分辨率模式、宽幅模式、低功耗模式。模式反映“按什么方式工作”。
• 参数：曝光时间 12 ms、增益 4、探测器温度 -20.3 ℃、工作电流 1.8 A。参数反映“具体数值是多少”。

状态和模式之间不是一一对应。同一状态下可以有多种模式，同一模式也可能出现在不同状态中。数据模型里应把状态、模式、参数分别建模，避免用参数阈值反推状态造成逻辑混乱。

健康度：从参数到可判断的结论

健康度不是原始遥测，而是对设备“是否正常、还能用多久”的综合判断。它通常由参数经过规则计算得到，输出可以是等级（正常/注意/警告/故障）或分数（0～100）。健康度模型应明确三件事：输入哪些参数、用什么规则、输出什么等级。

例如某蓄电池组健康度规则（示例参数，非实测）：

健康度计算可采用“最差项优先”策略：任一参数落入警告范围，整体健康度即为警告。这样避免多个正常参数掩盖一个危险参数。

设备字典与元数据设计方法

设备字典是设备管理的数据基础，它把上述概念结构化存储。设计时应遵循“一设备一记录、一参数一字段、一规则一表达式”的原则。元数据则描述数据本身，例如参数的单位、量程、采样周期、来源、精度、是否可写。

一个可参考的设备字典条目结构如下（示例）：

{
  "device_id": "AOCS-GYRO-01",
  "device_name": "陀螺仪A",
  "subsystem": "AOCS",
  "state": "待机",
  "mode": "正常模式",
  "params": {
    "spin_speed": {"value": 3200, "unit": "rpm", "range": [0, 6000], "writable": false},
    "temperature": {"value": 28.5, "unit": "℃", "range": [-40, 85], "writable": false}
  },
  "health": {"level": "正常", "score": 92, "rule": "max_severity"}
}

元数据设计要避免两个常见问题：一是单位不统一，例如温度有的用摄氏度、有的用开尔文，导致阈值判断错误；二是量程缺失，无法判断参数是否越界。建议在字典中强制填写单位、量程、采样周期和默认阈值。

数据模型落地时的关键检查点

把上述模型落到星务软件或数据库时，建议逐项检查：设备标识是否与遥测参数编号、指令地址建立了双向映射；状态和模式是否分开存储，避免用参数阈值反推；每个参数是否都有单位、量程、采样周期和可写标志；健康度规则是否可配置、可追溯，而不是硬编码在程序里；设备字典是否支持版本管理，设备更换后历史数据仍能关联。

总结来说，设备标识解决“是谁”，状态和模式解决“现在怎样、按什么方式工作”，参数解决“具体数值”，健康度解决“是否正常”，而设备字典与元数据把这一切组织成可查询、可计算、可追溯的数据模型。只有这五者关系清晰，星务系统的设备管理才能从“看遥测”走向“懂设备”。