An Example of How Solace is Enabling Smart Living

Leaders of cities around the world are looking for ways to leverage the Internet of Things (IoT) to streamline traffic and public transportation systems, more efficiently manage and deliver city assets, and provide personalized services to their citizens. These activities and initiatives are frequently described as smart city, smart building, smart infrastructure, and smart transportation, and together they add up to smart living.

Smart living leverages digital technologies to increase the efficiency and quality of life of every citizen. As technology evolves, smart living will positively affect every aspect of our life. Some examples include:

• Rerouting of smart public transit
• Notifications to drivers
• Developing trends that could be important to housing and community development
• Intelligent stormwater management (for drainage)
• Intelligent disaster response and evacuation
• Smart Environment that is capturing real-time environment information (like temperature, humidity, pollution index) and creates a more pleasant environment for the residents
• Health hazard tracking and alerting for diseases linked to standing water (like malaria outbreaks in certain regions)

Challenges with Event Distribution in IoT

At the heart of any smart living initiative is the Internet of Things: “The network of physical objects—“things”—that are embedded with sensors, software, and other technologies to connect and exchange data with other devices and systems over the Internet.” (Source: Wikipedia).

The foundation of IoT is the real-time collection of sensor data from millions of devices, which can be used to make intelligent decisions in real-time. Data distribution at scale is a big challenge for the enablement of IoT.

Data distribution in the IoT scenario must have the following characteristics:

• Very high throughput (For millions of messages flowing around every second)
• Very high connection count (for connecting a vast number of devices)
• Highly secure (Citizen and sensor data security is paramount)
• Low latency (especially in Command and Control scenario where latency required for data distribution would be in the range of milliseconds)
• Native support of IoT messaging protocols
• Shock absorption to make sure a large amount of data does not bring the applications down

PubSub+ Event Broker was purpose-built to solve this challenge, and in this article, we will use a real life example to show how.

Use Case Description

The Internet of Things is an umbrella that covers many machine-to-machine interactions. The machines could be anything from a manufacturing robot, to a pipeline flow sensor, to an ATM, a connected car, a smart building sensor, a fitness tracker, or even a smartphone. Whatever the use case, these devices need to communicate with various backend systems for the business case – data warehouses, account lookups, CEP farms, etc.

This communication can be one-way or bidirectional. It can be initiated from either end, and each interaction can have its own security needs.

Various use cases under the smart living umbrella have been described above. Let’s take a specific example of smart Buildings and see how we can implement this using Solace PubSub+ Event Broker. The challenge in an IoT deployment is real-time designing, bidirectional systems, having “command and control”, and analytics capabilities.

The same principles of event distribution used in smart buildings also apply to the other IoT use cases.

The main event distribution patterns in an IoT use case are:

• Event aggregation
• Command and Control
• Request/Reply interactions

Let’s see how these patterns apply to our smart buildings use case. Within a building estate, there are various sensors producing data, such as:

• Elevators
• Escalator
• Lighting in common building areas
• Water Levels
• Lamp-posts used for lighting up common areas

These components are critical parts of building infrastructure – building owners need to ensure the safe, reliable, and predictable functioning of these components. It can get more challenging to manage as the number of buildings increases. In terms of scale, the number of buildings can go up to 100,000 (or more if additional locations are added). The number of sensors can easily be increased by two-fold or more as time goes by. Various sensor data such as physical condition, utilization, state, levels, etc., is to be collected and made available to back-end systems.

Once the sensor data is collected, you can run analytics for various purposes. The device health data is then used to optimize the maintenance cycle and pre-empt any devices’ issues.

Additionally, you may want to perform “command and control” functions and send an instruction to a particular IoT device or a specific group of devices from the back-end – such as turning off a faulty escalator or turning off lighting that is not required.

Finally, you may want to perform some request/reply patterns – such as an OTA update where a device downloads the latest version of the firmware from the back-end system or when the back-end system requests for logs and diagnostics from a faulty device for troubleshooting.

Once the data is collected and made available to the back-end systems, you may want to send this to your favorite cloud provider’s services for machine learning and predictive analytics or share the data with other lines of business to provide the consumers with additional value-added services.

In the subsequent sections, we’ll explain how all this is achieved using Solace PubSub+ Event Broker as the data distribution fabric.

Implementation Example of Smart Buildings

A typical IoT deployment architecture has various layers to keep the back-end systems running on the core network separate from the IoT devices which are connecting over the Internet. This is a standard practice when external clients are accessing internal resources and is known as a “Defense in Depth” approach. The various layers are separated by firewalls that handle threats like SYN floods and other denials of service attacks.

PubSub+ Event Broker is deployed on both layers to enable application connectivity. All the IoT devices (either directly or via an IoT gateway) connect to the Solace broker on the Edge layer (known as the Connection Tier) over MQTT. The back-end services connect to the Solace brokers on the Core layer using protocols that serve their needs (such as JMS/AMQP or any of Solace’s proprietary APIs). Solace supports all of the most popular APIs and protocols so applications can seamlessly communicate without any additional component for translation.

Connectivity between the edge and the core layers of Solace brokers can be implemented using either Message-VPN Bridging or Dynamic Message Routing technologies. Both technologies have their advantages, and the choice depends on the requirements of the IoT use case.

Topic Hierarchy Design

In Solace PubSub+ Event Broker, all clients publish events to the broker on a topic. A topic describes the event published to the broker and can be considered as an event tag.

Let’s look at an example of the topic hierarchy and topic flows for this use case. The topic hierarchy decided for the use case was as follows:

<org>/<city>/<post-code>/<device-group>/<device-id>/<event type>

• org: Name of the organization, used as the root topic. We can have more levels for the different lines of business, etc.
• city: City Name
• post-code: Postal code of the building
• device-group: IoT device group or application
• device-id: unique identifier per device
• event type: Type of event being published

This topic hierarchy can serve as a starting point for your IoT use case – additional fields can be added and removed, depending on the specific requirements of the use cases. For more information on the best practices for designing a Solace topic hierarchy, I highly recommend you read this amazing blog.

Let’s now see how this topic hierarchy can aid in event distribution for each message pattern in our smart building example.

Event Aggregation

The aggregation and ingestion of events can be performed using Solace’s topic routing feature to fan out the sensor events from IoT devices to interested back-end consumers. For example, a single IoT device can report its status to multiple back-end systems.

For instance, if a sensor on an elevator identifies that it has stopped or a water tank monitor suggests more water is used, this can update several systems:

• A monitoring company can be notified to send someone out to check on the problem.
• An email can be sent to the owner of the unit to do basic troubleshooting.
• All of these data points are sent to a database for future analysis.

The number of back-end consumer services needed to handle the high volume of events from the fleet of IoT devices requires some form of persistence to be present on the event broker. Solace’s guaranteed messaging feature allows the broker to act as an efficient shock absorber in front of the back-end consumers – allowing the event broker to absorb any burst of IoT events and having them drip down to the consumers at a rate that they can sustain. This is implemented by creating queues for each back-end consumer. Solace’s topic to queue mapping features allows each consumer to attract messages on a particular set of subscriptions – allowing each consumer to only receive the IoT events from the type of device they are interested in, providing fine-grained filtering. The Solace event broker will dynamically filter and deliver only those messages to a consumer that satisfy the topic subscriptions on their queues. These are delivered in a persistent fashion – meaning that if the consumer goes down, messages are spooled for the consumer on the broker. This allows the consumer to continue processing messages when they reconnect to the Solace broker with no loss of data.

For example, various IoT devices such as escalators, elevators, and lamp posts can publish their health status on respective topics, and queues would be created for each consumer system on the Solace broker on the core layer. Each queue can have one or more subscriptions to attract the appropriate events. For example, the first queue attracts all escalators’ health status events, while the second queue collects this for all cameras. These subscriptions can also contain wildcards; for example, the third consumer is an audit application and requires all health events published by all devices.

Command and Control

Command and control events can be of two patterns – when the back-end system is sending out a broadcast to all IoT devices or a subset of them, or when the back-end system wants to communicate and instruction to a particular device.

The former pattern can be implemented using the topic-routing feature in Solace PubSub+. It is vital that the device group should be available as a field in the topic hierarchy, allowing the back-end system to publish the event to the entire group – such as a notification event informing all the devices that a new version of the firmware is available for download.

Since the device ID has also been incorporated in our topic hierarchy, the same pattern will allow our back-end systems to reach out to a single specific IoT device and send it an event to perform a particular action, like de-activating a single malfunctioning sensor or enabling the debug mode to turn on log verbosity for troubleshooting, or allowing a back-end service calculating lines of sight for a security camera to instruct the camera to re-orient itself to provide complete coverage.

Above, we can see a back-end service publishing a notification message to all devices in the “escalator” group that a new version of the firmware is available for download. A separate back-end service is publishing an event to a specific camera with device-id “PQR” to re-orient itself.

This pattern also works in the other direction. For example, a smart building sensor can report its temperature to a complex event processing service, or a video camera can send a single video frame to a surveillance application.

In short, any event can be addressed and delivered to any application connected to the event brokers.

Request/Reply Interactions

Request/reply interactions are meant for use cases where an application requires an acknowledgment of an event that it has published. This acknowledgment can be as simple as indicating that the event from the requesting system has been received or as complex as approving or denying a particular action. The simplest example of request/reply is an IoT device sending a request to the back-end service to look up a value in a database or a back-end service sending out a request to turn on or off a particular device.

Below, we can see an escalator publishing a request to retrieve a particular value from a back-end system and the back-end system providing the retrieved values in the response. At the same time, a separate back-end service is publishing an event to request a specific elevator with device-id “ASD” to stop, and the elevator will send its status in the response.

Request reply interactions can also be designed to have a multi-fragment response aggregated and consumed by the requesting system. An IoT device may want to download the latest version of the device firmware from the backend system – it would send out a single request for download, with multiple replies being sent back from the backend system with fragments of the firmware file.

Security

Security is one of the most critical challenges associated with IoT. From an event distribution perspective, these challenges include authentication, authorization, and transport security.

Solace PubSub+ Event Broker supports comprehensive authentication, authorization, and encryption feature to ensure that your infrastructure and information are protected at all times and that you pass internal and regulatory security audits.  The platform provides the capabilities to protect against unauthorized access to the messaging infrastructure, thereby mitigating network attacks.

• Authentication: Each IoT device should be authenticated when accessing the event broker. With Solace PubSub+ Event Broker, you can use OAuth and OpenID connect to authenticate the MQTT clients.  Client certificates can also be used to authenticate each device. Alternatively, you can authenticate the devices against your organization’s LDAP or Active Directory, providing a secure way to authenticate a device before it connects and publishes or subscribes to any data.
  For more information, see Client Authentication.
• Authorization: Authorization policies should be applied to ensure that each IoT device only publishes and subscribes to events that it is supposed to. Additionally, controls should be in place to ensure that one IoT device is not impersonated by any other compromised device. This can be achieved by applying Solace’s ACL Profiles to the various device groups.
  For more information, see Client Authorization.
• Transport Security: All data in transit between the devices, the event brokers, and the backend servers should be encrypted so that the data is not tampered. Solace PubSub+ Event Broker supports SSL/TLS to ensure that all your events in motion are encrypted to preserve data integrity. For more information, see TLS/SSL Encryption Overview.

Conclusion

We hope this article has helped you understand how Solace PubSub+ Event Broker plays a vital role in data distribution challenges for multiple smart living or IoT use cases. You may want to check out our docs for more use cases. Do contact us in case you or your team need more technical deep dive. We have done various use cases in this area and would love to hear from you.