2,000 Machines, 20 Billion Data Points: Where IIoT Architecture Gets Difficult

Industrial IoT becomes a different engineering problem when connected equipment reaches factory scale. Hyundai Motor India’s Chennai Manufacturing Plant near Sriperumbudur connects seven shops and more than 2,000 critical machines through more than 1,000 intelligent sensors, generating 20 billion data points a year. At that volume, the architectural questions are no longer about connectivity.

Hyundai Motor India offers a documented example at its Chennai Manufacturing Plant near Sriperumbudur: its dedicated network connects seven shops and more than 2,000 critical machines through more than 1,000 intelligent sensors. The company’s Draft Red Herring Prospectus dated June 14, 2024 states that the network generates 20 billion data points annually and enables real-time monitoring of more than 300 process parameters through 150 dashboards. Hyundai’s FY2024–25 Annual Report later reported that the IIoT network covered more than 86% of critical machinery across seven major shops, generated more than 20 billion data points annually, and analysed datasets in real time across 200 smart dashboards. Those figures describe what Hyundai has disclosed. They do not reveal its complete network, processing, or storage architecture. But they are large enough to raise the engineering questions any factory-scale IIoT deployment must answer: where should data be processed, how should readings retain context, what should be transported and stored, and how quickly does information need to reach an operator or system?

What Makes Data Scale an Architectural Problem?

Twenty billion annual data points is not only a throughput figure. It changes the work that has to happen after a machine produces a reading. A plant connecting thousands of assets may receive temperature, pressure, current, vibration, cycle, quality, and status information at different sampling rates and from different equipment types. Simply placing those values in a central system does not make them comparable or useful. The first architectural questions therefore become practical ones:

• Data ingress: How are readings collected from different machines and systems?
• Normalisation: Can applications interpret values consistently across equipment?
• Processing: Which information should be evaluated locally and which can travel upstream?
• Retention: Does every reading need to remain at full resolution for the same period?

Hyundai’s seven-shop, 2,000-plus-machine scale makes each question more consequential. A design that works for one machine or one production cell may become inefficient when applied across most of a plant.

How Does a Sensor Reading Become Contextualised Data?

A sensor reading is not the same thing as information. Consider a temperature value: 87 °C. The number alone says little about whether it indicates a fault. The system also needs to know which asset produced it, which subsystem the sensor belongs to, when the measurement was taken, what the machine was doing, and what operating conditions were present. At factory scale, useful context can include:

• Asset and sensor identity
• Timestamp and data quality
• Engineering unit and measurement range
• Machine state and operating mode
• Production line and process step
• Equipment hierarchy
• Product, batch or work-order context

That hierarchy matters when data spans several shops. A temperature signal can mean something different depending on whether it belongs to a motor, hydraulic system, spindle or another subsystem. The same parameter may also need to be interpreted differently during startup, normal production, or a maintenance state. This is where information modelling becomes important. The OPC UA specification, the industrial interoperability standard maintained by the OPC Foundation, describes an AddressSpace in which objects, variables, and their relationships can represent structure and semantics rather than exposing disconnected values. Its information-modelling capabilities allow real objects to be related through references, typed objects, and industry-specific data definitions. For a deployment spanning thousands of machines, the architectural benefit is straightforward: downstream systems can work with an asset and its relationships rather than reconstructing those relationships from raw tags every time.

OPC UA or MQTT? The Choice Depends on the Layer

OPC UA and MQTT are often compared as if an industrial architecture must select one. That misses the distinction between their roles.

• OPC UA: Focuses on industrial information exchange, interoperability, structured models, and semantics. The standard includes an AddressSpace model, typed objects, services, events, and multiple communication approaches.
• MQTT: Provides lightweight publish/subscribe messaging. A publisher sends application messages to a server, which distributes them to clients with matching subscriptions. MQTT 5.0 also defines three Quality of Service levels: at most once, at least once, and exactly once.

That makes the architectural question less about which protocol is “better” and more about where each mechanism fits. A machine-facing layer may benefit from structured industrial data and semantic relationships. A downstream messaging layer may benefit from publish/subscribe decoupling, where producers do not need direct knowledge of every consuming application. A gateway can therefore act as a boundary: Machine systems → industrial protocol/data model → gateway → selected telemetry/events → messaging infrastructure → applications That does not mean every factory will use this exact pattern. Hyundai’s public documents do not disclose which protocols underpin its Chennai IIoT network. The point is that at 2,000-plus-machine scale, protocol selection is an architectural decision rather than a plant-wide one-protocol contest.

What Stays at the Edge and What Moves Upstream?

The edge/cloud question becomes more important when data volume grows faster than the value of transporting every raw reading. The basic principle is not “edge is better than cloud.” It is to place processing where latency, bandwidth, resilience, and compute requirements make the most sense. At the edge: validation, filtering, aggregation, buffering, and time-sensitive event detection can often happen close to the machine. Upstream: cross-line correlation, long-term historical analysis, model development, enterprise reporting, and broader analytics can use centralised infrastructure. Consider high-frequency vibration data. Sending every raw waveform continuously upstream may create a much larger transport and storage burden than sending selected features for routine monitoring. An edge workload could derive features such as RMS, peak values, or frequency-band indicators. Routine features could move upstream continuously, while raw waveform segments could be retained selectively when an anomaly or investigation requires them. NIST’s Fog Computing Conceptual Model identifies large-scale, heterogeneous IoT environments and latency as reasons to decentralise applications and analytics into the network rather than relying exclusively on centralised cloud processing. NIST research on edge-based deep learning in IIoT likewise describes how moving computation closer to the data source can reduce data-transmission requirements. The relevance extends beyond one plant. MarkNtel Advisors’ Industrial Internet of Things market research identifies manufacturing as the leading end-user segment and highlights rapid adoption of edge computing as an opportunity because industrial environments generate large volumes of real-time data. The Hyundai example provides a concrete illustration of why that architectural issue exists in the first place.

How Do You Handle Billions of Time-Series Records?

Once telemetry reaches billions of observations, storage policy becomes part of the architecture. The mistake would be to assume that every reading should remain at the same resolution forever. A practical data lifecycle can separate information by value and access pattern:

• Hot data: recent measurements that operators and applications query frequently.
• Aggregated data: lower-resolution summaries retained for longer-term trends.
• Event data: abnormal conditions and their surrounding context preserved for investigation.
• Raw data: high-resolution measurements retained where diagnostic or regulatory value justifies the storage cost.

Suppose a vibration sensor produces high-frequency readings throughout a production shift. An architecture could retain calculated features continuously while storing the raw signal around significant events for deeper analysis. The same principle applies to other telemetry. Routine values can support operating trends without requiring every raw observation to remain immediately accessible indefinitely. This is also where contextualisation affects storage. A time-series query is rarely just “give me all temperatures.” The useful query is closer to: “Show temperature behaviour for this machine, this subsystem, during this production interval, together with related events.” The more consistently that asset and process context is attached before storage, the easier those queries become across a plant-wide dataset.

Why Does “Real Time” Depend on the Decision?

Real time is not one universal latency requirement. A machine-control loop, an operator dashboard, and a historical production report may all use the same underlying telemetry while requiring very different response times.

• Machine control: timing and predictability can be critical because the output directly affects physical operation.
• Condition monitoring: a delayed response may still be useful if the goal is detecting a developing equipment condition.
• Operator dashboards: freshness matters, but the requirement is different from a closed control loop.
• Historical analytics: seconds or minutes of delay may be irrelevant when the objective is trend analysis.

NIST’s work on factory automation specifically highlights the need to match communication requirements to sensing, robot, and machine-control applications and notes the importance of high reliability, low latency, and scalability in industrial environments. Hyundai’s annual report also describes AI vision systems for real-time defect detection in its Powertrain operations. That is a useful reminder that even within one factory, “real time” can describe different workloads with different architectural requirements. A better engineering question is therefore: What decision must happen, and how quickly must the information arrive for that decision to remain useful?

How Does Telemetry Become an Actionable Event?

The path from measurement to action is where an IIoT architecture proves its value. Take the earlier 87 °C temperature reading.

1. Validate: Is the measurement plausible? Is the sensor healthy? Is the timestamp valid?
2. Contextualise: Which machine and subsystem produced it? What operating mode was active?
3. Compare: Is 87 °C outside the expected range for that machine state?
4. Correlate: Did pressure, vibration, current draw, or cycle time change at the same time?
5. Classify: Is the reading a normal transient, a process deviation, or a possible equipment condition?
6. Prioritise: Should it remain informational, trigger a warning, or require urgent attention?
7. Act: Should the system update a dashboard, notify an operator, create a maintenance workflow, or trigger another defined response?

This distinction matters because more telemetry does not automatically produce better decisions. An architecture that forwards every reading but cannot establish context may simply move a data-management problem from the shop floor into a dashboard or data lake. The useful output is not the raw value. It is the contextualised event that tells another system or person what changed, why it matters, and what should happen next.

How Do the Layers Fit Together?

A factory-scale IIoT architecture can therefore be viewed as a sequence of responsibilities:

• Machines & sensors: generate measurements and equipment states.
• Industrial protocols/gateways: provide access across heterogeneous equipment and systems.
• Edge processing: validate, filter, aggregate, buffer, and identify time-sensitive conditions.
• Data transport: distribute selected telemetry and events between producers and consumers.
• Contextualisation/event processing: attach asset and process meaning and identify operationally relevant conditions.
• Storage: retain data at an appropriate resolution and for an appropriate period.
• Analytics: combine current and historical information to identify patterns and relationships.
• Dashboards/operational systems: deliver results to operators, engineers, and downstream workflows.

For a plant with thousands of connected machines, these are not merely software boxes. They define where meaning is added, where data is reduced, where resilience is maintained, and where decisions are made.

Conclusion

Hyundai Motor India’s public disclosures make the scale problem unusually concrete: more than 2,000 critical machines across seven shops, more than 20 billion annual data points, and a later reported coverage level of more than 86% of critical machinery. The engineering challenge at that scale is not simply collecting more telemetry. It is preserving meaning across thousands of assets, choosing the right communication mechanism for each layer, deciding what should happen at the edge, determining what data deserves long-term retention, and matching latency to the decision being supported. That is what factory-scale IIoT architecture has to solve.

- Advertisement -