1 簡介
汽車電子化是現代汽車發展的重要標志之一。目前世界每輛汽車采用電子裝置的情況已成為衡量這部汽車水平高低的主要標志。為了加強市場競爭能力,國外廣泛采用 16~32位微處理器,以及廣泛采用更先進的傳感器,使汽車的功能從對汽車自身的控制管理擴大到“汽車-人-環境”這樣一個大系統的信息獲取、處理和控制。
按照對汽車行駛性能作用的影響劃分,可以把汽車電子產品歸納為兩類。一類是車控電子——汽車電子控制裝置。汽車電子控制裝置要和車上機械系統進行配合使用,即所謂“機電結合”的汽車電子裝置。它們包括發動機、底盤、車身電子控制,例如電子燃油噴射系統、制動防抱死控制、防滑控制、牽引力控制、電子控制懸架、電子控制自動變速器、電子動力轉向等。另一類是車載電子——車載汽車電子裝置。車載汽車電子裝置是在汽車環境下能夠獨立使用的電子裝置,與汽車本身的性能并無直接關系。它們包括汽車信息系統(行車電腦)、導航系統、汽車音響及電視娛樂系統、車載通信系統、上網設備等。
汽車電子的技術基礎是嵌入式技術。在過去的幾十年里,嵌入式技術發展迅速。隨著后PC時代的來臨,計算廣泛的嵌入到應用中去,嵌入式系統將成為未來計算的主要存在方式。應用的牽引和計算環境的變遷推動了嵌入式技術的發展。嵌入式技術與行業的結合又帶動了行業的發展。汽車的電子化、信息化是嵌入式技術在汽車行業的應用。
車控電子產品是一個個分布在汽車上的電子控制單元(ECU)、智能傳感器(Smart Sensor)等功能單元器件。這些器件通過總線連接在一起組成一個子系統。它們可以以適合自己的協議,如Lin、J1939等進行通信。不同的子系統也通過總線組成更大的網絡。其中智能傳感器(Smart Sensor)是一個以工業現場總線為基礎,以CPU為處理核心,以數字通信為變送方式的傳感器和變送器的統一體。與傳統的Sensor相比,Smart Sensor增加了數字通信功能,面向網絡,具有聯網功能。
3 車控電子產品系統平臺——OSEK/VDX
為了滿足日益龐大復雜的汽車電子控制軟件的開發需要,實現應用軟件的可移植性和不同廠商的控制模塊間的可兼容性。1993年,德國汽車工業界聯合推出了汽車電子的開放式系統及接口——OSEK/VDX(Open Systems and the Corresponding InteRFaces For AutomoTIve Electronics)規范,旨在為汽車上的分布控制單元提供一個開放結構的工業標準。OSEK/VDX 規范從實時操作系統RTOS(RealTime Operating System)、軟件接口、通信和網絡管理等方面對汽車的電子控制軟件開發平臺作了較為全面的定義與規定。
它所提出的一整套解決方案是未來汽車電子軟件開發的發展方向。目前,一些公司推出了符合OSEK/VDX規范的操作系統并得到了OSEK /VDX委員會的認證,如 OSEK Works、OSEKOS、OSEKTurbo等。OSEK/VDX標準包括以下四部分:OSEK/VDX操作系統規范(OSEK Operating System,OSEK OS), OSEK/VDX通信規范(OSEK Communication,OSEK COM), OSEK/VDX網絡管理規范(OSEK Network Management,OSEK NM)以及OSEK/VDX實現語言(OSEK Implementation Language,OSEK OIL)。采用符合OSEK/VDX標準的嵌入式實時操作系統可以提高產品代碼的復用率、降低開發成本、縮短產品開發周期。使用兼容OSEK/VDX標準的嵌入式實時操作系統的應用架構如圖1所示。
圖1 兼容OSEK/VDX規范的操作系統應用架構
下面分別對OSEK規范的操作系統部分(OS)、通信部分(COM)、網絡管理部分(NM)、實現語言部分(OIL)、運行調試接口部分(ORTI)等進行介紹。
3.1 OSEK OS規范
OSEK OS規范定義操作系統內核的實現機制和應用編程接口(API),包括任務管理機制、中斷處理機制、事件機制、資源管理機制、報警器管理機制等及相關標準的應用編程接口。OSEK OS規范的實現機制見本刊網站www.dpj.com.cn。
3.2 OSEK COM規范
OSEK COM規范(OSEK Communication Specification)為汽車ECU應用軟件提供了統一的通信環境。通過定義應用軟件通信接口以及ECU內部通信和ECU外部通信,OSEK COM規范提高了應用軟件模塊的可移植性。OSEK COM 提供了多種服務,以方便在任務與任務之間、中斷服務程序與中斷服務程序之間以及任務與中斷服務程序之間發送數據。
OSEK COM 規范的目的是支持應用軟件的移植性、重用性和相互合作性。應用程序接口隱藏了內部和外部通信的區別,同樣也隱藏了不同的通信協議、總線系統和網絡。
OSEK COM中的通信是基于消息的。消息包括了特定應用的數據。消息和消息屬性通過OSEK實現語言(OIL)靜態配置。消息的內容和使用方法與OSEK COM無關。OSEK COM允許0長度的消息存在。在內部通信情況下,交互層IL(Interaction Layer)使消息數據立即發送到接收方。在外部通信情況下,IL將1個或多個消息壓縮成指定的交互層協議數據單元(IPDU),并把它們傳遞到下層處理,如圖2所示。 內部通信的功能性是外部通信功能性的子集。交互層里的消息管理者是基于消息對象的。消息對象存在于發送端的是“發送消息對象”,存在于接收端的是“接收消息對象”。
圖2 OSEK COM中消息發送和接收的簡單模型
交互層和下層通信的數據被組織稱I?PDUs,包括一個或多個消息。一個消息必須占據在I?PDU中連續的位而且不能被分離,在I?PDUs中交叉。在I?PDUs中消息被位排列。消息的大小在位中說明。交互層提供了應用程序接口(API)來處理消息,API包括初始化、數據傳送和通信管理的服務。在網絡上傳送消息的服務是非阻塞的,一個發送消息的服務可能不能返回一個最終的發送狀態,因為網絡中的傳送仍在進行之中。OSEK COM為應用程序提供了通知機制來決定傳送或接收的狀態。
3.3 OSEK NM規范
對于由不同生產商生產的汽車ECU產品,它們有通過串行數據交換連接成網絡的趨勢。因此,為了避免重復勞動和縮短開發時間,需要有一個基礎性的標準。OSEK NM規范(OSEK Network Management system specification)為提高ECU產品的網絡互連能力提供了一個網絡連接標準。OSEK NM任務的目的是提高ECU產品網絡通信的安全性和可靠性。OSEK NM規范規定了網絡管理的機制和應用編程接口(API)。采用OSEK NM規范的ECU產品具有以下功能:
◆ 經過授權后,每一個節點必須是可以訪問的;
◆ 在允許訪問失敗的情況下,具有最大容忍限度;
◆ 支持網絡診斷。
作為一個基礎的配置,遵守OSEK規范的網絡管理實現必須應用在網絡的所有節點。每一個節點都能在規定的間隔內獲得整個網絡的狀態信息。 OSEK NM為網絡監控提供了兩種機制:一種是通過監控應用的消息進行間接監控;另一種是對于特定的網絡管理利用標記機制進行直接監控。OSEK NM包括以下部分:
◆ OSEK NM與應用程序的接口(API);
◆ 節點監控的算法;
◆ OSEK NM與OSEK COM的接口;
◆ 轉換到睡眠狀態的算法;
◆ OSEK NM協議數據單元(NMPDU)。
圖3說明了OSEK NM在整個系統中的位置及其與其他部分的關系。
圖3 OSEK NM在系統中的位置
3.4 OSEK實現語言規范
為了達到軟件可移植的目標,OSEK OIL規范(OSEK Implementation Language Specification)定義了一種配置和使用OSEK應用的方法。圖4表示了一個遵守OSEK規范的應用開發過程。OIL文件可以是手寫的或者是系統配置工具產生的。
圖4 基于OSEK規范的應用開發過程
OIL提供一種在特定CPU中配置OSEK應用的機制。每個CPU對應一個OIL描述,所有的OSEK系統對象用OIL對象來描述。OSEK應用的OIL描述是一組OIL對象的組合,CPU是這些OIL對象的容器。OIL明確地為每個OIL對象定義了所有標準屬性。每個OSEK應用可以定義附加的特殊執行屬性和引用。每個OSEK應用可以限制每個屬性的取值范圍。
OIL中的對象包括:CPU(處理器)、OS(操作系統)、Appmode(應用模式)、Isr(中斷服務)、Resource(資源)、 Task(任務)、Counter(記數器)、Event(事件)、Alarm(報警器)、Com(通信子系統)、Message(消息)、Ipdu(交互層協議數據單元)、NM(網絡管理)。
3.5 OSEK ORTI規范
OSEK ORTI規范(OSEK Run?Time InteRFace Specification)為OSEK操作系統開發工具提供了統一的接口。通過OSEK ORTI,使調試工具可以獲取和顯示操作系統的運行狀態和性能、各種任務的狀態、各種操作系統對象的狀態等信息。ORTI文件是由系統生成器在系統生成階段產生的。ORTI使用KIOL語言將操作系統內核信息傳遞給調試器,同時為OSEK標準對象定義了一些的語法規則。ORTI信息是通過ASCII文本文件提供的。由于OSEK/VDX是基于靜態配置的,因此,ORTI不支持動態的表示和配置數據。
OSEK ORTI規范包括Part A和Part B兩部分:Part A介紹了ORTI為調試工具定義的操作系統內核對象的語言(Kernel Object Interface Language,KOIL);Part B描述了OSEK/VDX標準對象、屬性和它們的含義。
3.5.1 ORTI文件結構
ORTI文件包含版本信息部分、聲明部分和信息部分。版本信息部分描述了KOIL和內核的版本。對于ORTI來講,內核的版本是ORTI標準的版本號。聲明部分聲明ORTI實現中使用的內核類型,相當于C語言中的結構聲明。它描述了訪問內核對象所包含數據的方法。該部分詳細說明了給定屬性的顯示名稱。信息部分包含了所有給定系統聲明部分所聲明的方法,描述了計算或引用所需屬性的方法。信息部分還提供了所需屬性的靜態值和表達式。
3.5.2 標準的ORTI對象及屬性
OS對象,包含正在運行的任務、正在運行的優先級、正在運行的中斷處理程序、操作系統服務、最近的錯誤、當前應用的模式等屬性。
任務對象,包含優先級、狀態、堆棧、活動狀態、上下文等屬性。
上下文對象,包含地址、大小等兩個屬性。
堆棧對象,包含大小、基地址、堆棧方向、填充模式等四個屬性。
報警器對象,包含報警時間、周期、狀態、動作、記數器等五個屬性。
資源對象,包含狀態、資源鎖、優先級等三個屬性。
消息容器對象,包含消息名稱、類型、隊列大小、隊列記數器、當前消息地址等五個屬性。
4 車控電子產品的開發流程
車控電子產品是軟硬件結合的嵌入式系統。為了節約資源,縮短產品開發周期,一般應采取軟硬件同步開發的方案,如圖5所示。車控電子產品的開發工具對軟硬件的同步開發、調試提供了很好的支持。車控電子產品的軟件開發分為功能描述、軟件設計、代碼生成、操作系統環境下高級調試等步驟。車控電子產品的硬件開發分為硬件描述、硬件設計、硬件調試等步驟。當軟件設計完成后,通過使用相應的工具,完成在虛擬ECU平臺上的驗證。當硬件設計完成后,與硬件一起進行軟硬件集成調試。通過這種開發方式,縮短了產品上市的時間。
圖5 軟硬件并行的開發方案
目前,汽車車控電子產品軟件開發流程是“V”形開發流程,如圖6所示。“V”形開發流程分為五個階段,即功能設計、原型仿真、代碼生成、硬件在回路仿真——HIL、標定。
圖6 車控電子產品軟件開發流程
在功能設計階段使用的主要工具是MATLAB。通過使用MATLAB提供的Simulink、Stateflow等工具,完成控制方案的設計、功能模塊的設計、控制算法的設計等任務,并進行初步的仿真模擬工作。在原型仿真階段使用的主要工具是DSPACE。使用dSPACE提供的快速控制原型 ——RCP工具完成離線的仿真工作。在開始該階段之前,需要使用Real Time Workshop、Targetlink等工具完成由Simulink、Stateflow等產生的代碼向標準 C代碼的轉換工作。在進行向標準 C代碼的轉換過程中,可以根據需要加入符合OSEK規范的嵌入式實時操作系統。在代碼生產階段使用的主要工具是CodeWarrior。通過使用 CodeWarrior提供的編譯器、調試器等工具,完成從標準C代碼向目標硬件平臺上的產品代碼的轉換工作。圖7表示了車控電子產品的代碼生成過程。
圖7 車控電子產品代碼生成過程
結語
我國自主發展汽車車控產品尚處于起步階段。本文簡要介紹了車控產品的系統平臺——OSEK/VDX規范,并給出了一個基于OSEK/VDX規范的簡單的車控電子開發模型。在這個模型中,要求開發者熟練使用國際上主流的開發工具,以提高開發效率,縮短開發時間。
評論
查看更多