Internet of Things - Application of IoT in Manufacturing
This article is part of IoT Architecture Series - https://navveenbalani.dev/index.php/articles/internet-of-things-architecture-components-and-stack-view/
Large manufacturers have been using some automation and smart technology to streamline and optimize their processes and improve their operation and production efficiency. However, as manufacturers start moving towards the next industrial revolution (Industry 4.0 or Industrial Internet of Things(IIoT)) and technologies available today that can analyze massive volume, variety, and velocity of data generated by various machines and sensors, there arises an opportunity to streamline this information to further improve the manufacturing process and most importantly start designing and developing connected products that can enhance customer satisfaction and services and open up avenues for new financial business models.
*Note
– The term Industry 4.0 and Industrial Internet of Things are usually used interchangeably, but they have
different context and reference. Industry 4.0 is a term coined by the German government,
it marks the fourth*[*industrial
revolution*](https://en.wikipedia.org/wiki/Industrial_revolution) *and can be described as the digitalization of industrial
sector, especially for manufacturing. Industrial Internet of Things is about
enabling and applying IoT across industries. Also check out Industrial Internet
Consortium (http://www.industrialinternetconsortium.org/) a non-profit
organization, founded by AT&T, Cisco, GE, IBM and Intel to collaborate
and set the architectural framework and direction for the Industrial Internet
of Things*
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.
*Tip -
Anomalies can be detected using unsupervised machine learning algorithms like
K-means. Libraries such as Spark MLlib provide first class support for many
machine learning algorithms.*
In future, we
could see pre-built templates available for industry verticals which provide
the domain model, rules, process flows, machine learning models, anomaly detectors
and the job of the system integrator would be to map the device data into the
domain model, extend the data model and customize the flow based on the client
requirements.
There may be hundreds or thousands of such
rules in a complex manufacturing system,
and it becomes very imperative to capture such requirements as part of your
connected design. The connected design phase is yet to catch on, and most of the noise is around IoT
platforms and implementations. The futuristic software products will provide end-to-end
IoT implementations from a connected design perspective and also provide large-scale
simulations to simulate the design and the end product.
Predictive Maintenance
Predictive maintenance is the ability of
the system to predict a machine failure. Predictive maintenance phase comprises
of 2 parts - one is the ability to predict when the machine/asset failure would
happen and secondly to perform maintenance activity before the malfunction
happens. Predictive maintenance is one of the most widely discussed topics in
the IoT ecosystem.
The first two phases of the manufacturing
IoT involved monitoring and condition-based maintenance. These phases can
provide us with enough historical data, learnings,
the correlation between the data, type of
failures and corrective action taken and
enabled to predict possible failures and what actions needs to be performed on the concerned asset.
In many places, you would read that
predictive maintenance is same or a part of condition-based maintenance. We
chose to call it out separately as the scope and implementations are quite
different. Both deals with ensuring the maintenance are carried out before
failure. The condition based maintenance primarily use monitoring, rules, and
anomaly detection techniques; while predictive maintenance takes a step further
to analyze volumes of historical or trend data, correlations, and machine
specifications to predict an outcome. Predicting an outcome is very complex and
an ongoing task, which requires being handled
separately.
A simple use case is using the information
of the assets and its lifecycle and actual ‘wear and tear’ data of the parts
provided through the connected devices; one
can possibly predict the remaining life
cycle of an asset and when should the maintenance be required. Imagine a dashboard, which lists the assets
and its metadata, like manufacturing date, installed date, type, etc. along with its actual usage and maintenance
activity carried out during condition based maintenance phase. It also depicts
external factors and predictions on remaining life cycle of the asset and a
maintenance date. These factors can be used to plan a minimum maintenance downtime,
schedule spare parts delivery and ensure maintenance is executed with least impact.
Secondly, every manufacturer typically has historical maintenance records of
the systems and usage data in some form, which needs to be converted into
required format and can be a valuable input to predict the maintenance
activity.
Going back to the elevator use case, take
the example of the elevator lift cables. Can a system predict when the elevator
lift cables need to be changed?
Manufacturing innovations are happening in elevator cables, like using super
light carbon fiber ropes that increase
the lifespan of the cables, but still changing the lift cables is a costly
maintenance activity and at the same time its failure can have a considerable downtime.
Ensuring availability of new lift cables, specialized technicians availability,
compliance check and all these factors can impact the business operations
considerably.
In order to carry out any predictive maintenance for elevator lift cables, the
manufacturer needs to look at what data points would be required to predict the
failure. As part of its Connect product
design, the manufacturer had probably installed a sensor to track the running
time or distance served by the cable, a sensor to detect if the elevator is
descending faster than its designated speed and to monitor the start and stop
instances of the elevator. Sensor input together with the cable’s specified
life expectancy can be used to predict when the lift cables need to be replaced. In an actual scenario, many more such data sets need to be provided to
predict outcomes.
Predictive maintenance involves building
out machine learning models based on volumes of data. Developing machine
learning models require considerable time and effort. It’s virtually impossible
to expect a system to devise a predictive model which is always 100% accurate
(not even human operate with that level of accuracy:)),
but should be considerable enough to suggest a cause of possible failure with
reasonable accuracy.
Open source scalable machine learning
models like Spark MLlib or commercial offerings like SPSS from IBM or Azure ML
for Microsoft can aid in building predictive models. The real challenge is
building feature sets (attributes) and using algorithms like Support Vector
Machines, Logistic Regression, and Decision Trees or an ensemble model using
multiple machine learning algorithms to
predict an outcome.
The model once developed can be integrated
into your IoT platform (as part of the Analytics Platform layer –refer Chapter
- to predict outcomes in real-time. We would talk about this in detail in our
next chapter as part of the services offered by various IoT platforms.
In future, we should see specialized
pre-shipped predictive maintenance services targeted for various
industries/verticals like connected car, elevator maintenance, wind turbines, etc. These services would provide a
generalized machine learning model developed using various factors we talked
about earlier. System Integrators would play a key role in building the new machine
learning model or use existing machine learning models and integrate with the
IoT platform. For instance, take an example of a
connected car, using the OBD device (actual diagnostic data at runtime) + GPS
location, along with asset metadata (like type and make of car, manufacturing
date of various parts and its specifications), a generalized machine learning model
can be developed which can help predict maintenance activities and failures for
any car type. This assumes that you
should be able to look up the metadata for the car and its specifications, for instance,
the AUDI car type, model, maintenance service requirements would be different
as compared to BMW or an AUDI of a different model. The generalized data
model (a connected car would have different input/output parameters as compared
to a connected elevator) used by the machine learning model would also be a key
component in helping to build predictive
models effectively.
Many manufacturers are taking a step in this direction but building predictive
models with a good amount of accuracy is
not an easy task and this space would see a lot
of competition, partnership and innovations from manufacturers to software
platform provider to system integrators.
Optimization
Optimization phase is all about identifying
new insights based on the existing data that can further help refine the
manufacturing process. A large volume of
data generated by the devices, together with events generated by the system and
various insights from predictive and condition based maintenance opens up the
door for identifying and realizing new requirements, which further enriches
connected solution design to derive
better outcomes.
Optimization can happen during every phase
viz- monitoring, condition, and predictive-based maintenance. We called this out
as a separate phase as this is an important activity to track on how applying IoT
optimizes the current process and the connected products. For instance, using the
outcome of predictive maintenance, one can understand failure patterns better
and look at corrective ways to schedule services across the globe and order
spare parts effectively and in turn optimize the supply chain process.
Going back to the elevator use case, if the
elevator is fully occupied and it stops
at multiple floors due to passengers wanting to enter, only to find that there
is no room to enter. This can annoy
passengers who are inside and outside of the elevator. These kinds of pattern (which are not failure conditions) can be detected
as part of monitoring phase and therefore it can be optimized by creating a
rule not to stop at floors when load is full other than the floors selected by
the passengers inside the elevator and notifying passengers waiting for the elevator
with the appropriate status. To inspect
the user has already taken another elevator, sensors can be applied to
track the movement and presence of persons on each floor and share the status at runtime, which is picked up by the
incoming elevator and not to stop at the corresponding floor.
Take another example of various 100 storey buildings (in future tall skyscrapers would be quite common), how would a
system optimize elevators to ensure maximum passenger satisfaction and least
waiting time for passengers taking the elevators, fewer stops per trip and an
organized traffic flow to prevent crowding of passengers. These are the cases
where optimization and innovation can play an important part, and that would mean looking at the elevator IoT solution
holistically and not just relying only on data provided by the elevators. It
would mean determining connected dots like passenger movements, crowd density
at each floor, or even devising smarter
algorithms to utilize the data available and suggest optimized steps/routes to
the elevator system.
As we move into the future of a connected
world, we would see various such use cases which primarily focuses on customer
satisfaction and employing new innovations
to solve existing problem using the connected information.
Connecting ‘connected solutions’
In a connected world, the real innovation
would happen on how the data from one connected
system would be used by other connected systems and come up with new
business models that we haven’t thought of so far.
For example, let’s assume the elevator
manufacturing company relies on a third-party vendor for their logistics and
shipment of machinery and spare parts. Getting real-time visibility into the
moving parts across the globe along with
the external factors could help plan the contingency better. For instance, if
it takes X amount of additional time to get spare parts from Y location as
compared to Z location, but due to real-time weather insight integrated system,
reporting extreme weather conditions at Y location for next three days, it’s better to order spare parts
from Z location to reach on time. The distance from Z location can be further
optimized based on real-time notifications from traffic systems that can
provide an alternate route to the manufacturing plant. Here insights from the
logistics aggregation company are offered as the value added services to
manufacturing systems.
Take another example of passengers waiting
for an elevator, what is the best way to keep the passengers engaged and
satisfied and not grumble about the delay. A
customer after checking-in to the smart connected hotel and waiting for the
elevator for few minutes and later having too many stops to reach at his 90th
floor, in one way can be engaged by providing complimentary vouchers for the
delay on his Smartphone (through beacons and hotel smart apps on mobile) or
through his hotel room card (which is digitized and provide various
information) or a call as soon as he reaches his room. In that way, the
customer would get the sense of being instantly connected and feel that the
hotel acknowledged the delay and cared about it.
Take another
example of how data from the connected car solution can be used to derive real
values like, traffic management, public safety, fleet management, after sales
service and industries like insurance that would tap into the data and devise
‘pay per use’ model based on actual usage of the car and based on driving/behaviour
pattern of the driver. The insurance underwriting
process would be changed to take into account these various connected
parameters to quote the insurance premium. Insurance companies might also
provide various value added services like tying up with service vendors for
after sales services or providing just in time insurance for a second person
driving the car. Privacy and security can pose a challenge, but they can be effectively handled through service level
agreements between car broker/owner and insurance companies.
The current generation does not hesitate to
share information on social media. Sometimes sharing information can be tricky
but often times you would want to do that
to improve your experience with the connected world as every smart business
then will be able to provide personalized service based on your personal
preference or characteristic. It will bring out positive outcomes and benefit
at large and will be appreciated by the
same people thereby creating a framework of
connected people and business.
In the next article, we will talk about a couple of use cases. We call this as start-up use cases, where start-ups and small organizations are tapping into IoT to create new innovative products from scratch. We would cover two such use cases – connected car and connected home.