基于AUTOSAR的SOA OTA方案实践

8月5日,由盖世汽车、AUTOSAR组织联合主办的2022第三节软件定义汽车论坛暨AUTOSAR中国日在武汉举行。会议聚焦软件定义汽车围绕软硬件解耦、域控制器、SOA架构、高性能通信中间件等行业焦点及技术性话题进行讨论。艾拉比副总裁陆颖侃受邀出席活动并发表题为《一种SOA OTA方案实践以Adaptive AUTOSAR升级设计方案为参照》主题演讲。以下为演讲内容整理:

基于AUTOSAR的SOA OTA方案实践

陆颖侃 艾拉比副总裁

以下为演讲实录:艾拉比OTA演变,从面向过程到面向服务的OTA

艾拉比是国内最早进入汽车产业的OTA技术服务公司。那时候整个汽车行业OTA处于初期发展阶段,行业内对OTA的了解甚少,整车架构大多采用的还是传统的电子电气架构。艾拉比基于自身OTA技术研发实力,切入汽车行业后,与主机厂开始了长达一年的频繁沟通,推出了第一代产品OTA 1.0版本,即面向过程的OTA产品,之后随着技术的创新和大量的整车项目落地经验和积累,艾拉比OTA产品也在不断的迭代和进化。

艾拉比OTA1.0——面向过程的OTA

艾拉比第一代OTA 1.0版本主要是按照面向过程的开发,具有高度平台定制的特点。

面向过程的OTA虽然让汽车具备了升级能力,但是也存在一些自身的问题性:

1、平台扩展性较差、维护成本也较高;

2、各个模块之间耦合度非常高,新车型匹配工作量大;

3、车云通信、车内通信等强绑定的,依赖智能件自身的升级能力;

4、升级成功率相对来说也要低一些。

因此这个版本下的OTA时代,我们又将它称为零部件级的升级阶段。在这个阶段,很多汽车也不具备整车升级的条件,很少有车厂做整车升级,更多的还是面向智能件的升级。

艾拉比OTA2.0——面向产品的OTA

随着汽车行业的发展以及艾拉比大量的OTA项目实践,在2018年、2019年,艾拉比对整个产品重新进行了构建与分层,把各个功能模块进行分割,形成耦合度比较低的整体架构,并对各个功能模块进行了测试和各个维度的整车台架的测试,这个阶段产品质量和成功率得到了很大的提升,艾拉比OTA进入2.0版本,即面向产品的OTA。

基于AUTOSAR的SOA OTA方案实践

图片来源:艾拉比

同时,2.0产品也有赖于艾拉比的两个核心的技术:

一个是差分的算法,我们具备国内领先的差分还原效率;

另一个是诊断引擎:艾拉比采用私有化的引擎协议,可以做到5M RAM空间下运行,基本上可以适配国内绝大部分车型的刷新引擎,可以支持10路刷写,充分利用以太网的传输能力,后续会扩展支持产线升级的能力。

OTA产品架构的思考:

OTA产品的典型架构,在主控以下一般是网关,采用的是以太网的连接,网关之下会有域控。对于主控来讲,一般基本上分成两个大的模块,一个模块是起管理作用的模块,一个模块是起车内的诊断引擎和车内的数据处理和协议站的作用它两者的分工是比较明确的,一个负责管理,一个负责执行。

综合来看可以看到现在的产品里面大量的模块都是复用的,FOTA业务,与后面DOTA业务和SOTA业务,如果在一辆车上布三套系统,不仅是给车辆主控带来负荷,软件维护也很麻烦,然而对于内部来讲诊断引擎理论上是一致的。

艾拉比OTA3.0——面向服务架构的OTA

我们觉得AUTOSAR面向服务的概念和思路非常适合我们在OTA领域里的应用。

从AP SOA典型架构来看,车内一般分为外网和内网,内网安全级别很高,外网安全级别会低一些。外网模块包括TBOX、HUT、GW,在实践中都可以做主控,但它们是各有特点的。很多车辆外部网络其实是不能直接访问车内网络,必须经过网关认证之后才能进行内部网络的访问。

从架构的三大主控功能来看:  

1、网关是非常适合作为诊断引擎和数据管理的角色,但网关的资源非常昂贵,因为现在绝大多数公司虽然用高端芯片,但上面承担的业务和功能是非常多的,资源非常昂贵也非常稀缺。这样来看它并不适合承担所有的东西。

2、TBOX一般来说是半封闭系统,它属于中等水平。另外TBOX天生是带上网能力,同时它有4G模块,4G模块会有算力的冗余。我们如果把算力的冗余利用起来,其实是可以做管理上的决策。因为我们OTA的管理本身对算力要求并不高。

3、HUT可以外部进行安装软件本身安全性并不是很高,对它来讲做人机交互这样的角色是比较合适的。

从整个架构来讲这三类主控,现在绝大部分车厂主控是放在一个单独零件上,但从合理性的角度来看,针对不同零件的安全性和资源以及整个承载能力来看,分开部署是更加合理的。

分开部署的概念就是AUTOSAR的SOA概念的一种体现。

艾拉比面向服务的OTA3.0架构,主要包含云端和客户端架构。

基于AUTOSAR的SOA OTA方案实践

图片来源:艾拉比

云端采用的是微服务架构,不管是车端还是云端都是面向服务SOA的架构。云端包含车辆的软件版本管理的平台,它提供零部件软件版本、配置字、功能等的管理,为FOTA/SOTA提供所要使用的版本或功能信息。

客户端服务(OTA Client模块),主要负责车云交互和整个OTA的中台管理,包括在不同的项目里和车型里,车云交互会用到很多软件,在这上面的协议可以进行统一的管理。

最后:面向运营OTA架构的思考

回顾一下1.0-3.0的阶段,首先,通过业务的提炼和总结,形成了1.0版本;然后,将这些业务过程和经验变成产品化的过程,形成了2.0版本;接着,对于产品化和模块的整合面向服务,形成了3.0过程。3.0是面向整车的服务化阶段,把车内整个OTA各项业务进行了打通,将各个研发、生产、销售、以及售后服务串联起来。

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

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

当前的OTA都是面向内部研发部门来做的,大家更多地关注技术,包括SOA,大部分是技术环节,在应用环节和业务环节尚未彻底融合。从应用这个维度看,面向售后和软件可售,最终是面向用户的,这个管理方应该是售后管理方。

以远程诊断为例,具备远程诊断功能的汽车,首先在车端的诊断引擎会时刻监控车辆故障状态,一旦发生故障会采集故障相关数据,同时会通过TSP,TSP开展后续客户服务,比如通知4S店或者车主;同时远程诊断系统可以对车辆故障进行判断决策,4S店可以进行维修准备。整个系统是采用顶层设计,业务流转顺畅,从而极大的提升售后能力。

对艾拉比来讲,我们的服务就是要通过“XOTA”产品体系为基础,为将来软件定义汽车和面向运营提供更多的工具和支持。