RTOS 技术调研：实时机制、与 Linux/Android 的边界、RISC-V 64 生态与车规（AUTOSAR）落位

版本历史

术语与缩略语

可靠性标记

【C】 表示规范原文、官方文档或一手资料可直接核查的事实，不代表本报告已实测；【C*】 表示稳定的通用工程原理；【S】 表示厂商或组织的单方声明，未交叉验证；【P】 表示分析、估算、建议或条件性情景；【?】 表示本次证据不足。正文中的“判断”“建议”同样限定结论性质。

判读口径：“支持某架构”只表示代码与文档存在该目标的构建路径，不表示质量与性能达到何种水平；厂商页面上的认证等级默认为单方声明，正式等级以认证机构签发的证书与范围说明为准。“功能存在、功能可用、功能通过目标环境验收”是三个不同判断。

1. 核心判断（TL;DR）

• 【C】RTOS 与 Linux/Android 的分界不是“快慢”，而是确定性的来源不同。RTOS 的承诺是有界的最坏情况响应：固定优先级抢占、静态内存、可裁剪内核共同把中断延迟与调度延迟压缩到可分析的量级；Linux 的首要目标是吞吐与通用隔离（EEVDF 调度器接替 CFS，实时性依赖实时调度类与 PREEMPT_RT 的持续收敛）；Android 是在 Linux 之上叠加交互体验栈（ART 运行时、lmkd 内存回收、Binder IPC）的系统，其官方文档不以硬实时为目标。[S01][S02][S20][S21][S23][S25][S26]
• 【C】RISC-V 64 位（RV64）对 RTOS 的支撑已经“可用且可组合”，关键增量集中在三处硬件机制。M/S/U 特权级 + PMP 提供无 MMU 也能成立的保护域；Sstc 扩展以 stimecmp 直写消除定时器对机器态固件（SBI）的往返开销；AIA（IMSIC/APLIC）把平台中断推进到消息化并支持虚拟化投递，H 扩展（RVA23 起强制）开启单芯片多系统分区。[S29][S30][S31][S32][S33][S34][S36][S37]
• 【C】RTOS 与 AUTOSAR 不是同一层级的事物：AUTOSAR 定义软件架构与接口，内核实现由 RTOS/宿主 OS 提供。CP 的操作系统派生自 OSEK/VDX 并保持静态配置与可伸缩等级（SC1–SC4），由 RTA-OS 一类商业实现或车规 RTOS 承担；AP 以 POSIX PSE51 为接口面、强调进程与 IPC 模型，宿主 OS 由集成商选择（规范文本未点名具体宿主，Linux/QNX/PikeOS 属产品生态事实）。[S59][S60][S61][S62][S50][S54][S56]
• 【S】车规量产的现实组合是“双域 + 虚拟化”而非二选一：安全实时域用 RTOS + AUTOSAR CP 承接硬实时与 ASIL 目标，高性能计算域用 Linux/QNX + AUTOSAR AP 承接服务化与吞吐，而单芯片混合关键性由 Type-1 Hypervisor（QNX Hypervisor、PikeOS、INTEGRITY Multivisor、Jailhouse）分区承载。认证清单（QNX OS for Safety 8.0 的 ASIL D/SIL3、SAFERTOS 的 SIL3、VxWorks Cert 的 DAL A 路径、PikeOS 的预认证清单）均为厂商公开声明，需按项目取证复核。[S50][S51][S52][S53][S54][S55][S57]
• 【?】待观察项集中在“证据”而非“功能”：RV64 上开源 RTOS 的公开最坏情况延迟基准仍然稀少；seL4 的 hypervisor 扩展支持尚未并入主线；国内 RV64 实时芯片与车规 RTOS 的认证证据链处在建设期（Nuclei 与 Quintauris 的 RT-Europa 合作、芯来 SDK 对多款 RTOS 的集成属于公开进展，但公开材料未给出量产级延迟数据）。[S19][S45][S48][S49][S63]

2. 问题、范围与方法

2.1 调研问题与边界

本次调研围绕四个问题展开：其一，RTOS 的知识体系与核心机制是什么，它的“确定性”由什么机制支撑、在什么条件下失效；其二，RTOS 与 Linux、Android 的区别如何用工程语言说清楚，三者各自适配什么任务形态；其三，RISC-V 64 位平台（ISA 特性与实际芯片）对 RTOS 的支撑现状如何，哪些特性已经进入主流内核与板卡；其四，RTOS 与 AUTOSAR 及车规软件是什么关系，量产项目如何组合这些部件。

边界方面：本报告只使用公开材料，不采集个人邮件、聊天、OKR 或企业内部数据；不执行第三方仓库代码、不安装生产依赖；不进行目标板实测，因此所有“性能”“确定性”结论都属于机制与公开资料层面的判定，不构成实测数据。功能安全认证部分只引用厂商公开声明并标注其为单方声明，不构成认证评估。

2.2 证据分级与判读口径

证据分四级：一级为规范与官方文档（RISC-V 特权架构手册、AUTOSAR 规范、RTOS 项目官方文档）；二级为官方代码仓库与发行说明（FreeRTOS、RT-Thread、Nuclei SDK 等）；三级为厂商产品页与新闻（认证等级、产品定位，按单方声明处理）；四级为第三方报道与社区资料（仅用于定位线索，不用于承载结论）。所有 URL 在 2026-09-29 研究过程中访问核验；个别站点存在区域性网络波动，链接可达性可能随时间变化。

本报告对“实时”的判读采用可检出口径：主张实时能力，必须落到“最坏情况延迟与抖动是否有界、由谁保证、如何验证”三个问题上；仅描述调度机制（如“支持优先级抢占”）不构成实时性证据，这是后文所有对比与建议的基线。

3. 全球技术基线

3.1 RTOS 的定位与确定性来源

RTOS 的行业定义可以从实时系统的定义反推：硬实时指错过截止期即视为功能失效，软实时指偶尔超时只带来体验退化。[S20] 这决定了 RTOS 的设计目标是可预测的最坏情况响应，而不是平均吞吐。围绕这一目标，主流 RTOS 收敛出四组机制：

调度机制。Zephyr 采用固定的优先级抢占调度：数值越小优先级越高，所有就绪线程按优先级排序，高优先级线程就绪即抢占；同优先级可抢占线程之间可启用时间片轮转，时间片长度与适用优先级由 Kconfig 配置；协作式线程（不被抢占地运行到让出）是其调度语义的一部分。[S01]

内存机制。RTOS 的资源通常在配置期确定：栈、内核对象、驱动缓冲区以静态分配为默认形态；需要动态内存时使用固定块内存池（memory slab）或堆（heap），Zephyr 明确建议优先使用固定块池、限制堆的使用，以规避碎片与不确定的分配时延。[S02]

中断与定时。中断是实时延迟的主战场：常规 ISR 由内核管理、可访问受限的内核服务；Zephyr 另行提供“零延迟中断”（zero-latency IRQ），这类中断不经过内核的中断管理路径、可获得最低抖动，但代价是不得调用内核服务。[S03] 定时方面，tickless idle 在空闲时关闭周期节拍、按下一个到期事件编程定时器，既减少空转唤醒，也是低功耗场景的常规配置。[S05]

隔离机制。RTOS 的经典模型是单地址空间内的多任务并行：所有代码共享物理地址空间，任务隔离依赖硬件权限单元而非地址翻译。Zephyr 的用户态通过 MPU/PMP 划定的内存域给线程授予分区级权限，内核对象通过系统调用代为操作；RISC-V 平台上这一机制对应 PMP。[S04][S31]

由此可以给出本报告对“确定性”的操作定义：有界的调度延迟 + 有界的中断延迟 + 有界的阻塞时间，三者共同决定端到端的可分析性。任何一项无界，实时宣称都不成立；这也解释了为什么后文对 Linux 的讨论会落到“不可抢占路径、缺页与回收行为”，而不停留在调度器层面。

3.2 主流开源 RTOS 与实时内核对照

表中信息来自各项目官方文档与代码仓库。[S01][S04][S06][S08][S09][S10][S11][S12][S13][S14][S15][S16][S17][S18][S19] 需要强调两点：其一，开源许可证与安全认证无关，车规项目引用开源 RTOS 时，认证证据必须另行构建；其二，“支持 RV64”在不同项目中的成熟度不同，判断标准应回到板卡级构建与回归测试是否存在。上述项目均由活跃社区维护，版本迭代频繁，本报告只描述研究截点时的公开状态。

3.3 Linux 的实时性边界与实时化路径

Linux 是宏内核的多用户操作系统，其设计目标与 RTOS 相反：用虚拟内存、公平调度与丰富生态换取通用性。内核文档显示，通用调度器在 6.6 起采用 EEVDF 算法接替 CFS，同时体系内并存实时调度类（SCHED_FIFO、SCHED_RR、SCHED_DEADLINE），允许把指定线程置于更高优先级或按截止期调度。[S21][S22]

但“有实时调度类”不等于“端到端有界”：Linux 的不可确定性来自内核自身的不可抢占路径（锁、中断关闭区间）、内存子系统的按需分页与交换（缺页会引入毫秒级抖动）、以及 overcommit 策略下内存压力引发的回收与 OOM 行为——内核文档明确给出 overcommit 的三种策略模式及其风险，即内存超售在压力下可能触发不可预测的失败路径。[S24] PREEMPT_RT 补丁集正是为收敛这些路径而存在：把自旋锁转为可睡眠锁、将中断处理线程化、减少不可抢占区间。2024-09 的 LWN 报道确认其收尾补丁进入 6.12 合并窗口，实时抢占配置从此随主线内核发布，不再依赖独立补丁集维护。[S23]

因此对 Linux 的正确问法不是“是否实时”，而是：端到端的最坏情况延迟要求是多少、由内核的哪个配置保证、用什么工具测出。当要求是数十微秒级抖动与可数学分析的响应时，标准 Linux（含其常规实时调度类）不构成证据；PREEMPT_RT 收敛后仍需在目标硬件上以基准工具验证，且对驱动质量、内存预留、中断亲和性提出额外工程要求。【P】

3.4 Android 的位置：交互体验优先的运行时栈

Android 的官方架构文档把系统描述为自下而上的分层：Linux 内核之上是硬件抽象层（HAL），再上是原生库与 Android 运行时（ART），之上是系统框架与应用。[S25] 三个组件决定了它与实时性的距离：

其一，ART 运行时以 dex2oat 提前编译（AOT）与并发复制式垃圾回收为核心机制，垃圾回收的停顿虽经并发化设计压缩，其触发时机仍由堆状态驱动而不由任务截止期驱动。[S26] 其二，lmkd 守护进程依据内存压力信号（vmpressure/PSI）与分组阈值回收后台进程，回收行为属于系统级内存治理，应用无法给出确定性的内存保留承诺。[S27] 其三，Binder 作为框架层 IPC 的中枢，贯穿几乎所有系统服务调用，其优先级继承机制改善但不消除端到端延迟的分布性。[S25]

车载形态方面，Android Automotive OS 官方定位为“为车载体验供能的 Android 平台基座”，即把移动端应用生态与交互框架搬入座舱域。[S28] 需要特别说明：本次调研未能在官方文档中找到“Android 不是实时操作系统”的原文表述，因此本报告把“Android 不提供硬实时保证”作为研究判断（【P】）而非官方结论：依据是其运行时与内存治理机制均不以最坏情况延迟为目标，且相关文档未给出任何最坏情况延迟指标。在整车的安全与实时分工中，Android/AAOS 的现实位置是座舱与信息娱乐域（通常按 QM 级处理），硬实时与安全关键功能由 RTOS/AUTOSAR 域承担，两者的边界由第 3.8 节的架构图展开。

3.5 三者对照：确定性来源与工程后果

把三个系统放回同一张对照表，差异会收敛为“确定性从哪里来”这一行：RTOS 把不确定性在配置期消灭（静态内存、静态优先级、可裁剪内核）；Linux 把不确定性收敛为可调参数与补丁配置（实时调度类、PREEMPT_RT、内存策略）；Android 接受不确定性并围绕它做体验优化（GC、lmkd、Binder 调度）。见图 1。

图 1：RTOS、Linux 与 Android 的软件栈对照（RTOS 列：应用与实时任务—可裁剪内核—中间件—BSP—MCU；Linux 列：应用—运行时—宏内核（EEVDF、虚拟内存、可选 PREEMPT_RT）—驱动—应用处理器；Android 列：应用—系统框架—ART—Native/HAL—Linux 内核与补丁—移动 SoC）。来源为 Zephyr、Linux 内核、Android 官方文档与 LWN 公开材料归纳；为架构示意，不表示具体产品的模块划分或性能数值。[S01][S04][S05][S21][S23][S25][S26][S27]

上表来源为各系统官方文档与规范归纳。[S01][S02][S04][S20][S21][S23][S24][S25][S26][S27] 工程后果可以概括成三句话：要求“可证明的响应上限”时选 RTOS，因为其机制允许做最坏情况分析；要求“丰富的服务生态与隔离粒度”时选 Linux，并接受实时性是配置与验证问题；要求“移动应用体验与生态复用”时选 Android/AAOS，并把实时与安全责任划给相邻域。

3.6 RISC-V 64 位：从 ISA 特性到 RTOS 能力

RISC-V 的实时相关能力分布在三个抽象层：特权架构（M/S/U 模式、PMP、页表）、平台级设备（定时器与中断控制器）、可选扩展（Sstc、H 扩展等）。把这些构件映射到 RTOS 的软件能力，可以解释“为什么 RV64 现在适合跑 RTOS”，也可以解释“换平台时需要检查什么”。见图 2。

图 2：RV64 ISA 特性到 RTOS 软件能力的映射（左列为实时任务调度、可预测中断响应、隔离与保护、多核实时、多 OS 分区五组能力；右列为对应的定时器（CLINT/ACLINT 与 Sstc）、中断控制器（PLIC 至 AIA）、特权与保护（M/S/U + PMP、Sv39/Sv48）、原子与内存模型（A 扩展、RVWMO）、虚拟化（H 扩展）五组硬件机制）。来源为 RISC-V 特权架构手册（sv、machine、hypervisor、sstc 分册）、AIA/ACLINT 规范仓库与 RVA23 档位规范归纳；虚线箭头表示“硬件特性使能软件能力”的支撑关系，不代表唯一实现路径。[S29][S30][S31][S32][S33][S34][S35][S36][S37]

上表来源为 RISC-V 规范仓库与文档。[S29][S30][S31][S32][S33][S34][S35][S36][S38] 其中 Sstc 的规范原文给出其设计动机：特权架构原本只定义机器态定时器机制，S 态/HS 态的定时服务必须由 M 态经 SBI 调用代为提供，M 态软件需要把多个逻辑定时器复用到唯一的物理定时器上并转发中断；Sstc 为监督态提供自有的 CSR 定时机制（stimecmp），并同时为 VS 态提供 vstimecmp，从而“消除在 M 态模拟定时器与定时器中断生成的巨大开销”。[S33] 这段原文解释了为什么新平台（自 RVA23 档位起 H 扩展强制、Sstc 成为常见配置）对实时工作负载更友好：定时精度与抢占时延不再受固件调用路径牵制。[S36][S37]

需要提示的兼容性边界：旧平台（PLIC 时代的 SoC、无 Sstc 的核）依然可以跑 RTOS，但定时器路径依赖 SBI 往返或机器态实现，实时性分析需要把这部分开销计入最坏情况；AIA 与 Sstc 的可用性应以具体芯片手册为准，不能以 RISC-V 规范的存在推断芯片的提供。【P】

3.7 RV64 芯片与板卡生态

RISC-V 64 位 RTOS 的可用性最终落在芯片与板卡上。下表列出本次调研核验过公开资料的代表性平台，覆盖“开源板卡可跑通”与“面向车载/实时增强”两类需求。

上表来源为各厂商公开产品页与项目文档。[S08][S13][S19][S39][S40][S41][S42][S43][S44][S45][S46][S47] 对选型者而言，本表的关键信息不是“谁的核更强”，而是板卡级软件可用性：能在 Zephyr/NuttX/seL4 的官方目录里找到目标板，意味着 bring-up、驱动与回归测试有社区基线可依；否则项目需要自担全部移植成本。这一判据在后文建议与验收中反复使用。

3.8 RTOS 与 AUTOSAR：软件架构标准与内核实现的分工

AUTOSAR 不是操作系统，而是汽车软件的架构与接口标准体系，分 Classic Platform（CP）与 Adaptive Platform（AP）两条产品线。CP 的操作系统是规范内的组件：派生自 OSEK/VDX（ISO 17356 系列），采用静态配置、事件触发调度与可伸缩等级（scalability class SC1–SC4），内存与时间保护机制按等级提供，其实现由商业 RTOS 厂商承担。[S59][S60] AP 则以 POSIX PSE51 接口面定义操作系统能力边界：执行管理控制进程生命周期，应用通过进程与 IPC 模型运行；规范文本未点名具体宿主 OS，集成商可选用 Linux、QNX、PikeOS 等 POSIX 系统，公开产品生态也印证了这一组合模式。[S61][S62][S50][S54]

因此 RTOS 与 AUTOSAR 的关系可以一句话概括：AUTOSAR 回答“软件长什么样、接口是什么”，RTOS 回答“内核怎么实现、实时与安全如何被保证”。车规项目中的认证对象通常是后者及整个软件栈：QNX OS for Safety 8.0 声明通过 ISO 26262 ASIL D、IEC 61508 SIL3、IEC 62304 Class C 与 ISO/SAE 21434 认证；SAFERTOS 以 FreeRTOS 功能模型为基础、经 TÜV SÜD 认证至 SIL3；VxWorks 的 Cert Edition 与 653 产品线公开表述围绕 DO-178C DAL A 路径与 ISO 26262 等标准清单；PikeOS 以分离内核形态提供 RTOS 与 Type-1 虚拟化并支持 RISC-V；INTEGRITY 以分离微内核与 Multivisor 承接多域安全；ETAS RTA-OS 是 AUTOSAR OS 的商业实现。以上均为厂商公开声明，项目引用前应按证书范围复核。[S50][S52][S53][S54][S55][S56]

在整车电子电气架构上，这些部件组合成“双域 + 虚拟化”的常见形态：安全实时域运行 AUTOSAR CP + 车规 RTOS（硬实时、目标 ASIL-D，总线以 CAN/LIN/FlexRay 为主）；高性能计算域运行 AUTOSAR AP + Linux/QNX（吞吐与服务化，车载以太网承载 SOME/IP、DDS 等服务通信）；两域可物理分离，也可经 Type-1 Hypervisor 在同一 SoC 上分区共存（QNX Hypervisor、PikeOS、INTEGRITY Multivisor、Jailhouse 等方案）。AGL 等开源项目在同一图谱中承担座舱侧的开源底座角色。见图 3。

图 3：RTOS 与 AUTOSAR 在车规软件中的定位（左侧为安全实时域：功能域—AUTOSAR CP 栈—车规 RTOS/安全内核—MCU/实时核；右侧为高性能计算域：功能域—AUTOSAR AP 栈—宿主 OS（Linux+PREEMPT_RT/QNX/PikeOS）—高性能 SoC；两侧虚线箭头分别为服务化数据流（SOME/IP、DDS）与单 SoC 混合关键性分区（QNX Hypervisor、PikeOS、INTEGRITY Multivisor、Jailhouse））。来源为 AUTOSAR R25-11 规范、QNX/Wind River/GHS/SYSGO/SAFERTOS/ETAS 公开产品资料与 Jailhouse 项目文档归纳；认证等级均为厂商单方声明。[S50][S51][S52][S53][S54][S55][S57][S58][S59][S60][S61][S62][S63]

能力成熟度对比矩阵

上表为综合定性评估，用于快速定位而非评分排名；各单元格依据见相关章节来源。[S07][S19][S23][S27][S28][S36][S45][S50][S52][S55]

4. 国内发展、差距与机会

4.1 国内 RTOS 与 RISC-V 64 生态的公开进展

国内在这一交叉领域的公开进展集中在三条线：RTOS 本体、芯片与工具链、车规合作。

RTOS 本体。RT-Thread 是国产社区主导、以 Apache-2.0 许可发布的开源 RTOS，组件化裁剪与中文生态是其显著特征；其 libcpu/risc-v 目录已覆盖 common64、rv64、t-head、virt64 等 RISC-V 移植层，并覆盖 RV32E 到 RV64D 的指令集变体，是国内 RV64 平台上最常被引用的开源 RTOS 之一。[S15][S16]

芯片与工具链。芯来科技在 900 系列（NX900/UX900）与 1000 系列（UX1000 至 UX1060，公开资料标注 RVA23 与 RV64IMAFDCVB 方向）上持续迭代 RV64 产品线；其 Nuclei SDK 官方说明“集成了多款 RTOS，包括 FreeRTOS、UCOSII、RTThread 与 ThreadX”，为国内开发者提供了从裸机到多款 RTOS 的统一板级支持。[S45][S46][S47][S49] 芯片侧，嘉楠 K230、赛昉 JH7110、进迭时空 K1、平头哥 C920/R910 等平台分别覆盖视觉 AI、开源单板、应用级多核与实时控制方向，其中多款已进入国际开源 RTOS 的官方支持目录（见 3.7 表）。[S40][S41][S42][S43][S44]

车规合作。芯来科技与 Quintauris 于 2026 年公开合作，围绕 RT-Europa 汽车实时 RISC-V 平台推进“车规实时就绪”；RT-Europa 平台的公开定位包含强制 PMP、安全岛与面向实时场景的 profile 特性。[S48][S63] 结合 RT-Thread 与 Nuclei 生态可见，国内已形成“芯片 IP + 开源 RTOS + 车规平台合作”的公开链路，但与量产级延迟数据、完整认证证据链之间仍有距离。

4.2 差距与机会

差距一：证据链而非功能。国内项目已将多款 RTOS 移植到 RV64 芯片并公开演示，但公开材料普遍缺少可复现的最坏情况延迟数据（中断延迟分布、调度抖动、长时间压力回归）与认证范围说明；对车规客户而言，证据缺口比功能缺口更致命。[S19][S45][S48]

差距二：SMP 与实时增强的公开验证不足。RV64 多核平台（JH7110、K1 等）已常见，但开源 RTOS 在其上的多核实时调度质量、缓存与内存一致性对延迟的影响，缺少公开的系统性测试报告；平头哥 R910 等实时增强核的公开数据也以产品定位表述为主。[S42][S44]

差距三：工具链与安全件成熟度。国外安全 RTOS 的产品化配套（认证工具链、安全手册、长期支持）经过多年打磨；国内开源 RTOS 与芯片工具链在这些“非功能资产”上的积累仍在建设期。[S50][S54][S55]

机会一：混合关键性平台是窗口期。RVA23 把 H 扩展列为强制项、AIA 与 Sstc 进入新平台默认配置，意味着“单芯片上 RTOS 与 Linux/Android 分区共存”的硬件门槛在下降；RT-Europa、Jailhouse 等公开项目的活跃表明这一形态尚在定型，先行者可以参与规则制定。[S36][S48][S57][S63]

机会二：学习与预研成本已大幅下降。开发者可用 QEMU RISC-V、VisionFive 2、BPI-F3 等公开硬件，在 Zephyr/NuttX/seL4 的官方板卡支持上直接开展 RTOS 实践，再进入车规商业化路径；这为国内团队提供了低成本的切入点。[S08][S13][S19][S40]

5. 关键机制深挖

5.1 调度与确定性：优先级抢占的收益与边界

优先级抢占是 RTOS 最核心的机制承诺：任务按固定优先级组织，最高优先级的就绪任务总是获得 CPU；同优先级任务以时间片轮转，避免同优先级任务相互饿死。[S01][S09] 车规与实时领域的公开定义同样以“优先级驱动的抢占式调度 + 有界响应”为 RTOS 的判别特征。[S20] 但机制本身只给出“上界如何计算”的框架，上界的真实性取决于四件事——临界区长度、阻塞时间、中断路径、定时精度。

接口与实现依据：Zephyr 的调度器文档定义优先级抢占为默认模型（数值越小优先级越高），时间片长度与适用优先级区间可由 Kconfig 配置；协作式线程不被抢占，运行到主动让出为止。[S01] FreeRTOS 以配置宏组织同类语义（抢占开关与时间片开关分离），其内核在所有受支持架构上保持统一调度模型。[S09] QNX 的实时系统指南把“优先级驱动、抢占式、有界延迟”作为硬实时的判定要素，并区分硬/软实时的失效后果。[S20]

失效边界：第一，优先级反转：高优先级任务等待被低优先级任务持有的互斥资源，间接阻塞时长可能无界，需要优先级继承或优先级天花板限制；分析时必须把阻塞时间计入最坏情况。第二，临界区与中断关闭区间：内核在任何长时间关中断的代码段都会推迟所有中断响应，中断延迟上界由最长不可抢占区间决定，而不是由调度器算法决定。第三，时间片与节拍精度：轮转粒度依赖内核时钟精度，配置不当会把调度抖动放大到节拍量级。第四，共享资源密集的系统里，抢占无法消除阻塞，只能为阻塞时间设定上限——一旦资源设计失衡，优先级数量再多也救不回截止期。【P】

验证条件：实时性证据必须落到测量：以定时器捕获或 GPIO 翻转配合示波器/逻辑分析仪测量中断延迟与任务唤醒延迟的分布，报告最坏值而非均值；在压力场景（高频中断、满载任务、共享资源竞争）下做长时回归，确认最坏值不发散；对优先级反转场景做定向测试（故意构造低优先级任务持锁让高优先级任务阻塞）。Zephyr 项目在其功能安全路线中引入延迟基准测试作为证据实践的一部分，可作为社区层面的参照。[S03][S07]

成本与权衡：固定优先级的代价是配置刚性：需求变化往往意味着重新做可调度性分析；抢占频率提高会带来上下文切换与缓存污染开销，在 RV64 应用级核上这类缓存效应比 MCU 更明显；实现优先级继承增加了内核复杂度与最坏阻塞分析成本；过度使用高优先级任务会破坏系统的整体可预测性——这也是“所有任务都重要”的项目通常最不实时的原因。【P】

5.2 内存与隔离：静态内存、MPU/PMP 与虚拟内存的取舍

内存是第二个确定性主战场。RTOS 的常规姿态是“配置期静态化”：把分配不确定性在编译与配置阶段消灭；Linux 的姿态相反，用地址翻译与按需分配换取利用率与隔离粒度。[S02][S24] 两者的差异决定了各自的失效模式。

接口与实现依据：Zephyr 的内存管理文档区分固定块内存池（slab）与堆（heap），明确建议优先使用固定块分配以避免碎片与分配时延波动；内核对象的静态定义（Kconfig/K_THREAD/内存域）是其推荐路径。[S02] 用户态隔离侧，Zephyr 通过 MPU/PMP 内存域为线程授予分区权限，内核对象经系统调用代理访问，RISC-V 平台对应 PMP 机制。[S04][S31] Linux 侧的对应物是虚拟内存与 overcommit 策略：内核文档给出三种 overcommit 模式（含启发式与严格模式）及各自在内存压力下的行为差异。[S24] RISC-V 上，页式虚拟内存由 Sv39/Sv48（最高 Sv57）定义，是进程隔离与按需分页的硬件基础。[S30]

失效边界：静态化的失效模式是“计划外的碎片与溢出”：堆在长期运行后碎片化会让分配失败或时延增长；栈溢出若没有保护域兜底，会静默破坏相邻内存，最终以随机故障形式暴露。保护域侧的限制在于粒度与容量：MPU/PMP 以区域为单位授权，区域数量有限，映射设计在复杂系统中很快捉襟见肘。虚拟内存的失效模式是“抖动与超售”：缺页处理把毫秒级抖动引入本来微秒级的路径；overcommit 在压力下触发回收乃至 OOM，失败时机由系统整体压力决定而非由业务优先级决定。[S24]

验证条件：内存确定性的验证依赖三类手段：峰值与水位观测（各任务栈高水位、堆碎片度量、内核对象计数）；故障注入（越权访问触发 MPU/PMP 异常后，异常处理路径本身要被测试覆盖）；长时间运行回归（把碎片与泄漏问题在测试期暴露，而非在现场暴露）。虚拟内存侧的验证重点是压力下的行为：内存紧张时业务路径的最坏延迟是否仍被测量与接受。[S02][S04][S24]

成本与权衡：静态内存以灵活性为代价：内存预算需要人工规划、功能的动态性受限，换来的是可分析的最坏分配时间；虚拟内存以地址翻译开销与页错误路径为代价，换来进程级隔离、按需分配与“内存超售”的利用率；MPU/PMP 分区比 MMU 方案更省面积与功耗，代价是区域数量与映射自由度。对 RV64 RTOS 而言，组合策略通常是：内核与关键任务静态化，非关键子系统用固定块池，只有需要多进程语义的场合才引入页表。【P】

5.3 RV64 平台机制：定时器（Sstc）、中断（AIA）与虚拟化（H 扩展）

RV64 平台上，实时能力的三个关键硬件旋钮是定时器路径、中断路径与虚拟化路径，对应三份规范：Sstc 扩展、AIA（高级中断架构）与 H 扩展。[S32][S33][S34]

接口与实现依据：Sstc 规范原文描述了其动机：特权架构原本只为机器态定义定时器机制（mtime/mtimecmp），S 态定时服务必须经 SBI 调用由 M 态代管，M 态软件需要把多个逻辑定时器复用到唯一物理定时器并转发中断；Sstc 为监督态提供自有 CSR（stimecmp）并为 VS 态提供 vstimecmp，规范明确其目的是“消除在 M 态模拟定时器与定时器中断生成的巨大开销”。[S33] 中断侧，AIA 规范以 IMSIC（消息信号中断控制器）与 APLIC（应用级中断控制器）替代早期 PLIC 的直接线控模型，为中断直投与虚拟化投递提供标准构件。[S34] 虚拟化侧，H 扩展提供两阶段地址翻译与虚拟中断机制，RVA23 档位起为强制项；seL4 的硬件文档同时说明“hypervisor 扩展支持尚未并入主线”，提示软件生态与硬件特性的进度并不同步。[S32][S36][S19]

失效边界：第一，平台代际差异：无 Sstc 的旧平台上，定时器路径要把 SBI 往返开销计入最坏延迟，实时分析不能直接沿用新平台的数字。第二，中断控制器迁移成本：AIA 需要新的内核驱动与虚拟化支持，过渡期内 PLIC 与 AIA 两套栈并存，跨平台驱动代码的分支会持续存在。第三，虚拟化的软件缺口：芯片具备 H 扩展只是必要条件，目标 Hypervisor/内核是否已经支持该平台、是否通过一致性测试，需逐个核对（seL4 的公开说明即为实例）。第四，固件与协商：在 S 态运行的 RTOS 依赖 OpenSBI 一类固件提供 SBI 服务，固件版本、扩展位探测与设备树描述的任何缺失都会导致功能降级或启动失败。[S19][S33][S34][S38]

验证条件：对 Sstc：在目标平台上对比启用/未启用场合的定时器中断处理时延，并在规范要求的 STCE 控制位路径上做开关测试。[S33] 对 AIA：验证中断直投与虚拟中断投递的正确性（结合虚拟化测试），并测最坏中断延迟分布。[S34] 对 H 扩展：以两阶段翻译与虚拟中断的行为一致性测试为验收件，核对目标 Hypervisor 的官方支持列表后再制定集成计划。[S19][S32] 对固件：把 SBI 扩展探测与版本核对纳入板级 bring-up 检查单。[S38]

成本与权衡：新机制把最坏延迟的下限压低，代价是与新硬件绑定——多平台产品需要维护新旧两条定时/中断路径；AIA 迁移短期增加驱动与虚拟化集成成本，长期收益是统一的中断语义与更好的虚拟化支持；H 扩展开启的混合关键性分区能显著减少整机 BOM 与线束，但共享缓存与内存带宽的干扰需要靠分区规划与性能预留来管理，这部分工程成本必须计入预算。【P】

5.4 车规认证与混合关键性：RTOS 作为安全底座的证据链

在车规语境中，“RTOS 好不好”的最终裁判是证据链：功能安全等级、安全手册、工具链资格与长期支持，而不是调度器的名字。[S50][S54][S55]

接口与实现依据：AUTOSAR 侧，CP 定义 OS 的行为与配置模型（OSEK/VDX 派生、静态配置、可伸缩等级 SC1–SC4），其商业实现承担认证责任；AP 以 POSIX PSE51 定义接口面与进程模型，宿主 OS 由集成商选择。[S59][S60][S61][S62] 车规 RTOS 侧，QNX OS for Safety 8.0 声明 ASIL D、SIL3、IEC 62304 Class C 与 ISO/SAE 21434 认证；QNX Hypervisor 以嵌入式虚拟化产品形态面向安全场景；SAFERTOS 以 FreeRTOS 功能模型派生、经 TÜV SÜD 认证至 SIL3；VxWorks Cert Edition 与 653 围绕 DO-178C DAL A 路径与 ISO 26262 等标准清单公开表述；PikeOS 以分离内核提供 RTOS 与 Type-1 虚拟化并支持 RISC-V；INTEGRITY 以分离微内核与 Multivisor 承接多域；ETAS RTA-OS 是 AUTOSAR OS 的商业实现。[S50][S51][S52][S53][S54][S55][S56]

失效边界：第一，认证对象的边界：证书绑定产品版本、配置与工具链，同一品牌的另一配置可能不在证书范围内，“采用认证内核”不自动等于“项目合规”。第二，术语边界：“预认证”“认证就绪”“可认证”与“已认证”含义不同，将前者当后者使用是最常见的误读风险。第三，混合关键性的链式依赖：若 Hypervisor 自身不在安全范围内，其上安全分区的安全论证需要额外机制（时间/空间隔离论证或独立看门狗），否则混合等级被 Hypervisor 拉低。第四，开源替代的限制：开源 RTOS 用于安全域时，安全案例、工具链资格与证据维护都需要项目自建，公开材料中尚无成品证书可以直接引用。[S07][S50][S54]

验证条件：验收动作应可操作：索取证书与安全手册，逐条核对版本、配置与适用范围；针对目标硬件与自研驱动做认证差异分析（哪些软件不在证书假设内）；按项目安全计划执行集成验证（故障注入、覆盖度量、看门狗与安全状态迁移演练）；把供应商长期支持承诺写入合同条款。以上动作产出的书面材料，构成“RTOS 作为安全底座”的可审计证据。[S50][S52][S55]

成本与权衡：认证的总成本 = 软件许可 + 工具链资格认证 + 证据维护 + 长期支持，随安全等级、平台数量与使用年限增长；选择已认证内核能显著压缩证据成本与项目风险，代价是定制自由度与对供应商的绑定；用开源方案自建证据链是一种人力密集型投资，适合有长期平台战略、认证需求可分批推进的组织。对多数量产项目，现实策略是“安全域用认证件、非安全域用开源件”，并通过隔离机制控制两者边界。【P】

6. 演进方向与情景

6.1 技术走向

未来两到三年，本领域有五条可跟踪的技术线。

第一，实时 Linux 从“补丁工程”变为“配置与验证工程”。 PREEMPT_RT 收尾进入 6.12 合并窗口后，实时抢占成为内核选项，竞争焦点从“谁能打补丁”转向“谁能在目标硬件与驱动栈上验证最坏延迟”。[S23] 这对 RTOS 的影响是双向的：中等实时场景可能被 Linux 吸走，而微秒级与安全关键场景因分析成本与认证证据需求继续留在 RTOS。【P】

第二，RV64 RTOS 的运行形态上移。 从“直接接管机器态”转向“在 S 态经 SBI 运行”成为常规选择，OpenSBI 一类固件的成熟让 RTOS 可以复用平台抽象；Sstc 与 AIA 进入新平台的默认配置后，定时与中断路径的开销结构随之改变。[S33][S34][S38] 与之配套的是 RVA23 档位把 H 扩展列为强制项，虚拟化从高端特例变成默认能力。[S36][S37]

第三，开源 RTOS 的安全证据开始积累。 Zephyr 项目按 IEC 61508 路线与 SeooC 方法推进功能安全，并把延迟基准纳入证据实践；seL4 的验证方法学持续向平台移植扩展（RISC-V 目标已在官方硬件页列出）。[S07][S18][S19] 这里的进度值得跟踪，因为它决定开源方案能否跨过车规项目的第一道证据门槛。

第四，车规 RISC-V 走向“平台打包”。 芯来科技与 Quintauris 围绕 RT-Europa 的合作把 CPU IP、实时 profile 与工具链打包推进，属于“芯片-OS-工具链协同交付”的典型形态。[S48][S63] 这类平台把 PMP 强制、安全岛与实时增强作为卖点，意味着单点 IP 竞争正在升级为平台级竞争。

第五，混合关键性下沉为默认架构选项。 H 扩展的强制化与 AIA 的虚拟中断支持降低了单芯片多域方案的硬件门槛，QNX Hypervisor、PikeOS、INTEGRITY Multivisor、Jailhouse 等项目覆盖了从商业认证到开源静态分区的完整谱系。[S36][S51][S53][S54][S57] 对 RTOS 而言，最可能的长期形态不是消失，而是以“安全分区/实时分区”的身份嵌进虚拟化架构。【P】

6.2 三种情景

三种情景并不互斥，更可能按场景并行出现：MCU 级控制长期停留在情景 A；高性能域的服务化负载推动情景 B；域控制器与中央计算平台推动情景 C。[S36][S48][S51][S57][S63]

6.3 关键观察信号

• RVA23 芯片的量产节奏，以及 Sstc/AIA 在量产芯片手册中的默认配置情况。[S36][S45]
• 开源 RTOS 在 RV64 上发布可复现的最坏情况延迟基准（含测试方法与硬件清单）。[S07][S13]
• seL4 的 hypervisor 扩展支持是否并入主线，以及 RISC-V 目标板的验证范围扩展。[S19]
• 车规 RTOS 厂商在 RISC-V 平台上的认证发布与工具链落地进度。[S50][S54][S55]
• 国内平台合作（如 RT-Europa 与芯来的后续动作）是否带来量产级数据与认证声明。[S48][S63]

7. 建议与验收

7.1 决策前必须回答的三个问题

问题一：端到端的最坏情况延迟目标是多少，由谁测量？ 如果团队答不出数字与测量方法，任何“需要 RTOS / 不需要 RTOS”的争论都缺少依据。正确的起点是先建立延迟基准（见 7.3 的工作包）再选型。【P】

问题二：需要哪种隔离与生态？ 单地址空间的任务隔离（RTOS + MPU/PMP）、进程级隔离（Linux/QNX）、应用沙箱与移动生态（Android/AAOS）各自对应不同的产品形态与团队技能；隔离粒度直接决定内核选择。[S02][S04][S24][S28]

问题三：是否需要认证证据？ 目标等级（ASIL/SIL/DAL）与量产时间决定内核与工具链的路线：安全域引用已认证内核可以显著压缩证据成本，非安全域用开源方案并靠隔离控制边界。[S50][S52][S54][S55]

7.2 场景化选型建议

上表为条件性建议，具体项目需结合目标等级、量产时间与团队技能复核；各基座的公开支持状态见第 3 节来源。[S08][S13][S19][S23][S40][S41][S42][S45][S49][S50][S54][S57]

7.3 工作包与验收口径

建议—验收矩阵

7.4 不建议的做法

不建议用 Android/AAOS 直接承担安全或硬实时功能——其运行时与内存治理机制不以最坏情况延迟为目标，官方文档也未给出相关指标。[S26][S27][S28] 不建议在没有基准的情况下宣称“实时”，无论对象是 RTOS 还是 PREEMPT_RT Linux——机制存在与最坏值达标是两件事。[S23][S24] 不建议把厂商新闻稿中的“首个”“最快”等表述当作技术判据，认证与性能主张都需要按证据链复核。[S50][S55] 不建议在 RV64 上直接把 Linux 的单进程思维套进 RTOS——单地址空间、静态优先级与静态内存意味着移植问题首先是架构问题而不是编译问题。【P】

8. 不确定性与研究限制

本次调研受限于公开资料与研究方法，以下限制影响结论强度：其一，未做目标硬件实测，所有延迟与确定性讨论停留在机制与文档层面，具体数值需项目自行测量；其二，厂商认证等级均为单方声明，未向认证机构或证书数据库核对；其三，开源项目迭代频繁，文中引用版本状态以 2026-09-29 为准；其四，部分站点存在区域性网络波动，个别官方页面的可达性可能随时间变化；其五，未进行功能安全与信息安全的正式评估，涉及等级与合规的表述都限定为公开资料梳理。

本次未获证据支撑、需要标注为待观察的项包括：Android 官方从未以“非实时”自述（本次未找到原句，相关判断以研究分析形式给出）；ThreadX 功能安全证书的确切等级标签未在官方页面确认（仅见标准引用，等级以厂商声明为准）；COQOS 等产品的完整认证清单主要来自新闻稿而非产品页；AAOS 在分区虚拟机形态中的运行假设未获官方文档确认。以上各项不进入结论承重，只作为观察线索。

主张—证据矩阵

参考来源

以下链接均在 2026-09-29 研究过程中访问核验（HTTP 200）；个别站点存在区域性网络波动，可达性可能随时间变化。规范类来源为 RISC-V 与 AUTOSAR 官方文件；项目类来源为官方文档与官方代码仓库；厂商类来源为产品页或官方新闻，认证等级按单方声明处理。

附录：研究方法

本报告采用“官方文档优先、证据分级、逐条核验”的方法：首先以 RISC-V 规范仓库、AUTOSAR 规范文件与各 RTOS/操作系统官方文档建立机制基线；其次以官方代码仓库与发行资料核对实现事实（移植目录、板卡列表、SDK 集成）；再以厂商产品页与官方新闻收集认证与产品定位，全部按“单方声明”处理；最后以第三方权威媒体（如 LWN）交叉印证时间线类事实。全部 URL 在 2026-09-29 通过远程访问核验可达性，核验方式为按条目逐条请求并记录状态。

图表部分：三张 SVG 图均为本报告基于上述来源归纳绘制的定性示意图（Graphviz 生成），用于表达结构与关系，不表示具体产品的模块划分、性能数值或供应商排名；图注中已标注数据口径与来源编号。凡涉及认证等级、产品能力的表述均限定为公开资料原意，不构成认证评估或采购建议。

本次调研未使用任何非公开资料，未执行第三方仓库代码，未安装生产依赖，未采集与任务无关的个人通信或工作数据。