??01.前言

底盤系統存在大量連續非線性特性的控制邏輯，同時對整車安全有著至關重要的作用，在實車測試(特別是實車動態性能測試)之前更好更準確的進行臺架級測試，能大大降低實車測試風險和成本，所以其系統功能/性能測試歷來是一個較為復雜且重要的課題。

現如今，隨著各個主機廠在底盤開發業務上不斷延伸，以及EE架構的不斷升級，現有的測試系統越來越難滿足新的需求，主要體現在：

1、底盤內各個系統功能的關聯性越來越強，底盤域控單元的開發已經在各個主機廠啟動，傳統的單一HIL測試臺架（懸架/制動/轉向）無法完成底盤域控功能的相關測試。

2、各個主機廠對車輛的功能迭代速度的比拼進入了快車道，要求軟件能夠敏捷開發/交付，從而需要構建CT體系以快測試來完成軟件的驗證，但現有的大部分HIL測試臺架，自動化測試覆蓋率不高，無法達成這一要求。

3、智駕等技術的不斷成熟，導致與之相關的底盤系統要配合完成功能實現，越來越多的主機廠希望這部分軟件或是所有底盤軟件進行自主化開發，以實現軟件的快速迭代以及核心技術掌控，從而對測試臺架帶來了軟件開發過程中的debug/仿真需求。

4、新一代EE架構下，底盤系統強人機交互的功能往往被剝離并上移到基于SOA的域控單元。傳統的HIL臺架已經無法完成。

為了應對上述問題，底盤系統需構建了新一代的系統測試臺架，在解決上述問題的同時，在其它方面也帶來提升（具體見后續能力詳解）。

02.系統設計方案

2.1、測試范圍/目的

底盤系統測試臺架的主體為硬件閉環設備+車輛動力學模型+測試工程，主要作用為：

①、支持廣義全自動化測試；

②、包含平臺化的設計概念；

③、全程支持軟件的自主化開發；

④、支持部分駕駛感受主觀評估測試；

2.2、設計方案

臺架分為：制動系統測試臺架、轉向系統測試臺架、懸架系統測試臺架三個部分，同時三個部分可以通過硬件耦合+底盤系統測試工程形成底盤系統測試臺架，從而共計四套測試系統。如下所示：

圖1

每個系統分為三個層級：

a、軟件級：用于驗證內部邏輯的軟件閉環

b、信號級：通過硬件仿真設備達成硬件仿真閉環

c、系統級：控制機械負載施加反向激勵及模擬駕駛員控制輸入從而達成系統閉環

圖2

其中：

每個系統都支持軟件閉環；

每個系統都支持硬件仿真閉環；

每個系統都支持系統閉環；

三個等級的測試，不會對所需組件進行嚴格區分，比如系統級測試也會使用部分仿真設備資源；

2.3、注意

①、目前國內少有成熟的懸架系統（特別是空簧系統）動力學閉環仿真模型可借鑒，開發難度較大，需要和整車實際情況進行反復對比，以擬合出盡可能相近的特性曲線。

②、本文并未提及任何關于完成此臺架的實現手段（硬件方案、軟件方法等），僅闡述新一代臺架需達成的目的及實現該目的方法論。原因在于：不同供應商/主機廠對于系統測試臺架的定位和賦予的職責使命不盡相同，從而需要不同的軟/硬件方案配合完成其目的。

③、部分通用模塊可以委托第三方開發，但涉及功能/算法的部分，必須具備自己開發的能力：

編制自動化代碼的過程可以加強對功能的理解，反向校驗功能設計的同時，提升團隊能力；

復雜邏輯case的實現，需要對功能的深度理解，如果委托第三方，需要花費很多時間闡述要求；

很多測試case的驗證方法，強依托于實現的邏輯，如果將這些邏輯開放給第三方，有泄密的風險；

為了更好地支持軟件開發，系統臺架應具備實時調整測試case的能力，自己具備相應能力，可以大大降低失控風險；

03.底盤系統測試臺架能力詳解

3.1 支持廣義全自動化測試

區別于狹義的自動化測試的概念(這是老生常談的議題，這里不再繼續詳細展開)，此底盤系統自動化測試臺架，不僅包含測試用例的自動化執行，更著重于實現各個環節的測試任務一鍵式達成，具體體現為：

① 支持實車問題的自動化注入

偶發性的實車問題歷來為工程師所頭痛，其隨機性、無序性等特點給工程師帶來了很大的分析難度。一個有效的解決此類的問題的方法是在臺架上復現此問題，從而可以通過單步Debug的方式快速鎖定問題。

本系統在導入實車數據后，通過多次逼近的方法不斷快速縮小實車信號和仿真信號的時間差并控制在10ms內，同時利用過程預判的機制，將臺架和實車的物理量值偏差控制在1%以內，從而有效復現故障場景，以期復現故障，加速問題解決。

② 測試工具鏈的全棧打通

打通測試上下游工具鏈，達成一鍵式自動化測試，可以大大減少人為干擾和測試時間，提高測試效率和準確度。具體細節如下圖3所示：

圖3

其中需要注意的是：

a、本設計中自動化工具鏈的起點為被測軟件上傳到了共享盤，在這之前關于軟件的自動化加密、壓縮等暫不考慮；

b、通過遠程控制啟動測試以達成暗燈測試，當然也可以通過檢測軟件是否更新來自動觸發測試進程；

c、項目配置文件中，應包含被測內容的可選范圍，以應對不同的測試需求，比如：新軟件中僅僅軟件版本號發生了改變，測試時不應該加入故障注入等測試項目（具體見本3.1章節第⑤條）；

d、關于測試結果：測試報告為自動生成；時刻錄取過程trace及控制信息；問題上傳到問題管理系統時，應附帶trace并指出異常出現的具體時間；

e、問題出現的頻次、概率等的信息統計，由問題管理系統進行維護，這里不進行闡述；

③ 輸出結果為連續性特性功能的自動化測試（動態性能自動化測試/仿真）

底盤域的一些動態控制功能，其表現出來得輸出特性多為連續非線性。常規的測試手段無法準確判定其是否達成設計目標，基于此，我們采取下述方法來完成驗證目的：

a、采用多點采集/判斷的方式，對連續性執行結果進行多次仲裁；

b、將采樣點的時間及輸出有效值范圍進行參數化處理；

c 、通過百分比或是絕對值的方式限定有效值雙死區范圍；

d、測試/仿真的結果能夠做橫縱向對比，這一點尤為重要！

④ 支持ECU 特有測試用例的自動化測試

這類測試往往基于被測單元的固有特點，很難通過其它手段（集成測試/實車測試等）測試，比如：功能全部激活時所表現出的最大CPU 使用率、Bus load >95%時對高功能安全等級的功能的影響等。

⑤ 被測單元的測試范圍有可選擇性

不同測試目的下，被測單元的測試范圍也不同。整個系統測試工程應留測試case的選擇配置選項（如下圖4示例），或是通過的測試類型進行配置化管理（如下圖5示例）。

圖4? ? ? ? ??圖5

同時，因為底盤系統的ECU都會進行大電流控制，這種大電流控制的測試時間往往受限于ECU/硬件的散熱性以及其固有的器件保護機制。基于此點的考慮，設計者需要充分考慮為提升測試效率而做出的測試case選擇性配置需求。

⑥ 測試case代碼的自動生成

理論上講，測試case代碼的自動生成是自動化工具鏈的一環，此處把此條目再次單獨闡述，除了其在整個工具鏈上下游位置關鍵、任務量最大外，還尤為需要注意下述幾點：

a、區別于一些BSW等的共性測試，ECU功能測試需要開發者對各自產品功能非常熟悉，以能夠較好完成case的實現及平臺化的設計；

b、開發者應該根據實際的開發情況，制定測試case的錄入規則，否則腳本語言無法識別無序的case描述從而無法達成自動代碼生成；

c、因為底盤系統的部分性能測試步驟比較復雜，模塊化、圖形化的編程方式有時很難完成此種case的測試實現，這里推薦使用coding的形式來完成自動代碼生成。

⑦、參數的自動導入

a、不同項目/平臺有著不同產品特性差異，需要通過產品特性參數來達成可配；

b、因為上述不同的特性差異，測試時同樣需要調整測試參數來界定有效輸出范圍；

這兩種參數需要在測試前由產品工程師及測試工程師分別完成，完成后自動導入到測試系統完成測試。

⑧、支持底盤域聯合功能測試/底盤域控制器功能測試

3.2、平臺化的設計概念

由于底盤系統測試臺架一般投入較大、開發周期較長、開發復雜度較高，通常情況下需要盡可能考慮讓臺架承接更多的項目/平臺測試需求等，具體如下：

①、支持底盤域聯合系統聯合測試

一般情況下，供應商僅能夠提供底盤系統內單個子系統的開發/測試能力，所以底盤域控功能的測試工作一般由OEM完成。目前極氪的整個底盤系統測試臺架的設計采用由三個子系統組合完成的方式實現，具體為：懸架、制動、轉向的系統測試臺架可以單獨運行，提高臺架的適用效率。當有底盤域聯合系統測試需求時，將三套系統臺架進行通訊連接，并使用基于底盤系統測試的工程，即可完成該測試，以滿足底盤域功能測試的需求。

②、平臺/項目/車輛配置間差異化需求的解決方案

a、開發BOB工裝，完成不同ECU接口定義轉接；

b、開發虛擬網關，完成不同通訊定義的轉發，特別是針對基于中央超算的新一代EE架構，需要開發基于以太協議的仿真網關，并開發上移至中央超算的邏輯功能的測試case，來完成最終的測試；

c、臺架保留更換ECU及相關執行機構的能力，以應對不同項目采用不同供應商的產品帶來的差異；

d、測試工程通過導入不同配置參數列表，以應對差異化的測試需求；

③、軟件閉環和硬件閉環可快速解耦

由于本系統測試臺架承擔了支持軟件/算法自研的任務，所以要求硬件仿真閉環可以和系統閉環間迅速解耦，以便單獨使用硬件仿真閉環系統（或稱為：桌面級HIL/信號級HIL）來支持軟件的快速調試/仿真。

④、提前預留動力等其它域的擴展

a、臺架預留動力域硬件接口，特別是通信接口；

b、梳理和底盤域有交互的其它域的相關功能，并進行case設計，以提前識別相關需求；

c、完成動力等域的動力學模型搭建；

3.3、全程支持軟件的自主化開發

底盤系統邏輯復雜，底盤電控系統的主流供應商一般為國外企業，其對國內OEM形成技術性壁壘。為了打破此種狀況，極氪底盤電控團隊正在基于下一代EE架構進行底盤全學科及底盤域控的軟件/算法自主性開發。作為開發中重要的一環，系統測試臺架可以有效的支持整個開發過程。具體為：

①、輔助完成功能安全的設計

對功能安全case進行仿真驗證，輔助驗證case設計是否合理。

②、功能需求設計的檢查/校驗

測試case的設計遵從正確輸入時功能達成、異常輸入時輸出表現合理、故障注入時結果在預期內的原則，來覆蓋所有功能要求。此原則下，測試case設計過程會對功能需求內容進行反向檢查/校驗。

注意：售后或下線檢測功能等也是功能需求的一部分，不應該被忽略。

③、特殊功能/算法的臺架驗證

作用主要體現在：

a、提前于造車計劃，進行功能、性能的初步驗證；

b、危險case的先期驗證，比如：100km/h速度下大弧度轉彎時，底盤各系統對車輛防側傾的作用占比及翻車風險評估；

c、ECU參數的初步標定；

④、包含手動測試界面，用于軟件/功能單步調試

手動測試工程包含所有輸入輸出的控制按鈕以及對應內部邏輯處理，以確保可以手動進行功能的單步調試。

支持范圍：轉向/制動/懸架子系統，或是底盤域控制器系統。

⑤、動力學仿真模型可復用于SIL/MIL測試

以用來加快功能/算法開發進度。

3.4、支持部分駕駛感受主觀評估測試

如題，本系統可以支持譬如踏板感、方向盤手力等主觀功能的測評。

04.??總結

隨著國內汽車工業的發展，主機廠在底盤電控開發中的責任占比越來越高。為了有效把控軟件開發進度，提高軟件交付質量，系統測試模塊除了考慮常規功能的自動化測試外，亦應主動承擔更多的任務：努力推動供應商/自研團隊基于CD/CI/CT來實現軟件的迭代和交付、支持問題分析、推動問題解決進度等。

尤其在底盤領域，為了使主機廠在電控開發上占據更加主動地位，達成更快速的功能實現，更應該積極進行掌握XYZ軸向控制原理，建立用于算法動態仿真的動力學模型等等，以支持主機廠的復雜功能/算法自研工作。

基于上述目的，本文拋磚引玉，闡述基于極氪下一代EE架構的底盤系統測試臺架設計方案。

底盤電控系統的自主開發其路漫漫，希望測試同事能從本文得到一些啟示，找準各自在軟件開發的定位，并依此 “上下而求索”。

編輯：黃飛

?