面向服务架构的汽车软件分析和设计

本文将先重温下SOA架构的核心要素与优势，并重点讨论话题“面向服务架构（SOA）的汽车软件分析和设计”。

1.为什么要引入汽车SOA软件?

SOA作为一种面向服务的架构，是一种设计思想和方法论。在SOA架构中，服务是最核心的抽象手段和系统最基础的描述单元。

每个服务组件具备独立的功能，且可被复用；服务组件之间的接口遵循统一标准，可互相访问，可组合扩展。业务过程则是带有状态和服务调度策略的服务组件的组合与扩展(图1)。

通过SOA架构，可整合规划OEM在不同操作系统，硬件平台上(控制器)上的业务功能，实现对功能的快速迭代和重组，应对灵活多变的智能网联趋势下的业务需求。

图１ SOA架构模型

结合未来汽车域导向型电子电气架构(Domain-Oriented)和区域导向型电子电气架构(Zone-Oriented)，应用SOA架构可实现业务过程(功能)的快速迭代与灵活重组，为智能网联趋势下的软件个性化与创新需求提供了良好的平台性解决方案。SOA架构应用于汽车新电子电气架构下的优势(图2):

车辆功能软件实现软硬分离

由于服务组件接口“标准可访问”，且描述方式独立于硬件平台和操作系统，因此组件功能可脱离硬件平台任意部署移动，对于算力有要求的复杂功能组件可向具备高带宽大算力的域控制器移动。

一些使用频度很高且基础的功能可作为基础服务组件先被开发，由于服务组件的独立性以及接口的标准可访问，基础服务开发完成后可向服务中间件注册，并供所有电子电气架构中的控制器订阅使用。

车辆功能在SOP后可新增(扩展)

“小”的基础服务可组合成为“大”服务，“大”服务可进一步组合扩展并最终构建出新的业务过程，实现OEM的业务目标。结合OTA技术，用户可在车辆使用期限里，订阅一个类似，“预测性能量管理”的新功能并安装于域控制器上，新功能的业务逻辑依赖于一些已有的服务组件(eg:预测性能量管理依赖于能量管理策略，地图预测信息等基础服务)。

图2 新汽车电子电气架构中的SOA架构应用

面向服务架构的汽车软件分析与设计

面向服务架构的开发过程从整体上可以概括为6个步骤，分别是：面向服务分析、面向服务设计、服务开发、服务测试、服务部署和服务权限管理，如图3所示。其中，分析和设计面向服务的架构是开发SOA软件的开端，也是判断系统是否基于SOA架构的最重要且核心的环节。

联合电子对分析和设计面向服务架构汽车软件的具体流程与方法进行了探索，将面向服务的分析分解为系统需求分析、系统功能分析、候选服务分析三个子步骤，将面向服务的设计分解为系统架构设计和软件架构设计两个子步骤。经过架构师的良好分析，车辆功能(业务逻辑/业务过程)将结合实际实现情况，按不同业务领域完成解耦，并分解得到候选服务组件。后续，经过详细且不断迭代的设计，在候选服务的基础上，最终会产出面向服务(SOA)的软件架构。

图3 面向服务的分析与设计是服务架构开发的核心环节

接下来本文将围绕这5个子步骤对面向服务的分析与设计过程进行介绍。

如图4所示，整个SOA架构模型分为业务过程层，服务接口层和应用程序层三部分。SOA业务过程层专注于业务逻辑的分析；服务接口层聚焦于候选服务的设计和分析；应用程序层则体现面向服务的系统架构和软件架构设计。

系统需求分析聚焦SOA架构的最上层——业务层。概括来说，需求分析指的是设计和充分理解在用户具体使用场景下的真实业务过程，为后续抽象和封装服务提供充足的语境信息。

图4 需求分析聚焦SOA架构业务过程层

2. 系统功能分析

如图5所示，系统功能分析搭建起了SOA架构的业务层和服务层之间的桥梁，其过程就是从第一步系统需求分析的产物——业务过程和系统用例，向服务过渡的过程，目的是得出构成候选服务的服务操作（operation）。系统功能分析具体可描述为：设计用例的实现场景步骤，对系统用例逐个进行分析细化，描述系统如何与参与者（actor）一起实现每个用例，从而得到系统与参与者、与外部系统的界限及信息交互，最终得出对系统的功能要求，这些功能要求直接作为候选服务操作（business service operation candidates）。

图5 系统功能分析：从业务过程到服务

3. 候选服务分析

候选服务分析聚焦SOA架构的中间层——服务接口层。候选服务分析的目的是对业务逻辑进行抽象和封装，从业务角度寻找候选服务（Service Candidate）。值得强调的是，分析候选服务需要跳出特定功能开发，从架构角度强调业务的重用性(reusable)、自主性(autonomous)以及组合扩展性(composable)等特点，特别考虑候选服务在企业业务范围内潜在的重用可能，充分发挥SOA设计理念的优势，而不是仅仅作为技术实现方式(图6)。

图6 候选服务分析聚焦SOA架构的服务接口层4. 系统架构设计

系统架构设计的目的是设计和得到服务到架构要素的映射，以及要素间服务调用关系。下图中蓝色小圆圈代表分析得到的服务，通过系统架构设计，被映射至不同的架构要素( Platform A~C)(图7)。在这里，架构要素对应汽车上搭载不同控制器平台(Platform)。

图7 系统架构设计：服务与系统要素的映射

4. 软件架构设计

软件架构设计的目的是设计和得到服务（service）到服务组件（Service Component）的映射关系，过程与系统架构的设计过程类似，但需要将关注点转移到控制器内部。

在图8，SOA架构中，软件架构设计的行为发生在蓝色阴影区。软件架构的设计受到诸多因素的限制(以太网通讯Port口资源，客户具体用例场景的迭代变更等等)。总体设计思想上，高内聚，低耦合仍是设计的通用原则和架构评价的关键指标。额外需要强调的，应对智能网联软件需求迭代多变的特性，在SOA服务架构的设计中，还需强调重用性和扩展性，充分的灵活度才能以最小的软件变更应对大量的需求输入。

图9为一示意图，表达了针对某一服务Service A，有一个服务提供组件(Service Component)提供A服务，有三个服务消费组件消费服务A。

图8 软件架构设计

图9 服务与应用程序的映射

“分析和设计面向服务的架构”、“实现和部署面向服务的软件”是有效开发SOA汽车软件的关键环节， “分析和设计服务架构”的过程是从客户用例场景/需求到SOA软件架构产出的分析过程。

联合电子：面向服务架构（SOA）的汽车软件三部曲

汽车SOA架构

随着汽车新四化的趋势，现在新的汽车消费群体对车的要求也已经发生了巨大的改变，车在全面实现网联，自动驾驶，数据驱动的同时，也更趋向于直接触达用户，提升体验，服务，用户的个性化需求。同时高算力芯片，感知技术，数据智能等科技产品的引入，也需要车企突破传统的电子电气架构的枷锁。

在上一篇文章《整车电子电器的集中式发展》中，我介绍了整车电子电气架构演进的趋势和想法。本文我集中介绍一下在这种趋势下，SOA架构在整车架构设计时中核心优势。

SOA是什么

SOA(Service-Oriented Architecture) 面向服务的架构

SOA是一种软件架构，同时一种软件设计的思想，其实已经在IT领域有了很多年的发展和应用了。在SOA架构中，服务是最核心的抽象手段和系统最基础的单元。每个服务组件具备独立的功能；服务组件之间的接口遵循统一的标准，可互相访问，可组合扩展。业务过程则过程则是带有状态和服务调度策略的服务组件的组合和扩展，如下图所示。它具有，松耦合、可复用、高内聚的特点，请参考下图。

SOA Benefits

SOA将跨域跨ECU交互由“基于信号的通讯”变为“基于服务的通讯”。

• 应用服务化，使“全车智能”成为可能

服务化，各个域将自己的能力提供出来，在权限允许的情况下，供大家自由使用。

• 服务的灵活部署

SOA的一个基础，就是“服务发现”机制，即给每个服务分配一个“全局名称”，通过这个名称就可以直接找到对应的服务。

• 软件更新/升级更快速

一个功能的改变可能只需要更新/升级一个服务。

• 服务高内聚，软件易重用

一个服务往往只关注“一件事”做好。这件事需要从业务的角度进行梳理。

SOA == Some/IP?

SOME/IP: Service-Oriented MiddleWare over IP

是车载以太网通信引入的一个概念，位于OSI 7层模型的层4之上。是针对车载环境定义一套通信协议。出自AUTOSAR，可以达到屏蔽系统异构性，实现互操作的目的。它是在接收方有需求的时候才发送，这种方法的优点在于总线上不会出现过多不必要的数据，从而降低负载。该技术是SOA架构的重要支撑。

特点：

Remote Procedure Call(RPC)，远程服务调用

Service Discovery(SD)，服务发现

Publish/Subscribe(Pub/Sub)，发布订阅

Segmentation of UDP message , UDP拆组包以支持大数据传输（>1UDP Packet）

在整车电子电气架构中，某一个ECU有时会需要调用其他ECU上的一个服务，这是他们就分别扮演了Client和Server的角色，而Some/IP就是实现这种远程服务调用的接口，请参考下图

服务接口的主要分类

**Method：**一种远程过程调用，采用Request-Response机制进行通信，由Client发送远程过程调用请求Request，用于请求相关数据或者请求执行相关操作，Server收到Request，根据内容做一些操作之后，通过Response对Client的Request做出一些反馈。Method是一种可靠传输的服务接口，需要关系Request是否被送达。

**Event：**订阅-发布机制是控制事件组的交互，之后事件组是以单个Event报文进行就交互，从而向Client发送相关数据。Event是一种单向传输，无法保证数据是否被准确送达。

**Field：**Field关联三种服务接口，以组合的形式来呈现，三者对同一个数据做相关联的操作。Getter->Client主动获取相关操作的当前数据，该服务接口Request不携带任何数据

Setter->Client主动设置相关操作的数据，同时Server要将Client设置的数据通过Response反馈给Client，以便Client确认设置的数据是否成功。Notification->通信行为和Event极为类似，也遵循订阅-发布机制，以事件组的形式来订阅，但所发布的数据和Getter/Setter是同一套。

三个方法的过程请参考下图

基于总线 VS SOA

• 当前车企整车软件大多是基于AUTOSAR架构开发的，它是一种面向信号的架构，一个模块会不停的在总线上发送信息给另一个控制器。

• SOA是面向服务的架构，通过标准化的服务接口，松耦合的服务机制及可扩展性的服务特性，结合未来以高性能计算平台“域控制器”为核心的集中化电子电器架构，将成为未来汽车领域“软件定义汽车”，“科技驱动创新”“数据驱动服务”的技术基础，对比图如下。

SOA中的角色

**服务（Service）:

**提供某种功能的函数或方法，是一个离散的功能单元，可以远程访问并独立执行和更新。

**服务接口（Service Interface）：

**能够被外界模块调用的函数名称或一个封装AP。

**服务提供者（Service Provider）：

**实现服务功能（包含控制算法，功能逻辑等）的一方。

**服务使用者（Service Consumer）:

**使用服务接口，调用服务的一方。

关系图如下。

服务颗粒度如下图：

SOA场景举例

智能汽车中，大量的功能需要ECU间的协调功率来实现，当前ECU间基于信号的通讯会变得异常复杂，且不具备灵活性和扩展性，微小的功能改动都会引起整车通讯矩阵的改动，下图示例请参考。

传统CAN通信

SOA引入到汽车软件设计中，车辆功能被以面向服务的设计理念架构设计成不同的服务组件，SOA中每个服务都具有唯一的身份标识，可以完成自身的发布，对其他服务的订阅，与其他服务的通讯。由此，SOA很好的解决了传统架构中因个别功能增加/变更而导致整个通讯矩阵，上下游模块都要跟随变更的问题，下图示例请参考。

基于SOA通信

哪些传统架构中的服务和信号可以通过SOA来实现

理论上所以传统架构中的服务和信号都可以通过SOA来实现，但是目前传统的CAN，LIN等信号交互方式，网络传输稳定，问题和分析简单，工具链也更完善。因此一些跟驾驶安全相关的服务和信号还是建议使用传统的通信方式，也是目前已经规划SOA架构的车企没有完全用SOA取代传统架构的原因，下图请参考。

随着SOA更多车企引入SOA的架构方案，相信未来SOA在整车电子电气架构上的开发和应用会越来越完善。