Ignition 8.3: le novità per gli integratori

Novità principali e impatto pratico sui progetti di integrazione

Nei progetti Ignition Enterprise, tre elementi determinano la complessità di implementazione e i costi di manutenzione nel lungo periodo: la gestione dello storico, l’integrazione con sistemi eterogenei e la gestione del ciclo di vita delle configurazioni.

Ignition 8.3 affronta questi tre punti critici con soluzioni che cambiano di riflesso anche la gestione economica dei progetti.

Queste non sono soluzioni “magiche”: per ottenere benefici reali servono scelte progettuali precise, test di carico, politiche di retention e una governance dei dati chiara. In pratica, l’adozione efficace di 8.3 passa sempre per attività concrete che noi consigliamo e applichiamo: inventario dei tag, co-design, modellazione dei tipi di evento, staging, stress test e policy di sicurezza valutate con l’IT.

In Eureka System applichiamo questo approccio quotidianamente: siamo il partner tecnico di sviluppo dei MES basati su Ignition per realtà di produzione italiane come Menz&Gasser S.p.A., GranTerre S.p.A. e 3B S.p.A. Queste implementazioni ci hanno consentito di valutare sul campo quali combinazioni e pratiche offrano vantaggi misurabili in termini di sviluppo, manutenzione, time-to-restore e facilità di upgrade.

Modulo Historian

Ignition 8.3 introduce la Historian Module Suite composta dall’Historian Core e dal SQL Historian.

L‘Historian Core, basato su QuestDB, è progettato come un historian “no-maintenance”: offre aggregazioni e roll-up nativi, ottimizzazioni per time-series e prestazioni di lettura/scrittura sensibilmente superiori rispetto al precedente provider interno. Nella pratica, questo significa che molti casi d’uso edge o di piccolo/medio impianto possono essere coperti senza l’installazione e il tuning di un database esterno, riducendo la complessità operativa e le competenze necessarie nella fase iniziale.

Dalle nostre esperienze su progetti MES Ignition, l’adozione del Core per PoC e commissioning potrebbe tradursi in un risparmio operativo reale (tipicamente nell’ordine di giorni, su un progetto medio), soprattutto quando lo sforzo precedente era dedicato al provisioning, al tuning e alle connessioni a DB esterni. Va però ricordato che il valore effettivo dipende dal carico di ingest, dalla retention richiesta e, in generale, dalle politiche di governance dei dati.

Per scenari enterprise con esigenze di retention a lungo termine, compliance o reporting consolidato, la nuova Suite offre SQL Historian come opzione per integrare database relazionali o time-series di livello enterprise. Un’architettura consigliata è quella ibrida: Core per l’analisi in tempo reale, vicino alle macchine e alle automazioni; replica asincrona del database centrale per l’archiviazione, l’audit e il reporting.

La nuova Suite fornisce inoltre strumenti per modellare ricchi metadati per usare fonti read-only (CSV, tabelle DB) come storici di riferimento e introduce una public API che permette agli sviluppatori di moduli di implementare historian personalizzati, trasformando Ignition in una piattaforma estendibile per soluzioni di storage temporale. In termini pratici: maggiore flessibilità architetturale, meno vincoli proprietari e la possibilità di scegliere il bilanciamento tra prestazioni locali e governance centralizzata.

Modulo Event Streams e integrazione con Kafka

Per le aziende che devono integrare MES e flussi IIoT complessi, Ignition 8.3 rende più semplice la realizzazione di architetture robuste e aggiornabili. Il nuovo Event Streams in Ignition 8.3 è pensato per portare nativamente sulla piattaforma il concetto di stream processing leggero.

Il nuovo Event Streams è un ponte per gestire flussi di eventi, una vera e propria infrastruttura per modellare, filtrare e trasformare eventi (tag, allarmi, record di DB, messaggi Kafka) direttamente sul Gateway. Questo approccio riduce spesso la necessità di sviluppare middleware Python ad hoc per le integrazioni asincrone tra il MES e l’ERP o con i pipeline di analytics, perché consente di definire pipeline, trasformazioni e regole di routing in modo dichiarativo e centralizzato.

Ovviamente Event Streams semplifica molto le integrazioni standard, ma per trasformazioni molto complesse o logiche distribuite potrebbe ancora servire codice custom o microservizi dedicati. È però un ottimo strato di prima linea che, decentrando la logica più comune, riduce la complessità dei servizi esterni.

Se progettato con cura, il risultato è una pipeline di eventi che riduce i workaround e facilita l’integrazione con ecosistemi basati su Kafka e altri sistemi enterprise.

Configurazione file-based e uso di Git

La nuova interfaccia Gateway è più veloce e scalabile, con ricerca globale e diagnosi integrate. Sì, finalmente possiamo gestire progetti Ignition con branch, merge request e CI/CD. Cosa significa praticamente? La modalità Gateway deployment semplifica la gestione multiambiente (dev, stage, prod). Questo trasforma la gestione dei deployment multi-gateway in workflow automatizzati e tracciabili.

La configurazione, la diagnostica e la ricerca globale sono più accessibili, il che facilita il troubleshooting. In Ignition 8.3 la migrazione verso il file-based storage trasforma progetti e tag in risorse testuali, rendendoli immediatamente compatibili con Git. Questo apre possibilità concrete, ma richiede che il team di sviluppo adotti convenzioni per il naming, il linting e i test automatici per evitare regressioni e altri problemi.

Altri miglioramenti ai moduli Ignition

Ignition 8.3 introduce anche una serie di miglioramenti al modulo Perspective, alla gestione del Gateway, al modello di storage dei progetti e alle opzioni di deployment. Più che elenchi di feature, qui riportiamo cosa cambia davvero nel processo di sviluppo e quali vantaggi si possono attendersi.

Il nuovo Drawing Editor di Perspective

Il modulo Perspective si arricchisce di strumenti di disegno avanzati e di form personalizzabili.

Il nuovo Drawing Editor, ad esempio, porta in Designer un editor vettoriale (SVG) “first-class”, utile per creare e modificare grafiche HMI senza dover passare per tool esterni. In questo modo si riducono i passaggi e i tempi quando si iterano i dashboard e i simboli della macchina.

Da considerare, però, che binding massicci di elementi SVG a tag dinamici possono aumentare l’uso di CPU e di memoria sul client; per questo, il nostro consiglio per evitare sorprese di performance in produzione è di limitare il numero di binding attivi nelle visualizzazioni critiche e di usare grouping o virtualizzazione per gli elementi ripetitivi.

Nota interessante: anche gli SVG possono essere versionati e mantenuti come file testuali nella repository Git per la review e il rollback!

Allo stesso modo, il form generator automatizza la creazione di form responsivi con logica condizionale e validazione client-side, utili per raccogliere dati lot-by-lot o per eseguire check di qualità, ma bisogna predisporsi a una buona modellazione dei campi e alla gestione delle regole di validazione, per non trasferire la complessità dal front-end al run-time.

Un altro cambiamento è il supporto offline per l’app mobile, una novità importante per i siti con copertura intermittente: consente di inserire dati in assenza di rete e di sincronizzare al ripristino della connettività. Questo funziona bene per casi d’uso come interventi di manutenzione o la raccolta di parametri in magazzino, ma occorre validare i meccanismi di conflitto/sync e le politiche di retry in scenari reali. Consigliamo di includere test e scenari di rete degradati nel PoC!

REST API integrata

La REST API integrata in Ignition 8.3 cambia il paradigma: non si tratta più di “espedienti” per collegare tool esterni, ma di un nuovo canale primario per programmare e orchestrare la piattaforma. Questo apre scenari concreti di sviluppo, ma impone anche una certa disciplina operativa. In pratica, è necessario definire e versionare endpoint e chiamate, e usare ambienti di staging per testare le automazioni prima di eseguirle in produzione.

Dal punto di vista della sicurezza, ogni integrazione via API deve essere accompagnata da autenticazione forte, logging centralizzato e rate limiting: senza queste misure, l’automazione si apre a rischi di sicurezza.

Per trasformare questa novità in valore operativo, consigliamo di partire da casi d’uso ben delimitati, misurare latenza e carico e poi generalizzare le procedure e le policy di governance delle API.

Allarmi e notifiche con WhatsApp, Twilio Voice e metriche ISA 18.2

Le integrazioni con WhatsApp e Twilio Voice ampliano i canali operativi per le notifiche e, in combinazione con le nuove metriche ISA 18.2, offrono una visibilità più strutturata sugli allarmi.

Questo è utile per ridurre i tempi di intervento, ma rischia di aumentare il “rumore” se non gestito. Per ottenere valore concreto è necessario razionalizzare gli allarmi, definire soglie e regole di soppressione, deduplicazione ed escalation, e monitorare metriche di rumore, ad esempio il tasso di allarmi per operatore.

L’uso di canali VoIP o di messaggistica, ovviamente, deve essere protetto con chiavi API e limitazioni agli accessi, e inserito in playbook operativi: chi riceve cosa, quando e con quale priorità.

Modulo Driver Siemens

La versione 8.3 introduce un nuovo driver Siemens che consente una connettività senza interruzioni con i PLC Siemens.

Questo nuovo driver supporta la navigazione tra le risorse, l’accesso simbolico e l’accesso diretto ai canali I/O, senza la necessità di riconfigurazioni manuali.

Sul campo, ciò si traduce in meno errori di mapping e in setup più rapidi, soprattutto su macchine con ampi dizionari di variabili. Tuttavia, occorre verificare la compatibilità del firmware dei PLC, eventuali limitazioni e l’impatto sul polling e sul throughput.

Prima di estendere la soluzione su scala, consigliamo di predisporre politiche di caching e di rate limiting adeguate per evitare il sovraccarico della rete. In fase di progetto, bisognerà tenere conto anche delle policy di accesso e della gestione delle versioni.

Un controllo accessi più granulare per le tag

Il supporto a OPC UA 1.05 e l’introduzione di OPC UA Roles in Ignition 8.3 consentono un controllo dell’accesso a tag, dispositivi e cartelle molto più granulare.

Questa novità è particolarmente rilevante in impianti multi-tenant o in contesti in cui è necessario separare i permessi tra reparti o fornitori esterni.

Dal punto di vista operativo, sfruttare i ruoli significa sviluppare politiche di accesso basate sul principio del minimo privilegio e gestire certificati e trust list in modo coerente. Prima di abilitare ruoli estesi, sarà necessario verificare la compatibilità dei client e predisporre un piano di rollout che includa test di accesso, revoca e audit delle sessioni: la sicurezza operativa migliora solo se la gestione dei ruoli è supportata da processi e strumenti di governance.

Containerizzazione e orchestrazione: vantaggi e vincoli da considerare

Tra le altre cose, Ignition 8.3 facilita l’adozione di container e orchestratori come Kubernetes, rendendo più semplice l’allineamento dei progetti SCADA/MES alle policy IT aziendali. I vantaggi reali sono la riproducibilità degli ambienti, la possibilità di deployment automatizzati e la gestione centralizzata delle immagini. Tuttavia, la containerizzazione di Ignition richiede alcune decisioni architetturali: dove collocare i dati persistenti, come gestire backup e restore, quali risorse assegnare (CPU e memoria), eccetera. Non basta “containerizzare”: serve disegnare il modello di storage, integrare il logging e il monitoring e definire strategie per gli aggiornamenti e le recovery.