Application Of IoT In Manufacturing
By: Navveen Balani
Tags: Iot In Manufacturing, Internet of Things, Connected Elevator, Connected Home, Connected Car

Let’s take an example of a leading elevator manufacturing company which supplies elevators across the globe. The elevators already have some instrumentation built in, like door sensor, a weight sensor which triggers an alert like beep in case of overload, etc., but the elevator company has no visibility on how the elevators are being used across the globe and therefore, raises the following important questions:

Are these elevators working as expected and utilized as per the specification?

Is there a failure condition?

What kind of failure has occurred?

How are failures to be handled?

What is the typical acceptable downtime?

Which agency is handling the failure condition?

How effective is the after-sales service in that region?

Is there a competent expertise available to handle a given failure condition?

Are the spare parts available to quickly start the restoration process?

Proper application of IoT can address the above questions by designing a connected solution that will help capture and analyze the product usage, operational and failure data and ultimately improve the customer satisfaction and services.

IoT can not only transform the end products but the entire manufacturing process right from the start where the elevators are manufactured. The supply chain process and logistics can also be streamlined to enhance operational efficiency and productivity and deliver better financial gains.

IoT is an incremental journey; it’s an evolution, and any manufacturing IoT realization can be broken down into the following five phases:

Monitoring & Utilization

Condition based maintenance

Predictive Maintenance

Optimization

Connecting ‘connected solutions.’

Monitoring & Utilization

Monitoring and utilization are the first steps of an IoT journey. This is an umbrella phase which itself consists of many requirements.

For the large scale manufacturer, to enable seamless monitoring and utilization of their systems, the step usually comprises of:

Asset Management Identifying assets that need to be monitored

Instrumentation

Leveraging existing instrumentation investments (if any)

Adding new hardware capability (new sensors/actuators/microcontrollers) based on the design and requirements of the connected solution.

Handle Connectivity

Adding connectivity to devices as per above points (1) and (2). We would talk about various patterns, the device directly connected to the core platform; intercommunication between devices or a device gateway connected to the core platform which communicates with existing devices using a low level or existing proprietary protocols.

Perform Monitoring

Asset Management

To start with you need to identify the set of physical assets that needs to be monitored. For example, for an elevator manufacturing company an elevator is an asset, which contains various sub-assets like doors, input control buttons (open, close, call, alarm, etc.), elevator telephone, etc. Similarly, for a connected car manufacturer, the car is an asset that contains various sub-assets like engine, brakes, tires, etc. and for any manufacturing plant, machinery equipment, conveyor systems, etc. are examples of assets that needs to be monitored. An asset contains a set of metadata, for example, a car engine can have a manufacturer’s name, capacity, year of manufacturing, etc. Asset management is perceived through asset metadata and its dependencies with other assets. Manufacturers typically have a software platform or an application to manage the lifecycle of its assets. While moving towards implementing IoT, the existing asset management design or application may not be sufficient or good enough for building next generation connected solution. Right from requirements, design to simulation, creating connected products and its lifecycle management, will require a completely new approach and a set of next generation software products to realize a connected solution. We envision a set of new emerging software products to tackle requirements for designing connected solution. For instance, understanding a dependency between a car engine, engine oil, led indicators and brakes through the system’s metadata and making use of analytics platform to perform analysis on the actual sensor data in a connected car solution, could help derive correlations easily and suggest measures to tackle failure condition. The design of connected products is a separate topic in itself and outside the scope of this book.

Instrumentation

In the manufacturing world, some kind of instrumentation is already employed, like the use case of the elevator, which we talked about earlier. The elevators already have built-in sensors, but these sensors are not connected to any platform, (the platform here maps to core platform in our architecture diagram — Refer Chapter 1) so as to enable transfer and analysis of the data. Moreover, the protocol and connectivity (maps to communication layer in our architecture diagram– Refer Chapter 1) for the various hardware components (or devices) in the elevator and their interactions would be very proprietary in nature.

Based on the requirements of the connected product, new hardware components (devices, microcontroller, sensors, etc.) might also be required. For instance, in a connected elevator design, the elevators now have new requirements to maintain an optimum temperature for smooth functioning, taking into account surrounding external factors (external factors may vary in different regions). Now the new design could also break down an operating ambient temperature into multiple levels of degradations, monitor this remotely or via notification and use this information to schedule services. For instance, take the following example where X is the optimum temperature that needs to be maintained and if X is greater than Threshold value, the degradations process starts. Lastly, if no action is taken from the start of degradation beyond Y days, a critical failure alert message is sent to the elevator company.

X being optimum temperature,

X > Threshold Value -> Needs attention within 5 days. The elevator is still functional but with limited load. The load is cut down from 300 kg to 150 kg.

At this stage, details about the suggestive spare part changes, the location of the spare part, suggested service vendor nearest to the current location is also made available by the system. It’s easier for the system to detect the GPS coordinates of the connected system, look at the inventory and service vendors based on the region and scheduled maintenance services. At this stage, the elevator is operational but with reduced load and have controlled the movement of people using the elevator.

X > Threshold Value (Date) — Y Days –> Critical Failure alert. This is final alert to repair the defective part, along with a good time to repair the elevator based on people movement during that week and projections to ensure minimum downtime and least impact on passengers. The above is only one such example. A manufacturer could employ many such requirements, which would require design changes right from microcontrollers to adding new hardware components. Again, this is an incremental effort; one can take gradual steps by identifying and adding new hardware component and then connecting along the way to the core platform for data transmission. The data is then used to correlate and perform analysis at the core platform layer to understand failure conditions and patterns.

Handle Connectivity

There are three general connectivity patterns, which allow devices to communicate to the core platform

Connecting device directly to core platform

Connecting devices to an intelligent system and/or device gateway.

Intercommunication with devices.

Based on the use cases, the connectivity option would differ. If there is a requirement to process the data locally and take action and/or a requirement to map different proprietary protocols to a standardized protocol, a device gateway is generally used which will translate the incoming protocol instructions to that of the target platform. The requirement also depends on the power consumption capacity of the device, and it may not make sense for all devices to connect directly to the core platform.

For the elevator manufacturing use case, the devices (doors, motor temperature, shaft alignment, etc.) is already instrumented and connected to a central device (microcontroller). The central device can be IoT-enabled, or a new device gateway can be installed which talks to the central device. It can be done by installing the required platform libraries and code that connect to the core platform, understands and map the data from the controller into a payload object (like JSON) and submits the payload to the core platform.

Libraries are available which supports making a device IoT-enabled, like the Eclipse-based Paho library (http://www.eclipse.org/paho/) which is an open-source client implementation of MQTT that can be installed on devices supporting C, Java, Android, Python, C++, JavaScript and NET programming model. This is of course with the assumption that the core platform supports the MQTT protocol.

The choice of library depends on the device being IoT-enabled, the programming language supported by the device (C, C++, JavaScript, etc.), the protocols supported by the core platform (MQTT, AMQP, REST, etc.) and the client library available for the device. One can also use REST style invocations to connect to the core platform. Core platform can provide SDKs for various devices that provide APIs to convert the device data into required payload supported by the core platform. For example, open source projects like Connect-The-Dots (https://github.com/Azure/connectthedots) allow devices to connect to Microsoft IoT services.

Not all data from the IoT-enabled device need to be transferred to the core platform. The IoT-enabled device gateway can employ local storage to filter out the data (like start and stop activity on each floor in case of elevators) and transfer only relevant data to the platform. We don’t want to clog the network and the platform with data that is not relevant and at the same time make sure enough data is transmitted from the systems to analyze important indicators, operational activities of various sensors, identify failures and use the historical events and data for future prediction of machines. Identifying and understanding the critical aspect of the data and prioritizing the same should be a key decision factor for building IoT applications.

Edge gateways can also be used which is geographically located closer to the devices or the device gateways, which can normalize the data before moving it to the core platform. For instance, to a global connected car manufacturer, it would make sense to have edge gateways at respective locations which can then streamline data movement to the core platform. We would see a lot of such patterns evolving in future that would enable scalability and connectivity of billion of devices.

As new production ready devices are manufactured for IoT, we envision the required firmware and connectivity code would be part of the device design and shipped with some standardized protocol support. In an ideal world, we should have converged on one standardized protocol for IoT (like the AllJoyn protocol which is gaining momentum) to make connectivity seamless, but in reality, many such standardized protocols would exist, and there would be an integration approach required to make them work seamlessly.

Another example is of water and waste water manufacturing plant which uses SCADA network to gather, monitor and process data. The manufacturing plant already employs sensors and proprietary protocols that monitor temperature, relative humidity, pH, barometric pressure, and various other environmental parameters. To be agile and scalable, traditional manufacturing systems need to adopt technologies to store and aggregate volumes of data from sensors, monitor systems in real-time, analyze the data and give out insights which were not possible earlier and eventually create predictive models to predict equipment failure or a possible outcome.

This is especially true for manufacturing companies, which might have already employed a wide variety of protocols. The ideal approach or pattern would be to install an intelligent system of gateways to convert these protocols and make them communicate securely with the core platform. Manufacturers can incrementally move their legacy devices into the realm of IoT ecosystem by connecting them to the outside world through intelligent gateways. For instance, BACnet is the widely used protocol for smart building and products like Microsoft AllJoyn Device System Bridge, allows existing devices that use BACnet to connect to an AllJoyn network, thereby enabling existing devices to connect with IoT core platform and also with new AllJoyn devices.

In future, we would see the connected product design being a key requirement as part of the manufacturing process.

Perform Monitoring

Once the devices are connected and data from the devices is made available to the core platform, the monitoring part kicks in. The device data is usually stored in a database (possibly a time series database) for further analysis and predictions and at the same time can be acted upon by the system for real-time analysis. The monitoring phase typically involves providing a dashboard to track the devices remotely across the globe and how each device is being utilized as per the specification. The specifications are available as part of the metadata we talked about it earlier in Asset Management section.

For instance, in the case of the r elevator use case, the optimum motor temperature should not be more than 40 degree Celsius or the air condition temperature inside the elevator should be at least 18 degree Celsius at peak load.

Monitoring can also be used to detect if the elevators are installed and functioning as per the specification. For instance, every manufacturer provides a checklist for regular maintenance activity that can be tracked through remote monitoring. The following is a sample checklist, which is provided by the City of Chicago — Department of Buildings for compliance purpose. As you see, most of the test requirements can be handled by adding sensors and monitoring it remotely.

In the future, environmental requirements like energy efficiency, passenger safety, and control compliance can be met through the remote monitoring and used for auditing and inspection eventually.

As the manufacturers start embracing IoT with the concept of connected products in mind, we would see a new class of products in future that will change the complete dynamics of manufacturing process. Imagine a self-test on the elevator which automatically evaluates the compliance parameters and publishes a report as part of the audit and quality procedures in a connected environment. (In short, an elevator would be compliant and secured 24 * 7).

Once the systems and devices are being monitored, next step is to use the information to provide timely maintenance of the assets based on the specification and its operating condition. We refer to it as condition-based maintenance.

Condition Based Maintenance

Condition-based Maintenance (CBM) is about using the actual data gathered from the devices to decide what maintenance activity needs to be performed on the physical assets being monitored.

The connected device provides a set of continuous measurements (temperature, vibrations, air pressure, heat, etc.) for the physical asset. This data along with the required operating specification of the physical assets can be used to create rules for maintenance activities and taking corrective action.

For the elevator use case, we talked about operating temperature requirement earlier as part of the instrumentation design. With the device data being available, the maintenance service can be scheduled whenever the degradation of asset starts.

For example,

X being optimum temperature,

X > Threshold Value –> Alert the service professional. The service professional can inspect the elevator remotely and approve the spare part suggested by the system. The elevators can continue to be functional under limited load, and the load sensor rule now triggers at 150 kg instead of 300 kg. This ensures at any given point; the load does not increase beyond the expected value in case of degradation.

Take another example of a scheduled maintenance service for your automobile. The service schedule is usually specified as part of the manufacturer’s operation manual based on the average operating condition rather than the actual usage and condition of the automobile. Using condition-based maintenance, the service and maintenance activity, like the oil change in your vehicle should be triggered when the service and replacement is needed based on actual, rather than a predetermined schedule.

There are two approaches to arrive at condition-based maintenance:

The first approach is by creating predetermined rules based on the actual value provided by the devices and executing the required action. For example, if the optimum temperature of an elevator is > 40 and load > 150 kg, execute load alert/beep rule and start the elevator only when the load falls below 150 kg.

The rule can be a simple rule or a combination of rules. The rules can be visually modeled using a programming language or a tool supported by the core platform. The rules are created using the parameters or fields of the device payload. In the above example, optimum temperature, elevator load are the fields defined as part of the payload.

The second approach is monitoring the values and detecting an anomaly. The anomaly detection is about identifying the data and events, which do not conform to the expected pattern as compared to other items in the data set. For example, assume you haven’t defined any rules for optimum temperature functionality and data from the devices is being collected every second, say 15, 15, 17, 18 and on the third day you see this pattern 29,.30, 30, 29…, clearly the values read on the first day are less than half of the values read on the third day. This signifies an anomaly in the system, which can trigger an alert for someone to inspect the system. Another example would be in the case of fire, where this might be detected as an anomaly by the system indicating the dramatic rise in the temperature. There could be another case where fire sensors itself could be tracking fire events. These two cases could be combined to derive a correlation and thereby enabling you to make a more precise observation.

All anomalies might not necessarily be real problems, but detecting anomaly should be a key requirement to ensure any susceptive exceptions are being caught by the system.