AUTOSAR 知识综述与 RISC-V 32 位 RTOS 承载 Adaptive Platform 的可行性调研

版本历史

术语与缩略语

可靠性标记

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

版本规则：除明确注明其他版本外，AUTOSAR 结论均指 R25-11（2025-11-27 发布）规范；产品能力以厂商公开页面为准，不把“支持某标准版本”自动等同于“通过相应认证”。功能存在、功能可用、功能通过目标环境验收，是三个不同判断。

1. 核心判断（TL;DR）

• 【C】AUTOSAR 是并列的两条产品线，不是同一条线的两代版本。Classic Platform 面向 MCU 级实时控制，采用 OSEK 派生的静态配置 OS 与 RTE 分层架构；Adaptive Platform 面向高性能计算单元，要求 POSIX PSE51 接口与 C++17、以 ara::* 功能集群提供服务，进程由 Execution Management 统一控制。[S01][S02][S03][S04][S05]
• 【C】AP 对操作系统有一组不可回避的硬性要求。R25-11 的 OSI 规范要求多进程支持、进程间隔离（非法访存必须被 OS 检测）、每个进程运行在独立地址空间，并要求至少 8 组 ResourceGroup 及内存/CPU 限额；这些条款在 RV32 车规核（普遍只有 PMP/MPU、无 MMU）与主流 RV32 RTOS（单地址空间任务模型）上不能直接满足。[S01][S17][S22][S28]
• 【C】Vector 的 AUTOSAR 产品谱系覆盖 CP 与 AP 两侧，但 RV32 上的现实覆盖面是经典平台。MICROSAR Classic 与 MICROSAR Adaptive 分别提供两层基础软件（后者含 UCM 与 SOVD 诊断、验证至 ASIL D），DaVinci 系列负责建模与配置，CANoe/CANape/vTESTstudio/TA Tool Suite/VectorCAST 构成测试验证链；Vector 已宣布与 Quintauris 合作把 MICROSAR Classic 集成到 RT-Europa 汽车 RISC-V 参考平台（2025-12 宣布，CES 2026 演示），暂无 RV32 裸 RTOS 上的 AP 产品形态。[S11][S12][S13][S14][S15][S16]
• 【S】AUTOSAR 官方开源实现 CAPI 改变了“从零实现 AP”的成本结构，但没有改变完整 AP 的宿主前提。CAPI 1.0 包含 15 个核心功能集群的源代码与代码生成器，基线对应 AP R20-11，定位为认证就绪的 Linux/POSIX 运行基础；普华基础软件是参与代码贡献的中国企业之一。对 RV32+RTOS 而言，它降低了“参考实现从哪里来”的门槛，但移植工作仍需把 Linux 语义替换为目标 RTOS 语义。[S08][S09][S10]
• 【P】综合判断：在 RV32 RTOS 上“跑通完整 AP”不现实；可行目标是把 AP 裁剪为受控子集。建议先明确“跑通”的验收层次（能启动、能通信、能更新、或规范合规），再选择路线：学习与预研用 RV64 + Linux/QNX 或官方 CAPI；量产安全控制器走 CP；确有 RV32 约束且必须引入 AP 概念时，接受规范偏差清单，把多进程/MMU 依赖项降级为逻辑隔离并单独论证。[S01][S03][S08][S30][S31]

2. 问题、范围与方法

2.1 调研对象与证据来源

本次只使用公开材料，不采集个人邮件、聊天、OKR 或企业内部数据。证据分四类：AUTOSAR 官方规范 PDF（R25-11 的 AP/CP 核心文档，见附录）、RTOS 与平台官方文档（Zephyr、FreeRTOS、NuttX、QNX、PikeOS 等）、厂商产品页与新闻（Vector、Quintauris、Nuclei、Infineon 及国内厂商）、第三方公开报道。所有 URL 均在研究截点前实际访问核验。

本报告不执行第三方仓库代码、不安装生产依赖、不进行目标板实测，因此所有“可行性”结论属于规范与公开资料层面的判定，不构成实测结果。

2.2 “跑通”的四个可分辨层次

“在 RV32 RTOS 上跑通 AUTOSAR AP”这句话在不同人口中含义差别很大。为避免把演示级成功当成产品级能力，本报告把“跑通”拆成四个层次，后续章节的差距分析与工作量估算均按此口径：

这张表也解释了为什么“跑通”必须先定验收层次：L1/L2 的演示可以在几周内做出雏形，而 L4 是另一个量级的工程与认证问题。

3. 全球技术基线

3.1 CP 与 AP：两条产品线的定位差异

Classic Platform 的根基是 OSEK/VDX 操作系统：事件触发、固定优先级调度、静态配置，规范中随保护能力定义了 SC1–SC4 等可伸缩等级（含内存与时间保护），运行在典型 16/32 位 MCU 上；其软件架构分应用层、RTE 与基础软件（服务层、ECU 抽象层、复杂驱动、MCAL）。它解决的是“确定性与资源受限”问题。[S04][S05]

Adaptive Platform 的根基则是 POSIX PSE51 与 C++17：应用以 C++ 编写、按进程组织、通过 ara::* 接口使用功能集群；规范明确 OSI 本身不提供执行与控制进程的手段，AP 进程完全由 Execution Management 通过实现特定接口控制；同时指出典型 AP 栈通常不单独实现 OSI，因为功能已由标准库提供。它解决的是“动态部署与高算力”问题，主流宿主是带 MMU 的 Linux、QNX、PikeOS 等 64 位系统。[S01][S02][S03][S06]

两者不是版本演进关系：同一车辆可以 CP 管实时控制、AP 管计算服务，通过 SOME/IP、DDS 或信号网关跨平台通信。见图 1，左右两侧的依赖链与运行假设完全不同，这是后文所有差距分析的起点。

图 1：CP 与 AP 的架构对照与跨平台通信边界。左侧 CP 链路为应用—RTE—BSW—OSEK 派生 OS—MCU；右侧 AP 链路为 C++17 应用—ara::* 功能集群—POSIX PSE51 接口与 C++ 标准库—带 MMU 的多进程 OS—计算 SoC。来源为 AUTOSAR R25-11 的 SWArchitecture 与 CP 分层架构文档归纳；为架构示意，不表示具体产品的模块划分。[S03][S05]

3.2 AP 的功能集群与最小可用集合

R25-11 的 AP 软件架构把平台划分为若干功能集群组：Runtime（Execution Management、State Management、Log and Trace、Core、Operating System Interface）、Communication（Communication Management、Raw Data Stream、Network Management、Time Synchronization、API Gateway）、Storage（Persistency、Remote Persistency）、Security（Cryptography、IDS Manager、Firewall）、Safety（Platform Health Management、Safe Hardware Acceleration）、Configuration（UCM、Vehicle UCM、Registry）与 Diagnostics（Diagnostic Management）。[S03]

对“最小可跑通”而言，真正必选的是 Runtime 组的 EM、Log and Trace、Core、OSI 四者：没有 EM 就没有进程生命周期与状态上报，没有 ara::core 就没有应用可依赖的基础设施。通信、存储、更新、诊断属于按场景增补的能力。这一取舍直接决定 RV32 路线的功能裁剪范围：

3.3 AP 对 OS 与语言的硬性要求（差距判定的基准）

判断“RV32 RTOS 能不能承载 AP”，基准是 R25-11 的 OSI 规范条款。其中最关键的几条：SWS_OSI_01008 操作系统应支持多进程；SWS_OSI_01009 操作系统应隔离各进程，使非法访存被检出；SWS_OSI_01010 每个进程运行在独立（虚拟）地址空间，同可执行体的多个实例可共享只读代码与数据、可写数据必须分离；SWS_OSI_01014 允许配置进程禁止创建其他进程；SWS_OSI_02000 至少支持 8 组 ResourceGroup；SWS_OSI_02001/02002 支持内存与 CPU 资源限额，且内存核算需包含页表项等开销；调度策略需覆盖 SCHED_OTHER、SCHED_FIFO、SCHED_RR；getenv() 需在 C++ 静态初始化阶段可用。[S01]

语言侧，AP 要求 C++ 接口兼容 ISO 14882:2017（C++17），并以 MISRA C++:2023 作为关键系统编码准则；POSIX 侧以 PSE51 为接口边界。[S02] 运行时侧，EM 规定进程需通过 ara::exec::ExecutionClient::ReportExecutionState 上报 kRunning，终止流程与 SIGTERM 语义配合。[S06] 通信侧，ara::com 定义网络绑定（SOME/IP、DDS）、信号绑定与进程间通信等多种部署形态，具体绑定由服务实例清单与实现决定。[S07]

上述条款构成后文逐条差距分析的检查表；值得注意的是 SWS_OSI_01010 的表述直接暗示了虚拟内存与 MMU 级能力的依赖，这也是 RV32 路线最核心的冲突点。

3.4 Vector 的 AUTOSAR 产品谱系

Vector 是 AUTOSAR Premium Partner，其产品线覆盖从 ECU 基础软件到开发测试工具的完整链条，是评估 AUTOSAR 落地时最常被引用的商业基线：

来源为 Vector 官方产品页与产品总览。[S11][S12][S13][S14]

对 RISC-V 生态，Vector 的动作集中在经典平台侧：2025 年 12 月宣布与 Quintauris 技术合作，把 MICROSAR Classic 集成进 RT-Europa 汽车实时 RISC-V 参考架构，并在 CES 2026 联合演示。[S15][S16] 截至研究截点，未检索到 Vector 提供 RV32 裸 RTOS 形态 AP 栈的公开信息，因此“用 Vector 产品在 RV32 RTOS 上跑 AP”在本报告中不构成可评估路线。

3.5 宿主 OS 与商业 AP 栈对照

完整 AP 的宿主生态是明确的：MISRA 之外的现实选择集中在 QNX、PikeOS 一类可认证系统。QNX OS for Safety 8.0 由 TÜV Rheinland 认证至 ISO 26262 ASIL D、IEC 61508 SIL3、IEC 62304 Class C，并覆盖 ISO/SAE 21434。[S30] SYSGO PikeOS 以 RTOS + 分离内核 Type-1 Hypervisor 形态支持混合关键性分区，其 5.1.3 版本经 TÜV SÜD 预认证至 DO-178C DAL A、EN 50716 SIL 4、ISO 26262-6 ASIL D、IEC 61508 SIL 3，分离内核获 Common Criteria EAL 5+ 认证，且支持 RISC-V。[S31] 商业 AP 中间件方面，ETAS 的 RTA-VRTE（General Purpose Profile based on AUTOSAR）面向微处理器并提供 ISOLAR-VRTE 工具链，标称支持至 ASIL D 的安全系统；[S32] Elektrobit EB corbos AdaptiveCore 定位 HPC 的 AUTOSAR Adaptive 中间件，支持 R20-11 规范与 Linux/QNX，安全等级表述依附其组合的安全产品。[S33]

官方开源实现方面，AUTOSAR 组织的 CAPI 1.0 提供 15 个核心功能集群的源代码与代码生成器，含可直接搭建的演示，基线对应 AP R20-11（部分接口前瞻兼容 R23-11），定位为“认证就绪”的协作底座，并强调功能安全（ISO 26262）与网络安全（ISO/SAE 21434）设计；代码经官方 Git 仓库分发，普华基础软件为其贡献方之一。[S08][S09][S10]

能力成熟度对比矩阵

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

4.1 国内基础软件与芯片的公开进展

国内 AUTOSAR 生态的发力点目前集中在两个位置：经典平台基础软件与车规 MCU 芯片。Adaptive 侧则以“符合 AP 规范版本 + 认证等级”的宣称为主，尚缺少公开的 RV32 RTOS 落地案例。

来源为各厂商官网与官方新闻、行业媒体公开报道。[S34][S35][S36][S37][S38][S39][S40][S41][S10]

4.2 差距与机会

差距一：AP 侧缺少 RV32 形态的公开落地。国内 AP 产品（NeuSAR、普华 Adaptive 相关、经纬恒润 EAS-AP）的公开验证对象是 RISC-V 多核或 64 位平台，未检索到 RV32 裸 RTOS 上运行 AP 的公开案例。这与 3.3 节列出的 OSI 条款直接相关：多进程、隔离与虚拟内存要求在无 MMU 的 RV32 核上无法按规范原义满足。[S01][S34][S37]

差距二：芯片与 OS 的认证证据链尚不完整。CPU IP 有 ASIL-D 证书、MCU 有 ASIL-B 证书，并不等于“RV32 RTOS + AP 中间件”的整体组合能达到相应等级。组合级认证需要 OS 安全手册、中间件安全论证与集成假设清单，而开源 RTOS 在这一环普遍薄弱（见 5.5 节）。[S22][S23][S31][S38]

机会一：CP 侧的 RISC-V 拼图正在补齐。Nuclei 的 ASIL-B/D 内核、Vector 与 Quintauris 把 MICROSAR Classic 集成到 RT-Europa 参考平台、国内厂商的 CP 栈适配动作，共同说明“RV32 车规核 + AUTOSAR CP”正在从演示走向可工程化。对量产控制类项目，这是当前代价最低的 AUTOSAR 路线。[S15][S22][S25][S34][S37]

机会二：CAPI 把 AP 的“底座”变成公共品。CAPI 1.0 提供 15 个功能集群源码与生成器，且中国企业已参与贡献。[S08][S09][S10] 对希望研究 AP 内部机制、或计划做 AP 子集移植的团队，起点从“读懂 20 余份规范并自研”变为“读懂参考实现并裁剪”，工作量结构发生实质变化。但需要注意其基线是 Linux/POSIX，RV32 目标仍需替换进程、文件系统与内存语义，这部分工作量并未因 CAPI 消失。

机会三：差异化空间在“管理面”而非“控制面”。若目标是区域控制器一类的混合架构，可以把 CP（实时控制）与裁剪后的 AP 子集（配置管理、日志、诊断等管理面）分置于同一 SoC 的不同域，AP 子集运行在带 MMU 的 64 位小核上，而 RV32 核专注 CP 任务。这规避了 RV32 承载 AP 的硬冲突，同时保留了 AP 的部署与更新模型。[S03][S05]

5. 关键机制深挖

5.1 PSE51 适配层：把 AP 的 POSIX 预期映射到 RV32 RTOS

接口与实现依据：AP 应用按 POSIX PSE51 编程，规范明确 OSI 提供线程创建与属性控制、信号量、内存锁定、实时信号、消息传递、高精度定时器与时钟等能力，但不提供文件系统 API，也不提供执行与控制进程的手段。[S01][S03] 在 RV32 上，这层能力必须由 RTOS 提供或补齐：Zephyr 的 POSIX 支持按 PSE51/PSE52/PSE53 子集组织，但运行在单进程模型下；FreeRTOS+POSIX 提供 pthread 线程、互斥量、条件变量、屏障、信号量、消息队列与时钟/定时器 API，并要求调度器已启动后才能调用线程 API、其头文件不能与工具链自带 POSIX 头文件混用；NuttX 以 POSIX/ANSI 为主导标准，提供 pthread、鲁棒互斥、命名消息队列与信号等更接近完整 POSIX 的接口。[S17][S19][S20] 见图 2，从 AP 应用到 RV32 硬件之间存在五道门禁，其中适配层与运行时是第一道可自行搭建的关卡。

图 2：AP 应用依赖链在 RV32 RTOS 上的落点与五道门禁（G1 多进程隔离与每进程虚拟地址空间、G2 ResourceGroup 限额、G3 C++ 线程与互斥支持、G4 信号与 SIGTERM 语义、G5 SOME/IP 服务发现与序列化裁剪）。来源为 R25-11 OSI 条款、Zephyr/FreeRTOS/NuttX 官方文档与 RV32 车规核公开规格归纳；门禁颜色表示缺失程度，红色项需要架构性改造而非补丁。[S01][S17][S19][S20][S22]

失效边界：PSE51 中与进程相关的语义在无进程模型的 RTOS 上不可等价：fork/exec、进程组、每进程资源计量都不存在；Linux 下依赖虚拟内存的 dlopen、写时复制语义无法复现；FreeRTOS+POSIX 的 POSIX 层与原生 API 不能混用，意味着第三方库若直接包含标准 pthread.h 需要改造；Zephyr 的单进程前提使“进程间隔离”的验证无对象可测。[S17][S19][S01]

验证条件：建立两组测试：其一为 PSE51 一致性用例（线程优先级与调度策略、互斥量健壮性与优先级继承、条件变量超时、信号异步投递、时钟单调性），在目标板上复现并记录每一项的通过/降级状态；其二为负例测试（越权内存访问是否被检测、线程崩溃是否影响系统、资源限额是否生效），用于判定 OSI 条款的满足程度。测试结果应形成“条款—状态—证据”对照表，而不是只统计通过率。

成本与权衡：自建适配层的直接成本是人力（约一个小组数月级，随 API 覆盖面线性增长，属【P】估算），隐性成本是与 RTOS 版本演进的持续对齐：RTOS 每次升级都可能改变调度、时钟或同步语义，适配层需要回归。收益则是不改应用侧 API，保留未来向完整 AP 迁移的可能。替代方案是直接采用 NuttX 内核态等内置 POSIX 较完整的 RTOS，用“绑定单一 RTOS”换取更薄的适配层。

5.2 C++17 运行时：库与语义的双重缺口

接口与实现依据：AP 要求 C++ 接口兼容 ISO 14882:2017（C++17）并以 MISRA C++:2023 约束编码。[S02] 在 RV32 RTOS 上，C++ 能力由工具链（libstdc++/libc++、newlib/picolibc）与 RTOS 共同决定：Zephyr 的官方文档明确默认 C++ 标准为 C++11，不支持静态全局对象析构，明确排除 std::thread 与 std::mutex 等依赖 OS 的标准库类，且限制 C++ 只用于应用层、内核与驱动不得使用。[S18]

失效边界：三类缺口需要分别对待：语言层（异常、RTTI、thread_local 在嵌入式工具链上的裁剪策略）、库层（std::thread/std::mutex/std::future 依赖 OS 线程与同步原语，必须桥接到 RTOS；std::filesystem 依赖文件系统）、运行时层（全局构造顺序、析构不执行导致资源不释放、new/delete 的堆行为与内存碎片）。若 AP 应用代码按 C++17 惯例使用异常与智能指针，而工具链以 -fno-exceptions 构建，则语义不一致会在运行期以静默失败形式暴露。[S02][S18]

验证条件：用 AP 教程级示例验证：ara::core 的 Future/Promise 完成路径、日志宏、静态初始化阶段 getenv() 的可用性（对应 SWS_OSI 的 C++ 环境要求）；对异常路径、全局析构、thread_local 各写一个观察用例；运行期统计堆使用峰值与碎片增长曲线。任何被裁剪的语言特性都要在验收清单中显式记录为偏差项。

成本与权衡：选择在于“换工具链”还是“改代码”。静态链接完整 libstdc++ 并保留异常/RTTI 会带来数百 KB 级体积增长（随选用特性浮动，属【P】估算），对 SRAM 百 KB—数 MB 级的 RV32 目标是显著开销；裁剪异常/RTTI 又要求应用代码与第三方库遵循同一约束，并与 MISRA C++ 的核查规则相容。这项权衡没有普适答案，必须在项目起点就与代码规范一起冻结。

5.3 多进程、隔离与资源组：与 RV32 现实的正面冲突

接口与实现依据：规范条款是明确的：多进程支持、进程间隔离（非法访存被检出）、每进程独立（虚拟）地址空间、可配置禁止创建进程、至少 8 组 ResourceGroup、内存与 CPU 限额（内存核算含页表项开销），调度策略覆盖 SCHED_OTHER/FIFO/RR。[S01] EM 侧，进程状态上报通过 ara::exec::ExecutionClient::ReportExecutionState 完成，终止配合 SIGTERM 语义。[S06] RV32 侧的现实是：车规核如 Nuclei NA300 以 PMP（物理内存保护）与安全特性为内存保护手段，[S22] RISC-V 特权规范中的 Sv32 页式虚拟内存依赖 MMU，[S29] 而 RVM23U32 这类 32 位微控制器 profile 草案仍在开发阶段。[S28]

失效边界：三条候选路径各有明确边界。其一，NuttX 内核态（KERNEL build）提供带 MMU 的任务/进程虚拟空间，最接近 AP 语义，但要求目标核具备 MMU——多数 RV32 车规核不具备；其二，PMP/MPU 分区（NuttX PROTECTED 模式或 RTOS 用户态）能提供区域级保护，但不提供每进程虚拟地址空间，SWS_OSI_01010 的“独立地址空间”“共享只读代码”等表述无法对应；其三，单地址空间逻辑隔离（Zephyr 单进程形态）实际上放弃了进程隔离条款，仅能作为 L1/L2 演示。[S01][S17][S20][S28][S29]

验证条件：对照 OSI 条款逐条判定“满足/降级/不满足”，对每条判定给出可复现实验：写越界测试（是否被 PMP/MPU 捕获并终止越权线程）、资源限额测试（内存与 CPU 配额生效性）、进程创建限制测试、SIGTERM 处理测试。任何标记为“降级”的条款都必须在安全论证中单独说明补偿措施，否则不应进入 L4 语境。

成本与权衡：补足隔离能力的成本曲线是陡峭的：在 PMP 基础上做软件隔离（能力表、系统调用门）属于自研内核级特性，其验证与认证代价远超业务功能开发；选择 MMU 路线则把问题推回芯片选型——需要 RV32 之外的内核方案。相对务实的取舍是接受“区域保护 + 逻辑隔离”的能力天花板，并把它写成架构约束，而不是在项目后期用测试补救。

5.4 通信与存储：绑定裁剪决定可用性上限

接口与实现依据：ara::com 允许多种绑定：SOME/IP 网络绑定、信号绑定、DDS 网络绑定与进程间通信，具体部署由服务实例清单决定；服务发现、序列化与代理代码通常由生成器产出。[S07] CAPI 提供代码生成器作为源码分发，[S08] Vector 侧由 DaVinci Developer Adaptive 生成 manifest 并调用 MICROSAR 生成器。[S13] 在 RV32 上，可用绑定取决于外设现实：具备以太网 MAC 的 SoC 才能谈 SOME/IP；只有 CAN 的目标需要信号绑定或自定义绑定；同 SoC 内部通信可用共享内存 + 事件机制的 IPC 绑定。

失效边界：SOME/IP 的服务发现依赖 UDP/TCP 栈与足够的 RAM 预算，序列化与代理生成本身依赖工具链对目标平台的支持；跨 SoC 通信还需要网络管理与时间同步集群配合，这在 RV32 上通常被裁剪，导致“单节点可用、整车不可见”。持久化侧，Persistency 需要文件系统或块设备语义与断电一致性保证：Zephyr 提供文件系统子系统、NuttX 提供 VFS，但两者都不能自动给出 AP 规范的键值/文件存储语义与更新事务保证。[S07][S20][S08]

验证条件：端到端测试两个应用经 ara::com 完成方法调用与事件订阅，覆盖断链重连、超时、乱序与序列化兼容性；持久化测试覆盖断电写入、空存储启动、版本迁移与损坏恢复；对每个被裁剪的集群，记录“未实现/降级实现”的行为差异，避免应用在真实场景中静默缺失能力。

成本与权衡：保留规范绑定（SOME/IP）意味着以太网栈、内存与工具链的三重投入，且生成器是否支持目标平台是关键外包约束；裁剪为 IPC/信号绑定显著降低资源开销，但把跨节点互操作问题留给网关，并使部分 AP 工具链产物（服务实例清单等）失去直接用途。资源消耗与规范一致性在这条线上直接对立，需要在架构阶段就明确“本节点是否需要被整车服务发现”。

5.5 认证与工具链：从“能跑”到“可交付”

接口与实现依据：可交付性不只取决于功能。安全侧要求目标 OS 具备安全手册、假设条件与认证证据：QNX OS for Safety 以 ASIL D/SIL3/IEC 62304 C 级认证作为产品事实，[S30] PikeOS 以 DAL A/SIL 4/ASIL D 预认证与 EAL5+ 分离内核作为卖点。[S31] 工具链侧要求编译器、链接器、生成器进入工具置信度论证（ISO 26262 第 8 部分要求的工具鉴定），并配合 MISRA C++:2023 的静态核查。[S02]

失效边界：开源 RTOS 的认证证据链是 RV32 路线的最大不确定项：公开安全页面多以社区安全活动与分析方法为主，未提供可直接复用的认证结论；即便未来有认证版本，其认证包（安全手册、配置假设）与具体芯片、编译器的绑定关系仍会限制可用范围。同理，自研适配层本身若参与安全相关功能，需要自己的安全论证，而这类“自研中间件 + 开源 OS”的组合论证成本通常被低估。

验证条件：把认证拆成可验收的前置条件清单：OS 安全手册是否可得、编译器是否已鉴定或有鉴定路径、静态分析规则集与偏差记录是否建立、每个 ASIL 目标的分解假设是否书面化。对 RV32+AP 子集路线，额外要求“规范偏差清单”经安全评审签字；清单之外的条款不允许口头解释。

成本与权衡：认证成本与“自研比例”正相关：改动越多，需要论证的代码与接口越多。因此工程上常见的取舍是尽量使用已有认证证据的组件（认证 OS、商用 CP 栈），把自研范围压缩到适配薄层，并接受由此带来的供应商绑定与授权成本；反向选择（全自研以保持自主）则需要以年为单位的安全工程投入，不属于短期项目可承受的范围。

6. 演进方向与情景

6.1 规范与生态的中期走向

规范侧，R25-11 把 AP 的 C++ 基线提升到 C++17 并要求以 MISRA C++:2023 约束关键系统代码，这意味着应用侧的语言特性使用面在扩大，而嵌入式工具链的 C++ 支持水平将成为 RV32 路线的持续制约。[S02] 实现侧，CAPI 1.0 把功能集群参考实现摆上桌面，官方定位为认证就绪的协作基座，其价值在于把“规范—实现—工具”之间的解释工作收敛到一份可读源码上。[S08][S09][S10]

RISC-V 车规侧，三条线索并行：其一，CPU IP 与芯片持续取得安全认证（Nuclei 的 ASIL-D 产品证书与 NA300 的 ASIL-B/D 能力标注、奕斯伟 EAM2011 的 ASIL-B 证书、DF30 的 ASIL-D 定位），补齐“芯片可信”一环；[S22][S23][S38][S39] 其二，平台与 profile 层开始出现（Quintauris RT-Europa 定位首个汽车实时 RISC-V 平台/profile，强调 PMP 机制与安全岛，profile 于 2025 年初发布、平台 2026 年 1 月起面向客户）；[S25][S26] 其三，商业栈开始接入（Vector 与 Quintauris 把 MICROSAR Classic 集成到 RT-Europa 参考架构，CES 2026 演示），[S15][S16] 而 Infineon 以 AURIX 品牌宣布汽车 RISC-V MCU 家族，但量产时间未在新闻中固定。[S27] 32 位微控制器 profile（RVM23U32）仍处开发阶段，未冻结。[S28]

这些线索共同的指向是：RISC-V 在汽车上的突破路径是“实时与安全控制”先行，而不是“高性能计算/AP 先行”。

6.2 三种情景路线

把 AP 搬到 RV32 RTOS 的努力，最终会收敛到三种可分辨的情景。见图 3，三者不是在“是否先进”上的排序，而是与不同目标匹配的不同工程形态。

图 3：三条路线的成熟度对比矩阵（路线 A 标准 AP 运行在 RV64 + Linux/QNX/PikeOS 或 CAPI 基座；路线 B AP 子集运行在 RV32 + RTOS + 自研适配层；路线 C CP 优先运行在 RV32 车规核 + AUTOSAR CP 安全 OS）。来源为 R25-11 规范条款、RTOS 官方文档、CAPI 与 Vector/Quintauris 公开信息归纳；为定性评估，不是测量分数或供应商排名。[S01][S03][S08][S15][S17][S20][S22]

需要强调的边界：情景 B 与“完整 AP”之间不是工作量差距而是架构差距。“进程模型 + MMU 语义”属于 AP 的前置假设，把它替换为线程模型与区域保护之后，产出物严格来说是“采用 AP 接口风格与部分功能集群的嵌入式中间件”，这一命名差异在对外表达与合同验收中必须保持如实。

6.3 关键观察信号

以下信号可在未来 12 个月内用于更新本报告的判断：RT-Europa 参考规范的开放程度与是否出现 AP 方向的 profile 扩展；是否有厂商公开 RV32 形态的 AP 子集案例与其验收口径；CAPI 是否增加非 Linux 宿主支持（尤其是 RTOS 或分离内核后端）；NuttX 等开源 RTOS 是否出现面向汽车安全的认证证据包；RVM23U32 是否冻结并获得芯片落地。[S25][S26][S08][S20][S28]

7. 建议与验收

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

第一，“跑通”的验收层次是什么（2.2 节的 L1–L4）？不同层次的工作量相差一个数量级，且 L4 在当前 RV32 硬件上不可达。第二，安全目标是什么？若产品需要 ASIL 等级的论证，认证证据链的选择比技术选型更早决定路径。第三，硬件约束是否真实？很多“必须 RV32”的约束来自既有选型惯性而非产品需求；如果 AP 是硬需求，放宽到带 MMU 的 64 位内核通常是总成本最低的方案。

7.2 路线选择建议

7.3 工作包与工程量估算

若选择情景 B（RV32 RTOS + AP 子集，目标 L2–L3），工作可拆为以下包。规模为【P】估算，取“一名有经验的嵌入式系统工程师”为基准单位，实际随团队既有资产浮动：

建议—验收矩阵

7.4 不建议的做法

不建议把 PMP/MPU 的“访问越界检测”宣传为满足 AP 的进程隔离条款；不建议在未完成工具链鉴定与 OS 证据收集前启动安全相关功能的开发；不建议以“先跑起来再补架构”的方式在 RV32 上追完整 AP 的功能清单——5.3 节说明其差距是架构性的，后期补课成本呈非线性上升；不建议把 CAPI 的存在理解为“有现成 RV32 版本可移植”，其 Linux/POSIX 基线仍是需要跨越的语义鸿沟。[S01][S08][S20]

8. 不确定性与研究限制

本次没有可用的 RV32 车规目标板，未进行 RTOS 移植、CAPI 构建或任何实测，因此所有“可行/不可行”判定都是规范与公开资料层面的，不能替代在真实硬件与工具链上的复现。工程量与体积数字均为【P】量级估算，未实测。

证据层面的主要限制：CAPI 的集群清单与 Linux 依赖来自官方页面与公开报道，仓库实操未验证；[S08][S09][S10] 国内厂商的适配进展来自厂商新闻与媒体报道，未逐一验证其为原型、样件还是量产状态，也未获得矩阵中“ASIL-D 级 MCU”等表述的证书细节；[S34][S37][S38][S39] RT-Europa 公开页面未给出明确 ASIL 等级与完整规范全文，其“首个”类表述为 Quintauris 自述；[S25][S26] Zephyr 的安全页面为社区活动介绍，未给出认证时间表，本报告因此只把“认证证据不足”作为判断，不预测其认证前景；[S17][S18] 规范条款以 R25-11 为截点，R26-11 及之后版本可能调整 OSI 要求；[S01] 未检索到不等于不存在，尤其国内厂商的 RV32+AP 实践可能存在于未公开项目中。[S34][S40][S41]

主张—证据矩阵

参考来源

以下链接均在 2026-09-29 访问核验（HTTP 200）。规范类来源为 AUTOSAR R25-11 官方文件；产品类来源为厂商官方页面或官方新闻。

附录：研究方法

研究分三步：先在 AUTOSAR 官网下载并抽取 R25-11 的 AP/CP 核心规范文本，逐条摘录与本主题相关的强制条款（OSI、EM、CM、CP OS、CP 分层架构）；再以官方文档核验 RTOS 的 POSIX 与 C++ 能力边界；最后用厂商官网与官方新闻核实产品谱系与 RISC-V 生态进展。所有网络材料以只读方式获取，未执行第三方仓库脚本，未安装生产依赖。

规范 PDF 经文本抽取后在本地检索（工具为标准库与 pypdf）；本报告中的条款编号均可在对应 PDF 中定位。图 1 至图 3 由 graphviz 依据上述材料自行绘制，不使用无出处的市场数据。

# 规范文本抽取（本地，只读）
python3 autosar-research/docs/extract.py docs/AUTOSAR_AP_SWS_OperatingSystemInterface.pdf
# 报告结构校验
python3 skills/document/scripts/validate_research_report.py autosar-riscv32-ap-research.md --profile technical-research

报告结构与本图由工作区文档工具校验；该校验只针对报告质量，不代表对任何产品或平台的实测结论。