L’architettura firmware di un contatore: quattro livelli di customizzazione, una sola parola usata per tutti

Un OEM sta valutando tre fornitori per un contatore custom. Tutti e tre dichiarano «firmware customizzabile» sulla scheda commerciale. Sei mesi dopo, su tre progetti distinti, le tre customizzazioni si rivelano cose completamente diverse.

Con il primo fornitore, customizzazione significa: il cliente apre un tool di configurazione, rinomina le etichette dei registri Modbus, abilita o disabilita alcune misure derivate, esporta un file di profilo. Il firmware non viene mai modificato. Quello che cambia è solo l’inizializzazione.

Con il secondo, customizzazione significa: il fornitore prende il proprio codice base, ne crea un fork dedicato, modifica la struttura della tabella dei registri o la logica di un algoritmo. Il binario è ricompilato, i test interni rifatti, la certificazione MID resta valida o decade a seconda di cosa è stato toccato.

Con il terzo, customizzazione significa: il cliente e il fornitore lavorano in parallelo sull’architettura firmware del contatore, non sull’applicazione, ma sull’architettura. Il fornitore mantiene il controllo del nucleo metrologico, il cliente concorre alla definizione degli strati superiori. La roadmap è condivisa. La rinotificazione MID è pianificata in anticipo, non subita.

Tre offerte commercialmente diverse, tre tecnicamente diverse, tre rivolte a OEM con esigenze diverse. Una sola parola per descriverle tutte.

Per un OEM che sta scrivendo specifiche, capire dove un fornitore si colloca su questo spettro è una decisione strategica. Per un fornitore che vuole posizionarsi seriamente nel mercato OEM, distinguere chiaramente le tre offerte è una decisione di mestiere.

L’architettura: nucleo metrologico e strato applicativo

Il firmware di un contatore di energia conforme MID si divide architetturalmente in due parti, separate da un confine che la direttiva impone esplicitamente.

Il nucleo metrologico è il blocco di codice che esegue le funzioni soggette a verifica metrologica: campionamento dell’ADC, calcolo di potenza attiva e reattiva, integrazione di energia, gestione degli accumulatori sigillati, generazione del valore certificato. Questo blocco è oggetto della certificazione MID e firmato digitalmente. La sua firma è verificata all’avvio e periodicamente a runtime. Qualsiasi modifica, anche una singola riga, invalida la firma e richiede una nuova procedura di valutazione di conformità.

Lo strato applicativo è tutto ciò che il nucleo metrologico non tocca: gestione della comunicazione, protocollo di comunicazione, struttura della tabella dei registri, allarmi e soglie, log eventi non metrologici, calcoli derivati (THD, fattore di potenza presentato all’utente, statistiche), interfaccia di configurazione, gestione del display.

La separazione fra questi due strati non è una buona pratica progettuale. È un requisito normativo. WELMEC Guide 7.2, il riferimento europeo per il software di strumenti di misura legali, prescrive esplicitamente l’isolamento del software metrologicamente rilevante da quello che non lo è.

Capire dove cade questo confine è il primo passo per capire cosa è davvero customizzabile.

I quattro livelli

Sul mercato OEM, «firmware customizzabile» copre quattro livelli di intervento, in ordine crescente di profondità e di impatto regolatorio.

• Livello 1 — Configurazione.
  Tutto ciò che il firmware permette di modificare a runtime, attraverso un tool di configurazione o un protocollo di parametrizzazione. Tipicamente: indirizzo Modbus, baud rate, tariffe, soglie di allarme, etichette dei registri, abilitazione/disabilitazione di funzioni opzionali. Non richiede ricompilazione, non richiede nuova certificazione, è disponibile su qualsiasi prodotto serio. Quando un fornitore chiama questo livello «customizzazione», sta vendendo configurabilità di prodotto come fosse un servizio.
• Livello 2 — Mappatura applicativa.
  Modifica della tabella dei registri di comunicazione, dell’ordinamento delle misure, del formato dei dati esposti, dell’interfaccia di rete. È intervento sullo strato applicativo: il binario applicativo viene ricompilato, ma il nucleo metrologico resta intatto e la firma metrologica resta valida.È il livello a cui si colloca la maggioranza dei progetti «OEM customizzati» sul mercato, ed è sufficiente per la maggior parte dei casi d’uso.
• Livello 3 — Customizzazione applicativa profonda.
  Aggiunta di logiche di calcolo non metrologiche, allarmi compositi, integrazione di sensori esterni, gestione di protocolli proprietari, comportamenti event-driven custom. Resta nello strato applicativo, ma richiede sviluppo dedicato, validazione funzionale, eventualmente test di compatibilità EMC se l’hardware viene toccato. La firma metrologica resta valida, ma la documentazione di prodotto e i test funzionali devono essere riemessi.
• Livello 4 — Co-engineering metrologico.
  Intervento nel nucleo metrologico: cambio della finestra di calcolo per applicazioni DC, aggiunta di una funzione di misura non prevista nello standard di partenza, integrazione di un nuovo sensore primario, modifica della procedura di sealing. È il territorio dei progetti veramente strategici, dove l’OEM non sta acquistando un contatore: sta sviluppandolo.

Un fornitore serio nomina esplicitamente in offerta a quale dei quattro livelli si riferisce. Un fornitore che usa «customizzazione» come termine generico copre l’ambiguità con la parola.

Cosa non si può toccare, e perché è una caratteristica

Un OEM esperto a volte chiede di intervenire nel nucleo metrologico per ragioni che dal suo punto di vista sono legittime: ottimizzare la latenza, aggiungere un canale di misura, modificare la finestra di mediazione.

Il nucleo metrologico è blindato per ragioni che proteggono in primo luogo il cliente OEM. La firma digitale e l’integrità del codice sono ciò che rende il valore esportato dal contatore valido legalmente per fatturazione. Un nucleo «facilmente modificabile» è un nucleo che non garantisce le caratterstiche metrologiche del contatore.

Tracciabilità: la catena che lega codice e certificazione

Un firmware certificato MID non è solo un binario funzionante. È una catena di tracciabilità che collega:

• il codice sorgente (versione, repository, hash di commit);
• il toolchain di compilazione (compiler, versione, flag, librerie);
• il binario prodotto (firma digitale, hash crittografico);
• il rapporto di test del Notified Body;
• il certificato MID emesso.

Ogni anello della catena deve essere ricostruibile per l’intera vita del prodotto. Se fra cinque anni un’autorità di vigilanza chiede di verificare che il binario in campo corrisponde al codice certificato, il fornitore deve poter ricompilare bit per bit lo stesso binario partendo dal sorgente archiviato. Reproducible build non è un nice-to-have: è un requisito di prassi metrologica.

Per un OEM, questo significa che la qualità del partner firmware non si misura solo sulla qualità del codice oggi, ma sulla solidità dei processi che lo manterranno tracciabile per dieci anni.

Cosa significa per un OEM

La domanda da porre a un fornitore non è «il vostro firmware è customizzabile». È: «la modifica che chiediamo a quale livello ricade, configurazione, applicazione superficiale, applicazione profonda, nucleo metrologico, e per quanto tempo sarà mantenuto?»

Un fornitore che risponde con la stessa struttura, livello, tempi, certificazione, proprietà, lifecycle, ha un processo di sviluppo OEM maturo. Un fornitore che risponde «vediamo, parliamo, troviamo una soluzione» sta vendendo flessibilità verbale al posto di disciplina ingegneristica.

La parola «customizzazione» da sola non basta più a distinguere un fornitore dall’altro. È diventata un commodity linguistico. Quello che distingue è il rigore con cui un fornitore traccia il confine fra ciò che si può modificare nel firmware di un contatore e ciò che, per ragioni metrologiche, deve restare blindato.

Quel confine non è dove finisce la disponibilità commerciale. È dove inizia la responsabilità tecnica.