从成本等角度考虑，汽车ECU中用于缓存诊断服务数据的buffer大小有限，所以当我们需要读取或写入超过buffer大小的数据时，就无法简单地使用2E和22服务了，UDS据此定义了几个将大块数据写入或读出的服务，即数据下载和上传。
Upload Download functional unit总共定义了5个诊断服务，分别是：
RequestDownload （0x34）：客户端向服务器请求下载数据
RequestUpload （0x35）客户端向服务器请求上传数据
TransferData（0x36） 客户端向服务器传数据（下载），或者服务器向客户端传数据（上传）
RequestTransferExit（0x37）数据传输完成，请求退出
RequestFileTransfer（0x38） 传输文件的操作，可以用于替代上传下载的服务。
下图是数据下载的简略过程，用到了34，36，37这三个服务，如果是上传的话，34服务被35服务替换，数据传输方向变一下，就可以了。
RequestDownload （0x34）：
0x34服务用于启动下载传输，作用是告知ECU准备接受数据，ECU则通过0x74 response告诉诊断仪自己是否允许传输，以及自己的接受能力是多大。
0x34服务的请求格式包括5个部分
第一部分：1个byte的SID
第二部分：1个byte的dataFormatIdentifier，这里面标识了数据格式相关的信息，比如数据是否有压缩，是否有加密，用的什么算法加密等，应该由主机厂与供应商约定好，用哪个bit来表示压缩、加密等信息。
第三部分：1个字节的addressAndLengthFormatIdentifier，用于指示后面两个部分所占用的字节，高4bit表示memorySize所占的字节长度，低4bit表示memoryAddress
所占的字节长度。在这个例子中我将这两个值分别设置为n和m。
第四部分：m个字节的memoryAddress，由addressAndLengthFormatIdentifier中的低4bit指示。含义是要写入数据在ECU中的逻辑地址。
第五部分：n个字节的memorySize，由addressAndLengthFormatIdentifier中的高4bit指示。含义是要写入数据的字节数。
ECU收到请求之后，如果允许传输的话，会给出如下response
第一部分：1个byte的 Response SID
第二部分：1个byte的dataFormatIdentifier作为echo
第三部分：maxNumberOfBlockLength，长度不定，表示可以通过0x36服务一次传输的最大数据量。
ransferData（0x36）：
如果34服务得到了正确响应，tester就要启动数据传输过程了，使用的就是36服务。36服务的格式如下。
第一部分：1个byte的 SID
第二部分：1个byte的blockSequenceCounter，标识当前传输的是第几个数据块，或者简单地说就是第几次调用36服务。
第三部分：transferRequestParameterRecord，传输的数据。第次传输数据量的上限就是34服务响应中的maxNumberOfBlockLength。
举例：如果ECU告知tester,maxNumberOfBlockLength = 20，也就是说tester每次通过36服务只能发送最多20个字节，其中还包括了SID和blockSequenceCounter，所以实际上每次可传的数据信息只有18个字节。如果tester要传的数据为50个字节，则需要传输三次，每次分别传输18，18，14个字节，即调用3次36服务。
36的响应很简单，就是一个字节的Response SID再加一个字节的blockSequenceCounter作为echo。
RequestTransferExit（0x37）：
37服务用于退出上传下载，如果之前的34和36服务都顺利执行完成，那么37服务就可以得到ECU的positive response。
格式很简单，请求就是37，正确响应就是77，都是一个字节。
如果前面的36服务没有执行完成，以我前面举的例子来说，比如这个数据块有50个字节，但是tester只发了两次36服务传了36个字节，那么这次传输对于ECU来说是失败的，所以ECU应该给出NRC 0x7F 37 24，表示诊断序列执行有错误。
车载网络总线管理的目的是使网络中的ECU节点有序地睡眠和唤醒，在没有通信需求的时候睡眠，可以节约电池的能量。
CAN总线上的网络管理，是一种无中心式的网络管理，网络中的每个节点都依赖于自己和别人的网络管理报文（NM PDU）来实现通信的睡眠和唤醒，这个NM PDU是周期性发送的，对于每个ECU来说，收到别的ECU发送的NM PDU则意味着当前的网络有通信需求，自己发出NM PDU则是告知别的ECU自己有通信需求。如果某个ECU打算进入Bus-Sleep-Mode，它就会通止发送NM PDU，在进入Bus-Sleep-Mode之前会有一段延时，如果在这段延时中没有收到任何NM PDU，则它就会转入Bus-Sleep-Mode状态了。
CAN NM为ECU的网络管理定义了三种模式（Mode）：
Bus-Sleep Mode
Prepare Bus-Sleep Mode
Network Mode
最后的Network Mode又分为三个状态（state），
Repeat Message State
Normal Operation State
Ready Sleep State
CAN总线上的网络管理的核心，就是ECU在这3种模式和3个状态之间的转换的状态机。
Bus-Sleep Mode
Prepare Bus-Sleep Mode
Network Mode
最后的Network Mode又分为三个状态（state），
Repeat Message State
Normal Operation State
Ready Sleep State
CAN总线上的网络管理的核心，就是ECU在这3种模式和3个状态之间的转换的状态机。
跟着状态机走一遍，就会对这个过程有比较直观的了解了。
ECU最初处于Bus-Sleep Mode中，当它有了通信需求（比如接收其他ECU的NM报文，或者它的逻辑功能要求自己唤醒，比如车门控制器收到了遥控钥匙的信号），它就会进入Network Mode，Repeat Message状态是Network Mode的入口状态，到达这个状态之后，ECU会启动一个Repeat Message Timer，在这个Timer定义的时间内，ECU会一直处于Repeat Message状态。当这个timer结束后，如果有通信需求，ECU则进入Normal Operation状态，如果没有通信需求，则进入Ready Sleep 状态。Normal Operation状态就是ECU正常运行的状态，此时它的应用报文和NM报文都会正常收发。当ECU没有通信需求，它会瞬间进入Ready Sleep状态，在Ready Sleep中，如果又出现了通信需求，ECU则瞬间再回复到Normal Operation，如果在一个Timeout Timer中一直没有通信需求，ECU就进入Prepare Bus-Sleep Mode，在Prepare Bus-Sleep状态中，也会启动一个Timeout Timer，如果在这段时间内有了通信需求，ECU又会立即回到Repeat Message状态，如果过了这个timer还没有通信需求，则ECU会回到Bus-Sleep Mode中。
综上所述，ECU网络管理的实现的核心就是实现这个状态机，在AUTOSAR中，这些状态之间的跳变就是由AUTOSAR定义的各种接口函数实现的。
-
NM（网络管理）是用来做什么的；
大家知道，不管是传统的燃油车还是新能源车，车上都有各种各样的ECU，而所有这些ECU都是需要用电的，而车上的供电单元一般是蓄电池，因此蓄电池的电量是有限的，对于新能源车来说太耗电无疑会给电池的续航里程带来巨大影响，因此为了尽可能的省电，所以就提出了网络管理，也就是说网络管理一个最重要的作用就是为了省电。
那么网络管理是如何来实现省电的呢？我们知道车上的所有ECU之间会通过CAN通信、Flexray或以太网等进行相互通信连接在一起，那么网络管理就是通过在各个ECU的网络上，发送一些命令制定一套规则，来实现各个ECU的协同睡眠和唤醒。
什么是ECU的睡眠和唤醒？为了支持睡眠和唤醒，ECU的芯片必须支持低功耗模式和正常工作模式的切换。低功耗模式（ECU睡眠）指一个ECU断电或者处于极少数的外围器件工作的模式；唤醒指的是ECU处于全工作模式。
举个例子来说，也许你看过特斯拉的车门，它的门把手是和门平齐的，只有你带着车钥匙靠近时，它的门把手才会张开，其实这就是在唤醒了车门控制器，也就是说你把车停在那里时，实际上车门控制器是在睡眠状态，耗电量极地，而你带着车钥匙靠近了，表示你要用车了，他就会通过无线感应模块来唤醒车门，这样你就可以正常打开车门了，这个时候车门控制器ECU就处于唤醒状态。
总结下：其实网络管理就是用来节约能源，有效的实现车上的ECU的协同睡眠和唤醒。 -
AutoSar中网络管理的原理；
以下，我会以用的比较多的CAN网络管理为例来进行说明，我会主要围绕其中最重要的一个状态机来进行介绍。
首先我们讲一讲，为了实现网络管理，我们要考虑些什么因素，也就是有哪些需求。
网络管理最终要实现的是车上的ECU能够协同睡眠以及唤醒，也就是说网络管理最重要的一点是要保证车上的ECU能够协同唤醒和休眠。那么假如车上的ECU都处于睡眠模式，网络上都没有报文，你咋实现唤醒呢，其实，一般不会让所有的ECU都处于睡眠模式，这个时候可能会有极少的ECU处于工作状态，比如车上的BCM。也就是说有一些ECU是通过KL15直接唤醒的，而有些是通过CAN报文唤醒。当然或许后面会升级到更加节能的模块，可以不需要钥匙信号，这些模块在睡眠状态时，耗能非常少，因此可以一直处于可唤醒状态。
为了满足这种协同唤醒和睡眠，我们下面来看看Autosar中的NM是如何实现协同的。
如图所示，状态机中有三个主状态，分别是BusSleep、PreSleep、Network三个状态；其中Network状态又分为三个子状态，分别是RepeatMsg、NormalOperate、ReadSleep。下面我来讲一下每个状态它的作用。
BusSpleep状态：这个状态就是我们所说的休眠状态，这个状态下是不发送网络管理报文也不收发应用报文，一般该状态时一个低功耗的状态，也就是我们上文提到的协同睡眠状态。当然我们上电初始化时，也会默认进入该状态。
PreSleep状态：这个状态是进入休眠状态的前一准备状态，这个状态一般不发送网络管理报文帧了，也不发送应用报文了，只是等待其他ECU一起睡眠，为啥要这个状态呢，其实就是实现‘’协同‘’两个字，也就是让等一段时间让车上所有ECU实现一起睡眠，其实这个一起睡眠还是比较重要的，比如车上某个ECU的工作与其他ECU的工作是关联的，比如VCU（整车控制器）和INV（电机控制器），有可能VCU不发报文了，会导致INV报故障，因此这种情况是要避免的。
Network状态：这个状态是允许ECU进行正常通信的，一般这个状态下即可以收发网络管理报文帧也可以收发应用报文（包括诊断报文），意思就是唤醒状态。接下来我来解释一下这个状态下里面的三个子状态的含义：
Repeat meassage：表示重复发网络管理报文的状态。首先说说这个状态下会发生什么事，一般我们进入网络（Network）状态时，首先会进入这个状态，这个状态下会快速的发送一些网络管理报文帧出来，为啥要快速发送一些网络管理报文呢？其实就是想尽快的告诉车上的其他ECU，我上线了！我要正常通信了，大家请注意啊，大家也和我一块进行整车通信啊。就是以上这个意思。
Normal Operation：在进入RepeatMsg一段一时间后，如果需要通信，就会跳到正常工作状态，正常工作状态会按照正常的周期发送网络管理报文，以及所有应用报文正常进行通信，可以说这个状态就是真正的唤醒状态。
ReadySleep：如果唤醒后，需要休眠，那么我们可能需要做一些准备工作才能允许我们的ECU进入休眠，比如这个时候有一些数据要存储、比如电机控制器检测到电机还没停下来等等情况，因此这个状态就是用来做一些休眠前的准备工作，我们可以看到，任何从唤醒到休眠的过程，都需要经过这个状态，也就是说睡眠前有些准备工作是必须要完成的。那么这个状态下，其实还是能够进行通信的，只有进入PreSleep状态，才会把相应的应用报文收发关闭，以及发送NM报文关闭。还有一点要声明的是，一般网络管理报文帧的接收不会关闭。
其实，网络管理中，各个状态的切换条件是比较重要的，有兴趣的可以看着图进行钻研一下。
作者：AgingMoon
来源：CSDN
原文：https://blog.csdn.net/agingmoon/article/details/77826995
版权声明：本文为博主原创文章，转载请附上博文链接！