Aggiornamento software via radio dei gruppi di misura

MeterLinq srl
Nota Tecnica 06-14
Aggiornamento software via radio dei gruppi di misura del gas
classe A2 (G4)
Rev. 1.0
Aggiornamento software via radio dei gruppi di misura del gas
classe A2 (G4)
Introduzione
Una delle principali differenze tra un contatore ed uno smart meter è la presenza di software
(firmware) a bordo dell'apparato. Nel caso dello smart meter il software svolge una serie di funzioni
che vanno dalla gestione della componente metrologia a quella delle diverse interfacce di
comunicazione possibili.
In Italia, nei contatori di classe A2 (G4) è prevista la presenza di una porta locale per l'installazione
e manutenzione, ma l'interfaccia probabilmente più utilizzata per la comunicazione dei dati di
lettura e per il colloquio con il sistema di gestione è quella radio.
La normativa UNI TS 11291 [1] stabilisce per la classe A2 di contatori una interfaccia radio a 169
MHz, denominata PM1, in cui il livello di trasporto delle informazioni impiega il protocollo
wireless MBUS in modalità N (Narrowband) descritto nella [2], per realizzare una infrastruttura
radio con architettura punto-multi punto [3].
Da un punto di vista applicativo, nella architettura proposta dalla normativa il gruppo di misura
dialoga direttamente con il sistema di gestione (SAC), utilizzando in questo caso un protocollo
applicativo standard quale il DLMS/COSEM.
Questo protocollo è già in uso in diverse applicazioni di metering, ma nel caso particolare del gas il
suo impiego è previsto prevalentemente via radio.
In pratica il DLMS/COSEM viene “imbustato” all'interno del payload di una trama wireless MBUS
come rappresentato in figura 1.
DLMS/COSEM
DLMS/COSEM
SAC
(client)
Application
Payload
Header
DLMS/COSEM
DLMS/COSEM
w-MBUS
w-MBUS
Meter
(server)
Payload
Infrastructure
Header
Figura 1: Architettura applicativa DLMS/COSEM
Il DLMS/COSEM è stato originariamente previsto per un impiego su un mezzo trasmissivo filare
(come per esempio Power Line Communication o PLC) non ha paticolari facilitazioni per l'utilizzo
Pagina 1
con un trasporto radio e su apparati alimentati unicamente a batteria come i contatori del gas.
Per questo motivo la normativa italiana ha introdotto una serie di ottimizzazioni nel
DLMS/COSEM [4] volte a migliorare il rendimento del protocollo in presenza dei limiti imposti
dalla infrastruttura di smart metering del gas.
Tra le aggiunte apportate nella normativa al DLMS/COSEM, la novità più rilevante ed importante
sono sicuramente le trame compatte (compact frames).
Si tratta di un meccanismo basato su un dizionario convenzionale, basato sul numero di trama per
l'identificazione del contenuto della stessa, e che descrive il formato dei dati in modo sintetico
rispetto allo stesso messaggio spedito con una trama convenzionale.
In pratica il contenuto del messaggio in termini di tipologia dei dati e del loro valore è
predeterminato indicando il numero della trama compatta, evitando di includere nel messaggio,
come avviene normalmente, tutte le informazioni necessarie ad interpretarne il contenuto.
Questa “compressione” consente una riduzione sensibile del numero di bytes (ottetti) trasmessi e di
conseguenza un tempo di trasmissione e ricezione inferiore e una riduzione del consumo energetico.
Il risparmio complessivo ottenuto con l'introduzione dei compact frames può arrivare a percentuali
notevoli; mediamente il risparmio può variare complessivamente tra il 20% ed il 30% rispetto ai
frames standard DLMS/COSEM, e pertanto l'uso dei compact frames consente l'utilizzo del
DLMS/COSEM anche con una infrastruttura radio alimentata a batterie.
La normativa UNI TS 11291 è di recentissima introduzione (2013-2014) e contiene numerose
innovazioni studiate per il roll-out dello smart metering su una popolazione di milioni di contatori
residenziali. A causa della sua complessità e ed in mancanza di riferimenti “de facto”,
l'implementazione della normativa richiede un elevato grado di flessibilità da parte di tutti i
componenti della infrastruttura di smart metering, ed in particolar modo dei gruppi di misura.
Tale flessibilità è normata e descritta in [3][4][5], introduce la funzionalità obbligatoria per il
gruppo di misura dell'aggiornamento del software “over the air” sfruttando l'infrastruttura radio
esistente e prevedendo quindi la possibilità da parte del sistema di gestione di inviare al gruppo di
misura uno o più aggiornamenti nel corso della vita utile del contatore.
L'upgrade firmware previsto dalla norma [8] rende possibile aggiornare il software di bordo e
apportare modifiche di tipo funzionale (estendendo per esempio le funzioni dello smart meter), o
per la correzione di eventuali problemi legati anche alla normativa sulla intercambiabilità dei gruppi
di misura.
Il meccanismo di aggiornamento
L'attività di aggiornamento del firmware di uno o più gruppi di misura è descritto come caso d'uso
nella normativa [4][8]1. Questa attività è molto particolare e dovrebbe essere eseguita raramente a
causa delle ripercussioni nella funzionalità del misuratore, e in misura minore a causa dell'elevato
costo energetico rispetto alla normale operatività.
La complessità dell'aggiornamento del firmware è legata anche all'utilizzo di tutta l'infrastruttura di
rete in modalità punto-multi punto, ed in particolare con la necessità di organizzare il lavoro
1
Nella normativa il processo viene indicato come download, anche se tecnicamente si dovrebbe parlare di upload,
dal momento che il nuovo firmware viene trasmesso dal client DLMS/COSEM al server e non scaricato attivamente
dal server.
Pagina 2
coinvolgendo, oltre al contatore, anche il gateway/concentratore, e il sistema di gestione (SAC).
Il processo di aggiornamento di un contatore di classe A2 può essere riassunto in alcuni passi
principali:
1) Per prima cosa il sistema di gestione deve ottenere una immagine aggiornata del software del
gruppo di misura da parte del produttore. Le modalità di consegna dal produttore al gestore sono
definite attraverso una serie di messaggi definiti dalla normativa. Dal momento che la dimensione
di una trama inviata via radio al gruppo di misura ha dei limiti di dimensione (pari a 229 bytes per il
frame B del wireless MBUS), il sistema di gestione dovrà suddividere il firmware ricevuto in una
serie di elementi, detti blocchi, che verranno trasferiti singolarmente al gruppo di misura.
Firmware Image
Raw Blocks
Messages
Block 1
DLMS/COSEM 1
Block 2
DLMS/COSEM 2
Block 3
DLMS/COSEM 3
Block 4
DLMS/COSEM 4
Block N
DLMS/COSEM N
Figura 2: Suddivisione firmware in blocchi
2) Il sistema di gestione definisce una finestra temporale periodica durante la quale il gruppo di
misura entra in una modalità di ricezione (ascolto) dei messaggi di manutenzione. In questa fase il
SAC può inviare attraverso i gateways uno o più messaggi al gruppo di misura senza attendere il
risveglio di quest'ultimo per la normale attività di trasmissione (push) delle misure [5].
3) Le chiavi di cifratura del contatore interessato all'aggiornamento firmware vengono cambiate. In
questa fase le quattro chiavi di cifratura (dimensione 16 bytes) richiesta dalla gestione della
sicurezza [6] possono essere inserite dal client (SAC) in un solo messaggio DLMS/COSEM di tipo
unicast.
4) I gateway/concentratori ai quali i gruppi di misura sono affiliati ricevono i blocchi di firmware da
aggiornare, e si predispongono per la trasmissione in broadcast dei dati ricevuti verso i contatori.
5) Il client (SAC) invia al server (contatore) un messaggio DLMS/COSEM per l'impostazione
Pagina 3
relativa al trasferimento dell'immagine firmware al gruppo di misura; vengono impostate le
informazioni sulla finestra di manutenzione e di abilitazione al trasferimento dell'immagine
firmware. Questo messaggio è inviato sotto forma di trama compatta (Compact Frame 12 – FW
Update Setup) di tipo SET unicast.
6) Il client invia al server un messaggio DLMS/COSEM che segnala l'inizio della attività di
trasferimento dell'immagine firmware (ACTION image_transfer_initiate) di tipo unicast.
7) Il client invia al server una serie di messaggi DLMS/COSEM contenenti i singoli blocchi
dell'immagine firmware (ACTION image_block_transfer_data) di tipo broadcast. La
modalità di trasmissione effettiva è legata ad una serie di fattori esterni normalmente gestiti dal
gateway/concentratore. Di questi, il più importante probabilmente è legato alla sincronizzazione
degli orologi dei contatori con quelli del gateway che si occupa della consegna dei dati. Pur essendo
prevista dalla normativa una tolleranza di alcuni secondi, la sincronizzazione evita l'impegno della
frequenza di trasmissione oltre il necessario.
8) Per controllare lo stato dell'aggiornamento del firmware, il client può inviare al server un
messaggio specifico che richiede lo stato del trasferimento, Questo messaggio DLMS/COSEM può
essere un GET del compact frame 13 (FW Transfer Status), oppure del compact frame 22
(FW DLMS Transfer Status), i quali ritornano lo stato dell'aggiornamento dal punto di vista
del contatore. Questa attività può essere svolta ad ogni finestra di manutenzione da parte del SAC
per creare una mappa dei blocchi da trasferire, evitando quindi ripetizioni costose dal punto di vista
energetico.
9) Una volta terminato il trasferimento del firmware, il client può opzionalmente inviare un
ulteriore messaggio DLMS/COSEM al server di tipo GET image_to_activate_info,
unicast, che consente di verificare se la versione corrente del firmware del contatore è quella
trasferita, oppure se ci sono stati errori nel trasferimento e la versione è rimasta quella precedente 2.
Tramite questo messaggio, il SAC può verificare la versione e la firma digitale del firmware e
quindi segnalare eventuali anomalie al gestore del sistema.
2
Ovviamente esiste un terzo caso nel quale lo smart meter, in seguito ad errori nel trasferimento del firmware e alla
valutazione della congruenza della nuova immagine, perda le funzioni di comunicazione e si trasformi in un costoso
contatore tradizionale (brick).
Pagina 4
Valutazione dell'efficienza del processo
Il trasferimento di un nuovo firmware al gruppo di misura via radio è un processo che può avere
aspetti rilevanti dal punto di vista energetico, ma soprattutto dal punto di vista logistico
organizzativo. Per apprezzare il problema, è necessario fare alcune considerazioni.
Nota: per seguire meglio quanto descritto nei prossimi paragrafi, può risultare
utile consultare il codice sorgente della libreria libUNICosem di MeterLinq che
implementa il protocollo DLMS/COSEM per lo smart metering del gas.
Per ulteriori informazioni: http://www.meterlinq.com
Come segnalato in precedenza, pur essendo la dimensione massima di una trama completa di tipo B
wireless MBUS di dimensioni pari a 256 bytes [5], la dimensione complessiva disponibile nel
payload è di 229 bytes una volta sottratta la porzione invariante di header del protocollo.
Dalla figura 1 possiamo vedere che il DLMS/COSEM è incapsulato all'interno dei 229 bytes
disponibili nel payload del w-MBUS.
I messaggi DLMS/COSEM possiedono una porzione fissa descrittiva del messaggio stesso
(header); nel caso di messaggi di tipo ACTION, come quelli usati nel trasferimento del firmware, la
parte fissa è costituita da
• un wrapper della dimensione di 2 bytes e utilizzato per descrivere il tipo di trasporto DLMS
(in questo caso specifica il w-MBUS),
• un descrittore di sicurezza COSEM della dimensione di 8 bytes,
• un header del blocco dati del protocollo (APDU) della dimensione di 3 bytes,
• un oggetto COSEM con il descrittore del metodo della dimensione di 9 bytes.
La somma delle componenti fisse del messaggio COSEM sottrae 2+8+3+9, ovvero 22 bytes,
lasciando disponibili quindi 229 - 8 = 207 bytes.
A questi devono essere ulteriormente sottratti 8 bytes del tag di autenticazione COSEM, portando il
bilancio a 207 – 8 = 199 bytes disponibili al trasferimento di un blocco.
Il blocco non viene però trasferito semplicemente come gruppo di bytes all'interno del messaggio
COSEM, ma viene trasmesso come struttura dati[9], che possiede una propria descrizione
(SEQUENCE OF DATA) consistente in un identificativo del tipo della struttura della dimensione
di 1 byte,
• un contatore del numero di elementi della struttura della dimensione di 1 byte,
• un tag di identificazione del tipo di dato della struttura (data type tag) della dimensione di 1
byte,
• un campo che definisce la dimensione del blocco (image size) della dimensione di 4 bytes,
• un campo che definisce il tipo di dati contenuto nella struttura (octet stream tag) della
dimensione di 1 byte,
• un campo che definisce la lunghezza del blocco di dati contenuto nella struttura (length)
della dimensione di 2 bytes.
In pratica il descrittore della struttura sottrae altri 10 bytes alla dimensione utile del blocco di
immagine firmware trasferibile, portandolo alla dimensione finale di 189 bytes.
Nel caso (peggiorativo) di trasmissione e ricezione nel canale 2a o 2b dello standard w-MBUS, la
Pagina 5
velocità di trasferimento e di 2.4 kbps, ovvero circa 2458 bit per secondo.
Quindi un frame w-MBUS di tipo B completo (256 bytes, ovvero 2048 bit) richiede circa 804
millisecondi di tempo di trasmissione.
Il tempo si dimezza nel caso di utilizzo dei canali 1a, 1b, 3a e 3b che supportano una velocità di
trasferimento di 4915 bit per secondo, ma per mantenere un margine di sicurezza è utile modellare
il processo sui canali più lenti.
Supponendo quindi di avere un firmware del contatore della dimensione di 50 KB, ovvero 51.200
bytes, per il trasferimento di tutta l'immagine saranno necessari circa 271 blocchi.
Nel caso di trasmissione sui canali 2a o 2b questo implica, solo per il trasferimento dei blocchi
componenti l'immagine, un tempo complessivo di circa 220 secondi di ricezione, ai quali vanno
sommati i tempi di attività per l'effettiva elaborazione dell'immagine da parte del micro-controllore
utilizzato dall'elettronica dello smart meter.
Considerato che la normativa prevede un livello di servizio (SLA) per questa attività pari a 2 volte
nella vita utile del contatore [3], l'aggiornamento comporterebbe, considerando anche i consumi
relativi alle operazioni collaterali sulla scheda del contatore, complessivamente circa 440 secondi di
ricezione e conseguente budget energetico.
Nella pratica, il calcolo dell'impegno energetico ha come fattore principale la durata e la frequenza
della finestra di manutenzione ed il rispetto della normativa vigente per quanto concerne l'utilizzo
della radio frequenza.
Il duty cycle per i dispositivi "Meter Reading" operanti nella banda 169.4-169.475 Mhz è del 10%,
come definito nella norma [10], al paragrafo 7.2.3.
Il duty cycle è calcolato su base oraria. Sono quindi disponibili, per ogni ora di funzionamento, 360
secondi in cui un dispositivo può essere in stato di trasmissione.
La raccomandazione [11] REC 70-03 fornisce inoltre indicazioni sull'opportuna distribuzione del
tempo di trasmissione, in modo da facilitare la coesistenza di diversi dispositivi trasmittenti. La
raccomandazione richiede una spaziatura tra gli intervalli di trasmissione pari al 10% del tempo
complessivo di trasmissione, per cui, nella situazione della tele-gestione e telelettura del gas a 169
MHz, la trasmissione dovrebbe avvenire per 10 blocchi di durata massima pari a 36 secondi
intervallati, da un periodo di “silenzio” pari a un minimo di 3,6 secondi.
Tendo conto quindi dei limiti e delle raccomandazioni ETSI e delle raccomandazioni ECC, il
calcolo della dimensione ottimale della finestra di manutenzione comporta valori più elevati di
quelli teorici.
Da un punto di vista dell'impatto energetico sul contatore, l'aggiornamento tramite l'interfaccia PM1
non presenta però caratteristiche tali da renderlo problematico.
Pagina 6
Assumendo un modulo di comunicazione dello smart meter sviluppato in modo simile allo schema
in figura 3, possiamo calcolare approssimativamente il fabbisogno energetico della trasmissione e
ricezione.
Power On/Off
3.6v
DC/DC
3.3v
Metrology
μC
+
-
Super
cap
Radio
Figura 3: Schema modulo di comunicazione smart meter
Lo schema descrive a grandi linee il reference design MeterLinq usato anche per il
gateway/concentratore, con opportuni adattamenti per l'implementazione in un contatore; la
sorgente di alimentazione è una tipica batteria al cloruro di tionile (Li-SOCl 2) associata ad un super
capacitore ed un regolatore DC-DC che alimenta un micro-controllore ed un transceiver radio a 169
MHz3.
Il modulo è collegato alla componente metrologica per mezzo di una interfaccia seriale e può essere
acceso e spento o messo in stand-by in modo da conservare energia.
Per quanto riguarda la condizione di esercizio del contatore, possiamo ipotizzare un consumo in
trasmissione di circa 365 mA da parte del transceiver radio completo di amplificatore di potenza e
del micro controllore, ed un consumo in ricezione pari a 15 mA.
Nella gestione ordinaria, il lavoro principale dal punto di vista della comunicazione è la
trasmissione in “push” delle misure al SAC.
Dato che il messaggio DLMS/COSEM in push ha una dimensione media di 128 bytes, utilizzando i
canali “lenti” del w-MBUS la trasmissione richiede circa 400 ms.
Eseguendo 3 push al giorno verso il SAC, il tempo di trasmissione totale è di circa 1,2 s al giorno,
equivalenti a meno di 3600 s (un'ora) in 8 anni, che corrispondono, secondo i dati di consumo
ipotizzati, a 0,365 Ah.
In fase di aggiornamento del firmware, supponiamo di configurare finestre di manutenzione di 3,5
minuti per 4 volte al giorno e per un periodo di 7 giorni. In questo modo è possibile soddisfare
anche requisiti e raccomandazioni per il duty cycle.
3
Nel design MeterLinq si tratta di una combinazione del micro controllore ST Microelectronics STM32L0 e del
transceiver ST Micro Spirit1. Nello schema non è incluso l'amplificatore (PA) che in una implementazione reale è
invece presente, ma i consumi sono stati calcolati considerando anche il PA.
Pagina 7
Arrotondando quindi la somma dei tempi della finestra di manutenzione a 15 minuti, si ha che un
aggiornamento potrebbe richiedere complessivamente (e nel peggiore dei casi) 105 minuti di tempo
di ricezione da parte del contatore.
Con un consumo in ricezione pari a 15 mA, la sola attività di ricezione durante il periodo della
finestra di manutenzione (una settimana), si ottiene un valore di 0,03 Ah per aggiornamento.
Nel calcolo dei consumi devono essere considerati anche altri messaggi in downlink dal gateway al
contatore, come quelli relativi alla sincronizzazione dell'orologio.
Inoltre, nella procedura di aggiornamento firmware il contatore deve anche trasmettere al SAC dei
messaggi che richiedono una conferma, assumendo nel peggiore dei casi la necessità da parte del
contatore di ri-trasmettere fino a 6 volte i propri messaggi [5] a causa di problemi di comunicazione
con il gateway/concentratore.
Un ruolo importante nella gestione energetica è giocato anche dall'efficienza del convertitore
DC-DC, che nella nostra ipotesi4 assumiamo pari al 75%.
E' possibile quindi stimare questi ulteriore consumi e sommarli a quelli precedenti portando il totale
a circa 1.8 mAh al mese, per cui si ottiene un totale di poco superiore ad 1 Ah in un periodo di 8
anni.
Considerando l'utilizzo di una batteria per applicazioni di smart metering con una capacità nominale
di 17 Ah5, è facilmente sostenibile che la riserva di energia sia più che sufficiente per tutta
l'aspettativa di vita del contatore, consentendo un numero anche più elevato di aggiornamenti
firmware rispetto a quelli previsti dalla normativa.
4
5
Come Analog Devices ADP2504
Per esempio Saft LS 33600
Pagina 8
Possibili ottimizzazioni e libPatch
L'impatto di un aggiornamento firmware sulla carica della batteria è non trascurabile, considerando
le aspettative di vita dello smart meter, ma non è il solo problema che si pone il gestore della rete
radio. Le considerazioni precedenti non tengono conto di eventuali problemi di ricezione da parte
dello smart meter, che richiederebbero quindi ri-trasmissioni di uno o più blocchi, o in alcuni casi la
ripetizione completa della procedura.
Se dal punto di vista dei consumi di energia l'aggiornamento potrebbe non essere un vero problema,
il mantenimento dello SLA previsto dalla normativa e soprattutto la garanzia della funzionalità dei
contatori in seguito ad aggiornamento firmware rappresentano un problema molto più insidioso.
In una situazione reale di utilizzo della rete in architettura punto-multi punto devono essere presi in
considerazione, oltre all'effettiva dimensione del firmware da aggiornare e dell'overhead imposto
dai protocolli applicativi e di trasporto, anche possibili fluttuazioni nella disponibilità e copertura
radio, per cui il processo di aggiornamento dovrà essere dotato dei meccanismi di controllo previsti
dalla normativa e di un certo livello di ridondanza per poter garantire un completo rilascio a tutto il
parco di misuratori coinvolti.
Inoltre, in una fase iniziale di roll-out dei contatori G4 con interfaccia radio può essere complicato
stabilire a priori il numero massimo di aggiornamenti firmware possibili, dato che la presenza di
eventuali problematiche software e eventuali diverse condizioni operative dello smart meter
possono richiedere un aggiornamento del firmware.
Per queste ragioni, ovvero per minimizzare i problemi logistici nella fase di roll-out e
aggiornamento firmware dei contatori, può essere utile un approccio tendente a minimizzare i tempi
di trasmissione e di conseguenza i blocchi trasferiti.
La proposta MeterLinq per l'aggiornamento firmware, consiste in una libreria open source chiamata
libPatch, che ha come obiettivo quello di ridurre il volume delle informazioni trasmesse via radio
per due motivi principali:
1) la riduzione dei blocchi trasmessi aumenta la probabilità che l'aggiornamento sia ricevuto
con successo dal contatore riducendo la possibilità di errori di comunicazione, e
2) di conseguenza ottenere un sensibile risparmio energetico complessivo nella fase di
aggiornamento.
Il concetto di base del sistema di aggiornamento firmware MeterLinq è quello di inviare unicamente
le differenze tra le versioni, quella in esercizio e la successiva.
Per raggiungere questo obiettivo, per prima cosa vengono analizzate le due versioni di firmware
dello smart meter, ovvero viene effettuato un confronto binario tra il firmware esistente e la nuova
versione da distribuire.
Pagina 9
Firmware Image
Compare
New Image
Binary Δ
Diff
Comp Δ
Raw Blocks
Messages
Block 1
DLMS/COSEM 1
Block 2
DLMS/COSEM 2
Block 3
DLMS/COSEM 3
Block 4
DLMS/COSEM 4
Block N
DLMS/COSEM N
Shrink
Figura 4: Architettura libPatch
Questa attività viene eseguita automaticamente dal NOC di MeterLinq (sistema di gestione
MeterNet) una volta ricevuta l'immagine firmware da distribuire da parte del SAC del cliente per
mezzo di una applicazione di comparazione binaria.
L'interfacciamento tra il SAC del cliente ed il sistema di gestione MeterNet avviene utilizzando
l'interfaccia PP3 su TCP/IP, [7] oppure in modo semplificato attraverso una interfaccia REST messa
a disposizione dall'application server MeterNet.
Dal risultato del confronto dei file binari presenti sul server MeterNet, vengono determinate le
differenze tra le due versioni del firmware e viene creata una prima struttura di patch chiamata
“binary delta” o bΔ.
Il bΔ contiene non solo l'insieme delle differenze tra le due versioni, ma anche una serie di
istruzioni ad alto livello da utilizzare nell'applicare il bΔ all'immagine firmware originale del
contatore per ottenere come risultato il firmware aggiornato.
Il bΔ viene poi compresso per diminuire ulteriormente il numero totale complessivo di bytes da
trasferire, e quindi suddiviso in blocchi per la trasmissione da parte del gateway.
Il processo di diffusione in rete degli aggiornamenti è completamente automatizzato da parte del
NOC di MeterLinq, che utilizza anche una serie di informazioni aggiuntive per ottimizzare la fase
di delivery degli aggiornamenti anche sulla base delle condizioni della rete radio.
Sul contatore il processo è molto più semplice; la ricezione del bΔ avviene esattamente secondo le
specifiche della UNI TS 11291-11-2, ovvero utilizzando le finestra di manutenzione in modo
convenzionale, ma raccogliendo i blocchi che compongono il bΔ invece che i blocchi di dati “raw”
normalmente inviati.
Una volta raccolti in tutto o in parte i blocchi del bΔ , il firmware di bordo deve implementare la
funzioni della libreria open source libPatch, che ripristina il bΔ compresso al suo stato originale e
poi inizia ad eseguire le istruzioni contenute.
L'interfaccia a bordo del contatore consiste essenzialmente nella chiamata ad una funzione
Pagina 10
patch(received_block) → write offset, length, buffer
che per ogni blocco compresso ricevuto ne ritorna la versione espansa, l'offset di scrittura dall'inizio
dell'immagine firmware attuale e la lunghezza effettiva di scrittura. In pratica, la funzione patch
agisce anche come interprete dei comandi definiti dal sistema di generazione del bΔ.
Il codice sorgente della funzione patch, fornito da MeterLinq e da implementare sul contatore è
scritto nel linguaggio ANSI C e non presenta alcun tipo di dipendenza esterna da sistemi operativi,
real time executives o altre librerie.
Received
blocks
Binary Δ
Inflate
Current Image
Patch
New Image
Result
Figura 5: Ricostruzione immagine firmware
La funzione patch è compatta, con una dimensione inferiore ad 1 KB, e durante l'esecuzione
richiede solamente l'accesso ad un buffer statico in memoria RAM, che viene poi restituito al
sistema una volta terminata la procedura di ricostruzione e aggiornamento dell'immagine.
La dimensione del buffer statico è configurabile sul server MeterNet in sede di generazione del bΔ,
in modo tale da poter essere adattata a tipologie diverse di smart meter, anche se per motivi di
praticità è consigliabile una predisposizione temporanea di 1 KB.
Applicando in modo iterativo la funzione patch, come rappresentato in figura 5, si ottiene una
serie di blocchi dati da sovrascrivere al codice (realisticamente a una sua copia).
Il risultato è una versione modificata del firmware esistente che corrisponde all'aggiornamento
desiderato, verificata per congruenza ed integrità con l'originale inviato dal SAC.
Il codice della funzione è compilabile con qualsiasi compilatore e su diverse architetture di
micro-controllore; dal momento che libPatch è utilizzata anche nel gateway/concentratore
MeterLinq, la libreria è già validata per l'utilizzo con i micro controllori a 32 bit della famiglia
STM32 prodotta da ST Microelectronics.
Il server MeterNet in accoppiata con libPatch opera una serie di altre ottimizzazioni della procedura
di aggiornamento che vanno dalla mappatura dinamica dello stato dei trasferimenti, alla
Pagina 11
riconfigurazione delle finestre di manutenzione sulla base dell'effettivo stato della copertura radio.
Vengono gestite con efficacia dalla lbreria anche situazioni anomale di ricezione dei blocchi di
aggiornamento fuori sequenza, mitigando quindi l'impatto di eventuali derive degli orologi dei
contatori, oppure in caso di copertura radio fluttuante.
Conclusione
L'aggiornamento del firmware dei gruppi di misura può non essere particolarmente oneroso per i
gruppi di misura, ma rappresenta sicuramente una grossa sfida logistica ed organizzativa, dal
momento che mette in gioco tutti i componenti della infrastruttura di rete: SAC, autorità di garanzia
per la sicurezza, gateway/concentratori e contatori.
Il vero problema da risolvere è riuscire ad effettuare una operazione di aggiornamento così
articolata in modo efficiente ed evitando problemi di operatività della rete.
Per questo motivo può risultare estremamente efficace un processo di ottimizzazione delle
trasmissioni con l'obiettivo di sfoltire e semplificare il traffico tra contatori e SAC.
Nell'uso comune, libPatch consente di ridurre dal 30% fino ad oltre il 50% il volume delle
informazioni trasferite via radio.
Il vantaggio della compressione non è quindi relativo solamente al risparmio energetico, ma al fatto
che consente di aumentare le probabilità di eseguire aggiornamenti con successo nel minor tempo
possibile.
Il sistema di aggiornamenti basato su libPatch è attualmente utilizzato anche nei
gateway/concentratori MeterLinq per ottimizzare l'impiego della rete MeterNet, ma la sua efficacia
potrebbe risultare un valore aggiunto nella gestione di un ampio parco di smart meters.
La disponibilità della libreria in open source, e i vantaggi provenienti dal delegare la gestione di una
attività complessa come l'aggiornamento firmware dei contatori al sistema MeterNet permettono di
semplificare le attività del SAC rispetto all'attività di gestione della rete radio e dell'architettura di
comunicazione punto multi-punto dei contatori di classe A2.
La libreria libPatch è disponibile gratuitamente e distribuita con la licenza EUPL (European Union
Public Licence) sul sito MeterLinq.
Pagina 12
Riferimenti
[1] UNI/TS 11291-6:2013 Sistemi di misurazione del gas - Dispositivi di misurazione del gas su
base oraria - Parte 6: Requisiti per gruppi di misura con portata minore di 10 m3/h (contatore minore
di G10)
[2] UNI CEI EN 13757-4:2013 - Parte 4: Lettura wireless del contatore (lettura via radio per il
funzionamento nelle bande SRD)
[3] UNI/TS 11291-11-1:2014 Sistemi di misurazione del gas - Dispositivi di misurazione del gas su
base oraria - Parte 11-1: Generalità
[4] UNI/TS 11291-11-2:2014 Sistemi di misurazione del gas - Dispositivi di misurazione del gas su
base oraria - Parte 11-2: Modello dati
[5] UNI/TS 11291-11-4:2014 Sistemi di misurazione del gas - Dispositivi di misurazione del gas su
base oraria - Parte 11-4: Profili di comunicazione PM1
[6] UNI/TS 11291-10:2013 Sistemi di misurazione del gas - Dispositivi di misurazione del gas su
base oraria - Parte 10: Sicurezza
[7] UNI/TS 11291-11-5:2014 Sistemi di misurazione del gas - Dispositivi di misurazione del gas su
base oraria - Parte 11-5: Profili di comunicazione PP3
[8] UNI/TS 11291-9:2013 Sistemi di misurazione del gas - Dispositivi di misurazione del gas su
base oraria - Parte 9: Prove funzionali e di interoperabilità
[9] DLMS UA 1000-2 Ed. 7.0:2009 – DLMS/COSEM Architecture and Protocols, “Green Book”
[10] ETSI EN 300 220-1 V2.4.1 (2012-01) Electromagnetic compatibility and Radio spectrum
Matters (ERM); Short Range Devices (SRD); Radio equipment to be used in the 25 MHz to 1 000
MHz frequency range with power levels ranging up to 500 mW; Part 1: Technical characteristics
and test methods
[11] CEPT REC Recommendation 70-03 CEPT Relating to the Use of Short Range Devices (SRD)
- Subsequent amendments - 07 February 2014
Pagina 13

Download Report