IT201800005547A1 - Metodo per la memorizzazione di programmi per l’interfaccia operatore e di gestione di macchine e/o impianti per l’automazione - Google Patents

Description

Descrizione del trovato avente per titolo:

“METODO PER LA MEMORIZZAZIONE DI PROGRAMMI PER L’INTERFACCIA OPERATORE E DI GESTIONE DI MACCHINE E/O IMPIANTI PER L’AUTOMAZIONE”

CAMPO DI APPLICAZIONE

Il presente trovato si riferisce ad un metodo per la memorizzazione di programmi per l’interfaccia operatore e di gestione di macchine e/o impianti per l’automazione industriale.

Il trovato si riferisce anche ad un prodotto software, o formato di progetto, per l’esecuzione del suddetto metodo di memorizzazione.

Con il termine prodotto software il presente trovato si riferisce al formato di progetto che gestisce l’interfaccia operatore (HMI - Human Machine Interface) tra utente e impianto di produzione. Il presente trovato si riferisce altresì al funzionamento di un dispositivo di controllo di una macchina e/o impianto, ovvero di un qualsiasi macchinario o sistema per l’automazione industriale, come ad esempio un PLC (Programmable Logic Controller).

Il presente trovato trova applicazione in tutti i casi dove è necessario gestire o stabilire il funzionamento di un dispositivo industriale che può interagire con una macchina operatrice e/o impianto industriale.

STATO DELLA TECNICA

E’ noto che i dispositivi industriali, utilizzati su macchine e/o impianti per l’automazione, comprendono un programma di gestione (“Runtime”), che opera sulla base di un progetto che definisce le funzionalità della suddetta macchina e/o impianto.

Per dispositivi industriali s’intendono tutte quelle architetture hardware idonee ad eseguire appositi software, normalmente utilizzati in ambito industriale.

Nel presente trovato, per semplicità espositiva, si farà riferimento principalmente ai dispositivi di interfaccia operatore HMI, ma quanto esposto può essere esteso ad altri dispositivi industriali, per esempio i dispositivi di supervisione SCADA (Supervisiony Control And Data Acquisition), o ai dispositivi che gestiscono le macchine operatrici, tra i quali i PLC.

E’ noto anche che, per sviluppare un progetto, è solitamente necessario, o usuale, utilizzare un ambiente di sviluppo, o IDE (Integrated Development Enviroment).

Detto ambiente di sviluppo IDE è strutturalmente dedicato alla progettazione delle funzionalità dell’interfaccia operatore HMI.

Con l’IDE, in particolare, si possono definire le schermate di interazione con l’operatore di macchina e configurare le funzionalità dell’HMI, come per esempio gli allarmi, oppure le variabili di campo da leggere o scrivere.

Lo stato della tecnica prevede che il progetto creato mediante l’ambiente di sviluppo IDE sia salvato in uno o più file, solitamente di formato proprietario. Il progetto in questa forma è denominato progetto sorgente, poiché è possibile riaprirlo nuovamente nell’ambiente di sviluppo IDE per ulteriori modifiche.

Nei sistemi embedded, dove ci sono meno risorse hardware, è prassi comune che il progetto sorgente sia in un formato “compilato”, cioè in forma di uno o più file ottimizzati in modo che il programma “runtime”, di detto sistema embedded, sia in grado di leggere, interpretare ed eseguire le istruzioni in modo più efficiente e veloce.

La “compilazione” del progetto sorgente è invece meno usuale nell’ambito dei sistemi SCADA. Infatti il programma runtime di questi sistemi è solitamente in esecuzione su PC che hanno risorse hardware migliori rispetto ai sistemi embedded.

Il progetto compilato, pertanto, ha forma e finalità specifiche ad essere eseguito dal Runtime, ma non a subire ulteriori modifiche.

Inoltre, nella maggioranza dei casi l’IDE e il Runtime sono in esecuzione su due architetture hardware distinte.

L’IDE risiede normalmente su un generico PC dove il progettista sviluppa il progetto HMI, mentre il programma Runtime risiede sul dispositivo di interfaccia operatore.

II trasferimento del progetto, dall’IDE al Runtime, avviene in modo noto, ad esempio attraverso una rete nella quale sono connessi il PC e il dispositivo d’interfaccia operatore, oppure con l’utilizzo di una chiavetta USB, o mediante altri mezzi di trasferimento.

Per eseguire il progetto dell’HMI sul dispositivo d’interfaccia operatore di una macchina operatrice e/o di un impianto, lo stato della tecnica prevede il seguente flusso di lavoro:

- progettare su PC le funzionalità dell’interfaccia operatore attraverso l’ambiente di sviluppo IDE (la progettazione avviene solitamente negli uffici tecnici del produttore della macchina operatrice);

- salvare il progetto in formato sorgente sul PC e, in seguito, eventualmente compilarlo per renderlo eseguibile dal Runtime; - trasferire il progetto sul dispositivo d’interfaccia operatore per l’esecuzione (il dispositivo è normalmente installato sulla macchina operatrice presso il cliente, e quindi in un edificio lontano rispetto agli uffici di progettazione del produttore).

Durante il ciclo di vita della macchina e/o di un impianto, l’interfaccia operatore viene normalmente modificata per soddisfare, di volta in volta, determinate richieste, ad esempio avanzate dall’utilizzatore dell’impianto o dai tecnici installatori.

A grandi linee, lo sviluppo dell’interfaccia operatore della macchina e/o impianto può comprendere le seguenti fasi operative:

- Fase di progettazione: il progetto può essere sviluppato ex-novo, oppure può partire da un progetto precedente, ad esempio realizzando una variante personalizzata di un progetto di serie. Normalmente, la progettazione è affidata al personale di ricerca e sviluppo del produttore della macchina operatrice e/o impianto, e il progetto normalmente viene creato presso il rispettivo ufficio tecnico;

- Modifica del progetto durante l’uso o durante l’installazione del dispositivo d’interfaccia operatore: durante la fase d’installazione potrebbe essere necessario apportare modifiche all’HMI per abilitare l’interazione con le altre parti della macchina e/o impianto eventualmente progettate da terzi e quindi non conformi con gli standard di comunicazione dall’azienda produttrice. Questa fase può essere effettuata presso l’ufficio tecnico del produttore o direttamente presso la sede d’installazione della macchina e/o impianto durante la fase di messa in servizio;

- Personalizzazione dell’interfaccia operatore: questa fase può essere richiesta per molteplici motivi, per esempio a causa di traduzioni incomplete o errate, messa a punto dell’ergonomia, differenti esigenze operative, ovvero per un accesso facilitato alle operazioni comuni. In particolare, queste modifiche sono richieste dopo l’installazione del dispositivo e/o dopo l’avvio delle normali condizioni operative;

- Modifica del progetto nelle fasi successive all’ installazione: le modifiche all’interfaccia operatore vengono implementate dai tecnici di supporto durante le manutenzioni, upgrade adattamenti a nuovi vincoli normativi e processi simili o assimilabili;

Queste fasi operative mal si adattano al flusso di lavoro che coinvolge la compilazione e il trasferimento del progetto per eseguire l'ΗΜΙ sul dispositivo d’interfaccia operatore.

Un altro inconveniente delle soluzioni note deriva dal fatto che, in caso di messe a punto specifiche all’interfaccia operatore, ad esempio durante la fase di installazione, occorre ripercorrere il suddetto flusso di lavoro, andando a modificare l’intero progetto originale, o una sua copia.

Un altro inconveniente delle soluzioni note è che ogni modifica sul progetto comporta una modifica dello stesso, determinando la perdita della versione precedente.

E’ possibile, al più, fare una copia del progetto prima di ogni variazione, in modo da garantirsi di poter ritornare al punto salvato qualora la nuova modifica non risponda ai requisiti. Nel caso in cui sia possibile eseguire le modifiche al progetto, oltre che nell’ambiente di sviluppo, anche direttamente su Runtime, il formato del progetto sorgente dovrebbe essere uguale al formato del progetto compilato per evitare trasformazioni poco efficienti tra il progetto sorgente ed quello compilato.

Come già accennato in precedenza, il Runtime e l’ambiente di sviluppo sono solitamente in esecuzione su due architetture hardware distinte e quindi il progetto sorgente normalmente non è ottimizzato per le prestazioni hardware del dispositivo di interfaccia operatore.

Esiste pertanto la necessità di realizzare un nuovo formato di progetto, ed un relativo metodo di memorizzazione e modifica, che superi almeno uno degli inconvenienti della tecnica nota.

Un primo scopo del presente trovato è di creare un formato di progetto che si adatti alle fasi operative di sviluppo dell’interfaccia operatore. Un altro scopo del presente trovato è di sviluppare un formato di progetto che consenta di intervenire soltanto sulla parte interessata alla modifica, e non di coinvolgere l’intero progetto.

Un altro scopo del presente trovato è di semplificare la modifica al progetto, in particolare, senza che vi sia l’obbligo di fare copie del progetto per ogni variazione.

Un altro scopo del presente trovato è di proporre un formato di progetto che consenta sia di fare modifiche temporanee all’HMI sia persistenti.

Secondo una variante del trovato, dette modifiche possono essere valide per un periodo, ovvero la cui terminazione del dispositivo d’interfaccia operatore sia collegata ad un evento specifico.

Secondo un’ulteriore forma realizzativa le dette modifiche possono essere persistenti e quindi valide anche dopo lo spegnimento e successivo riavvio del Runtime.

Un altro scopo del presente trovato è di ottimizzare un formato di progetto che consenta di essere modificato sia dall’IDE sia direttamente su Runtime.

Un altro scopo del presente trovato è di proporre un formato di progetto ottimizzato, utilizzabile sia dall’ambiente di sviluppo che dal Runtime, adattato per le prestazioni hardware del dispositivo di interfaccia operatore sul quale è in esecuzione il Runtime.

Per ottenere questi ed altri scopi come nel seguito evidenziati, la Proponente ha studiato, sperimentato e realizzato il presente trovato.

ESPOSIZIONE DEL TROVATO

Il presente trovato è espresso e caratterizzato dalle rivendicazioni indipendenti. Le rivendicazioni dipendenti espongono altre caratteristiche del trovato, o varianti dell’idea di soluzione principale.

Secondo il presente trovato, in accordo con i suddetti scopi, un metodo di memorizzazione di programmi per l’interfaccia operatore e di gestione di macchine e/o impianti per l’automazione, in cui il programma definisce le funzionalità di una HMI o di un PLC, od altro ancora, comprende la strutturazione del suddetto programma, o formato di progetto.

Detta strutturazione del programma prevede più strati, in cui tali strati comprendono almeno uno strato di base, in genere creato dal reparto di ricerca e sviluppo del produttore, e una pluralità di strati aggiuntivi, specializzati funzionalmente, al di sopra del progetto base.

A differenza dello stato della tecnica, che prevede che tale formato di progetto sia costituito in modo compatto e monolitico, cioè composto da un solo blocco, il presente trovato espone lo stato completo e funzionante del progetto, implementando in modo incrementale, sullo strato di base, in un voluto e definito ordine, una pluralità di strati aggiuntivi di modifiche al progetto che vanno da quello più vecchio a quello più nuovo.

A tal proposito, il programma, o formato di progetto, così composto consente di associare ad ognuno di detti strati una fase operativa di sviluppo dell’interfaccia operatore. In questo modo, ogni strato di progetto contiene tutte le modifiche relative ad almeno una fase operativa. Ad esempio in uno strato possono essere racchiuse tutte le modifiche relative alla fase di collaudo o ad un adattamento normativo.

Inoltre, i diversi strati del progetto, sviluppati eventualmente anche da diversi operatori, possono non essere modificabili dai progettisti degli strati superiori. Questo garantisce una corretta catena di responsabilità facilmente tracciabile e identificabile.

Si fa notare che il presente trovato fornisce la possibilità di modificare lo strato di base, o gli strati aggiuntivi precedenti, con un certo grado di flessibilità, nel caso mantenendo inalterati, o richiedendo modifiche controllate, agli strati soprastanti e/o sottostanti in relazione della dominanza.

Secondo un aspetto del trovato, il formato di progetto suddiviso a strati consente di sviluppare progetti differenti partendo dalla stessa base (eventualmente con l’aggiunta di uno o più strati precedenti in comune). Inoltre, il trovato permette di realizzare, in un qualsiasi momento, un strato di modifica soprastante gli altri e in seguito cancellarlo. Ad esempio, è possibile fare modifiche derivanti dalla sperimentazione all’ interfaccia operatore per valutare se implementare determinate funzionalità nell’HMI.

Secondo un ulteriore aspetto del trovato, ogni strato associato ad una determinata fase operativa, o modifica funzionale del progetto, non deve necessariamente comprendere tutto l’insieme di funzioni del dispositivo d’interfaccia operatore, ma può fare riferimento solamente ad un sottoinsieme funzionale. In questo caso, gli strati associati ad una fase operativa di sviluppo dell’HMI vengono collocati parallelamente sullo stesso strato nel formato di progetto, nella misura in cui è relativa l’associazione.

Secondo una variante, detti strati posti in parallelo possono convivere, uno a fianco all’altro, se non vanno a modificare lo stesso sottoinsieme funzionale.

Secondo un aspetto del trovato, il metodo di aggiornamento del prodotto informatico proposto dal presente trovato consente di fare sia modifiche temporanee, sia modifiche persistenti.

Le modifiche temporanee all’interfaccia operatore nascono, e si sviluppano, in un contesto, anche contingente, di esecuzione del programma.

Ad esempio, le modifiche temporanee si possono riferire a spostamenti di oggetti grafici all’ interno dell’interfaccia operatore che in seguito si decide di non implementare in maniera definitiva.

Le modifiche persistenti, che possono essere durature, devono rimanere valide anche nel caso in cui si ha un riavvio del Runtime. A scopo esemplificativo, non limitativo, le modifiche persistenti si riferiscono alla configurazione delle pagine di visualizzazione, oppure alla correzione di una traduzione.

ILLUSTRAZIONE DEI DISEGNI

Queste ed altre caratteristiche del presente trovato appariranno chiare dalla seguente descrizione di forme di realizzazione, fornite a titolo esemplificativo, non limitativo, con riferimento agli annessi disegni in cui:

- la fig. 1 mostra un prodotto software, o formato di progetto secondo il metodo di memorizzazione dello lo stato della tecnica;

- la fig.2 mostra schematicamente una forma realizzativa di un prodotto software, o formato di progetto secondo il metodo di memorizzazione del presente trovato;

- la fig. 3 mostra una forma realizzativa di un prodotto software, o formato di progetto secondo il metodo di memorizzazione del presente trovato, in cui alcuni livelli vengono collocati parallelamente sullo stesso strato;

Per facilitare la comprensione, numeri di riferimento identici sono stati utilizzati, ove possibile, per identificare elementi comuni identici nelle figure. Va inteso che elementi e caratteristiche di una forma di realizzazione possono essere convenientemente incorporati in altre forme di realizzazione senza ulteriori precisazioni.

DESCRIZIONE DI FORME DI REALIZZAZIONE

La descrizione di dettaglio che segue è fornita a titolo di esempio e non esaurisce possibili varianti innocue o implementazioni dell’invenzione.

Forme realizzati ve del presente trovato si riferiscono ad un formato di progetto, 10 comprendente uno strato di base 11 e una pluralità di strati aggiuntivi 12.

Lo strato di base 11, nel caso specifico non limitativo, include le funzionalità principali dell’interfaccia operatore e funge da piattaforma per la pluralità di strati aggiuntivi 12 che andranno progressivamente a ottimizzare l’HMI per la specifica applicazione.

La pluralità di strati aggiuntivi 12 viene disposta sulla base in ordine corretto, cronologicamente sequenziale, dal più vecchio al più nuovo. Ogni strato aggiuntivo 12 rappresenta una modifica all’interfaccia operatore e produce una o più variazioni del progetto rispetto agli strati precedenti.

Esemplificativamente, secondo una possibile soluzione realizzativa, ogni strato aggiuntivo 12 è associato ad una fase operativa di sviluppo dell’interfaccia operatore.

Si noti che il presente trovato non fa riferimento soltanto alle fasi operative descritte in precedenza, fomite a scopo esemplificativo.

Secondo il trovato, l’idea di soluzione, può essere estesa ad altri cicli di sviluppo in quanto gli strati aggiuntivi 12 possono essere associati ad una qualsiasi fase operativa dello sviluppo dell’HMI.

Discorso analogo può essere fatto nel caso in cui il cui il presente trovato venga utilizzato per modifiche od aggiornamenti di PLC.

Anche se gli strati aggiuntivi 12 vengono progettati e disposti sequenzialmente sopra lo strato di base 11, il presente trovato prevede la possibilità di modificare lo strato di base 11, o gli strati aggiuntivi 12 precedenti, con un certo grado di flessibilità, mantenendo inalterati o richiedendo minime modifiche agli strati aggiuntivi 12 soprastanti.

Secondo una ulteriore possibile soluzione realizzativa, gli strati aggiuntivi 12 già progettati non sono modificabili da altri progettisti.

Il formato di progetto 10 così strutturato consente di sviluppare diversi progetti, ad esempio HMI ma non solo, partendo dalla stessa base 1 1.

Questo approccio garantisce il massimo riutilizzo delle varie fasi di progettazione, nel contempo assicura un’elevata flessibilità di sviluppo dell’interfaccia operatore.

Secondo una possibile soluzione realizzativa, il formato di progetto 1 0 consente di costruire in qualsiasi momento uno strato aggiuntivo 12 di modifica soprastante gli altri e in seguito cancellarlo.

Secondo un’ulteriore possibile soluzione realizzativa, ogni strato aggiuntivo 12 del progetto 10 non coinvolge la modifica dell’intero insieme di funzionalità dell’interfaccia operatore, ma fa riferimento solamente ad un sottoinsieme funzionale in essa presente. Gli strati 12 così definiti, che appartengono alla stessa fase operativa dello sviluppo dell’HMI, vengono collocati parallelamente sullo stesso strato del prodotto informatico 10.

Secondo un’ulteriore possibile soluzione realizzativa, il presente trovato consente di fare sia modifiche temporanee che modifiche persistenti per consentire al formato progetto 10 di adattarsi alle diverse circostanze definite dal caso di applicazione specifico. Il formato di progetto 10 del presente trovato consente di salvare le modifiche rispetto alla situazione precedente di un qualsiasi elemento del progetto, o ad un suo sottoinsieme funzionale.

Secondo il presente trovato, il formato di progetto 10 consente di descrivere una pluralità di variazioni tra gli strati che compongono il progetto. In particolare, le variazioni si possono riferire a modifiche implementate rispetto agli strati di progetto precedenti e possono essere create, eliminate o modificate nel corso dello sviluppo dell’interfaccia operatore. A tal proposito, al formato di progetto 10 può essere associato un metodo di composizione, o di memorizzazione, idoneo a interpretare le suddette variazioni ed a comporre la versione di progetto completa. Il metodo di composizione secondo il presente trovato prevede di partire dalla base 11 e di progressivamente disporre gli strati aggiuntivi 12 facendo riferimento alle dette variazioni.

Secondo una possibile forma di realizzazione, il metodo di memorizzazione secondo il trovato è idoneo a gestire strati che insistono su parti indipendenti del progetto, ma che sono associati alla stessa fase operativa, e che sono disposti parallelamente sullo stesso strato del formato di progetto 10.

Il metodo di memorizzazione secondo il trovato è in grado di capire, attraverso la pluralità di variazioni, se la modifica associata ad un determinato strato risulta significativa o meno. Infatti, in caso di ripetute variazioni è necessario semplificare le modifiche che sono sovrascritte o invalidate da quelle successive.

Inoltre, il metodo di memorizzazione interviene anche nel caso in cui i progettisti vanno a modificare lo strato di base 11 o gli strati aggiuntivi 12 inferiori, riuscendo a risolvere eventuali conflitti negli strati aggiuntivi 12 sovrastanti.

È chiaro che al prodotto informatico fin qui descritto, ed al relativo metodo di memorizzazione, possono essere apportate modifiche e/o aggiunte di parti, senza per questo uscire daH’ambito del presente trovato.

È anche chiaro che, sebbene il presente trovato sia stato descritto con riferimento ad alcuni esempi specifici, una persona esperta del ramo potrà senz’altro realizzare molte altre forme equivalenti, aventi le caratteristiche espresse nelle rivendicazioni e quindi tutte rientranti nell’ ambito di protezione da esse definito.

Nelle rivendicazioni che seguono, i riferimenti tra parentesi hanno il solo scopo di facilitare la lettura e non devono essere considerati come fattori limitativi per quanto attiene all’ ambito di protezione sotteso nelle specifiche rivendicazioni.

Claims (9)

1. RIVENDICAZIONI 1. Formato di progetto, idoneo a definire funzionalità e/o caratteristiche di un dispositivo d’interfaccia operatore o di un PLC di una macchina operatrice, più in generale di un dispositivo industriale, caratterizzato dal fatto che detto formato di progetto comprende uno strato di base (11) e una pluralità di strati aggiuntivi (12) disposti in ordine sullo strato di base (11) dal più vecchio al più nuovo, ciascuno di detti strati aggiuntivi essendo idoneo a descrivere almeno una variazione agli strati aggiuntivi (12) precedenti.
2. 2. Formato di progetto come alla rivendicazione 1, caratterizzato dal fatto che ciascuno di detti strati aggiuntivi (12) è associato ad una specifica fase operativa di sviluppo dell’interfaccia operatore, o più in generale, del programma di un dispositivo industriale.
3. 3. Formato di progetto come alla rivendicazione 1 o 2, caratterizzato dal fatto che detti strati aggiuntivi (12) o lo strato di base (11) già progettati da un rispettivo gruppo di sviluppatori non sono modificabili da un altro gruppo.
4. 4. Formato di progetto come in una o l’altra delle rivendicazioni precedenti, caratterizzato dal fatto che detti strati aggiuntivi (12) non sono interessati alla modifica dell’intero insieme di funzionalità dell’interfaccia operatore, ma intervengono solamente su una parte delle dette funzionalità.
5. 5. Formato di progetto come nella rivendicazione 4 quando dipendente dalla 2, caratterizzato dal fatto che detti strati aggiuntivi (12), associati a una di dette fasi operative, vengono disposti parallelamente sullo stesso livello.
6. 6. Formato di progetto come in una o l’altra delle precedenti rivendicazioni, caratterizzato dal fatto che le modifiche a detti strati aggiuntivi (12) sono temporanee.
7. 7. Formato di progetto come in una o l’altra delle precedenti rivendicazioni fino a 5, caratterizzato dal fatto che le modifiche a detti strati aggiuntivi (12) sono persistenti.
8. 8. Metodo di memorizzazione di un formato di progetto come definito in una o l’altra delle rivendicazioni precedenti, in cui detto prodotto informatico è idoneo a descrivere una pluralità di variazioni associata a due o più strati (12) consecutivi di detto prodotto informatico (10), in cui detti strati aggiuntivi (12) sono disposti progressivamente su detto strato di base (11) facendo riferimento a dette variazioni e detti strati aggiuntivi (12) sono associati ad una pluralità di fasi operative di sviluppo dell’interfaccia operatore, o più in generale, del programma di un dispositivo industriale, in cui detto metodo è idoneo a gestire detti strati aggiuntivi (12) che insistono su parti indipendenti di detto prodotto informatico e che fanno riferimento a detta stessa fase operativa.
9. 9. Metodo di memorizzazione come nella rivendicazione 8, caratterizzato dal fatto che detto metodo è configurato per capire, attraverso detta pluralità di variazioni, se le modifiche associate a detti strati aggiuntivi (12) risultino significative o meno.