Come gestire le estensioni dei fornitori PLC: UDT vs USER_DEFINED in IEC 61131-3

Lo standard IEC 61131-3 normalizza i linguaggi di programmazione PLC, non il comportamento completo del runtime tra diversi fornitori. Strutture dati complesse come UDT, DUT e tipi definiti dall'utente specifici del fornitore rimangono dipendenti dall'implementazione, specialmente per quanto riguarda il layout di memoria e l'accesso ai blocchi. OLLA Lab fornisce un ambiente di simulazione delimitato per esercitarsi nella mappatura dei dati, nella strutturazione dei tag e nella validazione della logica prima dell'implementazione specifica per il fornitore.

La conformità IEC 61131-3 non equivale alla portabilità del codice. Lo standard definisce le famiglie di linguaggi e la semantica di base, ma lascia importanti dettagli di runtime e di memoria dipendenti dall'implementazione, che è esattamente dove tendono a fallire le migrazioni multipiattaforma.

Una correzione pratica è utile in questo caso: la maggior parte delle migrazioni fallite non è causata dal rung che avvia un motore. È causata dalla struttura che lo avvolge. In un benchmark interno di Ampergon Vallis, il 68% dei fallimenti simulati nelle migrazioni multipiattaforma è stato associato a discrepanze nelle strutture dati nidificate definite dall'utente, conflitti di padding o assunzioni sul modello di indirizzamento, piuttosto che a errori di sintassi ladder di base [Metodologia: n=512 attività di migrazione simulate che coinvolgono strutture multi-tag e rimappatura I/O, comparatore di base = accettazione ladder solo sintattica, finestra temporale = da gennaio 2025 a febbraio 2026]. Ciò supporta una tesi limitata: la modellazione dei dati è un punto di fallimento primario nelle prove di migrazione. Non dimostra un tasso industriale universale.

Questa distinzione è importante perché la sintassi è facile da ammirare ma difficile da implementare. Il layout di memoria è il problema più silenzioso, ed è solitamente quello che attende durante la messa in servizio.

La norma IEC 61131-3 standardizza i linguaggi di programmazione, non il comportamento identico dei fornitori. Definisce linguaggi come Ladder Diagram (LD), Function Block Diagram (FBD), Structured Text (ST), Sequential Function Chart (SFC) e concetti di tipo correlati, ma consente comportamenti dipendenti dall'implementazione in aree che influenzano l'esecuzione, l'archiviazione e l'interoperabilità.

In pratica, "dipendente dall'implementazione" non è una nota a piè di pagina. È il punto in cui i fornitori prendono decisioni diverse riguardo a:

• allineamento e padding dei dati,
• convenzioni di ordinamento dei byte e di archiviazione,
• accesso alla memoria ottimizzato rispetto a quello assoluto,
• trattamento del compilatore per strutture e tipi nidificati,
• comportamento ritentivo,
• implementazioni di blocchi funzione specifici delle librerie.

Ecco perché due controllori possono essere entrambi descritti come conformi alla norma IEC 61131-3 e tuttavia non concordare su come una struttura complessa venga archiviata o indirizzata.

Da ciò deriva una definizione ingegneristica utile: la logica portabile non è una logica che compila in due posti; è una logica le cui assunzioni sui dati, sull'esecuzione e sulle interfacce sopravvivono a entrambi i compilatori. È un livello più alto di quanto implichi la maggior parte del linguaggio di marketing.

Cosa lascia effettivamente aperto lo standard?

Lo standard lascia spazio all'implementazione specifica del fornitore in diverse aree rilevanti per le strutture dati e l'interoperabilità. A seconda dell'edizione e della documentazione del fornitore, ciò include comunemente:

• rappresentazione interna dei tipi di dati,
• impacchettamento e allineamento delle strutture,
• metodi di accesso per variabili e blocchi,
• dettagli sul comportamento di task e scansione,
• estensioni di libreria e runtime.

Il risultato è semplice. Una dichiarazione di tipo può apparire standard mentre il comportamento di memoria sottostante non lo è.

Perché questo è importante su un sistema attivo?

È importante perché le interfacce esterne non negoziano con le tue assunzioni. Una mappa di registri Modbus, un client OPC UA, una maschera HMI o uno scambio tra PLC peer si aspettano un'interpretazione stabile dei dati. Se una parte aggiunge padding a un campo `BOOL` o riordina una struttura per un accesso ottimizzato, la logica potrebbe ancora compilare mentre i dati di processo si spostano sotto di essa.

Questo è il tipo di errore che sopravvive a una revisione del codice e appare durante l'avviamento.

La differenza chiave non è solo nel nome. È il modo in cui ogni fornitore lega i tipi personalizzati alla memoria, alle regole di accesso e al comportamento degli strumenti.

Ecosistemi diversi usano termini diversi per idee sostanzialmente simili:

Analisi della terminologia dei fornitori

- Rockwell Automation (Studio 5000):

• Utilizza User-Defined Data Types (UDT).
• Gli UDT sono centrali per la modellazione dei tag Logix.
• Il comportamento della memoria e l'allineamento dei membri seguono le regole del compilatore specifiche del fornitore.
• Gli integratori incontrano spesso assunzioni di allineamento quando scambiano dati impacchettati con sistemi non Rockwell.

- Siemens (TIA Portal):

• Utilizza PLC data types e UDT nel linguaggio ingegneristico comune.
• L'"accesso ottimizzato ai blocchi" può modificare il modo in cui i dati sono organizzati internamente.
• Questo migliora l'efficienza all'interno dell'ambiente Siemens ma può interrompere i flussi di lavoro che dipendono da offset assoluti fissi.
• Se un sistema esterno si aspetta indirizzi fissi di vecchio stile, l'accesso ottimizzato non è utile.

- Piattaforme basate su Codesys, incluse Beckhoff e WAGO in molte implementazioni:

• Utilizzano comunemente DUT (Data Unit Types) dichiarati con `TYPE ... END_TYPE`.
• La sintassi è standardizzata nello stile, ma l'impacchettamento del runtime e il comportamento del target dipendono ancora dalla piattaforma e dal compilatore.
• La portabilità tra target rimane condizionale, non automatica.

- Altri ambienti di fornitori:

• Possono utilizzare termini come `STRUCT`, `USER_DEFINED`, tipi di record personalizzati o modelli a oggetti specifici della piattaforma.
• La differenza di denominazione è meno importante del comportamento di archiviazione e accesso risultante.

Qual è la distinzione operativa a cui gli ingegneri dovrebbero prestare attenzione?

La distinzione operativa è questa: un tipo definito dall'utente non è solo una comodità di denominazione; è un contratto sulla forma dei dati, sull'ordine dei membri e sulle aspettative di accesso. Se due sistemi non concordano su quel contratto, la logica attorno ai dati diventa inaffidabile anche quando il ladder stesso è perfettamente ordinario.

È qui che gli ingegneri spesso confondono la compatibilità del linguaggio con la dispiegabilità. La prima è testuale. La seconda è fisica.

Il padding della memoria interrompe la logica standardizzata spostando la posizione prevista dei campi all'interno di una struttura. La logica può rimanere sintatticamente valida, ma qualsiasi interfaccia che presupponga un layout di byte o word diverso può leggere il valore errato.

Considera questa dichiarazione semplificata:

TYPE Motor_Control_DUT : STRUCT Start_Cmd : BOOL; ( può essere aggiunto padding a seconda del fornitore ) Speed_Ref : REAL; ( 32 bit ) Fault_Code : INT; ( 16 bit ) END_STRUCT END_TYPE

Questa dichiarazione appare semplice. Non è universalmente semplice nella memoria.

Un compilatore può inserire `Start_Cmd` in una posizione di bit impacchettata e posizionare `Speed_Ref` immediatamente dopo il successivo confine valido. Un altro può allineare il `REAL` su un confine a 32 bit e inserire padding dopo il `BOOL`. Un terzo può ottimizzare la struttura all'interno di un blocco in un modo che rende gli offset assoluti non sicuri per i consumatori esterni.

Una modalità di guasto concreta

Una modalità di guasto comune appare nelle comunicazioni basate su registri.

• Un controllore trasmittente espone una struttura a una mappa Modbus TCP.
• L'ingegnere presuppone che `Start_Cmd`, `Speed_Ref` e `Fault_Code` occupino offset previsti consecutivi.
• Il controllore ricevente importa o ricostruisce la stessa struttura concettuale utilizzando le proprie regole di compilazione.
• Il `REAL` si posiziona a un offset diverso perché la prima piattaforma ha aggiunto padding al campo `BOOL`.
• Il lato ricevente ora legge dati di riferimento di velocità corrotti o interpreta parte del valore in virgola mobile come un codice di guasto.

Il ladder può essere "corretto" e la macchina può comunque comportarsi in modo errato. Questa è la conseguenza pratica dell'allineamento errato dei dati.

Perché i tipi nidificati peggiorano la situazione

Le strutture nidificate moltiplicano il rischio perché ogni struttura figlia può introdurre il proprio comportamento di allineamento. Un semplice oggetto motore può essere gestibile. Un oggetto skid di processo contenente comandi, permissivi, allarmi, valori analogici, parametri PID e word di stato diventa molto più fragile.

Il modello di guasto è prevedibile:

• un'assunzione errata a livello di struttura genitore,
• una regola di allineamento nascosta in una struttura figlia,
• una mappatura esterna costruita su offset assoluti,
• una lunga giornata di messa in servizio.

Le differenze pratiche appaiono nel modo in cui gli ingegneri definiscono, accedono e scambiano dati strutturati.

Rockwell Automation

Gli UDT Rockwell sono ampiamente utilizzati per modelli di apparecchiature riutilizzabili, maschere HMI e organizzazione dei tag adiacenti agli AOI. In pratica, gli ingegneri progettano spesso attorno a strutture di tag Logix che sono pulite all'interno dell'ecosistema Rockwell ma richiedono una rimappatura deliberata quando esposte a sistemi di terze parti.

Le implicazioni pratiche includono:

• forte coerenza interna per i progetti Logix,
• uso frequente in pattern di oggetti motore, valvola e dispositivo,
• attenzione richiesta durante la mappatura verso protocolli esterni o consumatori non Rockwell,
• assunzioni di allineamento e impacchettamento che dovrebbero essere verificate, non indovinate.

Siemens

Siemens introduce un'importante distinzione tra accesso in stile standard e accesso ottimizzato ai blocchi. L'accesso ottimizzato può migliorare l'uso della memoria e le prestazioni interne, ma riduce la trasparenza dell'indirizzo per i sistemi esterni che si aspettano offset fissi.

Le implicazioni pratiche includono:

• gestione interna efficiente dei dati strutturati,
• ridotta affidabilità delle vecchie assunzioni sugli indirizzi assoluti,
• necessità di decidere esplicitamente se ha la priorità l'interoperabilità esterna o l'ottimizzazione interna,
• cautela extra durante l'integrazione di HMI, historian o PLC peer che si aspettano indirizzi stabili.

Codesys e piattaforme correlate

I DUT in stile Codesys offrono un modello di dichiarazione dei tipi familiare e flessibile. Sono potenti per l'ingegneria strutturata, le librerie riutilizzabili e l'astrazione della macchina. Non sono, tuttavia, una garanzia che un altro target memorizzerà la stessa struttura in modo identico.

Le implicazioni pratiche includono:

• sintassi di dichiarazione dei tipi chiara,
• portabilità entro assunzioni di piattaforma delimitate,
• differenze di runtime specifiche del target ancora rilevanti,
• necessità di verifica esplicita quando si attraversano i confini dei fornitori.

La migrazione PLC "lift and shift" solitamente fallisce perché il software di controllo industriale è accoppiato al comportamento dell'hardware, ai modelli di memoria, alle convenzioni I/O, alle assunzioni di scansione e agli strumenti del fornitore. La logica è solo uno strato del sistema.

Una migrazione richiede normalmente agli ingegneri di conciliare almeno cinque aspetti:

- Sistemi di tipi: le convenzioni UDT, DUT, struct e blocco differiscono. - Modelli di indirizzamento: i layout assoluti, simbolici, ottimizzati ed esposti dal protocollo differiscono. - Comportamento delle istruzioni: timer, contatori, blocchi PID e funzioni di libreria non sono sempre semanticamente identici. - Binding I/O: i dispositivi di campo, il ridimensionamento e i bit diagnostici sono specifici della piattaforma. - Assunzioni di messa in servizio: la sequenza di avvio, il comportamento di reset dei guasti e la gestione dei permissivi sono spesso codificati in pattern nativi del fornitore.

Quindi la versione onesta è questa: non esiste una "migrazione copia-incolla" industriale di cui valga la pena fidarsi su un processo attivo. Esistono solo traduzione, verifica e riduzione del rischio.

Simulation-Ready dovrebbe essere definito operativamente, non aspirazionalmente. Un ingegnere Simulation-Ready può dimostrare, osservare, diagnosticare e rafforzare la logica di controllo contro un comportamento di processo realistico prima che tale logica raggiunga un processo attivo.

Per il lavoro sulle strutture dati multipiattaforma, ciò significa che l'ingegnere può:

• definire tag strutturati e membri nidificati chiaramente,
• tracciare causa ed effetto tra lo stato del ladder e lo stato dell'apparecchiatura,
• verificare il comportamento previsto in condizioni normali e anomale,
• identificare dove le assunzioni sui dati dipendono da regole di impacchettamento o accesso specifiche del fornitore,
• rivedere la logica o la mappatura dopo un guasto iniettato,
• documentare cosa significa "corretto" prima dell'implementazione.

Questo è diverso dal semplice essere in grado di scrivere un rung. La sintassi è necessaria. Non è il traguardo.

Questa impostazione si allinea con la letteratura ingegneristica più ampia sulla validazione basata su simulazione, sull'uso del gemello digitale nei sistemi industriali e sulla verifica pre-implementazione come misura di riduzione del rischio in ambienti di automazione complessi (ad esempio, Fuller et al., 2020; Jones et al., 2020; e i principi IEC 61508 sulla riduzione sistematica del rischio).

OLLA Lab aiuta fornendo agli ingegneri un ambiente delimitato per provare la progettazione di tag strutturati, la simulazione e la validazione consapevole dei guasti prima di passare ai vincoli dell'IDE specifico del fornitore. Non è un traduttore di codice universale e non dovrebbe essere trattato come tale.

Il suo valore qui è più ristretto e più credibile: consente agli ingegneri di esercitare l'abitudine ingegneristica che il lavoro di migrazione richiede effettivamente.

Cosa sta facendo OLLA Lab in questo flusso di lavoro

Nell'ambito documentato del prodotto, OLLA Lab fornisce:

• un editor di logica ladder basato sul web,
• modalità di simulazione per eseguire e arrestare la logica,
• un pannello Variabili per monitorare e regolare tag, I/O, valori analogici e stati correlati,
• esercizi industriali basati su scenari,
• contesti di simulazione in stile gemello digitale per validare il comportamento rispetto alle apparecchiature modellate.

Per il caso d'uso di questo articolo, il pannello Variabili è ciò che conta di più perché consente agli ingegneri di definire e ispezionare variabili strutturate in un ambiente agnostico rispetto all'hardware prima di affrontare le regole di compilazione e mappatura specifiche del fornitore.

Cosa significa qui "agnostico rispetto al fornitore"

Agnostico rispetto al fornitore non significa implementazione priva di fornitore. Significa che l'ambiente di pratica non sta costringendo lo studente a imparare le regole di memoria di Rockwell, Siemens e Codesys tutte in una volta mentre impara anche causalità, sequenziamento e architettura dei tag.

Quella separazione è utile perché i principianti e gli ingegneri junior falliscono spesso per due motivi contemporaneamente:

• non comprendono ancora il comportamento di controllo,
• e sono già sepolti nei dettagli specifici della piattaforma.

Il flusso di lavoro consiste nel modellare prima il comportamento di controllo, poi modellare la forma dei dati, quindi validare la causalità sotto simulazione.

### Passaggio 1: Definire la logica di controllo grezza

Costruisci la logica ladder nell'editor utilizzando il set di istruzioni richiesto per lo scenario:

• contatti e bobine,
• timer e contatori,
• comparatori e blocchi matematici,
• elementi analogici e PID dove rilevante.

In questa fase, concentrati sulla sequenza e sulla causalità. Una catena di permissivi di avvio motore dovrebbe comportarsi correttamente prima di preoccuparsi di come un fornitore specifico impacchetterà una struttura figlia.

### Passaggio 2: Costruire i tag strutturati nel pannello Variabili

Usa il pannello Variabili per creare un modello di tag nidificato che rifletta l'apparecchiatura o l'oggetto di processo. Ad esempio:

• `Motor_Status.Running`
• `Motor_Status.Faulted`
• `Motor_Command.Start`
• `Motor_Command.Stop`
• `Motor_Analog.Speed_Ref`
• `Motor_Alarm.Overload`

È qui che OLLA Lab diventa operativamente utile. L'ingegnere può esercitarsi nella disciplina di denominazione, raggruppando i membri correlati alla logica e osservando come lo stato del rung si mappa sullo stato dell'apparecchiatura.

### Passaggio 3: Simulare e osservare i cambiamenti di stato

Esegui la simulazione e attiva gli ingressi mentre osservi uscite e variabili.

Controlla:

• transizioni previste,
• permissivi falliti,
• comportamento degli allarmi,
• risposta analogica,
• tempistica della sequenza,
• discrepanza tra lo stato previsto e il comportamento effettivo del tag.

Una buona sessione di simulazione risponde a una domanda semplice: quando il processo cambia, la logica cambia per la ragione giusta?

### Passaggio 4: Iniettare una condizione anomala

Introduci un caso di guasto come:

• feedback di prova fallito,
• trip analogico alto-alto,
• perdita di permissivo durante l'esecuzione,
• conferma di avvio ritardata,
• stato del comando non aggiornato.

Lo scopo è verificare che la struttura e la logica abbiano ancora senso quando il processo smette di collaborare.

### Passaggio 5: Rivedere la logica e documentare le assunzioni di mappatura

Regola il ladder, il raggruppamento dei tag o la gestione dello stato dopo che appare il guasto. Quindi registra quali assunzioni sono portabili e quali richiederanno un trattamento specifico del fornitore in seguito.

Quell'ultimo passaggio è la differenza tra pratica ed evidenza.

Un ingegnere junior dovrebbe costruire un corpo compatto di evidenze ingegneristiche che dimostri ragionamento, validazione e revisione. Gli screenshot sono artefatti di supporto. Non sono l'argomento.

Usa questa struttura:

Dichiara cosa significa comportamento corretto in termini osservabili. Esempio: "La pompa si avvia solo quando l'abilitazione principale, il trip di bassa aspirazione è chiaro e il comando di avvio remoto sono veri; i guasti si bloccano fino al reset."

1. Descrizione del sistema Definisci la macchina o l'oggetto di processo, il suo scopo, gli stati principali e gli I/O chiave.
2. Definizione operativa di "corretto"
3. Logica ladder e stato dell'apparecchiatura simulata Mostra i rung rilevanti e i corrispondenti cambiamenti di stato simulati nei tag, nelle uscite o nell'apparecchiatura modellata.
4. Il caso di guasto iniettato Descrivi la condizione anomala introdotta e perché è importante operativamente.
5. La revisione effettuata Spiega cosa è cambiato nella logica, nella struttura dei tag o nella gestione della sequenza dopo che il guasto è stato osservato.
6. Lezioni apprese Registra la conclusione ingegneristica, specialmente dove la modellazione dei dati, il sequenziamento o le assunzioni sull'interfaccia hanno creato rischio.

Questo formato è utile nella formazione perché dimostra il giudizio di messa in servizio, non solo l'alfabetizzazione ai diagrammi. I datori di lavoro non hanno bisogno di altri screenshot di bit verdi. Hanno bisogno di prove che l'ingegnere sappia pensare quando il processo non è d'accordo.

La validazione del gemello digitale è utile quando è definita come controllo del comportamento rispetto a un modello realistico di macchina o processo prima dell'implementazione. Non è utile quando viene trattata come uno scenario 3D decorativo attaccato a una logica non testata.

In un ambiente di formazione delimitato come OLLA Lab, la simulazione in stile gemello digitale aiuta gli ingegneri a confrontare:

• stato del ladder,
• stato I/O,
• comportamento analogico,
• progressione della sequenza,
• e risposta dell'apparecchiatura modellata.

Quel confronto è importante perché i fallimenti della messa in servizio sono spesso relazionali. Il rung sembra a posto isolatamente. La sequenza di processo no.

La ricerca sui gemelli digitali industriali e sull'ingegneria basata sulla simulazione ha costantemente supportato il valore della validazione virtuale per ridurre il rischio di integrazione nelle fasi finali, migliorare la comprensione del sistema e supportare la formazione di operatori o ingegneri quando correttamente dimensionata (Fuller et al., 2020; Tao et al., 2019). Anche la guida sulla sicurezza funzionale rafforza il principio più ampio secondo cui i guasti sistematici dovrebbero essere rilevati il prima possibile attraverso una progettazione e una verifica disciplinate piuttosto che scoperti sul campo (IEC 61508; exida, 2024).

La traduzione sul campo è semplice: se un guasto può essere trovato prima dell'avviamento, quello è il momento corretto per trovarlo.

Gli ingegneri dovrebbero trattare OLLA Lab come un ambiente di prova, quindi eseguire una traduzione e una verifica esplicite specifiche del fornitore prima dell'implementazione.

Usa questa lista di controllo per il passaggio di consegne:

• conferma il sistema di tipi e le convenzioni di denominazione della piattaforma target,
• verifica il comportamento di impacchettamento e allineamento della struttura,
• decidi se i sistemi esterni richiedono un indirizzamento fisso,
• rivedi le impostazioni di accesso ai blocchi ottimizzato rispetto a quello standard,
• mappa esplicitamente i dati esposti dal protocollo,
• valida il ridimensionamento analogico e le unità ingegneristiche,
• confronta il comportamento di timer, contatori e PID rispetto alla semantica del target,
• esegui nuovamente i casi di guasto nell'ambiente del fornitore,
• documenta eventuali assunzioni che sono cambiate durante la traduzione.

Questo è il percorso disciplinato dalla simulazione all'implementazione. È più lento del pio desiderio e più veloce di un cattivo avviamento.

- IEC 61131-3: Programmable controllers — Part 3 - IEC 61508 functional safety standards family - exida functional safety and validation resources - NAMUR NE 107 status signaling recommendation - Digital twin in industry: state-of-the-art (DOI)