汽车SOA模型解读

SOA定义

SOA 全称 Service-Oriented Architecture，即“服务导向式架构”。它可以定义为：

• 一种软件的设计方法
• 一个组件模型
• 一种应用程序架构
• 一种设计思想方法论

总之它并不是某一种具体的技术实现。

SOA 架构采用广泛可接受的标准，把业务功能封装成标准化的服务，这类服务通过确定的且与最后实现没有关联的接口进行定义。在SOA架构中，服务是最核心的抽象手段和系统最基础的描述单元。服务是更高效地利用现有能力满足需求的一种手段，这也是SOA的意义。

SOA架构将应用程序的不同功能单元（服务）通过它们之间定义好的接口联系起来。接口是采用中立的方式进行定义的，接口的定义独立于硬件平台、操作系统和编程语言。这使得构建在系统中的服务用一种统一和通用的方式进行交互。

SOA 功能特点

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义的接口进行通讯，不涉及底层编程接口和通讯模型，独立于实现服务的硬件平台、操作系统和编程语言。

特点：

• 易于扩展
• 灵活的平台
• 服务通信标准化
• 服务间：松耦合，无状态，无依赖
• 服务内：高内聚，完整，可复用，可灵活重组

SOA架构主要有三种实体：

• serviceprovider（服务提供者）
• servicerequestor (服务使用者)
• service register(服务注册中心)

这三种实体又有三种服务处理功能：

• Publish(发布)
• Find(查找)
• Bind(捆绑)。

面向服务通讯

基于信号设计的特点

在分布式EEA种架构下，一个控制器在设计之初就定义了需要接收和发送的信号，定义了控制器应该具备的功能。在车辆行驶过程中，无论信号支持的功能有没有被调用，这些信号都会按之前的定义接收和发送，无疑增加了网络负载，同时也影响CPU的计算速度。如果需要增加新的功能，autosar底层就要按之前设计的过程重新整一遍，还要进行设计验证，应用层也要更新和验证，增加了软件更新迭代的难度。

智能驾驶背景下，高精地图、地形识别、路径规划等需要交互和处理海量的数据，而基于信号的通信速率低，远远不能满足通信需求，同时单片机的算力也不支持复杂的计算。

面向服务通讯的特点

在IT行业里，服务指的是实现某种功能的方法（即函数）。服务是一个离散的功能单元，可远程访问并独立执行和更新，可以被反复调用和使用，且易于链接。特点是独立性，低耦合性，接口通用性。

关于SOA优势，首先得益于以太网的快速发展，使得SOA通信(SOC)优势明显：

1）以太网的带宽占据绝对优势，是直接碾压CAN等传统网络的，同时以太网的带宽会随着技术的不断发展，一直是持续精进的，这点传统网络已经不具备可比性；

2）从信息安全角度，CAN大部分采用MAC和SecOC等明文传输，加密等级并不高，而SOA通信可以借助强大的以太网加密方案，甚至可以不断扩展，安全方案是不断迭代的，目前也有很多主机厂专门成立信息安全团队，加固安全策略，而CAN信息安全很难扩展；

3）SOA服务通信模式不仅支持发送者-接收者模式，同时还支持客户端-服务器模式，而CAN通信，仅支持发送者-接收者模式，单纯的发送和接收，接收端均是被动接收，而SOC可以让Client主动请求控制或者状态数据，同时也支持订阅相关数据的发送。对于CAN来说，不同的通信对，对于同一个功能，是需要定义不同的报文和信号，而这几个相同功能的信号对应的值有时还不一致，运用SOA之后，就完全可以避免这种现场，不管有多少个Client，Server可以只有一个，同时不同的Client可以调用同一个服务接口；

4）SOA的发布-订阅机制以及服务功能独立不重叠，是和互联网SOA及微服务高度契合的，使得整车SOA服务通信和后端互联，为后续开发更多的运用提供无限可能，促进汽车智能化的发展；

5）SOA架构服务通信的最核心关键词就是动态，服务可以通过OTA动态的安装，服务间调用可以动态的创建连接。

汽车EEA架构

E/E架构的演进

分布式EEA可以理解为汽车电气系统的软硬件资源和能力是分散的，且它分散在不同的供应商手中。ECU的软硬件开发全部由不同的供应商完成，整车厂主要负责提出设计需求和测试验证。分布式EEA导致ECU软硬件资源和能力的浪费。不同的供应商负责不同的ECU开发，整车数十个ECU分别负责实现特定的软硬件功能，然后通过硬线信号或者网络信号进行交互，这种信息交互方式也被称为面向信号的通信。

在传统汽车采用的分布式电子电气架构阶段，车辆各功能受不同且单一的电子控制单元控制。随着配置需求与功能实现方式的增加，导致整车中ECU数量激增。面对这种无限制的扩张，分布式E/E架构很难高效地分配和承载数据网络、电能、控制器等过多的复杂功能，所以其不再是满足现阶段甚至未来智能化汽车所需要的更高算力与更强通讯能力的可拓展性的架构设计。同时，采用的传统E/E架构不能实现整车OTA,在智能化网联化功能软件出现BUG时，通过召回的方式才能最终解决难题，极大地影响了客户体验。

随着智能汽车的发展，对E/E架构也提出了更高的要求。智能汽车要求E/E架构能够满足高计算性能、高通讯带宽、高功能安全性、高网络安全性、软件持续升级能力等多方面的需求。E/E架构的升级主要体现在3个方面，分别为硬件架构升级、通信架构升级、软件架构的升级。

受限于研发周期、项目资源、技术发展（芯片算力、操作系统、软件架构等）、供应商能力以及整车厂能力等众多因素，由分布式EEA走向集中式EEA必然是一个渐进的过程，一般会经历以下几个阶段：

• 1、在局部子系统做一些简单的物理集成、在局部子系统做一些功能集成
• 2、将某个功能域的大部分或全部功能通过域控制单元进行集中控制
• 3、功能域的进一步融合
• 4、整车由几个核心计算单元进行集中控制
• 5、整车电气系统由一个中央计算单元进行集中控制（终极EEA形态）

目前大部分整车厂量产车型的EEA处于第1和第2个阶段，少部分处于第3阶段或第4阶段。前2个阶段从本质上讲还是处于分布式EEA阶段，因为无论是物理集成还是功能集成，都仅仅是在局部功能实现上减少ECU的数量，实现功能所需的软硬件资源还是以ECU为核心进行设计。

从第3阶段开始，EEA才算是进入了集中式控制阶段。分布式与集中式控制的本质区别在于，分布式阶段的整车功能是围绕一个个ECU作为主体进行设计的，而集中式阶段则需要从子系统甚至整车的软硬件资源所具备的不同能力的角度，对功能实现进行分层设计，核心思想是不同的层面具备不同的能力，其主要目的是软硬件资源和能力的解耦。因此在汽车上应用SOA的一个重要前提是实现业务需求与硬件资源的解耦。可以粗略地将整车软硬件资源所具备的能力分为3类：计算能力、通用控制能力和感知执行能力，并将这3种能力分别对应到计算层、通用控制层和感知执行层。在第3阶段，将某个功能域的计算能力集中到DCU（域控制单元）中，通用控制和感知执行能力由各个功能域中的下层ECU实现。

在第4和第5阶段，将整车的计算能力集中到几个核心计算单元或者唯一的中央计算单元中。通用控制能力则分布在整车不同区域的ZCU（区域控制单元）中，从某个区域的范围看，通用控制能力则集中在特定区域的某个ZCU中。感知执行能力只有特定类型的传感器和执行器才具备，只能分布于整车各个传感器和执行器中。

在SOA架构中，服务是更高效地利用现有能力满足需求的一种手段，而汽车电气系统的所具备的最基础的能力是由所具备的传感器和执行器的类型和数量决定的，也可以理解为由最底层的硬件资源所决定的，因此在汽车上应用SOA的一个重要前提是实现业务需求与硬件资源的解耦。当EEA发展到第3阶段时，即引入DCU集中控制某个功能域时，汽车上开始具备了实现SOA的条件。

DCU的芯片算力、操作系统以及软件架构可以满足业务需求与硬件资源解耦的需求，即有能力通过一套基础软件框架去实现SOA的设计思想，从而将底层的硬件资源具备的能力抽象为一种服务供外部使用，并能够支持一系列的服务管理功能（服务定位、服务发现，服务调用等）。此外，DCU必须支持基于IP协议的车载以太网通信，因为目前支持SOA的主流中间件，例如，SOME/IP等，都是基于IP协议通信的。

E/E架构方案

当前的E/E架构主要有集中功能域、跨域融合、整车集中+区域控制三种方案，分别如下：

（1）集中功能域方案
每个功能域设置一个域控制器，域控制器之间通过以太网和CANFD相连。域控制器分为性能型和集中型两类。性能型域控制器主要指信息娱乐域控制器和自动驾驶域控制器。该域控制器需要处理大量的数据，需要较大的数据处理能力。由于该控制处理数据庞大，域控制器方式相对于分布式架构，实现相同性能下可降低成本。集中式域控制器主要是指动力总成域、底盘域和车身域的 控制，该部分对算力要求较低，主要涉及的还是控制指令计算和通讯资源。

（2)跨域融合方案
为了进一步提升性能，满足协同执行又减少成本，跨域融合集中化方案应用而生,即将两个或者多个集成型域控制器合并为一个域控制器。比如动力域和底盘域的合并、车身域与信息娱乐域的合并。

（3)整车集中+区域控制方案
车中只有一个中央计算平台，区域控制器受中央计算平台统一管理。区域控制器以物理区域来定义的控制器，可就近布置线束，减少线束成本。分布式控制器集成，可以减少通信接口；能进一步提升算力利用率、减少算力设计总需求；同时数据能够更好的融合，统一交互，实现整车功能协同。在中间发展阶段，可能会出现由多个计算平台如(3个计算平台)向一个中央计算平台过渡的过程。未来云平台会作为中央计算平台的补充，完成部分实时性要求不高的计算。
各家OEM整体按照E/E架构发展趋势在规划相应的架构，如长城的3.X、4.0和5.0平台架构。

SOA在汽车上的应用

SOA在汽车上的应用，建立在芯片处理能力和操作系统的支持之上。

芯片算力

在分布式EEA架构中，各个ECU只连接特定的传感器和执行器，ECU的主要工作是提供I/O资源和网络接口，并进行实时控制。即使ECU需要运行操作系统，一般也是短小精悍的实时操作系统，ECU并不需要特别强大的算力和巨大的存储空间，使用普通的车规级MCU芯片即可满足需求。当EEA发展到第3阶段时开始使用DCU对某一个功能域进行集中控制，也是从这个阶段开始，DCU对于芯片算力的需求有了大幅度的提升。

以娱乐功能为例，最早就是简单的收音机或者CD播放器，并且都是实体按键操作。后来用触摸液晶屏进行HMI显示和操作，同时功能不断增加（视频播放、蓝牙音乐及电话、导航、语音控制、倒车影像等），这使得对娱乐主机MCU的数据处理能力和软硬件资源调度能力的要求不断提高，不仅MCU提高到32位，还增加了GPU进行图像处理及运行类似于android这样的非实时性嵌入式操作系统，以便有效分配系统资源，对各种任务调度管理。

等发展到了信息娱乐功能由智能座舱DCU集中控制阶段，除了以上娱乐功能之外，DCU还将组合仪表、HUD、氛围灯控制、DMS（驾驶员监测系统）、行车视频记录等功能进行集中控制。此外，智能网联汽车还需要与外界进行海量的数据交互。智能座舱DCU要求芯片的数据运算和处理能力进一步提升，并且需要多核异构的系统级芯片SOC来满足不同类型的控制和计算需求。在算力增加的同时，车规级芯片在功耗、安全和成本方面比消费电子要求更高。

综上所述，强大的车规级芯片是实现SOA的底层硬件基础。

操作系统

强大的芯片构成了实现SOA的底层硬件基础，但软件技术同样很重要。先从离硬件最近的系统软件-OS开始介绍。

在最初的分布式EEA阶段，很多ECU的功能简单，不需要OS。随着ECU功能的增加以及与外部交互接口越来越复杂，需要OS来协调管理硬件资源及进行任务调度。汽车不同功能对OS特性的要求也不同。例如，动力域和底盘域功能直接参与车辆的行驶控制，对系统控制的实时性、可靠性和安全性要求非常高，一般使用CP AUTOSAR OS（兼容OSEK OS）。又例如，对于娱乐功能，更注重OS对于应用程序的兼容性和应用生态的丰富性，对于实时性和可靠性要求可适当降低，因此，android这类OS越来越受欢迎。

到了域控制阶段，例如，在智能座舱DCU中，由于娱乐与仪表的功能安全等级不同，需要使用不同安全等级的OS，为此在DCU中引入了虚拟机管理技术(例如，AUTOSAR Hypervisor)。在虚拟机上可以同时运行两个或多个不同的OS，例如，娱乐功能使用Android，仪表功能使用QNX。感知执行层、通用控制层及计算层，不同层的能力要求不同，采用的OS也不同。一般来讲，感知执行层的ECU和通用控制层的ZCU不需要OS或采用实时性OS，确保对计算层下发的指令进行快速响应，对执行器进行实时控制。计算层的CCU硬件一般采用多核异构系统芯片（SOC），满足复杂的运算和大量的数据处理需求。CCU需要通过虚拟机技术运行多个不同类型的OS，因为不同的业务需求所适用的OS不同。例如，关键安全功能运行CP AUTOSAR OS，娱乐功能运行Linux或Android等。

AUTOSAR：

AUTOSAR的设计理念和思路都着眼于汽车系统的基本软件要求，并努力做到向前和向后的系统兼容性。AUTOSAR将SOA设计融入到了它的方法论中，对最终的软件产品提供了标准化的服务设计和实现方式。当然，SOA的实现方式可以多种多样，AUTOSAR只是其中一种可选的方式，它是否能成为最适合SOA的软件架构还需要时间的检验，但仅从当前来看，AUTOSAR是相对完整并具备可操作性的SOA软件架构解决方案。

AUTOSAR分为Classic AUTOSAR(CP）和Adaptive AUTOSAR(AP)。AP是在CP的基础上发展而来。CP一般应用于对实时性、安全性和可靠性要求高的嵌入式ECU，AP一般应用于需要高算力的多核异构中央计算单元（CCU）。