SOA=SOME/IP？你低估了这件事 | 第二弹

​        哈喽，大家好，第二弹的时间到~上文书说到v-SOA可以通过SOC、SORS和SOS来分解落地，第一弹中已经聊了SOC的实现，这部分也是国内各大OEM正在经历的阶段，第二弹，我们继续聊SORS和SOS的内容。

 

•  （三）v-SOA怎么实现呢？

SORS(Service-Oriented Reuse-shared Design)

        当前整车架构多处于分布式阶段（如下图1所示），车内所有具备以太网通信能力的节点离散的挂在网关上，没有域控制器、中央型处理器或者高性能处理节点等概念。如此实现SOC是没有问题的，但是以此实现SOA是有困难的，原因是功能太分散，每个节点的资源由于初期规划功能简单而不可能预留丰富的资源供量产后新增功能使用和消耗，故很难在此基础上实现功能重构，这也是为什么会有下一代电子电气架构（e.g Domain、Zone，如下图2所示）的原因之一，即需要新的架构来适配新的发展需求，本着逻辑上移的原则，可以将更多的实现逻辑置于高性能、多资源的中央类节点之中。当前整车架构多处于分布式阶段（如下图1所示），车内所有具备以太网通信能力的节点离散的挂在网关上，没有域控制器、中央型处理器或者高性能处理节点等概念。如此实现SOC是没有问题的，但是以此实现SOA是有困难的，原因是功能太分散，每个节点的资源由于初期规划功能简单而不可能预留丰富的资源供量产后新增功能使用和消耗，故很难在此基础上实现功能重构，这也是为什么会有下一代电子电气架构（e.g Domain、Zone，如下图2所示）的原因之一，即需要新的架构来适配新的发展需求，本着逻辑上移的原则，可以将更多的实现逻辑置于高性能、多资源的中央类节点之中。

图一 分布式EE架构示意

 

图二 下一代EE架构示意

 

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

 

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

 

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

 

•  那…具体怎样做呢？

 

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

 

•  那…具体怎样做呢？

 

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

 

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

 

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

 

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

SOS(Service Oriented Software Architecture)

​        针对面向服务的架构体系，ECU相关的软件架构，即SOS，也在努力适配。AUTOSAR Adaptive platform，简称AP，一个基于服务理念的中间件，就是个很好的例子。其体现了基于服务的架构思想：运行环境（ara）分成了Foundation和Service两部分

 

图三 AP软件架构示意

 

Foundation：

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

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

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

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

    ♦  TimeSyn（Time Synchronization）时间同步模块等；

 

Service：

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

    ♦  DM（Diagnostic Management）能够以AAP的粒度进行刷写和诊断

    ♦  NM（Network Management）网络管理模块

    ♦  UCM（Update and Config Management）主导的应用程序更新、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软件架构的模块化方式配合AUTOSAR OS也可以充分满足一些特定功能对ECU本身运行时实时性要求。

 

​        随着下一代架构的智能网联化发展，要求一些节点具备处理海量数据和执行大规模高频次算例的能力，这就必然会要求此类节点具备丰富的软硬件资源，同时满足车载环境下安全性的要求。该背景下，擅长用于嵌入式ECU的CP就显得心有余而力不足了。

 

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

 

​        进度条撑又不住了，本次的分享先告一段落，最后的第三弹，我们聚焦于各大OEM，看看他们都是如何实现自己的SOA，我们下期再见~~

 

经纬恒润

北京市海淀区知春路7号致真大厦D座6层

电话：010-64840808

邮箱：market_dept@hirain.com

网址：www.hirain.com