从Adaptive AUTOSAR的角度看SOA

必须打破车内静态交互模型

车辆内部控制器通过传统总线连接，从而实现通信交互，但是信号的收发关系和路由信息通常是静态的、不可更改的。如果后期突然新增节点，改矩阵和路由表？再如果，车辆上市后想新增一个功能到某个控制器，OTA可以将软件包本身下载到该控制器，但这个“新朋友”怎样从其他节点获得所需信息呢？

必须建立功能灵活治理的系统架构

OTA是目前解决车辆在线升级、持续提升用户用车体验的好方法。一个功能一个盒子的时代已经过去了。但OTA仅仅是途径，车辆的电子电气架构和软件设计架构能否支持功能更新呢？如果一个新增功能的实现，与车辆原有的系统架构、驱动方式、通信方式不匹配，甚至相冲突，这肯定是不可行的。那么应该怎样解决呢？

② 万物互联，汽车接入物联网

汽车在不久的将来会在互联网、物联网、能源物联网中都占有重要的地位。所以汽车必须具备开放性、网联性甚至自主性和自进化性。自动驾驶、V2X、边缘计算都是目之可见的应用场景，电子电气架构和软件平台架构在面对这些需求的时候，应如何处理？已有的电子电气架构及相应的解决方案，很难解决目前汽车所遇到的挑战，需要新的方法论来打破僵局，于是车载SOA作为解决方案被提了出来。

 2 SOA详解

① 先说说什么是SOA

• SOA是Service-Oriented Architecture的缩写，面向服务的架构。

• BEA资深SOA架构师Jeff Davies在其《SOA权威指南》中说到：SOA不是一种具体的技术，而是一种架构策略层面的指导思想。

• OASIS（结构化信息标准促进组织）对SOA的定义是：SOA是一个范式，以达到组织利用处于不同所有权范围控制下的分布式系统。

• 百度百科对SOA的定义是：面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

SOA的概念出自IT界，到现在都没有一个公认的定义，但是SOA的目标及其应具有的特性却是清晰明了的：

目标：

构建灵活可变的平台系统

特性：

服务间——松耦合、无状态、无依赖

服务内——高内聚且完整、可复用、可灵活重组

服务通信——标准化

② 从中我们看到SOA实现的重点在于：

• 服务通信标准化，即面向服务的通信（SOC，Service-Oriented Communication）

• 以服务重用、灵活重组为目的的服务划分，即面向服务的重用共享设计（SORS，Service-Oriented Reuse-shared Design）

• 还有一个隐形的重点，就是用于承载和适配SOC和SORS的软件实现，即基于服务的软件架构（SOSA，Service-Oriented Software Architecture）

在车载环境中，SOME/IP基本解决了SOC，但SORS呢？SOSA呢？仅有SOC的SOA是没有灵魂的，是不完整，也不可能实现SOA的目标。

3 汽车SOA(v-SOA)怎么实现呢

v-SOA：vehicle SOA，即应用在车辆上的SOA 。SOA在IT领域基本是基于以太网实现的，车载环境下最优的实现方式应该是继承成熟的技术和实现思路。好在车载以太网发展至今也有了几年的积累，国内自主研发应用以太网技术的新一代车型，已经陆续量产发售了。站在车载以太网的肩膀上去实现SOA，无疑是一种不错的选择。

聚焦于汽车电子，接下来从SOC、SORS和SOSA这三点来介绍v-SOA的实现。

① SOC面向服务的通信(Service Oriented Communication)

SOC主要为了实现通信标准化，动态建立通信关系，连接信息孤岛。车载以太网协议架构中的SOME/IP（Service-Oriented MiddleWare over IP）就是基于SOA思想定义的通信中间件。熟悉SOME/IP的朋友都知道，SOME/IP是针对车载环境定义一套通信协议，出自AUTOSAR。可以达到屏蔽系统异构性，实现互操作的目的。所以，就实现SOC而言，我们完全能够通过SOME/IP来完成（当然SOC并非仅能通过SOME/IP来实现，在满足一些前提条件时，其他传输协议也可以使用，比如DDS等）。

通信行为

SOME/IP吸收了RPC机制，顺利地继承了Server-Client的模型。SOME/IP Service Discovery可以让Client灵活可靠地找到Server，并订阅感兴趣的服务内容。Client可以用Request-Response、Fire&Forget的模型访问Server所提供的Services；Server可以利用Notification推送给Client已经订阅的服务内容。由于以太网采用交换机的组网方式，拓扑内以太网节点的交互能够二层转发，网内节点可以动态地建立服务提供与消费的关系，不依赖于其他额外的机制和组件。

例如，订阅机制，高精地图Server向外提供高精地图数据（Offer Service），ADAS控制单元想要订阅其车道线相关信息（Subscribe EventGroup），高精地图Server同意其订阅请求（Subscribe EventGroup Ack），而后Server开始发布高精地图的车道线数据给ADAS控制单元。

再如，请求与响应机制，HU想要获取DVR内存信息，此时DVR是Server，HU是client，由HU向DVR发出request，DVR收到请求后，根据自身当前状态，回复response。

服务接口描述

统一的服务接口描述是跨系统通信的重要组成，SOME/IP有自己的一套序列化原则，系统设计阶段要基于SOME/IP提供的数据类型，统一设计服务接口描述，例如下表，还要进一步定义寻址信息等。

② SORS面向服务的重用共享设计(Service-Oriented Reuse-shared Design)

汽车电子电气架构(EEA)的演进如下图所示：

当前整车架构多处于分布式阶段（下图），车内所有具备以太网通信能力的节点离散地挂在网关上，没有域控制器、中央处理器或者高性能处理节点等概念。如此实现SOC是没有问题的，但是以此实现SOA是有困难的。原因是功能太分散，每个节点的资源由于初期规划功能简单，而不可能预留丰富的资源供量产后新增功能使用和消耗，因此很难在此基础上实现功能重构。

这也是下一代电子电气架构（下图）产生的原因之一，即需要新的架构来适配新的发展需求，本着逻辑上移的原则，可以将更多的实现逻辑置于高性能、多资源的中央类节点之中。

SORS是基于下一代智能网联架构来实现的，主要是完成服务实现，并且体现服务复用性而进行的设计工作。使服务本身高内聚，服务之间能够低耦合，提高服务的可重用性，明确边界概念。

这个事情在什么阶段做？谁来做呢？

在整车功能概念设计阶段，OEM整车电子电气架构部门来做。这样的答案并不出乎意料，毕竟车辆本身的功能还有谁会比架构部门更加如数家珍呢？正如大家所熟知的，伴随着整车功能逻辑的定义和梳理，架构会主导或者参与到需求开发、功能定义、功能实现、子系统设计、零部件设计等过程中去，SORS的实现最好能够贯穿始终，并最终在功能实现的环节体现出来。

具体怎样做呢？

SORS没有技术标准更没有国际规范，只有一些未经全部验证的车载领域的SORS实现方法论。目前来看有两种思路，一是自下而上，二是自上而下。

• 自下而上：由整车末端硬件开始向中心硬件进行梳理和盘点，特定的硬件可以提供相同或者相似的服务。例如，阳光雨量传感器可以提供光照强度和雨量的信息。这样我们就可以抽象出来一个阳光雨量的服务。只要这个硬件在，我们的服务就会在，不受任何约束。之后可以继续向中心探索，挖掘硬件对应的功能、提供的数据等，进行服务抽取。

• 自上而下：由车辆既有功能和业务流程入手。例如整车防盗认证，会有各级防盗认证流程，期间会调用到很多的模块或者算法，比如随机化算法、防盗认证算法等。可以将这些算法抽取出来形成不同的算法服务，从一个个的功能业务链入手，分化抽离出服务库。最后可以逆向重建，即从服务库中挑选出一个个服务模块，通过排列组合的调用就可以将原始的功能业务场景还原出来。

SORS的设计方法对将来功能新增的影响是巨大的。在传统开发模式下，新增功能只能由OEM规划并部署，甚至需要重新开发车型，创意受限，周期长且投入大。在SORS开发模式下，OEM在平台/车型研发阶段将分析车辆本身拥有的一切软硬件资源，并提供重复利用的可能。OEM或授权的第三方可以基于服务库轻松开发新功能，快速完成迭代，并通过OTA技术部署到车端，持续提高用户体验。

③ SOSA面向服务的软件架构(Service Oriented Software Architecture)

Adaptive AUTOSAR这个基于服务理念的中间件，就是一种SOSA。它体现了基于服务的架构思想：运行环境（ara）分成了Foundation和Service两部分。

Foundation： 

CM（Communication Management）包揽了节点间&进程间通信

EM（Execution Management）负责进程控制执行

REST（RESTful）体现外沟通的连通性

PHM（Platform Health Management）系统平台健康管理

TimeSyn（Time Synchronization）时间同步模块

. . . . . .

Service：

SM（State Management）监管了AP上运行的所有功能组和进程的状态转换 

UCM（Update and Config Management）主导的应用程序更新、AP自更新以及OS更新的整套更新理念

NM（Network Management）网络管理模块

Adaptive AUTOSAR作为中间件，需要配合支持POSIX标准的操作系统使用，上层的自适应应用（AA）会通过ARA运行环境由AP来统一配置、管理、调度和分配资源。

4 Adaptive AUTOSAR与SOA

现有的操作系统和架构，比如Android，不能满足SOA基于服务的实现吗？AP也是AUTOSAR推出的，和CP有什么关系呢？为什么要引入AP呢？

• Non-AUTOSAR（信息娱乐）的控制器：占用较大的硬件资源、不具有实时性、运行非车规级的操作系统上（比如Linux、Android）。

• CP AUTOSAR开发出来的控制器：实时性强、消耗资源少、软件资源固定。

• Adaptive AUTOSAR是一种异构的软件平台，可以成为连接Classic AUTOSAR和非实时OS的桥梁。它的特点是：软实时（毫秒级别），满足功能安全要求（ASIL-B以上）、更适合于多核的高资源消耗环境、支持动态部署。

AP和CP都属于AUTOSAR家族，是亲兄弟的关系。CP推出的时间比较早，AP则是2017年才正式出现并有了初版AP规范集。正如大家所知道的，目前CP在各类车载ECU的开发实现中占有很大的使用比例，主要是应对嵌入式ECU的开发。这很符合上文所说的一个盒子一个功能的整车分布式E/E架构的需求，明确具体功能后可以精准地控制ECU本身的软硬件开发，并且CP软件架构的模块化方式配合AUTOSAR OS也可以充分满足一些特定功能对ECU本身运行时的实时性要求。

普通的OS例如Android，在某些场景下不能满足汽车的功能安全需求。此时AP登上历史舞台，作为HPC（High Performance Controller）类型ECU的重要组成部分，AP所做就是统一管理下属OS以及周边资源，使得系统运行时的一切调度、状态和资源消耗都处在一个可控的范围内，以满足车载安全性、确定性的要求。当资源丰富时，可选择的余地就会大一些，比如可以充分利用多核异构架构来处理复杂场景，使用Hypervisor等虚拟化技术，使CP、AP和非AUTOSAR系统共同存在于HPC中。

基于信号和基于服务这两种通信方式如何结合起来，是对新一代E/E架构提出的挑战。Adaptive AUTOSAR这个基于服务理念的中间件，是我们实现SOA的一种不错的选择。