【操作系统百科】实时 OS 巡礼

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

本文回答：

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

flowchart TD
    RT[实时需求] --> HARD[硬实时<br/>截止错过=失效]
    RT --> FIRM[固定实时<br/>错过无价值]
    RT --> SOFT[软实时<br/>偶尔可降级]

    HARD --> VX[VxWorks<br/>航空/国防]
    HARD --> QNX_R[QNX Neutrino<br/>汽车/医疗]
    FIRM --> ARINC[ARINC-653 分区]
    SOFT --> ZEPHYR[Zephyr<br/>MCU/IoT]
    SOFT --> PREEMPT[Linux PREEMPT_RT<br/>软实时+生态]

    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 定义

关键不在”快”，而在可证明的最坏情况。平均延迟 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） 为周期性硬实时任务提供充分条件。设 \(n\) 个任务，周期 \(T_i\)，执行时间 \(C_i\)，利用率 \(U = \sum C_i/T_i\)。

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

\[U \leq n\left(2^{1/n} - 1\right)\]

则 RMS（按周期越短优先级越高）可调度。\(n \to \infty\) 时上界趋于 \(\ln 2 \approx 0.69\)。

1.4 响应时间分析（简述）

对固定优先级任务 \(i\)，最坏响应时间 \(R_i\) 迭代求解：

\[R_i = C_i + \sum_{j \in hp(i)} \left\lceil \frac{R_i}{T_j} \right\rceil C_j\]

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

1.5 jitter 与时钟

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

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

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

工程含义：

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

认证项目通常用专业工具（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<br/>极短] --> DEF[延迟到<br/>高优先级任务]
    DEF --> TASK[应用任务<br/>固定优先级]
    TASK --> SYNC[sem/mutex<br/>优先级继承可选]

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 的对照

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 内核对象与配置

#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 启用子系统：

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 合入）：

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

5.2 主线合入时间线

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

启用：

# 内核配置
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 定义：

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

窗口 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 认证在买什么

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

7.2 与 Linux 的关系

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

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

7.3 边界声明

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

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

飞控 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 与其它选手（简表）

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 决策要点

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

9.2 常见误区

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

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

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 系列的交叉索引

10.1 测量工具链

对照 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<br/>飞控 FIFO] --- LOCK[共享资源?]
    CORE1[Core 1<br/>通信栈] --- 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 任务（最小到达间隔 \(T_i\)，执行 \(C_i\)）。可调度性分析更复杂。网络设备 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 背景读者的三条建议

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

12.2 术语表

12.3 与 Windows / 嵌入式 Linux 的边界

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

12.4 延伸阅读矩阵

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

12.5 采购与供应商问题清单

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

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

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

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

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

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

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

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