Immaginate un costruttore di macchinari che sta preparando la prossima versione di una macchina confezionatrice. Un cliente ha bisogno di una serie diversa di schermate operative; un altro desidera funzionalità diagnostiche aggiuntive; un terzo richiede un’interfaccia per il collegamento a una linea di produzione esistente. La macchina di base rimane riconoscibile, ma i requisiti software stanno divergendo.
La questione non è più semplicemente come programmare ogni singola macchina, bensì come sviluppare tali varianti senza dover gestire un progetto separato e sempre più fragile per ogni configurazione, e come garantire la supportabilità delle macchine installate dopo la consegna.
Il nostro precedente articolo sul perché l’automazione industriale sta diventando “software-defined” ne descriveva la direzione generale. Per i costruttori di macchine, il significato pratico emerge in una sequenza di lavoro più comune: progettare una famiglia di macchine, mettere in servizio le singole macchine, rilasciare le modifiche e fornirne il supporto anni dopo. L’automazione “software-defined” cambia il modo in cui queste fasi sono organizzate. Non elimina gli obblighi ingegneristici legati a un processo fisico.
Una famiglia di macchine necessita di un’architettura software
Molti OEM riutilizzano già codice di controllo, oggetti di visualizzazione e driver di comunicazione. Il cambiamento più significativo consiste nel considerare tale riutilizzo come una decisione architettonica piuttosto che come una raccolta di file copiati da un progetto all’altro.
Una famiglia di macchine può condividere sequenze di base, diagnostica e definizioni dei dati, pur differendo per I/O, opzioni, interfacce o comportamenti specifici del cliente. Se tali differenze sono disseminate in tutta l’applicazione, ogni nuova variante può diventare un nuovo ramo che deve essere testato e mantenuto. Se le funzioni comuni e la configurazione specifica della macchina hanno confini chiari, gli ingegneri possono distinguere quali modifiche appartengono alla piattaforma e quali a una singola macchina.
Ciò non richiede un unico programma universale, ma piuttosto una relazione ben definita tra moduli riutilizzabili, configurazione, interfacce e l’hardware su cui questi vengono eseguiti. Una nuova opzione può quindi essere considerata come una modifica a una parte definita dell’architettura, con le relative dipendenze e i test ben compresi prima che raggiunga la sede del cliente.
Il vantaggio è potenzialmente significativo per un OEM che produce diverse macchine correlate: lo sforzo ingegneristico può concentrarsi sulle differenze che contano per l’applicazione. La condizione è altrettanto importante. Il software condiviso crea una responsabilità condivisa. Una modifica a un modulo comune può influire su molte configurazioni, quindi l’OEM deve sapere esattamente dove viene utilizzato quel modulo.
Il codice riutilizzabile non è automaticamente codice portabile
Il termine “indipendenza dall’hardware”viene spesso utilizzato come sintomo per indicare l’automazione definita dal software. Merita però un’interpretazione più precisa. Esiste una differenza tra il riutilizzo di un progetto software su diverse macchine in un unico ambiente e l’esecuzione della stessa applicazione, senza modifiche, su qualsiasi controllore.
Le FAQ di PLCopen sulla portabilità secondo la norma IEC 61131-3 rendono questa distinzione particolarmente chiara. Anche quando i controllori supportano lo stesso standard di programmazione, l’indirizzamento I/O, le funzionalità supportate, le velocità di scansione dei task e i limiti specifici dell’implementazione possono impedire che un progetto venga copiato direttamente dal PLC di un fornitore a quello di un altro. Un linguaggio comune è utile, ma di per sé non garantisce un runtime comune.
La conseguenza pratica è che un OEM deve definire l’ambito della portabilità prima di prometterla. Una struttura comune dell’applicazione può facilitare il riutilizzo del codice all’interno di una famiglia di macchine. Il trasferimento di quel codice su un altro ambiente di esecuzione o controller richiede comunque la verifica delle sue interfacce hardware, del comportamento di esecuzione e delle funzionalità supportate. Si tratta di affermazioni diverse, con livelli di verifica diversi alla base.
Per un costruttore di macchine, la domanda utile è quindi specifica: quale parte del software dovrebbe rimanere riutilizzabile se l’hardware cambiasse? Potrebbe trattarsi di un modulo diagnostico, di un concetto di visualizzazione, di un modello di dati o di una funzione di controllo. Ciascuno presenta dipendenze diverse. Elencarle fin dall’inizio è più utile che dare per scontato che la portabilità si realizzi in seguito solo perché un componente è stato definito “software-defined”.
L’implementazione diventa parte integrante della progettazione delle macchine
Quando le applicazioni possono essere configurate e implementate in modo più indipendente, la messa in servizio assume una forma diversa. Un OEM può creare una linea di base testata per una famiglia di macchine e poi applicare le opzioni approvate per ogni ordine. Il team di progettazione deve sapere quale versione è stata installata, quale configurazione è stata utilizzata e su quale hardware e ambiente di esecuzione è stata convalidata.
Tale documentazione è importante dopo la consegna. Un tecnico dell’assistenza che indaga su un guasto deve distinguere un difetto del software da una modifica di configurazione specifica del sito o da una dipendenza hardware. L’OEM ha inoltre bisogno di un metodo controllato per trasferire un miglioramento testato ad altre macchine idonee senza dare per scontato che ogni macchina sul campo sia identica.
È qui che l’automazione definita dal software diventa una disciplina del ciclo di vita. La release è una versione che potrebbe dover essere identificata, testata, installata, supportata e, infine, sostituita. Per l’OEM, ciò significa pianificare come vengono convalidate le modifiche e in che modo i team di assistenza possano individuare quali macchine siano idonee per un determinato aggiornamento.
Infatti, la Guida alla sicurezza delle tecnologie operative (Guide to Operational Technology Security) del NIST, sezione 6.2.11, pagg. 124–125, sottolinea l’importanza di testare le patch per verificarne gli effetti operativi, documentare come e quando vengono applicate e pianificare l’implementazione in base alle interruzioni dei servizi OT. Tali principi sono particolarmente rilevanti quando le modifiche al software potrebbero influire sulle applicazioni di controllo o sulla disponibilità dei sistemi. Una distribuzione più agevole dovrebbe essere accompagnata da procedure più chiare di approvazione, collaudo e ripristino.
L’implementazione flessibile presenta comunque dei limiti fisici
Una macchina può disporre di risorse di elaborazione in grado di eseguire diverse applicazioni. Ciò offre l’opportunità di collocare la visualizzazione, la comunicazione, l’elaborazione dei dati e, in alcune architetture, il controllo su una piattaforma condivisa. Solleva inoltre una questione a cui non è possibile rispondere solo attraverso il packaging del software: cosa accade quando questi carichi di lavoro competono per le risorse o quando uno di essi fallisce?
La documentazione relativa a Intel Edge Controls for Industrial è istruttiva in questo senso. Descrive la virtualizzazione e la containerizzazione per carichi di lavoro con diversi livelli di criticità, ma illustra anche in dettaglio i kernel in tempo reale, l’isolamento della CPU e altre misure utilizzate per garantire un comportamento deterministico. La necessità di tali misure dimostra perché l’esecuzione di un’applicazione di controllo come software sia solo l’inizio del lavoro di progettazione.
Un OEM deve comunque valutare i tempi, il comportamento in caso di guasto, la disponibilità, i requisiti di sicurezza e l’effetto previsto degli aggiornamenti sulle applicazioni adiacenti. Alcune funzioni possono essere adatte a un ambiente di calcolo condiviso; altre possono rimanere su controller dedicati. L’automazione definita dal software offre agli ingegneri più opzioni di collocazione. Tuttavia, non fa scomparire tali vincoli.
Interfacce che consentono al software di evolversi
Anche un’applicazione ben strutturata deve scambiare informazioni con il resto della macchina. Interfacce stabili possono consentire a un OEM di modificare una funzione diagnostica o di visualizzazione senza dover ricostruire ogni integrazione ad essa correlata. La panoramica e le specifiche concettuali di OPC UA mostrano un modo per definire la struttura e lo scambio di informazioni industriali tra applicazioni e dispositivi. Si tratta di un meccanismo di interoperabilità; il trasferimento del codice di controllo eseguibile su un altro ambiente di esecuzione rimane un compito ingegneristico a sé stante.
Per la manutenzione, questa distinzione è utile. Un’applicazione diagnostica può essere aggiornata in modo indipendente se legge un’interfaccia macchina documentata e l’OEM controlla le modifiche a tale interfaccia. Il vantaggio dipende dalla compatibilità tra le versioni e dai test, non semplicemente dalla scelta di un protocollo di comunicazione comune.
Cosa cambia per il costruttore di macchine
Il cambiamento più concreto per il costruttore di macchine è un mutamento nella progettazione da parte dell’OEM. Oltre all’architettura meccanica ed elettrica della macchina, deve definire i confini del proprio software: cosa può essere riutilizzato tra le diverse varianti, cosa appartiene a una particolare installazione, come vengono tracciate le versioni e quali funzioni possono cambiare senza interferire con le altre.
Ciò può portare a applicazioni più modulari, risorse ingegneristiche condivise e un processo di rilascio più controllato. Può anche far emergere dipendenze che in precedenza erano nascoste all’interno di un file di progetto. Il risultato non è un’indipendenza automatica dall’hardware, aggiornamenti più rapidi in ogni caso o un motivo per consolidare ogni funzione. È l’opportunità di rendere l’evoluzione del software una parte intenzionale della progettazione della macchina.
Per un costruttore di macchine, la domanda decisiva è semplice: quando questa macchina deve cambiare, quali parti possono evolversi e cosa deve essere rivalidato prima che torni in funzione? Un’architettura software-defined credibile dovrebbe rendere più facile dare questa risposta per tutta la durata di vita della macchina.
