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

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

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

　　關鍵詞: 汽車電子; AUTOSAR 架構; 中央控制單元; CAN 通信軟件

　　0 引言

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

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

　　1 AUTOSAR 介紹

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

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

　　2 CAN 通信模塊設計分析

　　2. 1 CAN 通信模塊軟件架構

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

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

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

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

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

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

　　3 軟件設計

　　3. 1 AUTOSAR COM 模塊設計

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

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

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

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

　　發(fā)送信號結構體類型 Com_TxSignalType 的設計及部分成員的含義:

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

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

　　發(fā)送的信號最后會封裝在 I-PDU 之中進行傳輸，發(fā)送 I-PDU 結構體類型 Com_TxIPduType 的設計及部分成員的含義:

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

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

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

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

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

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

　　3. 2 PDU Router 模塊設計

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

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

　　3. 3 CAN Interface 模塊設計

　　CAN Interface( 簡稱 CAN IF) 模塊位于 CAN Driver 層之上，提供特定的接口函數(shù)來管理 CAN 硬件。CAN IF 模塊對 CAN 控制器郵箱結構進行抽象，得到硬件對象句柄( HOH) 、硬件發(fā)送句柄( HTH) 和硬件接收句柄( HRH) 。郵 箱 結 構 是 CAN 硬 件 緩 沖 區(qū)，包 含 了 CAN 幀的 ID、長度和數(shù)據(jù)等信息。HOH 定義為一個常數(shù)，表示可用的 CAN 控制器郵箱編號，定義為發(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ù)進行發(fā)送，發(fā)送流程如圖 7 所示。

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

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

　　3. 4 CAN Driver 模塊設計

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

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

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

　　4 軟件測試

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

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

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

　　5 結束語

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