【软件定义汽车】SOA框架介绍

面向服务架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操p程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

IBM将「SOA」定义为『一种可通过服务接口复用软件组件的方法。』通过「SOA」的整合，使得各种接口会使用通用的通信标准，这些标准能够快速合并到新应用程序中，而不必每次都执行深度集成。

SOA是一种架构理念，不单单指某一种基于SOA理念的协议。

所以千万别把SOA等同于SOME/IP协议，SOME/IP只是SOA的众多选择之一，而SOA本身的协议选择有很多。

SOME/IP是专门用于汽车行业，SOME/IP通过AUTOSAR规范来具体定义SOME/IP协议细节，Classic Platform AUTOSAR(CP)和Adaptive Platform AUTOSAR(AP)都可以运用SOME/IP协议来通信。

目前GENIVI提供的一种SOME/IP实现，称为vSOME/IP，是开源代码，可以做到很好的适配AUTOSAR需求

在SOA架构下，可以通过订阅功能，使得汽车中其它的功能和空调功能配合使用，也就是灵活可拓展。

比如摄像头检测到驾驶员疲劳驾驶，那么此时空调会自动降低温度，使得驾驶员头脑清醒。

简单地说，就类似于手机，开发者可以根据各种API直接调用手机上的所有功能开发出各种APP。

想一想SOA是不是很有未来呢/p>

未来，汽车工程师与互联 程序员也基本上没有太大的界限，工程师开发也需要了解到IT知识与IT开发语言，程序员如果想要进行汽车研发，也不需要了解内部硬件结构。每个人都是开发者。

比如电动车门，需要判断车速条件，车速模块位于底盘系统，而车门控制属于车身系统。因此一个功能往往涉及到多个系统之间的交互。跨系统的交互则引出了 络通信的需求。

系统架构分析

接下来对系统进行进一步细分及需求整合。不同功能可能对同一个子系统都有需求。因此在系统架构分析这一步，需要综合所有需求，针对每个子系统，输出相关需求文档，包含场景需求，输入输出接口，性能需求，HMI需求等。

通常在这一步也会完成功能分配，即子系统是由哪个硬件承接完成的。根据功能分配，子系统接口又被分为 络接口和硬线接口。

零部件开发规范

上步完成的功能分配，确定了每个硬件需要实现哪些子系统。零部件开发规范整合所有的子系统需求，完成零部件级别的开发需求，比如硬件接口，系统原理图，收发的 络信 等。

传统的架构开发流程基本上到此结束，最重要的工作在于子系统架构分析，在这一步功能完成了从用户语言到技术语言的转变。

然而这种开发流程存在以下几个问题：

1. 系统方案依赖供应商。

虽然功能分配在子系统分析之后，但实际上子系统由哪个硬件实现，已经由供应商决定。甚至某些子系统之间的交互接口，也是通过供应商提供的信 清单定义的。

2. 软件架构是黑盒。

在整个架构开发过程中，整车厂不参与软件实现方案，只提功能需求。

这样导致的后果是，更换功能变得很被动。因为受限于供应商的方案和ECU软件平台的不同，任何的更新都需要牵扯多方联动，效率低下。

SOA架构

SOA的目标就是实现灵活可变的IT系统。

要达到灵活性，通过三个途径来解决：标准化封装、复用、松耦合可编排。
SOA架构设计的目的是：

1)将逻辑块转变为服务参与方（participant），服务参与方之间的交互接口为服务接口（service interface）。每一个服务代表一个独立的功能，具有统一标准的接口。

2)通过对整车逻辑的分析，将重复的功能整合为一个服务，减少相同的逻辑块，节省成本。

软件架构设计，是关联服务和软件模块，使服务实例化。

实例化意味着服务的实现有了载体，相同的服务可以由不同的载体实现，在系统中有不同的实例。比如camera服务，可以被实例化多次，表示整车不同位置的摄像头。

因此，基于SOA的架构开发，实际上是以服务的方式对整车的功能进行拆解，将黑盒子的ECU白盒化，为未来扩展和功能更新，提供了良好的基础。

软件架构白盒化之后，功能的更新和重新部署都更为透明，快速和便捷。

所谓软件定义汽车，只有当我们把硬件的边界打破，软件之间能够互相“看得到”对方，彼此之间用同一种语言交流，才能形成更大的生态系统。

SOA优势

得益于以太 的快速发展，使得SOA通信(SOC)优势明显，另外SOA运用发布-订阅等机制，也促进了SOA发展。

1. 以太 的带宽占据绝对优势，是直接碾压CAN等传统 络的，同时以太 的带宽会随着技术的不断发展，一直是持续精进的，这点传统 络已经不具备可比性；

2. 从信息安全角度，CAN大部分采用MAC和SecOC等明文传输，加密等级并不高，而SOA通信可以借助强大的以太 加密方案，甚至可以不断扩展，安全方案是不断迭代的，目前也有很多主机厂专门成立信息安全团队，加固安全策略，而CAN信息安全很难扩展；

3. SOA服务通信模式不仅支持发送者-接收者模式，同时还支持客户端-服务器模式.

4. SOA的发布-订阅机制以及服务功能独立不重叠，是和互联 SOA及微服务高度契合的，使得整车SOA服务通信和后端互联，为后续开发更多的运用提供无限可能，促进汽车智能化的发展；

5. OA架构服务通信的最核心关键词就是动态，服务可以通过OTA动态的安装，服务间调用可以动态的创建连接。

优点：

• 扩展方便：可针对单个服务提供资源扩展
• 语言通用：接口通用，服务可以基于任何语言
• 新人友好：单一模块服务理解透彻即可服务此模块，不必理会架构
• 发版方便：可更新单一模块，不影响架构

缺点：

• 问题排查不便：功能调用服务多，很难直接定位问题点
• 沟通不便：模块独立，不确定其他模块状态
• 性能问题：通信时间损耗
• 关系混乱：服务越来越多，调用方越来越多的时候，就会比较混乱
• 运维难度：随着服务的增多，系统架构会越发复杂，这就给运维层面带来了挑战
• 数据一致性问题：单体项目因为数据都在同一个数据库里面，不需要过多的关注分布式事务等问题，SOA就需要关心了

CSDN话题挑战赛第1期
活动详情地址：https://marketing.csdn.net/p/bb5081d88a77db8d6ef45bb7b6ef3d7f