1. 为什么我会去啃《AF框架》第十七章做西门子PLC项目的同行应该都有体会真正到了现场最头疼的往往不是写逻辑而是怎么把PLC的数据稳定地送到上位机、SCADA、或者第三方面板里。我最近接了一个改造项目现场是S7-1500上位机用的Intouch中间网关用的是Kepware要求走OPC UA通信。设备对接的活儿倒是不复杂麻烦的是甲方要求程序结构必须按照西门子AF框架的标准来写——这就逼着我去翻英文原版文档找AF框架里对通信模块的规范定义特别是第十七章通信框架的通用设计。这一章翻完加上现场调完很多当初看不清的坑就全明白了。这篇文章就是把我翻译和实践第十七章的过程整理一遍顺手也把踩过的坑记下来希望给正在做类似项目的朋友省点时间。1.1 先说说AF框架到底是什么AF框架全称是Automation Framework西门子官方提供的自动化项目标准化参考架构。你把它理解成一套PLC程序的积木体系就行每个功能模块封装成标准的功能块FB配合规定的数据块DB和接口命名再把调用方式、程序循环周期、报警处理、HMI接口都约定好。为什么要搞这么一套东西因为大型项目动辄几百个功能块如果没有统一结构后面的人接手维护就是灾难。AF框架的作用就是让不同工程师写出来的程序长得像同一个人写的设备调试、代码复用、故障排查的效率能提高一个档次。AF框架涵盖的内容很多从硬件组态、程序结构、安全功能到通信都有。我之前用的比较多的是它关于程序分层的思路把应用层、驱动层、诊断层分开层与层之间通过标准接口传递数据。比如你写一个电机控制逻辑驱动层只管启停、反馈应用层管联锁、工艺流程互不干扰。我这次要翻译的第十七章正是通信层的通用框架设计包括通信功能块的封装、数据映射规则、与上位机交互的推荐方式。说实话这些内容单独看网上也能找到零散资料但散落在论坛里的经验大多不成体系官方的这一章算是把设计思路完整讲透了。1.2 第十七章对我手头项目的意义我的项目需求其实很典型S7-1500作为主站既要和现场的变频器跑Modbus RTU又要通过OPC UA把数据暴露给Kepware再由Kepware转给Intouch。这里面有个关键点AF框架要求所有通信功能都要封装在专门的功能块里不能直接在OB1里写一堆Raw的通信指令。第十七章讲的就是这套封装方法——你设计一个通用的通信FB输入输出参数对外标准化内部再去调用西门子通信协议指令这样上位机侧只需要面向这个FB的接口来读写数据底层换成什么协议都不影响上层逻辑。翻译这一章还有一个现实原因我们项目组里有新来的工程师对PLC通信的细节并不熟。如果按AF框架的规范来做新同事只需要照着功能块接口填参数就可以了不需要理解底层报文结构。这个价值在日常维护时特别明显——设备停机的时候谁还有心思翻手册看报文如果通信异常在功能块接口上直接有清晰的Error状态和诊断码排查速度会快很多。所以第十七章里简化接口、统一诊断的设计理念恰恰是现场最需要的。2. 翻译之前的准备工作术语和背景很多人以为翻译英文技术文档就是逐句变成中文其实不是。西门子的官方文档用词严谨很多术语在中文语境里有固定的习惯译法翻错了就会误导读者。我拿到第十七章先没急着翻而是花了半天时间把涉及到的术语和背景知识做了个梳理。2.1 绕不开的几个英文术语我整理了一个术语对照表对做翻译和阅读原版文档都比较有用列出来供参考英文术语中文习惯译法说明Application Framework应用框架即AF框架西门子自动化项目标准化参考结构Function Block (FB)功能块带背景数据块的程序块是AF框架的核心封装单位Instance Data Block背景数据块功能块被调用时生成的专用数据存储区Interface接口功能块对外的输入/输出参数Organization Block (OB)组织块由操作系统循环/事件触发的程序块如OB1Retentive Memory保持性存储区断电后数据不丢失的存储区域Transport Connection传输连接通信双方建立的逻辑连接Endpoint端点通信连接的物理或逻辑访问点Catalog目录/库可复用的功能块目录Diagnostics诊断信息用于定位故障的状态数据这里要特别说下Instance Data Block很多人直译成实例数据块但在国内西门子技术圈里一般叫背景数据块因为它是某个FB在调用时自动生成的、专门背在该FB后面的数据区。翻译的时候用背景数据块老师傅一看就懂如果用实例数据块虽然意思对但沟通成本高。2.2 为什么不能只看翻译而不看程序文档里的文字描述再清楚也替代不了在TIA Portal里实际建一个FB看一眼。我在翻译第十七章的过程中几乎是每翻一小节就打开博途TIA Portal把对应的代码块建出来跑一遍。为什么这么麻烦因为AF框架里有很多隐性约定是文字难以描述的比如功能块接口参数命名必须带前缀例如bEnable表示布尔使能iSpeed表示整数速度这个在文档里只是一句话但实际代码里到处都是这样的命名规则。你不亲手敲一遍根本不会注意到这些细节对可读性的影响。还有一个原因是第十七章里涉及了不少和通信协议相关的概念比如OPC UA的服务器端点、客户端证书等。如果不实际操作看到Endpoint地址、Security Policy这些词就只是字面意思很难理解为什么上位机要配置访问列表。我建议任何读AF框架文档的人都准备一个虚拟PLC环境不需要实体硬件用S7-1500的仿真PLC就行配合博途的仿真功能很多通信逻辑其实也能模拟。当然OPC UA通信仿真和真实PLC还是有点区别但至少能把功能块的逻辑调通。3. 第十七章的核心内容拆解AF框架的通信模块第十七章的内容我看下来其实就三个层次一是通信功能块的接口怎么设计二是数据块怎么规划三是怎么和上位机/第三方软件安全对接。下面我把这三个层次逐个展开。3.1 从功能块的接口设计说起这一章一开始就强调通信功能块的设计目标是把复杂协议藏着对外提供简单的启停接口。AF框架推荐的做法是定义一个标准的CommsFB里面分为控制接口和数据接口。控制接口常包括bEnable整体使能通信块bReset复位错误状态sErrorCode错误码如果有异常输出对应IDiState通信状态比如0空闲1建立连接2交换数据数据接口就是你要传给对端或者从对端读到的实际数据比如温度、压力、转速按功能分好输入输出。我照着第十七章的示例写了一个简化的SCL功能块逻辑FUNCTION_BLOCK FB_CommsS7 TITLE : AF Standard Communication Block VERSION : 0.1 VAR_INPUT bEnable : BOOL : FALSE; // 总使能 bReset : BOOL : FALSE; // 错误复位 sDataToSend : ARRAY[0..9] OF REAL; // 需要发送的10个浮点数 END_VAR VAR_OUTPUT bError : BOOL; // 错误标志 iState : INT; // 状态 sErrorCode : STRING[20]; // 错误码 sDataReceived : ARRAY[0..9] OF REAL; // 接收到的数据 END_VAR VAR_IN_OUT // 不需要 END_VAR VAR_TEMP iLoop : INT; END_VAR BEGIN // 默认赋初值 bError : FALSE; iState : 0; sErrorCode : ; // 主逻辑框架 IF bEnable THEN iState : 10; // 通信激活 // 这里调用真正的通信指令 // 例如 TCON、TSEND、TRCV 或者 OPC UA 方法 // 注意第十七章要求将协议细节封装在内部 ELSE iState : 0; END_IF; END_FUNCTION_BLOCK这段代码本身不是重点重点是第十七章要求的功能块内部必须包含完整的状态跃迁逻辑建立连接、保持心跳、超时重连、错误上报每一步都要有清晰的状态值。功能和协议直接写在OB1里虽然一时省事但以后每加一个通信就要重写一遍而且诊断困难。这个接口统一、内部屏蔽的思路其实和面向对象编程里的封装思想是一模一样的——只不过PLC环境下我们用的是FB和背景DB来实现而已。3.2 通信数据块DB的规划与背景数据块AF框架对数据块规划有明确规定每个通信客户端必须有一个独立的通信描述DB记录连接参数、通信状态、数据镜像。为什么要单独建DB因为TF通信功能调用时需要一个存储区来保存连接信息而且这个数据区最好是保持性的见2.1的术语表否则PLC断电再上电通信状态又得从头建立某些需要快速恢复的场景就会出问题。我在项目中设计了三类DBCFG_DB存放通信配置比如IP地址、端口号、站号这些由现场工程师人工维护STATUS_DB存放通信的状态标志包括在线/离线、错误码、时间戳DATA_DB存放实际的过程数据从现场仪表读到的值、要发给变频器的频率等。它们在层级上是分开的避免一锅烩。到了HMI侧组态时只要绑定STATUS_DB和DATA_DB操作员能看到状态和数据但不会误改配置。这个思路特别适合多设备、多协议混合的场景比如同一套S7-1500下一条Modbus RTU链路管一排仪表另一条Modbus TCP链路管几个变频器两条链路的CFG/STATUS/DATA完全分离各自独立运行互不干扰。3.3 与第三方系统对接时的关键控制点如果说通信功能块是框架的骨架那数据映射就是框架的血液循环。第十七章特别提到PLC内部的数据要与外部系统交换不能直接把CPU的内存地址暴露给上位机而是要通过一个标准化的数据映射表进行转换。这样做的好处是即使现场工艺改了只需要修改映射表上位机侧的地址不用变。我见过不少项目上位机强引用DB地址PLC一加功能块地址偏移上位机就得跟着改一大堆非常痛苦。AF框架推荐的做法是把上位机需要的数据集中收集到一个数据交换DB中比如DB_ProcessData其中定义结构化变量包含布尔、整型、浮点等类型并留适当的填充位。然后用OPC UA把这些变量暴露出去。这样上位机通过OPC UA读取DB_ProcessData中的变量时看到的地址是稳定的比如OPCUA.S7-1500.DB_ProcessData.Temperature而不是DB12.DBD20。这种间接访问的设计思想在第十七章里花了不小的篇幅讲实际操作时确实是能省掉大量后期维护的时间。还有一点值得提醒OPC UA通信涉及安全策略。AF框架文档里明确要求PLC的OPC UA服务器上要启用证书管理并为每个上位机客户端生成独立证书。如果只是测试环境可以直接把安全策略设置为无加密但工业现场这么做很危险。我在项目里就是最开始图省事把安全策略设成了None后来甲方安全审计直接不给过只能重新搞证书。这个流程很繁琐但必须做。4. 实际配置和操作实录讲完理论说说实际操作。这块我把翻译第十七章时自己动手做的配置步骤和代码示例整理出来尽量按现场施工的逻辑走一遍。4.1 在博途里创建通信FB新建一个功能块命名为FB_CommsS7接口按3.1里的模板定义。然后进入内部程序用SCL写状态机和具体通信调用。我这里以S7-1500通过开放式以太网与Kepware通信为例Kepware这一侧配置成OPC UA服务器时PLC作为客户端去连接它。配置步骤大概是在PLC设备属性里启用OPC UA服务器功能生成并导出PLC的证书这个证书要安装到Kepware的信任列表里在Kepware中新建一个OPC UA Client通道填入PLC的IP地址和端口默认4840编写PLC侧的功能块使用OPC UA相关的系统指令库中的方法构建连接和数据读写请求。因为AF框架第十七章里明确建议不要直接在一个功能块里写完所有协议而是把连接管理和数据读写分成两个FB一个负责维护会话一个负责传输数据。我照做了调试时确实方便连接保持和定时重连的逻辑在连接管理FB里数据读写FB只管数据的打包、解析和校验。两个FB通过背景DB交换握手信息。这样出错后定位很快连接问题看第一个FB数据问题看第二个FB。4.2 通过OPC UA和Intouch联调上位机侧我用Kepware做OPC UA Server的网关Kepware采集S7-1500的数据然后Intouch通过Kepware的OPC接口读数值。这样做的好处是Intouch不直接面对PLC任何PLC侧的改动只要Kepware这边重新映射一下即可Intouch侧的点名不用动。第十七章讲的是一个结构良好的通信层需要支持多级中转这个架构正是多级中转的实例。联调时的要点是地址命名一致性。我在AF框架的数据交换DB里把每一个变量都定义了友好的符号名比如Mixer_Speed、Tank_Level等。然后Kepware里创建通道时导入这些符号名Intouch里再引用。全程都用符号名不用绝对地址。这样一来变量对应关系在报表、报警、历史记录中都是一目了然的。如果你在博途里给PLC变量起名叫Tag_1、Tag_2到了Intouch里还得翻译很容易出错。4.3 证书验证和处理安全配置里最麻烦的是证书。在TIA Portal中S7-1500的OPC UA服务器可以自动生成自签名证书但也需要为每个客户端生成不同的信任证书。具体操作在项目的OPC UA配置界面里添加客户端证书并把客户端的公钥证书导入到PLC的Trust List同时PLC的证书也要导出安装到客户端机器的证书存储区。两边互相认证过才能建立安全连接。我也见过有同行图省事直接把S7-1500的OPC UA安全策略设置为No encryption, No authentication这样联调确实快但现场验收时肯定被卡。更关键的是一旦网络安全要求提高后续改造牵扯面更大。所以还是建议从最开始就把证书做起来一次到位。5. 常见问题排查速查这一章翻译下来我在现场也积累了不少实际问题。挑几个最常见的说说基本都和通信调试有关。5.1 数据不刷新PLC侧看变量有值上位机读到的是旧值这种问题十有八九出在Kepware的扫描周期和PLC缓存上。Kepware作为一个OPC Server会按自己设的扫描周期去读PLC如果你把扫描时间设成10秒那数据当然会慢半拍。另外如果PLC内部把数据写到了普通DB但没有标记为非保持性或者掉线保持上位机在通信瞬断时可能抓到的还是旧值。我个人的习惯是在数据交换DB里加一个数据有效性标志每次PLC和上位机握手成功后刷新这个标志上位机读到标志为无效时就认为数据不可信这样比直接显示旧值安全得多。5.2 连接时好时坏断开了能自动恢复但偶尔要手动重启这个问题多出在连接管理FB的重连策略上。AF框架第十七章里推荐的重连逻辑是初始连接失败后先等5秒重试连续失败5次后把间隔拉大到30秒然后再试而不是每次失败都固定短间隔重试。很多工程师第一次写重连失败就立即重试结果把网络资源耗尽越试越死。我按照第十七章的思路改好了重连间隔现场基本就没有再出现这种手动重启才能恢复的假死情况。5.3 问题对照速查表现象可能原因排查方向上位机读不到PLC数据证书未信任检查PLC和Kepware/OPC UA客户端证书的信任关系数据偶尔跳变数据类型长度不匹配检查S7和上位机侧的数据类型长度如REAL是否映射为Float32通信状态一直为正在建立连接端口/端点地址错误核对PLC OPC UA的服务端点默认4840端口确认没有防火墙拦截重新上电后通信不恢复连接描述DB没有保持性将连接状态DB属性改为保持性确保断电后连接状态可以恢复调用多个通信FB时报错背景DB重复使用每个FB实例必须有独立背景DB不能复用同一个实例OPC UA主题里出现大量错误日志安全策略不匹配客户端与服务器需指定相同安全策略比如Basic256Sha256如果你在做类似项目我建议直接把这张表打印出来放现场方便快速排查。6. 最后分享两个翻译和编程的私人心得翻完第十七章最大的感受是西门子的AF框架文档不是一本语法手册而是一本设计指南。里面很多章节看起来没有直接可抄的代码但字里行间全是经验。第十七章关于通信的部分教会我的是——做PLC通信不要一上来就敲指令先花时间想清楚数据从哪来、到哪去、断线了怎么办、上位机怎么用。功能块的接口设计其实就是在替甲方定规矩。另一点小技巧是翻译时不要孤立翻最好边翻边在博途里建一个测试项目边做边验证。第十七章里有一段讲通信状态机的状态转移条件我一开始没看明白后来在仿真PLC里单步调试看到状态值从10跳到20再跳到30的过程才真正理解。纸上得来终觉浅PLC这行尤其如此。以后我每翻译一章都会把动手验证的时间预留出来看似多花了一倍时间实际省了后面调试的十倍时间。