导言

这份 NM 源码来自 ISOLAR 工程整理结果，主体是 CanNm 协议栈模块。其他目录和文件主要是为了让 CanNm 能够按当前工程需要完成编译、联调或移植而集成进来的支撑接口。

从源码结构上看，这套工程的分析重点应该放在 CanNm 目录。它负责 CAN 网络管理报文的收发、网络状态维护、状态机切换、定时器处理以及和上层 Nm 模块之间的接口交互。

1. 顶层目录结构

当前源码的顶层结构如下：

NM└── NM    ├── CanNm    │   ├── api    │   ├── src    │   └── integration    └── Integration        ├── ComStack        ├── Nm_Integeration        ├── Platform        └── Standard

整体可以分成两大部分：

• • CanNm：CAN Network Management 模块本体，是这份协议栈源码的主体。
• • Integration：按工程需要集成的外部依赖、基础类型、桩函数和适配文件。

如果用 AUTOSAR 模块关系来理解，CanNm 是本文要分析的主体模块，但它不能完全脱离上下游接口运行。它上面会和 Nm、ComM 交互，下面会和 CanIf、CanSM、PduR 等模块交互，同时还依赖 Det、SchM、Std_Types、ComStack_Types 等基础服务。当前工程中这些模块并不是分析重点，而是根据 CanNm 移植和联调需要补进来的支撑部分。

2. CanNm：源码分析的核心目录

CanNm 是这套源码中最重要的目录，对应 AUTOSAR 里的 CAN Network Management 模块。它的核心职责是通过 CAN NM 报文维护网络管理状态，实现网络请求、网络释放、Repeat Message、Ready Sleep、Prepare Bus Sleep、Bus Sleep 等状态流转。

目录结构如下：

CanNm├── api├── src└── integration

2.1 CanNm/api：对外接口声明

api 目录主要存放 CanNm 对外暴露的头文件。

主要文件包括：

CanNm.hCanNm_Cbk.hCanNm_Inl.h

其中 CanNm.h 是最重要的公开接口文件，里面声明了 CanNm 的标准 API，例如：

CanNm_InitCanNm_PassiveStartUpCanNm_NetworkRequestCanNm_NetworkReleaseCanNm_DisableCommunicationCanNm_EnableCommunicationCanNm_SetUserDataCanNm_GetUserDataCanNm_GetNodeIdentifierCanNm_GetLocalNodeIdentifierCanNm_GetPduDataCanNm_GetStateCanNm_RepeatMessageRequestCanNm_TransmitCanNm_TriggerTransmitCanNm_RxIndicationCanNm_TxConfirmationCanNm_MainFunction

从这些 API 可以看出，CanNm 的功能大致可以分成几类：

• • 初始化与版本信息。
• • 网络请求与网络释放。
• • 通信使能与禁止。
• • UserData 读写。
• • 节点 ID 和 PDU 数据获取。
• • 状态查询。
• • NM 报文发送、接收、发送确认。
• • 周期主函数调度。

CanNm_Cbk.h 主要和回调接口相关。CanNm 作为通信栈中的模块，会被下层模块通知报文接收、发送确认等事件，因此需要单独定义 callback 类接口。

CanNm_Inl.h 文件体积较大，里面包含大量内部 inline 函数。虽然它放在 api 目录下，但从用途上看，它更接近 CanNm 内部逻辑的一部分。后续分析状态机和定时器时，这个文件需要重点关注。

2.2 CanNm/src：模块实现主体

src 是 CanNm 的真正实现目录，也是后续源码分析的重点。

这个目录中的文件命名非常清晰，基本上一个 API 或一个功能点对应一个 .c 文件，例如：

CanNm.cCanNm_Init.cCanNm_NetworkRequest.cCanNm_NetworkRelease.cCanNm_PassiveStartup.cCanNm_ChangeState.cCanNm_RxIndication.cCanNm_TxConfirmation.cCanNm_TriggerTransmit.cCanNm_Transmit.cCanNm_SetUserData.cCanNm_GetUserData.cCanNm_GetState.cCanNm_GetPduData.cCanNm_CheckRemoteSleepIndication.cCanNm_ConfirmPnAvailability.c

其中 CanNm.c 是主流程文件，里面实现了 CanNm_MainFunction。

CanNm_MainFunction 是 CanNm 的周期调度入口。它会遍历所有配置的 NM channel，然后调用内部处理函数执行状态机逻辑。可以把它理解成整个 CanNm 模块的主循环。

主流程大致包括：

• • 判断 CanNm 是否已经初始化。
• • 遍历所有配置的 channel。
• • 处理 RxIndication 标志。
• • 处理 TxConfirmation 标志。
• • 更新软件定时器。
• • 根据当前 NM mode 和 state 执行状态机。
• • 处理 ERA/EIRA、PN 等扩展逻辑。

CanNm_Prv.h 是内部私有头文件，里面定义了大量内部宏、DET 错误检查宏、状态机辅助宏、配置访问宏和内部数据类型。它是理解 CanNm 内部实现风格的关键文件。

配置相关文件包括：

CanNm_Cfg.cCanNm_Cfg.hCanNm_Cfg_Internal.hCanNm_PBcfg.cCanNm_PBcfg.h

这些文件负责描述 CanNm 的通道数量、PDU 长度、定时参数、功能开关、Post-Build 配置等。

AUTOSAR BSW 模块通常不是把所有逻辑写死在代码中，而是通过大量配置项裁剪功能。因此分析 CanNm 时，不能只看 .c 文件，还必须结合配置文件一起看。

2.3 CanNm/integration：CanNm 自身集成适配

CanNm/integration 目录存放 CanNm 模块自身相关的集成文件。

主要文件包括：

CanNmAppl.cCanNmSetDynamicNodeId.cCanNmSetDynamicNodeId.hCanNm_Cfg_SchM.h

CanNm_Cfg_SchM.h 和 SchM 临界区相关，用于保护 CanNm 内部共享数据访问。

在 CanNm_MainFunction 中可以看到类似下面的临界区调用：

SchM_Enter_CanNm_MainFunctionNoNest();SchM_Exit_CanNm_MainFunctionNoNest();

这说明 CanNm 在处理接收标志、发送确认标志、控制位等共享数据时，需要考虑中断上下文和主函数上下文之间的并发访问。

CanNmAppl.c 更偏应用层适配，通常用于放用户扩展、应用回调或项目集成时需要补充的函数。

CanNmSetDynamicNodeId.c 从命名看是动态设置 Node ID 的功能适配文件，属于具体项目中可能会使用的扩展能力。

3. Integration：外部依赖与集成桩

Integration 目录不是协议栈主体，也不是本文的核心分析对象。它是为了让 CanNm 能够在当前工程中运行、编译或分析而按需集成的外部模块接口。

CanNm 作为 AUTOSAR BSW 模块，依赖很多其他模块，例如：

• • Nm
• • ComM
• • CanIf
• • CanSM
• • PduR
• • Det
• • SchM
• • Std_Types
• • ComStack_Types
• • Platform_Types

在真实 AUTOSAR 工程中，这些依赖由其他 BSW 模块提供。当前源码中的 Integration 目录则提供了这些模块的头文件、类型定义或简化桩函数。

3.1 Integration/ComStack：通信栈通用类型

ComStack 目录中主要包含：

ComStack_Cfg.hapi/ComStack_Types.h

这里定义通信栈常用类型，例如：

PduIdTypePduInfoTypeNetworkHandleType

CanNm 的收发接口都依赖这些类型，例如：

CanNm_Transmit(PduIdType CanNmTxPduId, const PduInfoType * PduInfoPtr)CanNm_TriggerTransmit(PduIdType TxPduId, PduInfoType* PduInfoPtr)

因此，ComStack 是理解 CanNm 报文收发接口的基础。

3.2 Integration/Standard：AUTOSAR 标准基础类型

Standard 目录中主要是：

Std_Types.h

这里定义 AUTOSAR 标准类型和返回值，例如：

Std_ReturnTypeE_OKE_NOT_OKStd_VersionInfoType

这些是所有 BSW 模块都会使用的基础定义。

3.3 Integration/Platform：平台相关类型

Platform 目录中包含：

Platform_Types.hapi/Platform_AddOn_Types.hintegration/Platform_Types_Cfg.h

这里定义平台相关的基础数据类型，例如：

uint8uint16uint32boolean

AUTOSAR 为了保证跨编译器、跨芯片平台的一致性，会统一封装基础类型。因此 CanNm 代码中不会直接大量使用 C 标准类型，而是使用 AUTOSAR 风格类型。

3.4 Integration/Nm_Integeration：Nm 模块适配

目录中包含：

CanNm_Interface.cCanNm_MemMap.hCanSM_TxTimeoutException.hNm.cNm.hNmStack_Types.hNm_Cbk.hSchM_CanNm.h

这部分非常重要，因为 CanNm 是总线相关 NM 模块，而 Nm 是网络管理抽象层。

可以简单理解为：

• • Nm 向上对 ComM 或应用层提供统一 NM 接口。
• • CanNm 向下负责 CAN 总线上的 NM 报文和状态机。
• • Nm 和 CanNm 之间通过接口和回调连接。

当前 Nm.c 中已经实现了一些回调函数，例如：

Nm_NetworkStartIndicationNm_RepeatMessageIndicationNm_NetworkModeNm_StateChangeNotificationNm_PrepareBusSleepModeNm_BusSleepModeNm_TxTimeoutExceptionNm_PduRxIndication

其中 Nm_StateChangeNotification 里还调用了 CanNm_SetUserData，根据当前状态设置 NM UserData 中的 RMS 标志位。这说明这份源码不仅是纯 CanNm 标准实现，还带了一点项目应用逻辑。

3.5 ComM 相关文件：通信管理模块接口

Integration 顶层还有一些 ComM 相关文件：

ComM.hComM_BusSM.hComM_Interface.cComM_Types.h

ComM 是 AUTOSAR Communication Manager，用于管理通信请求。

在完整 AUTOSAR 架构中，应用或 SWC 通常不会直接控制总线通信，而是通过 ComM 请求通信模式。ComM 再和 Nm、BusSM 等模块交互，最终影响 CanNm 的网络请求和释放。

当前这些文件更像是简化版接口或桩文件，主要用于满足 CanNm 的编译和接口依赖。

3.6 Det：开发错误检测

Integration 中包含：

Det.cDet.h

Det 是 AUTOSAR Development Error Tracer。CanNm 里大量使用 DET 宏做参数检查、初始化状态检查、通道合法性检查等。

例如在 CanNm_Prv.h 中可以看到类似错误上报宏：

CANNM_DET_REPORT_ERRORCANNM_DET_REPORT_ERROR_NOK

当开发错误检测开关打开时，这类宏会调用 Det_ReportError 上报错误。

4. 这套源码体现出的模块关系

从目录和文件命名可以看出，这份源码大致符合下面的 AUTOSAR NM 调用关系：

其中：

• • ComM 负责通信模式管理。
• • Nm 负责网络管理抽象。
• • CanNm 负责 CAN 总线上的网络管理实现。
• • CanIf 负责 CAN 接口抽象。
• • CAN Driver 负责底层硬件发送和接收。

这份源码的主体是 CanNm。Nm、ComM、基础类型、开发错误检测等文件属于按需集成的支撑部分，主要用于体现 CanNm 的上下游接口边界。

5. CanNm 对 CanIf 的依赖

如果要把当前 CanNm 模块移植进自己的工程，最先要确认的不是状态机，而是 CanNm 和 CanIf 之间的接口边界。

从当前源码看，CanNm 对 CanIf 的直接依赖可以分成两类：

• • CanNm 主动调用 CanIf 的 API。
• • CanIf 反向调用 CanNm 的 callback。

5.1 CanNm 主动调用的 CanIf API

当前源码中，CanNm 直接调用 CanIf 的核心 API 是：

Std_ReturnType CanIf_Transmit(PduIdType TxPduId, const PduInfoType * PduInfoPtr);

调用位置在 CanNm_Inl.h 的 CanNm_MessageTransmit 中：

RetValOfFuncs_ui = CanIf_Transmit(ConfigPtr_pcs->TxPduId, &(RamPtr_ps->Pdu_s));

这个函数是 CanNm 发 NM PDU 的统一出口。也就是说，不管是周期发送、主动网络请求、总线同步请求，还是带 UserData 的触发发送，最终都会走到 CanNm_MessageTransmit，再由它调用 CanIf_Transmit。

当前源码中调用 CanNm_MessageTransmit 的典型位置包括：

• • CanNm.c：周期主函数中发送 NM PDU。
• • CanNm_RequestBusSynchronization.c：请求总线同步时触发单帧发送。
• • CanNm_SetSleepReadyBit.c：设置 Coordinator Sleep Ready Bit 后触发发送。
• • CanNm_Transmit.c：PduR 触发带 UserData 的 NM PDU 发送。

因此移植时，CanIf 至少要提供 CanIf_Transmit，并且它的行为要满足下面几点：

• • 入参 TxPduId 能映射到实际 CAN NM 报文。
• • 入参 PduInfoPtr->SduDataPtr 指向 CanNm 内部维护的发送 buffer。
• • 入参 PduInfoPtr->SduLength 是 NM PDU 长度，需要和项目 CanIf 配置一致。
• • 返回 E_OK 表示 CanIf 已接受发送请求。
• • 返回 E_NOT_OK 表示发送请求未被接受，CanNm 会停止本次发送超时监控，等待后续周期重试或由上层再次触发。

移植到新工程时，ConfigPtr_pcs->TxPduId 必须和 CanIf 里的 Tx L-PDU 配置一致，否则 CanNm 即使运行正常，也无法把 NM 报文发到正确的 CAN ID 上。

这里还可以顺带注意一个源码注释里的拼写问题：CanNm_Inl.h 中 CanNm_MessageTransmit 的说明写成了 CanIf_Tranmsit，正确拼写应为 CanIf_Transmit。源码实际调用的函数名是正确的：

CanIf_Transmit(ConfigPtr_pcs->TxPduId, &(RamPtr_ps->Pdu_s));

5.2 CanIf 需要回调 CanNm 的接口

CanNm 不只是调用 CanIf。CanIf 收到 NM 报文或发送完成后，也必须回调 CanNm。

这些回调在 CanNm_Cbk.h 中声明：

void CanNm_RxIndication(PduIdType RxPduId, const PduInfoType * PduInfoPtr);void CanNm_TxConfirmation(PduIdType TxPduId, Std_ReturnType result);

其中 CanNm_RxIndication 用于接收 NM 报文。

当 CanIf 收到配置给 CanNm 的 NM Rx PDU 后，需要把接收到的数据封装成 PduInfoType，然后调用：

CanNm_RxIndication(RxPduId, &PduInfo);

当前源码里 Integration/Nm_Integeration/CanNm_Interface.c 已经给了一个简化适配示例：

void CanNm_Indication(uint8_t index, uint32_t canid, uint8_t dlc, uint8_t* data_ptr){    PduInfoType Pdu;    Pdu.SduDataPtr = data_ptr;    Pdu.SduLength = dlc;    CanNm_RxIndication(0, &Pdu);}

这个例子里直接把 RxPduId 写成了 0。真实工程中不建议这样写死，而是应该根据 CAN ID 或 CanIf Rx PDU ID 映射到对应的 CanNm channel。

CanNm_TxConfirmation 用于发送确认。

当 CanIf 确认某个 NM Tx PDU 已经发送完成后，需要调用：

CanNm_TxConfirmation(TxPduId, E_OK);

CanNm 内部会设置 TxConfirmation_b，主函数后续会根据这个标志处理发送状态、超时监控和状态机推进。

5.3 TriggerTransmit 接口

当前源码还实现了：

Std_ReturnType CanNm_TriggerTransmit(PduIdType TxPduId, PduInfoType* PduInfoPtr);

这个接口不是 CanNm 主动调用 CanIf 的 API，而是给下层模块在 TriggerTransmit 机制下反向取数使用的。

移植时只需要确认目标工程是否使用 TriggerTransmit。如果使用，需要在 CanIf 配置中把对应 Tx PDU 配成触发发送模式，并确保 CanIf 在需要数据时调用 CanNm_TriggerTransmit；如果不使用，则主发送路径仍然是 CanNm 准备好 PduInfoType 后调用 CanIf_Transmit。

6. 当前 CanNm 模块如何移植进工程

移植这套 CanNm 源码时，可以按下面顺序处理。核心思路是先让基础类型和配置能编译，再接 CanIf 收发，最后接 Nm/ComM 的上层流程。

6.1 准备基础头文件和类型

CanNm 依赖 AUTOSAR 风格的基础类型，至少需要保证下面这些文件或等价定义可用：

Std_Types.hPlatform_Types.hComStack_Types.hNmStack_Types.h

这些文件提供：

• • uint8、uint16、uint32、boolean
• • Std_ReturnType
• • E_OK、E_NOT_OK
• • PduIdType
• • PduInfoType
• • NetworkHandleType
• • Nm_StateType
• • Nm_ModeType

如果目标工程已经有 AUTOSAR 基础类型文件，优先使用工程已有版本，不建议重复引入两套 Std_Types.h 或 Platform_Types.h，否则很容易出现类型重复定义。

6.2 移植 CanNm 源码和配置

需要纳入工程的 CanNm 文件主要包括：

CanNm/api/*.hCanNm/src/*.cCanNm/src/*.hCanNm/integration/CanNm_Cfg_SchM.hCanNm/integration/CanNmAppl.cCanNm/integration/CanNmSetDynamicNodeId.c

配置文件重点是：

CanNm_Cfg.hCanNm_Cfg_Internal.hCanNm_Cfg.cCanNm_PBcfg.hCanNm_PBcfg.c

移植后要重点检查：

• • CANNM_NUMBER_OF_CHANNELS 是否和工程实际 CAN NM 通道数量一致。
• • PduLength_u8 是否和 NM 报文 DLC 一致。
• • NodeIdPos_u8 和 ControlBitVectorPos_u8 是否符合项目 NM PDU 格式。
• • TxPduId 是否和 CanIf 的 Tx PDU ID 一致。
• • MessageCycleTime、MsgTimeoutTime、RepeatMessageTime 等定时参数是否符合项目需求。
• • CANNM_PASSIVE_MODE_ENABLED、CANNM_USER_DATA_ENABLED、CANNM_COM_USER_DATA_SUPPORT、CANNM_GLOBAL_PN_SUPPORT 等功能开关是否符合目标工程。

6.3 对接 CanIf

这是移植中最关键的一步。

目标工程的 CanIf 至少要完成三件事：

第一，提供 CanIf_Transmit。

Std_ReturnType CanIf_Transmit(PduIdType TxPduId, const PduInfoType * PduInfoPtr);

这个函数要能根据 TxPduId 找到实际 CAN ID、CAN controller、DLC 和发送 mailbox，然后把 PduInfoPtr->SduDataPtr 中的 NM 数据发送出去。

第二，接收 NM 报文后调用 CanNm_RxIndication。

CanNm_RxIndication(RxPduId, &PduInfo);

这里的 RxPduId 应该是 CanNm 能识别的 channel 或映射后的 PDU ID。当前源码在 RxIndication 中会用它访问：

CanNm_RamData_s[RxPduId]CANNM_GET_CHANNEL_CONFIG(RxPduId)

所以这个 ID 不能随便传。单通道工程可以先用 0，多通道工程必须做明确映射。

第三，发送完成后调用 CanNm_TxConfirmation。

CanNm_TxConfirmation(TxPduId, E_OK);

同样，TxPduId 必须能映射到 CanNm channel。否则 CanNm 会找错 RAM 数据，轻则状态不推进，重则访问错误通道。

6.4 对接 Nm 和 ComM

当前源码中已经有简化的 Nm.c、Nm.h、ComM_Interface.c。如果目标工程有完整 AUTOSAR Nm 和 ComM，应优先使用工程已有模块。

如果目标工程没有完整 Nm/ComM，而只是希望先让 CanNm 跑起来，可以先保留当前这些集成桩：

Integration/Nm_Integeration/Nm.cIntegration/Nm_Integeration/Nm.hIntegration/Nm_Integeration/Nm_Cbk.hIntegration/ComM.hIntegration/ComM_Types.hIntegration/ComM_BusSM.hIntegration/ComM_Interface.c

但要注意，这些桩函数只能满足基础联调，不等价于完整 AUTOSAR ComM/Nm。

6.5 对接 SchM、Det 和 MemMap

CanNm 使用 SchM 保护临界区，例如：

SchM_Enter_CanNm_MainFunctionNoNest();SchM_Exit_CanNm_MainFunctionNoNest();

如果目标工程有 OS 或 SchM，应把这些宏接到真实的临界区保护。裸机工程中可以先接成关中断/开中断，或者在确认没有并发访问风险时临时做空实现。

Det 用于开发错误检测。调试阶段建议保留 Det_ReportError，这样参数错误、未初始化调用、PDU ID 错误会更容易定位。

CanNm_MemMap.h 用于 AUTOSAR 内存段映射。如果目标工程没有严格的 MemMap 机制，可以先做成空宏适配，但要保证所有 CANNM_START_SEC_* 和 CANNM_STOP_SEC_* 宏都能被正确包含和消解。

6.6 初始化和周期调度

移植完成后，启动流程至少应包含：

CanNm_Init(NULL);

如果工程使用 Pre-Compile 变体，初始化参数通常不承载实际配置；如果工程使用 Post-Build 变体，则必须传入有效配置。

运行时必须周期调用：

CanNm_MainFunction();

调用周期要和配置中的 CanNm 主函数周期匹配。CanNm 的状态机、定时器、周期发送、超时检测都依赖这个主函数推进。如果只初始化不周期调用，模块不会正常发送 NM 报文，也不会完成状态迁移。

6.7 最小移植检查清单

最小可运行版本可以按下面清单检查：

• • CanNm_Init 被调用，且配置指针正确。
• • CanNm_MainFunction 被周期调用。
• • CanIf_Transmit 能发送实际 CAN NM 报文。
• • CanIf 接收 NM 报文后能调用 CanNm_RxIndication。
• • CanIf 发送完成后能调用 CanNm_TxConfirmation。
• • TxPduId、RxPduId 和 CanNm channel 映射正确。
• • PduInfoType.SduDataPtr 和 SduLength 正确。
• • CanNm_Cfg 中的 PDU 长度、Node ID、CBV 位置和项目协议一致。
• • SchM 临界区、Det、MemMap 已完成适配。
• • 如果使用 UserData、PN 或 Com UserData，PduR 相关接口也要补齐。

7. 小结

这份 NM 源码的核心是 CanNm。其中：

• • api 定义对外接口。
• • src 实现模块逻辑。
• • integration 放 CanNm 自身集成文件。
• • 外层 Integration 目录提供 AUTOSAR 其他模块的依赖接口和基础类型。

从源码结构看，它是一份典型的 AUTOSAR CanNm 模块实现。后续分析时，应围绕三个关键词展开：

• • 配置。
• • 状态机。
• • 报文收发。

只要抓住这三条主线，CanNm 的源码就不会显得零散。后续文章可以从初始化开始，一步步进入 CanNm_MainFunction，再展开网络请求、状态迁移和 NM 报文收发流程。