在机器人、智能制造、工业控制以及边缘计算快速发展的今天，一个嵌入式计算平台正在承担越来越多的任务。

过去，一台控制器可能只需要完成一个简单的闭环控制：

采集传感器数据
        ↓
控制算法
        ↓
输出执行指令

而现在，一台机器人控制器或者智能设备往往同时需要完成：

实时运动控制
实时数据采集
工业通信
AI推理
视觉处理
路径规划
设备管理
网络通信
日志记录
人机交互

问题也随之出现：

这些任务能不能全部放在Linux上运行？

如果可以，Linux又如何保证AI推理、视觉处理、网络通信这些计算量很大的任务，不会影响最关键的实时控制任务？

例如一个机器人系统中：

AI视觉任务
↓
计算量大、负载波动明显

路径规划任务
↓
计算量中等、周期不完全固定

运动控制任务
↓
1ms周期、实时性要求高

安全监控任务
↓
需要快速响应

如果这些任务全部运行在同一个操作系统中，传统的“所有任务共享CPU资源”的方式就会面临一个非常现实的问题：

AI任务可能需要大量CPU资源，而控制任务却要求稳定、确定的执行时间。

这两个需求天然存在差异。

AI更关心吞吐量：

一秒钟能够处理多少数据？

实时控制更关心确定性：

最晚什么时候必须完成？

普通Linux应用可能更关心：

系统功能是否稳定、网络是否正常、文件是否可用？

而安全相关任务可能关心：

关键任务受到其他任务影响时，能不能保持正常运行？

这就是近年来实时Linux架构中越来越重要的一个概念：

混合关键性系统（Mixed-Criticality System）。

所谓混合关键性，并不是简单地把“高优先级任务”和“低优先级任务”放在一起，而是指：

同一计算平台上，同时运行具有不同实时等级、可靠性要求和资源约束的任务。

这也意味着，实时操作系统的发展正在从“让一个任务跑得更快”，逐渐走向：

让不同类型的任务在同一个系统中安全、可预测地共存。

对于望获OS这样的国产实时操作系统而言，这正是核心隔离、实时调度和系统资源管理能够真正体现价值的地方。

---

一、为什么AI和硬实时控制天然存在冲突？两个任务追求的“快”根本不是一回事

理解混合关键性系统之前，首先要弄清楚一个非常容易被忽略的问题：

AI计算和实时控制虽然都需要高性能，但它们对“性能”的定义完全不同。

例如一个视觉AI任务：

摄像头
  ↓
图像采集
  ↓
预处理
  ↓
AI推理
  ↓
目标检测
  ↓
结果输出

它可能需要持续处理大量数据。

假设：

一帧图像
→ 10ms处理完成

通常并不意味着系统失败。

即使某些帧：

10ms
12ms
15ms
9ms
13ms

对于很多AI应用来说，只要整体吞吐量和平均响应仍然满足需求，系统可能依然可以正常工作。

但实时控制完全不同。

假设机器人运动控制周期是：

1ms

那么：

第1次：1.0ms
第2次：1.1ms
第3次：1.0ms
第4次：3.0ms

即使前三次表现很好，只要某一次超过系统允许的最大延迟，就可能产生明显影响。

所以：

AI更强调平均性能和吞吐量。

硬实时控制更强调最坏情况响应和确定性。

可以简单做一个对比：

类型	主要关注点	对延迟的要求
AI推理	吞吐量、平均响应	可以存在一定波动
网络通信	吞吐量、平均延迟	通常允许一定抖动
日志任务	数据完整性	通常不是严格实时
普通控制	响应速度	有一定实时要求
硬实时控制	最坏情况延迟	必须严格控制
安全监控	响应上界	需要确定性

这意味着，如果把所有任务都放进一个完全共享的执行环境：

CPU
│
├── AI
├── 网络
├── 日志
├── 文件系统
├── 控制
└── 安全任务

那么最大的风险并不是CPU性能不够。

真正的问题是：

不同任务可能互相干扰。

例如AI任务突然出现计算峰值：

AI负载
    ↑
    │       ███████████
    │       ███████████
    │ █████████████████
────┴────────────────────

此时如果控制任务与AI任务共享同一个CPU核心，控制任务可能出现：

正常：
1ms
1ms
1ms
1ms

受到干扰：
1ms
1ms
2ms
1ms

如果只是偶尔出现，那么问题可能还不明显。

但如果系统越来越复杂，任务数量不断增加，影响实时性的因素就会越来越多：

AI计算
网络中断
磁盘I/O
文件系统
内核线程
日志
动态内存
锁竞争
设备驱动

最终系统的最坏情况延迟越来越难以分析。

因此，混合关键性系统真正要解决的问题并不是：

“如何让所有任务都跑得一样快？”

而是：

如何让不同重要程度的任务，在共享一个计算平台时互不产生不可接受的影响？

这就引出了整个问题的核心：

隔离。

---

二、为什么“分任务”还不够？真正需要隔离的是CPU、内存、中断和内核活动

很多人第一次面对这个问题时，会想到一个非常直接的方法：

“那就给实时任务设置一个更高的优先级。”

例如：

AI任务：Priority 30
普通任务：Priority 20
控制任务：Priority 90
安全任务：Priority 95

看起来问题解决了。

因为：

安全任务 > 控制任务 > AI任务 > 普通任务

但是上一篇关于优先级反转的文章已经说明：

仅仅设置优先级并不能保证实时性。

因为任务之间还存在：

锁
中断
内核线程
共享CPU
共享缓存
共享内存
I/O

等各种资源竞争。

例如：

CPU2
│
├── 控制任务
├── AI任务
├── 网络中断
├── kworker
├── RCU
├── timer
└── 其他系统活动

即使控制任务是：

SCHED_FIFO 90

也不能简单认为CPU2已经属于控制任务。

因为CPU核心上发生的事情远不只是“用户态任务”。

这就是为什么实时Linux需要进一步考虑CPU核心隔离。

一个更加典型的设计可以是：

CPU0、CPU1
──────────────
普通Linux
AI
网络
日志
文件系统
系统服务

CPU2、CPU3
──────────────
实时域
运动控制
实时采集
安全任务
实时通信

这样做的意义不是简单地“把任务绑到CPU2”。

而是尽量让CPU2、CPU3减少非实时系统活动。

这也是前面文章反复强调的：

CPU Affinity只是告诉任务“可以在哪里运行”，CPU Isolation则进一步关注“这个CPU上还有谁在运行”。

这两者是完全不同的概念。

进一步来看，仅仅隔离CPU仍然不够。

因为实时系统还需要关注中断。

例如：

实时控制任务
      ↑
      │
CPU2
      ↑
      │
网络中断

如果网络设备产生大量中断，而这些中断恰好进入实时核心，那么控制任务仍然可能受到影响。

因此，一个完整的实时隔离设计通常需要考虑：

任务隔离
+
CPU隔离
+
IRQ隔离
+
内核线程管理
+
Timer/RCU活动控制

这时候，“实时域”的概念就开始出现。

所谓实时域，可以简单理解为：

一个尽可能减少非实时干扰、专门承载关键实时任务的执行区域。

例如：

┌──────────────────────────────┐
│        Linux系统              │
│                              │
│  普通计算域       实时计算域   │
│  ─────────       ─────────   │
│  AI              控制任务     │
│  网络            安全任务     │
│  日志            实时采集     │
│  UI              实时通信     │
│                              │
└──────────────────────────────┘

这时候Linux就具备了同时承载两类不同任务的基础。

---

三、混合关键性系统的核心不是“两个系统”，而是让不同任务拥有不同的确定性等级

当我们说：

AI
+
Linux
+
RTOS

很多人的第一反应是：

“那是不是应该直接部署两个操作系统？”

这其实是过去很多实时系统常见的架构思路。

例如：

CPU A
运行Linux
↓
AI / 网络 / 文件系统

CPU B
运行RTOS
↓
硬实时控制

这种架构确实有它的价值。

Linux负责：

复杂应用
网络
文件系统
AI
图形
开发生态

RTOS负责：

硬实时
控制
采集
安全

两个系统分别承担自己的任务。

但是这种架构也会带来新的问题：

两个系统之间怎么通信？

例如AI识别结果需要交给控制系统：

Linux
AI识别
   ↓
通信机制
   ↓
RTOS
运动控制

通信过程中就会涉及：

共享内存
消息队列
中断
DMA
OpenAMP
RPMsg
IPC

一旦通信链路复杂起来，系统开发、调试和维护成本都会提高。

同时，两个系统还可能需要：

不同启动流程
不同驱动
不同开发环境
不同升级机制
不同故障处理方式

对于复杂机器人和智能制造设备而言，这会成为系统工程上的额外负担。

因此，另一个非常重要的技术方向开始受到关注：

能不能在一个Linux内核体系中，同时承载普通任务和硬实时任务？

这就涉及前面讨论的：

混合关键性 + 核心隔离 + 实时调度。

其基本思路不是：

Linux + RTOS

而是：

一个系统
│
├── 普通计算域
│
└── 实时计算域

两个域可以共享底层硬件资源，但通过调度、隔离和资源管理，让关键任务获得更稳定的执行环境。

这对于现代智能设备非常有吸引力。

例如一台人形机器人可能需要：

AI视觉
语音交互
大模型推理
路径规划
运动控制
关节控制
实时通信
安全监测

如果全部采用传统RTOS架构：

AI生态
↓
需要大量额外软件支持

如果全部采用普通Linux：

实时控制
↓
需要额外解决确定性问题

因此真正需要的并不是简单地选择：

Linux
OR
RTOS

而是：

如何让Linux具备同时承载不同实时等级任务的能力。

这也是实时Linux技术路线非常重要的一个发展方向。

---

四、从“优先级”到“隔离”：为什么核心隔离是混合关键性系统的关键技术

到了这里，再回头看前面几篇文章，就会发现一个非常明显的技术演进。

最开始我们讨论实时Linux：

如何让任务及时运行？

于是有：

PREEMPT_RT

然后我们讨论：

任务之间怎么竞争CPU？

于是有：

SCHED_FIFO
SCHED_RR
SCHED_DEADLINE

接下来讨论：

任务为什么还会被其他任务影响？

于是出现：

CPU Isolation
IRQ Isolation

再往下：

任务为什么会被低优先级任务卡住？

于是需要：

Priority Inheritance
实时锁

最终所有这些技术都指向同一个目标：

建立一个可预测的实时执行环境。

而混合关键性系统进一步提出：

不仅要保证一个实时任务，而要保证不同关键等级任务能够在同一个系统中共存。

例如：

关键等级A
硬实时控制
安全任务

关键等级B
实时通信
状态计算

关键等级C
AI推理
视觉处理

关键等级D
日志
UI
后台服务

不同任务的要求不同，就不应该采用完全相同的资源策略。

可以形成类似：

                    CPU资源
                       │
          ┌────────────┴────────────┐
          ▼                         ▼
      实时核心                    普通核心
          │                         │
     ┌────┴────┐              ┌─────┴─────┐
     ▼         ▼              ▼           ▼
  控制任务   安全任务        AI任务       网络

如果进一步做核心隔离：

CPU0 CPU1
普通计算
AI
网络
日志
   │
   │
   │
CPU2 CPU3
实时控制
安全任务
实时通信

那么AI负载突然增加时：

AI CPU占用率
████████████████████

主要影响的是普通计算域。

实时核心仍然拥有相对独立的CPU资源：

RT CPU
████

这就是核心隔离对于混合关键性系统的意义。

当然，这并不意味着隔离之后就可以完全忽略其他资源。

真正成熟的系统还需要继续关注：

内存
缓存
DMA
总线
I/O
IRQ
共享设备
共享锁

因为CPU隔离并不等于整个硬件平台完全隔离。

但从系统软件架构角度来看，CPU核心隔离提供了一个非常重要的基础：

把不同实时等级的任务放入不同的执行区域。

这比单纯依赖任务优先级更容易建立系统边界。

例如：

优先级方案：

AI       Priority 30
网络     Priority 40
控制     Priority 90

这种方式本质上还是：

所有任务共享CPU

而核心隔离方案则是：

AI/网络
→ CPU0/CPU1

控制
→ CPU2/CPU3

二者的思路完全不同。

前者主要解决：

谁先运行。

后者进一步解决：

谁使用哪一块CPU资源。

这也是为什么对于真正追求确定性的实时系统来说：

资源隔离往往比单纯提高任务优先级更加重要。

---

五、从混合关键性到望获OS：实时Linux真正的下一步是让不同任务“共存而不互相干扰”

如果把整个实时Linux技术路线重新梳理一次，会发现它其实经历了几个非常明显的阶段。

第一阶段：

解决Linux能不能抢占。

核心技术：

PREEMPT_RT

第二阶段：

解决实时任务怎么调度。

核心技术：

SCHED_FIFO
SCHED_RR
SCHED_DEADLINE

第三阶段：

解决实时任务如何减少CPU和中断干扰。

核心技术：

CPU Affinity
CPU Isolation
IRQ Affinity
IRQ Isolation

第四阶段：

解决实时任务之间如何进行可预测同步。

核心技术：

Mutex
Priority Inheritance
实时锁

而第五阶段，就是今天讨论的：

如何让不同实时等级的任务在同一个系统中共存。

这就是混合关键性系统。

从这个角度来看，未来的实时Linux并不是简单地追求：

更低平均延迟

而是更加关注：

更低最坏情况延迟
+
更清晰的资源边界
+
更强的任务隔离
+
更可预测的调度
+
不同关键等级任务共存

对于机器人、工业控制和智能制造来说，这种架构尤其重要。

例如一台智能机器人未来可能同时存在：

AI视觉
        ↓
目标识别

路径规划
        ↓
轨迹生成

运动控制
        ↓
关节控制

安全监测
        ↓
异常处理

从软件角度看，它们完全可以属于同一套系统。

但从实时性角度看，它们绝不能被完全同等对待。

真正合理的系统应该能够表达：

AI：
追求吞吐量

路径规划：
关注计算响应

运动控制：
严格周期性

安全监控：
强调快速响应

日志：
允许延迟

然后根据不同任务的特点，分别使用：

不同调度策略
+
不同CPU资源
+
不同优先级
+
不同隔离级别

这也是望获OS这类国产实时操作系统值得重点关注的技术方向。

对于面向工业控制、机器人、边缘计算等场景的实时系统而言，真正的竞争力并不只是“能不能运行Linux应用”，而是：

能不能让复杂Linux生态与实时控制需求在同一个系统架构中真正共存。

尤其是核心隔离，它的价值并不只是让一个任务“跑在某个CPU上”，而是进一步建立：

普通计算资源
        │
        │ 隔离
        ▼
实时计算资源

这样的系统边界。

当这个边界建立起来以后，SCHED_FIFO、SCHED_RR、SCHED_DEADLINE才有了更加明确的落脚点：

核心隔离
    ↓
确定CPU资源
    ↓
实时调度
    ↓
确定任务执行顺序
    ↓
PREEMPT_RT
    ↓
降低内核路径延迟
    ↓
IRQ隔离
    ↓
减少中断干扰
    ↓
实时锁
    ↓
降低阻塞时间

最终形成的不是某一个单独的技术功能，而是一套完整的：

确定性实时执行环境。

这也是理解现代国产实时Linux与传统RTOS之间关系的一个重要切入点。

未来的实时操作系统并不一定意味着“所有任务都必须运行在一个传统RTOS内核里”。

对于复杂智能设备来说，更现实的需求可能是：

在保留Linux完整软件生态的同时，为关键实时任务提供接近RTOS级别的确定性执行能力。

这也是为什么“Linux实时化”正在从最初的：

降低调度延迟

逐步发展到：

实时调度
+
核心隔离
+
资源隔离
+
混合关键性

真正的目标已经从“让Linux变快”，变成：

让Linux能够管理不同等级的计算任务，并且知道哪些任务可以共享资源，哪些任务必须被保护。

而这恰恰是机器人、工业控制和智能制造系统未来需要面对的核心问题。

当一个系统同时存在AI、视觉、网络、运动控制、安全监测等大量任务时，真正困难的已经不是“CPU够不够快”。

而是：

当所有任务都在抢资源的时候，谁必须得到保障？

对于普通任务，可以接受一定程度的波动。

对于AI任务，可以通过增加算力提高吞吐量。

但对于硬实时控制任务，单纯增加算力并不能解决所有问题。

它真正需要的是：

确定的CPU
确定的调度
确定的响应
确定的资源
确定的边界

因此，从PREEMPT_RT到实时调度，从CPU Isolation到Priority Inheritance，再到混合关键性系统，可以看到实时Linux正在逐渐形成一套完整的方法论：

不是让所有任务都实时，而是让真正需要实时的任务拥有实时能力；不是让所有任务互相独立，而是让关键任务拥有明确的资源边界；不是简单追求更快，而是控制最坏情况下系统到底会发生什么。

这也可能是未来国产实时操作系统非常重要的一条技术演进路径：

从“实时Linux”走向“确定性Linux”，再从“确定性Linux”走向能够承载多种计算范式的混合关键性操作系统。

而下一篇可以继续深入一个更加底层、也非常适合做技术搜索流量的主题：

《CPU隔离之后还会有实时延迟吗？从IRQ、Timer、RCU到内核线程全面理解实时Linux的干扰源》

这一篇可以把前面一直提到的“核心隔离”彻底拆开讲清楚：为什么CPU已经隔离了，实时任务仍然可能出现延迟，以及一个真正的实时核心到底需要清理哪些系统活动。