software e hardware di comando. Ma questi sistemi spesso non sono in grado di comunicare tra di loro,
facilitando la gestione dell' impianto.
Questo problema si è fatto maggiormente sentire con l'arrivo delle reti, che permettendo lo scambio di grandi quantità di informazioni tra i computer hanno fatto sentire l'esigenza anche di scambio automatico di informazioni tra i sistemi.
Una delle ragioni principali di questo problema, è che le interfacce non sono standard. Sistemi proprietari di un produttore, che non comunicano con sistemi di altri produttori è abbastanza comune.
In assenza di standard, i produttori hanno sviluppato soluzioni hardware e software proprietarie. Tutti i controllori di processo e sistemi informatici sul mercato oggi hanno tecnologie proprietarie, interfacce, e API (Application Programming Interface) per accedere alle informazioni che essi gestiscono e/o contengono. I costi per integrare differenti sistemi, e piani di manutenzione per un impianto integrato possono essere molto significanti.
Per risolvere i problemi di comunicazione è possivile sviluppare driver e interfacce di comunicazione, tra i differenti sistemi. Lo sviluppo di driver ed interfacce dedicate però porta a problemi come l'incompatibilità tra diversi produttori di interfacce anche se basate sullo stesso protocollo di comunicazione, caratteristiche di protocollo non uniformemente utilizzate da tutti, aggiornamenti hardware che possono far malfunzionare un driver esistente e cosa da non trascurare, due applicazioni o sistemi non sono in grado di accedere allo stesso dispositivo contemporaneamente, senza l'aggiunta di interfacce aggiuntive.
Può darsi, cosa peggiore che un driver non è disponibile per un particolare dispositivo o software, limitando le opzioni di scelta dell'utente finale, o forzandolo a commissionare lo sviluppo e debug del driver, con annessi costi e tempi di attesa.
|
Solitamente uno sviluppatore di sistemi scada impiega circa il 30% del tempo di progettazione e sviluppo realizzando driver di comunicazione. Ogni volta che un produttore di hardware mette sul mercato un nuovo PLC, tutti gli sviluppatori devono scrivere un nuovo driver.
I fornitori di soluzioni software SCADA, spendono molti soldi sviluppando e mantenendo interfacce proprietarie, aggiungendo i costi sostenuti per questo aggiornamento, alle licenze per l'utente finale, e apportando un contributo pari a zero nel risolvere il problema della cooperazione tra più sistemi in un impianto industriale.
La soluzione è quella di avere uno standard che permetta un reale tecnologia software, plug.and-play , per il controllo di processo e l'automazione di fabbrica, dove ogni sistema, ogni dispositivo, e ogni driver possano semplicemente connettersi fra di loro e scambiare informazioni.
Avere uno standard di questo tipo rende possibile prospettare una comunicazione tra sistemi e dispositivi di tutto 'impianto , che sia uniforme, sicura e semplice e che parta dal livello di campo fino ai sistemi di managemant aziendale.
Il nome di questo standard è OPC : Object Linking and Embedding - for Process Control
Con l'impiego dell' OPC vengono eliminati confusione e costi di server multipli di produttori
diversi, e le annesse interfacce per la comunicazione tra essi.
|
OPC vuole portare al mondo industriale hardware e software gli stessi benefici che lo standard dei
driver per stampanti ha portato ai programmi per l'elaborazione di testi.