本文主要以普及CAN通信基本原理为目的，如有从事相关领域或者有意从事车载嵌入式开发的读友们欢迎留言探讨。
本文含有关键字如下。
CAN Bus Off，Bus Off DTC，Bus Off Recovery
CAN Bus Off
连接到CAN网络的通信设备一般称为节点，但在CAN中，它是电子控制单元（ECU）。通信线路称为总线，向总线传输数据称为总线访问。
图1 线型总拓扑概念图
CAN 支持 5 种类型的错误检测。 每个节点（ECU）都有一个错误计数器。 发生错误时，计数器按指定的常数递增（增加）。 相反，如果通信成功，则计数器递减（递减）一个固定常数。 根据该错误计数器的值，每个节点的通信状态发生变化。 这样，每个节点的通信受到限制。
每个节点都有一个错误计数器，根据值改变状态。 每个节点都有一个用于传输的 TEC（传输错误计数）和一个用于接收的 REC（接收错误计数）。 有三种类型的状态。
1. Error active
处于正常参与总线的状态。
当主动节点检测到错误时，会向总线传送Error Flag。
2.Error passive
当错误计数器从Error active状态超过某个值(REC>127 or TEC>127)时，它会转变为Error passive状态。
如果处于Error passive状态的节点检测到Error，但处于Error active状态的另一个节点未检测到Error，判断为整个总线没有Error。
处于Error passive状态的节点将处于对数据传输应用某些限制的状态。
如果Error很少，则可以返回到Error active状态。
3.Bus off
当错误计数器从Error passive状态进一步增加时，则会进入Bus Off状态。
它处于与总线分离的状态。 要返回总线，必须满足返回条件。
图2 ISO11898节点状态转换图
如图2所示，当一个节点 FCE 大于255则会请求进入Bus Off状态，该节点进入Bus Off状态。处于Bus Off的节点不发送或接受帧(Frame)，不发送显性（Dominant）位。
关于上文中提到的CAN网络中的Error分为以下5类。
l Bit error
发现节点：发送/接收
它将输出电平与总线上的电平进行比较，并检测这两个电平是否不匹配。
主要输出填充位是检测对象，传输时的仲裁字段和 ACK 被排除在外。
l Staff error
发现节点：发送/接收
在应进行位填充的字段中，同一级别连续 6 位时检测到Error。
l CRC error
发现节点：接收
当根据接收到的消息计算出的 CRC 结果与接收到的 CRC 序列值不同时检测到Error。
l Form error
发现节点：发送/接收
检测何时违反固定格式位域的Error。
l ACK error
发现节点：发送
发送节点的ACK时隙为ACK时检测到Error（未返回ACK时检测到Error）
将上述内容做一个汇总，则可得到以下关系表格。
No. | 状态 | TEC | REC |
1 | 接收设备检测到Error（在发送活动Error标志和过载标志时排除位错误） | - | ＋1 |
2 | 发送错误标志后的第一位为显性 | - | +8 |
3 | 发送设备发送Error标志 | +8 | - |
4 | 在发送设备发送活动Error标志或过载标志时检测到位Error | +8 | - |
5 | 在接收设备发送活动错误标志或过载标志时检测到位错误 | - | +8 |
6 | 在发送主动错误标志、被动错误标志和过载标志后，发送和接收设备都允许最多 7 个连续显性位。 每次出现主动错误标志时，过载标志都会检测到 14 位连续显性，被动错误标志之后是 8 位连续显性，之后是 8 位连续显性。 | +8 | +8 |
7 | 送信成功时 | If TEC<>0 | - |
8 | 接收成功时 | - | If 1<=REC<=127 |
9 | 如果 TEC 或 REC 为 128 或更多，则转移到Error passive。 | - | - |
10 | 如果 TEC 为 256 或更多，则进入Bus Off状态 | - | - |
11 | 当 TEC 和 REC 变为 127 或更小时，从Error passive转变为Error active。 | - | - |
12 | 当 11 个连续的隐性位发出 128 次时，将 TEC 和 REC 设置为 0 并从总线关闭转换为错误激活。 | 0 | 0 |
通常情况下，节点（ECU）如图3所示一般由MCU和CAN收发器组成，CAN收发器向CAN总线或者MCU负责传输和接收CAN帧（CAN Frame），MCU则按照CAN通信协议进行进一步处理。
图3 ECU组成概念图
Error的检出一般由MCU完成。MCU将Frame传送到CAN收发器后，检查传输的数据和总线上采样的数据的差异，如果有差异，则将其视为Error并且累计FCE计数器，当FCE大于255时该节点进入Bus Off状态。
CAN Bus Off DTC
1、成熟条件
- 恢复N次不能成功之后，记录DTC，N的具体数值，各个OEM定义不同。
节点通信丢失类DTC 使能条件
Bus Off产生后，不再记录通信类DTC，原因显而易见，所有通信类DTC都会产生，记录没有意义，不能准确定位到是什么通信故障发生，有一个Bus off 的DTC就够了。
CAN Bus Off Recovery
当节点(ECU)发生Bus Off事件后，代表这个CAN网络节点掉线，既不能发送消息，也不能接收消息。
在AUTOSAR中，Can Controller检测到Bus Off状态后会逐层上报。经由Can,CanIf模块儿将发生的Bus Off事件报告给CanIf_User_Cbk(通常指CanSM模块)。并由CanSM模块儿进行，Bus Off恢复处理，通常称作为Bus Off Recovery。
通常ECU检测出Bus Off后，会采取等待策略，称之为Bus Off Recovery。
1、快恢复（L1）
- 恢复时间, <=100ms
- 恢复次数，5~10次不等
2、慢恢复（L2）
- 恢复间隔, [200ms, 1s]
- 恢复次数, 不限
图4 AUTOSAR Bus Off 通知
CAN Bus Off恢复功能进行需求分解，主要划分给了CAN Driver, CAN Interface, CAN state Manager三个模块。
CAN Driver要做什么？
该模块负责实现供一个报告CAN Bus off状态的接口, 但不能自动恢复
CAN Interface 要做什么？
该模块需要实现向上层报告CAN Bus Off状态的接口
CAN State Manager要做什么？
The CanSm module is responsible for mode control management of all supported CAN Controllers and CAN Transceivers.
该模块需要实现为每一个CAN控制器实现CAN Bus Off恢复算法
该模块需要支持CAN Bus Off恢复时间配置
该模块需要提供一个接口，以在上电初始化时，支持通信模式配置（No communication，or silent communication)
若有想优先了解的ECU功能欢迎留言，我会根据留言的内容调整之后更新的ECU功能以及AUTOSAR中实现方法的详解。
编写内容不易，希望各位看官们点个赞同哦。
本文主要以普及CAN通信基本原理为目的，如有从事相关领域或者有意从事车载嵌入式开发的读友们欢迎留言探讨。
