Riepilogo

  • I tassi di scarto della programmazione in campo restano nascosti finché non li si misura.
  • La deriva di configurazione fra unità è invisibile alla consegna e costosa in fase di integrazione.
  • Imporre il firmware firmato è difficile da aggiungere dopo l'avvio della produzione.
  • La registrazione dell'hash del firmware per singola unità è un requisito di prontezza al CRA.

Scarto del flashing in campo

I team che caricano il firmware solo dopo l'uscita dell'unità dalla linea PCBA tendono a sottostimare lo scarto. Un'unità che non accetta il firmware sul banco dell'integratore viene rilavorata, restituita o buttata via, e il costo finisce su un capitolo di bilancio diverso da quello del PCBA.

Quando lo scarto si misura end-to-end, il tasso di scarto del flashing post-produzione si colloca di solito fra l'1 e il 4 percento. Su un lotto da 1000 unità sono dalle 10 alle 40 unità di rilavorazione o perdita che si potevano evitare. Il flashing in produzione porta questo tasso sotto lo 0,5 percento sulla maggior parte delle linee, perché il guasto viene intercettato alla stazione di test e non sul banco dell'integratore.

Drift di configurazione

Le unità flashate in sessioni diverse, con revisioni di firmware diverse, da operatori diversi, scivolano nel tempo verso configurazioni diverse. Valori di calibrazione, impostazioni di rete, flag di debug. Al momento della consegna il drift è invisibile; in fase di integrazione diventa costoso, perché un'unità si comporta in modo diverso da quella successiva.

Con il flashing in produzione ogni unità attraversa la stessa sequenza di flash, con lo stesso hash del firmware, lo stesso template di provisioning e lo stesso bootloader firmato. Il drift di configurazione scende a zero.

Firmware firmato come requisito

Imporre il bootloader firmato a un prodotto già in produzione è un'operazione faticosa. Il burn dei fuse, il passaggio delle chiavi, il ciclo di verifica: tutto va calato a posteriori in un flusso che non era stato pensato per ospitarli.

Progettare la linea di produzione attorno al firmware firmato fin dall'inizio rende invece la cosa banale. Per primo si scrive il bootloader con il riferimento alla chiave di firma, per secondo l'applicazione con verifica dell'hash, per terzo si brucia l'eFuse per bloccare la catena.

Pronti al CRA

Il Cyber Resilience Act presuppone una tracciabilità del firmware per singola unità. Un'unità spedita oggi può aver bisogno di un aggiornamento di sicurezza fra tre anni, e il costruttore deve sapere con quale versione di firmware è uscita dalla fabbrica.

Il flashing in produzione registra l'hash del firmware insieme al numero di serie in un database. Il flashing in campo non produce questo registro, a meno che l'integratore non ne costruisca uno separato, cosa che di norma non avviene.

Quando conviene il flashing in produzione

In linea di massima: ogni prodotto in cui le revisioni del firmware sono abbastanza stabili da poter essere impegnate su un lotto di produzione, e in cui il costo per unità del flashing in campo o del drift di configurazione è misurabile. Per la maggior parte dei prodotti per industria connessa, automazione degli edifici, energia e controllo accessi, questa soglia viene superata già nelle prime fasi della NPI.

Se il firmware cambia ogni settimana durante la NPI, conviene rimandare il flashing in produzione finché bootloader e chiavi di firma non si sono stabilizzati, per poi portarlo in linea.

Fonti

  • Report di settore IPC su collaudo e tassi di flashing in produzione
  • Espressif, documentazione di produzione "Secure Boot v2"
  • NXP, guide di produzione "Secure boot and trust provisioning"

Quotazione unità programmate e serializzate

Se questa ricerca corrisponde alla situazione del vostro prodotto, inviateci i file e definiremo lo scope della produzione.