Per ridurre i tempi di sviluppo della logica di controllo di una macchina automatica è importante che questa sia modulare e riutilizzabile, cioè basata su componenti di libreria che opportunamente configurati possano essere utilizzati su macchine automatiche diverse. Gli standard e le norme, come la IEC-61131-3 e PLCopen, stanno cercando di aiutare il progettista software a rendere i progetti sviluppati indipendenti dalla piattaforma di controllo, operando una standardizzazione dei linguaggi e delle funzionalità che le diverse piattaforme di controllo devono implementare. Oggi il progettista software trova disponibili sul mercato componenti per l’implementazione delle funzionalità di alto livello e basso livello, tipicamente per la gestione delle interfacce utente uomo macchina (HMI), gestione del motion control e gestione dei bus di campo di componenti remoti. Al contrario, per lo sviluppo della logica di controllo, il progettista software si trova spesso a dover sviluppare i propri componenti di libreria. Quando si parla di componenti software intelligenti, il primo passo è capire quali sono i componenti necessari per sviluppare un’applicazione nel mondo delle macchine automatiche.

Pensando a come è strutturato il software di una macchina automatica, possiamo dividere i componenti in due gruppi: uno comprende i componenti che pilotano dispositivi fisici (valvole pneumatiche, motori elettrici, ecc.), nell’altro quelli che implementano funzionalità che non sono legate a dispositivi fisici, ma a servizi necessari per lo sviluppo del controllo logico. Approfondiamo ora il tema dei componenti di libreria intelligenti di questo secondo gruppo.

Una problematica tipica nel mondo delle macchine automatiche è la gestione delle informazioni riguardanti il prodotto in lavorazione (solitamente quello che accade è un avanzamento del prodotto che viene lavorato in stazioni successive). Quando il prodotto si trova in una stazione di lavorazione, la condizione di lavorazione su quel prodotto dipende da condizioni derivate dalla lavorazione precedente. Ad esempio, se la lavorazione precedente non è andata a buon fine, il prodotto è da considerare scarto e non devono essere eseguite le lavorazioni successive.
Spesso il progettista software approccia questa problematica come una “semplice” gestione di dati che scorrono in uno shift register, andando a personalizzare per ogni macchina le condizioni di esecuzione di lavorazione, e le condizioni per leggere le informazioni dai sensori che indicano se la lavorazione è andata a buon fine oppure no. A complicare ulteriormente lo sviluppo del controllo della macchina sono le condizioni di funzionamento non nominali; un esempio classico sono le condizioni di arresto della macchina, sia di tipo immediato che non immediato. Sotto queste condizioni di arresto le lavorazioni devono venire sospese, ma non sempre nello stesso modo: in alcuni casi tramite arrestati immediati, in altri casi devono prima completare operazioni e poi arrestarsi per non rimanere a contatto con il prodotto (ad esempio per gli incollaggi).

Questa gestione differenziata viene di solito personalizzata dal progettista software ad ogni applicazione, mentre invece il problema potrebbe essere generalizzato ed affrontato in maniera più trasversale, sviluppando dei componenti di libreria software intelligenti, configurabili con le diverse modalità di gestione. Per affrontare questo problema, il componente di libreria al suo interno avrà varie unità di funzionamento: un’unità di memorizzazione dello stato dei prodotti durante il processo di lavorazione (registro a scorrimento); unità preposte all’individuazione dei prodotti da scartare a seguito di lavorazioni non correttamente effettuate (sezioni di verifica); unità preposte alla identificazione di situazioni operative cui può corrispondere un arresto della macchina, ma che non interferiscono col processo di lavorazione dei prodotti (sezioni di diagnostica); unità preposte all’inibizione di eventuali lavorazioni sui prodotti (sezioni di predisposizione); unità preposte al prelievo dei materiali e all’instradamento dei prodotti verso i relativi canali di raccolta (sezioni di controllo). Il componente di libreria dovrà, tramite opportuna configurazione: definire la sequenza delle attività di verifi ca e di controllo a eseguire sui prodotti in corso di lavorazione; definire i compiti affidati alle sezioni di verifica, diagnostica, predisposizione e controllo, e loro classificazione in termini di modalità di gestione dei relativi segnali di ingresso o di uscita. Si può configurare anche la gestione per la sincronizzazione del trasferimento di informazioni tra sottosistemi preposti alla verifica ed al controllo delle lavorazioni eseguite in parallelo su prodotti distinti. Con lo stesso approccio è possibile sviluppare un componente di libreria per la gestione delle segnalazioni. Con il termine segnalazione vogliamo indicare qualsiasi tipo di informazione (allarmi, anomalie, avvertimenti, indicazioni) debba essere inviata all’utente come supporto alla guida della macchina; quindi, oltre alle informazioni di diagnostica, con il termine segnalazione indichiamo le informazioni relative allo stato della macchina. Un punto critico riguarda la modalità di generazione delle azioni che devono scaturire in macchina a fronte delle varie segnalazioni.

In questo caso potrebbe sembrare non possibile generalizzare questo problema e quindi sviluppare un componente di libreria, dato che i guasti nelle macchine sono differenti e che ancor più differente nelle diverse macchine è l’azione da intraprendere a fronte dei diversi guasti. Il problema può essere scomposto in due parti: nella memorizzazione delle segnalazioni e nella generazione delle azioni. La memorizzazione può essere affidata a un componente di libreria, che opportunamente configurato può gestire la lista delle segnalazioni attive, con priorità temporale o priorità statica, e la modalità di reset o di autoreset (incondizionato, condizionato, temporaneo, a macchina ferma, ecc.) delle singole segnalazioni. La gestione della modalità di reset di ogni segnalazione, e l’azione corrispondente sulle condizioni operative della macchina (arresto incondizionato in emergenza, immediato, in fase, arresto temporaneo, ecc.), possono essere gestite tramite un semplice template in cui il progettista software deve inserire queste informazioni, cioè deve “descrivere il comportamento della macchina”.