Autosar CAN开发06（CAN通讯开发需求-CAN矩阵）

前言

    在这之前，我们已经了解了CAN总线的相关概念，那么接下来，我们就看看汽车行业CAN总线相关的开发需求。

    当然了朋友们，CAN相关的开发内容是非常多的，比如应用报文开发、网管报文开发、诊断报文开发、XCP开发、CAN时间同步报文开发、J1939等等，这些都属于CAN报文开发的范畴。

    在这里我们先只讲一下最简单、最常用、同时也是最重要的：应用报文开发。至于其它内容，我们后续会在其它文章单独讲解。

应用报文概念

    这应用二字，实际上跟我们工作常说的应用层中的应用是一个意思。我们开发一个项目，最重要的目的是啥？就是用这个东西的应用功能嘛对吧。

    举个栗子：

    比如车上的仪表。

    它功能就是用来显示各种车身数据，比如显示车速，仪表仅靠自己肯定是不能知道车速的，它只能是车上的其它管车速的地方，把车速传过来，然后仪表收到后，就把车速显示出来。

    当这个车速信号是通过CAN报文传过来的时候，这个CAN报文就叫做CAN应用报文。

    实际上，车上那么多ECU，每个ECU都需要其它节点传过来的各种数据，比如ECU-A工作需要使用ECU-B的车门开关状态、转向灯状态。ECU-B工作又要用ECU-C的温度、电压等等。

    而这些传来传去的，用于应用功能数据传输的报文，叫做应用报文。

    为什么说它最重要呢？

    因为如果缺了应用报文，整个东西的主要功能就废了。

    比如有一个牛逼的风扇，它能休眠低功耗（网管报文）、能接上诊断仪升级（诊断报文）等等，但它主要应用功能是干啥？用来吹风嘛对吧，但如果它直接不吹了，那还休眠个啥，升级个啥？

    ...

    在企业中，当某个项目刚开始时，车企会只要求ECU实现应用报文的功能，使得车上的应用功能能正常就可以了，至于网管报文、XCP、诊断等等，这些报文功能，推迟一点实现是没问题的。

应用报文需求（CAN矩阵）

1、背景介绍

知道啥是CAN矩阵的朋友，可以跳过这一节。

    CAN矩阵就是关于CAN应用报文的需求。

    在了解什么是CAN矩阵之前，我们需要了解一下实际车企与各个供应商之间的一个背景。

    大家都知道，一辆车的组成是非常复杂的，车上的不同零部件来源于不同的零部件供应商。

    举个简单的栗子。

    某大车企甲，它要造一辆车。

    这辆车上有3个ECU：ECU_A、ECU_B、ECU_C。它们分别来自于供应商A、B、C。

    那么问题来了。

    我们前面说过，一辆车要正常跑起来，各个ECU之间会有大量的数据交互，ECU_A可能用到其它两个ECU传过来的数据，ECU_B、ECU_C也是一样的情况。

    但是，供应商A、B、C是车企甲的客户，供应商A、B、C之间是不认识的。

    那咋办？总不能车企甲把他们3个拉出来吃顿饭认识一下吧？

    所以车企想了个办法。

    由于车企是统筹这辆车的，是知道每个ECU要干什么事情的。

    于是，车企把ECU_A要从其它两个ECU接收的数据、以及ECU_A要发送给其它两个ECU的数据整理到一个EXCEL表里，然后释放给ECU_A。对于其它两个ECU，车企也是如此操作。(也可能都给一模一样的CAN矩阵，但这个CAN矩阵会包含3个ECU节点所有接收、发生的报文信号)

    有了这个EXCEL，供应商之间就不用去认识彼此了。供应商开发功能的时候，对着EXCEL表开搞就行。

    而这个EXCEL，对于供应商来说，就是所谓的应用报文需求，也既CAN矩阵。

2、认识CAN矩阵

    了解了CAN矩阵的背景后，接下来，我来看一下CAN矩阵里面都有啥，以及它们是什么意思。

   首次接触的朋友看到这CAN矩阵估计会有点懵，不明白里面的意思。

   我们接下来一一讲解。

2.1 CAN报文（Message）

    首先，我们来看看CAN矩阵里面关于CAN报文的相关属性。

    另外说明一下，以下报文属性的名称在不同车企的CAN矩阵中，使用的名字不一，只要表达了对应意思即可。

2.1.1 报文名称（Message Name）

    每条报文都必须有属于自己的名称，但这个名称唯一的作用就是给别人（工程师）看的。

    从实际物理层面，在CAN数据传输时，没有报文名称这个东西。

2.1.1 报文长度（Message Length）

    既报文数据长度。（单位为byte）

    普通格式的CAN报文的数据长度最长是8 Byte，CANFD格式的CAN报文长度最长是64Byte。

2.1.3 报文ID（Message ID）

    对于标准格式CAN报文，CANID范围为0x0～0x7FF（占用11bit）。

    对于扩展格式CAN报文，CANID范围为0x0~0x1FFFFFFF(占用29bit)

2.1.4 报文类型（Message Type）   

    即下列的四种格式。（上图所示CAN报文类型为标准CAN格式）

 2.1.5 报文发送类型（Message Send Type）

（上图所示3条报文都是周期报文）

    周期报文：报文按照固定周期发送

    事件报文：报文在某事件触发后按照约定周期发送n帧该报文。至于这个事件是什么，则是客户去定的

    周期事件报文：报文在正常情况下按照固定周期发送，在某事件触发后，则按照事件触发后的约定周期快速发送n帧报文

2.1.6 报文发送周期（Period）

    即报文固定发送的周期（仅针对周期报文、周期事件报文）。

2.1.7 报文重复发送次数(Number of Repetition)

    即某事件触发后，报文重复发送的次数（仅针对事件报文、周期事件报文）。

2.1.8 报文重复发送周期(Repetition cycle time，待修改)

    即报文重复发送的周期（仅针对事件报文、周期事件报文）。

2.2 CAN信号（Signal）

   关于CAN信号，我们先举个栗子去理解一下什么是CAN信号。

    比如有一个车门开关的信号"Signal_DoorState"。它的值只有0或1，因此，它只需要占用1个bit，如下图所示。

    从这里大家应该看出来了，一个报文可以放很多CAN信号，具体能放多少，取决于报文总长度以及每个信号的长度。（比如上图，这个0x123报文只放了2个信号，空白的地方都没用上。）

    再比如一帧CANFD、64Byte的报文，总共有64*8=512个bit，如果每个bit都放一个信号，总共有512个信号。

    好了，接下来，我们来看看CAN信号的相关属性。

2.2.1 信号名称（Signal Name）

    跟报文名称一样，每个信号都必须有属于自己的信号名称，但这个名称唯一的作用就是给别人（工程师）看的。

    从实际物理层面，在CAN数据传输时，没有报文名称这个东西。

2.2.2 信号大小（Signal Size)

    即信号的长度。（单位为Bit）

2.2.3 信号排列（Byte Order）

    信号排列方式有2种：Motorola、Intel。Motorola即我们常说的大端，Intel即小端。

    所谓的大端，即高字节在前面，小端则是低字节在前面。

    这是啥意思呢？

    首先从字面意思要注意到的一点：如果信号没有跨字节，就没有大小端的说法，因为它只在一个字节里面，哪有高低字节之说。

    因此，大端小端是针对跨字节的信号的。

    接下来，举个栗子理解大小端。

    假设一个信号叫做车速：VehicleSpeed，它的信号大小是16个bit(2Byte)。如果我现在传条8Byte的报文给你，并告诉你，Byte4-Byte5就是这个车速信号的值。

    于是，收到数据后，你把数据从报文里面提取出来，得到Byte4是0x01，Byte5是0x02。

    接下来，需要把2个数据组合起来才能得到这个信号真正的值。

    是0x0102 ？还是0x0201呢？顺序一变，这个车速值可是天差地别。

    所以，在信号传给你之前，我还需要告诉你，这个跨字节的信号是怎么样的排序方式。

2.2.3.1 大端

    如果我说是大端：则高字节在前。

    所谓高，是指信号值的高字节。

    所谓前，则是指数据在CAN总线传输的顺序中位于前，显然Byte4前于Byte5

    因此，VehicleSpeed ＝ 0x0102。（即，在前面的Byte4（0x01）是信号的高字节。如下图所示）

    Motorola格式，在报文Layout中，信号排列顺序如下图所指示方向。

2.2.3.2 小端

    如果我说是小端：即低字节在前。

    所谓低，是指信号值的低字节。

    所谓前，则是指数据在CAN总线传输的顺序中位于前，显然Byte4前于Byte5

    因此，VehicleSpeed ＝ 0x0201。（即，在前面的Byte4（0x01）是信号的低字节。如下图所示）

    Intel格式，在报文Layout中，信号排列顺序如下图所指示方向。

2.2.4 信号起始位、结束位(Lsb/Msb)

    即信号在报文里面的起始位置。如我们上面讲到的CarSpeed信号

    如果是Intel格式，Lsb 为32，Msb为47

    如果是Motorola格式，Lsb 为40，Msb为39

    实际上，CAN矩阵里面一般只提供Lsb。（少数企业提供Msb），但效果都是一样的。

    比如只知道了Lsb，再知道信号排列和信号大小，就能算出Msb的位置了。因此如果Lsb和Msb两个都给就反而多余了。

2.2.5 信号精度（Factor）

    信号精度，有些CAN矩阵里面也叫做Resolution。

2.2.6 信号偏移（Offset）

    信号精度和信号偏移两者是放在一起的。他们的作用是用在一条公式里面：

(Physical value) = (Raw value) * (Factor)+ Offset

    我们来看看Physical value和Raw value的意思。

    所谓Raw value，即原始值，就是在CAN总线上传输的值，如下图所示：

    大家也看出来了，总线传不了浮点型的数据，以及如果传有符号的数据会比较麻烦(指定信号某个位代表正负)。

    于是，Factor和Offset就出来了。比如我要传一个温度数据：-12.5°

    那么，在数据传输前，我先把数据转换一下（假设Factor是0.5，Offset是-20）：

    (-12.5) = (Raw value) * (0.5)+ (-20)

    即Raw value为15，十六进制表示为0x0F。当别人收到0x0F的时候，则按照约定好的Factor和Offset再转换一下，就能得到-12.5了。

2.2.7 信号初始值（Init Value）

    信号初始值的作用也是非常大的。

    对与发送报文信号来说，当ECU刚启动时，通常会要求在最短的时间内发出固定周期的报文信号。

    此时由于很多功能还没跑起来或者相关功能没有计算出数据，这时候报文数据就需要发出CAN矩阵里面指定的默认值。

    对与接收报文信号也是一样的，在ECU刚启动时，别人可能还没发出报文数据，这时候你就要先使用默认值了。

2.2.7 信号最大值、最小值（Minimum/Maximum）

    这没啥好说的，即字面意思。

    但是大家需要注意，这两个值在CAN物理层面上也是没有任何作用的。因为总线传输信号，一个信号的最大值最小值实际上取决于它的信号长度。

    比如，信号长度是4个bit，这里从物理层已经限制了它的最大值是15了。

    至于CAN矩阵里面的最大最小值，通常是用于应用层实现功能时做限制。

2.2.7 发送节点（Sender）

    即此报文的发送方，且发送方有且只能是一个ECU，

2.2.7 接收节点（Receiver）

    即此信号的接收方，接收方可以是多个ECU。

---

    下一篇文章，我们就基于CAN矩阵需求去实现对应的功能。

返回目录：

Autosar BSW 开发笔记（目录）-CSDN博客