Learnings

Outcomes

Due to the structure of the OpenLV trials, the outcomes are defined within discrete areas of 
learning relating to the use of distributed intelligence platforms in a wide, business-as-usual 
capacity across GB electricity networks.
2.1  Method 1 – Capacity uplift
2.1.1 Sharing the level of capacity uplift achieved through Method 1
Method 1 sought to test the hypothesis that having distributed intelligence available within 
distribution substations would enable capacity uplift through automated analysis and 
decision making based on observations of local conditions. Although the distributed 
intelligence does not in itself create capacity uplift, it does instead enable opportunities for 
capacity uplift.
Network Meshing
Method 1 also sought to demonstrate the ability of the OpenLV platform in instructing the 
operation of physical devices through a network meshing trial. The network meshing trial 
sought to allow two substations to run in parallel for a period of network requirement.

To implement network meshing, it should be noted that the OpenLV trial installed intelligent LV devices at the 11kV/LV substations as a means to form Normally Open Points (NOPs) that could be automated. This was an atypical approach as NOPs are typically found 
midway between substation feeder cables in link boxes on public highways, rather than on the busbars at one of the substations in a pair.
The Method 1 network meshing trial demonstrated that it is practical to automate low 
voltage switching devices through the use of the OpenLV distributed intelligence platform.
The sequence of calculation and switching detailed in SDRC 4 was found to operate as 
expected, based on the control logic programmed into the system. The trigger thresholds 
were adjusted through the period of active trials to allow for changing ambient temperatures 
and network loading, whilst ensuring the system would continue to operate.
The network meshing trial also provided evidence that joining together LV substations as 
demonstrated in the trial was unlikely to lead to significant capacity uplift between transformers. This is due to the load being transferred using the trial approach equating to 
approximately half the load of one feeder. This is not sufficient to make a material change to 
the proportional load experienced by a transformer; but it has already been acknowledged 
that this was an artificial trial approach.
This trial also provided analytical evidence that points to a greater benefit of being able to 
control NOPs located within link boxes, rather than having automated NOP on the LV bus 
bars. By investigating the effect of meshing at the feeder link box level, it was shown that 
there would be viable cases where meshing helped the feeder pairs share load much more 
effectively, but this approach was unlikely to help create transformer uplift or materially 
reduce losses. This is due to the load on either side of NOPs in the monitored networks being 
closely matched – as such there is little realisable benefit from meshing networks in this 
manner.
It should also be stressed, because of the maturity of automated link boxes at the time of 
project initiation, that this trial did not demonstrate the effect of transferring customers 
between substations by using a combination of automated link boxes and equivalent devices 
to the ALVIN Reclose® units in one of the feeding substations. 
Moving NOPs from the middle of feeders between to substations to on the busbars at 
substation in a pair will always be effective in reallocating 50%-100% of a feeder’s load 
between substations. Having a capability to move NOPs in this manner will also create 
additional use cases not considered in this trial, an example being the capability to automate 
LV customer restoration after unplanned outages.

Dynamic equipment ratings

DNOs allow a cyclic rating to be applied to their distribution transformers for limited 
emergency conditions, during a period of additional back fed load for example, but only for a 
time-limited period. These are based upon fixed and worst-case assumptions and typically 
only allow a fixed uplift beyond the continuous nameplate rating.
Method 1 clearly demonstrated that having the ability to be able to apply real-time thermal 
ratings, based on site-specific measurements of ambient temperature and loading could 
create a dynamic rating beyond the transformer’s nameplate rating. This process was 
continuous and undertaken locally, operating whilst power was available to energise the 
OpenLV equipment. If deployed in a BAU scenario, the rating uplift would be available, in 
effect on an ad-infinitum basis, rather than under emergency conditions.
For such dynamic ratings to be taken advantage of there would need to be the ability to plan 
the network to remain within the expected dynamic ratings. Because the OpenLV trial 
gathered site-specific ambient temperature, hot spot forecast and loading cycles, this 
requirement would be satisfied.
This capacity uplift would be leveraged further when and if distributed intelligence devices 
are able to instruct smart devices to respond to periods where the transformer was forecast 
to exceed temperatures without additional intervention.

Such smart devices might include customer flexibility that was demonstrated through some 
of the Method 3 trials or alternatively some form of network reconfiguration such as changing the network open points. 
It is acknowledged that the network meshing trial was inconclusive. Smart link boxes were 
not technologically available at the time of the project initiation but progress in this field is 
ongoing.) A next development step may be to prove the concept of LV network load transfers 
using smart link boxes. If smart link boxes can be proved effective, it provides another means 
to create capacity uplift for the network. 
Network meshing and Dynamic Thermal Ratings

To implement Dynamic Thermal Ratings and network meshing, the trial implemented three 
different applications running of the OpenLV platform within the substations. These 
applications were:
 A load forecasting application.
 A transformer Dynamic Thermal Ratings application.
 The Loadsense application. This application reviewed data from the load forecasting 
application and the Dynamic Thermal Rating application. When the forecast load 
exceeded the forecast thermal rating, it would instruct the network to mesh.
Over the course of the active trials, across the five active pairs, network meshing was enacted 
on 792 occasions. Each instance resulting in the automatic activation of network meshing 
when determined to be beneficial to the network, and subsequently reactivation once the 
network conditions allowed. On average, each ‘active network pair’ operated 160 times over 
the 12-month period of active trials.
2.1.2 Establishing the level of capacity uplift that can be achieved in WPD’s 
licence area and across GB
Method 1 has provided evidence in SDRC 4 regarding the amount of capacity uplift that could 
be experienced across WPD’s licence areas and across the UK.
This analysis makes a conservative assumption that if dynamic transformer ratings were only 
applied to transformers of a size 300kVA or greater (which is less than 27% of WPD’s total 
population of LV transformers) then 6,350 MVA of total additional capacity would be created 
across 39,500 WPD substations. Extrapolation of this analysis across the total LV substation 
demographic of Great Britain would see a total uplift of 120,850 MVA in transformer 
headroom.
It should be remembered that Open data platforms have multiple roles and capabilities and 
as such, there are many other approaches to increase network capacity that can be enabled 
by a Distributed Intelligence Platform that were not demonstrated within the OpenLV trials. 

The same platform can provide functionality for multiple actors, such as the network 
operators, businesses, academics, and community organisations, this is detailed below.
For example, if a community wished to have an OpenLV platform monitor their community, 
then the incremental cost to deploy Dynamic Thermal Ratings would be minimal as it would 
simply require the analysis package to be loaded onto the platform. Conversely, in cases 
where an OpenLV data platform has been loaded into a substation to enable Dynamic 
Thermal Ratings, then additional applications can be loaded on to create even more value. 
Examples of these additional use cases may be pre-fault detection of LV faults or apps to track the amount of low carbon technology that has been installed in a LV network. For these 
reasons, it would be misleading to decide that installation of the OpenLV platform should be 
justified on solely based on the value created by Dynamic Thermal Ratings. 
2.2 Method 2 – Community Engagement
The potential for widespread or targeted deployment of distributed intelligence benefits to 
benefit communities was tested in the Method 2 – Community Engagement trials.
The OpenLV project found that communities, whether through established community 
energy groups, housing associations or local community organisations, could leverage value 
at a local level from the information provided by the OpenLV platform.
This was emphasised towards the end of the project trials when participating community 
organisations requested continued access to the data for their community, requiring an 
enduring solution to be installed in place of the trial equipment being removed. 

2.3 Method 3 – Business and Academia
2.3.1 Did OpenLV demonstrate new ways to engage with business?
Even though commercial organisations were required to fund their own involvement in the 
OpenLV trial, the available spaces for participation were oversubscribed.
The capability for the trial participants to access LV network data created new ways for DNOs and businesses to engage. The exact details of what the trial demonstrated can be found in SDRC 4. 
There is a clear demonstration of the following use 
cases:
 A basis for customer decision making. We observed a number of organisations being 
able to optimise control system settings and network capacity utilised on the basis of the load flow data that became available to them as a result of OpenLV. This is a new 
proposition since DNOs have not traditionally been equipped to stream data to other 
parties.
 Basis for supply chain innovation. We observed some of the trial participants using project data to assess new value propositions or to refine existing products. In some cases, we also observed that the data enabled these parties to conduct testing on these product refinements. Without the development of this data, it would have been harder to obtain meaningful depictions of network behaviour.
 New network management products. We observed several organisations creating platforms that enabled end-users or their equipment to respond to network loading information that is geographically specific in near real-time. Whilst it is acknowledged that the participants that demonstrated this did so on a limited basis, extrapolation of this capability would be a significant departure from the traditional business model that assumes customers are passive.
 New forms of information visualisation. By making the LV network data available, other parties were able to disseminate this information to their stakeholders alongside other key indicators. One good example of this included electricity network data being presented alongside other information from across other energy vectors which gives the end-user an insight that cannot be obtained from data used in business as usual to date.

Lessons Learnt

Many lessons were learnt over the course of the OpenLV project. These lessons are collected 
in this section of the close-down report, and the lessons learnt will be carried into future 
innovation projects where relevant. To help the reader find lessons relevant to future 
innovation projects, the lessons are grouped into categories, namely: hardware, software, 
network, communities, businesses and academia, and other (project communication, 
security, safety). 

7.1 Hardware

It is better to over specify core components of the system for a solution such as OpenLV, for 
example the ruggedised PC, thereby ensuring adequate processing power and storage for 
project trials. 
The hardware must fully support all software to be implemented in the project. Specifying 
specific hardware components can be a useful means to minimise technical risks when 
implementing software. 
It can be useful to over specify sensors used in trials, to ensure the sensors are fit for purpose 
for potential future applications which might require higher specified sensors than the 
applications at time of deployment require. 
The physical design of the system should consider the variety of physical spaces and 
conditions that the system might be installed in. Different mounting systems allow for 
hardware to be deployed in several different ways depending on which mounting system is 
most appropriate on a site-by-site basis. 
Well tested, off the shelf hardware reduces technical risk. For example, the LV monitoring 
hardware used in the project had already been used by WPD in Business as Usual (BaU) 
scenarios, as had the ALVIN® Reclose™ devices. 
When equipment is installed on the LV network, all possible situations the systems may 
instigate should be considered, together with the actions required to manage or mitigate 
them. Training and documentation should be provided where actions are required outside of 
normal operating practices. There should also be reminders on-site. 
A dedicated test rig was extremely useful in the development of the OpenLV platforms. The 
test rig should include all required sensors and be tested as early as possible to ensure 
components can be tested for as large a time as possible before installation. A dedicated test  rig allowed specific inputs into the system such that system outputs may be verified, in a way that would be technically extremely difficult to achieve in a live deployment. It is clear in this project, that a dedicated testing facility was a highly valuable asset and should be strongly considered for future network innovation projects. 
Overall solution system requirements must be formally defined such that the FAT and SAT 
documents cover testing all Project requirements.

7.1.1 Telecommunications

In project requiring adequate 3G/4G signal strength is required at deployment sites to ensure 
reliable communications, outdoor antenna should be utilised if doubts exist over the signal 
strength. 
Communication monitoring should be performed with alarms set to report any issues. This 
allowed hardware issues, commonly with routers, to be detected and rectified. 

7.2 Software

Software requirements should be captured using well tested approaches. The MoSCoW 
approach was the chosen approach for OpenLV. 
Single end-user requirements may be delivered by more than one Application. The technical 
requirements for these Applications must be cross-referenced to ensure compatibility. 
The OpenLV solution focussed on building core functionality first, before adding additional 
functionality later. This method proved effective as it allowed both earlier delivery of the core 
functionality, and earlier testing, thus minimising technical risk to deployment.
The LV-CAP® operating system was based upon a Docker system architecture. This was 
effective in allowing Apps (software) from multiple vendors to be packaged into separate 
“containers”, designed to run on a shared operating system. The environment was designed 
to allow a variety of programming languages to be used to create Apps, allowing fast 
development of the overall platform. 
Restrictions on technical specifications such as memory usage, processor usage and storage 
space must be clearly communicated to developers as early as possible. Applications storage size was limited by reliability and cost of deployment to all required sites over the mobile 
data network. It is clear from this that communicating technical specifications and limitations 
in any network innovation trial involving software development should be done in detail and 
at the earliest possible opportunity. 

7.2.1 Platform Management

EA Technology performed the role of administrating the OpenLV platform for this trial. This 
role included ensuring compliance of Method 3 apps against OpenLV protocols, in addition 
to issuing security certificates to apps once they have passed the process. Certification here 
refers to compliance of an app with the OpenLV protocol. 
The project revealed that where relationships were strong between app developers and the 
certification team, the certification process went smoothly because small problems were 
found early and corrected. However, weaker relationships harbouring difference in 
interpretation of the API rules, slowed down the certification process.

The skeleton app offered to software developers was successful in so far as developers who 
made good use of the app progressed quickly towards development. Those who did not use 
the app made progress towards certification more slowly. A common reason for developers 
not making use of the skeleton app was an unfamiliarity with the programming language that 
it was written in. Releasing skeleton apps in a wider variety of languages will help to overcome this problem. 
It was concluded that greater familiarity with the API rules would have decreased the number 
of failed certification attempts significantly. Developers attempting to use shortcuts in 
automation led to serious failed certification attempts due to significant changes to the 
source code being required before certification could be granted. In BaU context, these issues 
would be overcome by encouraging greater familiarity with the API rules and creating a 
culture of constructive feedback in the certification process.

7.2.2 App Development

EA Technology clarified the only requirement was a fully built app and a series of test inputs 
to confirm its correct application. These tests were only to check correct integration of the 
application into LV-CAP®, rather than to tests outputs from the application were correct or 
to demonstrate the app met customer requirements. Access to the source code was not 
required, avoiding conflicts of interest with potential app developers. Thirdly, the LV-CAP® 
platform’s timestamping of data and data validity flags reduced the need for data cleansing 
and thus time required significantly. OrxaGrid observed that the architecture of the OpenLV 
platform enabled them to focus on app development, as valuable time was not taken up for 
hardware installation of data network configuration and management. Valuable 
opportunities for commercial development were identified as a result of new data sources 
being available from the OpenLV platform, as well as greater potential deployment of existing 
analytics packages. 
Although LV-CAP® allows the use of a wide range of programming languages, it still imposes 
restrictions on the memory usage, processor usage and storage space available to 
applications. These restrictions must be clearly communicated to developers at an early 
stage. The main limit on the storage size of applications is the reliability and cost of deploying them to all required sites over mobile data networks.
The LV-CAP® environment enables developers to write apps in any programming language. 
This has enabled the overall platform to be built up quickly and easily utilising apps developed  by multiple vendors using various programming languages (C++, Java and Go) and approaches to developing those apps.
Many applications were created to operate as standalone software containers, whereas 
others required communication from other, paired containers to operate. There were also 
multiple applications developed using IBM’s Node-Red development tool.

7.3 Network

The OpenLV trial demonstrated that decentralised analysis and control was able to present a 
robust Method of automation for the Low Voltage network. Evidence for this came from low 
voltage networks being reconfigured at times of simulated network stress. This was enabled 
by OpenLV.
A Smart LV network device, located at one of a pair of substations, allowed the substations 
to be meshed, enabling the substation to share load. This was an unusual approach, as in BaU LV networks are sectionalised by link boxes located between two substations. In the 
arrangement utilised in this trial, temporary meshing of two transformers was shown not to 
be an ineffective method of de-loading substation transformers. However, if cost effective 
smart link boxes had been available at the onset of the trial, there was potential for significant 
network uplift. 
Method 1 investigated forecasting transformer capacity headroom available at LV 
transformer, based on real-time measurements of transformer temperature and load 
duration. This was successfully achieved, and the benefit estimated at a 6,350MVA capacity 
uplift across 39,500 of WPD’s 140,000 substations. While it would have been possible to carry 
out these calculations centrally, this would have relied upon reliable communications  between the central location and the substations, which would be a costly operation, prone 
to potentially harmful communication faults. This showed one of the high value propositions 
enable be decentralised computing, further demonstrated by the results of these calculations 
being shared with other apps serving the interests of Method 3 trial participants. 
One of the main learning points from this stage of the project that seemingly separate 
decisions combined to restrict the number of suitable substation pairs for use in the project. 
A combination of decisions made during the initial project development stage together with 
on-site restrictions limited the number of suitable sites. Each requirement or decisions 
reduced the proportion of the network suitable for use in the trial. Despite these decisions 
being made for sensible reasons, they still resulted in unintended consequences. Site 
selections became a much more time-consuming process than expected for the eventual 
outcome. The project trial’s system utilising LV-CAP® and ALVIN® Reclose™ devices was more difficult to implement than deployments of different hardware mixtures in the future. 

7.4 Communities

As detailed in the section0 above, future projects should be cognisant of the level of technical 
expertise within community groups and organisations such as parish councils. 
During the project planning phase, it was assumed that a level of expertise would exist within 
communities to enable development of applications, or to make sensible use of the data 
available. In hindsight, it remained impractical for many communities, especially those 
without specific domain knowledge, to make practical use of the available data. This was 
despite the project planning on support for participating communities and designing the 
interfaces from the distributed intelligence platform to be as simple to use as possible.
It should be remembered by future projects seeking to work with and utilise the local 
expertise of community groups, that whilst they tend to be highly enthusiastic for anything 
that would benefit their community, the challenge of their limited technical knowledge must 
not be underestimated.
The OpenLV project has demonstrated that whilst community groups required assistance to 
develop workable use cases for the project data, above and beyond that envisaged at the 
start of the project, once data access was secured a wide range of effective projects were 
implemented.
Community groups require different engagement approaches. Utilising tailored imagery and 
communication styles ensured high levels of engagement by communities in the project. 
Direct engagement with the community groups via telephone or in person contact was crucial 
to ensuring continued engagement in the project. Having CSE and Regen, companies already 
trusted by community groups, as part of the project team proved invaluable in successful 
‘testing the market’ and recruitment stages for the OpenLV project. The length of the project 
should be carefully considered, since the timeframes need to be long enough for 
communities to see real benefits from their network.
The variety of App ideas from community groups was wider than expected. For example, 5 
app idea under the banner of “policy, planning and retrofit programmes”, a topic not covered 
in the suggested app ideas, were suggested. App ideas should be subject to clear assessment criteria to take into account any barriers, issues and risks (in this case set out in the Regen market potential assessment report). 
The project showed that there was a strong desire from community groups about accessing 
local network data to enable a greater understanding of the local electrical system, and 
particularly the effect their actions had on the local network. High demand led to there being 
more formal application to participate in the trail than the number of substation platforms 
available in the trial. It is clear for future innovation projects that community groups have a 
strong desire to understand the effect of their actions on their local electrical network. 
To ensure a wide variety of engagement in the project, targeted marketing is required.