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 portino 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 a provisioning, tuning e 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 il SQL Historian come opzione per integrare database relazionali o time-series di livello enterprise. Un’architettura consigliata è quella ibrida: Core per analisi real-time vicino alle macchine e alle automazioni; replica asincrona verso SQL centrale per archiviazione, audit e reporting.

La nuova Suite fornisce inoltre strumenti per modellare ricchi metadati, usare fonti read-only (CSV, tabelle DB) come storici di riferimento e introduce una public API che permette agli sviluppatori di moduli di implementare propri historian custom, 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 flussi IIoT complessi, Ignition 8.3 rende più semplice costruire architetture robuste e aggiornabili. Il nuovo Event Streams in Ignition 8.3 è pensato per portare in modo nativo nella 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 pipeline di analytics, perché permette 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 abbassa 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 di deployment multi-gateway in workflow automatizzati e tracciabili.

Configurazione, diagnostica e ricerca globale sono più accessibili, il che facilita il troubleshooting. In Ignition 8.3 la migrazione verso 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 su naming, linting e 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 realmente in termini di sviluppo e quali vantaggi aspettarsi.

Il nuovo Drawing Editor di Perspective

Il modulo Perspective si arricchisce con strumenti di disegno avanzati e 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 passare per tool esterni. In questo modo si riducono passaggi e tempi quando si iterano dashboard e simboli della macchina.

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

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

Allo stesso modo, il form generator automatizza la costruzione di form responsivi con logica condizionale e validazione client-side, utili per raccogliere dati lot-by-lot o eseguire check di qualità, ma bisogna predisporsi per fare una buona modellazione dei campi e di gestione delle regole di validazione per non spostare 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: permette di inserire dati in assenza di rete e sincronizzare al ripristino della connettività. Questo funziona bene per casi d’uso come interventi di manutenzione o raccolta di parametri in magazzino, però 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 di avere una certa disciplina operativa. In pratica, è necessario definire e versionare endpoint e chiamate, e usare ambienti di staging dove 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 garanzie, 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 procedure e policy di governance 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, combinate alle 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 come ad esempio il rate degli allarmi per operatore.

L’uso di canali VoIP o messaggistica ovviamente deve essere protetto con chiavi API e limitazione degli 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 necessità di riconfigurazioni manuali.

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

Prima di estendere la soluzione su scala, consigliamo di predisporre adeguate politiche di caching e rate limiting per evitare sovraccarico della rete. In fase di progetto bisognerà tener 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 permettono un controllo molto più granulare sull’accesso a tag, dispositivi e cartelle.

Questa novità è particolarmente rilevante in impianti multi-tenant o in contesti dove è 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 allineare i 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 risiedono i dati persistenti, come gestire backup e restore, quali risorse assegnare come CPU e memoria, eccetera. Non basta “containerizzare”: serve disegnare il modello di storage, integrare il logging e il monitoring e prevedere strategie per aggiornamenti e recovery.