A Web-Based Material Requirement Planning Integrated Application
Liao Qiang, Tham Chen Khong, Wong Yoke San, Wang Jianguo, Chris Choy
Laboratory for Concurrent Engineering & Logistics (LCEL)
Department of Mechanical Engineering
National University of Singapore
10 Kent Ridge Crescent, Singapore 119260
E-mail: mpeliaoq@nus.edu.sg
Abstract
The paper exploits distributed object technology to
develop an enterprise application that integrates material
requirement planning (MRP) with job shop simulator. The
application aims to realize an integrated system that has
rapid response to changing requirements and capability
to integrate heterogeneous manufacturing facilities. At
first, the application accepts the customer’s order and
performs material requirement planning. Then MRP
dispatches daily planned order to job shop that carries
out real-time scheduling and production. At the same
time, MRP sends order to supplier for purchasing raw
materials. After completing production task, the job shop
returns the relevant information about finished parts.
Once the customers add or modify orders, MRP system
will update data automatically to respond to the changes
of customer requirements rapidly. The Unified Modeling
Language (UML) is applied for analyzing and designing
total application in which MRP subsystem uses Enterprise
Java Beans (EJB) that are deployed in a J2EE compliant
application server to perform Business-to-Customer
transactions and MRP logic, while the job shop subsystem
uses Common Object Request Broker Architecture
(CORBA) specification as communication platform.
1. Introduction
Due to the customized production, shorter product life
cycle and frequent process reengineering, today’s global
business competition is imposing special requirements to
manufacturing enterprises, such as rapid response to
changing requirements, reduction in both time and cost of
the product realization process.
In addition, most of the manufacturing enterprises are
often heterogeneous with respect to computer platforms,
operating systems, network capabilities, and custom and
commercial software. Further, it may be geographically
distributed across a wide area. The information
architecture itself must be scalable, interoperable and
reconfigurable. Internet technology, electronic data
exchange, and industry standards for interoperability will
be core to the infrastructure [1].
The application developed in this paper aims to realize
an integrated system which has rapid response to
changing requirements and capability to integrate
heterogeneous manufacturing facilities.
The application consists of two subsystems as follows:
•
Web-Based Material Requirement Planning
(MRP)
The paper utilizes several emerging technologies such
as Enterprise Java Beans (EJB) as well as Extensible
Markup Language (XML) technology to establish a webbased MRP system that considers the process that begins
when an order is placed by a customer and ends with the
production of the corresponding item. All works are done
on server-side. Three kinds of users, i.e. customer,
administrator and supplier may access this system
through web browser from anywhere and at anytime in
the world.
•
CORBA-Based Job Shop Simulator.
To simulate the real heterogeneous manufacturing
environment, the paper use CORBA as communication
platform to develop a job shop simulator in which
CORBA objects represent corresponding manufacturing
devices.
After receiving the customer’s order, MRP system
performs material requirement planning. Then MRP
dispatches daily planned order to job shop that carries out
real-time scheduling and production. On the other hand,
MRP sends purchased order to supplier for needed raw
materials. After completing production task, job shop
returns finished parts to MRP. Once the customers add or
modify orders, MRP system may update data
automatically so as to rapidly respond to change of
customer requirement.
The paper describes how to use distributed object
technology to develop modularized, distributed,
configurable and maintainable enterprise application.
First, section 2 presents the architecture of overall system.
Then section 3 focuses on MRP subsystem, including
MRP logic, XML-based Bill of Materials (BoM) file,
three-tier architecture, EJB overview and Model-ViewController (MVC) based design pattern. In addition, the
paper also uses Unified Modeling Language (UML) to
analyze and design the MRP subsystem. The section 4
introduced CORBA-based job shop object model. The
section 5 describes the communication means between
MRP with Job Shop. The section 6 presents
implementation and evaluation of the application. At last,
the summary and conclusions are presented in section 7.
process that begins when an order is placed by a customer
and ends with the production of the corresponding item.
Figure 2 illustrates the web page of order input. The major
components of the MRP are the Master Production
Schedules (MPS) and the Bill of Materials (BoM), which
will be discussed in this section.
2. Overall System Architecture
The application consists of two subsystems: MRP
subsystem, and job shop simulator subsystem. The overall
system architecture is shown in Figure 1. At first, the
application accepts the customer’s order through the B2C
web front. In the backend, material requirement planning
will be performed. Then MRP dispatches daily production
jobs to job shop that carries out real-time scheduling and
production. On the other hand, MRP sends purchased
order to supplier for needed raw materials. After
completing production task, job shop returns finished
parts to MRP that may adjust some initial parameters like
lot size, lead time to meet requirement of order from
customer. The overall system architecture is shown in
Figure 1.
Database
Supplier
Internet
Customer
MRP
Figure 2: Input of Customer Order
3.1 MPS Logic
The MPS is a time-phased statement that contained
numerous fields for each time unit called a “bucket”. One
bucket is one day in this paper. Each time bucket
consisted of the following fields – gross requirement,
scheduled receipt, on-hand inventory and planned order
release. Gross requirement is total actual demand for that
item at that time. Scheduled receipt indicates the expected
units that will be completed at that time. Planned order
release indicates the suggested amount of units to order
from the job shop. With the knowledge of time-phased
gross requirements, scheduled receipts and other MPS
parameters, the rest of the MPS can be filled out. An MPS
snapshot from the application is shown in Figure 3.
Job Shop Model
Figure 1: Overall System Architecture
3. MRP System
MRP is a computer modeling technique that allows for
demand-driven production plans to be made. It determines
what to produce, when to produce and how much to
produce. We implement a MRP system that considers the
Figure 3: An MPS Snapshot from the System
Figure 4: BoM Hierarchy Structure for Product A
Explosion of requirements in MRP programs flows
down through component levels following the linkage
specified in the BoM structure. The planned order release
of a parent item multiplied by the quantity of the child
item that goes into the making of one parent item, become
the gross requirement of the component required at the
next level. Explosion of requirements can be viewed as a
recursive procedure, whereby the same process is done
for each item, whose parent item’s production schedule
has undergone a change. Once the BoM is detected to
have zero components, the item is recognized a purchased
item and no further explosion took place [2].
3.2 XML-Based BoM
The Extensible Markup Language (XML) is a universal
standard for structuring content in electronic documents.
XML is extensible, enabling businesses to add new
structure to their documents as needed. The XML
standard does not suffer the version control problems of
other markup languages such as HTML because it has no
predefined tags. Rather, with XML you define your own
tags for your business needs. XML is a meta-markup
language because you can define your own markup
language that is self-describing. This makes XML the
ideal document format for transferring business data
electronically [3].
Bill of Material (BoM) is a special hierarchy structure
that has inherent similarity with XML file, so we use
XML to describe BoM data. As a sample, the Figure 4
shows hierarchy structure of BoM for product A. Product
A consists of two subassembles, SA1, SA2, which consist
of part P1, P2, P3, P4 respectively. The number shown in
the diagram represents needed quantity. For example, the
number 2 above part P1 represents that every subassemble
SA1 needs two part P1. Similarly, the number 4 above
part P3 represents that every subassemble SA2 needs four
part P3.
The following is BoM file of product A written in
XML.
<BOM>
<product name="A">
<subassemble name="SA1"quantity=”2”>
<part name="P1" quantity="2"></part>
<part name="P2" quantity="1"></part>
</subassemble>
<subassemble name="SA2" quantity=”3”>
<part name="P3" quantity="4"></part>
<part name="P4" quantity="6"></part>
</subassemble>
</product>
</BOM>
The file is plain TEXT format that can be read and
written in any platform. We use Java language that is
inherently platform-independent to access this BoM file
with Document Object Model (DOM) specification. So
that, we can conveniently read BoM file no matter what
platform it resides on.
3.3 Three-Tier Architecture of MRP System
In this paper, MRP is a web-based and server-side
application that is partitioned into three-tier in terms of
application logic. Each layer has a different responsibility
in the overall deployment, and within each layer there can
be one or more components.
•
•
Business Logic Layer contains components that
work together to solve business problems. In this
paper, these components are Servlets as well as
Enterprise Java Beans (EJB) that include Session
Beans and Entity Beans.
•
Data Layer that is used by the business logic layer
may persist state permanently. Central to the data
layer is one or more databases that house the stored
state.
Product
A
2
3
Subassemble
SA1
2
Subassemble
SA2
1
Part
P1
Part
P2
6
4
Part
P3
Part
P4
The layer partitioning is as follows:
Presentation Layer contains components dealing
with user interfaces and user interaction. The
presentation layer of a web-based deployment could
use HTML pages, Java Server Pages, and/or Java
Applets.
The advantage to partition the application into these
logical layers is to isolate each layer from the others. For
example, it should be possible to plug in a different view
(i.e., change the presentation layer) while minimizing
impacts on the business logic or data layers. It should
similarly be possible to plug in a different set of business
rule component implementations within your business
logic layer, or to plug in a different database in your data
layer, with relatively minor effects on the other layers [4].
In this paper, the three-tier architecture is shown in Figure
5.
application. The "view" is the component that handles the
user interface display. That's our JSP. And finally, the
"controller" is the traffic cop that provides a single control
point from which worker components are dispatched.
Figure 6 depicts the MVC design pattern.
Web Browser
Presentation Tier
Business Logic Tier
Data Tier
Servlet
(Controller)
Entity Beans
EJB
(Model)
Session Beans
Servlets
Session Beans
Web Browser
Web Server
Database
Application Server
JSP(View)
Figure 5: Application 3-Tier Architecture
3.4 Enterprise Java Beans (EJB) and Design
Pattern
It has always been very difficult to write distributed
application for the enterprise that would run in a reliable
and guaranteed fashion and be executable on all
platforms. Currently the Java 2 Enterprise Edition (J2EE)
has been seen as the standard for enterprise applications
henceforth. In J2EE, the Enterprise Java Beans (EJB)
component architecture is designed to enable enterprises
to build scalable, secure, multi-platform, business-critical
applications as reusable, server-side components. Its
purpose is to solve the problems described above by
allowing the enterprise developer to focus only on writing
business logic. In a distributed enterprise application,
there may be many complications such as instance
initiation, multithreading, security considerations, load
management and so on. The application server handles all
these and the options need merely be set as flags.
Figure 6: MVC Design Pattern
3.5 Use Cases
The whole system is modeled by using Unified Model
Language (UML). According to the architecture of
system, there are three kinds of users who will use this
system. They are: Customer, Administrator, and Supplier.
Different user has different use case. Use cases of the
three kinds of users are as follows.
Use case for Administrator is shown in Figure 7.
Administrator’s main responsibility is to manage
customer’s order, edit BoM and process plan, and perform
material requirement planning.
Login
<<include>>
Orders Management
Order Items
<<include>>
EJB covers two fundamental models for building
enterprise applications. Session Beans cover the first
model. A Session Bean is an object that represents a
transient conversation with a client. Entity Beans cover
the second model. An Entity Bean represents data in a
database, along with the methods to act on that data [5].
Bill of Materi al Editor
<<include>>
BoM Items
Process Plan Editor
Administrator
Process Plan Item s
Finished Parts
We use model-view-controller (MVC) design pattern to
the MRP application. The MVC paradigm was originally
developed to map the traditional input, processing, and
output tasks to the graphical user interaction model.
However, it is straightforward to map these concepts into
the domain of multi-tier applications.
<<include>>
Planned Order
Material Requirement Plan
Manufacturing System
Check Production Status
Each part of an MVC design has an independent role.
The "model" is the business policy implemented by the
Figure 7: Use Case Diagram for Administrator
3.7 Object-Oriented Analysis
Use case for customer is shown in Figure 8. Customer
can input order by using web browser and check order
status.
Browse On-Line Catalog
Based on above use cases and sequence diagram, further
object-oriented analysis can be performed. Here we only
present the object-oriented analysis for Administrator , as
shown in Figure 11.
<<extend>>
Place On-Line Order
Order File Upload
Customer
Master Production Schedule is designed as a Session
Bean that invokes other Entity Bean and performs MPS
logic. BoM, Customer Order, Process Plan and Inventory
Data are designed as Entity Bean because they represent
persistent data.
Check Order Status
All these Enterprise Java Beans reside in Application
Server that can supply valuable services like security,
transaction management, and scalability. In this way the
whole system may obtain excellent performance.
Modify Personal Information
Figure 8: Use Case Diagram for Customer
Use case for Supplier is shown in Figure 9. Supplier
may receive the purchase orders from MRP system by
using web browser.
<<entity>>
Bi ll of Material
1
1
1
1
<<include>>
<<control>>
Manufacturing Subsystem
1..n
<<entity>>
Customer Order
1.. n
<<entity>>
Bill of Material Items
0..n
<<entity>>
Customer Order Items
1..n
1
<<entity>>
Inventory Data
1..n
<<entity>>
Inventory Items
1..n
<<entity>>
Process Plan
Supplier
1..n
1
<<control>>
Mast er Production Schedule
1
Purchased Orders
1
1..n
1
1..n
<<entity>>
Process Plan Items
Order Items
Figure 9: Use Case Diagram for Supplier
Figure 11: Class Diagram for Administrator
3.6 Sequence Diagram
According to use case, the corresponding sequence
diagram can be designed. To save the space, only the
sequence diagram for administrator is shown in Figure 10.
: Verify Login
: Administrator
: Master Production
Schedule
Initial Data
Login
Is Administrator
Get Initial Data
: Manufacturing
Subsystem
Include:
Inventory Data,
Process Plan,
Bill of Material,
Customer Order
Perform MPS Algorithm
Send Planned Order
Return Production Result
Update Planning Result
Figure 10: Sequence Diagram for Administrator
4. Job Shop Object Model
4.1 Job Shop Architecture
The job shop simulator is developed using the objectoriented paradigm. Petri Nets is used to model the job
shop. Its various components such as Place, Transition
and Tokens are developed as generic Java objects in the
simulator and they serve as the building blocks for the job
shop model. In addition, each of them are further
categorized into different types and having different
functions. A complex job shop consisting of a central
storage, several workstations and a material handling
system is shown in Figure 12. In this paper, four
workstations are used. As such, the shop floor network
that is simulated consists of 6 distributed modules
including the central storage module and the material
handling system module.
development, especially in heterogeneous distributed
computing environment like the enterprise network.
Workstation
1
Arrival
Process
Central
Storage
Material
Handling
System
(Input)
Workstation
2
Material
Handling
System
(Output)
.
.
.
Workstation
n
In our job shop model, all devices are modeled as
CORBA objects, and these objects can be dynamically
added to or deleted from manufacturing system network
with CORBA technology. An object not only acts as a
client, but also as a server. For example, when
workstation request service to Central Storage, it acts as
client, but when Central Storage request service to
Material Handling System, it acts as server. CORBA
Object model is shown in Figure 13.
Figure 12: Job Shop Architecture
4.2 CORBA-Based Communication Platform
Central Storage
Object
Workstation
Object
Three main distributed object services are available
today: CORBA, Java RMI, and DCOM. Each of these
services uses a different Romote Method Invocation
(RMI) network protocol, but they all accomplish basically
the same thing: location transparency.
DCOM is primarily used in the Microsoft Windows
environment and is not well supported by other operating
systems. Its tight integration with Microsoft products
makes it a good choice for Microsoft-only systems.
Java RMI is a Java language abstraction or
programming model for any kind of distributed object
protocol. Java RMI may be used with almost any
distributed object protocol, but in practice Java RMI has
traditionally been limited to the Java Remote Method
Protocol (JRMP) – known as Java RMI over JRMP –
which can only be used between Java applications.
CORBA is neither operating-system specific nor
language specific and is therefore the most open
distributed object service of the three. On the other hand,
a CORBA client can be written in any language, including
C++, Smalltalk, Ada, and even COBOL, so it’s an ideal
choice when integrating systems developed in multiple
programming languages [6].
Object Request Broker (ORB)
Workstation
Object
Material Handling
Object
Workstation
Object
Figure 13: CORBA Object Model of Job Shop
4.3 Object-Oriented Design for Job Shop Model
The object-oriented technology is used to design the
job shop model. First, a base class Abstract Device
defines some basic attributes and methods. Then three
classes for job shop elements: Workstation, Central
Storage, Material Handling System are defined
respectively to inherit from class Abstract Device. The
inheritance relationship between classes is shown in
Figure 14.
Abstract Device
Device_Name
IP_Address
Port
As a platform-independent and language-independent
distributed object protocol, CORBA is often thought of as
the superior of the three protocols discussed here.
In addition, CORBA’s object-oriented property can
make application development or integration reusable and
extensible. At the same time, CORBA is evolving towards
a standard as component bus where software components
and applications can be ‘plug & play’ into the object
request broker just as what has realized in the hardware
bus. This property will cause the revolution in software
Workstation
Object
init()
Workstation
Machine_ID
Current_Status
init()
produce()
Central Storage
Buffer_Quantity
Unused_Buffer_Number
init()
load()
unload()
Material Handling System
AGV_Quantity
Unused_AGV_Number
init()
transfer()
Figure 14: Class Diagram of Job Shop Model
Figure 16: Class Diagram of CORBA Object
5. Communication Between MRP and Job
Shop
After accomplishing MRP computing, MRP system
needs to send the daily planned order to the job shop. In
addition, because customers may add, modify orders with
web browser at any time, the computing results of MRP
system should be updated to reflect the changes of
customer orders. We design a thread that can monitor the
change of customer order. Once the customers add or
modify orders, this monitoring thread will invoke MRP
system to update data automatically. Then MRP system
initiates a CORBA client object that communicates with
CORBA server object residing in the job shop system to
send jobs for processing. When order is completed , the
CORBA client residing in the job shop will communicate
with CORBA server residing in MRP system to return
finished jobs to MRP system. Then the CORBA server
residing in MRP system sends relevant data to database or
other objects. The communication interface is shown in
Figure 15.
MRP
Job Shop
Monitor
Thread
Input of
Customer Order
Servlet
SendJob
CORBA
Client
CORBA
Server
6. System Implementation and Evaluations
Based on above analysis and design, a complete system
has been successfully developed at the Laboratory for
Concurrent Engineering and Logistics, National
University of Singapore. The iPlanet Web Server and
Application Server are used as platform of the application.
The Visibroker ORB is used as the CORBA ORB for the
job shop simulator. The experiment shows that the
integrated system can rapidly respond to Customer’ order.
On the other hand, the MRP system can effectively
collaborate with Job Shop to meet requirement of
production.
7. Summary and Conclusions
In this paper, an enterprise application is developed to
integrate MRP system with job shop simulator by using
distributed object technology. The development procedure
consists of System Analysis, Object-Oriented Analysis,
and Object-Oriented Design. The UML is extensively
used through the entire procedure. The promising
Enterprise Java Beans specification is presented. In
addition, several emerging technologies such as XML,
CORBA are introduced. According to the testing results
of the application, it shows that the proposed system has
good performance in terms of response to customer.
ReturnFinishedJob
CORBA
Client
CORBA
Server
Database
References
Figure 15: Communication between MRP System
with Job Shop
Figure 16 shows the class diagram for CORBA client
that is in charge of dispatching planned order to job shop .
Thread
ServerThread
org.omg.CORBA.ORB orb
ServiceImpl()
setSS()
void run()
ServerThread()
JFrame
ServiceImpl
String flag
int partID
Frame1
contentPane
jTextField1
jLabel1
jButton1
Frame1()
init()
MonitorServer
Frame1 frame
main()
MonitorServer()
Timer
Frame1 frame1
long elapseTime
Timer()
run()
[1] Whiteside, R.A., Pancerella, C.M., Klevgard, P. “A
CORBA-based manufacturing environment”. System
Sciences, Proceedings of the Thirtieth Hwaii International
Conference, Hwaii, 1997, vol.1, pp. 34-43.
[2] George Plossl. Orlicky’s Material Requirement Planning.
New York: McGraw-Hill, Inc., 1995.
[3] J.P. Morgenthal, Bill la Forge. Enterprise application
integration with XML and Java. Upper Saddle River, N.J.:
Prentice Hall PTR, 2000.
[4] Ed Roman. Mastering Enterprise JavaBeans. New York:
John Wiley & Sons, Inc, 1999.
[5] Richard Monson-Haefel. Enterprise Java Beans.
Sebastopol, CA: O’Reilly & Associates, Inc., 2000.
[6] Jon Siegel. Corba 3 fundamentals and programming. New
York: John Wiley & Sons, Inc, 2000.
[7] Daniel Sipper, Robert Bulfin. Production: planning,
control, and integration. New York: The McGraw-Hill
Companies, Inc., 1997.
[8] Meng Chu Zhou, Kurapati Venkatesh. Modeling,
simulation, and control of flexible manufacturing systems:
a Petri Net approach. Singapore: World Scientific, 1997.
[9] Andreas Drexl, Alf Kimms. Beyond Manufacturing
Resource Planning (MRP II): advanced models and
[10]
[11]
[12]
[13]
[14]
[15]
[16]
methods for production planning. New York: Springer,
1998.
Darryl V. Landvater and Christopher D. Gray. MRP II
standard system: a handbook for manufacturing software
survival. New York: Wiley, 1989.
Erin Callaway. Enterprise resource planning: integrating
applications and business processes across the enterprise.
Charleston, SC: Computer Technology Research, 1999.
Andreas Vogel, Keith Duddy. Java programming with
CORBA. New York: John Wiley & Sons, Inc, 1998.
Fan-Tien Cheng, Meng-Tsang Lin, Rong-Shean Lee.
“Developing a Web-enabled Equipment Driver for
Semiconductor Equipment Communications”. Proceedings
of the 2000 IEEE International Conference on Robotics &
Automation San Francisco,CA, April 2000, vol.3, pp.
2203-2210.
Hori, M.; Kawamura, T.; Okano, A. “OpenMES: scalable
manufacturing execution framework based on distributed
object computing”. Systems, Man, and Cybernetics, 1999.
IEEE SMC '99 Conference Proceedings, vol.6, pp. 398403.
Zhonghua Yang; Guangbin Huang; Guan, R.L.Y.; Gay, R.
“CORBA as object-oriented infrastructure for factory
communication and control”. Communications, 1999.
APCC/OECC '99. Fifth Asia-Pacific Conference and
Fourth Optoelectronics and Communications Conference,
1999, vol.2, pp. 1083-1086.
R. Kolluru, S. Smith, P. Meredith, T. Chambers, G.
Seetharaman, T. D’Souza. “A Framework for the
Development of Agile Manufacturing Enterprise”.
Processding of the 2000 IEEE International Conference on
Robotics & Automation San Francisco, CA. April 2000,
vol.2, pp.1132-1137.