软件定义汽车（3）-SOA架构

殷玮

自动驾驶等 2 个话题下的优秀答主

好了，硬件折腾过了，中间件也有了，是不是就可以愉快的应用开发了，不，还有一个共享的思想必须掌握，接上一篇文章

中间件有了，只是我们和硬件完成了剥离，但在和其他模块的交互机制上仍然存在问题，这里先要聊下单播，组播和广播三个概念。

https://blog.csdn.net/qq_28657577/article/details/86487062

这三个概念，原本来源于计算机以太网通讯（就如软件定义汽车，现在车辆也用了这个概念）

单播(unicast): 是指封包在计算机网络的传输中，目的地址为单一目标的一种传输方式。通俗理解就是一对一通话，这种通讯方式稳定性好，但如果有多个人需要这些信息就不划算，每个人开一个频道就会占用很大的通讯带宽。

组播(multicast): 也叫多播，多点广播或群播。指把信息同时传递给一组目的地址。它使用策略是最高效的，因为消息在每条网络链路上只需传递一次，而且只有在链路分叉的时候，消息才会被复制。这种模式一般有订阅和发送方两个角色，只有订阅了，才会被发送，是介于单播和广播之间的一种方式。按需定制，效率平衡。

广播(broadcast):是指封包在计算机网络中传输时，目的地址为网络中所有设备的一种传输方式。实际上，这里所说的“所有设备”也是限定在一个范围之中，称为“广播域”。这种方式就是广场上用喇叭讲话，广场上的人都听的见。

整车现在采用了什么机制？

目前整车使用的一般是哪种？准确来讲应该是网关固定设计的单播，加独立CAN网内部的广播叠加的综合机制。

中间的是网关，旁边的都是独立的CAN网络或者其他网络，假设信息要共享，就会是这样

灰色连线内部如果要接受或者发送信息则都能够接收到（CAN的特性决定），如果要跨越几个控制器，就要经过上面一层的网关。网关里面谁给谁发，都是预先设定好了的单播策略。我们也称这种架构为signal oriented架构，面向信号的架构。

这种机制有没有问题，现在没有什么问题，因为发布即锁定，大家按照既定的来做就可以了。但如果需求发生变化情况就不同了。面向信号的架构，大家都依赖信号设计，而这些可不好改

为啥要用SOA呢？用了SOA有什么好处？

SOA是IT行业近年来典型的架构方式，大量的IT系统都是基于SOA实现的。而汽车领域采用SOA架构的一个主要原因就是能够加快车辆与互联网的互联互通。

大幅提升自动驾驶功能
便于实现高清地图的创建、更新及路线预测
便于实现车辆信息的上传以及云端指令的下达
快速提升系统与软件升级性能
有助于实现各种远程诊断、预诊断等功能
能够大幅提升影音娱乐功能的用户体验
能够实现不同平台间的各种App共享等功能
能够有效降低架构升级带来的复杂度

SOA架构下整车采用了什么机制？一重境修为SOC(Service Oriented Communication) 基于服务的通讯

简单讲，实际上是组播机制。具体说，SOC主要为了实现通信标准化，动态建立通信关系，连接信息孤岛。车载以太网协议架构中的AUTOSAR-SOME/IP就是基于SOA思想定义的通信中间件，SOME/IP是针对车载环境定义一套通信协议，可以达到屏蔽系统异构性，实现互操作的目的，SOME/IP可以直接用于实现SOC（但其他传输协议同样可以，例如DDS等）

当前整车架构多处于分布式阶段，通俗点讲就是“半吊子”你看着上图是不是和什么图片很像？

嗯，和CAN的结构很像，唯一的区别CAN的横条是广播的逻辑，而SOA的横条是组播逻辑，只是通讯上做了优化，那还有什么需要优化的？

车内所有具备以太网通信能力的节点离散的挂在网关上，如果没有域控制器、中央型处理器或者高性能处理节点。那很有可能每个节点的资源由于初期规划简单而不可能预留丰富的资源供量产后新增功能使用和消耗，故很难在此基础上实现功能重构。

这就引出了SOA的第二重境界

SOA架构下整车采用了什么机制？二重境修为SORS(Service-Oriented Reuse-shared Design）基于服务的复用共享式设计

在谈SOA架构的前提还是第一篇文章讲的，需要新的硬件架构来适配新的发展需求，如下图

过去分布式架构中，控制器数量都超过100个，所有的功能实现多是基于不同控制器之间传输信号来实现。软件定义汽车下，控制器数量大幅下降，针对少数控制器就可以单独的抽象出“服务组件”，最终形成面向服务的架构。

很多时候EEA变革、SOA架构是割裂的谈的，其实两者是相辅相成的。没有EEA对控制器的集中化，SOA没有多大意义。创造更大价值的主要还是Zonal架构变化带来的。SOA是和Zonal比较好的拍档，SOA有助于Zonal的实现。有时候能够降低通信的延迟，具备灵活可拓展的优势，降低测试成本和时间。SOA是一个长期演进过程，这中间并不容易。

以特斯拉为例，现在特斯拉Model 3是以类似CAN信号为导向的架构，还是以SOA为导向的架构？我觉得是一种中间状态。未来，SOA架构大概率也只能是特斯拉这样的车企去先践行了。因为SOA的落地同样需要的是组织架构的重组。绝大多数供应商只供应少数传感器和控制器，SOA是全局的，供应商是很难主导全局的变化。对车企内部来说也是一样的。各个部门和科室是割裂的，沟通效率不高，且即使车企有很强的内部协调能力，协调外部的200个不同的供应商也非常艰难。OTA也面临同样的问题，要协调那么多更新服务也不容易。目前大家都在给行业科普，但真正的实践和落地，说服领导，多半又只能看着特斯拉慢慢逆向和揣测了。

SOA架构的开发思想梳理

根据SOA软件开发方法，可从两个切入点开展SOA汽车软件平台的开发。 1)自下至上，从车辆基础功能/信号出发，将已有的应用功能逻辑/信号(eg:车辆车速信息)抽象或封装成服务组件，这类组件被称为基础服务层(Basic/Platform Service Layer)组件，具有最高的可复用性和可组合性，这些组件将为上层(业务服务层Business Service Layer)的服务组件提供最基础的支持。由整车末端硬件开始向中心硬件进行梳理和盘点，特定的硬件可以提供相同或者而类似的服务，例如，阳光雨量传感器就可以提供光照强度和雨量的信息，这样我们就可以抽象出来一个阳光雨量的服务，只要这个硬件在，我们的服务就会在，不受任何约束。之后可以继续向中心探索，挖掘硬件对应的功能、所提供的数据等，进行服务抽取。

2)自上而下，从整车业务逻辑和用例出发，结合各领域的核心业务知识，设计业务服务层(Business Service Layer)的服务组件；同时，遵循服务组件的复用性和自主性等原则，向下设计规划基础服务层(Basic/Platform Service Layer)的服务组件。由车辆既有功能和业务流程入手，例如整车防盗认证，会有各级防盗认证流程，期间会调用到很多的模块或者算法，比如随机化算法、防盗认证算法等，可以将这些算法抽取出来形成不同的算法服务。从一个个的功能业务链入手，分化抽离出服务库，最后可以逆向重建，即从服务库中挑选出一个个服务模块，通过排列组合的调用就将原始的功能业务场景无差的还原出来。

看起来，还是自下而上容易点，这样能保证穷举，所有现有功能可能都不会受到影响。

自上而下感觉容易有疏漏。或者说这个分析过程是同步的，同时自上而下和自下而上做冗余分析，然后看看推导出的基础服务层和基础服务组件是不是一致。如果一致那很好，如果不一致，再分析为什么不一致。在SORS开发模式下，OEM在平台/车型研发阶段将分析车辆本身拥有的一切软硬件资源，并提供重复利用的可能。OEM或授权的第三方可以基于服务库轻松开发新功能，快速完成迭代，并通过OTA技术部署到车端，持续提高用户体验。

SOC(Service Oriented Communication) 设计细节

通信行为：SOME/IP吸收了RPC机制，顺利地继承了Server-Client的模型，SOME/IP Service Discovery可以让Client灵活可靠的找到Server，并订阅感兴趣的服务内容，Client可以用Request-Response、Fire&Forget的模型访问Server所提供的Services；Server可以利用Notification推送给Client已经订阅的服务内容。由于以太网采用交换机的组网方式，拓扑内以太网节点的交互能够二层转发，网内节点可以动态的建立服务提供与消费的关系，不依赖于其他额外的机制和组件。例如，订阅机制，高精地图Server向外提供高精地图数据（Offer Service），ADAS控制单元想要订阅其车道线相关信息（Subscribe EventGroup），高精地图Server同意其订阅请求（Subscribe EventGroup Ack），而后Server开始发布高精地图的车道线数据给ADAS控制单元。再如，请求与响应机制，HU想要获取DVR内存信息，此时DVR是Server，HU是client，由HU向DVR发出request，DVR收到请求后，根据自身当前状态，回复response。