Getting Condition Data From the Shop Floor to Your Software
Enable continuous monitoring of your machines and production lines
Reading Time: minutes
IIoT (Industrial Internet of Things) is becoming more mainstream, leading to more vendors implementing innovative monitoring capabilities in the new generation of sensors. These sensors are now multifunctional and provide additional features such as self-monitoring.
With these intelligent sensors, it is possible to set up a system that enables continuous monitoring of the machines and production line. However, the essential requirement to use the provided data for analysis and condition monitoring for preventative and predictive maintenance is to get it from the shop floor to the MES, ERP, or other analysis software suites.
There are a variety of ways this can be done. This post will look at a few popular ways and methods to do so.
The most popular and straightforward implementation is using a REST API (also known as RESTful API). This has been the de facto standard in the consumer space for transporting data. It transfers multiple data formats, including multimedia and JSON (Javascript Object Notation).
This has certain disadvantages like actively polling for the data, making it unsuitable for a spotty network, and having high packet loss.
MQTT (Message Queuing Telemetry Transport) eliminates the above problem. It's very low bandwidth and works excellently on unreliable networks as it works on a publish/subscribe model. This allows the receiver to passively listen for the data from the broker. The broker only notifies when there is a change, and can be configured to have a Quality of Service (QoS) to resend data if one of them loses connection. This has been used in the IoT world for a long time, and has become a standard for data transport, so most software suites have this feature built-in.
The third option is to use OPCUA, which is the standard for M2M communication. OPCUA provides additional functionality over MQTT as it was developed with machine communication in mind. Notably, in-built encryption allows for secure and authenticated communication.
In summary, below is a comparison of these protocols.
REST API | MQTT | OPCUA | |
|---|---|---|---|
Complexity | Simplest to implement | Well documented and comparatively simple | Most complex of the three to implement |
Network flexibility | Requires a steady and reliable network | Suitable for unreliable networks | Requires a stable network |
Security | It can be configured to encrypt and authenticate requests | Has functionality to be encrypted and authenticated | Encryption and authentication are built in |
Cost | Initial development costs | Open source MQTT brokers are available | Requires OPCUA server implementation, and features can get expensive |
Vendor support | Varied but catching up | More prevalent than other options | Least likely, but catching up |
Multiple data consumers | Supports multiple data consumers but can be overwhelmed | Built to natively support multiple data consumers | Not ideal |
A more detailed explanation can be found for these standards :
REST API : https://www.redhat.com/en/topics/api/what-is-a-rest-api
MQTT : https://mqtt.org/
OPCUA : https://opcfoundation.org/about/opc-technologies/opc-ua/
Keywords
- Internet of Things
Author
Anjesh Shekhar
8 Contributions
Comment
Popular posts
Industrial sensing fundamentals – NPN vs PNP
What is a capacitive sensor?
How do I wire my 3-wire sensors?
The basic operating principle of an inductive proximity sensor
Contact form
Do you have any questions or suggestions? We are at your disposal.
Balluff Inc.
-
8125 Holton Dr.
Florence, KY 41042
