传统的汽车电子电气架构及相应的解决方案很难解决现在遇到的一些挑战，需要新的方法论来打破僵局，于是车载以太网、车载 SOA 作为解决方案提出来了。
(资料图)
Broker 可以是集中式的也可以是分布式的，如果是集中式的可以在某些设备上统一管理服务的发现；如果是分布式的类似以太网、SOME/IP 协议等可以在汽车的每个ECU 上充当角色来实现服务发布和订阅。
为什么要用SOA？
降低复杂性
如果要实现 SOA 的架构，在项目启动时，首先要确保能落地的 SOA 电子电气架构梳理出整车以太网的拓扑需求，从方方面面出发和产品、功能架构、平台软件等相关的去共同确认电子电气架构为确保以太网的拓扑和相关以太网芯片的选型，也需要根据一些实际的条件选择合适的 SOA 服务协议。
下图是当前常用的四种服务协议。
在车载架构中以太网和 SOA 是一个最强的搭档，如果要实现 SOA 的落地，理论上以太网是要先行的。
就部分主机厂来说，它们下一代架构先实现的功能是 DoIP，要让一部分的域控制器先实现基于以太网的通信，实现 TCP 的 IP 协议栈，让整车架构中的 ECU 先去有通信的能力以及整车安全方面的一些部署并且能够让一些工程师能实现整车上通过OBD 接口去实现车辆的 ECU 登录，车辆报文的录制等等技术的实现。
在以太网项目落地或 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 本身的实现。
架构分析
架构设计
架构实现
功能方案这里分为两个过程，一个是自上而下的开发过程，即从功能方案到功能SSTS（子系统技术规范）。
一个是对已有功能服务的转化自下而上的开发过程。整个功能方案中，一部分是服务的设计和实现，功能 SSTS（子系统技术规范）还是像传统的架构一样也是需要作为交付文档集中到软件开发。
整个架构设计流程是，通过功能方案的一个大致落地，对服务进行一个抽取形成整车服务的集合，服务集合会包含服务、服务接口大致的梳理和定义，基于整车服务的集合，每个负责服务的 Owner 对自己负责的服务进行服务规范的梳理。
服务规范是对服务和服务接口的详细描述，定义服务类型、服务依赖关系、服务的错误处理、服务存在应用的场景等。
然后对服务进行一个详细的实现设计，里面包括 Service ID，它是服务规范和服务实现技术规范一个过程文档。如果服务涉及到 CAN 信号的一个转换，需要一个服务对应信号的对照表。
后面整个开发流程是输出相关的 SSTS 文档，服务 Owner 会基于集合定义的服务规范，基于定义去填写服务接口需求表文档交付到网络开发，作为网络通信矩阵开发的一个输入，网络开发会交付相关的通信矩阵和相关的 ARXML 数据库，然后提供到软件开发作为文档的输入。
软件开发需要输入的文档包括服务技术规范，服务 SSTS，通信矩阵以及 ARXML 数据库等。需要说明的是，服务技术规范跟服务 SSTS 是要搭配使用的。
由于与网络开发相关的内容比较多，这是单独来看一下，部分截图如下图所示。
接下来，我们对每一个步骤进行稍微详细的分析。
Feature
Use Case（可选）
Requirement设计
进一步细化 Feature 列表，对各个 Feature 进行细节描述，包括法规需求、系统需求、用户自定义需求(值域的要求)等。
如下图所示。
服务实现技术规范
服务实现技术规范是对服务更详细的描述，里面涉及到整个服务接口的逻辑，服务配置字的设计，服务启动停止的条件等。