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