En PCBA kan monteras korrekt och ändå vara svår att testa.
Det är där DFT-planering är viktig.
Design for Testability, eller DFT, handlar inte bara om att lägga till fler testpunkter till en PCB-layout. I ett riktigt PCBA-projekt avgör DFT-planering om det sammansatta kortet kan drivas, programmeras, sonderas, mätas, felsökas, omarbetas, testas om och släppas under praktiska tillverkningsförhållanden.
Ett godkänt/underkänt test talar om för laget om en bräda fungerar.
En bra DFT-plan hjälper teamet att förstå var de ska leta när det inte gör det.
Den skillnaden är viktig under prototypupptagning-, första konstruktionsgranskning, förberedelse av pilotkonstruktion och upprepad EMS-produktion. En konstruktionsingenjör kanske kan felsöka ett kort med labbinstrument, bygelkablar och djup produktkunskap. Ett EMS-testteam behöver en repeterbar sökväg som fungerar över flera kort, med dokumenterade steg och tydlig felhantering.
DFT-planering förbättrar PCBA-testning och felsökningseffektivitet genom att göra den troliga felvägen lättare att observera innan kortet når testbänken.

DFT är inte ett teststeg. Det är ett designbeslut.
Testning sker efter montering.
DFT-planering sker innan tavlan byggs.
Den skillnaden är lätt att missa. Många team behandlar testning som något som fabriken kan "lista ut" efter att PCB-filerna har släppts. Ibland fungerar det för enkla brädor. Men för firmware-baserade kort, industriella styrkort, täta SMT-layouter, BGA-paket, kommunikationsgränssnitt, reläer, sensorer eller inkapslade-integrerade produkter, kan sen testplanering förvandlas till sent felsökningsarbete.
Kortet kan slås på, men felvägen kan vara otydlig.
Testet kan säga "misslyckas", men det kanske inte säger om problemet är montering, firmware, komponentskada, fixturkontakt, kontaktledningar, belastningstillstånd eller designbeteende.
Testbarhetsplanering flyttar det tänket tidigare. Den frågar:
- Vilka funktioner måste verifieras?
- Vilka signaler måste vara tillgängliga?
- Vilka kraftskenor behöver mätas eller isoleras?
- Vilka gränssnitt behöver programmering eller kommunikationsåtkomst?
- Vilka fel måste isoleras snabbt?
- Vilka teststeg måste kunna upprepas av EMS-testteamet?
- Vilken felsökningsinformation ska registreras efter fel?
En bräda som endast är konstruerad för att fungera får fungera på ingenjörsbänken.
Ett kort designat för test kan verifieras, diagnostiseras, repareras och testas om med mindre gissningar.
Börja med vad testet måste bevisa
Många DFT-diskussioner börjar med testpunkter.
Det är vanligtvis inte den bästa utgångspunkten.
Den bättre första frågan är: vad måste denna PCBA bevisa innan den kan släppas?
För vissa projekt kan svaret vara enkelt: korrekt komponentplacering, inga uppenbara kortslutningar, stabil ström-på och grundläggande elektriska kontroller. För andra kan kortet behöva laddning av firmware, sensorsvar, kommunikationsverifiering, reläväxling, strömmätning, analog kalibrering eller interaktion på systemnivå med en annan modul.
De situationerna behöver inte samma testplan.
|
Testmål |
Vilken DFT-planering bör klargöra |
|
Grundläggande monteringsscreening |
Åtkomst för kortslutningar, öppningar, felaktiga värden, polaritet och uppenbara monteringsfel |
|
Programmering |
Gränssnittsåtkomst, startläge, firmwareversion, programmeringsverktyg och verifieringsmetod |
|
Funktionstestning |
Effektinmatning, belastningstillstånd, signalingång, förväntad uteffekt och kriterier för godkänt/underkänd |
|
Felsökningsstöd |
Sondpunkter, referensnoder, felisoleringsväg och diagnostisk synlighet |
|
Upprepa produktionen |
Fixturåtkomst, operatörssteg, testpostformat, omarbetningsregler och omtestmetod |
Detta förhindrar ett av de vanligaste testbarhetsproblemen: kortet har testpunkter, men inte rätt teståtkomst.
En pad som är bekväm för layout kanske inte hjälper testteamet att isolera ett misslyckande. En kontakt som fungerar under teknisk upptagning-kan vara blockerad efter montering, beläggning eller integrering av hölje. Ett firmware-gränssnitt som fungerar för en ingenjör kanske inte är praktiskt för upprepad produktionstestning.
Bra DFT-planering börjar med utgivningsvillkoret och arbetar sedan bakåt för åtkomst, fixturmetod, inmatning av firmware, mätpunkter och omtestningsregler.
Gå bortom godkänd/underkänd testning
Ett godkänt/underkänt resultat är användbart, men det är inte detsamma som diagnos.
Detektionssvar: gick styrelsen igenom?
Diagnos svar: var ska teamet leta härnäst?
Den skillnaden blir viktig när en PCBA misslyckas med FCT, ICT, flygande sond, programmering eller ström-på verifiering. Om testet bara rapporterar ett allmänt styrelsefel kan teamet fortfarande behöva en lång manuell felsökningsslinga för att hitta det verkliga problemet.
En starkare DFT-metod ger testprocessen mer synlighet.
Till exempel, om en kommunikationsport misslyckas kan felsökningsvägen behöva tillgång till:
- effekt- och jordreferenser för gränssnittskretsen;
- återställ, aktivera eller startsignaler;
- klocka eller oscillatorutgång;
- bekräftelse av anslutningsstift;
- firmwareversion eller programmeringsstatus;
- bekräftelse av fixturkontakt;
- känt-bra kabel-, belastnings- eller extern modulskick;
- mellanliggande signalpunkter mellan funktionsblock.
Detta betyder inte att varje kort behöver en tung diagnostisk arkitektur.
En enkel tavla bör inte vara över-konstruerad för testning. Men om produkten innehåller firmware, komponenter med hög-densitet, fältledningar, industriella I/O, strömbrytare, sensorer eller kundspecifika-gränssnitt, bör DFT-planering tänka bortom ett enda godkänt/misslyckande resultat.
Ett testresultat som säger "misslyckas" utan en felsökningsväg kan förvandla en dålig styrelse till en lång utredning.

Teståtkomst börjar i layout, inte vid teststationen
Testavdelningen kan inte komma åt en signal som layouten aldrig gjort tillgänglig.
Det låter självklart, men det är en av de enklaste sakerna att missa när designteamet är under schemapress.
Teståtkomst beror på layoutbeslut:
- om kritiska nät har praktisk sondåtkomst;
- huruvida testpunkter kan nås med fixtursonder;
- om höga komponenter blockerar sondens rörelse;
- om testpunkterna är för nära komponentkroppar eller brädans kanter;
- huruvida referenser och verktygshål stödjer repeterbar fixturinriktning;
- om programmeringshuvuden förblir tillgängliga efter montering;
- om en skiva kan testas före eller efter beläggning eller kapslingsintegrering.
En testpunkt placerad på fel plats kan vara nästan lika ohjälpsam som ingen testpunkt alls.
För brädor med hög-densitet är svaret inte alltid "lägg till en testpunkt i varje nät." Styrelseutrymme, signalintegritet, kostnad, produktionsvolym och testmetod har betydelse. I vissa fall förtjänar kritiska nät, kraftskenor, återställningslinjer, klockor, programmeringssignaler och högriskgränssnitt prioritet. I andra fall kan gränsavsökning, flygande sond eller funktionstest täcka delar av testbehovet mer effektivt.
DFT-planering handlar inte om att lägga till funktioner blint.
Det handlar om att ge testteamet tillgång till de signaler som betyder något.
Gränsskanning kan minska Black Box-problemet
Gränsskanning, ofta förknippad med IEEE 1149.1 och JTAG, kan vara värdefull när fysisk sondåtkomst är begränsad.
Detta är särskilt relevant för kort med BGA:er, -bättrad IC, processorer, FPGA:er, minnesenheter eller täta digitala sammankopplingar. I dessa konstruktioner är många viktiga stift inte fysiskt tillgängliga efter montering. Utan en skanningsväg eller annan diagnostisk metod kan kortet bete sig som en svart låda när det misslyckas.
Gränsskanning kan hjälpa till att verifiera sammankopplingar mellan kompatibla enheter, stödja programmering eller konfigurationsarbetsflöden och ge diagnostisk synlighet där fysisk sondering är svår.
Men det hjälper bara om det är planerat.
Användbar gränsskanningsplanering kan inkludera:
- dirigera skanningssignaler till en tillgänglig kontakt eller testgränssnitt;
- bekräfta vilka enheter som stöder gränsavsökning;
- definiera skanningskedjan korrekt;
- tillhandahålla BSDL-filer vid behov;
- bekräfta om gränsavsökning används för produktionstest, teknisk felsökning eller båda;
- se till att testgränssnittet inte blockeras av mekanisk design eller höljesbegränsningar.
Gränsskanning ersätter inte all fysisk teståtkomst, och den verifierar inte alla analoga, ström- eller kontakttillstånd. Det är mest användbart när skanningskedjan planeras, dokumenteras och stöds av de valda enheterna.
För ett enkelt kort med begränsad digital komplexitet kan gränsavsökning tillföra lite värde. För en tät styrkort eller processor-baserad sammansättning kan det vara skillnaden mellan användbar felisolering och ett allmänt funktionsfel.
Ström- och signalpartitionering kan förkorta felsökningsslingor
Vissa fel är svåra att felsöka eftersom kretsen inte var designad för att vara isolerad.
En kortslutning på en delad elskena kan påverka många delar av kortet. Ett misslyckat kommunikationsgränssnitt kan vara svårt att separera från firmware, anslutningskablar, skada på transceivern eller fixturkontakt. En analog signalkedja kan misslyckas vid utgången medan det verkliga problemet ligger flera steg tidigare.
DFT-planering kan minska denna osäkerhet.
Användbara designval kan inkludera:
- tillgängliga mätpunkter på viktiga kraftskenor;
- praktiska jordreferenser nära uppmätta signaler;
- isoleringsalternativ som 0-ohms länkar, byglar eller borttagbara anslutningar där så är lämpligt;
- mellanliggande testpunkter i signalkedjor;
- aktivera eller återställa kontroll för funktionsblock;
- kända-bra laddnings- eller loopback-alternativ för utvalda gränssnitt;
- tydlig åtskillnad mellan programmeringsfel, fixturfel och kortfel.
Det är inte alltid dyra designförändringar. Ofta är det små beslut som tas tillräckligt tidigt.
Nyckeln är att tänka på vad teknikern kommer att se när tavlan misslyckas.
Om allt testsystemet kan rapportera är "kort misslyckades", börjar felsökningsvägen med osäkerhet. Om DFT-planering ger tillgång till funktionella block, kraftdomäner och kritiska gränssnitt, har teamet en bättre chans att vända felet till en specifik åtgärd.

Firmware och programmering hör till DFT-planering
För många moderna PCBA är testning inte bara elektrisk.
Det är också mjukvaruberoende-.
Ett kort kan behöva firmware innan det kan funktionstestas. Det kan kräva en bootloader, testbild, produktionsavbildning, konfigurationsfil, serienummer, MAC-adress, kalibreringsdata eller kommunikationsskript. Om dessa ingångar inte kontrolleras kan ett korrekt monterat kort fortfarande misslyckas med testet av fel anledning.
DFT-planering bör klargöra:
- vem tillhandahåller den fasta programvaran;
- vilken firmwareversion som används för produktionstest;
- om kortet är programmerat före eller efter inspektion;
- vilket gränssnitt som används för programmering;
- om programmeringskontakten förblir tillgänglig;
- om en kontrollsumma, loggfil eller versionspost krävs;
- vad händer om programmeringen misslyckas;
- om tavlan måste programmeras om efter omarbetning.
Detta är en av de vanligaste klyftorna mellan ingenjörstest och produktionstest.
Designteamet kanske vet hur man laddar fast programvara från en labbdator. EMS-testteamet behöver en metod som kan dokumenteras, följas, kontrolleras och upprepas.
Om firmware inte är en del av DFT-planeringen kan funktionstestning förvandlas till en programmeringsfelsökningssession innan det riktiga testet ens börjar.

Fixturberedskap beror på DFT-beslut
En testfixtur är inte bara en mekanisk hållare.
Det är det fysiska resultatet av tidigare beslut om testbarhet.
Armaturens beredskap beror på:
- där sonder kan kontakta styrelsen;
- om dynorna är tillräckligt stora och placerade på lämpligt avstånd för den avsedda metoden;
- om komponenthöjd blockerar åtkomst;
- huruvida brädstöd förhindrar böjning under kontakt;
- om kontakter behöver matchande kablar;
- om skivan är testad från ena sidan eller båda sidor;
- om testet sker före eller efter beläggning eller inneslutningsintegrering;
- om operatören behöver interaktion med streckkod, etikett eller serienummer;
- om misslyckade enheter kräver separation och omtest.
Om dessa beslut lämnas till sent, kan församlingen gå framåt medan testning blir flaskhalsen.
EMS-teamet behöver inte en komplett produktionsfixtur för varje tidig teknisk konstruktion. Men den behöver känna till den förväntade vägen: manuellt test, flygande sond, IKT, gränsskanning, FCT, temporär fixtur, kund-tillhandahållen installation eller produktions-avsiktsfixtur.
Det är olika konstruktionsantaganden.
Ett fixturproblem ser ofta ut som ett kortfel tills teamet bevisar att kontakten, kabeln eller installationen är stabil.
Ett projekt kan vara redo förPCB monteringoch fortfarande inte vara redo för repeterbara tester.
DFT-planering bör definiera omarbetnings- och omtestslingan
Testningen slutar inte när en bräda misslyckas.
Nästa fråga är vad som händer efter misslyckande.
Utan en definierad omtestningsväg kan omarbetningsbeslut bli inkonsekventa. En tekniker kan byta ut en misstänkt komponent och upprepa endast det misslyckade steget. En annan kan köra hela funktionstestet igen. En tredje kan passera brädet efter en snabb-startkontroll eftersom det ursprungliga symptomet försvann.
Det skapar risk.
En praktisk DFT-plan bör definiera:
- vilka fel som kräver teknisk granskning;
- vilken omarbetning är tillåten;
- vad som måste inspekteras efter omarbetning;
- om hela testsekvensen måste upprepas;
- om ett fokuserat omtest är acceptabelt;
- vilka feldata som ska registreras;
- hur upprepade misslyckanden eskaleras.
Detta är inte pappersarbete för sin egen skull.
En omarbetad PCBA bör inte släppas eftersom det "verkar bra nu." Den bör släppas eftersom den överenskomna omtestningsvägen bekräftar att problemet är stängt.
Det är här som DFT-planering stödjer både produktionseffektivitet och kvalitetskontroll.
Vad ett DFT-färdigt PCBA-paket bör innehålla
DFT-planering blir användbar när den är synlig i teknikpaketet.
Detta är inte en obligatorisk dokumentuppsättning för varje byggnad. Det är ett sätt att visa vilken information som kan behövas när testomfattningen går utöver en enkel visuell inspektion eller strömkontroll-.
För OEM-köpare kan ett praktiskt DFT-paket innehålla:
|
DFT-området |
Användbara ingångar för EMS-testning och felsökning |
|
Testmål |
Vad måste verifieras innan release |
|
Schematisk |
Elektrisk referens för testplanering och felsökning |
|
BOM |
Komponentidentitet, paket, alternativa och programmerade delar |
|
Gerber eller ODB++ |
PCB layout och tillverkningsdata |
|
CPL / välj-och-placera fil |
Placeringsreferens för montering och besiktning |
|
Monteringsritning |
Polaritet, referensbeteckningar, komponentsida och speciella anmärkningar |
|
Testpunktskarta |
Kritiska nät, kraftskenor, markreferenser och sondåtkomst |
|
Programmeringsinformation |
Firmwareversion, gränssnitt, verktyg, startläge och verifieringssteg |
|
Gränsavsökningsdata |
Skanna kedjans beskrivning, anslutningsåtkomst, BSDL-filer när tillämpligt |
|
Funktionstestprocedur |
Ingångar, belastningar, förväntade utdata, gränser och regler för godkänt/underkänd |
|
Fixture notes |
Sondåtkomst, anslutningskoppling, kortstöd och hanteringsbegränsningar |
|
Omarbeta och testa om regler |
Vad händer efter fel, reparation och upprepat fel |
|
Testrekord |
Vilken data ska samlas in och levereras efter testning |
En enkel bräda behöver kanske bara en lättare testbana. Ett firmware-baserat industristyrkort kan behöva ett mer komplett DFT-paket. En pilotversion kan behöva fler repeterbara poster än ett första tekniskt prov.
Det viktiga är inte dokumentvolymen.
Den viktiga punkten är om EMS-teamet har tillräckligt med information för att testa brädan utan att bygga testmetoden från gissningar.
Använd testresultat för att förbättra nästa revision
DFT är inte en-engångschecklista.
Den första konstruktionen lär ofta teamet något som inte var uppenbart under layoutgranskning.
Efter PCBA-testning och felsökning bör OEM- och EMS-teamet fråga:
- Vilka misslyckanden var svåra att isolera?
- Vilka teststeg tog längre tid än förväntat?
- Vilka funktioner kunde inte testas tillförlitligt?
- Vilka sondpunkter var svåra att komma åt?
- Vilka fixturkontakter orsakade falska fel?
- Vilken firmware eller programmeringssteg skapade förvirring?
- Vilka omarbetade brädor krävde mer omtestning än förväntat?
- Vilka testresultat ska registreras annorlunda nästa gång?
Denna feedback bör inte stanna bara i testområdet.
Det bör mata nästa PCB-revision, nästa testprocedur, nästa fixturdesign och nästa NPI-paket.
En bra DFT-process förvandlar den första byggnaden till en inlärningsslinga.
Hur detta ansluter till PCB-montering och teststöd
För OEM-köpare är DFT-planering mest användbar när den kopplar samman kortdesign, monteringsomfattning, programmeringsbehov, teståtkomst och släppförväntningar innan produktionen börjar.
STHL stödjer OEM-projekt genom monteringsförberedelser, testplanering ochProvning och inspektion, inklusive diskussioner kring AOI, ICT, FCT, -röntgeninspektion, programmering av firmware, fixturberedskap, förväntningar på omarbetning och omtestning samt spårbarhetsbehov.
Målet är inte att lägga till onödiga tester.
Målet är att göra testomfattningen tillräckligt praktisk för styrelsens funktion, produktionsstadium och risknivå.
Förbereder du ett PCBA-bygge som behöver tydligare teståtkomst eller funktionell testplanering? Skicka in ditt projekt genomBegär en offerteller mejlainfo@pcba-china.com.
Slutsats
DFT-planering förbättrar PCBA-testning och felsökningseffektivitet eftersom det flyttar testtänkandet uppströms, innan kortet når linjen.
Det hjälper OEM- och EMS-teamet att definiera vad som måste testas, var åtkomst behövs, hur firmware ska laddas, vilken fixtur eller kabelinstallation som krävs, vilket resultat som räknas som godkänt eller misslyckat, och hur felaktiga kort ska felsökas, omarbetas och testas om.
En skiva som är lätt att montera är inte alltid lätt att testa.
Ett kort som är lätt att testa är vanligtvis ett där teståtkomst, programmering, fixturberedskap och felsökningssynlighet övervägdes före montering.
För OEM-köpare är den praktiska lektionen enkel: den bästa tiden att fråga hur en bräda kommer att testas är innan layouten och byggpaketet låses.

