智能座舱架构与芯片 - (1) 背景篇

一、软件定义汽车

1.1 什么是软件定义汽车

软件定义汽车(Software Defined Vehicles, SDV)的核心思想是，决定未来汽车的是人工智能为核心的软件技术，而不再是汽车的马力大小，是否真皮座椅，机械性能的好坏。软件定义汽车的终极目标，就是无人驾驶汽车。

这个回答是否就是“软件定义汽车”的正确含义呢？恐怕未必见得。在通信行业，一直都有“软件定义无线电”，在IT行业，又有“软件定义功能”等等概念。这些概念体现了一个基本的思路，即从需求到产品的一个分析和实现的过程。

从上述的系统分析分解分配的思路来看，真正定义产品的，不是硬件，也不是软件，而是市场需求，以及由此而分析推演得出的系统架构。

1. 市场定义需求

汽车是满足人们需要的产品。因此汽车生产商(主机厂,OEM等)，需要进行大量的市场调研，定位目标客户群体，分析客户需求，对市场竞品进行分析，完成市场对标和技术对标，从而提炼出产品的特性，得到产品需求。

2. 需求定义架构

有了需求，汽车生产商的体验经理(或者叫Marketing经理)，就可以提出具体的要求。例如汽车的机械性能，座舱空间能力，各项电子设备的功能等等。这些需求将送到系统工程师，进入下一步分析环节。系统工程师分析现有的功能需求，根据现有技术和预研技术能力进行梳理，确定整车的系统架构。

3. 架构定义功能

如果现有的货架化产品可以满足要求，则搭配组合，形成产品功能矩阵。如果没有现成的技术，或者现有货架化产品成本太高，则需要确定自研技术，或者合作开发，或者选择备选方案。综合上述过程，形成产品的功能模块。

4. 功能定义软件和硬件

架构设计的功能，最终需要落实到软硬件来实现。硬件是载体，它决定了架构的下限。软件是功力，它决定了硬件能力发挥的程度。由于硬件的特性，它是不容易改变的，或者说它的更新迭代周期远远长于软件。因此需要对软件进行模块化设计，定义好升级迭代的策略。

5. 软硬件共同定义产品

由软件平台和硬件平台，共同组成了用户可见的汽车产品。当用户购买了一辆汽车时，他/她所见到，体验到的功能，由硬件和软件共同决定。不同的车型，即使采用了相同的硬件设备(Tier1提供的功能设备)，由于不同的软件适配能力，用户所能感受到的产品性能是不一样的。

在汽车发展的过程中，电子电气设备的重要程度逐渐提升。随着电动汽车时代的到来，智能化在用户感受程度方面逐渐成为产品的竞争门槛。在这种时代背景下，软件能力给汽车的体验功能提供了更高的天花板，提升了产品的竞争力。因此，笔者认为，这或许才是软件定义汽车的真正含义。

软件定义汽车，是相对于传统的汽车功能定义所提出的一种改变。

传统的汽车，整车物理结构主要由动力系统(发动机，变速箱等)，底盘，电气设备，车身等4个部分组成。底盘负责支承、安装发动机及其各部件、总成，形成汽车的整体造型，承受发动机动力，保证正常行驶。电气设备负责起动控制、点火控制、照明与信号系统、电动辅助控制等，主要包括蓄电池、发电机、起动系、灯光与信号系统、信息显示系统、辅助电气系统、电子控制系统等。车身包括车窗、车门、驾驶舱、乘客舱、发动机舱、行李舱等。当新时代的来临，汽车电动化，智能化，网联化，服务化的需求会要求新增更多的功能单元，如果没有一个良好的架构，越来越多的新功能将难以集成到现有的汽车架构中。

而新型的智能汽车，将整车分为了信息娱乐域，自动驾驶域，动力总成域，底盘域，车身域等5个大的功能领域。软件定义汽车的开发理念，将从架构体系入手，从上至下，实现软硬件的解耦。在整个过程中，整车功能的定义与实现主要通过系统架构设计而实现。整车的功能不再由多个现成的ECU单元所组合而成，而是被抽象成可以被软件和服务共享的资源池，从而使汽车的功能由软件来定义。

总体上，软件定义汽车是指汽车软硬件解耦，由系统架构设计决定汽车的硬件资源池，为整车提供模块化和通用化的硬件平台。以人工智能为核心的软件技术，将为汽车的智能化，网联化，服务化提供核心支撑，支持汽车功能的开发，引领技术革新和产品的差异化。

1.2 如何达到软件定义汽车

智能汽车领域正在成为新一轮科技革命和产业革命的战略高地。电动化，网联化，智能化，共享化等新"四化"正是智能汽车的标志。它是指搭载先进传感器，运用人工智能等新技术，具有自动驾驶功能，逐步成为智能移动空间和应用终端的新一代汽车。

相较于传统的汽车行业，智能汽车的核心差异点在于具有高级自动驾驶辅助系统，智能座舱系统，车联网系统。最显著的特征则是智能化，网联化，共享化。对应到智能汽车三大要素，即智能驾驶，智能交互，智能服务。

智能汽车的智能驾驶，智能交互，智能服务的实现，需要从硬件和软件两个层面得到支持。首先是需要具备摄像头，激光雷达，人工智能芯片等硬件系统支持；其次是需要高级的感知算法，决策算法，执行系统等软件支持。因此，智能汽车的核心竞争力体现为软件+硬件。

根据软件定义汽车的概念，需要实现汽车软硬件的解耦。如何实现解耦？这就要求通过汽车电子电气架构的设计来实现硬件平台的模块化和资源化；通过SOA来实现软件平台的服务化。

架构设计：
架构设计的方向主要是平台化，组件化，集成化，服务化。

1. 平台化

汽车的开发中，同一个平台的基础上可以发展出多款车型，这既是成本的需要，也是技术发展的必然。平台化同时体现了可复用性和可扩展性。基于相同的平台架构，通过子功能模块的组合与集成，就能够安全快捷地研发出新款车型，同时可以体现出差异化竞争的优势。

2. 组件化。

当系统架构向平台化发展时，另一个发展趋势必然是组件化。当软硬件解耦以后，硬件设备将被抽取出来，按功能领域进行划分，形成多个域控制器。软件功能将实现重新区分和组合，形成高内聚，低耦合的功能模块。这些模块通过标准通信接口和SOA服务实现相互作用，并且运行在不同的域控制器上。最终按组件形式成为了标准化的货架化产品，更方便升级。

3. 集成化

传统的汽车内有近百个ECU，每个ECU都是由独立的供应商设计和开发。ECU内部，软件和硬件是强绑定的，不同ECU之间协同难，效率低，升级慢。如果能够对ECU进行梳理，将多个ECU的功能集中到少数高性能的计算单元中，不仅可以节省算力；还可以降低成本。同时，更重要的是降低了汽车对ECU供应商的依赖，有利于供应链的整合。比如，再出现2021年汽车产业“缺芯”问题的概率就会大大降低。

4. 服务化

汽车正在由“功能型”向“服务型”进行转变，基于车载软件的智能服务也在悄然兴起。如娱乐服务，生活服务，出行服务等。汽车座舱将成为人们的“第二生活空间”。在这种趋势下，系统架构对服务化的适应，体现在以下几个方面：通过车联网，提供云端服务；通过SOA，实现功能组件的协同；通过OTA，实现功能升级和产品迭代。

因此，我们可以从系统架构的设计入手，推动软硬件解耦，整车物理结构不再与特定的功能绑定，而是抽象成可以被软件和服务共享的资源池，从软件的角度实现汽车功能的定义，开发，升级，从而实现软件定义汽车。

二、汽车电子电气架构EEA

2.1 什么是EEA

上文中提到，要想实现软件定义汽车，首先要考虑的就是通过汽车电子电气架构的定义与重构，实现汽车软硬件的解耦。那么问题来了，什么是电子电气架构？

根据百度百科的解释，电子电气架构(EEA, Electrical/Electronic Architecture)，是首先由德尔福公司提出的，集合汽车的电子电气系统原理设计，中央电器盒设计，连接器设计，电子电气分配等系统设计为一体的整车电子电气解决方案。通过EEA的设计，可将动力总成、驱动信息、娱乐信息等车身信息转化为实际的电源分配的物理布局、信号网络、数据网络、诊断、容错、能量管理等的电子电气解决方案。

随着智能汽车时代的到来，EEA被赋予了更新的意义。在实践中，智能汽车的电子电气设备更多向智能化和网联化发展。传统ECU在汽车内部的占比越来越低，EEA更加关注于新型智能设备，例如摄像头，大型显示屏，人工智能芯片等。EEA从传统的面向信号体系，加速向智能化时代的面向服务体系进行转变。

2.2 EEA的演进

说起EEA，就要从传统汽车面临的困局谈起。虽然现在大家已经基本接受了新型EEA的概念，但是简单回顾一下历史也非常有必要。

传统的汽车EEA中，一开始是依赖于各供应商提供的ECU来实现整车电子电气的。这种架构下，要新增一个功能，那就请供应商(Tier1)看看能提供什么样的产品(ECU 电子控制单元)。然后，分析该产品的布线，布局，看看在整车物理架构中如何塞进去。例如，考虑如何供电？考虑车内哪里有空间可以放下它？如果它要跟其他ECU通信，要怎么增加通信接口？是否需要再增加一根通信线？

当这种新的功能，或者说新的ECU需要越加越多的时候，问题就大了。如何才能满足要求？一辆传统连接的汽车中，导线总长度可以达到2000多米，电气节点可以达到1500多个。线束材料成本剧增，系统臃肿而庞大，并且还存在布局空间困难......

2.

这个时候，需要对EEA做点改变了。是不是首先想到，要建立总线的概念？系统工程师首先在车里布置好总线，而后，再把各ECU挂载到总线上，这样当需要增加新的ECU时候，只要ECU是按标准接口进行设计的，直接挂载到总线即可，非常的方便。这种以统一协议为基础的车载网络总线技术就是分布式ECU的EEA架构。

汽车总线技术的优点是在统一应用层协议和数据定义的基础上，可以使之成为一个“开放式系统”，具有很强的灵活性。对于任何遵循上述协议的供应商所生产的ECU都可轻易添加入该网络系统中或者从网络系统中拆除，几乎不需要做任何硬件和软件的修改，这完全符合现代汽车平台式设计的理念。因此汽车电子控制采用网络化设计可大大降低设计成本。

车载网络总线技术包括LIN，CAN，CANFD，FlexRay，MOST，车载Ethernet等。

但是这种EEA的缺点也逐渐暴露出来：总线技术是由ECU厂商确定并推广的。话语权在Tier1厂商手里。假如有新的技术出现，但是部分ECU供应商并没有更新换代的动力，仍然坚持采用旧的标准，这样就会造成新旧技术的并存，进而影响到汽车的演进和升级。尤其是智能汽车时代，同一辆车上，车载网络总线存在LIN，CAN，CANFD，Ethernet并存的现象。

3.

随着智能汽车的浪潮到来，原有的分布式EEA架构完全不敷使用。其一，车载网络总线带宽不足，根本无法承载高带宽数据量传输的要求。例如智能车的感知系统，需要传输高带宽的图像数据。其二，算力不足。无论是智能驾驶，智能交互，还是智能服务，都需要高算力的域控制器提供运行平台。因此，EEA架构必须适应新的发展。
新的EEA架构需要考虑如下3个关注点：

• 硬件成本：减少ECU的个数，可以降低成本。减少线缆的长度，也可以降低成本。从硬件成本的角度出发，要求新型EEA架构能够在汽车新功能不断增加的前提下，降低ECU个数和线缆的长度，从而降低硬件成本。
• 软硬件解耦：汽车行业的传统是，Tier1厂商将“软件+硬件”集成在ECU中，打包卖给汽车厂商(主机厂)。软硬件的耦合深，价格贵，调试难。且供应链很长，缺少任何零部件就会影响整车的生产。新型EEA需要将软硬件实行解耦，这样主机厂可以通过软件OTA升级，掌控汽车升级的节奏。
• 可复用可扩展：新型EEA架构下，硬件资源将尽可能的实现抽象，算力资源集中到少数的域控制器上。将原有的各种分布式ECU进行重构和组合，感知和决策由域控制器来实施，ECU将弱化为执行器，其控制功能由运行在域控制器上的软件来实现。这样就可以实现可复用和可扩展的要求。

基于如上3点考虑，汽车行业提出了EEA演进的Roadmap，下面将以最经典的一幅图来说明。

上图是博世汽车对EEA架构演进思考后提出的roadmap，得到了业界广泛的认同，大量分析EEA的文章均引用了此图。EEA的发展演进，被分为6个阶段：分布式模块阶段，功能集成阶段，标准域集中化阶段，跨域融合阶段，车载中央计算机和区域控制器阶段，车云一体化阶段。由于跨阶段发展存在重叠，又可以把6个阶段合并成3个具有明显特征区分的架构，即分布式ECU架构，域控制器架构，中央计算机架构。

1. 分布式ECU架构

在2015年博世汽车提出这个演进路线图时，EEA还处在分布式模块化和功能集中化的阶段，所以把该阶段称为Today。在Modular阶段中，一个功能是由一个ECU来实现的。并且还带有一组相关的传感器和执行器，并从车辆网络接收其他数据。车辆的通信矩阵描述了ECU之间的这些必要的通信通道。 但是，这种设计限制了可重用性。传感器和执行器直接连接到单个独立的功能性ECU上。 如果其他总线参与者需要使用这些值，则需要更改通信矩阵。

后来，ECU逐渐进行小规模的合并，目的是减少硬件设备。但是整体架构还是一种面向信号的通信机制，由CAN和LIN总线连接各ECU，进行点对点的通信。这个就是Integration的演进。

2. 域控制器架构

博世预估这个阶段的时间为2019年到2023年。这时EEA发展的特征是以车载以太网为通信骨干，以域控制器为处理核心，融合各ECU的功能，并努力集中到少数几个域控制器上。这里的域控制器(DCU, Domain Control Unit)是根据功能来划分的。在Centralization阶段，整车分为信息娱乐域，自动驾驶域，动力总成域，底盘域，车身域等5个主要的功能域，每个域由一个域控制器来实现域内ECU的功能。在这种EEA架构下，需要有一个中央网关来连接各域控制器。通过以太网，这些域控制器相互之间可以实现通信。

随着域控制器的进一步发展，进入了跨域融合的时代。这时部分域控制器会实现合并，5个域彼此重组融合，最后形成了3个域：智能驾驶域，智能座舱域，车辆控制域。

其中，车辆控制域基本将原动力域、底盘域和车身域等传统车辆域进行了整合；智能驾驶域和智能座舱域则专注实现汽车的智能化和网联化。涉及的零部件主要有4类，车控域控制器（VDC，Vehicle Domain Controller）、智能驾驶域控制器（ADC，ADAS\AD Domain Controller）、智能座舱域控制器（CDC，Cockpit Domain Controller）以及中央网关，其中：

• VDC作为Private DCU，负责整车控制，实时性安全性要求高；
• ADC作为Public DCU，负责自动驾驶相关感知、规划、决策相关功能的实现；
• CDC作为Public DCU，负责人机交互和智能座舱相关功能的实现；

这时，各ECU将降低成为执行器和传感器，失去了独立决策的能力。作为执行器，它们接收来自域控制器的命令，做出反馈动作。作为传感器，它们采集各种内外部信息，传递到域控制器的感知系统。

注意，对于ECU的功能变迁，只是一种高层级的描述。在实际应用中，由于汽车控制的要求与供应链的要求，涉及到车辆运动系统的变动，例如转向，安全防护等，还不能完全脱离传统ECU的功能定义。

3. 中央计算架构

对于EEA发展的第三阶段，在博世的描述中被称为Vision，远景，展望。在这个发展阶段中，首先，所有的DCU会合并成一个中央计算机，它承载了智能驾驶域，智能座舱域，车辆控制域的功能，并且还集成了中央网关的功能。这就是所谓的Vehicle Computer。而后，随着车联网进入5G时代，还可以期望将Vehicle Computer的功能迁移到网络云端，车辆完全作为一个网络节点而存在，所有的计算功能将布置在云上。这个功能被称之为Vehicle Cloud Computing。

2022年，已经有部分车企(主机厂)在向着Vehicle Computer的方向迈进。这其中的代表无疑是特斯拉。这种架构被称为中央计算机-区域控制器(Centralizer-Zonal)架构。在第二代EEA架构中，以功能来划分DCU。在相同的Domain下的ECU，即使分处车身的各物理区域，仍然需要直接连接到同一个DCU下。以车灯为例，前车灯，后车灯，都要连接到VDC上。这样势必会带来整车线束的过多，影响成本和重量。

从网络拓扑结构进行分析，可以将按功能划分的EEA架构改为按物理区域划分。这样，可以将全车分为前后左右四个区域(Zonal)，分布在各区域的ECU统一连接到本域的控制器上(Zonal-Controller)。这样就可以减少线束的使用。

在发展的过程中，可能存在4个，3个，2个Zonal的实际案例。这背后体现了各主机厂对功能划分的认识，对供应链整合的能力，以及对成本控制的考量。并没有统一的好或者坏的说法。下图是 Zonal划分的2个范例：

特别需要提起的是，中央计算机的含义是将三域控制器集成在一个中央单元内，但并不代表一定需要采用同一颗SOC芯片完成三域融合的功能。在当前的时期(2022)，还看不到三域融合到一颗SOC芯片的可能。

三、SOA概念与应用

3.1 什么是SOA

• SOA是Service-Oriented Architecture的缩写，面向服务的架构。
• 百度百科对SOA的定义是：面向服务的体系结构，是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分。通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

SOA的概念最早来自于IT界，到目前为止还没有一个公认的定义。但是SOA的目标和其特性是十分清楚的。
目标：构建一个灵活可变的平台系统。
特性：

• 服务间 ：低耦合、无依赖
• 服务内 ：高内聚、可复用、可重组
• 服务通信接口 ：标准化，不依赖于底层平台

SOA实现的重点在于：

• 服务通信标准化，即面向服务的通信（SOC，Service-Oriented Communication）
• 以服务重用、灵活重组为目的的服务划分，即面向服务的重用共享设计（SORS，Service-Oriented Reuse-shared Design）
• 用于承载和适配SOC和SORS的软件实现，即基于服务的软件架构（SOSA，Service-Oriented Software Architecture）

3.2 为什么需要SOA

在数字化重塑汽车的浪潮下，一场深刻的汽车电子电气架构和软件的变革正在酝酿。汽车行业正沿着PC和手机行业走过的道路迈向智能时代。在这样的时代背景下，传统的汽车EE架构，以及传统的面向信号的车载软件架构，都面临着颠覆性的变化。谁能拥抱这种变化，主动迎向这种趋势，谁才能赢得竞争。

传统的汽车软件，是面向信号的架构。车内多个ECU，通过CAN总线相连。但是信号的收发关系和路由信息通常是静态的、不可更改的。电子电气架构师在进行整车EE架构设计时，通常会首先画好整车的网络拓扑结构图。每一个ECU都是拓扑图上的节点。如果没有改动，那这些ECU可以很好的协同工作。但如果后期突然需要新增节点，如何更改矩阵和路由表呢？再如果，车辆上市后想新增一个功能到某个ECU，通过OTA可以将软件包本身下载到该ECU，但其他ECU如何获取这个新功能所提供的信息？是否需要将所有涉及的ECU全部执行一遍OTA升级？每一个ECU的供应商是否能协同配合？以上这些问题很难在传统的架构中得到解决。

根据之前所述SOA的特性，正好可以引入汽车行业，配合着新型的中央集中-区域控制器的EEA架构，实现软硬件解耦。从而解决了之前所述面临的困局。

因此，智能汽车软件架构进入了面向服务的时代。

3.3 SOA如何实现

与中央集中-区域控制器的EEA架构相匹配，它引入域控制器DCU概念，其芯片算力、操作系统以及软件架构可以满足业务需求与硬件资源解耦的需求。即有能力通过一套基础软件框架去实现SOA的设计思想，从而将底层的硬件资源具备的能力抽象为一种服务供外部使用，并能够支持一系列的服务管理功能（服务定位、服务发现，服务调用等）。

应用服务化：各个域将自己所能的提供服务公开化后，才能实现不同域之间的开发与融合，使智能汽车成为可能；
服务部署灵活：SOA的一个基础，就是“服务发现”机制，即给每个服务分配一个“全局名称”，通过这个名称就可以直接找到对应的服务，就好比我们上网时用的“网址” 。基于这个特性，在整车生命周期内，不同的车型配置可做不同的服务部署，对代码几乎可以不用改动；

软件更新灵活：SOA的松耦合特性，可以将功能更新与变更限制在更小的范围内。当硬件架构需要调整时，减少复杂功能涉及的ECU数量，多个ECU的功能融合到中央计算平台当中。当软件架构需要更新时，只需要在中央计算平台内部更新/升级部分软件即可；

1. SOC面向服务的通信(Service Oriented Communication)

SOC主要为了实现通信标准化，动态建立通信关系，连接信息孤岛。车载以太网协议架构中的SOME/IP（Service-Oriented MiddleWare over IP）就是基于SOA思想定义的通信中间件。SOME/IP是针对车载环境定义的一套通信协议，出自AUTOSAR。可以达到屏蔽系统异构性，实现互操作的目的。除了SOME/IP之外，还有一种DDS协议也可以用于SOC。

2. SORS面向服务的重用共享设计(Service-Oriented Reuse-shared Design)

SORS是基于下一代智能网联架构来实现的，主要是完成服务实现，并且体现服务复用性而进行的设计工作。使服务本身高内聚，服务之间能够低耦合，提高服务的可重用性，明确边界概念。

在SORS的设计中，我们可以采用Top-Down的思路来进行：

Top-Down又称为自上而下的分解过程。从车辆的功能和业务流程入手，将功能进行分解。例如整车防盗认证，会有各级防盗认证流程，期间会调用到很多的模块或者算法，比如随机化算法、防盗认证算法等。可以将这些算法抽取出来形成不同的算法服务，从一个个的功能业务链入手，分化抽离出服务库。最后可以逆向重建，即从服务库中挑选出一个个服务模块，通过排列组合的调用就可以将原始的功能业务场景还原出来。

SORS的设计方法，可以将服务分为如下三大类：

• 原子服务：不可拆分的服务，一般执行单一功能。不同的功能节点(ECU)，可以提供一个或多个针对业务的原子服务。
• 系统服务：系统可以提供的基础服务，体现该系统可以提供的能力。需要依赖于原子服务提供的功能，可以通过API或者服务提供机制，向服务使用者提供组合而成的系统服务包。
• 动态服务：基于原子服务和系统服务提供的功能进行组合，实现服务的级联。例如产品上定义一个抽烟模式，需要同时打开车窗、天窗，并播放车主收藏的音乐，这就需要调用多个系统服务去实现。

3. SOSA面向服务的软件架构(Service Oriented Software Architecture)

Adaptive AUTOSAR这个基于服务理念的中间件，就是一种SOSA。它体现了基于服务的架构思想：运行环境（ara）分成了Foundation和Service两部分。

Adaptive AUTOSAR架构逻辑视图（R20-11）

《中国汽车基础软件发展白皮书3.0》所定义的ASF，也是一种SOSA。

ASF 是位于基础软件平台（即基础操作系统和运行环境）和功能服务层之间的服务软件单元的集群，主要用于支持功能服务的通用化基础功能的开发和使用。可实现车内各功能服务之间、车云之间共享通信、 诊断、计算等资源。

ASF 主要可分为原子服务、SOA 增强型服务、系统级基础服务、整车级基础服务。软件架构设计师需基于各服务类型进行服务定义、设计，使 ASF 分层和功能定义更加清晰。在服务设计过程中遵循以下原则：

• SOA 增强型服务具有通用性：即可为所有的应用服务提供通用功能，应用服务基于服务自身需求可使用该类服务，如数据存储、服务信号转换、服务调试等诸如此类的通用化功能。
• 系统级基础服务具有一定范围的（如某操作系统或控制器之上）通用性，且具有抽象性：即对基础软件开发平台（如 AUTOSAR Adaptive/Classic、Android 等）提供的通用化功能进行抽象，并提供给应用服务使用，如健康管理服务、网络管理服务、时钟服务、电源管理服务等。
• 整车级系统服务具有全局性：即该类服务的设计更多关注的是整车层面对车内所有系统的通用化功能进行协同和管控，该层服务是对系统基础服务在整车层面的抽象和管控，即通过该层服务可以配置和控制系统基础服务，如整车健康管理服务、整车网络管理服务、整车时钟服务、整车电源管理服务等。
• 动态服务具有动态配置性：即应用服务在运行过程中可对服务进行配置，并基于配置输入执行动态服务的功能。
• 原子服务具有独立性：即其设计应与硬件配置和实现无关，与上层功能服务层和下层的硬件驱动层解耦，完全独立。
• 原子服务具有原子性：即设计的服务不可再拆分，作为服务的最小单位和执行实体，为功能服务提供最基础的执行或采集等功能

注：以上描述来自《中国汽车基础软件发展白皮书3.0》