IIoT e Odoo MRP: una guida tecnica senza semplificazioni

Nelle produzioni manifatturiere, il problema non è quasi mai la mancanza di dati. È che i dati esistono sull'HMI della macchina, nel foglio del capoturno e nella testa dell'operatore, ma non nel sistema gestionale. Chi pianifica lavora su informazioni in ritardo, chi controlla i costi non ha consuntivi reali, e il modulo MRP finisce per essere aggiornato a fine giornata, quando le decisioni sono già state prese.

Integrare l'IIoT con Odoo 19 MRP significa chiudere questo gap in modo strutturale. Questo articolo descrive l'architettura reale, i protocolli coinvolti e i limiti che è necessario conoscere prima di progettare qualsiasi cosa. Non è una guida introduttiva: presuppone familiarità con PLC, reti industriali e il funzionamento interno di Odoo. Se stai ancora valutando se e perché questo approccio ha senso per la tua realtà produttiva, ti consigliamo di partire da MRP vs MES: quando e come Odoo trasforma il controllo della produzione.

1. Cosa fa davvero l'integrazione

I segnali generati da PLC, CNC, sensori e strumenti di misura diventano eventi che Odoo interpreta e traduce in azioni sul flusso produttivo. Un ciclo completato dalla macchina avanza l'ordine di produzione. Un'assenza prolungata di carico elettrico genera una richiesta nel modulo Maintenance. Una misura fuori tolleranza blocca il passaggio alla fase successiva nel Quality Control Point.

La distinzione rilevante per un pubblico tecnico: non si sta parlando di reportistica retroattiva, ma di aggiornamento dello stato del work order in base a eventi reali. Odoo rimane però un ERP, non un MES né un sistema SCADA. La sua architettura — ORM su PostgreSQL, polling HTTP, transazioni sincrone — introduce latenze nell'ordine dei secondi, non dei millisecondi. Chi si aspetta reattività real-time stretta deve integrare un MES dedicato tra il layer OT e Odoo, usando Odoo esclusivamente come sistema di record per pianificazione, costi e reportistica.

2. Architettura: tre livelli, non uno

L'errore più comune nelle valutazioni preliminari è pensare all'integrazione come a un collegamento diretto tra macchina e Odoo. In pratica, l'architettura si articola su tre livelli distinti, ciascuno con implicazioni tecniche proprie.

Livello 1 — Layer di connettività (OT)

OPC UA è il protocollo di riferimento per PLC moderni. A partire da Odoo 15, l'IoT Box include un client OPC UA che può leggere i nodi esposti dal server OPC UA del PLC. Il termine "supporto nativo" va però qualificato: non significa zero configurazione. Il mapping tra i nodi OPC UA del PLC e le variabili Odoo richiede una fase di setup dipendente dal modello della macchina, dalla versione del firmware e dalla struttura dell'address space esposta. Su impianti con decine di variabili e namespace custom, questo lavoro non è triviale. Non aspettarti un'interfaccia di discovery automatica.

Per ambienti con dispositivi eterogenei o macchine che non espongono OPC UA, il pattern più robusto è un middleware intermedio: Node-RED, Kepware, Ignition Edge, o un broker MQTT come EMQX. Il middleware raccoglie i dati dal layer OT, li normalizza e li invia a Odoo via REST API o via JSON-RPC. Questo introduce un componente aggiuntivo da mantenere, ma garantisce la separazione netta tra rete OT e rete IT — separazione quasi sempre richiesta da politiche di sicurezza o da normative di impianto.

Nota: MQTT non è un canale nativo verso Odoo. Il broker MQTT gestisce la comunicazione nel layer OT/middleware; la traduzione verso Odoo avviene comunque via REST o JSON-RPC sul lato IT. Presentare MQTT e REST come alternative equivalenti verso Odoo è tecnicamente impreciso.

Per i macchinari datati senza interfaccia digitale, la strada è il retrofitting con sensori esterni: conta-pezzi ottici, current transformer sulla linea di alimentazione, accelerometri. I dati vengono acquisiti da un microcontrollore o da un gateway IoT dedicato e inviati a Odoo tramite API. Il TCO di questa soluzione è il più alto dell'intero spettro, ma spesso è l'unica opzione praticabile su impianti degli anni Novanta.

Livello 2 — IoT Box di Odoo 19

L'IoT Box supporta connessione via Ethernet o Wi-Fi ed è compatibile con dispositivi USB riconosciuti dal sistema. Bluetooth è presente ma marginale per applicazioni MRP.

Windows Virtual IoT Box: la versione Windows Virtual IoT (disponibile già da Odoo 16, non una novità della 19) abbassa la barriera di entry, ma ha una limitazione critica: i dispositivi MRP — incluse telecamere di controllo e strumenti di misura — non sono compatibili con questa modalità. Per qualsiasi utilizzo che coinvolga il modulo MRP, è richiesta l'IoT Box fisica.

Sul fronte dei costi, è importante distinguere i due casi. La IoT Box fisica richiede una sottoscrizione attiva al costo di 30 USD/mese per box (il prezzo pubblicato da Odoo è in dollari; la conversione in euro dipende dal tasso di cambio e dalla localizzazione contrattuale). La Windows Virtual IoT segue invece un regime diverso: per gli utenti con sottoscrizione Enterprise può essere attivata gratuitamente richiedendolo al proprio account manager Odoo, a condizione di non utilizzare una IoT Box fisica.

Dal punto di vista della sicurezza: la documentazione ufficiale Odoo specifica esplicitamente che né la IoT Box né la Windows Virtual IoT devono mai essere esposte su internet pubblico. Sono sistemi pensati per la LAN. Chi progetta l'infrastruttura deve tenerne conto nella segmentazione di rete, indipendentemente dal middleware scelto.

Livello 3 — Modulo MRP e trigger automatici

Una volta che i dati arrivano a Odoo, è il modulo MRP a contestualizzarli. In Odoo 19 Enterprise i work center possono avere dispositivi IoT associati: quando la macchina invia il segnale di fine ciclo, Odoo può aggiornare lo stato del work order, scalare i componenti dal magazzino e registrare i tempi reali di lavorazione.

3. OEE in Odoo 19: cosa misura davvero

Questo è il punto dove la documentazione informale — inclusa molta letteratura di terze parti — introduce le imprecisioni più significative.

Odoo 19 calcola un indice OEE, accessibile da Manufacturing → Reporting → Overall Equipment Effectiveness. È un punto di partenza concreto rispetto alla gestione manuale su foglio di calcolo: i dati vengono consolidati in tempo reale e offrono visibilità immediata sulle derive rispetto ai tempi pianificati. Tuttavia il modello implementato non corrisponde ai tre fattori dell'OEE industriale standard (ISO 22400-2: Availability × Performance × Quality). Odoo calcola l'OEE come rapporto tra la durata attesa del work order e il tempo totale trascorso, inclusi i blocchi. È un indicatore semplificato di aderenza al tempo pianificato.

I tre indici tradizionali (disponibilità, performance, qualità) non sono presenti come componenti separati nel pannello standard di Odoo 19. Chi necessita di un OEE conforme ISO 22400-2 deve implementarlo tramite moduli custom o via reporting esterno su dati Odoo. Va progettato esplicitamente; non è attivabile con una configurazione.

Nota: Verifica sempre sulla documentazione ufficiale della versione target (docs.odoo.com) prima di comunicare funzionalità OEE al cliente. Le feature di reporting cambiano tra release minori.

4. Manutenzione: predittiva vs. basata su soglie

Il modulo Maintenance di Odoo è disponibile in forma base anche nella versione Community; alcune funzionalità avanzate richiedono Enterprise. La distinzione non è binaria come spesso presentata.

La generazione automatica di richieste di intervento da segnale IoT richiede automation rules configurate sul superamento di una soglia su una variabile IoT. In pratica, il supporto nativo di Odoo per trigger basati su valori di campo IoT ha limiti: le automation rules standard operano su eventi del modello ORM (creazione/modifica di record), non su stream di dati continui da sensori. Per trigger su soglie di variabili IoT in tempo reale, nella quasi totalità dei casi è necessario sviluppo custom — un listener esterno o un cronjob che valuta i valori e crea la richiesta via RPC. Presentarlo come alternativa equivalente a uno sviluppo custom è fuorviante.

La manutenzione predittiva vera — modelli di degradazione basati su vibrazioni, temperatura, corrente — esula completamente dal perimetro nativo di Odoo e richiede un layer ML/analytics esterno (es. Python + scikit-learn, o piattaforme come AWS Lookout for Equipment) con integrazione verso Odoo via API per la creazione degli ordini di lavoro.

5. Quality Control Points e misure automatiche

Il modulo Quality di Odoo 19 (Enterprise) supporta Quality Control Points integrati nei work order. La registrazione automatica di misure da strumenti digitali connessi via IoT Box è tecnicamente realizzabile, ma condizionata alla compatibilità dello strumento con i driver gestiti dall'IoT Box.

Il catalogo di compatibilità ufficiale Odoo è il riferimento vincolante: non assumere compatibilità in base al protocollo esposto dallo strumento. Calibri e strumenti di misura con output RS-232 o Mitutoyo Digimatic richiedono verifica esplicita prima di qualsiasi impegno progettuale.

6. Enterprise vs Community: una decisione architettonica

La scelta tra le due edizioni precede qualsiasi decisione tecnica sull'integrazione IIoT. Il perimetro rilevante:

• OEE reporting: Enterprise
• Quality Control Points con integrazione IoT: Enterprise
• Work Center con dispositivi IoT associati in MRP: Enterprise
• Maintenance base: Community. Funzionalità avanzate IoT-triggered: Enterprise o custom
• IoT Box fisica: richiede sottoscrizione attiva indipendentemente dall'edizione (~30 €/mese per box)

7. Segmentazione OT/IT

Un progetto IIoT manifatturiero non può prescindere dalla separazione tra rete operativa (OT) e rete informatica (IT). Le motivazioni sono sia di sicurezza (i dispositivi OT non devono essere raggiungibili dall'esterno; un incidente sulla rete IT non deve impattare la produzione) sia di stabilità del protocollo (i traffic pattern OT — alta frequenza, bassa latenza — sono incompatibili con una rete IT generica).

Il gateway o middleware intermedio assolve anche questa funzione di demilitarized zone protocollare, oltre a quella di traduzione. Definire la topologia di rete prima dell'implementazione — con VLAN dedicate, firewall tra OT e IT, e una DMZ per il gateway — è uno dei punti critici più sottovalutati nelle fasi di presales. Progettarla in corso d'opera è significativamente più costoso.

8. Da dove iniziare: approccio pilota

Un pilota su un singolo work center riduce il rischio e permette di validare l'intera catena: macchina → protocollo → gateway → IoT Box → MRP. La macchina su cui avviare il pilota non è necessariamente la più nuova, ma quella su cui il dato in tempo reale ha l'impatto maggiore sulla pianificazione o sui costi — tipicamente un collo di bottiglia o un'attrezzatura con alta varianza nei tempi ciclo.

Prima di avviare il pilota, definire esplicitamente:

• Quali protocolli espongono i PLC target (OPC UA, Modbus TCP, EtherNet/IP, Profinet?)
• Quale gateway/middleware si usa e chi lo mantiene
• Quale topologia di rete OT/IT si adotta
• Quali funzionalità richiedono Enterprise e quali sono realizzabili in Community o con sviluppo custom
• Qual è la latenza accettabile per gli aggiornamenti di stato in MRP