1. 项目缘起当AI遇上PLC为什么“看不懂”成了最大的坎搞工业自动化的朋友大概率都有过这种体验手头有一堆TIA Portal里的梯形图、SCL代码、DB块和UDT想让AI帮忙分析一下逻辑、生成一段注释、或者排查一个互锁条件结果把代码贴过去AI给出的回答要么是“这段代码看起来是一个电机启动逻辑”要么是“建议检查变量定义”——全是正确的废话。问题出在哪不是AI不够聪明而是它根本“看不懂”PLC程序的结构。PLC程序和普通的高级语言代码有本质区别。一段Python脚本AI可以逐行理解变量作用域、函数调用关系、控制流但一段梯形图它的核心信息不在“文本”里而在网络之间的引用关系、变量在DB块中的偏移地址、FC/FB的调用层级、以及硬件组态与程序之间的映射。你把这些东西拍平成一段文本丢给AI就像把一张电路图撕成碎片再让电工去修——信息全在但结构没了。TIA Context这个项目的核心思路就是在AI和PLC程序之间架一层“语义中间层”。它不直接让AI去读原始代码而是先把TIA Portal项目里的程序结构、变量关系、调用链路提取出来构建成一个工业知识图谱再把这个图谱以AI能理解的方式喂给大模型。这样一来AI看到的不是一堆零散的指令而是一张有节点、有边、有属性的关系网络。这个项目适合谁如果你是在做PLC程序维护、产线改造、程序审查的工程师或者你在尝试用AI辅助PLC编程、做程序文档自动化、做故障知识库那这套思路值得仔细看看。它不要求你是AI专家但需要你对TIA Portal的项目结构有基本认知。2. 核心设计思路为什么是知识图谱而不是微调模型2.1 直接微调模型为什么走不通很多人第一反应是拿一堆PLC程序去微调一个大模型不就行了我试过这条路在工业场景下基本走不通原因有三个。第一数据量根本不够。一个中型产线项目的PLC程序可能就几千行大型项目也就几万行而且大量代码是重复的标准化逻辑。拿这点数据去微调模型学到的只是表面模式换个项目立刻失效。第二PLC程序的结构信息在文本化过程中会大量丢失。梯形图的并联分支、SCL里的结构体嵌套、DB块里的数组偏移这些信息在纯文本表示下很难保留完整的语义。微调模型学的是“文本到文本”的映射但PLC程序的核心是“结构到行为”的映射。第三工业场景对准确性要求极高。AI说错一句话在聊天场景里无所谓但在PLC程序分析里一个错误的互锁判断可能导致设备损坏甚至人身事故。微调模型的输出不可控无法满足工业场景的可靠性要求。2.2 知识图谱方案的核心优势TIA Context选择知识图谱作为中间层逻辑上非常清晰。知识图谱的本质是用节点和边来表示实体及其关系这恰好匹配PLC程序的结构特征。在PLC程序里实体包括变量DB块中的具体标签、功能块FB/FC、组织块OB、数据类型UDT、硬件设备IO模块、驱动器。关系包括变量被哪些网络读写、功能块被谁调用、数据类型被哪些变量实例化、硬件通道映射到哪个变量。把这些实体和关系提取出来就形成了一张程序语义图谱。AI在这张图谱上做推理比在原始代码文本上做推理要准确得多。比如你问“如果电机M1的启动条件不满足哪些输出会受影响”AI可以沿着图谱的边做多跳推理找到所有依赖M1状态的输出节点而不是靠猜。2.3 整体架构拆解整个TIA Context的架构可以分成四层我用一个实际项目的处理流程来说明。第一层项目解析层。从TIA Portal项目中提取原始数据。TIA Portal提供了Openness API可以通过C#脚本导出项目中的块、变量表、硬件组态信息。导出的格式通常是XML或SIMATIC ML格式。这一步的关键是完整提取所有交叉引用信息包括变量在哪个块的哪个网络被读写、块之间的调用关系、UDT的嵌套结构。第二层图谱构建层。把解析出来的结构化数据转换成图数据库中的节点和边。常用的图数据库有Neo4j、NebulaGraph轻量级场景也可以用NetworkX在内存中构建。节点类型包括Variable、Block、DataType、Device边类型包括READS、WRITES、CALLS、INSTANCE_OF、MAPS_TO。这一步的核心挑战是处理命名冲突和层级关系比如不同DB块里可能有同名变量需要通过完整路径来唯一标识。第三层语义增强层。给图谱节点补充语义信息。比如给变量节点添加注释、单位、量程、报警阈值给功能块节点添加功能描述、输入输出说明给设备节点添加型号、厂商、通信协议。这些信息一部分来自TIA Portal项目本身一部分来自外部维护的知识库。这一步是让AI能“理解”而不只是“看到”的关键。第四层AI交互层。把用户的自然语言问题转换成图谱查询再把查询结果转换成自然语言回答。这里可以用LLM做意图识别和查询生成但核心的推理逻辑在图谱上执行LLM只负责语言层面的转换。这样做的好处是推理过程可解释、可验证不会出现LLM“编造”关系的情况。3. 核心细节解析从TIA Portal到知识图谱的完整链路3.1 TIA Openness API的关键用法TIA Portal的Openness API是整套方案的起点。它允许外部程序通过C#与TIA Portal实例通信读取项目结构。我实际用下来有几个关键点必须注意。首先Openness的版本必须与TIA Portal版本匹配。TIA V16、V17、V18、V19各有对应的Openness DLL混用会直接报错。如果你同时维护多个版本的项目建议在虚拟机里分别装对应版本的TIA和Openness避免环境冲突。其次导出块内容时建议用Simatic ML格式而不是纯文本。Simatic ML是XML格式保留了完整的结构信息包括网络注释、变量注释、跳转标签、互锁条件。纯文本导出会丢失这些信息后续图谱构建时还得靠正则去补非常痛苦。下面是一段导出所有块的C#核心代码逻辑我做了简化保留关键步骤// 连接到运行中的TIA Portal实例 TiaPortal tiaPortal new TiaPortal(TiaPortalMode.WithUserInterface); Project project tiaPortal.Projects.Open(C:\Projects\MyProject.ap19); // 遍历所有PLC设备 foreach (Device device in project.Devices) { foreach (DeviceItem item in device.DeviceItems) { if (item.TypeIdentifier.Contains(PLC)) { PlcSoftware plcSoftware item.GetServicePlcSoftware(); // 导出所有块 foreach (PlcBlock block in plcSoftware.BlockGroup.Blocks) { string exportPath C:\Export\ block.Name .xml; block.Export(new FileInfo(exportPath), ExportOptions.WithDefaults); } // 导出变量表 foreach (PlcTagTable tagTable in plcSoftware.TagTableGroup.TagTables) { string tagPath C:\Export\Tags_ tagTable.Name .xml; tagTable.Export(new FileInfo(tagPath), ExportOptions.WithDefaults); } } } }这段代码跑完你会得到一堆XML文件。每个块一个文件每个变量表一个文件。接下来就是解析这些XML提取节点和边。3.2 从Simatic ML到图谱节点的映射规则Simatic ML的XML结构比较复杂但核心信息集中在几个标签里。我整理了一张映射表把XML中的元素对应到图谱中的节点和边XML元素图谱节点/边属性说明SW.Blocks.FC/FB/OBBlock节点名称、类型、编号、注释SW.Blocks.Interface接口定义输入/输出/输入输出/静态/临时变量SW.Blocks.NetworkNetwork节点网络编号、标题、注释Access元素READS/WRITES边源变量、目标变量、访问类型Call元素CALLS边调用者、被调用者、参数映射SW.Types.PlcStructDataType节点名称、成员列表、偏移量Tag元素Variable节点名称、数据类型、地址、注释解析的时候有个坑同一个变量在不同网络里可能以不同形式出现。比如在梯形图里是DB_Motor.Start在SCL里是DB_Motor.Start在HMI变量表里可能是DB_Motor_Start。图谱构建时必须做名称归一化把所有表示同一实体的引用合并到一个节点上。我的做法是维护一个别名映射表解析时先查表查不到再创建新节点。3.3 图谱Schema设计的关键决策图谱的Schema设计直接决定了后续AI能回答什么问题。我在设计时遵循了一个原则节点粒度要细到变量级边粒度要细到网络级。为什么变量级因为PLC程序的核心是变量之间的依赖关系。如果只把功能块作为节点粒度太粗AI无法回答“这个变量被哪些地方修改了”这类问题。为什么网络级因为梯形图的网络是逻辑执行的最小单元一个网络内的逻辑是强耦合的跨网络的逻辑是弱耦合的。把网络作为边的属性可以保留逻辑的局部性。具体的Schema如下节点类型Variable变量节点属性包括名称、数据类型、绝对地址、注释、单位、量程Block块节点属性包括名称、类型OB/FB/FC/DB、编号、编程语言Network网络节点属性包括所属块、网络编号、标题、注释DataType数据类型节点属性包括名称、类型基础类型/UDT/数组/结构体Device设备节点属性包括名称、型号、厂商、通信地址边类型READS变量被读取属性包括所在网络、读取方式WRITES变量被写入属性包括所在网络、写入方式CALLS块被调用属性包括调用参数映射INSTANCE_OF变量实例化自某个数据类型MAPS_TO硬件通道映射到变量DEPENDS_ON变量之间的依赖关系通过读写关系推导这套Schema跑下来一个中等规模项目大概会产生几千个节点和上万条边。用Neo4j存储查询响应在毫秒级。3.4 语义增强让图谱“有血有肉”光有结构还不够AI要真正理解程序还需要语义信息。语义增强分三个层次。第一层是变量注释。TIA Portal里每个变量都可以写注释这些注释是工程师对变量含义的直接描述。解析时要把注释提取出来作为Variable节点的属性。如果注释是中文还可以用分词工具提取关键词作为额外的标签。第二层是功能块描述。每个FB/FC通常有功能描述说明这个块是干什么的。这些描述可能写在块的注释里也可能在项目文档里。把描述信息关联到Block节点上AI就能回答“这个块的功能是什么”这类问题。第三层是外部知识库。比如设备的型号手册、报警代码表、工艺参数表。这些信息不在TIA Portal项目里但对理解程序至关重要。我的做法是维护一个外部知识库用设备型号和报警代码作为键与图谱中的Device节点和Variable节点关联。4. 实操过程从零搭建一个可用的TIA Context原型4.1 环境准备与工具选型先列一下我用的工具栈都是实际跑通的组合TIA Portal V17项目源Openness API的宿主Visual Studio 2022写C#导出工具Python 3.10写图谱构建和AI交互逻辑Neo4j 5.x图数据库社区版够用PyCharmPython开发环境配合AI插件提升效率OpenAI API或本地大模型做自然语言交互这里有个选型决策值得说明为什么用Neo4j而不是内存图。小项目用NetworkX确实够但实际产线项目动辄几千个变量内存图查询效率会明显下降。Neo4j的Cypher查询语言对多跳关系查询优化得很好而且支持持久化不用每次重新构建。4.2 第一步导出TIA项目数据在Visual Studio里新建一个C#控制台项目引用Siemens.Engineering.dll和Siemens.Engineering.HW.dll。这两个DLL在TIA Portal安装目录的PublicAPI文件夹下。导出时有个细节要注意Openness导出块时默认不包含系统常量块和加密块。如果你的项目里用了系统常量或者有加密的库块需要在导出前检查一下必要时手动处理。导出完成后你会得到一个XML文件集合。我建议按块类型分目录存放比如FC/、FB/、OB/、DB/、Tags/方便后续批量处理。4.3 第二步解析XML并构建图谱Python这边用lxml解析XML用py2neo连接Neo4j。核心逻辑分三步解析块、解析变量、建立关系。解析块的时候重点是提取网络信息和调用关系。Simatic ML里每个Network有独立的编号和标题网络内部的逻辑用Access元素表示变量访问。下面是一段解析网络访问关系的核心代码from lxml import etree def parse_network_access(xml_path): tree etree.parse(xml_path) root tree.getroot() accesses [] for network in root.iter(Network): network_id network.get(ID) for access in network.iter(Access): access_type access.get(Scope) # 如 GlobalVariable symbol access.find(.//Symbol) if symbol is not None: component symbol.find(.//Component) if component is not None: var_name component.get(Name) accesses.append({ network: network_id, variable: var_name, type: access_type }) return accesses这段代码跑完你会得到每个网络里访问了哪些变量。接下来把这些数据写入Neo4j用MERGE语句避免重复创建节点。4.4 第三步构建变量依赖关系有了读写关系就可以推导变量之间的依赖。逻辑很简单如果变量A在某个网络里被读取变量B在同一个网络里被写入那么B依赖A。这个推导规则虽然简单但实际效果很好能覆盖大部分梯形图逻辑。推导出来的依赖关系用DEPENDS_ON边表示边上可以附加网络编号和依赖类型直接依赖/间接依赖。这样AI在回答“修改这个变量会影响什么”时可以沿着DEPENDS_ON边做多跳查询。4.5 第四步接入AI做自然语言交互最后一步是把图谱查询和LLM结合起来。我的做法是用户输入自然语言问题LLM先做意图识别判断是查询变量信息、查询依赖关系、还是查询块功能。然后根据意图生成Cypher查询在Neo4j上执行把结果返回给LLM做自然语言组织。这里有个关键设计LLM只负责语言转换不负责逻辑推理。推理全部在图谱上完成保证结果可验证。比如用户问“电机M1启动需要满足哪些条件”LLM生成Cypher查询找到所有写入M1启动变量的网络再找到这些网络里读取的变量最后把变量列表返回给LLM组织成自然语言。5. 常见问题与排查技巧实录5.1 Openness连接失败怎么办这是最常见的问题表现是C#程序启动后连不上TIA Portal。排查顺序如下现象可能原因解决方法报错“无法连接到TIA实例”TIA Portal未启动先手动打开TIA Portal并加载项目报错“版本不匹配”Openness DLL版本与TIA版本不一致检查DLL路径确保使用对应版本报错“权限不足”当前用户无TIA访问权限以管理员身份运行程序连接成功但读不到块项目未完全加载等待TIA Portal完全加载后再执行我踩过最坑的一次是TIA V17和Openness V16混用报错信息很模糊查了半天才发现是版本问题。建议在项目文档里明确记录TIA版本和Openness版本的对应关系。5.2 变量名冲突怎么处理不同DB块里可能有同名变量比如两个电机DB里都有Start变量。如果直接按名称建节点会合并成一个节点导致关系混乱。解决方法是用完整路径作为变量节点的唯一标识。完整路径的格式是DB名称.变量名称如果有多层嵌套用点号连接。在Neo4j里用full_path属性作为唯一约束name属性只用于显示。5.3 图谱查询太慢怎么优化当节点数量超过一万时不加索引的查询会明显变慢。优化手段有三个第一给常用查询属性建索引。比如Variable.name、Block.name、Network.block_name这些属性经常出现在查询条件里建索引后查询速度提升明显。第二限制多跳查询的深度。DEPENDS_ON边可能形成很长的依赖链不加限制的查询会遍历大量节点。实际使用中限制在3到5跳以内通常就够了。第三预计算常用查询结果。比如“所有被写入的变量列表”、“所有被调用的功能块列表”这些结果不常变化可以预计算后缓存起来。5.4 AI回答不准确怎么排查如果AI给出的回答与图谱查询结果不一致通常是LLM在组织语言时“自由发挥”了。解决方法是在提示词里明确要求只使用查询结果中出现的变量名和关系不得添加任何未在结果中出现的信息。另外可以在返回结果里附带查询语句方便人工验证。5.5 项目更新后图谱怎么同步产线项目会不断修改图谱需要同步更新。我的做法是增量更新每次导出时记录块的修改时间只重新解析修改过的块删除对应的旧节点和边重新创建。这样比全量重建快得多一个中型项目的增量更新通常在几秒内完成。6. 这套方案还能怎么扩展TIA Context这套思路跑通之后扩展方向其实很多。我目前尝试过的有两个方向效果不错。一个是程序文档自动生成。基于图谱里的块调用关系和变量依赖自动生成程序结构说明文档。每个功能块的功能描述、输入输出变量、调用关系、依赖的全局变量全部从图谱里提取生成Markdown格式的文档。项目交接的时候特别有用新人不用一个个块去翻。另一个是故障知识库关联。把HMI报警记录和PLC程序里的报警触发条件关联起来。当某个报警触发时可以快速定位到是哪个变量、哪个网络、哪个条件导致的。这个在产线调试阶段能省大量时间。还有一个方向我还在探索基于图谱做程序变更影响分析。修改一个变量或一个块之前先在图谱上查询所有受影响的节点评估变更风险。这个如果做成熟了对程序维护的价值会很大。我个人在实际操作中的体会是这套方案的核心价值不在于AI有多智能而在于把PLC程序的结构信息完整地保留下来让AI在结构上做推理而不是在文本上做猜测。知识图谱这个中间层是整个方案能跑通的关键。如果你也在做类似的事情建议先把图谱Schema设计好后面的工作会顺很多。