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