您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 
 订阅
汽车SOA技术闲谈
 
 
  2043  次浏览      17 次
2021-8-16 
 
编辑推荐:
本文主要讲解了SOA与软件定义汽车、行业现状、SOA到底有什么好处?实现SOA的成本如何?及SOA带来的挑战 。
本文来自于微信公众号燃云汽车,由火龙果软件Linda编辑、推荐。

1 SOA与软件定义汽车

"软件定义汽车" 已经成为一个不可逆的趋势,其基本的意思是指汽车的功能及性能,之后将更多的由软件来决定。当然,业内也有不同的声音,如"架构定义汽车"等等,其本质差不多。

那么,在"软件定义汽车"的趋势下,”SOA“到底处于什么样的位置呢?

右图是历史上的经典”马拉火车“,当年中国第一条铁路修好后,因慈禧不喜欢火车头的“大呼小叫”,导致很长一段时间列车都是让马与驴拉的。

左图呢,由于受汽车行业的惯性思维影响,整车开发流程都是先定EEA,然后定点各ECU或沿用车型平台的ECU,放在前些年就没有然后了。近年来受”软件定义汽车“的影响,同时还会确定”哪些自研,哪些由Tier1开发“。但这还是不够的,如果不搞SOA,就算EEA升级、控制器升级、软件自研,他们也很难高效的运转与支持迭代。

空口无凭,接下来我们来详细的展开吧。

2 行业现状

这里借用几张出现频率较高的图来说明一下:

大众MEB E3 EEA

大众MEB平台的E3架构,采用千兆Ethernet,规划了3个ICAS(应用服务器),在软件层面上采用了SOA的架构。

现代(Hyundai)的EEA - 引用自《浅谈整车SOA架构系列》

现代的EEA也是将Ethernet纳入主干网,同时在Ethernet连接的结点采用了SOA架构。

国内上,在此领域走的比较靠前的“华人运通”,参考其官方宣传稿,采用了“HOA开放式EEA”,使用了千兆以太网,拥有6个超级域计算平台,并实现了“真正意义的软件与硬件分离”。从技术语言来说,同样采用了SOA架构。

结论就是,从国际和国内上的各种公开信息来看,凡是将Ethernet纳入主干网的车厂,都在其上采用SOA的架构。

3 SOA到底有什么好处?

SOA将跨ECU交互由“基于信号的通信”变为“基于服务的通信”,其意义抽象的讲,有以下方面:

应用服务化,使“全车智能”成为可能

服务的灵活部署

软件更新/升级更快速

服务高内聚,软件易重用

光讲这些太抽象,作为长期战斗在一线的软件架构师,上向领导汇报,下说服工程师,最有效的办法就是讲“场景”。下面一个个展开吧。

3.1 “全车智能”成为可能

服务化,各个域将自己的能力提供出来,在权限允许的情况下,供大家随意使用。这样的话,”智能“就不仅是体现在”智能座舱“、”智能驾驶“领域,也可以是”智能车身“、”智能底盘“等等。举几个具体的例子。

1) 智能交互的开放 —— APA(自动泊车)过程中语音提示

当前基于CAN通信,就是APA控制器提供CAN信号,中控接收到之后,根据APA的状态做用户提示。但是,一般来说搞中控的人对APA一点都不懂,很容易出各种问题。

SOA的做法,中控大屏提供TTS服务,APA控制器自行使用。

2) 车控能力的开放 —— “跳舞”模式 (Tesla Model X)

当前基于CAN通信,”跳舞“这个应用较为复杂,包含音乐、车身、前后运动等,其逻辑会分拆到多个控制器中,且基于各种安全因素的考虑,不一定会将直接的控制能力暴露出来。

基于SOA,各域可抽象出通用的服务出来,如”极低速控制服务“和”车身/灯光控制服务“出来,而”跳舞“相关的应用逻辑,就可以完全放在中控应用当中了。

3) 多域能力的开放与融合 —— 智能车窗

当检测到下雨时,自动将车窗关闭,并通过语音及界面来提示用户。

当前基于CAN通信,车身控制域提供“雨量传感器”的状态、“车窗控制”的信号,一切由中控大屏来实现。但说实话,这功能跟“中控大屏”有什么关系?因为是否与用户交互是可选项,并非此功能的核心。

基于SOA,中控将“通知”与“语音播报”的能力提供出来,车身控制域在发现“下雨”时,调用“车窗控制”,基于用户的习惯,选择合适的方式与用户交互,甚至于说不交互。

由于笔者为智能座舱背景,举的例子多半与智能座舱相关。相信其他领域的小伙伴,会有更多的用户场景可讲。

3.2 服务的灵活部署

SOA的一个基础,就是“服务发现”机制,即给每个服务分配一个“全局名称”,通过这个名称就可以直接找到对应的服务。比如我们上网时的“网址”就是起的这种作用。这样的好处是:

可以在ECU运行时获取服务的位置。继续以“网址”为例,"ele.me"的服务器到底部署在哪,我们是不知道的,当我们输入"ele.me",DNS服务器会解释其IP地址,并通过动态路由的方式找到拥有这个IP地址的服务器。大白话的说:"不管你在哪里,只要不改名,我都能找到你"

所以,基于这个特性,在整车生命周期内,不同的车型配置可做不同的服务部署,对代码几乎可以不用改动。以笔者较为熟悉的OTA,来说明吧:

基于SOA的OTA逻辑架构

上图中,带SOC的ECU都连接了Ethernet,需要基于SOA Middleware来提供标准的OTA Service,如版本号查询、自升级控制、升级状态反馈等;不带SOC的ECU,通过CAN连接网关,则通过UDS直接刷新。其中所有的Service的部署都与位置无关。

举个例子,拿OTA中最最最要命的”升级主控“的选择来说吧。”升级主控 (OTA Master)“是OTA的核心,其功能一般包含:版本检测、升级状态控制、回滚、状态上报、合法校验等。升级主控放在哪个ECU上,是整个OTA方案争议最大,最重要的决策之一。但问题是,同一个项目,因为不同配置的关系,它还要放在不同的ECU上。比如说,

放中控大屏上,低配车没有大屏怎么办?

放Tbox上,高配是5G,低配是4G,供应商还不一样怎么办?

放网关上,高配带SOC,低配只是个CAN网关怎么办?

采用SOA架构的OTA方案就没有这个问题。

升级主控由网关换成Tbox

如上图中,升级主控由网关换为Tbox,也只需要重新部署OTA Master Service和OTA UDS Service即可。其他的不变。

而传统架构的OTA方案,改动升级主控?大工程啊。除了服务要重新部署,相关的通信协议也需要改动,代码也要做一定的修改,麻烦。

3.3 软件更新更灵活

SOA的松藕合特性,可以将功能更新与变更限制在更小的范围内。

1) 硬件架构需要调整,减少复杂功能涉及的ECU数量

车控域发生域融合

如上图,基于SOA的架构,车控域发生域融合时,应用可以直接做重新部署,而无需重新开发,改动限制在服务的实现上。

若不基于SOA实现,发生域融合时,所有功能几乎都要重头开始。

2) 软件架构需要更新,一个功能改变只需要更新/升级部分软件

增加"空调滤芯寿命显示"功能时传统方式与SOA方式的对比

如上图,“增加PM2.5滤芯寿命显示”这一功能,传统方式有4处的改动,而SOA方式仅有2处。

4 实现SOA的成本如何?

4.1 内部成本

SOA在很多年前,某些Tier 1就已经在搞了,但由于设计过于理想,开发成本过高,且运行效率较低,放弃了。

在理想架构下,不同的控制器的应用与服务可以任意的通信,它们全都使用跨ECU IPC。但是,这样实现:

成本极高,比如Android源生支持binder,要把所有应用都改为使用新的IPC。Linux也一样,源生都是使用dbus,其对跨ECU通信支持较差,也要改为使用新的IPC,代价非常大。

运行效率低,跨ECU的IPC,其一定比ECU内IPC更重,资源消耗大、时延大。

所以,考虑实际,可落地架构是指

大部分的ECU中,内部通信使用源生的IPC,保证效率、降低开发成本。跨ECU通信,通过专门的proxy / adaptor来做中继。这种proxy / adaptor依据情况在同一ECU内可以有多个。

在某些业务逻辑较为简单的ECU内,可以采用跨ECU的IPC,方便后续移植。

所以,只有采用上图中的可落地架构,才能做到内部成本可控。

4.2 外部成本

要实现SOA,有不少的工具、组件需要向外部购买,其成本如何呢?是否可以分步走呢?

1) 基础版本:仅支持所有带SOC的ECU之间的服务调用。

成本:最低可以为0。

对于SOC上运行的操作系统,如Linux, Android, QNX而言,SOA是十分自然的过程,其源生的就支持IPC(跨进程通信),如binder, dbus等。在这种情况下,可选用的跨ECU的IPC就不少,如SOME/IP,DDS-RPC(DDS支持RPC的版本),fdbus (Jeremy大神写的)等等。

但由于免费的DDS-RPC及fdbus等方式,不被Classic AutoSAR支持,所以后续扩展会有一定的问题。

2) 进阶版本:支持所有ECU之间的服务调用,但不支持实时业务

成本最低为单件百万级别

目前可选的跨ECU通信中间件,只有SOME/IP,且最好选择商业版的。因为虽然Genivi有开源的vSOMEIP,但是是否量产还是个问题。

3) 专业版本:支持SOC内的应用升级(Software OTA)

成本为单件几百万至千万级别。

先解释一下SOTA。业界叫的OTA,通常指的是FOTA (Firmware OTA),而严格意义上的OTA分别3个级别:

Firmware OTA:固件升级。升级的对象为整个系统,通常不包含bootloader。风险最高,对可靠性要求也最高,升级频率1~3个月。

Software OTA:应用升级。升级的对象为单个或多个应用。风险中等,最严重的就是某个功能用不了,对可靠性要求中等,升级频率可以高至每个星期。

Data OTA:数据升级。升级的对象为应用内部的数据。风险低,最严重的就是某个子功能出问题,对可靠性要求低,升级频率随意。

目前来看,除了Android系统,其他系统最直接的方式就是上AutoSAR AP。但是个人比较质疑其效果,就拿源生支持SOTA的Android而言,对于深度定制的中控大屏系统,目前有哪一家支持SOTA?原因是,SOTA听起来简单,但对组织的能力要求很高,每次升级某个应用,都需要清楚的知道其依赖关系,而实行SOA架构的系统,其依赖关系往往错综复杂,很容易出错。

因此,AP平台需要慎重考虑。

4) 极致版本:支持跨ECU的实时通信

成本:上亿?

方式是选择TSN,使Ethernet上的部分业务达到CAN同样的实时性。当初Ethernet为了高吞吐量,采用了CSMA/CD,而CAN为了实时性,采用了CSMA/CR。采用TSN的Ethernet集齐了两者的共同优点,可谓完美。但现实是,目前其标准仍在修改中,且尚无车厂量产。

5 SOA带来的挑战

最后,简单总结一下,SOA的本质是让汽车变成一个真正的分布式系统,就像阿里的“飞天”一样。各自为战的ECU功能设计将被打破,取而代之的是分层式的架构设计与实施。

SOA分层式的架构也不是一蹴而就的,就跟软件行业的操作系统的发展一样,也是增加功能 -> 抽象的不断循环往复。

其将给我们带来变革与挑战:

人才的挑战:整车的功能分解与交互时序定义将由ECU级别(只管ECU的输入输出),下降至模块级别(要管ECU的各个模块的输入输出)。同时需要软件架构与EEA领域的知识。

功能的集成:跨多个ECU功能交互成为常态,在零部件仍大部分由Tier1提供的情况下,OEM功能的集成是个大问题

主导权的争夺:SOA需要OEM来主导各个ECU的对外提供的服务,以达到平台化的目的,可强势Tier1们愿意吗?

 

 
   
2043 次浏览       17
相关文章

中央计算的软件定义汽车架构设计
汽车电子控制系统中的软件开发过程
一文读懂汽车芯片-有线通信芯片
OTA在汽车上有哪些难点痛点?
相关文档

汽车设计-汽车的整体结构及动力系统
自动驾驶汽车软件计算框架
SysML在汽车领域的应用实践
电子电气架构-大陆汽车系统架构平台
相关课程

AutoSAR原理与实践
功能安全管理体系(基于ISO26262)
MBSE(基于模型的系统工程)
基于SOA的汽车电子架构设计与开发

最新活动计划
MBSE(基于模型的系统工程)4-18[北京]
自然语言处理(NLP) 4-25[北京]
基于 UML 和EA进行分析设计 4-29[北京]
以用户为中心的软件界面设计 5-16[北京]
DoDAF规范、模型与实例 5-23[北京]
信息架构建模(基于UML+EA)5-29[北京]
 
 
最新文章
在EA中内嵌文档- Artifact
EA中模型视图
EA中的实体关系图
使用EA进行风险建模
EA中的项目词汇表
EA的模型导出或导入csv文件
自定义表格(Custom Table)在EA中的使用
Gap Analysis Matrix(差距分析矩阵)
更多...   
MBSE工具
MBSE平台
建模工具 EA
模型库-Model Center
需求管理-ReqManager
自动建模-Modeler
多级仿真-Sys Simulator
代码工程-Code Engineer
文档生成器-DocGenerator
更多...   
成功案例
广汽研究院 SysML+EA+软件分析设计
高合汽车研发部门 建模工具EA、WebEA、学习视频
国汽智联 建模工具EA、模型库、WebEA和iSpace
亿咖通 MBSE工程体系与工具链咨询
中航无人机 MBSE工具链
吉利汽车 购买EA工具
华科汽车零部件 购买EA工具
东风岚图汽车 购买EA工具 以及EA定制开发
更多...