|
Webasto車(chē)頂供暖系統有限公司是世界著(zhù)名的車(chē)頂供暖系統設備供應商，在中國占有大量市場(chǎng)份額。在將天窗馬達裝配到天窗之前，要進(jìn)行多項操作和測試，具體包括：裝配測試、短路測試、接地測試、軟件版本驗證、硬件版本驗證、讀取序列號、參數寫(xiě)入與讀出和運轉測試。參數寫(xiě)入與讀出是整個(gè)周期中的一個(gè)重要的環(huán)節。參數寫(xiě)入的過(guò)程主要是將此參數的版本號信息、溫度傳感器、電流傳感器、電壓傳感器上下限的值以及天窗滑動(dòng)過(guò)程中的速度上限值等一些天窗運行過(guò)程中要滿(mǎn)足的指標信息寫(xiě)入ECU中;而從ECU中讀出的信息包括：此ECU的硬件和軟件版本號，天窗在運行過(guò)程中滑動(dòng)的位移、起翹的幅度、防夾力的大小和異常信息等一些與天窗性能相關(guān)的參數信息，這樣操作人員就可以根據相應的情況迅速地分析和處理異常情況。 汽車(chē)天窗馬達ECU通訊系統將成為操作人員、檢測人員的幫手，因此設計它是非常必要的。本著(zhù)攜帶方便、操作簡(jiǎn)單、軟硬件的可移植性好、成本低廉等原則，此通訊系統由如下裝置組成：一臺筆記本電腦、一根串口線(xiàn)、一個(gè)通訊盒和一個(gè)與馬達ECU連接的接插件(由Webasto車(chē)頂供暖系統有限公司提供)。 1 系統整體結構 此系統的硬件是基于ISO9141標準的K 線(xiàn)通訊方式，而其軟件部分是基于Webasto通訊協(xié)議的可以同時(shí)操作*.par文件、*.s文件的通訊軟件。系統結構如圖1所示。 (1) .s文件與.par文件 這兩種文件格式為ECU參數的不同編碼方式，都記錄了設備需要寫(xiě)入的ECU的參數值。.s文件為標準MOTOROLA s-record，其代碼是由ASCII格式的字符組成的，其中包含了存儲數據的地址、數據長(cháng)度、存儲的數據以及校驗碼。.par文件包含了ECU具體參數的名稱(chēng)和值，需要與參數說(shuō)明文件excel共同使用進(jìn)行ECU的讀寫(xiě)。 (2) File Decoder 讀取、識別兩種文件格式中的數據，儲存在應用程序中供用戶(hù)使用，并進(jìn)行文件之間相互轉換的操作。 (3) Message Handler 負責把應用程序中的參數數據按照Webasto Telegram Specification格式打包準備發(fā)送，也負責把接收到的數據按照同樣協(xié)議拆包，識別后保存在應用程序中。 (4) Communication Agent 應用程序通過(guò)調用該層次模塊實(shí)現對串行通信接口的透明操作。 (5) COMM API Windows串行接口A(yíng)PI函數庫。 (6) KBUS-232 ADAPTER 用來(lái)實(shí)現PC機到汽車(chē)天窗馬達ECU信息傳遞的硬件單元。 2 硬件結構 此汽車(chē)天窗馬達ECU通訊系統中，其所選的硬件是基于ISO9141通訊協(xié)議的K線(xiàn)通訊的，所以這里先說(shuō)明一下K線(xiàn)通訊的特點(diǎn)，然后在此基礎上說(shuō)明此天窗馬達ECU通訊系統設計時(shí)所采用的硬件結構。 2.1 診斷K線(xiàn)通訊特點(diǎn) 根據SAE規定的OBD標準，車(chē)輛行業(yè)使用K、L線(xiàn)進(jìn)行診斷和標定。通過(guò)K線(xiàn)對某個(gè)控制單元進(jìn)行查詢(xún)，通過(guò)K線(xiàn)、測試儀和控制單元可進(jìn)行數據交換。換句話(huà)說(shuō)，即通過(guò)K線(xiàn)數據被雙向傳送（從測試儀到控制單元以及從控制單元到測試儀）。最近生產(chǎn)的車(chē)上都裝有K線(xiàn)。而 L線(xiàn)則是用來(lái)對控制單元進(jìn)行查詢(xún)的導線(xiàn)，此線(xiàn)在目前生產(chǎn)的車(chē)輛中已經(jīng)不存在。由于串口的普及，所以K線(xiàn)實(shí)現起來(lái)更容易。而邏輯電平的改變，只是需要轉換電路。因此本系統采用K線(xiàn)的通訊方式。由于K線(xiàn)只是一根線(xiàn)，而PC機與控制單元都要向對方發(fā)出信息，所以可以判定此線(xiàn)是半雙工串行通訊。 K線(xiàn)通訊主要有以下特點(diǎn)： (1) 雙方采用半雙工異步串行通訊。 (2) 工作電壓范圍為8～18V。 (3) 使用環(huán)境溫度為－40°C～125°C。 (4) 最大速度是50kbps。 (5) 支持大電流。 (6) 與單片機CMOS電平無(wú)縫連接。 (7) 具有對地線(xiàn)保護作用。 (8) 串行通訊碼的每個(gè)單元包括10位二進(jìn)制數據，分別為起始位、8位數據、停止位，每個(gè)單元發(fā)送完畢后設有空閑等待。 (9) 雙方的通訊以“行”為單位輪流發(fā)送，即PC機發(fā)送一行消息后，ECU再發(fā)送一行消息，反之亦然。 (10) 一信息行由下列數據組成：第一位數據表示本行還要發(fā)送多少數據；第二個(gè)數據用來(lái)表示關(guān)鍵碼，表示此次用來(lái)完成什么樣的操作，如開(kāi)始參數、寫(xiě)數據到EEPROM中等；第三個(gè)數據表示要發(fā)送的數據。 (11) 在一信息行中，還包括用于校驗的反碼，一方每發(fā)出一個(gè)數據后，對方必須對回應此數據的反碼進(jìn)行校驗；由于K線(xiàn)是單線(xiàn)通訊，所以只有在正確處理回應數據的反碼進(jìn)行校驗時(shí)，才能保證通訊的順利進(jìn)行。 (12) 至于PC機在每一個(gè)功能塊中如何發(fā)出命令，ECU是如何給出相應信息的，在軟件結構中會(huì )做說(shuō)明。 2.2 K線(xiàn)通訊定義 在車(chē)輛網(wǎng)絡(luò )中,為準確、可靠地通訊,必須確定一個(gè)固定的通訊波特率。假設診斷設備及其連接導線(xiàn)的電容為CTE,K線(xiàn)對地電容為COBW,車(chē)輛ECU的電容為CECU,定義為: 設計時(shí)以上各電容必須滿(mǎn)足以下關(guān)系: 12V電源供電：CECU+COBW≤7.2nF;CTE≤2nF;24V電源供電：CECU+COBW≤5nF；CTE≤2nF。 假定K 線(xiàn)通訊波特率最大為10.4kbps,若通訊波特率高于最大波特率,則必須減小允許電容;反之,必須增加允許電容。同時(shí)，在車(chē)輛診斷網(wǎng)絡(luò )設計時(shí),必須保證任何ECU 信息不能引起其它ECU進(jìn)行數據通訊,在診斷儀初始化時(shí),只能有一個(gè)ECU響應,或若干個(gè)ECU按一定順序響應。 2.3 K線(xiàn)電路連接方式 K 線(xiàn)通訊本質(zhì)上為半雙工串口通訊。為保證準確、可靠的數據通訊, ECU和K線(xiàn)都必須有正確的電平。在K線(xiàn)系統中,發(fā)送時(shí)若電壓低于工作電壓的20%, 則認為邏輯“0”,高于工作電壓的80%，則定義為邏輯“1”;接收時(shí)低于工作電壓的30%為邏輯“0”,高于工作電壓的70%為邏輯“1”,電壓在工作電壓的30%～70%之間狀態(tài)不確定。由以上分析可知,其電平與常用的串口電平不一致,因此必須設計專(zhuān)門(mén)的K 線(xiàn)接口電路,以滿(mǎn)足車(chē)輛K 線(xiàn)診斷要求。圖2 為利用L9637D完成的K 線(xiàn)接口轉換電路。 K線(xiàn)可雙向傳遞數據，系統初始化后先傳遞ECU地址，連接成功后用于信息交換，典型接口轉換芯片有ST公司的L9637D和Motorola公司的33290等。L9637D是一個(gè)與ISO9141標準功能兼容的集成芯片，是專(zhuān)門(mén)為車(chē)輛診斷而開(kāi)發(fā)的雙向、半雙工通訊接口芯片。 3 軟件結構 此汽車(chē)天窗馬達ECU通訊系統中所使用的參數主要有兩種類(lèi)型：*.s參數類(lèi)型和*.par參數類(lèi)型的文件。其主要的區別是：*.s參數文件所采用的代碼格式是S-record，它是 Motorola 公司提供的一種標準文件格式，通過(guò)S－records代碼，將可執行代碼從主PC機發(fā)送到另外一個(gè)目標系統。在發(fā)送的過(guò)程中，S－records在其代碼頭上包含目標地址信息和校驗信息來(lái)檢驗誤差；而*.par參數文件是Webasto公司專(zhuān)用的代碼格式，它的代碼主要是包含在ECU中的具體參數和此參數的具體數值。此馬達天窗ECU通訊系統的軟件部分就是在對這兩種參數類(lèi)型熟悉的基礎上進(jìn)行的。 3.1 S-record格式說(shuō)明 每個(gè)S－record由如下六部分組成： (1) SOR：代碼的開(kāi)始部分（ASCII ‘S’）； (2) Type：S－record Type，有幾種類(lèi)型： S0：代碼起始段（可選），表示在其后還有其他的代碼。S0后面的地址代碼不被使用，經(jīng)常是（0X0000），有的還包括額外的信息,如表1所示。 S0代碼不被加載，可以被忽略，通常為S0030000 FC； S1：16位地址的數據代碼； S2：24位地址的數據代碼； S3：32位地址的數據代碼； S4：不同的目標系統不同的含義； S5：不同的目標系統不同的含義； S6：不同的目標系統不同的含義； S7：S3代碼結束段； S8：S2代碼結束段； S9：S1代碼結束段； 如果S9代碼后的地址代碼為 0X0000，則表示數據段的結束；如果其后代碼不為0，則地址代碼表示其開(kāi)始執行代碼的位置，通常為S9030000FC（注：S0，S9代碼是被忽略的）； (3) Length：兩位十六進(jìn)制數，表示Load Address、Code/Data、Checksum的字節數； (4) Load Address: 4、6、8個(gè)ASCII字符，表示Code/Data要加載的目標地址。如s1,用4位十六進(jìn)制數來(lái)表示要加載的地址； (5) Code/Data：0～64個(gè)ASCII字符，表示加載到目標系統的實(shí)際代碼； (6) Checksum：檢測在傳送中是否有錯誤發(fā)生，它的求法如下： (1+sump+checksum)mod256=0 注：sump 是length、Load Address、Code/Data中從左至右每?jì)晌皇M(jìn)制數代表的十進(jìn)制數值進(jìn)行累加所得到的值。 3.2 *.par 參數說(shuō)明 .par文件包含了ECU具體的參數名稱(chēng)和值，需要與參數說(shuō)明文件excel共同使用進(jìn)行ECU的讀寫(xiě)。以圖3為例解釋excel中的信息和*.par文件代碼的意義。 代碼如下： [NORMAL] ucCarType=2 aucPartNumber[0]=17 其中包含的參數所代表的含義和參數具體值的信息如下： (1) Location表示此par參數在excel中的位置，此例表示在NORMAL段； (2) Addr.表示代碼在EEPROM中的存儲地址信息； (3) Parameter name表示代碼參數的名稱(chēng)； (4) Parameter description表示代碼參數的含義； (5) Specific description對此代碼進(jìn)行特定的描述； (6) Allowed value表示此代碼取值的范圍； (7) Excel value表示此代碼實(shí)際的數值，此例分別為2、17； (8) S Value以ASCII碼形式表示代碼，此例分別為02、11； (9) Drive Value表示通訊過(guò)程中實(shí)際發(fā)送和接收的數值； (10) Parameter表示參數類(lèi)型； (11) C source表示此代碼在ECU中，用哪段代碼來(lái)表示； (12) Type key表示此代碼的數據類(lèi)型。 注：0 代表無(wú)符號字符 1 代表有符號字符 2 代表無(wú)符號的短整型 3 代表有符號的短整型 4 代表8 bit 數組 5 代表16 bit 數組 3.3 K線(xiàn)通訊協(xié)議及應用 ISO9141主要為車(chē)輛與診斷設備之間的通訊國際標準, ISO9141已被美國加州大氣委員會(huì )(California Air Resource Board)所采納,其ISO14230為專(zhuān)門(mén)指定的用于道路車(chē)輛診斷的協(xié)議。根據ISO14230 的規定, K線(xiàn)通訊消息基本格式如表2 所示。 表2中各參數含義如下: Fmt:幀字節;Tgt:目標地址;Src:源地址;Len:附加長(cháng)度字節; Sld :功能識別字節;Data :數據字節;CS:校驗和。 其校驗和滿(mǎn)足以下公式: i={(i-1)+}mod256(1) 式(1)中:1=＜1＞。 K 線(xiàn)協(xié)議采用消息結構進(jìn)行信息傳遞,可分為請求消息、指示消息和響應消息,其中，響應消息可分為正響應和負響應,所有這些消息都具有相同的結構。 Webasto汽車(chē)天窗馬達ECU與PC機的通訊方式是K 線(xiàn)通訊協(xié)議的一種應用，其代碼基本格式如下：長(cháng)度位、命令標志位、數據位(n=0…16)和校驗位，如表3所示。 所以最小的通訊長(cháng)度為3，即：傳輸的信息包括LEN、ID、CHKSUM(傳輸的數據位數n＝0)。 為了保證PC機與ECU之間的通訊正常，使用校驗碼來(lái)確保發(fā)送代碼的安全性，它是通過(guò)所有代碼的位與CHECKSUM_BASE=0xAA異或來(lái)求得。計算方法如下： 發(fā)送端的校驗碼: 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，說(shuō)明通訊順利完成。 為了確保通訊正常，在串行通訊過(guò)程中，規定兩個(gè)接收字節之間的時(shí)間不得超過(guò)50ms，若超過(guò)，則認為此次操作失敗。 此汽車(chē)天窗馬達ECU通訊系統軟件的程序流程如圖4所示。汽車(chē)天窗馬達ECU通訊系統的軟件運行如圖5所示。 界面上半部分負責*.s參數讀寫(xiě)的部分，下半部分負責*.par參數讀寫(xiě)的部分。此系統的硬件和軟件在Webasto車(chē)頂供暖系統有限公司的測試平臺上已經(jīng)通過(guò)驗證。此系統對其天窗馬達ECU進(jìn)行參數讀寫(xiě)、故障分析時(shí)，縮短了周期，大大提高了工作效率。 當前，汽車(chē)天窗市場(chǎng)多由國外廠(chǎng)商控制，價(jià)格昂貴，其馬達檢測系統的理念也是隨著(zhù)國外先進(jìn)技術(shù)的引進(jìn)而來(lái)的。因此，開(kāi)發(fā)適合我國的汽車(chē)天窗馬達ECU通訊系統不僅可以降低整車(chē)成本，還可以提高其國產(chǎn)化速度�，F在越來(lái)越多的電控系統將在車(chē)輛上使用,這些設備都可通過(guò)K 線(xiàn)使PC機與ECU進(jìn)行信息交換,以滿(mǎn)足實(shí)際車(chē)輛使用和維護的要求。同時(shí)K線(xiàn)也可進(jìn)行電控標定系統的開(kāi)發(fā),因此,本研究工程應用前景非常廣泛。 |
