WORKING GROUP

2305

ACCEPTANCE TESTING
of Digital Control Systems for
HV Substations

1.Introduction
The first industrial applications of
Digital Control Systems (DCS) in HV substations go back to the eighties. Since then,
the number of DCS in service grows each
year.
On the one hand the functions implemented up to now in these new control systems differ little from conventional systems,
and on the other hand, the processing and
the exchange of data within the DCS totally
differ from conventional systems : each processor in a DCS does the job of several independent and dedicated units in a conventional system, serial links replace classic
wiring, signals from the switchyard are
acquired once and put at the disposal of the
different processors via serial links instead
of being acquired in each of the dedicated
units. The difference also applies to the way
the systems are tested both during factory
tests and on-site.
Due to the integration of functions in
the DCS, the issue of availability of the DCS
is of a particular importance. As an example, we can consider switchyard control. We
usually distinguish three command levels:
bay level, substation level and remote control centre level. In a conventional system,
these three levels are independent. In a
DCS, depending on the selected architecture for the DCS, the same equipment handles the substation level and the interface
for the remote control centre.
This means that the loss of one equipment could result in the loss of these two
levels. This issue has to be studied during engineering and, to confirm system

integrity, a number of tests have to be carried out.

The integration of functions in the
DCS could give rise to test problems at the
time of later adaptations particularly when
the operating constraints require all or a
part of the installation to be kept in service during changes.
These observations induced Study
Committee 23 Substations to request the
WG to study acceptance tests of DCS in
greater detail.
The paper addresses the tests at the
manufacturers plant factory acceptance
tests as well as the tests on site.

2. Functions implemented in the control

system
Functions included in the DCS differ little from the conventional systems at
the exception of self checking functions
and automatic switching sequences that
are particular to DCS.

3. Comparison between Conventional

Control and Digital
Control System
It is fundamental to know the internal
workings of the DCS in order to be able to
lay down test procedures applicable to the
different cases described below. Today, we

23 05

WORKING GROUP 23.05

L. UYTTERSPROT (Belgium)
L. GRAINE (France)
W. DIETERLE (Germany)
H. NOGUCHI (Japan)
R. JEANNOT (France)
H. TIMMERMAN (The Netherlands)
G. SCANU (Italy)

often find in HV substations a decentralised architecture including, at bay level,

an acquisition unit and protective relays
connected with the acquisition unit via a
serial link and, at the substation level, a
central unit. The central unit is connected
to all bay units via a serial link. We find
in the central unit all functions related to
the substation level, the MMI, the interface
to the upper level and, in the bay units,
all functions particular to the bay.
The main feature of conventional systems is the physical independence of the
functions and the exchanges of information between the different units via pointto-point electrical links, each link corresponding to an information. Conversely,
with DCS, we have an integration of functions at bay level as well as at substation
level, plus sharing of the same serial links
between the different functions.

4. Conventional Control System - Test Procedure

In the tests of conventional control
systems there is a clear separation between
substation control and remote control,
usually materialised by a marshalling unit.
Tests are based on specifications, required
functionality and drawings.
Factory acceptance tests
Individual acceptance tests are performed on each unit. This will hardly give
rise to problems because each unit performs a clearly defined function.

No. 201 - April 2002 ELECTRA 21

C O N T I N U E D

W O R K I N G G R O U P 2305

23 05

Site acceptance tests

Site tests start again with all or a part
of the acceptance tests, but this time the
complete installation from HV apparatus up to the remote control centre will be
checked. Site tests are aimed basically at
checking the coherence between primary
and secondary equipment as well as
between the different units of the secondary installation (already tested during
factory acceptance tests).

Alstom (France)

The required test means vary from

unit to unit, e.g. for control and protection cubicles, a bay simulator and a test
set for analogue signals. The other units
mimic board, remote control cubicle,
etc. require elementary test means
capable to read or impose the exchanged
information. Of course, the link between
the remote control cubicle and the dispatching centre requires other test
means.

5.2 Different cases

Factory and site tests will differ according to the circumstances and the need to
minimise operating constraints :
New control system

5. Digital Control
System - Test Procedure

Addition of a bay (spare bay or

newly added bay)
Modification, addition of a function

5.1 General issues

We distinguish between Functional
test and Performance tests (control of time
delay for handling information, information flow, analysis of interference on serial
links, analysis of the loss of a module, covering of self checking).
Testing of the DCS requires on one
hand individual functional and performance tests for DCS, HV apparatus, protection relays, remote control, on the other
hand functional and performance tests of
the whole system.
Individual functional and performance tests are related to factory acceptance tests. For the DCS itself they are
mainly software tests.
Checking of the co-ordination with
HV apparatus and other existing equipment, if any, are related to site tests.

Software evolution
general purpose software (e.g.
UNIX, Windows)
firmware (programming functions implemented by the Manufacturer )
application software (programming functions implemented by
the Manufacturer or the User).
Modification, addition of a data
(database/ wiring)

5.3. Factory acceptance

test - New control system
5.3.1 Test items
In order to reduce site test items, the
scope of acceptance test at factory shall

cover all the test items except the limited ones that can be executed at site
only. This means that except the combination test with site equipment all the
test items shall be executed at factory.
Concerning priority of test items, basic
functions shall be confirmed first, for
example, telecontrol and local control
come first, and are followed by supporting systems. See table 1 which gives
a list of test items.
5.3.2 Test specification and environment
Preparing test specification
It is essential for both user and
manufacturer to jointly thoroughly
check test items and test procedures
in order to avoid omissions and to
clear misunderstandings.
Test items shall be determined so
as to cover entirely the engineering
specifications.
Each test item shall be documented with its purpose, the checking method, the assessment criteria and the density of recursiveness,
e.g. characteristic data collection
under different application modes
and status of operation.
Test specification shall be checked before issue by the different
engineering teams : software, hardware, design, etc.

No. 201 - April 2002 ELECTRA 23

C O N T I N U E D

Test environment
To create a test environment for the
DCS as close as possible to the real substation, it is preferable to assemble operator console, mimic board and telecontrol
equipment at the factory even if they are
under separate contracts. If this is not possible, for the telecontrol equipment for
example, we recommend to use a simulator instead.
System configuration, equipment and
tools which will be used for the acceptance
test are specified.
5.3.3.Organisation
Test execution and test management
organisations are described in a document
mentioning the distribution of the work
between user and manufacturer, the person who is responsible for the factory
acceptance tests and the person from the
users side who has authority for approval.
5.3.4 Schedule
It is necessary to consider the following critical periods in the schedule :
Possible periods for data amendments and software changes that may be
requested by the user.
Possible periods for software
improvements following faults detected
during the tests.
Periods for analysis and assessment
of the acceptance tests.
5.3.5 Test process and review
Tests shall be executed by using adequate tools to verify elementary and compound functions in short period efficiently. Continuous working tests,
combined tests and tests outside normal

conditions shall be executed to obtain

higher quality assurance and reliability.
These tests shall be carried out in accordance with test specifications. If any test
item differs from the test specifications,
the situation shall be documented.
The method for processing problems
or questions relating to a test item shall be
mentioned in the test specification. If software changes or modifications are necessary, the issue shall be clearly understood
by the test team and the related design files
shall be checked by designated people. The
tests after software changes or modifications shall cover all items related with the
modified item. Analysis of the results shall
include measured degree of performance,
the decision whether accepted or not, and
will mention tester name, approver name
and date. It is recommended for future system development to record for each item
the test process details such as period,
work-days, problems encountered, software modification, etc.
Test review will take place at the end
of each phase, i.e. after combined tests,
total system tests and users witness tests,
if applicable. This test review will be placed
under the responsibility of the nominated
person. The test review will be part of the
acceptance test report.
5.3.6 Management
The management plan concerns safety
during factory acceptance tests, test
progress, problem processing and system
environment. It will also organise the
meetings during test periods. Safety management covers safety at the factory related
to the use of temporary equipment.
Progress management monitors and controls actual progress compared to planned.
Problem management determines the
methods for problem documenting and
processing.
It also addresses the problems of questionable specifications or changes of specifications which arise during tests.
System environmental management
deals with history of change for hardware
and software platform. Software platform
covers application program, facility data,

internal data version, system configuration, swap file area and process priority,
etc.

5.4 Site acceptance test New control system

The purpose of the site test is not to
repeat factory acceptance test but to control the operation of the DCS in reality, i.e.
connected to all equipment such as primary equipment, protective relays, telecontrol.
The test items shall be focused on
power system operation and application,
not on software design or manufacturing.
At this stage software is considered as a
black box.
It is important to have a test document
specifying the following items:
organisation
test procedure and environment
test items and schedule

23 05

Provision for progress management, remedy management and

version management shall be made
in the test specification.
Initial state of the DCS shall be
stated for each test item.
Environmental requirements for
the tests.
Spot tests and new or existing
type-tests.

W O R K I N G G R O U P 2305

5.4.1 Organisation
The responsibility of the project leader
concerns the test document, the organisation of the test team, the execution of the
tests and the transfer of the tested system
to the user. The test team includes experts
in DCS, in protections, in primary equipment, in telecontrol. This test team may if
needed be strengthened with experts from
the manufacturer, depending on the test
teams expertise and on the results of factory acceptance test. Another possibility is
to call the manufacturer for particular
tests. The test team execute the tests
according to the test document.
5.4.2 Test procedure and environment
The tests are executed on site, i.e. in
the substation. The test procedure depends
on the status of the substation. In case of
a replacement of an existing control system, the switching of the primary equipment will be subject to authorisation by
the grid operator. Similarly, precautions
must be taken when executing tests involving telecontrol.

No. 201 - April 2002 ELECTRA 25

5.4.3 Test items and schedule

The test document contains a list of
test items. As factory acceptance tests have
already been performed it is not necessary
to repeat all those tests on site. Random
tests are sufficient. However, it is very
important to perform all test items related
to the working of the DCS in its real environment, i.e. connected to the H.V. equipment, telecontrol, The second objective
of the site tests is to control the coherence
between primary and secondary systems
and telecontrol.

5.5 Addition of a bay

5.5.1 Overview
Two cases arise : an additional bay has
already been planned for in the DCS, that
bay being an already installed spare one,
or in the other case the building of a new
bay is decided. In the first case, we suppose
that the engineering for the (spare) bay has
already been completed, all equipment is
installed and all tests have been done.
5.5.2 Spare bay
In this case, the existing DCS already
includes this bay. During site tests, the
spare bay and the related functions and
data were deactivated from DCS and will
now have to be activated. As all tests for the
spare bay have already been carried out
during the factory acceptance tests of the
existing DCS, factory acceptance tests for
the spare bay are not required and one can
proceed directly with the site test. As
already mentioned in the case of a new
DCS, the site tests are aimed at two objectives : control the working of the part of
the DCS relating to the new bay in its real
environment, and ascertain the coherence

between primary installation, DCS and

telecontrol.
Even in case of a spare bay some reengineering of the DCS may be necessary
due to evolution or modification of the
specifications.
5.5.3 Newly added bay
In this case nothing has been foreseen
for the additional bay in the DCS no
engineering, no equipment, no test. The
addition of a bay requires additional hardware, adaptation of the existing software
and extension of the database.
Furthermore, this addition has also
repercussions on substation level components and functions of the DCS e.g. MMI,
telecontrol interface and even on bay level
functions of existing bays e.g. substation
interlocking for which additional information has to be exchanged between bays.
The addition of functions will be studied
further. Which tests should be done ? The
answer to this question depends on the consequences for the DCS of the addition of
the new bay. If the database alone has been
modified, site tests are sufficient because
the existing bays remain unchanged. Conversely, in case of software adaptations, the
entire DCS should be tested. This is obviously impossible with the existing DCS and
the only option left is that of performing
factory acceptance tests on a reference DCS.

The problem is different if the addition is

made by the user. This requires that the user
should have the complete hardware and
software description of the DCS in order to
evaluate the consequences of the addition
of the bay. In this case, he must use his own
reference DCS.
Another aspect requires close attention : it is necessary to verify that the design
constraints of the DCS - e.g. maximum
number of bays, data - are still met when
the new bay is added.

23 05

The team executes the tests according to the test document, and tests results
are recorded in a test file. Faults have to be
repaired as soon as possible and the items
tested again.
When all items are successfully tested,
the user will take over the new installation
and put it in service. This last step concludes the work of the test team.

W O R K I N G G R O U P 2305

5.6 Modification, addition

of a function
Different cases arise : bay-related function or substation-related function, new
function or activation of an existing function in the software library. The methods
of testing will depend on the actual case.
In case of an entirely new function,
tests have to be carried out on a test system. This test system must be identical to
the existing DCS, this means same hardware and same software. For bay-related
functions the test system is composed of a
bay unit and a central unit. For substationrelated functions the test system consists
of a central unit and a number of bay
units. After these tests, the new functions
can be implemented in the real
BEL Engineering (Belgium)

C O N T I N U E D

No. 201 - April 2002 ELECTRA 27

C O N T I N U E D

5.7 Software update

There are three kinds of software in a
DCS :
system software, including firmware
application software
database.
The system software is the core of the
hardware (computer systems and peripheral equipment). The basic functionality
of the DCS is roughly dictated by the hardware and the system software (real-time
processing, database management, I/O
processing).
The application software is an extra
shell around the core. This software allows
the DCS to execute the functions described
in item 2. It contains a library of functions
which can be configured for each specific
application. This application software
mostly contains user-friendly language
allowing the user to develop specific functions, logic such as automatic switching
sequences, interlocking
Finally, the database is the result of the
configuration of the DCS for a specific
substation.
Software updates apply to the system
software as well as to application software.
A new release of system software of application software must be compatible with

the existing hardware, software and

database. It is the manufacturers responsibility to manage the various hardware,
system software and application software
versions.
What about tests ? From the definition
of system software and application software, it follows that a new release affects
the whole DCS. This entails that new tests
have to be carried out on a test system
identical to the existing DCS.

5.8 Modification, addition

of a data (database/wiring)
Problems encountered with modification/addition of a data are generally
related to the wiring.
When the wiring is changed a test has
to be performed to check the modification
from one point before it to one point after
it.
When only the database is changed,
keyboarding should be checked, completed by a software test or a site test if the
data is used for a function.

6. Implications on test
equipment
Having seen what tests to do in different cases factory and site acceptance
tests, new DCS or modification of an existing DCS we can now analyse the required
test equipment.
The following questions will help us
to select the most appropriate test equipment for each application.
Some answers depend on the experience of the user with DCS, others on the
terms of the contract between the user and
the Manufacturer.
Question no. 1 :
Test at substation level or at bay level?
This choice determines the size of the
simulator because the number of

Inputs/Outputs of the simulator is proportional to the number of bays. Technically, tests at the substation level are better
than tests at the bay level because the DCS
will be tested in working conditions similar to the reality. This is particularly important for avalanche testing (representing
enormous status changes) and for testing
functions common to several bays, for
example interlocking, automatism Also,
the cost, the size, the complexity of connecting the simulator increases proportionally to the number of Inputs/Outputs.
The problems related to configuration of
the simulator to make it consistent with the
H.V. installation must not be overlooked.
These different drawbacks have resulted in
substation simulators not being used much
in the case of conventional control systems.

23 05

DCS, where, depending on the local possibilities, some control tests can be
repeated.
In case of activation of an existing
function from the software library, we can
start from the hypothesis that the function
has already been tested during the factory
acceptance tests or, at least that the manufacturer has completely tested the function on a similar DCS. It results that complete tests on a reference DCS are no
longer necessary and the new function can
be directly implemented in the real DCS,
for which only some control tests are
needed. The same reasoning applies to the
modification of the configuration of an
existing function.

W O R K I N G G R O U P 2305

Question n 2 :
Simulation of the primary equipment
or only reading and imposing inputs/outputs? This choice determines the functionality included in the simulator. In the
second case - reading and imposing
inputs/outputs - there is no functionality
in the simulator. The simulation of the primary equipment requires functionality
such as switch on and switch off with corresponding feedback signals and realistic
response time, energy monitoring, simulation of abnormalities
Question n 3 :
Necessity of sophisticated tests like
measurement of response time of the
DCS, simulation of a high quantity of
events, ?
This choice may influence the technology used to build the simulator : it is
easier to generate an avalanche test with
a digital simulator than with a relay based
simulator.
Question n 4 :
What do we test? (See figure 1)
DCS only
DCS and remote control
all secondary equipment in the substation (except protection relay, auxiliaries)

No. 201 - April 2002 ELECTRA 29

W O R K I N G G R O U P 2305

C O N T I N U E D

all secondary equipment in the substation and remote control.

The answer has implications on the
test equipment?

Consequences
Place where to connect
Functionality to include
the simulator
in the simulator

What do we test ?

DCS only
via connectors in replacement of
the links with the bay
via test cards in the DCS

Simulation of
primary equipment
secondary equipment installed
between DCS and primary equipment
Or only reading outputs and
imposing inputs

DCS and remote

control

same as DCS only

same as DCS only

7. Conclusions
We recommend to analyse carefully
the problem of overall testing of DCS from
the very start of engineering because it has
impacts on engineering, on test equipment, on project planning, on the terms
of the contract between the Manufacturer
and the user.
It was not possible to advise a universal method for testing DCS. The reasons
are numerous : different DCS architectures, differences in scope - how much is
done by the manufacturer and how much
by the user, different cases - new DCS in
a new substation, new DCS in an existing substation, extension of existing DCS,
software evolution, etc. We hope the
Reader will find in this paper enough ideas
for his own application.
We can emphasise some significant
points raised:
Importance of a test document describing test specifications, test organisation, test procedure, test schedule.
Importance testing all functions,
including those that will be used only later,
all spare bays. This will make easier the test
when it will be necessary to put in service
a new function or a spare bay.
The need in some cases to have a reference DCS same hardware, same software
as the real DCS for test purpose.According
to the case, this reference DCS will be run by
the manufacturer or by the user.

8. References
[1] P. Assailly, A. La Rocca, H. Adam,
Y. Bonnardot : Procedure for the design,
manufacture and commissioning of H.V.
and E.H.V substation control systems within
EDF (CIGRE 1992 Report 23-201).

Secondary equipment At the interface between primary

and secondary equipment

Simulation of primary equipment

Or only reading outputs and
imposing inputs

Secondary equipment same as Secondary equipment

and remote control

same as Secondary equipment

Remote Control

23 05

DCS only

Remote control
center

DCS
Central Unit
Substation level

Protections

Bay computer

Bay
level

Other
functions
outside
DCS

Control &
Protection
Cubicle

H.V. switchgear
FIGURE 1

[2] R. Cornu-Emieux, M. Rolland :

Lutilisation des techniques numriques
pour le contrle, la protection et la mesure
dans un poste HT/MT (CIGRE 1988
Report 23-16).
[3] J.M. Theunissen, R. Niemack, G.C.
Oosthuyse, B. Young : Protection and control testing opportunities for modularised
bay secondary equipment in transportable
bay kiosks (CIGRE SC34 1995 - Colloquium Stockholm Report 34-108).

[4] C.G.A Koreman, M. Kezunovic, S.

Lemmer, A. Newbould : Configuration et
intgration du contrle-commande des
postes (CIGRE 1996 Report 34-106).
[5] F.L. Baldinger, N.J.A. Duindam, E.
van der Helm, H. Timmerman : Impact
of a Substation Automation System (SAS)
on engineering, management, maintenance
and required educational level of utility staff
(CIGRE SC 34 1993 Colloquium Antwerpen)

No. 201 - April 2002 ELECTRA 31