Type 1 Methodology and Architecture
ARIS ARchitecture of Integrated Information Systems
ARIS, according to Scheer (1994), the ARIS-approach provides a generic and well documented methodological framework. The ARIS-architecture distinguishes between organization, function, information and control view.
Business processes are described by process chain diagrams. The modeling is done using a toolset instead of a language. According to process aspects several subtools are available, each displayed in an own window. The information captured by the ARIS toolset is stored into a database following the ERM (entity-relationship-model). In
Scheer (1994) is argued that a formal language imposes restrictions on the day-to-day usability by potential end users. ARIS focuses on the analysis and requirements definition phase during the design of managerial information systems, not on the execution of business processes.

Type 1 Methodology and Architecture
Workflow Management within the ARIS Framework
Abstract
Business process re-engineering is the key issue for companies to regain competitiveness and profitability in increasingly volatile markets. Customer-focused enterprises are to be structured along their core processes and have to be strictly value-oriented. As everyone agrees on the objectives, the way to effective and efficient processes is burdensome and goes far beyond theoretical frameworks. Workflow Management is becoming more and more based on cooperative, distributed workflow applications which on the one hand need business process re-engineering to be effective and on the other hand use process models as a specification for the control of the process execution.
The lack of powerful tools as well as methodological deficiencies - particularly with regard to capturing complex process logics and dynamics - are major obstacles for a successful re-engineering of business processes. The ARISapproach not only provides a generic and well documented methodological framework but also a powerful business process modelling tool. This tool supports the entire process re-engineerig project during all life cycle phases. In a research project it has been integrated with a prototype workflow management system to improve the reuse of business process models for the implementation of workflow applications.
Current State of Business Process Re-engineering Methodologies
Enterprise Modelling Frameworks
Issues of enterprise modelling and integration have extensively been discussed at several workshops and conferences. Modelling frameworks, methodologies and life-cycle concepts emerged in different application domains such as Computer Integrated Manufacturing (CIM) [1], office automation [2] and information system design [3].
These modelling methodologies and frameworks are often based on implicit assumptions regarding their scope, objective and level of detail. The ARIS-architecture as depicted in figure 1, for instance, focuses on the analysis and requirements definition phases during the design of managerial information systems. It is a multi-layer - multi-view approach focusing on business-related issues distinguishing between the organization, function, information and control views. Each view is further detailed with reference to the stages of the software life cycle inthe levels requirements definition, design specification and implementation description as promoted by CIMOSA [4]. Process chains diagrams support the integral description of business processes on a comparitively aggregate level.
They can further be detailed according to view-specific particularities. Figure 1 indicates suitable methods and contents of the ARIS-framework. It can be used as the schema description of a repository system for organizational information systems. The CIMOSA framework was designed mainly to support the model-driven enactment of manufacturing processes. Its orientation towards 'run-time-modeling' necessitates a formal process description language. This formal strictness imposes restrictions on the day-to-day usability by potential end-users.
Another aspect that leads to the large variety of modelling approaches is the fact that the aptness of modelling methodologies is very much dependent on the purpose of modelling. Some modelling effort might be primarily descriptive by nature while in other cases an optimized implementation solution is sought. In the latter case, the process analysis has to be supported by formal evaluation tools such as simulation. This requires an unambiguous parsable process description which is far too detailed for merely descriptive purposes.
Currently, the need is being felt to reconcile different approaches, identify commonalities and consolodate the various modelling methodologies and frameworks. Throughout the research community a consensus has been

Type 1 Methodology and Architecture reached that there is no 'silver bullet' to enterprise modelling and integration. However, when compaing some major modelling frameworks such as the Purdue Enterprise Reference Architecture (PERA) [5], the CIMOSA modelling framework, the IFIP Reference Model [6] or the ARIS-architecture [7], clearly a substantial overlap can be perceived. Hence, it seems useful to identify the commonalities and differences on the way of consolidating the architectures. This approach is reflected by the IFAC/IFIP Task Force on Architectures for Integrating
Manufacturing Activities and Enterprises [8].
Methodological Issues
Dynamic business process modelling will become increasingly important in the future. The shift from mass production to mass customization in IS-design and the growing interest in high-level system specifications requires well-defined business process models. It is necessary to have a clear understanding of the nature of business processes to modify and re-configure them. Business process models help to identify and remedy deficiencies in the process logic. Such are redundant process components, unnecessary complexity, and insufficient decision support.
They might also serve as a software process specification for designing information systems.
Despite the widely felt need for process re-engineering, research in the field is still to be considered as 'preparadigmatic'. No methodological platform has been acknowledged as 'de-facto-standard'. Most of the key terms such as event, trigger or condition are used quite differently throughout the research community. Mechanisms for organizational decision making and coordination are not widely incorporated in modelling frameworks. Doumeingts et al. [9] were one of the first who explicitly modelled decision structures in CIM. Sol [10] emphasizes the improtance of modelling decision processes when designing information systems. With regard to dynamic process behaviour, in-depth modelling methodologies for information systems design are readily available in software engineering such as data-flow based approaches, stimuli-response chains, Petri-Nets and object-oriented techniques.
Although these approaches provide valuable insight into the principal problems of capturing dynamic behavior in a
'quasi-static' descriptions, they are not particularly well suited for addressing the dynamics of business processes.
They often are too formally described and don't appropriately capture business rules and events that control the business process flow. The dynamic behaviour of business processes clearly shows an 'organizational bias'. Business process models are superimposed by human behavior. This behavioral distortion can only partially be represented by formal modelling approaches originating from the IS-domain. A business process modelling methodology has to incorporate aspects such as human roles, responsibilities, and (informal) communication.
Another aspect of business process modelling requiring further research is the topic of reference models. A reference model is a partial modelling block that is not completely instantiated. It is an incomplete representation of a system under a given viewpoint serving a certain purpose for specific users. Reference models are an organizational information resource. They represent and store 'know-how' about systems. Reference models form a 'know-how base for business process modelling'. Benefits commonly associated with (data) reference models [11] such as accelerated modelling processes, cost and time savings and quality improvements emphasize the need for business process reference models. Although several EEC projects such as CIMOSA, VOICE and CODE enquired this approach, business process related issues have not been covered extensively. The focus clearly was on structural reference models.
Business Process Reengineering and Workflow Management
Their usefullness to support the automization of business processes in offices as well as manufacturing areas has led
Workflow Management Systems (WMS) to become very popular the last years [12]. Workflow applictions are often chosen as a technological enabler for business processes which involve many employees on different locations and/or need a better system integration, better process control, higher quality and/or improved customer focus.
Process models are the basis for the development of enterprise specific workflow applications. Whereas the models describe the process structure and logic on a type level the workflow application supports the execution of single processes on the instance level. Like the definition of data structure in a database management systems leads to a specific database, the definition of a process model in a WMS results in a particular workflow application. In contrast to the generation of program code out of models like intended in the classical CASE approaches the

Type 1 Methodology and Architecture development of workflow applications is based on the configuration of existing software building blocks and supports therefore the reuse of software.
Available WMS integrate modelling systems for the graphical definition of process models (see FlowMark,
FlowPath, Workparty, Cosa, FloWare, etc.). In comparison to existing architectural frameworks for the business process modelling the functionality of these systems and their modelling concepts are quite poor. They do not support the separate construction of models in views like data, organization, function and their integration in a central process view. Each WMS-provider has defined his own method for modelling processes. These methods are in the most cases a derivation of Petri-Nets. Currently the Workflow Management Coalition is working on a standardization for the process modelling within WMS.
The Modelling of Workflow Applications
Workflow projects have a duration between one and three years depending on the field of application [13]. Like in the most BPR projects at the beginning there is no clearness about how to improve the business process structure and workflow. The following describes how the ARIS framework supports the development of workflow applications.
Requirements Definition
The requirements definition follows primary business oriented and not technical goals, i.e., during the requirements definition aspects like time, costs, frequency, redundancy, etc., are explored. After a current state analysis different alternatives describing how the concerned business processes can be improved are developed. Depending on what kind of solutions are considered to achieve the chosen alternative we can differentiate between organizational, personal or technical approaches or even a mixture of these.
From the technical point of view it is possible to explore business process models with regard to what kind of information system is necessary. On the basis of process models it is even possible to specify the type of WMS needed to support the process (document management, integration of database applications, etc.). Therefore all views have to be integrated in the process model: data, organization and function.
Since exception handling is a central problem in workflow applications we have developed a new approach for the management of such exceptions. Already on the level of the requirements definition exceptions can be considered through the definition of a special exception diagram.
If process models are defined on the requirements definition level and approved as input for the development of workflow applications, they can be refined in the next level.
Design Specification
During design specification the process models have to be refined in regard to the chosen WMS. Whereas on the requirements definition level concrete software systems or exact parameters for the configuration of the workflow application are not focused now these are aspects which have to be considered and elaborated. The following describes some central rules for the refinement of process models into workflow models.
Functions which will be automated by the workflow application have to be specified on a detailed level. If functions are taken over by a software system their is no need to specify them very detailed. Manual performed functions have to be specified as task lists. Therefore we use function trees which are even shown as an orientational help in the workflow application.
The data and data flow is described on the level of the requirements definition mainly as clusters which are input or output of functions. During design specification these clusters have to be specified more in detail regarding the entities and structure of the data clusters. For a detailed description of the data flow it is necessary to define a data flow diagram.

Type 1 Methodology and Architecture
The organizational units described in the process models are often on an abstract level. Workflow applications use the role concept. Roles describe the capabilities a person must have to perform a certain job position. According to such roles at the runtime of the workflow application persons can perform specific process steps. This concept has to be considered.
Beside the described aspects it is important to define exactly the events and decision nodes within process models as well as specify the parameters for the integration of software programs.
Implementation Description
At the level of the implementation description it is necessary to adapt the given information infrastructure to the distributed, integrated concept of the workflow application based on the model resulting from the design specification.
The workflow models are used to configure the workflow application. They can be understood as a graphical program. Through this reuse of business process models the manual programming of software code decreases.
Not any WMS supports the graphical definition of workflow applications. In such cases the workflow models resulting from the implementation description can be used as a basis for the "normal" implementation work through programmers.
The Integration of Business Process Modelling Tools and Workflow Management Systems
Tool support for business process modelling requires computer-based means for representing and processing
(reference) models. It covers functionalities such as model representation and -manipulation. Major functions of a model management system are [14]:
 model construction and storage
 model selection/retrieval and analysis
 model configuration
 model integration
 model adaptation and modification
 model evolution and change
 model execution and interpretation
As described the stepwise development of workflow applications out of business process models is a meaningful approach. We have accomplished case studies in 17 companies which have or are in progress to implement company specific workflow applications. From this empirical research we have figured out different strategic success factors for the development of workflow applications, e.g., each of those 17 companies had engaged consultants to elevate the state of the art and develop alternatives for the reorganization of the business processes. Only one of those 17 companies could directly reuse the results of the consultancy services for the implementation of a workflow application. Reasons for this bad integration of reorganizational activities and the implementation of an appropriate system are:

Some consultancies dind't use modelling methods. They described their suggestions only verbally.

Some consultancies described business process models on ly in paper form.

Type 1 Methodology and Architecture

Other consultancy companies used modelling tools which on the one hand support a method not understood by
WMS and other hand have no interface to WMS.
On the background of these situations we have developed a WMS and integrated this system with the modelling tool
"ARIS Toolset". The following describes these systems:
ARIS-Toolset
The ARIS-Toolset [15] provides comprehensive computer support for business process modelling. Its modular range is depicted in figure 2. The four modules provide means for a computer aided analysis, planning and introduction of managerial information systems. The systematic approach covers the entire modelling life cycle. The ARIS-Modeller focuses on system modelling. Based on the meta-structure of the ARIS framework, view-specific modelling methods are provided for computer based modelling. This includes extended entity relationship modelling as well as process chain diagrams, stimulus-response chains, and functional and organizational heirarchy charts. The ARIS-Modeller covers the model construction and storage part of the model management activities mentioned above.
The ARIS-Analyzer provides means for examining and assessing the current system with regard to key performance indices. Weak point analysis can be conducted fore ach modelling view. Furthermore, an idealized integration concept may be derived. It includes target function and data models. Reference models are an essential part of the
ARIS-Analyzer. They are used to support the analysis and the modelling activities. The model selection and retrieval process is assisted by a classification scheme (business topology). It contains a table of features and feature characteristics to classify a company. Among the features are e.g. product structure, type of manufacture, complexity of assembly or type of order release. Based upon a company-specific feature profile, the most appropriate reference model is extracted from the model base and used as the starting point for modelling resp. analyzing the current situation. The selection process is supported by rule-based expert system. Model configuration activities such as model adaption and integration also are part of the ARIS-Analyzer. The reference model selected is tailored to the company-specific requirements. This involves steps such as detailing, modifying and enhancing the reference model.
The ARIS-Projectmanager is used for project control tasks. It is designed to plan, control and monitor the entire project in all its phases. The ARIS-Projectmanager defines all the tasks to be dealt with in the course of a business process modelling activity. The aim of the ARIS-Navigator is to provide computerized documentation for the corporate model developed during the modelling phases.
Figure 3 shows a sample screen layout of the ARIS-Modeller. The menu bar and the icons are compliant with the
Windows standards. Several windows can be displayed simultaneously. The active window in the upper left part of the screen is highlighted. It shows an excerpt of an ERM-based model. The modelling constructs (object types) for data modelling are activated in the left column of the screen. When another window with another model type is selected, it changes accordingly. On top of the construct column the ARIS-architecture is displayed indicating that the active window is a data modelling window.
The other three windows show the heirarchical functional and organizational modelling as well as a process chain diagram. The latter is associated with the control view of the ARIS-architecture. The modelling objects resp. the modelling instances stored in a database upon instantiation. Comprehensive consistency checking ascertains the correctness of the models. The modelling syntax is checked against rules derived from the metastructure in the repository. This ensures the correct application of the modelling constructs.
ARIS Workflow Manager
The ARIS Workflow Manager is the prototype of a WMS developed at the Iwi [16]. It is based on a client-serverarthitecture and fully process oriented. The functionality of the system comprises task management, process oriented searching in archives, the creation and distribution of multimedia documents (text, pictures, audio and video) as well as concepts for exception handling.

Type 1 Methodology and Architecture
The ARIS Workflow Manager uses process models from the ARIS Toolset as basis for the control of business process execution. Therefore the metastructure of both systems has been adapted to each other. Besides the definition of the process structure it is possible to start the process execution directly from within the ARIS Toolset by selecting and activating a single functional step of a process model.
Through a feedback functionality the end-user can leave statements (problems, suggestions, ideas, etc.) in a multimedia form for the process manager. The structuring of these feedbacks is done automatically by the system.
Process managers can browse through the process models in the ARIS Toolset and react immediately to new feedbacks.
Figure 4 shows the user interface of the ARIS-Workflow Manager.
Conclusion
There are no easy ways or short cuts on the way to truly integrated enterprises. Undue simplifications in the business process analysis and integration phase are a substantial risk for the implementation of integrated systems. Case studies and the integration of a prototype WMS with the ARIS Toolset has led us to the opinion that the consolidation of methodological frameworks (i.e. meta structures) is an essential prerequisite for the overall integration from business reorganization to information systems implementation.
References
[1] For a comprehensive treatment see Yoshikawa, H.; Goosenaerts, J. (eds.), Information Infrastructure Systems for Manufacturing. IFIP Transactions B-14. Amserdam: North-Holland, 1993; Petrie, Ch. J. (ed.), Enterprise
Integration Modelling. Proceedings of the First International Conference. Cambridge et al.: MIT-Press, 1992.
[2] Pernici, B.; Barbic, F.; Fugini, M.G. C-TODOS, "An Automatic Tool for Office System Conceptual Design",
ACM Transactions on Information Systems 7(1989)4, pp. 378-419.
[3] Olle, T.W.; Hagelstein, J.; MacDonald, I.G., Information Systems Methodologies. A Framework for
Understanding. Workingham et al:, 1988.
[4] ESPRIT Consortium AMICE (eds.), CIMOSA: Open System Architecture for CIM, 2nd rev. and ext. Ed.
Berlin, Springer, 1993; Vernadat, F., "CIMOSA: Enterprise Modelling and Enterprise Integration Using a
Process Based Approach", Proceedings of the JSPE/IFIP TC5/WG5.3 Workshop on the Design of Information
Infrastructure Systems for Manufacturing, DIISM'93, Tokyo, 1993, pp. 65-84.
[5] Williams, T.J., "The Purdue Enterprise Reference Architecture", Proceedings of the JSPE/IFIP TC5/WG5.3
Workshop on the Design of Information Infrastructure Systems for Manufacturing, DIISM'93, Tokyo, 1993, pp.
43-64.
[6] Olle, T.W.; Hagelstein, J.; MacDonald, I.G., Information Systems Methodologies. A Framework for
Understanding. Workingham et al:, 1988.
[7] Scheer, A.-W., Architecture of Integrated Information Systems, Berlin, Springer, 1992.
[8] Williams, T.J. et al., Architectures for Integrating Manufacturing Activities and Enterprises, Technical Report.
Williams, T.J. (ed.): Indiana, West Lafayete 1993.
[9] Doumeingts, G.;Chen, D.; Vallespir, B.; Fenie, P, GIM (GRAI Integrated Methodology) and its evolutions. A methodology to design and specify Advanced Manufacturing Systems, Proceedings of the JSPE/IFIP
TC5/WG5.3 Workshop on the Design of Information Infrastructure Systems for Manufacturing, DIISM'93,
Tokyo, 1993, pp. 101-117.

Type 1 Methodology and Architecture
[10] Sol, H.G., "Paradoxes around DSS", in: Holsapple, C.W.; Whinston, A.B. (eds.): Decision Support Systems:
Theory and Applications. NATO ASI Series, Vol. F31. Berlin et al., Springer, 1987, pp. 1-17.
[11] Hars, A., Referenzdatenmodelle. Wiesbaden, Gabler-Verlag, 1994, p. 13.
[12] White, T.E.; Fischer, L. (eds.): New Tools for New Times: The Workflow Paradigm, Alameda, USA, 1994.
[13] Joosten, S; et al.: WA-12 and Empirical Study about the Practice of Workflow Management, University of
Twente, Enschede, Netherlands, 1994.
[14] Hars, A., Referenzdatenmodelle. Weisbaden, Gabler-Verlag, 1994; Chang, Ai-Mei et al., "Model management issues and directions", Decision Support systems 9(1993), pp. 19-37.
[15] IDS Prof. Scheer, GmbH: ARIS-Toolset. Version 2.0 Manual. Saarbrücken 1994.
[16] Galler, J.; Scheer, A.-W. (1994), Workflow Management: Die ARIS Architektur als Basis eines multimedialen
Workflow-Systems, in: Scheer, A.-W. (eds.), Veröffentlichungen des Instituts für Wirtschaftsinformatik, paper
108, June 1994.

CAPM
TYPE 1 STUDY
Type 1 Study
Computer Aided Production Management
University of Nottingham

Type 1 Architecture
CARNOT MCC
The Carnot Project in the Enterprise Integration Program of the Information Systems Division at MCC is addressing the problem of logically unifying physically-distributed, enterprise-wide, heterogeneous information. World-wide information management is the objective. Specifically, Carnot will provide a user with the means to navigate information efficiently and transparently, to update that information consistently, and to write applications easily for large, heterogeneous, distributed information systems
 systems where resources may even reside on the conventional, closed environments that pervade businesses world-wide.
Carnot has developed and assembled a large set of generic facilities that are focused on the problem of managing integrated enterprise information. These facilities are organized as five sets of services: communication services, support services, distribution services, semantic services, and access services, as shown in Figure 1.

C4
C4 (GM)
Type 1 Architecture
General Motors

Type 1 Architecture
CIM - ALIVE ESPRIT Project _____
The ESPRIT Project CIM-ALIVE established a common project CIM reference model identifying cost effective reusable CIM concepts.

Type 1 Architecture
CIM Building Open Systems CIM-BIOSYS
MSI's INTEGRATING INFRASTRUCTURE Manufacturing Systems Integration Research Institute

Type 1 Architecture
MODEL ENACTMENT BASED ON USE OF THE CIM-BIOSYS INTEGRATING INFRASTRUCTURE
R H Weston and I A Coutts
MSI research Institute, Department of Manufacturing Engineering,
Loughborough University of Technology, Loughborough, Leicestershire,
LE11 3TU, United Kingdom
R.H. Weston@lut.ac.uk
Abstract
Properties of integrating infrastructures (IIS) are identified, with reference to enabling system integration on an enterprise-wide scale. These properties are used to highlight features of existing integrating infrastructures, including
CIM-BIOSYS. Also described is the role of CIM-BIOSYS in enabling model enactment and hence a bridge to topdown, structured system design methods.
The Need for a Structured Approach to Creating Manufacturing Systems
In modern manufacturing enterprises computer systems have become essential tools, which properly used have enabled the delivery of higher quality products over shorter timescales. Here activities carried out by appropriate combinations of people, automated equipment and computational tools can be achieved more efficiently and effectively than by predecessor solutions. However, in seeking to optimize the operating characteristics of a manufacturing enterprise there remain major problems of unifying the goals and activities of individual processes, whilst retaining sufficient flexibility in the holistic systems formed. Here methods and tools are required which are capable of defining and constructing complex integrated systems in a manner which enables them to realize systemwide goals, where invariably those goals will continuously change with the characteristics of the consumer, supplier, labor and financial markets within which they operate. In particular, therefore, it is necessary to realize improved support for:
(i) formally specifying the way in which the 'entities' 1 of a manufacturing enterprise should 'interoperate' 2 . This needs to be achieved with sufficient realism and completeness to guide subsequent system implementation [1].
(ii) 'enacting' 3 formal specifications so that system build and change can be achieved in a structured and effective manner [2].
This paper considers ways of facilitating (ii) having identified key benefits that can be realized from using
'integrating infrastructures (IIS)', which themselves offer computational means of implementing and supporting the operation of integrated manufacturing systems. Here research findings of the Manufacturing Systems Integration
(MSI) research institute at Loughborough University of Technology (LUT), UK are described which led to the creation of the CIM-BIOSYS IIS.
Key Properties and Benefits from Using an Integrating Infrastructure
1 'entities' is used here as a generic term, embracing the 'processes', 'computer systems', 'people', 'automated equipment' and other 'components' of an integrated system.
2 the term 'interoperate' is used to imply that the runtime operation of more than one entity is realized with a common purpose or goal in mind.
3 the term 'enact' is used to imply the process of turning a specification or plan into a working solutio. This process should be computer assisted and ultimately fully automated.

Type 1 Architecture
Figure 1 depicts the way in which an integrating infrastructure (IIS) can be used to integrate the runtime activities carried out by a number of manufacturing entities. It is not the purpose of the IIS itself to contribute functionality, this will be contained within the interoperating components of the systems. Rather the purpose of the IIS is to facilitate an aggregation of that functionality by enabling and managing the required interoperation. An IIS can thus be viewed as needing to satisfy the dual requirement of providing:
(i) an appropriate set of integration 'services', which collectively underpin the runtime integration of a number of entities, i.e. it is required to offer services which enable interoperation.
(ii) a set of integration 'tools' which collectively define, manage and change associations formed between entities.
When used in combination, the 'services' and 'tools' of an IIS can unify the various activities carried out in a complex manufacturing enterprise, whilst maintaining sufficient flexibility to allow such systems to evolve over a period of time i.e. an infrastructure can have marked benefits in terms of dealing with complexity and change . Important advantages stem from an inherent separation of ' integration processes ' from ' application processes ', where the former are concerned with accomplishing system interoperation and the latter with realizing system functionality . It is not necessary for an entity which uses IIS services to have knowledge of the way in which other system entities operate, but only needs a knowledge of how it should use IIS services. From the perspective of interoperating software processes, they are not required to maintain a localized (or private) knowledge of the way in which integration is achieved; rather they only require knowledge of how to use an appropriate sub-set of the integration mechanisms supported by the IIS. As a direct result a significant simplification occurs, with respect to:
(i) the design of the software processes themselves and
(ii) an inherently linear increase in system complexity, as the number of interoperating entities n increases (This as opposed to the n ( n -1)/2 relationship found with ad-hoc pairwise integrated systems).
Both of these simplifications are extremely important in the context of complex integrated manufacturing systems. In contemporary systems n can be extremely large, with interoperation occurring between large numbers of people, computer systems and automated/semi-automated machines. Moreover, in response to a need for increasingly configurable, modular and distributed software systems that number can typically be expected to rise sharply over the next decade.
Of course, it is not practical to expect 'something for nothing' and the complexity needs to be handled somewhere.
For example, knowledge must be retained about interrelationships and associations which must be formed between interoperating entities. This paper will show that much of that knowledge can be defined, maintained and modified by using the IIS.
Another inherent property of using an IIS is that it promotes a natural decomposition of solutions, thereby separating them into more containable and hence soluble parts. Indeed advantages derived from this decomposition are manifested in various ways. Through the provision of a well defined 'service interface' an IIS facilitates the standardization of entities. It enables systems to be designed with a clearer focus on implementation independent issues related to what a system should be doing. Subsequent use of the IIS provides a means of dealing with implementation dependent issues, such as how synchronization and information sharing can be achieved. As a result, opportunities arise to use methods which are now commonplace in the field of software engineering (such as CASE tools) to design integrated solutions, this can reduce appreciably the engineering effort and timescales connected with integration projects. Subsequently the use of IIS tools can facilitate the mapping of reusable distributed software solutions onto a given set of physical resources (i.e. data repositories and machines, with their embedded computer software and hardware). This in turn provides means by which manufacturing systems can be more flexible than contemporary counterparts, with 'soft' connections established between entities. This gives rise to soft or flexibly integrated manufacturing systems which facilitate continuous improvement. Furthermore it should be mentioned that the ability to achieve a software based mapping of distributed software onto physical resources, offers means of establishing practical migration paths from the use of a legacy (i.e. previously installed base) of non-standard

Type 1 Architecture physical resources and software systems, towards systems which can be more readily and effectively integrated into their host environment.

Type 1 Methodology
CIMSIM ESPRIT Project _____ also ESPRIT Exploratory Project 5603
On the economic aspect, the ESPRIT Project CIMSIM intends to provide a methodology and associated tools for the economic and technical evaluation of various CIM solution options. An ESPRIT Exploratory Action 5603 is dealing with the problems of incorporating human factors into technology research and development along with techniques for the economic justification of CIM.

Type 2
CIMOSA ESPRIT Project
Lastly, we close this section by introducing CIMOSA [17], the well known CIM Open System Architecture developed by the AMICE Consortium, and the most important CIM initiative within the ESPRIT program. The term
AMICE is a reversed acronym for 'European CIM Architecture'.
The aim of this project is to elaborate an open system architecture for CIM and to define a set of concepts and rules to facilitate the building of future CIM systems. An important aspect of the project is its direct involvement in standardization activities. The two main results of the project are the Modeling Framework, which is well known and the Integrating InfraStructure (see Fig. 4.8). The Modelling Framework supports all phases of the CIM system lifecycle from requirements definition, through design specification, implementation description and execution of the daily enterprise operation. The Integrating Infrastructure provides specific information technology services for the execution of the Particular Implementation Model, but what is more important, it provides for vendor independence and portability.
CIMOSA incorporates an event-driven, process-based modeling approach with the goal to cover essential enterprise aspects in one integrated model. The main aspects are the functional, behavioral, resource, information and organizational aspect. For each of the aspects, modeling constructs are available. This enables to model the aspects of business processes independent from each other. CIMOSA provides a formal language for the modeling, which is specified in BNF form. Furthermore, CIMOSA aims at the execution of business processes also, not only the modeling of those. The goal is to drive an information infrastructure with the processes modeled.
CIMOSA insists particularly that the released model of the CIMOSA architecture should be processable or executable and evolutive, e.g., it can be modified easily during the run time. CIMOSA also intends to provide a methodology to show how to use the reference architecutre to get a particular architecture of the studied enterprise.
These are known respectively as the CIMOSA Model Creation Processes, and as the CIMOSA System Life Cycle.
The CIMOSA modelling framework has been adopted by CEN/CENELEC as the European prestandard for enterprise modelling, where it is known as ENV 40003.
It is worth noting that several ESPRIT projects are currently carried out to evaluate and validate CIMOSA, notably the ESPRIT Project VOICE (Validation OSA in Industrial CIM Environments), the ESPRIT Project CIMPRES
(CIM Model and Implementation Concept in Precision and Special Tooling Industry). Another ESPRIT Exploratory
Action, 5605, is developing applications of CIM concepts, architectures and technology to Computer Integrated
Agriculture based on CIMOSA.
[17] AMICE Consortium, Open System Architecture for CIM, Research Reports of ESPRIT Project 688, Volume 1,
Springer Verlag, Berlin (1989).
[1] ESPRIT, Project 688, AMICE, OPen Systems Architecture for CIM, Springer Verlag, Berlin (1988)
[2] ESPRIT, Project 688, CIMOSA Reference Architecture Specification, ESPRIT Consortium AMICE, Brussels,
Belgium (May 1989)
[3] ESPRIT Consortium AMICE, Open System Architecture, CIMOSA, AD 1.0, Architecture Description, ESPRIT
Consortium AMICE, Brussels, Belgium (1991)
[4] Anonymous, AMICE: CIMOSA, ESPRIT Project 5288, Milestone M-2, AD 2.0, Volume 2, Architecture
Description, Document R0443/1, Consortium AMICE, Brussels, Belgium, (August 24, 1992)
[5] Beeckman, Dirk, 'CIMOSA: Computer Integrated Manufacturing Open Systems Architecture', Int. J. Computer
Integrated Manufacturing, Vol. 2, No. 2, pp. 94 - 105 (March - April 1989)
[6] Jorysz, H.R. and Vernadat, F.B., 'CIMOSA Part 1: Total Enterprise Modelling and Function View,' Int. J.
Computer Integrated Manufacturing, Vol. 3, Nos. 3 and 4, pp. 144-156 (1990)
[7] Jorysz, H.R. and Vernadat, F. B., 'CIMOSA Part 2: Information View,' Int. J. Computer Integrated
Manufacturing, Vol. 3, Nos. 3 and 4, pp. 157-167 (1990)
[8] Klittich, M., 'CIMOSA Part 3: CIMOSA Integrating Infrastructure - The Operational Basis for Integrated
Manufacturing Systems,' Int. J. Computer Integrated Manufacturing, Vol. 3, Nos. 3 and 4, pp. 168-180 (1990)

Type 2

CNMA
The ESPRIT Project CNMA allows the extending of MAP.
Type 1
ESPRIT Project 2617

COPICS
See IBM.
Type 1 Architecture and Methodology
Communications Oriented Production Information and Control System

Type 1 Architecture
EIP Enterprise Integration Program
Sponsored by: USAF Manufacturing Technologies Special Studies Program, usually called ManTech.

Type 1 Architecture
EIP Approach Enterprise Integration Program
Besides the university and company developed architectures, the EIP (Enterprise Integration Program), a research and development program composed of several projects, is being carried out in the USA. The Program Manager is the US Air Force and the Prime Contractor is SOFTECH. The EIP has four phases (framework, 18 months; commercialize, 24 months; pilot sites, 14 months; round up, 4 months). EIP considers that there is a global race for the technology to be first to market with the best. The range from the strongest to weakest will be decisive. The best performers will be those who excel at coordination. Specific improvements in process or product yield will only give temporary advantage. The source of a sustainable advantage will be the ability to continually improve.
EIP believes that Enterprise Integration is concerned with getting the right information, parts, processess, people, cash and products to the right places at the right times, and with reacting rapidly to changes in market demand, resources, technology and organization. The EIP seems to be the most important program in the US for the time being in the area of CIM. Close cooperation with the European AMICE Consortium (CIMOSA project) has been established in order to seek the complementary advantage which may exist between EIP and CIMOSA.
It seems that EIP addresses a broader scope than that of CIMOSA. EIP intends to integrate any and all models in an enterprise, all running in a hetergeneous and open environment (See Fig. 4.9). The US had sponsored two studies on an Enterprise Integration Framework (EIF) which focused on the applicability of CIMOSA to the US definition of the EI problem space. Cooperation between AMICE and US would emerge in a more internationally harmonized framework.

EIS
Type 1
Engineering Information System
Honeywell, Inc.

ESPRIT - CNMA
Type 1
Communications Network for Manufacturing Application
ESPRIT 2617, 5104

ESPRIT 7110 CIMOSA
Type 2

ESPRIT DCC
Type 2
EP 8823

ESPRIT DINAS
Type 2
EP 6779

ESPRIT - VOICE
Type 2
EP 5510, 6682

Language Standard
ESTELLE Formal Protocol Specification Language [ISO 1988]
Helps establish the Integrating Infrastructure (Communications) Design.

EXPRESS
Information Modelling Language used with STEP [ISO 10303]
Language Standard

FCIM
Language Standard

Type 1
FOF Factory to Future
ESPRIT 3143
It is generally considered that production in the future will be based on a one-of-a-kind system of product production. That's why the FOF Project (Factory of the Future - a Basic Research Action in the ESPRIT Programme) was launched. The ultimate goal of the project is to obtain a designer's workbench for the development of CIM in future production systems providing one-of-a-kind products (OKP) to the market, each OKP will require its own product design and process design [12].
There are many methods for describing the operations which occur in production systems. However, the methods are all fundamentally fragmented as they are all based on a set of scattered, theoretical notions (communication, organization, human point of view, decisional approach). Fig. 4.6 illustrates the various 'views' identified in the project, and points out their relationships. As the views are presented separately, we need an integrated approach for
PMS design. This integrated approach in the design phase was first based on an integrated model called
REMBRAND. A set of Design Choice (DC) and a set of Performance Indicators (P.I.) were connected by a set of relations. The designs of the Production Management System (PMS) were done in agreement with the value of the
P.I. and depending on the DC. See Fig. 4.7.
[12] Falster, P., Rolstadas, A., and Wortmann, A., 'Factory of the Future Production Theory', FOF WP2 Report,
Design of a Conceptual Model, Technical University of Norway, Trondheim, Norway (January 1991).

Partial Type 2 Architecture Methodology
GRAI-GIM
Another work performed at the GRAI laboratory was the extension of the GRAI method to GRAI-GIM (GRAI
Integrated Methodology) within the framework of the ESPRIT Project 418, Open CAM system and ESPRIT Project
2338, IMPACS [36,37]. GRAI-GIM contains a user-orineted method and a technically-oriented one (See Fig. 4.14).
The user-oriented method transforms user requirements into user specification in terms of function, information, decisions and resources. The technically-oriented method transforms the user specification into technical specifications in terms of information and manufacturing technology components and the organization. The technical specification must allow the implementor to choose (buy, commission, or develop) all the components needed to implement the system. A computerized support tool knows as CAGIM (Computer Aided GIM) is being developed at the GRAI Laboratory within the framework of the IMPACS project on Unix systems with X-Windows, to support the GRAI-GIM method.
[36] Vellespir, B., Doumeingts, G., and Zanettin, M., 'Proposal for an Integrated Approach to Model and Design
Manufacturing Systems', Proceedings, Third International Conference on Computer Application in Production and
Engineering, CAPE '89, Tokyo, Japan (October 2-5, 1989). Published by North Holland.
[37] Zanettin, M., and Doumeingts, G., 'The GIM Method for CIM System Analysis', for Advanced Studies in
Systems Research and Cybernetics, International Institute for Advanced Studies in Systems Research and
Cybernetics, Baden Baden, Germany (August 1992).

Early GRAI Work - Type 1
GRAI Method
Similar work on methods was also carried out in Europe, notably the GRAI method [7] and MERISE method [11].
Before developing the GRAI method, some existing works had been reviewed, notably SADT and SSAD methods. It was found that the decisional aspects were not very well taken into account in these methods. So, it was important for the GRAI method particularly to deal with the decisional aspects of manufacturing systems. Based on the GRAI models, two formalisms were developed to model the macro decision structure and the micro decision center; the
GRAI grid and the GRAI nets. A structured approach was defined to show how to apply the method. The GRAI method has been transferred to industry (over 100 industrial applications).
[2] Doumeingts, G., Vallespir, B. Darracar, d. And Roboam, M., 'Design Methodology for Advanced Manufacturing
Systems,' Computers in Industry, Vol. 9, No. 4, pp. 271-296 (December 1987).
[3] Doumeingts, G., Vallespir, B., Zanettin, M., and Chen, D., GIM, GRAI INTEGRATED METHODOLOGY, A
Methodology for Designing CIM Systems, Version 1.0, Unnumbered Report, LAP/GRAI, University Bordeaux 1,
Bordeaux, France (May 1992).
[7] Doumeingts, Guy, Methode GRAI: Methode de Conception des Systemes de Productigue, These d Etat en
Automatigue, Universite de Bordeaux 1, Bordeaux, France (November 1984).

Type 1
The GRAI model is a reference through which various elements of real world can be identified. The macro conceptual model is used to express one's perception and ideas on the manufacturing system which is decomposed into a decision subsystem, an information subsystem and a physical subsystem. Particularly within the decision subsystem one finds a heirarchical decision structure composed of decision centers. Decision centers are connected by a decision frame (objectives, variables, constraints and criteria for decision making). The operating system is an interface between the decision system and the physical system. The micro conceptual model is used to represent the internal elements and structure of the decision center.

IDEM
Type 1
Integrated DEsign and Modelling
Loughborough University

Type 1
Progress Report
IDEM - Methodology for factory modeling:
Just automating parts of a manufacturing facility is not enough to keep pace with the competitive environment. Thus, we need to take into account integration of these parts. Existing factories need to be redesigned or even an entirely new plant needs to be developed to remain competitive. Hence, is a need for a comprehensive factory modeling methodology. A lot of limitations exist in the available modeling techniques like not accurately representing the hierarchical nature of many factory systems. The IDEM methodology aims at overcoming these limitations and provides a methodology which can model a factory with not much effort.
The IDEM modeling technique consists of conceptual modeling, approximate modeling and detailed modeling. The conceptual modeling consists of the aims of the upper level management in the re-organization. They also set the scope and context of reorganization. Then an approximate model is constructed. This approximate model should be approximate enough not to be too detailed and cumbersome without cmpromising on the main aspects of the factory.
Then areas of the factory are considered and the detailed modeling is done.
Another problem which arises is the lack of modeling tools that model the factory from different viewpoints (ex functional, information, etc.). Some tools model the functional view well but do not model other views well. By doing this some of the important information of the model is lost. To solve this problem, a multi view modeling technique is needed. The IDEM method uses three different views - function, dynamic and inforamation view. The function view models all the functions that take place. IDEF0 is the basis of the IDEM function view since it can accurately model the hierarchical structure and the inputs, outputs, controls and mechanisms. The information view shows the information flows in the model and the dynamic view shows the way the model behaves with time.
The IDEM technique is an alternative to model a factory but the real effectiveness of the technique would be evident only when a process is modeled by the reader.
Relation between Manufacturing Strategy and Manufacturing model:
Manufacturing strategies are important for a company's success. However, often there is an inadequate link between manufacturing strategy and its realization. Molina et al think that this is due to the lack of appropriate decision support tools which can assist top management in organizing and communicate crucial strategy. Such tools need both a knowledge of how a strategy can be formulated and the manufacturing position of the firm. The results from two projects at Loughborough University of Technology namely the Startegic Manufacturing Decision Support (SMDS) project and the Model Oriented Simultaneous Engineering (MOSES) project are used in this paper. Manufacturing strategy can be broken down into Business Strategy, Product design strategy, Financial Strategy and Manufacturing
Strategy. An effective manufacturing strategy consists of interactions between these four areas. In developing an effective manufacturing strategy, we need to consider the present manufacturing of the company. This is where the manufacturing model comes into play.
The SMDS project aims to link business strategy to manufacturing performance. It also aims to supply a tool to top management to organize and communicate their strategies. The Manufacturing model is a four level model consisting of the factory, shop, cell and station levels. In each of these levels, there are Strategic decisions, Operational rules and performance measures. The factory level should represent the information needed for manufacturing strategy.
Thus the same set of criteria (Strategic decisions, Operational rules and performance measures) can be used for
SMDS. Strategic decisions are decisions made choosing a particular variable over another. Operation rules are the rules that are in use in the various levels and performance measures are the measures of the performance caused by the Strategic decisions and the operating rules.
Metamodels in manufacturing:
To design a manufacturing plant, the expected performance of the plant needs to be known. This is not an easy task and simulation needs to be carried out to find the performance. For a huge factory, performing a simulation is not a very efficient way of finding out the performance. These simulation models take up too much memory and they give

Type 1 out way too much output. They are also very complicated and the output cannot be interpreted easily. Hence, a metamodel can be used to simplify the simulation. In a simulation if the output Y = f1 (X1, X2, ... Xn) then the corresponding metamodel could be Y' = f2 (X1, X2, ... Xm). The authors did a study on the use of metamodels in manufacturing. The aim of the study is to show that metamodels are being used more and more in manufacturing.
The authors found that there was interest in metamodels in the late 70s and then there were not many papers about metamodels. The interest in metamodels has increased again since 1987. Also the numbers of papers of metamodels in manufacturing systems has increased greatly. Earlier, the papers were more theoretical but now the papers are more case studies. This means that the use of metamodels has increased in manufacturing.
IDEF3:
The IDEF3 method is a descriptive method. It was developed by the US air force in the Integrated Computer Aided
Manufacturing project. IDEF3 is a process description capture technique. The IDEF3 is compared with the IDEF0 technique. IDEF0 technique is a function modeling technique. The two methods were compared using the example of a small company. IDEF0 does not consider the time order between the processes but the IDEF3 technique can. The
IDEF0 technique can show the input, output, control and mechanism whereas the IDEF3 cannot. Processes can be associated with IDEF3 technique but they cannot be seen on the diagram.

Type 1
IEM Integrated Enterprise Modelling
IPK - Berlin
The IEM (Integrated Enterprise Modeling) method is based on three classes: product, resource and order. Enterprise data and business processes are assigned to objects of these classes during the modeling. IEM distinguishes between two views: function model and information model. Tasks on objects and business processes belong to functions and so-called linkage-elements like sequence, parallel branching, join and so on. The information model describes the data of an enterprise model based on the three classes mentioned above. Additional to the functional and information model other views can be integrated, e.g. control mechanisms, organization units and costs. How this is done is not explained in Mertins (1993). It is mentioned that a prototype of a modeling tool is under construction. Execution of business processes is not mentioned at all.

Type 2
MICIM ESPRIT Project 2706
In particular, in the methodology area, the ESPRIT Project 2706, MICIM (Methodology for the Introduction of
CIM), considered that the methodology for progressing towards an integrated manufacturing environment has largely been neglected with most of the emphasis of current work being placed on the problems arising in technology. This project therefore concentrated on defining a methodology to remedy this.

Type 1
MMCS Manufacturing Management Control System
ESPRIT 418
The MMCS (Manufacturing Management Control System) [13] was developed within the ESPRIT Project 418 -
Open CAM System, in which the GRAI laboratory was involved. This model is aimed at the problem of Shop and
Cell planning and control with well defined interfaces (see Fig. 4.2). These interfaces transform, where necessary, the external data view into the MMCS view. Via a database, the system is able to interface with the available commercial MRP system at the factory level. The core functions of the MMCS are the Shop and Cell Controllers.
Both the controllers have the same structure. They are responsible for the management of jobs, capacities and materials at Shop and Cell Levels respectively.
[13] PROCOS A/S, Functional Model for Shop and Cell Controllers, ESPRIT Project 418, Open CAM Systems,
PROCOS A/S, Birkeroed Denmark (November 24, 1988).

Type 1
MOSES
Project Background
Model Oriented Simultaneous Engineering System
University of Loughborough
University of Leeds
MOSES is a research project being carried out by two groups at the University of Leeds (in the Department of
Mechanical Engineering) and Loughborough University of Technology (in the Departmet of Manufacturing
Engineering).
The project is funded by the UK government (in the form of the EPSRC) and several industrial collaborators and has a full title (ie. That which appears in EPSRC literature) of:
"Exploiting Product and Manufacturing Models in Simultaneous Engineering"
The project is funded for a 3 year duration and started in May 1992.
Project Aims and Objectives
There are three major objectives:
1.
To provide a Reference Model for CAE systems based on Product and Manufacturing models.
2.
To identify the information and procedures necessary to support that part of the simultaneous engineering process concerned with concurrent design for function and design for manufacture, and to define and apply a prototype knowledge and software environment.
3.
To provide Intermediate and End Of Project demonstrations using industrial case studies.
Personnel
The following people are directly involved with the research being carried out by the project:
Leeds:

Professor Alan de Pennington

Dr. M. Susan Bloor

Dr. Neal Juster

Ms. Alison McKay

Mr. Pete Dawson

Mr. Brian Henson

Dr. Martin Ashworth
Loughborough:

Type 1

Professor Robert Bell

Dr. Robert Young

Dr. Keith Popplewell

Ms. Jenny Harding

Mr. Tim Ellis
Papers
A list of papers that have been published by project members is available.
The list contain links to the published papers (sometimes postscript, sometimes dvi, sometimes plain text).
Sometimes (often!) a link points to a message saying that it is not available on-line (for various reasons). A request for a copy of any of the published papers may be sent to me or either of the contacts listed below.
Contact Addresses
For general enquiries contact either:
Margaret Gibson
Dept. Of Mechanical Engineering
University of Leeds, LS2 9JT, UK
Phone: +44 (0) 113 233 2113
Fax: +44 (0) 113 233 2150
E-mail: maggie@leva.leeds.ac.uk or
Mary Treasure
Dept. Of Manufacturing Engineering
Loughborough University of Technology, LE11 3TU, UK
Phone: +44 (0) 1509 222921
Fax: +44 (0) 1509 267725
E-mail: A.M.Treasure@lut.ac.uk

Type 1
For specific enquiries, please see Personnel section.
Product Model
A Product Model is a computer representation of product data. Product data describes a particular product. The computer representation of product data requires a product data model, which defines the form and content of product data, and a product model, which contains data which is specific to the particular product concerned. For example, the fact that products have a colour and a name would be defined in a product data model; "blue car" and
"red pen" are examples of product models. Product data is the combination of a product model and the corresponding product data model. The product data model provides the meaning of the content and the product model: for example, the facts that "car" is the name of the product and "red" is its colour.
Manufacturing Model
The term Manufacturing Model has been used to define the information model which describes the manufacturing processes, resources and strategies of a manufacturing firm. This information model aims to provide a consistent source of manufacturing information to both users and applications and is key to the successful CAE support of simultaneous engineering. The Manufacturing Model has been defined and partially implemented by the MOSES research group in order to demonstrate that the manufacturing capability of a particular enterprise can be reliably represented. This Manufacturing Model has four levels based on a de-facto standard (i.e. Factory, Shop, Cell,
Station) and has been defined independently from any application. The Manufacturing Model is being implemented in the object oriented database DEC Object/DB.
The Manufacturing Model describes and captures the information about the manufacturing situation of a company in terms of its manufacturing facility and capabilities at different levels of abstraction. As the Manufacturing Model will represent the detailed manufacturing capability of an enterprise, and its current manufacturing status, this model will support the formulation of new and better manufacturing business strategies, will facilitate the development of factory models and will potentially be a useful source of information for real time production control applications.
The representation of structured resources and processes allows us to have reliable representation of the manufacturing facilities and their capabilities in terms of process technology and equipment. In addition to this type of information, there is a need to represent the manufacturing strategies, because the strategies are decisions made on the use and the organization of resources and processes (e.g. constraints imposed on the use of a certain type of resource or process). There are two types of decisions which make possible the formulation of manufacturing strategies: decisions made over time which define the structure, capacity and technology of the facilities, and the day to day decisions which determine how to use the facilities and related processes. In the Manufacturing Model, strategies will represent how the resources and processes are structured and used to support the realization of the manufacturing function in order to achieve the manufacturing objectives of a company.
The MOSES group consider formal methods for the description of system concepts and components to be essential for common understanding between developers and system users. A CAE Reference Model is being researched that is based on the Referenced Model for Open Distributed Processing (RM-ODP) and is set into the context of the
CIM-OSA architecture. The RM-ODP provides a framework to support the development of existing and new CAE systems by establishing a generic set of viewpoints: enterprise, information, computation, engineering and technology. To guide the development of the Manufacturing Model within the framework of the RM-ODP, the
Booch Object Oriented Methodology has been used. The Booch Methodology concepts can be mapped adequately into the object oriented concepts defined by the ODP reference model at the information and computation viewpoints.

Type 1
In order to exercise and prove the worth of the Manufacturing Model an application is being developed that will undertake design for manufacture using information from both an evolving product model representation and the manufacturing model. The results of the analysis undertaken by the application are stored in the product model. A structure for such information is being researched as are the effects of undertaking design for manufacture, whilst a design is evolving, on process planning.
The Intermediate Demonstration took place on 1st March 1994 at Leeds. It was shown to:

The ACME reviewers (Dr. Susan Morrell, Adrian Dent, Peter Gould)

The ACME-selected independent reviewers (Dr. Alec Hope, David Alexander, Prof. Tony Medland)

A DTI representative (Peter Munday)

The project industrial collaborators
It was designed to show how the various workpackages of the project had progressed to date. A primary objective, however, was to demonstrate our work on Harmonization which involved providing an underlying software infrastructure running in a distributed hetergeneous environment as well as an integrated data modelling definition (see
Product Model and Manufacturing Model).
A diagram of the demonstration is shown here with grey circles representing the software applications written to demonstrate the various areas of research. This diagram can be interrogated for information by clicking on the relevant bit (eg, clicking on the database rectangle will result in information about the database used). After reading the information, click on the Back button at the bottom of the window to return to this diagram.
The Harmonization work package
Objective
The approach used to integrate models during ISS and presently in STEP involve creating a single integrated model.
The logistics of this approach mean that one person must coordinate the entire model. For this reason, as the model grows, the approach loses its viability. We intend to consider more practical approaches to the integration of models.
To realize or final demonstration the development of models and applications must be coordinated throughout their life-cycles.
Methodology
Harmonization involves the integration of models and applications. To achieve our final demonstration this harmonization must include their implementation in a single environment.
NOTE}: A single environment may include multiple computer programs and languages on a hetergeneous hardware platform. However, all elements of the environment must be linked in some way. Early in the project thought will be given to the nature of the software environment that is required to support the final demonstration.
Although software engineering issues (the lowest three levels of the ODP reference model) will not be addressed by the research programme they will have an impact on its outcome. To realize our final demonstration we will have to address issues of software design.

Type 1

Type 1
PAC Production Activity Model
While the MMCS model is very generic it is challenged by an even more generic model: the PAC (Production
Activity Control) model. The PAC model was developed within the ESPRIT Project 477 entitled COSIMA (Control
System for Integrated Manufacturing) [14].
One of the basic principles of PAC as shown in Fig. 4.3 is the recognition of five basic building blocks representing the functions required for production control: Scheduler, Dispatcher, Mover, Producer and Monitor. Communication between these building blocks is facilitated through the use of the Application Network which was developed as part of the project. This Application Network also supports message passing across different nodes thus providing the means to develop a distributed PAC system. MMCS and PAC models are limited to the shop and cell levels. A more global model for factory supervision and control was defined in the ESPRIT Project 932 to support decision making at all levels. This model is based on the NBS model and the GRAI model and uses an intelligent workcell controller concept. A controller (see Fig. 4.4) performs three basic tasks (Planning, Quality Control and Preventive
Maintenance). Various expert system tools have been developed to support these controllers.
The knowledge based, real-time control, reference model enforces the decision making aspect by introducing some important concepts from the GRAI model, such as the Decision Horizon/Period and the Decision Frame, etc. The implemented system becomes totally goal oriented by means of the use of a 'decision frame'. The ESPRIT Project
932 finds its sequel ina new project; ESPRIT Project 2434 in ESPRIT 2.
The ESPRIT Project 2434 is concerned with real-time controllers for distributed factory supervision. The results achieved in ESPRIT 932 were used directly in ESPRIT 2434. The objective of this latter project is to make modern production philosophies (OPT, JIT, LOP, etc.) available on the factory floor by delivering decision support to each relevant function of the factory using knowledge based software techniques.
[14] Browne, J., Harken, J., and Shivman, J., Production Management Systems, A CIM Perspective, Addison-
Wesley Publishing Company, Reading, Massachusetts (1988).
THE PROCOS-A/S SYSTEM
[1] Moss, S.P., 'A Management and Control Architecture for Factory-Floor Systems: From Concept to Reality,' Int. J.
Computer Integrated Manufacturing, Vol. 2, No. 2, pp. 106-113 (March-April 1989).

PWAF
Type 1
Plant with a Future
Caterpillar

Type 1
SEW-OSA Systems Engineering Workbench centered on CIMOSA
Systems Engineering Workbench - Open Systems Architecture
Loughborough University
Based on EXPRESS
The acronym SEW-OSA (i.e. "system engineering workbench centred on CIM-OSA") was given to the workbench due to its orientation, namely: (1) it aims to address the engineering of an enterprise from a systems perspective; (2) its underlying framework is structured chiefly on the formalism of CIM-OSA; (3) it aims to provide the level of lifecycle support of a workbench, consisting of integrated tools for automating the entire design process, which encapsulates: the steps to be followed during the process (i.e. a method); the constructs to be created and manipulated in order to formalise the design (i.e. a language); the considerations, analyses and decisions to be made at each step (i.e. a framework); and associated documentation of design activities.
A workbench (such as SEW-OSA) is necessary in order to enable the investigation of a plethora of integration
'problems' and possible 'solutions' 6 , by providing means of: (1) describing each problem and defining possible solutions through the application of a formal language; and (2) testing the solutions. These requirements lead, respectively, to the proposition of the two main capabilities for such a workbench, namely: a model-building capability and a model-enactment capability 7 (as shown in Figure 1). Basically, each class of capability is required to support more than one modeling level of CIM-OSA, in a way which bridges gaps that exists within and between these modelling levels. Such capabilities are required to enable graceful migration from a modelling description of
'what' the system should do to a description of 'how' the system should do it by means of the actions executed by its components. Indeed, an important contribution envisaged for these two capabilities is that of defining a method for the organised application of the architectures, where their amalgamation would be under the framework defined by
CIM-OSA.
Thus, SEW-OSA provides the first instance of an organised method for the application of CIM-OSA, by providing two classes of capability associated with its design methodology. At each state of the design methodology, constructs 8 are manipulated in the form of diagrams and templates, thereby providing a means of organising design information as it is created.

Partial Type 2
SSADM Structured Systems Analysis And Design Method
Another method dealing with information systems design is the SSADM (Structured Systems Analysis And Design
Method) developed in the UK by CCT (Centre Computer and Telecommunications Agency) in the early 1980's. It is the UK government's standard method for carrying out the systems analysis and design stages of an information technology project. SSADM has been traditionally used for the development of medium or large systems. However, one variant of SSADM is 'Micro SSADM' which is for small systems. SSADM starts from defining the information system strategy and then develops a feasibility study module. These are followed by requirements analysis, requirements specification, logical system specification and a final physical system design.

Type 1
TOVE Toronto Virtual Enterprise
Enterprise Integration Laboratory
University of Toronto
The goal of the TOVE project is fourfold: 1) to create a shared representation (aka ontology) of the enterprise that each agent in the distributed enterprise can jointly understand and use, 2) define the meaning of each description (aka semantics), 3) implement the semantics in a set of axioms that will enable TOVE to automatically deduce the answer to many "common sense" questions about the enterprise, and 4) define a symbology for depicting a concept in a graphical context. The model is multi-level spanning conceptual, generic and applications layers. The generic and applications layers all also stratified and composed of micro theories spanning, for example, activities, time, resources, constraints, etc. At the generic level. Critical to the TOVE effort is enabling the easy instantiation of the model for a particular enterprise TOVE models will be automatically created as a by product of the enterprise design function. TOVE is currently being built to model a computer manufacturer and an aerospace engineering firm.

VOICE
Much of GRAI-GIM are developed under the VOICE Program of ESPRIT.
Type 2
ESPRIT Projects 5510, 6682