Texas Gas PODS Migration

1
Texas Gas PODS Migration
A Review of the Texas Gas PODS Migration One Year
Later
Michael Ray Texas Gas Transmission, LLC
PODS Users Group Presentation 2006
2
A Brief History

• How was Texas Gas storing pipeline data?
• Prior to late 1990s any GIS-type data was
  managed on paper based documents and drawings
• These primary method was managing the data on CAD
  and manual drawings alignment sheets and DOT
  sheets
• Alignment sheets represented typical pipeline
  attribute and facility data
• DOT sheets represent pipeline safety and
  compliance data, i.e. house counts, class, MAOP,
  hydrostatic test, etc..

3
Historical Alignment Sheet
Land Parcels
Aerial Photography
4
Historical Alignment Sheet
Pipeline Attributes and Facilities
Pipeline Deviations
Pipeline Key for Attributes and Coatings
5
Historical DOT Sheet
Alignment, Structures, House Counts
Class Location
Pipe Attributes, MAOP, Hydrostatic Test
6
A Brief History

• In the late 1990s, Texas Gas moved from a
  paper/CAD based system to a GIS solution.
• The first database was designed ..
• Data was collected off alignment and DOT sheets
  into an Access database
• Data was QCed and loaded into a Sybase database

7
A Brief History

• A common GIS effort was established by the
  Williams Companies
• All pipelines were instructed to develop a common
  database design
• This design was similar to the PODS model
• The Williams common model had a combined station
  point, event range table

8
A Brief History

• The common model attempted to accommodate the
  needs of 5 pipelines into a single database
• The model was a good first attempt at developing
  an enterprise GIS database for Williams, but
  loose business rules allowed for data to lose its
  integrity
• A set of web-based applications was developed to
  maintain the data

9
Brief History

• The overall GIS solution consisted of a web-based
  Facility Maintenance application and a common
  ArcView 3.3 project
• Alignment sheet and DOT sheet software was
  developed in Avenue
• A 3rd party application was selected to calculate
  Class and graphically maintain structure data

10
Brief History GIS Viewer

• ArcView 3.3 Project
• Slow, cumbersome
• Uses Avenue scripts, but is still connected to
  GIS database

11
Brief History Facility Maintenance

• Web-base maintenance apps
• Poorly designed systems
• Slow and not suited for maintaining data
• Easy to use when querying for data, but the
  requirements exceeded the capabilities of a web
  application

12
Brief History Other Maintenance Systems

• Web-based systems
• Poorly designed systems, each systems
  architecture varied from the others this made
  development and system maintenance difficult
• Each system was developed and maintained by a
  different IT group
• The systems used the same database, but users
  viewed each system as a separate database

13
Brief History Sheet Generators

• Alignment sheets built on ArcView 3.3 and Avenue
  scripts

14
A Brief History

• Other peripheral systems included a Risk and
  Corrosion. Both systems were 3rd party
  applications, with Texas Gas writing utilities to
  bridge data in and out of these systems.

15
The Decision to Move to PODS

• In spring of 2005, key stakeholders and IT began
  discussing the benefits of moving to an industry
  standard model
• In June 2005, the project to officially migrate
  from a proprietary model to the PODS model was
  kicked off

16
Reasons to Move to PODS

• The PODS model has a lot to offer
• Improved database design
• The model expands much easier than the
  proprietary Williams model
• Better rules to maintain integrity of data
• Experiences of other operators and vendors can be
  applied to the model, you can benefit from the
  experiences of others

17
Reasons to Move to PODS

• Current solution built on aging technology
• GIS viewer, sheet generators, and other ESRI
  tools were based on ArcView 3.x and Avenue
• Applications to maintain data were web-based,
  isolated from one another, and split across
  multiple departments with poor communication/notif
  ication on data changes
• Users viewed each system as a separate database,
  this created a lot of confusion
• Imagery and raster data existed on a network
  share, nothing was spatial

18
Reasons to Move to PODS

• 3rd party software integration
• Integrating 3rd party applications was a
  nightmare
• Because of a non-standard model, several
  utilities had to be built/maintained to handle
  bridging data in/out of these 3rd party systems
• Any changes to our model or 3rd party model
  required an effort to verify bridges worked
  properly
• Vendors that understand and support the PODS
  model should have software that integrates much
  easier into our overall GIS solution

19
The Objectives

• Complete PODS migration by end of 2005
• Implement a PODS model that is pure
• Replace GIS viewer and maintenance app
• Replace alignment and DOT sheets
• The new GIS solution should be more user-friendly
  with better analysis tools it should combine
  the viewer and maintenance applications into a
  single system
• Upgrade ESRI tools to 9.x
• Implement ArcSDE

20
The Migration Process

• We spoke with several vendors about our current
  solution and our end goals
• We selected a vendor with PODS experience, but
  more importantly, experience with PODS migrations
• A vendor visited our offices to learn more about
  our business rules and data

21
The Migration Process

• IT and TXG staff completed initial table/field
  mapping document for vendor
• Vendor reviewed and worked closely with TXG IT
  staff to understand proprietary model and map
  remaining tables/fields
• First run database delivered August 2005
• Final production database delivered October 2005

22
Migration Results - Successes

• Clean migration of attribute and facility data
• The migration of pipe attribute and facility data
  migrated without any problems
• Benefited from validating data as the migration
  proceeded
• We were able to remove parts of the database that
  were in the proprietary model (but were not in
  PODS) and were not important to Texas Gas
• Imagery and Boundaries loaded to SDE
• The load of all aerial photography, boundaries,
  and other miscellaneous raster sets loaded to SDE

23
Migration Results - Successes

• Upgraded to ArcGIS 9.0 and ArcSDE 9.0
• This was a simple and easy process
• New Facility Maintenance System
• A new FM system was implement
• More functionality, better interface
• Better design, easier to expand and maintain
• Integrated GIS viewing and maintenance
  capabilities

24
Migration Results - Successes

• Application runs through Citrix
• Some local installations
• Users can graphically view data and maintain data
  in same system
• Users no longer have to switch between systems to
  hunt for data

25
Migration Results - Successes
26
Migration Results - Successes
27
Migration Results - Successes

• Users can view all other data from any screen at
  any point on the pipeline

28
Migration Results - Successes

• Stand-alone FM application is still available

29
Migration Results - Successes

• Integrated reporting (via Crystal Reports)

30
Migration Results - Successes
31
Migration Results - Problems

• Bad centerline migration
• The centerline was not adequately QCed by both
  the vendor and Texas Gas personnel
• The initial centerline delivery was invalid for
  every route, the problem was fixed and a new
  centerline was built
• A new problem dealt with rebuilding our
  centerline from control point (coordinate) data
  that was not migrated correctly
• This problem has since been resolved, several QC
  efforts have verified the accuracy of the
  centerline

32
Advice on PODS Migrations

• Choose a vendor with both PODS knowledge and PODS
  migration experience
• Create a PODS migration team that understands
  your current data and also understands the
  reasons for migrating to PODS
• Stay true to the PODS model expanding the model
  is good, but avoid modifying the core
• Scrutinize your centerline data before and after
  your migration
• Negotiate reasonable deadlines if possible, avoid
  replacing everything at once and look into the
  option of running parallel systems
• If you a running a proprietary model, you need to
  migrate to PODS soon, if you are maintaining data
  on paper, you needed to migrate to PODS yesterday

33
Post Migration Benefits

• Opportunity to QC your data
• Allows for your users to determine what
  attributes are important can we simplify the
  model?
• Chance to expand the model in places you didnt
  have data before in the case of Texas Gas, the
  ILI module did not exist in our proprietary model
• Moving to SDE has improved performance of our
  system
• The burden of defining new modules is lifted, you
  can benefit (or suffer) from the experiences of
  other operators and vendors
• When implementing new software, vendors that are
  PODS-compliant will typically implement easier
  this was the case for our Risk software

34
Whats Next?

• Continue the process of integrating/assimilating
  other systems into the GIS world
• Land, Measurement, SCADA, etc
• Implement a smart forms system that will allow
  field personnel to electronically submit data
  that will ultimately feed into PODS
• System automation let the system perform
  redundant tasks as data changes, tasks like sheet
  generation could be triggered by user initiated
  events
• Continue developing better analysis tools
• Continue educating users on the data and how to
  effectively get the answers they are searching for