硬件工程师将底层的硬件地基夯实好，软件工程师便在其上一层层垒砖头。一个简单的软件建筑没有什么规则，讲究一个快速实现功能就好。但如果要建一个软件摩天大楼，规矩就多了，比如如何使得系统更容易测试，更容易迭代等等。软件架构的设计可以遵循不同的风格（或者说是规矩），这些风格本质上是定义了用于描述系统的术语表和一组指导构建系统的规则。在初识“汽车软件”这座建筑之前，可以先看看软件架构有哪些风格。
1.1分层架构
1.2基于组件的架构
基于组件的架构，比分层架构更加灵活，所有组件都可以进行消息交互或者相互独立。所有的通信都应该经过规范定义的公共接口进行，并且每个组件都具备单一的接口，以便通过接口实现对组件的查询。Windows系统就是典型的基于组件的架构，其大量使用了动态链接库和IUnKnown接口。
需要说明的是，基于组件的架构并不是完全替代分层架构，架构可以分为多个层次。在大的维度上，软件架构可以使用分层架构。比如系统可以分为平台层和应用层，这是分层架构的概念。但是在应用层内，多个应用之间可以采用基于组件的架构，多个APP可以互相调用。
1.3单体架构
与基于组件的架构相反，其假定整个系统是一个大型组件，系统中的所有模块都可以相互使用。这种风格通常用于低成熟度的系统，因为它会导致系统的高耦合和高复杂度。当有人质疑你的代码没有分层，没有架构设计，你就可以试着申辩说这是专门设计的单体架构（说点专业的，唬唬人）。
1.4微内核架构
内核包含系统运行的最小功能，是具有更高执行权限的有限组件的集合，如任务调度程序、内存管理和基础进程间通管理，这些组件相较于应用层的组件而言拥有更高级别的权限。应用程序则是相互独立的，它们之间的通信应该减至最少，避免出现互相依赖的问题。例如，用户应用程序进程、设备驱动程序或文件服务的组件，这些组件可以具备不同的权限级别，但是其权限级别要始终低于内核进程。
在汽车行业中，微内核架构被用于某些要求高安全性的组件。微内核架构具有以下优点：具有良好的功能延申性；功能之间相互隔离，应用程序可以独立加载和卸载，容易部署；可定制性高，能适应不同的开发需要；可以渐进式开发，逐步增加功能。
微内核架构的缺点主要有：扩展性差，内核通常是一个独立单元，不容易做成分布式；因为涉及应用程序与内核的通信，以及内部的应用程序登记机制，开发难度较大。
1.5管道与过滤器架构
管道域过滤器架构由两大组件构成，一个为过滤器，另一个为管道。过滤器的主要功能为从输入接口读取数据，然后经过特定的处理，将结果数据置于输出接口。管道式连接各个过滤器的组件，负责过滤器间数据的传输，充当过滤器之间数据流的通道。
管道与过滤器架构具有以下优点：符合高内聚、低耦合的设计原则，可以方便地对过滤器进行替换或删除等操作；支持模块的重用，可以将单个独立的过滤器应用到其他软件系统中；支持并行执行，每个过滤器是一个独立的实体，可以单独运行，不受其他过滤器影响。
管道与过滤器架构的缺点主要有：不适合处理交互的应用；传输的数据没有标准化，所以读入数据和输出数据存在格式转换等问题，会导致性能降低。
1.6客户端-服务器架构
客户端-服务器模式(Client–servermodel)简称C/S结构，是一种网络架构，它把客户端(Client)与服务器(Server)区分开来。每一个客户端软件的实例都可以向一个服务器或应用程序服务器发出请求。
这种系统的设计原则指定了具有特定角色的组件之间的解耦，即服务器根据客户端的请求提供资源。
客户端-服务器架构的缺点是：服务器是系统的核心部分，一旦服务器出现故障，整个系统就会瘫痪；网络带宽和延迟等因素会影响客户端和服务器之间的通信效率；由于客户端和服务器需要分别进行维护，因此维护成本较高。
后文提到的SOME/IP用的就是客户端-服务器的架构思想。
1.7发布者-订阅者架构
订阅者向中央存储订阅信息，以便获得有关信息的通知。发布者不知道订阅者，其任务仅仅是更新信息，这与客户-服务器架构有明显的差异，后者由服务器将信息直接发送到已知的客户端。
后文中提到的DDS用的就是发布者-订阅者的架构思想。
1.8中间件架构
中间件架构假定存在一个公共请求代理，其协调不同组件的资源使用需求。中间件的概念是随着对象管理组织推出的公用对象请求代理体系结构被引入软件工程当中的。AUTOSAR标准的设计中使用了中间件架构，中间件在汽车软件的适应机制和容错机制中正变得越来越重要。中间件是目前汽车软件架构的重要组成部分，后面会讲。
1.9面向服务的架构
1.10总结
各种架构风格并不是互斥的，一种特定的架构可能是由多种架构风格组成的，通过将多种基本风格组合为单个的协作风格来形成一种混合风格。在大的维度的上，是以分层架构来设计的，但在每一层软件实现上，可能会使用其他的架构风格。后文会对SOA进行展开，就可以看到，SOA里面有多种架构风格的体现。
2车载智能计算基础平台参考架构
白皮书中对车载智能计算基础平台的定义是，支撑智能网联汽车驾驶自动化功能实现的软硬件一体化平台，包括芯片、模组、接口等硬件以及系统软件、功能软件等软件。
该基础平台架构包含异构分布硬件架构、车控操作系统、安全体系、工具链。
系统软件纵向分为跨内核驱动框架层、内核及虚拟化管理层、系统接口层、系统中间件层。系统软件通过标准的系统接口、系统中间件向上层提供服务，实现与功能软件的解耦；通过跨内核驱动框架（包括AI驱动、BSP等各类驱动）、硬件抽象层，实现与硬件平台的解耦。
功能软件是根据各类智能驾驶功能的核心共性需求，定义和实现共性的功能组件，并通过标准的应用软件接口及服务，向上层应用软件提供服务，实现与应用软件的解耦。
安全体系保障车载智能计算基础平台的质量安全和使用安全，包括功能安全、预期功能安全、网络安全、数据安全、OTA安全、融合安全等。
我们重点看车载操作系统，这是软件的部分。这部分可以简化如下图所示。
2.1驱动
驱动负责管理底层的硬件资源，驱动程序本质上是软件代码，主要作用是计算机系统与硬件设备之间完成数据传送的功能，只有借助驱动程序，两者才能通信并完成特定的功能。这部分软件工作和底层软件耦合比较多。
2.2虚拟化
2.3OS
OS是狭义的操作系统，根据不同的应用，需要使用到不同的OS，后面会简单介绍下。
2.4系统接口
POSIX，PortableOperatingSystemInterface，即可移植操作系统接口。它是一个IEEE1003.1标准，定义了应用程序和UNIX操作系统之间的操作语言。当应用程序在两个支持POSIX标准的操作系统中迁移时，可以保证其兼容性。这样应用程序就与操作系统解耦了，提高了可移植性。你看，一切为了解耦。
2.5中间件
系统中间件向下获取操作系统内核的系统接口服务的支持，向上支撑功能软件层提供系统中间件的服务和接口。系统中间件大致包含如下部分。
SOA框架通常包含模块化服务、服务注册发现、标准互操作性接口、服务编排等内容和特征。SOA是目前车载软件里一个很重要的趋势，后面也会讲。
AI框架用于支撑自动驾驶AI应用和大模型应用的开发。
管理中间件中包括数据加密、身份验证、健康管理、网络与系统安全监测等安全措施及服务，对功能软件中的安全框架和安全服务等提供支撑，提升整体车控系统的稳定性和安全性。
2.6功能软件
功能软件是根据智能驾驶共性来定义和实现的通用模块，是支撑智能驾驶应用生态建设的重要层级。说简单点，就是将零碎的资源整合成若干通用模块，便于应用程序调用。
3OS
汽标委智能网联分标委于2021年发布了《车控操作系统架构研究报告》，该白皮书将车用操作系统分为如下几个部分。
车控操作系统分为安全车控操作系统和智能驾驶操作系统，其中，安全车控操作系统主要面向经典车辆控制领域，如动力系统、底盘系统和车身系统等，该类操作系统对实时性和安全性要求极高，生态发展已趋于成熟。智能驾驶操作系统主要面向智能驾驶领域，应用于智能驾驶域控制器，该类操作系统对安全性和可靠性要求较高，同时对性能和运算能力的要求也较高。该类操作系统目前在全世界范围内都处于研究发展的初期，生态尚未完备。
车载操作系统主要面向信息娱乐和智能座舱，主要应用于车机中控系统，对于安全性和可靠性的要求处于中等水平，该类操作系统发展迅速，依托于该类操作系统的生态也处于迅速发展时期。
3.1安全车控操作系统OS
3.2智能驾驶操作系统OS
智能驾驶操作系统将会成为自动驾驶汽车发展的核心竞争力之一。智能驾驶操作系统发展趋势和特点是纵向分层，以实现层与层之间的解耦，方便快速开发和移植，如下图所示。
AUTOSAR组织为应对自动驾驶技术的发展推出了AdaptiveAUTOSAR（AP）架构，如下图所示，其主要特点是采用面向服务的架构（SOA），服务可根据应用需求动态加载，可通过配置文件动态加载配置，并可进行单独更新，相对于ClassicAUTOSAR（CP），可以满足更强大的算力需求，更安全，兼容性好，可进行敏捷开发。
AdaptiveAUTOSAR系统主要适应于新的集中式的高性能计算平台，满足车内部件之间的高速通信需求和智能驾驶的高计算能力需求。AP平台采用了服务化的架构，系统由一系列的服务组成，应用和其他软件模块可以根据需求调用其中的一个或者多个服务，而服务可以是平台提供的，也可以是远程其他部件提供。
AP平台没有设计新的操作系统内核，所有符合POSIXPSE51接口的操作系统内核都可以使用。
4面向服务的架构
介绍完了操作系统内核，再往上，理论上就要讲中间件。但中间件是为了上下层服务的，所以在这之前，要先介绍SOA。
4.1SOA是什么
这个概念其实并不新鲜，早在20多年前，WebService出现的时候，SOA就已被誉为是下一代Web服务的基础框架。但是用在汽车上确是近年来随着软件定义汽车的发展，SOA在汽车上才开始得到应用。也就是说SOA在其他领域已经被用上了，汽车只是将SOA的概念拿来用。
汽车SOA是对整车智能化的底层能力进行组织。将车端的硬件能力和各种功能SOA化，划分为不同的服务，拆分成颗粒度更小的接口。这些服务根据SOA标准进行接口设计，基于SOA标准协议进行通信。说明白点，就是将各种ECU的能力以“菜单”形式呈现出来，中央控制器根据ECU展现出来的能力，去要求ECU执行特定的操作。例如，车舱内有很多灯，灯的颜色、闪烁频率、亮度等可选。所有灯可以作为一个整体，通过特定的协议（比如SOME/IP或DDS）向中央控制器表明自己可以提供如上服务。
SOA软件架构的特性就是高内聚、松耦合、服务平台无关化、服务动态部署/动态发现。因而为汽车出厂后的持续升级和服务降低难度、拓展出更多的可能性。
4.2SOA的目的
看了上面说的，来思考一下，为什么汽车上要用SOA？一切的目的都是为了实现“软件定义汽车”。
4.3SOA实现的基础
为了实现软件定义汽车的目的，就要解开软件的手脚，让其自由来去，大展拳脚。因此，需要先做下面几件事。
（1）EEA功能架构升级
EEA架构向着中央集中式架构演进，就是要把控制权回收，集中在自己的手里，大部分的ECU就变成单纯的执行器。这就使得软件从多个ECU抽取出来，汇集到区域控制器和中央控制器中，软件被独立出来，就有了操作自由度。
每个控制器上带着各种ECU，这是控制器的负载，这些ECU的功能后期可能会被标准化。区域控制器根据所有ECU的硬件功能以及自身软件功能的设计，将自身的能力抽象出若干服务，并通过标准协议，对外提供“菜单”。这样，不同组件可以调用互相的服务，形成不同的应用。最重要的是，可以快速迭代。几个ECU换了供应商，没关系，只需要更新下自身的“菜单”即可。
SOA要抽象出服务，虽然分布式架构也可以抽象，但不如集中式架构来得效率高。因此，可以说EEA功能架构的演进使得软件系统架构有了更高的服务抽象的能力。
（2）服务发现
所谓服务发现，就是说当ECU的各项能力被抽象出来后，可以被其他组件发现并调用。这就使得SOA有了动态配置的能力，提高了系统的可维护性和可配置性。当一个服务失效时，可以很快的用另一个相同功能的服务替换掉它，新服务的访问点信息会很快在系统中被其它服务获取，系统可以很快能从服务失效引起的错误中恢复，提高了系统的可靠性。当某个服务需要被升级时，也可以采用类似的方式进行，对系统的可进化性也有显著帮助。
在SOA中，以上工作依靠一些通信协议来实现，比如SOME/IP、DDS等。这些通信协议里，包含了服务的一些具体信息。SOME/IP和DDS其实是一种消息中间件。是的，SOA中用到了中间件的架构风格，其中最出名的中间件就是AUTOSAR。
（3）EEA网络架构升级
在分布式电子电气架构阶段，车上主要使用CAN或CANFD作为主干总线。CAN(FD)总线速度低、无效载荷开销大（甚至>50%）、有效数据长度太小（CAN8字节，CANFD64字节）。伴随着智能驾驶、智能座舱等功能的引入，整车数据吞吐量急剧增加，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可分为ClassicPlatform和AdaptivePlatform两个平台，两者分别被简称为AUTOSARCP与AUTOSARAP。
简单地说，AUTOSARCP主要跑在8bit、16bit、32bit的MCU上，对应传统的车身控制、底盘控制、动力系统等功能，如果涉及到自动驾驶的话，AUTOSARCP可能无法实现；而AUTOSARAP主要跑在64bit以上的高性能MPU/SOC上，对应自动驾驶的高性能电子系统。
严格地说，AUTOSARCP并不只是个“中间件”，它是相当于“OS内核+中间件”的一套完整的“操作系统”。AUTOSARCP定义了基本的上层任务调度、优先级调度等。在基于分布式架构的ADAS功能中，AUOTSARCP便是最常见的“操作系统”。在AUTOSAR的生态形成后，很多芯片厂商的MCU上标配的就是AUTOSARCP，主机厂没有什么选择权。由于分布式架构下的芯片主要是MCU，因此，便有了“AUTOSARCP主要跑在MCU上”的说法。
随着EE架构从分布式向集中式演进、芯片由MCU向SOC演进，计算量及通信量成数量级地上升，另外，多核处理器、GPU、FPGA以及专用加速器的需求，还有OTA等，都超出了AUTOSARCP的支持范围。
从计算能力方面来讲，近些年来汽车变得越来越智能，随之汽车对处理器的性能也提出了更高的要求，诸如自动泊车、环境感知、路径规划等高级功能对处理器的告诉案例需求远远高于对多核的需求。虽然CP已经应用于传统的多核处理技术，但依旧无法满足车辆对ECU处理能力的需求。此外，从处理器核半导体的技术角度看，提高性能的唯一方法是多核并行运行，并行运行以及所谓的异构计算也大大超出了CP能覆盖的范围。
2017年，为更好地满足集中式架构+SOC时代的高等级自动驾驶对中间件的需求，AUTOSAR联盟推出了通信能力更强、软件可配置性更灵活、安全机制要求更高的AUTOSARAP平台。
需要强调的是，不同于AUTOSARCP自身已经包含了基于OSEK标准的OS，AUTOSARAP只是一个跑在Lunix、QNX等基于POSIX标准的OS上面的中间件——它自身并不包含OS。
AP和CP的主要区别如下。
总的来说，AUTOSARCP一般应用在对实时性和功能安全要求较高、对算力要求较低的场景中，如引擎控制、制动等传统ECU；而AUTOSAR则应用在对实时性和功能安全有一定要求，但对算力要求更高的场景中，如ADAS、自动驾驶，以及在动态部署方面追求较高自由度的信息娱乐场景。
AP修改了大量的CP标准的内容，以SOA的思想进行开发，主要目的是满足当前汽车自动驾驶、电气化和互联互通等趋势的需求。下图是AP的软件分层架构。
5.1通信中间件介绍
SOA软件设计原则之一是模块化，模块化可以提高可维护性、代码重用性并隔离故障。以自动驾驶为例，系统可以分解成特定的任务模块，如数据收集、状态估计、任务规划等。为了完成任务，模块必须与其他模块交换信息。在现代操作系统中，将单个模块映射到软件进程非常方便，这些进程可以位于相同的计算设备上，也可以位于物理上独立的计算设备上。这就把信息交换的任务转化为了进程间通信的问题，也就引出了对通信中间件的需求。
以数据为中心，是相对于传统的以消息为中心而言的，其与后者的本质区别在于通信中间件知道它存储了什么数据，并能控制如何共享这些数据。对传统的以消息为中心的中间件，程序员必须为发送消息编写代码；而对以数据为中心的中间件，程序员只需要为如何及何时共享数据编写代码，然后就可以直接共享数据。
根据源代码是否开放，通信中间件可简单地分为闭源和开源两种。闭源的通信中间件主要有Vector公司的SOME/IP、RTI公司的DDS等;开源的通信中间件主要有OPENDDS、FASTDDS、CycloneDDS等。上面其实已经有提到了SOME/IP和DDS了。
5.2SOME/IP协议
SOME/IP的全称为：Scalableservice-OrientedMiddlewarEoverIP，是一种面向服务的传输协议。严格地说，SOME/IP不是一款特定的产品，而是一种技术标准。其最早由宝马在2012-2013年开发，并在2014年集成进AUTOSAR4.2.1中。
当前，全球最大的商用SOME/IP产品供应商是Vector。开源版的SOME/IP则是由Genivi协会来维护的。
SOME/IP是一种应用层协议，运行在TCP/IP传输协议之上，作为以太网通信中间件来实现应用层和IP层的数据交互，使其不依赖操作系统，同时能兼容AUTOSAR和非AUTOSAR平台。因此，SOME/IP可以独立于硬件平台、操作系统和编程语言。
Scalable:可扩展的，即不拘泥于某一个系统，可以用在多个系统上
Service-oriented：是直接为应用软件所使用的
Middleware:中间件
OverIP:基于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）组成，报文结构如下。
MessageID：
4个字节，用于识别应用程序的方法或事件。所以MessageID由ServiceID(16bit)和MethodID(15bit)组成，前者表示应用，后者表示方法或事件。当MethodID表示方法时，bit16为0。
当MethodID表示事件时，bit16为1。
举例来说，当你想用SOME/IP来远程控制汽车娱乐音响系统里的音乐播放器播放下一首歌时，音乐播放器就是用ServiceID表示，而切换到下一曲的动作就是MethodID。由此可以看出，MessageID对于整个系统来说是唯一的。
Length：
4个字节，它是从RequestID到Payload的字节长度。注意，不包括MessageID和Length本身。
RequestID：
4个字节，用来区分订阅者和提供者之间的同一个方法、事件、getter或setter的多个并行使用。当你前后两次远程控制音乐播放器切换到下一曲时，两次的RequestID是不同的，需要加以区分。准确来说，其实是RequestID里的SessionID来区分。RequestID由ClientID(2个字节)和SessionID(2个字节)组成。
ClientID是订阅者的的唯一标识，提供者用ClientID区分调用同一方法的多个订阅者。比如汽车方向盘控件可以控制娱乐音响系统的音乐播放器切换到下一曲，后排的控制面板也可以控制它，那么就可以用不同的ClientID区分它们。所以，每个ClientID在整个车辆中应该是唯一的。
SessionID用来区分同一发送者的连续请求或消息。提供者在生产响应消息时，应该把RequestID复制到响应消息中，这样订阅者收到后可以根据RequestID判断这是哪条请求的响应。
ProtocolVersion：
1个字节，用来表示SOME/IP的Header的格式，对于SOME/IP协议首部中的改动，ProtocolVersion应该增加，但是对于payload中格式的改变，ProtocolVersion不应该增加。
InterfaceVersion:
1个字节，用来表示服务接口版本。
MessageType
1个字节，用于区分不同类型的消息，不同值的含义如下。其中TP为SOME/IP-TP(SOME/IPTransportProtocol)。SOME/IP在采用UDP传输超出UDP允许数据长度的数据时需要采用SOME/IP-TP
Returncode:
用于表示请求是否被成功地执行。为了简化报头各式的排布，每个报文都包含返回码，具体定义规则如下。
Payload:
这里简单说下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的格式有略微差别，详情请见下面链接，这里不展开。
5.3SOME/IPSD协议
SOME/IPSD（ServiceDiscovery）是用于服务发现的协议，顾名思义，具备发现服务的基本功能，这是从节点作为Client来考虑的，需要找到网络上对应的服务；对应地，网络中必然存在至少提供该服务的节点，该节点可被称Server。
由上图可知，Subribe/Publish的过程主要经历以下四个阶段：
（1）对于需要服务的Client而言，通过FindService方式来发现当前网络中存在的服务；
（2）如果Server存在服务就会通过OfferService方式来广播通知自身存在的服务；
总而言之，SOME/IP-SD就是用于定位服务，检查服务可用性以及部署与发布服务句柄的一种应用层协议，该协议只能运行在UDP之上，服务发现报文格式与SOME/IP标准协议一致，且MessageID固定为0xFFFF8100，其中ServiceID是0xFFFF，MethodID为0x8100。SOME/IP-SD的报文格式如下。
SOME/IP-SD报文也是SOME/IP报文的一种，只是在SOME/IP标准协议的基础上扩展了Entry，Option等字段，其中Entry用于同步服务实例的状态以及发布/订阅关系的管理，Options则用于传输Entry的附加信息。各个字段的具体涵义可以参考下面链接的内容，这里不展开。
5.4DDS协议
DDS规范是由OMG（ObjectManagementGroup）对象管理组织发布的。OMG组织是一个国际性、开放性、非盈利性技术标准联盟，由供应商、终端用户、学术机构、政府机构推动，已经有31年的历史；OMG工作组针对各种技术和行业制定企业集成标准，并开发可为数千个垂直行业提供现实价值的技术标准。
在分布式系统中，DDS位于操作系统和应用程序之间，支持多种编程语言以及多种底层协议。这便是我们常说的跨平台。
先看下DDS的通信模式，如下图。
这里需要介绍几个概念。
Subscriber：订阅者，订阅主题数据，至少与1个DataReader关联。
DataWriter：数据写入者，类似缓存，把需要发布的主题数据从应用层写入到DataWriter中；
DataReader：数据读取者，同样可以理解为一种缓存，从订阅者得到主题数据，随之传给应用层；
Topic：是数据的抽象概念，由TopicName标识，关联相应数据的数据类型(DataType)，如果把车内所涉及的所有Topic集合在一起，这样就形成一个虚拟的全局数据空间“GlobalDataSpace”，进一步弱化了节点的概念，所以域参与者已经不是节点的概念了；
而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能够收到数据。
5.5SOME/IP和DDS的对比
（1）应用场景不同
（2）灵活性、可伸缩性不同
（3）订阅方和发布方是否强耦合
（4）DDS具有较好的QoS策略
SOME/IP只有一个QoS，即可靠性的定义；而RTIDDS和开源DDS里面分别有50多个和20多个QoS，这些QoS基本上能涵盖绝大多数可以预见到的智能驾驶场景。以一些具体例子来阐明QoS的作用。
b）数据传输过程中可能会出现丢帧现象，也就是说，不是每一帧都能达到接收端。针对这种现象，我们需要考虑场景需求。如果是关键信息（报警指令），我们需要发送方重发，如果是非关键信息（高频传感数据），系统就不必把丢失的部分都找回来，这些都只需配置QoS的reliability就可以了。
此外，由于没有QoS，SOME/IP在数据量大的时候，无法解决丢包的问题，进而造成指令被卡在某个地方发不出去，然后，整个系统就无法正常运作了。
6总结
EEA构建了骨架，SOA注入了灵魂。再这么成长几年，车厂就可以整更多的花活了。