电子发烧友App
0 序言
汽车EEA架构演变中一个明显的特点是软硬解耦，OEM将大部分ECU的控制逻辑集中到区域控制器中。区域控制器将数据上传到中央控制器，中央控制器进行运算处理，并将结果或者决策下发到区域控制器去执行。Tier1逐步成为硬件供应商，只需要按照特定功能和接口提供执行器即可。当需要更换另一家Tier1的ECU时，区域控制器的控制逻辑甚至不需要做更改，或者只需要做简单的修改。这应该就是所谓的“软硬解耦”。
人类工业史到处都有解耦这个概念，比如我总能想到初中历史课上有讲到美国工业发展的那段，福特搞起了第一条汽车生产线。流水线本身就是将整个制造流程分割成若干个互相解耦的工位，每个工位SOP中的多个动作可能会调整，但不会影响到其他工位的操作。下一个工位的工人，只需要无脑将上一个工位生产的零部件拿来用就好了。另外，在总线协议中，OSI七层模型，也充分发扬了解耦的这一理念。每一层的技术迭代，不会或者很少影响其他层。比如从传统以太网发展到车载以太网，物理层和数据链路层的技术有一些改变，但并不影响在车载以太网上应用TCP、UDP和IP等协议，这些是网络层和传输层的协议。
以上是从硬件工程师的角度来理解解耦，硬件工程师长期接触的是这些直观的物理事物，比较容易理解。硬件上讲究解耦，软件上当然也要解耦。读研时，写过单片机的裸机代码，刚开始不太懂，吃了很多亏。比如我要控一个灯，灯的亮度与PWM的占空比有关，我在主程序里定义PWM=50，但主程序里可能会出现多个PWM=50的这一条代码。当我要改PWM占空比的时候，需要将多条代码都修改才行。如果在头文件里，用宏定义就可以只改一条代码，且代码的可读性也大大增加。用宏定义只是最初级的解耦方式，在一个复杂的软件系统里，会有多种维度上的解耦。工程师们将系统抽象出好多个层，不同的工程师负责不同层的软件开发。一来，在开发阶段，大家可以独立开发；二来，在做迭代的时候，不同层的工程师也可以独立快速的搞完自己的业务，而不必过多的依赖其他工程师的支持。
上一篇文章学习了EEA架构的演变，EEA架构是软件架构得以实现的基础，而好的软件架构又能够充分发挥EEA架构的能力。本文试图从软件的门口路过，朝里面看一眼，大致理解一下软件工程师们在做哪些事情。
1 软件架构风格
软件工程师将软件代码抽象出若干个层，再怎么抽象上层软件，最终都会通过编译器“翻译”成多个机器码。这些机器码是由底层半导体厂商定义的，比如高通的芯片用的是ARM的架构，那就遵循ARM的指令集。指令集即上述机器码的集合，定义了哪些机器码对应了哪些功能。具体的功能则由微架构实现，微架构可以理解为固化在处理器中的最底层的电路，这些在之前的文章中都有谈到。因此，从硬件工程师的角度来看软件，可以从下往上看，心里有底，毕竟参天大树是从硬件的土壤里生长起来的，这是软硬件的联结处。
硬件工程师将底层的硬件地基夯实好，软件工程师便在其上一层层垒砖头。一个简单的软件建筑没有什么规则，讲究一个快速实现功能就好。但如果要建一个软件摩天大楼，规矩就多了，比如如何使得系统更容易测试，更容易迭代等等。软件架构的设计可以遵循不同的风格（或者说是规矩），这些风格本质上是定义了用于描述系统的术语表和一组指导构建系统的规则。在初识“汽车软件”这座建筑之前，可以先看看软件架构有哪些风格。
软件工程师根据项目的特点和需要选择特定的软件架构风格,这和不同地方根据当地气候和民族特色选择不同的建筑风格其实差不多。至于如何从哪些维度去评判软件架构的好坏，可以查看《自动驾驶软件架构之中间件与SOA介绍》这篇文章，里面有提到一些软件架构的评估方法。
1.1分层架构
分层架构是最常见的软件架构，这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节，层与层之间通过接口通信。在这种架构中，函数调用的方向是固定的，仅能从较高层级向较低层级调用。
分层架构具有以下优点：结构简单，容易理解和开发；不同技能的程序员可以负责不同的层，天然适合大多数软件公司的组织架构；每一层可以独立测试，其他层的接口通过模拟解决。
分层架构的缺点是：扩展性差，上下层还是存在一些耦合，有些功能的变化，可能涉及多层的修改；业务流需要经过多层代码的处理，性能会有所降低；分层结构中，只能由上层组件调用下层组件，同一个层级中的组件之间无法相互通信，导致软件架构不太灵活。
1.2基于组件的架构
基于组件的架构，比分层架构更加灵活，所有组件都可以进行消息交互或者相互独立。所有的通信都应该经过规范定义的公共接口进行，并且每个组件都具备单一的接口，以便通过接口实现对组件的查询。Windows系统就是典型的基于组件的架构，其大量使用了动态链接库和IUnKnown接口。
需要说明的是，基于组件的架构并不是完全替代分层架构，架构可以分为多个层次。在大的维度上，软件架构可以使用分层架构。比如系统可以分为平台层和应用层，这是分层架构的概念。但是在应用层内，多个应用之间可以采用基于组件的架构，多个APP可以互相调用。
1.3单体架构
与基于组件的架构相反，其假定整个系统是一个大型组件，系统中的所有模块都可以相互使用。这种风格通常用于低成熟度的系统，因为它会导致系统的高耦合和高复杂度。当有人质疑你的代码没有分层，没有架构设计，你就可以试着申辩说这是专门设计的单体架构（说点专业的，唬唬人）。
单体架构通常被用来实现安全关键系统中的部分功能，这类系统的内部组件间必须实时通信，并且通信开销尽可能小。单体架构采用的典型机制是编程语言中的安全机制，例如使用静态变量，没有内存管理，不使用动态结构等。
1.4微内核架构
微内核架构又称插件架构，指的是软件的内核相对较小，主要功能和业务逻辑通过插件实现，许多现代操作系统都采用这种架构。这种架构可以被看作分层架构中的一种双层架构的特例。
内核包含系统运行的最小功能，是具有更高执行权限的有限组件的集合，如任务调度程序、内存管理和基础进程间通管理，这些组件相较于应用层的组件而言拥有更高级别的权限。应用程序则是相互独立的，它们之间的通信应该减至最少，避免出现互相依赖的问题。例如，用户应用程序进程、设备驱动程序或文件服务的组件，这些组件可以具备不同的权限级别，但是其权限级别要始终低于内核进程。
在汽车行业中，微内核架构被用于某些要求高安全性的组件。微内核架构具有以下优点：具有良好的功能延申性；功能之间相互隔离，应用程序可以独立加载和卸载，容易部署；可定制性高，能适应不同的开发需要；可以渐进式开发，逐步增加功能。
微内核架构的缺点主要有：扩展性差，内核通常是一个独立单元，不容易做成分布式；因为涉及应用程序与内核的通信，以及内部的应用程序登记机制，开发难度较大。
1.5管道与过滤器架构
管道与过滤器架构适用于基于数据处理而运行的系统，这种架构假定组件沿着数据处理流的方向进行连接，在现代汽车软件中，这种架构在主动安全域的图像识别功能中十分常见，这一功能需要在多个阶段处理大量的视频数据，且组件之间必须相互独立。如果去看Camera的相关介绍，经常会看到pipeline这样的说法，可能就是因为Camera的处理是流式的，按照一定的顺序获取和处理数据。
管道域过滤器架构由两大组件构成，一个为过滤器，另一个为管道。过滤器的主要功能为从输入接口读取数据，然后经过特定的处理，将结果数据置于输出接口。管道式连接各个过滤器的组件，负责过滤器间数据的传输，充当过滤器之间数据流的通道。
管道与过滤器架构具有以下优点：符合高内聚、低耦合的设计原则，可以方便地对过滤器进行替换或删除等操作；支持模块的重用，可以将单个独立的过滤器应用到其他软件系统中；支持并行执行，每个过滤器是一个独立的实体，可以单独运行，不受其他过滤器影响。
管道与过滤器架构的缺点主要有：不适合处理交互的应用；传输的数据没有标准化，所以读入数据和输出数据存在格式转换等问题，会导致性能降低。
1.6客户端-服务器架构
客户端-服务器模式(Client–server model)简称C/S结构，是一种网络架构，它把客户端(Client) 与服务器 (Server) 区分开来。每一个客户端软件的实例都可以向一个服务器或应用程序服务器发出请求。
这种系统的设计原则指定了具有特定角色的组件之间的解耦，即服务器根据客户端的请求提供资源。
客户端-服务器架构的优点是：客户端和服务器可以独立地进行升级和扩展，从而提高了系统的可扩展性；服务器可以对客户端进行授权和身份验证，从而提高了系统的安全性；可以根据不同的应用需求选择不同的客户端和服务器软件，以适应不同的场景。
客户端-服务器架构的缺点是：服务器是系统的核心部分，一旦服务器出现故障，整个系统就会瘫痪；网络带宽和延迟等因素会影响客户端和服务器之间的通信效率；由于客户端和服务器需要分别进行维护，因此维护成本较高。
后文提到的SOME/IP用的就是客户端-服务器的架构思想。
1.7发布者-订阅者架构
发布者-订阅者架构可以当作是客户-服务器架构的特例，这种架构规定信息的提供者和信息的使用者之间是轻耦合的。
订阅者向中央存储订阅信息，以便获得有关信息的通知。发布者不知道订阅者，其任务仅仅是更新信息，这与客户-服务器架构有明显的差异，后者由服务器将信息直接发送到已知的客户端。
在汽车软件中，发布者-订阅者架构通常用于分发有关车辆状态变化的信息。其优点在于信息发布者和信息订阅者之间的解耦，信息发布者不会随着订阅者数量的增加而出现过载的情况。其缺点是信息发布者无法控制哪些组件使用信息，也无法确定在任意给定时刻相关组件拥有的信息内容（因为组件不必同步接收更新）。
后文中提到的DDS用的就是发布者-订阅者的架构思想。
1.8中间件架构
中间件架构假定存在一个公共请求代理，其协调不同组件的资源使用需求。中间件的概念是随着对象管理组织推出的公用对象请求代理体系结构被引入软件工程当中的。AUTOSAR标准的设计中使用了中间件架构，中间件在汽车软件的适应机制和容错机制中正变得越来越重要。中间件是目前汽车软件架构的重要组成部分，后面会讲。
1.9面向服务的架构
面向服务的架构（Service-Oriented Architecture，SOA）假设组件之间的松耦合采用互联网的协议标准。它所强调的是架构中组件的接口可以使用网络服务来访问，并且可以在系统运行期间按照需要添加和更改服务。
目前汽车电子电气架构由分布式向集中式演进，同时为了满足用户对智能化功能的快速迭代需求，汽车行业正迎来一场新的变革。在这场变革中，SOA是关键。SOA的关键是将位于整车ECU上的应用程序的不同功能单元拆分为服务，并定义服务接口，借助中间件实现服务的互操作。因此对于实现面向服务的架构，中间件是关键核心要素。
1.10总结
各种架构风格并不是互斥的，一种特定的架构可能是由多种架构风格组成的，通过将多种基本风格组合为单个的协作风格来形成一种混合风格。在大的维度的上，是以分层架构来设计的，但在每一层软件实现上，可能会使用其他的架构风格。后文会对SOA进行展开，就可以看到，SOA里面有多种架构风格的体现。
2 车载智能计算基础平台参考架构
看完软件架构风格，来更直观地感受下车载软件架构是什么样的。网络上各种文章里提出的各种架构很多，这里给出的是《车载智能计算基础平台参考架构2.0》里提出的架构。该文章是由工信部牵头联合多个机构给出的白皮书，与各种通信协议一样，政府也希望智能汽车的软硬件平台能够统一标准，推动产业发展。
白皮书中对车载智能计算基础平台的定义是，支撑智能网联汽车驾驶自动化功能实现的软硬件一体化平台，包括芯片、模组、接口等硬件以及系统软件、功能软件等软件。
该基础平台架构包含异构分布硬件架构、车控操作系统、安全体系、工具链。
该基础平台最下层是异构分布硬件架构，负责提供各类硬件结构和满足多方面算力需求，包括AI计算单元、通用计算单元、控制单元和安全处理单元。可以狭义理解为以GPU、MCU、FPGA等为核心构建的硬件平台。
车控操作系统是支撑智能网联汽车驾驶自动化功能实现和安全可靠运行的软件集合。车控操作系统采用纵向分层（包含系统软件和功能软件）、横向分区（包括安全车控操作系统、智能驾驶操作系统）式架构。插一句，操作系统分狭义和广义之分，上面说的是广义的，狭义的操作系统仅指OS，例如Linux、QNX等。
系统软件纵向分为跨内核驱动框架层、内核及虚拟化管理层、系统接口层、系统中间件层。系统软件通过标准的系统接口、系统中间件向上层提供服务，实现与功能软件的解耦；通过跨内核驱动框架（包括 AI 驱动、BSP 等各类驱动）、硬件抽象层，实现与硬件平台的解耦。
功能软件是根据各类智能驾驶功能的核心共性需求，定义和实现共性的功能组件，并通过标准的应用软件接口及服务，向上层应用软件提供服务，实现与应用软件的解耦。
安全体系保障车载智能计算基础平台的质量安全和使用安全，包括功能安全、预期功能安全、网络安全、数据安全、OTA 安全、融合安全等。
工具链为车载智能计算基础平台的开发迭代提供支撑，包括开发调试工具、测试仿真工具、持续集成工具、过程管理工具等。
我们重点看车载操作系统，这是软件的部分。这部分可以简化如下图所示。
2.1 驱动
驱动负责管理底层的硬件资源，驱动程序本质上是软件代码，主要作用是计算机系统与硬件设备之间完成数据传送的功能，只有借助驱动程序，两者才能通信并完成特定的功能。这部分软件工作和底层软件耦合比较多。
2.2 虚拟化
虚拟化技术用于支持多个不同的操作系统在平台上运行。由于不同应用对于实时性和安全性的差异，常常会在一个SOC上运行不同操作系统。另外，座舱发展到目前阶段，一芯多屏是基本配置。虚拟化能够管理并虚拟化CPU、内存、外接设备等硬件资源，并将它们分配给运行在虚拟化管理系统软件上的多个操作系统内核。
2.3 OS
OS是狭义的操作系统，根据不同的应用，需要使用到不同的OS，后面会简单介绍下。
2.4 系统接口
系统接口是操作系统内核对上层软件提供的服务接口，支持内存分配、调度管理、I/O处理、同步互斥等功能。POSIX API能提升跨多种操作系统内核的兼容性。POSIX API有实时扩展，包括定时器和时间管理、优先级调度互斥量和条件 变量、消息队列、共享内存、异步I/O和同步I/O等。
POSIX，Portable Operating System Interface，即可移植操作系统接口。它是一个IEEE 1003.1标准，定义了应用程序和UNIX操作系统之间的操作语言。当应用程序在两个支持POSIX标准的操作系统中迁移时，可以保证其兼容性。这样应用程序就与操作系统解耦了，提高了可移植性。你看，一切为了解耦。
2.5 中间件
系统中间件向下获取操作系统内核的系统接口服务的支持，向上支撑功能软件层提供系统中间件的服务和接口。系统中间件大致包含如下部分。
SOA框架通常包含模块化服务、服务注册发现、标准互操作性接口、服务编排等内容和特征。SOA是目前车载软件里一个很重要的趋势，后面也会讲。
AI框架用于支撑自动驾驶AI应用和大模型应用的开发。
管理中间件中包括数据加密、身份验证、健康管理、网络与系统安全监测等安全措施及服务，对功能软件中的安全框架和安全服务等提供支撑，提升整体车控系统的稳定性和安全性。
通信中间件具备服务发现、远程服务调用、读写进程信息等典型功能，实现车内单一节点内进程间通信或多节点间通信传输， 由基于CAN信号向面向服务的车载以太网数据包传输过渡。基于IP的可扩展的面向服务的中间件（SOME/IP）支持复杂车载网络的服务发现和交互。在安全性方面，SOME/IP 服务发现 （SOME/IP-SD）保证了车辆网络的安全。数据分发服务（DDS）分布式通信协议可以提供灵活、可靠、实时的数据交换机制，以满足智能网联汽车中多种应用程序之间的通讯需求，并确保数据的准确性和及时性。DDS还可以提供良好的扩展性和互操作性。
2.6 功能软件
功能软件是根据智能驾驶共性来定义和实现的通用模块，是支撑智能驾驶应用生态建设的重要层级。说简单点，就是将零碎的资源整合成若干通用模块，便于应用程序调用。
再上层的应用软件就是具体的应用实现了，比如ACC、NOA等等。
解析了上面的内容后，下文将挑选其中部分展开，即OS和中间件，同时会介绍SOA的相关概念。
3 OS
汽标委智能网联分标委于2021年发布了《车控操作系统架构研究报告》，该白皮书将车用操作系统分为如下几个部分。
车控操作系统分为安全车控操作系统和智能驾驶操作系统，其中，安全车控操作系统主要面向经典车辆控制领域，如动力系统、底盘系 统和车身系统等，该类操作系统对实时性和安全性要求极高，生态发展已趋于成熟。智能驾驶操作系统主要面向智能驾驶领域，应用于智能驾驶域控制器，该类操作系统对安全性和可靠性要求较高，同时对性能和运算能力的要求也较高。该类操作系统目前在全世界范围内都 处于研究发展的初期，生态尚未完备。
车载操作系统主要面向信息娱乐和智能座舱，主要应用于车机中控系统，对于安全性和可靠性的要求处于中等水平，该类操作系统发展迅速，依托于该类操作系统的生态也处于迅速发展时期。
该白皮书中的操作系统指的是广义上的操作系统，即系统软件和功能软件的集合。OS是系统软件中的一部分，本节只关注车控操作系统部分的OS。
3.1 安全车控操作系统OS
欧洲在20世纪90年代发展出用于汽车电子上分布式实时控制系统的开放式系统标准 OSEK/VDX，主要包括4部分标准：1）操作系统规范（OS）；2）通信规范；3）网络管理规范；4）OSEK实现语言。但随着技术、产品、客户需求等的升级，OSEK 标准逐渐不能支持新的硬件平台。
2003年，宝马、博世、大陆、戴姆勒、通用、福特、标志雪铁龙、丰田、大众9家企业作为核心成员，成立了一个汽车开放系统架构组织（简称 AUTOSAR 组织），致力于建立一个标准化平台，独立于硬件的分层软件架构，制定各种车辆应用接口规范和集成标准，为应用开发提供方法论层面的指导，以减少汽车软件设计的复杂度，提高汽车软件的灵活性和开发效率，以及在不同汽车平台的复用性。 AUTOSAR 以 OSEK/VDX 为基础，但涉及的范围更广。
AUTOSAR 组织已发布 Classic和 Adaptive 两个平台规范，分别对应安全控制类和自动驾驶的高性能类。Classic 平台基于 OSEK/VDX 标准，定义了安全车控操作系统的技术规范。需要说明的是Classic AUTOSAR不仅仅定义了OS，还定义了中间件。
3.2 智能驾驶操作系统OS
智能驾驶操作系统将会成为自动驾驶汽车发展的核心竞争力之一。智能驾驶操作系统发展趋势和特点是纵向分层，以实现层与层之间的解耦，方便快速开发和移植，如下图所示。
AUTOSAR组织为应对自动驾驶技术的发展推出了Adaptive AUTOSAR（AP）架构，如下图所示，其主要特点是采用面向服务的架构（SOA），服务可根据应用需求动态加载，可通过配置文件动态加载配置，并可进行单独更新，相对于 Classic AUTOSAR（CP），可以满足更强大的算力需求，更安全，兼容性好，可进行敏捷开发。
Adaptive AUTOSAR系统主要适应于新的集中式的高性能计算平台，满足车内部件之间的高速通信需求和智能驾驶的高计算能力需求。AP平台采用了服务化的架构，系统由一系列的服务组成，应用和其他软件模块可以根据需求调用其中的一个或者多个服务，而服务可以是平台提供的，也可以是远程其他部件提供。
AP平台没有设计新的操作系统内核，所有符合 POSIX PSE51接口的操作系统内核都可以使用。
目前普遍采用的车控操作系统底层内核主要有Linux、QNX和其他 RTOS（如 FreeRTOS、ThreadX、VxWorks等），三者之间的主要特点对比如下表所示。
4 面向服务的架构
介绍完了操作系统内核，再往上，理论上就要讲中间件。但中间件是为了上下层服务的，所以在这之前，要先介绍SOA。
4.1 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软件架构的特性就是高内聚、松耦合、服务平台无关化、服务动态部署/动态发现。因而为汽车出厂后的持续升级和服务降低难度、拓展出更多的可能性。
4.2 SOA的目的
看了上面说的，来思考一下，为什么汽车上要用SOA？一切的目的都是为了实现“软件定义汽车”。
手机可以通过系统升级，快速增加各种新的特性，使得用户觉得常用常新。所以，完全可以说是软件定义手机。对于传统的燃油车，基本在出厂的时候，其功能就固定了，这就应该叫做机械定义汽车。机械上的迭代是需要很长的周期的，在以往行业竞争没这么激烈的时候，各个厂家都有自己的特点，有自己的用户群体。但来到了新能源车时代，车上突然多了很多电子设备，当然还是可以按照以前的路子来，出厂就锁定。但电子设备上其实是有一定的灵活性的，即其中的软件可以快速迭代，当某个厂家可以频繁快速的提供各种更新，那其产品力就大大提升。另外，可以提供多种付费软件，增加营收。特斯拉就是走的这个路子，可以提供各种软件服务，大家付费购买。虽然我是硬件出身，但不得不承认，要实现产品的差异化，还是要依靠软件（当然，如果自己做芯片，且能有跨代的性能差异，那另说）。
4.3 SOA实现的基础
为了实现软件定义汽车的目的，就要解开软件的手脚，让其自由来去，大展拳脚。因此，需要先做下面几件事。
（1）EEA功能架构升级
上一篇文章，两万多字介绍了EEA架构。EEA要做的很重要的一件事就是软硬解耦。在初期的分布式电子电气架构阶段，一辆车上有几十个ECU，每个ECU里都有自己的处理器来承担相应的逻辑驱动。当整车需要功能迭代时，可能多要多个ECU共同修改配合。最终能不能做成另说，工程师在这个过程中，要花费大量的时间沟通。
EEA架构向着中央集中式架构演进，就是要把控制权回收，集中在自己的手里，大部分的ECU就变成单纯的执行器。这就使得软件从多个ECU抽取出来，汇集到区域控制器和中央控制器中，软件被独立出来，就有了操作自由度。
每个控制器上带着各种ECU，这是控制器的负载，这些ECU的功能后期可能会被标准化。区域控制器根据所有ECU的硬件功能以及自身软件功能的设计，将自身的能力抽象出若干服务，并通过标准协议，对外提供“菜单”。这样，不同组件可以调用互相的服务，形成不同的应用。最重要的是，可以快速迭代。几个ECU换了供应商，没关系，只需要更新下自身的“菜单”即可。
SOA要抽象出服务，虽然分布式架构也可以抽象，但不如集中式架构来得效率高。因此，可以说EEA功能架构的演进使得软件系统架构有了更高的服务抽象的能力。
（2）服务发现
所谓服务发现，就是说当ECU的各项能力被抽象出来后，可以被其他组件发现并调用。这就使得SOA有了动态配置的能力，提高了系统的可维护性和可配置性。当一个服务失效时，可以很快的用另一个相同功能的服务替换掉它，新服务的访问点信息会很快在系统中被其它服务获取，系统可以很快能从服务失效引起的错误中恢复，提高了系统的可靠性。当某个服务需要被升级时，也可以采用类似的方式进行，对系统的可进化性也有显著帮助。
在SOA中，以上工作依靠一些通信协议来实现，比如SOME/IP、DDS等。这些通信协议里，包含了服务的一些具体信息。SOME/IP和DDS其实是一种消息中间件。是的，SOA中用到了中间件的架构风格，其中最出名的中间件就是AUTOSAR。
（3）EEA网络架构升级
在之前的文章中，将网络架构作为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地址和标准化接口以便随时调用，最终通过对这些底层功能的自由组合，以实现某项复杂的智能化功能。
5 中间件
SOA软件架构下的应用软件具有标准化、相互独立和松耦合三大特点。
标准化是指每个服务件具有界定清晰的功能范围，并且留出标准化的访问接口，以便于其他控制器在进行功能变更或升级时进行订阅。
相互独立是指每个服务之间相互独立且唯一，若想升级或新增某项功能只要通过标准化的接口调用即可。
松耦合是指，应用软件可以独立于车型、硬件平台、操作系统以及编程语言。这就需要中间件来实现。
中间件本身也是一种软件，位于操作系统和应用软件之间。中间件其实就是将应用软件中常用的、重复的开发工作提取出来，以便提高重用性，而工程师可以专注于核心业务逻辑的开发。对下，它能够去适配不同的OS内核和架构；对上，它能够提供一个统一的标准接口，负责各类应用软件模块之间的通信以及对底层系统资源的调度。
举个例子，快递员给一个小区送快递，每一个快递员送每一个快递都要重复找楼栋，房间号等操作，这个很费时间。如果放在门卫处，门卫帮助分发，则可以大大提高效率。门卫在这里，就可以称为是一个中间件。
来介绍下主要的中间件标准，AUTOSAR。严格来说，AUTOSAR并非特指由某一家软件公司开发出来的某款操作系统或中间件产品，而是由全球的主要汽车生产厂商、零部件供应商、软硬件和电子工业等企业共同指定的汽车开放式系统架构标准。不过，在实践中，各公司基于AUTOSAR标准开发出来的中间件也被称为AUTOSAR。
当前，AUTOSAR可分为Classic Platform和Adaptive Platform两个平台，两者分别被简称为AUTOSAR CP与AUTOSAR AP。
简单地说，AUTOSAR CP主要跑在8bit、16bit、32bit的MCU上，对应传统的车身控制、底盘控制、动力系统等功能，如果涉及到自动驾驶的话，AUTOSAR CP可能无法实现；而AUTOSAR AP主要跑在64bit以上的高性能MPU/SOC上，对应自动驾驶的高性能电子系统。
严格地说，AUTOSAR CP并不只是个“中间件”，它是相当于“OS内核+中间件”的一套完整的“操作系统”。AUTOSAR CP定义了基本的上层任务调度、优先级调度等。在基于分布式架构的ADAS功能中，AUOTSAR CP便是最常见的“操作系统”。在AUTOSAR的生态形成后，很多芯片厂商的MCU上标配的就是AUTOSAR CP，主机厂没有什么选择权。由于分布式架构下的芯片主要是MCU，因此，便有了“AUTOSAR CP主要跑在MCU上”的说法。
随着EE架构从分布式向集中式演进、芯片由MCU向SOC演进，计算量及通信量成数量级地上升，另外，多核处理器、GPU、FPGA以及专用加速器的需求，还有OTA等，都超出了AUTOSAR CP的支持范围。
从通信速率方面来讲，随着通信技术的发展，汽车采用了以太网通信，车载以太网为汽车ECU带来了更高的带宽，使得数据的大量传输能够在短时间得以实现。以太网为更加有效地传输长消息和提供点对点通信提供了有效的解决方案。然而，AUTOSAR CP则是为了传统的车载通信技术CAN设计的，不能很好地兼容以太网，难以支持基于车载以太网的通信。
从计算能力方面来讲，近些年来汽车变得越来越智能，随之汽车对处理器的性能也提出了更高的要求，诸如自动泊车、环境感知、路径规划等高级功能对处理器的告诉案例需求远远高于对多核的需求。虽然CP已经应用于传统的多核处理技术，但依旧无法满足车辆对ECU处理能力的需求。此外，从处理器核半导体的技术角度看，提高性能的唯一方法是多核并行运行，并行运行以及所谓的异构计算也大大超出了CP能覆盖的范围。
2017年，为更好地满足集中式架构+SOC时代的高等级自动驾驶对中间件的需求，AUTOSAR联盟推出了通信能力更强、软件可配置性更灵活、安全机制要求更高的AUTOSAR AP平台。
需要强调的是，不同于AUTOSAR CP自身已经包含了基于OSEK标准的OS，AUTOSAR AP只是一个跑在Lunix、QNX等基于POSIX标准的OS上面的中间件——它自身并不包含OS。
AP和CP的主要区别如下。
总的来说，AUTOSAR CP一般应用在对实时性和功能安全要求较高、对算力要求较低的场景中，如引擎控制、制动等传统ECU；而AUTOSAR则应用在对实时性和功能安全有一定要求，但对算力要求更高的场景中，如ADAS、自动驾驶，以及在动态部署方面追求较高自由度的信息娱乐场景。
由于SOC+MCU组合的现象会长期存在，因而，在今后相当长一段时间内，AUTOSAR AP都不可能彻底取代AUTOSAR CP——最常见的分工会是，需要高算力的工作交给AUTOSAR AP,而需要高实时性的工作则交给AUTOSAR CP。
AP修改了大量的CP标准的内容，以SOA的思想进行开发，主要目的是满足当前汽车自动驾驶、电气化和互联互通等趋势的需求。下图是AP的软件分层架构。
AP的架构分层主要分为硬件层、基础服务层、ARA（实时运行环境）以及应用层。基础服务层中，主要服务包括通信服务、加密服务、日志记录服务、诊断服务、存储服务、状态管理、执行管理、时间同步、升级配置管理等。其中最常用的是通信中间件，常见的两种通信中间件是SOME/IP和DDS。下面来介绍这两种通信中间件。
5.1 通信中间件介绍
SOA软件设计原则之一是模块化，模块化可以提高可维护性、代码重用性并隔离故障。以自动驾驶为例，系统可以分解成特定的任务模块，如数据收集、状态估计、任务规划等。为了完成任务，模块必须与其他模块交换信息。在现代操作系统中，将单个模块映射到软件进程非常方便，这些进程可以位于相同的计算设备上，也可以位于物理上独立的计算设备上。这就把信息交换的任务转化为了进程间通信的问题，也就引出了对通信中间件的需求。
在没有使用通信中间件的时候，为了开发上层应用，开发者们需要定义数据的格式、数据的发送方和接收方。但有了如SOME/IP和DDS这类的中间件，采用以服务/数据为中心的发布/订阅模式后，开发者们只需要明确需要什么样的数据、数据传到哪里，而无需知道数据是由谁发出的、怎样发出的。
以数据为中心，是相对于传统的以消息为中心而言的，其与后者的本质区别在于通信中间件知道它存储了什么数据，并能控制如何共享这些数据。对传统的以消息为中心的中间件，程序员必须为发送消息编写代码；而对以数据为中心的中间件，程序员只需要为如何及何时共享数据编写代码，然后就可以直接共享数据。
常用的自动驾驶通信中间件中，SOME/IP和DDS采用的是发布/订阅模式。在这种模式中，发布者和订阅者通过主题相关联，双方不必知道对方在何处，也不必同时在线，实现了通信双方在时间、空间和数据通信上的多维松耦合。
此外，相比于面向信号的CAN，DDS和SOME/IP都是面向服务的通信协议。两者的区别在于：面向信号的数据传输，不管网络需不需要，它始终会不断循环发送；而面向服务的通信方式则不同，仅当客户端请求或服务器通知特定订阅者时，才在客户端-服务器配置中交换数据，这就确保了永远不会浪费带宽，并且仅在需要的时间和地点进行数据通信/交换。因此，面向服务的通信协议，能够大大减少网络负载，提高通信效率。
根据源代码是否开放，通信中间件可简单地分为闭源和开源两种。闭源的通信中间件主要有Vector公司的SOME/IP、RTI公司的DDS等;开源的通信中间件主要有OPEN DDS、FAST DDS、Cyclone DDS等。上面其实已经有提到了SOME/IP和DDS了。
5.2 SOME/IP协议
SOME/IP的全称为：Scalable service-Oriented MiddlewarE over IP，是一种面向服务的传输协议。严格地说，SOME/IP不是一款特定的产品，而是一种技术标准。其最早由宝马在2012-2013年开发，并在2014年集成进AUTOSAR 4.2.1中。
当前，全球最大的商用SOME/IP产品供应商是Vector。开源版的SOME/IP则是由Genivi协会来维护的。
SOME/IP是一种应用层协议，运行在TCP/IP传输协议之上，作为以太网通信中间件来实现应用层和IP层的数据交互，使其不依赖操作系统，同时能兼容AUTOSAR和非AUTOSAR平台。因此，SOME/IP可以独立于硬件平台、操作系统和编程语言。
来拆解一下SOME/IP：
Scalable: 可扩展的，即不拘泥于某一个系统，可以用在多个系统上
Service-oriented：是直接为应用软件所使用的
Middleware:中间件
Over IP:基于IP通信协议
所以说白了，SOME/IP是一套用TCP/IP协议帮助不同平台上的分布式应用软件互相传递信息的机制。SOME/IP将服务接口里的内容通过SOME/IP这一套规则打包，交给TCP/IP传输。服务可以是多个事件、字段和方法的组合。
SOME/IP协议内容按照AUTOSAR中的描述，我们可以更进一步的拆分为三类子协议：应用层的SOME/IP标准协议，SOME/IP-SD协议以及TP层的SOME/IP-TP协议，这三部分内容相辅相成，完整详细的阐述了SOME/IP协议的全部内容，是研究SOME/IP协议的必经之路。
在讲具体的协议之前，先介绍下事件、方法和字段的概念。
事件：
单向数据传输，仅在更改或循环时调用，从数据的提供者发送到订阅者。事件提供了从提供者到订阅者的循环发送或变化的数据。总的来说，事件是订阅者对提供者提出订阅后，提供者把订阅的数据通过循环发送或变化时发送这两种方式，发送给订阅者。
方法：
被调用的方法、函数或子例程。方法为订阅者提供了在提供者端执行远程过程调用的可能性。
订阅者如果想让提供者执行某个函数或方法，就可以SOME/IP中的方法实现。根据不同的消息类型，服务端可选择是否进行反馈。依据是否需要进行反馈，可以分为：
Request/response：客户端发出服务请求，服务端执行完毕后反馈调用结果的信息，对该服务进行响应。
Fire/forget：客户端发出请求后不期待来自服务器的回复响应。
字段：
（1）getter:订阅者可以调用getter来获取提供者的值/状态
（2）Setter:订阅者可以调用setter来更改提供者端的值/状态
（3）Notifier:订阅者可以调用notifier让提供者把变化的数据发送给订阅者。
下面来介绍SOME/IP的报文，SOME/IP 报文由消息头（Header）和数据段（Payload）组成，报文结构如下。
Message ID：
4个字节，用于识别应用程序的方法或事件。所以Message ID由Service ID(16 bit)和Method ID(15 bit)组成，前者表示应用，后者表示方法或事件。当Method ID表示方法时，bit16为0。
当Method ID表示事件时，bit16为1。
举例来说，当你想用SOME/IP来远程控制汽车娱乐音响系统里的音乐播放器播放下一首歌时，音乐播放器就是用Service ID表示，而切换到下一曲的动作就是Method ID。由此可以看出，Message ID对于整个系统来说是唯一的。
Length：
4个字节，它是从Request ID到Payload的字节长度。注意，不包括Message ID和Length本身。
Request ID：
4个字节，用来区分订阅者和提供者之间的同一个方法、事件、getter或setter的多个并行使用。当你前后两次远程控制音乐播放器切换到下一曲时，两次的Request ID是不同的，需要加以区分。准确来说，其实是Request ID里的Session ID来区分。Request ID由Client ID(2个字节)和Session ID(2个字节)组成。
Client ID是订阅者的的唯一标识，提供者用Client ID区分调用同一方法的多个订阅者。比如汽车方向盘控件可以控制娱乐音响系统的音乐播放器切换到下一曲，后排的控制面板也可以控制它，那么就可以用不同的Client ID区分它们。所以，每个Client ID在整个车辆中应该是唯一的。
Session ID用来区分同一发送者的连续请求或消息。提供者在生产响应消息时，应该把Request ID复制到响应消息中，这样订阅者收到后可以根据Request ID判断这是哪条请求的响应。
Protocol Version：
1个字节，用来表示SOME/IP的Header的格式，对于SOME/IP协议首部中的改动，Protocol Version应该增加，但是对于payload中格式的改变，Protocol Version不应该增加。
Interface Version:
1个字节，用来表示服务接口版本。
Message Type
1个字节，用于区分不同类型的消息，不同值的含义如下。其中TP为SOME/IP-TP(SOME/IP Transport Protocol)。SOME/IP在采用UDP传输超出UDP允许数据长度的数据时需要采用SOME/IP-TP
Return code:
用于表示请求是否被成功地执行。为了简化报头各式的排布，每个报文都包含返回码，具体定义规则如下。
Payload:
该字段包含所请求服务的相关参数。该字段的长度取决于所用的传输协议。如果采用了SOME/IP和UDP协议，有效载荷字段长度应不超过1400字节。若超出1400字节长度，可采用SOME/IP-TP或TCP传输协议。
这里简单说下TCP和UDP的区别。这两个协议都是用来在不同节点间传递数据的传输层协议。但是主要区别在于：是否需要建立连接。
为了保证长数据分包传输时的可靠性，防止漏掉一个或多个数据包，TCP协议需要与接收节点建立连接，并在传输的过程中对发送的每个数据包做接收确认。当某一个数据包对方未收到时，发送节点将重新发送，以保证整个数据的完整性。而UDP协议则不需要建立这样复杂的连接，只需要发送一个单包的数据，之后通过对方回复的响应作为接收确认就可以了。如果未收到对方回复的数据则再发送一遍就可以。因此，针对一些要求实效性且数据不完整不会引起严重问题时也会采用UDP协议。因此，通常针对需要建立连接，需要发送多包数据时采用TCP协议；而在不需要建立连接，只需要发送单包数据时采用UDP协议。
当前SOME/IP支持TCP和UDP协议。相对于UDP协议，TCP允许传输更大的数据，并且可以通过TCP的特性保证数据传输的可靠性。由于在一个IP包中通过UDP传输SOME/IP数据有数据长度限制，如果需要传输的数据长度超出UDP限制，需要应用SOME/IP-TP。SOME/IP-TP中，无法放置在一个UDP报文中的数据称为原始报文(original)，被分包后经SOME/IP-TP传输的数据部分被称为片段(segments)。SOME/IP-TP的报文格式与SOME/IP的格式有略微差别，详情请见下面链接，这里不展开。
https://blog.csdn.net/wto9109/article/details/123079284
5.3 SOME/IP SD协议
SOME/IP SD（Service Discovery）是用于服务发现的协议，顾名思义，具备发现服务的基本功能，这是从节点作为Client来考虑的，需要找到网络上对应的服务；对应地，网络中必然存在至少提供该服务的节点，该节点可被称Server。
在这种供需场景中我们看到了提供服务，订阅服务的过程，该过程如果用专业术语来讲可称为Subcribe/Publish模型，该模型涉及到Client与Server两方，交互过程如之前文章所描述如下图。
由上图可知，Subribe/Publish的过程主要经历以下四个阶段：
（1）对于需要服务的Client而言，通过FindService方式来发现当前网络中存在的服务；
（2）如果Server存在服务就会通过Offer Service方式来广播通知自身存在的服务；
（3）Client根据已发现的服务中通过Subcribe EventGroup的方式来订阅相关事件，同时在Server段发现Client的订阅满足条件则会回复正确的肯定响应；
（4）当Client订阅成功后，Server端便会按照服务的基本属性来事件型或者周期性提供Client端相关的服务
总而言之，SOME/IP-SD就是用于定位服务，检查服务可用性以及部署与发布服务句柄的一种应用层协议，该协议只能运行在UDP之上，服务发现报文格式与SOME/IP标准协议一致，且Message ID固定为0xFFFF8100，其中Service ID是0xFFFF，Method ID为0x8100。SOME/IP-SD的报文格式如下。
SOME/IP-SD报文也是SOME/IP报文的一种，只是在SOME/IP标准协议的基础上扩展了Entry，Option等字段，其中Entry用于同步服务实例的状态以及发布/订阅关系的管理，Options则用于传输Entry的附加信息。各个字段的具体涵义可以参考下面链接的内容，这里不展开。
https://blog.csdn.net/wto9109/article/details/123079284
5.4 DDS协议
DDS（Data Distribution Service）是另外一种常见的面向服务的通信中间件。DDS最早应用在美国海军系统，用于解决军舰系统复杂网络环境中大量软件升级的兼容性问题。在汽车领域，2018年Adaptive AUTOSAR引用了DDS，作为可选择的通信方式之一。目前国内已有主机厂开始研究，主要针对自动驾驶相关需求，工具方面，在汽车电子领域常用的工具厂商也在开发这部分内容。
DDS规范是由OMG（Object Management Group）对象管理组织发布的。OMG组织是一个国际性、开放性、非盈利性技术标准联盟，由供应商、终端用户、学术机构、政府机构推动，已经有31年的历史；OMG工作组针对各种技术和行业制定企业集成标准，并开发可为数千个垂直行业提供现实价值的技术标准。
在分布式系统中，DDS位于操作系统和应用程序之间，支持多种编程语言以及多种底层协议。这便是我们常说的跨平台。
先看下DDS的通信模式，如下图。
这里需要介绍几个概念。
Publisher：发布者，发布主题数据，至少与1个DataWriter关联，通过调用DataWriter的相关函数将数据发出去；
Subscriber：订阅者，订阅主题数据，至少与1个DataReader关联。
DataWriter：数据写入者，类似缓存，把需要发布的主题数据从应用层写入到DataWriter中；
DataReader：数据读取者，同样可以理解为一种缓存，从订阅者得到主题数据，随之传给应用层；
Topic：是数据的抽象概念，由TopicName标识，关联相应数据的数据类型(DataType)，如果把车内所涉及的所有Topic集合在一起，这样就形成一个虚拟的全局数据空间“Global Data Space”，进一步弱化了节点的概念，所以域参与者已经不是节点的概念了；
DDS是一个以数据为中心的中间件协议和API标准，意为用户只关心自己想要的数据，数据通过Topic进行标识，这样发布者根据主题发布数据，订阅者根据自己感兴趣的主题订阅数据。这便是DDS的核心，以数据为中心的发布-订阅模型DCPS（Data-Centric Publish-Subscribe）。
而SOME/IP是以服务为中心的，在SOME/IP中，我们需要做的是把数据打包成服务，之后服务的消费方向服务提供方通过SD订阅服务中的事件组，当数据发生变化后，相应的事件报文便会发到总线上。相比之下，DDS确实很直接，直接与数据沟通。
DDS的另一个特点是支持QoS，目前共支持22种QoS策略，每种策略都可以应用在不同的角色上，而针对同一角色，可单独使用一种QoS，也可以组合使用多种QoS策略。
QoS，即服务质量，其是指使用在网络上运行的机制或技术来控制流量，确保关键应用程序在有限的网络容量下的性能。简而言之，就是怎么保证数据更好的传输。上面的QoS策略，举个例子。
RELIABLITY（可靠性）
该策略下，可选的参数有RELIABLE和BEST_EFFORT。Kind = RELIABLE ，如果当网络发生错误， DataReader可能无法收到DataWriter的样本数据时，会对样本数据进行重发，保证DataReader能够收到数据；Kind = RELIABLE ，如果当网络发生错误， DataReader可能无法收到DataWriter的样本数据时，会对样本数据进行重发，保证DataReader能够收到数据。
其他QoS策略不展开，根据产品的需要可以自行配置相关的QoS策略。
5.5 SOME/IP和DDS的对比
SOME/IP和DDS是自动驾驶上用的最多的两类通信中间件，二者都是面向服务的通信协议，但二者也有一些区别。该部分内容摘自九章智驾公众号文章《DDS与SOME/IP谁主沉浮？》
（1）应用场景不同
SOME/IP是专为汽车领域而生的，它针对汽车领域的需求，定义了一套通信标准，并且，在汽车领域深耕的时间比较长；DDS是一个工业级别的强实时的通信标准，它对场景的适应性比较强，但在用于汽车/自动驾驶领域时需要做专门的裁剪。
（2）灵活性、可伸缩性不同
相较于SOME/IP，DDS引入了大量的标准内置特性，例如基于内容和时间的过滤、与传输无关的可靠性、持久性、存活性、延迟/截至时间监视、可扩展类型等。当AUTOSAR AP与DDS一起构建一个通信框架时，该框架不仅可以与现有ara::com api及应用程序兼容，而且在可靠性、性能、灵活性和可伸缩性等方面，都可以提供重要的好处。
（3）订阅方和发布方是否强耦合
在SOME/IP中，在正常数据传输前，client需要与server建立网络连接并询问server是否提供所需服务，在这个层面上，节点间仍然具有一定耦合性。服务的订阅方需要知道server在哪里，服务的发布方需要告知server提供哪种服务，例如写一个程序，需要用到传感器数据，这个程序要去询问server是否可以提供传感器数据；而在DDS标准下，每个订阅方或发布方只需要在自己的程序里面订阅或发布传感器数据就行了，不需要关心任何连接。可以理解为，在DDS中，服务订阅方和发布方的解耦更加彻底，需要什么数据，写一行代码就行了，不需要再去做绑定。
（4）DDS具有较好的QoS策略
SOME/IP只有一个QoS，即可靠性的定义；而RTI DDS和开源DDS里面分别有50多个和20多个QoS，这些QoS基本上能涵盖绝大多数可以预见到的智能驾驶场景。以一些具体例子来阐明QoS的作用。
a）通信中的传输优先级、数据可靠性、资源限制、时间过滤等，都需要在QoS里面设置。
b）数据传输过程中可能会出现丢帧现象，也就是说，不是每一帧都能达到接收端。针对这种现象，我们需要考虑场景需求。如果是关键信息（报警指令），我们需要发送方重发，如果是非关键信息（高频传感数据），系统就不必把丢失的部分都找回来，这些都只需配置QoS的reliability就可以了。
c）在感知系统有冗余的情况下，一旦一个传感器宕机，就需要第二个传感器补上来。针对这种情况，QoS可以配置一个ownership，对两个传感器的数据做优先级高低的区分。配置之后也不需要重新编译，因为它是动态部署的，配置完之后就可以按照最新配置运行，去完成不同节点之间的发布订阅。
d）DDS的解耦模式允许某一主题发布方在没有订阅方的情况下仍然发布数据，但后加入的订阅方也许对这一主题的历史记录感兴趣。例如，新节点上线后需要去监控其他节点的运行情况，这些节点也许每隔较长一段时间才发布一个信息说自己“运行正常”，那么这个新上线的节点就需要去了解其他节点发布的历史信息以确定其运行状态，也就是它希望能收到其上线之前其他节点发布的历史数据。这种情况，只需要简单配置QoS就可以实现，新节点可以获知上线之前多长时间、多长节点的数据流，去关注它的历史数据等等。
e）负责监控的新节点上线后，需要去监控其他节点的运行情况。通常，这些节点每个小时发布一个信息说自己“运行正常”，但也有可能这个“运行正常”的节点先发布了，过半小时之后监控节点才发布，那这时候，监控节点是否还能收到其上线之前其他节点发布的数据？这种情况，也是需要通过QoS去配置的，QoS可以去配置订阅新节点上线之前多长时间、多长节点的数据流，去关注它的历史数据等等。
总的来说，QoS能够提供实时系统所要求的性能、可预测性和资源可控性，并且能够保证发布/订阅模型的模块性、可量测性和鲁棒性等。因此，DDS能够满足非常复杂、非常灵活的数据流要求。
相比之下，SOME/IP只解决了发布订阅问题，但由于没有这些QoS，结果便是，很多本来可用自动配置服务策略来实现的功能，都需要通过软件开发人员写代码才能实现，这会浪费大量的时间。
此外，由于没有QoS，SOME/IP在数据量大的时候，无法解决丢包的问题，进而造成指令被卡在某个地方发不出去，然后，整个系统就无法正常运作了。
在《DDS与SOME/IP谁主沉浮？》这篇文章里，业内人员还提到了很多其他的观点，推荐阅读原文。
6 总结
EEA构建了骨架，SOA注入了灵魂。再这么成长几年，车厂就可以整更多的花活了。
编辑：黄飞
工商网监
评论