Utvikling av kundetilpassede bærekort: prosess, kostnader og tidsplan

Hva gjør en tilpasset bærekort?

En bærekort kobler en datamodul til resten av et produkt. Det kan gi strømkonvertering, feltsendere, kontakter, beskyttelse, lagringstilkoblinger og kontrollfunksjoner. Det nøyaktige arbeidet avhenger av hva modulen allerede leverer og hva installasjonen krever.

Prosjektet strekker seg utover å plassere koblinger rundt en modul. Mekaniske begrensninger, signalintegritet, programvarekonfigurasjon, produksjon og tjenestetilgang samhandler. En kobling som flyttes sent i prosjektet kan påvirke ruting, kapsling-verktøy og ledningsnettet. Fang disse avhengighetene mens de fortsatt er rimelige å endre.

Hvis plattformbeslutningen fortsatt er åpen, begynn med SoM versus enkeltkorts datamaskinveiledning. Hvis designet inkluderer AI-slutning, valider den tiltenkte modellen og sensorbanen før du fryser beregningsmodulen.

Hva skal inkluderes i designbriefen

Merk ukjente eksplisitt og tildel hver en eier. For eksempel lar "fire kameraer" grensesnittet, sensoren, kabellengden, synkroniseringen og samtidige driftsmoduser åpne. En innledende oppdagelsesfase kan løse disse usikkerhetene før et fast implementeringsomfang er avtalt.

En praktisk design- og valideringsprosess

1. Krav og gjennomførbarhet. Bekreft modulen, grensesnittallokering, tilgjengelig programvare og store risikoer. Lag et avtalt blokkdiagram og akseptoversikt.
2. Skjematisk og komponentgjennomgang. Definer krafttreet, beskyttelse, klokker, tilbakestillinger og grensesnitt. Gjennomgå komponenttilgjengelighet og alternativer før layout.
3. Layout og produksjonsgjennomgang. Løs oppstabling, plassering, rutingbegrensninger, mekanisk tilpasning, monteringstilgang og testpunkter.
4. Prototypeinnkjøp og montering. Sjekk fabrikasjonsdata og komponenterstatninger, og registrer deretter konfigurasjonen som bygget for hvert kort.
5. oppstart og testing av maskinvare og programvareintegrasjon. Bekreft strøm og oppstart før du trener grensesnitt og applikasjonens arbeidsmengde. Spor problemer mot styre- og programvarerevisjoner.
6. Validering og overlevering. Kjør de avtalte testene, lukk problemer og lever utgivelsesdataene og støttedokumentene definert i prosjektets omfang.

Bruk modulprodusentens designguide og oppstart og testing av maskinvare sjekkliste for den valgte delen. Leverandørreferanser kan identifisere krav som er enkle å overse, men instruksjoner for en annen modul eller generasjon er ikke utskiftbare. NVIDIA-sjekklisten i referansene er et eksempel på hvordan maskinvare- og programvaresjekker dokumenteres for et bestemt økosystem.

Hva bestemmer bærekort NRE-kostnaden?

Engangsteknikk dekker arbeid utført for å lage og validere designet. Et nyttig tilbud skiller dette arbeidet fra prototypekomponenter, PCB-fabrikasjon, montering, inventar, ekstern testing og gjentakende produksjon. Avtal hvilke av disse som er inkludert, valgfrie eller belastes separat.

En ren "PCB design"-pris er vanskelig å sammenligne med et komplett tilbud om produktutvikling. Be om en leveringsliste, forutsetninger, ekskluderinger, akseptkriterier og endringsprosess. Det gjør det mulig å sammenligne forslag uten å forutsette at manglende arbeid er inkludert.

Hvordan bør tidslinjen planlegges?

Bygg tidsplanen rundt avhengigheter. Kravgodkjenning går foran designfrysingen; fabrikasjon og komponenttilgjengelighet bestemmer når sammensatte prototyper kan ankomme; En maskinvareendring kan kreve en ny produksjonssyklus før en test kan gjentas. Programvare kan fortsette parallelt på en utviklingsplattform bare der den plattformen representerer den endelige maskinvaren tett nok.

Et troverdig leveringsestimat krever et definert omfang og en komponentforsyningssjekk. Separer ingeniørarbeid fra medgått ledetid og inkluderer tid for gjennomgang, anskaffelse og en avtalt iterasjonsgodtgjørelse. Behandle prototypetilgjengelighet og produksjonskvalifisering som separate milepæler.

Definer aksept før den første prototypen

Gjør krav til observerbare tester. I stedet for «gatewayen fungerer», spesifiser grensesnittmodusene, trafikkmønsteret, varigheten, tillatt tap og loggen eller målingen som registrerer resultatet. I stedet for «AI er rask», definer modellen, input, nøyaktighetsterskel, vedvarende gjennomstrømning og akseptabel utgangsforsinkelse.

• Dokumentoppstart, avslutning, gjenoppretting og oppførsel etter en avbrutt oppdatering.
• Tren de nødvendige grensesnittene sammen, i stedet for bare ett om gangen.
• Kjør den tiltenkte arbeidsbelastningen lenge nok til å evaluere den relevante termiske driftstilstanden.
• Verifiser avtalte service- og produksjonstestprosedyrer.
• Hold tavlerevisjonen, fastvaren og programvarebildet vedlagt hvert testresultat.

For mekaniske og kraftmessige hensyn, se vår robust designnotat uten vifte. For en nevrale nettverksarbeidsbelastning, RK3588 NPU testveiledning gir et utgangspunkt for å skille modellytelse fra komplett systemytelse.

Godta overleveringspakken

Spesifiser formatene og rettighetene for skjemaer, PCB layout, produksjonsutganger, stykklister, monteringsinstruksjoner, programvare, programmeringsinstruksjoner og testarmaturer. Definer hvilke redigerbare kilder som leveres, hvilke tredjepartskomponenter som har separate lisenser, og hvem som vedlikeholder designet etter aksept. Dette er prosjektvilkår som skal avtales, ikke forutsetninger som følger automatisk av betaling av NRE.

En nyttig utgivelse registrerer også kjente begrensninger, godkjente erstatninger, uløste risikoer og prosedyren for å be om endringer. Denne informasjonen hjelper produksjons- og serviceteamene med å skille en kontrollert revisjon fra en udokumentert variant.

Egendefinerte bærekort-spørsmål

Kan en referansebærer kopieres uendret?

Det kan være et ingeniørmessig utgangspunkt der lisensen tillater det, men den nye installasjonen trenger fortsatt elektrisk, mekanisk, programvare og produksjonsvalidering. Sjekk at hvert referert design gjelder den eksakte modulen og revisjonen.

Er BSP arbeid inkludert automatisk?

Bare hvis det avtalte omfanget inkluderer det. Oppgi hvem som eier oppstartskonfigurasjon, periferstøtte, operativsystemintegrasjon og langsiktige oppdateringer i prosjektbeskrivelsen.

Hva er nok for en første diskusjon?

Et blokkskjema, modulpreferanse, grensesnittliste, forsyningsdetaljer, kapsling-begrensninger, målmengder og tiltenkt pilotprosjekt-dato er et nyttig utgangspunkt. Ta med det som er uavgjort slik at den første samtalen kan fokusere på disse risikoene.

Koble PCB-design til innebygd Linux oppstart og testing av maskinvare

Tilpasset PCB-design og innebygd systemprogramvare er avhengig av hverandre. En kortstøttepakke (BSP) må samsvare med valgt system-på-modul, strømsekvensering, pinnetildeling og tilknyttede periferiutstyr. Løs disse grensesnittene før layout slik at maskinvare og innebygd Linux oppstart og testing av maskinvare kan fortsette mot samme konfigurasjon.

For et edge AI-produkt, inkludere den tiltenkte kamera- eller sensorbanen i tidlig gjennomførbarhetsarbeid. En fungerende prosessormodul beviser ikke at hele innsamlings- og slutningspipelinen vil møte den nødvendige latensen. Registrer drivertilgjengelighet, minnebehov og testbevis i prosjektbeskrivelsen.

Gjennomgå vifteløse industrielle PC-designbegrensninger