系统控制器制造测试全流程：从ICT到FCT的方案设计与实践

系统控制器的制造测试说白了就是产品出厂前最后一道把关。这活儿我干了快十年见过太多因为测试方案设计不合理导致的不良品流出也见过因为误测率太高导致产线停线、工程和品质拍桌子的场面。做测试方案这件事从来不是把板子通上电、跑两个功能就算完而是要通盘考虑工艺、成本、节拍、可靠性和数据追溯。这一篇我从系统控制器的制造测试整体方案讲起包括方案选型、夹具搭建、核心测试项的实现路径适合刚接手产线测试的硬件工程师、测试工程师以及想了解制造测试底层逻辑的研发同事。既然是第一部分我先把最基础的东西写透后面再单独展开数据分析和自动化方案。1. 谈整体方案之前先搞清楚被测对象1.1 系统控制器到底是什么在电子整机里系统控制器是负责逻辑控制和通信调度的核心板卡典型形态是MCU或SoC加上电源、时钟、存储、通信接口等外围电路。它可能是一块独立的控制板也可能是嵌入在设备内部的模组。无论哪种形态它的职责都是接收输入信号、执行控制逻辑、驱动执行机构、与外部进行数据交互。正因为处在整机“大脑”的位置它一旦出问题整机就是死机、误动作、通信失败这类大故障几乎不可能带病出货。我建议刚入行的工程师拿到测试任务时先别急着写测试用例花半天时间把被测板的原理图和PCB走线捋一遍搞清楚板上电源拓扑、主控型号、外设接口、关键信号走线甚至可以拿示波器抓一下典型波形。这个准备工作决定了后面做测试项的效率和准确度。很多测试方案出问题不是测试方法不够先进而是根本没弄明白被测对象的工作方式。1.2 制造测试要解决什么问题制造测试要解决的问题我总结成四个。第一把来料和焊接过程中的不良筛出来比如连锡、漏焊、虚焊、器件贴错。这类缺陷在ICT阶段能抓掉大部分但ICT不是万能的有些复杂的BGA封装、多层板内部走线ICT覆盖不到要靠功能测试来兜底。第二验证固件和硬件是否匹配确保烧进去的程序在目标硬件上能正常跑起来。纯硬件没问题的板子如果固件版本烧错、配置字不对、校准数据没写进去一样是废品。第三通过上电功能验证暴露时序类、信号完整性类问题。这类问题往往只有在真实工作状态下才出现比如上电瞬间某个复位信号时序不对、某路通信在临界速率下偶发丢包。第四为每个产品留下测试数据形成可追溯的记录。一旦市场端出现批量问题能靠SN和时间戳快速锁定生产批次和测试数据缩小排查范围。注意第三点不是研发测试那种全面功能验证制造测试追求的是“在最短时间内把最可能发生的缺陷暴露出来”。用研发测试的完整用例集去跑产线节拍根本扛不住成本也完全失控。1.3 测试层次怎么切分ICT、FCT还是全做制造测试通常分两个大层次ICT在线测试和FCT功能测试。ICT通过探针或针床测试开短路、电阻、电容、二极管、IC焊接情况不依赖给板卡上电FCT则是给板卡上电模拟真实工作状态做功能验证。对系统控制器这种核心控制板我的经验是ICT和FCT都做。ICT抓焊接工艺问题FCT抓功能和固件问题两条线各管一段。但如果产品定位在成本极度敏感的消费类也有人砍掉ICT只保留FCT靠FCT里的上电电流、通信接口检测这些间接手段来抓焊接问题。这个取舍没有绝对对错核心看产品定位和不良成本。我负责过的产品线里工业级控制器基本都保留ICT因为工业现场的可靠性要求高一旦控制器故障可能损坏整个设备返修成本远大于测试成本。消费级小家电控制器则经常只做FCT因为单板成本可能只有几十块钱加一道ICT工序摊到每块板子上的成本提升在百分之几到十几老板一看报表就摇头。2. 测试夹具与硬件环境搭建2.1 治具类型怎么选制造测试的效率和质量有一大半都押在治具上。治具这东西往大了说决定测试节拍和稳定性往小了说决定作业员的操作疲劳度。常见的治具类型有针床治具、压床治具和真空治具。针床治具适合测试点规则、板面较大、测试点分布均匀的板卡用弹簧探针阵列同时接触所有测试点一次按压完成全部电气连接效率最高但治具成本也最高。压床治具适合测试点数量少、板材厚、不易变形的板卡通过气缸或手动压合让探针接触指定测试点。真空治具则是利用真空负压把板卡压紧贴合在针床上适合薄板、挠性板受力均匀不容易板弯。我建议选择治具类型时别只看一个点要看板卡尺寸、测试点数量、板材厚度、产量预期、预算。产量大、生命周期长的产品值得上针床因为均摊成本低小批量多品种的试产阶段用压床或手压治具更灵活。我做过的项目里有个产品年产量几十万台刚开始舍不得针床治具的钱用了两套压床结果作业员压合动作强度大、效率低后来还是换了针床一天产能翻了将近一倍。2.2 探针选型与维护探针是治具里最容易出问题的部件没有之一。针尖类型直接决定接触可靠性和寿命常见的尖头针适合平面焊盘锯齿针适合焊点梅花针适合焊盘表面氧化层较厚的被测板但针尖越尖锐刮伤焊盘的风险也越高。探针的弹簧力通常在几十克到两百克之间力太小接触电阻不稳定力太大可能把焊盘压出痕迹甚至压坏板卡。选型时要参考被测板的最小测试点间距和焊盘材质。探针日常维护是被很多人忽略的环节。产线连续跑几个小时探针针尖上会积累助焊剂残留、灰尘和氧化物接触电阻慢慢变大最直观的表现就是某个测试项偶发Fail。我见过一条产线因为探针脏导致FCT误测率高达百分之十几产线主管一口咬定是产品批量不良结果把一批合格板子全部返工白白损失了几万块。后来排查才发现就是治具上的探针该擦了。现在我的产线规定每班次结束用无尘布沾酒精清洁针尖每周做一次接触电阻抽测问题基本绝迹。2.3 电源与信号接口设计测试系统的电源和信号接口直接关系到测试结果的真实性。给被测板供电的电源纹波和瞬态响应很关键。如果测试电源本身的纹波就很大测出的电压值波动会掩盖板卡的真实状态甚至导致板卡复位。我一般用可编程直流电源纹波控制在mV级别输出线上加足够的去耦电容尽可能模拟板卡实际工作环境的电源质量。信号接口方面测试系统与板卡之间的通信线要尽量短阻抗要可控。尤其是有高速通信接口比如SPI时钟跑到几十MHz、以太网、CAN FD的板卡测试线的长度和屏蔽直接影响眼图和误码率。我踩过一个坑当时测一块带以太网的控制器用了一根1米多长的普通杜邦线飞线连接测试夹具结果通信时好时坏一度怀疑是板卡PHY芯片问题。后来换了屏蔽双绞线并就近加磁环问题立刻消失。从那以后我定了一条规矩高速信号测试线缆必须用屏蔽线且电源线和信号线分开走线治具内部避免平行长距离走线。3. 核心测试项拆解与实现3.1 上电与电源测试上电测试是整个FCT流程的第一道关卡。板卡上电后首先要确认各路电源电压是否在规格范围内。系统控制器板上通常有多路电源比如5V输入转3.3V给MCU3.3V转1.8V给DDR3.3V转1.2V给内核。每路电压都要用ADC或万用表实际测量不能只看供电芯片的指示灯。我常用的做法是在测试夹具上预留电压测试点由工控机通过数据采集卡或数字万用表自动读取电压值判定范围根据板卡的手册设定。比如3.3V电源规格可能是3.3V正负5%实际测试时我会把判定范围放得更紧一点比如3.2V到3.4V太接近边界值的板卡虽然现在能用但器件老化后可能先出问题。上电电流也要测电流过大说明板上有短路或异常漏电电流过小说明某些器件没正常工作比如某个LDO后续负载没起来。3.2 固件烧录与校验固件烧录是系统控制器制造测试里绕不开的环节。烧录方式通常有离线和在线两种。离线烧录是先把程序写进烧录器再把烧录器的探针对准板卡的烧录接口适合批量生产在线烧录则是通过JTAG、SWD、UART等接口由工控机控制烧录适合测试流程需要自动化的场景。我比较推荐把烧录环节整合进FCT流程由上位机控制烧录器完成烧录后紧接着做固件校验。校验不能只比对烧录器返回的“烧录成功”标志要回读程序区的CRC或哈希值和原始固件的CRC比较。烧录器的“烧录成功”通常只表示它把数据写完了但写入的数据是否正确必须回读验证。我遇到过烧录器老化导致某几片Flash写入异常烧录器居然返回成功后来加了回读校验才拦住。固件烧录还有个常见坑是烧录接口信号电平不匹配。有些MCU的SWD接口是1.8V电平有些是3.3V烧录器不支持1.8V就会烧不进去或者烧进去之后MCU运行异常。3.3 通信接口测试系统控制器少不了各种通信接口常用的有UART、I2C、SPI、CAN、以太网、USB等。制造测试阶段不需要做全协议栈的复杂通信测试重点是验证物理层和基本通信能力。UART测试最简单可以直接把UART的TX和RX短接做自发自收发送一串已知数据接收端比对是否正确。SPI测试可以让主控发一个已知序列从设备回环数据比对接收结果。I2C测试可以扫描总线上的设备地址看是否和设计一致或者读取某个外设的寄存器确认通信链路正常。CAN测试需要两个CAN节点互发报文或者通过CAN分析仪做收发。以太网测试则要确认PHY Link状态和基本数据传输。我自己做通信接口测试时倾向用“回环已知数据比对”的方式。回环测试的好处是硬件上简单不需要复杂的仿真设备而且能直观反映链路是否通。但要注意别测试时间过长。每个通信接口如果都用大量数据跑完整吞吐测试节拍根本扛不住。我的经验是每个接口用少量数据验证功能正常即可详细的性能测试留到研发和可靠性抽检阶段做。3.4 GPIO与控制逻辑测试GPIO是系统控制器最基础的输入输出。制造测试里GPIO测试的重点是验证每个引脚没有被焊接短路、断路且能正确输出和读取电平。方法比较简单测试治具上给每个GPIO引脚接一个负载或信号发生器上位机控制MCU的GPIO输出高低电平由治具端检测或者治具端给GPIO输入高低电平由MCU读取并上报。控制逻辑测试则要覆盖一些关键的控制行为比如继电器通断、电机驱动信号的PWM频率和占空比、LED指示灯状态。这些测试往往要结合具体产品功能来设计。比如空调控制器的系统控制器要验证压缩机继电器在上电后能够正常吸合制冷模式下的PWM输出频率和占空比是否符合设定值。这类测试能间接暴露很多焊接问题继电器引脚虚焊吸合电流就不正常PWM输出引脚连锡波形就明显异常。4. 测试软件框架与流程控制4.1 上位机程序怎么搭制造测试的上位机程序相当于整个测试产线的“指挥官”。成熟的方案通常由几大模块组成硬件控制模块、测试序列管理模块、结果判定模块、数据记录模块、用户交互界面模块。硬件控制模块负责和电源、万用表、烧录器、IO采集卡等设备通信通常走SCPI指令或厂家提供的SDK。测试序列管理模块定义每个测试项的执行顺序、超时时间、依赖关系。比如必须先上电、再烧录、再测电压、再测通信接口顺序乱了测试结果就没有意义。我用过Python和C#两种方案。Python开发效率高适合测试项频繁迭代的试产阶段C#和LabVIEW在工业产线里用得更多稳定性和界面友好度更好。不管你选哪种语言有一点要特别注意测试程序必须有完善的异常处理机制。设备通信超时、操作员误操作、板卡短路导致电源保护这些异常如果没处理好程序就可能卡死或者误判直接影响产线节拍和数据可信度。4.2 Pass/Fail判定与防呆设计测试结果的判定逻辑是整个程序的核心。每个测试项不能只看是否执行成功还要保留实测值。比如测3.3V电源程序要记录实际读数然后和上下限比较判定Pass/Fail。这样后续做数据分析时才能看出同一批产品的电压分布趋势提前预警器件漂移。判定逻辑要特别注意边界值处理。我见过一个测试程序判断条件是电压小于3.5V且大于3.1V结果有一天产线大批量报警最后发现是一颗电源芯片的反馈电阻批量偏了电压全部接近3.5V边界虽然还在规格内但程序按3.5V以下判Pass实际测试值却很接近边界其实是器件一致性差的预警信号。防呆设计也很重要。治具里要加一些机械和电气防呆措施比如被测板方向反了要能检测到治具没压到位测试程序要能识别不放行。电气防呆可以在治具上放几个位置检测传感器只有板卡放正了才允许启动测试。没有防呆的产线作业员放反板卡是早晚的事轻则误测一堆良品重则损坏被测板和治具。4.3 测试数据记录测试数据记录不是为了签字存档而是为了后续分析。基本的数据字段至少包括产品型号、固件版本、PCBA序列号SN、测试工位号、测试时间、测试程序版本、每个测试项的实测值和判定结果、总体Pass/Fail状态。我建议数据记录尽量用结构化文件比如CSV或SQLite数据库不要只用日志文本。日志文本看起来方便但做统计分析时解析起来非常痛苦。我自己踩过这个坑早期用纯文本记录测试结果后面要做良率统计和趋势分析不得不写脚本去解析解析规则又经常被各种格式变体搞崩浪费了大量时间。结构化数据存下来之后不仅能做批量统计还能在售后质量分析时快速反查。一块板子在客户那里出问题通过SN反查制造测试数据能立刻看到它的测试时间、测试工位、所有实测值对定位问题非常有帮助。5. 常见问题与排查技巧实录5.1 误测率怎么就高了产线最怕误测。所谓误测就是一块本来合格的板子被判Fail拉去返修结果返修时发现一切正常。误测率的直接后果是返修工位压力大、物料搬运浪费、合格品被折腾一次甚至两次。更严重的是如果误测现象持续产线会失去对测试系统的信任开始“跳测”或者凭经验直接放行那测试体系就形同虚设了。误测率高发的原因我总结了几个。探针接触不良是头号原因测试参数阈值设置过紧是第二原因测试程序本身的时序竞争和状态残留是第三原因环境因素比如静电、湿度、电源波动是第四原因。排查的时候我会先看误测的故障现象是不是集中在某一个或某几个测试项是的话重点排查对应通道的探针和治具接线而不是急着改产品。有一个经典排查案例一块控制器测试时经常偶发UART通信失败复测又通过。刚开始怀疑是固件问题反复查无果。后来我用示波器挂在UART通信线上观察了上百次测试过程发现在治具气缸下压的瞬间通信波形会出现一个毛刺导致短暂误码。原因就是气缸的电磁阀开关产生电磁干扰耦合到了信号线上。后来把信号线换成屏蔽线并在治具端加了磁环误测率直接降到千分之几。5.2 探针接触不良的阴间问题探针接触不良是我在产线上处理最多的一类问题而且有时候表现得很“阴间”。比如只有某根探针接触不良导致某个信号偶尔不通板卡功能时好时坏排查起来非常头疼。处理探针接触不良我的经验是三步走。第一步用万用表或接触电阻测试仪量探针和对应治具端子的导通电阻正常应该在毫欧级如果到了欧姆级或者几十欧姆说明接触已经不可靠。第二步检查探针弹簧的压合行程探针行程压到底说明已经疲劳针尖磨损严重该换了。第三步看被测板测试点的状况如果测试点有氧化或者被针尖刮出凹坑即使换了新探针接触可靠性也会受影响。我还见过一种阴间情况探针本身没问题但针套和探针配合的镀金套筒里积了灰尘导致探针在针套里滑动不畅时而下压不到位。这种问题目视检查很难发现要用探针测试仪测量探针在不同压合深度下的接触电阻。所以保养治具时不但要擦针尖还要定期清洁针套。5.3 测试节拍怎么压下来产线节拍是量产测试的命门。每条产线的产能目标摆在那里测试节拍如果慢要么增加产线和设备要么加班。我的目标通常是把单板测试时间控制在2分钟以内超出这个范围就会实实在在影响产能。压缩测试时间有几个思路。第一并行测试如果测试资源和板卡接口允许同时测试多块板卡。治具设计时做双工位甚至四工位一个流程同时跑两块板。第二减少不必要的延时。测试程序里的sleep要有依据不能顺手写完就不管有些延时其实可以缩短或者去掉。第三测试项分级关键测试项全检非关键测试项抽样或者放在ICT里做。我优化过一个产品的测试流程把原来的固件烧录和功能测试分成两个工位优化成一个工位自动流转同时把每项通信测试的延时从几百毫秒优化到几十毫秒单板测试时间从三分半钟压到90秒。整个优化过程中没有牺牲任何一项测试覆盖率只是把流程串行改并行把等待时间压到最低。6. 测试数据管理和良率分析6.1 数据怎么统计才有效测试数据攒下来如果不做分析就是一堆死数据。我做产线管理时每天必看几个指标直通率First Pass Yield, FPY、单项测试不良率、返修后复测合格率、误测率。直通率是产线健康度最直观的指标指的是第一次测试就通过的比例。如果直通率连续几天下降就要警惕是工艺波动的早期信号。单项测试不良率则用来定位具体问题比如某个夹具工位的电容测试不良率突然升高那就大概率是该工位测试治具问题要去擦探针或者换探针了。数据统计分析可以做得不复杂一张Excel表格就能干活。但关键是数据格式要统一SN、测试时间、测试项名称不能乱写。后期如果产线多了我建议直接用MES系统管理测试数据自动汇总自动日报实时监控。没有MES的小厂也可以用Python脚本每天自动汇总CSV数据生成日报表投入产出比很高。6.2 从数据里看出产线问题数据分析还有一个用处就是提前发现器件和工艺的漂移趋势。比如前面说的3.3V电源电压如果测试程序记录了每个产品实测电压值就可以画出这批产品的电压分布直方图。如果分布中心发生偏移即使所有产品都在Pass范围内也说明电源芯片或反馈电阻的参数存在批次波动需要和供应商确认来料批次质量。我用这种方法发现过好几次潜在批量问题。有一次数据里看到某段时间的产品上电电流整体比之前高了10%虽然单项判定仍然Pass但趋势很异常。顺着这个趋势排查发现是某个电容厂换了原材料导致漏电流变大。如果没有测量值和历史数据对比这种早期隐患很难暴露等彻底出问题时可能已经出货几千片了。数据分析是制造测试的深水区这篇文章先提个总纲具体怎么搭建分析体系、怎么用统计工具处理测试数据我在后面单独写一篇再展开。7. 一些个人经验总结做制造测试这些年我最大的体会是测试方案没有最好只有合适的方案。同样一块系统控制器放在工业仪表里和放在消费玩具里测试项目的取舍、测试成本的底线完全不同。方案设计之前先问清楚产品定位、出货量、目标单价、客户对失效率的预期再动手画治具写代码。另外一个体会是测试系统本身也需要定期“体检”。探针磨损、治具变形、线缆老化、程序版本混乱这些都是慢慢出问题的东西。我养成的习惯是每周抽几块在库良品跨到产线上复测看看测试系统本身的状态稳不稳定。这点投入很小但能避免很多半夜被产线电话叫醒的麻烦。还有一个建议测试程序一定要做版本管理。产线测试程序改了几十版之后如果没有版本记录出了问题根本不知道哪一版在生产排查起来极其痛苦。用Git或者SVN管起来每次修改都记录原因这是我给所有新入行的测试工程师的第一条建议。制造测试是一个越挖越深的领域文章写到这里其实只把地基铺开了。后续我会接着写数据分析和自动化方向的内容。