iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Industrial IoT sensors do not usually send useful production information straight to an MES or cloud application on their own. A sensor measures a physical condition; a PLC or device exposes the reading; and plant integration software or an edge gateway can translate, filter, and add context before applications such as MES, historians, and analytics use it. The exact arrangement varies by factory, equipment, and control requirements.
From physical condition to machine reading
A sensor first measures a property of a machine, product, or process. Examples include temperature, humidity, and location. Sensors may be mounted on equipment or observe it from a distance. The raw measurement is only a value; to be useful, the system also needs to know what asset or process it describes and, often, when and where it was measured.
In many installations, sensors connect to a device or programmable logic controller (PLC). The PLC can represent or control physical equipment and expose information using industrial protocols. Existing plants may use protocols such as Modbus/TCP, S7, ProfiBUS, or ProfiNET, as IBM outlines in its industrial IoT architecture.
How plant data reaches an IoT platform
Gateways bridge equipment and software
An industrial IoT edge gateway can connect devices, sensor gateways, and supervisory control and data acquisition (SCADA) systems to an IoT platform. At the plant, it may adapt legacy protocols to a format or interface used farther upstream, such as OPC UA or MQTT. It can also format readings, filter noise or irrelevant events, and aggregate values before forwarding them. The gateway is an integration layer, not a replacement for the sensor or PLC.
#1 Best Overall
A plant service bus can further route and transform information between systems, reducing the need for many separate point-to-point connections. IBM describes this kind of service bus as complementary to a manufacturing execution system (MES): it helps move and adapt information, while the MES handles production operations.
OPC UA and MQTT have different roles
OPC UA is an industrial information-exchange framework intended to work across sensors and actuators, controllers, MES, enterprise resource planning (ERP), and IIoT systems. Its specification covers information, messaging, communication, and conformance models, supporting exchange from device-level communication through enterprise and cloud integration. See the OPC Foundation’s OPC UA overview. As the foundation puts it, “The OPC UA information modeling framework turns data into information.”
MQTT is often used in a publish/subscribe design. Field devices publish values to a broker, and subscribed applications receive them. The broker can run on-premises, in the cloud, or in a hybrid arrangement. This is one common integration pattern, not a requirement for every factory; Inductive Automation explains the pattern in its MQTT overview.
Recommended Free Tools
What manufacturing applications do with the readings
Once readings are delivered and associated with production context, applications can present or analyze them in different ways:
- MES: Relates equipment signals to work orders, production steps, and execution records.
- Historian: Stores time-series process data so teams can review operating history and trends.
- Dashboards and monitoring: Show current conditions, equipment status, or production indicators.
- Analytics: Supports use cases such as overall equipment effectiveness (OEE) analysis, forecasting, anomaly detection, and predictive maintenance.
Microsoft’s manufacturing IoT reference architecture documents these as supported scenarios. They are possible uses for the data, not guaranteed outcomes: the readings must be reliable, sufficiently contextualized, and connected to an application that can interpret them.
An example of edge-to-MES integration
One Siemens architecture illustrates how equipment can connect through industrial connectors, with edge applications streaming events and performance data toward MES. An OPC UA gateway can also bind live PLC values to work-order operations. This is an example of a possible design, not a universal product requirement; see Siemens’ Industrial Edge information.
Rank #4
- NOTE: Compatible Only with FALA IOT monitors and Y-splitters, exclusive FALA IOT ecosystem integration
- Length: 16.4 feet ( 5 meters), flat cable type. Custom lengths and special features available
- Ultra-wide Monitoring Range: The digital temperature probes & sensors measures extreme temps from -40°F to 248°F with lab-accurate ±0.6°F precision
- Anti-slip Design: Stays securely in place for uninterrupted monitoring. It'll work well through vibrations, handling, and harsh work environments
- High Quality: The premium stainless steel probe is waterproof & rust-proof for reliable performance in farming, cold chain, refrigerator, labs, drying box, constant box and industrial use, etc.
Why a cloud connection does not automatically make data actionable
Sending telemetry to a cloud platform can make it available for remote monitoring or analytics, but it does not by itself identify the relevant equipment, production step, units, or operating state. Those relationships depend on sound information models and naming, integration logic, and production context. Without them, a stream of values can remain difficult to interpret even when it arrives successfully.
Cloud analytics should also be distinguished from machine control. Microsoft’s reference solution includes an illustrative feedback loop, but says that a critical action such as opening a pressure-relief valve would be performed on-premises in a real deployment. A cloud analysis path should not be treated as a safety-control design. See Microsoft’s security discussion for the reference architecture.
Best Value
Architecture decisions to settle before connecting sensors
Factories do not all use the same topology. When assessing an integration, consider these questions:
- Compatibility: Can the design communicate with the installed sensors, PLCs, SCADA systems, and legacy protocols?
- Data preparation: Where will values be normalized, contextualized, filtered, or aggregated—at the device, gateway, plant service bus, or application?
- Outages and locality: Which processing must continue on-site if a cloud or network connection is unavailable, and what data can wait to be forwarded?
- Information quality: Are equipment names, units, timestamps, and relationships to process steps consistent enough for MES and analytics to interpret?
- Security boundaries: How are endpoints trusted, transport protected, access authorized, and network zones separated?
- Monitoring or control: Is the data path read-only, or can it participate in commands that affect equipment? Control paths need carefully defined local behavior and safeguards.
Security is part of the data path
Connections between devices, gateways, brokers, and applications need explicit trust and access controls. OPC Foundation identifies mechanisms such as encryption, message signing, certificate-based authentication, access rights, and auditing in its OPC UA security overview. Microsoft’s reference architecture also documents certificate trust for OPC UA and TLS-protected transport. The appropriate configuration depends on the deployment, but security cannot be assumed merely because an industrial protocol or cloud service is in use.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
