AI 编程助手能否“读懂“PLC 程序？——一次多工站装配线的逆向分析实验-港品优选

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 第一步：解析硬件配置 XML

TIA Portal 项目中有一个容易被忽略的文件：HardwareDetectionLiveList.xml，它是上线后硬件检测的快照。AI 读取后会解析每个 PROFINET 节点：

<Node><IPAddress>192.168.10.15</IPAddress><VendorID>0x19B</VendorID><!-- KUKA --><DeviceID>0x300</DeviceID><!-- KRC4 --><NameOfStation>krc4-u01r1</NameOfStation></Node>

关键不只是"看到"标签值，而是理解语义：

VendorID=0x19B→ 识别为 KUKA Roboter GmbH
DeviceID=0x300→ 识别为 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 个 FB，10 个背景 DB 实例化 19轴 V90 PN (同 VendorID=0x2A + DeviceID=0x51A) → 归纳为同一类设备 → 推断 PLC 端用 1 个 FB，19 个背景 DB 实例化 10站 XB6 (同型号) → 同上逻辑，1 个 FB + 10 个 DB

这套推理逻辑的核心是：同型号设备在规范的 PLC 程序中必然对应同一个功能块的多实例化。AI 不需要看到源码，通过设备型号的聚类就能判断程序复用策略。

3.5 推断结果 vs 真实设计的对比验证

做完分析后，我拿 AI 的推断结论和我的实际设计做了逐项对比：

推断项	AI 结论	实际设计	吻合度
双机器人协作站	U03, U04, U10	U03, U04, U10	100%
FB 编号分段	System/Axis/Valve/Robot/Other	System(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 程序？——逆向分析实验记录

企业官网建设流程全解析