本設計在基於(yu) MPC555微控製器硬件平台基礎上，構建了一個(ge) 開放的符合OSEKIVDX標準的汽車電子控製平台。

開放式汽車電控單元設計的關(guan) 鍵問題

　　根據IEEE的定義(yi) ，開放式控製係統必須使相應的執行程序能夠運行於(yu) 來源不同的平台，與(yu) 其他的係統應用進行無縫的連接和相互操縱，並為(wei) 用戶提供一個(ge) 具有一致風格的交互接口。這一定義(yi) 明確的提出了開放式控製係統的特點和設計的關(guan) 鍵，即可互操作、可複用、可擴展以及可互換。

　　另外，由於(yu) 車輛使用環境變化較大，控製係統要求有較強的適應性，能夠根據環境的變化進行係統動態配置，在線切換算法組件和改變組件間的互連等。

　　在硬件方麵，由於(yu) 硬件結構相對固定，係統升級基本采用部件替換或者增減的方式，更新周期也相對較長。因此，其開放性著重考慮的是硬件係統在汽車控製領域的通用性和適應性，也就是說硬件係統應該適應車載控製係統針對不同控製對象和控製模型的資源需要，同時也應注意係統開放互連的硬件支持。

OpenECU的硬件係統設計

　　係統硬件架構采用Freescale公司的MPC555作為(wei) 控製核心，由電源模塊、存儲(chu) 係統、複位電路和接口模塊幾部分組成。由於(yu) 係統是麵向汽車電子應用的，為(wei) 保證係統的在汽車電子領域的開放性，應對汽車電子領域常用的接口信號進行處理，采用相應的專(zhuan) 用接口芯片以滿足要求。同時，係統提供豐(feng) 富的 I/O資源也有利於(yu) 滿足開放性的要求。係統架構如圖1所示。

圖1 係統架構圖

1 係統CPU選擇方案

　　平台選用專(zhuan) 為(wei) 汽車電子等領域開發的處理器MPC555。基於(yu) 對MPC500係列微控製器功能分析，選用MPC555的原因有如下幾點：CPU處理能力可以滿足算法對計算任務和浮點運算能力的需求;片上資源豐(feng) 富，很多功能模塊，如TPU、MDA和CAN等，是專(zhuan) 門為(wei) 汽車電子行業(ye) 量身定製的，片上多種控製功能模塊的集成，使得係統無須過多外接功能驅動芯片，且硬件布線減少，成本降低，有助於(yu) 提高係統的可靠性;有較大的內(nei) 部存儲(chu) 器容量，用戶可以在滿足要求的情況下自由選擇是否使用外部存儲(chu) 器，這有利於(yu) 節約成本，提高可靠性。

2 外擴存儲(chu) 器係統的設計

　　MPC555微控製器片內(nei) 有448KB Flash，隻提供32KB的SRAM，可能在某些複雜的控製場合存儲(chu) 空間是不夠用的，為(wei) 增強適應性，為(wei) 用戶提供足夠的資源，本設計還外接SRAM和Flash存儲(chu) 器芯片。Flash選用AMD公司的AM29LV160DB，共2片。總存儲(chu) 容量為(wei) 4MB。讀寫(xie) 操作供電電壓範圍2.7～3.6V，訪問時間為(wei) 90ns。SRAM選用ISSI公司的IC61LV5128-10T芯片，共4片，總存儲(chu) 容量為(wei) 2MB。訪問時間為(wei) 10ns，供電電壓3.3V。

　　MPC555中的存儲(chu) 器控製器提供了對EPROM、靜態RAM、Flash、EEPROM和其他外圍設備的接口能力，共提供四個(ge) 存儲(chu) 區段，分別由四根片選信號線CS[0]～CS[3]來進行選擇，支持讀寫(xie) 操作。CS[0]還作為(wei) 係統自舉(ju) 時，程序入口地址區段的選擇信號線。根據這個(ge) 特性可以把係統配置成 Flash啟動方式。CS[1]作為(wei) SRAM的外擴片選信號。圖2給出MPC555微控製器外擴Flash和SRAM存儲(chu) 器的連接圖。其中 WE[0:3]/BE[0:3]為(wei) 寫(xie) 使能/字節使能信號線，其中WE[0]/BE[0]確認數據總線DATA[0:7]上的有效數據，WE[1] /BE[1]確認數據總線DATA[8:15]上的有效數據，WE[2]/BE[2]確認數據總線DATA[16:23]上的有效數據，WE[3] /BE[3]確認數據總線DATA[24:31]上的有效數據。OE為(wei) 輸出有效信號，CE為(wei) 片選有效信號。由於(yu) MPC555微處理器按字尋址，未使用地址線低兩(liang) 位以避免發生地址衝(chong) 突。

圖2 MPC555微控製器外擴Flash和SRAM存儲(chu) 器的連接圖

3 Lamda傳(chuan) 感器信號調理

　　LM9040是由兩(liang) 路獨立的Lamda氧氣傳(chuan) 感器采樣輸入的差分放大器組成的雙通道傳(chuan) 感器接口電路。Lamda傳(chuan) 感器監視發動機廢氣，根據空燃比產(chan) 生測量的電壓信號。LM9040可以將±2V的傳(chuan) 感器差分測量信號轉換為(wei) 適合5V參考電壓的A/D變換的輸出電壓。電路如圖3所示。

圖3 Lamda傳(chuan) 感器信號調理電路圖

4 CAN通信總線設計

　　為(wei) 了實現動力總成控製係統中的分布式控製和實時數據交換，必須采用高傳(chuan) 輸速率、抗幹擾能力強以及高可靠性的網絡總線方式。CAN總線以其突出的實時性、可靠性和靈活性的特點，在目前存在的多種汽車網絡通信標準中最具競爭(zheng) 實力。

　　MPC555中己經內(nei) 嵌兩(liang) 個(ge) CAN總線控製器模塊TouCAN，TouCAN符合CAN2.0B技術規範，兼容標準（11位標誌符）和擴展（29位標誌符）兩(liang) 種報文格式，所以本設計采用集成控製器的方式來實現CAN節點。要進行CAN總線通信，還需要連接一個(ge) CAN收發器，在本係統中，選用CAN控製器與(yu) 物理總線之間的接口芯片PCA82C251。值得注意的是，總線兩(liang) 端需加120Ω的電阻，對於(yu) 匹配總線阻擾，起著相當重要的作用。忽略掉它們(men) ，會(hui) 使數據通信的抗幹擾性及可靠性大大降低，甚至無法通信。通信介質選用雙絞線。為(wei) 了增強抗幹擾能力，去除傳(chuan) 送信號過程中所產(chan) 生的噪音，采用TDK公司特別為(wei) CAN總線使用而設計的高電感共態濾波器ZJYS81R5。

OpenECU的軟件係統設計

　　OpenECU的軟件係統根據開放性的要求，對用戶隱藏底層硬件和設備管理的細節，將係統分層封裝為(wei) 硬件抽象層和操作係統層，係統結構如圖4所示。

圖4 OpenECU軟件係統結構

　　硬件抽象層管理平台的硬件資源包括三個(ge) 主要的部分：硬件係統的設備驅動、硬中斷管理和係統調試與(yu) 診斷支持。它是係統的硬件中斷的管理者，生成和維護中斷向量表，提供操作係統中斷管理的支持;通過對硬件設備資源的封裝，為(wei) 操作係統提供設備操作的入口;采用中斷驅動的方式響應調試係統的服務，進行係統的狀態監視。

　　OSEKIVDX為(wei) 車用嵌入式操作係統及其相關(guan) 服務提供了一係列標準，目的是促進不同設備之間的協調工作能力，為(wei) 軟件開發者提供統一的編程接口，以提高軟件的複用性和互換性。OpenECU選擇TH-OSEK操作係統作為(wei) 管理軟硬件資源的係統平台和用戶控製算法的運行平台。主要是因為(wei) 其實時性較強，具有規範的應用程序接口，為(wei) 控製模型提供標準的係統服務，可方便模型的實現和移植。另外，為(wei) 了適用於(yu) 廣泛的目標處理器，支持運行在廣泛硬件基礎上的實時程序，OSEK操作係統具備高度模塊化和可靈活配置的特性。這些特點顯然是與(yu) OpenECU開放式開發平台所希望達到的開放性相一致的。OpenECU利用操作係統完成設備的進一步封裝，為(wei) 控製模型提供了規範的服務接口，並滿足設備複用和控製實時性的要求，另外TH-OSEK操作係統定義(yi) 了開放的網絡管理和通信係統，可以方便的實現控製節點的動態配置。#p#分頁標題#e#

　　對於(yu) 係統的診斷和測試，本設計側(ce) 重於(yu) 提供一個(ge) 實現診斷和測試服務的平台和手段，而不關(guan) 心具體(ti) 的診斷和測試項目，這部分功能用戶可以根據具體(ti) 情況在係統支持下進行定義(yi) 。OSEK ORTI實現係統診斷測試應用的基本服務支持，提供對OSEK操作係統進行查詢和監控的接口，通過這個(ge) 接口上層的診斷服務可以獲取自己所關(guan) 心的係統信息，並為(wei) 診斷服務提供對目標操縱的基本手段。這部分是係統診斷和測試功能的實現基礎，與(yu) 診斷通信服務一起實現對目標的分布式調試與(yu) 診斷。

結束語

　　初步的實際使用證明，本平台可以方便用戶構建複合汽車控製係統，有效提高係統的可靠性，具有較高的實用價(jia) 值。