Overall Equipment Effectiveness
A real-time monitoring and analytics dashboard built for plant supervisors: equipment performance, benchmarks and the numbers needed to make a call during a shift instead of after it.
- Timeline
- 2023 – 2025
- Context
- Professional project · Innoart Technologies
- My role
- Front end & data engineer — real-time dashboards, visualisation, API performance
Illustrative representation of the interface — not a screenshot of client software.
- 35%
- Lower frontend data latency
- 15%
- Better operational efficiency
API response optimisation and efficient state handling
Custom visualisations built for plant supervisors
The problem
Supervisors were running the floor on yesterday's numbers. Equipment performance existed inside the machines and in end-of-shift reports, but nowhere a supervisor could glance at while a shift was still running and still do something about it.
Raw machine data is not an answer. Availability, performance and quality only mean something once they're framed against a benchmark, and that framing was happening in people's heads.
The first working version was also slow. A dashboard that takes several seconds to answer gets checked once a day, which defeats the point of building it.
What I worked on
Designed the real-time operations dashboard for factory supervisors — what belongs on the screen, what a supervisor should notice first, and what can wait for a drill-down.
Built custom data visualisations aimed at plant supervisors rather than analysts: benchmarks, trends and downtime framed as decisions, not as chart types.
Reduced frontend data latency by roughly 35% through API response optimisation and more efficient state handling on the client.
Worked across the Django/Python backend, the Node service layer and the PostgreSQL schema that the dashboard reads from.
How it worked
Python and Django handle aggregation and the OEE calculations; a Node service sits on the ingest and streaming side; PostgreSQL stores the time-series and reference data the dashboard reads.
The API was restructured to return exactly the shape the charts consume. A large part of the latency win came from stopping the client from stitching together several responses and recomputing derived values on every render.
On the client, state is scoped per widget instead of held in one large shared store, so a new reading updates one chart rather than cascading a re-render through the whole page.
React with ApexCharts for the visualisation layer, with chart configuration centralised so every chart on the dashboard shares one visual language.
Challenges
"Real-time" and "a chart with a lot of points" pull against each other. Deciding what genuinely needed to be live, and what could be aggregated server-side and polled, was the difference between a smooth dashboard and a janky one.
Industrial data has gaps — machines go offline, readings arrive late or out of order. The charts had to represent missing data honestly instead of interpolating a comfortable-looking line over it.
Supervisors are not analysts and are not sitting comfortably at a desk. The interface had to be readable at a glance, in a noisy environment, by someone with a job to get back to.
Outcome
~35% reduction in frontend data latency after API response optimisation and state handling changes.
~15% improvement in operational efficiency, attributed to the custom visualisations giving supervisors actionable benchmarks.
Performance benchmarks and insights moved from end-of-shift reports into a live view supervisors could act on within the shift.