AF框架通讯与设备集成：从S7-1500到Modbus/OPC UA的实战解析

上周把AF框架第十三章的翻译稿交出去，总算松了一口气。这章稿子在我手里压了三周，不是篇幅长，而是通讯这块内容太容易翻错。作为长期做西门子自动化项目的人，我太清楚通讯在整个项目里的分量了：S7-1500要和变频器说话，S7-200 SMART要接触摸屏，上位机要通过OPC UA把数据拿走，产线上还有库卡机器人在等着交换信号。任何一个环节出了偏差，现场就是十几号人盯着红彤彤的报警灯发呆。

这一章在AF框架（Automation Framework，自动化框架）整套文档里的地位很特别。AF框架本身不是某个固件或某个软件，它是一套在TIA Portal环境里组织PLC程序的方法论，核心思路是把设备驱动、数据管理和工艺逻辑拆开，让程序不因为硬件变了就整个重写。而第十三章讲的就是这套框架里最容易被忽视、也最影响落地效果的部分——数据通讯与设备集成。说人话就是：当你的PLC需要同时伺候一堆外部设备时，程序结构该怎么搭才不会乱。

这篇内容是我翻译过程中的梳理和延伸，同时结合了国内工程师经常遇到的场景：S7-1500跨网段连MCGS触摸屏、KepServer 4.5怎么接S7-1500、森兰SB200和三菱变频器的Modbus RTU细节，以及Process Simulate通过OPC UA和PLC做联动。不管你是做设备调试、产线集成，还是纯粹想搞懂AF框架通讯模块的设计逻辑，这篇应该都能给你一些能直接用的东西。

1. 第十三章在AF框架中的定位：为什么通讯内容最难翻

1.1 先搞清楚AF框架到底是什么

AF框架并不是一个你安装之后点两下就能用的软件包。它更接近一套“程序组织的规范”加上一组封装好的功能块（FB）、全局数据块（DB）和调用规则。你可以在西门子技术社区、官方文档，以及很多大型设备商的标准化程序里看到它的影子。

我翻译的这套AF框架文档，核心逻辑围绕四个层级展开：

• 设备层：负责和外部硬件打交道，比如读写变频器、读取阀岛状态、跟机器人互发信号。
• 数据层：用全局DB作为“数据池”，设备层采集到的数据先落到这里，逻辑层也从这里取数据，避免各个FB之间直接点对点纠缠。
• 逻辑层：处理工艺逻辑、顺序控制、报警判断，它不关心数据是从哪个变频器来的。
• 交互层：给HMI、上位机、SCADA提供统一的读写入口，面板上看到的所有变量都来自数据池，而不是东拼西凑。

第十三章在整套体系里对应的，就是“设备层+数据层”如何协同工作。翻译到这一章时，我的第一感觉是：前面十二章都在讲怎么把程序结构搭得清爽，到了第十三章，突然开始面对一个极其现实的问题——设备之间到底怎么把数据对上话？这一章的英文原稿标题直译过来，大概就是“通讯与数据集成”。西门子文档里很少用花哨的词，但内容却非常硬核。

1.2 第十三章解决的是“设备之间的对话问题”

一个典型的自动化项目里，PLC往往同时面对好几种“说话对象”。对象不同，通讯协议就不同，数据格式也不同。最常见的组合是：

• PLC与变频器：Modbus RTU、USS、PROFINET，取决于变频器品牌和PLC型号。
• PLC与触摸屏：通常走以太网，但跨网段时涉及路由配置。
• PLC与上位机/KepServer/SCADA：OPC UA、S7通讯、Modbus TCP。
• PLC与机器人：PROFINET IO、TCP/IP裸协议，甚至基于OPC UA的交互。
• PLC与PLC：S7通讯、PUT/GET、PROFINET IO。

如果这些通讯全部用“裸功能块”散落在程序各处，项目初期调试还好，一旦投产之后某个变频器地址变了、某个机器人加了新信号，维护的人就要在程序里翻箱倒柜找半天。AF框架第十三章的核心，正是教你怎么把这些“对话”统一收口，用标准接口屏蔽设备差异。这也是我翻译时特别认同的一点：通讯问题本质上是架构问题，不是指令问题。

1.3 这一章原文的翻译难点在哪里

翻译第十三章，最棘手的是术语密集。通讯章节里每一段都涉及协议名称、寄存器地址、功能码、错误代码、数据类型。德语原文里很多复合词，比如“Datenaustausch”（数据交换）、“Sollwertvorgabe”（设定值给定），直接逐字翻译很容易变成“设定值预给定”这种拗口的话。我必须结合上下文改成中文工程师习惯的表达：“设定值下发”“给定赋值”。

另一个坑是错误码。西门子通讯相关的错误代码非常多，比如Modbus功能块返回的16#8184、16#8204这类异常码，官方文档里的解释是英文或德文，直译过来经常让人看不懂。我不能只做词汇转换，得把这些错误码翻译成工程师能理解的排查方向，比如“从站无响应，检查站地址和接线”“功能码不支持，检查从站协议版本”。这也是这一章翻译稿投入产出比最高的地方。

2. 从S7-1500到200 SMART：通讯能力边界必须事先画清楚

2.1 三款主流CPU的通信能力对比

很多做项目的朋友来问我，第一句话通常是“我能不能用S7-200 SMART和S7-1500直接走S7通讯？”这个问题背后，其实是没搞清楚不同型号PLC的通讯边界。AF框架第十三章里花了不小篇幅讲设备选型，我看完之后的感受是：通讯能力边界必须在项目一开始就画清楚，不然后期全是补丁。

我把三款最常见的CPU通讯能力整理成了一张表，方便选型时对照：

这张表看起来平淡，但它解决了我翻译过程中最纠结的一个问题：AF框架中很多“标准通讯方案”只针对于S7-1500，到了S7-200 SMART这一档，很多方案要降级用Modbus RTU或者开放式TCP。如果读者不先知道这个边界，照着AF框架的示例抄到S7-200 SMART上，根本编译不过。

2.2 AF框架眼中的设备分类：标准化设备、杂牌设备和IT系统

第十三章里，对通讯对象做了三种分类。这个分类方式我觉得很有参考价值，因为它直接决定了你在程序里用哪种通讯封装策略。

第一类是标准化设备。比如西门子V90伺服、G120变频器、S7-1500之间互联，它们支持PROFINET、S7通讯、OPC UA这些“正规军”协议，AF框架可以直接调用封装好的标准功能块。

第二类是第三方或老式设备。比如森兰变频器、三菱变频器、一些国产温控表，它们只支持Modbus RTU，地址表五花八门，寄存器含义千奇百怪。对这类设备，AF框架的做法是单独做一个“设备适配块”，把设备的寄存器映射表封装进去，对外只暴露几个统一的接口，比如“频率设定”“运行状态”“电流反馈”。

第三类是IT系统。比如MES、SCADA、KepServer、数据库，它们通常走OPC UA或者Modbus TCP，数据量可能很大但实时性要求没那么苛刻。AF框架中对这类对象的通讯往往放到一个专门的“数据网关”区域里，避免与实时控制逻辑抢扫描周期。

我实际做项目时特别推崇这个分类。因为很多工程师习惯把所有通讯对象一视同仁，变频器用Modbus，上位机也用Modbus，结果程序里全是五花八门的指令，出了故障排查异常困难。先分类，再设计，这是AF框架第十三章给我最大的启发之一。

2.3 通讯选型的判断逻辑

第十三章原文并没有直接给出一张“选型决策表”，但我在翻译过程中把它总结成了几条判断逻辑：

• 设备支持PROFINET，且PLC是S7-1500/1200，优先走PROFINET，不要为了省一个网络节点去用Modbus。
• 设备只支持RS485串口，再看PLC侧有没有自带串口。S7-200 SMART自带RS485口，可以直接用；S7-1200必须加CM1241通信模块；S7-1500同样需要CM/CP模块。
• 上位机/MES要求数据访问，优先把OPC UA服务器放在S7-1500侧，如果PLC档次不够，再加KepServer之类的网关软件。
• 两台西门子PLC之间需要交换大量数据，S7-1500之间用S7通讯，跨网段则考虑Profinet路由或者S7路由。
• 如果只是HMI读几个变量，触摸屏和PLC直接用以太网驱动就好，不要绕一圈OPC UA。

这套判断逻辑，我后来在自己的项目规划文档里反复用过，基本没有出过大的选型失误。通讯这件事，选对了路，后面调试就是填参数；选错了路，后面就是无休止地打补丁。

3. 变频器实操：森兰SB200与三菱变频器接入时的寄存器与报文细节

3.1 S7-200 SMART对森兰SB200的Modbus RTU接线与初始化

第十三章里变频器通讯占了很大篇幅，因为变频器是产线上最常接的设备。我挑两个典型的国内场景详细讲讲，一个是森兰SB200，一个是三菱变频器。

先说森兰SB200。很多老项目里用的是S7-200 SMART加森兰SB200系列变频器，走RS485，用Modbus RTU协议。接线本身不复杂：变频器侧的RS485端子，通常是A+和B-，接到S7-200 SMART的通信口Port0上。Port0的引脚定义要注意，3脚是RS485的B（对应D-），8脚是A（对应D+）。新手最容易犯的错，是把A和B接反，结果通讯时好时坏，偶尔能读到一次数据，然后一直报超时。

森兰SB200的Modbus RTU站号默认通常是1，波特率要看变频器面板设置，常见的有9600和19200。数据格式一般是8位数据位、1位停止位、无校验，或者8E1（偶校验），具体查变频器手册的通讯参数表。S7-200 SMART自带的Modbus RTU库指令是MB_MASTER和MB_SLAVE，编程时先用MB_CTRL指令初始化端口，把模式设为1（主站），波特率和校验方式要和变频器完全一致。

我翻译这一部分时，特意核对过寄存器映射的表述。森兰变频器典型的保持寄存器包括：通讯控制字、频率设定值、运行频率、输出电压、输出电流。频率设定值一般是一个16位寄存器，比如40001对应控制字，40002对应频率设定，单位可能是0.01Hz。写频率时先写控制字（比如0001启动、0007正转启动等），再写频率值，这一点不同品牌变频器差异很大，必须以具体手册为准。

3.2 三菱变频器与西门子PLC通讯时的兼容性细节

三菱变频器（比如FR-E700系列）和西门子PLC之间的Modbus RTU通讯，是另一个高频场景。三菱出厂默认很多参数是“适合自己的PLC来用的”，接到西门子PLC上需要改几个参数：

• 站号：Pr.117，设为1到247之间的一个值，和PLC侧MB_MASTER里的从站地址保持一致。
• 通讯速率：Pr.118，常见设为9600或19200。
• 数据格式：Pr.119，三菱默认是8位数据位、偶校验、1位停止位（停止位有时是2位）。如果西门子侧配置为8N1，则必须把Pr.119改成对应格式，否则通信永远异常。
• 从站允许：Pr.338、Pr.339这类和通讯运行指令相关的参数，需要根据实际控制需求打开。

我在现场就遇到过这样一个坑：三菱变频器在面板上可以正常操作，但S7-200 SMART发Modbus请求，变频器完全不回应。查了半天，发现是Pr.117站号被改成了0，而Modbus协议里站号0是广播地址，变频器作为从站不应该回应广播帧。把站号改成1之后，立刻正常。

另外一个注意点是寄存器地址偏移。三菱变频器的Modbus地址映射和森兰不完全一样，比如运行指令频率可能在寄存器“40010”等位置，但很多手册写的是“地址10”，协议帧里实际地址是0x0009（从零开始）。S7-200 SMART的MB_MASTER指令中，数据地址参数填的是“地址从1开始”的Modbus地址，还是“协议地址”，不同库版本有差异。我的经验是：先看库指令手册中地址的解释，再结合从站手册里的“协议地址/寄存器编号”来换算，不要想当然地直接填。

3.3 在AF框架中封装变频器指令，而不是到处裸调

第十三章里反复强调一个理念：通讯指令不要散落在OB1或者各个FC里，一定要封装成独立的FB。我见过太多项目，一个项目里有七八处调用MB_MASTER，各自读写不同的变频器参数，结果一查程序，连谁在写频率设定值都理不清。

AF框架的做法是这样：为每台变频器建一个“设备控制FB”，对外接口就几个：变频器编号、启停命令、频率设定值、当前反馈、故障复位。FB内部维护通讯状态机，定时触发读写，把读到的最新值写到全局DB对应的地址区。逻辑层想控制变频器，只调这个FB的接口就行，完全不用关心Modbus指令细节。

这样封装还有一个好处：换变频器品牌时，只需要重写这个FB内部的寄存器映射和报文构造，外部的逻辑层、HMI层完全不动。翻译第十三章时，我对这个设计印象极深，因为原稿用一个对照图展示了“逻辑层-设备适配层-硬件”之间的关系，虽然图我没法在这里复现，但核心思想就是“变化的东西必须隔离在最小范围内”。

4. 跨网段、跨平台的数据打通：MCGS、KepServer、OPC UA与库卡

4.1 MCGS触摸屏跨网段访问S7-1500

国内用MCGS触摸屏配合西门子PLC的项目非常多。常规做法是触摸屏和PLC在同一个网段，比如PLC是192.168.0.1，触摸屏是192.168.0.2，驱动配置直接填IP就能通信。但有些工厂网络环境复杂，触摸屏所在的网段和PLC不在同一个网段，这时候不能简单地把IP改到同网段，因为现场可能还有别的设备在用这个网段。

跨网段通讯的本质是：两端都要有到达对方网段的路由路径。S7-1500的PROFINET接口支持配置默认网关。比如PLC在192.168.1.10/24，触摸屏在192.168.2.20/24，中间有一台路由器或者三层交换机，那么PLC侧需要把默认网关设为192.168.1.1，触摸屏侧网关设为192.168.2.1，两边路由可达后，MCGS驱动里仍然填PLC的IP地址192.168.1.10，通讯就能通。

如果中间没有三层设备，只是两台设备用一根网线直连，跨网段是绝对不行的，这时候要么改一端的IP地址，要么在PLC侧加一个“辅助IP地址”。S7-1500在TIA Portal的以太网地址属性里支持设置多个IP地址，操作路径是：设备视图选中CPU的PROFINET接口，以太网地址选项卡，添加附加地址。这样PLC可以同时挂两个网段，触摸屏通过其中一个网段访问，上位机通过另一个网段访问，互不干扰。

4.2 KepServer 4.5连接S7-1500的配置与常见失败点

KepServer（现在叫Kepware）是工业数据网关里非常常见的一个。很多SCADA系统的数据链路是这样的：KepServer通过S7协议把S7-1500的数据读出来，再以OPC UA服务器身份把数据交给上层应用。4.5版本在国内存量很大，新项目也有不少用它的。

连接S7-1500时，KepServer里通常用“Siemens TCP/IP Ethernet”驱动（注意不是S7-200驱动）。新建通道后，在设备属性里填写PLC的IP地址，然后要设置Rack和Slot。S7-1500和S7-300不一样，默认机架是0，槽号也是0，不是S7-300时代的Rack 0 Slot 2/3。我第一次配置时就按老经验填了Slot 2，结果通道状态一直是“Device Not Connected”或者“Communication Error”。

另外一个高频坑是：S7-1500的DB块默认启用了“优化块访问”。优化块访问开启后，DB变量没有固定的偏移地址，而是通过符号名访问。KepServer的传统S7协议驱动依赖绝对地址（比如DB1.DBD0），遇到优化块访问就容易读不到数据。解决办法有两个：要么把需要被KepServer读取的DB取消“优化块访问”，在DB属性里把“优化块访问”复选框去掉；要么用Kepware较新版本中对符号化访问支持的驱动。我的习惯是：专门为上位机通讯建一个独立的DB，取消优化访问，所有需要暴露给上位机的数据都集中放这里，这样KepServer配置起来清晰，程序侧也安全。

4.3 Process Simulate通过OPC UA与PLC联动的配置

Process Simulate是Tecnomatix产品线里的工艺仿真软件。很多做产线规划的人用它做虚拟调试，也就是把PLC程序和仿真模型连起来跑，提前发现问题。第十三章翻译稿中，OPC UA通讯部分正好覆盖了这个场景。

S7-1500从固件V2.0开始内置OPC UA服务器，默认端口4840。要和Process Simulate做OPC UA联动，流程上要做三件事。

第一，在TIA Portal里启用OPC UA服务器。CPU属性中找到“OPC UA”，勾选激活OPC UA服务器，设置端口号。安全策略至少保留“None”用于测试，正式使用建议用“Basic256Sha256”并配置用户名密码或证书。第二，在PLC程序中准备需要暴露给OPC UA的数据。OPC UA服务器不会自动暴露所有DB，需要在DB属性里勾选“发布到OPC UA”或者通过“OPC UA XML设备描述”进行映射。第三，Process Simulate里配置OPC UA客户端，新建连接，填入PLC的OPC UA地址，比如opc.tcp://192.168.1.10:4840。连接建立后，仿真端就可以读写PLC里的变量了。

我在验证这个流程时遇到过一个有意思的问题：OPC UA地址明明填对了，安全策略也对，但Process Simulate就是连不上，报错信息是“BadSecurityModeRejected”。原因是我在PLC侧启用安全策略时选了“用户名和密码”，但Process Simulate的客户端配置里还是匿名方式。把两侧的安全策略改成一致，问题立刻消失。这个经验写在这里，大家少走弯路。

4.4 库卡机器人交互怎么接

和库卡机器人交互，是第十三章后面补充章节经常被问到的问题。库卡KR C4/KRC4机器人控制器和S7-1500之间最常用的是PROFINET IO通讯，也就是机器人作为IO设备，PLC作为IO控制器。需要在机器人的WorkVisual软件里配置一个“Profinet设备”，分配输入/输出地址区长度，比如输入32字节，输出32字节；PLC侧在TIA Portal里将机器人配置为PROFINET IO设备，分配设备名称和IP地址，组态IO地址。

这种交互方式本质上是一种“信号交换”：PLC把启动信号、工件号、允许运行等布尔量和少量数据写到输出区，机器人把完成信号、故障代码、当前状态写到输入区。由于是周期性IO，实时性有保障，调试时用博图的在线监控可以非常直观地看到信号变化。

如果项目要求交互的数据量很大，比如要读写机器人的坐标、工艺参数，PROFINET IO固定字节区就不够灵活了，可以考虑走OPC UA。新一代库卡控制器对OPC UA的支持已经比较成熟，S7-1500作为OPC UA服务器或者客户端都可以，两者之间通过信息模型进行数据交换。这种做法的好处是数据类型丰富、可扩展性好，缺点是实时性不如PROFINET IO，适合数据密集型但非实时控制的场景。

5. 翻译第十三章时的术语处理：对照表与还原性检查

5.1 高频术语的德英中对照

翻译章节时我做了一个术语对照表，长期做西门子项目的朋友可以直接参考：

这个表看起来简单，但实际翻译时，每个词都可能造成理解偏差。比如“Störung”在变频器语境下通常指“故障”，在PLC报警系统里又可能指“扰动”，必须结合上下文判断。

5.2 数据类型与寄存器地址是本地化的重灾区

通讯章节里最怕翻错的是数据类型和寄存器地址。原文中如果有“Dword”而译者译成“双字”还好，最怕的是把“Word”译成“单字”这种翻法，读者完全不知道是多少位。我统一采用约定俗成的译法：Bool=布尔型，Byte=字节，Word=字（16位），Dword=双字（32位），Real=实数。寄存器地址描述则保留16进制写法，因为现场对照手册时，工程师一定会看协议帧里的十六进制地址，翻成十进制反而容易出错。

另一个让我纠结的是西门子通讯中的“Unit ID”概念。在Modbus TCP报文里，Unit ID通常填1或者255，很多人直接叫“站号”或“单元号”。我在译稿中统一用“单元标识”，并在第一次出现时加括号说明“即习惯上说的站号/从站地址”，这样既严谨又贴近现场表达。

5.3 诊断信息不能一刀切直译

通讯错误诊断信息是最容易翻译成“正确的废话”的地方。比如“Connection timed out”，直译是“连接超时”，单独的“连接超时”对现场工程师几乎没用。AF框架第九章、第十三章的错误排查表格里，这种信息往往配了“可能原因”和“处理建议”。我翻译的原则是：错误描述保留标准说法，但后面一定要补上可执行的中文排查提示。

举几个例子：

• “No data received”译作“未接收到数据”，补充提示“检查从站是否上电、RS485接线A/B是否接反、站号是否匹配”。
• “Illegal data address”译作“非法数据地址”，补充提示“寄存器地址超出从站有效范围，对照从站手册确认地址映射”。
• “Slave device busy”译作“从站设备忙”，补充提示“从站正处理上一条请求，可适当增大请求间隔时间”。

这样处理后，中文译文不再是生硬的词汇转换，而是能让工程师直接照着干活的操作指导。

5.4 可复现性检查清单

翻译涉及程序示例的章节时，我留了一个检查清单，每次交稿前逐项打勾：

• 功能块接口参数名是否与英文原版一一对应，避免两个版本不一致导致读者对照官方文档时找不到变量。
• DB编号、I/O地址、定时器编号保持不变，不因为翻译顺手改成“更合理”的编号。
• 寄存器地址、功能码、错误码全部保留十六进制原始写法。
• 示例程序中注释的翻译保持简洁，操作步骤不改变。
• 涉及安全提示的警告、注意，必须原样保留，不要因为话多而删减。

这个清单没什么高深技术，但保证了我翻译出来的第十三章不是“中文化的版本”，而是“中文环境下可以直接对照原工程实施的技术资料”。

6. 把翻译稿丢进真实项目的验证心得

6.1 博图在线调试中的验证

翻译稿完成之后，我并没有直接交付，而是花了两个晚上，用TIA Portal V17搭了一个最小验证环境。没有真实硬件，我用PLCSIM模拟S7-1500，再配合一个Modbus TCP从站仿真工具，把第十三章里“Modbus TCP通讯块封装”的示例跑了一遍。

这一步比我预想的更有价值。仿真环境里，我首先验证了通讯块的初始化参数，以及错误码后处理逻辑。原稿建议：当通讯功能块返回错误码时，不要把错误码直接丢给HMI显示，而是先经过一个“错误解析FC”，转化成文本字符串，再显示在触摸屏上。这套机制在模拟环境里一切正常，但我也发现一个问题：有些错误是瞬时的，比如偶发超时，如果每次都弹报警，操作工会疯掉。于是我在实现层面加了一个“连续三次错误才确认报警”的滤波逻辑，这个经验在原稿中并没有详细展开，但我觉得非常实用。

6.2 时间锁程序案例与AF框架的结合

第十三章里有一个小例子，讲的是用PLC的实时时钟做设备使用时段控制，也就是大家常说的“时间锁”程序。很多设备在交付后，回款节点之前会限制部分功能，等收款后通过密码、或者HMI里的授权界面解除限制。

AF框架对这个功能的处理比较规范：时间锁判断被做成了一个独立的FC，输入参数是当前时间和授权截止时间，输出参数是“是否允许运行”。逻辑层只在启动流程里调用这个FC，而不是把时间判断散落在各个动作里。这样后期解除授权时，只需修改一个全局DB里的截止时间，或者通过一个高位密码进行在线修改。

我特别想提醒一句：时间锁功能的实现本身是合法的设备管理手段，但不要把精力花在研究怎么绕过别人的时间锁上。作为设备交付方，规范做法是合同里写清楚授权条款，程序里预留解除授权入口；作为使用方，如果设备因为授权问题停机，走商务流程解决比研究破解方案稳妥得多。

6.3 我最后想说的几句实在话

翻译第十三章这个过程，对我自己也是一种提升。很多原来“凭经验做”的通讯设计，在这套文档的体系里找到了理论依据。比如，我以前也喜欢把通讯指令封装成FB，但没有想过要从设备分类开始设计；我以前也喜欢把上位机数据集中到一个DB，但没有那么刻意地保证“这个DB可以被KepServer通过绝对地址访问”。

如果你看完这篇文章，想在自己的项目里试着落地AF框架的通讯思路，我建议从两件小事开始：第一，把项目里所有通讯对象列一张清单，按“标准化设备/第三方设备/IT系统”分类，给每类定一种统一的通讯封装方式；第二，专门建一个“通讯数据池DB”，所有进出的数据都经过这里，HMI和上位机只跟这个DB打交道。这两件事做完，你会发现不管后面接多少设备，程序都不会乱到哪里去。