ISO 15704:2000
(Main)Industrial automation systems - Requirements for enterprise-reference architectures and methodologies
Industrial automation systems - Requirements for enterprise-reference architectures and methodologies
Systèmes d'automatisation industrielle — Prescriptions pour architectures de référence entreprise et méthodologies
General Information
Relations
Frequently Asked Questions
ISO 15704:2000 is a standard published by the International Organization for Standardization (ISO). Its full title is "Industrial automation systems - Requirements for enterprise-reference architectures and methodologies". This standard covers: Industrial automation systems - Requirements for enterprise-reference architectures and methodologies
Industrial automation systems - Requirements for enterprise-reference architectures and methodologies
ISO 15704:2000 is classified under the following ICS (International Classification for Standards) categories: 25.040.01 - Industrial automation systems in general. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 15704:2000 has the following relationships with other standards: It is inter standard links to ISO 15704:2000/Amd 1:2005, ISO 15704:2019; is excused to ISO 15704:2000/Amd 1:2005. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 15704:2000 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 15704
First edition
2000-06-01
Industrial automation systems —
Requirements for enterprise-reference
architectures and methodologies
Systèmes d'automatisation industrielle — Prescriptions pour
architectures de référence entreprise et méthodologies
Reference number
©
ISO 2000
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 734 10 79
E-mail copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO 2000 – All rights reserved
Contents
Foreword .vi
0 Introduction.vii
0.1 Rationale for enterprise-reference architectures and methodologies.vii
0.2 Key principles of enterprise integration . viii
0.2.1 Applicability to any enterprise. viii
0.2.2 Enterprise identification and mission definition . viii
0.2.3 Separation of mission-fulfilment functions from mission-control functions. viii
0.2.4 Identification of process structures.ix
0.2.5 Identification of process contents.ix
0.2.6 Recognition of life-cycle phases .ix
0.2.7 Evolutionary approach to enterprise integration.ix
0.2.8 Modularity .x
0.3 Aim and benefits of deploying enterprise-reference architecture and methodologies.x
0.4 Benefits of this standard .x
1 Scope.1
2 Normative References.1
3 Terms and definitions .1
4 Requirements for enterprise-reference architectures and methodologies .4
4.1 Applicability and coverage of enterprise-entity types.4
4.1.1 Generality.4
4.1.2 Enterprise design.4
4.1.3 Enterprise operation .4
4.2 Concepts.4
4.2.1 General .4
4.2.2 Human-oriented.4
4.2.3 Process-oriented .5
4.2.4 Technology-oriented.5
4.2.5 Mission-fulfillment oriented.5
4.2.6 Mission-control oriented.5
4.2.7 Framework for enterprise modeling .5
4.2.8 Life cycle.5
4.2.9 Life history.5
4.2.10 Modelling views.6
4.2.11 Genericity.6
4.3 Components of enterprise-reference architectures .6
4.3.1 Engineering methodologies .6
4.3.2 Modelling languages .6
4.3.3 Generic elements.6
4.3.4 Partial models .7
4.3.5 Particular models .7
4.3.6 Tools.7
4.3.7 Modules .7
4.3.8 Enterprise-operational systems.7
4.4 Representation .7
4.5 Glossary .8
5 Completeness and compliance .8
Annex A (informative) GERAM: Generalised enterprise-reference architecture and methodologies.9
A.1 Introduction .9
A.1.1 Background.9
A.1.2 Scope.9
A.2 The framework for enterprise engineering and enterprise integration.10
A.2.1 General.10
A.2.2 Definition of GERAM framework components.11
A.2.2.1 GERA – Generic Enterprise Reference Architecture.11
A.2.2.2 EEMs – Enterprise engineering methodologies. 12
A.2.2.3 EMLs – Enterprise modelling languages. 12
A.2.2.4 GEMCs – Generic enterprise modelling concepts. 12
A.2.2.5 PEMs – Partial enterprise models. 12
A.2.2.6 EETs – Enterprise engineering tools. 13
A.2.2.7 EMs – (Particular) enterprise models. 13
A.2.2.8 EMOs – Enterprise modules. 13
A.2.2.9 EOSs – (Particular) enterprise operational systems. 13
A.3 Description of GERAM framework components . 13
A.3.1 GERA – Generalised Enterprise Reference Architecture . 13
A.3.1.1 General . 13
A.3.1.2 Human oriented concepts. 14
A.3.1.3 Process oriented concepts. 16
A.3.1.3.1 General. 16
A.3.1.3.2 Life cycle. 16
A.3.1.3.2.1 General. 16
A.3.1.3.2.2 Entity identification. 16
A.3.1.3.2.3 Entity concept . 17
A.3.1.3.2.4 Entity requirement. 17
A.3.1.3.2.5 Entity design . 17
A.3.1.3.2.6 Entity implementation . 18
A.3.1.3.2.7 Entity operation. 18
A.3.1.3.2.8 Entity decommissioning . 18
A.3.1.3.3 Life history . 18
A.3.1.3.4 Entity types in enterprise integration. 19
A.3.1.3.4.1 General. 19
A.3.1.3.4.2 Operation oriented entity types. 20
A.3.1.3.4.2.1 Project Enterprise Entity (Type A). 20
A.3.1.3.4.2.2 Repetitive Service- and Manufacturing Enterprise Entity (Type B). 20
A.3.1.3.4.2.3 Product Entity (Type C). 21
A.3.1.3.4.3 Recursive enterprise entity types . 21
A.3.1.3.5 Process modelling. 22
A.3.1.4 Technology oriented concepts. 23
A.3.1.4.1 General. 23
A.3.1.4.2 IT support for enterprise engineering and enterprise integration . 23
A.3.1.4.3 Enterprise Model Execution and Integration Services (EMEIS). 24
A.3.1.5 Modelling framework of GERA . 25
A.3.1.5.1 General. 25
A.3.1.5.2 Enterprise modelling . 26
A.3.1.5.3 View concepts. 26
A.3.1.5.3.1 General. 26
A.3.1.5.3.2 Entity model content views. 27
A.3.1.5.3.3 Entity purpose views. 28
A.3.1.5.3.4 Entity implementation views. 28
A.3.1.5.3.5 Entity physical manifestation views. 29
A.3.2 EEMs – Enterprise engineering methodologies. 30
A.3.2.1 General . 30
A.3.2.2 Human factor . 30
A.3.2.3 Project management . 32
A.3.2.4 Economic aspects . 33
A.3.3 EMLs – Enterprise modelling languages. 33
A.3.4 GEMCs – Generic enterprise modelling concepts. 34
A.3.4.1 General . 34
A.3.4.2 Glossary. 35
A.3.4.3 Meta-models . 35
A.3.4.4 Ontological theories. 35
A.3.5 PEMs – Partial enterprise models. 35
A.3.5.1 General . 35
iv © ISO 2000 – All rights reserved
A.3.5.2 Partial human role models .36
A.3.5.3 Partial process models.36
A.3.5.4 Partial technology models.36
A.3.5.4.1 General.36
A.3.5.4.2 Partial models of IT systems.36
A.3.6 EETs – Enterprise engineering tools.37
A.3.7 EMOs – Enterprise modules.38
A.3.8 EMs – Enterprise models .38
A.3.9 EOSs – Enterprise operational systems.38
A.4 Glossary of references .39
A.4.1 General references.39
A.4.2 Standards.40
Annex B (informative) Bibliography .41
B.1 CIMOSA references .41
B.2 GRAI-GIM references.41
B.3 PERA references.42
B.4 GERAM references .42
B.5 References on the work of the IFAC/IFIP Task Force .43
B.6 Other important references in the field of enterprise integration.43
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO
member bodies). The work of preparing International Standards is normally carried out through ISO technical
committees. Each member body interested in a subject for which a technical committee has been established has
the right to be represented on that committee. International organizations, governmental and non-governmental, in
liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
Draft International Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this International Standard ISO 15704 may be the
subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
International Standard ISO 15704 was prepared by Technical Committee ISO/TC 184, Industrial automation
systems and integration, Subcommittee SC 5, Architecture, communications and integration frameworks.In
preparing this document, substantive contributions were received from groups involved with enterprise-reference
architectures such as the Purdue Enterprise-Reference Architecture (PERA), the Graphes et Résultats et Activités
Interreliés GRAI Integrated Methodology (GRAI GIM), the Computer Integrated Manufacturing Open System
Architecture (CIMOSA), and the Generalised Enterprise-Reference Architecture and Methodology (GERAM).
Annexes A and B of this International Standard are for information only. Annex A is based on version 1.6.2 of
GERAM developed by the IFIP/IFAC Task Force on Architectures for Enterprise Integration who granted
permission for its inclusion in ISO 15704.
vi © ISO 2000 – All rights reserved
0 Introduction
0.1 Rationale for enterprise-reference architectures and methodologies
Industrial enterprises create and modify manufacturing and business operations to improve performance
in local and global markets. In the operational phase, they deploy a variety of resources such as people,
information systems, and automated machinery. Individually and collectively these resources provide the
functional capabilities required to expedite business processes and their constituent activities. The inter-
working of resources needs to be organised and targeted to accomplish the mission. This requires
suitable business rules and organisational structures to enable the enterprise to provide products and
services to its customers in conformance with agreed upon criteria.
Enterprises operate under uncertain market and environmental conditions so that enterprise engineering
may need to be ongoing. It follows that enterprise personnel have a variety of roles to play in the
conception and ongoing development of the mission, business rules, business processes, organisational
structures, and supporting resources and services. Because of the high levels of complexity involved in
enterprise engineering, invariably it is necessary to deploy means of assessing, structuring, coordinating
and supporting these engineering activities.
Enterprise-reference architectures underpinned by reference methodologies provide generally applicable
means of organising and coordinating engineering projects. By adopting, and as required adapting, a
reference methodology and architecture, enterprise personnel can cooperate in progressing enterprise-
engineering projects, improving the enterprise and utilisation of resources. By adopting a reference
methodology, architecture, and a supporting tool set, it becomes practical for personnel to reuse explicit
enterprise designs and models to achieve enterprise engineering on an ongoing basis to realise further
improvements in enterprise operation.
Therefore, a vital need is an enterprise engineering and integration reference base providing
methodologies and supporting technologies that can realistically treat the problem of enterprise
integration.
The work of the IFAC/IFIP (International Federation of Automatic Control/ International Federation for
Information Processing) Task Force on Architectures for Enterprise Integration and of many other similar
organisations around the world have recently focused their work on this problem in hopes of achieving
the generic solution needed. Their work has shown that such a reference base can be devised, and must
be underpinned by an enterprise-reference architecture that:
a) can model the whole life history of an enterprise-integration project from its initial concept through
definition, functional design or specification, detailed design, physical implementation or construction,
operation to decommissioning or obsolescence;
b) encompasses the people, processes, and equipment involved in performing, managing, and
controlling the enterprise mission.
It is important to note that enterprise-reference architectures deal with the structural arrangement
(organisation) of the development and implementation of a project or programme such as an enterprise-
integration or other enterprise-development programme. In contrast to these enterprise-reference
architectures, system architectures deal with the structural arrangement (design) of a system; for
example, the computer-control-system part of an overall enterprise-integration system.
The IFAC/IFIP Task Force on Architectures for Enterprise Integration has developed the definition of a
complete, generalised enterprise-reference architecture and methodology and has called it GERAM,
described in annex A. GERAM will be used as the example reference for the requirements set forth in
this document.
0.2 Key principles of enterprise integration
Several concepts that describe the nature of enterprise-reference architectures and methodologies have
emerged from the studies of the IFAC/IFIP Task Force on Architectures for Enterprise Integration that
can greatly simplify, integrate, and extend the work of enterprise engineering. This work has led to the
development of GERAM, which is capable of supporting those who plan, design, and implement complex
enterprise-integration projects.
Key principles of an enterprise-reference architecture are described below to provide a basis for the
requirements of clause 4.
0.2.1 Applicability to any enterprise
The early work in CIM (computer-integrated manufacturing) and enterprise integration was confined
largely to the field of discrete-parts manufacturing, and to computers and information handling. However,
the basic principles involved in enterprise integration apply to any enterprise, regardless of its size and
mission or any other such attributes involved and to all aspects of the enterprise. In addition, it has been
a mistake to confine the integration discussions to information and control systems alone. Often there are
problems within the mission system, manufacturing or other customer product and service operations, or
in the associated human and organisational area whose solution would greatly ease the overall system
problem, that is, a total solution must involve information, culture, and mission.
The reference architecture can be extended to cover all possible types of enterprise by considering
manufacturing as a type of customer service, providing concept, development, design, modification,
production, and supply of goods to the customer. Thus the mission-execution area of the architecture
would represent the customer service rendered by any enterprise even if that service involved the supply
of information-type products to the customer.
0.2.2 Enterprise identification and mission definition
No enterprise can exist in the long term without a business or mission, that is, it must produce products or
services desired by its customers. It usually produces these products or services in competition with other
enterprises. Therefore the enterprise identification and mission definition are essential parts of any
enterprise-integration project.
0.2.3 Separation of mission-fulfillment functions from mission-control functions
There are only two basic classes of functions involved in operating any enterprise. These are described
below.
a) One class comprises functions involved in fulfilling the mission, i.e. operating the processes that
produce the product or service. In the manufacturing plant these would include all material and
energy transformation tasks and the movement and storage of materials, energy, goods-in-process,
and products; and services.
b) The other class comprises functions involved that manage and control the mission-fulfillment to
achieve the desired economic or other gains that assure the viability or continued successful
existence of the enterprise. These include the collection, storage, and use (transformations) of
information to control the business processes, that is, to develop and apply necessary changes to the
business processes to achieve and maintain their desired operation. Control includes all planning,
scheduling, control, data management, and related functions.
viii © ISO 2000 – All rights reserved
0.2.4 Identification of process structures
Enterprise operation consists of many transformations of material, energy, and information that can be
categorised into two distinct classes: one for information transformations and the other for material and
energy transformations. These transformations will be carried out by many separate activities that can be
executed both concurrently and sequentially to constitute processes of an equivalent class. Processes of
both classes interface with each other in those activities that request and report status, and in those
activities that deliver operational commands. In combination these transformations define the total
functionality of the enterprise being considered.
0.2.5 Identification of process contents
For many technical, economic, and social reasons, humans are involved in the implementation and
execution of many business processes of all types in both classes mentioned in 0.2.4. Other processes
may be automated or mechanised. There are only three classes of implemented tasks or business
processes, which are as follows:
a) information and control activities that can be automated by computers or other control devices;
b) mission activities that can be automated by the mission-fulfillment equipment;
c) activities carried out by humans, whether of the information and control or mission-fulfillment class.
It is desirable to have a simple way of showing where and how the human fits in the enterprise and how
the distribution of functions between humans and machines is accomplished.
0.2.6 Recognition of enterprise life-cycle phases
All enterprises, of whatever type, follow a life cycle from their initial concept in the mind of an
entrepreneur through a series of stages comprising their development, design, construction, operation
and maintenance, refurbishment or obsolescence, and final disposal.
Not only does this life cycle apply to the enterprise but also to the enterprise products as well. Carried
further, one enterprise can be the product of another. For example, a construction enterprise could build
a manufacturing plant (enterprise) as its product. The manufacturing plant would then produce its own
product, such as an automobile. The automobile also has its own life cycle that goes through similar
steps to those discussed here (see 0.2.1).
A particular distinction can be made between those life-cycle phases which are concerned with the
creation and modification of enterprise entities (its development, design, construction, etc.) and their use
(operation). This distinction enables the orderly move (release) from the engineering environment to the
operation environment, providing for validation, testing and release of engineering results prior to
operation.
0.2.7 Evolutionary approach to enterprise integration
The integration of all of the informational and customer-product and service functions of an enterprise
may be a part of a master plan. The actual implementation of such integration may be broken up into a
series of co-ordinated projects that are within the financial, physical, and technical capabilities of the
enterprise. These projects can be carried out individually or collectively, as these resources allow, as long
as the master plan is followed.
0.2.8 Modularity
Because of the massive nature of all enterprise integration projects, modularity should be enforced
whenever possible. Thus it would be helpful if all activities were defined in a modular fashion, along with
their required interconnections, so they may later be interchanged with other activities that carry out
similar functions but in a different manner should this be desirable. Likewise, these replacement activities
would also be best implemented in a modular fashion, permitting their later substitution by still other
different methods of carrying out the same function. The choice of these implementation methods can be
governed by independent design and optimisation techniques as long as the activity specifications are
honoured.
Provided the modular implementation just stated is used, the interconnections between these modules
can be considered interfaces. If these interfaces are specified and implemented using company, industry,
national and/or internationally agreed upon standards, the interchange and substitution noted above will
be greatly facilitated.
0.3 Aim and benefits of deploying enterprise-reference architectures and methodologies
An enterprise-reference architecture with its associated methodologie and related enterprise-engineering
technologies that fulfill the requirements of this standard will enable an enterprise-integration-planning
team to determine and develop a course of action that is complete, accurate, properly oriented to future
business developments, and carried out with the minimum of resources, personnel, and capital. That is,
to:
a) describe the tasks required;
b) define the necessary quantity of information;
c) specify relationships among humans, processes, and equipment in the integration considered;
d) address management concerns;
e) address relevant economic, cultural, and technological factors;
f) detail the extent of computer-support required;
g) support process-oriented modelling that can model the whole life history of an enterprise.
0.4 Benefits of this standard
The enterprise-reference architecture and methodology requirements in this standard will allow a specific
enterprise-reference architecture and methodology to be checked for completeness with respect to its
current and future purpose. This standard will help guide their development.
This benefit will be most relevant to any group charged with improving an enterprise infrastructure or its
processes. Such a group will find it necessary to either select or create a reference architecture of its own
with a terminology that pertains specifically to the company, industry, and culture involved. This standard
will help guide that selection or creation.
x © ISO 2000 – All rights reserved
INTERNATIONAL STANDARD ISO 15704:2000(E)
Industrial automation systems — Requirements for enterprise-
reference architectures and methodologies
1 Scope
This International Standard defines the requirements for enterprise-reference architectures and
methodologies, as well as the requirements that such architectures and methodologies must satisfy to be
considered a complete enterprise reference architecture and methodologies.
The scope of these enterprise-reference architectures and methodologies covers those constituents
deemed necessary to carry out all types of enterprise creation projects as well as any incremental change
projects required by the enterprise throughout the whole life of the enterprise, including
a) enterprise creation,
b) major enterprise restructuring efforts, and
c) incremental changes affecting only parts of the enterprise-life cycle.
2 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of
this International Standard. For dated references, subsequent amendments to, or revisions of, any of these
publications do not apply. However, parties to agreements based on this International Standard are encouraged to
investigate the possibility of applying the most recent editions of the normative documents indicated below. For
undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC
maintain registers of currently valid International Standards.
ISO 14258, Industrial automation systems — Concepts and rules for enterprise models.
ISO 14258, Industrial automation systems — Concepts and rules for enterprise models: Technical
Corrigendum 1.
3 Terms and definitions
For the purposes of this International Standard, the following terms and definitions apply.
3.1
activity
all or part of functionality
NOTE Enterprise activity consists of elementary tasks performed in the enterprise that consume inputs and
allocate time and resources to produce outputs.
3.2
architecture
a description (model) of the basic arrangement and connectivity of parts of a system (either a physical or
a conceptual object or entity)
NOTE There are two, and only two, types of architectures that deal with enterprise integration. These are:
a) system architectures (sometimes referred to as "type 1" architectures) that that deal with the design of a
system, e.g. the computer control system part of an overall enterprise integration system;
b) enterprise-reference projects (sometimes referred to as "type 2" architectures) that deal with the organisation of
the development and implementation of a project such as an enterprise integration or other enterprise
development programme.
3.3
attribute
a piece of information stating a property of an entity
NOTE An attribute models an intrinsic property of something, for example, the geometry of a part, the condition of
a tool, or the qualifications of a worker.
3.4
behaviour
how the whole or part of the system acts and reacts
3.5
business process
a partially ordered set of enterprise activities that can be executed to realise a given objective of an
enterprise or a part of an enterprise to achieve some desired end-result
3.6
enterprise
one or more organisations sharing a definite mission, goals, and objectives to offer an output such as a
product or service
NOTE This term includes related concepts such as extended enterprise or virtual enterprise.
3.7
enterprise engineering
the discipline applied in carrying out any efforts to establish, modify, or reorganise any enterprise
3.8
enterprise model
a representation of what an enterprise intends to accomplish and how it operates
NOTE An enterprise model, which is used to improve the effectiveness and efficiency of the enterprise, identifies
the basic elements and their decomposition to any necessary degree. It also specifies the information, resources
and organisational requirements of these elements, and provides the information needed to define the requirements
for integrated information systems.
3.9
framework
a structural diagram that relates the component parts of a conceptual entity to each other
NOTE Neither the structure involved nor the relationship of the parts to each other have a life cycle or time
relationship in contrast to the enterprise-reference ("type 2") architecture.
3.10
genericity
the extent to which a concept is generic
3.11
life cycle
the finite set of generic phases and steps a system may go through over its entire life history
3.12
life history
the actual sequence of steps a system has gone through during its lifetime
2 © ISO 2000 – All rights reserved
3.13
master plan
the documentation of the major engineering and operations planning effort carried out prior to any large
enterprise integration or other systems engineering project
NOTE The master plan is based on management goals for the project and uses functional and economic analysis
techniques for the preliminary engineering of the project to achieve an initial design specification and prove
economic feasibility.
3. 14
methodology
a set of instructions (provided through text, computer programs, tools, etc.) that is a step-by-step aid to
the user
NOTE In carrying out needed aspects of the life cycle of the entity integration project, the methodology prescribes
or describes the processes of enterprise engineering and integration. A methodology may take account of any
involved social, political and economic aspects.
3.15
mission
that activity in which an enterprise engages to fulfil the customer product or service function for which it
was established; the mechanism by which an enterprise achieves its goals and objectives
3.16
model
an abstract representation of reality in any form (including mathematical, physical, symbolic, graphical, or
descriptive form) to present a certain aspect of that reality for answering the questions studied
NOTE A model can be used to describe the enterprise activities or the different phases of the life cycle of the
enterprise (see 3.8).
3.17
organisation
the structure of an enterprise and the distribution of responsibilities and authorities in the enterprise
3.18
resource
an enterprise entity that provides some or all of the capabilities required by the execution of an enterprise
activity and/or business process
3.19
structure
the definition of the relationships among the components of an organization
3.20
system
a collection of real-world items organised for a given purpose
NOTE A system is characterised by its structure and its behaviour.
4 Requirements for enterprise-reference architectures and methodologies
4.1 Applicability and coverage of enterprise-entity types
4.1.1 Generality
Enterprise-reference architectures and methodologies shall be capable of assisting and structuring the
description, development, operation, and organisation of any conceivable enterprise entity, system,
organisation, product, process, and their supporting technology. There may be reference architectures
that cover a sub-set and therefore are confined to a specific class or type of enterprise or systems (such
as discrete parts manufacturing, process industries, and information systems). However, the area
covered by these reference architectures and methodologies shall be clearly identified.
The methodology associated with a reference architecture shall provide 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. Such a methodology may or may not be model-based. That is, the
enterprise engineering process may or may not result in a specific enterprise model.
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 that might be used for it. The primary consideration shall be applicability and
capability in relation to these requirements.
Enterprise-reference architectures and methodologies shall identify concepts and components as
described in 4.2 and 4.3.
4.1.2 Enterprise design
Enterprise-reference architectures and methodologies shall identify the activities needed to manage,
conceive/define, describe, design, implement, maintain, and decommission any enterprise entity. See
3.2.3 and 3.4 of ISO 14258.
4.1.3 Enterprise operation
Enterprise-reference architectures and methodologies shall identify the activities needed to use the
results of enterprise engineering in the operation itself. Such use may include model-based decision
support and model-driven operation monitoring and control.
4.2 Concepts
4.2.1 General
The enterprise-reference architectures and methodologies shall address the role of humans, the
description of processes (function and behaviour) and the representation of all supporting technologies
throughout the life cycle of the enterprise.
4.2.2 Human oriented
Enterprise-reference architectures and methodologies shall exhibit the capability to represent human
aspects, such as organisational and operational roles, capabilities, skills, know-how, competencies,
responsibilities, authorisation, and relations to the organisation.
4 © ISO 2000 – All rights reserved
4.2.3 Process oriented
Enterprise-reference architectures and methodologies shall exhibit the capability to represent the
enterprise operation. Such representations shall cover both the functionality and behaviour of the
operation. The representations shall recognise the life cycle and life-history concepts of enterprise-entity
types and shall support process-oriented operations.
4.2.4 Technology oriented
Enterprise-reference architectures and methodologies shall exhibit the capability of representing all
technologies employed in the enterprise operation.
NOTE Such representation of 4.2.2, 4.2.3, and 4.2.4 shall provide for integration-technology infrastructures used
to support enterprise engineering and operation of business processes, models of enterprise resource (information
technology, manufacturing technology, office automation and others), facility layout models, information-system
models, communication-system models and logistics mode
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...