在当今汽车产业的变革中，中间件已不再是幕后默默运作的“配角”，而是推动智能汽车功能落地的“核心引擎”之一。它的作用不仅是将底层硬件与上层应用软件无缝连接，更在复杂的智能座舱体验和自动驾驶技术中起到承上启下的关键作用。

今天，我们接着上篇文章，深入来探讨下中间件如何打通智能汽车“任督二脉”:

• 到底什么是汽车软件中间件?
• 汽车软件中间件有什么作用?
• 汽车软件中间件具体怎么工作的?

带着这些问题，我们开始今天的文章。

首先，我们来看看汽车软件中间件的定义，到底什么是中间件?

一般来说，汽车软件的分层架构通常由四个主要层级组成： 处理器硬件、内核操作系统、中间件和实现车辆功能的应用软件 。

图片来源: Apex.AI

1. 处理器硬件

这是汽车软件架构中的硬件基础，在当前的集中式电子电气架构中，异构硬件架构成为趋势，即片上系统(SoC, System on Chip)。

SoC是一种集成电路，将计算机或电子系统中的所有主要组件集成到单一芯片上。SoC 通常包含处理器(CPU)、图形处理单元(GPU)、内存、输入/输出接口、控制器和其他功能模块，其主要目的在于：

• 集成度高：SoC将多个功能模块集成到一个芯片上，减少了电路板上的元器件数量，降低了设备的体积和复杂性。
• 功耗低：因为集成度高，SoC能够减少数据在不同模块之间的传输距离，从而降低功耗，这对于移动设备和电动车等应用至关重要。
• 提高性能：由于多个功能模块共享同一芯片，SoC中的数据处理速度快，可以提升系统的整体性能，尤其是在图形处理、人工智能计算等高需求任务中。
• 成本优化：SoC可以通过减少独立芯片和元器件，降低生产成本，并使得制造过程更加简化和高效。
• 专用功能：不同的SoC可以为不同的应用领域进行专门优化，如汽车中用于控制自动驾驶的SoC可以专门优化AI推理和传感器融合。

在汽车行业中，SoC被广泛用于支持高级驾驶辅助系统(ADAS)、自动驾驶功能、车载娱乐系统等智能应用。

2. 内核操作系统

汽车操作系统分广义和狭义的操作系统，这里只指狭义的操作系统，即内核操作系统(Kernel OS)，它是嵌入在汽车软件架构中非常关键的软件，负责管理车辆的硬件资源和执行实时任务，确保系统在各种驾驶场景中的调度任务被安全与稳定地执行。

它需要具备高实时性、强安全性以及高可靠性，能够快速响应传感器数据，调度执行诸如驱动系统控制、制动系统控制等核心任务。

典型的操作系统如AUTOSAR、QNX和实时Linux，被广泛应用于自动驾驶与高级驾驶辅助系统(ADAS)，当然，不同的域控，以及E/E架构对汽车操作系统的需求也有所不同。

3. 应用软件

这是最贴近用户体验的一层，主要用于实现具体的车辆功能和控制逻辑。随着汽车智能化程度的提高，应用软件的复杂性也在不断增加，包括自动驾驶、车联网、驾驶辅助系统等，这些软件直接决定了用户的驾驶体验。

4. 中间件

中间件(Middleware)本身属于广义的汽车操作系统 ，处于内核操作系统之上，应用层软件之下。

谈到中间件，相信大部分朋友的第一反应就是TRE，没错， RTE是我们最熟悉的嵌入式软件架构AUTOSAR Classic的中间件 。

中间件是整个汽车软件架构中的桥梁，连接着底层硬件和上层应用软件。它不仅提供了对处理器硬件的抽象，还为系统功能的实现提供支持，这也就是所谓''中间''二字的来源 ，例如，控制器内部通信、控制器间通信、数据管理等功能，都由中间件处理。

那么，到底什么是中间件呢?

中间件的定义其实有很多，我之前看到过一个定义，相对比较简洁，好理解:

简单地说，中间件(Middleware)就是glue code 。

从所处的位置来看，中间件属于汽车内核操作系统与应用软件之间 ，本身 属于广义的操作系统 。

从所发挥的作用来看，中间件起着翻译的作用，它通过 对底层的硬件进行抽象，屏蔽底层复杂的硬件，为上层应用层软件提供标准化的接口，使得汽车软件架构中的不同组件之间能够进行无缝的通信和数据交换。

当然，就如之前提到的， 中间件并不是在自动驾驶或者智能汽车背景下才出现的新鲜玩意，它在传统的汽车嵌入式软件架构中早已经存在，其主要目的都是为了实现软硬件解耦，例如，如下图所示，我们最熟悉的Classic AUTOSAR中的TRE就是非常典型的中间件解决方案。

这里特别说明 的是 ，Classic AUTOSAR不仅仅包含了操作系统和中间件，它是完整的汽车嵌入式软件架构，而与之相对应的基于服务的Adaptive AUTOSAR则仅仅只是中间件，并不包含操作系统，不属于完整的软件架构。关于 Classic AUTOSAR和 Adaptive AUTOSAR相关内容，我们后续在详细聊。

聊完了中间件定义，那么，中间件具体的功能和作用主要有哪些呢？

提到中间件的作用，大家比较熟悉的就是软硬件解藕，这也是中间件产生的初衷，但到底什么是软硬件解耦，中间件还有其他的作用吗 :

1. 抽象底层硬件，形成标准化接口:

中间件通过抽象和屏蔽底层硬件的复杂性 ，为应用软件提供了一致的标准化的操作接口。这样，汽车软件工程师无需直接与硬件交互，而是通过中间件提供的标准接口来访问硬件资源，方便上层软件开发。

中间件使得应用软件与操作系统和硬件解耦，应用层软件可以在不同的硬件平台上运行，而无需进行重大修改，增强了软件的可移植性和复用性，大大降低了开发成本和时间。

通过中间件的使用， 汽车软件架构能够实现模块化设计，聚焦上层应用层软件差异化 ，使得各个功能模块（如动力控制、车载娱乐系统、安全系统等）可以独立开发、测试和部署，这种模块化设计使得功能的扩展和维护更加便捷，同时也提高了系统的整体稳定性，提高了开发效率。

2. 通信与数据交换:

中间件在不同的软件组件之间，软件和硬件之间扮演着数据交换和通信的角色。它负责数据的传输、协议的转换和消息的分发，确保各个软件模块，在ECU内部及跨ECU之间，都能够高效地进行沟通。

通讯是中间件的最重要的功能之一 ， 也正是因为这样，中间件也被成为 通讯中间件 。尤其在汽车智能化大背景下，中间件作为数据交换和通讯的角色和重要性更加突出。

那对于通讯中间件而言，究竟需要做什么呢，具体又是怎么工作的呢?

相信大家都熟悉， 汽车控制单元中不同的通讯总线( 如CAN、LIN、FlexRay、Ethernet等)，根据不同的信号吞吐及速度要求，我们可以采用不同的通信总线和协议，完成不同ECU之间的通信。

例如:

• CAN 总线：最常用的汽车通信总线之一，特别适合实时性要求高的系统。
• LIN 总线：适用于低速、非实时的系统，如座椅调节和车窗控制等。
• Ethernet：在高级辅助驾驶系统(ADAS)和车载娱乐系统中，Ethernet逐渐被应用于高速数据传输。

那么问题来了！

问题1: 每个通信总线都有自己的数据帧格式、传输速率等特性，那么不同的ECU之间具体怎么通过中间件接收对方发来的信号呢?

这里以ECU A和ECU B之间的CAN通信为例:

当ECU A要发送数据时：

• 应用层 ：首先，ECU A中的应用层软件需要决定要发送哪个数据(如传感器读数，控制变量等)，这个是我们在应用层软件就定义好的。
• 中间件 ：然后，ECU A中的应用层软件会把这个信号先扔给ECU A的中间件， 中间件将底层的CAN通信协议进行抽象，使得ECU应用层不需要直接处理复杂的CAN协议细节，直接 通过中间件已经定义好的CAN通讯标准接口传递给ECU A的CAN硬件模块。中间件会封装成符合CAN协议的数据帧，并分配合适的CAN ID，并可能调用高层协议(如ISO-TP)进行大数据分片。
• CAN硬件模块 ：最后，ECU A的硬件模块拿到中间件发来的数据，就将数据按照CAN协议打包成CAN帧(包括设置帧ID、数据字段、CRC校验等)。 打包好的CAN帧通过CAN收发器发送到CAN总线上。

当ECU Ｂ要 接收数据时：

• CAN硬件模块 ：首先，ECU B的CAN硬件模块从总线上接收到ECU A发过来的CAN帧，解析出帧ID、数据字段、CRC等信息，并进行错误检测。
• 中间件 ：然后， ECU B的 中间件得到 ECU B的CAN硬件模块解析出的数据，根据预设的规则或ID，将数据路由到ECU B 中的相应模块或任务，确保数据传输的可靠性和正确性。
• 应用层 ：最后，ECU B的应用程序接收到最终的数据并进行处理即可。

问题2: 如果两个ECU之间总线不一样怎么办，如何实现跨总线传输呢?

例如，ECU 只有CAN总线，而ECU B只有Ethernet总线?

这就是中间件所谓的 消息路由(Message Routing)功能，当然这里 必须提到''网关''这个组件了。 网关 是专门处理 跨总线系统 的数据传输和协议转换的设备或模块。它负责物理层的连接和通信协议的转换，它和中间件共同配合完成跨总线传输。

例如 ：

• 中间件在ECU A ：假设ECU A连接在CAN总线上，它的中间件负责准备要发送的传感器数据，并通过CAN总线发送。
• 网关设备 ：这个数据会到达网关，网关识别到目标ECU B在Ethernet总线上，因此负责将CAN协议的消息转换成Ethernet协议，并通过Ethernet总线发送到目标ECU B。
• 中间件在ECU B ：ECU B接收到Ethernet总线上的消息，其中间件负责处理这个传感器数据，传递给该ECU B 内部的应用软件模块。

所以，这里需要分区中间件和网关的功能区别: 

• 中间件 ：管理ECU内部的软件模块通信，负责在单一总线上与其他ECU通信， 负责统一管理和协调， 但它不会直接负责跨总线的通信。
• 网关 ：处理跨总线通信的任务，负责将来自一种总线的数据传输到另一种总线，进行协议转换、路由和数据转发。

当然，除了实现上述的总线管理功能外，通讯中间件还有其他功能:

例如，如果应用层存在很多信号交互，而对于某些关键系统(如制动或转向系统)，对信号传输的实时性和可靠性都比较高，这种情况需要怎么处理呢?  这就涉及到通讯中间件以下几个功能:

时间触发调度(Time-Triggered Scheduling)

对于某些关键系统信息的传输，中间件可能会使用时间触发的调度机制，确保在预定的时间点传输重要数据。这种机制保证了系统的实时性和可靠性，特别是在处理安全关键的任务时。

• TTP(Time-Triggered Protocol)：一种常见的协议，它确保所有参与的ECU在严格同步的时间表下进行通信，避免数据碰撞和延迟。

错误检测与处理

中间件负责实时监控通信中的错误，并采取必要的措施来恢复或重传数据。典型的错误检测与处理方法包括：

• 校验码：例如在CAN总线中，每个消息帧包含校验码(CRC)，中间件可以根据校验码检测消息在传输过程中是否损坏。
• 自动重传：当发现数据包丢失或错误时，中间件可以自动发起重传，确保数据完整传输。
• 故障隔离：如果某个ECU发生故障，中间件能够检测并隔离它，以防止其影响整个系统的通信。

优先级调度

在资源有限的总线上(如CAN)，不同的消息有不同的优先级，中间件通过仲裁机制确保高优先级的消息优先传输。优先级的设定通常与功能安全相关，确保关键系统(如安全气囊)的信息不被延迟。

3. 任务调度和资源管理:

很多朋友有一个误解， 认为任务调度是操作系统OS的工作，但实际上它更多地依赖中间件。

以Autosar CP中的Runnable为例，只有通过RET对Runnable进行触发，并提供相应的数据，然后才会被分 配到不同的OS Task上去执行。所以， 中间件更像一个构件容器，为Runnable提供所需的运行环境和资源，然后再映射到OS Task去执行 ，OS Task只是提供了一个时钟运行的载体而已，这一点需要我们特别注意。

为了保证任务调度实时性，中间件可以采用实时操作系统(如AUTOSAR OS或其他RTOS)中的优先级调度机制，确保高优先级的任务得到及时处理。

例如，对于涉及驾驶安全的数据(如ADAS传感器的反馈)，中间件可以分配更高的优先级，优先调度这些数据包的处理。 对于低优先级的数据（如信息娱乐系统的音频流），则可以放到更低的优先级队列中，以避免对系统的关键实时任务产生干扰。

此外， 中间件还可以负责实时性和性能优化任务 。 例如， 中间件可以通过任务调度机制来优化系统资源的利用，确保高优先级任务（如安全相关任务）能够按时执行，而不受低优先级任务的影响。

它可以调度资源、管理内存和处理器使用，在多核系统中，中间件可以管理任务的分布，确保系统负载均衡，避免单个处理器过载，以及最小化上下文切换，将功能相关的任务进行合并或批量执行，减少任务之间频繁切换的需求(例如，多个传感器数据处理任务可以被合并到一个批处理任务中，从而减少多次任务切换的开销)等等，确保关键任务能够在严格的时间限制内完成，这对实时性要求高的域控制器，如自动驾驶和高级驾驶辅助系统，尤为重要 。

4. 安全与可靠性:

在安全性和可靠性方面，中间件也发挥着重要作用 。

对于信息安全 (Security)

中间件可以负责确保系统中传输和存储的数据的完整性和机密性，防止数据篡改、泄露或损坏。 具体措施包括：

• 加密传输：中间件可以在不同ECU之间进行数据加密，确保在通信总线上传输的数据不会被第三方截取或篡改。中间件能够调用加密模块或协议(如TLS)，保护敏感数据在汽车网络中的传输。
• 数据完整性校验：通过使用哈希算法或消息认证码(MAC)，中间件能够验证每次传输数据的完整性，确保数据在传输过程中未被修改或损坏。

对于功能安全(Functional Safety)

特别是在关键安全系统(如制动系统、动力系统、自动驾驶系统)中。中间件通过错误检测与隔离机制保障系统安全。 这也是为什么有些软件供应商会强调自己的中间件满足相应ASIL等级的原因。 具体措施包括：

• 故障检测与报告：中间件可以监控系统中的故障模式，并在检测到硬件或软件故障时，立即触发安全策略，例如降级模式或紧急停机，确保系统不会因为单点故障而导致整体失效。
• 冗余与错误恢复机制：中间件还可以通过冗余设计，支持多个备份系统，在一个系统出现故障时自动切换到备份系统，从而确保关键任务的持续安全运行。

总体而言， 中间件的核心思想体现在“统一标准、分散实现、集中配置”这三个关键原则:

首先，通过 统一标准 ，为各个厂商提供一个通用且开放的平台，确保不同组件能够在同一框架下无缝协作。

其次， 分散实现 意味着软件系统应当层次化和模块化设计，降低应用与平台之间的耦合度，使得各个模块能够独立开发、测试和部署。

此外，不同模块通常由不同的厂商开发，它们之间可能存在复杂的依赖关系。为了将这些模块整合成一个完整的系统，必须对所有模块的配置信息进行 集中管理 ，以统一的格式存储和管理配置数据，从而生成和维护整个系统的配置。

所以，从上述中间件功能可以看出，中间件诞生的初衷非常好，通过中间件实现软硬件解耦，对底层硬件进行抽象，对上提供标准接口和服务，让不同的OEM或者不同的平台之间，软件模块化，灵活复用，只关注上层应用的开发，而不用考过多虑底层硬件的细节和变更影响，避免重复造轮子。

但愿望很理想，现实很骨干 ，就拿我们传统嵌入式软件架构鼻祖Classic AUTOSAR为例，尽管在一定程度上实现了软硬件解耦，但还是没办法脱离硬件的束缚，OEM一旦选定硬件供应商后，基本上就深度绑定，软件的移植或硬件平台的更换依然需要付出大量的时间和精力，根本没办法实现像我们个人电脑应用这种级别的软硬件解耦 ，加上汽车高阶芯片的紧缺和垄断情况，从一定程度上，芯片决定了整个硬件，而硬件和软件又一定程度上深度绑定，这就是现实的无奈！

当然，这里存在很多原因，有技术原因，更多的是企业不同的组织架构，利益捆绑，技术壁垒等非技术因素，汽车软件中间件真正实现其初衷还有很长的路要走！！！

当然，也正是因为这种背景，智能汽车软件中间件解决方案也五花八门，这就引出了我下篇文章，中间件为什么突然火了，且听下回分解！