Bevezetés
Sok OEM-csapat azt feltételezi, hogy amint a prototípus táblák megérkeznek, az ellenőrzés gyorsan megtörténik.
Ez ésszerűen hangzik. A valódi projektekben gyakran nem.
A prototípus nyomtatott áramköri lap-összeállítás visszatérhet az ütemterv szerint, és napokat, vagy akár egy hetet is veszíthet az ellenőrzés során, ha a csapat még mindig azon vitatkozik, hogy mit kellett volna bizonyítania a buildnek, mi változott a BOM-ban, vagy hogy a tesztút készen áll-e egy használható válasz előállítására. Ezen a ponton a lassulás már nem csak az összeszerelés átfutási idejére vonatkozik. Ez kiadási, tesztelési és átadási problémává válik.
Ez az igazi kérdés a cikk mögött. A kérdés nem csak az, hogy milyen gyorsan lehet egy prototípust megépíteni. A probléma az, hogy miért akad el az ellenőrzés, miután a táblák már a padon vannak.
Ha csapata már túl van a táblaidőzítésen-, és most azt próbálja megérteni, miért tűnik még mindig lassúnak a prototípus fejlődése, akkor érdemes túl tekinteni az összeszerelésen, és át kell tekinteni a teljes utat.PCB összeállítás.
A prototípus szállítása és a prototípus ellenőrzése nem ugyanaz a mérföldkő
Ez az a hely, ahol sok menetrendet félreolvasnak.
A prototípus szállítása azt jelenti, hogy a táblákat legyártották, összeszerelték és megkapták. A prototípus-ellenőrzés azt jelenti, hogy a csapat valóban felhasználta ezeket a táblákat a tervezett technikai kérdés megválaszolására és a következő lépések eldöntésére.
Ezek nem ugyanazok a mérföldkövek.
Egy tábla időben megérkezhet, és mégsem tudja előremozdítani a projektet. Lehet, hogy bekapcsol, de még mindig nem támogatja a fontos tesztutat. Lehet, hogy helyesen van összeszerelve, de továbbra is kételyeket ébreszt a helyettesítőkkel, a programozási feltételezésekkel, az interfész viselkedésével kapcsolatban, vagy hogy melyik revízió van valójában a padon. Néha egyáltalán nem a hardver a probléma. A csapat egyszerűen nem ért egyet abban, hogy mi számít passznak, mi számít elfogadható eltérésnek, és mi váltson ki újabb pörgést.
Ez az oka annak, hogy a prototípus ellenőrzése gyakran megcsúszik a szállítás után, nem pedig előtte.
A tábla megépíthető, mielőtt valóban ellenőrizhető lenne.
Mi általában lassítja az ellenőrzést
A prototípus-ellenőrzés általában lelassul, amikor a csapat úgy kezeli a „beérkezett táblákat”, mintha az már „döntésre{0}}kész hardver” lenne.
Általában nem.
Gyenge adatátadás
Egyes prototípus-összeállítások elegendő információval rendelkeznek a tábla gyártásához, de nem elegendő információval a tisztaság ellenőrzéséhez.
Előfordulhat, hogy gerberek és anyagjegyzék található. Ami gyakran gyengébb, az minden körülöttük van: programozási megjegyzések, összeállítási szándék, jóváhagyott alternatívák, firmware-feltevések, polaritás-feliratok, átadási kritériumok és az érvényesítési logika, amely megmondja a csapatnak, hogy ez a pörgés valójában mit is jelent.
Ez azonnal súrlódást okoz.
A táblák megérkeznek, de az érvényesíteni próbáló embereket még tisztázni kell. Ezután minden váratlan viselkedés újabb értelmezési körbe fordul. A projekt nincs blokkolva, mert a szerelőház lassú volt. Le van tiltva, mert az összeállítási csomag elég teljes volt a kiadáshoz, de nem elég teljes a gyors tanulás támogatásához.
A DFM késői megállapításai
Egyes prototípus-ellenőrzési késéseket nem elektromos hiba okozza. Ezeket a gyártási problémák okozzák, amelyek csak akkor válnak nyilvánvalóvá, ha a tervezés már túl messzire mozdult.
Előfordulhat, hogy a lábnyom eltérése, a gyenge teszt{0}}elérési pont, az elkerülhető hőprobléma vagy az összeállítás-orientált elrendezés nem akadályozza meg a tábla építését. Továbbra is csúnyán lelassíthatja az ellenőrzést, ha a szaggatott viselkedés, a forrasztási inkonzisztencia vagy a vizsgálati nehézségek eltakarják a valódi tervezési kérdést.
Ezért a késői DFM-problémák költségesek a prototípus-munka során. Nem csak késleltetik a következő pörgetést. Csökkentik az aktuális pörgés tanulási értékét is.
Elérhetőség{0}}vezérelt helyettesítések
Egy prototípus-konstrukció több beszerzési rugalmasságot tud elviselni, mint egy kísérleti tétel. Ez normális.
A baj akkor kezdődik, amikor a pótalkatrészeket gyorsan választják ki, de nem veszik át egyértelműen az érvényesítési logikába. Ezen a ponton a csapat már nem tesztel egyetlen tiszta feltételezést. A tervezést és a beszerzési megoldást teszteli.
Ez a megkülönböztetés többet számít, mint sok csapat számít.
A tűs-kompatibilis alternatíva továbbra is eléggé eltolja az indítási viselkedést, a hőválaszt, az időzítési határokat vagy a jel jellemzőit ahhoz, hogy megnehezítse az előhívást. Az ellenőrzés ezután lelassul, mert a csapat a tervezetttől eltérő kérdésre próbál válaszolni. A projekt részben hibakeresési gyakorlat, részben újraminősítési gyakorlat lesz.
Tesztkészültség, amely elmaradt az összeépítési készenléttől
Ez az egyik leggyakoribb rejtett szűk keresztmetszet.
Előfordulhat, hogy egy tábla időben összeállítható, miközben a tényleges ellenőrzési útvonal egyáltalán nem áll készen. A programfájlok továbbra is mozoghatnak. A pad beállítása továbbra is informális lehet. Előfordulhat, hogy a rögzítések még nem léteznek. A funkcionális elvárások továbbra is homályosak lehetnek. Előfordulhat, hogy még a sikeres/nem teljesítési logika is túl laza ahhoz, hogy támogassa a gyors döntéseket.
Ezekben az esetekben a PCB Assembly nem az, ami lelassította a projektet. A szakadék az összeállítás befejezése és a használható tesztvégrehajtás között van.
Az AOI{0}}komplett prototípus nem automatikusan egy ellenőrzésre{1}}kész prototípus.
A kézi szondázás kezd szűk keresztmetszetté válni
A kézi szondázás jó néhány nagyon korai táblánál.
Ez sokkal gyorsabb lesz, mint sok csapat számít.
Amint a tábla sűrűbbé válik, a hozzáférés rosszabbodik, vagy az egységek száma meghaladja a maroknyi mintát, a kézi ellenőrzés megkezdi az egyes táblák saját kis vizsgálatát. A csapat továbbra is kaphat választ, de lassabban, többszöri ellenőrzéssel, és jobban függ attól, hogy ki tartja a szondát.
Ez az oka annak, hogy az egyszerű fejlesztési eszközök, a jobb szonda-hozzáférés vagy a strukturáltabb előállítási út-már a prototípus szakaszaiban is számíthatnak. A cél az, hogy ne építsenek túl korán egy teljes gyártási rendszert. A cél az, hogy ne pazaroljuk az ellenőrzési időt az elkerülhető fizikai hozzáférési problémákra.
Egy build túl sok kérdésre próbál választ adni
Egyes prototípus-tételek lassan mozognak, mert az építkezés hatóköre egyszerűen túl széles.
A tábla várhatóan egyszerre érvényesíti a hardver működését, a szoftver viselkedését, az energiastabilitást, a jel integritását, a hőt, a gyárthatóságot, a terepi viselkedést és talán még a korai megfelelőségi feltételezéseket is. Elméletileg ez hatékonyan hangzik. A gyakorlatban ez azt jelenti, hogy a nyitott kérdések egyike sem zárul le tisztán.
Egy fókuszált prototípus általában gyorsabban ellenőrzi, mint egy olyan építmény, amely mindent egy menetben próbál rendezni.
A prototípus-munka során az ütemterv gyakran a leglassabb megoldatlan kérdéssel mozog, nem csak a leglassabb fizikai lépéssel.
Ahol az OEM csapatok általában rosszul ítélik meg a problémát
A leggyakoribb hiba az, hogy feltételezzük, hogy a késés még mindig a gyártáshoz tartozik.
Néha igen. Gyakran nem.
Amint a táblák már a padon vannak, az igazi szűk keresztmetszet általában az érvényesítési logikába, a revízióvezérlésbe, a beszerzési tisztaságba és a tesztek sorrendjébe tolódik. A projekt továbbra is lassúnak tűnik, de már nem lassú ugyanabból az okból, amilyen lassú volt a build kiszállítása előtt.
Ez a különbségtétel azért fontos, mert a csapatok gyakran rossz problémára reagálnak. Gyorsabb következő-fordulós felépítést szorgalmaznak, amikor valóban szükségük van egy szigorúbb érvényesítési célkitűzésre, egy tisztább felülvizsgálati alapra vagy egy olyan tesztútvonalra, amely ténylegesen támogatja a döntéseket, ahelyett, hogy több vitát generálna.
Egy tábla visszatérhet az ütemterv szerint, és még mindig elveszíthet egy hetet az ellenőrzésben, ha a csapat még mindig azon vitatkozik, hogy pontosan mit is kellett volna bizonyítania.
Hasznos határeset
Egy kis prototípus tétel nem jelenti automatikusan azt, hogy az ellenőrzésnek gyorsnak kell lennie.
A tíz-tábla összeállítása továbbra is lassan tudja ellenőrizni, hogy az egyes egységekben vannak-e megoldatlan forrásmódosítások, nem egyértelmű a tesztelési szándék és vegyes felülvizsgálati feltételezések. Az öt-tábla pörgetése akkor is elhúzódhat, ha a firmware alapvonala egyidejűleg mozog, és az érvényesítési terv soha nem volt eléggé szűkítve.
Másrészt egy valamivel nagyobb tétel gyorsabban ellenőrizheti, hogy az anyagjegyzék tisztább, a kérdés szűkebb-e, és az előállítási útvonal-már strukturált.
Éppen ezért a táblaszám önmagában rossz előrejelzője az ellenőrzési sebességnek.
Mi segíti az ellenőrzést gyorsabban
Ha a prototípus ellenőrzésének lerövidítése a cél, akkor a legnagyobb fejlesztéseket általában a következő építés megkezdése előtt hajtják végre.
Zárja le az érvényesítési kérdést korábban
A prototípus gyorsabban ellenőrzi, ha a csapat tudja, hogy ennek a pörgésnek mit kell bizonyítania, és ami ugyanilyen fontos, mit nem kell bizonyítania.
Tartsa láthatóan a beszerzési változásokat
Ha rendelkezésre állás-vezérelt helyettesítéseket használtak, akkor ezeknek nyilvánvalónak kell lenniük a build rekordban, és könnyen megvitathatók az ellenőrzés során. A rejtett forrásmódosítások lassú tanulást eredményeznek.
Igazítsa az adatcsomagot a tesztútvonalhoz
A darabjegyzék-revíziónak, az összeállítás kimenetének, a firmware-verziónak, a programozási feltételezéseknek és a -megjelenítési ellenőrzőlistának ugyanarra a tervezett alapvonalra kell mutatnia.
A táblák érkezése előtt készítse elő a tesztpályát
A programozás, a pad beállítás, az átadási kritériumok és bármilyen egyszerű rögzítési munka nem várhat addig, amíg az összeállítások már kézben vannak.
Kezelje a DFM-et és a tesztelési hozzáférést ellenőrzési készenléti problémaként
Ha a teszthez való hozzáférés gyenge, vagy a gyártási kockázatok még mindig megoldatlanok, az ellenőrzés ritkán marad tiszta, függetlenül attól, hogy milyen gyorsan készültek a táblák.
Pontosan itt gondolkodunkTesztelés és ellenőrzéshasznossá válik, még a prototípus szakaszában is.
Miért fontosabb ez a jelenlegi környezetben?
A jelenlegi beszerzési környezetben a rendelkezésre állás{0}}vezérelt helyettesítések gyakoribbak, és az átfutási idő-könnyítése egyenetlen a kategóriák között. Ez lelassítja a prototípus-ellenőrzést, ha a lényeges változások nem tükröződnek egyértelműen az érvényesítési tervben. A tábla még időben megérkezhet. A tanulási út gyakran nem.
Ez egy másik oka annak, hogy a prototípus-ellenőrzést a saját tervezési és koordinációs szakaszaként kell kezelni, nem csak az összeszerelés átfutási idejének végeként.
Következtetés
A NYÁK-összeszerelési projektekben a prototípus-ellenőrzést gyakran lelassítja az, hogy mi történik a táblák megérkezése után, nem csak az, hogy milyen gyorsan készültek.
A leggyakoribb okok a gyenge adatátadás, a késői DFM-megállapítások, a rendelkezésre állás-vezérelt helyettesítések, a gyenge tesztkészültség, a kézi vizsgálati súrlódás, a revíziósodródás és az érvényesítési célok, amelyek túl tágak ahhoz, hogy egyetlen pörgetés egyértelműen válaszoljon.
Ezek nem mind gyártási problémák. Sok közülük kiadási, tesztelési és átadási probléma, mielőtt tisztán gyártási probléma lenne.
Éppen ezért a csapatoknak fel kell hagyniuk azzal, hogy a „prototípus kézbesítve” úgy kezeljék, mintha az „a prototípus ellenőrizve” lenne.
A padon lévő táblák önmagukban nem rövidítik meg a menetrendet. Egy használható ellenőrzési útvonal igen.
Ha csapata megpróbálja lerövidíteni a prototípus-ellenőrzést, a következő gyakorlati lépés a build áttekintésePCB összeállítás,szigorítsa meg az érvényesítési útvonalat a megfelelő szinttelTesztelés és ellenőrzésgondolkodni, majd összehangolni a következő prototípus hatókörétKérjen árajánlatotvagy forduljon közvetlenül a csapathoz a címeninfo@pcba-china.com.
GYIK
Mi a különbség a prototípus szállítása és a prototípus ellenőrzése között?
A prototípus szállítása azt jelenti, hogy a táblákat összeszerelték és megkapták. A prototípus-ellenőrzés azt jelenti, hogy a csapat ezeket a táblákat használta a tervezett technikai kérdés megválaszolására és a következő lépések eldöntésére.
Miért lehet egy prototípus táblát időben leszállítani, és még mindig lassan ellenőrizni?
Mivel a lassulás gyakran a gyártásról az érvényesítési logikára, az anyagjegyzék egyértelműségére, a helyettesítő-alkatrész bizonytalanságára, a tesztelésre való készenlétre, a revízió-ellenőrzésre és a kereszt{1}}funkcionális összehangolásra vált át.
A prototípus gyorsabb összeállítása automatikusan gyorsabb ellenőrzést jelent?
Nem. A gyorsabb összeszerelés csak akkor segít, ha az érvényesítési útvonal már elég világos a korábbi hardver hatékony használatához.
Mi az ellenőrzési késedelem egyik leginkább figyelmen kívül hagyott oka?
A gyakran figyelmen kívül hagyott ok az, hogy az összeállítási csomag elég teljes volt a kiadáshoz, de nem elég teljes ahhoz, hogy a táblák megérkezése után tisztán érvényesítsen.
