On the shop floor, data is everywhere: in PLC controllers, in SCADA systems, in sensors and IoT devices. The trouble is that this data rarely talks to itself. Every machine, every line and every maintenance system speaks its own protocol and keeps its numbers in its own format. For an operations director this adds up to one simple thing: you have plenty of data and still too few decisions.
In our experience on industrial and Industry 4.0 projects, the hard part is not “connecting a sensor” but carrying data from the machine all the way to the screen where someone acts on it. That work lives where OT and IT meet, and it needs people who understand both the controllers and the data pipeline. We provide those specialists through team augmentation or a dedicated team, with an optional AI and analytics layer.
Why is shop-floor data so hard to actually use?
Because the OT (automation) world and the IT world grew up apart for years and still sit in silos:
- different protocols - Modbus, Profinet, OPC UA, S7 and dozens of vendor variants,
- no shared time or units - the same quantity measured differently on every line,
- closed systems - SCADA and controllers designed for control, not for data export,
- uptime comes first - you cannot risk a stoppage for a data experiment,
- knowledge in people’s heads - the process context often lives only with the automation engineer at the machine.
That is why industrial data acquisition is not an IT project sitting “next to” the floor, but an effort that must respect the realities of maintenance and uptime.
Where does industrial data really come from: PLC, SCADA, sensors, IoT?
Before we collect anything, we map the sources, because they shape the rest of the architecture:
- PLC controllers - raw signals from machines, states, alarms, counters,
- SCADA systems - an aggregated view of the line and ready process variables,
- sensors and IoT - temperature, vibration, energy draw, often outside the controller,
- higher-level systems - MES, ERP and process historians as business context.
In practice, the most value comes from joining the PLC/SCADA layer with IoT data, because only together do they describe what is happening on the machine and why.
What do acquisition and normalisation of production data look like?
Collecting the data is only half the job. The other half is bringing it into one, understandable language:
- acquisition through gateways and connectors (e.g. OPC UA, MQTT) without touching control,
- normalisation of units, signal names and timestamps into a shared model,
- context - linking a signal to a machine, shift, product and work order,
- data quality - spotting gaps, bad readings and dead tags.
Without this step a dashboard will show numbers, but no one will trust them. A clean data model is the foundation everything else rests on.
Where do you store and process data: edge or cloud?
This is not an either/or choice but a split of roles between two layers:
- edge, close to the machine - buffering, pre-aggregation and near-real-time reaction,
- cloud or a central data centre - history storage, heavy processing and fleet analytics,
- data pipeline - streaming and batch, from an event to an analytical table,
- storage layer - time-series databases and a warehouse for reporting.
We match this split to the plant’s realities: network bandwidth, security requirements and how fast a reaction is actually needed.
How do you get from data to decisions: dashboards and production KPIs?
Data only makes sense when someone looks at it daily and changes something because of it:
- production KPIs - OEE, availability, performance, quality, micro-stops,
- dashboards per role - one view for the operator, another for the production manager,
- alerts and thresholds - a signal before the problem grows, not after the fact,
- root-cause analysis - the ability to drill from a metric down to a specific machine and shift.
We make sure the metrics are readable and calculated the same way across the whole plant, because only then do they become the basis for a conversation rather than an argument about numbers.
Which skills do we provide for an industrial data project?
We shape the team around the specific stage and the plant’s specifics, not “just in case”:
- OT engineers / automation specialists - PLC and SCADA integration, industrial protocols,
- data engineers - pipelines, normalisation, time-series databases,
- backend and DevOps - APIs, containerisation, cloud or on-premise deployments,
- analysts and BI specialists - KPI models, dashboards, reporting.
This setup lets us close the path from the controller to the dashboard without stitching the project together from several independent vendors.
When is it worth adding an AI layer to industrial data?
AI only makes sense on clean data, so we treat it as an optional step, not the starting point:
- failure prediction from vibration, temperature and operating history,
- anomaly detection in process parameters that thresholds miss,
- optimisation of setpoints and energy consumption,
- assistants over your data (RAG/LLM) that ease access to machine knowledge.
Our AI and Data competence is real - within the RITS Group we have delivered GenAI, RAG and LLM projects. But here we are talking about competence we bring to the project, not a finished deployment in a specific factory.
What are the most common pitfalls in production-data projects?
Most problems are not technological; they come from skipping the realities of the floor:
- starting from a tool, not a question - a platform with no clear “what for”,
- ignoring data quality - pretty charts on shaky numbers,
- leaving OT out - a project run “from IT” without automation and maintenance people,
- missing context - signals with no link to a product, shift and work order,
- security last - network segmentation bolted on after the fact.
That is why we start from one concrete business question and work back to the data, not the other way around.
How fast can our team join a project like this?
Speed matters, because every delay is more weeks of decisions made on gut feeling. Our recruitment usually closes in about three weeks, stretching to two months only for non-standard requirements. As a nearshore partner from Poland we work in a close time zone, so specialists join your working rhythm, reviews and meetings without a long ramp-up, and we verify skills before the start.
How do we do it at RITS?
We do it as a nearshore partner from Poland, with experience in industrial and Industry 4.0 projects (automation, embedded, integrations):
- we provide OT/IT and data engineering skills in one coherent team,
- we work through team augmentation or a dedicated team, under your management or with our lead,
- we join acquisition, normalisation and use of data into one maintainable whole,
- we add an optional AI/Data layer where the data is already clean.
We do not promise a box off the shelf - we provide the people and the skills who plug into your processes and your maintenance realities. We covered the differences between engagement models in our article on IT engagement models.
Where do you start collecting and using industrial data?
Start from one question you cannot answer well today (e.g. “where are we really losing OEE?”) and from a single line or machine as a pilot. That will define which sources to connect, how to normalise them and which KPI to show on the first dashboard. A small, working data flow convinces better than a big platform on slides.
Want to collect and use industrial data from PLC/SCADA and IoT? Let’s talk - we’ll match a team and an architecture to your plant.