一、AUTOSAR簡介

先簡單介紹下AUTOSAR，不論從這個組織架構上，還是涵蓋範圍上，以及标準實施上。其實AUTOSAR都是一個集大成者，九個核心會員基本上就不變了。他們一直在左右這個AUTOSAR的發展方向。

那其他的會員，也分不同層級，就看這個圖上有很多圈兒，有第一層第二層，不同層級都有不同的權限，所以很多公司都想進這個圈。

AUTOSAR發展一直沒有停止，基本上每年都會出新版本，從原來的1.0不成熟，到後面的3.0到4.0系列，現在的話已經到這個名字已經不那麼叫了，不叫5.0了，叫R20，R21，這個名字就比較時尚了。在官網這些個版本都可以找到，有感興趣的話可以去下載，比較一下有什麼區别。你可以看一下主要的你想關注的部分。

不管怎麼變，其實AUTOSAR它的核心思想并沒有變，還是三條，第一個就是統一标準，提供一個開放的，一個通的标準文檔，大家都可以看，免費的。第二個，就是實現可以分散，它有比較高的層次化和模塊化，在結構上和硬件解耦，然後軟件，上下層解耦。

經常看到一個口号，就是說AUTOSAR他是以什麼方式來實現？标準合作實現來競争，标準共享，大家憑本事自己去實現，最後來去互相競争，這個基本上已經達成了共識。

從上圖看比較明顯，左邊的話基本上就是由工具來實現，然後通過配置，還有一些個定義。最後生成代碼到右邊，是工程師比較較熟的過程了，就是做軟件開發的一個基本的過程。

比如說寫個自動代碼，編譯鍊接，然後後面做處理等等，當然這個反複叠代是是不可避免的，一定要反複叠代，因為很多需求也在變，包括OEM的需求在變，需求一直在變，基本上我們也都司空見慣了（這點是很正常的）。所以看起來是一個比較容易的事情，這種東西其實反複叠代可能好多遍，最後你才生成一個雙方都滿意的版本。

另外一個AUTOSAR的優點就是文檔多，一般做别的開發，就感覺文檔比較少，可參考的文檔比較少，但是AUTOSAR不一樣，它文檔就很多，規範的話200多個，需求2600多個.按每頁A4紙來算的話，大概有兩萬多頁。高度的話差不多就是兩米。他從軟件架構、軟件需求到軟件詳細設計，到設計用例。

二、AUTOSAR的三個主要優點

第一個就是很明顯能縮短這個開發時間，如果你不使用AUTOSAR，要開發一個比較複雜系統，你基本上兩到三年是要的。用了AUTOSAR的話，最慢半年搞定了，如果快的話可能更短，如果成熟的話。對單個模塊開發的話更快，因為AUTOSAR已經幫你做好了，你隻需要配一下可能一兩周就搞定。

第二個：AUTOSAR他把你的文檔架構都已經做好了。剩下後面的工作可能就是配一下，然後整合一下，因為AUTOSAR幫你把文檔架構都已經做好了，所以架構師的角色也不需要了，基本上就不用配這個架構師了，開發人員的話，3分之2的人都可以裁掉了，所以看起來維持的幾十個人團隊，目前看來好像還挺大的，其實相比以前這種開發的話，人數已經少太多了。

第三個就是測試要求降低了，因為代碼已經是由工具廠幫你做了，單元測試你可以就不用去做了，你如果需要的話，這些個認證，可以去跟供應商去要。

關于AUTOSAR的未來，圖上的A點和B點就不用多說了，基于汽車的智能化發展越來越多，需求也越來越多，功能安全和信息安全也一定會涉及到。AUTOSAR持續更新，那麼供應商也一定會提供這些模塊。

主要是C點AUTOSAR是高度依賴于工具的，所以後面做的越來越智能，有些工具已經做的就很傻瓜，你默認配置可能就解決了80%的工作，剩下的20%出問題，可能有自動修複就幫你搞定了。

三、AUTOSAR的弊端

第一個弊端就是貴。這個買過的人都知道它很貴，就是基本上幾百萬，可能還還收費形式不一樣，對針對不同的控制器，針對于不同的芯片項目都不一樣。這個很貴。一般小廠的話，好像買這個可能要掂量掂量，因為什麼都沒産出的話，幾百萬就花掉了。另外一個，對于不滿足需求部分，如果你想去讓工具廠商去改，那這個費用也非常高的，而且時間很長。這是它的第一個弊端。

對于控制器來說AUTOSAR有這幾個缺點

1. 代碼量龐大

他代碼量特别大。因為它很多這種配置項，除了那些個可以預編譯的以外，還會有很多也沒有細看過，當然裡面很多東西也不知道做什麼，反正一個文件一個功能的話，它總是搞得比較複雜，當然從安全的角度是有他的道理的。和一個以前同樣功能的控制器相比，代碼相當于四到六倍，這個很常見，所以對于flash要求很耗資源。在選的時候，如果你想用AUTOSAR的話，你你可能真的要考慮考慮你的flash要選多大，加上現在的話，因為還有很多雙備份刷新，你這個容量肯定翻倍了。

2. 選項衆多

因為想把這個工具，這個模塊做的盡量覆蓋所有功能。那麼他一定有很多選項，那麼你這個項目還要，那個項目不要，那麼這些怎麼辦？你隻能通過這種選項來配，所以這些選項特别多。而且有的選項互相牽連，你配錯一個别的還配不下去？雖然有些很多東西可以默認，但是依然有很多是讓你去自己去控制它的。

3. 邏輯比較複雜

因為它裡面大量的結構體，套結構體，結構體指針，指針又指向結構體，這個特别多，平時如果隻是編譯一下Demo雖然可能你用不到。但是量産的話肯定會有問題，有問題要排查，一旦排查起來，對于底層的話就是比較災難了，就是你要看代碼，這個時候因為代碼不是自己寫的，你就很難去很精确的定位到這個問題，可能配置開始檢查，用調制器來來回回調試，所以對于問題的鎖定就比較困難。

四、AUTOSAR的普及對行業的從業者帶來了哪些影響？

因為我做這塊兒比較久了，所以也接觸了很多底層軟件工程師，很多人反映說現在這個底層開發已經不像以前了，大部分從一個公司軟件工程師，成為了一個工具人，隻要你去點點鼠标，用工具去配就可以了。所以導緻工程師的成就感不高。

另外一個，MCAL也不用寫了。硬件驅動基本上MCAL靠本搞定，那麼你不需要再去一行行讀這個代碼，讀這個文檔datasheet。大部分工作其實都可以通過這個配置來配出來，基本上他那個MCAL做的都比較智能，所以你配一下，可能下面一堆的這種寫寄存器的工作就全部幫你搞定。

那因為第一個第二個，那麼第三個特殊需求的開發能力變弱，AUTOSAR讓基礎軟件開發變得高度統一，對工程師的能力要求越來越低，最終讓整個行業從0到1的開發能力變低。因為整個AUTOSAR是對這個基礎軟件負責的，所以看右邊這個圖的話，AUTOSAR其實是整個在金字塔是偏底下的，也就是說最接近于硬件的，相當于。傳統計算機裡面的系統軟件。

還有這個結構，其實越到下面越需要穩定，這樣的話，才能保證上面的穩定，本上面的工作本來就不那麼穩定，比如做些刷新，通過FOTA,SOTA更新上面的，那這個時候如果底層不穩定的話，整個系統就不會穩定，你這個控制器做出來肯定要出問題的。最終誰來買單？肯定是用戶了，終端用戶來買單，所以我覺得這個是個比較大的影響，就是不再有去深究這個技術的人員，而隻去圖産品開發快。

總結下來的話，有這麼兩點，第一個就是，個人得不到成長。在軟件公司的話就淪為工具。甚至也不需要一些編程經驗，所以成就感不足，那麼很多人的話就就轉型了，就不做這個了，去做比較熱門的行業，比如說自動駕駛，或者說你想做一些算法。

第二個是AUTOSAR标準和實現基本上都在國外，主要是歐洲幾個大公司，這基本上幾個大公司都知道，國内也遇到這個問題，國内有幾家的話也在做這個AUTOSAR開發，但是相比國外的話還有點差距，因為畢竟國外人比較多，一般做一個項目上千人做很久，國内的話。我還沒有見到上千開發AUTOSAR的，可能搞個大幾十人，就不錯了。而且AUTOSAR要求比較高，看起來他好像就一個模塊一個模塊獨立，其實并不是。就好像你去組織上千去去蓋樓一樣。你沒有這方面建築基礎的話，你可能蓋的都是平房，你想蓋個摩天大廈的話，你得有很好的架構設計師，這塊也是國内比較缺失的。沒有之前那些積累的話，慢慢的話可能對國内的汽車基礎軟件是個影響。可能存在這種什麼卡脖子的情況。大家現在被芯片搞得都比較擔心了。雖然現在看起來好像這個問題沒那麼突出，但是我猜想可能這個問題早晚會凸顯出來。除非像華為一樣，他能夠組織大量人力，有那麼多有豐富的公司來做AUTOSAR。

針對以上弊端對工程師有哪些要求？避免成為工具人呢？

第一個，我們首先得承認AUTOSAR确實是個好東西，因為它的整個思想體系，還有一些文檔都非常成熟，它是集世界上各大主機的思想于一體，很多需求都是他們提出來的，所以要做的話，其實還是要好好學習一下AUTOSAR。

尤其你如果想從事哪一部分的話，你要把這塊讀深入。真的讀懂，而不是把那個文檔去讀一讀，可能你真的要讀需求，讀文檔。再讀某家公司的代碼，最後再反向思考去想一想，如果讓你來寫，如何寫這個代碼。這樣長期積累下來，你才能不至于落後，你還是一個工程師。

第二個，AUTOSAR的需求，特别清晰。雖然很多描述的語言不多，每一個方格兒，那麼裡邊還是比較清晰的，而且每個需求都有實現和詳細設計對應。

第三個就是一個方法論的事情。AUTOSAR不僅是AUTOSAR的軟件開發這麼做。它裡面更多地體現了一些似于哲學思想在裡面。所以你把這些個慢慢積累起來的話，你也會樹立一個正确的開發方法論，這對于你以後開發新的東西就有很好的指導作用，你也就知道應該怎麼正向開發，應該先做什麼，後做什麼，給别人提供什麼文檔。

第四個接口比較明确。比如說每個接口定義很清楚，輸出還有包含關系很明确，他每一個模塊都有相互包含的文件，頭文件包含關系非常清晰，之前是沒有人整理的，而且這麼大規模整理是沒有的。所以最簡單做法就是頭文件全包含，看起來也編譯肯定沒問題，但是終不是規範的做法。

如果堅持想要做軟件工程師的話，我覺得這六點還是要堅持下來：

第一個：一定要有團隊合作精神，交流分享，我覺得這個很重要，這個看起來和軟件并沒有關系，但是它是指導整個軟件的一個大方向。因為有有些公司的這塊文化，可能就不怎麼交流。自己做一塊兒，那麼反正别人也不知道，我也隻會這一塊兒的話，比如說有什麼事情耽擱，那你隻能自己上，因為你的東西在你自己電腦上，那你不加班别人也沒法替你加班。那還有的，就是在部門之間也要合作，有的公司連硬件原圖都不給軟件工程師的話，其實原理圖的話是個很好的交互語言，這個語言不用，然後非要去寫那個上百頁的HSI軟件，這個文檔哪搞來搞去，搞來搞去，去耽誤時間，覺得又沒什麼用。所以團隊合作非常重要。

第二個是從一開始設計的時候，你要考慮這個軟件是可能工程化量産，是不是有變形項目，還有多少配置可以去選擇，這些個留出來，對以後升級做準備。不要一下子把這個接口定死，或者說就寫成一個比較死的常量放那裡。

第三個，既然是軟件公司，這裡提到軟件不提編程好像說不過去，那麼編程的話肯定要有，這就需要有長期的積累。

常用的話，現在其實底層主要是這個C語言，還有python，一些腳本語言，這些都會用到，這些個會很好的幫你去解決很多問題。做一些個小工具等等都不錯。要理解一個問題，用多角度去理解，你考慮比較全面一點。往往我們可能隻針對一個需求去做，還是從一個全面的，雖然作為基礎軟件底層工程師，還是要對整個硬件系統，整個物理世界。要比較清楚一點，這樣的話你才知道你這個開發初衷到底是怎麼做。

反正我看那個文檔，國内大部分寫的都覺得不太好。那你再看那個AUTOSAR文檔，他确實寫得很好，每一個都是很多頁，而且沒有什麼太多的廢話。所以當然這和國内環境有關系，因為很多公司是不留給文檔寫作時間的，其實文檔占了整個開發很大一部分工作量，一定要把這部分時間留出來。有意識的去創造這麼一個環境，可能就不是我們所能做到的，需要這個上面層面來支持這個事。

最後一個是測試，自己不做測試，扔給測試團隊，有些東西，自己還要測一測的，因為你做開發之後，你不測的話，你真的不知道正确與否。那隻有這種不斷的測試，你開發的，測試自己去做，相當于就有這麼一個PDCA的一個循環過程，不斷提高自我。

五、關于修改靜态代碼

我們常說AUTOSAR，它分為靜态代碼和配置代碼，靜态代碼的話就不需要修改，這個其實不絕對。因為需求，如果他那些已經提到的需求，他肯定覆蓋到了，你認為他全覆蓋到了，但是。這個世界上往往有例外，終歸有需求它覆蓋不到，那這個怎麼辦？你如果去找原廠去修改，那個時間又長費用又貴，其實也沒幾句話。這時候，你就要做到敢于去修改代碼，敢于去看，當然你不要這種很盲目的，還要做到膽大心細，你要做好理解，做好文檔，做好測試，整個你能想到全部做完了，這些個也滿足你需求了，其實你可以改的。不要怕這種承擔責任。因為一旦改了，這些公司說你改代碼我就不管了。其實這個是不負責的。比如說有些個廠商要求CAN ID動态更改。這個沒法去配。你隻能自己去改。

還有大部分應該說現在的AUTOSAR底層，都沒有個标定功能，但是有的公司就要求，因為他改這個東西，可能就不用去修改代碼了，不用修改不用去編譯了，可能改幾個标定量就不用重新配了，那這個工作就是客戶需求，也不是過分的需求，說怎麼辦？那還需要改。

第三個企标，每家企标大同小異，但是差異化部分也需要自己修改等等，包括複雜驅動，所以說我覺得還是要去敢于去修改這段代碼。不要把AUTOSAR特别神秘化。

來源：汽車電子與軟件 侵删

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!