一个工业大屏如果只能显示几张静态报表，它更像数据展板；真正的设备监控系统，需要让业务模型和实时数据共同驱动画面。

一、先说结论：模型决定画什么，实时数据决定现在是什么状态

实时设备监控大屏可以拆成两部分：

• 业务模型：设备模型、点位模型、模型文件和页面组件，描述系统里有什么设备、有哪些点位、应该如何展示。
• 实时数据：点位实时值、设备状态、告警事件，通过 WebSocket 或服务端通知推送到前端。

如果只有模型没有实时数据，页面只是静态展示；如果只有实时数据没有业务模型，前端就不知道数据应该绑定到哪台设备、哪个点位和哪个视觉元素。

二、监控大屏首先要解决“看谁”

很多大屏一上来就设计颜色、动画和 3D 效果，但没有先建立设备和点位模型。结果是：

• 页面写死设备名称
• 点位编码散落在 JavaScript 中
• 新增设备需要复制页面
• 同一设备在不同页面重复配置
• 模型状态和数据状态无法统一

更合理的做法是先建立业务模型。

设备模型

记录设备的基本信息和展示关系：

• 设备编号
• 设备名称
• 设备类型
• 所属工厂
• 所属车间
• 设备状态
• 3D 模型文件
• 位置和布局信息

点位模型

记录设备可以被采集和展示的测点：

• 点位编码
• 点位名称
• 数据类型
• 单位
• 展示方式
• 关联报警规则
• 是否进入实时看板
• 是否允许控制

模型表解决的是“数据和对象如何关联”。

三、实时数据应该通过推送到达前端

如果前端每隔几秒向服务端轮询一次，设备数量少时还能工作，设备和用户一多就容易出现：

• 请求数量过多
• 数据刷新不及时
• 多个页面重复查询
• 网络开销增加
• 设备断线状态不容易判断

实时监控更适合采用 WebSocket 或服务端通知：

1. 页面打开时建立订阅。
2. 服务端接收边缘侧的新数据。
3. 服务端根据设备和点位关系推送变化。
4. 前端只更新发生变化的组件。
5. 页面关闭时释放订阅。

实时数据消息可以保持简洁：

四、实时大屏应该展示哪些信息

一个可用的设备监控大屏，至少应该让用户快速看到四类信息：

设备状态

运行、停止、待机、故障、离线等状态，建议使用稳定的颜色和图标表达，不要只依赖闪烁动画。

关键点位

温度、压力、速度、液位、电流、功率等关键值，显示当前值和单位。

告警信息

需要区分报警等级、发生时间、持续时间、确认状态和恢复状态。

趋势变化

当前值只能说明“现在”，趋势曲线才能帮助判断设备是在升温、降温、波动还是逐渐恶化。

五、3D SCADA 不是为了炫技

3D 设备模型的价值不在于做得多漂亮，而在于降低理解成本。

对于锅炉、伺服电机、产线设备等对象，业务人员可以直接通过模型看到：

• 哪台设备处于运行状态
• 哪个设备正在报警
• 哪个部件数值异常
• 数据和现场位置的对应关系

但 3D 不是所有场景的默认选择。如果设备数量非常多、点位非常密集，二维拓扑或表格可能更适合快速扫描；如果需要展示设备结构和空间关系，3D 模型才更有价值。

选择展示形式时，要从用户任务出发，而不是从技术效果出发。

六、React 组件如何绑定设备数据

可以把 3D 设备大屏拆成三层组件：

场景层

负责加载模型文件、设置摄像机、灯光、视角和场景布局。

设备层

负责根据 device_id 找到对应设备模型，并处理设备级状态，例如运行、停止、离线和故障。

点位层

负责将 point_code 绑定到模型上的标签、仪表、颜色、动画或数值显示。

这种拆法可以避免所有逻辑集中在一个页面文件里，也便于未来增加新的设备类型。

七、数据刷新要注意三个问题

不要每条消息都重绘整个场景

设备模型通常很重，实时更新时应该只改变状态、文本或材质，不要每次收到点位消息都重新加载模型。

处理消息乱序

网络传输可能导致消息到达顺序和采集顺序不同。前端或服务端应根据 timestamp 判断是否接受旧数据。

处理离线状态

没有新数据不等于设备正常。应该根据最后一次有效上报时间设置数据过期策略，并将设备标记为离线或数据过期。

八、告警和状态不要混为一谈

设备状态是持续状态，告警是事件。

例如：

• 设备状态：运行
• 当前温度：85℃
• 告警事件：温度超过上限，持续 30 秒
• 告警状态：待确认

如果把它们都简化成一个红色图标，用户就无法知道问题发生了多久、是否已经确认、是否已经恢复。

建议在数据模型上分开：

• device_status：当前设备状态
• point_value：当前点位值
• alarm_event：告警事件
• alarm_state：告警生命周期状态

九、平台能力决定大屏能否长期维护

实时大屏只是前端的一部分，真正支撑它长期运行的还有平台底座：

• 服务端命令处理复杂业务逻辑
• 计划任务完成周期调度
• WebSocket 或服务端通知推送数据
• WebAPI 对外提供统一接口
• 权限控制不同用户能看到的设备范围
• 日志审计记录配置和控制操作
• 多终端布局适配 PC、平板和 PDA
• 插件接口扩展非标准数据源

如果平台只具备“画页面”的能力，却没有权限、审计、运维和集成能力，大屏上线后很快会变成一个难以维护的孤岛。

十、一个建议的落地顺序

不要一开始就做完整 3D 工厂大屏，可以按下面的顺序迭代：

1. 建立设备台账和设备模型。
2. 建立点位模型和统一数据结构。
3. 完成实时值查询和历史趋势查询。
4. 加入设备状态和离线判断。
5. 加入告警事件、确认和恢复。
6. 用二维页面验证业务流程。
7. 对关键设备增加 3D 模型和实时绑定。
8. 最后再做跨设备、跨车间的综合看板。

这样可以先验证数据和业务，再逐步增加可视化效果，避免把大量时间花在画面上，却没有解决现场真正关心的问题。

十一、总结

工业监控大屏的核心不是“实时”或“3D”这两个词，而是让用户能快速回答三个问题：

1. 现在有哪些设备？
2. 哪些设备正在异常？
3. 异常发生后应该采取什么动作？

业务模型让数据有归属，实时推送让画面保持新鲜，告警事件让异常可以追踪，平台底座让系统能够长期运行。

当设备模型、点位模型和实时数据真正连接起来时，监控大屏才不再只是展示页面，而是设备管理和生产运营的一部分。