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

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

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

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

　　0 引言

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

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

　　1 AUTOSAR 介紹

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

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

　　2 CAN 通信模塊設計分析

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

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

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

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

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

　　2. 2 CAN 通信模塊開發步驟

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

　　3 軟件設計

　　3. 1 AUTOSAR COM 模塊設計

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

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

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

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

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

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

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

　　發送的信號最后會封裝在 I-PDU 之中進行傳輸，發送 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 所有包含信號的數量* / 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 發送方式 TRUE 的結構體指針* / P2CONST( Com_TxModeType，AUTOMATIC，COM_APPL_CONST) ComTxModeFalse; /* I-PDU 發送方式 FALSE 的結構體指針* / …/* 省略部分參數* / } Com_TxIPduType;

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

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

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

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

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

　　3. 2 PDU Router 模塊設計

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

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

　　3. 3 CAN Interface 模塊設計

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

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

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

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

　　3. 4 CAN Driver 模塊設計

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

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

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

　　4 軟件測試

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

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

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

　　5 結束語

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