3. 实时性能测量与基准测试方法

实时性能优化不能靠感觉，必须靠测量。TwinCAT 提供了从内核态到用户态、从单任务到整机负载的多层观测手段。本节围绕四个核心工具——TwinCAT Scope、ETW、Performance Monitor 以及任务执行时间测量——说明如何获取可信的实时数据，并给出抖动统计与基准测试用例的设计方法。

一、四类测量工具的分工

不同工具观测的层次不同，混用会导致数据无法对齐。TwinCAT Scope 工作在 TwinCAT 实时层，通过 ADS 采样变量，适合观察 PLC 变量、轴位置、控制量的时间曲线，采样周期可低至 50 µs，但它是“应用层视角”，反映的是变量值随时间的变化，而非任务调度本身。ETW（Event Tracing for Windows）工作在 Windows 内核与驱动层，TwinCAT 的实时驱动会向 ETW 写入调度、中断、上下文切换事件，适合分析实时任务被 Windows 抢占、CPU 隔离失效等系统级问题。Performance Monitor 提供的是 Windows 计数器视角，如 CPU 占用率、DPC 延迟、中断时间，用于判断整机是否处于可承载实时负载的状态。任务执行时间测量则直接落在 PLC 任务内部，通过读取系统时间戳计算单次执行耗时，是判断任务是否超时的最直接依据。

一个实用的原则是：先用 Performance Monitor 确认整机健康，再用 ETW 定位系统级抖动，最后用 Scope 和任务内测量确认应用层表现。顺序颠倒容易在错误层次上反复排查。

二、任务执行时间与抖动的测量实现

在 PLC 中测量任务执行时间，最直接的方法是在任务开头和结尾读取系统时间戳。TwinCAT 提供 F_GetSystemTime 或通过 SystemTimeGet 获取 100 ns 精度的时间值。示例代码如下：

VAR
    tStart  : T_DWORD;
    tEnd    : T_DWORD;
    tExec   : T_DWORD;  // 单位 100 ns
    tMax    : T_DWORD := 0;
    tMin    : T_DWORD := 16#FFFFFFFF;
    nCycles : UDINT := 0;
    tSum    : ULINT := 0;
END_VAR

// 任务开头
tStart := F_GetSystemTime();

// ... 实际控制逻辑 ...

// 任务结尾
tEnd := F_GetSystemTime();
tExec := tEnd - tStart;

IF tExec > tMax THEN tMax := tExec; END_IF
IF tExec < tMin THEN tMin := tExec; END_IF
tSum := tSum + tExec;
nCycles := nCycles + 1;

这里 tExec 的单位是 100 ns，若任务周期为 1 ms，则周期对应 10000 个计数。抖动定义为实际执行时间与平均执行时间的偏差，常用指标包括最大值、最小值、平均值和标准差。假设某 1 ms 任务在 10000 个周期内测得平均执行时间为 320 µs，最大值为 480 µs，最小值为 290 µs，则抖动峰峰值为 190 µs，占周期的 19%。这个比例偏高，说明任务中存在不确定分支或内存分配，需要进一步用 ETW 确认是否被 Windows 线程抢占。

三、抖动统计与判读

抖动统计不能只看平均值。平均值掩盖了偶发的长尾延迟，而实时系统恰恰最怕长尾。建议同时记录以下统计量：

• 最大值：决定最坏情况是否超时，是硬实时判断的核心。
• 99.9 分位值：反映极端情况下的表现，比最大值更稳定。
• 标准差：反映整体波动程度，用于判断系统是否稳定。
• 超时次数：执行时间超过周期一定比例（如 80%）的次数，直接对应风险。

判读时先看最大值是否超过周期。若最大值接近或超过周期，说明任务已经存在超时风险，必须优化。若最大值正常但 99.9 分位值明显偏高，说明存在偶发干扰，应结合 ETW 查看是否有 Windows 线程或驱动在特定时刻抢占 CPU。若标准差很小但平均值偏高，说明任务本身计算量过大，需要拆分任务或优化算法。

四、基准测试用例设计

基准测试的目的是在可控条件下复现问题、对比优化效果。设计用例时应固定以下变量：任务周期、优先级、CPU 亲和性、IO 刷新周期、被测代码路径。建议至少设计三组用例：空载基线、典型负载、峰值负载。空载基线用于确认系统本身没有异常抖动；典型负载模拟实际运行工况；峰值负载用于测试最坏情况下的余量。

以下是一个可直接参考的基准测试记录表，用于记录每次测试的关键参数和结果：

表中数据为教学示例，用于说明记录格式和判读方式，并非实测结果。从 PEAK-01 可以看出，最大执行时间 920 µs 已接近 1 ms 周期，且出现 3 次超时，说明当前配置在峰值负载下余量不足。优化方向包括：将通信任务拆分到独立任务、降低非关键任务的优先级、或把周期从 1 ms 放宽到 2 ms。优化后应重新运行同一组用例，对比最大执行时间和超时次数的变化，才能确认优化是否有效。

五、工具协同的实践要点

实际调试中，建议先用 Performance Monitor 观察整机 CPU 占用率和 DPC 延迟，确认 Windows 侧没有明显异常；再用 ETW 抓取一段 10～30 秒的跟踪，重点查看实时任务是否被非实时线程抢占；然后用 TwinCAT Scope 观察关键变量的时间曲线，确认控制逻辑本身是否产生周期性波动；最后在任务内埋入时间戳，统计执行时间和抖动。四类数据相互印证，才能定位到真正的瓶颈。单独依赖任何一个工具，都容易得出片面结论。