域控制器目前承载信息娱乐系统、导航系统、驾驶员辅助系统、车辆监控和控制、安全系统等各种功能。

　　这篇博客主要是对座舱域控制器基于QNX做一个大致的介绍，如果想要更宽维度的了解，可以看第一篇参考文献，我觉得写得很好。

　　开篇从汽车电子电器架构的演变来讲解为何会出现智能座舱域控制器。最后我会描述和预测一下未来汽车域控制器软件架构会是如何的，以及传统软件架构和AI时代会有怎样的技术融合。欢迎各位留言探讨！

　　最早汽车中MCU都是相互相连接，互相传递信息，随着MCU增多，各个MCU之间传递的信息增多，会导致系统特别的复杂，汽车电子电器架构几乎没办法发展下去。

　　这个时候CAN通信问世了，CAN通信确实是一个非常伟大的发明，是汽车电子电器架构发展的转折点，核心就是CAN总线实现各个MCU之间的链接，各个MCU和CAN总线链接传递信息，不在各个ECU之间相互链接传递信息，这里也注定CAN总线是以总线信号为核心做处理传输。

　　汽车电子电气架构，是指集合汽车的电子电气系统原理设计、中央电器的设计、连接器的设计、电子电气分配系统等一体的整车电子电器解决方案的概念。在2007年，德尔福首次提出 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都可以访问硬件资源。

　　目前大模型在座舱和无人驾驶域都特别火，并且都在车端部署大模型阶段，我认为以后得趋势一定是共享大模型域资源，架构图如下：

　　这样可以越来越好的利用One Chip高带宽能力，让所有软件域共享数据和算力。

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

　　智能座舱域有两大功能，其中一个是In Vehicle Information娱乐功能域，第二个是仪表显示功能域。

　　最早这两个功能模块是两颗芯片在同一块电路板子，因为这两个功能域所要求的功能完全不同。对于仪表显示功能域最重要的点就是实时性、可靠性，所以对其特点就开发对应的实时操作系统。

　　娱乐功能域对实时性和可靠性并没有高的要求，要求高主要是娱乐生态的丰富性，主流选用的都是Android Autotive OS，因为目前Android生态非常的丰富。

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

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

　　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修改就可以，大幅度减少工作量。

　　不知道大家这里是否有想到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。

　　到这个流程结束时候之后，会通过以上链路对设置的数据来进行返回，让链路中所有模块对信号值进行确认，只有CEM返回正确的信号值才能代表整个链路打开空调的操作正确无误。

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