L’impatto del Motion sulle performance delle piattaforme commerciali di automazione


Autori: Stefano Lovisetto, Consorzio LIAM – Gianluca Berghella, CRIT
Articolo pubblicato su Automazione Integrata, Marzo 2013

Il Benchmarking di piattaforme commerciali di automazione è una delle attività svolte all’interno del laboratorio LIAM. Al momento sono nove i fornitori coinvolti nell’attività di Benchmarking: Beckhoff, B&R, Bosch, Lenze, Mitsubishi, Omron, Rockwell, Schneider e Siemens.

Tutte le piattaforme commerciali messe a disposizione dai fornitori integrano nativamente il motion control. Ciò significa che l’utente, acquistando il pacchetto completo di un solo fornitore (editor software + controllore + assi), è in grado di muovere gli assi elettrici direttamente dal software, facendo eseguire ai motori movimenti più o meno complessi (Fig.1).

Fig.1 - Editor Software - Controllore - Assi

Fig.1 - Editor Software - Controllore - Assi

Il progettista software, che ha il compito di sviluppare il progetto di controllo della macchina automatica attraverso lo specifico editor software messo a disposizione da ogni singolo fornitore, non dovrebbe, in linea di principio, preoccuparsi di gestire i dettagli implementativi a basso livello per far funzionare la piattaforma. La gestione della schedulazione dei processi, la comunicazione tramite il bus di campo, l’inseguimento dei profili di moto, la gestione delle motorizzazioni sono, infatti, alcune delle funzionalità tipicamente già fornite da una piattaforma commerciale. Queste attività risultano totalmente “trasparenti” per il programmatore, che dovrà preoccuparsi unicamente di configurarle correttamente nella fase di start-up.

Durante il funzionamento della macchina è necessario non solo gestire le motorizzazioni, ma anche l’intera logica di macchina: funzionamento nominale, supporto alle segnalazioni, controllo qualità, diagnostica e recupero da guasti, ecc.  Ognuna di queste attività richiederà un determinato sforzo computazionale, proporzionale alla quantità di dati real-time da processare.

Inoltre, poiché presumibilmente gli assi condividono il bus di comunicazione con altri dispositivi di varia natura (ad esempio I/O remoti e pannelli operatore), bisogna tenere in considerazione che ognuno di questi occupa una certa banda sul bus di campo in funzione della dimensione dei dati real-time che dovrà scambiare con il suo controllore.

E’ quindi importante notare come sia cruciale gestire in modo efficiente la capacità computazionale della cpu e le risorse del bus di campo. Ogni piattaforma, in funzione della propria architettura e della tipologia dei dispositivi utilizzati, ha una propria gestione di queste risorse.

Nonostante si abbiano differenti filosofie di gestione delle risorse di calcolo e di trasmissione dei dati, è condizione comune in tutte le piattaforme di automazione quella di concedere all’utente la possibilità di gestire solo una quota parte delle risorse del sistema. Questo perché parte di esse vengono impegnate in attività che possiamo denominare “attività di gestione del sistema”. Nel caso del bus di campo, le attività di sistema coincidono con gli strati funzionali (che compongono la piramide del modello ISO-OSI) utilizzati nel protocollo di comunicazione implementato dallo specifico fornitore. Per quel che riguarda le altre attività di sistema, quelle pertinenti al controllore sono (tra le altre): lo scheduling dei processi, l’interazione con l’immagine del processo, le politiche di gestione della cache run-time. Le attività utente sono invece tutte quelle che il progettista va a inserire e programmare all’interno del progetto di controllo.

Fig.2 - Senza Motion - con Motion

Fig.2 - Senza Motion - con Motion

Nelle applicazioni più complesse che prevedono la gestione di molti assi legati tra loro da relazioni di sincronismo, le attività di motion control possono consumare in modo decisamente oneroso le risorse di sistema. In particolare a loro esecuzione avrà un impatto sia sulle attività di gestione del sistema sia sulle attività utente (Fig.2).

Conseguenza naturale di queste valutazioni è la necessità di poter stimare a priori quanto una determinata configurazione di assi incida sul consumo delle risorse del sistema attraverso una misura della ricaduta sulle performance del bus di campo e dell’aumento del fattore di utilizzazione della cpu. Tale stima, ottenuta tramite un test di laboratorio, mira ad ottenere un trend del comportamento del sistema all’aumentare del numero di assi reali e virtuali configurati, come mostrato in Fig.3.

Fig.3 - Risorse Bus di campo VS Risorse Controllore

Fig.3 - Risorse Bus di campo VS Risorse Controllore

Il test definito dal LIAM consiste in un insieme di routine che riguardano l’analisi delle performance del sistema in relazione sia all’incremento progressivo del numero di assi configurati sia all’inserimento di camme di complessità crescente e di dinamiche sempre più spinte.

La stima dell’andamento del consumo delle risorse di un sistema a fronte di una determinata configurazione di assi è utile nella pratica per vari motivi.

Il primo esempio riguarda la scelta del controllore: di fronte alla necessità di realizzare una macchina con un elevato numero di assi e un’elevata dinamica, il test concepito dal LIAM permette di scartare i controllori che non riescono a soddisfare le specifiche. Analogo ragionamento vale per il bus di campo: la gestione di una rete composta da molti dispositivi con tempistiche molto stringenti necessita di un bus di campo all’altezza dei requisiti richiesti in termini di determinismo e tempi di reazione.

In alternativa si immagini una macchina automatica che presenta numerosi moduli opzionali, aggiunti di volta in volta per soddisfare le esigenze dell’end-user. In questo caso il livello di personalizzazione richiede una flessibilità non solo del software di macchina, ma anche dell’hardware utilizzato per il controllo e l’attuazione delle automazioni. E’ necessario quindi avere del margine sulle risorse messe a disposizione dal sistema e tarare controllore e bus di campo sulla configurazione di macchina completa, ovvero quella che prevede l’architettura più dispendiosa in termini di risorse (caso peggiore).

In generale è chiaro che migliorare l’efficienza di una macchina significa dimensionare bene le sue parti. In particolare gli azionamenti e tutta la catena cinematica sono fondamentali per quel che riguarda il consumo energetico. L’altra faccia della medaglia è rappresentata dall’efficienza dell’intelligenza. Poiché l’intelligenza ha un costo, è necessario ottimizzarla. Per questo le valutazioni hardware in termini di impatto sul controllore e sul bus di campo rivestono un ruolo non secondario per chi vuole realizzare delle macchine efficienti e intelligenti.

E’ proprio sull’intelligenza che si gioca una delle battaglie decisive in questi anni, sia per quel che riguarda il mercato dei fornitori di piattaforme di automazione sia per i costruttori di macchine.

Nel corso degli anni si è assistito ad un sempre maggiore impiego di assi elettrici in sostituzione dei dispositivi meccanici per quel che riguarda la realizzazione dei sincronismi. La complessità della macchina si sta quindi spostando sempre più dalla meccanica verso l’elettronica e il controllo software. Questo permette di ottenere nuove funzionalità e più flessibilità, a scapito del costo di integrazione e della gestione della complessità.

Se da un lato il costo della potenza di calcolo dei processori è diminuito nel tempo seguendo la legge di Moore, dall’altro la richiesta di aggiungere sempre nuove funzionalità, far interagire un numero maggiore di dispositivi, raggiungere nuovi standard di qualità, comporta un notevole sforzo di integrazione e di gestione della complessità, che si traduce nella necessità di piattaforme commerciali sempre più “intelligenti”.

In quest’ottica il lavoro di integrazione e gestione del motion control risulta uno degli aspetti chiave per il successo di una piattaforma commerciale di automazione. Nel mondo del packaging, in particolare, i requisiti dinamici sul motion control sono molto spinti. Per questo è fondamentale analizzare l’impatto delle attività di motion su una piattaforma commerciale.

Infine, per il LIAM lo scopo del Benchmarking non è quello di fare classifiche o dare voti, ma quello di fornire ai costruttori di macchine dei dati quanto più significativi e oggettivi possibile, affinché essi possano scegliere il prodotto che meglio si adatta, di volta in volta, alle esigenze della specifica applicazione.

, , , , , , , , , , , , , ,

  1. Nessun commento ancora.
(non verrà pubblicata)