引言:
我是车载以太网小L,深耕于整车以太网架构系统设计和软件开发,入过很多坑,尤其是SOA架构,没有经验可以借鉴,一路过关斩将,摸着石头过河,可谓经历九九八十一难,有一堆的经验和心得,想和行业内同仁分享和探讨,如果能够帮助大家解决一些实际问题,那将是我分享的意义所在。也欢迎大家关注我自己的公众号“车载以太网小L”
《浅谈整车SOA架构》系列分为四大部分,层层递进,干货满满,千万不要错过哦:
1. 背景介绍(已发表,点击可看)
2.大家眼中的SOA(已发表,点击可看)
3.我眼中的SOA(本篇内容)
4.整车SOA系统设计分享
我眼中的SOA
前两篇发布后,大家的反响非常强烈,这里要感谢大家的支持,大家的认可是我不断前行的最大动力。如果说前几篇是开胃小菜,那么接下来,让我们正式进入主题,来说说《我眼中的SOA》。
在过去很长一段时间里,我们都在低调并有序的做着研发工作,并没有想过跟业内分享我们的经验,但随着设计的SOA架构日趋成熟,再加上业内同仁们貌似都在焦虑,就想着是不是可以跟业内其他同仁分享一些经验,说说自己的想法,安抚一下大家焦虑的心,当然如果我的文章有一定的指导作用,那自然是极好的。另外,我们既然已经做好要分享的打算,肯定也会虚心接受业内人士的审视,有不足的地方,欢迎大家一起探讨,如果有的内容引发激烈的讨论,那也是我喜闻乐见的。不管怎样我们会始终保持初心,砥砺前行,不断从实践中总结经验,不断推陈出新!
01
SOA概念
什么是SOA:一种粗粒度小、松耦合服务架构,服务之间通过简单、精确定义接口进行通讯,不涉及底层编程接口和通讯模型。
SOA是一种架构理念,不单单指某一种基于SOA理念的协议,所以千万别把SOA等同于SOME/IP协议,SOME/IP只是SOA的众多选择之一,而SOA本身的协议选择有很多,我相信未来车内能够支持的SOA协议,会越来越多,主机厂可以发挥的空间会越来越大。
SOA和AUTOSAR:正如上面所说,SOME/IP是SOA协议之一,而SOME/IP是专门用于汽车行业,SOME/IP通过AUTOSAR规范来具体定义SOME/IP协议细节,Classic Platform AUTOSAR(CP)和Adaptive Platform AUTOSAR(AP)都可以运用SOME/IP协议来通信,而AUTOSAR Foundation规范则定义了CP和AP必须同时遵循的SOME/IP需求。虽然SOME/IP定义于AUTOSAR,但SOME/IP并不仅仅用于AUTOSAR,目前GENIVI提供的一种SOME/IP实现,称为vSOME/IP,是开源代码,可以做到很好的适配AUTOSAR需求。
对于SOME/IP协议,想要AUTOSAR系统和GENIVI系统能够正常通信,必须遵循同一套规范,所以在整车SOME/IP通信中,不管是不是AUTOSAR系统,SOME/IP相关实现必须依据AUTOSAR规范开发,这才是AUTOSAR的意义所在,而不是强制ECU必须所有软件模块都遵循AUTOSAR,这样反而被局限。
对于AUTOSAR规范,大家要理性的看待,合理的利用,适当的发挥:《AUTOSAR的生与死》一文中,指出了一堆AUTOSAR弊端,但却恰恰忽视了最现实的问题,没有AUTOSAR,不同系统如何协作通信,当前并没有一种规范可以取代AUTOSAR,哪怕有了可以和AUTOSAR相媲美的规范,谁又能保证不会出现第二个AUTOSAR呢,所以规范就只是一个参考,说到底还是取决于你怎么用。你如果只把它当做参考,那它只是你的一个工具而已,但如果你完全指着AUTOSAR,而没有自己的思考,自己的见解,那只能被AUTOSAR拖着走,早晚有崩的时候。
02
SOA对EEA的影响
1).过去
对于汽车行业从业人员来说,电子电器开发V模型并不陌生,但理想很丰满,现实非常骨感,我们常常阻碍重重,常常折服于现实:
(1)Tier1提供ECU,往往是平台件居多,功能已定,ECU需要哪些信号,其实已经确认;
(2)OEM更侧重于提炼这些确定的信号,进行网络信号排布设计;
(3)OEM高度依赖供应商,也造成了技术强势的Tier1几乎垄断了相关ECU,导致这方面OEM话语权极低;
(4)基于目前现状,ECU的功能极为固定,行业变革也举步维艰。
在我有限的工作经验中,对Tier1做妥协那是时有发生,已经足够习惯和麻木,常常一个供应商的零部件无法满足系统设计需求,而需要整网跟着调整参数来实现,做好新的策略之后,还得跟其他零部件系统工程师,架构工程师、供应商等一系列人去协调解决方案的落地,如果遇到另外一个强势的Tier1不愿意配合,那这个时候就又得发挥我“强大”的设计能力,重新给这个不配合的Tier1做另一个解决方案,就这样解决方案叠加解决方案,到最后我自己都不知道设计了一个什么出来。
2).现在
长久以来的反向开发流程,极大的压抑了主机厂的主动权,主机厂受控于平台化的零部件,功能无法突破,话语权不大,使得越来越多的主机厂开始想要变革,从最近的软件中心如雨后春笋就可以窥探一二,另一方面,软件定义汽车这个概念也越来越热门,大家的需求都非常迫切,都在寻求突破,我觉得这些都是极好的现象。
软件定义汽车变迁中,SOA理念将会发挥极为重要作用,它是这次变革的马前卒,可以让这场变革变得水到渠成。但如何引入SOA理念呢,大家是不是一头雾水?首当其冲的就是,在整车功能定义初期,SOA团队就必须要参与功能定义和梳理,协助并主导将整车功能划分为不同的子系统,在子系统的基础上,将所有功能划分为最小单元的功能模块,每个功能模块都必须做到独立不重叠,这样的功能模块才能是一个基础服务。有了基础服务之后,还要反向将子系统重新通过基础服务组合起来,这样子系统才会以组合服务而存在,这一系列操作下来,我们的服务API就基本定型,而服务的组合是一个可持续的过程,会让数据源源不断的产生价值。
3).未来
SOA服务的定义是高度依赖于整车功能定义,只有整车划分好子系统,SOA服务设计才会启动,服务设计好后,才能解析出软硬件需求,整车拓扑才能真正意义上的软硬件解耦。
在整车架构和SOA服务设计上,我们已经做的很超前,可以说SOA几乎规划了整车所有功能,但仍然有一些挑战要留给未来解决,目前我们完全没有办法要求供应商将各个ECU的功能逻辑上移到域控制器中,这个问题,我们势单力薄,是需要整个行业的共同努力推进,主机厂和供应商缺一不可,未来行业格局会重新洗牌。
未来,各大主机厂的软件中心将发挥极其重要的作用。
03
SOA优势
关于SOA优势,首先得益于以太网的快速发展,使得SOA通信(SOC)优势明显,另外SOA运用发布-订阅等机制,也促进了SOA发展。
1)以太网的带宽占据绝对优势,是直接碾压CAN等传统网络的,同时以太网的带宽会随着技术的不断发展,一直是持续精进的,这点传统网络已经不具备可比性;
2)从信息安全角度,CAN大部分采用MAC和SecOC等明文传输,加密等级并不高,而SOA通信可以借助强大的以太网加密方案,甚至可以不断扩展,安全方案是不断迭代的,目前也有很多主机厂专门成立信息安全团队,加固安全策略,而CAN信息安全很难扩展;
3)SOA服务通信模式不仅支持发送者-接收者模式,同时还支持客户端-服务器模式,而CAN通信,仅支持发送者-接收者模式,单纯的发送和接收,接收端均是被动接收,而SOC可以让Client主动请求控制或者状态数据,同时也支持订阅相关数据的发送。对于CAN来说,不同的通信对,对于同一个功能,是需要定义不同的报文和信号,而这几个相同功能的信号对应的值有时还不一致,运用SOA之后,就完全可以避免这种现场,不管有多少个Client,Server可以只有一个,同时不同的Client可以调用同一个服务接口;
4)SOA的发布-订阅机制以及服务功能独立不重叠,是和互联网SOA及微服务高度契合的,使得整车SOA服务通信和后端互联,为后续开发更多的运用提供无限可能,促进汽车智能化的发展;
5)SOA架构服务通信的最核心关键词就是动态,服务可以通过OTA动态的安装,服务间调用可以动态的创建连接。
如图所示,驾驶员意图分析服务作为一个新的服务,可在车主拿到车后,购买升级包,通过OTA推送该服务相关的APP,从云端将安装APP相关的Manifest发送到对应的控制器,仅升级该服务相关功能逻辑,而不需要改变任何其他的代码。另外,从图中可以看到,驾驶员意图分析服务会调用车内很多已有服务,进行数据融合分析,这种将分析结果反馈给云端,做边缘计算等算法,这里其他已有的服务不需要更改任何内容,因为服务在开发阶段就已经确定好哪些是可以动态被访问。
这时候,有人肯定会问,说了SOA服务可以动态,但真正有几个主机厂做到了动态,哈哈,目前在我们的SOA架构中,服务已经做到了动态创建连接,也就是说,服务可以被任意一个有访问权限的节点访问,而服务动态安装,我们也有借助OTA技术实现,进一步落地。
04
我们的SOA
在上一篇<大家眼中的SOA>,我分析了国内外的主机厂SOA架构落地情况,这里也简单说下我们自己的。
我们在决策电子电器架构的时候,架构专家们更多的是敢为人先,没有任何的犹豫和惆怅,直接采用了Domain架构(一群有魄力的人)。当然采用Domain架构还是Zonal架构,其实对SOA并没有本质的区别,因此物理架构的决策,更多的是考虑整车硬件环境和车辆实际情况,对于SOA,理论其实是一致的,SOA的设计经验完全可以平移。
我们在实现SOA架构设计的时候,具备两个前提条件:
1)从SOA架构落地角度,如果一个主机厂想要实现SOA架构,那整车SOA架构团队,必须对整个实现链路具备绝对的话语权。在我们SOA架构实现的过程中,我们具备对车内外系统规划权力的,我们可以综合决策车端SOA节点的软件系统、架构及中间件,同时也能推动娱乐系统,尤其是SOA Gateway节点实现我们的策略,另外,如何和云端进行SOA交互,我们提供解决方案,我们甚至能够支配第三方交互系统,在整个链路中,我们能够整体去把控,而不单单是车内以太网系统设计,大家别看上面看似寥寥几句,其实我们经历了好多,搞定其中一种就已经极不易,要同时做到这几点,更是难上加难,所以我们的整车SOA架构,是大家共同努力的成果。
2)整车SOA架构师必须具备十项全能,要想做到软硬件解耦,就必须从整车功能定义初期就参与其中,辅助整车功能部署,不仅要整车功能了然于心,同时具备SOA架构设计能力,还要精通整车网络系统设计和整个工具链的开发,还要精通软件架构,写得了代码,调得了板子,深入到软件实现,另外架构出身,必须熟知整车开发流程,还得做得了项目管理,因此对SOA架构师的要求是极高的。
至于我们如何运用SOA,如何实现,因为涉及公司机密,这里就不深入探讨了,但我相信时间会给出答案!
请大家继续关注下一期:《浅谈整车SOA架构》第四篇 整车SOA系统设计