只要傳統主機廠(chǎng)- 供應商的開(kāi)發(fā)體系不變，使用AUTOSAR的現狀就不會(huì )改變。傳統主機廠(chǎng)（特別是歐洲的主機廠(chǎng)）和一些沒(méi)有軟件能力的主機廠(chǎng)會(huì )繼續大規模使用。CP(Classic Platform)經(jīng)過(guò)10多年發(fā)展已經(jīng)是非常成熟的框架，經(jīng)過(guò)了眾多量產(chǎn)項目考驗。模塊的功能和API成熟度高。傳統主機廠(chǎng)最喜歡對供應商開(kāi)發(fā)的東西標準化。我甚至看到主機廠(chǎng)直接寫(xiě)ECU需求直接搬AUTOSAR Spec，比如網(wǎng)絡(luò )管理。而且，我自認為AUTOSAR最重要的貢獻就是，主機廠(chǎng)做通訊建模之后，導出某個(gè)節點(diǎn)ECU的CAN通訊矩陣，以ARAXML的格式。如果供應商用的AUTOSAR，工具鏈直接導入生成CAN通訊的代碼。我認為國產(chǎn)替代還是非常有希望的。AUTOSAR CP并不是什么先進(jìn)的框架。只是設計得非常復雜好像顯得門(mén)檻很高。國產(chǎn)替代能大幅度降低成本。
能否不用AUTOSAR？
結論：可以，但是我認為要想學(xué)Tesla自研不用AUTOSAR, 有幾個(gè)前提。
1、必須自研多個(gè)控制器。我在多個(gè)場(chǎng)合說(shuō)過(guò)，如果自研2個(gè)控制器以上，自己擼的框架比AUTOSAR從經(jīng)濟的角度合算。這是基于目前AUTOSAR供應商還是被國外廠(chǎng)商主導。
2、自己的軟件團隊需要有足夠的實(shí)力垂直集成/開(kāi)發(fā)。如果你的軟件團隊只能開(kāi)發(fā)應用層，最好盡快打消自研的念頭。你Hold不住。
下面給出我個(gè)人的推薦，參考AUTOSAR分層架構。一部分模塊已經(jīng)很成熟方案了，一部分模塊需要自研。給出參考建議方便讀者內部評估是否能自研。
操作系統：這部分完全沒(méi)必要自研。直接選用成熟的RTOS。你發(fā)現芯片廠(chǎng)商在發(fā)布新的芯片時(shí)都會(huì )預先集成常見(jiàn)的OS或者RTOS，并且提供驅動(dòng)的參考設計。也就是說(shuō)，如果你選用的RTOS比較常見(jiàn)，你后面連底層驅動(dòng)改動(dòng)都會(huì )非常少。比如一般芯片廠(chǎng)商會(huì )提供FreeRTOS的bring-up包括bootloader和所有常見(jiàn)外圍的驅動(dòng)等等。如果你是Safety系統，選用SafeRTOS，API和FreeRTOS兼容。這里我不是很明白，很多AUTOSAR廠(chǎng)商打包一個(gè)底層的OS給我，對我的好處在哪里？這些OS一般都是私有，按照這些OS的API反而把你綁在這個(gè)AUTOSAR廠(chǎng)商上。我認為：選擇常見(jiàn)OS的非常重要。工程師的學(xué)習成本低，而且絕對比AUTOSAR廠(chǎng)商提供的那套東西更成熟。唯一我能想到的好處是，AUTOSAR供應商告訴你他的OS完全滿(mǎn)足MISRA標準。顧慮：大部分RTOS沒(méi)有滿(mǎn)足MISRA C的要求開(kāi)發(fā)（包括FreeRTOS和國產(chǎn)RThread）。我們的做法是對幾個(gè)關(guān)鍵的文件我們自己做了符合MISRA的改動(dòng)。
底層驅動(dòng)：這部分芯片廠(chǎng)商都會(huì )提供參考設計。直接拿過(guò)來(lái)在上面改就行了。難度很低。注意Safety系統需要Safety BSP，這點(diǎn)上我的建議是，自己有能力就自己開(kāi)發(fā)Safety BSP。沒(méi)有足夠的能力就讓Safety OS的廠(chǎng)商提供。我們是自己做一部分，Safety OS廠(chǎng)商提供一部分通用的，節省時(shí)間和驗證成本。
硬件抽象HAL層：需要自己開(kāi)發(fā)，屏蔽底層硬件之間的差異性。這個(gè)設計上難度中等吧。我覺(jué)得比如RThread這部分做得還不錯?？傮w來(lái)講，就是使用函數指針來(lái)實(shí)現功能的多態(tài)。這算是C里的基操吧。一般高級工程師都能負責。
協(xié)議棧：什么網(wǎng)絡(luò )TCP/IP, AVB，DoIP這些。大部分時(shí)候都有成熟開(kāi)源的協(xié)議棧。我們一般直接拿來(lái)用或者做少量修改。我的建議是，公司內部還是最好有人熟悉代碼，即使有bug或者定制的需求可以自己做。這部分對工程師要求還是比較高的。比如我們使用的成熟開(kāi)源框架：
1. LwIP來(lái)做以太網(wǎng)協(xié)議棧，LittleFS做文件系統，TinyUSB做USB協(xié)議棧。
2. Linux為主的域控制器使用的開(kāi)源框架就更多了。這里都沒(méi)法一一羅列。
我負責的網(wǎng)絡(luò )團隊把LwIP源代碼完全吃透可以做任意修改。網(wǎng)上中文的源代碼分析也很多。難度不大。
提醒：我們對涉及到Safety部分的軟件功能使用開(kāi)源框架還是非常非常謹慎的。我個(gè)人建議Safety部分所有代碼自己擼。再往上就是一系列基礎服務(wù)了：診斷，功能安全Safety，信息安全，········等等。我們都是自己開(kāi)發(fā)。診斷：DoCAN，DoIP，UDS模塊都是自己寫(xiě)的。難度低。一個(gè)高級工程師帶一個(gè)研究生幾個(gè)月完成開(kāi)發(fā)測試。完全滿(mǎn)足ISO14229-1, ISO15765, ISO 13400-2要求。功能安全的模塊難度相對高。這里能找到又懂功能安全又懂軟件開(kāi)發(fā)的工程師非常非常難。AUTOSAR根據26262推薦的所有Safety measure我們都自己實(shí)現了。前后耗時(shí)做了一年多。因為開(kāi)發(fā)的難度本身也要大的多。信息安全：我們直接用的WolfSSL的Crypo+TLS模塊。如果遇到芯片上帶HSM（Hardware Security Module）,直接把WolfSSL 的某個(gè)Crypto API替換為硬件驅動(dòng)就可以了。難度低。
最后講麻煩一點(diǎn)的是：比如主機廠(chǎng)客戶(hù)用V的那套工具做CAN通訊建模。扔給你ARXML通訊矩陣。你需要自己開(kāi)發(fā)工具來(lái)解析ARXML，內部生成CAN通訊的代碼。
工具鏈: 我們自研的工具鏈，
1. 生成CAN/以太網(wǎng)通訊代碼，
2. 生成服務(wù)的底層通訊代碼。其他的建模我認為沒(méi)有必要。
總結
我個(gè)人認為所有號稱(chēng)自研控制器的供應商/主機廠(chǎng)都應該能做到上面所有。
轉自汽車(chē)電子與軟件
