CSDN话题挑战赛第1期
活动详情地址：https://marketing.csdn.net/p/bb5081d88a77db8d6ef45bb7b6ef3d7f
参赛话题：自动驾驶技术学习记录
话题描述：自动驾驶是当前最火热的技术之一，吸引了无数的开发者与学习者融入其中。然而，自动驾驶技术是系统硬件平台与人工智能、物联网、大数据、云计算等新一代信息技术深度融合的产物，具有知识新、内容杂、难度深、缺少系统教程等特点，让许多开发者眼花缭乱。
本话题通过记录分享自动驾驶相关技术，为大家提供相互学习与交流的平台。话题分享与讨论的技术点包括不限于：自动驾驶算法、自动驾驶系统基础架构、智能驾驶交互技术、虚拟仿真、自动化测试、无人系统与车辆平台、自动驾驶计算平台与传感器等。

前言

现在汽车软件圈子越来越流行‘SOA’这个概念，交流的时候不提SOA这个词，就会显的很不专业，是这个概念很新吗？倒也不是，互联网行业早已玩烂了这个概念，现在已经是micro-service甚至是serverless概念才是趋势。

那么，SOA到底是什么，为什么汽车软件SOA才刚刚流行起来，去实现这样一个架构，到底有多难呢？

什么是SOA

SOA，全称Service Oriented Architecture，是面向服务的架构。

SOA的概念比较抽象，是从IT行业引进过来的一种软件开发方法；是一种设计思想；是架构策略层面的指导思想。

当我们从中去理解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需求

今年2月份上汽集团发布了全球首个汽车 SOA 开放平台「上汽零束SOA平台」为例，其核心理念是『软件定义汽车』。

若是说此前已经发展多年的「电子电气架构EEA」（Electrical Electronic Architecture）是从「硬件层面」集合汽车的电子电器系统、ECU、各类传感器、线束、连接器的设计、电子电气分配系统等设计为一体的整车电子电气解决方案。那么SOA则是从软件层面全面打通各种标准/协议。

举个例子

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

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

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

想一想SOA是不是很有未来呢？

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

传统EEA架构

解释以下什么是EEA?

EEA（Electrical/Electronic Architecture），电子电气架构，是首先由德尔福公司提出的，集合汽车的电子电气系统原理设计、中央电器盒的设计、连接器的设计、电子电气分配系统等设计为一体的整车电子电气解决方案的概念。

他的理念如下：

1. 用户需求整理
2. 功能需求和功能逻辑架构分析
3. 系统架构分析
4. 零部件开发规范

用户需求整理

由市场部经过调研后，站在用户角度描述了本车型项目所具备的性能，配置要求等，比如具备电动车门，座椅加热等。

功能需求和功能逻辑架构分析

基于上述功能清单，电子电气架构团队将对各个功能的逻辑架构进行分析。将基于用户角度描述的功能，转变为基于技术角度的方案。

比如电动车门的工作条件，工作逻辑，故障判断等。在这个过程中，复杂功能会被分解成多个逻辑块。这些逻辑块可以属于不同系统，被分配到不同的硬件上。

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

系统架构分析

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