UDS在网络传输层的实现 I ——网络传输层的协议
UDS在应用层和会话层的时序（enhanced diag）
Overview
没有罗列很多参数，但求尽可能清楚的讲解15765-2的实现，其余具体一些参数，大家可以自行查找。
15765-2在网络传输层协议中主要做了两件事：
-
使收发的数据量达到了4095个字节，
-
汇报接收端或者发送端是当前动作（收或者发）是完成了，还是失败了。
帧格式PDU
发送帧的格式为：
主要为三部分，（PDU=AI+PCI+Data, 至于N_就是网络层。）
地址信息 AI，无论发送给谁，还是从谁那里接收，都需要地址信息才能发送协议控制信息 PCI，就是本文需要用到的，怎么发，要发多少数据量，PCI会告诉你数据信息 Data
数据发送
根据传输数据量的大小，主要分为了单帧和多帧传输：
单帧传输 （SF（single frame） transmission）
数据量为6个字节（当扩展寻址或者混合寻址（extended addressing or mixed addressing）的时候）
数据量为7个字节（当正常寻址（normal addressing）的时候）
地址信息，CAN ID厂商都会给好了，PCI 按上面的来，SF_DL就是告诉客户端，我需要发给你多少数据量，然后，带上事先准备好的数据，PDU也就准备好了， 直接传就好了。
Note：如果遇到以下情况，这些SF都会被忽略：
a. SF_DL=0
b. SF_DL > 7，normal addressing
c. SF_DL > 6, extended addressing or mixed addressing
多帧传输（FF FC CF）
当数据量大于6或者7个字节时，就需要进行多帧传输 ，如下图：
首先，客户端发送请求命令，
然后服务器端发送第一帧（FF First Frame） ，同样的先告诉客户端，我要发你多少字节，
Note: 同样的，如果FF_DL超出了客户端实际能接收到数据量，那接收到的消息都会被丢弃，并且发出的流控FC的参数FlowStatus=Overflow，如果第一帧像单帧一样少于对应寻址的数据量，FF帧就会被丢弃，也不会发流控。
客户端收到FF之后，就会发送流控帧(FC Flow Control)，告诉服务器端，你要以一个Block Size（BS）多少帧的数量（假如BS=0，就是把剩下的帧全发出来，否则就是按照流控的指示，先发多少来，等会我再给你命令，你再按要求发，直到发完为止。），每帧间隔STmin多长时间发送给我，并且告诉服务器端当前我的这边的情况Flow Status(FS),我是要你继续发CTS还是要你等Wait还是我这边已经溢出了Overflow。
Note:
- 假如FS是无效的状态，比如reserved，那整条消息的传输会被丢弃，confirm中的N_Result=N_INVALID_FS发给上层。
- 假如STmin的值也不是15765中定义的，那他的值就按照定义的最大值127ms来算。
假如没有啥问题，让继续发CTS，那么，服务器端就开始按着客户端的要求开始发连续帧（CF Consecutive Frame）了
SN就是每帧的***SequenceNumber，连续帧编号从1到F，然后又滚回1到F循环往复。
Note: 如果发来的某帧SN错了，那这整条消息都会丢弃，并且向上一层回复indication中的N_Result=N_WRONG_SN
N_WFTmax
最后的最后，假如在发送过程中出现了错误，为了防止发送方卡死在那，接收方不知所措等待，那接收方就同个发送FC.wait帧来告诉发送我，我可以等你，但不是等到海枯石烂，我最多等N_WFTmax个FC.wait帧的时间，我就不等了，这个参数其实也参与了流控FC的过程，但是只是通信的两者间做出的约定，所以并不出现在FC帧中。
N_WFTmax只用在接收网络实体中，如果N_WFTmax=0，那FC就要依赖CTS来继续发送，而不能用WT来等待。
网络层时序参数
上文，15765-2规定了，我要怎么发给你，你要怎么控制我，我们一来二去的，要有礼貌。那遇到一个疯子跟他说话，他不理我，可不行，就要在每个动作中间规定好时序，有一环超时掉了链子，就跪。
Indication和Confirm，一来用来标记时序的区间，一来假如超时了还可以用N_Result返回发送的结果。
错误处理
-
上文讲了很多错误的情况，需要丢弃帧；
-
收到意外帧的时候，也需要丢弃；（意外帧就是不按多帧套路发送过来帧，或者未知CAN ID的一帧等等无法解析的帧）
-
接收方发送了N_WFTmax FC之后，而还是不能发送FC NPDU CTS，那接收方刚收到的消息都得丢弃
这个丢弃的意思就是，不要了并且不会通知上层我收到帧了。