Update on PRODML

1
Update on PRODML

• Alan Doniger, Energistics CTO
• November 28, 2007
• Mumbai, India

2
Agenda

• Overview
• Recent Highlights
• Energistics Standards Summit, Nov. 6
• SPE Conference, Nov. 13
• Recap PRODML
• Business Case and Requirements
• Scope Production
• Roadmap 2006-2010 in place
• Conclusions
• PRODML SIG Meeting, Nov. 14
• Status and Participants
• Organization, Process, and Plans

3
Special Interest Groups and Subject Areas

• WITSML SIG (Drilling)
• PRODML SIG (Production)
• Data Management SIG
• Global Unique Well Identification
• Business Process Ref. Model
• EP Catalog Standards
• Reference Data Standards
• Industry Services SIG
• Energy Identity Trust

eRegulatory SIG Geophysics SIG Geology SIG
4
Recap PRODML Completing Year 2

• 2006 started by 5 operators with vendors
• A data interchange standard for production
• XML messages carried by web services
• Public domain standard
• Energistics is the organization with stewardship
  of the standard
• 4 pilot projects completed 2006
• 2007 year two, grows to 7 operators with 13
  vendor companies

5
PRODML Business Case

• Production application domain fragmented - point
  to point integration costly, slow, high
  maintenance
• Objectives
• Make integration cheaper, faster, simpler
• Enable dynamic creation value loops with new
  workflows and applications added on the fly
• Industry standards approach recognizes diverse
  supply chain

6
Data Exchange Needs

• Fit-for-purpose
• Integrate diverse data structures from single
  sensors to equipment performance and constraint
  curves
• Integrate schedules and trends of history and
  forecast
• Communicate changes in the information hierarchy,
  that arise from equipment add/remove and changes
  in characteristics

7
Potential Benefits

• Improved operational efficiency
• Improved data trustworthiness
• Accelerated adoption of production optimization
• Exploitation of remote skill and labor for
  production optimization
• Increased contribution of production optimization
• Safer working environment

8
PRODML The Most Viable Way to Enable Production
Interoperability

• The Opportunity
• Production application domain highly fragmented
• Doing nothing implies point to point
  integration costly, slow, very high maintenance
  ? Opportunity to fix this!
• The Objective
• Make integration cheaper, faster, simpler
• Enable dynamic creation value loops with new
  workflows and applications added on the fly
• Supply chain models standards vs consolidated
• Scada many vendors, public standards
• GG/Reservoir few vendors, de facto standards
• Production industry standards approach ?PRODML

9
ltPRODML/gt Producing Asset Scope
The Production Domain
10
PRODML Provides Glue in Key Area of Asset
Management
Business Processes
After Chevron, ExxonMobil
2008 (OPC-UA Option)
2006 PRODML Initial Scope
2007-9
2010
Many Production Applications
The Solution PRODML Open Standards
11
PRODML Material Progress 2006-7

• A common language for production data has been
  created
• Commercial application has commenced, eg
• Production Reporting (Statoil)
• Waterflood management (Chevron)
• DTS data management (Weatherford)
• First Commercial Applications (Schlumberger)
• RD Proofs of Concept have been substantial
• Gas Lift Optimisation
• Downhole sensors
• 5,000 well dataset transfers
• Network Model changes moving between applications

12
PRODML Data Objects

• Flow Network Model
• Originally defined for partner production
  reporting
• Production Volume Report
• Used for transferring all types of measurements
• Correlates to the Flow Network Model
• Originally defined for partner production
  reporting
• Well Test
• Originally defined for partner production
  reporting
• Distributed Temperature Survey
• (under development) Measurements
• (under consideration) Asset Reference Model

13
PRODML Focus Production OptimizationRoadmap in
place 3 more years to industry standard
Business Processes
High Frequency
Low Frequency
30
After Chevron, ExxonMobil
14
Opportunity Complete by 2010

• Way ahead clear 2008-2010 after year 2 review
  completed
• Extend Language for more processes assets
• Evolve Multiple protocols, giving easier
  deployment flexibility
• Professional support services from Energistics
• Grow Community 7 Energy, 12 Svc. Co.
• Multi-year commitment now required for successful
  completion

15
Roadmap of Use Cases 2006-10
16
Roadmap of Use Cases 2006-10
17
PRODML Future

• Opportunity Complete by 2010
• Way ahead clear after year 2 review completed
• Extend Schemas for more processes assets
  (roadmap)
• Evolve Multiple protocols, giving easier
  deployment flexibility but maintaining
  stability
• Professional support services
• Grow Community of users from current 20

18
Summary PRODML

• 2006-7 has established critical mass of content,
  technology and community
• 11 pilot projects completed involving 20 Co.s
• Successfully demonstrated many key benefits
• Roadmap for Use Cases projected for completion
  2010
• To be adopted in commercial projects from 2008

19
PRODML Status, Organization, and Plans
20
PRODML Initiative Headlines

• Scope
• Data Transfer and Web Services Standards
• Optimization and Transfers for Reporting and
  Complex Analysis
• Production Operations Coverage (short to long
  time cycles)
• Status
• Completing 2nd Year (started in late 2005 by 5
  energy, 8 vendor organizations plus Energistics)
• Ten completed implementation pilots (4 in 2006, 6
  in 2007)
• Evolving long-range road map commitment to
  delivering value
• Growing User Community (SIG) of over 25
  Organizations
• For 2008, quarterly technical workshops plus
  ongoing working teams using virtual collaboration
  tools
• Active SIG and Work Group teams project manager
• Current Release Version 1.0 published in
  November 2006
• Next Release Version 1.1 scheduled for Q2 of 2008

21
(No Transcript)
22
(No Transcript)
23
Special Interest Groups
EnergisticsBoard of Directors Management
Staff Membership
SIGs are standardsuser communities
PRODML SIGParticipants
WITSML SIG
Data Management SIG
Other SIGs
Energistics StandardsWITSML, PWLS, Epicentre,
etc.
24
Energistics Standards Life Cycle
25
PRODML Timeline
Years
2000-2001
2002-2003
2004-2005
2006-2007
2008-2009
2010-2011
WG06 Version 1.0
WG07
Version 1.1
WG08 Version 2.0
WG09
Version 2.1
WG10
Version 2.2
26
PRODML SIG Team Leaders

• PRODML SIG Steering Committee Chair
• Laurence Ormerod, Weatherford
• PRODML Work Group 07 Operational Team Chair
• Ben Weltevrede, Shell
• PRODML Work Group 07 Pilot Team Leaders
• Joe Palatka, BP
• Rick Morneau, Chevron
• Don van Speybroeck and Russell Borgmann,
  ConocoPhillips
• Carol Tessier, Pioneer Natural Resources
• Ben Weltevrede, Shell
• Bjorn Rugland, StatoilHydro
• PRODML SIG Coordination
• Alan Doniger, Energistics
• Gary Masters, Energistics
• Bryan Becker, Project Manager

27
SIG Meeting Agenda, Nov. 14

• Technical Review Team Summary Recommendations
• SIG Plans for 2008
• Funding
• Next Steps

28
Philosophy

• PRODML 2007 should be basis of major commercial
  deployment
• Evolve infrastructure new technologies optional
• Data model will evolve no major change to core
• Big effort on supporting deployment

29
V1.1 Release

• A technical upgrade is to be completed before
  release (items 1 2 TRT)
• Pilot teams have identified issues to sort out in
  addition to the upgrade
• This work should be done first before release
• As much documentation per plan as we can afford

30
Development 2008 and beyond

• Funding will focus on RD for content with low
  maturity plus supporting activity
• Commercial activity will drive majority of
  development next 3 years
• Work definition of use cases with SPE

31
Major Strategic Issues

• Engagement of all kinds of members for support
• Next generation Technical Architecture
• Energistics-wide
• PRODML, WITSML, etc.
• Recruit new members

32
Rough Maturity Model

• Maturity of Use Cases
• Proportion of workflows associated with a use
  case which are covered
• Completeness and usability of the workflows which
  are covered
• Work efforts need to reflect maturity, by type
• Use cases needing RD to discover needs
• Use cases which can be deployed selectively with
  asset Energistics support
• Use cases ready to deploy unsupported

33
Proposed Operating Strategy

• Finish/Fix 2007 work to make 1.1
• Drive to gather 2008 level 2 3 work efforts
• Refine use cases
• Support level 2 and 3 work efforts (not funding
  work efforts themselves)
• Conduct fit-for-purpose level 1 development
  (funded)
• Shift into workshop-driven development

34
Detailed Tasks and Teams

• Opportunity team
• Matches roadmap to real world deployments, SPE
  TIG, etc.
• Marketing team
• PRODML.org, SPE shows etc
• Technical team
• Architecture
• A seat for everyone
• Content team
• Detailed domain design, SMEs, support deployments
  / work efforts
• Training and support team
• Documentation material
• Workshop training
• SIG OT
• Comprises team leads plus others

35
Milestones

• Series of workshops coinciding with key stages
• Build community with multiple tracks PM role
  whole activity (Aberdeen template)
• Quarterly
• To coincide Intelligent Energy 25 Feb
• May
• To coincide SPE Denver 28 Sept
• December

36
Workshop 1 Feb IE 2008

• Opportunities track
• Divide into level 1, 2, 3
• First pass assess gaps in 1.1 for development
• Plan detailed design work until next workshop
• Technical track
• Working session
• Feedback session on proposed changes
• Training track
• On-boarding for new members (methodology etc)
• Hands on developer training
• SIG Management
• Dedicated time for governance
• Opportunities gathering is on-going
• Marketing
• SPE paper (may already be in by then)

37
Workshop 2 - May

• Release of 1.1 with fixes, with new object, with
  documentation
• Development track
• Level 1, 2 and 3 requirements wrap up
• Training track
• Emphasis on training for 1.1
• Training in new content
• More hands on developer training
• Technical track
• Lessons learned, potential roadmap if appropriate
• Marketing track
• SPE Plan etc
• Management
• As previous

38
Workshop 3 - SPE

• Training
• Sessions in brochure etc
• Marketing
• Development track
• Level 1, 2, 3 working sessions
• Management
• 2009 outline
• Technical
• Progress review UA etc
• Market review

39
Workshop 4 - Dec

• Training
• Development
• Marketing
• Management
• 2009 detailed planning

40
Governance

• Sign up for a team commitment to participate.
  Defined contribution expressed as person-time
• Develop expectation that workshop participation
  is aligned to actual contributions

41
Thank You

• Contact
• Alan Doniger, Energistics CTO
• 1 713 267 5124
• Alan.Doniger_at_Energistics.org

42
Technical Review Team
Status Report
43
Reminder of Perceived Barriers to Commercial Use

• The fact that discussion between application
  developers is needed to sort out what data and
  functions on data are available from any
  application, prior to linking.
• The lack of extensibility, so that any new idea
  cannot be incorporated into data.
• Complexity of the interfaces to data, leading to
  ambiguity and to difficulties for new adopters.
• Lack of good working examples, of test servers
  and of compliance assurance to help developers be
  confident they are doing it right.
• Lack of strategic certainty leading to developers
  adopting wait and see attitude.
• Lack of clarity as to co-existence with other
  standards, especially the emerging OPC-UA

44
Constraints

• Architectural concepts
• While other communication transports may be
  added, thePRODML interface must retain a web
  service implementation
• Current specification
• The team is explicitly invited not to feel
  limited by the approach taken by WITSML and
  PRODML V1.
• One Change to Specification
• The technical standard for PRODML must only
  change fundamentally in one instance over the
  foreseeable future
• Timing
• The team needs to complete its report and proof
  of concept to enable testing in the second batch
  of WG07 pilot projects.

45
Problem Analysis

• The structure of the data exchange object
• Identification of individual elementsSystem
  configuration
• Client-Server Interaction

46
Structure

• Document-centric
• Designed for specific purpose
• Self contained
• Used infrequently , primarily for reporting
• Focused
• Ad-hoc data exchange
• Contain only those elements needed for specific
  exchange
• Used very frequently

47
Structure - 2

• The document contains a fixed collection of
  parameters. Using parameters that are not
  defined in the document require a schema change,
  which is a barrier for extensibility.
• The use of the parameters (outside the context of
  the reporting) is not standardized and requires
  agreement between parties.
• The document is overly complex for the purpose of
  ad-hoc communication.

48
Structure simplified example

• ltpropertyHistory uid"FLWMTR-234234"gt
• ltpropertyKindgtvolumelt/propertyKindgt
• ltcontextgt
• ltinstallation kind"field"gtspindletoplt/installa
  tiongt
• ltfacility kind"choke"gt32ltfacilitygt
• ltfacilityParent1 kind"well"gt42390ltfacilityPare
  nt1gt
• ltportDirectiongtoutletlt/portDirectiongt
• ltflowKindgtproductionlt/flowKindgt
• ltflowQualifiergtmeasuredlt/flowQualifiergt
• ltflowProductgtwaterlt/flowProductgt
• lt/contextgt
• ltdatagt
• ltdTimgt2007-10-12T002123ZltdTimgt
• ltvalue uom"m3"gt23.3lt/valuegt
• lt/datagt
• lt/propertyHistorygt

49
Simplified structure advantages

• Reduced need for discussions between client
  server developers
• Footprint much wider

50
Identification configuration

• Identification context
• Mapping to be performed by every server
• Each server must be supplied with configuration
  data
• The inclusion of parameters required for natural
  identification unnecessarily complicates the
  exchange document.

51
Identification context

• ltproductVolume uid"PRODML_Shell_Pilot_Flow_Prope
  rties"gt
• ltnamegtPRODML Shell Pilot Flow
  Propertieslt/namegt
• ltinstallation kind"field"gtRotterd
  amlt/installationgt
• ltkindgtPRODML optimizationlt/kindgt
• ltperiodKindgtreport
  startlt/periodKindgt
• ltdateStartgt2005-10-26lt/dateStartgt
• ltdTimCurrentgt2005-10-26T080000.0
  00Zlt/dTimCurrentgt
• ltfacility
  uid"RotterdamRTD_13lift_gas_controller"gt
• ltname kind"controller --
  lift"gtlift gas controllerlt/namegt
• ltfacilityParent1
  kind"well"gtRTD 13lt/facilityParent1gt
• ltfacilityParent2
  kind"field"gtRotterdamlt/facilityParent2gt
• ltunit uidRef"C"gtClt/unitgt
• ltflow uid"3a_gas_measur
  ed"gt
• ltnamegt3a gas
  measuredlt/namegt
• ltkindgtgas
  liftlt/kindgt
• ltport
  uidRef"port-2"gt2lt/portgt
• 
  ltdirectiongtoutletlt/directiongt
• 
  ltqualifiergtmeasuredlt/qualifiergt
• 
  ltversiongt2005-10-26T080000.000Zlt/versiongt

Flow contextPressure expressed as attribute of
gas Asset Hierarchy Context Pressure expressed
as value of device
52
Entity identification
Client
Server
Server
Server
UI
UI
Configurationdb
ConfigurationFile
Hard coded
53
Entity identification Asset Reference Model
Client
Server
Server
Server
UI
Asset Reference Model
54
Asset Reference Model

• Shared Asset Model
• Single source of reference data
• Supports asset hierarchy and flow network
  connectivity
• Uses standard names for types and roles (e.g.
  temperature sensor and FTHP )

55
Asset Reference Model Server
Client
Server
Server
Server
ARM Server
UI
Asset Reference Model
56
Asset Reference Model Server
Client
Server
Server
Server
ARM Server
UI
Asset Reference Model
57
Asset Reference Model Server

• Flexible translation from natural to UID
• Runtime data discovery
• which data is available?
• Which server holds information?
• How is this data identified by this server?

58
Asset Reference Model - Discovery
1
Client
2
Server
Server
Server
ARM Server
UI
Asset Reference Model
1
1
Get server URL and data uid
Get server URL and data uid
2
Get data
59
Step 3 Client-server Interaction method

• Query Template
• XQuery
• Functional interfaces
• UA address space

60
Model 1 Query Templates

• Designed for specific purpose
• Limited Query Capability
• Syntactically complex

61
Model 2 XQuery

• Potential for Generic query
• Return can be XML document
• Needs further investigation

62
Model 3 Functional Interfaces

• Application-class specific Services
• Each service number of operations, narrow in
  scope, wide in deployment

63
Model 4 UA Address Space

• Network of objects
• Extensive software to manipulate and select
  objects
• Provides gateway to data

64
UA Usage Options

• Use UA Stack only
• Use Stack and Address Space

65
UA Stack only

• Similar to standard web services
• Added benefits
• Session management with authentication
• Encryption
• Reliable publish / subscribe mechanism
• Different transfer options
• State full
• UA code isolated

66
Address space browsing

• Full mesh network
• Extensive code base to manipulate objects in this
  space
• Requires understanding of UA concepts and
  knowledge of toolkit

67
Findings - 1

• Sufficiently stable and mature for use in
  commercial products
• Security, robustness, publish/subscribe and
  flexible communication are substantial added
  value
• Technology similarity in standards in Process
  Control Domain

68
Findings - 2

• Toolkit documentation insufficient(essential for
  UA- the full Monty)
• Risk changes expected in first years

69
UA Recommendation

• UA stack only Not Recommended
• Benefits insufficient
• Lack of OPC support
• UA address space Not Recommended at present
• Steep learning curve
• Lack of documentation
• Benefits unproven

70
UA Outlook

• Best fit in Asset Reference Model Server
• Design ARMS with UA in mind
• Network model matches our problem space
• Define functional and generic interfaceto enable
  UA-based server

71
ARM server and UA
UA server
UA client
PRODMLclient
PRODMLWS interface
72
Recommendations

• Define simple focused data exchange object
• Asset Reference Model
• Store reference data in single location
• Define Asset Reference Model specs
• Asset hierarchy and Network architecture
• Web services interface identity translation
  service
• Investigate UA benefits and revisit 2009

73
Timeline (for discussion)
Anaheim
Public Review
Internal Review
Report Discussion Paper
Nov
Dec
Jan
Feb
Mar
Apr
End of review
Proposal Draft spec
PRODML 1.1
74
Tasks

• Define ARM server
• Functionality
• Interfaces
• Define client-server interface
• Based on natural identifiers
• Based on UID
• Functional and/or XML document

75
Thank You ???????