Come costruire un laboratorio PLC domestico basato su browser a costo zero con OLLA Lab

Un laboratorio PLC domestico basato su browser sostituisce il costo dell'hardware con un ambiente di processo simulato, consentendo agli studenti di esercitarsi con ladder logic, causalità I/O, progettazione di macchine a stati e commissioning virtuale senza dover acquistare un trainer fisico. In OLLA Lab, ciò significa costruire e testare la logica di controllo rispetto a scenari industriali realistici prima che esista qualsiasi rischio legato alla messa in servizio reale.

La formazione sull'automazione viene spesso inquadrata come un problema di hardware. In realtà, è solitamente un problema di processo. Un piccolo kit di avvio PLC può insegnare indirizzamento, contatti, bobine e temporizzazioni di base, ma non fornisce una linea di imbottigliamento, una stazione di sollevamento o uno skid di processo da mettere in servizio in modo significativo. Interruttori e lampade sono utili, ma non sono un impianto.

Un laboratorio di automazione basato su browser è importante perché la logica di controllo implementabile non è solo sintassi. È la capacità di dimostrare, osservare, diagnosticare e consolidare la logica contro un comportamento reale della macchina prima che raggiunga un processo attivo. Questo è ciò che questo articolo intende per Simulation-Ready (pronto per la simulazione).

Metrica Ampergon Vallis: In una recente analisi interna delle sessioni di OLLA Lab utilizzando il preset di riempimento bottiglie, gli studenti hanno riscontrato e risolto 4,2 volte più condizioni di race condition che bloccavano la sequenza nelle prime 10 ore rispetto agli studenti che utilizzavano esercizi statici con trainer a interruttori e luci. Metodologia: n=84 studenti; definizione del compito = completare la sequenza avvio-indicizzazione-riempimento-uscita con almeno un ripristino da stato anomalo; comparatore di base = esercizi con trainer discreti senza modello di processo simulato; finestra temporale = prime 10 ore di pratica registrate. Ciò supporta l'ipotesi più ristretta che gli ambienti di processo simulati possano esporre i guasti di sequenziamento più precocemente. Ciò non dimostra una superiore preparazione lavorativa, competenza in sito o risultati formativi universali.

Un simulatore PLC basato su browser è più efficace quando l'obiettivo formativo è la causalità di processo, il sequencing e la gestione dei guasti, non semplicemente la sintassi delle istruzioni.

I kit di avvio fisici hanno ancora valore. Insegnano la disciplina del cablaggio, la familiarità con i dispositivi e il fatto ostinato che i segnali di campo non si comportano sempre in modo pulito come suggeriscono gli schemi. Tuttavia, la maggior parte dei kit entry-level è limitata a pulsanti discreti, spie luminose e forse un piccolo motore o un punto analogico. Sono vincolati da ciò che può essere posizionato in modo sicuro ed economico su un banco.

Il vero collo di bottiglia non è il controllore. È il processo.

Uno studente può acquistare un PLC compatto e non avere comunque alcun modo pratico per provare:

• l'indicizzazione delle bottiglie rispetto a una fotocellula
• l'alternanza pompa principale/ausiliaria
• le soglie di allarme con deriva analogica
• i permissivi e i trip su uno skid di processo
• il ripristino dei guasti dopo l'arresto di una sequenza

Questa distinzione è importante perché i datori di lavoro non faticano a trovare persone in grado di inserire un XIC in un rung. Faticano a trovare persone in grado di spiegare perché una sequenza si è fermata, quale interblocco l'ha bloccata e come revisionare la logica senza creare un secondo problema. La sintassi costa poco. Gli errori di commissioning no.

La matrice dei costi hardware vs. simulazione

Un confronto pratico appare così:

- Kit di avvio fisico: solitamente da diverse centinaia a oltre mille USD a seconda del fornitore, del pacchetto software e dell'I/O incluso - Laboratorio basato su browser: nessun acquisto di hardware del controllore richiesto per l'ambiente di simulazione stesso

• Hardware del controllore

- Kit di avvio fisico: cablaggio manuale, assegnazione dei dispositivi, risoluzione dei problemi di terminazioni allentate o errate - Laboratorio basato su browser: visibilità diretta dei tag e manipolazione delle variabili all'interno dell'interfaccia

• Configurazione I/O

- Kit di avvio fisico: solitamente limitato a semplici esercizi discreti - Laboratorio basato su browser: comportamento della macchina o del processo basato su scenari con cambiamenti di stato osservabili

• Realismo del processo

- Kit di avvio fisico: limitata a meno che non venga costruito hardware aggiuntivo - Laboratorio basato su browser: le condizioni anomale possono essere introdotte in modo sicuro e ripetibile

• Iniezione di guasti

- Kit di avvio fisico: ciclo di ripristino e riconfigurazione più lento - Laboratorio basato su browser: ciclo immediato di riesecuzione, modifica e ritest

• Velocità di iterazione

Questa non è una critica all'hardware. È un argomento a favore dell'abbinamento dello strumento alla competenza. Se l'abilità target è il commissioning virtuale, un modello di processo conta più di una pila di morsettiere.

Cosa significa qui "commissioning virtuale"?

Commissioning virtuale significa confrontare le sequenze di ladder logic previste con il comportamento osservato di un modello fisico simulato prima della messa in servizio.

Questa definizione è volutamente semplice. Esclude un linguaggio vago e si concentra su un atto ingegneristico osservabile:

• definire la sequenza prevista
• eseguire la logica
• osservare la risposta della macchina o del processo
• confrontare il comportamento atteso rispetto a quello reale
• revisionare la logica
• rieseguire finché la sequenza non è robusta

Nella pratica adiacente agli standard, ciò si affianca al più ampio uso ingegneristico della simulazione e della validazione basata su modelli prima dell'esecuzione in campo. Non è un sostituto per FAT, SAT, accettazione in sito o verifica della sicurezza funzionale. È un banco di prova più precoce e sicuro.

Si costruisce un utile laboratorio PLC domestico basato su browser ricreando il ciclo ingegneristico fondamentale: scrivere la logica, simulare il comportamento, ispezionare l'I/O, iniettare guasti, revisionare il programma e documentare le prove.

In OLLA Lab, quel ciclo è disponibile tramite un editor ladder basato sul web, una modalità di simulazione, un pannello delle variabili per la visibilità dell'I/O e digital twin basati su scenari. Il punto non è che il browser sia affascinante. Il punto è che il browser rimuove l'attrito della configurazione e ti fornisce un processo da controllare.

### Passaggio 1: Scegli uno scenario che abbia reali conseguenze di sequenziamento

Inizia con uno scenario che imponga la causalità, non solo rung isolati. Il preset di riempimento bottiglie è un buon esempio perché combina:

• un pezzo in movimento
• un evento di rilevamento
• un'azione di riempimento temporizzata
• una condizione di rilascio

È qui che OLLA Lab diventa operativamente utile. Un rung statico può sembrare corretto mentre la sequenza fallisce non appena lo stato della macchina cambia al di sotto di esso.

Altri tipi di scenario nella piattaforma includono preset nei settori manifatturiero, idrico e delle acque reflue, HVAC, utility, magazzinaggio, alimentare, chimico e farmaceutico. Il valore educativo non è l'etichetta del settore in sé. È la presenza di interblocchi, temporizzazioni, condizioni analogiche e note di commissioning che forzano il giudizio ingegneristico.

### Passaggio 2: Costruisci la logica nell'editor ladder

Utilizza l'editor ladder basato su browser per creare la sequenza con tipi di istruzioni standard come:

• contatti e bobine
• timer
• contatori
• comparatori
• operazioni logiche
• funzioni matematiche
• istruzioni PID dove rilevante

Per un laboratorio domestico, inizia prima con il sequenziamento discreto. Il controllo analogico è importante, ma molti fallimenti iniziano ancora con una scarsa gestione dello stato e una progettazione dei permissivi inadeguata.

### Passaggio 3: Esegui la sequenza in modalità simulazione

La modalità simulazione è dove il ladder smette di essere decorativo.

In OLLA Lab, puoi eseguire e arrestare la logica, attivare ingressi e osservare uscite e stati delle variabili senza hardware fisico. Ciò ti consente di testare se:

• la macchina si avvia solo quando i permissivi sono soddisfatti
• le uscite si eccitano nell'ordine previsto
• i timer si comportano correttamente
• la sequenza esce da ogni stato in modo pulito

Questa è la prima soglia pratica per essere Simulation-Ready: puoi dimostrare che la tua logica si comporta correttamente rispetto a un comportamento di processo realistico, non solo che il rung compila o appare ordinato.

### Passaggio 4: Usa il pannello delle variabili come livello di osservabilità

Il pannello delle variabili è il sostituto delle congetture alla cieca.

Fornisce visibilità su:

• stati degli ingressi
• stati delle uscite
• tag
• valori analogici
• variabili correlate al PID
• selezione dello scenario o contesto di stato ove applicabile

In un pannello fisico, potresti ricorrere a un multimetro, un trend o una tabella di monitoraggio. In un laboratorio basato su browser, il pannello delle variabili fornisce la stessa funzione essenziale: ti permette di tracciare causa ed effetto. Se un'uscita non si è eccitata, la domanda non è più "perché il simulatore è strano?", ma "quale condizione è rimasta falsa?".

### Passaggio 5: Inietta un guasto di proposito

Un laboratorio domestico è utile solo se consente un fallimento controllato.

Inietta almeno una condizione anomala:

• mantieni il segnale di rilevamento bottiglia alto troppo a lungo
• rimuovi il permissivo di avvio a metà sequenza
• simula una condizione di "libero" fallita
• altera un'ipotesi di temporizzazione

Questo insegna la validazione consapevole dei guasti, che è più vicina al commissioning reale rispetto all'inserimento della logica nel "percorso felice". La maggior parte degli ingegneri junior sa far girare una sequenza una volta. Quelli utili sanno spiegare perché fallisce al secondo ciclo.

### Passaggio 6: Documenta le prove ingegneristiche, non gli screenshot

Se vuoi dimostrare competenza, costruisci un corpo compatto di prove ingegneristiche utilizzando questa struttura:

1. Descrizione del sistema Definisci la macchina o il processo, il suo scopo e i principali I/O.
2. Definizione operativa di "corretto" Indica la sequenza richiesta, i permissivi, il comportamento di arresto e la risposta ai guasti in termini osservabili.
3. Ladder logic e stato dell'attrezzatura simulata Mostra i rung rilevanti e i corrispondenti stati della macchina durante l'esecuzione.
4. Il caso di guasto iniettato Descrivi la condizione anomala introdotta e cosa ha fallito.
5. La revisione effettuata Spiega quale logica è cambiata e perché.
6. Lezioni apprese Indica cosa ha rivelato il fallimento riguardo a sequenziamento, interblocchi, temporizzazioni o osservabilità.

Quella struttura è più credibile di una galleria di screenshot con frecce e ottimismo.

Un processo di riempimento bottiglie dovrebbe essere programmato come una macchina a stati esplicita perché la semplice ramificazione IF-THEN ad hoc diventa fragile una volta che temporizzazione e movimento interagiscono.

Le macchine a stati non sono gergo fine a se stesso. Sono un modo disciplinato per garantire che solo una fase principale dell'operazione sia attiva alla volta, con chiare condizioni di transizione tra le fasi. Nell'imballaggio, nel trasporto, nel pompaggio e nel dosaggio, questa è spesso la differenza tra una sequenza stabile e un groviglio logico.

La sequenza di imbottigliamento in 4 passaggi

Una sequenza di imbottigliamento compatta può essere definita come segue:

• Motore del nastro trasportatore SPENTO
• Valvola di riempimento SPENTA
• Il sistema attende il permissivo di avvio
• L'arresto di emergenza o la condizione di stop mantiene il sistema in uno stato di inattività sicuro

• Motore del nastro trasportatore ACCESO
• Il sistema attende il rilevamento della bottiglia nella posizione di riempimento
• La transizione avviene quando la fotocellula o il sensore di prossimità conferma la presenza della bottiglia

• Motore del nastro trasportatore SPENTO
• Valvola di riempimento ACCESA
• L'istruzione TON traccia la durata del riempimento
• La transizione avviene quando il timer di riempimento è completo

• Valvola di riempimento SPENTA
• Motore del nastro trasportatore ACCESO
• Il sistema attende la condizione di "bottiglia libera"
• La transizione avviene quando il sensore non rileva più la bottiglia, quindi ritorna a Inattivo o al ciclo successivo

1. Stato 0 — Inattivo / Attesa
2. Stato 1 — Indicizzazione
3. Stato 2 — Riempimento
4. Stato 3 — Uscita

Questa sequenza è intenzionalmente semplice. La semplicità è utile perché rende visibili le modalità di guasto.

Cosa dovrebbe imporre la ladder logic?

La ladder logic dovrebbe imporre tre cose:

• mutua esclusività degli stati
• chiare condizioni di transizione
• comportamento di interruzione sicuro

In pratica, ciò significa:

• solo un bit di stato dovrebbe essere attivo alla volta
• ogni transizione dovrebbe dipendere da condizioni di processo osservabili
• le condizioni di stop o arresto di emergenza dovrebbero interrompere la continuità della sequenza in modo prevedibile

Un errore comune dei principianti è lasciare che più bit di stato si eccitino da condizioni sovrapposte. Il risultato è una sequenza che sembra a posto finché la macchina non si rifiuta educatamente di obbedire allo schema.

### Esempio: un rung di autoritenuta per l'abilitazione della sequenza

Di seguito è riportato un esempio semplificato in stile ladder che mostra un'autoritenuta di avvio con una condizione di interruzione di arresto di emergenza.

|----[XIC Start_PB]----+----[XIO E_Stop_Active]----------------(OTE Seq_Enable)----| | | | +----[XIC Seq_Enable]----[XIO E_Stop_Active]-----------------|

Cosa fa questo rung:

• `XIC Start_PB` avvia la sequenza quando il pulsante di avvio è vero
• `XIC Seq_Enable` mantiene la sequenza dopo che il pulsante è stato rilasciato
• `XIO E_Stop_Active` interrompe il rung ogni volta che la condizione di arresto di emergenza diventa attiva
• `OTE Seq_Enable` eccita il bit interno di abilitazione sequenza

Questa è logica di base, ma è fondamentale. Se il comportamento di abilitazione della sequenza è trasandato, il resto della macchina a stati erediterà tale trasandatezza.

Come si testa la macchina a stati nel preset di riempimento bottiglie?

Testa la sequenza validando ogni transizione rispetto allo stato dell'attrezzatura simulata.

Un ciclo di test pratico appare così:

• avvia la sequenza da Inattivo
• conferma che il nastro trasportatore funzioni durante l'Indicizzazione
• verifica che il sensore della bottiglia arresti il nastro nella posizione di riempimento
• conferma che la valvola di riempimento si ecciti solo durante il Riempimento
• verifica che il timer si completi prima della transizione
• conferma che la bottiglia esca e liberi il sensore durante l'Uscita
• ripeti il ciclo per verificare problemi di ritenzione latente dello stato

La ripetibilità conta. Una sequenza che funziona una volta è una demo. Una sequenza che funziona attraverso cicli ripetuti con iniezione di guasti inizia ad assomigliare all'ingegneria.

Le istruzioni ladder essenziali per il commissioning virtuale sono quelle che gestiscono stato, tempo, conteggio, confronto e interblocchi in condizioni di processo mutevoli.

Un simulatore è utile proprio perché espone se tali istruzioni vengono utilizzate in modo coerente.

Istruzioni fondamentali da padroneggiare

Per la maggior parte degli esercizi di commissioning basati su browser, concentrati su queste classi di istruzioni:

• Contatti e bobine
• XIC / esame normalmente aperto
• XIO / esame normalmente chiuso
• OTE / eccitazione uscita
• pattern di latch/unlatch dove appropriato e attentamente delimitato

• Timer
• TON per azioni ritardate e tempi di sosta
• TOF dove il comportamento di ritardo allo spegnimento è importante
• temporizzazione ritentiva solo quando la logica di processo lo richiede veramente

• Contatori
• utili per indicizzazione, dosaggio e verifica del ciclo
• dovrebbero essere accoppiati con condizioni di reset esplicite

• Comparatori
• controlli di maggiore di, minore di, uguale
• essenziali per soglie analogiche, punti di allarme e permissivi

• Operazioni matematiche e logiche
• scalatura, condizioni derivate e logica di controllo booleana compatta

• Istruzioni PID
• rilevanti quando lo scenario include controllo di flusso, livello, pressione o temperatura
• dovrebbero essere validate rispetto al comportamento analogico, non trattate come una scatola magica

Perché queste istruzioni contano in un processo simulato?

Contano perché il commissioning virtuale non è solo "il rung si eccita?". È "la macchina si comporta correttamente nel tempo e attraverso i cambiamenti di stato?".

Ciò richiede:

• timer che non si sovrappongono in modo errato
• contatori che non avanzano per vibrazioni (chatter)
• confronti che non creano allarmi molesti
• interblocchi che falliscono in sicurezza quando un permissivo scompare

È qui che un digital twin aggiunge valore. Non stai semplicemente guardando i bit cambiare. Stai confrontando lo stato del ladder con la risposta dell'attrezzatura.

Cosa significa operativamente "validazione di digital twin"?

In questo articolo, validazione di digital twin significa testare la ladder logic contro un modello di attrezzatura virtuale realistico e verificare se il comportamento della macchina o del processo corrisponde alla filosofia di controllo prevista.

Operativamente, ciò include:

• osservare se le uscite comandate creano lo stato dell'attrezzatura previsto
• confermare che permissivi e trip blocchino transizioni non sicure
• validare le risposte ad allarmi e guasti
• revisionare la logica quando il processo simulato rivela un errore

Questa è un'affermazione delimitata. Non implica che un simulatore di formazione sia un modello di impianto certificato, uno strumento di valutazione SIL o un sostituto per le attività formali del ciclo di vita della sicurezza secondo la norma IEC 61508.

Alt-text dell'immagine: Screenshot del simulatore basato su browser OLLA Lab che mostra un digital twin di riempimento bottiglie, evidenziando il timer TON attivo e il corrispondente stato I/O della valvola di riempimento nel pannello delle variabili.

Gli studenti validano la causalità I/O tracciando se un cambiamento logico dell'ingresso produce l'uscita e la risposta della macchina previste secondo la filosofia di controllo definita.

Questa è la competenza principale di risoluzione dei problemi. Il cablaggio è importante, ma la causalità è la competenza più profonda.

In OLLA Lab, il pannello delle variabili consente a uno studente di:

• forzare o attivare un ingresso
• osservare se la condizione del rung diventa vera
• verificare se l'uscita si eccita
• confermare se la macchina simulata risponde di conseguenza

Ad esempio, se il sensore di presenza bottiglia viene forzato a vero:

• lo stato di indicizzazione dovrebbe arrestare il nastro
• lo stato di riempimento dovrebbe diventare idoneo
• la valvola di riempimento dovrebbe eccitarsi solo se tutti i permissivi rimangono soddisfatti

Se uno qualsiasi di questi passaggi fallisce, lo studente può ispezionare:

• permissivi mancanti
• ritenzione dello stato errata
• logica del sensore invertita
• condizioni del timer non ancora completate
• comandi di uscita bloccati da un interblocco

Questo è effettivamente un esercizio di osservabilità. Il simulatore non rimuove la disciplina ingegneristica; espone se ne possiedi una.

Perché questo è meglio che guardare semplicemente le luci su un pannello di addestramento?

È meglio per l'analisi della causalità perché lo studente può ispezionare sia lo stato della logica che lo stato fisico simulato in un unico ambiente.

Una luce sul pannello ti dice che un'uscita si è accesa. Non ti dice necessariamente se:

• la bottiglia ha effettivamente raggiunto la posizione
• la valvola avrebbe dovuto aprirsi in quel momento
• il timer è partito troppo presto
• la sequenza è ora in stallo in attesa di una condizione che non potrà mai verificarsi

Questa è la differenza tra conferma dell'uscita e validazione del processo. La prima è utile. La seconda è ciò di cui il commissioning ha effettivamente bisogno.

Un ingegnere Simulation-Ready può dimostrare, osservare, diagnosticare e consolidare la logica di controllo contro un comportamento di processo realistico prima che tale logica raggiunga un processo attivo.

Questa definizione è operativa, non aspirazionale.

Un ingegnere Simulation-Ready dovrebbe essere in grado di:

• definire come appare il comportamento corretto della macchina
• mappare l'I/O alle azioni di processo
• costruire o revisionare la ladder logic per il controllo della sequenza
• osservare la risposta dell'attrezzatura simulata
• iniettare almeno una condizione anomala
• diagnosticare perché la sequenza ha fallito
• revisionare la logica
• rieseguire il test finché il comportamento non è stabile

Questo non è lo stesso che essere pronti per il sito, autorizzati alla sicurezza o autonomamente implementabili. Il commissioning dal vivo comporta ancora pratica elettrica, disciplina di lockout/tagout, toolchain specifiche del fornitore, controllo della documentazione e vincoli del sito che nessun browser può replicare completamente.

Ma la simulazione addestra la parte che è spesso più difficile da ottenere precocemente: l'esposizione ripetuta al fallimento della sequenza, alla logica di interblocco, agli errori di temporizzazione e al ripristino controllato dei guasti.

Quali prove dovrebbe conservare uno studente?

Conserva le prove che mostrano il ragionamento ingegneristico, non semplicemente il completamento.

Un pacchetto di prove compatto dovrebbe includere:

• l'obiettivo del processo
• lista I/O e significati dei tag
• la sequenza ladder
• gli stati della macchina previsti
• il guasto iniettato
• il fallimento osservato
• la revisione della logica
• il risultato della validazione post-correzione

Quel pacchetto è utile per l'autovalutazione, la valutazione dell'istruttore e la formazione basata sul team. È anche molto più vicino a come viene discusso il lavoro reale sui controlli: per comportamento, modalità di guasto e cronologia delle revisioni.

Un laboratorio di automazione basato su browser non può sostituire il cablaggio in campo, la configurazione dell'hardware specifico del fornitore o la validazione formale della sicurezza.

Quel confine dovrebbe essere dichiarato chiaramente.

OLLA Lab è meglio inteso come un ambiente di validazione e prova a rischio contenuto per:

• costruzione di ladder logic
• progettazione di sequenze
• tracciamento I/O
• validazione di digital twin
• pratica analogica e PID
• iniezione di guasti
• risoluzione dei problemi in stile commissioning

Non è:

• una certificazione
• una garanzia di occupabilità
• un ambiente di qualificazione SIL
• un sostituto per la competenza in sito supervisionata

Quei limiti non indeboliscono lo strumento. Rendono leggibile il suo valore.

Dove si inserisce questo in un percorso formativo serio?

Una progressione credibile appare così:

1. apprendere la sintassi ladder di base e il comportamento delle istruzioni
2. esercitarsi nella progettazione di sequenze in simulazione
3. validare la causalità e la gestione dei guasti contro i digital twin
4. documentare le prove ingegneristiche
5. passare a flussi di lavoro specifici per l'hardware, pratica elettrica ed esposizione al commissioning supervisionato

Quella sequenza è pratica perché pone la ripetizione a basso rischio prima del lavoro in campo ad alta conseguenza.

Un laboratorio PLC domestico basato su browser a costo zero è utile perché offre agli studenti l'accesso alla parte della formazione sull'automazione che i banchi hardware raramente forniscono: il processo.

Se l'obiettivo è diventare Simulation-Ready, l'abilità chiave non è disegnare rung in isolamento. È dimostrare che la ladder logic sopravvive al contatto con il comportamento della macchina, gli stati anomali e le transizioni di sequenza. OLLA Lab supporta quel flusso di lavoro attraverso l'editing ladder basato su browser, la simulazione, la visibilità I/O, la validazione di digital twin e la pratica basata su scenari. Usato correttamente, non è un sostituto per l'esperienza in campo, ma può essere uno spazio di prova pratico per errori che è meglio trovare prima che un nastro trasportatore reale, uno skid di pompaggio o una valvola di riempimento dipendano dalla logica.

- Per capire come la logica di controllo interagisce con modelli di processo immersivi, vedi Digital Twins per tutti noi: il vantaggio WebXR di OLLA Lab.

• Per una visione architettonica più ampia, leggi la nostra guida agli Ambienti di formazione Cloud Native.
• Per la persistenza dei dati e la struttura del progetto, leggi Serializzazione JSON in OLLA Lab.
• Pronto a costruire la tua prima sequenza? Apri il preset di riempimento bottiglie in OLLA Lab.

- Panoramica dello standard di sicurezza funzionale IEC 61508 - Linguaggi di programmazione per controllori programmabili IEC 61131-3 - NIST SP 800-207 Architettura Zero Trust - ISO 9241-110 Ergonomia dell'interazione uomo-sistema - Tao et al. (2019) Digital twin nell'industria (IEEE) - Fuller et al. (2020) Tecnologie abilitanti per il digital twin (IEEE Access) - U.S. Bureau of Labor Statistics - Deloitte Manufacturing Industry Outlook