Issue link: http://read.dmtmag.com/i/55888
Asset Management Requires a Solid 'State' of Mind WHERE IT'S ABOUT TIME F BY ERIK SHEPARD or asset-intensive industries, such as energy, and asset-centric systems, such as GIS, state management is an important but often ignored topic. An asset goes through sev- eral stages in its lifecycle, starting with design and continuing through construc- tion, in servicing and finally retirement. Although the names may vary, and there may be additional states, these are core states that assets in most asset-intensive industries go through. In the design state, a layout is developed in which assets are specified. For example, an electric utility may install a new intelligent switch that can be remotely monitored and operated as well as a bypass around the switch to ensure that power continues to flow until the switch is placed in service. During construction, the asset may be placed exactly as specified in the design, but, in some cases, a change may be made to accommodate available materials (in the case of minor materials, but likely not for major components such as a switch), or a change may be made in the design to accommodate field conditions (e.g., if the pole on which the switch was to be placed already had equipment on it, the switch might be placed one pole upstream or downstream). The data associated with the actual assets installed are called as-builts and are collected in the construction phase. For major pieces of equipment such as new Erik Shepard is principal of Waterbridge Consulting; e-mail: erik@ waterbridge.biz. 30 switches, an outage will be required. Outages require that a utility ensure that customers receive alterna- tive power through the duration of the outage, and they also require careful coordination from a safety perspective. Thus, there will be a period of time between when a large piece of equipment is installed and when it's actually placed in service so the utility may plan for the outage. An asset will be retired at end of life, representing the retired state. In many cases, the utility may want to do planning around the retirement process, so identifying that the asset is a candidate for retire- ment requires tagging it in the retired state. GEO W ORLD / FEB R UA R Y 2O12 The Lifecycle What do asset lifecycle states have to do with temporal data management? Everything. For planning and histori- cal purposes, it's important to tag the particular state that an asset is in, or will be in, at a date of interest. Specifying that assets in a GIS are "in design" allows operators to filter out assets to see only what's now installed. It allows planners to see the state of the network as of a particular date. It also allows asset managers to calculate a value for the installed plant as of a certain date and a projected value as of a different date. It allows field crews to know how the current configuration of the network affects safety. Tracking state is a fairly straightforward task—state is essentially a form of discrete time, consisting of a series of distinct, non-overlapping attributes. Through tagging data with this state, the discrete state that the asset is in at any point in time can be identified. But is that sufficient for identifying state? As with anything else, it depends entirely on the application. If the only interest is to be able to filter assets that are in design, as-built, in service or retired, then this certainly is adequate. However, if the desire is to be able to view a state of the network as of a particular time, then additional information is required. What Does It Mean? Recall that bi-temporal data management specifies two data attributes: transaction time and valid time. The dates associated with states are a form of valid time. A minimal addition is a single dimension of valid time: when the asset was born and when it was retired. This gives a rudimentary way of seeing dates associated with states. But what does "born" mean in this context? Is it when the asset was designed? When it was built? Placed in service? What does "retirement" mean in this context? Is it when the asset was planned for retirement? Or when it was actually retired? To adequately capture the language of the state, several valid dates are required—essentially a range for each of the valid times. In this case, they would be an initial design date, a built date, an in-service date and finally a retirement date. This way, the ranges could be inferred. The asset is in "design" between the design date and the as-built date. The asset is "constructed," but not in service, between the as-built date and the in-service date. The asset is deployed between the "in-service" date and the "retirement" date. This repre- sents truly bi-temporal and multi-temporal databases. There are many ways to represent the state of an asset, but understanding what the database has to model is the starting point from which any design should start.