A  Leading  Service  Provider  

APIA  CONVENTION  2014  A  DATA  CENTRIC  APPROACH  TO  PIPELINE  ROUTE  

SELECTION  AND  FIELD  DEVELOPMENT  

21  October  2014  

Introduc>on  –  Data  Centric  Approach  

 2  

  Projects  and  assets  have  vast  quan>>es  of  data,  maximising  the  value  of  this  data  can  improve  outcomes.  

  Opportunity  for  an  improved  integrated  approach.    OSD  and  GeoSynergy  have  developed    and  deployed  a  plaRorm  called  Knowledge  Engineering  for  Geospa>al  Systems  (KEGS)  as  the  core  of  our  data  centric  approach.  

  Provide  an  insight  to  how  we  have  approached  this  challenge.    How  can  we  do  things  beXer?  

What  Is  A  Data  Centric  Approach?  

 3  

  The  solu>on:  –  Make  best  use  of  readily  available  data,  and  

front  end  load    –  Systemise  the  process  and  provide  a  

collabora>ve  mul>user  environment    =  KEGS  

  The  core  concept  is  that  data  is  an  asset  and  needs  to  be  managed.    Set  up  from  the  start  to  get  maximum  value  from  data,  then  substan>ve  addi>onal  benefits  are  available.    

  Why  is  this  an  issue?    –  Projects  are  missing  opportuni>es  to  reduce  costs,  reduce  schedule,  improve  landowner  and  

stakeholder  interac>ons,    and  improve  decisions.  –  We  see  the  benefits  of  data  centric  approach  in  every  day  life.  

What  Does  the  Data  Look  Like?  

 4  

Anything  on  ground  which  affects  design,  construc>on  or  opera>ons    

Steep  slopes   Exis>ng  

transport  

Vegetated  areas  

Drainage,  erosion  prone  

areas  Exis>ng  water  drainage  and  storage  

Agricultural  ac>vi>es  

Receptors  

terrain  

Fences/paddocks  

Project  Delivery  -­‐  Engineering  Design  

 5  

  High  level  of  efficiencies    Input  data  acceptance  tes>ng  and  QA  control    Full  stamping  of  changes  in  the  system,  ie  who,  what  and  when    Automa>c  data  integrity  checks,  no  need  for  expensive  engineers  to  check  basic  stuff    KEGS  uses  a  spa>al  rela>onal  database  at  it  core,  it  is  the  central  point  of  truth  for  the  design  process    Outputs  are  a  cut  of  the  KEGS  data  at  a  specific  >me,  no  post  processing  of  the  core  data  

Where  This  Has  Been  Used  

 6  

Some  examples  where  this  has  been  used  recently:    Concept  –   300  well  gathering  system  and  two  30  km  trunklines  for  a  CSG  to  LNG  project  

  Front  End  Engineering  Design  –  15  km  gas  transmission  pipeline    

  Detailed  Design  –  Gathering  systems  for  ~  480  wells  for  a  CSG  to  LNG  project  –  17  km  CSG  wet  gas  trunkline  in  central  Queensland  –  Produced  water  reinjec>on  network  for  a  CSG  to  LNG  project      Opera>ons  –  De-­‐boXlenecking  of  a  sec>on  of  an  20  well  gathering  system  

Tools  Built  Around  Engineering  Rules  

 7  

“Statement  of  pipeline  engineering  logic  that  can  be  programmed”    

 

A  gathering  system  follows  the  least-­‐cost  set  of  paths  to  connect  all  wells  in  a  field,  to  a  single  terminal  (the  facility)  

Wells  are  spaced  regularly,  about  ~750m  apart,  +/-­‐  150m,  in  loca>ons  that  op>mise  gathering  system  length  and  opportuni>es  for  less  

disturbance.    

Drains  are  op>mised  between  distance  (approx  750m  apart)  and  ‘low’  points.  Vents  are  op>mised  between  distance  (approx  750m  apart)  and  ‘high’  points.  

These  can  be  built  into  a  realis>c  spa>al  model  

These  can  be  built  into  a  realis>c  spa>al  model  

These  can  be  built  into  a  realis>c  spa>al  model  

Pipes  are  only  available  in  certain  sizes,  and  should  be  selected  based  on  flow  rate  &  distance  from  facility.  Connectors  are  required  at  pipe  junc>ons,  and  should  be  sized  according  to  respec>ve  pipes.  

These  can  be  run  as  programs  in  a  database  

Data-­‐driven  Network  Rou>ng  

 8  

1.These  rules  (based  on  project  data)    

1.  Drive  this  ‘heatmap’  

3.  Which  can  be  viewed  like  a  3d  terrain  model  

3.  And  as  a  basis  for  network  genera>on  

1.Flow  rates  per  corridor  get  totalled  through  the  network  

 9  

Flow  Assurance  Heuris>cs  

2.  Pipes  and  connectors  get  generated  and  sized  automa>cally  

 10  

Wellpad  Genera>on   •  Oriented  along  contour  •  Sized  according  to  number  of  downholes  •  Temporary  and  permanent  zones  

ROW  1.  Preselected  op>ons  2.  Width  dependent  on  #  and  size  of  pipes  

These  agents1  are  given  behaviour.    Here  they  seek  to  posi>on  themselves  according  to  rules  such  as    “HPV’s  should  be  placed  roughly  every  750m  and  on  high  points”  

Drain  and  Vent  Placement  -­‐  CSG  gathering  

1  Only  a  very  liXle  bit  like  agents  from  The  Matrix  

Erosion  Control  Placement  &  Orienta>on  

 12  

Method  1:    Loca>on  and  orienta>on  calculated  

according  to  slope  length,  angle,  previous  placement  etc  

 

Method  2:  Monte-­‐carlo1  type  simula>ons.  These  agents  

simulate  rainfall.    

Where  they  cross  routes,  their  erosivity  impact  can  be  calculated    as  a  func>on  of  

velocity  X    size.    1  Not  related  to  the  cream-­‐centred  biscuit  Steeper  slope,  closer  

together  

Flat  =  no  erosion  control  

Erosion  barrier  oriented  along  slope  

Rules  Engine  

 13  2.  Rules  engine  constantly  runs  and  checks  how  design  is  

1.  quality  statements  for  design  deliverables  

Conclusion  

 14  

  This  approach  can  be  used  on  pipelines  and  gathering  systems  of  any  sizes,  the  larger  and  more  complex  the  bigger  the  benefits.    

  Can  test  far  more  scenarios,  results  in  far  greater  level  of  defini>on  in  concept.    For  large  gathering  systems,  FEED  is  simplified  and  may  not  be  required  in  some  cases  if  system  standard  components  well  defined  (building  block  approach).  

  To  achieve  this  the  following  key  items  are  required:  

–  Management  of  project  data  

–  Rela>onal  associa>on  of  data  

–  Suitable  tools  to  exploit  the  data  is  required,  the  KEGS  plaRorm  provides  this  

  The  outcomes  are  benefits  across  all  aspects  of  delivering  projects  and  into  opera>ons.