声明：本文主要内容借鉴了知乎大佬–柏拉凃的回答，因为觉得他写的太好了所以决定搬运到个人CSDN博客里面来，方便以后学习翻阅，里面也会加加入自己的一些理解和积累，大家对原文感兴趣可以直接对他的内容-----传送门
一、什么是CAN
CAN总线技术诞生于1986年，全称：Controller Area Network，中文译为“控制器局域网络”。是目前世界汽车行业主流车载网络总线技术，不管你是硬件工程师、软件工程师、测试工程师还是标定工程师，都会接触到它，是汽车行业的必备基础知识之一。
二、CAN基础知识了解
既然是汽车电子工程师的必修课，就得扎实的学习，经历了数十年的发展与普及网络上关于CAN的材料可以说是数不胜数，大家可以百度查找，下面是公认的比较基础的一本入门书，由瑞萨公司编写，内容通俗易懂，就算里从没接触过CAN，也可以在短时间内获取该书本的80%的知识！
CAN入门书
下面介绍几个基本的知识点：
（1）CAN网络
CAN网络通常有N个节点组成，节点间呈总线式连接，每一个节点必须包含CAN收发器、CAN控制器、主控制CPU，（通常CAN控制器、主控制CPU为集成式方案）。较为常见的CAN通讯速率为500Kbps，125kbps，即行业内经常所谓的低速容错CAN和高速CAN，二者具有的不同的物理特性。
整车具备的CAN网络一般有：PT CAN、CH CAN、Body CAN、Info CAN、Diag CAN 5条CAN总线。详细内容可以参考这里-----整车CAN网络架构
低速容错CAN： CAN_H或CAN_L仅有一根断开时，任可正常通讯，主要使用在对可靠性要求高的场合如车身控制CAN网络通道。
高速CAN： 用于更高的数据吞吐能力，主要使用在对实时性、数据传输量大的场合，如汽车动力系统CAN通道等。
扩展阅读：高速CAN VS 低速CAN
（2）CAN帧分类
CAN的帧主要可分为** 数据帧、遥控帧、错误帧、过载帧、帧间隔** 。各种帧类型的用途如下表所示，作为数据传递的载体数据帧是最重要的，正常的控制命令、状态信息、诊断数据，刷新数据都是通过数据帧传递的。
| 帧 | 帧用途 |
|---|---|
| 数据帧 | 用于发送单元向接收单元传送数据的帧 |
| 遥控帧 | 用于接收单元向具有相同ID的发送单元请求数据的帧 |
| 错误帧 | 用于当检测出错误向其它单元通知错误的帧 |
| 过载帧 | 用于接收单元通知其尚未做好准备的帧 |
| 帧间隔 | 用于将数据帧及遥控帧与前面的帧分离开来的帧 |
（3）CAN数据帧的组成
要理解CAN，一定、绝对、千万不能不知道数据帧的组成，特别是要关注其中的仲裁段，数据段，如下图为标准帧（仲裁段为11bit）的帧格式组成,ID取值范围可为0x000 ~ 0x7FF；不同的厂家会将数据段进行区域划分，如（仅做示例）：
**0x00 ~ 0xFF：**用于高优先级的事件性报文传送；
**0x100 ~ 0x4FF：**用于周期型报文的传送；
**0x500 ~ 0x5FF：**用于网络管理报文的传送；
**0x600 ~ 0x6FF：**用于调试开发、标定相关报文的传送；
**0x700 ~ 0x7FF：**用于诊断相关报文的传送；
扩展帧：
相对于上图的标准数据帧，还有扩展CAN 数据帧，CAN 数据帧中紧随SOF 位的是32 位的仲裁字段。仲裁字段的前11 位为29 位标识符的最高有效位（Most Significant bit，MSb）（基本lD） 。紧随这11 位的是替代远程请求（Substitute Remote Request， SRR）位，定义为隐性状态。SRR位之后是lDE 位，该位为隐性状态时表示这是扩展的CAN 帧。
三、汽车开发中CAN开发的主要内容
（1）CAN驱动开发
要实现CAN的收发必须先实现CAN驱动开发，CAN驱动开发主要包括：CAN控制器驱动开发和CAN收发器驱动，较为经典的NXP的TJA104X系列CAN收发器，大部分NXP MCU集成的flexCAN控制器。这部分开发更多的是阅读对应型号的CPU，控制器的芯片手册，结合示例代码，一句一句抠，一行一行敲，再配合示波器（逻辑分析仪），各类CAN工具进行反复摸索。
CAN收发器驱动的开发中最最关键的一部分工作就是了解收发器不同工作模式的切换方法，如下图TJA1043T收发器状态切换示意图，收发器工作时主要分为NORMAL Mode,STADBY Mode,GO-TO-SLEEP Mode,SLEEP Mode。
（2）CAN通讯矩阵
CAN通讯矩阵通常由整车厂完成定义，车辆网络中的各个节点需要遵循该通讯矩阵才能完成信息的交互和共享。
如图为vector工具打开XXX.dbc文件（常用的保存通信矩阵文件格式）后的示例，可以看到**CAN报文Message1单次可传送8bytes，即64bits信息，64bits由多个signal组成，各个signal分布在message的不同位置，（示例）其中蓝色的openwindow可表示为车窗打开控制指令。**如：①openwindow=0时，表示打开车窗，openwindow=1时，表示关闭车窗；②vehiclespeed表示车速信息，vehiclespeed=5表示5km/h。这里只做简单示例，实际汽车开发中还会涉及到一定的物理值与逻辑值的转换。
这样当Message1发送到CAN总线上时，接收到CAN节点的就能获取到此时的CAN控制指令或状态值。
特别注意： CAN通讯矩阵的定义会有摩托罗拉格式和英特尔格式的区别，两者的区别-----传送门
（3）基于CAN的车辆诊断
车辆诊断：在不解体（或仅卸下个别零件）的条件下，确定汽车技术状况，查明故障部位及原因的检查。 包括汽车发动机的检测与诊断，汽车底盘的检测与诊断，汽车车身及附件的检测与诊断以及汽车排气污染物与噪声的检测等内容。CAN就能很好的满足上述要求。
汽车诊断的开发是汽车电子电器开发中非常重要的一环，对于CAN诊断最为常见的是UDS。UDS协议即ISO14229,是Unified Diagnostic Services，统一诊断服务，是诊断服务的规范化标准，在汽车诊断方面广泛使用，如图，为满足诊断需求，UDS中定义了一系列的服务。
当然，为了确保诊断报文的稳定传输，还有ISO 15765协议是一种CAN总线上的诊断协议。
其中：
ISO 15765-1包括物理层和数据链路层，
ISO 15765-2对网络层进行说明，
ISO 15765-3则是规定到应用层的具体服务。
（4）基于CAN的刷新
由于设计缺陷或者功能升级，车载控制器在生命周期内会有软件刷新的需求，作为控制器与外界几乎唯一的数据通道，车载控制器的软件刷新通常由CAN通道实现，基于CAN的刷新又与基于CAN的诊断息息相关。
但现在的整车OTA架构，基本不依靠CAN来进行刷新了
（5）CAN网络管理
主要分为OSEK网络管理，AUTOSAR网络管理
四、AUTOSAR
AUTOSAR在汽车电子行业的知名度应该不会亚于“六神”在中国香水界的地位。简单的讲AUTOSAR是由全球汽车制造商（宝马、戴姆勒、福特…）、部件供应商及其他电子（大陆、博世…）、半导体和软件系统公司联合建立，各成员保持开发合作伙伴关系。自2003年起，各伙伴公司携手合作，致力于为汽车工业开发一个开放的、标准化的软件架构。
CAN作为汽车电子领域最为重要的通讯形式，AUTOSAR怎么可以不对CAN进行定义规范，可以说AUTOSAR的架构思想对现今的软件架构产生了重要影响，如图为初步整理的的AUTOSAR中关于CAN的相关模块及架构，可以清楚的看到其中由下至上系统的定义出了CAN驱动、接口层、传输层、CAN诊断、CAN网络管理等。
不过，随着汽车智能化程度的不断推进，互联网巨头公司正在将Android和IOS系统逐步地往汽车上迁移，而且市面上已经有很多新上市汽车搭载了智能操作系统，汽车分散的ECU架构也往域控制器架构不断推进，以前一个汽车里面上百个ECU，在不久的将来（5-10年）将变成几十个甚至几个，到了这个阶段AUTOSAR还有市场吗？
面临同样困境当然还有我们的CAN总线技术，虽然主机厂门把CAN总线宣称地是安全地总线技术，但我认为这是一种既得利益者人为设置的壁垒而已，CAN总线在汽车智能化时代劣势已经越来越凸显了，行业急需一种更安全更快速，更具未来意义的总线技术，而车载以太网可以说是最有竞争力的候选技术-------传送门----有量产汽车不用CAN总线而用以太网的吗？