Una volta arrivati alla configurazione neutrale si deve ottenere il sistema destinatario traducendo prima semanticamente e poi sintatticamente i dati. Un esempio che illustra la traduzione è il seguente. Supponiamo che un certo sistema sorgente rappresenti le informazioni sui task includendo nella configurazione del controllore uno speciale blocco funzionale (Function Block) il quale specifica il cycle-time, la priorità ecc., degli altri blocchi funzionali. Nella rappresentazione neutrale, in accordo a quanto specificato da Iec 61131, le informazioni sui task (semantica) sono esplicitamente rappresentate e collegate con i programmi associati ai task. In questo caso la traduzione sintattica ha prodotto gli oggetti task analizzando i blocchi funzionali inseriti in un certo controllore. Il blocco funzionale che memorizza questi dati nel sistema sorgente è solo un elemento sintattico e quindi viene scartato. Mentre, l’informazione semantica è invariata (esiste un task e la logica viene eseguita in accordo ai requisiti temporali dettati dal task stesso). La traduzione realizzata dai vari stati della pipeline è basata su una o più basi di conoscenza che raccolgono le regole di traduzione, le quali possono essere configurate di volta in volta. La traduzione basata su regole migliora la flessibilità e la manutenibilità delle procedure di traduzione, e dà la possibilità di meglio incorporare l’esperienza degli esperti di revamping. Una regola è un “pezzetto” di codice che si occupa della traduzione di un certo tipo di dato (per esempio un function block). Il linguaggio usato per esprimere il “pezzetto” di codice può essere sia grafico sia testuale. Il linguaggio grafico risulta molto utile nel caso in cui si debbano tradurre diagrammi a blocchi funzionali. A seconda dello stadio della pipeline in cui ci si trova, le regole si occupano o della traduzione sintattica e strutturale delle basi di dati o della traduzione semantica dei valori contenuti nelle basi di dati. Le regole vengono applicate da un interprete della conoscenza (meglio noto come knowledge interpreter) che realizza la traduzione da una base di dati alla successiva.. Questo interprete opera, sulle tre basi di dati che hanno la stessa sintassi e struttura (basi di dati con sintassi e struttura neutrale). Risulta quindi possibile realizzare un solo interprete della conoscenza da utilizzare per la traduzione di ogni base di dati a sintassi neutrale; quest’interprete viene di volta in volta configurato con le regole più opportune per la traduzione da eseguire.
Conclusioni
Quest’articolo propone un approccio e uno strumento che si è dimostrato molto utile nella traduzione dei programmi dei sistemi di controllo scritti con linguaggi a function block. Lo strumento che è stato implementato sui concetti qui esposti, può far significativamente risparmiare tempo e costi prima di tutto perché migra quasi del tutto automaticamente il software e la configurazione hardware del sistema di controllo. In secondo luogo, l’approccio utilizzato comporta anche un ridotto tempo di controllo e ottimizzazione dopo il revamping, perché le regole di traduzione (che vanno a costituire la knowledge base) sono testate in anticipo e la traduzione produrrà consistentemente lo stesso risultato. E infine, nel caso in cui si voglia ampliare il tool considerando un nuovo sistema di controllo sorgente (o destinatario) solo la migrazione dal sistema sorgente verso il sistema neutrale (o dal sistema neutrale al sistema destinatario) viene coinvolta: quindi non deve essere riprogettatono reimplementato l’intero tool. Inoltre, quest’ambiente di migrazione presenta alta flessibilità e modularità, la quale incrementa l’utilizzabilità e la manutenibilità dello stesso. Infatti, durante il lavoro di revamping, nuove funzioni di traduzioni possono essere integrate nel tool, senza che ciò comporti cambiamenti nella progettazione e nell’implementazione, ma solo implementando nuove knowledge base grafiche e testuali.
Bibliografia
[1] G.M. Weisenborn, Method for converting a programmable logic controller hardware configuration and corresponding control program for use on a first programmable logic controller to use on a second programmable logic controller, Us Patent 5 142 469.
[2] J.Y. Levy et al., Compiler with generic front end and dynamically loadable back ends, Us Patent 5 812 851.
[3] M. Hayashi et al., Compiling apparatus and a compiling method, Us Patent 5 396 631.
[4] R.C. Waters, 1998, Program translation via abstraction and reimplementation, Ieee Transactions on Software Engineering, vol. 14, No. 8, pp. 1207-1228.
[5] R.W. Lewis., 1995, Programming industrial control systems using Iec 1131-3, Iee Control Engineering.
[6] Iec committee, 1992, Programmable logical controllers – Part 3: Languages, Iec 61131-3 standard.
[7] Verein Deutscher Ingenieure, Vdi/Vde 3696 standard function blocks, number 25.040.40.