基于AUTOSAR的SOAOTA方案实践

2022-09-01 07:09 来源:网络   阅读量:16324   

2022年8月5日,由盖世汽车和AUTOSAR联合主办的第三届软件定义汽车论坛暨AUTOSAR中国日在武汉举行。聚焦软件定义汽车,探讨软硬件解耦、域控制器、SOA架构、高性能通信中间件等行业焦点和技术话题。Airabi副总裁吕英侃受邀出席活动,并发表了题为《一个以自适应AUTOSAR升级设计方案为参考的SOA OTA方案实践》的主题演讲。组织以下演讲内容:

埃拉比副总裁卢英侃

以下为演讲实录:Elabi OTA的进化,从面向流程到面向服务的OTA

伊拉比是中国第一家进入汽车行业的OTA技术服务公司。当时整个汽车行业的OTA处于发展初期,业内对OTA知之甚少。大多数整车架构采用传统的电子电气架构。基于自身的OTA技术研发实力,切入汽车行业后,Airabi开始了长达一年的与OEM厂商的频繁沟通,推出了第一代产品OTA 1.0版本,即面向流程的OTA产品。之后随着技术的革新和大量整车项目的经验积累,Airabi OTA产品也在不断迭代和进化。

面向流程的OTA

Irabi第一代OTA 1.0版本主要基于面向流程的开发,具有平台定制度高的特点。

虽然面向流程的OTA使汽车能够升级,但它也有一些自身的问题:

1.平台扩展性差,维护成本高;

2.模块之间耦合度很高,匹配新模型的工作量大;

3、车云通信、车内通信等强绑定,依托智能设备本身的升级能力;

4.升级成功率比较低。

所以这个版本下的OTA时代,我们称之为组件级的升级阶段。现阶段很多车不具备整车升级的条件,很少有车厂做整车升级,更多的是针对智能零部件的升级。

Ellabi OTA2.0——面向产品的OTA

随着汽车行业的发展和大量OTA项目在Airabi的实践,2018年和2019年,Airabi对整个产品进行了重新构建和分层,将各个功能模块进行了划分,形成低耦合度的整体结构,对各个功能模块和整车台架进行了全方位的测试。这一阶段,产品质量和成功率大幅提升,Airabi OTA进入2.0版本,即面向产品的OTA。

同时,2.0产品还依赖于Airabi的两大核心技术:

一个是差分算法,我们有国内领先的差分约简效率;

另一个是诊断引擎:Airabi采用了私有化的引擎协议,可以在5M RAM空间运行,基本适配大部分国产机型的刷新引擎,可以支持10路刷机和写机,充分利用了以太网的传输能力,后续将扩展能力支持生产线升级。

关于OTA产品架构的思考:

OTA产品的典型架构一般是主控下的网关,通过以太网连接,网关下会有域控。就主控而言,一般分为两大模块。一个模块是管理模块,另一个模块是车内的诊断引擎和车内的数据处理和协议站。他们之间分工比较明确,一个负责管理,一个负责执行。

综合来看,我们可以看到目前产品中大量的模块都是复用的。背后的FOTA业务、DOTA业务、SOTA业务,如果三套系统分布在一辆车上,不仅会给车辆主控带来负荷,还会给软件维护带来麻烦。但是,诊断引擎理论上是内部一致的。

面向服务架构的Ellabi OTA 3.0-OTA

我们认为AUTOSAR面向服务的理念和思路非常适合我们在OTA领域的应用。

从AP SOA的典型架构来看,汽车内部一般分为外网和内网。内部网络的安全级别较高,而外部网络的安全级别较低。外网模块有TBOX、HUT、GW,实际中可以作为主控,但各有特点。其实很多车辆外网是不能直接接入内网的,必须经过网关认证后才能接入内网。

从架构的三个主要控制功能:

1.Gateway非常适合担任诊断引擎和数据管理的角色,但是gateway的资源非常昂贵,因为虽然现在大部分公司都使用高端芯片,但是承担的业务和功能非常多,资源非常昂贵和稀缺。从这个角度来说,不适合什么都承担。

2.总的来说,TBOX是一个半封闭系统,属于中等水平。另外,TBOX天生具备上网能力,有4G模块,会有计算能力的冗余。如果我们利用计算能力的冗余,我们实际上可以做出管理决策。因为我们的OTA管理本身对计算能力要求不高。

3.HUT可以安装在外部。软件本身安全性不是很高,让它来扮演人机交互的角色更合适。

就整个架构而言,现在这三种类型的主大部分都放在单个零件上。但从合理性的角度来看,根据不同部位的安全性、资源性和整体承载能力分别进行调配更为合理。

分离的概念是AUTOSAR的SOA概念的一个体现。

Airabi面向服务的OTA3.0架构主要包括云和客户端架构。

云采用微服务架构,车和云都是面向服务的SOA架构。云包括车载软件版本管理平台,提供零部件软件版本、配置字、功能等管理。,并向FOTA/SOTA提供要使用的版本或功能信息。

客户主要负责车云互动和整个OTA的管理,包括不同的项目和模式。车云互动会用到很多软件,以上协议可以统一管理。

最后,运营OTA架构的思考

回顾1.0-3.0的各个阶段,首先1.0版本是经过业务提炼和总结形成的;然后,将这些业务流程和体验变成产品化的流程,形成2.0版本;然后,产品化和模块化的融合是面向服务的,形成了3.0的流程。3.0是面向整车的服务阶段,将车内所有OTA业务打通,将所有RD、生产、销售、售后服务串联起来。

经过多年的技术研发和沉淀,整个产品的完善性和适用性都非常高。

但是通过大量的实践,我们发现产品的技术显然已经非常成熟了。但是随着汽车软件运营需求的爆发,OTA在运营中会遇到大量的应用场景,这给我们OTA带来了新的思考和方向。

目前,OTA是为RD内部部门设计的。人们更关注技术,包括SOA,大部分都是技术环节,但是应用环节和业务环节还没有完全融合。从应用的角度来说,面向售后和软件可卖,最后是面向用户。这个经理应该是售后经理。

以远程诊断为例。对于具有远程诊断功能的汽车,车端的诊断引擎会一直监控车辆故障状态,一旦出现故障,会收集故障的相关数据。同时会通过TSP、TSP进行后续客服,比如通知4S店铺或者车主;同时,远程诊断系统可以对车辆故障进行判断和决策,4S商店可以为维修做准备。整个系统采用顶层设计,业务流程顺畅,大大提高了售后能力。

就Irabi而言,我们的服务是为未来基于“XOTA”产品体系的软件定义汽车和运营提供更多的工具和支持。

郑重声明:此文内容为本网站转载企业宣传资讯,目的在于传播更多信息,与本站立场无关。仅供读者参考,并请自行核实相关内容。