Sistema di monitoraggio e controllo dell’abitazione

[Roberto]

Da circa 5 mesi ho installato un impianto fotovoltaico nel quale è presente un inverter Aurora Power One modello: PVI-6000-OUTD. Attualmente utilizzo il software di Aurora come monitoraggio dell’impianto. Purtroppo il software proprietario è limitato al solo monitoraggio dell’inverter.

Navigando un su internet, sono riapprodato sul vostro sito, al quale ero già registrato. Vorrei cogliere questa opportunità per mettere su un sistema di monitoraggio e controllo generale dell’abitazione (simil-domotica). Non amo i prodotti già preconfezionati della domotica, in quanto esageratamente costosi e “limitati” a ciò per cui sono stati programmati dalle case costruttrici. Venendo al nocciolo della questione, espongo la mia idea:

– Acquisire i dati dall’inverter tramite modbus 485 (energia prodotta, etc)
– Acquisire i dati relativi all’energia auto-consumata (per sottrazione sapere l’energia immessa in rete); a tale scopo utilizzerei dei trasduttori con uscita in mA ooppure in volt (non mi sono ancora addentrato nei dettagli)
– Acquisire dei contatti provenienti dal sistema antifurto (riposo, armato, allarme, fault)
– Acquisire contatto di allarme, fault sistema videosorveglianza
– Acquisire i dati temperatura ambiente esterna ed interna all’abitazione
– Acquisire contatto di allarme presenza gas all’interno dell’abitazione

– Elaborare i dati 
– Elaborare un sistema di logging per avere uno storico

– Attivare gli allarmi dovuti nel caso in cui l’energia auto-consumata è maggiore rispetto a quella prodotta per quelle fasce orarie in cui si avrà maggior costo
– Comandare la caldaia per gestire nel miglior modo possibile la temperatura interna
– Attuare l’elettrovalvola chiusura linea gas in caso di presenza gas

Il tutto collegato ad un PC a basso consumo (già di mio possesso) sul quale è installato un software proficy/scada cimplicity HMI compatibile con il protocollo Modbus RTU con gestione di grafica animata, trend, etc.

Ovviamente i punti sopra riportati sono solamente l’inizio. Impiantato un punto di partenza sicuramente verranno altre esigenze che necessiteranno di eventuali espansioni. Premesso tutto ciò, potreste indicarmi su quali vostri prodotti orientarmi ? Personalmente vedrei bene i prodotti SlimLine, cioè unità centrale di acquisizione ed elaborazione, quali altri ?

P.S. ho un dubbio che mi assale: una volta configurata la CPU ARM7, ad esempio ed interfacciata con l’inverter Power One, il PLC è in grado di salvare uno storico degli eventi, allarmi, grafici, oppure sarà sempre necessario mantenere il PC-HMI operativo. Facendo la domanda al contrario: cosa succede se il PC-HMI dovesse rimanere spento per problemi vari ?

[Sergio Bertana]

Direi che la scelta della famiglia SlimLine è sicuramente azzeccata, vediamo i vari punti da te citati come potrebbero essere affrontati.

– Inverter Power One, l’inverter non utilizza Modbus ma un protocollo proprietario, disponiamo di un blocco funzione che gestisce la connessione con l’inverter (Vedi post)
– Controllo energia, tramite ingressi digitali e/o analogici è possibile acquisire i dati di consumo (Vedi posts 1, 2, 3, 4, 5).
– Contatti allarme e gas, si possono acquisire con i normali ingressi logici.
– Temperatura, si può acquisire con sonde Pt1000 connesse al modulo acquisizione analogico.

Tutta l’elaborazione dei dati è fatta dal modulo CPU opportunamente programmato, che provvederà tramite uscite digitali a gestire gli attuatori (Caldaia, EV Gas, ecc.).

Per l’interfacciamento con lo SCADA i sistemi SlimLine dispongono del protocollo Modbus sia RTU su porta seriale che over IP su interfaccia Ethernet. Basterà che il programma appoggi in variabili indirizzabili da Modbus le varie grandezze che si desidera monitorare e così lo SCADA potrà acquisirle.

Lo SlimLine può gestire anche il log dei dati creando files ad esempio in formato CSV, che poi potranno essere scaricati tramite connessione FTP (Vedi post). Questo garantisce il log dei dati anche a sistema SCADA non connesso.

[Roberto]

Grazie delle risposte, ho avute molte conferme che mi servivano per convincermi che la mia fosse una buona idea.

Ho un’ulteriore domanda da porre, girovagando per il forum ed i manuali sul sito, avevo trovato un pdf in cui veniva spiegato in dettaglio come connettere lo SlimLine tramite Modbus RTU al software di grafica (Power HMI ad esempio, il software che utilizzerò io è molto simile), non l’avevo salvato e non riesco più a ritrovarlo.

Praticamente vorrei sapere quali sono gli indirizzi Modbus dello SlimLine da far leggere al software scada per l’acquisizione delle informazioni.

[Sergio Bertana]

Nel forum si trovano esempi di connessione allo SlimLine con softwares SCADA o con pannelli operatore touchscreen. Solitamente per la connessione viene utilizzata la porta ethernet con il protocollo Modbus OverIP, ricordo che lo SlimLine supporta il Modbus ascii ed RTU su porta seriale e OverIP su porta ethernet.
 
L’area di memoria indirizzabile dal protocollo Modbus è quella riferita alla DB 100 (Sono 4096 bytes di cui 2048 ritentivi), tutte le variabili allocate nella DB 100 (Da DB 100.0 a DB 100.4095) sono accessibili in lettura e scrittura da protocollo Modbus. L’indirizzamento modbus è il seguente (Attenzione! Notare che nei comandi accesso a registri l’indirizzo è diviso per 2):
 
0x01, 0x02 Read coil status, Read input status. Address: 40000-44095
0x03, 0x04 Read holding registers, Read input registers. Address: 40000-42047
0x05 Force single coil. Address: 40000-44095
0x06, 0x10 Preset single register, Preset multiple registers. Address: 40000-42047
 
In questo post vi è un esempio di connessione con Power HMI, in questo post vi è un esempio di connessione con Profilab Expert, in questo post vi è un esempio di connessione con un pannello operatore.

[Roberto]

Dopo i suggerimenti ricevuti ho realizzato il mio progetto e lo utilizzo con grande soddisfazione…

Leggendo i vari forum relativi all’argomento, mi sono soffermato su questo post, in particolare alla possibilità di utilizzare in contemporanea la connessione Modbus RS485 inverter Aurora Power One sia verso lo SlimLine sia verso il software Aurora comunicator… mi ha colpito il suo commento seguente:

Abbiamo realizzato per la famiglia SlimLine dei blocchi funzione per il dialogo con gli inverter Aurora (Vedi post), una CPU SlimLine dialoga con gli inverter, ed è possibile interrogare la CPU da più PC contemporaneamente utilizzando il protocollo Modbus over IP. Però in questo caso non si può utilizzare il programma Aurora communicator, ma si deve realizzare una applicazione ad hoc utilizzando il protocollo modbus over IP.

Ha qualche suggerimento dal quale partire per raggiungere lo scopo ultimo di utilizzare entrambe le comunicazioni (SlimLine – Aurora Comunicator) allo stesso tempo ?

[Sergio Bertana]

Il protocollo di comunicazione degli inverter Aurora è un protocollo Master/Slave e prevede un solo Master, quindi o colleghi l’Aurora Communicator o colleghi lo SlimLine.
 
Alcuni clienti utilizzano lo SlimLine per acquisire i dati dall’inveter e poi gli stessi sono visualizzati su di un pannello operatore oppure su pagina web (Direttamente dallo SlimLine, vedi post) o acquisiti dallo SlimLine con un PC ma utilizzando il protocollo Modbus.

[Roberto]

Salve, mi allego a questa discussione dato che si tratta di un “continuo”.

Vorrei ampliare il monitoraggio del mio inverter includendo nel mio SlimLine gli allarmi ed errori generati all’interno dell’inverter stesso. Il software proprietario Aurora comunicator ha la possibilità di leggere gli allarmi ed eventi, come posso fare per interrogare l’inverter e far acquisire questi segnali allo SlimLine ?

[Sergio Bertana]

Quando è stata sviluppata la libreria ePowerOneLib non è stato implementato il comando di lettura allarmi dall’inverter, non era stato richiesto dal cliente per il quale è partito il progetto. Allego la tabella di allarmi che viene ritornata dal comando di lettura (Download). 

Implementare il comando nella libreria è una operazione fattibile ma deve essere richiesto al nostro ufficio commerciale che credo chiederà una partecipazione ai costi di sviluppo. Non potendo noi provare fisicamente il comando con l’inverter dovrei chiedere a te di fare i tests pratici ed eventualmente aprire una sessione di supporto remoto per il debug.

[Autore]

Post