功能測試在MES中的應用與控制

筆者通過對UGS的MES產品使用和實施過程中，總結出對于功能測試MES應該覆蓋到的功能與應用情況。希望能夠對于MES在功能測試的設計與實施方面提供一些指導和幫助。



一、引言
MES是近年來緊隨ERP、PDM之后，另一個對于生產制造起著關鍵作用的系統，相對于ERP和PDM而言，MES更加貼近生產線，對于生產線的管理和指導作用更加明顯。然而正是因為MES更加貼近生產線，以及各個生產商由于產品類型、生產流程和管理上的不同差異，導致對于MES的需求各不相同。功能測試作為每個生產商比較核心的一塊，其對MES的需求筆者認為較為接近。

當前功能測試基本過程就是當測試的產品到達指定的測試工位后，用特殊的測試程序進行功能測試。如果測試通過，該產品將流入到下一道工序；如果測試失敗，那么將進行一定次數的重測，如果依舊失敗，則將被送到維修工位進行故障分析。

同時測試完畢以后有些功能測試是會生成測試數據文件，有些不能產生。如果產生了測試數據文件，其測試數據文件一種方式是直接存入到數據庫，另一種方式是先存放到本地，然后將文件上傳到指定的服務器。所以作為功能測試，其比較重要的特征就是有一個內容豐富的測試數據，該測試數據不但記錄了測試的狀態，還記錄了各個測試項目的結果以及這些測試項目存在問題。有些產品的功能測試過程包括多個測試步驟，這些測試步驟之間有些存在嚴格的先后次序，有些則沒有嚴格的先后次序。

所以在電子行業里面，功能測試的流程是相對復雜的。MES作為工廠流程控制、數據采集、信息反饋以及信息追蹤的系統，如何對功能測試流程進行系統的管理和控制，其難度是不言而喻的。

二、MES能夠對功能測試做什么？
●測試流程的控制
每一步功能測試，對于產品的生產都是不可缺少的，這對于保證產品的性能非常重要。筆者通過對各個工廠的功能測試的分析，筆者認為在測試流程的控制上，MES必須要保證下面兩個要求。

1）能夠定義測試工藝路線
工藝路線的定義主要有兩個目的：確定該工藝路線需要的測試步驟，測試工藝路線因為產品的不同而不同，所以MES必須有效的將工藝路線和產品進行自動關聯起來；確定各個測試步驟之的關系，有些工藝步驟之間必須遵循一定的先后順序，有些測試工藝步驟可以并行測試。

能否根據產品自身流程在MES定義對應的工藝路線，是決定MES能否具有有效“防呆”管理功能。工藝路線是由單個的測試工藝步驟組成，每個工藝步驟又和操作工位、維修工位存在聯系。MES需要能夠記錄功能測試的每次操作，例如哪個測試步驟、哪個測試工位、如果失敗應該送到哪里維修、哪個員工在什么時候測試的。

圖1是公司的MES產品提供的測試工藝路線定義模型，該工藝路線模型包含了所有的測試步驟、測試步驟之間的關系以及測試步驟和維修之間的關系。所以生產執行時，MES將能根據該工藝路線進行測試的“防呆”管理。但是該“防呆”動作只有觸發了MES操作，才能進行。模板本身還是能夠進行功能測試的，由于每步功能測試的時間較長，如何能夠在測試開始之前，即使沒有進行MES操作，也能進行有效的“防呆”管理？所以MES必須具備接下面將談到的要求。



2）能夠在進行測試之前，能夠進行測試步驟的檢驗
如果要實現這個要求，必須要使得MES和功能測試程序能夠有機的結合起來。因為MES包含了產品能否從事該測試步驟的信息，而功能測試程序控制了測試的開始和結束，只有將兩者的功能結合起來，才能達到完美的“防呆”效果。

那么兩者如何能夠有機的結合起來？筆者認為MES必須能夠提供開放的API接口函數RouteCheck，同時生產商可以將這個API函數嵌入到自身的測試程序里面。那么在測試開始之前，測試程序就會調用該API,進行RouteCheck工作，確定產品是否能夠進行該項測試步驟。

●測試數據的自動采集和不良的自動錄入
如果測試數據一旦存到本地或者數據庫，MES就有機會能夠對測試數據進行自動分析和采集。一般情況下測試數據包含測試序列號、測試工位、測試時間、測試人、測試結果、測試項目和測試值等等。

所以MES必須具有某個模塊能夠時刻監聽測試機器或者數據庫是否產生了一筆新的測試結果，一旦測試結果產生了，就必須將其測試數據進行解析，存儲在MES相應的表中。這里必須注意到一點的是，有些測試程序是邊測試邊產生測試結果。MES對其分析必須設定一段時間的延遲，否則解析出的數據不是完整的。

由于生產商在沒有實施MES之前，其測試數據里面一般不包含測試步驟這個信息。例如圖1所示的“TESTA”。而MES是需要這個關鍵的測試步驟信息，所以要實現完全自動數據采集，生產商必須在測試數據里面加入這個信息。否則需要在MES的客戶端設定當前的測試步驟，如果當前客戶端對應的測試步驟因產品而不同，則需要測試人員因產品而手動修改。

由于因客戶和產品的不同，其測試數據的格式與規范會大不相同，MES如何幫助不同的客戶實現這共同的目的？MES必須具有統一的自動數據搜集平臺，并且提供測試文件解析器開發工具給用戶，用戶能夠根據自身測試文件格式規范的不同，開發出符合自身需要的解析器。實際運用時，通過解析器分析數據，然后將數據傳遞給數據收集平臺，數據收集平臺最終將數據傳遞給MES。同時解析器開發工具必須簡單而且易于上手。

如果客戶希望對測試數據中的關鍵測試項目進行SPC分析,那么對于關鍵測試項目和測試值，MES必須要能夠單獨將其單獨存儲。這樣在今后做SPC分析時，數據的提取就非常容易。

如果測試數據顯示該測試失敗，并顯示失敗的項目，那么MES必須也能夠把相應的信息錄入到數據庫中，并顯示當前的狀態是失敗的。大多數生產商不會把測試項目當作不良名稱，因為可能多個測試項目不良對應同一個不良名稱，便于數據統計。

所以用戶可以在MES建立測試項目不良對應的不良名稱列表，這樣在產品測試不良送修時，維修人員首先看到的是不良名稱，進一步查看時才顯示哪個測試項目失敗。

●重測的控制
大多數生產商的功能測試都允許重測，即第一次測試失敗以后，可以進行重測，當重測成功以后產品可以進入下一步測試流程，當重測失敗以后還可以進行再一次的重測。只有當重測達到一定的次數以后，就不允許繼續測試了，必須送去維修。筆者曾經發現某個PCBA板被幾個操作員重測達20多次，實際企業規定重測的次數不能超過3次。如何控制重測次數，對于提高生產效率是很重要的。

MES包含了產品每次測試信息，而功能測試程序控制了測試的過程。所以要達到控制重測的目的，功能測試程序需要從MES得到該產品已經連續在本測試步驟做了多次，如果超過指標，彈出警告信息并停止測試。所以需要MES能夠提供這樣計算測試重測次數API函數，并嵌入到功能測試程序中去。



●測試維修的管理和返測的控制
對于功能測試的維修，大多生產商分為測試診斷和測試維修兩塊。測試診斷負責根據提示的錯誤信息和自身的經驗，分析出產品出現問題的根源，是某個芯片有問題，還是某個線路短路，并提出相應的維修策略，例如更換某個元件；測試維修負責根據診斷提出的維修策略進行實際的維修動作，維修完畢以后，要再進行一次測試，如果測試通過，表示產品維修完成，返還給生產線。如果依舊存在有問題，說明前次診斷是誤判，必須送給診斷人員進行再一次的分析，直到產品最終維修好。

維修的過程信息對于生產商非常重要，所以MES必須記錄診斷人員每次診斷過程，維修人員的維修時間，如果有換料的維修動作，還必須記錄物料的信息以便今后的追溯。一旦MES實現這樣的功能，從MES數據庫中就能很快了解每個診斷工程師的技能，那些工程師誤判的次數最少。

同時對于每種不良現象的最終原因可以在MES進行知識庫的累積，下次同樣的問題出現時，可以在MES很快的知道，對于以前的同樣問題，以前的維修記錄是什么樣的，哪個零件出現問題的概率最大，這樣很方便指導分析維修過程，摒棄經驗的習慣，提高維修的效率。

產品維修成功后，需要重新返還給生產線進行測試，如果該產品包含有多個測試步驟的情況下，例如產品包含測試步驟為T1、T2和T3。如果在測試步驟T2出現了問題，并維修完畢后，那么該產品是送到生產線的測試步驟T2開始測試，還是從測試步驟T1開始？這個問題取決于生產商和產品的不同而不同，有些產商認為只要做過維修就必須從新開始測試，有些則認為只有維修更換過元件才需要重新開始測試。所以MES必須能夠針對維修的動作定義不同的返回路徑。

要，所以MES必須記錄診斷人員每次診斷過程，維修人員的維修時間，如果有換料的維修動作，還必須記錄物料的信息以便今后的追溯。一旦MES實現這樣的功能，從MES數據庫中就能很快了解每個診斷工程師的技能，那些工程師誤判的次數最少。

同時對于每種不良現象的最終原因可以在MES進行知識庫的累積，下次同樣的問題出現時，可以在MES很快的知道，對于以前的同樣問題，以前的維修記錄是什么樣的，哪個零件出現問題的概率最大，這樣很方便指導分析維修過程，摒棄經驗的習慣，提高維修的效率。

產品維修成功后，需要重新返還給生產線進行測試，如果該產品包含有多個測試步驟的情況下，例如產品包含測試步驟為T1、T2和T3。如果在測試步驟T2出現了問題，并維修完畢后，那么該產品是送到生產線的測試步驟T2開始測試，還是從測試步驟T1開始？這個問題取決于生產商和產品的不同而不同，有些產商認為只要做過維修就必須從新開始測試，有些則認為只有維修更換過元件才需要重新開始測試。所以MES必須能夠針對維修的動作定義不同的返回路徑。