由蓋世汽車、AUTOSAR組織、上海車展三方聯合主辦的SDVF2021第二屆軟體定義汽車高峰論壇暨AUTOSAR2021中國日於4月19-21日在上海舉辦，本次活動也是2021上海車展的同期活動之一，同時也是AUTOSAR組織在中國區唯一官方會議。本次會議邀請到了
博世工程技術服務有限公司電子電氣架構工程師張人傑
先生
在本次論壇進行了題為
《
Autosar在面向服務架構中的支援與應用
》
的主題演講，以下是他在本次演講的主要內容：
大家好，非常感謝蓋世汽車和中國AUTOSAR給我們準備這樣的交流平臺，同時感謝AUTOSAR組織給我這個機會，在這裡和大家分享一下AUTOSAR在面向服務架構裡面的支援和應用。
我今天
分享
的幾點內容分別是
未來出行的願景，博世電子電氣架構的開發流程，AUTOSAR是怎麼針對面向服務架構的實現和支援。
大家都知道在新一輪全球科技革命和產業變革驅使下，
互聯化，定製化，自動化，電動化已經成為了汽車產業的一個趨勢。
在這四化裡面因為政策和環境的影響，電動化已經成為了最先佈局的方面，而隨著車聯網自動駕駛的融入，汽車的功能也變得越來越多樣化，定製化的汽車功能也成為了衡量一個汽車品質的標準之一。總之，電動化成為未來出行的一個基本要求，由互聯化，自動駕駛，定製化帶來的智慧出行成為了我們對於未來出行一個美好的期許。
隨著四化逐漸的理解和落地，我們發現汽車產業需要更先進的架構，更強大的硬體和更豐富的軟體來支援。當下汽車產業隨著軟體功能數量增加導致軟體週期迭代的緩慢，成本上升，同時因為我們電子電氣架構還是以分散式ECU為主，導致軟體數量上升，硬體數量也逐漸上升，對於OEM來說硬體採購成本，包括對於供應商管控難度都在上升。另外網路安全也導向一個最終話題，就是汽車產業開發成本上升。
而隨著新‘四化’帶來的美好設想，汽車需要更強大的架構，硬體，軟體的加持。但是回頭再看傳統汽車產業的設計開發流程。面臨著汽車功能數量增多，功能更復雜導致功能開發週期過長，硬體數量激增導致電子電器架構複雜度急劇上升，汽車互聯帶來的更多資訊保安和功能安全的考慮，對於各種資源的高效利用需求比如重量，通訊負載，能量消耗的問題。另外面臨著客戶需要更好的使用者體驗，面臨著跨域功能的多方協作的挑戰。而所有的這一些都帶來了一個核心問題汽車設計開發生產成本的上升，畢竟汽車作為一件商品，怎麼樣能夠在兼顧四化的同時又能提供極具價效比的汽車成為了OEM的考慮的問題。而軟體定義汽車，面向服務架構的提出就是為了能夠解決以上的問題。面向服務架構，我們所說的SOA能夠解決軟體開發迭代週期過長的問題，同時也推動了架構從分散式ECU到基於高效能運算平臺的域集中式的變革。而軟體定義汽車更是強調了軟體的重要性，也凸顯了Autosar的必要性。
我們看一下博世對於軟體定義汽車架構的理解，主要分為兩端，一個是車端，一個是雲端。車端包含在雲端實現的汽車服務和平臺的服務，博世IoT的服務。從車端可以看到，我們分成了兩個部件：硬體和軟體。再往上所有層級都是以軟體為劃分，所以凸現了軟體的重要性。再往上一層是硬體虛擬化和硬體抽象層，這一層對於下層硬體進行抽象和虛擬化，是為了提供給作業系統對硬體的呼叫，同時也保證不同的作業系統可以共享同一個硬體。在支援的作業系統裡面，大家熟悉的OSEK，當然也有效能更強的linux和安卓和QNX，再往上就是和AUTOSAR相關的，協議，中介軟體，底層軟體，這一層就是AUTOSAR大放異彩的地方，為不同的供應商和OEM減少軟體開發複雜度，提高了軟體的通用性。再往上便是應用層和介面層，可以看到博世在軟體定義層面將汽車分成幾個層級。我們換一個維度來看，從電子電氣化角度來看從分散式控制器到域集中控制器，它們又有怎樣的能力呢。
博世的汽車電子和軟體包括了汽車電子，動力，自動駕駛，駕駛輔助，車載多媒體，軟體架構。車身電子中包含閘道器，中央控制器，域控制器，車身控制單元，DC/DC轉換器。動力電子中包括VCU-plus，自動駕駛和駕駛輔助裡又包括了各類感測器，Dasy，VMC等。在車載多媒體方面包括顯示，娛樂等汽車電子。而在軟體方面擁有早期基於CP開發的CUBAS底層軟體，應用在ESC，ebooster，Radar等多個控制器上，現在又有基於AP開發同時相容CP的VRTE（vehicle runtime environment）。這一切都構成了博世汽車的跨域汽車電子軟體。同時依賴於這些寶貴的產品和經驗，我們的EEA設計更加豐富全面，跨域之間功能設計更加合理。
既然博世有這樣的經驗和技術，那在平常E/E裡面怎麼實現更好的佈局和域之間介面的設計呢？
博世的架構設計流程是
MBSE
（基於模型的系統工程設計）的設計方法，但是我們將
EE
架構開發抽象成
3
個部分，整車，系統，零部件，在
L1
中，我們將使用者的需求基於場景進行用例分析，從而獲得使用者功能的模型包括了使用者功能間的互動介面。此刻的使用者功能則是一個黑盒模型，比如使用者開啟了
TCS-OFF
功能，而內部的邏輯需要再進行白盒化分析從而得到系統需求，
TCS-OFF
功能開啟涉及到的內部邏輯。細分下來就是按鍵的功能需求，扭矩控制的功能需求等，再將這些功能放置到相應的域中，這裡的變化就比較多了，比如實體按鍵，軟開關，分屬在不同的域（車身或者娛樂），再把對應的需求劃撥到
分配好的零部件中，我們就變成了零部件的需求，可以把這個零部件提供給OEM或者供應商進行系統開發。
這塊就是我們博世對於整車電子電氣架構開發方法，不管是面向功能架構，還是面向服務架構，這套開發方法都可以應對這些場景的。
其實未來的E/E架構主要分為兩個方面，這張發展趨勢圖很明顯，主要是硬體減少和功能上移，隨著硬體減少和功能上移，但是其實軟體並沒有減少，反而會越來越多。
目前汽車行業E/E架構還是以分散式ECU，ECU分散式，CP就服務在ECU控制器上面，它能解決的問題就是實現了軟硬體解耦，提供了統一的標準，提高了軟體的高通用性。隨著基於高效能預算平臺的域集中式或者中央計算平臺架構的出現，已經不僅僅是ECU這麼簡單了，上面一個運算平臺上面可能會執行不同的作業系統和大量的應用軟體，作業系統和應用軟體之間是如何實現解耦的？就需要一箇中間件的實現，如果不解耦的話，不同作業系統可能開發數十個應用來進行，實現解耦就需要中介軟體實現，中介軟體的出現一方面是對下層硬體資源進行抽象，利用，另一方面對上提供下層ECU服務的介面，包括診斷的服務，控制器，高效能運算平臺的服務給上層提供軟體的開發。
這也是SOA解決的比較核心的問題，就是說如何實現應用開發和E/E架構的解耦，減少軟體工作量，減少網路介面配置的工作量。如果我們騰實現這些硬體層，中間層，應用層的解耦，同時它們不同元件中迭代的週期也會不一樣，應用層軟體迭代週期就會變得很快，可以豐富大家對於定製化的要求。這也伴隨著一個問題的到來，我們發現各個層級之間分的很清楚，我們可以類比於CP，把硬體層和軟體層做了區分，那CP就規定了硬體層和軟體層有一個統一的標準，統一的介面。既然我們把這三個層級也進行了分層，中介軟體作為承上啟下的部件那是不是需要一個標準來進行介面的規範化？那自適應AUTOSAR就隨之而來了，自適應AUTOSAR給我們中介軟體提供了一個非常詳細的標準，完善的規範來幫助我們來完成中介軟體的開發。
博世對於汽車計算機的架構也是分成三層，硬體層，應用層，中間層。
那我們是怎麼根據AUTOSAR進行中間層開發呢？我們把它分為三步：第一步是對中介軟體功能進行隔離，分成5層，分別是
硬體抽象層，作業系統介面層，面向服務中介軟體層，ECU平臺服務層，面向整車平臺服務層。
再往下我們根據已經成功分層的中間層的結構再去合理的根據AUTOSAR功能模組，包括功能叢集的分佈，將不同的功能集體方法到不同的層級中，這樣的好處是，因為我們知道AUTOSAR版本是一直在改變的，打個比方之前這個版本S2S是作為單獨服務，但是最近版本又把它整合進Communication management了，如果我們進行分層化和模組化開發的話就可以快速的針對AUTOSAR的改變，我們會把模組進行重新的集合和打包。我們再根據這樣的軟體的模組進行具體的設計和開發，這樣就得到了我們的產品VRTE。它提供的是一個面向自適應AUTOSAR的中介軟體，同時也支援經典AUTOSAR。它支援多種作業系統，另外也支援加密第三方軟體的整合和多功能域的整合。同時博世中介軟體軟體不僅是一套軟體的模組，它更是集成了開發套件，能夠支援上層應用的開發。
可以看到博世軟體層級是這麼八層，中間五層主要是中間層。第一層硬體抽象層，它做得是跟CP一樣的工作，是把硬體裝置介面進行統一化處理，內部實現方式大家都不一樣，但是介面標準是一樣的。第二層是作業系統介面層，包括各種通訊的協議棧。第三層是面向服務的通訊中介軟體，比如communication management。第四層是ECU平臺服務，就是原子級的服務，它對下層ECU提供的服務提取出來，然後作為ECU平臺服務供給上面整車層開發，整車層集合各個原子服務集，基於服務集我們進行上層更高階應用的開發。同時還提供保護域的功能，比如說基礎設施保護方面，我們透過安全域的劃分和程序的管理來實現保護作業系統和軟體的安全。另外在共享通訊方面也透過比如流量檢測等功能來保護安全。
在應用層保護方面講一下功能安全，其實功能安全主要分析還是看各個功能安全目標，如果這個應用功能安全等級非常明確之後，那我們就把它執行在域控制器上面。這塊就是軟體中間層包含的功能和內容。
既然說到中間層已經可以根據Adaptive autosar進行開發，而中介軟體是實現SOA面向服務開發的一個必要的元件，它的目的也是為了減少軟體的耦合度，更新軟體的開發週期。那麼應用層進行開發的時候是怎麼樣實現相互獨立開發，開發流程包括什麼，又是怎麼利用中介軟體的介面進行配置和開發的？
首先，基於目標硬體作業系統的選擇QNX，Linux，androidy，我們也選擇對應的開發工具Momentics還是eclipse還是adaptive studio等之後在專案包裡面主要分成三個部分，首先是應用設計，主要做得是應用介面的設計，包含三個部分：埠的定義，對於下層中介軟體平臺服務呼叫的定義，資料傳輸時候對資料型別的定義。靜態程式碼其實就是邏輯程式碼，Configuration就是修改通訊例項。我們透過生成技術生成應用，應用包括兩種型別的檔案，一個是C++，因為AUTOSAR要求C++作為唯一程式碼語言。應用設計也生成了Proxy和Skeleton程式碼，剩下這些API和網路，路由就是透過Application配置。
在具體編譯的時候，不管即將執行在的作業系統型別是什麼，整個配置是一致的，但是在編譯的時候會根據系統執行的目標作業系統，可以針對性使用它的編譯器。如果執行在QNX就用qcc，如果是linux可能就用gcc編譯器，這樣就得到了整個APP的應用。整個APP應用包括可執行檔案和中間層配置檔案。
其實這一套就實現了應用層軟體和中介軟體開發的分離，因為有AUTOSAR統一介面和標準，那我們之前的配置，裡面的內容都是一樣的，不管是什麼作業系統只要對編譯進行選項的調整就可以得到一個應用程式。
隨著面向服務架構和中介軟體的出現也改變了以往的商業模式（合作方式），第一種是博世一整套都由我們來提供。慢慢的演變成我們提供硬體或者中介軟體，你們可以透過中介軟體統一埠介面，第三方OEM或者第三方供應商進行應用開發。當然也可以只由博世提供中介軟體，硬體和應用都由第三方來開發，當然也可以基於博世的中介軟體進行二次開發，基於二次開發的中介軟體，大家無論是使用第三方硬體也好，博世硬體也好，進行應用的開發。可以說中介軟體成為了解決SOA面向服務架構的一個關鍵點。
總的來說，四化變成汽車的趨勢，但是任重而道遠，還有很多路要走。SOA面向服務架構幫助我們軟體定義汽車的實現。對於AUTOSAR又幫助SOA提供了一個非常明確的中介軟體開發的需求和標準。我希望在軟體定義汽車的時代，各個OEM和供應商之間隨著軟體開發投入的加大可以在未來有更深層次的合作。
下面是博世在本次大會中的精彩瞬間：
