- 智能汽車軟件功能安全
- 吳丹丹
- 7553字
- 2025-02-21 17:07:26
1.2 智能汽車技術發展路線
智能汽車的發展趨勢需要明確地體現在技術發展路線上,以將所有不確定性轉化為可落地實施的確定性。新技術的應用可能會帶來較大的系統性和架構性變革,同時可能引入新的波動和風險。然而,如果過分依賴舊有技術路徑而不進行變革與創新,就會失去技術演進的動力。依據技術成熟度曲線的客觀規律,每項新技術從誕生到成熟都必須經歷從高峰到低谷再到崛起的過程,才能最終到達預期的成熟高峰。深刻理解這一客觀規律,有助于更加準確地把握智能汽車技術發展的路線。這條路線本身是清晰的,雖然過程可能曲折,但最終目標是明確的。
技術的核心在于架構,架構不僅決定了技術的方向,而且作為技術的載體,提供了技術實現的基礎框架支撐。整車的電子電氣架構負責各項功能的運算處理和動力分配,通過整合各類軟硬件單元、線束拓撲和電子電氣分配系統,成為實現信息交互和復雜運算的中樞。在智能汽車中,功能的多樣化主要通過軟件來動態實現,因此軟件在技術中占據了重要的位置。本節將從智能汽車的電子電氣架構和軟件兩個方面進行介紹。只有清晰地認識技術發展路線,順應技術趨勢,并進行提前的規劃布局,才能在智能汽車領域把握住機遇。
1.2.1 智能汽車電子電氣架構發展路線
智能汽車的電子電氣架構發展路線可以劃分為4個階段:從傳統的整車分布式電子電氣架構開始,逐漸轉變為基于域控制器的集中式電子電氣架構,接著發展為跨域集中式電子電氣架構,最終演變為中央集中式電子電氣架構。這一發展過程體現了智能汽車電子電氣架構從分散管理向集中管理演變的趨勢。
1.傳統的整車分布式電子電氣架構
在傳統的整車分布式電子電氣架構中,整車的功能被細分為多個子系統,如動力系統、底盤系統、車身系統、娛樂信息系統等。每個子系統進一步劃分為不同的功能模塊,每個功能模塊都由一個獨立的電子控制單元(ECU)實現。這些不同的ECU主要通過CAN、CANFD、LIN等傳統車載網絡進行連接和通信。不同功能的子系統之間通過中央網關進行通信。圖1-2為傳統的整車分布式電子電氣架構示意圖。

圖1-2 傳統的整車分布式電子電氣架構示意圖
在這種分布式電子電氣架構模式下,每個ECU由不同的供應商提供,并進行軟硬一體化設計以實現所需功能。因此,整車制造商高度依賴這些供應商。從整車的角度來看,通信主要依賴低速總線網絡,這限制了高帶寬信息的傳輸,導致通信帶寬存在瓶頸。同時,軟硬件之間深度耦合,不同的硬件與特定的軟件綁定,各個硬件相互獨立,導致軟件不具備通用性,整個系統的兼容性和擴展性較差。此外,多個硬件的共同作用可能會導致功能上的冗余和重疊,從而造成算力和成本的浪費。
2.基于域控制器的集中式電子電氣架構
隨著智能汽車的硬件趨于同質化,軟件定義、數據驅動和車路云協同成為主流趨勢,傳統的整車分布式電子電氣架構已不足以靈活應對這些新需求。為適應智能汽車時代,電子電氣架構需不斷創新,其核心在于實現高度集中化、硬件標準化及軟硬件解耦。
首先,傳統的分布式電子電氣架構正逐漸向基于域控制器的集中式電子電氣架構演變。集中式電子電氣架構按照整車功能將系統分為不同的域,如動力域、底盤域、車身域、座艙域、智能駕駛域等。每個域配備一個計算能力強大的域控制器,集成并整合了多個傳統ECU的功能,負責數據的集中處理和運算。為提高通信效率,這些域控制器以以太網作為主干網絡進行連接。同時,該架構還考慮了與傳統分布式電子電氣架構中各種車載網絡的兼容性。
如圖1-3所示,基于域控制器的集中式電子電氣架構展現了不同功能域及其關聯的域控制器。在這種架構中,各個功能特性不再與ECU一一對應,而是通過減少ECU的數量來實現功能的集中化管理。軟件逐漸從與硬件一體化的黑盒中分離出來,其作用和價值變得更加明顯。具有更強大計算能力的域控制器開始處理更復雜的功能,為智能汽車技術的實現奠定了堅實的基礎。

圖1-3 基于域控制器的集中式電子電氣架構示意圖
3.跨域集中式電子電氣架構
在基于域控制器的集中式電子電氣架構中,每個域控制器只負責一個功能域的控制。隨著域控制器的計算能力和性能顯著增強,不同功能域開始進一步融合。一些域控制器現在可以對兩個或更多功能域進行集中控制,形成跨域集中式電子電氣架構,進而提高了功能集中化的程度。目前,一種主流的跨域融合方式是將動力域、底盤域和車身域合并成一個綜合的車輛控制域(簡稱車輛域)。該控制域與智能駕駛域、座艙域共同構成3個主要的控制系統。圖1-4展示了跨域集中式電子電氣架構示意圖。
在這個架構中,功能域的深度融合使得車輛域承擔整車的綜合控制任務,智能駕駛域專注于自動駕駛功能的控制與實現,座艙域則專注于座艙環境和人機交互功能的控制與實現。隨著功能集成和復雜性的增加,軟件角色得到進一步增強。因此,整車制造商與供應商之間的合作策略變得更加多樣化。一些制造商可能繼續采用傳統的供應鏈合作模式,尤其是當它們的軟件能力有限時;一些制造商可能尋求與供應商建立軟件合作開發的關系,共同推動技術進步;還有一些制造商開始自主研發軟件,以掌握更多核心技術和獲得競爭優勢。

圖1-4 跨域集中式電子電氣架構示意圖
4.中央集中式電子電氣架構
隨著智能汽車技術需求的持續提升,電子電氣架構正步入一個新階段。功能域將逐漸被通用的中央計算平臺取代,形成中央集中式電子電氣架構。在這種新興架構中,一個通用計算平臺將承擔車輛所有功能的控制邏輯,這意味著電子電氣系統不再按功能域分布,而是所有計算處理、通信和存儲功能都集中于一個強大的中央計算平臺。這個中央計算平臺可視為一個異構的數據中心服務器集群,將系統功能集成度提升至全新水平。此外,為了遵循資源就近原則,簡化通信和連接,中央集中式電子電氣架構還考慮根據物理位置來劃分區域,并在每個區域設立通用的區域計算平臺,負責局部的計算和處理任務。圖1-5展示了中央集中式電子電氣架構示意圖。

圖1-5 中央集中式電子電氣架構示意圖
在中央集中式電子電氣架構中,以太網作為整車通信的主干網絡,但各個區域內仍可使用其他傳統車載網絡。這一階段的架構明確強調了軟件在汽車系統中的核心地位。整個行業開始認識到軟件的重要性,并且整車制造商試圖主導原本由供應商提供的應用策略層軟件,同時逐步建立專業的軟件團隊。隨著軟硬件架構的分層,智能汽車電子產業鏈的分工也在進一步重塑。整車制造商不再僅是硬件的集成者,而是開始在軟件和服務領域擴展,以獲得更多的核心技術和更強的市場競爭力。這種轉變預示著智能汽車的發展將更加依賴軟件的創新和整合能力。
隨著智能汽車技術,尤其是車路云協同方面的不斷進步,未來的車輛將不再僅僅依賴車載的通用計算平臺。相反,中央通用計算平臺將向路側設施和云端資源擴展,與車載計算平臺一起完成處理和運算任務,從而形成一個綜合的車路云協同計算架構。這種架構模式提出了更高的要求,包括軟硬件的解耦、硬件及接口的標準化、強大的軟件功能,以及高效的數據傳輸和處理能力。
通用計算平臺的核心特點在于其通用性,主要負責集中式的計算、處理、通信和調度任務,而不限定于任何特定的車輛功能域。這種平臺并不依賴特定的應用功能,而是基于基礎硬件平臺和基礎軟件。通過標準化的設計,通用計算平臺支持多種標準接口類型,能夠適應不同的應用環境,實現快速適配。軟硬件解耦使得該平臺可以靈活部署在車載系統的中央、區域甚至路側和云端。通過高層的軟件設計,通用計算平臺能夠滿足智能汽車多樣化的應用需求。
從整車電子電氣架構的不斷演進中我們可以看出,技術發展路線在持續地突破和進化,呈現出計算集中化、平臺標準化和軟硬件解耦化的趨勢。電子電氣架構正從以功能信號為核心的導向模式轉變為以服務為核心的導向模式,實現了功能的定制化。這種變革使得軟件的價值成為智能汽車未來競爭的關鍵點。
整車制造商開始追求全棧技術布局和核心軟件技術的突破,智能汽車生態圈的合作伙伴也逐漸熱衷于構建通用計算平臺。隨著高性能智能計算基礎平臺的逐步發展和推廣,軟件創新的發展軌跡也得到了進一步推動,為智能汽車的發展鋪平了道路。
1.2.2 智能汽車軟件發展路線
隨著汽車電子電氣架構的持續演進,智能汽車技術正努力打破軟件與硬件之間的緊密耦合。引入通用計算平臺是這一變革的關鍵,它促使硬件平臺標準化、基礎軟件平臺化及應用功能生態化成為可能。這意味著在不同硬件平臺上,可以根據不同客戶的需求移植和使用相同的基礎軟件平臺,并在此基礎上靈活定制和開發不同的應用功能。為此,各種硬件基礎平臺需提供統一的標準化接口,以便不同的軟件能夠適配,實現一定意義的軟硬件解耦。然而,軟硬件解耦并不意味著軟硬件適配工作能夠一勞永逸,它只是相對減少了耦合工作量。同時,智能汽車軟件還需要建立合理的軟件分層架構模式,以實現軟件各層之間的軟軟解耦。基于軟件分層的功能開發可以促進生態分工模式的形成,支持定制化應用功能的開發。
智能汽車軟件架構主要分為3個層次:底層系統軟件、中間層軟件和上層應用軟件。底層系統軟件主要包括操作系統及其內核、其他相關軟件,為整個系統提供基礎的運行環境和服務。中間層軟件是一個廣義的概念,指的是從底層系統軟件到上層應用軟件之間的所有層級的軟件,起到連接上下層的橋梁作用。上層應用軟件則與車輛的具體功能密切相關,包括狀態機和應用邏輯軟件,直接面向最終用戶提供各種智能汽車功能。圖1-6展示了智能汽車典型軟件架構示意圖。

圖1-6 智能汽車典型軟件架構示意圖
智能汽車軟件的發展將推動整個生態鏈的重構。在這一過程中,底層系統軟件,特別是操作系統及其內核,重點在于構建生態圈。中間層軟件將成為智能汽車軟件領域的競爭藍海,未來可能孕育出行業巨頭。而上層應用軟件將成為整車制造商深度介入軟件領域的關鍵戰場。這種分層的軟件架構不僅有助于實現軟硬件解耦,還為智能汽車的個性化和定制化提供了有力支持。
軟件架構為軟件模塊提供了必要的框架,它承載了軟件工程中所有模塊及模塊間的信息交互,對整體系統性能至關重要。像一座大樓的地基和承重墻一樣,軟件架構為控制流和數據流提供了通道,決定了軟件“加蓋”的高度和質量。因此,軟件架構直接影響軟件的性能。智能汽車軟件的發展路線,必然圍繞軟件架構的優化和創新展開。
軟件分層架構模式是智能汽車軟件架構的基礎。然而,并非所有分層軟件架構都適用于智能汽車領域。每種架構需要根據智能汽車的具體需求和特性進行調整和優化,以確保其適應性和效能。
在汽車行業中,較早應用的軟件分層架構是AUTOSAR經典平臺(Classic Platform,CP)標準軟件架構。這種架構由3個主要層次組成,即基礎軟件層(BSW)、運行時環境(RTE)和應用軟件層。基礎軟件層進一步細分為服務層、ECU抽象層、微控制器抽象層和復雜驅動,每一部分又可以細分為多個小模塊。圖1-7所示為AUTOSAR經典平臺(CP)標準軟件架構示意圖。

圖1-7 AUTOSAR經典平臺(CP)標準軟件架構示意圖
(1)應用軟件層
應用軟件層主要負責實現ECU功能的邏輯算法,其內部包含多個軟件模塊。每個軟件模塊又包含一個或多個運行實體,這些運行實體中封裝了相應的算法。整車制造商或供應商可以在應用軟件層進行定制化開發,以滿足特定的應用邏輯需求。
(2)運行時環境
運行時環境(RTE)主要負責基礎通信服務,實現應用軟件模塊與基礎軟件層之間以及軟件模塊間的通信,提供了架構分層間的有效隔離。作為應用軟件層與基礎軟件層之間的中間交互層,RTE對基礎軟件層的服務進行封裝,并對外提供標準化接口。應用軟件層可以通過RTE接口調用基礎軟件層的相關功能。同時,RTE還負責實現對應用層的軟件函數的調度。
(3)服務層
服務層將基礎軟件功能以服務的形式封裝,供應用軟件層調度。它主要提供系統服務、存儲服務和通信服務三大部分,具體包括車輛網絡通信管理、內存管理、診斷管理、ECU狀態管理、模式管理、邏輯監控和程序流監控等服務。這樣的設計允許應用軟件層通過服務層調用所需的基礎功能,實現高效的資源管理和流程控制。
(4)ECU抽象層
ECU抽象層負責封裝微控制器抽象層及外圍設備驅動,提供內外設備的統一訪問接口,實現對通信、存儲器和I/O硬件的訪問。微控制器抽象層僅封裝芯片上的功能,ECU抽象層則負責對芯片及外圍電路等所有硬件進行統一封裝,從而實現上層軟件應用與ECU硬件的分離。ECU抽象包括車載設備抽象、通信硬件抽象、存儲硬件抽象和I/O硬件抽象等。ECU抽象層專注于所有硬件層面的統一封裝,無需開發人員關注微控制器內部的細節。
(5)微控制器抽象層
微控制器抽象層負責封裝訪問微控制器的各種驅動,實現不同硬件接口的統一化。這些驅動包括微控制器驅動、通信驅動、存儲驅動以及I/O驅動等。微控制器抽象層將芯片的寄存器操作統一封裝成標準的庫,并對外提供標準化接口。通過這一層,軟件與微控制器得以隔離,從而封裝微控制器硬件,避免上層軟件直接操作硬件。這種做法確保了只有該層與硬件直接交互。因此,當更換微控制器芯片時,只需修改這一層的適配內容,便可實現軟件的便捷移植。
(6)復雜驅動
復雜驅動主要針對那些因特殊性難以進行標準化抽象的內容而設計,如一些復雜的傳感器抽象。復雜驅動能夠封裝未定義的功能,并提供接口供應用層調用,從而逐步向AUTOSAR經典平臺(CP)規范架構轉化。它還允許應用軟件層通過RTE直接訪問硬件。
AUTOSAR經典平臺(CP)的標準軟件架構是一種面向功能的架構,使用基于信號的通信方式,在傳統汽車ECU領域得到廣泛應用。然而,智能汽車集中式電子電氣架構對系統通信速率和計算能力有高要求,需要支持多核異構設計部署、高性能并行計算和基于以太網的高帶寬傳輸通信的軟件。AUTOSAR經典平臺(CP)單獨使用不足以滿足這些需求。為了更好地滿足智能汽車集中式電子電氣架構的軟件要求,AUTOSAR組織推出了AUTOSAR自適應平臺(Adaptive Platform,AP)標準軟件架構。這一架構能夠實現靈活的軟件配置,提供高性能計算和高帶寬通信機制,總體分為自適應應用(AA)和自適應應用的AUTOSAR運行時(ARA)兩部分,如圖1-8所示。

圖1-8 AUTOSAR自適應平臺(AP)標準軟件架構示意圖
從圖1-8中可以看出,AA部分包括自適應應用和非平臺服務兩種類型的應用服務,它們之間可以相互提供服務。ARA部分主要由功能集群提供的各種應用接口構成。這些接口分為兩大類:一類是自適應平臺基礎,主要負責提供基礎功能,如通信管理集群、持久性集群、診斷集群、時間同步集群和平臺健康管理集群等;另一類是自適應平臺服務,主要提供標準服務,如狀態管理集群、網絡管理集群、更新和配置管理集群等。
AUTOSAR自適應平臺(AP)是一種面向服務的架構(SOA),具備數據并行處理能力,能實現高性能計算處理。它不僅能滿足系統的實時性要求,也能滿足非實時性應用的軟件架構需求。除了架構分層的定義差異外,AUTOSAR自適應平臺(AP)與AUTOSAR經典平臺(CP)的對比分析見表1-4。
從AUTOSAR自適應平臺(AP)與AUTOSAR經典平臺(CP)的對比來看,兩者各有優勢:AP在動態靈活性方面表現更佳,而CP在實時安全性方面表現更為突出。在智能汽車的不同應用場景下,我們可以利用這兩種平臺,構建一個既靈活又安全的異構軟件架構,實現它們之間的互補和協作。智能汽車的軟件架構正在向融合型的發展路線轉變,主要以SOA為核心。對于那些對實時性和安全性要求很高的應用,則采用異構軟件架構設計,或者針對實時性和安全性進行設計改造。
表1-4 AUTOSAR自適應平臺(AP)和AUTOSAR經典平臺(CP)的對比分析

那么,到底什么是SOA?SOA是一種設計思想,強調高內聚和低耦合。在智能汽車應用中,SOA能將車輛的所有功能劃分成不同的服務,這些服務拆分為顆粒度適中的服務組件。這些組件遵循統一的接口設計標準,并通過統一的協議標準進行相互通信和訪問。這種架構允許服務組件相互組合,提供更多服務,從而具有強大的可擴展性,并支持車輛在出廠后軟件的持續升級和維護。
為了更生動形象地闡述SOA機制,我們不妨以餐廳經營做類比。設想一家餐廳提供N種菜品,如果采用非面向服務的模式經營,則每種或每個組合菜品都需要配備專門的團隊、工具和設備資源。這個團隊負責從采購食材原料到烹飪完成,直至將菜品端上餐桌呈現給顧客的整個過程。若該餐廳銷售的菜品種類眾多,則必須配備大量的專門團隊,這樣的做法常導致團隊間在采購、清洗食材乃至烹飪環節出現重復勞動,從而造成資源的浪費,顯然不經濟。
在這樣的背景下,SOA機制顯得尤為重要。若餐廳采用此機制來經營,就不會根據所售菜品來劃分團隊,而是將內部組織分成采購組、洗菜組、烹飪組等專業小組。這些小組不必關心顧客具體選擇了哪道菜品,專注于完成自己的基本任務即可。服務員根據不同客人的點菜情況進行下單,后廚各組人員只需按照標準化流程履行各自的職責,不同菜品由不同小組協作完成。通過這種方式,餐廳實現了SOA機制,優化了資源配置,提高了經營效率。
智能汽車的軟件架構也是如此,采用SOA可以提升效率。在這種模式下,軟件采取分層設計,每個軟件層級由多個細分的軟件模塊組成。各軟件模塊專注于執行自己的基礎任務,無須關心具體的應用功能,從而實現了軟件層級間和模塊間的解耦。同時,通過采用標準化接口,不同軟件模塊相互配合能夠支持多樣的服務目標實現,從而為智能汽車的功能更新與擴展奠定了良好的架構基礎。
除了軟件架構的發展變革外,智能汽車軟件的本質屬性也在發生變化。隨著人工智能的發展,軟件正從人類明確編寫代碼實現程序邏輯的傳統軟件時代,過渡到通過神經網絡訓練達成預期目標的智能軟件時代。在智能汽車的軟件開發演進中,智能軟件將占據一定的比重,因此,在分析智能汽車軟件發展路線時,我們必須考慮這部分的影響。與傳統軟件相比,智能軟件在本質上具有一些獨特屬性,如表1-5所示。
表1-5 傳統軟件與智能軟件的對比分析

智能軟件顛覆了傳統軟件的開發流程,開啟了一個前所未有的新時代。在語音、圖像、視頻識別領域,智能軟件展現出了比傳統軟件更強大的優勢,能夠解決傳統軟件難以解決的問題。
舉個例子,在通過軟件開發方法實現對小狗圖像的識別時,若采用傳統軟件開發流程,首先要進行需求描述,明確小狗的外觀特征,包括頭部、身體、四肢、尾巴、顏色及行為動作等。接著,對需求進行細化并進行設計、編碼和實施。在使用這套軟件進行小狗識別時,需要將待識別內容與代碼中定義的小狗特征進行匹配判斷,匹配成功則輸出確認結果。這種方法能夠識別一種或幾種特定類型的小狗。然而,面對不同顏色和品種的小狗時,其識別能力就顯得不夠靈活、智能。相比之下,智能軟件通過機器學習的方式,借助訓練數據集調整參數權重,逐步優化性能,實現持續學習和提升,從而通過特征識別技術達到泛化的效果,能準確給出目標結果。
智能軟件提高了智能化水平,但也為智能汽車引入了較大的不確定性。隨著集中式電子電氣架構和面向服務的融合型軟件架構的發展,智能汽車中的傳統軟件代碼量大幅增加,進一步增加了不確定性。這種不確定性使得智能汽車的安全性成為一個廣泛爭論的話題。然而,安全始終是智能汽車發展的起點和重心。作為智能汽車核心競爭力的重要組成部分,軟件的安全性將成為未來的關鍵競爭力。