L’INSIEME DELLE FUNZIONALITÀ CHE UNA MODERNA MACCHINA AUTOMATICA DEVE IMPLEMENTARE RENDE EVIDENTE CHE LA PROGETTAZIONE DELLA LOGICA DI CONTROLLO È UN COMPITO DIFFICILE CHE COINVOLGE COMPETENZE MULTIDISCIPLINARI.

Autori: Eugenio Faldella (Università di Bologna), Matteo Sartini (LIAM)
Articolo pubblicato su Automazione Integrata, luglio 2012

È indubbio che il “successo” di una macchina automatica, dal punto di vista funzionale e prestazionale, discende primariamente dalle scelte progettuali operate in sede di definizione della sua struttura meccanica. Tuttavia, dallo stesso punto di vista, è fondamentale anche il ruolo svolto dal sistema di elaborazione preposto al controllo della macchina, essendo sempre più ampio e rilevante lo spettro dei compiti ad esso affidati.

Problematiche nello sviluppo di software di controllo.
In generale, la definizione della struttura hardware del sistema di controllo non pone particolari difficoltà. Il progettista, infatti, può trovare direttamente sul mercato “soluzioni sufficientemente universali” con spiccate caratteristiche di modularità, di espandibilità, di diretta compatibilità con il campo e tecnologicamente avanzate come: potenti unità di calcolo, controllori dedicati a funzioni speciali, dispositivi di I/O intelligenti, infrastrutture per la reti di comunicazioni.
Sfortunatamente, il principio “buy, plug & play” ha limitata applicazione nella progettazione del software del sistema di controllo. Le tipologie di componenti di libreria software che il progettista può trovare direttamente sul mercato (COTS – Commercial-Off-The-Shelf) riguardano tipicamente solo le infrastrutture software per la gestione delle reti informatiche e dei componenti remoti, gli ambienti di sviluppo e gli ambienti run-time. Questi componenti software supportano adeguatamente il progettista solo per quello che riguarda l’implementazione delle funzionalità di alto livello e basso livello, rimanendo tipicamente nei domini delle interfacce uomo macchina (HMI), della regolazione ad anello chiuso, del motion control e delle connessioni tramite bus di campo di componenti intelligenti remoti. La grande voragine esistente nel mezzo deve essere riempita dagli sviluppatori software. Ancora oggi manca, da parte dei fornitori di tecnologie per i sistemi di automazione industriale, un supporto concreto alla definizione di strutture software generali (design pattern), che possano guidare il progettista software nella definizione dell’architettura di controllo.
Come in molte altre applicazioni ingegneristiche, il problema viene affrontato mediante un approccio “divide et impera”: ispirandosi ai principi fondamentali della decomposizione e astrazione, si procede alla partizione dell’intera logica di controllo della macchina automatica in componenti più semplici e di più facile utilizzo, organizzati in un’architettura multilivello che rispecchia, almeno in una certa misura, la struttura meccanica e la dotazione di sensori e attuatori.

I fattori che incidono sui costi associati al ciclo di sviluppo del software.
Al di là delle attuali limitazioni tecnologiche e delle oggettive difficoltà che la progettazione di un sistema indubbiamente complesso comporta, altri fattori possono in generale concorrere ad estendere in maniera indesiderata i tempi, e conseguentemente i costi, di sviluppo e manutenzione del software. Prima di tutto, il ruolo ancillare spesso attribuito all’attività svolta dai progettisti software tende ad avallare la realizzazione di prototipi “rapidamente operativi” che possano fungere da veicolo per la verifica sperimentale delle prestazioni effettivamente conseguibili con le macchine dal punto di vista meccanico. In questo modo passa in secondo piano la necessità di realizzare sistemi caratterizzati da una struttura solida e flessibile. In secondo luogo, il limitato potere espressivo (della maggior parte) dei linguaggi di programmazione attualmente disponibili per le piattaforme PLC-based e PC o soft-PLC-based preclude la piena applicabilità delle metodologie di programmazione orientata agli oggetti. Non è quindi sorprendente che i costi associati al ciclo di sviluppo del software crescano ben oltre il budget pianificato.

Esperienze aziendali dimostrano come su macchine completamente diverse si possa implementare il 40-45% dello stesso codice di controllo.

L’architettura software “machine-independent & platform-independent”.
Al fine di aiutare a risolvere questi problemi, molte proposte interessanti sono state recentemente riportate nella letteratura scientifica e tecnica. Tra queste, alcune mirano a migliorare il rapporto costo-efficacia del complessivo processo di progettazione (ad esempio l’approccio meccatronico), favorendo e stimolando concurrent engineering, co-design e co-simulation. Altri approcci suggeriscono l’uso di linguaggi di modellazione (ad esempio UML) e di strumenti automatici per la generazione automatica di codice per migliorare la progettazione, il processo di sviluppo e la manutenzione del software.
Una soluzione efficace ai problemi citati non può derivare esclusivamente dalla collaborazione sinergica tra i progettisti dei vari gruppi di lavoro, così come dall’uso di potenti strumenti CAD-CAE e di ambienti di sviluppo integrati. Un ulteriore elemento chiave per migliorare decisamente la qualità del software e la produttività consiste nella definizione di un framework di riferimento che comprenda un set completo di componenti altamente riutilizzabili per la logica di controllo che, incentrati sulle funzionalità trasversali che caratterizzano il dominio dell’automazione, possano aiutare i progettisti durante il processo di modellazione e strutturazione delle loro applicazioni in base alle esigenze specifiche.
La realizzazione di un’architettura software quanto più possibile “machine-independent & platform-independent” risulta fondamentale non solo per ridurre drasticamente i tempi di progettazione di nuovi sistemi, ma anche per favorire l’intercambiabilità dei progettisti, oltre che delle piattaforme computazionali, in scenari affini. In tale ottica, riveste particolare rilievo la sistematica e coerente applicazione del principio “divide et impera”, e, conseguentemente:
i. l’identificazione di idonei criteri per la decomposizione funzionale del sistema complessivo in termini di una gerarchia di entità, astratte o concrete, opportunamente cooperanti;
ii. la definizione del ruolo e delle funzionalità di ciascuna entità (“what to do”), nonché delle relative interfacce e dei protocolli previsti per l’interazione con altre entità operanti nello stesso livello o nei livelli adiacenti della gerarchia;
iii. l’identificazione dei modelli di riferimento per la definizione formale del comportamento delle singole entità (“how to do”);
iv. l’identificazione dei modelli di riferimento per la definizione delle modalità di esecuzione dei compiti da parte delle singole entità (“when to do”).
Parimenti importante ai fini della riusabilità del software e della portabilità delle applicazioni è l’identificazione di efficaci design pattern orientati specificatamente al dominio applicativo delle macchine automatiche, quali la virtualizzazione della dotazione sensoriale e/o del sottosistema di attuazione di una macchina, il controllo della qualità del prodotto, la gestione delle informazioni di diagnostica.
Con un approccio metodologico, conforme al paradigma MDA (Model-Driven Architecture), è possibile definire, per ogni tipologia di problema affrontato, un modello di riferimento che abbia adeguata capacità espressiva (“la base di conoscenza”), e procedere, una volta per tutte, allo sviluppo del correlato programma (“il motore inferenziale”), in modo da conseguire prestazioni e comportamenti anche fortemente differenziati a partire dalla semplice configurazione parametrica del modello, piuttosto che attraverso lo sviluppo di codice ad hoc. Esperienze aziendali dimostrano come su macchine completamente diverse si possa implementare il 40-45% dello stesso codice di controllo.