You are here

Pre-Posting and Partial Energization at CoServ

A little over a year ago, CoServ engaged SSP in helping them migrate their legacy GIS/WMS integration into an Enterprise wide integration with Maximo. Aware of the opportunity to revise and improve their workflows and GIS usability — including with options such as pre-posting and partial energization — CoServ requested that SSP also helped them implement (besides the integration migration) three business requirements that they had identified a while back:

  1. Early GIS data availability at the Enterprise level.
  2. Up-to-date monitoring of network energization status.
  3. Improvements to the GDB operations.

All along, CoServ has had a very clear idea of the motivation for these requirements, and what was expected of them. CoServ's GIS group had even come up with very sound proposals for their implementation. The integration effort was chosen as the right time to get it done. In this post, let me explain the essence of these requirements, and describe the implementation strategy.

First Requirement: Early GIS Data Availability

CoServ has been using, and continues to use with success, ArcGIS as their Enterprise GIS. To maintain the GeoDatabase up-to-date they use ArcFM(TM) Designer Workflow Manager, as the staking system, and ArcFM(TM) Session Manager, as the tool for further edits to the assets in their distribution network. Both applications rely on ArcGIS SDE versions, where edits are applied. Once the changes introduced in a version are ready, the version is reconciled and posted so that updates are finally available for all Enterprise users in DEFAULT.

The time a version may be "lingering" in the system until its changes are posted to DEFAULT varies depending on the nature of the edits. Generally, CoServ uses Session Manager(TM) for "quick edits"; and the proposed changes in the (session) versions are available in DEFAULT very often within the working day. On the other hand, Designer Workflow Manager(TM) is used when monitoring the progress of a construction job from the design stages, through approvals, warehouse material release, actual construction updates, and final as-built edits. By the nature of these business processes, the updates introduced in these (design) versions may take quite a while to make it to DEFAULT; often months, some times years.

Even though it is common practice in the utility industry to wait untill as-builts are ready before completing GDB edits and posting to the Enterprise, CoServ has recognized the value of having design and construction data available early on to other Enterprise applications. For instance, it is valuable for CoServ to know that, although not energized yet, and perhaps not even under construction, there are some areas of the current network where assets are going to be installed, and eventually power will be consumed. This kind of early data availability allows for better forecasting and planning around the expansion of the network from several business aspects: budgeting, advertising, power delivery readiness, and more.

First Solution: Pre-Posting

The solution implemented by SSP consisted on creating an ArcFM(TM) Workflow Manager Subtask that executes an Esri Reconcile&Post on the design's SDE version, followed by removal of the version. The subtask was then inserted within CoServ's workflow, at the point when an Approved design transitions to Ready for Construction. The execution of the subtask serves two purposes:

  1. It makes the proposed and approved job details immediately available to the Enterprise; even before construction commences.
  2. It disposes of the design Esri version early on; drastically reducing the number of concurrent Esri versions managed by SDE.

When the construction is completed (no matter how much later), and as-built edits must be finally added to the GIS, the user re-opens the job. The inner workings of the OOTB Open Design subtask creates a new version in which to edit the updates. Usually, the as-built changes go through a quick editing and approvals process, and the final job is posted to DEFAULT with little delay.

Furthermore, CoServ's workflow was extended to allow for quick updates at any time during the construction period; allowing once more for early data availability at key stages of construction. This was done by creating a new task that runs the custom subtask at the discretion of the GIS team.

But you may be wondering... How then does CoServ Enterprise GIS differentiates between the currently energized network and these proposed, or under construction sections? The trick: Partial Energization; which we cover in the next section.

Second Requirement: Partial Energization

By using Pre-Posting, CoServ brings to DEFAULT changes to the network which are not energized until construction of each section completes... How do other Enterprise applications differentiate between the new additions and the pre-existing network? Without further constraints, the posted features would appear to be already part of the energized network; creating all kinds of problems. From reporting the wrong energized assets to an OMS, and the associated human risk to operate devices in that area, to misleading load calculations by an ADMS, or fooling a CIS user to believe that there are available services to new customers, and even skewing any capital investment forecasting. Aware of these problems, CoServ had already implemented a solution: Disconnected Features and Posting Workflow!

Second Solution: A Disconnected Features and Posting Status Tool

CoServ's solution to avoiding design features pre-posted to DEFAULT from being energized is simple and efficient:

  • On the one hand, features are added to the map disconnected from the network. For instance, if the design represents a new branch to electrify a future subdivision, all the features in the branch are placed in their correct location, and with proper connectivity. But the main primary reaching out to the energized network is drawn a bit short... effectively disconnected from the rest of the network.
  • On the other hand, CoServ has implemented a posting workflow that uses Pre-Posting as well as the Final Post, and makes use of a Posting Status attribute added to all network feature classes. With this status CoServ indicates whether a feature that appears pre-posted in DEFAULT represents an asset "In Construction", "Proposed", or "Energized". At Final Post all the new features have their posting status set to "Final As-Built". To facilitate the workflow, SSP developed for CoServ a Tool with which the Posting Status value can be updated at once for all participating features.

In summary, by making sure that design features are not connected to the existing network, and by updating their Posting Status as prescribed in their workflow, CoServ exposes network changes to DEFAULT so that all other applications using Enterprise GIS can benefit from early awareness of these changes. Furthermore, the value of the Posting Status, by means of the proper stored displays, drives the symbology that visually differentiates in DEFAULT those sections of the network that are being developed through construction jobs, and energization work orders.

Third Requirement (and Solution): Improved GDB Operations

It is a known fact that the more Esri versions cohexist under SDE management, the slower the GDB performance. The state tree grows, and the queries to delta tables run slower.

By deleting the Esri version after Pre-Posting, and as the Partial Energization workflow is executed, the state tree remains “healthy”, and the performance of the GDB is noticeably improved.

Putting It All Together: An Illustration By Example

The Pre-Posting and Partial Energization Workflows, as well as the use of the Posting Status can be illustrated as follows.

An engineer designs a section of electric circuit to provide power to a future subdivision. The design contains all the necessary assets, correctly distributed over the background map. The assets are also geometrically interconnected; except that the new circuit is not connected to the existing network.

The engineer sends the design for approvals, and finally the job is accepted for construction.


At this point:
1. The Posting Status is set to "In Construction".
2. The design undergoes Pre-Posting.
3. The design details are available to DEFAULT as being under construction.
4. The Esri version is deleted.

The figure below shows a portion of the design. Particularly, the area where the new features are drawn close to, but geometrically disconnected from the energized network. The Posting Status field is set to "In Construction".

EA CoServ - Partial Energization - In Construction - Partial Energization

At any time during construction, Engineering GIS personnel can re-open the design, and make corrections to the original layout. Then, Pre-Posting makes the corrections available in DEFAULT, and removes the Esri version. Corrections can be applied as many times as needed.

Partial Energization

Concurrently, Engineering GIS personnel may receive notification from the field crew that some sections of the job have been completed. The Engineering GIS uses ArcFM(TM) Session Manager and the Posting Status Tool to set all the features of the completed section to "Partial Post" (a.k.a. "Proposed"). Then, it runs Reconcile Session and Post Session. As a result, the proposed sections are available in DEFAULT; while the Esri version is deleted when (periodically) the ArcFM(TM) Clean Orphan Version tool is run. The proposed features appear in the map, because of the details of the stored displays, as of a different color than those already energized. The figure below shows the sample job after partial posting. The color differentiates energized from proposed features. Proposed features are close to, but not yet snapped to the energized network.

EA CoServ - Partial Energization - Partial Post  - Partial Energization

By means of a work order, an Enginnering GIS can use Session Manager(TM) to set the proposed section to "Partial As-Built" (a.k.a. "Energized"). After posting, the energized branch in DEFAULT is available for OMS and ADMS use, for instance. In the figure below the features have been energized, and the point of contact with the network snapped. It is the connection to the network what makes the design energized, alowing its features to be traced as part of the overall network. The section of electric circuit is now in service, and appears as such in the Enterprise GIS.

CoServ - Partial Energization - Partial As-Built - Partial Energization

The updates to "Proposed" and "Energized" using the Posting Status Tool can be applied per sections, and as many times as needed while complying with the workflow.

Finally, when as-built reports are submitted at the end of the job, Engineering GIS can re-open the design for final edits, and queue up the design for batch reconcile and post. When processed by the posting processor, the Posting Status is set to "Final As-Built", all the assets posted to DEFAULT, and the Esri version deleted.

The Posting Status Tool can also be used after some inspection effort, where crews go to the field to verify that the equipment, in "Final As-Built", is in fact located and arranged in-situ as shown in DEFAULT. The sections of network thus verified can have their Posting Status updated to "Field Verified".

Conclusion: Pre-Posting and Partial Energization

SSP has collaborated with CoServ to provide the capability to accomplish three requirements:

  1. Early data availability - Via Pre-Posting.
  2. Monitoring the evolution of a job - Using Posting Workflow and Posting Status Tool.
  3. Improving GDB operability - By deleting Esri versions when not needed.

Fulfilling these requirements, CoServ is now running its operations (not only GIS) with a better understanding of the present state and future layout of its distribution network.

Author Information

  • Joaquin Madrid

    Joaquin Madrid

    Joaquin Madrid comes to SSP from having worked in the GIS and Smart Grid fields for the last 12 years, and specializes in Electric Utilities systems integration. In this role, Joaquin manages the technical direction for SSP implementation’s team and provide leadership in the adaptation of new technologies for the long-term future growth of SSP Innovations.

    See all items created by this author >

    Connect with me on:

Add new comment