<acronym id="olop1"><th id="olop1"></th></acronym>
<strike id="olop1"><blockquote id="olop1"></blockquote></strike>

<button id="olop1"><xmp id="olop1">

<button id="olop1"><dfn id="olop1"></dfn></button>

<button id="olop1"><dfn id="olop1"></dfn></button>

<button id="olop1"></button>
<strike id="olop1"></strike>

<option id="olop1"></option>
<strike id="olop1"></strike>
<button id="olop1"></button>

400-821-6015
行業資訊
您當前的位置:首頁 ? 行業資訊 ? 行業資訊
內部資訊行業資訊

智能汽車E/E架構技術發展趨勢(下)

發布日期:2023-08-29

接上篇:智能汽車E/E架構技術發展趨勢(上)

4 多域電子電氣架構的通信系統

     4.1 車載通信系統發展及現狀

     E/E 架構依靠通信系統實現各個硬件間的信息傳遞。目前主要的通信技術有5 種:控制器局域網(CAN)[29] 、局域互聯網(LIN)[30] 、面向多媒體的系統傳輸(MOST)[31] 、FlexRay 總線[32] 和車載以太網(ETH)[33] 。

     5種通信技術的主要特征如表1所示。

表1 各通信技術特性表

圖片

      除了上述外,還有一些處于試驗階段的新型車載通信技術。如第三代CAN 通信技術CAN XL[34] ,該技術縮小了CAN 與ETH 之間的傳輸速度和耦合的差距,可與以太網共同在基于信號的通信和面向服務的通信之間提供連接。在未來,車載通信系統的安全性和保密性將得到重視,光纖通信具有抗電磁干擾、無輻射、難以竊聽的優點,在車載通信安全、故障診斷與高精度控制領域也有廣闊的應用空間。

      隨著汽車智能駕駛等級的不斷提高,車載元器件數量呈指數級上升,信息數據量增多,對車載總線網絡在傳輸速率、實時性、容錯率以及成本方面都提出了更高的要求[35] 。CAN 總線雖然受到傳輸數據量少和時間不同步的限制,但其技術成熟度高,目前仍是車載總線技術的支柱[36] ;而LIN 總線、MOST 總線和FlexRay 通常根據其自身特點作為局域網絡接入;以太網憑借其高帶寬及低成本的優勢將作為通信系統的骨干網絡在未來引領下一代車載網絡的發展。目前情況下,要形成一個統一的車載總線協議標準仍需要較長時間。因此,在這之前,車載網絡系統仍然需要采用多總線并存的方式來滿足不同的 傳輸需求,進一步完善各種車載總線標準的兼容性和互操作性,以實現更好的數據交換和系統集成仍然是多域E/E架構需要解決的關鍵問題之一。

      4.2 時間敏感網絡通信協議分析及研究

      隨著高精度傳感器的廣泛部署和信息娛樂系統的功能不斷增強,車內數據量急劇增加,傳統的車載網絡難以有效支持和處理不斷增長的高速率、高帶寬通信需求[37] 。時間敏感網絡(time sensitive network,TSN)可實現數據在以太網中的確定性、實時性、低延時、高安全傳輸,被認為是解決以上問題的關鍵方案[38] 。TSN 可實現低成本大帶寬傳輸,傳輸速率可達10 Mb/s 至10 Gb/s,而且使用非屏蔽單對雙絞線實現全雙工通信,成本比傳統的屏蔽線纜降低80%,質量減輕30%[39] 。此外,TSN 具有良好的擴展性和通用性,可支持多種構型的車載網絡拓撲結構,實現不同應用數據的傳輸。

      對車載通信具有重要影響的TSN 協議可以分為4 種類型:時間同步、流量控制、可靠性和資源管理,下文將對其進行詳細介紹。

      4.2.1 時同步類協議

      部署了TSN 的E/E 架構的通信系統運行時,需要有一個統一的時間標度以保證時間同步的精度。TSN 的IEEE 802.1AS—2020 協議[40] 對TSN 流的時間同步方法和過程進行了定義和解釋。通過時間戳機制保證所有組件受同一全局時鐘控制,同時允許網絡中存在不同時域。對該協議的研究主要包括同步精度的影響因素[41] ,本地時鐘校正[42] 和同步質量評估[43] 等。在E/E 架構中,時鐘同步精度是保證各個傳感器實現高精度響應和定位外部環境的基礎。雖然目前有大量的研究針對工業TSN 的時鐘同步,但缺乏專門針對車內TSN時鐘同步特性的研究。車內通信環境與工業自動化系統有很大的差異,車輛的振動、溫度變化、電磁干擾等因素會對時鐘同步的精度造成干擾。因此,需要進一步研究車內TSN 時鐘同步精度的影響因素,以確保實現車內通信系統的高可靠性和高效性。

      4.2.2 流量控制類協議

      流量控制機制是TSN實現流確定低時延傳輸的關鍵技術之一。TSN 流量控制過程可以分為:流量分類、流量整形、流量調度和流量搶占[44] ,分別對應的TSN協議如表2所示。

表2 流量控制類協議表

圖片

      目前流量控制類協議的研究熱點領域,主要研究包括:各類流量最大端到端時延分析[45] ,TSN流量整形方法研究[46] 和時間關鍵流的流量調度方法研究[47] 。目前的研究大多集中在單一協議,下一階段需要圍繞協議間的協同作用機制以及協議在實際車載網絡場景下的應用開展。

      4.2.3 可靠性協議

      TSN 的可靠性指網絡對故障的預防以及恢復能力,主要包括IEEE802.1CB 和IEEE802.1Qci 協議。IEEE802.1CB[48] 設置了幀的復制和消除(FRER)機制,降低了流傳輸時幀擁堵或故障帶來的影響。主要針對控制類幀,嚴格限制丟包率,保證傳輸的可靠性。IEEE802.1Qci[49] 設置了幀的過濾與報錯(PSFP)機制,針對網絡出現故障時流的處理問題,避免了流量的過載和錯誤交付,提高了系統的魯棒性。TSN 可靠性問題研究主要包括冗余機制[50] 、故障檢測[51] 以及同步故障下的可靠性[52] 。后續研究應當重點關注車輛TSN網絡在各種故障情況下的可靠性,確保車輛在行駛過程中的安全性和穩定性。

       4.2.4 資源管理類協議

      資源管理的主要功能包括對網絡資源進行管理和配置及對性能數據進行監測和分析等。IEEE802.1Qat[53] 流預留協議解決了流的注冊與預留問題,是進行整形、調度和傳輸等過程的前提。IEEE802.1Qcc[54] 協議解決了TSN 網絡的集中管控問題,提出了分布式、集中式和集中網絡分布用戶式3 種TSN 網絡管控模型。目前研究主要圍繞架構模型的實現部署方案展開[55-56]。這些研究成果為車輛TSN網絡資源管理的實現提供了重要的技術支持和借鑒。后續研究應該重點關注如何實現車載TSN的管理與配置,重點突破事件觸發流等隨機流的管理、車-云安全交互管理等關鍵難題。

      TSN 作為多域E/E 架構的重要組成部分已經得到了充分的重視。但目前對TSN的研究主要集中在工業互聯網領域,在車載TSN 網絡的研究還不夠深入,在技術的遷移中主要存在幾大難點亟待解決:

    (1)場景構建問題,大數據、多種類的車載TSN 網絡模型的構建較為復雜,事件觸發的隨機信號流建模困難。

    (2)功能匹配問題,如何設計軟件去實現TSN的相關標準,以及TSN 協議在車載場景下的執行情況和效果如何都有待實驗驗證。

    (3)硬件支持問題,目前支持TSN以太網的芯片相對較少且沒有針對車載TSN 的專業測試設備,硬件實驗平臺的搭建較為困難。雖然困難重重但是仍然無法否定TSN在車載實時通信的應用潛力。在未來,TSN 的帶寬優勢有望進一步提高[57] ;車載TSN 與IP 協議的結合,使更多更復雜的車載安全和多媒體應用成為了可能[58] ;隨著自動駕駛等級的提升,TSN 的可靠性將隨著車載網絡信息安全性進一步得到提高;TSN 協議的開放性也為學術研究和工業部署提供了更開闊的空間。


      4.3 基于服務的軟件定義網絡

      傳統的車載網絡存在流量負載分布不均衡、報文發送延遲大、網絡吞吐量低、網絡模塊兼容性差和開放性低等問題,不利于進一步的開發和創新,也不利于未來各車型智能車載系統的互聯互通。為了解決這個問題, Ku 等[59] 在2014 年最先提出了軟件定義車載網(software defined vehicular network, SDVN)的概念。SDVN 將軟件定義網絡技術(SDN)應用到車載網絡中,用軟件定義網絡的思想改造車載網絡的體系結構。SDVN 首先將車載網絡設備中的數據轉發平面與控制平面分離開來,然后將所有的控制平面集中到一個邏輯上集中的控制器中,最后利用這個集中的控制器控制車載網絡中所有數據轉發平面報文的轉發行為[60] 。SDVN 可有效提高網絡性能、降低網絡服務更新的代價、簡化網絡管理、加速網絡創新。在SDVN 的應用方面,He 等[61] 提出了一種支持異構無線接口以提高網絡性能的SDVN 架構,使車載網絡的配置更加靈活。Ge等[62] 提出了一種集成5G 移動通信技術、SDVN 以及云計算的車載網架構,提高了車載網絡可擴展性。Correia 等[63] 提出了一個分層的SDVN 車載網絡架構,并基于Rawashde 等[64] 提出的聚類算法設計了一種新的路由協議,實現了數據的快傳輸、低延遲和高吞吐量。大量研究人員都希望通過SDVN 來具體實現TSN 的集中式模型構想。Hackel 等[65] 證明了TSN 與SDVN的結合能夠保障時間敏感流的傳輸質量,在汽車網絡中具有巨大的潛力。Gerhard 等[66] 結合SDVN 提出了一種軟件定義流保留的體系架構并根據802.1Qcc 定義了一個功能完整的TSN 配置基礎設施。目前基于服務的SDVN 還處于起步階段,在安全性、移動性、服務效率、部署和標準化等方面還有很多亟待解決的關鍵技術問題。但SDVN 作為一種可編程和高靈活的網絡架構仍具有很好的發展前景,可被應用于高效帶寬分配、車-路-云彈性算力分配等諸多場景。

      綜合上述,未來車載通信網絡將具有以下特點:

    (1)未來車載的通信協議將向著大帶寬、低成本、高安全的方向發展,車載TSN將成為骨干網絡,提供確定性、高帶寬和高安全的連接,現有總線形式在某些特定場景仍將保留。

    (2)為應對智能駕駛帶來的挑戰,車載網絡將實現更多的安全功能,SDVN 的應用將進一步提高網絡的可配置性和靈活性。

    (3)不同通信軟件組件之間的接口將進一步標準化,軟件的互換性將顯著提高。


5 多域電子電氣架構的軟件系統

    5.1 軟件定義汽車

      5.1.1 SDV的基本理念

      隨著功能的豐富,車輛設計的核心逐漸從硬件設計轉移到軟件開發,軟件成為塑造整車廠競爭力核心要素[67] 。SDV 的概念已成為產業界的共識,軟件的開發、升級將成為貫穿設計、銷售和服務的車輛全生命周期關鍵組件?;赟DV 的汽車整車開發流程將形成用戶交互評價信息指導新車開發、OTA技術實現軟件持續更新迭代的雙閉環模式[68] ?;诜盏能浖軜嬋鐖D9所示。該軟件架構一般被分為4層[69] 。

圖片

圖9 基于服務軟件架構

      SDV 的重要優勢就是減少了硬件差異對軟件的影響,從設備抽象層與原子服務層的軟件設計追求多車復用與減少差異化。通過API 標準化接口,減少重復勞動,降低軟件的復雜度,提高軟件的設計開發效率。在應用層的設計則重點打造差異化與定制化功能,最終實現軟件組件的高附加值與個性化服務。同時SDV 和OTA 技術的出現對汽車整車開發流程也帶來了新的變革。

      5.1.2 軟硬件解耦與映射

      SDV 實現的重要前提是軟硬件解耦,它是指軟件系統的設計完全獨立于硬件,在軟件框架中通過對硬件接口進行抽象化處理來兼容不同硬件設備。軟硬件解耦的關鍵在于接口定義的標準化,這需要整個汽車產業合理分工,通力配合,形成統一的軟硬件接口定義技術規范。實現軟硬件解耦對未來汽車開發、驗證和售后都將產生舉足輕重的影響。首先,軟硬件的解耦使得數據被從一個個子系統中解放出來,整車廠對功能實現的控制能力增強,這將對產業分工產生重要影響。其次,軟件可以脫離硬件進行獨立驗證,原本需要通過硬件在環測試的功能可以通過集成硬件環境的軟件在環測試進行驗證,這將極大地加快整車開發與測試速度,降低驗證成本。另外,汽車全生命周期的可升級,將有效提高汽車售后的可維護性和安全性,通過遠程升級(OTA)軟件可以逐步解放功能,有效增強用戶體驗和提高汽車保值能力。然而,目前受到傳統研發模式、企業轉型困難以及產業分工矛盾的影響,軟硬件的解耦仍然與理想狀態相去甚遠[70] 。

      伴隨著軟硬件解耦而來的是軟硬件映射問題,由于DCU 和CCP 需要集成包括傳感器數據處理、智能人機交互和高精度控制決策等眾多功能于一體,數據處理的復雜度驟增。如何將不同數據運算特點的功能軟件映射到匹配的處理器、實現軟硬件的協同最優是軟硬件映射需要解決的核心問題。多域E/E 架構引入了多種微處理器、大量異構計算資源與通信鏈路組合,使得需要考慮的因素進一步復雜。早期的研究通常根據任務通信關系和屬性,考慮時間、成本以及功耗等因素對單核異構系統進行軟硬件映射[71-72]。隨著多核嵌入式芯片的發展,大量研究針對多核分布式異構系統軟硬件映射問題提出優化設計方法[73-74],優化目標包括能耗優化[75-76]和硬件成本優化[77-78]。車載多核異構芯片對于成本、功耗、安全、算力和實時性等因素極其敏感,如何綜合考慮以上因素,根據功能設計專有芯片結構,并實現易于解耦的軟硬件映射是未來車載主控芯片設計需要突破的關鍵難題。

      5.2 面向服務的軟件設計

      面向服務的體系架構(SOA)是汽車產業從IT產業引入的先進理念,憑借可重用、易升級、易部署和松耦合的特點被認為是ICV 汽車軟件發展的重要方向。SOA的理念是通過靈活的接口使服務不再局限于特定的功能環境,實現服務共享[79] ,其中接口的定義需要根據SOA 標準進行設計,獨立于操作系統與硬件平臺。這與上文提到的SDV 原子服務層和設備抽象層的概念相輔相成。SOA的引入打破了傳統汽車軟件固化、封閉的生態,使之逐漸開放、開源。目前汽車產業對SOA 軟件設計已經做了相關實踐并提出基于SAO 的軟件開發模式[80-81],驗證出SOA使系統復雜度大大降低,各代汽車之間的軟件組件的重復使用大大簡化。

      為了保證了各系統服務之間的信息互通和組合形式的擴展,各服務模塊之間通過基于服務的中間件進行通信,這改變了車內通信方式。傳統的基于信號的通信方式,在車輛設計時就完成了通信矩陣的定義,信號的數據量、發送周期、路由路徑是固化的,靜態的?;诜盏闹虚g件則是通過在應用程序和網絡之間進行一定的抽象,在服務與應用之間建立相應的網絡連接。這個通信過程通常是動態的,可在運行時配置,不需要在設計時進行固化[82]。目前主流的面向服務的中間件主要包括DDS(data distribution service)與SOME/IP(scalable serviceoriented middleware over IP)。它們在AutoSAR 中都被集成為標準化模塊,因此被行業視為一流的解決方案。SOME/IP、DDS 和基于信號驅動的通信機制對比如表3所示。

表3 通信機制對比

圖片

     5.3 車用操作系統

     車用操作系統作為車內系統程序的集合,主要用來實現管理硬件資源、隱藏內部邏輯提供軟件平臺、提供用戶程序與系統交互接口、為上層應用提供基礎服務等功能,包含車控操作系統和車載操作系統兩大類[83] 。

     5.3.1 車控操作系統

      車控操作系統主要包括安全車控以及智能駕駛兩個子類操作系統,其基本架構如圖10所示。安全車控操作系統主要面向實時性要求極高,并且安全等級要求須達到ASIL-D 的傳統車輛底盤、動力、車身等功能領域,目前主流的安全車控操作系統大多兼 容 OSEK 以 及 AUTOSAR Classic Platform(AUTOSAR CP)標準軟件架構,目前相關技術已經較為成熟[84] 。基于AUTOSAR CP 的操作系統軟件的開發相較于傳統開發方式已經基本實現應用層和底層軟件以及軟件和硬件的解耦,從而一定程度上增強了軟件的移植、復用、擴展、升級、安全和維護等能力,對減少軟件開發周期和降低成本都起到了有益作用[85] 。


圖片

圖10 車控操作系統基本架構


      智能駕駛操作系統則面向新一代集中式E/E 架構升級背景下高算力、高性能、高安全性、高可靠性要求的智能駕駛功能,此種操作系統正處于發展機遇期,各國都在初步探索階段。對于智能駕駛操作系統AUTOSAR CP難以完全適應,基于此AUTOSAR組織在2017 年發布了基于POSIX PSE51 子集的操作系統與應用程序之間標準編程接口規范的面向服務架構的AUTOSAR Adaptive Platform(AUTOSAR AP)以應對異構芯片平臺上車輛智能駕駛服務需求[86-87]。

      對于車控操作系統,國內外大部分企業均基于AUTOSAR 開發各自的系統[88] ,可以說AUTOSAR 軟件架構標準在車控操作系統領域起到了關鍵的引領和參考作用,是目前國際上主流的汽車標準軟件架構?;贏UTOSAR 標準的軟件架構的實現離不開相應配置工具鏈解決方案的支持,當下主流工具鏈為德國Vector 公司的面向AUTOSAR CP 的DaVinci系列工具以及面向AP 的MICROSAR Adaptive;Bosch 旗下子公司ETAS 的面向CP 和AP 的RTACAR 以及RTA-VRTE。此外還有ElektroBit 公司下的EB tresos、EB corbos 系列CP 和AP 配置工具;Siemens 的Capital VSTAR,KPIT 的KSAR Classic、KSAR Adaptive 等。國內對于AUTOSAR 也積極布局,普華基礎軟件、東軟睿馳等都相繼推出各自的AUTOSR 解決方案,助力國產化工具鏈的實踐落地[89] 。

       5.3.2 車載操作系統

       車載操作系統主要面向車輛上安全性、實時性要求相對較低的信息娛樂功能需要,發展較為迅速[90] ?,F階段主流的車載操作系統在實時性、安全性、應用場景等方面的對比如表4所示[91] 。


表4 各類車載操作系統功能屬性對比

圖片

      伴隨著智能化、網聯化的深入發展,單個的車載操作系統已難以應對車上信息娛樂功能的不斷豐富,車載操作系統逐步向多操作系統架構過渡。多操作系統架構主要有兩種實現方式,基于硬件隔離的架構[92] 以及基于虛擬化管理技術(Hypervisor)的架構[93] 。硬件隔離架構由于在物理層面上進行了硬件分區,相應的資源分配管理問題得到了簡化,較容易開發,但是固定的硬件分區下可能導致其靈活性相對較差,并可能會造成一定程度的資源浪費;而基于Hypervisor 進行多操作系統隔離以管理多個操作系統平臺及其應用程序則可以避免系統資源的固定分配,提高資源利用率,并且其利用主機內存作為數據交互媒介,數據共享能力顯著提高,但同時也造成了系統開發復雜度和安全風險的提升[94] 。


6 研究展望

      目前針對ICV 的多域E/E 架構研究日益增加,各國學術界和工業界均展開了大量的研究,各大型車企也都在先進車型上進行了初步部署,但是由于E/E 架構涉及要素的綜合性和復雜性,仍未形成一套完備的E/E 架構設計理論、工程方法以及工具軟件,建議進一步加強下述研究。

    (1)加強架構總體設計理論和方法研究

      業界現有架構開發仍然存在著大量的依靠工程經驗的設計,但是隨著功能的復雜化,需求的多元化和迭代的快速化,基于經驗的設計很難得到最優的設計效果。因此必須盡快形成完整的設計理論和方法,為架構總體設計提供從總體設計理論到工程實踐應用自上而下的指導。后續研究需要從ICV 的E/E 架構的設計問題的本質出發,研究架構實現安全性、經濟性、可擴展性的設計機理。通過理論分析和試驗驗證,梳理汽車功能需求、安全需求與架構設計實現之間的內在聯系,完成需求的規范化建模與功能的準確分割。基于現有主流架構和技術水平,開展架構建模、系統優化和分析的研究,形成架構設計的理論和方法。

    (2)構建軟件、硬件和通信接口標準體系

      架構設計在車內涵蓋軟件、硬件與通信系統,在車外互通車端、路端和云端,各類接口復雜多樣,單一廠商很難完成所有接口的端到端的設計。只有形成軟件、硬件和通信接口標準體系,才能讓產業鏈  各方各抒己長,整車廠才能根據架構總體設計框架進行集成、靈活配置,從而推動ICV 快速落地。在自頂向下的服務設計上,標準化接口應使應用層和通信層開發專注于業務邏輯,不受限于硬件實現;在自底向上的抽象設計上,應該使底層硬件設備能關注到不同車型差異,具備通過對配置的靈活更改以減小代碼差異化的能力。

    (3)開發E/E架構仿真測試驗證體系

       E/E 架構仿真評估技術是驗證設計合理性和實現快速迭代更新的基礎,因此需要建立多層級、一體化、虛實結合的E/E 架構測試驗證體系。開展融合虛擬仿真、封閉場景、開放道路測試的多環境交互技術研究,研發適用于失效分析與風險評估的E/E 仿真場景庫挖掘與重構技術,開發實時性評估仿真分析平臺,實現架構評估與仿真測試的平臺化與標準化。面向硬件在環和實車在環測試的物理信號高保真和實時模擬技術,開發網聯場景下的通信信號模擬裝置,開展E/E 架構測試驗證體系的多層級建設,形成部件級、系統級、整車級多層次的測試評價方法,實現E/E架構測試驗證體系的一體化設計。

    (4)加強多維度冗余架構體系設計與信息安全縱深防護技術研究

      為應對ICV 架構失效的隱蔽性和突發性難題,針對冗余架構體系下的傳感器、控制器、執行器層面的故障檢測方法及主動重構控制理論進行研究,探索高效精準的故障檢測方法,建立完善的主動重構控制機制,保證在一定故障下ICV 仍具有正常行駛的能力。為了保證高級別自動駕駛系統的網絡安全、數據安全和信息安全,需要從外部網聯安全、域間控制安全、車載網絡通信安全、控制器本體安全等多個維度出發,構造多層縱深防御體系,構建縱深防護技術理論,在保證系統安全的同時降低冗余度和系統復雜性。

    (5)加速ICV核心部件產業鏈國產化進程

      我國在ICV 領域已經具備了先發優勢,但在高算力芯片、車用操作系統和架構設計工具軟件等方面,與歐美等發達國家相比仍存在一定差距。雖然出現了大量國產化方案,但其功能完整度和產業支持配套相對較弱,尚未形成完整的國產化產業鏈。因此,當前我國需要進一步加快關鍵技術的國產化研發,將先發優勢轉化為領跑實力,努力發展出具有獨立自主特色的中國汽車產業,提高自主品牌競爭力,推動我國汽車產業向高質量發展邁進。


7 總結

       多域E/E 架構對于未來ICV 能否普及并實現其預期功能有著重要意義。然而,在當前階段該領域還沒有形成完善的方法論、技術理論體系與工具鏈,行業仍然處在摸索與研究階段,仍然需要大量的研究與實踐投入。本文參考大量研究與產業實例,厘清了E/E架構的發展需求與挑戰,梳理了E/E架構的技術現狀,從總體設計、硬件系統、通信系統及軟件系統4 個角度對多域E/E 架構的關鍵技術及現有方案進行詳細的綜述,最后對未來架構研究進行了展望。


轉自智能汽車設計

上海創程車聯網絡科技有限公司版權所有 滬ICP備11045498號-1   技術支持:網站建設
国产免国产免 费,久久激情无码免费综合视频,色呦呦网站,欧美乱妇日本无乱码特黄大片
<acronym id="olop1"><th id="olop1"></th></acronym>
<strike id="olop1"><blockquote id="olop1"></blockquote></strike>

<button id="olop1"><xmp id="olop1">

<button id="olop1"><dfn id="olop1"></dfn></button>

<button id="olop1"><dfn id="olop1"></dfn></button>

<button id="olop1"></button>
<strike id="olop1"></strike>

<option id="olop1"></option>
<strike id="olop1"></strike>
<button id="olop1"></button>