汽车SOA开发方法和实践

在未来，智能化和网联化是汽车技术发展的核心引擎，将使能汽车领域的主要创新，包括进一步节能减排、自动驾驶和新出行方式等。智能网联汽车的功能特性多是依靠软件实现的，但传统嵌入式汽车软件开发方法，难以支撑汽车软件规模和复杂度的指数级增长。汽车产业也在从 IT 技术领域引入先进技术，其中面向服务架构（SOA）被认为是能够支持未来汽车软件发展的核心技术之一。

面向服务架构软件是一种软件设计模式，自 20 世纪 90 年代被提出后，在 IT 技术领域获得了快速发展和广泛应用。SOA 具有松耦合、可重用、易集成等优点，能够支持智能网联汽车软件发展的需求，AUTOSAR Adaptive 平台也提供了 SOA 软件在汽车中实施的技术方案。在现有文献中，关于 SOA 软件开发方法的研究多集中在 IT 业务领域，在汽车领域的研究多以技术实现或个别开发案例为主，少有对 SOA 汽车软件开发方法的探讨。

SOA 不仅是一种软件实现技术，更重要的是一种软件设计模式，只有采用合适开发方法，才能有效发挥 SOA 的优势。本文讨论 SOA 汽车软件的开发方法，并付诸实践：第一部分提出一种 SOA 汽车软件分层模型；第二部分基于分层模型，介绍两种 SOA 汽车软件开发方法；第三部分相应介绍基于两种方法的开发实践；第四部分介绍 SOA 汽车软件在域控制器上的部署；最后进行总结。

在术语中，将客户的特定需求称之为业务需求，将描述业务需求的一种形式称为业务用例，将业务用例的实现过程称为业务过程，将业务过程中完成特定任务的一部分逻辑称为业务逻辑。在面向服务架构中，“服务”是对业务逻辑的封装，具有明确定义的接口，并被独立的实现；“面向服务”定义了一种方法，这种方法通过连接多个“服务”实现业务需求。

“服务”所封装业务逻辑的大小，决定了“服务” 在业务过程中涉及的范围，直接决定了“服务”的自治、重用等关键特性，是 SOA 架构设计的核心问题。在 SOA 汽车软件设计中，必须有清晰的模型作为依据，才能有效地发挥 SOA 的优势。参考 IT 领域良好实践，本文提出一种 SOA 汽车软件分层模型，如图 1，包括元服务、基础服务和应用服务三个层级，使不同层级的“服务”分别对应不同层级的汽车业务逻辑。 

图 1 SOA 汽车软件分层模型

1）元服务

元服务是最小单元。从业务角度，元服务是对底层逻辑的封装，不具有再拆分的意义和价值；从架构角度，元服务是高度通用、高度自治和可重用的功能单元，构建了整个 SOA 架构的底层基础结构。汽车的传感器、执行器等基本接口和车辆基本参数可封装为元服务，例如，将车速、车辆惯性状态等参数封装为“车辆状态”元服务，可以对上层服务架构提供支持。

2）基础服务

基础服务是分层模型的中间层服务。从业务角度，基础服务封装了更多的业务逻辑，即组合了若干元服务；从架构角度，基础服务可以访问和调用元服 务以实现更大范围的业务过程。基础服务应是足够自治和可重用的。在利用元服务的基础上，可重用的汽车业务逻辑可封装为基础服务，例如，在利用自车车辆状态服务、雷达等传感器信息服务以及其他信 息的基础上，可构建“环境信息融合”服务，作为基础服务。

3）应用服务

应用服务是分层模型的最顶层服务。从业务过程角度，应用服务可以包括一个业务过程的全部业务逻辑，封装了与特定业务有关的基础服务；从架构 角度，应用服务可以访问和调用基础服务以帮助其解决业务问题。元服务和基础服务更强调架构的灵活性，而应用服务则更强调商业意义，和业务需求有非常紧密的联系。具有客户价值的业务用例可作为应用服务，例如，“能量预测管理”是一个应用服务，它利用车辆状态元服务、环境信息融合基础服务和其他服务，从而实现了通过智能管理降低车辆能耗这一具有商业意义的业务需求。

在设计中，上层服务调用下层服务，下层服务不调用上层服务，这一原则有助于构建清晰简单的 SOA 汽车软件架构。参考以上分层模型，可以有效定义 SOA 汽车软件的开发方法，从而有效地发挥和获得 SOA 的优势。

基于 SOA 汽车软件分层模型，结合汽车领域软件开发的工程实际，可定义 SOA 汽车软件开发方法，典型的有“业务驱动型”的开发方法和“平台驱动 型”的开发方法，两种方法适用于不同的应用场景。

2.1 业务驱动型开发方法

业务驱动型指从业务用例出发，以服务为导向，正向设计 SOA 汽车软件的开发方法。此方法应用于业务用例已知，需要设计 SOA 汽车软件以实现业务用例的开发场景。在设计过程中，通过“业务过程分析”、“服务操作分析”、“候选服务分析”三个步骤，解决“应该构建哪些服务？”、“每个服务应该封装什么逻辑？”两个核心问题。

1）业务过程分析

业务过程分析指的是充分理解具体使用场景下的真实业务过程。本文采用了用例驱动的方法来分析业务需求和过程。用例驱动指从用户使用的角度而非开发人员的角度考量功能需求和系统实现，重视从系统外部观察对系统的使用。由用例驱动的开发活动，可以建立需求和服务操作之间清晰的追溯关系，为抽象和封装服务提供充足的语境信息。 

2）服务操作分析

服务封装的业务逻辑，由服务操作实现。服务操作代表了服务所执行的特定动作，可类比软件中的方法或函数。面向服务的分析包括了识别候选服务 操作并将其分组的过程，这些组最终成为候选服务，我们将这个过程抽象为服务操作分析和候选服务分析两个步骤。

服务操作分析是从业务过程分析的产物向服务过渡的过程，目的是得出构成候选服务的服务操作。服务操作分析具体可描述为：对系统用例逐个进行分析细化，描述系统如何与参与者一起实现每个用例，从而得到系统与参与者、与外部系统的界限及信息交互，最终得出对系统的功能要求，这些功能要求是系统必须实现的功能点，在下一步将直接作为组成服务的候选服务操作。 

3）候选服务分析

候选服务分析的目的是对业务逻辑进行抽象和封装，从业务角度寻找最优的服务操作划分方式，所提出的“SOA 汽车软件分层模型”为候选服务分析提供了有价值的参考。根据重用性和自主性的面向服务设计原则，参考图 1 三层模型设计元服务和基础服务。对元服务和基础服务的设计，SOA 鼓励即使没有立即重用的要求，也要根据服务导向的设计原则促进重用，因此潜在的重用也要考虑在内。通过良好的 SOA 设计，当业务用例增加，或原有业务用例发生变更时，良好的基础服务和元服务设计，保证了重用性和较少的软件变更，从而实现更快速高效的功能迭代和清晰明确的版本管理。

图 2 业务驱动型开发过程

2.2 平台驱动型开发方法

平台驱动指从汽车已开发完成的物理逻辑出发，将物理逻辑封装为元服务，也可将部分元服务进一步组合为基础服务。平台驱动型开发方法适用于如下场景，即业务用例尚不十分明确，但需建立 SOA 汽车软件基础平台，以支持潜在应用服务的快速引入，利于未来快速软件创新。在实施平台驱动型开发方法过程中，通常需要对汽车物理逻辑进行收集，并根据物理逻辑的潜在 服务价值，优先选取潜在服务价值较大的部分，将其封装为元服务，并适当组成基础服务。在未来应用服务构建时，可利用已构建的元服务和基础服 务，实现快速的软件创新。基于平台驱动型开发方法，可提供车辆软件系统的开放性，最终实现汽车的“操作系统”。

在实际汽车软件工程开发领域，以上所述业务驱动型和平台驱动型开发方法均有应用需求。本章分别描述基于以上两种开发方法的 SOA 汽车软件开发实践。

3.1 业务驱动型开发方法实践

图 3 业务过程分析案例

图 3 展示了一个业务过程分析的例子：以一辆混合动力的汽车为例，终端消费者的期望是提高驾驶经济性，这是一个长期目标，需求分析人员针对该 目标，挖掘消费者的使用场景，结合该车混合动力的特点，发现了在驾驶过程中优化动力来源分配策略这一短期目标，通过短期目标的累积最终实现长期经济性目标的整车需求。功能开发人员针对该需求提出了融合网联提供的前方道路信息和历史数据信息对汽车动力来源进行预测性优化的解决方案。

首先进行业务过程分析：在充分理解该方案提出的问题背景下，采用用例驱动的方法，分析和设计了该方案的业务过程，得到了系统用例。接下来进行服务操作分析，对系统用例逐个进行分析细化，描述系统如何与参与者一起实现每个用例，从而得到系统与参与者、与外部系统的界限及信息交互，最终得出对系统的功能要求，这些功能要求直接作为候选服务操作。图 4 展示了对“确定导航路径”这一系统用例的分析示例。

图 4 服务操作分析案例

最后进行候选服务分析。图 5 展现了一个案例，在得出候选服务操作的基础上，初步抽象出了候选服务，并定义了每个候选服务应具有的服务操作。综 合实际业务情况等多方面因素，运用面向服务的重用性等原则进行综合分析，我们对这些初步候选服务进行了多次评估和调整，得到了如图 5 右半部分所示的候选服务。

图 5 候选服务分析

3.2 平台驱动型开发方法实践

在实际工程实践中，面向客户需求的业务用例往往不是一次性开发出来的，而整车架构必须事先布局，以使未来业务用例明确时，软件能够快速构建，以在有限的时间窗口内进入市场，实现更大的商业价值。因此，平台驱动型的开发方法是必要的。

如下是一个平台驱动型开发方法的实践。

图 6 平台驱动型开发方法实践案例

如图 6 所示，通过对已存在的车辆物理逻辑及其潜在服务价值的分析，认为电池管理系统 （Battery Management System, BMS） 电池剩余电量 （State of Charge, SoC）、电池均衡状态、电池高压互锁状态等信息具有潜在的应用价值，未来基于这些信息可构建多种有商业价值的业务用例，因此，将这些信息构建为元服务。在进一步整合封装后，形成“BMS 电池状态”的基础服务，同理，经过同样的评估，可得到如下基础服务内容：

1）BMS 电池状态服务

2）整车热管理服务

3）车辆动力系统驱动服务

在完成上述基础服务单元后，业务逻辑可被进一步灵活拓展。BMS 电池状态服务可与车辆动力系统驱动服务进一步扩展结合，组建优化电池充电曲 线的应用服务。同样，随着未来业务场景的不断清晰，这些有潜在价值的基础服务与元服务，可以不断扩展、组合，灵活的应对业务需求的迭代更新。

4.1 SOA 汽车软件的部署平台

随着汽车电子电气架构向集中化发展，域控制器将成为部署 SOA 汽车软件的最优选择，其原因如下: 

1）域控制器采用多核微处理器并搭载多进程 （RichOS）操作系统，其高算力、多线程、可并发运行于多核处理器的特性使大量边缘触发型的数据处理功能在汽车软件中得以实现，而边缘触发逻辑是 SOA 软件部署的重要特性之一。

2）域控制器平台间通过以太网进行数据传输，高带宽赋能了基于以太网的、面向服务的通讯机制，让 SOA 软件的跨域合作成为可能。

3）域控制器平台可搭载 AUTOSAR Adaptive 中间件，保证了应用软件可以直接调用 AUTOSAR 组织提供的公共标准的接口（ARA::API），代表应用软件不再需要为不同操作系统的不同接口做适配和变更，从而使得 SOA 软件“软硬分离”的特性得以实现。

4.2 SOA 汽车软件的部署方法

AUTOSAR Adaptive（AP）作为 AUTOSAR 组织发布的面向 POSIX 操作系统的标准中间件，提供 SOA 汽车软件部署的整体解决方案。AP 中的 Communication Middleware（CM）组件实现了服务中间件的功能，服务中间件解耦了服务接收方和发送方，并与服务接收、发送方一起，实现服务的注册，订阅，提供和查找功能；同时，AUTOSAR 组织定义了基于 ARXML 文件的服务架构模型（SCA – Service Component Architecture）描述规范，该规范描述了图 7 中 SCA 中接口和消息的部分，并提供对于这些描述文件的代码生成工具。当前，我们将 AP 中间件集 成于联合汽车电子有限公司开发的域控制器（XCU）平台，并使用 AP 中间件，完成 SOA 汽车软件的实现和部署。

图 7 服务组件内部结构

无论是元服务、基础服务还是应用服务，都具备接口标准可访问、自治、可组合扩展等特性。这些特性源于 SOA 汽车软件的架构模型。

SCA 将服务组件划分为业务逻辑、服务接口和服务消息三个部分，并确保三者相互独立：

1）服务消息的内容取决于 SOA 软件绑定的消息机制，即通讯协议，汽车软件当前主流应用是 SOME/IP 协议，该协议栈已被集成于 AP 中的 CM 组 件单元。

2）服务接口是服务组件有别于传统软件单元的核心部分，服务接口调用消息机制，让每个服务软件对外都可以标准且相同的方式被访问。AP 提供了 基于 ARXML 的标准接口描述规范以及相应的代码生成工具，服务提供方与服务接收方以 AUTOSAR 组织标准约定的描述文档进行服务内容的交互。

3）业务逻辑展现了每个服务组件的具体功能，业务逻辑独立于消息和接口而存在，可单独进行开发，且不依赖于特定的编程语言。

设计与部署一个 SOA 汽车软件分为以下几个重要步骤。通过这些步骤，我们可以实现和部署出一个 SOA 汽车软件在域控制器平台上。

以 3.2 节 BMS 电池状态服务为例，BMS 电池状态服务为基础服务，用于提供电池包的状态信息，其由剩余电池电量、电池均衡状态以及电池包高压互 锁状态这些元服务组合而成。因服务用途，BMS 电池状态基础服务的 SOA 软件以固定周期向订阅者提供该服务中的数据信息。

上述电池状态服务的 SOA 软件开发步骤如图 8 所示。

图 8 汽车 SOA 软件的开发和部署步骤

1）服务接口开发

服务接口开发用于完成 SCA 架构中服务接口部分的部署，是 SOA 软件开发的第一步且是关键一步。其过程主要可分解为如下步骤：a）服务的数据类型定义；b）服务端口设定；c）服务端口与软件单元（SWC）以及软件进程（Executable）的绑定。这些接口信息在 ARXML 文档中被描述，并通过 AUTOSAR Adaptive 中间件供应商提供的工具生成为代码和配置信息（Manifest）。

对应电池状态服务的 SOA 软件，首先定义包括 电池包剩余电量、电池均衡状态以及电池包高压互锁状态信息的数据类型，并采用 Field 的 Notification 方式周期性推送上述服务信息；由于是服务提供方，因此服务端口设定为提供端口（Provide Port）；将该 Provide Port 绑定至电池状态服务 SOA 软件的可执行进程。

2）业务（应用）逻辑开发

业务（应用）逻辑开发用于完成 SCA 架构中服务软件单元的实现。其过程是实现 1）中定义的服务接口，业务逻辑的编写可通过手工代码的方式或沿 用 基 于 模 型 的汽车 建 模 软 件 （ 例 如 Matlab/Simulink），最终产出 C/C++ 逻辑源码文件。

对应电池状态服务的 SOA 软件，在 1）设定的服务接口函数中，完成电池状态服务提供的业务逻辑代码。

3）集成

集成工作一方面用于集成 SCA 架构中服务接口和业务逻辑的代码；另一方面，用于完成电池状态服务 SOA 软件向目标中间件环境（AP）的适配。其过程主要可分解为如下步骤：a）SOA 软件进程的运行资源，调度机制和起动选项配置；b）服务提供和查找的参数配置，服务环境的 IP 地址，端口号信息；c） SOA 软件运行的系统状态。4）编译和部署 在完成上述工作后，选择 XCU 平台的目标交叉 编译器，对上述 SOA 软件进行编译和链接，并通过 SFTP 客户端软件 WINSCP 将编译产物可执行文件 （Executable）以及相关配置文件（Manifest）按系统要求安装于域控制器 XCU 平台相应的文件系统上。

面向服务架构（SOA）被认为是使能软件定义汽车的关键技术之一。本文给出了一种 SOA 汽车软件分层模型，依据该模型，提出了两种 SOA 汽车软件开发方法，并分别进行了实践，将所开发的 SOA 汽车软件案例，部署在联合汽车电子有限公司开发的域控制器（XCU）中。本文所提出的两种开发方法，分别适用于从汽车业务用例出发的正向开发，以及从汽车物理逻辑出发的平台构建，在 SOA 汽车软件开发中将并行使用，以使 SOA 的主要优势在汽车软件研发中得到体现。

参考文献

[1] KUGELE S, OBERGELL P, BROY M, et al. On Service-Orientation for Automotive Software [A]. IEEE. 2017 IEEE International Conference on Software Architecture（C）. Gothenburg: IEEE, 2017.

[2] ERL T. Service-Oriented Architecture: Concepts, Technology, and Design [M]. Prentice Hall PTR, 2005. 

[3] AUTOSAR. Adaptive Platform [OL]. 

https://www.autosar.org/standards/adaptive-platform/. 

[4] SADTLER C, CALCAGNO L, COX R, et al. Pattern SOA Foundation Service Creation scenario [M]. IBM. 2006. 

[5] KEEN M, ACKERMAN G, AZAZ I, et al. Pattern SOA Foundation-Business Process Management scenario [M]. IBM. 2006. 

[6] WAGNER M, ZOEBEL D, NEROTH A. Model-driven development of SOA-based Driver Assistance Systems [A]. ACM SIGBED Review. 2013. Volume 10 （1）. 

[7] 宋杰静，马云杰，田鹏飞. 基于 PREEvision 的以太网 SOA 设计方法[A]. 中国汽车工程学会. 2019 中国汽车工程学会年会论文集[C]. 2019. 1275-1278. 

[8] 刘佳熙，丁锋. 面向未来汽车电子电气架构的域控制器平台[J]. 中国集成电路, 2019, 9: 82-87.