New
technology bytesWhat Does Slowing Down Mean When You've Built the Fastest Engine in the World?articleMigrating a 20-Year WordPress Blog to Be Agent-Readytechnology bytesAGI Has Arrived. Now Give It a Simpler Problem.technology bytesWhat Does Slowing Down Mean When You've Built the Fastest Engine in the World?articleMigrating a 20-Year WordPress Blog to Be Agent-Readytechnology bytesAGI Has Arrived. Now Give It a Simpler Problem.
Navveen Balani Making systems intelligent, efficient & responsible

Connected Elevator Solution using IBM IoT Stack

Original post View as markdown

This article is part of IoT Architecture Series - https://navveenbalani.dev/index.php/articles/internet-of-things-architecture-components-and-stack-view/

In the previous article, we went through the IBM IoT stack. In this article, we will implement the connected elevator solution.

Hardware and Connectivity

In this section,

we would discuss the hardware and connectivity approach for the elevator use

case. The elevator manufacturer has already invested in Maximo (IBM Asset

Management solution) for managing the physical assets and workflows and now

wants to start the journey towards a smarter connected solution. We described

the set of phases in the second chapter and how can a manufacturer use each of

these phases to incrementally implement an IoT

solution. We will realize the elevator use case using IBM IoT stack

through the following phases viz. monitoring (which includes asset management),

condition maintenance and finally predictive maintenance.

We would not go into the details of each

phase again but only talk about the

implementation steps. The manufacturer as part of a connected design adds

various new sensors to the existing elevator control unit. The elevator

manufacturer as a first step leverages

its existing investment and tries to keep the connectivity and communication

protocol between elevator control unit and rest of components same and builds

up the device connectivity code using the

Watson IoT Platform Embedded C Device library and converts the non-proprietary

protocols to MQTT and deploys it in the elevator control unit.  The elevator control unit device is provisioned with secure access as part of

the device registration process using Watson IoT Platform dashboard (or Watson

IoT Platform APIs).

The control unit can be thought of as a gateway that connects to Watson

IoT Platform and does local processing

and conversion. It collates the data from various sensors and maintains the

communication and wraps the sensor data into JSON data and sends it over MQTT

protocol to Watson IoT Platform.

Software Implementation Overview

The following are the high-level steps that needs to be performed in Bluemix

  1. Create Watson IoT Platform service
  2. Register devices and get access credentials
  3. Provision devices (elevator control device)
  4. Create storage (database for storing raw data from devices, asset mapping)
  5. Create Node-RED flow   (end to end execution flow)
  6. Create Push Notification Service (mobile notifications)
  7. Create ML model (anomaly and predictive maintenance)

The above step is just one of the

approaches to building end-to-end IoT application. Instead of Node-RED flow we

could also use IBM Streaming Analytics or Apache Spark service. As mentioned

earlier, this service does not have seamless integration with Watson IoT

Platform.  As part of the solution, we

can create separate Node-RED flows as it’s easier to maintain and replace the

flow by Streaming Analytics services for high throughput cases where complex

requirements like correlating and working with multiple data sources are required.

Following shows the connected elevator solution using Watson IoT Platform and Bluemix services.

The Watson IoT Platform service receives

the data from the connected elevator over MQTT protocol.  A Node-RED flow is created which receives the connected elevator device data from

the corresponding topic. To map the runtime data

from devices to physical asset in Maximo, a database (MongoDB) is used

to store the mapping.

We create multiple Node-RED flows as shown below;

they all listen to events from specified MQTT topic.

  • A Node-RED flow stores the data in MongoDB

  • A set of Node-RED flows works on data directly and evaluates the required monitoring and condition-based

    rules.

  • A Node-RED flow for predictive maintenance which creates the abstract data model and calls the predictive

    analytics service via the REST API

  • A Node-RED flow for

    anomaly detection. Note this is bidirectional in the implementation diagram

    above, as the response from anomaly is send to the mobile operator using push

    notification.

  • Based on the outcome, the required action item is executed by the above flows (SMS via the push service

    or invoking a work order in Maximo through REST call).

We have not covered the details of building

the predictive model as it was already discussed

as part Microsoft IoT solution.  The

approach of building a machine model, whether using Microsoft or IBM tools or

open source options remains the same. You build the model and train the model

iteratively using the raw data from the connected devices, asset metadata and

historical maintenance records. The real challenge in building the model is

choosing the right features, cleaning and

aggregating the data, applying algorithms, training the model and continuously

iterating it to reasonably predict the outcome.

 We

use the SPSS Modeler, which provides the

capabilities to prepare the data and build models, similar to Azure ML that we

discussed earlier. We use the SPSS Modeler to build predictive models and

detect anomaly.

Once the model is developed, it is deployed in Bluemix through the predictive maintenance dashboard and can be accessed through the Node-RED flow through the HTTP/REST API connector node. This completes the connected elevator implementation using IBM Watson IoT Platform and Bluemix.

In the next article, we would implement the IoT Solution using Amazon AWS Stack

iot