《浅谈整车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