文章目录
前言
之前一直理解的诊断请求会维持网络，客户报问题说诊断请求不能快发Nm报文，但软件没改过，以前也没报过这个问题，本文梳理一下该问题报的是否合理
Autosar规范
标准Autosar CanNm状态机如下：
大家知道快发Nm报文是在Repeat Message State 状态下，正常ECU被动唤醒状态下，处于Ready Sleep State 状态下，不会发送Nm报文
由上图Nm状态机可以看到，当Nm处于Network Mode 时，如果CanNmPnHandleMultipleNetworkRequests 配置为True时（上图红框1），调用CanNm_NetworkRequest() ;函数会重新进入RMS状态,此时就可以快发Nm报文了。如果CanNmPnHandleMultipleNetworkRequests 配置为False，同时Nm处于Network Mode-RSS时（上图红框2），调用CanNm_NetworkRequest() ;函数，Nm状态会跳转到Normal Operation State ，此时Nm报文正常慢周期发送（如1s）,也就不会有快发报文
对应的Autosar标准需求如下：
细心的同学应该发现了，从RSS到RMS还可以通过调用CanNm_RepeatMessageRequest 函数实现，那为什么诊断不是通过调用该函数实现快发的呢？之前介绍过诊断请求网络的实现，参考：Autosar Dcm开发-诊断报文请求网络管理报文的实现方法-基于ETAS软件
请求网络最终由ComM_DCM_ActiveDiagnostic函数实现，Autosar ComM中有如下需求：
可知诊断请求最终由Nm_NetworkRequest实现，对于Can网络来说，也就是CanNm_NetworkRequest实现。
同时，我查了下代码，项目中CanNm_RepeatMessageRequest实际没有用到，Nm在NOS或RSS状态下，外部调用这个函数可以主动进RMS，而诊断请求并不是通过该函数实现的。
问题分析
到此已经可以解释文章的问题了，到底能不能快发Nm报文取决于CanNm中的CanNmPnHandleMultipleNetworkRequests配置，配置为True才能快发Nm报文，否则不能快发Nm报文。
而客户需求中明确规定了CanNmPnHandleMultipleNetworkRequests需要配置为True，所以这个问题提的就是不合理的。
总结
Nm状态机这边只提了调用CanNm_NetworkRequest来触发快发报文，那诊断请求又是如何调用CanNm_NetworkRequest函数的呢？CanNmPnHandleMultipleNetworkRequests又是如何影响Nm状态机的呢？留着后面有空再整理吧~