Using Information Technology to Gain a Competitive Advantage
In Discrete Manufacturing
By
Jason E. Seay
B.E. Mechanical Engineering, Vanderbilt University, 1993
M.S. Mechanical Engineering, University of California-Irvine, 1995
Submitted to the Sloan School of Management and the
Department of Civil and Environmental Engineering
in Partial Fulfillment of the Requirements for the Degrees of
Master of Business Administration and
Master of Science in Civil and Environmental Engineering
In Conjunction with the Leaders for Manufacturing Program at the
Massachusetts Institute of Technology
June, 2003
@ 2003 Massachusetts Institute of Technology
All Rights Reserved
Signature of
Author
Jason E. Slay
of
Sloan School Management
Department of Civil and Environmental Engineering
May 9th 2003
Certified
by
Don Rosenfield
Senior Lecturer of Management, Sloan School of Management
Thesis Supervisor
Certified
by
Associate Professor, Department of C'vil andE
Jol;i(Williams
ironmental Engineering
Thesis Supervisor
Accepted
by
Oral Buyukozturk
Engineering
Environmental
and
Department of Civil
Chairman, Department Committee on Graduate Studies
Accepted
by____
Margaret Andrews
Sloan School of Management
Director, Master's Program
MASSACHUSETTS INSTITUTE
OF TECHNOLOGY
AUG 0 4 2003
LIBRARIES
BARKER
(This Page Left Intentionally Blank)
2
Using Information Technology to Gain a Competitive Advantage
In Discrete Manufacturing
By
Jason E. Seay
Submitted to the Sloan School of Management and the Department of Civil and Environmental
Engineering on May 9 th, 2003 in partial fulfillment of the requirements for the degrees of
Master of Business Administration
And Masters of Science in Civil and Environmental Engineering
ABSTRACT
The use of computers has inextricably altered the process of manufacturing in every company in
every industry. These changes began with the introduction of word processors and
spreadsheets and have developed into enterprise and collaborative software systems which are
capable of linking the entire supply chain. While the majority of effort to date has focused on
Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), and Supply
Chain Management (SCM), the arena of Manufacturing Execution Software (MES) presents a
unique opportunity for development. ERP focuses on what has happened within an
organization, while CRM and SCM analyze what is going to happen. MES systems provide the
critical link to what is happening right now. The delivery of this real time production information
will enable tremendous benefits in terms of operating efficiencies in the future.
The current work focuses on the MES space and the possibilities for software development in
this space. The work specifically examines a variety of software applications being developed
at ABB, which are attempting to enable real time information from the shop floor. An
assessment of the required functionality for a basic MES application was completed and a new
direction was defined. This new direction centers on the development of broadly applicable
software. To broadly apply software, a particular application must be customizable in order to
meet a variety of customers' requirements. Based on a software project implemented at
Ratingen Germany, the current work explored new methods for linking software systems. A
new application for connecting the shop floor to enterprise level systems, termed Cell Manager,
is presented. This application should be considered a generic software application which could
be applied to any factory.
Additionally, the work presents a new methodology for developing software within ABB. This
new methodology is focused on the use of web services for development of a next generation
MES system. A method for utilizing web services to create MES applications is presented and
defined.
Thesis Supervisor: Don Rosenfield
Title: Senior Lecturer of Management
Sloan School of Management
Thesis Supervisor: John Williams
Title: Associate Professor
Department of Civil and Environmental
Engineering
3
ACKNOWLEDGEMENTS
First and foremost, I wish to acknowledge the Leaders for Manufacturing program at
MIT for supporting this work. The knowledge that this program delivers is unmatched at
any university in the world.
I must also thank ABB and specifically Mika Kuhmonen and Rafael De-Jesus for
sponsoring my internship.
A host of other people at ABB must also be acknowledged. First, Mark Shaw assisted
me from day one and without him I would have never succeeded. There are too many
reasons to list why I am happy that he is a friend. Next, Joni Rautavuori kept me
focused on lean processes and fed me well. Johanna Finskas provided endless
amusement around the office. I must thank Petri Isotalo for being a great friend and
confidant. And finally, I must thank my LFM partner, Roland Sargeant, who made my
first three months there great.
I wish to also thank my thesis advisors, Don Rosenfield and John Williams, for their
tremendous support, advice and thoughts throughout the entire process.
Finally, I wish to dedicate this thesis to my parents, Bill and Rosina. They have offered
complete support throughout every endeavor of my life and I will be eternally grateful for
this.
4
TABLE OF CONTENTS
A B S T R A C T .........................................................................................................................
3
ACKNOW LEDGEMENTS ..............................................................................................
4
TABLE OF CONTENTS ...................................................................................................
5
L IST O F TA B LE S ................................................................................................................
6
LIST OF FIGURES.......................................................................................................
6
1.0
INTRODUCTION ..............................................................................................
1.1
The Use of Software in Manufacturing Environments ...................................
1.2
Scope of Current Thesis...............................................................................
1.3
ABB Attempts Software Development.........................................................
1.4
Project History .............................................................................................
2.0
BACKGROUND ...............................................................................................
2.1
ABB and Industrial IT ...................................................................................
2.1.1
W hat is Industrial IT?.............................................................................
2.1.2
W hat is the Aspect Integrator Platform?...............................................
2.2
The Layers of Manufacturing Software.......................................................
2.2.1
Collaborative Software Systems ...........................................................
2.2.2
Enterprise Resource Planning (ERP/MRP)..........................................
2.2.3
Device-Level Software Systems............................................................
2.2.4
Manufacturing Execution Software (MES) Systems..............................
2.3
Discrete vs. Process Manufacturing ...........................................................
7
7
8
10
12
17
17
18
21
28
28
35
41
45
49
3.0
52
3.1
3.2
4.0
MES DEVELOPMENT AT ABB ..............................................................................
Distribution Transformer Project - Lodz.......................................................
Embedded Pole Project - Ratingen .............................................................
52
55
GENERALIZATION OF SOFTWARE SOLUTIONS ........................................................
59
4.1
Cell Manager / Line Manager Development ................................................
4.1.1
Cell Manager 2.0 ..................................................................................
4.1.2
Line Manager 1.0 .................................................................................
4.2
W eb Services Model ...................................................................................
4.2.1
W hat are W eb Services?.......................................................................
4.3
Using W eb Services for Customizable MES Software .................................
5.0
5.1
5.2
5.3
5.4
60
62
65
67
68
71
CONCLUSIONS AND RECOMMENDATIONS ...............................................................
74
The Business Value of IT in Manufacturing ................................................
Creating Generic Software ...........................................................................
Creating Lean Software................................................................................
W eb Services as an Alternative..................................................................
74
75
77
78
APPENDIX A: DATA MODEL FOR CELL MANAGER 2.0............................................ 80
APPENDIX B: FUNCTIONAL REQUIREMENTS OF ABASIC APS PACKAGE ............
81
R E F E R E N C E S ..................................................................................................................
97
5
LIST OF TABLES
Table
Table
Table
Table
Table
1:
2:
3:
4:
5:
Current OPC standards. [21]......................................................................
MES interactions with other systems. [23]..................................................
MES functions as described by MESA. [22].............................................
Simplified data model for Cell Manager 2.0................................................
18 initial functions for Line Manager 1.0....................................................
44
47
48
65
66
LIST OF FIGURES
Figure 1: Advancements in processing speeds and storage space. [1]...................... 8
Figure 2: Shrink-wrap application example for ABB's discrete MES offering. ........... 10
Figure 3: Aspect Integrator Platform [3]....................................................................
12
Figure 4: Hoag Example of WIP Tracking at Transformer Factory [4]....................... 13
Figure 5: Distribution Transformer Project Schematic [5]......................................... 15
Figure 6: Embedded Pole Operator Screen [6]........................................................ 16
Figure 7: Integration of systems utilizing Industrial IT [3]......................................... 20
Figure 8: Switchgear object and its aspects (attributes). [11]................................... 23
Figure 9: Object modeling of substation. [11]...........................................................
24
25
Figure 10: Functional structure of a reactor system. [11] ........................................
Figure 11: Location structure within AIP. [11]........................................................... 26
Figure 12: AIP Development architecture [12].........................................................
27
Figure 13: Flow of information and goods in the supply chain. [14]......................... 32
Figure 14: Supply Chain Data Exchange Points. [15].............................................. 33
Figure 15: Schematic of MRP. [17] .........................................................................
36
40
Figure 16: M R P II Schem atic. [17] ..........................................................................
Figure 17: Device-driver concept with proprietary software. [20]............................. 43
Figure 18: MES and its interactions with various systems. [22]................................ 45
Figure 19: Discrete vs. Process Industries. [23]...................................................... 50
Figure 20: MES Functions with discrete and process spaces. [23].......................... 51
Figure 21: Distribution Transformer Project Overview. [24]...................................... 53
Figure 22: Devices connected to Ratingen workplace software ...............................
56
62
Figure 23: C ell M anager G U I. [25] ..........................................................................
Figure 24: Example Line Manager GUI...................................................................
67
Figure 25: Web service interactions. [28]................................................................. 70
71
Figure 26: Utilizing web services for MES applications. ............................................
73
Figure 27: Running MES through a web browser....................................................
Figure 28: Business Value of IT. [29].....................................................................
75
6
1.0 INTRODUCTION
1.1
The Use of Software in Manufacturing Environments
The development of the personal computer (PC) has dramatically changed the
face of manufacturing operations. Both the speed and the storage capabilities of
personal computers have increased at an incredibly fast pace. Since the 1970s,
processor speeds have increased by over 1,000 percent and storage capabilities have
increased by a factor of 10
9
[1]. Figure 1 below demonstrates the rapid advancements
achieved in these two areas. These improvements in hardware have allowed software
developers to create more advanced user interfaces, which attempt to automate
processes and improve efficiency. The first software tools allowed businesses to
transition from typewriters to word processors. Additionally, spreadsheets improved
efficiency with accounting and large, engineering calculations. However, during the
1980s, the advent of powerful servers enabled computers to become more broadly
applied. The processing speeds of these servers could handle calculations for an entire
company. This led to an explosion in Manufacturing Resource Planning (MRP)
software. These MRP systems were utilized to store a variety of information from Bills
of Material (BOM) to on-hand inventories to vendor information. As MRP systems
developed, additional functionalities were included to handle accounting, human
resource, and financial functions. This gave birth to Enterprise Resource Planning
(ERP) eftware , whichis now commonplace in manufacturing companies. In today's
world, software associated with the Internet is dramatically improving methods by which
companies can communicate. Software tools such as the eXtensible Markup Language
(XML), Java, and Web Services enable a host of new concepts within the manufacturing
7
world. As software standards continue to develop, manufacturing operations will be
capable of relying on software to an ever increasing degree. Research for the current
work was centered on the development of Manufacturing Execution Software (MES)
within the discrete manufacturing arena. Both of these terms will be further explained in
the following sections.
10122000
*01
01800
1010-
00
16
1400
.
S*g
109
.2
108C
'OC1200
G
S 10oo
MR
107-
1 30
~0
1960
1970
1980
1990
2000
1970
1975
Figure 1: Advancements in processing speeds and storage space
1.2
1980
1985
1990
1995
2000
[1]
Scope of Current Thesis
Over the course of seven months, research was conducted at the ABB Corporate
Research Center in Finland (Vaasa, Finland). The focus of this research was in the
application of software tools to the factory floor, as part of ABB's new initiative termed
Industrial IT. The thesis project was broken down into three major areas of research,
which are listed below.
*
Understanding the benefits of Manufacturing Execution Systems (MES)
*
Understanding how ABB's Industrial IT initiative can be utilized within the MES space
*
Initiating the development of a commercially available MES product
The first stepvas centered on gaining a better understanding of MES systems
and the required functionality of a commercially available MES product. A well-defined
8
specification for an MES product was completed in August by Roland Sargeant, a
previous LFM intern [2]. Therefore, the majority ofmy work in this area focused on the
ability to incorporate lean processes into a software program to improve the value
proposition to the customer. Additionally, my research identified the appropriate method
for productization of a MES system within the ABB Corporation. The second phase of
the research project incorporated MES specification information and analysed the
method through which ABB's Industrial IT platform can be utilized to achieve lean MES
applications. This phase examined the ability of the aspect/object methodology in
modeling shop floor processes. The final area of research focuses on the initiation of a
commercially available MES product. This was accomplished by working with project
teams in Finland and Sweden, who were independently developing software tools to
interact with manufacturing workplaces.
The final phase of the thesis project primarily
focused on assisting these groups in defining the next generationsoftware solution for
manufacturing workplaces. The goal was to specify a product that is applicable to any
manufacturing cell within any industry. Figure 2 below depicts a typical "shrink wrap"
application to be developed as part of this project.
9
Figure 2: Shrink-wrap application example for ABB's discrete MES offering.
1.3
ABB Attempts Software Development
In 1988, the merger of Asea and Brown Boveri created Europe's second largest
engineering group with yearly revenues in the $20 to $30 billion range. The company is
10
split into three major divisions: Power Technologies, Automation Technologies, and Oil
and Gas solutions. However, the primary focus of the company lies in the power and
automation groups. In fact, the oil and gas division is currently up for sale, as ABB
strives to refocus on its core capabilities. The power technologies division sells
products such as distribution transformers, switches, circuit breakers, and inverters.
The automation division is most renowned for delivering high quality robotic solutions as
well as motors, drives, and actuators.
In an effort to integrate their products with a common software platform, ABB has
recently (late 1990s) launched an effort to develop a major corporation-wide program
termed Industrial IT. The concept behind Industrial IT is to develop a combination of
software products and IT enabled devices such as motors, switchgears, robots, and
other electrical equipment. By focusing both on products and software, the company
hopes to provide customers increased value by both delivering complete hardware
solutions and automating those solutions to provide real-time information from the shop
floor. The development of this idea has certainly followed an evolutionary strategy with
the original Industrial IT concept formulated within the process industries side of ABB.
In 1992, a software product, named Operate IT, was developed on Microsoft's COM
platform, which provided real-time information on plant equipment. Since that time, this
product has evolved into a software platform, termed the Aspect Integrator Platform
(AlP). This system utilizes a combination of objects and aspects for those objects.
Objects can be considered any piece of plant floor equipment, such as motors, mixing
tanks, or casting machines. Aspects store information for those objects, such as user
manuals, temperature data, maintenance logs, and other information. The AIP platform
11
then ties these objects together into a logical Windows Explorer framework. Figure 3
below presents a standard view from the AIP platform.
Loa Additive Warehouse
SolidProcessingBuding
ntermediate
Store
fo edsing devl
u
opi
, Functional Structure 10/6/98
A Location
Structure
Structure
10/6/98
10/6/98
e
OCS
.....
1 O/G/9 7:23:30 A14
10/6/98 7:23-30 AM 10/6/98 7:23:30 AM-7:23-30 AM
10/6/98
7:23:30 f A
10//98 7:23:30 A
7:23-30 AM
7:2a.30 AM
Control Room
-Laboratory
Process Room
Packaging
Building
%
LcThis pltfr
1.4 ui Proect
no
4
seve as th bai for al nusra
T eaesfwr
Huistory
Th urn
res ecttheo ooftAmn dvtuepme ntaisa
obc andME aspystemisacotnutono
wigr3
sAse IJneao
wogr
s:tase
inuegr20012 lafo1
bytfr Mihe[
byM[3]Ha
og34.A]enindpevosy
[]
smnind
rvosy
Asfucs
deve
ostoftheearly
developngthpatfmrojtes fusd
solutions
h
h
ithinparoce
lopmert ofwIsdustsial ITeandsAsPfbrgan withintthe prTcessaindusre sidwaefAB
development.
Becanusrae
id usreschi
H
y
Ascusued os o
th
or AP beeganpting
g
prfoss andoutins, stdwo
a developin h ltomwe poterts bousd
solutions
th
ABB.nc
n pratfo ss
industries, such as paper, oil, or consumer goods. However, Michael Hoag identified
12
the discrete manufacturing segment as a potential avenue for development. A further
description of the differences between discrete and process industries is provided in the
following section. Michael formulated a strategy for this new direction and then
proceeded to develop a series of concepts that demonstrated how IT could be applied
within the discrete manufacturing context. One example of his many concepts is
presented below as Figure 4.
Figure 4: Hoag Example of WIP Tracking at Transformer Factory [4]
This original work was completed within the Advanced Manufacturing
Engineering (AME) group, headed by Rafael De-Jesus. This group is primarily tasked
with process improvement projects and lean manufacturing implementations at factories
13
throughout the ABB group. The majority of projects are focused on the Power
Technologies side of ABB. Based on Michael's initial work, this group has begun to
acquire software development capabilities. Two projects are currently underway and
are attacking MES development from two very different directions. The first project, at a
distribution transformer factory in Lodz Poland, is closer to an enterprise-level MES
system. This work is attempting to link the sales process to the ERP system within the
plant. This project is also attempting to schedule orders at various factories and link to
shop floor operations. Figure 5 below demonstrates the aggressive project goals.
Further details about the scope and achievements of this project will be discussed in
Chapter 3.
14
AIP
ERP
OfferEntry
Design
TrafoNetl
-
FTaoe
TraoNet
Viewer
Machines
-OPC -
S
EDSM
AlP
SAP
SOAP
JCO
SOP
AP
Facade
ERP
Facade
SDesign
Facade
sign
SOAP
SOAP-
Offer
Facade-
9,7777
HTTP
TrafoNe
Bea
JSP
-77
Figure 5: Distribution Transformer Project Schematic [5]
The second project is tackling the MES development problem from the bottom up
by focusing on the transfer of information on the shop floor. This project, at an
embedded pole factory in Germany, provides process related information to workers on
the line. Each workstation in the process will be outfitted with a computer which has
been customized to provide the required information for that process step. Figure 6
below presents the "typical" operator screen displayed on the shop floor, which provides
15
information on process steps, components required, drawings, and other useful details.
Additionally, this project links workorders within the ERP system to individual
workstations. Again, further details on this project will be provided in Chapter 3.
9/92002
13.04
000070192062
GCE0000000R0101
000W70192M6
GCED00000R0101
Quantity:
Short Name of EP:
Short Name of VI:
15)
M murm80thcower
1P4S 2412-31
vG 4
Nomis VOaae
p
NOmme CUment
p96
SoaCent
pi
Product ID of Vi: IGCE70042MR0102
Figure 6: Embedded Pole Operator Screen [6]
While these plant specific projects are continuing, LFM interns have been utilized
to continue development of a generic MES product that could be easily implemented at
a variety of factories. The initial work in this area, completed by Roland Sargeant, was
centered on four major areas: Project Definition, Project Feasibility, Product
Development, and Product Commercialization. Project definition included identifying
the requirements of a generic MES product and the emerging trends within this industry.
The feasibility of the project was assessed by examining the competitive space and the
resource base within ABB. The product development work revolved around appropriate
development processes, the overall strategy, and apparent risks in development.
16
Finally, the commercialization plan spelled out various product attributes such as the
maintenance plan, pricing, and training. The work described above set the foundation
for all topics discussed in the current thesis.
2.0 BACKGROUND
The previous section introduced a variety of concepts and terminology related to
the use of information technology in a manufacturing setting. This included terms such
as ERP, MES, Industrial IT and others. The goal of the background section is to
provide further detail for each of the terms in order to provide the reader a solid
understanding of the final results. This section begins with an overview of Industrial IT
and the Aspect Integrator Platform. Next, the various pieces of software, currently in
use in manufacturing facilities, will be discussed. The final section describes the
differences between discrete and process manufacturing, as well as the application of
an MES product in each of these spaces.
2.1
ABB and Industrial IT
ABB is primarily a producer of products. It is difficult to determine a single focus
of the company, as itsproduct lines ex tend into control products, instrumentation,
motors, drives, robotics, valves, and actuators. However, the company is best known
for its wide array of electrical transmission equipment. These products include circuit
breakers, surge arrestors, capacitors, transformers, fuses, switches, vacuum
interruptors, and a host of other products. Therefore, the foundation of the company
centers on a variety of low margin (i.e. commodity) products. ABB's profit margins
signal this focus with net income averaging 2-4% of sales [32]. In an attempt to improve
17
profit margins, a strategic initiative, named Industrial IT, was developed. The goal of the
new initiative was to develop a set of software products to complement the company's
commodity product offerings. An example of this would be to not only provide
components for a power sub-station, but also the software to control that station. By
offering a complete service, ABB hopes to improve its profit margins.
2.1.1
What is Industrial IT?
The term Industrial IT is ambiguous and could certainly be applied to any
application of computers within any industrial setting. Clearly, Microsoft's definition of
Industrial IT will differ from GE's, which will again differ from ABB's. The following
section attempts to define what the term Industrial IT means within ABB. In its simplest
sense, Industrial IT is considered the enabling and integration of information across an
enterprise. The ultimate goal of the program is to develop a set of intelligent products
and re-useable applications which can be applied in any industrial factory. In fact, the
Industrial IT initiative is split between the development of products and software
solutions.
On the product side, the concept of 'plug and produce' is often utilized when
describing Industrial IT. This concept is similar to current standard practice within the
computer industry. For example, when purchasing a printer, the device includes all the
fonts and other drivers for use. When the printer is connected to the computer, all of the
required information is transferred, and the printer should work seamlessly. The
Industrial IT concept hopes to extend this vision to the entire line of ABB products. To
standardize the development of Industrial IT enabled products, a framework has been
18
defined to establish various levels of functionality. The four Industrial IT certification
levels for products are presented below [7].
Information (Level 0): To become Industrial IT Level 0:
Information enabled, a product must have the following aspects:
- Product Identification
- Product documentation:
1. Product data sheet or technical reference manual
2. Installation and commissioning manual
3. Application manual
4. Operating manual
5. Maintenance and service manual
6. Declaration of conformity regarding CE marking
7. Environmental product declaration
8. Environmental information
- CAD Data
- Technical data and product classification
Connectivity (Level 1): Having Level 1 certification means that the product can be
connected to and work well in an Industrial IT system. This means that the product has
all the level 0 characteristics, plus:
- Hardware can be physically connected via defined and approved
interfaces.
- Software can be installed and handled in a consistent manner.
- The product does not introduce disturbances to the environment in which
it is inserted.
- Basic data can be exchanged via defined protocols.
Integration (Level 2): As well as having all the characteristics of levels 0 and 1, a
product that is level 2 certified will also guarantee that:
- Extended data (status, maintenance, etc) can be exchanged via defined
protocols.
- Aspect System functionality is available.
Optimization (Level 3): Certification to level 3 means that a Pnduct, when integrated
into an Industrial IT system, is capable of all Industrial IT functionality.
As of April 2, 2003, the ABB website displays that 35,833 products have
achieved at least the Level 0 certification level. While the number of products achieving
levels of certification above 0 has been limited [8], ABB continues to initiate programs to
further develop the existing products into higher certification levels.
19
On the software side, Industrial IT refers to the real-time transfer of information
across an enterprise. Currently, in most manufacturing environments, information is
stored in a variety of systems which are not capable of communicating with one
another. Industrial IT hopes to integrate this information so that it can be delivered to
the right person at the right time. Figure 7 below presents the concept of data
integration, utilizing Industrial IT. As seen in the figure, information can be broken down
into a variety of levels, extending from enterprise-wide data down to data for a specific
device. Most enterprise-level data is typically stored within ERP systems, provided by
companies such as SAP or Oracle. When approaching the device layer, information
could be stored in databases or files or within a maintenance manager's desk.
SAP, i2, Baan,
t
Oracle
SAP, i2, Baan,
Oracle, IBM
E
Manugisitics,
Honeywell,
Ariba
Honeywell,
Invensys,
Siemens, ABB,
etc.
Figure 7: Integration of systems utilizing Industrial IT [3]
This transfer and integration of data can come in many forms. In fact, any
software application that communicates with industrial equipment or shop floor
20
processes is classified as being Industrial IT enabled. Within ABB, this included a host
of custom visual basic applications and other software which had been developed prior
to the Industrial IT initiative. However, to better define the term Industrial IT on the
software side of the initiative, ABB developed a common platform to standardize
Industrial IT software solutions. This common platform (or architecture) is termed the
Aspect Integrator Platform ad will be discussed in the following section .
Further, to
better organize these software solutions, ABB has defined 30 functional categories to
allocate each solution. Rather than describe all 30 categories, a representative sample
is listed here: Design'T , InformT, OperateT, ProduceT, Optimize T , and ProteCtIT
Products and software, within the Operate' T folder, would focus on the human-machine
interface.
In summary, the term Industrial IT includes products that meet the certification
requirements defined above and software solutions that utilize the Aspect Integrator
Platform as a basis for development.
2.1.2
What is the Aspect Integrator Platform?
As mentioned previously, the development of the Aspect Integrator Platform
(AIP) began in 1992 with the release of OperatelT. This product was originally
designed to model production equipment in the process industry. For example, the
software could be customized to display a variety of equipment, such as tanks, valves,
and actuators, within a production line. Data associated with this equipment could then
be displayed via links within the software. Since that time, the product has evolved into
the foundation for all Industrial IT software products and has been renamed AIP.
Currently, an entire team of engineers continues to develop further functionality for the
21
product. For example, there are presently two versions of the software; a thick client
allowing 10 concurrent users and a thin client allowing unlimited users. The AlP
development group continues to refine the product based on the needs of the software
developers who are creating applications on top of the platform.
The AIP software is based on objecto riented programming. The concept of
object oriented programming began back in the mid 1960's with the development of the
first object oriented language, SIMLUA, by Ole-Johan Dahl and Kristen Nygaard [9].
However, this programming technique has only recently gained recognition with the
increasing use of languages such as C++ and Java. Object oriented design is based on
the hypothesis that the more closely a program models its real world counterpart, the
more stable the program will be. The steps in object oriented design are [10]:
" Identify the objects and their attributes
" Determine what can be done to each object
" Determine what each object can do to other objects
" Determine what parts of each object will be visible to other objects
" Define each object's public interface
When referring to development at ABB, it is important to make the distinction
between object-oriented-design within the context of AIP and other development on top
of AIP. The AlP platform itself relies completely on this method of design. All elements
within AIP are classified as objects with a specified set of attributes. However, typical
software projects utilizing AIP rarely employ object oriented design. For example, the
Ratingen project (the German project previously identified) is using the structured
22
design philosophy for development. Further details of this distinction are provided in
Section 3.2.
To better describe the AIP platform, one must first start with objects. As
mentioned previously, object oriented design attempts to take real world objects and
model them. Each object will then have a set of attributes. Within ABB, these attributes
are classified as aspects. A good example of how AIP pulls together a series of objects
is obtained by examining a switchgear operating inside a power substation. Figure 8
presents a switchgear (the object) with a variety of information (i.e. aspects) associated
with it. As seen in the figure, information such as test reports, mechanical drawings,
and technical specifications, all describe the object. As more information becomes
available, it can be attached to this object as a new aspect. For example, maintenance
reports for the device could be generated and attached to this object at a later time.
While there might be hundreds of switchgears in one substation, object oriented
programming makes this particular switchgear a unique object within the plant.
Describing this device in the software code as a unique object provides tremendous
flexibility to a software designer.
Technical Spec.
Mech. Drawing
Elec. Diagram
Simulation Model
Control Program
Test Report
Figure 8: Switchgear object and its aspects (attributes). [11]
23
Now, this switchgear operates as one piece of machinery within the entire
substation operations. Within the context of AIP, this substation will be abstracted as a
combination of hundreds of objects. Figure 9 presents a schematic example of this
arrangement. Each object in the facility will have appropriate aspects attached to it and
can be allocated to larger subsystems. For example, the switchgear could be allocated
to a group termed transmission equipment or described by its location (i.e. Room 121).
Each physical object within the substation will be represented as a virtual object within
AlP.
Power System
Installation
Aspect
Object
Aspect Object
Model
Figure 9: Object modeling of substation. [11]
One of the primary benefits of AIP is that it provides some structure to these
hundreds of objects associated with one installation. It accomplishes this task by
grouping objects into larger subsystems. In fact, AIP can be setup to offer any number
24
of structures to a potential user. Two of the more useful structures are the functional
structure and the location structure. Figure 10 presents an example of a functional
structure for a reactor. The functional structure associates objects with the systems to
which they are attached. Three levels of abstraction are presented in the figure. The
highest structural level that is presented is the reactor. Obviously, this level is a few
steps down in the overall hierarchy of the plant. Below the reactor level, two additional
subsystems are presented (heating and draining). Finally, within the heating level, we
reach a layer of abstraction that actually includes a physical object (valve) which can be
modeled. Of course, lower levels of abstraction can also be included on the heating
layer. For example, the temperature control layer isn't an object itself but could contain
a variety of different objects. Using this hierarchical structure, the user or programmer
is capable of finding any desired object.
II
Reactor I
Ti,
Reactor,.-,
-1
Heating I
Valve 1.1
Temp control
4MVI1.1
PID 1.1
Out 1.1
Draining I
Heating
System
I
I
Reactor 2
I
Heating 2
Valve 2.1
Temp control 2
MV 2.1
PID 2.1
Out 2.2
Valve
Draining 2
Figure 10: Functional structure of a reactor system. [11]
25
Additionally, the AIP platform allows one to view objects via a location structure.
Figure 11 presents this concept as it would appear to a user running AIP. The top layer
of the location structure is the Milko Chemical Plant. This plant has a variety of different
locations, such as the additive warehouse, the solid processing building, and others.
These locations then have sub locations. For example, the liquid processing building
contains a control room, a laboratory, and a process room. Each of these rooms will
then contain individual pieces of equipment and the structure will begin to resemble the
functional structure described above. For example, the process room could contain a
reactor that might have a variety of objects attached to it.
i
j
j
Additive Warehouse
Solid Processing Building
Intermediate Store
SMilk Silos
j
Liquid Processing Building
Control Room
j Laboratory
Process Room
E,
Product Silos
Packaging Building
+
s
Figure 11: Location structure within AIP. [11]
26
The AIP platform described above now serves as a platform for further software
development. AIP has been designed to function with a host of other software
programs, such as Visual Basic and C+. This then allows developers to create
applications that utilize data stored in each object. Development of tools to improve
manufacturing operations is now the primary focus of ABB's Industrial IT program.
Figure 12 depicts the concept of developing applications on top of AIP. The program
AIP itself was built on top of Window's COM technology, which handles many of the
lower level computing operations of the program. Within AIP, a variety of standard
object types has been created and serves as a library for developers to utilize. Above
this layer, developers utilize Visual Basic and C+, as well as other programming
languages, to create new solutions. A few of the applications which have been created
are shown in the figure. Utilizing this architecture, ABB is currently attempting to enter
the Manufacturing Execution Software space with a new product offering.
Solution Folders
Solutions
Technology
Figure 12: AIP Development architecture [12]
27
2.2
The Layers of Manufacturing Software
Within a given manufacturing facility, a myriad of potential software applications
can be utilized to get product out the door. These applications can include everything
from million dollar enterprise-wide systems to simple, custom Visual Basic programs.
For the current project at ABB, the development is focused on the Manufacturing
Execution Software space. In order to understand how this fits into other plant systems,
the following section describes in detail, the myriad of software offerings utilized within
manufacturing. The section begins at the very top of the software food chain,
collaborative software systems, and works down to software associated with various
devices on the shop floor. The section concludes with a description of how
Manufacturing Execution Software is capable of bridging the gap between collaborative
software and devices.
2.2.1
Collaborative Software Systems
The term, collaborative software, is fairly general and can be utilized to describe
a great number of software products. However, this term is typically associated with
three major software areas: Customer Relationship Management (CRM), Supply Chain
Management (SCM), and E-Commerce. A further description of each of these areas is
provided below.
Customer Relationship Management (CRM)
The basic premise of any CRM system is to learn more about customer's needs
and behaviors in order to develop stronger relationships with them. These improved
relationships should then translate into higher customer satisfaction and increased
revenues. CRM systems achieve this goal by focusing on three, main objectives:
28
" Acquire new customers
"
Retain the right, existing customers
"
Grow the relationship with existing customers
The business processes that are primarily impacted by a CRM solution are the
marketing, sales, and service organizations. This is fairly obvious as these
organizations are any company's primary contact with customers. The CRM space can
be split into three main areas of functionality: customer-facing applications, customertouching applications, and customer-centric intelligence gathering [13].
Customer-facing applications include contact center support, sales force
automation, and field service automation. Within a contact center, CRM applications
will assist by providing information for both incoming (teleservice) and outgoing
operations (telemarketing and telesales). These applications provide everything from
customer order histories, leads, and prospects to quotes, customer requests, and
product information. Sales force applications support the selling efforts of a company's
salesforce by managing leads, prospects, and personal customer information
throughout the sales cycle. Field service automation systems support customer service
efforts for a variety of personnel. This type of application will manage information such
as customer service requests, service orders, service contracts, service schedules, and
service calls. Many of these applications are centered on efficient planning, scheduling,
dispatching, and reporting for a group of service representatives.
Customer-touching applications include functions such as campaign
management and self-service customer support. Campaign management systems
typically automate a marketing campaign. They accomplish this task by providing
29
leads, contacts, and on demand customers via automated email lists, call center data
and direct mail databases. Additionally these systems should be capable of providing
analysis on the effectiveness of a specified campaign. Self-service customer support
applications allow customers to access a variety of information including product
support instructions, service requests, and order management. An excellent example of
this type of system is UPS's on-line shipment tracking system. This system saves UPS
millions of dollars by automating this aspect of customer service.
Customer-centric intelligence applications are required to both store and
analyze customer information. These applications include customer data warehousing,
reporting, and analytical functions. Data warehousing refers to systems which capture
and store customer data for later use. This is a tremendously complex function for CRM
applications as it serves as the foundation and must provide efficient access to huge
amounts of data. Reporting applications include software to extract data and present
both tabular and graphical data. Analytical functions are utilized to automate the
reporting process. Analytical applications actually process warehoused data, whereas
reports merely present the data. This includes functions such as detecting customer
requests, providing insight on customer behavior, and forecasting response to
marketing, sales, and service initiatives.
Additionally, the CRM space is rapidly changing as new technologies become
available. The first CRM applications were designed to work on large internal servers
that limited the flow of information within companies. Software to access any CRM data
had to be installed on each individual's computer. Currently, most CRM vendors
provide Internet access to their entire range of functionality. This provides much
30
improved distribution of information and greater possibilities for functionality. However,
the future of CRM applications will be completely altered by the introduction of web
services. Many CRM companies are currently developing web service functionality that
will allow customers to select specific functions that are most appropriate for their
business.
Supply Chain Management (SCM)
The term Supply Chain Management (SCM) can potentially involve a wide
range of activities. Therefore the following section will provide a simplified view of the
major aspects of SCM and related IT concepts. This will be completed to again
demonstrate the potential interactions with Manufacturing Execution Software and the
benefits afforded by this interaction. Figure 13 presents the two types of information
flow within a SCM system, interfirm and intrafirm [14]. This figure demonstrates one of
the primary goals for SCM: to seamlessly link the point of production to the point of
delivery. This section will begin with a further discussion of the goals of SCM and then
move on to the various elements that comprise an SCM system. Finally, the section will
conclude with a discussion of the IT technologies that are utilized by SCM applications.
31
I
_
I
Product Flow
-
I
_
Suppliers
I
Manufacturers
Warehouses
I
Retailers
Information Flow
ISInterfirm
,+
Intrafirm --
+.
-Interfirm-+
Figure 13: Flow of information and goods in the supply chain. [14]
Delivering the right piece of information to the right person at the right time is
central to SCM. As such, the three primary goals of supply chain information
technology revolve around data. These goals are listed below [14].
" Gather information on each product from pre-production to delivery and
provide complete visibility to all players.
" Provide a single point of contact for all data within the system.
* Analyze, plan, and suggest tradeoffs based on information from all
sources.
Based on the current available technologies and status of companies, these
goals are very difficult to achieve. Most companies utilize a variety of systems which
could include data wrapped in proprietary databases. This lack of data structure
standard severely limits the ability of a SCM system to gather information across the
various systems within the supply chain. This fragmentation also limits the ability to
serve up all information from a single point of contact. Information will reside on a
32
myriad of systems and complete integration into a single contact point would require
endless links. Even SCM software itself is very fragmented. Software tools for any
number of needs have been developed. This limits the ability to analyze and plan while
still considering the entire system. For example, would the inventory management
application be capable of communicating with the demand forecasting application? If
not, then the inventory management system will be operating with less than optimal
data and could yield a faulty analysis. Since this lack of communication severely limits
the effectiveness of SCM, an enormous amount of effort is placed into methods for
communicating, storing, and retrieving data.
As mentioned above, SCM software is tremendously fragmented, with
hundreds of small applications available for handling any number of needs. The
following section attempts to describe some of the major areas of development. Figure
14 below segments these areas of functionality into the following five major categories:
Suppliers, Procurement, Production, Logistics, and Customer [15].
Enterprise
Suppliers
Procurement
Production
Logistics
Purchasing
Planning
n
Planning
Parts Mg
G DFinished
Materials
Sourcing
WholesalingDstribution
otealig
nd
IASchduieg
Goosb
'~Mgmnt
Customers
DelIvery
A and
and
CDeliveries
nstattiond
(
Support and
Services
Figure 14: Supply Chain Data Exchange Points. [15]
Within each of these categories, there are sub-sections with overlapping
categories. These areas are considered points of data exchange. Additionally, within
each sub-section, there are multiple programs for dealing with a host of issues. As it
would be very difficult to describe all in sufficient detail, we will provide an example by
digging into the sub-section of scheduling within production. From external research
33
[16], it was determined that approximately 117 different companies operate in the
advanced planning and scheduling software space. These companies sell applications
which provide everything from finite capacity scheduling and work-order dispatching to
what-if analyses for optimizing schedules. All told, there are approximately 30 different
pieces of functionality within the scheduling space.
As a summary, the list below presents some of the more common functions of a
SCM system. While this is not a comprehensive list, it does represent pieces of
functionality which should be considered critical pieces of any SCM software.
"
Demand Planning / Forecasting
"
Distribution Planning / Deployment
"
Inventory Management
" Transportation Management
*
Warehouse Management
The effectiveness of a SCM system is directly dependent on the ability of the
system to communicate up and down the supply chain. Some relatively new
technologies are assisting tremendously in this area. The face of supply chain
management will be completely altered as the standards associated with the eXtensible
Markup Language (XML) and Web Services become fully developed. Currently, both
the XML and Electronic Data Interchange (EDI) are allowing improved transmission of
data over the Internet. Additionally, technologies related to radio frequency
identification (RF-ID) and the Global Positioning System (GPS) are improving the ability
to track in real-time all parts and equipment.
34
E-Commerce
The concept of E-commerce should be readily understood by most readers at
this point. Therefore, a very limited discussion of this topic will be presented. In its
most basic sense, E-commerce is the buying a selling of products and services via the
Internet. Some of the premiere Internet retailers include Amazon.com and Dell
Computers. If properly connected to the right systems, E-commerce can improve the
efficiency and speed of responding to customer requests. In fact, E-commerce systems
can be utilized to provide customer preference data to CRM applications, as well as
demand forecasting data to SCM applications. E-commerce has impacted customers in
primarily two ways: improved information on products and services (i.e. both product
details and competitive alternatives) and improved access to products and services
(e.g. 24 hour, 7 day availability).
2.2.2
Enterprise Resource Planning (ERP/MRP)
As opposed to collaborative systems, traditional Enterprise Resource Planning
software is focused on the internal operations of a company. These software
applications have developed over time to include all aspects of running a business. In
fact, the first examples of enterprise software systems were solely focused on
Manufacturing Resource Planning (MRP). Since that time, these applications have
improved to include functions for handling financial information such as accounts
receivable/payable, the general ledger, purchasing as well as functions such as human
resources planning and payroll. However, for the current research, we will focus on the
development of MRP, as this piece of ERP software has significant interactions with
Manufacturing Execution Software. The following section describes the processes
35
completed by a typical MRP system. This perspective is important to fully understand
the benefits of utilizing an MES to improve information flow to and from the shop floor.
As mentioned previously, MRP systems came into existence in the early 1980s in
response to improved server capabilities. These first applications were primarily utilized
to manage the dispatching and organization of products. Figure 15 below provides a
schematic representation of the inputs and outputs of an MRP system. Further detail
for each element is provided.
On-Hand
Inventory
Item Master
(BOM)
Scheduled
Master
Receipts
Schedule
MRP:
Netting
Lot Sizing
Offsetting
BOM Exploding
Planned
Change
rerse
Notices
Exception
Notices
Figure 15: Schematic of MRP. [17]
First, any MRP system requires a set of inputs, typically from three sources: (1)
the item master file, (2) the master production schedule, and (3) the inventory status file
[17]. The item master file is a database, with part number as a primary key, containing
information such as a description of the part, bill of material structure, lot-sizing, and
36
planning lead times. The Master Production Schedule (MPS) provides a forecast of
demand for all final products. This demand will include requirements for all final
assembled products as well as lower level items, which could be sold as spare parts.
The MPS contains information on part number, quantity needed, and a due date for
each purchase order. The inventory status file provides information, sorted by part
number, for part location, and on-hand status. A final input to the MRP system,
scheduled receipts, are obtained from previous MRP runs. Once a purchase order or
manufacturing job has been released, a scheduled receipt is created within the MRP
system. In other words, a planned order release that has actually been released to the
floor is a scheduled receipt. Once that job is completed and the inventory file is
updated, the scheduled receipt for that part is deleted.
With the information provided above, the MRP system then completes five tasks
as described below [17].
1.
Netting: The MRP system obtains the gross requirements for zero level
BOM items from the MPS and calculates net requirements by subtracting the
on-hand inventory. For lower level items, the gross requirements are
obtained from previous MRP runs. For example, with zero scheduled receipts
and an on hand quantity of 30 units, an MPS gross requirement for 75 units
will net to a production requirement of 45.
2. Lot Sizing: This task takes the netted demand and divides it into appropriate
lot sizes to create new production jobs. The minimum lot size will dictate the
number of units that can be produced during one job. For instance, a certain
part might have a minimum lot size of 50 units to minimize setup time.
Therefore, when demand for that part exists, the MRP system will produce 50
units of that part. Demand for a part results in a planned order receipt, which
calls for one or more lots of parts on a specific date.
3. Time Phasing: This task simply requires two pieces of information: planned
order receipts for a given part and the lead time for that part. To determine
the production release date (or purchase order date), the lead time is
subtracted from the planned order receipt.
37
4. BOM Explosion: The system then determines the planned release dates for
all sub-components by exploding the BOM from the top down. Lead time
information on sub-components will once again come from the item master
database.
5. Iterate: The MRP system will continue to repeat these steps until the bottommost level of the BOMs for all demanded parts has been processed.
Once this has been accomplished, the MRP system then outputs three items: (1)
planned order releases, (2) change notices, and (3) exception reports. The planned
order release contains information on the part number, the number of units required,
and the due date. Once released, these become scheduled receipts. Change notices
indicate modifications to existing jobs, such as expediting or deferring. Exception
reports indicate the differences between what was planned and reality. These reports
can contain information on job count differences, inventory discrepancies, and other
actual events.
With an understanding of MRP operation, one can now better understand the
problems with the system. First, capacity infeasibility is a major limitation. MRP
systems base schedules on fixed lead times. Since this lead time does not take into
account the level of work in a plant, the system assumes that any and all production
lines will always have sufficient or infinite capacity. This assumption can result in large
problems, especially when a plant is operating at or near capacity [17]. This constant
lead time assumption also leads to pressures to increase planned lead times. For
instance, let us assume that the lead time for a specific part is on average 4 weeks with
a standard deviation of 1 week. Most production planners will set the lead time to 6
weeks to ensure a very high service level (i.e. >95%). This, in turn, leads to larger
levels of WIP and potential lost orders due to lengthy lead times. System nervousness
is another problem with traditional MRP systems [17]. This occurs when a small change
38
in the MPS results in a new production schedule that is infeasible. Further, typical MRP
systems require fixed processes or routings, when alternative methods or processes
could be utilized. These systems also prioritize production releases only by period or
date, when other options, such as priority or minimum tool changes might be preferred.
MRP 11 systems attempted to correct some of these problems by introducing new
functionality, including demand management, forecasting, rough-cut capacity planning,
and capacity requirements planning. Long-term planning and aggregate production
planning attempted to address the levels of production, staffing, overtime, and inventory
over the long term. However, due to sometimes dramatic changes in demand, these
systems have proven to be less than reliable. One of the primary problems lies not with
MRP itself, but rather the way that it is used. Using arbitrary schedules with significantly
varying demand proves to be an extremely challenging task. Additionally, demand
management attempted to resolve issues with creating feasible production schedules by
utilizing a combination of firm orders and a short-term forecast. This system utilized the
technique known as available to promise (ATP), where forecasted orders are
"consumed" by actual orders. However, this system also relies on a potentially incorrect
short-term forecast. Finally, Capacity Requirements Planning (CRP) has been utilized
to obtain more details on the capacity loading within a factory. However, this model still
utilizes fixed lead times and simply informs the production planner which machines are
in an overloaded condition. The planner is then forced to determine the source of the
problem and potential solutions. Figure 16 depicts the new functionality introduced by
MRP 11 systems.
39
Long-Term
Forecast
Resource
Plannge
i
Rough-Cut
Capacity
Planning
Aggregate
PEv
otooan
Firm
Orders
Master
Production
Scheduling
(MPS)
Short-Term
Forecast
Demand
Management
Master
Resource
Planning
(MRP)
Job
Pool
4
-
0
Capacity
Requirements
Planning
Figure 16: MRP 11 Schematic. [17]
While ERP vendors continue to add functionality such as web interfaces, the
technology behind MVRP has only evolved minimally per the MVRP I I discussion above.
Some vendors have attempted to improve upon the limitations of MVRP by adding
Advanced Planning and Scheduling (APS) modules. APS systems do utilize a finite
scheduling approach to dispatch orders, which dramatically improves the ability to
model a given plant. However, these modules also rely on the input of accurate and
timely data for actual production times. A comprehensive specification for APS software
was also completed as part of the current work [16]. An overview of the required
functionality for a basic APS software product, generated as part of this research, is
provided in Appendix B. The ultimate solution to this problem is to implement an MES
system that provides real-time data on shop floor operations.
40
2.2.3
Device-Level Software Systems
In order to enable a real-time MES system, shop floor equipment and
processes must be connected to the computer network in some way. Depending on the
nature of the work being performed in a particular process, this connection can prove to
be either very easy or fairly complex. For example, we will study the production line for
a distribution transformer. Within this line, there are a series of processes that are
either completely manual, machine-assisted, or completely automated. The cutting and
stamping of the transformer core is a process that is completely automated once a roll
of material has been installed on the machine. Under these conditions, it would be
optimal for the MES system to interact with this machine without human intervention.
All required information would simply pass from the machine into the MES. Further
down this production line, operators use devices, termed winding machines, to finalize
the transformer cores. This process requires both a full time worker and a machine.
Under these conditions, interactions with an MES system could be performed by the
operator of the machine or could be fully automated as described above. In this case,
ease of interaction would become the deciding factor for or against fully automating the
transfer of data. After the winding process, finished cores are then manually inserted
into the transformer enclosure. As this process is completely manual, there is only one
method of interaction with the MES system. The operator must be utilized to input all
required data on his/her process step. This type of interaction is considered relatively
easy, as the operator can utilize a computer that has been connected to the plant's
network. The link from data to MES is performed via an Ethernet connection to the
MES system.
41
As mentioned above, the fully automated link presents the greatest challenge.
The following section describes the technologies utilized to enable this automated link,
and we will again use the example of a distribution transformer factory to illustrate this
link. In addition to the cutting/stamping machines and winding machines, there are at
least two other major processes that require a semi-automated system. The first is the
heating process. Once a distribution transformer has been completely assembled, it is
then placed into a heating oven to remove all moisture. This oven heats and cools the
transformers using a specific protocol which is transferred to the heating elements via a
Programmable Logic Controller (PLC). Additionally, the transformer test process is
controlled by a series of PLCs. These PLCs serve as connections to lower level
devices such as valves, heating elements, or capacitors. The connection between the
PLC and controlled device is typically completed using a point-to-point wired 4-20 mA
signal. Each device is then calibrated to respond over this signal range. For example,
a valve will move to a fully closed position when sent a 4 mA signal and move to fully
open when provided a 20 mA signal.
In order to reduce the wiring requirements associated with this point-to-point
system, a technology termed fieldbus was developed. This technology continues to
support the interconnectivity provided by conventional 4-20 mA systems, but also allows
multiple devices to be connected to a single bus, provides additional data content, and
distributes intelligent functions such as proactive maintenance and self-diagnostics [18].
The basic premise behind fieldbus is that it establishes a network of connected devices
and allows improved communication with those devices. While fieldbus can be
42
considered the most popular standard for industrial networks, there are several other
standards which are utilized within industry, Profibus and CANbus [19].
However, the data from this equipment is not yet connected to the MES system
or any computer network for that matter. In order to obtain full real-time functionality,
data transmitted over the fieldbus network must be transferred to a standard operating
system. In the past, this connection was completed by simply writing drivers (i.e. code)
for every device that a particular program must use. Figure 17 below presents an
example of this situation. Because each system utilized proprietary software,
developers were required to write drivers for every device. The best example of this is
the original word processors which only supported a limited number of printers.
PC With
PLC with
DCS with
software
proprietary
proprietary
pack ge A
software
software
Devie
A
Device
B
Device
C
Figure 17: Device-driver concept with proprietary software. [20]
While this method of data conversion is effective, it consumes a large amount
of software development resources. In August of 1995, a task force, including members
from Fisher-Rosemount, Rockwell, Intellution, Opto-22, and Intuitive Technology, began
to develop a standard communication protocol for communicating with various devices
[20]. The goal of the group was to develop an open, flexible, plug-and-play standard
which could be utilized by anyone. The result was the OPC standard (OLE for Process
Control). OPC consists of a standard set of interfaces, properties, and methods for
43
communication between devices, controllers and software programs. The OPC
standard chose to utilize Microsoft's Active X, COM, and DCOM technologies as the
platform for development. Therefore, all OPC compliant devices, software, or
controllers use COM to interact and share data.
To better explain the implications of this standard, we will use the example of a
PLC. The OPC standard requires the PLC hardware manufacturer to provide data
collection and distribution, because they are most familiar with the methods for
extracting data internal to the device. The PLC would then become an OPC server and
provide data to any number of OPC clients. At this point, developers could utilize any
software program (i.e. C++, Visual Basic, etc..) to create applications that access this
data. Essentially, the OPC server (i.e. PLC) translates the internal data into a form
recognized by COM. Once the data is resident on the COM platform, any number of
applications can be utilized to perform functions on that data. The development of OPC
compliant products continues to evolve as is the standard for OPC itself. The table
below describes the various standards created by the OPC Foundation to date.
The following spedfications ewst for OPC
W OPC Data Access Specification . . . . . .process
..
data communication
U OPC Alarms and Events Specification . . . . monitoring of alarms and events
* OPC Historical Data Access Specification . access to historical data
a OPC Batch Specification .............
access to data of MES/Batch systems
2 OPC Security Specification ...........
protection against unauthorized access
and intervention
U OPC and XML* ...................
integration of OPC and XML for the creation
of Web applications and interfacing with
non-Windows operating system platforms
a OPC DX* ......................
configurable Server-Server interaction
* in preparation
Table 1: Current OPC standards. [21]
44
2.2.4
Manufacturing Execution Software (MES) Systems
With a description of the various pieces of manufacturing software completed, it
is now possible to describe how Manufacturing Execution Software (MES) can be
utilized to improve the performance of these other systems. Figure 18 presents the
relationship between MES and both higher level and lower level software systems.
Sales & Service
Management
ERP
Customer
Relationship
MManagement
E-Commerce
Dispatching
Production
Units
Product
Tracking
Maintenance
Management
Process
Management
Supply Chain
Management
Inventory
Management
Procurement
E-Auction
Resource
Allocation
Scheduling &
Planning
Strategic
Sourcing
MES: Integrated Production
Data Working with Operations
Quality
Management Systems, People, Management
And Practice
Document
Control
Labor
Management
Inbound/
Outbound
Logistics
Product & Process
Engineering
CAD/CAM
Performance
Analysis
Product Data
Management
Controls
PLC/
SoftLogic
Drives,
Motors
Relays
Data
Collection
Manual
Process
Control
DCS/ OCS
Automation, Instruments, Equipment
Figure 18: MES and its interactions with various systems. [22]
As described in the previous sections, device-level software systems translate
data from physical devices and convert them into conventional 4-20 mA signals or more
advanced fieldbus signals or even COM based data via OPC. The MES system then
serves as the aggregator of this data and performs functions that convert the data into
more useful forms. This system also stores the data and then interacts with other
45
systems to improve their performance. A good example would be the potential
interaction of an MES system and an ERP system. An MES system is capable of
monitoring in real-time processes on the shop floor. If a machine breaks down, the
MES system will recognize this event. This information could then be relayed to an
ERP system to prevent it from releasing more work-orders to that particular section of
the plant. In this way, the MES would prevent a Work in Progress (WIP) explosion,
which can be fairly common when only operating with an ERP. MES systems also are
capable of performing a wide variety of other functions that are tremendously useful to
CRP systems as well as SCM systems. The following table displays some of the key
data that is transferred between MES systems and other manufacturing systems.
DATA TO/FROM
9
0
SYSTEM
Costs
Cycle times and throughput
SLot consumptions per part number
Inventory
0
WIP and FG
0
Production Posting
0
Issue Work Order
0
Plans and routings
0
Bills of Materials
SMaterial
visibility
Numbers
lot information
"
Order status
"
Time spent
*
Production ca acities and ca abilities
"
Master plans and schedules
"
Supplier information
on
rework
Product yield and quality
*
ERP
SCM
PDM
Maintenance records
46
*
Work instructions
*
Operational parameters
*
Availability and delivery
*
On-hand inventory levels
CRM
"
Configurations
*
Special
*
Instructions and recipes
*
Operating parameters
Instructions
Controls
*
Operating conditions
*
Alarms & events
Table 2: MES interactions with other systems. [23]
A Manufacturing Execution System (MES) is a factory floor information and
communication system [23]. Its primary goal is to integrate real-time data from the shop
floor to enable efficient production, manage manufacturing processes, and feed shop
floor information back to enterprise applications. Within the world of manufacturing
software, the functional boundaries among programs are very blurred. For example,
ERP systems are constantly incorporating functions that could be considered part of a
Supply Chain Management application or other process-specific applications. The
situation is the same for MES software with different vendors offering different levels of
functionality. However, the Manufacturing Enterprise Solutions Association (MESA) has
developed a detailed model of the basic functionality of any MES solution. Table 3
provides descriptions of all eleven MES modules, as defined by MESA.
47
1. Resource Allocation and Status
Manages resources including machines, tools, labor
skills, documents and other materials that are needed
for work to start at an operation.
2. Operations/Detailed Scheduling
Sequences and times activities for optimized plant
performance based on finite capacities of the
resources and attributes of specific production units.
3. Dispatching Production Units
Manages the flow of production units in the form of
jobs, orders, batches, lots and work orders by giving
commands to send materials or orders to parts of the
plant to begin a process or step.
4. Document Control
Manages and distributes records or forms on
products, processes, designs, or orders.
5. Data Collection
Monitors, gathers, and organizes data about
processes, materials, and operations from people,
machines, or controls.
6. Labor Management
Tracks, directs and provides status on the use of
operations personnel based on qualifications, work
patterns and business needs.
7. Quality Management
Records, tracks, and analyzes product/process
characteristics against engineering specifications.
8. Process Management
Directs the flow of work in the plant based on planned
and actual production activities.
9. Maintenance Management
Plans and tracks activities to maintain capital assets
to ensure their availability for manufacturing.
10. Product Tracking and Genealogy
Monitors the progress of units, batches, or lots of
output to create a full product history.
11. Performance Analysis
Compares actual manufacturing results in the plant to
goals and historical performance.
Table 3: MES functions as described by MESA. [22]
The key benefit of a MES application, like most Manufacturing Information
Systems, is the efficient handling of production data. This improved efficiency is often
due to the integration of information from disparate systems. MES applications are
tools for organizing and cataloging enormous amounts of data and provide easy and
48
immediate access to the right data at the right time. The five bullets below describe in
further detail some of the specific benefits of MES [23].
Improved Information Flow - Implementing a MES allows integration of several
systems for scheduling, procurement, order tracking, metrics reporting, process control
and testing. By making the MES the "window" into these various systems, non-value
added repetitive activities such as managing paperwork can be eliminated and real-time
electronic information flow enabled. In essence, it enables a "paperless" manufacturing
environment.
Inventory Management - MES provides visibility to key metrics such as WIP and FG
inventory levels. By seeing the current level of inventory, the plant manager can set
inventory targets and define alarms when pre-set levels are exceeded. MES systems
improve inventory turns by allowing focused inventory reduction actions, decreased inprocess inventory, increased cost avoidance in compliance, and reduced work in
process.
Orders Tracking Capability - Production order tracking within the plant will provide
greater visibility to information. Having the capability to track orders through the plant
will give the sales force and customers a better estimate of when orders will be
delivered.
Improved Quality - Tracking of key quality metrics allows for easier reporting, control
charting, statistical process control, and root cause analysis, which all result in improved
quality. In this area, they reduce scrap, rework and returns and offer complete product
traceability.
Improved Operator Efficiency - Operators no longer have to wade through several
reams of paper to find the information they need. The correct Bill Of Material or Product
Drawing is made available on demand at the workstation. Revisions to product
specifications can be pushed to the floor electronically without significantly disrupting
production.
2.3
Discrete vs. Process Manufacturing
As mentioned previously, it is important to identify the differences between the
process and discrete manufacturing spaces in order to understand the direction of
49
ABB's MES development. The following section will attempt to shed some light on this
topic.
In discrete industries, products can be sold as units or multiples of a unit; in
process industries, products can be divided into any lot size by adjusting container size.
Examples of discrete industries include the aerospace, automotive and semiconductor
industries while the chemicals, paper, oil refining and mill products are considered
process industries. In some cases, the line between process and discrete
manufacturing is blurred.
In the food industry, many products use continuous
processes but the packaging of the end product may be discrete. In the apparel
industry, production of raw materials is process while production of the final units of
clothing is discrete. Figure 19 presents a table of various industries and their
classifications as either discrete or process.
Discrete
Machinery
Communications
Aerospace
Consumer Goods
Automotive
Food
SemconucorsApare
Medical Electronics
Process
Oil and Gas
Metal Refining
Pulp and Paper
Pharmaceuticals
Electricity Generation
Figure 19: Discrete vs. Process Industries. [23]
Manufacturing Execution Systems fordiscrete manufacturing address diagnostic,
maintenance, and productivity challenges associated with personnel and machines
used in volume manufacturing. The operator interfaces typically provide machine
control, diagnostic/production instructions, fault logs, product flow, material
management, and operator guidance. The biggest challenge facing discrete
50
manufacturers is how to integrate and leverage real-time information from multiple
sources to get a product out the door. The effort is focused on integrating data from
individual parts of the process - from product specifications and parts inventory, to
assembly, instructions, QA testing, receiving and shipping.
Manufacturing Execution Systems forprocess manufacturing address
diagnostics, maintenance, statistical process control, recipe management and
productivity challenges associated with batch processes. The operator interfaces
typically provide machine control, diagnostic messages, bar graphsor parameters such
as temperature, flow meters, pressure monitors, and recipe editors. The challenge
facing process manufacturers is capturing real-time information from several points in a
single integrated process to get a product of exacting quality out the door. Not only does
the production process involve a continuous flow that cannot be interrupted, but also the
individual production processes are so closely linked to each other that it's impossible to
view or manage any of them in isolation.
Though MES applications exist for both the discrete and process industries, there
are significant differences in the way they are used. Figure 20 below shows typical
functions that are available in MES applications in both industries and some that apply
to both but are used differently in each.
PROCESS
Ung
il
Mgn
du -,06
Rorce Allocation
Scheduling &Planning.
Dispatch
c-A
um
Workflow Management. peormance Anm
- Flow Monitoring
Recipe Management
larm, Managmn
- Proces
Man
Figure 20: MES Functions with discrete and process spaces. [23]
51
3.0 MES Development at ABB
Based on the initial work of Michael Hoag, ABB did in fact launch several software
development efforts into the discrete manufacturing space. Rather than create generic
applications that could be applied to any factory, ABB made the decision to develop
both projects in partnerships with specific factories. While this strategy eases the
customer requirements and functionality phases of software development, it severely
restricts the ability to re-use the software at a variety of factories. The following sections
provide detailed information on each of the projects.
3.1
Distribution Transformer Project - Lodz
As a first trial of AIP and Industrial IT in a discrete manufacturing setting, ABB
selected a distribution transformer factory in Lodz, Poland as a test case. The project
plan called for development of a variety of systems including software to support sales,
engineering design, global scheduling, and electronic transfer of information. Figure 5
in Chapter 1 provided an overview of the complete system and all the interactions with
various subsystems. As seen in Figure 5, the project extends from the sales/design
process all the way down to pieces of equipment on the shop floor. The first step in the
process was to utilize a software program, termed TrafoNet, to assist engineers with the
selection of appropriate designs to meet customer requirements. This program was
intended to standardize the quoting process and attempts to translate customer
requirements into specific design features. This system would then be connected to
both the ERP system and an order management application. The primary function of
the order management application is to store design information and select an existing
design which could be applied to TrafoNet's specified requirements. Once a design is
52
selected, the information is then passed back to TrafoNet for costing and quoting. If the
order is placed, this information is then sent to the ERP system and back to an order
facilitator application. The order facilitator application interacts with a variety of
systems: ERP, Inventory Manager, Rules Engine, Shop Floor Manager, Planning
Manager. All of these applications then begin the process of determining how and
when to schedule the order for production. This process is completed by retrieving realtime data from machines operating on the shop floor. All major processes will be
connected to these applications via the AIP platform. Figure 21 below presents a
schematic overview of the intended system.
Business Process Optimization
Windf~rs
TrafoNet
CIS
Skyva APS
Core CteTest
Manufacturing Process Optimization
Skyva: Transactional Data
-
'- Industrial IT:
-
implemented as Aspect Systems
Real Time Data - implemented as Aspect Objects
Figure 21: Distribution Transformer Project Overview. [24]
This specific project is attempting to optimize both the manufacturing process
and the business process. On the manufacturing side, all of the applications just
described should improve the speed and efficiency with which an order is handled. The
intent here is to dramatically reduce the time from quote to delivery. On top of these
systems, the project called for a global planning and scheduling application, termed
53
Skyva, to optimize the business process. The Skyva application will be connected to
several distribution transformer factories around the world and will have real-time
access to information such as equipment utilization, backlog, and other capacity related
data. The primary goal of the Skyva application is to determine the factory that is most
suitable for handling the order promptly. Once the minimum lead time is calculated, the
order would be sent to the factory that provides both the best customer service and best
cost.
It is difficult to classify this project as solely an MES application, as it includes a
variety of functions which would be considered out of the scope of MES per our earlier
description. The features which could be considered MES are the planning/scheduling
of shop floor processes, the real-time connections to equipment, and the electronic
transfer of shop floor information. Both the TrafoNet application and order manager
application assist with the sales/quotation processes and therefore should be
considered part of a CRM system. Additionally, the business optimisation, performed
by Skyva, could also be classified as a CRM function or even a SCM function.
The Lodz project was officially launched in June 2001 with an intended project
completion date of January 2003. However, based on a plant visit in September 2002,
the project has fallen significantly behind schedule. At that time, the only piece of
functionality in place was the TrafoNet application. This delay can be attributed to a
host of factors including the project team, scope, and complexity of interactions. The
project team consisted of a variety of personnel residing in six locations: Poland
(Warsaw, Krackow, Lodz, and Wroclaw) and U.S.A. (Boston and Raleigh). While
distributed development is feasible, it requires a detailed set of requirements and
54
exhaustive communication management systems. It was not clear to the author that
either of these elements was in place. The scope of the project also limited the
development capabilities. This project is attempting to create MES, CRM, and
advanced planning and scheduling applications. To undertake an effort of this scope
requires a huge project team that is fully dedicated to the task. Again, this was not
readily apparent. Finally, the complexities of the interactions are tremendous with a
host of programming languages being employed. For example, connections to provide
real-time shop floor data will be provided via the AIP platform. The planning manager,
order manager, order facilitator, inventory manager, and machine manager applications
are being developed in Java. Meanwhile, these applications must also interact with an
SAP ERP system, TrafoNet, and the Skyva software. With a host of independently
developed software, the interactions will present a significant challenge.
3.2
Embedded Pole Project - Ratingen
A second discrete manufacturing MES program was launched at an embedded
pole factory in Ratingen, Germany in January 2002. Compared to the Lodz project, the
development efforts in Ratingen are much better focused on the MES space. The
primary goal of the application is to improve the flow of information throughout shop
floor processes. It is achieving this goal by delivering the following list of functions:
" Dispatch work orders from ERP to required workplace.
" Scan & print barcodes to enable product genealogy.
*
Provide "on-line" documents for BOM, drawings, etc.
*
Log information on quality defects.
*
Collect data from measurement locations.
55
*
Store and display process steps for each workplace.
Since the majority of process steps within this factory are manual (i.e. require
human interactions), the software is focused on improving the efficiency of these actions
by delivering the required information promptly. Figure 6 in chapter 1 displays the
primary Graphical User Interface (GUI) for the Ratingen application.
As seen in this figure, the employees at various workplaces will primarily be presented
information on the workorders within their queue and information on the product in
progress. Additionally, these workers will be capable of linking to drawings, product
specifications, BOMs, and procedural instructions. The software program also attempts
to eliminate many of the non value adding (NVA)steps in the current process. Figure
22 presents the specific devices that will be linked to the software to eliminate a few of
these NVA steps.
WORKPLACE
GUI
MANAGER
GUI
ADMINISTRATION
GUI
Aspect Integrator Platform
OPC (OL for Process Control)
SCANNER
TEST
EQUIPMENT
TORQUE
WRENCH
LP
TNDGER
CASTING MACHINE
CALIPERS
PRINTER
Figure 22: Devices connected to Ratingen workplace software.
56
For example, the current process requires workers to label a product with an ID
number several times. The Ratingen project automates this process by linking to a
scanner and printer which will automatically generate, register, and print the required
labels. Additionally, the program is linked to callipers, torque wrenches, test equipment,
and a casting machine. Data from all of this equipment will be automatically stored by
the new program. In this way, the Ratingen project should dramatically improve the
speed of production by eliminating many of these NVA steps. In fact, the primary
quantified benefits of the program revolve around improvements in speed. The list
below describes some of these benefits as well as expected savings in dollar terms.
" Production ($151,000 savings/year by 2006).
o
Reduction in throughput time per embedded pole.
o
Reduction of working time for updating instructions.
o Reduction of clarification time for completing products.
*
Packaging ($7,000 savings/year by 2006).
o
Reduction in working time.
" Quality ($216,000 savings/year by 2006).
o
Reduction in number of EP rejections due to poor quality.
" Management of Process ($26,000 savings/year by 2006).
o
Reductions in clarification/investigation time.
The Ratingen project also represents what should be considered a full Industrial
IT solution. All relevant product data will be stored as objects/aspects within the AIP
platform, rather than in external SQL databases. The program does utilize an external
database to store information such as drawings or other documents, but the majority of
57
information will reside within AIR As the AIP platform contains interface capabilities
with Visual Basic, all of the GUIs for this projecthave been programmed in that
language. Additionally, the Ratingen project will pull workorder information from an
interface with SAP's ERP system.
While the Ratingen project was initially conceived as a "quick win", several
factors have slowed progress. In fact, the original implementation date for the software
was August 2002, while the revised date is currently scheduled in December 2003.
One of the primary factors hindering development is the project's use of the thin client
version of AIP. The thin client version is still under development and the programmers
for this project are utilizing a beta release of the software. As such, there are a number
of bugs in the AIP software which have caused significant delays. Additionally, the
Ratingen project is attempting to use transient objects (i.e. objects that move through
the data structure). For example, each embedded pole is represented by an object
within the AIP structure. As the product moves through the process, the IT
representation of this product will also move through the various workstations. This
movement requires additional, complex programming when compared to static objects.
Second, the complexity of interfacing with a variety of systems has caused several
delays. The Ratingen software must be capable of communicating with the ERP
system, as well as a variety of products on the shop floor. While the connection to the
ERP system is accomplished via a standard Business Application Programming
Interface (BAPI), connections to older plant equipment prove more difficult. For
example, the PLC utilized to control the casting machine is not OPC compatible and
therefore, interface code must be written to extract data from this machine. Finally, the
58
project team consists of one project manager and only two full-time programmers.
While this is certainly an efficient organizational structure, the limitation in resources will
slow progress. Another organizational factor affecting development speed is each
programmer's knowledge of the AIP system. While it is easy to find Visual Basic or
Java programmers, AIP experts are in short supply.
4.0 Generalization of Software Solutions
Some pieces of code are written for very specific applications, while others are
intended to be broadly applied. The key to elegant software development is to create
an application which is detailed enough to be beneficial to a specific application, while
broad enough to appeal to a variety of users. For example, the program, Microsoft
Word, was clearly written to serve as a word processor, a very specific application.
However, the code was developed in such a way that it can be applied broadly.
Imagine if Microsoft only considered the needs of novelists while developing the
program. Many pieces of functionality, such as inserting of tables or figures, would not
have been included, since novelists do not require this feature. If Microsoft attempted to
sell this particular version of Word to professors or students, it would certainly not be
received well, as both parties rely heavily on figures and tables. Microsoft would then
need to re-code a second version of the software to appease this group of customers.
In reality, Microsoft Word includes a myriad of features, which make it applicable to any
person in any industry.
While developing a piece of MES software, the same must be true. In order to
be applied in a variety of industries, the program must be general (or customizable) to
59
be applied broadly, but provide functionality to assist a specific plant. However, the
development method at ABB prevents programmers from thinking broadly. By
partnering with specific plants, the developers focus their efforts on solving one
particular customer's needs. For example, consider the Ratingen project described
earlier. This application contains code which was written to handle a specific number of
workplaces for a specific part in one factory. Rather than creating a general workplace
object that can be added or removed as necessary, the developers have coded specific
workstations in the process with specific pieces of functionality at each workstation.
Therefore, it is doubtful that this program could be applied to even another embedded
pole factory without recoding, since their process could be slightly different. This is an
extreme case of utilizing only one customer's perspective. On the other hand, the Lodz
project is a step in the right direction. The developers of this application are utilizing
Java. If the Java classes are created properly, it is possible that they could be re-used
in other factories. However, by partnering with a specific distribution transformer
factory, it is again doubtful that the program could be utilized in, say, a semiconductor
factory without some level of recoding.
Recognizing these limitations in re-use, another project was initiated with the
goal of producing generally applicable version of the Ratingen software. This new
project included the development of two pieces of code, termed Cell Manager and Line
Manager. The following section describes the current status of this project.
4.1
Cell Manager I Line Manager Development
The Cell Manager / Line Manager project was born out of some initial work
completed by a robotics solutions company in Sweden. This particular company builds
60
and installs turnkey solutions that utilize roboticells . After interviewing several groups
of customers, a development project was launched to create an application that would
interface with a variety of devices within a given robotic cell. The result of this effort is a
product termed Cell Manager. The following list describes the overall functionality of the
software.
"
Provides current status of equipment.
- Running, Down, % of expected production.
- Starved, Blocked.
- Current process/product.
- Alarm information.
"
Delivers cell specific information.
*
- User Manuals, Maintenance Info., Drawings, etc.
Displays production information.
- Average/Present/Expected cycle time.
- Number of products completed.
Figure 23 depicts the main graphical user interface for the Cell Manager
application. This main screen presents an overhead view of a specific robotic cell. As
seen in the figure, the exact layout of the cell is represented with conveyors, two robots,
and two tooling stations. Detailed information, such as drawings and maintenance
instructions, can be obtained by right-clicking on a specific object. Additionally, a
standard set of information, such as cell status, product in progress, and production
performance, is provided on the right-hand side of the screen. Because this product
was forced to consider the needs of more then one customer, the software can actually
be customized without re-coding. Additional robots or tooling can simply be added to
the picture presented below without going back to the code. This ability to customize
makes the product more broadly applicable.
61
Figure 23: Cell Manager GUI. [25]
However, the development team only considered customers that utilize robotic
cells. As such, this piece of software could not be utilized at the embedded pole factory
in Ratingen. The functionality to handle manual workstations was not developed. The
project initiated in November 2002 was tasked with making a second version of Cell
Manager, which could be applied to any factory. Additionally, the project entailed the
development of a second layer of functionality which could present simplified
information for a series of work cells.
4.1.1
Cell Manager 2.0
At first glance, the generalization of Cell Manger 1.0 appears to be a fairly simple
task, since no changes in functionality were planned. However, four main issues made
62
the problem much more difficult: customisation of graphics, equipment connections,
data storage, and data capture.
In order for the program to be generally applicable, the main GUI must be easily
customisable. The Cell Manager 1.0 application utilized another program termed
Graphics Builder from Visual Basic to create the view shown in Figure 23. The ease of
use associated with the Graphics Builder application will limit the ability for various
customers to generate their desired view. Since Graphics Builder requires expert
knowledge of Visual Basic, the Cell Manager 2.0 becomes less useful, because a
programmer is required to customize the applbation. Additionally, t he current library of
images for the main user GUI consists of products related to robotic cells, which
includes such elements as robots, conveyors, etc. In order for the program to be
broadly applied, some easy method for generating user-specific graphics must be
supplied. In this way, customers or consultant teams could perform the customisation
process.
The second major issue relates to equipment connections. The Cell Manager
1.0 program utilizes a piece of software termed WebWare SDK to communicate with
each robot. For generally applicable software, the program must be capable of
communicating with a variety of equipment. For example, the Cell Manger 2.0
application must be capable of communicating with ABB robots or a PLC attached to a
casting machine, as at Ratingen. Obviously the first step to improving communications
is to build an OPC interface into the program. This will allow communication with any
OPC compliant piece of equipment. Secondly, a system for storing a library of
proprietary connections must be developed. This is a similar concept to the "plug-ins"
63
seen in Microsoft Word. While many customers do not require the use of equations in
their documents, some do. If desired, a user can simply add this piece of functionality
into the program via the tools menu. A similar concept for communicating with PLCs
and other equipment must be considered in Cell Manager 2.0.
The third major issue relates to the storage of data. Cell Manager 1.0 utilizes the
AIP platform to store all product and equipment data as objects. However, due to
limitations in AIP, this data is only stored for a single day. Obviously, a great many
customers would appreciate the ability to store data for a longer period of time.
Therefore, some method for storing data must be developed. This could be
accomplished by utilizing a SQL database or possibly with the Inform IT Historian
product.
The final major issue relates to the information that is stored in Cell Manager 1.0.
The current application does store useful information such as machine status, units
produced, and even process details. However, many details are omitted. This again
relates to the development process of looking at a small set of users. The generally
applicable version of the software must consider a variety of users as well as potential
future development of functionality. Establishing a detailed data model which considers
future functionality reduces the probability that re-coding will be necessary. For
example, consider recording a simple piece of data such as a time stamp when the
status of a machine changes. If the data is present, future versions of the software
could include functionality to calculate overall equipment effectiveness (OEE) based on
the time stamps. If the data is not present, then this functionality cannot be included.
With this in mind for manufacturing workplaces, a data model was developed. Table 4
64
below presents a simplified version of the model, while the full version can be seen in
Appendix A. The intent of this data model is to present all required data for a generic
workstation. With this data model in place for Cell Manager 2.0, a host of downstream
functionality should be enabled.
Classification
Info
Provide current status
Running
States
Normal operation
% of expected production
Stopped
Product
Process
Workorder
Machine Failure
Starved
Blocked
Idle
Setup/Adjustment
Preventative Maintenance
Product I
Product 2....
Process I
Process 2...
Quality Station
Inbox
In Progress
nuthnx
Deliver Cell/Workplace information
Information button
......
Calculate, store & display production info
Process Data
Process Instructions
Setup Instructions
Other Info....
Present Cycle Time
Temperature
Pressure
Other Data.....
Workorder Data
Number Produced
[Number
of
Rejects
Table 4: Simplified data model for Cell Manager 2.0
4.1.2
Line Manager 1.0
With the Cell Manager 2.0 data model above in place, Line Manager should
simply be considered an aggregator of information from a series of Cell Managers. This
program will be responsible for interacting with higher level systems as well as
performing calculations related to line specific information, such as throughput time.
Based on initial customer feedback and an internal expert survey, Table 5 displays the
top 18 functions to be included in the first version of the software. Each piece of
65
functionality has been broken down into six major categories. Obviously, the functions
presented in this list should be considered the wish list for the first version of the
software. Depending on the desired completion date and availability of resources, the
list of functionality could be reduced to meet any limitations.
Workorder Management
Line Control/Status
Performance Data
Lean Processes
Reporting/Data Output
Product Tracking and Genealogy
Recieve workorders from external system (inbox)
Start Workorder
Stop Workorder
Provide complementary workorder information (serial
number, user manuals, drawings, etc.)
Dispatch workorders to appropriate cells/workplaces
Modify workorder
Forecast/Simulate workorder completion
Alarm Notification
Start/Stop line cycle (empty line before stopping)
Line Supervision (Overall view and detailed view per cell)
Throughput Tracking
Average-current-expected cycle time
Quality performance (for line/each employee per part per
_month, day, year, etc....)
Define Maximum WIP levels
WIP Status
OEE for each cell/workplace
Extract information to Excel, Word, Crystal Reports, etc...
Store/Retrieve product genealogy information
Table 5: 18 initial functions for Line Manager 1.0
Figure 24 presents an example GUI for the Line Manager application. Similar to
Cell Manager, the Line Manager program must be customizable to suit the needs on
any number of customers. For example, all items in the left hand window of Figure 24
must be "drag and drop" functionality. In this particular case, the user has defined three
major process steps. For each step, the customer has chosen to link to information on
the equipment within that particular process step. This is represented by the figures on
the left hand side. Also, the customer has added the stoplight functionality which allows
him/her to quickly analyze the equipment status in each workplace. As seen, the WIP
66
tracking functionality has also been enabled. Quick information on the number of
products residing in a workstation's inbox, outbox, and in progress box are presented.
Finally, the OEE "plug-in" has been enabled for the first process step. While this is
simply an example, this level of customizable functionality should be included with a
generic Line Manager program.
Figure 24: Example Line Manager GUI
4.2
Web Services Model
While the Line Manager and Cell Manager applications described above present
a generic solution for MES development, the ease of customization and integration must
be considered. Both of the programs will utilize a combination of AIP, Visual Basic, and
likely a SQL server for data storage. While these programs are tremendously useful,
there are significant limitations to their flexibility. For example, it is doubtful that true
"drag and drop" functionality will be enabled via these technologies, especially for
difficult functions such as WIP tracking. It is likely that while customizing the GUls,
67
some level of experience in Visual Basic, AIP, and SQL server will be required.
Therefore the customization process will be performed by programmers and general
users will be shut out. However, another development model could be utilized for
development of an MES which would allow simple full customization on a per user basis
(i.e. easily completed by people with practically no IT knowledge). This development
model employs web services for small pieces of functionality. Complete details on this
model are presented in the following sections.
4.2.1
What are Web Services?
In the simplest sense, web services are a web-based technology for improving
the exchange of information. This technology has only recently been enabled via the
standardization of a variety of processes. In fact, web services rely on the existence of
four primary standards: XML, SOAP, WSDL, and UDDI. Each of these concepts are
explained in a simplified manner below.
The introduction of eXtensible Markup Language (XML) was the critical step to
enabling improved data communication [26]. Basically, XML creates a standard method
for defining data by setting up a protocol for defining data tags. Data tags simply inform
a user (i.e. human or machine) what data is enclosed in the tag. The following example
presents a series of XML statements for a chocolate chip recipe to emphasize this point
[27]. The comments enclosed in parenthesis <" "> are the XML statements. In this
way, both the data and the context of the data are presented to users.
<?xml version="1.0"?>
<list>
<recipe>
<author>Carol Schmidt</author>
<recipe name>Chocolate Chip Bars</recipe name>
<meal>Dinner
<course>Dessert</course>
</meal>
68
<ingredients>
<item>2/3 C butter</item>
<item>2 C brown sugar</item>
<item>l tsp vanilla</item>
<item>l 3/4 C unsifted all-purpose flour</item>
<item>1 1/2 tsp baking powder</item>
<item>1/2 tsp salt</item>
<item>3 eggs</item>
<item>1/2 C chopped nuts</item>
<item>2 cups (12-oz pkg.) semi-sweet choc. chips</item>
</ingredients>
<directions>
Preheat oven to 350 degrees. Melt butter;
combine with brown sugar and vanilla in large mixing bowl.
Set aside to cool. Combine flour, baking powder, and salt; set aside.
Add eggs to cooled sugar mixture; beat well.
Stir in reserved dry
ingredients, nuts, and chips.
Spread in greased 13-by-9-inch pan. Bake for 25 to 30 minutes until golden
brown; cool.
Cut into squares.
</directions>
</recipe>
</list>
The acronym SOAP stands for Simple Object Access Protocol and is essentially
the tool used to pass commands and parameters between clients and servers. One of
the primary benefits of SOAP is that it is independent of the platform, object model, and
programming language. This enables it to work across a variety of systems.
Additionally, SOAP is based upon the XML standard. For more information on the
details of SOAP, please refer to the W3C SOAP 1.1 specification
(http://www.w3.org/TR/SOAP/).
The Web Services Description Language (WSDL) is the method by which web
services are defined and is basically a user manual for the service. A WSDL file is
attached to every web service and defines the method for interacting with that web
service. By interacting with a given WSDL file, the web service can be called and
utilized by another application.
69
The Universal Description, Discovery, and Integration (UDDI) is essentially a
large telephone directory for web services. It stores a list of available web services and
points a user to the appropriate location for a particular web service's WSDL file.
Figure 25 presents a schematic overview of how each of these elements work
together to enable a web service.
The first step in the process is to find a web service
that will serve the needs of the user (i.e. XML web service client). This is accomplished
by referring to an existing UDDI registry. Next, the client issues a HTTP statement to
the web service's website and receives an HTML or XML message back with a link to
the WSDL file. The client then issues a statement to the web service asking for
information on the WSDL file and receives an XML document with the service
description. The actual service is then called and a XML document is transferred using
SOAP. At this point, the web service is then active on the client's site.
Figure 25: Web service interactions. [28]
70
4.3
Using Web Services for Customizable MES Software
The use of web services within the context of an MES application has profound
implications on the ease of customization. This is primarily related to the modular
aspect of web services. For example, the software development projects described
earlier are large, complex, interconnected programs with thousands of lines of code.
Re-coding a section within this type of program could cause significant problems in
other areas, which of course would be difficult to detect due to the size of the project.
The web services model allows the use of tiny pieces of functionality which can be
brought together at run time. Therefore, a given MES application could consist of
1000's of very small web services. Figure 26 attempts to explain this concept in relation
to the Ratingen solution described above.
Ratingen Workplace
User Interface
\SOAP
Internal
UDDI
Registry
Bill of
Materials
Workorder
Wnding
QueueMtr
Figure 26: Utilizing web services for MES applications.
Let us assume that three web services have been developed which handle
specific pieces of MES functionality. The first web service is capable of interacting with
an ERP system and returns a list of the items on Bill of Materials for a given product.
The second web service again interacts with the same ERP system, but simply returns
71
a list of workorders for a given workstation. The third web service communicates with a
motor utilized within a winding machine and displays this information in the form of a
plot of r.p.m. over time. Now, let us assume that I am a developer creating an MES
application for the Ratingen factory. Rather than utilize a standard programming
language such as Visual Basic or C++, I decide to attempt a thin client version of the
software using only a web browser as the user interface. My first step is to utilize ABB's
internal UDDI registry to find relevant web services. With luck, my search of the registry
identifies three web services which can be of use to me. For all other required pieces of
functionality, I can simply program additional web services to meet those needs and
register them in the UDDI. Next, I create a call statement which returns the WSDL files
for the three web services that I desire. With the WSDL file, I can then embed these
three web services into my web browser interface. Over time, my library of web
services continues to grow and additional functionality can be easily added to my webbased MES application.
The point of the story above is to demonstrate how web services changes the
traditional programming paradigm. In the traditional programming world, applications
are written, compiled, and then installed on client machines. In the web services world,
applications are pieced together from individual elements of functionality and executed
over a thin client, which only requires a web browser as an interface. Figure 27 displays
how this concept would appear in relation to the MES story above.
72
File
Edit
View
Tools
L
Back
Address
Favorites
ttp
Help
Search
Favorites
Media
e om
Go
!W rkordertNumbe
Produdtli
000070192062
GCE00000R0101
000070192065
GCE0000000R0101
Links
_
Bill Of
Materials
14
Internet
Mg
Figure 27: Running MES through a web browser.
As mentioned previously, web services can enable simple customization of
applications. This is again achieved due to the modularity of functionality. By simply
calling or not calling specific web services, the user interface can be completely
customized. If a particular user would like to see a list of workorders for a given
workstation that web service will then be embedded in his/her GUI. In this way, the user
interface can be customized down to each individual user. By associating a list of web
services with a particular user login, the desired web services can automatically be
called and presented upon login. Additionally, the given web services can be arranged
on the initial web page in any order (i.e. design layout can be customized per user).
Finally, web services enable even basic users to add/remove/arrange functionality
73
without any IT knowledge. Administrative screens can be created which make this
process accessible to the most IT adverse user.
5.0 Conclusions and Recommendations
ABB's concept of developing software applications in conjunction with their
standard product offerings is tremendously sound. The Industrial IT program should
certainly move the company toward a more service based business model and thereby
improve profit margins. Additionally, by developing software close to the product level
(i.e. MES level), the company can leverag its extensive product knowledge base.
When combining software, products, and an excellent distribution channel, the ability to
improve profit margins is undoubted. The following sections attempt to summarize
some of the key concepts discussed within the thesis.
5.1
The Business Value of IT in Manufacturing
In any company, an investment is made in order to achieve a return on that
investment. The same is true of software implemented in manufacturing environments.
Therefore many software vendors claim a host of benefits: deliver efficiencies, cut
costs, achieve significant return on investment (ROI), enable business productivity,
solve problems, optimize assets, leverage resources and maximize customer value [29].
While these statements might prove to be true, they do not provide quantitative
assessments of the true value of the IT implementation. This problem has continued to
plague software vendors as many customers demand specific figures concerning the
value of the investment. In order to assess the business value of the IT investment, one
must establish a link between the IT solution and its contribution to business processes.
Figure 28 presents a variety of business processes and the potential types of business
74
value that can be created in each area. By focusing on these areas of business value,
software vendors can then begin to apply specific numbers to the return on investment.
- Faster
orders
Better
information
Lower costs
- New and
improv d
products
h nels
and
ar
Reued
irwentory
Manage
Services
Produce
Services
Perform
Planning
Develop
Services
productivity
pr cost
- Faster to market - Reduced
irnentory
- New product
- Improved
functionality
quality
- Easier regulatory
compliance
Deliver
- Higher
Services
- Lower costs
- Faster delivery
- Reduced
inventory
Lower costs
8 etter crossselling
- Easier customer
acquisition
More-profitable
- Faster
service
- ette r
information
Lower
costs
customers
- More responsive
Provide Support Services
-
Easier communications
Lower costs
Faster decisions
Improved recruitment
Better staff development
-
Faster reports
Shared knowledge
Easier regulatory compliance
Better staff development
Figure 28: Business Value of IT. [29]
Additionally, the business environment plays a significant role in what companies
deem valuable. For example, consider the general industry shift from build-to-stock
toward build-to-order. These changes promoted an interest in the order end of the
manufacturing process and drove the adoption of ERP and CRM [30]. Further, the
outsourcing of production to component manufacturers increased the value proposition
for SCM, as these applications improved the communications between vendors within
the supply chain. Recently, companies have been focusing on improvements of internal
efficiencies, which have promoted further use of MES software [31].
5.2
Creating Generic Software
The value proposition discussed above must extend to the software developers
as well. A tremendous amount of money and resources are required to develop useful
75
software applications. Therefore the ability to apply a given piece of software within a
variety of industries becomes very important. By creating a piece of software that can
be broadly applied, the software developer can tremendously improve the profit
possibilities of the product. This brings us back to the creation of generic software,
discussed in Chapter 4. A major part of the current work was focused on the ability to
apply the Ratingen and Lodz solutions to different factories. However, the research
concluded that these applications have limited potential for re-use, due to the method of
development. This presents a significant problem when considering the return on
investment. Because these solutions will only apply to a single factory without further
coding investment, all profit potential must come from efficiency improvements at each
factory. This extends the payback period for the software well into the future.
The recognition of this fact was the primary driver behind the development of the
Cell Manager and Line Manager applications. The intent of these pieces of software is
to allow application in a variety of locations. For example, the Cell Manager 2.0
application will extend the functionality of Cell Manager 1.0, so that the software can be
applied to any manufacturing workplace. Additionally, the Cell Manager 2.0 data model
provides a map of required information which will enable further pieces of functionality
to be developed. By considering all possible workplaces and recording all relevant
data, the Cell Manager 2.0 software should be generally applicable. Further, by
generalizing the Cell Manager application, development of Line Manager becomes
much simpler. Since all data will be stored within the Cell Manager application, Line
Manager must simply aggregate this data and present a higher level view. The ability of
Line Manager to be customized is also a critical element to its success. The
76
specification calls for this application to allow for modules of functionality which can be
added or removed by individual customers. This modular concept of functionality is the
primary key behind the broad application of the software. With these generalized
software applications, ABB should be capable of achieving a much faster return on
investment, due to the ability to apply the software at a variety of factories.
5.3
Creating Lean Software
While the Cell Manager and Line Manager applications should provide improved
payback schedules for ABB, the next step in development is to consider the payback for
customers. As discussed in Section 5.1, it is critical for software applications to
establish links to the underlying business processes. However, if those business
processes are poorly designed, their automation with IT will not improve the customer's
bottom line. This was clearly explained by Michael Hoag when describing the Computer
Integrated Manufacturing movement [4]. Therefore, software applications must provide
tools to customers which allow them to improve their business processes. Specifically,
these solutions must promote lean manufacturing processes. Within his thesis, Michael
Hoag presented a host of possible applications to achieve this goal. For example,
Michael presented opportunities to develop software which provided WIP Tracking,
Kanban notification, and RFID monitoring of products. Each of these software concepts
were intended to improve the manufacturing processes and drive customers toward
more lean enterprises.
These same concepts have been proposed for the Cell Manager and Line
Manager applications. The most critical elements of functionality for this software relate
to the ability to track WIP and provide OEE for specific workplaces. While these pieces
77
of functionality are more difficult to develop, they will provide customers with
significantly improved returns due to the elimination of waste by going lean. Additionally
much work was completed with the Ratingen team in an effort to introduce lean
concepts to the current project development. This includes such topics as an electronic
Kanban system which is well suited for the build-to-stock nature of the Ratingen factory.
5.4
Web Services as an Alternative
The discussion of web services was intended to present an alternative method of
development for an MES system within ABB. The current development processes are
utilizing a combination of Visual Basic, AIP and SQL to create applications. While these
platforms are sufficient, they present significant problems when attempting to create
customizable software. In fact, Visual Basic is typically used as a tool for developing
very specific custom applications. Each piece of functionality is built into the software
and then compiled to create the executable file. While this is an excellent tool for
creating applications with specific functional requirements, it presents a challenge when
considering applications that must be customized to meet the requirements of varying
customers' needs. The best way to explain this statement is to provide an example.
Currently, ABB has developed a product called Optimize IT. This application, created in
Visual Basic, serves as a tool for calculating the OEE of a particular piece of machinery.
This is the only function that the program can complete. However, an MES-type
application such as Line Manager must be capable of performing a variety of functions,
such as WIP Tracking, OEE, equipment status, and many more. If every customer
desired the same pieces of functionality, this would not be a problem. Unfortunately,
this is not the case when considering MES applications, as each customer has differing
78
requirements. Therefore, pieces of functionality must be "turned on or off' based on the
requirements of a specific user. Visual Basic does not allow for this flexibility.
As described previously, one of the major factors behind broadly applicable
software is the ability to customize. Therefore, the project teams at ABB must utilize a
software platform which enables this ease in customization. Web services present a
unique opportunity for enabling this customization by allowing developers to focus on
modules of functionality. Within the web services framework, applications are simply a
combination of various pieces of functionality, which can be enabled or disabled very
easily. Because each piece of functionality has been created using a standard
programming framework, they can be called and enabled at will. This makes the
process of customization much easier.
Because web services are web based, they provide much improved flexibility
with regard to installation and connectivity. First, web services are thin clients. This
means that the applications (i.e. pieces of functionality) are run on a central server. The
information created from these applications is then presented via an Internet browser.
Therefore no software applications must be installed on a user's computer, saving a
tremendous amount of time and effort. Additionally, because the software is webbased, all information can be accessed from any location with an Internet or Intranet
connection. This allows the data to be provided across multiple factories or even
different companies/customers/suppliers along the supply chain. Obviously, the value
associated with this connectivity is tremendous. By developing MES applications within
a web services framework, ABB could significantly improve the acceptance of these
applications.
79
pendix A: Data Model for Cell Manager 2.0
assifiCation
Info
vide current status
Running
Sub-states
Normal operation
% of expected production
Reason I
Reason 2....
Functions
Sub-Functions
Display green light on main cell screen
Display yellow light on main cell screen & notify operator with alarm
Present reasons to operator for input & log reason in database with time stamp
Stopped
Machine Failure
Reason I
Reason 2...
Component I
Component 2
Temperature
Measurement
DataX
Display current process on main cell screen
Log temperature data for process 1
Log measurement data for process I
Log DataX for process 1
Measurement
Log measurement for quality station Present quality tolerances. Display reject screen.
WorkorderX
WorkorderY
Log workorder into inbox with time stamp.
WorkorderA
WorkorderB
Log workorder into progress with time stamp. Record workorder, product #, workstation
Break
Lunch
ReasonX....
Product
Setup/Adjustment
Preventative Maintenance
Product I
Process
Product 2....
Process I
Display red light on main cell screen. Notify operator and manager with alarm.
Log reason in database with time stamp
Display starved symbol on main cell screen. Nobly manager with alarm Log time stamp.
Display blocked symbol on main cell screen. Notify manager with alarm. Log time stamp.
Display idle symbol on main cell screen. Log time stamp.
Display break symbol on main cell screen. Log time stamp.
Display lunch symbol on main cell screen. Log time stamp.
Present reasons to operator for input & log reason in database with time stamp
Display setup symbol on main cell screen. Log time stamp.
Display maintenance symbol on main cell screen. Log time stamp.
Diplay current product in process on main cell screen.
Log component 1 serial number to product numbertworkorder.
Log component 2 serial number to product numberworkorder.
Starved
Blocked
Idle
Process 2...
Quality Station
Workorder
Enable quality check
list to operator.
Inbox
In Progress
Outbox
ver CelllWorkplace
culate,
States
information
store & display production Info
Information button
......
.....
Process Data
Process Instructions
Setup Instructions
Equipment Manuals
Maintenance Instructions
Maintenance Log
Preventative Maintenance Due Dates
Product Information
Emergency Contact Information
WorkorderC
WorkorderD
Process button
Setup button
...
Log workorder into outbox with time stamp upon completion.
Find and display information on current process being performed.
Find and display information on current setup instructions for specified product.
.....
Present Cycle Time
Average Cycle Time
Expected Cycle Time
Speed vs. Time History
Temperature
Pressure
Measurement
DataX
Graph
CalcJGraph
Graph
CaIcJData
Data(Graph
.....
......
Number Produced
Number ot Rejects
CalcJData
CalcJData
Find and display data from last completed product.
Pull data and calculate average for last X products produced. Display graph.
Find and display data on OEM standard cycle time.
Pull and present data for operation status for last: hour, shift, day, month, year
Pull and present data for temperature for last: hour, shift, day, month, year
Workorder Data
Calculate and display number of products produced this: hour, day, shift, etc..
Sum the number of rejects for last: hour, shift, day, month, year
Enable right click to view equipment picture
APPENDIX B: Functional Requirements of a Basic APS Package
APS FUNCTIONS
As with any product, it is critically important to understand the customer requirements in
order to develop appropriate functions for that product. The following table presents
both a proposed list of customer requirements and product features to satisfy those
requirements. The customer requirements can vary tremendously for different
companies within the same industry. Looking at the automobile industry provides us a
clear perspective. For example, the requirements of the GM Truck Assembly Plant in
Fort Wayne, Indiana will certainly be more complex than the requirements for a small
vendor that supplies door handles for the trucks. Within the truck assembly plant there
are potentially hundreds of thousands of processes that would require accurate
modeling and tracking. For the handle manufacturer, there might be ten or twenty
processes to model. Therefore the following list of customer requirements should be
considered a "representative sampling." This also stresses the fact that any APS
system should be developed in as generic a way as to cater to a variety of different
companies.
Customer Requirement
Allows planning of resources
Allows planning prior to commitment or execution of plan
Allows schedulinq of resources
Due date guoting
Hour by hour based planning
assembled and finished
WhatIf Capability
Finite Capacity / Heuristics / Forward / Backward / Mixed / Genetic Algorithm
Available to Promise / Qapable to Promise
"Drag and Drop" Scheduling Gantt Chart / Order Pegging / Real-time Order Status
Simple factory model
Account for the build up of Work In Process (WIP)
Planned raw material release date
Ability to track the quantity of
APS Feature
Sales & Operation Planning / Capacity Analysis
Flexible Model Building
Bottleneck Manaqement / Buffer Management / Real-time Order Tracking
Material Requirements Scheduling
roducts
Ability to schedule chanoeover, maintenance. and non-working hours
Ability to adust the resource's capacity and efficiency and labor standards
Ability to set the detail behind each work order
Issue the plan in the form of a report, email or Visual Manaaement display
Performance Measurement
Ability to identify Critical Constrained Resources
Size buffers in front of Critical Constrained Resources
Allow for exception handling - 'rush' material lead times, 'rush' capacity, oertime
Inventory Analysis
Flexible Model Building
Flexible Model Building
Real-time Work Order Dispatch
Crystal Reports Interaction ODBC, crv files
Analysis Graphs / Reports
Bottleneck Management
Buffer Management
Exception Management
Table 1: Customer Requirements and Resulting Features
81
Functions Overview
MESA International decribes the functions of an APS system as follows.
attributes,
priorities,
on
based
sequencing
"Provides
characteristics, and/or recipes associated with specific production
units at an operation such as shape or color sequencing or other
characteristics which, when scheduled in sequence properly,
minimize set-up. It is finite and it recognizes alternative and
overlapping/parallel operations in order to calculate in detail exact
time or equipment loading and adjust to shift patterns."
While this definition does in fact provide the premise behind any APS system, it lacks
much of the detail necessary to completely understand the functions of the system. A
more detailed definition describes APS systems as three integrated aspects; Factory
Modeling, Process Control, and Process Optimization/improvement.
" Factory Modeling - This function of APS systems should be thought of as
the ability to define actual plant processes in sufficient detail to provide
meaningful schedules for the plant. This requires that the software tool be
generic enough to apply to almost any situation.
" Process Control - This function of APS systems is defined as the ability to
create an appropriate schedule for customer demand via a proscribed
decision/calculation process. This piece of the functionality is the actual
scheduling process and can be achieved from a variety of tools, including
finite capacity scheduling, Heuristics-based scheduling or other tools. A
further analysis of this critical component is presented in the control section
below.
" Process Optimization/improvement - This piece of APS functionality
relates to the ability to improve plant performance by collecting and analyzing
historical and real-time data. This is first accomplished by ensuring that the
scheduling tool model accurately represents the actual plant processes.
Additionally, process optimization can be achieved by utilizing Key
Performance Indicators (KPIs) and other tools to focus the improvement
process. APS solutions contain many features for accomplishing this task,
including Real-time analysis and graphing, bottleneck management, capacity
analysis, yield management, inventory analysis, and others.
82
Factory Modeling
One of the main benefits of APS systems is the ability to overcome the limitations of
infinite scheduling. This is accomplished by accurately modeling the material, labor,
and resources of the plant. This should be considered the most critical aspect of an
APS system as it determines how well the model schedules processes within the plant.
There is no set methodology for modeling the plant, but many companies utilize a
system of basic blocks for defining each step of a process. These blocks are defined
pieces of time that could be attributed to anything from setup of a machine to molding
machine processing time to maintenance time for a particular machine. These blocks
are critical to improving the ability of the model to predict production times. By
constantly comparing the actual time versus predicted time to complete various tasks
under different load levels within the plant, the model can be continuously refined to
provide a more realistic picture of factory operations. This database of information is
often times the best tool for predicting future flow through the plant. Obviously, by
improving the detail (i.e. level of resolution) of each process, one can improve the ability
of the model to accurately predict flow through the plant. An enormous amount of
information can and should be utilized by APS systems. The list below presents some
of the inputs required to accurately model a factory.
" Workforce Availability (shifts/hours/days, breaks, holidays, training, etc..)
" Raw Material Availability (stock levels, re-order points, lead-times
(normal/rush), variance)
" Resource Availability (maintenance requirements, scrap rate, setup time,
teardown time, transfer batch size, repair time, etc..)
" Bill of Materials (BOM)
" Potential Routings (standard/alternative)
" VolumeNariety Forecast
83
Some APS systems take these basic blocks of time and assign them more specific
definitions to improve feedback on factory performance. For example, some systems
can analyze actual production time data and classify certain resources as critically
constrained (CCR). Additionally, specific blocks of time can be inserted into the factory
model to serve as buffers for this resource. Figurel below demonstrates a potential
"model" for flow around a CCR. Most, if not all, APS systems should incorporate the
ability to apply Theory of Constraint models such as the one presented below.
Buffer
CCR
Buffer
Figure 1: Critically Constrained Resource Flow Model
Process Control
The process of determining an "optimal" schedule for a factory is not completely
understood even today. A variety of dispatching rules and scheduling tools work under
different production situations. Therefore a host of potential techniques are available for
determining "optimal" schedules, and which technique works best depends on both the
type of facility (complex job shop vs. continuous production system) and the demand
levels. The word optimal is placed in quotes, because all scheduling systems make use
of heuristics and therefore are unable to truly create optimal schedules. The following
sections provide further detail on a few of the more familiar techniques for creating
production schedules.
84
Dispatching
The process of scheduling every job on every machine in a factory can become very
challenging. Dispatching of orders simplifies this process greatly, by sorting jobs
according to a specific order as they arrive at a machine. There are several ways of
dispatching jobs, all with varying levels of success. The simplest dispatching rule is
first-in, first-out (FIFO). As jobs come to a machine, the first job to arrive will be the first
to be completed. Simulation studies have shown that this rule does not work
particularly well in complex job shops. A second technique for dispatching is shortest
process time (SPT). Under SPT, jobs at a machine are sorted by the expected length of
processing time. Therefore, this type of dispatching has the effect of clearing out all the
small jobs before tackling the larger jobs. While this type of dispatching does decrease
average manufacturing times and improves utilization, the variance in average due date
performance is very high. This is due to the fact that some very long jobs continued to
get pushed out. One way to avoid this problem is to dispatch via the SPT rule. This
rule states that the next job to be completed will be the one with the least processing
time unless another job has been waiting for x time units or longer. A third type of
dispatching is by earliest due date (EDD). This rule works well under conditions where
all jobs are approximately the same size and have similar routings. Under EDD, the job
with the closest due date is the next job to be completed. In addition to these three
rules, there are at least 100 additional dispatching rules. For a good survey of these
different techniques, Blackstone et. al. (1982) evaluate each technique by using a
simulated factory.
85
Simulation-Based Scheduling
Many of the more advanced APS systems apply simulation-based scheduling. This
style of scheduling utilizes detailed and deterministic process times in an attempt to
model the entire system at a factory. Each step of a process is completely specified,
including setup and teardown time. Demand information for the model is pulled from
the master production schedule of ERP, as well as the current status of active jobs.
With this information, the model applies a variety of dispatching rules at each factory
station and evaluates the result against a set of objective functions. The list below
presents some of the potential objective functions that are commonly utilized.
"
Maximize profit
"
Maximize machine utilization
"
Minimize number of late orders
"
Minimize average lateness
" Minimize cycle time
" Minimize WIP
" Minimize Setup times
Once the objective function has been satisfied, the model stops and deems the current
schedule to be the "best." One of the main advantages to this type of scheduling is that
the model can generate a variety of schedules quickly, allowing the user to choose from
the schedule that best fits his/her needs. The main drawback to this model is the
enormous amount of data that must be constantly maintained. Setup times, processing
times, and other measures must be continuously recorded to ensure that they match
actual times as much as possible. This signals another of the larger problems with this
system. It does not account for variability between the actual and predicted times.
86
However, virtually all finite scheduling systems ignore this variability. One method for
reducing errors associated with variability is to regularly run and regenerate the
schedule.
Bottleneck Scheduling ("Drum, Buffer, Rope")
Bottleneck Scheduling is often referred to as one form of optimization-based scheduling.
The main difference between optimization and simulation based scheduling is that
optimization based techniques rely on an algorithm to search for the best possible
schedule. Bottleneck scheduling involves four basic stages:
1.
Determine the bottleneck for the shop
2. Propagate the due date requirements from the end of the line back to the
bottleneck using a fixed lead time with a buffer.
3. Maximize the utilization of the bottleneck
4. Propagate material requirements from the bottleneck backward to the front of
the line using a fixed lead time to determine a release schedule.
This type of scheduling is often referred to as "Drum, Buffer, Rope" scheduling, based
on its origins within the Theory of Constraints. The drum represents the bottleneck for
the plant, and limits the flow of production through the plant. Therefore, the drum sets
the beat for production (i.e. the rate at which product can flow through the plant). The
buffer is required to ensure that the bottleneck is never starved for product to process.
This can come in the form of either an inventory buffer (i.e. ensuring that WIP is
constantly sitting in front of the bottleneck) or a time buffer. The rope is utilized to
ensure that all other resources in the plant are coordinated with the drum. The rope is
similar to a Kanban type system where just enough material is released to satisfy
demand.
87
Heuristic-Based Scheduling
As mentioned previously, optimization-based techniques utilize an algorithm or heuristic
to arrive at a solution. Within the APS community, there are hundreds of possible
optimization-based heuristics. One entire class of solutions is based on the branch and
bound problem and simplifications to that problem. A branch and bound problem is
defined by selecting a partial schedule (i.e. a branch) and then setting a lower limit (i.e.
bound) on the makespan that can be achieved by using that partial schedule. In this
case, if the bound on a branch exceeds the makespan of the best schedule found so
far, that branch is no longer considered. This can become computationally difficult due
to the number of potential branches. Therefore, many other heuristics have been
developed to minimize the computation time. For example, the beam search checks
only a few branches that have been selected by some intelligent criteria.
Another class of optimization-based heuristics is termed local search techniques.
These solutions begin with a given schedule and then search in the neighborhood of
this schedule to attempt to find a better schedule. However, a simple neighborhood
search does not typically work well, as there tends to be many poor schedules that look
good in a local neighborhood. One potential correction to this problem has been termed
the tabu search. This search prevents the most recent schedules from being selected
and forces the solution to look further than just in the local area. The use of genetic
algorithms is another technique for preventing local optima. In this case a set of
"parent" schedules are used to generate "offspring" or new schedules. Then only the
best offspring are allowed to survive and reproduce new schedules. A host of other
techniques are also available to the scheduler, but will not be discussed within the
88
context of this paper. Additionally, similar to simulation-based scheduling, these
heuristic techniques attempt to satisfy objective functions, such as maximizing resource
utilization and minimizing average late orders. To gain a better understanding of which
solutions work well in various settings, please refer to Operations Scheduling by Pinedo
and Chao (1999).
Due Date Quoting
Although all of the previously mentioned systems assist production schedulers in finding
the "best" available schedule, they still contain one big limitation. If the schedule
released from the MPS system is infeasible, then no amount of scheduling or
optimization will yield a feasible schedule. Due date quoting is a technique which is
utilized to solve this problem, but requires much more integration than a simple
scheduling program. It also requires one to be capable of specifying reasonable due
dates, which sometimes proves to be a daunting challenge. Due date quoting attempts
to encompass the functionality of MPS, MRP, and APS. This system is a real-time
system which uses the current capacity utilization in the plant, and other features to
determine the lead time to quote to customers. By extending the system all the way to
the customer quote, due date quoting is capable of ensuring feasible schedules, that is
if the system is capable of reliably predicting due dates. Due date quoting constantly
adjusts the lead times it offers to customers by analyzing the current capacity levels in
the plant and the current schedule. Many APS systems term this functionality Capable
To Promise (CTP). This differs from Available To Promise (ATP) type solutions that are
present in MRPII systems. ATP solutions provide due date quoting based on both the
finished goods inventory and the WIP. CTP solutions extend this functionality, by
89
considering both the on-hand parts availability and availability of parts down the supply
chain.
Process Optimization-Improvement
The final aspect of an APS system deals with optimization and improvement of
processes within the factory. These tools are intended to provide the user with
information for continuous improvement. The variety of improvement tools available
within different software packages is rather large, and therefore, no single APS system
contains all potential improvement tools. Additionally, it would prove impossible to
describe each tool in length, so the following sections break these tools into specific
categories and presents a representative sampling of potential applications.
Real-time Controls
Real-time controls deal with applications that are updated at a minimum of every hour.
These tools are mainly centered on automating parts of the production process and
providing assistance to plant personnel. The following list details a few of the real-time
controls available in APS systems.
" Order Status/Tracking - Allows users to see real time information on where a
particular order is in the production plant.
" "Drag and Drop" Scheduling - Many APS systems employ a real-time Gantt
chart that allows users to see immediately where every job is in the process.
This tool also allows users to change prioritization of jobs and processing of
jobs by dragging and dropping them in place.
*
Work Order Dispatch - This is an automation tool that dispatches work orders
to the appropriate personnel when an order is released.
*
Capable to Promise - Provides users with immediate lead-time information for
product delivery.
90
System Management
System Management tools are applications that collect data and provide users with
assistance in finding areas of improvement. The list below provides information on a
variety of available diagnostics.
*
Buffer Management - Calculates and allocates (or recommends) appropriate
buffer sizes to ensure appropriate customer service levels.
" Exception Management - Provides visibility, monitoring, alerting, and analysis
of the extended factory. Some systems not only identify a problem but also
attempt to provide resolution paths and simulation capabilities.
"
Bottleneck Management - Provides the ability to determine the location of
bottlenecks and tracks if bottlenecks move. These systems typically also
provide assistance in the appropriate way to schedule bottlenecks.
*
Capacity Planning - Analyzes machine utilization information and other data
to assist in planning for future demand.
" Operations Planning - Analyzes operations data to assist in planning for
future demand.
"
Inventory Analysis - Attempts to optimize the levels of inventory maintained
within the factory.
Performance Measurement
Performance measurement refers to the tracking and presentation of data on key
performance indicators. Unlike system management tools, these tools only provide
information and offer no assistance in finding solutions to identified problems. The list
below presents some of the analysis graphs and data that are typically provided within
APS systems.
" On-time delivery percentage
" Machine utilization
" Throughput rate
" WIP
" Cycle Time
91
.
Lead Time
*
Machine Yields
Feature Set for Basic APS Implementation
The goal of this section of the paper is to define a reasonable feature set for a basic
APS application. Using the term "basic"' does not mean that the system is overly
simple, but does signify that it contains only the most critical functions. While the
capabilities of the system defined would not be suitable for the most advanced users
(i.e. Dell Computers), it could certainly be applied to a variety of manufacturing
situations. Additionally, the feature set described below represents the opinion of the
author. Another opinion could yield a feature set that either contains more or less
functionality.
"
Flexible Model Building - The basic system must include some form of user
interface for customizing the factory model to specific customer needs. The
simplest form of this would be a flowchart type system where the user can
build from scratch a flow of processes and machines for a particular
production line.
*
Rules-based Finite Capacity Scheduling - The basic system should allow
users to select between at least two types of rules-based finite capacity
scheduling, Bottleneck Scheduling and some form of Simulation-based
Scheduling. The simulation-based package should be capable of applying a
variety of dispatching rules at individual workstations to model the factory. A
nice feature would be to allow users to input their own dispatching rules that
might be more applicable to their particular situation. Bottleneck scheduling
should include some resources to assist with identification of bottlenecks and
management of buffers and scheduling of upstream and downstream
resources.
Visual Planning Board - The basic system should include some visual
method of viewing jobs as they move through the factory. This is required to
allow planners/schedulers to immediately view and react to any problems.
This visual planning board should include functionality to allow a scheduler to
analyze the impact of accepting a rush order or anticipate changes if a piece
of equipment fails. This board should also allow the scheduler to move
operations, split batches, and add overtime if necessary. The figure below
demonstrates one possible method of providing visual job management.
*
92
--- D2
.P4MA
Screenshot courtesy of Prof@x website.
What-if Analysis - While many people would consider what-if analysis to be a
complex function, almost every APS systems contains some form of this
functionality. The basic APS system should include some tools for analyzing
the pros and cons of different scheduling strategies. A simple system would
provide basic information such as number of late orders or average days late
for a variety of dispatching options.
*
Work-order Dispatching - The basic system should include functionality to
output the schedule to the required people. The simplest form of this would
be to print the required workorders directly from the system. A more
advanced model might include the ability to email workorders to the required
locations.
*
Analysis - The basic system must include the ability to store and present
historical data on a variety of key performance indicators (KPIs). These KPIs
could include data on waiting times, stock levels, machine utilization, planned
vs. actual reports, material usage and others. A more advanced package
would also include the ability for customers to create their own graphs and
reports based on their needs.
*
Systems Integration - The basic system must
allow for the integration to the other systems.
code should be necessary. In other words, an
site should be capable of setting up the required
include some functions that
No changes to the internal
IT manager at any customer
links to various databases.
93
Future Trends in APS
Once ABB commits to developing and selling an APS product, the company must
immediately begin to consider what functionality will be required in the future. This will
be necessary to maintain a happy customer base and keep up with competitors. While
it might seem premature, I believe that a brief discussion of the future trends in APS
would prove useful. A great deal of information on the future of manufacturing systems
has been collected and documented by a two year research project (1999-2000) in the
United States termed the Integrated Manufacturing Technology Roadmapping (IMTR)
initiative. This two-year study was conducted by interviewing over 400 manufacturing
experts from over 170 companies, government agencies, and industry associations.
The goal of the project was as follows: "to lay out a comprehensive plan for research,
development, and implementation of manufacturing technologies that will benefit all
sectors of industry by providing quantum improvements in efficiency, flexibility,
capability, and competitiveness." Table 3 below presents a state map for process
planning and execution.
94
- Manual Process Planning
Current
State of
Practice
(2000)
- PC-based planning systems using templates
- Automated process planning systems using
both "variant" and "generative" approaches
- Scheduling approaches vary widely, from
informal manual techniques to commercial
MRP systems
- Advanced MRP & ERP systems for scheduling
Current
State of Art
(2000)
- Finite Scheduling
- Support for large scheduling systems is major
expense
- Enhanced Logistics
- Knowledge- & feature-based process planning
Expected
2005 State
systems
- Scheduling optimized based on orders, WIP &
profit
- Generative, controller-level process planning
coupled to product models
IMTR 2015
Vision
- Simulation models used to optimize process
planning
- Adaptive modification of process plans
based on workload & equipment availability
Table 3: State map for Process Planning and Scheduling (IMTR Roadmap)
Additionally, there are four major initiatives currently taking place that will set new
standards within the APS community. First, many companies are shifting from
client-server based software systems to thin client systems. The intent here is to
utilize the power of the Internet to improve communication throughout the
company or enterprise. Several players have built complete APS packages from
the ground up using web-based techniques (webPlan, SynQuest, Syncra).
Second, the most significant initiative involves improved collaboration throughout
the supply chain. As parts of the supply chain begin to take a more active role in
95
supplying real-time data to an enterprise, the supply and demand plans will
become more accurate. This collaboration will also allow the supply chain to
react quicker and more efficiently to changes in the demand curve. Third,
companies such as Manugistics have begun to integrate pricing/revenue
optimization with supply chain planning in an attempt to meld the operations and
marketing departments. The thought here is that the ability to model the cause
and effect of marketing changes on the supply chain will improve the strategic
decision making process. Finally, as more companies move toward global
operations, supply chain planning must begin to incorporate the ability to better
evaluate the impact of sourcing and distribution to foreign countries. As a result
APS solutions will need to become more tightly integrated into transportation and
logistics systems.
96
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
Hayes, Brian Terrabyte Territory. Computing Science, May-June 2002.
Sargeant, Roland Manufacturing Execution Software Specification. Internal ABB
document, August 2002.
Unknown Author Inside Industrial IT Internal ABB presentation.
Hoag, Michael Improved Integration of Information in Discrete Part Manufacturing
Environments. LFM Thesis, June 2002.
Unknown Author, Internal ABB Visio Specification Drawing for Lodz project.
Ratingen Project Application Screenshot, September 2002.
Staff Report The ABCs of Industrial IT. ABB Review, Number 1, 2002.
Sargeant, Roland Internal ABB document, June 2002.
Dahl, Ole-Johan and Nygaard, Kristen How Object Oriented Programming Started.
Available from
http://heim.ifi.uio.no/-kristen/FORSKNINGSDOK MAPPE/F 00 start.html
[Accessed 21 February 2003]
McConnell, Steve Code Complete. Microsoft Press, Redmond WA. 1993, pp. 152.
Unknown Author Industrial IT Fundamentals. Internal ABB presentation.
Unknown Author, Internal ABB Presentation.
Staff Report An Executive's Guide to CRM. The Patricia Seybold Group, 2002.
Simchi-Levi, David Designing and Managing the Supply Chain. McGraw-Hill
Higher Eductation, 2000, Chapter 10.
Martin, J. and Roth, R. Supply Chain Management Development Strategy, ECRU
Technologies, 2000.
Seay, Jason Advanced Planning and Scheduling Specification Internal ABB
document, August 2002.
Hopp, Wallace and Spearman, Mark Factory Physics. McGraw-Hill, Boston, 2001.
Unknown Author What is Fieldbus? Available from www.yokogawa.com/fieldbus
[Accessed 23 February 2003].
Unknown Author Profibus. Available from www.softin.com [Accessed 23
February 2003].
Unknown Author OPC Technical Overview. OPC Foundation, 1998.
Unknown Author OPC Product Overview. Softing, May 2002.
Unknown Author MES Explained: A High Level Vision. MESA International, White
Paper #6, September 1997.
Sargeant, Roland and Seay, Jason MES for Discrete Manufacturing: An
Overview. Internal ABB document, August 2002.
Bayoumi, Deia lIT in Distribution Transformer Manufacturing. Internal ABB
presentation, 2001.
Unknown Author Produce IT Cell Manager Product Description, Internal ABB
document, September 2002.
Barefoot, Darren Web Services Primer. Available from
http://www.capescience.com/education/primer/index.shtml [Accessed 20 March
2003]
Greenspan, Jay Introduction to XML. Available from
http://hotwired.lycos.com/webmonkey/98/41/index1a.html [Accessed 20 March
2003]
97
[28] Unknown Author .Net Developer Training. Microsoft presentation 2002.
[29] Roberts, John The Business Value of /T Vendors. Gartner Research, Note DF
18-9870, January 2003.
[30] Robb, Drew Rediscovering Efficiency. ComputerWorld, Vol. 35, Issue 29., pp. 54.
[31] Prouty, Kevin AMR Research Note, 2001.
[32] Unknown Author ABB Form 20-F. File with Securities and Exchange
Commission, Washington D.C., June 2002.
98