Webasto車頂供暖系統有限公司是世界著名的車頂供暖系統設備供應商，在中國占有大量市場份額。

在將天窗馬達裝配到天窗之前，要進行多項操作和測試，具體包括：裝配測試、短路測試、接地測試、軟件版本驗證、硬件版本驗證、讀取序列號、參數寫入與讀出和運轉測試。參數寫入與讀出是整個周期中的一個重要的環節。參數寫入的過程主要是將此參數的版本號信息、溫度傳感器、電流傳感器、電壓傳感器上下限的值以及天窗滑動過程中的速度上限值等一些天窗運行過程中要滿足的指標信息寫入ECU中;而從ECU中讀出的信息包括：此ECU的硬件和軟件版本號，天窗在運行過程中滑動的位移、起翹的幅度、防夾力的大小和異常信息等一些與天窗性能相關的參數信息，這樣操作人員就可以根據相應的情況迅速地分析和處理異常情況。

汽車天窗馬達ECU通訊系統將成為操作人員、檢測人員的幫手，因此設計它是非常必要的。本著攜帶方便、操作簡單、軟硬件的可移植性好、成本低廉等原則，此通訊系統由如下裝置組成：一臺筆記本電腦、一根串口線、一個通訊盒和一個與馬達ECU連接的接插件(由Webasto車頂供暖系統有限公司提供)。

1 系統整體結構

此系統的硬件是基于ISO9141標準的K 線通訊方式，而其軟件部分是基于Webasto通訊協議的可以同時操作*.par文件、*.s文件的通訊軟件。

這兩種文件格式為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 線診斷要求。

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，即：傳輸的信息包括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通訊系統軟件的程序流程。汽車天窗馬達ECU通訊系統的軟件運行如圖5所示。

界面上半部分負責*.s參數讀寫的部分，下半部分負責*.par參數讀寫的部分。此系統的硬件和軟件在Webasto車頂供暖系統有限公司的測試平臺上已經通過驗證。此系統對其天窗馬達ECU進行參數讀寫、故障分析時，縮短了周期，大大提高了工作效率。

當前，汽車天窗市場多由國外廠商控制，價格昂貴，其馬達檢測系統的理念也是隨著國外先進技術的引進而來的。因此，開發適合我國的汽車天窗馬達ECU通訊系統不僅可以降低整車成本，還可以提高其國產化速度。現在越來越多的電控系統將在車輛上使用,這些設備都可通過K 線使PC機與ECU進行信息交換,以滿足實際車輛使用和維護的要求。同時K線也可進行電控標定系統的開發,因此,本研究工程應用前景非常廣泛。