日前，天際汽車自主開發了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加熱的許可權。它就是一個獨立的功能模組，甚至可以把它放到車企的應用商店裡去下載。只要使用了這個應用，例如在冬天，如果使用者上下班只是短途低速行駛，就可以根據實際行駛需求，控制電池的加熱溫度，而不是始終以一個固定的較高溫度目標去加熱。這個過程中可以大大的將實際使用能耗降下來，全過程把雲、車構成一體，形成完整的閉環系統。
