工业机器人监控系统架构演进：从组态到容器化部署

半夜两点手机突然狂震，车间一台六轴机器人报伺服过载，我爬起来打开电脑，不到三十秒定位到是J2轴电流峰值异常，顺手把前后五分钟的扭矩曲线调出来发给值班电工，电话里跟他说先查减速机。从接到报警到给出判断，全程没离开被窝。放在十年前，同样的故障我得先跑到现场，打开工控机，翻半天历史报表，才有可能猜个大概。

做机器人监控系统这块，我前前后后折腾了差不多十年，从最开始用组态软件凑合，到现在整个监控平台跑在容器集群上，踩过的坑比写过的代码多得多。这篇就从头到尾梳理一下，这套系统到底是怎么一步一步演进过来的，中间踩了哪些坑、做了哪些关键决策，以及如果你现在要从零搭一套，哪些东西可以直接抄作业。

1. 最早那套系统：组态软件加轮询，能用但很勉强

先说结论：第一代监控系统压根算不上“系统”，就是一台工控机挂着组态软件，配上数据库，把机器人的IO信号和几个关键报警拉出来看。

1.1 当时的硬件环境与机器人通信方式

那时候车间里主要是六轴工业机器人，控制器五花八门，有日系的、有欧系的，也有国产刚起步的。每台机器人都带一个控制柜，控制柜上一般有以太网口或者串口，往外吐数据的方式也各不一样。日系老款很多走Host Link协议，欧系喜欢走Profinet或者DeviceNet，国产的倒是一上来就以太网为主。

当时最省事的做法是给每台机器人装一块IO板卡，把机器人控制器里的数字量输出映射到IO板卡上，比如“运行中”“报警”“急停触发”这些信号。组态软件跑在工控机上，按几百毫秒的周期去轮询IO板卡，把状态刷新到画面上。画面做得也简单，一个车间平面图，每台机器人对应一个小图标，正常是绿的，报警变红。

这套方案的好处是便宜、快，一个电工配合一个软件工程师，两三天就能上线。坏处也很明显，你只能看到开关量，看不到伺服电流、扭矩、位置偏差这些真正有用的过程数据。想查一下机器人某段轨迹的实时扭矩，根本没戏。

1.2 数据全靠数据库硬扛

当时为了留历史数据，我直接在工控机上装了一个关系型数据库。采集程序每秒读一次IO状态，有变化就写一条记录，没变化就隔几秒写一条心跳。一台机器人一天大概能产生几万条记录，车间里几十台机器人，数据库很快就吃不消了。尤其到月底导出报表的时候，一条SQL查出来几十万行，Excel直接卡死。

现在回头看，那时候的架构最大的问题不是慢，而是设计思路本身错了。监控系统不应该把重点放在“存”上，而应该放在“流”上，数据应该像水流一样持续流动，需要的时候才落库。我用关系型数据库去存时序数据，本质上是拿一个不适合的工具去做一件它本来就不擅长的事。

当时也有个好处，就是通过这套蹩脚的系统，我把车间里每台机器人的脾气摸了个遍。哪台机器人周末容易出报警，哪台机器人夏天散热不行，哪台机器人晚上十点以后经常丢信号，这些规律后来都成了我做第二套系统时的需求来源。

2. 从单体到服务化：为什么必须拆

第二代系统的起点，是车间扩产，机器人从几十台涨到上百台，同时新上的机器人开始支持OPC UA这类现代通信协议。我意识到如果还按老一套去搞，光采集程序就得写死，更别提后续要做告警、做报表、做数据分析。

2.1 采集层独立：机器人数据先统一收口

第二代改造的第一步，是把“采集”这