Most floors run controllers from several decades side by side. We read them through one read-only connection, give every number a single name in a structured data layer, and put a live dashboard and APIs on top. We start with the equipment you already run.
Describe your equipmentIllustrative diagram. The machines, tag names and screen are samples, not data from a real plant.
Where most plants start
Mixed floors are normal
Plants grow one machine at a time. A press bought years ago sits next to a machining center bought last spring, and each one came with the controller that was current when it arrived. Some speak Ethernet. Some only speak serial. A few have nothing but a counter and a light stack, and someone writes their numbers on a sheet at the end of the shift.
That mix is not something to fix before you can see the floor. It is the starting point. If a PLC holds a value, or an HMI or an OPC server can see it, there is usually a way to read it without changing how the machine runs.
Where a machine holds nothing useful, we tell you plainly. Then we look at what can fill the gap, often a spreadsheet the line already keeps.
How the pieces fit
The layers
Four layers, left to right, the same as the diagram above. Each one has a single job.
LAYER 1
Machines, old and new
Older and newer PLCs, HMIs and the spreadsheets kept beside them. We walk the tag lists with your controls people and map what each machine actually holds. Allen-Bradley and other makes.
LAYER 2
Read-only connection
Kepware or another OPC server reads the tags. It only reads. There is no write path to the controls, and your own IT and controls people can check that for themselves.
LAYER 3
Structured data layer
Every value lands in one place with one name, one unit and its context: line, machine, part and shift. It runs inside your environment, and the code and the data are yours.
LAYER 4
Dashboard and APIs
A live plant view: machine status, part counts, run rates, uptime and downtime with reasons, scrap where the data exists, OEE and trends. The same layer serves APIs for other tools.
A plain word on OEE. The controls supply run state and counts. Shift calendars and ideal cycle times usually come from your ERP or your standards, so we bring those in from there instead of guessing them.
Tag normalization
One name per number
Every machine names its values its own way. On the older press, the good-part count lives at N7:12. The newer press calls it Line2_Press7_PartCount. The HMI on the weld cell shows it as CNT_GOOD. All three mean the same thing.
Before any of it reaches a screen, we give that count one name, one unit and the context around it: which line, which machine, which part was running and which shift. That is tag normalization, the quiet and careful part of the job.
It is what lets you compare one press with another, or this week with last, without someone translating tag names by hand. Your team reviews the mapping, and when a controller is swapped, its new tags are mapped onto the same names.
Illustrative tag names
Press 4, older PLCN7:12
Press 7, newer PLCLine2_Press7_PartCount
Weld cell, HMICNT_GOOD
In the data layergood_partsOne name for all three, counted in parts, with line, machine, part number and shift attached.
Once the layer exists
What the data layer is for
The dashboard is usually the first thing a plant wants. It is one reader among several, and every reader sees the same names.
DashboardsThe live plant view, on screens by the lines and in the office.
ReportsShift and weekly reports that assemble themselves from the same numbers.
APIs for other toolsERP, quality and scheduling systems read what they need from one place.
Spreadsheets that pull live numbersThe sheets your planners already use, filled from the floor instead of retyped.
Capabilities
What else we build
The plant dashboard is often where work with us begins. The same team builds the systems around it.
Spreadsheet workflows, rebuilt
Critical spreadsheets become governed web apps with an audit trail and permissions. You approve the rules before anything is rebuilt.
Workflow automation and integrations
Your systems pass work to each other, so people stop copying it from one screen to the next.
A structured data layer with APIs
One place your tools read from, with names and context that agree.
Reporting that assembles itself
Reports built from live data instead of pasted together by hand.
Custom internal tools
Small, focused tools for the people who run the floor and the office.
Ongoing support
Available if you want it, never required. You own the code, the data and the systems either way, with no licence.
Who does the work
One team covers controls and PLC work, including Allen-Bradley, data architecture and integration, backend and frontend development, and ERP advisory, with 20+ years building systems inside operations-heavy businesses.
Contact
Tell us what is on your floor.
A rough list is plenty: the machines, the controllers you know about, whether Kepware or an OPC server is already there, and the number you would want on a screen first. We will tell you what looks readable, what does not, and whether we are the right fit.
