InduSoft Web Studio and MQTT for Internet of Things Applications

MQTT in InduSoft Web Studio
February 2016

THANK YOU!
Together, we are stronger!
15+ years of innovation, collaboration, evolution, and
success!

Agenda
InduSoft (Andre Bastos)
– Introduction: the Internet of Things
– Architecture
– The MQTT Driver
– Demo
– Q&A

The Internet of Things
 The term Internet of Things (IoT) is used to describe
the practice of connecting devices through the use of
the Internet.
 The IoT is already connecting computing devices,
appliances, humans and other living beings through
the Internet.
 The IoT is made of events
and signals of many
different kinds and
require a standardized
mode of communication
Source: ibm.com

The amount and variety of data from smart devices is
increasing exponentially. It is predicted that, by 2020,
there will be an installed base of more than 30 billion
smart devices worldwide, up from 2.5 billion in 2009 and
10 billion today.
Sources: ibm.com and software.schneider-electric.com/solutions/internet-of-things/

Internet Of Things (IoT) / Industry 4.0 *
 15x growth in machine generated data by 2020
(interoperability)
 50x growth in stored data by 2020 (BIG Data)
 85% of devices are not connected yet (timing)
 $19 trillion estimated untapped value (opportunity)
Source: WindRiver Helix 360 System Tools

IIoT
Industrial Internet Of Things (IoT) / Industry 4.0
 Devices are machines operating in industrial,
transportation, energy or medical environment
 Data volumes and rates tend to be from sustained to
relatively high (BIG Data)
 Applications are mission and or safety critical, e.g. the
failure of a smart grid has severe impact on our life
and economy, the misbehaving of a smart traffic
system can threaten drivers
 IIoT applications tend to be “system centric”
Source: Prismtech

Protocol
The connected devices need a protocol using which they
could communicate only when it is required.
Devices with constrained resources
should be able to communicate
with various other heterogeneous
devices.
Source: ibm.com

MQTT (“Message Queueing Telemetry Transport”)
MQTT is a machine-to-machine
(M2M)/"Internet of Things"
connectivity protocol.
It is an open protocol and
standardized by the OASIS
Technical Committee.
This makes this protocol easy to
adopt for the wide variety of IoT
devices, platforms, and operating
systems
Source: mqtt.org

MQTT
It was designed as an
extremely lightweight
Publish/Subscribe messaging
transport.
It is useful for connections
with remote locations where
a small code footprint is
required and/or network
bandwidth is at a premium.
Source: mqtt.org

Benefits
It has been used in Sensors communicating to a
Broker via satellite link, over occasional dial-up
connections with healthcare providers, and in a
range of home automation and small device
scenarios.
Picture Source: ibm.com

Mobile
It is also ideal for mobile applications because
of its small size, low power usage, minimized
data packets, and efficient distribution of
information to one or many receivers
Source: mqtt.org

Benefits
Source: Paulo Patierno @ppartieno

Publish / Subscribe
The MQTT messages are delivered
asynchronously (“push”) through publish subscribe
architecture.
The MQTT protocol works by exchanging a series of
MQTT control packets in a defined way.
Publish/Subscribe decouples
a client, which is sending a
particular message
(called publisher) from another
client (or more clients),
which is receiving the message (called subscriber).
Source: ibm.com

Broker
The Broker is primarily responsible for:
 receiving all messages and
filtering them
 deciding who is interested
 sending the message to all subscribed clients
 the authentication and authorization of clients
It also holds the session of all persisted clients including
subscriptions and missed messages.
The broker is the central hub, which every message
needs to pass
Source: hivemq.com

Topic
 A Topic is a hierarchical structured string,
which is used for message filtering and routing and
determines which message gets to which client
Source: embedded101.com

Topic Name
 The MQTT Topic Name is included in every PUBLISH
message
 In general Topic name have the format:
site/line/machine/data
 Notice that the device or appliance ID is useful to
include to be able to subscribe to the flow coming
from a specific device, e.g. the refrigerator, as
opposed to all instance of a given device
 As such the length of the topic name, in real
applications is on the order of tens of bytes.
Source: ibm.com

Quality of Service (QoS)
Determine how each MQTT message is delivered
and must be specified for every message sent
through MQTT.

Quality of Service (QoS)
This value determines how the client and the server
communicate to deliver the message.
 QoS 0 (At most once) - where messages are delivered
according to the best efforts of the operating
environment. Message loss can occur.
 QoS 1 (At least once) - where messages are assured to
arrive but duplicates can occur.
 QoS 2 (Exactly once) - where message are assured to
arrive exactly once.
Source: ibm.com

Architecture
WAN
Internet
LAN
Thin Clients
Goals
Distributed Data Acquisition, Manipulation and
Control
Centralized Management
Characteristics and Requirements
Scalable – Large number of devices, Big Data
Secure – Encryption, Filtering, Remote notification
Platform agnostic – Both runtime and Thin Clients
Simple - Easy to configure, deploy, and maintain

MQTT Driver
The MQTT driver, currently on version 1.2, is available
for the following Runtime Targets:
 IWS – Windows PC Runtime
 EmbeddedView – Runtime for Windows Embedded
Standard
 IoTView – Platform Agnostic Runtime (Linux)
Current Limitations:
• No support for Authentication
• No support for SSL
Free download on
www.indusoft.com/Products-Downloads/Drivers

MQTT Driver Settings
Keep Alive: measured in seconds, defines the maximum time that should pass
without communication between the client and the server.
The client will ensure that at least one message travels across the network
within each keep alive period. In the absence of a data-related message
during the time period, the client sends a very small MQTT "ping" message,
which the server will acknowledge. The keep alive interval enables the client
to detect when the server is no longer available without having to wait for the
long TCP/IP timeout. Set to 0 if you do not want any keep alive processing.
Client ID: The Client Identifier identifies
the Client to the Server. Each Client
connecting to the Server has a unique
Client ID.
The Client ID MUST be a unique
(not empty) string.

MQTT Driver Worksheet
Station field:
<IP Address or URL>[:Port Number][:QOS][:R]
Where:
IP Address or URL
IP address of the third-party MQTT broker (Server). (This field is mandatory.)
Port Number
TCP port number used to connect with the third-party MQTT broker (Server). If
omitted, the default Port number (1883) is used by the driver.
QOS
Quality of Service number (0, 1, or 2). If omitted, the default QOS (1) is used by
the driver.

MQTT Driver Worksheet
MDS I/O Address field:
Each message is sent by the publisher to the broker with a topic
(alphanumeric identifier). The broker forwards the messages to the
clients that subscribed to the respective topic.
The Topic of each message is configured in the I/O Address field.
SDS Header + Address fields:
They will be concatenated to form the complete Topic used to
publish a message to the broker or to subscribe to a Topic.

Demo Architecture
Schneider Electric M340 PLC
MOTCP Driver (Modbus over TCP/IP)
InduSoft IoTView
MQTT Driver
Acting both as
Publisher
(Publish PLC Data) &
Subscriber
(Send Data to the PLC)
TT3
MQTT Client Test
Mobile Access Thin Clients

InduSoft Web Studio and MQTT for Internet of Things Applications

More Related Content

Viewers also liked

Similar to InduSoft Web Studio and MQTT for Internet of Things Applications

More from AVEVA

Recently uploaded

InduSoft Web Studio and MQTT for Internet of Things Applications