- Email: [email protected]
An object-oriented information modeling methodology for manufacturing information systems
Computersind. EngngVol. 24, No. 3, pp. 337-353, 1993 Printed in Great Britain. All rights reserved
0360-8352/93 $6.00+ 0.00 Copyright © 1993 Pergamon Preu Ltd
AN OBJECT-ORIENTED INFORMATION MODELING METHODOLOGY FOR MANUFACTURING INFORMATION SYSTEMS CHEOLHAN KIM, KWANGSOO KIM a n d I N J u s CHOI Department of Industrial Engineering, Pohang Institute of Science and Technology, Pohang 790-784, Korea (Receivedfor publication 11 March 1993) Atetract--In this paper, we propose a new information modeling methodology for manufacturing information systems, called OOMIS (Object-Oriented modeling methodology for Manufacturing Information Systems). The proposed methodology consists of an analysis phase and a design phase. In the analysis phase, manufacturing functions are decomposed into component functions to define the information flow among the manufacturing functions and their infrastructures. The manufacturing functions are described with functional diagrams. Then, functional diagrams are transformed into three types of tables: function, data, and operation tables. In the design phase, these tables are translated into an object-oriented information model. The information model consists of a class dictionary and class relationship diagrams. Through an aggregation and integration process, these tables are transformed into a class dictionary which consists of function classes and entity classes. The function classes describe manufacturing functions and the entity c ~ describe manufacturing data. The class relationships (generalization, aggregation, and interaction) are defined in the semantic design process. The integrated information model supports semantic properties of the manufacturing information and can be directly translated into a specific data dictionary for OODBMS.
1. INTRODUCTION
The trend in manufacturing systems is to change from islands of automation to enterprise-wide integration, from physical processing workers to information processing workers, and from management of people/activities to management of information about people/activities. The key for coping with this trend is a broad, comprehensive, and focused approach to integrating information systems within manufacturing environments. To design an integrated information system, we need to understand how each manufacturing function operates and how it relates to other manufacturing functions. An integrated information system also requires coordinated solutions to data management problems for individual applications as well as for the exchange of data between these applications. Since function and data are closely inter-related in the integrated system, it is necessary to represent these functions and the data in a single integrated information model. Many authors have developed manufacturing system analysis and database design methodologies for the integrated information systems. Among these are ICAM's IDEF [1-5], GRAI's GRAI [6-8], Nijssen's NIAM [9], and Canadian NRC's M* [10, 11]. However, they appear to be inadequate for the analysis and design of manufacturing information systems, because these methodologies were basically developed for traditional business applications. Therefore, they cannot coherently represent diverse manufacturing functions and the heterogeneous data modeled in manufacturing systems [12]. This paper develops a new information modeling methodology, called OOMIS (Object-Oriented modeling methodology for Manufacturing Information Systems) which represents manufacturing functions and data in an integrated information model using the representational scheme, Class. OOMIS consists of two phases: analysis and design (Fig. 1). Inthe analysis phase, we decompose the manufacturing system into manufacturing functions to analyze the information flow and represent the decomposed functions with functional diagrams. In the design phase, we translate the analysis results into an integrated information model which consists of a class dictionary and relationship diagrams. 337
338
C ~ O L ~ N IOM et at.
i
I
I l~'`ii°'i'tl'i~m ,o,ion I I O~,,',,~l~ I le
I
I labl° 'W.
I
I llblo
I_
....~.7~,I.7~;/D7~i -i~-~-~i~l .....................
,~#<~nformlitmadol ion ~' '>I Iion,,,,,
Ii
io~,
f
t,'ti'grm'
1 J
I
J
Fig. I. OOMIS procedure
This paper is organized as follows. In Section 2, the existing modeling methods for information systems are reviewed. Section 3 discusses the basic characteristics of object-oriented paradigms and manufacturing information systems. Section 4 presents object-oriented information modeling as a methodology. In Section 5, an application of the proposed methodology is briefly described. Section 6 identifies future research directions and concludes the paper. 2. EXISTING METHODOLOGIES OF INFORMATION ANALYSIS AND DESIGN
IDEF, GRAI, and M* are among these information modeling methodologies frequently used to analyze and design manufacturing information systems. Their description follows: 2.1. IDEF
IDEF is comprised of three models: the functional model (IDEF0), the information model (IDEF1), and the dynamics model (IDEF2). IDEF0 is a cell-modeling technique based on functional decomposition. In IDEF0, a whole function is represented as a box which is a collection of related functions, not just monolithic actions. IDEF 1 is used to produce an information model which represents the structure and the semantics of information within the environment (or system). The components of an IDEFI model are entities, relationships, and attributes. IDEF2 is used to produce a dynamics model which represents the time varying behavior of manufacturing systems in such a way that the descriptions can be analyzed to generate measures of the manufacturing system performance using computer simulation. IDEF is powerful in analyzing a system in view of each model. IDEF, however, is not suitable for design of integrated databases because it does not consider interfaces among subsystems. Furthermore, not all characteristics of manufacturing data can be properly represented since it
A manufacturing information system
339
represents the data as a single entity, and the information model is not therefore expressive enough to capture rich semantics of manufacturing information.
2.2. GRAI The GRAI method was developed specially for the study of decision-making in production systems. In the GRAI method, a production system is composed of a physical system and a production control system. The physical system is a set of manufacturing units whose functions transform raw materials or parts into finished parts or a complete product. The production control system makes decisions. It consists of an information system and a decision system. It makes decisions based on such information as order, resource, and energy, in order to make the physical system perform its functions. The GRAI conceptual model represents the relationships between the information system, the decision system, and the physical system. The information system is the connecting link between other systems. The GRAI model has a hierarchical structure; therefore at each level, decisions and information are determined by the task to be performed and by the time period in which the decision is made. Thus, the information must be structured to match the decision at each level. The GRAI method is suitable for the analysis of production systems and for the specification of the decision-making systems for production systems. However, the GRAI method is not adequate as a database design tool because its main purpose is to design a decision-making system rather than an information system. 2.3. M* M*, adapted from the DATAID of Italy, is a methodology dealing with enterprise analysis and centralized database design. It provides engineers with analysis and design tools for a database within a CIM environment. The M* methodology consists of three main phases: (1) enterprise modeling and analysis, (2) conceptual design, and (3) implementation design. Enterprise modeling and analysis aims to support a structural analysis of an enterprise in terms of the AS_IS analysis and the TO_BE analysis to obtain a clearer understanding of the enterprise's functions and operations, expressed in terms of a functional model, an information model, and a dynamics model. The conceptual design determines !ocal and global views of the enterprise. It defines a data model, an operation model, ~and a process model using data schema, operation schema, and functional schema. The extended entity-relationship (EER) model is used as a data model to represent information. The operation model explains the operations of an entity represented within the EER model. The process model, described by the Petri Net, defines processes as sequences of operations which follow the conditions of the object functions. These models deliver local views, and then finally integrated global views, through conflict analysis in order to solve the mutual conflicts between local views. Finally, implementation design transforms the models which are generated from the conceptual design into the data structure of the special DBMS, and by using the global data schema and the global operation schema, it constructs application programs with a relational schema, and designs a physical schema. Whereas IDEF and GRAI are information modeling methodologies for analysis, M* is an information modeling methodology for both analysis and design. However, it has a limited ability to capture the complex semantics of manufacturing information. Thus, the complexity and heterogeneity of manufacturing data may not be properly expressed in an EER model such as the one used in the conceptual design phase because of its limited data types. 3. OBJECT-ORIENTED PARADIGM
3.1. Basic characteristics of object-oriented paradigm An object-oriented paradigm is a new way of thinking about problems using models organized around real-world concepts. The fundamental construct is the object, which combines both data structure and behavior in a single entity. Object-oriented paradigms are useful for understanding problems, communicating with application experts, modeling enterprises, and designing programs and databases. Object-oriented models offer a number o f important advantages for these applications [13-15].
340
CH~LHAN KZM et ai.
One advantage is the modeling of all conceptual entities with a single concept, namely, objects. The state of an object is captured in the instance variables. The behavior of an object is encapsulated through the methods. Objects can communicate with one another through the messages which constitute the public interface with an object. The object-oriented model had additional advantageous features such as (1) encapsulation, (2) generalization, (3) inheritance, and (4) polymorphism. Encapsulation (or information hiding) is the separation of the external aspects of an object, which are accessible to other objects, from the internal implementation details of the object, which are hidden from other objects. Generalization forms a higher level general entity class (called a superclass) by grouping similar lower level classes (called subclasses). A generalization is an abstraction which enables a class of individual objects to be thought of as a single named object. Inheritance allows us to reuse the behavior and the code of a class in the definition of new classes. Subclasses of a class inherit the operations of their superclass and may have new operations and new instance variables. Polymorphism means the ability to take several forms. In object-oriented programming, it refers to different representations of the same property based on the position in the generalization class hierarchy. Polymorphism enhances software reusability by enabling to the implementation of generic software that will handle for a large range of existing objects, as well as any objects which are added later.
3.2. An object-oriented paradigm for manufacturing information systems Previous work [16-18] allows us to understand the characteristics of manufacturing data. The structural characteristics of the manufacturing data can be summarized as follows: (1) (2) (3) (4) (5) (6) (7)
complex data types (vector, matrix, set, etc.) composite and complex object multiple versions of design hierarchies for data structures attributes that draw values from alternative domain recursion definition of data objects temporal, positional, and procedural relationships.
The desire to capture more semantics of data requires the use of data abstraction and other features of the object-oriented paradigm in order to model and integrate data in a manufacturing environment. The object-oriented paradigm enhances the semantic content of the data by defining relationships with inheritance of properties and operators. The object-oriented paradigm also provides a flexible data model in which the complex data structures of manufacturing applications can be created and manipulated easily. These inherent features of the object-oriented paradigm allow us to express the complexity of the manufacturing data through representational means, class, which encapsulates both the data and the functions of the manufacturing system. Hence. the representation of diverse manufacturing information in a unified, consistent, and efficient manner is possible. The class hierarchy provides a basis for the decomposition of the manufacturing system. Furthermore, message-passing in the object-oriented paradigm provides a model that can describe the distributed nature of manufacturing systems in a natural, appealing manner. 4. OBJECT-ORIENTED INFORMATION MODELING METHODOLOGY
4.1. Analysis phase In the analysis phase, manufacturing functions are decomposed into component functions to define the information flow between the manufacturing functions and their infrastructures. The decomposed functions are described with functional diagrams. The basic information extracted from the manufacturing functions is then transformed into the form of tables: function, data, and operation tables. 4.1.1. Decomposition of the functions. To construct an integrated information system, the information common to the subsystems (manufacturing functions) must be analyzed. This requires that manufacturing functions be decomposed into component functions, and eventually into unit functions which perform fundamental and simple operations. To decompose maniifacturing
A manufacturing information system
341
functions into a set of quasi-independent and communicating entities, the following principles are needed: (1) minimal information flow, (2) semantic consistency of component functions as an identical process or a continuous process, and (3) the transparency of data. Minimal information flow prohibits the duplication of information and the generation of the unexpected data. Consistent decomposition of a function means that component functions are either replications of an identical process or they constitute a continuous process. In other words, implemented functions and their compositions must correspond to real manufacturing processes. Furthermore, decomposition of a function must be carefully performed to maintain transparency of its data because information networks in manufacturing systems are distributed networks [19, 20] With the above criteria, each function is decomposed into unit functions so that the operations (behaviors or activities) of the function and the data used by the operations can be easily defined throughout the entire decomposition process. A function is never divided into more than six component functions at each decomposition level. The upper limit of six was chosen since psychological experiments have shown that it is difficult to grasp more than 5-7 distinct concepts at one time [21]. The functional decomposition process is completed which every component function of each function in the system is defined as a unit function. A manufacturing system can be defined as a set of unit functions. Unit functions also may be combined to form subsystems which support manufacturing systems. The unit functions enforce modularity and facilitate reusability. Modularity is enforced because each unit function is a separate independent entity. This facilitates reusability because each entity can be reused without considering relationships between the entity and other entities in the function domains. Reusability is increased by the encapsulation, inheritance, and message-passing capabilities of the object-oriented paradigm. Modularity also enables flexible implementation and enhances productivity. Thus, the decomposed functions are described with their related data and functions: input data, output data, control data, and source function of the input and control data. The functional diagrams shown in Fig. 2(a) represent these descriptions. The infrastructure of a function is naturally revealed through the steps of decomposition and described by the functional diagrams. The information flow between manufacturing functions can be easily obtained by connecting of the related functional diagrams because the input and control data of the functions have an easily traceable origin, which determines the precedence of functions. Hence, the degree of data dependency generated by the functions can also be defined. 4.1.2. Functional diagram. In the OOMIS, functional diagrams, which are similar to the functional diagrams of IDEF0, represent the information flow among functions. In a functional diagram, a box represents a function and the function name appears within the box. Incoming arrows entering a box from the left-hand side represent information or materials needed to perform the function, i.e. the input data. Information and material can be distinguished by their different logistic properties (e.g. information can be easily replicated at several sites, while material cannot). Information flow is denoted by solid line and material flow by dotted fine. Outgoing arrows represent information or materials created when a function is performed, i.e. the output data. The input and output data of a function show what is done by the function. The control data of a function, represented by arrows coming into the box from above, constrain transformation by the function (input) and status of the transformation (output). They describe the conditions or circumstances that govern the function and show why the function is done. Source functions are indicated within parentheses to the left side of the data or under the data. They describe the origins of the input and control data. Displaying the information source in the functional diagrams helps us to know the relationships and/or the precedence of related functions while the functional diagrams of IDEF or M* do not. Interacting and combining these functions enhances functional integration. 4.1.3. Function tables, data tables, and operation tables. The function table shown in Fig. 2(b) describes the components of the manufacturing functions and the functional hierarchy (decomposed order and level) of the functions. The function tables augment the functional diagram giving additional information about each function such as its function code and procedure name. The function code starts with an "F" followed by a number, which is followed by a dot and digits
342
CH~LHAN K m et o2.
(a)
Control
~ (source function)
Input
Output m.~
Function name
(source function)
Component : BOX / Input data Output data / Control data source function .....> material Information Co) Funtion name
:
Function code : F *** ** Function type: : 7 Procedure name Input data: Output data : Control data:
T
function decomposition level & order
function code
Fig. 2. (a) Functional diagram. (b) Function table.
indicating the decomposition level and order. Note that the number after the dot of a function code uniquely identifies the component function: the position of a digit in the number indicates the decomposition level, and the magnitude indicates the components function's order. A procedure name is used to link the static description of a function described by the function table with its dynamic description (e.g. Petri Net or State Net). As for describing the dynamic nature of the function, this task is important for interactive systems but is not addressed in OOMIS, which only aims to analyze manufacturing information system and to design an information model for them. When specifying input and control data in a function table, the source of each datum is also specified by pairing the source and the datum. The data table in Fig. 3(a) represents the output datas of the functional diagram. All the manufacturing data can be defined by the data tables because the manufacturing data or the attributes of the data must be generated by only a manufacturing function. In addition, this manufacturing data may be modified and referenced by the other manufacturing functions. In the data table, attribute_name represents the output data name literally, If attribute_name is a part of manufacturing data, attribute_of is the manufacturing data. If attribute_name represents the entire manufacturing data, the attribute_name is the same as the attribute_of The operation table in Fig. 3(b) describes how a manufacturing function handles its operations. The operations of an operation table are the aggregated set of processes or procedures of the unit functions. The operations of the manufacturing functions are the main activities of the manufacturing information system and become the class methods described in Section 4.2.2.
A manufacturing information system (a)
Function .code:
Function name: attribute_name
343
attribute_of
description i
i
(b) Function name: operation
Function code: description
Fig. 3. (a) Data table.(b) Operation table.
4.2. Design phase In the design phase, the function, operation, and data tables obtained in the analysis phase are translated into an integrated information model using an object-oriented paradigm. Through the aggregation and integration process, these tables are transformed into a class dictionary which consists of function classes and entity classes. The function classes describe the properties of the manufacturing functions and the entity classes represent the manufacturing data. The class dictionary can be directly translated into the specific data dictionary of OODBMS. The relationship diagrams (generalization, aggregation, and interaction) are defined to describe the semantic properties of the manufacturing information. 4.2. I. Aggregation and integration. To define classes or objects without redundancy, local tables are collected and merged into the global tables. After the global tables have been obtained, a reconstruction step is needed in order to coherently represent them as classes or objects in the class dictionary, which will be explained later. The aggregation process is carried out by identifying common concepts in the tables. The attribute_name tuples of the data tables which have the same attribute_of field are aggregated to represent a manufacturing datum whose name is attribute_of The attribute_name and attribute_of fields must be unique because an attribute of a manufacturing datum is created by only a manufacturing function, and it is this attribute which can be used or updated by other manufacturing functions. If function tables have the same input and control data, these functions are merged. The merged function table has multi-valued attributes for function code determined by the pre-merged function tables. The merged function table also contains output data which are related to each function table. This table can refer the operation tables, which are then related to each function table, to choose a suitable method for organizing the function table. Then finally, aggregated tables have been obtained, an integration step is needed. The basic activity of the integration process is conflict analysis [22]. Thus each table is compared with other tables to identify any conflicts between the corresponding components. If there are any conflicts, they will be either name conflicts or structural conflicts. The name conflicts arise because of synonyms or homonyms. If the same component has two or more names in different tables, there is a synonym conflict. If different components have the same name, a homonym conflict occurs. CAIE ~4/~-B
344
~
Kn~ et a/.
The structural conflicts in the model arise when different types of structures represent the same concept, or there are conflicting constraints. Structural conflicts include attribute/object-class conflicts, type conflicts, and constraint conflicts. Attribute/object-class conflicts occur when a name represents an object and the attributes of other objects. Attribute/object-class conflicts are resolved through the aggregation process. Type conflicts may occur if one table describes a concept at high level of abstraction whereas another table describes it at a low level of abstraction. Type conflicts also occur when corresponding relationship set has different structures. In one table, for example, a relationship set may be an "n-ary" relationship set while in another table it is a "part-6f" relationship set. Constraint conflicts occur when there are inconsistencies in constraints. Other tables may be inconsistent because they are incomplete. For example, one table may have a general constraint that is entirely omitted in a corresponding table. Name conflicts are resolved by changing names or allowing aliases, whichever best suits our needs. However, on the whole, resolution of the structural conflicts is more difficult than resolution of name conflicts. Because in general, tables must be made to conform by making sVuctural alterations. 4.2.2. Class definition. A standard interface to external applications (1) helps integrate different tools that can coorporate by using the same information, and (2) minimizes the possibility of human error by limiting the number of allowed operations. To satisfy this requirement, the tables are transformed into the uniform representation scheme, namely, class. A class consists of an identifier, attributes, and methods. The attributes of a class represent the static properties of a manufacturing system component. The method describes the dynamic properties of components. Through message-passing, the class communicates with other classes. The communication promotes the interaction between the components. In manufacturing environments, manufacturing functions may be executed by multiple objects. It is not easy to encapsulate the operations of the functions into a single object. To describe a manufacturing function in the object-oriented paradigm, we define an abstract class, called function class. The function class represents the characteristics of the manufacturing function. Methods of the function class describe the operations of the manufacturing function. The attributes of the class are function code, procedure name, source function, and the manufacturing entities which are the function's input, output, and control data. These attributes may be multi-valued attributes. The attribute function code, represents the level and order of the function class in the functional hierarchy. The methods of a function class, which are derived from the corresponding operation tables, represent the function's operations (activities, data processing, decision, and its behavior). Entity classes describe the physical properties of manufacturing data (or entities). The structures of entity classes allow us to represent complexity and heterogeneity of manufacturing data. They
object_name
function_name
attribute_set
function code: procedurename: inpuUdata: output_data: controldata:
method
method
P.ataz.c/uL
.k'~nntlon Class
Fig. 4. Diagrams of class definition
"
A manufacturing information system
I
I
I M°t°r I
345
I Veh'oio I
(c) Unidirectional
(a) Generalization
I Robot I
I
I
(d) Unidirectional Synchronous Interaction
(b) Aggregation
Po,i.ooiog Soo or
Motor
(e) Bidirectional Synchronous Interaction
Asynchronous
Interaction
I C'ork I
] (f) Bidirectional Asynchronous Interaction.
Fig. 5. Relationships diagrams.
have instances which represent the status or value of the manufacturing data. Inheritance and the class hierarchy of the entity class support the characteristics of the manufacturing data. The methods of the entity classes, which also come from operation tables, calculate the values of manufacturing data or evaluate the status of the manufacturing function. Figure 4 shows diagrams of class definition which provide a formal graphic notation for modeling objects, classes, and their relationship among them. Object diagrams are concise, easy to understand, and easy to put into practice. These diagrams are composed of object identifiers, attributes, and methods. The broad arrow indicates a message connection. The class dictionary consists of function classes and entity classes. If a new function is required in manufacturing environment, it can be easily designed by selecting the suitable classes from the class dictionary. If there are no suitable classes, new classes describing the properties of the function can be designed. 4.2.3. Semantic design. Semantic design facilities minimize the gap between the world and the representation of the world. Semantic design provides database designers with richer data structuring capabilities for database applications. The semantic relationships among objects or classes are described by the relationship diagrams as shown in Fig. 5. There are three types of semantic relationships: generalization, aggregation, and interaction. Generalization (G) is the relationship between a class and one or more refined versions of it. Generalization and inheritance are powerful abstractions for sharing commonality among classes while preserving their idiosyncrasies. In Fig. 5(a), Motor is a superclass of Step Motor and DC Motor. A subclass has only intrinsic properties and inherit commonality (attributers and methods)
346
C'm~t.qKn4 ~ etai.
ITMT T il
T
A
i!
T I ii,.,l
A manufacturing information system
347
J --C
||
348
CI~O~N ~
et al.
function name: inventory_control
function name: work_order_control
function code: F7 procedure name: i..c..proc input data: material plan (MRP) purchase order (purchasing) work order receipts (productionmgt.) product structure (BOM) output d_a_J_a:current inventorystatus control data: cog(account) safety stock (production mgL)
function code: F7.1 procedure name:w_o_c_proc input data: work order receipts (production mgt.) product structure (BOM) inventory data (material issue and receipts) output data: exceptional condition control data: safety stock (production mgL)
Fig. 7. (a) Function table of inventorycontrol. (b) Function table of work order control. from the superelass. The inheritance of commonality can greatly simplify the database definition task. Generalization facilitates modeling by structuring classes and capturing the similarity and difference between classes succinctly. Inheritance of methods is helpful during implementation as a vehicle for reusing code. In case of group technology (GT), a family name is a generalization, and an instance of that family is a specialization. Aggregation (A) is the 'is__partof" relationship in which objects representing the components of something are associated with an object representing the entire assembly. One common example is the BOM or parts explosion tree. In Fig. 5(b), M o t o r is composed of several components: brush, rotor, and coil. The difference between aggregation and generalization is that whereas an aggregation tree is composed of object instances that are all parts of a composite object, a generalization tree is composed of classes that describe an object. Also, aggregation differs from interaction which binds classes as a single object set. The function class hierarchy of a manufacturing function has this relationship. Interaction (I) represents the relationship between classes which are not hierarchically related to each other, but functionally related (namely, function class and function class, or function class and entity class). The classes which interact each other can be regarded as a single set. There are two aspects in interaction: synchronization and direction. For synchronous interaction, the receiver must be ready to receive a message when the sender sends it. If the receiver is not ready, the message is lost. For asynchronous interaction, the receiver and sender communicate through the mail or blackboard. Sometimes, there are pairs of interactions which are closely related. These relationships are bidirectional. In Fig. 5(c), the relationship between M o t o r and Driver is a unidirectional
Function name: Inventory_control
Function code : F7
Description
Operation i
:[ inventory_trans
process all inventory translation on line
report_inventory
report current inventory status
material_receipt
update received material
work_order_proc
process work orders and report material issue
proc_bom
make pan list from work order
Fig. 8. Operation table of inventorycontrol.
A manufacturing information system
349
asynchronous interaction. Figure 5(d) describes the interaction between Sensor and Robot to assemble PCB: as the sensor detects a signal, it commands Robot to operate. This relationship is a unidirectional synchronous interaction. Bidirectional synchronous interaction, as shown in Fig. 5(e) occurs when two objects such as Motor and Positioning Sensor (Encoder) communicate
f
fn..name: work..order_control
-,
fn_code:F7.1 proc_.name: w_o_c_proc in..dats: work_order BOM_info inventory_data out_data:execptiona] conditions con_data: safety, stock
obj_name: work_ordcs
obj_name:invent6ry date
lxoducL.id: batch...id: priority: ~der date: duedate: completiondate: quantity:
product_id: pan id: on_hand: lead_thne: lot_size: on_order: location: rawmaterial_type: alternative:
cost:
BOL_no: muting:
work_order_c.onuol
J
update
(a)
update_inventory_status
(b)
(c)
obj_name: production info
obj_nsme: psrt_info
obj_name: BOM_info
product_id: production_name: description: version..no:
partjd: material code: proce...plm_no: NC_pmgram_no: GT_~x~: dfawing...no:
BOM_no: product_id: part_id: quantity: uom: assembly_insuuction:
uom;
pan_info: BOM. no: BOL..no:
upda,..
add_born modify_born
update
(f)
(e) obj..mn~:BOb_info
obj_nmne: drawins_info
obj.m~ae: maus,ial_info
BOL_no:
drawin&..no:
material code: material_name:
pmduct..id:
p.n.id:
dep,mment: product_cycle_time: labor_hour: labor_cosu
drawins_filenme: scale: release_date'. venion_no:
u~m
update
(g)
hardness:
stiffness: uom:
updme
(h) Fig. 9. Class dictionary example.
(i)
350
CHEOLHAN KIM el a~.
work_order_conU'ol
,
work order
inventory_data
inl
BOM_info
nfo NC..program_info
_info -' rnaterial_info Fig. 10. Relationshipdiagramsbetwvenclasses. each other. Figure 5(0 shows a bidirectional asynchronous interaction that occurs between clerk and manager which make request orders to each other.
5. AN APPLICATIONOF THE PROPOSEDMETHODOLOGY As an application, a material management system was analyzed and designed by OOMIS. The material management system consisted of inventory control, material requirement planning (MRP), and master production scheduling (MPS) functions in HP's material management/3000 [23]. Inventory control consisted of four subfunctions: inventory balance management (IBM), material issues and receipts (MIR), work order control, (WOC), and purchase order tracking (POT). In this application, POT was not included because POT function is regarded as a part of the purchasing function. MPS generates a production schedule for the products. MRP simulates the complex flow of materials to manufacture products and generates a material plan. MIR helps control stockroom inventory by maintaining timely and accurate records of all actions that affect inventory balances. IBM maintains information about inventory balances and warehouse locations. In WOC, all work orders require the issue of on hand inventory for their completion. The outputs of WOC are reports noting exceptional conditions. To define information flow among material management functions mentioned above, the functions are described with input, output, and control data. As shown in Fig. 6(a), the connection of the related data describes the information flow. The source functions, which appear on the function diagram, manage the input and control data of the function. As shown in Fig. 6(a), the outputs of one function serve as the inputs to other functions: M R / ' function receives the current inventory status as an input from the inventory control function. This reveals the hierarchy and
A manufacturinginformationsystem
351 Part-info
i
-!77°! I
. . . . . .
•
Inventory_data i = I Part-id I ] Product_id ] HI
Set Work_order_control Bin-data I
/
Product_info [ Bol_no I--
,om_o lit i , ,jd
I
Work_order
i I ] PrOduCt-id]
Bol info Bom_info [ partjd I
Fig. 1I. CI~ hierarchyexample. precedence of the functions. IDEF and M* cannot describe the information flow among these functions effectively because the source functions cannot be described. In OOMIS, on the other hand, the information flow is easily defined by connecting the related data among the functions centering around the source functions. The extension of the information flow to other related functions is easy because the source functions of the input and control are already known. To obtain more detailed information about the related data, the functions were decomposed into several component functions. This revealed the infrastructures of the functions. In the case of the inventory control function in Fig. 6(a), it can be decomposed into three component functions as shown in Fig. 6(b). This shows the exact source of the related data (input data of other function). From the functional diagram, the function and the operation tables were derived. Figure 7(a) is the function tablefor inventory control function whose function code is F7. Figure 7(b) is the function table for the work order control function which is a component of the itwentory control function. The function code of this component function is F7.1. Function tables of the manufacturing functions were easily translated into class hierarchy in OOMIS.
352
C3¢mt.H~q Kn~ et al.
The operations of the operation table for the inventory control function in Fig. 8 were used to define the methods of the classes in Fig. 9. Figure 9(a) is a function class that describes the work order control function. Figure 9(b) represents the entity class which is related to a work order. Among the attributes of the entity class in Fig. 9(b), produce_id is related with the entity class product_info. This entity is also related with part_info, BOM_info, and BOL_info entity classes. Figure 9(c) represents the inventory data. Figure 9(d)-(i) show other entity classes which are indirectly related to the work_order_control class. The relationship diagram in Fig. 10 shows the classes related to the work_order_control class. Figure 11 illustrates the aggregation hierarchy of the classes in Fig. 9. This hierarchy diagram was generated by an OODBMS (Object-Oriented Database Management System), UNISQL/4GE, on a SUN workstation.
6. CONCLUSION
To develop an integrated manufacturing system, the main bottleneck we need to overcome is the integration of the information produced by the subsystems. Information integration requires a common framework representing manufacturing functions and data. In this paper, a new information modeling methodology is proposed to analyze manufacturing systems and to design an integrated information model which coherently represents manufacturing functions and data. This methodology describes manufacturing functions and data, and their relationships with a uniform representational scheme of class. The proposed methodology has the following features: (1) The hierarchical and parallel structure of manufacturing systems can be grasped through functional diagrams. (2) Various semantic properties of manufacturing information (functions, data, and relationships) can be represented in a single integrated information model. (3) The flexible design of manufacturing systems is possible: a manufacturing function can be defined by its unit functions. (4) Straightforward translation from the class dictionary to a specific data dictionary of OODBMS is possible. (5) The proposed methodology develops an object-oriented design methodology, and extends it from logical design level to conceptual design level. By analyzing and designing a manufacturing information system using OOMIS, we can develop an integrated information model for an integrated manufacturing environment. We are now carrying out an extensive experimentation with this methodology, and developing automated support tools. Our future work will also include the extension of OOMIS to an integrated knowledge representation model based on the ideas presented in this paper. Acknowledgement--This work was supported in part by the KOSEF Engineering Research Center for Intelligent Automation at Pohang Institute of Science and Technology.
REFERENCES 1. R. R. Bravoco and S. B. Yadav. Requirement definition architecture--an overview. Comput. Ind. 6, 237-251 (1985). 2. R. R. Bravoco and S. B., Yadav. A methodology to model the functional structure of an organization. Comput. Ind. 6, 345-361 (1985). 3. R. R. Bravc~o and S. B.I Yadav. A methodology to model the information structure of an organization. J. Syst. Software & 59-71 (1985). 4. R. R. Bravoco and S. B. Yadav. A methodology to model the dynamic stru~ute of an organization. Inform. Syst. 10, 299-317 (1985). 5. U.S. Air Force. ICAM Functional Model Manual IDEF. Air Force Material Laboratory, Wrisht-Patterson AFB, Ohio (1981). 6. U. Rembold and R. Dillman. Computer-Aided Design and M~ufacturing Methods and Tools. Springer, New York
(tgss). 7. O. Doumemeingts. Design methodology for advanced muufactuting systems. Compt. Ind. 9, 271-296 (198T). 8. O. D o ~ et a/. ORAI approach to ~ and contmlti~ adnnmd manufacturing system in CIM environman[. In Aabanced Informatlan Technolog~s for IndustrialMaterial Flow SYStems (Editedby S. Y. Nof and C. L, Modies), Springer,New York (1989). 9. O. H. Bray. CIM: The Data M~agmJ~t,nt Strategy.DigitalPrees,New York 0988).
A manufacturing information system
353
10. A. Di Leva and F. Vemadat. Information system analysis and conceptual database design in production environments with M*. Comput. Ind. 9, 193-217 (1987). 11. A. Dileva and P. Giolito. Information system design and analysis of manufacturing environments, the new M* approach. Computer Applications in Production and Engineering. North-Holland, Amsterdam (1989). 12. C. Hsu and L. Rattner. Information modeling for computerized manufacturing. IEEE Trans. Syst. Man Cybernet. 20, 758-776 (1990). 13. J. Rumabugh et al. Object-Oriented Modeling and Design. Prentice-Hall, Engiewood Cliffs, N.J. (1991). 14. P. Wegner. Concepts and paradigms of object-oriented programmins, OOPSLA-89 Keynote Talk (1989). 15. G. Booch. Object-Oriented Design and Applications. Benjamin/Cummings, New York (1991). 16. C. U. King, S. S. Adams and E. L. Fisher. Representation of manufacturing entities. In Intelligent Manufacturing (Edited by M. Ollff). Benjamin/Cummings, New York (1989). 17. F. Vernadat. A conceptual schema for a CIM database. CAD~CAM Integration and Innovation. SME (1985). 18. S. Y. W. Su. Modeling integrated manufacturing data with SAM*. IEEE Comput. Mag. 34-49 (1986). 19. D. M. Weber and C. L. Moodie. Distributed, intelligent information system for automated, integrated manufacturing systems. In Advanced Information Technologiesfor Industrial Material Flow Systems (Edited by S. Y. Nof and C. L., Moodies). Springer, New York (1989). 20. E. Barkmeyer and M. J. Mitchell. An architecture for distributed data management in CIM. U.S. Department of Commerce Report No. NBSIR86-3312 (1986). 21. G. Miller. The magical number seven, plus or minus two: some limits on our capacity for processing information. Psychol. Rev. 63, 81-97 (1956). 22. C. Batini, M. Lenzerini and M. Mosarini. View integration. In Methodology and Tools for Database Design (Edited by C. Cedri). North-Holland, Amsterdam (1983). 23. N. C. Federman and R. M. Steiner. An interactive material planningand control system for manufacturing companies. Hewlett-Packard J. 3-12, April (1981).
0360-8352/93 $6.00+ 0.00 Copyright © 1993 Pergamon Preu Ltd
AN OBJECT-ORIENTED INFORMATION MODELING METHODOLOGY FOR MANUFACTURING INFORMATION SYSTEMS CHEOLHAN KIM, KWANGSOO KIM a n d I N J u s CHOI Department of Industrial Engineering, Pohang Institute of Science and Technology, Pohang 790-784, Korea (Receivedfor publication 11 March 1993) Atetract--In this paper, we propose a new information modeling methodology for manufacturing information systems, called OOMIS (Object-Oriented modeling methodology for Manufacturing Information Systems). The proposed methodology consists of an analysis phase and a design phase. In the analysis phase, manufacturing functions are decomposed into component functions to define the information flow among the manufacturing functions and their infrastructures. The manufacturing functions are described with functional diagrams. Then, functional diagrams are transformed into three types of tables: function, data, and operation tables. In the design phase, these tables are translated into an object-oriented information model. The information model consists of a class dictionary and class relationship diagrams. Through an aggregation and integration process, these tables are transformed into a class dictionary which consists of function classes and entity classes. The function classes describe manufacturing functions and the entity c ~ describe manufacturing data. The class relationships (generalization, aggregation, and interaction) are defined in the semantic design process. The integrated information model supports semantic properties of the manufacturing information and can be directly translated into a specific data dictionary for OODBMS.
1. INTRODUCTION
The trend in manufacturing systems is to change from islands of automation to enterprise-wide integration, from physical processing workers to information processing workers, and from management of people/activities to management of information about people/activities. The key for coping with this trend is a broad, comprehensive, and focused approach to integrating information systems within manufacturing environments. To design an integrated information system, we need to understand how each manufacturing function operates and how it relates to other manufacturing functions. An integrated information system also requires coordinated solutions to data management problems for individual applications as well as for the exchange of data between these applications. Since function and data are closely inter-related in the integrated system, it is necessary to represent these functions and the data in a single integrated information model. Many authors have developed manufacturing system analysis and database design methodologies for the integrated information systems. Among these are ICAM's IDEF [1-5], GRAI's GRAI [6-8], Nijssen's NIAM [9], and Canadian NRC's M* [10, 11]. However, they appear to be inadequate for the analysis and design of manufacturing information systems, because these methodologies were basically developed for traditional business applications. Therefore, they cannot coherently represent diverse manufacturing functions and the heterogeneous data modeled in manufacturing systems [12]. This paper develops a new information modeling methodology, called OOMIS (Object-Oriented modeling methodology for Manufacturing Information Systems) which represents manufacturing functions and data in an integrated information model using the representational scheme, Class. OOMIS consists of two phases: analysis and design (Fig. 1). Inthe analysis phase, we decompose the manufacturing system into manufacturing functions to analyze the information flow and represent the decomposed functions with functional diagrams. In the design phase, we translate the analysis results into an integrated information model which consists of a class dictionary and relationship diagrams. 337
338
C ~ O L ~ N IOM et at.
i
I
I l~'`ii°'i'tl'i~m ,o,ion I I O~,,',,~l~ I le
I
I labl° 'W.
I
I llblo
I_
....~.7~,I.7~;/D7~i -i~-~-~i~l .....................
,~#<~nformlitmadol ion ~' '>I Iion,,,,,
Ii
io~,
f
t,'ti'grm'
1 J
I
J
Fig. I. OOMIS procedure
This paper is organized as follows. In Section 2, the existing modeling methods for information systems are reviewed. Section 3 discusses the basic characteristics of object-oriented paradigms and manufacturing information systems. Section 4 presents object-oriented information modeling as a methodology. In Section 5, an application of the proposed methodology is briefly described. Section 6 identifies future research directions and concludes the paper. 2. EXISTING METHODOLOGIES OF INFORMATION ANALYSIS AND DESIGN
IDEF, GRAI, and M* are among these information modeling methodologies frequently used to analyze and design manufacturing information systems. Their description follows: 2.1. IDEF
IDEF is comprised of three models: the functional model (IDEF0), the information model (IDEF1), and the dynamics model (IDEF2). IDEF0 is a cell-modeling technique based on functional decomposition. In IDEF0, a whole function is represented as a box which is a collection of related functions, not just monolithic actions. IDEF 1 is used to produce an information model which represents the structure and the semantics of information within the environment (or system). The components of an IDEFI model are entities, relationships, and attributes. IDEF2 is used to produce a dynamics model which represents the time varying behavior of manufacturing systems in such a way that the descriptions can be analyzed to generate measures of the manufacturing system performance using computer simulation. IDEF is powerful in analyzing a system in view of each model. IDEF, however, is not suitable for design of integrated databases because it does not consider interfaces among subsystems. Furthermore, not all characteristics of manufacturing data can be properly represented since it
A manufacturing information system
339
represents the data as a single entity, and the information model is not therefore expressive enough to capture rich semantics of manufacturing information.
2.2. GRAI The GRAI method was developed specially for the study of decision-making in production systems. In the GRAI method, a production system is composed of a physical system and a production control system. The physical system is a set of manufacturing units whose functions transform raw materials or parts into finished parts or a complete product. The production control system makes decisions. It consists of an information system and a decision system. It makes decisions based on such information as order, resource, and energy, in order to make the physical system perform its functions. The GRAI conceptual model represents the relationships between the information system, the decision system, and the physical system. The information system is the connecting link between other systems. The GRAI model has a hierarchical structure; therefore at each level, decisions and information are determined by the task to be performed and by the time period in which the decision is made. Thus, the information must be structured to match the decision at each level. The GRAI method is suitable for the analysis of production systems and for the specification of the decision-making systems for production systems. However, the GRAI method is not adequate as a database design tool because its main purpose is to design a decision-making system rather than an information system. 2.3. M* M*, adapted from the DATAID of Italy, is a methodology dealing with enterprise analysis and centralized database design. It provides engineers with analysis and design tools for a database within a CIM environment. The M* methodology consists of three main phases: (1) enterprise modeling and analysis, (2) conceptual design, and (3) implementation design. Enterprise modeling and analysis aims to support a structural analysis of an enterprise in terms of the AS_IS analysis and the TO_BE analysis to obtain a clearer understanding of the enterprise's functions and operations, expressed in terms of a functional model, an information model, and a dynamics model. The conceptual design determines !ocal and global views of the enterprise. It defines a data model, an operation model, ~and a process model using data schema, operation schema, and functional schema. The extended entity-relationship (EER) model is used as a data model to represent information. The operation model explains the operations of an entity represented within the EER model. The process model, described by the Petri Net, defines processes as sequences of operations which follow the conditions of the object functions. These models deliver local views, and then finally integrated global views, through conflict analysis in order to solve the mutual conflicts between local views. Finally, implementation design transforms the models which are generated from the conceptual design into the data structure of the special DBMS, and by using the global data schema and the global operation schema, it constructs application programs with a relational schema, and designs a physical schema. Whereas IDEF and GRAI are information modeling methodologies for analysis, M* is an information modeling methodology for both analysis and design. However, it has a limited ability to capture the complex semantics of manufacturing information. Thus, the complexity and heterogeneity of manufacturing data may not be properly expressed in an EER model such as the one used in the conceptual design phase because of its limited data types. 3. OBJECT-ORIENTED PARADIGM
3.1. Basic characteristics of object-oriented paradigm An object-oriented paradigm is a new way of thinking about problems using models organized around real-world concepts. The fundamental construct is the object, which combines both data structure and behavior in a single entity. Object-oriented paradigms are useful for understanding problems, communicating with application experts, modeling enterprises, and designing programs and databases. Object-oriented models offer a number o f important advantages for these applications [13-15].
340
CH~LHAN KZM et ai.
One advantage is the modeling of all conceptual entities with a single concept, namely, objects. The state of an object is captured in the instance variables. The behavior of an object is encapsulated through the methods. Objects can communicate with one another through the messages which constitute the public interface with an object. The object-oriented model had additional advantageous features such as (1) encapsulation, (2) generalization, (3) inheritance, and (4) polymorphism. Encapsulation (or information hiding) is the separation of the external aspects of an object, which are accessible to other objects, from the internal implementation details of the object, which are hidden from other objects. Generalization forms a higher level general entity class (called a superclass) by grouping similar lower level classes (called subclasses). A generalization is an abstraction which enables a class of individual objects to be thought of as a single named object. Inheritance allows us to reuse the behavior and the code of a class in the definition of new classes. Subclasses of a class inherit the operations of their superclass and may have new operations and new instance variables. Polymorphism means the ability to take several forms. In object-oriented programming, it refers to different representations of the same property based on the position in the generalization class hierarchy. Polymorphism enhances software reusability by enabling to the implementation of generic software that will handle for a large range of existing objects, as well as any objects which are added later.
3.2. An object-oriented paradigm for manufacturing information systems Previous work [16-18] allows us to understand the characteristics of manufacturing data. The structural characteristics of the manufacturing data can be summarized as follows: (1) (2) (3) (4) (5) (6) (7)
complex data types (vector, matrix, set, etc.) composite and complex object multiple versions of design hierarchies for data structures attributes that draw values from alternative domain recursion definition of data objects temporal, positional, and procedural relationships.
The desire to capture more semantics of data requires the use of data abstraction and other features of the object-oriented paradigm in order to model and integrate data in a manufacturing environment. The object-oriented paradigm enhances the semantic content of the data by defining relationships with inheritance of properties and operators. The object-oriented paradigm also provides a flexible data model in which the complex data structures of manufacturing applications can be created and manipulated easily. These inherent features of the object-oriented paradigm allow us to express the complexity of the manufacturing data through representational means, class, which encapsulates both the data and the functions of the manufacturing system. Hence. the representation of diverse manufacturing information in a unified, consistent, and efficient manner is possible. The class hierarchy provides a basis for the decomposition of the manufacturing system. Furthermore, message-passing in the object-oriented paradigm provides a model that can describe the distributed nature of manufacturing systems in a natural, appealing manner. 4. OBJECT-ORIENTED INFORMATION MODELING METHODOLOGY
4.1. Analysis phase In the analysis phase, manufacturing functions are decomposed into component functions to define the information flow between the manufacturing functions and their infrastructures. The decomposed functions are described with functional diagrams. The basic information extracted from the manufacturing functions is then transformed into the form of tables: function, data, and operation tables. 4.1.1. Decomposition of the functions. To construct an integrated information system, the information common to the subsystems (manufacturing functions) must be analyzed. This requires that manufacturing functions be decomposed into component functions, and eventually into unit functions which perform fundamental and simple operations. To decompose maniifacturing
A manufacturing information system
341
functions into a set of quasi-independent and communicating entities, the following principles are needed: (1) minimal information flow, (2) semantic consistency of component functions as an identical process or a continuous process, and (3) the transparency of data. Minimal information flow prohibits the duplication of information and the generation of the unexpected data. Consistent decomposition of a function means that component functions are either replications of an identical process or they constitute a continuous process. In other words, implemented functions and their compositions must correspond to real manufacturing processes. Furthermore, decomposition of a function must be carefully performed to maintain transparency of its data because information networks in manufacturing systems are distributed networks [19, 20] With the above criteria, each function is decomposed into unit functions so that the operations (behaviors or activities) of the function and the data used by the operations can be easily defined throughout the entire decomposition process. A function is never divided into more than six component functions at each decomposition level. The upper limit of six was chosen since psychological experiments have shown that it is difficult to grasp more than 5-7 distinct concepts at one time [21]. The functional decomposition process is completed which every component function of each function in the system is defined as a unit function. A manufacturing system can be defined as a set of unit functions. Unit functions also may be combined to form subsystems which support manufacturing systems. The unit functions enforce modularity and facilitate reusability. Modularity is enforced because each unit function is a separate independent entity. This facilitates reusability because each entity can be reused without considering relationships between the entity and other entities in the function domains. Reusability is increased by the encapsulation, inheritance, and message-passing capabilities of the object-oriented paradigm. Modularity also enables flexible implementation and enhances productivity. Thus, the decomposed functions are described with their related data and functions: input data, output data, control data, and source function of the input and control data. The functional diagrams shown in Fig. 2(a) represent these descriptions. The infrastructure of a function is naturally revealed through the steps of decomposition and described by the functional diagrams. The information flow between manufacturing functions can be easily obtained by connecting of the related functional diagrams because the input and control data of the functions have an easily traceable origin, which determines the precedence of functions. Hence, the degree of data dependency generated by the functions can also be defined. 4.1.2. Functional diagram. In the OOMIS, functional diagrams, which are similar to the functional diagrams of IDEF0, represent the information flow among functions. In a functional diagram, a box represents a function and the function name appears within the box. Incoming arrows entering a box from the left-hand side represent information or materials needed to perform the function, i.e. the input data. Information and material can be distinguished by their different logistic properties (e.g. information can be easily replicated at several sites, while material cannot). Information flow is denoted by solid line and material flow by dotted fine. Outgoing arrows represent information or materials created when a function is performed, i.e. the output data. The input and output data of a function show what is done by the function. The control data of a function, represented by arrows coming into the box from above, constrain transformation by the function (input) and status of the transformation (output). They describe the conditions or circumstances that govern the function and show why the function is done. Source functions are indicated within parentheses to the left side of the data or under the data. They describe the origins of the input and control data. Displaying the information source in the functional diagrams helps us to know the relationships and/or the precedence of related functions while the functional diagrams of IDEF or M* do not. Interacting and combining these functions enhances functional integration. 4.1.3. Function tables, data tables, and operation tables. The function table shown in Fig. 2(b) describes the components of the manufacturing functions and the functional hierarchy (decomposed order and level) of the functions. The function tables augment the functional diagram giving additional information about each function such as its function code and procedure name. The function code starts with an "F" followed by a number, which is followed by a dot and digits
342
CH~LHAN K m et o2.
(a)
Control
~ (source function)
Input
Output m.~
Function name
(source function)
Component : BOX / Input data Output data / Control data source function .....> material Information Co) Funtion name
:
Function code : F *** ** Function type: : 7 Procedure name Input data: Output data : Control data:
T
function decomposition level & order
function code
Fig. 2. (a) Functional diagram. (b) Function table.
indicating the decomposition level and order. Note that the number after the dot of a function code uniquely identifies the component function: the position of a digit in the number indicates the decomposition level, and the magnitude indicates the components function's order. A procedure name is used to link the static description of a function described by the function table with its dynamic description (e.g. Petri Net or State Net). As for describing the dynamic nature of the function, this task is important for interactive systems but is not addressed in OOMIS, which only aims to analyze manufacturing information system and to design an information model for them. When specifying input and control data in a function table, the source of each datum is also specified by pairing the source and the datum. The data table in Fig. 3(a) represents the output datas of the functional diagram. All the manufacturing data can be defined by the data tables because the manufacturing data or the attributes of the data must be generated by only a manufacturing function. In addition, this manufacturing data may be modified and referenced by the other manufacturing functions. In the data table, attribute_name represents the output data name literally, If attribute_name is a part of manufacturing data, attribute_of is the manufacturing data. If attribute_name represents the entire manufacturing data, the attribute_name is the same as the attribute_of The operation table in Fig. 3(b) describes how a manufacturing function handles its operations. The operations of an operation table are the aggregated set of processes or procedures of the unit functions. The operations of the manufacturing functions are the main activities of the manufacturing information system and become the class methods described in Section 4.2.2.
A manufacturing information system (a)
Function .code:
Function name: attribute_name
343
attribute_of
description i
i
(b) Function name: operation
Function code: description
Fig. 3. (a) Data table.(b) Operation table.
4.2. Design phase In the design phase, the function, operation, and data tables obtained in the analysis phase are translated into an integrated information model using an object-oriented paradigm. Through the aggregation and integration process, these tables are transformed into a class dictionary which consists of function classes and entity classes. The function classes describe the properties of the manufacturing functions and the entity classes represent the manufacturing data. The class dictionary can be directly translated into the specific data dictionary of OODBMS. The relationship diagrams (generalization, aggregation, and interaction) are defined to describe the semantic properties of the manufacturing information. 4.2. I. Aggregation and integration. To define classes or objects without redundancy, local tables are collected and merged into the global tables. After the global tables have been obtained, a reconstruction step is needed in order to coherently represent them as classes or objects in the class dictionary, which will be explained later. The aggregation process is carried out by identifying common concepts in the tables. The attribute_name tuples of the data tables which have the same attribute_of field are aggregated to represent a manufacturing datum whose name is attribute_of The attribute_name and attribute_of fields must be unique because an attribute of a manufacturing datum is created by only a manufacturing function, and it is this attribute which can be used or updated by other manufacturing functions. If function tables have the same input and control data, these functions are merged. The merged function table has multi-valued attributes for function code determined by the pre-merged function tables. The merged function table also contains output data which are related to each function table. This table can refer the operation tables, which are then related to each function table, to choose a suitable method for organizing the function table. Then finally, aggregated tables have been obtained, an integration step is needed. The basic activity of the integration process is conflict analysis [22]. Thus each table is compared with other tables to identify any conflicts between the corresponding components. If there are any conflicts, they will be either name conflicts or structural conflicts. The name conflicts arise because of synonyms or homonyms. If the same component has two or more names in different tables, there is a synonym conflict. If different components have the same name, a homonym conflict occurs. CAIE ~4/~-B
344
~
Kn~ et a/.
The structural conflicts in the model arise when different types of structures represent the same concept, or there are conflicting constraints. Structural conflicts include attribute/object-class conflicts, type conflicts, and constraint conflicts. Attribute/object-class conflicts occur when a name represents an object and the attributes of other objects. Attribute/object-class conflicts are resolved through the aggregation process. Type conflicts may occur if one table describes a concept at high level of abstraction whereas another table describes it at a low level of abstraction. Type conflicts also occur when corresponding relationship set has different structures. In one table, for example, a relationship set may be an "n-ary" relationship set while in another table it is a "part-6f" relationship set. Constraint conflicts occur when there are inconsistencies in constraints. Other tables may be inconsistent because they are incomplete. For example, one table may have a general constraint that is entirely omitted in a corresponding table. Name conflicts are resolved by changing names or allowing aliases, whichever best suits our needs. However, on the whole, resolution of the structural conflicts is more difficult than resolution of name conflicts. Because in general, tables must be made to conform by making sVuctural alterations. 4.2.2. Class definition. A standard interface to external applications (1) helps integrate different tools that can coorporate by using the same information, and (2) minimizes the possibility of human error by limiting the number of allowed operations. To satisfy this requirement, the tables are transformed into the uniform representation scheme, namely, class. A class consists of an identifier, attributes, and methods. The attributes of a class represent the static properties of a manufacturing system component. The method describes the dynamic properties of components. Through message-passing, the class communicates with other classes. The communication promotes the interaction between the components. In manufacturing environments, manufacturing functions may be executed by multiple objects. It is not easy to encapsulate the operations of the functions into a single object. To describe a manufacturing function in the object-oriented paradigm, we define an abstract class, called function class. The function class represents the characteristics of the manufacturing function. Methods of the function class describe the operations of the manufacturing function. The attributes of the class are function code, procedure name, source function, and the manufacturing entities which are the function's input, output, and control data. These attributes may be multi-valued attributes. The attribute function code, represents the level and order of the function class in the functional hierarchy. The methods of a function class, which are derived from the corresponding operation tables, represent the function's operations (activities, data processing, decision, and its behavior). Entity classes describe the physical properties of manufacturing data (or entities). The structures of entity classes allow us to represent complexity and heterogeneity of manufacturing data. They
object_name
function_name
attribute_set
function code: procedurename: inpuUdata: output_data: controldata:
method
method
P.ataz.c/uL
.k'~nntlon Class
Fig. 4. Diagrams of class definition
"
A manufacturing information system
I
I
I M°t°r I
345
I Veh'oio I
(c) Unidirectional
(a) Generalization
I Robot I
I
I
(d) Unidirectional Synchronous Interaction
(b) Aggregation
Po,i.ooiog Soo or
Motor
(e) Bidirectional Synchronous Interaction
Asynchronous
Interaction
I C'ork I
] (f) Bidirectional Asynchronous Interaction.
Fig. 5. Relationships diagrams.
have instances which represent the status or value of the manufacturing data. Inheritance and the class hierarchy of the entity class support the characteristics of the manufacturing data. The methods of the entity classes, which also come from operation tables, calculate the values of manufacturing data or evaluate the status of the manufacturing function. Figure 4 shows diagrams of class definition which provide a formal graphic notation for modeling objects, classes, and their relationship among them. Object diagrams are concise, easy to understand, and easy to put into practice. These diagrams are composed of object identifiers, attributes, and methods. The broad arrow indicates a message connection. The class dictionary consists of function classes and entity classes. If a new function is required in manufacturing environment, it can be easily designed by selecting the suitable classes from the class dictionary. If there are no suitable classes, new classes describing the properties of the function can be designed. 4.2.3. Semantic design. Semantic design facilities minimize the gap between the world and the representation of the world. Semantic design provides database designers with richer data structuring capabilities for database applications. The semantic relationships among objects or classes are described by the relationship diagrams as shown in Fig. 5. There are three types of semantic relationships: generalization, aggregation, and interaction. Generalization (G) is the relationship between a class and one or more refined versions of it. Generalization and inheritance are powerful abstractions for sharing commonality among classes while preserving their idiosyncrasies. In Fig. 5(a), Motor is a superclass of Step Motor and DC Motor. A subclass has only intrinsic properties and inherit commonality (attributers and methods)
346
C'm~t.qKn4 ~ etai.
ITMT T il
T
A
i!
T I ii,.,l
A manufacturing information system
347
J --C
||
348
CI~O~N ~
et al.
function name: inventory_control
function name: work_order_control
function code: F7 procedure name: i..c..proc input data: material plan (MRP) purchase order (purchasing) work order receipts (productionmgt.) product structure (BOM) output d_a_J_a:current inventorystatus control data: cog(account) safety stock (production mgL)
function code: F7.1 procedure name:w_o_c_proc input data: work order receipts (production mgt.) product structure (BOM) inventory data (material issue and receipts) output data: exceptional condition control data: safety stock (production mgL)
Fig. 7. (a) Function table of inventorycontrol. (b) Function table of work order control. from the superelass. The inheritance of commonality can greatly simplify the database definition task. Generalization facilitates modeling by structuring classes and capturing the similarity and difference between classes succinctly. Inheritance of methods is helpful during implementation as a vehicle for reusing code. In case of group technology (GT), a family name is a generalization, and an instance of that family is a specialization. Aggregation (A) is the 'is__partof" relationship in which objects representing the components of something are associated with an object representing the entire assembly. One common example is the BOM or parts explosion tree. In Fig. 5(b), M o t o r is composed of several components: brush, rotor, and coil. The difference between aggregation and generalization is that whereas an aggregation tree is composed of object instances that are all parts of a composite object, a generalization tree is composed of classes that describe an object. Also, aggregation differs from interaction which binds classes as a single object set. The function class hierarchy of a manufacturing function has this relationship. Interaction (I) represents the relationship between classes which are not hierarchically related to each other, but functionally related (namely, function class and function class, or function class and entity class). The classes which interact each other can be regarded as a single set. There are two aspects in interaction: synchronization and direction. For synchronous interaction, the receiver must be ready to receive a message when the sender sends it. If the receiver is not ready, the message is lost. For asynchronous interaction, the receiver and sender communicate through the mail or blackboard. Sometimes, there are pairs of interactions which are closely related. These relationships are bidirectional. In Fig. 5(c), the relationship between M o t o r and Driver is a unidirectional
Function name: Inventory_control
Function code : F7
Description
Operation i
:[ inventory_trans
process all inventory translation on line
report_inventory
report current inventory status
material_receipt
update received material
work_order_proc
process work orders and report material issue
proc_bom
make pan list from work order
Fig. 8. Operation table of inventorycontrol.
A manufacturing information system
349
asynchronous interaction. Figure 5(d) describes the interaction between Sensor and Robot to assemble PCB: as the sensor detects a signal, it commands Robot to operate. This relationship is a unidirectional synchronous interaction. Bidirectional synchronous interaction, as shown in Fig. 5(e) occurs when two objects such as Motor and Positioning Sensor (Encoder) communicate
f
fn..name: work..order_control
-,
fn_code:F7.1 proc_.name: w_o_c_proc in..dats: work_order BOM_info inventory_data out_data:execptiona] conditions con_data: safety, stock
obj_name: work_ordcs
obj_name:invent6ry date
lxoducL.id: batch...id: priority: ~der date: duedate: completiondate: quantity:
product_id: pan id: on_hand: lead_thne: lot_size: on_order: location: rawmaterial_type: alternative:
cost:
BOL_no: muting:
work_order_c.onuol
J
update
(a)
update_inventory_status
(b)
(c)
obj_name: production info
obj_nsme: psrt_info
obj_name: BOM_info
product_id: production_name: description: version..no:
partjd: material code: proce...plm_no: NC_pmgram_no: GT_~x~: dfawing...no:
BOM_no: product_id: part_id: quantity: uom: assembly_insuuction:
uom;
pan_info: BOM. no: BOL..no:
upda,..
add_born modify_born
update
(f)
(e) obj..mn~:BOb_info
obj_nmne: drawins_info
obj.m~ae: maus,ial_info
BOL_no:
drawin&..no:
material code: material_name:
pmduct..id:
p.n.id:
dep,mment: product_cycle_time: labor_hour: labor_cosu
drawins_filenme: scale: release_date'. venion_no:
u~m
update
(g)
hardness:
stiffness: uom:
updme
(h) Fig. 9. Class dictionary example.
(i)
350
CHEOLHAN KIM el a~.
work_order_conU'ol
,
work order
inventory_data
inl
BOM_info
nfo NC..program_info
_info -' rnaterial_info Fig. 10. Relationshipdiagramsbetwvenclasses. each other. Figure 5(0 shows a bidirectional asynchronous interaction that occurs between clerk and manager which make request orders to each other.
5. AN APPLICATIONOF THE PROPOSEDMETHODOLOGY As an application, a material management system was analyzed and designed by OOMIS. The material management system consisted of inventory control, material requirement planning (MRP), and master production scheduling (MPS) functions in HP's material management/3000 [23]. Inventory control consisted of four subfunctions: inventory balance management (IBM), material issues and receipts (MIR), work order control, (WOC), and purchase order tracking (POT). In this application, POT was not included because POT function is regarded as a part of the purchasing function. MPS generates a production schedule for the products. MRP simulates the complex flow of materials to manufacture products and generates a material plan. MIR helps control stockroom inventory by maintaining timely and accurate records of all actions that affect inventory balances. IBM maintains information about inventory balances and warehouse locations. In WOC, all work orders require the issue of on hand inventory for their completion. The outputs of WOC are reports noting exceptional conditions. To define information flow among material management functions mentioned above, the functions are described with input, output, and control data. As shown in Fig. 6(a), the connection of the related data describes the information flow. The source functions, which appear on the function diagram, manage the input and control data of the function. As shown in Fig. 6(a), the outputs of one function serve as the inputs to other functions: M R / ' function receives the current inventory status as an input from the inventory control function. This reveals the hierarchy and
A manufacturinginformationsystem
351 Part-info
i
-!77°! I
. . . . . .
•
Inventory_data i = I Part-id I ] Product_id ] HI
Set Work_order_control Bin-data I
/
Product_info [ Bol_no I--
,om_o lit i , ,jd
I
Work_order
i I ] PrOduCt-id]
Bol info Bom_info [ partjd I
Fig. 1I. CI~ hierarchyexample. precedence of the functions. IDEF and M* cannot describe the information flow among these functions effectively because the source functions cannot be described. In OOMIS, on the other hand, the information flow is easily defined by connecting the related data among the functions centering around the source functions. The extension of the information flow to other related functions is easy because the source functions of the input and control are already known. To obtain more detailed information about the related data, the functions were decomposed into several component functions. This revealed the infrastructures of the functions. In the case of the inventory control function in Fig. 6(a), it can be decomposed into three component functions as shown in Fig. 6(b). This shows the exact source of the related data (input data of other function). From the functional diagram, the function and the operation tables were derived. Figure 7(a) is the function tablefor inventory control function whose function code is F7. Figure 7(b) is the function table for the work order control function which is a component of the itwentory control function. The function code of this component function is F7.1. Function tables of the manufacturing functions were easily translated into class hierarchy in OOMIS.
352
C3¢mt.H~q Kn~ et al.
The operations of the operation table for the inventory control function in Fig. 8 were used to define the methods of the classes in Fig. 9. Figure 9(a) is a function class that describes the work order control function. Figure 9(b) represents the entity class which is related to a work order. Among the attributes of the entity class in Fig. 9(b), produce_id is related with the entity class product_info. This entity is also related with part_info, BOM_info, and BOL_info entity classes. Figure 9(c) represents the inventory data. Figure 9(d)-(i) show other entity classes which are indirectly related to the work_order_control class. The relationship diagram in Fig. 10 shows the classes related to the work_order_control class. Figure 11 illustrates the aggregation hierarchy of the classes in Fig. 9. This hierarchy diagram was generated by an OODBMS (Object-Oriented Database Management System), UNISQL/4GE, on a SUN workstation.
6. CONCLUSION
To develop an integrated manufacturing system, the main bottleneck we need to overcome is the integration of the information produced by the subsystems. Information integration requires a common framework representing manufacturing functions and data. In this paper, a new information modeling methodology is proposed to analyze manufacturing systems and to design an integrated information model which coherently represents manufacturing functions and data. This methodology describes manufacturing functions and data, and their relationships with a uniform representational scheme of class. The proposed methodology has the following features: (1) The hierarchical and parallel structure of manufacturing systems can be grasped through functional diagrams. (2) Various semantic properties of manufacturing information (functions, data, and relationships) can be represented in a single integrated information model. (3) The flexible design of manufacturing systems is possible: a manufacturing function can be defined by its unit functions. (4) Straightforward translation from the class dictionary to a specific data dictionary of OODBMS is possible. (5) The proposed methodology develops an object-oriented design methodology, and extends it from logical design level to conceptual design level. By analyzing and designing a manufacturing information system using OOMIS, we can develop an integrated information model for an integrated manufacturing environment. We are now carrying out an extensive experimentation with this methodology, and developing automated support tools. Our future work will also include the extension of OOMIS to an integrated knowledge representation model based on the ideas presented in this paper. Acknowledgement--This work was supported in part by the KOSEF Engineering Research Center for Intelligent Automation at Pohang Institute of Science and Technology.
REFERENCES 1. R. R. Bravoco and S. B. Yadav. Requirement definition architecture--an overview. Comput. Ind. 6, 237-251 (1985). 2. R. R. Bravoco and S. B., Yadav. A methodology to model the functional structure of an organization. Comput. Ind. 6, 345-361 (1985). 3. R. R. Bravc~o and S. B.I Yadav. A methodology to model the information structure of an organization. J. Syst. Software & 59-71 (1985). 4. R. R. Bravoco and S. B. Yadav. A methodology to model the dynamic stru~ute of an organization. Inform. Syst. 10, 299-317 (1985). 5. U.S. Air Force. ICAM Functional Model Manual IDEF. Air Force Material Laboratory, Wrisht-Patterson AFB, Ohio (1981). 6. U. Rembold and R. Dillman. Computer-Aided Design and M~ufacturing Methods and Tools. Springer, New York
(tgss). 7. O. Doumemeingts. Design methodology for advanced muufactuting systems. Compt. Ind. 9, 271-296 (198T). 8. O. D o ~ et a/. ORAI approach to ~ and contmlti~ adnnmd manufacturing system in CIM environman[. In Aabanced Informatlan Technolog~s for IndustrialMaterial Flow SYStems (Editedby S. Y. Nof and C. L, Modies), Springer,New York (1989). 9. O. H. Bray. CIM: The Data M~agmJ~t,nt Strategy.DigitalPrees,New York 0988).
A manufacturing information system
353
10. A. Di Leva and F. Vemadat. Information system analysis and conceptual database design in production environments with M*. Comput. Ind. 9, 193-217 (1987). 11. A. Dileva and P. Giolito. Information system design and analysis of manufacturing environments, the new M* approach. Computer Applications in Production and Engineering. North-Holland, Amsterdam (1989). 12. C. Hsu and L. Rattner. Information modeling for computerized manufacturing. IEEE Trans. Syst. Man Cybernet. 20, 758-776 (1990). 13. J. Rumabugh et al. Object-Oriented Modeling and Design. Prentice-Hall, Engiewood Cliffs, N.J. (1991). 14. P. Wegner. Concepts and paradigms of object-oriented programmins, OOPSLA-89 Keynote Talk (1989). 15. G. Booch. Object-Oriented Design and Applications. Benjamin/Cummings, New York (1991). 16. C. U. King, S. S. Adams and E. L. Fisher. Representation of manufacturing entities. In Intelligent Manufacturing (Edited by M. Ollff). Benjamin/Cummings, New York (1989). 17. F. Vernadat. A conceptual schema for a CIM database. CAD~CAM Integration and Innovation. SME (1985). 18. S. Y. W. Su. Modeling integrated manufacturing data with SAM*. IEEE Comput. Mag. 34-49 (1986). 19. D. M. Weber and C. L. Moodie. Distributed, intelligent information system for automated, integrated manufacturing systems. In Advanced Information Technologiesfor Industrial Material Flow Systems (Edited by S. Y. Nof and C. L., Moodies). Springer, New York (1989). 20. E. Barkmeyer and M. J. Mitchell. An architecture for distributed data management in CIM. U.S. Department of Commerce Report No. NBSIR86-3312 (1986). 21. G. Miller. The magical number seven, plus or minus two: some limits on our capacity for processing information. Psychol. Rev. 63, 81-97 (1956). 22. C. Batini, M. Lenzerini and M. Mosarini. View integration. In Methodology and Tools for Database Design (Edited by C. Cedri). North-Holland, Amsterdam (1983). 23. N. C. Federman and R. M. Steiner. An interactive material planningand control system for manufacturing companies. Hewlett-Packard J. 3-12, April (1981).