One sensor on a GE gas turbine engine generates roughly 500 gigabytes of data per day. At that rate, a single sensor produces about 15 terabytes a month. Injection molding machines on plastics lines can throw off multiple terabytes a day on their own.
That is big data in manufacturing at its most literal, and most of it never gets used. According to the Industry 4.0 newsletter, plants sample most of it down, average it out, or discard it, because they have no infrastructure to keep it and no reason to.
Many plants generate more sensor data than their networks and storage were built to hold. They keep only a fraction of what survives the sampling and averaging. The sections below cover why that happens, what makes data ready for artificial intelligence (AI), and where a capture layer fits.
Why Doesn’t Manufacturing Use Most of Its Sensor Data?
Three gaps explain it. The data has nowhere to live, no reason to stay, and no meaning attached when it arrives.
No Infrastructure to Hold It
Storage and network capacity in many plants were sized for production counts, work orders, and quality records. A turbine sensor or a molding press that produces terabytes per day exceeds that capacity quickly. Many machine controllers keep a short window of detail and then overwrite it.
Moving the full stream to a central system takes bandwidth, storage, and ongoing spend. That spend rarely appears in the budget for the machine itself. As a result, the cheapest option is to keep the live value on a local screen and let the rest go.
Mixed equipment vintages add another barrier. A press from two decades ago and a newer robotic cell rarely expose their data the same way, so even a plant that wants to keep everything has to solve each machine separately.
No Reason to Keep It
Data costs money to store, and a stored reading earns that money back only when someone uses it. Most big data in manufacturing has no named owner and no question assigned to it. Without a question, the cheapest decision is to keep less.
Plants therefore shrink the stream. Sampling keeps one reading out of many. Averaging replaces a run of readings with a single number. Deletion removes whatever the first two missed.
A molding press shows how this works in practice. It measures pressure and temperature throughout every cycle, and a common choice is to keep the cycle summary and drop the detail behind it. An hourly average also smooths over a brief excursion, which is often the event worth studying. Once the detail is gone, nobody can recover it.
No Meaning Attached to It
A raw reading is a number and a timestamp from a device. It says nothing about which asset produced it or where that asset sat at the time. A temperature spike on an unlabeled stream is a number. The same spike tied to a specific press in a specific zone is something a team can act on.
Models face the same limit. When someone asks a model about one line, readings that do not say which machine they came from add nothing to its answer. Plants that cannot label their data have little reason to store it, which feeds the first two gaps.
Labeling gets harder across systems. In many plants, the same press appears under one name in the maintenance system, another in the production schedule, and a third on the controller. Models cannot join records that disagree about which machine they describe.
Big Data in Manufacturing Has a Capture-and-Discard Problem
Manufacturing data collection in many plants follows one pattern. Engineers instrument a machine, and a screen shows the live value. Meanwhile, the plant trims, averages, or drops the history behind that value.
Big data in manufacturing costs real money to generate. The return stays small because the part that would feed analytics and AI is gone before anyone asks for it.
What Sampling and Averaging Cost
The cost shows up when a question arrives after the data is gone. A defect appears on a finished part, and the investigation needs the detail from the hours before it. A plant that averaged that period has a summary and no explanation.
AI models face the same constraint. A model can only learn from the history a plant kept, so a thin history produces thin answers. Teams cannot know in advance which questions will matter, which means they cannot know which discarded data would have answered them.
The gap also costs time. Teams that start an analytics or AI project after the fact often begin by collecting data again, because the history they need was never kept. That collection period delays the project before it produces its first answer.
Why More Sensors Do Not Fix It
Adding sensors makes big data in manufacturing bigger without adding a place to keep it. Each new device adds to the stream that the plant has to sample, average, or drop.
Our earlier post, Your Factory Doesn’t Need More Data. It Needs the Right Data., covers the opposite failure: teams that keep every reading with no plan for which signals matter. The two posts describe one gap from opposite ends. In both cases, the plant lacks a layer that captures the right signals and delivers them in a form other systems can use.
What Does “AI-Ready” Data Actually Require?
Manufacturing data analytics tools, from dashboards to large language models, depend on the same input. Big data in manufacturing helps them only when it is organized, labeled, and current. The models are here, and they work today. What limits them in a plant is the data they receive.
Structure, Meaning, and Timing
Readings from different machines and sensor types have to arrive in a consistent format, because a model can compare two machines only when their readings look alike. Each reading also has to carry its origin. When it ties to the specific asset and zone that produced it, a stream of numbers becomes evidence about a particular machine in a particular place.
Timing matters as much as either one. Data that lands the next morning answers yesterday’s questions, while a decision on the floor needs the reading as the machine runs. Our post on why live telemetry is the missing piece for AI covers that timing gap in more depth.
Questions the Data Has to Answer
A plain question tests whether data is AI-ready. Which machines sat idle during second shift? Where was this asset when the line stopped? Which tools passed through this zone today? Each question needs a history of machine utilization or location, and each answer fails if the plant averaged that history away or never tied it to an asset.
Once the data holds up under questions like these, a person at a dashboard and an AI agent can both use it.
Open Delivery to Any Model
AI-ready data also has to reach whatever system the plant uses. Thinaer delivers customer-owned data through open standards: MQTT (a lightweight messaging protocol for machine data), REST APIs (standard web interfaces for requesting data), and the Model Context Protocol (MCP), which AI agents use to reach data and tools. Any cloud and any model can consume it.
Dashboards, business intelligence (BI) tools, enterprise resource planning (ERP) systems, and digital twins can read the same stream. The customer owns the data throughout, so changing a model or a cloud provider does not mean rebuilding the data layer.
Where the Capture Layer Fits for Industrial IoT Data
Physical AI runs in three stages: Capture, Learn, and Act. Capture comes first and covers sensors, gateways, and structured data streams. Learn covers digital twins, simulation, and foundation models, which cloud and AI platform partners supply. Act covers operators deciding with sharper input and automation carrying out what they direct. Thinaer owns Capture. Without it, the other two stages have nothing to work on.
What Thinaer Captures
Industrial Internet of Things (IoT) data comes from many kinds of sensors, so Thinaer carries more than 40 sensor types across technologies that include Bluetooth Low Energy (BLE), radio-frequency identification (RFID), ultra-wideband (UWB), and GPS. The environment decides the mix. BLE places an asset within a room or zone, at 3 to 10 feet of accuracy. UWB delivers sub-foot precision where operations demand it. GPS covers the yard outside. Sensors report back over wired Ethernet, Wi-Fi, cellular, or private 5G, whichever the site supports.
Together, the sensors record the operational picture of the floor: where assets are, how they move, the conditions around them, and whether machines are running, idle, or off. That IoT sensor data goes into one platform, and from there it reaches any AI, analytics, or BI tool the plant already runs.
What Sonar Shows on Day One
Sonar, Thinaer’s operational visibility application, turns that capture into a live picture from the first day: real-time maps, geofencing, alerts, dashboards, and time-out tracking. In 2025, Thinaer deployments triggered more than 10 million events, including geofence breaches, time-out alerts, and environmental exceedances. Each one reached an operator the moment it happened. Each one also became part of the same structured dataset that feeds the plant’s AI and analytics tools. Sonar is Gartner recognized.
Operators get value immediately, and the dataset starts growing at the same time. Nothing waits for a model project to finish.
Environments Where Capture Was Never an Option
In some spaces, no one discarded the data because no one could capture it in the first place. Classified bays, ordnance areas, and radio-constrained shipyard spaces rule out most radios and most platforms. Thinaer holds a patent pending for sensor deployment in classified environments, and its deployments are approved by the Defense Information Systems Agency (DISA) and HERO ZERO certified for ordnance areas. The structured data from those spaces reaches the same tools as data from an open factory floor.
What Specialized Sensors Still Do
Thinaer does not capture high-frequency waveform data, such as the acoustic emission or vibration signatures that specialized sensors record on a turbine or a high-speed press. Those sensors do that job well, and they should keep doing it. The capture layer complements them by recording the operational picture around those machines. A model that reads both has more to work with than a model that reads either one alone.
Every New Sensor Adds to the Same Dataset
The first deployment pays back on its own. Sonar shows operators a live picture on day one, and the same data builds an AI-ready record from that day forward. Each later deployment adds to that record. A new building, a new line, or a new sensor type extends the same dataset, which gives every model more history and more coverage to learn from.
The platform stays the same when the technology changes, so value rises while complexity stays flat. A site that needs BLE in one area and UWB in another still sends everything through one platform and one set of APIs.
Consistent Data Across Sites
When each building feeds the same dataset, a question that works at one site works at the next. A team that asks where tools sit during a build can ask it again in another facility without redesigning anything. Big data in manufacturing becomes comparable across sites when every site shares the same structure.
The scale backs this up. Thinaer’s capture layer runs more than 150,000 sensors across 33 locations and more than 12 million square feet. A leading defense original equipment manufacturer (OEM) documented a multi-million-dollar return from the approach. Our post on how clean, contextualized data powers real AI covers what that looks like in practice.
Start With What the Floor Already Produces
Every plant already produces the signals. Machines run, assets move, and conditions change around the clock, and most plants sample down or discard much of it today. Big data in manufacturing starts paying back once a plant keeps it in a form models can use. A practical way to change that is to pick one line, one area, or one asset class and capture it properly from the first day. Four checks make a good first scope:
- Name one operational question the data should answer, such as where a specific tool sits during a build.
- Confirm the signals that answer it arrive at full detail rather than averaged.
- Confirm each reading ties to a specific asset and zone.
- Confirm the data can leave the plant over open standards, so any model can use it.
Operations teams get the live picture, and data and AI teams get the history they have been missing. Sonar shows the first results on day one, and the structured data stays ready for any model the team chooses. See how Sonar gives operations teams a live picture from day one.
The models are here. The data isn’t. We fix that.