Table 3.1 evaluates whether each requirement listed in Section 3.1 has been met, partly met, or not met, by the testing environment that has been developed, as described in this chapter.
Most of the requirements have been met, with requirements 1(f) and 3(a) only partly met. However, despite these limitations, the test environment was suitable for the testing, described in Chapter 4, which was required in pursuit of research objective 1.
Table 3.1 Evaluation of testing environment against requirements
No. Requirement Met? Comment
1 (a) Repeatability: each test shall be de- terministic and it must be possible to prescribe and record all factors that can affect the outcome of a test, so that any test can be repeated and the same outcome obtained.
Yes Achieved through using the test runs database to store all parameters that affect each test, including the value used to seed any random number generator used by an algorithm. 1 (b) Observability: it must be possible
to observe and record any parameter relevant to a test, in order to gather results for analysis and also to allow tests to be repeated if necessary with the same conditions.
Yes Full state information for the power system being modelled is available within theSysModel and LFEngine objects, and these are captured and stored in a data archive file for each test. Furthermore, the state of each algorithm can be captured, stored and reinstated at any point.
1 (c) Flexibility: as required by research objective 1(c), it must be possible to run tests on a variety of networks; furthermore, as required by research objective 1(d) it must be possible to simulate different operating scenar- ios within each network including conditions that change over time.
Yes The SysModel object can be used to represent any power system that comprises the component types listed in Section 3.3.2, and can be used to represent a particular oper- ating condition by altering compo- nent parameters. The runs database allows scenarios with changing con- ditions to be stored and used for test- ing.
Table 3.1 (continued from previous page)
No. Requirement Met? Comment
1 (d) Automation: the environment must be capable of running multiple tests and recording their results, without user intervention, in order to enable the large scale testing envisaged by research objective 1(d).
Yes Achieved, mainly by the DriverProcess that automates test runs that are pre-defined in the runs database.
1 (e) Reliability: the environment must be tolerant of failed tests. If a test fails for whatever reason, then the failure should be recorded. Furthermore, the failure of one test should not influence the outcome of any other test.
Yes Achieved through the failure- tolerant design of the DriverProcess and TestProcess objects (please refer to Sec- tion 3.7.2).
1 (f) Speed: the environment should al- low testing to be completed as quickly as possible within the re- sources available. However, the en- vironment is not required to oper- ate in real-time and match the “wall clock” time like a real-time digital simulator (RTDS) [56].
Partly The architecture of the testing en- vironment is based on parallel pro- cessing, which allows testing to ex- ploit the speed advantage of multi- core processors. However, the use of Python for implementing the test en- vironment may result in speed penal- ties compared with other program- ming languages.
2 (a) The environment must be capable of running full AC load flow.
Yes ThePyPower load flow engine pro- vides full AC load flow calculation, using the Newton-Raphson solution method.
2 (b) The environment must allow for the simulation of real-time network op- eration over a time period, compris- ing a series of steady states sepa- rated by a constant time interval.
Yes Each test in the runs database con- sists of an initial state followed by any number of condition changes, representing a series of steady-states at a constant time step.
Table 3.1 (continued from previous page)
No. Requirement Met? Comment
2 (c) The environment must allow for representations of standard power system components and for compo- nents that could be expected in fu- ture power systems, in order to allow existing and emerging control algo- rithms to be tested.
Yes Section 3.3.2 details which compo- nents can be represented. The mix of component types includes some that are prevalent in today’s power systems, such as transformers and generators, while other types are still emerging, such as energy storage units and embedded DC links. 2 (d) The environment must allow time-
based characteristics of components to be simulated, in order to reflect real-world operation.
Yes Section 3.3.2 describes a number of components that can be represented within aSysModel that can include time-based characteristics that are updated between time steps, such as the state of charge of an energy storage (sto) unit.
3 (a) The environment must support the simulation of multiple control algo- rithms, in order to fulfil research ob- jective 1(b).
Partly The architecture of the test environ- ment is flexible to allow different al- gorithms to be implemented within it, and for tests be run on each; although the version implemented does not allow multiple algorithms to execute simultaneously during a single test run. However, this limi- tation did not impinge on the scope of testing performed for this work, in particular that presented in Chap- ter 4.
Table 3.1 (continued from previous page)
No. Requirement Met? Comment
3 (b) It must be possible to specify a set of components that each control al- gorithm can control. Any control action request that falls outside an algorithm’s specified set of control- lable devices shall be ignored, so that the control scope of individual algorithms can be restricted to par- ticular zones of operation [2, 57].
Yes Zone (zn) components can be used to control which components each algorithm can control down to the per-busbar level. Additionally, each component has anenable parame- ter that disallows algorithm control at a per-component level, regardless of zone.
3 (c) Algorithms must only be able to modify the operational parameters of components. Modification of fixed parameters – such as circuit impedances – or internal parameters – such as the state of charge of a bat-
tery storage unit – shall not be al- lowed, in order to reflect real-world operation.
Yes The components within the SysModel can have different types of parameters, as listed in Sec- tion 3.3.1, and algorithms are only allowed to modify some of these (namely, control- and mode-type parameters).
3 (d) Any interaction that an algorithm has with the power system model must be observable and should be able to be captured for inspection and analysis, such as for debugging when prototyping a control algo- rithm.
Yes This is achieved by having the com- munications system between the algorithms and the power system model, as described in Section 3.4.
3 (e) It should be possible for the envi- ronment to be extended to include modelling of communications sys- tem characteristics, such as delays and data drop-outs, which could be used as factors to influence the be- haviour of control algorithms.
Yes The communications system objects described in Section 3.4 could be modified to represent those charac- teristics, without necessitating mod- ifications to any of the other objects within the testing environment.
Table 3.1 (continued from previous page)
No. Requirement Met? Comment
3 (f) Any information that is preserved by an algorithm between executions must be available for inspection. Furthermore, it should be possible to capture and restore this preserved information, so that tests can be restarted at any point without inval- idating the requirement for repeata- bility.
Yes The structure of each algorithm’s OnlineProcess requires that any preserved information is available in an externally-accessible data struc- ture.