由蓋世汽車、AUTOSAR組織、上海車展三方聯合主辦的SDVF2021第二屆軟體定義汽車高峰論壇暨AUTOSAR2021中國日於4月19-21日在上海舉辦，本次活動也是2021上海車展的同期活動之一，同時也是AUTOSAR組織在中國區唯一官方會議。本次會議邀請到了
東風汽車公司技術中心主任工程師樊昀
女士
在本次論壇進行了題為
《
AUTOSAR在東風的應用及發展
》
的主題演講，以下是她在本次演講的主要內容：
非常榮幸今天能被邀請過來跟大家分享AUTOSAR在東風的應用與發展。我今天想給大家分享的內容包括
東風引入AUTOSAR的背景，AUTOSAR在東風的
發展
演進，AUTOSAR在東風所開發的專案，還有我們的建議與體驗。
AUTOSAR在東風引入背景，普華的劉總講到當時採用AUTOSAR的原因，我覺得講的非常好。我們當時引入AUTOSAR也是因為汽車軟體面臨著大量電子化，MCU數量激增，整車廠需要維護多個MCU開發。採用傳統的開發模式就面臨著很多的弊端，為了解決這些問題，我們的總師高瞻遠矚，引入了AUTOSAR。
因為AUTOSAR有統一的介面，我們可以採用配置的方式，它的基礎軟體都是商業化的程式碼，安全性和可靠性都是非常高。
這個是AUTOSAR在東風的發展演進，東風做AUTOSAR開發差不多有十年了，2010年的時候我們組織了團隊對AUTOSAR進行了預研。2015年第一代發動機控制系統就是基於AUTOSAR開發的，同年我們購買了AUTOSAR平臺。2018年的時候第一代發動機控制系統EMS實現了量產，同時匹配了多款車型，第一代閘道器專案也實現了量產。目前為止，基於AUTOSAR開發的專案包括多款域控制器和自動駕駛專案，以及第二代中央閘道器的專案。
因為我是做AUTOSAR基礎軟體的開發，大約做了有八年左右時間，所以今天給大家講的更多是技術的分享。我們當時在做AUTOSAR之初採用的方式跟現在大家很多公司採用的方式一樣，拿到配置工具之後先匯入DBC檔案做通訊協議棧開發，再新增其他模組，再做上層SWC開發，最後得到系統描述檔案，匯出ECU extract，最後進行整合編譯。當然我們涉及到AUTOSAR模組有：系統服務、安全的、記憶體管理、診斷等各個方面。最初開始採用這種方式在專案開發過程中就發現了很多的弊端，於是在我們專案開發中對我們工具鏈進行逐漸完善。
這個圖是東風在目前為止採用的標準化AUTOSAR開發流程，從需求、架構、基礎軟體、應用軟體、整合
都有
完善的工具鏈。
可能很多在應用或者即將應用AUTOSAR都會面臨這樣一個問題。我們的需求及架構工具用的是systemweaver，開發工程師可以在裡面建立所需要的SWC介面，當然我們現在還在裡面維護了資料型別庫，我們知道在AUTOSAR開發過程中資料型別是一個比較複雜的東西，雖然寫程式碼的時候覺得資料型別很簡單，但是在AUTOSAR裡面資料型別涉及到三種，包括application datatype，implementation datatype，base type，每個對應關係都需要把它定義的很清楚。SWC工程師在裡面建立介面，因為可以引用裡面的資料型別庫，建立完之後可以匯出XML的檔案，這個xml檔案包含了他所需要的輸入輸出介面，這個檔案可以透過我們的工具導到Matlab裡面做下一步的策略邏輯的開發。
當
應用軟體和基礎軟體開發完之後，開發完之後我們有一個整合工具
叫
Jenkins，這個工具是開源的，為什麼我們採用這個工具
呢
？
我們都知道AUTOSAR貴，我們不可能讓每一個工程師都有一個賬號電腦上，應用工程師在做整合的時候怎麼辦呢？我們就有了這個工具，它是基於web頁面，呼叫批處理檔案實現程式碼整合編譯。如果要想整合一版軟體，比如說專案經理，他要求在某一個節點之前整合符合某個需求的一版軟體，他就會透過我們另外一個工具發給大家CR，在這個時間節點之前我們就會把對應的版本上傳到版本管理工具，到整合軟體的時候，專案經理就會去請求版本工具裡面所對應的版本下載到伺服器上。這個伺服器效能非常強大，因為它要做得工作就是將工程下載到本地之後需要呼叫matlab介面生成SWC對應的程式碼以及對應的arxml檔案。目的就是為了遮蔽應用工程師複雜的工作，因為他需要在裡面不但建立介面，還要知道採用觸發方式是什麼樣的。採用了我們的工具之後，他不需要關心這些內容，他所需要關心的就只是它的策略。我剛才所說的AUTOSAR定義的內容，全部給它做了一個封裝，生成程式碼的時候同時生成符合AUTOSAR的檔案。
在2020年東風基於戰略需求更換了AUTOSAR平臺，其實對於我們來說也是一個很大的挑戰。因為我們知道每家工具是不一樣的，你想把現有流程匹配到新的工具上面還是需要做很多的工作。但是我們的專家做了一個Python框架，在這個框架下面更改AUTOSAR描述檔案，讓它匹配新的平臺工具。也就是說，在現有架構不變情況下只是更換一下指令碼做自動的匹配，這個工作已經完成了，已經應用到新的專案之中了。
這裡給大家分享的，大家現在也許正在遇到的或者即將遇到的問題。
這裡面有一個非常好的技術在這個地方。東風在做中央閘道器開發的時候，我們知道閘道器主要是進行訊號路由或者報文路由，不管是採用哪家工具，我們把DBC導進去之後自動配置全是訊號路由。那麼，對於報文路由的需求，傳統的方式來做這個工作，就需要在COM中將報文和訊號刪除，然後在PDUR中將src和dest進行更改，這種方式弊端是每次都要進行幾百個訊號的刪除以及上百個PDUR的資料操作，但是每一次需求的變更，我們都需要重新匯入DBC，那以前的工作可能就要推倒重來。當時為了解決這個問題，我們寫了一個指令碼，也就是說，我們可以透過配置檔案，只需要維護一個配置檔案，執行一下我們的指令碼，全部幫你你配置好，不需要人工再做配置。
第一模組是BswM模組，它的邏輯很簡單，但是配置起來很麻煩，因為涉及到很多條，每一條都需要進行配置。因為在閘道器開發過程中有一個需求，閘道器需要最大覆蓋化，所有車型只發布一版軟體，透過改配置實現不同車上報文路由的轉發，我們就需要透過這個模組進行管理。
這個地方有一個截圖，把每一條加起來，如果是手動配置大概有1000條左右，每一次需求變更全部都要推倒重來。我們後來就用了自動化指令碼實現這部分內容，當然實現的還有閘道器整合診斷的功能。現在驗證結束以後後面再有新的開發都是一鍵生成。
我還想說的是在做診斷開發過程中很多廠家說，我是可以匯入CDD檔案，支援匯入ODX檔案，實際上東風也沒有匯入CDD檔案也沒有匯入ODX檔案，我們之前做法是做維護，透過自動化指令碼直接實現自動化配置。現在我們換了工具還是可以透過一個列表把DTC定義好，所需要的引數都定義好之後執行一個自動化指令碼，它就可以完全實現自動化配置。我為什麼要提這個？這個在我們迭代開發過程中是很能提高我們工作效率的。因為從一個需求到一個軟體版本的釋出要求時間只有兩週左右。
我再說一下軟體整合流程
。
採用一整套流程方法，這個流程從架構設計，介面設計，BSW開發，當然也包括CDD複雜驅動模組的開發，可能那部分佔的時間比較久，因為你要寫底層晶片的驅動，到介面Mapping，我們的Mapping工作也是屬於半自動化的，因為我們在做SWC開發的時候要求上層之間的輸入和輸出介面名字一致，這樣就可以透過指令碼實現自動化的匹配。底層和上層介面可以不一樣，我們也是透過一個表做一個人工的核查，匯出一個表實現自動化的配置，最後到RTE的自動化配置與生成，最終實現軟體的整合編譯。
這個地方是開發我們第二代發動機控制系統的時候，因為我們第一代發動機控制系統由於整個工具鏈還不是很熟悉，當時對AUTOSAR瞭解不是很深入，花了很長時間。但是我們在做第二代發動機EMS控制系統以及其他控制器開發過程中，我們開發的速度就明顯比以前快很多。為什麼？我們有300多個模組庫，涉及到各個領域的，扭矩的，燃燒的，通用模組庫等，那些通用模組庫基本上都適用於各個模組的開發。我們把模組庫把所需要的模組提取出來，然後做BSW開發，BSW診斷部分除了新增的，其他的基本上是沿用以及自動化配置，不需要人工做處理。IO抽象模組這塊程式碼和介面也是實現了自動化生成，包括。c檔案，因為對於有些專案來說，這個介面有幾百個，我們現在正在開發的中央控制系統確實它的介面就有幾百個，如果人為做這項工作的話，你要花很長的時間，而且不能保證人工出錯的機率，這塊我們也是透過自動化指令碼來做的。
這是我們採用AUTOSAR架構所進行開發的專案。第二代發動機控制系統匹配的是2020年獲得十佳發動機的C15TDR發動機。我們同時匹配這個發動機還有VECU的專案，搭載到HEV車型上面，今年已經實現了量產。第二個是域控制器，中央安全閘道器的開發已經實現PT裝車，預計2021年量產，同步匹配多款車型。我們還有域控制器，CCU域控制器開發，自動駕駛專案等目前也在開發階段。
這是東風從2015年以來基於AUTOSAR開發的控制器
。
第一代發動機EMS，當時匹配了好多個車型，閘道器專案，ADAS專案，第二代EMS，這是東風采用AUTOSAR架構開發的。我們剛開始採用AUTOSAR的時候開發一個ECU可能要花很長時間，但是在我們工具鏈整個流程建立起來之後，開發一個產品時間是很短的，相對於以前傳統的方式，開發週期很短，而且可靠性比較高。
這麼多年來，AUTOSAR給東風到底帶來了什麼好處？
1、高質量。以前我們採用手寫程式碼的方式，是幾個工程師在戰鬥。現在我們採用平臺，BSW程式碼都是供應商提供的，我們相當於後面還有一個團隊陪著我們在戰鬥。2、低成本。大家都說採用AUTOSAR平臺好貴，但是從長遠來看是值得的，因為你不用花很多人力和時間成本去找BUG。3、短週期。在開發過程中，可以看到你的體系流程建立起來之後開發一款產品，它的時間可以大大的縮短。
我們東風在AP AUTOSAR上面做了一些預研工作，希望下次再開這個會議的時候，能有東風工程師講一下AP AUTOSAR在東風發展的情況。
最後跟大家分享一下收集的工程師的一些建議以及這麼多年來我們去做AUTOSAR心得體會。說起體會來還是挺複雜的，做了這麼多年AUTOSAR，還是有很多感觸的。
在這裡我想用王國維
的
讀書三境界形容一下，我們在使用AUTOSAR過程當中的三個境界。
第一個境界是：昨夜西風凋碧樹，獨上高樓，望盡天涯路。剛開始是拿著AUTOSAR標準幾個人在翻譯，一句話一句話翻譯，翻譯完之後，我不知道它在講的是什麼，不知所云。第二個境界是：衣帶漸寬終不悔，為伊消得人憔悴。我們在真正做專案開發的時候看它的程式碼，再同步去看標準，再去看程式碼看配置背後所蘊含的含義，從工程中去了解標準的含義。第三個境界：眾裡尋他千百度，驀然回首，那人卻在燈火闌珊處。當一個專案一個一個專案做下來，做了幾個專案之後再去看標準，你就會豁然開朗，你才知道原來那些引數是什麼意思，那個時候你再看的時候就會覺得AUTOSAR確實很好用。
路漫漫其修遠兮，當然東風也面臨很多的挑戰，但是我們東風依舊會不忘初心，上下求索。同時也希望AUTOSAR能夠發展的越來越好，讓每一個使用AUTOSAR的人能夠體會到它的美，謝謝大家。
下面是東風汽車在本次大會中的精彩瞬間：
