ISO 14258:1998/Cor 1:2000
(Corrigendum)Industrial automation systems — Concepts and rules for enterprise models — Technical Corrigendum 1
Industrial automation systems — Concepts and rules for enterprise models — Technical Corrigendum 1
Systèmes d'automatisation industrielle — Concepts et règles pour modèles d'entreprise — Rectificatif technique 1
General Information
Relations
Standards Content (Sample)
INTERNATIONAL STANDARD ISO 14258:1998
TECHNICAL CORRIGENDUM 1
Published 2000-02-15
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION � МЕЖДУНАРОДНАЯОРГАНИЗАЦИЯПОСТАНДАРТИЗАЦИИ � ORGANISATION INTERNATIONALE DE NORMALISATION
Industrial automation systems — Concepts and rules for enterprise
models
TECHNICAL CORRIGENDUM 1
Systèmes d’automatisation industrielle — Concepts et règles pour modèles d’entreprise
RECTIFICATIF TECHNIQUE 1
Technical Corrigendum 1 to International Standard ISO 14258:1998 was prepared by Technical Committee
ISO/TC 184, Industrial automation systems and integration, Subcommittee SC 5, Architecture, communications and
integration frameworks.
Page 1
Definition 2.1.1
Replace text with:
a group of organizations sharing a set of goals and objectives to offer products or services or both
Definition 2.1.2
Replace text with:
the uncontrollable part of a system which is widened to the extent that a decision-making procedure cannot be
conceived for the control of such a system
ICS 25.040.40 Ref. No. ISO 14258:1998/Cor.1:2000(E)
© ISO 2000 – All rights reserved
Printed in Switzerland
---------------------- Page: 1 ----------------------
ISO 14258:1998/Cor.1:2000(E)
Page 2
Definition 2.2.3
Replace text with:
for a system, restrictions and limitations which can come from inside or outside the system under consideration; for
a model, restrictions and limitations on the model imposed by the modeler for some purpose or in response to
some system constraint
Definition 2.2.5
Replace text with:
a representation of what an enterprise intends to accomplish, how it operates, and, possibly, how it is organized
NOTE An enterprise model is an abstraction that identifies and represents the basic elements of an enterprise and their
decomposition to any necessary degree. It is used, for example, to improve the effectiveness and efficiency of an enterprise. It
also specifies the information requirements of these elements, and provides the information needed to define the requirements
for integrated information systems.
Subclauses 3.1, 3.2, 3.2.1, and footnote
Change all occurrences of “systems theory” to “system theory”
Page 3
Subclause 3.2.3
Change the second and third list items to read:
— manage and operate an enterprise so that it can meet its objectives, and
— support an enterprise to modify, redesign, dismantle and rebuild it.
Subclause 3.2.4
Replace text with:
To make the information captured by an enterprise model available to humans and machines, that information shall
be represented either in a neutral format (preferable) or as specified by the using application.
Subclause 3.2.5
Replace text with:
Models, as representations of enterprises, shall exhibit syntax and semantics so that contents of the model are
understandable to human users. The syntax of a model refers to the permissible kinds of relations. The semantics
of a model encompass the meanings of the elements and relations with respect to enterprise-model concepts. The
syntactic form and semantic content of a model can be different depending, for example, on the purpose of the
model and on the boundary and environment of the enterprise.
Subclause 3.3
Delete “(informative)” from heading
2 © ISO 2000 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 14258:1998/Cor.1:2000(E)
Page 4
Subclause 3.3.1
Replace text with:
Three types of activities are required to solve issues found within each high-level system life-cycle phase
(Plan/Build, Use/Operate, Recycle/Dispose). These types are
— find out what to do (W activity),
— find out how to do it (H activity),
— do it (D activity).
Figure 1 is an example of a manufactured product showing a mapping between common names for system life-
cycle phases and the what, how, and do activities.
The W, H, and D activities may be represented by different types of models. These models shall have the
capability to interoperate where it has been determined that these activities need to communicate with each other.
Figure 1
Change the title of the figure to read:
Mapping between system life-cycle phases and system W, H, and D activities
Subclause 3.3.2
Change second paragraph to read:
Feeding modeled information forward and backward in life-cycle activities enables value-added iteration of
enterprise processes that improves product quality.
Subclause 3.3.3
Replace text with:
The W, H, and D activities are recursive and decomposable. Therefore, each activity can be divided into
subactivities, and these subactivities will consist of another set of W, H, and D activities (see Figure 2).
These subactivities may be represented by different types of models. These models shall be able to interoperate
where it has been determined that these subactivities need to communicate with each other.
EXAMPLE In a manufacturing enterprise, the activity “Produce” can be, in turn, separated into lower-level W, H, and D
activities. W activities are user-needs driven and comprise any activities finally resulting in a request for what is to be produced.
H activities are technology-requirements driven and comprise any activities finally resulting in how the product/system has to be
produced in terms of a release statement. D activities are task driven and comprise any activities finally resulting in the
shipment of the product.
© ISO 2000 – All rights reserved 3
---------------------- Page: 3 ----------------------
ISO 14258:1998/Cor.1:2000(E)
Page 5
Figure 2
Change the text in the box entitled “H2” to read:
Design Product (From H activity of Figure 1)
Change the title of the figure to read:
Decompose “Design Product” activity to show recursiveness of W, H, and D activities
Subclause 3.3.4
Change first paragraph to read:
The W, H, and D activities are iterative. Therefore, there is no fixed sequence of these activities, but it is possible
to return to previous activities to repe
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.