Per chi opera nel service post-vendita industriale con le tradizionali competenze in meccanica, elettrotecnica, elettromeccanica, meccatronica è ben consapevole che ci sono ulteriori e molteplici difficoltà nell’eseguire messe in servizio (commissioning-startup), attività di service in remoto-campo e manutenzioni su beni strumentali industriali (componenti, attrezzature, sistemi, equipaggiamenti, macchinari, skids-packages d’impianto) dotati di un crescente numero di elementi “software-intensive”.
Ecco alcune delle principali identificate negli anni:
I sistemi software-intensive sono (ovviamente) intrinsicamente più complessi rispetto ai sistemi elettromeccanici (si tende a parlare di “systems of systems” solo nel comparto difesa, aerospazio, ma ne beneficierebbe ampiamente anche il comparto dei beni strumentali industriali). Questo implica che i tecnici di field service (i lavoratori trasfertisti che operano in campo e cantiere sulla base d’installato degli OEMs ed end-user) devono possedere competenze digitali specifiche (oltre a quelle meccaniche-elettriche-elettromeccaniche-meccatroniche) per comprendere anche il funzionamento del software, diagnosticare i problemi e apportare modifiche (attività prevalente nelle personalizzazioni integrazioni in campo durante le messe in servizio) o aggiornamenti. Ciò richiede una conoscenza della programmazione e dei linguaggi di sviluppo utilizzati (in particolare per modificare codice scritto da altri, il che complica ulteriormente il processo).
Competenze rare visto che buona parte del personale di field detiene skills di programmazione PLC in solo linguaggio ladder e quasi mai abilità con linguaggi ad alto livello o ad oggetti (mentre gli sviluppatori interni d’ufficio tecnico che hanno le competenze non sempre sono disponibili o hanno conseguito le necessarie idoneità professionali per recarsi “in sicurezza” sul campo, cantiere, offshore magari in zone disagiate o a rischio).
L’integrazione tra il software e l’hardware interno alla quadristica di comando-controllo del proprio equipaggiamento-macchinario può essere a volte problematica soprattutto nei progetti ad alta customizzazione (tipici per gli OEMs costruttori di macchine-linee automatiche manifatturiere), One-of-a-Kind, Engineer-to-Order (oltre all’integrazione con gli altri sistemi software-intensive del cliente o di altri fornitori OEMs, che non può essere quasi mai integralmente testata nei collaudi in fabbrica FAT).
Quando si effettua la manutenzione o si sostituiscono i componenti è pertanto necessario assicurarsi che siano compatibili con il software esistente, verificando prima di inviare un eventuale ricambio in sito che sia già stato caricato il firmware/software/file di configurazione corretto. Questo può richiedere l’accesso a specifiche versioni del software o a componenti particolari, il che può complicare il processo di manutenzione (il problema delle revisioni codice, schemi elettrici non tracciate può scoperchiare veri e propri vasi di pandora in molte organizzazioni abituate tradizionalmente a gestire ricambistica essenzialmente elettrica/meccanica).
I sistemi software-intensive sono soggetti a bug e vulnerabilità (oltre a cicliche ri-scalature digitali per il degrado nel tempo di sensoristica-strumentazione analogica) che potrebbero influire sul funzionamento del macchinario. Un bug nel software non individuato durante il commissioning potrebbe causare “sporadicamente” malfunzionamenti o errori nel funzionamento del macchinario stesso (se non addirittura guasti anche gravi o pericolosi sulla componentistica meccanica e di potenza).
Allo stesso modo, le vulnerabilità nella sicurezza del software potrebbero consentire l’accesso non autorizzato o il controllo remoto del macchinario da parte di terze parti. Pertanto, è necessario effettuare aggiornamenti regolari del software e implementare misure di sicurezza per proteggere il sistema (attività tradizionalmente evitate dai manutentori per paura di innescare fermi macchina non rapidamente/autonomamente ripristinabili).
Anche se purtroppo capita di rado, i tecnici che supportano il post-vendita di macchinari software-intensive devono essere adeguatamente e continuamente formati per comprendere il funzionamento dei vari sistemi e risolvere eventuali problemi. Ciò richiede tempo e risorse dell’ingegneria per fornire la formazione necessaria, che può essere più complessa rispetto alla formazione richiesta per i sistemi elettromeccanici tradizionali (quando un tecnico non opera su commessa viene spesato su centro di costo interno, e questo erode i margini di business unit, fenomeno che non sempre piace alle direzioni con un forte orientamento alla sola performance finanziaria).
Inoltre, a causa della rapida evoluzione della tecnologia, è necessario mantenere costantemente aggiornate le competenze del personale anche e soprattutto lato utilizzo strumenti di configurazione digitale, sviluppo software. Tools digitali che possono anche essere decine e decine (in passato gli OEMs si appoggiavano ad un solo principale fornitore per l’automazione-controllo-supervisione con un limitato numero di ambienti di sviluppo-configurazione, mentre oggi i fornitori possono essere molto più numerosi).
Aggiungiamo un elemento da non trascurare anche per l’end-user ed il suo team di manutenzione interno. Per eseguire la manutenzione del sistema software-intensive del fornitore, potrebbe essere necessario accedere al codice sorgente o alla documentazione specifica dell’architettura di sistema (questo è fonte di numerose dispute contrattuali post-vendita). Tuttavia, alcuni OEMs e/o produttori di applicativi software potrebbero limitare l’accesso a queste risorse per motivi di proprietà intellettuale o di sicurezza. Questo può rendere più difficile per i tecnici del cliente finale eseguire determinate attività di manutenzione o risolvere problemi complessi (diventando così sempre più dipendente dal post-vendita del fornitore).
Industria 4.0 e dipendenza dalla connettività: Nei macchinari software intensive, la connettività di rete può essere un ulteriore fattore critico per il loro funzionamento. La mancanza di connessione o problemi di rete (o quelli più insidiosi di “run-time macchina” derivante dalla latenza nell’interscambio-transcodifica dati) possono influire sulle capacità del macchinario o rendere difficile la diagnostica locale, remota e la risoluzione dei problemi. Ciò significa che il personale di field deve essere in grado di affrontare anche problemi di connettività e reti informatiche. E qui si entra nel mondo dell’OT (Operational Technology) dove la complessità delle configurazioni lato networking/modello OSI possono crescere a tal punto da mettere in difficoltà anche un tradizionale esperto di networking IT (senza dimenticare i sempre più numerosi rischi introdotti lato sicurezza informatica “industrial-cybersecurity”, derivanti da settaggi-configurazioni effettuate da personale non sufficientemente esperto in ICT).
Anche le schede elettroniche (non solo la componentistica di potenza… vedi misure di corrente, tensione, termiche, etc) vanno manutenute, a maggior ragione con la crescente difficoltà negli approvvigionamenti dei micro chips. Servono pertanto appositi piani di manutenzione e test della micro componentistica discreta analogica (esistono validi testi sull’affidabilità, manutenzione, riparazione della componentistica elettronica e numerosi articoli tecnici), che vadano oltre alla pulitura-soffiatura con aria compressa delle schede o delle misure sui condensatori di potenza, ma che tengano anche conto (oltre al normale degrado dei componenti) degli ambienti a volte aggressivi lato atmosfera chimica. In tali situazioni (marine-offshore, raffinerie, cementerie-ceramiche, etc.) si può dannegiare irrimediabilemente l’elettronica o peggio innescare sul macchinario comportamenti imprevisti e di difficile diagnostica-individuazione (che il più delle volte non lasciano altra alternativa che sostituire ciecamente rack interi di controllo senza aver individuato le precise cause del guasto, causa urgenza/fretta di ripartire con la produzione).
In sintesi, le principali e supplementari difficoltà nella messa in servizio, service e manutenzione dei macchinari dotati di sistemi altamente software-intensive risiedono nella complessità del software, nei problemi di compatibilità, integrazione, nei rischi di bug e vulnerabilità, nella formazione del personale, nell’accesso al codice sorgente, alla documentazione, e nella dipendenza dalla connettività di rete (oltre che dall’affidabilità delle schede elettroniche/embedded).
Affrontare queste sfide richiede nuove competenze specialistiche (non solo lato team ingegneria, ma anche per i ruoli di project & service managers, commissioning professionals/managers e tecnici di field service), accesso alle risorse appropriate e un’adeguata-continua formazione del personale, ma anche un cambio di paradigma nelle fasi di collaudo interno, ispezione ed accettazione in fabbrica (FAT) che coinvolga più un approccio a V-model (ben noto a chi adotta pratiche di systems engineering) volto all’analisi-funzionalità del software e non solo della qualità delle misure elettriche, prestazioni meccaniche. Per non parlare della serviceability dei componenti, sistemi, equipaggiamenti, macchinari (ma questo è tema di un altro articolo).
P.S. chi è un tecnico d’automazione trasfertista dotato di una buona formazione-competenza anche lato ICT/OT può essere un prezioso aiuto in campo per aiutare le aziende (anche se stranamente il mercato nazionale dei macchinari industriali continua a preferire, lato assunzioni, i tecnici d’automazione di field service più con skills lato montaggi meccanici e cablaggi elettrici…) ad affrontare tali sfide in particolare lato operazioni di service management (field/post-vendita) per avanzati e complessi beni strumentali industriali “software-intensive”, applicazioni (greenfield/brownfield) d’automazione industriale (discreta-meccatronica-elettronica-conversione di potenza) basate sull’uso di azionamenti-motori elettrici, attuatori ed emergenti tecnologie Industria 4.0.