1. 引言
AUTOSAR的主要目标是提高车辆软件组件的模块化、可扩展性和可重用性，以及促进不同系统和技术的集成。AUTOSAR组织的成员单位将包含自身IP的技术成果贡献进AUTOSAR标准，这已经在很大程度上避免了大家“重复造轮子”，一定程度上实现了缩短开发周期，提升软件质量，降低开发成本的目标[1]。同时，面对软件定义汽车对功能快速扩展和开发效率提升的迫切需求，AUTOSAR也开始尝试采用“代码优先”的创新模式开发AUTOSAR AP (Adaptive Platform)平台[2]。不过，对于AUTOSAR CP (Classic Platform)平台，当前行业内仍以Vector、ETAS、普华基础软件等提供的商业解决方案为主，同时，也有部分企业在尝试通过自研或开源的方式进行实现。
对于AUTOSAR CP平台软件的实现，目前行业最大的痛点有两个：
一是使用成本较高，无论采购商业软件还是自研，都需要大量的研发资金投入。同时各家所实现的软件相互不兼容，技术碎片化特征明显，经常需要重复购买，更加剧了这一问题。这个问题主要受AUTOSAR组织早期倡导的“在标准上合作，在实现上竞争”的商业模式的惯性影响。虽然从早期看有其合理性，但随着当前开源、降本的呼声越来越高，这一商业模式正面临严峻挑战。
二是技术迭代慢，相对行业需求存在一定程度的落后。面对越来越复杂的应用场景和功能越来越强大的多核异构处理器、中央/区域控制器，各家按照CP标准20年前即开始定义的架构、功能和方法论开发出的软件难以满足行业需求，这方面需求虽不如AP平台多，但也存在大量标准以外的新功能需要开发，同时开发工具链也亟待升级以提高开发效率。
Zephyr作为Linux基金会旗下新一代开源的实时操作系统平台，在IoT与边缘计算领域已验证其可靠性，具备向车规级演进的潜力。本文旨在初步分析“在Zephyr RTOS基础上构建兼容AUTOSAR CP的智能车控操作系统”的可行性、意义与价值，希望为解决以上行业痛点提供参考技术方案。
2. 为什么是Zephyr，而不是其他RTOS
Zephyr是一个由Linux基金会主导的开源、可扩展、安全且实时的嵌入式实时操作系统，专为资源受限的嵌入式系统和物联网设备设计。自2016年发布以来，Zephyr已迅速成长为全球主流的开源嵌入式操作系统之一，广泛应用于可穿戴设备、工业控制、医疗设备、智能家居、边缘计算以及新兴的汽车电子领域。
Zephyr绝不仅仅是“又一个开源RTOS罢了”，而是极有可能统一整个嵌入式RTOS世界。理由如下[3]：
(1) 极度活跃的社区。当其它实时操作系统项目停滞不前或出现下滑时，Zephyr的贡献者基数自2017年以来增长了7倍，在今年达到了平均每月344名活跃的开发者，1640次提交。如下图1所示。
Figure 1. The fast growth of Zephyr contributors
图1. 快速增长的Zephyr开发者及提交
(2) 真正的厂商中立性。与私有系统或由单一厂商主导的开源项目不同，Zephyr项目托管在Linux基金会旗下，目前有超过57家成员公司和组织参与协作，包括国内的openEuler社区，湖南大学，成都菁蓉联创公司等，而不受单一实体的限制和控制。Zephyr在开放源码的基础上，实现了透明开放的开发流程，以及开放中立的治理。这意味着参与者可以以“贡献越大，主导权越大”的方式引导它具备高质量和实用的功能集。
(3) 功能丰富，且高度可配置。Zephyr支持x86、ARM、RISC-V等几乎所有主流处理器架构，截至目前已经支持800多种开发板、200多种传感器，涵盖NXP、ST、Infineon、Renesas等众多厂商芯片。同时还提供RTOS内核以外的各种不同的通信协议栈、网络安全、文件系统、电源管理等丰富的基础软件功能。
(4) 重视信息安全与功能安全。Zephyr在开发时就考虑了功能安全与信息安全，信息安全方面具有独立的CVE编号和完善的治理框架，功能安全方面目前具备满足行业认证(如ISO 26262/IEC 61508)的技术条件。
(5) 现代化开发工具链。Zephyr不仅是一个操作系统，更是一套完整的嵌入式开发生态。如基于Cmake + Python的构建系统，使用Devicetree + Kconfig对软件进行配置，采用West作为元工具统一管理代码、构建、烧录与调试，测试框架内置Ztest单元测试、覆盖率分析、静态检查工具，并支持CI/CD和容器化开发。
(6) 对产品开发友好。Zephyr项目整体采用对商业友好的Apache 2.0许可证，同时每两年一个长期支持版本(LTS, Long Time Support)，每个LTS版本的社区维护周期为五年，可以高效地支持产品级的开发。
3. Zephyr + AUTOSAR CP中间件 = 面向MCU的新一代汽车电子基础软件平台
复杂软件系统的开发如同做一桌大餐，丰富多样的食材、专业的烹饪工具和熟练的制作方法三者缺一不可，如下图2所示。车载软件的开发也不例外，要想做出好的汽车软件，需要在软件功能模块、开发工具链和开发方法论三个方面持续精进。
Figure 2. The composition of automotive software
图2. 汽车软件领域三大内容
Zephyr的快速发展和AUTOSAR CP软件的开源化，使得汽车基础软件平台围绕以上三个方面的精进有了更具体的目标。
3.1. 汇聚IoT和汽车两大边缘计算领域平台功能，实现技术领先
3.1.1. Zephyr提供丰富多样且极具特色的功能(但“汽车味”不够)
Zephyr并非通用操作系统，而是专为MCU应用设计的轻量级、硬实时、高安全RTOS，同时通过模块化设计兼顾功能完整性。其参考架构图如下图3所示。
(1) 全面的内核服务。Zephyr提供了一系列开发者熟悉的内核服务，如多线程服务、中断服务、线程间数据传递与同步服务、内存分配服务、电源管理服务等。同时支持协作式与抢占式、时间片轮转、最早截止时间优先等多种调度算法。另外，还支持大量不同的CPU架构和具体芯片型号。虽然不符合AUTOSAR所定义的OS标准，但可以通过将线程(Thread)封装为AUTOSAR任务(Task)的方式，实现与AUTOSAR软件的兼容。
(2) 提供内存保护机制。Zephyr实现了可配置的针对特定架构的栈溢出保护、内核对象与设备驱动权限追踪，以及在线程级内存保护下的线程隔离机制。其内存保护机制主要依赖硬件上MMU、MPU和堆栈指针保护机制。
Figure 3. The architecture of Zephyr
图3. Zephyr操作系统架构
(3) 丰富的底层OS基础功能服务[4]。Zephyr不仅仅是一个RTOS内核，还提供了类似AUTOSAR Memory技术栈的存储服务，类似AUTOSAR MCAL和CDD的各种外设及复杂驱动，信息安全技术栈，核间通信，符合SOA思想的ZBus机制，软件远程更新，以及基于Zephyr的嵌入式实时虚拟机ZVM (Zephyr-Based Virtual Machine)。
(4) 提供支持多种协议的原生以太网技术栈。以太网通信支持功能完整且经过优化，包含LwM2M协议及符合BSD套接字标准的支持。同时提供对OpenThread的支持。这一特性有利于车载以太网通信功能的开发。
(5) 高效的跟踪与调试功能。Zephyr内置高级日志记录框架和跟踪框架，支持UART、网络、文件系统等多种后端，配合外部工具可实现内核及其各子系统内部运行状态的可视化，如下图4所示，以较低的成本即可提升开发效率。
Figure 4. Percepio’s graphical tool base on Zephyr trace
图4. Percepio公司基于Zephyr Trace功能图形化分析工具
除以上外，Zephyr还正在探索Rust语言集成、机器学习、大模型轻量化与本地部署等新兴技术领域。
当然，需要注意Zephyr所提供的汽车基础软件领域相关标准要求的功能还很少，如诊断协议栈、网络管理、CAN/LIN/Flexray通信协议栈，不能兼容AUTOCAR CP等，尚不足以支撑汽车领域特别是车控领域的广泛应用。
3.1.2. AUTOSAR CP标准定义了丰富的车用基础软件(但“完整性”不够)
相比上世纪90年代欧洲汽车行业所定义的OSEK标准，AUTOSAR标准为汽车ECU定义了更为完整的基础软件功能。在OSEK已定义的操作系统、通信和网络管理三部分标准的基础上，通过横向分层、纵向分技术栈的架构设计，对约100个模块的实现进行了标准化，如下图中橙色背景的OS、Com、NvM等软件模块。极大地提高了车辆软件组件的模块化、可扩展性和可重用性，并促进了不同系统和技术的集成。如图5所示。
Figure 5. The evolution of automotive system software
图5. 汽车电子基础软件行业标准的演变
然而，这种完整性是相对的。一方面，由于所定义的基础软件模块是各家会员单位具有普遍共识的部分，而对于缺乏共识，尤其是自己的“独门秘籍”，各家其实都“留有后手”，如复杂驱动。具体可参考《汽车基础软件漫谈|2. 汽车基础软件的定义》[5]一文中的介绍。另一方面，随着汽车智能网联化的快速发展，产生了FOTA、Hypervisor等大量新的需求，而AUTOSAR标准难以及时将这些新需求标准化。因此，这也就造成当前还有大量的基础软件模块并没有被标准化，如图6中灰色背景的软件模块。
Figure 6. The landscape of AUTOSAR CP
图6. AUTOSAR CP全景图
不过，从上一节中的分析不难看出，Zephyr恰好可以大量补充这些未标准化的基础软件模块。如各种硬件驱动、核间通信IPC，软总线ZBus，软件远程更新OTA，以及虚拟化功能等。
3.2. Zephyr提供完整的“现代化嵌入式开发”工具链体系，大幅提升开发效率
3.2.1. 统一的构建系统：Cmake + Python + West
Zephyr的构建系统可以形象地概括为“CMake为骨，Python为皮”。凭借跨平台、易扩展、驾驭复杂项目结构的先天优势，CMake早已成为众多顶级开源工程的“基建”——从人工智能(TensorFlow)到计算机视觉(OpenCV)，从桌面框架(Qt)到机器人操作系统(ROS)，几乎无处不在。
Zephyr在此基础上搭起了一套功能强悍却细节繁复的构建框架。为了不让普通开发者直面CMake的“钢筋水泥”，Zephyr用Python包裹出一层简洁的外壳：元工具west一键完成代码拉取、编译、烧录、调试；配套Python脚本则进一步补位，接管设备树解析、测试调度等杂务。骨子交给CMake，面子留给Python，Zephyr就这样把“强大”与“友好”一并交到了开发者手里。
3.2.2. 高效的软件配置机制：Kconfig + Devicetree + Yaml
Zephyr 自诞生起就以“把Linux验证过的成功范式搬到RTOS世界”为己任，其中最具代表性的两张王牌便是Kconfig与DeviceTree——在实时操作系统里首次做到“全套照搬、完整落地”。
Kconfig把Linux内核“千刀万剐”式的可裁剪能力原封不动搬进Zephyr：只要一行prj.conf，驱动、协议栈、调试特性均可按需开关，真正做到“一样源码，千般身材”。这一方案与Bosch在其经典的Motronic系列发动机控制器中所使用的“系统常数”机制非常类似。
DeviceTree则让“板级细节”彻底告别硬编码。Zephyr的DT语法与Linux保持兼容，却玩出了RTOS独有的“静态化”花样：不再由bootloader动态解析臃肿的DTB，而是借助Python脚本在编译阶段直接把设备树翻译成C宏 + 初始化代码，既省资源又省启动时间——思路与AUTOSAR的ARXML异曲同工，却胜在肉眼可读、版本可控。
光有这两件利器还不够，Zephyr又把YAML拉进战场：仓库清单、应用摘要、测试向量一切皆可YAML化，让“配置”成为一等公民。
通过Kconfig、Devicetree、Yaml配置文件等一系列措施，Zephyr实现了相当高程度的代码、配置可复用性，典型的结果就是在Zephyr中基于已有的硬件上去增加类似但又有不同的硬件支持会非常高效率，这也是Zephyr中自带的硬件开发板支持快速增加的根本原因。
3.2.3. 强大的调试、测试与优化基础设施
Zephyr所提供的工具链犹如一把瑞士军刀，除了提供软件配置与构建工具外，还提供了大量实用、先进的现代化开发工具。以下挑选其中部分工具进行介绍。
(1) QEMU模拟器。Zephyr为ARM，RISC-V等各种不同的CPU架构提供了QEMU模拟器，使得开发者可以在PC环境下，无需开发板即可对软件进行调试。同时为了进一步提高开发效率，Zephyr还是在支持PC环境下原生运行(Native Support)，也即Zephyr应用作为一个Linux进程运行，可以访问网络、可以和蓝牙模拟程序、I/O模拟程序，乃至Matlab连接，同时可以比QEMU模拟器更快的仿真速度。
Figure 7. The TraceCompass tool for Zephyr
图7. Zephyr中的TraceCompass工具
(2) Twister测试运行器。它是Zephyr开发流程中至关重要的一环，专门用于管理和执行大规模、跨平台的编译与测试。可以将其理解为Zephyr的专属持续集成和测试框架。它的核心任务是自动化地验证Zephyr代码库的正确性。考虑到Zephyr支持超过800多块开发板和多种架构(x86、ARM、RISC-V等)，手动测试所有组合显然是不现实的，Twister正是为了解决这一难题而生。
(3) 静态代码分析。Zephyr支持Coverity、Parasoft C/C++ test、Polyspace、CodeChecker等近10种原生静态代码分析工具，开发者仅需将自己所使用的工具配置到Cmake中即可。
(4) TraceCompass跟踪调试器。一款由爱立信开发的开源工具，能够可视化线程调度与中断等并发时序事件，有助于在复杂系统中发现非预期的交互行为与资源冲突。下图展示了其部分效果，如图7所示。
3.3. 关键开发方法：信息安全能力强，功能安全有基础
在软件定义汽车和智能网联时代，功能安全是底线，信息安全是防线。二者均强调系统性、全生命周期、基于风险的开发流程，共同构成智能汽车可信运行的“双轮驱动”，是车企技术竞争力、合规准入和用户信任的核心保障。那Zephyr在这两个方面有哪些特点，是否能满足汽车行业的高要求呢？
3.3.1. 信息安全能力
Zephyr的信息安全旨在保护设备在联网环境下的数据机密性、完整性和可用性，防止恶意攻击。具有以下核心安全特性与机制。
安全的启动链与代码完整性
MCUboot：Zephyr官方推荐并深度集成MCUboot作为安全启动引导程序。它通过数字签名验证固件镜像的完整性和真实性，防止运行被篡改的代码。
硬件信任根：支持利用芯片内的安全硬件(如TrustZone、TPM、HSM)来安全存储密钥和进行加密操作。
加密套件与安全协议
丰富的加密库：内置了稳健的加密算法库，包括AES (加密)、SHA (哈希)、RSA/ECC (非对称加密)等，并支持硬件加速。
完整的网络安全协议栈：原生支持TLS/DTLS (用于安全通信)，并集成了流行的库如Mbed TLS。
安全的更新机制
通过MCUboot实现安全、可靠的固件空中升级。支持A/B分区，确保更新失败后能回滚到旧版本，保障设备可用性。
内核级安全功能
内存保护单元支持：当硬件支持MPU或者MMU时，Zephyr可以配置内存区域的访问权限(只读、只执行等)，防止用户态应用程序破坏内核或其他应用的内存。
栈溢出保护：内置栈保护机制(如栈边界检查)，可以有效缓解栈溢出攻击。
线程隔离：支持将线程限制在其专属的内存域中，限制其可访问的资源，实现权限分离。
信息安全审计与漏洞管理
Zephyr项目有一个活跃的信息安全委员会，负责接收、评估和披露安全漏洞。
拥有明确的漏洞报告流程，并定期发布安全公告。
代码库会接受持续的安全审查和静态代码分析(例如，使用Coverity Scan)。
总之，信息安全是Zephyr的“核心优势”，其已经具备了工业级应用所需的安全能力。车载软件在很大程度上可以复用，而无需重新开发。
3.3.2. 功能安全能力
功能安全关注的是系统在发生故障或操作失误时，能避免引发人身伤害、设备损坏或环境危害等风险。Zephyr的目标是满足国际功能安全标准。其核心特性与进展如下：
功能安全认证准备
Zephyr项目已通过IEC 61508 (通用功能安全标准) SIL 3的概念批准(Concept Approval)。正积极推进IEC 61508 SIL3的正式认证，同时准备ISO 26262 ASIL-D认证，以满足汽车电子等高安全等级应用需求。
项目正在为此进行系统性准备，包括建立完善的开发流程、文档和验证体系。
高可靠性内核设计
确定性行为：作为RTOS，Zephyr具有确定性的线程调度和中断响应时间，这对于安全关键型应用至关重要。
错误处理：内核包含多种运行时错误检测机制，如断言检查、空指针解引用检测等，能及时报告系统异常。
测试与验证
强大的测试框架：如前所述的Twister工具，用于进行大规模、自动化的回归测试，确保代码更改不会引入新的缺陷。
高测试覆盖率：项目对内核和关键模块有极高的代码覆盖率要求，并通过测试用例库和模拟器(如QEMU)持续执行。
静态代码分析：强制使用静态分析工具，在代码合并前发现潜在缺陷。
详细的文档与可追溯性：
功能安全认证要求严格的流程。Zephyr项目正在完善其设计文档、需求规格说明和测试计划，确保开发过程的可追溯性。
总之，功能安全是Zephyr的“战略方向”，它正在系统性地为未来的国际安全认证做准备，虽然目前还不是一个现成的已认证操作系统。
4. 总结
Figure 8. The reference software platform combined Zephyr and AUTOSAR CP
图8. 整合Zephyr RTOS和AUTOSAR CP中间件的车控操作系统平台
伴随着普华开源小满、理想星环OS等开源汽车操作系统的出现，以Zephyr项目为基础，在其丰富多样的基础功能、高效现代化的工具链体系和快速提升的安全性的基础上，将开源汽车操作系统中相关软件模块与其整合在一起，如图8所示，从而打造一个开放、领先、安全、高效的开源智能车控操作系统的可能性正逐渐增大。尤其是当考虑到Zephyr正在以每月近2000次的提交速度高速成长时，更让我们对未来充满期待。