方曉穎

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

?

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

方曉穎

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

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

CAN通訊 變速箱控制單元 全標(biāo)定CAN CAN矩陣

1 引言

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

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

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

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

2 設(shè)計概念

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

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

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

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

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

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

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

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

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

3.3 Checksum及Alive counter處理

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

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

3.4 CAN通訊相關(guān)的故障碼分配

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

4 實現(xiàn)方法

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

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

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

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

4.1.1 報文接收

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

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

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

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

4.1.3 報文發(fā)送

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

4.2 報文解包打包

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

·一個信號占一個byte

·一個byte包含幾個信號

·一個信號占幾個byte

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

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

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

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

4.3.1 報文通訊方向

CAN通訊方向?qū)傩杂小敖邮铡?，“發(fā)送”和“未使用”三種。全標(biāo)定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)絡(luò)上所有節(jié)點(diǎn)發(fā)送的報文分配一個ID號。通常情況下，ID號越是小表示該報文優(yōu)先級越高，所加載的信號越重要。TCU應(yīng)用層根據(jù)OEM的輸入，給所有接收發(fā)送的報文配置ID號，保證傳輸報文在整車網(wǎng)絡(luò)中的唯一性。

4.3.4 報文模式

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

4.3.5 報文掩碼

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

4.3.6 報文DLC位數(shù)

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

4.3.7 報文周期及接收超時

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6 結(jié)論

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

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

綜上所述，TCU通訊采用全標(biāo)定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)原理、設(shè)計與應(yī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

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

文獻(xiàn)標(biāo)識碼：