EN IEC 62890:2020

SLOVENSKI STANDARD
01-december-2020
Meritev, nadzor in avtomatizacija merilnega procesa - Upravljanje življenjskega
ciklusa za sisteme in sestavne dele (IEC 62890:2020)
Industrial-process measurement, control and automation - Life-cycle-management for
systems and components (IEC 62890:2020)
Industrielle Leittechnik - Life-cycle-Management von Systemen und Komponenten (IEC
62890:2020)
Mesure, commande et automation dans les processus industriels - Gestion du cycle de
vie des systèmes et produits (IEC 62890:2020)
Ta slovenski standard je istoveten z: EN IEC 62890:2020
ICS:
13.020.60 Življenjski ciklusi izdelkov Product life-cycles
25.040.40 Merjenje in krmiljenje Industrial process
industrijskih postopkov measurement and control
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN IEC 62890

NORME EUROPÉENNE
EUROPÄISCHE NORM
September 2020
ICS 25.040.40
English Version
Industrial-process measurement, control and automation - Life-
cycle-management for systems and components
(IEC 62890:2020)
Mesure, commande et automation dans les processus Industrielle Leittechnik - Life-cycle-Management von
industriels - Gestion du cycle de vie des systèmes et Systemen und Komponenten
produits (IEC 62890:2020)
(IEC 62890:2020)
This European Standard was approved by CENELEC on 2020-08-26. CENELEC members are bound to comply with the CEN/CENELEC
Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the
same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2020 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN IEC 62890:2020 E
European foreword
The text of document 65/805/FDIS, future edition 1 of IEC 62890, prepared by IEC/TC 65 "Industrial-
process measurement, control and automation" was submitted to the IEC-CENELEC parallel vote and
approved by CENELEC as EN IEC 62890:2020.
The following dates are fixed:
• latest date by which the document has to be implemented at national (dop) 2021-05-26
level by publication of an identical national standard or by endorsement
• latest date by which the national standards conflicting with the (dow) 2023-08-26
document have to be withdrawn
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC shall not be held responsible for identifying any or all such patent rights.
Endorsement notice
The text of the International Standard IEC 62890:2020 was approved by CENELEC as a European
Standard without any modification.
In the official version, for Bibliography, the following notes have to be added for the standards
indicated:
IEC 61804-2 NOTE Harmonized as EN IEC 61804-2
IEC 61804-3 NOTE Harmonized as EN 61804-3
IEC 61987 (series) NOTE Harmonized as EN IEC 61987 (series)
IEC 61987-10 NOTE Harmonized as EN 61987-10
IEC 62402:2019 NOTE Harmonized as EN IEC 62402:2019 (not modified)
IEC 62264-1 NOTE Harmonized as EN 62264-1

IEC 62890 ®
Edition 1.0 2020-07
INTERNATIONAL
STANDARD
colour
inside
Industrial-process measurement, control and automation – Life-cycle-

management for systems and components

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 25.040.40 ISBN 978-2-8322-8683-8

– 2 – IEC 62890:2020 © IEC 2020

CONTENTS
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 7
2 Normative references . 7
3 Terms, definitions and abbreviations . 7
3.1 Terms and definitions. 7
3.2 Abbreviated terms and acronyms . 12
4 Generic models for Life-Cycle-Management . 13
4.1 Product type and product instance . 13
4.2 Life-Cycle-Model . 14
4.3 Structure model . 16
4.4 Compatibility model . 19
5 Strategies for Life-Cycle-Management . 23
5.1 General . 23
5.2 Last-time buy . 25
5.3 Substitution . 26
5.4 Re-design . 27
5.5 Migration. 28
5.6 Comparison of the strategies . 30
5.7 Application of Life-Cycle-Management strategies for service . 31
5.7.1 Service regarding Life-Cycle-Management . 31
5.7.2 Service levels . 31
5.7.3 Standard service . 31
5.7.4 Service through special agreement . 31
6 Life-Cycle-Management . 32
6.1 Proactive Life-Cycle-Management . 32
6.2 Life-Cycle-Excellence . 33
Annex A (informative) The current status of life-cycle aspects . 35
Annex B (informative) Requirements, influencing factors, industry-specifics . 38
B.1 General requirements . 38
B.2 Consideration of industry-specific requirements . 40
B.3 Requirements of the energy industry . 48
B.3.1 General industry characteristics . 48
B.3.2 Life-cycle related requirements . 49
B.3.3 Industry-specific economic aspects. 49
B.3.4 Anticipated industry trends . 50
B.4 Industry-neutral aspects . 50
B.4.1 Overview . 50
B.4.2 Examples of external technical influences. 51
B.4.3 Examples of the influence of standardization and legislation . 51
B.4.4 Examples of socio-economic influences . 51
B.5 Summary . 52
Annex C (informative) Life-cycle considerations for selected examples . 55
C.1 Component life-cycles . 55
C.2 Microprocessors . 55

IEC 62890:2020 © IEC 2020 – 3 –
C.3 Field device integration . 56
C.4 Standards and regulations . 57
Annex D (informative) Example for the application of the Life-Cycle-Management
strategies . 59
Annex E (informative) Plant user strategies . 62
Annex F (informative) UML diagram semantics . 64
Bibliography . 66

Figure 1 – Relationship of product type and its product instance(s) . 13
Figure 2 – Generic Life-Cycle-Model of a product type . 14
Figure 3 – Evolution of products (type with version and revision) . 15
Figure 4 – Maintenance of products (type with version and revision) . 15
Figure 5 – Life time of a product instance . 16
Figure 6 – UML diagram of a hierarchical system structure . 17
Figure 7 – Hierarchical system structure (example) . 17
Figure 8 – Example for Life-Cycle-Management of a system (type) by integrating
components (types) . 18
Figure 9 – Example of integrating components into a system . 19
Figure 10 – Example of mapping of compatibility requirements to the level of
compatibility . 22
Figure 11 – Example of a compatibility assessment of a product . 23
Figure 12 – Relationships between the partners in the value chain . 23
Figure 13 – Ensuring delivery of a system through last-time buy of a component . 25
Figure 14 – Ensuring delivery of a system through substitution of a component . 26
Figure 15 – Re-design of a system due to end of production of a component . 28
Figure 16 – Level model for migration steps . 29
Figure 17 – Typical characteristics of the Life-Cycle-Management strategies . 30
Figure 18 – Life-Cycle-Excellence . 34
Figure A.1 – Typical structure of an instrumentation and control system with functional
levels according to IEC 62264-1 . 35
Figure A.2 – Example of the effects of component failure . 36
Figure A.3 – Life-cycles of plants and their components. 37
Figure A.4 – The iceberg effect . 37
Figure B.1 – Trade-off between procurement costs (initial investments) and costs for
operating and maintenance . 39
Figure B.2 – Typical ranges of variables which influence the life-cycle . 53
Figure C.1 – Examples of component life-cycles . 55
Figure D.1 – Compatibility assessment of replacement devices . 59
Figure D.2 – Replacement of the defective device with a new device . 61
Figure F.1 – Semantics of UML elements used in this document . 64

Table B.1 – Overview of industry-specific requirements . 42
Table B.2 – Overview of industry-specific requirements . 45
Table E.1 – Fundamental characteristics of plant users . 63

– 4 – IEC 62890:2020 © IEC 2020
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
INDUSTRIAL-PROCESS MEASUREMENT, CONTROL AND AUTOMATION –
LIFE-CYCLE-MANAGEMENT FOR SYSTEMS AND COMPONENTS

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international
co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and
in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports,
Publicly Available Specifications (PAS) and Guides (hereafter referred to as "IEC Publication(s)"). Their
preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with
may participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for
Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence between
any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent
rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62890 has been prepared by IEC technical committee 65: Industrial-
process measurement, control and automation.
The text of this International Standard is based on the following documents:
FDIS Report on voting
65/805/FDIS 65/820/RVD
Full information on the voting for the approval of this International Standard can be found in the
report on voting indicated in the above table.
This document has been drafted in accordance with the ISO/IEC Directives, Part 2.

IEC 62890:2020 © IEC 2020 – 5 –
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under "http://webstore.iec.ch" in the data related to
the specific document. At this date, the document will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct understanding
of its contents. Users should therefore print this document using a colour printer.

– 6 – IEC 62890:2020 © IEC 2020
INTRODUCTION
In today's automation applications, an increasing divergence of the life-cycles of components,
devices and systems in comparison to the life time of overall plants is evident. The increasing
functionality of components, the advancing development of electronics and the innovation
dynamics inherent to hardware and software are continuously shortening the life-cycle of
individual automation components. Certain semiconductor components are only manufactured
for a short period of time, for example, and subsequently abandoned.
By comparison, the time in use of automation systems is considerably longer. Moreover, there
are considerable differences depending on the industry sector. The time in use of a production
line in the automobile industry is usually identical with the period of time in which a new model
is manufactured which is around 7 to 8 years today. By comparison, the operational life of a
process plant in the chemical industry is typically some 15 years, while up to 50 years may be
reached in the case of oil and energy, and power plants. The plant and product life-cycles have
to be considered by the management for the overall plant functionality and economic
considerations.
Increased utilization and integration of plant process data from automation systems towards
enterprise and asset management systems has caused technology dependencies between
hierarchy layers of automation systems. A more uniform way of dealing with Life-Cycle
Management between these layers and all partners in the value chain is essential with respect
to plant regularity, operability and security aspects.
Consequently, this necessitates different strategies to maintain the availability of the plant by.
sophisticated maintenance strategies. As a result, considerable demands are made on the
delivery capacity of automation products and spare parts, as well as the provision of services,
such as maintenance and repairs. For example, when the planning of a new plant envisages
the usage of a newer version of an engineering system, the producer has to ensure that this
newer version can also be employed for older components and systems already in use in the
existing plant and may have to develop upgrades accordingly. To an increasing extent, this
calls for close cooperation between the partners along the value chain.
The presented situation illustrates that mastering these conflicting characteristics of Life-Cycle-
Management will become increasingly significant in automation, not least in the ongoing
discussions between plant users and manufacturers as well as manufacturers and suppliers.
The interaction between global, legal and technical aspects – including demands for high
functionality and efficiency, as well as the influence of IT technologies in automation – helps to
demonstrate the scope of this topic.
This International Standard has been prepared in response to this situation. It is comprised of
basic, complementary and consistent models and strategies for Life-Cycle-Management in
automation. These generic models and strategies are then applied to various examples.
Consequently, this document represents a consistent general approach, which is applicable to
automation in various industrial sectors. The economic significance of Life-Cycle-Management
is a recurring theme of this document. The definitions of generic models, terms, processes and
strategies form an indispensable foundation for a joint understanding between plant users and
manufacturers and between manufacturers and suppliers regarding Life-Cycle-Management.
Proactive Life-Cycle-Management focuses on the selection of robust components,
specifications, and technologies that consequently have long-term stability. The proactive
approach includes the application of this set of generic reference models in the development of
standards in order to be able to efficiently ensure sustainable interoperability and compatibility.

IEC 62890:2020 © IEC 2020 – 7 –
INDUSTRIAL-PROCESS MEASUREMENT, CONTROL AND AUTOMATION –
LIFE-CYCLE-MANAGEMENT FOR SYSTEMS AND COMPONENTS

1 Scope
This International Standard establishes basic principles for Life-Cycle-Management of systems
and components used for industrial-process measurement, control and automation. These
principles are applicable to various industrial sectors. This standard provides definitions and
reference models related to the life-cycle of a product type and the life time of a product instance,
It defines a consistent set of generic reference models and terms. The key models defined are:
– Life-Cycle-Model;
– structure model;
– compatibility model.
This document also describes the application of these models for Life-Cycle-Management
strategies. The content is used for technical aspects concerning the design, planning,
development and maintenance of automation systems and components and the operation of
the plant.
The definitions of generic models and terms regarding Life-Cycle-Management are
indispensable for a common understanding and application by all partners in the value chain
such as plant user, product and system producer, service provider, and component supplier.
The models and strategies described in this standard are also applicable for related
management systems, i.e. MES and ERP.
2 Normative references
There are no normative references in this document.
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1.1
after-sales support phase
phase in the life-cycle of a product type which begins at the end of the selling phase and ends
with product abandonment
3.1.2
backward compatibility
downward compatibility
fulfilment by a new component of all the specified requirements of the compatibility profile of its
predecessor
Note 1 to entry: Antonyms are forward compatibility and upward compatibility, respectively.

– 8 – IEC 62890:2020 © IEC 2020
3.1.3
capability profile
compatibility profile that represents characteristics of a product type
3.1.4
compatibility
ability of a component to fulfill the compatibility profile of another component
3.1.5
compatibility assessment
verification of an agreed compatibility level
3.1.6
compatibility profile
list of all compatibility requirements of a system, or a component of a system, depending upon
the application
3.1.7
component
autonomous element of a system, which fulfills a defined sub-function
3.1.8
construction compatibility
fulfilment of the constructional aspects of a compatibility profile by a component
Note 1 to entry: Related requirements are physical dimensions, construction properties, connection method
(including e.g. power supply) and the location with respect to environmental conditions.
3.1.9
data compatibility
fulfilment of the functional aspects related to data type and format of a compatibility profile by
a component
3.1.10
delivery release
end of the manufacturing preparation process after which series production can begin
Note 1 to entry: The manufacturing preparation process is part of the development phase.
3.1.11
development phase
phase of the product life-cycle which begins with the decision to develop a product type and
ends with delivery release of the product type
3.1.12
disposal
removal of a product instance following the time in use and disposal or recycling
Note 1 to entry: This is the final phase of the life-cycle of a product instance
3.1.13
end of sales
end of all active sales activities for a product
Note 1 to entry: This is also called discontinuation of a product.
3.1.14
end of service
end of all service activities for a product type

IEC 62890:2020 © IEC 2020 – 9 –
3.1.15
end of production
point of time when instances of a product type are no longer produced
3.1.16
full compatibility
fulfilment of all aspects of a compatibility profile by a component
Note 1 to entry: The aspects are function, construction, location and performance.
3.1.17
function compatibility
fulfilment of the functional aspects of a compatibility profile by a component
3.1.18
instance
concrete, clearly identifiable component of a certain type
Note 1 to entry: It becomes an individual entity of a type, for example a device, by defining specific property values.
Note 2 to entry: In an object-oriented view, an instance denotes an object of a class (of a type).
3.1.19
last-time buy
Life-Cycle-Management strategy in which instances of an abandoned product type are
purchased before end of sales
3.1.20
level of compatibility
fulfillment of the requirements described in the compatibility profile
3.1.21
life time
length of time from the end of the creation of a product instance to the end of disposal
3.1.22
life-cycle
length of time from the start of the development phase of a product type to the product
abandonment
3.1.23
Life-Cycle-Costs
sum of all instance costs for plant user incurred after purchase up to the end of the life time of
a system
3.1.24
Life-Cycle-Excellence
holistic approach to managing changing conditions to ensure technical, application specific,
economic and ecological robustness of the Life-Cycle-Management for products
3.1.25
Life-Cycle-Management
methods and activities for the planning, realization and maintenance of products for the life-
cycle of types and the life time of instances
3.1.26
Life-Cycle-Management strategy
strategy for applying Life-Cycle-Management methods to ensure the availability of a system
throughout the time in use
– 10 – IEC 62890:2020 © IEC 2020
3.1.27
migration
replacement of components in an existing system by a component with extended or modified
functionality or with a different technology while maintaining functionality
3.1.28
milestone
defined point in time with a specific meaning for example:
– 3.1.10 delivery release
– 3.1.13 end of sales
– 3.1.15 end of production
– 3.1.14 end of service sales
– 3.1.32 product abandonment
3.1.29
obsolete product
not available product from the original producer to the original specification
[SOURCE: IEC 62402:2019, 3.1.15, modified]
3.1.30
producer
company which develops a product type, maintains it during its life-cycle and manufactures
instances of this type
3.1.31
product
commodity (goods or service) for operational business, with defined properties (of product type),
which is created (product instance) in a value chain process with reproducible quality
Note 1 to entry: It is sold during a defined period and is technically and logistically supported until product
abandonment. The value chain process can be a process for integrating components into a system (integration
process). Products can be hardware, software, services or combinations thereof.
3.1.32
product abandonment
point of time when all service for a product type have stopped
3.1.33
product instance
Instantiated product types
Note 1 to entry: Instantiated expresses that the product has been produced, the service has been performed, the
software has been registered, etc.
3.1.34
product type
definition of all characterizations for instantiated products
Note 1 to entry: Instantiated expresses that the product has been produced, the service has been performed, the
software has been registered, etc.
3.1.35
re-design
Life-Cycle-Management strategy in which a new version of a product type is developed which
typically fulfils or exceeds the specification, and therefore the compatibility profile, of a previous
type
IEC 62890:2020 © IEC 2020 – 11 –
3.1.36
requirements profile
compatibility profile that represents characteristics of a role-based equipment, required to
achieve its role
3.1.37
revision
defined status of a software or hardware, including all of its integrated components, which is
explicitly identified by a revision number
3.1.38
robustness
capability of a system to continue to fulfill its function under changing conditions
3.1.39
sales phase
phase of life-cycle which begins at delivery release and end with end of production
3.1.40
sales release
point of time when active sales activities for a product type have started
3.1.41
service
total of all supporting activities for products (types and instances)
Note 1 to entry: Standard services end with product type abandonment. Supporting activities after product
abandonment are subject to special service agreements.
3.1.42
signal compatibility
level of compatibility from the function view of the compatibility profile related to signal
acquisition and processing
3.1.43
software compatibility
level of compatibility from the function view of the compatibility profile related to software
3.1.44
standard services
level of service without consideration of specific user requirements
3.1.45
substitution
Life-Cycle-Management strategy in which instances of a product type are replaced by instances
of a compatible new type without repercussions for the system
3.1.46
system
defined and structured set of components which fulfill a function (system function) through
interactions or interrelationships with each other
Note 1 to entry: Systems could have a hierarchical structure, i.e. they could consist of underlying systems (which
are then considered components of the system).
Note 2 to entry: From a sales perspective, a system denotes a set of product types belonging to a specific portfolio
line.
– 12 – IEC 62890:2020 © IEC 2020
3.1.47
time in use
portion of the life time in which a product instance is actually in use for its intended purpose
3.1.48
update
new revision of a version designed for error correction and/or minor functional improvements
Note 1 to entry: For software, an update is called a patch which can include bug fix for general errors and hotfix for
critical or urgent error corrections.
3.1.49
upgrade
product for upgrading a component to a newer version with improved or enhanced functionality
Note 1 to entry: The term upgrade can apply to hardware and software.
3.1.50
version
defined status of a product type, including all of its integrated components, which is explicitly
identified by a version number
3.1.51
warranty period
time frame in which a replacement or repair of a faulty item is contractually assured
3.2 Abbreviated terms and acronyms
ASIC Application specific integrated circuit
CE Conformité Européenne
COTS Components Off The Shelf
NOTE 1 Also used for Commercial Off The Shelf.
EMC Electromagnetic compatibility
ERP Enterprise Resource Planning
EU European Union
FDA Food and Drug administration
FPGA Field programmable gate array
ID Identifier
IT Information technology
LCC Life-Cycle Costing
MES Manufacturing execution system
PLM Product Life-Cycle Management
RoHS Reduction of Hazardous Substances
TCO Total Cost of Ownership
UML Unified Modelling Language
NOTE 2 See Annex F.
USB Universal serial bus
IEC 62890:2020 © IEC 2020 – 13 –
4 Generic models for Life-Cycle-Management
4.1 Product type and product instance
Requirements from industries result in a very wide range of factors which affect the life-cycles
of products to varying degrees. Consequently, the Life-Cycle-Model specified in this document
takes this into account. The differentiation between product types and product instances is
fundamental. Each product instance is an instantiation (produced product, registered software,
performed service, etc.) of a product type. As shown in the UML diagram of Figure 1, a product
type can be represented by a UML class and a product instance by a UML object. The semantics
of the UML elements used in this document are explained in Annex F.

Figure 1 – Relationship of product type and its product instance(s)
A product type is characterized by an unambiguous product ID (for example the order number),
a set of development documents, manufacturing and test descriptions, and technical
documentation. For approval of a product type for specific applications, certificates can be
demanded and issued. This definition of a product type is valid for hardware products, software
products, and products that are hardware/software bundles. Typically, the right to use product
types is regulated in reproduction licensing agreements. All activities that are performed
regarding the development, maintenance, and service of a product type, regardless of how often
it is manufactured, refer to the product type.
According to Figure 1, each produced unit of a product type represents a product instance of
this type. The product instance is always an individual entity and shall be identified by an
unambiguous identifier (such as a serial number). The right to use product instances of software
products is regulated by license agreements.
NOTE 1 Some countries have specific guidelines. [9] .
Activities for a product instance are: manufacturing, all services during the life time, etc. It is
recommended to document activities related to the product instance throughout its life time for
e.g. asset management (see Figure 2).
NOTE 2 In some cases, there exists recommendations or regulation for archiving of history beyond the end of the
life time.
___________
Figures in square brackets refer to the bibliography.

– 14 – IEC 62890:2020 © IEC 2020
4.2 Life-Cycle-Model
The life-cycle of a product type is divided into phases as shown in Figure 2. Milestones are
associated to these phases (see the filled diamond in Figure 2) and the announcements (see
diamond in Figure 2).
NOTE 1 Each phase can be further detailed, if necessary.

Figure 2 – Generic Life-Cycle-Model of a product type
The life-cycle begins with the development phase, in which the product is developed as a
product type. During the development phase of a product type, the product type is developed
by some activities such as designing, testing, sales preparation, and trials (piloting) in the
targeted system environments. When the specified technical and commercial criteria have been
met, the product is released for sale (see milestone 1). Following the conclusion of successful
testing, Production preparation process and service preparation, the delivery release is
achieved (milestone 2). This enables manufacturing of the product, which means, in the context
of the introduced terminology, the instancing of the product type starts.
The sales phase follows the development phase. The operational business with the product
type finishes with the end of sales (see milestones 3). the end of production (see milestone 4)
is after the end of the sales phase and depends on technical and economic conditions. An
announcement of end of sales (milestone 3A) should be communicated to enable plant users
to cover their demands before end of production.
Standard service for the product begins with delivery release (see milestone 2) and ends with
end of standard service (see milestone 5). The after-sales support phase begins with the end
of sales (see milestone 3) and finishes with product abandonment. The end of standard service
(see milestone 5) occurs in the after-sales support phase prior to product abandonment. This
means that all product-related deliveries i.e. spare parts, documentation, etc. and standard
services provided by the producer end with the product abandonment. An announcement of end
of sales (milestone 5A) should be communicated to enable plant users to cover their service
demands before product abandonment. In the phase between milestone 5 and 6 special
services maybe available. After milestone 6, the product (type) is obsolete.
The sum of these phases for a product type is called the product life-cycle. The term "cycle" is
meant to express that there is a recurring sequence in the context of the product evolution
(Figure 3). These innovation cycles result in new product versions of the product. Rules for
versioning of a product type should be specified.

IEC 62890:2020 © IEC 2020 – 15 –
Process descriptions are used for all activities required for managing a product life-cycle,
enabling concurrent workflows while ensuring fulfillment of required quality criteria. This
process is usually referred to as the Product Life-Cycle-Management process (PLM process)
and comprises the type-related sub-processes portfolio management, definition, realization,
commercialization, and after-sales support.
In order to manage the history of design and design change of a product type, version and
revision are used. The product manufacturer should keep information regarding history of
design and design change available.

Figure 3 – Evolution of products (type with version and revision)
Product evolution is described by version number and revision number. More detailed
versioning conventions may be applied, for example a third level for minor error corrections or
a fourth level for build numbers of software products. This version information is highly relevant
with regard to the compatibility and requires version management conventions. Typically,
product types with different version numbers have their own after-sales support phase.
NOTE 2 In some industries, there are recommendations for version management for example the NAMUR
recommendation NE53 [10].
Figure 4 – Maintenance of products (type with version and revision)
The service provided in the after-sales support phase depends on service levels (see 5.7.2).
Typically, product types with different revision numbers are not maintained as individual
products. Instead, only the type with the latest revision has an after-sales support (see Figure 4).
In case of specific service contracts (see 5.7.4), other revisions may be maintained as well.
Each product instance has a life time (see Figure 5) that starts with production (milestone a),

– 16 – IEC 62890:2020 © IEC 2020
for example the hardware manufacturing, and ends with start of disassembling or with disposal
of this instance (milestone f). The product life time can last significantly longer than the end of
the life-cycle of the product type (milestone 6) (Figure 5). The essential section of the life time
is the time in use, which begins at milestone c, for example with the software
installation/activation, and ends with the decommissioning (milestone e), for example de-
installation or irreparable defect. The time in use can be interrupted by outage times (down
times).
The warranty period begins when the risk is passed to the customer (milestone b), for example
the handover of a plant to the customer after acceptance and ends in accordance with legal
regulations or customer contracts (milestone d). The warranty period is independent from the
milestone "end of sales".
All deliveries i.e. spare parts, documentation, etc. and standard services provided by the
producer, related to product types and instances, end with the product abandonment
(milestone 6). Support may be extended through special agreement.

Figure 5 – Life time of a product instance
4.3 Structure model
A system can be understood as a defined, structured set of elements (components) which fulfills
a function (system function) through interactions or interrelationships with each other. Systems
can be hierarchically structured, which means that they can consist of underlying systems
(which are then considered comp
...