杂话 CAN BusOFF的处理

5525

杂话 CAN BusOFF的处理 [复制链接]

 

CAN BusOFF
  什么是BUSOFF，
  举例：
    车上一个ECU 1, 一直向总线上发送消息，可怎么都发送不出去。
    如果这个累计到一定的次数，按照CAN总线协议：
     ECU 1自己的进入 BUSOFF模式，这个时候ECU 1 一时半会是不能送信了。


  对ECU 1自己来看，没啥好处，但是他没有 坏一锅酱啊，不影响大局，其他人还是能自由的通信的奥。


  协议让ECU 1坚持了几把，可以了
  协议也让ECU 1 懈了，这样给他人留方便
  

5525

BUS OFF之后 咋办

ECU 1在自己内部检测到BUS OFF后，默默的从逻辑上退出了总线，
暂时他没妨碍大家，
ECU 1他自己也搞不明白啥回事，
于是ECU 1拿着小本子，记下了 x年x月x日x时x分x秒, 但是汽车电压，里程，xxx 是多少多少，我bus off 了

写完备案后，ECU 1 开始数时间，等待 5 秒后，重启自己的CAN模块，
又开始了 和小伙伴们的对话。

(5秒只是 示例，具体情况而异)

5525

CAN 总线还是不错的--主要是说CAN总线比较健壮！！！

1. 小毛刺噪音，电路上带点小过滤  --- 过了


2. 大毛刺噪音，本来就是差动 传数据 --- 抵消下， 过了


3. 粗毛刺噪音，上位 CAN Control内部逻辑过滤 --- 过了


4. 粗粗毛刺噪音，上位 CAN Control内部有采样点控制，不会那么巧碰到 --- 过了
   就那么巧了，你怎么说？？
   怕你了，碰巧采到那个点，就会向总线连续发 0, 这样，全网都知道这消息，不能用了？
   这是送的人一看，不好意思哈，我再送


5. 粗粗毛刺噪音，老来，导致发的人总是要多发几次才行 --- 基本能通信，凑活过了


6. 粗粗毛刺噪音，来了有一会了，导致发的人总是要多几次也不行
   协议说了，的坚持且懈，送的那个ECU直接退出了 --- 协议让这么干的，不能影响全局吗，必须过了


7. 粗粗毛刺噪音，来了有一会了，有走了，刚才 坚持且懈的那个ECU，也振作精神来和大家说话了
   

通信又恢复了正常。

5525

CAN总线弱的x面
-1- 物理上线一长，速度就下降
-2- 无理上仲裁看ID，一个bit一个bit的比较，这个是速度上的瓶颈
-3- 正常报文头都要加入 校验，确保报文控制部分的正确，CAN没有
-4- 用的人一多，节点间的通信延时就会变大，
-5- 哪怕是传一个bit的数据，报文头啊，校验啦，开始，停止啦，overhead偏大


（
    上面有很多看起来有点过分要求，但是毕竟其他总线改进了其中的部分
    所谓，不进则退
）

nickman1982

5525 发表于 2016-6-23 07:07
CAN总线弱的x面
-1- 物理上线一长，速度就下降
-2- 无理上仲裁看ID，一个bit一个bit的比较，这个是速度 ...

第一点. 在CAN规范范围内的长度下，速率还是可以保证的，除非线束拓扑设计太烂，没有遵循规范设计要求
第二点，速度瓶颈，主要还是跟收发器物理电路有关，以及MCU的时钟精度，CAN FD同样的仲裁机制，速率不是提高了？
第三点，在数据帧中可以增加包含ID的CRC 或者奇偶校验
第四点，CAN总线增加节点并不一定会增加报文通信延时，主要看网络负载率，网络负载率超过一定值时，会导致报文的错误（概率变大），导致延时重发等现象。
第五点，CAN 2.0 payload的最大效率只有50%多点，CAN FD可以有效改善payload效率低的问题

5525

>第一点. 在CAN规范范围内的长度下，速率还是可以保证的，
>除非线束拓扑设计太烂，没有遵循规范设计要求
就CAN来看，这么说可以，按CAN的规范来就行。
跟其他协议相比，比如MOST，CAN的物理线长对速率影响大些。

>第二点，速度瓶颈，主要还是跟收发器物理电路有关，以及MCU的时钟精度，
>CAN FD同样的仲裁机制，速率不是提高了？
CAN的物理层瓶颈，是大家都连接在一个物理链路上，交换的当前的1 bit，
这个就像PC里面的PCI总线，再快上不去了，就上PCI EXPRESS了。

5525

>第三点，在数据帧中可以增加包含ID的CRC 或者奇偶校验
首先DLC能正确收下来，后面的CRC才能收下了，CAN的消息并没有对CAN的DLC进行单独的保护。
好多通信协议对 报文的头，都是有单独的校验的。
比如 LIN, TCP/IP, 还有无线的很多协议。

>第四点，CAN总线增加节点并不一定会增加报文通信延时，
>主要看网络负载率，网络负载率超过一定值时，会导致报文的错误（概率变大），导致延时重发等现象。
CAN总线本来就是比ID，谁小的谁就发，消息一多，关键节点就会造成延时
Flexray，改变了这一点，把传送分成静态和动态的，
静态去，宁缺毋滥，放在这里传送的报文，延时都是预制的。

5525

>第五点，CAN 2.0 payload的最大效率只有50%多点，CAN FD可以有效改善payload效率低的问题

CAN是不错的，就是CAN有CAN的历史使命，现在还在给力服役。

CAN FD的确改善了，但是什么时候大规模采用，不好说。
2016年我们看到很多CPU还没有带 FD 的控制器。
当然不光CAN，以太网也有这个效率问题。

不过还是有协议改进了这个效率问题，
比如A2B和MOST，这块就改进很多，大量数据都是直通的。

5525

话说回来，存在就是理由。
这么多协议诞生了，也商用了，
也没见CAN消失。

存在就是理由，CAN的优点已经很多了，
但他不是万能的，100%完美的。

要完全替代CAN，还要一段时间。

Charsly

楼主有空讲下bus off与bus error区别

5525

bus off是个非常集体的概念，
  ECU自己送信失败，TX error count + 8，
  ECU自己送信成功，TX error count - 1，
  这个TX error count 超过255，ECU就必须进入Bus Off 状态，并需要逻辑上断开总线

bus error是个笼统的说法，
No ACK错误，CRC错误等

5525

CAN frame 的一些常见错误

送的ECU检查：
  有无ACK
  CRC检查，CRC Delimiter, ACK Delimiter，EOF等
  BIT监控， 送的那个ECU，自己校对每个BIT，看有没有都送对（ID区域，和ACK区域除外）

收的ECU检查：
  CRC检查，CRC Delimiter, ACK Delimiter，EOF等
  检查有无联系6比特是全0、或全1的

nickman1982

5525 发表于 2016-6-24 19:31
>第五点，CAN 2.0 payload的最大效率只有50%多点，CAN FD可以有效改善payload效率低的问题

CAN是不错的 ...

CAN FD 协议还没有标准化，CRC算法还在更新，未来汽车电子的总线高速方案就是以太网了，MOST和A2B（这是什么总线?)应该不会大面积使用，MOST的成本太高了，光纤的使用增加线束布置难度

nickman1982

5525 发表于 2016-6-24 19:17
>第三点，在数据帧中可以增加包含ID的CRC 或者奇偶校验
首先DLC能正确收下来，后面的CRC才能收下了，CAN的 ...

Flexray虽然不错，但是它的拓扑结构更加复杂。静态与动态的分离，从软件层面就可以实现，比如TTCAN协议。现在国内外从Flexray的应用角度，也没有大面积使用，欧洲车厂中也只是在豪华品牌中使用，一旦CAN FD的推广，Flexray未来还是会被取代的

nickman1982

5525 发表于 2016-6-24 19:13
>第一点. 在CAN规范范围内的长度下，速率还是可以保证的，
>除非线束拓扑设计太烂，没有遵循规范设计要求
...

我想CAN当初的设计是为了实时控制系统设计，点对点的设计，增加传输延时，另外90年代初的时候，车上的ECU没有几个，没有必要搞成点对点，现在网络节点多了，就分层次结构了，未来的车载网关处理能力必定更强，所以CAN FD/Ethernet会成为更好的选择

5525

nickman1982 发表于 2016-6-29 13:24
CAN FD 协议还没有标准化，CRC算法还在更新，未来汽车电子的总线高速方案就是以太网了，MOST和A2B（这是 ...

MOST这几年采用车企 已经超过100家，这个是在microchip开会的时候看到的。
MOST还是很适合汽车的。

有兴趣，请看这里
https://bbs.eeworld.com.cn/forum-18-1.html

光钎的确使用成本高，布线难。
的确是的，MicroChip自己也发现了这个问题，
他们推出了双绞线 和 同轴电缆连接方案，算是一种弥补吧。

5525

nickman1982 发表于 2016-6-29 13:27
Flexray虽然不错，但是它的拓扑结构更加复杂。静态与动态的分离，从软件层面就可以实现，比如TTCAN协议。 ...

“一旦CAN FD的推广，Flexray未来还是会被取代的”
这个我信。
到目前，Flexray已经在丰田看到好多在用了，CAN FD 还没看到用的。可能是我看到的不够多。

其实，CAN FD, 我们也想用，就是还没有找到适合的SOC。

5525

nickman1982 发表于 2016-6-29 13:30
我想CAN当初的设计是为了实时控制系统设计，点对点的设计，增加传输延时，另外90年代初的时候，车上的ECU ...

CAN FD/Ethernet，目前来看是这两个方向是不错。
不过应该还会有新的协议出来，社会毕竟是在发展的吗。

现在节点是越来越多，年年都在扩容，扩的比4G网都勤！

5525

MOST 25/50/150 主要传 控制，声音，图像用的，Microchip家的
A2B， Automotive audio bus, 主要传 控制，声音的， Analog Device 家的

Chaos233

继续留名，哈哈，我们只是can的消费者啊。。。。。。。。。。。。