引言

　　在車身電子方面，國內外進行了系列的研究。上海理工大學陳家琪等人利用工控機和相關數據采集卡以及CAN總線智能接口，構建了一個集中式的車身電子試驗臺。哈爾濱工業大學焦曉偉等人采用Stateflow圖形化建模工具構建符合AUTOSAR標準的車身應用層軟件模型，再利用Targetlink代碼生成工具基于模型實現代碼自動生成。而英國Warwick大學的Yue Guo等人，則比較了基于SysML和基于“Simulink+Stateflo-w”的開發方法在駕駛信息系統開發過程中的優缺點。本文采用基于框架結構和高級語言描述的車身網絡電控系統開發方法，采用UML建模工具實現程序代碼的自動生成，可進一步簡化車身網絡的設計與開發過程，提高軟件可重用度，降低開發成本，減少人為錯誤。

　　1 EA及代碼生成功能

　　Enterprise Architect（EA）是澳大利亞Sparx Systems公司開發的一套UML建模及設計平臺。EA體積小巧，使用簡便，對UML標準的支持完整；除支持UML2．0標準的所有13種圖形之外，還支持其他的擴展圖，包括分析圖、自定義圖、需求圖、維護圖、用戶界面圖、數據庫模式圖、文檔、業務建模與業務交互圖等。

　　為便于擴展、定制以及二次開發，EA提供了豐富的SDK。代碼模板框架（Code Template Framework，CTF）是SDK的一部分，EA的代碼生成功能正是通過基于此框架的代碼生成模板實現的。代碼生成模板指定了從UML元素到給定編程語言的轉換過程，其修改通過代碼模板編輯器實現。打開方法為EA主菜單Settings→Code Generation Template，或使用快捷鍵Ctrl+Shift+P。代碼生成模板以純文本形式編寫，其語法風格兼具標記語言和腳本語言的語法特性。這種語法主要關注三種基本結構：

　　（1）字面文本。在代碼生成模板中，除了空行將被忽略以外，所有不是宏或變量的定義及引用的文本，都將作為字面文本而直接輸出到生成的代碼中。如：

　　class ％ className％

　　（2）宏。宏既可用于訪問UML模型中的元素值，又可用于對生成的代碼進行結構化處理。所有的宏都有兩個百分號％包含其中。CTF中包含模板替代宏、域替代宏、標記值替代宏、控制宏、函數宏和EASL代碼生成宏6種基本的宏。正是這些豐富的宏定義造就了EA強大的代碼生成功能。仍以上例說明， “％className％”就是一個域替代宏，在生成的代碼中將以當前的類名替代，故若當前類為Foo，則語句的輸出為“cl-ass Foo”。

　　（3）變量。變量的定義和引用為在代碼生成模板中存取數據提供了方便。CTF中的變量采用弱類型定義，即變量的數據類型可以被忽略且一個變量可以被賦予不同數據類型的值。變量的值可以來自各種宏、雙引號包含的字面文本和其他變量的引用等。變量的定義和引用使用美元符號加一個合法標識符，如$foo=％class Name％。變量$foo將存儲當前類的名稱，需要引用此變量時直接使用$foo即可。

　　2 軟硬件設計

　　為了方便調試及驗證生成代碼的有效性，本設計搭建以CAN總線為主干、LIN總線為下層網絡的車身網絡演示實驗臺。

　　2．1 硬件拓撲

　　根據車身電器的功能和位置，實驗臺拓撲布局如圖1所示。其中，粗實線為CAN總線及其節點，細實線為UN總線及其節點。主干CAN總線上共有8個節點，既是下層LIN網絡上的主機節點，又是CAN／LIN網關。其中，數據采集節點使用USBCAN卡搭建，其余網關節點使用 Freescale公司16位單片機MC9S12XSl28作為主控芯片。

　　MC9S12XSl28同時具有CAN網絡控制器（MSCAN模塊）和LIN網絡控制器（SCI模塊），故只需再連接相應的CAN網絡收發器 TJAl050和LIN網絡收發器TJAl020即可完成CAN／LIN網關節點的硬件設計。CAN／LIN網關節點功能框圖如圖2所示。

　　LIN從機節點使用Freescale公司8位單片機MC9S08DZ60作為主控芯片，使用其SCI模塊連接LIN網絡收發器TJAl020，再連接其他外圍執行器組成。LIN從機節點功能框圖如圖3所示。

　　2．2 軟件建模

　　目前，大多數單片機所支持的軟件編譯器均以C語言為主，而在C語言中沒有類及繼承等相關概念，同時出于可移植性的考慮，軟件模型采用分層思想。將整個設計的軟件結構分為4層：第0層為類型定義及中斷服務程序返回值的宏定義，第1層為單片機及其內部功能模塊類的抽象，第2層為外圍硬件類的抽象，第3層為車身網絡各個節點類的抽象。上層的類通過調用下層類提供的函數實現特定功能，各層的依賴關系如圖4所示。其中，虛線表示調用關系。下面具體介紹第1～3層的建模方法。

　　2．2．1 第1層一單片機及其內部功能模塊類的抽象

　　第1層的函數功能通過對單片機寄存器的讀寫實現，故使用類的成員函數，將寄存器的讀寫代碼直接寫在成員函數Behavior屬性的Ini-tial框中。如使能S12中的MSCAN模塊的代碼如下：

　　CANCTL1（MSCANx）|=CANCTlLl_CANE_MASK；

　　其中的CANCTL1是為了便于對多個MSCAN模塊做統一處理，以及便于選擇使用某個特定模塊而手動編寫的函數宏。在使用時只需將MSCANx賦值為相應的整數值（對于MC9S12XSl28，可以是O～4）。

　　2．2．2 第2層一外圍硬件類的抽象

　　第2層需要調用第1層類的操作，這可以通過活動圖實現。在活動圖中，新建一個Action，根據需要選擇CallOperation（調用成員函數）或Call Behavior（調用活動圖的行為），再指定具體調用哪個成員函數或行為即可（調用的參數通過Action的Arguments屬性傳遞）。最后，將各個Action按照程序流程連接起來。

　　這里，使用CAN協議（上層協議使用J1939）發送一個數據幀（活動圖略——編者注）。為了能夠實現行為圖（包括活動圖）的代碼生成，必須將所有的行為圖及其元素都放在某個類中。活動圖經過轉換后生成的代碼如下所示：

　　2．2．3 第3層一車身網絡各個節點類的抽象

　　除了同樣需要調用第1層、第2層類的操作之外，第3層還需要對中斷服務程序（ISR）進行建模。ISR的建模涉及兩個問題：ISR的返回值和ISR的定位。

　　（1）ISR的返回值問題。CodeWarrior支持兩種ISR的聲明方式。一種是使用預編譯指令pragma定義一個TRAP_PROC符號，TRAP_PROC會提示編譯器下面的函數是ISR，編譯器會使用一個特殊的中斷返回指令來結束這個函數（一般是RTI指令）。此方法需要同時修改 CodeWarrior工程中的PRM文件，將ISR與中斷向量表中的向量聯系起來，不便于使用UML建模。

　　另一種是使用與C51類似的interrupt關鍵字，并指定相應的中斷向量號，這樣就同時完成了ISR的聲明和與中斷向量表的關聯。在EA中修改類的代碼生成模板，添加一個衍型（stereotype）并命名為define，并添加相應的模板代碼。其核心部分代碼如下：

　　修改完成后，在建模過程中只需將類的衍型設置為define，將類名設置為新定義的符號，類的父類設置為原符號即可。以CANO模塊的接收中斷的返回值為例，可將類名設置為ISR_CAN0_RX，將父類設置為interrupt 38void（此父類并不存在）。最后生成的代碼如下：

　　#define ISR_CAN0_RX interrupt 38 void

　　然后將ISR的返回值指定為ISR_CANO_RX即可。

　　（2）ISR的定位問題。中斷服務程序的聲明和定義都必須定位于non-banked區域，通過使用“#pragma CODE_SEG NON_BANKED”實現。同時，中斷服務程序末尾需要添加“#pragma CODE_SEG DEFAULT”，否則后面的函數也會被定位在non-banked區域而導致錯誤。因此，中斷服務程序必須被“#pragma CODE_SEG NON_BANKED”和“#pragma CODE_SEG DEFAULT”包圍起來。這也可通過修改代碼生成模板實現。結合ISR返回值的宏定義，只需在當函數返回值的前3個字符是“ISR”時，在函數前后輸出上述兩條pragma預編譯指令即可。生成ISR聲明的代碼生成模板的核心部分如下：

　　仍以上述CAN0模塊的接收中斷為例，最終生成的函數聲明如下；

　　3 調試與驗證

　　本設計除了使用USBCAN卡作為數據采集節點以外，為了驗證兩種總線協議的實現是否符合標準，更直觀地查看總線幀中各個字段的值以及隨時檢測總線上是否發生幀錯誤等，使用PC示波器PicoScope 5203搭配總線協議分析軟件WaveBPS捕獲兩種總線信號并進行協議分析。Pi-coScope的兩個通道可同時捕獲CAN總線及LIN總線上的信號，進一步方便了網關節點的調試。

　　圖6為在控制面板節點（源地址為0x26）打開左轉向燈時發送給車燈節點（目標地址為0x20）的CAN數據幀。其中，標記為S的位是根據位填充規則自動插入的填充位。圖7為車燈節點收到上述CAN數據幀后，根據網關路由策略及幀轉換規則，發送到LIN總線上的數據幀。

　　4 結論

　　本設計借助EA的代碼生成功能，通過修改代碼生成模板以滿足車身網絡電控系統開發中C語言及編譯器的要求，進行了車身網絡系統的開發和初步實驗驗證。此方法極大地方便了設計開發，并可提高系統的可靠性。