Introducere
Multe echipe OEM presupun că odată ce sosesc plăcile prototip, verificarea se va deplasa rapid.
Sună rezonabil. În proiectele reale, adesea nu este.
Un ansamblu prototip de PCB poate reveni la program și poate pierde în continuare zile, sau chiar o săptămână, în verificare dacă echipa încă se ceartă cu privire la ceea ce trebuia să demonstreze construcția, ce s-a schimbat în BOM sau dacă calea de testare este gata să producă un răspuns utilizabil. În acel moment, încetinirea nu se mai referă doar la termenul de asamblare. Devine o problemă de eliberare, testare și transfer.
Aceasta este adevărata întrebare din spatele acestui articol. Problema nu este doar cât de repede poate fi construit un prototip. Problema este de ce verificarea încă blochează după ce plăcile sunt deja pe bancă.
Dacă echipa dvs. a depășit deja timpul liber-bordului și acum încearcă să înțeleagă de ce progresul prototipului este încă lent, acesta este scopul să priviți dincolo de asamblare și să revizuiți calea completă în jurul valorii deAnsamblu PCB.
Livrarea prototipului și verificarea prototipului nu sunt aceeași etapă
Aici o mulțime de programe sunt citite greșit.
Livrarea prototipului înseamnă că plăcile au fost fabricate, asamblate și primite. Verificarea prototipului înseamnă că echipa a folosit efectiv acele plăci pentru a răspunde la întrebarea tehnică intenționată și pentru a decide ce urmează.
Acestea nu sunt aceeași piatră de hotar.
O placă poate ajunge la timp și totuși nu reușește să avanseze proiectul. Se poate porni, dar tot nu acceptă calea de testare care contează. Poate fi asamblat corect, dar totuși ridică îndoieli cu privire la înlocuitori, ipoteze de programare, comportamentul interfeței sau care revizuire este cu adevărat pe bancă. Uneori hardware-ul nu este deloc problema. Echipa pur și simplu nu este de acord cu ceea ce contează ca o trecere, ce contează ca o abatere acceptabilă și ce ar trebui să declanșeze o altă rotire.
De aceea, verificarea prototipului deseori alunecă după livrare, mai degrabă decât înainte.
O placă poate fi construită înainte de a fi cu adevărat verificabilă.
Ceea ce încetinește de obicei verificarea
Verificarea prototipului tinde să încetinească atunci când echipa tratează „planșele primite” ca și cum ar însemna deja „hardware gata de decizie-”.
De obicei, nu.
Transfer de date slab
Unele modele de prototip sunt lansate cu suficiente informații pentru a fabrica placa, dar nu suficiente informații pentru a o verifica în mod curat.
Gerbers și o BOM pot fi prezente. Ceea ce este adesea mai slab este totul în jurul lor: notele de programare, intenția de asamblare, alternativele aprobate, ipotezele firmware-ului, indicațiile de polaritate, criteriile de trecere și logica de validare care spune echipei ce este menită să rezolve de fapt această rotire.
Asta creează imediat frecare.
Plăcile sosesc, dar cei care încearcă să le valideze mai au nevoie de lămuriri. Apoi fiecare comportament neașteptat se transformă într-o altă rundă de interpretare. Proiectul nu este blocat pentru că casa de montaj a fost lentă. Este blocat deoarece pachetul de compilare a fost suficient de complet pentru a fi lansat, dar nu suficient de complet pentru a sprijini învățarea rapidă.
Descoperiri tardive ale DFM
Unele întârzieri de verificare a prototipului nu sunt cauzate de o defecțiune electrică. Acestea sunt cauzate de probleme de fabricabilitate care devin evidente doar după ce designul s-a mutat deja prea departe.
O nepotrivire a amprentei, un acces slab la-puncte de testare, o problemă termică care poate fi evitată sau o alegere de aspect-orientată pe asamblare nu poate împiedica construirea plăcii. Poate încetini în continuare verificarea odată ce comportamentul intermitent, inconsecvența lipirii sau dificultatea de sondare încep să ascundă adevărata întrebare de proiectare.
De aceea, problemele DFM târzii sunt costisitoare în munca de prototip. Ei nu întârzie doar următoarea rotire. De asemenea, reduc valoarea de învățare a spinului curent.
Substituții bazate pe{0}}disponibilitate
O construcție prototip poate tolera mai multă flexibilitate de aprovizionare decât un lot pilot. Este normal.
Problema începe atunci când piesele înlocuitoare sunt alese rapid, dar nu sunt incluse clar în logica de validare. În acel moment, echipa nu mai testează o ipoteză clară. Testează designul și soluția de aprovizionare.
Această distincție contează mai mult decât se așteaptă multe echipe.
O alternativă compatibilă cu pin-poate schimba în continuare comportamentul de pornire, răspunsul termic, marjele de sincronizare sau caracteristicile semnalului suficient pentru a complica-apariția. Verificarea încetinește apoi, deoarece echipa încearcă să răspundă la o întrebare diferită de cea la care plănuia să răspundă. Proiectul devine parțial exercițiu de depanare, parțial exercițiu de re-calificare.
Pregătirea de testare care a rămas în urma pregătirii pentru construcție
Acesta este unul dintre cele mai comune blocaje ascunse.
O placă poate fi asamblată la timp în timp ce calea reală de verificare nu este deloc gata. Este posibil ca fișierele de programare să fie încă în mișcare. Configurarea bancului poate fi încă informală. Este posibil ca dispozitivele să nu existe încă. Așteptările funcționale pot fi încă vagi. Chiar și logica de trecere/eșec poate fi prea liberă pentru a sprijini decizii rapide.
În acele cazuri, asamblarea PCB nu este cea care a încetinit proiectul. Diferența se află între finalizarea construcției și execuția testului utilizabil.
Un prototip-complet AOI nu este automat un prototip-pregătit pentru verificare.
Sondarea manuală începe să devină blocaj
Sondarea manuală este bună pentru unele plăci foarte timpurii.
Devine o picătură mult mai repede decât se așteaptă multe echipe.
Odată ce placa devine mai densă, accesul se înrăutățește sau numărul de unități crește dincolo de o mână de mostre, verificarea manuală începe să transforme fiecare placă în propria sa mică investigație. Echipa poate primi răspunsuri în continuare, dar le primește mai încet, cu verificări mai repetate și cu mai multă dependență de cine ține sonda.
Acesta este motivul pentru care instalațiile simple de dezvoltare, un acces mai bun la sondă sau o cale de aducere-mai structurată pot conta chiar și în etapele prototipului. Scopul este să nu construim un dispozitiv de producție complet prea devreme. Scopul este de a nu mai pierde timpul de verificare pe probleme de acces fizic care pot fi evitate.
O build încearcă să răspundă la prea multe întrebări
Unele loturi prototip se mișcă încet, deoarece domeniul de aplicare al construcției este pur și simplu prea larg.
Se așteaptă ca placa să valideze funcția hardware, comportamentul software, stabilitatea puterii, integritatea semnalului, temperatura, fabricabilitatea, comportamentul pe teren și poate chiar și ipotezele timpurii de conformitate. În teorie, sună eficient. În practică, înseamnă că niciuna dintre întrebările deschise nu se închide curat.
Un prototip concentrat se verifică de obicei mai repede decât o construcție care încearcă să rezolve totul într-o singură trecere.
În munca de prototip, programul se mișcă adesea cu cea mai lentă întrebare nerezolvată, nu doar cu cel mai lent pas fizic.
Unde echipele OEM apreciază greșit problema
Cea mai frecventă greșeală este să presupunem că întârzierea aparține încă producției.
Uneori o face. De multe ori nu.
Odată ce plăcile sunt deja pe bancă, adevăratul blocaj se transformă de obicei în logica de validare, controlul revizuirii, claritatea surselor și secvențierea testelor. Proiectul încă se simte lent, dar nu mai este lent din același motiv pentru care era lent înainte de livrarea construcției.
Această distincție contează deoarece echipele reacționează adesea la o problemă greșită. Ei fac eforturi pentru o construcție mai rapidă-turnului următor, atunci când ceea ce au nevoie cu adevărat este un obiectiv de validare mai strâns, o linie de referință de revizuire mai clară sau o cale de testare care poate susține de fapt deciziile în loc să genereze mai multe discuții.
Un consiliu poate reveni la program și poate pierde încă o săptămână în verificare dacă echipa încă se ceartă despre ceea ce trebuia să demonstreze exact.
Un caz limită util
Un lot prototip mic nu înseamnă automat că verificarea ar trebui să fie rapidă.
O versiune de zece-tablete poate verifica în continuare lent dacă fiecare unitate are modificări nerezolvate de sursă, intenție de testare neclară și ipoteze de revizuire mixte. O rotire de cinci-placă se poate trage, de asemenea, dacă linia de bază a firmware-ului se mișcă în același timp și planul de validare nu a fost niciodată restrâns suficient.
Pe de altă parte, un lot ceva mai mare se poate verifica mai repede dacă BOM-ul este mai curat, întrebarea este mai restrânsă și calea-de apariție este deja structurată.
De aceea, numărul de plăci este un predictor slab al vitezei de verificare.
Ce ajută verificarea să se miște mai rapid
Dacă scopul este de a scurta verificarea prototipului, cele mai mari îmbunătățiri sunt de obicei făcute înainte de începerea următoarei versiuni.
Blocați întrebarea de validare mai devreme
Un prototip se verifică mai repede atunci când echipa știe ce ar trebui să demonstreze această rotire și, la fel de important, ce nu ar trebui să demonstreze.
Păstrați vizibile modificările de proveniență
Dacă s-au folosit substituții bazate pe disponibilitate-, acestea ar trebui să fie evidente în înregistrarea versiunii și ușor de discutat în timpul validării. Modificările ascunse ale surselor creează o învățare lentă.
Aliniați pachetul de date cu calea de testare
Revizuirea BOM, ieșirea ansamblului, versiunea de firmware, ipotezele de programare și lista de verificare-de apariție ar trebui să indice aceeași linie de bază dorită.
Pregătiți traseul de testare înainte de sosirea plăcilor
Programarea, configurarea bancului, criteriile de promovare și orice lucru simplu de fixare nu ar trebui să aștepte până când ansamblurile sunt deja în mână.
Tratați DFM și accesul de testare ca probleme de pregătire pentru verificare
Dacă accesul la test este slab sau riscurile de fabricabilitate sunt încă nerezolvate, verificarea va rămâne rareori curată, indiferent cât de repede au fost construite plăcile.
Acesta este exact în cazul în care gândirea în termeni deTestare și inspecțiedevine util, chiar și în stadiul de prototip.
De ce acest lucru contează mai mult în mediul actual
În mediul actual de aprovizionare, înlocuirile bazate pe disponibilitate-sunt mai frecvente, iar reducerea-la timpului de livrare este inegală între categorii. Acest lucru face ca verificarea prototipului să fie mai lentă ori de câte ori modificările materiale nu sunt reflectate clar în planul de validare. Placa poate ajunge la timp. Calea de învățare de multe ori nu.
Acesta este un alt motiv pentru care verificarea prototipului ar trebui să fie tratată ca o etapă proprie de inginerie și coordonare, nu doar ca finalul final al asamblarii.
Concluzie
Verificarea prototipurilor în proiectele de asamblare PCB este adesea încetinită de ceea ce se întâmplă după sosirea plăcilor, nu doar de cât de repede au fost construite.
Cele mai frecvente cauze sunt transferul slab al datelor, constatările cu întârziere în DFM, înlocuirile bazate pe disponibilitate-, pregătirea slabă pentru testare, frecarea de sondare manuală, deviația de revizuire și obiectivele de validare care sunt prea ample pentru ca o singură rotire să poată răspunde clar.
Nu toate sunt probleme de fabricație. Multe dintre ele sunt probleme de lansare, testare și transfer înainte de a fi probleme pure de fabricație.
De aceea echipele ar trebui să înceteze să trateze „prototipul livrat” ca și cum ar însemna „prototipul verificat”.
Scândurile de pe bancă nu scurtează de la sine programul. O cale de verificare utilizabilă o face.
Dacă echipa dvs. încearcă să scurteze verificarea prototipului, un pas practic următor este să revizuiți construcția față deAnsamblu PCB,strângeți calea de validare cu nivelul potrivit deTestare și inspecțiegândindu-vă, apoi aliniați următorul scop prototipSolicitați o cotațiesau contactați echipa direct lainfo@pcba-china.com.
FAQ
Care este diferența dintre livrarea prototipului și verificarea prototipului?
Livrarea prototipului înseamnă că plăcile au fost asamblate și primite. Verificarea prototipului înseamnă că echipa a folosit aceste plăci pentru a răspunde la întrebarea tehnică intenționată și pentru a decide ce se întâmplă în continuare.
De ce o placă prototip poate fi livrată la timp și totuși poate fi verificată încet?
Deoarece încetinirea trece adesea de la logica de producție la logica de validare, claritatea BOM, incertitudinea-piesei de înlocuire, pregătirea pentru testare, controlul revizuirii și alinierea inter-funcțională.
O asamblare mai rapidă a prototipului înseamnă automat o verificare mai rapidă?
Nu. Asamblarea mai rapidă ajută numai dacă calea de validare este deja suficient de clară pentru a utiliza hardware-ul anterior în mod eficient.
Care este una dintre cele mai neglijate cauze ale întârzierii verificării?
O cauză obișnuită trecută cu vederea este aceea că pachetul de compilare a fost suficient de complet pentru a fi lansat, dar nu suficient de complet pentru a fi validat în mod curat odată ce au sosit plăcile.
