欢迎来到本系列的第10篇文章，本文将总结下前面文章的内容，同时也思考下后面文章写什么。不知你是否发现了前面文章只是介绍了最常见的CAN通讯发送与接收功能，而且只考虑最理想的情况。当然是特意这么安排的，因为想先构建基于AUTOSAR的CAN通讯的主树干，再根据实际的需要逐渐扩展CAN通讯的分枝，这样也符合我们实际的软件开发过程。好了，那下面我们就从3个视角来做回顾，并提供一些可供深入的主题。
视角1：信号角度
从信号角度，主要想再说明下：信号在CAN总线上是电压形式，在软件中是二进制数，这是怎么转换的？信号在软件中是如何变化的？
1.1 数模转换
通过本系列前面文章，我们知道ECU之间通过CAN总线通讯。从信号转换角度：模拟信号到数字信号，比如接收，如图1所示。其具体过程为：在CAN总线上，信号表现为电压形式，其具体值根据ISO11898和ISO11519标准的定义而来。然后电压信号经过CAN收发器转换成数字信号，即逻辑电平0和1。接着这些逻辑电平序列将被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文档等。
视角2：软硬件角度
从软硬件角度，要实现怎么样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文档。
视角3：功能视角
功能需求决定了硬件和软件，所以先看软件实现了怎么样的功能，然后再看软件具体是怎样实现的。正如目前文章介绍的只是最常见的CAN通讯发送与接收功能，没有考虑通讯错误的情况，也没有考虑总线关闭的情况。为了完善CAN通讯基本功能，也为了强化CAN通讯功能，下面将大概列举出来，也算是预告下后面文章的内容。
对于CAN通讯错误的情况，CAN协议标准定义了一套完成的错误处理机制。比如：
针对总线信号有定义错误帧，下图6所示。
针对总线通讯单元有定义主动错误，被动错误和总线关闭状态，如图7所示。
针对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.
1827
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
