Return to: WG1 Home Page.

Edited by: Ted Williams, Purdue University.
Coordinated by: JG Nell, TC184 SC5 WG1 convener
Updated 1997-April-29

TC184 SC5 WG1, Modeling and Architecture

Requirements for Enterprise-Reference Architectures

Outline:

Introduction and Rationale (From N364)

Editor Note: Shorter, Nevins, Vlacic to prepare business-oriented drivers for integration

Feasibility: The IFAC/IFIP Task Force on Architectures for Enterprise Integration has studied enterprise-reference architectures since its establishment in 1990. In its work the Task Force has established the requirements to be satisfied by candidate enterprise-reference architectures and their associated methodologies to fulfill the needs of industry for such aids to enterprise integration. The result has been called GERAM, for Generalized Enterprise-Reference Architecture and Methodology, by the Task Force. The Task Force has shown that such an architecture is feasible and that several architectures presently available in the literature can already or potentially can fulfil such requirements.

Industry today is modifying manufacturing and business operations to assure:

• A better and faster response to customer requirements
• Ever higher quality for products
• More flexibility and faster response when introducing new products and in responding to marketplace needs.

At the same time there is pressure to increase company earnings while:

• Decreasing the environmental impact of factory operations
• Increasing personnel and environmental safety
• Improving working conditions and job satisfaction.

Many experts feel that computer-assisted integration of manufacturing and other business processes is the means to accomplish much of the goals mentioned. Unfortunately, integration generally has been presented with a strong technology bias resulting in only partial success. Often, efforts to improve the level of integration have been too narrowly focused and have resulted in non-integrable islands of automation rather than the integrated whole originally envisioned.

This narrow focus did not relate directly to the business-critical success factors of the company; and thus, has not led to sufficient investment payoff. Likewise, the necessary human issues, organizational changes, and the process-technology improvements have not been coordinated with, and fully integrated into, the information-integration process.

There have been several major causes for this. Primarily this has occurred because the project planners have not recognized the breadth and magnitude of the overall effort and underestimated capital and other resources required.

Timeliness and Urgency: Each company contemplating a major computer-based integration effort should develop a master plan covering all of the anticipated effort required to integrate the whole of the company or factory operation. With this master plan, smaller projects within the monetary and human resources capability of the company can be initiated with the knowledge that the sum of this and all succeeding projects will contribute to higher levels of process integration. This will be possible provided that the requirements of the initial master-planning effort are followed in every subsequent project.

Aim and Benefits: Editor Note: Nevins and Williams to redraft. This standard will identify methodologies and a number of checklists to assure that the master plan developed by a company integration-planning team is complete, accurate, properly oriented to future business developments, and carried out with the minimum of resources, personnel and capital. This needed methodology would:

• Describe the tasks to develop the master plan including its continual renewal
• Define the necessary quantity of information and data
• Specify the informational, the human-organizational, and the customer products and services interrelationships in the integration considered
• Consider and address management concerns
• Present relevant economic, cultural, and technological factors
• Detail the extent of computer support required.

Beneficiaries: The development of this standard of reference-architecture requirements will allow a specific architecture to be checked for completeness with respect to its current and future purpose, and the methodology so this standard will guide its development. These benefits will be most relevant to any group tasked with executing an infrastructure or process improvement, and so requiring to create a planning architecture of its own with a terminology that pertains specifically to the company, industry, and culture involved.

1.0 Scope (From N364)

The requirements defined in the proposed standard describe an enterprise-reference architecture that models the entire life history of an enterprise integration project from its initial concept in the eyes of the entrepreneurs who initially developed it, through its definition, functional design or specification, detailed design, physical implementation or construction, and finally operation to obsolescence and disposal. A compliant architecture shall be a relatively simple framework upon which all the functions and activities involved in the aforementioned phases of the life of the enterprise-integration project can be mapped. It also shall permit the tools used by the investigators or practitioners at each phase to be indicated. The architecture defined shall apply to projects, products, and processes; as well as to enterprises.

This standard does not define or require a standard enterprise-reference architechure. However, the standard does identify features of a candidate enterprise-reference architecture that contribute to the completeness of that architecture. The standard also does not require that an architecture be complete. The purpose for identifying the features of completeness is to provide a mechanism for two or more enterprises to share information by indicating areas where enterprise representation is needed.

2.0 References, normative and informative

See also Annex A

3.0 Definitions

(Editor Note:Use the task-force definitions as a resource)

For the purposes of this International Standard, the following important definitions related to these requirements for completeness of enterprise-reference architectures apply.

3.1 Definitions of enterprise concepts

3.1.1

3.1.2

3.1.3

EXAMPLES

1. Enterprise planners, builders, modifiers, and analyzers using the requirements to check completeness of their activity.
2. Enterprise-architecture and model builders using the requirements to assure consistency and to enable interoperability.
3. Developers of standards for enterprise representation using the requirements to assure consistency between their standards and this International Standard.

3.2 Definitions of enterprise-reference architecture concepts

3.2.1

3.2.2

• A type 1 architecture deals with the structural arrangement (design) of a physical system such as the computer control system part of an overall enterprise integration system; and
• A type 2 architecture deals with the structure arrangement (organisation) of the development and implementation of a project or program such as an enterprise integration or other enterprise development program.

The requirements in this standard will apply to both type 1 and type 2 architectures.

3.2.3

NOTE An enterprise model is an abstraction that identifies and represents the basic elements of an enterprise and their decomposition to any necessary degree that is used to improve the effectiveness and efficiency of the enterprise. It also specifies the information requirements of these elements, and provides the information needed to define the requirements for integrated information systems.

3.2.3

NOTE A model is an abstraction that represents one's understanding of a system or situation, and of the relevant elements and relationships. It represents the system elements and the connectivity between the elements.

4.0 Requirements (Outline in N383)

Requirements (as envisaged by the IFAC/IFIP Task Force) which must be fulfilled by a candidate enterprise-reference architecture and methodology for it to be considered as a GERAM compliant architecture.

(Editor Note:

1. Bernus and Kosanke to identify IFAC/IFIP requirements from N379 and N375a for insertion into clauses 2, 3, 4, and the annexes.
2. Bernus to do life-history from PERA. (Done, Figure 3)
3. Kosanke to do 8 life-phases. (Done)

4.1 General Concepts

4.1.1 Architectures and frameworks

(General things before specifics; e.g. type 1 and 2 architectures, distinguish life cycle/life history, views, aspects. A summary of these concepts should appear in the definitions, Clause 3)

4.1.2 Framework for enterprise models and its role

4.2 Purpose for enterprise-reference architectures

A candidate enterprise reference architecture and methodology for consideration as a GERAM (herein to be termed candidate architecture) must be a complete architecture and methodology, it must cover all of the details of the life cycle of any enterprise, entity or system from its initial concept throughout all aspects of its life history until and including its operation and final disposal. In this statement, completeness means that human factors (requirement 7), customer product and services (requirement iii) and information systems all must be considered.

A complete enterprise reference architecture shall:

• Cover all relevant life-cycle activities for any enterprise or its products from initial concept throughout all aspects orf life history until and including operation and final disposal
• Cover all relevant aspects of the enterprise and its elements such as function, organization, information, economy, and ecologic; or its products.
• Provide a unifying perspective of the enterrprise and any of its entities.
• Provide an environment for representing aspects and elements of any enterprise or any of its products.
• Be represented by a framework, understandable to humans, identifying all the components which make up the reference architecture.
• Define terms of all the items to be used in the course of the application of the reference architecture in any enterprise engineering efforts.

The candidate architecture must not be confined to any specific class or type of systems (discrete manufacture, information systems, CIM, etc.), e.g., it should be capable of handling the description and development of any conceivable enterprise , entity or system.

The candidate architecture must be able to incorporate, present and utilise all of the useful capabilities of any and all pertinent. type 2 architectures. Thus, it should contain the total capability of all type 2 architectures proposed by the Task Force and others.

4.2.1 Enterprise-reference architecture relation to framework for enterprise modeling (Figure 7 and others)

4.2.2 Components and roles of components

To develop further these requirements, it is necessary to represent the relationships between the concepts with which this standard is concerned. The following figure presents a "framework" for this purpose. Each part of this figure and its relations to other parts is explained . This standard then sets out criteria by which the completeness or otherwise of examples (instance) of these parts can be assessed. (suggested DNS text)

This will then be followed by the figure and text. (Use figure 1 of GERAM paper (Kurt's) as the GERA framework. Add life history and language. Also use the life activity descriptions of the elements that Peter and Kurt are identifying.)

4.2.2.1 Life cycle

How enterprise life-cycle activites can be represented in a reference architecture

• Concepts for life-cycle phases
• Concepts of views
• Concepts for representing enterprise-reference architectures in a human-understandable way

4.2.2.2 Life history

4.2.2.3 Views

4.2.2.4 Languages

4.2.2.5 Completeness

4.2.2.6 Role of humans

The candidate architecture for consideration as a GERAM must be able to show the place of the human in all aspects of their involvement in the enterprise : in terms of the tasks carried out wholly or initially by humans; in terms of their interaction with information systems or mission fulfilment components of the enterprise; in terms of necessary skills and other requirements for task execution, the skills themselves, training, working conditions, safety, compensation and benefits, social factors, etc.; human organisational structures; and all other factors vital to the well-being of the enterprise and its human staff.

The candidate architecture for GERAM should present a standardized glossary for use in enterprise integration engineering and other systems engineering efforts and provide a semantics and syntax to promote overall understanding in projects and other co-operative efforts in this area or provide reference to another suitable glossary to which it complies.

4.3 Requirements for Components of an Enterprise Reference Architectures (Normative)

(Life cycle; life-history views; languages--human and IT oriented; role of humans)

4.4 Methodologies (Normative)

The methodology associated with the candidate architecture must be able to provide all the necessary guidelines and management techniques for the initiation and pursuit of a project or program of development and operation of an enterprise or entity

Members of the GERAM class of enterprise-reference architectures and methodologies need not be based on any one single methodology and its accompanying architecture or framework. There are potentially many different methodologies and/or frameworks which might be used for it. The primary consideration should be total applicability and total capability in relation to these requirements.

Other necessities may require that any combinations of suitable frameworks and methodologies adequately presenting the capabilities of a GERAM may be used by different user groups, CIMOSA, GRAI-GIM, and PERA (for example) may suitably modify their current architectures (frameworks) and methodologies to satisfy the requirements of GERAM

The associated methodologies shall:

• Provide all the necessarly guidelines and management techniques for the initiation and pursuit of a project or program for development of an enterprise or any of its products.
• Provide user assistance for interpretion and use on the reference architecture and its associated methodologies
• Define terms describing the items to be used in the course of applymg the associated methodologies in any enterprise engineering effort.

4.5 Requirements for representation of relations to the environment (normative)

(Human, product and services, processes, resources, infrastructures)

The framework or overall graphical form of any member of the GERAM class of enterprise reference architectures and methodologies should be able to assist users in the interpretation and use of the associated methodologies of that candidate architecture. It is recommended that this be done by showing graphically the place and relative applicability of:

1. Computer-based tools of all types helpful to the user
2. Modelling languages applicable in all areas of the life cycle
3. Generic and partial models of the subject enterprises
4. Generic modules (standardized implementation components--software and hardware) which might find wide use in implementation in many industries and other application areas
5. Ontologies which can describe the overall requirements for these systems. Ontologies should be described in text form and in formal representations
6. Project and task interfaces, i. e., intraphase relationships
7. All of the life cycle tasks of the enterprise (concept, design, development, manifestation, operation, and disposal is one such list) including interphase relationships

Items 1 to 5 of the above should have a graphical representation in addition to the graphical representation with the elements of that member of the GERAM class.

4.6 Requirements for enterprise-model interoperability

(Unifying terminology, graphical representation)

4.6.1 Concepts and rules for unifying terminology

5.0 Compliance/Conformance

Require a mapping from individual architectures to the standard enterprise-reference architecture.

A.0 Annexes

A.1 Bibliography

1. IFAC/IFIP Task Force on Architectures for Integrating Manufacturing Activities and Enterprises, Architectures for Integrating Manufacturing Activities and Enterprises, Williams, T. J., editor, Technical Report, Purdue Laboratory of Applied Industrial Control, Purdue University, West Lafayette, IN, USA, March, 1993. Also published as: Williams, T. J, Bernus, P., Brosvic, J, Chen, D., Doumeingts, G., Nemes, L., Nevins, J. Vlietstra, J, Zoetekouw, D., and with the contributions of other members of the IFAC/IFIP Task Force on Architectures for Integrating Manufacturing Activities and Enterprises, "Architectures for Integrating Manufacturing Activities and Enterprises," Sydney, Australia, July 18-23, 1993 . The 12th IFAC World Congress ; same authors and same title, Computers in Industry, Vol. 24, No. 2-3, pp. 111-140, September 1994, and as Bernus, P., Nemes, L., and Williams, T. J., Architectures for Enterprise Integration, Chapman and Hall, London, 1996.
2. Bernus, Peter and Nemes, Laszlo, "A Framework to Define a Generic Enterprise Reference Architecture and Methodology", Minutes, Ninth Workshop Meeting, IFAC/IFIP Task Force on Architectures for Enterprise Integration, Ottawa, Canada, August 25-26, 199Q; also in Proceedings of the International Conference on Automation, Robotics and Computer Vision (ICARV'94), Singapore, November 10-12, 1994.
3. Bernus, Peter and Nemes, Laszlo, A Framework to Define a Generic Enterprise Reference Architecture and Methodology, Divisional Report Number, MTM 366, CSIRO division of Manufacturing Technology, Preston, Victoria, Australia 3072, undated. Also in Minutes, Tenth Joint Meeting, IFAC/IFIP Task Force on Architectures for Enterprise Integration, Singapore, November 7-8, 1994; Grenoble, France, December 13, 1994 . Revised Version of Item 2 above .
4. Williams, T. J., and the Members of the Industry-Purdue University Consortium for CIM, The Purdue Enterprise Reference Architecture, Technical Report 154, Purdue Laboratory for Applied Industrial Control, Purdue University, West Lafayette, Indiana, USA, December 1991. Also published as: Williams, T. J., The Purdue Enterprise Reference Architecture, Instrument Society of America, Research Triangle Park, NC, USA, 1992; and Williams, T. J., "The Purdue Enterprise Reference Architecture", Computers in Industry, Vol. 24, No. 2-3, pp. 141-158, September 1994.
5. Williams, T. J., editor, A Guide to Master Planning and Implementation for Enterprise Integration Programs, Technical Report 157, Purdue Laboratory for Applied Industrial Control, Purdue University, West Lafayette, Indiana, USA, June 1994.
6. Li, Hong, A Formalisation and Extension of the Purdue Enterprise Reference Architecture and the Purdue Methodology, Ph. D. Thesis, Purdue University, West Lafayette, IN, USA, December 1994. Also published as Li, Hong and Williams, T. J., A Formalisation and Extension of the Purdue Enterprise Reference Architecture and the Purdue Methodology, Technical Report 158, Purdue Laboratory of Applied Industrial Control, Purdue University, West Lafayette, Indiana, USA, December 1994.
7. Williams, T. J., and Li, Hong, A Specification and Statement of Requirements for GERAM, Report No. 159, Purdue Laboratory for Applied Industrial Control, Purdue University, West Lafayette, Indiana, USA, September 1995.
8. Anonymous, AMICE Consortium, CIMOSA, Architecture Description, ESPRIT Project 5288, Milestone M-2, AD2.0, Vol. 2, Document R0443/1, Brussels, Belgium, August 24, 1992.
9. AMICE Consortium, Open System Architecture, CIMOSA, AD 1.0, Architecture Description, ESPRIT Consortium AMICE, Brussels, Belgium, 1991.
10. AMICE Consortium, Open System Architecture for CIM, Research Report of ESPRIT Project 688, Vol. 1, Springer-Verlag, 1989.
11. ESPRIT Project 688, AMICE, Open System Architecture for CIM, Springer-Verlag, Berlin, 1988.
12. Doumeingts, G., Vallespir, B., Zanettin, M., and Chen, D., GRAI GIM Integrated Methodology, A Methodology for Designing CIM Systems, Version 1.0, LAP/GRAI, University Bordeaux I, France, May 1992.
13. Doumeingts, G., Vallespir, B., Darracar, D., M., "Design Methodology for Advanced Manufacturing Systems", Computers in Industry, Vol. 9, pp. 271-296, December 1987.
14. Williams, T. J., "Contributions of the Purdue Enterprise Reference Architecture and Methodology (PERA) to the Development of a General Enterprise Reference Architecture and Methodology (GERAM) ", in Proc. of the Third International Conference on Automation, Robotics and Computer Vision (ICARCV' 94), pp. 83-87, Singapore, Nov. 9, 1994.
15. Sssenguth, Wolfram and Jochem, Roland, An Object-Oriented Method for Integrated Enterprise Modelling Applied for the Development of Enterprise Related CIM-Strategies and General CIM-Standards, Technical Report, Fraunhofer-Instut fr Produktionsanlagen Konstruktonstechnik (IPK), Berlin, Germany, 1992.
16. Mertins, Kai, Sssenguth, Wolfram, and Jochem, Roland, "Integrated Information Modelling for CIM: An Object-Oriented Method for Integrated Enterprise Modelling", in Doumeingts, G., Browne, J., and Tomljanovich, M., editors, Proc. 4th International IFIP TC5 Conference on Integration Aspects, Computer Applications in Production and Engineering, CAPE 1991, pp. 315-323, Elsevier (North Holland), Bordeaux, France, Sep. 1991.

A.2 State of the Art with GERAM as Reference.

Bernus, Nemes, Kosanke GERAM paper, Kosanke's DIISM paper

A.3 Context and vision for Enterprise Reference Architectures

Edited by: Ted Williams, Purdue University.
Coordinated by: JG Nell, TC184 SC5 WG1 convener ( nell@nist.gov.)
Updated 20 February 1997