中间件Middlewares被宽泛地定义为位于应用程序和系统软件之间的一层软件，它对底层系统进行抽象，使开发者能够专注于特定应用任务。基于现代电子电气EE架构，新一代汽车中间件已成为汽车领域新软件架构的基础。

Automotive Software
Stack汽车软件栈

汽车软件栈是支持应用程序的软件层集合，由操作系统或管理程序为基础，加上软件框架和中间件组成，为应用程序提供功能。

上图展示了汽车软件栈的分层结构，自下而上依次为硬件层、资源分区（如 Hypervisor）、操作系统层（如RTOS、Linux）、通信中间件层（如SOME/IP）、架构平台层（如AUTOSAR AP）和应用层（App A、App B）。这种分层架构清晰展示了各软件层在支持应用程序运行过程中所处的位置和相互关系。

中间件处于应用程序和操作系统之间，并且分为两层。下层的通信中间件（如 SOME/IP）主要负责分布式系统中的通信功能，为上层应用提供基础的通信支持；上层的架构平台（如AUTOSAR AP）则基于通信中间件，提供诸如空中下载（OTA）更新、资源控制和安全等更丰富的功能。

上图左侧展示了汽车软件栈不同元素的术语定义，将汽车中间件相关元素分为通信中间件、架构平台和应用框架等。这种分类方式有助于清晰地界定和理解汽车软件系统中不同层次和功能的软件组件。

右侧展示了以AUTOSAR AP为例，应用逻辑（Application Logic）是其应用层面的体现；AUTOSAR运行时自适应应用（AUTOSAR Runtime for Adaptive Applications）属于架构平台部分，为应用提供运行环境和基础服务；工具（Tooling）则是辅助开发、部署和管理AUTOSAR AP系统的工具集合。

Automotive Middlewares
汽车中间件

中间件运行在分布式、异构的汽车电子电气（E/E）架构中，由于这种分布式系统架构的特性，通信和结构化软件执行成为它们的核心功能。由于处于这样的位置，中间件会与众多不同领域进行交互。

上图展示了汽车中间件在运行过程中与不同领域产生交互。这些领域涵盖了电子电气（E/E）架构、软件架构和操作系统多个方面。中间件作为连接应用程序和系统软件的关键层，其功能的实现依赖于与这些领域的协同工作。

Communication middlewares通信中间件是汽车软件架构的核心，有助于各个电子控制单元（ECU）之间进行数据交换。它们通过将应用程序与底层车内网络（IVN）拓扑结构分离来实现这一目标。这通常通过发现机制来实现，即通信路径不是预先确定的，而是在运行时动态发现的。或者，也可以使用网络拓扑的集中式定义将IVN与应用程序分离。这种概念上简单的软件设计模式，使得基于该中间件构建的应用程序能够独立于特定的ECU和IVN拓扑结构，因为网络中的所有其他应用程序都是动态发现的。

Software Design
Pattern软件设计模式

软件设计模式是针对常见设计问题的通用解决方案。巴斯（Bass）等人在2012年所著的《软件架构实践》中，将其定义为对元素（例如客户端和服务）以及这些元素之间的关系（如请求）的描述，并对其使用方式加以约束。它们通常只描述软件架构中的一个子集或重复出现的模式，经典的模式示例包括客户端-服务器模式、n-tier模式或面向服务模式。

通过采用这些软件设计模式，架构平台（architecture platforms）能够确定高级架构决策，例如软件系统的组件构成和通信方式。因此，架构平台是汽车软件系统不可或缺的一部分。

上图展示了常见中间件，区分了闭源和开源中间件，体现了对架构平台和通信中间件的分类。

中间件的分类方式：该图从两个维度对中间件进行分类，一是根据中间件的功能，分为架构平台（Architecture Platforms）和通信中间件（Communication Middlewares）；二是依据访问权限，区分了闭源（closed source）和开源（open source）中间件。

在架构平台类别中，包含了AUTOSAR AP、ROS 2等。其中，AUTOSAR AP是汽车行业为实现从信号导向架构向基于中间件的架构转变而提出的标准，由大型联盟开发，具有商业性质；ROS 2则是机器人领域占主导地位的开源架构平台，在汽车领域也有应用潜力。

在通信中间件类别里，有FastDDS、SOME/IP、Zenoh等。FastDDS是对象管理组织（OMG）定义的 DDS 标准的开源实现；SOME/IP是AUTOSAR项目的汽车通信中间件标准；Zenoh是新兴的通信中间件，旨在提升性能并应对多种挑战。

Communication
Pattern通信模式

通信模式从软件模式定义衍生而来，指消息的结构、顺序以及接收者的确定方式，简单的通信模式有助于开发者专注于应用核心功能。现代中间件常见的通信模式是发布-订阅和请求-响应，发布-订阅通信通过主题组织消息，新参与者易加入网络；请求-响应通信用于调用远程方法。通信中间件还考虑IVN的可靠性和安全性，通过可配置QoS保证消息传输可靠性，部分支持消息加密或提供安全扩展。其实现基于主机操作系统的IP网络栈，常用TCP、UDP和共享内存协议，会根据IVN和E/E架构自动选择传输方式。

上图展示了发布-订阅（Publish-Subscribe）通信模式在DDS（Data Distribution Service）域中的具体工作方式。

在DDS域中，发布-订阅通信模式通过主题（topics）来组织数据交换。如图所示，发布者Publisher可以在某个主题上发布消息，而其他想要接收该消息的订阅者Subscriber则可以订阅这个主题。消息并不直接与特定的接收者相关联，而是与主题绑定。当Publisher在主题上发布新消息时，所有订阅了该主题的Subscriber都会收到通知，从而实现数据的分发。这种机制使得新参与者能够轻松加入现有网络，只要其与已有的主题进行交互，就可以参与到数据通信中。

Publisher无需关心消息会被哪些具体的Subscriber接收，Subscriber也无需知道消息的具体来源，双方仅通过主题进行交互。这不仅简化了通信过程，还提高了系统的灵活性和可扩展性，使得系统中的组件可以更加独立地进行开发和维护。

Communication
Middlewares
通信中间件

SOME/IP

可扩展面向服务的IP中间件（Scalable service-Oriented MiddlewarE over IP）解决传统汽车通信协议（如CAN、LIN、MOST和FlexRay）的局限性，实现异构设备间可扩展、面向服务的通信，满足汽车复杂功能对数据交互的需求，确保与AUTOSAR设备兼容，并提供汽车用例所需的功能。

上图展示了SOME/IP中远程过程调用（Remote Procedure Call）的两种方法。

有返回值的调用（With Return）：电子控制单元ECU A向ECU B发送请求（Request，橙色箭头），请求调用ECU B上的某个函数或方法。ECU B执行该函数或方法后，向ECU A返回响应（Response，蓝色箭头 ），响应中包含函数执行的结果或状态信息，这就是有返回值的远程过程调用。

辅助驾驶系统（举例）：前方车辆速度、距离等信息由雷达、摄像头等传感器所在的ECU（服务器）获取和处理信息。驾驶辅助系统ECU（客户端）向传感器ECU发送请求，获取前方车辆数据。传感器ECU处理数据后，将前方车辆距离、速度等结果返回给驾驶辅助系统ECU，后者据此调整本车速度，保持安全车距。

无返回值的调用（Without Return）：ECU A向ECU B发送请求（Request，橙色箭头），请求调用ECU B上的函数或方法，但ECU B不需要向ECU A返回任何结果或状态信息。

车辆灯光控制（举例）：当驾驶员通过车内灯光控制按钮（对应车身控制模块ECU作为客户端）开启车辆的日间行车灯时，车身控制模块ECU向负责灯光控制的ECU（服务器）发送开启日间行车灯的请求。灯光控制ECU接收到请求后执行开启操作，无需向车身控制模块ECU返回操作结果，因为开启动作完成即达到目的。

上图左侧展示了Getter/Setter方法，客户端主动对服务器字段进行读写。Getter获取字段值，Setter修改值，服务器返回响应，体现客户端对数据的直接操作。比如：仪表盘ECU向娱乐系统ECU发Getter请求获取播放状态，或用 Setter 请求调节音量等。

上图右侧展示了Field Notification，客户端先订阅事件组，关注字段变化。服务器在字段值变化时，主动通知已订阅的客户端。比如：胎压传感器ECU在胎压异常时，向信息显示系统ECU发送通知。

上图左侧展示了客户端订阅事件组，关注特定事件。服务器在事件发生时，向客户端发送通知，强调事件触发及基于订阅的告知。比如：碰撞传感器ECU 在碰撞触发时，通知安全系统及信息记录ECU；防盗系统ECU检测到被盗事件，通知车主手机APP关联服务器。

FastDDS

FastDDS（前身FastRTPS）是基于DDS标准的开源通信中间件，采用以数据为中心的发布-订阅模式。它主要用于实现不同电子控制单元（ECU）、传感器与车载系统间高效可靠的数据交互，辅助驾驶系统中传感器数据快速传输与处理、车联网环境下车与车（V2V）、车与基础设施（V2I）间的信息共享。

上图展示了在RTPS域的数据交互流程。

数据发布：参与者（RTPSParticipant）里的写入器（RTPSWriter）负责发送数据。以汽车辅助驾驶为例，摄像头传感器作为参与者，其写入器将障碍物检测数据发布到主题（Topic）1 ，车道线识别数据发布到Topic 2，如同给数据贴上标签准备发出。

数据订阅与接收：读取器（RTPSReader）接收数据。辅助驾驶决策系统的读取器订阅Topic 1，当摄像头传感器的写入器发布新的障碍物检测数据时，它就像接收货物一样接收数据，用于规划行驶路径。

跨参与者与主题交互：在车联网中，一辆车作为参与者，通过写入器将行驶状态信息发布到Topic 3。其他车辆的读取器订阅Topic 3借此分享行程，实现协同驾驶。

域参与者作用：汽车信息娱乐系统作为域参与者，其写入器将音乐、导航等数据发布到Topic 4。仪表盘显示系统若感兴趣，其读取器订阅Topic 4并展示信息。各实体的属性（Attributes）决定其在交互中的表现。

Zenoh

Zenoh以（key，value）形式结构化数据，核心组件包括发布者（Publisher）、订阅者（Subscriber）和可查询组件，由put（创建资源）、delete（销毁资源）、get（查询资源）等原语构建，可用于数据链路、网络、传输层，支持安全通信。

上图展示了Zenoh中数据以资源「key（特定功能），value（功能的具体数据/状态）」形式结构化，通过key进行访问。

图中展示了发布者（Publisher）和订阅者（Subscriber）基于key和selector进行通信。发布者Pub为不同的key（如/key2/a）创建资源，订阅者可以通过订阅特定key或包含通配符的selector（如/key2/*）来接收匹配的资源。这体现了Zenoh通信模式的灵活性，新参与者能轻松加入网络，通过与已有主题交互实现数据共享。

比如：在座舱系统里，车辆信息娱乐系统可以作为发布者，将key音乐播放状态（如“音乐播放状态/歌曲名称”“音乐播放状态/播放进度”）、导航信息（如“导航信息/目的地”“导航信息/剩余里程”）等数据发布出去。车内的仪表盘和抬头显示系统作为订阅者，通过订阅相应的key或者selector，获取并展示这些信息。例如，仪表盘订阅“车辆行驶数据/*”，就能实时显示车速、转速等数据，方便驾驶员查看。

Architecture
Platforms
架构平台

ROS 2

ROS 2基于DDS通信中间件，支持发布/订阅模型和服务调用机制，保障不同组件间实时数据交换。发布/订阅模型适用于实时性要求高的数据传输，如传感器数据；服务调用则用于需要即时响应的任务，确保汽车系统各部分能及时交互信息。拥有改进的实时性能，可高效处理辅助驾驶中的及时数据，比如传感器数据，满足辅助驾驶对数据处理时效性的要求 。

上图展示了ROS 2生命周期状态机的状态。

包括未配置（Unconfigured）、非活动（Inactive）、活动（Active）、清理（Cleaning Up）、停用（Deactivating）、处理错误（Processing Error）、已完成（Finalized）和关闭（Shutting Down）等。状态之间的转换体现了节点在系统运行过程中的行为变化。例如从“未配置”到“非活动”，再到“活动”状态的转变，代表着节点从初始未配置状态，经过配置进入准备工作的非活动状态，最终进入可执行任务的活动状态。

应用到汽车功能中，比如在自适应巡航控制功能开启时，相关节点（如传感器节点、控制算法节点等）进入活动状态。传感器节点持续收集前方车辆距离、速度等数据，并通过发布-订阅模式将数据传递给控制算法节点。当遇到前方车辆减速等情况，控制算法节点依据接收到的数据进行计算，随后向车辆动力系统和制动系统的节点发送指令，调整车速。若系统检测到故障（如传感器故障），则会切换到处理错误状态，同时向驾驶员发出警报，并可能将车辆切换到安全状态（如减速至停止）。

AUTOSAR AP

AUTOSAR AP作为智能中枢，集成多样功能，为自适应应用程序提供运行环境，实现软件组件间的通信、执行管理、状态管理以及安全和更新等功能，帮助汽车软件从面向信号架构向基于中间件的架构转变。AUTOSAR AP基于SOME/IP通信中间件，实现机器间和机器内的通信。它支持与SOME/IP相同的通信模式，包括字段、方法、事件以及静态或动态应用发现。

上图展示了AUTOSAR AP内部组件构成与协作关系。

组件包含通信管理、执行管理、诊断、入侵检测系统（IDS）管理、网络、持久性、同步等等，这些组件共同协作。通信管理功能簇基于SOME/IP实现服务间通信，保障数据交互；执行管理功能簇控制应用程序执行，实现确定性执行；状态管理功能簇确保系统正确启动和运行，管理资源和应用程序执行权限；更新/配置管理功能簇支持软件更新和配置管理，实现OTA更新等操作。

通过众多功能组件建起一个完整的体系，以应对汽车软件系统在通信、计算、安全、更新等多方面的需求，为汽车软件系统提供统一、规范且全面的支持。

—end—