In uno dei laboratori che seguiamo c'è una macchina di prova costruita nel 1976. Nello stesso capannone ce ne sono altre del 2020 e del 2021. Tutte ricevono le richieste di prova dallo stesso software e gli restituiscono i risultati nello stesso formato, anche se per farle parlare abbiamo dovuto prendere strade completamente diverse.
Negli ultimi anni abbiamo collegato così un centinaio di macchine, tra sale prove e linee di produzione. Non ce n'erano due uguali.
I numeri dei progetti di connessione macchine seguiti da Contech negli ultimi anni.
Tutto questo lavoro sul campo ci ha lasciato un'idea precisa. Leggere duecento parametri da un PLC non è la parte difficile, lo sanno fare in tanti. Il difficile arriva dopo, quando il laboratorio cambia una procedura o vuole un report diverso e scopre che per farlo deve aprire un ticket al fornitore e aspettare settimane.
Il vincolo: le macchine non si toccano
Quasi ogni progetto parte dalla stessa condizione, detta in modi diversi: le macchine non si toccano. Spesso il costruttore non esiste più, oppure esiste e chiede cifre importanti per mettere mano al software di bordo. Ci sono tarature e procedure validate. E le macchine devono continuare a lavorare mentre le colleghiamo.
Quindi non rifacciamo le interfacce. Andiamo a prendere i dati dove la macchina li mette già.
Solo che quei posti sono i più vari. Nelle sale collegate finora abbiamo trovato PLC con Modbus TCP o OPC UA, pronti all'uso, e controlli più vecchi con la sola porta seriale, portati in rete con convertitori Modbus RTU/TCP. Su alcune macchine il software di bordo, scritto in Visual C++, salva i risultati in un database Oracle locale, e siamo andati a leggerli lì. Altre trasmettono in UDP con un protocollo del costruttore, altre ancora si scambiano messaggi su code IBM MQ. E poi ci sono i file XML e CSV lasciati in una cartella a fine prova, che restano il caso più diffuso di tutti.
Le interfacce trovate sulle macchine collegate, dalla porta seriale alle API REST, ricondotte a un unico formato di dati.
Su una macchina ci sono più di duecento parametri da leggere. Su un'altra ogni stazione di prova ha ventiquattro termocoppie. Numeri così li regge qualsiasi sistema serio. Il tempo, semmai, se ne va per capire cosa significa ogni parametro e chi lo usa davvero. Di solito lo si scopre al banco con l'operatore, non sul manuale.
Quattro strade, scelte macchina per macchina
Per collegare una macchina scegliamo una di quattro strade. Non esiste una regola valida per tutta la sala, e in un laboratorio vero le quattro convivono.
- API diretta. Se il PLC o lo SCADA della macchina sanno fare una chiamata HTTPS, parlano direttamente con il software. È la strada più pulita, e sulle macchine recenti di solito anche la più rapida.
- Gateway a bordo macchina. Per i controlli datati o chiusi installiamo un piccolo gateway industriale su guida DIN. Legge la macchina nel suo linguaggio (seriale, Modbus, database locale, UDP) e inoltra i dati in HTTPS. Negli anni abbiamo usato Siemens IOT2050 e gateway edge Optix: il modello conta meno di quanto si pensi.
- Integrazione del costruttore. Per le macchine ancora da ordinare conviene che l'integrazione la faccia chi le costruisce. Gli consegniamo la specifica delle API e l'elenco dei dati da scambiare, e la macchina arriva già pronta.
- File o form a bordo macchina. Quando non c'è proprio nulla da collegare, l'operatore inserisce i dati da un form sul pannello o sul PC di reparto, oppure il sistema raccoglie il file che la macchina lascia a fine prova. Non è elegante, ma un dato inserito a mano e tracciato vale più di un foglio di carta che si perde.
Le quattro strade per collegare una macchina al software di gestione, con i casi in cui si usa ciascuna.
Leggere e scrivere
Un sistema che si limita a leggere è un cruscotto. Utile, ma fa metà del lavoro. Nei progetti che ci piacciono di più la comunicazione va nei due sensi.
In laboratorio funziona così. Il tecnico prepara la richiesta di prova nel software, con i parametri e la sequenza. La richiesta arriva alla macchina, che la mostra all'operatore in un popup sullo SCADA di bordo, e la prova parte. Misure e serie di dati tornano indietro mentre la prova gira e finiscono nella prova giusta, senza che nessuno le ricopi. A fine prova il report esce già compilato, sul modello Excel che il laboratorio usa da sempre.
Il ciclo di una prova: la richiesta scende alla macchina, i dati risalgono e il report si compila da solo.
Il risultato che i clienti citano più spesso è banale da dire: la preparazione dei report è passata da ore a minuti. Prima un tecnico raccoglieva i file dalle macchine, li incollava in un foglio e ricontrollava i numeri a mano. Quel lavoro adesso non c'è più. E ogni valore del report si può ricondurre alla prova, alla macchina, all'operatore e all'ora in cui è stato misurato, ed è la prima cosa che chiedono durante un audit.
Il cliente non deve chiamarci ogni volta
Qui c'è la scelta che ci distingue di più, ed è anche quella che richiede più lavoro in fase di progetto.
Un software di laboratorio o di reparto cambia di continuo. Arriva un nuovo tipo di prova. Un cliente chiede un campo in più nel certificato. Se ogni modifica passa dal fornitore, il fornitore diventa il collo di bottiglia, e il cliente comincia a odiare il software che ha pagato.
Per questo tutto quello che cambia spesso lo mettiamo in mano a chi usa il sistema. Nei laboratori R&D di un gruppo industriale internazionale, con sedi in tre paesi, il cliente aggiunge da solo le macchine nuove, definisce i tipi di prova e le procedure, disegna i moduli che i tecnici compilano e decide quali serie di dati raccogliere. I modelli di report li crea lui, in Excel, con la sua grafica e le sue formule. Gestisce utenti e permessi, anche agganciandoli ad Active Directory, e carica le tabelle di riferimento che servono ai calcoli.
Anche le regole stanno nella configurazione. Una colonna può comparire solo per certi tipi di prova. Un campo può diventare obbligatorio, o bloccarsi, a seconda di cosa c'è scritto in un'altra colonna, riga per riga. Un valore può essere calcolato da una formula e restare in sola lettura, così nessuno lo sovrascrive per sbaglio. In molti software servirebbe uno sviluppatore; qui lo fa il responsabile del laboratorio, e ogni modifica resta nel registro delle attività con nome e data.
Schema illustrativo di una tabella configurabile, con colonne attive in base al tipo di prova, campi obbligatori condizionali e valori calcolati da formula.
A noi restano i lavori da integratore, come collegare una macchina con un protocollo mai visto o mettere mano a un PLC. Preferiamo che l'assistenza serva per queste cose, e che per aggiungere un campo a un modulo nessuno debba aspettare una nostra telefonata.
Dopo l'avviamento: cosa configura il cliente in autonomia e cosa richiede un intervento di Contech.
API aperte, anche per gli altri
L'altra metà dell'autonomia sono le API. Il software espone le sue funzioni attraverso API REST documentate, le stesse che usano le macchine. L'IT del cliente le usa per portare i dati nel gestionale o in uno strumento di analisi. Il costruttore di una macchina nuova le usa per integrarla senza passare da noi.
Per ogni macchina c'è un contratto dati scritto: cosa legge dal sistema, cosa scrive, con quali chiamate. Sembra burocrazia. In realtà è il documento che permette a un'altra azienda, tra cinque anni, di collegare una macchina che oggi non esiste.
Un sistema chiuso tiene legato il cliente al fornitore. Noi preferiamo che il cliente resti perché il sistema funziona, e che sia libero di andarsene se un giorno smette di funzionare.
Nessuna porta aperta in ingresso
Quando si parla di collegare macchine alla rete, l'IT fa sempre la stessa domanda per prima: quali porte dobbiamo aprire? La risposta è nessuna, in ingresso.
Il traffico va in una sola direzione. Gateway e macchine chiamano il software in HTTPS sulla porta 443, in uscita, e dall'esterno nessuno può raggiungerli. I PLC restano sulla rete macchine, separata da quella aziendale, e non vengono mai esposti. Ogni macchina ha le sue credenziali, così se una va sostituita o dismessa si revoca solo quella. Anche l'assistenza remota passa da una VPN industriale che apre la connessione verso l'esterno.
Poi c'è un dettaglio che nessuno chiede e che prima o poi serve: tutti gli orologi sono sincronizzati via NTP. Sembra una sciocchezza finché non devi ricostruire la sequenza degli eventi di una prova durata giorni, con dati arrivati da tre dispositivi diversi.
Nei progetti con più stabilimenti installiamo un'istanza del software in ogni sito, così ogni sede lavora sui suoi dati, e una centrale che dà la vista di gruppo. Il codice è lo stesso ovunque, è la configurazione a decidere il ruolo. Sotto ci sono due database: uno relazionale per anagrafiche e prove, uno documentale per le serie di dati ad alta frequenza, che in un laboratorio crescono in fretta.
Architettura su più stabilimenti: macchine e gateway sulla rete di campo, un'istanza locale per sito e una centrale, con traffico solo in uscita su HTTPS.
Stesso metodo, clienti molto diversi
Nei laboratori R&D di cui abbiamo parlato il software gestisce richieste di prova, macchine e report su più paesi. Da un produttore romano di circuiti stampati, di cui abbiamo raccontato il progetto qui, connette la produzione e i consumi energetici delle singole macchine, misurati con contatori MID; da quando abbiamo scritto quell'articolo le macchine collegate sono aumentate parecchio. E ci sono altri progetti, più piccoli, di cui non possiamo fare i nomi.
Quello che si ripete è il metodo: un giro in reparto macchina per macchina, la scelta della strada di collegamento, un contratto dati scritto e un sistema che il cliente possa far evolvere da solo.
Una base nostra, rifatta per ogni cliente
Ci chiedono spesso se vendiamo un prodotto. La risposta onesta è: in parte.
Abbiamo una base software nostra su cui lavoriamo da anni. Dentro c'è quello che abbiamo imparato collegando un centinaio di macchine: i connettori per i protocolli, la gestione di utenti e permessi, il registro delle attività, il motore dei report. Ci permette di non ripartire da zero e di non rifare errori già fatti.
Nessun cliente però riceve la stessa cosa. Ogni progetto parte da come lavora quel laboratorio o quel reparto, con i suoi nomi e i suoi report, e la base viene ricostruita attorno a quello. Il software in scatola funziona finché il vostro processo somiglia a quello che aveva in mente chi l'ha progettato. Quando non somiglia, è il reparto che deve adattarsi, e a noi sembra il contrario di quello che serve.
Se avete una sala prove o un reparto con macchine di epoche diverse, e i dati viaggiano ancora su chiavette e fogli Excel, scriveteci a info@contech.xyz. Partiamo sempre da un giro in reparto, macchina per macchina.
Argomenti trattati
