Paperless OEE: Build an Offline PWA from Barcode Scans & PLC Stop Codes
Paper downtime sheets are a black hole. Operators fill them out, supervisors stack them, and nobody analyses the data. The result: you guess at OEE, you chase symptoms instead of root causes, and every month you lose 15–20% capacity you didn’t know you had.
This guide walks through building a zero-server, offline-capable Progressive Web App that calculates real-time OEE directly from operator interactions: a barcode scan for job ID, a physical button box for downtime reason codes, and a few manual inputs for scrap. Everything stores locally in IndexedDB. No signup, no server, no license fees. You can run it on a tablet strapped to the machine.
We’ll cover the exact data points you need, how they feed into the Availability × Performance × Quality formula, and how attaching the whole thing to a visual SOP system locks in the ROI — turning data into daily action.
1. The Core OEE Formula — and Why Most Shops Get It Wrong
OEE is not a mystery. It’s three numbers multiplied together:
- Availability = (Operating Time) / (Planned Production Time)
- Performance = (Ideal Cycle Time × Total Parts) / (Operating Time)
- Quality = (Good Parts) / (Total Parts)
The problem is that most shops use machine-logged run time for availability, then manually estimate performance based on a ideal cycle time they haven’t validated in years. Quality is often a monthly scrap report pulled from a separate system. The formula gets fragmented, and nobody trusts the output.
Our PWA solves that by tying every data point to a single operator action at the time it happens. The operator is the source of truth, not a paper sheet.
2. Capturing Data on the Floor: Barcode, Button Box, and PLC Edge Triggers
2.1 Operator Barcode Scan → Job & Part Master Data
When a job starts, the operator scans a printed barcode on the job packet. The PWA decodes the job number, part number, and programmed ideal cycle time from a local lookup table (preloaded from a CSV or pasted from your ERP). This avoids any network call.
Once the scan is registered, the app begins timing the planned production run. Every subsequent scan of the same barcode (or a “part produced” barcode) increments the total parts produced counter. This becomes the Performance numerator later.
2.2 Physical Button Box → Downtime Reason Codes
Operators won’t open a dropdown menu when a tool breaks. We built a simple USB button box (or a touch screen emulation) with 8 physical buttons labelled “Material Wait”, “Setup”, “Tool Change”, “Breakdown”, “Quality Issue”, “Operator Absent”, “Planned Break”, “Other”. Each press records a timestamp and the reason code code.
These events become the raw logs for Availability. The app automatically calculates cumulative downtime per shift by summing the duration of each event (ignoring “Planned Break” if it falls inside scheduled breaks).
The button box is read via the WebHID API or a simple serial-to-USB converter. For shops that don’t want hardware, we also include a fallback touch screen grid.
2.3 PLC Edge Triggers for Unplanned Stops (Optional)
If your machine has a PLC with a TCP/IP or Modbus output, you can feed stop signals directly into the PWA. The app listens on a local WebSocket (running on the same device via a lightweight Node.js helper) for stop codes sent by the PLC. This eliminates the need for operator intervention on pure machine faults.
But even without PLC integration, the button box method works well enough. The key is that every stop is time-stamped and categorised — no more “miscellaneous” downtime.
3. Quality: Scrap Count and First Pass Yield
At the end of each job, or whenever a quality issue arises, the operator uses the PWA to enter the scrap count. The app also prompts them to confirm the total parts produced (which may have been auto-counted by the barcode system).
From there, First Pass Yield is derived as:
FPY = (Total Parts Produced – Scrap) / Total Parts Produced
That scrap input, combined with the earlier downtime and performance data, completes the OEE formula. No manual Excel sheet required.
4. Data Points Required — Exact Table for Implementation
The table below shows each data point, its source, and how it maps to the final OEE value. Build your IndexedDB schema around these fields.
| OEE Component | Data Point | Source / Input | Calculation Use |
|---|---|---|---|
| Availability | Planned Production Time | Shift schedule in PWA (manual config) | Denominator for Availability |
| Availability | Operating Time | Planned Time minus cumulative downtime from button box / PLC logs | Numerator for Availability |
| Availability | Downtime events (timestamp + reason code) | Button box or PLC | Summed to subtract from Planned Time |
| Performance | Ideal Cycle Time | Preloaded from job master data (scanned barcode) | Multiplied by Total Parts to get theoretical time |
| Performance | Total Parts Produced | Barcode scans or manual entry | Multiplied by Ideal Cycle Time |
| Quality | Scrap Count | Operator input | Subtracted from Total Parts for FPY |
| Quality | First Pass Yield | Calculated: (Total Parts – Scrap) / Total Parts | Quality multiplier in OEE |
5. Building the Offline PWA — Architecture Overview
The entire app is a single HTML file with embedded JavaScript (or a small set of files). Service Worker enables offline availability after the first load. IndexedDB stores:
- Job master data (barcode, part number, ideal cycle time)
- Shift schedule
- All event logs (downtime, part scans, scrap entries)
- Calculated OEE snapshots per shift / job
On every event, the app recalculates the current OEE and displays it on a real-time dashboard. No server sync required. If you want to send data to a backend later, you can add a sync button — but the core value is pure offline, instant feedback.
6. Real-Time OEE Dashboard — What You See
The dashboard shows three gauges (availability, performance, quality) and a combined OEE percentage. Below that, a running log of the last 50 events, sorted by recency. Operators can see today’s OEE vs. target, and supervisors can walk the floor and see the numbers live on the tablet.
Because the data is stored in IndexedDB, you never lose a record. Even if the device crashes, the data persists. And because there’s no server, there’s no security attack surface — the app runs entirely on the device you control.
7. Avoiding Common Pitfalls
- Ideal cycle time must be validated. If it’s out of date, Performance will be either inflated or crushed. Recalibrate every quarter using a stopwatch on the fastest operator.
- Don’t count planned breaks as downtime. Hard-code your shift breaks (e.g., 30-minute lunch) so they are excluded from Availability automatically.
- Train operators on the button box. If they treat it like a toy, data becomes garbage. Use visual SOPs (posters or laminated cards) next to the machine showing which button to press for each stop reason.
- Scrap entries must be immediate. Do not batch-scrap at the end of the week; it will mismatch part counts.
8. The Ryxen Hook: Software That Locks in the ROI
Building a PWA is a great first step, but the real leverage comes when you connect that data to a system that forces action. Paperless OEE is pointless if nobody looks at the dashboard. That’s where visual SOPs and exception-based workflows come in.
At Ryxen, we build tools like ShopDocs (Visual SOPs) and SafeDesk (Safety Compliance). The data from your offline OEE PWA can feed directly into a visual SOP viewer: when OEE drops below a threshold, a visual SOP card appears on the tablet showing the operator exactly which steps to follow for troubleshooting. No paper lookup, no supervisor call — immediate, guided response.
Automating this loop — capture OEE → detect out-of-spec condition → display corrective visual SOP → log operator action — is what locks in the ROI. You stop losing that 15–20% capacity because every minute of downtime triggers a closure loop, not a paper sheet.
The code for the PWA is open source and available on our GitHub. But the ecosystem integration that makes it sustainable is what Ryxen provides. We build software that works like your best tools: one job, one screen, no bloat.