当前位置:首页 > 智能制造 CIM/MES > 正文内容

CP/FT测试数据散落各处?我用Python+SQLite搭了个轻量TDMS

CP/FT测试数据散落各处?我用Python+SQLite搭了个轻量TDMS

【摘要】做良率分析最头疼的不是算法,是找数据:CP测试在设备导出里、FT测试在另一套系统、WIP在MES,分析一次要到处拷文件对半天。我用一个周末搭了个轻量测试数据管理系统(TDMS),统一元数据、秒级检索、趋势直出。这篇文章讲落地全过程。

────────────────────────────────────────────────

一、背景:被测试数据孤岛坑惨的良率工程师

我做YE时,一次客户投诉某批次可靠性异常,要拉这个lot从CP到FT的全链路测试数据做分析。结果CP数据在测试机本地Excel、FT数据在另一套数据库、WIP在MES,三个来源格式还不一样。我对了整整一天才拼出一张表,客户都等急了,电话打了三个过来催。

更常见的是:每周良率复盘,要手动从5台测试机各导一份Excel,合并、清洗、画趋势图,2小时没了。有次漏导了一台机的数据,良率算高了自己高兴,实际那台机的不良被掩盖,周后发现虚惊一场,但会上已经报了假的好数据,信誉受损。

核心痛点是"数据孤岛+无统一元数据"。每台机、每个系统对wafer/lot/程序版本/测试项的命名都不一致,人对不齐、机读不了。2023年我决定自己搭个轻量TDMS(Test Data Management System),不追求大平台,先把"找得到、对得齐、查得快"解决。

说实话,搭之前我也犹豫:是不是该申请采购现成系统?但一问报价和周期(半年起步),我就放弃了。一个周末自己撸一个,先把痛点解了,万一不好用再考虑别的。结果这一撸就用到现在。

二、技术原理:轻量TDMS长什么样

重型TDMS(如Camstar、自主开发的Web系统)功能全但重,部署周期长、需要专职运维,小团队玩不起。我的思路是"够用就好":用SQLite做统一元数据库,测试原始数据按lot存文件,库里只存索引和关键结果,检索快、存储省、单机可跑。

核心是统一的元数据模型:每条测试记录必须有 wafer_id、lot_id、device、test_program(版本)、equipment、test_type(CP/FT)、test_time、关键参数结果。不同来源进来先映射到这个模型,命名就一致了,后续分析不用再为每个来源写适配。

为什么用SQLite而不是MySQL?因为单机、零部署、文件即数据库,复制带走就能用,换新电脑拷文件就行。数据量上亿行时SQLite会变慢,但中小FAB的测试数据(千万级)完全够。真不够再迁PostgreSQL,模型不变,迁移成本低。

检索用SQL:查某lot全链路、查某device近30天良率趋势、查某测试项超spec的分布,一条SELECT搞定,秒级返回。比翻Excel快100倍,且不会漏。

对比重型方案,轻量TDMS牺牲了并发和权限细粒度,但换来了"一个周末能搭起来、零成本、自己完全掌控"。对小团队,这是最优解--先解决80%的痛点,剩下20%等规模上来再说。

一个设计取舍:元数据存库、原始数据存文件。有人会问为什么不直接全存库?因为原始测试数据动辄几GB,全进SQLite会拖慢查询。拆开后,库轻、检索秒级,原始文件按需读取,各取所长。

关于"统一"的度:元数据模型不要追求一步到位覆盖所有字段,先覆盖检索和分析必须的5个,其余按需补。过度设计会让导入器复杂到没人愿意维护。

三、实战:一个周末搭起来的系统

落地分四步,全是Python,边写边测:

第一步,写导入器 importer.py。针对每台测试机的不同格式(CSV/Excel/设备专有格式),写适配器把数据映射成统一模型,写进SQLite。新增设备就加一个适配器,不影响其他。适配器模式让系统可扩展。

第二步,建库 schema。建tests表(元数据+关键结果)、wafers表、lots表,建索引加速检索。原始大数据存parquet文件,库里只留路径和摘要,库轻、检索快。

第三步,写查询接口 query.py。封装常用查询:by_lot、by_device_trend、by_test_item。分析师不用写SQL,调函数就行,降低使用门槛,组内其他人也能用。

第四步,可视化。query结果直接喂matplotlib画良率趋势、参数分布、wafer map。一次分析从"对一天"变成"跑一条命令5分钟出图",效率提升量级明显。

上线后第一次客户投诉,我5分钟拉出全链路数据,客户当场认可响应速度。每周复盘也从2小时变20分钟,且再没漏过数据--导入时强制校验元数据,不齐就不收。

四、为什么要这样写代码

这段代码是统一导入的核心。用INSERT OR REPLACE保证重复导入不报错(测试数据常因重测而重传),ON CONFLICT按lot_id+test_type判重,避免主键冲突打断整批导入。

适配器模式(不同设备不同parse函数)让系统可扩展:新设备只需加一个parse_xxx函数并注册,主流程不动。这是"开闭原则"的实战应用,也是TDMS能从一个周末的小工具长成日常系统的原因。

元数据与原始数据分离存储,库轻、检索快;原始数据留文件可追溯。权衡了查询便利和存储成本,也是SQLite能扛住的关键。

五、效果对比:从对一天到5分钟

搭TDMS前后,单次全链路分析从1天→5分钟,周度良率复盘从2小时→20分钟,且数据完整性从"可能漏"变成"必全"(导入时强制校验元数据,漏导直接告警)。

隐性收益是分析深度:以前来不及做,现在5分钟出图,我开始做以前想做没做的"跨设备参数相关性分析",还真挖出过一个测试程序版本导致的隐性良率损失(某版本CP程序漏测了一项,导致不良流到FT才暴露)。这种发现,靠手工对数据是永远做不到的。

ROI角度:这个系统一个周末搭成,零软件成本,省下的是YE每周2小时乘常年。按工程师时薪折算,一年隐性收益就有大几万,更别说几次客户投诉的快速响应带来的口碑。

六、实施建议:先定标准再写代码

1. 先定元数据标准:wafer/lot/device/程序版本/测试类型这五个字段必须先统一,这是TDMS的地基,不定后面全乱。我花了一天和测试组对齐这五个字段的定义。

2. 导入即校验:数据进库前强制校验元数据完整性,缺字段就拒收并告警,别等查询时才发现对不齐。宁可少收,不能收错。

3. 原始数据留底:统一模型只存摘要,原始文件必须留(parquet/原文件),出问题可回查,也满足客户审计要求。

4. 从一个测试类型起步:先接CP或FT一种,跑顺再扩,别一上来想接全厂所有机台,容易卡在适配器细节里。

5. 备份库文件:SQLite是单文件,定时拷到网络盘,丢了就一无所有。我设了每天凌晨自动备份到NAS。

6. 封装查询函数:别让同事写SQL,封装成by_lot/by_device这种函数,降低使用门槛,系统才用得起来。

推广时降低门槛:写好README和示例,让测试组的人也能自助查,系统才活起来。只你自己会用的工具,迟早随你忙而荒废。

七、进阶方向:从孤岛到闭环

轻量TDMS下一步是接自动流转:测试机做完自动推数据到系统,不用人工导。这需要测试机开放接口或加一个监听程序,技术上不难,难在和测试组协调流程。

再进一步,TDMS和YMS(良率管理系统)、FDC打通,测试异常自动触发FDC分析、良率自动归集,形成闭环。那是大厂玩法,小团队可以分步靠近--先把TDMS这环做实。

数据量上亿时,把SQLite迁到PostgreSQL+DuckDB做分析,模型不变,平滑升级,前期投资不浪费。

数据多了之后,可以加一层"自动洞察":比如某device良率连续3天下滑自动标红并推送给YE,不用人每天盯着趋势图。这是TDMS从"仓库"变"哨兵"的关键一步。

再远一点,TDMS沉淀的数据是训练良率模型的金矿。我们后来直接用TDMS里的标准化数据训了良率预测模型,数据清洗时间从两周降到两天,TDMS的价值从这开始滚雪球。

效果对比

完整代码

import sqlite3, pandas as pd con = sqlite3.connect('tdms.db') con.execute(CREATE TABLE IF NOT EXISTS tests( lot_id TEXT, wafer_id TEXT, device TEXT, test_type TEXT, program_ver TEXT, equipment TEXT, test_time TEXT, yield REAL, raw_path TEXT, PRIMARY KEY(lot_id, test_type, program_ver))) con.commit() def import_test(df, raw_path): df['raw_path'] = raw_path df.to_sql('tests', con, if_exists='append', index=False, method='multi') print(f"导入 {len(df)} 行 -> {raw_path}") trend = pd.read_sql(SELECT test_time, AVG(yield) FROM tests WHERE device='ABC123' AND test_type='CP' GROUP BY test_time ORDER BY test_time, con) print(trend.head())

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📝 发布后复制到评论区:

你在FAB里遇到过模型上线后悄悄变差的情况吗?或者有哪些数据质量的坑?欢迎在评论区聊聊你的真实经历,我会一一回复。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

💎 本文配套VIP资源:相关工具已打包上传CSDN资源区(关注后可直接下载)。更多半导体AI实战工具,关注我持续更新。

👉 关注我,持续分享半导体智能制造一线实战。

标签: 半导体

相关文章

良率工程实战:从72%到89%的完整爬坡路径

良率工程实战:从72%到89%的完整爬坡路径

良率工程实战:从72%到89%的完整爬坡路径 一、问题背景:良率是晶圆厂的生命线 良率(Yield)是晶圆厂最核心的KPI,直接决定了盈利能力和市场竞争力。我在晶圆厂负责良率工程的这些年,深刻体会到良...

SPC统计过程控制:FAB质量管理的定海神针

SPC统计过程控制:FAB质量管理的定海神针

SPC统计过程控制:FAB质量管理的定海神针 Statistical Process Control — 用数据说话,让异常无处遁形 一、问题背景:FAB里每天产生上百万个数据点,靠什么来管理质量?...

刻蚀工艺深度解析:干法刻蚀vs湿法刻蚀怎么选

刻蚀工艺深度解析:干法刻蚀vs湿法刻蚀怎么选

刻蚀工艺深度解析:干法刻蚀vs湿法刻蚀怎么选 大家好,我是老张。前面讲完了光刻,今天聊聊刻蚀(Etching)。如果说光刻是「画图」,那刻蚀就是「刻字」——把光刻转移到光刻胶上的图形,精确地转移到下面...

半导体产业全景:从沙子到芯片的完整产业链

半导体产业全景:从沙子到芯片的完整产业链

半导体产业全景:从沙子到芯片的完整产业链 大家好,我是老张,在半导体行业摸爬滚打了十五年。从Fab厂的一线工艺工程师,到现在的产业分析师,我有幸见证了这个行业最波澜壮阔的十年。今天,我想用最接地气的方...

CMP化学机械抛光:让晶圆表面平整到原子级

CMP化学机械抛光:让晶圆表面平整到原子级

CMP化学机械抛光:让晶圆表面平整到原子级 Chemical Mechanical Planarization — 半导体制造中最精密的表面平坦化技术 一、问题背景:为什么芯片需要"磨皮&q...

MES制造执行系统:半导体FAB的信息中枢到底管什么

MES制造执行系统:半导体FAB的信息中枢到底管什么

MES制造执行系统:半导体FAB的信息中枢到底管什么 Manufacturing Execution System — 当FAB遇上数字化转型,信息流如何驱动价值流? 一、问题背景:FAB一天产生几个...