分層與職業(yè)路徑)
從各個渠道加我的同學(xué)經(jīng)常問一個問題車載測試和HiL測試到底哪個門檻更高是不是HiL更高級其實(shí)這個問題背后藏著一個更大的主題——整個汽車研發(fā)V模型里的測試崗大體上可以分為哪幾類每一類玩的東西、用的工具、要懂的知識差別大到什么程度。我最早做臺架測試后來轉(zhuǎn)到HiL測試再后來帶測試團(tuán)隊跟車載測試工程師、HiL測試工程師、甚至底盤標(biāo)定工程師都有大量交叉協(xié)作。這幾年面試過的人少說也有上百個特別是在車載測試面試環(huán)節(jié)發(fā)現(xiàn)很多人都把HiL測試?yán)斫獬伞邦愃婆_架測試的升級版”還有不少人以為車載測試就是“在車上點(diǎn)點(diǎn)屏幕、看看導(dǎo)航”。這倆理解都跑偏了。今天這篇文章我就把車載測試和HiL測試的區(qū)別、各自的技術(shù)門檻以及它們在整個汽車研發(fā)V模型中的位置盡量講透。全程不繞彎子文章里我會穿插一些面試真題方向、實(shí)操經(jīng)驗以及我自己踩過的坑。1. 從V模型看懂車載測試與HiL測試的崗位定位差異1.1 V模型到底是怎么回事想搞清楚車載測試和HiL測試的區(qū)別繞不開汽車研發(fā)的V模型。很多轉(zhuǎn)行的人一聽到V模型就頭大覺得是個很大的概念其實(shí)它沒那么玄乎。V模型描述的是一套“從需求到驗收”的工程流程左邊是自頂向下做開發(fā)設(shè)計右邊是自底向上做集成測試驗證左右對應(yīng)起來就成一個V字。左邊從最頂層的整車需求開始逐級拆解成系統(tǒng)需求、子系統(tǒng)需求、軟硬件需求最后到軟件單元、硬件單元。右邊從最底層的單元測試開始逐級向上一層做集成測試、系統(tǒng)測試、整車驗收。這里面的核心思想是你右邊怎么做測試完全取決于左邊怎么定義需求兩邊是嚴(yán)格對應(yīng)的。測試不是開發(fā)完了才開始而是需求階段就要考慮怎么驗證。在V模型框架下車載測試和HiL測試的差異本質(zhì)上是驗證層級的差異。車載測試更多落在右側(cè)靠上的位置也就是在整車或者整臺樣車上做系統(tǒng)級驗證。HiL測試則落在右側(cè)靠中間偏下的位置把控制器取出來接到實(shí)時仿真環(huán)境里做驗證所謂硬件在環(huán)硬件是真實(shí)的控制器環(huán)路里跑的是虛擬的車。這個位置差異決定了后面所有東西都不一樣。1.2 兩個測試在V模型里的位置切分我接觸過不少項目V模型在每家車企、每個零部件供應(yīng)商那里的裁剪方式都不一樣但大體上可以把測試層級分成五層單元測試與靜態(tài)測試主要針對軟件函數(shù)和模型工具是Simulink、Polyspace、Ctest這些。軟件集成測試驗證的是軟件組件之間的通信和數(shù)據(jù)交互很多用MiL或SiL方式做。HiL測試把真實(shí)控制器硬件放進(jìn)仿真環(huán)境驗證硬件與軟件交互、傳感器/執(zhí)行器信號、總線通信甚至是故障注入。臺架測試或系統(tǒng)集成測試這一步是控制器連上真實(shí)執(zhí)行機(jī)構(gòu)和環(huán)境模擬設(shè)備比如發(fā)動機(jī)臺架、電池臺架、電機(jī)臺架硬件是真的但整車環(huán)境還不完整。整車測試與實(shí)車路試也就是Road Test車輛在真實(shí)道路上跑測試內(nèi)容包括功能、性能、可靠性、耐久性等。從這條鏈上看HiL測試屬于控制器級別的驗證層車載測試往往泛指整車級別的驗證層。當(dāng)然有些公司叫法不一樣比如有的把HiL也歸到車載測試崗有的把臺架測試叫車載測試這都很常見。但你不管叫什么技術(shù)架構(gòu)是不會變的差異核心在于HiL是“把控制器從車上拆出來測”車載整車測試是“在整車上把所有控制器聯(lián)起來測”。1.3 本質(zhì)區(qū)別對象、環(huán)境與目的我習(xí)慣用三個維度來區(qū)分測試對象、測試環(huán)境、測試目的。HiL測試的對象是被測控制器俗稱ECU或VCU也有叫域控制器的它通過線束接到一套實(shí)時仿真系統(tǒng)上。仿真系統(tǒng)給控制器提供虛擬的傳感器信號同時采集控制器輸出的執(zhí)行器信號讓控制器感覺自己“還連在車上”。測試環(huán)境是實(shí)驗室是虛擬與真實(shí)混在一起的半實(shí)物環(huán)境。車載測試的對象是整車是幾十個控制器連同線束、傳感器、執(zhí)行器都在的真實(shí)系統(tǒng)。測試環(huán)境是實(shí)車可以是環(huán)境倉、試驗場也可以是公開道路。測試目的也不同HiL測試主要驗證控制器功能邏輯是否正確、軟件是否有Bug、信號鏈路是否正常、故障處理是否可靠車載測試主要驗證整車級的交互、系統(tǒng)匹配、用戶感受、極端場景下的表現(xiàn)、網(wǎng)絡(luò)穩(wěn)定性、電子電氣架構(gòu)的實(shí)際表現(xiàn)。打一個比方HiL測試就像是給一套剛組裝好的電腦主機(jī)單獨(dú)接上模擬顯示器、模擬鍵盤驗證主板、CPU、內(nèi)存、顯卡這套東西邏輯上有沒有問題。車載測試則是把電腦接上真實(shí)顯示器、真實(shí)鍵盤鼠標(biāo)、真實(shí)路由器開機(jī)跑各種軟件看體驗好不好、速度達(dá)不達(dá)標(biāo)。HiL保證“主機(jī)沒毛病”整車測試保證“整臺機(jī)器好用”。2. 車載測試到底在測什么從臺架、實(shí)車到路試2.1 車載測試的四大核心方向車載測試這個名字在招聘網(wǎng)站上被用得很泛有的公司把HMI功能測試叫車載測試有的把整車CAN網(wǎng)絡(luò)測試叫車載測試有的把ADAS路試也叫車載測試。實(shí)際上按工作內(nèi)容可以粗分為四類。第一類是功能測試這是最普遍的方向。座艙里的導(dǎo)航、語音、藍(lán)牙、倒車影像、車控App、空調(diào)界面每一個功能都要一條條去驗證。這個方向門檻相對低很多零基礎(chǔ)轉(zhuǎn)行的人都是從這里入手的。第二類是網(wǎng)絡(luò)與診斷測試這就要看CAN、CAN FD、LIN、FlexRay、車載以太網(wǎng)這些總線了你需要用CANoe或PCAN去抓報文、看信號、發(fā)診斷請求門檻明顯上一個臺階。第三類是整車性能測試偏向于動力性、經(jīng)濟(jì)性、制動、轉(zhuǎn)向、NVH、熱管理等經(jīng)常和底盤標(biāo)定、動力總成標(biāo)定的工程師一起干活這個方向?qū)囕v工程背景的要求比較高。第四類是ADAS測試與自動駕駛路試需要懂傳感器原理、場景設(shè)計、法規(guī)標(biāo)準(zhǔn)目前在所有方向里最火薪資天花板也高但門檻和風(fēng)險也都高。多數(shù)車載測試工程師實(shí)際是把第一類和第二類混著做的尤其是新勢力車企和Tier1的測試工程師一個人要覆蓋功能、網(wǎng)絡(luò)、診斷三塊。傳統(tǒng)主機(jī)廠反而分得更細(xì)。2.2 車載測試的日常工具與工作方式車載測試最常用的工具第一梯隊是Vector家的CANoe這基本是總線測試和診斷測試的標(biāo)配不會用CANoe都不好意思說自己做車載測試。第二梯隊是CANalyzer、PCAN、PicoScope示波器、同星、周立功的CAN卡。第三梯隊是診斷儀、萬用表、鉗流表、OBD轉(zhuǎn)接頭。做整車網(wǎng)絡(luò)測試的時候CANoe加上一個VN1640或VN7610接口卡配合整車線束轉(zhuǎn)接盒就能把整車CAN網(wǎng)絡(luò)上的報文全部實(shí)時監(jiān)控下來。真車測試還要帶一個很重要的東西——數(shù)采設(shè)備用陀螺儀、GPS天線、溫度傳感器、電壓采集模塊把車輛狀態(tài)和駕駛行為數(shù)據(jù)同步錄下來。實(shí)際工作中車載測試工程師通常按照測試用例來執(zhí)行一條一條過。一個DTC診斷測試用例可能是上電、把OBD口接上診斷儀、讀版本信息、清故障碼、設(shè)置某個故障條件、等60秒、再讀故障碼、驗證狀態(tài)位。這些操作看起來簡單但重復(fù)性非常高真正考驗的是你有沒有耐心、做不做記錄、會不會報告異常。我見過太多人測出一個異常卻不記錄復(fù)現(xiàn)步驟等開發(fā)工程師問起來的時候完全說不清楚這種問題在測試行業(yè)是很致命的。2.3 車載測試崗位的實(shí)際門檻純功能類的車載測試崗位學(xué)歷門檻通常放得比較寬大專以上就可以核心是會用工具、會看日志、會提Bug單、能寫測試報告。但網(wǎng)絡(luò)與診斷方向就不一樣了你得懂CAN協(xié)議棧、UDS診斷協(xié)議、DBC解析、J1939還要會用CANoe的CAPL腳本做一些簡單的自動化這個門檻會濾掉一大半人。如果你要往ADAS路試和自動駕駛測試發(fā)展那還需要懂傳感器原理、復(fù)雜場景設(shè)計、數(shù)據(jù)采集與標(biāo)注流程、法規(guī)倫理更重要的是你得能開車跑各種極限工況。ADAS路試的工程師你要是沒在高速上測過AEB沒在雨霧天測過ACC你都不好意思說自己干過這塊。門檻不只是技術(shù)還有膽量和體力一跑就是幾個小時車精神高度集中返程還要整理數(shù)據(jù)非常累。3. HiL測試的深層拆解半實(shí)物仿真才是硬骨頭3.1 HiL測試系統(tǒng)是怎么組成的HiL測試的核心是一套實(shí)時仿真系統(tǒng)行業(yè)里主流方案是dSPACE SCALEXIO、NI PXI、Vector VT System國產(chǎn)的也有經(jīng)緯恒潤的HiL、ETAS的LABCAR這幾年國產(chǎn)化的比例提高了很多。一套完整的HiL測試臺架至少包含四大部分。第一部分是實(shí)時機(jī)這是整個臺架的大腦它運(yùn)行著車輛動力學(xué)模型、電機(jī)模型、電池模型、發(fā)動機(jī)模型等被控對象模型以固定步長實(shí)時計算一般為1毫秒或更小。第二部分是IO板卡與信號調(diào)理包括模擬量輸入輸出、數(shù)字量輸入輸出、電阻仿真、PWM捕獲與生成、頻率信號等負(fù)責(zé)把控制器發(fā)出的真實(shí)信號和模型計算出的虛擬信號進(jìn)行交互。第三部分是故障注入單元也叫FIU通過繼電器矩陣把信號線開路、短路、對地短接、對電源短接用來模擬各種電氣故障這是HiL測試最核心的價值之一。第四部分是負(fù)載箱和傳感器仿真盒用來模擬噴油嘴、繼電器線圈、電機(jī)負(fù)載這些功率器件以及溫度、壓力傳感器等。除了硬件軟件部分半壁江山是模型和自動化環(huán)境。模型用Simulink搭建再編譯部署到實(shí)時機(jī)上。自動化環(huán)境用ECU-TEST、TestStand或者Python腳本編寫測試序列自動執(zhí)行測試用例、自動判斷Pass/Fail、自動生成報告。很多人以為HiL測試就是“學(xué)會開臺架”其實(shí)真正難的是模型和自動化這部分。3.2 為什么一定要做HiL測試有人會問反正最后要上車路試為什么還要花幾十萬上百萬搭一套HiL臺架做半實(shí)物仿真答案很簡單安全和成本。很多故障場景在真車上是不能復(fù)現(xiàn)的或者說復(fù)現(xiàn)成本極高。舉個例子如果你要驗證整車控制器對BMS上報的絕緣故障怎么響應(yīng)你在真車上很難精準(zhǔn)地制造一個絕緣故障就算你能做也很危險。但HiL臺架在軟件里控制模型狀態(tài)然后通過故障注入單元把信號線弄斷控制器就會認(rèn)為真的出現(xiàn)絕緣故障了你可以反反復(fù)復(fù)試一百遍。再比如驗證ABS或ESP在低附著路面上的控制邏輯在實(shí)車上你需要在冰面上測試費(fèi)時費(fèi)力但HiL臺架可以通過修改路面附著系數(shù)模型在10秒內(nèi)進(jìn)行多組工況切換。還有一個很實(shí)際的目的測試前置和自動化回歸。軟件開發(fā)是迭代的每發(fā)一個版本你都得做一輪回歸測試。在真車上做回歸一是車只有幾臺資源排不過來二是環(huán)境不可控今天下雨明天暴曬測試結(jié)果不一定是軟件問題還是環(huán)境差異。HiL臺架可以7乘24小時自動跑測試晚上人走了臺架還在跑用例第二天早上看報告就行。我?guī)У腍iL項目一個控制器一輪回歸3500多條用例在臺架上不到兩天就能跑完放在實(shí)車上至少干兩個星期。3.3 電池HiL測試和車載以太網(wǎng)HiL測試的特殊性這里重點(diǎn)說說電池HiL測試因為電池相關(guān)的熱搜詞在車載測試面試?yán)锍霈F(xiàn)頻率非常高。電池HiL和傳統(tǒng)控制器HiL最大的區(qū)別在于被測對象通常不是BMS主控板這么簡單而是BMS從板、主板、絕緣監(jiān)測、電流傳感器等一套系統(tǒng)很多場景還要把真實(shí)的電池模組或電池包接進(jìn)來形成所謂“電池HiL”的混合測試系統(tǒng)。電池HiL需要仿真電池單體的電壓和溫度變化這里要求非常高的精度和實(shí)時性。一個電芯的模型要能模擬開路電壓、內(nèi)阻、容量衰減、溫度特性150串電芯的電壓通道要能同步刷新到毫秒級。我做電池HiL時踩過一個大坑某次測試放電均衡功能模型里的電芯電壓是按照1秒步長更新的結(jié)果均衡打開后真實(shí)的BMS電流控制完全不收斂電芯電壓在模型和真實(shí)采樣之間不停跳變。后來才發(fā)現(xiàn)模型的實(shí)時性不足我們把步長改到50毫秒內(nèi)阻參數(shù)按熱模型耦合修正后均衡邏輯才穩(wěn)定下來。車載以太網(wǎng)HiL測試是這幾年冒出來的方向。傳統(tǒng)總線是CAN和LIN帶寬和速率有限但智能座艙和ADAS帶來的數(shù)據(jù)量暴漲車載以太網(wǎng)已經(jīng)成為主干網(wǎng)。做以太網(wǎng)的HiL難點(diǎn)在于怎么把以太網(wǎng)報文延遲、幀丟失、重傳這類網(wǎng)絡(luò)質(zhì)量問題在仿真環(huán)境里復(fù)現(xiàn)出來還要和自動駕駛的感知決策模型聯(lián)動。我記得有一次給客戶的智駕域控制器做以太網(wǎng)HiL測試?yán)锩媾芰薃EB算法和環(huán)視攝像頭測試場景是夜間行人橫穿結(jié)果以太網(wǎng)網(wǎng)絡(luò)擁堵造成感知幀延遲80毫秒算法決策直接晚了雖然最終通過虛擬OBD抓到了根因但排查過程特別痛苦同時也讓我們認(rèn)識到以太網(wǎng)測試的仿真精度有多重要。3.4 HiL測試崗位的技術(shù)門檻HiL測試的門檻第一關(guān)是理解被控對象。你要是測電池相關(guān)的HiL你得懂電芯特性、SOC估算算法、均衡策略你要測底盤制動你得懂液壓系統(tǒng)、制動防抱死邏輯。很多新人在這一點(diǎn)上就卡住了以為HiL測試就是操作臺架其實(shí)不會建模不會標(biāo)定遇到模型和實(shí)車差異都不知道從哪下手。第二關(guān)是實(shí)時仿真技術(shù)。你得懂實(shí)時操作系統(tǒng)、仿真步長、模型的代數(shù)環(huán)問題、IO板卡的延遲和精度、甚至還要懂一點(diǎn)信號完整性?？刂破鬏敵鲆粋€大電流PWM信號如果負(fù)載箱阻抗匹配不對信號反射會造成電平畸變控制器可能直接誤判為故障。這種問題光靠看波形圖很難定位得對整個鏈路有系統(tǒng)性的理解。第三關(guān)是自動化開發(fā)能力。純粹的點(diǎn)擊式測試在HiL領(lǐng)域早就不夠用了你得會用ECU-TEST的TAScript、Python或者CAPL搭自動化測試框架會寫自定義函數(shù)、做測試數(shù)據(jù)流、對接Jenkins做持續(xù)集成回歸。我面試的時候碰到過一個候選人跟我說他做過兩年HiL測試結(jié)果問他會不會寫自動化腳本他說只會用臺架廠商給好的工程文件改參數(shù)。這種其實(shí)是“操作員”而不是“測試開發(fā)工程師”兩者待遇差一個量級。4. 兩個崗位的技術(shù)門檻對比技能棧、職業(yè)發(fā)展與面試方向4.1 技能棧對比為了幫助準(zhǔn)備車載測試面試或者正在做職業(yè)規(guī)劃的同學(xué)我把兩個崗位的技能棧做了個對比表格這個表格可以當(dāng)作自測清單來用。技能維度車載測試實(shí)車/臺架HiL測試半實(shí)物仿真車輛知識需要整車系統(tǒng)視角了解各系統(tǒng)交互重點(diǎn)在被控對象電驅(qū)/電池/底盤/發(fā)動機(jī)總線協(xié)議CAN/CAN FD/LIN/以太網(wǎng)診斷UDS/OBD同樣需要但更關(guān)注故障注入和信號級交互工具鏈CANoe、CANalyzer、示波器、診斷儀、數(shù)采設(shè)備CANoe、dSPACE ControlDesk、NI VeriStand、ECU-TEST、Simulink仿真建模不太需要需要至少能看懂和改參數(shù)高階需要獨(dú)立搭模型編程能力會CAPL或Python加分必備Python/CAPL/TAScript至少精通一門自動化能力可選有一定加分必備HiL測試的核心價值之一就是自動化回歸故障處理主要是故障現(xiàn)象記錄和初步定位要能復(fù)現(xiàn)、注入、分析信號級異常道路與試驗場經(jīng)驗必須路試占比高基本不需要都在實(shí)驗室里完成有人看完這個表格可能覺得HiL測試對軟件技能要求高太多了。確實(shí)如此但反過來車載實(shí)車測試對“整車?yán)斫狻焙汀芭R場判斷”要求更高。很多純做HiL的人第一次去參加整車路試遇到一個很簡單的偶發(fā)問題——儀表黑屏結(jié)果判斷不了是因為總線負(fù)載過高、電源電壓跌落還是軟件死機(jī)因為他從來沒有在真實(shí)電氣環(huán)境下看過問題。4.2 薪資與晉升路徑的差異從招聘市場的實(shí)際薪資來看一線城市車載測試工程師應(yīng)屆起步大概在10K到15K月薪1到3年經(jīng)驗的大概在15K到25K超過3年并且能獨(dú)立帶項目的30K也不奇怪。HiL測試因為門檻更高應(yīng)屆起步通常在15K到20K一些大廠或外企甚至可以給到20K以上3到5年經(jīng)驗且熟悉控制和建模的30K到40K是一個比較常見的區(qū)間。晉升路徑上兩者也有明顯差異。車載測試工程師往上走一般是高級測試工程師、測試組長、測試經(jīng)理、項目經(jīng)理方向比較豐富可以轉(zhuǎn)測試開發(fā)、自動化測試、測試架構(gòu)也可以橫向轉(zhuǎn)做產(chǎn)品需求、標(biāo)定、售后質(zhì)量。HiL測試往上走典型路徑是HiL測試工程師、HiL測試高級工程師、HiL系統(tǒng)開發(fā)工程師、測試架構(gòu)師很多人甚至可以往自動駕駛仿真、控制算法方向轉(zhuǎn)型因為做過HiL的人往往對控制器內(nèi)部邏輯和模型更熟悉轉(zhuǎn)算法和嵌入式的成功率更高。從個人長期發(fā)展來看我個人的建議是如果你對硬件、控制、軟件底層有好奇心HiL測試更值得深耕因為它面向的是“控制器的靈魂”。如果你喜歡跑在真實(shí)道路上的感覺更喜歡從用戶視角發(fā)現(xiàn)問題車載測試更適合你因為你面對的是“整車的極限”。4.3 車載測試面試題方向分析結(jié)合最近的面試考點(diǎn)我整理了幾個高頻方向給準(zhǔn)備面試的小伙伴一個參考。第一個方向是總線與診斷基礎(chǔ)。幾乎必問CAN和CAN FD的區(qū)別是什么DBC文件里有哪些關(guān)鍵要素UDS診斷服務(wù)0x22和0x2E分別代表什么OBD和UDS的關(guān)系是什么答的時候不能只背概念要能結(jié)合項目說比如“我在XX項目中用CANoe抓到過DTC狀態(tài)位變化當(dāng)時排查的是……”這種有實(shí)操細(xì)節(jié)的答案面試官很吃這一套。第二個方向是測試用例設(shè)計。面試官會給你一個功能場景比如“設(shè)計一套停車輔助雷達(dá)的測試用例”就看你能不能從正常功能、邊界條件、故障注入、網(wǎng)絡(luò)異常、電磁干擾、極端環(huán)境幾個維度去拆。很多人一上來就列二三十條用例但都是正常情況邊界和異常場景很少過不了幾輪就會被追問到脫層皮。第三個方向是工具與腳本。比如CANoe的CAPL里on message的定時器怎么寫、Python的Pytest框架怎么組織測試數(shù)據(jù)、怎么把測試數(shù)據(jù)做成可視化報告。這一環(huán)是很多轉(zhuǎn)行者的痛苦點(diǎn)真的需要靜下心去練最好能自己搭一個PythonCANoe的自動化練習(xí)小項目放在GitHub上。第四個方向是HiL專有話題比如電池HiL、以太網(wǎng)PMA測試。問到電池HiL核心點(diǎn)是電芯建模精度、電壓電流同步采集速率、絕緣與高壓安全保護(hù)怎么模擬。問到以太網(wǎng)PMA測試指的是物理介質(zhì)附加層測試關(guān)注的是100/1000BASE-T1的電氣特性比如發(fā)射機(jī)畸變、回波損耗、MDI模式轉(zhuǎn)換你要能讓面試官感受到你懂得物理層測試和協(xié)議層測試的差異而不只是會用示波器。5. 常見問題與避坑指南從新手到進(jìn)階都要看5.1 新手最容易踩的幾個坑第一個坑是把HiL測試當(dāng)成“搭積木”。很多人以為買一套dSPACE臺架把線接好模型部署好就可以開測了。實(shí)際上絕大部分時間都花在信號梳理、參數(shù)校準(zhǔn)、模型調(diào)通上。我記得第一次獨(dú)立搭電驅(qū)HiL臺架光是把旋變反饋信號和真實(shí)電流采樣的極性校準(zhǔn)就花了兩天某根信號線正負(fù)接反電流環(huán)直接發(fā)散控制器報過流差點(diǎn)燒了功率板卡。這件事之后我養(yǎng)成了一個習(xí)慣任何HiL上線之前必須先做IO信號打點(diǎn)和極限保護(hù)測試用信號發(fā)生器手動灌信號驗證鏈路再加載模型跑閉環(huán)。第二個坑是不記錄環(huán)境參數(shù)。做整車測試的時候很多人只記錄測試結(jié)果不記錄當(dāng)時的SOC、環(huán)境溫度、空調(diào)負(fù)載、胎壓、路面狀態(tài)、風(fēng)速導(dǎo)致測出來的異常無法復(fù)現(xiàn)。我告訴團(tuán)隊新人一個鐵律每一條測試記錄必須包含環(huán)境和前置狀態(tài)字段缺任何一個字段都算無效記錄。因為整車測試?yán)铩芭及l(fā)問題”十個里有九個是環(huán)境參數(shù)沒控制好。第三個坑是忽視自動化回歸價值。做HiL測試但只用人工操作臺架跑用例的團(tuán)隊效率低不說還容易漏回歸。我們后來要求所有新增用例必須帶上自動化標(biāo)簽?zāi)苣_本化的絕不手工點(diǎn)上線之前必須跑通“全量自動化回歸”這一關(guān)才允許發(fā)布測試報告。這件事一開始比較痛苦但堅持執(zhí)行半年后臺架日均利用率從不足50%提升到90%以上人力的真實(shí)消耗反而下降了。5.2 做車載測試與HiL測試時遇到這些情況怎么辦實(shí)車測試時偶現(xiàn)報錯復(fù)現(xiàn)不了怎么辦我一般的做法是先保證現(xiàn)場數(shù)據(jù)足夠完整整車日志、CAN日志、DTC快照、截圖視頻全部保留然后用“二分法”縮小范圍。比如儀表黑屏偶發(fā)先看發(fā)生前5秒電源電壓波形有沒有跌落再看總線負(fù)載率有沒有異常再看視頻面板的背光有沒有閃爍一步一步排除。最忌諱的是還沒定位就隨便換件換件只會把真正的問題掩蓋。HiL測試時模型發(fā)散電壓電流亂飛怎么辦第一反應(yīng)不是改模型參數(shù)而是先檢查IO信號鏈路的極性、增益、偏置用萬用表和示波器去量每一個關(guān)鍵信號確認(rèn)硬件層面沒有問題。如果硬件沒問題再看模型狀態(tài)是否初始化正確、步長是否合適。很多時候模型發(fā)散都是因為IO配置和模型接口類型不匹配比如模型里定義的是物理量IO板卡輸出的是原始數(shù)字量中間沒有標(biāo)定轉(zhuǎn)換必然發(fā)散。準(zhǔn)備跳槽面試時項目經(jīng)驗不夠亮眼怎么辦我的建議是從現(xiàn)在開始每做一個測試項目不管大小都拆成四層復(fù)盤需求背景、測試環(huán)境與工具、個人負(fù)責(zé)部分、最終價值與量化結(jié)果。例如“我負(fù)責(zé)車身域控制器的HiL回歸測試搭建了Python自動化框架將回歸用例執(zhí)行時間從12個小時壓縮到3個小時測試覆蓋率達(dá)到100%”。這種表述比“我做了很多測試”有說服力得多。5.3 兩個崗位該選哪一個實(shí)操建議我的個人經(jīng)驗是給一個兩分鐘自測來判斷第一題你更喜歡搞懂一個控制器的內(nèi)部邏輯和仿真模型還是更喜歡在真實(shí)車上跑多樣路況第二題你有沒有耐心坐下來調(diào)試一條信號通道反復(fù)看波形和模型輸出到深夜第三題你是靠C/C/Python這些軟件技能吃飯更安心還是靠駕駛經(jīng)驗、整車感覺和臨場判斷吃飯更安心。如果第一題選前者、第二題選有耐心、第三題選軟件那HiL測試更匹配。反過來如果第一題選真實(shí)路況、第二題選沒那么喜歡反復(fù)調(diào)試、第三題選整車感覺那車載測試更匹配。這里再補(bǔ)充一點(diǎn)不要覺得兩者是互斥的。我見過很多優(yōu)秀的測試架構(gòu)師既做過兩年HiL測試又做過一年整車路試然后再回頭做測試策略這類人對測試的全局理解非常透徹。如果你現(xiàn)在剛?cè)腴T不用急著定死方向先把HiL測試和車載測試的基礎(chǔ)能力都打上一些再根據(jù)實(shí)際感受逐步傾斜這樣幾年后反而更有競爭力。6. 寫在最后測試的本質(zhì)不是點(diǎn)按鈕而是理解系統(tǒng)邊界說了這么多最后分享一個我這些年帶團(tuán)隊的真實(shí)體會。不管是車載測試還是HiL測試崗位名稱可以變工具鏈可以變但測試工作的本質(zhì)始終是兩件事第一理解系統(tǒng)應(yīng)該在什么邊界內(nèi)正確運(yùn)行第二想辦法用最低成本、最高效率的方法驗證它在邊界內(nèi)和邊界外的真實(shí)表現(xiàn)。HiL測試的價值在于把系統(tǒng)邊界內(nèi)的邏輯問題提前暴露在實(shí)驗室里避免帶著已知風(fēng)險上路。車載測試的價值在于把系統(tǒng)放在真實(shí)世界里接受“你預(yù)想不到的考驗”。兩者不是誰替代誰的關(guān)系而是汽車研發(fā)V模型里不可互相替代的兩道關(guān)卡。很多人問我車載測試和HiL測試的終極門檻到底是什么我的答案是不是學(xué)歷不是工具熟練度而是你對被測對象有多深的理解以及你在海量信息里定位問題的能力。這兩個能力前者靠長期積累和被控對象背后的物理與控制知識后者靠不斷復(fù)盤踩過的坑。從今天開始不管你現(xiàn)在是做功能測試還是做HiL操作都試著多問一句這個信號為什么是這個值這個故障為什么這個時候報多問幾個為什么你會發(fā)現(xiàn)自己提升得比身邊人都快。 車載測試與HiL測試門檻對比：從V模型看測試崗技術(shù)分層與職業(yè)路徑
從各個渠道加我的同學(xué)經(jīng)常問一個問題車載測試和HiL測試到底哪個門檻更高是不是HiL更高級其實(shí)這個問題背后藏著一個更大的主題——整個汽車研發(fā)V模型里的測試崗大體上可以分為哪幾類每一類玩的東西、用的工具、要懂的知識差別大到什么程度。我最早做臺架測試后來轉(zhuǎn)到HiL測試再后來帶測試團(tuán)隊跟車載測試工程師、HiL測試工程師、甚至底盤標(biāo)定工程師都有大量交叉協(xié)作。這幾年面試過的人少說也有上百個特別是在車載測試面試環(huán)節(jié)發(fā)現(xiàn)很多人都把HiL測試?yán)斫獬伞邦愃婆_架測試的升級版”還有不少人以為車載測試就是“在車上點(diǎn)點(diǎn)屏幕、看看導(dǎo)航”。這倆理解都跑偏了。今天這篇文章我就把車載測試和HiL測試的區(qū)別、各自的技術(shù)門檻以及它們在整個汽車研發(fā)V模型中的位置盡量講透。全程不繞彎子文章里我會穿插一些面試真題方向、實(shí)操經(jīng)驗以及我自己踩過的坑。1. 從V模型看懂車載測試與HiL測試的崗位定位差異1.1 V模型到底是怎么回事想搞清楚車載測試和HiL測試的區(qū)別繞不開汽車研發(fā)的V模型。很多轉(zhuǎn)行的人一聽到V模型就頭大覺得是個很大的概念其實(shí)它沒那么玄乎。V模型描述的是一套“從需求到驗收”的工程流程左邊是自頂向下做開發(fā)設(shè)計右邊是自底向上做集成測試驗證左右對應(yīng)起來就成一個V字。左邊從最頂層的整車需求開始逐級拆解成系統(tǒng)需求、子系統(tǒng)需求、軟硬件需求最后到軟件單元、硬件單元。右邊從最底層的單元測試開始逐級向上一層做集成測試、系統(tǒng)測試、整車驗收。這里面的核心思想是你右邊怎么做測試完全取決于左邊怎么定義需求兩邊是嚴(yán)格對應(yīng)的。測試不是開發(fā)完了才開始而是需求階段就要考慮怎么驗證。在V模型框架下車載測試和HiL測試的差異本質(zhì)上是驗證層級的差異。車載測試更多落在右側(cè)靠上的位置也就是在整車或者整臺樣車上做系統(tǒng)級驗證。HiL測試則落在右側(cè)靠中間偏下的位置把控制器取出來接到實(shí)時仿真環(huán)境里做驗證所謂硬件在環(huán)硬件是真實(shí)的控制器環(huán)路里跑的是虛擬的車。這個位置差異決定了后面所有東西都不一樣。1.2 兩個測試在V模型里的位置切分我接觸過不少項目V模型在每家車企、每個零部件供應(yīng)商那里的裁剪方式都不一樣但大體上可以把測試層級分成五層單元測試與靜態(tài)測試主要針對軟件函數(shù)和模型工具是Simulink、Polyspace、Ctest這些。軟件集成測試驗證的是軟件組件之間的通信和數(shù)據(jù)交互很多用MiL或SiL方式做。HiL測試把真實(shí)控制器硬件放進(jìn)仿真環(huán)境驗證硬件與軟件交互、傳感器/執(zhí)行器信號、總線通信甚至是故障注入。臺架測試或系統(tǒng)集成測試這一步是控制器連上真實(shí)執(zhí)行機(jī)構(gòu)和環(huán)境模擬設(shè)備比如發(fā)動機(jī)臺架、電池臺架、電機(jī)臺架硬件是真的但整車環(huán)境還不完整。整車測試與實(shí)車路試也就是Road Test車輛在真實(shí)道路上跑測試內(nèi)容包括功能、性能、可靠性、耐久性等。從這條鏈上看HiL測試屬于控制器級別的驗證層車載測試往往泛指整車級別的驗證層。當(dāng)然有些公司叫法不一樣比如有的把HiL也歸到車載測試崗有的把臺架測試叫車載測試這都很常見。但你不管叫什么技術(shù)架構(gòu)是不會變的差異核心在于HiL是“把控制器從車上拆出來測”車載整車測試是“在整車上把所有控制器聯(lián)起來測”。1.3 本質(zhì)區(qū)別對象、環(huán)境與目的我習(xí)慣用三個維度來區(qū)分測試對象、測試環(huán)境、測試目的。HiL測試的對象是被測控制器俗稱ECU或VCU也有叫域控制器的它通過線束接到一套實(shí)時仿真系統(tǒng)上。仿真系統(tǒng)給控制器提供虛擬的傳感器信號同時采集控制器輸出的執(zhí)行器信號讓控制器感覺自己“還連在車上”。測試環(huán)境是實(shí)驗室是虛擬與真實(shí)混在一起的半實(shí)物環(huán)境。車載測試的對象是整車是幾十個控制器連同線束、傳感器、執(zhí)行器都在的真實(shí)系統(tǒng)。測試環(huán)境是實(shí)車可以是環(huán)境倉、試驗場也可以是公開道路。測試目的也不同HiL測試主要驗證控制器功能邏輯是否正確、軟件是否有Bug、信號鏈路是否正常、故障處理是否可靠車載測試主要驗證整車級的交互、系統(tǒng)匹配、用戶感受、極端場景下的表現(xiàn)、網(wǎng)絡(luò)穩(wěn)定性、電子電氣架構(gòu)的實(shí)際表現(xiàn)。打一個比方HiL測試就像是給一套剛組裝好的電腦主機(jī)單獨(dú)接上模擬顯示器、模擬鍵盤驗證主板、CPU、內(nèi)存、顯卡這套東西邏輯上有沒有問題。車載測試則是把電腦接上真實(shí)顯示器、真實(shí)鍵盤鼠標(biāo)、真實(shí)路由器開機(jī)跑各種軟件看體驗好不好、速度達(dá)不達(dá)標(biāo)。HiL保證“主機(jī)沒毛病”整車測試保證“整臺機(jī)器好用”。2. 車載測試到底在測什么從臺架、實(shí)車到路試2.1 車載測試的四大核心方向車載測試這個名字在招聘網(wǎng)站上被用得很泛有的公司把HMI功能測試叫車載測試有的把整車CAN網(wǎng)絡(luò)測試叫車載測試有的把ADAS路試也叫車載測試。實(shí)際上按工作內(nèi)容可以粗分為四類。第一類是功能測試這是最普遍的方向。座艙里的導(dǎo)航、語音、藍(lán)牙、倒車影像、車控App、空調(diào)界面每一個功能都要一條條去驗證。這個方向門檻相對低很多零基礎(chǔ)轉(zhuǎn)行的人都是從這里入手的。第二類是網(wǎng)絡(luò)與診斷測試這就要看CAN、CAN FD、LIN、FlexRay、車載以太網(wǎng)這些總線了你需要用CANoe或PCAN去抓報文、看信號、發(fā)診斷請求門檻明顯上一個臺階。第三類是整車性能測試偏向于動力性、經(jīng)濟(jì)性、制動、轉(zhuǎn)向、NVH、熱管理等經(jīng)常和底盤標(biāo)定、動力總成標(biāo)定的工程師一起干活這個方向?qū)囕v工程背景的要求比較高。第四類是ADAS測試與自動駕駛路試需要懂傳感器原理、場景設(shè)計、法規(guī)標(biāo)準(zhǔn)目前在所有方向里最火薪資天花板也高但門檻和風(fēng)險也都高。多數(shù)車載測試工程師實(shí)際是把第一類和第二類混著做的尤其是新勢力車企和Tier1的測試工程師一個人要覆蓋功能、網(wǎng)絡(luò)、診斷三塊。傳統(tǒng)主機(jī)廠反而分得更細(xì)。2.2 車載測試的日常工具與工作方式車載測試最常用的工具第一梯隊是Vector家的CANoe這基本是總線測試和診斷測試的標(biāo)配不會用CANoe都不好意思說自己做車載測試。第二梯隊是CANalyzer、PCAN、PicoScope示波器、同星、周立功的CAN卡。第三梯隊是診斷儀、萬用表、鉗流表、OBD轉(zhuǎn)接頭。做整車網(wǎng)絡(luò)測試的時候CANoe加上一個VN1640或VN7610接口卡配合整車線束轉(zhuǎn)接盒就能把整車CAN網(wǎng)絡(luò)上的報文全部實(shí)時監(jiān)控下來。真車測試還要帶一個很重要的東西——數(shù)采設(shè)備用陀螺儀、GPS天線、溫度傳感器、電壓采集模塊把車輛狀態(tài)和駕駛行為數(shù)據(jù)同步錄下來。實(shí)際工作中車載測試工程師通常按照測試用例來執(zhí)行一條一條過。一個DTC診斷測試用例可能是上電、把OBD口接上診斷儀、讀版本信息、清故障碼、設(shè)置某個故障條件、等60秒、再讀故障碼、驗證狀態(tài)位。這些操作看起來簡單但重復(fù)性非常高真正考驗的是你有沒有耐心、做不做記錄、會不會報告異常。我見過太多人測出一個異常卻不記錄復(fù)現(xiàn)步驟等開發(fā)工程師問起來的時候完全說不清楚這種問題在測試行業(yè)是很致命的。2.3 車載測試崗位的實(shí)際門檻純功能類的車載測試崗位學(xué)歷門檻通常放得比較寬大專以上就可以核心是會用工具、會看日志、會提Bug單、能寫測試報告。但網(wǎng)絡(luò)與診斷方向就不一樣了你得懂CAN協(xié)議棧、UDS診斷協(xié)議、DBC解析、J1939還要會用CANoe的CAPL腳本做一些簡單的自動化這個門檻會濾掉一大半人。如果你要往ADAS路試和自動駕駛測試發(fā)展那還需要懂傳感器原理、復(fù)雜場景設(shè)計、數(shù)據(jù)采集與標(biāo)注流程、法規(guī)倫理更重要的是你得能開車跑各種極限工況。ADAS路試的工程師你要是沒在高速上測過AEB沒在雨霧天測過ACC你都不好意思說自己干過這塊。門檻不只是技術(shù)還有膽量和體力一跑就是幾個小時車精神高度集中返程還要整理數(shù)據(jù)非常累。3. HiL測試的深層拆解半實(shí)物仿真才是硬骨頭3.1 HiL測試系統(tǒng)是怎么組成的HiL測試的核心是一套實(shí)時仿真系統(tǒng)行業(yè)里主流方案是dSPACE SCALEXIO、NI PXI、Vector VT System國產(chǎn)的也有經(jīng)緯恒潤的HiL、ETAS的LABCAR這幾年國產(chǎn)化的比例提高了很多。一套完整的HiL測試臺架至少包含四大部分。第一部分是實(shí)時機(jī)這是整個臺架的大腦它運(yùn)行著車輛動力學(xué)模型、電機(jī)模型、電池模型、發(fā)動機(jī)模型等被控對象模型以固定步長實(shí)時計算一般為1毫秒或更小。第二部分是IO板卡與信號調(diào)理包括模擬量輸入輸出、數(shù)字量輸入輸出、電阻仿真、PWM捕獲與生成、頻率信號等負(fù)責(zé)把控制器發(fā)出的真實(shí)信號和模型計算出的虛擬信號進(jìn)行交互。第三部分是故障注入單元也叫FIU通過繼電器矩陣把信號線開路、短路、對地短接、對電源短接用來模擬各種電氣故障這是HiL測試最核心的價值之一。第四部分是負(fù)載箱和傳感器仿真盒用來模擬噴油嘴、繼電器線圈、電機(jī)負(fù)載這些功率器件以及溫度、壓力傳感器等。除了硬件軟件部分半壁江山是模型和自動化環(huán)境。模型用Simulink搭建再編譯部署到實(shí)時機(jī)上。自動化環(huán)境用ECU-TEST、TestStand或者Python腳本編寫測試序列自動執(zhí)行測試用例、自動判斷Pass/Fail、自動生成報告。很多人以為HiL測試就是“學(xué)會開臺架”其實(shí)真正難的是模型和自動化這部分。3.2 為什么一定要做HiL測試有人會問反正最后要上車路試為什么還要花幾十萬上百萬搭一套HiL臺架做半實(shí)物仿真答案很簡單安全和成本。很多故障場景在真車上是不能復(fù)現(xiàn)的或者說復(fù)現(xiàn)成本極高。舉個例子如果你要驗證整車控制器對BMS上報的絕緣故障怎么響應(yīng)你在真車上很難精準(zhǔn)地制造一個絕緣故障就算你能做也很危險。但HiL臺架在軟件里控制模型狀態(tài)然后通過故障注入單元把信號線弄斷控制器就會認(rèn)為真的出現(xiàn)絕緣故障了你可以反反復(fù)復(fù)試一百遍。再比如驗證ABS或ESP在低附著路面上的控制邏輯在實(shí)車上你需要在冰面上測試費(fèi)時費(fèi)力但HiL臺架可以通過修改路面附著系數(shù)模型在10秒內(nèi)進(jìn)行多組工況切換。還有一個很實(shí)際的目的測試前置和自動化回歸。軟件開發(fā)是迭代的每發(fā)一個版本你都得做一輪回歸測試。在真車上做回歸一是車只有幾臺資源排不過來二是環(huán)境不可控今天下雨明天暴曬測試結(jié)果不一定是軟件問題還是環(huán)境差異。HiL臺架可以7乘24小時自動跑測試晚上人走了臺架還在跑用例第二天早上看報告就行。我?guī)У腍iL項目一個控制器一輪回歸3500多條用例在臺架上不到兩天就能跑完放在實(shí)車上至少干兩個星期。3.3 電池HiL測試和車載以太網(wǎng)HiL測試的特殊性這里重點(diǎn)說說電池HiL測試因為電池相關(guān)的熱搜詞在車載測試面試?yán)锍霈F(xiàn)頻率非常高。電池HiL和傳統(tǒng)控制器HiL最大的區(qū)別在于被測對象通常不是BMS主控板這么簡單而是BMS從板、主板、絕緣監(jiān)測、電流傳感器等一套系統(tǒng)很多場景還要把真實(shí)的電池模組或電池包接進(jìn)來形成所謂“電池HiL”的混合測試系統(tǒng)。電池HiL需要仿真電池單體的電壓和溫度變化這里要求非常高的精度和實(shí)時性。一個電芯的模型要能模擬開路電壓、內(nèi)阻、容量衰減、溫度特性150串電芯的電壓通道要能同步刷新到毫秒級。我做電池HiL時踩過一個大坑某次測試放電均衡功能模型里的電芯電壓是按照1秒步長更新的結(jié)果均衡打開后真實(shí)的BMS電流控制完全不收斂電芯電壓在模型和真實(shí)采樣之間不停跳變。后來才發(fā)現(xiàn)模型的實(shí)時性不足我們把步長改到50毫秒內(nèi)阻參數(shù)按熱模型耦合修正后均衡邏輯才穩(wěn)定下來。車載以太網(wǎng)HiL測試是這幾年冒出來的方向。傳統(tǒng)總線是CAN和LIN帶寬和速率有限但智能座艙和ADAS帶來的數(shù)據(jù)量暴漲車載以太網(wǎng)已經(jīng)成為主干網(wǎng)。做以太網(wǎng)的HiL難點(diǎn)在于怎么把以太網(wǎng)報文延遲、幀丟失、重傳這類網(wǎng)絡(luò)質(zhì)量問題在仿真環(huán)境里復(fù)現(xiàn)出來還要和自動駕駛的感知決策模型聯(lián)動。我記得有一次給客戶的智駕域控制器做以太網(wǎng)HiL測試?yán)锩媾芰薃EB算法和環(huán)視攝像頭測試場景是夜間行人橫穿結(jié)果以太網(wǎng)網(wǎng)絡(luò)擁堵造成感知幀延遲80毫秒算法決策直接晚了雖然最終通過虛擬OBD抓到了根因但排查過程特別痛苦同時也讓我們認(rèn)識到以太網(wǎng)測試的仿真精度有多重要。3.4 HiL測試崗位的技術(shù)門檻HiL測試的門檻第一關(guān)是理解被控對象。你要是測電池相關(guān)的HiL你得懂電芯特性、SOC估算算法、均衡策略你要測底盤制動你得懂液壓系統(tǒng)、制動防抱死邏輯。很多新人在這一點(diǎn)上就卡住了以為HiL測試就是操作臺架其實(shí)不會建模不會標(biāo)定遇到模型和實(shí)車差異都不知道從哪下手。第二關(guān)是實(shí)時仿真技術(shù)。你得懂實(shí)時操作系統(tǒng)、仿真步長、模型的代數(shù)環(huán)問題、IO板卡的延遲和精度、甚至還要懂一點(diǎn)信號完整性?？刂破鬏敵鲆粋€大電流PWM信號如果負(fù)載箱阻抗匹配不對信號反射會造成電平畸變控制器可能直接誤判為故障。這種問題光靠看波形圖很難定位得對整個鏈路有系統(tǒng)性的理解。第三關(guān)是自動化開發(fā)能力。純粹的點(diǎn)擊式測試在HiL領(lǐng)域早就不夠用了你得會用ECU-TEST的TAScript、Python或者CAPL搭自動化測試框架會寫自定義函數(shù)、做測試數(shù)據(jù)流、對接Jenkins做持續(xù)集成回歸。我面試的時候碰到過一個候選人跟我說他做過兩年HiL測試結(jié)果問他會不會寫自動化腳本他說只會用臺架廠商給好的工程文件改參數(shù)。這種其實(shí)是“操作員”而不是“測試開發(fā)工程師”兩者待遇差一個量級。4. 兩個崗位的技術(shù)門檻對比技能棧、職業(yè)發(fā)展與面試方向4.1 技能棧對比為了幫助準(zhǔn)備車載測試面試或者正在做職業(yè)規(guī)劃的同學(xué)我把兩個崗位的技能棧做了個對比表格這個表格可以當(dāng)作自測清單來用。技能維度車載測試實(shí)車/臺架HiL測試半實(shí)物仿真車輛知識需要整車系統(tǒng)視角了解各系統(tǒng)交互重點(diǎn)在被控對象電驅(qū)/電池/底盤/發(fā)動機(jī)總線協(xié)議CAN/CAN FD/LIN/以太網(wǎng)診斷UDS/OBD同樣需要但更關(guān)注故障注入和信號級交互工具鏈CANoe、CANalyzer、示波器、診斷儀、數(shù)采設(shè)備CANoe、dSPACE ControlDesk、NI VeriStand、ECU-TEST、Simulink仿真建模不太需要需要至少能看懂和改參數(shù)高階需要獨(dú)立搭模型編程能力會CAPL或Python加分必備Python/CAPL/TAScript至少精通一門自動化能力可選有一定加分必備HiL測試的核心價值之一就是自動化回歸故障處理主要是故障現(xiàn)象記錄和初步定位要能復(fù)現(xiàn)、注入、分析信號級異常道路與試驗場經(jīng)驗必須路試占比高基本不需要都在實(shí)驗室里完成有人看完這個表格可能覺得HiL測試對軟件技能要求高太多了。確實(shí)如此但反過來車載實(shí)車測試對“整車?yán)斫狻焙汀芭R場判斷”要求更高。很多純做HiL的人第一次去參加整車路試遇到一個很簡單的偶發(fā)問題——儀表黑屏結(jié)果判斷不了是因為總線負(fù)載過高、電源電壓跌落還是軟件死機(jī)因為他從來沒有在真實(shí)電氣環(huán)境下看過問題。4.2 薪資與晉升路徑的差異從招聘市場的實(shí)際薪資來看一線城市車載測試工程師應(yīng)屆起步大概在10K到15K月薪1到3年經(jīng)驗的大概在15K到25K超過3年并且能獨(dú)立帶項目的30K也不奇怪。HiL測試因為門檻更高應(yīng)屆起步通常在15K到20K一些大廠或外企甚至可以給到20K以上3到5年經(jīng)驗且熟悉控制和建模的30K到40K是一個比較常見的區(qū)間。晉升路徑上兩者也有明顯差異。車載測試工程師往上走一般是高級測試工程師、測試組長、測試經(jīng)理、項目經(jīng)理方向比較豐富可以轉(zhuǎn)測試開發(fā)、自動化測試、測試架構(gòu)也可以橫向轉(zhuǎn)做產(chǎn)品需求、標(biāo)定、售后質(zhì)量。HiL測試往上走典型路徑是HiL測試工程師、HiL測試高級工程師、HiL系統(tǒng)開發(fā)工程師、測試架構(gòu)師很多人甚至可以往自動駕駛仿真、控制算法方向轉(zhuǎn)型因為做過HiL的人往往對控制器內(nèi)部邏輯和模型更熟悉轉(zhuǎn)算法和嵌入式的成功率更高。從個人長期發(fā)展來看我個人的建議是如果你對硬件、控制、軟件底層有好奇心HiL測試更值得深耕因為它面向的是“控制器的靈魂”。如果你喜歡跑在真實(shí)道路上的感覺更喜歡從用戶視角發(fā)現(xiàn)問題車載測試更適合你因為你面對的是“整車的極限”。4.3 車載測試面試題方向分析結(jié)合最近的面試考點(diǎn)我整理了幾個高頻方向給準(zhǔn)備面試的小伙伴一個參考。第一個方向是總線與診斷基礎(chǔ)。幾乎必問CAN和CAN FD的區(qū)別是什么DBC文件里有哪些關(guān)鍵要素UDS診斷服務(wù)0x22和0x2E分別代表什么OBD和UDS的關(guān)系是什么答的時候不能只背概念要能結(jié)合項目說比如“我在XX項目中用CANoe抓到過DTC狀態(tài)位變化當(dāng)時排查的是……”這種有實(shí)操細(xì)節(jié)的答案面試官很吃這一套。第二個方向是測試用例設(shè)計。面試官會給你一個功能場景比如“設(shè)計一套停車輔助雷達(dá)的測試用例”就看你能不能從正常功能、邊界條件、故障注入、網(wǎng)絡(luò)異常、電磁干擾、極端環(huán)境幾個維度去拆。很多人一上來就列二三十條用例但都是正常情況邊界和異常場景很少過不了幾輪就會被追問到脫層皮。第三個方向是工具與腳本。比如CANoe的CAPL里on message的定時器怎么寫、Python的Pytest框架怎么組織測試數(shù)據(jù)、怎么把測試數(shù)據(jù)做成可視化報告。這一環(huán)是很多轉(zhuǎn)行者的痛苦點(diǎn)真的需要靜下心去練最好能自己搭一個PythonCANoe的自動化練習(xí)小項目放在GitHub上。第四個方向是HiL專有話題比如電池HiL、以太網(wǎng)PMA測試。問到電池HiL核心點(diǎn)是電芯建模精度、電壓電流同步采集速率、絕緣與高壓安全保護(hù)怎么模擬。問到以太網(wǎng)PMA測試指的是物理介質(zhì)附加層測試關(guān)注的是100/1000BASE-T1的電氣特性比如發(fā)射機(jī)畸變、回波損耗、MDI模式轉(zhuǎn)換你要能讓面試官感受到你懂得物理層測試和協(xié)議層測試的差異而不只是會用示波器。5. 常見問題與避坑指南從新手到進(jìn)階都要看5.1 新手最容易踩的幾個坑第一個坑是把HiL測試當(dāng)成“搭積木”。很多人以為買一套dSPACE臺架把線接好模型部署好就可以開測了。實(shí)際上絕大部分時間都花在信號梳理、參數(shù)校準(zhǔn)、模型調(diào)通上。我記得第一次獨(dú)立搭電驅(qū)HiL臺架光是把旋變反饋信號和真實(shí)電流采樣的極性校準(zhǔn)就花了兩天某根信號線正負(fù)接反電流環(huán)直接發(fā)散控制器報過流差點(diǎn)燒了功率板卡。這件事之后我養(yǎng)成了一個習(xí)慣任何HiL上線之前必須先做IO信號打點(diǎn)和極限保護(hù)測試用信號發(fā)生器手動灌信號驗證鏈路再加載模型跑閉環(huán)。第二個坑是不記錄環(huán)境參數(shù)。做整車測試的時候很多人只記錄測試結(jié)果不記錄當(dāng)時的SOC、環(huán)境溫度、空調(diào)負(fù)載、胎壓、路面狀態(tài)、風(fēng)速導(dǎo)致測出來的異常無法復(fù)現(xiàn)。我告訴團(tuán)隊新人一個鐵律每一條測試記錄必須包含環(huán)境和前置狀態(tài)字段缺任何一個字段都算無效記錄。因為整車測試?yán)铩芭及l(fā)問題”十個里有九個是環(huán)境參數(shù)沒控制好。第三個坑是忽視自動化回歸價值。做HiL測試但只用人工操作臺架跑用例的團(tuán)隊效率低不說還容易漏回歸。我們后來要求所有新增用例必須帶上自動化標(biāo)簽?zāi)苣_本化的絕不手工點(diǎn)上線之前必須跑通“全量自動化回歸”這一關(guān)才允許發(fā)布測試報告。這件事一開始比較痛苦但堅持執(zhí)行半年后臺架日均利用率從不足50%提升到90%以上人力的真實(shí)消耗反而下降了。5.2 做車載測試與HiL測試時遇到這些情況怎么辦實(shí)車測試時偶現(xiàn)報錯復(fù)現(xiàn)不了怎么辦我一般的做法是先保證現(xiàn)場數(shù)據(jù)足夠完整整車日志、CAN日志、DTC快照、截圖視頻全部保留然后用“二分法”縮小范圍。比如儀表黑屏偶發(fā)先看發(fā)生前5秒電源電壓波形有沒有跌落再看總線負(fù)載率有沒有異常再看視頻面板的背光有沒有閃爍一步一步排除。最忌諱的是還沒定位就隨便換件換件只會把真正的問題掩蓋。HiL測試時模型發(fā)散電壓電流亂飛怎么辦第一反應(yīng)不是改模型參數(shù)而是先檢查IO信號鏈路的極性、增益、偏置用萬用表和示波器去量每一個關(guān)鍵信號確認(rèn)硬件層面沒有問題。如果硬件沒問題再看模型狀態(tài)是否初始化正確、步長是否合適。很多時候模型發(fā)散都是因為IO配置和模型接口類型不匹配比如模型里定義的是物理量IO板卡輸出的是原始數(shù)字量中間沒有標(biāo)定轉(zhuǎn)換必然發(fā)散。準(zhǔn)備跳槽面試時項目經(jīng)驗不夠亮眼怎么辦我的建議是從現(xiàn)在開始每做一個測試項目不管大小都拆成四層復(fù)盤需求背景、測試環(huán)境與工具、個人負(fù)責(zé)部分、最終價值與量化結(jié)果。例如“我負(fù)責(zé)車身域控制器的HiL回歸測試搭建了Python自動化框架將回歸用例執(zhí)行時間從12個小時壓縮到3個小時測試覆蓋率達(dá)到100%”。這種表述比“我做了很多測試”有說服力得多。5.3 兩個崗位該選哪一個實(shí)操建議我的個人經(jīng)驗是給一個兩分鐘自測來判斷第一題你更喜歡搞懂一個控制器的內(nèi)部邏輯和仿真模型還是更喜歡在真實(shí)車上跑多樣路況第二題你有沒有耐心坐下來調(diào)試一條信號通道反復(fù)看波形和模型輸出到深夜第三題你是靠C/C/Python這些軟件技能吃飯更安心還是靠駕駛經(jīng)驗、整車感覺和臨場判斷吃飯更安心。如果第一題選前者、第二題選有耐心、第三題選軟件那HiL測試更匹配。反過來如果第一題選真實(shí)路況、第二題選沒那么喜歡反復(fù)調(diào)試、第三題選整車感覺那車載測試更匹配。這里再補(bǔ)充一點(diǎn)不要覺得兩者是互斥的。我見過很多優(yōu)秀的測試架構(gòu)師既做過兩年HiL測試又做過一年整車路試然后再回頭做測試策略這類人對測試的全局理解非常透徹。如果你現(xiàn)在剛?cè)腴T不用急著定死方向先把HiL測試和車載測試的基礎(chǔ)能力都打上一些再根據(jù)實(shí)際感受逐步傾斜這樣幾年后反而更有競爭力。6. 寫在最后測試的本質(zhì)不是點(diǎn)按鈕而是理解系統(tǒng)邊界說了這么多最后分享一個我這些年帶團(tuán)隊的真實(shí)體會。不管是車載測試還是HiL測試崗位名稱可以變工具鏈可以變但測試工作的本質(zhì)始終是兩件事第一理解系統(tǒng)應(yīng)該在什么邊界內(nèi)正確運(yùn)行第二想辦法用最低成本、最高效率的方法驗證它在邊界內(nèi)和邊界外的真實(shí)表現(xiàn)。HiL測試的價值在于把系統(tǒng)邊界內(nèi)的邏輯問題提前暴露在實(shí)驗室里避免帶著已知風(fēng)險上路。車載測試的價值在于把系統(tǒng)放在真實(shí)世界里接受“你預(yù)想不到的考驗”。兩者不是誰替代誰的關(guān)系而是汽車研發(fā)V模型里不可互相替代的兩道關(guān)卡。很多人問我車載測試和HiL測試的終極門檻到底是什么我的答案是不是學(xué)歷不是工具熟練度而是你對被測對象有多深的理解以及你在海量信息里定位問題的能力。這兩個能力前者靠長期積累和被控對象背后的物理與控制知識后者靠不斷復(fù)盤踩過的坑。從今天開始不管你現(xiàn)在是做功能測試還是做HiL操作都試著多問一句這個信號為什么是這個值這個故障為什么這個時候報多問幾個為什么你會發(fā)現(xiàn)自己提升得比身邊人都快。