Contingency Analysis System Integration

Kent Active System Management (KASM)
SDRC 9.2 – Contingency Analysis

System Integration
November 2016
UK Power Networks (Operations) Limited. Registered in England and Wales. Registered No. 3870728. Registered Office: Newington House, 237 Southwark Bridge Road, London, SE1 6NP Page 1 of 60
KASM SDRC 9.2: Contingency Analysis System Integration
Contents
1 Executive Summary ........................................................................................................................................................................ 3
1.1 Background .................................................................................................................................................................... 3
1.2 Integration Architecture ................................................................................................................................................ 3
1.3 Testing............................................................................................................................................................................ 4
2 Definition of Terms ........................................................................................................................................................................ 5
3 Introduction ................................................................................................................................................................................... 7
3.1 Purpose of Document .................................................................................................................................................... 7
3.2 References ..................................................................................................................................................................... 7
4 Requirements ................................................................................................................................................................................. 8
5 Contingency Analysis Integration ................................................................................................................................................. 10

5.1 Introduction ................................................................................................................................................................. 10
5.2 Business Architecture .................................................................................................................................................. 11
5.3 Data Architecture ......................................................................................................................................................... 16
5.4 Application Architecture .............................................................................................................................................. 23
5.5 Technology Architecture .............................................................................................................................................. 29
5.6 Security Architecture ................................................................................................................................................... 34
6 Architecture Sign-off .................................................................................................................................................................... 35
7 Completion of Installation and Demonstration ........................................................................................................................... 36

7.1 Testing Strategy ........................................................................................................................................................... 36
7.2 Test Approach .............................................................................................................................................................. 37
7.3 Testing Phase Details ................................................................................................................................................... 38
7.4 Testing Metrics ............................................................................................................................................................ 40
7.5 Defect Management .................................................................................................................................................... 40
7.6 Release Management .................................................................................................................................................. 40
7.7 Assumptions................................................................................................................................................................. 41
7.8 Test Results .................................................................................................................................................................. 42
8 Engagement with Stakeholders ................................................................................................................................................... 57

8.1 Engagement through Webinars ................................................................................................................................... 57
8.2 Engagement through the LCNI Conference ................................................................................................................. 58
8.3 Engagement through the Grid Code Development Forum and Grid Code Review Panel............................................ 58
9 Conclusions .................................................................................................................................................................................. 59
9.1 Lessons Learned ........................................................................................................................................................... 59
9.2 Identified Risks ............................................................................................................................................................. 60
1 Executive Summary
1.1 Background
The Kent Active System Management (KASM) project aims to carry out a range of technical innovation trials to demonstrate more
advanced operations and planning techniques for the 132kV and 33kV network in East Kent. It is envisaged that the project will
deliver benefits that will span various areas, including the enablement of low carbon generation, the deferral of capital-intensive
reinforcement associated with new generation connections and improved reliability of the network.
The last few years have seen a number of Grid Supply Points (GSPs) come under pressure from the level of embedded generation
exporting power on the electricity distribution networks. In the most extreme form of the electricity network operating in the
opposite way to which it was originally designed, whole sections of the network are not only supplying their own demand but are
also exporting the surplus onto the transmission system. These conditions on the network can result in significant network
constraints, which can impact existing generators as well as new generators seeking to connect to the distribution network.
The area of East Kent being used in this project contains four GSPs (of approximately 350 nationwide), and a fifth is being
established in the area. Nevertheless, it currently requires as many as 34 contingency scenarios to be analysed in order to
understand the network fully. The significant uptake of wind and solar generation in recent years, due to government incentives,
and the presence of interconnectors connected to the transmission system, will only ever increase the number of scenarios that
need to be analysed – there is no longer a simple ‘day of highest winter demand' and 'day of lowest summer demand'. There is
more variation and hence a greater requirement to monitor all contingencies during real-time operation and future planning of the
network.
Contingency Analysis (CA) is a valuable tool to understand more about the network and predict the effect of outages like failures
of overhead lines, and to take actions to keep the distribution network secure and reliable. UK Power Networks (UKPN) will trial
for the first time the use of CA on the Great Britain (GB) electricity distribution network. It will also be the first trial which utilises a
coordinated data exchange with the electricity transmission network.
The KASM project will tackle and demonstrate the value of the Contingency Analysis System (CAS) in operational and planning time
frames on the network in East Kent, delivering conservatively estimated net benefits of £0.4m for the project trial area in East Kent.
Once proven successful, replication of this method across GB could conservatively provide net benefits of over £62m over the
lifetime of the 45-year investment, when compared to business-as-usual (BAU) approaches.
This report (representing the project Successful Delivery Reward Criterion (SDRC) 9.2) focuses on the successful integration and
testing of the CAS, including key lessons learned and identified risks.
1.2 Integration Architecture
The CAS integration architecture designed by the project covers the aspects of the different architectures aligned to The Open
Group Architecture Framework (TOGAF). The Business, Data, Application, Technology and Security architectures are described in
detail to illustrate the overall picture of the CAS. The main innovations in the architecture revolve around the enhanced Data Bridge,
state estimation and real-time power flow solver. To ensure the architecture designed as part of the KASM solution aligns with the
wider UKPN Information Systems strategy, the Logical Architecture Design Documents (LADD) were presented to a review board
who approved several key principles of the project architecture.
In order to manage the complexities of sourcing data from multiple applications, the project developed an enhanced data mapping
engine and Data Bridge which facilitates the build of a real-time power flow model. Conventional real-time power flow engines
utilise state estimation as an input, however state estimation is not commonly available to DNOs due to the limited need to run
real-time power flow calculations. In addition, the level of SCADA data available makes state estimation more complex than for
transmission network operators, who have a richer source of SCADA data available. Through an innovative approach, the KASM
project has worked with Bigwood Systems Inc. (BSI) to produce a State Estimator for the distribution network. The output from this
can be utilised to perform real-time contingency analysis. The benefit of this can be derived in several use cases, including reliability
management, outage management, and capacity management. As the level of embedded generation increases, the distribution
network power flows become more dynamic – thus understanding real-time power flows becomes an important capability to
manage the network efficiently and securely.
Integration with control room environments requires significant design considerations around security and resilience. The project
has designed an efficient cloud infrastructure rather than using traditional physical hardware. This results in a reduced cost through
smart server management, faster speed of deployment and improved reusability, whilst maintaining security of critical systems.
This infrastructure allows future projects to easily build on the data available from the KASM project.
1.3 Testing
Developing new innovative tools requires rigorous testing before embedding products within BAU processes. To maintain clarity
during testing, the project has created a detailed Test Strategy which covers the various elements required to validate the end
product. Due to the complexity associated with development of the end solution for KASM, it was decided to approach the
development in two phases. The first phase is the core product, which demonstrates the main functionality. The second phase
delivers enhanced user functionality.
The project has successfully completed testing of the first phase, which was demonstrated to a wide audience including project
partners and end users. Key elements of CAS functionality that were tested were:
 Importing of data from a range of existing applications

 Running state estimation using real-time SCADA data
 Running contingency analysis in a real-time and offline environment
This SDRC report provides a detailed approach to the testing conducted and presents the key evidence showing the tool being
tested successfully.
Throughout the integration design and testing of the CAS a number of stakeholder engagement activities were conducted, including
webinars, presentations and panel discussions. The project has incorporated feedback from these discussions within the integration
design and has considered key principles within the Test Strategy. During the design and testing phase a number of lessons were
learned and risks and mitigations identified. Key lessons revolve around data mapping, interfacing with multiple existing
applications and testing of state estimation and power flow solutions. In addition to lessons learned, there remain key risks which
need to be considered when integrating similar software in the control room IT architecture. These risks include the following:
 Ensuring up-to-date network models are used in the application – this is mitigated against by developing a robust network
model change process
 Maintaining security using cloud infrastructure – this is mitigated against through careful design and penetration testing
 Guaranteeing active engagement with the solution from the end users – this is mitigated against by providing a clear end
user training plan and early engagement in the design
2 Definition of Terms
Term Definition
ARB Architecture Review Board
BSI Bigwood Systems Inc.
CA Contingency Analysis
CAS Contingency Analysis System
CEGB Central Electricity Generating Board
CIM Common Information Model
CPT Cutover Process Testing
DMS Distribution Management System
DNO Distribution Network Operator
DPF Distribution Power Flow
DSR Demand Side Response
EHV Extra High Voltage
ENTSO-E European Network of Transmission System Operators for Electricity
EPN Eastern Power Networks plc
FALCON Flexible Approaches for Low Carbon Optimised Networks (LCNF project by WPD)
FEP Front End Processor
FTP File Transfer Protocol
GE General Electric
GEMA Gas and Electricity Markets Authority
GSP Grid Supply Point
HMI Human Machine Interface
HVDC High Voltage Direct Current
HV High Voltage
ICCP Inter-Control Centre Communications Protocol
IEC International Electro-technical Commission
IEMS Integrated Energy Management System
IIB IBM Integration Bus
IP Internet Protocol
IS Information Systems
KASM Kent Active System Management
LA Look Ahead
LADD Logical Architecture Design Document
LAN Local Area Network
LCNI Low Carbon Networks & Innovation
LPN London Power Networks plc
LV Low Voltage
MQ Message Queue
MQP Message Queue Protocol
MVA Mega Volt Ampere
MVar Mega Volt-Ampere Reactive
MW Mega Watt
NG National Grid
NPG Northern Powergrid
OC2 Operational Code 2
Ofgem Office of Gas and Electricity Markets
PICS Protocol Implementation Conformance Statement
RT Real-Time
RTU Remote Terminal Unit
SCADA Supervisory Control And Data Acquisition
SDRC Successful Delivery Reward Criteria
SFTP Secure File Transfer Protocol
SPN South Eastern Power Networks plc
TB Tera Byte
TCP Transmission Control Protocol
TLS Transport Layer Security
TOGAF The Open Group Architecture Framework
TSO Transmission System Operator
UKPN UK Power Networks
OLTC On-Load Tap Changer
VM Virtual Machine
WAN Wide Area Network
WPD Western Power Distribution
XML Extensible Mark-up Language
3 Introduction
3.1 Purpose of Document
The purpose of the document is to describe the solution architecture that has been developed and delivered as part of the KASM
project. In addition, the document will present the testing strategies and evidence of demonstrations through our testing
procedure. The solution architecture provides the description of the system integration of CA software into UKPN’s systems. The
design includes Business, Data, Application, Technology and Security architecture. The testing chapters within the document cover
the Test Strategy and key evidence from the test procedures.
Key evidence criteria of SDRC 9.2:
Criteria Evidence Section

 Sign-off on set up of CA software  Section 6
 Sign-off on successful demonstration and  Section 7

Completion of the system
testing of CA software  Section 9
integration of Contingency
Analysis software into UK
Power Networks systems,  Published report on CA software integration  Section 5
excluding a real time link to NG that includes the control room IT architecture,  Section 8
lessons learned, engagement with other DNOs,  Section 9.1
and identified risks  Section 9.2
Table 1: Key evidence criteria of SDRC 9.2 and corresponding sections of the document
3.2 References
Number Document Name Author

1 SDRC 9.3 – Installation of forecasting modules Alex Jakeman, Sam Sankaran; October 2016
2 P.0032.KASM.Contingency Analysis System – Sam Sankaran, Gilbert Manhangwe, Paz Mehta; September 2016
Testing Strategy
3 Logical Architecture Design Document Paz Mehta, Alex Jakeman, Gilbert Manhangwe, Chris Potter,
Nathalie Beaufond; October 2016
4 Requirements
Table 2 lists some of the key requirements for successful implementation of the CAS. The results of each test case are presented
later in this document in section 7.8. Requirements related to performance, security and IT specific requirements are captured in
the formal requirements matrix, which can be provided upon request.
Requirement Category Sub Requirement Test

Number category case(s)
1.1.0 Contingency General The CAS must be able to operate in three distinct modes: 3.2.2
Analysis  Using real-time data; CAS Real-Time mode 3.4.2
 Using historical data; CAS Study mode 3.5.1
 Future mode, using forecasted data; CAS Look-Ahead mode
1.4.0 Contingency General The real-time CAS should be able to conduct CA in pre-determined and 3.5.3
Analysis configurable time intervals, report the results to the control room and
store and archive each iteration.
1.15.0 Contingency Power Flows The CAS must model Full Generator Participation with Power at Risk – 3.4.4
Analysis same as above except that the slack bus generator is treated as a normal
generator and the delta generation to meet load demand is calculated
and allocated locally/rank-wise/capacity-wise among all participating
generators. All the generators at risk (i.e. where the allocated power is
outside the limits of the generator operating region) are reported
separately.
1.19.0 Contingency Power Flows The CAS must have options to set or import from the DMS, control limits 3.2.5
Analysis to tap controller, generators and transformer controller, switched 3.5.7
compensators and other component controllers.
1.22.0 Contingency Outputs and The CAS must retrieve, edit and store historical CA scenario data 3.1.4
Analysis reporting (including associated network topology) for network capacity
management studies and analysis.
1.23.0 Contingency Outputs and The CAS must provide data for outage management studies and 3.1.5
Analysis reporting analysis.
1.24.0 Contingency Outputs and The CAS must provide data to support reliability management studies 3.1.6
Analysis reporting and analysis.
1.26.0 Contingency Outputs and The CAS must support the view of study results over a set period of time 3.1.8
Analysis reporting for the entire network or set of components selected from the diagram
or network model in standard spreadsheet format (table format) for
further analysis. The data is exportable to standard spreadsheet format.
1.28.0 Contingency Outputs and The outputs from the CA shall be represented in a clear and concise 3.1.9
Analysis reporting format supported by data tables and a single line diagram which can
easily be interpreted – both in Study mode and Real-Time mode.
2.2.0 Network Data The CAS must have the capabilities to import different component 3.2.6
Modelling exchange ratings from the DMS and PowerFactory. 3.5.9
2.7.0 Network Network The CAS model must be capable of importing detail networks and 3.1.14
Modelling Definition equivalent networks (400kV, 275kV, 132kV, 33kV, 11kV).
2.9.0 Network Network The CAS must have a flexible network model and allow for network 3.1.15
Modelling Definition updates based on changes in network detail and KASM network
boundaries.
2.10.0 Network Data The CAS must be able to exchange network models based on industry 3.1.16
Modelling exchange standard information exchange standards, i.e. Common Information
Model (CIM) and PSS/E format.
Requirement Category Sub Requirement Test

Number category case(s)
2.15.0 Network Real time The real-time CAS must use the network switch status and should reflect 3.2.1
Modelling the connectivity arrangements taken from the DMS system. Any change 3.5.10
in switch status or load must be reflected in the CA tool automatically
and near real-time.
2.16.0 Network Validation The CAS must perform data validations before execution of Load Flow 3.4.1
Modelling calculations enabling accurate study results. Any assumptions used in 3.5.11
Load Flow calculations shall be accessible to the user.
3.7.0 System Network The CAS will be able to import the network model and its specifications 3.1.13
Integration Modelling from PowerFactory. The methods for integration must be robust, i.e.
Common Information Model (CIM) and PSS/E format.
Table 2: Requirements for successful implementation of the CAS
5 Contingency Analysis Integration
5.1 Introduction
The KASM study area (East Kent) has in recent times become more challenging to manage both for the transmission and distribution
network operators, partly due to increased distributed generation connected and increased flows on transmission interconnectors
to continental Europe.
The CAS is a valuable tool to understand more about the network and predict the effect of outages like failures of overhead lines,
and to take actions to keep the distribution network secure and reliable. The KASM project aims to introduce CAS as a tool to assist
outage planners, infrastructure planners and control room engineers with the planning and management of the electricity
distribution network.
The purpose of this section is to summarise the logical architecture of the CAS defined within the scope of the project. Although
the project is only a trial, it is important that the underlying design is based on sound architectural principles, as it intended to
provide the starting point for an enduring solution and a move to a possible BAU activity. The full description of architecture is
contained in the LADD, which is available upon request.
The scope of the document is divided into the five architectural domains defined by the TOGAF 1 ADM (Architecture Development
Method):
1. Business – for the system users that will use the CAS, it describes the context in which the CAS will reside. It also outlines
the current and to-be business processes
2. Data – describes the data that will be used in the CAS. The data is categorised and the sources of data are described. The
network model used in the CAS is also covered
3. Application – describes the CAS and supporting software applications used to provide the data for contingency analysis
4. Technology – describes the IT infrastructure that will host the CAS
5. Security – describes the security considerations, including physical, communications and IT
1The Open Group Architecture Framework (TOGAF) is a framework – a detailed method and a set of supporting tools – for developing an
enterprise architecture. For more information please see: http://pubs.opengroup.org/architecture/togaf8-doc/arch/
5.2 Business Architecture
There is a strong focus among Distribution Network Operators (DNOs) to develop contingency plans to avoid or shorten outage
periods when carrying out maintenance works, restoring power supplies to demand customers and maintaining routes for
generation in the event of a fault. This section describes the business architecture at a high level. The details behind proposed
business architecture will be covered under SDRC 9.6 (Development of business design to incorporate contingency analysis as
business-as-usual), which is due in December 2017. It is envisaged that the trial period will help determine the future business
process in greater detail.
Each of the Users has the responsibility of managing the power system in different timescales, as demonstrated in Figure 1 below:
 The control room engineer operates the distribution network in real-time.

 The outage planner is typically looking at the network within the next 1-7 days.
 The infrastructure planner is looking at the network in timescales that are months and often years ahead.
Real-time
to 36hrs 1 day to 7 days Months ahead
Figure 1: Timescales of responsibility for network management
To this effect, the role of control room engineers is to monitor the network in real-time, issue and manage safety permits to staff
working on the network, and respond to faults by reconfiguring the network. The role of network management continues with
outage planners, who specialise in maintaining and optimising the programme of outages to best serve customers. Finally,
infrastructure planners maintain the design of the network and respond to new connection requests by identifying suitable points
of connection to the network for major loads and distributed generation. Accurate real-time, short- and long-term planning is
valuable in effectively managing the distributed resources, resulting in optimum use of the available network capacity.
Control Room
The role of control room engineers is to monitor the network in real-time, identify and mitigate harmful contingencies, issue and
manage safety permits to staff working on the network, and respond to faults by reconfiguring the network.
Control room engineers use the PowerOn Distribution Management System (DMS) to perform their day-to-day task of managing
and controlling the power system. In order to assist the engineers, the CAS will be deployed alongside the DMS. The DMS will send
a real-time feed of data to the CAS application.
Using the CAS, the control room engineers will be alerted to future harmful contingencies in real-time. This capability will help
control room engineers move from a reactive response to a proactive approach based on outputs from the CAS, which in turn will
improve the reliability of the network.
Figure 2: Flow chart showing the UKPN network monitoring and control process
Outage Planning
The role of outage planners is to carry out outage checks to confirm the feasibility of planned network outages. These checks are
carried out through power flow studies conducted with the application PowerFactory and other necessary supplementary tools.
The studies ensure voltage, thermal and fault level constraints are not put at risk during the outage. The studies help the outage
planner to decide the best running arrangements of the network under the planned outage. If an alternative running arrangement
cannot be determined, the outage planner will need to determine if generation needs to be curtailed in order to take the network
outage.
Currently, outage planners manually analyse all possible contingencies to ensure that the outage plan is consistent with n-1
reliability requirements. Moving forward when the CAS is available, outage planners can use the automated CAS to run multiple
contingencies in a number of seconds. The CAS will provide additional analytics facilities which enable outage planners to use
forecast data to run studies rather than use ‘worst-case’ operating conditions (minimum demand and maximum generation) in East
Kent. The overarching aim of using CAS is to reduce outage constraints on generators and the timescales required to analyse
multiple contingencies.
Figure 3: Flow chart showing the UKPN outage planning process
Infrastructure Planning
The role of infrastructure planners is to manage new load and generation connections on the 33kV and 132kV networks. In addition,
they manage ongoing reinforcement of the network to ensure security of supply. Like outage planners, infrastructure planners also
use PowerFactory application to model new load and generation connections on the network. They currently perform these studies
using worst-case operating assumptions.
Moving forward, using the CAS infrastructure planners will be able to model new connections based on realistic operating
conditions which have been archived over a period of time. The archived scenarios will help them understand the coincidence of
load and generation. Using more realistic operating conditions based on the coincidence of load and generation will reduce the
expected reinforcement required for new connections. It will be important to manage the network closely in real-time to ensure
the network is managed accordingly if the worst-case scenarios materialise.
Figure 4: Flow chart showing the UKPN infrastructure planning process
Contingency Analysis
The contingency analysis capability of the CAS will support all three of the user groups listed above. The architectural elements
covered in the high-level architecture illustrate its capability to generate and manage network models that support real-time
operations and planning functions.
5.2.4.1 High Level Architecture
Fundamental to Contingency Analysis simulation is the creation of a ‘base case’, which is a model of the power system in its normal
steady state operation. Within the KASM CAS, a real-time base case will be produced from PowerOn Fusion using the distribution
power flow (DpF) extract capabilities, and this will be merged with a Common Information Model (CIM) extract from PowerFactory,
a network planning tool for EHV networks at UKPN. The two models are joined as the real-time and connectivity data from the
PowerOn Fusion is essential for getting an up-to-date view of the network and the asset characteristic data is required from
PowerFactory, which is routinely used in power system modelling.
At present the data in each of these two systems (PowerOn Fusion and PowerFactory) exists in isolation. There is no automated
reconciliation between the two systems and the data must be mapped from one system to the other.
The CAS will operate in three different modes – Real-time, Look-ahead and Study – to complement the different user roles defined
in the previous sections. The overview of the system architecture is shown in Figure 5 below.
Distribution Actual
Network Real
Contingencies Forecasting Weather
time state
Real-time
Network
PowerOn Base Case
Contingency Analysis Load/ Weather
(Real-time Power
Transmission Suite Generation Forecasting Forecast
System Control)
Network Real Load/
time state generation
forecasts
Planning Historical
Network Metering
Base Case National Grid
Wind
Forecaster
Network
Model PowerFactory Interconnector
(TSO & DNO) (Power System Network Forecast
Modelling)
NG Network
(Transmission)
UKPN Network
(DNO)
Figure 5: A block diagram showing High Level Architecture for the CAS
Network Control (Real-time Network Operation)
The expectation is that the CAS is a standalone application that sits alongside the DMS. The DMS has a live electrical model of the
power system which can be exported for contingency analysis. The CAS will provide online network status, possible violations and
the capability for control room engineers to run the application in Study mode to check the feasibility of suggested network
configurations.
The source of the network model to generate the base case for the control room engineer will primarily be derived from the data
in PowerOn Fusion. However, the data in PowerOn Fusion, requires supplemental data from PowerFactory, which includes:
transformer vector group information, generator equipment rating and impedance data.
Power System Models
The electrical model of the power system needs to contain the following information:
1. Description of network assets on the network, e.g. transformers, circuit breakers, overhead lines etc.
2. Connectivity of the network assets, i.e. how the network components are connected
3. Real-time status of the network, i.e. voltage levels, active and reactive power flows, switch positions, transformer tap
positions etc.
The data architecture and data requirements are described in detail in section 5.3.
5.2.6.1 Network Definition
The boundary of the pilot area being used within the KASM area has been defined on the basis of a number of substations whose
power flows are known to be challenging to analyse, and which are becoming increasingly influenced by renewable generation and
by activity on the National Grid transmission network, such as flows on interconnectors and large plant outages.
Irrespective of the topographical area of the network being analysed now or in the future – whether the KASM pilot area, the wider
SPN licence area or the whole NG transmission network with the SPN licence area embedded in it – the following technical
boundaries will apply:
 Within a 33kV/11kV substation, the network model will terminate at the SCADA measurements on the 11kV feeders
 At an earthing transformer or auxiliary transformer, the network model will terminate at the primary side. The network
model should represent the transformer as an impedance to earth
 On 33kV feeders which are leaving the topographical area, the network model will terminate at the 33kV circuit breaker
associated with that feeder on the substation that is inside the topographical area
 On 132kV feeders which are leaving the topographical area, the network model will terminate at the 132kV circuit breaker
associated with that feeder on the substation that is inside the topographical area
 On 400kV or 275kV feeders which are leaving the topographical area, the network model will terminate at the 400kV or
the 275kV circuit breaker associated with that feeder on the substation that is inside the topographical area
5.2.6.2 Network Trace Options
The PowerOn Fusion model data is exported in XML data format. The XML file contains a network model which is based on an
electrical trace from a set seed (starting) point. When the network configuration changes – through switching or a circuit breaker
tripping – the network trace will either grow or shrink. The CAS takes the XML file and any other asset information and solves a
load flow regardless of how big or small the network is on every export. Three different network trace options are available for
controlling the extent of the trace with the power flow analysis tool:
1. Current network – the current network is a model of the live power system network in real-time. The network is traced
from a seed component and will stop at every open point or when it encounters a component of the selected termination
component type. Dead (not energised) areas of network will not be in the model. This network model can be extracted
with meaningful network status information (e.g. SCADA data)
2. Design state – the design state of the network is the network in its normally switched state
3. Scheduled network – within power flow analysis it is possible to superimpose switching actions on top of the current
network state to create a user-defined switched view of the network
Initially, due to the NG transmission network not being modelled in the current live system, the extent of the network model will
be limited to a section of the EHV/HV (132kV/33kV/11kV) network. The model will be taken from a network trace from a circuit
breaker at the Sellindge 132kV substation up to the in-feeds from the supergrid transformers on the transmission network, down
to the circuit breakers on the 11kV bus bars. This trace will be expanded as confidence in the CA tool is gained and modelling of the
NG transmission assets is undertaken.
5.3 Data Architecture
Introduction
The CAS operates in three key modes – Real-time, Look-ahead and Study – utilising a mixture of static data, dynamic data and
forecast data to build an accurate and converging (base case) model. The configuration and inputs of the model vary depending on
the activated mode of the contingency analysis. Dynamic data reflects the current operating state of the power system and is
updated in near real-time. Static data is updated by exception, representing elements such as display configurations/layout, and
changes when the latter is modified or network components (transformers, lines etc.) are added.
The construction of an accurate model involves importing data from different sources for the creation of the base case scenario,
which is essential to run contingency analysis. The base case scenario is a model of the power system in its normal steady-state
operation. In order to create a (converging) power flow case for contingency analysis, the following information is required:
1. Network connectivity including switching status

2. Voltage level for the system
3. Line parameters (resistance (r), reactance (x), susceptance (b), rating)
4. Transformer parameters (r, x, rating)
5. Transformer tap changer parameters (side, ratio, angle, upper limit, lower limit or in another way tap position, high step
and low step, neutral voltage and neutral position)
6. Shunt capacitor parameters (for those that will participate in control, their controlled bus and voltage schedule is required)
7. Load data (direction of power flow)
8. Generator data (Pmax, Pmin, Qmax, Qmin, voltage schedule and controlled bus)
9. Quad booster data (side, ratio, angle, upper limit, lower limit or in another way tap position, high step and low step, neutral
voltage and neutral position)
10. Measurements (P, Q, Amps, V)
In addition to the data for the base power system model outlined above, the following data is required for executing and reporting
contingency analysis:
1. Single line diagram of the power network

2. Forecast data for loads, wind generators and solar generators
3. Other additional information such as:
a. Contingency list
b. Monitoring list
c. Capability curve (optional)
d. Wind farm list
e. Solar generator list
f. Other renewable generator list
4. Project lookup tables which allow matches between the GE PowerOn name, the PowerFactory name and OSIsoft PI
Historian tags
Figure 6 illustrates the CAS high-level data flow architecture and exhibits the internal and external data sources that feed into the
CAS.
UK Power Network data sources External data sources
National Grid
OSI Soft Control Centre
DigSILENT GE
PowerFactory PowerON Pi Historian Met Office ENTSOE
National Grid
System Operation
Contingency Analysis Suite
Offline Data Single Line

Mapping Engine Diagram Builder
Data Bridge,
Forecasting
State Estimator &
Engine
Power flow solver
Look-Ahead Mode Real-Time Mode

Study Mode (Analysis & (Analysis &
Control Engine) Control Engine)
Viewer
Figure 6: Block diagram showing the CAS high-level data flow architecture
Data Sources
Figure 7 shows the data architecture of the CAS in conjunction with the internal and external data sources required to support the
various CAS operational modes, and also illustrates the internal and external data sources themselves. Internal data sources are
internal to UKPN’s existing architecture. External data sources are external entities such as NG and the Met Office.
UK Power Networks data sources External data sources
National Grid
ICCP Control Centre
DigSILENT GE ENTSOE
PowerFactory PowerON Met Office
OSI Soft Interconnector Data
National Grid
Pi Historian System Operation
CIM file XML file
Hotspot positions xls

Connection
KASM data sources Contingency Analysis Suite World_List
SFTP
Custom project Offline Data Single Line FTP Web page script
lookup tables Mapping Engine Diagram Builder
Data Bridge,
Supplemental List Forecasting
State Estimator &
Files Engine
Power flow solver
Look-Ahead Mode Real-Time Mode

Study Mode (Analysis & (Analysis &
Control Engine) Control Engine)
Viewer
Figure 7: Block diagram showing the CAS Data Flow Architecture
5.3.2.1 Internal Data Sources (UKPN Data Sources)
DIgSILENT PowerFactory
DIgSILENT PowerFactory is a power system analysis tool used by UKPN for outage planning and infrastructure planning.
PowerFactory has a CIM export capability to extract the power system model and pass it to the CAS applications.
A full CIM export from PowerFactory is made available with all switches present, without network optimisation (i.e. no node
reduction), so that the complete network is extracted for the on-line CAS. The equipment parameter data is copied from the CIM
export file and matched, where possible, to the corresponding equipment in the GE PowerOn Fusion XML (PowerOn XML). The BSI
Data Mapping Engine, running as a stand-alone application, performs the matching and stores the matched parameter data in the
Parameter Matching table.
It should be noted that the CIM extract does not contain the transformer vector information that is required to create a full model
for contingency analysis, even though the power flow solution in PowerFactory considers transformer vector groups. To obtain the
required information, a PowerFactory-exported transformer data sheet (in Excel) is produced which the Data Mapping Engine then
uses to match the vector group to the transformer windings.
GE PowerOn
GE PowerOn Fusion is UKPN’s Distribution Management System (DMS), which is used in the control room to manage the network
in real-time. The DMS represents the ‘live’ running configuration of the network to the control engineers who manage the
distribution network in real-time. The DMS receives SCADA data from Remote Terminal Units (RTUs) in the field and presents this
data on a network diagram in the application. The DMS provides alerts based on user defined limits of equipment and also allows
remote switching capability on the majority of the EHV/HV networks.
PowerOn Fusion is the source for the real-time network configuration and power flows on the distribution network which will be
used in the CAS. PowerOn Fusion is also the source of the schematic diagram which will be presented in the CAS. The real-time
network configuration and power flows will be provided through an export capability in PowerOn Fusion called Distribution Power
Flow (DPF) trace, which provides the relevant data in a PowerOn XML export file with a proprietary format of a bus-branch power
system model. The schematic diagram data will be provided by a separate export containing three files: a hot-spot-positions file, a
connections file, and a world list file. These three data files are combined with data in the PowerOn XML file to produce the CAS
single line diagram. The PowerOn XML export is supplied to the CAS on a configurable time interval, which was set at 15-minute
intervals for the KASM project.
The file also contains the real-time network status data from the power system, which includes voltages (reported against busbars),
current (reported against individual switches or circuit breakers), switch states, and tap positions.
OSIsoft PI Historian
OSIsoft PI Historian is the UKPN SCADA historian into which all available real-time data from the DMS is archived. Each network
analogue has a PI tag associated with it, which provides the ID for retrieving the data from the PI database. For KASM, the PI
database is used to extract historical load and generation data that is used to train the load and generation forecasting algorithms
which sit within the BSI Forecasting Engine. The data from the PI database will be exported in Microsoft Excel format with
measurement data recorded at half-hourly intervals. Once the forecasting algorithms have been initially trained, there will be no
further interface between the forecasting engine and the PI database.
5.3.2.2 External Data (National Grid, Met Office ENTSO-E Data Sources)
NG Real-Time Data (NG Control Centre)
NG is the transmission network operator in the KASM network area. The CAS collects transmission network real-time control
measurements data through the PowerOn XML extract. Real-time control measurements data is transmitted over an ICCP link that
connects the UKPN and NG control rooms. ICCP data exchange details are explained in UKPN’s SDRC 9.1 report (Development of
the strategy for Inter-Control Centre Communications Protocol for the purposes of KASM), which was submitted to Ofgem on 29
December 2015. The National Grid real-time control measurement information will be included in the PowerOn XML export, which
is supplied to the CAS at 15-minute intervals.
NG Forecast Data
The CAS forecasting engine will receive NG’s wind generation forecast data. This forecast data includes 0-4 day ahead wind
generation forecasts at an individual site level, and for sites larger than 100kW on an hourly basis. This data will be used as an
input to the forecasting engine.
The Met Office
The Met Office is a national weather service provider in the UK. For the KASM project, the Met Office is the source of weather data
including observational and forecast information. Weather forecast data will be periodically provided to UKPN by the Met Office
via Excel files. The service will include a number of weather station sites which cover the geographic area of the KASM network.
The data will be used to train the forecasting algorithms and as an input to the live forecasting engine.
ENTSO-E
The CAS will take data from the ENTSO-E (European Network of Transmission System Operators for Electricity) Transparency
Platform. This platform provides expected day-ahead power flows data across the European interconnectors. The data will be
processed in the forecasting engine prior to being used in the Look-ahead (LA) Data Bridge and State Estimator. The data will include
the expected power flows across the BritNed (1GW) interconnector and the France-Angleterre (IFA) interconnector (2GW). The
forecast power flows are provided on an hourly basis.
5.3.2.3 KASM Data Sources
Custom Project Lookup Tables developed by KASM Team
The custom project lookup tables were developed by the KASM team to enable the mapping of PowerFactory CIM parameter data
to the PowerOn XML extract and achieve matches by exception for equipment that did not correspond under normal processing.
The following tables were defined and are used in the CAS:
 Parameter Matching table (csv)

 Generator lookup table (csv)
 Lines lookup table (csv)
 Rail load lookup table (csv)
 Site exception table (csv)
 Separate from the tables listed above, an offline contingency list table which is used to define the contingencies (csv)
Parameter Matching Table
The parameter matching stores the results of the matching process to define the relationship of the PowerOn equipment and the
PowerFactory parameters. The output of this process is moved to the CAS folder area and will be used by the CAS Data Bridge to
process each new PowerOn XML until this process is run again and the new table is substituted.
Lookup Tables
All of the lookup tables are text CSV-formatted files. These tables were developed and populated by the KASM team.
Supplemental List Files
These are text files which are supplied manually from offline sources.
In addition to the above, the BSI Forecasting Engine (which is part of the Contingency Analysis Suite) serves as a data source for
forecasting data, using inputs from NG, the Met Office, ENTSO-E and data from the BSI Forecasting Engine. Details for each data
source and its role in the overall Architecture are outlined in section 5.3.4.
Data Model Definition
Data from internal sources is essentially the distribution network model, circuit breaker statuses and analogue measurements. The
distribution network model, circuit breaker status and analogue measurements are associated with various component types from
different data sources. For example, the status of a switch and analogue measurements of that switch are captured within a switch
component from PowerOn. However, the parameters associated with that switch will come from PowerFactory.
There are two types of data – dynamic and static – that are needed by the CAS for both online cases and planning study cases.
Dynamic data is updated in near real-time to reflect the current operating state of the power system. Static data represents
elements that are updated infrequently (e.g. display configurations/layout) and change when the latter is modified or network
components are added.
Data Interfaces
The input data from the collection of data sources (as outlined in Figure 7) is supplied to the CAS, which in turn is passed through
the Data Bridge, State Estimator, and Power Flow Solver module, and generates the contingency list, the monitoring list, and other
supporting data that can be used in the Real-Time, Look-Ahead and Study modes.
At the start of the KASM project a State Estimation output was not available. Conventional contingency analysis solutions have a
Data Bridge which uses the State Estimation as an input. The State Estimation used in the KASM project is based on the Distribution
State Estimation developed by BSI during the project. The converted supporting files and the solved power flow case output
together make a complete contingency analysis base case dataset, which is sent to the contingency analysis engines for analysis.
This process develops case sets for both RT and LA CA Power System Models. In the following subsections, we detail the source of
input data for each of the three contingency analysis engines used in CAS (Real-time, Look-ahead and Study).
5.3.4.1 Data Bridging and State Estimation – Real-time (RT) Mode
The data for the CAS-RT analysis is sourced from the PowerFactory CIM and the PowerOn XML extracts. Ideally, the source of the
network model would be the PowerOn XML extract, which contains all of the static and dynamic data required to create a base
case for contingency analysis. However, it was determined that the equipment parameter data in the GE PowerOn system was not
suitable for the CAS. The resulting approach was to use the parameter data for these components from the PowerFactory CIM
extract. The connectivity and line definitions will be taken from the PowerOn XML extract.
5.3.4.2 Data Bridging and Power Flow Solver – Look Ahead (LA) Mode
The base case in CAS-LA mode is generated using information from the Data Bridge and Power Flow Solver module. In addition, the
forecast data for the load and generation sites, supplied by the BSI Forecasting Engine, is used to create the LA case (please see
UKPN’s SDRC 9.3 report (Completion of installation of forecasting modules that will link the DNO control room with other data
sources). This is an automatic process. The case is archived and the user can export the LA case to the KASM Study mode to run a
full contingency analysis on the generated case.
5.3.4.3 Online Study Mode
The user has a choice of initialising the Study mode from either an online base case archived by the CAS or a planning case created
in PowerFactory (a function to be made available in Release 1) and imported to the CAS Study mode as a CIM extract. A CAS study
can be conducted on any one of three data sources:
1. An archived CAS RT case

2. An archived CAS LA case
3. A planning study case developed in PowerFactory
BSI Forecasting Engine
The BSI Forecasting Engine is a standalone application which sits within the Contingency Analysis Suite. It consumes:
 Metered data from the OSIsoft’s PI Historian database as an offline manual Excel file copy
 Met Office weather forecasts via FTP
 National Grid wind generation forecast
 ENTSO-E day-ahead interconnection schedules via FTP
 ‘Live feed’ measurement data from CAS
When the managed network footprint includes full or near full coverage of the forecaster and CAS snapshot data has been archived
in the Forecaster database for more than six months, this historical data, provided by CAS, will be used to train and produce
forecasts.
The BSI Forecasting Engine produces forecasts for the following:
 Load
 Wind generation
 Solar generation
Forecasting results are passed to the CAS Data Bridge for use in look-ahead analysis, and are made available to other UKPN
applications through the BSI Forecasting Engine user interface.
For further details of the forecasting engine please refer to UKPN’s SDRC 9.3 report (Completion of installation of forecasting
modules that will link the DNO control room with other data sources).
5.3.5.1 Network Diagram Change Process
The CAS updates for the single line diagram are processed under two scenarios. This is a manual process due to the low frequency
of updates.
Scenario 1: Complete update (to be used when updating large portions of the system in CAS and when large scale changes to the
network are made)
1. Generate a new single line diagram

2. Re-run data mapping process
Scenario 2: Incremental update (to be used when a small portion of the system is updated)
1. Update single line diagram (affected part only)

2. Manually update Parameter Matching table
5.4 Application Architecture
BSI’s CAS uses advanced power flow and smart Homotopy based power flow solvers2 to study the network for thermal, voltage and
steady state violations due to a large set of contingencies. This implementation includes tailored data and application processing
for UKPN’s existing online environment, to quickly assess the threat of varying power flows through grid supply points or from
generators and to account for the impact of renewable energy.
A conventional CA Data Bridge uses state estimation as input. The Data Bridge generates a contingency list, or inputs and re-formats
the externally-supplied contingency list to create monitoring lists and other supporting data that match the state estimation output.
The combination of the converted supporting files and the state estimation output make a complete CA base case dataset, which
is sent to CA engine for analysis.
In KASM, state estimation is not available from the existing power flow modelling applications and therefore a state estimation
solution will be developed. Specifically, the Data Bridge will be enhanced to generate raw power flow base cases from a number of
different data sources. This process is the main function of Data Bridge and Power Flow Solver for both the RT and LA modes.
The enhanced Data Bridge and State Estimator generates the CAS case set from various data sources and performs contingency
analysis. The CAS Viewer receives results from the engine and displays them to the users. Through the CAS Viewer, operators can
download an online case and launch Online Study Mode for detailed study and further contingency analysis. Furthermore,
operators can initiate a dispatched (user-initialised) LA study by sending a request to the LA engine, which relays the request to the
forecasting engine. Study Mode also accepts base cases generated directly from PowerFactory in CIM format, in addition to the
archived RT and LA cases.
For both the RT and LA engines, there is a high availability solution which includes primary and backup servers. Both servers accept
identical input streams, with each running independently of the other. Individual CAS Viewers are configured to utilise one of the
server pairs as a primary server and the other as a backup server. If the primary server is out of operation, the viewers automatically
and seamlessly switch to the backup server. The detailed architecture is illustrated in Figure 8 below.
2 Solving power flow problems is essential for the reliable and efficient operation of a power network. Current software for solving these
problems are typically based on the Newton-Raphson method and have several limitations. One key limitation is that a ‘good’ initial point
is usually required to obtain a solution. Homotopy based techniques help to mitigate this limitation. The basic strategy to solve a system
of non-linear equations using a Homotopy method is to start with a new system of non-linear equations which is easier to solve. Then, one
constructs a family of problems through one or more parameters that are members of the system to be solved and the newly constructed
system. Next, each solution of the new system is tracked towards the original system along the parameters to get the final solution.
Converted Network Data Forecast Data
RT Data Bridge LA Data Bridge

Forecasting
and State and Power Flow
Engine
Estimator Solver
RT Case Set LA Case Set
DIgSILENT
PowerFactory
Base Case
RT Analysis and LA Analysis and

Control Engine Control Engine
Online Study
Mode
Archived cases
and results
Primary
Backup
Converted Single
CAS Viewer Line Diagram
Figure 8: Block diagram showing the CAS Application Architecture
Converted Network Data
Prior to online execution of CAS Data Bridge and State Estimator, the CAS Data Mapping Engine must be run using input from
PowerOn and PowerFactory to associate common equipment that is represented in each of these third-party datasets. Each match
creates an output record in the Parameter Matching lookup table, which associates the power system parameters from the
PowerFactory CIM file with the matched equipment record in the PowerOn XML file. The Parameter Matching lookup table is
subsequently used for internal processing in the CAS. Detailed data flow is discussed in the data architecture in section 5.3.
RT Data Bridge and State Estimator
The RT Data Bridge performs the following functions:
1. When starting, the RT/LA mode Data Bridge loads the converted static model data.
2. The Data Bridge automatically checks the folder where GE PowerOn exports the XML file, using basic file system functions.
When a new dynamic network model data is available, the Data Bridge loads and processes the files. A raw RT base case
is then generated.
3. The raw case is sent to the BSI simplified State Estimator; using the BSI RT Power Flow Solver, a power flow solution is
generated.
4. The RT Data Bridge generates an RT dataset after combining the power flow solution, contingency list, monitoring list,
capability curve, generator participation factor and other supplementary files.
5. The RT Data Bridge generates a mapping file consisting of the hotspots file and the XML data, and links devices in the bus-
branch model with the components displayed in the single line diagram.
6. The generated RT dataset is stored in the RT engine feed-in folder.
5.4.2.1 LA Data Bridge and Power Flow Solver
The LA Data Bridge performs the following functions:
1. The converted static model data is loaded.

2. The forecast folder is automatically checked for new forecast data and loaded.
3. After combining the forecast data with the current switching status, a raw LA base case is generated and the future
network arrangement is scheduled.
4. The raw case is sent to the BSI LA Power Flow Solver to compute the LA power flow solution.
5. After combining the power flow result, contingency list, monitoring list, capability curve, generator participation factor
and other supplementary files, an LA dataset is generated.
6. A mapping file is generated which consists of the hotspots file and the XML data and links devices in the bus-branch model
with the components displayed in the single line diagram.
7. The generated LA dataset is stored in the LA engine feed-in folder.
8. The user dispatched forecast folder is checked for user dispatched forecast data. If user dispatched forecast data is
available, user dispatched LA case sets are generated by following steps 3-5.
9. The generated user dispatch LA datasets are stored in the dispatch result folder.
The Data Bridge will not automatically update the static model data. Whenever there is a new static model, the user needs to stop
and restart the Data Bridges by controlling relevant Windows Services. This is a manual process and has to be performed every
time a static model is updated. It should be noted that the static model update frequency is low compared to the other data. The
Forecast Engine and the Data Bridge share several folders through the CAS. Discrete folders and files are used for the applications
in the LA thread to prevent file overwrite and file locks.
The LA Data Bridge and Power Flow Solver also provide the bridging between the LA Analysis and Control Engine and the Forecasting
Engine. The data flow could be in either of two directions:
 LA Engine to the Forecast Engine: The live feed of measurement data is provided by the LA Engine. In the meantime, the
LA Engine also provides the state estimation data to the Forecast Engine.
 Forecast Engine to LA Engine: In this direction, the Forecast Engine provides the forecasts (load, wind and solar generation)
to the LA Engine.
Analysis and Control Engines
The Analysis and Control Engines are the heart of the CAS. They use the cases created by the Data Bridge and perform the
contingency analysis. The Analysis and Control Engines run in the background in parallel computation mode in a periodic cycle.
A valid RT power flow solution is the key to the success of the project. Solving a raw power flow base case without knowing the
voltage profile is a challenging task even for an offline planning application. In planning mode, convergence of a power flow often
involves significant human intervention. Regular power flow could fail most of the time, especially when the system size is large.
The online RT Solver has a higher requirement, in that it must automatically and continuously solve raw power flow cases generated
from the RT Data Bridge at intervals of a few minutes, without any human involvement. A robust algorithm is a must for
convergence of most of the raw base cases. In the CAS, we are applying a homotopy-based smart power flow solution algorithm
developed by BSI, as the engine of the RT Power Flow Solver for best convergence results.
The main goal of the CAS is to identify violations on the network base case and the post-contingency case. There are normally three
types of violations:
1. Voltage limit violation – this refers to voltage values at a certain bus that exceed its upper or lower limit
2. Voltage deviation violation – this refers to the condition where the difference between pre-contingency and post-
contingency voltages exceed a defined limit
3. Thermal violation – this occurs when the current flowing through certain equipment exceeds the equipment limit
In addition to the above violations, voltage collapse is another condition that is identified by the CAS. Voltage collapse refers to a
system instability where the power flow cannot solve due to the system conditions. During a contingency, voltage collapse may
occur immediately if the post-contingency operating point does not exist, which is a serious condition in a power system.
Based on the existence of post-fault operation and violation, contingencies are classified as one of three types:
1. Secure contingency – this has a post-contingency operating point and no violation

2. Critical contingency – this has a post-contingency operating point and some voltage or thermal violation
3. Insecure contingency – this has no post-contingency operating point. An insecure contingency indicates that the system
will not survive (no static solution) should the corresponding contingency occur. While the system may operate under
certain violations for a certain period of time, the base-case power system will suffer from a voltage collapse immediately
if an insecure contingency occurs. Conventionally, an insecure contingency is declared if the post-contingency power flow
diverges.
The CAS engine can reliably identify insecure and critical contingencies after applying the base-case dataset against a list of credible
contingencies. The outputs are three sub-lists:
 Secure contingencies
 Critical contingencies
 Insecure contingencies
For each of the above categories, the CAS provides a list of violations associated with each case. The results are archived
automatically once the computation is done. Among the critical and insecure contingencies, the insecure contingencies are ranked
as worst, followed by the critical contingencies. The critical contingencies themselves are ranked based on the severity of violations.
Contingency Analysis
The integrated method that has been developed for Contingency Analysis is described in the following steps:
1. Perform a power flow analysis on each contingency in the contingency list generated by the Data Bridge from steps 2-4.
The contingency list is a pre-arranged/pre-defined list based on credible network outages defined by operational
engineers.
2. If the power flow analysis diverges, perform homotopy-based Smart Power Flow to compute the margin to the voltage
collapse point.
3. If the margin is less than one, declare it as an insecure contingency. Otherwise, export the post-contingency power flow
when the margin hits one.
4. Compute violations. If violations exist, declare it as a critical contingency and export the violation list. Otherwise, declare
it as a secure contingency.
5. Rank contingencies with the insecure ones at the top, then the critical ones and finally the secure ones. The limiting
contingency is the most severe one.
6. If the limiting contingency is an insecure contingency, run preventative control. If the limiting contingency is a critical
contingency, run corrective control. These terms are explained in Section 5.4.4.1 and Section 5.4.4.2.
7. Export the preventative and corrective control action recommendations.
5.4.4.1 Preventative Control
When the load margin to voltage collapse for the base case is sufficient, yet the system may still be insecure should certain critical
contingencies occur, the integrated package determines effective preventative controls. These preventative controls are
recommendations made by the CAS tool that the user should consider to secure the system. The preventative controls are
implemented to increase the load margin for counteracting insecure contingencies by selecting controls from the following
candidate options:
1. Transformer tap position using On-Load Tap Changer (OLTC)

2. Generator real power output
3. System reconfiguration
Additional details on the controls and related objectives are provided in the LADD, which is available upon request.
5.4.4.2 Corrective Control
Whenever there are violations, the integrated package determines effective corrective controls. These corrective controls are
recommendations that the user should consider to secure the system. The CAS determines the corrective controls to remove
violations by exercising all of the following control actions:
1. Transformer tap position using On-Load Tap Changer (OLTC)

2. Generator real power output
3. System reconfiguration
The results of the Contingency Analysis, along with the system file, are archived automatically and summaries of the results are
written to the internal architecture reporting facility in .csv format.
Online Study Mode
Study mode is the place for users to conduct detailed contingency studies of the network. Operators and engineers can run different
analyses, and can manipulate system parameters to test their impact.
Study mode runs as a standalone process, which can be launched directly from the workstation desktop or from the CAS Viewer.
In Study mode, the user can open an archived case from the CAS Viewer or load cases from local storage. Study mode can also load
base cases generated from PowerFactory in CIM format and perform analysis on the case. When working this way, the wizard in
Study mode will create a study case set based on the imported study case and other supporting files. Study mode has the same
capabilities in terms of Contingency Analysis, Preventative Control and Corrective Control as described in section 5.4.3.
Forecasting Engine
The BSI Forecasting Engine is a standalone application. It utilises data from multiple data sources which are listed below and shown
in Figure 7:
 Metered data from the OSIsoft’s PI Historian database as an offline manual Excel file copy
 Met Office weather forecasts via FTP
 National Grid wind generation forecast
 ENTSO-E day-ahead interconnection schedules via FTP
 ‘Live feed’ measurement data from CAS
When the managed network footprint includes full or near full coverage of the forecaster and CAS snapshot data has been archived
in the Forecaster database for more than six months, the historical data provided by CAS will be used to train and produce forecasts.
Initially, a data extract from the OSIsoft PI Historian database is used to train the forecaster algorithms.
For further details on forecasting application please refer to UKPN’s SDRC 9.3 report (Completion of installation of forecasting
modules that will link the DNO control room with other data sources).
5.5 Technology Architecture
The technology architecture defines the landscape in which the CAS will reside. Communication interfaces, data storage and
retrieval, linkage with other relevant systems, network and communication infrastructure to support the CAS are defined in this
section.
Contingency Analysis Technical Design
Figure 9: CAS Cloud Architecture shows the Contingency Analysis architecture that will be delivered with the project. The
architecture comprises the following components:
1. A high level view of the Technical Architecture

2. Servers to host the CAS
3. Contingency Analysis software
4. Data links to the source systems
The CAS solution has been designed to work with a Microsoft Azure cloud solution. There are a number of reasons why cloud based
architecture has been chosen:
 Lower costs if using the server for short-term projects or if there are opportunities to power down the server outside core
business hours. This concept is not viable when purchasing physical hardware
 Speed of deployment – it only takes around 15 minutes to provision a new server using a standard Microsoft image
 Ability to make configuration changes to virtual machine specification with only a reboot – very useful if there are any
performance issues
 Scalability – as the project progresses, it is possible to add more virtual machines to a scalability set to increase
performance, if the software allows this
 Moves UKPN closer to the Services Orientated Architecture (SOA)
 Reusability – any of the designed data items can be subscribed to by any future application or project within a small time
frame. This will build our catalogue of data integration and make future data integration tasks faster and cheaper to
implement. Rather than develop application-to-application interfaces, we have decoupled the business and integration
logic.
Figure 9: CAS Cloud Architecture shows the Contingency Analysis architecture that will be delivered with the project.
Figure 9: CAS Cloud Architecture
5.5.1.1 Technology Architecture Components
Like other critical systems, the CAS is expected to operate in high availability configuration with primary and standby servers.
Supporting IT architecture has also been designed for model, code and data migration from the development/test environment to
the production environment.
Figure 10 shows the cloud based IT technology stack. Key components within this are:
 The use of Citrix XenApp to deploy the CAS client, which reduces the overhead from an IT operations perspective when it
comes to software installation/upgrades and also removes the risk of installing software onto our secure control room
workstations
 The high availability configuration, which uses the availability sets within Microsoft Azure
 The Azure Service Bus, which acts as the pathway for all data integration from our on-premise assets to our cloud presence
 Express Route, which provides a secure and direct connection between UKPN’s data centre and the cloud so that no data
is transmitted across the public internet
 The scalability of the virtual servers – it will be possible to add more resources to a virtual server if it is seen to have any
performance issues
Microsoft
Azure
Resource
group
Pre-Production Availability Test Availability set

set
PreProduction PreProduction Test CAS Test CAS

CAS Server 1 CAS Server 2 Server 1 Server 2
Look Ahead Availability set Real Time Availability set
Look Ahead Look Ahead Real Time CAS Real Time CAS
CAS Server 1 CAS Server 2 Server 1 Server 2
FAT Client Support

via Citrix RDP via
Citrix
XenApp
XenApp
ExpressRoute Storage (Azure) Service Bus Firewall
Figure 10: Cloud infrastructure
Figure 11 shows the existing IT infrastructure which UKPN already has in place. The key assets are the PowerOn Fusion and
PowerFactory applications (the source systems for elements of the data required by CAS) and IBM Integration Bus and IBM Data
Power (which forms the pathway for all data transfers into the CAS).
Figure 11: A simplified outline diagram showing UKPN infrastructure
The CA architecture will comprise the following hardware/software stack:
System Technology Component (Version) Explanatory Notes

Azure Azure Service Bus Cloud service supporting application integration via messaging
Azure Iaas Virtual Machine Infrastructure as a Service Virtual Machine
Azure RemoteApp Cloud based application hosting
IBM Integration Bus Message Queue (MQ) On-premise service supporting application integration via messaging
GE PowerOn Fusion DPF Server PowerOn Fusion is UKPN’s DMS and the DPF component carries out
the bus branch network reduction and passes this output to CAS.
DIgSILENT CIM export PowerFactory is UKPN’s current power modelling tool and holds the
PowerFactory loads, ratings and power flow models down to the 11kV circuits. This
information is exported in Common Information Model (CIM) format,
which is based on eXtensible Markup Language (XML).
ENTSO-E RESTful Data Service The ENTSO-E Transparency Platform offers data relating to
Transparency interconnect imports/exports. This is accessed via a RESTful web
Platform service and messages are in eXentisible Markup Language (XML)
format.
Met Office Met Office Data Feed The Met Office data feed is a premium service, to which UKPN
subscribes. The information is collected from the Met Office via File
Transfer Protocol (FTP) and is in Comma Delimited Values (CSV)
format.
Spazio SFTP Server Spazio is UKPN’s Secure File Transfer Protocol (SFTP) server.
Table 3: Hardware/software stack
5.5.1.2 Virtual Servers
The CAS is hosted on Microsoft Windows Virtual Machines, which in turn are hosted on the Azure cloud platform.
Based on the failover requirements, both for application stability and server availability, the virtual machines will run within two
separate Azure availability sets. One set will hold the Real-time servers and the second will house the Look-ahead servers. By
creating these availability sets we will have a 99.9% uptime Service Level Agreement (SLA) from Microsoft.
5.5.1.3 Scalability
The CAS architecture has been hosted on the Azure platform to allow for future scalability to include all three DNO areas. If UKPN
expands KASM into new DNO regions, more virtual machines (or additional processing cores and memory, dependent on further
cost analysis) will be added to deal with the processing of their respective DNO networks, as per BSI’s system requirements
calculations.
5.5.1.4 Backup & Restore
All Azure storage is hosted on locally redundant storage across three separate virtual disks. Azure Backup will be added and can be
scheduled to run backups daily or weekly and with locally redundant or geo redundant storage as required.
5.5.1.5 Performance
The expectation is that the chosen Azure platform will meet the performance requirements. However, hosting on the Azure
platform gives flexibility in the processing power available and the underlying environment can easily be upgraded or downgraded
as required.
5.5.1.6 Storage
The CAS application will be hosted on the respective virtual machines but there will be some storage provisioned within Azure
Storage which will be used to archive data.
Application Software
The contingency analysis server will run on the Windows server virtual machines in the cloud.
Electrical Model and SLD
5.5.3.1 PowerOn Fusion
KASM is dependent on the PowerOn Fusion DPF server and the exports it provides. PowerOn Fusion runs the export on a scheduled
basis via a scheduled job, which runs every 15 minutes. Once the export has been produced, the scheduled job transfers the output
to IBM Integration Bus via the FTP, and the IBM Integration Bus then transfers the output file via SFTP to the Azure virtual machine,
into the DPF directory. The CAS application then polls the specified directory and processes any new files on a timer basis.
5.5.3.2 PowerFactory
As changes to the PowerFactory model are quite infrequent, a notification will be sent to the PowerFactory administrator whenever
a change to the KASM network area is detected from within PowerOn Fusion. Receipt of the notification will trigger a manual export
of the electrical model, in CIM format, and this will be manually copied to the CAS server. The same notification method will then
advise the CAS administrator to reload the model into the CAS application.
5.6 Security Architecture
The following section covers security considerations associated with the architecture design.
Physical
There are no requirements for the physical security of the CAS. The physical security inherited by the hosting infrastructure will
meet any security concerns.
Communications
All external communications and links to third parties will leverage the existing corporate infrastructure and approved methods of
communications:
1. SFTP using the Spazio service

2. HTTPS IIB gateway to ENTSO-E
3. FTP over VPN to NG
Information Security
The sensitivity of the data used within the CAS is low. The data originating from the NG Wind Generation Forecast interface could
be considered to have some slight commercial value, however the data only provides a small subset of the generation forecast.
Any transmission of data within corporate networks will utilise secure methods of transport, such as Message Queue (MQ), HTTPS
or SFTP.
Existing Security Architecture Impact
The internal security architecture is already in place to support the secure transmission methods described earlier (MQ, HTTPS,
SFTP), but there are some new requirements for the private cloud architecture. UKPN already has in place an Express Route link
between our Data Centre and the Azure cloud environment for Microsoft Azure’s Infrastructure as a Service. However, in order to
ensure the use of a private link for any internal service bus (IBM Integration Bus) to a cloud based service bus (Azure Service Bus),
some changes will need to be made to the existing Express Route configuration/licensing to route Platform as a Service traffic down
the same network route.
6 Architecture Sign-off
The purpose of the Architecture Review Board (ARB) within UKPN is to ensure that all IT Solution designs are:
 Strategically aligned
 Avoid high costs of development, operation and support
 Are of sufficient quality
 Minimise risks
 Demonstrate re-use and replication of existing solutions where appropriate
In the context of the KASM project, the role of the ARB was to review the CA integration design and provide the architectural
assurance and guidance to the project.
The KASM CA integration architecture was presented to the ARB by the Project Architect. The main areas of focus for the submission
were around how to transfer data and the hosting environment for KASM. The submission was approved with the key points being:
 The high-level solution architecture is appropriate

 The use of our existing Enterprise Service Bus (ESB) to transfer files/data across UKPN’s network
 The use of a new Azure Service Bus to transfer files/data within the Azure cloud network
 Using bus topics to ensure reusability of data feeds (where appropriate)
 The hosting of Azure on cloud based virtual servers
 Using the newly commissioned ExpressRoute network connection which provides UKPN with a dedicated path between
our internal network and the Azure cloud. No use of internet networks in the transferral of data between UKPN and
Azure cloud
 FTP to either MQP or AMQP as soon as possible in the transfer chain. Also ensures delivery and allows re-use of any of
the data feeds for future use
7 Completion of Installation and Demonstration
The project has successfully installed and demonstrated the core functionality of the CAS. The scope of this section is to define the
Testing Strategy for the CAS, and the forecasting capabilities of the software platform. It describes the approach to testing and the
phases involved to fully demonstrate that the solution delivers the functionality using all aspects of the hardware and software
required for the CAS. This strategy defines the purpose of each test phase and the roles and responsibilities of each stakeholder
for the test to be successful, which includes defect, change and release management processes.
7.1 Testing Strategy
The following section provides a high-level breakdown of the Testing Strategy applied. The detailed strategy has been captured in
the project Test Strategy document, which is available upon request.
The CAS is envisaged as a tool that will support near real-time operations once implemented. This vision for the CAS transforms it
from being an innovative application to a business-as-usual solution soon after being trialled for the purposes of the KASM project.
Given the rigour needed to implement a system for supporting a critical system, the testing of the CAS has been split into two
releases. Each release will have factory and site acceptance tests conducted and documented.
 Release 0 – Core Product: during this release the core applications and their capabilities were tested. The key areas of
focus were: data import, data accuracy from import and solution quality perspectives, core system interfaces, engine
performance, manoeuvrability and system installation.
 Release 1 – Final Product: during this release the full CAS application will be tested end-to-end. Modifications and/or fixes
coming out of Release 0 will be incorporated. The application user interface will be fully developed with the automated
integration of various data interfaces and applications.
Testing Overview
The KASM CAS testing followed a risk based test approach which entails both static and dynamic testing:
 Static testing involved evaluating a source document such as Requirements or Acceptance Criteria without execution of a
particular test script. Static testing occurs during reviews and walkthroughs of source (approved) documents such as KASM
Requirements, test scripts execution results or Acceptance Criteria
 Dynamic testing involves evaluating an application or a service based on its behaviour during execution of a particular test
script. Within dynamic testing, various factors such as operational capability, accuracy, business risk and performance
criticality were analysed, so that a decision could be made on the test phases to perform and the amount of testing to be
done.
Testing Process
The next section describes the key processes that were applied during testing. Any deviations from this process are documented
and justified in the Test Strategy document.
A number of test phases were coordinated and managed by the nominated test lead and executed by relevant testing team(s). The
test teams comprised resources from multiple organisations or external third party organisations. During the testing phases all
identified defects were registered in a common defect log. The defect log was distributed by the test lead to all relevant parties
and was discussed on a regular basis to prioritise, resolve, release, retest and close all defects. The defect log was maintained across
all testing phases, to ensure that defects do not reappear during future test phases and for audit capability.
The test phases, at a high level, are:
Release 0:
 Factory Acceptance Testing – the supplier’s own testing prior to installation

 Site Acceptance Testing – validating the installation functions as per the design
Release 1:
 Factory Acceptance Testing – the supplier’s own testing prior to installation

 Site Acceptance Testing – validating the installation functions as per the design
 Network Testing – validating the communication connectivity and its integrity
 System Integration Testing – validating the CAS software with imported data and live system information from NG and
UKPN sites
 Business Continuity Testing – ensuring CAS and forecasting systems work if any part of the infrastructure malfunctions
 User Acceptance Testing – verification of CAS solution against existing output from systems
 Non Functional Testing – to validate server/application related functions like backup & restore, data storage, user access,
penetration/security and scheduled housekeeping tasks
 Operational Acceptance Testing – validation of process(es) to support CAS in live production, including routine data
imports
 Cutover Process Testing (CP/CPT) – a dress rehearsal to ensure smooth transition into live production
 Regression Testing – to ensure that no errors or problems have been introduced and existing unchanged areas of the
application/service still function as they did prior to the changes
Additional detail on the test phases is provided in the LADD, which is available upon request.
Organisations Involved
The following organisations or departments provided input into the CAS testing:
 UKPN’s operations team, who are day-to-day users of the system (control room engineers, outage planners and
infrastructure planners)
 UKPN’s KASM project team, who are responsible for delivering the KASM solution
 NG’s KASM project team, who are responsible for assisting in delivering the KASM solution
 BSI, who are delivering the CAS and forecasting solution
 Navigant Consulting Inc., who are involved with the test script development and test supervision
There are a variety of other supporting suppliers/installers who are not listed here to maintain clarity.
7.2 Test Approach
At the start of each testing phase, the test lead was responsible for producing a detailed test plan specifying the total scope of the
testing to be undertaken.
All test cycles were owned by specific test teams and allocated to a specific individual within the team. That individual was
responsible for the production of the test preparation and for conducting the test execution.
KASM CAS Environments
The core CAS environment shows the infrastructure installed at UKPN sites. The environment includes the communication
infrastructure, data storage, application servers, human machine interfaces (HMIs) and connectivity to external entities (e.g.
generation and weather interfaces) for forecasting. The CAS has three distinct integrated environments:
1. Test (virtual server on a UKPN site)

2. Pre-production (server hosted in the cloud)
3. Production (server hosted in the cloud)
Integrated components:
 PowerOn Fusion (Production) (Pre-Prod and Test was available if required)

 PowerFactory (Production)
 Secure File Transfer Protocol (SFTP) (to receive files from NG)
 IBM Integrated BUS (IIB) (this has a Test, Pre-Prod and Prod)
 Inter-Control Centre Communications Protocol (ICCP) (Production) (Pre-Prod and Test is available if required)
 Internet connections with ENTSO-E and the Met Office
Human Interface (HMI) connectivity:
 UKPN users and administrators used their existing laptops and/or desktops to connect directly to all three CAS
environments. Each user had a distinct way of connecting to CAS Test, Pre-Prod or Production, ensuring that no confusion
occurred when logging into CAS
 External stakeholders connected via VPN tunnel and/or predefined access methods as per UKPN’s Security policy
As a default, all three environments were integrated with the existing production systems. For example, UKPN’s PowerOn Fusion
and PowerFactory production systems were integrated with the CAS Test, Pre-Prod and Production environments. However, where
available, equivalent Test and Pre-Production systems were used.
For Release 0 testing, only the CAS Test environment was used and all interfaces were manually integrated. Thus any data required
by CAS was dropped into appropriate locations manually.
7.3 Testing Phase Details
Test Phase Entry Criteria
Standard software testing procedures with rigorous controls have been deployed due to CAS supporting critical real-time
operations. Figure 12 shows the relationship and dependency of the test phases and documentation produced during the planning
and execution of the tests. The documents are captured in orange and the workflows are captured in red.
Testing Planning
Test Strategy
Testing Strategy
Test Plan
Test Execution Report
Test Scripts Defect log
KASM Test Phase

Test Exit Criteria
Completion Report
Test Closedown
KASM Test Phase

Lessons Learnt
Completion Report
Figure 12: Flowchart showing the relationship and dependency of the test documentation
Testing Responsibility Matrix
Table 4 shows the major activities and the role that is responsible for performing, approving or supporting the testing activities.
The RASCI chart defines responsibilities and interrelationships, normally for tasks or deliverables for the test phases. All of the test
phases are described in detail in the LADD. Unit and System testing is totally at the discretion of the supplier.
The acronyms are:
 R (Responsible): those who do the work to achieve the task. There is at least one role with a participation type of
‘responsible’ – although others can be delegated to assist in the work
 A (Accountable): the individual ultimately answerable for the correct and thorough completion of the deliverable or
task, and the individual who delegates the work to those responsible. In other words, an accountable individual must
sign off on (approve) work that the responsible individual provides. There must be only one accountable individual
specified for each task or deliverable
 S (Supports): those who are in a position to support the activity and the infrastructure
 C (Consulted): those whose opinions are sought (typically subject matter experts) and with whom there is two-way
communication
 I (Informed): those who are kept up to date on progress, often only on completion of the task or deliverable, and with
whom there is only one-way communication
Test Supervision
Business User
Test analyst
Test Lead
Supplier
Produce FAT test plans and scenarios R A A/C C
Collate FAT input data and pre-requisites R A C I
Execute FAT C/I I I R/A
Witness and sign-off of FAT A A/C C R
Defect and software version control A I I R
Environment management FAT C/I I I R
Table 4: RASCI matrix for FAT
7.4 Testing Metrics
All test phases have the ability to extract test metrics. These indicate the progress, status and level of testing that was performed
during that test. The metrics allow the test lead to understand how results from certain tests may impact the overall test plan and
ensure that any defects that are picked up are shared with the wider test team. Further information about the testing metrics can
be found in the Test Strategy.
7.5 Defect Management
The Defect Management process covers finding a defect through to it being resolved. Defect Management was applied to all phases
of testing, from static testing onwards, with defects being raised by the test team during acceptance tests.
7.6 Release Management
Release Management allows the project to track each deliverable throughout the project life cycle. As changes are inevitable, the
project and BSI undertook version control of any change to the system. BSI releases included the reason explaining the change and
uniquely identifying the change and/or defect identifier. This helped to manage and test changes to the system prior to going live.
Each delivery was accompanied by a release note describing the above.
7.7 Assumptions
Based on the knowledge at the time the Test Strategy was prepared, the project assumptions are listed below. If an assumption is
invalidated at a later date, the activities and estimates in the Project Plan will be adjusted accordingly.
 A Project Plan is in place to identify the resource effort required to undertake the testing outlined in the Test Strategy.
 Project resources are in place and available, including subject matter experts, technical experts, hardware, desks, PCs etc.
(see entry and exit criteria section for further details).
 The delivery of environments is on time and has been successfully tested by the suppliers.
 All project requirements must have been reviewed, agreed and placed under configuration control.
 Test resources have been identified and made available.
 The test environment will be prepared and set up in advance of test execution, pipe cleaned and available for testing
activities as per the stated entry and exit criteria.
 Changes to the project scope will be made through a release management process. These may result in some of the test
scripts being reworked.
 The hardware and software are available to facilitate the test execution.
 There is sufficient availability of data and support from various teams
7.8 Test Results
The following section provides the results from testing and demonstrations of the CAS. It is the basis for validating that the CAS has
been installed successfully on UKPN’s IT systems, and that the relevant tests have been performed to ensure the core functionality
can be proven. Following FAT and SAT the relevant exit reports were produced and signed off by the supplier, test lead and business
lead. Certain tests have been marked as partially completed in the Release 0 stage. Core aspects of the test have been completed
using the Release 0 solution, however additional Release 1 testing is required to validate the full test. Moving forward, these tests
have been retained in the list to ensure they are tracked and re-tested along with Release 1 testing.
Release 0 Testing
The testing process for the KASM project involved the preparation of detailed test cases. The requirements were analysed and
relevant test cases were documented. The test cases target key business functional areas:
 Project related tests (shown in red)

 Real-Time control related tests (shown in green)
 Infrastructure Planning tests (shown in pink)
 Outage Planning related tests (shown in blue)
The requirements were analysed by the relevant functional groups and test cases related to the relevant requirements were
documented in detail. This process ensured coverage of the requirements from various functional perspectives and resulted in
multiple test cases relating to a single requirement. A summary of the functionality tested under each functional group is covered
in the following sections.
7.8.1.1 Project-related Tests
These are test cases related to the basic operations of the system from an operational perspective. The test cases defined within
this category aim to ensure the software is able to:
 Import/load UKPN data

 Accept modifications to the data
 Export the required results
 Perform various tasks
 Archive and retrieve the cases
 Report results on screen and through printable methods
 Manoeuvre the user interface
7.8.1.2 Real-Time Control-related Tests
Test cases in this category focus on the real-time functionalities of the system. They aim to ensure the software is able to:
 Reflect the validation of variations in near real-time

 Execute CAS in Real-time mode at regular intervals and store the case
 Create contingency case with various network elements
 Provide real and reactive power balancing capability
 Import control limits from DMS into real-time case
 Adjust network element ratings in real-time
7.8.1.3 Infrastructure Planning Tests
Test cases in this category focus on the feasibility of using CAS as an effective tool for infrastructure planning. They aim to cover
the following aspects:
 Data validation before execution

 Comparison of the power flow results with the XML power flows using historical data
 Creating contingency cases in Study mode consisting of combinations of network elements and run CAS
 Running Load Flow in CAS to balance load demand and generation demand based on slack bus dispatch (within an isolated
region)
 Configuring ratings of circuit components
7.8.1.4 Outage Planning-related Tests
Test cases in this category focus on assessing the capability of CAS in the outage planning operations. They aim to test whether the
CA solution is capable of:
 Operating in three distinct modes (using real-time data, historical data and forecast data)
 Modelling a contingency case consisting of combinations of network elements
 Running studies for pre-determined and configurable intervals
 Modelling load flow to balance load demand and generation demand as well as real and reactive power
 Importing components from DMS and manually amending different component ratings
 Using the network switch and reflecting the connectivity arrangements taken from the DMS system
Table 5 presents a summary of test outcomes.
Test Number Test Description Success Y/N

3.1.2 Real-time performance of load flow and contingency analysis calculation Y
3.1.3 Study mode performance of calculating load flows and contingency analysis Y
3.1.4 CA Model management Y
3.1.5 The CAS must provide data for outage management studies and analysis Y
3.1.6 The CAS must provide data to support reliability management studies and analysis Partial
completion.
Release 1
test required
3.1.8 Study cases and results Partial
completion.
Release 1
test required
3.1.9 The outputs from the CAS shall be represented in a clear and concise format, supported by Partial
data tables and a single line diagram which can easily be interpreted – both in Study mode completion.
and Real-time mode Release 1
test required
3.1.13 The CAS will be able to import the network model and its specifications from DIgSILENT
PowerFactory. The methods for integration must be robust, i.e. Common Information Model Y
(CIM)
3.1.14 The CAS model must be capable of taking detail networks and equivalent networks (400kV,
Y
275kV, 132kV, 33kV, 11kV)
3.1.15 The CAS must have flexible network model and allow for network updates based on changes
Y
in network detail and KASM network boundaries.
3.1.16 The CAS must be able to exchange network models based on industry standard information
Y
exchange standards, i.e. Common Information Model (CIM)
3.2.1 Validation of model variations are reflected in near real-time Y

3.2.2 Execute CAS in Real-time mode at regular intervals and store the case Y
3.2.3 Create contingency case with various network elements Y
3.2.4 Real and reactive power balancing capability Y
3.2.5 Import control limits from DMS into real-time case Y
3.2.6 Adjust network element ratings in real-time Y
3.4.1 Data validation before execution Y
3.4.2 Run CAS in Study mode using historical data and compare the power flow results with the
Y
XML power flows
3.4.3 Create contingency cases in Study mode consisting of combinations of network elements and
Y
run CAS
3.4.4 Run load flow in CAS to balance load demand and generation demand based on slack bus
Y
dispatch – within an isolated region
3.5.1 The CAS must be able to operate in three distinct modes Y
3.5.3 Run studies for pre-determined and configurable time intervals Y
3.5.5 Model Load Flow to balance load demand and generation demand Y
3.5.6 Balancing real and reactive power Y
3.5.7 Import components from DMS Y
3.5.9 Import different component ratings Y
3.5.10 Network switch status should reflect the connectivity arrangements taken from DMS system Y
3.5.11 Data validations before execution of Load Flow calculations Y
Table 5: Summary of Release 0 test results
From Table 5 it is clear that the core functionality has been tested with successful results. These results are discussed in section
7.8.2
Results of Testing
As previously mentioned, the aims of the Release 0 testing were to ensure that the core functionality of the CAS was developed,
highlight any concerns with data imports and validate the accuracy of the outcomes. This section explains the outcomes of key
tests to demonstrate key CAS functionality – with the understanding that not all tests will be covered.
CAS is a supporting tool that will enhance real-time and planning operations to produce credible results. To ensure the data
imported is accurate, several test cases were defined to validate the data import into CAS. For these test cases, a series of PowerOn
network measurement data, time variant with multiple network changes, was imported into the CAS.
7.8.2.1 Data Import into CAS
The data import process involves utilising data from various sources; these have been explained in detail in the Data Architecture
section. The key data imports that need to be performed in order to have a functioning model on which the CAS tool can perform
analysis are the PowerFactory CIM data and the PowerOn Fusion XML data. In this section the tests related to data loading are
performed.
The following screenshots illustrate the data loading from PowerFactory and PowerOn Fusion. Here, the related PowerFactory and
PowerOn Fusion files are selected into the data mapping tool of the CAS and processed to generate a static data model.
Figure 13: Running data mapping shows the interface of the data mapping engine. The relevant PowerFactory CIM file and PowerOn
Fusion XML file are loaded through this interface.
Figure 13: Running data mapping
Figure 14: Data mapping successful shows the successful mapping of the PowerOn Fusion and PowerFactory models. This forms
the base network model that will be analysed using the CAS tool.
Figure 14: Data mapping successful
Figure 15 shows the CAS application real-time/online mode window with a previously loaded case. The following diagrams are
screenshots of a new XML file being loaded.
Figure 15: CAS application real-time/online mode window
Figure 16 illustrates the processor loading that indicates the complex data mapping and XML loading process of the CAS tool. The
four peaks in CPU usage demonstrate CAS processing a new XML.
Figure 16: Processor loading
Figure 17 illustrates that the selected XML is loaded and the CAS tool has performed the base case contingency analysis.
Selected XML
loaded
Figure 17: Selected XML is loaded and the CAS tool has performed the base case contingency analysis
To ensure proper loading of the data, multiple XML files that were time variant were loaded into the CAS tool. The following
diagrams illustrate the tests related to loading of data from different intervals and the comparison of the variation in the data
within the case.
Figure 18 illustrates that the first XML file is being loaded into the CAS online application viewer.
New XML loaded with

different timestamp
Figure 18: CAS screenshot showing XML load in viewer
Figure 19 illustrates the loading of a second XML file extracted at a different time. The viewer indicates the loading of the second
XML file.
CAS reflects latest XML

model available
Figure 19: Example CAS screenshot showing loading of second XML and verification in viewer
Figure 20 illustrates the comparison of the data from two cases with varying timestamps loaded into the CAS tool. The two cases
loaded were KASM_2016-0824_13_00_09.xlsx and KASM_2016-08-24_13_30_08. The data from the relevant cases was exported
and loaded into a comparison tool that highlights the variations in the data contained in the two cases. The comparison tool
highlighted that the components within each of the models were consistent; therefore, the import methodology was considered
robust and to have been successfully demonstrated. The results from both models (which were taken 30 minutes apart) show a
very similar number (940 and 941) of state estimated results, indicating the same model components.
Two files loaded at different times showing

similar number of state estimated values in
CAS
Figure 20: Comparative analysis showing variation of data in the loaded files
7.8.2.2 Performance of Load Flow Contingency Analysis Calculation in Real-time and Study Modes
Testing the performance of the application is key to ensuring the tool is usable and can perform the analysis in the expected time
frames. Performance criteria were identified during the requirements stage, and this section illustrates the related testing that was
conducted.
In Real-time mode, assuming an optimised network and appropriate hardware, calculations such as load flows and contingency
analysis must not exceed 30 seconds. In Figure 21 and Figure 22 it can be clearly seen from the computation time that the cases
load and solve in real-time within 30 seconds.
Loaded in 12
seconds
Figure 21: CAS screenshot showing the performance result from loading first case
Loaded in 13
seconds
Figure 22: CAS screenshot showing the performance result of loading second case
Similar to the above real-time/online case performance, in Study mode, assuming an optimised network and appropriate hardware,
calculations such as load flows and contingency analysis must not exceed two minutes. Figure 23 and Figure 24 illustrate the ‘Study
mode’ window used to test the performance of the CAS in Study mode.
CA ran at 13:56:33
Figure 23: CAS screenshot showing example execution timestamp before Study Mode run
CA ran at 13:58:18. 105

seconds elapsed since
previous execution timestamp
Figure 24: CAS screenshot showing example execution timestamp after study mode execution
In comparing the execution timestamps from Figure 23 and Figure 24, it can be seen that from launching a study mode to running
a full power flow and ranking contingencies it took 105 seconds. It should be noted that most of this time was utilised in capturing
screenshots rather than actual computation time. The engine performance is very fast – and well within the two-minute
requirement.
7.8.2.3 Power Flow and State Estimation Solver
The core functionality of the CAS tool is the Power Flow and State Estimation Solver. The ability to process the network model and
perform contingency analysis in real-time and offline studies is critical.
The following section demonstrates that the CAS State Estimation and Power Flow Solver results are considered to be accurate.
The screenshots show the launch of a study session from Real-time mode, which will enable the user to interrogate the power flow
results. The CAS power flow results have been compared with actual PowerOn measurement points to validate the accuracy of the
tool.
Figure 25 shows the viewer in Real-time/online mode, from which the Study mode will be initiated. It shows how the user can
select a specific study case to analyse.
Button to launch
the Study Mode
viewer
Figure 25: Launch Study Mode
Upon selection of the study case, the study mode is initiated to perform the analysis shown in Figure 26 below.
Figure 26: Study mode window
The results of the power flow are shown in Figure 27 below.
Figure 27: Base case Power Flow run
To illustrate the change in the topology represented in the CAS, it has been decided to select Canterbury South GT1 for an outage.
This is achieved through a series of steps using the interactive interface of the CAS and creating a contingency. The resulting analysis
(see Figure 28) shows the flows being reduced to 0.0 – indicating the outage of the network element.
0.0 flow on bus 236
Figure 28: Power flow result indicating 0.0 flow through element selected for an outage
In addition to the above test, a manual comparison of results from the CAS tool and PowerOn screenshots was performed. This
resulted in the following outcomes, which are within an acceptable error tolerance:
 RICH CB405 PowerOn screenshot shows 10MW, CAS base case shows 12.3MW (delta 2.3MW)
 RICH CB605 PowerOn screenshot shows 3.3MW, CAS base case shows 4.1MW (delta 0.8MW)
 RICH CB805 PowerOn screenshot shows 2.9MW, CAS base case shows 0.0MW (delta -2.9MW)
 RICH CB505 PowerOn screenshots shows 8MW, CAS base case shows 12MW (delta 4MW)
 SELL CB305 PowerOn screenshot shows 44.4MW, CAS base case shows 41.2MW (delta -3.2MW)
 SELL CB505 PowerOn screenshot shows 64.2MW, CAS base case shows 57.7MW (delta -6.5MW)
 CANTS CB505 PowerOn screenshot shows 6.5MW, CAS base case shows 9.4MW (delta -2.9MW)
 CANTS CB405 PowerOn screenshot shows 59.3MW, CAS base case shows 59.5MW (delta 0.2MW)
It should be noted that the PowerOn Fusion analogue values are based on CTs 800/1A with an error range of 2-3% (16–24Amps
which equates to approx. 3.5–6MW at 132kV). Almost all of the results fit within this band. The exception is SELL CB505, which is
0.5MW outside the acceptable range. However, this is not considered critical from an end-user perspective.
Additional tests to cover the full set of test cases including demonstration of balancing capability, changing of control limits,
changing of equipment ratings etc. were performed during Site Acceptance Testing. The detailed steps and screenshots have been
captured in the test results.
One of the challenges of using the CAS was that a solved State Estimator solution does not exist. To solve this problem, BSI had to
generate a State Estimator solution that was credible enough to support the real-time operations, outage and infrastructure
planning groups. The process used to validate the results is illustrated in Figure 29. While this will be the validation process when
both Release 0 and Release 1 are complete, intermediate validation was performed by comparing the power flows from the CAS
and the power flows from PowerOn Fusion.
Primary Test – FAT sessions Secondary Test - UKPN pre-prepared/set before FAT sessions
Taken almost at same time

XML_1, 2, 3,
PowerOn Transmission
4
1. model_KASM_2016-08-19_13_40_09 Snapshot analogues
2. model_KASM_2016-08-19_13_50_09 Snapshots
3. model_KASM_2016-08-19_14_00_14 1. 33kV_EXISTING_13_37_59; 132kV_EIXISTING_13_38_39
4. model_KASM_2016-08-19_14_05_11 2. 33kV_CB505CB2105OPEN_13_48_17; 132kV_CB505CB2105OPEN_13_48_58
3. 33kV_CANTN_KEMS_PARALLEL_14_00_58; 132kV_CANTN_KEMS_PARALLEL_14_00_29
4. 33kV_PARALLEL_OFF_14_05_40; 132kV_PARALLEL_OFF_14_06_21
Assumption: State Estimator
The state estimator processing and
output are correct all the time. This
is said to be the approach used in Combine Power
many other test scenarios. Flow & network
configuration
Base Cases
PSS/E_1, 2,
3, 4
Once, and make a conclusion
PowerFactory CAS model_1, 2, 3,4 PowerFactory

model_1, 2, 3, 4 model_1, 2, 3, 4
Repeat tests
Power Flow Power Flow Power Flow

Solution_1, Solution_1, Solution_1,
2, 3, 4 2, 3, 4 2, 3, 4
PF2
PF1 Compare
PF3
Either PowerFactory
Compare model settings or
Is PF1 & PF2 Is Outcome List for future
No Yes both to State Estimator
comparable? Acceptable? investigation
PF3 output source of
error
End
Figure 29: Diagram of primary and secondary tests for validation
8 Engagement with Stakeholders
Engagement with other DNOs took three forms:
 UKPN hosted a series of webinars with DNOs and other interested parties to discuss the project
 UKPN attended the LCNI Conference, presented the topic and gathered feedback from the audience
 UKPN engaged with a number of parties in recent discussions of Grid Code changes with the Grid Code Development
Forum and the Grid Code Review Panel.
These are explained in more detail in the table below.
8.1 Engagement through Webinars
WebEx Topic DNO/TNO Details Actions taken

Integration of WPD A basic PowerOn extract was carried The KASM team
existing modelling out as part of the FALCON project. disseminated learning
tools WPD is expecting that more through SDRC report and/or
advanced network model extracts bilateral meetings.
(e.g. CIM) will be required in the
near future.
Data quality NG In addition to defining data The CAS produced residual
cleansing rules and to identify bad error results which compare
data, UKPN should consider state estimation results
comparing the output from a State with measured data. Where
Estimator with SCADA points. large errors occur this can
be investigated further by
engineers
Sharing of NPG Similar to UKPN, NPG have UKPN successfully applied
Transmission unsuccessfully investigated the for a Grid Code change to
network models possibility of sharing the NG allow long-term planners to
between DNOs’ network model currently provided access the same NG
Contingency
operational and to DNOs’ outage planning teams network models and
Analysis and
long-term planning (for operational purposes) with operational planners
Forecasting
teams. long-term planning teams.
Webex
This is due to restrictions under the
Grid Code.
Sharing of DNO NPG NPG is currently sharing data with UKPN is sharing DNO
connected NG under Week 24 information. metering data associated
generation outputs The data is being provided to NG with embedded generators
with NG under Section 105 of the Utilities with NG
Act.
Utilisation of Initial NG The KASM team has considered the The KASM team decided not
Physical use of this information as part of its to pursue this as part of the
Notifications (IPNs) forecasting solution, but has Grid Code change.
and Maximum concluded (following discussions
Export Limits with NG) that the information is not
(MELs) from CVA sufficiently accurate to add value.
Generators
PowerOn Fusion WPD/NPG A design decision has been made UKPN provided information
State estimation not to use the PowerOn Fusion to DNOs supporting this
state estimation functionality. decision.
8.2 Engagement through the LCNI Conference
LCNI Conference 2015
The KASM project team attended the LCNI Conference in 2015 and engaged with a number of DNOs and National Grid. The
engagement during the conference was mainly focused on receiving feedback from DNOs and NG on:
 The considerations for ICCP

 The data exchange between DNOs and NG
 Load and generation forecasting
A number of challenges that were previously covered in the webinars were discussed and followed up on accordingly.
LCNI Conference 2016
The KASM team attended the LCNI Conference in 2016. Various media were used to disseminate the project learning, including
presentation sessions, videos and single page overview flyers. During the presentation sessions a number of questions were asked.
These included:
Q1) How can Contingency Analysis be used to help develop DSR schemes?
A1) The team believes that having a library of historical real-time power flows will provide a significantly improved dataset
to analyse and determine where DSR schemes could be most appropriate.
Q2) What is the speed of running through the contingencies?

A2) Currently this is operating within a number of seconds.
Comments from the audience suggested that DNOs agree they need to move away from worst-case operating practices and
manage the network closer to real-time in order to maximise asset capacity.
8.3 Engagement through the Grid Code Development Forum and Grid Code Review Panel
The project engaged with NG to determine the best approach for proposing a Grid Code change. The change proposed was to
amend the Grid Code to allow long-term network planners to have access to the same NG network models as UKPN’s operational
planners.
Initially, the project team presented with UKPN’s outage planners and infrastructure planners at the Grid Code Development Forum
on 4 February 2016. This forum discussed early-stage proposals to amend the Grid Code, and the audience included a range of
stakeholders from generation developers and suppliers to transmission network operators and other DNOs. There was strong
interest in the project, and stakeholders provided feedback highlighting the importance of data sharing between NG and DNOs in
a changing environment.
Following the meeting, it was agreed that the project team should take the proposal forward to the Grid Code Review Panel. The
proposal was presented to the Grid Code Review Panel on 16 March 2016; the audience included representatives from NG, Ofgem
and a number of other stakeholders. The proposal was subsequently approved by the Grid Code Review Panel and released for
public consultation on 15 April 2016. The consultation was supported by WPD and did not receive any opposition. The Grid Code
was amended on 28 July 2016, following approval by the Gas and Electricity Markets Authority (GEMA).
9 Conclusions
In conclusion, SDRC 9.2, related to CAS integration and testing, covers the aspects of the different architectures aligned to the
TOGAF framework. The Business, Data, Application, Technology and Security architectures are covered in sufficient detail to
illustrate the overall picture of the CAS. The test results obtained as part of the Release 0 testing indicate that the core functionality
of CAS is adequately demonstrated. The test results shown in this document, combined with the detailed test results, prove that
the data import, performance and accuracy of results are well within acceptable limits. The document also covers the testing
strategy used to test the tool. The CAS is expected to be a critical application used to support operations and planning.
The following sections cover the key lessons learned from the project to date and key risks associated with implementation of
similar projects.
9.1 Lessons Learned
Lessons learned have been tracked and recorded on the project including, through a workshop, discussions with key stakeholders
(held 24 October 2016) to identify the main lessons learned from the project to date. The discussion was structured around areas
where other DNOs implementing such projects should focus, that may impact the implementation of such systems. Four key
themes were identified during the workshop: data, interface, testing and security.
Data
 The data required to build a real-time power flow may not be able to be sourced from one application; it may require an
interface with several applications. These applications may not have the same unique IDs for the same assets, therefore
data mapping may be required.
 The synchronisation of real-time data is key to producing accurate power flow results.
 When exporting data from PowerFactory, CIM was considered the most appropriate export format. It is important to
consider that there are various forms of CIM which provide varying amounts of information. When exporting the CIM
models it is important to configure the export accurately.
Interface
 Using an integration bus provides a more sustainable and reusable solution for delivering data. The data can be easily
accessed by other projects which require the same data.
 Data can be exported from the PowerOn Fusion DMS using the DPF trace options, however there can be significant
complexity in retrieving a full network model. Several trace options may need to be used to export the data.
 When exporting data through the DPF trace, the export files do not contain any single line diagram attributes. The single
line diagram definitions were exported using alternative export capabilities. Re-creation of the single line diagram is time
consuming and the change process needs to be managed and documented very clearly to ensure the CAS is up to date.
Testing
 Validation of a power flow solver requires access to another reliable power flow solver in order to validate outputs.
 Testing should be done with primary and backup sources available.
 Access to the tool early in the process, is key to defining the necessary and sufficient test scenarios and create the
detailed testing steps. There should be a period between completing development and defining the test scenarios.
 With multiple data sources being used in the application it is critical that installation guides provide every detail required
to set up the programme correctly.
Security
 The interface with existing UKPN systems requires substantial security measures.
 User permissions should be set as per responsibilities, rather than giving generic access to everyone involved.
 Linking outputs/alerts from the CAS back into PowerOn Fusion requires significant development regarding security. This
was not included as part of this project but has been highlighted as a potential future enhancement.
 Additional security conditions should be considered for a cloud based solution.
9.2 Identified Risks
This section explores the risks associated with the integration of Contingency Analysis software within a DNO environment. The
lessons learned on the KASM project are strongly linked to risks which have been identified in the list below. These risks have been
mitigated against in numerous ways for the purposes of the KASM project. However, for future implementation of similar solutions,
the following risks need to be mitigated against appropriately, considering the DNO environment.
1. Interfacing with multiple data sources can create complex integration architecture that needs multiple data bridges in
order to translate data between applications. Multiple data bridges are difficult to maintain when introducing new data
sources. To mitigate against future issues with data bridging, the project has used a robust integration bus which provides
a single translation platform which can be managed efficiently. It is important to maintain any translation tables within
the integration bus and if input data formats change, the integration bus will not be able to translate the data. Bearing
this in mind, it is important that any application interface has a clear change control process to determine if updates to
the integration bus are required.
2. When adding new applications within critical business functions it is vital that clear training is provided to users to ensure
they are fully capable of deriving benefit from the solution. The project will mitigate against this risk through thorough
user training, user acceptance testing and easy to follow user guides. A practical example of change is that within the
control room each control desk has four monitor screens which are fully utilised in current operation practices. Providing
the new software will require one additional screen on the control desk. It is important that the positioning of the screen
is carefully designed in collaboration with control room engineers. The project team will continue to liaise with control
room engineers to mitigate against any ergonomic issues which may result in adding more screens to the control desk.
3. Hosting critical solutions in cloud infrastructure carries security risks (e.g. data breaches). However, any such threats can
be minimised through thorough design of the Azure cloud architecture and detailed penetration testing prior to go-live.
4. Building a control room interface with external parties can introduce additional risks. The security and reliability of the
control room applications can be jeopardised if external parties do not manage interfacing applications robustly. To
mitigate against this, clear terms of security management have been agreed with NG, who are interfacing our DMS through
the Inter-Control Centre Communication Protocol (ICCP) link.
5. Introducing new business processes can be daunting to existing employees, who are familiar with a single way of working.
To ensure confidence is developed in the new business process, the project aims to trial the solution over an extended
period, during which engineers can run existing processes in parallel with the innovation CAS process. This will provide
significant benefits to the end user.
6. Maintaining up-to-date network models in the CAS is vital. If out-of-date models are utilised in a decision-making process,
it can result in potentially hazardous consequences. To mitigate against this. the project has implemented secure change
control processes which will maintain up-to-date network models.
The project will continue to monitor risks and update mitigation actions. This will be captured in future progress reports and future
SDRC milestones.

Contingency Analysis System Integration

Uploaded by

Copyright:

Available Formats

Contingency Analysis System Integration

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Contingency Analysis System Integration

Uploaded by

Copyright:

Available Formats

Kent Active System Management (KASM)

SDRC 9.2 – Contingency Analysis

2 Definition of Terms ........................................................................................................................................................................ 5

5 Contingency Analysis Integration ................................................................................................................................................. 10

6 Architecture Sign-off .................................................................................................................................................................... 35

7 Completion of Installation and Demonstration ........................................................................................................................... 36

8 Engagement with Stakeholders ................................................................................................................................................... 57

1.2 Integration Architecture

 Importing of data from a range of existing applications

3.1 Purpose of Document

Key evidence criteria of SDRC 9.2:

Criteria Evidence Section

 Sign-off on successful demonstration and  Section 7

Number Document Name Author

Requirement Category Sub Requirement Test

Requirement Category Sub Requirement Test

5 Contingency Analysis Integration

4. Technology – describes the IT infrastructure that will host the CAS

5. Security – describes the security considerations, including physical, communications and IT

5.2 Business Architecture

 The control room engineer operates the distribution network in real-time.

to 36hrs 1 day to 7 days Months ahead

Figure 1: Timescales of responsibility for network management

Figure 3: Flow chart showing the UKPN outage planning process

Figure 4: Flow chart showing the UKPN infrastructure planning process

5.2.4.1 High Level Architecture

Network Control (Real-time Network Operation)

Power System Models

5.2.6.1 Network Definition

5.2.6.2 Network Trace Options

5.3 Data Architecture

1. Network connectivity including switching status

1. Single line diagram of the power network

UK Power Network data sources External data sources

Contingency Analysis Suite

Offline Data Single Line

Look-Ahead Mode Real-Time Mode

UK Power Networks data sources External data sources

CIM file XML file

Hotspot positions xls

Look-Ahead Mode Real-Time Mode

Figure 7: Block diagram showing the CAS Data Flow Architecture

5.3.2.1 Internal Data Sources (UKPN Data Sources)

NG Real-Time Data (NG Control Centre)

The Met Office

5.3.2.3 KASM Data Sources

Custom Project Lookup Tables developed by KASM Team

 Parameter Matching table (csv)

Parameter Matching Table

Supplemental List Files

Data Model Definition

5.3.4.1 Data Bridging and State Estimation – Real-time (RT) Mode

5.3.4.3 Online Study Mode

1. An archived CAS RT case

BSI Forecasting Engine

The BSI Forecasting Engine produces forecasts for the following:

5.3.5.1 Network Diagram Change Process

1. Generate a new single line diagram