天天看點

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

01

智能汽車軟體架構梳理

軟體定義汽車時代下,智能汽車軟體架構逐漸向SOA 邁進

1.1 軟體成為智能汽車差異化的核心

汽車智能化的大趨勢下,“軟體定義汽車”成為産業共識。簡單來說,軟體定義汽車(Software Defined Vehicles,SDV)指的是軟體将深度參與到汽車定義、開發、驗證、銷售、服務等過程中,并不斷改變和優化各個過程,實作體驗持續優化、過程持續優化、價值持續創造。

目前,不同車型在硬體配置方面逐漸趨同,各大車企在硬體領域已經經曆了漫長的競争,硬體及其成本持續改善的空間較為有限。相較于傳統汽車,智能汽車能為車主創造豐富的、可感覺的價值以及全新的駕駛體驗,這也是目前不同汽車形成差異化的關鍵。是以,軟體和算法逐漸成為了車企競争的核心要素,造車的壁壘也由從前的上萬個零部件拼合內建能力演變成将上億行代碼組合運作的能力。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

軟體價值不斷提升,全球汽車軟體市場将快速增長。據麥肯錫預測,全球汽車軟體與硬體産品内容結構正發生着重大變化,2016 年軟體驅動占比從 2010 年的 7%增長到 10%,預計 2030 年軟體驅動的占比将達到 30%。從規模上來看,全球汽車軟體市場規模将從 2020 年的 350 億美元增長到 840 億美元,未來将有巨大的空間。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

競逐智能化下半場,軟體及計算能力成為新時代下汽車的核心。智能化、網聯化、電動化、共享化已成為汽車産業變革的必然趨勢,汽車産品逐漸由傳統代步機械工具向新一代具備感覺和決策能力的智能終端轉變。在汽車“新四化”浪潮的變革趨勢下,比亞迪董事局主席兼總裁王傳福曾在 2021聯想創新科技大會上表示:“電動化是上半場,智能化是下半場。智能化是更大的變革,創造的生态超乎想象。

”在電動汽車時代,電池、電驅等三電核心技術是比亞迪的護城河,王傳福認為,在下一個汽車時代軟體決定了汽車競争力。在 2021華為智能汽車解決方案生态論壇上,華為智能汽車解決方案 BU CEO 餘承東同樣表示,電動化、網聯化、智能化的時代已經到來,與傳統汽車相比,智能汽車的本質已經發生了改變,計算和軟體成為了汽車的核心。可以預見的是,未來汽車智能化将成為各大車廠競逐的焦點,而軟體能力将成為定義整車功能的關鍵。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進
【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

“硬體預埋,軟體更新”成為車企主流政策,未來汽車軟體、算法優化空間巨大。目前面向量産乘用車的智能駕駛系統整體處于 L3及以下級别,智能駕駛技術仍在持續疊代更新中。汽車産品具備較長的生命周期,一般為 5-10 年,車載計算平台的算力上限決定車輛生命周期内可承載的軟體服務更新上限。相較而言軟體疊代更快,是以智能駕駛軟體疊代周期與硬體更換周期存在錯位。

為保證車輛在全生命周期内的持續軟體更新能力,主機廠在智能駕駛上采取“硬體預置,軟體更新”的政策,通過預置大算力晶片,為後續軟體與算法更新優化提供足夠發展空間。以蔚來、智己、威馬、小鵬為代表的主機廠在新一代車型中均将智能駕駛算力提升至 500-1000Tops 級别。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

大陸智能汽車産業發展速度領先世界,L3 及以上級别自動駕駛落地有望為行業帶來更大機遇。在巨大的消費需求推動下,大陸汽車産業鍊中的企業密切合作,不僅建構了良性互動的生态環境,并且推動着行業标準水準快速提升。根據 IHS Markit 資料,大陸 2020 年智能座艙新車滲透率達48.8%,且到 2025 年預計可以超過 75%,無論是滲透率還是滲透率提升速度均高于全球水準。

從座艙域到駕駛域,近年來高算力晶片的問世加速了智能汽車向更進階别自動駕駛的演進,例如英偉達推出的Xavier(30TOPS)、DRIVE Orin(254TOPS)、DRIVE Atlan(1000TOPS),而根據地平線資料,實作 L3 自動駕駛的算力需達 20-30TOPS,到 L4 級需要 200TOPS 以上,可見目前晶片算力方面已為 L3及更進階别的自動駕駛“做好了準備”。

根據艾瑞咨詢,随着智能駕駛相關上路法規的不斷完善,L3 級别有條件自動駕駛乘用車有望在 2023 年開始逐漸落地。結合大陸新勢力車企對于今年新車型的大算力預埋,我們認為,2022-2023 年将成為 L3 及更進階别自動駕駛發展的關鍵節點,具有領先軟體和算法能力的車企、軟體供應商有望獲得重要機遇。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

1.2 軟硬體解耦帶動汽車軟體架構向 SOA 演進 傳統汽車分布式的 EE 架構難以适應軟體定義汽車的時代需求:

1> 在傳統 EE 架構中軟硬體高度嵌套,軟體功能的實作更加依賴于硬體。若要新增單一功能,需要改變所有與其相關的 ECU 軟體,同時也要修改車内電線、線束布線等,功能或系統更新的複雜性極大,車企內建驗證更為困難。若要實作較為複雜的功能,則需要多個控制器同時開發完成才能進行驗證,一旦其中任意一個控制器出現問題,可能導緻整個功能全部失效;

2> 在傳統分布式 EE 架構之下,ECU 由不同的供應商開發,架構無法複用,無法統一。同時, OTA 外部開發者無法對 ECU 進行程式設計,無法由軟體定義新的功能,以進行硬體更新;

3> 基于傳統分布式 EE 架構,車企隻是架構的定義者,核心功能是由各個 ECU 完成,其軟體開發工作主要是由 Tier1 完成。主機廠隻做內建的工作,這也導緻過去大部分主機廠自身的軟體開發能力較弱。

随着汽車不斷向智能化、網聯化方向發展,以單片機為核心的傳統分布式電子電氣架構已經很難滿足未來智能汽車産品的開發需求,同時還面臨算力束縛、通訊效率缺陷、以及不受控的線束等成本黑洞。是以,汽車電子電氣架構從傳統分布式架構正在朝向域架構、中央計算架構轉變,而集中化的 EE 架構是實作軟體定義汽車重要的硬體基礎。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

在集中化的 EE 架構下軟硬體解耦,軟體開發逐漸通用化、平台化。分布式軟體架構是一種面向信号的架構,控制器之間通過信号來傳遞資訊,整個系統是封閉、靜态的,在編譯階段就被定義完成,是以若主機廠要修改或增加某個控制器的功能定義,同時該指令還必須調用另一個控制器上的功能時,就不得不把所有需要的控制器都更新,大大延長開發周期、增加開發成本。

此時,軟硬體高度嵌套,硬體之間難以形成較強的協同性,汽車軟體的可複用性和 OTA 更新能力整體較弱。随着汽車 EE 架構逐漸趨于集中化,域控制器或中央計算平台以分層式或面向服務的架構部署,ECU 數量大幅減少,汽車底層硬體平台需要提供更為強大的算力支援,軟體也不再是基于某一固定硬體開發,而是要具備可移植、可疊代和可拓展等特性。汽車原有以 ECU 為單元的研發組織将發生轉變,形成通用硬體平台、基礎軟體平台以及各類應用軟體的新型研發組織形态。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

為實作軟體定義汽車,智能汽車軟體架構需向 SOA 轉型更新。過去汽車軟體架構更多是面向信号的架構(Signal-Oriented Architecture),ECU 的功能是固定的,軟體被提前編寫在控制器中。

但随着智能汽車的發展,車内搭載的 ECU 數量快速增加,這不僅使 ECU 的點對點的通訊變得十分複雜,且不具備靈活性和擴充性,微小的功能改動都會引起整車通訊矩陣以及各 ECU 軟體的變動。SOA(Service-Oriented Architecture,面向服務的軟體架構)是一種軟體架構,同時也是一種軟體設計方法和理念,其具備接口标準化、松耦合、靈活易于擴充等特點:

1> 首先,在 SOA架構中每一個服務都具有唯一且獨立互不影響的身份辨別(ID),界定了清晰的功能範圍,并通過服務中間件(Service Middleware)完成自身的釋出、對其他服務的訂閱以及與其他服務的通訊工作。

是以,SOA架構解決了傳統架構中因個别功能增減/變更而導緻整個通訊矩陣與路由矩陣都要變更的問題。同時,SOA 架構中每一個服務元件接口都是 “标準可通路”的,服務元件的設計、部署不再依賴于具體特定的硬體平台、作業系統和程式設計語言,同樣的元件/功能可以通過标準化接口在不同的車型上實作複用,實作元件的“軟硬分離”。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

2> 在智能汽車時代,軟體的疊代周期越來越短,獨立于硬體的軟體更新是持續為客戶提供價值的關鍵。由于 SOA架構具有“松耦合”的特性,服務元件和硬體均可以标準化地接入和通路,若要新增某一功能隻需增加相應的服務元件并使其調用不同的硬體功能即可。

是以在 SOA 架構下,開發人員可更多地專注于上層應用的開發,而無需再對底層算法甚至各個 ECU 中的軟體進行重新編譯,這也解決了相同的應用在不同車型及硬體環境下重複開發的痛點,使得汽車軟體架構十分靈活并易于拓展。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

在軟硬體解耦以及汽車軟體架構向 SOA 轉型的背景下,汽車軟體産業鍊正逐漸被重塑:

1> 主機廠開始重視軟體能力的建構,通過建立軟體自研能力、系統架構能力以及 SOA 架構能力以強化軟硬體解耦。目前大部分車企已經完成了軟體自研能力補充或更新,建立起了平台型架構體系,車企的傳統開發模型也正向面向軟體定義汽車的開發模型更新

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

2> 軟體供應商一躍成為 Tier1 供應商。由于汽車軟體開發難度提升,傳統的汽車零部件供應商研發能力難以滿足需求,此時車廠開始繞過傳統一級供應商,直接與原有的二級供應商(晶片、軟體算法等廠商)合作。

在軟體定義汽車時代,軟體重要性不言而喻,整車廠為了掌握主導權并降低高昂的研發成本,往往會選擇直接與具備較強的獨立算法研發能力的軟體供應商合作,是以這些軟體供應商一躍成為了 Tier1 廠商。未來,軟體供應商的盈利模式有望發生轉變,開發基礎平台收許可費、供應功能子產品按 Royalty 收費及定制化的二次開發等方式或成為主流打法。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

主機廠紛紛布局SOA軟體架構的開發,未來幾年内或迎來SOA量産的高峰期。目前大部分OEM主機廠仍處于硬體架構更新的階段,目前僅有特斯拉、大衆完成了定制 OS 核心的開發建構和規模化應用,汽車軟硬體解耦也處于發展初期,現階段主機廠紛紛将底層基礎軟體(系統軟體層)作為發展重點。

從長期來看,SOA 将重構汽車生态,汽車行業很可能複制 PC 和智能手機的軟體分工模式。車企可通過自建或與供應商合作搭建作業系統和 SOA平台,引入大量的算法供應商、生态合作夥伴等形成開發者生态圈,未來車企能夠向使用者提供全生命周期的軟體服務。這一背景下,主機廠紛紛布局 SOA 軟體架構的開發,未來幾年有望成為 SOA 量産的高峰期。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

02

縱觀智能汽車軟硬體架構,最底層的是車輛平台以及外圍硬體(傳感器、V2X、動力及底盤控制等),在其之上的是自動駕駛計算平台,而這也是實作汽車智能化的核心。進一步來看,自動駕駛計算平台可以分為硬體平台和軟體兩大部分,其中軟體層面自下而上分别為:

1> 系統軟體:由硬體抽象層、OS 核心(狹義上的作業系統)和中間件元件構成,是廣義作業系統的核心部分;

2> 功能軟體:主要為自動駕駛的核心共性功能子產品,包括自動駕駛通用架構、AI 和視覺子產品、傳感器子產品等庫元件以及相關中間件。系統軟體與功能軟體構成了廣義上的作業系統。

3> 應用軟體:主要包括場景算法和應用,是智能座艙(HMI、應用軟體等)以及自動駕駛(感覺融合、決策規劃、控制執行等)形成差異化的核心。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

2.1 系統軟體:提供基礎功能和底層環境支援,是作業系統的核心

系統軟體是車載作業系統的基礎,不僅為上層應用以及功能的實作提供了高效、穩定環境的支援,也是各類應用排程底層硬體資源的“橋梁”,在智能汽車整體軟硬體架構中處于核心的位置。通常來說,系統軟體由硬體抽象層、OS 核心(狹義上的作業系統)和中間件元件三部分構成。

2.1.1 硬體抽象層:Hypervisor 與 BSP 搭建軟硬體間的“橋梁”

在汽車電子電氣系統中,不同的 ECU 提供不同的服務,同時對底層作業系統的要求也不同。根據 ISO 26262 标準,汽車儀表系統與娛樂資訊系統屬于不同的安全等級,具有不同的處理優先級。

汽車儀表系統與動力系統密切相關,要求具有高實時性、高可靠性和強安全性,以QNX作業系統為主;而資訊娛樂系統主要為車内人機互動提供控制平台,追求多樣化的應用與服務,主要以Linux 和 Android 為主。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

在 EE 架構趨于集中化後,虛拟化(Hypervisor)技術的出現讓“多系統”成為現實。在電子電氣系統架構從分布式向域集中式演進的大背景下,各種功能子產品都集中到少數幾個計算能力強大的域控制器中。此時,不同安全等級的應用需要共用相同的計算平台,傳統的實體安全隔離被打破。

虛拟化(Hypervisor)技術可以模拟出一個具有完整硬體系統功能、運作在一個完全隔離環境中的計算機系統,此時供應商不再需要設計多個硬體來實作不同的功能需求,而隻需要在車載主晶片上進行虛拟化的軟體配置,形成多個虛拟機,在每個虛拟機上運作相應的軟體即可滿足需求。

Hypervisor 提供了在同一硬體平台上承載異構作業系統的靈活性,同時實作了良好的高可靠性和故障控制機制,以保證關鍵任務、硬實時應用程式和一般用途、不受信任的應用程式之間的安全隔離,實作了車載計算單元整合與算力共享。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

在車載虛拟化領域,主流的 Hypervisor 技術提供商包括 BlackBerry QNX Hypervisor(閉源)及 Intel 與 Linux 基金會主導的 ACRN(開源)。目前,隻有 QNX Hypervisor 應用到量産車型,它也是目前市場上唯一被認可功能安全等級達到 ASIL D 級的虛拟化作業系統。

國内廠商也紛紛加入兩大主流虛拟機技術生态:2017 年,中科創達與誠邁科技入選黑莓 VAI 計劃(該計劃将建立一個基于黑莓 QNX 嵌入式技術和 Certicom 安全技術的全球專家網絡,旨在拓展嵌入式軟體市場),公司可以基于黑莓的嵌入式技術開發內建服務、安全關鍵型解決方案;東軟集團在 ACRN 項目早期就成為了其會員;2019 年,ACRN 與潤和軟體建立戰略合作夥伴關系。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進
【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

BSP 可支援作業系統更好地運作于硬體主機闆。BSP(Board Support Package)指闆級支援包。對于一般的嵌入式系統,硬體部分需要嵌入式硬體工程師設計硬體電路,而新出廠的電路闆需要BSP 來保證其能穩定工作,在此基礎之上才能進行下一步的軟體開發。BSP 是介于主機闆硬體和作業系統之間的系統軟體之一,主要目的是為了支援作業系統,使之能夠更好的運作于硬體主機闆。

BSP 是相對于作業系統而言的,不同的作業系統對應于不同定義形式的 BSP。例如 VxWorks 的BSP 和 Linux 的 BSP 相對于某一 CPU 來說盡管實作的功能一樣,可是寫法和接口定義是完全不同的,是以寫 BSP 一定要按照該系統 BSP 的定義形式來寫,這樣才能與上層 OS 保持正确的接口。由于 BSP 處于在硬體和作業系統、上層應用程式之間,是以 BSP 程式員需要對硬體、軟體和作業系統都要有一定的了解。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

2.1.2 OS 核心:QNX 、Linux、VxWorks 為主流

汽車作業系統可分為狹義 OS 和廣義 OS,OS 核心屬于狹義 OS。如前文所述,汽車的自動駕駛計算平台分為四個層級,從下到上分别為硬體層、系統軟體層、功能軟體層、應用軟體層。

廣義OS 指系統軟體層(包括硬體抽象層、OS 核心、中間件元件)與功能軟體組成的軟體集合,而狹義 OS 僅單指 OS 核心。具體來說,OS 核心又稱為“底層 OS”,提供作業系統最基本的功能,負責管理系統的程序、記憶體、裝置驅動程式、檔案和網絡系統,決定着系統的性能和穩定性,是系統軟體層的核心。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

目前,狹義 OS 的核心呈現 QNX、Linux 和 VxWorks 三足鼎立的局勢。自動駕駛 OS 核心的格局較為穩定,主要玩家為 QNX(Blackberry)、Linux(開源基金會)、VxWorks(風河)。

因打造全新 OS 需要花費太大的人力、物力,目前基本沒有企業會開發全新的 OS 核心。目前,無論是 Waymo、百度、特斯拉、Mobileye 還是一些自動駕駛初創公司、車企,所謂的自研自動駕駛OS,都是指在上述現成核心的基礎之上自研中間件和應用軟體。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

QNX、Linux 和 VxWorks 三大核心有以下差別:

1> 實時性:以是否對需要執行的任務劃分優先級為标準,OS 核心可分為分時 OS(Time-Sharing OS)和實時 OS(Real-time OS)兩種。前者對各個使用者/作業都是完全公平的,不區分任務的緊急性;而後者指在高優先級的緊急任務需要執行時,能夠在某個嚴格的時間限制内搶占式切換到該任務上。

實時 OS 還可以分為硬實時和軟實時兩類:硬實時系統有一個剛性的、不可改變的時間限制,它不允許任何超出時限的錯誤;而軟實時系統的時限是一個柔性靈活的,它可以容忍偶然的逾時錯誤。

QNX 和 VxWorks 均屬于實時 OS,且均屬于硬實時 OS。最初 Linux 屬于分時 OS,但 Linux 對實時性改進的工作從未停止過。經過優化後, Linux核心也分為搶占式核心和非搶占式核心,其中,搶占式核心的實時性足以滿足自動駕駛的需求。是以,實時性大幅改善的 RT Linux 實際上已經成為硬實時作業系統。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

2> 開放性:QNX是一個半封閉系統,而 Linux 和 VxWorks 均是開源系統。所謂“半封閉”,即QNX 的核心,客戶是不能改的,但客戶可自己編寫中間件和應用軟體;所謂開源,即所有核心源代碼都向客戶開放,客戶可根據自己的實際需求裁剪,可配置性很高。

與 QNX 相比, Linux 更大的優勢在于開源,在各種 CPU 架構上都可以運作,可适配更多的應用場景,并有更為豐富的軟體庫可供選擇,是以具有很強的定制開發靈活度。VxWorks 也是開源的,VxWorks RTOS 由 400 多個相對獨立、短小精悍的目标子產品組成,使用者可獲所有源代碼并根據需要對 OS 核心在源代碼層面進行裁剪和配置。

3> 核心架構:QNX 與 VxWorks 是微核心,即核心中隻有最基本的排程、記憶體管理,驅動、檔案系統等都是使用者态的守護程序去實作的。微核心的優點是穩定、漏洞少,驅動等的錯誤隻會導緻相應程序發生 Bug,不會導緻整個系統都崩潰,同時具有靈活性高、易擴充的特點,可以便捷地在作業系統中增減功能;缺點是頻繁的系統調用與資訊傳遞使 OS 運作效率較低。

Linux是宏核心,即除了最基本的程序、線程管理、記憶體管理外,檔案系統,驅動,網絡協定等等都在核心裡面,其優點是效率高,可以充分發揮硬體的性能;缺點是核心結構複雜,穩定性較差,開發程序中的 Bug 可能會導緻整個系統崩潰,是以基于 Linux 開發的門檻很高。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

4> 是否付費:QNX 憑借其安全性、穩定性和實時性占據汽車嵌入式作業系統市占率第一的位置,但 QNX 是需要商業收費的。雖然 VxWorks 和 Linux 同為開源系統,但差別在于 Linux 是免費的,而 VxWorks 是收費的。

QNX 與 VxWorks 均需收取高昂的授權費,開發定制成本也很高,這也會在一定程度上阻礙其市場占有率的增長;相較而言,Linux的免費也會對車企有很強的吸引力。

綜上,車企在選擇 OS 核心時,主要考慮開放性、可擴充性、易用性、安全性、可靠性及成本等因素,再結合自己的需求及能力體系來做權衡。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

2.1.3 中間件:AUTOSAR 标準應用最為廣泛

中間件位于硬體及作業系統之上,應用軟體之下,是汽車軟體架構中重要的基礎軟體。中間件(middleware)是基礎軟體的一大類,在汽車軟體架構中位于硬體、作業系統之上,應用軟體的下層,總的作用是為處于自己上層的應用軟體提供運作與開發的環境,幫助使用者靈活、高效地開發和內建複雜的應用軟體,并能在不同的技術之間實作資源共享并管理計算資源和網絡通信。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

軟體定義汽車時代下,中間件的作用愈發重要。随着 EE 架構逐漸趨于集中化,汽車軟體系統出現了多種作業系統并存的局面,這也導緻系統的複雜性和開發成本的劇增。為了提高軟體的管理性、移植性、裁剪性和品質,需要定義一套架構(Architecture)、方法學(Methodology)和應用接口(Application Interface),進而實作标準的接口、高品質的無縫內建、高效的開發以及通過新的模型來管理複雜的系統。

中間件的核心思想在于“統一标準、分散實作、集中配置”:統一标準才能給各個廠商提供一個通用的開放的平台;分散實作則要求軟體系統階層化、子產品化,并且降低應用與平台之間的耦合度;由于不同子產品來自不同的廠商,它們之間存在複雜的互相聯系,要想将其整合成一個完善的系統,必須要求将所有子產品的配置資訊以統一的格式集中管理起來,集中配置生成系統。

有了汽車軟體中間件後,所有的軟體和應用都具備了标準化接口,同時硬體功能也被抽象成服務,可以随時被上層應用調用;軟體開發可以跨配置、跨車型、跨平台、跨硬體适應;軟體開發者可以更多地聚焦軟體功能的差異化;軟體認證可以有标準可依。是以,可以說中間件在汽車軟硬體解耦的趨勢中發揮了關鍵的作用。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

在所有中間件方案中,AUTOSAR 是目前應用範圍最廣的車載電子系統标準規範。AUTOSAR (Automotive Open System Architecture)指汽車開放架構,是由全球汽車制造商、零部件供應商以及各種研究、服務機構共同參與制定的一種汽車電子系統的合作開發架構,并建立了一個開放的汽車控制器(ECU)标準軟體架構,規範了車載作業系統标準與 API 接口。

2003 年 7 月,寶馬、博世、大陸、戴姆勒、福特、通用、PSA、豐田、大衆等 9 家汽車行業巨頭發起了AUTOSAR聯盟的建立,這9家公司後來也成為 AUTOSAR聯盟的核心成員。截至2021年 7月, AUTOSAR 聯盟已經擁有了 300 多家合作夥伴,包括全球各大主流整車廠、一級供應商、标準軟體供應商、開發工具與服務提供商、半導體供應商、高校以及研究機構等,其中也包括了華為、百度、長城、東風、一汽、上汽、吉利、蔚來、拜騰、甯德時代等國内廠商。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

AUTOSAR 旨在通過提升 OEM 以及供應商之間軟體子產品的可複用性和可互換性來改進對複雜汽車電子電氣架構的管理。汽車行業中有衆多的整車廠和供應商,每家 OEM 會有不同的供應商以及車型,每個供應商也不止向一家 OEM 供貨,此時若盡可能地讓相同産品在不同車型可重複利用或是讓不同供應商的産品互相相容,這樣就能大幅減少開發成本。

為此,AUTOSAR 聯盟建立了獨立于硬體的分層軟體架構;為實施應用提供方法論,包括制定無縫的軟體架構堆疊流程并将應用軟體整合至 ECU;制定了各種車輛應用接口規範,作為應用軟體整合标準,以便軟體在不同汽車平台複用。有了标準化應用軟體和底層軟體之間的接口,開發者可以專注于功能的開發,而無需顧慮目标硬體平台。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

目前,AUTOSAR 擁有 Classic Platform 和 Adaptive Platform 兩大平台,分别對應傳統控制類車輛電子系統與對應自動駕駛的高性能類車載電子系統:

1> Classic Platform(CP):Classic Platform 是 AUTOSAR 針對傳統車輛控制嵌入式系統的解決方案,具有嚴格的實時性和安全性限制。從架構來看,Classic Platform 自下而上可大緻分為微控制器、基礎軟體層、運作環境層和應用軟體層。

Classic 平台軟體架構實作了汽車軟體的階層化與子產品化,将硬體依賴和非硬體依賴的軟體進行了封裝。同時,如果使用工具鍊進行開發,基礎軟體可以通過配置參數即可實作功能剪裁、算法邏輯,便于基礎軟體的開發。此外,接口的标準化便于基礎軟體與硬體抽象層軟體對接,縮短開發周期的同時也為OEM提供了更多的選擇空間。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

2> Adaptive Platform(AP):Adaptive Platform 是 AUTOSAR 面向未來自動駕駛、車聯網等複雜場景而提出的一種新型汽車電子系統軟體架構标準。Adaptive平台修改了大量Classic平台标準的内容,采用了基于 POSIX 标準的作業系統,以面向對象的思想進行開發,并且可使用所有标準的 POSIX API,主要目的是為滿足目前汽車自動駕駛、電氣化和互聯互通等趨勢的需求。

Adaptive Platform 自下而上可分為三層:(1)硬體層:AP 可将運作的硬體視作Machine,這也意味着硬體可以通過各種管理程式相關技術進行虛拟化,并可實作一緻的平台視圖;(2)實時運作環境層(ARA):由功能叢集提供的一系列應用接口組成,分為 API和 service 兩種接口類型;(3)應用層:運作在 AP 上的一系列應用。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

Adaptive Platform 相較 Classic Platform 更加适應于目前汽車架構向 SOA 轉型的大趨勢。如前文所述,目前汽車架構中同一硬體平台可能內建了多種系統,例如車載資訊娛樂相關的 ECU 通常使用 Linux、QNX 或其他通用作業系統。

盡管 Classic Platform 支援 AUTOSAR OS(OSEK OS),而 Adaptive Platform 支援虛拟化技術以及多系統并存的架構,隻要是 POSIX OS 都可使用,包括那些達到 ASIL-D 的作業系統,相容性廣,可移植性高,是以 AP 相較 CP 更有優勢。

此外,CP 主要支援面向信号的架構(Signal-Oriented Architecture),以基于信号的靜态配置的通信方式(CAN、LIN)為主,開發後功能更新較為困難;AP 主要支援面向服務的軟體架構(SOA),以基于服務的 SOA 動态通信方式(SOME/IP)為主,硬體資源間的連接配接關系虛拟化,不局限于通信線束的連接配接關系,軟體也可實作靈活的線上更新。是以,AP 更專注于提供高性能計算和通訊機制,提供了靈活的軟體配置方式,更加适用于目前智能汽車領域高速發展的時代。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

面向全新 E/E 架構的智能汽車,AUTOSAR 和中間件 OS 将是衆多 Tier1 的發力重點。目前全球知名的 AUTOSAR 解決方案廠商包括 ETAS(博世)、EB(Continental)、Mentor Graphics (Siemens)、Wind River(TPG Capital)、Vector、KPIT(美印合資)等。在國内,Classic AUTOSAR 标準下的開發工具鍊及基礎軟體由海外供應商占據主導地位,包括 EB、ETAS、 Vector 等,國内廠商主要包括東軟睿馳、華為、經緯恒潤等;

國内 Adaptive AUTOSAR 仍處于起步階段,大陸 EB 與大衆合作将 AP AUTOSAR 和 SOA 平台應用于大衆 MEB 平台 ID 系列純電動車型上。此前國内汽車基礎軟體架構标準及産業生态整體較為落後,在汽車智能化轉型更新的趨勢下,國内廠商紛紛将 AP AUTOSAR 作為發力重點,推出相應的中間件及其工具鍊産品,搶占市場先機。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

2.2 功能軟體:提供自動駕駛的核心共性子產品,支撐自動駕駛技術的實作

汽車軟體架構中,功能軟體層主要包含自動駕駛的核心共性功能子產品以及相關中間件。根據 SOA架構設計理念,通過提取自動駕駛核心共性需求,形成了自動駕駛共性功能子產品,主要包括自動駕駛通用架構子產品、網聯子產品、雲控子產品、AI 與視覺子產品、傳感器子產品等。

利用這些共性功能子產品,開發者可更高效地進行自動駕駛業務層面的研發,縮短了智能駕駛系統的開發周期;主機廠基于自身政策,在設計和開發功能軟體時可以選擇不同的功能子產品和算法元件,實作拼插式功能組合,靈活建構智能駕駛系統級解決方案,這也降低了系統內建成本。

功能軟體層中,中間件同樣可對軟硬體資源進行管理、配置設定和排程,例如對傳感器、計算平台等資源進行抽象,對算法、子系統、功能采取子產品化的管理,并通過提供的統一接口。功能軟體與系統軟體共同構成了廣義的自動駕駛作業系統,支撐着自動駕駛技術實作。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

1> 自動駕駛通用架構子產品:自動駕駛通用架構子產品是功能軟體的核心和驅動部分。L3 及以上等級自動駕駛系統具備通用、共性的架構子產品,如感覺、規劃、控制等及其子子產品。一方面,自動駕駛會産生安全和産品化的共性需求,通過設計和實作通用架構子產品來滿足這些共性需求,是保障自動駕駛系統實時、安全、可擴充和可定制的基礎;

另一方面,重點算法(特别是人工智能算法)仍在不斷演進,如基于 CNN架構的深度學習感覺算法、基于高精度地圖等多源資訊融合定位算法、基于通用 AI 和規劃的決策規劃算法和基于車輛動力學模型的控制算法等。

自動駕駛通用架構子產品定義了核心、共性的自動駕駛功能和資料流,并包含共性子產品的實作;提供對外接口 API 和服務,以接入非共性或演進算法、HMI 等;通用架構子產品也會調用自動駕駛作業系統内的雲控、網聯、資訊安全等功能軟體子產品,或使用這些子產品提供的服務。通用架構子產品的設計和實作,可以充分利用市場不斷成熟的、不同領域的算法子子產品,促進産品高質高效的快速疊代。

2> 網聯子產品:網聯子產品是自動駕駛作業系統功能軟體中實作網聯通信、處理網聯資料的功能子子產品。除滿足正常網聯服務場景要求外,該子子產品通過完善通用架構子產品設計實作網聯協同感覺、網聯協同規劃、網聯協同控制等網聯自動駕駛功能。

網聯資料通過 V2X(車用無線通信技術)獲得,包括路測資料、攝像頭、智能信号燈、道路交通提示預警等資訊及其他車輛資訊等,與單車傳感器系統的多種探測手段相結合和融合處理,能夠有效實作單車感覺範圍到數百米,車輛間防碰撞,根據預警直接控制車輛啟停等重要感覺、規劃和控制功能。

單車智能化與 V2X 網聯功能的有機結合增強自動駕駛系統整體的感覺、決策和控制能力,降低自動駕駛成本,最終實作無人駕駛。該子子產品是智能網聯汽車的典型特征,也是自動駕駛作業系統的核心功能之一。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

3> 雲控子產品:雲控子產品是與雲控基礎平台互動的功能子子產品。雲控基礎平台為智能網聯汽車及其使用者、管理及服務機構等提供車輛運作、基礎設施、交通環境等動态基礎資料。雲控基礎平台具有高性能資訊共享、高實時性雲計算、多行業應用大資料分析等基礎服務機制。

雲控子產品通過自動駕駛通用架構子產品的支援,提供雲控基礎平台所需的資料支撐,同時通過高速通信與中心雲/邊緣雲進行雲端感覺、規劃和控制等資料的實時同步,實作雲-端分工協同,如基于廣泛多車感覺的雲端感覺、雲端多車感覺融合和雲端最終裁決等。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

4> AI 與視覺子產品:功能軟體需要支援深度學習嵌入式推理架構,便于成熟算法移植和适配。自動駕駛是深度學習算法的重要應用場景,尤其在視覺、雷射雷達及決策規劃方面,算法企業、科研機構進行了長期且富有成效的研究和産品化工作。

自動駕駛作業系統功能軟體中需要支援深度學習嵌入式推理架構(如 TensorRT),并相容 TensorFlow 和 Caffe 等主流訓練開發架構的深度學習模型,便于已有成熟算法和開發生态的移植和适配。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

5> 傳感器子產品:傳感器子產品規範和子產品化各類自動駕駛傳感器,為傳感資料融合提

供基礎。L3及以上等級自動駕駛技術方案多依賴雷射雷達、攝像頭、毫米波雷達等不同類型、不同安裝位置的傳感器,這些傳感器硬體接口、資料格式、時空比例、标定方法不同。針對傳感器的多樣性、差異性和共性需求,自動駕駛作業系統功能軟體中預置傳感器子產品來規範和子產品化自動駕駛各類傳感器,為異構傳感器資訊融合處理提供基礎。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

功能軟體開發涉及多方合作,Tier1 與軟體算法廠商可為主機廠提供相應的優勢解決方案。自動駕駛功能軟體平台設計規範将解耦的功能軟體标準化和平台化,明确了各功能子產品之間的接口定義。

基于标準規範和開放接口,功能軟體元件的生産就可變成類似于汽車傳統零部件的生産方式, Tier1、軟體算法廠商以及主機廠等參與方可憑借自身優勢提供解決方案,例如在AI和視覺領域有優勢的算法廠商可以專注于功能軟體中 AI 和視覺子產品的開發,傳感器廠商(Tier1)可與主機廠共同對功能軟體中傳感器子產品進行開發。

是以,自動駕駛功能軟體平台設計規範的制定建立了有序、高效、靈活的汽車軟體供應鍊體系,實作了更有效的分工與合作,為自動駕駛解決方案供應商提供更多的應用需求,也為主機廠提供了更靈活的選擇,極大地促進了自動駕駛的落地以及産業化發展。

2.3 應用軟體:智能汽車差異化的核心

應用軟體層主要包括智能汽車場景算法、座艙功能、資料地圖等内容,是智能座艙(HMI、應用等)以及自動駕駛(感覺融合、決策規劃、控制執行等)形成差異化的核心,位于汽車軟體架構最上層。

過去的汽車供應鍊一般是由實力強勁的 Tier1 提供軟硬體一體化的“黑盒”産品,軟硬體解耦難度非常高。在軟體定義汽車時代,汽車電子零部件也将像過去的傳統機械、車身零部件一樣加速“白标化”,硬體差異化越來越小,利潤也愈發透明,“硬體成本價”售車成為可能性,軟體則将成為汽車的靈魂和 OEM 的新的利潤中心。車輛的差異化和盈利能力将向技術和相關軟體堆棧轉移,其中主要包括智能座艙、自動駕駛、資料地圖/車路協同等方面。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

智能座艙相較自動駕駛技術實作難度更低,有助于迅速提升産品差異化競争力。由于自動駕駛軟體及算法開發難度及測試難度較大,同時目前政策法規方向尚不完善,是以自動駕駛的整體的市場成熟度仍然不高。

目前在整車智能化轉型時代,智能座艙能內建更多的資訊和功能,給使用者帶來更直覺、更個性化的體驗,進而成為整車智能化的先行者。根據 IHS Markit 調查,雖然座艙智能科技配置需求的相關消費習慣尚在培育階段,但仍有超過 60%的使用者認可座艙配置的價值并有望實作需求的轉化,反映出使用者層面的座艙智能配置需求有很大的上升空間。未來,大陸智能座艙新車滲透率将快速提升,到 2025 年預計可以超過 75%,高于全球市場裝配水準。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

自動駕駛由低速向高速演進需要長時間的訓練和算法積累,未來空間巨大。目前,L3 及以上級别的自動駕駛有望在封閉、半封閉和低速場景下率先應用,自主泊車作為自動駕駛的低速複雜場景,将為自動駕駛技術演進提供低速域的資料訓練和積累。

盡管自動駕駛高速場景的商業化落地還有一定距離,但特斯拉、谷歌、百度等廠商依舊把目光放在了進階别的自動駕駛上,為的就是在行業拐點來臨之前占得先機。根據 IHS 的預測,自動駕駛汽車将在 2025 年前後開始一輪爆發式增長。

到 2035年,道路行駛車輛将有一半實作自動駕駛,屆時自動駕駛整車及相關裝置、應用的收入規模總計将超過五千億美元。根據 CIC 預測,預計到 2025 年大陸自動駕駛市場空間接近 4000億元,2020-2025 年 CAGR 接近 107%,遠快于全球市場增速。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

進階别的自動駕駛的實作需要高精度定位與地圖的支援。車路協同是目前業界普遍認為實作智能駕駛的關鍵路徑之一,智能汽車将逐漸從單車智能向車路協同邁進。與智能攝像頭、毫米波雷達、雷射雷達等類似,C-V2X 是通過“車、路、雲”的協同以獲得其他車輛、行人運動狀态的另一種資訊互動手段。

由于高速自動駕駛需要對更遠的行人、車輛的運動狀态做出實時的判斷,加之可能存在天氣、障礙物等因素的影響,僅靠單輛車的傳感器難以對路況做出實時判斷,此時就離不開路端的資訊來為智能車的駕駛決策來做補充。

車聯網将定位技術、傳感器技術、通信技術、網際網路技術等先進技術進行有機結合,而進階别的自動駕駛更是需要車聯網的支援,其中定位技術(包括高精地圖)是車聯網關鍵之一,是車輛在高速狀态下實作安全行駛的重要保障。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

在 SOA 和分層解耦趨勢下,OEM、傳統 Tier1 和軟體供應商分别采取了不同的應對政策,以融入應用軟體的開發生态:

(1)主機廠向軟體轉型主要有三種路徑模式:

1> 成立軟體子公司:實作全棧技術自研布局,OEM 逐漸掌握軟體、算法、晶片等全技術棧的自主研發能力,一定程度上繞過傳統 Tier1,與過去二級軟體供應商共同開發子系統,如上汽零束軟體、長安汽車軟體科技公司等;

2> 成立軟體研發部門:通過合作、投資等方案與核心技術廠商直接合作,最大程度實作自主可控,主要在某一項或多項具備戰略性差異的領域建立 in-house 的研發能力,部分共性軟體外包。例如蔚來、小鵬等初創企業,由于體量較小更加靈活,無須面面俱到,專注于智能座艙、自動駕駛核心應用軟體的開發,組建了規模龐大的自研團隊。

3> 與軟體企業戰略合作:OEM 一邊擴充内部研發隊伍,一邊與軟體企業建立戰略聯盟,主機廠推進軟體生态建設,但執行由軟體 Tier1 來實作。例如廣汽研究院與東軟睿馳、中科創達等組建聯合創新中心。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

(2) 傳統 Tier1 需要打造軟硬一體的能力。對于傳統 Tier1 來說,部分系統功能開發權被主機廠收回是大勢所趨,是以傳統Tier1迫切需要轉型尋求新的出路,避免淪為硬體代工商。

目前來看,軟硬體全棧能力的打造,是搶占下一個市場佔有率制高點的關鍵所在,這一點,傳統 Tier1 巨頭深谙其道。更多的 Tier1 緻力于打造“硬體+底層軟體+中間件+應用軟體算法+系統內建”的全棧技術能力,典型代表如博世、華為、德賽西威等,既能為客戶提供硬體、也能提供軟體,同時也提供軟硬一體化的解決方案。

(3) 軟體供應商需要不斷豐富産品矩陣,并逐漸提升硬體能力。随着 OEM 主機廠自主權和軟體自研能力的不斷加強,OEM 主機廠開始尋求與軟體供應商的直接合作。比如 OEM 廠商将首先尋求将座艙 HMI 互動系統功能收回,UI/UX 設計工具、語音識别子產品、音效子產品、人臉識别子產品等應用軟體則直接向軟體供應商購買軟體授權,進而繞過了傳統 Tier1,實作自主開發。

對于軟體供應商來說,能提供越多的軟體 IP 産品組合,就可能擷取更高的單車價值。同時,軟體供應商也正尋求進入傳統 Tier1把持的硬體設計、制造環節,比如域控制器、TBOX等,以提供多樣化的解決方案。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

03

相關公司介紹

3.1 中科創達:車載作業系統頭部廠商,由座艙域到駕駛域打開成長空間

基于移動終端領域積累多年的嵌入式作業系統二次開發經驗,公司切入智能網聯汽車領域。自2013 年,公司基于積累多年的作業系統優化技術、優秀的 3D 引擎、機器視覺、以及語音和音頻技術,為汽車提供從作業系統開發、核心技術授權到應用定制的包括汽車娛樂系統、智能儀表盤、內建駕駛艙、ADAS 和音頻産品在内的整體智能駕駛艙軟體解決方案和服務,為駕乘者提供豐富、先進的智能駕駛體驗。目前,全球采用公司智能駕駛艙産品和解決方案的公司超過 100 家。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

基于 SOA架構,公司智能座艙産品已經發展為跨系統融合的智能駕駛艙 4.5 解決方案,為客戶提供從底層系統軟體、中間件再到上層應用的全棧式解決方案。從公司 TurboX Auto 4.5 智能座艙平台架構來看:系統軟體方面,公司具備 BSP 開發能力,解決方案支援多個主流晶片平台(高通、瑞薩、NXP 等),基于 Hypervisor 技術平台可支援 QNX、Linux、Android 等 OS 核心,并可對OS 性能進行優化;

功能軟體方面,平台具備提供音頻及圖像處理、傳感器融合、車内網絡等子產品的能力;上層應用方面,基于Kanzi,平台提供資訊娛樂系統、智能儀表、ADAS和影音內建等産品,提供5G、雲服務并支援 FOTA更新;平台提供的中間件方案可實作軟硬體接口的标準化,

3.2 光庭資訊:國内領先的汽車軟體及解決方案提供商

公司具備面向智能網聯汽車的全域全棧軟體開發能力。公司成立于 2011 年,自成立以來一直專注于汽車電子軟體先端技術的研發與創新。伴随着汽車電子電氣架構的演變以及“軟體定義汽車” 理念的興起,公司緊密圍繞汽車智能化、網聯化、電動化的發展趨勢,緻力于建構以車載作業系統為核心的基礎軟體平台,以軟體驅動汽車數字化轉型,為使用者提供全新的駕乘體驗及服務。

目前,公司産品和技術服務已涵蓋了構成智能網聯汽車核心的智能座艙、智能電控和智能駕駛三大領域,并建立了智能網聯汽車測試服務體系與移動地圖資料服務平台兩大支撐體系。目前,公司全域全棧的産品體系已具備為新一代智能網聯汽車提供軟體開發與技術服務的能力。

【關注】軟體定義汽車時代下,智能汽車軟體架構逐漸向 SOA 演進

來源:東方證券研究所

繼續閱讀