2. 虚拟调试环境搭建与工具链选型

虚拟调试（Virtual Commissioning）的核心思路，是在真实设备到货之前，用软件模型替代尚未就位的机械、电气与执行机构，让 PLC 程序、机器人程序、上位控制逻辑能够提前运行、提前暴露问题。要把它落地，第一步不是写测试用例，而是搭出一套"能跑起来、能复现、能扩展"的环境，并选对工具链。本节围绕三件事展开：主流虚拟调试平台怎么选、自动化测试框架怎么接进去、环境与版本怎么管。

一、主流虚拟调试平台的能力分层

市面上的虚拟调试工具看似很多，但按"仿真什么对象"可以清晰分成三层，选型时先定位自己需要哪一层，再谈品牌。

• PLC 逻辑仿真层：以 PLCSIM Advanced、CODESYS SoftPLC、TIA Portal 仿真 CPU 为代表。它们运行真实的 PLC 程序（OB/FB/FC、DB 块），提供虚拟网卡或 API 接口，让外部程序读写 I/O、DB 变量。这一层解决的是"控制逻辑对不对"。
• 机器人/运动仿真层：以 RoboGuide、RobotStudio、KUKA.Sim、Process Simulate 为代表。它们带运动学模型、可达性分析、节拍计算，能输出机器人关节角、TCP 位姿、I/O 信号。这一层解决的是"动作轨迹与节拍对不对"。
• 数字孪生/工厂级仿真层：以 Plant Simulation、Visual Components、NVIDIA Isaac Sim 为代表。它们关注整线物流、节拍平衡、AGV 调度、产能瓶颈。这一层解决的是"系统级行为对不对"。

三层并非互斥。典型项目是"PLC 仿真 + 机器人仿真"通过 OPC UA 或共享内存对接，数字孪生层再向上聚合。选型时不要只看功能列表，重点看三个硬指标：是否支持真实 PLC 程序（而非重写逻辑）、是否开放 API 供自动化脚本驱动、是否支持信号级联调（I/O 映射、时序对齐）。如果工具只能"看动画"而不能被脚本读写变量，它就无法进入自动化测试链路。

二、自动化测试框架的集成方式

虚拟调试平台本身通常只提供"手动操作 + 观察"的界面，要自动化，必须通过它开放的接口把变量读写、仿真启停、状态查询暴露给测试框架。集成方式主要有三类。

第一类：PLC 变量级读写。这是最常用、最稳定的方式。以 PLCSIM Advanced 为例，它提供 API 接口，Python 可通过 pycomm3 或 snap7 连接仿真 CPU，直接读写 DB 块中的变量。测试用例的典型结构是：写入输入变量 → 等待若干扫描周期 → 读取输出变量 → 断言。例如验证一个电机启动逻辑：向 DB1.StartBtn 写 True，延时 200 ms，读取 DB1.MotorRun，期望为 True；再写 DB1.StopBtn 为 True，读取 DB1.MotorRun，期望为 False。这种用例不依赖界面，可在 CI 中批量执行。

第二类：机器人仿真 API 驱动。RobotStudio 提供 .NET API，RoboGuide 提供 PC SDK，可通过 C# 或 Python 封装调用，实现"设置机器人到某位置 → 读取关节角 → 校验是否在安全范围"这类用例。注意机器人仿真的时间尺度与 PLC 不同，需要显式同步，否则会出现"PLC 已发信号、机器人还没到位"的假失败。

第三类：信号级联调。当 PLC 仿真与机器人仿真对接时，需要建立 I/O 映射表，把 PLC 的输出位映射到机器人的输入信号，反之亦然。这张映射表本身就是测试资产，应纳入版本管理。联调时最容易被忽略的是时序对齐：PLC 扫描周期可能是 10 ms，机器人仿真步长可能是 50 ms，若测试用例按固定延时断言，就会不稳定。推荐做法是"轮询 + 超时"：循环读取目标变量，直到满足条件或超过 2 s 超时，而不是死等固定时间。

三、环境配置与版本管理要点

虚拟调试环境比普通软件开发环境更"重"，因为它同时包含 PLC 工程、机器人工程、仿真配置、测试脚本四类资产，且它们之间存在版本耦合。管理不当，最常见的问题是"昨天还能跑的用例今天跑不通"，而原因只是某个 DB 块偏移量变了。

建议按以下要点组织：

• 工程文件与脚本同仓管理：PLC 工程（.ap 系列）、机器人工程、测试脚本放在同一 Git 仓库，用分支对应功能开发，用 tag 对应可复现的测试基线。二进制工程文件建议配合 Git LFS。
• 接口契约显式化：把 DB 块变量名、偏移量、数据类型、I/O 映射表写成一份 interface.yaml 或 CSV，测试脚本从该文件生成变量访问代码，而不是硬编码地址。这样 DB 块调整时只需改契约文件。
• 环境快照与依赖锁定：记录 PLCSIM Advanced 版本、TIA 版本、Python 依赖版本（requirements.txt 或 pyproject.toml），并在 CI 中固定。仿真软件版本升级往往改变 API 行为，必须显式验证。
• 仿真启停脚本化：把"启动仿真 CPU → 下载程序 → 切换到 RUN → 执行用例 → 停止仿真"写成脚本，避免人工操作引入差异。每次测试从干净状态开始，是结果可复现的前提。

下面给出一份可直接参考的环境配置清单，字段按实际项目填写：

把这三件事做好——选对分层工具、用 API 而非界面驱动测试、把接口契约和版本纳入管理——虚拟调试环境才具备"可自动化、可复现、可扩展"的基础。后续的测试用例设计、批量执行与报告分析，都建立在这套环境之上。