SIMTech Technical Report () IDEF* - A comprehensive Modelling Methodology for the Development of Manufacturing Dr Ang Cheng Leong (Operations & Supply Chain Applications Group, Manufacturing Information Technology Division, 2000)
1 BACKGROUND Models are descriptions of systems. To completely describe a manufacturing enterprise system, several models of the manufacturing system are usually created, each from a different viewpoint. According to CIMOSA (CIM Open System Architecture) reference architecture (AMICE 93), manufacturing enterprise systems can be viewed from at least four complementary viewpoints: function, information, resource, and organisation. Unfortunately, in practice, models from each viewpoint are built independently using different methodologies and in different environments. However, a methodology tailored to a particular viewpoint may be incompatible with another. This traditional approach thus poses the following problems (Wang et al 1993; Kim 1996): describe the structure and components of the software tool. The methodology is termed IDEF* because it is an enhancement of the IDEF (ICAM DEFinition language) methodology developed by the US Air Force s ICAM (Integrated Computer-Aided Manufacturing) programme in the 80 s for CIM (Computer-Integrated Manufacturing) implementation. The IDEF methodology comprises IDEF0 (USAF 1981a), IDEF1 (USAF 1981b), IDEF2 (USAF 1981c), and IDEF3 (Mayer et al 1992) which are methodologies for functional, information, dynamic, and process modelling, respectively. There are two versions of IDEF1: IDEF1 (1981) (USAF 1981b) and IDEF1x (1986) (Bruce 1992, Loomis 1986). IDEF1 is used for requirements specification, while IDEF1x for the design of relational databases. (a) The whole modelling process involves repeated capturing of same information and is time-consuming. (b) It is very difficult to identify the effect of changes to one model on the others. (c) Incompatibility between the different but interrelated models. (d) Model maintenance is difficult because of (b). (e) Seamless transition in the systems development life cycle is difficult because of (c). (f) It is difficult for system users and system developers to communicate and work together. (g) Similarly, it is difficult for several system developers who have different purposes and backgrounds but who are working on the same system to communicate and work together. According to CIMOSA recommendations, a comprehensive modelling methodology termed IDEF* and a supporting software tool have been developed at Gintic to overcome these problems. The purpose of this paper is to explain the features and concept of the methodology, and to 2 OBJECTIVE To develop a methodology for integrated modelling of manufacturing enterprise systems and a supporting software tool, based on CIMOSA and IDEF0. 3 METHODOLOGY The main features of the IDEF* methodology are that it is: CIMOSAcompliant, IDEF0-based and Integrated. 3.1 CIMOSA COMPLIANCE The IDEF* methodology conforms to the CIMOSA modelling framework (AMICE 1993) which is a diagrammatic representation of three modelling dimensions (figure 1). In one dimension, modelling is described as consisting of generic, partial, and particular layers. In another dimension, modelling has function, information, resource, and organisation views. Finally, in the third dimension, modelling is described as having requirements definition, design specification, and implementation description levels of development. The combination of each of these three Keywords: Enterprise modelling; IDEF0; IDEF1x; IDEF*; Integrated modelling; Automated generation of IDEF0 models, 1
dimensions results in 36 different modelling domains C x,y,z s (where x, z =1,3, and y =1,4), and many possible routes for enterprise systems development. The IDEF* methodology supports the following route which consists of four sections and is thought to be one of the shortest in terms of development effort. (i) C 2,1,1 C 3,1,1 C 3,1,2 C 3,1,3 (ii) C 3,1,2 C 3,2,2 C 3,2,3 (iii) C 3,1,2 C 3,3,2 C 3,3,3 (iv) C 3,1,2 C 3,4,2 C 3,4,3 The development route is based on: (a) the waterfall system development life cycle model, which is characterised by a formal sign-off for each phase before work commences on the next phase (Brumbaugh 1994, Tkach et al 1994); (b) the premise that the information system of a manufacturing enterprise as well as its resources and organisation must support its business processes (Vernadat 1996). Section (i) of the development route involves: (a) customising a partial function model into a particular function model at the requirement definition level; (b) extending the particular function model to enable both visual and computer analyses of the model at the design specification level; (c) further extending the particular function model to enable computer workflow execution at the implementation description level. Organisation Resource Information Y + Function C 3,4,2 Generic Partial Particular X C 3,3,2 + C 3,1,1 Requirements Definition C 2,1,1 C 3,1,1 C 3,,2,2 C 3,4,3 + C 3,3,3 Z Design C X,Y,Z C 3,1,2 C 3,1,2 Specification C 3,2,3 Implementation C 3,1,3 Description C 3,1,3 Figure 1: CIMOSA Modelling Framework 2
Section (ii) involves the derivation of a particular information model from the particular function model at the design specification level, and the design of relational databases at the implementation description level. Sections (iii) & (iv) involve extending the particular function model to include resource view and organisation view, respectively, at both the design specification level and the implementation description level. 3.2 IDEF0-BASED IDEF0 is chosen as the basis of the IDEF* methodology. In producing a complete system description, an IDEF0 model is first built and other details are then added progressively to the IDEF0 model so that: (a) functional description of the system can be achieved at any level of abstraction; (b) complete system description can be realised sequentially; (c) models compatibility can be maintained by using the same functions among the different models. Throughout the modelling process, the IDEF0 model is used as the basis for the collection of relevant details. This helps to ensure that models resulting from the process will be compatible with the IDEF0 model, and that only function-related details are collected. This is in contrast with the traditional approach as mentioned in the introduction section. Three main reasons for choosing IDEF0 as the basis of the IDEF* methodology are that: it is one of the few functional modelling methodologies that are popular with the industrial community (Feldmann 1998); it is superior to many other functional modelling methodologies in terms of simple graphics, conciseness, rigor and precision, consistent methodology, levels of abstraction, and separation of organisation from function (Hunt 1996, Mandel 1990); it is a de facto international standard and a US Federal Information Processing standard (FIPS 1993) for functional modelling. 3.3 INTEGRATION IDEF* is integrated in the sense that it can achieve four kinds of modelling integration. The first two kinds of integration are achieved through an integrated modelling approach in which the different modelling processes share the same common information on the functionality of the enterprise system being modelled. The approach will not only help to ensure compatibility between the function model and the other models, but will also help to reduce the time and effort needed to build and maintain them. It will also allow system users and system developers to work together more easily than when using models that are built independently (Kim 1996). The third kind involves the use of a knowledge-based system to semiautomate the generation of IDEF0 models based on the concept of reference models (Ang et al 1997). The knowledge-based system approach helps to reduce modelling time and effort, and eliminate model inconsistency (Luo 1998). Finally, the last kind is achieved by extending the IDEF0 model to include other details, making it computerprocessable not only for workflow analysis (simulation) (Wang et al 1993), but also workflow execution (Ang 1998, Zukunft et al 1996, Johnson 1992). Such integration will help to reduce the time and effort of both system development and system maintenance. Any changes to system operations can now be effected simply by changing the relevant parts of the extended IDEF0 model which is much easier than changing directly the controller software. 3
4 RESULTS The IDEF* software tool developed comprises the following six components, which can be used either as standalone modules or together as an integrated software tool. They are integrated in the sense that output from the first component serves directly as input to the others. (a) A knowledge-based system for the semi-automated generation of IDEF0 models. (b) A software tool for the systematic derivation of the IDEF1x model from the IDEF0 model. (c) A software tool for the conversion of the integration of modeling views: function view with each of process, dynamics, information, resource, and organisation views; (d) integration of three modeling levels: requirements definition, design specification, and implementation description; (e) integration of three modeling layers: generic, partial, and particular; (f) integration of enterprise engineering and enterprise operation. (g) IDEF0 models to both the business process and the quality process models. (h) A software tool for the conversion of the IDEF0 model to the IDEF0-based IDEF2 dynamic model and its execution for systems simulation and control. (i) A software tool for the conversion of the IDEF0 model to the IDEF0-based resource model. (j) A software tool for the conversion of the IDEF0 model to the IDEF0-based organisation model. Details of the knowledge-based system are given by Ang et al (1997a), and Luo (1998). The system makes use of two expert systems: one to query the user for information on the company s characteristics and to automatically generate an IDEF0 partial model for the company; whereas the other to query the user based on the partial model generated for specific information on the company's activities and to automatically transform the partial model into a particular model (which is to be subject to validation). The second component supports the procedure mentioned in section 3.3 for the systematic derivation of the IDEF1x model from the IDEF0 model, and the generation of SQL scripts from the IDEF1x model for a number of well-known relational database systems like Oracle, DB2, and Informix. The other components are basically enhanced IDEF0 modelling tools. The third component is used to create the IDEF0-based process model, which is an integrated business and quality process model, directly from the IDEF0 model. The fourth component is used to transform the IDEF0 model into the IDEF0-based IDEF2 dynamic model. It also has a builtin intelligent simulator that can read and interpret the ASCII text file of the dynamic model, and operate in either simulation mode or control mode. In simulation mode, the simulator is used to simulate the dynamic model for workflow analysis, while in control mode, it is used to control the actual activities for workflow execution (Ang 1998). The last two components are used to create the IDEF0-based resource and organisation models. The IDEF* software tool was developed in Windows 95 environment using a number of commercial case tools. These include MetaDesign, Design/IDEF TM Version 3.5, and Design/OA TM of Meta Software Corporation (1992); Software Development Kit and Visual C++ of Microsoft Corporation (1993); Kappa-PC TM of IntelliCorp Inc. (1992). The software tool is expected to greatly enhance the effectiveness of IDEF* as it allows the entire process of enterprise systems design to be carried out in the same Design/IDEF TM environment. Figure 4
10 shows how the IDEF* software tool can be used to support the entire enterprise systems development life cycle. 5 CONCLUSION A comprehensive methodology termed IDEF* has been development for the modelling of manufacturing enterprise systems. The methodology, which incorporates such robust modelling methodologies as IDEF0, IDEF3(PFD), and IDEF1x, conforms to the CIMOSA modelling framework. It is comprehensive in the sense that it supports modelling from the four modelling views and at the three important development levels of CIMOSA. It is also integrated, meaning that it achieves four kinds of modelling integration as explained in the paper. Finally, it also satisfies eight important principles of good modelling methodologies. When supported by an appropriate software tool such as the one developed at Gintic, it is expected to drastically reduce the time and effort of enterprise systems development and maintenance. 6 INDUSTRIAL SIGNIFICANCE The IDEF* approach has the following advantages as compared to the conventional approach. a. Easy to understand. b. Complete system description can be realised sequentially and systematically. c. Models compatibility can be maintained by using the same functions among the different models. d. No repeated capturing of the same information on system functionality because of (c). e. No consistency checking is required because of (c). f. Efficient because of (d) & (e), and because complete system description can be accomplished in the same Design/IDEF TH environment. g. Ideal for CIM implementation or enterprise-wide integration because IDEF* is based on IDEF0. h. Conform to international standards 1 because IDEF* is CIMOSA-compliant and IDEF-based. i. Models are executable by computers for workflow simulation and workflow execution. j. System flexibility and hence system responsiveness can be greatly increased because of (i). IDEF* satisfies the eight important principles of good modelling methodologies proposed by Vernadat (1996). They are as follows. (a) Principle of separation of concerns: it is unrealistic to consider a manufacturing enterprise as a whole due to its inherent complexity. It must, therefore, be analysed piece by piece, each one corresponds to an existing functional area or domain. Thus, like CIMOSA, IDEF* views an enterprise as a collection of domains. A domain is a functional area achieving some goals of the enterprise and is made up of a collection of stand-alone core processes, called domain processes, and interact with other domains. (b) Principle of functional decomposition: in IDEF*, major functions are structured into sub-functions, subfunctions into sub-sub-functions, and so on in a stepwise-refinement approach as originally systematised in SADT (Ross 1977). (c) Principle of modularity: to facilitate model maintenance, IDEF0* models are modular in structure. In other words, the models are made of an assembly of compatible building blocks so that they can be built on a plug-and-play basis. Here, compatibility is ensured by means of the ICOM conventions (Ross 1977). (d) Principle of model genericity: although many activities or components of an enterprise are different, they often exhibit identical or similar properties. It is, therefore, important to define 5
standard building blocks as generic classes to factor common descriptive attributes and behaviours. In IDEF*, these generic classes are the various function objects and entity objects in the frame-based knowledge models that are built to facilitate the semiautomated generation of IDEF0 models (Luo 1998). (e) Principle of reusability: in IDEF*, partial models are reused and customised to particular models to reduce modelling time and effort. (f) Principle of process and resource decoupling: in IDEF*, the processes (i.e. things being done) and the resources (i.e. agents performing the processes) are decoupled in order to preserve operational flexibility. Each enterprise activity defined at the design specification stage is first decomposed into elementary processing steps, called functional operations. Executing agents or functional entities are then assigned to the functional operations. This is done by matching required functionalities of activities with functionalities offered by functional entities. (g) Principle of separation of behaviour and functionality: enterprise functionality concerns things to be done, while enterprise behaviour defines how things are done (AMICE 1993). The two should be separated if organisational flexibility has to be enforced. This will allow modification of one without impacting the other, and vice versa. In IDEF0*, the two are separated: functionality is first defined in terms of enterprise activities and functional operations during functional modelling, functional behaviour is then specified in terms of sequence of activities, behaviour rules, resource allocation, temporal rules, etc. (see section 3.2) during process modelling and dynamic modelling. (h) Principle of conformity: this principle deals with syntax and semantics of the model and concerns the ability of the model to accurately represent what it is supposed to model. Because IDEF* incorporates such well-proven and robust modelling methodologies as IDEF0, IDEF3(PFD), and IDEF1x, there are no questions of its ability to accurately describe the activities of a manufacturing system, their sequential relationships, and the information needed to support them. Also, important information on system behaviour, resource, and organisation can all be input directly into the IDEF0* model as textual descriptions. Thus IDEF* is as accurate as the modeler can be. REFERENCES 1. AMICE Consortium, 1993, CIMOSA Open Systems Architecture for CIM (Berlin: Springer Verlag). 2. Ang, C. L., Luo M., and Gay Robert K.L., 1997a, A Knowledge-Based Approach to the Generation of IDEF0 Models. International Journal of Production Research, 35. 3. Ang, C. L., Integrating IDEF1x with IDEF0, 1 st revision July 2000, International Journal of Production Research. 4. Ang, C. L., 1999, Enactment of IDEF0 Modes. International Journal of Production Research, to be published. 5. Bruce, T., 1992, Designing Quality Database with IDEF1x Information Models (New York: Dorset House Publishing). 6. Brumbaugh, D. E., 1994, Object-Oriented Development (Wiley). 7. Feldmann, C. G., 1998, The Practical Guide to Business Process Reengineering 8. Using IDEF0 (New York: Dorset House Publishing). 9. FIPS PUBS, 1993, Integration Definition for Function Modeling (IDEF0), Federal Information Processing Standards Publication 183, National Institute of Standards and Technology, USA. 10. Hunt, V. D., 1996, Process Mapping - How to Reengineer Your Business Processes (Wiley). 11. Johnson, E. M, 1992, An Integrated Simulation and Shopfloor Control System. Manufacturing Review, 5, (3). 12. Kim, J. I, 1996, Function, Information., Dynamics, and Organisation Integrated 13. Modelling Methodology for Enterprise Systems Integration. PhD Thesis, Arizona State University. 6
14. Loomis, M. E. S., 1986, Data Modeling - the IDEF1x Technique. Fifth Annual International Phoenix Conference on Computers and Communications, Scottsdale Arizona, IEEE. 15. Luo, M., 1998, A Knowledge-Based Approach to the Automated Generation of IDEF0 Models. PhD Thesis, Nanyang Technological University. 16. Mandel, K., 1990, Graphical Process Description - Views and Diagrams. International Journal of Computer Integrated Manufacturing Systems, 3, (5). 17. Mayer, R. J., Cullinane, T. P, dewine, P. S., Knappenberger, W. B., Perakath, B., and Wells, M. S., 1992, Information Integration for Concurrent Engineering (IICE), IDEF3 Process Description Capture Method Report, Air Force Systems Command, Wright-Patterson Air Force Base, Ohio 45433, AL-TR-1992-0057. 18. Ross, D. T., 1977, Structured analysis (SA): A Language for communicating Ideas. IEEE Transactions on Software Engineering, 3, (2). 19. Vernadat, F.B., 1996, Enterprise Modelling and Integration, Principles and Applications (Chapman & Hall). 20. Wang, W., Popplewell, K., and Bell, R., 1993, An Integrated Multi-View System Description Approach to Approximate Factory Modelling. International Journal of Computer Integrated Manufacturing, 6, (2). 21. Zukunft, O., and Rump, F., 1996, From Business Process Modelling to Workflow Management: An Integrated Approach. Scholz-Reiter, B. (Ed), Business Process Modelling (Berlin: Springer-Verlag). 7