[总线技术]汽车ECU网络传输-诊断协议测试-基于Canoe软件CAPL脚本编写

一．汽车电子电控结构

先介绍一下汽车电子电控的结构，汽车并不像电脑一样，只有一个CPU，而是分为多个“CPU”独立工作，就是由很多很多个控制器组成的，比如：ABS（防抱死系统）、AC(空调控制器)、VCU(整车控制器)、BMS(电池管理系统-电动/混动车才有)等等。每一个控制器负责不同的功能，把各个控制器安装在车身的不同位置，再通过线束连接，就组成了汽车。

汽车电子结构中比较重要的部分就是电源和通信了，先说下电源。一般来说汽车电源分为两种电，一种是30电，也就是常电，由蓄电池供电，是主要的用电器的用电来源；第二种是IG电，也就是15电，点火开关的电源，就是钥匙拧到ON档的时候才会有的电。

那各个控制器是如何进行通信的呢？

一般来说，汽车大部分控制器都是用的是Can总线网络通信，有少数几个功能不是很重要的控制器可以用Lin总线通信（例如：雨刷等等），每个汽车使用的都是不一样的。听说特斯拉没有线束？都是无线的？没有接触过就不说了吧。现在比较流行的是，使用以太网通信代替了Can通信，以太网通信的好处就是数据传输可以更多更快，例如OTA刷新程序的时候，刷新1MB的更新文件，用Can的话，要刷5分钟左右，用以太网刷新基本在十几秒就可以结束（实测），但是用以太网可能更贵吧，不过应该是以后的方向，数据量大的控制器更需要以太网，例如：多媒体、大屏这些都有UI界面的。

难道汽车上所有的Can通信的线都接到一起？并不是的！

整车上并不是把所有的Can线都连到一起的，也是需要分类的。一般分为5类：

  1.PT CAN (PowerTrain CAN ) 动力总成CAN总线。

  2.CH CAN (Chassis CAN) 底盘控制CAN总线。

  3.Body CAN车身控制总线。

  4.Info CAN ( Infomercial CAN ) 信息娱乐系统总线。

  5.DiagCAN ( Diagnose CAN ) 诊断控制总线。

GW是网关，所有的Can总线都连接到网关上面。上图是某个汽车的网络拓扑，它没有信息娱乐Can，OBD就是诊断控制总线，接口一般就在驾驶员侧。

二．测试工具

一般来说，使用Can总线工具都可以，只要是Can总线的设备，都可以通过连接OBD接口读取数据。或者直接连接控制的Can总线。如果直接连接的是控制器的Can接口，那么就是与该控制器进行通信，如果连接的是OBD接口，那就是整车的数据。

介绍一下比较常用的工具Canoe，是Vector公司的产品，主要用于汽车Can总线测试，我这里使用的硬件设备是1640A，4路Can通道，2路Lin通道。对应的软件使用的是Canoe 11.0（软件License和硬件的价格大概在30W左右）。

这里说一下Canoe工具的用法，因为我就是用的Canoe进行诊断测试。

Canoe的强大的地方很多，其中一项就是有一个独有的编译开发软件CAPL，CAPL就是一个编译器，在CAPL里面编写代码，编译后可以在Canoe中运行。一般都是在CAPL编写自动化测试脚本，在Canoe中自动发送一些你想要的Can报文，或者判断接收的Can报文。下图是正在使用Canoe进行发送和接收报文。

三．自动化测试脚本建立

具体说一下如何建立CAPL自动化测试脚本。

1. 首先打开Canoe，在Simulation中，找到Simulation Setup，点击。在红蓝线的地方右键，然后选择CAPL Test Modle。

2. 会出现一个Test 1的方块，点击小铅笔图标，弹出对话框，这时要新建一个CAPL的程序文件，扩展名为.Can。

3.  输入新建的文件名后会自动弹出CAPL编辑的界面。之后就需要在这里编写测试脚本代码了。Includes{}里面是包含的头文件，variables{}是全局变量。

 

四．自动化测试脚本的编写

CAPL有一套自己的编程语言和方法，属于类C，学过C语言的入手超级快。基本和C语言差不多。

我们要进行诊断UDS相关的测试，所以首先要了解UDS诊断是什么？

UDS就是统一诊断服务，比如读取故障码、读取版本号、控制相关IO等等，诊断的东西说起来太多了，有需要的先去看一下ISO-14229和ISO-15765。

1. Includes{}里面是包含的头文件，我们还用不到，暂时不用管。variables{}是定义全局变量的地方，如果我们需要定义一些全局变量，就需要在里面定义了(不能像单片机那种在外面定义，只能在括号里面定义)。

2. 因为我们先要发送报文，所以首先要建立一帧报文。message * req,resp;这里message是报文的定义变量，建立了两个报文，一个req，一个resp，req是我们要发送的报文，resp是我们一会要接收的报文，先定义上。

3. 之后需要建立一个MainTest函数，类似单片机main()的原理，程序会在这个函数里面运行。

4. 之后就可以编辑报文内容并发送了。首先定义报文的长度为8，req.dlc=8;定义报文的ID为0x7DF(诊断的功能寻址请求ID)，req.id = 0x7DF;然后定义报文8个byte的内容，这里定义的是诊断功能寻址进入扩展会话模式，02 10 03。

5. 最后就是发送报文了，outout()是发送报文的函数，直接调用即可，output(req);点击左上角Compile编译，OK，没问题，之后就可以进入Canoe中运行试试了。

Canoe根据自己连接的通道配置好，点击运行。

运行后并没有发出我们编写的报文，为什么呢？

我们可以调试一下。

打印一些调试信息出来，使用write()函数，类似C的printf()，在MainTest的开始加上write(“运行开始”);之后加个延时函数testwaitfortimeout(1000)，延时1秒，在最后增加write(“运行结束”);再次编译运行。

这里明显看出来，write窗口并没有打印出我们的调试信息，看来是这个Test模块没有运行。

后来发现，CAPL模块还需要配置一下，让它立马运行。需要在test的方块上右键，选择Configuration，之后immediately打上勾就可以了，点击OK。

现在再运行一下看看。

OK，我们编辑的报文发出来了，并且控制器也给了响应的回复报文-06 50 03 00 32 00 C8 6E，进入扩展会话成功！

6. 接下来编写一下如何判断我们想要接收的指定报文。使用testWaitForMessage(resp.id,5100)函数，等待指定的报文，参数resp.id是我们要接收的报文ID，5100就是在5100ms内等待。testGetWaitEventMsgData(resp);获取这帧报文的内容，并通过write打印出来。

我们运行调试一下看看。

接收报文没有问题，数据也获取的正确。

五．总结

做了一篇汽车诊断测试脚本CAPL的编写与调试的简介，主要介绍了使用Canoe软件自带的CAPL插件，编写测试用例，根据发送和接收报文的处理，可以做一个复杂的自动化测试脚本，遍历测试等待。附件上传了Canoe 11.0的工程，有需要的朋友可以下载下来试试。欢迎大家提问。
---------------------
作者：小叶三千
链接：https://bbs.21ic.com/icview-3133628-1-1.html
来源：21ic.com
此文章已获得原创/原创奖标签，著作权归21ic所有，任何人未经允许禁止转载。