点击订阅专栏不迷路

返回总目录

先看一张图，这是整个BSW层可以提供的服务，今天我们重点来讲一讲这个通信服务。

整个通信服务所包含的模块可以分为下图所示，这张图涵盖了所有总线模块，后边的文章中我们会依次展开介绍，今天我们主要讲一讲BSW层通信的三层架构，从上到下分别是通信服务、通信硬件抽象、通信驱动。

一、通信驱动

如果接触过Arm的童鞋，应该听过库的概念。简单说就是将芯片的寄存器操作都封装称API函数，方便用户调用。这里的通信驱动也是一样，是将芯片上的关于通信的功能都封装称一个一个的API函数，供上层调用，而这些API函数是AutoSAR规定好的（通常驱动这一层叫做Mcal）。针对不同的芯片，在这一层就可以做到对上层的接口完全一致。这样的好处就是，当配置好了之后，同一个操作可以兼容所有芯片。

二、通信硬件抽象

通信硬件抽象（Communication Hardware Abstraction）能够将通信控制器的位置以及 ECU的硬件布局进行抽象化处理。对于所有的通信系统，如 LIN、CAN、FlexRay 等，都需要特定的通信硬件抽象。

以一个具体的 ECU 为例，它具有一个带有 2 个内部 CAN 通道的微控制器，以及一个带有 4 个 CAN 控制器的板载 ASIC（专用集成电路），并且该 CAN - ASIC 通过 SPI（串行外设接口）与微控制器相连。

通信硬件抽象的主要任务是提供平等的机制来访问总线通道，而无需考虑其位置（是在芯片上还是在板载上）。其具有以下属性：

• 实现方式：独立于微控制器（μC），但依赖于 ECU 硬件以及外部设备。
• 上层接口：依赖于总线，而独立于微控制器和 ECU 硬件。

在实际架构中，通信驱动程序通过特定于总线的接口（例如 CAN 接口）进行访问。通信硬件抽象层包含了如 CAN 接口、CAN 收发器驱动、外部 CAN ASIC 驱动等模块，它们协同工作，为上层软件提供了一个统一且与硬件细节无关的通信接口，使得上层软件能够更加便捷、高效地与底层硬件进行通信交互，同时也增强了系统的可移植性和可维护性，为汽车电子系统的稳定运行和功能实现奠定了坚实的基础。

三、通信服务

在汽车电子系统的软件架构里，通信服务是一组服务于车辆网络通信（涵盖 CAN、LIN、FlexRay 和以太网等）的模块集合。它们借助通信硬件抽象层与通信驱动程序交互，任务在于为车辆网络通信提供统一接口，为网络管理提供统一服务，为诊断通信提供统一接口，同时向应用层隐藏协议与消息属性。其属性方面，实现上独立于微控制器和 ECU 硬件，部分依赖总线类型，上层接口则独立于微控制器、ECU 硬件及总线类型。

在示例图里，诸如 LdCom、Com、PduR 这类模块具备能够独立与总线相连的特性。简单来讲，不管是在哪种总线上，这些模块都是通用的。

对于其中一些模块而言，当其应用于不同总线时，又会存在一定差异。例如，总线状态管理模块，在示例图中呈现为<Bus specific>State Manager，而当具体对应到特定的总线时，就会分别表现为 CanSm（对应 CAN 总线）、EthSm（对应以太网总线）等不同形式。再比如传输控制模块<Bus specific>Transport Protocol，当它应用到特定总线时，就会相应地变成 CanTp（对应 CAN 总线）、LinTp（对应 LIN 总线）等具体的形式。

3.1 CAN通信协议栈

先直接上图，图中蓝色模块为CAN通信协议栈独有的模块，也就是上边说的和总线相关联的模块，分別有CanSM、CanTp、CanNm
、CanIf、CanTrcv、CanDrv。

CAN 通信服务是一组专为车辆网络中 CAN 通信系统服务的模块集合，确保车辆各电子控制单元（ECU）之间基于 CAN 总线的高效、稳定通信。其主要任务有：

• 提供统一接口：为 CAN 网络提供一个统一的接口，使得应用层无需关心底层 CAN 通信的复杂细节，只需通过该统一接口就能与 CAN 网络进行交互，大大降低了应用层开发的难度和复杂度，提高了软件开发的效率和可维护性。
• 隐藏协议与消息属性：将 CAN 通信的协议以及消息的具体属性对应用层进行隐藏，应用层只需关注要传输的数据内容，而无需深入了解 CAN 协议的帧格式、位定时等底层技术细节，进一步简化了应用层的开发工作，使开发者能够更专注于应用功能的实现。

CAN协议栈支持的通信类型有：

• 经典 CAN 通信（CAN 2.0）：这是 CAN 通信的基础版本，广泛应用于汽车电子系统中，能够满足大多数常规的车辆通信需求，如发动机控制、车身电子等系统之间的数据交互。
• CAN FD 通信（若硬件支持）：CAN FD（具有灵活数据速率的 CAN）是 CAN 通信的一种扩展，在保持与经典 CAN 兼容性的基础上，提高了数据传输速率和数据帧的有效载荷，适用于对实时性和数据量要求更高的场景，如自动驾驶相关的传感器数据传输等。但需要注意的是，其使用依赖于硬件的支持，如果车辆的 ECU 硬件不具备 CAN FD 功能，则无法使用这种通信方式。

在实现方面，CAN 通信服务独立于微控制器（μC）和 ECU 硬件，这意味着它可以在不同的硬件平台上进行移植和复用，提高了软件的通用性和可扩展性。但同时，它又部分依赖于 CAN 总线本身，例如在一些与 CAN 总线特性相关的参数设置、错误处理等方面，需要根据 CAN 总线的具体规范和要求进行适配和处理。

AUTOSAR COM（遵循 AUTOSAR 标准的通信模块）、通用 NM（网络管理）接口和诊断通信管理器这几个模块对于所有车辆网络系统是相同的，并且在每个 ECU 上仅存在一个实例。通用 NM 接口仅包含一个调度器，不包含其他进一步的功能。但在网关 ECU 的情况下，它还可以包含 NM 协调器功能，该功能允许同步多个不同的网络（相同或不同类型），以便同步唤醒或关闭它们，从而实现整个车辆网络系统的高效电源管理和协同工作。而 CAN NM 是专门针对 CAN 网络的，会根据每个 CAN 车辆网络系统进行实例化，以满足不同 CAN 网络的特定管理需求，例如网络状态监测、节点状态管理等。

通信系统特定的 Can 状态管理器（CanSM）负责处理与通信系统相关的启动和关闭特性。此外，它还控制 COM 模块的不同选项，例如发送协议数据单元（PDUs）以及监控信号超时等功能，确保 CAN 通信的可靠性和实时性，及时发现和处理通信过程中的异常情况，保障车辆网络的正常运行。

3.2 J1939通信协议栈

J1939 通信服务是对普通 CAN 通信栈的扩展，其同样基于CAN总线传输数据（扩展帧），专门用于重型车辆的车辆网络通信。它在重型车辆的电子系统中起着关键作用，确保车辆各部件之间能够高效、可靠地进行信息交互。具体有关于J1939协议的介绍我们将在后续文章中单独介绍。

• 提供 J1939 所需协议服务：为满足 J1939 标准在重型车辆网络中的应用，提供相应的协议服务，包括数据的封装、解析、传输等一系列操作，以保证符合 J1939 规范的数据能够在车辆网络中准确传输和处理。
• 隐藏非必要协议与消息属性：对于应用层，在不需要了解的情况下，隐藏 J1939 协议以及消息的具体属性，使应用层开发者能够专注于应用功能的开发，而无需深入钻研复杂的 J1939 协议细节，降低了开发难度和复杂度。

CanTp 与 J1939Tp 的使用场景：在 CAN 栈中有两个传输协议模块，即 CanTp 和 J1939Tp，它们可以在不同通道上交替或并行使用。CanTp 主要用于 ISO 诊断（DCM）以及在标准 CAN 总线上传输大型协议数据单元（PDU）；而 J1939Tp 则用于 J1939 诊断以及在 J1939 驱动的 CAN 总线上传输大型 PDU。这样的设计使得系统能够根据不同的应用场景和需求，灵活选择合适的传输协议模块，提高了系统的适应性和灵活性。

J1939通信协议栈的主要特点有：

• 实现独立性与基于 CAN：在实现上，J1939 通信服务独立于微控制器（μC）和 ECU 硬件，这为其在不同硬件平台上的应用提供了便利，增强了软件的可移植性和通用性。同时，它是基于 CAN 的，继承了 CAN 总线的一些基本特性和优势，如可靠性高、实时性强等，但又在 CAN 的基础上进行了针对重型车辆网络通信的扩展和优化。
• 模块通用性与实例化：AUTOSAR COM、通用 NM 接口和诊断通信管理器这几个模块对于所有车辆网络系统是相同的，并且在每个 ECU 上仅存在一个实例。这种设计保证了系统架构的一致性和规范性，便于系统的集成和管理。
• 支持动态帧标识符：支持在配置时未知的动态帧标识符，这使得系统能够更加灵活地处理各种数据帧，适应复杂多变的车辆网络通信环境，提高了系统的可扩展性和兼容性。
• J1939 网络管理特点：J1939 网络管理负责为每个 ECU 分配唯一地址，但不支持睡眠 / 唤醒处理以及像部分网络这样的相关概念。这意味着在 J1939 网络中，主要关注的是节点地址的分配和管理，以确保网络中各节点的唯一性和可识别性，但在电源管理等方面相对较为简单，可能需要其他机制来补充实现。
• J1939 诊断与请求处理：提供了 J1939 诊断功能和请求处理能力，方便对重型车辆的电子系统进行故障诊断和维护。通过 J1939 诊断，可以快速准确地获取车辆各部件的状态信息和故障信息，提高了车辆的可维护性和可靠性，降低了维修成本和时间。

3.3 LIN通信协议栈

LIN 通信服务是一组专门用于车辆网络中 LIN 通信系统的模块集合，在汽车电子系统的 LIN 网络通信中发挥着核心作用，确保车辆内各 LIN 节点之间能够顺畅地进行信息交互。同样的，其主要任务有：

• 提供统一 LIN 网络接口：为 LIN 网络提供一个统一的接口，使得应用层能够以一种简洁、一致的方式与 LIN 网络进行通信，无需关心底层 LIN 通信的复杂细节和协议规范，大大降低了应用层开发的难度和复杂度，提高了软件开发效率。
• 隐藏协议与消息属性：将 LIN 通信的协议以及消息的具体属性对应用层进行隐藏，应用层只需关注要传输的数据内容，而无需深入了解 LIN 协议的帧格式、位定时、校验方式等底层技术细节，使开发者能够更专注于应用功能的实现，提升了开发的便捷性和灵活性。

LIN 通信服务包含内容有：

1、符合 ISO 17987 标准的通信栈：

• 调度表管理器（针对 LIN 主节点）：用于处理切换到其他调度表的请求，确保 LIN 主节点能够按照预定的调度策略有序地与 LIN 从节点进行通信，实现对 LIN 网络通信的高效管理和控制，保证数据传输的及时性和准确性。
• 不同 LIN 帧类型的通信处理：能够处理 LIN 网络中各种类型的帧，包括数据帧、事件触发帧、诊断帧等，满足不同应用场景下的数据传输需求，确保 LIN 网络能够适应车辆电子系统中多样化的通信要求。
• 用于诊断的传输协议：提供了专门用于诊断的传输协议，方便对 LIN 网络中的节点和系统进行故障诊断和状态监测，有助于快速定位和解决车辆电子系统中的问题，提高车辆的可靠性和可维护性。
• 唤醒和睡眠接口：具备唤醒和睡眠接口，实现 LIN 网络的节能管理。当车辆处于休眠状态时，LIN 网络可以进入低功耗的睡眠模式，而当需要唤醒时，通过该接口能够快速、可靠地将 LIN 网络唤醒，恢复正常通信，在保证车辆功能正常运行的同时，降低车辆的能耗。

2、底层 LIN 驱动：

• 实现 LIN 协议与硬件访问：负责实现 LIN 协议的具体细节，包括数据的编码、解码、错误检测等，并能够访问特定的硬件资源，如 LIN 控制器、收发器等，确保 LIN 通信能够在硬件层面上顺利进行，是 LIN 通信服务与硬件设备之间的桥梁。
• 支持多种 LIN 硬件：支持简单的 UART（通用异步收发传输器）和复杂的基于帧的 LIN 硬件，具有良好的硬件兼容性，能够适应不同类型的 LIN 硬件平台，为系统的硬件选型和集成提供了更大的灵活性。

LIN 与 AUTOSAR 集成相关内容

• LIN 接口的作用：LIN 接口控制唤醒 / 睡眠 API，并且允许从节点采用去中心化的方式保持总线唤醒状态。这种去中心化的唤醒机制使得 LIN 网络中的从节点能够在一定条件下自主控制总线的唤醒状态，提高了系统的灵活性和可靠性，避免了因主节点故障导致整个 LIN 网络无法唤醒的情况。
• LIN 状态管理器的功能：通信系统特定的 LIN 状态管理器负责处理与通信相关的启动和关闭特性，确保 LIN 网络在启动和关闭过程中能够按照预定的流程和时序进行操作，保证网络的稳定性和可靠性。此外，它还控制来自通信管理器的通信模式请求，协调 LIN 网络的通信模式切换，以满足不同的通信需求。同时，LIN 状态管理器通过与 COM（通信模块）接口，控制 I-PDU（交互层协议数据单元）组，实现对数据传输的精细化管理和控制，确保数据能够准确、高效地在 LIN 网络中传输。
• LIN 帧发送时的数据请求机制：当发送 LIN 帧时，LIN 接口会在需要数据（即正好在发送 LIN 帧之前）的时刻，从 PDU 路由器请求该帧（I-PDU）的数据。这种实时的数据请求机制能够确保发送的数据是最新的，并且与当前的通信需求相匹配，提高了 LIN 网络数据传输的实时性和准确性。

3.4 FlexRay通信协议栈

FlexRay 通信服务是一组专门服务于车辆网络中 FlexRay 通信系统的模块集合，同样的，其主要任务有：

• 提供统一接口：为 FlexRay 网络提供统一的接口，这使得应用层在进行数据交互时，无需深入了解 FlexRay 通信底层复杂的协议、拓扑结构以及数据传输机制等细节内容，只需通过这个统一的接口就能便捷地与 FlexRay 网络进行通信，极大地简化了应用层开发的复杂度，提高了软件开发的效率与可维护性。
• 隐藏协议与消息属性：将 FlexRay 通信的协议以及消息具体属性对应用层进行隐藏，应用层开发者只需聚焦于要传输的数据本身，不用操心诸如 FlexRay 帧格式、时隙分配、编码方式等底层技术细节，从而能更专注于实现具体的应用功能，让开发工作更加高效。

在 FlexRay 栈中有两个传输协议模块，分别是 FrTp 和 FrArTp，它们可相互替代使用。

• FrTp（FlexRay ISO 运输层）：主要遵循 FlexRay 的 ISO 相关标准构建运输层功能，负责在 FlexRay 网络中进行数据的传输调度、差错控制等操作，保障数据能按照 ISO 标准规范在 FlexRay 总线上准确、可靠地传输。
• FrArTp（FlexRay AUTOSAR 运输层）：它的重点在于提供与 AUTOSAR 标准的兼容性，特别是针对 AUTOSAR R3.x 版本，确保基于 FlexRay 网络的通信能很好地融入整个遵循 AUTOSAR 标准的汽车电子系统架构中，实现不同模块、不同网络之间的协同工作。

FlexRay通信协议栈的主要特点有：

• 实现独立性与部分依赖性：在实现方面，FlexRay 通信服务独立于微控制器（μC）和 ECU 硬件，这意味着该服务可以较为方便地在不同硬件平台间进行移植和复用，增强了软件的通用性和可扩展性。不过，它部分依赖于 FlexRay 总线本身，毕竟 FlexRay 有其独特的通信特性，像通信周期、时隙配置等，所以在一些与这些特性相关的功能实现和参数设置上，需要依据 FlexRay 总线的具体要求来进行适配处理。
• 通用模块的特性与实例化：AUTOSAR COM、通用 NM 接口和诊断通信管理器这几个模块对于所有车辆网络系统来说是通用的，并且在每个 ECU 上仅存在一个实例。通用 NM 接口只包含一个调度器，本身并不涵盖其他更多功能。但在网关 ECU 的情况下，它会被 NM 协调器所替代，NM 协调器除了具备基本的调度功能外，还额外提供了同步多个不同网络（无论是相同类型还是不同类型的网络）的功能，能够实现对这些网络进行同步唤醒或关闭操作，这对于整个车辆网络系统的电源管理以及不同网络间的协同工作十分关键。
• FlexRay NM 的针对性：FlexRay NM 是专门针对 FlexRay 网络而设置的，会依据每个 FlexRay 车辆网络系统进行实例化，其主要负责 FlexRay 网络的节点管理、网络状态监测以及与 FlexRay 网络特性紧密相关的一些网络管理功能，例如保障 FlexRay 网络中各节点在正确的时隙进行通信、处理网络中的节点加入和退出等情况，以此确保 FlexRay 网络的稳定运行。
• FlexRay 状态管理器功能：通信系统特定的 FlexRay 状态管理器负责处理与 FlexRay 通信系统相关的启动和关闭特性，例如在系统启动时，按照 FlexRay 网络的初始化要求进行各节点的配置、时隙分配等操作，在关闭时有序地停止各节点通信，避免数据丢失或错误。此外，它还控制 COM 模块的不同选项，像发送协议数据单元（PDUs）以及监控信号超时等功能，以此确保 FlexRay 通信过程中数据传输的准确性和实时性，及时发现并处理通信过程中出现的异常情况，保障车辆网络的正常运转。

3.5 ETH通信协议栈

TCP/IP 通信服务是一组专门针对车辆网络中采用 TCP/IP 通信系统而设计的模块集合。其主要包含的模块有：UdpNm、EthSM、SoAd、TcpIp、EthIf、EthSwitchDrv、EthTrcv、EthDrv。以太网通信属于AUTOSAR通信架构中的高级通信服务了，后边会单独出一个大的章节专门讲一讲以太网通信协议栈。其主要任务同样有以下两点：

• 提供统一接口：为 TCP/IP 网络打造一个统一的接口，使得车辆电子系统中的应用层无需去深入了解 TCP/IP 协议族复杂的底层细节，比如 TCP 三次握手、IP 数据包的封装与转发、UDP 的无连接传输机制等。应用层只需通过这个统一接口就能轻松地与 TCP/IP 网络进行交互，极大地简化了应用开发过程，提升了开发效率以及软件的可维护性。
• 隐藏协议与消息属性：将 TCP/IP 协议以及消息的具体属性向应用层进行隐藏，让应用层开发者把注意力更多地集中在需要传输的数据内容本身，而不用操心诸如 IP 地址分配、端口号管理、协议头格式等繁杂的底层技术细节，从而更专注于实现具体的应用功能，促进汽车电子系统中各类功能应用的快速开发。

ETH通信协议栈的主要特点有：

• TcpIp 模块功能：TcpIp 模块承担着实现 TCP/IP 协议族中主要协议的重要职责，具体涵盖了 TCP（传输控制协议）、UDP（用户数据报协议）、IPv4（网际协议版本 4）、IPv6（网际协议版本 6）、ARP（地址解析协议）、ICMP（网际控制报文协议）以及 DHCP（动态主机配置协议）等协议。通过对这些协议的实现，它能够在以太网上提供基于套接字（socket）的动态通信方式。例如，基于 TCP 协议，车辆的某个 ECU 可以与远程服务器建立可靠的、面向连接的通信链路，用于传输诸如车辆诊断数据、实时路况信息等重要数据；而利用 UDP 协议，则可以实现一些对实时性要求较高但对数据可靠性要求相对没那么严格的通信场景，像车载多媒体系统中的实时音频流传输等。IPv4 和 IPv6 负责网络层的地址分配与数据包路由，确保数据能准确地在不同网络节点间传输；ARP 用于将 IP 地址解析为对应的 MAC 地址，保障数据能准确地发送到相应的物理设备上；ICMP 则用于在网络中传递控制消息，辅助检测网络的连通性和故障情况；DHCP 能够动态地为网络设备分配 IP 地址，方便车辆网络中的设备快速接入网络。
• Socket Adaptor 模块（SoAd）：Socket Adaptor 模块（SoAd）在整个架构中处于关键位置，它是 TcpIp 模块唯一的上层模块。SoAd 模块主要起到一个衔接的作用，它将 TcpIp 模块所提供的基于套接字的通信功能进行进一步整合与适配，以便更好地对接应用层，为应用层提供更加符合其使用习惯和需求的接口，使得应用层能够更加便捷、高效地利用 TcpIp 模块实现的 TCP/IP 通信功能，从而完成诸如发送和接收数据、建立和关闭网络连接等操作。

在接下来的文章中我们将对CAN通信协议栈涉及到的所有模块进行详细讲解。

参考文档： AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf