别这么做：忽略最坏情况下的执行时间

在实时嵌入式系统中，哪怕一次时限未满足，都可能损害安全性与可靠性。从汽车、航空电子到工业自动化、国防领域，开发人员必须证明：系统对最坏情况执行时间（WCET）有充分理解并能持续界定其范围，确保运行中任何任务都不会超出这个可靠上限。

估算 WCET 绝非易事，尤其在现代多核系统中。因此，即便是经验最丰富的开发团队，也常常低估 WCET，且往往实现得很差。关键任务的最坏情况执行时间会随其他运行任务、共享资源状态以及处理器负载行为的变化而波动。

随着系统日益复杂，以及人工智能与机器学习（AI/ML）负载带来更大的内存与数据流量压力，开发人员必须直面 WCET 问题。忽略它是不可接受的。即便平均执行时间看起来合理，低估 WCET 仍会危及安全性、可靠性与认证合规性（图 1）。

图 1：实测执行时间（橙色）只是所有可能执行时间（紫色）中的一部分。为确保能满足最坏情况执行时间（WCET），开发人员利用实测执行时间来估算 WCET。为实现安全可靠的运行，开发人员可设定一个时序上限，保证实际 WCET 一定在此范围内。

即使是平均满足时序要求的任务，在真实负载下仍可能出现超时。认证标准强制要求开发人员证明：

• 每个安全关键任务在所有运行条件下都满足时限。

• 即使存在干扰，WCET 仍在系统约束范围内。

• 即使其他核心并发执行，时序依然保持确定性。

实测执行时间只能捕捉到测试中观察到的部分情况。在真实多核硬件上，每次运行的干扰模式都会因缓存状态、内存流量与其他共享资源竞争而改变。测试中测到的最坏情况，极少是真正的 WCET，它仅仅是测试期间观察到的上限。而这个差距，正是可能引发灾难性故障的地方。

在实时关键任务系统中，WCET 不可忽视的其他原因包括：

• 隐藏的并发影响：即使任务不共享代码或数据，也可能通过共享缓存、内存总线或外设产生干扰，引发不可预测的延迟突增。

• 稀有事件脆弱性：时序违规常发生在不常见但关键的场景下，例如传感器数据突发、AI/ML 负载峰值、多重中断同时发生 —— 而这些时刻恰恰是可靠性最关键的时候。

• 安全与认证影响：ISO 26262、DO‑178C、IEC 61508 等标准要求提供时序保证的证据。忽略 WCET 可能危及认证或带来责任风险。

• 系统动态行为：内存竞争、缓存替换、任务重叠都会随时间变化。依赖平均执行时间可能掩盖最坏情况。

• 关键任务影响：在强实时系统（如飞控、汽车安全、医疗设备）中，哪怕一次超时都可能是灾难性的。

简单来说：WCET 是决定实时系统能否在所有条件下安全可靠运行的最重要因素。忽略它会带来仅靠测试平均值无法发现的失效风险。

为什么 WCET 分析如此困难？

多核时序耦合

即使任务不共享数据、不共享函数，且运行在不同核心上，仍会因共享的底层硬件（L2/L3 缓存、内存总线与互联、共享外设、RAM 访问模式）而相互干扰。这些隐藏的干扰通道会产生时序突增，仅靠代码审查无法预测。

并发执行具有非确定性

任务之间的执行重叠每次运行都不同。某个任务在一次测试中与另一任务重叠数毫秒，在下一次中可能几乎不重叠。这种可变性直接影响 WCET，使分析成为一个迭代、以测量为主导的过程。

数据大小改变缓存行为

当任务的工作集超出 L1 缓存容量时，就会依赖共享 L2 或 RAM 访问。多个任务同时超过这一阈值会导致缓存竞争激增，时序不可预测地拉长，在真实系统中有时增幅可达 40% 甚至更高。

人工合成干扰不真实

人为生成的干扰模式无法复现真实硬件竞争。WCET 必须在目标硬件、真实负载、实际缓存与内存配置下评估。

分三个互补阶段分析多核 WCET

根据行业指导文件与标准，开发人员可采用多种方法在复杂的多核处理器系统中测量执行时序。三种成熟方法可在整个开发周期提供有价值的时序数据：

1. 开发早期：哈尔斯特德度量与静态分析

哈尔斯特德复杂度度量可作为开发人员的早期预警系统。该方法可揭示特定代码段的复杂度与资源需求。通过静态分析，开发人员可将哈尔斯特德数据与目标系统的实时测量结果结合，帮助更高效地降低 WCET。

这类指标能反映代码的时序相关特性，包括模块大小、控制流结构、数据流。通过识别规模更大、复杂度更高、数据流更复杂的代码段，开发人员可优先优化对处理时间要求最高的代码。在开发生命周期早期优化这些资源密集型区域，可有效降低时序违规风险，并简化后续分析。

2. 开发中期：执行时间的实测动态分析

当模块无法满足时序要求时，开发人员可测量、分析、跟踪单个任务的执行时间，以识别并缓解时序问题（实测分析）。必须消除开发环境与生产环境在配置上的差异（如编译选项、链接选项、硬件特性）。因此，分析必须在应用实际运行的环境中进行。这意味着实测分析要等到测试系统搭建完成后才能全面开展。

为反映多次运行之间环境与应用的变化，必须重复执行足够多的测试以确保结果准确、可靠、一致（实测动态分析）。要在合理时间内完成足够测试，自动化必不可少。自动化还能减轻开发人员负担，并消除手动过程中可能出现的人为错误。

3. 开发后期：应用控制与数据耦合分析

评估竞争需要从控制与数据两个角度识别应用内的任务依赖关系。通过控制耦合与数据耦合分析，开发人员可研究任务间的执行与数据依赖如何相互影响。标准强制要求此类分析，不仅是为了确保所有耦合关系都被覆盖，也因为它们能揭示潜在问题。

端到端方案如何改善 WCET 分析

由于 WCET 同时取决于软件与硬件行为，开发人员需要具备以下能力的工具：

• 在目标硬件上插装代码、捕获时序、实时交换数据

• 揭示数据耦合、控制耦合与时序耦合

• 支持可复现、符合标准的验证

准确的 WCET 分析依赖于对代码在目标硬件上运行行为的理解。这些工具共同为开发人员提供完整的执行行为视图，实现更准确、更具说服力的 WCET 分析：

• 编译器通过控制机器码的确定性影响 WCET。可预测的优化与稳定的代码生成有助于保持执行时序一致。

• 调试器让开发人员实时观察负载下的系统执行。支持追踪的工具可揭示指令流、任务重叠、内存访问模式以及多核干扰导致的时序突增。

• 软件质量与验证工具通过代码插装收集详细的运行时测量数据，帮助开发人员识别数据、功能与时序耦合；验证执行路径；并将结果与系统需求关联。这为支持安全与认证目标提供可追踪的证据。

对于 WCET 而言，硬件分析同样至关重要。它包括：识别目标特定硬件配置中所有潜在的干扰通道；设计测试或配置系统，以触发应测量 WCET 的最坏情况条件。

缓解时序耦合，控制 WCET

时序耦合是指任务之间即使不共享代码或数据，也会相互影响执行时间。在多核系统中，隐藏依赖通过共享缓存、内存总线、外设等硬件资源产生。这些交互会造成意外延迟，拉高 WCET，导致关键任务超时（图 2）。

图 2：时序耦合干扰会显著影响最坏情况执行时间。

识别干扰源后，开发人员可采用以下缓解技术：

• 最小化数据集以适配 L1 缓存：减少缓存竞争，避免任务相互淘汰工作数据。

• 调整多核配置：设置核心亲和性、缓存模式、任务优先级，帮助关键任务隔离干扰。

• 使用 L2 缓存分区或 RTOS 级分区：为每个任务或核心保留资源，防止任务间竞争拉高 WCET。

• 在确定性优先于 raw 性能时关闭 L2：在某些系统中，可预测时序比吞吐量更重要。

• 在满负载下重新运行 WCET 分析：验证缓解措施在真实系统条件下有效。

其他管理时序耦合的方法包括：任务调度与优先级设置；限制共享外设的并发访问，以减少多核心同时访问同一设备时的不可预测阻塞时间；分析控制与数据依赖，识别任务间可能传播延迟的间接交互。

通过追踪与运行时插装，开发人员不仅能验证任务执行时间，还能分析时序变化的原因、定位干扰源，并确认缓解策略有效。这种可见性对于确保 WCET 上限可靠、关键任务在所有运行条件下都满足时限至关重要。

LDRA 近期与美国陆军联合开展的一项研究表明：潜在时序问题可能导致安全关键 / 时序关键应用中超过 40% 的性能问题。干扰带来如此大的时序增幅是不可接受的。

未来之路

现代指导文件（如 A (M) C 20‑193）强化了对航空电子开发人员的要求：必须提供证据，证明多核干扰可被理解、WCET 可被界定、且确定性行为可被保证，而不是仅仅假设。

在汽车与工业领域，功能安全（FuSa）标准虽没有 A (M) C 20‑193 那样详细的指导，但多核设备已被大量使用，不满足 WCET 要求同样可能引发安全危险。

随着实时系统纳入更大数据集（尤其用于 AI/ML 推理），内存访问模式、缓存压力与多核干扰只会变得更加显著。仅依赖平均执行时间或孤立任务测量的开发人员，将面临遗漏关键时序缺陷的风险。

借助具备确定性的编译器、支持追踪的调试器、运行时验证工具，再结合静态、动态与耦合分析，开发人员可获得系统级可见性，识别隐藏的时序耦合、在真实硬件上准确测量 WCET、验证确定性行为，并构建安全、可靠、可认证、满足实时时限的系统。

忽略 WCET 已不再可行。但借助合适的工具、测量方法与方案，开发人员最终能够掌控最坏情况执行时间，确保实时系统在所有条件下都保持安全、可靠与可认证。