2.1.1 整体架构

图2-1所示为一个典型的座舱整体框架示意图，可以看到端侧主要包含硬件平台、系统层、框架层以及应用层4个部分。

1.硬件平台

硬件平台包含了智能交互、通信以及网关3个单元。其中通信单元实现互通互联，包含GSM/GPRS/C-V2X、GPS、WiFi以及蓝牙等的无线连接。网关单元用于保障座舱域内安全可靠的数据传输、内置存储和常用网关接口，包括车载以太网（ETH）、控制器局域网（CAN、CANFD）、本地互联网（LIN）和FlexRay等接口。因为这两个模块属于比较标准的模块，这里不再赘述。对于智能座舱开发者来说，接触最多的是智能交互单元，因为这个单元主要用于处理各类传感器的感知结果（音频、视频或其他信号），并且将处理后的结果传入处理器进行推理计算。为了确保AI算法模型的高效运行，将会使用多种不同类型的AI芯片。我们将在本书的第3章专门讲述这类AI芯片的相关知识。

图2-1 座舱整体框架示意图

2.系统层

系统层直接运行在硬件之上，用于提供底层的算法、通信、状态管理等服务。一般来说，系统层先是通过虚拟机监视器（Hypervisor）+板级支持包（Board Support Package，BSP）的方式实现硬件平台的虚拟化，使得系统软件可以更方便地与不同硬件平台对接。Hypervisor可以被简单地理解成我们在计算机中使用虚拟机（Virtual Machine），一种可以运行在硬件平台与座舱操作系统之间的中间软件层。在系统层中，还有一个模块叫作汽车开放系统架构（Automotive Open System Architecture，AutoSAR），这是一个由全球各家汽车制造商、零部件供应商以及各种研究、服务机构共同参与的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器（ECU）标准软件架构。许多中国厂商都是AutoSAR联盟成员，如长城、东风、一汽、上汽、吉利、蔚来、拜腾、宁德时代等。AutoSAR成立的初衷是通过提升OEM以及供应商之间软件模块的可复用性和可互换性来改进对复杂汽车电子电气架构的管理。为此，AutoSAR对应用软件与底层软件之间以及应用软件之间的接口进行标准化，给出一个控制器软件参考架构，而且规范分布式开发流程中的交换格式。这样，整车厂和供应商就可以专注于功能的开发，而无需顾虑目标硬件平台。打个简单的比方，整车和零部件就好比是计算机和外设的关系，它们之间通过标准的USB接口来连接。然而在实际应用当中，AutoSAR还是有诸多限制，例如，目前提供AutoSAR开发工具链及基础层软件的基本上就Vector、Elektrobit（Continental）和Bosch三家，由于各家对AutoSAR标准的理解和具体实现方式不同，导致它们的基础层软件在某些方面是不兼容的，这使得应用时的灵活性受到了限制。其次，AutoSAR的整套工具链价格还是相当昂贵的，特别是对于一些小供应商来说。另外，传统AutoSAR用的是静态操作系统，其进程的数量、优先级、内存分配等都是固定的。一旦需要做一个改动，比如添加一个通信信号，都需要重新生成一遍整个ECU的代码并刷写，不够灵活。于是人们又开发出了Adaptive AutoSAR，来满足汽车越来越高的智能化以及越来越快的功能和软件更新频率要求。AutoSAR目前主要用于仪表和车机部分，对于智能座舱开发来说，主要关注点在框架（Framework）及通信，因为在这里主要用于提供机器学习、数据融合、图像及音频处理等基础软件开发包（Software Development Kit，SDK）及内部数据通信协议，从而支撑上层感知功能的开发及运行。我们将会在下面用实际例子加以说明。

3.框架层

基于系统层提供提供的感知、通信及管理等基础服务，框架层主要是实现座舱不同功能的模块化，用于上层座舱场景的开发。以图2-1中的框架层为例，这是一个典型的面向服务的架构（Service-Oriented Architecture，SOA），这种架构既可以实现业务和技术的分离，又可以实现业务和技术的自由组合，为上层的场景开发带来便利。为此，这里还专门基于这些模块提供了场景开发平台，以进一步降低场景开发的难度。对于智能座舱来说，这里的模块除了常用的空中下载技术（OTA）、协议解析等模块外，还可以包含各类感知模块，如情绪感知、行为动作感知、疲劳感知等。场景开发平台可以根据这些感知结果进行具体的场景开发，例如，检测到驾驶员轻度疲劳时进行语音提醒，检测到抽烟时开窗，检测到打电话时降低音响音量等。我们也将会在本书的第6章详细介绍座舱中常见的场景算法及实现。

4.应用层

该层就是座舱用户直接体验到的各类场景及功能。常见的座舱场景及应用已经在本书的第1章介绍过，这里不再赘述。

除了上面4个部分之外，智能座舱还包含各类外设，例如，以摄像头、传声器为代表的舱内传感器，以触摸屏为代表的人机交互设备，还有通信设备以及用于OTA及个性化服务的云端等。因此我们可以看到，当前智能座舱系统拥有智能化、网络化的特征、同时覆盖端侧与云侧，通过端云一体的方式为座舱用户提供主动、人性化的关怀。目前智能座舱架构没有统一标准，不同厂商会根据业务、车型及硬件平台搭建不同的架构，下面我们以地平线机器人推出的Halo智能座舱解决方案以及斑马智行智能座舱操作系统为例加以说明，方便读者参考。Halo智能座舱是地平线机器人基于其征程系列芯片而打造的智能座舱产品，并且于2020年在长安UNI-T上首次实现了量产。斑马智行智能座舱基于AliOS打造，在智己L7等车型上得到应用。

如图2-2所示，Halo智能座舱架构包含了硬件层（车机硬件、各类传感器等外设）、系统平台（HAL+驱动）、Android Framework车机服务和基于Antares策略中心的框架层，以及最终的交互应用层（包含第三方应用）。除此之外，还有J2中的系统与感知软件，这些是后续算法与开发的重心之一。在外设方面，有专门的地平线云提供相关的OTA、账号、数据等服务。以手势举例，主要以摄像头（车机硬件）为感知终端，并且将相关的图像信息输入地平线推出的AI芯片中（以BPU为核心IP的SoC，我们将会在本书第3章做详细介绍）进行手部区域检测与手势识别，这是因为相关的检测与识别模型均运行在AI芯片中。以上流程均是在系统平台与硬件的支撑下完成的。为了方便J2端感知算法的开发与扩展，以上手势识别模型可以在插件化模块中进行集成。另外，手势识别结果及交互指令也会通过决策中心发送给车机服务模块和交互应用模块，用于实现系统音量调节等场景。而在云端，除了常见的OTA服务外，还有账号管理、数据安全等服务，并且逐步扩展到个性化服务，用于实现部分场景的千人千面特征。

图2-2 Halo智能座舱架构

图2-3所示为斑马智行智能座舱架构（又称为斑马智行智能座舱操作系统），它是基于AliOS（淡蓝色部分）打造的一种全新的多核分布融合架构，包含生态娱乐核、安全仪表核、实时自驾核、实时车控核，既有负责安全的微内核，也有宏内核，可同时满足车内不同域的功能隔离和功能安全要求。最后通过SOA的框架把多核整合起来成为一个虚拟化的整体大操作系统。在图中我们可以看到，该架构分为了三个核（Core），分别是仪表Core、车机Core以及AI智能Core，通过系统级Fusion技术将三个系统整体融合打通。可同时支持仪表Core和车机Core的运行。因此，图2-3与图2-1最大的区别在于：图2-1是通过不同操作系统（QNX+Android+Linux）+应用级融合中间件来“拼装”智能，本质上仅是两个系统间的简单“通信”和应用端部分数据融合，而图2-3是基于底层操作系统级别的融合，才能让汽车内的各个端真正融为一体。另外，图2-3中异构融合式的操作系统方案能够充分发挥硬件平台的优势，大幅提升操作系统的流畅性和协同性，这也代表了智能座舱架构未来的发展趋势。下面我们将会从车端与云端两个方面分别进行剖析。