一文聊聊智能汽车中SOA架构设计方法

一文聊聊智能汽车中SOA架构设计方法
2023-1-31 18:21:24 Author: 谈思实验室(查看原文) 阅读量:16 收藏

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

什么是SOA

SOA（面向服务的架构）可以理解为一种架构设计方法，它是将一个系统所具有的能力抽象成可调用的并具有标准接口的服务，从而可以通过调用服务或者调用多个服务的组合来满足系统的业务需求。

SOA并不是某一种具体的技术实现，而是一种系统架构的设计思想。SOA的提出是为了解决随着面临的问题越来越复杂，软件系统变得难以维护、难以扩展、容易出错等问题。

SOA也是一种软件架构设计方案，它用以组织和运用分散在系统不同部分的能力(capabilities)。能力与运用能力，概念上有所差别。需求与能力可以独立于 SOA 而存在。

在SOA架构中，服务是更高效地利用现有能力满足需求的一种手段，这也是SOA的意义。

为什么汽车上要应用SOA

SOA在IT领域已经存在很久，究竟是什么原因促使SOA应用在汽车上呢？

对于任何一个系统来说，外部对系统的“需求”和系统本身具备的“能力”是决定如何设计系统的2个最关键的因素。

能力越强则可以满足更多的需求，但能力越强也意味着需要耗费更多的资源。资源从来都是有限和稀缺的，但需求却不断地增加和快速地变化。有限的资源和能力与无限的需求之间的矛盾是系统设计面临的最大挑战。

对于任何一个盈利性组织来讲，在设计开发汽车电气系统时，如何用相同的能力满足更多的需求，如何用更少的能力满足相同的需求，如何用现有的能力更快速地、更好地满足不断增长的复杂多变的需求，这是促使SOA设计思想和设计方法应用在汽车上的最本质原因。

如何实现SOA

汽车EEA的发展使SOA具备了初步的应用条件

汽车EEA从分布式逐步向集中式发展。从整车厂的角度，这种趋势背后的最大驱动力也是为了更好地解决能力与需求的结合和匹配问题。

所谓分布式EEA，可以理解为汽车电气系统的软硬件资源和能力是分散的，分散在不同的供应商手中。ECU的软硬件开发全部由供应商完成，整车厂主要负责提出设计需求和测试验证。

分布式EEA导致的ECU软硬件资源和能力的浪费是显而易见的。不同的供应商负责不同的ECU开发，整车数十个ECU分别负责实现特定的软硬件功能，然后通过硬线信号或者网络信号进行交互，这种信息交互方式也被称为面向信号的通信。

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

1）在局部子系统做一些简单的物理集成。例如，在三电系统，将DCDC和OBC整合为一个ECU，外壳和接插件可以共用（资源的利用率得到提升），但内部还是两个独立的控制器，分别具有各自的PCB和软硬件资源。

2）在局部子系统做一些功能集成。例如，在车身控制系统，将BCM、PEPS、TPMS实现的功能通过一个ECU来实现。外壳、接插件、PCB可以共用，软硬件资源也可以部分共享，相对于物理集成，功能集成进一步提高了资源的利用率。

3）将某个功能域的大部分或全部功能通过域控制单元进行集中控制。比较典型的功能域划分方式将整车分为5个域：动力域、底盘域、车身控制域、智能座舱域和智能驾驶域（包括ADAS和AD）。

4）功能域的进一步融合，整车由几个核心计算单元进行集中控制。例如，特斯拉的整车电气系统主要由autopilot+MCU(智能驾驶+多媒体)、左车身控制和右车身控制三个核心计算单元进行集中控制。华为的智能驾驶、智能座舱和整车控制器三个核心计算单元。

5）终极EEA形态：整车电气系统由一个中央计算单元进行集中控制。

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

从第3阶段开始，EEA才算是进入了集中式控制阶段。分布式与集中式控制的本质区别在于，分布式阶段的整车功能是围绕一个个ECU作为主体进行设计的，而集中式阶段则需要从子系统甚至整车的软硬件资源所具备的不同能力的角度，对功能实现进行分层设计，核心思想是不同的层面具备不同的能力，其主要目的是软硬件资源和能力的解耦。

可以粗略地将整车软硬件资源所具备的能力分为3类：计算能力、通用控制能力和感知执行能力，并将这3种能力分别对应到计算层、通用控制层和感知执行层。

在第3阶段，将某个功能域的计算能力集中到DCU（域控制单元）中，通用控制和感知执行能力由各个功能域中的下层ECU实现。

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

在SOA架构中，服务是更高效地利用现有能力满足需求的一种手段，而汽车电气系统的所具备的最基础的能力是由所具备的传感器和执行器的类型和数量决定的，也可以理解为由最底层的硬件资源所决定的，因此在汽车上应用SOA的一个重要前提是实现业务需求与硬件资源的解耦。

当EEA发展到第3阶段时，即引入DCU集中控制某个功能域时，汽车上开始具备了实现SOA的条件。

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

多项关键技术共同促进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的底层硬件基础。

操作系统（OS）：

强大的芯片构成了实现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：

在介绍了芯片和OS之后，接下来以AUTOSAR为例，介绍SOA的软件架构如何设计。

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

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

图1 CP AUTOSAR

图2 AP AUTOSAR

CP的通信协议基于在系统运行前的静态预配置的基于信号的规范，而AP基于面向服务的通信，允许动态启动通信。即在CP中，运行时的服务必须在编译时处理确定的，而AP支持运行时服务的动态注册。AP支持的应用程序动态调度策略，它允许在运行时动态部署应用程序。

SOA的软件架构设计离不开服务模型的设计。针对服务组件，SOA定义了服务组件的架构模型SCA（SCA，Service Component Architecture），模型中的主要元素分为“服务接口”和“服务实现”两大类。

表1 AP的SCA模型描述

AP采用经典的代理(Proxy)-框架(Skeleton)模式来完成SCA模型的描述。这种模式将直接交互的客户端(Client)和服务端(Server)分离，由代理负责传递信息来完成服务调用，客户端和服务端不需要处理通信层详细信息。

服务组件由服务单元提供的“业务逻辑”和适配目标系统环境相关的“基础设施逻辑”两部分组成。在开发过程中，这两部分是解耦的，可同时进行的，且软件形态是灵活的。

服务单元的逻辑可以是源码或被封装为SDK形式，且不关心具体的编程语言；基础设施逻辑 (Interface和Message) 则以C++的形态编码，与服务管理中间件一起确保服务的动态响应性和服务自身的可扩展性，其软件形态同样可以是源码或SDK形式提供。

在流程上方法论上，”实现和部署”工作主要分为服务组件接口设计，服务组件集成实现和安装部署3个步骤：

1、组件接口设计阶段: 编写arxml完成对服务组件SCA中“基础设施逻辑”的配置开发，并经由AP中间件供应商提供的代码框架和生成器(Generator)，最终得到相关的配置文件(.json)和源代码(.cc/.cpp)；对“服务单元逻辑”，可同步基于建模工具进行开发；

2、组件集成实现阶段: 编写APP框架，完成“服务单元逻辑”与“基础设施逻辑”的软件集成工作；

3、组件安装部署阶段: 编写编译和安装脚本，完成源码的编译链接和可执行文件(App)的安装，同时，对APP安装部署权限和系统环境做适配调整。

表2 服务组件的设计和部署

SOME/IP:

SOME/IP (Scalable Service-Oriented MiddlewarE Over IP) ，即“运行于IP之上的可伸缩的面向服务的中间件”。“中间件”是一种独立的系统软件或服务程序，SOA软件架构中的“服务”可借助中间件在不同的软件平台或操作系统之间共享资源。

SOME/IP属于应用层协议，它提供面向服务的通讯接口。SOME/IP定义的服务接口包含方法（Methods），事件（Events），字段（Fields）和事件组（Eventgroups），可以支持请求/响应模式的远程服务调用，也可以支持订阅/发布模式的消息通知。

图3 车载以太网协议

服务是SOME/IP的最核心概念，在一个服务中，定义了服务端（Server）和客户端（Client）两个角色：服务端提供服务，客户端调用服务。对于同一个服务，只能存在一个服务端，但可以同时存在多个客户端调用服务，一个服务由Method/EventField组成。

SOME/IP的访问方式分为事件通知（Notification）、远程过程调用（Remote Procedure Call，RPC）和访问进程数据（Getter、Setter）3种。事件通知与传统CAN通信消息类似，服务端周期性或者事件变化时向客户端发送特定消息。远程过程调用是当客户端有请求的时候，向服务端发送一个请求消息，服务端根据情况返回响应。访问进程数据可以使客户向服务器端写入（Setter）或者读取（Getter）数据。

SOME/IP数据包括2部分，分别是Header和Data。在传输的过程中可以通过TCP和UDP两种通信数据协议进行传输。SOME/IP定义的通信方式主要包括4类：

1. Method: 包含了请求后有应答的Method，和请求后没有应答的Method（Fire&Forget）。

2. Event：当某种事情发生后，服务端向客户端发送的报文。

3. Field：Get/Set/Notifier某种属性或者状态。

4. EventGroup：用来进行publish/subscribe处理Eventsand Fields的通信的逻辑组。

SOME/IP定义了其服务发现协议SOME/IP-SD，用于动态发现服务的提供者地址以及检查服务状态是否健康。SOME/IP-SD的报文通过UDP发送，每个设备通过在局域网中周期性地广播一条包含其提供的所有服务的OfferService报文来帮助其他设备完成服务发现（服务IP，端口等信息）。服务调用者也可以通过广播一条FindService消息来主动查询自己需要的服务。

SOME/IP中与数据通信相关的一些术语定义如下：

1. Request/Response：客户端向服务端请求特定的报文，然后服务端将相应的数据报文返回给客户端。

2. Fire&Forget：客户端调用服务端Method的报文，通过请求完成Method远程调用；

3. Notification：对应Event接口类型，类似CAN报文，在特定的事件触发下，服务端会发给客户端一个notification报文主要包括Cyclic事件、数据Changed等；

4. Publish/Subscribe：主要用于SOME/IP的SD（服务发现），客户端首先订阅相关的服务，只有订阅成功后，才允许进行Notification通信。

5. Field：一个可被远程访问的属性。主要包含三种类型的数据通信Getter、Setter和Notifier。其中Getter读取属性值，请求报文的payload为空，响应报文中含有当前属性值；Setter设置属性值，将预设值置于请求报文的payload中，属性的设置结果放于响应报文中，Notifier类似于Event，Notifier在订阅完成后，会立即发送Initial Event，通知当前值。

强大的车规级芯片是实现SOA软件架构的底层硬件基础。

操作系统是离底层硬件最近的系统软件，它负责为应用软件协调管理硬件资源并进行多任务的切换和调度。

AUTOSAR本质上是一种软件设计的方法论，它为具体如何实现SOA的软件架构提供了标准化的服务设计和实现方式。例如，AUTOSAR定义了为了运行AP的应用程序，操作系统需要具备POSIX标准库接口，操作系统应通过在启动和运行时的动态调度和通信路径的动态配置来支持应用程序的动态行为。

SOME/IP是一种中间层协议，是实现SOA的面向服务通信的一种具体的技术实现方式。AUTOSAR将SOME/IP也融入到了它的方法论中，例如，规定CP只能支持SOME/IP协议，而AP可以运行SOME/IP，也支持HTTP协议，AP后续还会增加其他协议。CP仅支持静态SOME/IP服务交互机制，而AP可以支持静态和动态SOME/IP服务交互机制。SOME/IP在AUTOSAR中的实现主要包括与SD相关的配置和数据通信协议相关模块的配置。

正如SOA的软件架构实现方式不是唯一的（AUTOSAR只是其中一种可选的方式），SOA软件架构下的通信协议也是多元化的，任何基于服务机制的协议均可以认为是SOA通信协议。在汽车上，应用比较广泛的主要是SOME/IP、HTTP、MQTT协议，其中SOME/IP满足车规要求，用于车内节点之间的服务通信，而HTTP和MQTT承接于互联网，多运用于无线网络，以便于车内节点和云端交互，但也可以用于车内有线以太网。

技术是手段，不是目的

在汽车产业重构期，诸多的新技术不断涌现，整车厂的核心能力到底是什么？

不管是对于企业还是个人，能力和资源都是有限的，必须集中有限的资源做自己应该做的事。

整车厂之所以为整车厂，就是因为它必须对最终生产出来的车辆负责，它必须对客户的用车体验负责。在软件定义汽车的时代，不断提升客户的用车体验也是整车厂的生存之本。

SOA只是诸多应用在汽车上的新技术之一，整车厂的核心能力应该是掌握有效应用这些新技术的集成能力，而有效应用新技术必须以深入理解目标客户的用车需求为前提，其最终的目的就是提升客户的用车体验。

对于SOA在汽车上的应用而言，服务设计才是整车厂的核心能力，因为车辆能够提供服务的好坏决定了用户体验，并且服务设计必须针对目标客户的用车需求来完成。

这篇文章从服务设计的角度介绍SOA。

智能汽车的本质属性并不是功能的多少，因为功能再多也只是一个静态的概念。静态意味着一旦功能设计完成，汽车能够完成的任务是固定的。

一个功能的实现可以分为输入、处理逻辑和输出三个部分。功能设计完成后，它只能根据特定的输入、特定的处理逻辑和特定的输出控制来完成固定的任务，也可以理解为向客户提供特定的用车服务，满足客户的用车需求。

为什么是SOA（面向服务的架构）而不是FOA（面向功能的架构）？服务和功能到底有什么区别和联系？

笔者认为，服务和功能这两个概念从完成任务的实现方式（输入、处理逻辑、输出）来讲，并没有本质区别。

之所以使用服务这个概念，相对于传统的功能而言，主要是为了突出智能汽车在完成各种任务时所体现的灵活性、主动性以及预测性，也是就可以根据不同用车场景动态地调整完成任务的方式。

汽车是由各种配置（偏重于硬件）和服务（偏重于软件）组成的。配置的高低决定了车辆的下限，而服务的好坏则决定了车辆的上限。

在特定的时间和空间中，当一个或多个事件发生时，对于车辆而言就形成了我们通常所说的用车场景。

真正意义上的智能汽车是能够更有效地识别用车场景甚至预测用车场景，并且主动通过各种服务来满足客户用车需求的汽车。这里的核心词是“主动”，智能的本质就是具有自主性甚至预测性，并且这种“自主性”和“预测性”的能力也能够在不断的自我进化中得到提升，越来越好地满足用车需求。

基于以上对于智能汽车所提供服务的理解，我们在设计SOA服务时可以将服务分为以下3类：

1、场景感知类服务：

这类服务主要用于用车场景的感知，即对时间、空间以及发生事件的感知。

时间感知服务：例如，车辆通过4G网络获取时间信息；

空间感知服务：例如，车辆通过GPS天线获取位置信息；

事件感知类服务：例如，车辆上电感知，车辆换挡感知，环境温度感知、驾驶员表情感知、驾驶员视线感知；

场景感知服务主要是基于车辆硬件配置来实现的。

从服务与功能的关系来理解，场景感知类服务属于基础服务，可以等同于传统的感知类功能。

2、控制决策类服务：

这类服务是造就智能汽车的核心服务。它根据场景感知类服务以及用户操作所提供的各种输入，经过分析和计算，最终决定车辆应该以何种方式满足客户的用车需求。

既然智能汽车的本质属性是具有主动性和预测性，那么对于控制决策类服务而言，能多大程度地减少对于用户操作输入的依赖，能多大程度地充分利用场景感知类服务输入，并将各种输入通过强大的算力进行综合分析计算，完成最终的控制决策过程，这是判断控制决策类服务智能化程度高低的依据。

例如：

氛围灯的颜色可以根据用户心情自主调节。

用户吃饭的餐厅可以根据用户的口味、综合最新的餐厅优惠折扣活动自主推荐。

温度、湿度、空气质量可以根据用户身体状态、当前天气情况自主调节。

控制决策类服务依赖于算法和控制策略，并且这种算法和控制策略自身也可以不断进化，它主要是基于软件来实现。从服务与功能的关系来理解，控制决策类服务属于高级服务，它可以理解为一种具备自主性的高级功能，它可以灵活调用和组合基础服务完成不同的任务，满足不同场景的用车需求。

3、动作执行类服务：

这类服务主要是用于控制车辆执行各种动作，包括所有用户可以感知到的声音，文字、图像、电机动作等等。

动作执行类服务主要是基于整车硬件配置来实现的。从服务与功能的关系来理解，动作执行类服务也属于基础服务，可以等同于传统的动作执行类功能。

在之前的文章“SOA在汽车上的应用(1)-(3)”中，笔者介绍了SOA是什么，为什么要应用SOA、如何实现SOA以及如何设计SOA服务。

这篇文章继续介绍如何来设计SOA服务。

服务是更高效地利用车辆能力满足需求的一种手段，那么设计服务必然是从车辆所具有能力入手。

车辆电气功能的实现需要输入、处理、输出三个过程，它们对应车辆的三种能力：感知能力（提供信息输入），计算控制能力（对信息进行处理）、执行能力（实现输出的结果）。

笔者曾将车辆的软硬件资源所具备的能力分为3类：计算能力、通用控制能力和感知执行能力，并将这3种能力根据EEA发展的5个阶段，分别对应到计算层、通用控制层和感知执行层。

感知和执行能力取决于车辆具备的传感器和执行器硬件配置，它们是车辆最底层的能力，这些能力可以被抽象为SOA原子服务。

这里的“原子”有2个含义，1个是底层（对应集中式EEA的感知执行层）的意思，可以理解为最基础的服务；1个是不可再分的意思，即原子服务是最小颗粒度的服务，可以通过组合调用1个或多个原子服务形成高层级的（通用控制层和计算层）服务。

既然感知和执行能力是车辆的基础能力，在设计原子服务时，我们可以从传感器和执行器入手，分析所需要的原子服务。

例如，对于车身控制类服务，可以基于不同的执行器（电动车门、电动车窗、电动门锁等）设计原子服务，也可以基于不同的传感器（门状态开关、车窗位置传感器、门锁状态开关）设计原子服务。

这里需要注意，原子服务虽然是最底层和最小颗粒度的服务，但原子服务也是一种服务，设计服务的目的是为了满足实际的需求，而不是机械化地将原子服务等同于车辆最底层的感知和执行能力。

车辆的传感器和执行器数量庞大，且其类型、接口和参数也种类繁多。

例如，对于仅仅一个HVAC电气系统来说，传感器和执行器类型涉及温度传感器、压力传感器、湿度传感器、光线传感器、水泵电机、电动压缩机、PTC加热器、电磁阀、电子膨胀阀、冷却风扇、风门电机、鼓风机等；设备接口涉及数字输入、模拟输入、高端驱动、低端驱动、CAN、LIN等；设备参数涉及电压、电流、压力、温度、位置等；

如果将车辆所有电气系统的所有传感器和执行器抽象为原子服务，不仅使原子服务的数量过于庞大，而且从实际需求的角度也是没有必要的。

对于HVAC电气系统而言，我们需要从实际需求的角度，分析可能需要哪些原子服务。

例如，获取当前车内某个区域的温度值或者设定目标温度值、开启或关闭某个区域的自动温度控制、开启或关闭通风、获取当前风量大小，设置目标风量大小、获取当前吹风模式、设置吹风模式等等；

如果要实现SOA，则需要实现原子服务与车型平台的解耦，从而提升原子服务的复用性。不同车型平台的硬件设备与驱动程序不同，这需要包括操作系统在内的广义平台系统软件来实现软件与硬件设备的解耦，屏蔽硬件设备与驱动的差异，给原子服务提供统一的API。

因此，从软硬件解耦的角度去考虑，车辆所有的硬件设备有必要抽象为标准的接口。另一方面，原子服务可能根据需求进行增加，全面的硬件设备的API接口使原子服务的设计更加灵活。

从这个角度来理解SOA的服务设计，整车厂可以参与原子服务的设计，但这并不是构建整车厂差异化竞争力的关键。

基于原子服务的组合，在不同的用车场景中构建个性化、智能化的应用，提升用车体验，这才是SOA服务设计的最终目的，也是整车厂需要掌握的核心能力。

来源：汽车电子电器架构

文章来源: http://mp.weixin.qq.com/s?__biz=MzIzOTc2OTAxMg==&mid=2247518241&idx=2&sn=5c9a3c480449b28e3dd45ea48b939607&chksm=e927ccfade5045ecbbab1b0ecb5f1c3ac6bec2b8e17f36edbb9727030d31389d0ef30257f9be#rd
如有侵权请联系:admin#unsafe.sh