Progettazione e sviluppo di una architettura software per il controllo di un impianto didattico in ambiente Linux/RTAI

Il software finora sviluppato è essenzialmente un'architettura per il controllo di un impianto sperimentale basandosi sulla piattaforma Linux/RTAI. Tale architettura ha come caratteristica fondamentale l'individuazione di tre componenti software indipendenti e intercomunicanti, che assumono differenti ruoli nel controllo del plant. Tali componenti sono:

• un software che permettesse l'interfacciamento a livello  fisico con l'impianto e la segnalazione delle situazioni di emergenza;
• un'API in grado di ascoltare le segnalazioni di emergenza reagendo opportunamente e fornente un'implementazione ad oggetti dell'impianto stesso;
• un pannello di controllo in grado di visionare l'impianto e di avviare le ricette scritte dall'utente.
  

Il tutto è stato svluppato nell'ottica dell'open-source, ed in particolare con l'utilizzo di Linux/RTAI, l'estensione del kernel sviluppata dal dipartimento di aeronautica del politecnico di Milano.

---

Il gestore dell'accesso all'hardware

Il layer di interazione con l'hardware ha delle  funzioni ben precise, esso infatti:

• si occupa della gestione dell'hardware di comunicazione con l'impianto tramite  l'interfacciamento con la scheda di acquisizione dati e dialogando con la porta seriale a cui sono collegati i motori del braccio SCARA. Quindi:
• utilizza COMEDI per la gestione della scheda Advantec
• interagisce con la porta seriale del PC per il controllo dei motori dello SCARA
• offre un'interfaccia verso gli strati superiori dell'architettura di controllo per permettere l'interazione concorrente da parte di più thread con il plant,
• gestisce le situazioni di emergenza più gravi ( nell'impianto in questione, l'esempio più immediato è sicuramente l'attivazione dei  finecorsa delle articolazioni del manipolatore ), mettendo in sicurezza l'impianto e notificandole opportunamente all'utente.
  Nel caso in cui venga riconosciuta una situazione di emergenza ogni comunicazione verso il plant viene interrotta e i task di controllo in esecuzione vengono fermati. In situazioni anomale questo è l'unico task a poter comandare l'impianto, per dare la possibilità all'operatore umando di riportare il plant in uno stato consistente.

Il tutto avviene garantendo l'esecuzione in hard real-time, che a questo livello significa sostanzialmente l'esecuzione di ogni comando ricevuto da chi realizza il controllo logico in tempi prevedibili.

Per ulteriori informazioni ved l'elaborato di tesi relativo, o contattare Matteo Giani.

L'API per l'implementazione delle ricette

L'API di implementazione delle ricette, fornisce a futuri studenti di ingegneria informatica un'interfaccia software per poter gestire un impianto da laboratorio che simula processi industriali, in ambiente Linux RTAI, il quale permette l'implementazione di task Hard Real-Time non solo in kernelspace, ma anche in userspace, grazie all'innovativo LXRT. Tale caratteristica ha reso disponibili le caratteristiche di RTAI per lo sviluppo del software in questione, realizzato in C++, seguendo il paradigma di programmazione ad oggetti.

Per quanto riguarda invece le ricette vere e proprie, l'API fornisce all'utente, colui cioè che effettuta il vero controllo logico, una facile interfaccia di programmazione per poter gestire agevolmente l'impianto da laboratorio Beo. Tramite tale interfaccia l'utente utlizza i metodi forniti per scrivere una ricetta seguendo l'ottica tipica dei programmi in SFC: sono infatti forniti metodi di accesso alle funzionalità dei singoli elementi del plant mappati in maniera trasparente sullo strato di interazione con l'impianto fisico, quindi sulle vere e proprie chiamate ai drivers della scheda di acquisizione dati nonchè alla porta seriale per il manipolatore SCARA. Dal momento che tali interfaccie devono essere utilizzate da studenti nell'ambito dell'automazione industriale, tale strato, piuttosto che fornire all'utente chiamate a metodi quali apri_pinza() o pistone_esci(), segue il paradigma visto a lezione ed in laboratorio lavorando con ISaGRAF, dando cioè visibilità all'utente su ogni singola valvola, sensore e motore, piuttosto che su oggetti da questi composti.

Riprendendo l'esempio precedente, per aprire la pinza l'utente deve aprire la valvola interna al pistone della stessa, tenerla aperta e fare polling sul sensore di pinza aperta  fino a quando questo non non dà il relativo segnale, seguendo quindi più da vicino il comportamento di un vero programma per PLC. Solo allora la procedura di apertura della pinza potrà dirsi conclusa. Lo scopo di questo tipo di sviluppo è quindi concorde con l'ottica di programmazione appresa nelle esperienze di laboratorio del corso in questione, seguendo l'idea di fornire all'utente un prodotto con  fini didattici affine a quanto appreso nel corso, e non con  scopi produttivi o di comodità di programmazione.

Per ulteriori informazioni vedi l'elaborato di tesi relativo, o contattare Matteo Lazzarotto.