從工程師的角度看AUTOSAR
“軟件定義汽車”的火熱帶動了工程師們對于汽車電子軟件熱烈地討論。不曾想到,隱藏在控制器內(nèi)部,默默地發(fā)揮著作用的汽車電子軟件,如今備受矚目。本人畢業(yè)到現(xiàn)在,一直在汽車行業(yè)做軟件,切身感受到一系列的變化。寫軟件的方法在變,行業(yè)技術(shù)標準在變,和OEM合作模式在變,還有敏捷轉(zhuǎn)型等等。10多年前,有人認為汽車行業(yè)是夕陽產(chǎn)業(yè),IT是朝陽產(chǎn)業(yè)?,F(xiàn)在看來,無論是汽車還是IT,依然朝氣蓬勃,更令人欣喜的是,這兩個產(chǎn)業(yè)的融合為未來的發(fā)展帶來了新的契機。
1
開端-OSEK/VDX
OSEK/VDX標準的出現(xiàn)代表著汽車電子軟件標準化的開端,該標準的構(gòu)成:實時的操作系統(tǒng)(OSEK OS),通訊子系統(tǒng)(OSEK-COM)和網(wǎng)絡管理系統(tǒng)(OSEK-NM)。
在OSEK出現(xiàn)之前,軟件生產(chǎn)商們僅依靠自身積累,寫出的軟件五花八門,水平參差不齊,有些甚至沒有清晰的軟件層次結(jié)構(gòu),這樣寫出的軟件質(zhì)量堪憂,并且可維護性是很差的。有了OSEK標準的借鑒和指導,很多軟件生產(chǎn)商依照OSEK標準開發(fā)出了自己的軟件產(chǎn)品。像汽車行業(yè)的Tier1,提供軟件與硬件整套完整方案是常態(tài),Tier1自研的完善可靠的軟件產(chǎn)品也是其核心競爭力之一。
OSEK OS是實時操作系統(tǒng),可以滿足大多數(shù)汽車控制器的任務調(diào)度要求。另外其可移植性和可擴展性很高,可以輕松移植到新MCU平臺。對于實時性要求,除了要有好的操作系統(tǒng),也需要程序設計者合理地規(guī)劃常規(guī)任務和中斷處理程序,如果任務阻塞或執(zhí)行時間過長,會極大的影響正常任務的調(diào)度。近年來,軟件系統(tǒng)的實時性和確定性執(zhí)行也不斷地在演進。確定性操作系統(tǒng),再配合邏輯執(zhí)行時間(LET)模型,可提供更高級別的功能安全機制。
下圖摘取自OSEK標準文檔,圖中展示了OSEK/VDX的基本結(jié)構(gòu)和各組件間的關(guān)系。這也算是典型的帶網(wǎng)絡通信的汽車ECU軟件的最小系統(tǒng)了。
在2000年左右,Tier1的ECU軟件自研比例非常高,對軟件產(chǎn)品的掌控力也相當強,底層軟件和應用層軟件都由Tier1完成開發(fā)。OEM和Tier1之間軟件開發(fā)的合作方式,主要是由OEM向Tier1分發(fā)書寫格式和內(nèi)容非常規(guī)范化的需求文檔,有些做到好的,則采用格式化的語言來描述需求,甚至是偽代碼的書寫形式。
V模型開發(fā)流程(瀑布模型的進階)是當時的主流。按自上而下的過程遞交交付物,并在相對應層級依次驗證,是V模型開發(fā)的特點。V模型開發(fā)迭代周期長,一般與功能交樣時間相匹配。迭代次數(shù)少,一般5到6次迭代后,基本就到SOP量產(chǎn)了。當時汽車ECU功能定義固化早,每個ECU功能數(shù)量較少,需求開發(fā)相對穩(wěn)定,在當時看來,V模型的開發(fā)流程是非常合適的。
2
進階-AUTOSAR
上文提到了OSEK,因為它與AUTOSAR頗具淵源,AUTOSAR的部分設計也參考了OSEK標準。OSEK是汽車軟件標準化的第一步,它影響的范圍是ECU層面。OEM和Tier1之間穩(wěn)定的合作方式也已經(jīng)形成。但汽車軟件標準化的進程并沒有停下來。
這里插句題外話。OEM和Tier1的這種合作模式下,Tier1的系統(tǒng)與軟件能力變得格外的強,另外OSEK的標準化,總線設計的標準化,也讓各個廠家設計的ECU之間的連通變得簡單。在這個背景下,Tier1對整車電子電器架構(gòu)的影響很大,依靠Tier1的能力,攢起一套主流的電子電器架構(gòu)也成為可能。行業(yè)頭部的整車廠,Tier1,芯片等其他環(huán)節(jié)的供應商,對電子電器架構(gòu)的構(gòu)想也一定程度上推動著行業(yè)的發(fā)展。
上文有提到過,OEM需要花費相當大的精力來書寫需求說明書,以描述ECU的應用層功能,完成后交予Tier1來開發(fā)軟件。而隨著車上的ECU數(shù)量不斷增加,信號復雜程度增加,傳統(tǒng)的開發(fā)方式顯露出了開發(fā)復雜,維護困難等弊端。讓汽車電子系統(tǒng)開發(fā)更靈活,更有效率,成為汽車工程師的目標。AUTOSAR的誕生旨在達成這個目標。AUTOSAR從一開始就志在整體汽車電子開發(fā)的標準化。所以AUTOSAR所涵蓋的方法論,虛擬功能總線,元模型與模板工具,軟件架構(gòu)及模塊,所有這些工作都導向這一目標。可以毫不夸張的說,AUTOSAR是汽車工程師的智慧結(jié)晶。
AUTOSAR的推出,OEM與Tier1之間的合作方式有了微妙的變化。在介紹新的合作方式之前,這里 先介紹下AUTOSAR的核心概念:虛擬功能總線(VFB)。
下圖引用自AUTOSAR標準。如圖,VFB之上描述的是軟件組件(SWC),以實現(xiàn)軟硬分離。OEM著重于系統(tǒng)層面的設計,包含SWC的設計及它們之間的通信方式。VFB是虛擬總線,真實的情況是它們以Flexray,CAN總線方式通信,或者是ECU的內(nèi)部通信。而這些都會在整車開發(fā)流程中的SWC部署,網(wǎng)絡設計中體現(xiàn)。
在了解以上的基本概念后,再來講講OEM和Tier1的合作方式有哪些。
方式一:
OEM:以AUTOSAR的標準方法設計系統(tǒng)及軟件架構(gòu),并以ARXML的形式導出,同時負責應用層軟件SWC的開發(fā)。
Tier1:以AUTOSAR的標準方法完成基礎軟件的配置與生成,復雜驅(qū)動軟件的開發(fā),最終軟件的集成與版本釋放,并提供硬件平臺。
特點:雙方關(guān)注自己負責的軟件部分,耦合部分不多,溝通成本最低。
方式二:
OEM:基本與方式一相同,但OEM自己不開發(fā)應用層軟件。
Tier1:除了方式一提到的內(nèi)容,還包括應用層軟件的開發(fā)。
特點:軟件開發(fā)的工作都落到了Tier1身上,但應用層軟件需求溝通的成本較高。
方式三:
OEM:除了系統(tǒng)及軟件架構(gòu)設計以外,OEM還負責應用層及底層軟件開發(fā),包括最終軟件的集成與釋放。
Tier1:僅配置MCAL部分的軟件。
特點:OEM包攬了大部分的軟件工作,Tier1的價值僅在于提供硬件平臺(包括MCAL軟件)。
方式四:
OEM:按自身的方式設計系統(tǒng)架構(gòu)及發(fā)布需求,但并不是AUTOSAR的標準方法,應用層軟件開發(fā)為備選。
Tier1:以AUTOSAR的標準方法完成底層軟件,應用層軟件為備選,取決于OEM是否提供基于標準接口的應用層軟件。
特點:此方式用到了AUTOSAR軟件標準架構(gòu)和模塊,但缺少了精髓的系統(tǒng)設計部分。
另外,AUTOSAR也改變了軟件工程師需要的技能和工作方式。手工代碼漸漸轉(zhuǎn)向基于模型的開發(fā),底層功能模塊依靠工具配置及代碼生成。驗證軟件的方式也更多樣,模型仿真,SIL,HIL等等。
3
突破-AP AUTOSAR
從本節(jié)開始,AUTOSAR會標注CP (Classic Platform) 和AP (Adaptive Platform),以示區(qū)分。
CP AUTOSAR標準其實也在不停的演進中,Ethenet, Crypto, E2E, SOME/IP等等也是在4.X的版本中才出現(xiàn)。基本上,有新的技術(shù)需要運用,AUTOSAR就有推出相應的標準。
但CP平臺畢竟有它的局限性,對于高算力的應用場景無能為力。AP AUTOSAR的出現(xiàn)正是應對高性能計算平臺的需要,AP AUTOSAR的定位是運行于POSIX操作系統(tǒng)之上的中間件。設計者也不乏考慮,AP平臺和CP平臺在一個架構(gòu)下共存的問題。所以它與生俱來,具備和CP AUTOSAR有良好的交互能力。
高性能計算平臺必然是未來電子電器架構(gòu)的主角,已經(jīng)有不少架構(gòu)師們設想把它運用到多域控制器,以及中央計算平臺當中。AP AUTOSAR在高性能計算平臺的作用不可小覷。這可以從AP AUTOSAR的設計細節(jié)得出。
ARA:COM提供應用層之間標準且可靠的通信方式,統(tǒng)一化的通信方式有助于避免由于通信機制的不同造成的設計缺陷。同時支持事件驅(qū)動和輪詢模式也是它的主要特點,因?qū)崟r應用程序通?;谳喸兡J?,而支持此模式可以保證前后級數(shù)據(jù)傳遞式樣的一致,避免不必要的上下文切換。
ARA:EXEC主控應用程序的生命周期,設計者同時也考慮了功能安全方面的設計,例如狀態(tài)恢復,資源管理,確定性執(zhí)行等機制。
ARA:SM 收集應用程序的各種異常狀態(tài)并適時地調(diào)整相應的應用程序功能,為功能安全提供有效的機制。
ARA:PHM提供監(jiān)控應用程序的能力,并在檢測到異常后執(zhí)行恢復動作。它支持幾種典型的任務監(jiān)測機制:alive, deadline, logical supervision。
其他AP AUTOSAR包含的API及Service組件不在這里 一一介紹??梢钥闯?,APAUTOSAR除了提供基本的應用層開發(fā)平臺中間件,同時也有不少功能安全上的考慮,其中一些機制可以有效的應對ISO26262軟件部分“Freedom from interference”中提出的相關(guān)需求。
AP AUTOSAR在這樣一個復雜的環(huán)境下誕生,工程師們必定對其賦予厚望,從它的設計思路來看,AP AUTOSAR不但吸取了現(xiàn)有成熟的技術(shù),同時也有所創(chuàng)新,引入互聯(lián)網(wǎng)技術(shù)的同時也不乏考慮其適用性和可靠性。如今AP AUTOSAR剛經(jīng)歷了幾個版本,對比CP AUTOSAR從萌芽到茁壯成長的過程,AUTOSAR的未來必定可期。
— END—
《淺談汽車電子軟件》專輯
進入汽車行業(yè)是偶然,但選擇做軟件是必然。聽一位前輩說過,“你永遠別指望一個人能把一件不喜歡的事做好”,軟件技術(shù)一直是我的愛好,汽車也是我熱愛的,慶幸當初的自己能選擇這個行業(yè)?,F(xiàn)在閑暇時寫一些分享性的文章,希望和行業(yè)中的友人們一起成長。
作者:Paulfrank
-
OEM
+關(guān)注
關(guān)注
4文章
408瀏覽量
51663 -
AUTOSAR
+關(guān)注
關(guān)注
10文章
380瀏覽量
22694
發(fā)布評論請先 登錄
東軟睿馳亮相第16屆AUTOSAR開放大會
RT-Thread睿賽德正式成為AUTOSAR組織合作伙伴,攜手推動智能汽車技術(shù)新發(fā)展| 新聞速遞

黑芝麻智能與Elektrobit推出Classic AUTOSAR解決方案
AUTOSAR組織蒞臨普華基礎軟件參觀交流
光庭信息榮獲AUTOSAR中國中心2024年度特別貢獻獎
AUTOSAR通信對自動駕駛的影響 AUTOSAR通信與嵌入式系統(tǒng)設計
AUTOSAR通信與網(wǎng)絡安全 AUTOSAR通信在車輛中的應用
AUTOSAR通信實現(xiàn)中的常見問題
AUTOSAR中通信堆棧的配置 AUTOSAR通信模塊測試方法
AUTOSAR通信框架的優(yōu)勢 AUTOSAR通信實例與應用場景
AUTOSAR通信與CAN協(xié)議的關(guān)系
AUTOSAR通信組件介紹 AUTOSAR通信層功能分析
AUTOSAR通信協(xié)議解析 如何實現(xiàn)AUTOSAR通信
極海半導體推出AUTOSAR MCAL軟件包和配置工具

AUTOSAR解決方案 — INTEWORK-EAS-AP

評論