Unit 3 - Real-Time Monitoring & Visualizing
Unit 3 - Real-Time Monitoring & Visualizing
https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequenc… 1/15
1/14/25, 10:52 AM Real-Time Monitoring and Visualizing
Real-Time Monitoring
You may have heard the phrase, Data is the new gold – and it’s true! Data allows businesses to make
better decisions backed by information from the real world. With the interconnectivity brought about by
Industry 4.0, big data analytics such as machine learning becomes possible on an even larger scale.
Data allows us to identify areas for optimisation in businesses, utilise resources better, and to impose tighter
quality controls through extensive and widespread real-time monitoring. On the other hand, businesses
may also use data to drive core development decisions, such as whether to expand or diversify.
Real-time monitoring has helped many businesses tackle age-old problems such as dealing with downtime,
increasing equipment efficiency, and logistics management. This is due to its ability to provide business
insights and actionable intelligence concerning manufacturing operations.
Digital transformation has been underway on the factory floor for a long time. With Industry 4.0 and the
associated networking of all systems that are involved in the production process, the importance of standards
to ensure cross-system data exchange and efficient machine-to-machine communication is increasing
rapidly.
When it comes to the exchange of data between Operational Technology (OT - hardware and software
that monitors and controls physical devices) and Information Technology (IT - systems handling the flow
of information/data between applications) even within a single enterprise - require a new approach to IT
networking, but we also need to find creative ways to integrate them with existing machinery and workflows.
For example, traditional temperature controls linked to OT systems would typically report readings by way of
a closed-loop readout, enabling employees “on the floor” to see whether adjustments were necessary on
their end. With IIoT technology, however, those temperature sensors can be connected to IT networks,
allowing them to communicate in real-time with other assets across facilities in order to optimize temperature
levels automatically for maximum performance. AI and machine learning, of course, have a role to play here
as well.
That’s why industrial communication protocols have become such a key part of the conversation. Whether it’s
for machine-to-machine (M2M) communication for real-time control (RTC), pushing data up from an IoT
gateway to the cloud, or just displaying data on a human-machine interface (HMI) for an operator to monitor
it, we all need to transfer data in ways that are scalable, reliable, and secure.
https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequenc… 2/15
1/14/25, 10:52 AM Real-Time Monitoring and Visualizing
While there’s plenty of options to choose from, two of the most dominant ones are OPC UA (Open Platform
Communications Unified Architecture) and MQTT (Message Queuing Telemetry Transport). Both
of these protocols share certain similarities, such as built-in cybersecurity and their reliance on other
networking technologies like TCP. Each bring their own advantages, and each is better suited for different
use cases.
https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequenc… 3/15
1/14/25, 10:52 AM Real-Time Monitoring and Visualizing
Introduction to OPC UA
OPC Unified Architecture (OPC UA) is a connectivity framework standard in the manufacturing environment
that was published in 2008 as the successor to the OPC (Object Linking and Embedding for Process Control)
standard. The unified architecture that OPC UA introduces is designed for platform independence.
One of the goals of OPC UA is to achieve device interoperability that is independent of the proprietary APIs of
device manufacturers.
The OPC UA protocol is one of the most important communication protocols in the manufacturing industry.
Typical use cases include industrial automation and process control applications as well as client-server
interactions between components such as devices or applications. To facilitate configuration, browsing,
monitoring, and data access, the address space of servers and devices is exposed to allow queries to all
objects that are located in the space. OPC UA also supports a semantic description of data. The requests of
the OPC UA client are sent to an OPC server. The OPC server processes the request and sends a response
back to the respective OPC UA client. Structured data is used for this request-response communication
pattern.
OPC UA is based on client/server architecture and uses TCP/IP and HTTP/SOAP as underlying
technologies.
https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequenc… 4/15
1/14/25, 10:52 AM Real-Time Monitoring and Visualizing
0:00 / 10:01
https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequenc… 5/15
1/14/25, 10:52 AM Real-Time Monitoring and Visualizing
The OPC UA server converts the hardware communication protocol so that the device data via a
standardized device model.
Security is implemented through various methods such as PKI certificates, WebSocket tokens, TLS, and
username/password authentication for device clients.
Error management and exception handling are supported and communicated via different events and alarms.
OPC UA services include limited support for message delivery guarantees (QoS); however, QoS functionality
is not present as an underlying concept.
OPC UA defines a complete data type system. Resources in OPC UA are referred to as nodes. The different
nodes that make up a system are individually addressable and can be structured as data objects from
structured data types of varying complexity.
Additionally, OPC UA discovery services are available to dynamically detect new components in the
infrastructure setup.
Generic device models play a central role in OPC UA architecture. Device manufacturers are responsible for
providing the server that maps a generic device model to the specific device. The OPC UA standard is
composed of numerous individual specifications. Each specification describes a sub-function and specifies
which interfaces the servers and clients must implement to support a particular function. Since it is not
necessary to implement all of the individual specifications, the client-server system that is running OPC UA
must identify which specifications the client and server need.
Companion specifications from various industries for the devices and systems involved can help identify
which specifications are necessary. The companion specifications supply predefined structures that are
created for the respective industry-specific applications and the associated objects.
Communication to other services can be established with gateway implementations for networking
middleware (DDS) and direct machine to machine communication (M2M) applications, or through an HTTP
gateway.
Servers provide an object-oriented remotely-callable API that implements the device model. The device can
be accessed via a standard device model. There are device models for dozens of device types, from sensors
to feedback controllers.
https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequenc… 6/15
1/14/25, 10:52 AM Real-Time Monitoring and Visualizing
For example, the object model of a particular sensor can provide methods for setting parameters, reading
data, and operating the device. The methods allow applications to directly control the sensor without knowing
the exact implementation of the respective manufacturer. One or more servers in the system wait for any
number of clients to send requests. When a server receives a request, it responds and then returns to a
waiting state.
If desired, the client can instruct the server to send updates as they arrive on the server.
https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequenc… 7/15
1/14/25, 10:52 AM Real-Time Monitoring and Visualizing
In OPC UA, the client decides when and which data the server retrieves from the underlying systems. For
example, even if the server subscribes to periodic status updates, it is up to the client to determine how often
the server polls the devices and systems.
The capabilities of OPC UA, such as browsing or reading meta information and the flexible organization of
variables in monitoring lists, make it easier to view and monitor machines externally.
However, when numerous heterogeneous applications and devices from different manufacturers are
connected, the challenges of implementing OPC UA architecture increase. With more than 1,200 pages, the
sheer length of the OPC UA specification foreshadows how extensive a complete implementation might
become. Full implementations are not only expensive in terms of development and support costs, but also in
the significantly higher CPU requirements OPC UA places on the devices.
The implementation of multiple consumers that one-to-many constellations and highly flexible publish-
subscribe architecture necessitate are problematic. Due to the underlying architecture, real data decoupling
cannot be achieved. The connection to cloud-based applications can also prove to be complicated or require
a high implementation effort.
Client-server architecture
Platform independence and interoperability through the use of TCP / HTTP as the transport protocol
Security with TLS and certificates
Fully defined data type setup
Fixed structure data objects and endpoints
Library of predefined industry-specific specifications
Discovery service available
Gateway compatibility
https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequenc… 8/15
1/14/25, 10:52 AM Real-Time Monitoring and Visualizing
https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequenc… 9/15
1/14/25, 10:52 AM Real-Time Monitoring and Visualizing
Introduction to MQTT
If you want to bypass complexity and move to a lean solution that guarantees a secure and reliable data
exchange in industrial automation, you invariably encounter the MQTT protocol. MQTT celebrated its 20th
anniversary in 2019. As an OASIS standard, the MQTT 5 protocol offers a specification that is generally
acknowledged as the de facto standard for IoT.
The core principle of the exceptionally lightweight MQTT protocol is the publish-subscribe pattern. This
pattern allows any number of data consumers to subscribe to individual topics or subject areas and receive
the messages published about them
The slimness of MQTT is particularly suitable for very low-resource devices and communication in low-
bandwidth, unreliable, or high-latency networks.
0:00 / 7:18
https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequen… 10/15
1/14/25, 10:52 AM Real-Time Monitoring and Visualizing
MQTT architecture enables communication with an unlimited number of clients via the publish-subscribe
protocol.
Since many detailed descriptions of the MQTT specification such as the MQTT 5 Essentials series are
available, this paper focuses only on aspects of MQTT that are interesting in comparison with OPC UA.
Lightweight, TCP-based Publish/subscribe architecture Secure Stateful session usage Data-agnostic Highly
dynamic topics Delivery guarantees for messages Last Will and retained messages concept MQTT 5
features Introduction of semantic metadata like user properties, payload indicators, or content type
descriptors Request-response pattern Shared subscriptions Negative acknowledgments Message and
session expiry per client And more MQTT architecture enables communication with an unlimited number of
clients via the publish-subscribe protocol.
All messages are sent via a central MQTT broker and all MQTT clients connect to the broker and can
subscribe to specific topics.
The MQTT broker takes over the task of the server and handles each communication with an unlimited
number of MQTT clients.
MQTT clients are implemented directly on gateways, devices, or within applications, and all of the clients are
loosely coupled. There are no direct relationships between the clients. In addition to functional requirements,
the MQTT broker handles needs such as redundancy, failover, high availability, and scalability within a given
infrastructure.
https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequen… 11/15
1/14/25, 10:52 AM Real-Time Monitoring and Visualizing
The central component of MQTT is always an MQTT broker. It is the responsibility of the broker to fully
implement the MQTT specification. Particularly concerning MQTT 5 features, the compliance levels of
brokers vary. Since many features in the MQTT 5 specification are optional, some brokers do not implement
all of the features MQTT 5 offers. The different levels of support are especially relevant in the cloud area.
The use of sessions allows data for MQTT clients to be persisted beyond the duration of the client
connection. For example, subscriptions, offline messages, or additional information stored for an offline client
at the broker remain immediately available to the client when it reconnects.
Another essential difference in the context presented here is in the area of data agnostics. The MQTT
protocol does not impose restrictions regarding data types on the specification level. As a result, the MQTT
protocol can be used to transmit widely diverse types of data.
This complete freedom also applies to the topics. Beyond syntactic requirements, MQTT topics are not
subject to any specifications. Topics are dynamic and do not have to be specified or created beforehand. The
topic only exists in the context of an MQTT client that subscribes to the topic to consume incoming
messages. If a message is published on a topic to which no MQTT client subscribes, the broker will ultimately
discard the message.
To guarantee the complete transmission of messages with a stable connection, MQTT uses TCP as the
transport protocol. Since MQTT was designed mainly for unstable networks, three quality of service levels
(QoS), QoS 0, 1, and 2, are specified. This concept of delivery guarantees for MQTT messages is another
significant difference from OPC UA.
The retained messages principle in MQTT is also very useful for production environments. This feature allows
a specific message to be stored on each topic. The retained message ensures that every client that
subscribes to the topic can immediately receive the saved message.
The same relevance applies to the MQTT last will concept that specifies a message during client connection
to send when an offline event occurs. A typical use case for last will messages is the transmission of status
information from a client.
MQTT 5 also introduces user properties that make it possible to freely transfer meta information in MQTT
packets without using the payload. User properties provide a simple and effective variant for exchanging
meta information.
In contrast to OPC UA, the succinct 80 page MQTT specification is easy to implement and does not define
fixed structures or data types.
https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequen… 12/15
1/14/25, 10:52 AM Real-Time Monitoring and Visualizing
The main use case of OPC UA is for closed loop process control on a local area network (LAN). If we need to
get our machinery on the plant floor to talk to each other in real-time, OPC UA is the first place to look. A
corollary is that this protocol is better suited for integrating with a supervisory control and data acquisition
(SCADA) system. Not only does OPC UA have a proven track record for SCADA use cases, but it’s features
and architecture are strong reasons to prefer it for SCADA.
Another good reason to use OPC UA is if we need to integrate legacy equipment. Industrial equipment tends
to have a longer lifespan than most IT devices, and, as a industrial-first communication protocol, OPC UA is
designed with this fact in mind.
Our final use case for OPC UA comes from research by Profanter et al. They found that, at least compared to
MQTT, OPC UA functions much better for quick response time, which makes it very well suited for high speed
motion and sensing applications. If your application requires serious compute power or you don’t have many
cycles to spare, OPC UA is the way to go.
On the other hand, the primary use case for MQTT is IIoT applications. If you’re collecting data from remote
locations and sending that data over an unreliable network like cellular, we recommend MQTT. Along these
same lines, because of MQTT’s built in QOS feature a message can be guaranteed to be received by the
end source because MQTT can keep attempting to post a message whereas in a base implementation of
OPC UA, the message would be lost. A great example for using MQTT is for IoT gateways that collect sensor
data and push it up to the cloud for data analysis and an overall view of a manufacturing line’s performance.
The Profanter research also found that MQTT functions better on heavily trafficked networks than OPC UA
does. So, if you’re sending tons of data over the wire and pushing your network capacity to the maximum,
MQTT will offer better performance.
https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequen… 13/15
1/14/25, 10:52 AM Real-Time Monitoring and Visualizing
Data Visualizing
Real-time Monitoring primarily helps in monitoring and managing the consumption and use of data across a
complex IT system or on a standalone software/database. Typically, an Real-time Monitoring software/system
provides data administrators with visual insights into the data, which is fetched from various sources including
Web server logs, network logs, database logs and application usage statistics. It can also provide instant
notifications/alerts into specific data-driven, administrator-specified events, such as when a data value goes
out of range.
Generally, real-time monitoring software displays relevant data on customizable dashboards. Administrators
can choose to display expected data ranges and formats as numerical line graphs, bar graphs, pie charts or
percentages.
https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequen… 14/15
1/14/25, 10:52 AM Real-Time Monitoring and Visualizing
https://www.techopedia.com/definition/12274/real-time-data-monitoring-rtdm
(https://www.techopedia.com/definition/12274/real-time-data-monitoring-rtdm)
https://solace.com/blog/industry-4-0-iiot-data-opc-ua/ (https://solace.com/blog/industry-4-0-iiot-data-opc-ua/)
https://www.outlierautomation.com/blog/202020/12/16/whats-the-difference-between-opc-ua-and-mqtt
(https://www.outlierautomation.com/blog/202020/12/16/whats-the-difference-between-opc-ua-and-mqtt)
https://opcconnect.opcfoundation.org/2019/09/opc-ua-mqtt-a-popular-combination-for-iot-expansion/
(https://opcconnect.opcfoundation.org/2019/09/opc-ua-mqtt-a-popular-combination-for-iot-expansion/)
https://www.spotlightmetal.com/iot-basics-what-is-opc-ua-a-842878/ (https://www.spotlightmetal.com/iot-
basics-what-is-opc-ua-a-842878/)
https://www.hivemq.com/iiot-protocols-opc-ua-mqtt-sparkplug-comparison/ (https://www.hivemq.com/iiot-
protocols-opc-ua-mqtt-sparkplug-comparison/)
https://www.muutech.com/en/comparison-mqtt-vs-opc-ua/ (https://www.muutech.com/en/comparison-mqtt-vs-
opc-ua/)
https://opcconnect.opcfoundation.org/2017/10/should-i-use-opc-ua-mqtt-amqp/
(https://opcconnect.opcfoundation.org/2017/10/should-i-use-opc-ua-mqtt-amqp/)
https://splms.polite.edu.sg/d2l/le/enhancedSequenceViewer/545684?url=https%3A%2F%2Fb988e89b-eb2c-401a-999a-94b943da0008.sequen… 15/15