IEC 61850, Sottostazioni digitali e Smart Grid
Autori: Niclas Wetterstrand e Andrea Bonetti
La norma IEC 61850 è stata lanciata nel 2003 come standard per le sottostazioni digitali ed è ampiamente utilizzata in tali applicazioni. In linea di principio, tuttavia, la Smart Grid è solo un sistema di sottostazioni elettriche distribuito a livello regionale, quindi la norma IEC 61850 è molto rilevante anche per la Smart Grid e, di fatto, l'IEC l'ha designata come uno degli standard principali della smart grid.
Per scoprire cosa sta facendo Megger in relazione alla norma IEC 61850, Electrical Tester ha organizzato una chiacchierata tra Niclas Wetterstrand, direttore del settore di Megger per la protezione, e Andrea Bonetti, Senior Specialist per la protezione dei relè e per la norma IEC 61850 presso Megger Sweden.
NICLAS: Da quanto tempo Megger lavora con le sottostazioni digitali e la smart grid?
ANDREA: Megger ha una lunga storia di lavoro relativamente alla norma IEC 61850. Abbiamo iniziato nel 2008 con lo sviluppo di GOOSER e MGC (Megger GOOSE Configurator) per i quali abbiamo ottenuto un brevetto per alcuni concetti chiave all'avanguardia, come il confronto dei dati di rete con i dati tecnici (SCL) e il punto di accesso sicuro che impedisce la connessione di un PC alla rete di comunicazione della sottostazione. GOOSER è stato commercializzato per la prima volta nel 2009 e ora è fuori produzione. La sua funzionalità tuttavia è integrata nei set di test per relè delle nostre gamme SMRT e FREJA 5xx. Per applicazioni con barra di distribuzione di processo (Sampled Values), nel 2010 abbiamo implementato la norma IEC 61850-9-2 LE (Light Edition) quando abbiamo partecipato a un progetto di messa in servizio in America Centrale. Nel corso degli anni, la norma IEC 61850 è passata dall'edizione 1 alla 2, e ora all'edizione 2.1 (che non è in realtà una nuova edizione onnicomprensiva, un aspetto che ho spiegato ai lettori di ET nel primo numero di questa rivista). In Megger, il nostro compito è seguire lo standard e incorporare i nuovi concetti nei nostri strumenti hardware e software.
N: Ho sentito molto parlare del certificato KEMA. Può spiegare cos'è e come si relaziona con i prodotti Megger?
R: Il cosiddetto "certificato KEMA" per la norma IEC 61850 è in realtà un report di test di un istituto accreditato, in questo caso KEMA (l'attuale CESI), sebbene ce ne siano altri. Il certificato conferma un certo livello di conformità allo standard IEC 61850 in termini di interoperabilità e, poiché è prodotto da un istituto accreditato indipendente, è noto come certificato di "Livello A".
Anche il certificato di "Livello B" conferma l'interoperabilità, ma è rilasciato da un istituto accreditato non indipendente, ad esempio i laboratori Hitachi Energy IEC 61850 in Svizzera. È prassi comune eseguire i test per la prima versione di un prodotto al Livello A, e le successive piccole modifiche o migliorie al Livello B. Megger dispone di certificati "KEMA Livello A" per GOOSE e Sampled Values. È noto che i certificati da soli non garantiscono la completa interoperabilità. Se un progetto IEC 61850 deve funzionare senza problemi, sono necessari ulteriori test e una buona specifica da parte dell'utente finale. La certificazione è un requisito minimo che dimostra che il produttore ha fatto ciò che è ragionevolmente possibile per fornire un prodotto o uno strumento conforme alla norma IEC 61850.
N: Ha menzionato GOOSE e Sampled Values. Sarebbe corretto affermare che la norma IEC 61850 è un nuovo protocollo o una nuova serie di protocolli di comunicazione?
R: Questa è probabilmente la domanda più comune sulla norma IEC 61850 e la risposta più semplice è che è molto più di una serie di protocolli. La norma IEC 61850 si basa su tre pilastri: Standard Signal List, Standard Information Exchange e Standard System Engineering.
N: Da quanto discusso finora, mi aspetterei che GOOSE e Sampled Values siano parte dello Standard Information Exchange. Può fare alcuni esempi per gli altri due pilastri e su come si relazionano l'uno con l'altro?
R: Ha ragione, i protocolli standardizzati fanno parte dello Standard Information Exchange. Prima di procedere, tuttavia, ci sono altri piccoli aspetti da considerare.
L'elenco Standard Signal List fornisce un approccio standardizzato per la modellazione del sistema, dell'apparecchiatura e dei segnali associati al sistema e all'apparecchiatura. E lo fa definendo le "funzioni elementari" denominate nodi logici (LN) insieme ai loro segnali, ovvero oggetti dati (DO) e attributi dati (DA), e le loro descrizioni, nel linguaggio di configurazione del sistema (SCL).
Un'idea chiave è che se abbiamo un file SCL master che descrive il sistema, descrive anche il traffico dati che lo attraversa. Un'altra importante idea è che possiamo considerare il file SCL come l'impronta della comunicazione nella sottostazione.
N: Qual è il vantaggio di avere i tre pilastri invece di un semplice protocollo di comunicazione dati?
R: Devo ammettere che stiamo ponendo la stessa domanda da molti anni! La risposta è che il concetto dei tre pilastri è incredibilmente solido e a prova di futuro. Alcune persone lo hanno persino descritto come bello! Per comprenderne i vantaggi, tuttavia, sono necessari alcuni esempi. Torniamo al file SCL che, come ho detto, può essere considerato come una descrizione del sistema e del traffico dati che lo attraversa. Se siamo in grado di rilevare e misurare questo traffico dati con uno strumento, talvolta chiamato "sniffing" dei dati, possiamo confrontarlo con la descrizione SCL master e, in caso di differenze, segnalarle inviando avvisi. Questa idea inizialmente è nata a causa della necessità di identificare i problemi di interoperabilità nelle sottostazioni. Non scenderemo nei dettagli, ma è ancora utilizzata in questo modo. Un'altra possibilità, come abbiamo già detto, è considerare il file SCL come l'impronta della comunicazione nella sottostazione. Come prospettiva, ho esposto una presentazione introduttiva su questi concetti all'IEEE GPECOM nel 2020. In un'ora di presentazione, penso di aver menzionato i protocolli di comunicazione solo per pochi minuti!
N: Interessante, ma non si tratta in realtà di un vero e proprio test dei relè, giusto?
R: No, va ben oltre! Lo standard, grazie alla sua struttura a tre pilastri, apre un'intera gamma di possibilità che aspettano solo di essere sviluppate. Una su cui Megger sta lavorando dall'inizio del 2009 è il confronto del modello di dati, descritto dallo standard, con il traffico di dati effettivo, sotto forma di messaggi GOOSE, nella sottostazione. Ancora una volta, per questo concetto pionieristico, Megger ha ottenuto il brevetto.
Ciò è possibile perché la norma IEC 61850 è molto più di uno standard sui protocolli: offre un modo per descrivere l'impianto elettrico. Questa descrizione viene formalizzata nel linguaggio SCL ed è disponibile nei file SCL. Megger ha brevettato alcuni algoritmi correlati che consentono il confronto di SCL GOOSE con i messaggi GOOSE di rete. Poiché il file SCL è un'impronta della comunicazione nella sottostazione, l'idea è di confrontare periodicamente la comunicazione effettiva con l'impronta master (di riferimento). Tale confronto fornisce una base eccellente per lo sviluppo di routine di manutenzione automatiche. Megger ha scritto diversi documenti su questi concetti, oltre ad aver collaborato con l'Istituto Reale di Tecnologia di Stoccolma (KTH) per una tesi importante sugli stessi argomenti:
N: Per fare questo confronto, dobbiamo essere in grado di leggere i messaggi GOOSE nelle sottostazioni e i messaggi GOOSE nel file SCL. È corretto?
R: Sì! Lo strumento preposto a questo scopo è chiamato sniffer GOOSE. Si tratta di un dispositivo collegato al bus Ethernet della sottostazione e in grado di leggere in modo trasparente (passivamente) il traffico, senza inviare dati al sistema. Lo sniffer GOOSE di Megger fa parte del software Megger GOOSE Configurator (MGC). Questo software è anche in grado di leggere i file SCL, quindi abbiamo uno strumento in grado di funzionare senza problemi con i messaggi GOOSE dalla rete e dal file SCL.
N: Intende dire che posso andare alla sottostazione, leggere tutti i messaggi GOOSE e importarli dal file SCL della sottostazione?
R: Sì! Supponiamo, ad esempio, che ci siano 500 messaggi GOOSE dalla sottostazione. Dovremmo aspettarci di trovare anche 500 messaggi dal file SCL. Dovremmo aspettarci che i messaggi di queste due serie siano equivalenti. O, per dirla in un altro modo, dovremmo aspettarci che i messaggi della sottostazione siano conformi alla descrizione fornita nel file SCL.
N: Ha degli esempi per spiegare perché potrebbero esserci delle differenze?
R: Nell'ingegneria raramente le cose sono perfette! Purtroppo, nella fase di messa in servizio è improbabile che si disponga di una sola versione del file SCL. Fornitori diversi lavoreranno sulle proprie versioni del file, che useranno per programmare i loro dispositivi. Se il file SCL finale non è completamente aggiornato con le informazioni più recenti, o se ci sono dispositivi non programmati correttamente, ci saranno delle differenze tra i messaggi della sottostazione e il file SCL.
Ad esempio, in una situazione pratica, un relè potrebbe essere fuori servizio. I messaggi GOOSE provenienti da quel relè scompaiono dalla rete, ma si trovano ancora nel file SCL. Pertanto, saranno presenti solo 80 messaggi della sottostazione, ma 85 messaggi nel file SCL. Oppure qualcuno potrebbe aver modificato alcuni relè, pur dicendo il contrario quando gli viene chiesto. Un controllo rapido mostrerà se è vero. Oppure uno switch Ethernet potrebbe essere stato sostituito con un nuovo switch con impostazioni differenti. Ciò significa che le VLAN sono ora diverse, generando errori e avvisi.
N: Quali sono i problemi riscontrati sul campo confrontando i messaggi della sottostazione e del file SCL?
R: I problemi finora identificati includono switch Ethernet sostituiti con le impostazioni errate, il che significa che alcuni messaggi GOOSE sono scomparsi mentre altri hanno perso il tag VLAN. Ho anche visto IED riconfigurati, il che significa che alcuni messaggi delle sottostazioni non si sono uniti (ossia, "erano diversi") a causa di una diversa revisione della configurazione (ConfRev); IED fuori servizio o scollegati, il che significa che alcuni messaggi GOOSE delle sottostazioni sono scomparsi, e ancora, ulteriori IED inseriti, che facevano comparire nuovi messaggi delle sottostazioni indicanti che il file SCL non era stato aggiornato come previsto. Ho persino visto una situazione in cui l'integratore di sistema ha fornito al cliente quello che avrebbe dovuto essere il file SCL di fabbricazione. Tuttavia, solo cinque minuti di test hanno rivelato enormi differenze tra il traffico GOOSE e il file SCL: il file SCL non rifletteva la sottostazione!
N: In che misura è importante avere la descrizione corretta della sottostazione nel file SCL?
R: È molto importante perché il file SCL è la documentazione di base per la risoluzione dei problemi quando si verifica un evento imprevisto. Inoltre, è la documentazione di base per il retrofit. Se il file SCL non descrive la sottostazione, l'intero concetto IEC 61850 crolla. Molti servizi di pubblica utilità insistono per un controllo comparativo del file SCL di fabbricazione e del traffico di rete durante il test di accettazione in fabbrica (FAT) e il test di accettazione in loco (SAT). Un file SCL errato si traduce in nessuna accettazione e nessun pagamento! A proposito, quando il file SCL descrive la sottostazione, viene chiamato file SCD (descrizione della configurazione della sottostazione).
N: Quindi, il test di accettazione in fabbrica è ancora un'altra applicazione del metodo del test di confronto?
R: Sì, ed è un'applicazione importante. Nelle mani dell'utente finale, un test di confronto è uno strumento potente che consente di determinare la presenza o meno di discrepanze. Se sono presenti, devono essere esaminate e risolte.
Alcuni anni fa, stavo erogando una sessione di formazione IEC 61850 per Megger. Ho spiegato come testare i relè e poi ho affermato che ogni utente Megger ha accesso al metodo di test di confronto, anche se potrebbe non essere a conoscenza di quello che potrebbe farci. Il giorno successivo, su dieci partecipanti ne sono tornati solo due. Quando ho chiesto informazioni sugli altri, chiedendo se avevano avuto un problema di sottostazione importante poiché erano tutti dipendenti di servizi di pubblica utilità, mi è stato detto che, a seguito della mia presentazione, erano tutti in giro a controllare i loro file SCL!
N: Cosa succede se riceviamo, ad esempio, dieci avvisi di differenza da un test di confronto? Cosa dovremmo fare in tal caso?
R: Dipende dalla situazione. Se si tratta di un test di accettazione in fabbrica, potrebbe essere sufficiente scrivere un rapporto sugli avvisi per rifiutare l'approvazione del file SCL. In alternativa, è possibile partecipare all'indagine per scoprire perché si sono verificate le differenze. Se utilizzato correttamente, lo strumento Megger è in grado di identificare le differenze nel confronto. Ciò può essere molto difficile da determinare manualmente, quindi il risparmio di tempo può essere enorme. Lo strumento non è in grado di risolvere le differenze, ma può individuarle.
N: Tutto questo sembra essere molto costoso.
R: In effetti no. Ogni utente Megger ha accesso al metodo di confronto, poiché il software MGC per IEC 61850 è incluso come standard con le apparecchiature di test Megger. Ma molti utenti Megger non si rendono conto di averlo! Questo metodo, lo ammetto, ha bisogno di un certo livello di competenza in relazione alla norma IEC 61850, che va oltre il "test dei relè", ma una volta fatta l'abitudine, non è fantascienza. Ciononostante, sarebbe molto più efficace se i test di confronto potessero essere eseguiti automaticamente come una sorta di monitoraggio continuo. Inoltre, ho notato che altri di recente hanno adottato questo concetto di confronto manuale che abbiamo introdotto sul mercato nel 2009.
N: Quali sono i vantaggi dei test di confronto automatici?
R: Stiamo parlando di procedure di autosorveglianza, routine di manutenzione automatiche, manutenzione basata su eventi e simili. Il vantaggio di implementarle è che aumentano notevolmente la disponibilità del sistema rispetto all'uso di procedure di test manuali periodiche.
N: In che modo questi concetti sono correlati alla smart grid?
R: Direi che una delle principali associazioni è il costo. Nessuno vuole pagare un test periodico su un sistema che funziona ancora correttamente. Da un lato, vogliamo avere la migliore disponibilità possibile e dall'altro un sistema semplice ed economico, che fornisca allarmi automatici quando è necessario riparare qualcosa. Lo sviluppo di procedure di manutenzione automatiche aiuterà quindi lo sviluppo della Smart Grid in tutte le aree della società, anche nelle nostre case.
N: Ma al momento non abbiamo un sistema automatico...
R: Esatto, al momento è manuale, ma abbiamo tutte le competenze necessarie per implementarlo. Quello di cui Megger ha bisogno è un cliente disponibile, sensibile a questi argomenti e disposto a collaborare con noi per implementare test di confronto automatici come un progetto smart grid.
N: Grazie Andrea, per aver trovato il tempo di partecipare a questa intervista. È stato interessante e stimolante. E spero che riceviate risposte positive in merito alla vostra ricerca di un partner che collaborerà con voi per sviluppare le vostre idee. Inoltre, vorrei aggiungere che saremmo lieti di ricevere commenti su questa intervista e, qualora i lettori di ET avessero delle domande, di inviarcele tramite l'editor ([email protected]).
