车载以太网网络管理之UdpNm

汽车ECU开发 2023-06-15 08:50

TI MCU方案：电动汽车实时控制 构建AI未来，Arm计算平台无处不在

前言

首先，请问大家几个小小问题，你清楚：

你知道UdpNm模块的主要作用是什么吗？
UdpNm模块与其他AUTOSAR基础软件模块交互关系；
UdpNm模块的网络管理算法，状态机如何运转？
UdpNm模块的PNC功能如何作用？
UdpNm的应用场景有哪些？

今天，我们就来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲：

正文

随着车载以太网技术的发展，越来越多的汽车厂商和供应商开始采用基于TCP/IP协议栈的通信系统，以提高车辆内部网络的性能和可靠性。

然而，TCP/IP协议栈本身并不提供网络管理功能，也就是说，它不能实现节点之间的状态同步、节能控制、故障检测等功能。为了解决这个问题，AUTOSAR组织制定了一种基于UDP协议的网络管理协议，即UDP Network Management (UdpNm)。

如下图1所示，描述了UdpNm在整个AUTOSAR架构中的位置关系：

图1 UdpNm与AUTOSAR架构关系

由上图可知UdpNm与车载以太网协议栈SoAd模块，NM模块有着密切的联系，后文将一一为大家解读，除此之外UdpNm在整个AUTOSAR架构中存在着如下限制条件，如下图2所示：

在一个网络中只允许一个NM Cluster关联一个UdpNm实体;
在同一个ECU中只允许一个网络与一个UdpNm实体关联；
UdpNm仅适用于基于TCP/IP的系统；

图2 UdpNm限制条件

UdpNm应用场景与特点

UdpNm是一种独立于硬件和物理层的网络管理协议，它可以与TCP/IP协议栈一起工作，实现基于TCP/IP的系统的网络管理功能。UdpNm主要有以下几个特点：

UdpNm基于分散的直接网络管理策略，这意味着每个网络节点只根据在通信系统内接收或发送的UDP数据包来执行自给自足的活动。UdpNm不需要任何中心节点或主节点来协调或控制其他节点。
UdpNm使用UDP协议作为传输层，这使得UdpNm具有较低的开销和延迟，以及较高的容错性和灵活性。UdpNm不需要建立连接或保持会话状态，也不需要对数据包进行确认或重传。
UdpNm支持局部网络管理功能，也就是说，它可以根据节点的通信需求和能耗情况，动态地激活或抑制部分网络群集（Partial Network Cluster, PNC）。这样可以减少不必要的数据包传输，节省网络带宽和电源消耗。
UdpNm支持触发传输功能，也就是说，它可以根据应用层或其他模块的请求，主动地发送或接收用户数据。这样可以提高用户数据的及时性和可靠性。

UdpNm适用于各种基于TCP/IP的车载以太网系统，例如车联网系统、音频视频系统、导航系统等。UdpNm可以实现这些系统中节点之间的状态同步、节能控制、故障检测等功能，常见的应用场景如下所示：

基于TCP/IP的车载以太网系统：UdpNm可以与TCP/IP协议栈一起工作，实现车载以太网节点的协同睡眠和唤醒，提高网络效率和节省能源。
分布式嵌入式系统：UdpNm可以用于基于UDP的通信系统，提供网络管理接口（Nm）和TCP/IP协议栈之间的适配，实现网络节点的状态监控和控制。
多媒体应用：UdpNm可以用于支持多媒体数据传输的网络系统，提供网络节点的同步和协调功能，实现数据流的质量保证和优化。

UdpNm工作原理

在正式介绍UdpNm工作原理之前，想必大家都听过AUTOSAR CanNM模块，该模块小T在之前的文章《AutoSAR之基础篇CanNM》已经进行了较为详细的介绍，因此有必要针对两者做一个比较，以便让大家对这两者的相同点与不同点有一个基本的认识。

UdpNm与CanNM的区别联系

如下图3所示，清晰地描述了UdpNm与CanNm两者之间的区别与联系：

图3 UdpNm与CanNm区别联系

由此可见，UdpNm的整个网络管理算法与CanNm基本是一致的，只不过是控制参数的变量名有所区别，本质上是相同的切换条件。

因此本文将不会过多的对UdpNm的网络管理状态机做过多的描述，如果大家需要详细了解，可以参考小T之前关于CanNm的文章《AutoSAR之基础篇CanNM》。

针对UdpNm的自身特性，UdpNm的工作原理主要围绕如下三个部分进行展开：

网络管理算法：定义了UdpNm如何根据接收和/或传输的UDP数据包来切换不同的网络状态，并执行相应的动作，定义了UdpNm如何根据不同的网络状态和条件来确定何时发送或接收UDP数据包，并说明了发送或接收UDP数据包所遵循的规则和流程。。
消息格式：定义了UdpNm使用的UDP数据包中包含哪些字段和信息，并说明了各个字段和信息的含义和作用。
用户数据处理：定义了UdpNm如何根据应用层或其他模块进行相应的数据处理。

网络管理算法

如下图4所示，为基于UdpNm的网络管理状态机，即对应的网络管理算法，描述的就是各网络状态之间如何进行切换：

图4 UdpNm网络管理状态机

与CanNm网络管理状态机一致，UdpNm模块将整个网络管理状态仍然划分为Bus Sleep Mode, Prepare Bus Sleep Mode, Network Mode 三大主体状态，其中Network Mode 可进一步划分如下三个子状态：

Repeat Message State：重复发送报文阶段（处于周期性发送NM报文阶段）；
Ready Sleep State：准备休眠阶段；
Normal Operation State: 主动请求正常工作阶段(处于周期性发送报文阶段)；

切换条件在这里不过多赘述，基本与CanNM一致，只不过UdpNm基于TCP/IP系统，调用的函数接口与配置参数名会有所差异，如需要对外发送以太网NM报文时调用的函数接口为SoAd_IfTransmit，接收以太网NM报文则是通过UdpNm_SoAdIfRxIndication来进行获取。

消息格式

如下图5所示，展示了UDP NM报文的报文格式：

图5 UdpNm报文格式

其中各关键参数解释如下：

Source Node Identifier：默认是Byte 0，通过参数UDPNM_PDU_NID_POSITION来决定，可以选择Byte 0，Byte1；
Control Bit Vector(CBV)：默认是Byte 1，不过也可通过参数UDPNM_PDU_CBV_POSITION来决定，可以选择Byte0，Byte1；
整个NM报文的长度不应超过底层传输层的MTU(Maximum Transmission Unit);

对于CBV域对于整个网络管理状态机控制也十分关键，因此也有必要再进一步解析下其中每一个bit的具体含义：

图6 UdpNm报文格式

如下图7所示解释了各CBV域各bit位所代表的具体含义：

图7 CBV域内各Bit含义说明

用户数据处理

如上图5所示，除去Byte0与Byte1，其他数据都可以作为User data来看待，可以通过函数接口UdpNm_SetUserData来设置NM报文中的User Data，也可以通过UdpNm_GetUserData接口来实现。

UdpNm局部网络管理功能(PNC)

局部网络管理的目的只有一个，就是降低不必要的通信消耗，节约能源，因此有必要了解基于UdpNm的局部网络管理功能。局部网络管理(Partial Networking Cluster, 简称PNC) 首先针对NM报文的接收与发送进行一个基本说明：

若配置参数UdpNmPnEnabled==FALSE，则UdpNm模块只会进行正常NM报文的接收，不会进行与PNC有关的处理；
若配置参数UdpNmPnEnabled==TRUE且NM报文中的PNI bit位为0，则UdpNm模块只会进行正常NM报文的接收，不会进行与PNC有关的处理；
若配置参数UdpNmPnEnabled==TRUE且NM报文中的PNI bit位为1, 则UdpNm模块不仅会进行正常NM报文的接收，同时还会进行与PNC有关的处理；
若配置参数UdpNmPnEnabled==TRUE，则UdpNm模块会在发送的NM报文中PNI bit位置1，对于局部网络管理，CBV是必须的；
若配置参数UdpNmPnEnabled==FALSE, 则UdpNm模块会在发送的NM报文中PNI bit位置0;

PDU过滤算法

NM PDU过滤算法是通过三配置参数UdpNmPnInfoOffset ，UdpNmPnInfoLength，UdpNmPnFilterMaskByte来共同决定是否存在PNC请求以及什么类型的PNC请求。

若UdpNmPnInfoOffset == 3 且 UdpNmPnInfoLength == 2，则意味着仅有Byte3 与Byte4包含PNC信息，每个Bit就代表一个PNC网络，如果对应的Bit为1，则意味着对应的PNC网络被请求，如果对应的bit为0，则代表不存在对应的PNC网络被请求。

通过参数UdpNmPnFilterMaskByte便可以决定Byte3与Byte4中哪些PNC中的bit位与本ECU有关，MaskByte中bit位对应为1代表本ECU与这个PNC有关，否则便无关，进而决定我是否需要做相应的PNC网络处理。

EIRA机制逻辑

对于需要根据内部或者外部PNC请求来实现IPDU Group切换的ECU而言，那么就需要用EIRA特性，该特性能够根据接收到的PNC请求在ComM模块实现IPDU Group的切换。

EIRA全称为内部或者外部请求集合，用于收集ECU内外部PN请求。

如果参数UdpNmPnEiraCalcEnabled == TRUE, 无论是来自内部或者外部的PN请求，对应接收或者发送总线的PNC bit位将会置位；

对于EIRA机制逻辑而言，存在多少个EIRA Reset Timer完全取决于存在多少个PNC网络，因为EIRA对应的PDU Group切换对于ECU则是全局操作，与具体的物理通道无关。若只有8个PNC网络，却对应6个物理通道，那么也仅有8个PNC EIRA Reset Timer。

值得注意的事项如下：

是为了避免内部的PNC请求来不及发送至总线造成丢失，因此需要确保UdpNmPnResetTime务必要大于UdpNmMsgCycleTime，同时UdpNmPnResetTime需要小于UdpNmTimeoutTime，防止当NM状态切换至Prepare Bus Sleep阶段PNC Reset Timer失效；
若参数UdpNmPnEiraCalcEnabled == TRUE，对应的PNC请求变化将会通过UdpNm调用函数接口PduR_UdpNmRxIndication将EIRA信息传输至COM模块，COM则会同步传递至ComM模块，最终完成IPDU Group的切换；
若UdpNmPnEiraCalcEnabled == TRUE 且UdpNmPnEraCalcEnabled == TRUE, 对应的PNC信息将会各自进行存储。

ERA机制逻辑

ERA相比EIRA而言，少了内部请求，因为该机制主要用于外部PNC请求，即用于外部PNC请求的收集与其他通道的PNC的转发，主要面向网关节点。

若存在子网关，则特别需要注意接收到的PNC Gateway请求不能直接映射发送回去，否则就会造成主网关与子网关都无法休眠。为解决这个问题，AUTOSAR引入了Active PNC Gateway与Passive PNC Gateway概念，对于Passive PNC Gateway而言就不会将接收到的对应PNC Gateway请求直接映射发送出去。

若参数UdpNmPnEraCalcEnabled == TRUE, 且接收到的NM报文中PNC bit位置位时，将会进行后续的PNC网络处理，如转发至其他物理通道，因此每个通道需要管理所有PNC网络的状态。

对于存在8个PNC网络，且对应6个物理通道而言，ERA Reset Timer则会有48个，因为对于子网关而言，接收到的PNC网络请求不能被映射发送回去，所以有必要监控每个PNC请求的物理通道来源。

其他的值得注意的事项与EIRA机制保持一致。