日前，天際汽車自主開發(fā)了VBU控制器，將VCU和BMS整合到一起，實現(xiàn)軟硬件的自主開發(fā)應(yīng)用。這不僅打破了專業(yè)技術(shù)的壁壘，同時在天際汽車目前上市的ME5增程車和純電動車上都實現(xiàn)了量產(chǎn)。該系統(tǒng)架構(gòu)實現(xiàn)了電池管理系統(tǒng)，從硬件上面脫離，不再跟隨電池包，而是以VBU為主，變成了置身于電池包外的控制器，賦予了非凡的意義。
在傳統(tǒng)控制系統(tǒng)中，不光是動力系統(tǒng)控制，VCU、EMS、MCU、BCM等等控制器都脫不開輸入，中間邏輯處理，最后是輸出的框架。輸入典型包括數(shù)字量、模擬量采集、通訊輸入；輸出典型包括低邊、高邊驅(qū)動，以及通訊總線的輸出。將來會不會存在一種專用于傳感執(zhí)行的控制衛(wèi)星板的概念，衛(wèi)星板可能分會為A/B/C型，每一型會根據(jù)最優(yōu)配置的原則，在不浪費的情況下配置一些廣泛使用的、特定數(shù)量的接口，具有一定的驅(qū)動能力，以及通訊的能力。基于該前提，就把邏輯算法，更多上提，提到核心板（高算力的SOC做異構(gòu)的芯片）。
在這種劃分下，電子電氣構(gòu)架上面中心控制器將更貼近于用戶感知功能，衛(wèi)星板則更多和硬件被控對象，如電池包、電機、OBC、DC等結(jié)合。
天際汽車認為將來對于車載的控制系統(tǒng)硬件技術(shù)趨勢而言，從低速總線通訊會越來越多的向高速總線過渡，另外會從有線向無線過渡。硬件上會越來越多融合消費電子和工業(yè)領(lǐng)域的WIFI、4G、高速串行技術(shù)。
車輛控制功能融合和重新組織
過去燃油車沒有VCU，所有都集成在EMS中，所有駕駛中的扭矩、油門、制動、檔位，都通過EMS完成。發(fā)動機被電機替代后，增加了電池需要進行充放電模式及上下電過程的管理，以上功能需要一個控制器去實現(xiàn)，而VCU承擔了這些功能。同時，電動車的的能量和功率協(xié)調(diào)也需要控制器進行計算，再疊加信息處理、安全監(jiān)控系統(tǒng)等內(nèi)容，最后就集成為VCU控制器。
而現(xiàn)在反過來想，例如VCU的縱向控制功能，是在駕駛員需求扭矩解析的基礎(chǔ)上，對電驅(qū)動系統(tǒng)發(fā)控制指令實現(xiàn)。無論從VCU發(fā)出，還是從其它控制器發(fā)出，從單純的縱向控制需求而言，完全可能被其它控制器取代，只需把駕駛員及其它縱向扭矩的的輸入信息獲取和解析。再如，熱管理系統(tǒng)在電動車上更加復(fù)雜，乘員的空調(diào)舒適溫度與關(guān)鍵部件的適宜溫度訴求應(yīng)相互協(xié)調(diào)而來，相關(guān)的泵、閥、風(fēng)扇、壓縮機、加熱器等部件管理也具備與電池管理系統(tǒng)或其它控制器融合的可能性，而不需要綁定在VCU上。而像充放電模式、上下電過程等協(xié)調(diào)，本來就是跟著電池而來，自然是可以聚焦于電池管理的控制器上。VCU剩下的信息處理、安全監(jiān)控、診斷系統(tǒng)，其實是每個控制器都需要，可以算平臺功能。因此大膽預(yù)測，未來VCU控制器作為獨立控制器存在的意義不大。
目前天際汽車將VCU和BMS兩個控制器進行融合。對于電動車而言快充、慢充、放電、遠程喚醒這幾個模式本就是一體的，結(jié)合也顯得非常自然。總而言之，將兩個控制器相結(jié)合，能夠創(chuàng)造出很多便利性，將原來大量需要通過交互和溝通的過程，變成控制器內(nèi)部變量的傳遞，對整個提高系統(tǒng)的控制效率起到了極大的幫助。
隨著車輛控制功能融合和重新組織，主機廠和供應(yīng)商之間的關(guān)系將被重新定義。過去主機廠是找許多零部件廠商攢一個功能，基本上各個零部件會傾向于去用自身平臺功能，不愿意修改，所以主機廠就要居中協(xié)調(diào)幾家的廠商來合起來實現(xiàn)功能，過程非常的冗長和復(fù)雜，并且更改的自由度小，基本上基于現(xiàn)有的平臺做小的調(diào)整。在域控制器模式下底層軟硬件開發(fā)對于各個ECU之間的功能，提出更加精準有針對性的需求。
所以將來在產(chǎn)業(yè)鏈上的分化將會呈現(xiàn)主機廠越來越多的強調(diào)掌握接口，去差異化，與為用戶創(chuàng)造價值，對于供應(yīng)商而言，可能是更多的強調(diào)制造標準的接口，達到標準和可靠。
控制功能承載的主體往云端拓展
天際汽車現(xiàn)在車上都配備T-box，有自己的企標上傳規(guī)則和服務(wù)器，把一些數(shù)據(jù)存下來，行業(yè)很多乘用車企業(yè)也是這么做的。
天際汽車計劃在云端為每輛車建檔，以每輛汽車的VIN碼為標識。給每輛車分配每個控制器的數(shù)據(jù)儲存單元。數(shù)據(jù)存儲器里面存三類數(shù)據(jù)，第一類是周期性的重要數(shù)據(jù)，第二類是特定事件發(fā)生時的捕捉數(shù)據(jù)，此外還有第三類通過車載控制器進行邊緣計算提煉出的關(guān)鍵特征數(shù)據(jù)。
有了數(shù)據(jù)之后，就是計算部分?；谠贫藬?shù)據(jù)進行計算，可以抽象駕駛員的駕駛風(fēng)格，電池的健康狀態(tài)等，之后甚至可以去下發(fā)標定，把當前控制器里的標定值進行修改，并且把變更存檔在云端。從行業(yè)技術(shù)狀態(tài)而言，目前各個環(huán)節(jié)的基礎(chǔ)技術(shù)棧都已經(jīng)具備，只需要進行貫通就可以實現(xiàn)。
天際汽車希望做到目標是出廠時有一致性標定，在每次運行的時候，有云端的信息過來就按照云端的信息進行調(diào)整，沒有云端的信息過來它就是原來車上的控制器，只有把車上和云上結(jié)合到一起，才是一個完整的控制系統(tǒng)。每輛車隨著使用，會調(diào)整一些特征的特性，最后實現(xiàn)一車一標定的概念。
SOA面向服務(wù)的架構(gòu)
目前汽車行業(yè)內(nèi)大部分還是非面向服務(wù)架構(gòu)，控制系統(tǒng)里面在進行一個項目之前，要把開頭給定義好，任何一方改一個信號，要涉及到多方去改矩陣，牽一發(fā)而動全身?，F(xiàn)在倡導(dǎo)的SOA其實是一種不同的的開發(fā)思路，用規(guī)范的接口、標準的服務(wù)來定義控制器，方便靈活的變化升級。
雖然一直相提并論，但實際SOA的思路與現(xiàn)在以太網(wǎng)、DDS等概念沒有必然的聯(lián)系。傳統(tǒng)汽車上最典型的面向服務(wù)思路就是OBD的車載診斷。只要滿足14229的標準，用任何一款診斷儀插上OBD，就可以讀它的故障信息或進行其它一些操作。這就是一種典型的面向服務(wù)的架構(gòu)，所以面向服務(wù)并不是以太網(wǎng)的專利，在汽車行業(yè)一直就有，只不過現(xiàn)在隨著以太網(wǎng)的興起，將這個事情實現(xiàn)的便利性和它的可用性大大加強了。
將來對于控制軟件的發(fā)展趨勢：
第一是標準化，隨著越來越多的開發(fā)，就像診斷協(xié)議一樣，對于一些應(yīng)用層要用的信號的命名、函數(shù)原語、調(diào)用方式都會有組織調(diào)出來形成標準化，盡量實現(xiàn)不同企業(yè)之間的標準化應(yīng)用。
第二個是信號在車里會有多源。例如車速當下基本都從ESP這個控制器拿，將來車上SOA的話，電機轉(zhuǎn)速可以換算一個車速，ESP可以根據(jù)輪速算一個，有衛(wèi)星和導(dǎo)航的話，導(dǎo)航還可以算一個車速。當然這幾個車速信號精度和刷新頻率等是不一樣的，但是如果作為一個控制功能的開發(fā)者而言，只要信號服務(wù)質(zhì)量即QoS滿足功能要求，其實從哪里來并不重要。
第三是功能的原子化，這是軟件開發(fā)的常用定義，就是高內(nèi)聚、低耦合，每個軟件功能單元把自己包的越來越嚴實，越來越是獨立的功能塊，而盡可能減少相互之間的耦合關(guān)系。
最后第四就是分級分域，按照不同的層級、不同的權(quán)限、不同的時效，對車內(nèi)所有服務(wù)化的信號流和調(diào)用關(guān)系做管控。
當SOA發(fā)展到一定程度后，車可能就是下一個智能終端實體。舉個例子，將來車內(nèi)可能會有這樣一個APP，它獲取了讀取用戶的駕駛習(xí)慣這個權(quán)限，就像安卓一樣；它還可以讀取電池的信息，可以獲取電池的溫度，可以獲取驅(qū)動水泵和一定范圍內(nèi)PTC加熱的權(quán)限。它就是一個獨立的功能模塊，甚至可以把它放到車企的應(yīng)用商店里去下載。只要使用了這個應(yīng)用，例如在冬天，如果用戶上下班只是短途低速行駛，就可以根據(jù)實際行駛需求，控制電池的加熱溫度，而不是始終以一個固定的較高溫度目標去加熱。這個過程中可以大大的將實際使用能耗降下來，全過程把云、車構(gòu)成一體，形成完整的閉環(huán)系統(tǒng)。
（轉(zhuǎn)載）
