Revamping di sistemi di controllo Un nuovo approccio..

• 
• Tweet
• Pin It
• Condividi per email

La traduzione: il nuovo approccio

L’insieme di concetti fondamentali, illustrati nel precedente capitolo, è condiviso, più o meno estesamente, da ogni sistema di controllo distribuito; anche se ogni piattaforma di controllo usa una forma proprietaria per descrivere concetti d’applicabilità generale. Questa differenza nella sintassi implica che ogni traduzione sarà dipendente sia dalla sorgente sia dall’obiettivo della traduzione. Questa doppia dipendenza implica che al crescere delle sorgenti e degli obiettivi il numero di diverse traduzioni tende ad esplodere. Questa possibile esplosione è illustrata in Figura 2. Nell’esempio mostrato a sinistra ogni freccia rappresenta una traduzione da una certa sorgente a un certo obiettivo; il totale delle traduzioni è quindi pari a dodici (quattro sorgenti per tre destinatari). Per ridurre il numero di versioni è stata introdotta una rappresentazione intermedia, che si frappone fra sorgente e destinatario durante la traduzione. Ciò è mostrato in Figura 2 (a destra): il numero di versioni si riduce a sette (comparato a dodici dell’approccio convenzionale). Questa rappresentazione intermedia, chiamata Neutral Layer, è stata utilizzata anche perché i diversi sistemi di controllo distribuito differiscono principalmente nella sintassi piuttosto che nella semantica. La soluzione di problemi di traduzione tramite uno strato intermedio di rappresentazione è largamente adottata nella tecnologia dei compilatori [2]. Lo strato intermedio apporta i seguenti vantaggi:
– lo strumento che si ottiene è basato su un framework modulare invece di tanti singoli strumenti di traduzione;
– allo stesso tempo, però, le traduzioni, fra sorgente e livello intermedio e fra livello intermedio e sistema obiettivo, sono svolte da “moduli” traduttori che sono fra loro lascamente accoppiati;
– minimizza lo sforzo necessario per aggiungere un nuovo sistema sorgente o un nuovo sistema obiettivo;
– permette di applicare alla descrizione neutrale vari tipi d’ottimizzazione, che basandosi proprio sulla rappresentazione neutrale sono applicabili a ogni possibile traduzione [3];
– usando una rappresentazione intermedia la configurazione del sistema di controllo risulta descritta sempre nello stesso modo. Questa uniformità di descrizione, indipendente dal sistema sorgente e obiettivo, migliora la possibilità di comprensione delle soluzioni di automazione da parte di una persona in grado di comprendere la rappresentazione intermedia. In [4] è descritta la traduzione di un linguaggio di programmazione general-purpose, eseguita con un approccio a passi.
Quest’approccio ha degli ottimi vantaggi, ma non può essere considerato come base per la traduzione di un linguaggio per sistemi di controllo, perché il corretto funzionamento del sistema d’automazione non è solo determinato dalle singole funzioni di controllo, ma anche dall’ambiente d’esecuzione (il sistema operativo dei programmi di controllo), dai collegamenti per la comunicazione fra controllori, e dalle caratteristiche della configurazione hardware, specialmente per quanto riguarda le connessioni con sensori e attuatori. Questi aspetti strutturali sono strettamente correlati con i programmi del sistema di controllo e quindi ogni sforzo di traduzione deve tenerne conto. La rappresentazione intermedia non può limitarsi a essere un semplice linguaggio di controllo neutrale, ma deve assolutamente includere tutti i concetti elencati in precedenza. La rappresentazione neutrale è perciò una sorta di sistema di controllo distribuito virtuale che come ogni sistema di controllo distribuito ha i propri controllori, schede di I/O, sistemi di comunicazione, linguaggi di programmazione e librerie.
La traduzione da sorgente a destinazione viene quindi trasformata nella traduzione da ogni sorgente alla rappresentazione intermedia e dalla rappresentazione intermedia a ogni destinazione. Il modello usato per descrivere la rappresentazione intermedia è stato progettato seguendo lo standard Iec 61131 [5, 6] e trae spunto per la parte di definizione semantica dallo standard tedesco Vdi/Vde 3696 [7]; il modello include anche degli elementi sintattici per la rappresentazione della comunicazione tra controllori, tra task e tra un controllore e la stazione operatore.

I dati considerati durante una traduzione, e le loro numerose trasformazioni sono gestiti con l’uso di un approccio all’elaborazione dei dati chiamato pipeline. Esso è spesso usato nei casi in cui una certa quantità di dati deve subire una sequenza di trasformazioni indipendenti. I vari elementi di elaborazione costituenti la pipeline migrano le informazioni di configurazione da una struttura, formato e contenuto relativi al primo Dcs a una struttura, formato e contenuto relativi al secondo Dcs. Inoltre le relazioni tra i vari elementi di una configurazione legata ad un certo sistema risultano preservati nella loro essenza, sebbene la loro forma possa variare a causa del processo di traduzione. La pipeline di traduzione applicata al presente problema, esegue la traduzione di una configurazione hardware e software di un Dcs attraverso la separazione tra la traduzione semantica e la traduzione sintattica in due passi successivi. Nella Figura 3 la forma degli elementi all’interno delle basi di dati (cilindri) rappresenta la sintassi e struttura dei dati stessi mentre il riempimento delle varie forme ne illustra la semantica. Il primo passo è la traduzione sintattica la quale trasforma la configurazione sorgente modificando i suoi elementi strutturali. Successivamente la traduzione semantica può essere eseguita in modo da trasformare i concetti ed i valori legati al sistema sorgente nei rispettivi concetti e valori della semantica neutrale.

Scarica l'allegato

• 
• Tweet
• Pin It
• Condividi per email