开头搞设备管理的朋友应该都有过这种体验现场几十台设备台账在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且开放通讯口通过协议直读Modbus TCP/RTU、S7、OPC UA确认PLC的通讯口令和寄存器地址表设备模拟仪表/无通讯接口外加传感器采集网关注意安装位置和供电避免干扰设备在偏远区域/移动设备4G采集终端独立上报注意流量成本和信号覆盖老设备但有人机界面从HMI后门或触摸屏通讯口旁路采集操作前务必备份程序断线风险自己承担最理想的当然是读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的时候会很痛苦。我设计的核心指标表大致有这些字段字段示例说明ts2024-06-01 10:30:00数据产生时间device_idMTR-PUMP-001设备唯一编号全局统一编码metriccurrent指标名称value12.35物理量值单位统一如安培/Aquality0/1质量戳0有效1无效/可疑关键点是统一device_id的编码规则。因为前端设备五花八门有的叫“1号泵”有的叫“P-101”有的名字是拼音缩写对账的时候会让人崩溃。统一规则建议按工程标准来比如区域码-设备类型-序号例如MTR-PUMP-001表示机修车间第一号泵。这个规则越早定越好后期设备多了改起来非常麻烦。时间戳也要注意设备本地时间与服务器时间要保持一致否则排序和计算容易错乱。这个问题在第四章我详细说。2.4 告警不只是“超过就响”告警是openrig里最影响使用者体验的功能。配置不好要么天天误报变成狼来了要么漏报导致错过处理时机。我常用的几个原则持续时间判定。一个值瞬时超过阈值很多时候只是闪变持续超阈值比如超过10秒才说明真的异常。规则引擎里都要配置超限持续时间这在降低误报率上非常有效。死区设置。比如液位设定高限90%当超过92%触发报警之后要等降到88%才能消除避免在临界点反复抖动导致告警不断产生和恢复。死区的幅度一般是设定限值的2%左右具体要看现场工况波动情况。分组与升级。一般告警分三级注意黄色、警告橙色、严重红色。不同级别通知不同的人。比较严重的情况还可以升级比如告警持续15分钟未确认从值班人员升级到设备主管。我记得有次车间设备告警了十来分钟无人处理后来升级机制把电话打到负责人那里事情才被重视。告警可以只在系统内部弹窗也可以接企业微信、钉钉、邮件推送的具体形式不关键关键是有人看到并且处理闭环。3. 实操过程与核心环节实现3.1 先搭一套最小可用系统硬件清单如果从零开始别想着一步到位把全厂设备都接入。我建议先选一条产线或者一个区域搭一套最小系统跑起来验证稳定之后再复制推广。我以一个典型场景为例一台循环水泵外加一个电机的轴承温度。要做的事情就是把这几个信号采上来、传到平台、显示在看板、设置告警。需要的硬件设备型号参考作用边缘采集网关支持Modbus的工业网关/工控机采集数据、解析协议、转发MQTT温度传感器PT100热电阻变送器测轴承温度4-20mA输出电流互感器开口式互感器变送器测电机电流不用断电安装交换机/网线普通工业交换机连接网关和传感器服务器/虚拟机2核4G起步部署私有化平台这套硬件的总成本控制在几千块以内适合用来验证整个流程。后续设备增加只需要增购传感器和扩大网关接入点数就行。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应用主要做几件事接收MQTT消息校验device_id是否存在解析metrics按照设备配置的量程换算得到标准的物理量打上质量戳标记解析成功还是数据可疑写入数据库同时触发规则引擎进行告警判断。这个地方最容易踩的坑是并发量上来之后消息堆积。如果设备数量多、消息频率高后端的解析速度要跟得上。最开始为了简单我是单线程消费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(groupmaintenance)这里的“持续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, jsondata)实测下来很稳推送延迟基本在秒级。注意要把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做到现在给我最大的体会是设备管理系统的核心不是技术选型而是从设备到平台整条链路是否可靠、数据是否可信、告警是否有人响应。开源只是手段把设备一套套接进来把人的经验一点点沉淀成数据规则这才是真正的价值。最后再分享一个实操小技巧每接入一种新设备都建立一个独立的接线和参数配置记录照片、寄存器地址、量程、换算公式全记下来。现场设备多了以后这份资料会比系统本身还值钱。后续再遇到类似的设备照着配置改一改就能上线不用重新踩一遍调试的坑。这个项目后续还可以扩展的方向很多——比如接入电表做能耗分析把设备振动数据跟故障预测模型结合起来将自己的维护经验固化成算法。但不管怎么扩展先把数据底子打牢、把基本流程跑顺才是最关键的事情。