Smart metering gas, i nuovi sistemi di telegestione

Smart metering gas, i nuovi sistemi di telegestione Un ambiente di prova dedicato per garantirne l'intercambiabilità e l'interoperabilità Antonella Scaglia - Marco De Angelis IMQ - Istituto Italiano del Marchio di Qualità Milano, Italy Dario Bellatreccia ALTRAN Bologna, Italy Abstract Sistemi smart di telelettura e telegestione del gas naturale. Il progetto Test Suite realizzato da IMQ per le verifiche dei casi d uso d intercambiabilità previsti dalla UNI TS 11291-11-6 per i nuovi contatori intelligenti e i gateway di rete. Keywords intercambiabilità, interoperabilità, gas naturale, gateway, test suite, smart metering I. INTRODUZIONE L ambizioso programma europeo di Ricerca e Innovazione Horizon 2020 ha tra i principali obiettivi il miglioramento dell efficienza energetica complessiva del 20% entro il 2020. Per supportare il conseguimento di questo risultato, l Unione ha istituito un quadro comune di riferimento adottando la Direttiva 2006/32/CE, aggiornata dalla Direttiva 2012/27/CE, concernente l efficienza degli usi finali dell'energia e i servizi energetici. Negli indirizzi di miglioramento dell'efficienza energetica stabiliti dal Parlamento Europeo e dalla Commissione vi sono le innovazioni tecnologiche efficaci, tra cui, ad esempio, l introduzione dei contatori intelligenti (comunemente chiamati smart meter ). Con questo termine si identifica una nuova generazione di apparati elettronici per la registrazione dei consumi di energia (elettricità, gas, acqua e calore), mediante i quali l utente finale, quasi in tempo reale, è in grado di verificare l energia prelevata e l importo effettivamente pagato. Questo processo è consentito dall integrazione degli smart meter in reti di telecomunicazione, ad esempio le comuni reti mobile dati (come 3G o 4G) o, alternativamente, con l utilizzo di dispositivi di interfaccia denominati gateway. Il consumatore, utilizzando una semplice applicazione installata nel proprio smartphone o altri supporti, acquisisce un ruolo attivo, con la possibilità di intervenire direttamente nel processo di efficientamento energetico: ad esempio, individuando gli apparecchi domestici che sono a più alto consumo di energia, sostituendoli, oppure riducendone l utilizzo per il tempo necessario, attivando processi di automazione domestica intelligente denominati scenari. Discutendo di riduzione dei consumi energetici è più naturale fare riferimento all elettricità, perché di più facile controllo per l utente finale. Con le altre tipologie di energie, quali gas e calore, una gestione intelligente sembrerebbe apparentemente più complessa da attuare. E invece, quale potrebbe essere il vantaggio nell utilizzare smart meter in tali ambiti? Per rispondere in parte a questa domanda, si pensi che la funzione primaria di un contatore intelligente è quella di rendere disponibili dati di misura esatti senza la necessità di interventi da parte del consumatore (come le poco agevoli procedure di auto-lettura, utilizzate ancora oggi in alcuni contatori). Per i distributori significherebbe disporre di precisi rilevamenti dei quantitativi di gas erogati nei punti di riconsegna, consentendo il raggiungimento degli obiettivi di efficienza e affidabilità del servizio. La gestione delle volture e delle morosità risulterebbe più trasparente ed efficace: i conguagli sarebbero ridotti a casi eccezionali, migliorando anche la percezione e la qualità del servizio presso l Utenza. La disponibilità in tempo reale dei consumi faciliterebbe e quindi favorirebbe scenari di gara per l assegnazione dei servizi di distribuzione, incentivando le Aziende del settore a rinnovare gli impianti, ad effettuare sinergie che riducano i costi di gestione, introducendo ulteriori elementi di concorrenza, a beneficio dell efficienza di tutti i processi. E non solo. Questi sistemi offrirebbero altre prestazioni interessanti, ad esempio consentendo la modifica delle condizioni di fornitura anche per periodi limitati, nonché del fornitore stesso. Inoltre sarebbero intrinsecamente predisposti alla gestione del cosiddetto multi-servizio (ossia la fornitura di differenti energie), con evidenti vantaggi di natura commerciale. Infine, considerando un possibile scenario futuro - già realizzabile con tecnologia esistente, ma subordinato all interesse dei distributori nell offrire tale opportunità ai propri clienti - gli smart meter potrebbero interagire direttamente con ambienti domestici intelligenti (smart home), ottenendo obiettivi di efficientamento energetico ben superiori a quelli fino ad oggi ipotizzati, oppure abilitando servizi di pubblica utilità. II. LO STATO DELL ARTE DELLO SMART METERING GAS I contatori di elettricità telegestiti sono già una realtà pienamente operativa da alcuni anni e si sta considerando l introduzione di una prossima generazione più performante. Per il gas naturale la situazione è un po differente: il CIG (Comitato Italiano Gas), su mandato dell Autorità per l energia elettrica il gas e il sistema idrico (Deliberazione n ARG/gas 155/08 22 ottobre 2008), ha recentemente ultimato la stesura di un dettagliato quadro tecnico-normativo di riferimento (la serie di norme tecniche UNI/TS 11291[1][2]). Come risultato, i fabbricanti stanno concentrando importanti sforzi nella

progettazione e realizzazione dei primi contatori gas intelligenti e dei gateway per la loro telegestione, entrambi rispondenti a tale normativa. Le specifiche tecniche e funzionali ora disponibili sono ben definite e robuste, essendo basate su tecnologie consolidate fin dagli anni Ottanta; tuttavia, considerando il complesso processo innovativo introdotto da queste nuove applicazioni, è naturale che si sviluppi qualche occasionale dubbio interpretativo nelle fasi iniziali di implementazione della rete e avvio del servizio. Di questo aspetto se ne farà carico la competente commissione tecnica del CIG. Per quanto riguarda invece gli smart meter per acqua e calore, i fabbricanti stanno ultimando la realizzazione dei primi apparati compatibili con l infrastruttura di telegestione definita nella UNI TS 11291; presto questi dispositivi saranno oggetto di sperimentazione nel territorio nazionale insieme a rispettivi omologhi per il gas (Delibera del 10 luglio 2014 n 334/2014/R/gas e comunicato stampa Energia: al via in 9 città progetti pilota di smart meter multi servizio, 8 settembre 2014, pubblicati dall Autorità per l energia elettrica il gas e il sistema idrico). III. IL PROGETTO TEST SUITE Nell ambito dei sistemi di telelettura e telegestione per il gas naturale destinati all uso domestico, IMQ, in collaborazione con la società ALTRAN, ha investito proprie risorse e competenze per la realizzazione di un ambiente di collaudo per smart meter e gateway, denominato Test Suite. Il progetto realizza una soluzione innovativa per i progettisti di sistemi di misura per gas, in grado di operare sia come piattaforma di sviluppo per i nuovi apparecchi per reti di telegestione, sia come strumento per la loro validazione funzionale prima della effettiva immissione nel mercato. Fig. 1. Architettura generale software La Test Suite, attraverso un software dedicato e i componenti d interfaccia che saranno descritti in seguito, realizza i numerosi prospetti di controllo stabiliti nella norma tecnica [2], eccetto quelli relativi allo strato fisico (ossia meccanici, ottici e a radiofrequenza) che non rientrano nello scopo di questo ambiente di test. Il sistema consente la messa a punto e la verifica degli apparati smart meter e dei gateway secondo le specifiche definite nelle norme [1]; tra queste vi sono le caratteristiche funzionali e di sicurezza, l interoperabilità (ossia la capacità di scambiare dati tra gli elementi di un sistema) e, soprattutto, l intercambiabilità. Quest ultimo è senz altro il requisito più importante: elementi intercambiabili di un sistema possono essere sostituiti da altri apparecchi similari senza provocare alcun degrado delle prestazioni, al costo di semplici operazioni di riconfigurazione dei sistemi stessi. L interoperabilità, così come tutte le altre caratteristiche funzionali, rappresenta perciò un sottoinsieme dall attributo più restrittivo d intercambiabilità. IV. ARCHITETTURA DELL APPLICAZIONE L architettura software, rappresentata in Figura 1, è stata realizzata utilizzando l ambiente di sviluppo Qt 5.4 (2014) integrato con parti scritte in codice C++. I costituenti principali, possono essere brevemente descritti come segue: User Manager: modulo per la creazione e la gestione di nuovi utenti. Ogni utente dispone di un area dedicata (criptata) contenente i propri progetti. Test Database: contiene l archivio dei test stabiliti dalla specifica tecnica [2] (denominati casi d uso ) e i relativi script esecutivi. Questo database viene letto e gestito dal modulo Test Engine. Test Engine: motore di elaborazione che consente l esecuzione dei test contenuti nel modulo denominato TestDatabase. L utente interagisce con il sistema attraverso un interfaccia grafica (Desktop Interface). Al termine di ogni verifica, la tracciatura di tutti i messaggi scambiati (denominati trame ) e l esito ottenuto sono registrati in un rapporto di sessione. Projects Manager: gestisce i progetti dei singoli utenti, comprendendo gli elenchi dei test scelti, i relativi esiti, il registro di ogni singola azione dell utente e i parametri di default (eventualmente modificati). I/O Interface: consente un accesso astratto rispetto all hardware verso le porte fisiche di comunicazione di tipo USB, dove vengono implementati rispettivamente l HDLC (per la porta ottica), e un protocollo di colloquio con il modulo radio 169 MHz, che opera come gateway simulator. Questo modulo trasferisce i messaggi da/a Test Engine, che procede a verificare la correttezza dei formati e dei contenuti, nonché delle sequenze delle trame, verificando così la conformità rispetto alla norma Sicurezza: tutti i file gestiti dall applicazione sono in formato binario e dotati di codice di controllo, composto dall hash del file e da una chiave segreta, rigenerato ad ogni modifica per prevenire eventuali manomissioni. Questo aspetto è particolarmente importante perché la Test Suite può essere utilizzata anche come strumento di verifica di conformità ai sensi

di una certificazione (rilasciata da IMQ in qualità di Ente Terzo). Come accennato in precedenza, la Test Suite implementa rigorosamente i casi d uso definiti nella specifica tecnica [2]. A tale scopo, è in grado di ricreare valide condizioni funzionali per l apparecchio in esame (denominate scenari ) e le impostazioni iniziali, come ad esempio dati pre-caricati. L applicazione agisce anche da gateway simulator per poter controllare correttamente lo smart meter da collaudare; mentre, in caso di verifica di un gateway, emula la presenza di un contatore, potendolo telegestire attraverso una sorta di piattaforma SAC (Sistema di Accesso Centralizzato per la raccolta dei dati delle teleletture e per la telegestione della rete). Per poter comprendere meglio l organizzazione funzionale dell ambiente ricreato dalla Test Suite, occorre ricordare che i requisiti di intercambiabilità ed interoperabilità dei dispositivi sono garantiti attraverso l implementazione di alcuni livelli logici differenziati nell architettura di sistema, ossia il livello fisico, il livello di trasporto dati e il livello applicativo, naturalmente adattati alle logiche di servizio e di sicurezza previste. Essi saranno esaminati in dettaglio nei prossimi paragrafi. A. Lo smart meter gas: interfacce del sottosistema di comunicazione Lo smart meter gas (o Gruppo di Misura GdM nella terminologia UNI TS) è un dispositivo che può essere schematizzato in due blocchi funzionali: il sottosistema di misura e gestione del servizio (valvola) il sottosistema di comunicazione La norma tecnica UNI TS 11291 è focalizzata sul sottosistema di comunicazione, e in particolare sulle due interfacce di cui ogni GdM deve essere dotato: l interfaccia locale, di tipo ottico, conforme alla norma [4] e l interfaccia di tipo RF, conforme alla norma [5] (wireless M-Bus). La Test Suite richiede l esecuzione di molteplici operazioni, che fanno riferimento all utilizzo quotidiano del GdM, e ne verifica gli esiti in massima parte attraverso scambio di messaggi con le due interfacce del sottosistema di comunicazione. È importante sottolineare che la norma tecnica [2] che, come già scritto, definisce i test di interoperabilità e di intercambiabilità, non ha come obiettivo quello di verificare la funzionalità del GdM, ma piuttosto la capacità dello stesso GdM di ricevere comandi e comunicare stati ed eventi con modalità e protocolli interoperabili. Alcuni test quindi riguardano proprio questi aspetti funzionali, ma la vera finalità è verificare che la comunicazione tra il GdM e i vari Client che lo accedono (si veda oltre) sia interoperabile. B. Interfaccia locale e livello fisico PM1 configurazioni di prova Per eseguire i Test Cases sono definite alcune impostazioni di prova: per ogni Test Case viene indicata una determinata configurazione da utilizzare. Alcune di esse riguardano le verifiche da effettuare sui livelli fisici (quindi escluse dallo scopo della Test Suite); tutte le altre (riguardanti circa 160 prove) prevedono l utilizzo di una sonda ottica ZVEI per comunicare localmente, la comunicazione wireless attraverso un cosiddetto gateway simulator (GWS), realizzato con un kit radio 169 MHz STM STEVAL-IKR002V1 prodotto da ST Microelectronics, e l utilizzo di altri apparati (come ad esempio soffiatori calibrati per simulare il flusso del gas, o simulatori di batteria per simulare condizioni di carica parziale, etc). Ogni Test Case è descritto attraverso un Prospetto, che indica quale configurazione deve essere allestita, quali operazioni effettuare, e quali sono gli esiti attesi. In molti casi l interfaccia locale viene utilizzata per portare il GdM in uno stato particolare, che consente poi l esecuzione del test usando il GWS o altre apparecchiature esterne (come il soffiatore calibrato). Entrambe le interfacce, locale e RF, utilizzano il protocollo applicativo DLMS/COSEM. Si tratta di un protocollo Object Oriented, che consente l interazione tra due entità (un Client e un Server) attraverso oggetti che esportano metodi attraverso i quali in ragione dei diritti d accesso è possibile leggere o modificare alcuni parametri o attributi. Il GdM si comporta sempre come un Server, al quale i vari Client sottopongono molteplici richieste (ad esempio la lettura della data e dell ora, la lettura dei totalizzatori, la lettura degli allarmi, un azione di chiusura della valvola, etc). I Client possono essere diversi, con differenti diritti: il Client di Gestione, che coincide con il Sistema di Accesso Centralizzato (il SAC), e che raccoglie i totalizzatori e i dati diagnostici, può agire sulla valvola, etc; il Client di Manutenzione, che opera localmente attraverso la porta ottica; il Client Gateway, che, ad esempio, esegue operazioni di sincronizzazione degli orologi. Gli oggetti che il GdM può gestire (e che quindi i Client sono in grado di accedere e modificare) sono parecchie decine, e sono codificati attraverso 6 numeri, denominati OBIS code, secondo la sintassi aa-bb:mm.nn.oo.pp. Ad esempio, l oggetto UNIX TIME, che rappresenta la data e l ora in formato UTC (tempo coordinato universale), ha l OBIS code 0-0:1.1.0.255. Quando un Client vuole accedere o modificare un oggetto del Server, lo indirizza utilizzando il suo OBIS code. La norma definisce poi gli attributi e i metodi di accesso, con i relativi previlegi (UNI TS 11291-11-2). Per ambedue le interfacce l interazione consiste in richieste dei Client che ricevono risposte dal Server (il GdM): le richieste e le risposte sono veicolate attraverso il protocollo applicativo DLMS/COSEM. I messaggi DLMS sono consegnati utilizzando un protocollo di trasporto, che nel caso dell interfaccia locale è l HDLC, mentre nel caso di interfaccia RF è il wireless M-Bus (descritto nella [5]). I Test Cases sono raggruppati secondo una numerazione che ne determina l ambito di applicabilità: 8.1-XX gruppo di test relativi all interfaccia locale ottica 8.2-XX gruppo di test relativi all interfaccia fisica PM1 8.3-XX gruppo di test relativi al livello data-link PM1 8.4-XX gruppo di test relativi al livello applicativo

La Test Suite, in ottemperanza alla norma [2], verifica che il livello data-link sia correttamente gestito dal GdM sull interfaccia locale (test del gruppo 8.1-XX); analogamente, attraverso i test del gruppo 8.3-XX, esamina la consistenza e la correttezza del livello data-link sull interfaccia RF (cosiddetta PM1). Infine, con i test del gruppo 8.4-XX effettuati in gran parte via porta locale conferma che il GdM esponga correttamente tutti i metodi di interazione con gli oggetti DLMS/COSEM, che ne definiscono il comportamento applicativo. In questo modo la Test Suite rappresenta uno strumento di rapido ed efficace utilizzabile sia in fase di debugging (analisi e correzione degli errori), sia in fase di validazione definitiva e Fig. 2. Test Suite: in evidenza la scheda STM STEVAL-IKR002V1, prodotta da STMicroelecreonics ed installata nel Gateway Symulator, e la sonda ZVEI relativa certificazione. ALTRAN, collaborando con il team di specialisti di STMicroelectronics, ha integrato le funzionalità già disponibili nel kit radio a 169 MHz con alcune modalità di tapping per l acquisizione di riscontri temporali precisi, come richiesto dalla norma: ad esempio nel Test Case 8.3-3 la norma [2] richiede la verifica delle temporizzazioni con precisioni dell ordine dei microsecondi. Queste misure quindi devono essere effettuate direttamente dal GWS, e non attraverso il PC Desktop nel quale gira il software di gestione della Test Suite, per garantire adeguata ripetibilità ed accuratezza. La norma [5] definisce molte modalità di utilizzo: per l ambito smart meter gas è stata definita la modalità N, che prevede l utilizzo di sei canali radio con frequenze spaziate di 12.5kHz nella banda principale a 169MHz. La modulazione è GFSK, e il bitrate è 4,8 kbs in quattro di essi, e 2,4 kbs sugli altri due. Tutti i canali sono bidirezionali, e la comunicazione tra gateway e GdM è di due tipi: messaggio spontaneo (cosiddetta PUSH), che il GdM invia periodicamente, rispettando regole definite e con opportuni oggetti DLMS. Le PUSH possono essere (o non essere) confermate dal gateway sessione Frequent Access Cycle (FAC), durante la quale i Client attraverso l intermediazione del gateway scambiano informazioni con il Server GdM che è momentaneamente disponibile, fino alla chiusura della FAC stessa. La Test Suite verifica ambedue i comportamenti attraverso i test del gruppo 8.3-XX, sia nella modalità ALOHA che nella modalità sincrona. Il trasporto wireless M-Bus prevede che il trasmettitore invii un preambolo con un bit pattern specificato, che il ricevitore utilizza per sincronizzare il proprio PLL. Successivamente seguono i campi di controllo e di indirizzamento, e il payload propriamente detto, che è cifrato con le chiavi del Client specifico, ed è in formato DLMS. La stratificazione del software del GdM (e conseguentemente, del software sviluppato per la Test Suite), consente di verificare la correttezza della sintassi del livello di trasporto, e successivamente di rendere disponibile al livello applicativo le informazioni che modificano il comportamento del GdM e/o ne raccolgono stati/eventi. V. ALCUNI ESEMPI DI TEST CASE A titolo esemplificativo, illustriamo di seguito due casi di test particolarmente significativi: Test 8.3-6 Verifica della trasmissione /ricezione sul canale selezionato Questo caso di test prevede la configurazione di prova #9 della norma [2], con uso della porta ottica locale e GWS. Il prospetto descrive le azioni da effettuare: la Test Suite si comporta, in questo caso, come HHUS (Hand Held Unit Simulator). Simula cioè il comportamento di uno Smartphone, o Tablet o PC portatile che attraverso la porta ottica configura il GdM in una certa modalità. La modalità scelta è quella di invio di spontanee (le cosddette PUSH) su uno dei canali a scelta (tra quelli a 4.8 kbs descritti in precedenza) per verificare se tramite accesso all oggetto OBIS opportuno, e con la richiesta di modifica dei parametri efffettuata con le dovute procedure e credenziali di sicurezza il GdM autentica il Client (che in questo caso è il Client di Gestione, cioè il SAC), e modifica di conseguenza il suo comportamento. Poiché i comandi sono inviati dai Client attraverso FAC, il Test Case chiede di verificare che il GdM termini la sessione corrente FAC sul canale attuale, e solo successivamente invii le nuove spontanee (PUSH) sul un nuovo canale, riconfigurato terminata la sessione FAC. Prova 8.4 49 Prova di chiusura (Disconnessione) immediata della valvola tramite singolo comando nel passato Questo test ha l obiettivo di verificare la catena di comandi ed eventi che consentono la chiusura della

valvola del GdM, e la conseguente interruzione del servizio (ad esempio per scadenza termini del contratto). La configurazione di prova prevede il cosiddetto HHUS (Hand Held Unit Simulator, cioè la Test Suite con la relativa porta ottica per l interfaccia locale) e un soffiatore che consenta di verificare se la portata si è effettivamente interrotta a seguito della chiusura della valvola. La prova consiste nell accedere tramite HHUS agli oggetti OBIS di gestione delle valvola, di configurazione PGV (Parola di Programmazione della Valvola) e Scheduler, che rispettivamente determinano il comportamento, le modalità e l istante di chiusura della valvola stessa. La Test Suite verifica la consistenza di Fig. 3. Registro delle trame scambiate (cifrate) tutte le trame HDLC scambiate con il GdM, e successivamente chiede conferma all operatore che il rilevatore di portata a valle del GdM rilevi portata nulla, e quindi la condizione di valvola chiusa. Questo test è esemplificativo di come concettualmente la norma [2] abbia inteso facilitare il compito di chi deve verificare l interoperabilità e l intercambiabilità: i test di livello applicativo sono in gran parte effettuati via HHUS (cioè, Test Suite dotata di porta ottica per l interfaccia locale). Invece i test effettuati con GWS hanno la controindicazione di dover essere condotti per forza attraverso cicli FAC a seguito di invio di spontanee (PUSH), e quindi implicano tempi di validazione molto più lunghi rispetto a quelli che richiedono accessi attraverso l interfaccia locale. Poiché il protocollo è stratificato in Layer 2 (trasporto) e Layer 7 (applicativo), le verifiche eseguite dai test 8.1-XX e 8.3-XX assicurano che i due diversi livelli di trasporto (HDLC per l interfaccia locale, e wireless M-Bus per l interfaccia RF) funzionino correttamente. Le verifiche applicative possono quindi essere condotte sull interfaccia locale, lasciando al Costruttore del GdM l onere di garantire, attraverso i suoi processi di sviluppo, la totale ortogonalità del comportamento applicativo rispetto al protocollo di trasporto. VI. SVILUPPI FUTURI L applicazione Test Suite può a richiesta decifrare le trame scambiate nel merito dei contenuti, sia per il livello di trasporto che applicativo, per consentire all utente un efficace azione di analisi di eventuali malfunzionamenti. I tracciati trama sono tutti protetti da chiave di protezione hw, per evitare la manomissione dei risultati, e proteggere l integrità dei risultati del test. L applicazione Test Suite può essere facilmente estesa per coprire anche test di integrazione che vedono coinvolti tutti i componenti del sistema: il SAC, il gateway e il Gruppo di Misura. Inoltre, è importante sottolineare come le norme tecniche di riferimento non prescrivano test di tipo affidabilistico. Non è questo infatti l obiettivo della UNI TS 11291, che definisce una classe di dispositivi e le loro interazioni (con il requisito cogente dell intercambiabilità e interoperabilità), ma non entra nel merito delle soluzioni tecnologiche, che possono essere più o meno robuste sul profilo della durata, dei costi di gestione, etc. Ad esempio, i test che riguardano la batteria sono finalizzati a verificare che un eventuale livello critico sia correttamente segnalato, come richiesto dall interoperabilità e intercambiabilità. Non effettuano misure di consumo, per stimare se la durata in utilizzo normale, o sotto stress, sarà adeguata al profilo di missione degli apparati. Disponendo dell ambiente della Test Suite, è sicuramente immaginabile un percorso che porti a finalizzare ulteriori test case che abbiano l obiettivo di verificare, oltre alle funzionalità, anche le prestazioni di tipo affidabilistico, per una corretta valutazione dei costi CAPEX rispetto agli OPEX. RIFERIMENTI [1] UNI/TS 11291-1:2013 Sistemi di misurazione del gas - Dispositivi di misurazione del gas su base oraria - Parte 1: Caratteristiche generali del sistema di telegestione o telelettura 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) UNI/TS 11291-7 2013 Sistemi di misurazione del gas - Dispositivi di misurazione del gas su base oraria - Parte 7: Sistemi di Telegestione dei misuratori gas 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à UNI/TS 11291-10:2013 Sistemi di misurazione del gas - Dispositivi di misurazione del gas su base oraria - Parte 10: Sicurezza UNI/TS 11291-11-1:2014 Sistemi di misurazione del gas - Dispositivi di misurazione del gas su base oraria - Parte 11-1: Generalità UNI/TS 11291-11-2:2014 Sistemi di misurazione del gas - Dispositivi di misurazione del gas su base oraria - Parte 11-2: Modello dati UNI/TS 11291-11-3:2014 Sistemi di misurazione del gas - Dispositivi di misurazione del gas su base oraria - Parte 11-3: Profilo di comunicazione su interfaccia locale 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

UNI/TS 11291-11-5:2014 Sistemi di misurazione del gas - Dispositivi di misurazione del gas su base oraria - Parte 11-5: Profilo di comunicazione PP3 [2] UNI/TS 11291-11-6:2015 Sistemi di misurazione del gas - Dispositivi di misurazione del gas su base oraria - Parte 11-6: Intercambiabilità - Specifiche di prova per la valutazione di conformità [3] DLMS Blue Book COSEM Identification System and Interface Classes DLMS Green Book DLMS/COSEM Architecture and Protocols DLMS Yellow Book DLMS/COSEM Conformance Testing Process DLMS White Book COSEM Glossary of Terms [4] EN 62056-21:2002 Misura dell'energia elettrica - Scambio dei dati per la lettura dei contatori, controllo delle tariffe e del carico Parte 21: Scambio dei dati diretti in locale [5] EN 13757-4:2013 Communication systems for meters and remote reading of meters Part 4: Wireless meter readout (Radio meter reading for operation in SRD bands)