---
title: Connected Elevator Solution using IBM IoT Stack
type: article
date: 2018-12-01
source: website
original_url: "https://navveenbalani.dev/index.php/articles/connected-elevator-solution-using-ibm-iot-stack/"
topics: ["iot"]
legacy_categories: ["iot"]
tags: ["iot-guide"]
summary: "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…"
draft: false
---

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](/articles/building-application-with-ibm-iot-platform), 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