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?Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email