AI 编程助手能否读懂PLC 程序——一次多工站装配线的逆向分析实验写在前面本文是《西门子PLC程序架构实战多工站自动装配线》的姊妹篇。上篇从作者视角讲解了程序架构与 IO 编号体系的设计思路本篇换个角度——如果只给 AI 一个项目文件夹让它自己分析能得出什么结论一、实验动机上篇文章写完以后我产生了一个想法之前借助 WorkBuddy 整理架构本质上是**“人先理解AI 后整理”**——我先描述程序长什么样它再帮我归纳成文。那如果反过来呢我把整个 TIA Portal 项目文件夹直接交给 AI不提供任何设计思路它能自己看懂这套程序吗于是我做了一个实验。输入项目目录343 个文件包含二进制 PLC 程序块.cnk、156 个 QML 画面文件、GSDML 设备描述、硬件在线检测日志HardwareDetectionLiveList.xml、运动控制缓存等。指令两个字——「分析」。二、实验结果AI 独立完成了什么在没有人工提示的情况下AI 给出了以下分析结论工作内容依赖的文件从 40 个 PROFINET 节点中识别出 10 台 KUKA KRC4、19 轴 V90 PN、10 个 XB6 IO 站HardwareDetectionLiveList.xml GSDML推断出 IP 地址按工站十位段分段的规划策略设备 IP 分布规律从 156 个 QML 文件中归纳出 S/0~S/3 四画面组架构总览/参数/监控/诊断目录结构 文件内容推断 PLC 程序的 OB/FB/FC/DB 层级关系硬件拓扑 → 程序结构推理生成量化评分81 分及优化建议多维度加权评估这让我很意外。重点是整个过程我没有提供任何程序架构信息——AI 完全是从文件中逆向分析出结论的。三、AI 是怎么做到的——从文件解析到架构推理3.1 第一步解析硬件配置 XMLTIA Portal 项目中有一个容易被忽略的文件HardwareDetectionLiveList.xml它是上线后硬件检测的快照。AI 读取后会解析每个 PROFINET 节点NodeIPAddress192.168.10.15/IPAddressVendorID0x19B/VendorID!-- KUKA --DeviceID0x300/DeviceID!-- KRC4 --NameOfStationkrc4-u01r1/NameOfStation/Node关键不只是看到标签值而是理解语义VendorID0x19B→ 识别为 KUKA Roboter GmbHDeviceID0x300→ 识别为 KRC4 控制器.10~.15地址段 → 推断为工站 1 设备区通过这个文件AI 还原出了完整的设备列表。这是在 TIA Portal 不开源的情况下为数不多能透视硬件规模的方式。3.2 第二步读取 GSDML 理解设备能力KUKA KRC4 → 输入 79 字节 / 输出 59 字节 V90 PN → 标准 105 报文工艺轴 XB6-PN → 分布式 IO 模块AI 解析 GSDML 后不仅能识别设备型号还能读取 IO 数据块的大小。基于此推断出 PLC 需要为 10 台机器人分配IB1000-IB4399的地址空间做数据映射——这与上篇文章我实际设计的地址范围完全吻合。3.3 第三步聚类 QML 文件还原 HMI 架构TIA Portal 的 HMI 画面以 QML 格式存储AI 的处理方式是按文件路径聚类 → 发现S/0、S/1、S/2、S/3四个画面组按文件大小排序 → 定位超大界面84KB含 200 控件标记为需关注按命名模式分类 → 识别 P 类页面、D 类对话框、T 类模板统计模板复用率 → 14 个 T 类模板支撑 119 个页面复用率 80%这就意味着不需要打开 TIA Portal也能评估 HMI 的架构质量。3.4 第四步基于硬件拓扑推断 PLC 程序结构这是最核心的一步——AI 不是简单地解析文件而是基于硬件拓扑做工程推理10台 KUKA KRC4 (同 VendorID DeviceID) → 归纳为同一类设备 → 推断 PLC 端用 1 个 FB10 个背景 DB 实例化 19轴 V90 PN (同 VendorID0x2A DeviceID0x51A) → 归纳为同一类设备 → 推断 PLC 端用 1 个 FB19 个背景 DB 实例化 10站 XB6 (同型号) → 同上逻辑1 个 FB 10 个 DB这套推理逻辑的核心是同型号设备在规范的 PLC 程序中必然对应同一个功能块的多实例化。AI 不需要看到源码通过设备型号的聚类就能判断程序复用策略。3.5 推断结果 vs 真实设计的对比验证做完分析后我拿 AI 的推断结论和我的实际设计做了逐项对比推断项AI 结论实际设计吻合度双机器人协作站U03, U04, U10U03, U04, U10100%FB 编号分段System/Axis/Valve/Robot/OtherSystem(6000)/Axis(6010)/Valve(6020)/Robot(6030)/Other(6050)方向正确IO 三层寻址本站IO / 机器人 / 伺服本站IO / 机器人 / 伺服轴100%IP 十位段策略每工站独占一个十位段.10~.19, .20~.29 …100%HMI 四屏架构总览/参数/监控/诊断S0 总览/S1 参数/S2 监控/S3 诊断100%5 个核心推断中4 个完全吻合1 个方向正确。所有分析都在未打开 TIA Portal 的情况下完成。四、AI 能读什么读不了什么这个问题需要诚实地回答——不能夸大也不能贬低。能直接解析的文件文件类型内容分析价值XML 硬件日志在线设备列表含 IP、VendorID、DeviceID、设备名还原设备拓扑GSDML 设备描述PROFINET 设备的 IO 模块、数据长度、诊断能力理解设备接口QML 界面文件HMI 画面的控件树含命名、大小、层级关系分析 HMI 架构运动控制缓存确认使用标准 Motion Control 还是自研算法判断工程规范性读不了的内容文件类型原因.cnk程序块OB/FC/FB/DB西门子私有二进制格式.ap数据库TIA Portal 内部封闭格式.sdf安全文件加密存储这是一个客观限制——西门子 PLC 程序的源码只有 TIA Portal 本身能打开任何外部工具都一样。但通过边缘文件反推核心架构的策略可以在不打开 TIA Portal 的情况下获得架构级理解。就像通过户型图和外墙材料推断建筑的结构设计——虽看不到钢筋排布但主体判断是可靠的。五、一个值得关注的思路逆向验证工作流这次实验让我意识到一种新的工作方式。结合上篇 WorkBuddy 的体验形成了一个闭环人工设计程序架构 → AI 辅助整理文档 → 项目文件归档 → AI 逆向分析验证 ↓ 吻合度高 → 设计质量确认 吻合度低 → 发现问题返工这个闭环的意义在于让 AI 从不同角度审查同一套程序。上篇 WorkBuddy 是顺着设计思路走——我说什么它整理什么本篇的 AI 是抛开设计思路走——只认文件不看人两种视角互相印证能暴露设计文档和实际实现之间的差异。比如本项目中AI 正确推断了硬件拓扑、IO 规划、HMI 架构但在 FB 编号的具体号段上只能判断分段方向而无法确定具体数值6000/6010/6020 等。这恰恰说明仅靠文件快照分析架构层面的判断是高置信度的细节层面的判断需要结合源码。六、延伸思考这种能力的实际价值在哪抛开实验性质这种只看文件就能分析程序的能力在真实的工业自动化场景中有几个落地点场景一接手遗留项目做过技改的同行都遇到过一个情况——甲方给的 PLC 程序是黑盒要么没有文档要么文档和实际程序对不上。这时如果能先跑一遍文件分析拿到设备清单、IO 映射关系、架构评估再决定要不要投入时间逐块阅读效率会高很多。场景二多方案对比评审业主招标时通常会收到多家集成商的方案。除了看报价和硬件清单程序架构的设计水平其实更影响后期运维成本。通过统一的分析维度模块化程度、复用率、扩展性做量化评估比凭经验判断更客观。场景三新人快速上手一个 10 工站、40 节点的项目新人要看懂程序架构通常需要数天。如果能先生成一份架构速览标注出关键功能块的定位和设备映射关系学习曲线会平缓很多。七、本次实验的局限与改进方向诚实地讲这次实验也有明显不足PLC 程序是推理出来的不是读取出来的。OB/FB/FC/DB 的具体逻辑、变量名、注释质量完全无法评估。要从推理升级到实证唯一的办法是在 TIA Portal 中导出源码为 SCL 文本再让 AI 阅读。推断结论需要人工验证。本次 5 个核心推断的吻合率较高很大程度上是因为我自己就是程序的设计者可以逐项对照。如果分析的是一个完全陌生的项目AI 给出的推断需要有人能验证。网络拓扑、安全配置、报警文本等更细节的内容未覆盖这些也需要源码导出后才能分析。下一步值得尝试的方向将 PLC 源码导出后让 AI 直接阅读 SCL 代码进行变量命名规范审计、状态机逻辑检查、死代码检测等更深层的分析。八、两篇文章的关系上篇本篇方法人带 AI先描述设计AI 辅助整理AI 自主只给文件AI 独立分析内容FB 编号体系、IO 规划、画面编号规则从文件逆向推导出上述架构本质设计思路的文档化设计思路的可验证性两篇合在一起的意义在于自动化程序不仅要设计得好还要经得起审查。如果一个项目让 AI 和人都能独立得出相似的架构结论说明设计的逻辑是自洽的、可追溯的。项目来源遥控器组装多工站自动装配线邯郸控制平台西门子 S7-1514SP-2 PN KTP900 Basic PN × 4 V90 PN × 19 KUKA KRC4 × 10项目规模10 工站、10 台机器人、19 轴伺服、40 PROFINET 节点标签#西门子PLC #自动化架构 #AI编程 #项目评估 #逆向工程系列文章 上篇西门子PLC程序架构实战——程序架构 IO编号规划综合评估 本篇AI 编程助手能否读懂PLC 程序——逆向分析实验记录