Le prestazioni di una moderna macchina automatica, dal punto di vista funzionale e prestazionale, dipendono primariamente dalle scelte progettuali operate in sede di definizione della sua struttura meccanica. Tuttavia, fondamentale è anche il ruolo svolto dal sistema di elaborazione preposto al controllo della macchina, essendo sempre più ampio e rilevante lo spettro dei compiti a esso affidati. Oltre alle attività strettamente inerenti l’automazione dei cicli di lavorazione della macchina, esso è tipicamente chiamato a espletare altre funzionalità complementari, ma non meno importanti, come l’emulazione del comportamento di tradizionali organi meccanici o l’adattamento dinamico delle strategie e dei parametri di controllo in relazione a differenziate esigenze produttive.
Le moderne architetture.
Dal punto di vista hardware, la progettazione del sistema di controllo può avvalersi di un mercato ricco di risorse tecnologicamente avanzate, scalabili e interoperabili. La rapida crescita delle funzioni presenti nei moderni sistemi di controllo rende sempre più complessa per il progettista la scelta dell’architettura hardware più adatta in termini di:
Spesso queste scelte vengono effettuate in maniera separata e indipendente senza analizzare gli effetti della loro integrazione.
L’attività di benchmarking nasce con lo scopo di analizzare e valutare le principali soluzioni tecnologiche dei maggiori fornitori presenti sul mercato. I fornitori che stanno collaborando con il laboratorio LIAM per questa attività sono: B&R, Beckhoff, Mitsubishi, Omron, Rockwell, Schneider, Siemens. L’attività è focalizzata sull’analisi di soluzioni di controllo PLC-based, PCbased e di architetture multicore. Il benchmarking non deve essere interpretato solo come una mera attività di misurazione, bensì come un’attività che, partendo dallo studio della tecnologia, vuole analizzare le moderne architetture per l’automazione con un approccio metodologico.
Analisi architetture.
Per lo studio delle soluzioni di controllo PLC-based e PC-based, l’attività è divisa in tre fasi che permettono di eseguire in prima battuta un’analisi sui singoli componenti e in un secondo momento una serie di test rivolti all’integrazione delle varie parti del sistema di controllo. Le tre fasi individuate sono:
Le prove sui dispositivi intendono analizzare le prestazioni dei tempi di scrittura-lettura degli I/O, i tempi di reazione del sistema a eventi esterni, la banda passante dei dispositivi analogici, le prestazioni delle CPU in termini di tempo di esecuzione, determinismo del tempo di ciclo, algoritmi di schedulazione dei task e valutazione del jitter e i ritardi introdotti da isole remote collegate tramite bus di campo. Il laboratorio sta lavorando anche per automatizzare tutte le procedure di test. Si pensi al classico esempio della valutazione della banda passante o della distorsione introdotta da moduli di I/O di tipo analogico. Spesso è l’operatore a dover aumentare manualmente (con enorme dispendio di tempo) la frequenza del segnale che costituisce l’ingresso del componente da testare. Questo processo può essere automatizzato usando schede di acquisizione pilotate da “motori intelligenti”.
Utilizzando schede di acquisizione USB, oppure soluzioni National Instruments basate su CompactDaq, è possibile generare la variazione del segnale in maniera automatica: i dati acquisiti dal modulo vengono trasferiti mediante comunicazione OPC al computer di raccolta dati, che, mediante l’utilizzo di ambienti evoluti come LabVIEW o Matlab, esegue un’analisi run-time dei dati. Un altro esempio di automatizzazione di una procedura di test è quello della valutazione dei ritardi e dei jitter presenti nella comunicazione tra isole remote di I/O. L’attivazione contemporanea di più uscite a fronte di ingressi esterni rappresenta un classico esempio di test per l’analisi di queste prestazioni. Anche in questo caso l’operatore solitamente si trova a dover salvare manualmente i pochi dati ricavati da un oscilloscopio. Spesso si tratta di valori medi del segnale o valori che fanno riferimento al caso migliore o quello peggiore: non è possibile ricavare e valutare, per esempio a fronte di 500.000 attivazioni contemporanee delle uscite, tutti i ritardi presenti tra uscita e uscita. Per fare un’operazione di questo tipo con i classici strumenti di misurazione, l’operatore dovrebbe salvare manualmente tutte le forme d’onda per poi implementare un’analisi off-line dei dati salvati (dati che per acquisizioni di cinque o anche sei ore possono raggiungere le centinaia di Gbyte). Anche in questo caso, utilizzando schede di acquisizione intelligenti è possibile, tramite ambienti evoluti come LabVIEW e Matlab, eseguire un’acquisizione run-time dei dati e svolgere una completa analisi statistica dei dati.
Analisi motion control.
Le prove sul motion control vogliono investigare sia alcuni aspetti software, come l’implementazione di camme e riduttori elettrici, le funzionalità masterslave e gli algoritmi di auto-tuning forniti dai relativi ambienti di programmazione, sia aspetti legati all’hardware, come le prestazioni dinamiche in termini di precisione di inseguimento del set-point, di precisione nell’esecuzione di sincronismi e dell’impatto che il motion control ha sul sistema di controllo sia dal punto di vista della comunicazione, che dell’esecuzione del codice. L’ultima fase dell’analisi sul motion prevede di valutare l’architettura di controllo unendo hardware e software, attraverso lo sviluppo di un’applicazione tipica nel mondo del packaging (macchina per incollaggio al volo). L’attività di benchmarking valuterà anche l’ambiente di sviluppo attraverso l’analisi delle funzioni di debug messe a disposizione, dei linguaggi disponibili (IEC 61131, C), della facilità con cui il codice può essere riutilizzato implementando librerie standard, dell’integrazione con la parte di motion control, con la safety e con ambienti di virtual engineering come Matlab/Simulink e strumenti CAD.
L’ultima importante parte delle attività riguarda l’analisi delle prestazioni di piattaforme basate su sistemi multicore per applicazioni industriali. Non sempre, infatti, si conoscono le reali prestazioni di queste nuove tecnologie che stanno invadendo il mercato dell’automazione: utilizzare N-core non significa banalmente moltiplicare per N le prestazioni del sistema. In un sistema SMP (Symmetric Multi Processing), la gestione ottima delle sezioni critiche è diversa da quella tradizionale e richiede altre competenze. Ad oggi, non esiste un unico modello di riferimento per approcciarsi allo sviluppo di piattaforme multicore. Si sono affermati sostanzialmente tre macromodelli operativi, SMP, AMP (Asymmetric Multi Processing) e HyperVisor (Virtual Machine Manager), caratterizzati da profonde differenze a livello tecnologico e da un differente rapporto costi/benefici in funzione dello scenario applicativo nel quale vengono utilizzati. Senza un approccio sistematico che permetta di capire pregi e difetti di queste soluzioni innovative, si rischia di essere “abbagliati” dalle strategie di marketing dei fornitori e di perdere di vista la realtà dei fatti. Per valutare meglio le proposte attuali e quelle del prossimo futuro, il laboratorio LIAM sta eseguendo un’analisi delle architetture SMP, AMP e HyperVisor sia dal punto di vista teorico, sia schematizzando e valutando delle realizzazioni pratiche.
Articolo pubblicato anche su Automazione Integrata