Plc Con Supporto Iec 60870-5-104

[lucacarone]

Ciao a tutti,

sono alla ricerca di un prodotto (PLC) che supporti il protocollo IEC 60870-5-104.

Ho cercato un po su internet ma sembra sia un protollo fantasma!

Qualcuso mi saprebbe dare un consiglio?

[gigi130358]

E' un protocollo usato nell'ambito delle utility elettriche, anche se ormai si punta a IEC61850.

Al link http://brodersensystems.com/products/plcrtu-series/rtu32 puoi trovare un esempio di un PLC che supporta questo tipo di protocollo, basato su TCP/IP, sia lato server che client.

Se poi in google inserisci qualcosa tipo "gateway protocol converter iec60870" trovi qualche altra alternativa.

Gianluigi

[rddiego]

Un esempio, ma solo perchè lo conosco:

Plc M340 + modulo NOR

ma tutti i maggiori costruttori hanno configurazioni simili. oppure come suggerito cerca tra i gateway.

[lucacarone]

Vi ringrazio delle risposte!

Ma in che cosa si differenzia questo protocollo da protocolli più utilizzati quali Profibus, Modbus, Ethernt/IP, ecc ?

[gigi130358]

IEC60870-5-104 è un protocollo che sostanzialmente incapsula in TCP/IP quello che originariamente stava su seriale (IEC60870-5-101).

Guarda questo documento:

http://www.ricercadisistema.it:8080/site/b...i/a1-038319.pdf

La figura 35 a pagina 68 ti mostra che entrambi si appoggiano su TCP/IP, ma a livello applicativo ognuno ha un proprio modello per accedere ai dati.

Per avere un'idea delle differenze tra 104 e Modbus vedi anche questo gateway http://www.prosoft-technology.com/content/view/full/7154 che fa proprio da convertitore tra questi due mondi.

[lucacarone]

Ciaoo Gigi, ti ringrazio del supporto!

[gigi130358]

Di nulla.

Ciao

[RESNIC]

Di seguito vado a delucidare le differenze tra protocollo di Polling ( tipo Modbus) e protocollo IEC60870

Protocolli di pooling

Nei protocolli di Polling si identifica un Master ed un Slave ( oppure nelle reti Ethernet, un Client ed un Server), ove chi regola la comunicazione chiede continuamente dati al dispositivo sul campo, occupando cosi di fatto tutta la banda disponibile. Nel periodo in cui la comunicazione si interrompe ( i motivi possono essere svariati, dal Master/Client che cade, alla connessione elettrica che manca), nessun meccanismo intrinseco va a registrare ciò che accade per poi al momento del restore ricostruire il passato. Ho definito apposta intrinseco perché ognuno potrebbe al di sopra di un protocollo esistente creare un meccanismo di handshaking dati, ma ciò sarebbe un meccanismo “personale”, e non opportunamente regolato. Per effettuare una ricostruzione del passato, inoltre dev’essere predisposto l’invio del Timestamp ( sequenza di caratteri che denotano la data e l’ora dell’evento) associato al dato, questo tipo di dato spesso non è definito in maniera standard.

Nella realtà industriale, come già detto il meccanismo del polling va giustamente ad occupare la maggior banda possibile, ma nella realtà del telecontrollo, la banda utilizzata ha un costo, e nella scelta del contratto con il gestore questo è un parametro importante.

Protocollo IEC60870

Un protocollo nato sulle basi ed esigenze specifiche del telecontrollo è lo standard IEC60870. Anche se non risaputo, ma lo standard IEC60870 è il protocollo a più diffusa iterazione con la nostra quotidianità, essendo lo standard utilizzato nella rete elettrica nazionale. Nato per la gestione della distribuzione elettrica, trova a maggior ragione un largo utilizzo anche in campi come la distribuzione dell’acqua ( acquedotti oppure consorzi di bonifica), distribuzione del gas e metano ove le dinamiche del processo sono sicuramente più lente.

Perché utilizzare IEC60870? Nato opportunamente per il telecontrollo ha innati nel DNA quei meccanismi cui sopra avevamo visto altri protocolli non supportare. Secondo lo standard la RTU remota (viene definito RTU il dispositivo in campo) dev’essere in grado di storicizzare ciò che avviene in un Buffer interno. Alla riconessione, lo Standard definisce precisamente qual è il meccanismo di handshaking che si deve instaurate tra il Centro di Controllo e la RTU. Nello standard si definisce la possibilità di utilizzare il Timestamp associato al valore in maniera nativa, quindi le ricostruzioni cronotemporali, possono essere tranquillamente eseguite nel Centro di Controllo dopo la fase di download.

Dopo una fase preliminare di riconoscimento e scarico dati, lo standard definisce che sarà la RTU remota ad inviare i dati in maniera del tutto spontanea. È stato utilizzato il termine spontanea e non casuale, infatti la spontaneità è ben determinata dall’avvenimento di eventi. In molte RTU la programmazione dell’evento può rendere personalizzabile l’invio del dato ad esempio un dato può essere inviato per pressione di un pulsante, perché ha superato una certa soglia preimpostata (quindi per variazione), oppure perché bisogna inviarlo comunque a tempo; tutte queste logiche possono essere utilizzate in logica e costrutto booleano. Con questa spiegazione si capisce evidentemente che l’invio dei dati avviene solamente quando si presenta l’effettiva necessità , quindi la banda di comunicazione viene ridotta ed utilizzata per l’invio dell’essenziale, attuando di fatto una riduzione dei costi d’esercizio.

Spero d'aver spiegato abbastanza bene la differenza concettuale che sta alla base tra i protocolli... per i motivi sopracitati nonpossiamo definire Modbus un protocollo per telecontrollo .

[lucacarone]

Grazie RESNIC una spigazione magistrale!

Quindi se non ho capito male, IEC60870 introduce il concetto di TimeStamp! Quindi l'unità di controllo esegue un handshak con il RTU, successivamento l'unita di controllo non interroga più il RTU, ma al contrario RTU invia un messaggio ogni qual volta accade un evento e grazie all'ausiolio del TimeStamp riesce a ricostruire la serie di eventi!

Sembra essere molto proficuo, effettivamente quando mettevo in comunicazione un PLC Ethernet/IP con l'unità di contollo feceva richieste di dati praticamente ogni mezzo secondo, occupando così molta banda!

Una Domanda? ma in questa maniera, diciamo ad eventi, se perdo RTU l'unità di controllo non lo se ne accorge mai, o lo saprà nel momento del ripristino del RTU? O avviente un polling sporadico per il controllo?

[RESNIC]

Ciao,

Hai capito benissimo il concetto di Timestamp e la ricostruzione.

Per il resto hai fatto una domanda giustissima e lecita ... infatti non ho voluto precendentemente divulgarmi per non rendere pedante la spiegazione.

Diciamo brevemente che il centro di controllo ha diverse possibilità , una è quella di inviare il TEST Frame, un meccanismo cui in assenza di messaggi per un certo periodo esso invia questo messaggio di Test ( keep alive) per verificare la connessione. Poi in realtà l'invio di questo tipo di messaggi è subbordianto a dei parametri del Protocollo IEC60870 ( chiamati t1, t2, t3 , k, w ) percui a seconda delle impostazoni potrebbe essere anche la RTU che invia il TEST Frame al centro di controllo.

[lucacarone]

Grazie RESNIC, tutto molto più chiaro!

[Calogero]

la Wago ha una gamma di PLC dedicati al telecontrollo IEC60870 IEC61850 IEC61400 e varianti

Ne parlano qui http://www.wago.com/infomaterial/pdf/51267424.pdf

[honey9]

Nella realtà industriale, come già detto il meccanismo del polling va giustamente ad occupare la maggior banda possibile, ma nella realtà del telecontrollo, la banda utilizzata ha un costo, e nella scelta del contratto con il gestore questo è un parametro importante.

[mauromp3]

Io ho usato i Wago in varie Utility settore energia e vanno molto bene. la CPU 752 integra le librerie necessarie e lo sviluppo lo fai in standard IEC 61131-3.

La libreria dovrebbe essere in corso di omologazione Terna.

[RESNIC]

Ciao,

Dato che ci si può sbilanciare con le marche, io ho utilizzato la soluzione completa di Panasonic.

PLC dell serie FPSigma e modulo FPWebServer il tutto completo di librerie IEC61131 ... Contemporaneamente riesco a gestire IEC60870 e programmazione on-line il tutto via HSPA .... fino a poco tempo fa andavo in GPRS.