Įvadas
Daugelis OEM komandų mano, kad kai tik bus pristatytos prototipinės plokštės, patikrinimas bus atliktas greitai.
Tai skamba pagrįstai. Realiuose projektuose dažnai taip nėra.
PCB agregato prototipas gali sugrįžti pagal grafiką ir vis tiek praleisti dienas ar net savaitę tikrinant, ar komanda vis dar ginčijasi dėl to, ką turėjo įrodyti konstrukcija, kas pasikeitė MK, ar bandymo kelias yra paruoštas naudoti tinkamam atsakymui. Tuo metu sulėtėjimas nebėra susijęs tik su surinkimo trukme. Tai tampa išleidimo, testavimo ir perdavimo problema.
Tai yra tikrasis šio straipsnio klausimas. Svarbu ne tik tai, kaip greitai galima sukurti prototipą. Problema ta, kodėl tikrinimas vis dar stringa, kai lentos jau yra ant suolo.
Jei jūsų komanda jau pralenkė-lentos laiką ir dabar bando suprasti, kodėl prototipo pažanga vis dar atrodo lėta, verta pažvelgti ne tik į surinkimą ir peržiūrėti visą kelią.PCB surinkimas.
Prototipo pristatymas ir prototipo patikrinimas nėra tas pats etapas
Čia daugelis tvarkaraščių klaidingai perskaitomi.
Prototipo pristatymas reiškia, kad plokštės buvo pagamintos, surinktos ir gautos. Prototipo patikra reiškia, kad komanda iš tikrųjų panaudojo šias lentas, kad atsakytų į numatytą techninį klausimą ir nuspręstų, kas nutiks toliau.
Tai nėra tas pats etapas.
Lenta gali atvykti laiku ir vis tiek nepavyks pajudinti projekto į priekį. Jis gali įsijungti, tačiau vis tiek nepalaiko svarbaus bandymo kelio. Jis gali būti surinktas teisingai, bet vis tiek kelia abejonių dėl pakaitalų, programavimo prielaidų, sąsajos elgsenos arba dėl to, kuri peržiūra iš tikrųjų laukiama. Kartais problema nėra aparatinė įranga. Komanda tiesiog nesutaria, kas laikoma perdavimu, kas priimtinu nukrypimu ir kas turėtų sukelti kitą sukimąsi.
Štai kodėl prototipo patikra dažnai nuslysta po pristatymo, o ne prieš jį.
Lentą galima pastatyti anksčiau, nei ji tikrai patikrinama.
Kas paprastai lėtina patvirtinimą
Prototipo tikrinimas paprastai sulėtėja, kai komanda „gautas lentas“ traktuoja taip, lyg tai jau reikštų „sprendimui{0}}paruošta aparatinė įranga“.
Paprastai taip nėra.
Silpnas duomenų perdavimas
Kai kurios prototipų versijos išleidžiamos su pakankamai informacijos, kad būtų galima pagaminti plokštę, bet nepakanka informacijos, kad ji būtų švari.
Gali būti gerberių ir MK. Tai, kas dažnai yra silpnesnė, yra viskas aplinkui: programavimo pastabos, surinkimo tikslas, patvirtinti pakaitiniai elementai, programinės įrangos prielaidos, poliškumo išnašos, perdavimo kriterijai ir patvirtinimo logika, nurodanti komandai, ką šis sukimas iš tikrųjų turi išspręsti.
Tai iš karto sukuria trintį.
Lentelės atkeliauja, tačiau jas patvirtinti bandančius žmones dar reikia paaiškinti. Tada kiekvienas netikėtas elgesys virsta dar vienu aiškinimu. Projektas neužblokuotas, nes surinkimo namas buvo lėtas. Jis užblokuotas, nes kūrimo paketas buvo pakankamai pilnas, kad būtų išleistas, bet nepakankamai užbaigtas, kad būtų palaikomas greitas mokymasis.
Vėlyvos DFM išvados
Kai kurių prototipų patikros vėlavimų priežastis nėra elektros gedimas. Jas sukelia gamybos problemos, kurios tampa akivaizdžios tik tada, kai dizainas jau per toli.
Pėdų atspaudų neatitikimas, silpna bandymo{0}}taško prieiga, išvengiama šiluminė problema arba į surinkimą{1}} orientuotas išdėstymo pasirinkimas gali nesustabdyti plokštės kūrimo. Jis vis tiek gali labai sulėtinti tikrinimą, kai nutrūksta elgesys, litavimo nenuoseklumas arba zondavimo sunkumai pradeda slėpti tikrąjį dizaino klausimą.
Štai kodėl vėlyvos DFM problemos yra brangios atliekant prototipų darbą. Jie ne tik atideda kitą sukimąsi. Jie taip pat sumažina dabartinio sukimosi mokymosi vertę.
Prieinamumo{0}}pakeitimai
Prototipo konstrukcija gali toleruoti daugiau lankstumo tiekimo srityje nei bandomoji partija. Tai normalu.
Bėdos prasideda, kai pakaitinės dalys parenkamos greitai, bet nėra aiškiai įtrauktos į patvirtinimo logiką. Tuo metu komanda nebebando vienos aiškios prielaidos. Tai išbando dizainą ir šalinimo būdą.
Šis skirtumas yra svarbesnis nei daugelis komandų tikisi.
Suderinamas kaiščių-alternatyvas vis tiek gali pakankamai pakeisti paleidimo elgseną, šiluminį atsaką, laiko ribas arba signalo charakteristikas, kad apsunkintų iškvietimą. Tada tikrinimas sulėtėja, nes komanda bando atsakyti į kitokį klausimą, nei planavo atsakyti. Projektas tampa derinimo pratimo dalimi,{4}}perkvalifikavimo pratimu.
Bandymo parengtis atsiliko nuo kūrimo parengties
Tai yra viena iš labiausiai paplitusių paslėptų kliūčių.
Plokštė gali būti surinkta laiku, kol tikrasis patikrinimo kelias visai nėra paruoštas. Programavimo failai vis dar gali būti perkelti. Suoliuko nustatymas vis tiek gali būti neoficialus. Armatūra dar gali neegzistuoti. Funkciniai lūkesčiai vis dar gali būti neaiškūs. Net patvirtinimo/nepavyko logika gali būti per laisva, kad būtų galima priimti greitus sprendimus.
Tokiais atvejais PCB surinkimas nėra tai, kas sulėtino projektą. Tarpas yra tarp kūrimo užbaigimo ir tinkamo bandymo vykdymo.
AOI{0}}užbaigtas prototipas automatiškai nėra patvirtinimui{1}}paruoštas prototipas.
Rankinis zondavimas pradeda tapti kliūtimi
Kai kurioms labai ankstyvoms plokštėms tinka rankinis zondavimas.
Tai tampa daug greičiau, nei daugelis komandų tikisi.
Kai plokštė tampa tankesnė, prieiga pablogėja arba vienetų skaičius viršija keletą pavyzdžių, rankinis patikrinimas pradeda paversti kiekvieną plokštę savo nedideliu tyrimu. Komanda vis tiek gali gauti atsakymus, bet juos gauna lėčiau, dažniau tikrindama ir labiau priklausydama nuo to, kas atlieka tyrimą.
Štai kodėl paprasti kūrimo įrenginiai, geresnė prieiga prie zondo arba labiau struktūrizuotas{0}}vedimo kelias gali būti svarbūs net prototipo etapuose. Tikslas yra ne per anksti sukurti pilną gamybos įrangą. Tikslas – nebešvaistyti tikrinimo laiko dėl išvengiamų fizinės prieigos problemų.
Viena konstrukcija bando atsakyti į per daug klausimų
Kai kurios prototipų dalys juda lėtai, nes konstrukcijos apimtis yra per plati.
Tikimasi, kad plokštė vienu metu patvirtins aparatinės įrangos funkciją, programinės įrangos elgseną, maitinimo stabilumą, signalo vientisumą, šilumines charakteristikas, gamybiškumą, elgesį lauke ir galbūt net ankstyvas atitikties prielaidas. Teoriškai tai skamba efektyviai. Praktiškai tai reiškia, kad nė vienas iš atvirų klausimų neuždaromas švariai.
Koncentruotas prototipas paprastai patikrinamas greičiau nei konstrukcija, kuri bando viską išspręsti vienu važiavimu.
Prototipų darbe tvarkaraštis dažnai perkeliamas su lėčiausiu neišspręstu klausimu, o ne tik lėčiausiu fiziniu žingsniu.
Kur OĮG komandos paprastai klaidingai įvertina problemą
Dažniausia klaida yra manyti, kad vėlavimas vis dar priklauso gamybai.
Kartais tai daro. Dažnai taip nėra.
Kai plokštės jau yra ant stendo, tikroji kliūtis paprastai pereina į patvirtinimo logiką, peržiūros valdymą, šaltinio aiškumą ir testų seką. Projektas vis dar atrodo lėtas, tačiau jis nebėra lėtas dėl tos pačios priežasties, kuri buvo lėta prieš išsiunčiant versiją.
Šis skirtumas yra svarbus, nes komandos dažnai reaguoja į neteisingą problemą. Jie skatina greitesnį kito posūkio kūrimą, kai jiems iš tikrųjų reikia griežtesnio patvirtinimo tikslo, tikslesnės peržiūros pradžios arba bandymo kelio, kuris iš tikrųjų gali padėti priimti sprendimus, o ne tik sukelti daugiau diskusijų.
Valdyba gali grįžti pagal grafiką ir vis tiek prarasti savaitę patikrinimo metu, jei komanda vis dar ginčijasi, ką tiksliai ji turėjo įrodyti.
Naudingas ribinis atvejis
Maža prototipo partija automatiškai nereiškia, kad patikrinimas turi būti greitas.
Dešimties -plokštės versija vis tiek gali lėtai patikrinti, ar kiekviename bloke yra neišspręstų šaltinio pakeitimų, neaiškių bandymų tikslo ir mišrių peržiūros prielaidų. Penkių- lentų sukimas taip pat gali trukti, jei tuo pačiu metu juda pagrindinė programinės įrangos linija, o patvirtinimo planas niekada nebuvo pakankamai susiaurintas.
Kita vertus, šiek tiek didesnė partija gali greičiau patikrinti, ar MK yra švaresnė, klausimas siauresnis, o iškėlimo kelias jau sutvarkytas.
Štai kodėl vien lentų skaičius yra prastas patikrinimo greičio prognozuotojas.
Kas padeda patvirtinimui judėti greičiau
Jei tikslas yra sutrumpinti prototipo patikrinimą, didžiausi patobulinimai paprastai atliekami prieš pradedant kitą kūrimą.
Užrakinkite patvirtinimo klausimą anksčiau
Prototipas patikrina greičiau, kai komanda žino, ką šis sukimas turi įrodyti, o ne mažiau svarbu, ko ji neturi įrodyti.
Kad šaltinio pakeitimai būtų matomi
Jei buvo naudojami pasiekiamumo{0}}pakeitimai, jie turėtų būti akivaizdūs versijos įraše ir lengvai aptariami tikrinant. Paslėpti šaltinio pakeitimai sukelia lėtą mokymąsi.
Sulygiuokite duomenų paketą su bandymo keliu
KMK peržiūra, surinkimo išvestis, programinės aparatinės įrangos versija, programavimo prielaidos ir pateiktas{0}}kontrolinis sąrašas turėtų nurodyti tą pačią numatytą bazinę liniją.
Paruoškite bandymo kelią prieš atvykstant lentoms
Programavimas, stendo sąranka, išlaikymo kriterijai ir bet koks paprastas montavimo darbas neturėtų laukti, kol mazgai jau bus rankoje.
DFM ir bandymo prieigą traktuokite kaip pasirengimo patvirtinimui problemas
Jei bandomoji prieiga yra prasta arba gamybos rizika vis dar neišspręsta, patikrinimas retai išliks švarus, nesvarbu, kaip greitai buvo pastatytos plokštės.
Būtent čia mąstomaTestavimas ir apžiūratampa naudinga net prototipo stadijoje.
Kodėl tai svarbiau dabartinėje aplinkoje
Esant dabartinei tiekimo aplinkai, prieinamumo{0}}pagrįsti pakaitalai yra dažnesni, o pristatymo-laikas įvairiose kategorijose nevienodas. Dėl to prototipo patikra lėtėja, kai esminiai pakeitimai nėra aiškiai atspindėti patvirtinimo plane. Lenta vis tiek gali atvykti laiku. Mokymosi kelias dažnai to nedaro.
Tai dar viena priežastis, kodėl prototipo patikra turėtų būti traktuojama kaip atskiras inžinerijos ir koordinavimo etapas, o ne tik kaip surinkimo laiko pabaiga.
Išvada
PCB surinkimo projektų prototipų patikra dažnai sulėtėja dėl to, kas nutinka po plokščių pristatymo, o ne tik dėl to, kaip greitai jos buvo pagamintos.
Dažniausios priežastys yra silpnas duomenų perdavimas, vėlyvos DFM išvados, pasiekiamumas{0}}pagrįsti pakaitalai, prastas pasirengimas bandymams, rankinio tikrinimo trintis, peržiūros poslinkis ir patvirtinimo tikslai, kurie yra per platūs, kad vienas sukimas galėtų tiksliai atsakyti.
Tai ne visos gamybos problemos. Daugelis iš jų yra išleidimo, bandymo ir perdavimo problemos, kol jos nėra vien tik gamybos problemos.
Štai kodėl komandos turėtų nustoti traktuoti „prototipas pristatytas“ taip, lyg tai reikštų „prototipas patikrintas“.
Lentos ant suoliuko savaime grafiko netrumpina. Tinkamas patvirtinimo kelias.
Jei jūsų komanda bando sutrumpinti prototipo patvirtinimą, kitas praktiškas veiksmas yra peržiūrėti kūrimąPCB surinkimas,sugriežtinkite patvirtinimo kelią tinkamu lygiuTestavimas ir apžiūramąstymą, o tada suderinkite kito prototipo taikymo sritįPrašyti kainos pasiūlymoarba susisiekite su komanda tiesiogiai elinfo@pcba-china.com.
DUK
Kuo skiriasi prototipo pristatymas ir prototipo patikrinimas?
Prototipo pristatymas reiškia, kad plokštės buvo surinktos ir gautos. Prototipo patikra reiškia, kad komanda naudojo šias lentas, kad atsakytų į numatytą techninį klausimą ir nuspręstų, kas nutiks toliau.
Kodėl plokštės prototipas gali būti pristatytas laiku ir vis tiek tikrinamas lėtai?
Kadangi sulėtėjimas dažnai pereina nuo gamybos prie patvirtinimo logikos, MK aiškumo, pakaitinės dalies neapibrėžtumo, pasirengimo bandymams, peržiūros kontrolės ir kryžminio -funkcinio suderinimo.
Ar greitesnis prototipo surinkimas automatiškai reiškia greitesnį patikrinimą?
Ne. Greitesnis surinkimas padeda tik tuo atveju, jei patvirtinimo kelias jau pakankamai aiškus, kad būtų galima efektyviai naudoti ankstesnę aparatinę įrangą.
Kokia yra viena iš labiausiai nepastebimų patikrinimo delsos priežasčių?
Dažna nepastebima priežastis yra ta, kad kūrimo paketas buvo pakankamai pilnas, kad būtų išleistas, bet nepakankamai išsamus, kad būtų galima švariai patvirtinti plokštes gavus.
