一种基于SOA架构的车辆服务平台的分析

朴春日，栾 辉

0 引 言

智能化、网联化是汽车产业发展的重要方面。汽车新功能的开发速度越来越快，软件布署更加复杂，用户要求愈加丰富，这些对传统电子电气架构提出了挑战，新的电气架构开发模式逐渐出现。从IT 领域引入的SOA （Service-Oriented Architecture，面向服务架构）被认为是能够支持未来汽车软件发展的核心技术之一[1]。

SOA 自20 世纪90 年代被提出后，在IT 领域获得快速发展和广泛应用[2]。将汽车软件封装成服务以提高软件的可维护性和可重用性的思想[3]是汽车SOA架构的核心理念。这些服务软件模块具有低耦合、自治的特点和标准接口，通过SOME/IP（Scalable service-Oriented MiddlewarE over IP，基于IP 可扩展的面向服务的通信中间件协议）被其他模块调用。SOME/IP 是面向服务的通信协议，不同ECU（Electronic Control Unit，电子控制单元）之间通过Client/Server （客户端/服务端） 或Sender/Reciever（发送端/接收端）方式进行通信，数据只在有需要时进行传输，有效降低总线负载[4]。

目前，汽车领域多家企业已进行了相关探索。联合汽车电子有限公司提出将AP （Adaptive Platform，自适应平台）中间件集成于所开发的XCU（域控制器）平台，以完成 SOA 汽车软件的实现和布署[1]。 宝马公司在新一代E/E （Electrical/Electronic，电子电气）架构中引入SOA 方法，为整个系统提供大量抽象服务[5]。

本文构建一种基于SOA 的车辆服务平台，其上运行车身域和娱乐域的多种基础服务，包括电气件状态服务如门锁状态、灯状态等，电气件控制服务如打开雨刮、播放音乐等。这些服务对外提供SOME/IP 接口和MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议）接口，方便其他应用调用。用户可对各类服务自由灵活调用编排，使之成为定制的车辆新功能。

1 SOA服务平台系统

1.1 系统组成

SOA 服务平台系统由应用层、服务层和传感执行层3 部分组成。（1）应用层布署和实现SOA 场景功能APP 软件，例如提神模式、自定义场景等，并且可调用服务层服务，基于预设逻辑、时序等实现特定的应用场景功能。应用层的应用场景由场景编辑器开发，操作流程如图1所示，编辑场景时首先定义进入场景的条件，包括触发条件和状态条件两类，之后设置对应场景的执行动作，并确定是否定义退出场景。全部内容定义完成后，将场景配置文件下载至车端。（2）服务层布署和实现SOA 服务软件，例如外灯服务、导航服务等，该层一方面接收传感执行层状态信号，向传感执行层发送控制信号，封装信号为服务，另一方面向应用层提供服务能力，供应用层调用。（3）传感执行层提供车辆基础的传感、执行能力，主要包括娱乐域、车身域。

图1 场景编辑器操作流程

1.2 服务划分

服务作为面向服务设计的最基本单元，承载了特定责任，为降低服务间的耦合，服务划分应满足单一责任、低依赖和基于场景划分的原则[6]。据此将常见的车身域和娱乐域功能抽离出来封装成元服务，总计46 个服务、281 个服务接口，见表1，其中每个服务均由若干子服务（接口）组成，包括车辆已定义并实现的服务（车辆支持）、车辆已定义未实现的服务（车辆未支持）以及车辆未定义的服务（预留）。

表1 服务划分

1.3 硬件布署

SOA 服务平台系统的硬件布署如图2 所示。应用层布署在Scene Engine（场景引擎控制器）上，保存场景编辑器中的新应用。服务层布署在BU（中央域控制器）上，实现全部服务的独立运行。传感执行层布署在HU（HMI Unit，人机交互单元）和其他车身域电气件上，提供车辆状态和实现具体执行动作。BU 上运行Adaptive AUTOSAR（自适应平台），既可通过SOME/IP 接口对外提供服务，又可借助一个应用代理模块通过MQTT接口对外提供服务。服务层和传感执行层之间通过CAN（Controller Area Network，控制器局域网络）进行交互。此外，新应用的开发通过布署在PAD（Portable Android Device，便携式安卓设备）上的场景编辑器实现，可将应用下载到Scene Engine中。

图2 硬件布署

2 SOA服务平台软件

2.1 Scene Engine

Scene Engine实现场景配置文件的无线下载和车端布署、SOA 应用管理和场景触发等，其中场景配置文件的格式为JSON。Scene Engine 软件分为4 个模块：MQTT、数据引擎、场景引擎和服务引擎，如图3 所示。（1）MQTT 负责与PAD 进行无线通信，接收、校验和解析SOA 应用配置文件、上报场景状态等，通信协议为MQTT；（2） 数据引擎通过SOME/IP 通信方式订阅车辆车身域和娱乐域的各种服务状态，并发送给Scene Engine，通过状态信息和场景配置文件中的触发条件判断场景触发与否；（3）场景引擎负责车辆SOA应用（场景）管理，如增加、删除、启用、禁用某个场景等，核心功能是监控已启用的全部场景的触发条件是否满足，当某个场景的触发条件满足时则调用服务引擎响应车辆执行动作的请求；（4）服务引擎为SOME/IP 通信代理端，负责响应场景引擎的请求指令，如解锁车门、打开音乐等，并实现各种车辆服务的调用。

图3 Scene Engine组成

Scene Engine是SOA车辆服务平台的核心组成部分。

2.2 BU

BU 为运行车辆SOA 中间件的平台，实现车身域和娱乐域全部服务的逻辑和对外提供接口，其软件模块包括MQTT 通信模块、CAN 通信模块、SOME/IP 通信模块和服务逻辑模块，如图4 所示。（1）服务逻辑模块负责车身和娱乐域服务逻辑的实现，并与CAN 进行交互，完成车辆状态的获取和车辆操作的执行；（2）CAN 通信模块负责车辆CAN 解析，同时接收和发送CAN 信号；（3）SOME/IP 通信模块将各车辆服务通过SOME/IP方式对外提供；（4）MQTT 通信模块将各车辆服务通过MQTT 方式对外提供。

图4 BU组成

BU 是车辆SOA 服务平台的服务层，可进行服务的动态布署和更新。

2.3 场景编辑器

场景编辑器是一款安装在车载PAD 端可创建车辆运行时各种场景的软件，包括两个模块：场景管理和场景编辑。（1）场景管理可通过在主页面点击“我的场景”进入，显示了当前车辆拥有的所有场景，可对场景进行新增、编辑、删除和执行操作；（2）场景编辑是允许用户为场景编辑场景名称、场景描述、场景触发条件和场景执行操作，即创建车辆新功能应用。

当车辆满足触发条件时，已安装在车端的场景会执行相应操作。

场景编辑器匹配安卓操作系统，可由引擎Cocos Creator 开发。编辑器使用单场景模式，即只有一个主场景，多个预制体进行页面切换，通信协议为MQTT。

3 新功能实例

通过SOA 车辆服务平台，用户使用场景编辑器编辑车辆新功能并下载到车端。本文以迎宾模式和分心模式为例说明新功能的实现过程。

3.1 迎宾模式

迎宾模式为用户自定义的新功能，当用户拉开车门时被触发，执行一系列动作，包括调节座椅、开启空调、播放音乐、变换座舱主题等，实车测试如图5所示。

图5 迎宾模式实车数据

由图5 可知，根据实车CAN 信号，迎宾功能的触发条件为：挡位为P 挡（信号3）、主驾门关闭（信号2）、主驾无人（信号4）、用户解锁车辆（信号1）；触发后执行迎宾功能：危险警报灯闪烁2 s（信号6）、位置灯和近光灯打开（信号5、7）、座椅X向位置调节至最大腿部空间（信号8、9）。从解锁车辆（信号1 对应的第1 条竖直虚线）到第1 个执行动作被触发（信号6 对应的第2 条竖直虚线）的时间约为800 ms，并发的执行动作也同时被触发，满足自定义的迎宾场景的功能和性能要求。

3.2 分心模式

车辆行驶中，当识别出用户分心行为如打电话、低头等时，需通过语音、屏幕图文、车窗下降、空调调节等方式提醒用户注意行车安全，实车测试如图6 所示。

图6 分心模式实车数据

由图6 可知，根据实车CAN 信号，分心模式的触发条件为：挡位为D 挡（信号2）、主驾有人（信号3）、系统识别到驾驶员注意力不集中（信号1）；触发后执行分心模式动作：打开左前和右前车窗（信号4、5）。从识别出驾驶员分心（信号1 对应的第1 条竖直虚线）到车辆执行动作被触发（信号4 对应的第2 条竖直虚线）的时间约为400 ms，满足自定义的分心模式的功能和性能要求。

4 结束语

本文基于SOA 的开发理念，提出一种车辆服务平台系统及软硬件设计方案，通过自定义新功能迎宾模式和分心模式，验证设计方案有效可行。