Sensor to dashboard — how factory data actually flows

If you ask three vendors how their Industry 4.0 platform works, you'll get three glossy diagrams and zero useful information. The diagrams are deliberately vague. They're sales aids, not architecture.

This is the honest version. The pipeline an actual production-line dashboard runs on, written so a non-engineer SMB owner can follow it without losing the thread.

The six layers, simplified

A real Industry 4.0 pipeline has six layers between the machine and the screen. Each layer can fail in its own specific way. A vendor who doesn't understand all six is a vendor who's going to ship a fragile system.

1. Equipment       (the machine itself)
2. Sensor / PLC    (turns physical state into electrical signal)
3. Field gateway   (collects, buffers, forwards)
4. Backend         (stores, normalises, calculates)
5. API + cache     (serves data to UIs)
6. Dashboard / app (renders to humans)

We'll walk through each one.

Layer 1: equipment

The machine. A pump, a packing line, a CNC, an injection moulder. It has electrical or mechanical state — running, idle, faulted, producing — that you want to know about.

The thing most vendors gloss over: equipment age and condition. A 2024 servo press with a built-in fieldbus interface is a different problem from a 1995 hydraulic press with no data outputs at all. The first is a software problem; the second is a sensor-installation problem before it's a software problem.

How this layer fails: the machine itself fails. Industry 4.0 doesn't fix this — it just lets you see it happening sooner.

Layer 2: sensor / PLC

This layer turns physical state into electrical signal. A few common patterns:

• Existing PLC exposes data. Modern PLCs (Siemens S7, Mitsubishi MELSEC, Omron NX) speak Modbus, OPC UA, or fieldbus protocols. If your equipment has one of these, this layer is mostly already done.
• PLC exists but doesn't expose data. We add a small protocol bridge — typically an Advantech or Moxa I/O module — that reads the PLC's signals and exposes them on the network.
• No PLC at all. We retrofit. A small microcontroller board, a few standard sensors (proximity, current, vibration, temperature), and the machine starts speaking factory-network.

The retrofit option is more common than people expect — about half of the SMB lines we instrument have at least one machine that needs it.

How this layer fails: sensor mis-installation. A cycle counter mounted in the wrong spot, a temperature probe with bad thermal contact, a current sensor on the wrong leg of a 3-phase supply. We've seen all three.

Layer 3: field gateway

A small computer on the factory floor that collects data from sensors and PLCs, buffers it locally, and forwards it. Usually a small fanless PC or an industrial gateway (Advantech UNO, Siemens IoT2050, custom Linux on a ruggedised mini-PC).

This layer matters for two reasons:

1. Resilience. If your factory network drops or the cellular connection wobbles, the gateway buffers data locally and sends when reconnected. Without this layer, every dropped packet is lost data.
2. Protocol normalisation. Different sensors speak different protocols. The gateway's job is to convert all of them into one unified message format (typically MQTT or HTTPS payloads) before they hit the backend.

How this layer fails: power loss without UPS, network outage longer than buffer size, the gateway PC running out of disk space because someone left logging at debug level. The first two are why we put gateways on UPS as a default; the third is why we monitor gateway disk health.

Layer 4: backend

The cloud-side data layer. Receives data from gateways, validates it, normalises it, stores it, calculates derived metrics (OEE, downtime, kWh per unit produced).

For SMB-scale builds we typically run:

• Backend on AWS or your preferred cloud
• A time-series database for raw sensor data (typically TimescaleDB, ClickHouse, or InfluxDB depending on volume)
• A relational database for "business" data — assets, lines, shifts, users, alerts
• A small queue for async processing (alerts, reports, integrations)

The thing that surprises clients: most of the engineering effort is here, not on the dashboard. A pretty dashboard with bad data is worthless. A boring dashboard with rock-solid data is gold.

How this layer fails: schema drift over time, time-zone bugs around DST or shift boundaries, OEE calculation edge cases on planned PMs, accidentally deleting data on a "cleanup" script. We treat backend changes carefully — they affect every dashboard view.

Layer 5: API + cache

Between the backend and the dashboard sits an API. It exposes endpoints like "give me OEE for line 3, last 24 hours, broken down by hour" and serves them quickly.

A cache layer in front of the API matters because:

• A dashboard refreshing every 30 seconds × 10 dashboards × 100 widgets = a lot of database queries.
• Without caching, the database becomes the bottleneck and the dashboard feels slow.
• With proper caching, dashboards stay snappy even when data volume grows.

How this layer fails: cache invalidation bugs (showing stale data after an update), API rate limiting, a deploy that misses cache warmup. These are usually invisible until they aren't.

Layer 6: dashboard / app

What the user actually sees. The bit clients spend the most time judging when comparing vendors. The bit that's typically least important to overall reliability.

A good dashboard:

• Loads in under 2 seconds, even on a Klang Valley 4G connection.
• Updates within 1–5 seconds of new data arriving.
• Works on mobile because supervisors are on phones, not desks.
• Has an obvious call-to-action when something is wrong (red, big, with a "what to do" prompt).
• Doesn't try to show everything — shows what matters now.

How this layer fails: mostly UX problems. Dashboards that show 47 metrics but nothing actionable. Dashboards that look great in demos but unusable on a 5-inch phone screen during a real incident. Designs that confuse "live" with "stale".

What this means for buying decisions

If you're talking to a vendor:

• Ask what's at each layer. A vendor who can answer "we use Modbus to OPC UA via Advantech UNO, MQTT to AWS IoT, TimescaleDB for time-series, GraphQL API with Redis cache, React dashboard" has actually built systems before. A vendor who can only show you screenshots probably hasn't, or doesn't want you to know what they use.
• Ask about layer-3 resilience specifically. What happens when the network drops? If the answer is "data is lost", that's a serious gap.
• Ask about layer-4 calculations. OEE is easy to calculate badly. Ask how they handle planned downtime, scheduled PMs, shift changeovers, public holidays.
• Don't over-rate the dashboard. A pretty dashboard backed by fragile data is the exact failure mode that wastes the most money.

What our stack looks like

For Malaysian SMB factory clients, our typical stack:

• Layer 1–2: existing PLCs where possible (Modbus / OPC UA), Advantech I/O for retrofit, custom microcontroller for legacy gear
• Layer 3: industrial gateway PC running Linux, MQTT, local buffering, UPS-protected
• Layer 4: AWS or DigitalOcean depending on cost, TimescaleDB or ClickHouse for time series, Postgres for business data
• Layer 5: TypeScript-based API, Redis cache, role-based access control
• Layer 6: React web dashboards, native Android for floor staff, WhatsApp / email alerts

We don't lock clients into the stack — everything's standard, exportable, and yours. If you ever want to take it elsewhere, you can.

If you'd like to walk through what the right stack looks like for your specific factory, drop us a line — free 30-minute discovery call, no obligation.