The Emerald Research Register for this journal is available at www.emeraldinsight.

com/researchregister

The current issue and full text archive of this journal is available at www.emeraldinsight.com/1741-038X.htm

Data model design for manufacturing execution system

Bing-hai Zhou, Shi-jin Wang and Li-feng Xi
Department of Industrial Engineering, School of Mechanical Engineering, Shanghai Jiaotong University, Shanghai, Peoples Republic of China
Abstract
Purpose Since the data model plays an important role in designing manufacturing execution system (MES) database, this paper seeks to provide a generic and adaptable data model for MES, which can facilitate and improve the MES development. Design/methodology/approach Extended entity-relationship (EER) model technique is adopted to build the data model of MES. Findings Based on MES functions and database requirement analysis, four subjects structures of MES database is abstracted from a system integration point of view. These four structures are independent relatively but also have close interrelation. Each structure is modeled with EER model. Research limitations/implications The presented data model mainly focuses on discrete manufacturing MES, which perhaps limits its usefulness elsewhere, and the data model still need further testing in manufacturing enterprises with different scales. Practical implications A prototype MES system is developed and implemented, the results show that the proposed EER modeling approach can establish and make clear complex relationships among entities existed in a manufacturing system, which lays the foundation for adaptable and modular MES software development and implementation. Originality/value This paper fulls a fundamental need of designing data model for MES and provides a main framework for developing MES data model, which provides reference for researches both in academia and industry to build specic relational data models for specic needs. Keywords Management information systems, Manufacturing systems, Data handling, Modelling Paper type Research paper

Data model design for MES

909
Received April 2004 Revised September 2004 Accepted October 2004

1. Introduction In the distributed manufacturing environment, manufacturing execution system (MES) is to provide the information and control decision link between the master planning system (Deuel, 1994) at higher level and the equipment control system (Burggraaf, 1995) at the lower level. Namely, MES provides up-to-the-minute mission-critical information about production activities across the shop oor and supply chain via communications networks (e.g. local area networks), resulting in the optimization of activities throughout all aspects of the manufacturing process. MES accomplishes this task by guiding, initiating, responding to, and reporting on plant activities in real time, by using current and accurate data. This rapid response to changing conditions, together with a focus on reducing non-protable activities, lead to more efcient plant
This work was supported by China 863 CIMS HiTech Project under grant 2003AA414120 and 2003AA414033. The authors would like to express sincere appreciation to Dr Yang Weiming for participating in the data model development. The authors also would like to thank the editor and the anonymous referees for their detailed and helpful comments on this paper.
Journal of Manufacturing Technology Management Vol. 16 No. 8, 2005 pp. 909-935 q Emerald Group Publishing Limited 1741-038X DOI 10.1108/17410380510627889

JMTM 16,8

910

operations and processes (MESA International White paper, 1997). In the last decade, the importance of integrated MES in plant information systems has been emphasized by researchers in both academia and industry (David and Joe, 1995; Steven, 1996; Barry et al., 1998; Hori et al., 1999; Chung and Jeng, 2002; Sieberg and Walter, 2003). How do we design, build and implement a cost-effective, integrated MES to plant needs? The key steps are to assess the present state of integration and the availability of infrastructure, and then to map the information needs of all the operational layers, based on this, the database of the MES has to be designed for the plant-specic conditions. Namely, the key infrastructure of MES is database systems. The general task of database design is to map a given real-world application into the formal data model of a given database management system. There is a general agreement on the division of database design into following steps (Rochfeld and Negros, 1992; Chung and Jeng, 2002): requirement analysis, conceptual design, logical design, and physical design. Requirement analysis consists of extracting requirements from users. In this step, all information needed to correctly model the desired application is collected and analyzed. Conceptual design develops requirements into a conceptual model (e.g. the entity-relationship (ER) model) that is used to describe the conceptual schema. In this step, a conceptual schema is created, describing the structure of the database independent of the underlying system. Logical design translates the conceptual schema into the data model (e.g. the relational model) supported by the target database management system. Physical design transforms the logical schema into a physical schema suitable for a specic conguration. In this paper, our objective is to analyze MES functions and database requirement from a system integration point of view. In particular, a general MES extended entity-relationship (EER) schema is built. In the remainder of this paper, Section 2 describes MES functions and database requirement analysis. In order to build MES data model efciently, EER modeling technique is introduced in Section 3. Section 4 establishes detailed MES EER models according to database requirement analysis. An application example of MES database is introduced in Section 5. Finally, Section 6 presents the contribution of this study and future work. 2. MES functions and database requirement analysis 2.1 MES functions MES is but one key element of an information system supporting a manufacturing facility. In the distributed manufacturing environment, there are two other key functional groupings with which a MES must interface in order to effectively manufacture product. Figure 1 indicates these functional groupings: enterprise resources planning (ERP) and controls. ERP consists of those systems that provide nancial, order management, production and materials planning, and related functions. The modern ERP systems focus on global planning, business processes and execution across the whole enterprise (intra-enterprise systems), with an accrued recent importance of aspects like supply chain planning and the whole supply chain management aspects and extending to include the whole inter-enterprise supply chain. Controls are usually hybrid hardware/software systems such as distributed control systems (DCS), programmable logic controllers (PLC), distributed numerical control (DNC), supervisory control and data acquisition (SCADA) systems, and other controls designed to automate the way in which the product is being manufactured (MESA International White paper, 1997).

Although ERP and Controls are both integral parts of a plants automated operation, the two systems must be linked so the plant oor will know whats happening at the business level and vice versa. This is where MES ts in taking a seat right in the middle. An integrated MES system correctly implemented should computationally assist many functions of product manufacturing, which are mainly as follows (Barry et al., 1998; Hori et al., 1999): . Resources allocation and status. MES should be able to manage production resources available in the automated manufacturing shop oor, such as machines, tools, labor resources, specic abilities, materials and supporting equipment, and others like documentation that need to be available for production teams to work. . Detailed operations schedule. MES should develop the sequential operation of the production based on properties, attributes, characteristics and revenue associated to each product, in each order. A subset of MES objectives is the reduction of the setup time of machines to the minimum, and to be able to do so, the system should consider, in the scheduling of the activities, aspects like colors, shapes, formulas, analog processes and equivalent components, and to generate the most efcient mixes of operations. . Production units allocation. MES should manage the entire product ow in plant, be it by order, nal product, work or any other method as desired. The sequence in which these orders are processed should be controlled by MES, taking in consideration the chain of properties and all eventual changes in plan that could occur even after the job has already begun. MES should have the capacity of changing the work plan on shop oor and also to consider the use of remanufacturing and disposal of items during the production process, and to balance the activities in course at all times. . Maintenance activities management. MES should make the activities related to planning and scheduling of preventive maintenance, as well as trigger corrective maintenance jobs in alarm situations. A history of maintenance activities should also be kept together with the current status of all maintenance teams. . Process management. MES should monitor the production activities in a continuous way and feed operators with enough information for corrective actions to be taken in the processes in case of necessity. It is advisable that MES should identify and process the alarms coming from shop oor in such a way

Data model design for MES

911

Figure 1. MES an enterprise ow model

JMTM 16,8
.

912

that production managers are aware of situation and have the means to take the necessary actions. Tracking and genealogy of products. In the manufacturing process of each order, MES should keep track of the equipment and materials being used in each product, operators and supervisors responsible for each step of the production, possible problems and the tools involved. After each step is nished, the information should be made available in a way that each sold product can be tracked to its components and processes.

2.2 MES database requirement analysis To implement the functions of integrated MES in a distributed manufacturing environment, it is very important to build a distributed database system. Our objective of designing the MES database system attempts to support MES functions. Namely, MES software developers can develop all kinds of MES functions on the basis of the database system. Through analyzing the mentioned MES functions, we summarize following four subjects structures for MES database: (1) system resource subjects structure (SRSS); (2) detail executable plan subjects structure (DEPSS); (3) system status subjects structure (SSSS); and (4) system conguration subjects structure (SCSS). SRSS denes geometry attributes and performance parameters of all sorts of resource objects involved in production activities, and describes interrelation among these objects. Resource objects in SRSS are composed of six basic classes, namely, program class, text class, workpiece class, tools class, xture class and pallet class. Each class can be further divided into sub-classes according to specied applications in the production system. For example, program class can be divided into NC program class, measure program class. Text class can be classied into drawing class, technique specications class, operational rule class, test method class, standard class and so on. SRSS is indispensable to execute detailed operation schedule. If some resources are unavailable, a production planning is invalid, which will lead to failure of detailed operations schedule. In addition, SRSS describes attributes and features of all resource objects in the production system, which prepares for maintenance activities management. If certain resources are depleted, then operators can make efforts to supplement the depleted resources timely. Moreover, SRSS supports the system congurable since it adopts the methods of class division and level abstract. New resource can be added into the system and destroyed ones can be removed from the system easily. Thus SRSS can be extended or reduced according to different actual applications. DEPSS denes objects related to various plan processes which include production scheduling plan, vehicles plan, equipment plan, tools plan and so on, and denes interaction information among these objects. Once an order is input in the production system, tasks associated with the order will be immediately decomposed into more detailed sub-tasks, according to operations of the system process plan. Considering current or planned status of needed resources for the sub-tasks, DEPSS can balance the burden of resources or try to ensure a resource available when it is needed.

The information of these resources and the interaction information among them in DEPSS make it possible to make suitable and feasible production plan, which ensures the following production activities be executed properly and timely. With the dynamical changes of plans in production environment, DEPSS supports to update the objects and information stored in the system. The information of the stored objects and interrelation information among these objects can be displayed and retrieved through the user interface according to needs of users. SSSS denes the system status information and relations among them. SSSS prepares for real-time decision supports for the whole production system. SSSS mainly concerns status of objects involved in all kinds of production activities, which includes object locations, object states, relations among the objects and so on. For example, at 9:00 am, the position of a vehicle in a material ow route or the state a piece of equipment can be shown in SSSS. Therefore, the information stored in SSSS is a snapshot of the system status at a specied time. Because most production activities in production system are dynamic and uncertain, real-time status of all resources in production system is the heart for control decision of production. So SSSS is the key and foremost part of the four subjects structures. During the process of production, production activities follow the detailed operations schedule. However, the dynamic and uncertainty of production activities always result in rescheduling and active schedule, SSSS can support to collect real-time information of resources, which responses for rescheduling and ensures the production activities be carried out timely and effectively. SCSS aims to describe the conguration of the production system accurately. First, SCSS describes which resource objects are in the production system, illustrates what specic performance attributes and features these resource objects possess, determines organization relationships among these resource objects (e.g. parallel), and depicts how these objects lay out in the production environment. Second, SRSS must clarify which material ow sub-systems are in the production system and relationships among these sub-systems, make out how many vehicles and routes for transportation are in each material ow sub-system, and describe the relationships between the vehicles and routes for each material ow sub-system (e.g. a route is whether suitable for a vehicle or not). In addition, layout of each route, performance attributes of vehicles, whether a piece of workpiece can be loaded on a vehicle or not, and the number of load positions for each vehicle have to be described clearly. SCSS separates the conguration of the production system and the specic application of conguration clearly. Therefore, SCSS has the property of reconguration. The content of the SCSS can be changed and updated at runtime. Through SCSS, the production system can describe the location of equipment in the production environment denitely. Moreover, thanks to describing specic performance attributes of equipment clearly, SCSS prepares for the equipment maintenance, which is the basis for maintenance activities management. SCSS denes the material ow routes and vehicles in production system, which is helpful for tracking of production and process management. 3. Data model technique Among four steps of database design, conceptual data model design plays an important role. The resulting conceptual schema requires be stable and easy to apprehend for end-users. To this end, an appropriate data model technique should be used. The ER model, originally proposed by Chen (1977), is a well-known conceptual

Data model design for MES

913

JMTM 16,8

914

data model and has been widely used for conceptual database modeling due to its simplicity and clarity of structuring concepts (Martin and Uwe, 1991; Fahrner and Vossen, 1995). However, using the ER model as a conceptual schema representation has proved difcult because of the inadequacy of the initial modeling constructs. Thus, a number of extended ER (EER) models have appeared, which provide the generalization and full aggregation capabilities in addition to the basic ER constructs (Teorey et al., 1986; Czejdo et al., 1990; Victor and Arie, 1992; Saiedian, 1997). Concerning another popular modeling method, object-oriented (OO) modeling method, EER is superior in representing relationship than it (Shoval and Shiran, 1997; Liao and Palvia, 2000). From an end-user perspective, EER inheritance has closer correspondence to the real world than OO model, in the sense that it is synthesized from facts about tangible entities, rather than imposed through software engineering process. Considering the complex relationships in MES, in this paper, a version of the EER model technique (Teorey et al., 1986) is adopted, for this model provides simple representations for concepts of generalization hierarchy and subset hierarchy in addition to advantages of original ER model. Moreover, the EER model is selected for conceptual design because of its widespread use in designing relational databases, and because extensive work has already been done on translating EER models into relational data models (Teorey et al., 1986; Markowitz and Makowsky, 1990; Victor and Arie, 1992; Fahrner and Vossen, 1995; Kolp and Zimanyi, 2000). 3.1 EER model representations The EER diagram representations adopted from Teorey et al. (1986) are modied as shown in Figure 2. The EER diagram has a high expressive power and exibility to represent the knowledge of a complex system. Many features form an important basis to support the proposed specication methodology, and they mainly include:

Figure 2. The representations of graphical formalism for the EER model

Entities (entity sets) refer to the principal objects about which information was to be collected and usually denoted a person, place, thing, or event of informational interest. Entities can be distinguished by the regular of their identifying attributes. Regular entities have internal identiers that uniquely determine the existence of entity occurrences. Weak entities derive their existence from the identifying attributes. Attributes are used to describe the entities in detail by giving them descriptive properties such as name, address, and weight. There are two types of attributes: identiers and descriptors. The former is used to uniquely distinguish between the occurrences of an entity, whereas the latter is used to describe an entity occurrence. As shown in Figure 2, identiers are further divided into two types: internal and external. An entity that has only internal identier is a regular entity. An entity that has external identier is usually a weak entity, which includes existence dependencies and identication dependencies. Relationships (relationship sets) are used to represent real-world associations among one or more entities. Relationships have semantic meaning, which is indicated by the connectivity between entity occurrences (one-to-one, one-to-many, and many-to-many), and the participation in this connectivity by the member entities may be either optional or mandatory. In our data model, the relationship constraints are mainly expressed by (min-card, max-card) format (Batini et al., 1992). Subset hierarchy denition. An entity S is a subset of another entity E if every occurrence of S is also an occurrence of E. A subset hierarchy is the case in which every occurrence of the generic entity may also be an occurrence of other entities that are potentially overlapping subsets. Generalization hierarchy denition. An entity E is generalization of the entities X1, X2, . . . , Xn. If each occurrence of E is also an occurrence of one and only one of the entities X1, X2, . . . , Xn. A generalization hierarchy occurs when an entity is partitioned by different values of a common attribute.

Data model design for MES

915

3.2 Transformation rules of EER model to relations In order to transfer EER models to relational data models efciently, the transformation rules must be dened and applied. The main transfer rules applied in this paper are summarized as follows (Teorey et al., 1986; Fahrner and Vossen, 1995; Reda, 2003): . Transform each entity into a relation containing the key and non-key attributes of the entity. If there is a many-to-one relationship between an entity and another entity, add the key of the entity on the one side into the relation. If there is a one-to-one relationship between an entity and another entity, then add the key of one of the entities into the relation for the other entity. The addition of a foreign key due to a one-to-one relationship can be made in either direction. One strategy is to maintain the most natural parent-child relationship by putting the parent key into the child relation. Another strategy is based on efciency: add the foreign key to the relation with fewer tuples. . Every entity in a generation hierarchy or subset hierarchy is transformed into a relation. Each of these relations contains the key of the generic entity.

JMTM 16,8
.

916

The generic entity relation also contains non-key values that are common to all the entities so related, and the other relations contain non-key values specic to each subtype entity. Another option is to include all subtype attributes in the super-type entity and allow null values. Transform every many-to-many binary (or unary) relationship into a relationship relation with the keys of the entities and the attributes of the relationship.

In order to illustrate the rules mentioned above, a simple example (extracted from DEPSS EER diagram, see Section 4) is shown in Figure 3, where SPP stands for system process plan, SOPR stands for operation, SRList stands for system resource list, and RType stands for system resource type. RType could further be divided into six sub-resource entities, namely, tool (represented by ToolsCla), xture (FixtureCla), program (ProgramCla), workpiece (WorkpieceCla), pallet (PalletCla), and text (TextCla). The followings are relations transferring from EER diagram shown in Figure 3. Relations between entities are established through keys underlined: . Many-to-one. There exists many-to-one relationship between RType entity and SRList entity. Each RType can have at most one SRList (optional). One SRList could use several RTypes. Relations: SRList (SPPNo, SPPVerNo, . . . , RTypeNo1, . . .), RType (RTypeNo1, . . .). Here, SPPNo is system process plan number, SPPVerNo is system process plan version number, RTypeNo1 is resource type number. . Generalization hierarchy. Different types of resources are partitioned by values of a common attribute. Relations: RType (RTypeNo1, common attributes), ToolsCla (RTypeNo1, specic attributes), FixtureCla (RTypeNo1, specic attributes), ProgramCla (RTypeNo1, specic attributes), WorkpieceCla (RTypeNo1, specic attributes), PalletCla (RTypeNo1, specic attributes), TextCla (RTypeNo1, specic attributes).

Figure 3. An EER model for relationship transformation rules

Subset hierarchy. Resources with special attributes are shown as overlapping subsets based on partitions on values of different attributes. Relations: SPP (SPPNo, SPPVerNo, common attributes), SOPR (SPPNo, SPPVerNo, specic attributes). Many-to-many. Every SOPR could have many RType, or none. Every RType could belong to many SOPR, or none. Relations: SOPR (SPPNo, SPPVerNo, SPOPNo, . . .); RType (RTypeNo1, . . .); USES (SPPNo, SPPVerNo, SPOPNo, RTypeNo1). Here, SPOPNo is system operation number.

Data model design for MES

917

Owing to its relative simplicity and its easy understanding, one-to-one relationship is not introduced in this paper. Interested reader can refer to existing literatures (e.g. Teorey et al., 1986; Markowitz and Makowsky, 1990; Fahrner and Vossen, 1995; Reda, 2003) to get some points. 4. MES data model In this section, the entities consisted in each of the four subjects structures are dened and described in detail. Figures 47 shows the structure of subjects in an EER model way. Attributes are not included in gures for simplicity and clarity, but are dened and used in practical application. The dashed rectangles in gures denote entities, which do not belong to the current structure, but have relationships with entities in the current structure. 4.1 System resource subjects structure Based on the aforementioned requirements specication, the conceptual data model of SRSS is built, and the data model is shown in Figure 4. The model mainly describes resource families and their interrelations. Main entities and entities relationships in the model are described in detail in Table I. For claritys sake, each entity is given both in full name and symbol name.

Figure 4. The EER schema for SRSS

JMTM 16,8

918

Figure 5. The EER schema for DEPSS

Data model design for MES

919

Figure 6. The EER schema for SSSS

JMTM 16,8

920

Figure 7. The EER schema for SCSS

Entity name ResourceType (RType)

Descriptions and relationships An upper level entity of six basic resource entities, that is, this entity has generalization hierarchy relationship with the six basic resource entities. An instance of the entity relates to at least one instance of Operation (SOPR) (introduced in DEPSS), and relates to one and only one instance of the SystemResourceList (SRList) (introduced in DEPSS) entity A weak entity is on the existence of the SystemProcessPlan (SPP) (described in DEPSS) entity. An instance of the entity describes a piece of specic workpiece. An instance of this entity relates to at least one instance of the SystemProcessPlan (SPP) entity, for different system process plan can product a same piece of workpiece The entity can be further divided into sub-text les, which include drawings, technique specications, operational rules, test methods, standards and so on The attributes of an instance of the entity provide information associated with a specic program such as register code, name, GT number, saving le path This entity groups static information of tools in the system. The information focuses on the unique code of a tool and all physical attributes and features of the tool. An instance of the entity relates to at least one instance of the ToolsValue (ToolsValue) entity A weak entity is on the existence of the ToolsClass (ToolsCla) entity. An instance of this entity is to describe the theoretic offsets of a tool along the orientation of a coordinate axis An instance of the entity describes an accessional device type for tools adjustment in advance. One such accessional device can adjust some kinds of tools, so one instance of the entity relates to at least one instance of the ToolsClass (ToolsCla) entity An instance of the entity describes the static information of a pallet. The information mainly includes the code of the pallet and the physical attributes of the pallet Each instance of the entity provides detailed static information for a unique xture. The information includes the unique code of the xture and all physical attributes of the xture. An instance of this entity relates to at least one instance of the FixturePostionClass (FixturePosCla) entity A weak entity depends on the identication of the FixtureClass (FixtureCla) entity. An instance of the entity describes a specic xing position of a xture and a type of xing. Each instance of the entity has at least one instance of the FixtureOrigin (FixtureOrigin) entity. Some xtures may be suitable for xing a piece of workpiece, so more than one instance of the entity correspond to one instance of the WorkpieceClass (WorkpieceCla) entity (continued)

Data model design for MES

921

WorkpieceClass (WorkpieceCla)

TextClass (TextCla) ProgramClass (ProgramCla) ToolsClass (ToolsCla)

ToolsValue (ToolsValue)

AdjustToolsType (AdjuToolsType)

PalletClass (PalletCla) FixtureClass (FixtureCla)

FixturePostionClass (FixturePosCla)

Table I. Entities descriptions and relationships explanation for SRSS

JMTM 16,8

Entity name FixtureOrigin (FixtureOrigin)

Descriptions and relationships A weak entity depends on the identication of FixturePostionClass (FixturePosCla) entity. An instance of this entity describes the theoretic offset of a local coordinate origin of a unique xture A weak entity depends on the identication of the FixturePostionClass (FixturePosCla), Workpiece (WorkpieceCla) and Operation (SOPR) entity. An instance of the entity denotes the interrelations between a workpiece and a xing position of a specic xture, which illustrates whether the xture can x the workpiece or not

922

FixtureWorkpiece (FixtureWorkpiece)

Table I.

4.2 Detail executable plan subjects structure The entities in this structure can be classied into three groups: entities related to system process plan, entities related to system production task, and entities related to equipment and resources assignment plan. These three groups of entities are by no means independent; on the contrary, they have close interrelations. The data model is shown in Figure 5. The detailed denitions of entities and their relationships are described in detail in Table II. 4.3 System status subjects structure Three groups of entities are dened in this structure: entities related to the status of resources, entities related to the status of material ow points and vehicles, and entities related to the status of equipment and DNC tasks. The EER schema for this structure is shown in Figure 6. The detailed introduction of entities and their relationships are illustrated in Table III. 4.4 System conguration subjects structure Four groups of entities are dened in this structure: entities about conguration of equipment, entities about conguration of material ow system, entities about conguration of coexistence between resources and tasks, and entities about conguration of users and system information. The EER schema for this structure is shown in Figure 7. The detailed introduction of entities and their relationships are illustrated in Table IV. 5. Application example of MES database In our nal relational data model, there are at least eighty tables in the MES database, which is implemented on Microsoft Access. The screen shot shown in Figure 8 is one part relation of the whole relational data model. On the basis of the database, a prototype MES system is developed in Visual C 6.0 environment. The screen shot shown in Figure 9 is one user interface of the developed system, which aims to optimal production planning and real-time control in a shop oor where there are seven pieces of different equipment, all kinds of necessary resources. The system can accommodate to different shop oors by changing some parameters. The system is to realize the

Entity group Entity name Entities SystemProcessPlan related to (SPP) system process plan

Descriptions and relationships

Data model design for MES

Entities related to production task

Entities related to equipment and resources assignment plan

An instance of the entity corresponds to a specic system process plan. This entity has many-to-many relationships with the SystemTask (ST) entity. A system process plan usually has many operations, so this entity and the Operation (SOPR) entity form subset hierarchy relationship Operation (SOPR) A weak entity is on the identication of the EquipmentStatistic (EquipSta) entity. An instance of the entity relates (not necessary) to instances of the SystemProcessTask (SPT) entity and describes all the necessary information for a specic task SystemResourceList A weak entity is on the identication of the ResourceType (SRList) (RType) and Operation (SOPR) entity. An instance of the entity describes a set of resources used in a specic task. An instance of this entity relates (not necessary) to instances of the Operation (SOPR) entity, and relates (not necessary) to instances of the ResourceType (Rtype) entity SystemTask (ST) A weak entity depends on the identication of the SystemProcessPlan (SPP) entity. An instance of this entity describes a set of the system process tasks, so the entity and the SystemProcessTask (SPT) entity form the subset hierarchy relationship SystemProcessTask A weak entity is on the identication of the Operation (SPT) (SOPR) entity and the EquipmentStatistic (EquipSta) entity. An instance of the entity describes a sub-task that can be nished on a piece of equipment at a time, and the instance corresponds to one instance of the Operation (SOPR) entity. Each instance of this entity relates to one instance of the TaskResourceList (TRList) entity. The entity has one-to-many relationship with the ToolsAssignmentPlan (ToolsAP) entity and the FixtureAssignmentPlan (FixtureAP) entity. As shown in the gure, this entity is the heart of the data module. It has relations with equipment, system process operation, system resources, equipment capacity plan, tools assignment plan and xture assignment plan EquipmentCapacityPlan A weak entity depends on the identication of the (ECP) EquipmentStatistic (EquipSta) entity and the existence of the Calendar (Calendar) entity. The entity groups system production tasks, which are to be nished on the specic equipment during a specied period of time. An instance of this entity relates to one instance of the ECPMaterialFlowPoint (ECPMFP) entity. A capacity plan may be suitable for some equipment, so each instance of the entity corresponds to at least one instance of the EquipmentStatistic (EquipSta) entity. One instance of the entity relates (not necessary) to one or more instances of the SystemProcessTask (SPT) entity Calendar (Calendar) A weak entity is on the identication of the EquipmentStatistic (EquipSta) entity. An instance of the entity describes the plan information of a piece of specic equipment during a specied period of time. The plan information includes working plan, maintenance plan and so on (continued)

923

Table II. Entities descriptions and relationships explanation for DEPSS

JMTM 16,8

Entity group Entity name EquipmentStatistic (EquipSta)

Descriptions and relationships

924

Entities related to equipment and resources assignment plan

Table II.

Every instance of this entity describes main conguration information and performance parameters of a piece of specic equipment. The entity belongs to SCSS, but due to its interrelation with entities of DEPSS, we introduce it here. In the system plan, a piece of equipment includes many plan activities, including capacity plan, calendar plan, xture assignment plan and so on ECPMaterialFlowPoint A weak entity depends on the identication of (ECPMFP) EquipmentStatistic (EquipSta) and MaterialFlowPointConf (MFPConf) (introduced in SCSS). An instance of the entity describes the interrelation between a piece of equipment and a material ow point ToolsAssignmentPlan A weak entity is on the identication of the (ToolsAP) SystemProcessTask (SPT) entity. An instance of the entity describes an assignment plan of a specic tool on a piece of given equipment. An instance of the SystemProcessTask (SPT) entity may not use a tools assignment plan or may use some tools assignment plans, so the entity has one-to-many relationships with the SystemProcessTask (SPT) entity FixtureAssignmentPlan A weak entity is on the identication of the (FixtureAP) SystemProcessTask (SPT) entity. An instance of the entity describes an assignment plan of a specic xture on a piece of given equipment. Each instance of the entity builds a relation among the specic task, a piece of equipment and a specic xture ToolsLoadPlan A weak entity is on the identication of the (ToolsLP) EquipmentStatistic (EquipSta) entity. An instance of this entity describes a specic load/unload plan of a specic tool on a piece of given equipment. Each instance of this entity relates to one instance of the EquipmentStatistic (EquipSta) entity, but not vice versa TaskResourceList A weak entity depends on the identication of the (TRList) SystemProcessTask (SPT) entity and the ResourceStatus (RStatus) (described in SSSS) entity. This entity builds relations with the SystemProcessTask (SPT) entity and the ResourceStatus (RStatus) entity. An instance of the entity relates to one and only one instance of the SystemProcessTask (SPT) entity ResourcePrepareTask A weak entity depends on the identication the (RPTask) ResourceStatus (RStatus) entity. An instance of this entity describes resource preparation on a piece of specic equipment before carrying out a given system process task. One instance of the entity relates to only one instance of the TaskResourceList (TRList) entity

optimum management of the whole manufacturing process, including order receiving, planning, scheduling, equipment status and resource status management and monitoring, the shop oor layout reconguration and so on. Figure 9 mainly output the job-shop scheduling result, as shown in the upper part of the right-hand view of the gure. As one important part of the system plan, the job-shop scheduling aims to get more optimal resource utilization, including equipment rational plan and corresponding tools, xtures plan. The main algorithm used in

Entity group An upper level entity. An instance of the entity represents the status of a specic resource. Attributes of an instance of the entity provide dynamic information of a resource instance

Entity name

Descriptions and relationships

Entities related to the status of resources

ResourceStatus (RStatus)

PalletStatus (PalletStus)

FixtureStatus (FixtureStus)

WorkpieceStatus (WorkpieceStus)

ProgramStatus (ProgramStus)

TextStatus (TextStus)

ToolsStatus (ToolsStus)

TaskResourceListConguration (TRListConf)

ToolsArrivalStatus (ToolArrStus)

FixtureArrivalStatus (FixtureArrStus)

Every instance of the entity describes a real-time status of a specic pallet. Attributes of an instance represent the dynamic information of a pallet in the system, including location information and working status and so on Every instance of the entity describes a real-time status of a specic xture. Attributes of an instance dene the dynamic information of a xture in the system A weak entity depends on the identication of the SystemProcessTask (SPT) entity. An instance of the entity describes a status of a piece of workpiece. Attributes of an instance mainly provide the information of being transported or being performed on a piece of equipment A weak entity is on the identication of the EquipmentStatistic (EquipSta) entity. An instance of the entity describes a status of a specic program, including being in use, being in transported, being in idle, and been planned. Programs are used to direct setting and adjustment of xtures and tools, so the entity has relationships with the ToolsRealValue (ToolsRValue) entity and the FixtureRealOrigin (FixtureROrigin) entity Every instance of the entity describes the status of a given text. Attributes of an instance dene dynamic information of the text, including being transported, being used An instance of the entity describes a status of a specic tool. Such statuses mainly are being in use, being transported, been destroyed, been planned A weak entity is on the identication of the ResourceStatus (Rstatus) entity. It denes some existing real-time relationships among resources. For example, a piece of workpiece can be hold by a pallet, then the workpiece and the pallet has a corresponding relationship Attributes of an instance of the entity provide dynamic information of a specic tool, which mainly includes as follows: whether the tool is arrived, which equipment the tool will be loaded and which tool measure program will be used Attributes of an instance of the entity provide dynamic information of a specic xture, which mainly includes as follows: whether the xture is arrived, which equipment the xture will be loaded and which xture loading program will be used (continued)

Data model design for MES

925

Table III. Entities descriptions and relationships explanation for SSSS

926

JMTM 16,8

Entity group

Entities related to the status of material ow points, vehicles

Entities related to ResourceStatusMFP (RStusMFP) the status of material ow points, vehicles

Table III.
Descriptions and relationships Material ow points include goods position of warehouse, buffer for input/output, pallet exchange place and so on. An instance of the entity is to describe a status of a specic material ow point in the system. The dynamic status includes being idle, being in use and holding. An instance of the entity relates to one instance of the ResourceStatus (RStatus) entity, but not necessary vice versa. Such relationship exists between the VehicleStatus (VehiStus) entity and the MaterialFlowPoint (MFP) entity, the ResourceStatusMFP (RStusMFP) entity and the MaterialFlowPoint (MFP) entity An instance of the entity describes the location and the status of a specic vehicle in the system. The real-time location of a vehicle describes which material ow point the vehicle locates or on which material ow route the vehicle locates. The statuses are being idle, stop, breakdown and so on. Every instance of this entity relates to at least one instance of the VehiclePositionStatus (VehiPosStus) entity, because a vehicle has at least goods position on it. At a specied time, a vehicle may be locating on a material ow point, so one instance of the VehicleStatus (VehiStus) entity relates to at most one instance of the MaterialFlowPoint (MFP) entity A weak entity depends on the identication of the VehicleStatus (VehiStus) entity. An instance of this entity describes a status of a specic goods position on a vehicle. The goods position may be idle or kept at a specied time. A resource may not be loaded on a goods position of a vehicle, so every instance of the ResourceStatus (RStatus) entity relates (not necessary) to one instance of this entity A weak entity depends on the identication of the ResourceStatus (RStatus) entity and the VehiclePositionStatus (VehiPosStus) entity. An instance of this entity builds the dynamic relationship between a specic goods position on a vehicle and a specic resource. Every instance of the entity relates to one instance of the ResourceStatus (RStatus) entity, but not necessary relates to one instance of the VehiclePositionStatus (VehiPosStus) entity, because some goods positions on a vehicle do not allow loading the specic resource A weak entity is on the identication of the ResourceStatus (RStatus) entity and the MaterialFlowPoint (MFP) entity. An instance of this entity builds the dynamic relationship between a specic material ow point and a specic resource. Every instance of the entity relates to one instance of the ResourceStatus (RStatus) entity, but not necessary relates to one instance of the MaterialFlowPoint (MFP) entity, because some material ow points do not allow existing the specic resource (continued)

Entity name

MaterialFlowPoint (MFP)

VehicleStatus (VehiStus)

VehiclePositionStatus (VehiPosStus)

RStatusVehiclePosition (RstusVehiPos)

Entity group

Entity name

Descriptions and relationships

Entities related to the status of equipment and DNC tasks

EquipmentStatus (EquipStus)

ResourceOnEquipmentStatus (EquipRTypeStus)

EquipmentResource (EquipRTypeConf)

ToolsRealValue (ToolsRValue)

FixtureRealOrigin (FixtureROrigin)

An instance of the entity describes a status of a piece of specic equipment and the DNC status. The entity has relation with the ResourceOnEquipmentStatus (EquipRTypeStus) entity, the ToolsRealValue (ToolsRValue) entity and the FixtureRealOrigin (FixtureROrigin) entity, because a status of a piece of equipment may includes tools loading and adjusting, xture loading and adjusting, and other resources performed status on the equipment A weak entity is on the identication of the EquipmentStatus (EquipStus) entity. Attributes of an instance of the entity represent the dynamic information of resources equipped on a piece of specic equipment. Each instance of the entity relates (not necessary) to one or more instances of the ResourceStatus (RStatus) entity A weak entity depends on the identication of the ResourceStatus (RStatus) entity and the ResourceOnEquipmentStatus (EquipRTypeStus) entity. An instance of the entity describes the corresponding relationship between a piece of specic equipment and resources equipped on the equipment. One instance of the entity relates to one instance of the ResourceOnEquipmentStatus (EquipRTypeStus) entity, and relates (not necessary) to one or more instances of the ResourceStatus (RStatus) entity A weak entity depends on the existence of the ToolsStatus (ToolsStus) entity and the identication of the EquipmentStatus (EquipStus) entity and the ProgramStatus (ProgramStus) entity. An instance of the entity describes the real offset along an orientation of a coordinate axis direction of the specic tool. One or more instances of the entity relate to one and only one instance of the ProgramStatus (ProgramStus) entity and the ToolsStatus (ToolsStus) entity. One or more instances of the entity relate to at most one instance of the EquipmentStatus (EquipStus) entity A weak entity is on the existence of the FixtureStatus (FixtureStus) entity and the identication of the EquipmentStatus (EquipStus) entity and the ProgramStatus (ProgramStus) entity. An instance of the entity describes the real offset of a local coordinate origin along a global coordinate axis direction. One instance of the entity relates to only one instance of the FixtureStatus (FixtureStus) entity (continued)

Data model design for MES

927

Table III.

928

JMTM 16,8

Entity group

Table III.
Descriptions and relationships A weak entity depends on the identication of the ECPMaterialFlowPoint (ECPMFP) and the ProgramStatus (ProgramStus) entity. An instance of the entity describes some real-time information of a system process task selected according to an instance of the EquipmentCapacityPlan (ECP) entity. The information mainly illustrates on which equipment the task will be carried out, which programs will be followed, which material ow point corresponds to the equipment and how many and what resources will be loaded dynamically on the equipment A weak entity is on the identication of the SystemProcessTask (SPT) entity and the ResourceStatus (RStatus) entity. An instance of the entity describes specic resources involved in a specic DNC task during at a specied time. One or more instances of this entity relate to one and only one instance of the DNCStatus (DNCStus) entity A weak entity depends on the identication of the WorkpieceStatus (WorkpieceStus) entity and the SystemProcessTask (SPT) entity. An instance of the entity describes the status of a piece of specic workpiece during the specic DNC task. It builds the relation between workpiece and DNC tasks. One or more instances of this entity relate to one and only one instance of the DNCStatus (DNCStus) entity A weak entity depends on the identication of the ResourceOnEquipmentStatus (EquipRTypeStus) entity and the SystemProcessTask (SPT) entity. An instance of the entity describes relationships between instances of the DNCStatus (DNCStus) entity and the ResourceOnEquipmentStatus (EquipRTypeStus) entity. By aid of this entity, we can transform many-to-many relation between the DNCStatus (DNCStus) entity and the ResourceOnEquipmentStatus (EquipRTypeStus) entity to one-to-many relation among these three entities Instances of the entity describe communication protocols among all sorts of objects

Entity name

DNCStatus (DNCStus)

DNCResourceList (DNCTRList)

DNCWorkpieceStatus (DNCWorkpieceStus)

DNCEquipmentResource (DNCEquipRType)

Protocal (Protocal)

Entity group

Entity name

Descriptions and relationships

Entities about conguration EquipmentClassInformation (EquipClaInfo) of equipment

EquipmentRelation (EquipRela)

Entities about conguration MFSConguration (LsysConf) of material ow system BufferConguration (BuffConf) MaterialFlowPointConf (MFPConf)

RouteConguration (RouteConf)

VehicleConguration (VehiConf)

A weak entity depends on the identication of the EquipmentStatistic (EquipSta) entity. An instance of the entity describes the information of a class of equipment. Apart from all the attributions of the EquipmentStatistic (EquipSta) entity, an instance of the entity has attributions of the equipment status and the DNC status A weak entity depends on the identication of the EquipmentStatistic (EquipSta) entity. An instance of the entity describes the relationships among equipment. A piece of equipment may be included in another piece of equipment, or may include another piece of equipment An instance of the entity describes the conguration information of a material ow system. The entity is a super entity, and includes four sub-entities, namely, buffer for in/out, material ow point, route and vehicle An instance of the entity describes the conguration information of the specic buffer for input/output. Buffer is one of the main parts in the material ow system An instance of the entity describes the conguration information of a specic material ow point. The information includes the location of the material ow point, the attribution of input/output: only for input or only for output or both for input and output, the description of the material ow point, and so on A weak entity depends on the existence of the MaterialFlowPointConf (MFPConf) entity. An instance of the entity describes the conguration information of a route in the material ow system. A route links two material ow points, so each instance of the entity relates to two instances of the MaterialFlowPointConf (MFPConf) entity An instance of the entity describes the conguration information of a specic vehicle in the material ow system. The information mainly includes physical size of the vehicle, vehicle control type, number of goods positions, and so on (continued)

Data model design for MES

929

Table IV. Entities descriptions and relationships explanation for SCSS

930

JMTM 16,8

Entity group VeGPositionConguration (VehiPosiConf)

Table IV. Entity name Descriptions and relationships A weak entity depends on the identication of the VehicleConguration (VehiConf) entity. An instance of the entity describes the conguration information of a specic goods position of a vehicle. One or more instances of the entity relate to one instance of the VehicleConguration (VehiConf) entity MaterialFlowPointAccessible (MFPAcc) A weak entity depends on the identication of the MaterialFlowPointConf (MFPConf) entity and the VehicleConguration (VehiConf) entity. An instance of the entity builds the relation between a vehicle and a material ow point. The relation describes whether the vehicle can arrive the material ow point or not. Each instance of the entity relates to two or more than two instances of the MaterialFlowPointConf (MFPConf) entity, and relates (not necessary) to one or more instances of the VehicleConguration (VehiConf) entity RouteAccessibeConguration (RouteAccConf) A weak entity depends on the identication of the RouteConguration (RouteConf) entity and the VehicleConguration (VehiConf) entity. An instance of the entity builds the relation between a vehicle and a material ow route. The relation describes whether the vehicle can arrive the material ow route or not. Each instance of the entity relates to one or more than one instances of the RouteConguration (RouteConf) entity, and relates (not necessary) to one or more instances of the VehicleConguration (VehiConf) entity RelationAmongMFPs (RelaMFP) A weak entity depends on the identication of the MaterialFlowPointConf (MFPConf) entity. The entity builds the relation among the material points not belong to the local material ow points and the material ow point belongs to local material ow point MFPAConf (MFPAConf) A weak entity depends on the identication of the MaterialFlowPointConf (MFPConf) entity. An instance of the entity describes the conguration information of the joint angle between a material ow point and a vehicle. One instance of MaterialFlowPointConf (MFPConf) entity relates to at most one instance of the MFPAConf (MFPAConf) entity (continued)

Entity group

Entity name

Descriptions and relationships

Entities about conguration EquipmentResourceType (EquipRType) of coexistence between resources and tasks

Entities about conguration MFPResourceType (MFPRType) of coexistence between resources and tasks

VeGPostionResource (VehiPosiRType)

Entities about conguration SystemConguration (SysConf) of users and system information UserConguration (UserConf)

A weak entity depends on the identication of the ResourceType (RType) entity and the EquipmentStatistic (EquipSta) entity. An instance describes the coexistence relation between equipment and resources. For example, whether a tool can be loaded on a piece of equipment or not is such a relation. Each instance of the entity relates to more than one instance of the ResourceType (RType) entity and the EquipmentStatistic (EquipSta) entity A weak entity depends on the identication of the ResourceType (RType) entity and the MaterialFlowPointConf (MFPConf) entity. An instance describes the coexistence relation between material ow points and resources. It describes whether a kind of resource can be used or existed in a specic material ow point. Each instance of the entity relates to at least one instance of the ResourceType (RType) entity and the MaterialFlowPointConf (MFPConf) entity. Each instance of the entity relates (not necessary) to at least one instance of the ResourceType (RType) entity and the MaterialFlowPointConf (MFPConf) entity A weak entity depends on the identication of the ResourceType (RType) entity and the VeGPositionConguration (VehiPosiConf) entity. An instance of the entity describes the coexistence relation between resources and vehicle goods positions, which shows whether a kind of resource can be loaded/unloaded on a specic vehicle goods position of a vehicle. Each instance relates to each instance of the MFPResourceType (MFPRType) entity. Like instances of the MFPResourceType (MFPRType) entity, instances of this entity have the same relation with instances of the ResourceType (RType) entity, the MaterialFlowPointConf (MFPConf) entity and the MFPResourceType (MFPRType) entity An instance of the entity describes the information of the system register and indication An instance of the entity describes the information of a user in the system. The information mainly includes user name, password, and right limitation

Data model design for MES

931

Table IV.

JMTM 16,8

932

Figure 8. The screen shot of one part relation of the MES relational data model

Figure 9. Screen Shot of one part of the developed prototype system

job-shop scheduling is ltered-beam search algorithm (Sabuncuoglu and Bayiz, 1999; Zhou et al., 2002, 2004). The criterion selected in this algorithm is makespan minimization. The beam search is used not only because of its speed but also because of additional desirable properties. First, it is exible in the sense that all kinds of scheduled resources (e.g. jobs, machines, tools) can be incorporated into the algorithm easily. Moreover, beam search makes it possible to generate job sequences of various lengths due to application of the changeable parameters (e.g. lterwidth, beamwidth). In addition, this method can be well utilized to generate partial schedules in a stochastic and dynamic environment. The lower part of the right-hand view shows the static attributes of equipment of the system, including equipment register code, GT number, equipment name and so on. Another pane of this view is information of orders. The information of order mainly describes attributes and status of an order. The left view shows buttons for other modules, including status management, resources management, orders management and equipment management. Except for effectiveness of dynamic scheduling, the developed prototype system has been proved to realize anticipated functions successfully. This shows in some sense that the proposed EER modeling approach makes it possible to establish and make clear complex relationships among entities existed in a manufacturing system, which lays the foundation for adaptable and modular software development and implementation. 6. Conclusion and future work In this paper, the detailed functions and database requirement analysis of MES are presented. By aid of the EER modeling technique, we establish the MES data model and develop a corresponding prototype system. In doing so, the main contribution of the study includes: . The summary of the general MES functions, which provides the basic guidance for development of various MESs. . Designing and building four general structures for MES database requirement analysis. Based on resource families, system plan, system status, and system conguration, the MES database requirement analysis is illustrated. These four structures are independent relatively, different further requirements can be extended from the four basic structures, which facilitate developing MES for different manufactureing enterprises. Meanwhile, these four structures have close interrelation, which makes for balancement of the production environment and provides a global decision support for management people. . The EER modeling technique is used to build the MES relational data model. This solves the problems that ER modeling techinique cannot solve, including weak entity denition, hirearchy relationship. The developed relational data model is recongurable and it provides a main framwork for developing MES relational data model. The developed data model is a generic and adapatable model, which provides referrence for researches both in academia and industry to build specic relational data models for specic needs. In the further study, we will focus on converting database from Microsoft Access into SQL Sever, since Microsoft Access is more apt to personal computer use while SQL

Data model design for MES

933

JMTM 16,8

934

Sever is more powerful in all other aspects, especially in client/sever aspect. Combining with the system status modular, a real-time scheduling modular will be developed to further enhance the exiblity of the system. On the one hand, we will further study to accommodate some algorithms other than the ltered-beam search algorithm, and try to study cooperation between different search algorithms. On the other hand, we will try to make exible room for different users to introduce their own dened algorithms in this model. Moreover, to be a better fundamental framwork of MES rational data model, the presented data model need further research and prove in manafacturing enterprises with different scales.
References Barry, J., Aparicio, M., Durniak, T., Herman, P., Karuturi, J., Woods, C., Gilman, C., Lam, H. and Ramnath, R. (1998), NIIIP-SMART: an investigation of distributed object approaches to support MES development and deployment in a virtual enterprise, Enterprise Distributed Object Computing Workshop, EDOC 98 Proceedings, pp. 366-77. Batini, C., Ceri, S. and Navathe, S. (1992), Conceptual Database Design, Benjamin/Cummings, Redwood City, CA. Burggraaf, P. (1995), MES software: preparing your questions, Semiconductor International, Vol. 18 No. 1, pp. 65-70. Chen, P. (1997), The entity-relationship model: towards a unied view of data, ACM Transactions on Database Systems, Vol. 1 No. 1, pp. 9-36. Chung, S.L. and Jeng, M.D. (2002), Manufacturing execution system (MES) for semiconductor manufacturing, IEEE International Conference on Systems, Man and Cybernetics, Vol. 4, pp. 7-11. Czejdo, B., Elmasri, R., Rusinkiewicz, M. and Embley, D.W. (1990), A graphical data manipulation language for an extended entity-relationship model, IEEE Computer, Vol. 23 No. 3, pp. 26-35. David, J.A. and Joe, H. (1995), Does a manufacturing execution system reduce the cost of production for bulk pharmaceuticals, ISA Transactions, Vol. 34 No. 4, pp. 343-7. Deuel, A.C. (1994), Benets of a MES for plant wide automation, ISA Transactions, Vol. 33 No. 10, pp. 123-9. Fahrner, C. and Vossen, G. (1995), A survey of database design transformations based on the entity-relationship model, Data & Knowledge Engineering, Vol. 15 No. 3, pp. 213-50. Hori, M., Kawamura, T. and Okano, A. (1999), OpenMES: scalable manufacturing execution framework based on distributed object computing, Systems, Man, and Cybernetics, IEEE SMC 99 Conference Proceedings, Vol. 6, pp. VI-398-VI-403. Kolp, M. and Zimanyi, E. (2000), Enhanced ER to relational mapping and interrelational normalization, Information and Software Technology, Vol. 42 No. 15, pp. 1057-73. Liao, C. and Palvia, P. (2000), The impact of data models and task complexity on end-user performance: an experimental investigation, International Journal of Human-Computer Studies, Vol. 52 No. 5, pp. 831-45. Markowitz, V. and Makowsky, J. (1990), Identifying extended entity-relationship object structures in relational schemas, IEEE Transactions on Software Engineering, Vol. 16 No. 8, pp. 777-90. Martin, G. and Uwe, H. (1991), Towards a semantic view of an extended entity-relationship model, ACM Transactions on Database Systems, Vol. 16 No. 3, pp. 369-416.

MESA International White paper (1997), MES Explained: A High Level Vision, White Paper, 6 MESA International White paper, September. Reda, A. (2003), Extracting the extended entity-relationship model from a legacy relational database, Information Systems, Vol. 28 No. 6, pp. 597-618. Rochfeld, A. and Negros, P. (1992), Relationship of relationship and other interrelationship links in ER models, Data & Knowledge Engineering, Vol. 9 No. 2, pp. 205-21. Saiedian, H. (1997), Evaluation of extended entity-relationship model, Information and Software Technology, Vol. 39 No. 7, pp. 449-62. Sabuncuoglu, I. and Bayiz, M. (1999), Job shop scheduling with beam search, European Journal of Operational Research, Vol. 118 No. 2, pp. 390-412. Shoval, P. and Shiran, S. (1997), Entity-relationship and object-oriented data modeling-an experimental comparison of design quality, Data & Knowledge Engineering, Vol. 21 No. 3, pp. 297-315. Sieberg, J. and Walter, R. (2003), A scheduling and resource optimizing MES for the semiconductor and MEMS industry, Advanced Semiconductor Manufacturing Conference and Workshop, ASMC03, IEEE/SEMI, Munich, pp. 101-5. Steven, W. (1996), Getting the MES model methods for system analysis, ISA Transactions, Vol. 35 No. 2, pp. 95-103. Teorey, T.J., Yang, D. and Fry, J.P. (1986), A logical design methodology for relational database using the extended entity-relationship model, ACM Computing Survey, Vol. 18 No. 2, pp. 197-222. Victor, M. and Arie, S. (1992), Representing extended entity-relationship structures in relational databases: a modular approach, ACM Transactions on Database Systems, Vol. 17 No. 3, pp. 423-64. Zhou, B.H., Zhou, X.J., Cai, J.G. and Feng, K. (2002), Beam search-based algorithm for exible manufacturing system scheduling, Journal of Dong Hua University, Vol. 19 No. 3, pp. 13-18. Zhou, B.H., Xi, L.F. and Cao, Y.S. (2004), A beam-search-based algorithm for the tool switching problem on a exible machine, The International Journal of Advanced Manufacturing Technology, online.

Data model design for MES

935