<meter id="pryje"><nav id="pryje"><delect id="pryje"></delect></nav></meter>
          <label id="pryje"></label>

          新聞中心

          EEPW首頁 > 汽車電子 > 設(shè)計(jì)應(yīng)用 > 新型整車控制器關(guān)鍵技術(shù)分析

          新型整車控制器關(guān)鍵技術(shù)分析

          作者: 時(shí)間:2023-02-14 來源:九章智駕 收藏

          從汽車電動化、智能化、網(wǎng)聯(lián)化、共享化的角度闡述了新型關(guān)鍵技術(shù)需求,包括高計(jì)算性能、高通訊帶寬、高功能安全性、軟件持續(xù)更新。針對上述需求總結(jié)了以太網(wǎng)、CANFD、多核芯片、雙核心、OTA關(guān)鍵技術(shù)行業(yè)現(xiàn)狀,對未來發(fā)展趨勢進(jìn)行了展望。

          本文引用地址:http://www.ex-cimer.com/article/202302/443338.htm


          1.前言 


          電動化、智能化、網(wǎng)聯(lián)化和共享化是汽車產(chǎn)業(yè)公認(rèn)的未來發(fā)展方向。作為電動汽車核心零部件,必須能夠支撐汽車“四化”。其必須滿足高計(jì)算性能、高通信帶寬、高功能安全性、軟件持續(xù)更新等需求。目前整車電子電氣架構(gòu)及所搭載技術(shù)普遍無法滿足以上需求。為覆蓋上述需求,未來汽車產(chǎn)品將逐漸采用集中式電子電氣架構(gòu),同時(shí)整車控制器必須包含以太網(wǎng)、CANFD、多核芯片、雙核心、OTA等關(guān)鍵技術(shù)。


          本文將首先介紹整車控制器與分布式和集中式2種電子電氣架構(gòu)的關(guān)系,然后分別介紹了新型整車控制器的關(guān)鍵技術(shù),對技術(shù)內(nèi)容進(jìn)行了分析,提出了未來發(fā)展趨勢并進(jìn)行了展望。


          2.整車控制器與電子電氣架構(gòu)


          1 整車控制器與分布式電子電氣架構(gòu)


          在以往的芯片能力前提下,受到計(jì)算能力及通信能力的限制,整車控制器無法集成所有的車輛控制軟件,即使是新能源部件控制相關(guān)的軟件也無法全部集成。這決定了整車控制器只能作為分布式電子電氣架構(gòu)中的一員,但是這種關(guān)系限制了功能變更及擴(kuò)展。


          在分布式電子電氣架構(gòu)中,一項(xiàng)整車層級的功能由多個(gè)控制器配合完成。某項(xiàng)功能的實(shí)現(xiàn)可能需要幾個(gè)或十幾個(gè)控制器相互配合,并且這些控制器可能分布在整車不同的網(wǎng)絡(luò)中(圖1)。整個(gè)交互過程與時(shí)間配合異常復(fù)雜。整車普遍有100余個(gè)控制器,幾百項(xiàng)整車級功能,功能與控制器本身的物理連接交織成一個(gè)巨大而復(fù)雜的網(wǎng),非常不利于模塊化設(shè)計(jì)與擴(kuò)展。在這種情況下,增加一個(gè)新功能,需要在上述的復(fù)雜功能網(wǎng)絡(luò)上考慮各部分相關(guān)性,并對大量的控制器軟件進(jìn)行修改及測試。


          11.png

          圖1 整車控制器在分布式電子電氣架構(gòu)中的位置


          2 整車控制器與集中式電子電氣架構(gòu)


          隨著芯片及車載以太網(wǎng)的發(fā)展,整車控制器已經(jīng)具備集成大部分車輛控制軟件的能力。分布式電子電氣架構(gòu)正在逐漸向高度集成化和智能化發(fā)展,整車控制器在電子電氣架構(gòu)中的位置也隨之發(fā)生變化,真正實(shí)現(xiàn)車輛層級的集成型控制器,其控制涵蓋動力、底盤以及一些網(wǎng)關(guān)功能。整車控制器與集中式電子電氣架構(gòu)的關(guān)系如圖2所示。將大部分的功能集成于整車控制器中會極大地減少整車線束長度與控制器數(shù)量。


          12.png

          圖2 整車控制器在集中式電子電氣架構(gòu)中的位置


          3.新型整車控制器關(guān)鍵技術(shù)


          為支撐汽車“四化”,整車控制器必須滿足高通信帶寬、高計(jì)算性能、高功能安全性、軟件持續(xù)更新等多項(xiàng)需求。其中,高通信帶寬催生了車載以太網(wǎng)、CANFD技術(shù)發(fā)展;高計(jì)算性能催生了多核芯片和雙核心控制架構(gòu)技術(shù)發(fā)展;軟件持續(xù)更新催生了OTA技術(shù)發(fā)展。這些技術(shù)將被普遍應(yīng)用在新型整車控制器上。下面將分別介紹這些技術(shù)。


          1 車載以太網(wǎng)


          在過去20年里通信帶寬問題一直困擾著汽車行業(yè)。在這期間,CAN總線是主流的車載網(wǎng)絡(luò)技術(shù)。其1 Mbit/s的標(biāo)稱速度在該技術(shù)早期對于汽車帶寬需求有足夠的裕度。然而近年來隨著車輛控制邏輯越來越復(fù)雜,所需控制器和傳感器數(shù)量急劇增加,雖然集中式電子電氣架構(gòu)可以在一定程度上減少控制器數(shù)量,但是由于域控制器的計(jì)算能力遠(yuǎn)高于原有車輛控制器,因此1 Mbit/s的CAN通信帶寬顯然是無法滿足數(shù)據(jù)交互需求的。


          更高的通信帶寬要求加速了以太網(wǎng)和汽車行業(yè)的融合。以太網(wǎng)誕生于20世紀(jì)70年代,其最早的雛形與如今家庭、辦公、服務(wù)器機(jī)房、數(shù)據(jù)倉庫運(yùn)行的以太網(wǎng)早已截然不同。盡管以太網(wǎng)與時(shí)俱進(jìn)地發(fā)展,但是應(yīng)用于汽車仍有一些問題,最主要的是電磁兼容性問題。這些限制在BroadR-Reach技術(shù)出現(xiàn)后被打破,該技術(shù)可在單對非屏蔽雙絞線上提供100 Mbit/s的帶寬。這種傳輸方法從未應(yīng)用在之前的以太網(wǎng)。即便物理層變化,這種技術(shù)仍能夠在高層實(shí)現(xiàn)與以太網(wǎng)的無縫結(jié)合且運(yùn)行方式不變。目前,該技術(shù)已經(jīng)用于量產(chǎn)車型。同時(shí),支持更快速度的RTPGE技術(shù)正在研發(fā)中,在保留軟件兼容性的同時(shí),其帶寬有望提升到1 Gbit/s。


          盡管通信帶寬有著明顯的優(yōu)勢,但受制于成本及功耗因素,車載以太網(wǎng)主要應(yīng)用于骨干網(wǎng)絡(luò)。用于整車控制器與其他域控制器的通信,如圖3。而對于域內(nèi)的智能執(zhí)行器和傳感器,使用其他低成本解決方案,如CANFD、CAN、LIN。


          13.png

          圖3 整車控制器使用以太網(wǎng)與其他域控制器通信


          當(dāng)然,在整車控制器上增加車載以太網(wǎng)面臨著巨大的改變:相對于CAN通信更龐大的軟件協(xié)議棧;更大的控制器功耗;更大的靜態(tài)電流,這些都需要在系統(tǒng)設(shè)計(jì)時(shí)被考慮。


          2 CANFD


          考慮到成本及功耗,整車上只有骨干網(wǎng)使用高通信帶寬的以太網(wǎng)通信。但是對于其他子網(wǎng),標(biāo)稱1 Mbit/s的CAN通信也迫切的需要提升通信速度。目前成熟的CANFD技術(shù)是一個(gè)好的解決方案。


          CANFD總線是CAN總線的高帶寬解決方案,博世公司于2011年首先提出CANFD概念,并于2012年首先發(fā)布CANFD1.0版本。在保留CAN總線主要特性的同時(shí),改善了錯(cuò)誤幀漏檢率,同時(shí)保證網(wǎng)絡(luò)中大部分軟硬件特別是物理層不變。將總線的最高傳輸速率提高到5 Mbit/s以上(CAN通信的最高傳輸速率為1 Mbit/s,實(shí)際使用速率最高為500 kbit/s)。


          更重要的是,CANFD數(shù)據(jù)長度最長64字節(jié),這使得CANFD的數(shù)據(jù)場占比達(dá)到近85%。CAN的數(shù)據(jù)場占比只有約50%。這意味著即使同樣的通信帶寬,CANFD可以多傳輸約70%的有效數(shù)據(jù)。CANFD幀格式如圖4所示。


          1673955702922464.png

          圖4 CANFD幀格式


          更為關(guān)鍵的是,由于CANFD保留了CAN的大部分關(guān)鍵特性,所有的CANFD芯片都能夠兼容CAN。這使得選擇CANFD芯片的控制器在不改變硬件的情況下,只修改軟件即可適配CAN通信網(wǎng)絡(luò)。CANFD技術(shù)有多重優(yōu)勢,在未來相當(dāng)長一段時(shí)間內(nèi),車載以太網(wǎng)與CANFD將會長期共存,各司其職,共同發(fā)展。


          3 多核芯片


          同傳統(tǒng)消費(fèi)電子領(lǐng)域早期一樣,為了獲得更快的處理速度,汽車行業(yè)采用提升核心頻率的方式來提升處理速度。但為了兼顧穩(wěn)定性,核心頻率提升遇到瓶頸,未來小幅的提升核心頻率已經(jīng)不能滿足日益增長的軟件執(zhí)行速度需求。這種情況下,汽車行業(yè)選擇了與消費(fèi)電子一樣的技術(shù)路線,采用多核芯片。


          多核芯片大幅提升了芯片的運(yùn)算能力。這是一種并行的方法。所以在應(yīng)用中想獲得同樣的效果,需要在軟件設(shè)計(jì)時(shí)合理地將各部分軟件分配到各個(gè)核心中。原則是盡量讓所有軟件并行。多核芯片的算力與同頻率單核芯片的算力加速比可以使用Amdahl定律來評估。公式如式(1):


          15.png


          其中,S為多核芯片的算力與同頻率單核芯片的算力加速比;a為并行計(jì)算部分所占的比例;n為核心數(shù)量。


          如圖5,當(dāng)并行程序?yàn)?5%時(shí),加速比的極限性能為4.0。在10核以內(nèi)增加核心數(shù)都可以大幅提升運(yùn)算性能。前期可以通過此方式對系統(tǒng)運(yùn)算能力和分配要求做大略的評估,尋找一個(gè)最佳投入產(chǎn)出點(diǎn)。同時(shí)這個(gè)公式還指出,對于一個(gè)核心數(shù)量固定的多核系統(tǒng),增加程序并行性是提升系統(tǒng)運(yùn)算性能的有效措施。


          16.png

          圖5 并行程序占75%時(shí),加速比S與核心數(shù)量n之間的關(guān)系


          4 雙核心控制架構(gòu)


          在過去的幾十年里,汽車電子行業(yè)一直采用微控制器(MCU)搭建各種類型的車載控制系統(tǒng)。盡管不同廠家的微控制器性能各異,但他們都有一些通用的特點(diǎn):集成度高、價(jià)格低廉、高可靠性、核心頻率低、程序是預(yù)先裝載的以及不允許用戶安裝軟件。軟件定義汽車的出現(xiàn),要求整車控制器具備高計(jì)算性能、程序可更新、客戶可安裝軟件等特性,在整車控制器上微控制器便不能再獨(dú)自勝任。


          目前主流的解決方案是引入微處理器(MPU)作為微控制器的補(bǔ)充。組成雙核心高性能整車控制器。這些微處理器與智能手機(jī)或PC中使用的微處理器非常相似,具有強(qiáng)大的計(jì)算及數(shù)據(jù)處理能力和高核心頻率。但其并不像微控制器具有種類繁多的外設(shè),甚至連程序運(yùn)行所必須的RAM、ROM都不包含,所以硬件設(shè)計(jì)時(shí)必要的外設(shè)需要被重新考慮。


          整車控制器中同時(shí)包含了微處理器與微控制器(圖6)。由于這是2個(gè)獨(dú)立的軟件系統(tǒng)去實(shí)現(xiàn)一些共同的功能,核間通信必不可少。核間通信有大量數(shù)據(jù)量傳輸,對通信帶寬要求較高,且通信方式必須同時(shí)被微控制器和微處理器所支持。滿足上述特點(diǎn)的以太網(wǎng)是一個(gè)優(yōu)質(zhì)選擇。


          17.png

          圖6 微控制器(MCU)與微處理器(MPU)集成度差別


          雙核心控制架構(gòu)還有一種形式,高集成度的SOC(System on Chip)芯片同時(shí)集成微控制器和微處理器。盡管物理上統(tǒng)一,但這仍然是2個(gè)獨(dú)立的軟件系統(tǒng),需要相互配合去實(shí)現(xiàn)一些共同的功能。


          在雙核心架構(gòu)的整車控制器中,微控制器和微處理器采用不同的操作系統(tǒng)。CLASSIC AUTOSAR依然是微控制器最好的操作系統(tǒng)解決方案。而對于微處理器,操作系統(tǒng)選擇空間很大,主要包括Linux、QNX、VxWorks、PikeOS。雖 然AUTOSAR推 出 了ADAP?TIVE AUTOSAR,但嚴(yán)格來講,這并不是一個(gè)完整的操作系統(tǒng)。ADAPIVE AUTOSAR無法獨(dú)立運(yùn)行,它運(yùn)行于POSIX標(biāo)準(zhǔn)接口之上。而POSIX接口還需要上述提到的Linux、QNX、VxWorks、PikeOS等操作系統(tǒng)來提供。同CLASSIC AUTOSAR相比,ADAPTIVE AU?TOSAR的模塊數(shù)量不足前者15%。從目前情況看,若想達(dá)到CLASSIC AUTOSAR在汽車行業(yè)的普及率,ADAPTIVE AUTOSAR依然有很多路要走。


          5 OTA


          在過去的幾十年里,汽車電子產(chǎn)品所有的軟件都是預(yù)先裝載的。車輛交付給客戶后,沒有不可接受的軟件問題,一般不會對車輛軟件進(jìn)行更新;一旦發(fā)現(xiàn)軟件問題,要進(jìn)行車輛召回。統(tǒng)一由售后服務(wù)人員逐一為有問題的車輛升級軟件。對售后部門來說,這是一筆非常龐大的開銷。據(jù)統(tǒng)計(jì)2015年美國汽車召回達(dá)到8 400萬量,其中6.4%的召回與軟件有關(guān)。而空中升級技術(shù)(Over-the-Air Technology,OTA)可以解決上述問題。


          OTA技術(shù),最早用于手機(jī)端,用戶可以通過云端下載和更新軟件。帶有OTA的汽車也同樣可以通過云端遠(yuǎn)程進(jìn)行車輛系統(tǒng)和功能的升級更新。特斯拉首先將OTA技術(shù)應(yīng)用于汽車上。


          OTA技術(shù)需要云端和車內(nèi)端系統(tǒng)同時(shí)部署,OTA架構(gòu)如圖7。主要介紹整車控制器支撐OTA需要實(shí)現(xiàn)哪些功能。在經(jīng)過授權(quán)情況下,軟件從云端經(jīng)OTA Client進(jìn)入車內(nèi)端。經(jīng)過防火墻,分發(fā)到需要升級的控制器。


          18.png

          圖7 OTA系統(tǒng)方案


          OTA是一個(gè)復(fù)雜的過程,為了避免出現(xiàn)問題,下述問題在整車控制器設(shè)計(jì)時(shí)必須被考慮。


          (1)需要支持程序回滾,在OTA升級失敗或新程序運(yùn)行不穩(wěn)定的情況下,使程序回滾到穩(wěn)定運(yùn)行版本;

          (2)需要考慮信息安全,通過通信加密、軟件包驗(yàn)簽等方式保證軟件信息安全;

          (3)需要對車輛配置進(jìn)行識別并對OTA能否開始條件進(jìn)行判斷;

          (4)需要考慮軟件OTA升級通信速率問題,避免出現(xiàn)由于升級時(shí)間過長,影響用戶用車的情況。


          4.結(jié)語


          綜上所述,為支撐汽車實(shí)現(xiàn)電動化、智能化、網(wǎng)聯(lián)化和共享化,作為電動汽車核心零部件的整車控制器必須具備高計(jì)算性能、高通信帶寬、高功能安全性、軟件持續(xù)更新的特點(diǎn)。本文首先介紹了在這些新特點(diǎn)下整車控制器與電子電氣架構(gòu)之間的關(guān)系。然后,結(jié)合相關(guān)成熟技術(shù),闡述新型整車控制器將配備車載以太網(wǎng)、CANFD、多核芯片、雙核心控制和OTA關(guān)鍵技術(shù)。最后,對上述技術(shù)進(jìn)行了介紹,分析了在整車控制器上應(yīng)用涉及的相關(guān)特性。其中很多特性并不局限于整車控制器,對其他控制器也有借鑒意義。


          來源:九章智駕




          關(guān)鍵詞: 整車控制器

          評論


          相關(guān)推薦

          技術(shù)專區(qū)

          關(guān)閉
          看屁屁www成人影院,亚洲人妻成人图片,亚洲精品成人午夜在线,日韩在线 欧美成人 (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })();