Sammendrag

  • Kassasjonsraten ved flashing i felt er skjult inntil du måler den.
  • Konfigurasjonsdrift mellom enheter er usynlig ved overlevering og kostbar ved integrasjon.
  • Håndheving av signert firmware er vanskelig å legge til etter at produksjonen er startet.
  • Logging av firmware-hash per enhet er et krav for CRA-beredskap.

Skrap ved flashing i felt

Team som flasher fastvare etter at enheten har forlatt PCBA-monteringen, underrapporterer ofte skrap. En enhet som ikke tar imot fastvare på integratorens benk, blir omarbeidet, returnert eller kastet, og kostnaden havner i et annet regnskap enn PCBA-kostnaden.

Måler man skrap fra ende til ende, ligger flashing-skrap etter produksjon vanligvis på 1 til 4 prosent. På en batch med 1000 enheter blir det 10 til 40 enheter med omarbeid eller tap som kunne vært unngått. Flashing på produksjonssiden presser denne raten under 0,5 prosent på de fleste linjer, fordi feilen oppdages på teststasjonen, ikke hos integratoren.

Konfigurasjonsdrift

Enheter som flashes i ulike sesjoner, med ulike fastvareversjoner og av ulike operatører, driver fra hverandre i konfigurasjon. Kalibreringsverdier, nettverksinnstillinger, debug-flagg. Driften er usynlig ved overlevering og kostbar ved integrasjon, når én enhet plutselig oppfører seg annerledes enn den neste.

Flashing på produksjonssiden sender hver enhet gjennom samme flashesekvens, med samme fastvarehash, samme provisjoneringsmal og samme signerte bootloader. Konfigurasjonsdriften faller til null.

Håndheving av signert fastvare

Å ettermontere håndheving av signert bootloader når produktet allerede er i produksjon, er smertefullt. Brenningen av fuser, overleveringen av nøkler, verifiseringssyklusen – alt må monteres på en flyt som ikke var laget for det.

Dersom produksjonslinjen er designet rundt signert fastvare fra starten, blir dette enkelt. Bootloaderen skrives først med referanse til signeringsnøkkelen, applikasjonen skrives deretter med hash-verifisering, og eFusen brennes til slutt for å låse kjeden.

CRA-beredskap

Cyber Resilience Act forventer sporbarhet på fastvare per enhet. En enhet som sendes ut i dag, kan trenge en sikkerhetsoppdatering om tre år, og produsenten må vite hvilken fastvareversjon den ble levert med.

Flashing på produksjonssiden logger fastvarehashen mot serienummeret i en database. Flashing i felt produserer ikke en slik logg, med mindre integratoren bygger en separat, noe de som regel ikke gjør.

Når flashing på produksjonssiden lønner seg

Grovt sagt: i alle produkter der fastvareversjonene er stabile nok til å låses til en produksjonsbatch, og der enhetskostnaden ved flashing i felt eller konfigurasjonsdrift kan måles. For de fleste produkter innen tilkoblet industri, bygningsautomasjon, energi og adgangskontroll, passerer terskelen tidlig i NPI.

For produkter der fastvaren endres ukentlig gjennom NPI, vent med produksjonsside-flashing til bootloaderen og signeringsnøklene har satt seg, og legg det så inn på linjen.

Kilder

  • IPC-bransjerapporter om produksjonstest og flashing-rater
  • Espressif, produksjonsdokumentasjon for "Secure Boot v2"
  • NXP, produksjonsveiledninger for "Secure boot and trust provisioning"

Be om tilbud på programmerte og serialiserte enheter

Hvis denne forskningen passer din produktsituasjon, send filer så skoper vi produksjonen.