Problemi di controllo e validazione del software negli strumenti legali

Luigino Benetazzo - Dipartimento Ingegneria dellinformazione Universit

Degli Studi di Padova

1. Introduzione Considerare la Metrologia legale per il FIRMWARE significa occuparsi sia dellHARDWARE, sia del SOFTWARE residente nellHardware stesso, per questo ultimo nella medesima ottica adottata per la strumentazione usualmente indicata come elettronica. Non pu poi essere trascurata una implicazione aggiuntiva consistente nelle interazioni tra queste due parti (SW-HW), originate con criteri di progettazione ovviamente diversi, ma spesso con specifiche non coerenti tra loro o che perdono coerenza in occasione di revisioni SW, talora frequenti perch riferite a sistemi di sviluppo che evolvono in continuazione. Focalizzando lattenzione sul Software, che pu anche operare su un elaboratore elettronico general purpose esterno allapparecchiatura di misura strettamente intesa, dopo una lunga aspettativa si pu oggi fare riferimento ad un corpus di norme organico (MID software requirements and validation). Su di esso si pu e si deve basare, in primo luogo, la certificazione del SW stesso da intendersi a tutti gli effetti come un prodotto per il quale, pertanto, possibile parlare di qualificazione prima e di conformit poi. Lapproccio pi opportuno sembra inoltre essere quello della

qualit

globale

e,

conseguentemente, di poter disporre di un attestato di conformit rilasciato al produttore da parte di un organismo competente. In questa visione, ed in analogia con le regole che vengono seguite per la strumentazione elettronica (intesa come Hardware), ogni volta che il SW residente in un apparecchiatura viene modificato (da remoto via rete o localmente per manutenzione o aggiornamenti) lapparecchiatura stessa da considerarsi NON TARATA e quindi da assoggettare nuovamente alle procedure di taratura presso un laboratorio accreditato a tal scopo. Inoltre, se con uno strumento tarato in laboratorio si procede ad una misurazione sul campo, cio in condizioni di diversi valori delle grandezze di influenza (temperatura, umidit, ecc..), a
XXIV Congresso GMEE Tavola Rotonda: Esigenze tecniche della metrologia legale: possibili soluzioni

prescindere dalla confidenza dei dati rilevati sul campo, quando si fa ritorno nel laboratorio obbligatorio ricontrollare la taratura dello strumento utilizzato per la taratura sul campo, onde verificare se si mantenuto entro i limiti previsti. Ci vale anche per le eventuali verifiche che si vogliano fare presso le apparecchiature di misura installate sul campo (ad esempio per controllare lerogazione di carburanti) e per le quali sia prevista la tracciabilit dellHw e del SW. Come premessa si pu dire che il SW di cui si parla opportuno che non contenga parametri modificabili run-time che possano inficiare la taratura, cio a dire che parametri di questo tipo devono essere depositati in memorie ROM (a sola lettura), mentre parametri inevitabilmente soggetti ad aggiornamenti possono utilizzare memorie RAM (modificabili in scrittura e leggibili). Per quanto riguarda la sicurezza degli aggiornamenti del SW residente fatti via rete, dovrebbe essere contestualmente attivata una procedura di lettura della firma software del nuovo codice depositato: firme validate da considerare come particolari configurazioni di bit che identificano il prodotto SW e ne garantiscono il corretto funzionamento ( pag.7 della GUIDA per lapplicazione delle direttive MID) e di invio di tale firma al laboratorio SIT , o aziendale accreditato, che funziona da depositario del riferimento (repository) per il confronto-verifica di identit. In caso affermativo, dal Laboratorio deve essere inviato un segnale di validazione avvenuta, che rende nuovamente operativa lapparecchiatura in considerazione messa sempre (precedentemente ed automaticamente) in stand-by allatto dellarrivo-installazione di una versione modificata o totalmente nuova del SW residente.

2. MID: direttive per il software

Con riferimento alle direttive MID, si pu dire che il citato approccio di Qualit Globale trova nelle medesime puntuali riscontri sia for manufacturer sia for notified Bodies (pag.11 della Guida di MID). Il MID copre tutta larea della strumentazione che fa uso di parti software, come momento della catena metrologica in senso stretto e/o per la gestione della procedura di misurazione, in una fondamentale e condivisibile distinzione tra i due casi:

Software residente (built-in measuring instruments), Tipo P, tipico di un prodotto Firmware. Software gestito da una unit elaborativa funzionalmente separata (measuring instruments

using a universal computer),Tipo U.

XXIV Congresso GMEE Tavola Rotonda: Esigenze tecniche della metrologia legale: possibili soluzioni

Nelluno e nellaltro caso (pagg.13-20 e pagg.21-29 della Guida rispettivamente) sono indicate le Descrizioni Tecniche e le Specifiche da rispettare comuni per le classi di rischio B, C, D aggiuntive per la classe E, e

(classi opportunamente definite nelle pagg. 95-97 della Guida),

indicando anche quando alcune sono comuni per tutte le classi da B ad E. Pur sottolineando che tutti i 13 capitoli nei quali si articola la Guida sono rilevanti e vanno presi in considerazione, interessante considerare che le direttive MID coprono anche le problematiche della trasmissione di dati tramite le reti di comunicazione ( pagg. 39-46 della Guida) e quindi quanto va garantito da un lato e verificato dallaltro sulla remotizzazione del software. Anche per questa parte sono indicate le Specifiche da rispettare distinte per Classi di rischio. Il complesso delle direttive MID cui la Guida si riferisce e concernenti il Software coinvolto nella strumentazione di misura, costituisce una Normativa pi che adeguata per la qualificazione di un prodotto software da parte del produttore, per la sua validazione da parte di un Competent Body e, quindi, per una certificazione rilasciata da un Ente a ci preposto, a garanzia dellutente finale. Il fatto pi importante per MID il livello di recepimento da parte della UE e dello Stato Italiano e i conseguenti obblighi per i produttori, adempimenti per i valutatori (competent bodies) e procedure per gli Enti certificatori. Attualmente la normativa MID adottata dellItalia, anche se non ancora adeguatamente utilizzata da tutti gli organismi coinvolti.

3. Monitoraggio e Ispezioni

La realt che ha interesse prendere in considerazione di fatto costituita da un sistema distribuito ( anche a livello di territorio nazionale) di apparecchiature che esplicano contestualmente sia una funzione di fornitura di un bene, sia la misura quantitativa del bene stesso per monetizzarne il valore commerciale addebitandolo al fruitore finale. In particolare interessa monitorare il SW residente sia allatto della prima istallazione per la sua validazione legale, sia ogni qualvolta il SW in questione venga modificato. Questa sorveglianza pu certamente pensarsi attuata localmente su ogni singola

apparecchiatura, ma poich di fatto modifiche e aggiornamenti sono oggi per lo pi realizzati da remoto con trasmissioni su linee cablate o via radio, conviene pensare anche il monitoraggio realizzato da remoto ed esteso a tutto il sistema di apparecchiature, con modalit che consentano
XXIV Congresso GMEE Tavola Rotonda: Esigenze tecniche della metrologia legale: possibili soluzioni

sia una operativit efficiente, sia una garanzia legale per cadenza di ispezioni e per coerenza di confronti con quanto previsto dalla Normativa. Ci premesso, si ritorna a quanto previsto dalle direttive MID in merito alla SIGNATURE KEY, che pu essere simmetrica o asimmetrica ma che usualmente quella di spedizione nota a chi invia, mentre quella di ricezione pubblica per un ambiente ben definito. Sempre MID prevede:

Lutilizzo di un algoritmo (Hash Algorithm) per la generazione di un codice che rappresenta un ben definito blocco di dati (potrebbe essere il programma residente od una sua parte).

Un ulteriore algoritmo di criptografia che utilizzando una apposita chiave rende illeggibile il codice di cui sopra, il quale pu essere letto solo da chi possiede una chiave di decriptazione corrispondente.

Lindividuazione di un Sistema pubblico di chiavi (PKS: Public Key System) che utilizza due chiavi, una segreta ed una pubblica, per verificare la integrit e la autenticit dellinformazione fornita dallalgoritmo di generazione del codice e quindi in ultima analisi del SW che esso rappresenta in forma compressa.

Una

tale

impostazione

rende

realisticamente

fattibile

quanto

succintamente

esposto

nellIntroduzione a proposito di un sistema, pi o meno centralizzato, che attua il ciclo:

lettura della firma, invio al repository di riferimento per la verifica di confronto con quella prevista e relativa allultima taratura,

risposta dal sito di repository di riferimento allapparecchiatura per lo sblocco, o per il mantenimento del blocco stesso in quanto non sia rispettata la taratura,

ciclo che pu essere evidentemente ripetuto con una cadenza ritenuta opportuna per verificare se si sono verificate alterazioni dovute a guasti, interferenze elettromagnetiche, manomissioni, intrusioni. La natura, per cos dire, elettronico-informatica delle parti Firmware consiglierebbe di far riferimento ai competenti organismi di accreditamento per poter fruire di laboratori certificati (SIT o interni allazienda costruttrice della apparecchiatura specie se si adotta il criterio della qualit
XXIV Congresso GMEE Tavola Rotonda: Esigenze tecniche della metrologia legale: possibili soluzioni

globale) sia per le operazioni di taratura, sia per utilizzarli come repository delle firme validate. Poich gli organismi preposti per dare laccreditamento specifico pretendono lentrata in regime di qualit del laboratorio verrebbero, tra laltro, scremati costruttori-produttori poco affidabili (1) Un sistema come quello indicato:

rende possibile parlare di tracciabilit per un prodotto software consente lautomatizzazione delle ispezioni pu essere gestito da un depositario della versione certificata utilizza come depositario (repository) un laboratorio SIT od uno aziendale certificato

responsabilizza il produttore e/o il fornitore-installatore sul mantenimento dei requisiti di qualit globale del prodotto SW a fronte di modifiche e aggiornamenti.

4. Conclusioni

Per alcuni servizi estesi a tutto il territorio nazionale, come la distribuzione di carburanti, o alcuni prodotti periodicamente soggetti a verifica metrologica (bilance) da parte di Ispettori che rispondono alla CCIAA di riferimento, ipotizzabile e senza dubbio realizzabile da un punto di vista tecnico-operativo una funzione di repository presso la stessa CCIAA o presso una unica sede a ci deputata. Capacit e di memorizzazione e potenzialit elaborativa dei moderni sistemi di calcolo, unitamente alla velocit di trasferimento dati delle moderne reti di telecomunicazione, rendono effettivamente possibile una gestione centralizzata delle operazioni ispettive. Ne risulterebbe un elevato grado di garanzia per il consumatore, fruitore finale di servizi o prodotti, ispezionati con cadenze temporali adeguate e modalit spersonalizzate sicure. La stessa applicazione della normativa MID registra significativi ritardi da parte delle autorit competenti ed, in ogni caso, anche se non si pu prescindere da un tempo di transizione per i fornitori. Una iniziativa autonoma, connotata dalle considerazioni svolte, da parte delle organizzazioni imprenditoriali o di organismi come le CCIAA avrebbe il merito di imprimere una accelerazione a questo approccio di considerare il Software come un prodotto, doverosamente soggetto a criteri di metrologia legale a garanzia del consumatore finale in una variet di contesti molto significativa.
XXIV Congresso GMEE Tavola Rotonda: Esigenze tecniche della metrologia legale: possibili soluzioni