KPI, OEE and Downtime Analytics: October 2015 An ICONICS Whitepaper
KPI, OEE and Downtime Analytics: October 2015 An ICONICS Whitepaper
KPI, OEE and Downtime Analytics: October 2015 An ICONICS Whitepaper
Downtime Analytics
October 2015
An ICONICS Whitepaper
www.iconics.com
ICONICS WHITEPAPER
CONTENTS
2 Introduction
2.1 ICONICS Tools Provide Downtime Analytics
The ICONICS GENESIS32 and BizViz products enable plants to significantly improve efficiencies by
capturing detailed events, faults, and production information from equipment and operators.
ICONICS’ data collection methodology allows a customizable data set in an open database format,
thus providing the necessary data, for a variety of analytics with the ICONICS reporting, data
management and visualization toolsets to enable improvement of the overall production process.
Plant engineers and managers need to make informed decisions and implement best practices
and may need to have some of the following questions answered:
Plant and operations personnel can make informed decisions using advanced downtime
reporting capabilities. The following white paper explains the ICONICS Downtime Analytics
solution and the modules that comprise it.
AVAILABILITY: Total time equipment was scheduled to run divided by the total
possible time the equipment could have been scheduled to run.
PERFORMANCE: Total time equipment was in cycle producing divided by the total
time scheduled to run.
OEE: These 3 percentages are multiplied together then divided by 10,000 to calculate
the overall equipment effectiveness (OEE).
This display shows Historic OEE data delivered to the end user by a typical ICONICS Downtime Application.
Downtime is one of the key components of the Performance factor of OEE listed above.
Downtime is any time that will reduce the Total Time in Cycle component. In general,
break times and lunch times are not considered downtime as they are already included
in the Total Scheduled Runtime calculation.
There are many types of downtime reasons. This is a small list of the possible reasons:
• Equipment Faulted: Control system detects an undesirable condition that could
cause equipment, part or personnel damage or injury and shuts down process.
• Equipment Over Cycle: Equipment has taken longer to complete a cycle than
configured. Usually this is due to operator content such as part loading and unloading.
• Changeover: Equipment is converting from one part type to another. Usually
requires tooling or fixture changes. Control system is then notified of the change.
• In Process Maintenance: Components or tooling used within the process need
replacement or attention due to wear or other criteria.
• Scheduled Maintenance: Equipment is taken out of production for servicing.
Usually this is for preventative maintenance such lubrication or replacement or
repair of worn or defective components.
• Starved: Equipment has run out of raw materials or subcomponents and is
waiting. Equipment can also be waiting for a part to work on due to preceding
station delays.
• Blocked: Equipment is unable to release current part. This can be caused by the
fact that there is no more room in finished part container or it is absent. It can
also be caused by the next station has not released its part and there is no
buffer between them.
• Production Meeting: Supervisor calls a meeting. Usually for quality alerts or
scheduling changes.
These reasons, some automatic and some requiring operator entry, should be entered
into the system before restarting so the monitoring application can log the reason as the
equipment goes back into production.
It is very good practice to define a set of registers or bits in the control system that will
always be allocated in every system in order to maintain consistency and ease of
implementation on the logging side. If this is done properly the logging system has only to
change the control system address in order to connect to the next system’s events. We will
call this the Common Event Interface. Once this memory is allocated, logic should be
developed to connect the actual signals in the system to the Event Interface.
In the control system, events should be selected that give indications of Faulted, Part
Present to work on, Starved, Blocked, Cycle Complete and Part Accepted.
Once the events to be monitored have been configured in the control system, we must
consider how the reporting system will be querying the data. In most cases some additional
data is required besides just the event name and time stamp. The following is a list of
typical data required for good reporting and ease of configuration.
1 Process ID – Numeric value defined in the database which references the process
information and its location in the facility.
2 Production Date – String value which is the date on which these events will be
charged. This is not always the time stamp date. This is due to the fact that in most
cases events occurring after midnight on the second shift will be charged to the
previous day. Alternatively, events occurring before midnight on the third shift are
usually charged to the next production day. This value is generated by a Shift Engine
Procedure in the database which references a defined shift schedule.
3 Shift Number – Numeric value which represents the current shift. This value is also
generated by the Shift Engine Procedure in the database.
4 Part Type or Product – This string value is read from the control system and
represents the current part type or product being produced.
5 Serial Number or Sequence – If available, this parameter can increase the resolution
of the data down to the individual part being produced.
6 Event Type – This numeric value is defined in a reference table in the database.
Each type of event will have a unique value. This will enable reports to query using
the numeric value instead of the event name, greatly increasing the speed of queries
that report on specific events.
4 Production Reports
The following sections illustrate how with ICONICS BizViz applications, namely ReportWorX™
and Alarm Analytics™, one can create a robust and scaleable data collection and reporting
system that can be easily deployed to many facilities.
Unified ReportWorX w/
Web Interface Alarm Analytics Option
OPC Client Interface Using a Common Register Naming Convention for All Events
DataWorX32
Specific Control System Addressing
OPC INPUTS OPC INPUTS OPC INPUTS
6 Application Overview
The following sections illustrate how with ICONICS GENESIS32 and BizViz Applications one can
create a robust and scaleable Downtime data collection and reporting system that can be easily
deployed to many facilities.
There is also a Related Values tab for associating additional values to a certain Event. When
used is conjunction with the AlarmWorX32 Logger these related values can then be reported on
and filtered on.
Many automated lines have hundreds or even thousands of stoppages per week. It is not
practical to involve operators in every one of these events. By utilizing ICONICS AlarmWorX32
Logging for downtime event data capture and ICONICS ReportWorX for downtime reporting,
pertinent information can selectively be filtered and distributed to plant operators as necessary.
ReportWorX is a powerful, advanced reporting tool based on Microsoft Excel that is easy to
learn and can integrate information from any data source, including popular HMI, SCADA, MES
and control systems. The ability of ReportWorX to connect to real-time OPC data in addition to
databases such as SQL, Oracle, SAP, AspenTech, OSI PI and more, makes it the perfect
compliment to the GENESIS32 data collection products for advanced Downtime Analysis.
ICONICS offers the following pre-configured templates as part of its Downtime Analytics module,
or customize your own templates with ReportWorX’ easy-to-use data mining wizards:
ICONICS’ Alarm Analytics product enables plant personnel to Visualize, Analyze, and Manage
alarm information in accordance with the industry’s best practices. It is based on EEMUA and
OSHA alarm management specifications, and therefore ensures proper analysis of alarms and
events in a manufacturing plant. That analysis can reveal significant opportunities for improving
current operations and mitigating abnormal situations. The ICONICS Alarm Analytics module
captures and analyzes all alarm and event information to identify frequent alarms, chattering
alarms, cross-correlated alarms, and many more alarm-related issues. This module also records,
analyzes, and displays operator-initiated process changes, which then yield significant insight
into the performance of the entire system.
In addition to the insightful reports that are provided as part of ICONICS ReportWorX, you can
leverage Alarm Analytics to perform an in-depth analysis of events generated by ICONICS
AlarmWorX32. Here are some of the pre-configured industry standard templates that you can
take advantage of as part of your Downtime Reporting package:
7 Summary
The previous sections illustrated how ICONICS GENESIS32 and BizViz applications can be used
to create a robust and scaleable data collection and reporting system that can be easily
deployed to many facilities.
A Cost-Effective Solution
Many automated lines have thousands of stoppages per week. It is not practical to involve
operators in all of these events. Using the tools provided as part of the ICONICS BizViz Suite of
Manufacturing Intelligence products a broad list of capabilities are provided at a fraction of the
cost associated with comparable customer solutions, especially when the cost of supporting
these custom applications is considered.
• Logic is configured directly within the BizViz and GENESIS32 Suite of products, thus
allowing consolidation of configurations at an ideal level for each situation, as opposed
to many configurations defined in distributed hardware controllers such as
programmable logic controllers, distributed control systems or other remote devices.
• This solution works with existing software and infrastructure. There is no need to
replace existing data collection systems, HMIs or control systems.
ICONICS is leading the way in cloud-based solutions with its HMI/SCADA, analytics,
mobile and data historian to help its customers embrace the Internet of Things (IoT).
ICONICS products are used in manufacturing, building automation, oil & gas,
renewable energy, utilities, water/wastewater, pharmaceuticals, automotive and
many other industries. ICONICS’ advanced visualization, productivity, and
sustainability solutions are built on its flagship products: GENESIS64™ HMI/SCADA,
Hyper Historian™ plant historian, AnalytiX® solution suite and MobileHMI™ mobile
apps. Delivering information anytime, anywhere, ICONICS’ solutions scale from the
smallest standalone embedded projects to the largest enterprise applications.
Italy UK India
Tel: 39 010 46 0626 Tel: 44 1384 246 700 Tel: 91 22 67291029
Email: [email protected] Email: [email protected] Email: [email protected]
www.iconics.com
© 2015 ICONICS, Inc. All rights reserved. Specifications are subject to change without notice. AnalytiX and its respective modules are registered trademarks of
ICONICS, Inc. GENESIS64, GENESIS32, Hyper Historian, BizViz, PortalWorX, MobileHMI and their respective modules, OPC-To-The-Core, and Visualize Your
Enterprise are trademarks of ICONICS, Inc. Other product and company names mentioned herein may be trademarks of their respective owners.