软 PLC 的实时性能测试方法

软 PLC（Soft PLC）是将传统 PLC 的控制功能移植到通用计算机或嵌入式处理器上运行的软件系统。与传统硬件 PLC 相比，它依赖操作系统的调度。测试的核心在于验证其控制周期是否稳定，以及在负载增加时是否会出现任务超时。以下指南将直接指导你完成从环境搭建到数据分析的全过程。

第一阶段：测试环境与工具准备

在开始编写测试程序前，必须确保底层硬件和操作系统能够满足实时性要求。普通 Windows 桌面系统无法保证微秒级的确定性响应，因此需要特定的内核支持。

1. 安装 带有实时扩展功能的操作系统。推荐选择配置了 Xenomai 补丁的 Linux 发行版，或者带有硬实时支持的 Windows IoT 版本。不要直接在标准桌面版 Windows 上执行高精度测试。
2. 连接 高性能计数器或示波器作为外部基准。如果条件有限，可以使用同一台机器上的高精度软件定时器作为参考源。
3. 下载 软 PLC 运行时库（Runtime Library）。确保版本与你的控制器代码完全匹配。
4. 配置 网络参数（如果涉及分布式 IO）。将网卡固定为静态 IP，关闭自动获取地址功能，并禁用不必要的后台服务以减少中断干扰。

第二阶段：核心参数配置

实时的关键在于“周期”。你需要定义控制循环的时间长度以及允许的误差范围。过短的周期会超出 CPU 处理能力，导致丢步；过长的周期则失去实时意义。

请根据被控对象的要求，在软 PLC 的工程文件属性中修改以下关键参数：

注意：上述参数必须在编译生成二进制文件之前锁定。如果在运行时动态调整周期，可能会引入额外的上下文切换开销，影响测试结果。

第三阶段：编写与部署测试逻辑

测试程序本身不能产生副作用。你需要创建一个简单的闭环逻辑，用于记录时间戳。该逻辑不需要控制电机或阀门，只需占用 CPU 资源并打点。

1. 创建 一个新的全局变量，命名为 cycle_start_time，类型为 LREAL（长浮点数）。

2. 定义 另一个变量 jitter_count，类型为 INT，初始化为 0，用于统计异常次数。

3. 插入 以下伪代码到你的主程序循环（OB1）中：

   // 读取当前高精度时间戳
   current_time := GetHighResTime(); 
   
   // 计算距离上次周期的时间差
   delta_time := current_time - last_cycle_time;
   
   // 更新总时间戳
   last_cycle_time := current_time;
   
   // 判断偏差
   IF ABS(delta_time - nominal_period) > max_jitter THEN
       jitter_count := jitter_count + 1;
   END_IF;

   其中 nominal_period 是你预设的目标周期，例如 0.001 代表 1 毫秒。

4. 编译 整个工程，检查是否有任何语法警告。

5. 上传 可执行文件到目标机器的指定目录，路径建议为 /opt/plc/runtime/app.bin。

第四阶段：运行监测与数据采集

程序就绪后，进入实测环节。这一阶段必须保持现场安静，关闭所有浏览器、杀毒软件和即时通讯工具，防止它们抢占 CPU 时间片。

1. 启动 软 PLC 服务进程。使用命令行工具输入 sudo systemctl start soft-plc。
2. 监控 系统负载率。打开系统监视器，观察 CPU Load。理想状态下，空载时应低于 10%。如果超过 40%，说明背景干扰过大，需排查原因。
3. 记录 连续运行时长。建议至少持续运行 1 小时。短时间的测试可能无法捕捉到偶发的系统调度延迟。
4. 导出 日志文件。找到生成的 .csv 或 .txt 日志，文件名通常包含时间戳。
5. 停止 测试任务。输入 sudo systemctl stop soft-plc 确保数据落盘。

第五阶段：数据分析与判定标准

拿到数据后，不能仅凭感觉判断。你需要依据数学公式计算具体的抖动指标，并结合逻辑流程图确定是否合格。

1. 计算抖动系数

抖动（Jitter）反映了稳定程度。计算公式如下：

$$ Jitter = \frac{\sum |T_{actual} - T_{nominal}|}{N} $$

其中：

• $T_{actual}$ 为每一次扫描的实际周期时间。
• $T_{nominal}$ 为理论设定的周期时间（如 0.001 秒）。
• $N$ 为采样总次数。

若计算出的平均抖动值大于配置表中定义的 最大抖动允许值，则视为不达标。

2. 判定逻辑流程

分析过程遵循以下决策路径。首先确认是否有任务丢失，然后检查抖动分布，最后评估整体可用性。

图中逻辑说明：如果发现任何一次周期完全未执行（即出现两次采集间隔超过 2 倍周期），直接判定为丢包失败。这通常意味着发生了严重的中断阻塞。即使没有丢包，如果单次最大值超过了阈值的两倍，也说明系统抗干扰能力不足。

3. 常见问题处理表

在分析过程中，你可能会遇到以下典型问题，请参考下表进行排查：

4. 最终验证步骤

完成上述分析和修正后，需要进行最后一次回归测试来验证修复效果。

1. 重复 第三阶段和第四阶段的运行测试。
2. 对比 新产生的数据曲线与前一次的结果。
3. 确认 波动范围收缩至安全区间内。
4. 保存 最终的基准配置文件，用于后续版本比对。

软 PLC 的实时性能测试完成