OpenCode+博途MCP实操：AI自动解析PLC项目架构

工控工程师的AI效率革命

接手一个陌生的西门子博途（TIA Portal）项目往往是件头疼的事——复杂的程序块层层嵌套、交叉引用密如蛛网，工程师常常需要花费数小时甚至数天，逐个打开程序块才能理清整体架构。而现在，借助 OpenCode 与西门子博途 MCP 服务器的组合，这个过程可以被压缩到几分钟。

TIA Portal（Totally Integrated Automation Portal）是西门子推出的全集成自动化工程平台，整合了PLC编程（STEP 7）、HMI组态（WinCC）、驱动配置（SINAMICS Startdrive）等多种工程工具于统一界面中。它支持从S7-1200到S7-1500全系列PLC的编程，支持LAD（梯形图）、FBD（功能块图）、SCL（结构化控制语言）、STL（语句表）和Graph（顺序功能图）等多种编程语言。博途项目文件内部包含完整的程序块层级、硬件拓扑、网络配置和交叉引用数据库，信息量巨大，这也正是手动梳理如此耗时的根本原因。

要理解博途项目的复杂性，有必要了解其内部的程序块组织方式。在西门子PLC体系中，程序块分为四大类：OB（Organization Block，组织块）是程序执行的入口点，其中OB1是主循环扫描块，此外还有中断OB、启动OB等；FB（Function Block，功能块）是带有实例数据块的可重用程序模块，每次调用都会保留自己的状态数据；FC（Function，函数）是无状态的可重用程序模块；DB（Data Block，数据块）则专门用于存储数据。博途项目文件（.ap17、.ap18、.ap19等，后缀数字对应博途版本号）底层采用SQL Server Compact数据库进行存储，所有程序块、符号表、硬件配置、网络拓扑都以结构化数据的形式保存在其中。自2009年博途V11首次发布以来，该平台已演进到V20版本，每一代都在编译速度、项目管理和开放性接口方面持续改进——而MCP服务器的出现，正是博途开放性战略的最新体现。

本文基于一位 B 站 UP 主的实操演示，介绍如何使用 OpenCode 连接博途项目，让 AI 自动分析一个基于西门子官方 AF（Automation Framework）架构的案例程序。这套方案不仅能快速梳理程序框架、硬件配置，还能深入到单个功能块生成 HTML 分析报告，对刚接手项目的工程师极具参考价值。

MCP服务器与OpenCode是什么

MCP：连接AI与工业软件的桥梁

MCP（Model Context Protocol，模型上下文协议）是一种让大模型与外部工具、软件进行标准化交互的协议。该协议由Anthropic于2024年底正式发布，旨在解决大语言模型与外部数据源、工具之间缺乏统一交互标准的问题。在MCP出现之前，每个AI应用与外部系统的集成都需要定制化开发，导致大量重复工作。MCP采用客户端-服务器架构，定义了标准化的消息格式和通信流程，使得任何兼容MCP的AI客户端都能通过MCP服务器访问特定软件的内部数据。

从技术实现层面来看，MCP基于JSON-RPC 2.0协议进行消息通信，定义了三种核心原语：Resources（资源）用于向AI暴露结构化数据，如博途项目中的程序块列表、硬件配置表等；Tools（工具）允许AI调用具体操作，如读取某个FB的源码、查询交叉引用、获取编译状态等；Prompts（提示模板）则为常见分析任务提供预定义的交互模板。与传统REST API集成方式不同，MCP的核心优势在于它是为AI会话场景专门设计的——AI可以在一次对话中动态发现可用工具、按需调用、组合结果，而无需开发者预先硬编码所有交互逻辑。这种"即插即用"的设计理念使得MCP生态能够快速扩展：截至目前，社区已经发布了数百个MCP服务器，覆盖数据库、云服务、开发工具等众多领域，而西门子博途MCP服务器正是工业自动化领域的重要里程碑。

西门子提供的博途 MCP 服务器，正是这一生态中面向工业自动化领域的重要实现。它本质上是一个中间层，把博途项目中的程序块、硬件配置、交叉引用等信息暴露给 AI，使 AI 能够像人类工程师一样"读取"和"理解"PLC 项目。

OpenCode：免费大模型的入口

OpenCode 是本次演示所使用的客户端工具。它是一款基于终端（Terminal）的AI编程助手，定位类似于近年来大热的Cursor、Windsurf、GitHub Copilot等AI编程工具，但与这些主要面向软件开发者的IDE增强工具不同，OpenCode以其轻量化和开源特性脱颖而出。它的一大亮点是内置了免费的大模型，用户无需额外付费即可体验 AI 分析能力。同时，OpenCode原生支持MCP协议，这意味着用户可以通过简单的配置文件将任意MCP服务器接入，从而将AI的能力从纯代码分析扩展到与各种专业软件的深度交互——博途MCP服务器的接入正是这一能力的典型应用场景。

安装流程也相当简洁：下载并安装 OpenCode 后，选择免费模型，然后将 MCP 安装文件路径复制给 AI，直接对它说"帮我安装该 MCP 服务器"，AI 便会自动根据文件完成配置。

有意思的是，MCP 服务器安装完成后通常需要重启系统，重新登录 Windows 并重启 OpenCode 才能生效。

连接博途项目并自动分析架构

建立与博途项目的连接

完成 MCP 服务器安装后，打开西门子官方的 AF 架构案例程序，切换到项目视图，复制项目路径并告诉 AI"帮我测试连接到该项目"。此时 Agent 会调用 MCP 中的工具连接博途，博途端会弹出访问确认窗口，点击"全部确认"后，AI 便成功接入项目。

一句话读懂整个PLC项目

连接成功后，只需对 Agent 说"帮我分析该项目的程序架构、程序框架、硬件配置"，AI 就会自动执行一系列操作：

• 获取项目信息，检测编译状态
• 读取核心程序逻辑与 CPU 硬件详情
• 识别硬件型号
• 读取 FB Unit、EM 设备调度等模块

经过分析，AI 得出结论：该案例程序基于 OMAC 状态机模型构建，采用了 Unit（单元）→ EM（设备模块）→ CM（控制模块）的三层架构，并大量使用了西门子的各种官方库。

这里值得展开介绍的是AF架构的设计理念。AF（Automation Framework）是西门子基于ISA-88和OMAC PackML标准推出的一套标准化自动化编程框架。其中，ISA-88（也称为S88）是国际自动化学会（ISA）于1995年首次发布的批量控制标准，最初面向制药、食品、化工等批次生产行业。ISA-88的核心贡献在于提出了两个关键分离原则：将物理设备模型（Physical Model）与工艺过程模型（Procedural Model）分离，以及将配方管理（Recipe Management）与设备控制分离。其物理模型定义了Enterprise → Site → Area → Process Cell → Unit → Equipment Module → Control Module的七层设备层级，AF框架正是吸收了这一分层思想的精髓，将其简化为适合离散制造业的三层架构。

AF框架将设备控制逻辑分为三个层级：Unit（单元层）负责整机或生产线级别的状态管理和协调调度；EM（Equipment Module，设备模块层）负责单个工艺设备的控制逻辑；CM（Control Module，控制模块层）负责最底层的传感器/执行器交互。这种分层设计遵循面向对象编程思想，使得程序模块高度可复用，正是AF框架标准化设计的典型体现。

而OMAC（Organization for Machine Automation and Control）是一个由终端用户驱动的行业组织，其成员包括宝洁、雀巢、联合利华等全球顶级消费品制造商。其制定的PackML（Packaging Machine Language）标准已成为包装行业乃至更广泛制造业的事实标准。OMAC状态机定义了一套通用的机器运行状态模型，包括Stopped、Starting、Execute、Completing、Complete、Resetting等17个标准状态，以及它们之间的转换条件。采用OMAC状态机的好处在于，不同厂商、不同设备之间可以使用统一的"状态语言"进行通信和协调，大幅降低系统集成难度，也便于MES/SCADA等上位系统统一监控。在实际工程中，PackML标准的采用意味着一个工厂内不同供应商提供的设备——无论是灌装机、贴标机还是装箱机——都以相同的状态模型向上层系统报告自身状态，产线协调效率因此得到质的提升。

深入分析单个功能块

模拟量输入库的实战剖析

宏观架构梳理清楚后，真正的价值在于能够逐层下钻。演示中，UP 主选取了一个模拟量输入库，复制其库名称后要求 AI："帮我详细分析该程序，生成 HTML 分析报告，并包括在整个项目中的调用情况以及作用。"

AI 随即读取源码并获取交叉引用信息。交叉引用（Cross Reference）是PLC开发环境中的一项核心功能，它记录了每个变量、程序块、数据块在整个项目中被使用（读取、写入、调用）的所有位置。对于大型工业项目而言，一个PLC程序可能包含数百个程序块和数千个变量，手动追踪某个变量在哪些位置被使用几乎不可能。MCP服务器将交叉引用数据暴露给AI，正是其相比简单代码分析的关键优势所在。

分析结果显示，该模拟量输入模块在整个项目中被调用了 4 次，对应 4 个多重实例——分别用于温度传感器、湿度传感器、风速传感器和太阳光照强度传感器，全部集中在一个负责控制的 EM FB 块中。

这里有必要解释西门子PLC中"多重实例"（Multi-Instance）这一重要概念。在传统的单实例调用方式中，每个FB被调用时都需要分配一个独立的实例DB（数据块），如果一个FB被调用100次，就需要创建100个实例DB，项目管理非常繁琐。多重实例则允许将被调用FB的实例数据嵌入到调用者FB的实例DB中，作为其静态变量的一部分进行管理。这意味着一个EM层的FB可以在自己的实例DB中包含多个CM层FB的数据，形成清晰的数据层级结构。在AF框架中，多重实例被大量使用——例如演示中的EM FB包含了4个模拟量输入模块的多重实例，所有传感器数据都被组织在同一个实例DB中，极大地简化了数据管理和程序维护。

这里凸显了 MCP 方案相比传统 AI 的核心优势：如果只是把源码复制粘贴给通用 AI，它无法基于整个项目上下文理解这个程序块的实际作用与调用关系。而通过 MCP 连接，AI 能够获取完整的交叉引用，明确该模块在项目中的定位。

HTML报告：结构化的分析输出

AI 最终生成的 HTML 分析报告内容相当详尽，与工程师在博途中手动查看的结果完全一致：

• 基本信息：FB 编号、块的属性等全部罗列
• 项目定位：明确该模块处于底层，直接与模拟量传感器进行数据交互
• 数据流路径：硬件层（4 个传感器）→ CM 层 → EM 层 → 工艺逻辑 → HMI 接口 → VCC Unified 触摸屏
• 接口定义：输入输出、静态变量全部翻译整理
• 内部处理流程：输入采集、复位管理等
• 算法解析：模拟量采用 4-20mA 对应 0-27648 的换算，并设有有效性窗口（上超两层、下超两层的判断）
• 状态列举与 AF 框架的协作机制

关于模拟量信号处理，这里有必要补充一些工程背景。4-20mA电流信号是工业自动化中最常用的模拟量传输标准之一，其历史可以追溯到20世纪60年代，由于电流信号在传输过程中不受导线电阻影响（根据基尔霍夫电流定律，串联回路中电流处处相等），因此相比电压信号具有抗干扰能力强、可远距离传输的优势，即使在电磁环境恶劣的工业现场也能保持信号完整性。4mA作为零点（而非0mA）的设计使系统能够区分"测量值为零"和"线路断路"两种状态——当检测到回路电流降至4mA以下（通常以3.6mA为阈值）时，系统即可判定传感器故障或线路断路，这是工业安全设计的重要考量。在西门子PLC中，4-20mA信号经模拟量输入模块的A/D转换后映射为0-27648的整数范围（对应14位有效分辨率，实际硬件可能支持更高的过量程范围如-32768到32767），工程师需要在程序中将这个原始数值通过线性插值公式换算为实际物理量（如温度、压力、流量等），公式通常为：实际值 = (原始值 / 27648) × (量程上限 - 量程下限) + 量程下限。报告中提到的"上超两层、下超两层"是指信号超限报警机制：通常设置高高限（HH）、高限（H）、低限（L）、低低限（LL）四个阈值，其中H和L触发预警提示，HH和LL则触发紧急报警甚至联锁保护动作，用于保护设备和工艺安全。

灵活应对陌生项目

哪里看不懂就分析哪里

这套工作流的精髓在于按需分析。演示中，UP 主对 Unit 层程序块并不了解其具体内容，同样只需复制块名并说"按照先前的要求分析这个程序块"，AI 便快速生成了 Unit 的分析报告，涵盖接口定义、网络数据流、依赖的库，以及 5 个 UDT（用户自定义数据类型）。

UDT（User-Defined Data Type）在西门子PLC编程中是一个重要概念，类似于高级编程语言中的结构体（struct）或C语言中的typedef struct。工程师可以将多个相关的变量（如一个电机的转速、电流、温度、运行状态、故障代码等）封装为一个UDT，从而实现数据结构的标准化和复用。例如，定义一个名为"UDT_MotorData"的数据类型后，项目中所有电机都可以使用同一个UDT来组织数据，确保数据格式的一致性。在AF框架中，UDT被大量使用来定义标准化的接口数据结构，例如EM层与Unit层之间的命令/状态交互数据、HMI面板需要显示的工艺数据、报警管理数据结构等。合理使用UDT可以显著提高程序的可读性和可维护性，并确保同类设备采用一致的数据格式。值得一提的是，在博途V14及以后版本中，西门子还引入了"系统数据类型"（SDT）的概念，进一步扩展了数据类型的标准化能力。

适用场景与实际价值

这种 AI 辅助分析方式最适合以下情况：

1. 刚接手陌生项目：无需逐个打开程序块，AI 可初步梳理整体构成
2. 理清复杂调用关系：所有块的交叉引用都能自动生成
3. 快速定位关键模块：从宏观架构下钻到具体逻辑

正如 UP 主所言，操作本身"挺简单"，关键在于提示词是否足够充分。给出清晰、具体的指令，AI 就能帮你实现所需的分析功能。

总结

OpenCode + 博途 MCP 服务器的组合，展示了 AI 深度融入工业自动化工作流的一个务实方向。它并非取代工程师的专业判断，而是把最耗时的"读代码、理架构"环节大幅加速。对于工控行业而言，这类工具的价值在于降低了理解复杂项目的门槛，让工程师能把精力集中在真正需要人类经验的决策与优化上。

随着 MCP 生态的成熟，未来我们或许会看到更多工业软件与 AI 的深度集成——从 PLC 编程到 SCADA 组态，AI 辅助将成为工程师的标配工具。SCADA（Supervisory Control and Data Acquisition，数据采集与监视控制系统）是工业自动化的上层软件平台，负责从现场PLC、RTU等控制器实时采集数据，以图形化方式呈现整个工厂或产线的运行状态，并提供报警管理、历史趋势、报表生成等功能。目前，西门子WinCC、Ignition、AVEVA等主流SCADA平台尚未推出官方MCP服务器，但考虑到这些系统同样存在项目复杂、配置繁多的特点，AI辅助分析的需求同样迫切。可以预见，当MCP服务器覆盖到SCADA组态、DCS（分布式控制系统）编程、机器人离线编程等更多工业场景时，AI将真正成为贯穿工业自动化全栈的智能助手。