雞肋——汽車行業AUTOSAR的使用現狀和利弊分析--弊篇

以我有限的認知和體驗來談談堂堂AUTOSAR的一些弊端，也不敢說是弊端，只能說是局限性吧。還請輕怕。

在此之前我先說說目前AUTOSAR在市面上使用的幾種情況：

一種是號稱的AUTOSAR，在AUTOSAR概念剛剛興起的時候，不管是國內國外的汽車零部件廠商或者大小軟體服務商在宣傳語上都會宣傳基於AUTOSAR架構，這種狀況就像現在所有廠商都會宣傳自己是符合功能安全一樣。我此前在一個軟體諮詢公司待過，那會兒剛剛開始研究AUTOSAR的資料，還沒有做項目，公司的頁面就已經把我們軟體是基於AUTOSAR開發的作為宣傳了。這種情況很常見，我見過很多項目，軟體部分是外包的，不管這個項目的預算多少，項目是否必要，技術要求上都會無腦將AUTOSAR，功能安全各種要求堆放上去，但因為主導此項目的人並不了解AUTOSAR或者功能安全的要求，軟體外包服務商基本上在交付文檔上借用AUTOSAR的一張圖，介紹一下AUTOSAR的基本概念，軟體交付的工程結構勉強有個AUTOSAR的分層結構就算過關了。造成這種現象也是有原因的，國內主機廠好面子，供應商為了生存，就形成了畸形供需的狀況，總不能所有大小項目都被幾個零部件巨頭都承包了，現在這幾個巨頭依託於AUTOSAR和功能安全已經賺的金箔滿盆，而且有越來越難伺候的趨勢。

一種是購買了完整的工具鏈，投入人力和金錢嘗試開發AUTOSAR的，這裡又分兩種，一種是作為預言項目，項目結了就交差，或者遇到困難就半途而廢的，這在國內也常見。另一種是下決心好好整，希望能推向量產的。不管哪種，可以借用AUTOSAR核心會員的資源，利用他們的工具鏈，培訓服務和軟體服務，對於快速和深入學習AUTOSAR還是幫助很大的。AUTOSAR標準如果不借項目操作去理解，單看標準是很難的。

還有一種是不嚴格的AUTOSAR架構，就是用了AUTOSAR的核心概念，但是在實際使用中為了適應市面上各OEM的狀況，在軟體平台搭建時對AUTOSAR做了取捨，但核心架構和分層仍然AUTOSAR。我在幾家零部件巨頭的控制器軟體方案中都看到了這樣的情況。有的乾脆捨棄了RTE這一層，使用了傳統的介面進行軟體集成，這樣避免了國內很多廠家沒有RTE環境而無法與基於AUTOSAR架構的基礎軟體進行集成。這和功能安全類似，國外強調的功能安全的概念，而不是標準，利用了標準的方法和理念，沒有完全被標準束縛，他們通常都是自己對自己的認可，不像國內的企業需要請求第三方認證公司給自己發一個證，以此證明自己是優秀的，所以能看到國外的一些知名車企或者零部件廠商都是自己對自己認證，很少尋求第三方。此前和一個功能安全做了20年的資深工程師交流，他說功能安全是無止境的，而不是標準上的這些。我覺得這樣是相對務實的。當前的AUTOSAR不管是工具鏈，還是大家的接受程度，以及國內普及度，都還是不夠成熟的，做一些取捨是有必要的。

說了這麼多，有些跑題了，下面談一下我對AUTOSAR的一些弊端，從當前市面上幾個AUTOSAR工具鏈的情況，以及國內外零部件廠商在AUTOSAR的使用情況來看，AUTOSAR在國外或是國內的運用情況並不成熟，至少與AUTOSAR最初的設計理念還有較大的偏離，而且對於量產項目而言在靈活性上還是有所欠缺，其軟體復用性獨立性也不如宣傳的好使。從以下幾個方面說說我在項目中的一些AUTOSAR在實際使用時的而一些弊端：

一，AUTOSAR工具鏈不便宜且不成熟，不是針對哪家工具鏈，現在市面上使用的就那麼兩三家，據了解，多多少少都存在問題，這兩年在整個項目實施的過程，基本也是工具鏈逐漸更新修復BUG的過程，雖然項目已上車，軟體也能穩定運行，但由於工具bug而調整的手寫代碼也讓整個軟體工程變得不那麼「踏實」，軟體集成由於這些修補代碼也要變得格外小心。有的問題雖然並非算是工具bug，需要工具鏈支持而支持不了，工具鏈在適應實際項目需求時還是缺乏了靈活性。

二，工具鏈之間的兼容性影響了AUTOSAR軟體宣傳的復用性獨立性效果。AUTOSAR號稱的軟體模塊復用性和獨立性，在實際體驗中並沒有宣傳中的那樣好。一方面是因為這些工具鏈廠商對於自己產品的問題修復已自顧不暇，沒辦法花精力處理這一問題；另一方面出於利益衝突，他們互相之間並沒有做好的兼容性溝通和設計。當然還有個重要的原因，因為AUTOSAR的普及度還不夠，矛盾暴露的還不夠激烈。我向各個廠家諮詢過相關的問題，是否能將另一家公司配置好的RTE環境的描述文件用在當前公司的工具鏈中，並順利生產代碼。沒有一家可以打包票說沒有問題，也沒有人回復說嘗試過。這會造成一些問題，原本希望通過AUTOSAR的優勢，不同廠家一起合作完成一個軟體項目，但由於工具鏈的兼容性而不得不保持工具鏈的一致性，這對於合作的限制是很大的。

三，集成效率偏低，難以適應項目頻繁變更帶來的影響。這在業內也不是新鮮事了，大家都碰到了這種困擾。BSW與策略的介面集成，有大量的工作，雖然都是體力活，但當前的情況，這一體力活不僅在操作上低效，在錯誤檢查方面也不行，不如傳統軟體集成方式；另外由於項目變動需要調整CAN協議時，這一工作在傳統集成時是簡單的修改，但對於AUTOSAR項目來說是一個災難性的變動，基本上可以說此前80%的集成工作需要重新做，當然這一問題有國內廠家系統階段定義CAN協議太隨意造成變更太隨意的流程問題原因，不能全怪在AUTOSAR身上。

四，策略與BSW的適應性問題。AUTOSAR項目中，APP與基礎軟體的集成有兩種方式，一種是自上而下，另一種是自下而上。拿MATALAB來舉例，自上而下，是MATLAB策略軟體將定義號的模塊，介面，數據類型，調度周期等信息先做好定義生成ARXML文件，導入到AUTOSAR工具鏈中進行集成。自下而上，則是由AUTOSAR工具鏈定義好模塊及介面，生成ARXML文件後導入到MATLAB中，MATLAB再在此框架中進行建模。但還是由於工具兼容性的問題，基本上目前只能實現自上而下的集成方式，自下而上的方式，由於MATLAB對於AUTOSAR介面的檢查規則與其他廠家的規則不一致導致會報錯，基本上無法這樣實施。

五，調試問題。這是自動代碼生成的通病，和MATLAB自動生成的代碼一樣，RTE generator生成的代碼可讀性上也很差，這給軟體調試帶來了不少麻煩，在C代碼層級，信號的數據走向和函數調用需要一層一層的查詢才能找到相應的數據關係。

六，汽車工程師對於AUTOSAR新理念的接受程度。AUTOSAR提出了很多新概念，例如標定量是通過描述文件進行描述，再由RTE進行統一管理生成代碼。策略介面也不以簡單直接的全局變數的方式與底層軟體進行交互，而是對介面進行描述定義，由RTE統一進行介面匹配生產代碼。其他還有RE,IB,Interface等這些抽象的概念給接觸AUTOSAR的人帶來了很多困擾。AUTOSAR的軟體開發理念和傳統嵌入式工程師的認知偏差還是有些大的，造成了一些排斥心理，這也是AUTOSAR普及度不高的一個原因。

小結一下：有一種說法，行業內的標準都是幾個巨頭為了鞏固自己的壟斷地位制定出來。各位辯證的看這個問題，AUTOSAR利弊都挺明顯，不管怎樣，目前看來也還是汽車軟體開發發展的趨勢，我個人也希望AUTOSAR能夠越來越普及，以此來推動工具鏈或者標準在實際使用中的優化，畢竟是吃這碗飯的，擔心自己丟了飯碗。。上面是自己的觀點，認知有限，不對的地方望理解。

推薦閱讀：