《浅谈整车SOA架构》第2篇 大家眼中的SOA

引言 

我是车载以太网小L,深耕于整车以太网架构系统设计和软件开发,入过很多坑,尤其是SOA架构,没有经验可以借鉴,一路过关斩将,摸着石头过河,可谓经历九九八十一难,有一堆的经验和心得,想和行业内同仁分享和探讨,如果能够帮助大家解决一些实际问题,那将是我分享的意义所在。也欢迎大家关注我自己的公众号“车载以太网小L”


《浅谈整车SOA架构》系列分为四大部分,层层递进,干货满满,千万不要错过哦:

1. 背景介绍(已发表,点击可看)

2.大家眼中的SOA(本篇内容)

3.我眼中的SOA

4.整车SOA系统设计分享


                                           大家眼中的SOA

首先,先来说说国外知名主机厂是如何实现SOA架构理念,如果短时间内无法获得的技能,那就多看看前辈的经验,站在前辈们的角度想想为什么,在模仿中加入自己的思考和自己创新,这是一种非常不错的方法!


                                                      01

                                                     宝马

宝马将电子电器架构中ECU按照需求进行分类,将分散凌乱的ECU、传感器和执行器按类定义ECU系统需求和统一开发方法,甚至统一管理供应商,最终按类进行系统优化。

在中央计算平台进行整车功能的划分,将功能进行严格的抽取和封装,相互之间独立性强,而复杂度大大的降低,从而有利于功能单元的移植和复用。


这种变革,是未来整车电子电器的必经之路,但目前来说,太难了,哪怕电子电器架构已经采用域控制器Domain架构,亦或者Zonal架构,想要统一所有ECU,传感器和执行器的需求和开发,就得调整整个行业供求关系,是一场行业的变革,单靠几个主机厂,根本无法推动。

                                                                                02

                                                                               大众


再来看看大众如何落地SOA理念的,大众率先采用面向服务的架构——MEB架构,用于构造服务的架构模式,是一种架构思想,主要来源于软件技术,独立域操作系统,编程语言和软件框架,初衷是讲软件合理地划分为单独的软件组件,以最小化组件之间的功能依赖性,提高软件的可扩展性和可再次使用性。

从MEB架构的实现来看,SOA架构思想主要是通过不同服务的相互作用实现一个复杂的功能,每个服务都是一个独立可执行的软件组件,被准确描述的功能范围,通过准确定义的服务接口将功能性作为服务提供给其他软件组件,服务可以以组合的形式来调动其他基础服务,然后将功能组合起来。


从上图可以看到,大众也是将相关功能逻辑上移到域控制器级别ECU,在域控制器下接嵌入式ECUs,传感器和执行器,从设计思路角度和宝马有异曲同工之处。大众还公开了软件架构,使用CP和AP服务中间件来实现SOA通信,其中CP连接传感器、执行器和嵌入式ECU,收集信号,通过服务或者信号发送给AP,AP作为封装服务,和云端后台或者其他AP节点进行服务交互。

最终SOA架构带来的优势,可降低由紧密互动的软件组件引起的复杂性

大众MEB架构和宝马下一代架构的对比分析,从中可以看到不管是大众还是宝马,并没有所有功能都切换到SOA通信,而是部分实现。

                                                                         03

                                                                       丰田

Toyota电子电器架构经历了简单的LAN网络,到分层LAN网络架构,目前采用中央网关和域控制器架构,用于应对复杂的系统需求和减少开发量。但随着车型的改进不断产生新的变型,系统和软件也变得越来越大,而且Tier1开发过程必须统一管理,基于这些目标,他们提出了Central&Zone架构,EE架构需要引入中控ECU,所有功能都分配到ZoneECU。

详细参看Toyota的分析报告。

                                                                          04

                                                                        现代

现代的电子电器架构图如下所示,图中介绍了具体的实现细节,让我感触良多的就是他们的设计理念,好多都和我们的实现不谋而合。现代电子电器架构设计中,定义服务的出发点是为了重复使用,远程访问,独立维护,这样可以节省生产和测试成本,减少整车开发时间,同时具备很好的可扩展性。

在现代的架构通信设计中,CAN等其他网络会和以太网共存相当长一段时间,但SOA并不能直接和这些网络通信,所以他们采用了SOA Adaptor模块来转换其他网络的功能和信息,而在我们的架构中,将SOA Adaptor模块落实到SWC中,作为一个功能单元来实施,同时设置相关服务的访问权限和访问优先级。

在和云端交互的时候,需要使用外部设备来进行服务级别的交互,这样增强了整车数据的开放性,同时增加了信息安全等问题,于是在车内系统,他们同时设计了SOA Gateway节点,用于升级安全等级。而在我们的设计中,我们同样引入了SOA Gateway,进行SOA架构通信协议和安全策略切换,增强整车安全等级。

因为服务交互特别频繁,需要更高效的处理服务相关信息,更新和新增服务,他们采用了SD Proxy,安全或者强相关的服务,通过Service Router来访问。在我们的设计中,弱化了ServiceRouter,采用Service Agenda来代理服务,做到服务真正的服务端和客户端完全的隔离,增加了访问逻辑判断和权限识别。


                                                                      05

                                                                    国内现状


相较于国外主机厂的强势变革,国内主机厂,尤其是传统OEM,变革涉及太多车型,以及庞大的供应商体系,使得固有的电子电器架构模式极难突破,因此采用更稳妥的循序渐进策略,将SOA理念的实施重点放在娱乐系统,以娱乐系统的验证来考量是否有实施整车SOA架构的条件,但个人认为恰恰是这种做法,反而阻碍了整车落地SOA架构的步伐。

首先,娱乐系统本身功能安全等级低于其他域的要求,设计的服务理念未必可以直接推广到整车架构,其次,传统电子电器架构是将其他域的信号通过CAN整合到娱乐域,通过娱乐域来协调信号资源,这样好多其他域的功能逻辑都有上移到娱乐域,如果在此基础上,再在娱乐域推广服务架构,反而加剧了功能逻辑的集中,众所周知,SOA架构的理念,是将功能单元抽离出来,提高功能单元的复用性,平衡整车ECU负载,尤其是要解放娱乐系统相关模块的负担。

另外,还有一部分主机厂,率先在ADAS域内先实现SOA通信,将SOA融入到自动驾驶中,个人认为,这种是比较保险的推进方案,新型技术的强强联手,一般都会擦出大火花,最终实现互相成就。


请大家继续关注下一期:《浅谈整车SOA架构》第3篇 我眼中的SOA


你可能感兴趣的:(《浅谈整车SOA架构》第2篇 大家眼中的SOA)