1 什么是SOA

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

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

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

在SOA架构中，服务是更高效地利用现有能力满足需求的一种手段，这也是SOA的意义。如需系统性学习和掌握电子电气架构(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的底层硬件基础。

2 操作系统（0S）

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

3 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）。如需系统全面学习和掌握AUTOSAR可以参考《Classic AUTOSAR & Adaptive AUTOSAR学习视频汇总》

▲CP AUTOSAR

▲AP AUTOSAR

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

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

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安装部署权限和系统环境做适配调整。

服务组件的设计和部署

4 SOME/IP

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

SOME/IP属于应用层协议，它提供面向服务的通讯接口。SOME/IP定义的服务接口包含方法（Methods），事件（Events），字段（Fields）和事件组（Event groups），可以支持请求/响应模式的远程服务调用，也可以支持订阅/发布模式的消息通知。如果您需要系统全面掌握和学习SOME/IP，可以参考学习《汽车以太网SOMEIP在线视频》《席位预约中|车载以太网培训训练营》

▲车载以太网协议

服务是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，通知当前值。

5 小结：

强大的车规级芯片是实现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在汽车上的应用

1 技术是手段，不是目的

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 场景感知类服务

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

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

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

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

场景感知服务主要是基于车辆硬件配置来实现的。从服务与功能的关系来理解，场景感知类服务属于基础服务，可以等同于传统的感知类功能。

3 控制决策类服务

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

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

例如：

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

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

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

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

4 动作执行类服务

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

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