汽车智能座舱软件架构

前言

智能座舱域控制器目前承载信息娱乐系统、导航系统、驾驶员辅助系统、车辆监控和控制、安全系统等各种功能。
这篇博客主要是对座舱域控制器基于QNX、Android Automtive OS软件架构做一个大致的介绍，如果想要更宽维度的了解，可以看第一篇参考文献，我觉得写得很好。
开篇从汽车电子电器架构的演变来讲解为什么会出现智能座舱域控制器。最后我会描述和预测一下未来汽车域控制器软件架构会是怎么样的，以及传统软件架构和AI时代会有怎样的技术融合。欢迎大家留言探讨！

汽车电子电器架构演变

最早汽车中MCU都是相互相连接，互相传递信息，随着MCU增多，各个MCU之间传递的信息增多，会导致系统特别的复杂，汽车电子电器架构几乎无法发展下去。
这个时候CAN通信问世了，CAN通信确实是一个非常伟大的发明，是汽车电子电器架构发展的转折点，核心就是CAN总线实现各个MCU之间的链接，各个MCU和CAN总线链接传递信息，不在各个ECU之间相互链接传递信息，这里也注定CAN总线是以总线信号为核心进行处理传输。

电子电器架构定义

汽车电子电气架构，是指集合汽车的电子电气系统原理设计、中央电器的设计、连接器的设计、电子电气分配系统等一体的整车电子电器解决方案的概念。在2007年，德尔福首次提出 E/E 架构的概念，对发动机系统、车窗控制、车载娱乐系统等一切需要电力控制的软硬件进行系统设计和不断优化。

现代化E/E架构

博世于2017年提出了新的电气架构演化图，整车的架构将从离散的分布式架构逐步集成为几个域控制器。这种集成式的架构方案发展又来到一个转折点的变化，整车电子电器架构演进趋势如下图所示：

目前在24年底基本上主流主机厂都完成域控制器架构的开发与发布，在往中央化计算架构发展。
域控制器架构主要分为几大域控制器：动力域、底盘域、车身域、座舱域和自动驾驶域。这篇博客主要介绍智能座舱域控制器软件架构。
但是由于中央化架构马上已经要到来了，这里简单介绍主要的几种形式和演进趋势。

中央化架构

中体上分为三个阶段：

• 第一阶段：One Box，也就是每个域控制器单独一块电路板，板间通过Ethernet传输数据，传输速率大概在125MB/s。
• 第二阶段：One Broad，每个域控制芯片都在一块板子上面，之间通过PCIE接口传输数据，PCIE 4.0 x4速率可以达到8GB/s，速度比高速Ethernet提升64倍，效率大大提升。并且这个阶段Body Control Domain应该可以融合到Cockpit Domain，目前定义的BC Domain主要是外置功放和CDM（Control Dignose Center），最多在加上以S32G芯片为代表的中央网关。以后Cockpit Chip ADSP功能强大之后可以不要外置功放，并且CDM功能可以整合到Cockpit chip中，毕竟UDS（Unified Diagnostic Services）本人认为是以座舱域控为控制中心。目前的中央计算中心要交换大量的数据，很可能S32G中央网关芯片还是外挂，提供为Cockpit 和ADAS Chip访问联网数据。
• 第三阶段：One Chip，每个域控制器的功能做到整个SOC中作为一个IP core，之间通信方式为片内通信，这个速度有多快呢？可以参考M4 芯片内存带宽可以达到120Gb/s，速率提升15倍。
  目前主流主机厂One Box方案已经上车，主要都在研发One broad方案，或者直接过渡到One Chip方案。
  在域融合的过程中最主要的就是数据共享、硬件共享。

在这里我可以举个例子给大家思考：ADAS 感知数据产生是存在ADAS Domain，但是绘制显示是在Cockpit Domain，这就需要把数据跨域发送。如果是分布式域控制器架构，一般的感知数据帧率是在10Hz左右，这个帧率人眼还是明显发现有卡顿，受限与Ethernet带宽，不可能把帧率做得太高。但是如果在One Broad架构方案下，可以很轻松的做到30Hz以上，显示数据会非常流畅。
但是如果是One Chip方案，这种数据场景完全不够发挥这么高带宽的价值，我认为最高的价值应该在硬件共享，使用Hpervisor 技术对CPU、GPU、DSP等硬件虚拟化，让Cockpit and ADAS Domain都可以访问硬件资源。
目前大模型在座舱和自动驾驶域都特别火，并且都在车端部署大模型阶段，我认为以后得趋势一定是共享大模型域资源，架构图如下：

大模型域独立于其他两个域，并且可以让Large Model 通过Hypervisor给Cockpit和ADAS Domain提供AI能力，给座舱提供语音大模型，给ADAS Domain提供End To End Large Model能力。
这样可以更好的利用One Chip高带宽能力，让所有软件域共享数据和算力。

这里可以看到目前中间架构下是没有底盘域和动力域控制器的，因为这两个域控制器技术相对都比较封闭。特别是底盘域，目前都是使用Bosch EMB为代表的One box系统，这套系统的算法和控制单元Bosch都是没有开放出来的，也是统一一个模组来卖，所以目前这种技术方案是没有办法集成到中央控制中心。

智能座舱域

智能座舱域有两大功能，其中一个是In Vehicle Information娱乐功能域，第二个是仪表显示功能域。
最早这两个功能模块是两颗芯片在同一块电路板子，因为这两个功能域所要求的功能完全不同。对于仪表显示功能域最重要的点就是实时性、可靠性，所以对其特点就开发对应的实时操作系统。
娱乐功能域对实时性和可靠性并没有高的要求，要求高主要是娱乐生态的丰富性，主流选用的都是Android Autotive OS，因为目前Android生态非常的丰富。

智能座舱软件架构

随着芯片算力能力增强，这两个功能域融合为一颗芯片，但是这个功能域还是区分为两个操作系统，怎么把两个OS跑在同一颗芯片上？这就需要Hypervisor Technology。

Hpervisor Architecture

使用Hypervisor技术对硬件虚拟化搭建起来，主要有下面两种软件架构：


这两种Hypervisor Type不同点就在于Type2中，Host OS 和 Hypervisor 是一个系统，比如Qualcomm 方案中QNX使用GVM 进程作为Hypervisor功能运行Android Automotive OS。而Type1中Hypervisor 相对于Host OS是两个独立的系统。
目前域控制器方案中MCU都是单独的芯片，所以单独罗列出来。

系统软件层级架构

本人主要是基于Qualcomm 平台软件架构开发，Qualcomm 平台是以QNX为Host OS，并且其中包含Hypervisor 功能，Type 2软件架构方案。
Android Automotive OS为guest OS，
对Type 2软件架构分级进一步详细，再加上MCU 软件部分。

先从SOC部分开始介绍，QNX启动GVM进程加载Android，Android主要分为APP、Framework、Native service、HAL 、BSP layer。
Android特别解释：

• Native Service：主要包含system分区除了framework 核心服务之外的一些外设服务，比如MDNSD（Multicast DNS daemon）、logcat、ADBD、Iptable、Radio Service、Factory Reset。还有和Vendor厂商相关的Native Service，比如：Thermal Engine、CNSS（Compass Navigation Satellite System）-Daemon、Power Daemon 、IPACM（IP Access Control Manager）。
• Extend Service：主要是Vendor 厂商定制化的system Service，比如Speech Service、OMS（Occupation Monitor Service）、Car Audio Service。
• Android Runtime：Ueventd 、VOLD、LMKD、 Tombstone、Zygote、Service Manager，这都是标准组件。
• IPC OS：这个都是主机厂为了SOA Service所使用的模块，Android OS可以直接和外域OS通信。

QNX特别解释：

• Infrastructure Service：在QNX系统中提供核心服务的模块：收集QNX Log Service（一般会同时收集MCU log，然后通过UFS映射到Android 分区，直接通过ADB就可以查看，非常方便，不是需要通过MCU厂商提供的软件来导出MCU Log，很麻烦）、管理QNX power Service、接收Android系统界面信号vehicle Signal Service、接收整车车控信号的IPC Service、OMS、DMS、管理CSD屏幕和仪表屏幕的Display Service。
• Cluster Service：主要是为仪控HMI APP提供基础服务能力，比如：接收IPC Service发送过来的车控信号，在仪表界面显示的各种状态灯提供处理分析逻辑；在多屏互动过程中提取Android map的图像数据和设置显示图层的基础Service；接收ADAS传输过来的自动驾驶感知数据Service。
• APP：主要指HMI 模块，这个layer一般都会使用Unity或者Unreal Engine提供的解决方案和产品，让仪表屏幕能够显示各种图像和数据。再包括一些数据消息缓存队列

MCU软件架构主要是以AUTOSAR为标准进行搭建的，主要是处理总线信号的功能（包括各种车控信号和整车电源信号），主机厂能够开发的应该是SWC Layer，其他部分都是买的定制化AUTOSAR系统组件。
AUTOSAR（Automotive Open System Architecture）是一个全球性的汽车行业合作组织，同时也是一个开放的标准化软件架构，旨在为汽车电子系统提供一个标准化的开发框架。框架就相当于是把接口定义好，但是实现是需要自己写代码的，所以主机厂的AUTOSAR都是买的供应商的。

未来软件架构猜想

未来软件架构本人认为，应该主要是往第一种方向发展，Qualcomm和NVIDIA已经在这么做了。
主要原因我认为主要是：

• 第二种架构中Host OS会融合Hypervisor功能，所以当Host OS出现各种功能异常的情况，一定是会影响到Guest OS，两个OS耦合性还是太高。
• 第一种架构只是比第二种架构在CPU loading角度多增加一个微内核，一个微内核的CPU loading只占一个大核loading的2%左右（主要是proc 进程），负载是非常低的，付出这一点点代价换来两个操作系统解耦、不相互影响是非常划算。

还有一个发展方向我个人认为会发生，就是把MCU芯片集成到SOC芯片中，作为一个独立IP核。目前MCU单独一颗芯片的核心原因是因为SOC Chip需要在整车下电的工况断电，而MCU是一直正常低功耗运行，并且在车辆启动过程中唤醒SOC。还有一个功能就是处理总线信号，接收车辆总线传输过来的信号，然后把总线信号（模拟信号）转换之后转发到SOC。
我本人认为这两个功能作为独立IP都可以实现，现在SOC可以对单独一颗IP单独供电，解决功耗问题。也可以添加一个ADC IP处理数模转换问题，但是这样高的集成度，也涉及到成本、研发投入、市场接受程度等各种问题。而且目前MCU主要使用Infineon的芯片，Qualcomm自己不知道有没有MCU Chip，所以让Qualcomm或者NVIDIA去把MCU功能集成到SOC 作为一颗独立IP也是需要技术挑战的。

车控功能域总体架构

座舱软件架构中车控功能主要是接收各种车控信号，比如空调打开和设置温度、座椅调整方位、整车灯光使用等各种车控相关的信号。车控系统的软件架构我认为最能代表出智能座舱域控软件架构的数据链路。
总体软件架构图如下：

以打开空调为例子介绍整个数据流程：

• Air Condition APP会调用Car Service提供的API接口下发打开空调的指令。这个过程扩展说一点，一般的主机厂会在这里添加一个中转进程Service。因为这样可以让APP Layer和HAL高度解耦。在实际的环境中只有Google定义的Vehicle property信号是远远不够的，需要主机厂定义自己的Vehicle property ID。如果各种原因导致Property ID发生改变，这个时候APP是需要修改ID Number，但是APP众多各个都去适配代价很大。所以一般会做一个中转信号的进程Service，对Vehicle Property ID进行封装为标准带有特定含义的API提供给APP使用，这个时候ID Change只需要中间Service修改就可以，大大减少工作量。
• CarService再把Vehicle Property通过HIDL接口传递到Vehicle HAL（Android 14之间都是使用HIDL，14之后全部替换为AIDL）。VehicleHALManger对信号的转发进行权限校验，SubscriptionManger对只有订阅Vehicle Property信号服务的用户端才会产生信号交互功能，这两个功能组件都是Vehicle HAL中模块。Vehicle HAL这个时候就需要跨域通信把信号发送到QNX，一般是选用SOME/IP或者FDBUS建立Client。
• 图中CAN和POWER的意思代表：一般会把普通车控信号和POWER信号分别建立Client区分发送，因为普通车控信号和POWER信号在QNX是两个Server来接收的。SOC POWER信号功能非常重要，会在QNX中开发Power Manager Service模块对POWER状态机进行管理，会把SOC各种Power电源状态广播到Cluster Layer、Infrastructure Layer、Android OS（通过Vehicle HAL）。
• 不知道大家这里是否有想到Vehicle HAL中的FDUBS 都是Client，却Server都在QNX。因为核心服务的提供者都在QNX，通过QNX去管理Android状态。所以两个系统高度耦合依赖，一旦QNX状态出现问题，Android 对整个SOC状态的感知将全部失效。
• Vehicle Signal Service接收到请求信号之后，也会通过FDBUS 把信号传递给一个IPC Service模块。Vehicle Signal Service作为中间件模块会提供Android界面下发信号联动功能，如果空调功能打开的同时需要在仪表界面显示一个通知，就会通过FDBUS发送消息到Cluster APP绘制图标；如果需要Audio播放声音，也是需要把信号发送到Audio module使其通过扬声器播放出“打开空调”的声音。并且控制信号需要记忆化存储也是此模块完成，比如空调温度设置到20°C，下次空调打开就是上次设置的温度，也是Vehicle Signal Service把信号值传递到Persistency Module写入到Persistency分区，在SOC下次上电时从Persistency分区读取恢复记忆。并且如果需要把Android传递过来的数据发送外域其他ECU，可以调用SOA Client发送信号值到其他SOA Server。
• IPC Service模块功能是把FDBUS数据序列化编码为SPI格式化数据，通过SPI网络节点传输到MCU CAN Service组件中。在QNX中的其他模块：AVM、Cluster Service、Audio、FOTA需要接收车控总线信号，都是从IPC Service模块订阅获取。
• MCU CAN Service接收到SPI传输过来的数据，也先要进行反序列化，再通过CAN / Flaxray / Ethernet等数据总线传输到CEM（Centrol Electronic Module），通过CEM再打开空调压缩机。
• 到这个流程结束时候之后，会通过以上链路对设置的数据进行返回，让链路中所有模块对信号值进行确认，只有CEM返回正确的信号值才能代表整个链路打开空调的操作正确无误。

Android 整车信号和整车总线信号主要的区别：一个是Android OS下发的信号，一个是从整车总线获取的信号，信号方向和类型不一样。一个是以Vehicle Property为标识，一个以信号为标识。

Acknowledgement and Sentiment

这篇博客我是从Acknowledgement开始写的，因为进入行业一年半真的感触很深，当时隔一年半再次下笔来写感触良多。
本人是23年上半年开始入职一家新能源企业开始从事智能座舱方向软件的开发，我进入行业的时候很多座舱域控制传统软件架构都已经非常清晰，Android Automative差不多国内是17年开始研发投产，到23年这个阶段已经非常成熟，到24年10月份这个阶段，我预测主流的主机厂应该对座舱域控制器已经完成全栈自研。
我本人也是经历了全栈自研从0到1的过程，觉得汽车座舱软件系统真的太复杂了，虽然很多技术目前不深入，但是软件链路特别长横跨三大操作系统，硬件链路涉及SOC和MCU，相当复杂，我自己认为汽车是应该是目前技术上最复杂的嵌入式设备。
目前汽车行业变革也是非常的快速，已经从电子电器化的发展到智能化的发展了，由于智能化的发展会又会带来整车机械和电子电器化的进步，比如说整车48V低压系统（这个转变非常重要，因为传统的12V低压电子电器架构最高只能支持到3KW功率，预估以后中央计算平台功率会接近800W，整车其他电子电器架构部分的功率也会增加，所以3KW在未来高性能AI中央计算平台是完全不够用的，必须要提升到48V架构才能解决功率提升问题）、线控转向和线控底盘。
我对智能座舱域控制器也只算是入门，并且现在端侧大模型也开始部署，各个主机厂都在开始研发自己的AIOS，并且融合到现在的整车OS 中，发展是特别的迅速。
也有很多系统值得写但还没有写入到这个博客中，看大家有什么需求把，也非常欢迎大家留言或者发送邮件到我的邮箱和我交流，如果我发现感兴趣的人比较多，我也很愿意拉一个微信群大家一起交流！纯手打写博客不易欢迎大家留言点赞支持！
邮箱：maojun23@qq.com

参考文章

• 4W字一文带你看懂 智能座舱域控制 主流芯片及平台架构
• 智能座舱与芯片
• 汽车CEM模块是什么