Comunicazione ridondante in tempo reale per un rete elettrica affidabile

La rete elettrica è una risorsa vitale oggi nel mondo. La sua affidabilità è di primaria importanza, specialmente con l'aumentare dell'uso della generazione elettrica distribuita e l'introduzione di "microreti" che richiedono più intelligenza locale in termini di monitoraggio e controllo. Tutti i sistemi in rete devono cooperare per garantire una fornitura stabile e costante di corrente alternata tramite analisi frequenti di tensione, frequenza e stato delle sottostazioni. Questa necessità punta ad avvalersi dell'uso del monitoraggio avanzato e di comunicazioni facilmente disponibili e a bassa latenza tra centri di controllo e nodi ad alto valore come le sottostazioni per garantire che lo stato di ogni sottosistema sia strettamente monitorato.

Per aiutare a gestire l'infrastruttura di rete e offrire il necessario livello di controllo e comunicazione, l'industria della distribuzione elettrica ha adottato lo standard IEC 61580. Sulla base di IEC 61580, sono usati dei segnali digitali che trasmettono informazioni sullo stato dell'energia tra sottostazioni e sottosistemi elettrici attraverso una rete basata sulla tecnologia Ethernet. Per rispondere alle crescenti e complesse esigenze degli operatori di reti elettriche, lo standard IEC 61580 si è evoluto per includere numerosi servizi time-critical, come la sincronizzazione IEEE 1588, Generic Object Oriented System Event (GOOSE) e la messaggistica Sampled Value (SV).

Figura 1: Diagramma degli elementi chiave di IEC 61580 e relazioni con Ethernet.

Il protocollo GOOSE supporta il modello di messaggio publisher/subscriber, più adatto per applicazioni a controllo distribuito rispetto al modello di comunicazioni tradizionale client-server usato in molti sistemi IT. IEC 61580 rende disponibili i messaggi client-server separatamente per supportare la gestione di dispositivi da stazioni remote e altre situazioni in cui un nodo in una sottostazione o una microrete richiede che vi si possa accedere direttamente.

GOOSE permette messaggi in tempo reale sullo stato di vari parametri elettrici che devono essere riportati a qualsiasi dispositivo abbia necessità di usarli. Ogni relè, ad esempio, pubblica informazioni usando un singolo identificatore per ogni diverso tipo di oggetto che contiene e per il quale deve riportare lo stato. Altri relè e dispositivi possono sottoscrivere lo stream dei messaggi sullo stato inviati dal relè target. Ciò viene eseguito usando una combinazione di multicasting attraverso la rete e filtraggio sui nodi riceventi: il publisher non richiede di sapere chi sono i subscriber o se questi ricevono il messaggio. Per offrire le prestazioni massime, GOOSE non usa il protocollo TCP/IP comunemente utilizzato. I messaggi GOOSE vengono invece inseriti direttamente nei frame Ethernet (livello Data Link). In modo simile, la messaggistica SV offre un modo di effettuare il multicasting dei dati ai ricevitori sottoscrittori per i valori che cambiano rapidamente, ad esempio la misurazione della tensione.

I servizi forniti sulla base di IEC 61580 includono la sincronizzazione temporale secondo lo standard IEEE 1588. Questo standard distribuisce i segnali di temporizzazione da un grandmaster clock ad alta precisione. In molti sistemi odierni, il grandmaster clock si avvale dei segnali orari trasmessi dai satelliti del Global Positioning System (GPS) che sono dotati di orologio atomico. Il grandmaster clock alimenta un albero di orologi slave che sono o classificati come orologi periferici (situati in gateway che possono agire temporaneamente come master se il segnale GPS è assente) o come orologi normali che risiedono in ogni sistema che richiede la sincronizzazione. Le informazioni orarie si propagano lungo l'albero usando una serie di scambi di messaggi che devono essere ripetuti a intervalli regolari per assicurare che tutti i sistemi restino sincronizzati.

Il protocollo funziona con un master clock che invia agli slave un messaggio di sincronizzazione contenente un indicatore di data e ora. Subito dopo invia un seguito contenente un indicatore di data e ora successivo. Lo slave risponde con un messaggio che chiede al master una stima del ritardo, al quale il master risponde con l'orario che gli è stato inviato. Alla fine del processo, lo slave avrà quattro indicazioni orarie, tre delle quali inviate dal master. Usando le informazioni temporali in sequenza, lo slave determina l'aggiustamento necessario al suo clock interno per regolarlo nel modo più preciso possibile su quello del master. Il protocollo determina una sincronizzazione temporale che, in una LAN, ha una precisione tipica entro le decine di nanosecondi.

Altre parti chiave dell'infrastruttura secondo IEC 61580 sono i protocolli di trasmissione dei dati ridondanti. Standardizzato in IEC 62439, il Parallel Redundancy Protocol (PRP) supporta comunicazioni Ethernet dual-port full-duplex. Il protocollo prevede la gestione di due stream di pacchetti ridondanti sotto l'interfaccia del layer MAC vista dai protocolli di applicazioni del layer superiore come GOOSE e SV. Tipicamente, le connessioni Ethernet avvengono attraverso diversi switch Ethernet e prevedono una topologia di rete con cablaggio a stella.

Figura 2: Il protocollo di ridondanza PRP presume una topologia di cablaggio a stella.

Un'alternativa è High-availability Seamless Redundancy (HSR), anch'essa definita in IEC 62439. HSR utilizza una topologia ad anello e ogni pacchetto viene duplicato e inviato in direzioni opposte sull'anello verso la destinazione. L'architettura ad anello evita la necessità di adottare ulteriori switch/router al prezzo di un aumento del ritardo se i pacchetti devono superare molti nodi per raggiungere la destinazione. I controller avanzati di comunicazione possono aiutare a minimizzare questo ritardo con l'uso della spedizione cut-through. Questo approccio non richiede che un pacchetto sia totalmente decodificato prima che inizi l'invio alla destinazione.

Figura 3: Il protocollo di ridondanza HSR è studiato per una topologia ad anello.

Data la necessità di ampio filtraggio dei messaggi Ethernet entranti, IEC 61580 richiede un'elaborazione ad alte prestazioni che può ridurre la quantità di potenza di calcolo disponibile per controllare gli algoritmi. Una risposta è quella di scaricare (offload) quanto più possibile l'analisi a livello di rete in modo che il processore host debba trattare solo i messaggi che richiedono la sua attenzione. Ciò può essere fatto su SoC multicore, alcuni dei quali contengono processori di rete intelligenti specializzati. Un esempio è il microprocessore embedded AM572x Sitara di Texas Instruments. È disponibile una scheda di valutazione che permette di esplorare facilmente le sue funzionalità di rete.

AM572x è basato su un processore ARM® Cortex®-A15. Il dispositivo multicore potenzia il processore host con un Cortex-M4 che può essere usato per attività intensiva di I/O di offload. Sono inclusi anche due processori di rete assieme a un processore di segnale digitale basato su architettura C66x per eseguire l'analisi dei dati. Il sottosistema PRU-ICSS su AM572x offre elaborazione separata oltre a quella disponibile nel core ARM. L'unità contiene due PRU, ciascuna dotata di processore RISC a 32 bit in grado di operare fino a 200 MHz, oltre a un'interfaccia di rete. La disponibilità di due core intelligenti indipendenti offre supporto immediato ai protocolli PRP e HSR.

Il processore RISC nel core della PRU non ha un'architettura generalista. Al contrario, questo core è specificamente progettato per la manipolazione dei tipi di strutture dei dati mappati in memoria e impacchettati che incontra nei frame di rete. Incorpora numerose funzioni per il supporto di applicazioni con stretti vincoli in tempo reale. In parte il filtraggio del pacchetto può essere eseguito nei processori della PRU. Su AM572x, è disponibile più spazio dal Cortex-M4 per protocolli come IEEE 1588, GOOSE e SV.

Il core Cortex-M4 può essere utilizzato per analizzare tutti i pacchetti multicast entranti e confrontare i loro indirizzi di Application ID (APPID) per vedere se hanno una sottoscrizione valida fornita dal software in esecuzione nel Cortex-A15. Da questo M4 è possibile stabilire quali messaggi hanno bisogno di essere passati a monte. Gli altri pacchetti possono essere scaricati ed eliminati dalla memoria.

Figura 4: L'IPC a memoria condivisa supporta l'offload dell'elaborazione IEC 61580 al Cortex-M4 e ad altri processori.

In questa architettura con elaborazione offloaded, un aspetto chiave è la modalità con cui i singoli processori comunicano tra loro. AM572x offre memoria condivisa per facilitare il passaggio dei messaggi da un processore a un altro. I pacchetti possono essere rapidamente formati in code in modo da poter essere scritti e letti in sequenza. La domanda chiave è quale protocollo utilizzare. Un'opzione è quella di usare Linux su Cortex-A15. Ciò consente l'utilizzo delle interfacce standard di programmazione delle applicazioni (API) che il sistema operativo offre per le comunicazioni tra processi, ad esempio remoteproc e rpmsg.

Il sistema di messaggistica rpmsg funziona fornendo un dispositivo virtuale che rispecchia ogni canale di comunicazione collegato a un processo remoto. I canali sono identificati da un nome testuale ed hanno un indirizzo rpmsg locale e un indirizzo rpmsg remoto. Quando un driver inizia l'ascolto su un canale, la funzione di callback usata per la ricezione è legata a un indirizzo locale esclusivo rpmsg a 32 bit. Quando arriva un messaggio in entrata, il core rpmsg lo spedisce al driver appropriato in base al suo indirizzo di destinazione. Questi messaggi vengono ripetuti chiamando l'handler di ricezione del driver e fornendo insieme il payload del messaggio in entrata. Tramite questo schema, il codice di filtraggio per messaggi GOOSE e SV può passare messaggi con indirizzi specifici APPID a diversi handler in esecuzione su Cortex-A15. In alternativa, possono essere raggruppati tutti per essere ripetuti a un processore di messaggi comune e ordinati nel processore host.

La libreria open-source IPC3.x disponibile dal Git repository di TI implementa il software per supportare l'uso di rpmsg tra l'ambiente Linux e TI RTOS disponibile per core Cortex-M4 e DSP. Offrendo le stesse API sui dispositivi TI, il prodotto IPC compendia il supporto specifico per dispositivo per gli spinlock hardware, mailbox inter-processore e messaggi compatibili rpmsg che passano attraverso l'API MessageQ.

Conclusione

Grazie al multiprocessing con supporto per la trasmissione di messaggi, i dispositivi come AM572x possono supportare in modo efficiente protocolli di controllo complessi in tempo reale come quelli studiati per compiti mission-critical di gestione dell'infrastruttura della rete elettrica.