一．汽车电子电控结构

先介绍一下汽车电子电控的结构，汽车并不像电脑一样，只有一个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。

现在比较流行的是，使用以太网通信代替了Can通信，以太网通信的好处就是数据传输可以更多更快，例如OTA刷新程序的时候，刷新1MB的更新文件，用Can的话，要刷5分钟左右，用以太网刷新基本在十几秒就可以结束（实测），但是用以太网可能更贵吧，不过应该是以后的方向，数据量大的控制器更需要以太网，例如：多媒体、大屏这些都有UI界面的。这里message是报文的定义变量，建立了两个报文，一个req，一个resp，req是我们要发送的报文，resp是我们一会要接收的报文，先定义上。或者直接连接控制的Can总线。 CPAL 脚本 自动化测试 ———— 信号 测试 系列函数及使用 CPAL 脚本 自动化测试 ———— Flexray系列函数及使用 CPAL 脚本 自动化测试 ———— FDX系列函数及使用 CPAL 脚本 自动化测试 ———— 诊断 模块之参数赋值 CPAL 脚本 自动化测试 ———— Message的相关属性 CPAL 脚本 自动化测试 ———— 诊断 模块的安全解锁函数分析 1. 打开 CA N oe 软件 ，创建一个新的配置文件，设置好相应的硬件接口、波特率等参数。 2. 在配置文件中打开一个新的 测试 模块，选择 CA PL 编辑器，开始编写验证预期帧接收的 测试 脚本 。 3. 首先，定义一个消息的结构体，包括消息的 ID、数据长度和数据内容等信息。 4. 接着，使用 `on message` 事件来捕获收到的消息。在事件中，可以通过 `message` 对象获取到收到的消息的 ID 和数据内容等信息。 5. 对于每个收到的消息，都需要判断它是否为预期的消息。如果是，就可以进行相应的操作，如打印消息内容、修改数据内容等。 6. 最后，通过向 CA N oe 发送预期的消息来验证系统的响应。可以使用 `output` 函数来发送消息，同时可以设置发送消息的 ID 和数据内容等信息。 需要注意的是， CA PL 脚本编写 的关键在于对事件和函数的理解和使用。只有深入掌握了这些内容，才能编写出高效、准确的 测试 脚本 。