从 PLC 仿真挑战中学习：实用指南
Roland Schulz 先生 2002 年博士论文中的这段厚重论述很好地总结了整个问题的核心。
简而言之：“尝试和测试有助于发现错误”。
这里不讨论整个生产工厂的仿真，而是将原则进一步细化到单个单元（组件），如自动化程序或用户项目。
过去，作为 Phoenix Contact 的年轻员工，我也曾学习编程，若当时有控制器仿真，我定会乐于通过“试错”深入了解功能块或程序的运行和功能。遗憾的是当时不存在，后来出现的 PLC 仿真功能也非常有限。IEC 61131-3 代码仿真尚可，但缺乏对特殊设备的支持，或仅仅是 Intel、ARM 或 Motorola 架构系统间代码行为差异的支持。
怀揣这些想法和对“经典”PLC 仿真痛苦的记忆，我们着手寻找真正有增值且不产生巨大工作量的方案——既包括仿真开发的工作量，也包括后续使用中可能产生的工作量。
作为用户，我希望能通过一次鼠标点击将项目发送到 PLC 或仿真环境。我不想关心处理器架构，更不想被迫在代码中隐藏甚至移除仿真不支持的功能。
还有什么比在仿真中使用真实控制硬件上也在运行的真实固件更自然？这正是我们所做的。
如今存在成熟的系统仿真，不仅允许在 Windows 下运行各种操作系统，还能仿真各种处理器架构及其特性。
我们的控制器基于 Linux 并非秘密。但对于代码开发而言，这里也使用不同的处理器架构这一事实至关重要。
在工程软件（即 PLCnext Engineer）中，客户应能在控制器 IP 地址与仿真之间单击鼠标即可切换，无需担心进一步的代码适配或二进制代码兼容性。
这些想法产生了什么成果？
我们发现了系统仿真 QEMU 并用于仿真控制器。QEMU 是一款“开源机器仿真器”，完全符合我们的需求。
“仅仅”在其中运行固件，QEMU 即可仿真 PLCnext Technology 的完整 Linux 系统，包括部分 PLCnext 控制器的 ARM 处理器架构——PLCnext 仿真由此诞生。诚然，我们包含了一些次要限制。PROFINET 通信或其他通信协议被禁用。但 OPC UA 服务器等不受影响。
然而，PLCnext Technology 的所有特殊功能均得以保留。因此我也可将 C/C++、C# 或 Matlab Simulink 程序和组件发送至仿真。Store 中针对特定应用的 APP 也可投入执行。
一些进一步限制显而易见——不应指望这种仿真系统具备确定性。视我的 Windows 系统负载而定，PLCnext 仿真上可能出现看门狗错误。但这种情况下，我可在 Windows 系统中给仿真进程更高优先级，看门狗错误即可快速解决。
现在我终于拥有了一个控制器的仿真，或者视定义而定，甚至是仿真器。但遗憾的是我曾不得不在没有它的情况下学习编程，现在也不怎么编程了。
工业技术