控制任务与普通业务如何分核？设计一套可验证的实时运行架构

在工业控制、机器人和 EtherCAT 多轴运动控制系统中，一个常见的工程问题是：控制算法、总线通信、状态监测、日志记录、网络服务和数据存储都运行在同一台 Linux 设备上，为什么系统空闲时运行正常，一旦开启数据采集、调试日志或者上位机通信，控制周期就开始出现抖动？

很多工程师遇到这类问题后，会尝试提高实时线程优先级、绑定 CPU，或者直接启用 CPU 核心隔离。这些方法有时确实有效，但如果任务之间的依赖关系、数据交换方式和中断分布没有设计好，即使把控制线程绑定到独立 CPU，也不能保证整个控制链路按时完成。

原因在于，实时系统的性能并不是由某一个线程或某一项内核参数单独决定的。真正需要设计的是一条完整的执行链路：数据何时到达、控制任务何时被唤醒、何时获得 CPU、何时完成计算、何时更新输出，以及设备何时真正执行指令。

本文以工业控制和机器人运动控制为例，介绍如何从任务建模出发，将实时控制任务与普通业务任务合理分层，通过 CPU 与 IRQ 规划、任务间通信、异常处理和持续测试，构建一套能够分析、能够复现、能够验收的实时运行架构。

一、先确定系统的实时边界：哪些任务必须按时完成？

在进行 CPU 分配之前，首先要回答一个问题：系统中究竟哪些任务具有明确的时间约束？

以一台运行 Linux 的 EtherCAT 运动控制设备为例，它可能同时承担以下工作：周期性读取从站输入数据、执行运动控制算法、更新目标位置和速度、与上位机交换状态、采集运行日志、保存诊断数据，以及运行 Web 管理服务。

这些任务都很重要，但它们的时间要求并不相同。

运动控制任务可能要求每隔固定时间执行一次，并在下一个控制周期到来前完成；通信状态监测可能允许数毫秒的延迟；日志写入磁盘则通常不需要在某个精确的微秒级时间点完成。如果把所有任务都当作实时任务，不仅会增加调度设计的复杂度，还可能让真正重要的控制线程面临更多资源竞争。

因此，系统架构设计的第一步，是按照时间约束和业务职责对任务进行分层。

需要注意，这张表只是常见的划分方式，并不是所有系统都必须采用完全相同的分层。例如，某些安全监测任务具有严格的响应时间要求，应当根据其安全需求和故障处理时限进行单独设计，不能简单地归为普通业务任务。

1. 从控制周期推导时间预算

假设某台工业控制设备采用 1 ms 的控制周期，那么每个周期对应 1000 μs 的时间间隔。但这并不意味着控制算法可以不受限制地执行 1000 μs。

在这段时间内，系统可能还需要完成输入数据获取、控制计算、输出数据更新以及必要的同步操作。任务还必须考虑调度延迟、执行时间变化、资源竞争和设备接口时序。

工程设计时，可以先将周期划分为若干时间预算。例如，下面是一组用于说明设计方法的假设值，并非实测数据或通用推荐值：

这里最重要的不是各环节具体分配多少微秒，而是建立明确的时间预算，并通过测量验证实际运行是否符合预算。

假设控制算法平均只需要 150 μs，但在高负载时偶尔需要 350 μs，那么仅看平均执行时间就可能低估风险。对于实时系统，还需要关注执行时间的变化范围、任务开始是否迟到、关键路径是否出现阻塞，以及截止时间违约是否发生。

同时，1 ms 的控制周期并不自动意味着端到端响应必须在 1 ms 内完成。输入采样、主站交换、控制计算和执行器响应之间的具体时序，需要根据系统的同步方式与控制设计明确规定。

2. 用任务依赖关系定义实时边界

控制任务与普通业务任务之间，最容易被忽视的不是 CPU 使用率，而是任务依赖关系。

例如，控制线程为了获取上位机下发的参数，直接等待网络线程完成处理；或者控制线程为了写日志，等待日志线程释放一个共享锁。即使网络线程和日志线程运行在其他 CPU 上，控制线程仍然可能被它们间接拖慢。

因此，设计实时架构时，需要逐一检查以下问题：

• 控制任务是否等待普通业务线程？

• 实时线程是否需要访问由非实时线程维护的共享数据？

• 是否存在跨线程锁、同步 I/O 或动态资源申请？

• 通信数据是否可能积压，导致控制任务处理过期数据？

• 异常处理是否会让控制线程进入不确定时长的等待？

如果关键控制路径依赖于一个没有明确时间约束的普通任务，那么这种依赖本身就需要重新设计。合理的分核不是简单地把线程分开，而是尽可能减少实时路径对非实时工作的同步依赖。

二、如何规划 CPU、线程与中断：从职责划分到执行隔离

完成任务分层后，才进入 CPU 规划阶段。多核处理器提供了并行执行的条件，但并不意味着只要拥有足够多的 CPU 核心，系统就自然具有良好的实时性。

实际规划时，需要同时考虑线程运行位置、IRQ 分布、后台内核活动、线程之间的通信，以及 CPU 之间共享缓存和内存带宽等因素。

1. 建立一张明确的 CPU 职责表

假设设备使用一颗具有 8 个逻辑 CPU 的处理器，编号为 CPU0 至 CPU7。以下是一种用于说明架构思路的示例，具体分配必须结合处理器拓扑、硬件中断、内核配置和实际负载验证。

这个示例不是唯一正确的分配方式。尤其是 EtherCAT 主站任务与控制算法是否应该分核，需要结合主站调用模型和数据交换机制判断。

如果主站周期任务和控制算法需要频繁交换少量数据，分配到不同核心可能引入额外同步开销。如果它们需要严格串行执行，将其放在同一个核心上有时反而更容易分析时序。相反，如果两者存在足够的并行空间，且跨核通信开销可控，分核可能带来收益。

真正的判断标准不是“每个任务都有自己的 CPU”，而是整个执行链路能否在目标截止时间内稳定完成。

2. 区分 CPU 亲和性与核心隔离

CPU 亲和性用于限制线程可以在哪些 CPU 上运行；核心隔离则涉及减少指定 CPU 上的普通任务和部分系统活动。两者有关联，但不是同一个概念。

可以先检查系统拓扑和线程当前的运行情况：

lscpu ps -eLo pid,tid,psr,cls,rtprio,pri,ni,stat,comm taskset -pc <TID>

其中，TID应替换为目标线程的实际线程 ID。ps输出中的psr反映采样时线程所在的处理器，不能单独证明线程只允许在该 CPU 上运行。

在 Linux 中，可以通过线程亲和性 API 或taskset调整允许运行的 CPU。对于需要更严格控制的系统，还可以评估isolcpus、nohz_full和rcu_nocbs等内核启动参数。

但这些参数并不等价于“彻底关闭指定 CPU 上的一切系统活动”。其具体效果与内核版本、配置和其他系统设置有关，仍然需要检查中断、内核线程、定时器、RCU 活动及其他共享资源干扰。

另外，不要为了追求隔离而把所有 IRQ 都机械地迁移到某一颗 CPU。集中处理过多中断可能导致该核心过载，而实时核心也可能因为设备中断分配不合理而受到干扰。应根据中断来源、处理时限以及设备驱动行为进行规划。

3. CPU 规划必须与 IRQ 规划一起进行

在工业控制设备上，网络接口、EtherCAT 主站所依赖的网卡、串口、存储设备以及其他外设都可能产生中断。中断处理的位置和方式，可能影响实时任务获得 CPU 的时间。

可以通过以下命令观察中断计数：

cat /proc/interrupts

分别在空载和业务负载下采集数据，比较各 CPU 上中断计数的变化。对于目标 IRQ，还可以检查其亲和性配置：

cat /proc/irq/<IRQ号>/smp_affinity_list

如果平台支持对应接口，也可以在经过验证后调整 IRQ 允许运行的 CPU 范围。但需要注意：

• 不是所有中断都能通过同一种接口自由迁移。

• 驱动、内核版本以及中断控制器可能限制实际配置行为。

• 启用irqbalance等自动均衡机制时，应确认其策略是否符合实时 CPU 规划。

• 在 PREEMPT_RT 环境中，部分中断处理可能线程化，不能只关注硬中断上下文，还要观察相关中断线程的调度行为。

如果实时线程出现偶发延迟，应将线程调度轨迹与 IRQ 事件放在同一时间线上分析，而不是看到某个中断计数增长就直接判定其为根因。

4. 不要忽视共享硬件资源

即使控制线程独占一个逻辑 CPU，它仍然可能受到其他核心的间接影响。

例如，普通业务线程持续访问内存、多个核心竞争末级缓存、内存带宽被大量数据采集占用，或者处理器受到热状态与频率管理影响，都可能改变实时任务的实际执行时间。

因此，CPU 隔离的目标应当是降低可控干扰，而不是承诺绝对没有干扰。最终是否达到设计目标，需要在真实硬件上通过测量确认。

三、线程之间如何交换数据：既要及时，也要避免互相等待

CPU 分配只是架构的一部分。实时系统中另一个关键问题是：控制线程和普通业务线程之间究竟如何交换数据？

如果采用不合理的共享方式，即使线程运行在完全不同的 CPU 上，也可能因为锁竞争、队列积压或数据同步问题而出现延迟。

1. 尽量避免控制线程同步等待普通业务

假设上位机每隔一段时间发送一次运动参数，控制线程需要读取这些参数。如果控制线程每次执行时都通过网络请求获取参数，那么网络抖动就可能直接影响控制周期。

更合理的做法通常是将网络接收和控制执行分离：

1. 网络线程接收、校验并解析参数。

2. 网络线程将完整的有效参数发布到共享数据区。

3. 控制线程在自己的周期内读取已发布的数据。

4. 控制线程不等待网络接收、参数解析或磁盘操作完成。

这种设计能够让网络处理的延迟更多地留在业务侧，而不是直接进入控制周期。

不过，参数发布仍需要定义明确的一致性语义。若参数由多个字段组成，不能让控制线程读到一半是新值、一半是旧值。可以根据数据大小、更新频率和平台条件，选择互斥锁、双缓冲、原子操作或经过正确实现的无锁队列。

双缓冲也不是只靠两个数组就能自动保证正确性：发布顺序、内存可见性、缓冲区所有权以及生产者和消费者的并发关系都必须设计清楚。

2. 根据数据类型选择通信机制

这里需要特别注意队列的容量和溢出策略。一个没有容量上限、允许无限积压的队列，可能在短时间内看起来工作正常，但当消费者处理速度低于生产者时，延迟会持续增加，最终演变为内存压力和系统不稳定。

因此，队列不仅要规定容量，还要规定满队列时的行为。

对于只需要最新状态的数据，可以考虑覆盖旧快照；对于不能丢失的故障事件，则应采用满足业务要求的可靠记录或告警机制。不能对所有数据统一采用“队列满了就丢弃”的策略。

3. 明确数据新鲜度，而不只是数据是否存在

在运动控制中，数据是否成功传递并不是唯一指标。数据是否足够新鲜，同样重要。

假设控制线程在第 100 个周期收到一条数据，但这条数据实际上是在第 90 个周期生成的。那么，即使通信过程没有报错，控制算法也可能使用过期状态做出决策。

因此，关键数据最好具备可追踪的时间信息，例如生成时间、序列号或对应周期编号。系统应当根据业务需求识别过期数据，并明确规定处理策略。

对于机器人控制，可以根据数据类型选择丢弃过期指令、使用最新有效状态、进入受控降级模式或触发故障处理。对于具有严格安全要求的控制系统，则必须按照安全需求和故障策略进行设计，不能用通用的“继续运行”逻辑替代。

同时，跨线程时间戳比较必须建立在明确的时钟基础上。如果数据来自不同设备或不同时间域，还需要考虑时钟同步误差，不能直接把不同来源的时间戳相减并将结果当作准确延迟。

4. 锁、日志和动态内存应尽可能退出关键路径

实时控制线程中，以下操作都值得重点检查：

• 同步写文件、刷新日志或等待磁盘 I/O。

• 等待网络响应、设备响应或普通业务线程完成工作。

• 获取可能被低优先级线程长期持有的锁。

• 在周期循环中执行不可预测的动态内存分配。

• 因队列已满而等待消费者释放空间。

这些操作并非在所有情况下都绝对禁止，但如果执行时间没有明确上界，或者可能发生无界等待，就会增加截止时间违约的风险。

对于关键路径，可以优先考虑启动阶段预分配资源、固定容量缓冲区、有限执行时间的数据处理，以及可控的锁与同步机制。是否使用mlockall()等内存锁定机制，也应结合权限、资源限制和实际内存需求评估，而不是直接把它当作解决所有内存延迟的开关。

四、异常、过载和降级：实时架构必须考虑失败时怎么运行

一套成熟的实时系统不能只设计正常工作时的执行路径，还要明确当通信异常、队列积压、业务过载或者设备状态异常时，系统应当如何反应。

如果所有异常处理都依赖普通业务线程，或者错误日志一旦产生就要求控制线程同步写盘，那么故障发生时，系统可能恰恰在最需要稳定控制的时候出现更严重的延迟。

1. 为每个关键环节定义超时和失效行为

以机器人 EtherCAT 控制系统为例，可以从以下几个方面建立故障处理规则：

其中，控制任务超时后的行为尤其需要谨慎。简单地在下一个周期继续执行，并不一定适合所有系统；盲目连续补跑错过的周期，也可能导致控制任务追赶过度、占用后续周期的时间预算。

正确做法应由控制算法、设备特性和安全需求共同决定。例如，系统可能需要跳过已经失去意义的周期、采用最近一次有效状态、限制执行路径，或者按照规定的安全策略停止输出。具体策略必须经过系统级验证。

2. 为过载制定明确的优先级

当 CPU、内存带宽或数据队列达到压力边界时，系统需要有明确的取舍顺序。

通常可以将任务分为三类：

第一类是必须优先保障的控制和故障处理任务。这些任务需要清晰的时间约束与资源预算。

第二类是影响系统运行质量，但允许适度延迟的监测和状态更新任务。对于这类任务，可以根据业务需求适当降低采样频率或减少非必要工作。

第三类是可延后执行的日志整理、历史数据存储、非关键统计和界面刷新等工作。当系统过载时，可以优先限制这些工作的资源消耗。

但不能把“控制任务永远最高优先级”简单理解为所有控制相关线程都应使用最高实时优先级。如果故障处理线程、通信线程与控制线程之间存在依赖关系，仍然需要分析优先级、锁竞争和截止时间，否则可能因为调度策略不当产生新的阻塞。

3. 降级行为也必须可观测

系统进入降级状态后，应当留下足够的信息帮助工程师判断发生了什么。

例如，可以记录：

• 控制任务迟到次数和截止时间违约次数。

• 通信数据过期次数和过程数据错误计数。

• 队列溢出、数据丢弃和限流事件。

• 关键任务执行时间的变化。

• 设备状态转换和降级状态持续时间。

这些信息可以通过预分配缓冲区记录，再交由后台线程异步处理。关键路径中应避免因为记录异常而引入额外的无界等待。

对于涉及人身安全或设备安全的应用，降级行为必须服从系统的安全设计，不能仅凭性能测试决定。实时性良好也不等于系统具备功能安全能力。

五、如何验证这套架构：从静态设计走向可复现测试

CPU 分配表、线程优先级和架构图只是设计产物，并不能证明系统已经满足实时要求。只有在目标硬件、实际驱动、真实业务负载和明确测量口径下完成验证，才能判断设计是否有效。

建议按照以下步骤建立工程化验证流程。

1. 第一步：明确需求与验收指标

首先列出每个关键任务的周期、截止时间、执行时间预算、数据依赖和异常行为。

同时，明确测量对象究竟是线程唤醒延迟、控制算法执行时间、EtherCAT 周期任务完成时间，还是从输入采样到输出更新的端到端延迟。

这些指标不能混为一谈。cyclictest可以帮助建立周期定时唤醒延迟的基线，但不能代替完整控制链路的测量。

2. 第二步：记录系统基线

在尚未进行核心隔离或复杂优化前，先记录系统的原始表现，包括：

• 内核版本、配置、启动参数和实时补丁状态。

• CPU 型号、逻辑 CPU 拓扑及频率管理设置。

• 关键线程的调度策略、优先级与 CPU 亲和性。

• IRQ 分布、后台业务负载和设备驱动情况。

• 任务开始、完成时间戳及实际周期。

• 平均延迟、P95、P99、P99.9、最大观测延迟和截止时间违约次数。

这里的百分位统计必须明确样本数量、统计时间段和计算方式。最大观测延迟只是已观测样本中的最大值，不能直接视为理论最坏执行时间。

3. 第三步：逐项改变架构参数

建议采用一次改变一个主要因素的对照方式，例如：

1. 在原始配置下测量。

2. 调整关键线程的 CPU 亲和性。

3. 优化 IRQ 分布。

4. 减少控制路径中的锁竞争和同步 I/O。

5. 调整实时与普通任务的 CPU 分配。

6. 在确认平台支持且理解副作用后，评估核心隔离相关配置。

每一步都保留配置、测试结果和变更记录。如果一次同时修改十几个参数，即使性能改善，也很难判断真正有效的因素是什么。

测试过程中还应注意观察者效应：高频日志、过量 trace 事件和过于密集的监测程序本身可能增加系统负担。应在详细追踪与长时间低开销测试之间合理切换。

4. 第四步：验证真实业务负载与长时间运行

系统不能只在空载时通过测试。还应模拟上位机高频通信、日志持续写入、数据采集、磁盘负载、网络流量和多个设备同时运行等场景。

对于 EtherCAT 或机器人控制，还需要验证通信状态、过程数据新鲜度、同步配置、控制任务周期以及设备实际响应之间的关系。

如果某个异常只在运行数小时后出现，就应进行长时间压力测试，并观察内存、队列、线程数、CPU 状态和延迟分布是否随时间发生变化。

最终的验收标准应在测试前定义，而不是看到某次结果较好后再临时决定合格线。

5. 第五步：把系统配置与测试证据绑定

一份可复现的实时系统测试记录，至少应包含以下信息：

• 硬件型号与关键外设配置。

• 内核版本、内核配置和启动参数。

• 驱动、主站及应用程序版本。

• CPU 与 IRQ 分配方案。

• 实时线程的调度策略和优先级。

• 测试时长、样本数量和业务负载。

• 指标定义、测量起止点和统计方法。

• 异常次数、测试日志和关键追踪记录。

这样才能在升级内核、替换驱动、增加业务功能或更换硬件之后，进行有依据的回归测试。

无论使用通用 Linux、启用了 PREEMPT_RT 的内核，还是采用望获OS等实时操作系统方案，都应遵循相同的验证原则：在相同硬件、相同驱动、相同负载和相同测量口径下进行比较。核心隔离和实时调度机制可以帮助降低干扰，但是否满足具体控制系统的截止时间要求，最终仍然取决于整条执行链路的设计和实测结果。

总结

控制任务与普通业务任务如何分核，并不是一个单纯的 CPU 参数配置问题，而是一个系统架构问题。

有效的实时运行架构，需要先明确每个任务的周期、截止时间和依赖关系，再决定线程如何分层、CPU 如何分配、IRQ 如何规划，以及不同线程之间如何交换数据。同时，还必须为队列积压、通信异常、任务超时和资源过载设计明确的处理策略。

最值得记住的是三点：

第一，CPU 隔离可以减少部分干扰，但不能自动消除锁竞争、共享硬件资源和端到端链路中的所有延迟。

第二，实时线程与普通业务线程应尽可能通过有界、可预测的数据交换机制协作，避免关键控制路径依赖网络、日志和存储等不确定时长的操作。

第三，架构是否有效，不能仅凭 CPU 使用率或一次短时测试判断。必须结合真实业务负载、长期运行、延迟分布和截止时间违约情况进行验证。