).
I membri del gruppo di lavoro 10 del comitato tecnico 57 "Gestione dei sistemi elettrici e delle relative tecnologie di scambio di informazioni" dell'IEC, che sta sviluppando lo standard, Alexey Olegovich Anoshin e Alexander Valerievich Golovin stanno oggi prendendo in considerazione il protocollo di trasferimento dati utilizzando la tecnologia server-client -MMS.

NORMA CEI EN 61850
Protocollo MMS

Nella pubblicazione abbiamo esaminato uno dei protocolli di comunicazione importanti e più discussi descritti dallo standard IEC 61850: il protocollo GOOSE, progettato per trasmettere segnali principalmente discreti tra dispositivi di protezione relè e dispositivi di automazione (RPA) in formato digitale. Oltre a GOOSE, lo standard descrive:

• MMS (Manufacturing Message SPECIFIC) - protocollo di trasferimento dati che utilizza la tecnologia client-server;
• SV (IEC 61850-9-2) è un protocollo per la trasmissione di valori di corrente e tensione istantanei dai trasformatori di misura.
  A rigor di termini, lo standard IEC 61850 non descrive il protocollo MMS. Il capitolo IEC 61850-8-1 specifica solo come vengono assegnati i servizi dati.

SERVIZI DI TRASMISSIONE DATI ASTRATTI

Una delle idee principali racchiuse nello standard IEC 61850 è che non cambia nel tempo. I capitoli dello standard descrivono in sequenza prima le questioni concettuali del trasferimento di dati all'interno e tra impianti elettrici, quindi la cosiddetta "interfaccia di comunicazione astratta" e solo nella fase finale - l'assegnazione di modelli astratti ai protocolli di trasferimento dei dati.

Pertanto, le questioni concettuali e i modelli astratti risultano indipendenti dalle tecnologie di trasmissione dei dati utilizzate (canali cablati, ottici o radio) e pertanto non richiederanno una revisione in relazione ai progressi nel campo delle tecnologie di trasmissione dei dati.

L'interfaccia di comunicazione astratta nella norma IEC 61850-7-2 comprende sia i modelli di dispositivo (ovvero standardizza i concetti di "dispositivo logico", "nodo logico", "blocco di controllo", ecc.) sia una descrizione dei servizi di trasferimento dati.

Oltre al servizio GOOSE, il Capitolo 7-2 descrive più di 60 servizi che standardizzano:

• la procedura per stabilire la comunicazione tra il client e il server (Associate, Abort, Release);
• procedura di lettura del modello informativo (Get-ServerDirectory, GetLogicalDeviceDirectory, GetLogical-NodeDirectory);
• procedura per la lettura dei valori delle variabili (GetAll-DataValues, GetDataValues, ecc.);
• trasferimento di valori variabili sotto forma di report (Report) e altri.

Il trasferimento dei dati nei servizi elencati viene effettuato utilizzando la tecnologia client-server. Ad esempio, in questo caso il server può essere un dispositivo di protezione relè e il client può essere un sistema SCADA.

I servizi di lettura consentono al client di leggere un modello informativo completo dal dispositivo, ovvero di ricreare un albero di dispositivi logici, nodi logici, elementi e attributi di dati. In questo caso, il cliente riceverà una descrizione semantica completa dei dati e della loro struttura. I servizi per la lettura dei valori delle variabili consentono di leggere i valori effettivi degli attributi dei dati, ad esempio utilizzando un metodo di polling periodico. Il servizio di reportistica consente di configurare l'invio di determinati dati al verificarsi di determinate condizioni. Una variante di tale condizione potrebbe essere un cambiamento di vario tipo associato a uno o più elementi del set di dati.

Per implementare i modelli astratti di trasmissione dei dati descritti, la norma IEC 61850 prevede l'assegnazione di modelli astratti ad uno specifico protocollo. Per i servizi in esame tale protocollo è l'MMS, descritto dallo standard ISO/IEC 9506.

STORIA DEGLI MMS

Nel 1980, il protocollo MMS (Manufacturing Message Specifiche) è stato sviluppato per automatizzare la produzione automobilistica da parte della General Motors. Tuttavia, il protocollo si è diffuso solo dopo essere stato significativamente riprogettato da Boeing e ha iniziato ad essere utilizzato attivamente nei settori automobilistico e aerospaziale dai produttori di controllori logici programmabili (Siemens, Schneider Electric, Daimler, ABB).

Nel 1990, l'MMS è stato standardizzato come ISO/IEC 9506. Oggi esiste una seconda edizione di questo standard, pubblicata nel 2003. I problemi risolti durante lo sviluppo del protocollo MMS erano generalmente simili ai problemi risolti dallo standard IEC 61850:

• Fornire una procedura standard per il trasferimento di dati da controller di vario tipo, indipendentemente dal produttore.
• Leggere e scrivere dati utilizzando messaggi standard.

COMPITI MMS

L'MMS definisce:

• un insieme di oggetti standard per eseguire operazioni sugli stessi che devono esistere nel dispositivo (ad esempio lettura e scrittura di variabili, segnalazione di eventi, ecc.);
• un insieme di messaggi standard scambiati tra client e server per le operazioni di gestione;
• un insieme di regole per codificare questi messaggi (come valori e parametri vengono assegnati a bit e byte durante la trasmissione);
• un insieme di protocolli (regole per lo scambio di messaggi tra dispositivi).

Pertanto, MMS non definisce i servizi applicativi, che sono definiti dallo standard IEC 61850. Inoltre, il protocollo MMS non è di per sé un protocollo di comunicazione, definisce solo messaggi che devono essere trasmessi su una rete specifica. MMS utilizza lo stack TCP/IP come protocollo di comunicazione. La struttura generale dell'utilizzo del protocollo MMS per l'implementazione dei servizi di trasferimento dati in conformità con la norma IEC 61850 è presentata in Fig. 1.

Riso. 1. Schema del trasferimento dati tramite protocollo MMS

Come accennato in precedenza, il sistema scelto, a prima vista piuttosto complesso, consente in definitiva, da un lato, di garantire l’immutabilità dei modelli astratti (e quindi l’immutabilità della norma e dei suoi requisiti), e dall’altro , utilizzare le moderne tecnologie di comunicazione basate sul protocollo IP . Va tuttavia notato che, a causa dell’elevato numero di assegnazioni, il protocollo MMS è relativamente lento, il che lo rende poco pratico per le applicazioni in tempo reale.

ESECUZIONE DELLE ATTIVITÀ DI RACCOLTA DATI APPLICATE

Lo scopo principale del protocollo MMS è l'implementazione delle funzioni del sistema di controllo automatizzato del processo, ovvero la raccolta di dati di telesegnalazione e telemisurazione, nonché la trasmissione di comandi di telecontrollo.

Allo scopo di raccogliere informazioni, il protocollo MMS fornisce due funzionalità principali:

• raccogliere dati utilizzando il polling periodico del/i server da parte del client;
• trasmissione dei dati al client da parte del server sotto forma di report (sporadici).

Entrambi questi metodi sono richiesti quando si imposta e si utilizza un sistema di controllo di processo automatizzato. Per determinare le aree della loro applicazione, diamo uno sguardo più da vicino ai meccanismi di funzionamento di ciascuno (Fig. 2).

Riso. 2. Meccanismo di trasferimento dati client-server

Raccolta dei dati interrogando periodicamente il server da parte del client

Nella prima fase viene stabilita una connessione tra i dispositivi “client” e “server” (servizio di associazione). La connessione viene avviata dal client contattando il server utilizzando il suo indirizzo IP.

Nella fase successiva, il client richiede determinati dati al server e riceve da esso una risposta con i dati richiesti. Ad esempio, dopo aver stabilito una connessione, un client può richiedere al server il proprio modello informativo utilizzando i servizi GetServerDirectory, GetLogicalDeviceDirectory, GetLogicalNodeDirectory. Le richieste verranno effettuate in sequenza:

• dopo una richiesta GetServerDirectory, il server restituirà un elenco di dispositivi logici disponibili;
• dopo una richiesta GetLogicalDeviceDirectory separata per ciascun dispositivo logico, il server restituirà un elenco di nodi logici in ciascuno dei dispositivi logici;
• una richiesta GetLogicalNodeDirectory per ogni singolo nodo logico restituirà i suoi oggetti e attributi di dati.

Di conseguenza, il client calcola e ricrea il modello informativo completo del dispositivo server. In questo caso, i valori effettivi degli attributi non verranno ancora letti, ovvero l'“albero” letto conterrà solo i nomi dei dispositivi logici, dei nodi logici, degli oggetti dati e degli attributi, ma senza i loro valori.

Nella terza fase è possibile leggere i valori effettivi di tutti gli attributi dei dati. In questo caso è possibile leggere tutti gli attributi utilizzando il servizio GetAllDataValues ​​oppure solo singoli attributi utilizzando il servizio GetDataValues.

Al completamento della terza fase, il client ricreerà completamente il modello informativo del server con tutti i valori degli attributi dei dati.

È opportuno notare che questa procedura prevede lo scambio di quantità di informazioni abbastanza significative con un numero elevato di richieste e risposte, a seconda del numero di dispositivi logici, di nodi logici e del numero di oggetti dati implementati dal server. Ciò porta anche ad un carico piuttosto elevato sull'hardware del dispositivo. Questi passaggi possono essere eseguiti in fase di impostazione del sistema SCADA, in modo che il cliente, dopo aver letto il modello informativo, possa accedere ai dati presenti sul server. Tuttavia, durante l'ulteriore funzionamento del sistema, non è richiesta la lettura regolare del modello informativo. È inoltre inappropriato leggere costantemente i valori degli attributi utilizzando il polling regolare. In alternativa è possibile utilizzare il servizio Report.

Trasferimento dei dati al client da parte del server sotto forma di report

La norma IEC 61850 definisce due tipi di report: bufferizzati e non bufferizzati.

La loro principale differenza è che quando si utilizza il primo, le informazioni generate verranno consegnate al client anche se nel momento in cui il server è pronto per emettere un report, non esiste alcuna connessione tra esso e il client (ad esempio, il canale di comunicazione corrispondente è stato rotto). Tutte le informazioni generate vengono accumulate nella memoria del dispositivo e la loro trasmissione verrà completata non appena verrà ripristinata la connessione tra i due dispositivi. L'unica limitazione è la quantità di memoria del server allocata per l'archiviazione dei report.

Se esiste una connessione tra il client e il server, sia quando si utilizza un report bufferizzato che quando si utilizza un report non bufferizzato, il trasferimento dei dati al client può essere immediato al verificarsi di determinati eventi nel sistema.

La seconda cosa da notare è che quando si parla di report non intendiamo monitorare tutti gli oggetti e gli attributi dei dati del modello informativo del server, ma solo quelli che ci interessano, combinati nei cosiddetti “set di dati”.

Il terzo punto importante: è possibile configurare il server non solo per trasmettere l'intero set di dati controllato, ma anche per trasmettere solo quegli oggetti/attributi di dati con cui si verificano determinati tipi di eventi entro un intervallo di tempo predefinito dall'utente.

Per fare ciò, nella struttura del blocco di controllo per la trasmissione dei report tamponati/non tamponati, è possibile specificare categorie di eventi, il cui verificarsi deve essere monitorato e, in base ai quali, solo quegli oggetti dati /gli attributi interessati da questi eventi verranno inclusi nel rapporto. Si distinguono le seguenti categorie di eventi:

• modifica dei dati (dchg). Quando imposti questo parametro, il report includerà solo gli attributi di dati i cui valori sono cambiati o solo quegli oggetti di dati i cui valori di attributo sono cambiati;
• cambiamento degli attributi di qualità (qchg). Quando imposti questo parametro, il report includerà solo quegli attributi di qualità i cui valori sono cambiati o solo quegli oggetti dati i cui attributi di qualità sono cambiati;
• aggiornamento dei dati (dupd). Impostando questa opzione, nel report verranno inclusi solo gli attributi o gli oggetti dati i cui valori sono stati aggiornati. Per aggiornamento intendiamo, ad esempio, il calcolo periodico dell'una o dell'altra componente armonica e la registrazione del suo nuovo valore nell'attributo dati corrispondente. Tuttavia, anche se il valore calcolato nel nuovo periodo non è cambiato, l'oggetto dati o l'attributo dati corrispondente viene incluso nel report.

Come accennato in precedenza, è anche possibile configurare il report per trasmettere l'intero set di dati monitorati. Tale trasferimento può essere effettuato sia su iniziativa del server (condizione di integrità) sia su iniziativa del client (interrogazione generale). Se viene inserita la generazione dei dati in base alla condizione di integrità, l'utente deve anche indicare il periodo per la generazione dei dati da parte del server. Se si accede alla generazione dei dati nella condizione di interrogazione generale, il server genererà un report con tutti gli elementi del set di dati alla ricezione del comando corrispondente dal client.

ANALISI COMPARATIVA DELLA RACCOLTA DATI ATTRAVERSO INDAGINI E REPORT PERIODICI

Il meccanismo di reporting presenta importanti vantaggi rispetto al metodo del polling periodico:

il carico sul processore server e sul processore client è ridotto;

è garantita la consegna rapida dei messaggi sugli eventi che si verificano nel sistema.

Tuttavia, è importante notare che tutti i vantaggi derivanti dall'utilizzo di report bufferizzati e non bufferizzati possono essere valutati solo se configurati correttamente, il che a sua volta richiede che il personale che esegue la configurazione dell'apparecchiatura sia altamente qualificato e abbia una vasta esperienza di progettazione.

ALTRI SERVIZI

Oltre ai servizi descritti, il protocollo MMS supporta anche modelli di controllo delle apparecchiature, la generazione e la trasmissione di registri di eventi, nonché il trasferimento di file, che consente di trasferire, ad esempio, file di oscillogrammi di emergenza. Questi servizi richiedono una considerazione separata.

CONCLUSIONI

Il protocollo MMS è uno dei protocolli a cui possono essere assegnati i servizi astratti descritti dalla norma IEC 61850-7-2. Allo stesso tempo, l’emergere di nuovi protocolli non influenzerà i modelli descritti dallo standard, garantendo che lo standard rimanga invariato nel tempo.

Per assegnare modelli e servizi al protocollo MMS si utilizza il capitolo IEC 61850-8-1.

Il protocollo MMS fornisce vari meccanismi per la lettura dei dati dai dispositivi, inclusa la lettura dei dati su richiesta e la trasmissione dei dati sotto forma di report dal server al client. A seconda dell'attività da risolvere, è necessario selezionare il meccanismo di trasmissione dei dati corretto e configurarlo di conseguenza, che consentirà di utilizzare in modo efficace l'intero set di protocolli di comunicazione dello standard IEC 61850 in una centrale elettrica.

LETTERATURA

1. Anoshin A.O., Golovin A.V. Norma IEC 61850. Protocollo GOOSE // .
2. MMS. Presentazione del prof. Dott. H. Kirrmann, Centro di ricerca ABB, Baden, Svizzera.
3. Anoshin A.O., Golovin A.V. Norma IEC 61850. Modello di informazioni sul dispositivo // .

• Traduzione

Le tecnologie delle comunicazioni stanno svolgendo un ruolo sempre più importante nel crescente mercato AMI. L'articolo presenta un'analisi completa e un confronto di quattro protocolli del livello applicativo utilizzati per la misurazione intelligente. Vengono presi in considerazione i seguenti protocolli: DLMS/COSEM, SML (Smart Message Language), nonché la mappatura MMS e SOAP di IEC 61850. Il lavoro si concentra sull'uso di questi protocolli insieme allo stack TCP/IP. I protocolli vengono prima confrontati rispetto a criteri di qualità, ad esempio la possibilità di sincronizzazione dell'ora, ecc. Successivamente viene confrontata la dimensione del messaggio e analizzata l'efficienza della codifica.

L'AMI (Infrastruttura di misurazione avanzata) è un sistema integrato di contatori intelligenti, reti di comunicazione e sistemi di gestione dei dati che include la comunicazione bidirezionale tra il fornitore del servizio e il consumatore.

I. Introduzione

Il numero e le dimensioni dei sistemi AMI stanno crescendo rapidamente. Sono costituiti da contatori intelligenti situati nelle case che comunicano in modo bidirezionale con il fornitore del servizio. L’implementazione di tali sistemi è principalmente associata al raggiungimento dei seguenti tre obiettivi:

1. Fornire ai consumatori informazioni sui loro consumi e sui costi, promuovendo così un uso più parsimonioso delle risorse;
2. Ridistribuire l'utilizzo delle risorse da periodi di carico elevato a periodi di carico basso.
3. Creare un'infrastruttura che possa essere facilmente utilizzata da altre applicazioni di rete intelligente nelle reti di distribuzione.

La comunicazione nei contatori intelligenti è oggetto di numerosi lavori di standardizzazione ( Per esempio,) e parte delle roadmap nazionali dedicate alle reti intelligenti. Ma fino ad ora, la maggior parte delle apparecchiature AMI installate utilizza protocolli proprietari che non sono conformi agli standard aperti o internazionali. In futuro, tuttavia, l’attenzione dovrà concentrarsi sugli standard aperti. Ciò creerà concorrenza nel libero mercato e porterà ad una riduzione del costo delle attrezzature.

Questo articolo mette a confronto quattro diversi protocolli del livello applicativo utilizzati per la misurazione intelligente. Questo è il protocollo SML ( Linguaggio Smart Message, bozza IEC 62056-58), DLMS/COSEM ( CEI 62056-53 E CEI 62056-62), nonché mappatura MMS e SOAP per lo standard IEC 61850.

In precedenza i protocolli per la misurazione intelligente dei consumi sono già stati analizzati da diversi punti di vista. Il lavoro fornisce quindi una panoramica generale dei protocolli più comuni per la misurazione intelligente dei consumi a tutti i livelli. Il documento mette a confronto DLMS/COSEM con IEC 60870-5-104. Il documento fornisce un'analisi dettagliata del DLMS/COSEM. Questo articolo è il primo a confrontare i protocolli DLMS/COSEM, SML e IEC 61850 in termini di criteri di qualità ed efficienza di codifica.

L'articolo è organizzato come segue. La seconda sezione illustra le topologie di rete comuni utilizzate nella misurazione intelligente. Viene indicato dove possono essere utilizzati i protocolli in questione. La terza sezione discute i criteri qualitativi con cui i protocolli vengono analizzati e confrontati nella quarta sezione. La quinta sezione analizza la dimensione del messaggio e l'efficienza di codifica dei protocolli considerati. Infine si dà la conclusione.

II. Topologia di comunicazione dei sistemi di misurazione intelligente dei consumi

Per organizzare la comunicazione nei sistemi AMI vengono utilizzate diverse topologie di rete. Tuttavia, la maggior parte delle topologie può essere derivata dalla forma generale fornita in Figura 1. In questa figura i contatori di gas, energia elettrica, acqua, calore sono collegati al cosiddetto “gateway di casa”, attraverso il quale viene implementata l'interfaccia verso il mondo esterno. Nella maggior parte dei casi questo gateway è effettivamente integrato nel contatore di energia elettrica. Si noti che i contatori del gas, dell'acqua e del calore sono speciali nel senso che sono alimentati principalmente da fonti autonome. Questa caratteristica deve essere presa in considerazione nella scelta dei protocolli di comunicazione per la linea ( B). Il gateway (o contatore di energia) può essere collegato ad un sistema di raccolta dati lato fornitore del servizio o direttamente tramite una connessione Internet ( Con), o attraverso un concentratore di dati ( D E e) - Dove D Di solito si tratta di una linea elettrica o di una soluzione wireless a medio raggio.

Figura 1 – Topologia di comunicazione per la misurazione intelligente dei consumi

I protocolli del livello applicazione discussi in questo articolo possono utilizzare lo stack di protocolli TCP/IP per lo scambio di dati, quindi sono adatti per comunicare tramite una connessione Internet ( Con E e), e può essere utilizzato anche per lo scambio di dati in reti locali come Ethernet e WiFi ( UN). Inoltre, alcuni dei protocolli considerati supportano lo scambio di dati utilizzando altri protocolli di livello inferiore. DLMS/COSEM supporta la comunicazione tramite UDP, HDLC, M-Bus, nonché vari protocolli di comunicazione su linea elettrica, come IEC 61334-5. SML supporta lo scambio dati tramite linee seriali e protocollo M-Bus. MMS e SOAP non supportano protocolli aggiuntivi di livello inferiore.

III. Criteri qualitativi

Questa sezione descrive i criteri qualitativi con cui i protocolli verranno analizzati e confrontati nella quarta sezione.

A. Supporta vari tipi di informazioni

I protocolli del livello applicativo utilizzati per la misurazione intelligente possono essere confrontati rispetto al loro supporto per la trasmissione di diversi tipi di informazioni. Per i sistemi AMI, di norma, sono necessarie tecnologie di comunicazione per trasmettere i seguenti tipi di informazioni:

• Risultati della misurazione. Naturalmente tutti i protocolli in esame supportano il trasferimento dei dati misurati (energia, potenza, tensione, volume, ecc.). Ma i protocolli possono differire nel supporto per tipi di informazioni come:
  • Carica profili. Il misuratore può memorizzare profili di carico ( Per esempio, con una risoluzione di 15 min.). Pertanto, i protocolli devono essere in grado di veicolare questi profili, se necessario con opportune timestamp;
  • Firma digitale. I risultati delle misurazioni possono essere firmati digitalmente per dimostrare l'integrità dei dati a terzi.
• Informazioni sulla sincronizzazione dell'orologio. La sincronizzazione dell'ora è importante per i contatori che memorizzano i profili di carico o per i contatori che cambiano rapidamente, in base a un programma, tra i registri tariffari.
• Aggiornamento del firmware. Poiché i gateway o i dispositivi di misurazione, nonché i relativi moduli di comunicazione, diventano sempre più complessi, la funzione di aggiornamento remoto del firmware sembra molto utile, poiché consente di correggere errori o aggiungere nuove funzionalità.
• Informazioni sui costi. La trasmissione delle informazioni sui costi può essere implementata in diversi modi. Nel lavoro è stata effettuata un'analisi dei vari approcci alla trasmissione delle tariffe e un confronto dei protocolli. Questo articolo non analizza i protocolli rispetto al loro supporto tariffario.

B. Possibilità di trasferimento dell'iniziativa

I protocolli del livello applicativo possono seguire un rigido principio client-server, nel qual caso la connessione o l'associazione viene stabilita solo dal client. Il server rappresenta il dispositivo che memorizza i dati del dispositivo di misurazione (ad esempio, il contatore stesso) e il client rappresenta il dispositivo che desidera accedere a questi dati o impostare eventuali parametri nel dispositivo server.

I protocolli possono anche basarsi sul principio peer-to-peer, nel qual caso i due oggetti tra i quali viene trasferita l'informazione hanno pari capacità. In qualsiasi momento, un oggetto può svolgere il ruolo di client o server. Questo principio consente un utilizzo più flessibile del protocollo, poiché i dispositivi di misurazione hanno la capacità di inviare dati ad altri dispositivi senza la necessità di stabilire una connessione dal lato client.

C. Disponibilità di un modello a oggetti di interfaccia

Nei protocolli di architettura client-server DLMS/COSEM e IEC 61850, il server contiene quello che viene chiamato un modello di oggetti di interfaccia, che rappresenta il dispositivo server ( Per esempio, dispositivo di misurazione). Questo modello è costruito utilizzando un approccio orientato agli oggetti e funge da interfaccia di informazioni visibili per il cliente. Il client può recuperare il modello a oggetti dell'interfaccia in modo standardizzato utilizzando il protocollo e quindi non ha bisogno di conoscere in anticipo l'esatta struttura e funzionalità del server. In questo caso si dice che il server descrive se stesso. Da un lato, il modello a oggetti dell'interfaccia recuperabile semplifica il meccanismo di comunicazione nel senso che il client può essere programmato per conformarsi automaticamente a diversi modelli. D'altra parte, questo modello consolida la struttura client-server, poiché il server contiene sempre il modello a oggetti dell'interfaccia.

D. Meccanismi di sicurezza integrati

La maggior parte dei contatori intelligenti installati richiede maggiore attenzione in termini di sicurezza del sistema AMI. Un protocollo può avere meccanismi di sicurezza integrati, come la crittografia, oppure può lasciare questa procedura a protocolli di livello inferiore, come TLS (Transport Layer Security).

IV. Analisi qualitativa

A.S.M.L.

LMS ( Linguaggio dei messaggi intelligente) è stato sviluppato come parte del progetto SyM 2 ( Contatore modulare sincrono). Il protocollo SML è ampiamente utilizzato in Germania e fa parte di un impegno più ampio volto a standardizzare la misurazione intelligente. Fino ad ora, SML è stato utilizzato raramente al di fuori della Germania, ma la situazione potrebbe cambiare se gli sforzi per promuovere il protocollo SML come standard internazionale avranno successo. Sarà comunque utile confrontare gli standard internazionali DLMS\COSEM e IEC 61850 con il protocollo SML. Poiché un simile confronto può portare a preziosi miglioramenti negli standard internazionali in questione.

SML differisce da DLMS/COSEM e IEC 61850 in quanto definisce i messaggi anziché definire un modello di oggetti di interfaccia e servizi per accedervi. SML, per definire la struttura gerarchica dei messaggi, utilizza un formato simile a ASN.1. I messaggi sono codificati con una cifra speciale, che verrà discussa nella quinta sezione. Possono esserci due tipi di messaggi, una richiesta o una risposta. Tuttavia, è possibile inviare un messaggio di risposta senza richiesta. Pertanto, SML non segue i rigidi principi dell'architettura client-server e i dispositivi di misurazione possono emettere messaggi proattivi.

Il formato del messaggio supporta la trasmissione dei profili di carico e delle firme digitali associate. È anche possibile trasferire una nuova immagine firmware e sincronizzare l'orologio, ma queste procedure sono descritte in altri standard ( Per esempio, ).

SML non dispone di meccanismi di sicurezza integrati oltre ai semplici campi "nome utente" e "password" nei messaggi SML. Il protocollo SSL/TLS può essere utilizzato per trasmettere dati su TCP/IP.

B.DLMS/COSEM

DLMS ( Specifica della lingua del messaggio del dispositivo) e COSEM ( Specifiche complementari per la misurazione dell'energia) insieme formano il protocollo del livello applicativo DLMS/COSEM e il modello di interfaccia per le applicazioni contabili. Utilizzando il livello intermedio definito in , DLMS/COSEM può essere utilizzato per trasmettere dati su TCP/IP e UDP/IP.

DLMS/COSEM si basa su una rigorosa architettura client-server. Il server è un dispositivo di misurazione e il client è un dispositivo che accede al dispositivo di misurazione. Il client, ad esempio, potrebbe essere un gateway o un dispositivo di raccolta dati da parte del fornitore di servizi. Sono possibili anche altre possibilità, ad esempio se il server si trova direttamente nel gateway e il client si trova dal lato del fornitore di servizi.

Prima che possano essere scambiate informazioni contenenti misurazioni reali, deve essere stabilita una cosiddetta associazione. Questa operazione viene avviata dal client. Una volta stabilita l'associazione, il client DLMS può accedere al modello di oggetto dell'interfaccia situato nel server. Una volta stabilita un'associazione, il server DLMS può inviare notifiche al client senza una richiesta esplicita.

DLMS/COSEM supporta la sincronizzazione dell'orologio e la trasmissione dei profili di misurazione. Finora il DLMS/COSEM descritto non supporta il trasferimento delle firme digitali insieme ai dati di misurazione, né supporta il download di una nuova versione del firmware. Tuttavia, questa funzionalità sarà supportata in futuro. Già ora sono disponibili gli oggetti per eseguire l'operazione di aggiornamento del firmware, descritta nel blue book 10a edizione. Il supporto per le firme digitali è in lavorazione; questo viene fatto dall'organizzazione DLMS UA.

DLMS/COSEM include servizi di autenticazione e privacy basati sulla crittografia simmetrica. Questo protocollo però non supporta TLS/SSL, con il quale i servizi sopra indicati potrebbero essere implementati utilizzando una chiave asimmetrica. Il supporto alla crittografia asimmetrica è in fase di sviluppo e viene affrontato dal secondo gruppo di lavoro del tredicesimo comitato tecnico dell'organizzazione CENELEC.

C.IEC 61850

La mappatura MMS e SOAP della norma IEC 61850 non differisce nel supportare i criteri di qualità discussi in questo documento. Pertanto tutto quanto detto di seguito varrà per entrambi i protocolli.

IEC 61850 è un gruppo di standard sviluppati appositamente per l'uso nell'automazione delle sottostazioni. Lo standard è stato ora ampliato per coprire la gestione di centrali idroelettriche, turbine eoliche e altre risorse energetiche distribuite. Il documento fa riferimento a DLMS/COSEM e ANSI C12.19 come standard applicabili alla contabilità dei trasferimenti fiscali. La norma IEC 61850 si applica laddove non sono previsti requisiti di misura fiscale. Questa differenza tra la contabilità commerciale e altri tipi di contabilità sembra essere più politica che tecnica. Perché non esiste alcun motivo tecnico per non utilizzare lo standard IEC 61850 come protocollo per la misura fiscale.

IEC 61850 funziona sugli stessi principi di architettura client-server di DLMS/COSEM. Il server contiene un modello di oggetti di interfaccia accessibile tramite servizi standardizzati. Il modo esatto in cui vengono trasferiti questi servizi dipende dal tipo di mappatura utilizzata (ad esempio, MMS o SOAP).

Il modello a oggetti dell'interfaccia IEC 61850 è costituito da dispositivi logici liberamente componibili (LD). I dispositivi logici sono costituiti da uno o più nodi logici (LN). La norma IEC 61850-7-4, per la misurazione, definisce il nodo logico MMRT. Insieme ai servizi di registrazione e/o reporting, questi nodi logici possono essere utilizzati per trasmettere i profili di carico. Le firme digitali non fanno parte del nodo logico e pertanto non sono supportate. Anche il meccanismo di aggiornamento del firmware non è supportato da questo standard. Sia la mappatura MMS che quella SOAP utilizzano il protocollo SNTP per sincronizzare l'ora.

Quando viene utilizzata la mappatura MMS, il server può inviare dati senza una richiesta esplicita, attraverso il meccanismo di reporting IEC 61850. L'associazione e quindi la connessione socket TCP aperta deve essere avviata anticipatamente dal client. La mappatura SOAP non supporta il reporting attivo da parte del server.

Né la mappatura MMS né quella SOAP dispongono di meccanismi di sicurezza integrati. Questa funzionalità è lasciata al protocollo TLS/SSL, come raccomandato in .

D. Confronto

La tabella 1 fornisce informazioni sul supporto di alcuni criteri di qualità per i protocolli in esame. La differenza principale tra il protocollo SML e gli altri due protocolli è che SML non si basa su un modello di oggetti di interfaccia e quindi non enfatizza la standardizzazione a livello funzionale. Ciò da un lato offre maggiore flessibilità nell'utilizzo del protocollo, dall'altro significa che i dettagli (ad esempio i tipi di messaggi supportati dai dispositivi) devono essere definiti in altri standard per garantire l'interoperabilità. SML è l'unico protocollo che supporta il trasferimento delle firme digitali.

Tabella 1 – Confronto tra i protocolli SML, DLMS/COSEM e IEC 61850

DLMS/COSEM ha il vantaggio rispetto a SML di essere già uno standard internazionale ampiamente utilizzato in Europa. Numerosi team stanno lavorando per aggiungere le opzioni mancanti a questo standard. Il fatto che DLMS/COSEM definisca il proprio meccanismo di sicurezza non è necessariamente un vantaggio. Poiché la funzionalità relativa alla sicurezza è limitata solo all'uso della crittografia a chiave simmetrica. Se i contatori combinassero le loro misurazioni con le firme digitali, avrebbero comunque bisogno di chiavi asimmetriche e potrebbero utilizzare le stesse coppie di chiavi per SSL/TLS, se consentito.

La IEC 61850, rispetto ad altri standard, può essere applicata non solo allo smart metering, ma anche ad altre applicazioni di smart grid. Tuttavia, al momento, non c’è abbastanza interesse nel rendere questo protocollo più funzionale per le applicazioni di misurazione intelligente.

V. Analisi delle prestazioni

Nella sezione precedente, i protocolli sono stati analizzati rispetto a criteri qualitativi. Questa sezione fornisce un'analisi dell'efficacia dei vari protocolli. In particolare viene considerato il numero totale di byte trasmessi da ciascun protocollo. In questo caso, confrontare i protocolli non è un compito banale perché tutti i protocolli supportano la trasmissione di diversi tipi di informazioni, utilizzando diverse strutture di messaggio e diversi schemi di crittografia. Per questo motivo, per il confronto dei protocolli nella sottosezione successiva, è stata selezionata un'operazione, vale a dire l'accesso in lettura istantaneo, seguita da una sottosezione sui diversi schemi di crittografia.

A. Accesso alle letture istantanee

Ottenere valori istantanei delle grandezze misurate è un’operazione fondamentale supportata da tutti i protocolli. Per questo motivo è stata scelta questa operazione come base di confronto.

Per prima cosa descriveremo il meccanismo per ottenere le letture dai dispositivi di misurazione per ciascun protocollo, quindi confronteremo le dimensioni dei loro messaggi. I quattro protocolli discussi utilizzano i seguenti metodi per accedere alle letture dei valori istantanei:

• SML definisce un messaggio di tipo GetList per ottenere valori istantanei delle grandezze misurate. Il messaggio di richiesta contiene i nomi dei parametri o elenchi di parametri da leggere. La risposta contiene l'elenco di valori richiesto. Verranno analizzati due scenari:
  • Il contatore o gateway SML è preparametrizzato con una lista di parametri che devono essere letti insieme. Pertanto, per ottenere tutti i parametri/valori associati al nome della lista, sarà sufficiente inviare al server il nome di questa lista.
  • Il contatore o il gateway non sono preparametrizzati e sono necessarie query esplicite per ottenere le letture desiderate.
• DLMS/COSEM definisce un servizio GET per ottenere valori di lettura istantanei. Get-Request può contenere un elenco dei cosiddetti descrittori di attributi COSEM, che definiscono in modo univoco i parametri esatti che devono essere letti. La risposta, in questo caso, contiene un elenco di valori di parametri senza ripetere il descrittore associato.
• La norma IEC 61850 offre servizi per la gestione e l'accesso ai cosiddetti set di dati. In questo modo, è possibile creare dinamicamente un set di dati contenente un numero arbitrario di punti dati. Successivamente il set di dati può essere ottenuto in modo abbastanza efficiente utilizzando il servizio GetDataSetValue.

Successivamente, vengono determinate le dimensioni dei messaggi delle richieste e delle risposte corrispondenti. Più precisamente, le equazioni con cui viene calcolata la dimensione della SDU TCP ( Unità dati di servizio) a seconda del numero di valori misurati richiesti. Diversi parametri nei messaggi di richiesta e di risposta hanno lunghezza variabile. Per questo motivo vengono sempre selezionati i parametri con la lunghezza più breve. Inoltre, utilizzando i protocolli in esame, è possibile richiedere un numero di dati abbastanza elevato. Pertanto, per confrontare i protocolli, verrà presa in considerazione una richiesta di valori di misurazione sotto forma di quattro byte di numeri interi. La dimensione del pacchetto è determinata in parte dall'implementazione dei protocolli di comunicazione effettivi e dall'acquisizione del traffico, e in parte utilizzando modelli analitici.

Per SML, la dimensione della SDU TCP dei messaggi di richiesta e di risposta viene calcolata come segue:

SML Req = SML TP V 1 + OpenReq + GetListReq + CloseReq + StuffedBits
Ris SML = SML TP V 1 + OpenRes + GetListRes + CloseRes + StuffedBits

SML può essere potenzialmente utilizzato con una varietà di schemi di codifica, ma in pratica viene utilizzata solo la codifica binaria SML. Per uno scenario senza parametri preparametrizzati, la dimensione di GetListReqPDU in byte da trasferire X i valori, utilizzando la codifica binaria SML, possono essere calcolati come segue:

LMS richiesto = 16 + 28 + 30x + 19 + 0
Ris. SML = 16 + 27 + 45x + 19 + 0

Per lo scenario con parametri preparametrizzati valgono le seguenti equazioni:

LMS richiesto = 16 + 28 + 30 + 19 + 0
Ris. SML = 16 + 27 + (26 + 19x) + 19 + 0

Composizione e dimensione del TCP SDU DLMS/COSEM, durante la trasmissione X valori è descritto dalle seguenti equazioni:

Richiesta DLMS = Wrapper TCP + GetReqWithList = 8 + (4 + 11x)
Ris. DLMS = Wrapper TCP + GetResWithList = 8 + (4 + 6x)

Composizione e dimensioni degli MMS TCP SDU:

MMS Req = RFC 1006 e ISO 8073 + Sessione ISO 8327 + Presentazione ISO + MMS GetListReqPDU = 7 + 4 + 9 + 44
Ris MMS = RFC 1006 e ISO 8073 + Sessione ISO 8327 + Presentazione ISO + MMS GetListResPDU = 7 + 4 + 9 + (10 + 6x)

Composizione e dimensione del TCP SDU SOAP:

Richiesta SOAP = Intestazione SOAP + Richiesta SOAP XML = 197 + 236
Ris. SOAP = Intestazione SOAP + Ris. SOAP XML = 113 + (175 + 32x)

Vengono fornite le dimensioni dei messaggi risultanti Tavolo 2. Inoltre, la dimensione del messaggio di risposta viene mostrata sotto forma di grafico figura 2. Da questa figura possiamo vedere che DLMS e MMS sono i protocolli più efficienti in termini di dimensione dei messaggi. Tuttavia, non dimenticare che DLMS e IEC 61850 richiedono un'associazione per poter scambiare messaggi. Il protocollo SML non richiede un'associazione. Per questi calcoli non si è tenuto conto delle spese generali legate alla costituzione dell'associazione. Tuttavia, possono essere trascurati se l’associazione viene costituita una volta e mantenuta per un lungo periodo di tempo.

Tabella 2 – Dimensione del campo dati TCP in byte in funzione del numero di valori richiesti (x).

Figura 2 – Dimensioni del messaggio di risposta

B. Confronto delle codifiche binarie

Tutti i protocolli, MMS, DLMS/COSEM e SML utilizzano la codifica binaria byte-byte per codificare i propri messaggi. Questa sezione confronta direttamente le codifiche.

Il protocollo MMS utilizza la codifica ASN.1 BER per codificare i messaggi. Anche DLMS/COSEM utilizza la codifica BER per i messaggi di associazione, tuttavia, una volta stabilita l'associazione, vengono utilizzate regole di codifica speciali, le cosiddette A-XDR, definite in . Le regole A-XDR sono state progettate per ridurre la quantità di informazioni rispetto a BER e vengono utilizzate solo per codificare un sottoinsieme di ASN.1. Il protocollo SML, a sua volta, definisce anche nuove regole di codifica chiamate SML Binary Encoding. L'obiettivo è lo stesso di A-XDR: ridurre la dimensione del messaggio rispetto a BER. Quando si utilizza la codifica BER, in genere è richiesto un byte per il campo del tipo di valore e un byte per il campo della lunghezza del valore codificato. Nel caso della codifica binaria SML, ove possibile, il tipo e la lunghezza vengono codificati in un byte. In A-XDR, i campi del tipo di valore e della lunghezza vengono generalmente omessi ove possibile.

Le tre codifiche binarie discusse vengono confrontate codificando il messaggio di risposta MMS GetDataValues. La tabella 3 mostra il numero di byte necessari per codificare i vari componenti di un messaggio MMS.

Tabella 3 - Confronto delle lunghezze dei messaggi per diverse codifiche (in byte)

Come si può vedere dalla Tabella 3, A-XDR richiede il minor numero di byte per codificare un pacchetto. A-XDR codifica con la stessa efficienza di BER e in alcuni casi, con l'eccezione di campi aggiuntivi non selezionati, anche meglio. La codifica binaria SML non codifica con il numero più piccolo di byte in tutti i casi. Ciò è dovuto al fatto che i tag nella selezione sono codificati con almeno due byte. Tutta l'"efficienza" della codifica binaria A-XDR e SML deriva dai campi tipo e lunghezza. I valori effettivi sono codificati in un numero uguale di byte.

VI. Conclusione

In questo lavoro sono stati identificati i criteri di qualità più significativi per il protocollo a livello applicativo utilizzato per la misurazione intelligente dei consumi. Un confronto tra i protocolli DLMS/COSEM, SML e IEC 61850 ha dimostrato che non esiste un unico protocollo che sia il migliore sotto tutti gli aspetti. L'analisi e il confronto delle dimensioni dei messaggi hanno dimostrato che DLMS e MMS IEC 61850 sono chiaramente superiori a tutti gli altri. Sia DLMS/COSEM che SML utilizzano codifiche speciali per una codifica più efficiente rispetto a BER, tuttavia la codifica binaria SML presenta svantaggi significativi durante la codifica dei tag di selezione degli elementi ASN.1. A-XDR fa un buon lavoro nel ridurre il sovraccarico causato dai campi di tipo e lunghezza.

In futuro sarebbe interessante fare un confronto simile anche per protocolli promettenti come ZigBee Smart Energy 2.0 e ANSI C12.19.

Bibliografia

1. E. Commissione, “M/441 EN, mandato di standardizzazione a CEN, CENELEC ed ETSI nel campo degli strumenti di misura per lo sviluppo di un'architettura aperta per contatori di servizi pubblici che comprenda protocolli di comunicazione che consentano l'interoperabilità”, Mar. 2009.
2. NIST, “Quadro NIST e tabella di marcia per gli standard di interoperabilità delle reti intelligenti, versione 1.0”, 2010.
3. DKE, “Die deutsche normungsroadmap E-Energy/Smart grid”, aprile 2010.
4. Gruppo S. P., “Linguaggio dei messaggi intelligenti (SML) v. 1:03", dicembre 2008.
5. "IEC 62056-53 - Scambio di dati per la lettura dei contatori, le tariffe e il controllo del carico - parte 53: Livello di applicazione COSEM", 2006.
6. "IEC 62056-62 - Scambio di dati per la lettura dei contatori, le tariffe e il controllo del carico - parte 62: Classi di interfaccia", 2006.
7. “IEC 61850-8-1 ed1.0 - reti e sistemi di comunicazione nelle sottostazioni - parte 8-1: Mappatura specifica del servizio di comunicazione (SCSM) - mappature a MMS (ISO 9506-1 e ISO 9506-2) e a ISO/IEC 8802-3", maggio 2004.
8. "IEC 61400-25-4 ed1.0 - turbine eoliche - parte 25-4: Comunicazioni per il monitoraggio e il controllo degli impianti eolici - mappatura al profilo di comunicazione", 2008.
9. K. D. Craemer e G. Deconinck, “Analisi degli standard di comunicazione all’avanguardia per la misurazione intelligente”, Leuven, 2010.
10. S. Mohagheghi, J. Stoupis, Z. Wang, Z. Li e H. Kazemzadeh, "Architettura di risposta alla domanda: integrazione nel sistema di gestione della distribuzione", in Smart Grid Communications (SmartGridComm), 2010 Prima conferenza internazionale IEEE, 2010 , pag. 501–506.
11. A. Zaballos, A. Vallejo, M. Majoral e J. Selga, "Indagine e confronto delle prestazioni di AMR rispetto agli standard PLC", Power Delivery, IEEE Transactions on, vol. 24, n. 2, pagg. 604–613, 2009.
12. T. Otani, “Una valutazione primaria per l’applicabilità della norma IEC 62056 a una rete elettrica di nuova generazione”, in Smart Grid Communications (Smart-GridComm), Prima conferenza internazionale IEEE del 2010, 2010, pp. 67–72.
13. S. Feuerhahn, M. Zillgith e C. Wittwer, "Comunicazione standardizzata dei prezzi in base al tempo di utilizzo per la gestione intelligente dell'energia nella rete di distribuzione", in VDE Kongress 2010 - E-Mobility, Lipsia, Germania, nov. 2010.
14. SyMProjectGroup, "SyM - specifiche generali per contatori modulari sincroni", ottobre 2019. 2009.
15. VDE, "Lastenheft MUC - Comunicazione multiutility, versione 1.0", maggio 2009.
16. "IEC 62056-47 - Scambio di dati per la lettura dei contatori, le tariffe e il controllo del carico - parte 47: Livelli di trasporto COSEM per reti IPv4", 2006.
17. "IEC 61850-7-410 ed1.0 - reti e sistemi di comunicazione per l'automazione dei servizi energetici - parte 7-410: Centrali idroelettriche - comunicazione per il monitoraggio e il controllo", agosto 2019. 2007.
18. "IEC 61400-25-2 ed1.0 - turbine eoliche - parte 25-2: Comunicazioni per il monitoraggio e il controllo degli impianti eolici - modelli informativi", Dec. 2006.
19. "IEC 61850-7-420 ed1.0 - reti e sistemi di comunicazione per l'automazione dei servizi energetici - parte 7-420: Struttura di comunicazione di base - nodi logici delle risorse energetiche distribuite", ottobre 2019. 2009.
20. "IEC/TS 62351-1 ed1.0 - gestione dei sistemi energetici e scambio di informazioni associate - sicurezza dei dati e delle comunicazioni - parte 1: sicurezza delle reti e dei sistemi di comunicazione - introduzione alle questioni di sicurezza", maggio 2007.
21. "openMUC - piattaforma software per gateway energetici",

Protocollo dell'evento - con parole tue

Se consideriamo l’allegoria della classe, che funziona bene, i protocolli ciclici come Modbus, Profibus, Fieldbus sono come interrogare ciascuno degli studenti in sequenza. Anche se non c'è interesse per il dispositivo (studente). I protocolli degli eventi funzionano diversamente. Viene effettuata una richiesta non a ciascun dispositivo di rete (studente) in sequenza, ma alla classe nel suo insieme, quindi le informazioni vengono raccolte dal dispositivo con uno stato modificato (studente che ha alzato la mano). Pertanto, vi è un notevole risparmio nel traffico di rete. I dispositivi di rete non accumulano errori quando la connessione è scarsa. Dato che l'invio degli eventi avviene con timestamp, anche se c'è un certo ritardo, il master del bus riceve informazioni sugli eventi che si sono verificati sugli oggetti remoti.

I protocolli di eventi vengono utilizzati principalmente negli impianti di produzione di energia, nonché nei sistemi di controllo remoto di vari sistemi gateway e spartiacque. Vengono utilizzati ovunque sia necessario l'invio remoto e il controllo di oggetti molto distanti tra loro.

Storia dello sviluppo e dell'implementazione dei protocolli di eventi nell'automazione degli impianti energetici

Un esempio di uno dei primi tentativi riusciti di standardizzare lo scambio di informazioni per i controllori industriali è il protocollo ModBus, sviluppato da Modicon nel 1979. Attualmente il protocollo esiste in tre versioni: ModBus ASCII, ModBus RTU e ModBus TCP; il suo sviluppo è portato avanti dall'organizzazione no-profit ModBus-IDA. Nonostante ModBus appartenga ai protocolli del livello applicativo del modello di rete OSI e regoli le funzioni di lettura e scrittura dei registri, la corrispondenza dei registri con i tipi di misurazione e i canali di misurazione non è regolamentata. In pratica, ciò porta all'incompatibilità dei protocolli di dispositivi di diverso tipo, anche dello stesso produttore, e alla necessità di supportare un gran numero di protocolli e le loro modifiche da parte del software USPD integrato (con un modello di polling a due livelli - software del server di raccolta) con capacità limitata di riutilizzare il codice del programma. Considerando il rispetto selettivo degli standard da parte dei produttori (l'uso di algoritmi non regolamentati per il calcolo del checksum, la modifica dell'ordine dei byte, ecc.), la situazione è ancora più aggravata. Oggi è evidente che ModBus non è in grado di risolvere il problema della separazione dei protocolli delle apparecchiature di misurazione e controllo dei sistemi energetici. La specifica DLMS/COSEM (Device Language Message SPECIFIC), sviluppata dall'Associazione degli utenti DLMS e inserita nella famiglia di standard IEC 62056, è progettata per fornire, come affermato sul sito ufficiale dell'associazione, "un ambiente interoperabile per la modellazione strutturale e i dati scambio con il responsabile del trattamento.” . La specifica separa il modello logico e la rappresentazione fisica delle apparecchiature specializzate e definisce inoltre i concetti più importanti (registro, profilo, pianificazione, ecc.) e le operazioni su di essi. La norma principale è la IEC 62056-21, che ha sostituito la seconda edizione della IEC 61107.
Nonostante uno studio più approfondito del modello di rappresentazione del dispositivo e del suo funzionamento rispetto a ModBus, purtroppo permane il problema della completezza e della “purezza” dell'implementazione dello standard: in pratica, interrogando un dispositivo con supporto dichiarato per DLMS di un produttore con un programma di polling di un altro produttore è limitato ai parametri di base o semplicemente impossibile. Va notato che la specifica DLMS, a differenza del protocollo ModBus, si è rivelata estremamente impopolare tra i produttori nazionali di dispositivi di misurazione, principalmente a causa del maggiore complessità del protocollo, nonché costi generali aggiuntivi per stabilire una connessione e ottenere la configurazione del dispositivo.
Il pieno supporto degli standard esistenti da parte dei produttori di apparecchiature di misurazione e controllo non è sufficiente per superare la disunità delle informazioni all’interno del sistema. Il supporto per un particolare protocollo standardizzato dichiarato dal produttore, di norma, non significa il suo pieno supporto e l'assenza di modifiche introdotte. Un esempio di un insieme di norme straniere è la famiglia di norme IEC 60870-5 creata dalla Commissione Elettrotecnica Internazionale.
Diverse implementazioni della norma IEC 60870-5-102 - uno standard generale per il trasferimento di parametri integrali nei sistemi di alimentazione - sono presentate in dispositivi di numerosi produttori stranieri: Iskraemeco d.d. (Slovenia), Landis&Gyr AG (Svizzera), Circutor SA (Spagna), EDMI Ltd (Singapore), ecc., ma nella maggior parte dei casi solo come ulteriori. Come principali protocolli di trasferimento dati vengono utilizzati protocolli proprietari o variazioni del DLMS. Vale la pena notare che la norma IEC 870-5-102 non è ampiamente utilizzata per un altro motivo: alcuni produttori di dispositivi di misurazione, compresi quelli domestici, hanno implementato protocolli telemeccanici modificati nei loro dispositivi (IEC 60870-5-101, IEC 60870-5 - 104), ignorando tale norma.

Una situazione simile si osserva tra i produttori di protezione relè e automazione: in presenza dell'attuale standard IEC 60870-5-103, viene spesso implementato un protocollo simile a ModBus. Il prerequisito per questo, ovviamente, era la mancanza di supporto per questi protocolli da parte della maggior parte dei sistemi di livello superiore. Qualora sia necessario integrare la telemeccanica e i sistemi di misurazione dell'energia elettrica, è possibile utilizzare i protocolli telemeccanici descritti nelle norme IEC 60870-5-101 e IEC 60870-5-104. A questo proposito, hanno trovato ampia applicazione nei sistemi di dispacciamento.

Specifiche Tecniche del Protocollo di Automazione

Nei moderni sistemi di automazione, a seguito della costante modernizzazione della produzione, si incontrano sempre più spesso i compiti di costruire reti industriali distribuite utilizzando protocolli di trasferimento dati basati su eventi. Per organizzare le reti industriali di impianti energetici, vengono utilizzate molte interfacce e protocolli di trasferimento dati, ad esempio IEC 60870-5-104, IEC 61850 (MMS, GOOSE, SV), ecc. Sono necessari per il trasferimento dei dati tra sensori, controller e attuatori (AM), collegamenti tra i livelli inferiore e superiore del sistema automatizzato di controllo del processo.

I protocolli sono sviluppati tenendo conto delle specificità del processo tecnologico, garantendo una connessione affidabile e un'elevata precisione del trasferimento dei dati tra vari dispositivi. Oltre al funzionamento affidabile in condizioni difficili, la funzionalità, la flessibilità nella progettazione, la facilità di integrazione e manutenzione e la conformità agli standard industriali stanno diventando requisiti sempre più importanti nei sistemi di controllo dei processi automatizzati. Diamo un'occhiata alle caratteristiche tecniche di alcuni dei protocolli sopra indicati.

Protocollo IEC 60870-5-104

La norma IEC 60870-5-104 formalizza l'incapsulamento dell'ASDU dalla norma IEC 60870-5-101 nelle reti TCP/IP standard. Sono supportate sia le connessioni Ethernet che quelle modem che utilizzano il protocollo PPP. La sicurezza dei dati crittografici è formalizzata nello standard IEC 62351. La porta standard è TCP 2404.
Questa norma specifica l'utilizzo di un'interfaccia TCP/IP aperta per una rete contenente, ad esempio, una LAN (rete locale) per un dispositivo di telecontrollo che trasmette ASDU secondo IEC 60870-5-101. I router, compresi i router per WAN (wide area network) di vario tipo (ad esempio X.25, Frame Relay, ISDN, ecc.), possono essere collegati tramite un'interfaccia comune TCP/IP-LAN.

Esempio di architettura applicativa generale della norma IEC 60870-5-104

L'interfaccia del livello di trasporto (l'interfaccia tra l'utente e TCP) è un'interfaccia orientata al flusso che non definisce alcun meccanismo di avvio-arresto per l'ASDU (IEC 60870-5-101). Per definire l'inizio e la fine di un'ASDU, ciascuna intestazione APCI include i seguenti contrassegni: un carattere iniziale, un'indicazione della lunghezza dell'ASDU, insieme a un campo di controllo. È possibile trasmettere l'APDU completo o (a fini di controllo) solo i campi APCI.

Struttura del pacchetto dati del protocollo IEC 60870-5-104

In cui:

APCI - Informazioni sul controllo del livello di applicazione;
- ASDU - Unità dati. Mantenuto dal livello dell'applicazione (blocco dati del livello dell'applicazione);
- APDU - Unità dati del protocollo del livello di applicazione.
- START 68 N definisce il punto di partenza all'interno del flusso di dati.
La lunghezza dell'APDU specifica la lunghezza del corpo dell'APDU, che consiste dei quattro byte del campo di controllo APCI più l'ASDU. Il primo byte conteggiato è il primo byte del campo di controllo e l'ultimo byte conteggiato è l'ultimo byte dell'ASDU. La lunghezza massima dell'ASDU è limitata a 249 byte perché La lunghezza massima del campo APDU è 253 byte (APDUmax=255 meno 1 byte iniziale e 1 byte di lunghezza) e la lunghezza del campo di controllo è 4 byte.
Questo protocollo di trasferimento dati è attualmente il protocollo di dispacciamento standard di fatto per le imprese del settore dell'energia elettrica. Il modello di dati contenuto in questo standard è più sviluppato, ma non fornisce alcuna descrizione unificata dell'impianto energetico.

Protocollo DNP-3

DNP3 (Distributed Network Protocol) è un protocollo di trasferimento dati utilizzato per la comunicazione tra componenti ICS. È stato progettato per una comoda interazione tra diversi tipi di dispositivi e sistemi di controllo. Può essere utilizzato a vari livelli di sistemi di controllo del processo automatizzato. Esiste un'estensione Secure Authentication per DNP3 per l'autenticazione sicura.
In Russia, questo standard è scarsamente distribuito, ma alcuni dispositivi di automazione lo supportano ancora. Per molto tempo il protocollo non è stato standardizzato, ma ora è stato approvato come standard IEEE-1815. DNP3 supporta sia le comunicazioni seriali RS-232/485 che le reti TCP/IP. Il protocollo descrive tre livelli del modello OSI: applicazione, collegamento dati e fisico. La sua caratteristica distintiva è la capacità di trasferire dati sia da un dispositivo master a un dispositivo slave, sia tra dispositivi slave. DNP3 supporta anche il trasferimento sporadico di dati da dispositivi slave. La trasmissione dei dati si basa, come nel caso della IEC-101/104, sul principio della trasmissione di una tabella di valori. In questo caso, per ottimizzare l'utilizzo delle risorse di comunicazione, non viene inviato l'intero database, ma solo la sua parte variabile.
Una differenza importante tra il protocollo DNP3 e ​​quelli discussi in precedenza è il tentativo di descrivere oggettivamente il modello dati e l'indipendenza degli oggetti dati dai messaggi trasmessi. Per descrivere la struttura dei dati in DNP3, viene utilizzata una descrizione XML del modello informativo. DNP3 si basa su tre livelli del modello di rete OSI: applicazione (opera con oggetti di tipi di dati di base), canale (fornisce diversi modi per recuperare i dati) e fisico (nella maggior parte dei casi vengono utilizzate le interfacce RS-232 e RS-485) . Ogni dispositivo ha il proprio indirizzo univoco per una determinata rete, rappresentato come un numero intero compreso tra 1 e 65520. Termini di base:
- Outslation: dispositivo slave.
- Master - dispositivo principale.
- Frame (frame) - pacchetti trasmessi e ricevuti a livello di collegamento dati. La dimensione massima del pacchetto è 292 byte.
- Dati statici: dati associati a un valore reale (ad esempio, un segnale discreto o analogico)
- Dati evento - dati associati a qualsiasi evento significativo (ad esempio, cambiamenti di stato, raggiungimento di una soglia di un valore). C'è un'opzione per allegare un timestamp.
- Variazione (variazione) - determina come viene interpretato il valore, caratterizzato da un numero intero.
- Gruppo (gruppo) - definisce il tipo di valore, caratterizzato da un numero intero (ad esempio, un valore analogico costante appartiene al gruppo 30 e un valore analogico di evento al gruppo 32). A ciascun gruppo viene assegnata una serie di variazioni, con l'aiuto delle quali vengono interpretati i significati di questo gruppo.
- Oggetto: dati del frame associati a un valore specifico. Il formato dell'oggetto dipende dal gruppo e dalla variazione.
Di seguito è riportato un elenco delle varianti.

Variazioni per dati costanti:

Variazioni per i dati degli eventi:

I flag implicano la presenza di un byte speciale con i seguenti bit di informazione: la sorgente dati è in linea, la sorgente dati è stata riavviata, la connessione alla sorgente è stata persa, il valore è stato forzato per essere scritto, il valore non è consentito limiti.

Intestazione del frame:

Sincronizzazione - 2 byte di sincronizzazione che consentono al destinatario di identificare l'inizio del frame. Lunghezza: il numero di byte nel resto del pacchetto, esclusi gli ottetti CRC. Controllo della connessione: un byte per coordinare la ricezione di una trasmissione di frame. Indirizzo di destinazione: l'indirizzo del dispositivo a cui è assegnato il trasferimento. Indirizzo di origine: l'indirizzo del dispositivo che esegue la trasmissione. CRC: checksum per il byte di intestazione. La sezione dati del frame DNP3 contiene (oltre ai dati stessi) 2 byte di CRC per ogni 16 byte di informazione trasmessa. Il numero massimo di byte di dati (escluso CRC) per un frame è 250.

Protocollo MMS IEC 61850

MMS (Manufacturing Message Specifica) è un protocollo di trasferimento dati che utilizza la tecnologia client-server. Lo standard IEC 61350 non descrive il protocollo MMS. Il capitolo IEC 61850-8-1 descrive solo come assegnare i servizi dati descritti dallo standard IEC 61850 al protocollo MMS descritto dallo standard ISO/IEC 9506. Per comprendere meglio cosa significa, è necessario dare uno sguardo più da vicino su come lo standard IEC 61850 descrive i servizi di comunicazione astratti e cosa fanno.
Una delle idee principali racchiuse nello standard IEC 61850 è che non cambia nel tempo. Per garantire ciò, i capitoli della norma descrivono successivamente dapprima le questioni concettuali del trasferimento di dati all'interno e tra impianti elettrici, poi viene descritta la cosiddetta "interfaccia di comunicazione astratta" e solo nella fase finale lo scopo dei modelli astratti per i protocolli di trasferimento dati è descritto.

Pertanto, le questioni concettuali e i modelli astratti sono indipendenti dalle tecnologie di trasmissione dei dati utilizzate (canali cablati, ottici o radio) e pertanto non richiederanno revisioni causate dai progressi nel campo delle tecnologie di trasmissione dei dati.
Interfaccia di comunicazione astratta descritta dalla norma IEC 61850-7-2. include sia una descrizione dei modelli dei dispositivi (cioè standardizza i concetti di “dispositivo logico”, “nodo logico”, “blocco di controllo”, ecc.). e una descrizione dei servizi di trasferimento dati. Uno di questi servizi è SendGOOSEMessage. Oltre al servizio specificato, vengono descritti più di 60 servizi che standardizzano la procedura per stabilire la comunicazione tra il client e il server (Associate, Abort, Release), leggendo il modello informativo (GetServerDirectory, GelLogicalDeviceDirectory, GetLogicalNodeDirectory), leggendo i valori delle variabili ​​(GetAllDataValues, GetDataValues, ecc.), trasferimento di valori variabili sotto forma di report (Report) e altri. Il trasferimento dei dati nei servizi elencati viene effettuato utilizzando la tecnologia client-server.

Ad esempio, in questo caso il server può essere un dispositivo di protezione relè e il client può essere un sistema SCADA. I servizi di lettura del modello informativo consentono al client di leggere il modello informativo completo dal dispositivo, ovvero di ricreare un albero di dispositivi logici, nodi logici, elementi e attributi di dati. In questo caso, il cliente riceverà una descrizione semantica completa dei dati e della loro struttura. I servizi per la lettura dei valori delle variabili consentono di leggere i valori effettivi degli attributi dei dati, ad esempio mediante polling periodico. Il servizio di reportistica consente di configurare l'invio di determinati dati al verificarsi di determinate condizioni. Una variante di tale condizione potrebbe essere un cambiamento di vario tipo associato a uno o più elementi del set di dati. Per implementare i modelli astratti di trasmissione dati descritti, lo standard IEC 61850 descrive l'assegnazione di modelli astratti a un protocollo specifico. Per i servizi in esame tale protocollo è l'MMS, descritto dallo standard ISO/IEC 9506.

L'MMS definisce:
- un insieme di oggetti standard su cui vengono eseguite operazioni che devono esistere nel dispositivo (ad esempio: lettura e scrittura di variabili, segnalazione di eventi, ecc.),
- una serie di messaggi standard. che vengono scambiati tra il cliente e il nord per effettuare operazioni di gestione;
- un insieme di regole per codificare questi messaggi (ovvero, come valori e parametri vengono assegnati a bit e byte durante la trasmissione);
- un insieme di protocolli (regole per lo scambio di messaggi tra dispositivi). Pertanto, MMS non definisce i servizi applicativi che, come abbiamo già visto, sono definiti dallo standard IEC 61850. Inoltre, il protocollo MMS stesso non è un protocollo di comunicazione, definisce solo messaggi che devono essere trasmessi su una rete specifica. MMS utilizza lo stack TCP/IP come protocollo di comunicazione.

Di seguito viene presentata la struttura generale dell'utilizzo del protocollo MMS per l'implementazione dei servizi di trasferimento dati secondo IEC 61850.


Diagramma del trasferimento dati tramite protocollo MMS

Un sistema così complesso, a prima vista, consente in definitiva, da un lato, di garantire l'immutabilità dei modelli astratti (e, di conseguenza, l'immutabilità della norma e dei suoi requisiti), dall'altro di utilizzare i moderni tecnologie di comunicazione basate sul protocollo IP. Va tuttavia notato che, a causa dell’elevato numero di assegnazioni, il protocollo MMS è relativamente lento (ad esempio rispetto a GOOSE), quindi il suo utilizzo per applicazioni in tempo reale non è pratico. Lo scopo principale del protocollo MMS è implementare le funzioni di un sistema automatizzato di controllo del processo, ovvero la raccolta di dati di telesegnalazione e telemisurazione e la trasmissione di comandi di telecontrollo.
Allo scopo di raccogliere informazioni, il protocollo MMS fornisce due funzionalità principali:
- raccolta dati mediante polling periodico del(i) server(i) da parte del client;
- trasferimento dei dati al client da parte del server sotto forma di report (sporadici).
Entrambi questi metodi sono richiesti quando si imposta e si utilizza un sistema di controllo di processo automatizzato; per determinare le aree della loro applicazione, daremo uno sguardo più da vicino ai meccanismi operativi di ciascuno.
Nella prima fase viene stabilita una connessione tra i dispositivi client e server (il servizio “Associazione”). La connessione viene avviata dal client contattando il server utilizzando il suo indirizzo IP.

Meccanismo di trasferimento dati client-server

Il passo successivo è che il client richiede determinati dati al server e riceve una risposta dal server con i dati richiesti. Ad esempio, dopo aver stabilito una connessione, un client può richiedere al server il proprio modello informativo utilizzando i servizi GetServerDirectory, GetLogicalDeviceDirectory, GetLogicalNodeDiretory. Le richieste verranno effettuate in sequenza:
- dopo una richiesta GetServerDirectory, il server restituirà un elenco di dispositivi logici disponibili.
- dopo una richiesta GelLogicalDeviceDirectory separata per ciascun dispositivo logico, il server restituirà un elenco di nodi logici in ciascuno dei dispositivi logici.
- La richiesta GetLogicalNodeDirectory per ogni singolo nodo logico restituisce i suoi oggetti e attributi di dati.
Di conseguenza, il client calcola e ricrea il modello informativo completo del dispositivo server. In questo caso i valori effettivi degli attributi non verranno ancora letti, ovvero l'“albero” letto conterrà solo i nomi dei dispositivi logici, dei nodi logici, degli oggetti dati e degli attributi, ma senza i loro valori. Il terzo passo può essere quello di leggere i valori effettivi di tutti gli attributi dei dati. In questo caso è possibile leggere tutti gli attributi utilizzando il servizio GetAllDataValues ​​oppure solo singoli attributi utilizzando il servizio GetDataValues. Al completamento della terza fase, il client ricreerà completamente il modello informativo del server con tutti i valori degli attributi dei dati. Va notato che questa procedura comporta lo scambio di volumi di informazioni abbastanza grandi con un gran numero di richieste e risposte, a seconda del numero di dispositivi logici dei nodi logici e del numero di oggetti dati implementati dal server. Ciò porta anche ad un carico piuttosto elevato sull'hardware del dispositivo. Questi passaggi possono essere eseguiti nella fase di impostazione del sistema SCADA in modo che il cliente, dopo aver letto il modello informativo, possa accedere ai dati sul server. Tuttavia, durante l'ulteriore funzionamento del sistema, non è richiesta la lettura regolare del modello informativo. È inoltre inappropriato leggere costantemente i valori degli attributi utilizzando il polling regolare. In alternativa è possibile utilizzare il servizio di reportistica Report. La norma IEC 61850 definisce due tipi di report: bufferizzati e non bufferizzati. La differenza principale tra un report bufferizzato e uno non bufferizzato è che quando si utilizza il primo, le informazioni generate verranno consegnate al client anche se nel momento in cui il server è pronto per emettere il report non esiste alcuna connessione tra questo e il report. client (ad esempio, il canale di comunicazione corrispondente è stato interrotto). Tutte le informazioni generate vengono accumulate nella memoria del dispositivo e verranno trasferite non appena verrà ripristinata la connessione tra i due dispositivi. L'unica limitazione è la quantità di memoria del server allocata per l'archiviazione dei report. Se durante quel periodo di tempo in cui non c'era connessione si verificavano molti eventi che causavano la generazione di un gran numero di rapporti, il cui volume totale superava la quantità consentita di memoria del server, alcune informazioni potrebbero comunque andare perse e i nuovi report generati “sposteranno” i dati precedentemente generati dal buffer, tuttavia, in questo caso, il server, attraverso un attributo speciale del blocco di controllo, segnalerà al client che si è verificato un overflow del buffer ed è possibile una perdita di dati. Se esiste una connessione tra il client e il server - sia quando si utilizza un report tamponato che quando si utilizza un report non bufferizzato - il trasferimento dei dati al client può essere immediato al verificarsi di determinati eventi nel sistema (a condizione che il tempo intervallo per il quale vengono registrati gli eventi, è pari a zero). Quando si tratta di report, non intendiamo monitorare tutti gli oggetti e gli attributi dei dati del modello informativo del server, ma solo quelli che ci interessano, combinati nei cosiddetti “set di dati”. Utilizzando un report bufferizzato/non bufferizzato, è possibile configurare il server non solo per trasmettere l'intero set di dati monitorato, ma anche per trasmettere solo quegli oggetti/attributi di dati con cui si verificano determinati tipi di eventi entro un intervallo di tempo definito dall'utente.
Per fare ciò, nella struttura del blocco di controllo per la trasmissione dei report tamponati e non, è possibile specificare categorie di eventi, il cui verificarsi deve essere monitorato e, in base ai quali, solo quegli oggetti dati /gli attributi interessati da questi eventi verranno inclusi nel rapporto. Si distinguono le seguenti categorie di eventi:
- modifica dei dati (dchg). Quando imposti questa opzione, il report includerà solo gli attributi dei dati i cui valori sono cambiati o solo gli oggetti dati i cui valori degli attributi sono cambiati.
- modifica dell'attributo di qualità (qchg). Impostando questa opzione, il report includerà solo gli attributi di qualità i cui valori sono cambiati o solo gli oggetti dati i cui attributi di qualità sono cambiati.
- aggiornamento dei dati (dupd). Quando imposti questo parametro, il report includerà solo gli attributi di dati i cui valori sono stati aggiornati o solo gli oggetti di dati i cui valori di attributo sono stati aggiornati. Per aggiornamento intendiamo, ad esempio, il calcolo periodico dell'una o dell'altra componente armonica e la registrazione del suo nuovo valore nell'attributo dati corrispondente. Tuttavia, anche se il valore basato sui risultati del calcolo per il nuovo periodo non è cambiato, l'oggetto dati o l'attributo dati corrispondente viene incluso nel report.
È inoltre possibile configurare il report per riportare l'intero set di dati monitorati. Tale trasferimento può essere effettuato sia su iniziativa del server (condizione di integrità) sia su iniziativa del client (interrogazione generale). Se la generazione dei dati viene inserita in base alla condizione di integrità, l'utente deve anche indicare il periodo per la generazione dei dati da parte del server. Se la generazione dei dati viene inserita in base alla condizione di interrogazione generale. il server genererà un report con tutti gli elementi del set di dati alla ricezione del comando corrispondente dal client.
Il meccanismo di trasmissione dei report presenta importanti vantaggi rispetto al metodo di polling periodico: il carico sulla rete informatica è significativamente ridotto, il carico sul processore del dispositivo server e del dispositivo client è ridotto e la consegna rapida dei messaggi sugli eventi che si verificano nel sistema è assicurato. Tuttavia, è importante notare che tutti i vantaggi derivanti dall'utilizzo di report bufferizzati e non bufferizzati possono essere ottenuti solo se configurati correttamente, il che, a sua volta, richiede qualifiche sufficientemente elevate e una vasta esperienza da parte del personale che esegue la configurazione delle apparecchiature.
Oltre ai servizi descritti, il protocollo MMS supporta anche modelli di controllo delle apparecchiature: la formazione e la trasmissione di registri di eventi, nonché il trasferimento di file, che consente di trasferire, ad esempio, file di oscillogrammi di emergenza. Questi servizi richiedono una considerazione separata. Il protocollo MMS è uno dei protocolli a cui possono essere assegnati i servizi astratti descritti dalla norma IEC 61850-7-2. Allo stesso tempo, l’emergere di nuovi protocolli non influenzerà i modelli descritti dallo standard, garantendo così che lo standard rimanga invariato nel tempo. Per assegnare modelli e servizi al protocollo MMS si utilizza il capitolo IEC 61850-8-1. Il protocollo MMS fornisce vari meccanismi per la lettura dei dati dai dispositivi, inclusa la lettura dei dati su richiesta e la trasmissione dei dati sotto forma di report dal server al client. A seconda del compito da risolvere, è necessario selezionare il meccanismo di trasmissione dei dati corretto e devono essere effettuate le impostazioni appropriate, che consentiranno di utilizzare efficacemente l'intero set di protocolli di comunicazione dello standard IEC 61850 presso l'impianto elettrico.

Protocollo GOOSE IEC 61850

Il protocollo GOOSE, descritto nel capitolo IEC 61850-8-1, è uno dei protocolli più conosciuti previsti dallo standard IEC 61850. L'abbreviazione GOOSE - Generic Object-Oriented Substation Event - può essere tradotta letteralmente come “general object-oriented evento in una sottostazione”. Tuttavia, in pratica, non dovresti attribuire molta importanza al nome originale, poiché non dà alcuna idea del protocollo stesso. È molto più conveniente intendere il protocollo GOOSE come un servizio progettato per scambiare segnali tra dispositivi di protezione relè in forma digitale.

Generazione di messaggi GOOSE

Il modello dati dello standard IEC 61850 specifica che i dati devono essere formati in insiemi - Dataset. I set di dati vengono utilizzati per raggruppare i dati che verranno inviati da un dispositivo utilizzando il meccanismo di messaggio GOOSE. Successivamente, il blocco di controllo di invio GOOSE specifica un collegamento al set di dati creato, nel qual caso il dispositivo sa quali dati inviare. Va notato che all'interno di un messaggio GOOSE è possibile inviare sia un valore (ad esempio un segnale di avvio della protezione da sovracorrente) sia diversi valori contemporaneamente (ad esempio un segnale di avvio e un segnale di protezione da sovracorrente, ecc.). Il dispositivo ricevente, allo stesso tempo, può estrarre dal pacchetto solo i dati di cui ha bisogno. Il pacchetto di messaggi GOOSE trasmesso contiene tutti i valori attuali degli attributi dei dati inclusi nel set di dati. Quando uno qualsiasi dei valori degli attributi cambia, il dispositivo inizia immediatamente a inviare un nuovo messaggio GOOSE con i dati aggiornati.

Trasmissione OCAmessaggi

Secondo il suo scopo, il messaggio GOOSE è destinato a sostituire la trasmissione di segnali discreti sulla rete corrente operativa. Consideriamo quali requisiti sono imposti al protocollo di trasferimento dati. Per sviluppare un'alternativa ai circuiti di trasmissione del segnale tra dispositivi di protezione a relè, sono state analizzate le proprietà delle informazioni trasmesse tra dispositivi di protezione a relè tramite segnali discreti:
- piccola quantità di informazioni: i valori "vero" e "falso" (o "zero" e "uno" logici) vengono effettivamente trasmessi tra i terminali;
- è richiesta un'elevata velocità di trasferimento delle informazioni - la maggior parte dei segnali discreti trasmessi tra la protezione relè e i dispositivi di automazione influenzano direttamente o indirettamente la velocità di eliminazione della modalità anomala, pertanto la trasmissione del segnale deve essere effettuata con un ritardo minimo;
- è richiesta un'elevata probabilità di consegna del messaggio - per implementare funzioni critiche, come l'emissione di un comando per spegnere l'interruttore dal sistema di protezione e automazione del relè, lo scambio di segnali tra la protezione del relè e le apparecchiature di automazione quando si eseguono funzioni distribuite, è necessario garantire la consegna garantita del messaggio sia nella normale modalità di funzionamento della rete di trasmissione digitale dei dati sia in caso di guasti a breve termine;
- la possibilità di trasmettere messaggi a più destinatari contemporaneamente - quando si implementano alcune funzioni distribuite di protezione e automazione dei relè, è richiesto il trasferimento dei dati da un dispositivo a più dispositivi contemporaneamente;
- è necessario monitorare l'integrità del canale di trasmissione dati - la presenza di una funzione diagnostica sullo stato del canale di trasmissione dati consente di aumentare il fattore di disponibilità durante la trasmissione del segnale, aumentando così l'affidabilità della funzione svolta con la trasmissione del messaggio specificato.

I requisiti presentati hanno portato allo sviluppo di un meccanismo di messaggi GOOSE che soddisfa tutti i requisiti. Nei circuiti di trasmissione del segnale analogico, il ritardo principale nella trasmissione del segnale è causato dal tempo di risposta dell'uscita discreta del dispositivo e dal tempo di filtraggio del rimbalzo sull'ingresso discreto del dispositivo ricevente. In confronto il tempo di propagazione del segnale lungo il conduttore è breve.
Allo stesso modo, nelle reti di dati digitali, il ritardo principale è causato non tanto dalla trasmissione del segnale sul supporto fisico, ma dalla sua elaborazione all'interno del dispositivo. Nella teoria delle reti di trasmissione dati, è consuetudine segmentare i servizi di trasmissione dati secondo i livelli del modello OSI, di norma, scendendo dall'“Applicazione”, cioè il livello di presentazione dei dati applicati, al “Fisico”, ovvero il livello di interazione fisica dei dispositivi. Nella visione classica, il modello OSI ha solo sette livelli: fisico, collegamento dati, rete, trasporto, sessione, presentazione e applicazione. Tuttavia, i protocolli implementati potrebbero non avere tutti i livelli specificati, ovvero alcuni livelli potrebbero essere saltati.
Il meccanismo di funzionamento del modello OSI può essere chiaramente illustrato utilizzando l'esempio del trasferimento di dati durante la visualizzazione di pagine WEB su Internet su un personal computer. Il contenuto delle pagine viene trasferito su Internet utilizzando HTTP (Hypertext Transfer Protocol), che è un protocollo a livello di applicazione. Il trasferimento dei dati HTTP viene solitamente effettuato dal protocollo di trasporto TCP (Transmission Control Protocol). I segmenti del protocollo TCP sono incapsulati nei pacchetti del protocollo di rete, che in questo caso è IP (protocollo Internet). I pacchetti TCP comprendono frame di protocollo del livello di collegamento Ethernet, che possono essere trasmessi utilizzando diversi livelli fisici a seconda dell'interfaccia di rete. Pertanto, i dati della pagina visualizzata su Internet attraversano almeno quattro livelli di trasformazione quando formano una sequenza di bit a livello fisico, e quindi lo stesso numero di passaggi di trasformazione inversa. Questo numero di conversioni porta a ritardi sia durante la formazione di una sequenza di bit ai fini della loro trasmissione, sia durante la conversione inversa per ottenere i dati trasmessi. Di conseguenza, per ridurre i tempi di ritardo, il numero di trasformazioni dovrebbe essere mantenuto al minimo. Questo è il motivo per cui i dati tramite il protocollo GOOSE (livello applicazione) vengono assegnati direttamente al livello di collegamento dati - Ethernet, bypassando altri livelli.
In generale, il capitolo IEC 61850-8-1 prevede due profili di comunicazione che descrivono tutti i protocolli di trasferimento dati previsti dalla norma:
- Profilo “MMS”;
- Profilo “Non MMS” (ovvero non MMS).
Di conseguenza, i servizi di trasferimento dati possono essere implementati utilizzando uno dei profili specificati. Il protocollo GOOSE (così come il protocollo Sampled Values) si riferisce specificatamente al secondo profilo. L'utilizzo di uno stack "accorciato" con un numero minimo di trasformazioni è un modo importante, ma non l'unico, per accelerare il trasferimento dei dati. L'uso di meccanismi di prioritizzazione dei dati aiuta anche ad accelerare il trasferimento dei dati tramite il protocollo GOOSE. Pertanto, per il protocollo GOOSE viene utilizzato un identificatore di frame Ethernet separato: Ethertype, che ovviamente ha una priorità più elevata rispetto ad altro traffico, ad esempio trasmesso utilizzando il livello di rete IP. Oltre ai meccanismi sopra descritti, il telegramma Ethernet GOOSE può essere dotato anche di etichette di priorità IEEE 802.1Q. nonché etichette di rete locale virtuale del protocollo ISO/IEC 8802-3. Tali etichette consentono di aumentare la priorità dei frame durante l'elaborazione da parte degli switch di rete. Questi meccanismi per aumentare la priorità saranno discussi più dettagliatamente nelle pubblicazioni successive.

L'utilizzo di tutti i metodi considerati ci consente di aumentare significativamente la priorità dei dati trasmessi tramite il protocollo GOOSE rispetto ad altri dati trasmessi sulla stessa rete utilizzando altri protocolli, riducendo così al minimo i ritardi sia durante l'elaborazione dei dati all'interno dei dispositivi delle sorgenti e dei ricevitori dati, sia così come e quando elaborati dagli switch di rete.

Invio di informazioni a più destinatari

Per indirizzare i frame a livello di collegamento vengono utilizzati gli indirizzi fisici dei dispositivi di rete - indirizzi MAC. Allo stesso tempo Ethernet consente la cosiddetta messaggistica di gruppo (Multicast). In questo caso l'indirizzo multicast è indicato nel campo dell'indirizzo MAC del destinatario. Per le trasmissioni multicast che utilizzano il protocollo GOOSE, viene utilizzato un determinato intervallo di indirizzi.

Intervallo di indirizzi multicast per i messaggi GOOSE

I messaggi con il valore “01” nel primo ottetto dell'indirizzo vengono inviati a tutte le interfacce fisiche della rete, quindi di fatto il multicast non ha destinatari fissi, e il suo indirizzo MAC è piuttosto un identificatore del broadcast stesso, e non puntano direttamente ai suoi destinatari.

Pertanto l'indirizzo MAC di un messaggio GOOSE può essere utilizzato, ad esempio, quando si organizza il filtraggio dei messaggi su uno switch di rete (filtro MAC) e l'indirizzo indicato può anche servire come identificatore su cui possono essere configurati i dispositivi riceventi.
Pertanto, la trasmissione di messaggi GOOSE può essere paragonata a una trasmissione radiofonica: il messaggio viene trasmesso a tutti i dispositivi della rete, ma per poter ricevere e successivamente elaborare il messaggio, il dispositivo ricevente deve essere configurato per ricevere questo messaggio.


Schema di trasmissione dei messaggi GOOSE

La trasmissione di messaggi a più destinatari in modalità Multicast, nonché i requisiti per elevate velocità di trasferimento dati, non consentono di ricevere conferme di consegna dai destinatari durante la trasmissione di messaggi GOOSE. La procedura di invio dei dati, generazione di un riconoscimento da parte del dispositivo ricevente, ricezione ed elaborazione da parte del dispositivo mittente e quindi reinvio se il tentativo fallisce richiederebbe troppo tempo, il che potrebbe portare a ritardi eccessivi nella trasmissione di segnali critici. Invece, è stato implementato un meccanismo speciale per i messaggi GOOSE per garantire un'elevata probabilità di consegna dei dati.

Innanzitutto, in assenza di modifiche negli attributi dei dati trasmessi, i pacchetti con messaggi GOOSE vengono trasmessi ciclicamente ad un intervallo specificato dall'utente. La trasmissione ciclica dei messaggi GOOSE consente di diagnosticare costantemente la rete informatica. Un dispositivo configurato per ricevere un messaggio attende che arrivi a intervalli specificati. Se il messaggio non arriva entro il tempo di attesa, il dispositivo ricevente può generare un segnale di malfunzionamento nella rete informatica, avvisando così il dispatcher dei problemi sorti.
In secondo luogo, quando uno degli attributi del set di dati trasmesso cambia, indipendentemente da quanto tempo è trascorso dall'invio del messaggio precedente, viene generato un nuovo pacchetto che contiene i dati aggiornati. Dopodiché l'invio di questo pacchetto viene ripetuto più volte con un ritardo minimo, quindi l'intervallo tra i messaggi (se non ci sono modifiche nei dati trasmessi) aumenta nuovamente al massimo.


Intervallo tra l'invio di messaggi GOOSE

In terzo luogo, il pacchetto di messaggi GOOSE contiene diversi campi contatore, che possono essere utilizzati anche per monitorare l'integrità del canale di comunicazione. Tali contatori includono, ad esempio, il contatore di invio ciclico (sqNum), il cui valore varia da 0 a 4.294.967.295 o finché non cambiano i dati trasmessi. Ad ogni modifica dei dati trasmessi nel messaggio GOOSE, il contatore sqNum verrà azzerato e anche un altro contatore, stNum, verrà incrementato di 1, anch'esso cambiando ciclicamente nell'intervallo da 0 a 4.294.967.295. Pertanto, se vengono persi più pacchetti durante la trasmissione, questa perdita può essere monitorata utilizzando due contatori specifici.

Infine, in quarto luogo, è anche importante notare che il messaggio GOOSE, oltre al valore del segnale discreto stesso, può contenere anche un segno della sua qualità, che identifica uno specifico guasto hardware del dispositivo fonte di informazioni, sia che le informazioni il dispositivo sorgente è in modalità test e si verificano una serie di altre condizioni anomale. Pertanto, il dispositivo ricevente, prima di elaborare i dati ricevuti secondo gli algoritmi forniti, può verificare questo attributo di qualità. Quanto sopra può impedire il funzionamento errato dei dispositivi di ricezione delle informazioni (ad esempio, il loro falso funzionamento).
Va tenuto presente che alcuni dei meccanismi integrati per garantire l'affidabilità della trasmissione dei dati, se utilizzati in modo errato, possono portare a un effetto negativo. Pertanto, se l'intervallo massimo tra i messaggi viene scelto troppo breve, il carico sulla rete aumenta, sebbene, dal punto di vista della disponibilità del canale di comunicazione, l'effetto della riduzione dell'intervallo di trasmissione sarà estremamente insignificante.
Quando gli attributi dei dati cambiano, la trasmissione dei pacchetti con un ritardo minimo provoca un aumento del carico sulla rete (modalità “tempesta di informazioni”), che teoricamente può portare a ritardi nella trasmissione dei dati. Questa modalità è la più complessa e va considerata come calcolata quando si progetta una rete informatica. Tuttavia, è necessario comprendere che il carico di picco è molto breve e la sua diminuzione multipla, secondo i nostri esperimenti in laboratorio per studiare la compatibilità funzionale dei dispositivi che funzionano secondo i termini della norma IEC 61850, viene osservata ad un intervallo di 10 ms.

Quando si realizzano sistemi di protezione a relè basati sul protocollo GOOSE, cambiano le procedure per la loro regolazione e test. Ora la fase di installazione consiste nell'organizzare la rete Ethernet dell'impianto elettrico. che comprenderà tutti i dispositivi di protezione relè. tra i quali è richiesto lo scambio di dati. Per verificare che il sistema sia configurato e abilitato secondo i requisiti di progetto, diventa possibile utilizzare un personal computer con appositi software preinstallati (Wireshak, GOOSE Monitor, ecc.) o apposite apparecchiature di test che supportano il protocollo GOOSE (PETOM 61850. Omicron CMC). È importante notare che tutti i controlli possono essere effettuati senza interrompere i collegamenti prestabiliti tra le apparecchiature secondarie (dispositivi di protezione a relè, interruttori, ecc.), poiché lo scambio dati avviene tramite la rete Ethernet. Quando si scambiano segnali discreti tra dispositivi di protezione a relè in modo tradizionale (applicando tensione all'ingresso discreto del dispositivo ricevente quando si chiude il contatto di uscita del dispositivo che trasmette i dati), al contrario, è spesso necessario interrompere le connessioni tra i apparecchiature secondarie da includere nel circuito degli impianti di prova per verificare la correttezza dei collegamenti elettrici e la trasmissione dei corrispondenti segnali discreti. Pertanto, il protocollo GOOSE prevede tutta una serie di misure volte a garantire le caratteristiche necessarie di velocità e affidabilità nella trasmissione di segnali critici. L'uso di questo protocollo in combinazione con la corretta progettazione e parametrizzazione della rete informativa e dei dispositivi di protezione relè consente, in alcuni casi, di abbandonare l'uso di circuiti in rame per la trasmissione del segnale, garantendo al contempo il livello richiesto di affidabilità e prestazioni.

#MMS, #GOOSE, #SV, #870-104, #evento, #protocollo, #scambio

Eccolo: Protocollo MMS-1000 contro l'HIV/AIDS e altre malattie:

♦ Prendi 3 gocce di MMS attivato, aggiungi succo o acqua e prendi una volta ogni ora, 8 ore consecutive ogni giorno per 3 settimane.

♦ È meglio iniziare con 1 o 2 gocce all'ora, nelle prime ore,

♦ Per una persona molto malata, è meglio iniziare con mezza goccia all'ora per le prime ore.

♦ Aumentare il numero di gocce all'ora nella misura in cui il paziente lo tollera, ma non superare mai le 3 gocce all'ora.

♦ Se si verificano vomito o diarrea, interrompere le dosi orarie finché non scompaiono, quindi ricominciare con una dose inferiore.

♦ In caso di nausea, ridurre immediatamente la dose, ma finché la nausea è tollerabile, non interrompere l'assunzione dell'MMS.

Potete assumere la vostra dose di MMS in due modi. Assicurati di farlo in una tazza o un bicchiere pulito e asciutto.

1. Utilizzare una soluzione di acido citrico al 50% e aggiungere una goccia per ogni goccia di MMS. Chiacchiera un po', attendi 20 secondi, aggiungi mezza tazza di acqua o succo (che non contiene vitamina C supplementare, ma è possibile utilizzare vitamina C naturale) e bevilo.

2. Utilizzare una soluzione di acido citrico al 10% (o succo di limone o lime) e aggiungere 5 gocce per ogni goccia di MMS. Agitare un po', attendere tre minuti, aggiungere un quarto di tazza di acqua o succo (che non contiene vitamina C supplementare, ma è possibile utilizzare vitamina C naturale) e berlo.

Non utilizzare il succo d'arancia. La maggior parte dei succhi dovrebbero andare bene purché non contengano vitamina C. Anche l'acqua tonica è adatta. Il succo d'arancia e l'aggiunta di vitamina C prevengono gli effetti dell'MMS.

Se non hai il succo o semplicemente non vuoi usarlo, usa invece un bicchiere pieno d'acqua (8 once). Quindi non dovresti poterlo assaggiare.

Protocollo MMS 1000 contro l'HIV/AIDS

Questo protocollo è valido per tutti i casi di HIV/AIDS e molte altre malattie in cui la persona non è attualmente in pericolo di vita e in cui le restano ancora settimane o mesi ma alla fine diventerà pericolosa per la vita.

Il Protocollo MMS-1000 è anche una procedura di super pulizia, forse la più efficace fino ad oggi. Le persone che hanno eseguito la procedura sono diventate sane e, per la maggior parte, felici. Devi essere qui in Africa per vederlo. Una volta completato il Protocollo 1000, le persone raggiungono una salute eccellente. Penso che non sia possibile trovare un solo medico che possa dire di non essere sano e, secondo me, le persone sane sono spesso felici. Vorrei davvero che tu potessi vederlo. I risultati di queste persone superano di gran lunga i risultati che qualsiasi programma di disintossicazione o digiuno che ho visto può produrre. Ad oggi sono 800 i guariti con un solo test, più tanti altri nel mondo. Molti sono stati testati negli ospedali locali e sono tutti sani.