We held our quarterly OGC technical committee meeting on September 13, 2017 at the Southampton, UK event. The meeting was well attended (both physically in UK as well as online). Discussion was robust and many individuals contributed to the discussions on how best to advance this standards development initiative. The meeting agenda included the following:

1. Welcome and Introductions
2. Scope, Overview
3. Quick Review of Current Models
4. Status Update on PipelineML
5. Issues & Decisions
   1. Concepts for Harmonization with LandInfra
   2. Publication of Component Attribute Definition documents
6. Question and Answers
7. Next steps

We covered some scope overview as we had several new participants, including representatives from the Canadian government regulatory group. This included the following slide and discussion on the current scope including only midstream use cases as we need to keep the scope as narrow as possible in the early formative stages of this standards effort.

We also provided an overview of the current 2 use cases we are supporting at this point in the development initiative. This included the following slide.

We gave an overview of the package dependencies model and the current iteration of the conceptual model. Following a review of these models, we provided a status update on progress. This included the following slide.

Next, we discussed ongoing efforts to collaborate with other standards groups. This included discussion on the previous day’s meeting with the OGC Energy & Utility Domain Working Group. There, we participated in discussions with LandInfra, CityGML, and others. We discussed the possibility of eventually moving the PipelineML SWG under either the Energy & Utility DWG or possibly the LandInfra DWG.

I invited a representative of LandInfra to join us for this meeting and to help share concepts for harmonization between LandInfra and PipelineML. We discussed how our core is based on high degree of detail with component by component attribution. We could leverage levels of detail where our core components are defined at the most granular level of detail. Perhaps more aggregated levels of detail could be more easily harmonized with other standards like LandInfra. We also discussed have some use cases such as land division and ownership that are ideal candidates for InfraGML implementation.

 

Erik Stubkjær provided insights into ways pipeline components could be extended into an existing class in LandInfra. We had many participants share their thoughts in terms of areas of overlap and gaps. Multiple individuals indicated they would email detailed information in this regard. We will gather this feedback and back it accessible in the future. We decided that LandInfra SWG and PipelineML SWG would be sharing documents and continuing dialogue in the future to better understand each other’s needs and models. Erik also suggested that we develop a set of shared use cases pertaining to the pipeline industry. We agreed this is a worthwhile effort warranting our time and consideration.

We also discussed the need to publish our pipeline component attribution definition documents onto the public portal (this site) so that industry stakeholders can access this information and provide feedback. We have been vetting these documents within the SWG for over a year and have matured them. The guidelines surrounding an OGC SWG prevent us from publishing technical documents to the public least a vendor begin developing solutions on incomplete and unapproved documents. It was agreed by OGC staff that this will not be a problem so long as we include clear language in the documents that they are drafts and should not be used in the development of software solutions. After extended dialogue, we agreed that it is best to hold a vote at the next technical committee meetings to publish the completed drafts as soon as they are complete.

We concluded our meeting with a brief overview of next steps. This includes the following:

• Next steps
  • Complete UML models
  • Auto generate core schema and manually tweak, as needed
  • Develop Database Export Tool
  • Upcoming Interoperability Experiment

Our meeting in St. John’s, Newfoundland was held on June 28, 2017. Our agenda included the following:

1. Welcome and Introductions
2. Recommended Resources
3. Where Are We – Status of PipelineML
4. Recent Developments
5. Current Issues
6. Concepts for Harmonization with LandInfra
7. Upcoming Interoperability Experiment
8. Question and Answers
9. Next steps

We discussed some of the recent developments in our standards initiative. This included the following:

• Completed Coterminous Component Attribution Definitions (where to find docs)
• Completed External Reference Code Lists for all Coterminous Components
• Started Appurtenant Component Attribution Definitions
• Started External Reference Code Lists for all Appurtenant Components

We addressed some current issues we are addressing. This included the following:

• Refining component attribute inheritance
• Whether to support virtual linepipe component
• Supporting coincident coordinates as default topology with augmentation for logical topology
• How to avoid unnecessary overlap with other standards efforts
• Concepts for Harmonization with LandInfra

Finally, we touched on some of our upcoming next steps. This included the following:

• Upcoming Interoperability Experiment
• Question and Answers
• Next steps
  • Appurtenance component attribution definition
  • Connector component attribution definition
  • Pipeline/assembly attribution definition

 

Our meeting in Delft, The Netherlands took place on March 23, 2017. The following are our agenda:

• Welcome and Introduction
• Recommended Resources for new participants
• Where are we – status of PipelineML
• Recent developments
  • Modular schema revisions
  • Conceptual model revisions
  • Component attribution definition
• Key Discussion Points
• Next Steps
  • Completion of attribution definitions
  • Application schema generation and schema refinement
  • Interoperability experiment
  • Roadmap
• How to participate
• Q&A

Jan Stuckens, our Co-chair from Belgium, was present in person at the meeting. So, he led much of the presentation. There were about 9 member present in Delft as well as up to 5 people attending online for a total of 14 attendees. The following notes were taken.

• Welcome (Jan)
• Introductions
  • Jan Stuckens
  • John Tisdale
  • Local Attendees
  • Remote Attendees
• Pipeline SWG Objectives – http://www.opengeospatial.org/projects/groups/pipemlswg
• Public-facing document – Introduction to PipelineML available at http://www.pipelineml.org/documents/
• Contact the Chairs
  • John Tisdale JTisdale@eprod.com
  • Jan Stuckens Jan.Stuckens@merkator.com
• Status Update
  • PipelineML SWG started in March 2014
  • Extensive encoding prototyping in 2014-2015 to help determine our conceptual model framework
  • Developed conceptual model in 2016
  • Defining feature attribution and inheritance modeling in 2017
  • Our goal is to have our conceptual and encoding standard proposal for Core schema ready for AB submission by end of 2017
  • Ongoing discussions with LandInfra DWG/SWG about harmonization of our standards efforts
• Revisions to the package dependencies or modular schemas were discussed by John Tisdale
• Recent revisions made to the conceptual model was discussed by Jan and John
• The location of the component (Feature) attribute documents on the OGC portal were covered. The linepipe attribution document was opened and the contents quickly reviewed by Jan.
• Key Discussion Points
  • Discuss potential extension of standard to support OffShore midstream assets (Petrobras/Brazil). We discussed the potential of including offshore midstream assets in the future. It was mentioned that such assets could be included in the core schema instead of using an Offshore schema.
  • Discuss potential adjustments to harmonize or even merge with LandInfra
    • Advantages of merger
    • Disadvantages of merger
  • The advantages and disadvantages of merger with LandInfra were discussed at length. It was mentioned that the next step will be to hold an offline conference call with the key stakeholders of LandInfra for additional conversation on the topic.
• Next Steps were discussed, including:
• Core componentry attribution
  • Elbow, Tap, Reducer, Cap, Pump, Compressor, Meter LauncherReceiver
  • PipeConnection
  • Sleeve, LinepipeCoating, Casing
  • StationEquation, Assembly, Pipeline
• Application schema generation
• Schema Refinement
• Interoperability Experiment
  • PipelineML Future Roadmap were mentioned:
  • Cathodic protection
    • Cathodic prot cables, anode beds, measure points…
  • Safety
    • Beacons, marker stones, physical protection
  • Connectivity
    • Connectivity model vs topology
  • Operations
    • Operational state, gas type, standard operational pressure
    • Real-time attribution?
  • Survey
    • Survey info, accuracy, equipment, date
  • Regulatory
    • Multiple national regulatory standards
    • Common subpackage?
  • Jan discussed how people can participate in the standards development initiative. This included the following points:
  • Document Reviewer (OGC membership recommended)
    • Feedback on conceptual model, UOM, attribution
  • Interoperability Experiment (OGC membership NOT required)
    • Test standard on corporate asset data model
  • Active Contributor (OGC membership required)
    • Selected topics e.g.
      • Connectivity submodel
      • Addition of specific componentry e.g. off-shore
      • Work out specific packages (to be discussed)
  • Additional notes from Q&A discussions include the following:
  • The question was raised as to whether we should include a Metadata schema. We concluded that metadata was needed within each schema and therefore it was not necessary.
  • The possibility of including a Maintenance Schema in addition to Operations was discussed. We decided to give more careful consideration of this concept
  • It wad discussed that we should consider renaming the Appurtenance abstract class to something else as this name is used in INSPIRE with a different meaning and may cause confusion. We will give this matter additional consideration.
  • An attendee suggested Facility could be a specific sub-type of Assembly – Facility may have a one to many relationship
  • Assembly – connects 2 or more components. Should the conceptual model be revised? Assess further.
  • An attendee mentioned the need to support an Unknown series of components – not use linepipe but give a unique type. This was considered a valid point and warranted additional consideration.

Our quarterly OGC Technical Committee meeting was held this week in Taichung, Taiwan. Attendance was low as the meeting occurred from 1:15-3:00 AM CT on Saturday night/Sunday morning. Here is the agenda for the meeting:

• Attendee Introductions
• Overview of PipelineML SWG
• Review of Introduction to PipelineML document
• Discussion of Package Dependency Model
• Summary of Conceptual Model
• Q&A
• Discussion on overlap with other standards body such as LandInfra and potential for future merger
• Discussion on 2017 Interoperability Experiment
• Planning for March 2017 Delft meeting
• Next steps for SWG

Trevor Taylor was present in Taichung. John Tisdale dialed into the meeting and covered most of the contents. Besides providing an overview and answer questions, we discussed plans for the upcoming March 2017 meeting in Delft, The Netherlands. This meeting is expected to draw a larger audience and to be at a more US-friendly time.

We are making excellent progress on the list of attributes to be supported in the first version of PipelineML. As you may know, Jan Stuckens in Belgium was voted in as a co-chair of the Standards Working Group. We are holding weekly conference calls where we are going through our individual lists of component attributes and determining matches, overlaps and gaps. It is an arduous process. However, the results are quite encouraging. We are finding over 90% matches. The remaining 10% of attributes are being flagged for inclusion or exclusion based on our discussions.

Our OGC Technical Committee meeting held on September 21, 2016 in Orlando, FL USA went well. This was the 100th occurrence of the OGC TC meetings. We briefly reviewed decisions made in previous meetings. We discussed our concepts for modularizing our schema and presented a package dependency UML diagram that illustrated our concepts. There was solid agreement on the approach. Jan Stuckens and I presented the most recent version of our conceptual model as a UML class diagram. Jan discussed some of the issues involved in supporting the European INSPIRE initiative. There was some good healthy discussion. Jan also provided an overview of his concept for a units of measure schema that is a hybrid of some existing standards and accepted values with some modifications to address our needs. We discussed how we were working with some of the other OGC working groups to avoid unnecessary overlap in our efforts. We did not have any decisions that required a vote. The following was the meeting agenda:

1. How We Got Here
2. Package Dependencies
3. Conceptual Model Presentation and Discussion
4. Units Of Measure Schema Presentation and Discussion
5. Feedback, Questions and Answers
6. Next Steps

We held an important PipelineML SWG meeting this week. The following were the primary topics on the agenda.

1. Status Update
   • Ongoing prototyping of PipelineML encoding using nonproprietary sample dataset
   • Undergoing major revisions from lessons learned
   • Only working on core feature class of pipeline components that will comprise the core schema
   • Refining our component elements and attributes
   • Defining our reference data code lists
   • Defining our conceptual model as we learn from prototypes
   • Preparing for major revision in September Orlando TC
   • Working toward an OGC Experiment
2. International Co-chair Position
   • OGC PipelineML SWG down a co-chair due to Terry Strahan leaving Morris P. Hebert, Inc.
   • Desire to increase international representation within PipelineML SWG
   • Introduce Jan Stuckens from Belgium
   • Jan Stuckens’ background and introduction
   • Vote to add Jan Stuckens as PipelineML SWG co-chair to replace Terry Strahan
3. Discussion on standardization of international units of measure
   • Creating a custom UOM enumeration to service our needs (Option A or B)
   • Utilization of http://unitsofmeasure.org/trac/
   • http://www.opengeospatial.org/standards/om
4. Request comments on component elements and attributes inventory 
   • Changes necessary to support internationalization?
   • Any missing attribution for existing component list?
5. Internationalization Issues
   • Is there a valid use case for the interchange of pipeline data across nationalities and languages such that we need to unify translated terminologies using common numeric values?
   • How have other OGC groups handled international encoding?
   • What lessons have been learned about what not to do?
6. Discussion on reference code list integration and management
   • Store stable reference code lists as enumerations     in schema
   • Store nonstable lists temporarily in schema until more viable approach is developed
   • Oasis Genericode
   • Schematron
   • CSW-ebRIM
   • Custom built online type registry
7. Questions and Answers
8. Open Discussion

We introduced Jan Stuckens of Merkator NV/SA in Belgium. OGC staff introduced us to Jan several months ago. After extensive dialogue, it was apparent how closely aligned Jan’s knowledge, skills and philosophies were aligned with those of the SWG. A co-chair seat was vacated when Terry Strahan left his previous company that was a member of the OGC. So, we proposed Jan be elected to this co-chair seat. There were no objections to unanimous consent and Jan was elected as Co-chair of OGC PipelineML SWG.

The OGC PipelineML SWG met this week at the Technical Committee meetings in Sydney. The following were the topics on our agenda.

1. Discuss changes to Prototype 1 scope
2. Discuss who has reviewed the Prototype 1 schema and sample instance data
   • Questions and answers related to these documents
   • Gather any feedback on suggested changes
3. Discuss scope and schedule for Prototype 2
4. Discuss Enterprise Products’ internal efforts working with our pipeline engineering group to vet a list of standardized domain reference codes that are compatible with the American Petroleum Institute’s (API) pipeline standards
   • Any volunteers to submit their reference code lists for review and possible inclusion in these code lists?
   • Open discussion regarding international issues pertaining to reference code list standards.
5. Discuss use of GML Dictionary standard as a short-term solution for external reference code management until such a time as requirements can be gathered, joint funding raised, a Request for Proposal written, and submitted to service provider candidates for the development of a Web-based Code Type Registry (discussion of instance registry development will be reserved for a future date)
6. Discuss possible participation in an OGC Interoperability Experiment
   • When is the best time for participation? Now. At end of Prototype 2 development?
7. Discuss next steps
8. Volunteer opportunities
9. Open question and answer

The discussions were positive and the feedback was informative. We reviewed the status of the initiative, answered questions and discussed next steps. There were no votes involved in this meeting. Below is the summary presented at the Closing Plenary:

1. Discussed successful completion of PipelineML Prototype 1 that included:
   –GML SF-0 (almost-compliant) Application Schema
   –Instance document containing accurate sample data with weld-level detail of connected pipeline components with full attribution
   –Complete documentation
   –Online and static help files to help domain experts understand and speak into the standards initiative
2. Discussed use of PipelineML for upstream and downstream industry segments in addition to the midstream market
3. Discussed need for internationalization of standards
4. Discussed how best to support internationalization of reference code lists with no decisions
5. Discussed need to support multiple geometry types per feature – 0 dimensional (point) and 1 dimensional (linestring/curve) for backwards compatibility with PODS data storage model
6. Need to switch order of geometry types so that GIS applications that do not support multiple geometry types and default to choosing last one, will utilize the linestring geometry and not the point geometry
7. Identified SF-0 compliance issue:
   –User-defined complex type using MaxOccurs=“Unbounded” need modification – will put metadata schema migration into Prototype 2 scope
8. Began Defining Prototype 2 Scope:
   –Migrate metadata to OGC/ISO metadata schema
   –Bind type data to external domain reference code lists (xml static files) until online type registry can be scoped, funded and developed
   –Create broader variety of sample data packages to demonstrate flexibility of solution (simple, intermediate, complex, etc.)

 

We held a heavily attended meeting this week in Dublin (as most of the current stakeholders are in the U.S.). Several members of the PODS Association were on hand. We had a wide variety of dialogue that involved retracing much of the work undertaken to date as well as philosophical and technical discussions. The following was our meeting agenda:

1. Quick walkthrough of Prototype 1 Definition document (to be posted to portal prior to the meeting and as quickly as possible although it is undergoing heavy revision currently—it is not subject to 3 week rule as it will not require a vote, per Scott Simmons)
2. Gather feedback on such issues as:
   1. Prototype methodology, scope and schedule
   2. Whether to support pipeline component sub-elements for type attribution or role all component type attribution up to the parent component feature element
   3. How best to leverage FeatureCollections based on the proposed data structure (experience from past initiatives)
   4. Given the sample instance data structure defined in above document, can we achieve GML-SF level 0 compliance or will we need to resort to level 1 compliance (why and how)
   5. Should we attempt to support 2 levels of data granularity in this first prototype – (1) detailed feature attribution and (2) simplified geography representation for visualization and if so what are thoughts on the best approach (any lessons learned from other group initiatives)
3. Discuss possible participation in Interoperability Program and interest in sponsorship among stakeholders
4. Request assistance with:
   1. Modeling conformance classes in UML
   2. Vetting of metadata and feature attribution from pipeline industry and survey professionals

The following were the summary points made during the Closing Plenary:

1. Reviewed PipelineML Prototype 1 Definition document
2. PipelineML SWG is pursuing an early encoding prototype based on GML Application Schema and Simple Features profile SF-0 compliance with a very narrow scope.
3. Goal is to get sample data to stakeholders quickly to inform technical decisions regarding supported features, reference code lists, abstract/conceptual model, conformance classes, etc.
4. Use Cases
   –Detailed Survey Data Package from New Pipeline Construction
   –Light-weight Survey Data Visualization of New Pipeline Construction
5. Test Cases
   –Visualize survey data package using ESRI ArcGIS
   –Visualize survey data package using open source GIS tool such as QGIS
   –Facilitate programmatic coterminous component count (tally)
6. Detailed discussion and feedback will be facilitated via a follow-up meeting in 4 weeks.

The following are notes from this week’s PipelineML SWG meeting held in Geneva on June 10, 2014:

Meeting Metadata

Date: 2014.06.10 17:00-17:50 PM (10:00-10:50 AM CDT)

Location: Geneva, Switzerland

Attendees:

• John Tisdale, Enterprise Products
• Gary Hoover, Enterprise Products
• Terry Strahan, Morris P. Hebert, Inc.
• Bart De Lathouwer, OGC
• Joseph Howell, Global Information Systems

Meeting Agenda

The following agenda was reviewed with no comments:

• 17:00-17:05 – Meeting Schedule Overview
• 17:05-17:20 – Election of SWG Chair and Co-chair positions
• 17:20-17:25 – Key PipelineML Events to Date
• 17:25-17:30 – Governing Values of PipelineML
• 17:30-17:40 – Standards Development Process
• 17:40-17:50 – Major Components of SolutionThe following guidelines were discussed related to potential conflicts of interests regarding leadership positions for the SWG. We want to avoid any situation in which there could be a perception of a conflict of interest. Given these parameters, the following guidelines were suggested:
• Chair and Co-chair Election

• Avoiding Potential Conflicts of Interest

• Position/s should not be delegated to:
  • Staff of vendor/solution provider who may be considered for outsourcing, prototyping, or building of any PipelineML components or technologies
  • Staff of standards organization
• Prefer pipeline operators or pipeline service providers (non-technical services providers)
• Following leadership guideline discussion, the opportunity was extended for nominations to be made for the Chair position of the SWG.

• Nominations for PipelineML SWG Chair Position

• Ron Lake, Galdos Systems, nominated John Tisdale
• Gary Hoover, Enterprise Products, seconded the motion
• No further nominations were made
• Call for discussions yielded none
• Call for objections to unanimous consent yielded none
• Motion passed

• Nominations for PipelineML SWG Co-chair Position/s

• Gary Hoover, Enterprise Products, nominated Terry Strahan
• Ron Lake, Galdos Systems, seconded the motion
• No further nominations were made
• Call for discussions yielded none
• Call for objections to unanimous consent yielded none
• Motion passed

Key Milestones for PipelineML

The following information was shared outlining some of the key milestones that have led to this point in the formation of PipelineML:

• PODS and Enterprise Products begin exploring standards opportunities with ISO 15926 (11/2012)
• Enterprise Products joined OGC (7/2013)
• Formation of OGC PODS MOU (9/2013)
• OGC PipelineML Ad-hoc Meeting – Washington, DC (3/2014)
• Tentative formation of PipelineML SWG (3/2014)
• Development of PipelineML SWG Charter (3/2014)
• Refinement of PipelineML SWG Charter (4/2014)
• Charter review and commenting period passed (5/2014)
• Discussions with American Society of Civil Engineers (ASCE) about formation of MOU (5/2014)The following governing values were defined for PipelineML:
• Governing Values for PipelineML

• Practical/Pragmatic
• Flexible
• Extensible
• Fit-for-purpose
• Broad industry support (International)
• Use Case driven
• Agile and iterative developmentThe following process was proposed for the development of the PipelineML standard.
• Proposed Process for Defining and Developing the PipelineML Standards

1. Identify Prospective Partners and Engage in Dialogue
   • Existing standards bodies (identify gap/overlaps – adopt and extend whenever possible)
   • Thought-leader pipeline operators and service providers
2. Requirements and Scope
   • Gather, document, model (UML), and vet use cases and requirements
   • Define phases and scopes
3. Define Solution Architecture
   • Major solution components
   • Discover existing solution components we can leverage
   • Define component champions and ownership
4. Develop PipelineML
   • Define conceptual model
   • Determine existing standards candidates (XML, GML, CSW-ebRIM, etc.) – integrate where viable
   • Translate conceptual model into encoding schemes
   • Rapid prototypes in agile iterations to quickly vet concepts
   • Engage OGC Interoperability Program
   • Test proposed standard
   • Collection additional feedback
   • Refine standard as needed
5. Publish Standard
6. Create Awareness of Standard among Industry Stakeholders
7. Broaden Scope, Mature Concepts and Repeat

The opportunity for feedback was extended. Ron Lake mentioned the need to define the conceptual model as early in the process as possible. Ron was thanked for his feedback and insights.

Key Components of Solution Architecture

The following diagram was shown and discussed that define the key components of the proposed solution:

The Pipeline Type Registry [working title] is an online registry that contains a thorough industry-vetted listing of various component types.

1. This registry would provide the functionality needed to add or edit classes of codes, codes, and attributes
2. This registry would provide the functionality needed to add or edit classes of codes, codes, and attributes

 

We held an ad-hoc meeting at the OGC Technical Committee meetings in Washington DC. Gary Hoover, Dion Duran and myself traveled to DC to attend this special meeting in person. We were joined by around 90 people in attendance remotely as well as in person. The following was our agenda:

1:00-1:15 Attendee Introductions

• Who are you?
• In what field do you work?
• What is your interest in PipelineML?

1:15-1:45 Pipeline Industry Overview (Gary Hoover)

1:45:2:15 Information Management Challenges (John Tisdale)

2:15:2:45 Potential Technical Solutions (Dion Duran)

2:45-3:00 Break

3:00-3:30 Open Discussion

3:30-4:00 Applicability of Existing OGC Standards and WG’s

4:00-5:00 Next Steps

• Phase 1 scope definition
• Intellectual property issues
• Propose formation of Standard Working Group (Pipeline SWG)

Many questions were posed and discussions went on until near the end of our allotted time of 5:00PM. We called for a vote for the creation of the OGC PipelineML Standards Working Group (SWG). There was a strong voice of affirmations and no objections to anonymous consent. The vote passed with much applause and the SWG at formed. John Tisdale was elected as the interim chair until the following quarterly meeting where nominations could be made and voted tallied.