汽车EEA架构演变中一个明显的特点是软硬解耦，OEM将大部分ECU的控制逻辑集中到区域控制器中。区域控制器将数据上传到中央控制器，中央控制器进行运算处理，并将结果或者决策下发到区域控制器去执行。Tier1逐步成为硬件供应商，只需要按照特定功能和接口提供执行器即可。当需要更换另一家Tier1的ECU时，区域控制器的控制逻辑甚至不需要做更改，或者只需要做简单的修改。这应该就是所谓的“软硬解耦”。
人类工业史到处都有解耦这个概念，比如我总能想到初中历史课上有讲到美国工业发展的那段，福特搞起了第一条汽车生产线。流水线本身就是将整个制造流程分割成若干个互相解耦的工位，每个工位SOP中的多个动作可能会调整，但不会影响到其他工位的操作。下一个工位的工人，只需要无脑将上一个工位生产的零部件拿来用就好了。另外，在总线协议中，OSI七层模型，也充分发扬了解耦的这一理念。每一层的技术迭代，不会或者很少影响其他层。比如从传统以太网发展到车载以太网，物理层和数据链路层的技术有一些改变，但并不影响在车载以太网上应用TCP、UDP和IP等协议，这些是网络层和传输层的协议。
以上是从硬件工程师的角度来理解解耦，硬件工程师长期接触的是这些直观的物理事物，比较容易理解。硬件上讲究解耦，软件上当然也要解耦。读研时，写过单片机的裸机代码，刚开始不太懂，吃了很多亏。
比如我要控一个灯，灯的亮度与PWM的占空比有关，我在主程序里定义PWM=50，但主程序里可能会出现多个PWM=50的这一条代码。当我要改PWM占空比的时候，需要将多条代码都修改才行。如果在头文件里，用宏定义就可以只改一条代码，且代码的可读性也大大增加。用宏定义只是最初级的解耦方式，在一个复杂的软件系统里，会有多种维度上的解耦。工程师们将系统抽象出好多个层，不同的工程师负责不同层的软件开发。一来，在开发阶段，大家可以独立开发；二来，在做迭代的时候，不同层的工程师也可以独立快速的搞完自己的业务，而不必过多的依赖其他工程师的支持。
软件工程师将软件代码抽象出若干个层，再怎么抽象上层软件，最终都会通过编译器“翻译”成多个机器码。这些机器码是由底层半导体厂商定义的，比如高通的芯片用的是ARM的架构，那就遵循ARM的指令集。指令集即上述机器码的集合，定义了哪些机器码对应了哪些功能。具体的功能则由微架构实现，微架构可以理解为固化在处理器中的最底层的电路，这些在之前的文章中都有谈到。因此，从硬件工程师的角度来看软件，可以从下往上看，心里有底，毕竟参天大树是从硬件的土壤里生长起来的，这是软硬件的联结处。硬件工程师将底层的硬件地基夯实好，软件工程师便在其上一层层垒砖头。一个简单的软件建筑没有什么规则，讲究一个快速实现功能就好。但如果要建一个软件摩天大楼，规矩就多了，比如如何使得系统更容易测试，更容易迭代等等。软件架构的设计可以遵循不同的风格（或者说是规矩），这些风格本质上是定义了用于描述系统的术语表和一组指导构建系统的规则。在初识“汽车软件”这座建筑之前，可以先看看软件架构有哪些风格。软件工程师根据项目的特点和需要选择特定的软件架构风格,这和不同地方根据当地气候和民族特色选择不同的建筑风格其实差不多。至于如何从哪些维度去评判软件架构的好坏，可以查看《自动驾驶软件架构之中间件与SOA介绍》这篇文章，里面有提到一些软件架构的评估方法。分层架构是最常见的软件架构，这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节，层与层之间通过接口通信。在这种架构中，函数调用的方向是固定的，仅能从较高层级向较低层级调用。
分层架构具有以下优点：结构简单，容易理解和开发；不同技能的程序员可以负责不同的层，天然适合大多数软件公司的组织架构；每一层可以独立测试，其他层的接口通过模拟解决。
分层架构的缺点是：扩展性差，上下层还是存在一些耦合，有些功能的变化，可能涉及多层的修改；业务流需要经过多层代码的处理，性能会有所降低；分层结构中，只能由上层组件调用下层组件，同一个层级中的组件之间无法相互通信，导致软件架构不太灵活。基于组件的架构，比分层架构更加灵活，所有组件都可以进行消息交互或者相互独立。所有的通信都应该经过规范定义的公共接口进行，并且每个组件都具备单一的接口，以便通过接口实现对组件的查询。Windows系统就是典型的基于组件的架构，其大量使用了动态链接库和IUnKnown接口。
需要说明的是，基于组件的架构并不是完全替代分层架构，架构可以分为多个层次。在大的维度上，软件架构可以使用分层架构。比如系统可以分为平台层和应用层，这是分层架构的概念。但是在应用层内，多个应用之间可以采用基于组件的架构，多个APP可以互相调用。与基于组件的架构相反，其假定整个系统是一个大型组件，系统中的所有模块都可以相互使用。这种风格通常用于低成熟度的系统，因为它会导致系统的高耦合和高复杂度。当有人质疑你的代码没有分层，没有架构设计，你就可以试着申辩说这是专门设计的单体架构（说点专业的，唬唬人）。
单体架构通常被用来实现安全关键系统中的部分功能，这类系统的内部组件间必须实时通信，并且通信开销尽可能小。单体架构采用的典型机制是编程语言中的安全机制，例如使用静态变量，没有内存管理，不使用动态结构等。微内核架构又称插件架构，指的是软件的内核相对较小，主要功能和业务逻辑通过插件实现，许多现代操作系统都采用这种架构。这种架构可以被看作分层架构中的一种双层架构的特例。
内核包含系统运行的最小功能，是具有更高执行权限的有限组件的集合，如任务调度程序、内存管理和基础进程间通管理，这些组件相较于应用层的组件而言拥有更高级别的权限。应用程序则是相互独立的，它们之间的通信应该减至最少，避免出现互相依赖的问题。例如，用户应用程序进程、设备驱动程序或文件服务的组件，这些组件可以具备不同的权限级别，但是其权限级别要始终低于内核进程。
在汽车行业中，微内核架构被用于某些要求高安全性的组件。微内核架构具有以下优点：具有良好的功能延申性；功能之间相互隔离，应用程序可以独立加载和卸载，容易部署；可定制性高，能适应不同的开发需要；可以渐进式开发，逐步增加功能。微内核架构的缺点主要有：扩展性差，内核通常是一个独立单元，不容易做成分布式；因为涉及应用程序与内核的通信，以及内部的应用程序登记机制，开发难度较大。管道与过滤器架构适用于基于数据处理而运行的系统，这种架构假定组件沿着数据处理流的方向进行连接，在现代汽车软件中，这种架构在主动安全域的图像识别功能中十分常见，这一功能需要在多个阶段处理大量的视频数据，且组件之间必须相互独立。如果去看Camera的相关介绍，经常会看到pipeline这样的说法，可能就是因为Camera的处理是流式的，按照一定的顺序获取和处理数据。
管道域过滤器架构由两大组件构成，一个为过滤器，另一个为管道。过滤器的主要功能为从输入接口读取数据，然后经过特定的处理，将结果数据置于输出接口。管道式连接各个过滤器的组件，负责过滤器间数据的传输，充当过滤器之间数据流的通道。
管道与过滤器架构具有以下优点：符合高内聚、低耦合的设计原则，可以方便地对过滤器进行替换或删除等操作；支持模块的重用，可以将单个独立的过滤器应用到其他软件系统中；支持并行执行，每个过滤器是一个独立的实体，可以单独运行，不受其他过滤器影响。管道与过滤器架构的缺点主要有：不适合处理交互的应用；传输的数据没有标准化，所以读入数据和输出数据存在格式转换等问题，会导致性能降低。客户端-服务器模式(Client–server model)简称C/S结构，是一种网络架构，它把客户端(Client) 与服务器 (Server) 区分开来。每一个客户端软件的实例都可以向一个服务器或应用程序服务器发出请求。
这种系统的设计原则指定了具有特定角色的组件之间的解耦，即服务器根据客户端的请求提供资源。客户端-服务器架构的优点是：客户端和服务器可以独立地进行升级和扩展，从而提高了系统的可扩展性；服务器可以对客户端进行授权和身份验证，从而提高了系统的安全性；可以根据不同的应用需求选择不同的客户端和服务器软件，以适应不同的场景。客户端-服务器架构的缺点是：服务器是系统的核心部分，一旦服务器出现故障，整个系统就会瘫痪；网络带宽和延迟等因素会影响客户端和服务器之间的通信效率；由于客户端和服务器需要分别进行维护，因此维护成本较高。后文提到的SOME/IP用的就是客户端-服务器的架构思想。发布者-订阅者架构可以当作是客户-服务器架构的特例，这种架构规定信息的提供者和信息的使用者之间是轻耦合的。订阅者向中央存储订阅信息，以便获得有关信息的通知。发布者不知道订阅者，其任务仅仅是更新信息，这与客户-服务器架构有明显的差异，后者由服务器将信息直接发送到已知的客户端。
在汽车软件中，发布者-订阅者架构通常用于分发有关车辆状态变化的信息。其优点在于信息发布者和信息订阅者之间的解耦，信息发布者不会随着订阅者数量的增加而出现过载的情况。其缺点是信息发布者无法控制哪些组件使用信息，也无法确定在任意给定时刻相关组件拥有的信息内容（因为组件不必同步接收更新）。后文中提到的DDS用的就是发布者-订阅者的架构思想。中间件架构假定存在一个公共请求代理，其协调不同组件的资源使用需求。中间件的概念是随着对象管理组织推出的公用对象请求代理体系结构被引入软件工程当中的。AUTOSAR标准的设计中使用了中间件架构，中间件在汽车软件的适应机制和容错机制中正变得越来越重要。中间件是目前汽车软件架构的重要组成部分，后面会讲。
面向服务的架构（Service-Oriented Architecture，SOA）假设组件之间的松耦合采用互联网的协议标准。它所强调的是架构中组件的接口可以使用网络服务来访问，并且可以在系统运行期间按照需要添加和更改服务。
目前汽车电子电气架构由分布式向集中式演进，同时为了满足用户对智能化功能的快速迭代需求，汽车行业正迎来一场新的变革。在这场变革中，SOA是关键。SOA的关键是将位于整车ECU上的应用程序的不同功能单元拆分为服务，并定义服务接口，借助中间件实现服务的互操作。因此对于实现面向服务的架构，中间件是关键核心要素。各种架构风格并不是互斥的，一种特定的架构可能是由多种架构风格组成的，通过将多种基本风格组合为单个的协作风格来形成一种混合风格。在大的维度的上，是以分层架构来设计的，但在每一层软件实现上，可能会使用其他的架构风格。后文会对SOA进行展开，就可以看到，SOA里面有多种架构风格的体现。
![]()
TTiaMib5iavNgtR7G4jOEH5z3MRXgIicp4ibKia6FOV5bRFppI3FjcA/640?wx_fmt=gif" src="https://semi-static.oss-cn-hangzhou.aliyuncs.com/article/2024/07/17/1721219720.jpg" alt="图片">
看完软件架构风格，来更直观地感受下车载软件架构是什么样的。网络上各种文章里提出的各种架构很多，这里给出的是《车载智能计算基础平台参考架构2.0》里提出的架构。该文章是由工信部牵头联合多个机构给出的白皮书，与各种通信协议一样，政府也希望智能汽车的软硬件平台能够统一标准，推动产业发展。
白皮书中对车载智能计算基础平台的定义是，支撑智能网联汽车驾驶自动化功能实现的软硬件一体化平台，包括芯片、模组、接口等硬件以及系统软件、功能软件等软件。该基础平台架构包含异构分布硬件架构、车控操作系统、安全体系、工具链。该基础平台最下层是异构分布硬件架构，负责提供各类硬件结构和满足多方面算力需求，包括AI计算单元、通用计算单元、控制单元和安全处理单元。可以狭义理解为以GPU、MCU、FPGA等为核心构建的硬件平台。车控操作系统是支撑智能网联汽车驾驶自动化功能实现和安全可靠运行的软件集合。车控操作系统采用纵向分层（包含系统软件和功能软件）、横向分区（包括安全车控操作系统、智能驾驶操作系统）式架构。插一句，操作系统分狭义和广义之分，上面说的是广义的，狭义的操作系统仅指OS，例如Linux、QNX等。系统软件纵向分为跨内核驱动框架层、内核及虚拟化管理层、系统接口层、系统中间件层。系统软件通过标准的系统接口、系统中间件向上层提供服务，实现与功能软件的解耦；通过跨内核驱动框架（包括 AI 驱动、BSP 等各类驱动）、硬件抽象层，实现与硬件平台的解耦。功能软件是根据各类智能驾驶功能的核心共性需求，定义和实现共性的功能组件，并通过标准的应用软件接口及服务，向上层应用软件提供服务，实现与应用软件的解耦。安全体系保障车载智能计算基础平台的质量安全和使用安全，包括功能安全、预期功能安全、网络安全、数据安全、OTA 安全、融合安全等。工具链为车载智能计算基础平台的开发迭代提供支撑，包括开发调试工具、测试仿真工具、持续集成工具、过程管理工具等。我们重点看车载操作系统，这是软件的部分。这部分可以简化如下图所示。
驱动负责管理底层的硬件资源，驱动程序本质上是软件代码，主要作用是计算机系统与硬件设备之间完成数据传送的功能，只有借助驱动程序，两者才能通信并完成特定的功能。这部分软件工作和底层软件耦合比较多。虚拟化技术用于支持多个不同的操作系统在平台上运行。由于不同应用对于实时性和安全性的差异，常常会在一个SOC上运行不同操作系统。另外，座舱发展到目前阶段，一芯多屏是基本配置。虚拟化能够管理并虚拟化CPU、内存、外接设备等硬件资源，并将它们分配给运行在虚拟化管理系统软件上的多个操作系统内核。OS是狭义的操作系统，根据不同的应用，需要使用到不同的OS，后面会简单介绍下。系统接口是操作系统内核对上层软件提供的服务接口，支持内存分配、调度管理、I/O处理、同步互斥等功能。POSIX API能提升跨多种操作系统内核的兼容性。POSIX API有实时扩展，包括定时器和时间管理、优先级调度互斥量和条件 变量、消息队列、共享内存、异步I/O和同步I/O等。POSIX，Portable Operating System Interface，即可移植操作系统接口。它是一个IEEE 1003.1标准，定义了应用程序和UNIX操作系统之间的操作语言。当应用程序在两个支持POSIX标准的操作系统中迁移时，可以保证其兼容性。这样应用程序就与操作系统解耦了，提高了可移植性。你看，一切为了解耦。系统中间件向下获取操作系统内核的系统接口服务的支持，向上支撑功能软件层提供系统中间件的服务和接口。系统中间件大致包含如下部分。
SOA框架通常包含模块化服务、服务注册发现、标准互操作性接口、服务编排等内容和特征。SOA是目前车载软件里一个很重要的趋势，后面也会讲。AI框架用于支撑自动驾驶AI应用和大模型应用的开发。管理中间件中包括数据加密、身份验证、健康管理、网络与系统安全监测等安全措施及服务，对功能软件中的安全框架和安全服务等提供支撑，提升整体车控系统的稳定性和安全性。通信中间件具备服务发现、远程服务调用、读写进程信息等典型功能，实现车内单一节点内进程间通信或多节点间通信传输， 由基于CAN信号向面向服务的车载以太网数据包传输过渡。基于IP的可扩展的面向服务的中间件（SOME/IP）支持复杂车载网络的服务发现和交互。在安全性方面，SOME/IP 服务发现 （SOME/IP-SD）保证了车辆网络的安全。数据分发服务（DDS）分布式通信协议可以提供灵活、可靠、实时的数据交换机制，以满足智能网联汽车中多种应用程序之间的通讯需求，并确保数据的准确性和及时性。DDS还可以提供良好的扩展性和互操作性。功能软件是根据智能驾驶共性来定义和实现的通用模块，是支撑智能驾驶应用生态建设的重要层级。说简单点，就是将零碎的资源整合成若干通用模块，便于应用程序调用。再上层的应用软件就是具体的应用实现了，比如ACC、NOA等等。解析了上面的内容后，下文将挑选其中部分展开，即OS和中间件，同时会介绍SOA的相关概念。
汽标委智能网联分标委于2021年发布了《车控操作系统架构研究报告》，该白皮书将车用操作系统分为如下几个部分。
车控操作系统分为安全车控操作系统和智能驾驶操作系统，其中，安全车控操作系统主要面向经典车辆控制领域，如动力系统、底盘系 统和车身系统等，该类操作系统对实时性和安全性要求极高，生态发展已趋于成熟。智能驾驶操作系统主要面向智能驾驶领域，应用于智能驾驶域控制器，该类操作系统对安全性和可靠性要求较高，同时对性能和运算能力的要求也较高。该类操作系统目前在全世界范围内都 处于研究发展的初期，生态尚未完备。车载操作系统主要面向信息娱乐和智能座舱，主要应用于车机中控系统，对于安全性和可靠性的要求处于中等水平，该类操作系统发展迅速，依托于该类操作系统的生态也处于迅速发展时期。该白皮书中的操作系统指的是广义上的操作系统，即系统软件和功能软件的集合。OS是系统软件中的一部分，本节只关注车控操作系统部分的OS。欧洲在20世纪90年代发展出用于汽车电子上分布式实时控制系统的开放式系统标准 OSEK/VDX，主要包括4部分标准：但随着技术、产品、客户需求等的升级，OSEK 标准逐渐不能支持新的硬件平台。
2003年，宝马、博世、大陆、戴姆勒、通用、福特、标志雪铁龙、丰田、大众9家企业作为核心成员，成立了一个汽车开放系统架构组织（简称 AUTOSAR 组织），致力于建立一个标准化平台，独立于硬件的分层软件架构，制定各种车辆应用接口规范和集成标准，为应用开发提供方法论层面的指导，以减少汽车软件设计的复杂度，提高汽车软件的灵活性和开发效率，以及在不同汽车平台的复用性。 AUTOSAR 以 OSEK/VDX 为基础，但涉及的范围更广。AUTOSAR 组织已发布 Classic和 Adaptive 两个平台规范，分别对应安全控制类和自动驾驶的高性能类。Classic 平台基于 OSEK/VDX 标准，定义了安全车控操作系统的技术规范。需要说明的是Classic AUTOSAR不仅仅定义了OS，还定义了中间件。智能驾驶操作系统将会成为自动驾驶汽车发展的核心竞争力之一。智能驾驶操作系统发展趋势和特点是纵向分层，以实现层与层之间的解耦，方便快速开发和移植，如下图所示。
AUTOSAR组织为应对自动驾驶技术的发展推出了Adaptive AUTOSAR（AP）架构，如下图所示，其主要特点是采用面向服务的架构（SOA），服务可根据应用需求动态加载，可通过配置文件动态加载配置，并可进行单独更新，相对于 Classic AUTOSAR（CP），可以满足更强大的算力需求，更安全，兼容性好，可进行敏捷开发。
Adaptive AUTOSAR系统主要适应于新的集中式的高性能计算平台，满足车内部件之间的高速通信需求和智能驾驶的高计算能力需求。AP平台采用了服务化的架构，系统由一系列的服务组成，应用和其他软件模块可以根据需求调用其中的一个或者多个服务，而服务可以是平台提供的，也可以是远程其他部件提供。
AP平台没有设计新的操作系统内核，所有符合 POSIX PSE51接口的操作系统内核都可以使用。目前普遍采用的车控操作系统底层内核主要有Linux、QNX和其他 RTOS（如 FreeRTOS、ThreadX、VxWorks等），三者之间的主要特点对比如下表所示。
介绍完了操作系统内核，再往上，理论上就要讲中间件。但中间件是为了上下层服务的，所以在这之前，要先介绍SOA。上文讲了各种软件架构风格，在汽车发展的不同阶段和不同场景中，可能都有被应用。但要重点讲的是SOA，这在各种文章中也是高频出现的，这是以后新能源汽车一个明确的趋势。这个概念其实并不新鲜，早在20多年前，WebService出现的时候，SOA就已被誉为是下一代Web服务的基础框架。但是用在汽车上确是近年来随着软件定义汽车的发展，SOA在汽车上才开始得到应用。也就是说SOA在其他领域已经被用上了，汽车只是将SOA的概念拿来用。汽车SOA是对整车智能化的底层能力进行组织。将车端的硬件能力和各种功能SOA化，划分为不同的服务，拆分成颗粒度更小的接口。这些服务根据SOA标准进行接口设计，基于SOA标准协议进行通信。说明白点，就是将各种ECU的能力以“菜单”形式呈现出来，中央控制器根据ECU展现出来的能力，去要求ECU执行特定的操作。例如，车舱内有很多灯，灯的颜色、闪烁频率、亮度等可选。所有灯可以作为一个整体，通过特定的协议（比如SOME/IP或DDS）向中央控制器表明自己可以提供如上服务。这样，各服务组件之间就可以相互访问，从而扩展了服务的组合形式。举个例子，目前很多车上有DMS系统，DMS是检测驾驶员状态的。随便假设一个场景，我们需要做一个欢迎灯效，当驾驶员进车落座后，车舱内的灯产生一定的灯效。那么其实就是DMS系统要调用灯的服务，DMS系统通过SOME/IP协议，获得灯的服务，DMS+灯的组合，就可以形成这样的场景应用。根据用户需求和工程师们的想象力，不同组件之间的组合可能会产生很多有趣的功能。SOA是面向服务，与之相对的是面向信号。为了实现某一项功能，ECU从底层到应用层开发了一整套的软件，并根据事先设定的特定信号与外部进行交互。传统EE架构中，ECU 由不同的供应商开发，框架无法复用，无法统一，集成难度大。如果开发新的功能，那么整条软件链路上所有相关的参数都需要重新编写和配置，也就是说模块之间的耦合度太高，其中一个升级会影响其他模块都得跟着升级。功能模块复用率非常低，牵一发而动全身，任何功能的更改，都会带来非常大的工作量。还是来举个例子，对于面向服务，DMS系统只需要向灯光系统请求，执行“欢迎灯效”（灯光系统预先定义了某一种功能或服务）。对于面向信号，DMS需要发送的信息则可能是，先开左边的绿色的灯，再开右边红色的灯。在不同的车型上，如果灯光系统有变更。对于SOA，只需要查看下灯光系统支持什么功能，然后调用就好了。但对于面向信号的架构，则需要很多细节的软件逻辑或参数。
SOA软件架构的特性就是高内聚、松耦合、服务平台无关化、服务动态部署/动态发现。因而为汽车出厂后的持续升级和服务降低难度、拓展出更多的可能性。看了上面说的，来思考一下，为什么汽车上要用SOA？一切的目的都是为了实现“软件定义汽车”。手机可以通过系统升级，快速增加各种新的特性，使得用户觉得常用常新。所以，完全可以说是软件定义手机。对于传统的燃油车，基本在出厂的时候，其功能就固定了，这就应该叫做机械定义汽车。机械上的迭代是需要很长的周期的，在以往行业竞争没这么激烈的时候，各个厂家都有自己的特点，有自己的用户群体。但来到了新能源车时代，车上突然多了很多电子设备，当然还是可以按照以前的路子来，出厂就锁定。但电子设备上其实是有一定的灵活性的，即其中的软件可以快速迭代，当某个厂家可以频繁快速的提供各种更新，那其产品力就大大提升。另外，可以提供多种付费软件，增加营收。特斯拉就是走的这个路子，可以提供各种软件服务，大家付费购买。虽然我是硬件出身，但不得不承认，要实现产品的差异化，还是要依靠软件（当然，如果自己做芯片，且能有跨代的性能差异，那另说）。为了实现软件定义汽车的目的，就要解开软件的手脚，让其自由来去，大展拳脚。因此，需要先做下面几件事。上一篇文章，两万多字介绍了EEA架构。EEA要做的很重要的一件事就是软硬解耦。在初期的分布式电子电气架构阶段，一辆车上有几十个ECU，每个ECU里都有自己的处理器来承担相应的逻辑驱动。当整车需要功能迭代时，可能多要多个ECU共同修改配合。最终能不能做成另说，工程师在这个过程中，要花费大量的时间沟通。EEA架构向着中央集中式架构演进，就是要把控制权回收，集中在自己的手里，大部分的ECU就变成单纯的执行器。这就使得软件从多个ECU抽取出来，汇集到区域控制器和中央控制器中，软件被独立出来，就有了操作自由度。每个控制器上带着各种ECU，这是控制器的负载，这些ECU的功能后期可能会被标准化。区域控制器根据所有ECU的硬件功能以及自身软件功能的设计，将自身的能力抽象出若干服务，并通过标准协议，对外提供“菜单”。这样，不同组件可以调用互相的服务，形成不同的应用。最重要的是，可以快速迭代。几个ECU换了供应商，没关系，只需要更新下自身的“菜单”即可。SOA要抽象出服务，虽然分布式架构也可以抽象，但不如集中式架构来得效率高。因此，可以说EEA功能架构的演进使得软件系统架构有了更高的服务抽象的能力。所谓服务发现，就是说当ECU的各项能力被抽象出来后，可以被其他组件发现并调用。这就使得SOA有了动态配置的能力，提高了系统的可维护性和可配置性。当一个服务失效时，可以很快的用另一个相同功能的服务替换掉它，新服务的访问点信息会很快在系统中被其它服务获取，系统可以很快能从服务失效引起的错误中恢复，提高了系统的可靠性。当某个服务需要被升级时，也可以采用类似的方式进行，对系统的可进化性也有显著帮助。在SOA中，以上工作依靠一些通信协议来实现，比如SOME/IP、DDS等。这些通信协议里，包含了服务的一些具体信息。SOME/IP和DDS其实是一种消息中间件。是的，SOA中用到了中间件的架构风格，其中最出名的中间件就是AUTOSAR。在之前的文章中，将网络架构作为EEA架构中其中一个维度。这里将其单独拎出来，是因为网络架构升级是实现SOA架构风格的关键技术。在分布式电子电气架构阶段，车上主要使用CAN或CANFD作为主干总线。CAN(FD)总线速度低、无效载荷开销大（甚至>50%）、有效数据长度太小（CAN 8字节，CAN FD 64字节）。伴随着智能驾驶、智能座舱等功能的引入，整车数据吞吐量急剧增加，CAN(FD)总线显得有心无力。在这样的需求背景下，诞生了适用汽车领域的车载以太网。车载以太网提供100Mbp~10bps的带宽能力，可以说一步到位解决汽车当前及以后的数据吞吐量不断增加的难题。很巧的是，车载以太网的应用，使得SOA也有了发展的基础。以太网为什么能够推动SOA的发展，是因为其具有CAN总线没有的特点，即支持IP协议，Flexray、LIN和CAN一样，都不支持IP协议。这意味着这几个网络是无法互通的。汽车电子电器架构设计的时候，解决互通问题的办法就是两个网络中间加网关。网关同时支持两个以上网络并来回搬运数据。即使是两条Can总线想要互通也需要加网关，而且网关的数据搬运代码都需要单独定制，因为每条Can的应用层协议都不一样。设想一下，在这种网络环境下做SOA服务是什么效果。假如我们基于Can协议实现了一个SOA服务，我们没法进行RPC（远程过程调用）请求，因为 Can 协议没有寻址的概念，请求不知道发给谁。不过好消息是Can 本质上也是发布订阅的机制，我们可以放弃单播通讯，只做事件广播。但Can一个消息只有8个字节，没有地方放更多的头信息，我们在设计服务发现机制的时候会遇到巨大挑战。就算我们设计出了服务发现，对不起，这个服务在别的网段中不会被发现，因为各个网段的服务是不能互通的。我们就需要开发网关程序跨网段搬运数据。但是每增加一个服务，或者对服务的数据格式做些修改，网关程序都要重新修改适配。就算这些都完成了，我们想让一个开发好的服务在另一个项目中复用几乎不可能，因为对应的Can 协议，网关程序全部都要重新适配。引入以太网技术带来的 IP 层是解决这些问题的关键。不管各段网络的物理层和链路层是什么样的，只要支持 IP层协议，IP报文就可以在不同网段之间传输。IP 协议是可以支持广播和多播（一次数据发送，多个目标接收）的。而且广播和多播是可以跨网段的，有成熟的协议支持。广播和多播可被用于SOA 的“服务发现”和服务之间的数据发布订阅。当有个IP之后，每一个服务就是一个独立的可执行的软件组件，可以对其赋予特定的IP地址和标准化接口以便随时调用，最终通过对这些底层功能的自由组合，以实现某项复杂的智能化功能。
