上个月去一个做食品包装的客户那边出差，他们车间有两台从日本进口的枕式包装机，买的时候花了六十多万。
机器倒是挺好使，每分钟能跑120包。但问题来了——车间主任想把这台设备的运行数据接到他们的MES系统里，方便看产量、算OEE。结果打开电柜一看，PLC是日本的一个小众品牌，既不是三菱也不是欧姆龙，通讯口就一个RS485串口。问厂家要协议，那边回复说这是商业机密，不对外公开。
说白了就是不想让你碰他们的数据，后续搞什么都得找他们原厂。那套数据采集方案报价五万八，还不包括PLC程序修改。
车间主任直接骂娘了，转头问我：”老刘，能不能帮我破解一下这个协议？自己能搞定的话，这顿饭我请三个月。”
思路：不碰PLC程序，只抓通讯数据
直接破解PLC程序是不现实的，而且可能会把设备弄宕机，影响生产。但换个思路——PLC跟触摸屏之间走的RS485通讯，我只要在中间挂一个”窃听”设备，把通讯报文抓下来，分析出规律，不就能模拟上位机去读数据了吗？
这个思路在工控圈子里叫”协议窃听”或”被动侦听”，就是不干涉原有设备，纯靠分析通讯信号来反推协议格式。
需要的工具也不复杂：一个USB转RS485的转换器（三十多块钱），一个串口监听软件，再加一个逻辑分析仪（我用的是几年前买的Saleae逻辑分析仪，十几块钱的国产版也够用）。关键的第3样东西——大模型。我用的Claude和Kimi两个，一个负责分析协议规律，一个负责写解析代码。
第一步：搭监听环境
RS485是差分信号，用A/B两根线传输。我把USB转485的A线接到PLC侧的A端，B线接到B端，注意不能接反了。然后打开串口调试软件，设置波特率9600、8数据位、1停止位、无校验——这是大多数日系设备的标准配置。
但说实话，试了十几分钟什么都抓不到。可能波特率不对，也可能是校验方式不同。
这时候就得让逻辑分析仪上场了。我把逻辑分析仪的通道0夹在RS485的A线上，通道1夹在B线上，然后让触摸屏和PLC正常通讯。逻辑分析仪把原始波形抓下来，一看——这波特率根本就不是9600，而是19200，而且用的是偶校验。
很多兄弟可能不太清楚，RS485的波形在逻辑分析仪上看其实是一串高低电平的脉冲。一个位的时间长度就是波特率的倒数。我在逻辑分析仪上量了一下，一个位大概52微秒，那波特率就是1/0.000052≈19200。这种土办法虽然笨，但在不知道参数的时候特别好使。
第二步：抓报文，找规律
波特率确定之后，重新用串口软件监听。这次数据刷刷地出来了，全是十六进制报文。PLC不停地往外发数据，触摸屏也不停地回复。但问题来了——这些报文是什么意思？一堆16进制的字节，没有任何注释。
我录了大约两分钟的通讯数据，大概有2000多条报文。然后把数据扔给大模型分析。
这里有个技巧：不要直接把原始数据全扔给AI，它会懵。我先把数据按时间排列，标注出哪些报文是PLC发的（主机），哪些是触摸屏回的（从机）。然后告诉AI：这是RS485通讯的原始报文数据，主站是PLC，从站是触摸屏，我需要你分析协议格式、帧头、数据域、校验方式。
Claude分析了一下，发现了一个规律：报文以固定字节5A 01开头，长度固定为10字节，最后两个字节是CRC16校验。而且我注意到，当设备产量从0变成1时，报文中有一个字节从00变成了01。当包装速度发生变化时，另一个字节也跟着变了。这就是我们需要的”映射关系”。
说实话，如果没有大模型辅助，纯靠人工去翻这2000多条报文，找出规律至少要两三天。但AI几分钟就给我画好了一张对照表：哪个字节对应产量，哪个字节对应速度，哪个字节对应温度——全给我标出来了。
第三步：验证和踩坑
AI分析出来了之后，我用Python写了个简单的协议解析脚本，把抓到的历史数据全部跑了一遍，验证AI标注的映射关系是否正确。结果第一轮跑了之后发现问题了——有两组字节的映射关系搞反了。
比如AI认为第5个字节是当前包装速度，第6个字节是累计产量。但我对照车间的实际数据一看，那台包装机实际跑了1500包，报文里显示第6个字节是0x05DC（十进制1500），而第5字节是0x0064（十进制100包/分钟），跟现场观察一致——所以应该是第5字节是产量，第6字节是速度。AI把顺序搞反了。
所以提醒各位：AI的分析只是一个基础参考，最终还是需要人工去验证。
第四步：写上位机驱动
协议分析清楚之后，我用C#写了一个Modbus兼容驱动，把非标协议包装成了一个标准的Modbus TCP服务器。这样一来，上层的MES系统、SCADA都不用改任何配置，直接用Modbus TCP去读就行了。我在中间接了一块”黑盒”——一块树莓派Zero W，跑着这个协议转换程序。
树莓派通过USB转485跟包装机的PLC通讯，解析出数据后，再通过Modbus TCP协议往上面的MES系统转发。整个方案下来，硬件成本不到300块钱（树莓派200+USB转485线30+外壳和电源70），软件开发时间是两个晚上。
跑了一周之后车间主任给我发微信：数据全部正常，MES上能看到每小时的包数、设备运行状态、故障代码，跟原厂的方案一模一样。省了那五万八，他请我吃了三顿饭。
这套方法的适用范围
通过这件事我总结了一下，用AI+逻辑分析仪解析非标协议，适用于以下几种场景：
- 设备PLC有明确的RS232/RS485通讯口，能抓到原始报文
- 协议是明文的或简单的自定义协议，没有加密——加密了基本不用想
- 通讯频率不高，每秒几十到几百条报文的量级，数据量不大
- 对外只有读操作，不需要反向写入控制——写入风险太大，不建议逆向写指令
如果你的设备用的是加密协议或者Profinet/EtherCAT这种实时工业以太网，那逻辑分析仪就搞不定了，需要的设备和时间成本会高很多。
大模型在这件事里到底起了多大作用
说实话，如果没有AI的帮助，单靠我自己去手动分析2000多条十六进制报文，光一个个字节对照着看就要花掉整整一天。而且人眼很容易疲劳，看久了就串行。AI在这方面确实强——它不累，能一次性把所有报文对比完，找出数据变化的规律。
但是，AI也有它的局限。它分析出来的”结论”有时候是错的或者张冠李戴的。比如上面说的把产量和速度搞反了，还有一次它把CRC校验的起算位置都推错了，导致我写的解析代码一直在报CRC错误，查了半小时才发现是AI给的校验规则不对。
我的个人建议是：把AI当一个”聪明但偶尔会犯错的实习生”来用。它帮你完成80%的重复性分析工作，但最终的验证和确认，还是得靠你自己的工控经验。
一点感想
做我们工控这一行的，经常碰到设备厂商搞”设备锁定”——协议不公开、上位机只能买他们的、配件只能用原厂的。以前遇到这种情况，要么花高价买原厂方案，要么硬着头皮换整套设备。
但现在有了大模型这个工具，至少协议分析这一块的门槛降低了很多。不是说你不需要懂通讯原理——你还是得知道RS485怎么接线、波特率什么概念、CRC是什么——但AI帮你把最枯燥的”猜字节意义”这一步大大简化了。
你们有没有也遇到过进口设备协议不公开的烦心事？是怎么解决的？欢迎在评论区聊聊。