随着商用车电动化、智能化、网联化和共享化的发展，电子电气架构的设计变得愈发重要，传统的E/E 架构从软件迭代能力、架构复杂度、算力和数据传输等方面已无法满足商用车的发展。本文基于域控架构和SOA架构，结合商用车自动驾驶的应用场景，提出商用车域控架构下SOA的实现方案，从而精简车辆控制器的布局，减轻车辆的电器零部件总质量，扩充整车数据交互容量，降低各个模块间的耦合度，并且使得功能的扩展更容易。
1 前言
随着乘用车自动驾驶技术研究以及应用的深入，商用车领域也掀起了自动驾驶技术应用浪潮。得益于商用车在港口、矿山、机场等封闭场景广泛应用，自动驾驶技术也快速地在商用车上使用。由于自动驾驶所需要的算力及数据量的爆发式增长，传统的E/E架构已经很难满足需求，而域控架构方案可以很好地满足控制器算力及数据量的巨大需求。同时，随着软硬件技术的发展，面向服务的体系架构（Service-Oriented Architecture，简称SOA） 为商用车E/E架构开发指明了新的方向。基于此技术，车辆通过搭载基于SOA设计的通用域控制器，使得车辆具有更好的可扩展性、良好的平台化功能、灵活的功能配置和更高的智能化水平。本文基于域控架构和SOA架构，结合商用车的应用场景，提出商用车的域控架构下SOA的实现方案。
2 SOA架构及域控架构
2.1 SOA架构
SOA的核心概念是服务，每个服务组件具备独立的功能。服务组件之间的接口遵循统一的标准，可互相访问，可组合扩展，其最大的优点是松耦合和跨平台。SOA架构下，软件系统通过定义了利用服务接口复用的软件组件的方法，通过通用通信标准应用到新的应用程序中。
2.1.1 参与者
SOA架构中包含3种参与者，分别是：服务提供者、服务消费者、服务注册中心，如图1所示。
图1 SOA架构图
1） 服务消费者：使用服务消费者提供的一组或者多组服务的组件。
2） 服务提供者：是一个可提供通过网络寻址的实体，接受和执行来自使用者的请求。
3） 服务注册中心：储备服务描述，服务提供者注册其服务，服务消费者访问其中已经发现的所提供的服务。
2.1.2 基本操作
SOA架构中的消费者和服务提供者要交互，需通过3种基本操作来完成。
1） 发布：为了使服务可访问，需要服务提供者发布服务描述以使服务消费者可以发现它。
2） 查找：服务消费者定位服务，方法是查询服务注册中心里所注册的服务，找到满足其要求的服务。
3） 绑定：在服务消费者查找到服务描述之后，服务使用者根据服务描述中的信息来调用服务。
2.2 域控架构
域控架构是将整车电器系统根据功能划分为若干个大的功能块，如图2所示，每个功能块的属性统一，且与其他功能块功能耦合度低。功能块采用一个算力强大的多核中央计算机代替以往的多个分布式ECU，主要处理逻辑运算及指令下发。域系统内部的传感器、执行器、节点等采用硬线、CAN、LIN总线连接。而不同域之间的通信，由更高传输性能和更大容量的以太网作为主干网络承担信息交换任务。目前较为经典的功能域可以划分为5个主要域：动力、底盘、车身、座舱和驾驶辅助。
图2 域控架构示意图
3 商用车域控架构下SOA的分析
3.1 传统EEA与基于SOA的域控EEA对比
商用车传统的E/E架构中大量的功能需要ECU、信号间的协调来实现，所以整车中ECU间基于信号的通信会变得庞大而复杂，且不具低耦合性，微小的功能变动都会引起整车通信矩阵的变化。传统E/E架构中消息发送者不关心接收节点，只负责将信号发送出去，这种技术适用于有限大小控制数据的应用场景。
SOA代码灵活性强，支持请求/响应模式，支持复杂的数据模型，可扩展性强，能够满足自动驾驶等应用场景下，大量数据的动态交互，可以对系统进行部分更新。
如图3所示，当多媒体控制需要增加一项控制空调的功能时，需要同时变更控制对象（多媒体屏）、网关、被控对象（空调） 整个逻辑链路上的所有节点。
图3 基于CAN信号通信的功能变更
SOA引入到商用车软件设计中后，整车功能被设计为各种不同的服务组件，每个服务都有自身唯一的标识，可以完成自身发布以及订阅其他服务并进行通信。由此可以很好地解决上面整个逻辑链上的接点都要变更的问题。
如图4所示，当多媒体控制需要增加一项控制空调的功能时，只需要变更服务消费端的节点，逻辑链上的其他节点不需用变更。
图4 基于SOA通信的功能变更
3.2 整车功能服务设计流程
根据商用车域控架构的特点，结合软件SOA思想，将域控制器的软件按照重用性和自主性面向服务原则进行设计，对整车功能软件开发设计。良好的服务设计，使得整车功能增加，或原有功能发生变更时，保证了较少的软件变更，从而实现更快速高效的功能迭代和清晰明确的版本管理。
EEA工程师根据整车需求清单先提取出整车功能清单和整车配置，然后设计出整车子系统需求规范和整车子系统设计方案。根据零部件和功能分配完成整车域控架构设计，当域控架构设计完成后，根据域控制器、总线节点、执行器、传感器等对功能进行服务化设计。服务设计时，必须基于整车规划和发展考虑，将整车基本功能、选配功能、未来可能搭载的功能、容易更新的功能等整车需求纳入服务设计中，按照车载以太网协议要求对各个服务的相关参数进行定义。最后软件工程师按照功能逻辑、服务结构、通信参数等对域控器、总线节点、传感器等电器件进行软硬件设计，完成整车功能的实现，如图5所示。
图5 整车功能实现流程
3.3 商用车域控架构下SOA的设计
得益于域控架构的优势，许多功能的逻辑实现都可以由单一域控制器实现，使得不同域之间的功能耦合度降低，这使得SOA思想可以更好地与其贴合。其次，SOA是面向服务的架构，通过标准的服务接口，使得单个功能的实现可以通过一个固定的服务接口暴露给其余需用的组件。最后，结合以算力强大的“域控制器”为中心的集中化物理架构，使得需要通过通信交互的控制器得到有效的控制。简化了整车物理结构的同时也简化了整车通信结构，使得车辆功能的扩展性更强、灵活性更高。例如，某个功能已经设计为服务后，该功能的实现只在自身所在的域控制器里实现。当该服务需要更新时，只需服务接口不变，其余调用该服务的域控制器均不会受到影响。如图6所示。
图6 基于域控架构下SOA的设计
3.4 商用车域控架构下SOA的实现
运用SOA思想后，将整车功能基于信号交互的方式优化为基于服务交互。从整车功能和域控制器功能出发，将其分解或者合并为单个服务，单个服务只注重实现单一功能，并保证各个服务之间相互独立，耦合度最低。域控制器平台可搭载AP中间件，可以直接使用AUTOSAR组织提供的公共标准的接口，软件不再需要为不同操作系统的不同接口做适配和变更。不同域控制器之间的通信以车载以太网进行数据传输，对每个服务的类型、功能、数据结构等信息按照车载以太网的协议要求设计，高带宽的通信能力，让SOA软件的跨域合作成为可能。功能的服务化使得各个域之间的信息交互及功能调用更加简单和直接。
服务设计和部署完成后，通过对不同服务的调用来实现整车设计的功能。如图7所示。例如，按照整车功能开发流程，提取出车身域控制器所要开发的服务。如图8所示，车身域控制器分别提供了空调服务、门锁服务。其中空调服务由自动空调开启关闭控制、空调状态反馈等基础服务组成；门锁服务由车门解闭锁控制等服务组成。同时这些服务的消费者分别分布在中央网关、座舱域控制器、云端等主体。服务中间件解耦了服务接收方和发送方，并与服务接收、发送方一起，实现服务的注册、订阅、提供和查找功能。AP提供了基于ARXML的标准接口描述规范，服务提供者与服务消费者共同标准约定的描述文档进行服务内容的交互。
图7 整车域控架构
图8 车身域控制器服务布置架构
车身域控制器提供的所有服务应按照SOME/IP协议将服务消息进行设定。完成后会进行服务接口的开发，服务接口的开发和部署是SOA软件的第一步并且是关键的一步，主要包括：服务的类型定义、端口设置、进程绑定。接口开发完成就是逻辑开发、逻辑和服务集成、代码编译。
车辆上电后，各个域控制器会分别向注册中心提供自身所提供的所有服务，其他域控制器会将自己所需要的服务进行标记。服务消费者通过对注册中心的查询，提取出该服务的所有通信信息，并根据服务特性及自身需求，调用服务或者周期性建立交互。
从这个简单的例子可以窥探出商用车域控架构下SOA的设计实现过程，体现出软件SOA架构与域控架构结合后的优势。
4 结束语
