郦小号从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编排调度。
这次重构让我对监控系统的认知发生了根本变化——它不再是一个软件，而是一个平台。机器人监控不只是画面上显示几个跳动的数字，而是要把实时数据、历史趋势、报警管理、运维工单全部打通。边缘网关在那个阶段开始发挥关键作用，很多脏活累活都在离设备最近的这一层消化掉，服务器端只处理干净、标准化的数据。