從事半導體制造或者封測這一行的朋友應該都對“良率”這倆字又愛又恨。它直接跟錢掛鉤跟產能掛鉤跟客戶信任掛鉤。但真要把良率分析做好尤其是當產品進入量產爬坡或者遇到異常波動時你手里得有足夠“干凈”且“全面”的數(shù)據(jù)否則一切分析都是空談。我這兩年深度參與了公司良率分析平臺的數(shù)據(jù)底座建設核心工作就是把產線上那些五花八門的設備數(shù)據(jù)、工藝數(shù)據(jù)、測試數(shù)據(jù)給“揉”到一塊。今天這篇就專門聊聊多源數(shù)據(jù)集成這件事在半導體良率分析平臺里到底是怎么落地的又踩了哪些坑。這套東西不光是給數(shù)據(jù)分析師看的做設備自動化EAP、搞SECS/GEM協(xié)議對接、以及負責MES維護的兄弟我建議都花幾分鐘看看因為你們每天經手的那些報文和數(shù)據(jù)正是整個平臺的“口糧”。1. 為什么良率分析平臺必須做多源數(shù)據(jù)集成先別急著談技術架構我們得先聊聊“為什么”。很多人覺得良率分析不就是看看CPCircuit Probing晶圓探針測試和FTFinal Test最終測試的map圖嗎哪有那么復雜。如果你只做成品良率的統(tǒng)計報表那確實不復雜Excel都能干。但只要你想做一點深度的根因分析比如“這批晶圓邊緣區(qū)域的失效為什么突然變多”你會立刻發(fā)現(xiàn)你需要的數(shù)據(jù)壓根就不在同一個地方。1.1 良率分析的“五馬分尸”困局一條典型的半導體產線從硅片進廠到最后出貨數(shù)據(jù)散落在至少五個獨立的系統(tǒng)里。設備數(shù)據(jù)來自光刻機、刻蝕機、薄膜沉積設備、清洗機等工藝設備。這些設備每秒鐘都在產生海量的實時數(shù)據(jù)包括腔體壓力、溫度、射頻功率、氣體流量、機械手臂位置等等。這些數(shù)據(jù)通常通過SECS/GEM協(xié)議傳給EAP系統(tǒng)或者存在設備本地的歷史庫里。測試數(shù)據(jù)這是良率分析的核心主要來自測試機比如Teradyne的UltraFlex系列也就是大家常說的93K、探針臺Prober和分選機Handler。這里的數(shù)據(jù)包括每顆Die的測試結果Bin號、電壓電流參數(shù)、良率map圖等。注意測試數(shù)據(jù)又分CP和FT兩種數(shù)據(jù)格式和含義完全不同。制造執(zhí)行數(shù)據(jù)存儲在MES制造執(zhí)行系統(tǒng)里記錄了批次Lot的加工路徑Route、在制品WIP信息、設備派工情況、操作員信息、工藝配方Recipe版本等。工藝配方數(shù)據(jù)通常是設備端Recipe的具體參數(shù)設置。有時候MES里只記錄了Recipe的ID和版本但Recipe內部的詳細參數(shù)只有設備控制器里才有。** defect檢測數(shù)據(jù)**來自缺陷檢測設備如KLA的暗場/明場檢測設備的缺陷坐標、缺陷尺寸、缺陷類型ADC分類結果等。這五個系統(tǒng)的數(shù)據(jù)格式完全不同時間粒度不同設備廠商的通信協(xié)議也不同。要做良率分析就得把這五個源頭的數(shù)據(jù)按照“晶圓ID 設備ID 加工時間 工藝步驟”的維度對齊起來。這就是多源數(shù)據(jù)集成存在的唯一理由消除數(shù)據(jù)孤島讓數(shù)據(jù)的關聯(lián)分析成為可能。1.2 數(shù)據(jù)集成解決的兩個核心業(yè)務問題數(shù)據(jù)集成不是目的解決業(yè)務痛點才是目的。在我看來它主要解決兩件事第一件事是異常回溯。產線反饋某批貨良率突然從97%掉到90%傳統(tǒng)的做法是工藝工程師憑經驗猜是哪個步驟出了問題然后去翻該設備的歷史記錄。有了多源數(shù)據(jù)集成的平臺你只需要輸入Lot ID系統(tǒng)自動關聯(lián)出這批貨經過的所有設備、所有工藝參數(shù)、所有測試結果甚至能自動匹配到當時的環(huán)境溫濕度。分析時間從按“天”計算縮短到按“分鐘”計算這就是集成帶來的直接價值。第二件事是參數(shù)相關性挖掘。光刻機的聚焦精度Focus和刻蝕機的射頻駐波比VSWR之間可能對最終的晶體管閾值電壓Vt有交互影響。這種跨設備的關聯(lián)分析在數(shù)據(jù)孤島時代幾乎沒法做。但把數(shù)據(jù)都拉到一個平臺里用簡單的相關性分析或者機器學習模型就能找到那些隱藏的“魔鬼組合”。這類分析對于先進工藝的良率爬坡至關重要。2. 數(shù)據(jù)集成方案的核心設計與技術選型現(xiàn)在大家都喜歡談“數(shù)據(jù)中臺”、“湖倉一體”但半導體產線里的數(shù)據(jù)集成方案選型往往沒有那么自由。因為現(xiàn)場環(huán)境對數(shù)據(jù)安全、實時性、穩(wěn)定性的要求極高而且在產線里搞平臺最怕“動靜太大”影響生產。2.1 數(shù)據(jù)流向與分層架構規(guī)劃我參與搭建的這套平臺在邏輯上分了四層采集層、傳輸層、存儲層、應用層。采集層這一層負責跟設備打交道。對于支持SECS/GEM協(xié)議的設備絕大部分前道工藝設備和后道測試設備都支持直接通過EAP系統(tǒng)的接口拿數(shù)據(jù)。對于沒有標準通信接口的老舊設備或者SECS協(xié)議里沒定義的數(shù)據(jù)比如設備內部日志文件就得靠駐留agent的方式主動去拉取或者接收文件。傳輸層考慮到產線網絡通常和辦公網隔離數(shù)據(jù)傳輸不能直接穿透。我們是部署了一套基于消息隊列Kafka的緩沖機制在產線DMZ區(qū)架設了數(shù)據(jù)轉發(fā)服務。數(shù)據(jù)先落地到產線側的本地存儲再由轉發(fā)服務異步上傳到分析平臺所在的核心數(shù)據(jù)區(qū)。這樣做的好處是即使分析平臺升級或者網絡抖動也不會影響產線設備的數(shù)據(jù)采集EAP系統(tǒng)和設備不受牽連。存儲層這是很多人容易搞錯的點。我們并沒有把所有的數(shù)據(jù)全塞進一個庫而是采用了“混合存儲”策略。設備產生的實時狀態(tài)數(shù)據(jù)比如每100ms一條的RF功率數(shù)據(jù)量太大存進時序數(shù)據(jù)庫如InfluxDB或TDengine。測試結果數(shù)據(jù)Die級別的Bin信息結構化程度高且查詢頻繁放在關系型數(shù)據(jù)庫如PostgreSQL。設備報警日志、Recipe文件等非結構化數(shù)據(jù)則存放在對象存儲如MinIO里。應用層這一層就是良率分析平臺真正給用戶看的界面和功能了。包括良率報表、SPC監(jiān)控、Map圖分析、多變量分析模塊等。這個分層架構的核心思想是“各司其職”尤其要把實時采集鏈路和批量分析鏈路分開。因為實時采集要求低延遲而批量分析往往需要跑復雜的聚合查詢兩者如果混在一起互相拖后腿現(xiàn)場會非常難受。2.2 選型背后的“為什么”在技術選型上我有幾個比較深的體會供參考。消息隊列為什么選Kafka因為我們需要應對“秒級”的數(shù)據(jù)峰值。比如一臺93K測試機在測試小芯片時每秒可能產生上萬條測試結果事件。這種高吞吐場景Kafka的吞吐能力是其他一些消息中間件很難比的。而且Kafka自帶分區(qū)和副本機制數(shù)據(jù)不容易丟。時序庫為什么單獨拎出來而不直接用關系型數(shù)據(jù)庫因為良率分析不僅要看“最終結果”還要看“過程曲線”。比如分析刻蝕機腔體壓力數(shù)據(jù)我們要看的是升壓、穩(wěn)壓、抽真空整個過程中壓力值的變化曲線。這種數(shù)據(jù)每秒產生幾十甚至上百個點一張晶圓加工下來就是幾十萬條記錄。用關系型數(shù)據(jù)庫存這種數(shù)據(jù)查詢性能會隨著數(shù)據(jù)量增大迅速惡化。時序數(shù)據(jù)庫的壓縮算法和預聚合能力就是為這種場景量身定制的。這里也順帶提醒一句別迷信所謂“一套平臺搞定所有數(shù)據(jù)”的商業(yè)產品。半導體工廠的數(shù)據(jù)基因太特殊了標準化產品往往需要大量二次開發(fā)。在選型初期一定要明確哪些功能是產品自帶的哪些需要我們自己的開發(fā)團隊去定制不然后期定制開發(fā)的成本會遠超預算。2.3 數(shù)據(jù)模型的標準化與擴展性數(shù)據(jù)集成最怕的就是“臟數(shù)據(jù)”和“二義性”。沒有一個統(tǒng)一的數(shù)據(jù)模型集成得越多可能越亂。所以我們做了一個比較關鍵的動作就是建立良率分析數(shù)據(jù)模型標準。這個模型的核心是一個事實表Fact Table它記錄了每一次“測量行為”本身。什么晶圓Wafer ID、什么批次Lot ID、在什么設備Equipment ID、哪個腔室Chamber ID、哪個工序Operation Code、用的什么RecipeRecipe ID以及測試或測量的原始結果值。所有的維表設備表、產品表、工序表都圍繞這個事實表建立。另外還有一個關鍵字段是“時間戳”但這個時間戳必須以設備服務器時間為基準而不是MES時間或者平臺接收時間。標準化模型的好處是顯而易見的。新增一種設備類型時只要按照這個模型適配出對應的數(shù)據(jù)映射關系開發(fā)工作量會顯著降低。后續(xù)的數(shù)據(jù)分析工具、報表工具也只需針對這一套模型進行開發(fā)不用像以前那樣一個系統(tǒng)配一套開發(fā)。3. 核心環(huán)節(jié)實現(xiàn)從SECS/GEM到EAP再到平臺這里重點說一說數(shù)據(jù)鏈路中最關鍵、也最容易出問題的一段從設備通過SECS/GEM協(xié)議產生數(shù)據(jù)到EAP系統(tǒng)處理再到數(shù)據(jù)集成平臺落庫的過程。3.1 SECS/GEM協(xié)議對接的實戰(zhàn)要點在半導體設備通信里SECS/GEM是繞不開的協(xié)議族。包括SECS-I基于RS-232串口和HSMS基于TCP/IP以及定義了數(shù)據(jù)項和消息的SECS-II還有定義設備行為狀態(tài)的GEM標準SEMI E30。雖然現(xiàn)在新設備都支持HSMS了但工廠里總有那么幾臺老設備還是串口通信或者串口轉網口的轉換器。協(xié)議對接里最重要的事并不是把報文收發(fā)通就算完而是要保證業(yè)務邏輯的完整性。我舉個例子EAP系統(tǒng)要判斷一張晶圓在當前設備上的加工是否結束不能只看設備的“Process End”消息還要結合Equipment Constant設備常數(shù)里的狀態(tài)值來確認。不同設備廠商對GEM狀態(tài)機的實現(xiàn)千差萬別有的設備把“Processing”狀態(tài)細分為好幾個子狀態(tài)有的則沒有。所以在做SECS/GEM對接時不能簡單套用模板必須逐個設備地去核對狀態(tài)模型。我建議搞一個“設備兼容性清單”表格記錄每種設備廠商/型號支持哪些標準事件IDCEID、哪些狀態(tài)變量SVID、哪些數(shù)據(jù)變量DVID這些對我們的集成平臺來說就是元數(shù)據(jù)Metadata。有了這個清單后面的開發(fā)調試能少走很多彎路。3.2 EAP系統(tǒng)腳本部署的關鍵邏輯EAPEquipment Automation Program是連接設備和上層系統(tǒng)的“神經中樞”。在集成項目里EAP不僅要處理SECS消息還要決定數(shù)據(jù)往哪兒轉發(fā)。以測試設備為例。當探針臺在測試一顆Die并產生結果后測試機通過SECS/GEM的Event消息比如CEID1000代表測試完成把結果發(fā)給EAP。EAP收到這個消息后做的第一件事不是轉發(fā)而是校驗上下文。它會檢查這條消息里攜帶的Wafer ID是否和當前正在執(zhí)行的Lot ID匹配檢查產品的加工步驟是否和MES派工一致。只有校驗通過的消息才會被轉換成標準的數(shù)據(jù)格式再發(fā)送給Kafka最終寫入時序庫和關系庫。那些校驗失敗的數(shù)據(jù)會被標記為異常進入專門的“懸掛隊列”等待人工處理。這里有個非常容易忽略的細節(jié)EAP腳本的狀態(tài)處理必須考慮設備復機Recovery的場景。比如設備在加工中途突然報警停機操作員進行處理后重新開始加工此時EAP的狀態(tài)機必須能正確“恢復”如果恢復邏輯沒做好可能出現(xiàn)設備已經重新開始加工了但EAP還認為設備在“等待搬運”導致數(shù)據(jù)丟失或重復。3.3 93K測試機數(shù)據(jù)的采集與解析說到93KTeradyne UltraFlex用過的人都知道它的數(shù)據(jù)文件格式和“市面上”常見的測試數(shù)據(jù)格式不太一樣。除了通過SECS/GEM與EAP聯(lián)動之外93K還會生成大量的測試日志文件如 .dat 或 .txt 格式這些文件包含每個測試項的詳細測量值比如某個引腳的漏電流值、輸出高電平電壓值。我們采集93K數(shù)據(jù)的方案是雙軌并行軌道一走SECS/GEM事件實時拿到每顆Die的Bin號和Map圖信息軌道二通過文件采集器定時掃描測試機指定的輸出目錄把詳細的測試參數(shù)文件抓取到平臺解析后入庫。這樣既保證了map圖的實時性也保證了分析參數(shù)時的完整精度。解析93K的數(shù)據(jù)文件有一點要特別小心文件內的記錄順序并不等于測試順序。因為測試機是并行測試多個Site的文件里的數(shù)據(jù)是按照測試資源Site分組排序的。如果你按行讀取后直接當成時間序列去分析很可能會得出完全錯誤的結論。正確的做法是在解析文件時先按“Site TestName Instance”這三個維度對數(shù)據(jù)進行分組再按內部的Sequence號排序這樣得到的數(shù)據(jù)才是準確的。4. 常見問題與排查技巧實錄多源數(shù)據(jù)集成平臺的上線從來不是一蹴而就的。這個過程中我們遇到的典型問題可以說是不勝枚舉。這里挑幾個發(fā)生率最高、排查起來最費勁的問題給大家做個交流。4.1 設備數(shù)據(jù)“幽靈重復”問題有一次我們發(fā)現(xiàn)某臺刻蝕機的腔體壓力數(shù)據(jù)在凌晨3點左右出現(xiàn)了約5分鐘的數(shù)據(jù)重復也就是說同一個時間戳的數(shù)據(jù)出現(xiàn)了兩條一模一樣的記錄。起初以為是采集程序bug排查了很久最后發(fā)現(xiàn)是設備端的SECS通信模塊在凌晨做了一次“重連”。重連時設備會重新發(fā)送緩存的最近幾筆事件數(shù)據(jù)以保證服務器端狀態(tài)同步。而我們的EAP腳本沒有識別出這是重復事件簡單地全量轉發(fā)到了Kafka。排查思路與解法面對這種情況單純靠時間戳去重往往不夠因為設備重啟后時間戳也可能重置。比較好用的方式是在采集端和設備端之間建立冪等機制。我們在數(shù)據(jù)模型里加了一個“全局唯一ID”由EAP根據(jù)設備ID和事件序列號SECS報文頭里的SYS字節(jié)生成。當存儲層檢測到相同的全局唯一ID重復出現(xiàn)時直接忽略。另外通過設置一套“設備不同步時間補償參數(shù)”也可以解決部分由于設備時鐘偏移導致的時序錯亂。4.2 多設備間時間不同步的噩夢如果分析時發(fā)現(xiàn)一張晶圓的工藝配方和測試結果對不上且時間順序明顯亂序大概率是設備時間沒同步。產線里幾十臺設備不可能每臺都去手動校時。有的設備工程師圖省事關了設備后重啟時間返回到了出廠設置于是整個時間段的數(shù)據(jù)時間軸就亂了。排查思路與解法我們最終是靠“三級校時”解決的。第一級在網絡層面啟用NTP服務器讓所有設備都同步到同一個時間源。第二級在設備接入平臺時采集軟件會先獲取設備當前時間和平臺時間對比偏差超過5秒就會發(fā)起告警并在數(shù)據(jù)中打上時間偏差標記。第三級在數(shù)據(jù)分析層我們允許特定場景如缺陷分析使用“設備加工步驟序號”而不是絕對時間進行數(shù)據(jù)對齊。這樣即使絕對時間有偏差步驟之間的先后關系依然不會錯。4.3 Recipe版本混亂導致的數(shù)據(jù)歸因錯誤有一次工藝工程師說某批次產品在光刻工序后關鍵尺寸CD測量值偏大。平臺自動關聯(lián)了那臺光刻機的Recipe版本發(fā)現(xiàn)用的是老的Recipe V2.3。但MES顯示施工單上要求用的是新的V2.5。這意味著設備工程師現(xiàn)場改了Recipe但MES沒更新導致數(shù)據(jù)分析歸因時匹配到了錯誤的信息。排查思路與解法這是典型的“數(shù)據(jù)源之間字段不一致”問題。MES里記錄的是“工藝要求的Recipe”而設備實際執(zhí)行的是“本地加載的Recipe”。要解決這個問題必須把“計劃要求”和“實際執(zhí)行”兩層數(shù)據(jù)獨立采集、獨立存儲、再在分析層做對比。我們在EAP腳本中增加了一個邏輯當MES下達批次的Recipe要求后EAP在設備啟動加工前會回讀設備當前的Recipe名稱和修改時間如果不匹配就禁止啟動加工或發(fā)送告警。并且平臺里保存的Recipe數(shù)據(jù)是以“設備端回讀的實測值為準”而不是MES的登記值。5. 一些壓箱底的避坑建議如果前面講的都是“術”的層面那最后這部分算是“道”的經驗。多源數(shù)據(jù)集成項目到后期往往拼的不是技術而是對產線現(xiàn)場規(guī)則的理解和對不確定性的容忍度。別忽視數(shù)據(jù)字典的維護。設備廠商的技術支持提供的SECS數(shù)據(jù)字典往往只有簡單的變量名和描述。但真正到了使用的時候你會發(fā)現(xiàn)同一個變量名在不同設備型號下的物理含義可能不同。比如“RF_POWER”在等離子體刻蝕機里可能是“下電極射頻功率”在PECVD設備里可能就是“射頻源功率”。這份數(shù)據(jù)字典最好由項目組自己結合工藝知識重新梳理一遍形成企業(yè)的標準數(shù)據(jù)字典維護好它是平臺能夠長期發(fā)揮作用的生命線。數(shù)據(jù)質量監(jiān)控必須前置。不要等業(yè)務用戶發(fā)現(xiàn)報表異常了才去檢查是不是數(shù)據(jù)采集的問題。我們在平臺上建了一個數(shù)據(jù)“健康度看板”實時統(tǒng)計每分鐘從每條鏈路收到的數(shù)據(jù)條數(shù)、時間戳延遲、重復率、空值率。任何一個指標遠超基線系統(tǒng)自動推送告警到值班群。這樣能省掉后續(xù)大量“背鍋式”排查時間。集成平臺與產線系統(tǒng)解耦是底線。這一點我非常堅持。集成平臺就是用來“吸”數(shù)據(jù)的它不應該反向依賴產線系統(tǒng)的實時響應。哪怕分析平臺宕機了產線上的EAP、MES也應該正常流轉只是歷史數(shù)據(jù)暫時無法同步而已。這靠的就是前文提到的“傳送帶”架構產線數(shù)據(jù)先把數(shù)據(jù)寫到本地緩沖再由單向的數(shù)據(jù)搬運服務搬到平臺。任何時刻都不要開“雙向通道”否則一個邊緣系統(tǒng)的變更就可能引發(fā)生產事故。說到底良率分析平臺的多源數(shù)據(jù)集成表面上看是技術問題實質上考驗的是對半導體制造全流程的理解深度。它能走多遠不取決于用了多貴的大數(shù)據(jù)組件而取決于你對產線上每一個數(shù)據(jù)來源的“脾氣”摸得有多透。把基礎打牢后續(xù)分析才能有恃無恐。