【上汽零束SOA】云管端一体化SOA软件平台系列介绍之二：数字架构篇

本篇为SOA服务软件平台系列的第二篇，零小束希望与各位分享SOA服务平台与整车数字架构的关系以及建立服务架构的设计方法。

一、SOA服务平台在整车数字架构中的应用

1.1 问题与思考

“下一代”电子电气架构是每家OEM都重点关注的项目，它如同一栋大楼的主结构，对建筑物的安全稳定、功能实用、节能环保、以及对外观造型的支撑有决定性的作用。电子电气架构的概念从总线引入汽车开始就不断更新和演化，如今一套完整的整车数字架构所考虑的内容除了传统的拓扑、网络、线束与电气分配、逻辑功能分配，还需结合整车的功能/信息安全架构、数据架构、计算架构，以及实现通讯架构与软件架构的协同，功能架构与服务架构的协同，车内服务与云端服务的协同。

那么针对SOA软件平台的问题来了，它是如何服务于整车数字架构的呢？两者是否有依赖关系呢？SOA软件平台与业内热议的域集中、区域架构又是否有关联呢？

尽管“Next Gen”架构对于每家OEM都不一样，但是参照业内公认的对于架构的演化预测，多数OEM会选择分步走的策略，分阶段进行架构设计。为了简明，本文暂以两类典型架构进行说明。

1.2 Domain Centralized Architecture

域集中架构在连接上由功能域控制器，分别通过子网与各功能域内ECU相连接，而域控制器之间则修建通讯“高速公路”，通过高带宽的骨干网络相连。拓扑结构只是架构的表象，而表象背后的核心特征是功能逻辑被抽象上移至功能域控制器中，缺少这个步骤的域集中架构是没有灵魂的（此步骤也是汽车OEM向智能设备制造商转变所要突破的重点之一，本文不多赘述）。那么回归本文的主题SOA软件平台，域集中架构对于SOA是否有依赖呢？仅从实现投产的角度来说可能仁者见仁，但从平台建设的角度，二者结合就如同齐天大圣与定海神针的相互成就，既可用来协助建立数字架构平台，又可通过SOA软件平台快速而持续地提供更新的用户体验，结论则是显而易见的。

OEM从原本分布式架构过渡到域集中架构的目的有哪些呢？

1)主导功能应用层软件，更好更快的实现迭代和优化用户体验，SOP后低成本持续更新；

2)域内功能集中控制，简化功能间协同的复杂度，解耦域间通讯；

3)在域控制器之间建立高带宽骨干网络，兼容高带宽数据流共享；

4)FOTA软件迭代是智能汽车实现软件持续生长的根本，简化软件迭代复杂度和周期；

SOA软件服务平台是否可以协助这些目标呢？

1)以服务为元素，搭建Application内外部的动态调用关系，平台之上的创新应用可大量减少非必要控制器的软件变更，从而快速更新用户体验；

2)通过服务设计解耦域间通讯，在跨域平台上通过一套标准中间件解决方案，提供标准化的服务接口；

3)服务标准化是利用高带宽骨干网络的重要手段，能够将更多数据和接口通过服务提供出来，实现跨域融合（复杂的智能场景等功能则更易实现）；

4)建立在软件架构基础上的服务平台在需要软件更新时，往往只要识别出需要动态部署的新服务，或者调整调用服务平台的应用，低耦合度的软件平台可以尽可能减少迭代复杂度；

1.3Vehicle Centralized and Zonal Architecture

整车集中和区域架构在连接上是通过分布在车内各物理区域的区域网关/控制器将车内物理I/O分别就近连接和控制，形成整车数字系统的“手”和“脚”，然后通过骨干网络与系统中的“大脑”控制单元进行连接。连接关系同样只是表象，而核心价值在于将车内软件（运算）和硬件解耦，彻底实现软件独立“生长”（或者说算力架构可以迭代，共享算力变成了可能），而硬件同样可以独立“生长”（跨车型平台，或者在车辆生命周期内为用户提供升级服务，而这些在传统架构中实现的成本是不可控的）。

OEM将“辛苦”建立的域集中架构又过渡到区域架构，究竟又是为了什么呢？

1)彻底将每个车型平台都可能调整或升级的硬件I/O从域控制器上解耦出来，避免域控制器因为I/O硬件升级而不得不迭代的问题，并让平台具备向中央计算电脑过渡的前提；

2)区域内直接控制（驱动、连接、供电等等），大大降低Physical Architecture成本，分布控制对于能耗的管控也更加智能

3)软件/算力架构可独立“生长”，与硬件平台解耦

4)硬件I/O平台可独立“生长”或“切换”，与软件架构解耦

SOA软件服务平台是否可以协助这些目的呢？

1)随着通讯量的增大，基于服务与具备实时性能（如TSN技术）的高带宽骨干网络协同的软件平台，对于I/O分离的区域架构有着天然支撑，I/O资源也不再是孤岛；

2)SOA软件平台与区域控制是相辅相成的，其为各个区域网关/控制器提供了标准化的中间件，以及接口层，运算无需再知晓被控对象以及传感器所属的物理连接。因此SOA软件平台为区域控制提供了有力工具，而区域控制也最大化的利用了服务平台所提供的灵活性；

3)经过服务平台解耦出来的运算逻辑，可以根据项目或平台升级动态部署，在一定的硬件框架下，算力平台都可具备在车型平台“无缝生长”（具备了通过域融合而形成中央运算电脑的先决条件），甚至在SOP以后为用户提供按需更新的可能；

4)经过服务平台解耦出来的硬件I/O单元，可以根据项目、技术升级、供应商动态调整，而对整车OS/应用软件几乎不产生影响；

二、服务平台的设计方法

以上介绍了SOA软件平台的意义，那么落地到架构开发流程中，我们如何完成SOA软件平台的设计呢？SOA的引入对传统电子电气架构开发产生了什么影响？

2.1 传统电子电气架构开发

传统的架构开发流程主要由以下几部分工作组成：

(1)用户需求整理

通常由市场部经过一系列的调研之后，结合之前车型，站在用户角度描述了本车型项目所具备的性能，配置要求等，比如具备电动车门，座椅加热等。

(2)功能需求和功能逻辑架构分析

基于上述功能清单，电子电气架构团队将对各个功能的逻辑架构进行分析。将基于用户角度描述的功能，转变为基于技术角度的方案。比如电动车门的工作条件，工作逻辑，故障判断等。在这个过程中，复杂功能会被分解成多个逻辑块。这些逻辑块可以属于不同系统，被分配到不同的硬件上。比如电动车门，需要判断车速条件，车速模块位于底盘系统，而车门控制属于车身系统。因此一个功能往往涉及到多个系统之间的交互。跨系统的交互则引出了网络通信的需求。

(3)系统架构分析

接下来对系统进行进一步细分及需求整合。不同功能可能对同一个子系统都有需求。因此在系统架构分析这一步，需要综合所有需求，针对每个子系统，输出相关需求文档，包含场景需求，输入输出接口，性能需求，HMI需求等。通常在这一步也会完成功能分配，即子系统是由哪个硬件承接完成的。根据功能分配，子系统接口又被分为网络接口和硬线接口。

(4)零部件开发规范

上步完成的功能分配，确定了每个硬件需要实现哪些子系统。零部件开发规范整合所有的子系统需求，完成零部件级别的开发需求，比如硬件接口，系统原理图，收发的网络信号等。

传统的架构开发流程基本上到此结束，最重要的工作在于子系统架构分析，在这一步功能完成了从用户语言到技术语言的转变。然而这种开发流程存在以下几个问题：

(1)系统方案依赖供应商。虽然功能分配在子系统分析之后，但实际上子系统由哪个硬件实现，已经由供应商决定。甚至某些子系统之间的交互接口，也是通过供应商提供的信号清单定义的。

(2)软件架构是黑盒。在整个架构开发过程中，整车厂不参与软件实现方案，只提功能需求。

这样导致的后果是，更换功能变得很被动。因为受限于供应商的方案和ECU软件平台的不同，任何的更新都需要牵扯多方联动，效率低下。

而这又与“软件定义汽车”的理念相违背。软件定义汽车，是希望能够为用户在整车生命周期内都提供持续的应用更新。

因此基于服务的架构引入了新的开发流程，增加了对整车资源的标准接口抽象和软件架构定义。

2.2 服务架构开发流程

服务架构设计和软件架构设计位于逻辑架构设计和系统架构设计之间。

服务架构设计的目的是：

(1)将逻辑块转变为服务参与方（participant），服务参与方之间的交互接口为服务接口（service interface）。每一个服务代表一个独立的功能，具有统一标准的接口。

(2)通过对整车逻辑的分析，将重复的功能整合为一个服务，减少相同的逻辑块，节省成本。

软件架构设计，是关联服务和软件模块，使服务实例化。实例化意味着服务的实现有了载体，相同的服务可以由不同的载体实现，在系统中有不同的实例。比如camera服务，可以被实例化多次，表示整车不同位置的摄像头。

因此，基于服务的架构开发，实际上是以服务的方式对整车的功能进行拆解，将黑盒子的ECU白盒化，为未来扩展和功能更新，提供了良好的基础。软件架构白盒化之后，功能的更新和重新部署都更为透明，快速和便捷。所谓软件定义汽车，只有当我们把硬件的边界打破，软件之间能够互相“看得到”对方，彼此之间用同一种语言交流，才能形成更大的生态系统。

本文重点介绍服务架构的设计方法，软件架构的设计将在接下来的文章中为大家详细介绍。

基于零束以服务为主体的SOA架构能够帮助OEM将整车的硬件能力以原始服务的形式提供向应用层调用，通过可访问的标准化的接口实现车辆功能的软硬件解耦。同时，第三方公司能力也能通过零束SOA软件架构以服务的形式进行接入，为应用层开发者提供更丰富的选择。

鉴于现阶段，整车硬件能力将随车型配置及年改款产生大量变种，零束云端平台将同时实现车型服务与接口管理，确保开发者应用能够动态下发至OEM具备硬件适配能力的车型。

2.3 开发者平台产品

虽然电子电气架构开发从理论上是正向开发，但实际上一款车型的开发并不是完全从零开始的，很多功能方案会沿用老款车型。这样的后果是，系统和软件模块已经固定，即无法通过正向设计的思路拆解逻辑，设计服务。考虑这种情况，服务设计可以分为以下两种方法。

(1)自下而上的方法：

适用于现有平台上已实现的功能或系统。此种方法的基础是，功能的网络分配，通信，ECU软件架构，功能规范和使用场景等都已经有明确定义。我们可以利用现有的这些输入，完成将原有功能对SOA的转换。

适用功能和系统：

•车身舒适的大部分功能，如车门，车窗，座椅，空调等，功能逻辑没有太大争议，就可以通过现有子系统规范和网络信号清单，进行服务接口设计。

•动力和底盘系统。这是整车中对安全要求最高的两个系统，因此一般来说，我们在设计第一代SOA架构时。这两个系统更适合自下而上的方法，通过对已有功能的提取，转换为服务接口，接入整车服务系统。

•传感器和执行器资源。汽车上的每个元件都代表了一种基础能力。基于整车传感器和执行器清单，能够快速形成一份基础服务清单。由此出发，再通过功能梳理，层层往上，可以形成更加丰富多层次的服务列表。

(2)自上而下的方法：

自上而下的方法即为正向设计方法。在基于SOA的电子电气架构开发中，对于复杂功能，或者引入到平台中的新功能和新系统，必须遵循这种方法完成服务设计。基于上述所介绍的开发流程，从需求出发，进行逻辑拆解，服务拆解，软件架构搭建，系统设计等。这个方法所依赖的输入一般是功能需求表和用户场景。

不管使用哪种方法，通常服务的设计是在单个功能或系统级别定义的，最后需要架构师综合考虑整车系统，将高度复用性的服务归类为平台级通用服务。通用服务池子是“生态共创”的基础。

服务的分类

(1)硬件抽象服务

根据ECU的功能和硬件外围设备（传感器和执行器），定义硬件抽象服务。这些服务同时属于平台级核心服务。

示例：Camera interface，Rain sensor interface

(2)平台级核心服务

在应用程序集群和域之间通用的所有服务。

示例：Power mode，Vehicle speed，Key status

(3)域级核心服务

在域内的应用程序集群内不同应用程序之间通用的服务。

示例：Front vehicle distance calculate，Front obstacles

(4)应用服务

为每个特定的应用程序或系统功能服务的服务。

示例：Enable ACC，AEB system status

服务设计的输入要求

(1)应用级别的服务

•功能和系统描述，用户场景描述

•功能和系统需求

•功能和系统逻辑架构

(2)平台级别的服务

•跨域的系统设计文档

•跨域的功能清单

•网络拓扑

•传感器和执行器列表（用于提取硬件抽象服务）

服务设计的输出

在说明服务设计输出之前，我们先来看看一个服务是由哪几部分组成的，以及它和下游软件之间的关系。

-Service：表示一种能力，可以通过定义良好的接口对外提供功能。服务通过唯一的ID进行标识。服务提供方和消费方之间，通过服务接口和ID，建立通信契约。

-Service interface：服务接口，定义了提供方和消费方之间的数据交换方式。包含以下类型：

•Field(setter/getter/notifier)：表示一种属性，可以被设置/读取/订阅

•Method：表示一种方法，通过请求/响应的方式完成调用

•Fire and forget method：表示一种方法，只有请求，无需响应

•Event and event group：表示一种事件，不同的事件可以组成事件组，通过订阅/通知完成调用

服务的调用方式覆盖了原来信号通信中的周期型和事件型报文，可以根据需求自由选择合适的通信方式。

-Service provider：服务提供方，可以通过定义好的接口提供服务内容。

-Service consumer：服务消费方，可以通过定义好的接口调用服务，而无需知道service provider具体在哪里（哪个域，哪个网段）。

*一般来说，一个服务都会至少配置一个provider和consumer。但是某些情况下，consumer是可以不定义的。Provider可以接受任意符合条件的consumer调用。

*一个服务可以有多个provider，被多次实例化（此时instance ID不同）。

*一个服务可以有多个consumer，被多个应用复用。

-Service port：service consumer和service provider上的虚拟端口，分为provider port和consumer port。端口的作用即为传输service interface。一对service port需要映射到同一个service interface，provider和consumer之间才能建立正确的通信关系。

-SW component（SWC）：在软件层面上，代表了实现某个或者某些服务的一个具体的软件组件。可以分为classic AUTOSAR SWC，adaptive AUTOSAR SWC和non-AUTOSAR SWC。

-Composition：SWC的组合，不同层级的组合形成软件架构层。

-Software port：SWC的虚拟端口。在AUTOSAR的定义中，该端口类型可分为sender receiver port和client server port。

*Classic AUTOSAR platform：method对应为client server port，event对应为sender receiver port

*adaptive AUTOSAR platform：所有的service interface类型均对应为client server port。

因此，服务设计的输出主要为

(1)服务的定义

(2)服务接口的定义

(3)服务提供方和消费方信息

(4)软件模块信息

对应的输出文档可以分为

(1)服务定义矩阵

(2)服务详细设计文档（包含软件实现信息）

(3)服务数据库ARXML（涵盖通讯、服务、软件部署等信息）

↑传统电子电气架构开发流程

↑新增服务架构设计流程

↑服务层级关系

↑服务组成

三、思考与研究

3.1 技术实现的思考与研究

讲了这么多服务架构的好处和设计方法，那么实现层面是否存在一些还没有标准答案的问题，值得大家思考并通过建立一套完整的软件服务平台来解决呢？在此抛砖引玉的提出一些问题：

-实时性

用来作为骨干网络的服务架构平台必然要考虑服务调用的实时性，而当前在各个通讯层级以及软件层级中的实时控制策略是否可以通过协同，而形成一套完整的服务实时控制机制呢？

-服务的动态管理

区域架构的一个难点就是如何解决定制化和灵活配置的平衡问题，而服务的管理也必然面临从权限管控，到结合整车不同配置而调整的服务部署策略，如何定义一套动态服务管理机制则是解决问题的关键。

-服务测试平台的搭建

传统的测试手段和工具已经不能满足服务平台的测试需求，搭建一套灵活的基于软件环境的服务测试平台势在必行，来满足服务在软件中的灵活部署以及软件接口测试。

-服务的评价指标

服务的颗粒度划分并没有一个量化的原则，通常由工程师根据功能的逻辑，外部需求，实现难度和成本，综合选择划分方式。但是，这样颗粒度的服务设计是否最优？设计一套可量化的评价体系，对于搭建一套好的服务架构平台非常关键。

-如何将legacy network转化为SOA

对于部分无法直接通过服务架构实现的功能，比如底盘等，目前比较通用的方案是，通过部署在网关中的SOA gateway将传统的SWC转换为SOA SWC。本质上是将信号与服务接口互转，其他的应用可以直接通过服务接口进行调用。SOA gateway的设计需要满足对应的功能安全要求，并且也需要仲裁逻辑，比如是否所有的consumer都可以调用该服务数据，如果同时多个consumer调用，如何进行优先级筛选等。

-功能安全要求

对于ECU来说，不管是否基于SOA架构实现，都需要满足原定的功能安全等级。站在通信的角度，引入基于车载以太网的服务通信，我们也需要设计End2End保护。E2E profile在AUTOSAR中有如下定义，问题在于如何选择合适的profile：

汇总本文的分析，软件服务平台是实现下一代数字架构的基石和有力武器。SOA架构也绝不仅是通讯层面的升级，其落地的关键则是建立软件服务架构，零小束将基于自身对于软件架构的理解，从软件维度为大家带来更多分享，敬请期待！

-----------------------------------------

作者：零小束

文章来源：上汽零束开发者论坛

原文链接： https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7481https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7481https://bbs.z-onesoft.com/omp/community/front/api/page/mainTz?articleId=7481

【上汽零束SOA】云管端一体化SOA软件平台系列介绍之二：数字架构篇相关推荐

SOA+AIOT=无限可能，上汽零束 AIOT 沙龙上海站火热报名中
上汽零束致力于打造融合SOA.AI和IOT为一体的开发者平台,帮助汽车电子企业快速便捷应用SOA.物联网技术,实现在智能汽车时代的竞争力升级.本次活动聚焦在全面解读上汽零束SOA+AIOT的发展布局. ...
SOA+AIOT=无限可能，上汽零束AIOT沙龙上海站火热报名中启动
上汽零束致力于打造融合SOA.AI和IOT为一体的开发者平台,帮助汽车电子企业快速便捷应用SOA.物联网技术,实现在智能汽车时代的竞争力升级.本次活动聚焦在全面解读上汽零束SOA+AIOT的发展布局. ...
社会招聘 | 上汽·零束科技智驾计算平台全球招募人才
更多智能车招聘信息,请关注零束SOA开发者论坛https://bbs.z-one.tech/
嘉为蓝鲸携手东风集团、上汽零束再获信通院四项大奖
7月28日,由中国信息通信研究院主办的"2022 首届XOps产业生态峰会"在北京隆重召开.本次大会以"智效赋能·价值引领,共筑XOps新蓝图"为主题,嘉为蓝鲸 ...
零束银河全栈技术解决方案之网络安全
当汽车遇上互联网,产业快速融合,狂拽炫酷的"车联网"横空出世,科幻片中的智能汽车已经走进现实!"软件定义汽车"成为新的潮流!智能网联汽车在方便人们出行的同时,也 ...
Neptune CHT-C助力零束打造智舱界王者
9月27日,上汽子品牌飞凡汽车的首款旗舰车型--飞凡R7刚一上市就牢牢吸引了众多视线,在了解了其配置后,用户纷纷称其为"智驾界卷王". 飞凡R7搭载的RISING MAX 3+1巨 ...
零束科技获得中国信通院“2022 XOps产业生态峰会优秀案例”奖
近日,在中国信息通信研究院主办的"2022首届XOps产业生态峰会"上,"零束科技DevSecOps研运一体化平台建设项目"荣获"研运质效典范标杆案例 ...
2009年SOA七大预测：SOA借力云计算
1.对云计算的兴趣(WOA.Web 2.0)将会推动许多企业采用SOA架构. 对于那些想要充分利用"埋藏"在"云"中的资源的企业来说,它们很快就能理解只有将他们 ...
服务金融机构数字化升级，阿里云发布一体化金融移动端平台
8月26日,2022阿里云金融创新峰会期间,阿里云正式发布一体化金融移动端平台. 新平台可支持金融机构打造全新的交互体验型超级APP,包括更多样的沉浸式交互.更开放的场景体验.更智能的数字化运营以及更 ...
【无标题】深圳卫视专访行云创新马洪喜：拥抱AI与云原生，深耕云智一体化创新
人工智能(AI)是引领新一轮科技革命和产业变革的重要驱动力.因此,深圳出台相关行动方案,统筹设立规模1,000亿元的人工智能基金群,引导产业集聚培育企业梯队,积极打造国家新一代人工智能创新发展试验区和 ...

【上汽零束SOA】云管端一体化SOA软件平台系列介绍之二：数字架构篇

【上汽零束SOA】云管端一体化SOA软件平台系列介绍之二：数字架构篇相关推荐

最新文章

热门文章