2. TIA Portal项目结构与测试对象识别
在TIA Portal中开展自动化测试与验收，第一步不是打开仿真器，而是把项目“拆开看”。一个典型的TIA Portal项目由PLC变量表、数据块（DB）、函数（FC）、函数块（FB）、组织块（OB）、HMI画面、驱动参数以及IO映射等多个对象组成。这些对象并非孤立存在，它们通过符号寻址、背景数据、调用关系和过程映像形成一张相互依赖的网络。测试对象识别，就是在这张网络中找到“哪些对象需要被验证、验证到什么程度、边界在哪里”。
一、从项目树理解对象层级
在项目树中，PLC通常位于“设备与网络”下，其内部又分为“程序块”“工艺对象”“PLC变量”“设备组态”等文件夹。程序块中，OB是CPU扫描机制的入口，FB/FC是逻辑封装单元，DB是数据载体。HMI则作为独立设备存在，通过HMI变量与PLC变量建立连接。驱动设备（如G120、S210）通常以工艺对象或报文形式挂载在PROFINET/PROFIBUS上，其参数通过驱动报文与PLC的IO地址交互。
识别测试对象时，建议按“执行层—数据层—交互层—驱动层”四个维度建立清单：执行层包括OB、FB、FC；数据层包括全局DB、背景DB、PLC数据类型；交互层包括HMI画面、HMI变量、报警；驱动层包括驱动报文、工艺对象、编码器参数。每一层都有不同的测试关注点，不能混为一谈。
二、PLC变量表与IO映射：测试的“地址锚点”
PLC变量表定义了符号名与绝对地址的对应关系，例如 "StartBtn" → I0.0、"ConveyorMotor" → Q0.1。IO映射则是将物理输入输出、分布式IO、驱动报文的过程映像映射到这些地址上。测试时，变量表是“锚点”：无论是强制输入、监视输出，还是HMI读写，最终都落到这些地址或符号上。
需要特别注意的是，变量表中存在“系统常量”和“用户常量”两类。系统常量由硬件组态自动生成，用户常量由工程师手动定义。测试边界划分时，应明确哪些变量属于“可强制测试点”，哪些属于“只读监视点”。例如，安全相关的F-DI/F-DQ通常不允许强制，只能通过安全程序仿真或专用测试模式验证。
三、DB块：数据一致性的核心测试对象
DB分为全局DB和背景DB。全局DB用于存储跨块共享的数据，如配方参数、状态字、累计产量；背景DB则与FB实例绑定，保存FB的静态变量。测试DB时，重点不是“看数值”，而是验证数据一致性：写入值是否被正确保持、多重背景嵌套时数据是否串位、优化访问与标准访问在符号寻址上的差异是否影响测试脚本。
例如，一个全局DB "DB_Recipe" 中包含 Speed_SP、Temp_SP、Batch_No 三个变量。测试时，可以通过监控表写入 Speed_SP = 1500，然后观察FB中实际使用的速度设定值是否同步变化。如果FB中使用了 DB_Recipe.Speed_SP 的绝对地址访问，而DB被重新编译后地址偏移发生变化，就会出现“写入成功但逻辑未响应”的典型问题。这类问题在验收阶段必须通过符号寻址测试来暴露。
四、FC/FB/OB：调用链与执行顺序
OB决定程序的执行时机：OB1是主循环，OB100是启动组织块，OB35是循环中断，OB82/OB86是诊断中断。测试对象识别时，必须明确每个OB的优先级、循环周期和调用关系。FC是无记忆的逻辑函数，FB是带背景数据的有记忆函数块。测试FB时，要同时验证其输入输出和背景DB中的静态变量；测试FC时，则主要验证输入输出映射和临时变量使用是否正确。
调用链的测试边界划分原则是：如果FB被多个OB调用，且使用同一个背景DB，则测试时必须考虑重入和时序竞争；如果每个调用点使用独立背景DB，则测试可以按实例隔离进行。对于循环中断OB中的PID控制，测试边界应包含采样周期、积分饱和和输出限幅三个关键点。
五、HMI画面与驱动参数：交互层与驱动层的测试对象
HMI画面测试不是“看画面是否好看”，而是验证变量连接、画面切换、报警触发和输入限制。每个HMI变量都对应一个PLC变量或DB地址，测试时应建立“HMI变量—PLC符号—绝对地址”的映射表。例如，HMI上的“启动”按钮连接 "StartBtn"，按下后PLC的 I0.0 是否置位、程序是否响应，这是交互层测试的核心。
驱动参数测试则关注报文配置、控制字/状态字、斜坡函数和限幅。以G120为例，标准报文1包含控制字1（STW1）和状态字1（ZSW1），主设定值（NSOLL_A）和实际值（NIST_A）。测试时，通过PLC写入控制字 16#047F 使驱动使能，观察状态字是否返回 16#FB31 或类似值，再给定速度设定值，验证实际转速是否跟随。驱动参数的测试边界应包含“使能—给定—反馈—故障复位”四个状态。
六、测试边界划分的实操方法
边界划分不是“画个框”，而是回答三个问题：这个对象被谁调用？它的输入来自哪里？它的输出影响谁？以一台输送带控制为例，FB "FB_Conveyor" 被OB1调用，输入来自HMI的启动/停止命令和光电开关，输出控制Q0.1和HMI指示灯。测试边界应包含：HMI命令写入、光电开关信号模拟、FB内部状态机跳转、Q0.1输出监视、HMI指示灯反馈。这五个点构成一个完整的测试闭环。
对于驱动参数，边界划分要区分“参数化”和“运行测试”。参数化阶段验证报文配置、控制字定义、斜坡时间；运行测试阶段验证使能、给定、反馈和故障复位。两者不能混在一次测试中，否则故障定位会非常困难。
七、常见识别误区
第一个误区是“只测FB不测背景DB”。FB的逻辑正确不代表背景DB中的数据保持正确，尤其是多重背景嵌套时，静态变量的地址偏移容易出错。第二个误区是“忽略优化访问与标准访问的差异”。优化DB不支持绝对地址访问，如果测试脚本依赖绝对地址，必须提前确认DB的访问属性。第三个误区是“把HMI变量和PLC变量混为一谈”。HMI变量有独立的连接和刷新周期，HMI上的数值变化不等于PLC中的数值已经变化，反之亦然。
识别测试对象的最终目的，是让每一个测试用例都能明确回答：测什么、在哪里测、怎么判断通过。当项目结构被拆解为可识别的对象清单和边界条件后，后续的测试用例设计、仿真执行和验收判定才有稳定的基础。