ArcFM Proposed Equipment (Part 1)
Managing proposed equipment in your ArcGIS/ArcFM implementation seems on the surface to be a pretty straightforward proposition. Equipment that’s “proposed” is just in a different state in its life cycle than “existing” equipment, right? But as we dig in to the topic it gets pretty complicated pretty quickly.
However, just because it can get complicated doesn’t mean it’s not a requirement.
In the early days of ArcGIS/ArcFM we may have been able to get away with a versioning workflow where proposed equipment lived only in versions underneath DEFAULT and as equipment was energized/as-built it would get posted to DEFAULT. Meaning that:
1. A user connected only to DEFAULT would never see proposed equipment, and
2. To see all proposed equipment – or even all equipment at a given life cycle state such as “Design Complete” – a user would need to have *many* versions present in our map document. Impractical to say the least.
An maybe back then there was not always the business driver for another approach. But today there clearly are business drivers. Plenty of them. Here are just a couple.
Safe Construction Practices In both electric and gas – though particularly so in gas – it’s vital to err on the side of safety. Meaning that its much preferable to display equipment proposed but not yet built than run the risk of not showing equipment already built. Due to the inevitable time lag between “construction complete” and “map updates” – even if it’s a week or even if it’s a day – proposed equipment must be visible to at least some category of user, and thus in DEFAULT.
Operations Awareness On the electric side there is a present and growing need to make proposed equipment available to applications like an Advanced Distribution Management System (ADMS) – such as Schneider Electric’s DMS product. In what’s a highly desirable scenario to some electric utilities, the ADMS operator should be able to see the proposed equipment, recognize that it’s not yet energized, and in communication with field crews close in the protective device to complete the energization. Of course realizing that the source of all distribution system equipment – existing and proposed – is the GIS and is refreshed daily.
In this post we don’t claim to offer an ultimate solution. In fact, the “ultimate” solution may be different for different companies. What we do hope to do is walk through a number of considerations that come into play when you’re choosing an approach. We also take into account the fact that you may already have a production Geodatabase that does not account for proposed equipment, but you want it to.
With that, here are some considerations.
Does proposed equipment need to be included in the geometric network?
It may be the case your users simply need to see proposed feature locations, but not have network operations – like traces – operate against the proposed features. Installs can be symbolized like existing except with a distinct color. Removes can be symbolized with an “x” or cross-hatch. Construction notes can be included if deemed useful to the general user. 
A case in point might be if your primary driver is to provide features for a one-call locating service. These applications typically just check for the presence of underground equipment within the proximity of a given address or intersection.
If your proposed features don’t need to be in the network, then it may be your design features are also not in the network… and you may be using a product like SE’s Designer Express. In which case you’ve got clear sailing. All you have to do is decide which point in the construction life cycle you want proposed equipment posted to DEFAULT. Visible to all, just like your designers.
If you’re not using Designer express then you might implement a process that copies design features into simple, non-network feature classes that can then be posted to DEFAULT without interference with existing network features.
When does the proposed equipment need to be in DEFAULT?
See the topic below on “as-built update” changes.
How often are there “as-built update” changes – and how significant are they?
A construction design has a life cycle. At its beginning the chance that it reflects what will ultimately be built are slim to none. Along its course the design will be extended, shrunk, changed or possibly canceled. However, if not canceled, at some point it will clearly reflect what the customer, design technician and supervisor all envision to be built, then it will be approved by all who need to approve it and released for construction.
And here lies the question… and a potential opportunity.
You can, and some companies do post the design to DEFAULT simultaneously with releasing the work packet to the construction crew. If you’re using a construction design solution like Schneider Electric’s Designer this may simply mean performing an “ArcMap” post – which moves design features into DEFAULT while still with a work flow status of “In Construction”. If your as-built edits that affect GIS features are rare – or if they are typically not significant – then this course may be for you.
For that matter, you could consider this approach even if you’re doing construction design outside of GIS altogether.
What types of proposed equipment to you need in DEFAULT?
Does your business driver require that *all* types of features in your construction design be present in DEFAULT, or is it only really important for certain types of equipment? For example, you may categorize work into types such as Level 1 and Level 2 with types distinguished based on their impact to the network. A “Level 1” design might add a new switch along a backbone three phase span.
If your business driver calls for DEFAULT to contain an up-to-date representation of the geometric network for major pieces of equipment then you could consider a process that pre-posts equipment from “Level 1” designs but not others. It may be the case that the process involves, first, a manual update of DEFAULT for the Level 1 design equipment and, second, a manual process to back out these updates when the Level 1 design is ready for full as-built updating. But it’s also likely that there are not so many “Level 1” designs to be accounted for.
Validation and Attribution
You may have a process that performs quality assurance prior to posting a design to DEFAULT – and prevents positing if QA fails. The question here is, do you need to apply the same level of validation to proposed features as you do to “existing” ones.
This can certainly vary. You might initially be inclined to answer with a quick “no”. For example, there may be a requirement for a unique, non-null company number on all “existing” devices that would simply not be known for proposed equipment. But, on the other hand if you’re going to provide proposed equipment to your DMS where it will be energized by an operator, then you’ll want to be sure that the equipment carries valid electrical properties.
How will your proposed equipment be “commissioned”?
If you’ve got a process by which proposed equipment will find its way into DEFAULT in a way that meets your business needs, then you need to consider what will happen to that proposed equipment will transitioned to “existing” when the construction is actually complete and the design is as-built.
Summary
While it might not be an NYT Best Seller, a book could be written on this topic. Or at least a chapter. And neither of these were our goals with this post. What we wanted to get across here is that there is more than one way to get proposed equipment into DEFAULT. In a subsequent post we’ll delve more deeply into some of the details of how some of these options can work.
