如何设计一个SOA架构呢

面向服务的开发模式已经是为大家熟知的下一代智能汽车开发模式了，由于SOA（Service Oriented Architecture）架构的灵活性和可扩展性，而这个恰恰与「软件定义汽车」的思路不谋而合，因此可以说SOA的发展基础是伴随着软件定义汽车的模式而产生的。为了更好的支持车控软件的分布式部署与更新迭代，针对SOA的开发模式，需要在基于信号的服务通讯架构下进行开发，这种新架构下的开发模式本身也存在一定的难度。

SOA系统由一组服务组成，并且其中的总服务包可以依次使用其他的多个子服务，也可以根据需要使用一个或多个服务的应用程序，SOA通常以不同系统间隔表现出不同的功能特性。

为了支持复杂的应用程序，同时在处理分布式和计算资源分配方面提供最大的灵活性和可扩展性，业界均采用AP（Adaptive Platform）作为中间件进行SOA的设计开发，遵循面向服务的体系结构。

AP作为HPC（High Performance Controller）类型ECU的重要组成部分，可以统一管理下属OS以及周边资源，使得系统运行时的一切调度、状态和资源消耗都处在一个可控的范围内，以满足车载安全性、确定性的要求。



此外，AP架构可以实现分布式计算，通过某种形式的消息传递进行有效通信。这种基于消息传递和基于通信的架构也可以实现快速和高带宽的有效通信（例如以太网）。

本文将以系统设计和开发者的身份重点讲解如何设计一个SOA架构，并重点说明整个过程中需要完成哪些具体的工作。

1.SOA开发流程设计

下一代自动驾驶系统将定义整车级SOA软件架构，通过分层部署的方式，将全局变量的服务统筹提取出来（例如车速、时间、车辆状态等），作为共用的软件模块提供服务，实现特定的基础功能软件接口统一，并可灵活部署。



大体上，AP（Adaptive Platform）的开发是一个“从上至下”的流程，其中跟SOA设计相关的有以下几个重要步骤：

Step1：定义服务内容

此步骤实际上就是搭建了一个系统功能架构，从整车层面即是按照功能需求定义并划分服务。对于SOA中的服务表示了一种独立的功能单元，一个服务可以包含其他子服务单元，使用标准接口进行通讯，将内部信息封装成一个黑盒子，实现子服务的重用性。

上层服务可以通过该标准接口调用下层服务封装的子服务内容。同时，整体的服务内容可以被操控单元远程访问和独立更改或更新。同时，对于SOA来说，需要通过服务编排来定义清楚服务之间的相互关系。

简单地说服务对于智能驾驶汽车而言就是定义产品，对其中产品的能力进行描述，这里的产品能力我们称之为PC（Product Capability）。

实现这种产品能力需要从下至上定义硬件抽象服务、平台核心服务、域核心服务、应用程序服务。而每一个服务内容对应着一个或多个实现的软件模块，这里我们称之为SWC（Software Capability）



产品能力(PC) 描述了系统所需的一些高级功能。区别于系统设计，PC是用来分配职责的，所以很清楚哪个SWC Module软件模块（如摄像头识别模块、雷达识别模块、中央域控制器模块）应该实现什么。

它们在功能设计时由功能负责人识别和请求。一些系统相关的PC也可以由系统架构师或模块负责人直接识别，在模块架构工作中映射PC时，模块所有者还可以确定对更多 PC 的需求。

在确定并决定添加 PC 后，对应的软件模块拥有该 PC，模块所有者负责将其实施到正确的版本，并在平台的整个生命周期内维护/发展 PC。

 

Step2：定义服务接口

服务接口是一种通信内容定义，其目的在于将服务从功能架构过渡到软件技术架构，且软件模块之间的关系需要被清晰的定义出来，过程中将服务内容封装成相应的接口被实际调用。这种接口定义是独立于通信协议的抽象实体，这种接口可以建立任何两个服务间的通信能力，而使用合适的工具链可以由此生成基于特定协议的接口。

服务接口可分为方法（Method）、属性（Property）、事件（Event）三种类型。以智能驾驶的一个子功能执行接口服务为例，假设需要获取摄像头传感器探测的环境数据，而需要进行定义的服务接口中方法是要对传感器的参数进行后融合，那么就需要其底层服务提供摄像头处理的基础函数（如ISP、深度学习函数、BEV函数等）。

而服务接口的属性则是通过一定的方法操作（如get/set）来获取该服务函数，这种服务属性可以对上层调用的服务部分可见，底层服务有变动上层的调用方式也会随之变动，这种变动所带来的更新会由服务底层决定何时发送给上层调用它的服务单元。 服务接口定义完整后，开发人员可以根据该接口定义对其中的函数进行定义开发了。

Step3：配置服务映射关系

此过程会建立软硬件之间的映射关系，实现从抽象的服务定义到软件层面的推导，从而方便实现软件驱动或调用硬件实现单元，这种结果是实现服务与中间件或底层硬件ECU之间的映射关系。

从整个SOA的架构模型中我们知道服务需要从通用服务平台开始进行底层驱动，然后对上层传感器执行器的控制管理进行驱动。

由于AP直接支持服务接口，可以直接面向上层应用层，CP仍然是对常用的底层应用服务的驱动映射，因此，两层驱动分别对应着经典的CP Autosar中间件调用和AP Autosar模式。

Step4：通讯协议设计

智能网联汽车的SOA架构设计需要强大的环境感知、信息处理、实施决策、控制能力可以把智能交通、地图、定位、通讯、云、大数据等进行系统集成，故车端与云端、车辆与车辆之间、车辆内部的各个ECU之间通信的速率和数据量都比传统汽车高出几个数量级，这些需要由多种复杂的硬件、软件和高速通信总线共同实现，并在很大程度上决定智能汽车的功能实现和扩展的可靠性。

车载以太网能够很好的解决大数据量的信息交互，整个通信协议的定义包括虚拟以太网VLAN，以太网交换机Switch，套接字Socket，基于IP的可扩展面向服务的中间件SOME/IP，SD等。而基于AVB的下一代协议TSN（时间敏感网络）可以提供非常优秀的实时性。

以太网通讯设计过程包含对服务实例进行通讯协议相关的信息配置。由于SOA架构中包含多个应用实体之间的多通路通信过程，且这些通信通常是网状通信，因此需要在各个实体节点之间建立中间路由、转化等。

区别于传统总线（Can/Lin），在软件架构设计过程中，开发人员需要设计具体的服务类型、服务ID、服务数据类型、服务角色等。

2.SOA架构设计流程

SOA的逻辑架构内容需要根据分层架构策略分配给一层的多个模块。这些层也被分成几个功能区，使用Enterprise Architect进行架构模型管理是SOA模块架构设计的基础，如下图表示了典型的SOA系统的架构设计模型。



区别于传统Can总线面向信号的设计思路，在以太网设计过程中，开发人员需要在逻辑层面将功能抽象为服务的方式进行架构设计。

如上图，从下至上包含了SOA基础服务管理、硬件I/O控制管理、系统功能控制管理、单元域功能控制管理、整车功能控制管理、云端控制管理、人机交互管理。

SOA基础服务管理：该模块主要是对整车软件模块的基础功能（例如诊断管理、驱动管理、存储、日志记录、OTA等）进行分解并统一管理。

SOA硬件I/O控制管理：该模块主要涉及对SOA中的传感器&执行器进行的相应管理，包括定义传感器输入源硬件（Camera、Radar、Lidar、Uss、GPS等），定义执行器输入输出源硬件（方向盘、制动踏板、转向电机、车门车窗、电源电池、蓝牙wifi等）。

传感器执行器层中的所有模块都必须包含其各自设备的功能设备驱动程序 (FDD)。设备管理模块将包含所有 ECU 使用的通用 ECU 设备驱动程序 (EDD)。

SOA系统功能控制管理：以SOA服务所需要实现的系统内部作为划分区间，将对特定功能进行控制的特殊功能服务，例如比如ADAS系统将传感器输入的信息进行统一初级信息处理（如ISP、加串解串、原始点云处理）。

单元域功能控制管理：对系统内部功能进行协调的功能服务，如ADAS系统中利用深度学习进行环境信息检测、传感器信息融合，同时在动力学模型中进行车辆运动控制、车身姿态控制。

整车功能控制管理：对单个整车内的系统进行调度的功能服务，包括协调运动控制单元、动力系统、车辆安全相关的能力，特别是车身安全上需要充分考虑智能网联车辆的功能安全设置相应的软硬件安全门槛。

云端服务管理：云端管理可以是以总监控台管理的该车辆及其周边车辆、基础设施相关的功能服务，例如网络安全管理、云端计算服务、软件升级等协同控制。

基于以太网的SOA架构设计，需要开发人员明确4个问题： 服务提供者（Provider）+ 服务·类型（Service）+ 客户端（Consumer） + 服务接口（Service Interface）。

一般的，对于SOA系统架构设计过程中可使用面向对象的设计工具进行设计。

如前所述对于服务来说我们需要首先进行产品能力PC定义，对应于该服务模块需要设计相应的服务软件模块组建SWC。

其中服务组件包和软件组件包的设计流程分别如下：



如上过程的设计和配置完成之后可采用一些现有的SOA开发工具PREEvision生成Arxml文件。该文件区别于CAN/CANFD/LIN总线的DBC和LDF等数据文件，Arxml包含了SOA架构设计所有相关的服务、属性以及服务的软硬件实现方式，成为了以太网总线开发的通用标准数据接口。

SOA架构主要优势是可以很大程度上实现软硬解耦，通过软件升级OTA可以更加方便灵活的实现服务实体有效部署在任意的域控制器上，而且可以在售出车辆上调整部署策略。

同时，SOA的衍生功能是可以在汽车功能安全方面实现有效的冗余部署。例如，对于安全性要求比较高的智能驾驶功能可以实现双重制动冗余配置，同时在车端布置双重中央域控制服务，确保当一个域控制器失效时，那么另外一个域控制器上的备用服务实例立刻启动，重新与服务使用者建立连接，以保证功能的正常运转，借此实现冗余机制。

对于SOA来说，是需要在AP Autosar流程下设计从服务定义到服务实例化的整个过程，为了实现在算法和软硬件调用中的有效通信，就需要设计有效的通信协议，对于SOA来说基础的通信协议除了Can以外，最基本的就是以太网的通讯设计。

审核编辑：刘清