Leveraging a rich amount of data in our corporate SDE to create, both tabular and spatial, to create text-based models for SPS used for pipeline design, optimization and leak detection.
A lot of list building and converting it to text lines, resulting in a sizable text file from spatial data.
2. Objectives
Create models for simulating fluid
in pipelines used in Synergi
Pipeline Simulator [SPS]
● Automate data integration for
pipeline design, optimization,
and leak detection.
● Keep up-to-date with business
demands of using hydraulic
profiling/pressure models.
4. Solution
FME Workflow
Integrate data and
convert into a text-
based format
SPS
Fully functioning system
GIS spatial data
+
PODS attribute data
START FINISH
7. Basic Breakdown: Part 1
Objective:
• Obtain attributes from PODS
database and As-built/ILI generated
pipeline geometry
• Calculate length weighted averages
for attributes such as wall thickness
and operating pressures
• Prepare geometry to be segmented
by lateral (smaller pipelines)
8. Basic Breakdown: Part 2
Objective:
• Convert spatially projected data
back to a Cartesian coordinate
system
• Apply new adjusted coordinates to
all aspects of the text attribute to be
further used: valves, start mid and
end points of pipeline, facilities.
9. Basic Breakdown: Part 3
Objective:
• Provide elevation profile that can be
used by SPS
• Combine entire elevation profiles
into one attribute feature (attributes
with over 100 lines of text)
10. Basic Breakdown: Part 4
Objective:
• Establishing trigger to create a SPS
ready file
• Putting everything in text format into
a basic text file
• SPS takes a specific file type
[.inprep] but in reality is a just a text
file so outputting .txt is renamed to
.inprep
12. Output
• File can be directly imported
into SPS
• Geometrically similar to real
world placement of assets
• Text formatting allows for cut
and paste into existing
models without modifications
to create much complicated
systems
14. Results
● A fully automated system that has replace
manual building of models
● File format that can be imported directly into the
software without further modifications
● 1 month of effort has been reduced to 1-2 hours.
15. Benefits
● Increased standardization and accuracy of
pipeline attributes.
● Automation of model creation.
● Quick turnaround modelling allowing for further
analytics for proposed new builds and new
pipeline to be added to already existing models
● Create models that are visually relatable to real
world placement of assets.
● Time is saved to free up resources and staff
workload.
16. Tips
● ListBuilder, Sorter, and
Concatenator are helpful for
creating multiline attributes.
● ExpressionEvaluator is helpful
for creating scaling factors.
● StringConcatenator is helpful
for generating script syntax.
The engineering team at PMC was struggling to keep up with the business demands of using hydraulic profiling and pressure models for debottlenecking and ideal pressure design for pipeline systems, which were needed for pipeline design, optimization, and leak detection.
Patrick’s team was creating models for use in a program that simulates fluid hydraulics, essentially simulating that there’s a product flowing through a pipeline. In terms of leak detection, the program runs based on operating pressure of their pipelines - information they keep in their database - and if the model runs and does not follow their current operating pressures, they further investigate. The program is primarily used for assigning pressures and pipeline safety.
To create these models, the team would extract data from their Pipeline Open Data Standard (PODS) database and convert it into text.
These models were each taking 1-2 months to create, so Patrick was tasked with automating the process.
That month-long process used an engineering application called Synergi Pipeline Simulator (SPS). The models generated by this program were structured in a text-based format called an INPREP file; these tracked the user’s feature creation such as pipelines, valves, and pump stations on a planar canvas. These files could be created visually in the SPS application itself or created via text, and required users to not only input the spatial component but the attributes of each module.
Caption for the photo:
“SPS provides hydraulic profiles for both transient and steady state pipeline operation. The model configuration is flexible to allow changes in pipe geometry allowing various case studies to be performed.”
Patrick replaced this manual process by creating an FME workflow that automatically combines data from their attribute-rich PODS database with spatial data from their GIS, and converts it into the text-based format that is required by SPS.
Here is an example of their input: spatial data in ArcGIS
This is Patrick’s workspace
This is Patrick’s workspace
This is Patrick’s workspace
This is Patrick’s workspace
This is Patrick’s workspace
And this is a sample of the output text file. The data placed into these text files includes pipeline specifications, on line facilities (valves, pumps, outlets) as well as a dynamically generated elevation profile for each line.
And this is a sample of the output text file. The data placed into these text files includes pipeline specifications, on line facilities (valves, pumps, outlets) as well as a dynamically generated elevation profile for each line.
This is an example graph of how the actual models are used. This graph shows pressure, flow rate and batches along the pipeline length.
With some adjustments and slight modifications, the accuracy and standardization of the placement of pipelines and their attributes is more accurate than it was before. Patrick’s team agreed that the reliability towards leveraging Plains Midstream’s PODS database has been a great benefit and saved them from having to draw out attribute and data manually.
Now that FME is in place, the hydraulic engineering team only have to wait about 1 - 2 hours, depending on the complexity of the pipelines that need to be joined together, to create a functioning system vs. a model that could have taken over a month to complete.
And once the skeleton model has been generated, the engineer’s only job now is inserting fluid dynamics information and the actual analytical portion of the task instead of having the burden of creating a new model from scratch each time new assets are required for hydraulic modeling.
Also a great value addition to this project was to leverage their PODS database to help populate the attributes of the pipeline where the data has ensured accuracy.
The ListBuilder, Sorter, and Concaternator were used to create multiline attributes (thousands of lines in one attribute to create an elevation profile).
ExpressionEvaluators enabled Patrick to create scaling factors.
The StringConcatenator was used to mimic the script syntax and create a repeatable step to ensure future models would not fall victim to simple syntax error causing failure of the models.
Patrick had previously viewed FME as a tool used to manipulate spatial and tabular data but with this project, Patrick saw a much greater scope of functionality for FME that’s not as limited.
He says “This task has felt like I was programming for another language and this was an application that was a guide for it.”