IEC TR 61850-90-20:2025

IEC TR 61850-90-20 ®
Edition 1.0 2025-08
TECHNICAL
REPORT
Communication networks and systems for power utility automation -
Part 90-20: Use cases of redundancy in systems
ICS 33.200  ISBN 978-2-8327-0614-5

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
IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC copyright
or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local
IEC member National Committee for further information.

IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Discover our powerful search engine and read freely all the
The advanced search enables to find IEC publications by a
publications previews, graphical symbols and the glossary.
variety of criteria (reference number, text, technical With a subscription you will always have access to up to date
committee, …). It also gives information on projects, content tailored to your needs.
replaced and withdrawn publications.

Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished The world's leading online dictionary on electrotechnology,
Stay up to date on all new IEC publications. Just Published containing more than 22 500 terminological entries in English
details all new publications released. Available online and and French, with equivalent terms in 25 additional languages.
once a month by email. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer
Service Centre: sales@iec.ch.
CONTENTS
FOREWORD . 3
INTRODUCTION . 5
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 7
4 Abbreviations . 8
5 Introduction to redundancy concepts. 8
5.1 General . 8
5.2 Standby redundancy . 9
5.2.1 General. 9
5.2.2 Cold standby redundancy . 9
5.2.3 Warm standby redundancy . 10
5.2.4 Hot standby redundancy . 10
5.2.5 1:N redundancy . 11
5.3 Active-active redundancy . 11
5.3.1 Active-active (hot-hot) redundancy . 11
5.3.2 Active-active redundancy with load balancing . 12
5.4 Modular redundancy . 13
5.4.1 General. 13
5.4.2 Dual modular redundancy . 13
5.4.3 Triple modular redundancy . 13
5.5 Partial redundancy . 14
6 Use cases . 14
6.1 General . 14
6.1.1 Overview . 14
6.1.2 Client redundancy . 15
6.1.3 Server redundancy . 15
6.1.4 Actors . 15
6.1.5 State machine . 15
6.2 Use case 1: Startup of redundant clients . 16
6.2.1 Overview . 16
6.2.2 Use case description . 17
6.3 Use case 2: State change of redundant clients . 18
6.3.1 Overview . 18
6.3.2 Use case description . 18
6.4 Use case 3: Redundant reporting . 20
6.4.1 Overview . 20
6.4.2 Use case description . 20
6.5 Use case 4: Startup of redundant servers . 22
6.5.1 Overview . 22
6.5.2 Use case description . 22
6.6 Use case 5: State change of redundant servers . 23
6.6.1 Overview . 23
6.6.2 Use case description . 23
6.7 Service on demand use cases . 24
6.7.1 Overview . 24
6.7.2 Use case 6: Redundant clients perform service on demand on single
server . 25
6.7.3 Use case 7: Single client performs service on demand on redundant
servers . 26
6.7.4 Use case 8: Redundant clients perform service on demand on
redundant servers . 28
Bibliography . 30

Figure 1 – Basic redundancy scheme, Redundant Client . 5
Figure 2 – Basic redundancy scheme, Redundant server . 5
Figure 3 – Cold standby redundancy . 10
Figure 4 – Warm standby redundancy . 10
Figure 5 – Hot standby redundancy . 11
Figure 6 – 1:N redundancy . 11
Figure 7 – Active – Active redundancy . 12
Figure 8 – Active-aActive redundancy with load balancing . 12
Figure 9 – Dual modular redundancy . 13
Figure 10 – Triple modular redundancy . 14
Figure 11 – Simplified state diagram for Initialization and change of state for one IED . 16
Figure 12 – Collaboration diagram for use case 1 – Startup of redundant clients . 16
Figure 13 – Collaboration diagram for use case 2 – State change of redundant clients . 18
Figure 14 – Collaboration diagram for use case 3 – Redundant reporting . 20
Figure 15 – Collaboration diagram for use case 4 – Startup of redundant servers. 22
Figure 16 – Collaboration diagram for use case 5 – State change of redundant servers . 23
Figure 17 – Collaboration diagram for use case 6 – Service on demand from redundant
clients on single server . 25
Figure 18 – Collaboration diagram for use case 7 – Service on demand from single
client on redundant servers . 27
Figure 19 – Collaboration diagram for use case 8 – Service on demand from redundant
clients to redundant servers . 28

Table 1 – Actors . 15

INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
Communication networks and systems for power utility automation -
Part 90-20: Use cases of redundancy in systems

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) IEC draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights in
respect thereof. As of the date of publication of this document, IEC had not received notice of (a) patent(s), which
may be required to implement this document. However, implementers are cautioned that this may not represent
the latest information, which may be obtained from the patent database available at https://patents.iec.ch. IEC
shall not be held responsible for identifying any or all such patent rights.
IEC TR 61850-90-20 has been prepared by IEC technical committee 57. It is a Technical
Report.
The text of this Technical Report is based on the following documents:
Draft Report on voting
57/2786/DTR 57/2817/RVDTR
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this Technical Report is English.
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available
at www.iec.ch/members_experts/refdocs. The main document types developed by IEC are
described in greater detail at www.iec.ch/publications.
A list of all parts in the IEC 61850 series, published under the general title Communication
networks and systems for power utility automation, can be found on the IEC website.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the
specific document. At this date, the document will be
• reconfirmed,
• withdrawn, or
• revised.
INTRODUCTION
Parts of this document are based on IEC TR 61850-90-2, Communication networks and systems
for power utility automation – Part 90-2: Using IEC 61850 for communication between
substations and control centres.
Redundancy is used to increase the availability of a system. This document describes different
types of redundancy (denoted as redundancy schemes), while focusing on device redundancy.
Put into simple words, device redundancy is using two physically different devices for the same
purpose. If one of them fails, the other one takes over. The failover time of the affected
components, which results in a downtime of this part of the system, is as little as possible. In
this way, continuous operation is ensured. Loss of data can be avoided.
Since redundant devices provide equal functionality at the same time, information flow to and
from these devices is often duplicated. Therefore, components of a redundant system are able
to handle duplicated data.
Figure 1 and Figure 2 describe two basic redundancies. The first one shows redundant clients,
the second one shows redundant servers. Blue lines indicate dataflow, the green dotted lines
indicate an option for shared data between the two redundant components. In the first example
a server in IED A has two redundant clients, one in each of IED G and H. In the second example,
a client in IED H has two redundant servers, IED A and IED B.

Figure 1 – Basic redundancy scheme, Redundant Client

Figure 2 – Basic redundancy scheme, Redundant server
For the communication between the redundant system application and the lower level IEDs
typically IEC 61850 is used, mainly based on IEC 61850-8-1(MMS) reporting and commands,
for time critical functions with IEC 61850-8-1(GOOSE) and IEC 61850-9-2(SV).
For the communication with clients at station level typically IEC 61850 based on MMS is also
used for supervision, commands, and configuration changes. Since MMS is an acknowledged
service, server and client are aware of each other and the client supervises the servers.
To enable changes of settings or configuration data without having contradicting behaviour, the
higher-level client must be able to switch the standby IED entity to off, thus invalidating all
application related output data for any possible receivers.
Since GOOSE and SV are unacknowledged services, the sender does not need to be aware of
any receivers. The receivers are only aware of the message (application) addresses, and not
of the physical senders, a separate supervision of the physical senders might be necessary.
Setting the application mode of the active IED entity to off could be one possibility to force a
switchover to the standby unit. This especially means that the deactivated entity does no longer
send GOOSE and SV messages. Other methods for triggering a switchover are discussed in
this document.
In this document several use cases are elaborated and presented to serve as input to a future
edition of this document to extend initialization and synchronization requirements based on
these use cases.
1 Scope
This part of IEC 61850, which is a technical report, describes use cases of redundancy in
systems.
This document considers use cases of duplication of function and devices and covers
redundancy of information flow at message level. Functional safety is out of scope of this
document. To keep focus on details relevant for this document, some figures and drawings do
not show electrical wiring, redundant coils, etc, where this is not important for the use case.
This document is not a guideline on the design of redundancy systems; guidance on designing
redundancy systems can be found in textbooks such as [1] and [2].
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following
addresses:
• IEC Electropedia: available at https://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp
3.1
entity
common denomination for any participant in the redundancy scheme, e.g. an IED, an MU or a
SCADA client
3.2
active
state in which the entity is actively controlling and/or supervising other entities
Note 1 to entry: "hot" is used as a synonym for "active" (see 5.3.2).
3.3
standby
state in which the entity is currently passive
Note 1 to entry: It can be in a hot, warm or cold state. Often such an entity is also called "passive".
3.4
isolated
state in which the entity is temporarily not participating in the redundancy scheme
3.5
redundancy state
current role which an entity assumes in the redundancy scheme, i.e. active, standby or isolated
___________
Numbers in square brackets refer to the Bibliography.
3.6
hot standby
redundancy concept where two physically different entities operate simultaneously
SEE: 5.2.4
3.7
voter
mechanism that gets more than one input for the same signal and decides which of them will
be sent on
3.8
availability
percentage of time that a system is up and running for a given mission time
4 Abbreviations
DO Data object inside a logical node
IED Intelligent Electronic Device
MU Merging Unit
SCADA Supervisory control and data acquisition
5 Introduction to redundancy concepts
5.1 General
This clause describes options for redundancy schemes in a general manner.
In engineering, redundancy is usually understood as the duplication of critical components or
functions of a system with the intention of increasing the availability. Adding redundancy
typically increases the cost and complexity of a system design but might be considered to meet
other system requirements. The type of redundancy is application dependent.
The following redundancy schemes will be discussed in this document:
a) Standby redundancy
• Cold standby redundancy
• Warm standby redundancy
• Hot standby redundancy
• 1:N redundancy
b) Active-active redundancy (hot-hot redundancy)
• Active-active redundancy (load balanced)
c) Modular redundancy
• Dual modular redundancy
• Triple modular redundancy
d) Partial redundancy
e) Network redundancy
The concept of network redundancy is already covered in other parts of the IEC 61850 series
and is not in the scope of this document. Consequentially it is not covered in this document and
is only mentioned here for completeness.
Without redundancy, the system downtime depends on the following:
f) Time to detect the problem
g) Time to analyse the problem
h) Time for repair or replacement
i) Time for the system to become fully operational again
j) Error coverage
In case of a hardware failure, an option is to replace the failed component or system. Depending
on the accessibility and availability of spare parts, replacement can take minutes to days. In
case of a software failure, a reboot of the system might temporarily repair it. Depending on the
complexity of the system, such a reboot can take seconds to hours.
Applying redundancy, the possible downtime depends on the time to detect a failure and the
time to switch over to a backup system. This can be in the range of seconds to minutes. Some
systems achieve sub-millisecond downtimes. Correctly applied, redundancy can therefore
improve the availability by several orders of magnitude.
The controlling system and the controlled system must be considered together, when evaluating
redundancy requirements, specifically to reduce the impact of common-mode or common-cause
failures. These failures occur when several failures have the same source. An introduction to
common-mode failures can be found in [4] and [5].
The following subclauses describe the redundancy schemes in greater detail.
5.2 Standby redundancy
5.2.1 General
Standby redundancy is characterized by the fact that there is an active entity and a standby
entity. The active entity is fully operational. It depends on the redundancy scheme if the standby
entity performs any operations.
The figures in this section use colours to indicate the operational state and the data flow:
a) Red indicates an operational part of an entity.
b) Blue indicates a non-operational part of an entity.
c) Blue lines indicate control of switching redundancy states.
d) Green lines indicate supervision.
e) Black lines indicate command data flow.
Active entity and standby entity can monitor each other to decide if a switchover is required,
e.g. by comparing their respective health state. Alternatively, or additionally, a third component
can monitor the system and decide if a switchover is required. This decision is based on
parameters defined in the application monitoring the system. In Figure 3 to Figure 8 this
application is labelled Fault Detection.
5.2.2 Cold standby redundancy
In cold standby, the standby entity is powered off. In case of a redundancy switch, the standby
entity is power up and acquires active state.
The decision as to whether a redundancy switch is required is made by the fault detection
mechanism, which is implemented by the redundancy scheme, as illustrated in Figure 3.
Figure 3 – Cold standby redundancy
In a cold standby scheme, a switchover will take at least several minutes. Loss of data is very
likely.
5.2.3 Warm standby redundancy
In warm standby, the standby entity is powered up, but it is not sending, receiving, or processing
process data. In case of a redundancy switch, the standby entity will acquire active state. The
decision as to whether a switch-over is required is taken as described in 5.2.2. Data can be
mirrored to the standby entity in real time, as illustrated in Figure 4.

Figure 4 – Warm standby redundancy
In a warm standby scheme, a switchover will take at least a few seconds. Loss of data can
happen. Clients can reduce the probability of data loss by using buffered reporting.
5.2.4 Hot standby redundancy
In hot standby, the standby entity receives and processes process data the same way the active
one does. Hence both entities have identical data and an identical data and process history.
The standby entity does not send any commands. Upon failure of the active entity, the standby
entity can immediately take over. The decision as to whether a switch-over is required is taken
as described in 5.2.2, as illustrated in Figure 5.
Figure 5 – Hot standby redundancy
In a hot standby scheme, a switchover can be performed in milliseconds. Supervised IEDs,
network and supervising system are able to deal with the doubled load of data transfer. The
supervising system can handle redundant data.
5.2.5 1:N redundancy
1:N redundancy is a design technique where a single backup system is used for multiple primary
systems. It can apply any of the redundancy schemes described above.
The backup system can function as any of the primary systems. This technique offers
redundancy at a lower cost than the before mentioned redundancy schemes. This approach
works well when the primary systems have similar functions, and the backup system can back
up any of them in case one of the primary systems fails, as illustrated in Figure 6.

Figure 6 – 1:N redundancy
5.3 Active-active redundancy
5.3.1 Active-active (hot-hot) redundancy
In an active-active redundancy both entities are fully operational, receiving, processing and also
sending process data in parallel. Data can be mirrored between the entities, as illustrated in
Figure 7.
Figure 7 – Active – Active redundancy
In an active-active scheme, virtually no switchover time occurs. The consuming application in
command direction is able to handle the duplicated data, i.e. performs only one control action
although it receives two commands (one from each of the active entities). As in the hot standby
scheme, the supervising system can handle redundant data.
NOTE Figure 7 shows the fault scenario, which means IED 2 has been taken off the redundancy scheme and is in
redundancy state isolated. During normal operation conditions, both switches would be closed.
5.3.2 Active-active redundancy with load balancing
In this redundancy scheme the entities are both active and fully operational. A load balancer
distributes the workload between the entities. Upon failure the remaining entity takes over the
whole load. Data can be mirrored between the entities, as illustrated in Figure 8.

Figure 8 – Active-aActive redundancy with load balancing
Each entity is able to handle the required load alone, in case the other one fails.
Since load balancing is not a distinctly different redundancy scheme, it is not further elaborated
in this document.
5.4 Modular redundancy
5.4.1 General
Modular redundancy, also known as parallel redundancy, refers to the approach running
multiple entities in parallel. All entities are synchronized and receive the same input information
at the same time. Their output values are compared and a voting mechanism (voter) decides
which output values to use.
5.4.2 Dual modular redundancy
The dual modular redundancy uses two functionally identical entities; both are able to control
the process. Because both entities receive the same input data, the voter decides what to do if
the entities give different commands. The most challenging aspect is determining which entity
is correct when there is a discrepancy. Different voting strategies are possible, which one to
choose is application specific. This is illustrated in Figure 9.

Figure 9 – Dual modular redundancy
5.4.3 Triple modular redundancy
Triple modular redundancy uses three functionally identical entities to provide redundancy
backup. The approach is very common in critical applications like aerospace. Triple modular
redundancy is more reliable than dual modular redundancy. In addition to having three entities
processing the same data, the entities could be implemented on different hardware and
software platforms from different vendors, each designed to solve the same problem using the
same common requirements. The voter decides which system controls the process. With triple
modular redundancy the decision which system to trust is made democratically and the majority
rules. In the case of three different results the voter has a fall-back strategy. The drawback of
the triple modular redundancy is the costs. This is illustrated in Figure 10.
Figure 10 – Triple modular redundancy
5.5 Partial redundancy
Partial redundancy is not a redundancy mechanism on its own but describes a situation where
some functions within a set of devices follows one of the redundancy schemes described above
and other functions within these devices have no redundancy. This situation is sometime also
referred to as "functional redundancy".
Partial redundancy typically is used for server redundancy where entities are aware of each
other. The redundant part is then the operative part of the unit and to be viewed as any of the
entities described above. The entities establish a connection between their non redundant parts
by either GOOSE or Ethernet. Which one is chosen is application specific.
In terms of redundancy the non-redundant part of an entity can implement:
a) A fault detection mechanism. Such a mechanism is able to detect certain faults quicker than
a supervising system.
b) A mechanism for synchronizing the entities.
In this way, using partial redundancy, some fault detection can be done by the entities
themselves, also calculating an individual health state and monitoring each other. The
mechanism negotiating the role in the redundancy scheme is robust so that always only one
server assumes the active role. The units reveal their role in the redundancy scheme to a
supervising client. It depends on the implementation if the units also reveal their health state to
a supervising client.
6 Use cases
6.1 General
6.1.1 Overview
The use cases outlined in this document are not a complete collection of use cases for the
power system domain. They do not imply any specific solution or implementation. They are
collected to provide the basis for extending the IEC 61850 standard.
Use cases describe typical functions which are applicable to power utility automation systems.
These use cases can include operational, engineering and testing activities.
The switch-over between entities in any redundant system can either be triggered automatically
by a fault detection mechanism or manually by a human actor.
The descriptions cover only certain redundancy schemes, chosen to illustrate the most common
use cases. They can be applied to other schemes by adding missing steps, e.g. powering up a
redundant entity in case of cold stand by redundancy.
6.1.2 Client redundancy
For client redundancy, the use case descriptions cover the following redundancy schemes:
a) Warm standby redundancy.
b) Hot standby redundancy.
c) Active – active redundancy.
6.1.3 Server redundancy
For server redundancy, the use case descriptions cover the following redundancy schemes:
a) Hot standby redundancy.
b) Active – active redundancy.
Warm standby redundancy is not covered since this redundancy scheme is not feasible for
servers.
Servers, which participate in a redundancy scheme, expose their role in the redundancy scheme
to clients. This can be done by e.g. writing a specified value to a dedicated data attribute of
functional constraint ST.
NOTE To ensure interoperability it seems to be feasible to clearly specify DOs which are used for this or similar
kind of data.
6.1.4 Actors
Actors participating in the following use cases are listed in Table 1.
Table 1 – Actors
Name Role description
Operator A user having to intervene on the substation automation system.
Fault detection mechanism An application running at any level of hierarchy that supervises the state of an
entity participating in the redundancy scheme.
Control application Any function executing or requesting a service either automatically or triggered
by an operator or a fault detection mechanism.
Controlled entity A device receiving and processing requests, e.g. a circuit breaker.
Client An actor representing a client role in a client-server configuration.
Server An actor representing a server role in a client-server configuration.
6.1.5 State machine
Figure 11 shows a simplified state diagram which applies to the most common use cases.
Figure 11 – Simplified state diagram for Initialization and change of state for one IED
6.2 Use case 1: Startup of redundant clients
6.2.1 Overview
The use case applies to two clients and a single server as shown in Figure 12.

Figure 12 – Collaboration diagram for use case 1 – Startup of redundant clients
6.2.2 Use case description
6.2.2.1 General
This use case describes the start-up routines of clients.
Start-up includes the following steps:
a) On start up one of the clients assumes the active role. It depends on the redundancy
scheme, if the other one also assumes the active role or becomes the standby client.
b) The active client establishes connection to the server. It depends on the redundancy
scheme, if the redundant client also establishes connection.
c) The active client configures report communication. It depends on the redundancy scheme,
if the redundant client also configures report communication.
6.2.2.2 Start up in case of warm standby redundancy
Use case step Description
Prerequisites Both clients are powered off. The server is running and is working correctly within its defined
parameters.
Network connections are available and conform to the requirements of the redundancy
scheme.
The redundancy scheme has a dedicated primary client defined.
Step 1 Upon system start, the dedicated primary client assumes the active role, the other one
becomes the standby client.
Step 2 The active client establishes connection to the server.
It depends on the implementation, if the standby client also establishes connection.
Step 3 The active client configures report communication and can send or receive data.

6.2.2.3 Start up in case of hot standby redundancy
Use case step Description
Prerequisites Both clients are powered off. The server is running and is working correctly within its defined
parameters.
Network connections are available and conform to the requirements of the redundancy
scheme.
The redundancy scheme has a dedicated primary client defined.
Step 1 Upon system start, the dedicated primary client assumes the active role, the other one
becomes the standby client.
Step 2 Both clients establish connection to the server.
Step 3 Both clients configure report communication and can send or receive data.

6.2.2.4 Start up in case of active-active redundancy
Use case step Description
Prerequisites Both clients are powered off. The server is running and is working correctly within its defined
parameters. It is able to handle duplicated data.
Network connections are available and conform to the requirements of the redundancy
scheme.
Step 1 Upon system start, both clients assume active role.
Step 2 Both clients establish connection to the server.
Step 3 Both clients configure report communication and can send or receive data.

6.3 Use case 2: State change of redundant clients
6.3.1 Overview
The use case applies to two clients and a single server as shown in Figure 13.

Figure 13 – Collaboration diagram for use case 2 – State change of redundant clients
It depends on the implementation if the active client communicates its state information to the
standby client. This communication can take place either on the main network or on a private
channel (for example, a dedicated Ethernet link, used for the communication between the
entities of a redundancy scheme). One possible communication is a heartbeat signal which
periodically announces that the active client is still healthy.
NOTE Implementors are advised to consider potential communication load due to coordination of data between
active and standby clients. For further recommendations see IEC TR 61850-90-4.
6.3.2 Use case description
6.3.2.1 General
This use describes a change of states of clients. In case of standby redundancy this means that
the active client changes to either standby or isolated while the standby client becomes the
active client. Such state change can be triggered by either a fault detection mechanism or an
operator.
A client which is out of the redundancy scheme is termed an isolated client. While a client is
out of the redundancy scheme, it can be put into various test modes, reconfigured, have the
firmware updated, etc. Two actions with respect to the redundancy scheme can be taken with
an isolated client:
a) Join the redundancy scheme as a standby client.
b) Join the redundancy scheme as an active client.
A state change includes the following steps:
c) An operator or a fault detection mechanism request an active client to become either
standby or isolated.
d) In case of standby redundancy an application specific mechanism requests the standby
client to assume the active role.
6.3.2.2 State change in case of warm standby redundancy
The use case describes non-redundant reporting, i.e. both clients use the same set of report
control blocks on the server. Redundant reporting is described in 6.4.
Use case step Description
Prerequisites Both clients and the server are running and working correctly within their defined
parameters.
The active client is connected to the server. It depends on the implementation, if the standby
client is also connected. Only the active client has configured report communication and can
send and receive data.
Network connections are available and conform to the requirements of the redundancy
scheme.
Step 1 Operator or fault detection mechanism request a state change from the control Application.
Step 2a Control application requests the active client to become either standby or isolated.
Step 2b There can be a synchronisation between the clients.
Step 3 Active client frees the reports and stops all communication with the server.
Step 4a Control application requests the formerly standby client to assume the active role.
Step 4b In case the new active client has not yet connected to the server, it establishes the
connection.
Step 5 The new active client configures report communication and can send and receive data.
Step 6 Client(s) notify control application about the result of the state change.
Step 7 Control application notifies the operator.

6.3.2.3 State change in case of hot standby redundancy
Use case step Description
Prerequisites Both clients and the server are running and working correctly within their defined
parameters.
Both clients are connected to the server. Both clients have configured report communication
and can receive data. Only the active client can send data.
Network connections are available and conform to the requirements of the redundancy
scheme.
Step 1 Operator or fault detection mechanism request a state change from the control application.
Step 2a Control application requests the active client to become either standby or isolated.
Step 2b There can be a synchronisation between the clients.
Step 3 In case the active client has been sent to isolated, it frees the reports and stops all
communication with the server.
Step 4 Control application requests the formerly standby client to assume the active role.
Step 5 The new active client can now also send data.
Step 6 Client(s) notify control application about the result of the state change.
Step 7 Control application notifies the operator.

6.3.2.4 State change in case of active – active redundancy
During normal operation both clients are fully operational, therefore this use case applies only
in case of a fault of one of the clients.
Use case step Description
Prerequisites Both clients and the server are running and working correctly within their defined
parameters.
Both clients are connected to the server. Both clients have configured report communication
and can send and receive data, i.e. both client-entities are working in parallel.
Network connections are available and conform to the requirements of the redundancy
scheme.
Step 1 Operator or fault detection mechanism request a state change from the control application.
Step 2a Control application requests the active client to become isolated.
Step 2b There can be a synchronisation between the clients.
Step 3 Active client frees the reports and stops all communication with the server.
Step 4 Client(s) notify co
...