从3个视角谈CAN通讯

首页发布

导读：

本文由汽车电子与软件授权发布，作者为糊涂振。

本文是CAN通讯系列的第10篇，本文将总结前面文章的内容，并介绍后续的文章思路。前9篇文章只是介绍了最常见的CAN通讯发送与接收功能，而且只考虑最理想情况。当然这是特意安排的，因为想先构建基于AUTOSAR的CAN通讯的主树干，再根据实际的需要逐渐扩展CAN通讯的分支，这样也符合我们实际的软件开发过程。下面我们就从3个视角来做回顾，并提供一些可供深入的主题。

信号角度

从信号角度，主要想再说明下：信号在CAN总线上是电压形式，在软件中是二进制数，这是怎么转换的？信号在软件中是如何变化的？

1.1 数模转换

通过本系列前面文章，我们知道ECU之间通过CAN总线通讯。从信号转换角度：模拟信号到数字信号，比如接收，如图1所示。其具体过程为：在CAN总线上，信号表现为电压形式，其具体值根据ISO11898和ISO11519标准的定义而来。然后电压信号经过CAN收发器转换成数字信号，即逻辑电平0和1。接着这些逻辑电平序列将被ECU硬件单元处理，丢弃或存入寄存器。反之，发送过程其实就是一个数字信号到模拟信号的转换过程。

图1 CAN总线到ECU的信号转换

这里若需掌握各个环节的细节：

关于CAN总线特性，可通过ISO11898，ISO11519系列标准研究总线的电器和物理特性。
关于信号转换实现，可研究CAN收发器的原理与特性等。
关于寄存器存储，可细读相应的芯片手册，并动手去配置芯片和调试代码。

1.2 信号变化

上述的逻辑电平序列有什么规律？有什么作用？通过前面文章我们知道CAN协议标准定义了这些逻辑电平序列，使这些数据有了实际意义，其实就是一些数据帧，遥控帧等的信息。通过配置CAN硬件单元，比如利用IDE的数据就可以决定ECU是否接收某个CanId的数据，进而再准确将接收的相应数据存入相应的寄存器，比如IDE存入IDE相关的寄存器，DLC存入长度相关的寄存器。当软件通过硬件接口访问相应的寄存器，就可以读取到对应的数据，比如长度，数据等信息。这样软件按照OSI参考模型的架构将这些读取的数据以协议数据单元（PDU）格式逐层向上传输，直到将PDU解包成报文通讯协议规定的信号形式，整个过程如下图2所示。

这里若研究各个环节的实现：

关于CAN帧定义，可细读CAN协议和ISO11898-1标准。
关于寄存器的存储与提取，可研究相应的芯片手册。
关于CAN通讯架构，可参考OSI参考模型，ISO17356和AUTOSAR文档等。

软硬件角度

从软硬件角度，要实现怎么样CAN通讯功能，就决定了要用怎样的硬件和软件。那么从软件工程师角度，是怎么看硬件？又是怎么看软件的？

2.1 硬件

从软件工程师角度，主要是根据芯片手册，ECU原理图和其他驱动的用户手册来助于对软件的理解，比如了解CAN的硬件连接，即从总线连接到哪个PIN，PIN连接到什么收发器，收发器连接到芯片的哪些引脚。或者了解提取寄存器数据，要对芯片进行的哪些配置，怎么配置等。或者更深入地就是硬件特性变化会对软件产生怎样的影响等等。

2.2 软件

从前面文章我们知道，先明确了一个清晰的软件架构，如下图3的中间部分，再从控制流和数据流考虑。若采用一个极其简单的架构，如图3最左侧部分，从寄存器提取完数据，直接给应用层去解析。但这样的架构显然满足不了软件的安全性，可移植性，可重用性和可扩展性等要求，所以为了满足这些要求，会采用基于OSI参考模型的AUTOSAR架构，如图3最右侧部分，只允许CAN Driver 访问硬件，向上只对接CAN Interface，与上层的模块通讯均由CAN Interface统一管理，通过PduR路由到更多的上层模块，减少接口等等。当然前面文章出于内容更易懂且精炼的考虑，采用了图3中间部分的基于OSI参考模型的AUTOSAR架构的简约版。

这个软件架构的CAN通讯控制流如下图4所示。前面文章已经大体上介绍了CAN发送与接收的控制过程，比如不同模块如何进行数据传输，同一模块中数据传输所需具备的条件。另外也介绍了这些过程所涉及的接收通知，发送，发送确认的相关函数与动作。抽象地讲就是实现一个功能需先要以一定的时序组织不同的模块，然后各个模块要满足各自一定的条件才去采取执行某些活动，最后考虑这些活动如何具体地一步一步实施。

当然通过控制流不难发现，数据流也极其重要。基于OSI参考模型，协议数据单元（PDU）在不同的层会有不同的名字，比如数据链路层的PDU叫L-PDU，网络层的PDU叫N-PDU，交互层的PDU叫I-PDU。我们根据这些PDU和其他信息的映射关系，链接关系，就可构建起整个CAN通讯功能的数据流，类似于图5。这样使得我们能更好理解AUTOSAR配置工具，比如VECTOR或EB工具配置内容的设置和链接关系；也能更深入AUTOSAR的CAN通讯实现原理与方法，比如硬件的访问机制，从L-PDU到N-PDU到I-PDU的映射逻辑等。

这里若想研究软件的各个模块，可根据ISO11898-1， ISO17356-4和相关AUTOSAR文档。

功能视角

功能需求决定了硬件和软件，所以先看软件实现了怎么样的功能，然后再看软件具体是怎样实现的。正如目前文章介绍的只是最常见的CAN通讯发送与接收功能，没有考虑通讯错误的情况，也没有考虑总线关闭的情况。为了完善CAN通讯基本功能，也为了强化CAN通讯功能，下面将大概列举出来，也算是预告下后面文章的内容。

对于CAN通讯错误的情况，CAN协议标准定义了一套完成的错误处理机制。比如：

针对总线信号有定义错误帧，下图6所示。

图6 错误帧定义，引自[2]

针对总线通讯单元有定义主动错误，被动错误和总线关闭状态，如图7所示。

图7 单元的错误状态，引自[2]

针对CAN通讯网络有定义无通讯模式，静默模式，完全通讯模式，如图8所示。

对于CAN数据帧数据长度不够的情况，有提出一种更灵活的CAN数据帧，即CANFD。

对于CAN通讯网络能被唤醒的情况，如下图10所示。

这里就先列出这些典型的CAN通讯功能，通过这些新功能不难发现：为了应对日益增加的功能需求，不管是针对个人还是企业，硬件还是软件，其实都需要不断地进行更新和强化。

到此我们就从3个视角既回顾了CAN通讯的基本发送与接收功能，也提出了CAN通讯的新功能，为了让大家更加全面且系统地了解CAN通讯功能，后面文章将在CAN发送与接收的主树干上继续生枝发叶。

Reference:

[1] Layered Software Architecture

[2] Can 入门书.pdf

[3] Specification of CAN State Manager

[4] CAN FD - The basic idea

[5] Tutorial for Wake Up Schemes and Requirements for Automotive Communication Networks, Automotive Electronics, BOSCH.

#	BC-AUTO 在售报告列表
1	全球及中国数十家汽车工程技术服务企业研究报告
2	全球及中国电液制动系统EHB产业研究报告
3	全球及中国汽车基础软件企业研究报告
4	全球及中国车机系统产业研究报告
5	全球及中国前向ACC、AEB产业技术研究报告
6	全球及中国车载ESP产业研究报告
7	全球及中国车载EPS产业研究报告
8	国际汽车半导体企业研究报告
9	中国汽车半导体企业研究报告
10	全球及中国汽车半导体产业研究报告
11	Euro-NCAP、C-NCAP主动安全规划及技术方案研究
12	全球及中国车联网产业研究报告
13	全球及中国整车OTA应用产业研究报告
14	全球及中国车企、主流Tier1出行业务研究
15	全球及中国汽车大数据应用研究报告
16	全球及中国商用车自动驾驶产业研究报告
17	全球及中国驾驶员监测系统产业研究报告
18	全球及中国车载5G智能终端产业研究报告
19	智能汽车操作系统产业研究报告
20	中国智能汽车行业主流Tier1研究报告
21	全球智能汽车网络安全及信息安全产业研究报告
22	全球及中国车载网关产业研究报告
23	全球及中国车载超声波雷达产业研究报告
24	全球及中国环视ADAS产业研究报告
25	国际主流前向双目视觉ADAS产业研究报告
26	国际主流前向单目视觉ADAS产业研究报告
27	全球及中国泊车辅助&自主泊车研究报告
28	特斯拉整车OTA汇总分析研究报告
29	国际主流Tier1自动驾驶业务分析报告
30	全球及中国车载毫米波雷达产业研究报告
31	全球及中国车载激光雷达产业研究报告
32	全球及中国车载高精度地图产业研究报告
33	全球及中国自动驾驶算法集成企业研究报告
34	全球及中国主流车企自动驾驶进展研究报告
35	智能网联汽车Tier2转型为Tier1供应商研究报告
36	全球及中国自动驾驶域控制器产业研究报告
37	全球及中国车载T-box产业研究报告
38	全球及中国数十项ADAS功能研究报告
39
40	全球及中国软件定义汽车产业研究报告
41	全球及中国数十家汽车仿真企业及产品研究报告
42	全球及中国车身域控制器产业研究报告
43	全球及中国汽车仪表系统产业研究报告
44	全球及中国智能座舱产业研究报告
45	高级别自动驾驶惯性导航产业研究报告
46	全球及中国车载HUD产业研究报告
47	全球及中国车载显示屏产业研究报告
48	2021年全球及中国车载夜视系统产业研究报告
49	2021年中国汽车工业全产业链自主可控研究报告