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

来源：联合电子

随着汽车智能化、网联化、共享化的趋势，终端用户对车辆功能的预期也悄然发生着改变，汽车在实现高等级自动驾驶/辅助驾驶功能的同时，也更趋向于提升用户体验，例如满足快速的功能更新和升级，可以提供个性化、人性化、差异化的功能与服务等。

面向服务的软件架构(Service-Oriented Architecture)正为未来的车辆软件服务提供良好的解决方案。不同于传统汽车电子电气架构中面向信号的架构，面向服务的软件架构(SOA)通过标准化的服务接口，松耦合的服务机制以及可组合扩展的服务特性，结合未来以高性能计算平台——域控制器——为核心的集中化电子电气架构，将成为未来汽车领域“软件驱动创新”的技术基础。

第一部：面向服务架构(SOA)的汽车软件及其开发方法

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

SOA是一种软件架构，同时也是一种软件设计方法和理念，在IT领域已有数十年的应用经验。SOA具备”松耦合”、”接口标准可访问”和”易于扩展”等特点，使得开发人员能以最小的软件变更应对迭代多变的客户需求。

在智能网联汽车中，大量的功能需要控制器（ECU）间的协调工作来实现，当前ECU 间基于信号(Signal-Oriented)的点对点通讯将会变得异常复杂，且不具备灵活性和扩展性，微小的功能改动都会引起整车通讯矩阵的改动(图1)。

因此，联合电子将SOA引入到当前汽车软件设计中(图2)，车辆功能被以面向服务的设计理念架构为不同的服务组件，有别于面向信号的传统架构，SOA中的每个服务都具有唯一且独立互不影响的身份标识(ID)，并通过服务中间件(Service Middleware)完成自身的发布，对其他服务的订阅以及与其他服务的通讯工作。由此，SOA良好的解决了传统架构中因个别功能增减/变更而导致整个通讯矩阵与路由矩阵都要变更的问题。更进一步，由于其”接口标准可访问”的特性，服务组件的部署不再依赖于具体特定的操作系统和编程语言，在一定程度上实现了组件的”软硬分离”。

  

图1  面向信号的架构(Signal-Oriented Architecture)

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

二. 如何有效的开发SOA汽车软件？

对于汽车行业而言，SOA是一套新引入的技术，需要一套有效的流程、方法和工具，用以解决如下三个问题：1) 如何分析和设计服务架构，2) 如何建模和记录服务架构，3)如何部署和实现面向服务的软件。

1) 如何分析和设计面向服务的架构?

“分析和设计服务架构”的过程是从客户需求到SOA软件架构产出的分析过程，相对于传统汽车软件开发采用的基于功能分解的面向过程分析方法，“用例驱动的开发方法”和“面向服务架构的设计方法”是SOA软件架构开发的两个主要特点。

用例(Use Case)驱动的开发方法(图3)指从用户的角度而非开发人员的角度考虑功能需求和系统实现，重视从系统外部观察对系统的使用。由用例驱动的开发活动，可以建立需求和系统功能之间清晰的追溯关系，更好的应对智能网联产品需求的快速迭代更新。

面向服务的分析方法(图4)则是以业务为中心，在由用例分析得到系统功能需求的基础上，对业务逻辑进行抽象和封装，从业务角度寻找候选服务（Service Candidate），从架构角度强调服务的重用性(reusable)、自主性(autonomous)以及组合扩展性(composable)特点，充分发挥SOA设计理念的优势，而不是仅仅作为技术实现方式。

图3  用例驱动的开发方法

图4  面向服务的分析方法

2) 如何建模和记录面向服务的架构?

标准化的建模语言和统一化的文档结构，对提升架构的开发质量、实现架构内容的有效传递具有重要作用。SysML语言和Arc42模板可以作为SOA软件架构的标准语言和文档结构模板。

系统建模语言SysML（System Modeling Language）是由统一建模语言UML（Unified Modeling Language）扩展而来的标准化系统建模语言，能够准确表达系统及其组件的需求、行为、结构和属性。Rhapsody软件支持SysML建模，并提供了自动化功能，提高建模效率，同时保证与用例的追溯关系。Arc42明确定义了架构文档的结构，通过统一化的文档，提升开发团队中的信息传递效率和质量。

如下图5显示，联合电子使用SysML语言，Rhapsody建模工具以及Arc42架构模板进行应用服务架构的开发。

图5  SysML语言，Rhapsody工具和ARC42开发模板

3) 如何部署和实现面向服务的软件

“部署和实现面向服务架构的软件”的过程是以SOA软件架构为设计输入，最终开发实现出软件产品的工作过程(图6)。主要包括 1)对服务接口行为的开发和实现，完成服务接口与服务主体逻辑的绑定；2) 针对目标运行环境，完成对服务接口参数，服务主体运行参数的配置；3)服务接口与应用程序策略逻辑的集成编译。

AUTOSAR  Adaptive 组件封装了SOA软件底层的通讯细节(包括SOME/IP协议，IPC等)，同时提供代理(Proxy)-骨架(Skeleton)模型，该模型以C++面向对象语言描述，方便上层应用开发人员调用标准服务接口(API)进行开发。Application Design Model是该模型另一种可配置的呈现，开发人员通过使用相应的配置工具对Application Design Model进行描述和配置，即可实现基于SOA服务架构的软件落地和部署。联合电子使用AUTOSAR Adaptive组件完成SOA服务架构软件的开发(图7)：

图6  部署和实现面向服务的软件

图7  应用软件设计模型

三. SOA汽车软件创新平台

联合电子开发的域控制器XCU ，提供了部署SOA汽车软件的平台。在硬件方面，XCU具备高算力处理器芯片和多路车规级以太网通道；在软件方面，XCU搭载POSIX操作系统和AUTOSAR Adaptive平台。

根据SOA软件开发方法，可从两个切入点开展SOA汽车软件平台的开发。

1)自下至上，从车辆基础功能/信号出发，将已有的应用功能逻辑/信号(eg:车辆车速信息)抽象或封装成服务组件，这类组件被称为基础服务层(Basic/Platform Service Layer)组件，具有最高的可复用性和可组合性，这些组件将为上层(业务服务层Business Service Layer)的服务组件提供最基础的支持。

2)自上而下，从整车业务逻辑和用例出发，结合各领域的核心业务知识，设计业务服务层(Business Service Layer)的服务组件；同时，遵循服务组件的复用性和自主性等原则，向下设计规划基础服务层(Basic/Platform Service Layer)的服务组件(图8)。

图8  基于域控制器(XCU)的SOA服务架构

四.  SOA架构的核心要素与优势

1

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

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

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

图9：SOA架构模型

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

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

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

车辆功能可被大范围复用

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

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

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

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

第二部：面向服务架构（SOA）的汽车软件分析和设计

1

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

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

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

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

1. 系统需求分析

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

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

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

2. 系统功能分析

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

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

3. 候选服务分析

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

图14 候选服务分析聚焦SOA架构的服务接口层

4. 系统架构设计

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

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

5. 软件架构设计

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

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

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

图16软件架构设计

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

结语   

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

联合电子认为，相对于传统汽车软件开发采用的基于功能分解的面向过程的分析方法，“用例驱动的开发方法”和“面向服务架构的设计方法”是SOA软件架构开发的两个主要特点。

联合电子具备相关项目经验，可以帮助具备业务逻辑的厂商(OEM/第三方)完成基于服务的用例分析和架构设计工作，并最终协助客户输出面向服务的软件架构。

第三部：面向服务架构（SOA）的汽车软件实现和部署

根据SOA架构层级模型(图18)，业务逻辑经过面向服务架构(SOA)的软件分析和设计过程后，被分解为单个服务并绑定相应的可执行软件单元。以服务软件架构为输入，汽车服务软件的实现和部署工作主要在服务组件层(Service Components)完成(图1红色箭头)。

图 18 SOA 层级架构模型

01

满足 SOA 架构的服务组件架构

(Service-Component-Architecture)

针对服务组件，SOA定义了服务组件的架构模型(SCA)(图19)，在SCA的框架下，服务组件内部被分为业务逻辑(Service)与基础设施逻辑(Interface和Message)两部分，并互相解耦：

• 服务软件单元(Service)：业务/功能逻辑，不关心操作系统和编程语言，可由熟悉业务逻辑的相关方开发

• 接口(Interface)：决定对外提供哪些服务以及自身服务依赖哪些服务，不关心操作系统和编程语言，可由SOA架构设计方完成开发和部署

• 消息(Message)：接口数据的通讯链路/环境绑定，不关心操作系统和编程语言，可由SOA架构设计方完成开发和部署

整个服务组件层的工作是对服务组件进行规范型描述，描述内容主要包含两个部分:

1. 服务组件架构模型SCA的配置描述

2. 服务组件内部业务逻辑和基础设施逻辑的集成

图19  SOA服务组件架构模型(SCA)

02

服务组件架构SCA的配置描述

通过SCA架构模型，每个服务软件单元(Service)以标准的接口形式(Interface)向消费方提供服务内容，以统一的通讯协议传递序列化消息(Message)。对于SOA架构设计和应用人员，需要通过工具配置SCA架构模型中的参数，使其与服务管理组件一同实现SOA软件的部署和运作。

图20  SCA架构模型中的配置信息

SCA架构模型中的主要元素分为“服务接口”和“服务实现”两大类。其中，“服务接口描述”包含服务软件单元(Services)，组件接口(Interface)和消息通讯(Message)；“服务实现”则包括通讯协议绑定(Binding)和服务端口信息等(Endpoint)(图20)。

WebService的SCA架构模型配置描述

以IT行业SOA封装使用较为广泛的WebService为例，其对SCA架构模型的描述遵从如下标准协议:

表1  SCA架构模型中的配置信息

在IBM公司发布的SOA系统解决方案- 企业服务总线(Enterprise-Service-Bus)中提供了WebSphere Integration Developer开发环境，该环境支持配置生成符合WSDL规范的服务组件描述文档。

汽车软件的SCA架构模型配置描述

在汽车软件领域，当前，联合电子采用AUTOSAR Adaptive组织提供的模型描述规范。AUTOSAR Adaptive组织对SCA架构模型的描述遵循如下标准: 

表2  SCA架构模型中的配置信息

03

汽车SOA软件的实现方案

如上文所述，汽车软件领域，联合电子遵循AUTOSAR Adaptive标准来完成SOA中间件的部署和应用，AUTOSAR Adaptive组件采用经典的代理(Proxy)-框架(Skeleton)模式来完成SCA架构模型的描述(如图21)。

图21  Proxy(stub)/Skeleton架构模式

这种模式将原本直接交互的调用者(Client)与被调用者(Server)分离，由代理负责传递信息来完成调用，client和server不需要处理通信层详细信息。同时，AUTOSAR Adaptive厂商基于C++语言具体实现代理-框架模式，确保应用服务开发人员可以灵活配置自定义的服务接口，并结合对应工具生成SCA架构模型代码(.cpp/.cc)和配置文件(.json)。具体的，这些代码：

1. 封装了SOME-IP协议栈和底层通讯细节(Middleware Transport Layer)

2. 提供了相应的服务虚接口(virtual function)

通过1)，服务组件开发人员不必再关心服务Message对应的协议如何实现；通过2)，服务组件开发人员基于C++的语言特性，可继承(inherit)虚接口并覆写(override)虚接口的具体实现(函数体)。该机制保证了“基础设施逻辑”和“业务(功能)逻辑”的解耦，服务内部业务逻辑的改动不影响服务组件向外的接口提供。

04

SOA服务组件实现和部署的具体步骤

SOA服务组件“实现和部署”的整个过程以面向服务(SOA)的软件架构为输入，内容上除完成第二章提到的“基础设施逻辑”配置工作外，还需将业务(功能)逻辑与基础设施逻辑集成，最终编译成可执行的服务组件单元(Service Component)(图22)。

图22  服务组件单元(Service Component)

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

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

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

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

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

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