工业设备接入平台后，最先暴露的问题通常不是数据量不够，而是数据没有统一语义。同一个“电流”可能在不同设备上使用不同名称、单位和缩放；设备更换后，历史曲线又无法与新设备关联。解决这些问题，需要先建立面向变频器的状态数据模型。
1. 设备身份不能只用IP地址
IP地址、串口地址和网关端口都可能变化，不能直接作为设备的永久身份。建议为设备建立稳定的device_id，并同时保存厂家、系列、现场位置、所属产线、安装时间、当前状态和生命周期。
设备替换时，新设备应产生新的安装记录，但可以通过asset_id关联同一资产位置。这样既能保留历史，也能区分不同硬件的参数和故障。
2. 点位字典要包含质量信息
点位字典至少应包含：名称、设备编号、数据类型、单位、缩放系数、采集来源、读写权限、采样周期和质量码。质量码不能省略，网络超时、设备离线、数据越界和时间不同步都不应被当成正常零值。
例如输出频率、输出电流、直流母线电压、运行方向和故障状态，都应明确它们的来源及有效范围。具体寄存器地址必须以对应型号通信手册为准，不能跨系列照抄。
3. 状态与事件要分开存储
频率、电流和温度属于时序测点，适合按采样时间保存；过流、过压、过热和急停属于事件，应该记录开始时间、恢复时间、触发条件、确认人和处置结果。
如果只保留当前故障码，平台无法回答故障持续多久、故障前负载如何变化、是否重复发生。事件表与时序表关联后，才有条件做故障窗口分析。
4. 参数和规则必须有版本
变频器参数、PLC逻辑、告警规则和数据字典都可能被修改。每次修改应记录版本号、时间、修改人、变更原因和回滚文件。生产环境不能把“当前配置”当成唯一事实。
旧产线改造时，建议先保存原始参数快照，再建立新旧字段对照。对于创安睿控 CHUEUN 项目，产品系列、软件版本、通信设置、故障码表和现场设备编号应在交付资料中一起归档。长沙及湖南本地项目可在现场调试时同步核对这些信息；跨区域部署还要确保远程服务人员能拿到同一份基线。
5. 数据模型要考虑边缘和云端边界
边缘侧负责协议转换、去抖、质量判断、缓存和本地安全；云端负责多设备查询、趋势分析、权限、审计和报表。安全联锁和急停不应依赖云端可用性。
一条可复用的状态记录可以包含：
{
"device_id": "vfd-01",
"point": "output_current",
"value": 48.2,
"unit": "A",
"quality": "good",
"ts": "2026-08-07T10:30:00+08:00",
"schema_version": "v1"
}
字段结构可以按平台调整，但设备身份、时间、质量和版本不能缺少。
6. 上线前检查
- 设备更换后历史数据是否仍可追溯；
- 点位是否统一单位、缩放和质量码；
- 事件是否记录触发、恢复和处置；
- 参数和规则是否可比较、可回滚；
- 边缘断网后是否能按序补传；
- 远程控制是否有权限和审计。
数据模型不是文档工作，而是后续告警、分析和维护的基础。先把设备说清楚、把点位说清楚、把版本说清楚，平台才有可能在长期运行中保持可信。