开源轻量级工业物联网平台UNIHH-IOT：设备数据采集与可视化实战

年底帮一家中型制造企业做产线数据化改造，折腾了几个月，最大的感触是：市面上能用的物联网平台，要么贵得离谱，要么重得吓人。商用平台按点位收费，一个车间几十台设备一年下来就是一笔不小的开支；开源阵营里功能全的大块头又往往依赖重、部署复杂，光初始化环境就能耗掉一周。后来我们自己搭了一套轻量级的工业物联网平台UNIHH-IOT，前后端全部开源，跑在普通的工控机上，平时两三个人维护就够。这篇内容就把它背后的设计思路、技术选型、现场部署经历和二次开发踩过的坑完整记录下来，供同样想搞定工业数据采集与可视化的同行参考。

UNIHH-IOT的核心定位并不复杂：面向工业现场的设备数据接入、存储、计算和展示，强调轻量、高性能、易部署。它不追求把MES、ERP、SCADA的所有功能都塞进去，而是先把“设备说话、平台听懂、人看得见”这条链路打通。对于系统集成商、制造企业信息化部门、自动化工程师，甚至是在校做相关课题的研究者，这套平台的设计思路都有直接的借鉴价值。

这套东西不是说出来的，是实实在在从车间里熬出来的。下边我从为什么做、怎么做、现场怎么落地、二次开发哪里最费时间这几个方面，把UNIHH-IOT完整拆开。就当我带着你从前端页面到后端服务、从设备协议到数据看板，把整个项目重新过了一遍。

1. 为什么非要自己搭一个轻量级平台：车间里的真实约束

先别急着聊技术选型，得先搞清楚一个前提问题——在真实工厂里，物联网平台到底要解决什么。很多文章一上来就堆概念：边缘计算、数字孪生、工业互联网平台，听着高大上，但落到车间地面上，第一批要解决的往往是很朴素的事：把这台注塑机的温度读出来，把那台空压机的运行状态记下来，再把几条线的开工率统计到看板上。

1.1 商用平台在中小车间的“水土不服”

我参与过的几个项目里，有客户一开始直接采购商用物联网平台。平台的销售演示阶段确实漂亮，什么大屏都有，什么图表都会画。但真正进场实施时问题就冒出来了。

首先是计费模式。商用平台普遍按“点位”收费，也就是每个采集的数据点都要算钱。一个车间几十台设备，每台设备少说四五个点位：温度、压力、电流、运行状态、报警信号，算下来一年订阅费相当可观。更难受的是如果后期要加设备、加点位，费用是线性增长的，产线扩了，平台费跟着涨，甲方财务看一次头大一次。

其次是数据留存的限制。有些商用平台的免费版或者基础版，存不了几天历史数据，想看一周前的趋势图都不行，得加钱买存储空间。工业现场要分析设备的长期运行趋势，历史数据恰恰是最值钱的资产，这一点被商业平台卡脖子，实在憋屈。

还有一点是集成的封闭性。设备数据进了平台之后，想再拉出来对接给MES或者自己做的看板，往往只能通过官方API，部分平台还限流、限制字段。如果甲方自己做信息化的小团队想改点东西，根本使不上劲。

1.2 开源大平台的“能力过剩”

既然商用平台有这些问题，那就看开源方案。开源物联网平台确实有不少成熟项目，功能覆盖设备接入、规则引擎、可视化、告警等方方面面，社区也活跃。但用下来有两个很难绕开的痛点。

第一个是重。这类重型平台通常依赖多个中间件，消息队列、非关系型数据库、关系型数据库、容器编排一套拉起来，对服务器配置的要求不低。中小工厂的信息化机房，往往就是一台老旧的服务器，配置很普通。硬要把重型平台塞进去，性能直接拉胯。

第二个是维护成本高。功能越全的系统，升级、调优、排障的复杂度越高。车间里没有专职的平台运维工程师，往往是设备科的电工兼着信息化，你让他去调消息队列的参数、搞集群扩容，不太现实。

还有一点，重型平台为了兼容各种各样的接入场景，把架构层做得很绕。真要二次开发去加一个自定义协议解析器，得翻大半天源码才能找到合适的扩展点，学习曲线非常陡。

1.3 倒是“小步快跑”最实际

把商用平台和重型开源平台的问题摆在一起，其实就勾勒出了我们自己需要的东西：能在普通工控机上流畅运行，部署步骤尽量少，核心数据模型自己说了算，前后端代码完全可改。平台不追求大而全，但设备接入、数据存取、实时展示、告警通知、二次开发接口这五件事必须做到称手。

UNIHH-IOT最初就是在这么个背景下立项的。当时我们的目标很具体：让一个没有专职IT的车间，也能用一台普通电脑，三天之内跑起自己的设备监控系统。这个目标听起来不性感，但做起来比想象的复杂得多。也就是从那时候起，我开始理解“轻量”不是少了功能的借口，而是要在各种约束下做取舍的艺术。

这就是为什么我在文章开头说，UNIHH-IOT不是实验室里构思出来的，是从车间里熬出来的。技术选型、模块划分、性能优化，桩桩件件都是被实际条件逼出来的。

2. 整体架构拆解：云、管、边、端四个层面的取舍

架构设计这件事，最忌讳一上来就画复杂的分层图，把微服务、容器、大数据全堆上去。UNIHH-IOT的核心设计理念是“让数据沿着最短路径流动”。我把整个平台拆成端、边、管、云四个层面来看，每个层面都做了很明确的取舍。

2.1 端侧：设备协议接入的务实策略

工业现场的协议之杂，做过的都懂。Modbus RTU、Modbus TCP、OPC UA、三菱或者西门子的私有协议、再到各类传感器厂商的定制协议，每一类都够喝一壶的。

UNIHH-IOT的端侧接入层采用了“协议插件化”的结构。核心框架定义了一套标准的数据模型和通用接口，具体解析工作全部丢给独立插件。这意味着新接入一种设备，只需要实现一个协议解析插件，而不用动平台主干代码。

举一个很典型的例子。车间里有一批老旧温控仪表，只支持Modbus RTU串口通信，仪表里存的寄存器地址还跟标准略有差异。我们当时做的就是写一个简单的Modbus插件，把寄存器的映射关系做成可配置的JSON文件。来一个新设备，改改配置文件就行，连代码都不用动。

另外，端侧还预留了MQTT网关接入方式。很多新设备自带MQTT上云能力，还有些传感器通过边缘网关转成MQTT再统一上报。UNIHH-IOT把MQTT和Modbus这两种模式当作一等公民来支持，基本覆盖了绝大多数中小车间的通讯现状。

2.2 边侧：网关缓存与断网续传的价值

工业网络和办公楼网络最大的不同在于——车间里网络抖动、掉线是常态。车间地面有重型设备移动，无线信号被遮挡是常有的事；有线网络也偶发因为施工挖断了线缆导致通信中断。如果在这些情况下平台直接丢数据，那么后期的统计和分析就全部失真了。

UNIHH-IOT在边缘侧设计了一个轻量网关程序，这个程序可以直接跑在工控机上，也可以部署在车间角落的迷你主机里。它的核心作用是：一边连接现场设备采集数据，一边和云端平台保持通信。一旦网络断了，网关会把数据写到本地环形队列缓存里；网络恢复后，再按时间戳顺序补报。

这个功能看着不起眼，但实际价值非常大。我们遇到过产线网络连续断了几小时的情况，正是因为有了边缘缓存，恢复后几分钟内就把断档数据补齐了，趋势曲线完全连续，甲方对这一点印象极其深刻。

2.3 管侧：轻量规则引擎和告警机制

数据从边缘到了平台侧，就要进入规则处理和告警判断的环节。UNIHH-IOT没有去实现一个像开源流处理框架那样复杂的分布式流计算引擎，而是做了一个轻量级的、基于时间窗和阈值配置的规则引擎。

规则引擎怎么理解？打个比方，就是给数据设置“如果-就”的监测逻辑。比如注塑机的料筒温度如果连续三次采集都超过300度，那就触发高温告警；空压机的电流如果在一分钟内波动超过某个百分比，就提示运行异常。

关键在于所有规则都通过界面配置，不需要写代码。工厂里的老师傅也能在技术人员的简单指导下，添加一条自己的监测规则。告警产生之后，通知渠道可以对接短信、邮件、消息群机器人，这个机制在车间里非常实用，老师傅不用一直盯屏幕，设备出了异常手机上就能收到提醒。

2.4 云侧：存储、API 与前端可视化的高效协作

平台侧的存储选择上，UNIHH-IOT没有上来就用复杂的大数据组件。时序数据存储用的是轻量级的时序数据库，设备点位等元数据用关系型数据库，两层各司其职。时序数据库对高频写入的吞吐量支撑很好，查询指定时间段趋势图也非常快，几千个点位的数据量完全可以稳定跑着。

API层全部采用标准REST风格开放，认证做了简单的Token机制。甲方自己的信息化团队想对接数据，拿到文档几分钟就能上手。前端可视化使用的是经典的前端技术栈，配合一些成熟的开源图表库，实现实时曲线、柱状统计、报警记录、车间总览大屏等场景。前端工程和后端服务是彻底分离的，前后端各自部署、各自演进，二次开发时可以只改前端不需要动后端，也可以反向操作。

这么一套“端-边-管-云”的分工，最终目标就是让不同角色的使用者在各自的环节都能快速上手。下面这篇文章，我把细节收敛到更具体的落地过程中来展开，讲一讲那些真正把平台用起来的关键动作。

3. 把一台老设备接上平台：从接硬件到看大屏的完整链路

光讲架构不讲操作就是纸上谈兵。这一部分我以一台很常见的“老家伙”设备为例，完整走一遍从硬件接线到最终大屏展示的流程，让你清楚地看到UNIHH-IOT是怎么一口一口把设备数据吃进去的。

3.1 硬件侧的“最小接入方案”

拿一台老式的液压机来说，它的控制器只支持Modbus RTU RS485串口输出。工控机要不要装？网关要不要挂？其实不用那么复杂。UNIHH-IOT的最小接入方案只需要一台边缘网关或者普通的迷你工控机，加上一块USB转RS485转换器，再加上两根线把转换器接到设备的RS485接线端子上。

第一次接触工业通信的同行，常被RS485的接线搞晕。其实记住两条规矩就够了：A接A，B接B，不要接反；还有千万别把485的两根线接到供电端子上，一接反轻则通信无响应，重则烧掉转换器。我们现场吃过一次亏，所以特别强调这第一道关卡。

硬件接好之后，在网关机器上运行边缘网关程序，填好设备连接的串口信息、波特率、数据位、校验位这些参数。再用一个简单的设备调试工具扫一下设备寄存器，确认能读到真实数值。这一步的本质是验证链路通不通，如果读不到数据，往往是波特率不对、设备地址不对或者寄存器地址区间填错，这三件事解决了九成问题。

3.2 在平台侧添加设备和数据点

在UNIHH-IOT的管理界面里，新建一个“设备”，选择对应的协议类型（这里选Modbus RTU），填入设备地址；接着给这台设备配置数据点：温度、压力、运行时间、当前状态，每个数据点都对应寄存器地址和数据类型。

配置完成后平台会实时显示从网关同步上来的数据。这里提一个细节——数据点的采集周期的设置。并不是每个点位都要求一秒刷一次，像设备温度这种变化缓慢的量，设置5秒采集一次就够了；而像设备运行状态这种需要及时感知的，可以设置1秒。合理分配采集周期，能明显降低网关和平台的负载，这是性能调优里最轻松又很见效的一步。

3.3 时序数据如何落库，前端如何读到

数据从设备出来，经网关传到平台之后，并不是直接扔给前端展示的，中间还有一条重要的流水线：平台收到上报数据后，先做协议层面的验证和解析，再按数据点标识存入时序数据库。存储时给每个数据点自动打上时间戳，并保留设备维度的标签，这样后续查询“某台设备某一天的运行时长达标率”就非常快。

前端看板读取数据用的是API查询。拿实时曲线举例，页面打开时一次性加载最近一个小时的历史数据画曲线，然后通过WebSocket通道持续接收最新的实时点位值进行动态更新。这种方式既保证打开页面时曲线立刻有内容可看，又不会因为频繁轮询给数据库带来压力。

3.4 看板设计：从数据表到大屏的审美跨越

设备接上、数据在库里躺好了，最后一步是让数据变得“好看好用”。真正让车间里的人愿意用起来的看板，设计逻辑是反过来的——先想好看板给谁看，再看要放什么数据。

给车间主任的看板，核心就要突出三件事：今天的产量完成比例、各设备当前的运行状态、有没有报警还没处理。给设备工程师的看板则偏向详细数据曲线，比如主轴温度趋势、压力波动情况。这两类人的需求完全不同，在同一张看板上硬塞是两头不讨好。

UNIHH-IOT的前端做了多页面看板的支持，一套平台可以配置多个看板页面，每个页面自由拖拽图表组件。大屏展示时用深色背景、高对比度配色；日常操作页面则保持浅色、信息密度适中。这种灵活度在二次开发时很受用，甲方自己没有设计师也能通过配置模板做出像样的画面。

4. 现场上线后的真实问题：性能、协议与稳定性的缠斗

凡是觉得物联网平台做完就能一劳永逸的，多半是还没经历过现场上线的考验。UNIHH-IOT在多个现场跑过之后，我们有针对性地解决了好几类真正磨时间的问题，这里挑最有代表性的几个展开，能帮你少走不少弯路。

4.1 数据量涨起来后的性能瓶颈与优化

刚开始接入十几台设备时，平台跑得相当丝滑。后期扩展到几十台设备、上百个数据点，高频率采集时发现一个怪象：前端看板偶尔出现数据延迟，时序数据库的CPU占用率也一路飙升，数据库查询越来越慢。

排查下来，最大的瓶颈在写入路径上：每个数据点都是一条独立的高频写入请求，数据量一大，数据库的连接池和写入线程直接饱和。优化的思路很直接，把高频写操作改成批量写：网关在边缘侧先攒一批数据，按照几十条一组的节奏提交；平台侧同步调整写入逻辑，一次事务处理一批点位数据。改动上线后，数据库的压力骤降，前端数据的及时性也恢复正常了。

另一个容易被忽略的坑是历史数据清理策略。时序数据库如果不做保留周期的管理，磁盘再大也会被不知不觉写满。我们给所有点位设了默认保留周期，例如原始数据保留90天、聚合数据保留两年，既满足日常分析需求，又锁住了存储成本的上涨。

4.2 Modbus轮询超时与设备响应慢的处理

Modbus是标准协议，但现场的表现往往不那么“标准”。我们碰到过一种情况：车间里某几台设备都挂载在同一条RS485总线上，网关轮询的时候发现，只要那几台设备凑在一起运行，总会有读取超时。

最终定位是总线上设备过多、通信周期太长导致的响应冲突。处理方法有两种：一是把总线上设备拆分到不同串口，降低单条总线的负载；二是调整轮询策略，给每台设备设置独立的超时参数和重试次数。还有一次更折腾的状况，排查到最后是某台第三方设备主动占用了总线，把通信节奏打乱了。这种问题最费时间，需要一台一台设备断开去试。UNIHH-IOT支持把设备分组、每组单独配置轮询频率，同时在日志里记录每次超时的完整上下文，这让排查总线问题时效率高了不少。

4.3 网络抖动如何做到“看不出来”

车间网络质量参差不齐，前面提到边缘网关有断网续传机制，这里再补一个细节：如果网关和平台之间长时间断开，缓存的数据量会非常大，恢复后如果一次性全量补报，平台端的写入压力同样会很大，甚至可能引发二次故障。

UNIHH-IOT在补报时采用了“分批平滑补报”的方式：恢复网络之后，网关不会一股脑把积压数据全部推上来，而是按照一个合理速率，一小批一小批地补偿。这样既能保持数据的完整性，又不会对平台造成冲击，相当于在网络恢复和平台负载之间做了缓冲。现场实际运行下来，断网半小时以内，前端看板几乎察觉不出异常。

4.4 二次开发中最容易拖后腿的三件事

UNIHH-IOT一定是需要二次开发的，毕竟每个工厂的工艺都不一样。但据我们观察，很多二次开发团队把精力耗在了三件不太值得的事情上。

第一件事是钻牛角尖去改核心架构。UNIHH-IOT的扩展点已经留得很清楚，协议插件、规则函数、API接口都有现成的机制。非要为了一个特殊需求去动底层存储结构，结果往往是升级新版本时痛苦得不行。除非平台的核心逻辑和你的需求真的冲突，否则不建议动主框架。

第二件事是忽视权限模型。很多集成商在开发时把精力放在功能上，系统上线后才发现不同角色（操作工、班组长、工程师）的权限划分得不清不楚。UNIHH-IOT的角色权限模块是开箱即用的，什么时候花点心思把角色配置好，什么时候就能省掉后期大量的管理麻烦。

第三件事是不重视日志与监控。二次开发上线之后，出了问题第一反应是看日志，如果日志写得不到位，排查问题就像大海捞针。我们的经验是每个新增功能至少要保证“开启时有关键信息输出、异常时有明确错误上下文”这两件事，日志的事儿拖不得。

除了上面三点，我还想额外提醒：二次开发时尽量保持前后端的接口文档同步。UNIHH-IOT的API本身有自动文档生成的能力，只要你后端改了接口，前端开发的同事立刻能看到更准确的信息，省掉大量口头沟通的时间。

5. 部署细节与维护经验：多快好省地跑起来

这部分给真正准备动手部署UNIHH-IOT的同行列一些可执行的参考。整个平台部署以Docker为首选方式，前后端服务加边缘网关，一个编排文件即可拉起来，对硬件要求并不高。

5.1 硬件配置参考

以上参数来自实际部署经验。特别注意，尽量不要把数据库放到机械硬盘上，时序写入模式对随机读写性能要求较高，SSD能明显提升长期稳定性。

5.2 启动顺序与常见陷阱

部署时最容易踩的坑就是服务启动顺序。UNIHH-IOT依赖关系很明确：数据库最先启动并完成初始化，然后启动后端业务服务和时序数据库服务，最后启动前端页面服务和边缘网关。如果先后顺序弄反，后端服务启动时连不上数据库就会直接退出。Docker编排文件里已经配置好了依赖关系，但如果你采用手动部署的方式，一定要留意这个顺序。

另一个常见问题是端口占用。工业现场的老服务器上可能跑着其他管理系统，80端口、8080端口经常被占用。UNIHH-IOT的配置文件里所有端口都可以自定义，改起来简单，但建议上线前就规划清楚，别到后期再迁一次，迁一次折腾一次。

5.3 维护经验：例行巡检与定期备份

系统稳定运行一段时间后，日常维护的压力不大，但有两件事建议形成固定巡检动作。

一是查看边缘网关的缓存队列深度和网络连接状态。如果发现缓存队列经常处于较深水位，说明现场网络稳定性有待提升，需要尽早处理，别等到累积成故障才发现。

二是数据库定时备份必须配置。时序数据是整套系统最宝贵的资产，丢了很难追回。我们通常设置每天凌晨自动备份一次，保留最近一周的快照。整个过程无感，只需要在服务器上挂一个定时任务就行。

5.4 文档与社区：也算开源的一部分

UNIHH-IOT的“全开源”不仅指代码，还有配套的说明文档、部署指南、协议插件开发样例。很多开源项目的问题出在文档太简略，部署一个环境要靠自己猜。这个项目在这方面的体验很友好，照着文档一步一步来，基本可以顺利跑通。

如果真的遇到问题，社区里的讨论氛围也不错。很多一线实施的朋友提出的问题都特别实际，比如“某款仪表遵循Modbus协议但寄存器地址映射比较奇怪该怎么配”，这种具体场景往往能从别人的经验里直接找到答案。开源的意义从来不只是把代码挂到网上，而是建立一个让使用者互相帮助、反馈迭代的正循环。

我个人在这些年的项目实施中感触最深的一件事是：一个平台的价值，不在于用了多新的技术，而在于它能不能让现场的人真正用起来。UNIHH-IOT之所以能在一个个车间里长期稳定跑下去，很大程度是因为它把“轻量”“可用”“可改”这三件事贯彻到了每一个模块的设计里。

如果你也正准备在工业现场搭建自己的设备数据采集系统，我的建议很简单：先不要纠结平台要多么“完整”，先把一台设备、一条产线完整地跑通，再慢慢扩展。所谓数字化转型，说到底就是让数据从设备里走出来，走到看板上，走到决策人的眼前。这套路走通一次，后面就一通百通。