方曉穎

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

?

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

方曉穎

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

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

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

1 引言

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

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

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

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

2 設(shè)計(jì)概念

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

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

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

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

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

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

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

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

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

3.3 Checksum及Alive counter處理

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

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

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

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

4 實(shí)現(xiàn)方法

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

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

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

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

4.1.1 報(bào)文接收

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

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

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

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

4.1.3 報(bào)文發(fā)送

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

4.2 報(bào)文解包打包

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

·一個(gè)信號(hào)占一個(gè)byte

·一個(gè)byte包含幾個(gè)信號(hào)

·一個(gè)信號(hào)占幾個(gè)byte

報(bào)文解包即把一個(gè)CAN信號(hào)根據(jù)以上三種情況從報(bào)文中解析出來(lái)。而報(bào)文打包，可理解為報(bào)文解包的逆過(guò)程，也分這三種情況。

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

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

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

4.3.1 報(bào)文通訊方向

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

4.3.2 中斷使能

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

4.3.3 報(bào)文ID

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

4.3.4 報(bào)文模式

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

4.3.5 報(bào)文掩碼

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

4.3.6 報(bào)文DLC位數(shù)

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

4.3.7 報(bào)文周期及接收超時(shí)

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

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

4.3.8 報(bào)文監(jiān)測(cè)使能

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

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

以接收?qǐng)?bào)文EMS1中的發(fā)動(dòng)機(jī)損耗扭矩信號(hào)為例。首先，通過(guò)接口函數(shù)實(shí)現(xiàn)報(bào)文各個(gè)byte的輸入：

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

其次，根據(jù)dbc中CAN Matrix定義，在模型中對(duì)EMS1的各個(gè)byte進(jìn)行分解。因?yàn)榘l(fā)動(dòng)機(jī)損耗扭矩占1個(gè)byte，所以整個(gè)接收該byte信號(hào)即可。

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

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

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

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

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

報(bào)文掩碼：eg.所以報(bào)文都定義成0xFF。

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

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

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

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

測(cè)試結(jié)果如圖4所示。把CAN總線上傳輸?shù)膱?bào)文信號(hào)通過(guò)接口文件，模型輸入，轉(zhuǎn)化成了TCU實(shí)際需要使用的信號(hào)。其中，

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

1為CAN總線上傳輸報(bào)文信號(hào)，即

CAN報(bào)文信號(hào)=HIL模擬EMS損耗扭矩/ factor 。

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

實(shí)際TCU使用EMS損耗扭矩=CAN報(bào)文信號(hào)*factor*HIL模擬EMS損耗扭矩/-最大扭矩

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

6 結(jié)論

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

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

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

[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] 羅 峰,孫澤昌.汽車(chē)CAN總線系統(tǒng)原理、設(shè)計(jì)與應(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

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

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