前言：

汽車的智能化和軟件化，就像一個巨大的漩渦，吸引著各方勢力卷入其中。就像上一篇文章提到的一樣，在大家構建軟件能力過程中，一些危機也正在醞釀之中，在缺乏良好設計的框架下，一旦進入正常的車型迭代，就會被以前歷史的版本束縛住手腳。前面的系列文章從各個角度闡述了如何構建軟件驅動的硬件平臺能力：

• 《概述》
• 《面向服務的架構設計》
• 《SOA基礎軟件框架與參考實現》
• 《行業現狀》
• 《中央計算單元架構》
• 《開發人才從何而來》
• 《高性能計算單元架構》
• 《構建開源軟件生態系統》
• 《危機是如何釀成的》

我構思了很久，想以一種比較簡明扼要的方式，展現出整個數字系統架構的全貌。花了很長的時間去梳理，終于有了下面這張圖，現在看來，這是所有文章里面我最滿意的一張圖了，從整車的視角，展現出了如何去構建新一代整車數字化平臺。其實這也是一張作戰地圖，未來幾年，群雄逐鹿，各方勢力都將圍繞地圖中的各個主題進行展開。這張圖比較清楚的展示出了如何去構建一個軟件、硬件、車型平臺相互解耦的系統。

full stack architecture?這張圖是以A4紙的尺寸來進行繪制的。建議下載下來放大來看，原圖我會放在汽車電子軟件公眾號的后臺，大家可以在微信后臺輸入“架構總覽”獲取。畫這張整體架構圖，其實有以下幾個目的：

• 技術在這場變革中很重要，但是不是最關鍵的，從全局的角度去思考打造體系化的能力，首先必須知道要做的事情是什么。

• 對于產業鏈上的朋友來講也可以理解，究竟OEM客戶需要什么，自己所提供的產品，扮演了什么樣的角色。

• 對于投資圈朋友來講，參考這張圖可以了解到，感興趣的投資標的究竟處在什么樣的行業位置當中，想解決什么樣的問題，未來想發展成什么樣。

• 新平臺的開發，技術鏈路非常長且復雜，所以我非常希望看到產業鏈上的各個環節能夠形成合力。在這次變革當中，能夠幫助到各方玩家，更快的完成架構的升級和轉型。

• 整個工程就像一個龐大的戰役，如果各方都能清楚，自己在這個戰役當中的位置，作為執行者來講，也能夠發揮自己的主觀能動性，去更加積極主動的解決相關問題，也能知道如何去配合上下游開展工作。

架構總覽

整個架構可以總結為“6+4”：6層邏輯架構構建起了一個軟硬解耦的系統；4層服務架構完成了服務的抽象與適配，建立了一個標準化的服務體系；六層邏輯架構包括：

• 可拓展電子電氣架構，也叫計算與通信架構

• 可拓展硬件計算平臺

• 操作系統內核

• 分布式服務中間件

• 標準化服務層

• 可編排應用層

這6層的架構設計，實現了軟件、硬件、車型平臺相互解耦，之前也介紹過可能會碰到的軟件危機，而良好的架構設計是解決這其中很多問題的關鍵。總結下來，可以體現為以下幾點：

• 基于標準服務的開發，能夠提高應用的迭代速度，讓產品經理更加深入的介入產品的開發過程。

• 分層的架構設計，便于進行分層測試與驗證，減少集成測試的壓力，問題發現的更充分，也能夠提高版本發布的速度。

• 便于形成產品線和平臺線的分工，產品線負責具體車型項目，平臺線，負責構建技術中臺。

• 可拓展的硬件計算平臺，可以兼容多種傳感器和外部設備，同時支持芯片和硬件的可升級。

• 可拓展的計算通信架構，可以加快車型開發的速度，平臺能夠快速地適配到新的車型之上，分層的結構，把車型之間的差異化縮到最小，能夠減少后期多產品線維護的壓力。

1. 可拓展計算與通信架構

主要目的是，提供一個與車型無關的統一平臺，在此之上構建的所有車型都將采用統一架構。可拓展中央計算平臺與模塊化Zonal Controller 是構建這個標準電子架構的核心。中央計算單元將整合自動駕駛，智能座艙和車輛控制三大域的核心業務功能，標準化的區域控制器主要有三個職責：

• 電力分配
• 數據服務
• 區域網關

所謂的標準化區域控制器，是指所有的Zonal Controller都采用相同的硬件設計，擁有相同的IO接口。可以根據車型的需要靈活的去配置三個，四個，甚至更多的區域控制器，以滿足不同車型對于拓展性的要求。central+zonal中央計算單元與區域控制器之間都會采用高速以太網相互連接。因此，中央計算單元將會集成一個高吞吐量的以太網交換機。為了滿足車輛控制實時性的要求，核心網將會采用如TSN等的可靠通訊技術。在區域控制器下的局域網內，傳統的CAN、Lin等通訊方式將會繼續存在。局域網內可以以傳統的信號的方式進行通信，在核心的以太網骨干網絡中，將會以服務的方式進行數據之間的交互，就需要如DDS等通信中間件。隨著整車集成化的程度越來越高。越來越多ECU的功能將會慢慢的被吸收到區域控制器當中。所以，區域控制還同時承擔，整車硬件抽象的重要職能，這一塊在介紹服務層中的原子服務時會詳細說明。概括來講，可拓展的電子架構就是要屏蔽車型之間的硬件差異。不管采用多少個區域控制器組成的通訊網絡，其相互之間的通訊模式，都遵守同樣的規則。同時區域控制器也承擔其局域網內，ECU功能的抽象之責。

2. 可拓展中央計算平臺

中央計算平臺需要擁有統一的傳感器及外設接口，同時需要能夠兼容各家的芯片產品。隨著整車智能化的提高，越來越多的芯片玩家進入到了車載芯片領域，在此之前，車載芯片的迭代速度非常慢，然而最近幾年，車載芯片的迭代速度越來越快，各種高性能的芯片層出不窮。如果每次換芯片都要進行換骨手術，對整個技術架構進行重構，會極大的拖慢新產品的開發速度。目前來看，車載芯片的發展速度，正在向消費電子靠近，消費電子領域基本是一年一代芯片。車載領域雖然稍微慢一點，但是升級換代的訴求也非常強烈。關于中央計算單元的架構方式，之前的文章已專門做過闡述，有三種方式：分離SOC、硬件隔離、軟件虛擬化，詳細可參考這篇文章，《中央計算單元架構》總結下來，中央計算平臺需要擁有統一的傳感器及外設接口，同時能夠支持芯片的升級，其最終目的就是要實現在車生命周期內的硬件可升級，從而延長汽車的智能化生命周期。

3. 操作系統內核

關于操作系統的概念，之前的文章已經辨析過。目前各種操作系統的概念滿天飛，但大部分都只是操作系統中間件。由于車輛的復雜性以及對于實時性的要求，沒法用一個操作系統來統一所有的應用場景。這并不是一個軟件問題，在此不做過多闡述，詳細參考這篇文章，《軟件定義汽車-概述》在操作系統內核層面，最主要的就是要滿足實時性的要求，能夠保證系統的性能和穩定性。如果需要采用虛擬化的方案，很多虛擬化的工作也需要在這一層展開。這塊不是車廠的強項，也不是能夠體現產品差異化的地方。因為無論用誰家的，其實現的功能都非常相似。所以沒必要車廠單獨去開發一個內核，本身很多生態的建設靠車廠也無法完成，這個工作交給科技公司去做就好了，有很多成熟的可選的方案。在上面的圖中，也有一種類型的系統叫OS for MCU，最典型的就是Classic AutoSAR。從這個整體架構圖當中，大家也可以看到，它的生與死其實根本就不關鍵。因為它只是整個計算系統當中非常小的一塊兒。所有的代碼量加起來也就幾兆大小，對它的需求是成熟穩定，可用即可。在中央計算架構下，以太網是核心的通信方式，傳統的MCU的網絡管理、CAN通信、診斷等功能，將會被中央計算單元所吸收。未來中央計算單元的MCU承擔的最主要的職責可能是電源管理。

4. 分布式服務框架

很多人也把這層稱為XX.OS，其本質上是一個操作系統中間件。其最核心的作用，就是提供一個分布式的計算和通信框架。對下屏蔽各類操作系統內核的差異，對上提供統一的服務開發框架。其主要包含服務管理、網絡管理、通信管理、升級、診斷、日志、狀態等。Adaptive Autosar和ROS就是典型的分布式服務開發框架，此類中間件都是解決通用的技術問題，實質上也不是車廠的核心競爭力，當然有余力的也可以選擇自己開發，詳細可以參考這篇文章，《SOA基礎軟件框架與參考實現》

5. 標準化服務層

也有很多人把在這層也稱之為XX.OS，其主要目的是把車上，硬件功能抽象為各種服務，并且進行分類分層，為上層應用提供良好的開發SDK。在上圖的架構中，分為四層設計：

• 最下層是服務的適配層，運行在Zonal Controller之上，將對局域網內的ECU功能進行抽象化處理，面向具體車型的信號進行適配。
• 服務適配層向上對接的是原子服務，指的是硬件的一些基本功能，比如傳感器、電機控制、門窗、車燈等，最基本一些操作。
• 在原子服務之上是邏輯服務，也稱為組合服務，里面有一定的判斷邏輯存在。比如打開車門，打開車燈，并不是在任何狀態下都無條件執行，需要判斷很多條件。
• 在邏輯服務之上是業務服務，和各域的功能聯系的比較緊密。

服務的抽象也有一些方法論可以遵守，可以從原來ECU的信號出發，從下往上梳理，形成一系列原子服務。另外就是從業務功能出發，從上往下梳理，形成一系列的邏輯服務和業務服。關于SOA分類分層的介紹，可以參考這篇文章，《面向服務的架構設計》。我想強調的是，服務層的設計其實是車廠的關鍵能力，因為無論是服務中間件還是操作系統內核，很多的Tier1都可以去做，因為這些都是一個純技術性的通用工作。但是服務層的設計只有OEM廠商才能夠做。因為任何Tier1都只能接觸到其中的一部分，所以沒法從全局的角度去設計整個服務的框架，而這一層最大的作用就是，提供一些靈活可重組的基礎服務，以供上層應用場景的快速實現。為產品功能的快速迭代打下了很好的基礎。

6. 可編排應用層

在服務層之上就是各域的應用功能，此處的“域”只是一個虛擬的概念，因為在中央計算的架構下，各域之間已經沒有了明顯的物理邊界，邏輯上可以劃分為以下四個：

• 自動駕駛
• 智能座艙
• 車輛控制
• 智能天線

前面幾個都有過介紹，所謂的智能天線，其實就是集合了所有的與外界通信的功能，如BT、WIFI、NFC、V2X、5G等等。一個產品的功能往往都是需要，各域的相互配合才能實現的，在之前的技術架構下，產品經理很難介入到整個產品功能的開發周期當中。因為技術架構過于復雜，更多情況下是系統工程師在主導。所以把服務層做厚，把應用層做薄，把底層架構做充分的解耦，可以讓產品經理很深入的介入到產品功能的設計開發當中。此時產品功能的開發已經不需要去關心底層中間件、操作系統、硬件、電子架構的的影響。基于服務層提供的SDK可以快速的開發出產品所需要的功能，這也是未來智能座艙和自動駕駛等產品功能快速迭代的一個技術基礎。

結語

同樣一個問題，有多種解決的途徑，分析下來會有多種解決方案。但是需要做的事情分分類，也都殊途同歸。所以右邊的文字部分詳細的列出了各塊兒需要做的事情，可以供大家參考。每一個點都是非常龐大的主題，要講清楚，需要花很長的篇幅。后續有機會我們將圍繞這些工作，進行更加細致的闡述。很多人也在問，有沒有一些書或者成熟的方案可以借鑒，很難有，因為這是一個很新的領域，很多時候需要去創造產業鏈上沒有的東西，所以正向的研發，正向的思考是非常關鍵的。一切從問題出發，正向去思考，分析解決這些問題的途徑，自然而然的會形成一種比較一致的判斷。技術方案其實是一個非常客觀的東西，大家可以理性的去分析，也歡迎大家反饋自己的想法。本來是準備寫關于芯片定制化的一些思考，但是如果不解釋清楚整個技術架構，講芯片的定制化可能會讓大家感到疑惑。其實在設計中央計算單元的時候，最大的挑戰就是可用的芯片。目前沒有一款芯片能夠同時滿足幾大功能域的要求，只能用多個芯片拼起來。半導體行業其實已經有了從晶元級別去集成多個芯片的能力。下一期我們可以仔細聊聊這個話題。

• 后臺回復“架構總覽”，下載《汽車數字系統架構圖》

—END—

《軟件定義汽車》專輯

作為一個技術的愛好者，搞算法，玩芯片，攢系統，并不只是工作，也是自己所追求的很重要的部分。寫這個系列，是為了梳理這幾年的所學、所思、所想，從而形成一個完整的知識體系，也供大家參考。

作者：leo_huang_?

加入汽車軟件開發者社區(僅限技術人員)：

管理員微信：18521323533

技術交流群：YasmineMiao(微信)投稿合作：18918250345(微信)

總結

以上是生活随笔為你收集整理的虚拟局域网软件开源_软件定义汽车 (第十集)：决战架构之巅的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。