Definizione delle architetture di Data Collection
Realizzare un sistema di Data Collection partendo da zero e potendo decidere un’architettura di sistema e di applicativi comune per tutti gli impianti sarebbe, oggi, senz’altro relativamente semplice in quanto la maggior parte dei produttori di sistemi di controllo (Pcs) affianca a questi prodotti delle piattaforme Hmi/Scada in grado di interfacciarsi “automaticamente” con i loro Pcs e quindi di “vedere” in completa trasparenza tutti i dati disponibili. Purtroppo la realtà è sempre molto più complessa: in quasi tutte le aziende gli impianti esistono già, sono stati realizzati in tempi diversi, con prodotti e tecnologie diverse e comunque anche nel caso di una nuova fornitura sempre più spesso ci si orienta verso soluzioni standard del fornitore in quanto meno costose e con tempi di consegna più brevi ma spesso non omogenee dal punto di vista dei sistemi di controllo e supervisione adottati. Nel caso inoltre di aree produttive particolarmente articolate e complesse, dove la quantità dei dati da acquisire è particolarmente elevata (oltre i 10 mila tag), non sarebbe possibile acquisire i dati direttamente dal “Livello 1” senza averli prima opportunamente organizzati e aggregati per tipologia (Bit, Byte, Word, Dword, String ecc.) e per utilizzo (Real-Time, Evento, Comando ecc.) pur avendo a disposizione un’architettura di sistema e di applicativi comune per tutti gli impianti: in caso contrario il traffico di tale massa di dati acquisiti singolarmente non sarebbe sopportabile da nessuno degli attuali sistemi di comunicazione disponibili a meno di investire cifre improponibili nelle componentistiche hardware. Con riferimento al tipico di architettura dei Sistemi di comando e controllo riportato in Figura 2 è stato scelto di acquisire i dati direttamente dal “Livello 1” in quanto tutti gli impianti sono governati da Sistemi di controllo evoluti (Plc) eventualmente molto semplici da aggiungere laddove non ancora presenti ma si ritenesse necessario raccogliere dati significativi utilizzando I/O remoti gestiti da un Plc concentratore (ad esempio per il rilevamento di consumi energetici quali elettricità e/o vapore per singolo impianto). Il “Livello 1” (Plc, Dcs ecc.) si presenta molto più omogeneo e standard del “Livello 2” oltre che assolutamente “aperto” a eventuali implementazioni software atte a rendere disponibili i dati necessari al sistema di Data Collection, anche grazie al fatto che l’utilizzo e lo sviluppo di driver Opc per tali dispositivi è ormai sufficientemente consolidato e supportato da adeguati toolkit software. Per la connessione dei vari sistemi di Livello 1 con il Data Collection del sistema gestionale si è pertanto deciso di realizzare una rete locale, definita Plant Network, utilizzando lo standard Ethernet Tcp/Ip in quanto, oltre che già presente su tutti gli impianti più recenti, fornisce una connessione standard, con un grado di sicurezza e di affidabilità elevato, supportata da tutti i sistemi sia hardware sia software, dotata di un’elevata capacità e velocità di trasmissione dati. Su questa rete si appoggia un sistema di Data Collection in Hot-Backup basato su standard Opc per lo scambio dei dati con i sistemi di Livello 1. Il sistema di Data Collection a sua volta supporta una rete locale Ethernet definita Area Network dove rende disponibili i dati raccolti verso i sistemi di pari o superiore livello. Questa architettura permette di separare fisicamente il livello Shop-Floor dai livelli gestionali. L’architettura pertanto si evolverà comprimendo i “Livelli 1 e 2”, inserendo il nuovo “Livello 3” e trasformandosi indicativamente nell’esempio di Figura 3.
Definizione dei metodi di comunicazione
Dallo sviluppo delle definizioni via via più dettagliate delle funzionalità e degli obiettivi che si vuole raggiungere, si arriva alla definizione dettagliata delle tipologie di dati che si ha bisogno di acquisire da ciascun impianto/macchinario per passare successivamente alla definizione delle metodologie o protocolli di comunicazione. In altre parole si tratta di definire un linguaggio comune che permetta a tutti i partecipanti di capire le richieste di informazioni che arrivano e di soddisfarle oppure di richiedere a loro volta delle informazioni e di riceverne la relativa risposta. Purtroppo la complessità realizzativa di un interfacciamento completo fra il Sistema Mes e i sistemi di controllo degli impianti è molto elevata e costituisce oltre il 50% dell’intero sviluppo software. Non si tratta, infatti, di un semplice sistema di Data Collection ma di un vero e proprio Sistema gestionale di fabbrica che dovrà essere interfacciato da una parte con i sistemi informatici aziendali, l’approvvigionamento materie prime, la progettazione prodotto, il controllo qualità, la pianificazione della produzione e dall’altra con gli impianti produttivi, il personale operativo, il processo, il prodotto, i consumi. Per questo motivo la definizione del datalink deve essere curata nei minimi dettagli, partendo dalla definizione della tipologia dei dati che saranno cambiati che potranno indicativamente essere così composti:
– Real Time: tutti i dati che richiedono un’acquisizione continua del loro valore (misure, grandezze, stati ecc.). Il sistema Mes esegue continuamente la lettura dell’area dati configurata per questo tipo di acquisizione, tipicamente esistono diverse tipologie di Polling secondo la tipologia del dato, normalmente si usa un Polling “Real Time Veloce” a 1 s e un Polling “Real Time Lento” a 5 o 10 s.
– Evento: tutti i dati che richiedono un’acquisizione del loro valore solamente in conseguenza di un cambio di stato, del verificarsi di un’azione o di una condizione particolare (inizio produzione, fine produzione, presenza allarme, comando di arresto ecc.) in cui il sistema Mes viene chiamato a interpretare e archiviare l’evento, mettendo in atto le eventuali azioni necessarie o richieste.
– Comando: tutti i dati che richiedono un’azione e una risposta (Download della programmazione e della ricetta ecc.). Il sistema Mes non comanda direttamente il sistema di controllo ma richiede a quest’ultimo di eseguire dei comandi codificati rimanendo in attesa della risposta.