| 编辑推荐: |
本文讨论SOA汽车软件的开发方法，并付诸实践：第一部分提出一种SOA汽车软件分层模型；第二部分基于分层模型，介绍两种SOA汽车软件开发方法。
本文来自于联合汽车电子有限公司，由火龙果软件Anna编辑、推荐。 |
|
1. SOA汽车软件分层模型
在面向服务架构中，“服务”是对业务逻辑的封装，具有明确定义的接口，并被独立的实现；“面向服务”定义了一种方法，这种方法通过连接多个“服务”实现业务需求。
“服务”所封装业务逻辑的大小，决定了“服务”在业务过程中涉及的范围，直接决定了“服务”的自治、重用等关键特性，是S0A架构设计的核心问题。在SOA汽车软件设计中，必须有清晰的模型作为依据，才能有效地发挥SOA的优势。
本文提出一种SOA汽车软件分层模型，如图1，包括元服务、基础服务和应用服务三个层级，使不同层级的“服务”分别对应不同层级的汽车业务逻辑。
（1）元服务
元服务是最小单元。从业务角度，元服务是对底层逻辑的封装，不具有再拆分的意义和价值；从架构角度，元服务是高度通用、高度自治和可重用的功能单元，构建了整个SOA架构的底层基础结构。汽车的传感器、执行器等基本接口和车辆基本参数可封装为元服务，例如，将车速、车辆惯性状态等参数封装为“车辆状态”元服务，可以对上层服务架构提供支持。
（2）基础服务
基础服务是分层模型的中间层服务。从业务角度，基础服务封装了更多的业务逻辑，即组合了若干元服务；从架构角度，基础服务可以访问和调用元服务以实现更大范围的业务过程。基础服务应是足够自治和可重用的。在利用元服务的基础上，可重用的汽车业务逻辑可封装为基础服务，例如，在利用自车车辆状态服务、雷达等传感器信息服务以及其他信息的基础上，可构建“环境信息融合”服务，作为基础服务。
（3）应用服务
应用服务是分层模型的最顶层服务。从业务过程角度，应用服务可以包括一个业务过程的全部业务逻辑，封装了与特定业务有关的基础服务；从架构角度，应用服务可以访问和调用基础服务以帮助其解决业务问题。元服务和基础服务更强调架构的灵活性，而应用服务则更强调商业意义，和业务需求有非常紧密的联系。具有客户价值的业务用例可作为应用服务，例如，“能量预测管理”是一个应用服务，它利用车辆状态元服务、环境信息融合基础服务和其他服务，从而实现了通过智能管理降低车辆能耗这一具有商业意义的业务需求。
在设计中，上层服务调用下层服务，下层服务不调用上层服务，这一原则有助于构建清晰简单的SOA汽车软件架构。参考以上分层模型，可以有效定义SOA汽车软件的开发方法，从而有效地发挥和获得SOA的优势。
2. SOA汽车软件开发方法
基于SOA汽车软件分层模型，结合汽车领域软件开发的工程实际，可定义SOA汽车软件开发方法，典型的有“业务驱动型”的开发方法和“平台驱动型”的开发方法，两种方法适用于不同的应用场景。
2.1 业务驱动型开发方法
业务驱动型指从业务用例出发，以服务为导向，正向设计SOA汽车软件的开发方法。此方法应用于业务用例已知，需要设计SOA汽车软件以实现业务用例的开发场景。在设计过程中，通过“业务过程分析”、“服务操作分析”、“候选服务分析”三个步骤，解决“应该构建哪些服务?”、“每个服务应该封装什么逻辑?”两个核心问题。
（1）业务过程
分析业务过程分析指的是充分理解具体使用场景下的真实业务过程。本文采用了用例驱动的方法来分析业务需求和过程。用例驱动指从用户使用的角度而非开发人员的角度考量功能需求和系统实现，重视从系统外部观察对系统的使用。由用例驱动的开发活动，可以建立需求和服务操作之间清晰的追溯关系，为抽象和封装服务提供充足的语境信息。
（2）服务操作分析
服务封装的业务逻辑，由服务操作实现。服务操作代表了服务所执行的特定动作，可类比软件中的方法或函数。面向服务的分析包括了识别候选服务操作并将其分组的过程，这些组最终成为候选服务，我们将这个过程抽象为服务操作分析和候选服务分析两个步骤。
服务操作分析是从业务过程分析的产物向服务过渡的过程，目的是得出构成候选服务的服务操作。服务操作分析具体可描述为：对系统用例逐个进行分析细化，描述系统如何与参与者一起实现每个用例，从而得到系统与参与者、与外部系统的界限及信息交互，最终得出对系统的功能要求，这些功能要求是系统必须实现的功能点，在下一步将直接作为组成服务的候选服务操作。
（3）候选服务分析
候选服务分析的目的是对业务逻辑进行抽象和封装，从业务角度寻找最优的服务操作划分方式，所提出的“SOA汽车软件分层模型”为候选服务分析提供了有价值的参考。根据重用性和自主性的面向服务设计原则，参考图2三层模型设计元服务和基础服务。
对元服务和基础服务的设计，SOA鼓励即使没有立即重用的要求，也要根据服务导向的设计原则促进重用，因此潜在的重用也要考虑在内。通过良好的SOA设计，当业务用例增加，或原有业务用例发生变更时，良好的基础服务和元服务设计，保证了重用性和较少的软件变更，从而实现更快速高效的功能迭代和清晰明确的版本管理。
2.2 平台驱动型开发方法
平台驱动指从汽车已开发完成的物理逻辑出发，将物理逻辑封装为元服务，也可将部分元服务进一步组合为基础服务：平台驱动型开发方法适用于如下场景，即业务用例尚不十分明确，但需建立SOA汽车软件基础平台，以支持潜在应用服务的快速引入，利于未来快速软件创新。
在实施平台驱动型开发方法过程中，通常需要对汽车物理逻辑进行收集，并根据物理逻辑的潜在服务价值，优先选取潜在服务价值较大的部分，将其封装为元服务，并适当组成基础服务j在未来应用服务构建时，可利用已构建的元服务和基础服务，实现快速的软件创新。基于平台驱动型开发方法，可提供车辆软件系统的开放性，最终实现汽车的“操作系统”。
在实际汽车软件工程开发领域，以上所述业务驱动型和平台驱动型开发方法均有应用需求。
第二部分别描述基于以上两种开发方法（面向服务架构汽车软件的开发方法）的SOA汽车软件开发实践。
3.1 业务驱动型开发方法实践
图3展示了一个业务过程分析的例子∶ 以一辆混合动力的汽车为例，终端消费者的期望是提高驾驶经济性，这是一个长期目标，需求分析人员针对该目标，挖掘消费者的使用场景，结合该车混合动力的特点，发现了在驾驶过程中优化动力来源分配策略这一短期目标，通过短期目标的累积最终实现长期经济性目标的整车需求。功能开发人员针对该需求提出了融合网联提供的前方道路信息和历史数据信息对汽车动力来源进行预测性优化的解决方案。
首先进行业务过程分析∶ 在充分理解该方案提出的问题背景下，采用用例驱动的方法，分析和设计了该方案的业务过程，得到了系统用例。
接下来进行服务操作分析，对系统用例逐个进行分析细化，描述系统如何与参与者一起实现每个用例，从而得到系统与参与者、与外部系统的界限及信息交互，最终得出对系统的功能要求，这些功能要求直接作为候选服务操作。图4展示了对"确定导航路径"这一系统用例的分析示例。
最后进行候选服务分析。图5展现了一个案例，在得出候选服务操作的基础上，初步抽象出了候选服务，并定义了每个候选服务应具有的服务操作。综合实际业务情况等多方面因素，运用面向服务的重用性等原则进行综合分析，我们对这些初步候选服务进行了多次评估和调整，得到了如图5右半部分所示的候选服务。
3.2 平台驱动型开发方法实践
在实际工程实践中，面向客户需求的业务用例往往不是一次性开发出来的，而整车架构必须事先布局，以使未来业务用例明确时，软件能够快速构建，以在有限的时间窗口内进入市场，实现更大的商业价值。因此，平台驱动型的开发方法是必要的。
如下是一个平台驱动型开发方法的实践。如图6所示：
通过对已存在的车辆物理逻辑及其潜在服务价值的分析，认为电池管理系统（Battery Management
System，BMS）电池剩余电量（State of Charge，SoC）、电池均衡状态、电池高压互锁状态等信息具有潜在的应用价值，未来基于这些信息可构建多种有商业价值的业务用例，因此，将这些信息构建为元服务。
在进一步整合封装后，形成"BMS电池状态"的基础服务，同理，经过同样的评估，可得到如下基础服务内容∶
1）BMS电池状态服务
2）整车热管理服务
3）车辆动力系统驱动服务
在完成上述基础服务单元后，业务逻辑可被进一步灵活拓展。BMS电池状态服务可与车辆动力系统驱动服务进一步扩展结合，组建优化电池充电曲线的应用服务。同样，随着未来业务场景的不断清晰，这些有潜在价值的基础服务与元服务，可以不断扩展、组合，灵活的应对业务需求的迭代更新。
4. SOA汽车软件在域控制器上的部署
随着汽车电子电气架构向集中化发展网，域控制器将成为部署SOA汽车软件的最优选择，其原因如下∶
1）域控制器采用多核微处理器并搭载多进程（RichOS）操作系统，其高算力、多线程、可并发运行于多核处理器的特性使大量边缘触发型的数据处理功能在汽车软件中得以实现，而边缘触发逻辑是
SOA 软件部署的重要特性之一。
2）域控制器平台间通过以太网进行数据传输，高带宽赋能了基于以太网的、面向服务的通讯机制，让SOA软件的跨域合作成为可能。
3）域控制器平台可搭载AUTOSAR Adaptive 中间件，保证了应用软件可以直接调用AUTOSAR组织提供的公共标准的接口（ARA::API），代表应用软件不再需要为不同操作系统的不同接口做适配和变更，从而使得
SOA 软件"软硬分离"的特性得以实现。
5. SOA 汽车软件的部署方法
AUTOSAR Adaptive（AP）作为AUTOSAR 组织发布的面向POSIX操作系统的标准中间件，提供SOA汽车软件部署的整体解决方案。AP中的
Communication Middleware（CM）组件实现了服务中间件的功能，服务中间件解耦了服务接收方和发送方，并与服务接收、发送方一起，实现服务的注册，订阅，提供和查找功能；
同时，AUTOSAR组织定义了基于ARXML 文件的服务架构模型（SCA-Service Component
Architecture）描述规范，该规范描述了图7中SCA中接口和消息的部分，并提供对于这些描述文件的代码生成工具。
当前，我们将AP中间件集成于联合汽车电子有限公司开发的域控制器（XCU）平台，并使用AP中间件，完成
SOA汽车软件的实现和部署。
无论是元服务 、基础服务还是应用服务，都具备接口标准可访问、自治、可组合扩展等特性。这些特性源于SOA汽车软件的架构模型。
SCA将服务组件划分为业务逻辑、服务接口和服务消息三个部分，并确保三者相互独立∶
1）服务消息的内容取决于 SOA 软件绑定的消息机制，即通讯协议，汽车软件当前主流应用是 SOME/IP
协议，该协议栈已被集成于 AP中的 CM组件单元。
2）服务接口是服务组件有别于传统软件单元的核心部分，服务接口调用消息机制，让每个服务软件对外都可以标准且相同的方式被访问。AP提供了基于
ARXML的标准接口描述规范以及相应的代码生成工具，服务提供方与服务接收方以AUTOSAR组织标准约定的描述文档进行服务内容的交互。
3）业务逻辑展现了每个服务组件的具体功能，业务逻辑独立于消息和接口而存在，可单独进行开发，且不依赖于特定的编程语言。
设计与部署一个SOA汽车软件分为以下几个重要步骤。通过这些步骤，我们可以实现和部署出一个SOA汽车软件在域控制器平台上。
以3.2节BMS电池状态服务为例，BMS电池状态服务为基础服务，用于提供电池包的状态信息，其由剩余电池电量、电池均衡状态以及电池包高压互锁状态这些元服务组合而成。因服务用途，BMS电池状态基础服务的SOA软件以固定周期向订阅者提供该服务中的数据信息。
上述电池状态服务的 SOA 软件开发步骤如图8所示。
1）服务接口开发
服务接口开发用于完成SCA架构中服务接口部分的部署，是 SOA软件开发的第一步且是关键一步。其过程主要可分解为如下步骤∶
a)服务的数据类型定义;
b)服务端口设定;
c)服务端口与软件单元（SWC）以及软件进程（Executable）的绑定。这些接口信息在 ARXML文档中被描述，并通过
AUTOSAR Adaptive 中间件供应商提供的工具生成为代码和配置信息（Manifest）。
对应电池状态服务的 SOA 软件，首先定义包括电池包剩余电量、电池均衡状态以及电池包高压互锁状态信息的数据类型，并采用
Field 的 Notification方式周期性推送上述服务信息;由于是服务提供方，因此服务端口设定为提供端口（Provide
Port）;将该 Provide Port 绑定至电池状态服务 SOA 软件的可执行进程。
2）业务（应用）逻辑开发
业务（应用）逻辑开发用于完成SCA架构中服务软件单元的实现。其过程是实现1)中定义的服务接口，业务逻辑的编写可通过手工代码的方式或沿用
基于 模型的汽车建模软件（例如Mat- lab/Simulink），最终产出C/C++逻辑源码文件。
对应电池状态服务的SOA软件，在 1）设定的服务接口函数中，完成电池状态服务提供的业务逻辑代码。
3）集成
集成工作一方面用于集成 SCA 架构中服务接口和业务逻辑的代码;另一方面，用于完成电池状态服务 SOA
软件向目标中间件环境（AP）的适配。其过程主要可分解为如下步骤∶
a）SOA 软件进程的运行资源，调度机制和起动选项配置;
b）服务提供和查找的参数配置，服务环境的 IP地址，端口号信息;
c） SOA 软件运行的系统状态。
4）编译和部署
在完成上述工作后，选择 XCU平台的目标交叉编译器，对上述 SOA 软件进行编译和链接，并通过 SFTP
客户端软件 WINSCP将编译产物可执行文件（Executable）以及相关配置文件（Manifest）按系统要求安装于域控制器XCU平台相应的文件系统上。 |
