New OSS product – Restoration Manager

At Passionate About OSS, we’re lucky enough to count the utilities market as an important part of our client base. This probably puts us in a very small percentage of OSS exponents that work across OSS for telco and utilities.

Utilities have a number of interesting and unique nuances compared with other OSS markets. Starting at the top, the network is core business for a telco, whereas the comms network only supports the core business of other utilities.

Despite having vastly different functions, there are still many similarities between operational support tools at telcos and other utilities. Similarities include:

  • Network inventory is made up of nodes and arcs (nodes are routers vs pumps vs sub-stations; arcs are comms cables vs power cables vs pipes)
  • All are CAPEX-heavy industries, so asset management is important from a financial (ie depreciation and “useful life remaining” modelling) as well as physical perspective
  • Assets need to be systematically life-cycle managed (ie commissioned, repaired, replaced, modified, maintained, decommissioned, etc)
  • A field workforce needs to be coordinated to keep the network in a healthy operational state
  • The network either provides (or supports) essential services so rapid remediation of failed / degraded services is expected by customers

Anyway, enough of the preamble. I find it interesting to observe the tools used by the different utilities to prompt alternate ways of thinking about our OSS.

Last week I observed a tool called a Restoration Manager. It is used widely in the power industry to handle fault restoration on comms networks. It has little direct equivalent in comms network management.

Some ticket managers allow task templates to be developed and defined. Similarly, the Restoration Manager also retains restoration plans, which are sequences of responses, but it also goes further by:

  • Coordinating implementation of restoration plans in real-time 
  • Looking ahead of each step in the  restoration plan to determine whether it is still useful or potentially harmful
  • Providing an indicator of whether the current network state is suited to being handled by each of the stored restoration plan/s
  • Coordinating restoration of planned or unplanned outages and even degradation events
  • Facilitates use AI or past restorations to create an optimal restoration plan
  • Documenting a proposed plan of action/s that can be audited by internal groups (eg engineering, QC, etc) or external groups (eg regulators)

The restoration plans could be made to tie in with DRP (Disaster Recovery Plans), CRB (Change Request Boards), outage window sequencing/management and even security incident response.

What are your thoughts? Would a Restoration Manager be useful for our OSS stack (ie solves an existing, unsolved problem) or do we already have suitable ways of solving / avoiding the outage problem?

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions


Most Recent Articles

One Response

  1. I suppose the big difference between utilities (pipes, valves etc) and comms (fibre, switches and routers) is that the telco industry is heavily invested in resilient protocols. There’s a greater focus on building a comms network that will be able to leverage those protocols to respond effectively to a range of unexpected outages.

    How effective this approach is, is probably up for debate, but I’d imagine a well invested and designed comms network’s response to an outage should be at least as good as a Restoration Manager response.

    Or maybe I’m underestimating modern utility networks! Is there any equivalence of a protocol in utilities? Or is all the intelligence in it’s OSS layer?

    All that said, there’s still a set of faults in networks that protocols cannot handle effectively (otherwise we’d never see a network outage IRL!), and I really like the idea of dedicated processes that don’t just manage the necessary network change but also look ahead at the same time to predict the outcome and determine whether it’s still the correct course of action. For any network fault that takes more than a few minutes to resolve, that approach adds a lot of value.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.