基于AUTOSAＲ的電動(dòng)汽車中央控制單元CAN通信軟件開發(fā)

　　摘要: 隨著人們對(duì)于汽車安全性和舒適性要求的日益提高，汽車電子技術(shù)不斷發(fā)展，日益復(fù)雜的汽車功能需求使得汽車 ECU 軟件代碼量急劇增加。軟件與硬件之間的高度耦合使得開發(fā)工作大量重復(fù)且復(fù)用性低，極大增加了企業(yè)研發(fā)和維護(hù)成本。以 AUTOSAR 架構(gòu)為基礎(chǔ)，進(jìn)行以電動(dòng)汽車中央控制單元為硬件平臺(tái)的 CAN 通信模塊軟件開發(fā)，提升軟件的復(fù)用性和開發(fā)效率，降低軟件更新和硬件升級(jí)的研發(fā)成本。

　　董碧成; 石春; 吳剛， 儀表技術(shù) 發(fā)表時(shí)間：2021-08-05

　　關(guān)鍵詞: 汽車電子; AUTOSAR 架構(gòu); 中央控制單元; CAN 通信軟件

　　0 引言

　　隨著汽車電子技術(shù)的發(fā)展，其應(yīng)用取代了大部分傳統(tǒng)的機(jī)械部件，逐步深入到汽車的各個(gè)角落，成為驅(qū)動(dòng)汽車執(zhí)行動(dòng)作的核心。日益復(fù)雜的功能需求，使得汽車 ECU ( Electronic Control Unit) 數(shù) 量 逐 漸 增 加。 ECU 的軟件代碼量也隨著功能的增加日趨龐大，軟件維護(hù)和管理工作繁重。與此同時(shí)，每當(dāng)硬件升級(jí)或更換硬件平臺(tái)時(shí)，軟件需要進(jìn)行大量地修改甚至重新設(shè)計(jì)，使得軟件開發(fā)周期延長，開發(fā)成本大大提高[1]。

　　在此背景下，全球最大規(guī)模的幾家汽車企業(yè)、零部件供應(yīng)商以及電子、半導(dǎo)體、軟件系統(tǒng)公司，于 2003 年聯(lián)合成立了一個(gè)汽車開放系統(tǒng)架構(gòu)聯(lián)盟———AUTOSAR( AUTomotive Open Source ARchitecture) 聯(lián)盟，并推出了一個(gè)開放化、標(biāo)準(zhǔn)化的汽車嵌入式系統(tǒng)軟件架構(gòu)———AUTOSAR 規(guī)范。其主要目標(biāo)涵蓋了軟件升級(jí)更新、開發(fā)可重用軟件、加快軟件開發(fā)維護(hù)以及優(yōu)化可擴(kuò)展系統(tǒng)成本等多個(gè)方面，較好地解決了 ECU 軟件開發(fā)過程中的突出問題[2]。

　　1 AUTOSAR 介紹

　　AUTOSAR 采用模塊化的分層軟件設(shè)計(jì)，從軟件架構(gòu)視圖角度可分為應(yīng)用層、運(yùn)行時(shí)環(huán)境和基礎(chǔ)軟件層，如圖 1 所示。應(yīng)用層由軟件組件單元構(gòu)成，包含與硬件無關(guān)的應(yīng)用軟件組件、傳感器軟件組件和執(zhí)行器軟件組件等。運(yùn)行時(shí)環(huán)境為系統(tǒng)提供基礎(chǔ)的通信服務(wù)，支持應(yīng)用層軟件組件之間的通信，以及應(yīng)用層軟件組件到下層基礎(chǔ)軟件層之間的通信，運(yùn)行時(shí)環(huán)境將應(yīng)用層軟件與下層基礎(chǔ)軟件層分割開來?；A(chǔ)軟件層主要提供基礎(chǔ)軟件服務(wù)、標(biāo)準(zhǔn)化系統(tǒng)功能和應(yīng)用接口，由服務(wù)層、ECU 抽象層、微控制器抽象層和復(fù)雜驅(qū)動(dòng)組成[3]。

　　AUTOSAR 架構(gòu)通過將硬件層進(jìn)行抽象，得到微控制器抽象層，隱藏了硬件接口細(xì)節(jié)，達(dá)到將硬件與上層軟件分離的效果，實(shí)現(xiàn)水平層解耦。當(dāng) ECU 硬件平臺(tái)進(jìn)行更新?lián)Q代時(shí)，只需要將微控制器抽象層接口函數(shù)進(jìn)行修改，上層代碼可以實(shí)現(xiàn)復(fù)用，大大減少了開發(fā)時(shí)間和成本，提升了軟件的復(fù)用性。

　　2 CAN 通信模塊設(shè)計(jì)分析

　　2. 1 CAN 通信模塊軟件架構(gòu)

　　CAN 通信模塊包括了 AUTOSAR COM、PDU Router、CAN Interface 和 CAN Driver 幾個(gè)模塊。根據(jù) AUTOSAR 分層設(shè)計(jì)思想和 AUTOSAR 規(guī)范對(duì) CAN 通信模塊設(shè)計(jì)的要求，設(shè)計(jì)出如圖 2 所示的軟件框架。OSEK OS 是個(gè)靜態(tài)的實(shí)時(shí)操作系統(tǒng)，主要為應(yīng)用層軟件提供服務(wù)，在 CAN 通信中為需要周期執(zhí)行的函數(shù)提供服務(wù)。 OSEK OS 位于系統(tǒng)服務(wù)層，操作系統(tǒng)需要直接操作下層硬件，貫穿了 ECU 抽象層和微控制器抽象層。

　　AUTOSAR COM 模塊主要起到信號(hào)接口和數(shù)據(jù)網(wǎng)關(guān)的作用，負(fù)責(zé)發(fā)送上層傳遞的信號(hào)和信號(hào)組，解析從底層接收的數(shù)據(jù)并通知上層。上層只需要傳遞數(shù)據(jù)和接收數(shù)據(jù)，無需關(guān)心傳輸和接收的具體過程[4]。

　　PDU Router 簡稱 PDUR，PDUR 模塊主要是起一個(gè)過渡兼容的作用，對(duì)上提供統(tǒng)一的接口，屏蔽下層網(wǎng)絡(luò)細(xì)節(jié)，對(duì)下層兼容多種車載總線，如 CAN、LIN 和 FlexRay 等。PDUR 模塊提供 I-PDU 的網(wǎng)關(guān)功能，使得不同的總線之間可以進(jìn)行通信[5]。CAN Interface 簡稱 CAN IF，CAN IF 模塊主要是處理上層模塊和底層驅(qū)動(dòng)之間的 PDU 數(shù)據(jù)流傳遞，為上層模塊提供統(tǒng)一接口，并通過特定的接口函數(shù)來管理 CAN 硬件[6]。

　　CAN Driver 模塊為 CAN 通信軟件的最底層，是直接訪問 CAN 通信相關(guān)硬件的模塊，通過對(duì)硬件抽象，向上層 CAN IF 模塊提供與硬件無關(guān)的函數(shù)接口[7]。

　　2. 2 CAN 通信模塊開發(fā)步驟

　　CAN 通信模塊各層軟件開發(fā)步驟如圖 3 所示。通過 AUTOSAR 規(guī)范中對(duì)分層架構(gòu)設(shè)計(jì)和對(duì) CAN 模塊開發(fā)的要求，確定基礎(chǔ)數(shù)據(jù)類型和定義數(shù)據(jù)結(jié)構(gòu)，規(guī)范各文件主要作用并確定相互包含結(jié)構(gòu)，設(shè)計(jì)相應(yīng)的通知機(jī)制和錯(cuò)誤處理機(jī)制。

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

　　3. 1 AUTOSAR COM 模塊設(shè)計(jì)

　　COM 模塊從上層接收到的數(shù)據(jù)稱為信號(hào)或信號(hào)組，信號(hào)組由復(fù)雜的或者功能類似需要同步發(fā)送的信號(hào)組合而成。COM 模塊的信號(hào)類型如表 1 所示。

　　COM 模塊為上層需要傳遞的信號(hào)和信號(hào)組確定唯一的編號(hào)信息，并為類型相同的信號(hào)集中定義運(yùn)行時(shí)緩沖區(qū)，用來存儲(chǔ)信號(hào)值的最新數(shù)據(jù)。信號(hào)和信號(hào)組在 COM 模塊都會(huì)被封裝在交互層數(shù)據(jù)協(xié)議單元( IPDU) 之中，進(jìn)而完成數(shù)據(jù)向下層模塊傳遞。COM 模塊為信號(hào)定義了 5 種傳輸屬性，一個(gè) I-PDU 可以包含多個(gè)信號(hào)，每個(gè)信號(hào)可以選擇一種傳輸屬性，這個(gè)傳輸屬性定義了在信號(hào)寫訪問時(shí)觸發(fā)包含此信號(hào) I-PDU 的傳輸情況。信號(hào)的傳輸屬性如表 2 所示。

　　I-PDU 有 4 種傳輸模式，各傳輸模式的含義如表 3 所示。

　　在 COM 模塊的數(shù)據(jù)處理過程中，涉及到很多數(shù)據(jù)類型，這些數(shù)據(jù)類型包裝在結(jié)構(gòu)體中進(jìn)行使用。COM 模塊使用的數(shù)據(jù)結(jié)構(gòu)體包括: COM 模塊配置參數(shù)結(jié)構(gòu)體、發(fā)送信號(hào)結(jié)構(gòu)體、接收信號(hào)結(jié)構(gòu)體、發(fā)送 I-PDU 結(jié)構(gòu)體、接收 I-PDU 結(jié)構(gòu)體、發(fā)送信號(hào)組結(jié)構(gòu)體和接收信號(hào)組結(jié)構(gòu)體等。

　　發(fā)送信號(hào)結(jié)構(gòu)體類型 Com_TxSignalType 的設(shè)計(jì)及部分成員的含義:

　　問觸發(fā) I-PDU 傳輸?shù)膸追N模式* / const PduIdType ComIpduRefIndex; /* 所屬的 I-PDU 的索引* / P2CONST( Com _ FilterType，AUTOMATIC，COM _ APPL _ CONST) ComFilter; /* 信號(hào)的過濾配置參數(shù)，在發(fā)送端用于確定傳輸模式條件 TMC* / …/* 省略部分參數(shù)* / } Com_TxSignalType;

　　結(jié)構(gòu)體 Com_TxSignalType 中所包含的成員較多，進(jìn)行了部分省略。發(fā)送信號(hào)主要包含用于在信號(hào)發(fā)送時(shí)的各項(xiàng)參數(shù)以及跟信號(hào)相關(guān)的回調(diào)函數(shù)。定義的 ComErrorNotification 是一個(gè)函數(shù)指針類型，主要用于在信號(hào)發(fā)送時(shí)，如果包含信號(hào)的 I-PDU 沒有激活，就會(huì)調(diào)用這個(gè)回調(diào)函數(shù)通知錯(cuò)誤。ComNotification 則用于信號(hào)成功發(fā)送到總線上時(shí)通知上層使用。ComFilter 是一個(gè)指向過濾參數(shù)的結(jié)構(gòu)體指針，在接收信號(hào)時(shí)用于接收過濾，在發(fā)送信號(hào)時(shí)用于計(jì)算判斷傳輸模式條件 TMC。TMC 的值會(huì)影響 I-PDU 發(fā)送模式選擇 TMS 的值。

　　發(fā)送的信號(hào)最后會(huì)封裝在 I-PDU 之中進(jìn)行傳輸，發(fā)送 I-PDU 結(jié)構(gòu)體類型 Com_TxIPduType 的設(shè)計(jì)及部分成員的含義:

　　typedef struct { const uint16 ComIPduHandleId; /* I-PDU 的標(biāo)識(shí) ID* / const Com_IPduSignalProcessingType ComIPduSignalProcessing; /* 信號(hào)的確認(rèn)和指示的處理模式，直接模式和延遲模式* / const Com_IPduType ComIPduType; /* I-PDU 類型* / const Com_SignalIdType ComIPduSignalsRefNumber; /* I-PDU 所有包含信號(hào)的數(shù)量* / P2CONST( Com_SignalIdType，AUTOMATIC，COM_APPL_CONST) ComIPduSignalsRef; /* 指向此 I-PDU 所包含的信號(hào)的指針* / const uint16 ComPduIdRef; /* 底層 PDU 標(biāo)識(shí) ID* / P2CONST( Com_TxModeType，AUTOMATIC，COM_APPL_CONST) ComTxModeTrue; /* I-PDU 發(fā)送方式 TRUE 的結(jié)構(gòu)體指針* / P2CONST( Com_TxModeType，AUTOMATIC，COM_APPL_CONST) ComTxModeFalse; /* I-PDU 發(fā)送方式 FALSE 的結(jié)構(gòu)體指針* / …/* 省略部分參數(shù)* / } Com_TxIPduType;

　　結(jié)構(gòu)體 Com_TxIPduType 定義了發(fā)送 I-PDU 傳輸中的參 數(shù)，其 中 ComTxModeTrue 和 ComTxModeFalse 是 COM 模塊為 I-PDU 定義的兩種發(fā)送方式，這兩種發(fā)送方式的參數(shù)需要靜態(tài)配置，根據(jù) I-PDU 所有包含信號(hào)的 TMC 值來確定 I-PDU 發(fā)送模式選擇 TMS。兩種發(fā)送方式都可以定義 I-PDU 在傳輸時(shí)所需要的時(shí)間參數(shù)。

　　COM 模塊發(fā)送信號(hào)的流程如圖 4 所示。

　　通過調(diào)用 Com_SendSignal( ) 函數(shù)不會(huì)立即觸發(fā) IPDU 的傳輸，只是更新存儲(chǔ)在 I-PDU 緩沖區(qū)中的信號(hào)數(shù)據(jù)，I-PDU 的發(fā)送通過 OSEK OS 實(shí)時(shí)操作系統(tǒng)的任務(wù)調(diào)用 Com_MainFunctionTx( ) 函數(shù)進(jìn)行處理。Com_ MainFunctionTx( ) 函數(shù)會(huì)對(duì)所有需要發(fā)送的 I-PDU 進(jìn)行循環(huán)判斷，結(jié)合 I-PDU 的傳輸模式和發(fā)送中需要滿足的 時(shí) 間 參 數(shù) 綜 合 判 斷 是 否 需 要 調(diào) 用 PduR _ ComTransmit( ) 函數(shù)傳輸該 I-PDU 到下層。

　　在接收數(shù)據(jù)時(shí)，下層會(huì)調(diào)用 Com_RxIndication( ) 回調(diào)函數(shù)通知 COM 模塊接收到 I-PDU 數(shù)據(jù)，并將接收到的 PDU 數(shù)據(jù)信息復(fù)制到 COM 模塊定義的 I-PDU 緩沖區(qū)中，更新相關(guān)的 I-PDU 屬性參數(shù)。

　　上層通過 Com_ReceiveSignal( ) 函數(shù)獲取存儲(chǔ)在 COM 模塊的信號(hào)緩沖區(qū)中的數(shù)據(jù)，圖 5 為軟件執(zhí)行流程。

　　3. 2 PDU Router 模塊設(shè)計(jì)

　　PDU Router( 簡稱 PDUR) 模塊位于通信軟件中間，擁有多個(gè)上層和多個(gè)下層，在 CAN 通信軟件中， PDUR 模塊上層為 COM 模塊，下層為 CAN Interface 模塊。PDUR 模塊主要包括兩個(gè)部分，PDU 路由表和 PDU 路由引擎。PDU 路由表靜態(tài)定義了每個(gè) I-PDU 的路由路徑，根據(jù)路由表來確定 I-PDU 的上下層模塊信息; PDU 路由引擎是根據(jù) PDU 路由表進(jìn)行操作的實(shí)際代碼，實(shí)現(xiàn) I-PDU 信息的路由傳遞。

　　COM 模 塊 通 過 調(diào) 用 PduR _ ComTransmit ( ) 將 I-PDU傳遞到 PDUR 模塊，PDUR 模塊根據(jù)靜態(tài)定義的路由表，查找 I-PDU 的目的模塊，然后調(diào)用相關(guān)下層 CanIf_Transmit( ) 函數(shù)實(shí)現(xiàn)傳輸。在完成傳輸之后，下層調(diào)用 PduR_CanIfTxConfirmation( ) 函數(shù)通知 PDUR模塊，PDUR 模塊根據(jù)路由表查找上層模塊信息，進(jìn)而完成通知上層，此過程如圖 6 所示。下層在接收到 IPDU 數(shù)據(jù)時(shí)，操作過程與發(fā)送完成的確認(rèn)過程類似。

　　3. 3 CAN Interface 模塊設(shè)計(jì)

　　CAN Interface( 簡稱 CAN IF) 模塊位于 CAN Driver 層之上，提供特定的接口函數(shù)來管理 CAN 硬件。CAN IF 模塊對(duì) CAN 控制器郵箱結(jié)構(gòu)進(jìn)行抽象，得到硬件對(duì)象句柄( HOH) 、硬件發(fā)送句柄( HTH) 和硬件接收句柄( HRH) 。郵 箱 結(jié) 構(gòu) 是 CAN 硬 件 緩 沖 區(qū)，包 含 了 CAN 幀的 ID、長度和數(shù)據(jù)等信息。HOH 定義為一個(gè)常數(shù)，表示可用的 CAN 控制器郵箱編號(hào)，定義為發(fā)送使用的是 HTH，定義為接收使用是 HRH。

　　CAN IF 模 塊 CanIf _ Transmit ( ) 函 數(shù) 接 收 來 自 PDUR 模塊的 I-PDU，根據(jù)傳入的 I-PDU ID 獲取靜態(tài)配置的底層 CAN 幀信息，組包合成 CAN 協(xié)議數(shù)據(jù)單元，同硬件發(fā)送句柄 HTH 一起傳遞給下層發(fā)送函數(shù)進(jìn)行發(fā)送，發(fā)送流程如圖 7 所示。

　　當(dāng)下層 Can_Write( ) 返回 CAN_BUSY 時(shí)，表明指定的硬件緩沖區(qū)沒有空間，此時(shí) CAN IF 模塊將發(fā)送失敗的數(shù)據(jù)存儲(chǔ)在 CAN IF 模塊定義的緩沖區(qū)，等待 CAN 硬件緩沖區(qū)空閑時(shí)進(jìn)行發(fā)送。當(dāng) CAN Driver 模塊成功發(fā)送報(bào)文時(shí)，會(huì)在 CAN 發(fā)送中斷中調(diào)用 CanIf_ TxConfirmation( ) 通知 CAN IF 模塊，此函數(shù)再調(diào)用上層回調(diào)函數(shù)通知上層發(fā)送完成，并查詢 CAN IF 緩沖區(qū)是否有待發(fā)送數(shù)據(jù)，如果存在待發(fā)送數(shù)據(jù)就會(huì)請(qǐng)求底層傳輸。

　　在底層 CAN 接收中斷中，會(huì)調(diào)用 CAN IF 層 CanIf _RxIndication( ) 通知 CAN IF 層接收到了數(shù)據(jù)，此函數(shù)會(huì)判斷接收的數(shù)據(jù)是否需要軟件過濾，并檢查數(shù)據(jù)長度，然后判斷是否調(diào)用上層回調(diào)函數(shù)通知上層接收到新數(shù)據(jù)。

　　3. 4 CAN Driver 模塊設(shè)計(jì)

　　CAN Driver 模塊是最底層的硬件驅(qū)動(dòng)模塊，通過操作硬件寄存器實(shí)現(xiàn)對(duì)硬件的控制。Can_Write( ) 是 CAN Driver 模塊的發(fā)送函數(shù)，具體流程如圖 8 所示。

　　當(dāng)硬件郵箱空閑時(shí)正常完成發(fā)送，當(dāng)在被占用情況下會(huì)返回 CAN_BUSY，CAN IF 模塊會(huì)根據(jù)返回值存儲(chǔ)沒能完成發(fā)送的數(shù)據(jù)信息。

　　在 CAN 中斷處理函數(shù)中，會(huì)根據(jù)中斷標(biāo)志位判斷出現(xiàn)的是發(fā)送中斷還是接收中斷，然后調(diào)用不同的上層回調(diào)函數(shù)，完成發(fā)送確認(rèn)和接收指示操作，具體流程如圖 9 所示。

　　4 軟件測試

　　軟件測試是軟件開發(fā)的重要一環(huán)，在軟件設(shè)計(jì)時(shí)，需要進(jìn)行功能測試和系統(tǒng)測試。在各模塊的函數(shù)功能設(shè)計(jì)中，為函數(shù)設(shè)置不同的輸入輸出測試用例，來完成函數(shù)功能測試，測試結(jié)果可在編譯軟件中調(diào)試查看。

　　系統(tǒng)測試采用中央控制單元作為硬件平臺(tái)。中央控制單元作為電動(dòng)汽車整車控制系統(tǒng)的核心，兼具整車控制與遠(yuǎn)程監(jiān)控功能。中央控制單元主控芯片選用了 恩 智 浦 公 司 的 ARM 內(nèi) 核 32 位 微 控 制 器 MK60DN512VLQ10。測試 工 具 包 括 12 V 電 源、USB CAN 分析儀、上位機(jī)軟件和 JLINK 調(diào)試工具等，軟件環(huán)境為 μVision V5. 24. 2. 0。

　　在測試過程中通過在應(yīng)用層定義信號(hào)，在各層配置文件中進(jìn)行參數(shù)配置，并定義信號(hào)所屬的 I-PDU 以及發(fā)送和接收信號(hào)的 CAN 報(bào)文 ID、幀類型、幀格式和長度等。將 PC 機(jī)與 USB CAN 分析儀和 JLINK 調(diào)試工具連接， CAN 總線波特率配置為250 kbit/s，使用編譯器軟件將編譯好的程序下載至中央控制單元。通過 USB CAN 分析儀進(jìn)行報(bào)文數(shù)據(jù)的解析，由 ECANTools 上位機(jī)軟件進(jìn)行顯示。圖10 為 ECANTools 軟件 CAN 通信測試數(shù)據(jù)接收和發(fā)送界面，幀 ID 為 0x18FFFFFF 和0x18FFFFFA 是中央控制單元發(fā)出的報(bào)文，幀 ID 為 0x18FFFF0A 是 ECANTools 軟件模擬其他 ECU 發(fā)送給中央控制單元的報(bào)文。經(jīng)過測試驗(yàn)證，中央控制單元可以正常收發(fā) CAN 報(bào)文，且數(shù)據(jù)信息和報(bào)文格式都符合預(yù)期。

　　5 結(jié)束語

　　本文根據(jù) AUTOSAR 規(guī)范要求，完成了 AUTOSAR CAN 通信模塊軟件的開發(fā)，并在中央控制單元硬件平臺(tái)進(jìn)行測試應(yīng)用。軟件開發(fā)按照分層和模塊化的設(shè)計(jì)思想，層與層之間隱藏設(shè)計(jì)細(xì)節(jié)，實(shí)現(xiàn)了解耦，能夠較好提升軟件復(fù)用性，為后續(xù)軟件開發(fā)減少時(shí)間和成本，提高開發(fā)效率。