谈谈关于SOA的几个问题.docx

谈谈关于SOA的几个问题.docx

《谈谈关于SOA的几个问题.docx》由会员分享，可在线阅读，更多相关《谈谈关于SOA的几个问题.docx（9页珍藏版）》请在冰点文库上搜索。

谈谈关于SOA的几个问题

谈谈关于SOA的几个问题

一、为什么汽车要上SOA？

老车新体验，快速满足市场需求

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

车辆内部控制器通过传统总线连接，从而实现通信交互，但是信号的收发关系和路由信息通常是静态的、不可再更改的，如果后期突然新增节点，改矩阵和路由表？

再如果车辆上市后想新增一个功能到某个控制器，OTA可以将软件包本身下载到该控制器，但这个新“朋友”怎样从其他节点获得所需信息呢？

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

OTA是目前解决车辆在线升级，持续提高用户用车体验的好方法，一个功能一个盒子的时代已经过去了，但…OTA仅仅是途径，车辆的电子电气架构和软件设计架构能否支持得起功能更新呢？

如果一个新增功能的实现，与车辆原有的系统架构、驱动方式甚至通信方式不匹配，甚至相冲突，肯定是不可行的。

那么应该怎样解决呢？

万物互联，汽车要进物联网

汽车在不久的将来会在互联网、物联网、能源物联网中都占有重要的地位，那么汽车必须具备开放性、网联性甚至自主性和自进化性，自动驾驶、V2X、边缘计算都是目之可见的应用场景，电子电气架构和软件平台架构在面对这样需求的时候，应如何处理？

已有的电子电气架构及相应的解决方案，很难对应并且解决目前汽车所遇到的挑战，需要新的方法论来打破僵局，于是SOA的车载运用作为解决方案被提了出来。

二、为什么说SOA=SOME/IP的话，就低估了整件事？

先说说，什么是SOA（Service-OrientedArchitecture）呢？

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

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

”

🔹 XX百科告诉我们，面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。

接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。

SOA的概念出自IT界，然而也还没有大家公认的定义，但是SOA的目标及其应具有的特性却是清晰明了的：

∙目的：

构建灵活可变的平台系统

∙特性：

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

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

     服务通信标准化

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

🔹 服务通信标准化，即面向服务的通信（SOC，Service-OrientedCommunication）

🔹 以服务重用、灵活重组为目的的服务划分，即基于服务的复用共享式设计（SORS，Service-OrientedReuse-sharedDesign）

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

在车载环境中，SOME/IP基本解决了SOC，但SORS呢？

SOS呢？

仅有SOC的SOA是没有灵魂的，是不完整，也不可能实现SOA的目标，故而，若认为SOA=SOME/IP的话，你真的低估了SOA。

图1SOA示意图

三、v-SOA怎么实现呢？

v-SOA：

vehicleSOA，即应用在车辆上的SOA。

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

聚焦于汽车电子来说，可以从SOC（ServiceOrientedCommunication）、SORS（Service-OrientedReuse-sharedDesign）和SOS（Service-OrientedSoftwareArchitecture）的介绍v-SOA的实现。

SOC（ServiceOrientedCommunication） 

SOC主要为了实现通信标准化，动态建立通信关系，连接信息孤岛。

车载以太网协议架构中的SOME/IP就是基于SOA思想定义的通信中间件，熟悉SOME/IP（Service-OrientedMiddleWareoverIP）的小伙伴会知道，SOME/IP是针对车载环境定义一套通信协议，出自AUTOSAR，可以达到屏蔽系统异构性，实现互操作的目的，所以，就实现SOC而言，我们完全能够通过SOME/IP来完成（当然SOC并非仅能通过SOME/IP来实现，在满足一些前提条件时，其他传输协议也可以使用，例如DDS等）。

通信行为：

SOME/IP吸收了RPC机制，顺利地继承了Server-Client的模型，SOME/IPServiceDiscovery可以让Client灵活可靠的找到Server，并订阅感兴趣的服务内容，Client可以用Request-Response、Fire&Forget的模型访问Server所提供的Services；Server可以利用Notification推送给Client已经订阅的服务内容。

由于以太网采用交换机的组网方式，拓扑内以太网节点的交互能够二层转发，网内节点可以动态的建立服务提供与消费的关系，不依赖于其他额外的机制和组件。

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

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

图2SOME/IP通信示例

服务接口描述：

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

SORS（Service-OrientedReuse-sharedDesign）

当前整车架构多处于分布式阶段（如下图1所示），车内所有具备以太网通信能力的节点离散的挂在网关上，没有域控制器、中央型处理器或者高性能处理节点等概念。

如此实现SOC是没有问题的，但是以此实现SOA是有困难的，原因是功能太分散，每个节点的资源由于初期规划功能简单而不可能预留丰富的资源供量产后新增功能使用和消耗，故很难在此基础上实现功能重构，这也是为什么会有下一代电子电气架构（e.gDomain、Zone，如下图2所示）的原因之一，即需要新的架构来适配新的发展需求，本着逻辑上移的原则，可以将更多的实现逻辑置于高性能、多资源的中央类节点之中。

图一分布式EE架构示意

图二下一代EE架构示意

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

那…这个事情在什么阶段做？

谁来做呢？

在整车功能概念设计阶段，OEM整车电子电气架构部门来做。

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

那…具体怎样做呢？

SORS没有技术标准更没有国际规范，最多有未经全部验证的车载领域的SORS实现方法论。

目前来看有两种思路，一是自下而上，二是自上而下。

∙自下而上：

由整车末端硬件开始向中心硬件进行梳理和盘点，特定的硬件可以提供相同或者而类似的服务，例如，阳光雨量传感器就可以提供光照强度和雨量的信息，这样我们就可以抽象出来一个阳光雨量的服务，只要这个硬件在，我们的服务就会在，不受任何约束。

之后可以继续向中心探索，挖掘硬件对应的功能、所提供的数据等，进行服务抽取。

∙自上而下：

由车辆既有功能和业务流程入手，例如整车防盗认证，会有各级防盗认证流程，期间会调用到很多的模块或者算法，比如随机化算法、防盗认证算法等，可以将这些算法抽取出来形成不同的算法服务。

从一个个的功能业务链入手，分化抽离出服务库，最后可以逆向重建，即从服务库中挑选出一个个服务模块，通过排列组合的调用就将原始的功能业务场景无差的还原出来。

SORS的设计方法对将来功能新增的影响是巨大的。

在传统开发模式下，新增功能只能由OEM规划并部署，甚至需要重新开发车型，创意受限，周期长且投入大。

在SORS开发模式下，OEM在平台/车型研发阶段将分析车辆本身拥有的一切软硬件资源，并提供重复利用的可能。

OEM或授权的第三方可以基于服务库轻松开发新功能，快速完成迭代，并通过OTA技术部署到车端，持续提高用户体验。

SOS（ServiceOrientedSoftwareArchitecture）

针对面向服务的架构体系，ECU相关的软件架构，即SOS，也在努力适配。

AUTOSARAdaptiveplatform，简称AP，一个基于服务理念的中间件，就是个很好的例子。

其体现了基于服务的架构思想：

运行环境（ara）分成了Foundation和Service两部分

图三AP软件架构示意

Foundation：

∙CM（CommunicationManagement）包揽了节点间&进程间通信

∙EM（ExecutionManagement）负责进程控制执行

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

∙PHM（PlatformHealthManagement）系统平台健康管理

∙TimeSyn（TimeSynchronization）时间同步模块等；

Service：

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

∙DM（DiagnosticManagement）能够以AAP的粒度进行刷写和诊断

∙NM（NetworkManagement）网络管理模块

∙UCM（UpdateandConfigManagement）主导的应用程序更新、AP自更新以及OS更新的整套更新理念等；

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

那…AP也是AUTOSAR推出的，和CP有什么关系呢？

为什么要引入AP的概念呢？

现有的操作系统和架构，比如Android，不能满足SOA基于服务的实现吗？

AP和CP都属于AUTOSAR家族，是亲兄弟的关系。

CP推出的时间比较早，AP则是2017年才正式出现并有了初版AP规范集。

正如大家所知道的，目前CP在各类车载ECU的开发实现中占有很大的使用比例，主要是应对嵌入式ECU的开发，这很符合之前我们聊到的一个盒子一个功能的整车分布式EE架构的需求，明确具体功能后可以精准的控制ECU本身的软硬件开发，并且CP软件架构的模块化方式配合AUTOSAROS也可以充分满足一些特定功能对ECU本身运行时实时性要求。

随着下一代架构的智能网联化发展，要求一些节点具备处理海量数据和执行大规模高频次算例的能力，这就必然会要求此类节点具备丰富的软硬件资源，同时满足车载环境下安全性的要求。

该背景下，擅长用于嵌入式ECU的CP就显得心有余而力不足了。

当然普通的OS同样也满足不了这一需求，例如Android，某些场景下它不能满足车载功能安全需求。

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

当资源丰富时，可选择的余地就大些，比如可以充分利用多核异构架构来处理复杂场景，使用Hypervisor等虚拟机技术，使CP、AP和非AUTOSAR系统共同存在于HPC中，也算是一种典型的实现方法，当然一切从需求出发。