#Innolight

计算机和通信

计算机软件组件之间有效通信的挑战几乎与计算机系统本身一样古老。无论两段计算机代码是在一台计算机的不同内存区域运行和操作，还是在数千英里之外，让它们相互“对话”的挑战自计算诞生之初就一直困扰着计算机科学家和工程师。

这一基本要求的原因来自多个方面：

• 首先，单个计算单元的功能一直以来（并且很可能也将一直）受到限制，包括指令执行和存储容量。在这些单元上运行的软件组件可以利用跨通信来更高效地分配和执行工作负载。
• 尽管几十年来计算能力在多个方向上都在不断增长，但没有任何一个人的大脑能够管理当今计算机所能运行的软件系统的复杂性。因此，软件需要“适应”现有的计算机，并被结构化和模块化，形成易于单个组织、团队以及最终由工程师开发和维护的内聚单元。毫无疑问，这些内聚单元之间需要相互通信。
• 此外，诸如安全性和保障性等软件特性在很大程度上取决于执行环境隔离的概念。正如没有人是一座孤岛一样，任何一段代码都无法完全独立于其环境运行，因此跨环境通信必不可少。

远程通信的概念深深植根于计算机设计之中，以至于历代处理器指令集都包含“调用”指令。当然，在这种情况下，“调用”意味着将执行流程传输到不同的位置，同时保留当前状态直到调用完成。某种程度上，这些调用指令是通信机制的前身，这种机制允许数据元素在单个计算机程序的不同部分之间移动，同时作为不同的进程或任务运行（可能并发运行）。

这就是“进程间通信 (IPC)”一词的由来。最初，在计算机开始相互通信之前，IPC 机制被设计用于在同一台计算机上运行的进程或任务之间共享数据，其中一组内存资源和/或互连可供多个软件组件访问。但后来计算机网络改变了游戏规则，允许不同计算机中的软件元素使用类似 IPC 的机制来共享信息。

计算机软件组件之间有效通信的挑战几乎与计算机系统本身一样古老。

一个被忽视的关键点是，尽管 IPC 机制功能强大，但它们仍然是相对低级和原始的通信基础设施。它们不包含任何关于其传输数据的语义，而且在很多情况下，它们几乎无法保证数据的安全性、完整性、真实性、时序性或隐私性。正如美国参议员泰德·史蒂文斯曾经对互联网的著名描述：“它是一系列管道”。

通信协议为流经这些管道的数据赋予了节奏和意义。根据其运行级别，它们会优先处理语音通话，而不是多人游戏通信；区分视频流会话和地震警报；或确保银行业务的安全。通信协议是任何计算机系统（无论其规模大小）的重要组成部分。

值得一提的是，即使是最小的微控制器也拥有内部总线协议来管理内存和外设访问，并且只有在连接到系统的其他元素并使用协议进行通信时才能发挥作用。

正如预期的那样，协议最终变得过于复杂和庞大，以至于软件组件及其设计人员无法直接有效地管理它们。 就像计算领域的其他一切一样，它们被抽象成层，首先是非正式的，然后根据开放系统互连 (OSI) 模型更正式地被抽象成：物理协议、数据链路协议、网络协议、传输协议、会话协议、表示协议和应用协议。

在 OSI 模型中，从左到右，这些层由 I/O 硬件实现的程度越来越低，而由软件基础设施实现的程度越来越高。通信中间件组件位于 OSI 堆栈的顶部，位于软硬件通信基础设施和特定于任务的应用程序逻辑之间。

从协议到中间件

如上所述，通信基础设施已被构建成层级结构，层级内又包含协议，硬件和软件组件将一个挑战抽象化，层层叠加。然而，软件工程师仍然面临着这样的情况：他们特定的软件组件间语义和需求远非 OSI 模型最高层抽象出的那些“愚蠢”的“管道”。通信协议赋予数据在流经这些管道时的节奏和意义。

这正是中间件技术在 OSI 各层提供坚实的协议支持的地方，它不仅支持请求-响应、发送-接收和触发，还为上层应用层提供一套内聚的抽象通信模式、类型系统和应用程序编程接口 (API) 来实现它们。这些模式包括：

• 请求-响应通信，其中一端传输数据以传达某种请求，而另一端则提供回复（例如，接收/执行确认）。
• 发送-接收通信，其中一端发送离散数据单元，一个或多个接收者接收并处理这些数据。
• 发布-订阅通信，类似于发送-接收，但增加了接收者动态“表达兴趣”的概念，因此对某些信息不感兴趣的接收者不会订阅接收该数据，也不会包含在分发传输中。
• 触发通信，类似于发送-接收和发布-订阅模式，但其语义仅限于给定事件的发生，不包含有关事件本身的额外数据。

总而言之，中间件结合了通信协议和软件基础设施，以弥合领域特定逻辑与进程间通信基础设施，无论是本地的还是网络的。

AUTOSAR 平台和通信中间件

AUTOSAR 作为一种软件架构，其核心理念是抽象和统一各种技术和标准（例如微控制器架构、硬件接口或车载和车外通信协议），以便汽车软件工程师能够专注于实际的功能开发。

在汽车行业，AUTOSAR 是最具代表性的中间件之一，即使不是最具代表性的。没有任何 AUTOSAR 平台会告诉您在设计中应该使用哪种微控制器或微处理器架构、从哪个供应商购买、应该部署哪些网络技术来互连您的系统，或者应该使用哪些底层协议。

AUTOSAR 将决定（以及许多其他事项）您的软件组件将使用哪些通信模式来相互通信。在经典平台中，运行时环境 (RTE) 支持请求-响应、发送-接收和触发通信等。

在自适应平台中，通信管理功能集群（CM 或 ara::com）的请求-响应、发送-接收和触发通信模式被归类于单一面向服务架构 (SOA) 概念。

这些中间件解决方案不仅强制执行通信模式，还提供统一的类型系统来定义数据在请求方和回复方、发送方和接收方、发布方和订阅方之间流动时的结构和性质。

当然，没有哪个 AUTOSAR 平台会在单个层、功能集群或软件模块中实现这些通信模式，而是利用完整的系统服务、硬件抽象和驱动程序堆栈。

融合中间件标准

随着我们阅读本文的时间推移，我们发现通信中间件解决方案似乎注定要相互叠加，就像几十年来的网络协议一样，提供更深层次的抽象，以便设计出功能更强大的系统。

在其他成熟的中间件标准之上重新构建面向应用的中间件组件，不仅为网络层的互操作性打开了大门（例如，防火墙可以过滤网络层帧，而对其携带的数据一无所知），也为应用层的互操作性打开了大门。在应用层，基于不同中间件解决方案（例如 AUTOSAR Classic、AUTOSAR Adaptive、DDS 和 ROS）构建的应用程序之所以能够互操作，是因为它们在内部共享配置为完全协调运行的通用中间件层。

AUTOSAR 独特的灵活性是引入这些全新中间件技术的关键：

• 在经典平台中，PDU（分组数据单元）路由器无缝集成了多种上层通信模式和序列化技术，以及低带宽总线和基于 IP 的协议等低层传输机制。
• 在自适应平台中，ara::com 的网络绑定概念允许多种底层网络技术实现面向服务。

在经典平台和自适应平台中，OMG® DDS 中间件不仅作为协议进行了标准化，而且作为底层中间件进行了标准化，分别实现并改进了 RTE 和 ara::com，超越了目前普遍使用的 SOME/IP 和基于 PDU 的协议。例如，不同的 ROS 衍生产品也可以采用类似的方法。

随着 AUTOSAR 平台不断改进和发展，涵盖更多功能领域，它们也将通过新的、更符合行业的中间件集成进行垂直扩展。

此次整合不仅将扩展 AUTOSAR 生态系统内外的互操作性，还将带来重要的新功能，包括（但不限于）高级 QoS 策略、更灵活的底层传输选择以及运行时可观察性。互操作性的持续进步将有助于汽车工程师在未来汽车设计的演进过程中不断进步。