Arduino在汽車CAN通訊中的應(yīng)用研究 Research on the Application of Arduino in Automobile CAN Communication

信松嶺 XIN Song-ling 張召 ZHANG Zhao

摘要：汽車各個電子控制單元之間的通訊通過CAN，在汽車研發(fā)過程中，存在軟件不同步以致CAN通訊異常，無法交互信號，車輛功能異常。為滿足研發(fā)需求，采用Arduino UNO+MCP2515進(jìn)行CAN信號解析、轉(zhuǎn)換并發(fā)送，試驗(yàn)數(shù)據(jù)顯示，轉(zhuǎn)發(fā)物理量的正確性及實(shí)時性較好，表明該方案有效，為其他類似場景需求提供解決方案。

Abstract： The communication between various electronic control units of the vehicle is through CAN. In the process of vehicle development， software asynchronization leads to abnormal CAN communication， unable to exchange signals， and abnormal vehicle functions. In order to meet the research and development requirements， Arduino Uno +MCP2515 was used to analyze， convert and send CAN signals. The test data showed that the correctness and real-time performance of the forwarding physical quantity were good， which indicated that the scheme was effective and provided a solution for other similar scene requirements.

關(guān)鍵詞：控制器局域網(wǎng);Arduino開發(fā)板;信號解析

Key words： controller area network;Arduino development board;signal parsing

中圖分類號：U463.1? ? ? ? ? ? ? ? ? ? ?文獻(xiàn)標(biāo)識碼：A? ? ? ? ? ? ? ? ? ? ? 文章編號：1674-957X（2021）22-0006-03

0? 引言

當(dāng)今階段的汽車電氣化程度日益發(fā)展，每臺配備數(shù)十個ECU（電子控制單元）[1]，而它們之間并非是完全獨(dú)立的，完成某項(xiàng)整車功能可能需要來自幾個不同ECU的信號，例如非常熟悉的儀表顯示，它需要獲取ABS（防抱死制動系統(tǒng)）的車速信號，獲取ECM（發(fā)動機(jī)控制模塊）的發(fā)動機(jī)轉(zhuǎn)速和水溫信號，獲取TCM（變速箱控制模塊）的擋位信號。而TCM在執(zhí)行換擋功能時，也同樣需要獲取發(fā)動機(jī)轉(zhuǎn)速和車速等其他控制器的信號。為了解決汽車控制器之間的通訊問題，德國Bosch公司開發(fā)了一種現(xiàn)場總線——CAN（Controller Area Network），并最終成為國際標(biāo)準(zhǔn)（ISO11519），是應(yīng)用最廣泛的現(xiàn)場總線之一[2]。它通過兩條雙絞的線纜，以差分信號的形式進(jìn)行通訊。CAN通訊具備以下特點(diǎn)：

①多主總線，每個節(jié)點(diǎn)機(jī)均可成為主機(jī)，且節(jié)點(diǎn)機(jī)之間也可進(jìn)行通訊;

②通訊速率快，最高可達(dá)1Mb/s;

③采用CRC校驗(yàn)并提供相應(yīng)的錯誤處理功能，保證通訊的可靠性;

④最大的特點(diǎn)是沒有采用傳統(tǒng)的站地址編碼，取而代之對通訊數(shù)據(jù)塊編碼，這種方式可使節(jié)點(diǎn)機(jī)的個數(shù)在理論上不受限制，也可以使不同的節(jié)點(diǎn)機(jī)同時接收相同的數(shù)據(jù)，還可以作為發(fā)送仲裁的依據(jù)。

1? 原理與設(shè)計(jì)

1.1 研究背景

在汽車研發(fā)初期，會定義出車輛的配置及零部件方案，并以某款成熟汽車作為基礎(chǔ)進(jìn)行改制，列舉如下場景：

場景一：改制車有控制器A，其外發(fā)的CAN信號中有個信號a，會被控制器B接收并執(zhí)行其相應(yīng)功能，而基礎(chǔ)車沒有控制器A，導(dǎo)致控制器B無法正常執(zhí)行功能;

場景二：改制車將基礎(chǔ)車的控制器C更換為控制器D，那么控制器D與基礎(chǔ)車的其他控制器無法正常通訊，因?yàn)榭刂破鱀與控制器C對信號的定義不同;

場景三：預(yù)研新增控制器做原型開發(fā)，與已有的控制器通過CAN進(jìn)行通訊（該控制器的應(yīng)用層軟件非自主，不能直接在該控制器中開發(fā)，僅開放CAN接口），并通過其響應(yīng)驗(yàn)證新開發(fā)邏輯的可行性。

這三個場景有個共同點(diǎn)是都涉及到了CAN通訊，按照正常的開發(fā)流程需要各自的控制器更改軟件以適配CAN信號的變更，但不同的供應(yīng)商會有不同的開發(fā)周期，舉例某供應(yīng)商在僅更改CAN信號定義的軟件升級需要3至4個月，對于整車公司而言，這個周期是很長的，難以滿足開發(fā)需求。

1.2 問題分析

分析各個場景的問題核心，有如下解決方案：

場景一：可以通過設(shè)備模擬缺失的信號a;

場景二：可以將設(shè)備串接在控制器D前，并將交互的信號按照兩側(cè)的定義進(jìn)行轉(zhuǎn)發(fā)，具體而言（為簡化描述，兩側(cè)分為左側(cè)和右側(cè)），設(shè)備按照左側(cè)的信號定義接收，解析后獲得表征的物理值，然后按照右側(cè)的信號定義發(fā)送，同理從右側(cè)接收，向左側(cè)發(fā)送;

場景三：可以通過設(shè)備運(yùn)行新策略，并將最終結(jié)果通過CAN外發(fā)。

接下來對設(shè)備進(jìn)行選型，筆記本電腦安裝BusMaster，可以通過USB口連ES581接入CAN總線，但此方案要占用一臺電腦資源，而且占用空間大，不易放置。

通過調(diào)研，MCP2515作為一款獨(dú)立的CAN控制器并集成了收發(fā)器[3]，可以直接接入CAN總線，而與主控芯片通過SPI通信，主控芯片則選用Arduino UNO[4]。三個場景的網(wǎng)絡(luò)拓?fù)淙鐖D1所示。

1.3 硬件連接

以場景二為例，僅儀表控制器更換供應(yīng)商，其他控制器不變，開發(fā)設(shè)備的硬件包括：Arduino UNO一臺（含線，集成數(shù)據(jù)傳輸及供電功能），MCP2515兩塊，杜邦線若干。Arduino UNO與MCP2515引腳連接關(guān)系如表1所示。

將儀表控制器原有的CAN總線剪斷，儀表這一側(cè)的線頭與MCP2515（ABS）的CAN總線連接，另一側(cè)的線頭與MCP2515（總線）的CAN總線連接，注意雙絞線的兩條線不能接反，如果CAN信號中轉(zhuǎn)功能異常，這是一個排查點(diǎn)。Arduino UNO的線是USB口，可以通過車上的USB供電。

1.4 軟件設(shè)計(jì)

軟件是控制系統(tǒng)的靈魂，Arduino在軟件設(shè)計(jì)的優(yōu)勢在這里就明顯的體現(xiàn)出來了。由于開源的緣故，很多專業(yè)的高水平的研究人員或電子愛好者，會將開發(fā)的驅(qū)動封裝為庫函數(shù)，在應(yīng)用時就會極為方便，只需要調(diào)用幾個函數(shù)，就能輕松完成對外設(shè)的控制，讓我們更加專注于應(yīng)用層軟件的設(shè)計(jì)，專注于功能的實(shí)現(xiàn)。

Arduino的軟件開發(fā)環(huán)境是Arduino IDE，與其他主控芯片有多個工具軟件的開發(fā)方式不同的是，這是一個集成開發(fā)環(huán)境，包含代碼編寫、編譯、下載等功能，界面簡潔友好[5]。

對于MCP2515的支持有許多庫函數(shù)，本次應(yīng)用研究使用sutowp開發(fā)的arduino-mcp2515-master。該庫函數(shù)封裝了幾個重要且常用的函數(shù)：

①M(fèi)CP2515 mcp2515（9），定義一個名為mcp2515的MCP2515對象，參數(shù)9代表mcp2515的片選引腳;

②mcp2515.setBitrate（CAN_500KBPS），定義mcp2515的總線速率為500kbps;

③mcp2515.readMessage（&canMsg），定義mcp2515的接收函數(shù)，并將報文信息保存至canMsg，包含3個主要內(nèi)容，canMsg.can_id表示報文ID、canMsg.can_dlc 表示報文DLC（1～8）、canMsg.data[0]～ canMsg.data[7]表示1～8字節(jié)長度的數(shù)據(jù)場;

④mcp2515. sendMessage（&canMsg），定義mcp2515的發(fā)送函數(shù)，將canMsg保存的報文信息發(fā)送至總線;

為了滿足場景二的需求，需要提取特定CAN信號并轉(zhuǎn)發(fā)出去，其中有兩個關(guān)鍵點(diǎn)：ID匹配和數(shù)值轉(zhuǎn)換。通過canMsg.can_id可以直接獲得接收報文或定義發(fā)送報文的ID，接下來對數(shù)值轉(zhuǎn)換進(jìn)行說明。數(shù)值轉(zhuǎn)換指的是報文的數(shù)據(jù)場數(shù)據(jù)（Raw Value）與信號的物理數(shù)據(jù)值（Physical Value）相互轉(zhuǎn)換的過程。在汽車CAN研發(fā)過程中，對數(shù)值轉(zhuǎn)換一般采用Excel管理，稱之為CAN Matrix進(jìn)行描述，而每家汽車公司都有自己的模板，但大同小異，vector公司也制定了一種統(tǒng)一的DBC格式的文件來進(jìn)行描述。主要包含以下主要內(nèi)容：

①Byte Order，有Motorola和Intel兩種;

②Factor，數(shù)據(jù)場數(shù)據(jù)的“1”代表物理數(shù)據(jù)的值;

③Offset，偏移量，與Factor合用，Physical Value = Raw Value * Factor + Offset;

④Startbit，信號的Raw Value在數(shù)據(jù)場中的起始位置;

⑤Length，信號的Raw Value在數(shù)據(jù)場中的長度，影響其最大值。

借用BusMaster軟件界面，以發(fā)動機(jī)轉(zhuǎn)速為例進(jìn)行說明，如圖2所示，Byte Order為Motorola，F(xiàn)actor為0.125，Offset為0，Startbit為16，Length為16。如圖2解析，數(shù)據(jù)場數(shù)據(jù)（Raw Value）的第1和第2字節(jié)代表的十六進(jìn)制數(shù)值為4B00，對應(yīng)十進(jìn)制數(shù)值為19200，計(jì)算Physical Value為2400。圖中的Raw Value和Physical Value欄的數(shù)值框是可以輸入數(shù)據(jù)的，改變其中一個，另一個會自動改變?yōu)槠鋵?yīng)的值。反之，已知Physical Value，先計(jì)算對應(yīng)的Raw Value（十進(jìn)制），轉(zhuǎn)為二進(jìn)制，依據(jù)Length高位補(bǔ)0，再依據(jù)Startbit放置相應(yīng)位置，即可得數(shù)據(jù)場數(shù)據(jù)。

將代碼輸入Arduino IDE，如圖3所示，通過點(diǎn)擊工具欄中“項(xiàng)目”下拉菜單的“驗(yàn)證/編譯”，可以檢查語法等其他錯誤，會在最下方的消息框中以紅色字體提示，如沒有錯誤，編譯完成時則顯示如圖的白色字體信息。最后可以通過工具欄中“項(xiàng)目”下拉菜單的“上傳”來將程序燒錄至Arduino UNO。

2? 實(shí)驗(yàn)

最后進(jìn)入實(shí)車驗(yàn)證階段，改制一臺領(lǐng)克03汽車，將儀表更換為另一家供應(yīng)商的產(chǎn)品以模擬場景二，改制完成后發(fā)現(xiàn)發(fā)動機(jī)轉(zhuǎn)速、水溫、車速均沒有示數(shù)。

按1.3硬件連接中的方案將芯片接入汽車，如圖4所示，發(fā)現(xiàn)儀表發(fā)動機(jī)轉(zhuǎn)速、水溫、車速有示數(shù)。

主觀轉(zhuǎn)發(fā)正常，接下來進(jìn)行數(shù)據(jù)采集，駕駛工況為自由駕駛，其中147s后為原地駐車踩油門，為了直觀所以以發(fā)動機(jī)轉(zhuǎn)速和車速為例進(jìn)行說明，結(jié)果如圖5所示，圖中共顯示4個信號，ECM_EngSpd，ECM_VehSpd，CAN_EngineSpeed，CAN_VehicleSpeed，分別為ECM外發(fā)的發(fā)動機(jī)轉(zhuǎn)速，發(fā)動機(jī)接收的車速（ABS發(fā)出），ABS側(cè)CAN總線解析出的發(fā)動機(jī)轉(zhuǎn)速和車速，從圖中只看到兩條曲線，這是因?yàn)镃AN_EngineSpeed和ECM_EngSpd基本重合，ECM_VehSpd和CAN_VehicleSpeed基本重合，這表明經(jīng)過Arduino UNO+MCP2515的轉(zhuǎn)發(fā)，各個物理量可以保持原有值，而且轉(zhuǎn)發(fā)未出現(xiàn)明顯延時。

3? 結(jié)論

通過實(shí)車驗(yàn)證Arduino UNO+MCP2515轉(zhuǎn)發(fā)CAN信號方案的可行性，為研發(fā)過程中由于CAN信號定義不同步帶來的通訊異常提供解決方案，研究結(jié)果表明，該方案切實(shí)有效。

參考文獻(xiàn)：

[1]方友勇.基于CAN總線的多ECU通信系統(tǒng)設(shè)計(jì)[D].南昌大學(xué)，2020.

[2]黃菊花，顧曉輝，曹銘.基于Arduino的CAN通信模塊的設(shè)計(jì)[J].南昌大學(xué)學(xué)報（工科版），2020，42（04）：404-408.

[3]丁雪靜，許永輝.基于MCP2515的CAN總線通信單元設(shè)計(jì)[J].現(xiàn)代電子技術(shù)，2015，38（21）：60-63.

[4]孫龍，劉暉虎.基于MCP2515的CAN總線控制軟件的設(shè)計(jì)與實(shí)現(xiàn)[J].現(xiàn)代信息科技，2018，2（07）：1-4，8.

[5]趙琨.基于Arduino的云平臺智能家居控制系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[D].華中師范大學(xué)，2020.