Integrare Exchanger in un progetto software: tempi e modalità per system integrator
Per un system integrator che valuta Exchanger per un progetto cliente, la domanda pratica non è solo “cosa fa il middleware”, ma “cosa devo fare io per integrarlo, e quanto tempo mi porta via”. Questo articolo descrive il percorso tipico, dal primo contatto tecnico all’integrazione a regime.
Il percorso tipico di un’integrazione
1. Analisi dei macchinari del progetto
Il punto di partenza è sempre capire cosa c’è da collegare: quali macchine, quali protocolli espongono (OPC UA, Fanuc FOCAS, Siemens S7, Modbus, o altri), e se ci sono macchinari legacy privi di connettività nativa che richiedono un adattatore hardware. Questa analisi tecnica è congiunta tra il system integrator e il team di Campi, e serve a definire con precisione lo scope del progetto prima di iniziare.
2. Configurazione dei driver
Per i protocolli standard già supportati da Exchanger, la configurazione consiste nell’identificare i segnali utili sulla macchina (stati, contatori, allarmi, parametri di processo) e mapparli nel formato normalizzato che il middleware espone. Per macchinari legacy o protocolli non standard, questa fase può includere lo sviluppo di un driver custom.
3. Integrazione con il software del system integrator
Una volta che Exchanger espone i dati normalizzati — via API REST, database o server OPC UA — il team del system integrator li integra nel proprio software secondo l’architettura già esistente. Non è richiesto riscrivere il software attorno al middleware: Exchanger si adatta al canale di accesso che il software già utilizza.
4. Test su impianto pilota
Prima di estendere l’integrazione a tutto il parco macchine del cliente finale, è buona pratica validare il funzionamento su un numero limitato di macchine, verificando che i dati ricevuti corrispondano a quanto la macchina sta effettivamente facendo.
5. Estensione e messa a regime
Una volta validato il pilota, l’estensione alle altre macchine segue lo stesso schema, con tempi generalmente più rapidi perché le scelte architetturali principali sono già state prese.
Cosa serve dal lato del system integrator
- Conoscenza dell’architettura del proprio software e di come consumerà i dati (API, database, OPC UA)
- Accesso, anche solo documentale in fase iniziale, ai macchinari del cliente finale
- Un referente tecnico del cliente finale per la fase di test sul campo
Non è richiesta una conoscenza approfondita dei protocolli industriali specifici delle macchine: è proprio questo il lavoro che il middleware assorbe.
Supporto tecnico durante l’integrazione
Per i casi che richiedono driver custom o macchinari particolarmente datati, il team tecnico di Campi affianca il system integrator nell’analisi dei segnali disponibili e nella configurazione, invece di lasciare l’intero lavoro di analisi del protocollo al team esterno. L’obiettivo è che il system integrator possa concentrarsi sul proprio software, non sul reverse engineering dei protocolli macchina.
Se stai valutando Exchanger per un progetto cliente e vuoi capire tempi e modalità specifiche per il tuo caso, contattaci per un’analisi tecnica: partiamo sempre dai macchinari e dal software reali del progetto, non da uno schema generico.