CAN通信如果丢包会怎么样.docVIP

CAN通信如果丢包会怎么样？ 相对于车载以太网，汽车上的CAN网络是一种相当简单的网络协议。用OSI七层模型来解释CAN网络的话，物理层-数据链路层-网络层部分的工作通常由硬件来实现，而传输层-会话层-表示层-应用层部分通常使用软件实现。我们可以根据实现方式和完成功能，将CAN网络简单粗暴地划分为：物理链路层和软件协议层。 CAN网络模型 这是本人为了方便表述创造的说法，业界在讨论CAN网络时似乎并无此划分方式和专有名词。CAN网络的物理链路层，在实际应用场景中直接使用MCU内置的CAN控制器和硬件CAN收发器来实现；而软件协议层可以自行编写can协议软件或购买适配AutoSAR的CAN协议栈，通常是后者。 而且，CAN的网络架构里面不存在对应OSI模型网络层和传输层的功能。 STM32的CAN控制器说明 在讨论CAN通信丢包问题时，我们将使用上面定义的两层CAN网络模型进行分析。 我们知道，CAN通信协议在设计时以可靠性作为最主要的目标，所以CAN的物理链路层从原理上讲：不会发生丢包。这是怎么做到的呢？ 因为通信两端的CAN控制器和收发器时刻监视CAN线上的报文，发送者发送的每一个Bit都会被读回来比对是否发送正确，而且在正确发送之后接收者将在报文的ACK Bit做出应答，只要发现报文任一Bit错误，或者没有收到ACK，发送者的CAN控制器就会自动重发出错报文，直到该报文成功发送出去。只要有一条报文出错，CAN控制器就会不断重发该报文，甚至阻塞缓存中后续的CAN报文。 正因如此，我们可以说CAN的物理链路层只会通信断开，但是逻辑上认为它不会丢失报文。这个结论非常重要，直接影响了CAN软件协议层的设计。 逻辑上认为物理层不丢包，可是实际上呢？ CAN的物理设备实际上是会丢包的，这个不出奇，工程学没有绝对。但是实践中工程师都当做不会丢包来考虑。丢包之后，CAN物理设备会通过软硬件方式（中断、标志等）通知软件，但是软件不会处理丢包，通过周期发送的方式可以弥补偶然丢失的数据。 CAN报文结构图 CAN软件协议层在发送报文时只关心三件事，一件就是CAN报文是否成功传递给了物理链路层，如果传递成功就可以认为该报文已经发送成功。如果传递失败，通常原因是CAN控制器缓存满了或繁忙无响应等，软件协议层就稍等片刻再尝试。这里要注意的就是，因为默认物理链路层不会丢包，所以CAN网络没有从物理链路层通知软件协议层通信状态的反馈机制。也就是说，软件协议层没有办法判断自己的报文是否发送成功，只能绝对相信报文一定成功。 但是实际上，参与过车型开发的同学都知道，CAN网络偶然是会丢包的，负载率越高的CAN总线，丢包概率越大。数据包的丢失大概率发生在软件协议层，或软件协议层将数据发送给物理链路层的过程中。 为了解决软件协议层无法知道丢包的问题，软件协议层会关注通信过程中的第二个信息，那就是周期报文的周期。 我猜，CAN通信引入周期报文的出现也有一个典故。CAN协议设计者最开始的目标是想让CAN网络协议即简单又可靠，但是实践中发现已经建成的机制根本就保证不了不丢包，所以就大量引入周期报文进入通信过程中，即使偶然丢了一两个数据包也影响不大。所以软件协议层会检查收到的报文的周期是否正确，如果多个周期都没有收到某个周期报文，就可以判断发生了报文丢失，同时CAN报文通常和控制器功能相互绑定，通过CAN报文丢失甚至可以判断某个控制器发生了“掉线”或者“故障”。 借助周期报文的力量，虽然发送者不知道发送的报文丢失了，但是接收者知道自己错过了本应收到的报文。接收者发现自己错过了报文时，会根据通信协议定义的信号默认值进行处理或者跳过本次处理，这个到底怎么做，大概取决于功能定义和开发者的心情吧。 那么，肯定有同学会问，事件报文如果丢失怎么办呢？这个问题问得好。我想可能没有控制器知道事件报文丢失吧。所以，有些车辆总线工程师在定义总线报文时，会尽量多的使用周期报文，如果不是总线负载率过高会存在更大的危害，他们宁愿把所有报文都安上周期的吧。 这时还有一个问题，发送者不知道自己丢包信息怎么办？有的控制器软件协议层通过第三个信息来获知丢包情况，那就是Diagnostic Trouble Code(DTC)诊断故障代码。发送者通过DTC查询接收者的故障记录，说不定可以看到通信丢失的记录，从而知道自己发生过丢包。可是绝大多数通信的发送者并不关心自己是否丢包了，因为在CAN网络中即使发生了丢包发送者也不需要特别做什么来弥补，唯一能做的，可能就是在仪表上点亮小彩灯了。 仪表异常状态灯 ?