杨波涛 - 从域融合Hypervisor出发思考汽车操作系统技术路线和发展策略V1.2

1 . al ti en 从域融合&Hypervisor出发思考 id nf 汽车操作系统的技术路线和发展策略 Co 中瓴智行 2023-03 rt ma gs in Zl 

2 .目录 al ti 目录 01 en 域融合现状与趋势 id CONTENTS nf 02 汽车操作系统的技术路线 Co rt 03 汽车操作系统的发展策略 ma gs in Zl 2 

3 .智能网联汽车电子电气架构正加速向域融合方向演进 al ti 分布式架构 域控制器架构 中央计算架构 en id nf Co 智能汽车 分布式 域控制器（DCU） 中央计算（CCU） Cluster、IVI、中控、网关、T-Box、 座舱域控、车身域控、辅助驾驶、 ECU 行车记录仪、车身控制、辅助驾驶等 1个HPC和多个Zone控制器 rt 中央网关等典型域控制器 10+个ECU 传感器 要的冗余传感器越多 ma 每个ECU单独传感器，功能越多，需 传感器连接域控制器，可复用大部 分传感器 传感器连接到HPC或Zone控制 器，所有业务功能通过服务访问 gs 整车线束 >6km 3~5km <1km 骨干网络 CAN CAN/Ethernet Ethernet in 通信方式 信号 信号或服务 服务 Zl 3 

4 .智能网联汽车是复杂网络系统和多网络节点的电子电气架构 al 应用1 平台 应用2 ti en L1：车外通信 V2X 4G/5G WiFi/BT 网络层 id L2：车内网关 Gateway 边缘网关 nf Co L3：车内局域网 局域网1 局域网2 Telematics DCU ADAS DCU Body DCU PowerTrain DCU ... 感知 感知 rt L4：车内ECU Display APA Doors BMS Camera ma DVR Lights ... 控制 控制 gs 空调 ... ... 视频线 以太网 CAN总线 LIN总线 互联网 工业互联网参考模型 in Zl 不同网络节点业务需求具有差异性，需要多个不同类型的操作系统来达成业务目标 4 

5 .智能网联汽车需多类型操作系统满足差异化的业务需求 al ti 车用操作系统 en 车控操作系统 车载操作系统 安全车控操作系统 智能驾驶操作系统 id 来源：《车用操作系统标准体系》 nf Co rt ma gs in Zl 来源：《车载智能计算基础平台SOA软件架构白皮书》 5 

6 .智能网联汽车域融合趋势下的多操作系统架构 al n 汽车EEA四种典型多系统架构 技 术路 线 功能 安 全 系 统 性能 实时性 软 件 平台 化 配 置 灵活 性 系 统 成本 ti ü 硬件分离（不同SoC） 硬 件分 离 高 高 高 中 低 高 ü 硬件隔离（相同SoC、不同硬件资源） 硬 件隔 离 高 中 高 中 中 中 en ü 硬件虚拟化（Hypervisor） H y p er vi s or 高 高 高 高 高 中 id 容器 低 高 低 高 高 低 ü 软件虚拟化（容器） n Hypervisor既有硬件分离和硬件隔离方案的安全性、系统性能和实时性优点，也具有容器方案的平台 nf 化、灵活配置和低成本特征 Co Apps Apps Apps Apps Apps Apps rt Apps Apps Apps Framework Framework Framework Framework Framework Framework Apps Apps Apps Framework Framework Framework OS1 OS2 OS3 OS1 OS2 OS3 Framework Framework Framework OS1 SoC1 OS2 SoC2 OS3 SoC3 maAMP Single SoC VCPU1 VCPU2 VCPU3 VCPU4 VCPU5 VCP6 Hypervisor Container Host OS gs GPU CPU GPU CPU CPU IO GPU1 CPU1 GPU2 CPU2 CPU3 IO3 Single SoC Single SoC in DSP IO NPU IO DSP IO1 NPU IO2 CPUs GPUs DSP NPU IOs CPUs GPUs DSP NPU IOs DCU/HPC DCU/HPC DCU/HPC DCU/HPC Zl 硬件分离 硬件隔离 硬件虚拟化 软件虚拟化 6 

7 .四种多系统架构短期并存，随MPU/MCU芯片的发展 Hypervisor会成为汽车域融合架构中最基础的底座 al 软件虚拟化：容器 ti 硬件分离：异构核 或独立MCU Apps Apps Apps Apps Apps en Framework Framework Framework Framework Framework FSM： Hypervisor FSM HM& id Container VMM OS1 OS2 OS3 OS4 nf VCPU1 VCPU2 VCPU1 VCPU1 VCPU2 VCPU3 VCPU4 VCPU5 VCPU6 VCPU7 Hypervisor Hypervisor Hypervisor Co Single SoC MCU IO1 CPU1 GPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 NPU1 IO2 GPU2 NPU2 IO3 rt DCU/HPC 硬件隔离：AMP ma 硬件虚拟化：Hypervisor gs 1. 资源占用轻量化（ROM/RAM） 4. MCU的支持 in 关键需求 2. ISO 26262 ASIL D 5. 多类型和多数量的虚拟机支持 Zl 3. 跨SOC/CPU/VM的快速IPC机制 6. 硬件设备的软件抽象 7 

8 .国内外主要Hypervisor方案和应用情况 al 《中国汽车基础软件白皮书V3.0》 ti en id nf Co rt ma gs in 国外案例：QNX Hypervisor 国内案例：RAITE Hypervisor Zl （高通/瑞萨/芯驰/...） （MTK/NXP/瑞萨/瑞芯微/芯驰/...） 8 

9 .目录 al ti 目录 01 en 域融合现状与趋势 id CONTENTS nf 02 汽车操作系统的技术路线 Co rt 03 汽车操作系统的发展策略 ma gs in Zl 9 

10 .汽车操作系统特性趋势 – 智能化、网联化 al n ICT技术发展使能一分多(域融合、复合型设备)、多合一(网联化)，需要功能更强大的操作系统支撑业务场景； ti n 虚拟化是实现一分多的首选支撑技术； n 短期看，多合一可在现有多种异构OS上演进SOA平台实现融合；长期看，原生服务化、可扩展、统一架构规范的全场 en 景泛在操作系统更有优势； id TSP服务 生态服务 IOT服务 nf OS & SOA平台 Co 智能汽车 车 座舱娱乐服务 仪 自动驾驶服务 云 智能手机 表 rt 一 OS & SOA平台 OS & SOA平台 车机融合服务 盘 体 OS &SOA平台 域融合 TV Pad 手表 ma万物融合 底盘服务 Hypervisor 多域 车身服务 gs 协同 OS & SOA平台 OS & SOA平台 in Ø 智能化：单设备既可完成自有特色功能，也可以软件定义成复合型设备，完成原先多个设备的功能； Zl Ø 网联化：多设备通过SOA实现算力、外设、数据、服务、应用融合，相互赋能、各展所长，实现超能系统、最佳体验； 10 

11 .汽车操作系统特性趋势 – 安全、可靠 al n 智能化、网联化打破了传统安全边界，对安全性、可靠性带来全新、持续挑战 ti n 安全、可靠、实时的操作系统是智能网联汽车的根基； n 安全可靠的设计实现方法、解决方案会成为高度智能化、网联化时代的核心竞争力； en 智能座舱 id nf 智能网关 仪表/HUD APP IVI APP Co SOA中间件 SOA中间件 TSP/智慧交通云 实时OS 实时OS Hypervisor rt 车路云互联APP 车身互联APP V2X信息 ma SOA中间件 实时OS SOA中间件 实时OS 智能驾驶 gs Hypervisor 感知融合 规划决策 控制执行 RTOS in 传感/执行 SOA中间件 SOA中间件 SOA中间件 SWCs 实时OS 实时OS 实时OS Zl Classical AUTOSAR Hypervisor 

12 .微内核架构理念符合操作系统发展趋势，原生满足智能、网 联、安全可靠发展需求 al ti en 安全 需求趋势 智能 网联 id 可靠 nf Co rt 微内核架 构优势 模块/ ma 服务 分布 伸缩 更安 强实 轻量 更可 可扩 标准 化 式 性 全 时 化 靠 展性 gs 化 in Zl 12 

13 .典型OS架构对比分析 al OS架构 特权模式 内核 驱动 应用 服务化扩展 访问控制 安全开发/认证 ti 地址空间不隔 与内核同地址 代码量小，方便认 通常不区分， 通常为平板式内 离，相互影响。 传统RTOS 空间，直接调 无 无 证。但应用/驱动 en 安全性差 核 可利用MPU实 用，相互影响 集成后使认证无效。 现空间隔离。 id 主体处于内核 宏内核以特权 应用与内核分 中，驱动的不 分散开源开发，难 模式运行其整 系统功能集中于 离、应用与应 标准Linux无。 DAC、MAC、 nf 稳定影响内核 以遵循安全流程。 宏内核OS 个代码， 增加 内核，庞杂、攻 用分离，系统 Android扩展了 RBAC、 安全。 难以做到高等级安 了发生灾难的 击面大 调用较多，有 部分机制。 ABAC Co Android有重 全。未达到ASIL-B。 概率。 安全威胁 构改进。 最小化原则，只 应用与内核分 原生架构支持 充分利用硬件 主体处于内核 基于能力的 符合ASIL-D最高等 rt 保留最基本功能、 离、应用与应 服务化及安全 特权级别 外，相互独立， 访问控制， 级开发流程认证、 微内核OS 早小机制。信任 用分离，基于 调用，FC、本 (EL0~EL3)，安 稳定性、安全 类零信任安 产品认证，可形式 全管控完整。 全。 ma 基小，可证明安 性好。 安全管控的IPC 调用 地IPC、远程 IPC自适应。 全机制。 化证明。 gs in n 微内核的最小化原则、最小权限原则决定其原生适用于高信息安全、高功能安全系统； n 微内核的服务化架构决定其原生支持智能化、网联化； Zl 13 

14 .目录 al ti 目录 01 en 域融合现状与趋势 id CONTENTS nf 02 汽车操作系统的技术路线 Co rt 03 汽车操作系统的发展策略 ma gs in Zl 14 

15 . 开放 ≠ 开源，开源 ≠ 自由、免费 al ti BSD 宽松型 en 开放 Apache MIT 开源许 id GPL 可 nf 著作权型 LGPL 开放数 开放源 MPL Co 据 码 地图数据、全 源码可公开查看， 球森林数据等 需要遵循开源合 软件市场模式 AOSP+GMS 规要求 rt 专业服务模式 Redhat 售卖开源软件 BSD Unix ma 商务模 延迟开源模式 QT 开放标 gs 带动产品售卖 芯片SDK 准 式 认证和培训 in P O S I X 、 A U TO S A R 、 Android HAL等 悬赏、众筹、捐赠等 Zl 品牌效应 15 

16 . 汽车操作系统应具备开放性，兼容应用、中间件、硬件等生 态，支持上下游供应商的重塑 al 编号 开放模式 模式说明 ti 1 架构、接口、组件全封闭 需求方与供应商约定产品功能、性能指标等 en 开 2 架构、接口开放标准，组件封闭 架构和接口依据行业、客户、技术标准，如POSIX、ARINC653、AUTOSAR等 放 id 性 3 架构、接口开放标准，部分组件开放源码 Ø 标准化、开放的产品架构和接口 nf Ø 多供应商产品组件可组合、可对接、可替换，保证生态兼容，供应链灵活 性、持续性 Co 4 架构、接口、组件全部开放源码 开源开放指源代码可见，授权协议约束使用方式 rt 自主 ma 可扩 生态 gs 可靠性 安全性 ... 可控 展性 伙伴 in Zl 16 

17 .汽车操作系统供应商与芯片供应商、第三方组件厂商，以及 汽车主机厂形成生态联盟式的合作模式 al 编号 生态模式 模式说明 OS类型 ti Ø 架构和应用编程接口标准化，向上开放给应用软件开发者 PC时代 - en 1 Ø Windows重点支持Intel/AMD的X86架构，其它芯片生态难以兼容 标准化操作系统 Wintel联盟 Ø 应用生态因标准化而繁荣，芯片生态封闭 id Ø 架构和应用编程接口标准化，向上开放给应用软件开发者 Ø 内部系统组件（AOSP）开源，支持系统深度定制，发布ROM型 nf 智能数码时 OS 2 定制型操作系统 代 - AA联盟 Ø HAL等组件接口标准化，芯片和硬件厂商遵循标准可闭源提供 Co Ø 系统软件因开源而产生特色化的ROM型OS，应用和芯片生态因标 准化而繁荣 ？？ OS 芯片 rt n 芯片特征 Ø 架构异构：CPU、MCU、GPU、NPU、DSP等 ？ 供应商重塑：传统芯片供应商、新势力、跨界供应商 智能汽车时 ma Ø n OS特征 需求差异性：安全车控OS（实时、安全、可靠）、智能驾驶OS gs 4 代 - 生态联 泛在操作系统 Ø （安全、可靠、高计算性能）、车载OS（人机交互、高性能） 盟 供应商重塑：传统OS供应商、新势力（如RAITE OS） in Ø 服务组件 服务组件 n Ø SOA框架：跨芯片架构、跨网络的SOA服务架构 Zl Ø 中间件：算法、功能组件等与SOA的集成 

18 . al ti 谢 谢！ en id nf Co rt http://www.zlingsmart.com/ ma gs in Zl