郦小号从2015年误打误撞开始做机器人监控，到现在整整十年。我见过产线里二十多台焊接机器人靠一台工控机跑组态软件的日子，也经历了把监控系统拆成微服务、上容器、接时序数据库、训练预测模型的全过程。这期间踩过的坑、推倒重来的架构、被数据搞到怀疑人生的夜晚，积累下来的经验远比一套系统本身值钱。很多做设备或者搞智能制造的朋友后台问我，机器人监控系统到底该怎么做、怎么演进，今天就拿我这十年的实际经历，把路线、关键选型、实操细节和那些保命的避坑经验一次讲清楚。
1. 十年路线图：机器人监控系统是怎么一步步走到今天的
1.1 2015年前后：单体软件加本地组态，能看没法管
回到2015年，大部分工厂里的机器人监控基本处于“原始社会”。当时我们焊接车间有二十多台机器人，每台控制器上都有一组I/O模块，通过RS485串口连到一台工控机上。工控机里装的是组态王、WinCC这一类的组态软件，画面上能实时显示伺服电流、速度、报警代码，就算很先进的方案了。
这套模式的问题非常明显。首先是采集不稳定，RS485走的是轮询机制，点位一多，一圈扫下来往往要好几秒，画面上的数值经常卡顿。其次是数据基本不落库，要么不存，要么扔进一个Access或者小型的SQL Server，两三个月后数据库膨胀到几百兆，查询一下慢到没法用。最要命的是断线恢复能力几乎为零——只要工控机死机或者串口线松动，监控就彻底失灵，必须有人到现场重启。
那个阶段做监控，本质上是在“看设备”，而且是近距离地看。车间主任能通过屏幕知道机器人现在有没有报警，但没法回答“上个月哪台设备故障最多”“这台机器人的伺服电流是慢慢劣化还是突然恶化”这类问题。因为数据没有真正被管理起来。
1.2 2018年转折：中心化平台加Web，数据开始流动
2017年底到2018年，工厂在做数字化改造，监控系统第一次迎来真正意义上的架构升级。这时候机器人控制器基本都带了以太网口，支持的协议也从Modbus RTU升级到了Modbus TCP，有的甚至开始支持OPC DA。我们当时选了一台服务器，装了Kepware做OPC Server，把所有机器人的数据统一采集上来，再通过一个自研的Web组态界面展示给车间和管理层看。
这个阶段有两点突破很关键。第一是数据开始集中了，SQL Server作为历史库，支撑了最简单的报表功能，终于能查到“某台设备某天的开机时长、报警次数、平均电流”。第二是Web化，不再依赖工控机装客户端，管理人员在自己的电脑上打开浏览器就能看到产线状态，这就打破了监控的地域限制。
但问题也随之而来。OPC DA这套东西极度依赖Windows的COM/DCOM技术，部署和维护都是噩梦。端口要开一堆，权限要配来配去，稍微有个防火墙策略变动，客户端就连不上服务器。而且这个阶段的架构还是典型的单体应用——采集、存储、展示全在一台服务器上，一旦数据量上来，查询接口直接卡死。
1.3 2021年重构：云边协同加容器化，监控系统成了平台
到了2021年，产线规模翻了一倍，控制器型号也越来越杂，有焊接机器人、搬运机器人、视觉引导的AGV，原来那套中心化架构彻底撑不住了。这时候我们做了一次比较大的重构，思路是分层：边缘网关负责和机器人通信，采集数据、解析协议、本地缓存；消息中间件负责数据管道；时序数据库负责存储；Grafana负责可视化。所有服务都容器化，用Kubernetes编排调度。
这次重构让我对监控系统的认知发生了根本变化——它不再是一个软件，而是一个平台。机器人监控不只是画面上显示几个跳动的数字，而是要把实时数据、历史趋势、报警管理、运维工单全部打通。边缘网关在那个阶段开始发挥关键作用，很多脏活累活都在离设备最近的这一层消化掉，服务器端只处理干净、标准化的数据。
1.4 2025年现状：预测性维护和AI诊断走进产线
2024到2025年，最明显的变化是AI开始“上位”了。监控系统不再满足于“坏了报警”，而是开始尝试“提前告诉你可能要坏”。我们接入了机器人关节电机、减速机、焊枪的振动和电流数据，在边缘侧做特征提取，把时域和频域特征打包上传，在平台上训练异常检测和寿命预测模型。
当然，说实话，现在数字孪生和AI诊断在产线上还没有到完全成熟的地步，很多项目还是试点性质。但趋势已经非常明确：监控系统的价值正在从“过程和状态的透明化”向“决策的智能化”转移。十年下来，整个行业基本完成了从设备监控到数据平台再到智能诊断的三级跳。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 架构选型的几个关键决策：协议、链路、存储
2.1 通信协议为什么最后都收敛到OPC UA
做机器人监控，第一件事就是选通信协议。早期代码里全是Modbus TCP的寄存器地址表，后来发现这条路走不长。Modbus的问题在于它本质上只是“给你一堆寄存器地址”，数据代表什么含义、单位是什么、量程是多少，全靠工程师自己在文档里记。设备多了以后，笔记一乱，对接过程就变成灾难。
OPC UA能成为现在工业通信的事实标准，核心在于它解决了三件事：跨平台、安全性、信息模型。跨平台意味着不再依赖Windows COM/DCOM，Linux网关也能直接读数据；安全性内置证书加密和用户认证，不用自己折腾防火墙和权限；信息模型则让数据自描述，点位除了数值还带单位、质量戳、工程值范围，下游系统看到数据就知道含义。
我们现在的选型原则非常简单：新设备必须支持OPC UA，旧设备走Modbus TCP能换网关就换网关，实在不行才保留私有协议。ABB、KUKA、FANUC这些主流品牌的新型控制器基本都原生支持OPC UA，对接起来半小时完成，和以前翻手册写Modbus地址相比节省了太多时间。
2.2 数据链路的三个环节怎么分工
一套完整的机器人监控系统可以拆成三个环节：采集、传输、存储展示。每个环节都有各自的定位和选型逻辑，千万别混为一谈。
采集层，也就是边缘网关这一层，负责和设备通信、协议解析、数据清洗。这个环节的关键是要离线可用。产线网络抖动、服务器重启都是常态，网关必须在本地做缓冲。我们的做法是在网关里内置一个本地队列，数据写不上去就落本地文件，网络恢复后按顺序回补。这个机制的可靠性决定了整套系统的数据完整率，是压倒一切的核心需求。
传输层，我们内部选的是Kafka，外部接入用MQTT。Kafka在这条链路里的角色是“智能管道”，高吞吐、可回溯、支持多个下游消费者。机器人数据的特点是点位多、写入频繁、峰值明显，Kafka能轻松扛住每秒几万条的消息写入，而且消费者可以按需重新消费数据，这在排查问题或者重算指标时非常有用。
存储展示层的关键是存储引擎选型。这一层必须和上层应用解耦，我们的经验是先把数据接入Kafka，让下游自己去消费写库，这样即使存储层挂了，采集层和数据管道里的数据也不会丢，等存储恢复后再从Kafka消费历史消息，实现了真正的“数据零丢失”。
2.3 存储选型踩坑：关系库换时序库的必然性
我在SQL Server上栽过大跟头。2019年我们直接用关系库存历史数据，20多台机器人、每台200个点位、5秒采集一次，算下来一天大概是6000多万条记录。一开始还算勉强，一个月后单表超过20亿行，查询一个时间段的趋势要花二十几秒，索引重建要跑一个晚上。从那以后我就坚定了一个想法：工业监控的数据必须用时序数据库。
现在主流的选择无非是InfluxDB、TimescaleDB、TDengine或者IoTDB。我们用最多的是InfluxDB，理由是生态成熟、Grafana集成顺滑、学习曲线平缓。TimescaleDB本质是PostgreSQL插件，适合团队本来就很熟SQL的场景；TDengine和IoTDB在工业场景的压缩率和超级表设计也有优势，但团队需要额外学习成本。
存储量级可以算一笔账：假设30台机器人，每台500个实时点位，5秒一个采样点，就是每秒3000次写入，一天下来大概2.6亿个数据点。按平均每条30字节算，一天原始数据7.8GB左右，时序库压缩后大概1.5到2GB。这个量级必须靠时序库，关系库不管怎么优化都扛不住。另外一定要设计保留策略，后面我会重点讲这个坑。
3. 实操落地的细节：点位表、采样频率、告警规则、可视化
3.1 点位表定了，系统上限就定了
很多团队做监控系统，上来就写采集程序，写了一半才发现点位含义不清、命名混乱，最后只能推翻重来。点位表是监控系统的“宪法”，是后续所有环节的基础。点位表管理得好，整个系统的上限就高；管理混乱，后面所有功能都会绊手绊脚。
我们的命名规范是“车间-产线-工位-设备-部件-参数”，举个例子：W1-L2-ST04-RB01-J1-CUR，拆开就是一号车间、二号线、四号工位、机器人一号、第一轴、电流。每一个点位必须记录五类信息：点位名称、单位、数据类型、采集方式、报警上下限。此外还要有存储策略，哪些点是秒级存储、哪些点分钟级存储、哪些点只做实时展示不存储，这些都要提前定清楚。
点位表不只服务于采集程序。后面做报警规则、做报表统计、做机器学习特征工程，全部都是围绕点位表展开的。早期我们吃过亏，一个“电流”在不同机器人上叫法都不一样，有的叫I，有的叫Current，有的叫DianLiu，做数据分析时写SQL写到崩溃。统一命名和元数据管理，前期多花一天，后期能省一个月。
3.2 采样周期别迷信“越快越好”
很多工程师一上来就把所有点位都设成1秒采集一次，理由是“数据越多越安全”。这是最典型的思维误区。采样周期要看被测量本身的物理特性，温度、压力这类慢变量，5秒甚至10秒采一次完全够用；而振动、电流波形这类动态信号，1秒采一次等于没采，因为有用信息都在毫秒甚至微秒级别，必须用专门的采集卡或传感器来采样。
正确的做法是分级设计采样策略。A类设备的关键参数，比如核心伺服电机的电流和温度、减速机振动，可以做到短周期高频采集，甚至走边缘计算的触发式采集；B类设备的一般运行状态，5秒到10秒一次就足够；纯粹的IO状态量，比如启动、停止、急停，应该走事件触发机制，状态一变立刻上报，而不是靠周期轮询。采集频率设计完以后，每个点位都要明确写入点位表，实施阶段不许临时乱改。
3.3 告警规则怎么定才能既灵敏又不误报
告警是监控系统最核心的功能，也是最容易做崩的功能。很多项目上线第一天就触发几百条告警，值班人员连看都不想看，最后彻底变成“狼来了”的系统。问题的根源是告警规则只做了“阈值判断”，而工业现场数据天然有波动和抖动，一个值在临界点附近来回穿越，系统就会疯狂报警。
我们的告警规则至少要包含三个维度：阈值、持续时间、变化率。举个例子，机器人伺服电流，瞬时超过额定值80%可能是焊接瞬间的冲击，是正常现象，但如果持续超过3秒，那就是过载预警；温度还没到上限时，如果5分钟内上升超过10摄氏度，这本身就是异常趋势，比单向阈值更有预警价值。所以规则设计上要支持“阈值+持续时长”的组合，条件满足并保持一段时间才触发，另外要有恢复条件，故障复位后自动回到正常状态。
告警还需要分级。我们的分法是四级：提示、警告、严重、停机。提示类只记录不推送；警告类推送给班组长；严重类推送给设备工程师；停机类除了推送还必须联动工单系统，自动创建维修任务。分级不只是为了“推给谁”，更重要的是决定系统对告警的处理优先级和响应速度。
3.4 可视化层的实时刷新和物模型
可视化是监控系统最容易踩“形式主义”坑的地方。很多花了重金做的LED大屏、3D厂区图，对现场运维其实没什么帮助。值班人员真正需要的是三样东西：一眼能看到哪台设备报警了、快速查某个点位的趋势曲线、按时间段分析故障统计。至于大屏上那些花哨的动画效果，更多是给来访领导看的。
可视化架构上要注意实时机制。以前我们做过一版纯HTTP轮询的页面，每秒钟请求一次接口，结果并发一高接口直接被打死。后来改成WebSocket推送，服务端有数据变化才往前端推，压力小了一个数量级，页面响应也从秒级降到了毫秒级。另外，前端展示的每个指标，最好都和后端物模型的点位一一对应，不要在前端硬编码指标名称，否则点位调整后页面显示就乱套了。
按角色分层设计也是关键：车间主任看汇总大屏，OEE、故障率、产量；工程师看趋势分析和报警明细，要能自己选时间段、选参数做对比；维保人员看设备健康看板，聚焦当前有哪些告警、哪些设备需要保养。一个界面服务所有角色，最后一定谁都用得不舒服。
4. 十年里踩过最深的几个坑
4.1 数据断档：网络、程序、断电一个都不能漏
数据断档是监控系统最隐蔽也最难查的问题。现象很典型——曲线中间缺了一块，而且没有任何报错。排查顺序我们总结成了固定的套路：先看边缘网关和服务器之间的网络是否连通，再看网关程序的日志有没有异常，最后检查设备控制器侧有没有重启记录。
实际遇到过几次有意思的情况：一次是交换机的某个端口在数据量大的时候会自动降速，导致网关和服务器之间的长连接经常断开；还有一次是机器人控制柜的电源模块老化，设备偶尔瞬间重启，控制器上的OPC UA服务跟着掉线，但程序日志里完全看不出异常。后来我们学乖了，在网关本地加了SQLite队列，任何一条数据先写本地，ACK之后再删除，服务器恢复后网关按时间戳回补。这个机制上线后，数据断档率从每月十几次直接降到了接近零。每条数据都加设备侧时间戳，别依赖网关或者服务器打时间，这是保证数据可回溯的底线。
4.2 告警风暴是怎么把值班组逼疯的
有一年夏天，某台机器人伺服电机温度报警，一晚上发了6000多条消息，值班人员的手机直接卡死，第二天所有人都在抱怨。查下来原因是温度阈值设得只比正常工作值高5度，夏季车间温度一上升，温度在阈值附近反复横跳，系统每秒钟判一次“超限”，就一直在推消息。
这种告警风暴的本质是规则设计缺陷。后来我们从三个层面做加固：第一，所有阈值判断必须加持续时长，比如温度超过90度并保持10秒才告警；第二，加抑制间隔，同一个设备同一种告警在10分钟内只推送一次；第三，加聚合降噪，同一时间段同类型告警合并成一条“摘要”，比如“3号机器人伺服温度在14:20至14:35之间超限12次，峰值95度”。另外还有告警升级机制，告警持续30分钟未恢复，自动提升等级并通知上一级负责人，避免重要告警被静默处理。
4.3 时间戳错了，一切白搭
监控系统里时间戳是最容易被忽略、却影响全局的数据。我们踩过一个非常隐蔽的坑：网关采集数据时用的是设备本地时间，服务器入库时又把时间覆盖成了服务器时间，结果设备本地时钟漂移加上两班倒切换，趋势图上的曲线出现了大量“时间倒流”的现象。数据本身没丢，但时间错乱让整张图没法看。
排查这种问题特别痛苦，因为系统没有任何报错，纯粹是逻辑上的错乱。解决方案说起来很简单，做起来需要下决心：采集层一律使用设备侧的原始时间戳，网关和服务器在任何环节都不许二次赋时；所有设备、网关、服务器统一通过NTP对时，保证时间源一致。从那以后，我们再写任何采集程序，都默认第一行就明确定义“时间戳来源是设备侧，不可覆盖”。
4.4 存储膨胀：数据量增长超出预期的教训
时序数据库虽然能压数据，但不做保留策略同样会出事。InfluxDB上线那会儿我们只顾着写入，没配retention policy，结果一年攒了500多GB数据，查询速度肉眼可见地变慢。虽然时序库压缩率高，但监控数据本身增长太快，不设保留策略就是给自己埋雷。
正确的设计是分级降采样。原始秒级数据保留30天，因为是常规排障最常看的时间窗口；分钟级均值保留一年，用于月度分析和趋势观察；小时级均值长期保留，给管理层做报表和年度总结。数据过期后由数据库自动清理，不需要人肉干预。还有一点容易忽略：tag的基数不能无脑膨胀。我们一开始把设备ID和点位全部塞进tag，导致内存占用飙升，后来改成核心标签用tag，数值和属性放field，性能立刻提上来。监控系统上线半年后都会面临存储扩容的问题，提前规划好数据生命周期，能少花很多冤枉钱。
5. 演进真正的驱动力：技术红利加业务需求
5.1 开源生态把监控系统的门槛打了下来
回过头看这十年，开源生态对整个行业的影响是决定性的。2015年做一套机器人监控系统，组态软件授权费、数据库授权费、报表工具授权费，零零总总加起来是一笔不小的开销。现在Grafana免费、InfluxDB开源版够用、Kafka和K8s全是开源方案，一套系统在软件层面的成本几乎可以忽略不计，大头反而是实施和集成。
这说明监控系统的问题早就不再是“买不起软件”，而是“有没有人能把数据接进来、治理好、用起来”。开源生态带来的另一个变化是人才供给多了，熟悉Prometheus、Grafana、Kafka的开发者远比熟悉WinCC、组态王的年轻人多，招人、维护、迭代都容易很多。这也是我们后来坚定走向开源技术栈的核心原因。
5.2 业务需求变了：从能看、能管到能预测
技术演进只是表象，真正的驱动力是业务需求在一步步升级。最开始车间要的是“能看”，远程能看到设备状态就行；然后管理层要“能管”，要有OEE、故障率、停机时长这些管理指标；再往后设备部门要“能预测”，希望系统能提前判断哪台机器人快出问题了，好把维修安排在计划性停机窗口里，而不是让故障打断生产。
这种演进在具体指标上体现得很明显：2018年我们做报表，问的是“昨天停了几次机、停了多久”；2021年问的是“哪台设备的故障频次突然升高”；2025年问的是“这台减速机的健康度分数在下个月会不会跌破安全线”。每一个新问题的出现，都倒逼着架构在数据深度、算法能力、联动机制上往前迈一步。监控系统做到最后，本质上是在回答一层比一层更接近本质的设备和生产问题。
6. 给正在搞监控系统的人几条实在建议
6.1 先建模再写代码
我见过太多项目，一上来就直奔采集程序和页面开发，结果点位命名随手写、单位不统一、报警规则想到哪加到哪，三个月后系统变成了谁也维护不了的烂摊子。正确顺序一定是先建物模型，把设备、点位、单位、元数据、告警规则、存储策略全部定义清楚，评审通过后再开始写代码。建模阶段多花一周，开发阶段省下的时间至少是按月算的。
6.2 预留二十倍的扩展空间但别过度设计
监控系统扩展的速度永远比你想象得快。我们最开始规划30台机器人的容量，结果第二年就翻倍了。服务器CPU、内存、磁盘、数据库容量，最好按未来三到五倍甚至二十倍的规模去预留，反正硬件成本在下降，一次性到位比事后扩容体面得多。但架构上别过度设计，微服务、K8s、消息队列这些东西，设备数量少、点位不多的时候强行上，纯属自找麻烦——10台机器人以内的监控，一个边缘网关加一台服务器加一个时序库，完全够用。
6.3 边缘计算要清楚边界
边缘计算在这套架构里的定位，是做采集、解析、清洗、特征提取和断点缓存。别把大模型推理和长周期历史分析放到边缘层，边缘设备算力有限、存储有限，硬塞进去只会换来频繁卡死和故障。AI模型训练和复杂诊断就该放在云端或者机房服务器上，边缘负责提供高质量的数据。这个边界划清楚了，系统才能稳定。
十年经验浓缩下来其实就是一句话：监控系统永远是在“数据完整、稳定可靠、能用起来”这三个目标之间反复打磨。我们走过的弯路，希望后来者能少走一点。