江 艷,蔣先慶(泛亞汽車技術(shù)中心有限公司,上?!?01201)
?
基于AUTOSAR的空調(diào)控制器軟件架構(gòu)設(shè)計
江艷,蔣先慶
(泛亞汽車技術(shù)中心有限公司,上海201201)
摘要:基于AUTOSAR架構(gòu)設(shè)計空調(diào)控制器的軟件架構(gòu),形成基礎(chǔ)軟件和應(yīng)用軟件的模塊化和平臺化,可實現(xiàn)根據(jù)不同項目、不同車型、不同功能配置和不同硬件選擇相應(yīng)的軟件模塊,進行裁剪、移植和集成,從而縮短項目的軟件開發(fā)周期并降低開發(fā)成本。
關(guān)鍵詞:AUTOSAR;空調(diào)控制器;軟件架構(gòu)
傳統(tǒng)汽車電子控制器軟件開發(fā)周期漫長,已經(jīng)無法滿足現(xiàn)代社會快速增長多樣化的功能需求。軟件開發(fā)周期漫長主要是因為應(yīng)用軟件和底層基礎(chǔ)軟件之間以及它們各自之間缺乏兼容性接口。當(dāng)硬件發(fā)生變化時,基礎(chǔ)軟件需要耗費很多時間去調(diào)整接口和更改代碼;當(dāng)新需求或新功能增加時,應(yīng)用軟件也需要花費大量的精力調(diào)整接口和更改代碼;當(dāng)相同功能在不同ECU之間互換時,有的甚至需要重新開發(fā)軟件。為了解決這些問題,AUTOSAR(AUTomotive Open System Architecture,汽車開發(fā)系統(tǒng)架構(gòu))從系統(tǒng)方法論、軟件架構(gòu)、應(yīng)用功能接口和一致性測試等4個方面對汽車電子軟件架構(gòu)工具鏈進行全面定義和約束,并提出虛擬功能總線的概念。即模塊化,將功能分為很多原子類型的軟件構(gòu)件(Software Component,SWC),所有SWC之間的信息交換都是通過虛擬功能總線完成[1]。當(dāng)前人們對汽車舒適性的要求越來越高,空調(diào)控制器的功能也在不斷增加,不同項目不同配置對空調(diào)控制器的要求也不同,隨著科技的進步,硬件的更新?lián)Q代更快,為了適應(yīng)這些變化,有效地縮短軟件開發(fā)的周期和成本,基于AUTOSAR架構(gòu)開發(fā)一款平臺化的空調(diào)控制系統(tǒng)軟件是非常必要和有價值的。
AUTOSAR是由全球主要汽車生產(chǎn)廠商、零部件供應(yīng)商、軟硬件和電子工業(yè)等企業(yè)(如BMW、BOSCH、Continental、DAIMLER、Ford、OPEL、PSA、TOYOTA、VW等)共同制定的汽車開放式系統(tǒng)架構(gòu)標準。其主要目的是建立標準的ECU開放式嵌入式軟件架構(gòu),并為ECU軟件架構(gòu)中的軟件模塊定義統(tǒng)一的AUTOSAR標準接口及標準API(Application Programming Interface,應(yīng)用編程接口)等,以達成提高軟件品質(zhì)、增加軟件復(fù)用便利性的目標[2]。
AUTOSAR將汽車電子軟件架構(gòu)抽象成3個層:應(yīng)用層(Application,APP)、運行時環(huán)境(Runtime Environment,RTE)和基礎(chǔ)軟件層(Basic Software,BSW),如圖1所示。應(yīng)用層以實現(xiàn)控制器的功能邏輯為主,是核心開發(fā)內(nèi)容,現(xiàn)如今功能的更改和新增周期很快,這部分是軟件開發(fā)的重點內(nèi)容,也需最大的工作量?;A(chǔ)軟件層從功能實現(xiàn)上來看大部分控制器使用的功能都是類似的,但實際上又是和硬件強相關(guān),所以當(dāng)硬件變化時很多開發(fā)工作必須重新進行。在當(dāng)前電子技術(shù)日新月異的背景下,硬件的變化又是頻率相當(dāng)高的,該部分也要能夠滿足快速開發(fā)要求。運行時環(huán)境就是定義的統(tǒng)一標準接口,銜接應(yīng)用層和基礎(chǔ)軟件層,使得應(yīng)用軟件與ECU的映射無關(guān),并將應(yīng)用層和基礎(chǔ)軟件層組成一個完整的軟件整體。
圖1 AUTOSAR標準架構(gòu)
汽車空調(diào)系統(tǒng)是為汽車提供取暖、制冷、除霜、空氣凈化和濕度調(diào)節(jié)等功能,其主要組成部分見圖2。汽車空調(diào)系統(tǒng)主要有手動空調(diào)(拉索空調(diào))、電動空調(diào)(電機控制)和自動空調(diào)(單區(qū)、雙區(qū)、三區(qū)、四區(qū)等)。此處討論的空調(diào)控制器軟件架構(gòu)主要是針對電動空調(diào)和自動空調(diào),手動空調(diào)不在此范圍內(nèi)。
圖2 空調(diào)系統(tǒng)組成
在不同的功能應(yīng)用(如電動、單區(qū)自動、雙區(qū)自動、三區(qū)自動、四區(qū)自動等)下,傳感器的數(shù)量(是否有車內(nèi)傳感器,是否有空氣質(zhì)量傳感器及管道傳感器布置個數(shù)等)、核心的控制算法(手動控制還是自動控制)以及輸出控制的對象(步進電機還是直流電機、定排壓縮機還是變排壓縮機等)都會有區(qū)別,因此,如何設(shè)計一個好的軟件架構(gòu),能夠在不同項目、不同配置車型應(yīng)用時支持最小的開發(fā)工作量和開發(fā)成本,是本架構(gòu)的重點。
圖3 應(yīng)用軟件層架構(gòu)
3.1基礎(chǔ)軟件架構(gòu)
本文將基礎(chǔ)軟件層架構(gòu)分為4部分:系統(tǒng)服務(wù)層、ECU抽象層、微控制器抽象層、復(fù)雜驅(qū)動層[3]。系統(tǒng)服務(wù)層用于提供應(yīng)用層可用的服務(wù),包括操作系統(tǒng)、存儲服務(wù)、診斷與通信服務(wù)。ECU抽象層主要包括板載驅(qū)動抽象、存儲硬件抽象、通信硬件抽象和輸入輸出抽象,使得應(yīng)用層軟件與硬件設(shè)計無關(guān)。微控制器抽象層主要包括微處理器驅(qū)動、存儲驅(qū)動、通信驅(qū)動和輸入輸出驅(qū)動,使得應(yīng)用層軟件與微處理器型號無關(guān)。復(fù)雜驅(qū)動層用于提供復(fù)雜傳感器和執(zhí)行器的驅(qū)動,使得重要的應(yīng)用模塊可以直接訪問硬件資源。
基礎(chǔ)軟件層利用模塊化的設(shè)計,可以方便地根據(jù)不同的要求對模塊進行選擇和組合,以構(gòu)成不同功能和功能相同但性能不同、規(guī)格不同的產(chǎn)品?;A(chǔ)軟件層重要的是具有可配置性,對整個功能模塊要可裁剪,如某個項目上ECC(Electronic Climate Control,空調(diào)控制器)不需要EEPROM(Electronically Erasable Programmable Read Only Memory,電子可擦可編程只讀存儲器)功能時,那么此ECC上就可以不包括這個模塊的功能代碼;對功能模塊內(nèi)部實現(xiàn)可配置,以適用不同硬件要求,這樣ECC在切換不同硬件時,可根據(jù)實際硬件配置選擇對應(yīng)的功能內(nèi)部代碼。
3.2應(yīng)用軟件架構(gòu)
在本架構(gòu)中將ECC應(yīng)用軟件層劃分為傳感器模塊、邏輯控制模塊和執(zhí)行器模塊,見圖3,其中LF(Left Front)、RF(Right Front)、LR(Left Rear)、RR (Right Rear)分別代表空調(diào)的左前區(qū)、右前區(qū)、左后區(qū)、右后區(qū)。傳感器模塊主要負責(zé)ECC所有傳感器數(shù)據(jù)的采集、濾波、數(shù)值轉(zhuǎn)換,以及ECC所有用戶按鍵的采集、濾波。邏輯控制器模塊主要根據(jù)用戶設(shè)定輸入、各個傳感器數(shù)值、車輛狀態(tài)、配置設(shè)定等,計算出各個執(zhí)行器最佳的執(zhí)行狀態(tài),以達到車內(nèi)最舒適的環(huán)境和最經(jīng)濟的油耗。執(zhí)行器主要按照邏輯控制模塊計算出的最佳狀態(tài),進行輸出控制以及相關(guān)診斷等。
一個好的軟件架構(gòu),不僅僅是要滿足所有功能的需求,還需要能夠很好地實現(xiàn)系統(tǒng)的性能和品質(zhì)需求。本架構(gòu)設(shè)計,在軟件性能上,應(yīng)用層和基礎(chǔ)軟件層都可以在平臺軟件上根據(jù)實際項目、實際的硬件條件進行選擇性配置,極大地減少了實際的代碼量,提升了ECU的性能,在軟件品質(zhì)上具有很高的安全性、可擴展性、可重用性、可移植性、很好的維護性和易理解性。
為了更好地滿足用戶對舒適性和功能性的要求,空調(diào)系統(tǒng)功能需求會不斷更新和變化。本軟件架構(gòu)設(shè)計各個功能模塊劃分具有很好的獨立性,并且基于傳感器單元、邏輯控制單元、執(zhí)行器單元進行劃分控制,對于日后的功能擴展非常便利。如為了改善車內(nèi)空氣品質(zhì),新增負離子發(fā)生器,即可在原架構(gòu)基礎(chǔ)上,開發(fā)負離子功能邏輯控制代碼和執(zhí)行器代碼,分別加入對應(yīng)單元即可,與其他模塊的交互直接通過RTE讀取和設(shè)定即可。
本軟件架構(gòu)是一個平臺化的架構(gòu)軟件。僅通過修改配置標定或者根據(jù)配置選擇需要模塊,即可實現(xiàn)不同項目和不同空調(diào)配置的軟件要求;軟件的重用性和利用率非常好,開發(fā)人員不需要為每個項目單獨費時費力進行處理。如單區(qū)空調(diào),只要在平臺軟件中選擇溫度控制、風(fēng)量控制、模式控制大的SWC中單區(qū)小SWC代碼即可。
為了適應(yīng)整車設(shè)計時,不同項目和車型會存在同一功能點于不同ECU上實現(xiàn),本軟件架構(gòu)將這類功能需求設(shè)計成獨立模塊,接口的定義精簡只存在物理性的輸入和輸出交互,這樣就能很好地在不同ECU之間進行移植和復(fù)用。如后除霜功能或者是某個執(zhí)行器的實現(xiàn)被挪入其他的ECU上,即可將獨立的后除霜功能和對應(yīng)執(zhí)行器的代碼整體挪入其他ECU,內(nèi)部代碼無需更改和開發(fā),直接配置對應(yīng)的RTE接口和基礎(chǔ)軟件即可實現(xiàn)。
本架構(gòu)不僅大模塊間按照面向物理對象進行劃分,并且各個模塊內(nèi)也根據(jù)功能需求點進行構(gòu)造,每個功能點、每個函數(shù)功能獨立,不產(chǎn)生交叉影響,這樣對代碼的理解和后續(xù)修改都是非常便利和簡單的,大大減少了代碼錯誤率的產(chǎn)生。
本文主要基于AUTOSAR開發(fā)了空調(diào)控制器的軟件架構(gòu)設(shè)計,將應(yīng)用軟件和基礎(chǔ)軟件之間和各自內(nèi)部都通過通用接口進行通信,并實現(xiàn)模塊化,可以根據(jù)實際不同的項目、車型配置和硬件選擇,在平臺化軟件基礎(chǔ)上,直接裁剪或者挪動模塊代碼,提高了ECC代碼的復(fù)用性和移植性,大大減少了代碼開發(fā)的周期和成本。本文設(shè)計的架構(gòu)目前已在別克新英朗和下一代GL8車型上得到較好的運用。
參考文獻:
[1]陳虹.自主汽車電子軟件架構(gòu)技術(shù)戰(zhàn)略解析與規(guī)劃[J].汽車技術(shù),2010(6):1-5.
[2]李震,劉敏.基于AUTOSAR的整車電子電氣架構(gòu)設(shè)計方法[J].機電一體化,2012(11):73-76.
[3]AUTOSAR官方.AUTOSAR Specification Software Architecture.Release 4.2[OL].[2015-07-15].http://www.autosar.org/specifications/release-42.
(編輯楊景)
Software Architecture Design of Air Conditioning Controller Based on AUTOSAR
JIANG Yan,JIANG Xian-qing
(Pan Asia Technical Automotive Center Co.,Ltd.,Shanghai 201201,China)
Abstract:The software architecture for air conditioning controller is described in this paper,to realize modularization of software,and platform application software.According to different programs,vehicle types,functional configure and hardware,it could cut out and migrate the software modules to reduce the time and cost of software development program based on this architecture.
Key words:AUTOSAR;air conditioning controller;software architecture
中圖分類號:U463.851
文獻標識碼:A
文章編號:1003-8639(2016)06-0060-03
收稿日期:2015-11-20;修回日期:2015-12-08
作者簡介:江艷(1986-),女,四川人,碩士,工程師,研究方向為汽車空調(diào)電子軟件開發(fā);蔣先慶(1986-),男,江蘇人,工程師,研究方向為Autosar汽車電子架構(gòu)模塊開發(fā)。