What’s so special about asset systems for network operators?

Publish date:

Although a digital network model is essential for the deployment of smart grids and the roll out of smart asset management practices, many network operating companies do not have a single network master model in place today. What is so special about asset systems that it prevents these organizations to adequately model them digitally and maintain them in a single master source?

The analysis of the aforementioned Electric Power Research Institute (EPRI) paper is very precise in identifying the business use cases around network model management. Although written by and for transmission system operator (TSO) people, this view applies to all network operators. The paper says, “the role of Network Model Management is to maintain a master repository of the network model data that is shared by different network model consumers.” The rationale is clear: “master data elements are created once but used many times.”

Although a digital network model is essential for the deployment of smart grids and the roll out of smart asset management practices, many network operating companies do not have a single network master model in place today. What is so special about asset systems that it prevents these organizations to adequately model them digitally and maintain them in a single master source?

First, we must understand that an asset system is composed of virtual objects. So, the de-composition of an asset system in its constituent parts should not go down to a physical equipment but reflect a modelled breakdown in functional sections that together deliver an asset system capacity. “Objects” have a different meaning for IT professionals than they have for engineering staff in a utility company. The latter mostly see an object as a tangible and physical piece of equipment that can be installed, maintained and replaced. An information model on the other hand should also represent functional sections of a network model that are not necessarily identifiable as single pieces of equipment. Such information objects are needed to record information related to the asset system level, instead of information attributes of a physical equipment.

Let’s look at a simple crossroad with traffic lights and other equipment needed to control flows through an urban road asset system. There are eight individual traffic light poles installed here; under the pavement there are counting loops installed to monitor traffic for certain directions. These devices are obviously connected with cables for electricity supply and communications. All these elements represent the physical equipment level included below.

The “urban road asset system” is organized as a network with nodes interconnected with linear road segments. The simple crossroad above is just one node in this whole system that creates value by its ability to enable fluent traffic flows, according to a set of rules imposed on the vehicles that travel through the node. There are several options to conceive a traffic node ranging from crossings with lights to complex roundabouts and depending on the option the traffic rules will be different.

The traffic flow logic is determined by design and the node’s design will integrate the flow rules that will be enforced at the crossing. Theoretically, each vehicle arriving at the crossing has four options (continue, U-turn, left, right) from all four directions so in total there are 16 possible trajectories. Disabling some of these options is a decision at a higher level (asset system level) since obviously traffic flows are not managed just for one node but for a combination of interconnected nodes in a network model.

Based on the (traffic) system design, detailed engineering will determine the physical equipment that is needed to operate the crossroad as designed. This detailed translation will incorporate other guidelines (local topography, visibility, local safety constraints, equipment dimensions, manufacturer or maintenance provisions, etc.) as well as technical configuration designs for the individual equipment.

It is not always clear whether a design decision belongs to the asset system design, or to the detailed engineering work. Placing two traffic lights on either side of the road for each direction can have a purely physical reason (one light is not visible from all angles) or a traffic management reason (important signage must always be redundant in case of failure of one light the other one works).

This – generally poorly understood and hardly implemented – distinction between the asset system lifecycle and the asset lifecycle is one of the main reasons why the asset systems are not well mastered in many cases. In fact, network operating companies usually have at least three models of their asset system:

  • A (often partial) network model of the as-built network responding to the need to have a full inventory of roads, pipes or cables without details of the network nodes. This model is generally documented in a GIS database. The purpose is to register the “as built” network only, in its normal operating state.
  • Network model variants used in network calculation tools or for analytical purposes. They are extracted from the first model, completed with missing (in-plant) features, and modified to simulate “what-if” situations to evaluate network investment or configuration alternatives. Network models here are in an ‘as imagined’ status, as many of the investigated alternatives will never be constructed. Sometimes, a variant is promoted to an “as designed” status when network extension projects move into the project lifecycle.
  • Operational models, reflecting – as much as possible – the actual status of the network in real time. These models, used in SCADA, EMS, OMS and ADMS systems differ from the first model in that they are complete to represent the real traffic, hydraulic or electric flows as closely as possible. They also represent the network in an “as operated” status, including parts that are temporarily switched off or isolated, valves and switches that are set different from their normal position, etc.

This observation brings us to the second reason why asset system models are not managed as an “end-to-end” lifecycle. In previous decades, the limitations of the paper medium forced operators to document the reality of their asset system in different pieces. Geographic maps or records represented the network outside stations, feeder maps, or P&IDs were used to describe specific hydraulic or electrical assemblies in a synthetic way, alphanumeric records kept details about individual installations or equipment. Significant progress has been made to digitize and consolidate these inventories, but mostly without revisiting the lifecycle of the information or optimizing the information management processes.

As a result, different variants of the network model continue to exist. They are managed in separate silos, and consistency is only partially achieved by computer-assisted replication routines helping people to copy information from one silo to another every time a modification in one silo is relevant to another one.

In a smart and digital future, it would be better to take a step back and implement master network model management from an asset system perspective. The key question to be asked is: how do modifications to the asset system (network model) travel through a network operator’s business, and who would be triggering a modification to the master model?

The answer is quite obvious since important modifications to a network will require hydraulic or electrical study work, leading to complex design files that will – after going through a long decision process – be realized as investment projects to extend, upgrade or enhance the network. So, the network planners and the investment project lifecycle are the natural masters of evolutions to the model. The (one or more) construction projects that are conducted to realize a network enhancement are only a consequence of the decisions that have been made at the system level. Detailed engineering will complete the preparations for construction and manage the logistics but will never fundamentally change the designed model.

In summary one can say: you design and operate asset systems and therefore you build and maintain assets. These are two different end-to-end lifecycles.

In a next contribution, we address the application portfolio aspect; what technologies and applications are most appropriate to support asset management and asset system management? As the title “What’s so spatial about asset systems?” suggests, spatial technology and GIS applications have a central role in the landscape.

This blog is part of a series of 6 under the theme “Asset Systems for the Smart Grid”:

  1. What is an asset system for a network company?
  2. Smart grid or silly tube maps?
  3. What’s so special about asset systems?
  4. What’s so spatial about asset systems?
  5. Wearables, whereabouts and roundabouts
  6. What happens on the asset system, stays on the asset system

I have more than 20 years experience in GIS (Geographical Information Systems) and asset management projects in utilities (water, electric, gas), telecom and the public sector (transportation, cadastral services). You can connect with me here.

Related Posts

GPS

Wearables, whereabouts, and roundabouts

Jan Van de Steen
Date icon December 16, 2020

Even if we expect smart grid deployment or IoT sensors to automatically deliver asset and...

Asset System

What happens on the asset system, stays on the asset system

Jan Van de Steen
Date icon December 16, 2020

Asset systems are characterized by virtual objects defined “by design” for an asset system...

Asset System

Smart grid or silly tube maps?

Jan Van de Steen
Date icon December 11, 2020

Everyone who uses a public transportation system such as the London Underground intuitively...