实时 OS 巡礼：VxWorks、QNX、Zephyr 与 PREEMPT_RT

原文发布于 quant67.com，转载请保留出处。

汽车制动、飞机飞控、工业机器人协作------这些场景问的不是"平均延迟多少"，而是最坏情况延迟（WCET）是否有上界。通用 Linux 在默认配置下无法给出硬保证；VxWorks、QNX 等 RTOS 可以，但代价是生态、内存与认证成本。

本文回答：

硬实时、软实时、固定实时的定义与可调度性分析（RMA）各是什么？
VxWorks、QNX、Zephyr 的内核机制如何保证（或逼近）确定性？
Linux PREEMPT_RT 合入主线后，离"硬实时"还有多远？
何时必须商业 RTOS，何时 PREEMPT_RT 或 Zephyr 够用？

flowchart TD RT[实时需求] --> HARD[硬实时 截止错过=失效] RT --> FIRM[固定实时 错过无价值] RT --> SOFT[软实时 偶尔可降级] HARD --> VX[VxWorks 航空/国防] HARD --> QNX_R[QNX Neutrino 汽车/医疗] FIRM --> ARINC[ARINC-653 分区] SOFT --> ZEPHYR[Zephyr MCU/IoT] SOFT --> PREEMPT[Linux PREEMPT_RT 软实时+生态] classDef hard fill:#f8514922,stroke:#f85149,color:#adbac7; classDef firm fill:#a371f722,stroke:#a371f7,color:#adbac7; classDef soft fill:#f0883e22,stroke:#f0883e,color:#adbac7; class HARD,VX,QNX_R hard class FIRM,ARINC firm class SOFT,ZEPHYR,PREEMPT soft

一、硬实时、软实时与固定实时

1.1 定义

类型	定义	错过截止时间的后果	典型场景
硬实时（Hard Real-Time）	每个任务必须在截止前完成	系统失效或安全事故	ABS、飞控、反应堆保护
固定实时（Firm Real-Time）	偶尔错过无灾难，但结果作废	丢帧、丢采样	工业视觉、高频采样
软实时（Soft Real-Time）	统计上满足即可	卡顿、降级	视频会议、游戏

关键不在"快"，而在可证明的最坏情况。平均延迟 10 μs 而偶尔 50 ms 的 OS 不能用于硬实时。

1.2 与 Linux 默认内核的距离

标准 Linux（PREEMPT 或 PREEMPT_VOLUNTARY）存在：

长临界区持锁不可抢占
硬中断与 softirq 延迟
内存回收、块 I/O 路径上的不可预测停顿
无界内核线程活动

对照调度延迟分析：应用层看到的延迟尖刺，部分来自调度器，部分来自上述内核路径。PREEMPT_RT 缓解但未消除证明义务------认证场景仍倾向 VxWorks/QNX。

1.3 实时调度的形式化工具：RMA

Rate Monotonic Analysis（RMA） 为周期性硬实时任务提供充分条件。设 $nn$ n 个任务，周期 $Ti T_i$ Ti，执行时间 $Ci C_i$ Ci，利用率 $U=∑Ci/Ti U = \sum C_i/T_i$ U=∑Ci/Ti。

经典 Liu & Layland（1973）结果：若

$U≤n(21/n−1) U \leq n\left(2^{1/n} - 1\right)$ U≤n(21/n−1)

则 RMS（按周期越短优先级越高）可调度。 $n→∞n \to \infty$ n→∞ 时上界趋于 $ln⁡2≈0.69\ln 2 \approx 0.69$ ln2≈0.69。

$nn$ n	利用率上界
1	1.00
2	0.828
3	0.780
5	0.743
10	0.718
$∞\infty$ ∞	$ln⁡2≈0.693\ln 2 \approx 0.693$ ln2≈0.693

1.4 响应时间分析（简述）

对固定优先级任务 $ii$ i，最坏响应时间 $Ri R_i$ Ri 迭代求解：

$Ri=Ci+ ∑j∈hp(i) ⌈ RiTj ⌉ Cj R_i = C_i + \sum_{j \in hp(i)} \left\lceil \frac{R_i}{T_j} \right\rceil C_j$ Ri=Ci+∑j∈hp(i)⌈TjRi⌉Cj

其中 $hp(i)hp(i)$ hp(i) 为优先级高于 $ii$ i 的任务集。RTOS 价值在于使 $Ci C_i$ Ci（最坏执行时间）可静态界定；Linux 通用路径上 $Ci C_i$ Ci 常含不可忽略的内核变异项。

1.5 jitter 与时钟

实时系统关心 jitter（周期触发相对理想时间的偏移）。RTOS 通常提供：

高分辨率硬件定时器
tickless 或细粒度 tick（Zephyr CONFIG_SYS_CLOCK_TICKS_PER_SEC）
可选时钟同步（PTP/IEEE 1588 在工业以太网）

对照时钟源与定时器：Linux 具备高精度定时器，但全局事件（回收、其他 CPU 中断）仍引入 jitter。

工程含义：

硬实时设计先算利用率，再选优先级分配
RTOS 提供固定优先级抢占 与有界中断延迟，使 $Ci C_i$ Ci 可分析
Linux 上即使用 SCHED_FIFO，若内核不可抢占段过长， $Ci C_i$ Ci 上界仍不可信

认证项目通常用专业工具（Symtavision、RTaW 等）与 WCET 分析工具链完成证据链。

二、VxWorks：Wind Kernel 与确定性

2.1 产品定位

VxWorks（Wind River）是商业 RTOS，广泛用于航空电子、国防、工业控制、网络设备。Wind River 文档与产品数据表（A 级来源）强调：

确定性优先级抢占调度
可配置中断延迟上界（平台相关，微秒至数十微秒量级，以具体 BSP 数据表为准）
可选内存保护（MPU/MMU）
长期支持版本（LTS）与认证工件包

2.2 Wind Kernel 结构

VxWorks 7 采用可配置内核架构（VxWorks 7 Product Documentation）：

Wind Kernel：任务调度、同步、中断管理
任务：独立线程上下文，优先级 0--255（数值规则以文档为准）
ISR ：上半部极短，下半部 defer 到 task 上下文（与 Linux threaded IRQ 思想相近，对照线程化 IRQ）

flowchart LR ISR[硬件 ISR 极短] --> DEF[延迟到 高优先级任务] DEF --> TASK[应用任务 固定优先级] TASK --> SYNC[sem/mutex 优先级继承可选]

2.3 调度语义

抢占式固定优先级：高优先级就绪立即抢占低优先级
同优先级 FIFO 或时间片（配置决定）
优先级反转 ：VxWorks 提供互斥量优先级继承协议选项（与优先级反转讨论的问题域相同）

2.4 内存与分区

航空场景常用 VxWorks 653 或 ARINC-653 兼容分区配置：时间分区 + 空间分区，一个分区故障不拖垮飞控分区。这与 Linux namespace 隔离目标相似，但时间窗口隔离是 ARINC 强制要求，Linux 默认无。

2.5 POSIX 与生态

VxWorks 提供 POSIX 子集（pthreads、消息队列等），便于移植 Unix 风格代码，但不是完整 glibc Linux。驱动与中间件生态小于 Linux；优势在 BSP、认证与支持合同。

2.6 何时选 VxWorks

需要 DO-178C DAL A/B 级证据链
需要 Wind River 长期供应与责任边界
目标硬件已有成熟 VxWorks BSP

2.7 中断延迟与数据表

Wind River BSP 数据表常列出中断延迟 （interrupt latency）与调度延迟 （scheduling latency）典型上界。数值因 CPU 而异------引用时必须带 BSP 名与版本。工程上在选型阶段要求供应商提供目标板卡的实测报告，而非抄网上泛化 μs 数。

2.8 网络与存储子系统

VxWorks 提供端到端网络栈（IPv4/IPv6、DPDK 类加速选项视版本而定）与文件系统（dosFs、HRFS 等）。与 Linux 全栈相比，组件少但路径更可控------适合网络设备 OS，不适合需要最新容器生态的场景。

三、QNX Neutrino：微内核与消息传递

3.1 架构

QNX Neutrino （BlackBerry）是微内核 RTOS：内核只保留调度、IPC、中断路由、时钟；文件系统、网络栈、驱动多在用户态服务器实现。

对照宏内核 vs 微内核与 Minix：QNX 是微内核商业化的代表，IPC 性能是核心优化点。

flowchart TB subgraph user [用户态] DRV[驱动服务器] FS[文件系统服务器] NET[网络栈服务器] APP[应用] end subgraph kern [Neutrino 微内核] SCHED[调度] IPC[消息传递] INT[中断/向量] end APP --> IPC DRV --> IPC FS --> IPC NET --> IPC IPC --> SCHED

3.2 消息传递 IPC

QNX 的 MsgSend / MsgReceive / MsgReply 构成同步消息传递：

客户端发送请求并阻塞，直到服务器回复
内核拷贝消息（或结合共享内存优化路径）
适合明确的所有权转移与服务器崩溃隔离

与 Linux 管道/socket IPC 对比：Linux 宏内核内完成多数 IPC，延迟常更低，但故障隔离粒度不如微内核服务器。

3.3 汽车与 ISO 26262

QNX 在汽车仪表盘、ADAS、域控制器中广泛部署。ISO 26262 要求功能安全生命周期证据------QNX 提供安全手册、FMEDA 等工件（厂商文档，A/B 级）。本文不做法务解读；工程上理解：认证买的是"可审计过程 + 已知缺陷管理"，不是"零 bug"。

3.4 与 Minix 的对照

方面	QNX	Minix 3
定位	商业硬实时/汽车	教学/研究微内核
IPC	高度优化 msg	同步 send/rec
驱动位置	用户态服务器	用户态驱动
生态	汽车 BSP 成熟	学术为主

3.5 何时选 QNX

车载信息娱乐/仪表/ADAS 需要 ISO 26262 支持包
需要微内核故障隔离 + 商业支持
团队熟悉 Neutrino IPC 模型

3.6 进程模型与优先级

QNX 中进程包含多个线程；Neutrino 调度线程。微内核服务器常以独立进程实现，崩溃可由内核重启服务器而不拖垮整个地址空间------前提是 IPC 客户端处理服务器重启语义（重新连接、状态重建）。

3.7 启动时间与安全启动

车载 ECU 关注启动到首帧显示时间；QNX 提供快速启动路径与安全启动链（Secure Boot 协作）。对照启动流程：Linux 桌面启动链更长，裁剪 initramfs 可优化但不等于 RTOS 冷启动。

四、Zephyr：开源 MCU RTOS

4.1 定位

Zephyr （Linux Foundation）面向 MCU 到资源受限应用处理器：

内核可裁剪（Kconfig）
静态线程栈为主
支持 800+ 板卡（Zephyr Project Documentation）
LTS 版本两年维护

4.2 内核对象与配置

c 复制代码

#define STACK_SIZE 1024
K_THREAD_STACK_DEFINE(my_stack, STACK_SIZE);
static struct k_thread my_thread;

void main(void)
{
    k_thread_create(&my_thread, my_stack, STACK_SIZE,
                    my_entry, NULL, NULL, NULL,
                    K_PRIO_PREEMPT(5), 0, K_NO_WAIT);
}

特点：

编译期配置：未启用的子系统不进镜像
协作/抢占线程 ：K_PRIO_COOP vs K_PRIO_PREEMPT
设备树：硬件描述与 Linux 设备树概念相近

4.3 ARM Cortex-M 典型部署

Cortex-M 无 MMU（或可选 MPU）时，Zephyr 提供：

中断嵌套与 ISR 延迟由 NVIC 与内核配置决定
内存池 k_mem_slab、无堆或受限堆
适合传感器 hub、BLE 外设、工业网关前端

对照特权级与隔离：MCU 上"隔离"常是 MPU 区域 + 静态分区，而非 Linux 式 VM。

4.4 与 Linux 的边界

Zephyr 不是 Linux 的替代品跑云工作负载；它竞争的是 FreeRTOS、Mbed、裸机。需要 TCP/TLS 全栈、容器、eBPF 时选 Linux；只需确定性采样 + 无线协议栈时选 Zephyr。

4.5 安全与认证

Zephyr 推动 PSA Certified、TF-M 集成等；工业/医疗认证项目需评估具体 LTS 版本与供应商支持。开源本身不自动等于认证合格。

4.6 Kconfig 与镜像裁剪

Zephyr 通过 prj.conf 启用子系统：

conf 复制代码

CONFIG_GPIO=y
CONFIG_SPI=y
CONFIG_NETWORKING=y
CONFIG_NET_IPV4=y
CONFIG_MAIN_STACK_SIZE=2048

未选中的代码不链接进最终镜像------与 Linux CONFIG_* 类似，但 Zephyr 面向单应用固件 而非多用户服务器。对照 Linux kmod 生态：Linux 动态加载模块；Zephyr 多数部署静态链接。

4.7 同步原语

Zephyr 提供 k_sem、k_mutex（可选优先级继承）、k_msgq、k_mbox。阻塞原语与 Linux futex 不同：在 MCU 上常直接调度切换，无复杂地址空间。

五、Linux PREEMPT_RT：软实时主线化

5.1 补丁做了什么

PREEMPT_RT 核心改动（Linux RT Wiki + 主线 6.12 合入）：

机制	标准 Linux	PREEMPT_RT
`spinlock_t`	关抢占持锁	多数变为可睡眠 `rt_mutex`
softirq	硬中断上下文	`ksoftirqd` 线程化
硬中断 handler	全程硬 IRQ	线程化 IRQ（除极短路径）
优先级继承	PI futex 等	扩展到 rt_mutex 链

目标：把不可抢占的内核路径压到可分析长度，使 SCHED_FIFO 任务 WCET 可测。

5.2 主线合入时间线

多年 -rt 补丁树维护（Steven Rostedt 等）
Linux 6.12 （2024）：CONFIG_PREEMPT_RT 作为正式选项合入主线（LWN / kernel.org release notes，A 级）

启用：

bash 复制代码

# 内核配置
CONFIG_PREEMPT_RT=y
CONFIG_HIGH_RES_TIMERS=y

验证常用 cyclictest（rt-tests 包）测量调度延迟分布------需在目标硬件上跑并记录环境。

5.3 仍非硬实时之处

即使 PREEMPT_RT：

关闭中断的第三方模块仍可能破坏保证
巨大 page fault、存储抖动、NUMA 远端访问引入变异
无 ARINC 式时间分区
CVE 与攻击面仍大于裁剪 RTOS

硬实时认证通常不接受"通用 Linux + RT 补丁"作为飞控唯一 OS，除非额外隔离层（hypervisor 分区 + 认证 guest）------那是系统架构而非内核单点问题。

5.4 部署实践

隔离 CPU（isolcpus、nohz_full，对照 NO_HZ）
mlockall 锁定应用内存
避免 swap（交换是实时大敌）
SCHED_FIFO 优先级规划 + RT-throttling 防饿死普通任务

5.5 PI mutex 与优先级继承

PREEMPT_RT 将内核中大量 spinlock 替换为 rt_mutex ，支持优先级继承（Priority Inheritance） ，缓解优先级反转------与优先级反转中讨论的 PI futex 同族。

场景：高优先级 FIFO 任务等待低优先级任务持有的内核锁时，持有者优先级临时提升，避免中优先级任务插队。

5.6 cyclictest 读数注意

cyclictest 输出 min/avg/max 延迟，单位常为数微秒到数十微秒（视 CPU、C-states、固件而定）。本文不写入具体 μs 数字作为普适结论 ------必须在目标板卡、关闭节能、固定频率下实测。公开教程常用作相对对比（开/关 PREEMPT_RT），而非跨硬件绝对值。

5.7 与 SCHED_DEADLINE 的关系

SCHED_DEADLINE 提供 EDF + CBS，适合周期性任务带宽保证；与 FIFO 正交。工业系统可能混用：DEADLINE 管周期传感器，FIFO 管短临界控制环。

六、ARINC-653 与分区调度

航空电子 ARINC-653 定义：

空间分区：各分区独立地址空间
时间分区：调度表轮转，每分区固定时间窗口
健康监控：分区超时/故障 → 分区重启或降级

css 复制代码

窗口 1 → 分区 A（飞控）  10ms
窗口 2 → 分区 B（导航）  20ms
窗口 3 → 分区 C（通信）  5ms

一个分区死循环只消耗自己的窗口，不阻塞飞控分区------前提是 hypervisor/RTOS 正确实现调度表。VxWorks 653、LynxOS-178、PikeOS 等提供此类能力。

6.1 与健康监控

ARINC-653 健康监控（HM） 定义分区/任务超时、死锁、栈溢出时的恢复动作（分区重启、模块复位、告警）。这比 Linux watchdog 更形式化------动作表在系统集成时预先认证。

6.2 与 hypervisor 组合

现代航空电子常在 Type-1 hypervisor （PikeOS、VxWorks 653 on Xen 等）上跑多个 ARINC 分区。对照 KVM：通用虚拟化提供空间隔离；时间分区表仍需 RTOS/hypervisor 扩展，不是 KVM 默认能力。

七、安全认证：DO-178C 与 ISO 26262

7.1 认证在买什么

标准	领域	对 OS 的典型要求（概念）
DO-178C	航空软件	需求追溯、WCET、覆盖率、变更管理
ISO 26262	汽车功能安全	ASIL 等级 → FMEDA、安全手册、已知缺陷
IEC 62304	医疗软件	软件生命周期、风险分析
IEC 61508	通用功能安全	SIL 等级

认证不保证无 bug；保证过程可审计、残余风险在标准接受范围内。RTOS 厂商售卖"认证工件包"降低集成成本。

7.2 与 Linux 的关系

主线 Linux 无 DO-178C DAL A 级"开箱认证"。工业用户可能：

用 RTOS 跑安全相关分区
用 Linux 跑非安全相关 HMI/连接
用 hypervisor 隔离两侧

7.3 边界声明

本文描述工程语境，不构成合规建议。立项应咨询认证机构与厂商安全手册。

7.4 DO-178C 设计保证等级（DAL）

DAL	失效后果	典型软件要求（概念）
A	灾难性	最严格覆盖率、形式化方法可能
B	危害大	高覆盖率、独立验证
C	中等	结构化覆盖
D	较小	简化流程
E	无安全影响	最轻

飞控 OS 常在 DAL A/B 语境评估。RTOS 厂商文档会声明其内核组件在特定配置下支持的 DAL------配置错误（如启用未认证驱动）会使工件失效。

7.5 ISO 26262 ASIL 简述

汽车 ASIL（A 至 D）由危害分析与风险评估得出。OS 本身不"具有 ASIL"，而是作为 SEooC（Safety Element out of Context）提供安全手册，由集成商论证在目标 ECU 上的使用。QNX/VxWorks 汽车产品线文档描述此类角色。

八、FreeRTOS 与其它选手（简表）

RTOS	许可	典型场景
FreeRTOS	MIT	MCU、AWS IoT 引用设计
SAFERTOS	商业	IEC 61508 SIL 衍生
ThreadX / Azure RTOS	微软生态	嵌入式中间件
RT-Thread	Apache	国内工业/IoT
NuttX	Apache	POSIX-ish MCU

Zephyr 与 FreeRTOS 在 IoT 正面竞争；硬实时航空仍倾向 VxWorks/PikeOS。

8.1 FreeRTOS 要点

FreeRTOS（Amazon 维护）极简内核：任务、队列、信号量、软件定时器。内存占用可至 KB 级（以配置为准）。AWS IoT 参考设计广泛引用。与 Zephyr 相比：FreeRTOS 更"库"式嵌入；Zephyr 更完整平台（驱动、网络、构建系统）。

8.2 RT-Thread 与 NuttX（简）

RT-Thread ：中国工业界常用，组件化（FinSH shell、DFS 文件系统）。NuttX：POSIX 风格 API，NASA 部分任务采用。选型常由供应链与本土支持决定，而非纯技术优劣。

九、选型决策树

flowchart TD START[需要实时?] -->|否| LINUX[通用 Linux] START -->|是| DEAD[错过截止后果?] DEAD -->|灾难| CERT[需要认证?] DEAD -->|降级可接受| SOFT[软实时路径] CERT -->|DO-178C/26262| COMM[VxWorks/QNX/认证 RTOS] CERT -->|自证+工具| HYBRID[RTOS分区+Linux服务] SOFT --> MCU{MCU 级?} MCU -->|是| ZEPHYR[Zephyr/FreeRTOS] MCU -->|否需Linux生态| RT[PREEMPT_RT Linux]

9.1 决策要点

先定失效模式：人命/设备损毁 → 硬实时 + 认证证据链
再定硬件：有无成熟 BSP 比内核哲学更重要
再定生态：要 Node.js 容器还是 32KB RAM
最后测 WCET：cyclictest、示波器、逻辑分析仪上板

9.2 常见误区

误区	纠正
"Linux + RT 补丁 = 硬实时"	仅软实时逼近，认证飞控不够
"RTOS 一定比 Linux 快"	RTOS 保证的是上界，不是更高吞吐
"开源 Zephyr 免费所以无成本"	集成、认证、BSP 仍昂贵
"平均延迟低就够了"	看 99.999% 或最大延迟

9.3 工业案例类型（不编造具体数字）

行业	常见 OS 选择	决定因素
民航飞控	VxWorks 653 / PikeOS	DO-178C DAL
汽车座舱	QNX / Android Automotive	ISO 26262 + UI 生态
电机伺服	VxWorks / RT-Linux / bare metal	循环周期 μs 级
网关传感器	Zephyr / FreeRTOS	RAM/功耗
机器视觉 PC	PREEMPT_RT Linux	GPU/算法生态

表中为架构模式归纳，非市场份额预测。

9.4 PREEMPT_RT 与容器

在 Kubernetes worker 上跑软实时工作负载时，CPU manager static policy、cgroups cpuset 与 RT 任务隔离可组合------但混部会引入噪声。生产实践常专用裸机或隔离核跑 FIFO 任务，普通 Pod 跑在非隔离核。

9.5 机器人与协作机械臂

协作机器人常混合架构：

安全 PLC / 专用控制器：硬实时急停、力矩限幅（认证固件）
Linux 工业 PC：运动规划、视觉、HMI（PREEMPT_RT 或标准内核）
MCU：关节编码器采样（Zephyr/FreeRTOS）

安全相关路径不经过 Linux------与汽车"安全岛"模式相同。评估 RTOS 时画清安全边界框图，比比较内核线程模型更重要。

9.6 能源与医疗边缘案例类型

核电站 I&C、医疗输液泵等场景常见 VxWorks 或专用 RTOS + 形式化验证子集。共同点是：变更控制比功能列表更重要------长期维护合同与源码 escrow 常写入采购条款。

十、与 Linux 系列的交叉索引

Linux 话题	篇章
SCHED_FIFO / PREEMPT_RT	22-realtime-sched
优先级反转	71-priority-inversion
中断与 threaded IRQ	73-interrupts、75-threaded-irq
调度理论	19-scheduling-theory
延迟分析	26-sched-latency
微内核架构	03-kernel-architectures

10.1 测量工具链

工具	用途
cyclictest	Linux 调度延迟直方图
hwlatdetect	硬件导致的 latency 尖刺
ftrace function_graph	内核路径耗时
Zephyr timing reports	内核基准（官方 CI）

对照 perf 子系统：通用性能分析与实时验收测量目标不同------后者强调最大值 与可重复性。

十一、EDF 与固定优先级补充

11.1 EDF 最优性

动态优先级 Earliest Deadline First（EDF） 在单核上利用率不超过 100% 时对周期性任务集合最优。Linux SCHED_DEADLINE 实现 EDF + Constant Bandwidth Server（CBS）防止任务组合饿死。

RTOS 侧常用固定优先级（RMS）因为：

行为更易静态分析
与 ARINC 分区表兼容
厂商工具链成熟

11.2 多核实时

多核硬实时需额外约束：共享缓存、总线、锁竞争使单核 WCET 分析不够。VxWorks/QNX 提供多核亲和与资源分区；Linux PREEMPT_RT 多核可用但全局可调度性证明更难------工业界对安全核仍倾向分区或单核飞控。

flowchart LR CORE0[Core 0 飞控 FIFO] --- LOCK[共享资源?] CORE1[Core 1 通信栈] --- LOCK LOCK -->|尽量避免| OK[独立外设/内存] LOCK -->|必须共享| WCET[WCET 联合分析]

11.3 缓存与 WCET 工具

WCET 分析工具（aiT、RapiTime 等）需要建模流水线、缓存、分支预测。多核共享 L2/L3 使单核 WCET 之和不等于多核 WCET------RTOS 厂商文档与学术论文均强调联合验证。简单在 Linux 上跑 stress 不能替代认证级 WCET 报告。

11.4 从 NFV 看实时需求迁移

路由器、基站 PHY 层曾广泛用 VxWorks/QNX。云原生 NFV 转向 Linux + DPDK 后，软实时与吞吐优先于硬截止------说明产品代际改变实时定义，旧选型不能机械套用。

11.5 sporadic 任务与突发负载

除了周期任务，还有 sporadic 任务（最小到达间隔 $Ti T_i$ Ti，执行 $Ci C_i$ Ci）。可调度性分析更复杂。网络设备 IRQ 风暴、CAN 总线突发帧都属于此类------RTOS 用有限深度队列 + 背压；Linux 用 NAPI、coalescing 等削峰。硬实时设计要对 sporadic 源设最坏到达率假设。

11.6 看门狗与 deadman switch

RTOS 与 Linux 都提供 watchdog 定时器；安全标准常要求独立硬件 watchdog 不经过主 CPU 软件链。飞控板上常见双通道：软件喂狗 + 独立监视 MCU。对照定时器子系统：Linux watchdog 驱动丰富，但认证布局要把 watchdog 纳入失效分析树（FTA）。

11.7 内存保护单元（MPU）与 MMU

Cortex-M 常用 MPU 划分区域；MMU 系统用页表隔离。Zephyr 与 VxWorks 均支持 MPU 配置；错误访问触发 fault 可预测。Linux MMU + 用户态边界隔离更强，但 fault 处理路径更长------硬实时任务常 pin 在已知物理页并锁定 TLB 工作集（mlock、大页）以减少变异。

十二、小结

确定性来自固定优先级、有界中断延迟、可分析 WCET------不是"内核体积小"
VxWorks/QNX 卖确定性 + 认证工件；Zephyr 卖 MCU 可裁剪开源；PREEMPT_RT 卖 Linux 生态下的软实时
RMA 给出利用率充分条件；工程还需测量与认证工具
选型先问失效模式，再问认证与硬件，最后才问内核商标

12.1 给 Linux 背景读者的三条建议

在提议"用 Linux 替代 RTOS"之前，先写清错过截止的失效模式与是否需认证工件。
若选 PREEMPT_RT，预算中应包含隔离核、实测 cyclictest、禁止 swap 的运维约束，而非仅改 CONFIG_PREEMPT_RT。
MCU 与服务器是不同赛道：不要在 Zephyr 上找容器，也不要在飞控分区跑未裁剪的 Ubuntu。

12.2 术语表

术语	含义
WCET	Worst-Case Execution Time，最坏执行时间
BCET	Best-Case Execution Time
RMS	Rate Monotonic Scheduling，周期越短优先级越高
EDF	Earliest Deadline First
BSP	Board Support Package，板级支持包
SEooC	Safety Element out of Context，脱离上下文安全元件
PI	Priority Inheritance，优先级继承

12.3 与 Windows / 嵌入式 Linux 的边界

Windows 内核桌面路径不提供硬实时保证；Windows IoT/Embedded 产品线亦不等同 VxWorks。嵌入式 Linux（Yocto、Buildroot）裁剪后可用于软实时网关，但认证飞控仍走 RTOS 或分区 hypervisor------三类方案不要混称为"实时 Linux"。

12.4 延伸阅读矩阵

你想搞懂...	建议接着读
Linux FIFO 与 RT 补丁	22-realtime-sched
延迟是不是调度器的锅	26-sched-latency
中断路径	73-interrupts
微内核争论	03-kernel-architectures
容器混部风险	100-containers-security

RTOS 与通用 OS 的边界不是"谁更先进"，而是谁为你的失效模式背书。把背书关系写进架构评审材料，比在内核邮件列表争论 PREEMPT_RT 是否够硬更有用。

12.5 采购与供应商问题清单

向 RTOS 供应商索要材料时，可检查：

目标 BSP 的中断延迟与调度延迟实测报告（含 CPU 型号与编译选项）
认证工件版本与内核配置哈希是否匹配
安全公告 SLA 与 CVE 处理流程（商业 RTOS 亦有安全更新）
长期支持（LTS）结束日期与迁移路径
多核配置下共享驱动是否经过 WCET 分析

缺少第 2 项时，DO-178C/ISO 26262 集成会在适航/适车审查中卡住------技术选型与商务条款同等重要。

12.6 与 Unikernel / 库 OS 的对比预告

Unikernel 在云上追求极小攻击面与快启动，与 RTOS 在"裁剪"上形似，但没有硬实时保证与认证文化。不要把 MirageOS 镜像当成飞控候选；实时与专用化是不同维度。

最后记住：PREEMPT_RT 合入主线降低软实时门槛，但不改变硬实时认证默认答案。Linux 6.12+ 值得在网关、机器人非安全核、音视频管线评估；飞控 DAL A 仍查供应商工件表。

附录、PREEMPT_RT 与工业认证边界补充

DO-178C / ISO 26262 对 OS 的要求是 过程与证据 ------「用了 PREEMPT_RT」不等于「通过认证」。认证包通常绑定 具体 RTOS 产品 + 版本 + BSP 。Linux PREEMPT_RT 常见于 工业 PC、测试台、非生命安全辅助；飞控/制动仍倾向 VxWorks/QNX。

问题	硬 RTOS	PREEMPT_RT
WCET 证据	厂商 Datasheet + 实测	难给出全局上界
认证历史	航空/汽车案例多	新兴，项目制
生态	专用工具链	完整 GNU/Linux

选型时把 认证预算 与 上市时间 写入决策表------见正文 §七决策树。

附录 1、工程深化：PREEMPT_RT 认证边界

维度	要点	本站交叉引用
机制	PREEMPT_RT 认证边界在 RTOS 语境下的默认假设	见正文与系列 index
运维/开发	变更前建立可核对基线；避免无证据调参	perf
边界	不编造 benchmark；外部数据标 B 级	写作规范

flowchart LR Q[PREEMPT_RT 认证边界] --> E[证据台账] E --> I[工程决策] I --> R[回滚策略]

读者若维护生产系统，应把 PREEMPT_RT 认证边界纳入架构评审清单------与容器隔离、虚拟化等篇形成闭环，而非孤立采纳单一技术。

附录 2、工程深化：DO-178C 证据包

维度	要点	本站交叉引用
机制	DO-178C 证据包在 RTOS 语境下的默认假设	见正文与系列 index
运维/开发	变更前建立可核对基线；避免无证据调参	perf
边界	不编造 benchmark；外部数据标 B 级	写作规范

flowchart LR Q[DO-178C 证据包] --> E[证据台账] E --> I[工程决策] I --> R[回滚策略]

读者若维护生产系统，应把 DO-178C 证据包纳入架构评审清单------与容器隔离、虚拟化等篇形成闭环，而非孤立采纳单一技术。

参考文献

官方文档（A 级）

Wind River, VxWorks Product Documentation and Programmer's Guide
BlackBerry QNX, QNX Neutrino System Architecture and System Security Guide
Zephyr Project, Zephyr Kernel Documentation, docs.zephyrproject.org
Linux Kernel, PREEMPT_RT wiki, wiki.linuxfoundation.org/realtime
Linux 6.12 release notes, kernel.org

论文与书籍

Liu, C. L., Layland, J. W. "Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment." Journal of the ACM, 1973
ARINC Specification 653, Avionics Application Software Standard Interface

工具

cyclictest（rt-tests）
Zephyr west build system

上一篇 ：Windows 内核与 Linux 的关键差异

下一篇 ：Unikernel