Planned outage management has become ever more challenging due to the increased volatility and complexity created by the massive integration of renewable energy sources on the electricity network and the reinforcement of the system to facilitate the transfer of increased generation volumes. This has generated additional manual work for outage planners, which, without process change, could become unmanageable. The Project aims to explore the use of decision support algorithms to improve the efficiency and effectiveness of planned outage management processes.
Benefits
There are several potential benefits with the successful development of this optimising outage planning prototype tool listed below.
• Improve the overall efficiency of the outage planning process, improve response times, and free up the team to add value to the outage planning function, such as improved engagement with key stakeholders.
• Future proofing – increased outage planning challenge to come as more renewables and reinforcement works are required with growing the network (increased complexity).
• Improved coordination with stakeholders by developing a more flexible approach to planned outages, achieved by creating a user-friendly software platform to enhance collaboration across multiple teams.
Cost Benefit Analysis (CBA)
The primary measurable benefit of this project is a potential reduction in response time of outage planners in processing change requests. For the current situation, it takes 5 hours for an outage planner to address a change request for the year-ahead plan and 4 hours for a current year request. With the algorithm in place, the processing time for a single change request will be reduced by 50%, leading to less working hours for outage planners assigned to change requests. There are some assumptions have been made to quantify the potential
benefits if the algorithm is applied across our network.
Assumptions
• The project cost is a one-off cost and is included in this analysis as the development cost.
• If this pilot project is successful, the next stage of this project will be integration with our network. The cost of the integration stage is assumed to be 25% of the project cost and was factored in this analysis as part of the development cost. The integration cost will be revised once the project is completed, and next steps are defined.
• The number of change requests for the year-ahead plan is 905, and for the current year plan is 2720. This is assumed based on advice from subject matter experts (SME), historical data and NGESO published data. The number of change requests remain the same for both the base case and innovation case.
• By using the algorithm, it can help save 50% of the time to process a change request, regardless of whether it is within a year or for the year-ahead.
• The annual subscription cost is £50,000 as advised by the supplier.
• The capitalisation rate is 0% as this project does not involve any CAPEX.
• The value in CBA is demonstrated in 2018 real price as per Ofgem’s requirement.
Results
• The estimated scaled benefit until the end of T3 is £1m and it can reach £6.2m over the lifetime of assets.
• There are some risks identified in this project, therefore we have applied the risk factor of 20% to the potential benefits. The risk adjusted lifetime benefit is £4.9m and it is estimated at £850k at the end of T3. In this case, benefit-cost ratio (BCR) up to the end of T3 is 3.2. This means that for £1 spending, it will return £3.2 by the end of T3. The lifetime BCR is 13.9 which means that for £1 spending, it can return £13.9 over the lifetime of 45 years. Annualise ROI is
18%.
• The benefit starts from the first year of implementation, which is 2026.
• To consider this project viable, the minimum efficiency level of the algorithm should be 8.5%. This means that the algorithm must reduce 8.5% of the response time to a change request to justify the initial development cost and the on-going subscription cost.
Key Risks
• Time and resources required to keep it up to date as the network changes and grows. This project is limited to the current network and will involve a comparison with existing year-ahead plans for 2022 or 2023 to allow for validation that the tool leads to optimised planning. Any future phases of this project will need to consider how changes to the network will be captured and maintained without significant time or resource investment.
• Repeated use of the tool with each request could cause multiple changes to a given outage. If that outage affects third parties and they are notified each time, it could become detrimental to our relationship with that customer. To mitigate the risk there could be a limit on the frequency of runs or putting a cap on the number of times a given outage can be repeatedly changed.
Learnings
Outcomes
The Year Ahead Outage Optimiser developed during this project ultimately outlined the success of the objectives, the codifying of part of an Outage Planners activity.
Ultimately, more development is required to bring the TRL from the level 5 (Proof of Concept) in which it has been developed to date, up to 8 / 9 for further rollout to SSEN-T or other network licensees. The platform delivers tangible benefits in outage planning, however it is not a single solution to all issues faced within the process. From the work completed in YAhOO there has been identified a need for a follow on project to further develop the TRL up to a level that is suitable for business as usual deployment. This has been expanded on further in section 10.
Lessons Learnt
The fundamental concept remained consistent throughout the project – to code a Power System Engineer's network knowledge and use this to automate identification of planned outage placement options, to realise process efficiencies. N-Side’s experience in delivering solutions across the global energy industry provided a valuable knowledge base on which to build a paradigm of electricity transmission network outage planning and change management. This is a niche function and therefore required some explanation by subject matter experts. To support this explanation, SSEN-T shared KPIs, network diagrams, maintenance schedules, industry governance documents and historic outage plans.
N-Side exhibited understanding of the problem statement by expanding the solution functionality to include plan validation and optimisation features, in addition to the single outage request placement feature. An in-person meeting at the beginning of the process was particularly valuable to agree on accurate translation of the rule set into mathematical objective functions. N-Side then coded the mathematical description of the objective functions. Simultaneously, N-Side developed a draft Graphic User Interface (GUI) layout, later presented as a mock up at the regular online cadence meetings. This mock up provided a useful opportunity to feedback and refine the GUI before N-Side created the GUI functions e.g. filtering, Gantt chart views, core function buttons, layout etc. Linking the GUI to the back-end algorithm was one of the last steps in the process, to minimise rework for the developer. As we explored user stories together, it would have been beneficial to emphasise the requirement for reporting functions, but this was an opportunity missed. Reporting functions would have supported better UAT testing and therefore feedback, by allowing the output to be interrogated via alternative methods besides the GUI Gantt displays.
Throughout the development of the core algorithm, SSEN-T SMEs created and refined the network rules (or constraints) in the form of an exhaustive list of unacceptable asset outage combinations. This was a feasible approach given the relative simplicity of the SSEN-T network. However, scaling the tool for a larger asset base will require some automation of this rule-creation process to accommodate other GB networks, and indeed SSEN-T's future network, to avoid unnecessary SME manual burden at set up and maintenance of the rule set. The rule set was regularly discussed and refined in terms of categorising rule sub-sets into must-have, should-have, and hold (for a later version).
Ultimately the outage optimiser was a successful proof of concept which demonstrated the core capability of simulating network knowledge and asset availability requirements to inform automated outage placement. The project also delivered the functions derived from that capability which were defined as plan validation, plan optimisation, and single request analysis.
