基于全標定CAN的TCU通訊開發(fā)*

方曉穎

上海汽車變速器有限公司 軟件工程師

?

基于全標定CAN的TCU通訊開發(fā)*

方曉穎

上海汽車變速器有限公司 軟件工程師

全標定CAN是一種全新的TCU通訊開發(fā)方式。與傳統(tǒng)通訊開發(fā)模式相比，全標定CAN軟件在開發(fā)過程中TCU供應商只負責接收和發(fā)送報文，而報文信號的打包及解包由應用層開發(fā)者負責。在此基礎上，應用層擁有CAN通訊參數(shù)配置權(quán)限。即底層將CAN通訊所涉及配置的參數(shù)以標定量的形式開放給應用層，使得在更新CAN矩陣時，只需應用層編寫接口函數(shù)，匹配標定參數(shù)，而TCU供應商無需重新對底層軟件進行更新，從而減少了整個軟件的開發(fā)周期。

CAN通訊 變速箱控制單元 全標定CAN CAN矩陣

1 引言

CAN是控制器局域網(wǎng)絡(Controller Area Network,CAN)的簡稱，是由研發(fā)和生產(chǎn)汽車電子產(chǎn)品著稱的德國BOSCH公司開發(fā)，并最終成為國際標準(ISO 11898)，是汽車計算機控制系統(tǒng)和嵌入式工業(yè)控制局域網(wǎng)的標準總線。TCU與整車上其它節(jié)點的通訊都是通過CAN總線來實現(xiàn)的，如圖1所示，因此CAN通訊開發(fā)是TCU軟件開發(fā)中最基礎的一部分。

在TCU軟件開發(fā)過程中，通常會根據(jù)實際需求不斷更新CAN Matrix。由于受目前TCU供應商底層軟件平臺的CAN sharing模式限制，CAN Matrix的每次更新，需要底層軟件供應商來完成。無論CAN Matrix修改內(nèi)容多少，底層都需要進行集成，測試，整個軟件開發(fā)周期較長。

圖1 TCU與整車通過CAN網(wǎng)絡通訊

為了提高CAN matrix的靈活性，減少底層軟件的開發(fā)工作量， 把CAN matrix的配置，集成工作轉(zhuǎn)由應用層來完成，以此減少軟件開發(fā)周期，實現(xiàn)CAN模塊的一次性開發(fā)。

2 設計概念

全標定CAN設計概念：在開發(fā)過程中TCU供應商只負責接收和發(fā)送報文，而報文信號的打包及解包由應用層開發(fā)者負責。在此基礎上，應用層擁有CAN通訊參數(shù)配置權(quán)限。即底層將CAN通訊所涉及配置的參數(shù)以標定量的形式開放給應用層，使得在更新CAN matrix時，只需應用層編寫接口函數(shù)，重新標定參數(shù)，而無需重新對底層軟件進行更新。

應用層負責報文信號打包解包及參數(shù)配置，其中包括：

報文handle、報文ID、報文方向、報文模式、中斷使能、接收/發(fā)送周期、報文數(shù)據(jù)長度、接收超時時長、延時時長、接收掩碼，各報文中信號的分布結(jié)構(gòu)，信號值的計算。

3 與傳統(tǒng)CAN通訊開發(fā)的區(qū)別

基于全標定的TCU CAN通訊開發(fā)與傳統(tǒng)模式開發(fā)的主要區(qū)別在于以下幾個方面：

3.1 信號接收發(fā)送方式

傳統(tǒng)軟件中TCU上層只需接收或發(fā)送具體信號，每個信號與傳輸CAN報文中的解包或打包過程則由負責底層開發(fā)的TCU供應商完成。而在全標定軟件中，TCU應用層直接接收CAN報文，并在此基礎上，完成信號的解包或打包工作。

3.2 CAN通訊參數(shù)配置

在CAN 通訊開發(fā)中涉及到很多參數(shù)的配置定義，如報文傳送方向，是接受或發(fā)送。傳統(tǒng)軟件中，這些參數(shù)由TCU供應商定義。而全標定軟件中，所有與CAN通訊相關的參數(shù)由應用層通過標定來配置。

3.3 Checksum及Alive counter處理

在CAN通訊中，重要報文的發(fā)送或接收需經(jīng)過checksum和alive counter校驗。Alive counter可監(jiān)視報文是否按時正常發(fā)送或接收。Checksum可檢驗報文內(nèi)容是否發(fā)送正確。傳統(tǒng)軟件中，這部分的校驗由TCU供應商完成。而全標定軟件中，這些校驗由TCU應用層開發(fā)。

由于checksum和alive counter由應用層負責校驗，所以在底層發(fā)送的CAN狀態(tài)信號中不再包括這兩部分的信息。

3.4 CAN通訊相關的故障碼分配

由于全標定軟件與CAN通訊相關的功能開發(fā)全部開放給應用層，因此報文與其故障碼(如，幀丟失)的對應關系也由TCU應用層分配。

4 實現(xiàn)方法

全標定CAN通訊功能主要通過三個方面來開發(fā)實現(xiàn)。首先，開發(fā)報文接收發(fā)送接口函數(shù)。其次，通過Matlab建模實現(xiàn)報文解包打包。最后，離線配置CAN通訊參數(shù)，如圖2所示。

圖2 全標定CAN實現(xiàn)Fig.2 Realization of free calibration CAN

4.1 報文接收發(fā)送接口函數(shù)

TCU應用層與底層CAN通訊的所有交互過程均通過接口函數(shù)實現(xiàn)。其中包括，報文接收，報文狀態(tài)接收以及報文發(fā)送。所有報文均以byte為單位被接收或發(fā)送。

4.1.1 報文接收

TCU應用層通過調(diào)用接收函數(shù)獲取報文中某一byte信息。

4.1.2 報文狀態(tài)接收

TCU應用層在接收報文的同時接收報文狀態(tài)來判斷該報文的當前周期通訊情況。

如果狀態(tài)為1，表示通訊正常，接收的報文信息有效。如果狀態(tài)為0，則表示當前周期TCU并沒有建立與該報文的通訊，收到的報文信息并不可靠。此時，TCU應用層需要考慮以默認值代替接收到的報文信息作為一種幀丟失的后處理。

4.1.3 報文發(fā)送

同理，TCU應用層通過調(diào)用發(fā)送函數(shù)實時發(fā)送byte信息。

4.2 報文解包打包

應用層開發(fā)者通過Matlab建模實現(xiàn)報文的打包解包。一幀報文有8個byte，根據(jù)解讀bdc得知信號與byte的關系分為三種情況。

·一個信號占一個byte

·一個byte包含幾個信號

·一個信號占幾個byte

報文解包即把一個CAN信號根據(jù)以上三種情況從報文中解析出來。而報文打包，可理解為報文解包的逆過程，也分這三種情況。

4.3 CAN通訊參數(shù)配置

CAN通訊功能的實現(xiàn)，除完成報文的解包打包過程外，還要需定義各類屬性，如通訊方向，通訊周期等。在全標定CAN軟件中， 所有與CAN通訊相關參數(shù)通過離線標定方式配置。參數(shù)配置的正確與否將直接影響TCU與整車網(wǎng)絡的通訊。如圖3所示：CAN通訊配置參數(shù)如下。

圖3 CAN通訊配置參數(shù)Fig.3 Parameters of CAN communication

4.3.1 報文通訊方向

CAN通訊方向?qū)傩杂小敖邮铡保鞍l(fā)送”和“未使用”三種。全標定CAN軟件中TCU輸出報文定義為“發(fā)送”，EMS, ABS等輸入報文定義為“接收”，其余則定義為“未使用”。

4.3.2 中斷使能

中斷使能是指CAN報文在通訊過程中是否允許被中斷。根據(jù)傳輸特性和要求，TCU的發(fā)送報文定義為“使能中斷”，否則會引起收發(fā)阻塞。而TCU接收報文定義為“禁止中斷”。

4.3.3 報文ID

現(xiàn)代基于CAN總線的汽車開發(fā)過程中，OEM會給CAN網(wǎng)絡上所有節(jié)點發(fā)送的報文分配一個ID號。通常情況下，ID號越是小表示該報文優(yōu)先級越高，所加載的信號越重要。TCU應用層根據(jù)OEM的輸入，給所有接收發(fā)送的報文配置ID號，保證傳輸報文在整車網(wǎng)絡中的唯一性。

4.3.4 報文模式

CAN報文傳輸模式有常規(guī)模式，發(fā)送復用模式，接收復用模式主報文，接收復用模式從報文等。

4.3.5 報文掩碼

在CAN接收發(fā)送處理過程中，通過設置掩碼可以對ID進行篩選，把它們放置在不同的mailbox里。

4.3.6 報文DLC位數(shù)

CAN標準消息報文中，數(shù)據(jù)場的字節(jié)數(shù)目由數(shù)據(jù)長度碼(data length code，簡稱DLC)決定。TCU應用層可以根據(jù)dbc定義分別設置發(fā)送報文和接收報文的DLC位數(shù)。位數(shù)范圍：0-8。

4.3.7 報文周期及接收超時

在TCU 與整車CAN通訊過程中，所有報文都是以周期形式接收或發(fā)送的。通常加載重要信息(如扭矩，轉(zhuǎn)速)的報文優(yōu)先級較高，發(fā)送或接收的周期較短，以保證重要信息傳輸?shù)膶崟r性。TCU應用層根據(jù)dbc定義來配置所有報文的傳輸周期，eg. 10 ms，20 ms。

在配置報文接收周期的同時，需定義判斷報文接收超時時間。軟件中定義為連續(xù)n個周期未收到某一報文，則診斷為該報文接收超時。

4.3.8 報文監(jiān)測使能

所有對報文的監(jiān)測都是通過該報文的使能開關控制的。開關可設置成使能報文監(jiān)測或抑制報文監(jiān)測。根據(jù)診斷需求，所有報文定義使能監(jiān)測。

5 開發(fā)案例及測試結(jié)果

以接收報文EMS1中的發(fā)動機損耗扭矩信號為例。首先，通過接口函數(shù)實現(xiàn)報文各個byte的輸入：

EMS1_0=CanByte(3,0)。其中(3,0)分別是EMS1這幀的通訊編號及發(fā)動機損耗扭矩在該幀中的byte位。

其次，根據(jù)dbc中CAN Matrix定義，在模型中對EMS1的各個byte進行分解。因為發(fā)動機損耗扭矩占1個byte，所以整個接收該byte信號即可。

最后進行一系列CAN通訊參數(shù)配置。

報文通訊方向：EMS1幀是EMS節(jié)點發(fā)送幀，故TCU端定義為“接收”幀。

中斷使能：EMS作為接收幀，定義為“禁止中斷”。

報文ID：根據(jù)整車dbc文件，定義EMS1的ID與TCU通訊編號的對應關系，即把標號為3的通訊幀定義成EMS1的ID， 0x78。

報文模式：EMS1幀定義為“常規(guī)報文”。

報文掩碼：eg.所以報文都定義成0xFF。

報文DLC位數(shù)：統(tǒng)一定義為8。

報文周期：EMS1為高速CAN上的關鍵幀，根據(jù)整車要求周期定義為“10 ms”，從而保證扭矩交互的實時性。

接收超時：根據(jù)通訊協(xié)議，定義成10倍的報文周期為該幀的接收超時。

報文監(jiān)測使能：診斷需求定義為“監(jiān)測使能”。

測試結(jié)果如圖4所示。把CAN總線上傳輸?shù)膱笪男盘柾ㄟ^接口文件，模型輸入，轉(zhuǎn)化成了TCU實際需要使用的信號。其中，

3為硬件在環(huán)設備HIL模擬的發(fā)動機損耗扭矩。

1為CAN總線上傳輸報文信號，即

CAN報文信號=HIL模擬EMS損耗扭矩/ factor 。

2為實際TCU內(nèi)部使用的發(fā)動機損耗扭矩，即

實際TCU使用EMS損耗扭矩=CAN報文信號*factor*HIL模擬EMS損耗扭矩/-最大扭矩

圖4 發(fā)動機損耗扭矩輸入Fig.4 Engine loss torque input

6 結(jié)論

基于全標定CAN軟件的最大優(yōu)勢在于其開發(fā)的便利性。無論CAN矩陣有任何更新，都無需TCU供應商對底層軟件做任何更改和測試，相反，TCU應用層開發(fā)者擁有最大程度上的開發(fā)權(quán)。

但由于該開發(fā)模式仍處于起步階段，后續(xù)可能出現(xiàn)的問題仍然未知。除此之外，由于應用層開發(fā)工作量增加，為確保軟件產(chǎn)品的質(zhì)量，相應的測試任務也進一步加重。這樣就對軟件開發(fā)和測試人員的專業(yè)要求有所提高。

綜上所述，TCU通訊采用全標定CAN的模式體現(xiàn)出顯著的優(yōu)勢。該開發(fā)模式在減少了軟件開發(fā)周期的同時也降低了開發(fā)成本，將成為今后其他項目開發(fā)沿用的趨勢。

[1] Module Documentation 2055 CAN-Configuration

[2] Module Documentation 2062 CAN message monitoring

[3] Module Documentation 2055 CAN_IFC

[4] Free_Calibration_CAN_Instruction_20140304

[5] 羅 峰,孫澤昌.汽車CAN總線系統(tǒng)原理、設計與應用

The Development of TCU Communication Based on Free Calibration CAN

FangXiaoying

(ShanghaiAutomobileGearWorks,Shanghai201800,China)

Free calibration CAN is a new development mode of TCU communication. Compared with traditional mode, in this new development TCU supplier is only responsible for the transmission of CAN frame, while TCU application layer implement packing and unpacking of CAN frame. Besides, TCU application developer have the overall right to calibrate the parameter which related to the CAN communication. Moreover, When the CAN matrix is updated, TCU application developer just need to modify the interface, and calibrate the parameter. No platform software need to be changed by TCU supplier. Then considerable development time will be saved.

CAN communication TCU Free Calibration CAN CAN Matrix

1006-8244(2015)02-031-04

* 該項目得到了上海市科學技術(shù)委員會的資助，資助課題編號為“13DZ225044(上海市汽車變速器工程技術(shù)研究中心)”

文獻標識碼：