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
- Create Watson IoT Platform service
- Register devices and get access credentials
- Provision devices (elevator control device)
- Create storage (database for storing raw data from devices, asset mapping)
- Create Node-RED flow (end to end execution flow)
- Create Push Notification Service (mobile notifications)
- 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
