Servizi

L’architettura software è composta da diversi servizi per ciascun attore (TSO, Aggregatore, Customer).

L’architettura software è composta da diversi servizi per ciascun attore (TSO, Aggregatore, Customer): ciascuno può essere eseguito in modo indipendente dagli altri. L’interazione tra servizi che fanno riferimento al medesimo attore avviene per mezzo del database real-time Redis, che in questo contesto viene utilizzato come uno strumento per lo scambio di messaggi. L’interazione tra servizi che fanno riferimento ad attori diversi viene invece implementata secondo il protocollo di comunicazione previsto da quella interfaccia, che in alcuni casi può essere definito a livello normativo (per esempio nell’interazione TSO-Aggregatore) oppure lasciato alla scelta dell’implementatore (per esempio nell’interazione tra Aggregatore-Customer). In quest’ultimo caso sono state implementate più soluzioni alternative, in particolare l’interfaccia prevista dalla norma CEI 0-16 (basata su protocollo IEC 61850) e un’interfaccia basata su protocollo IEC 61870-104 (in analogia a quanto previsto nella comunicazione tra TSO e Aggregatore). Le seguenti sezioni descrivono più in dettaglio i singoli servizi software che sono stati implementati, suddivisi per attore di competenza.

Servizi associati al TSO

Questo attore include i seguenti servizi:

  1. terna_meas_receiver: implementa un master per il protocollo IEC 60870-104, il quale si collega tramite protocollo TCP (usando la porta 2404 come default) al corrispondente servizio aggregator_meas_producer al fine di raccoglierne le misure aggregate. Tali misure devono pervenire a Terna dall’Aggregatore con periodo di 4 secondi e in conformità all’allegato A.42 del codice di rete Terna. Le misure ricevute vengono memorizzate nel database Redis, diventando in questo modo disponibili agli altri servizi associati all’attore Terna.
  2. terna_dashboard_backend: implementa un semplice server HTTP che fornisce l’interfaccia grafica per lo svolgimento della simulazione, implementata mediante tecnologia HTML5.
  3. terna_dashboard_frontend: è l’interfaccia grafica vera e propria, che comprende alcune parti codificate in linguaggio Javascript. In particolare viene gestito l’aggiornamento in tempo reale delle misure rese disponibili dal backend e l’invio verso l’aggregatore di un nuovo file comandi. Quest’ultimo viene inviato tramote protocollo HTTP al servizio aggregator_cmd_receiver.

Servizi associati all’Aggregatore

Questo attore include i seguenti servizi:

  1. aggregator_meas_producer: implementa uno slave per il protocollo IEC 60870-104, il quale accetta connessioni TCP (usando la porta 2404 come default) da un master (in particolare, dal servizio terna_meas_receiver) al fine di inviare le misure aggregate disponibili ogni 4 secondi. Le misure hanno la struttura descritta nell’allegato A.42 del codice di rete Terna e vengono calcolate sulla base delle misure dei singoli Customer lette dal database Redis. Quest’ultimo viene popolato dai singoli servizi di interfaccia (aggregator_customer_interface_CEI016 e aggregator_customer_interface_60870).
  2. aggregator_cmd_receiver: implementa un server HTTP per la ricezione dei file comandi da Terna. I file ricevuti vengono memorizzati nel database Redis, diventando in questo modo disponibili agli altri servizi associati all’attore Aggregatore.
  3. aggregator_customer_scheduler: implementa la logica di schedulazione dei Customer a fronte della ricezione di comandi da Terna. I comandi vengono letti dal database Redis, in cui sono scritti dal servizio aggregator_cmd_receiver. A sua volta la schedulazione prodotta da questo servizio viene scritta in Redis, diventando in questo modo disponibili agli altri servizi associati all’attore Aggregatore.
  4. aggregator_dashboard_backend: implementa un semplice server HTTP che fornisce l’interfaccia grafica per lo svolgimento della simulazione, implementata mediante tecnologia HTML5.
  5. aggregator_dashboard_frontend: è l’interfaccia grafica vera e propria, che comprende alcune parti codificate in linguaggio Javascript. In particolare vengono visualizzati i comandi ricevuti dal TSO e le conseguenti schedulazioni prodotte per i Customer.
  6. aggregator_customer_interface_CEI016: implementa un client IEC 61850 per l’invio di set-point di potenza e raccolta di misure verso Customer che presentano un’interfaccia conforme alla norma CEI 0-16 (servizio customer_interface_CEI016). I set-point di potenza vengono letti dal database Redis, dove sono stati scritti dal servizio aggregator_customer_scheduler e viceversa le misure lette tramite IEC 61850 vengono scritte in Redis, diventando in questo modo disponibili agli altri servizi associati all’attore Aggregatore.
  7. aggregator_customer_interface_60870: implementa un master per il protocollo IEC 60870-104, il quale si collega tramite protocollo TCP (usando la porta 2405 come default) al corrispondente servizio customer_interface_60870 al fine di raccoglierne le misure e inviare set-point di potenza. I set-point di potenza vengono letti dal database Redis, dove sono stati scritti dal servizio aggregator_customer_scheduler e viceversa le misure lette tramite IEC 60870-104 vengono scritte in Redis, diventando in questo modo disponibili agli altri servizi associati all’attore Aggregatore.

Servizi associati al Customer

Questo attore è implementato in due varianti: con interfaccia IEC 61850 (conforme al profilo previsto dalla norma CEI 0-16) e con interfaccia IEC 60870-104 (in analogia a quanto previsto per lo scambio dati tra Aggregatore e Terna). A parte le diverse interfacce di comunicazione, tutti gli altri servizi sono assolutamente gli stessi per entrambe le tipologie. In sintesi i servizi implementati sono quindi i seguenti:

  1. customer_interface_60870 e customer_interface_CEI016: implementano l’interfaccia di comunicazione del Customer verso l’aggregatore per la ricesione di comandi e l’invio di misure. In particolare la prima implementa uno slave per il protocollo IEC 60870-104 il quale accetta connessioni TCP (usando la porta 2405 come default) da un master (in particolare, dal servizio aggregator_customer_interface_60870). Le misure seguono un formato del tutto analogo a quello previsto nella comunicazione Aggregatore-Terna, ma in questo caso anche l’invio di set-point avviene tramite 104 invece che tramite file comandi. Per quanto riguarda l’interfaccia IEC 61850 è stato invece utilizzato il modello dati previsto dalla norma CEI 0-16, implementando inoltre (sempre a livello dimostrativo) le soluzioni di sicurezza informatica previste dalla norma IEC 62351: a tale scopo è stata utilizzata la versione “sicura” della libreria MMSLite di Sisco.
  2. customer_dashboard_backend: implementa un semplice server HTTP che fornisce l’interfaccia grafica per lo svolgimento della simulazione, implementata mediante tecnologia HTML5.
  3. customer_dashboard_frontend: è l’interfaccia grafica vera e propria, che comprende alcune parti codificate in linguaggio Javascript. In particolare vengono visualizzati i comandi ricevuti dall’aggregatore.
  4. customer_ems: implementa la logica di schedulazione dei singoli dispositivi a fronte della ricezione di comandi dall’aggregatore. I comandi vengono letti dal database Redis, in cui sono scritti dal servizio customer_interface_60870 o customer_interface_CEI016. A sua volta la schedulazione prodotta da questo servizio viene scritta in Redis, diventando in questo modo disponibili agli altri servizi associati all’attore Customer.

A questo attore sarebbero inoltre associabili ulteriori servizi di comunicazione con i singoli dispositivi. Tale comunicazione potrebbe avvenire tramite un protocollo di comunicazione “locale” (nel senso di non connesso a Internet) come per esempio Modbus. Tali servizi non sono stati implementati nel simulatore, in quanto non di interesse dal punto di vista degli aspetti di interoperabilità (si tratta infatti di una scelta implementativa fatta dal Customer).