Sažetak

  • Stope škarta pri upisu firmvera na terenu ostaju skrivene dok ih ne izmerite.
  • Odstupanja u konfiguraciji između jedinica nevidljiva su pri primopredaji, a skupa pri integraciji.
  • Obavezno korišćenje potpisanog firmvera teško je naknadno uvesti nakon početka proizvodnje.
  • Beleženje hash-a firmware-a po jedinici je zahtev za usklađenost sa CRA.

Škart kod terenskog flešovanja

Timovi koji firmware flešuju nakon što jedinica izađe sa PCBA sklapanja često prijavljuju manje škarta nego što ga zaista ima. Jedinica koja na integratorovom stolu ne primi firmware ide na doradu, vraća se ili odlazi na otpad, a trošak se evidentira u drugoj knjizi, ne u PCBA troškovima.

Kada se škart meri od početka do kraja, post-produkciono flešovanje obično daje 1 do 4 procenta škarta. Na seriji od 1000 jedinica to je 10 do 40 jedinica izbežive dorade ili gubitka. Flešovanje u proizvodnji svodi tu stopu ispod 0,5 procenata na većini linija, jer se otkaz hvata na test stanici, a ne kod integratora.

Drift konfiguracije

Jedinice flešovane u različitim sesijama, sa različitim revizijama firmware-a i od strane različitih operatera, počinju da driftaju u konfiguraciji. Kalibracione vrednosti, mrežna podešavanja, debug flag-ovi. Taj drift je nevidljiv pri primopredaji, a skup pri integraciji, kada se jedna jedinica ponaša drugačije od sledeće.

Flešovanje u proizvodnji svaku jedinicu provodi kroz istu sekvencu flešovanja, sa istim hash-om firmware-a, istim provisioning šablonom i istim potpisanim bootloader-om. Drift konfiguracije pada na nulu.

Sprovođenje potpisanog firmware-a

Naknadno uvođenje obavezne primene potpisanog bootloader-a, kada je proizvod već u proizvodnji, bolan je posao. Pregorevanje fuse-a, primopredaja ključeva, ciklus verifikacije, sve to mora da se ugradi u tok koji nije za to bio osmišljen.

Kada se proizvodna linija od početka projektuje oko potpisanog firmware-a, ovo postaje trivijalno. Bootloader se piše prvi, sa referencom na ključ za potpisivanje, aplikacija se piše druga, uz verifikaciju hash-a, a eFuse se pregoreva treći i zaključava lanac.

Spremnost za CRA

Cyber Resilience Act očekuje sledljivost firmware-a po jedinici. Jedinica isporučena danas može tražiti bezbednosno ažuriranje za tri godine, a proizvođač mora znati sa kojom verzijom firmware-a je otišla.

Flešovanje u proizvodnji beleži hash firmware-a uz serijski broj u bazi podataka. Terensko flešovanje takav zapis ne stvara, osim ako ga integrator posebno ne uvede, što obično nije slučaj.

Kada se flešovanje u proizvodnji isplati

Grubo rečeno: svaki proizvod kod kojeg su revizije firmware-a dovoljno stabilne da se može vezati za proizvodnu seriju i kod kojeg je trošak po jedinici od terenskog flešovanja ili drifta konfiguracije merljiv. Za većinu povezanih industrijskih proizvoda, automatizaciju zgrada, energetske uređaje i kontrolu pristupa, taj prag se pređe rano tokom NPI faze.

Kod proizvoda kod kojih se firmware tokom NPI faze menja iz nedelje u nedelju, sačekajte sa flešovanjem u proizvodnji dok se bootloader i ključevi za potpisivanje ne stabilizuju, pa to onda premestite u liniju.

Izvori

  • Izveštaji IPC industrije o produkcionom testiranju i stopama flešovanja
  • Espressif, "Secure Boot v2" produkciona dokumentacija
  • NXP, "Secure boot and trust provisioning" produkcioni vodiči

Zatražite ponudu za programirane i serijalizovane jedinice

Ako se ovo istraživanje poklapa sa situacijom vašeg proizvoda, pošaljite datoteke i odredićemo obim proizvodnje.