- Email: [email protected]
A structured methodology for implementing engineering data management
Robotics and Computer-Integrated Manufacturing 14 (1998) 275 — 296
A structured methodology for implementing engineering data management Yuh-Min Chen*, Tien-Heng Tsao Institute of Manufacturing Engineering, National Cheng Kung University, Taiwan 70101, Taiwan, ROC Received 5 September 1997; accepted 8 May 1998
Abstract One of the most significant positive effects on product and process development in recent years has been the application of data management techniques. Engineering data management or product data management is the most promising one. The implementation of engineering data management is heavily dependent on the engineering process and involves the technologies of management, engineering, and information. However, as there is no commonly acceptable approach and methodologies for implementing engineering data management, it’s implementation becomes a bottleneck. This paper presents a structured methodology for the implementation of engineering data management. The approach consists of a series of steps, from business and engineering process analysis, modeling and reengineering, through system design and modeling, to system realization. This research will facilitate engineering process improvement and the planning, design and implementation of engineering data management. Consequently, it will help increase product development capability and quality, reduce development cycle time and cost, and hence increase product marketability. ( 1998 Elsevier Science Ltd. All rights reserved. Keywords: Engineering data management; Product data management; Concurrent engineering; Enterprise modeling
1. Introduction Concurrent engineering has been recognized as the methodology for industry to meet global competition (Mills et al., 1991; Miller 1993; Clausing, 1994). The essence of concurrent engineering is an integrated and collaborative process, where people in different disciplines cooperate to design products and develop related processes through coordination, communication, and control (Davis and Trapp 1991; Cleetus 1992; Nagy et al., 1992; Chen et al., 1994). The key to the success of a concurrent engineering process is a complete understanding and sharing of product- and process-related information through the entire development cycle (Trapp 1991; Karinthi et al., 1992). To facilitate the concurrent engineering processes, tools are available to help manage product delivery activities and track products from conception to retirement and, at the same time, support effective communication and information sharing among
*Corresponding author. Tel.: 886-6-2757575 ext. 63922; fax: 886-62085334; e-mail: [email protected]. 0736-5845/98/$19.00 ( 1998 Elsevier Science Ltd. All rights reserved. PII: S0736-5845(98)00013-1
functional groups and individuals of a development team (Bradley and Agogino 1991; Wong and Sriram 1993). These tools are known as product data management (PDM) and engineering data management (EDM) (Miller, E. 1993; Stover, 1993; McIntosh, 1995; Chen and Hsiao, 1997). Most of the commercially available engineering data management systems have the following key elements in common (Miller et al., 1992; McIntosh, 1995): workflow and process management, project management, configuration management, design release management, product structure management, and configuration management (McIntosh, 1995). Although engineering data management is known by many different names, all of them share the same idea of providing a structured way to orderly and efficiently store, integrate, manage and control both data and engineering process from design, manufacturing to distribution. EDM is considered an ‘‘unifying’’ technology rather than a ‘‘point’’-type solution such as CAD or CFD (McIntosh, 1995). The implementation of EDM depends heavily on the characteristics of engineering process and involves the technologies of management, engineering,
276
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
and information. As no two organizations are the same, they must customize the processes and functions to fit their specific needs and circumstances (Miller et al., 1992; McIntosh, 1995). However, as there are no commonly acceptable approach and methodologies for implementing EDM, its implementation becomes a bottleneck. The objective of this research is to develop a structured methodology for implementation of EDM through applying and unifying the principles, methodology, and technology of concurrent engineering, system engineering, and EDM. The objective can be attained by developing the method and procedure for (1) engineering process analysis, modeling, and reengineering, (2) system design, modeling and realization, and (3) their integration. Developing this methodology involves: (1) domain investigation, (2) methodology study, (3) methodology development and integration, and (4) application examination. Domain investigation characterizes the engineering process and requirements for supporting engineering process from the data management point of view, as well as the functionality of EDM systems. Methodology study reviews related methodologies for process modeling, process reengineering, information modeling, and data modeling. etc. Based on the results of domain investigation and methodology study, an approach for implementing engineering data management is developed and then examined in a real-world case.
2. Overview of the proposed methodology This section presents the overview of the proposed methodology for implementing EDM. The methodology includes the phases of business and process analysis, system design and modeling, and system realization as shown in Fig. 1. The goal of business analysis is to learn the business vision, organizational structure, and functions of business units so as to guide the re-engineering process in meeting the corporate mission. Similarly, the objective of process analysis and modeling is to identify the motivation and goals for implementing EDM and to fully understand the characteristics of the engineering processes, thus facilitating process re-engineering. The result of process analysis and modeling is an as-is process model that can be used for reengineering. An actor-based integrated process model (AIM), which consists of an information flow model, an activity model, and a functional model, is devised to properly and efficiently model the engineering process. Process re-engineering is performed by employing principles of concurrent engineering as well as information technology based on the as-is model. The aims of process re-engineering are to make the process more efficient and effective, and eventually meet the process
Fig. 1. Steps of the proposed methodology.
goals. The result of process reengineering is a to-be process model. The phases of system design and modeling include the tasks of requirement analysis, system planning. The requirement analysis defines what the desired system must do; system planning defines how it will be done; system design makes high-level decisions about the overall framework; and system modeling focuses on the description of the structures and behaviors of the elements of the software system and their relationships. Based on the to-be process model, requirement analysis and planning of engineering data management system is performed. It includes software functional requirement analysis, hardware configuration requirement analysis and administrative requirement analysis. According to the requirements, the system planning is conducted to outline the software system framework, hardware system capacity and configuration, and administration organization for EDM. The software system framework that depicts the system functions and their relationships from the user perspective is used for user interface design by decomposing system functions. Before performing system modeling, the elements of the EDM system should be identified on the basis of the engineering process model obtained in the business and process analysis phase. To obtain the characteristics and behavior of the elements, an information object diagram,
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
277
an information life cycle model, an information state transition diagram and an activity object diagram are developed based on the process model. The system modeling aims to build a design model based on the analysis model, but containing implementation details. The details are added to the design model in accordance with the strategy established during system design. In the proposed methodology, an object-oriented modeling technique is employed to define the structures and behaviors of the elements in the system as well as the relationships among the elements in terms of objects. The result of system modeling is a set of object classes that correspond to the elements in the system. The phase of system realization includes the tasks of development approach selection, system implementation, integration and testing. The determination of a system implementation alternative is made on the basis of budget, technical ability and resources. Once the approach is determined, the system implementation can be done by building underlying database systems and coding the object classes defined in the system modeling stage.
3. Business and process analysis This section presents the methods for business analysis, process analysis, process modeling, and process re-engineering. 3.1. Business analysis Business analysis includes the tasks of the initial analysis, preliminary planning, and detailed business analysis. The goal of the initial business analysis is to understand the current situation and characteristics of the enterprise, and the requirements and expectations on the implementation of EDM so as to prepare a proposal for implementing EDM. The initial business analysis is conducted by interviewing the corporate high-level management team or the engineering department head. The result of business analysis is an organizational structure with functional or responsibility description of each functional unit in the structure, and/or flow charts of engineering processes. Based on the findings in the initial business analysis, a proposal for implementing EDM is prepared through negotiating and discussing with the enterprise management team. The proposal should contains the enterprise background, problems encountered, objective and requirements, current methods for EDM and related facility, system plan, budget, steps of the tasks, schedule, and outputs. Accompanied with the proposal is a project plan that contains project objectives, project organization and responsibility, project tasks description, schedule, and outputs.
Fig. 2. Steps of detailed business analysis.
The implementation of EDM actually starts with the detailed business analysis. The goal of detailed business analysis is to characterize the work details of business activities to facilitate the analysis and modeling of engineering processes. As shown in Fig. 2, the analysis begins with an organizational functional analysis if the processes to implement EDM are not clear. The result of organizational functional analysis is an enterprise or engineering department organization chart with the individual actors at the bottom layer. The works of each individual actor in the organizational structure are identified and described in a work analysis sheet (e.g. work analysis sheet A). Work sheet A contains information of the activities performed by the actor, including suppliers of each work and their supporting inputs, consumers of each activity and the outputs to them, and the usage of the information. Process flows can be identified by connecting the inputs and outputs into and from the activity. The processes are then prioritized for re-engineering.
278
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
Fig. 3. Work step diagram.
The process activity analysis is conducted on the activities of the target processes. The details of each activity is described in another work analysis sheet (e.g. work analysis sheet B) and a work step diagram. Work analysis sheet B contains information such as work title, relevant processes, tools used, application software used, servers and their supporting inputs, consumers and the outputs to them, the usage of the information, importance rating and media of the inputs and outputs, the major and minor functions of the work and their importance ratings, the type of the work (i.e. procedural or non-procedural), reference or supporting information and media, and other person involved. The work step defines the procedural details of the activity by using the notations of data flow diagram (Page-Jones, 1988). Figure 3 shows an example of work step diagram. 3.2. Process analysis and modeling According to the results of business analysis, the process models of the target processes can be built using a proposed process modeling technique as, described. 3.2.1. Process model Modeling an engineering process represents the characteristics, behavior, and relationships element in the process. According to the business analysis in the previous section, an engineering process can be seen as a complex dynamic system consisting of concurrent and/or cooperative processes, where each process is a flow of activities that are triggered by some real-world events and performed by people from various organizational units using tools to process engineering items. From the EDM aspect, the elements in engineering processes can be classified as the items to be processed and the functions to process these items. They are represented in an object diagram using Rumbaugh’s notation
(Rumbaugh 1992) as shown in Fig. 4, where rectangular boxes denote classes of elements. An association is drawn as a line between classes, with which a verb in a problem statement is attached. Aggregation is drawn like association, except a small diamond indicates the assembly end of the relationships. The generalization is indicated by a triangle connecting a superclass to its subclasses. The proposed process model, which consists of a set of activity models, an information flow model, and an activity functional model is developed based on the results of business analysis. The relationships between the business analysis results and the process model is illustrated in Fig. 5. 3.2.2. Activity diagrams An activity is a set of elementary ordered or nonordered operations executed to realize the goals of the activity. The graphical representation of activities is shown in Fig. 6, which makes use of a box with four legs — ICOR. The ‘I’ stands for the input information to the activity, which is provided by suppliers, the ‘C’ represents the coordination information or shared information between collaborative activities through activity interactions, the ‘O’ is the output information to the consumers, and the ‘R’ denotes the reference information that can be queried from reference information resources. 3.2.3. Activity model An activity model that defines the work flow of an activity is the micro view of the activity. It consists of a series of operations, decisions, data (inputs, outputs, reference, coordination), and messages. Figure 7 gives an example of the activity model. The notation of the activity model is shown in Fig. 8. In-process information is the input, output or coordination information of an activity, which is the trigger of the activity. Examples of in-process information are order
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
279
Fig. 4. Elements in an engineering process and their relationships.
Fig. 5. Relationships between business analysis results and process model.
forms, product models, and text files. The information folder represents an aggregation of a set of in-process information. Instead of triggering an activity, reference information is static data referenced while performing an activity. An example of reference information is machine and tool data referenced for process planning. Information sequence, which indicates the number of steps that the information has been operated on, is shown in the upper-right corner of an in-process information symbol. The information number indicates the number of duplications of information. Similar to in-process information, messages appear in the locations of input, output, and communication; however, they do not have fixed formats and donot need to be stored in an ordinary database. Actions are operations performed to complete an activity. Decisions are made to choose one of two options; while routings are made to determine a series of options. Delivery indicates the location for information distribution. An output information without a delivery symbol shows that the information is stored for reference rather than distributed to other activities. A terminator represents a workflow is started or terminated without a trig-
Fig. 6. Activity diagram.
Fig. 7. Activity model.
gering in-process information. A ‘‘connection’’ connects two connective activities. 3.2.4. Information flow model An information flow model defining the flow of information along the flow of activities can be developed
280
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
Fig. 8. Activity model notation.
view of information processing, for example ‘‘create’’, ‘‘edit’’, ‘‘store’’, and ‘‘distribute’’ an order form. Actor and location indicate who and where to perform an activity are also indicated. 3.2.6. Integrated process model The information flow model, activity functional model, and activity model together form a process model that represents the integrated aspect of the models. The relationships between these models is illustrated in Fig. 10. Fig. 9. The information flow model.
3.3. Process re-engineering by connecting the inputs, outputs and coordination of the activity diagrams. Figure 9 shows an example of information flow model. 3.2.5. Activity functional model To further define the functional aspect of activities, the functional model of activities is developed as an ‘‘activity functional model’’. The activity functional model defines mechanisms for coordination, activity-specific tools, actor, location, and operational functions of an activity. The coordination mechanisms are the functions for supporting process coordination and communication. Activity-specific tools are tools used to perform an activity. Examples of activity-specific tools are CAD, CAE and project management systems. An activity functional model also represents three operational functions of an activity. They are (1) the function of the activity itself, such as product design or process planning, (2) the operations performed on information in the activity, for example ‘‘produce’’ a product model, and (3) the micro-
The goal of process re-engineering is to rationalize and concurrentize the engineering process so as to reduce excessive delay or costs. It consists of the tasks of process goal identification, problem identification and resolution, process rationalization and concurrentization, and validation (Fig. 11). The first step of process re-engineering is to clarify the goals of the process and make sure that the goals meet the corporate mission and strategy. A strategy analysis is then performed to develop the strategy and methods for achieving the process goals. Similarly, the strategy for achieving process goals should also meet the corporate strategy. A cause-effect diagram as shown in Fig. 12 is used for strategy analysis. Problem identification and resolution aim to identify the problems of the process and analyze the causes of each problem. The resolutions, each of which may consist of one or several methods, are then developed to resolve the problem. Cause-effect diagrams are also used in the analysis (Fig. 13).
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
281
Fig. 10. The integrated process model.
Fig. 11. Steps of process re-engineering.
The objective of process rationalization is to ensure that each activity in the engineering process contributes to the process goals. Value analysis is conducted on each activity by
z identifying the reason for the existence of the activity, z clarifying the importance of the output of the activity to its consumer(s), z checking if this activity can eliminated or replaced.
z identifying the function of the activity, z clarifying if the function helps achieve process goals,
The other principles of process rationalization include: shortening the duration of activities, eliminating
282
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
Fig. 12. Cause-effect diagram for goal identification and strategy analysis.
redundant activities, discarding non-value-added activities, partitioning a complicated activity into simpler and more controllable subactivities, combining two series and closely related activities, and eliminating cycles (Kusiak, et al., 1994). Process concurrentization is conducted by analyzing the relationships between activities based on the input, output, and coordination information of activities. The relationships between activities can be classified as either sequential, concurrent or collaborative. The sequential
relationship between activities defines a strict ordering relation between two activities, where one activity should be fully executed before the other can be executed. Activities with concurrent relationships are both the successors of a certain activity and have no interaction between each other. They can be therefore performed concurrently. Activities with collaborative relationships should be performed cooperatively or collaboratively through information and knowledge sharing as a result of their strong interactions. Validation is to check if the to-be process is acceptable and better than the as-is process. Theoretically, process simulation and evaluation should be performed based on the parameters of quality, cost and time. However, since most of the engineering activities are non-procedural and their quality, cost, and time consumed are highly dependent on the product complexities and actors’ experiences, development of the evaluation model and determination of the values of the parameters are still research issues (Aldowaisan and Gaafar, 1997). Since this research does not intent to resolve these issues, validation at this stage is done by simply comparing the number of the activities in the to-be and as-is processes and the number of steps in each of their activities.
4. System development The business and process analysis discussed in the previous sections helps promote an understanding of the real-world engineering process and data management,
Fig. 13. Cause-effect diagram for problem identification and resolution analysis.
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
thus providing a practical basis for system development and implementation. The output of the process re-engineering is a to-be process model. According to the to-be process model, the analysis, design and modeling of the EDM system can be performed. This section presents an approach for system development that fully integrates the process model developed in the business and process analysis and modeling phase. 4.1. Functional requirement analysis The functions for EDM can be classified into processwide functions such as work flow management and team library management and activity-specific functions such as message passing and assignment. The activity-specific functions can be identified from the workflow of the activity models. Some of these functions are commonly used in most of the activities and some others can be further decomposed into lower-level functions, both of which can be generalized as generic functions for system implementation. As the example in Fig. 14 shows, the functions for information processing include information receiving, information distribution, library access, and database query, which are functions that can be generalized as generic functions for information processing. 4.2. System planning and design Based on the results of requirement analysis, the planning and design of the EDM system is performed. The system planning outlines the software system framework, hardware system capacity and configuration, and administration organization for engineering data management, while system design specifies the details based on the outlines.
283
The software system framework defines the system functions and their relationships from the user perspective by grouping and decomposing the required functions identified in the previous stage. The result of software system framework design is a system functional decomposition structure that can be used for user interface design. The system configuration defines the structure of the computer systems in accordance with the system functionality and the locations of the actors performing activities. 4.3. System modeling 4.3.1. System modeling overview System modeling builds a set of object classes that correspond to classes of elements in the domain of EDM. The proposed system modeling methodology uses four kinds of models to describe an EDM system: an object model, a dynamic model, a functional model, and a data model. The object model, dynamic model, and functional model are similar to those in Rumbaugh’s object modeling technique (OMT) (Rumbaugh, 1992). The object model defines the static, structural, and data aspects of the framework in terms of objects and relationships that correspond to elements in the domain of EDM. The dynamic model defines the temporal, behavioral, and control aspects of the framework in terms of event and states of these elements. The functional model defines the transformational and functional aspects of the framework values and functions. Data modeling, in the proposed methodology, converts the object-oriented information model into relational data base schema for implementation of data bases. System modeling starts with the identification of the elements in the EDM system based on the process model
Fig. 14. An example of functional requirement identification.
284
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
obtained in the phase of business and process analysis. Object modeling is then conducted by classifying the elements and specifying their relationships using classification, generalization and association techniques. The results of object modeling are an activity object diagram, an information object diagram and an actor object diagram, that define the object classes in the system and their relationships. Dynamic modeling includes the tasks of event identification, state transition diagram development, information life cycle modeling, and information relationship modeling. The events are identified from the activity model of the process model. They are then used to define the state transition diagram of each object class. In order to help the control of workflow and engineering process, as well as the distribution of information, an information life cycle model is developed based on the information flow model in the process model. Similarly, an information relationship model is derived to define the relationships between information items so as to facilitate the tracking of related information and maintenance of their associativity. Functional modeling specifies the procedural details of the methods in the object classes. Data modeling converts the object-oriented information model into entityrelationship models for the development of relational databases. 4.3.2. Object modeling According to the process model, the key elements in engineering processes include the process itself, activities, actors, tools, organization, and information items (see also Fig. 4). Since tools can be defined as the attributes of activities or actors and the organization can be treated as
the attribute of actors, the object diagram of the elements can be reduced as shown in Fig. 15. A process is the aggregation of activities; activities are performed by one or more than one actors; a person can perform one or more than one activity; information items are associated with activities as inputs, outputs or for reference; the information items as well as activities have relationships among one another. (1) Information object diagram: Information involved in the engineering process can be identified from the input, output, coordination and reference of activity diagram of process model. They can be classified as product and process data, business process data, activity reference data, posted information and on-line communication information (Fig. 16). Product and process data are basically the outputs of the process activities, such as product models, mold models, process plans, assembly plans, and engineering drawings. One hand of business process data are those that flow along the engineering process and drive the process. Typical examples of business process data are business forms such as order forms, work orders and request for proposals. The business process data also include information related to process status. Activity reference data are those that are referenced for performing an activity. Examples of reference data are material data, machinability data, company historical data, project documents, and operation standards. Posted information is basically public information that is posted in public domain and available to the public, such as new product lines, process status and work results. On-line communication information are knowledge shared during activity interactions. They are transmitted in forms of mails, talks and discussions.
Fig. 15. Object diagram.
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
285
Fig. 16. Information object diagram.
Fig. 17. Activity object diagram.
The relationships between information items can be classified as the relationships between information items and the relationships between versions of an information item. The examples of the former include attach/ attached—by, depends—on/depended—on—by, and contains/ is—in, while the examples of the latter are is—superseded— by/is—revised—as, is—checked—out—as/ is—checked—out—of, and is—copy—of/is—copied—as. (2) Activity object diagram: Activities involved in the engineering process can be identified from the activity models of the process model. They can be classified as the ones along the flow of engineering process and the others related to the engineering process. The former, which can be obtained from the information flow model, are referred to as workflow activities, such as assembly layout, preliminary design, detail design and mold design; the latter are seen as supporting activities, such as process
control, project management, system administration, and configuration (Fig. 17). (3) Actor object diagram: Actors involved in the engineering process can be identified from the functional model of the process model. The characteristics of an actor, such as the role an actor plays, the location, accessibility to engineering data and tools of an actor, can be defined as the attributes of the actor object class. Therefore, there is no need to further classify the actors. The actors can be defined in terms of one actor object class. 4.3.3. Dynamic modeling Object modeling examines the static structure of the constructs in EDM by identifying the structure of the objects in it and their relationships. Dynamic modeling describes changes to the objects and their relationships over time. The main construct of dynamic modeling is
286
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
control information, including the sequence of events, states, and operations that occur within a system of objects. (1) Events and states: The object model presented in the previous section described the possible patterns of objects and links that can exist in the EDM system. The attribute values and links of an object at a single moment in time are called its ‘‘state.’’ Over time, the user may perform operations or the objects may stimulate each other, which results in a series of changes in their states. An individual stimulus from outside the system (i.e. the user performs operations) is called an ‘‘external event’’, while an ‘‘internal event’’ occurs if it is from one object to another. The response to an event depends on the state of the object receiving it and can include a change of state or the sending of another event to the original sender or to a third object. External events to the system occur when activity actors perform operations on the system. Therefore, they can be identified from the activity model or functional model of the process model. The internal events occur during the interactions among the objects as well as changes of object states. The former can be obtained from the object relationships specified in an object diagram, while the latter can be identified through the development of the state transition diagrams of object classes. Information object diagrams define the information object classes and their relationships. (2) State diagrams: A state diagram describes the behavior of a single class of objects. A state diagram is a graph whose nodes are states and whose directed arcs
are transitions labeled by event names. A state is drawn as a rounded box containing an optional name. A transition is drawn as an arrow from the receiving state to the target state; the label on the arrow is the name of the event causing the transition. All the transitions leaving a state must correspond to different events. Figure 18 gives an example of a state diagram. After it is created, a product item can reside in a workbench or bin of the work area of an activity or in a team library. It may be associated with a product structure or exist individually before being added to a product structure or removed from a product structure. The item can be sent to or received from another activity work area. (3) Information life cycle model: The information life cycle model of an information item denotes the transition of the information item along the engineering process and repository. It is derived from the information flow model of the process model. The information life cycle model can facilitate the control, tracking and distribution of information items, as well as the control of work flow, especially for the form type of information items. Figure 19 shows the generic representation of information life cycle models, where the rounded block represents the activities; the arrow represents the flow of the information items; and the information items can reside in the work area of an activity (i.e. temporary storage) or in a team library (i.e. permanent storage). 4.3.4. Object class development An object class is defined in terms of class name, attributes, and methods. One of the purposes of the
Fig. 18. The state diagram of product item object class: an example.
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
287
Fig. 19. The generic representation of information life cycle model.
Fig. 20. Operation and information accessibility matrix.
modeling discussed previously is to help obtain the object classes, their attributes and methods to completely define them. This section presents how to obtain the attributes and methods from the process model, object models and dynamic models. (1) Actor object class: The actor object class defines the role and information accessibility of actors, as well as the activities performed by the actors. The information accessibility and operations can be specified in an accessibility matrix derived from functional model as shown in Fig. 20.
(2) Information object class: As shown in Fig. 21, the information flow model denotes the information items, information relationships and information classification. The information object diagram, which is developed based on the information flow model, can be used to define the information class hierarchy, the type of each class, and the relationship between classes as attributes. Through the information flow model and functional model, the information life cycle model contributes the attributes of owner, status and location to the information object class. The events carried in the information
288
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
Fig. 21. The transformation from process model to information object class.
Fig. 22. The transformation from the process model to the activity object class.
state transition diagram denote the methods for transmitting the information items. The functions defined in the functional model can be used directly as the methods for manipulating the information items. (3) Activity object class: The attributes and methods of each activity object class are identified from the activity model, activity diagram, information flow model, functional model and activity state diagram, as shown in Fig. 22. From the activity model, the methods for manipulating information items by the activity can be identified; the activity diagram denotes the information items related to the activity; the functions defined in the functional model can be directly employed as the methods for manipulating information items; the functional model also provides actor and location as the attributes; and the events specified in activity state diagrams are also treated as the methods.
4.3.5. Functional modeling Functional models are employed to specify the meaning of operations and constraints in the object model and actions in the dynamic models. They consist of multiple data flow diagrams (DFDs), which specify the meaning of operations, constraints and actions. A DFD shows the functional relationships of the values computed by a system, including input values, output values, and internal data structures. A DFD contains processes that transfer data, data flows that move data, actor objects that produce and consume data, and data store objects that store data passively. 4.3.6. Data modeling The relationships defined in the information relationship model are at the application or process level; however, it may be required to break down the information
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
items and their relationships into lower-level database schemes for the implementation of databases. A data modeling is therefore performed to convert the information relationship model into an E—R model. To model the data, information items are classified into ones for being stored in databases and the others for being stored in repositories. The former are basically business items such as tables and forms while the latter include product items such as documents, files and product models. Each class of the product items, which is defined in terms of a class name and its attributes, is modeled as an entity with the attributes. The relationships are inherited from the information relationship model. For modeling the business items, the following steps are taken (Rosemary, 1989): (1) Conversion to table form — Taking the box or column headings and laying them out in simple table form with the headings across the top of the page and the values below the headings in rows. Repeating blocks of values should be listed against the set of values for which they repeat. (2) Key identification — Finding a column heading that will uniquely identify a full row of values. Ideally, it should be just one heading. If we cannot get uniqueness using one we must combine two or more until a unique identifier is found. (3) Creating first normal form — Removing the repeating groups and creating a separate table for the repeating group and duplicating the key value in the new table. Choosing a key for the new table in the same way as the key is chosen for the original table. (4) Conversion to second normal form — Looking at the keys that have been formed from a combination of column headings. Taking each part of the key in turn, looking through the non-key items and seeing if any items look like they depend on the part key rather than the whole key. (5) Conversion to third normal form — If any non-key item is dependent on another non-key item, remove the dependent group of items from the table and create a new table with the item it. (6) Conversion to data model — Convert the tables to data model.
289
5. System realization System realization is to convert the system models developed in the previous stage into software codes and finally become an EDM system. This phase includes the tasks of development approach selection, system implementation, integration and testing. 5.1. Determination of system development approach The determination of a system development approach is indeed the selection of software components for system implementation. The system can be developed in a highlevel engineering data management system shell such as MetaPhaseTM, a tool kit such as Lotus NotesTM, or using lower-level language such as C##, depending on the budget, resources, technical ability of the enterprise. In this paper, we focus the discussion on the aspect of technical ability. Figure 23 illustrates the decision flow for the determination of system development approach. It begins with the collection of system functions identified from the process model and a listing all candidate shells, tool kits
In practice, we should merge the data models from all resources into one composite data model by: 1. Merging entities that have the same name together. 2. Merging relationships that have the same name together, otherwise keep separate on the model. 3. Merging attributes that have common names, if the attributes have conflicting. 4. Refining the data model by removing synonyms, checking for attribute duplication, generalizing entities and relationships, removing redundancy, and resolving many to many relationships.
Fig. 23. Decision loop for development approach determination.
290
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
and languages for assessment. Each of the functions will be checked to see if it is a standard PDM or EDM function. If it is, the score of the shell or kit that provides this function is increased one; if it is not, the determination will be made further to see if there exists stand-alone software that can provide this function. The assessment of the software is conducted if the answer is yes. The assessment is made on the possibility for developing this function by employing the application interface functions (API) of the shell or kit if there is no existing software supporting this function. If it too difficult or impossible to develop the function by using the API of shells or kits, the selection of software languages for implementing this function is required. The loop continues until all functions are covered. Theoretically, the shell, kit or language with the highest score will be used for developing this system. 5.2. Implementation The implementation of an EDM system includes building underlying database systems and coding system object classes. The former requires defining relational tables based on the relational data schema developed in the data modeling stage and entering enterprise data into the tables. The latter varies with the tools employed for implementation; however, they all share the idea of system object construction.
6. Application example The applicability and feasibility of this methodology have been examined by conducting case studies at Metal Industries Research and Development Center (MIRDC), Mechanical Industry Research Laboratories of Industrial Technology Research Institute (MIRL-ITRI), and the Computer-Aided Concurrent Engineering Research Lab of the Institute of Manufacturing Engineering, National Cheng Kung University in Taiwan. The systems of these three cases were developed on a tool kit — Lotus NotesTM, an engineering data management shell — MetaPhaseTM, and C##, respectively. Here, we take the case of MIRDC as an example. 6.1. Process analysis and reengineering 6.1.1. Information flow model Figure 24 shows the information flow model of mold development. The actors involved in the process include R&D manager, design engineer, analysis engineer, process planning engineer, and production engineer. The R&D manager uses the draft plan of work orders as input and project files to perform project management. He distributes the work orders to all actors involved in the process and transmits the work notification and cost estimation to the mold design engineer. The mold designer uses the material database, standard mold design
Fig. 24. Information flow model of model development.
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
291
Fig. 25. Functional model of model development.
Fig. 26. Activity model of model development.
operation plan (SOP), and technical manual for reference when designing the mold. He produces the mold structure, mold assembly drawing, and mold component drawings. The mold structure is transmitted to the
analysis engineer for structural analysis, and the mold component drawings are transmitted to the process planner for process planning. The outputs from the process planning include a process plan and material
292
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
Fig. 27. System framework.
Fig. 28. System configuration.
requirement plan, which are transmitted to the production manager for production tryout. 6.1.2. Functional model Figure 25 shows the functional model of model development. The R&D manager is responsible for project management and process control; the design engineer
conducts structural design and component design; the analysis engineer performs structural analysis; the process planning engineer is responsible for mold manufacturing process planning and material requirement analysis; the production manager plays the role for production tryout. All the actors can work collaboratively through a mold development collaboration support
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
293
Fig. 29. Information object diagram.
system. The customer may communicate with the development team for process status through the collaboration system. 6.1.3. Activity model Figure 26 is the activity model of the design engineer for the mold development process. The main tasks of this activity include mold structure design and drawings, mold component design and drawing, mold assembly design and drawing, and mold component or assembly redesign. The inputs to the activity are work order, previous work completion notification, cost estimation information, and project information. The result of mold structure design will be distributed to the analysis engineer and the results of mold component design or redesign will be transmitted to the mold manufacturing process planner. The reference information used in this activity includes project files, raw material information, standard component information, fixture data, standard operation plan for mold design and other technical documents.
The system is configured as shown in Fig. 28. Application systems such as MIS, CAPP, CAD/CAM/CAE, and MRP are connected to the system via an application system interface. Information items produced by the application systems and the CACESS itself are stored in a relational database or a common repository, depending on the types of information. Both the database and repository are managed by an information management module. The engineering processes are classified into two major processes: molding product development and non-molding product development. Each of them consists of several inter-related processes and projects and are managed by a process control and project management module. 6.2.2. Object diagram The information items in the case are grouped into files such as machine data file, cost estimation file, mold development file, project information file, supplier information file, material data file, product model file, and standard operation plan document file. Each of them is further classified, as shown in Fig. 29.
6.2. System design and modeling 6.2.1. System framework and configuration According to the process model, a concurrent engineering support system (CACESS) was designed for MIRDC. This system consists of the modules of project management, process control, information management and system administration. Each of the modules provides functions as shown in Fig. 27.
6.2.3. Object models The object classes are developed according to objectoriented modeling. Some of the classes are shown in Fig. 30. 6.3. System implementation Based on the results of system design and modeling, a prototype engineering data management system
294
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
Fig. 30. Part of the information object classes.
Fig. 31. Interface for process control.
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
295
Fig. 32. Interface for process status viewing.
(Computer-Aided Concurrent Engineering Support System — CACESS) has been implemented in an environment equipped with an Acer Altos 9000 PCTM server and an Acer Power 590h PCTM workstation networked with six PC clients under Windows-NTTM. The software components employed in the implementation of this system include Lotus NotesTM 4.5 (Domino), MS ProjectTM, MS WordTM, and AutoCADTM. All of them support OLE functionality. The Lotus Notes 4.5 (Domino) is used as the core software component and also plays the roles of database server, Internet server and mail server. Figure 31 shows the user interface for the setup of the process for information item distribution and control. The project manager can define the activities and their sequence, as well as the flow of information through the interface, and view the process status via the interface shown in Fig. 32. 7. Conclusion and discussion This paper presents a structured methodology for the implementation of EDM. It supports integrated models and methods for analysis and modeling from business and process analysis at the organizational level through system design and modeling at system level to system implementation at an engineering level. The applicability and feasibility of this methodology have been examined by conducting a case study at Metal Industries Research and Development Center and Mechanical Industry Research Laboratories of Industrial Technology Research Institute in Taiwan.
The characteristics of this approach include: z it provides a tight link from business, organization and process to detailed system design and implementation description at an engineering level, which makes process analysis and reengineering more practical and useful, z it satisfies the principle of separation of concern, separation of functionality, and behavior (Vernadat, 1996), z it emphasizes the interactions and concurrence between activities to reflect the nature of concurrent engineering processes, and z it is simple and easy to understand. However, there are still some limitations that need further research to resolve: z it produces a static or paper model that is not computer-processable and is therefore of limited value to support management of change, z lack of the ability to analyze certain quantitative properties such as process performance evaluation and cycle times. To provide the capability, introduction of the time, cost and quality parameters into the models may be required.
Acknowledgements This work was supported by National Science Council, Taiwan, ROC under Grant No: NSC 86-2212E-006-034.
296
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
References Aldowaisan, T.A., Gaafar., L.K., A framework for developing technical process reengineering designs, Comput. Ind. Eng. 1997; 32 (3) 657—70. Bradley, S.R., Agogino, A.M., Design Capture and Information Management for Concurrent Design Addison-Wesley, New York, 1991. Chen, Y.M., Miller, R., Dik Lun, L., Object-oriented part model for geometric reasoning. J. Integrated Computer-Aided Eng. 1994; 1 (5), 375—95. Chen, Y.M., Hsiao. Y.T., A collaborative data management framework for concurrent team-oriented product and process development. Int. J. Comput. Integrated Manufar. 1997; 10 (6), 446—469. Miller, E., MacKrell, J., Johnson, R., Amman, K., PDM Buyer guide. Ann Arbor, CIMdata, Michigan, 1992. Clausing, D., Total Quality Development: A Step-by-Step Guide to World Class Concurrent Engineering. ASME Press, New York, 1994. Cleetus, K.J., Modeling evolving product data for concurrent engineering. CERC Technical Report. CERC-TR-RN-92-016. West Virginia University, Concurrent Engineering Research Center, 1992. Curtis, B., Lellner, M., Over, J., Process Modeling. Commun. ACM 1992; 35 (9) 75—90. Davis, T.A., Trapp, G., Advancing concurrent engineering using step. CERC Technical Report, CERC-TR-RN-91-012. West Virginia University, Concurrent Engineering Research Center, 1991. Karinthi, R., Jaganna, V., Montan, V., Petro, J., Raman, R., Trapp, G., Promoting concurrent engineering through information sharing. Proc. ASME Winter Annual Meeting, Anaheim, California, 1992; 8—13 November 1992.
Kusiak, L., Nick, T., Wang, J., Reengineering of design and manufacturing process. Comput. Ind. Eng. 1994; 26 (3) 521—36. McIntosh, G., Engineering Data Management: A Guide to Successful Implementation. McGraw-Hill Book Company, New York, 1995. Miller, E., Managing engineering data: an inside look at PDM. Computer-Aided Eng. July, SR1—SR8, 1993. Miller, L.C.G., Concurrent Engineering Design. Society of Manufacturing Engineers, Dearborn, Michigan, 1993. Mills, R., Beckert, B., Carrabine, L., The future of product development. Computer Aided Eng. 1991; 10, 38—46. Nagy, R.L., Ullman, D.G., Dietterich, T.G., A data representation for collaborative mechanical design. Res. Eng. Des. 1992; 233—42. Meilir, P., The Practical Guide to Structured Systems Design. Yourdon Press, NJ, 1988. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W., Object-Oriented Modeling and Design. Prentice-Hall, NJ, 1992. Rosemary, R., An introduction to data and activity analysis. QED Information Sciences, 1989. Stover, R.N., EDM as an enabling technology. special report/ engineering document management. Comput Aided Eng. August, EDM1—EDM16, 1993. Trapp, G. Sharing Information: a CALS/CITIS, Concurrent Engineering and PDES/STEP Synergy. CERC Technical Report, CERCTR-TM-91-011. West Virginia University: Concurrent Engineering Research Center, 1991. Wong, A., Sriram, D., SHARED: An information model for cooperative product development. Res. Eng. Des. 1993; 5, 21—39.
A structured methodology for implementing engineering data management Yuh-Min Chen*, Tien-Heng Tsao Institute of Manufacturing Engineering, National Cheng Kung University, Taiwan 70101, Taiwan, ROC Received 5 September 1997; accepted 8 May 1998
Abstract One of the most significant positive effects on product and process development in recent years has been the application of data management techniques. Engineering data management or product data management is the most promising one. The implementation of engineering data management is heavily dependent on the engineering process and involves the technologies of management, engineering, and information. However, as there is no commonly acceptable approach and methodologies for implementing engineering data management, it’s implementation becomes a bottleneck. This paper presents a structured methodology for the implementation of engineering data management. The approach consists of a series of steps, from business and engineering process analysis, modeling and reengineering, through system design and modeling, to system realization. This research will facilitate engineering process improvement and the planning, design and implementation of engineering data management. Consequently, it will help increase product development capability and quality, reduce development cycle time and cost, and hence increase product marketability. ( 1998 Elsevier Science Ltd. All rights reserved. Keywords: Engineering data management; Product data management; Concurrent engineering; Enterprise modeling
1. Introduction Concurrent engineering has been recognized as the methodology for industry to meet global competition (Mills et al., 1991; Miller 1993; Clausing, 1994). The essence of concurrent engineering is an integrated and collaborative process, where people in different disciplines cooperate to design products and develop related processes through coordination, communication, and control (Davis and Trapp 1991; Cleetus 1992; Nagy et al., 1992; Chen et al., 1994). The key to the success of a concurrent engineering process is a complete understanding and sharing of product- and process-related information through the entire development cycle (Trapp 1991; Karinthi et al., 1992). To facilitate the concurrent engineering processes, tools are available to help manage product delivery activities and track products from conception to retirement and, at the same time, support effective communication and information sharing among
*Corresponding author. Tel.: 886-6-2757575 ext. 63922; fax: 886-62085334; e-mail: [email protected]. 0736-5845/98/$19.00 ( 1998 Elsevier Science Ltd. All rights reserved. PII: S0736-5845(98)00013-1
functional groups and individuals of a development team (Bradley and Agogino 1991; Wong and Sriram 1993). These tools are known as product data management (PDM) and engineering data management (EDM) (Miller, E. 1993; Stover, 1993; McIntosh, 1995; Chen and Hsiao, 1997). Most of the commercially available engineering data management systems have the following key elements in common (Miller et al., 1992; McIntosh, 1995): workflow and process management, project management, configuration management, design release management, product structure management, and configuration management (McIntosh, 1995). Although engineering data management is known by many different names, all of them share the same idea of providing a structured way to orderly and efficiently store, integrate, manage and control both data and engineering process from design, manufacturing to distribution. EDM is considered an ‘‘unifying’’ technology rather than a ‘‘point’’-type solution such as CAD or CFD (McIntosh, 1995). The implementation of EDM depends heavily on the characteristics of engineering process and involves the technologies of management, engineering,
276
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
and information. As no two organizations are the same, they must customize the processes and functions to fit their specific needs and circumstances (Miller et al., 1992; McIntosh, 1995). However, as there are no commonly acceptable approach and methodologies for implementing EDM, its implementation becomes a bottleneck. The objective of this research is to develop a structured methodology for implementation of EDM through applying and unifying the principles, methodology, and technology of concurrent engineering, system engineering, and EDM. The objective can be attained by developing the method and procedure for (1) engineering process analysis, modeling, and reengineering, (2) system design, modeling and realization, and (3) their integration. Developing this methodology involves: (1) domain investigation, (2) methodology study, (3) methodology development and integration, and (4) application examination. Domain investigation characterizes the engineering process and requirements for supporting engineering process from the data management point of view, as well as the functionality of EDM systems. Methodology study reviews related methodologies for process modeling, process reengineering, information modeling, and data modeling. etc. Based on the results of domain investigation and methodology study, an approach for implementing engineering data management is developed and then examined in a real-world case.
2. Overview of the proposed methodology This section presents the overview of the proposed methodology for implementing EDM. The methodology includes the phases of business and process analysis, system design and modeling, and system realization as shown in Fig. 1. The goal of business analysis is to learn the business vision, organizational structure, and functions of business units so as to guide the re-engineering process in meeting the corporate mission. Similarly, the objective of process analysis and modeling is to identify the motivation and goals for implementing EDM and to fully understand the characteristics of the engineering processes, thus facilitating process re-engineering. The result of process analysis and modeling is an as-is process model that can be used for reengineering. An actor-based integrated process model (AIM), which consists of an information flow model, an activity model, and a functional model, is devised to properly and efficiently model the engineering process. Process re-engineering is performed by employing principles of concurrent engineering as well as information technology based on the as-is model. The aims of process re-engineering are to make the process more efficient and effective, and eventually meet the process
Fig. 1. Steps of the proposed methodology.
goals. The result of process reengineering is a to-be process model. The phases of system design and modeling include the tasks of requirement analysis, system planning. The requirement analysis defines what the desired system must do; system planning defines how it will be done; system design makes high-level decisions about the overall framework; and system modeling focuses on the description of the structures and behaviors of the elements of the software system and their relationships. Based on the to-be process model, requirement analysis and planning of engineering data management system is performed. It includes software functional requirement analysis, hardware configuration requirement analysis and administrative requirement analysis. According to the requirements, the system planning is conducted to outline the software system framework, hardware system capacity and configuration, and administration organization for EDM. The software system framework that depicts the system functions and their relationships from the user perspective is used for user interface design by decomposing system functions. Before performing system modeling, the elements of the EDM system should be identified on the basis of the engineering process model obtained in the business and process analysis phase. To obtain the characteristics and behavior of the elements, an information object diagram,
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
277
an information life cycle model, an information state transition diagram and an activity object diagram are developed based on the process model. The system modeling aims to build a design model based on the analysis model, but containing implementation details. The details are added to the design model in accordance with the strategy established during system design. In the proposed methodology, an object-oriented modeling technique is employed to define the structures and behaviors of the elements in the system as well as the relationships among the elements in terms of objects. The result of system modeling is a set of object classes that correspond to the elements in the system. The phase of system realization includes the tasks of development approach selection, system implementation, integration and testing. The determination of a system implementation alternative is made on the basis of budget, technical ability and resources. Once the approach is determined, the system implementation can be done by building underlying database systems and coding the object classes defined in the system modeling stage.
3. Business and process analysis This section presents the methods for business analysis, process analysis, process modeling, and process re-engineering. 3.1. Business analysis Business analysis includes the tasks of the initial analysis, preliminary planning, and detailed business analysis. The goal of the initial business analysis is to understand the current situation and characteristics of the enterprise, and the requirements and expectations on the implementation of EDM so as to prepare a proposal for implementing EDM. The initial business analysis is conducted by interviewing the corporate high-level management team or the engineering department head. The result of business analysis is an organizational structure with functional or responsibility description of each functional unit in the structure, and/or flow charts of engineering processes. Based on the findings in the initial business analysis, a proposal for implementing EDM is prepared through negotiating and discussing with the enterprise management team. The proposal should contains the enterprise background, problems encountered, objective and requirements, current methods for EDM and related facility, system plan, budget, steps of the tasks, schedule, and outputs. Accompanied with the proposal is a project plan that contains project objectives, project organization and responsibility, project tasks description, schedule, and outputs.
Fig. 2. Steps of detailed business analysis.
The implementation of EDM actually starts with the detailed business analysis. The goal of detailed business analysis is to characterize the work details of business activities to facilitate the analysis and modeling of engineering processes. As shown in Fig. 2, the analysis begins with an organizational functional analysis if the processes to implement EDM are not clear. The result of organizational functional analysis is an enterprise or engineering department organization chart with the individual actors at the bottom layer. The works of each individual actor in the organizational structure are identified and described in a work analysis sheet (e.g. work analysis sheet A). Work sheet A contains information of the activities performed by the actor, including suppliers of each work and their supporting inputs, consumers of each activity and the outputs to them, and the usage of the information. Process flows can be identified by connecting the inputs and outputs into and from the activity. The processes are then prioritized for re-engineering.
278
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
Fig. 3. Work step diagram.
The process activity analysis is conducted on the activities of the target processes. The details of each activity is described in another work analysis sheet (e.g. work analysis sheet B) and a work step diagram. Work analysis sheet B contains information such as work title, relevant processes, tools used, application software used, servers and their supporting inputs, consumers and the outputs to them, the usage of the information, importance rating and media of the inputs and outputs, the major and minor functions of the work and their importance ratings, the type of the work (i.e. procedural or non-procedural), reference or supporting information and media, and other person involved. The work step defines the procedural details of the activity by using the notations of data flow diagram (Page-Jones, 1988). Figure 3 shows an example of work step diagram. 3.2. Process analysis and modeling According to the results of business analysis, the process models of the target processes can be built using a proposed process modeling technique as, described. 3.2.1. Process model Modeling an engineering process represents the characteristics, behavior, and relationships element in the process. According to the business analysis in the previous section, an engineering process can be seen as a complex dynamic system consisting of concurrent and/or cooperative processes, where each process is a flow of activities that are triggered by some real-world events and performed by people from various organizational units using tools to process engineering items. From the EDM aspect, the elements in engineering processes can be classified as the items to be processed and the functions to process these items. They are represented in an object diagram using Rumbaugh’s notation
(Rumbaugh 1992) as shown in Fig. 4, where rectangular boxes denote classes of elements. An association is drawn as a line between classes, with which a verb in a problem statement is attached. Aggregation is drawn like association, except a small diamond indicates the assembly end of the relationships. The generalization is indicated by a triangle connecting a superclass to its subclasses. The proposed process model, which consists of a set of activity models, an information flow model, and an activity functional model is developed based on the results of business analysis. The relationships between the business analysis results and the process model is illustrated in Fig. 5. 3.2.2. Activity diagrams An activity is a set of elementary ordered or nonordered operations executed to realize the goals of the activity. The graphical representation of activities is shown in Fig. 6, which makes use of a box with four legs — ICOR. The ‘I’ stands for the input information to the activity, which is provided by suppliers, the ‘C’ represents the coordination information or shared information between collaborative activities through activity interactions, the ‘O’ is the output information to the consumers, and the ‘R’ denotes the reference information that can be queried from reference information resources. 3.2.3. Activity model An activity model that defines the work flow of an activity is the micro view of the activity. It consists of a series of operations, decisions, data (inputs, outputs, reference, coordination), and messages. Figure 7 gives an example of the activity model. The notation of the activity model is shown in Fig. 8. In-process information is the input, output or coordination information of an activity, which is the trigger of the activity. Examples of in-process information are order
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
279
Fig. 4. Elements in an engineering process and their relationships.
Fig. 5. Relationships between business analysis results and process model.
forms, product models, and text files. The information folder represents an aggregation of a set of in-process information. Instead of triggering an activity, reference information is static data referenced while performing an activity. An example of reference information is machine and tool data referenced for process planning. Information sequence, which indicates the number of steps that the information has been operated on, is shown in the upper-right corner of an in-process information symbol. The information number indicates the number of duplications of information. Similar to in-process information, messages appear in the locations of input, output, and communication; however, they do not have fixed formats and donot need to be stored in an ordinary database. Actions are operations performed to complete an activity. Decisions are made to choose one of two options; while routings are made to determine a series of options. Delivery indicates the location for information distribution. An output information without a delivery symbol shows that the information is stored for reference rather than distributed to other activities. A terminator represents a workflow is started or terminated without a trig-
Fig. 6. Activity diagram.
Fig. 7. Activity model.
gering in-process information. A ‘‘connection’’ connects two connective activities. 3.2.4. Information flow model An information flow model defining the flow of information along the flow of activities can be developed
280
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
Fig. 8. Activity model notation.
view of information processing, for example ‘‘create’’, ‘‘edit’’, ‘‘store’’, and ‘‘distribute’’ an order form. Actor and location indicate who and where to perform an activity are also indicated. 3.2.6. Integrated process model The information flow model, activity functional model, and activity model together form a process model that represents the integrated aspect of the models. The relationships between these models is illustrated in Fig. 10. Fig. 9. The information flow model.
3.3. Process re-engineering by connecting the inputs, outputs and coordination of the activity diagrams. Figure 9 shows an example of information flow model. 3.2.5. Activity functional model To further define the functional aspect of activities, the functional model of activities is developed as an ‘‘activity functional model’’. The activity functional model defines mechanisms for coordination, activity-specific tools, actor, location, and operational functions of an activity. The coordination mechanisms are the functions for supporting process coordination and communication. Activity-specific tools are tools used to perform an activity. Examples of activity-specific tools are CAD, CAE and project management systems. An activity functional model also represents three operational functions of an activity. They are (1) the function of the activity itself, such as product design or process planning, (2) the operations performed on information in the activity, for example ‘‘produce’’ a product model, and (3) the micro-
The goal of process re-engineering is to rationalize and concurrentize the engineering process so as to reduce excessive delay or costs. It consists of the tasks of process goal identification, problem identification and resolution, process rationalization and concurrentization, and validation (Fig. 11). The first step of process re-engineering is to clarify the goals of the process and make sure that the goals meet the corporate mission and strategy. A strategy analysis is then performed to develop the strategy and methods for achieving the process goals. Similarly, the strategy for achieving process goals should also meet the corporate strategy. A cause-effect diagram as shown in Fig. 12 is used for strategy analysis. Problem identification and resolution aim to identify the problems of the process and analyze the causes of each problem. The resolutions, each of which may consist of one or several methods, are then developed to resolve the problem. Cause-effect diagrams are also used in the analysis (Fig. 13).
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
281
Fig. 10. The integrated process model.
Fig. 11. Steps of process re-engineering.
The objective of process rationalization is to ensure that each activity in the engineering process contributes to the process goals. Value analysis is conducted on each activity by
z identifying the reason for the existence of the activity, z clarifying the importance of the output of the activity to its consumer(s), z checking if this activity can eliminated or replaced.
z identifying the function of the activity, z clarifying if the function helps achieve process goals,
The other principles of process rationalization include: shortening the duration of activities, eliminating
282
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
Fig. 12. Cause-effect diagram for goal identification and strategy analysis.
redundant activities, discarding non-value-added activities, partitioning a complicated activity into simpler and more controllable subactivities, combining two series and closely related activities, and eliminating cycles (Kusiak, et al., 1994). Process concurrentization is conducted by analyzing the relationships between activities based on the input, output, and coordination information of activities. The relationships between activities can be classified as either sequential, concurrent or collaborative. The sequential
relationship between activities defines a strict ordering relation between two activities, where one activity should be fully executed before the other can be executed. Activities with concurrent relationships are both the successors of a certain activity and have no interaction between each other. They can be therefore performed concurrently. Activities with collaborative relationships should be performed cooperatively or collaboratively through information and knowledge sharing as a result of their strong interactions. Validation is to check if the to-be process is acceptable and better than the as-is process. Theoretically, process simulation and evaluation should be performed based on the parameters of quality, cost and time. However, since most of the engineering activities are non-procedural and their quality, cost, and time consumed are highly dependent on the product complexities and actors’ experiences, development of the evaluation model and determination of the values of the parameters are still research issues (Aldowaisan and Gaafar, 1997). Since this research does not intent to resolve these issues, validation at this stage is done by simply comparing the number of the activities in the to-be and as-is processes and the number of steps in each of their activities.
4. System development The business and process analysis discussed in the previous sections helps promote an understanding of the real-world engineering process and data management,
Fig. 13. Cause-effect diagram for problem identification and resolution analysis.
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
thus providing a practical basis for system development and implementation. The output of the process re-engineering is a to-be process model. According to the to-be process model, the analysis, design and modeling of the EDM system can be performed. This section presents an approach for system development that fully integrates the process model developed in the business and process analysis and modeling phase. 4.1. Functional requirement analysis The functions for EDM can be classified into processwide functions such as work flow management and team library management and activity-specific functions such as message passing and assignment. The activity-specific functions can be identified from the workflow of the activity models. Some of these functions are commonly used in most of the activities and some others can be further decomposed into lower-level functions, both of which can be generalized as generic functions for system implementation. As the example in Fig. 14 shows, the functions for information processing include information receiving, information distribution, library access, and database query, which are functions that can be generalized as generic functions for information processing. 4.2. System planning and design Based on the results of requirement analysis, the planning and design of the EDM system is performed. The system planning outlines the software system framework, hardware system capacity and configuration, and administration organization for engineering data management, while system design specifies the details based on the outlines.
283
The software system framework defines the system functions and their relationships from the user perspective by grouping and decomposing the required functions identified in the previous stage. The result of software system framework design is a system functional decomposition structure that can be used for user interface design. The system configuration defines the structure of the computer systems in accordance with the system functionality and the locations of the actors performing activities. 4.3. System modeling 4.3.1. System modeling overview System modeling builds a set of object classes that correspond to classes of elements in the domain of EDM. The proposed system modeling methodology uses four kinds of models to describe an EDM system: an object model, a dynamic model, a functional model, and a data model. The object model, dynamic model, and functional model are similar to those in Rumbaugh’s object modeling technique (OMT) (Rumbaugh, 1992). The object model defines the static, structural, and data aspects of the framework in terms of objects and relationships that correspond to elements in the domain of EDM. The dynamic model defines the temporal, behavioral, and control aspects of the framework in terms of event and states of these elements. The functional model defines the transformational and functional aspects of the framework values and functions. Data modeling, in the proposed methodology, converts the object-oriented information model into relational data base schema for implementation of data bases. System modeling starts with the identification of the elements in the EDM system based on the process model
Fig. 14. An example of functional requirement identification.
284
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
obtained in the phase of business and process analysis. Object modeling is then conducted by classifying the elements and specifying their relationships using classification, generalization and association techniques. The results of object modeling are an activity object diagram, an information object diagram and an actor object diagram, that define the object classes in the system and their relationships. Dynamic modeling includes the tasks of event identification, state transition diagram development, information life cycle modeling, and information relationship modeling. The events are identified from the activity model of the process model. They are then used to define the state transition diagram of each object class. In order to help the control of workflow and engineering process, as well as the distribution of information, an information life cycle model is developed based on the information flow model in the process model. Similarly, an information relationship model is derived to define the relationships between information items so as to facilitate the tracking of related information and maintenance of their associativity. Functional modeling specifies the procedural details of the methods in the object classes. Data modeling converts the object-oriented information model into entityrelationship models for the development of relational databases. 4.3.2. Object modeling According to the process model, the key elements in engineering processes include the process itself, activities, actors, tools, organization, and information items (see also Fig. 4). Since tools can be defined as the attributes of activities or actors and the organization can be treated as
the attribute of actors, the object diagram of the elements can be reduced as shown in Fig. 15. A process is the aggregation of activities; activities are performed by one or more than one actors; a person can perform one or more than one activity; information items are associated with activities as inputs, outputs or for reference; the information items as well as activities have relationships among one another. (1) Information object diagram: Information involved in the engineering process can be identified from the input, output, coordination and reference of activity diagram of process model. They can be classified as product and process data, business process data, activity reference data, posted information and on-line communication information (Fig. 16). Product and process data are basically the outputs of the process activities, such as product models, mold models, process plans, assembly plans, and engineering drawings. One hand of business process data are those that flow along the engineering process and drive the process. Typical examples of business process data are business forms such as order forms, work orders and request for proposals. The business process data also include information related to process status. Activity reference data are those that are referenced for performing an activity. Examples of reference data are material data, machinability data, company historical data, project documents, and operation standards. Posted information is basically public information that is posted in public domain and available to the public, such as new product lines, process status and work results. On-line communication information are knowledge shared during activity interactions. They are transmitted in forms of mails, talks and discussions.
Fig. 15. Object diagram.
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
285
Fig. 16. Information object diagram.
Fig. 17. Activity object diagram.
The relationships between information items can be classified as the relationships between information items and the relationships between versions of an information item. The examples of the former include attach/ attached—by, depends—on/depended—on—by, and contains/ is—in, while the examples of the latter are is—superseded— by/is—revised—as, is—checked—out—as/ is—checked—out—of, and is—copy—of/is—copied—as. (2) Activity object diagram: Activities involved in the engineering process can be identified from the activity models of the process model. They can be classified as the ones along the flow of engineering process and the others related to the engineering process. The former, which can be obtained from the information flow model, are referred to as workflow activities, such as assembly layout, preliminary design, detail design and mold design; the latter are seen as supporting activities, such as process
control, project management, system administration, and configuration (Fig. 17). (3) Actor object diagram: Actors involved in the engineering process can be identified from the functional model of the process model. The characteristics of an actor, such as the role an actor plays, the location, accessibility to engineering data and tools of an actor, can be defined as the attributes of the actor object class. Therefore, there is no need to further classify the actors. The actors can be defined in terms of one actor object class. 4.3.3. Dynamic modeling Object modeling examines the static structure of the constructs in EDM by identifying the structure of the objects in it and their relationships. Dynamic modeling describes changes to the objects and their relationships over time. The main construct of dynamic modeling is
286
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
control information, including the sequence of events, states, and operations that occur within a system of objects. (1) Events and states: The object model presented in the previous section described the possible patterns of objects and links that can exist in the EDM system. The attribute values and links of an object at a single moment in time are called its ‘‘state.’’ Over time, the user may perform operations or the objects may stimulate each other, which results in a series of changes in their states. An individual stimulus from outside the system (i.e. the user performs operations) is called an ‘‘external event’’, while an ‘‘internal event’’ occurs if it is from one object to another. The response to an event depends on the state of the object receiving it and can include a change of state or the sending of another event to the original sender or to a third object. External events to the system occur when activity actors perform operations on the system. Therefore, they can be identified from the activity model or functional model of the process model. The internal events occur during the interactions among the objects as well as changes of object states. The former can be obtained from the object relationships specified in an object diagram, while the latter can be identified through the development of the state transition diagrams of object classes. Information object diagrams define the information object classes and their relationships. (2) State diagrams: A state diagram describes the behavior of a single class of objects. A state diagram is a graph whose nodes are states and whose directed arcs
are transitions labeled by event names. A state is drawn as a rounded box containing an optional name. A transition is drawn as an arrow from the receiving state to the target state; the label on the arrow is the name of the event causing the transition. All the transitions leaving a state must correspond to different events. Figure 18 gives an example of a state diagram. After it is created, a product item can reside in a workbench or bin of the work area of an activity or in a team library. It may be associated with a product structure or exist individually before being added to a product structure or removed from a product structure. The item can be sent to or received from another activity work area. (3) Information life cycle model: The information life cycle model of an information item denotes the transition of the information item along the engineering process and repository. It is derived from the information flow model of the process model. The information life cycle model can facilitate the control, tracking and distribution of information items, as well as the control of work flow, especially for the form type of information items. Figure 19 shows the generic representation of information life cycle models, where the rounded block represents the activities; the arrow represents the flow of the information items; and the information items can reside in the work area of an activity (i.e. temporary storage) or in a team library (i.e. permanent storage). 4.3.4. Object class development An object class is defined in terms of class name, attributes, and methods. One of the purposes of the
Fig. 18. The state diagram of product item object class: an example.
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
287
Fig. 19. The generic representation of information life cycle model.
Fig. 20. Operation and information accessibility matrix.
modeling discussed previously is to help obtain the object classes, their attributes and methods to completely define them. This section presents how to obtain the attributes and methods from the process model, object models and dynamic models. (1) Actor object class: The actor object class defines the role and information accessibility of actors, as well as the activities performed by the actors. The information accessibility and operations can be specified in an accessibility matrix derived from functional model as shown in Fig. 20.
(2) Information object class: As shown in Fig. 21, the information flow model denotes the information items, information relationships and information classification. The information object diagram, which is developed based on the information flow model, can be used to define the information class hierarchy, the type of each class, and the relationship between classes as attributes. Through the information flow model and functional model, the information life cycle model contributes the attributes of owner, status and location to the information object class. The events carried in the information
288
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
Fig. 21. The transformation from process model to information object class.
Fig. 22. The transformation from the process model to the activity object class.
state transition diagram denote the methods for transmitting the information items. The functions defined in the functional model can be used directly as the methods for manipulating the information items. (3) Activity object class: The attributes and methods of each activity object class are identified from the activity model, activity diagram, information flow model, functional model and activity state diagram, as shown in Fig. 22. From the activity model, the methods for manipulating information items by the activity can be identified; the activity diagram denotes the information items related to the activity; the functions defined in the functional model can be directly employed as the methods for manipulating information items; the functional model also provides actor and location as the attributes; and the events specified in activity state diagrams are also treated as the methods.
4.3.5. Functional modeling Functional models are employed to specify the meaning of operations and constraints in the object model and actions in the dynamic models. They consist of multiple data flow diagrams (DFDs), which specify the meaning of operations, constraints and actions. A DFD shows the functional relationships of the values computed by a system, including input values, output values, and internal data structures. A DFD contains processes that transfer data, data flows that move data, actor objects that produce and consume data, and data store objects that store data passively. 4.3.6. Data modeling The relationships defined in the information relationship model are at the application or process level; however, it may be required to break down the information
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
items and their relationships into lower-level database schemes for the implementation of databases. A data modeling is therefore performed to convert the information relationship model into an E—R model. To model the data, information items are classified into ones for being stored in databases and the others for being stored in repositories. The former are basically business items such as tables and forms while the latter include product items such as documents, files and product models. Each class of the product items, which is defined in terms of a class name and its attributes, is modeled as an entity with the attributes. The relationships are inherited from the information relationship model. For modeling the business items, the following steps are taken (Rosemary, 1989): (1) Conversion to table form — Taking the box or column headings and laying them out in simple table form with the headings across the top of the page and the values below the headings in rows. Repeating blocks of values should be listed against the set of values for which they repeat. (2) Key identification — Finding a column heading that will uniquely identify a full row of values. Ideally, it should be just one heading. If we cannot get uniqueness using one we must combine two or more until a unique identifier is found. (3) Creating first normal form — Removing the repeating groups and creating a separate table for the repeating group and duplicating the key value in the new table. Choosing a key for the new table in the same way as the key is chosen for the original table. (4) Conversion to second normal form — Looking at the keys that have been formed from a combination of column headings. Taking each part of the key in turn, looking through the non-key items and seeing if any items look like they depend on the part key rather than the whole key. (5) Conversion to third normal form — If any non-key item is dependent on another non-key item, remove the dependent group of items from the table and create a new table with the item it. (6) Conversion to data model — Convert the tables to data model.
289
5. System realization System realization is to convert the system models developed in the previous stage into software codes and finally become an EDM system. This phase includes the tasks of development approach selection, system implementation, integration and testing. 5.1. Determination of system development approach The determination of a system development approach is indeed the selection of software components for system implementation. The system can be developed in a highlevel engineering data management system shell such as MetaPhaseTM, a tool kit such as Lotus NotesTM, or using lower-level language such as C##, depending on the budget, resources, technical ability of the enterprise. In this paper, we focus the discussion on the aspect of technical ability. Figure 23 illustrates the decision flow for the determination of system development approach. It begins with the collection of system functions identified from the process model and a listing all candidate shells, tool kits
In practice, we should merge the data models from all resources into one composite data model by: 1. Merging entities that have the same name together. 2. Merging relationships that have the same name together, otherwise keep separate on the model. 3. Merging attributes that have common names, if the attributes have conflicting. 4. Refining the data model by removing synonyms, checking for attribute duplication, generalizing entities and relationships, removing redundancy, and resolving many to many relationships.
Fig. 23. Decision loop for development approach determination.
290
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
and languages for assessment. Each of the functions will be checked to see if it is a standard PDM or EDM function. If it is, the score of the shell or kit that provides this function is increased one; if it is not, the determination will be made further to see if there exists stand-alone software that can provide this function. The assessment of the software is conducted if the answer is yes. The assessment is made on the possibility for developing this function by employing the application interface functions (API) of the shell or kit if there is no existing software supporting this function. If it too difficult or impossible to develop the function by using the API of shells or kits, the selection of software languages for implementing this function is required. The loop continues until all functions are covered. Theoretically, the shell, kit or language with the highest score will be used for developing this system. 5.2. Implementation The implementation of an EDM system includes building underlying database systems and coding system object classes. The former requires defining relational tables based on the relational data schema developed in the data modeling stage and entering enterprise data into the tables. The latter varies with the tools employed for implementation; however, they all share the idea of system object construction.
6. Application example The applicability and feasibility of this methodology have been examined by conducting case studies at Metal Industries Research and Development Center (MIRDC), Mechanical Industry Research Laboratories of Industrial Technology Research Institute (MIRL-ITRI), and the Computer-Aided Concurrent Engineering Research Lab of the Institute of Manufacturing Engineering, National Cheng Kung University in Taiwan. The systems of these three cases were developed on a tool kit — Lotus NotesTM, an engineering data management shell — MetaPhaseTM, and C##, respectively. Here, we take the case of MIRDC as an example. 6.1. Process analysis and reengineering 6.1.1. Information flow model Figure 24 shows the information flow model of mold development. The actors involved in the process include R&D manager, design engineer, analysis engineer, process planning engineer, and production engineer. The R&D manager uses the draft plan of work orders as input and project files to perform project management. He distributes the work orders to all actors involved in the process and transmits the work notification and cost estimation to the mold design engineer. The mold designer uses the material database, standard mold design
Fig. 24. Information flow model of model development.
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
291
Fig. 25. Functional model of model development.
Fig. 26. Activity model of model development.
operation plan (SOP), and technical manual for reference when designing the mold. He produces the mold structure, mold assembly drawing, and mold component drawings. The mold structure is transmitted to the
analysis engineer for structural analysis, and the mold component drawings are transmitted to the process planner for process planning. The outputs from the process planning include a process plan and material
292
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
Fig. 27. System framework.
Fig. 28. System configuration.
requirement plan, which are transmitted to the production manager for production tryout. 6.1.2. Functional model Figure 25 shows the functional model of model development. The R&D manager is responsible for project management and process control; the design engineer
conducts structural design and component design; the analysis engineer performs structural analysis; the process planning engineer is responsible for mold manufacturing process planning and material requirement analysis; the production manager plays the role for production tryout. All the actors can work collaboratively through a mold development collaboration support
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
293
Fig. 29. Information object diagram.
system. The customer may communicate with the development team for process status through the collaboration system. 6.1.3. Activity model Figure 26 is the activity model of the design engineer for the mold development process. The main tasks of this activity include mold structure design and drawings, mold component design and drawing, mold assembly design and drawing, and mold component or assembly redesign. The inputs to the activity are work order, previous work completion notification, cost estimation information, and project information. The result of mold structure design will be distributed to the analysis engineer and the results of mold component design or redesign will be transmitted to the mold manufacturing process planner. The reference information used in this activity includes project files, raw material information, standard component information, fixture data, standard operation plan for mold design and other technical documents.
The system is configured as shown in Fig. 28. Application systems such as MIS, CAPP, CAD/CAM/CAE, and MRP are connected to the system via an application system interface. Information items produced by the application systems and the CACESS itself are stored in a relational database or a common repository, depending on the types of information. Both the database and repository are managed by an information management module. The engineering processes are classified into two major processes: molding product development and non-molding product development. Each of them consists of several inter-related processes and projects and are managed by a process control and project management module. 6.2.2. Object diagram The information items in the case are grouped into files such as machine data file, cost estimation file, mold development file, project information file, supplier information file, material data file, product model file, and standard operation plan document file. Each of them is further classified, as shown in Fig. 29.
6.2. System design and modeling 6.2.1. System framework and configuration According to the process model, a concurrent engineering support system (CACESS) was designed for MIRDC. This system consists of the modules of project management, process control, information management and system administration. Each of the modules provides functions as shown in Fig. 27.
6.2.3. Object models The object classes are developed according to objectoriented modeling. Some of the classes are shown in Fig. 30. 6.3. System implementation Based on the results of system design and modeling, a prototype engineering data management system
294
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
Fig. 30. Part of the information object classes.
Fig. 31. Interface for process control.
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
295
Fig. 32. Interface for process status viewing.
(Computer-Aided Concurrent Engineering Support System — CACESS) has been implemented in an environment equipped with an Acer Altos 9000 PCTM server and an Acer Power 590h PCTM workstation networked with six PC clients under Windows-NTTM. The software components employed in the implementation of this system include Lotus NotesTM 4.5 (Domino), MS ProjectTM, MS WordTM, and AutoCADTM. All of them support OLE functionality. The Lotus Notes 4.5 (Domino) is used as the core software component and also plays the roles of database server, Internet server and mail server. Figure 31 shows the user interface for the setup of the process for information item distribution and control. The project manager can define the activities and their sequence, as well as the flow of information through the interface, and view the process status via the interface shown in Fig. 32. 7. Conclusion and discussion This paper presents a structured methodology for the implementation of EDM. It supports integrated models and methods for analysis and modeling from business and process analysis at the organizational level through system design and modeling at system level to system implementation at an engineering level. The applicability and feasibility of this methodology have been examined by conducting a case study at Metal Industries Research and Development Center and Mechanical Industry Research Laboratories of Industrial Technology Research Institute in Taiwan.
The characteristics of this approach include: z it provides a tight link from business, organization and process to detailed system design and implementation description at an engineering level, which makes process analysis and reengineering more practical and useful, z it satisfies the principle of separation of concern, separation of functionality, and behavior (Vernadat, 1996), z it emphasizes the interactions and concurrence between activities to reflect the nature of concurrent engineering processes, and z it is simple and easy to understand. However, there are still some limitations that need further research to resolve: z it produces a static or paper model that is not computer-processable and is therefore of limited value to support management of change, z lack of the ability to analyze certain quantitative properties such as process performance evaluation and cycle times. To provide the capability, introduction of the time, cost and quality parameters into the models may be required.
Acknowledgements This work was supported by National Science Council, Taiwan, ROC under Grant No: NSC 86-2212E-006-034.
296
Y.-M. Chen, T.-H. Tsao / Robotics and Computer-Integrated Manufacturing 14 (1998) 275–296
References Aldowaisan, T.A., Gaafar., L.K., A framework for developing technical process reengineering designs, Comput. Ind. Eng. 1997; 32 (3) 657—70. Bradley, S.R., Agogino, A.M., Design Capture and Information Management for Concurrent Design Addison-Wesley, New York, 1991. Chen, Y.M., Miller, R., Dik Lun, L., Object-oriented part model for geometric reasoning. J. Integrated Computer-Aided Eng. 1994; 1 (5), 375—95. Chen, Y.M., Hsiao. Y.T., A collaborative data management framework for concurrent team-oriented product and process development. Int. J. Comput. Integrated Manufar. 1997; 10 (6), 446—469. Miller, E., MacKrell, J., Johnson, R., Amman, K., PDM Buyer guide. Ann Arbor, CIMdata, Michigan, 1992. Clausing, D., Total Quality Development: A Step-by-Step Guide to World Class Concurrent Engineering. ASME Press, New York, 1994. Cleetus, K.J., Modeling evolving product data for concurrent engineering. CERC Technical Report. CERC-TR-RN-92-016. West Virginia University, Concurrent Engineering Research Center, 1992. Curtis, B., Lellner, M., Over, J., Process Modeling. Commun. ACM 1992; 35 (9) 75—90. Davis, T.A., Trapp, G., Advancing concurrent engineering using step. CERC Technical Report, CERC-TR-RN-91-012. West Virginia University, Concurrent Engineering Research Center, 1991. Karinthi, R., Jaganna, V., Montan, V., Petro, J., Raman, R., Trapp, G., Promoting concurrent engineering through information sharing. Proc. ASME Winter Annual Meeting, Anaheim, California, 1992; 8—13 November 1992.
Kusiak, L., Nick, T., Wang, J., Reengineering of design and manufacturing process. Comput. Ind. Eng. 1994; 26 (3) 521—36. McIntosh, G., Engineering Data Management: A Guide to Successful Implementation. McGraw-Hill Book Company, New York, 1995. Miller, E., Managing engineering data: an inside look at PDM. Computer-Aided Eng. July, SR1—SR8, 1993. Miller, L.C.G., Concurrent Engineering Design. Society of Manufacturing Engineers, Dearborn, Michigan, 1993. Mills, R., Beckert, B., Carrabine, L., The future of product development. Computer Aided Eng. 1991; 10, 38—46. Nagy, R.L., Ullman, D.G., Dietterich, T.G., A data representation for collaborative mechanical design. Res. Eng. Des. 1992; 233—42. Meilir, P., The Practical Guide to Structured Systems Design. Yourdon Press, NJ, 1988. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W., Object-Oriented Modeling and Design. Prentice-Hall, NJ, 1992. Rosemary, R., An introduction to data and activity analysis. QED Information Sciences, 1989. Stover, R.N., EDM as an enabling technology. special report/ engineering document management. Comput Aided Eng. August, EDM1—EDM16, 1993. Trapp, G. Sharing Information: a CALS/CITIS, Concurrent Engineering and PDES/STEP Synergy. CERC Technical Report, CERCTR-TM-91-011. West Virginia University: Concurrent Engineering Research Center, 1991. Wong, A., Sriram, D., SHARED: An information model for cooperative product development. Res. Eng. Des. 1993; 5, 21—39.