基于K线的汽车天窗马达ECU通讯系统的设计

　　Webasto 车顶供暖系统有限公司是世界著名的车顶供暖系统设备供应商，在中国占有大量市场份额。在将天窗马达装配到天窗之前，要进行多项操作和测试，具体包括：装配测试、短路测试、接地测试、软件版本验证、硬件版本验证、读取序列号、参数写入与读出和运转测试。参数写入与读出是整个周期中的一个重要的环节。参数写入的过程主要是将此参数的版本号信息、温度传感器、电流传感器、电压传感器上下限的值以及天窗滑动过程中的速度上限值等一些天窗运行过程中要满足的指标信息写入ECU中;而从ECU中读出的信息包括：此ECU的硬件和软件版本号，天窗在运行过程中滑动的位移、起翘的幅度、防夹力的大小和异常信息等一些与天窗性能相关的参数信息，这样操作人员就可以根据相应的情况迅速地分析和处理异常情况。

　　汽车天窗马达ECU通讯系统将成为操作人员、检测人员的帮手，因此设计它是非常必要的。本着携带方便、操作简单、软硬件的可移植性好、成本低廉等原则，此通讯系统由如下装置组成：一台笔记本电脑、一根串口线、一个通讯盒和一个与马达ECU连接的接插件(由Webasto车顶供暖系统有限公司提供)。

　　1 系统整体结构

　　此系统的硬件是基于ISO9141标准的K 线通讯方式，而其软件部分是基于Webasto通讯协议的可以同时操作*.par文件、*.s文件的通讯软件。系统结构如图1所示。

　　(1) .s文件与.par文件

　　这两种文件格式为ECU参数的不同编码方式，都记录了设备需要写入的 ECU的参数值。.s文件为标准MOTOROLA s-record，其代码是由ASCII格式的字符组成的，其中包含了存储数据的地址、数据长度、存储的数据以及校验码。.par文件包含了ECU具体参数的名称和值，需要与参数说明文件excel共同使用进行ECU的读写。

　　(2) File Decoder

　　读取、识别两种文件格式中的数据，储存在应用程序中供用户使用，并进行文件之间相互转换的操作。

　　(3) Message Handler

　　负责把应用程序中的参数数据按照Webasto Telegram SpecifICation格式打包准备发送，也负责把接收到的数据按照同样协议拆包，识别后保存在应用程序中。

　　(4) Communication Agent

　　应用程序通过调用该层次模块实现对串行通信接口的透明操作。

　　(5) COMM API

　　Windows串行接口API函数库。

　　(6) KBUS-232 ADAPTER

　　用来实现PC机到汽车天窗马达ECU信息传递的硬件单元。

　　2 硬件结构

　　此汽车天窗马达ECU通讯系统中，其所选的硬件是基于ISO9141通讯协议的K线通讯的，所以这里先说明一下K线通讯的特点，然后在此基础上说明此天窗马达ECU通讯系统设计时所采用的硬件结构。

　　2.1 诊断K线通讯特点

　　根据SAE规定的OBD标准，车辆行业使用K、L线进行诊断和标定。通过K线对某个控制单元进行查询，通过K线、测试仪和控制单元可进行数据交换。换句话说，即通过K线数据被双向传送(从测试仪到控制单元以及从控制单元到测试仪)。最近生产的车上都装有K线。而 L线则是用来对控制单元进行查询的导线，此线在目前生产的车辆中已经不存在。由于串口的普及，所以K线实现起来更容易。而逻辑电平的改变，只是需要转换电路。因此本系统采用K线的通讯方式。由于K线只是一根线，而PC机与控制单元都要向对方发出信息，所以可以判定此线是半双工串行通讯。

　　K线通讯主要有以下特点：

　　(1) 双方采用半双工异步串行通讯。

　　(2) 工作电压范围为8～18V。

　　(3) 使用环境温度为-40°C～125°C。

　　(4) 最大速度是50kbps。

　　(5) 支持大电流。

　　(6) 与单片机CMOS电平无缝连接。

　　(7) 具有对地线保护作用。

　　(8) 串行通讯码的每个单元包括10位二进制数据，分别为起始位、8位数据、停止位，每个单元发送完毕后设有空闲等待。

　　(9) 双方的通讯以“行”为单位轮流发送，即PC机发送一行消息后，ECU再发送一行消息，反之亦然。

　　(10) 一信息行由下列数据组成：第一位数据表示本行还要发送多少数据;第二个数据用来表示关键码，表示此次用来完成什么样的操作，如开始参数、写数据到EEPROM中等;第三个数据表示要发送的数据。

　　(11) 在一信息行中，还包括用于校验的反码，一方每发出一个数据后，对方必须对回应此数据的反码进行校验;由于K线是单线通讯，所以只有在正确处理回应数据的反码进行校验时，才能保证通讯的顺利进行。

　　(12) 至于PC机在每一个功能块中如何发出命令，ECU是如何给出相应信息的，在软件结构中会做说明。

　　2.2 K线通讯定义

　　在车辆网络中, 为准确、可靠地通讯,必须确定一个固定的通讯波特率。假设诊断设备及其连接导线的电容为CTE,K线对地电容为COBW,车辆ECU的电容为CECU,定义为:

　　设计时以上各电容必 须满足以下关系:

　　12V电源供电：CECU+COBW≤7.2nF;CTE≤2nF;24V电源供电：CECU+COBW≤5nF;CTE≤2nF。

　　假定K 线通讯波特率最大为10.4kbps,若通讯波特率高于最大波特率,则必须减小允许电容;反之,必须增加允许电容。同时，在车辆诊断网络设计时,必须保证任何ECU 信息不能引起其它ECU进行数据通讯,在诊断仪初始化时,只能有一个ECU响应,或若干个ECU按一定顺序响应。

　　2.3 K线电路连接方式

　　K 线通讯本质上为半双工串口通讯。为保证准确、可靠的数据通讯, ECU和K线都必须有正确的电平。在K线系统中,发送时若电压低于工作电压的20%, 则认为逻辑“0”,高于工作电压的80%，则定义为逻辑“1”;接收时低于工作电压的30%为逻辑“0”,高于工作电压的70%为逻辑“1”,电压在工作电压的30%～70%之间状态不确定。由以上分析可知,其电平与常用的串口电平不一致,因此必须设计专门的K 线接口电路,以满足车辆K 线诊断要求。图2 为利用L9637D完成的K 线接口转换电路。

　　K线可双向传递数据，系统初始化后先传递ECU地址，连接成功后用于信息交换，典型接口转换芯片有ST公司的L9637D和Motorola公司的33290等。L9637D是一个与ISO9141标准功能兼容的集成芯片，是专门为车辆诊断而开发的双向、半双工通讯接口芯片。

　　3 软件结构

　　此汽车天窗马达ECU通讯系统中所使用的参数主要有两种类型：*.s参数类型和*.par参数类型的文件。其主要的区别是：*.s参数文件所采用的代码格式是S-record，它是 Motorola 公司提供的一种标准文件格式，通过S-records代码，将可执行代码从主PC机发送到另外一个目标系统。在发送的过程中，S-records在其代码头上包含目标地址信息和校验信息来检验误差;而*.par参数文件是Webasto公司专用的代码格式，它的代码主要是包含在ECU中的具体参数和此参数的具体数值。此马达天窗ECU通讯系统的软件部分就是在对这两种参数类型熟悉的基础上进行的。

　　3.1 S-record格式说明

　　每个S-record由如下六部分组成：

　　(1) SOR：代码的开始部分(ASCII ‘S’);

　　(2) Type：S-record Type，有几种类型：

　　S0：代码起始段(可选)，表示在其后还有其他的代码。S0后面的地址代码不被使用，经常是(0X0000)，有的还包括额外的信息,如表1所示。

　　S0代码不被加载，可以被忽略，通常为S0030000 FC;

　　S1：16位地址的数据代码;

　　S2：24位地址的数据代码;

　　S3：32位地址的数据代码;

　　S4：不同的目标系统不同的含义;

　　S5：不同的目标系统不同的含义;

　　S6：不同的目标系统不同的含义;

　　S7：S3代码结束段;

　　S8：S2代码结束段;

　　S9：S1代码结束段;

　　如果S9代码后的地址代码为 0X0000，则表示数据段的结束;如果其后代码不为0，则地址代码表示其开始执行代码的位置，通常为S9030000FC(注：S0，S9代码是被忽略的);

　　(3) Length：两位十六进制数，表示Load Address、Code/Data、Checksum的字节数;

　　(4) Load Address: 4、6、8个ASCII字符，表示Code/Data要加载的目标地址。如s1,用4位十六进制数来表示要加载的地址;

　　(5) Code/Data：0～64个ASCII字符，表示加载到目标系统的实际代码;

　　(6) Checksum：检测在传送中是否有错误发生，它的求法如下：

　　(1+sump+checksum)mod256=0

　　注：sump 是length、Load Address、Code/Data中从左至右每两位十六进制数代表的十进制数值进行累加所得到的值。

　　3.2 *.par 参数说明

　　.par文件包含了ECU具体的参数名称和值，需要与参数说明文件excel共同使用进行ECU的读写。以图3为例解释excel中的信息和*.par文件代码的意义。

　　代码如下：

　　[NORMAL]

　　ucCarType=2

　　aucPartNumber[0]=17

　　其中包含的参数所代表的含义和参数具体值的信息如下：

　　(1) Location表示此par参数在excel中的位置，此例表示在NORMAL段;

　　(2) Addr.表 示代码在EEPROM中的存储地址信息;

　　(3) Parameter name表示代码参数的名称;

　　(4) Parameter description表示代码参数的含义;

　　(5) SpecifIC description对此代码进行特定的描述;

　　(6) Allowed value表示此代码取值的范围;

　　(7) Excel value表示此代码实际的数值，此例分别为2、17;

　　(8) S Value以ASCII码形式表示代码，此例分别为02、11;

　　(9) Drive Value表示通讯过程中实际发送和接收的数值;

　　(10) Parameter表示参数类型;

　　(11) C source表示此代码在ECU中，用哪段代码来表示;

　　(12) Type key表示此代码的数据类型。

　　注： 0 代表无符号字符

　　1 代表有符号字符

　　2 代表无符号的短整型

　　3 代表有符号的短整型

　　4 代表8 bit 数组

　　5 代表16 bit 数组

　　3.3 K线通讯协议及应用

　　ISO9141 主要为车辆与诊断设备之间的通讯国际标准, ISO9141已被美国加州大气委员会(California Air Resource Board)所采纳,其ISO14230为专门指定的用于道路车辆诊断的协议。根据ISO14230 的规定, K线通讯消息基本格式如表2 所示。

　　表2中各参数含义如下:

　　Fmt:帧字节;Tgt:目标地址;Src:源地址;Len:附加长度字节; Sld :功能识别字节;Data :数据字节;CS:校验和。

　　其校验和满足以下公式:

　　i={(i-1)+}mod256(1)

　　式(1)中:1=<1>。

　　K 线协议采用消息结构进行信息传递,可分为请求消息、指示消息和响应消息,其中，响应消息可分为正响应和负响应,所有这些消息都具有相同的结构。

　　Webasto汽车天窗马达ECU与PC机的通讯方式是K 线通讯协议的一种应用，其代码基本格式如下：长度位、命令标志位、数据位(n=0…16)和校验位，如表3所示。

　　所以最小的通讯长度为3，即：传输的信息包括LEN、ID、CHKSUM(传输的数据位数n=0)。

　　为了保证PC机与ECU之间的通讯正常，使用校验码来确保发送代码的安全性，它是通过所有代码的位与CHECKSUM_BASE=0xAA异或来求得。计算方法如下：

　　发送端的校验码:

　　CHKSUM_s=CHECKSUM_BASE xor LEN xor ID xor DATA_1 xor... xor DATA_n

　　接收端的校验码:

　　CHKSUM_r=LEN xor ID xor DATA_1 xor... xor DATA_n xor CHKSUM_s xor CHECKSUM_BASE

　　CHKSUM_r的结果为0，说明通讯顺利完成。

　　为了确保通讯正常，在串行通讯过程中，规定两个接收字节之间的时间不得超过50ms，若超过，则认为此次操作失败。

　　此汽车天窗马达ECU通讯系统软件的程序流程如图4所示。汽车天窗马达ECU通讯系统的软件运行如图5所示。

　　界面上半部分负责*.s参数读写的部分，下半部分负责*.par参数读写的部分。此系统的硬件和软件在Webasto车顶供暖系统有限公司的测试平台上已经通过验证。此系统对其天窗马达ECU进行参数读写、故障分析时，缩短了周期，大大提高了工作效率。

　　当前，汽车天窗市场多由国外厂商控制，价格昂贵，其马达检测系统的理念也是随着国外先进技术的引进而来的。因此，开发适合我国的汽车天窗马达ECU通讯系统不仅可以降低整车成本，还可以提高其国产化速度。现在越来越多的电控系统将在车辆上使用,这些设备都可通过K 线使PC机与ECU进行信息交换,以满足实际车辆使用和维护的要求。同时K线也可进行电控标定系统的开发,因此,本研究工程应用前景非常广泛。