Rebutul flashing-ului în teren
Echipele care încarcă firmware-ul abia după ce unitatea iese din linia PCBA tind să subraporteze rebutul. O unitate care nu acceptă firmware-ul pe bancul integratorului ajunge să fie relucrată, returnată sau aruncată, iar costul cade pe un alt cont decât cel al PCBA-ului.
Când rebutul se măsoară end-to-end, rata rebutului la flashing-ul post-producție se situează de obicei între 1 și 4 procente. La un lot de 1000 de unități, înseamnă între 10 și 40 de unități de rebut sau relucrare evitabile. Flashing-ul făcut în producție coboară această rată sub 0,5 procente pe majoritatea liniilor, pentru că defectul este prins la stația de test, nu la integrator.
Drift de configurație
Unitățile flashate în sesiuni diferite, cu revizii diferite de firmware, de operatori diferiți, alunecă în timp către configurații diferite. Valori de calibrare, setări de rețea, flag-uri de debug. La predare drift-ul este invizibil, iar la integrare devine costisitor, când o unitate se comportă altfel decât următoarea.
Flashing-ul în producție trece fiecare unitate prin aceeași secvență de flash, cu același hash al firmware-ului, același template de provisioning și același bootloader semnat. Drift-ul de configurație scade la zero.
Firmware semnat ca cerință
A impune un bootloader semnat unui produs care este deja în producție este o operațiune anevoioasă. Arderea fuse-urilor, predarea cheilor, ciclul de verificare, toate trebuie adăugate ulterior pe un flux care nu a fost gândit pentru ele.
Gândirea liniei de producție de la bun început în jurul firmware-ului semnat transformă lucrurile într-o banalitate. Mai întâi se scrie bootloader-ul cu referința la cheia de semnare, apoi aplicația cu verificarea hash-ului, iar la final se arde eFuse-ul pentru a bloca lanțul.
Pregătirea pentru CRA
Cyber Resilience Act presupune trasabilitatea firmware-ului pe fiecare unitate. O unitate expediată azi poate avea nevoie de o actualizare de securitate peste trei ani, iar producătorul trebuie să știe cu ce versiune de firmware a ieșit din fabrică.
Flashing-ul în producție înregistrează hash-ul firmware-ului împreună cu numărul de serie într-o bază de date. Flashing-ul în teren nu produce un astfel de registru, decât dacă integratorul construiește unul separat, ceea ce de obicei nu se întâmplă.
Când merită flashing-ul în producție
În linii mari: orice produs la care reviziile firmware-ului sunt suficient de stabile cât să poată fi angajate pe un lot de producție și la care costul pe unitate al flashing-ului în teren sau al drift-ului de configurație este măsurabil. Pentru majoritatea produselor de industrial conectat, automatizare a clădirilor, energie și control acces, acest prag se atinge încă din fazele timpurii ale NPI.
Pentru produsele la care firmware-ul se schimbă săptămânal în timpul NPI, este mai bine să amânați flashing-ul în producție până când bootloader-ul și cheile de semnare se stabilizează, iar apoi să îl mutați în linie.
Surse
- Rapoarte de industrie IPC privind testul de producție și ratele de flashing
- Espressif, documentația de producție "Secure Boot v2"
- NXP, ghidurile de producție "Secure boot and trust provisioning"