企业官网建设流程全解析

工厂车间里那些老设备，很多连个像样的数据接口都没有，但老板又天天盯着大屏要看OEE、要看良率、要看哪台机器在偷懒。这个项目就是解决这个矛盾的——把车间里五花八门的设备数据抓上来，做成能看的图表，出问题了自动喊人。我做过好几个类似的产线数字化改造，从注塑机到CNC再到装配线，踩过的坑比写过的代码还多。下面把这些经验完整拆开讲，从数据怎么采、采什么、怎么存、怎么展示、告警怎么配才不烦人，一条线捋清楚。

1. 先搞清楚采什么：工厂设备数据的分类与采集边界

1.1 设备数据到底分几层

很多人一上来就问"用什么协议采"，这其实问反了。应该先问"采什么"。工厂设备的数据粗略分三层：

• 状态层：运行、停机、待机、故障、换模。这层数据量最小但价值最高，直接决定OEE计算。
• 过程层：温度、压力、速度、扭矩、电流、计数。这层是工艺监控的核心，采样频率通常1秒到1分钟一次。
• 事件层：报警代码、配方切换、参数修改、操作员登录。这层是追溯和质量分析的关键。

我见过太多项目只采了过程层，结果老板问"这台机昨天停了多久"答不上来。状态层和事件层必须一起采，否则后面做可视化就是花架子。

1.2 不同年代设备的采集方式差异

车间里的设备年龄跨度可能超过20年，采集方式完全不同：

提示：老设备加装传感器时，电流互感器判断运行状态是最稳妥的方案。设备主电机电流超过阈值就认为在运行，低于阈值认为停机，准确率能到95%以上，成本只要几十块钱。

1.3 采集频率怎么定才不浪费

采集频率不是越高越好。我见过一个项目把注塑机温度按100ms采集，一天产生几千万条数据，数据库直接扛不住。合理的做法是：

• 状态变化：事件触发，一变就上报，不变化不占带宽。
• 过程参数：按工艺节拍，比如注塑周期30秒，那就每5秒采一次，一个周期6个点足够画曲线。
• 计数类：累计值定时上报，比如每10秒上报一次累计产量，而不是每次+1都上报。

这样设计下来，一台设备一天的数据量从几千万条降到几万条，存储成本降两个数量级。

2. 数据采集网关的选型与现场部署实战

2.1 网关选型的三个硬指标

网关是采集方案的核心硬件，选型看三个指标：

1. 协议覆盖：至少要支持Modbus RTU/TCP、OPC UA、MQTT。如果车间有西门子PLC，还要支持S7协议；有三菱的，要支持MC协议。
2. 边缘计算能力：能不能在网关上做数据预处理。比如把原始寄存器值换算成工程量、做死区过滤、做本地缓存。没有边缘计算能力的网关，所有数据原样上传，云端压力巨大。
3. 断网续传：车间网络抖动是常态，网关必须能本地存至少24小时数据，网络恢复后自动补传。这个功能看着不起眼，实际项目里能救命。

2.2 现场部署的布线经验

网关部署位置很讲究。我的经验是：

• 网关尽量靠近设备，减少串口线长度。RS485线超过50米信号就开始衰减，超过100米基本不可靠。
• 一个网关带设备数量控制在8-16台。带太多轮询周期会拉长，实时性下降。
• 网关供电单独走一路，不要和设备主电源共用。设备启停时的电压波动会干扰网关。
• 网线走线槽，远离变频器和伺服驱动器。电磁干扰是数据丢包的隐形杀手。

2.3 一个真实的踩坑案例

有个项目，网关装好后数据时有时无。排查了两天，最后发现是网关和一台变频器共用了同一个配电箱，变频器工作时网关就重启。换了个独立电源后问题消失。这种坑在实验室永远遇不到，只有到了现场才会碰到。

注意：现场调试时，先用万用表量一下网关供电电压的波动范围。如果波动超过±10%，必须加稳压模块。

3. 数据上云后的存储与处理架构

3.1 时序数据库是必选项

工厂设备数据是典型的时序数据，用MySQL存是自找麻烦。时序数据库选型：

• TDengine：国产，性能好，SQL语法友好，适合中小规模项目。
• InfluxDB：生态成熟，文档丰富，但集群版收费。
• TimescaleDB：基于PostgreSQL，适合已经用PG的团队。

我一般推荐TDengine，一张超级表按设备ID建子表，写入和查询都很顺畅。一个中等规模工厂（200台设备）用单节点就能扛住。

3.2 数据清洗不能省

原始数据直接存库是大忌。必须做几件事：

• 死区过滤：温度变化小于0.5度不上报，避免大量重复值。
• 异常值剔除：传感器偶尔会报出明显不合理的值（比如温度突然9999），要过滤掉。
• 时间戳对齐：不同设备的时间可能不一致，统一用网关时间戳。
• 单位统一：有的设备报华氏度，有的报摄氏度，入库前统一。

这些处理放在网关边缘做最好，减轻云端压力。

3.3 数据分层存储策略

热数据（最近7天）存时序库，支持实时查询和可视化。温数据（7天到1年）做降采样后存时序库，比如原始1分钟一个点，降采样成5分钟一个点。冷数据（1年以上）归档到对象存储，需要时再恢复。

这样设计，存储成本能降低70%以上，而查询性能几乎不受影响。

4. 可视化大屏的设计逻辑与实现

4.1 大屏不是图表堆砌

很多可视化大屏做出来就是一堆图表的拼盘，看着热闹但没用。好的工厂大屏应该回答三个问题：

1. 现在怎么样：当前产量、良率、设备运行率，用大数字展示。
2. 哪里有问题：异常设备用红色高亮，按严重程度排序。
3. 趋势如何：最近24小时产量趋势、故障趋势，用折线图。

我通常把大屏分三个区域：顶部是核心KPI，中间是设备状态矩阵，底部是趋势图和告警列表。

4.2 技术选型：ECharts + WebSocket

前端可视化用ECharts，这个没什么争议。关键是数据刷新方式：

• 不要用定时轮询，用WebSocket推送。轮询在设备多的时候会把后端压垮。
• 后端用MQTT订阅设备数据，处理后再通过WebSocket推给前端。
• 前端收到数据后只更新变化的部分，不要整个图表重绘。

4.3 设备状态矩阵的实现细节

设备状态矩阵是大屏的核心。每台设备一个方块，颜色表示状态：绿色运行、黄色待机、红色故障、灰色离线。

实现要点：

• 方块数量多时（超过100个），用Canvas渲染而不是DOM，性能差好几倍。
• 点击方块弹出该设备的详细面板，显示实时参数和历史曲线。
• 状态变化时加一个闪烁动画，让操作员一眼看到。

// 设备状态矩阵核心逻辑示意 const statusColors = { running: '#52c41a', idle: '#faad14', fault: '#f5222d', offline: '#d9d9d9' }; function renderDeviceMatrix(devices) { devices.forEach(device => { const color = statusColors[device.status] || statusColors.offline; updateBlock(device.id, color, device.status); }); }

4.4 实时曲线图的性能优化

实时曲线是可视化里最吃性能的部分。我的经验：

• 数据点超过500个后，人眼已经分辨不出细节，所以只保留最近500个点。
• 用ECharts的appendData方法增量添加数据，不要每次重新setOption。
• 多条曲线时，用large: true开启大数据量优化模式。

5. 告警系统的设计与降噪策略

5.1 告警分级是降噪的第一步

告警不降噪，操作员三天就麻木了。分级是基础：

5.2 告警降噪的四个实用手段

1. 告警抑制：同一设备同一告警，5分钟内只发一次。
2. 告警聚合：同一设备多个告警合并成一条消息发送。
3. 告警依赖：设备离线时，抑制该设备的所有其他告警。设备都离线了，还报温度超限没意义。
4. 动态阈值：不同产品、不同工艺阶段的阈值不同，不能一刀切。

5.3 告警通道的可靠性设计

告警发不出去等于没有告警。我的做法是：

• 主通道用企业微信机器人，配置简单，到达率高。
• 备用通道用短信，只在P0级别启用。
• 告警发送失败要记录并重试，重试3次仍失败则升级通知方式。

# 告警发送与重试逻辑示意 def send_alert(alert, channels=['wecom', 'sms']): for channel in channels: for attempt in range(3): try: result = dispatch(channel, alert) if result.success: log_alert_sent(alert, channel) return True except Exception as e: log_alert_failed(alert, channel, attempt, e) time.sleep(2 ** attempt) # 指数退避 escalate_alert(alert) # 所有通道失败，升级处理 return False

5.4 告警闭环：从发出到关闭

告警不能只发不管。必须形成闭环：

• 告警发出后，操作员在企微里点击"认领"，表示已看到。
• 处理完成后点击"关闭"，并填写处理措施。
• 超时未认领的告警自动升级，通知上级。
• 所有告警记录存档，用于后续分析和改进。

这套闭环机制能让告警真正发挥作用，而不是变成"狼来了"。

6. 系统集成与调度任务的编排

6.1 为什么需要调度系统

数据采集是实时的，但很多任务是定时的：日报表生成、数据降采样、告警统计、设备OEE计算。这些任务需要一个调度系统来管理。

DolphinScheduler是个不错的选择，可视化编排，支持依赖关系，失败自动重试。配置一个任务失败时通过企微告警，运维人员能第一时间知道。

6.2 任务编排的实践经验

• 任务粒度：一个任务只做一件事。比如"计算昨日OEE"是一个任务，"生成日报"是另一个任务。
• 依赖关系：日报生成依赖OEE计算完成，用DolphinScheduler的依赖节点控制。
• 失败重试：网络抖动导致的任务失败，配置自动重试3次，间隔30秒。
• 超时设置：每个任务设置超时时间，避免卡死。

6.3 与MES/ERP的数据对接

工厂里通常已经有MES或ERP系统。物联网平台的数据要能对接过去：

• 工单信息：从MES获取当前工单号、产品型号、计划数量。
• 产量回传：把采集到的实际产量回传给MES。
• 质量数据：把关键工艺参数回传给MES，用于质量追溯。

对接方式优先用API，实在不行用中间数据库表。API要处理好认证和限流。

7. 项目落地中的常见问题与应对

7.1 网络不稳定怎么办

车间网络环境复杂，无线信号容易被金属设备遮挡。应对策略：

• 优先用有线网络，无线只作为备用。
• 无线AP部署时做信号覆盖测试，确保每个角落信号强度大于-65dBm。
• 网关配置断网续传，网络恢复后自动补数据。
• 关键数据在网关本地也存一份，防止云端故障。

7.2 设备协议不开放怎么办

有些设备厂商不提供协议文档，或者要收高额授权费。应对方法：

• 先用抓包工具分析设备与上位机的通信，逆向出协议。
• 如果设备有上位机软件，可以从上位机软件的数据库或日志里取数据。
• 实在不行，加装传感器间接采集。比如用光电传感器数产量，用电流互感器判断运行状态。

7.3 数据准确性怎么保证

采集的数据不准，后面全白搭。保证准确性的措施：

• 定期用标准仪器校准传感器。
• 关键数据做交叉验证。比如产量数据，既从设备计数器取，也从光电传感器取，两者对比。
• 建立数据质量监控，发现异常数据自动告警。
• 保留原始数据，便于追溯和修正。

7.4 操作员不接受怎么办

系统做得再好，操作员不用就是废的。推广经验：

• 界面要简单，操作员只需要看和点，不需要输入。
• 告警要准确，不要频繁误报，否则操作员会直接忽略。
• 让操作员参与需求调研，他们提的意见往往最实用。
• 上线初期安排专人跟进，及时解决问题，建立信任。

8. 从单点试点到全厂推广的路径

8.1 先做样板线

不要一上来就全厂铺开。选一条有代表性的产线做试点，跑通全流程，验证方案可行性。试点线要包含不同类型的设备，这样能暴露各种问题。

试点周期一般1-2个月，包括部署、调试、试运行、优化。

8.2 标准化复制

试点成功后，把方案标准化：

• 网关配置模板化，新设备接入时改几个参数就行。
• 数据模型统一，所有设备用同一套数据模型。
• 可视化模板复用，新产线大屏基于模板快速生成。
• 告警规则库积累，常见告警规则直接复用。

8.3 持续优化

系统上线不是终点。要持续收集反馈，优化告警规则，增加新的分析维度。我一般建议每季度做一次系统回顾，看看哪些告警误报多、哪些数据没人看、哪些功能可以砍掉。

工厂设备数据采集这套东西，技术本身不复杂，难的是现场的各种意外和对业务的理解。我做了这么多年，最大的体会是：不要追求技术上的完美，要追求业务上的有用。一个能稳定运行、操作员愿意用的简单系统，比一个功能强大但天天出问题的复杂系统有价值得多。采集频率够用就行，可视化能看懂就行，告警准确就行。把这三件事做好，项目就成功了八成。