第一次看到 openrig 这个词的人十有八九会愣一下——这到底是一个“开放的钻机”还是某种“开放机架”实际上在工业自动化与设备运维的圈子里rig 是对大型现场设备的一种习惯叫法从钻机、修井机到泵组、压缩机组都可以被叫作 rig。而 openrig 这个词我更喜欢把它拆成 open rig 来理解一套面向工业设备、架构开放、数据开放、逻辑开放的采集与远程运维平台。简单说就是把现场设备从“黑盒”变成“白盒”让设备状态、运行参数、报警信息都能实时、透明地汇聚到统一平台里再通过看板、报警和数据分析真正用起来。如果你正在面对设备厂商私有协议绑定、现场数据拿不上来、多品牌设备难以统一管理这类问题那 OpenRig 这个思路可能正对你胃口。这篇文章我会完整复盘 OpenRig 平台的背景、架构、选型理由和实测踩坑从设备层的数据采集一直讲到服务端的可视化与运维尽量把每一步怎么选、为什么这么选都交代清楚。无论你是工厂的自动化工程师、做设备物联网的开发者还是刚入行想了解工业数据平台搭建的爱好者都可以从里面找到可以直接照做的部分。1. 为什么需要 OpenRig开放设备平台的背景与思路1.1 从“设备黑盒”到“数据透明”做设备运维的人都有体会现场设备越先进数据反而越难拿。很多设备控制系统出厂时就带了一套远程监控方案但往往是封闭的要么只能看厂家自己的界面要么想导出数据还要单独买授权甚至有的协议连文档都不公开。用户想自己做一个报警提醒、做一个能耗分析都会被卡在数据获取这一步。我自己最开始做 OpenRig 的起因就是现场一台大型机组总是出现不明原因的停机厂家远程看了半天也没给出定论。后来我们想自己分析历史趋势结果发现控制系统的数据导出功能被限制只能手工截图。那段时间我就在想如果设备数据能用一套开放、标准的方式拿到自己手里很多问题根本不用等厂家。所谓“数据透明”不是说要把设备厂家的核心控制逻辑全都翻出来而是把运行参数、报警事件、启停状态这些运维需要的数据用标准协议传输出来。比如一个温度测点、一个振动测点、一条报警记录这些数据本身不涉及厂家核心技术但却是设备管理最需要的东西。OpenRig 做的第一件事就是把这一层数据通道打开。1.2 传统 SCADA 方案的局限与开放架构的优势很多工厂已经有 SCADA 系统为什么还需要 OpenRig 这样的开放平台传统 SCADA 擅长的是实时监控和操作但它有几个现实问题。第一点位组态通常很重新增一个测点往往需要停机或者重新组态第二历史数据存储能力弱想要做长时间趋势分析、机器学习训练数据量一大就扛不住第三SCADA 的数据模型跟具体项目绑定很深很难把多个站点、多种类型的设备统一成一个标准模型。OpenRig 的核心思路是“数据层与监控层解耦”。数据采集层只负责把设备数据转成标准格式并转发到消息总线平台层只负责存储、计算和展示两者通过标准协议对接。这样一来设备端可以换平台端也可以换任何一层都不是绑死的。这个架构对多站点、多品牌设备尤其友好。举个实际例子A 现场用的是西门子 PLCB 现场用的是国产控制器C 现场还是老式仪表加采集模块。传统做法是分别建几套系统而 OpenRig 的做法是每套现场加一个边缘网关网关内部把不同协议统一成同一个 JSON 模型然后上报到同一个平台。上层根本不需要关心底下是什么品牌它只认设备 ID、测点 ID 和数值。这种“底层异构、上层统一”的思路就是 open 里最值钱的部分。1.3 谁最适合用 OpenRig 这套方案并不是所有场景都需要上完整平台。根据我的经验OpenRig 最适合三类情况。第一类是中小规模但设备种类杂的工厂没有专职 IT 团队但想用低成本的方案把设备数据管起来第二类是有多个异地站点的企业比如污水处理厂、泵站、光伏电站需要把分散设备的数据集中到一个平台看板第三类是准备做预测性维护、设备健康管理的团队需要一个能存海量历史数据、方便跑算法的底座。反过来如果是单套大型 DCS 集中控制的生产线或者对实时性要求达到毫秒级联锁的控制场景那 OpenRig 不适合那是 DCS/SCADA 的领域。OpenRig 解决的是管理、分析、优化层面的问题不是替代现场控制。这个边界一定要清楚不然方案评审的时候容易被懂行的人一句话问住。2. OpenRig 整体架构与核心技术选型2.1 四层架构从设备现场到数据看板OpenRig 的整体架构可以分成四层设备层、边缘采集层、平台服务层、应用层。设备层就是现场的传感器、PLC、控制器、仪表它们通过各种协议对外提供数据边缘采集层是 OpenRig 的关键通常由工业网关或嵌入式设备组成负责协议解析、数据清洗、边缘计算和断点续传平台服务层包含消息队列、时序数据库、规则引擎和 API 服务是数据流转和处理的中枢应用层则是可视化看板、报警中心、移动端和数据分析环境。这个分层设计最大的好处是每一层都能独立升级、独立扩展。比如设备层加了新类型只要边缘层适配好平台层不用动平台层想换数据库只要接口不变应用层也不受影响。模块之间全部通过标准 HTTP/MQTT 接口通信任何一层换成其他开源组件都成立。某些开源项目会把采集、存储、展示都做成一个一体化服务部署简单但扩展性差。OpenRig 从第一天起就按微服务思路拆哪怕初期所有组件都跑在同一台 PC 上逻辑边界也保持不变。等到数据量大、设备量多的时候直接把某个服务拆出来部署到独立服务器就行。2.2 数据采集层Modbus、OPC UA 与自定义协议处理设备侧数据采集是 OpenRig 最“硬”的部分。以最常见的工业设备为例老设备基本都支持 Modbus RTU/TCP新设备很多支持 OPC UA还有些设备只有厂家私有协议甚至只有网口和一组 SDK。OpenRig 在采集层定了一个很实用的原则优先走标准协议私有协议尽量在网关上适配而不是在平台上适配。为什么这么选因为平台如果接入十种私有协议那十种协议的解析逻辑就要长期维护而如果每个现场的网关只处理自己连的那一两种私有协议难度就小得多也方便现场人员做针对性调试。平台层只接收统一格式的数据这是“开放”的关键约束。实际开发中我用 Node-RED 做协议解析比较多。Node-RED 本身支持 Modbus、OPC UA 等节点同时可以自己写 JavaScript 解析函数非常适合快速做协议适配。当然如果要做大规模部署会改用 Go 或者 Rust 写的采集程序资源占用更小但逻辑上还是同样的套路定时轮询设备寄存器做数据转换然后按标准模型上报。2.3 传输层为什么消息选了 MQTT 而不是 HTTP不少朋友问数据量也不大为什么设备上报要用 MQTT 而不是 HTTP这里关键不在数据量而在连接模型。工业现场大量设备位于 NAT 网关后面没有公网 IPHTTP 需要设备主动连接服务端服务端很难主动把指令下发回设备而 MQTT 基于发布/订阅模式设备和服务器之间通过一条长连接保持通信既能上报数据也能随时接收平台下发的控制指令。另外MQTT 的 QoS 机制很适合工业数据补传。现场网络经常出现断断续续MQTT 可以把消息持久化到 broker等设备恢复连接再补推保证数据不丢。OpenRig 的传输层默认选 EMQX原因很简单开源、支持 MQTT 5.0、集群部署容易、自带规则引擎。如果只是小规模验证用 Mosquitto 也完全够用但规则引擎和插件能力弱一些。MQTT 主题设计也要提前规划好。OpenRig 采用三层主题结构openrig/{site_id}/{device_id}/telemetry 上报测点数据openrig/{site_id}/{device_id}/event 上报事件和报警openrig/{site_id}/{device_id}/command 下发指令。这样不同数据通道天然隔离平台侧订阅起来也很清晰不会出现所有消息都堆在一个主题里的情况。2.4 存储层时序数据库选型与数据保留策略设备数据本质上是一堆带时间戳的数值序列特点就是写入频率高、查询经常按时间范围聚合。普通关系型数据库不是不能用但数据量一大写入和查询性能会明显下降。OpenRig 的存储层选择了时序数据库 TimescaleDB它是 PostgreSQL 的扩展既能享受 PG 的生态又能自动按时间分区对 SQL 支持非常友好。很多团队一开始用 MySQL 存测点数据到百万条数据后查询就明显变慢。TimescaleDB 通过 hypertable 把数据按时间分块存连续两年的数据也能秒级查询聚合。而且它对已有 PG 经验的人几乎没有学习成本标准的 SQL 就能写连续聚合、降采样用起来比很多专用时序库顺手。存储层还需要考虑数据保留策略。OpenRig 默认会把原始数据保留 30 天用于实时分析把降采样后的小时级数据保留一年月度统计永久保留。具体做法是 TimescaleDB 的保留策略加连续聚合视图比如原始数据一分钟一条保留一个月五分钟聚合数据保留一年一小时聚合数据永久。这样既能控制存储成本又不丢失长期趋势。2.5 应用层从 Grafana 看板到低代码规则引擎应用层是用户真正能看到价值的地方。OpenRig 的可视化用的是 Grafana接入 TimescaleDB 后可以快速做趋势曲线、仪表盘、热力图和报警面板。Grafana 的好处是插件生态丰富、告警规则灵活、看板可以导出分享团队协作起来很方便。除了看板规则引擎也很重要。EMQX 自带规则引擎可以直接对 MQTT 消息做过滤和转换比如发现某个测点连续三次超过阈值就产生一条报警消息。复杂一点的场景可以用 Node-RED 做条件判断比如超温加振动异常才触发真正的故障报警而不是单点一超就乱报。OpenRig 的报警规则都设计成可配置的运维人员不需要改代码在配置文件或界面里就能调整阈值和报警时间窗口。3. OpenRig 从零搭建的实操记录3.1 硬件选型与现场安装准备先说说我们用的硬件。边缘网关是最核心的现场设备OpenRig 支持两类方案一是低成本的树莓派或国产 ARM 盒子适合数据量小、环境较好的场景二是工业级 DIN 导轨网关比如带有串口、网口、DI/DO 的型号适合有粉尘、高温、振动大的设备现场。我当时选的是 ARM 架构的工业网关装 Debian 系统带两个千兆网口和四个 RS485 串口。为什么选这款因为现场设备同时有网口和串口两种接口这款网关刚好能同时接入两个 RS485 总线和一个以太网不用再加转换器。安装的时候一定要确认导轨牢固并做好接地很多采集波动的问题都是现场接地不良引起的。网关上面跑的服务很轻量一个 Node-RED 进程负责协议采集一个 Mosquitto 客户端负责发布数据再加一个简单的看门狗脚本定期检查两个进程是否存活。网关不直接跑数据库和看板尽量把计算压力留给服务器这是边缘网关保持稳定的关键。3.2 点位表梳理与数据字典设计接设备之前最重要的一步是梳理点位表。点位表就是把每个测点的设备号、寄存器地址、数据类型、数据格式、单位、采集周期、报警上下限全部列清楚。传统做组态时点位表是写在 Excel 里的OpenRig 的做法是把点位表转成一份 JSON 配置文件通过网关上的 Node-RED 节点动态加载。这里特别容易踩坑很多设备的寄存器地址并不是连续一致的。比如一个设备把温度放在 40001另一个同类设备温度在 40005如果靠写死地址未来新增设备就要改程序。OpenRig 从一开始就在点位配置里加了一个“设备模板”的字段同型号设备共用模板新设备上线只要填设备 ID 和实例编号不用重新配置测点。数据字典设计还涉及一个看似小但很关键的问题单位换算。很多现场数据是原始整数比如温度寄存器里的值是 352实际要除以 10 是 35.2 度。这个换算系数必须写进点位配置不能上报到平台后再临时算否则在边缘端如果不统一后面做分析会乱套。3.3 边缘网关配置与数据上报实现下面我把网关配置的关键步骤拆开讲尽量让你照着做也能跑通。第一步安装 Node-RED 和 Modbus 相关节点。可以使用以下命令sudo apt install node-red cd ~/.node-red npm install node-red-contrib-modbus node-red-contrib-mqtt-broker第二步在 Node-RED 里创建一个 Modbus 读点的流程。简单来说一个节点连接设备 IP 和端口一个节点读取指定寄存器一个函数节点做单位换算最后一个节点把结果组装成 JSON交给 MQTT 节点发送。核心的发送消息格式大概是这样的{ device_id: compressor_001, ts: 2025-03-14T10:30:0008:00, points: { bearing_temp: 42.3, oil_pressure: 0.65, vibration: 2.8 } }这里特别强调一下 ts 字段必须在设备端生成并携带而不是等服务端接收时打时间戳。否则网络延迟或断网补传的时候数据时间会完全错掉趋势分析就是错的。我们现场调试中因为这个问题吃过亏后来才统一了“设备时间优先”的规则。第三步配置 MQTT 连接。在 Node-RED 的 MQTT 节点里填写 broker 地址、端口、用户名密码主题就按之前说的三层结构来写。建议开启 MQTT 的 retain 选项吗这里反而不建议因为 retain 只用于保存最新状态而测点历史数据不应该用 retain。第四步测试数据上报。可以在网关本机用命令行订阅主题确认消息结构正确mosquitto_sub -h broker_host -t openrig/demo_site/compressor_001/telemetry -v如果能看到 JSON 数据正常输出说明边缘侧已经打通。我最开始调试时总是忘记把 Node-RED 的输出节点改成 JSON 格式导致订阅端显示的是字符串转义的一堆符号很影响判断。这个小问题排查了好一阵子后来我把所有输出节点都统一加一个 JSON 解析再把解析后的对象发给 MQTT。3.4 服务端组件部署与配置服务端我用 Docker Compose 一次性拉起三个核心组件EMQX、TimescaleDB、Grafana。下面是一个最小化的部署文件version: 3.8 services: emqx: image: emqx/emqx:5.x ports: - 1883:1883 - 8083:8083 - 18083:18083 environment: EMQX_DASHBOARD__DEFAULT_USERNAME: admin EMQX_DASHBOARD__DEFAULT_PASSWORD: your_password timescaledb: image: timescale/timescaledb:latest-pg16 environment: POSTGRES_PASSWORD: your_password volumes: - ./pgdata:/var/lib/postgresql/data grafana: image: grafana/grafana-enterprise ports: - 3000:3000 environment: GF_SECURITY_ADMIN_PASSWORD: your_password volumes: - ./grafana-data:/var/lib/grafana部署完成后需要到 TimescaleDB 里创建时序表。基本建表语句如下CREATE TABLE telemetry ( device_id text NOT NULL, point_name text NOT NULL, value double precision NOT NULL, ts timestamptz NOT NULL ); SELECT create_hypertable(telemetry, ts);然后还要建一个连续聚合视图用来做小时级的降采样CREATE MATERIALIZED VIEW telemetry_hourly WITH (timescaledb.continuous) AS SELECT device_id, point_name, avg(value) AS avg_value, max(value) AS max_value, min(value) AS min_value, time_bucket(1 hour, ts) AS bucket FROM telemetry GROUP BY device_id, point_name, bucket;这笔数据量要清楚假设一套设备有 50 个测点采集频率 1 秒一次一天就是 50 × 86400 432 万条数据。如果现场有 10 套设备一天就是 4320 万条一个月就要超过十亿条。没有时序数据库和连续聚合这种量级靠普通查询是撑不住的。这也是 OpenRig 选择 TimescaleDB 的直接原因。3.5 看板搭建与报警规则配置服务端跑起来后Grafana 里添加 TimescaleDB 数据源然后新建一个面板。我最常用的是时序图用来同时显示同一设备的温度、压力、振动趋势。为了对比不同时段的数据Grafana 里可以加一个时间范围变量。用 SQL 写查询的时候注意$__timeFilter(ts)这个宏它能自动跟随面板的时间范围避免每次改时间都要重新写 SQL。报警配置上Grafana 自带的报警系统已经够用。先建一个报警规则例如指标telemetry 中的 bearing_temp条件max() over 5 minutes 50评估间隔1 分钟通知渠道Webhook 发送到企业微信群机器人这套配置下来报警延迟基本控制在 1 分钟以内。但有件事要提前说报警阈值不一定一上来就是死的。建议先用历史数据算一个基准比如用最近 7 天的 95 分位乘一个安全系数。直接套用设备手册里的额定值往往会产生大量误报这是我在现场比较深的体会。4. 常见问题与排查技巧实录4.1 网关数据不上报怎么办数据不上报是 OpenRig 最常见的故障。我的排查顺序是先看网关进程是否存活再看 MQTT 连接是否正常再看主题是否正确最后看服务端是否收到。可以用一条命令在网关上检查 MQTT 连接状态mosquitto_sub -h broker_host -t openrig/# -v -W 10如果网关能订阅但看不到数据把 Node-RED 里的调试节点打开看看消息是不是根本没走到 MQTT 节点。大多数问题出在 Modbus 读取失败比如寄存器地址不对、设备 IP 变了、串口波特率不匹配。这里有一个小技巧先用厂家自带的调试工具读同一个寄存器确认数值正常再对比 Node-RED 读出来的值。如果有差异大概率是字节序或数据类型选错了。4.2 时间戳错乱与历史数据补偿前面提过OpenRig 规定时间戳必须由设备端生成。但实际运行中网关的时钟可能会漂移尤其是一些低成本的 ARM 板子没有 RTC 电池断电重启后系统时间可能回到出厂时间。如果网关上没做 NTP 同步上报的数据会带着一个错误的时间戳进了时序数据库之后整段趋势全是乱的。解决方案是给所有网关配置 NTP 客户端并定期检查时钟偏移。OpenRig 在每个网关的看门狗脚本里加了一个时间同步检查如果偏移超过 30 秒就强制同步一次。服务端收到数据后也可以做一层时间合理性校验如果设备时间与服务器时间差超过 5 分钟就把这条消息标记为可疑数据。宁可漏一点也不能让脏数据污染长期趋势。4.3 网络抖动导致的数据丢失与补传工业现场网络不稳定的情况太常见了。MQTT 虽然有 QoS但如果 broker 在设备断线期间把消息丢弃了数据就永久丢失。OpenRig 的解决办法是在边缘网关本地做一个 SQLite 缓存队列。具体逻辑是数据照常生成先写入本地 SQLite然后按顺序发布到 MQTT发布成功后删除本地记录。如果网络断开发布失败的消息会继续保留在队列里。网络恢复后程序自动发起补传。这个机制听起来不难但要注意一个细节消息在本地队列里也要带原始时间戳同时记录一个“实际发布时刻”。否则补传的数据到了服务端会有一大片突兀的“平线滞后”现象因为 Grafana 按时间戳画图而写入时间晚了几小时。4.4 时序数据库写入性能瓶颈调优数据量上来之后TimescaleDB 也可能出现写入延迟。首先要检查是否创建了正确的索引尤其是 device_id ts 的组合索引。没有这个索引查询会变得非常慢但写入性能不受太大影响。写入慢更常见的原因是磁盘 IO 跟不上或单条 SQL 插入太多行。OpenRig 使用批量写入边缘网关每次发布包含多个测点的数据服务端在接收时积攒 500 条或 2 秒批量插入一次。TimescaleDB 的常见参数也需要调。比如timescaledb.max_background_workers默认值偏小连续聚合和保留策略都依赖后台任务现场有多个 hypertable 的时候可能会调度不过来。把它调大到 16 或者更高任务排队的情况会明显改善。修改方法是在配置文件里设置或者直接执行ALTER SYSTEM SET timescaledb.max_background_workers 16;另外时序数据表中不要随便加大量索引。很多新手为了查询方便给 value、point_name 单独建索引结果写入性能直线下降。点数多的时候把 point_name 和 ts 作为复合索引就够了value 主要通过聚合视图来统计不需要单列索引。4.5 安全与权限管理上容易忽略的三个点OpenRig 部署在公网服务器上时安全是不能忽略的。我给你列三个最容易被忽略的点都是踩过的坑。第一EMQX 默认 Dashboard 端口和管理员账号必须改。默认账号是 admin/public很多人部署完懒得改结果服务器被抓进去挖矿。第二MQTT 不启用 TLS 的时候用户名密码都是明文传输等于裸奔。花钱买证书也行用自签发证书也行总之不能裸着跑公网。第三数据库端口千万不要直接暴露到公网Grafana 连数据库通过 Docker 内网网络就行公网只需要放行 1883 和 443 这两个端口。如果 OpenRig 要支持多个客户或部门查看数据可以在 EMQX 里做 ACL 控制每个设备账号只允许订阅以自己站点 ID 开头的主题。Grafana 侧对应配置 Viewer 角色只给只读权限防止有人误删面板或修改报警规则。5. 踩坑心得与后续扩展建议OpenRig 这套平台我从单个站点测试一直做到跨区域多站点部署最大的体会是技术选型从来不是越复杂越好反而是把数据模型和时间戳这些基础设计定了后面才不会翻车。刚开始我图省事直接在服务端用接收时间作为数据时间结果断网补传后一片混乱后来才明白设备端时间戳是可信的根本。另一个值得说的经验是OpenRig 不要一开始就把所有设备都接入。先选一台运行稳定、故障率高的设备做试点把采集、存储、看板、报警全链路跑通再逐步扩展到更多站点。这样同事和领导能看到实际效果后期推广阻力会小很多。如果一开始铺开几十台设备中途出现一堆协议问题很容易把项目做黄。后续扩展可以考虑的方向也很多。我现在正在做的是把采集到的历史数据接入一个简单的机器学习模型尝试对轴承温度做趋势预测。因为 OpenRig 的数据接口是标准 SQL算法团队可以直接从 TimescaleDB 里取数不需要额外整理数据。另一个方向是给边缘网关增加本地闭环控制比如发现设备振动超标时网关直接发送停机指令。这需要非常谨慎但 OpenRig 的指令通道已经预留好后面做出来也只是时间问题。最后再分享一个小技巧给所有现场网关都加上远程管理入口例如搭建一个轻量的 WebSSH 服务方便运维时直接登录网关查看日志。我一开始没做每次现场出问题都要跑一趟机房后来加了这个入口排查效率明显提升。OpenRig 这样的开放平台只有让自己的维护过程也“开放”起来才能真的省心。