WORKING GROUP
23•05
ACCEPTANCE TESTING
of Digital Control Systems for
HV Substations
WORKING GROUP 23.05
1.Introduction
The first industrial applications of
Digital Control Systems (DCS) in HV sub-
stations go back to the eighties. Since then,
the number of DCS in service grows each
year.
On the one hand the functions imple-
mented up to now in these new control sys-
tems 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 pro-
cessor in a DCS does the job of several inde-
pendent and dedicated units in a conven-
tional 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 exam-
ple, we can consider switchyard control. We
usually distinguish three command levels:
bay level, substation level and remote con-
trol centre level. In a conventional system,
these three levels are independent. In a
DCS, depending on the selected architec-
ture for the DCS, the same equipment han-
dles the substation level and the interface
for the remote control centre.
This means that the loss of one equip-
ment could result in the loss of these two
levels. This issue has to be studied dur-
ing engineering and, to confirm system
integrity, a number of tests have to be car-
ried 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 ser-
vice 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
manufacturer’s plant – factory acceptance
tests – as well as the tests on site.
2. Functions imple-
mented in the control
system
Functions included in the DCS dif-
fer little from the conventional systems at
the exception of self checking functions
and automatic switching sequences that
are particular to DCS.
3. Comparison bet-
ween “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
L. UYTTERSPROT (Belgium)
L. GRAINE (France)
W. DIETERLE (Germany)
H. NOGUCHI (Japan)
R. JEANNOT (France)
23 • 05
H. TIMMERMAN (The Netherlands)
G. SCANU (Italy)
often find in HV substations a decen-
tralised 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 sys-
tems is the physical independence of the
functions and the exchanges of informa-
tion between the different units via point-
to-point electrical links, each link corre-
sponding to an information. Conversely,
with DCS, we have an integration of func-
tions at bay level as well as at substation
level, plus sharing of the same serial links
between the different functions.
4. Conventional Con-
trol System - Test Pro-
cedure
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 per-
formed on each unit. This will hardly give
rise to problems because each unit per-
forms a clearly defined function.
No. 201 - April 2002 ELECTRA 21

The required test means vary from
unit to unit, e.g. for control and protec-
tion 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 dis-
patching centre requires other test
means.
➤ Site acceptance tests
Site tests start again with all or a part
of the acceptance tests, but this time the
complete installation from HV appara-
tus 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 sec-
ondary installation (already tested during
factory acceptance tests).
5. Digital Control
System - Test Proce-
dure
5.1 General issues
We distinguish between Functional
test and Performance tests (control of time
delay for handling information, informa-
tion flow, analysis of interference on serial
links, analysis of the loss of a module, cov-
ering of self checking).
Testing of the DCS requires on one
hand individual functional and perfor-
mance tests for DCS, HV apparatus, pro-
tection relays, remote control, on the other
hand functional and performance tests of
the whole system.
Individual functional and perfor-
mance tests are related to factory accep-
tance tests. For the DCS itself they are
mainly software tests.
Checking of the co-ordination with
HV apparatus and other existing equip-
ment, if any, are related to site tests.
C O N T I N U E D
5.2 Different cases
Factory and site tests will differ accord-
ing to the circumstances and the need to
minimise operating constraints :
➤ New control system
➤ Addition of a bay (spare bay or
newly added bay)
➤ Modification, addition of a func-
tion
➤ Software evolution
● general purpose software (e.g.
UNIX, Windows)
● firmware (programming func-
tions implemented by the Manu-
facturer )
● application software (program-
ming 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
W O R K I N G G R O U P 23•05
© Alstom (France)
23 • 05
cover all the test items except the lim-
ited ones that can be executed at site
only. This means that except the com-
bination 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 sup-
porting systems. See table 1 which gives
a list of test items.
5.3.2 Test specification and envi-
ronment
➤ 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 docu-
mented with its purpose, the chec-
king method, the assessment crite-
ria and the density of recursiveness,
e.g. characteristic data collection
under different application modes
and status of operation.
● Test specification shall be chec-
ked before issue by the different
engineering teams : software, hard-
ware, design, etc.
No. 201 - April 2002 ELECTRA 23

● Provision for progress manage-
ment, 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.
➤ Test environment
To create a test environment for the
DCS as close as possible to the real sub-
station, it is preferable to assemble opera-
tor console, mimic board and telecontrol
equipment at the factory even if they are
under separate contracts. If this is not pos-
sible, for the telecontrol equipment for
example, we recommend to use a simu-
lator 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 per-
son who is responsible for the factory
acceptance tests and the person from the
user’s side who has authority for approval.
5.3.4 Schedule
It is necessary to consider the follow-
ing critical periods in the schedule :
➤ Possible periods for data amend-
ments 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 ade-
quate tools to verify elementary and com-
pound functions in short period effi-
ciently. Continuous working tests,
combined tests and tests outside normal
C O N T I N U E D
conditions shall be executed to obtain
higher quality assurance and reliability.
These tests shall be carried out in accor-
dance 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 soft-
ware changes or modifications are neces-
sary, 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 modifica-
tions 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 sys-
tem development to record for each item
the test process details such as period,
work-days, problems encountered, soft-
ware modification, etc.
Test review will take place at the end
of each phase, i.e. after combined tests,
total system tests and user’s 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 man-
agement covers safety at the factory related
to the use of temporary equipment.
Progress management monitors and con-
trols actual progress compared to planned.
Problem management determines the
methods for problem documenting and
processing.
It also addresses the problems of ques-
tionable specifications or changes of spec-
ifications which arise during tests.
System environmental management
deals with history of change for hardware
and software platform. Software platform
covers application program, facility data,
W O R K I N G G R O U P 23•05
internal data version, system configura-
tion, swap file area and process priority,
etc.
5.4 Site acceptance test -
New control system
23 • 05
The purpose of the site test is not to
repeat factory acceptance test but to con-
trol the operation of the DCS in reality, i.e.
connected to all equipment such as pri-
mary equipment, protective relays, tele-
control.
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
5.4.1 Organisation
The responsibility of the project leader
concerns the test document, the organisa-
tion 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 equip-
ment, in telecontrol. This test team may if
needed be strengthened with experts from
the manufacturer, depending on the test
team’s expertise and on the results of fac-
tory 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 environ-
ment
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 sys-
tem, the switching of the primary equip-
ment will be subject to authorisation by
the grid operator. Similarly, precautions
must be taken when executing tests involv-
ing telecontrol.
No. 201 - April 2002 ELECTRA 25

The team executes the tests accord-
ing 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 con-
cludes the work of the test team.
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 envi-
ronment, i.e. connected to the H.V. equip-
ment, 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 objec-
tives : control the working of the part of
the DCS relating to the new bay in its real
environment, and ascertain the coherence
C O N T I N U E D
between primary installation, DCS and
telecontrol.
Even in case of a spare bay some re-
engineering 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 hard-
ware, adaptation of the existing software
and extension of the database.
Furthermore, this addition has also
repercussions on substation level compo-
nents 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 infor-
mation 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 con-
sequences 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. Con-
versely, in case of software adaptations, the
entire DCS should be tested. This is obvi-
ously impossible with the existing DCS and
the only option left is that of performing
factory acceptance tests on a reference DCS.
W O R K I N G G R O U P 23•05
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 atten-
23 • 05
tion : 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.
5.6 Modification, addition
of a function
Different cases arise : bay-related func-
tion or substation-related function, new
function or activation of an existing func-
tion 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 sys-
tem. This test system must be identical to
the existing DCS, this means same hard-
ware and same software. For bay-related
functions the test system is composed of a
bay unit and a central unit. For substation-
related 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)
No. 201 - April 2002 ELECTRA 27

DCS, where, depending on the local pos-
sibilities, 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 man-
ufacturer has completely tested the func-
tion on a similar DCS. It results that com-
plete 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.
5.7 Software update
There are three kinds of software in a
DCS :
➤ system software, including firm-
ware
➤ application software
➤ database.
The system software is the core of the
hardware (computer systems and periph-
eral equipment). The basic functionality
of the DCS is roughly dictated by the hard-
ware 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 func-
tions, 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 appli-
cation software must be compatible with
C O N T I N U E D
the existing hardware, software and
database. It is the manufacturer’s respon-
sibility to manage the various hardware,
system software and application software
versions.
What about tests ? From the definition
of system software and application soft-
ware, 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 modifi-
cation/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, com-
pleted 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 dif-
ferent cases – factory and site acceptance
tests, new DCS or modification of an exist-
ing DCS – we can now analyse the required
test equipment.
The following questions will help us
to select the most appropriate test equip-
ment for each application.
Some answers depend on the experi-
ence 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
W O R K I N G G R O U P 23•05
Inputs/Outputs of the simulator is pro-
portional to the number of bays. Techni-
cally, tests at the substation level are better
than tests at the bay level because the DCS
will be tested in working conditions simi-
lar to the reality. This is particularly impor-
tant for avalanche testing (representing
enormous status changes) and for testing
23 • 05
functions common to several bays, for
example interlocking, automatism… Also,
the cost, the size, the complexity of con-
necting the simulator increases propor-
tionally 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.
Question n° 2 :
Simulation of the primary equipment
or only reading and imposing inputs/out-
puts? This choice determines the func-
tionality included in the simulator. In the
second case - reading and imposing
inputs/outputs - there is no functionality
in the simulator. The simulation of the pri-
mary equipment requires functionality
such as switch on and switch off with cor-
responding feedback signals and realistic
response time, energy monitoring, simu-
lation 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 tech-
nology 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 sub-
station (except protection relay, auxilia-
ries)
No. 201 - April 2002 ELECTRA 29
 C O N T I N U E D W O R K I N G G R O U P 23•05

➤ all secondary equipment in the sub-

Consequences
station and remote control.
What do we test ? Place where to connect Functionality to include
The answer has implications on the the simulator in the simulator
test equipment?
DCS only DCS only Simulation of
– via connectors in replacement of – primary equipment
the links with the bay – secondary equipment installed
– via test cards in the DCS between DCS and primary equip-
7. Conclusions ment
Or only reading outputs and

23 • 05
imposing inputs
We recommend to analyse carefully DCS and remote same as “DCS only” same as “DCS only”
the problem of overall testing of DCS from control
the very start of engineering because it has Secondary equipment At the interface between primary Simulation of primary equipment
impacts on engineering, on test equip- and secondary equipment Or only reading outputs and
ment, on project planning, on the terms imposing inputs

of the contract between the Manufacturer Secondary equipment same as “Secondary equipment” same as “Secondary equipment”
and the user. and remote control

It was not possible to advise a univer-

Remote Control Remote control
sal method for testing DCS. The reasons
center
are numerous : different DCS architec-
tures, differences in scope - how much is DCS
Central Unit
done by the manufacturer and how much
by the user, different cases - new DCS in Substation level
a new substation, new DCS in an exist-
ing substation, extension of existing DCS,
software evolution, etc. We hope the Bay computer Protections
Reader will find in this paper enough ideas
for his own application.
We can emphasise some significant
points raised: Bay
➤ Importance of a test document des- Other level
cribing test specifications, test organisa- functions
tion, test procedure, test schedule. outside
➤ Importance testing all functions, DCS
Control &
including those that will be used only later,
Protection
all spare bays. This will make easier the test Cubicle
when it will be necessary to put in service
a new function or a spare bay.
➤ The need in some cases to have a refe- H.V. switchgear
rence DCS – same hardware, same software
FIGURE 1
as the real DCS – for test purpose.According
to the case, this reference DCS will be run by
the manufacturer or by the user. [2] R. Cornu-Emieux, M. Rolland : [4] C.G.A Koreman, M. Kezunovic, S.
L’utilisation des techniques numériques Lemmer, A. Newbould : Configuration et
pour le contrôle, la protection et la mesure intégration du contrôle-commande des
dans un poste HT/MT (CIGRE 1988 postes (CIGRE 1996 Report 34-106).
8. References Report 23-16). [5] F.L. Baldinger, N.J.A. Duindam, E.
[3] J.M. Theunissen, R. Niemack, G.C. van der Helm, H. Timmerman : Impact
[1] P. Assailly, A. La Rocca, H. Adam, Oosthuyse, B. Young : Protection and con- of a Substation Automation System (SAS)
Y. Bonnardot : Procedure for the design, trol testing opportunities for modularised on engineering, management, maintenance
manufacture and commissioning of H.V. bay secondary equipment in transportable and required educational level of utility staff
and E.H.V substation control systems within bay kiosks (CIGRE SC34 1995 - Collo- (CIGRE SC 34 1993 Colloquium Antwer-
EDF (CIGRE 1992 Report 23-201). quium Stockholm Report 34-108). pen) ■

No. 201 - April 2002 ELECTRA 31