当前位置：首页 > MES/ERP 工厂落地实战 > 正文内容

CP/FT测试数据管理：SQLite轻量TDMS

CP/FT测试数据散落各处?我用Python+SQLit

【摘要】

本文系统梳理电性测试与 Bin 分析领域的核心问题与落地路径。【摘要】做良率分析最头疼的不是算法,是找数据:CP测试在设备导出里、FT测试在另一套系统、WIP在MES,分析一次要到处拷文件对半天。全文围绕「背景:被测试数据孤岛坑惨的良率工程师、技术原理:轻量TDMS长什么样、实战:一个周末搭起来的系统、为什么要这样写代码、效果对比:从对一天到5分钟」逐层展开，给出原理说明、实操步骤与验证方法。核心结论：再远一点,TDMS沉淀的数据是训练良率模型的金矿。补充说明：WAT 在划片前对测试键做电性测量，用于判断工艺是否处在规格内；CP 对每颗芯片做功能测试并生成 Bin Map；FT 在封装后做最终规格确认。三者的数据串联起来才能完整反映「工艺-器件-成品」链条。

【核心要点】

背景:被测试数据孤岛坑惨的良率工程师：我做YE时,一次客户投诉某批次可靠性异常,要拉这个lot从CP到FT的全链路测试数据做分析。
技术原理:轻量TDMS长什么样：重型TDMS(如Camstar、自主开发的Web系统)功能全但重,部署周期长、需要专职运维,小团队玩不起。
实战:一个周末搭起来的系统：第一步,写导入器 importer.py。针对每台测试机的不同格式(CSV/Excel/设备专有格式),写适配器把数据映射成统一模型,写进SQLite。
为什么要这样写代码：这段代码是统一导入的核心。用INSERT OR REPLACE保证重复导入不报错(测试数据常因重测而重传),ON CONFLICT按lot_id+test_ty…
效果对比:从对一天到5分钟：搭TDMS前后,单次全链路分析从1天→5分钟,周度良率复盘从2小时→20分钟,且数据完整性从"可能漏"变成"必全"(导入时强制校验元数据,漏导直接告警)。
实施建议:先定标准再写代码：1. 先定元数据标准:wafer/lot/device/程序版本/测试类型这五个字段必须先统一,这是TDMS的地基,不定后面全乱。

【适用场景】

良率异常的 WAT 与 CP 数据联合分析。
Bin Map 形态异常的工艺归因。
测试程序覆盖率评估与更新。
参数分布形态异常（双峰/长尾）的原因分析。

【摘要】做良率分析最头疼的不是算法,是找数据:CP（晶圆针测，Chip Probing）测试在设备导出里、FT（成品终测，Final Test）测试在另一套系统、WIP（在制品，Work In Process）在MES（制造执行系统，Manufacturing Execution System）,分析一次要到处拷文件对半天。我用一个周末搭了个轻量测试数据管理系统(TDMS),统一元数据、秒级检索、趋势直出。这篇文章讲落地全过程。

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

🔧 配套工具：本节的核算／判读可用站内工具直接跑，推荐半导体MES工单管理v2 详解、半导体生产排程优化v2、半导体批次追溯增强版v2（zip 包，含可运行 Python 脚本与示例数据）。
这个方向的工具共 53 款，完整清单与选型建议见 MES与生产管理工具包。全部 351 款见工具资源包下载页。

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

我做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分钟,且再没漏过数据--导入时强制校验元数据,不齐就不收。

CP、FT、SLT 三段测试的职责不同：CP 在晶圆阶段筛掉功能与参数不合格的裸片，FT 在封装后确认成品规格，SLT 则在接近真实应用的板卡与负载条件下做系统级验证，三者组合才能覆盖从器件到系统的完整把关链条。

四、为什么要这样写代码

这段代码是统一导入的核心。用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小时乘常年。按工程师时薪折算,一年隐性收益就有大几万,更别说几次客户投诉的快速响应带来的口碑。

CP 与 FT 的失效判定口径必须一致：同一颗裸片在 CP 判定为边界合格的样本，可能因封装引入的应力与热过程在 FT 失效，两段数据的口径差异是良率争议最常见的来源。

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

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

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

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

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

CP/FT测试数据散落各处?我用Python+SQLit

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

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

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

WAT（晶圆允收测试，Wafer Acceptance Test）测试结构的代表性决定了它与实际产品表现的一致性。测试键的图形密度、位置与结构若不能代表产品的关键区域，就会出现 WAT 达标而产品失效的情形。

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

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

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

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

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

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

WAT 与 CP 良率常出现不一致：WAT 全部达标而 CP 良率偏低，说明问题在测试键未覆盖的区域（如密度相关效应）；反之则可能是测试键本身设计过于乐观。

效果对比

WAT 在划片前对测试键做电性测量，用于判断工艺是否处在规格内；CP 对每颗芯片做功能测试并生成 Bin Map；FT 在封装后做最终规格确认。三者的数据串联起来才能完整反映「工艺-器件-成品」链条。

完整代码

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

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

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

---

Bin（测试等级／分类格，Bin） Map 的形态分析是良率归因的快捷入口：径向分布反映均匀性问题，边缘集中反映传输或边缘工艺，扇区分布反映设备或腔体的空间差异，随机散点反映污染类缺陷。

【常见坑】

4. 从一个测试类型起步:先接CP或FT一种,跑顺再扩,别一上来想接全厂所有机台,容易卡在适配器细节里。
你在FAB里遇到过模型上线后悄悄变差的情况吗?或者有哪些数据质量的坑?欢迎在评论区聊聊你的真实经历,我会一一回复。
只看 CP 良率不看 WAT 参数分布。良率数字达标但参数分布尾部变长的批次，后续可靠性风险往往更高。
Bin Map 只看总体良率不看图形特征，丢掉了最直接的归因线索。
测试程序长期不更新，覆盖不到新出现的失效模式。

常见问题（FAQ）

Q：WAT 参数全部合格，为什么 CP 良率偏低？

A：常见原因有三类：一是测试键的结构与密度不能代表实际产品图形，密度相关效应未被覆盖；二是测试键位置固定，落在片内较优区域；三是缺陷问题属于随机分布，测试键未必命中。此时应结合 Bin Map 的空间分布重新判断。

Q：Bin Map 出现明显的扇区分布说明什么？

A：扇区分布通常与设备或腔体的空间位置相关，例如多腔体设备中某个腔体的工艺结果与其余不同，或者传输机械手在特定位置造成的影响。下一步应把 Bin Map 与设备腔体映射对齐做比对。

Q：参数分布出现双峰说明什么？

A：通常说明样本中混入了两个不同来源的群体，例如来自两台设备、两种工艺条件或两个材料批次的产品。此时应先做数据分层再统计，否则均值与标准差都失去意义，后续能力分析也会得出错误结论。

Q：测试数据能否直接用于工艺监控？

A：可以，但需注意测试条件的稳定性与测试程序的一致性。测试机台差异、探针接触状态、温度控制都会影响电性结果，因此把测试数据用于监控前应先评估测试系统自身的不确定度，并建立机台间的比对机制。

Q：CP 良率和 FT 良率的差距多大算正常？

A：一般以产品自身的历史基线为参照：建立基线后，若差值稳定在合理区间即属正常；某批次差值突然放大时，应优先排查封装工艺与测试条件，而不是直接判定晶圆工艺异常。

Q：SLT 测试与 ATE 测试是什么关系？

A：两者互补。ATE 关注电性参数与功能是否符合规格，覆盖率高但难以模拟真实系统环境；SLT 把芯片置于接近实际应用的板卡与负载条件下运行，覆盖高速接口与协议交互等 ATE 的盲区，二者组合才构成完整把关。

【总结】

电性测试与 Bin 分析的难点往往不在单点技术，而在于把原理、数据与现场验证串成闭环。再远一点,TDMS沉淀的数据是训练良率模型的金矿。我们后来直接用TDMS里的标准化数据训了良率预测模型,数据清洗时间从两周降到两天,TDMS的价值从这开始滚雪球。Bin Map 的形态分析是良率归因的快捷入口：径向分布反映均匀性问题，边缘集中反映传输或边缘工艺，扇区分布反映设备或腔体的空间差异，随机散点反映污染类缺陷。建议先用小范围试点验证有效性，再逐步扩大适用范围，并保留完整的数据与判断记录以便复盘。

术语速查

CP（Chip Probing，晶圆针测）：用探针卡对晶圆上每颗芯片进行功能与参数测试，并生成 Bin Map。　工程意义：CP 良率是判断是否继续封装的主要依据。
FT（Final Test，成品终测）：封装完成后的成品测试，覆盖功能、速度、功耗等最终规格。　工程意义：FT 与 CP 良率的差异常指向封装或测试环节问题。
MES（Manufacturing Execution System，制造执行系统）：位于计划层与控制层之间，负责工单执行、过程追溯、数据采集与质量管控的信息系统。　工程意义：是打通 ERP 计划与车间现场的中间层。
FDC（Fault Detection and Classification，故障检测与分类）：对设备传感器时序数据进行实时分析，识别异常并归类故障原因的系统。　工程意义：是从「事后维修」转向「预测维护」的数据基础。
WIP（Work In Process，在制品）：处于生产流程中尚未完工的产品或批次。　工程意义：WIP 金额与停留时间过高意味着流程存在瓶颈或积压。
NA（Numerical Aperture，数值孔径）：投影物镜收集衍射光的角度范围，直接决定分辨率极限。　工程意义：提高 NA 可提升分辨率，但会压缩焦深。
WAT（Wafer Acceptance Test，晶圆允收测试）：在晶圆完成制造后、划片前于测试键上进行的电性参数测试。　工程意义：是监控工艺是否处于规格内的关键闸门。
Bin（Bin，测试等级／分类格）：测试后按结果对芯片进行的分类编号，用于区分合格与各类失效。　工程意义：Bin 分布变化是良率异常的第一手信号。