日前，天際汽車自主開發了VBU控制器，將VCU和BMS整合到一起，實現軟硬件的自主開發應用。這不僅打破了專業技術的壁壘，同時在天際汽車目前上市的ME5增程車和純電動車上都實現了量產。該系統架構實現了電池管理系統，從硬件上面脫離，不再跟隨電池包，而是以VBU為主，變成了置身于電池包外的控制器，賦予了非凡的意義。

在傳統控制系統中，不光是動力系統控制，VCU、EMS、MCU、BCM等等控制器都脫不開輸入，中間邏輯處理，最后是輸出的框架。輸入典型包括數字量、模擬量采集、通訊輸入；輸出典型包括低邊、高邊驅動，以及通訊總線的輸出。將來會不會存在一種專用于傳感執行的控制衛星板的概念，衛星板可能分會為A/B/C型，每一型會根據最優配置的原則，在不浪費的情況下配置一些廣泛使用的、特定數量的接口，具有一定的驅動能力，以及通訊的能力。基于該前提，就把邏輯算法，更多上提，提到核心板（高算力的SOC做異構的芯片）。

在這種劃分下，電子電氣構架上面中心控制器將更貼近于用戶感知功能，衛星板則更多和硬件被控對象，如電池包、電機、OBC、DC等結合。

天際汽車認為將來對于車載的控制系統硬件技術趨勢而言，從低速總線通訊會越來越多的向高速總線過渡，另外會從有線向無線過渡。硬件上會越來越多融合消費電子和工業領域的WIFI、4G、高速串行技術。

車輛控制功能融合和重新組織

過去燃油車沒有VCU，所有都集成在EMS中，所有駕駛中的扭矩、油門、制動、檔位，都通過EMS完成。發動機被電機替代后，增加了電池需要進行充放電模式及上下電過程的管理，以上功能需要一個控制器去實現，而VCU承擔了這些功能。同時，電動車的的能量和功率協調也需要控制器進行計算，再疊加信息處理、安全監控系統等內容，最后就集成為VCU控制器。

而現在反過來想，例如VCU的縱向控制功能，是在駕駛員需求扭矩解析的基礎上，對電驅動系統發控制指令實現。無論從VCU發出，還是從其它控制器發出，從單純的縱向控制需求而言，完全可能被其它控制器取代，只需把駕駛員及其它縱向扭矩的的輸入信息獲取和解析。再如，熱管理系統在電動車上更加復雜，乘員的空調舒適溫度與關鍵部件的適宜溫度訴求應相互協調而來，相關的泵、閥、風扇、壓縮機、加熱器等部件管理也具備與電池管理系統或其它控制器融合的可能性，而不需要綁定在VCU上。而像充放電模式、上下電過程等協調，本來就是跟著電池而來，自然是可以聚焦于電池管理的控制器上。VCU剩下的信息處理、安全監控、診斷系統，其實是每個控制器都需要，可以算平臺功能。因此大膽預測，未來VCU控制器作為獨立控制器存在的意義不大。

目前天際汽車將VCU和BMS兩個控制器進行融合。對于電動車而言快充、慢充、放電、遠程喚醒這幾個模式本就是一體的，結合也顯得非常自然。總而言之，將兩個控制器相結合，能夠創造出很多便利性，將原來大量需要通過交互和溝通的過程，變成控制器內部變量的傳遞，對整個提高系統的控制效率起到了極大的幫助。

隨著車輛控制功能融合和重新組織，主機廠和供應商之間的關系將被重新定義。過去主機廠是找許多零部件廠商攢一個功能，基本上各個零部件會傾向于去用自身平臺功能，不愿意修改，所以主機廠就要居中協調幾家的廠商來合起來實現功能，過程非常的冗長和復雜，并且更改的自由度小，基本上基于現有的平臺做小的調整。在域控制器模式下底層軟硬件開發對于各個ECU之間的功能，提出更加精準有針對性的需求。

所以將來在產業鏈上的分化將會呈現主機廠越來越多的強調掌握接口，去差異化，與為用戶創造價值，對于供應商而言，可能是更多的強調制造標準的接口，達到標準和可靠。

控制功能承載的主體往云端拓展

天際汽車現在車上都配備T-box，有自己的企標上傳規則和服務器，把一些數據存下來，行業很多乘用車企業也是這么做的。

天際汽車計劃在云端為每輛車建檔，以每輛汽車的VIN碼為標識。給每輛車分配每個控制器的數據儲存單元。數據存儲器里面存三類數據，第一類是周期性的重要數據，第二類是特定事件發生時的捕捉數據，此外還有第三類通過車載控制器進行邊緣計算提煉出的關鍵特征數據。

 有了數據之后，就是計算部分。基于云端數據進行計算，可以抽象駕駛員的駕駛風格，電池的健康狀態等，之后甚至可以去下發標定，把當前控制器里的標定值進行修改，并且把變更存檔在云端。從行業技術狀態而言，目前各個環節的基礎技術棧都已經具備，只需要進行貫通就可以實現。

天際汽車希望做到目標是出廠時有一致性標定，在每次運行的時候，有云端的信息過來就按照云端的信息進行調整，沒有云端的信息過來它就是原來車上的控制器，只有把車上和云上結合到一起，才是一個完整的控制系統。每輛車隨著使用，會調整一些特征的特性，最后實現一車一標定的概念。

SOA面向服務的架構

目前汽車行業內大部分還是非面向服務架構，控制系統里面在進行一個項目之前，要把開頭給定義好，任何一方改一個信號，要涉及到多方去改矩陣，牽一發而動全身。現在倡導的SOA其實是一種不同的的開發思路，用規范的接口、標準的服務來定義控制器，方便靈活的變化升級。

雖然一直相提并論，但實際SOA的思路與現在以太網、DDS等概念沒有必然的聯系。傳統汽車上最典型的面向服務思路就是OBD的車載診斷。只要滿足14229的標準，用任何一款診斷儀插上OBD，就可以讀它的故障信息或進行其它一些操作。這就是一種典型的面向服務的架構，所以面向服務并不是以太網的專利，在汽車行業一直就有，只不過現在隨著以太網的興起，將這個事情實現的便利性和它的可用性大大加強了。

將來對于控制軟件的發展趨勢：

第一是標準化，隨著越來越多的開發，就像診斷協議一樣，對于一些應用層要用的信號的命名、函數原語、調用方式都會有組織調出來形成標準化，盡量實現不同企業之間的標準化應用。

第二個是信號在車里會有多源。例如車速當下基本都從ESP這個控制器拿，將來車上SOA的話，電機轉速可以換算一個車速，ESP可以根據輪速算一個，有衛星和導航的話，導航還可以算一個車速。當然這幾個車速信號精度和刷新頻率等是不一樣的，但是如果作為一個控制功能的開發者而言，只要信號服務質量即QoS滿足功能要求，其實從哪里來并不重要。

第三是功能的原子化，這是軟件開發的常用定義，就是高內聚、低耦合，每個軟件功能單元把自己包的越來越嚴實，越來越是獨立的功能塊，而盡可能減少相互之間的耦合關系。

最后第四就是分級分域，按照不同的層級、不同的權限、不同的時效，對車內所有服務化的信號流和調用關系做管控。

當SOA發展到一定程度后，車可能就是下一個智能終端實體。舉個例子，將來車內可能會有這樣一個APP，它獲取了讀取用戶的駕駛習慣這個權限，就像安卓一樣；它還可以讀取電池的信息，可以獲取電池的溫度，可以獲取驅動水泵和一定范圍內PTC加熱的權限。它就是一個獨立的功能模塊，甚至可以把它放到車企的應用商店里去下載。只要使用了這個應用，例如在冬天，如果用戶上下班只是短途低速行駛，就可以根據實際行駛需求，控制電池的加熱溫度，而不是始終以一個固定的較高溫度目標去加熱。這個過程中可以大大的將實際使用能耗降下來，全過程把云、車構成一體，形成完整的閉環系統。