EEA 发展趋势
当前汽车正处于一个智能化、网联化、电动化、共享化的发展，越来越多的汽车逐步应用到智能驾驶、智能座舱、车联网等相关的技术。
新四化的不断发展对算力和带宽的需求急剧增加，以太网逐渐取代传统的总线，成为车载通信的骨干。
EEA 架构从原来上百个 ECU 分布式的架构逐渐向以太网为骨干的域控发展，成为中央电脑+区域化控制器的系统架构。
同时，日益增长的功能需求与软件的复杂度之间形成一个不可逾越的鸿沟，AUTOSAR 的标准基于实现软硬件的解耦和复用的目的，提出并制定了一个标准化的软件开发架构的方法论。
传统的汽车电子电气架构及相应的解决方案很难解决现在遇到的一些挑战，需要新的方法论来打破僵局，于是车载以太网、车载 SOA 作为解决方案提出来了。
SOA 概述
SOA，全称 Service Oriented Architecture，是面向服务的架构。
SOA是什么？
SOA 的概念比较抽象，是从IT行业引进过来的一种软件开发方法；是一种设计思想；是架构策略层面的指导思想。当我们从中去理解 SOA 是什么的时候可以从中提取几个关键词，功能定义服务、服务带有标准的接口、服务可以被调用。
SOA的一些关键属性
服务：函数或方法
服务角色：Provider、Consumer、Broker
服务接口：获取服务的方式
服务注册：实现服务的注册订阅发布等
Broker 可以是集中式的也可以是分布式的，如果是集中式的可以在某些设备上统一管理服务的发现；如果是分布式的类似以太网、SOME/IP 协议等可以在汽车的每个ECU 上充当角色来实现服务发布和订阅。
SOA的特点
有意义的：它本来代表着一种业务和功能，比如我们会用它登录注册的一些功能。
无状态的：服务无状态是指服务提供方并不关心它被调用的次数以及服务调用前后的关系。
可复用的：服务可以被多次调用。
位置透明的：可以通过服务发现来获取服务。
为什么要用SOA？
降低复杂性
实现敏捷开发
软硬件分离
实现互联互通
SOA的使用场景
SOA 在智能驾驶、娱乐影音、互联互通等场景使用，有些共同的特点是它们需要传输的数据量大，数据类型相对复杂，需要高强度的算力，服务之间存在调用的关系。
SOA实现的重点
包含两个方面，面向服务的软件和面向服务的通信。面向服务的通信通过以太网的协议去满足业务实现的需求。
SOA 与以太网的关系
如果要实现 SOA 的架构，在项目启动时，首先要确保能落地的 SOA 电子电气架构梳理出整车以太网的拓扑需求，从方方面面出发和产品、功能架构、平台软件等相关的去共同确认电子电气架构为确保以太网的拓扑和相关以太网芯片的选型，也需要根据一些实际的条件选择合适的 SOA 服务协议。
下图是当前常用的四种服务协议。
ETH系统设计与 SOA 开发流程
在车载架构中以太网和 SOA 是一个最强的搭档，如果要实现 SOA 的落地，理论上以太网是要先行的。
就部分主机厂来说，它们下一代架构先实现的功能是 DoIP，要让一部分的域控制器先实现基于以太网的通信，实现 TCP 的 IP 协议栈，让整车架构中的 ECU 先去有通信的能力以及整车安全方面的一些部署并且能够让一些工程师能实现整车上通过OBD 接口去实现车辆的 ECU 登录，车辆报文的录制等等技术的实现。
ETH系统设计流程
在以太网项目落地或 SOA 设计开发前，大量的 OEM 厂家最先是从预研先开始的，首先以太网的相关设计流程要求相关的工程师建立一定的知识储备，先去实现一些规范体系的建设。
如上图所示，规范体系建设主要包含三部分内容：
- 协议需求类规范
- 全局规划类规范
- 项目交付类规范
协议需求规范
这部分包含一些比如以太网通信需求规范等，是对协议的功能原理去进行一些解析，对相关的属性和参数去进行约束。
全局规划类规范
这个规范是在整车的全局上，比如 VLAN & IP 划分的原则，IP 定义的规则，IP 地址定义的一些前缀的定义要求，不同的 VLAN & IP 划分的原则以及每个 ECU 后缀的一些划分规律等全局的一个规范。
项目交付类规范
比如 ECU 以太网参数配置规范，涉及到 ECU 在以太网从底层到上层相关属性的配置，包括整车架构全局的配置方案，还有拆分到各个 ECU 的一个约束的配置，由DRE 交付到供应商或者交付到软件开发团队去约束他们的开发行为，也是作为后续SOA 服务部署的一个输入文档。
协议的需求规范文档和项目交付类文档会交付到 ECU 的控制器供应商或者软件团队进行相关的协议要求的开发，但是软硬件解耦的概念提出后，很多主机厂更倾向于把核心的零部件开发掌握在自己的手中，比如域控网关、中央网关等。
网关实现基于以太网的一些规范，通过 OBD 口实现智能网关 Telnet 的登录，通过端口镜像的开和关实现报文从车端到 OBD 接口的复制，方便工程师实现报文的一些录制，制定 OBD 接口一些相关的安全访问机制、防火墙机制，车端进行 802.1.x 的认证，对接入的 PC 进行安全访问的约束。
相关的 ECU 实现 TCP/IP 协议栈、ARP、ICMP、DoIP 等协议的开发和实现，去进行 TC8 的测试以及其他相关测试，去进行反复的迭代和印证。
车载以太网技术生态有了初步的落地之后，然后再开始 SOA 的落地，架构可以把更多的关注放到 SOA 本身的实现。
SOA 设计开发流程
SOA 的架构设计开发流程也是从规范体系建设开始，初期的时候就已经对 SOA 的协议需求规范进行梳理和落地，然后做全局规划类规范，包括 SOA 设计流程和指导准则以及相关以太网的属性（如 SOME/IP 属性的命名要求）以及相关 ID 定义的一些技术要求。
之后基于所选的 SOA 的服务去进行整个 SOA 设计过程中需要交付的规范模板的制定。
从技术角度、项目落地的角度，从整个架构交付产物的角度和可管控的角度需要去思考更多的一些内容。比如服务权限管控该如何去做，车型上一些服务的配置管理，车云通道部署问题等。
SOA 开发流程分为三大部分
- 架构分析
- 架构设计
- 架构实现
下图中间部分是整个开发的过程，右边第一列对应的左边开发过程的交付文档，第二列是相关的负责人。这里我们可以看到相关责任人多出一个功能 Owner 这个概念，这个是 SOA 开发过程中衍生出的一个新角色。
架构分析
首先我们需要根据 OEM 整车配置或参考供应商规划或未来整车功能的趋势，整理出适合 SOA 的 Feature list，对 UseCase 进行梳理，提出更细化的需求，生成一个较为完整的功能方案，做功能到服务的转化设计。
架构设计
功能方案这里分为两个过程，一个是自上而下的开发过程，即从功能方案到功能SSTS（子系统技术规范）。
一个是对已有功能服务的转化自下而上的开发过程。整个功能方案中，一部分是服务的设计和实现，功能 SSTS（子系统技术规范）还是像传统的架构一样也是需要作为交付文档集中到软件开发。
整个架构设计流程是，通过功能方案的一个大致落地，对服务进行一个抽取形成整车服务的集合，服务集合会包含服务、服务接口大致的梳理和定义，基于整车服务的集合，每个负责服务的 Owner 对自己负责的服务进行服务规范的梳理。
服务规范是对服务和服务接口的详细描述，定义服务类型、服务依赖关系、服务的错误处理、服务存在应用的场景等。
然后对服务进行一个详细的实现设计，里面包括 Service ID，它是服务规范和服务实现技术规范一个过程文档。如果服务涉及到 CAN 信号的一个转换，需要一个服务对应信号的对照表。
后面整个开发流程是输出相关的 SSTS 文档，服务 Owner 会基于集合定义的服务规范，基于定义去填写服务接口需求表文档交付到网络开发，作为网络通信矩阵开发的一个输入，网络开发会交付相关的通信矩阵和相关的 ARXML 数据库，然后提供到软件开发作为文档的输入。
软件开发需要输入的文档包括服务技术规范，服务 SSTS，通信矩阵以及 ARXML 数据库等。 需要说明的是，服务技术规范跟服务 SSTS 是要搭配使用的。
由于与网络开发相关的内容比较多，这是单独来看一下，部分截图如下图所示。
接下来，我们对每一个步骤进行稍微详细的分析。
架构分析
Feature
整理出 Feature 清单，并对 Feature 进行一轮梳理，确定需要进行 SOA 服务化的Feature；完成 Feature 的详细定义，如 Sub-Feature 以及其具体描述。
Feature list 中可以可以分为三种 Feature 类型，一种是可以用 SOA 实现的，比如说一些可以共享给其他 APP 的信息，来实现互联互通，如远程调用位置信息等。
还有一种是不可以用 SOA 实现的，比如说对功能安全要求比较高的底盘和动力系统的一些控制功能。或者对时间敏感要求比较高的，比如说制动和转向系统的一些控制功能。
还有一种是不确定是否可以用 SOA 方式来实现的，需要做一些预留。
Use Case（可选）
空调控制功能场景示例如下：
Use Case Item，前置条件，执行定义，触发事件及流程定义，描述定义。
Use Case Diagram(PREEvision)
Requirement设计
进一步细化 Feature 列表，对各个 Feature 进行细节描述，包括法规需求、系统需求、用户自定义需求(值域的要求)等。
如下图所示。
SOA 设计之流程指导
根据 Feature，Requirements 及 Use Case 进行 Services 定义（功能服务化），基于 SOA 设计的指导准则，这个准则会在项目设计过程中不断进行更新迭代。
SOA 设计之服务接口定义
下面是 SOA 设计过程中功能架构和服务 Owner 去输出的文档。
服务规范文档
前期是一些服务规范的文档，服务规范是服务和服务接口相关的一些定义，服务一些典型机制案例的使用，服务一些错误处理，传输实现的要求，如下图所示。
服务ICD
服务 ICD 是服务规范和服务实现技术规范中间的一个过程性文档，服务实现技术规范也是需要参考服务 ICD 去定义一些功能逻辑。
服务实现技术规范
服务实现技术规范是对服务更详细的描述，里面涉及到整个服务接口的逻辑，服务配置字的设计，服务启动停止的条件等。
以太网通信矩阵设计
以太网通信矩阵设计包含以下内容：
1）服务&服务接口定义
2）DataType 数据类型定义
3）服务部署
4）序列化定义
5）SD 通信参数定义
6）E2E 定义
以太网通信参数配置
以太网通信参数配置主要包含以下内容：
1）PHY芯片选型
2）CNB主从时钟选择
3）MACA地址定义
4）VLAN设置
5）ARP配置
6）IP配置
7）TP层选择及端口定义
以太网ID统计表
1）ServiceIDPrefix
2）ServiceID
3）MulticastIP
4）E2E DataID
5）Port
6）......
相关工具链
SOA 通信设计关注的重心：不同操作系统不同协议栈中代码实现的完整性和相互通信的兼容性，以适配上层服务接口及服务通信的设计。
不同协议栈当前的底层问题对上层设计方案的影响
不同商业 AUTOSAR 协议栈对于输入的 ARXML 数据库的配置兼容性
不同协议栈 ECU 之间的通信兼容性。
下图是相关的工具链情况。下属工具链中，相对来说 AUBASS 的工具链是落地风险最低的。
SOA 架构的挑战
总的来说，SOA 架构在汽车行业会面临以下挑战：
- SOA 概念抽象，需要建立一定的知识储备。
- 组织架构变革，全新团队全新角色的新增。
- 方法论、流程体系变革、工具。
- 短期内不会带来明显的收益。
作者：搞一下汽车电子
文章来源：汽车电子与软件
推荐阅读
更多汽车电子干货请关注汽车电子与软件专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
