- Email: [email protected]
Architectures for Integrating Manufacturing Activities and Enterprises
Copyright © IFAC 12th Triennial World Congress, Sydney, Australia, 1993
ARCHITECTURES FOR INTEGRATING MANUFACTURING ACTIVITIES AND ENTERPRISES T.J. Willlams, P. Hernus, J. Hrosvic, D. Cheng, G. Doumeingts, L. Nemes, J.L. Nevins, H. Vallesplr, J. Vllet<;tra and D. Zoetekouw ConJributions from other members of the IFAClIFIP Task Force on Architectures for Integrating Manufacturing Activities and Enterprises have been included in this paper.
Abstract. This paper is a summary of the major technical report (Williams et al. 1993) of the IFAC/IFIP Task Force on Architectures for Integrating Manufacturing Activities and Enterprises. It presents a synopsis of the investigations of pertinent architectures undertaken, and the findings generated relating to the suitability of various architectures for the integration task. It also presents the Task Force's recommendations for achieving a "complete" architecture in terms of the necessary capabilities by "completing" a currently available architecture. The Task Force also outlined how a "best" architecture could be achieved by selecting and combining the best features of the available architectures. K(~yw()rds.
enterprise reference architectures
TilE ENTERPRISE INTEGRATION PROBLEM
INTRODUCTION
THE FORMATION OF T1m TASK FORCE Enterprise integration is a strategy as well as a technology. It strives to achieve a pro-active, aware enterprise which is able to act responsively in a real-time adaptive mode to customer needs in a global way, and to be resilient to changes in the technological, economic, and social environment.
It was proposed during the 11th Triennial Congress of the International Federation of Automatic Control (IFAC) in 1!J90 that a lIew Working Group be formed in IFAC focussed on the topic "Control Architectures for Int.egrating Manufact.uring Activities and Enterprises." Further, it was recommended that this be a joint Task Force between the IFAC Manufacturing Technology and Computer Technical Committee and the IFI P Technical Committee for Computer Applications (TC-S). It wal> further suggested that the new group should also interface to the ISO TC 184/SCS/WGI, alld IEEE Control Society and IFAC TC on Theory project "Facing the Challenge of Computer Science in the IlIdustrial Area of Control." The Technical Board of I FAC and TC-S of I FIP appointed prof T. Williams to chair the Task Force, and approved the scope of the work.
An integrated enterprise coordinates its strategic, tactical and day-to-day decisions achieving this by implementing an efficient, timely information flow, and an organisation which allows the use of this information in an optimal way. An integrated enterprise needs to possess some further properties, such as maintainability and changeability of its own structure, and the efficient use and re-use of its available resources, including existing human skills, investments in production technology, and in information technology. There is burgeoning interest on the part of industry around the world in the potentials for overall information integration. Companies need technology to achieve the maximum benefits resulting from faster response to external occurrences and higher economic optimisation in the operation of their plants. This new technology has been evolving as a computer-based, control activating media hence the collection of parties involved, IFIP and IFAC. However, we hasten to say, enterprise integration is an area where the prime interest is the enterprise as a structure or organism in which information technology has a defined role together with other co-factors.
With an initial seven members (si lice illcreased to 24, both active and corresponding) the new group faced a daunting task - that of surveying the presently available architectures, recommending the best one or a small group of them, or failing this, to defille the requirements for a new, "hett.er" generic architecture to satisfy industry's needs. In addition, members were scattered world wide and meetings were possible only through travel sponsored by the members employers, there being no funds available for Task Force sponsorship. But, most important of all, there was no common understallding of the terms describing the architectures and the integration field in general, and
It ill clear that !!olu tion!! (even partial !lol ulion!!) to
every group developing a new architecture coined and
these ambitious goals will equally be complex and that no party can claim overall responsibility for the entire area.
defined its own terms in its own way. Thus, initial steps were haltillg at best.
883
THE PURPOSE OF THIS STUDY
THE ROLE OF REFERENCE A RCHITECTURES
This study is aiming at various audiences, including end users, funding agencies, consultants, managers, and researchers. One of the main goals of the work is to define the area, giving a taxonomy of the problems which then can be separately tackled.
The development of a system of integrated information flow and organisation - as required for the integrated enterprise - is a task which faces three major problems. First, the cost (and risk) of this development can be high if attempted without any previous experience. Second, skills required to perform integration projects are usually not all available within the user's organisation. Third, the developed new organisational and information structures may not be feasible or will be very brittle if not rooted in technologies generally available for the enterprise on the market (defying one of the major goals of the project) .
The Task Force wanted to create a snap-shot of the present activities in a new and potentially important field and define the usefulness of available approaches as well as define the roles that its co-founders (IFAC and IFIP), and funding agencies could take in developing these. In a situation where large research, and standardisation efforts are underway, and many products are announced each claiming solution to the integration problem there is little guidance on how to interpret these claims. Especially little help is available for deciding what is not feasible at the moment.
The idea behind developing enterprise reference arch itectures is that a large part of integration projects is in fact similar and common in every type of enterprise and thus could be captured, standardised and utilised instead of repeatedly developing it from scratch . Once standardised , generally accepted architectures can be supported by tools, methodologies, and a range of compatible products thus making the entire endeavour efficient in time and cost.
Users need criteria which should help select one or other of these solutions, and must be able to assess what to expect: the costs, benefits, and risks associated with the utilisation of integration technology. Because of its strategic importance, funding agencies, educational institutions and industry policy makers also need clear analysis of the situation.
The Task Force, on one of its first meetings, identified that there were in fact at least four types of common compon ents of enterprise integration projects which can be developed in a generic way. These components collected together and made available for enterprises could dramatically reduce the cost and complexity of integration projects. The elements are defined as follows.
The Task Force in its study attempts to give such analysis (Williams et al . 1993), the present article is a short exposition of the results.
DEFINITION OF TERMS. STUDY METHODS • System of models (descriptions) (sometimes referred to as architecture in the narrow sense) .
The study was carried out by a series of meetings of Task Force members and by the development of analytic tools that could be adopted by the Task Force for evaluating enterprise reference architectures.
Enterprise Reference Architectures(in the narrow sense) describe the integrated enterprise on a generic level. These are model syste ms proposed which describe, from various points of view, the integrated enterprise as it is going to function.
Given the large number of possible architectures a list of available architectures was compiled and three major ones were used as closer subjects of study.
Enterprise Reference Architectures (in the broad sense) : describe the enterprise in various stages of its development, with each stage possibly described from many points of view. The latter systems include the former as components.
Three analysis procedures were used:
• A Questionnaire was generated,
Such model systems identify areas where models can be developed and possibly standardised, similarly to the ways of the famous 7 layer ISO-OSI architecture for computer communication.
• Results of the questionnaire were compiled into matrices,
• Methodology, which is a set of proven guidelines, techniques, procedures which the end-user can follow in order to implement an enterprise integration policy as well as carry out integration projects within that policy. Methodologies usually are developed in conjunction with reference architectures.
• Target architectures were mapped onto one another (one to one mapping)
The matrices, once generated, appeared useful to help identify research issues, areas of potential standardisation, And Areas where results of other disciplines could be adopted . Some of these possibilities have been exploited and appear as conclusions here while still more could be drawn in further work to be pursued .
• Modelling methods and tools which make it possible to create (express), develop and analyse the above identifi ed models. Tools mayor may not 884
be directly associated with a particular methodology or reference architecture.
design, construction, etc. of the computing system, the communication system, and others comprising the overall system. Thus, the Type 1 architectures will become major tools, or aids to be included in the overall Type 2 architectures.
• Infrastructure, which is a system of underlying processing and communication functions deemed necessary for implementing the information integration of the enterprise.
CRITERIA FOR USER NEEDS. The ongoing study also showed that:
It is thus possible to assess solutions proposed by various groups in the above areas and point out what is and what is not provided by these. Furthermore the Task Force decided to identify how partial existing solutions may be combined to fully satisfy each of these aspects.
The most valuable architecture from the viewpoint of the user is that of Type 2 above, the one which shows the structure and relationship of all of the tasks involved in the concept, analysis, design, building, commissioning and operation of the desired integrated enterprise.
Architectures as defined above are targeted at diverse audiences such as consultants, designers of the enterprise (on the technical level) , and decision makers involved in the design and development of the enterprise including both internal and external projects .
This architecture should be accompanied by a methodology which shows the user how to accomplish all of the steps just noted . That is the architecture should not only model the project development process, it should also teach and guide the user how to carry out each step of that development process through the accompanying methodology.
SOME INITIAL FINDINGS THAT DEFINED THE PATH
The methodology should also specify or suggest computer based and other tools, techniques, etc. which will aid the above work.
As the Task Force members studied the available architectures two major groups of findings were evident:
Thus, the IFAC/IFIP Task Force on Architectures for Integrating Manufacturing Activities and Enterprises determined that the potential user of these architectures vitally needed instruction on the "how' to design, develop, implement and use manufacturing and enterprise integration . (It is not enough to just give descriptions or merely designs for the related computer system.) This became the second method of classification.
1. A classification of the available architectures in terms of the task each architecture attempted to answer, and
2. The needs of the users of these architectures in terms of how they wanted the architectures to help them or how the architecture would be used in the integration task.
CLASSIFICATION ACCORDING TO PURPOSE. There are a multitude of proposed architectures and models in both the open and proprietary literature which purport to illustrate, explain and guide the task of integrating manufacturing activities and enterprises. However, only a very few of these actually treat the "how" of enterprise integration as well as the "what" that is needed . The remainder concentrate on describing the structure of the computer control system involved itself and/or the interconnectivity of the various functions being carried out by it , i.e., the "what" only. It was therefore evide nt that all of these architectures could be classified into two types:
ARCHITECTURES WHICH DESCRIBE THE PROJECT LIFE CYCLE We found that only three of the many architectures of both types known to us, and which were initially accessible for evaluation, were suitable for the dual task just noted . These were: 1. The Open System Architecture for Computer Integrated Manufacturing - Cl M-OS A as developed by the European CIM Architecture Consortium (AMICE) under ESPRIT projects 688, 2422 and 5288 of the European Community. This work was initiated in 1984 (hereafter called CIM-OSA) (see Bibliography, CIM-OSA).
1. Those which describe the architecture or physical structure of some component or part of the integrated system comprising the factory, such as the computer system, the communications system, etc. These will be called Type 1 in the discussion to follow.
2. GRAI-GIM - the GRAI Integrated Methodology as developed by the GRAI Laboratory of the University of Bordeaux in France. This work resulted from production management studies initiated at the GRAI Laboratory as early as 1974. It has taken its current form since about 1984 (hereafter called GRAI-GIM) (see Bibliography, GRAI-GIM).
2. Those which present an architecture of the project itself which is needed to develop the integration i.e., those that illustrate the life history or life cycle of the project developing the integrated enterprise. These will be labelled as Type 2.
It should be noted in passing that a major step in the development of the integration project will be the
3.
885
The Purdue Enterprise Reference Architecture
and the related Purdue Methodology as developed at Purdue University as part of the work of the Industry - Purdue University Consortium for CIM. This latter work started formally in 1989 but bears on the Purdue Reference Model developed starting in 1986 and earlier work of the Purdue Laboratory for Applied Industrial Control dating back to the mid seventies (hereafter called Purdue) (see Bibliography, PURDUE)
and human points of view in an integrated way. 3. The knowledge which is necessary to design a system cannot be found in a single person; designing requires team work. 4. The initial status of the system is not a matter of chance; this initial status must therefore be taken into account in order to well understand under which specific constraints the system operates on the one hand and, on the other hand, to avoid the re-design of those parts of the system which are satisfactory. Because of today's economic situation, this point becomes more and more relevant; many industrial systems must evolve faster and faster but with a cost as low as possible (Doumeingts et. al 1992).
These then are the three architectures which were extensively examined by the Task Force and which are described in a technical report (Williams et al. 1993). Manufacturing integration is not automation and/or computer application per se, although computers and automation are usually involved in its implementation. Manufacturing or enterprise integration is the collection, reduction, storage and use of data (and/or information) from the business entity involved, plus its environment, in order to optimise the operation of the business entity as a whole according to the criteria established by that business entity's management. It must also include the integration of the raw material, intermediate and final product flows, as well as machine organisation, to further the enterprise optimisation possible. Because of this important factor, the Task Force early decided to remove the word "control" from its title in order not to obscure the larger, true picture of the integration field .
'The term "methodology" means a consistent set of components which are:
1. The reference model (as defined in the broader sense) globally and generically showing the structure of the project to create an integrated enterprise or unit. 2. One or more modelling formalisms enabling the build up of the model in order to study alld evaluate it. 3. A structured approach for the overall program leading step by step from an existing system to a future system taking into account evolution objectives and specific constraints.
The Task Force was extremely fortunate in that its membership contained representatives from the groups developing each of the candidate architectures listed above. Thus they had access to information and insight into the details, definitions, future plans, etc. concerning these architectures not available to any other comparable group to our knowledge.
4. Performance evaluation criteria with which the system can be evaluated in relation to several points of view (economics, reliabili ty, etc.) . 'Generally speaking, a structured approach is a set of steps to be followed to solve a problem. Within the framework of an integrated manufacturing system design methodology, the structured approach must cover all of the life cycle of the integration project which is split into states (analysis, design, development, implementation, operation). Every step of the methodology must be precisely defined and based on a standardised project structure giving the set of actors for which the work must be precisely d efined as well . 'Defining very precisely all steps which are required to go from concept to specification to implementation is essential. During each step some models are built and checked. The consistency of these models and results for each step must be constantly checked." (Doumeingts et. al 1992)
ESTABLISHING JUDGING CRITERIA "Any organisation planning to carry out a programme in computer integrated manufacturing, or more generally enterprise integration, has a set of very special needs in order to be able to accomplish its desired tasks. 'An Integrated Manufacturing System solution cannot be bought off the shelf; each firm must be involved in devising its own, which explains why methodologies must be made available so that CIM systems can be built.
The above statement characterises very succinctly the industrial requirements which needed to be considered by the Task Force Thus evaluating manufacturing integration architectures must consider not only the "what" of integration but also the "how" of integration as well . That is, how integration is accomplished in terms of the development of the whole enterprise system, that is including service provided by the enterprise (henceforth "customer service"), human relationships, and information technology as a whole.
'Designing a CIM system meets with a number of difficulties: 1. The system is extremely complex, so some special techniques must be used to understand this complexity in order to efficiently act on it and to define the possible intervention area of every operator related to their skills.
2. The system must take into account not only the technical points of view but also the economic, social,
886
CIM-OSA
EVALUATION METHODS DEVELOPED AND USED
1. The AMICE Consortium which initially developed CIM-OSA is to be highly corn mended for their early decision to be as formal as possible in their definition and description of all aspects of this architecture. This was done with the ultimate aim of achieving complete computer executability of all constructs, models, tools, techniques, etc, associated with the architecture.
Once the Task Force had decided that the major elements of its technical charge involved an evaluation of how well the three candidate architectures (CIM-OSA, GRAI-GIM and Purdue) fulfilled the needs for "integrating manufacturing activities and enterprises", the major task facing them was to choose the method(s) of evaluation to be used . The methods used in the detailed study (Williams et at. 1993) have only been summarised here:
2. The AMICE Consortium initially restricted the scope of CIM-OSA to the discrete manufacturing field and in addition imposed a further restriction in the form of its application only to those factories where each element of the subject plant's production floor equipment has its own local control system . That is, CIM-OSA studies only what is termed supervisory control and production management by other groups. The dynamic direct control of plant floor production units is handled only by the production unit's own built-in local controllers which are fed general operating instructions by the CIM-OSA system.
METHOD 1 - QUESTIONNAIRES An extensive questionnaire was developed and adopted after a lengthy process of refinement to cover all important ramifications of the requirements for these architectures. This would then be completed by the groups developing each separate architecture a.nd reviewed by the Task Force before being adopted for its report. A shorter questionnaire was also developed a.nd a Short Form Evaluation Questionnaire for Integration Reference Architectures was accepted and completed for all three architectures.
3. CIM-OSA does have and describes a the CIM system . However, it has not extended this description to become a true methodology yet for the use of this architecture by the user organisation's planning and development group for carrying out plant integration studies and programs.
METHOD 2 - MAPPINGS, ONE ON ONE At the first meeting in Bordeaux it was also suggested that a method be developed to "map" the characteristics and capabilities of each of the architectures onto a suitable representation of the corresponding characteristics and capabilities of the others (a total of six, hopefully graphical presentations, to cover the full spectrum of characteristics and capabilities).
4. Because of its declared goal of formality and eventual computer executability, CIM-OSA is the most formally described of the three candidate architectures. This has unfortunately imposed a burden on its readability and understandability for those potential users who do not have a computer science or related ed ucational background.
A diagram representing the Life Cycle for each architecture was used for the framework desired. These were suitably modified to include any capabilities missing in that particular architecture if necessary. Representations of CIM-OSA and PURDUE and vice versa and the related GRAI-GIM representations were then developed.
5. In order to increase the potential for executability, CIM-OSA is developing-two major environments, the Enterprise Engineering Environment and the Enterprise Operation Environment and a set of specified system services known as the Integrating Infrastructure . The first of these environments formalises the development of enterprise models and their conversion to working programs for the system. The second formalises the testing, proving and acceptance of the resulting programs as new additions or changes to the operating enterprise information systems. The Infrastructure defines how all such programs, as just noted, work together to carry out the overall functions of the integrated computer system .
METHOD S - MAPPING AGAINST A SET OF REQUIREMENTS A different form of mapping diagram, that based on a Matrix of Requirements or Needs was created. A set of trial mappings for each architecture were then presented to representatives of CIM-OSA and GRAIGIM and accepted by them.
6. CIM-OSA is the most thoroughly studied of the candidate architectures and the most widely published. It is also the one which has received the most attention concerning potential standardisation as an International Standard.
CONCLUSIONS REGARDING EACH CANDIDATE ARCHITECTURE
GRAI-GIM Conclusions concerning each candidate architecture are summarised as developed by the work of the Task Force or derived from the work of other groups:
1. GRAI-GIM has a well developed and described methodology for the application of its architecture and
887
presentation of its overall structure and layered phases for program development. Its associated methodology is complete, particularly in its discussion of the planning phases of an integration progra.mme. The Purdue Architecture's structure approximates the way many plant workers think of their factories and their operations.
related tools and technology for the development of an integration program by the user through the specification stages. 2. GRAI-GIM, in its descriptive documentation has generally been confined to discussions of the development of the computer system and related hardware and software to implement the factory integration desired . Such a restriction is not inherent in the methodology or necessarily intended by the developers.
3. The split of the Implementation View of the Purdue Architecture into Information System, Human and Organisational, and Manufacturing Equipment (or Customer Service) considerations permits the Purdue Methodology and the subsequent enterprise integration programmes to undertake an extensive discussion of all of the human aspects of the enterprise involved as they affect enterprise integration.
3. Although not specifically so stated, GRAI-GIM discussions, descriptions, case studies, etc, are all todate confined to the discrete manufacturing field . 4. GRAI-GIM has also confined itself to date in its life cycle methodology to the concept, analysis, specification and detailed design phases of the overall development and use of an integration system for an enterprise. There is no discussion as yet of the construction, testing and commissioning of a system or of its continued development while in use. There is nothing inherent in the GRAI-GIM system itself which would prevent its ready expansion to cover these additional phases or indeed to study other industries than discrete manufacturing.
4. Likewise the manufacturing (or customer service) equipment considerations pe rmit the details of the integration of material and energy flows, equipment layout optimisation and many other important factors in the overall enterprise integration system to be considered beyond those of information integration alone. 5. Purdue has shown its extendibility to cover all types of industries and indeed to cover all types of enterprises regardless of their individ ual mission and as a methodology is the most extensively documented of the three in its Purdue Implementation Procedures Manual.
5. Like CIM-OSA, GRAI-GIM treats the human worker as a resource in terms of the required skills and physical capability. Also like CIM-OSA there is no discussion of human relations, needed training programmes, union requirements, human organisation details, etc.
6. Purdue lacks the set of mathe matical modelling techniques necessary wh en an architecture is to be computer modelled . There is no built-in restriction adding these, and the architecture can be readily extended in this direction .
6. The GRAI Laboratory in producing GRAI-GIM has developed several tools and t echniques of potential wide use in enterprise integration studies such as the GRAI-GRID, GRAI-NET, ECOGRAI, the GRAI Model and others. They have also advanced the use of other tools and techniques developed by others such as MERISE, Petri Nets, etc.
GENERAL CONCLUSIONS REGARDING ALL THREE ARCHITECTURES
7. The philosophy of CIM and of the carrying out of a ClM development project as expressed by the GRAI-GIM descriptive documents is the best of three candidate architectures in terms of its adherence to the philosophy adopted by the Task Force.
1. Enterprise integration is a very complex and highly detailed endeavour . Similarly, the reference architectures which describe this endeavour are also complex and highly detailed . As a result none of the candidate architectures and associated methodologies are, as yet, completely developed, described and documented . However, in each case the path to their ultimate completion is clear either from the work of the architectural development group themselves and their future plans or from the associated work of other groups, including this Task Force.
8. GRAI-GIM is intermediate between CIM-OSA and Purdue in terms of the degree of formality implied and used and the consequent ease of understanding by the non-computer science educated user.
PURDUE
2. Each of the studied architectures and their associated methodologies can be extended by the original development groups or others to become a complete architecture and methodology for guiding enterprise integration programs from initial conception to their actual construction and use. In our Recommendations section here we outline one method by which this could be accomplished in each case.
1. The Purdue Enterprise Reference Architecture and its associated Methodology are an informally described means for leading a user's application group through all of the phases of an enterprise integration programme from initial concept through use to final plant obsolescence.
2. As a.n informa.l description it is the easiest to understand by non-computer science educated users. This is especially true because of its easy-to-grasp graphical
3. It would also be possible, and perhaps more re888
warding, to combine the best parts of each of the candidate architectures to capture the possible synergy in a new or combined architecture. In the Recommendations section we have proposed one. way by which the combined architecture could be developed. We have also pointed out those additional features which could be added to each architecture or the combined architecture to make them or it even more helpful to the user applications group which will be the ultimate customers of this work .
associated methodology. This should then allow the development of a computer executable form of the architecture, compatible with current "open systems" trends in computer usage. Items 2a-2d need to be confirmed by the results of the Case Study of Item 1 above. This report recommends a possible pathway by which this might be achieved for each of the candidate architectures and for a possible "joint" one. Such work should be carried out for at least one complete architecture,
RECOMMENDATIONS FOR FUTURE WORK We further recommend that the above work should, if possible, be carried out in the framework of an International Research Programme and it is to be determined how to plan, finance and implement such a programme.
Our general recommendations are as follows : 1. A funded Task Force program should be initiated which will carry out a Case Study on the three candidate architectures. A specific enterprise should be chosen (or defined) after which each of the architectural development organisations (of the candidate architectures) will be asked to provide an architectural description of that enterprise in terms of their specific architecture.
3. It is our observation that user groups in attempting enterprise integration feel overwhelmed by the mass of detail necessary to plan and carry out the integration project or programme desired. Because of the size and complexity of the enterprises attacked in these studies the actual complexity involved is probably unavoidable (Vaes, 1991) . Therefore , the necessity which should be satisfied is to reduce the "apparent" complexity involved. Some ways by which the above might be accomplished are:
Such study would be necessary for a detailed validation of the conclusions as drawn by the Task Force and give further insight into the applicability of the three candidate architectures.
a. Development of instructional manuals of the methodology and, wherever possible, of the architecture itself, which are easily understood by those not formally trained in computer science, and related technologies.
2. The study by the Task Force init.ially concluded that while neither of the candidate archit.ectures was yet complete in terms of our definition of ultimate usability, there was no indication of unsurmountable difficulty in completing any of them if the initial development group or some follow-on group should decide on carry out this work. To reiterate, our definition of completeness includes the following :
b. Publication of comprehensive case studies using the architecture and methodology while thoroughly explaining each step of the process and its results achieved .
a . In addition to modelling the proposed computer based system of decisions, sched uling, and control (needed for information integration - under whatever title it is described), the architecture should also model the structure and progress of the project or programme under which the task of integration of the enterprise, factory, or unit involved is achieved.
c. Continued development of the possibilities and techniques of "configuring" generic, open structures ("integration platforms") underlying the implementation of scheduling, and control systems, for communication systems, application programs, databases, and tools for enterprise engineering. These techniques should ease the need for reprogramming all or large parts of the systems for each new business function.
Along with showing the structural model of b. the project or programme required, the architecture should have associated with it a methodology whose description will serve to instruct th e user organisation's planning and implementation groups in achieving the desired integration of information, and of the flow of materials and products .
d . De velop as many as possible example or standard system structures (generic or partial models). These could be parametrised, extended or modified by the user groups to easily generate models as needed for their own systems. By this the necessary collection of the massive detail involved can be circumvented and the quality of the resulting individual models improved . A compendium of already available such models would be most useful to develop.
c. In addition to instructions, the methodology should include aids (computerised or otherwise) which can be prescribed, or developed to whatever degree possible, to assist the user's planning and implementation group in their task of achieving the integration desired.
e . Search for techniques that reduce the apparent complexity of the architectures as experienced in the application context. The difficulty of dealing with the amount of data generated in realistic applications prompted researchers to look for simplification tech-
d. The pathway should be clear to achieving formally defined syntax and semantics for the models, techniques and tools involved in the architecture and its 889
ology to handle the human relations aspects could be readily included.
niques of presentation and analysis to reduce apparent complexity, e.g., Precedence Matrix techniques (Eppinger et al., 1992) . Similar techniques could contribute to the ease of use of the reference architectures studied.
2. Likewise the means for including the details of the modelling and applications of enterprise system construction, check-out, commissioning, etc, could be readily added . Similarly the technology for continuous improvement of the operations methodology applied to the working factory throughout its operational life could also be added for a complete life history treatment .
RECOMMENDATIONS FOR FURTHER DEVELOPMENT OF EACH ARCHITECTURE AND ITS ASSOCIATED METHODOLOGY
PURDUE
The case study recommended earlier should specifically address the following points concerning each of the three candidate architectures:
The Purdue Enterprise Reference Architecture and its associated Methodology are the most informal of the three candidate architectures in their presentation. In view of the strongly expressed need for formality in order to achieve eventual executability of the architectural constructs, this appears to be the first need in further development of the Purdue offerings. This can be accomplished in several ways either separately or as a joint undertaking. Some of these are:
CIM-OSA In view of the findings of the Task Force and the general recommendations just above, it is offered that CIM-OSA could be developed into a so-called complete architecture as follows :
I. Where applicable, employ ready developed by CIM-OSA appropriate credit as to source. the Integrating Infrastructure GRAI GRID of GRAI-GIM
1. Make it clear in the description of the use of the CIM-OSA Modelling Framework that it applies to studies of the manufacturing equipment systems and of the human and organisational systems of the enterprise as well as to the information integration systems (the computer-based systems).
the methodologies aland GRAI-GIM, with Possible examples are of CIM-OSA and the
2. Where the required technologies do not already exist, in the companion architectures or other fields, develop them as needed .
2. Prepare a companion document to the existing descriptions of the CIM-OSA Architecture itself to encapsulate the extensive discussion of the use of the CIM-OSA "life cycle". This would provide the methodology to aid user groups who plan to employ CIM-OSA for their e nterprise integ rating planning and development projects or programmes . This documented methodology should also describe the needs and methodology of the identification and concept layers present in the other two architectures but missing, in description at least, in CIM-OSA.
Other developments which would be helpful to Purdue would be as follows: 1. Purdue does not as yet require specific designated tools or techniques at each step of the development of an integration system, as called for by CIM-OSA. It would greatly aid the user if work were carried out to classify, evaluate and document the relative applicability of each of the multitude of computer-based, graphical and interactive analysis tools available. This applies to every stage of the analysis, design, construction, check-out, and operation of the integration systems . Those which are especially applicable could be formalised, if not already accomplished, for that application.
3. Remove the self-imposed restriction of CIM-OSA to discrete manufacturing systems. While all examples to date only treat such manufacturing systems, the Task Force could find no inherent limitations in Cl M-OS A that would prevent its expansion to include systems in other industries or, indeed, in enterprises in general.
2. There is currently a major lack of formality in the specification and development of human and organisational systems. This involves the specification of the innovative tasks which must be carried out by humans, as well as the specifications of the appropriate organisations to promote the accomplishments of human based tasks. Also it should include the best ways of assuring the availability of the necessary human skills as needed . Anything which can be accomplished in this area would be extremely valuable for future integration projects.
GRAl-GIM Like CIM-OSA, GRAI-GIM is unnecessarily restricted, in the opinion of th e Task Force, to the discrete manufacturing field. The following are other suggestions for "completing" GRAI-GIM in the ways developed by the Task Fore:
1. GRAI-GIM is limited in its discussion to the manu3. Formalisation of the corresponding tasks in the manufacturing or customer service equipment area on
facturing equipment and the control system. This is a self imposed limitation of treatment since the method-
890
the other hand is quite straight-forward in concept. The problem here is the extremely wide range of devices, etc., which are needed and thus the corresponding massive endeavour needed to impose formality on this area.
and compatibility as described in the proposals and recommendations of this study. 2. The contemplated work must not conflict with the ongoing international standardisation efforts where these apply, and 3. Sufficient funds can be made available to have a small dedicated group to work on these proposals (and particularly the case study) to assure their completion.
COMBINATION OF EXISTING A RCHITECTURES In view of the strong points of each architecture as brought out in the several evaluations carried out by the Task Force, the following is one possible consolidation of the three studied architectures which might be proposed. The case study should provide further insight as to the correctness of these proposals.
A POSSIBLE FUTURE ROADMAP FOR PROMOTION OF THE FIELD OF ENTERPRISE INTEGRATION USEFUL FOR FUNDING AGENCIES
1. Use the structure of the Purdue Enterprise Reference Architecture to guide the overall programme since it seems to be the one which is most easily understood and accepted by non-computer science educated personnel in user plan ning and development groups.
The work of the IFAC/IFIP Task Force on Architectures for Integrating Manufacturing Activities and Enterprises, as recorded here, has shown that the needs of the users for their acceptance and application of their Integration Architecture in priority order are as follows :
2. Use the CIM-OSA Modelling Framework to supplement the Purdue data flow and material and energy flow analysis method. These include the generic task lists described there. These are necessary for establishing the functional requirements for the proposed overall system.
1. A "complete" Architecture is necessary.
2. An associated Methodology for applying the Architecture and its related models, techniques and tools in the easiest possible manner for User Application Groups must be available.
3. Use the GRAI-GIM Modelling Framework as a reference check if needed to assure the completeness of the requirements.
3. Standardisation of the Architectures and their associated generic models, techniques and tools is very important as a promoter of their wide acceptability and use. It should be emphasized that it is the wide acceptability rather than standardisation per se which is the important criteria here.
Complementing (or combination of) existing methods and tools: 1. In the Functional Design or Specification Level, apply the GRAI-GIM, GRAI GRID and GRAI NET, and adopt the formality of the CIM-OSA Integrating Infrastructure, Integrated Engineering Environment and Integrated Operational Environment as templates for the design.
4. There is a general lack of knowledge and appreciation of the capabilities of integrating systems to improve the productivity and economic return of enterprises of all types in the minds of potential users everywhere.
2. Formalisation of the Human and Organisational and of the Manufacturing or Customer Service Equipment areas for the Purdlle Architecture.
This is due to the explosion of progress in computer and information systems technology in all areas of application in recent years and to the inability of the user community to keep abreast of these burgeoning capabilities and the associated benefits of their use. Thus any methods (case studies, training programs, easier to learn and use application methods, additional computer-aided tools, etc.) which promote knowledge and acceptance in the field are vitally important.
3. Adopt either the Cl M-OSA Integrating Infrastructure (lIS) or the Purdue Manifestation and Operation Layers or Phases and complete them with the necessary formalisation.
FUNDING AND COOPERATION The Task Force believes that its current evaluation work has outlined what is necessary to achieve a "complete" architecture . Likewise we believe that the requirements for a suitable methodology have also been defined here, and in the available literature.
It must be stressed that the present proposals and recommendations crucially depend on the following conditions: These proposa.ls a.nd rccommenda.Lions a.re supported by the development organisations of the candidate architectures in terms of developing the respective architectures so as to finally achieve completeness
1.
Thus the Task Force would strongly encourage current and future funding organisations to support the needs listed in this section .
891
PROPOSAL FOR FUTURE WORK OF THE TASK FORCE
BIBLIOGRAPHY AND REFERENCES
The major distinguishing feature of the Task Force in its work in evaluating and promoting the field of architectures for enterprise integration has been the fact that its membership included representatives of each of the major groups active in this field . Thus we are in a unique position to report on and hopefully guide the future development of this vitally important field for the future . Therefore, any future continuation of the Task Force and its work should continue to build on and exploit this unique characteristic and capability.
GENERAL Williams et al (1993), IFAC/IFIP Task Force on Architectures for Integrating Manufacturing Activities and Enterprises, Architectures for Integrating Manufacturing Activities and Enterprises, Technical Report, Theodore J. Williams, Editor, Purdue University, West Lafayette, Indiana, USA (March 1993). CIM-OSA AMICE Consortium (1989), Open System Architecture for CIM Research Reports of ESPRIT Project 688 Volume 1, Springer Verlag, Berlin.
Since the Task Force believes its work during this past triennium has effectively answered the challenge of its initial Scope as presented by its organisers, a new Scope and Plan of Work is needed. Recommendations for these are presented below .
AMICE Consortium , (1992) AMICE: CIM-OSA , ESPRIT Project 5288, Milestone M-2 , AD2 .0 Volume 2, Architecture Description , Document R0443/1, Consortium AMICE, Brussels, Belgium, (August 24, 1992) .
TASKS TO BE UNDERTAKEN 1. Monitoring and initiation , development and execution of the Case Study and other development work proposed herein . It is presumed that this work will be carried out by personnel other then the Task Force members because of the degree of involvement and dedication necessary for their accomplishment.
Beekman, D., (March-April 1989) "CIM-OSA: Computer Integrated Manufacturing - Open System Architecture, " Int . J . Computer Integrated Manufacturing, Vol. 2, No. 2, 94-105. CEN/CENELEC (April 18, 1990), (The Joint European Standards Organisation), European Prestandard Env 40003, " Computer Integrated Manufacturing, System Architecture, Framework for Enterprise Modelling," Berlin , Germany.
2. Work toward the development of one or more complete or open enterprise integration reference architecture(s) . This can be accomplished by, (a) fleshing out either of the current candidate architectures in a manner similar to that proposed in the 1993 Report of the Task Force (Williams et al. 1993) , or (b) by consolidating them into a best candidate similar to another proposal also made by the Task force in its report.
ESPRIT (1988) , Project 688, AMICE Open System Architecture for CIM, Springer-Verlag, Berlin. ESPRIT (1991), Consortium AMICE Open system Architecture, CIM-OSA, AD 1.0, Architecture Description ESPRIT Consortium AMICE, Brussels, Belgium.
3. Evaluate the relationships of the currently available analysis, design and implementation models, techniques and tools and recommend a selection of these to be incorporated with the complete architecture(s) proposed .
Jorysz, H. R. and Vernadat, F. B., (1990) "CIMOSA Part 1: Total Enterprise Modelling and Function View ," Int. J. Computer Integrated Manufacturing, Vol. 3, Nos. 3 and 4, pp. 144-156.
4. Where appropriate recommend standards for models, techniques, and/or tools which will help promote the acceptance of the architecture(s) and associated methodology(ies ).
Jorysz, H.R. and Vernadat, F . B. , (1990) "CIM-OSA Part 2: Information View ," Int. J . Computer Integrated Manufacturing, Vot. Nos. 3 and 4, 157-167.
5. Develop an on-going list of needed but primarily unavailable models, techniques and tools which would greatly aid the field of enterprise integration and encourage potential developer organisations to undertake this work.
3
Klittich, M., (1990) "CIM-OSA Part 3: CIMThe OperaOSA Integrating Infrastructure tional Basis for Integrated Manufacturing Systems," Int. J . Computer Integrated Manufacturing, Vol. 3 Nos. 3 and 4, 168-180.
6. Prepare syllabuses for innovative training programs needed in the area of enterprise integration and the details of integrating systems. As there are already many available programs for training in this area, only new, innovative ideas are worth promoting by an organisation like the Task Force.
Vaes, P., (1991) , "CIM-OSA Case Study of the IC Route," AT&T Network Systems Nederland, BV., Hilversum, the Netherlands.
The Task Force would benefit from the inclusion of more members from the direct user community of enterprise reference architectures.
GRAI-GIM Doumeingts, G ., (November 1984) Methode GRAI :
892
Dr. Gustav 1. Oiling, Chrysler Motors Corporation, Highland Park, MI, USA Ing. Marco Tomljanovich, ITALCAD Tecnologic e Sistemi S.P.A., Rome, Italy Dr. Bruno Vallespir, Universite de Bordeaux 1, Talence, France Dr. David Cheng Universite de Bordeaux 1, Talence, France Ing. lakob Vlietstra, McKinleyville, CA, USA Ing. Dick Zoetekouw, AT&T Network Systems Nederland BV, Hilversum, The Netherlands
Methode de Conception des Systemes de Productique. These d Etat en Automatique, Universite de Bordeaux 1, Bordeaux, France. Doumeingts, G., Vallespir, B., Darricar, D. and Roboam, M., (December 1987), "Design Methodology for Advanced Manufacturing Systems," Computers in Industry, Vol. 9 No. 4, 271-296 Doumeingts, G ., Vallespir, B., Zanettin, M., and Chen, D., (May 1992), GIM, GRAI Integrated Methodology, A Methodology for Designing CIM Systems, Version 1.0, Unnumbered Report, LAP /GRAI, University Bordeaux 1, Bordeaux, France.
CORRESPONDING MEMBERS
PURDUE
Mr. Randy Aranguren, IBM Corporation, Rochester, MN USA Professor Karl-lohan Astrom, Lund Institute of Technology, Sweden Dr. Albert Benveniste, IRISA-INRIA Rennes, France Professor Chen Yuliu, Tsinghua University, Beijing, Peopl. Rep. of China Professor Mark S. Fox, University of Toronto, Canada Dr. Yoshiro Fukuda, Technical Research Institute, JSPMI, Tokyo, Japan Dr. Zengjin Han, Tsinghua University, Beijing, Peopl. Rep. of China. Professor Lennart Ljung, Linkoping University, Linkoping, Sweden Dr. G. Kovacs, Hungarian Academy of Sciences, Budapest, Hungary Professor Leo Motus, Estonian Academy of Sciences, Estonia Professor Michael G. Rodd, University College of Swansea, University of Wales, United Kingdom
Industry-University Consortium (June 1992), Purdue Laboratory for Applied Industrial Control, An Implementation Procedures Manual for Developing Master Plans for Computer Integrated Manufacturing, Report Number 155, Purdue Lab . for Applied Industrial Control, Purdue University, West Lafayette, IN Williams, T . J., (1989) Editor, A Reference Model for Computer Integrated Manufacturing (CIM), A Description From the Viewpoint of Industrial Automation, Minutes, CIM Reference Model Committee, International Purdue Workshop on Industrial Computer Systems, Purdue University, West Lafayette, IN (1988), Instrument Society of America, Research Triangle Park, NC Williams, T. J., (1992) The Purdue Enterprise Reference Architecture, Instrument Society of America, Research Triangle Park, NC Eppinger.,S.D., Whitney, Di..Ei.., Gebels, D.A. (1992) "Organizing the Tasks in Complex Design Projects: Development of Tools to Represent Design Procedures," 1992 NSF Design and Manufacturing System Conference, Atlanta Georgia January 1992.
MEMBERS FORCE
OF THE TASK
Prof. Theodore 1. Williams, chairman, Purdue University, West Lafayette, IN, USA ACTIVE MEMBERS Dr. Peter Bernus, Griffith University, Nathan, (Brisbane) Queensland, Australia Mr. lim Brosvic, Honeywell, Inc . Phoenix, AZ 85023, USA Profeuor Guy Doumeingts, Universite de Bordeaux 1, Talence, France Mr. Fadi G. Fadel, University of Toronto, Canada Dr. Aisushi Inamoto, Mitsubishi Electric Corporation, Tokyo, Japan Dr. La3zlo Nemes, Division of Manufacturing Technology, CSIRO, Preston, Victoria 3072, Australia Mr. lames L. Nevins, 26 Sunset Dr., Burlington,MA,USA
893
ARCHITECTURES FOR INTEGRATING MANUFACTURING ACTIVITIES AND ENTERPRISES T.J. Willlams, P. Hernus, J. Hrosvic, D. Cheng, G. Doumeingts, L. Nemes, J.L. Nevins, H. Vallesplr, J. Vllet<;tra and D. Zoetekouw ConJributions from other members of the IFAClIFIP Task Force on Architectures for Integrating Manufacturing Activities and Enterprises have been included in this paper.
Abstract. This paper is a summary of the major technical report (Williams et al. 1993) of the IFAC/IFIP Task Force on Architectures for Integrating Manufacturing Activities and Enterprises. It presents a synopsis of the investigations of pertinent architectures undertaken, and the findings generated relating to the suitability of various architectures for the integration task. It also presents the Task Force's recommendations for achieving a "complete" architecture in terms of the necessary capabilities by "completing" a currently available architecture. The Task Force also outlined how a "best" architecture could be achieved by selecting and combining the best features of the available architectures. K(~yw()rds.
enterprise reference architectures
TilE ENTERPRISE INTEGRATION PROBLEM
INTRODUCTION
THE FORMATION OF T1m TASK FORCE Enterprise integration is a strategy as well as a technology. It strives to achieve a pro-active, aware enterprise which is able to act responsively in a real-time adaptive mode to customer needs in a global way, and to be resilient to changes in the technological, economic, and social environment.
It was proposed during the 11th Triennial Congress of the International Federation of Automatic Control (IFAC) in 1!J90 that a lIew Working Group be formed in IFAC focussed on the topic "Control Architectures for Int.egrating Manufact.uring Activities and Enterprises." Further, it was recommended that this be a joint Task Force between the IFAC Manufacturing Technology and Computer Technical Committee and the IFI P Technical Committee for Computer Applications (TC-S). It wal> further suggested that the new group should also interface to the ISO TC 184/SCS/WGI, alld IEEE Control Society and IFAC TC on Theory project "Facing the Challenge of Computer Science in the IlIdustrial Area of Control." The Technical Board of I FAC and TC-S of I FIP appointed prof T. Williams to chair the Task Force, and approved the scope of the work.
An integrated enterprise coordinates its strategic, tactical and day-to-day decisions achieving this by implementing an efficient, timely information flow, and an organisation which allows the use of this information in an optimal way. An integrated enterprise needs to possess some further properties, such as maintainability and changeability of its own structure, and the efficient use and re-use of its available resources, including existing human skills, investments in production technology, and in information technology. There is burgeoning interest on the part of industry around the world in the potentials for overall information integration. Companies need technology to achieve the maximum benefits resulting from faster response to external occurrences and higher economic optimisation in the operation of their plants. This new technology has been evolving as a computer-based, control activating media hence the collection of parties involved, IFIP and IFAC. However, we hasten to say, enterprise integration is an area where the prime interest is the enterprise as a structure or organism in which information technology has a defined role together with other co-factors.
With an initial seven members (si lice illcreased to 24, both active and corresponding) the new group faced a daunting task - that of surveying the presently available architectures, recommending the best one or a small group of them, or failing this, to defille the requirements for a new, "hett.er" generic architecture to satisfy industry's needs. In addition, members were scattered world wide and meetings were possible only through travel sponsored by the members employers, there being no funds available for Task Force sponsorship. But, most important of all, there was no common understallding of the terms describing the architectures and the integration field in general, and
It ill clear that !!olu tion!! (even partial !lol ulion!!) to
every group developing a new architecture coined and
these ambitious goals will equally be complex and that no party can claim overall responsibility for the entire area.
defined its own terms in its own way. Thus, initial steps were haltillg at best.
883
THE PURPOSE OF THIS STUDY
THE ROLE OF REFERENCE A RCHITECTURES
This study is aiming at various audiences, including end users, funding agencies, consultants, managers, and researchers. One of the main goals of the work is to define the area, giving a taxonomy of the problems which then can be separately tackled.
The development of a system of integrated information flow and organisation - as required for the integrated enterprise - is a task which faces three major problems. First, the cost (and risk) of this development can be high if attempted without any previous experience. Second, skills required to perform integration projects are usually not all available within the user's organisation. Third, the developed new organisational and information structures may not be feasible or will be very brittle if not rooted in technologies generally available for the enterprise on the market (defying one of the major goals of the project) .
The Task Force wanted to create a snap-shot of the present activities in a new and potentially important field and define the usefulness of available approaches as well as define the roles that its co-founders (IFAC and IFIP), and funding agencies could take in developing these. In a situation where large research, and standardisation efforts are underway, and many products are announced each claiming solution to the integration problem there is little guidance on how to interpret these claims. Especially little help is available for deciding what is not feasible at the moment.
The idea behind developing enterprise reference arch itectures is that a large part of integration projects is in fact similar and common in every type of enterprise and thus could be captured, standardised and utilised instead of repeatedly developing it from scratch . Once standardised , generally accepted architectures can be supported by tools, methodologies, and a range of compatible products thus making the entire endeavour efficient in time and cost.
Users need criteria which should help select one or other of these solutions, and must be able to assess what to expect: the costs, benefits, and risks associated with the utilisation of integration technology. Because of its strategic importance, funding agencies, educational institutions and industry policy makers also need clear analysis of the situation.
The Task Force, on one of its first meetings, identified that there were in fact at least four types of common compon ents of enterprise integration projects which can be developed in a generic way. These components collected together and made available for enterprises could dramatically reduce the cost and complexity of integration projects. The elements are defined as follows.
The Task Force in its study attempts to give such analysis (Williams et al . 1993), the present article is a short exposition of the results.
DEFINITION OF TERMS. STUDY METHODS • System of models (descriptions) (sometimes referred to as architecture in the narrow sense) .
The study was carried out by a series of meetings of Task Force members and by the development of analytic tools that could be adopted by the Task Force for evaluating enterprise reference architectures.
Enterprise Reference Architectures(in the narrow sense) describe the integrated enterprise on a generic level. These are model syste ms proposed which describe, from various points of view, the integrated enterprise as it is going to function.
Given the large number of possible architectures a list of available architectures was compiled and three major ones were used as closer subjects of study.
Enterprise Reference Architectures (in the broad sense) : describe the enterprise in various stages of its development, with each stage possibly described from many points of view. The latter systems include the former as components.
Three analysis procedures were used:
• A Questionnaire was generated,
Such model systems identify areas where models can be developed and possibly standardised, similarly to the ways of the famous 7 layer ISO-OSI architecture for computer communication.
• Results of the questionnaire were compiled into matrices,
• Methodology, which is a set of proven guidelines, techniques, procedures which the end-user can follow in order to implement an enterprise integration policy as well as carry out integration projects within that policy. Methodologies usually are developed in conjunction with reference architectures.
• Target architectures were mapped onto one another (one to one mapping)
The matrices, once generated, appeared useful to help identify research issues, areas of potential standardisation, And Areas where results of other disciplines could be adopted . Some of these possibilities have been exploited and appear as conclusions here while still more could be drawn in further work to be pursued .
• Modelling methods and tools which make it possible to create (express), develop and analyse the above identifi ed models. Tools mayor may not 884
be directly associated with a particular methodology or reference architecture.
design, construction, etc. of the computing system, the communication system, and others comprising the overall system. Thus, the Type 1 architectures will become major tools, or aids to be included in the overall Type 2 architectures.
• Infrastructure, which is a system of underlying processing and communication functions deemed necessary for implementing the information integration of the enterprise.
CRITERIA FOR USER NEEDS. The ongoing study also showed that:
It is thus possible to assess solutions proposed by various groups in the above areas and point out what is and what is not provided by these. Furthermore the Task Force decided to identify how partial existing solutions may be combined to fully satisfy each of these aspects.
The most valuable architecture from the viewpoint of the user is that of Type 2 above, the one which shows the structure and relationship of all of the tasks involved in the concept, analysis, design, building, commissioning and operation of the desired integrated enterprise.
Architectures as defined above are targeted at diverse audiences such as consultants, designers of the enterprise (on the technical level) , and decision makers involved in the design and development of the enterprise including both internal and external projects .
This architecture should be accompanied by a methodology which shows the user how to accomplish all of the steps just noted . That is the architecture should not only model the project development process, it should also teach and guide the user how to carry out each step of that development process through the accompanying methodology.
SOME INITIAL FINDINGS THAT DEFINED THE PATH
The methodology should also specify or suggest computer based and other tools, techniques, etc. which will aid the above work.
As the Task Force members studied the available architectures two major groups of findings were evident:
Thus, the IFAC/IFIP Task Force on Architectures for Integrating Manufacturing Activities and Enterprises determined that the potential user of these architectures vitally needed instruction on the "how' to design, develop, implement and use manufacturing and enterprise integration . (It is not enough to just give descriptions or merely designs for the related computer system.) This became the second method of classification.
1. A classification of the available architectures in terms of the task each architecture attempted to answer, and
2. The needs of the users of these architectures in terms of how they wanted the architectures to help them or how the architecture would be used in the integration task.
CLASSIFICATION ACCORDING TO PURPOSE. There are a multitude of proposed architectures and models in both the open and proprietary literature which purport to illustrate, explain and guide the task of integrating manufacturing activities and enterprises. However, only a very few of these actually treat the "how" of enterprise integration as well as the "what" that is needed . The remainder concentrate on describing the structure of the computer control system involved itself and/or the interconnectivity of the various functions being carried out by it , i.e., the "what" only. It was therefore evide nt that all of these architectures could be classified into two types:
ARCHITECTURES WHICH DESCRIBE THE PROJECT LIFE CYCLE We found that only three of the many architectures of both types known to us, and which were initially accessible for evaluation, were suitable for the dual task just noted . These were: 1. The Open System Architecture for Computer Integrated Manufacturing - Cl M-OS A as developed by the European CIM Architecture Consortium (AMICE) under ESPRIT projects 688, 2422 and 5288 of the European Community. This work was initiated in 1984 (hereafter called CIM-OSA) (see Bibliography, CIM-OSA).
1. Those which describe the architecture or physical structure of some component or part of the integrated system comprising the factory, such as the computer system, the communications system, etc. These will be called Type 1 in the discussion to follow.
2. GRAI-GIM - the GRAI Integrated Methodology as developed by the GRAI Laboratory of the University of Bordeaux in France. This work resulted from production management studies initiated at the GRAI Laboratory as early as 1974. It has taken its current form since about 1984 (hereafter called GRAI-GIM) (see Bibliography, GRAI-GIM).
2. Those which present an architecture of the project itself which is needed to develop the integration i.e., those that illustrate the life history or life cycle of the project developing the integrated enterprise. These will be labelled as Type 2.
It should be noted in passing that a major step in the development of the integration project will be the
3.
885
The Purdue Enterprise Reference Architecture
and the related Purdue Methodology as developed at Purdue University as part of the work of the Industry - Purdue University Consortium for CIM. This latter work started formally in 1989 but bears on the Purdue Reference Model developed starting in 1986 and earlier work of the Purdue Laboratory for Applied Industrial Control dating back to the mid seventies (hereafter called Purdue) (see Bibliography, PURDUE)
and human points of view in an integrated way. 3. The knowledge which is necessary to design a system cannot be found in a single person; designing requires team work. 4. The initial status of the system is not a matter of chance; this initial status must therefore be taken into account in order to well understand under which specific constraints the system operates on the one hand and, on the other hand, to avoid the re-design of those parts of the system which are satisfactory. Because of today's economic situation, this point becomes more and more relevant; many industrial systems must evolve faster and faster but with a cost as low as possible (Doumeingts et. al 1992).
These then are the three architectures which were extensively examined by the Task Force and which are described in a technical report (Williams et al. 1993). Manufacturing integration is not automation and/or computer application per se, although computers and automation are usually involved in its implementation. Manufacturing or enterprise integration is the collection, reduction, storage and use of data (and/or information) from the business entity involved, plus its environment, in order to optimise the operation of the business entity as a whole according to the criteria established by that business entity's management. It must also include the integration of the raw material, intermediate and final product flows, as well as machine organisation, to further the enterprise optimisation possible. Because of this important factor, the Task Force early decided to remove the word "control" from its title in order not to obscure the larger, true picture of the integration field .
'The term "methodology" means a consistent set of components which are:
1. The reference model (as defined in the broader sense) globally and generically showing the structure of the project to create an integrated enterprise or unit. 2. One or more modelling formalisms enabling the build up of the model in order to study alld evaluate it. 3. A structured approach for the overall program leading step by step from an existing system to a future system taking into account evolution objectives and specific constraints.
The Task Force was extremely fortunate in that its membership contained representatives from the groups developing each of the candidate architectures listed above. Thus they had access to information and insight into the details, definitions, future plans, etc. concerning these architectures not available to any other comparable group to our knowledge.
4. Performance evaluation criteria with which the system can be evaluated in relation to several points of view (economics, reliabili ty, etc.) . 'Generally speaking, a structured approach is a set of steps to be followed to solve a problem. Within the framework of an integrated manufacturing system design methodology, the structured approach must cover all of the life cycle of the integration project which is split into states (analysis, design, development, implementation, operation). Every step of the methodology must be precisely defined and based on a standardised project structure giving the set of actors for which the work must be precisely d efined as well . 'Defining very precisely all steps which are required to go from concept to specification to implementation is essential. During each step some models are built and checked. The consistency of these models and results for each step must be constantly checked." (Doumeingts et. al 1992)
ESTABLISHING JUDGING CRITERIA "Any organisation planning to carry out a programme in computer integrated manufacturing, or more generally enterprise integration, has a set of very special needs in order to be able to accomplish its desired tasks. 'An Integrated Manufacturing System solution cannot be bought off the shelf; each firm must be involved in devising its own, which explains why methodologies must be made available so that CIM systems can be built.
The above statement characterises very succinctly the industrial requirements which needed to be considered by the Task Force Thus evaluating manufacturing integration architectures must consider not only the "what" of integration but also the "how" of integration as well . That is, how integration is accomplished in terms of the development of the whole enterprise system, that is including service provided by the enterprise (henceforth "customer service"), human relationships, and information technology as a whole.
'Designing a CIM system meets with a number of difficulties: 1. The system is extremely complex, so some special techniques must be used to understand this complexity in order to efficiently act on it and to define the possible intervention area of every operator related to their skills.
2. The system must take into account not only the technical points of view but also the economic, social,
886
CIM-OSA
EVALUATION METHODS DEVELOPED AND USED
1. The AMICE Consortium which initially developed CIM-OSA is to be highly corn mended for their early decision to be as formal as possible in their definition and description of all aspects of this architecture. This was done with the ultimate aim of achieving complete computer executability of all constructs, models, tools, techniques, etc, associated with the architecture.
Once the Task Force had decided that the major elements of its technical charge involved an evaluation of how well the three candidate architectures (CIM-OSA, GRAI-GIM and Purdue) fulfilled the needs for "integrating manufacturing activities and enterprises", the major task facing them was to choose the method(s) of evaluation to be used . The methods used in the detailed study (Williams et at. 1993) have only been summarised here:
2. The AMICE Consortium initially restricted the scope of CIM-OSA to the discrete manufacturing field and in addition imposed a further restriction in the form of its application only to those factories where each element of the subject plant's production floor equipment has its own local control system . That is, CIM-OSA studies only what is termed supervisory control and production management by other groups. The dynamic direct control of plant floor production units is handled only by the production unit's own built-in local controllers which are fed general operating instructions by the CIM-OSA system.
METHOD 1 - QUESTIONNAIRES An extensive questionnaire was developed and adopted after a lengthy process of refinement to cover all important ramifications of the requirements for these architectures. This would then be completed by the groups developing each separate architecture a.nd reviewed by the Task Force before being adopted for its report. A shorter questionnaire was also developed a.nd a Short Form Evaluation Questionnaire for Integration Reference Architectures was accepted and completed for all three architectures.
3. CIM-OSA does have and describes a the CIM system . However, it has not extended this description to become a true methodology yet for the use of this architecture by the user organisation's planning and development group for carrying out plant integration studies and programs.
METHOD 2 - MAPPINGS, ONE ON ONE At the first meeting in Bordeaux it was also suggested that a method be developed to "map" the characteristics and capabilities of each of the architectures onto a suitable representation of the corresponding characteristics and capabilities of the others (a total of six, hopefully graphical presentations, to cover the full spectrum of characteristics and capabilities).
4. Because of its declared goal of formality and eventual computer executability, CIM-OSA is the most formally described of the three candidate architectures. This has unfortunately imposed a burden on its readability and understandability for those potential users who do not have a computer science or related ed ucational background.
A diagram representing the Life Cycle for each architecture was used for the framework desired. These were suitably modified to include any capabilities missing in that particular architecture if necessary. Representations of CIM-OSA and PURDUE and vice versa and the related GRAI-GIM representations were then developed.
5. In order to increase the potential for executability, CIM-OSA is developing-two major environments, the Enterprise Engineering Environment and the Enterprise Operation Environment and a set of specified system services known as the Integrating Infrastructure . The first of these environments formalises the development of enterprise models and their conversion to working programs for the system. The second formalises the testing, proving and acceptance of the resulting programs as new additions or changes to the operating enterprise information systems. The Infrastructure defines how all such programs, as just noted, work together to carry out the overall functions of the integrated computer system .
METHOD S - MAPPING AGAINST A SET OF REQUIREMENTS A different form of mapping diagram, that based on a Matrix of Requirements or Needs was created. A set of trial mappings for each architecture were then presented to representatives of CIM-OSA and GRAIGIM and accepted by them.
6. CIM-OSA is the most thoroughly studied of the candidate architectures and the most widely published. It is also the one which has received the most attention concerning potential standardisation as an International Standard.
CONCLUSIONS REGARDING EACH CANDIDATE ARCHITECTURE
GRAI-GIM Conclusions concerning each candidate architecture are summarised as developed by the work of the Task Force or derived from the work of other groups:
1. GRAI-GIM has a well developed and described methodology for the application of its architecture and
887
presentation of its overall structure and layered phases for program development. Its associated methodology is complete, particularly in its discussion of the planning phases of an integration progra.mme. The Purdue Architecture's structure approximates the way many plant workers think of their factories and their operations.
related tools and technology for the development of an integration program by the user through the specification stages. 2. GRAI-GIM, in its descriptive documentation has generally been confined to discussions of the development of the computer system and related hardware and software to implement the factory integration desired . Such a restriction is not inherent in the methodology or necessarily intended by the developers.
3. The split of the Implementation View of the Purdue Architecture into Information System, Human and Organisational, and Manufacturing Equipment (or Customer Service) considerations permits the Purdue Methodology and the subsequent enterprise integration programmes to undertake an extensive discussion of all of the human aspects of the enterprise involved as they affect enterprise integration.
3. Although not specifically so stated, GRAI-GIM discussions, descriptions, case studies, etc, are all todate confined to the discrete manufacturing field . 4. GRAI-GIM has also confined itself to date in its life cycle methodology to the concept, analysis, specification and detailed design phases of the overall development and use of an integration system for an enterprise. There is no discussion as yet of the construction, testing and commissioning of a system or of its continued development while in use. There is nothing inherent in the GRAI-GIM system itself which would prevent its ready expansion to cover these additional phases or indeed to study other industries than discrete manufacturing.
4. Likewise the manufacturing (or customer service) equipment considerations pe rmit the details of the integration of material and energy flows, equipment layout optimisation and many other important factors in the overall enterprise integration system to be considered beyond those of information integration alone. 5. Purdue has shown its extendibility to cover all types of industries and indeed to cover all types of enterprises regardless of their individ ual mission and as a methodology is the most extensively documented of the three in its Purdue Implementation Procedures Manual.
5. Like CIM-OSA, GRAI-GIM treats the human worker as a resource in terms of the required skills and physical capability. Also like CIM-OSA there is no discussion of human relations, needed training programmes, union requirements, human organisation details, etc.
6. Purdue lacks the set of mathe matical modelling techniques necessary wh en an architecture is to be computer modelled . There is no built-in restriction adding these, and the architecture can be readily extended in this direction .
6. The GRAI Laboratory in producing GRAI-GIM has developed several tools and t echniques of potential wide use in enterprise integration studies such as the GRAI-GRID, GRAI-NET, ECOGRAI, the GRAI Model and others. They have also advanced the use of other tools and techniques developed by others such as MERISE, Petri Nets, etc.
GENERAL CONCLUSIONS REGARDING ALL THREE ARCHITECTURES
7. The philosophy of CIM and of the carrying out of a ClM development project as expressed by the GRAI-GIM descriptive documents is the best of three candidate architectures in terms of its adherence to the philosophy adopted by the Task Force.
1. Enterprise integration is a very complex and highly detailed endeavour . Similarly, the reference architectures which describe this endeavour are also complex and highly detailed . As a result none of the candidate architectures and associated methodologies are, as yet, completely developed, described and documented . However, in each case the path to their ultimate completion is clear either from the work of the architectural development group themselves and their future plans or from the associated work of other groups, including this Task Force.
8. GRAI-GIM is intermediate between CIM-OSA and Purdue in terms of the degree of formality implied and used and the consequent ease of understanding by the non-computer science educated user.
PURDUE
2. Each of the studied architectures and their associated methodologies can be extended by the original development groups or others to become a complete architecture and methodology for guiding enterprise integration programs from initial conception to their actual construction and use. In our Recommendations section here we outline one method by which this could be accomplished in each case.
1. The Purdue Enterprise Reference Architecture and its associated Methodology are an informally described means for leading a user's application group through all of the phases of an enterprise integration programme from initial concept through use to final plant obsolescence.
2. As a.n informa.l description it is the easiest to understand by non-computer science educated users. This is especially true because of its easy-to-grasp graphical
3. It would also be possible, and perhaps more re888
warding, to combine the best parts of each of the candidate architectures to capture the possible synergy in a new or combined architecture. In the Recommendations section we have proposed one. way by which the combined architecture could be developed. We have also pointed out those additional features which could be added to each architecture or the combined architecture to make them or it even more helpful to the user applications group which will be the ultimate customers of this work .
associated methodology. This should then allow the development of a computer executable form of the architecture, compatible with current "open systems" trends in computer usage. Items 2a-2d need to be confirmed by the results of the Case Study of Item 1 above. This report recommends a possible pathway by which this might be achieved for each of the candidate architectures and for a possible "joint" one. Such work should be carried out for at least one complete architecture,
RECOMMENDATIONS FOR FUTURE WORK We further recommend that the above work should, if possible, be carried out in the framework of an International Research Programme and it is to be determined how to plan, finance and implement such a programme.
Our general recommendations are as follows : 1. A funded Task Force program should be initiated which will carry out a Case Study on the three candidate architectures. A specific enterprise should be chosen (or defined) after which each of the architectural development organisations (of the candidate architectures) will be asked to provide an architectural description of that enterprise in terms of their specific architecture.
3. It is our observation that user groups in attempting enterprise integration feel overwhelmed by the mass of detail necessary to plan and carry out the integration project or programme desired. Because of the size and complexity of the enterprises attacked in these studies the actual complexity involved is probably unavoidable (Vaes, 1991) . Therefore , the necessity which should be satisfied is to reduce the "apparent" complexity involved. Some ways by which the above might be accomplished are:
Such study would be necessary for a detailed validation of the conclusions as drawn by the Task Force and give further insight into the applicability of the three candidate architectures.
a. Development of instructional manuals of the methodology and, wherever possible, of the architecture itself, which are easily understood by those not formally trained in computer science, and related technologies.
2. The study by the Task Force init.ially concluded that while neither of the candidate archit.ectures was yet complete in terms of our definition of ultimate usability, there was no indication of unsurmountable difficulty in completing any of them if the initial development group or some follow-on group should decide on carry out this work. To reiterate, our definition of completeness includes the following :
b. Publication of comprehensive case studies using the architecture and methodology while thoroughly explaining each step of the process and its results achieved .
a . In addition to modelling the proposed computer based system of decisions, sched uling, and control (needed for information integration - under whatever title it is described), the architecture should also model the structure and progress of the project or programme under which the task of integration of the enterprise, factory, or unit involved is achieved.
c. Continued development of the possibilities and techniques of "configuring" generic, open structures ("integration platforms") underlying the implementation of scheduling, and control systems, for communication systems, application programs, databases, and tools for enterprise engineering. These techniques should ease the need for reprogramming all or large parts of the systems for each new business function.
Along with showing the structural model of b. the project or programme required, the architecture should have associated with it a methodology whose description will serve to instruct th e user organisation's planning and implementation groups in achieving the desired integration of information, and of the flow of materials and products .
d . De velop as many as possible example or standard system structures (generic or partial models). These could be parametrised, extended or modified by the user groups to easily generate models as needed for their own systems. By this the necessary collection of the massive detail involved can be circumvented and the quality of the resulting individual models improved . A compendium of already available such models would be most useful to develop.
c. In addition to instructions, the methodology should include aids (computerised or otherwise) which can be prescribed, or developed to whatever degree possible, to assist the user's planning and implementation group in their task of achieving the integration desired.
e . Search for techniques that reduce the apparent complexity of the architectures as experienced in the application context. The difficulty of dealing with the amount of data generated in realistic applications prompted researchers to look for simplification tech-
d. The pathway should be clear to achieving formally defined syntax and semantics for the models, techniques and tools involved in the architecture and its 889
ology to handle the human relations aspects could be readily included.
niques of presentation and analysis to reduce apparent complexity, e.g., Precedence Matrix techniques (Eppinger et al., 1992) . Similar techniques could contribute to the ease of use of the reference architectures studied.
2. Likewise the means for including the details of the modelling and applications of enterprise system construction, check-out, commissioning, etc, could be readily added . Similarly the technology for continuous improvement of the operations methodology applied to the working factory throughout its operational life could also be added for a complete life history treatment .
RECOMMENDATIONS FOR FURTHER DEVELOPMENT OF EACH ARCHITECTURE AND ITS ASSOCIATED METHODOLOGY
PURDUE
The case study recommended earlier should specifically address the following points concerning each of the three candidate architectures:
The Purdue Enterprise Reference Architecture and its associated Methodology are the most informal of the three candidate architectures in their presentation. In view of the strongly expressed need for formality in order to achieve eventual executability of the architectural constructs, this appears to be the first need in further development of the Purdue offerings. This can be accomplished in several ways either separately or as a joint undertaking. Some of these are:
CIM-OSA In view of the findings of the Task Force and the general recommendations just above, it is offered that CIM-OSA could be developed into a so-called complete architecture as follows :
I. Where applicable, employ ready developed by CIM-OSA appropriate credit as to source. the Integrating Infrastructure GRAI GRID of GRAI-GIM
1. Make it clear in the description of the use of the CIM-OSA Modelling Framework that it applies to studies of the manufacturing equipment systems and of the human and organisational systems of the enterprise as well as to the information integration systems (the computer-based systems).
the methodologies aland GRAI-GIM, with Possible examples are of CIM-OSA and the
2. Where the required technologies do not already exist, in the companion architectures or other fields, develop them as needed .
2. Prepare a companion document to the existing descriptions of the CIM-OSA Architecture itself to encapsulate the extensive discussion of the use of the CIM-OSA "life cycle". This would provide the methodology to aid user groups who plan to employ CIM-OSA for their e nterprise integ rating planning and development projects or programmes . This documented methodology should also describe the needs and methodology of the identification and concept layers present in the other two architectures but missing, in description at least, in CIM-OSA.
Other developments which would be helpful to Purdue would be as follows: 1. Purdue does not as yet require specific designated tools or techniques at each step of the development of an integration system, as called for by CIM-OSA. It would greatly aid the user if work were carried out to classify, evaluate and document the relative applicability of each of the multitude of computer-based, graphical and interactive analysis tools available. This applies to every stage of the analysis, design, construction, check-out, and operation of the integration systems . Those which are especially applicable could be formalised, if not already accomplished, for that application.
3. Remove the self-imposed restriction of CIM-OSA to discrete manufacturing systems. While all examples to date only treat such manufacturing systems, the Task Force could find no inherent limitations in Cl M-OS A that would prevent its expansion to include systems in other industries or, indeed, in enterprises in general.
2. There is currently a major lack of formality in the specification and development of human and organisational systems. This involves the specification of the innovative tasks which must be carried out by humans, as well as the specifications of the appropriate organisations to promote the accomplishments of human based tasks. Also it should include the best ways of assuring the availability of the necessary human skills as needed . Anything which can be accomplished in this area would be extremely valuable for future integration projects.
GRAl-GIM Like CIM-OSA, GRAI-GIM is unnecessarily restricted, in the opinion of th e Task Force, to the discrete manufacturing field. The following are other suggestions for "completing" GRAI-GIM in the ways developed by the Task Fore:
1. GRAI-GIM is limited in its discussion to the manu3. Formalisation of the corresponding tasks in the manufacturing or customer service equipment area on
facturing equipment and the control system. This is a self imposed limitation of treatment since the method-
890
the other hand is quite straight-forward in concept. The problem here is the extremely wide range of devices, etc., which are needed and thus the corresponding massive endeavour needed to impose formality on this area.
and compatibility as described in the proposals and recommendations of this study. 2. The contemplated work must not conflict with the ongoing international standardisation efforts where these apply, and 3. Sufficient funds can be made available to have a small dedicated group to work on these proposals (and particularly the case study) to assure their completion.
COMBINATION OF EXISTING A RCHITECTURES In view of the strong points of each architecture as brought out in the several evaluations carried out by the Task Force, the following is one possible consolidation of the three studied architectures which might be proposed. The case study should provide further insight as to the correctness of these proposals.
A POSSIBLE FUTURE ROADMAP FOR PROMOTION OF THE FIELD OF ENTERPRISE INTEGRATION USEFUL FOR FUNDING AGENCIES
1. Use the structure of the Purdue Enterprise Reference Architecture to guide the overall programme since it seems to be the one which is most easily understood and accepted by non-computer science educated personnel in user plan ning and development groups.
The work of the IFAC/IFIP Task Force on Architectures for Integrating Manufacturing Activities and Enterprises, as recorded here, has shown that the needs of the users for their acceptance and application of their Integration Architecture in priority order are as follows :
2. Use the CIM-OSA Modelling Framework to supplement the Purdue data flow and material and energy flow analysis method. These include the generic task lists described there. These are necessary for establishing the functional requirements for the proposed overall system.
1. A "complete" Architecture is necessary.
2. An associated Methodology for applying the Architecture and its related models, techniques and tools in the easiest possible manner for User Application Groups must be available.
3. Use the GRAI-GIM Modelling Framework as a reference check if needed to assure the completeness of the requirements.
3. Standardisation of the Architectures and their associated generic models, techniques and tools is very important as a promoter of their wide acceptability and use. It should be emphasized that it is the wide acceptability rather than standardisation per se which is the important criteria here.
Complementing (or combination of) existing methods and tools: 1. In the Functional Design or Specification Level, apply the GRAI-GIM, GRAI GRID and GRAI NET, and adopt the formality of the CIM-OSA Integrating Infrastructure, Integrated Engineering Environment and Integrated Operational Environment as templates for the design.
4. There is a general lack of knowledge and appreciation of the capabilities of integrating systems to improve the productivity and economic return of enterprises of all types in the minds of potential users everywhere.
2. Formalisation of the Human and Organisational and of the Manufacturing or Customer Service Equipment areas for the Purdlle Architecture.
This is due to the explosion of progress in computer and information systems technology in all areas of application in recent years and to the inability of the user community to keep abreast of these burgeoning capabilities and the associated benefits of their use. Thus any methods (case studies, training programs, easier to learn and use application methods, additional computer-aided tools, etc.) which promote knowledge and acceptance in the field are vitally important.
3. Adopt either the Cl M-OSA Integrating Infrastructure (lIS) or the Purdue Manifestation and Operation Layers or Phases and complete them with the necessary formalisation.
FUNDING AND COOPERATION The Task Force believes that its current evaluation work has outlined what is necessary to achieve a "complete" architecture . Likewise we believe that the requirements for a suitable methodology have also been defined here, and in the available literature.
It must be stressed that the present proposals and recommendations crucially depend on the following conditions: These proposa.ls a.nd rccommenda.Lions a.re supported by the development organisations of the candidate architectures in terms of developing the respective architectures so as to finally achieve completeness
1.
Thus the Task Force would strongly encourage current and future funding organisations to support the needs listed in this section .
891
PROPOSAL FOR FUTURE WORK OF THE TASK FORCE
BIBLIOGRAPHY AND REFERENCES
The major distinguishing feature of the Task Force in its work in evaluating and promoting the field of architectures for enterprise integration has been the fact that its membership included representatives of each of the major groups active in this field . Thus we are in a unique position to report on and hopefully guide the future development of this vitally important field for the future . Therefore, any future continuation of the Task Force and its work should continue to build on and exploit this unique characteristic and capability.
GENERAL Williams et al (1993), IFAC/IFIP Task Force on Architectures for Integrating Manufacturing Activities and Enterprises, Architectures for Integrating Manufacturing Activities and Enterprises, Technical Report, Theodore J. Williams, Editor, Purdue University, West Lafayette, Indiana, USA (March 1993). CIM-OSA AMICE Consortium (1989), Open System Architecture for CIM Research Reports of ESPRIT Project 688 Volume 1, Springer Verlag, Berlin.
Since the Task Force believes its work during this past triennium has effectively answered the challenge of its initial Scope as presented by its organisers, a new Scope and Plan of Work is needed. Recommendations for these are presented below .
AMICE Consortium , (1992) AMICE: CIM-OSA , ESPRIT Project 5288, Milestone M-2 , AD2 .0 Volume 2, Architecture Description , Document R0443/1, Consortium AMICE, Brussels, Belgium, (August 24, 1992) .
TASKS TO BE UNDERTAKEN 1. Monitoring and initiation , development and execution of the Case Study and other development work proposed herein . It is presumed that this work will be carried out by personnel other then the Task Force members because of the degree of involvement and dedication necessary for their accomplishment.
Beekman, D., (March-April 1989) "CIM-OSA: Computer Integrated Manufacturing - Open System Architecture, " Int . J . Computer Integrated Manufacturing, Vol. 2, No. 2, 94-105. CEN/CENELEC (April 18, 1990), (The Joint European Standards Organisation), European Prestandard Env 40003, " Computer Integrated Manufacturing, System Architecture, Framework for Enterprise Modelling," Berlin , Germany.
2. Work toward the development of one or more complete or open enterprise integration reference architecture(s) . This can be accomplished by, (a) fleshing out either of the current candidate architectures in a manner similar to that proposed in the 1993 Report of the Task Force (Williams et al. 1993) , or (b) by consolidating them into a best candidate similar to another proposal also made by the Task force in its report.
ESPRIT (1988) , Project 688, AMICE Open System Architecture for CIM, Springer-Verlag, Berlin. ESPRIT (1991), Consortium AMICE Open system Architecture, CIM-OSA, AD 1.0, Architecture Description ESPRIT Consortium AMICE, Brussels, Belgium.
3. Evaluate the relationships of the currently available analysis, design and implementation models, techniques and tools and recommend a selection of these to be incorporated with the complete architecture(s) proposed .
Jorysz, H. R. and Vernadat, F. B., (1990) "CIMOSA Part 1: Total Enterprise Modelling and Function View ," Int. J. Computer Integrated Manufacturing, Vol. 3, Nos. 3 and 4, pp. 144-156.
4. Where appropriate recommend standards for models, techniques, and/or tools which will help promote the acceptance of the architecture(s) and associated methodology(ies ).
Jorysz, H.R. and Vernadat, F . B. , (1990) "CIM-OSA Part 2: Information View ," Int. J . Computer Integrated Manufacturing, Vot. Nos. 3 and 4, 157-167.
5. Develop an on-going list of needed but primarily unavailable models, techniques and tools which would greatly aid the field of enterprise integration and encourage potential developer organisations to undertake this work.
3
Klittich, M., (1990) "CIM-OSA Part 3: CIMThe OperaOSA Integrating Infrastructure tional Basis for Integrated Manufacturing Systems," Int. J . Computer Integrated Manufacturing, Vol. 3 Nos. 3 and 4, 168-180.
6. Prepare syllabuses for innovative training programs needed in the area of enterprise integration and the details of integrating systems. As there are already many available programs for training in this area, only new, innovative ideas are worth promoting by an organisation like the Task Force.
Vaes, P., (1991) , "CIM-OSA Case Study of the IC Route," AT&T Network Systems Nederland, BV., Hilversum, the Netherlands.
The Task Force would benefit from the inclusion of more members from the direct user community of enterprise reference architectures.
GRAI-GIM Doumeingts, G ., (November 1984) Methode GRAI :
892
Dr. Gustav 1. Oiling, Chrysler Motors Corporation, Highland Park, MI, USA Ing. Marco Tomljanovich, ITALCAD Tecnologic e Sistemi S.P.A., Rome, Italy Dr. Bruno Vallespir, Universite de Bordeaux 1, Talence, France Dr. David Cheng Universite de Bordeaux 1, Talence, France Ing. lakob Vlietstra, McKinleyville, CA, USA Ing. Dick Zoetekouw, AT&T Network Systems Nederland BV, Hilversum, The Netherlands
Methode de Conception des Systemes de Productique. These d Etat en Automatique, Universite de Bordeaux 1, Bordeaux, France. Doumeingts, G., Vallespir, B., Darricar, D. and Roboam, M., (December 1987), "Design Methodology for Advanced Manufacturing Systems," Computers in Industry, Vol. 9 No. 4, 271-296 Doumeingts, G ., Vallespir, B., Zanettin, M., and Chen, D., (May 1992), GIM, GRAI Integrated Methodology, A Methodology for Designing CIM Systems, Version 1.0, Unnumbered Report, LAP /GRAI, University Bordeaux 1, Bordeaux, France.
CORRESPONDING MEMBERS
PURDUE
Mr. Randy Aranguren, IBM Corporation, Rochester, MN USA Professor Karl-lohan Astrom, Lund Institute of Technology, Sweden Dr. Albert Benveniste, IRISA-INRIA Rennes, France Professor Chen Yuliu, Tsinghua University, Beijing, Peopl. Rep. of China Professor Mark S. Fox, University of Toronto, Canada Dr. Yoshiro Fukuda, Technical Research Institute, JSPMI, Tokyo, Japan Dr. Zengjin Han, Tsinghua University, Beijing, Peopl. Rep. of China. Professor Lennart Ljung, Linkoping University, Linkoping, Sweden Dr. G. Kovacs, Hungarian Academy of Sciences, Budapest, Hungary Professor Leo Motus, Estonian Academy of Sciences, Estonia Professor Michael G. Rodd, University College of Swansea, University of Wales, United Kingdom
Industry-University Consortium (June 1992), Purdue Laboratory for Applied Industrial Control, An Implementation Procedures Manual for Developing Master Plans for Computer Integrated Manufacturing, Report Number 155, Purdue Lab . for Applied Industrial Control, Purdue University, West Lafayette, IN Williams, T . J., (1989) Editor, A Reference Model for Computer Integrated Manufacturing (CIM), A Description From the Viewpoint of Industrial Automation, Minutes, CIM Reference Model Committee, International Purdue Workshop on Industrial Computer Systems, Purdue University, West Lafayette, IN (1988), Instrument Society of America, Research Triangle Park, NC Williams, T. J., (1992) The Purdue Enterprise Reference Architecture, Instrument Society of America, Research Triangle Park, NC Eppinger.,S.D., Whitney, Di..Ei.., Gebels, D.A. (1992) "Organizing the Tasks in Complex Design Projects: Development of Tools to Represent Design Procedures," 1992 NSF Design and Manufacturing System Conference, Atlanta Georgia January 1992.
MEMBERS FORCE
OF THE TASK
Prof. Theodore 1. Williams, chairman, Purdue University, West Lafayette, IN, USA ACTIVE MEMBERS Dr. Peter Bernus, Griffith University, Nathan, (Brisbane) Queensland, Australia Mr. lim Brosvic, Honeywell, Inc . Phoenix, AZ 85023, USA Profeuor Guy Doumeingts, Universite de Bordeaux 1, Talence, France Mr. Fadi G. Fadel, University of Toronto, Canada Dr. Aisushi Inamoto, Mitsubishi Electric Corporation, Tokyo, Japan Dr. La3zlo Nemes, Division of Manufacturing Technology, CSIRO, Preston, Victoria 3072, Australia Mr. lames L. Nevins, 26 Sunset Dr., Burlington,MA,USA
893