menghuyouyou的博客

但是实际情况不会那么顺畅，经常碰到电子电器架构部门拒绝退回的情况，原因比如是CAN通讯的变更将导致CAN总线负载率过高，此时功能开发工程师就只能各显神通了，如果对功能影响没要么大，也许就此放弃；这些CAN信号耗费大量的物力人力和精力，这些CAN信号经常是在主机厂各个部门的千锤百炼，相互拉扯，甚至吵得面红耳赤，干架厮杀出来的。首先，最基本的点，这么多控制器要明白到认可这个功能实现的逻辑，认领各自的任务，必须通过多番的沟通。整车的网络拓扑决定了各个控制器的定位以及相互之间的关系，以怎样的方式进行通讯等。

1 CAN通讯先定义整车网络拓扑，即各ECU都通过哪路CAN建立起通讯；然后对于单个ECU，需要定义利用该路CAN，发送多少条报文，每条报文发送哪些信号，同时需要明确接收哪些报文；最终以CAN矩阵或者DBC文件形式确定各个ECU的CAN通讯内容，本质上是以CAN 报文实现车辆内部各个 ECU 间的数据交换，确保信息的准确传递。

但这样的架构显然满足不了软件的安全性，可移植性，可重用性和可扩展性等要求，所以为了满足这些要求，会采用基于OSI参考模型的AUTOSAR架构，如图3最右侧部分，只允许CAN Driver 访问硬件，向上只对接CAN Interface，与上层的模块通讯均由CAN Interface统一管理，通过PduR路由到更多的上层模块，减少接口等等。基于OSI参考模型，协议数据单元（PDU）在不同的层会有不同的名字，比如数据链路层的PDU叫L-PDU，网络层的PDU叫N-PDU，交互层的PDU叫I-PDU。

首先，ASW经RTE模块调用Com模块的Com_SendSignal或Com_SendSignalGroup函数发送相关的信号给COM模块，存入其相关的buffer。COM模块处理PDU与信号的转换，而与前面文章的CAN，CAN接口和PDUR模块的处理均仅基于PDU，那么针对PDU转换成信号，会有什么不一样的要求呢？以上就是从ASW到COM模块再到PduR模块的发送过程，当然这里忽略很多传输特性的细节，若想了解如下图13，14所示的CAN发送接收过程，详见[2]。由此可知COM模块定义一套符号转换的规则。

通过以上知识对应到CAN通讯，就是PduR模块从CAN接口模块/COM模块接收到了PDU，然后根据PDU ID查找已定义好的静态路由表，获得其目标地址，定向并转发到COM模块/CAN接口模块，即路由PDU，故称为PDU Router。以上就是简单介绍了PduR模块在CAN通讯的发送与接收所起的作用，当向上进入COM层后，简单地说就是：接收时，将PDU解包成一个一个的信号，供ASW使用；发送时，PduR模块将来自COM模块的发送请求路由到Can接口模块，将来自Can接口模块的确认路由到COM模块，如下图3。

CAN Interface，顾名思义，CAN接口模块，位于下层的CAN设备驱动（CAN Driver，CAN收发器驱动）和上层的通讯服务层（CAN传输协议层，Pdu Router等）之间，如下图1所示。图1 AUTOSAR CAN Layer Model，引自[1]引自[1]: CAN接口模块由所有与CAN硬件无关的任务组成，这些任务属于相应ECU的CAN通讯设备驱动程序。这些功能在CAN接口模块中执行一次，以便底层CAN设备驱动程序只专注于访问和控制相应的特定CAN硬件设备。

关于AUTOSAR概念的内容不在此展开，这方面的资料很好找，权威资料可以去AUTOSAR官网找：https://www.autosar.org/fileadmin/ABOUT/AUTOSAR_EXP_Introduction102020.pdf。

同样地，对于唤醒功能2，ZCUR会唤醒自身网段的同时，唤醒ZCUF和ZCUB（因为唤醒功能1需要ECU2和ECU5的参与）。对于唤醒功能1，通过ECU1先唤醒ZCUF，然后让ZCUF唤醒ZCUL和ZCUB，最后ZCUL唤醒域内的ECU3（ECU4可能也会被唤醒，因为它与ECU3在同一网段，取决于它的网络管理配置），ZCUB唤醒域内的ECU6；这就是PN的概念，精准定位到哪个控制器需要被唤醒，在汽车研发过程中，网络管理策略通常由整车电子电器架构部门负责，而休眠唤醒场景的定义则需要各个功能开发负责人来输入。

同时针对不同休眠或唤醒场景，网管报文的userdata有所区别，如何做到场景与网管报文内容一一映射，通常会定义另一帧报文，用来表明当前是哪个或哪几个唤醒条件或休眠条件满足。又或者如果用户发现汽车电量不充足了，那么会有充电需求，插枪充电，这时如果插上慢充枪，那么OBC会先被唤醒，识别出插枪行为及其慢充枪的连接状态，然后OBC唤醒BMS和其他相关的控制器进行充电。也就是说，通过对一个又一个整车功能和应用场景的详细分析，最终能够汇总出整车所有的休眠唤醒场景需求，通常会用一个表格来管理，俗称休眠唤醒表。

而被动唤醒节点EPS和VCU接收到IEB的网管报文，同样它们的状态会跳转到重复报文状态，也会周期性发送不同ID的网管报文，但不是快发形式，通常是500ms的发送周期，具体发多少帧取决具体需求。通过该网管报文可知，IEB为主动唤醒节点，它需要唤醒三个控制器，分别是EPS，EPB和VCU，依此思路，针对不同休眠唤醒场景，网管报文的内容会不同，也就是说需要详细分析每一个场景来确定网管报文的内容。另外在这个状态，对于主动唤醒节点IEB除了需要发送网管报文，还需要发送应用报文，但第一帧是先发网管报文。

1 本地唤醒本地唤醒是指某些控制器可以通过特定的触发信号被唤醒，比如KL15硬线，某些传感器唤醒引脚信号。当这些触发信号被检测到时，控制器可以被唤醒以执行相应的操作。1.1 KL15硬线唤醒KL15是汽车电子中的一个标准电源信号，常用于控制器的供电。KL15硬线信号在车辆点火时处于高电平状态，表示电源已连接。KL15硬线唤醒是指通过监测KL15信号的状态变化来唤醒控制器或其他电子模块，并开始执行相应的操作，例如初始化或执行特定任务等。下图所示是一种最常见的KL15硬线唤醒方式。

对于CAN通讯的唤醒机制，会涉及到软硬件部分，其中硬件部分通常与CAN收发器有关，一种常见的方式是通过CAN收发器的唤醒引脚或中断功能来触发唤醒信号，然后使用唤醒信号来激活电源芯片，再由电源芯片提供电源给微控制器。CAN控制器的作用是管理CAN总线上的通讯活动，它负责处理报文的收发，确保报文的正确性、完整性和时序性。为什么需要接终端电阻？CAN总线的传输介质通常采用的是双绞线，原因是双绞线结构可以有效地减少外部电磁干扰对CAN信号的影响，也可以延长CAN总线的传输距离以及有助于提高CAN总线的传输速率。

通讯形式包括Lin, CAN,和Flexray等，以CAN通讯为例，信号通过CAN_H和CAN_L两根线传输，对于一个控制器硬件来说，先对信号做一些处理，比如抗干扰电路，然后需要使用CAN收发器将CAN_H和CAN_L两根线的差分信号转换成逻辑电平信号，再传输给微处理器中的CAN控制器。接下来就回答这个问题。除了上述的这些功能，一般在PCB会留有调试接口供软件开发调试使用，EMC设计相关的硬件电路，可能会有外加存储芯片，比如针对OTA功能，可能因为微控制器Flash大小不够，而增加外部Flash。

假设场景：某节点处于主动错误状态，初始TEC为0，一直向总线发送一条报文，但因干扰原因每次都发送失败（输出错误标志），那就意味着每次发送都会使得TEC+8，因此发送了16次（TEC=8*16=128）该节点跳转到被动错误状态，再发送16次（TEC=128+8*16=256）,该节点跳转到Bus off。根据CAN总线协议的定义，当节点处于被动错误状态时，发送错误计数值（TEC）大于255，那么节点就会跳转到总线关闭态，即Bus off，这时节点就不能参与总线通讯，无法发送和接收CAN报文。

的示波器采集的实际数据再来了解错误帧发送，下图发送节点Tx(紫线)在箭头2到箭头4之间出现连续12us的显性位，而CAN位时间位2us，这意味着出现了连续的6个显性位，即错误帧的主动错误标志。当发送节点Node_A检测到位错误后，就立即在下一位开始发送主动错误帧，即6个连续显性位的主动错误标志和8个连续隐性位的错误界定符。从上面例子发现，一个节点上检测到错误发送错误帧，会导致总线上所有的节点都会检测到错误并发送错误帧，为什么要这样设计？接下来，先通过位错误和填充错误的例子来了解错误帧的发送。

处于被动错误状态的节点即使检测出错误，而其它处于主动错误状态的节点如果没发现错误，整个总线也被认为是没有错误的。一个节点发送被动错误标志，该节点向总线发送连续六个隐性位（被动错误标志）却回读到显性位，不认为是位错误。关于位错误， 所谓“发出的电平与从总线上回读的电平不一致”，指的就是节点向总线发出隐性位，却从总线上回读到显性位或者节点向总线发出显性位，却从总线上回读到隐性位这两种情况。可以正常参加总线通信的状态，处于主动错误状态的节点检测出错误时，输出主动错误标志。检查到错误后，什么时候发送错误帧呢？

通俗地讲，就好比一条报文就是CAN总线上一辆辆飞驰的汽车，如果发送的报文太快太频繁，可能会出现拥挤，而导致传输阻塞，信息延迟或丢失等问题，因此，在设计一条CAN总线有多少报文，报文多快频率发送时，就用负载率来衡量。在给定时间内，CAN总线所采用的通信参数与总线容量之比，大白话就是CAN总线具备1s传递1000bit数据的能力，而目前设计如果要求1s传递500 bit数据，那么负载率就是50%，如果要求1s传递1000bit数据，那么负载率就是100%。CAN总线正常的发送过程中，帧间隔有3个隐性位。

就这么一个小小功能的解析，其实已经包含了从基本原理到软件实现，再到实际应用，后续继续以这种思路，解析更多CAN通讯内容，欢迎持续关注。已经详细介绍了波特率，CAN位时间，同步段(SS)、传播时间段(PTS)、相位缓冲段1(PBS1)和相位缓冲段2(PBS2)，采样点等概念。然后，要设置的波特率为500Kbps，换算时间表示则为1/500 Kbps =2000ns。如果CAN位时间为24个tq，那么tq=83.33ns，tq不为整数，也不成立！综上，就可以确定CAN位时间应为8个tq，tq=250ns，取。

在总线空闲状态，接收节点检测出帧起始（SOF位）时，会调整当前位的同步(SS)段，调整宽度不限，这就是硬同步，即接收节点直接将此下降沿的位置认为是SS段，强行将自己的SS段与发送节点的SS段直接拉齐，然后按照位时序对信号进行采样，达到同步的效果。发送节点当前位的SS段诞生2Tq时长之后，接收节点当前位才产生SS段；发送节点在发送SOF位时，SOF位的下降沿在SS段，此时接收节点发现自己当前位的SS段和发送节点SOF位的SS段不同步，于是接收节点强行将自己的SS段拉到与SOF位的SS段同步。

同步段的Tq数是固定的1Tq，传播时间段的Tq数设为2Tq，相位缓冲段2的Tq数是根据采样率来计算，定义采样点在相位缓冲段1和相位缓冲段2之间，采样率为前三段的Tq数与四段的总Tq数比值的百分比，如下图，第1个采样率 =(7Tq/10Tq) x 100% = 70%，第2个采样率为60%。2）CAN时钟周期，由系统时钟分频而来的一个时间长度值，即类似于机器周期与晶振时钟周期的关系，按照特定的公式计算：CAN时钟周期 =2 x 晶振时钟周期 x BRP，其中，BRP叫做波特率分频值。首先，获取晶振时钟周期。

1 CAN总线定义继续之前例子，VCU和MCU采用CAN通讯进行信息交互，他俩是以两根双绞线的物理总线形式连接，一根称为CAN_H，另一个根称为CAN_L。在这两根CAN总线上，信号表现为电压形式，通过CAN_H和CAN_L线上的电位差来表示CAN信号。当CAN_H和CAN_L的电压均为2.5v，两者电压差为0v，就规定CAN信号为逻辑0；当CAN_H的电压为3.5v，CAN_L的电压为1.5v，两者电压差为2v，就规定CAN信号为逻辑1。

Node_A和Node_B都是标准格式，那么仲裁发生在11位ID范围，即从D10-D0，采用线与机制（逢0变0），逐位进行比较，一旦某位出现不同，如上图的ID7位，则显性位覆盖隐性位，仲裁结束，显性位的对应节点Node_A胜出。如果都一样，则标准格式的节点胜出，因为11位ID后1位，标准格式的RTR位恒为显性，扩展格式的SRR位恒为隐性，显性位的对应节点胜出。数据段的数据有几个字节，取决于控制段的数据长度码DLC的数值，DLC可以取0-15的值，但是它取9-15时没意义，因为已经超过数据段的长度。

本着从实际问题出发，信号如何从一个控制器传递到另一个控制器，本文展现了这么一个自然的思考过程，我想应该对本文的例子（VCU如何通过CAN通讯发送给MCU信号）有了一个初步的认识，当然，其中也引入CAN数据帧定义的相关内容，我想通过理论与实际相结合的方式，更有助于理解CAN标准或协议这些相对抽象的内容，甚至会发现这些标准或协议是如何精妙。显然，还需要额外的数据段来装剩下的信号，一个数据段不够，那就再用一个数据段，直到够用为止。比如目标转速请求信号通常占用16位，那就意味着数据段最多能放4个这样的信号。

那么，在软件中具体如何实现CAN通讯，包括两方面数据流和控制流，即一方面是数据是以怎样的形式在软件模块中传递，另一方面是CAN通讯相关的模块中，不同模块或同一模块的函数是怎样的调用关系。因此，不管你从事的具体是什么岗位，都可以去了解CAN通讯，总之自己的目标得定位好，比如你做系统集成的，别想着干底层软件的CAN通讯开发。对于汽车行业从业者，如何学习CAN通讯，最重要的是取决于你的岗位职责。，可能是不同的传输速率，CAN网络需要通过网关才能通讯，就如上图的动力网的安全带控制器与车身网的车门控制器通讯。

后面又接触了应用层软件中的CAN通讯模块，这时能模块中有做信号转换的逻辑，有做ID , checksum, rolling counter等信息检查的逻辑，有做信号有效性校验的逻辑，另外，也需要去CAN通讯模块的测试，比如使用CANalyzer或CANape发送一条报文，看软件是否按照预期的逻辑执行。最初接触CAN通讯，那时刚工作，在主机厂的研发部门，经常需要去车上采集和分析数据。这时，仍需要选定CAN的波特率，同时需要配置这个报文的发送ID和接收ID，还要选择A2L文件，然后再去选定测量信号和标定量。

上文介绍完了CAN通讯在系统层面的基本需求，最后再从利益相关者视角来回顾一下，如果你是客户，你会提哪些需求？首先，基于车载网络架构可知有几路CAN，与我的控制器产生信息交互的又有几路CAN，诊断和标定是否需要单独的1路CAN，这时我就可以确定该向供应商提需要几路CAN，是否需要配置终端电阻。然后，对于每路CAN的功能或性能要求是什么？需要支持哪些CAN类型，哪些CAN帧类型，哪些CAN帧格式，每条CAN的传输速率是多少，是否需要具备CAN唤醒功能，如果需要对唤醒方式是否有要求。

现代汽车有非常多的控制器（ECU，Electronic Control Unit）, 这些控制器可以实现各种各样的功能。有些功能只需要一个控制器就可以实现，而更多功能是需要多个控制器联合控制才能实现，这就意味着这些控制器之间需要进行信息交互，比如电机控制功能，电机控制器（MCU，Motor Control Unit）一方面需要获取整车控制器（VCU，Vehicle Control Unit）的目标电机扭矩或目标电机转速等信息，另一方面MCU需要反馈实际电机扭矩或实际电机转速等信息给VCU。