商用車電子電氣架構設計的思考

在上述電動化、智能化、網聯化趨勢下，當前商用車也正從分布式E/E架構、向域集中式E/E架構演進，同時部分新勢力商用車企業已從功能域集成向跨域融合以及區域融合演進，但是不同企業會選擇不同的功能集中及融合方案，本文想在此探討企業如何選擇適合自己的架構拓撲。

2.1 物理解耦

商用車駕駛室通常通過懸置連接底盤車架，目前商用車市場情況，一款駕駛室開發出來以后通常要用很多年（甚至10年），然而底盤卻需要根據不同的車輛使用場景進行定制開發，例如礦區、港口、環衛、快遞、快運等，不同的場景對于底盤的軸距、驅動功率、驅動形式（4x2、6x4）都有不同要求，并且同一款駕駛室會適配不同的動力總成如純電動、燃料電池、天然氣動力、柴油等，因此為了保證不變與異變部分的解耦，在重卡電子電氣架構設計時要考慮駕駛室與底盤在功能和物理上的解耦；

因此商用車與乘用車區域控制器布置不同，商用車應該上下布置區域控制，即在駕駛室布置座艙區域控制器，在底盤布置底盤區域控制器，座艙區域控制器可承擔駕駛室相關設備控制，如燈光、雨刮、門鎖、車窗、座艙、空調、PEPS、藍牙等，同時可根據公司的產品策略，考慮將車身控制邏輯BCM部署在座艙區域控制器，還是整車控制器VDC，而底盤區域控制器可考慮集成底盤燈光控制（如倒車燈、制動燈、霧燈、側標志燈、側轉向燈等）、熱管理系統（電驅熱管理、電池熱管理、高壓部件熱管理）、底盤I/O Hub（儲氣筒氣壓傳感器）、底盤配電、TPMS等；

2.2 模塊化

例如燃料電池系統包含大量的傳感器（壓力傳感器、空氣流量傳感器、溫度傳感器等）及執行（氫氣噴嘴、空壓機、旁通閥、氫氣循環泵、水泵等），因此對于燃料電池控制器FCU來說，其需要一個Pin腳資源豐富的硬件，從降低線束復雜度的角度考慮，燃電系統控制器FCU應盡量安裝在電堆附近，并和電堆一起作為標準化模塊，因此在動力域功能融合時不建議將FCU集成進動力域控PCU中，而作為單獨的控制器，并保留其核心控制功能（進氣控制、氫氣控制、氫堆功率控制、電堆熱管理控制等）。

2.3 功能集中化

我在這里想說的是功能集中化的目標是要降低跨ECU交互的復雜性以及時延，以提高車輛的性能，并同時滿足功能軟件快速迭代的需求，而不是單純的控制器融合，以縮減控制器數量為目的，把相互之間聯系并不密切的功能放在同一個硬件上，表面上集中度更高，實際帶來了軟件開發集成的復雜性，同時成本上比采用相對標準化的控制器更高；

以對新能源商用車能耗影響較大的串聯式制動能量回收功能為例，其功能涉及多個控制器之間的高頻扭矩交互，首先整車控制器VCU需要結合動力電池的SOC以及可充電能力、電機的最大/最小可用扭矩、整車用電器的功率消耗等計算能量回收可用電扭矩，電控制動系統EBS接收駕駛員的制動踏板位置計算期望減速度，結合當前VCU發送的能量回收可用電扭矩，制動I曲線等計算前軸/后軸的制動力分配，同時優先將后軸的制動力轉換為電機的扭矩請求，并將電機扭矩請求發送給驅動控制單元，對于具有雙電機/三電機的驅動系統，驅動控制單元將接收到的電機回饋扭矩請求分配到不同的電機控制器，電機控制器控制電機進行制動，同時在電制動的過程中，驅動控制單元需要實時將實際執行扭矩反饋給EBS，在電制動不足時氣制動會立即進行補足，從而滿足駕駛員制動減速度的需求，為了滿足實時性要求，以上扭矩交互報文的周期通常在10ms，對于J1939 500bps的網絡帶寬來說有點不堪重負，同時因為傳輸鏈路過長，在一些極端場景（大油門加速然后切制動）電機回饋扭矩達到目標扭矩時間無法滿足制動性能需求，通常會導致EBS關閉串聯式制動能量回收功能，全部由氣制動來完成制動過程。

因此對于上述串聯式制動能量功能來說，如果能夠實現縱向驅動、制動的融合控制將是有益的，對于主機廠來說在目前集中式架構趨勢下如果能夠將能量管理、扭矩計算、扭矩協調、多電機扭矩分配、多變速箱檔位控制、制動能量回收控制、ESC等功能集成進車輛運動域控制器VMC（Vehicle Motion Control）將對車輛能耗降低、動力學性能提升（如VDC、TCS、ROP）等帶來價值，在傳統液剎、氣剎制動的時代，制動系統的控制由Tier1牢牢把控，主機廠很難在底盤域上實現整合集成，但是在下一代電子制動系統EMB （Electronic Mechanical Brake）到來時，其主控ECU可以融合進VMC，而橋控模塊、輪端執行電機可由供應商進行開發；

2.4 開放平臺構建

如1.3章節所說，圍繞商用車全生命周期服務，商用車車聯網的盈利模式更加清晰，但是如果每家OEM都構建自己封閉的生態系統，投入與產出將不對稱，同時對于車隊運營商來說管理來自多個品牌的車輛將是困難的，不同品牌的車型其車聯網設備、可提供的車輛數據都是不一樣的，如果要將不同品牌的車輛統一接入自己的車隊管理系統FMS（Fleet Management System）將需要帶來大量的重復開發工作，因此構建統一的數據共享標準，通過開放平臺將車輛數據共享給車隊運營商及第三方內容服務商將是有益的。

為了達成上述目標COVESA組織推出了VSS（Vehicle signal Specification），該規范旨在構建一個開放數據模型，旨在規范車輛數據（如車輛速度、車輛胎壓、車內照明燈），其核心理念在于提供一種易于理解且可在各種環境中被廣泛使用的規范，減少車輛數據的碎片化，促進商用車整個生態系統的發展。

而實現COVESA VSS當前還沒有廣泛應用的成熟方案，AUTOSAR組織在2024年發布了Adaptive AUTOSAR R24-11，AUTOSAR Automotive API 也在該規范中發布，AUTOSAR Automotive API實現了將Adaptive Application的服務接口內容轉換成標準的VISSv2（整車信息信號規范）接口的功能，在架構規范時可將Automotive API Gateway部署在高性能控制器上，如整車控制器VDC或高性能中央網關上，

由以上可知，對于商用車的整車控制器VDC通常不會融合底盤相關控制如VCU、TMS等，而更多是承擔整車的數據中心、信息中心、計算中心，可部署Ethernet GW、VMM、OTA Master、IDPS、RVDC、Data Collect、Automotive API Gateway等功能。

2.5 回歸生產工具屬性

與乘用車將座艙定義為“第二起居室”、成為懂情感、會思考的AI智能體不同，商用車更多的還是生產工具，作為生產工具其最核心的功能是提高生產效率、降低生產成本，從而推動生產力的發展，因此在進行智能座艙、智能駕駛的設計時，還是要回歸商用車作為生產工具的屬性，座艙影音娛樂、情感交互、個性化定制相關的功能在商用車上并不是強需求，同時對于智能駕駛，在滿足法規安全需求后，若不能真真切切的減員增效，其過多的輔助駕駛功能也不是必要的，除非像1.2章節所說的實現“技術-資本-場景”的商業閉環。