去年秋天產(chǎn)線突然批量報“CRC校驗失敗”我第一反應(yīng)是這批應(yīng)答器要整體返工。但拆了幾臺拿到實驗室頻譜儀上細看報文波形明明是對的。排查到最后問題出在LabVIEW程序里讀頻譜儀trace的超時時間設(shè)得太短軟件拿到的是上一次循環(huán)緩存的舊數(shù)據(jù)。這種坑做過儀控自動化的人應(yīng)該都懂——測試系統(tǒng)自身不穩(wěn)定比被測產(chǎn)品出問題還難查。做LabVIEW高鐵應(yīng)答器出廠測試系統(tǒng)遠不是畫個界面、調(diào)幾個驅(qū)動API那么簡單。它牽扯射頻鏈路設(shè)計、近場耦合、報文解調(diào)、時序精度控制、數(shù)據(jù)庫追溯還有產(chǎn)線上的各種意外情況。這篇文章把這個項目從需求拆解、硬件選型、軟件架構(gòu)到現(xiàn)場排障的完整過程梳理一遍給正在做類似產(chǎn)線測試系統(tǒng)的工程師一個參考也適合剛接觸LabVIEW但想往射頻測試方向走的同學(xué)——你會看到一套完整的系統(tǒng)是怎么把上位機、儀表、夾具和邏輯串起來的。1. 應(yīng)答器出廠測試到底在測什么幾個指標(biāo)幫我理清了需求1.1 應(yīng)答器遠沒有看起來那么簡單應(yīng)答器Balise是高鐵列控系統(tǒng)里的地面關(guān)鍵設(shè)備安裝在鋼軌中間。列車底部有車載天線經(jīng)過時發(fā)出27.095MHz的射頻能量給應(yīng)答器供電應(yīng)答器內(nèi)部電路被激活后通過FSK調(diào)制方式在4.23MHz上行鏈路上把報文回發(fā)給列車。報文里帶著公里標(biāo)、線路坡度、限速信息列車靠這個確認(rèn)自己的位置。這個原理描述起來很輕松但到出廠測試這一環(huán)就麻煩了。被測對象是按近場耦合方式工作的測試時不能像測普通射頻模塊那樣直接拿SMA線纜懟上去。你得模擬列車底部天線的饋能環(huán)境同時用耦合環(huán)天線接收應(yīng)答器回發(fā)的信號。整個測試鏈路有“無線”部分稍微哪里匹配不好測出來的數(shù)據(jù)就和真實過車場景對不上。我在項目一開始犯了個錯上來就列了一堆要測的射頻參數(shù)結(jié)果被老師傅問了一句你這些指標(biāo)測出來能判斷列車能不能可靠讀到這個報文嗎我這才意識到應(yīng)答器測試的核心不是追求指標(biāo)多而是確保“車載BTM在真實環(huán)境下能完整、穩(wěn)定地解出這條報文”。1.2 出廠測試的核心項目與判定邏輯經(jīng)過反復(fù)梳理我把出廠測試項目分成四類。報文類測試是基礎(chǔ)每條應(yīng)答器寫入的報文內(nèi)容不同出廠時要驗證報文的固定字段、可變字段是否正確CRC校驗是否通過報文中間有沒有丟位、錯位。這個直接對應(yīng)列車能不能解出正確信息。射頻類測試是關(guān)鍵上行載波頻率是否在4.23MHz的容差范圍內(nèi)輸出功率是否滿足協(xié)議要求FSK頻偏是否達標(biāo)調(diào)制是否干凈。頻率偏了、功率低了都會導(dǎo)致車載設(shè)備在高速過車時來不及解調(diào)。時序類測試容易被忽略但非常重要從應(yīng)答器被饋能激活到輸出穩(wěn)定報文有一個啟動時間切斷饋能后應(yīng)答器還能維持發(fā)送一小段時間。這兩個時間窗口決定了列車高速通過時能不能在有效區(qū)域內(nèi)完成報文讀取。直流類測試面向有源應(yīng)答器和內(nèi)部電路供電電流是否正常有沒有短路漏電內(nèi)部儲能電容的充電特性是否達標(biāo)。這類測試用到的就是熱搜詞里反復(fù)出現(xiàn)的Keithley 6221電流源和2182納伏表組合。這里我想多說一句關(guān)于判定邏輯。產(chǎn)線測試最怕的是“模糊地帶”——參數(shù)不上不下測出來既沒超上限也不算完全合格。后來我定的規(guī)矩是所有硬指標(biāo)按協(xié)議上下限加測量不確定度后形成內(nèi)控線內(nèi)控線比協(xié)議線收緊5%到10%寧可把邊緣產(chǎn)品攔下來復(fù)測也絕不讓帶病產(chǎn)品流出去。1.3 為什么繞不開LabVIEW市面上不是沒有專用的應(yīng)答器測試儀表但價格昂貴而且只針對特定接口和協(xié)議產(chǎn)品一迭代儀表就跟不上。用LabVIEW搭一套自己的測試系統(tǒng)好處是明顯的。驅(qū)動生態(tài)全。GPIB、LAN、USB、串口幾乎所有儀器都有現(xiàn)成的LabVIEW驅(qū)動省去了大量底層通信開發(fā)時間。界面開發(fā)快。產(chǎn)線工人需要的不是復(fù)雜的曲線分析界面而是“掃碼、按啟動、看PASS/FAIL”的極簡交互LabVIEW幾分鐘就能拖出來。數(shù)據(jù)處理和存儲靈活。測試數(shù)據(jù)要寫數(shù)據(jù)庫、要出Excel報告、要存原始波形LabVIEW都有現(xiàn)成工具包。而且有一點被很多人低估LabVIEW做產(chǎn)線測試狀態(tài)機邏輯非常直觀。測試步驟多、判斷條件多、異常分支多圖形化的狀態(tài)機比文本代碼更容易讓同事看懂和維護。這個項目里哪怕是沒系統(tǒng)學(xué)過LabVIEW的電氣工程師也能在狀態(tài)機框圖里找到某個測試步驟在哪改個超時參數(shù)不費勁。2. 測試臺架構(gòu)設(shè)計從射頻鏈路到供電控制的一次性規(guī)劃2.1 激活鏈路和采集鏈路怎么搭硬件架構(gòu)是整個項目的骨架這塊規(guī)劃錯了后面軟件寫得再好都白搭。我先梳理了一下系統(tǒng)的鏈路。激活鏈路上位機控制射頻信號源輸出27.095MHz連續(xù)波作為給應(yīng)答器饋能的“激活源”經(jīng)過功率放大后送到激活天線模擬列車底部天線的作用。應(yīng)答器被激活后開始回發(fā)4.23MHz的FSK信號這個信號被耦合環(huán)天線接收經(jīng)過可調(diào)衰減器送到頻譜儀進行分析。一條發(fā)送鏈路、一條接收鏈路再加上直流供電和數(shù)字控制。信號源選型我選了Keysight N5171B原因是它頻率穩(wěn)定性好、支持外部觸發(fā)可以在LabVIEW里精確控制“什么時候開始饋能”。頻譜儀用的是Keysight N9000B帶IQ分析功能既能看頻譜又能做矢量解調(diào)。如果預(yù)算有限國產(chǎn)同檔次型號也可以但一定要保證解調(diào)帶寬和觸發(fā)能力滿足要求別只看頻率范圍。這里有個特別容易踩的坑應(yīng)答器回發(fā)的信號屬于近場耦合信號在測試夾具里測到的絕對功率值本來就偏低。頻譜儀輸入端一定要加可調(diào)衰減器和保護電路防止操作失誤時信號源大功率直接灌進來。我的方案是信號源輸出后接一個固定10dB衰減再加到天線上接收鏈路從天線出來先過一個可調(diào)衰減器再進頻譜儀這樣即使鏈路接錯也不至于燒掉儀器前端的低噪聲放大器。2.2 直流參數(shù)測試的儀器組合62212182熱搜詞里頻繁出現(xiàn)的6221與2182同步采集在應(yīng)答器測試?yán)锎_實是剛需。6221是精密電流源2182是納伏表兩者配合可以做Delta模式的電阻測量和低電平電壓測量。應(yīng)答器內(nèi)部電路在待機、激活、發(fā)送三個狀態(tài)的電流差異很大有的狀態(tài)電流小到微安級用普通萬用表根本測不準(zhǔn)。我把6221和2182通過GPIB總線接到上位機中間用一根觸發(fā)線把兩臺儀器的Trigger Link連接起來。為什么要強調(diào)同步因為2182納伏表采樣速度慢6221電流源輸出變化快如果兩臺儀器各自獨立工作采到的電壓和電流不是同一個時間點算出來的電阻值誤差會很大。用觸發(fā)線把兩者同步后6221每改變一次輸出電流2182立刻開始采集電壓這在LabVIEW里配合驅(qū)動自帶的Delta模式示例就能實現(xiàn)。實際測試中我們還遇到過一個問題6221輸出微安級電流時測試線纜本身的接觸電阻和溫漂會影響測量結(jié)果。后來改成四線制開爾文接法把電流回路和電壓采樣回路分開穩(wěn)定性提升了一個數(shù)量級。這個細節(jié)在常規(guī)文檔里寫得不明顯但做低電平測量時是必須的。2.3 臺架布局與夾具設(shè)計的細節(jié)臺架設(shè)計看起來是硬件的事但直接決定軟件參數(shù)好不好寫。天線與應(yīng)答器的相對位置必須固定間距誤差控制在毫米級。近場耦合的信號強度對距離極敏感應(yīng)答器放偏一點測出來的功率值就會差出幾個dB直接導(dǎo)致誤判。我的方案是做了一套抽屜式夾具應(yīng)答器放進定位槽后被氣缸壓緊位置公差控制在±0.5mm以內(nèi)。激活天線固定在夾具頂部接收耦合環(huán)天線緊貼被測品表面間距靠定位塊保證。這樣軟件里的功率判定閾值才能有實際意義。另一個細節(jié)是線纜布局。射頻信號線和電源線、控制線必須分開走交叉時要垂直交叉避免工頻干擾串入射頻鏈路。我見過一個項目就是線纜扎在一起導(dǎo)致頻譜儀底噪抬高了整整10dB排查了半個月才發(fā)現(xiàn)是電機控制線的電磁干擾。做產(chǎn)線測試電磁兼容問題從第一天就要考慮進去。3. LabVIEW軟件怎么組織狀態(tài)機、生產(chǎn)者消費者和配置驅(qū)動的組合3.1 軟件主狀態(tài)機設(shè)計產(chǎn)線測試軟件不能是跑通一次就算完它要長時間連續(xù)運行要應(yīng)對掃碼槍沒識別、儀器沒響應(yīng)、閾值超限等各種異常。我采用了經(jīng)典的狀態(tài)機結(jié)構(gòu)主循環(huán)分為這幾個狀態(tài)初始化、空閑待機、掃碼確認(rèn)、測試執(zhí)行、結(jié)果判定、數(shù)據(jù)存儲、異常處理。初始化狀態(tài)下程序自動檢測所有儀器是否在線信號源是否鎖定頻譜儀是否空閑任何一個掉線就彈窗提示絕不帶病運行。空閑待機狀態(tài)下軟件等待掃碼槍輸入掃到的SN碼會先校驗格式防止亂碼進入測試流程。測試執(zhí)行狀態(tài)是整個系統(tǒng)的核心它會根據(jù)配置文件里的測試序列逐個調(diào)用測試模塊。狀態(tài)機能讓我在任何時候都清楚“程序現(xiàn)在在哪一步”。有一次產(chǎn)線反饋測試卡住不動我遠程看畫面看到停在“等待頻譜儀空閑”這一步立刻知道是頻譜儀上一輪測試的IQ數(shù)據(jù)沒釋放直接定位到資源占用問題。如果是平鋪直敘的腳本式代碼這個問題至少要翻半天日志才能查出來。3.2 數(shù)據(jù)流結(jié)構(gòu)生產(chǎn)者消費者模式測試過程中頻譜儀的IQ數(shù)據(jù)、6221的直流數(shù)據(jù)、狀態(tài)監(jiān)測數(shù)據(jù)都在同時產(chǎn)生如果都在一個循環(huán)里處理很容易出現(xiàn)數(shù)據(jù)積壓。原來我犯過錯誤把頻譜儀讀數(shù)據(jù)和界面刷新放在一起結(jié)果頻譜儀數(shù)據(jù)量一大界面就卡死。后來改成生產(chǎn)者消費者模式生產(chǎn)者循環(huán)專門負(fù)責(zé)從頻譜儀、6221、采集卡讀數(shù)據(jù)把數(shù)據(jù)和對應(yīng)的時間戳打包成簇通過隊列發(fā)給消費者循環(huán)。消費者循環(huán)負(fù)責(zé)處理、分析和顯示。隊列緩沖區(qū)的深度要設(shè)夠我一般設(shè)為10000個元素數(shù)據(jù)量再大也不會丟。這里要特別注意隊列溢出問題。如果消費者處理速度跟不上生產(chǎn)者隊列會越積越多最后內(nèi)存暴漲。我給隊列加了監(jiān)控當(dāng)隊列深度超過80%時自動丟棄一些非關(guān)鍵UI數(shù)據(jù)只保留測試數(shù)據(jù)同時在界面提示“系統(tǒng)繁忙”。這樣保證測試數(shù)據(jù)完整性的同時界面也不會被拖死。3.3 配置文件和測試項管理整個項目的測試項、閾值、儀器地址全部外置到配置文件里而不是寫死在代碼中。我用的是INI格式簡單直觀產(chǎn)線工程師用記事本就能改。配置文件里分幾個段儀器地址段、報文參數(shù)段、射頻閾值段、時序閾值段、數(shù)據(jù)庫連接段、報告模板路徑段。配置驅(qū)動的意義在于換型靈活。同一個測試臺可能兼容多種型號應(yīng)答器不同型號的報文長度、功率閾值、啟動時間要求都不一樣。換型時不需要重新編譯軟件只換一個配置文件就行。后來我還做了一個配置文件版本號校驗測試結(jié)果里會記錄當(dāng)時用的配置版本這樣追溯起來非常清楚。這里多說一句教訓(xùn)。配置文件雖然方便但也容易被誤改。產(chǎn)線操作員有時候會隨手改掉某個閾值導(dǎo)致一批產(chǎn)品誤判。我給配置文件加了只讀保護和修改權(quán)限控制只有工程師賬號才能修改操作員賬號只能查看。測試軟件啟動時會校驗配置文件哈希值如果文件被動過會提示并且拒絕繼續(xù)測試。4. 核心測試項的實現(xiàn)細節(jié)與調(diào)試過程4.1 報文解碼和CRC校驗的實現(xiàn)報文測試是整個系統(tǒng)的靈魂。應(yīng)答器回發(fā)的信號是FSK調(diào)制載波4.23MHz符號率564.48kbps。在LabVIEW里先把頻譜儀設(shè)成IQ分析模式采集一段包含完整報文的IQ數(shù)據(jù)然后做FSK解調(diào)。解調(diào)我用了NI的Modulation Toolkit里面有現(xiàn)成的解調(diào)函數(shù)指定符號率、調(diào)制方式、頻偏范圍就能輸出符號序列。這里有一個關(guān)鍵參數(shù)是解調(diào)起始位置。信號不是一上電就穩(wěn)定輸出波形的開頭有一段前導(dǎo)碼和同步頭必須要先用同步頭做定時恢復(fù)找到報文的起始位再往后解析數(shù)據(jù)。如果直接從采樣起點開始解調(diào)前面幾個bit大概率是錯的整幀CRC校驗肯定失敗。CRC校驗我按協(xié)議規(guī)定的多項式寫了一個子VI用移位寄存器逐位處理。這里要注意兩點一是CRC初始值和出參是否需要按位取反不同協(xié)議差異很大二是CRC校驗失敗時要把失敗的具體bit位置記錄下來方便分析問題而不是只報一個“CRC Error”。在實際調(diào)試中我發(fā)現(xiàn)單靠頻譜儀一次IQ采集的報文來判CRC偶爾會出現(xiàn)偶發(fā)性的誤碼。后來調(diào)整策略每臺設(shè)備連續(xù)解調(diào)5幀要求至少4幀完全正確。這樣既保證了測試效率又避免了單幀偶發(fā)干擾導(dǎo)致的誤判。這個規(guī)則現(xiàn)在看起來簡單當(dāng)時是誤判率居高不下時反復(fù)試出來的。4.2 射頻參數(shù)測量頻率、功率、頻偏怎么取射頻參數(shù)測量我用的是頻譜儀加軟件計算的組合。中心頻率測試用頻譜儀的frequency counter模式比手動找峰值的精度高一個量級。輸出功率用channel power測量設(shè)定一個以4.23MHz為中心的積分帶寬把帶內(nèi)所有能量積分起來這樣比取peak值更穩(wěn)定也更能反映真實信號強度。FSK頻偏的測量我先把IQ數(shù)據(jù)解調(diào)然后看符號“0”和符號“1”對應(yīng)的瞬時頻率分布兩者的中心間距除以2就是頻偏。這個參數(shù)不能只看一兩個符號要統(tǒng)計一整幀所有符號的分布情況。我寫了一個分布直方圖VI把頻偏的均值、標(biāo)準(zhǔn)差都算出來標(biāo)準(zhǔn)差過大說明調(diào)制質(zhì)量不好就算均值達標(biāo)也可能導(dǎo)致解調(diào)誤碼。頻譜儀的參數(shù)設(shè)置也很關(guān)鍵。分辨率帶寬設(shè)太大會把信號周圍細節(jié)抹掉設(shè)太小測量速度又跟不上。我測試下來中心頻率4.23MHz、span 2MHz、RBW 10kHz既能清晰看到FSK的雙峰測量速度也合適。RBW和VBW的比例一般設(shè)1比1或1比1.5太大會把噪聲抹平導(dǎo)致功率讀數(shù)偏低。4.3 啟動時間與連續(xù)性判斷的時序處理啟動時間測量是這個項目里比較容易被忽視的部分。應(yīng)答器從通電饋能到穩(wěn)定輸出報文這個時間過長的話列車以時速350公里通過時可能還沒來得及讀到完整報文。測量啟動時間不能用軟件輪詢的方式因為輪詢的精度依賴于循環(huán)速度誤差太大而且容易漏掉瞬間的電平跳變。我用了NI采集卡的計數(shù)器功能。方案是這樣的信號源開始輸出饋能信號的同時給采集卡的數(shù)字輸入口發(fā)出一個同步觸發(fā)脈沖計數(shù)器以這個脈沖的上升沿作為時間起點應(yīng)答器回發(fā)的射頻信號經(jīng)過一個檢波二極管電路轉(zhuǎn)換成直流電平送到另一路數(shù)字輸入口當(dāng)這路輸入檢測到上升沿時計數(shù)器停止計時時間差就是啟動時間。這個方案的核心是硬件的邊沿觸發(fā)和計數(shù)器精度可以達到微秒級完全不受Windows系統(tǒng)調(diào)度的干擾。當(dāng)時為了驗證這個方案我用信號發(fā)生器做模擬源輸入標(biāo)準(zhǔn)延遲信號反復(fù)測量精度穩(wěn)定在±50微秒以內(nèi)完全滿足協(xié)議要求。連續(xù)性判斷我用的是頻譜儀的zero span模式把中心頻率設(shè)在4.23MHz看時間域上的信號包絡(luò)。通過包絡(luò)的持續(xù)時間和平坦度可以判斷應(yīng)答器在整個發(fā)送窗口內(nèi)有沒有中斷、有沒有掉功率。這個測試看起來簡單但能抓到競品設(shè)備偶爾出現(xiàn)的“打嗝”現(xiàn)象——報文中間突然斷開一個bit的時間CRC過濾時卻不一定每次都抓得到。5. 產(chǎn)線上真實踩過的幾個坑從誤判到反復(fù)停機5.1 地環(huán)路讓我排查了整整兩天有一次產(chǎn)線反饋功率測量值不穩(wěn)定同一個待測品連續(xù)測試的數(shù)據(jù)上下跳動接近0.5dB但把儀器搬到研發(fā)實驗室里就正常。我和產(chǎn)線的維護同事排查了兩天換過頻譜儀、換過天線、重新校準(zhǔn)過電纜都沒用。最后我用示波器掛在頻譜儀的中頻輸出上才看到有一個微弱的50Hz工頻分量。原因就是地環(huán)路。機柜里信號源和頻譜儀插在不同的電源排插上地線之間存在電位差這個電位差通過射頻電纜的屏蔽層形成回路電流把工頻干擾耦合進了信號鏈路。解決方案很簡單所有設(shè)備強制接到同一個電源排插射頻電纜屏蔽層只在主機端單端接地另一端懸空。處理后功率讀數(shù)穩(wěn)定了一個量級。這個坑給我最深的教訓(xùn)是做射頻測試系統(tǒng)第一優(yōu)先考慮的不是先進功能而是接地和屏蔽。電磁兼容問題一旦出現(xiàn)癥狀千奇百怪而且沒有任何日志能幫你查。5.2 預(yù)觸發(fā)時間不夠?qū)е聢笪念^被截斷軟件上線后陸陸續(xù)續(xù)出現(xiàn)報文解析偶發(fā)失敗特別是一天中第一次測試時最容易出現(xiàn)。后來我把頻譜儀的IQ采集設(shè)置打開發(fā)現(xiàn)采集起始點比信號到達晚了一點報文開頭被切掉了一截。原因是我把觸發(fā)模式設(shè)成了IF功率觸發(fā)信號到了之后才開始采樣預(yù)觸發(fā)時間設(shè)得又太短前導(dǎo)碼和同步頭直接丟了。解決方法是改成外部觸發(fā)以信號源開始饋能的脈沖作為頻譜儀采樣觸發(fā)的起點同時把預(yù)觸發(fā)時間從0改成2毫秒確保把信號建立過程完整記錄下來。這個改動之后報文解析的成功率從98%提升到了99.9%以上。產(chǎn)線測試最怕的不是偶發(fā)失敗而是偶發(fā)失敗被當(dāng)成不合格品處理。像這種情況根源在測試系統(tǒng)自身不在被測品。5.3 操作員動了夾具位置測試結(jié)果整體漂移還有一次整個白班的測試數(shù)據(jù)功率讀數(shù)都偏低但沒有報警只是每臺設(shè)備的功率都靠近內(nèi)控線下限。我看趨勢圖才發(fā)覺不對勁跑到產(chǎn)線一看原來是操作員嫌掃碼槍線纜礙事把線纜繞在了接收環(huán)天線的連接桿上。線纜帶走了部分射頻能量導(dǎo)致信號幅度整體下降。這個問題的根源是我設(shè)計夾具時沒有考慮產(chǎn)線操作的實用性。后來我把天線連接桿和線纜做了固定走線槽天線周圍用防護罩包起來操作員正常情況下摸不到天線區(qū)域。同時加了一個標(biāo)定流程每天早班用標(biāo)準(zhǔn)應(yīng)答器測一次基準(zhǔn)值如果基準(zhǔn)值偏離正常范圍超過0.2dB測試軟件禁止啟動強制產(chǎn)線找工程師處理?；鶞?zhǔn)值標(biāo)定這個機制之后幫我們擋掉了很多次潛在批量誤判事故。6. 測試數(shù)據(jù)的去向批次追溯和報表管理6.1 原始數(shù)據(jù)存TDMS判定結(jié)果存數(shù)據(jù)庫測試系統(tǒng)的數(shù)據(jù)管理直接影響后續(xù)質(zhì)量追溯和客訴處理。我的設(shè)計是分級存儲原始波形數(shù)據(jù)存TDMS文件判定結(jié)果和核心參數(shù)存數(shù)據(jù)庫報表模板單獨生成。TDMS是NI自家的二進制格式寫入快還能在文件里附帶屬性信息。我把SN碼、測試時間、軟件版本、配置文件版本、儀器校準(zhǔn)信息都寫進TDMS文件的屬性里這樣每一個測試記錄的原始數(shù)據(jù)都是自描述的后期不論誰打開這個文件都能清楚看到當(dāng)時的測試環(huán)境。判定結(jié)果存到了MySQL數(shù)據(jù)庫。數(shù)據(jù)庫中包含一個測試記錄主表和一個測試明細表。主表存SN碼、判定結(jié)果、測試時間、工單號明細表存每一項的具體數(shù)值。這樣產(chǎn)線質(zhì)檢要查某臺設(shè)備的測試歷史輸入SN碼就能拉出全部記錄還能看趨勢。數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計時我加了索引SN碼和時間戳查起來很快幾百萬條記錄也不卡。6.2 報表模板與自動歸檔客戶和內(nèi)部質(zhì)量部都要求提供測試報告用LabVIEW自帶的Report Generation Toolkit生成Excel報表。報表里包含SN碼、產(chǎn)品型號、各項測試值和判定結(jié)果還會附上一個波形截圖方便直觀看到報文解調(diào)情況。每次測試完成后自動生成報表按日期和SN號命名歸檔到服務(wù)器指定目錄。后來質(zhì)量部提了需求希望日報和周報自動統(tǒng)計當(dāng)期的合格率、返修率、各不合格項占比。我用SQL直接查數(shù)據(jù)庫生成統(tǒng)計結(jié)果寫了個定時任務(wù)每天早上自動生成前一天的產(chǎn)線日報發(fā)到指定郵箱。這個功能極大減輕了質(zhì)量工程師的重復(fù)勞動也讓他們更愿意信任這套系統(tǒng)。6.3 關(guān)于數(shù)據(jù)防篡改的一些想法產(chǎn)線數(shù)據(jù)最怕被改。測試結(jié)果是PASS的改成FAIL會造成誤返工FAIL的改成PASS則是質(zhì)量事故。我在數(shù)據(jù)庫表里加了一個校驗字段用SN碼、測試時間、最終判定結(jié)果的字符串算了一個SHA1哈希值任何人在數(shù)據(jù)庫里改了原始字段哈希校驗就會失敗審計時能立刻發(fā)現(xiàn)。這套方法算不上高深但效果很實在。有一次質(zhì)量部做年度審計就靠這個哈希機制確認(rèn)了一段時期內(nèi)的測試數(shù)據(jù)沒有被任何人修改過順利通過了外審。如果你的產(chǎn)線測試系統(tǒng)也有數(shù)據(jù)追溯要求建議從設(shè)計之初就把防篡改考慮進去事后補會非常麻煩。7. 項目維護期的一些體會做完整套LabVIEW應(yīng)答器出廠測試系統(tǒng)后我最大的感受是寫測試邏輯只占整個項目三分之一的工作量另外三分之二用在系統(tǒng)穩(wěn)定性、現(xiàn)場異常處理和數(shù)據(jù)追溯上。LabVIEW的圖形化編程讓這個復(fù)雜系統(tǒng)變得可控但它不會自動幫你解決射頻鏈路、電磁兼容、工業(yè)環(huán)境這些“代碼之外”的問題。有幾個細節(jié)值得后來的同行參考。一是狀態(tài)機一定要有看門狗機制任何一個測試步驟超過最大時間都要自動報錯并復(fù)位儀器避免程序無限卡死二是所有日志都要帶時間戳產(chǎn)線排查問題時最需要的就是“什么時間發(fā)生了什么”三是波形原始數(shù)據(jù)一定要保存下來PASS的也建議存有些質(zhì)量問題幾個月后才能從波形趨勢上看出端倪沒有原始數(shù)據(jù)就只能干瞪眼。這個項目的意義不在于多先進而在于讓一套復(fù)雜的近場耦合射頻測試變得穩(wěn)定、可追溯、可復(fù)現(xiàn)。當(dāng)你看到一臺臺應(yīng)答器在幾秒鐘內(nèi)自動完成所有測試并打出合格標(biāo)簽時會發(fā)現(xiàn)前期踩過的每一個坑都是值得的。