企业官网建设流程全解析

1. 这一章在AF框架里的位置：程序骨架和外部世界的连接层

先说个背景。AF框架（Automation Framework，自动化框架）在西门子工程圈里，通常指的是以 TIA Portal 为开发环境的一套标准化程序架构。它把一套 PLC 程序抽象成几个固定层——安全层、逻辑控制层、设备层、通讯层、诊断层。每一层各管各的事，互相之间通过统一的接口（接口DB、命名规范、UDT 结构）交互。这样做的直接好处是：不管项目是单台设备还是整条产线，程序结构都是一样的，调试的人换了一个又一个，程序翻起来还是同一个味道。

我翻译的第十九章，放在整套 AF 框架里的位置相当微妙。前面的章节把 CPU 选型、IO 规划、安全回路、基本功能块都讲透了，到第十九章时，要解决的问题已经从"这台设备怎么动"升级成了"这台设备怎么跟别人说话"。说得直白一点，这一章讲的是通讯集成和外部设备协同，包括 PROFINET 现场总线上的从站管理、变频器驱动、机器人握手、以及和上位系统做数据交换的几种方式。

为什么这一章难翻译？因为它不光是语法层面的英译中，更麻烦的是术语背后的语境。比如 "telegram" 在西门子报文语境里指的是周期性数据块结构，不能按单词直译成"电报"；"muting" 在安全光栅场景里指的是屏蔽，而不是"静音"。这些都是翻译过程中的大坑，也是我这一章花时间最多的地方。

另外值得说一句，第十九章在整套框架中作了一个非常关键的承上启下动作——把前面定义好的功能块和具体的外部设备通讯打通。也就是说，你在程序里看到的 FB 调用、DB 数据，不再只是内部逻辑的演练，而是真正变成了控制现场变频器、接收机器人状态、向第三方系统提供 OPC UA 服务的一条条真实数据流。理解清楚这一层关系，是读懂这一章的前提。

2. 通讯组态的地基：先从 PROFINET 设备视图讲起

2.1 设备组态里最容易被忽略的"设备名称"和"IP地址"的配合

第十九章上来第一步就讲 PROFINET 设备怎么接入项目。很多朋友在 TIA Portal 里添加 PROFINET IO 设备的时候，习惯性点一下自动分配设备名称就过了。但实际现场报错的时候，八成都出在这个看似简单的环节上。

PROFINET 和普通以太网最大的一点区别就是：它并不靠 IP 地址来确定设备身份，而是靠一个叫"设备名称（Device Name）"的东西。你在 TIA Portal 的组态里指定了设备名称后，硬件本身也得通过PST工具或者在线分配的方式写上这个名字。两边名字对不上，设备显示的在线状态就是"不可用"。

我在实际调试中遇到过一种很典型的情况：用第三方工具（比如 Wireshark 抓包）去看，设备明明在线，MAC 地址、IP 都能看到，但 TIA Portal 里就是找不到设备。后来一查，是设备名称里的大小写不一致。PROFINET 的设备名称规范比较严格，只能用小写字母、数字和连字符，设备名称不能以下划线开头，不能有空格。很多国产第三方设备（比如某些协议转换网关、伺服驱动器）对这套规则支持得不太好，写设备名的时候强制要求大写或者允许带下划线，组态的时候一眼看上去没问题，下载到 PLC 之后就是通讯不上。

提示：如果你用的是西门子自家的 G120 变频器或者 ET200 分布式 IO，设备名称这一关一般很顺畅。但只要是第三方 PROFINET 设备，一定要先去查设备手册里对设备名称的约定，再对照 PROFINET 命名规范做一次强制转换，否则后面排查会折腾很久。

2.2 报文结构的选择直接决定了你编程时面对的数据结构

框架文档里反复强调一个概念：西门子 PROFINET 通讯中，"报文"就是数据交换的最小周期单元。你在设备视图里给变频器拖一个报文，比如"标准报文 1，PKW+PZD"，其实就已经决定了你后面在程序里看到的是什么样的数据结构。

具体到翻译内容，第十九章里对报文解释得比较系统。报文分两部分，PKW 区是参数区，用来读写变频器内部的参数号；PZD 区是过程数据区，用来实时传递控制字、状态字、速度给定值和实际值。平时我们做速度控制，走的是 PZD；要修改变频器的加减速时间这类参数，走的是 PKW。

但注意一个容易踩坑的点：报文长度一旦选定了，后面想要改，不只是删掉重拖那么简单。你在用户程序里依赖的接口变量（比如"变频器转速实际值"对应的地址）会跟着变，工艺逻辑上到处都引用到这个地址的话，改动量不小。所以选报文之前，先想清楚现场到底要传几个控制字、几个给定值、几个反馈值。我一般模块化设备选标准报文 20（带五个 PZD），不需要太多数据就把整定、使能、复位、速度给定、实际电流全放下了；如果只是简单启停调速，标准报文 1 足够。

2.3 非周期通讯：什么时候用，什么时候不碰

很多搞了几年 PLC 的人，对周期性报文很熟，但对读写请求（非周期通讯）一直模模糊糊。第十九章里用了一整节来讲"控制器如何读写 IO 设备中的任意参数"，翻译到这里我自己也重新理了一遍。

非周期通讯的作用场景很清晰：比如设备运行中你想动态改一个变频器的斜坡时间，又不想重新下载硬件组态。这个时候你通过WRREC（写入记录）或者调用驱动库自带的参数读写功能块，把目标参数号打包成一条请求发出去，设备在后台处理完再给应答。周期报文里没有这个参数，但非周期通讯能办到。

不过要泼一盆冷水：非周期通讯的响应时间取决于设备的处理能力和总线负载，千万不要把它当成可规划的控制路径。有人为了图省事，把一个需要实时响应的速度修正逻辑用WRREC去写变频器参数，结果现场数据刷新慢，整个工艺被拖垮。AF 框架里面的原则很明确——周期报文走控制，非周期报文走组态和参数维护，两者绝不能混用。

3. 跟变频器做邻居：AF 框架里的驱动块是怎么设计的

3.1 从热词"abb变频器与西门子plc"展开：第三方驱动要不要用库

网络热搜词里面恰好有"ABB 变频器与西门子 PLC"这种组合，这个其实特别能代表 AF 框架应用时的一个现实问题：很多产线不是全西门子的设备，变频器可能是国产的，成套设备里又是 ABB 的，控制层却是西门子 PLC。这时候如果强行要求"都用 PROFIdrive 协议上 PROFINET"，很多第三方变频器虽然支持扩展报文，但细节上和西门子自己的 G120 系列总有差别。

我的观点是这样：能用标准报文解决的就用标准报文，省事；涉及到专用功能、专用参数的，就在设备层自己封装一个驱动功能块。AF 框架对设备层的定义就是可替换。你把一个"逻辑控制层"的接口 DB 定义好——控制字、速度给定、运行反馈、故障反馈——至于里面调的是西门子官方 FB 还是第三方写的自定义 FB，逻辑控制层根本不用关心。

之前我在一条包装线上干过一件事：四台变频器，两台西门子 G120，两台国产某品牌，用的都是 RS485 Modbus RTU 接入 S7-1200 的 CM1241 通讯模块。因为 G120 自带 PROFINET 接口，国产那两台没有，只能走串口。我为两套设备各写了一个功能块，面向逻辑层暴露一模一样的接口：启停、故障复位、速度设定、实际速度、电流反馈。逻辑层根本不关心这层差异，只要接口一致就行。这就是 AF 框架里"设备驱动应封装差异"的真实含义。

3.2 Modbus RTU 通讯的实操参数：从波特率到数据格式

说到串口通讯，这其实是很多人眼里的老大难，但原理搞清楚了反而特别稳。Modbus RTU 是一种很老的协议，结构简单，一主多从，基于 RS485 半双工。要在 TIA Portal 里把它调通，有几个参数几乎是必查的：

贴一段我常用的 S7-1200 调用 Modbus 指令的骨架代码（LAD 里不方便看，用 SCL 描述一下逻辑）：

// 使用 MB_COMM_LOAD 建立背景连接 MB_COMM_LOAD(slot := 1, port := 1, baud := 19200, parity := 0, // 0=无校验, 1=偶校验 flowCtrl := 0, timeout := 1000, echo := 0, mode := 1); // 1=RS485 半双工，注意接线 // 使用 MB_MASTER 或 MB_SLAVE 建立周期读写 MB_MASTER(REQ := readTrigger, MB_ADDR := 16#01, // 从站地址 MODE := 0, // 0=读保持寄存器 DATA_ADDR := 40001, // 起始地址，注意 40001 可能对应地址 0x0000 DATA_LEN := 4, DATA_PTR := "ReadBuffer", DONE => mbDone, ERROR => mbError, STATUS => mbStatus);

这里特别想强调一个地址映射的坑：很多国产变频器的报文起始地址（比如速度给定地址）跟 Modbus 协议地址之间有一个偏移。比如有的变频器手册里写"通讯地址 1000H"，翻译成 Modbus 数据地址的时候，用户很容易直接把 16#1000 填进去，结果读出来的数据完全不对。正确做法是先看设备寄存器映射表，再把地址换算好。

3.3 博途里组态第三方变频器的另一个选择：GSD 文件

如果你不想写串口通讯，第三方变频器也有不少支持 PROFINET 接口的型号，这些设备会随 Box 附带一个 GSD 文件（或者 GSDML 文件）。TIA Portal 里在"设备和网络"视图的空闲处右键，选择"从文件中安装 GSD 文件"，导入后就能像添加西门子设备一样把它拖到 PROFINET 网络上。

加了 GSD 文件之后，组态视图里会多出一堆报文类型，但第三方设备的报文数据格式和西门子的标准报文不完全一样，你得对着厂家给的映射表整理一遍输入输出的字。这个工作量不大，但需要细心。我之前导入一款伺服驱动器的 GSD 时，它的报文字节序和西门子默认的字节序不一样，结果现场试运行的时候，速度给定值完全是乱的。后来在驱动器的配置软件里把数据格式调成匹配的字节序，问题立刻就消失了。翻译第十九章里"组态数据一致性"那一小节时，我很自然地联想到了这个案例。

4. 设备协同的高阶玩法：机器人握手和 Muting 功能块

4.1 西门子 PLC 和库卡机器人交互的信号握手设计

热搜词里有"西门子1500和库卡机器人交互"，这也是 AF 框架第十九章里讲得比较重的内容，因为现代产线里 PLC 和机器人的协同监管直接影响节拍和安全。搞过的人都知道，机器人和 PLC 之间的交互，本质上是"信号握手"，不是数据的简单搬运。

先说最基础的 IO 握手。库卡机器人一般提供两组信号给 PLC：一组是机器人当前的工作状态，比如"运行中""程序已停止""急停""异常报警"；另一组是外部自动请求信号，比如"允许启动""程序复位""暂停"。PLC 侧呢，一般定义一套启动序列：机器人安全门关闭、无报警、夹具在初始位置、所有伺服使能正常，然后 PLC 输出一个"允许自动运行"的信号给机器人。机器人收到后执行主程序，到某个位置时输出"周期完成"信号，PLC 收到后控制夹具打开、放行输送线。

这个过程中最常见的问题是什么？信号竞争。比如 PLC 发了"允许启动"，下一秒条件变了（安全光栅被挡住、急停被拍下），PLC 又把它撤掉，但机器人已经进入了启动序列，双方各执一词，最后停在半中间。我自己的经验是：在 PLC 侧对输出信号做脉冲保持处理，即对方没有确认收到之前，输出必须要保持有效且可验证；如果条件中途丢失，不能直接撤信号，要先走一个"请求取消"的互锁逻辑，等机器人回一个"启动取消确认"再复位。这样两边才有明确的应答闭环。

这套信号握手的细节如果只是看官方文档里的函数手册，其实是很难自己全部推出来的，因为官方文档只告诉你输入输出的定义，不会教你怎么设计时序。AF 框架的价值就在这——它把这类经验变成了一套可复用的结构化逻辑，我在翻译第十九章时，特别把这部分内容对照了自己的现场经验做了补充注释。

4.2 Muting 功能块：安全屏蔽不是把安全功能关掉

热词里还出现了"西门子muting功能块"。Muting 存在感很强，但误用率也高，因为大家搞不清"屏蔽"和"旁路"的区别。

在安全术语里，Muting 指的是在特定条件下暂时屏蔽一个安全传感器（通常是光栅或者安全门）的信号，屏蔽期间允许人员或物料通过，屏蔽结束后传感器恢复正常保护功能。关键点是：Muting 是有条件的、有时间的、有方向的。你不能因为"这里要上料方便"就干脆把光栅给旁路了——那是移除安全功能，性质完全不同。

举一个实际场景：AGV 小车要从一个安全光栅隔离的区域穿过，光栅检测到 AGV 进入时肯定要触发急停，但工艺要求 AGV 可以以低速穿过。这时候解决方案是在光栅两侧再装两个传感器，当两个传感器都同时被遮挡时，系统判断有一个体积较大的实体（AGV 而不是人）正在经过，于是临时屏蔽光栅的输出。这个屏蔽只能持续有限的周期，如果超过时间或者传感器状态不满足条件，屏蔽立刻终止，设备回落到安全停机状态。

在博途里实现这个逻辑，习惯上会写到安全程序中，用 F-CPU（故障安全 CPU）的话，需要在安全程序里调用安全相关指令。非安全 CPU 的普通程序里做 Muting 只能做逻辑仿真，不能真正满足 ISO 13849 或 IEC 61508 的安全要求，这点一定得写清楚。

具体实现时，有几个条件我记得特别牢：

这个功能块翻译过来放在 AF 框架的安全层里，本质上它是一个带状态机的安全逻辑：空闲 -> 请求屏蔽 -> 屏蔽中 -> 屏蔽结束 -> 等待复位。任何一步异常，整条线就走故障分支。我在实际项目里是放在 S7-1500F 的 F 运行组里的，用 F-FB 来写，调试起来要特别注意 F 程序块的版本管理，因为安全程序改动是要重新验证签名的。

4.3 延续一下：库卡机器人和西门子的总线耦合方式

除了硬接线 IO 握手，现在更主流的方式是通过 PROFINET 把机器人作为智能设备集成到 PLC 网络里。库卡机器人一般会配一个总线耦合卡，比如 CX1000 控制器的倍福 EtherCAT 或西门子侧的 PN/PN Coupler 方案。

用 PROFINET 集成机器人时，整个通讯本质上还是报文收发。PLC 往机器人侧周期发数据块，里面包括"运行命令""路径选择""速度倍率输出"，同时从机器人侧周期读取"当前位置""当前状态""程序行号"等。这部分跟直接接 IO 的区别在于，交换机网里能传的数据量大得多，而且诊断信息更全。但风险也大——一旦网络有延迟抖动，机器人的安全回路可能先自己动作，因为机器人的安全继电器通常会监控通讯信号中断的情况。

我见过一个项目，PLC 和机器人通过 PROFINET 通讯，中间网络交换机故障导致通讯闪断，机器人立刻报"外部自动停止"。因为现场的布线跨了一个很长距离，链路质量不好，闪断几乎每隔十几分钟发生一次。后来把交换机的端口强制成 100M 全双工，禁止自动协商，故障就压下来了。这种排查经验一般文档里不会写，但凡是实际调过通讯的，应该都懂。

5. 上层与边缘侧：OPC UA 和第三方上位系统的对接经验

5.1 OPC UA 在 AF 框架中的定位：把数据开放出去的安全姿势

热词里反复出现"process simulate-通过opcua与西门子plc进行通讯"和"kepserver4.5连接西门子1500plc"，这两个场景本质上是同一件事：外部系统以 OPC UA 客户端的身份，向西门子 PLC 读写数据。

S7-1500 从固件版本 V2.0 开始原生支持 OPC UA 服务器，不需要额外硬件。在 TIA Portal 里启用 OPC UA 服务器之后，需要做三件事：

1. 在"在线访问"里打开 OPC UA 服务的证书和安全策略；
2. 规划好数据映射——是暴露整个 DB，还是通过 UA 定义好的节点集？
3. 为不同的客户端设置用户权限，最小权限原则。

第二点是我特别想展开的。很多人图省事，直接在 OPC UA 服务器配置里把整个数据块暴露出去，结果 MES 系统一上来就扫描到一大堆内部变量，查问题的时候头都是大的。正确做法是定义一个专门的"交互接口 DB"，只放那些需要给上位系统读写的数据。这个 DB 实际上起的是"API 网关"的作用——PLC 内部随便怎么变，上位系统访问的永远是同一个地址和结构。我在很多项目的通讯规范里就明确要求：开放给 OPC UA 的地址范围，只允许映射到接口 DB 区间，任何内部 DB 不得直接暴漏。

5.2 KepServer 连接 S7-1500 的两个常见问题

说到 Kepware（现在叫 KEPServerEX），这是工业界非常常用的第三方网关软件。KepServer 4.5 连接 S7-1500 的时候，最常见的两个坑是：

第一个是版本兼容性。KepServer 早期版本对 S7-1500 的驱动支持是通过 S7 协议做的，老版本容易遇到"设备型号不匹配"的问题。建议有条件的话升级到较新的版本（比如 6.x），并且确保"通道设置"里的设备驱动选的是"Siemens S7-1500"而不是老的"Siemens S7-300/400"。

第二个坑是连接分区的问题。当你通过 S7-1500 的集成 PN 口访问数据时，CPU 里面有个"连接资源"的概念，每路 OPC UA 或 HMI 连接都会占用资源。如果 CPU 的资源池已经满了（比如有十几个 HMI、30 多个 PUT/GET 连接），KepServer 连接就会异常满时不工作，你需要去 CPU 属性里调大"通信资源"的预留比例。注意，这个修改会改变 CPU 的处理周期，所以不能无脑开到最大。

我见过最极端的情况：某项目 CPU 是 1511-1 PN，HMI 有 10 组，MES 接口、过程数据采集接口都在跑，导致 KepServer 连接上一会儿就断开。后来把 CPU 的"通信接口内存"调整了一下，又把 KepServer 的请求速率降了下来（原来是 100ms 循环读取，改成 500ms），现场就稳定了。所以说，"读太快"有时候反而是问题的源头，上位系统的采集频率要结合 CPU 负载来定，不是越快越好。

5.3 Process Simulate 联合 OPC UA 仿真对调试的价值

Process Simulate 和西门子 PLC 通过 OPC UA 通讯，这种模式非常适合产线虚拟调试（Virtual Commissioning）。在 AF 框架的理念里，程序应该先跟虚拟设备跑通，再下现场。因为很多逻辑性问题（比如机器人是否碰触工装、传感器信号时序是否正确）根本不需要物理设备就能暴露出来。

我自己做虚拟调试的时候发现一个特别实用的技巧：用 OPC UA 连接时，给 Process Simulate 里的传感器信号加一个小的时间抖动（比如 ±50ms 的随机差异）。为什么？因为真实传感器是有响应延迟和抖动误差的，如果仿真里所有信号都"咔嗒"一下瞬间切换，PLC 逻辑看不到真实环境的滤波问题，到了现场才爆雷。用一个简单的随机量模拟传感器的不确定性，反而能让程序更耐操。

这一条虽然不完全算"翻译第十九章"的直接内容，但写出来是因为它跟第十九章"数据交换的可靠性"这一主题也有关系。可靠的数据交换不只是通讯链路的事，更包括你对数据时刻性的判断。仿真阶段就锻炼这种意识，现场会少踩很多雷。

6. 翻译稿成稿后我按此复查了一遍，几个重点问题值得再强调

到这里，西门子 AF 框架第十九章的主要内容基本梳理完了。这个章节的翻译初稿已经完成后，我又结合现场经验从头核对了一遍，发现整理出几条比较一致的高频注意事项，放在这里集中说一次：

第一，约定大于配置。AF 框架里面对名字、地址、报文、接口 DB 的命名有强制规范，翻译成中文文档后，我把这些规范整理成了一张"项目开发前必须对照的表格"，比如：

• 逻辑层接口 DB 统一以If_前缀开头；
• 设备层功能块统一以Drv_前缀开头；
• 硬件组态里的设备名称全部小写字符；
• OPC UA 暴露的数据地址全部限定在If_区段内。

这种约定越细，后面各工程师之间的交接成本就越低。越到后期越能体会到，在调试阶段真正消耗时间的往往不是代码本身写得有多复杂，而是大家各写各的、冲突和歧义满天飞。

第二，报文不只是"拖一个默认的"那么简单。选报文要按工艺功能来选，选完后不要轻易改，要改就得过一遍验收流程。框架文档里有一条写得很好：报文是程序和设备之间的"契约"，改契约是要走变更管理的。

第三，安全功能块（比如 Muting）绝对不在普通程序里实现。如果项目有安全设计需求，一开始就要用带 F 功能的 CPU，并把安全相关逻辑放入 F 运行组。很多新入行的工程师会把 Muting 当成一个普通 FB 去试验，这是非常危险的事，我在第 4 节里也提到了这一点。

第四，OPC UA 和 KepServer 这一类上位通讯，花一点时间把接口 DB 设计清楚，后面能省大量麻烦。接口 DB 就是系统的"外交窗口"——只开需要的端口，只传该传的数据。很多人为了避免前期设计在一个 DB 里堆了几百上千个变量，最后做上位联调的时候效率极低，甚至还会影响扫描周期。

我在实际操作中还有一个感受：翻译这类技术文档，最怕的不是单词看不懂，而是没有现场经验的"直译"会误导读者。比如device name直译成"设备名"大家可能还能理解，parameter telegram如果直译成"参数电报"，新手就完全懵了。所以我的处理方式是：遇到这类术语，保留西门子原文，同时加一个括号注释，把它在工程里的实际作用解释清楚。第十九章翻译完成后，我又在文章末尾加了一个术语对照表，把章节里出现的原文、中文翻译和实际工程含义三者列在一起，方便读者随时翻阅。

最后分享一个基于这套 AF 框架的实践判断：如果你手上的项目只是 20 个 IO、一台 PLC、一条单机设备，那么这套框架的前期投入成本可能真有点大，完全可以简化；但如果是个几十个设备、数百个信号的产线项目，没有一套类似 AF 的标准化框架，到了后期维护和扩展的时候，你会发现自己每天都活在"改了这个功能块会不会搞坏另一个功能块"的恐惧里。框架这东西，越早意识到它对你的意义，你后面的项目就越轻松。