Un system integrator eredita una macchina che funziona da anni, finché non cede la scheda di controllo. È un progetto custom di un fornitore che nel frattempo ha chiuso. Nessun sorgente, nessun secondo fornitore, un componente di controllo fuori produzione. La macchina si ferma per una scheda che non esiste più, mentre la stessa funzione su un controllore standard sarebbe tornata in linea in un pomeriggio. Lo scenario è noto a chiunque lavori in campo, e dice una cosa precisa: la scelta dell’unità di controllo, in un progetto nuovo, non si decide su chi è capace di fare il lavoro. Sul piano delle capacità grezze PLC, IPC e piattaforme embedded si sovrappongono ormai a tal punto che sbagliare per incapacità tecnica è raro. Si sbaglia piuttosto per contesto, ovvero per volume, manutenzione, certificazione e ciclo di vita. E negli ultimi due anni una variabile in più ha rimescolato le carte, perché il controllo ha iniziato a staccarsi dall’hardware che lo esegue. Vale la pena vedere dove ciascuna strada conviene davvero, e perché.
PLC: il prezzo della robustezza è il lock-in
Il PLC vince quando il sistema lo manterrà qualcun altro. Il manutentore del cliente apre il progetto IEC 61131-3 e legge la logica senza conoscere il codice a priori, i moduli si sostituiscono con ricambi a magazzino, la diagnostica è standardizzata. Per un costruttore di macchine questo non è un vantaggio tecnico, è un vantaggio di modello di business: il sistema non ti rende una dipendenza permanente del cliente.
Il punto che spesso si tace è il rovescio di quella robustezza. La mantenibilità del PLC è alta dentro il suo ecosistema, ma quell’ecosistema è chiuso: toolchain proprietaria, licenze, formazione specifica per vendor e moduli che dialogano bene solo con i fratelli dello stesso marchio. In sostanza si scambia il lock-in sul proprio know-how, tipico del custom, con il lock-in su un fornitore di automazione. Per un parco macchine eterogeneo questo significa più ambienti di sviluppo da presidiare e margini di acquisto dettati dal vendor. Lo standard IEC 61131-3 promette portabilità, ma nella pratica librerie, blocchi funzione proprietari e gestione hardware restano specifici, al punto che portare un progetto da un marchio all’altro è più una riscrittura che un’esportazione.
Restano due vantaggi che un confronto onesto non può ignorare. Il primo è la sicurezza funzionale: un PLC safety porta blocchi certificati fino a un certo SIL o Performance Level, e costruire un arresto di emergenza sopra funzioni già validate evita di certificare da zero una catena propria. Il secondo è la longevità: disponibilità di prodotto e ricambi su orizzonti di quindici anni e oltre, con percorsi di migrazione documentati. Per un impianto che resta in linea due decenni, questi due elementi pesano più del costo unitario, che resta alto. Il PLC conviene dove i volumi sono bassi e il sistema è una macchina, non un prodotto replicato in serie.
IPC: la consolidazione e il limite del determinismo
L’IPC entra quando il collo di bottiglia non è il controllo ma i dati. Visione ad alta risoluzione, inferenza al bordo, storicizzazione di flussi densi, gateway verso i livelli MES: compiti dove un soft-PLC su PC industriale fa quello che un PLC fatica a gestire, e li fa sullo stesso hardware che esegue la logica. La forza dell’IPC è la consolidazione: in una sola macchina convivono il soft-PLC che gestisce la logica, il sistema di visione che ispeziona il pezzo e il livello di edge computing che decide cosa elaborare in locale e cosa mandare al cloud. Il risultato sono meno nodi separati, meno cablaggi e meno punti di guasto.
Qui il confronto interessante non è “l’IPC è più potente”, che è ovvio, ma capire perché, nonostante la potenza, il controllo di moto stretto continua a non girare sull’IPC. Un kernel real-time tipo Preempt-RT su hardware con core isolato porta il jitter a poche decine di microsecondi, eppure il sistema operativo general purpose resta una sorgente di non determinismo difficile da azzerare. Gestione della cache, traffico DMA, interruzioni di sistema come gli SMI che il firmware nasconde al sistema operativo: sono fenomeni che producono code di latenza rare ma reali. Per questo la sincronizzazione di assi a microsecondi viene quasi sempre delegata a un bus deterministico come EtherCAT o a un controllore di moto dedicato. L’IPC orchestra, l’anello veloce gira altrove, e chi ignora questa divisione costruisce sistemi che reggono in laboratorio e perdono colpi sotto carico.
Il secondo limite è la superficie da gestire. Un sistema operativo completo porta con sé aggiornamenti, patch e tempi di boot non istantanei. Porta anche una superficie d’attacco che in ambiente OT va presidiata con le logiche di difesa proprie della sicurezza dei sistemi di controllo industriali secondo IEC 62443. Un IPC mal gestito, in fondo, non è il cervello dell’impianto ma il suo anello debole.
Embedded custom: non è “il microcontrollore”
La terza strada viene quasi sempre etichettata come MCU, ed è una semplificazione che porta fuori strada. L’elettronica embedded su misura è in realtà un continuum di soluzioni, e la scelta interna pesa quanto quella tra le tre macro-opzioni. All’estremo del controllo deterministico, a basso consumo e con timing stretto, sta la MCU. Quando contano compute, interfacce e connettività si sale verso un SoC o un modulo SoM con Linux. E dove il timing va risolto in hardware, o serve elaborazione parallela su flussi veloci, si arriva a un FPGA o a un SoC con fabric programmabile. La domanda, in altre parole, non è quale chip scegliere, ma quale tipo di elaborazione deve stare a bordo.
Questa strada vince quando l’unità di controllo non è una macchina da installare, ma un prodotto da fabbricare in serie. Sarebbe un equivoco, però, pensarla ancora come la scheda che pilota un relè. In un contesto Industria 4.0, e ancora di più nella direzione 5.0 dove il dato e la collaborazione uomo-macchina diventano centrali, il dispositivo custom nasce come nodo dell’architettura embedded industriale: acquisisce, elabora al bordo e dialoga via MQTT o OPC UA con i livelli superiori. Quando deve raccogliere dati di campo, applicare logica locale e inoltrarli verso cloud o MES, la piattaforma embedded diventa di fatto il gateway tra sensori e sistema informativo. Valgono allora le stesse regole di robustezza che definiscono un buon nodo IIoT, dal watchdog alla gestione dei dati persistenti.
Dove si sposta il punto di pareggio
Per un esperto la domanda non è se esista un break-even di volume, che è ovvio, ma cosa lo sposta. Il costo non ricorrente di una soluzione custom non è solo progettazione hardware e firmware: è la certificazione. Marcatura CE, test EMC e, soprattutto, l’eventuale sicurezza funzionale ricadono interamente su chi sviluppa, e una catena safety certificata da zero alza il punto di pareggio di un ordine di grandezza.
Due forze recenti lo stanno muovendo in direzioni opposte. Da un lato i moduli SoM industriali pre-certificati abbassano la soglia, perché spostano una quota di NRE e di rischio EMC sul fornitore del modulo. Il custom diventa così conveniente anche a volumi più bassi di un tempo. Dall’altro l’obsolescenza del silicio la alza, perché impone di presidiare gli ultimi acquisti programmati e le migrazioni di componente, un lavoro che su un PLC fa il costruttore al posto tuo. L’ordine di grandezza resta indicativo, con qualche centinaio di pezzi come soglia bassa e il migliaio come zona in cui il custom inizia a vincere. Il numero esatto, però, dipende quasi sempre dal peso della certificazione, non dal costo del chip.
La virtualizzazione che sta riscrivendo le regole
Il fatto nuovo, quello che rende datata la vecchia tripartizione, è il distacco del controllo dall’hardware che lo esegue. Il vPLC, il PLC virtuale containerizzato, non è più un concetto da convegno. Diversi vendor hanno rilasciato runtime di controllo che girano come container conformi a standard OCI su hardware x86 standard, su edge server o dentro macchine virtuali in un data center. La logica di controllo, per decenni inchiodata a un dispositivo in armadio, diventa un’immagine deployabile come un microservizio qualsiasi.
La spinta è arrivata più dal mondo IT e dagli OEM che dai costruttori di PLC. È la naturale prosecuzione del trend in cui l’IT scende verso il bordo e l’OT sale verso il cloud, come documentano le analisi di mercato sul vPLC. Il caso più citato è una linea di assemblaggio assi di un grande gruppo automotive, in produzione dal 2024. Lì la logica di controllo è consolidata su PLC virtuali in un data center a chilometri dalla fabbrica, mentre sensori e attuatori restano a bordo macchina.
Per un progettista questo cambia i termini della scelta in modo concreto, perché la separazione tra IPC ed embedded si sfuma quando lo stesso edge server ospita più istanze di controllo virtualizzate accanto ai servizi dati. Restano però due nodi tecnici seri. Il primo è che la rete diventa parte dell’anello di controllo: protocolli come PROFINET o EtherCAT devono garantire qualità di servizio su distanze maggiori, ed è il terreno dove entra in gioco il Time-Sensitive Networking nel profilo IEC/IEEE 60802. Il secondo è il determinismo del controllo containerizzato, che resta sotto esame: i requisiti hard real-time mal si conciliano con uno stack di virtualizzazione, dove l’hypervisor e lo scheduling condiviso introducono jitter. Per questo oggi il vPLC copre bene la logica di processo e molto meno il moto stretto, che resta su hardware dedicato. Per chi progetta ora, insomma, il vPLC è una direzione da considerare nell’architettura, non ancora la risposta per ogni anello.
I criteri che spostano davvero la decisione
Le tre piattaforme convergono sulle capacità e divergono sul contesto. La tabella riassume gli assi su cui si gioca la scelta, esclusi i megahertz che ormai contano poco.
| Criterio | PLC | IPC | Embedded custom |
|---|---|---|---|
| Volume di break-even | Basso (macchine, impianti) | Basso-medio | Alto, ma lo sposta la certificazione |
| Chi mantiene | Terzi, dentro un ecosistema chiuso | Team con competenze IT-OT | Solo chi ha sviluppato |
| Determinismo | Nativo | Soft, anello veloce delegato | Da hard (MCU, FPGA) a soft (SoC Linux) |
| Sicurezza funzionale | Certificata, pronta | Da architettare e validare | Tutta a carico di chi sviluppa |
| Ciclo di vita | 15+ anni garantiti | Legato alla piattaforma PC | Da gestire, obsolescenza silicio |
| Architettura dati | Buona (OPC UA, fieldbus) | Massima (IT-OT, cloud) | Su misura (IIoT, edge) |
| Virtualizzabile | Sì, via vPLC emergente | Già base per soft-PLC e vPLC | No, è il livello fisico |
Tra questi, due criteri decidono più degli altri e meritano una nota.
Chi mantiene il sistema è il più sottovalutato. Se la manutenzione è di terzi, una piattaforma diagnosticabile dentro uno standard noto vale più di qualunque ottimizzazione, anche al costo del lock-in di vendor. Se invece gestisci tu il sistema per tutta la sua vita, la libertà del custom smette di essere un rischio e diventa leva.
Il peso della sicurezza funzionale è ciò che muove davvero il calcolo economico. Una funzione safety già certificata su PLC e la stessa funzione da validare da zero su una scheda custom non differiscono di una voce di costo, ma di un capitolo di progetto. Su un PLC safety una STO o un monitoraggio di velocità sicura arrivano come blocchi precertificati con il loro safety manual. Sul custom occorre dimostrare la conformità della catena secondo ISO 13849 o IEC 61508, con analisi dei guasti, calcolo del PFH e dossier che un ente notificato dovrà accettare. È un onere che il prezzo di listino non mostra, e che da solo decide molti progetti.
Conclusione: la domanda giusta non è “quale”, è “come distribuire”
Ridurre la scelta a una gara tra tre concorrenti è comodo e fuorviante, perché le architetture solide quasi mai usano una piattaforma sola. Un IPC che orchestra logica e dati, il moto delegato a slave su bus deterministico, una flotta di nodi embedded che raccoglie il campo: è lo schema reale, e la virtualizzazione lo accentua scollegando ancora di più il dove-gira-il-controllo dal dove-stanno-gli-I/O.
La decisione corretta parte dal contesto e non dal datasheet. Volume, chi manterrà il sistema, peso della certificazione, orizzonte di vita, architettura dati: questi spostano la scelta, le prestazioni quasi mai. La vera competenza progettuale, oggi, non è scegliere la piattaforma più potente. È distribuire le funzioni sul livello dove ciascuna rende meglio, e farlo sapendo che quel livello, per la prima volta, può non coincidere più con un pezzo di hardware in un armadio.
Domande frequenti
Qual è la differenza tra PLC e IPC?
Il PLC è un controllore con sistema operativo dedicato e ciclo di scansione deterministico, mantenibile da terzi tramite linguaggi IEC 61131-3 dentro un ecosistema chiuso. L’IPC è un PC industriale che esegue il controllo via soft-PLC e, sullo stesso hardware, gestisce dati, visione e connettività. Il PLC privilegia robustezza e standardizzazione, l’IPC potenza di calcolo e integrazione IT-OT.
Cos’è un vPLC e quando ha senso?
Un vPLC è un PLC virtuale: la runtime di controllo gira come container su hardware standard, edge server o macchina virtuale, separata dall’hardware fisico. Ha senso per consolidare la logica di più controllori e gestirla in modo centralizzato. Oggi copre bene la logica di processo, molto meno il controllo di moto a microsecondi, dove i requisiti real-time mal si conciliano con la virtualizzazione.
Quando conviene una soluzione embedded invece di un PLC?
Quando l’unità di controllo è un prodotto da fabbricare in serie, non una macchina da installare. Sopra il migliaio di pezzi il basso costo unitario ripaga sviluppo e certificazione. La soglia però si abbassa con i moduli SoM pre-certificati e si alza con le funzioni di sicurezza da validare da zero.
Un IPC può sostituire del tutto un PLC?
Per la logica di controllo sì, via soft-PLC. Per il moto a microsecondi e la sincronizzazione di assi quasi mai, perché questi compiti restano delegati a un bus deterministico o a un controllore dedicato. L’IPC orchestra, l’anello veloce gira su hardware specializzato.
