Dong Tan Nguyen
Case study 04

Smart Factory

A real-time operations system for an electronics production floor, built around the fact that the physical world does not wait for a page refresh.

Years2019 — 2021
ScopeProduction, inventory & floor operations
The floor, on a screen

What it had to do

A production floor cannot wait for a spreadsheet, a refresh button, or a person to reconcile several systems at the end of a shift. Operators, materials, boards, reels, machines, and manufacturing steps each leave a trace; the useful system is the one that turns those traces into a current, understandable picture of what is happening now.

The work covered the path around that floor: production tracking and exceptions, scanner and RFID-assisted checkpoints, machine-facing state, warehouse movement, supply and purchasing context, and the dashboards people used to make sense of it. A late or invalid signal needed to be visible as a situation to resolve, not quietly become bad data.

Ruby on RailsReactMQTTPostgreSQL
production state on the floor
Live
operator and material checkpoints
RFID
shared operational record
One
The shape of it
floor operations and planninglive signals and operational state
Guided view 0 / 3Ready

Explore the system

Step through the three operational paths.

[ ] chapters · P play · Esc reset
Use the guided controls to focus device ingest, operational processing, and feedback with live dashboards. Each component can also be selected directly.scan eventsbadge eventssubscribequeue workbufferscheduled workrecord statebroadcastlive updatesapplication datafeedbackdevice promptsBarcode Scanners · floor checkpointsBarcode Scannersfloor checkpointsRedis · buffers · queues · pub/subRedisbuffers · queues · pub/subWork Scheduler · scheduled floor tasksWork Schedulerscheduled floor tasksRails API · access · operational dataRails APIaccess · operational dataMQTT Broker · device message routingMQTT Brokerdevice message routingDevice Ingest · normalises device messagesDevice Ingestnormalises device messagesOperational Rules · route · validate · updateOperational Rulesroute · validate · updateReact Dashboard · live floor stateReact Dashboardlive floor stateRFID Readers · operator · material checkpointsRFID Readersoperator · material checkpointsDevice Feedback · light · sound promptsDevice Feedbacklight · sound promptsPostgreSQL · work · events · inventoryPostgreSQLwork · events · inventoryLive Updates · dashboard channelsLive Updatesdashboard channels

Device signals are captured at the floor, interpreted as operational work, recorded durably, and then reflected back through physical feedback and live dashboards. Labels stay deliberately generalised; the interaction boundaries are the important part.

One event, end to end

How it moves

  1. 01

    Capture

    An operator action, scanner read, RFID checkpoint, or machine-side update produces a signal at the point where work is actually happening.

  2. 02

    Interpret

    The system gives that raw signal operational context: which work, material, person, machine, or step it belongs to — and whether it is valid in that moment.

  3. 03

    Record

    A durable operational record updates the relevant production and inventory state, leaving a trace that a later operator can understand.

  4. 04

    Broadcast

    The changed state reaches the React dashboards in real time, so the screen follows the floor instead of catching up after the fact.

  5. 05

    Assist

    Feedback and exceptions make the next action clear at the point of work, helping a wrong scan become an immediate correction rather than a downstream mystery.

  6. 06

    Plan

    Warehouse movement, supply, purchase, and estimation data add the material context needed to keep production decisions connected to reality.

Designed for the physical world

The screen had to agree with the floor

Capture at the source. Make state visible. Surface exceptions early. Leave a trace.

  • An invalid scan

    A read that does not fit the current work context is handled as an immediate exception, so the operator can correct the situation before it becomes a misleading production record.

  • A delayed device update

    The floor-facing workflow is separated from the screen update path. State is recorded first, then broadcast, so a delayed display does not erase what happened.

  • A handoff between people or places

    Operator and material checkpoints create an understandable trail across workstations and warehouse movement, giving the next person context without relying on memory.

What I actually did

  • Built the live operational path

    Built the Rails and React application paths that turn floor activity into current production state, keeping the dashboard close enough to real time to support decisions while work is still in motion.

  • Connected physical checkpoints to software state

    Implemented scanner, RFID, and machine-event workflows that attach physical activity to the right manufacturing context instead of treating a device message as useful on its own.

  • Made exceptions part of the workflow

    Worked on validation and feedback loops around floor events so mismatches were visible and actionable at the moment they occurred, with a record for follow-up.

  • Kept production connected to materials

    Built across the operational model for boards, reels, machines, inventory movement, supplies, and purchasing, so floor status could be understood alongside material reality.

  • Made the system useful in the room

    Delivered dashboards and operational views for people doing the work, with live updates and enough history to answer the practical question behind most factory software: what happened, where, and what should happen next?

The contribution trail

What changed because I was there

Factory names, floor-specific rules, device details, and internal integrations are intentionally generalised. The responsibilities and system behaviour are representative of my work.

  • 01

    A shared operational model

    Connected production work, materials, equipment, people, and warehouse movement in one application model rather than leaving each area to its own disconnected record.

  • 02

    Live state over periodic refresh

    Established the real-time path from operational events to floor dashboards, so current conditions could be observed while they still mattered.

  • 03

    Rules at the point of ingestion

    Put validation around incoming operational signals, turning ambiguous or inappropriate reads into visible exceptions before they could distort downstream state.

  • 04

    Checkpoints that carry context

    Made scanner and RFID interactions useful as operational handoffs: each one could connect a person or material to the work and place around it.

  • 05

    Planning stayed close to execution

    Brought supply, purchasing, inventory, and estimation concerns into the same operational picture, so planning did not have to guess at what the floor was doing.