企业官网建设流程全解析

开头

搞设备管理的朋友应该都有过这种体验：现场几十台设备，台账在Excel里，点检靠纸质表，故障信息一半在微信群里，一半在老师傅脑子里。想判断一台机器状态好不好，得靠听声音、摸温度、看仪表——经验稍微不够，问题往往要等停机了才暴露出来。

“openrig”这个名字是我自己起的项目代号，核心就一句话：用一套开源的、可私有化部署的设备数据采集与运维平台，把散落在各个设备上的状态数据统一管起来。它能覆盖设备台账、实时工况、异常告警、维修记录这几个环节，解决“设备状态不可见、故障发现太晚、数据全在孤岛里”的问题。文章里我尽量按照实际落地时的顺序来写——从方案怎么想到的、硬件怎么选，到数据怎么采、表怎么建、告警怎么配，再到我踩过的坑和排查思路。无论你是做设备维护的工程师、带产线的管理者，还是想给自家工厂搭一套轻量物联网平台的开发者，都可以参考这套思路。

1. 项目整体设计与思路拆解

1.1 “openrig”到底要解决什么问题

我在工厂里待了几年之后，对设备管理最深的感受是：大部分企业根本不缺数据，缺的是把数据整理成决策依据的手段。

一台设备哪怕是最普通的电机、泵、空压机，中控屏或者PLC里也会记录电流、温度、压力、运行时长等信息。但这些数据要么只在本地显示一下就没了，要么存在专用软件里，导出一次费半天劲。结果就是：

• 设备状态靠人工巡检，白班夜班各走一趟，中间出了异常根本不知道；
• 故障发生之后才去翻工控机里的历史曲线，分析要花大量时间；
• 各种设备的参数格式不一样，整理出来的数据没法横向对比；
• 备件采购、维修派单、保养计划各走各的流程，出了问题互相扯皮。

所以这个项目从一开始就不是奔着“做一个高大上的工业互联网平台”去的，我目标很务实：先把设备的数据接到一个统一的系统里，实现看得见、存得住、能报警，再把报警和维修流程串起来。openrig这个名字，一个意思是“开放”的架构，所有的采集协议、数据库表、告警规则都可以自己改；另一个意思是“把机器整套装置运转起来”，不是单点监测某一台设备，而是把车间里的设备当成一个整体来看。

1.2 为什么自己搭而不是直接买商业平台

立项之前我也看过市面上的设备管理系统，好用的确实有，但普遍存在几个让我犹豫的地方。

第一是收费模式。很多商用平台按照设备点数、用户数、数据存储量来收费，一个车间几十个监控点，一年下来费用不小，还没有算升级和后期维护。厂房里的设备是持续增加的，盒子买了一圈，平台却当成年费来收，这个模式不适合中小规模场景。

第二是数据封闭。设备数据的价值远不止看实时曲线，后续要做能耗分析、做预测性维护、做产品质量追溯，数据需要能和MES、ERP系统打通。商业平台的数据结构往往是黑盒，想自由做二次开发，API权限又给得很抠。

第三是扩展不自由。不同的项目现场，设备品牌、通讯协议、控制逻辑千差万别。商业平台支持标准协议，但碰到老旧设备或者特殊协议的传感器，定制开发成本非常高，响应周期以月为单位。而开源方案可以直接改底层逻辑，自己动手就行。

所以openrig的路线确定为：优先采用各种开源组件，自己设计数据模型和业务流程，把平台部署在自己的服务器上。数据主权在自己手里，每个传感器怎么接可以自己控制，项目中后期完全可以无限制地往任意方向扩展。

1.3 整体架构与核心选型思路

openrig的架构我大致分成四层：

• 感知层：负责把设备工况变成数字信号。包括已经有数据输出的PLC、智能仪表，也包括后加的温振传感器、电流互感器、压力变送器。
• 传输层：负责把数据从现场送到服务器。通常现场部署一台边缘采集网关，通过串口、以太网、4G等方式把设备数据读出来，再用MQTT协议上传。
• 平台层：负责数据接收、存储、处理、告警。这是系统的核心，包括消息中间件、时序数据库、规则引擎。
• 应用层：负责把数据展示给不同角色的人。包括状态看板、设备台账、告警记录、维修工单等。

选型方面我后面会详细讲，这里先给个大概：消息中间件用的是EMQX，时序数据库用了TDengine，可视化面板用Grafana，规则的流转我写了一套轻量级的Java应用来处理。这套组合不是最炫的，但胜在资源占用小、环节相对少、好调整。等整套跑通了，再考虑把AI预测算法加进去。

2. 核心细节解析与实操要点

2.1 数据采集方式的对比与选择

不同年代、不同厂商的设备，能拿到的数据量完全不一样。我按现场经验总结了一套选择逻辑：

最理想的当然是读PLC里的数据，不额外破坏设备本体。但很多老旧设备根本没有通讯接口，或者接口定义早就没人知道了。这种情况下就不要折腾设备本体了，采用外挂传感器的方案：在电机轴承座上贴温振一体传感器，在配电柜里加电流互感器，在管路上加压力变送器。这样虽然多花一点硬件钱，但不动设备原始逻辑，对生产安全更稳妥。

我在现场见过很多人非要厂商提供通讯协议，结果两个月都没动静，项目进度全卡在这一步。我的建议是：搞清楚你到底是需要“设备内部逻辑数据”，还是只需要“设备运行状态数据”。如果是后者，外挂传感器的成本更低、周期更短。

2.2 Modbus采集的一个关键细节：量程换算

Modbus是工业现场最常用的通讯协议，几乎90%的仪表和部分PLC都支持。但真正开始读数据时，很多人会发觉一个问题：寄存器里读出来的值，乱七八糟的，和数据手册对不上。

举例，一个压力变送器的量程是0到1.6MPa，输出4到20mA，经过PLC的模拟量模块或采集网关之后，读到Modbus寄存器里的原始值可能是0到4000。这时候显示的是归一化数值，不是真实压力值。需要换算：

真实值 = 量程下限 + (原始值 / 量程上限) × (量程上限 - 量程下限)

比如读到原始值2000，真实压力 = 0 + (2000/4000) × (1.6-0) = 0.8MPa。就这么一步。听起来很简单，但我见过太多初学的人直接把原始值存进数据库，做出的报表没法看，还以为是传感器坏了。

这个换算到底放在哪儿做？我的经验是放在边缘网关或者采集程序里做，而不是等数据到了平台再算。一来网关算完之后直接上报物理量，后续看板、告警、分析都省事；二来每台设备的量程和零点可以独立配置，数据进到平台时已经是一致的标准格式了。

还有一个高频问题：数据的字节顺序。比如一个16位整数寄存器，传输时可能是高字节在前，也可能是低字节在前，读出来经常差得离谱。所以调试的时候一定先用Modbus调试工具挨个确认寄存器类型（保持寄存器/输入寄存器）、数据类型（16位无符号/32位浮点），再写正式采集代码。

2.3 数据模型设计：时间戳、质量戳和设备编码

如果只是一两台设备，数据表随便建都行。一旦设备上到几十台，数据模型没设计好，写SQL的时候会很痛苦。

我设计的核心指标表大致有这些字段：

关键点是统一device_id的编码规则。因为前端设备五花八门，有的叫“1号泵”，有的叫“P-101”，有的名字是拼音缩写，对账的时候会让人崩溃。统一规则建议按工程标准来，比如：区域码-设备类型-序号，例如MTR-PUMP-001表示机修车间第一号泵。这个规则越早定越好，后期设备多了改起来非常麻烦。

时间戳也要注意，设备本地时间与服务器时间要保持一致，否则排序和计算容易错乱。这个问题在第四章我详细说。

2.4 告警不只是“超过就响”

告警是openrig里最影响使用者体验的功能。配置不好，要么天天误报变成狼来了，要么漏报导致错过处理时机。

我常用的几个原则：

持续时间判定。一个值瞬时超过阈值，很多时候只是闪变；持续超阈值比如超过10秒，才说明真的异常。规则引擎里都要配置超限持续时间，这在降低误报率上非常有效。

死区设置。比如液位设定高限90%，当超过92%触发报警之后，要等降到88%才能消除，避免在临界点反复抖动，导致告警不断产生和恢复。死区的幅度一般是设定限值的2%左右，具体要看现场工况波动情况。

分组与升级。一般告警分三级：注意（黄色）、警告（橙色）、严重（红色）。不同级别通知不同的人。比较严重的情况还可以升级，比如告警持续15分钟未确认，从值班人员升级到设备主管。我记得有次车间设备告警了十来分钟无人处理，后来升级机制把电话打到负责人那里，事情才被重视。告警可以只在系统内部弹窗，也可以接企业微信、钉钉、邮件，推送的具体形式不关键，关键是有人看到并且处理闭环。

3. 实操过程与核心环节实现

3.1 先搭一套最小可用系统：硬件清单

如果从零开始，别想着一步到位把全厂设备都接入。我建议先选一条产线或者一个区域，搭一套最小系统跑起来，验证稳定之后再复制推广。

我以一个典型场景为例：一台循环水泵，外加一个电机的轴承温度。要做的事情就是把这几个信号采上来、传到平台、显示在看板、设置告警。需要的硬件：

这套硬件的总成本控制在几千块以内，适合用来验证整个流程。后续设备增加，只需要增购传感器和扩大网关接入点数就行。

3.2 采集侧配置实例：从串口到MQTT

传感器变送器输出4-20mA信号，接到网关的模拟量输入口，网关内部把电流信号线性映射成对应的物理量。接着在网关上配置数据采集任务，设置轮询周期，也就是多少秒去读一次传感器数据。轮询周期值得认真讲一下——不是越短越好。

比如温度信号本身变化很慢，1秒读一次和10秒读一次差别不大，过高的采样频率会增加网关和数据库的压力。我的经验值是：温度/液位10到30秒一次，电流/压力3到5秒一次，振动信号如果要分析频谱那得单独考虑高速采集。先把数据采集频率定清楚，才能控制后续的存储量和成本。

网关把读到的物理量整理成JSON格式，通过MQTT协议发往平台。MQTT报文的大致结构是这样：

{ "device_id": "MTR-PUMP-001", "ts": "2024-06-01 10:30:00", "metrics": { "bearing_temp_c": 65.2, "motor_current_a": 12.35 } }

PAYLOAD尽量轻量，字段名称不要随意改，平台解析时用统一的规则。这个环节我建议在网关上加上本地缓存，万一网络断开，数据先存本地，恢复之后补传，避免关键数据的丢失。

3.3 平台侧的数据流：接收、解析、入库

平台侧我用EMQX作为MQTT消息中间件，设备数据进来之后，由后端服务订阅消息，解析验证之后再写入时序数据库。这里后端服务我选的是Java的Spring Boot应用，主要做几件事：

1. 接收MQTT消息，校验device_id是否存在；
2. 解析metrics，按照设备配置的量程换算，得到标准的物理量；
3. 打上质量戳，标记解析成功还是数据可疑；
4. 写入数据库，同时触发规则引擎进行告警判断。

这个地方最容易踩的坑是并发量上来之后消息堆积。如果设备数量多、消息频率高，后端的解析速度要跟得上。最开始为了简单，我是单线程消费MQTT消息，设备一多就出现延迟。后来改成多线程消费，并且将写入数据库的操作批量处理，大幅提升了吞吐量。这里建议后端应用加上消息队列，削峰填谷，即使后端暂时故障，数据也不会直接丢。

3.4 可视化看板：Grafana配置思路

数据进库之后，展示是让领导、操作工人都愿意用起来的关键一步。很多人花了很多时间做数据大屏，我的经验是先做几张实用的看板，再考虑大屏。

Grafana连接时序数据库以后，可以很快建立一个设备总览面板，比如：

• 每台设备当前状态（运行/停机/告警）
• 实时电流曲线，最近1小时/24小时趋势
• 轴承温度趋势，方便观察是否缓慢上升
• 告警事件列表

页面不用太花哨，数据准确、刷新及时、异常高亮才是核心。不过要注意，别把现场的模拟量和数字量曲线混在一张图里，刻度都不一样，看起来会很混乱。用多个面板区隔开，或者用不同的单位设置。

3.5 告警通知集成：从阈值到企业微信

规则引擎我用的是自己写的一套简单逻辑，没有引入复杂的CEP引擎。比如温度告警的规则可以这样配置：

rule_name: bearing_temp_high metric: bearing_temp_c condition: value > 70 持续 15s severity: warning action: notify(group=maintenance)

这里的“持续15s”如何实现？我的实现方式是每次数据进来更新该设备的这个指标状态，如果连续15秒都超阈值，才产生一条告警；一旦有一次低于阈值，计数清零。这个逻辑用定时窗口也可以做，但要注意窗口的滑动策略，别用固定窗口，否则在窗口边界附近可能检测变慢。

通知方面，直接对接企业微信的机器人是常用方式。构造一个HTTP POST请求，把告警信息发送到群里。例如：

import requests def send_wechat_alert(text): webhook = "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的密钥" data = { "msgtype": "text", "text": {"content": text} } requests.post(webhook, json=data)

实测下来很稳，推送延迟基本在秒级。注意要把webhook密钥保存在服务端配置里，不要硬编码在前端页面，否则任何人都能往群里发消息。

4. 常见问题与排查技巧实录

4.1 数据断断续续，曲线毛刺多

这类问题在前期集成阶段特别常见。如果是Modbus串口采集，先检查通信参数——波特率、数据位、停止位、校验位是否和设备一致。之前我在现场遇到过一台仪表，通讯参数用9600 8 N 1才稳定，但采集配置里多勾了一个奇校验，结果曲线每隔几分钟就断一下。

如果是网口采集，重点检查网关和设备的IP是否冲突、网线是不是劣质线。还有一点容易被忽略：网关到传感器的走线尽量不要跟动力电缆绑在一起，否则变频器一启动，数据波动、报错全来了。可以用屏蔽双绞线，屏蔽层单端接地，能减少大部分电磁干扰。

另外网关本身的处理能力也要注意。有些网关虽然标称可以接多路传感器，但实际上轮询周期很短时CPU占用很高，导致数据上报不稳定。出现这种情况，就降低采集频率，或者减少同时采集的寄存器数量。

4.2 采集值明显不对，怎么定位

值明显不对，一般先从硬件层排查，再到软件层。

第一步确认传感器本身的输出。拿电流钳表或者万用表量一下变送器输出是不是在4-20mA范围内。比如温度变送器，量程0到150摄氏度，输出8mA，对应温度大约是37.5摄氏度。如果实际温度接近，说明硬件OK，问题在后续的换算或配置。

第二步检查网关的原始数值。如果原始值已经不对，查网关的输入范围配置；如果原始值是对的，查后续的量程换算公式和单位配置。我这里特别强调：把换算公式写清楚，并保留原始值和换算后的值各存一份。有后台数据做对照，排查效率会高很多。

第三步检查是不是字节顺序或者数据类型不对。32位浮点数一个不注意就出来天文数字。32位浮点是IEEE754吗？是大端还是小端？都需要跟设备手册核对。

4.3 时间戳错乱导致曲线排序混乱

时序数据最关键的就是时间对齐。如果设备时间比服务器时间慢5分钟，那这条曲线就是“滞后5分钟”的曲线，告警判断也会跟着偏移。

解决方案是：所有设备统一用NTP服务器同步时间。网关一般都有NTP客户端配置，直接把时间源指向平台所在的内网NTP服务器，一天同步一次。设备本身支持NTP最好，不支持的只能依赖网关打时间戳。

这里我遇到过一个典型案例：一套系统数据入库后，看板上显示的电流曲线波形是对的，但时间轴跟实际差了8分钟，排查半天发现是网关时区设置成了UTC，没有改成北京时间。后续把所有网关的时区都统一设置好，这个坑才算真正填上。

4.4 告警轰炸：不是规则错了，而是规则太敏感

告警轰炸大概率是阈值设置得离正常工作点太近，或者没有设置持续时间和死区。比如电机正常运行可能瞬时电流冲到60A，你把告警阈值设在61A，稍微有一点波动就报“电流超限”，值班人员一晚上被吵醒好多次。

把阈值调高到实际场景不会误触发的水平，比如75A，再加上持续10秒判定，告警数量会立刻降下来。另外还可以设置告警冷却时间：同一台设备同一指标，10分钟内最多推送1条告警，避免重复搅扰。这个功能我在规则引擎里是单独做的，很实用。

4.5 平台启动很久后内存持续上涨

这个问题排查过几次。通常是后端服务消费MQTT消息后，没有正确关闭一些连接或者缓存不断累积。我会定期用jstat、arthas去观察内存分布，找出迟迟不能被GC回收的对象。多数情况是因为数据库连接池配置过小，或者消息处理异常没有释放。比较典型的是：设备离线时，MQTT会不断重连，连接对象没有释放，积少成多就把内存耗尽了。处理好重连策略，加上断线心跳检测，问题基本就解决了。

4.6 上数据中台时候数据量如何精简

设备数据采上来了，尤其是高频采集，数据量增长非常快。运行一年下来，磁盘占用几十GB都不奇怪。如果只是做监控和统计报表，可以配置降采样，把超过30天的原始数据聚合为分钟级平均值。比如原始数据是5秒一个点，存储30天；30天之前的聚合到1分钟一个点再存一年；一年前的再聚合到10分钟一个点存三年。这样既保留了趋势信息，也控制了存储成本。

时序数据库很多都自带这个能力，比如TDengine的降采样。我之前很后悔没有一开始就配置，导致历史数据区间的查询越来越慢。建议采集系统上线时就规划好保存策略。

写在最后

openrig做到现在，给我最大的体会是：设备管理系统的核心不是技术选型，而是从设备到平台整条链路是否可靠、数据是否可信、告警是否有人响应。开源只是手段，把设备一套套接进来，把人的经验一点点沉淀成数据规则，这才是真正的价值。

最后再分享一个实操小技巧：每接入一种新设备，都建立一个独立的接线和参数配置记录，照片、寄存器地址、量程、换算公式全记下来。现场设备多了以后，这份资料会比系统本身还值钱。后续再遇到类似的设备，照着配置改一改就能上线，不用重新踩一遍调试的坑。

这个项目后续还可以扩展的方向很多——比如接入电表做能耗分析，把设备振动数据跟故障预测模型结合起来，将自己的维护经验固化成算法。但不管怎么扩展，先把数据底子打牢、把基本流程跑顺，才是最关键的事情。