2. 虚拟调试平台与工具链

虚拟调试的故障注入能力，并不取决于某一个软件“能不能仿真”，而取决于整条工具链能否把故障条件注入到被控对象模型、控制程序或通信链路中，并让异常在可观测的信号上稳定复现。Plant Simulation、NX MCD、TIA Portal、CODESYS 四类工具在工具链中承担的角色不同，故障注入的切入点也完全不同。选型时若只看“支持不支持仿真”，很容易在项目后期发现故障根本注不进去，或者注进去之后无法判断控制程序是否真的响应了异常。

四类平台在故障注入中的定位

Plant Simulation 属于物流与产线级仿真平台，强项是节拍、缓存、可用率和物料流。它的故障注入通常以资源失效、停机时间分布、维修时间、可用性参数的形式出现，例如把某台设备的 MTBF 设为 120 min、MTTR 设为 8 min，观察缓存区是否溢出、上游是否阻塞。它不直接执行 PLC 代码，因此适合验证“设备级异常对产线吞吐的影响”，不适合验证“某个传感器信号抖动时控制逻辑是否误动作”。

NX MCD 是机电概念设计工具，核心是刚体、碰撞体、运动副、传感器与执行器。它的故障注入更贴近物理层：可以把某个位置传感器的触发区间改偏、把气缸行程缩短、把输送带速度设为异常值，或让某个碰撞体暂时失效。MCD 常与 TIA Portal 通过 PLCSIM Advanced 联合仿真，此时 MCD 负责“设备动作与信号”，TIA Portal 负责“控制逻辑”，故障可以分别从两侧注入。

TIA Portal 配合 PLCSIM Advanced 或 PLCSIM，是西门子控制程序虚拟调试的主力。它的故障注入能力体现在：强制 I/O 变量、修改 DB 块中的过程值、在 OB 中插入临时故障逻辑、通过 API 从外部脚本改写输入映像。例如在 PLCSIM Advanced 中把 %I0.3 强制为 TRUE 模拟限位开关常闭触点断开，或在循环中断 OB 中把某个模拟量通道乘以 1.2 模拟漂移。它的优势是控制程序真实执行，因此故障响应逻辑可以被完整验证。

CODESYS 是独立于硬件的 IEC 61131-3 开发环境，支持 SoftPLC 运行在 Windows 或 Linux 上。它的故障注入更灵活：可以直接在应用层写测试代码，也可以通过 SysFile、CmpSettings 等库修改运行参数，或利用 CODESYS Test Manager 编写自动化测试用例。对于非西门子控制器或需要跨品牌验证的场景，CODESYS 常作为“控制侧”的虚拟执行环境。

接口与数据交换方式

故障能否注入，关键看接口是否开放。TIA Portal 与 NX MCD 之间常用 PLCSIM Advanced 的共享内存或 API，MCD 把传感器信号写入 PLC 输入映像，PLC 输出驱动 MCD 中的执行器。此时若要在控制侧注入故障，可以用 PLCSIM Advanced 的 SetInput 接口直接改写输入；若要在设备侧注入，则修改 MCD 中传感器的触发位置或运动副参数。Plant Simulation 与 PLC 的耦合通常通过 OPC UA、Socket 或专用接口，故障注入以修改仿真模型中的资源参数为主，不直接改写 PLC 变量。CODESYS 则可以通过 Test Manager、CmpSettings 或自定义测试工程，在 SoftPLC 内部按测试用例改写变量，适合做批量回归。

一个常见的误区是：在 Plant Simulation 里把某台设备设为“故障”，就认为验证了控制程序的异常处理。实际上 Plant Simulation 的故障只影响物流模型，PLC 侧可能完全不知道。正确的做法是让 Plant Simulation 通过接口把“设备故障”状态传给 PLC，或者直接在 PLC 侧强制对应输入，再观察 PLC 输出是否让产线进入安全状态。

选型要点

选型时建议按以下顺序判断：

• 故障注入点在哪里：如果重点是控制逻辑对传感器异常的响应，优先选 TIA Portal + PLCSIM Advanced 或 CODESYS；如果重点是设备动作干涉，优先 NX MCD；如果重点是产线级停机与缓存，优先 Plant Simulation。
• 接口是否可编程：能否用脚本或 API 批量改写变量、批量执行测试用例。PLCSIM Advanced 提供 .NET API，CODESYS 提供 Test Manager，Plant Simulation 提供 SimTalk，MCD 提供信号映射与外部接口。接口越开放，自动化故障注入越容易。
• 时间同步与实时性：联合仿真时，MCD 与 PLC 的仿真步长是否一致，Plant Simulation 的离散事件与 PLC 的循环扫描如何对齐。步长不一致会导致故障注入后信号抖动或丢失。
• 观测与断言能力：能否在故障注入后自动判断“报警是否触发、停机是否执行、恢复后是否回到基线”。CODESYS Test Manager 和 PLCSIM Advanced API 支持断言；Plant Simulation 更依赖实验管理和结果统计。
• 许可与部署成本：PLCSIM Advanced 需要额外授权，MCD 需要 NX 环境，Plant Simulation 独立授权，CODESYS 有免费版但高级测试功能需授权。选型时要结合团队已有软件资产。

一个可执行的故障注入配置示例

以 TIA Portal + PLCSIM Advanced 为例，假设要验证“输送带入口光电传感器 %I0.3 持续为 TRUE 时，PLC 是否在 2 s 内触发堵塞报警 %Q1.1”。可以在 PLCSIM Advanced 的 API 中写入以下伪代码逻辑：

// 示例：通过 PLCSIM Advanced API 强制输入并观测输出
plc.SetInput("I0.3", true);          // 模拟传感器被持续遮挡
Thread.Sleep(2500);                   // 等待 2.5 s，超过报警延时
bool alarm = plc.GetOutput("Q1.1");   // 读取堵塞报警输出
if (alarm == true) {
    // 报警触发，继续验证恢复逻辑
    plc.SetInput("I0.3", false);
    Thread.Sleep(1000);
    bool reset = plc.GetOutput("Q1.1");
    // 期望 reset == false，否则报警未复位
}

这段逻辑的关键参数是：报警延时 2 s、观测等待 2.5 s、恢复等待 1 s。这些数值应来自控制程序的实际定时器设定，而不是随意假设。若报警未触发，需要检查 %I0.3 是否真的写入了输入映像、OB 循环是否在运行、报警定时器是否被其他条件复位。若恢复后报警未消失，则要检查复位逻辑是否依赖传感器下降沿或手动复位按钮。

对于 CODESYS，可以把上述逻辑写成 Test Manager 的测试用例，用 Assert 判断输出；对于 NX MCD，则把 %I0.3 对应的传感器触发区间临时改为“始终触发”，再观察 PLC 输出。不同平台的操作方式不同，但判断依据一致：故障条件是否真实进入控制程序、控制程序是否在设定时间内产生预期响应、故障消失后系统是否回到可继续运行的状态。

选型检查清单

选型没有唯一答案，关键是先明确“要验证哪一类异常”，再检查工具链是否能把该异常注入到正确的层级，并且有足够的接口和观测手段判断响应是否正确。如果故障注入点与控制程序不在同一层，就必须确认两层之间的信号映射是否完整、时序是否一致，否则虚拟调试会变成“看起来跑了，但异常根本没传到该到的地方”。