AI 写 PLC 代码终于有地基了！RealPLC 一键配置 TIA Openness，让自然语言编程真正跑进博途 ！

今天我们跑了一天的Vibe Coding，目的当然还是把TIA Openness的能力接入RealPLC实现自然语言编程的闭环。

很多人一提到 AI 编程，第一反应是：让大模型帮我写一段代码。但在 PLC 工控领域，事情远没有这么简单。

普通软件代码写完后，可以直接放进 IDE 编译、运行、测试；而 PLC 代码不一样，它最终必须进入真实工程环境，比如 Siemens TIA Portal，也就是我们常说的博途。它不仅要语法正确，还要能被 TIA 接受、能生成 FB/FC/DB/UDT、能进入正确的项目目录、能通过编译诊断，并且不能误改硬件、不能下载 PLC、不能碰安全程序。

这就是 RealPLC 正在解决的问题。

RealPLC 的目标不是简单做一个“会写 PLC 代码的聊天机器人”，而是打造一个面向电气工程师的 AI PLC 工程助手：你用自然语言描述需求，AI 生成 PLC 程序，RealPLC 自动送进 TIA Portal 里验证，拿到真实编译结果，再根据错误摘要进行修复，最终形成可审批、可追踪、可落地的工程变更。

而这一切的地基，就是 TIA Portal Openness API。

01

西门子TIA Openness

TIA Openness 是 Siemens 提供的自动化工程 API，它允许外部程序和 TIA Portal 工程交互，例如读取项目结构、导入外部源文件、生成程序块、编译 PLC、获取诊断信息等。

换句话说，AI 生成的 PLC 代码想要真正落地，不能只停留在 .scl 文本文件里，而是要经过这条链路：

自然语言需求
→ AI 生成 SCL
→ 导入 TIA Portal
→ 生成 FB / FC / DB / UDT
→ 编译验证
→ 返回错误/警告
→ AI 修复
→ 再验证
→ 形成 ChangeSet

没有 Openness API，AI 只能“写代码”；有了 Openness API，AI 才有机会进入“工程闭环”。

这就是 RealPLC TIA配置向导存在的意义：把原本复杂、容易踩坑的 TIA Openness 环境配置，变成普通用户也能一步步完成的流程。

02

为啥做成配置向导

很多电气工程师不是不会用博途，也不是不懂 PLC，而是不想在一堆 API 路径、权限组、PublicAPI 版本、Agent 启动、端口检测里浪费时间。

尤其是 TIA Openness 的配置，常见坑非常多：

.NET Framework 版本不对

没有安装 TIA Openness

没有加入 Siemens TIA Openness 用户组

PublicAPI 自动选错版本

V18 项目却误选了 PublicAPI\V15.1

Agent 没启动

CloudBridge 不通

编译结果拿不到

RealPLC 配置向导要解决的就是这些问题。

它的定位很明确：简单配置，即可使用 Openness API，为 AI 自然语言 PLC 编程做好地基。

用户不需要理解每个底层 API 的细节，只需要按照向导一步步检查和修复，直到环境达到可用状态。

03

配置向导主要步骤

RealPLC 的环境配置向导可以理解成一个“Openness 接入体检 + 修复工具”。它不是一次性弹窗，而是围绕 AI PLC 编程链路，把关键节点拆成几个明确步骤。

第一步：检测 TIA Portal 是否安装

首先，RealPLC 会检测当前电脑是否安装了 TIA Portal。例如用户使用的是 TIA Portal V18，那么系统会识别本机的 Portal 安装目录：

C:\Program Files\Siemens\Automation\Portal V18

这一步的意义是确认当前电脑具备最基本的工程环境。

如果连 TIA Portal 都没有，后面的 Openness API、PLC 编译验证都无从谈起。如果没有安装的话，下方的官方链接可以直接点击参考的。

第二步：检测 TIA Openness 是否可用

TIA Portal 安装了，不代表 Openness API 就一定能正常使用。RealPLC 会继续检测 PublicAPI 目录和关键 DLL，例如：Siemens.Engineering.dll。

这一步非常关键，因为 RealPLC 后续要通过这些 API 与 TIA Portal 工程交互。

特别是 TIA V18 环境下，PublicAPI 目录可能同时存在多个版本：

V15.1
V16
V17
V18
V18.AddIn

之前最容易踩的坑就是：程序误选了 PublicAPI\V15.1，导致生成 FB/UDT 时无法进入指定目录。现在 RealPLC 已经明确规则：

TIA Portal V18 默认使用 PublicAPI\V18
不默认使用 PublicAPI\V15.1

这一步修复后，RealPLC 才能稳定使用：

GenerateBlocksFromSource(targetGroup, option)

把 FB、FC、DB、UDT 生成到指定工程目录中。

第三步：检测 Siemens TIA Openness 权限组

TIA Openness 不是装好就能直接调用的，还涉及 Windows 权限组。用户需要加入：Siemens TIA Openness。否则程序调用 TIA API 时可能会出现权限异常。

配置向导会检测当前用户是否已经具备权限，如果没有，会提示用户加入对应用户组，并提示可能需要重新登录或重启电脑。

这一步非常重要，因为它决定 RealPLC Agent 是否真正有权限访问 TIA 工程。

第四步：TIA项目状态

目前是需要先打开一个项目进行测试，后面会补充创建项目、打开项目等步骤。

实际上就是监控电脑上TIA博途里的进程是否开启。

第五步：启动 RealPLC TIA Agent

前面的步骤是环境准备，真正执行 Openness 调用的是 RealPLC TIA Agent。Agent 的作用可以理解为本地桥梁：

RealPLC Web / AI 请求
→ Local Agent
→ TIA Openness API
→ TIA Portal 工程

它运行在 Windows 本地，因为 TIA Portal 本身就是 Windows 工程软件，不能简单放到云端 Docker 里跑。配置向导会检查 Agent 是否启动、端口是否可用、HTTP 服务是否正常。

第六步：检测 CloudBridge / 本地通信链路

RealPLC 的目标不是只做一个本地工具，而是要让 AI 系统能调用本地 TIA 能力。

所以还需要确认：

RealPLC 前端
→ Gateway
→ CloudBridge
→ LocalHttpAgent
→ Worker
→ TIA Portal

配置向导会帮助用户确认连接状态，避免出现“界面看起来启动了，但 AI 请求根本没打到 TIA”的情况。如果像图中没有连接，可以点击下方的执行/修复当前步骤，右侧有详细的解释和说明。基本可以明白当前在干啥，出现啥问题，可以怎么解决等等。

第七步：运行快照和编译验证

最后一步是实际验证能力。

RealPLC 会尝试读取当前 TIA 工程信息，例如：

• 项目名称
• PLC 名称
• CPU 型号
• 固件版本
• 程序块列表
• 数据类型列表

然后执行一次 SCL 验证测试，把样例代码导入 TIA，生成块并编译。

如果成功，说明 Openness API 已经真正可用，而不是“路径看起来对”。配置成功后，RealPLC 能做到什么？配置完成后，RealPLC 就不再只是“生成一段 SCL 文本”。它可以完成更工程化的闭环：

1. 根据自然语言需求生成 PLC 代码
2. 自动拆分 UDT / FB / FC / DB 文件
3. 自动导入 TIA Portal
4. 自动生成到指定目录
5. 自动编译 PLC
6. 提取错误、警告、主因
7. 让 AI 根据诊断结果修复
8. 再次验证
9. 形成可审批 ChangeSet

比如用户输入：

生成一个电机启停 FB，包含启动、停止、急停、过载、复位、运行输出、故障输出。传统 AI 可能只是给你一段代码。而 RealPLC 的目标是继续往后走：

代码能不能进博途？

• 能不能生成 FB？
• 依赖的 UDT 是否齐全？
• 编译有没有报错？
• 错误在哪一行？
• AI 能不能修？

是否可以安全应用到原项目？

这才是面向电气工程师的真实价值。

为什么这件事重要？AI 时代，PLC 编程的门槛不会消失，但工作方式会改变。未来电气工程师可能不再从空白处一行一行写程序，而是更多地做：

需求描述
逻辑审核
安全边界确认
代码验证
错误修复
工程审批
现场调试

AI 可以帮你生成初稿，但真正能不能用，必须交给工程环境验证。

RealPLC 正在补的就是这块中间层：让 AI 生成的 PLC 代码，不只是“看起来像”，而是能进入 TIA Portal，被真实编译器检查，被工程流程约束，被用户审批后再落地。

配置向导看起来只是一个小功能，但它实际上是 RealPLC 工程化路线的第一块地基。

因为只有用户能简单配置好 Openness API，后面的自然语言 PLC 编程、自动验证、AI 修复、ChangeSet 审批，才有真正落地的可能。

04

总结

RealPLC 配置向导的核心价值可以用一句话概括：

让普通电气工程师用最少配置，打通 TIA Openness API，为 AI 自然语言 PLC 编程做好工程地基。

它解决的不是“AI 会不会写代码”的问题，而是“AI 写出来的 PLC 代

码能不能进入真实工程环境验证”的问题。

从这个角度看，RealPLC 不是简单的 PLC 代码生成器，而是在搭建一套面向未来的 AI PLC 工程闭环：

自然语言
→ 代码生成
→ 博途验证
→ 错误诊断
→ AI 修复
→ 工程审批
→ 安全落地

这一步打通之后，AI 辅助 PLC 开发才真正

从“演示”走向“可用”。如果对您有帮助，

还请点赞👍、推荐

参考链接：

【1】https://www.realplc.com