4019
作者 / 阿宝，出品 / 阿宝1990
一、整体软件架构
汽车电子电气架构正在由传统的分布式架构向域集中式和中央集中式演进， 并继续演进至车路云一体化协同。智能网联汽车整体软件架构需要采用 SOA 分层思路构建， 从下往上，分为系统软件层、 功能软件层、 应用软件层， 以及云平台。其中， 系统软件与功能软件构成了广义上的操作系统（本文中， 没有特别强调说明的“操作系统”， 均指广义操作系统。如下图 智能网联汽车软件架构中红色线框内所示） ， 是汽车软件的基础。
此外， 汽车软件一般要配合专业的硬件平台来运行， 硬件平台为基于高性能芯片搭建的异构分布式硬件运行环境， 具有选型灵活、 配置可插扩、 算力可堆砌等特点。
智能网联汽车软件架构
系统软件是针对汽车场景定制的复杂大规模嵌入式系统运行环境， 不仅为上层应用以及功能的实现提供了高效、 稳定环境的支持， 也是各类应用调度底层硬件资源的“桥梁”， 在智能汽车整体软硬件架构中处于核心的位置。主要包含虚拟化管理与 BSP（板级支持包） 、 操作系统内核（如：OSEK、 RTOS、 Linux、 Android Q） 、 基础中间件三层， 进一步细化可分为异构分布系统的多内核设计及优化、 虚拟化管理（如 Hypervisor） 、 POSIX（可移植操作系统接口） 、 系统中间件及服务（如 AUTOSAR、 DDS）等。
功能软件是根据面向服务的架构设计理念， 通过提取智能网联汽车核心共性需求， 形成各共性服务功能模块， 高效实现智能网联功能开发的软件模块。主要包括数据抽象、 通用框架、 通用模型、 API， 以及安全域基础应用和管理平面。
应用软件运行在操作系统之上， 具体负责功能实现。即为实现具体自动驾驶功能、 HMI（人机界面） 交互等算法软件， 基于下层基础服务实现对整车服务、 应用、 体验等进行定义和组合增强， 构建差异化竞争力的应用。应用算法差异化涵盖了智能座舱（车载信息娱乐系统 IVI、 车联网、 人机交互、 中控系统、 ADAS、 智能座椅等） 、 智能驾驶（L1-L5 级智能驾驶等级） 等领域。同时伴随着云端软件复杂性的提高， 车载网络信息安全（检测与防卫远程攻击） 也将逐步成为未来应用算法的关注焦点。
云平台是独立与车端之外， 可以在云端部署， 并与车端互联互通， 提供计算、 互联等服务的远程服务平台。在新一代汽车的 SOA 架构下， 越来越多的应用层接入云端， 使得车载网络在以前独立的电子领域（例如信息娱乐、 ADAS 和动力总成） 之间建立连接。云服务平台包含大数据服务、 远程诊断、 应用商店、 驾驶服务等。
此外， 汽车软件整体架构在设计和开发过程中， 还需要关注安全要求， 以及配套工具链。安全体系自底向上贯穿硬件、 系统软件、 功能软件和应用软件等各个层级， 需要关注的安全要求有功能安全、 信息安全、 预期功能安全， 防护的层次主要有三个， 分别是车路云一体安全防控、 整车级安全防控、 零部件级安全防控。软件的配套工具链包括系统设计工具、 软件配置工具、 系统集成工具和开发、 调试、 测试工具等。
当前， 车端软件架构 SOA 化主要集中在智驾、 座舱、 车身功能域， 动力和底盘域受限于实际需求、 时延和可靠性要求以及其他非技术原因， 暂时还未实现 SOA 化。但未来， 随着EEA 向 HPC 中央计算平台的进一步演进， 车端各功能域软件也会逐步实现完全 SOA 化。
各大整车企业和供应商提出的新一代软件架构中， 均采用了 SOA 设计思想， 提出分层解耦开发目标。从底层的内核与基础中间件， 到框架支撑层的功能软件， 再到上层应用软件，明确了各层之间的向下依赖关系， 各层之间通过规范化的 API 进行交互， 实现了不同层次间的分离与解耦。
汽车软件整体架构中， 操作系统（OS） 是基础支撑。不同功能域对于操作系统的要求也不同。比如传统的动力和底盘域， 仍然是高实时性高确定性的嵌入式 OS（如 OSEK/VDX OS），通常和经典 AUTOSAR 平台绑定在一起。在智能座舱领域， 以车端 Android 操作系统为主，通过 SOA 网关实现自身服务和外部功能域之间的服务化交互。在智驾域， 满足高功能安全和高性能要求的实时操作系统 RTOS 被广泛应用（如 BlackBerry QNX， 中兴 ZEOS 等） ， 同时为满足机器学习和视觉 AI 算法的 OS 层接口要求， 安全 Linux 操作系统也需要引入， 比如和RTOS 一起构筑软件功能安全岛， 支撑 AI 算法丰富接口要求的同时， 满足智驾要求的功能安全等级， 如下图所示。
智驾域控制器软件架构示意图
汽车软件 SOA 新架构中均引入了自适应 AUTOSAR（Adaptive AUTOSAR） 平台， 用于满足一定的代码规范性和功能安全的目标， 同时也是借助于 Adaptive AUTOSAR 平台自身SOA 架构完成软件系统设计与开发。Adaptive AUTOSAR 经过五年左右的发展， 目前推出了R21-11 最新规范（如下图所示）， 国内外 AUTOSAR 厂商均在规划对齐最新规范进行各自 Adaptive AUTOSAR 产品的完善。总体而言， Adaptive AUTOSAR 平台面临的场景更加多样化， 相应的处理逻辑更加复杂多样， 功能范围更加宽泛， 即使是目前 Adaptive AUTOSAR 最新的规范也不能完全满足应用软件的需要， 需要在此基础上做进一步的扩展和完善。在国内， 中国智能网联汽车产业创新联盟基础软件工作组和中国汽车基础软件生态委员会（AUTOSEMO）等组织正在致力于推进相关标准化工作。
Adaptive AUTOSAR R21-11 规范框架
在汽车软件 SOA 架构中， 通过针对不同设备的抽象和适配， 对外发布原子服务， 实现设备和软件平台之间的解耦。在此基础上进一步定义组合服务、 应用服务以及动态服务， 实现服务的完全共享和重用。当前， 中国汽车工程学会、 汽车工业协会等组织在积极推进感知设备、 执行机构、 车身传感器及执行器、 热管理系统的设备抽象和原子服务定义， 具体落地实现还需要一个较长时期的过程。
此外， 软件 SOA 架构中各服务和应用模块之间的通讯， 当前应用层协议主要还是SOME/IP 及其关联的服务发现（SD） 。目前 Classic AUTOSAR 和 Adaptive AUTOSAR 都已经支持了 SOME/IP 协议栈， 同时在 Adaptive AUTOSAR 平台中还提供了 S2S 服务， 实现服务和信号的相互转换， 支持面向服务功能模块和面向信号模块之间的消息互通。当前， 以数据为中心的 DDS 协议虽然已经纳入 Adaptive AUTOSAR， 但目前对 DDS 的支持还很少。另外， 用于车云通讯的 MQTT（Message Queuing Telemetry Transport， 消息队列遥测传输， ISO标准下基于发布/订阅范式的消息协议） 、 RESTful 还没有正式应用到车端软件架构中。
汽车 SOA 架构设计当前处于起步阶段， 面临诸多挑战。其中包括车端硬件环境的限制，高实时性和高确定性要求， 系统设计与工作模式的转变， 面向服务通讯组件的整合与集成，架构服务化带来的信息安全风险， 功能安全方面的挑战， 异构环境及非 SOA 架构模块的并存增加了系统架构的复杂度等。
总体而言， 目前整车企业更多是进行少量服务化尝试， SOA 架构还未形成通用普适性规范。汽车软件架构正处于 SOA 化和传统非 SOA 化架构并存的阶段， 软件跨域分布式计算与多功能域异构软件环境是其显著特点。未来随着汽车电子电气架构向中央集中式演进， 汽车软件架构也会逐步实现全面 SOA 化， 各域功能进一步融合， 服务定义更加丰富， 服务重用与共享程度更高， 软件开发更加灵活便捷。伴随着车云一体化发展， 汽车软件平台会逐步演进为智能网联汽车边缘计算节点， 和智能网联云平台充分协同， 有效推动软件定义汽车的实现。
二、系统软件
2.1 虚拟化管理与板级支持包
系统软件层面， 主要包括 BSP（板级支持包） 、 Hypervisor（虚拟化管理） 、 操作系统内核（狭义操作系统） 、 中间件组件等。
Hypervisor 是运行在基础物理服务器和操作系统之间的中间软件层， 可允许多个操作系统和应用共享硬件， 也可称为 VMM（Virtual Machine Monitor） ， 即虚拟机监视器。硬件虚拟化技术管理并虚拟化硬件资源（如 CPU、 内存和外围设备等） ， 提供给运行在 Hypervisor之上的多个内核系统。虚拟化（Hypervisor） 解决方案提供了在同一硬件平台上承载异构操作系统的灵活性， 同时实现了良好的高可靠性和故障控制机制， 以保证关键任务、 硬实时应用程序和一般用途、 不受信任的应用程序之间的安全隔离， 实现了车载计算单元整合与算力共享， 是实现车载跨平台应用、 提高硬件利用率的重要途径。
在域集中式电子电气架构下， 各种功能模块都集中到少数几个计算能力强大的域控制器中， 不同安全等级的应用需要共用相同的计算平台， 传统的物理安全隔离被打破。虚拟化技术可以模拟出一个具有完整硬件系统功能、 运行在一个完全隔离环境中的计算机系统。此时供应商不再需要设计多个硬件来实现不同的功能需求， 而只需要在车载主芯片上进行虚拟化的软件配置， 形成多个虚拟机， 在每个虚拟机上运行相应的软件即可满足需求， 如下图所示。虚拟化技术的出现让“多系统”成为现实。
虚拟化技术示意
如下图所示， Hypervisor 通常被分成 Type1 与 Type2， Type1 类型的 Hypervisor 直接运行在硬件之上， Hypervisor 需要自己管理所有硬件资源；Type2 类型的 Hypervisor 运行在某个Host 系统之上， 利用 Host 系统对硬件资源进行访问。大家在 PC 上使用的 Virtual Box 和 VMware 虚拟机， 就属于 Type2 的类型。
Hypervisor 类型
全虚拟化时， Hypervisor 完整模拟了所有硬件资源， Guest OS 不知道正在被虚拟化， 它也不需要任何修改就能运行， Hypervisor 负责捕获并处理所有特权指令， 如果 Guest OS 使用的指令集架构与物理设备的相同（例如都是 ARM64） ， 那么用户级别的指令可以直接在物理设备上运行。在某些场景下， 要完全模拟一个真实的物理设备是非常慢的， 因为所有对模拟寄存器的访问都会产生一个软中断， 之后系统需要切换处理器特权模式， 陷入到 Hypervisor 当中进行模拟， 这样会带来很多额外的性能开销。为了解决这个问题， 部分外围设备会采用半虚拟化， 半虚拟化方式需要修改 Guest OS， 使之意识到自身运行在虚拟机当中， 通过 Guest OS 当中的前端驱动， 与 Hypervisor 中的后端驱动进行直接通信， 以此来换取更好得 I/O 性能，VMware vSphere、 华为 FusionSphere 就是比较常见的半虚拟化的方案。全虚拟化和半虚拟化方案如下图所示。
全虚拟化与半虚拟化
每个提供商都将为该特定处理器提供操作系统和应用程序,随着系统复杂程度的提高， 所需的计算能力被集中在一台集中式计算机中。这些处理器被要求放在一起， 同时又要互不干扰分开工作， 不同的安全等级往往会带来很大的难度。通过软件虚拟化的方法， 可以创建分配任务的错觉， 将每个任务分开， 如果某个特定任务由于软件故障而失败， 那么其他所有任务都将不受影响。软件虚拟化是分隔不同软件系统并降低总体硬件成本的有效方法。
在车载虚拟化领域， 主流的虚拟化技术提供商包括BlackBerry QNX Hypervisor（闭源） 及Intel与Linux基金会主导的ACRN（开源） 。目前， 只有QNX Hypervisor应用到量产车型， 也是唯一被认可功能安全等级达到ASIL D级的虚拟化操作系统。
Hypervisor 介乎于底层 DCU 硬件和上层操作系统软件之间， 与标准化服务器（x86） +标准化操作系统（Windows 和 Linux） 的云虚拟化应用场景不同， 汽车嵌入式环境中的虚拟化技术面临的挑战是 Hypervisor 往往需要定制适配底层 DCU 硬件和上层操作系统软件， 这对于 Hypervisor 的大规模商用与普及是一个非常大的技术障碍。因此 OASIS（Organization for the Advancement of Structured Information Standards， 结构化信息标准促进组织） 于 2016 年 3 月正式标准化 VirtIO 项目， 旨在提供一种通用的框架和标准接口， 减少 Hypervisor 对底层不同硬件和上层不同软件的适配开发工作量。
同样地， BSP（板级支持包） 是介于主板硬件和操作系统之间的中间软件层。BSP 用于为操作系统提供虚拟硬件平台， 使其具有硬件无关性， 可以在多平台上移植。BSP 包括 Bootloader（以基础支持代码来加载操作系统的引导程序） 、 HAL（硬件抽象层） 代码、 驱动程序、 配置文件等。不同的操作系统对应于不同定义形式的 BSP， 例如 VxWorks 的 BSP 和 Linux 的 BSP 相对于某一 CPU 来说尽管实现的功能一样， 可是写法和接口定义是完全不同的，所以写 BSP 一定要按照该系统 BSP 的定义形式来写， 这样才能与上层操作系统保持正确的接口。
对于一般的嵌入式系统， 硬件部分需要嵌入式硬件工程师设计硬件电路， 新出厂的电路板， 需要 BSP 来保证其能稳定工作， 在此基础之上， 才能进行下一步的软件开发。
BSP 涉及到的企业较多， 涵盖芯片制造商、 第三方软件服务商、 整车企业， 比如高通、华为、 德赛西威、 中科创达、 长城毫末和长城诺博等。
2.2 内核
内核（狭义操作系统） 是汽车操作系统最基本的部分， 负责管理系统的进程、 内存、 设备驱动程序、 文件和网络系统， 决定着系统的性能和稳定性， 是系统软件层的核心， 也被称为操作系统内核（OS 内核） /底层操作系统。根据域集中架构下汽车操作系统的发展情况，可将对应的内核粗略分为三大类：智能座舱操作系统内核、 智能驾驶操作系统内核和安全车控操作系统内核。
智能座舱操作系统主要为车载信息娱乐服务以及车内人机交互提供控制平台， 是汽车实现座舱智能化与多源信息融合的运行环境。智能座舱操作系统应用于车机中控、 仪表、 T-Box等系统， 提供导航、 多媒体娱乐、 语音、 辅助驾驶、 AI 以及网联等功能， 对于安全性和可靠性的要求处于中等水平。随着车辆由单纯交通工具向智能移动终端转变， 智能座舱操作系统内核需要支持更多样化的应用与服务， 可以支撑一个丰富的生态。
智能驾驶操作系统主要面向智能驾驶领域， 运行于智能驾驶域控制器， 支持智能驾驶所需的高性能计算、 高带宽通信的高算力异构芯片， 对安全性和可靠性要求较高， 同时对性能和运算能力的要求也较高。智能驾驶操作系统内核应以标准的 POSIX 接口为基础， 兼容国际主流的系统软件。中间件如 Adaptive AUTOSAR 等， 满足智能驾驶不同应用所需的功能安全和信息安全等要求。根据当前异构分布硬件架构各单元所加载的内核系统安全等级有所不同，AI 单元内核系统支持 QM~ASIL-B， 计算单元内核系统支持 QM ~ ASIL-D， 控制单元内核系统需支持 ASIL-D 安全等级。
安全车控操作系统用于传统的车辆控制， 适用于动力系统、 底盘与车身控制等领域， 支持 MCU 等控制芯片。车辆底盘控制与动力系统对操作系统最基本的要求是高实时性， 系统需要在规定时间内完成资源分配、 任务同步等指定动作， 而嵌入式实时操作系统具有高可靠性、 及时性、 交互性以及多路性等优势， 系统响应度极高， 通常在毫秒或者微秒级别， 满足了高实时性的要求。目前主流的安全车控操作系统都兼容 OSEK/VDX 和 Classic AUTOSAR 标准。安全车控操作系统内核需要符合车规级实时控制功能安全应用需求， 应达到 ISO26262 ASIL-D 级安全认证。
在汽车电子电气系统中， 不同的 ECU 提供不同的服务， 同时对底层操作系统的要求也不同。为支持车载软件适应不同的汽车应用场景和硬件资源， 需要不同的底层汽车操作系统（OS内核） 来支撑。因打造全新操作系统需要花费太大的人力、 物力， 所以当前基本没有企业会开发全新的 OS 内核。比如 Waymo、 百度、 特斯拉、 Mobileye ， 无论是自动驾驶企业还是车企的“自研操作系统”， 其实都是在上述现成 OS 内核的基础之上， 将自研中间件和应用软件整合形成。目前普遍采用的汽车 OS 内核主要有：
OSEK/VDX OS， 主要用于安全车控操作系统
OSEK/VDX 是应用在模块和静态实时操作系统上的标准， 由主要的汽车制造商、 供应商、研究机构以及软件开发商发起。OSEK， 是指德国的汽车电子类开放系统和对应的接口标准；而 VDX 则是汽车分布式执行标准， 后来加入了 OSEK 团体。OSEK/VDX 标准主要由四部分组成：操作系统规范、 通信规范、 网络管理规范和 OSEK 实现语言。OSEK/VDX OS 一般用作安全车控操作系统， 主要用于 ECU/TCU（远程信息控制单元） 等底层控制单元。这些单元通常使用处理能力简单且资源受限的 MCU 执行传统的车辆控制任务， 对实时性、 安全性要求非常苛刻。
目 前 OSEK/VDX 是国际上被广泛应用的汽车行业标准 ， AUTOSAR OS 正是在OSEK/VDX 的基础上进行了扩展， 并成为汽车应用主流。各嵌入式操作系统厂商都相继推出了符合 OSEK/ VDX 规范的产品， 比较典型的有 Vector 公司的 osCAN 及 MICROSAR OS、WINDRIVER 公司的 OSEKWorks、 ETAS 公司的 RTA-OSEK、 MOTOROLA 的 OSEKturbo、美国密西根大学的 EMERALDS-OSEK、 普华软件的 ORIENTAIS OS 等。随着该规范应用的不断深人，其结构和功能不断完善和优化， 版本也不断升级和扩展。
微内核 RTOS， 用于智能驾驶操作系统和安全车控操作系统
随着自动驾驶技术的发展， 车辆环境融合感知与智能决策需求带来了更为复杂的算法，并产生了大量的数据， 需要更高的计算能力和数据通讯能力。基于 OSEK/VDX OS 的传统嵌入式实时操作系统已经不能满足未来自动驾驶的需求， 这些需求对原有的车控操作系统提出了巨大的挑战。为应对挑战， 业界在继承 OSEK/VDX OS 高实时、 高功能安全特性的基础上，发展出可运行于异构大算力、 高带宽环境之上的微内核 RTOS 实时操作系统。
微内核 RTOS 架构设计是内核部分代码量少， 系统服务更多的运行在用户空间， 当某个服务发生问题时并不会影响内核稳定性， 天生具备功能安全优势。但微内核缺少类似 Linux的开源生态环境支持， 所以微内核更适合汽车软件中对功能安全要求更高、 稳定性更强的部分， 但同时对软件生态没有过高要求的场景使用（如需要 AI 算法模型框架的高级自动驾驶，较为封闭的微内核 RTOS 的应用生态很难满足） 。
基于 POSIX 标准的微内核 RTOS， 通常以 ASIL-D 功能安全级别为目标， 满足安全实时要求， 适用于自动驾驶所需要的高性能计算和高带宽通信， 支撑自动驾驶决策、 规划、 控制的算法需求， 可用于智能驾驶操作系统。在一些基于异构核的 SOC 硬件环境， 微内核 RTOS可以通过 Hypervisor 虚拟化平台运行在实时核上， 用作安全车控操作系统， 支撑一些对实时性、 安全性要求高的功能需求。目前应用在汽车领域的微内核 RTOS 主要包括 BlackBerry QNX、 风河 VxWorks、 华为鸿蒙 OS、 中兴 GoldenOS、 阿里 AliOS 等。
Safety Linux OS， 用于智能驾驶操作系统和智能座舱操作系统
Linux 是一款开源、 功能强大、 应用广泛的操作系统。Linux 具有内核紧凑高效等特点，可以充分发挥硬件的性能。它与 QNX 等微内核解决方案相比最大优势在于开源以及丰富的生态应用， 具有很强的定制开发灵活度。通常基于 Linux 开发新的操作系统是指基于 Linux Kernel 进一步集成中间件、 桌面环境和部分应用软件。Linux 功能较 QNX 等微内核更强大，组件也更为复杂， 因此 Linux 常用于支持更多应用和接口的信息娱乐系统中。AGL、 GENIVI 等联盟致力于将开源 Linux 操作系统推广至汽车领域中。AGL（Automotive Grade Linux） 是一款基于开放源代码的车载操作系统。Linux 基金会推出可定制、 开源的车载系统平台 AGL，旨在成为未来车载系统开源标准平台。互联汽车系统联盟（COVESA） ， 前身为 GENIVI 联盟， 专注于实现对车载信息娱乐系统开源开发平台的广泛普及。
不论是 AGL、 GENIVI， 还是原生 Linux， 由于其对硬件外设驱动支持性高、 软件生态丰富等特性， 成为了现阶段汽车操作系统首选之一， 但其依然面临缺乏功能安全的局限。为此，Linux 基金会启动了 ELISA 开源项目， 致力于联合业界厂家研发以功能安全级别 ASIL-B 为目标的 Safety Linux 操作系统。Safety Linux 操作系统继承 Linux 丰富的应用生态， 可更好地支持汽车高级自动驾驶业务。
ELISA 项目吸引来诸多重量级汽车领域厂商和供应商参与。ELISA 的创始会员包括丰田、宝马、 Intel、 RedHat、 英伟达等， 国内厂家华为、 中兴通讯、 斑马智行、 上汽、 地平线、 国汽智控也已经加入该组织。
目前来看， 实现 Safety Linux 工作量巨大， 尽管 ELISA 发布了一些资料对 Linux 进行了诸多卓有成效的鉴定分析， 但由于系统过于庞大， 后续分析仍然道路漫长， 而基于分析构建的认证工具、 过程资产也需要 ELISA 成员贡献大量的精力， 任重而道远。以 ASIL-B 为目标的 Safety Linux 实现， 尤其对内核关键功能进行安全增强更是一个长期任务。
Android Automotive OS， 主要用于智能座舱操作系统
Google 基于移动端 Android 操作系统， 开发了 Android Automotive OS， 专门服务于汽车领域。由于 Android Automotive 继承了 Android 生态圈开放灵活的优点， 被广泛应用到了车载信息娱乐系统当中（安全性要求较低， 车规要求宽松， 个性化需求多） 。但对功能安全要求高的仪表、 ADAS/AD 相关系统，Android Automotive OS 则无法胜任。
近年来， 智能座舱的娱乐与信息服务属性越发凸显， 目前主流车型的智能座舱操作系统包括 QNX、 Linux、 Android 等。QNX 占据了绝大部分份额， 开源的 Linux 以及在手机端拥有大量成熟信息服务资源的 Android 也被众多厂商青睐。Android Automotive OS 成为后起之秀， 为了加快 Android Automotive OS 在座舱领域的应用进程， Google 建立了一个联盟 OAA，包括奥迪、 通用、 现代、 芯片厂商英伟达等。Android Automotive OS 的买家， 不仅包括绝大部分后装供应商， 同时也有新兴造车势力和传统整车企业。
国内各大互联网巨头、 造车新势力纷纷基于 Android 进行定制化改造， 推出了自己的汽车操作系统， 如阿里 AliOS、 百度小度车载 OS、 比亚迪 DiLink、 蔚来 NIO OS、 小鹏 Xmart OS等，传统车企， 吉利推出的 GKUI 智能车载系统、 奇瑞 Cloudrive、 东风风神 Windlink 3.0、 长安的 in Call 均是基于 Android Automotive OS 开发。此外， 一些 Tier1 供应商， 也在 Android 领域进行深耕， 例如博泰推出基于 Android 深度定制版擎 OS。
总体而言， 智能驾驶操作系统与智能座舱操作系统将是未来发展重点， 其内核发展分别呈现如下趋势。
2.2.1 智能驾驶操作系统内核
（1）宏内核 Linux 的安全能力增强
继承 Linux 丰富的开源生态， 基于开源、 功能强大 Linux 宏内核， 重点增强其安全性和实时性， 发展以功能安全级别 ASIL-B 为目标的 Safety Linux 操作系统。在实时性处理方面，Safety Linux 包括大部分 POSIX 标准中的实时信号处理机制和功能， 如符合 POSIX 标准的调度策略， 包括 FIFO（先入先出） 调度策略、 时间片轮转调度策略和静态优先级抢占式调度策略。Safety Linux 内核提供内存锁定功能， 以避免在实时处理中存储页面被换出， 同时通过实时调度算法减少任务上下文的切换时间， 从而满足任务的时限要求。另外， Safety Linux 通过开源实时性 RT 补丁， 支持三级抢占、 自旋锁主动释放、 资源分区、 任务可配置优先级、任务排他性绑核运行、 无中断干扰、 智能迁移等特性， 增强实时调度能力。在安全性方面，Safety Linux 针对车用场景需求裁剪系统配置， 借助 ELISA 开源项目提供的安全分析方法和认证工具， 识别功能安全需求， 对安全关键功能采用 ISO 26262 形式化或半形式化方法完成正向设计和验证。另外提供任务运行监控、 内核增强管理、 紧急控制台、 可靠重启、 轻量级异常转储以及系统黑匣子等安全机制， 增强 Linux 安全能力。
（2） 微内核生态支持能力拓展
注重功能安全， 以 ASIL-D 功能安全级别为目标， 基于 POSIX 标准实现的微内核 RTOS。微内核 RTOS 仅实现任务调度、 时钟、 中断、 内存管理、 IPC 等最基础功能， 文件系统、 网络协议栈、 设备驱动、 POSIX 接口等都放在微内核之外， 运行在受内存保护的用户态空间。微内核 RTOS 内核小巧， 代码量少， 运行速度极快， 具有独特的微内核架构， 安全和稳定性高， 不易受病毒破坏系统。微内核 RTOS 目前在全世界范围内处于研究发展的初期， 不同厂家有不同的实现， 芯片及应用生态尚未完备。相比 Linux， 由于微内核 RTOS 缺少类似的开源生态环境支持， 目前只适合对功能安全要求更高、 稳定性更强， 但同时对软件生态没有过高要求的场景使用。未来对于智驾应用引入的 AI 算法模型框架， 微内核 RTOS 需要向上扩展支持 PSE51、 PSE52 及 PSE53、 PSE54 等 POSIX 接口标准， 甚至需要支持非 POSXI 标准接口， 向下则需定制适配兼容不同硬件厂家的 AI 算力芯片。
智能座舱操作系统内核
（1）支持多样化应用
能够支持多样化的应用已经成为智能座舱操作系统的重要指标。目前， 汽车座舱除了仪表显示、 空调/车窗控制等传统功能外， 已经开始集成支付、 娱乐、 导航、 信息服务等多样化功能。
（2） 多生态资源
越来越多的智能座舱操作系统采用 Android Automotive OS 或其他类 Linux 系统的原因是便于应用程序移植。目前手机端已经具备十分庞大的信息娱乐服务生态资源， 通过采用相同或类似的操作系统， 直接将功能移植到车辆智能终端上， 无疑是一种能够避免重复开发并且快速丰富车端生态的思路。
（3）安全性
智能座舱的使用不仅关乎用户的个人隐私安全与财产安全， 同时也通过车载网络与底盘控制、 自动驾驶等车控系统相连通。因此， 智能座舱操作系统不能简单地将手机操作系统复制到车端， 而应通过深度定制达到车辆信息安全和功能安全的标准。
2.3 中间件
为了提高软件的管理性、 移植性、 裁剪性和质量， 需要定义一套架构、 方法学和应用接口，从而实现标准的接口、 高质量的无缝集成、 高效的开发以及通过新的模型来管理复杂的系统，即软件架构“中间件”。中间件位于硬件及操作系统之上， 应用软件之下， 是汽车软件架构中重要的基础软件。总体作用是为应用软件提供运行与开发环境， 帮助用户灵活、 高效地开发和集成复杂的应用软件， 并能在不同的技术之间实现资源共享， 并管理计算资源和网络通信。中间件的核心思想在于“统一标准、 分散实现、 集中配置”。统一标准才能给各个厂商提供一个通用的开放的平台；分散实现则要求软件系统分层化、 模块化， 并且降低应用与平台之间的耦合度；由于不同模块来自不同的厂商， 模块之间存在复杂的相互联系， 要想将其整合成一个完善的系统， 必须要求将所有模块的配置信息以统一的格式集中管理起来， 集中配置生成系统。
有了汽车软件中间件后， 所有的软件和应用都具备了标准化接口， 同时硬件功能也被抽象成服务， 可以随时被上层应用调用；软件开发可以跨配置、 跨车型、 跨平台、 跨硬件适应；软件开发者可以更多地聚焦软件功能的差异化；软件认证可以有标准可依。汽车软件架构中间件包括了应用广泛的AUTOSAR、 ROS2， 以及百度 Apollo 专为无人驾驶研发的Cyber RT， 博世旗下子公司ETAS研发的针对高级别自动驾驶应用的通信中间件Iceoryx， 通信中间件SOME/IP、DDS、 MQTT等。
三、功能软件
数据抽象
数据抽象通过对传感器、 执行器、 自车状态、 地图以及来自云端的接口等数据进行标准化处理， 为上层的通用模型提供各种不同的数据源进而建立异构硬件数据抽象， 达到功能和应用开发与底层硬件的解耦。
通用框架
功能软件通用框架是承载通用模型的基础， 分为数据流（计算引擎） 和基础服务两部分。数据流向下封装不同的智能驾驶系统软件和中间件服务， 向通用模型中的算法提供与底层系统软件解耦的算法框架， 基础服务是功能软件层共用的基本服务， 其主要服务于通用模型或 功能应用。
（1）数据流
数据流框架向下封装不同的智能驾驶系统软件和中间件服务， 向智能驾驶通用模型中的算法提供与底层系统软件解耦的算法框架。数据流框架的主要作用是对通用模型中的算法进行抽象、 部署、 驱动， 解决跨域、 跨平台部署和计算的问题。
（2）基础服务
基础服务是功能软件层共用的基本服务， 其主要服务于通用模型或功能应用， 比如网联服务、 数据服务、 OTA、 地图服务等。
通用模型
（1）智能驾驶通用模型
智能驾驶通用模型是对智能驾驶中智能感知、智能决策和智能控制等过程的模型化抽象。
环境模型作为智能感知框架， 为智能决策和智能控制提供模型化的广义环境信息描述。环境模型调度各类感知、 融合和定位算法， 对传感器探测信息， 车-路、 车-车协同信息， 以及高精地图先验信息进行处理加工， 提供探测、 特性、 对象、 态势、 场景等各级语义的道路交通环境和自车状态信息。
规划模型根据环境模型、 自车定位、 个性化设置和自车状态反馈等信息， 为自车提供未来一段时间内的行驶轨迹， 主要分为行为预测、 行为决策和运动规划三大部分。行为预测是根据感知和地图数据对其他交通参与者未来的行驶轨迹进行预测， 为行为决策提供更全面、可靠的参考信息；行为决策为自车提供行为策略， 同时为运动规划提供相应的规划约束条件，保证规划结果不仅满足交通法规等硬性要求， 同时更加符合人的驾驶策略；运动规划根据以上信息， 为自车规划未来一段时间内的安全、 舒适、 正确的轨迹。
控制模型主要由常规工况和降级工况组成， 其中常规工况主要针对 ODD（运行设计域）以内的动态驾驶任务， 降级工况主要针对发生系统性失效或者超出 ODD 以外的动态驾驶任务， 均需要进行输入处理、 状态决策、 控制计算及执行输出等。针对上游及底盘信息的输入，以及控制输出均需要适配层去匹配不同的功能算法框架平台及车辆平台；针对横纵向及紧急控制等算法模块需要进行故障诊断、 配置及标定接口模块统一管理。
（2）智能座舱通用模型
a. 智能语音识别框架
智能语音交互主要涵盖语音唤醒、 语音识别、 自然语言理解、 语音合成等技术， 核心是自然语言处理（NLP） 。智能座舱语音交互应用主要是语音助手， 不同于早期的只能拨打电话或简单地识别几个单词， 自然语音识别一般指可以识别一个句子， 语音助手则是基于自然语义的理解并做出对应的调整或给出对应的响应。智能座舱域将 NLP 技术（含自然语言理解<NLU>、 自然语言生成<NLG>） 封装成服务框架， 为座舱各类智能语音交互提供 API 接口。
b. 智能视觉识别框架
在智能座舱领域， 计算机视觉使用深度学习等先进技术， 配合摄像头和显示器等输入输出设备， 结合专业的 AI 计算芯片， 及时有效地存储、 传输、 处理图像信息， 帮助大幅度提升信息转化效率和用户体验。计算机视觉的底层技术可分为全图检测、 目标跟踪、 分类识别（粗细粒度） 、 Re-ID（行人重识别技术） 、 视频理解、 3D 感知及特定任务回归等。结合应用可以进一步扩展为人体部位检测、 活体检测、 行为分类、 人脸识别、 手势识别和视线跟踪等方向， 这些视觉感知结果为座舱的人机交互及图像识别提供了基础能力。
座舱域控针对智能视觉识别框架封装服务接口， 提供手势识别服务支持手势交互。同时也提供人脸图像识别接口， 支持 DMS（驾驶员监测系统） 和 OMS（乘客监测系统） 等智能应用。
c. 多模智能交互框架
基于语音和视觉的多模智能交互是提升车载智能 HMI 体验的关键技术， 其核心是多模态交互， 对应技术是多模感知的算法融合技术， 从被动交互走向主动交互， 实现个性化推荐、多模意图理解、 多模态输出等。
多模语音是典型的多模融合技术， 该技术深度融合了语音和唇部图像信息， 有非常明显的优点， 无论语音前端和后端都可以借助于多模技术提升算法性能。多模语音技术的主要优点主要体现在图像信息的引入、 误唤醒的控制以及音区个数的增加。
随着车载终端 AI 芯片的丰富算力能支持视频流和音频流的实时处理， 结合视觉辅助的多模语音方案正成为技术演进的趋势。相较于纯语音算法日益趋缓的发展， 多模语音方案不仅能够带来高噪声场景下指标的显著提升， 解决高噪环境语音方案难用的传统痛点， 极大提高用户体验。
座舱域控针对多模智能交互框架封装服务接口， 提供手势、 语音识别的融合服务。同时也提供人脸图像识别接口， 支持 DMS（驾驶员疲劳监测系统） 和 OMS（乘客监测系统） 等智能应用。
d. HMI 展示框架
智能座舱 HMI 人机交互界面逐步朝着大屏、 多屏、 酷炫、 智能等方向发展， 针对不同形式的 HMI 展示需要， 统一封装一套强大的 MVC（模型视图控制器） 展示框架尤为必要。近年来中科创达提供的 Kanzi 展示框架在座舱车机领域应用广泛， Kanzi 框架包括 KANZI Studio 和 KANZI Engine， 以及由 KANZI Connect、 KANZI Maps、 KANZI Particles、 KANZI Autostereoscopy 构成的功能包， 如下图所示。基于 Kanzi 框架进行服务化封装， 可以支撑 3D 仪表、 HUD 抬头显示、 AR 导航等应用的酷炫效果展示。
Kanzi 框架示意
安全域基础应用
安全域是指同一系统内有相同的安全保护需求， 相互信任， 并具有相同的安全访问控制和边界控制策略的子网或网络。将安全需求相同的接口进行分类， 并划分到不同的安全域，能够实现域间策略的统一管理。例如车内网系统对外的安全接口包括了：近场通讯（wifi/bluetooth/rke/pke/） 、 远端通讯（4g/5g/gps） 、 对外物理连接节点（bms） 、 对外物理连接端口（obd、 USB 等） 。针对车内通信数据进行传输控制， 车载通信架构中引入防火墙，在整车架构外围及各安全域层之间进行监控隔离， 根据既定的安全策略（如黑/白名单） 对通信通路进行可靠性管理。
管理平面
管理平面是汽车操作系统实现的设计基石。管理平面是复杂嵌入式系统的通用概念， 包含日志、 管理、 配置、 监控等非强实时功能， 存在于每个硬件单元。数据平面是实时控制平面， 实现自动驾驶操作系统的主要功能和数据处理， 运行自动驾驶通用数据、 实时状态监控、数据收集、 失效切换、 网联、 云控等功能模块。
API
应用程序接口可以是基于面向服务（SOA） 的订阅形式架构， 也可以是使用统一开发接口 （API） 函数调用的形式， 使用这些应用软件接口和 SDK（软件开发工具包） 可以进行高效、 灵活、 敏捷的定制化开发。
四、软件远程升级
在软件定义汽车的时代， 汽车安装了大量的软件程序， 从而变得越来越智能， 但当出现一个程序问题或者更新升级时， 传统模式将是一项繁重的任务， 而远程升级技术会是解决汽车软件程序/系统升级的难题的有效方案。
汽车远程升级， 又称为 OTA（Over-the-air， 空中下载技术） ， 是指通过移动通信网络（3G/4G/5G 或 WiFi 等） ， 对零部件终端上固件、 数据及应用等“软件”进行远程管理的技术。OTA 贯穿了汽车软件系统最上层的应用软件、 云服务， 直到最底层的系统软件层， 纵向跨越了软件不同层次， 将深刻影响汽车软件的开发和更新迭代。
汽车 OTA 可分两类：一是 SOTA（Software-over-the-air， 软件在线升级） ， 在操作系统的基础上对应用程序进行升级， 例如 UI 界面、 车载地图、 人机交互界面等。二是 FOTA（Firmware-over-the-air 即固件在线升级） ， 在不改变车辆原有配件的前提下， 通过写入新的固件程序进行设备升级， 比如通过 FOTA 新增自动驾驶功能等。
汽车 OTA 主要作用：一是降低汽车召回的成本。通过 OTA 修复部分软件 BUG， 可以大大节省汽车厂家、 4S 店和车主的费用及时间成本。二是增加汽车新功能和体验。具备 OTA功能的车辆在使用期间可以增加新人机交互方式或功能、 优化设备系统性能。三是拓展了汽车服务新空间。借助于 OTA， 整车企业在完成车辆销售后可以继续和车主产生互动， 并持续提升用户体验， 拓宽了车厂用户运营及服务的范畴。
汽车 OTA 升级流程， 核心业务包括软件包研制、 升级任务定义、 车端版本下载和刷新等部分。升级过程一般可分为三步， 首先将更新软件上传到 OTA 中心， 然后 OTA 中心无线传输更新软件到车辆端， 最后车辆端自动更新软件。
汽车 OTA 业务可以划分为 OTA 云端、 OTA 车端和整车企业 IT 系统， 如下图所示。OTA 的云平台用以管理 OTA 的业务， 包括车型管理、 车辆管理、 零件管理、 升级固件管理、升级任务管理、 用户管理、 数据统计等功能。OTA 的车端主要负责处理升级管理， 包括车端的人机交互、 升级包的下载、 升级条件判断、 升级流程管理、 升级结果通知等。汽车 OTA 业务还可以与整车企业现有的 IT 系统做整合从而实现车厂信息化系统的统一建设。
汽车 OTA 业务
汽车 OTA 关键技术：
分布式部署
随着以中央计算为核心的电子电气架构的普及， 以及软件定义汽车的普及， 要实现整车软件升级， OTA 软件功能将会在不同的域进行部署， 来满足 OTA 的实时性与硬件资源的局限性。这就要求 OTA 软件功能的设计具有可移植性， OTA 软件的分布式设计技术尤为关键。
可靠性设计
容灾备份：软件包仓库（软件包文件） 及 OTA 云服务的关键数据（车辆、 ECU 档案、最新版本号等） 需要支持灾备， 通过在不同数据中心、 甚至不同城市之间做备份。
加密及认证：加密和认证机制保证升级包完整可靠。
支持断电续传、 断电续升：车端 OTA 升级代理从云端下载升级包时， 需要支持断电/短链续传功能， 和具体实现方式， 比如可以将升级包切分为多个数据块， 每次下载之后记录当前最新的块序号， 续传时从最新的块序号开始下载即可。断电续升是指车端升级代理刷写ECU 固件包时， 断电恢复后可以按最新版本数据位置继续刷写。
支持 A/B 块升级策略：在车端 ECU 模块中， 只是先向备用目录刷写版本包， 刷写成功后再重启切换加载位置（bootloader 中控制） ， 通过这种方式实现 A/B 块升级策略。如果升级后出现问题， 可以确保快速安全回退。此外， 车端针对同类 ECU， 支持灰度升级策略， 即先升级一个 ECU， 验证正常后再批量刷写同类型的其他各个 ECU。
支持升级回退：对于升级异常或成功的情况都支持回退操作， 恢复到升级前的版本。
支持重复升级：支持同版本号多次重复刷写， 主要应用场景是对于升级结果不可信的情况， 可以多次尝试， 确保升级结果可信。
差分升级
差分升级又称“增量升级”， 就是升级时并不会把所有的文件全部进行替换， 而只是替换那些需要更新的文件。过程分为：
（1）从两个升级包通过差分工具， 利用差分算法生成差分包。
（2）在设备端升级时， 通过还原算法把差分包还原后再进行升级。
差分升级与整包升级相比， 优势在于升级包的大小减少， 缩减了下载时间节省了网络流量；劣势在于在升级过程的处理上更为复杂， 流程控制上需要更严谨。
无感升级
无感升级是指在系统升级过程中， 对于用户使用车辆没有影响。这种升级方式常用于车辆的智能设备， 目前市场上多数案例还是集中体现在座舱域。无感升级对于设备的要求较高，需要有 A/B 两套均可正常工作的系统分区。例如， 在域控制器内进行内存分区， 一个区用于升级， 一个区用于车辆正常运行， 可实现在 A 系统正常提供各种应用功能的情况下， 去升级 B 系统， 从而在升级期间不影响车辆使用。对于集成了复杂功能的域控设备的车辆， 无感升级可大大缩短车辆用户可感知的升级时间， 减小了驻车升级时对车辆电量的消耗， 缩短了车辆不可用时间， 也保证了系统始终的可用性。不过， 在车辆运行时执行完成 B 系统的升级过程， 对设备系统的性能与安全性也提出了很高的要求。尤其是在 FOTA 层面， 例如实现传统的电子控制单元 ECU 的“无感升级”， 一方面需要解决数据包传输的问题， 另一方面 ECU 本身要支持类似于“A/B”的系统特性， 提供备份冗余， 或者实现软件内容 A/B 区域的地址映射。
OTA 通信协议
OTA 的通信协议主要包括车云的通信协议， 与车内控制器之间的通信协议。随着新的汽车电子电气架构的发展， 以及以中央计算为核心的电子电气架构的普及， OTA 的车云通信协议需要实现标准化， 用于普及未来汽车软件生态的共享。同时通过统一的通信协议， 更好的监管 OTA 的升级记录与 OTA 的安全流程。
从应用现状来看， 目前仅有少数车型能够提供整车 FOTA， 大多数车型能够做到的 OTA还只是将软件升级包发送至车内的 T-BOX， 而不能实现 ECU 层面的软件升级。FOTA 能够深层次改变汽车控制系统、 管理系统及性能表现， 比 SOTA 在技术实现上难度更大。FOTA 涉及控制器核心功能（控制策略） 的系统性更新， 对整车性能影响较大， 升级过程对时序、 稳定性、 安全性要求极高， 同时升级前置条件包括挡位、 电量、 车速等要求， 因而升级过程一般不支持车辆运行， 也就是前文提及的“无感升级”在 FOTA 层面的实现颇具挑战。作为车辆应用软件的底层载体， 操作系统是汽车 OTA 得以实现的关键支撑技术， 尤其 FOTA 固件更新。
下载ECAD模型
