вход по аккаунту



код для вставкиСкачать
Proceedings of the 2016 11th International Pipeline Conference
September 26-30, 2016, Calgary, Alberta, Canada
Birgit Juergensen
Stream Systems Ltd.
Calgary, Alberta, Canada
Ivan Ewanicke
Stream Systems Ltd.
Calgary, Alberta, Canada
Thomas Xi
Stream Systems Ltd.
Calgary, Alberta, Canada
The problem of identifying and forecasting potential
scheduling conflicts and the impact to quality and delivery
targets is a very real and complex problem. The most effective
way to meet the above business objective is to develop a
terminal simulation model that combines elements of a mass
balance system (MBS), operational rules/procedures and
operator behavioral patterns.
Last year a Canadian Midstream company faced a big
challenge with one of its new planned pipeline terminals: In
light of the recent oil price drop the capex for this new terminal
needed to meet a certain return on investment (ROI) which
could only be achieved by moving away from the well proven
approach of a terminal with full connectivity to a design with
more shared terminal elements like meters and tank lines.
Several options were explored all showing potential to reduce
This paper is a case study describing the approach in
designing a detailed pipeline tank terminal simulation model
with an objective to identify and quantify complex and possibly
unresolvable operating conflicts/events occurring given a
current pipeline, tank or terminal configuration and then
comparing this with other configuration options. In addition,
the model will be able to measure quality impacts (measured by
quantifying the volume of degraded product) that results from
resolving the operating conflicts for each evaluated
But this approach left the scheduling team with the question of
whether they would be able to operate this new terminal to the
shippers’ expectation of overall throughput and quality
adherence. The terminal was too complex to validate future
operations in spreadsheets. Hence they turned to simulation to
check the validity of the proposed design options.
This paper discusses the design of the terminal model
using three different modelling techniques - Discrete-Event,
System Dynamics and Agent-Based simulation. This paper will
also discuss challenges faced with the model design, the
validation approach taken to bridge between the known
operation of existing terminals and future operation of the new
terminal as well as some of the key insights the validated and
verified model provided.
We will demonstrate how the resultant model allows a
terminal operator to effectively understand quality impacts to
batches delivered through the pipeline tank terminal as a
function of operational procedures and system configuration
Copyright © 2016 by ASME
Downloaded From: on 10/25/2017 Terms of Use:
System Dynamics
Simulating midstream operations has been a challenge for
a long time because of the complexity of a system with
multiple decision components, like batches, multiple
commodities, several routes per commodity and source or
destination, multiple tanks and sequencing options. One
approach has been to use decision trees to answer business
questions like finding a feasible schedule for batches through a
terminal. Because of the multiple variables and the time
dependency the resulting model options often exceed billions
of possible solutions. This makes the resulting models slow in
run time and difficult to interpret and maintain. The midstream
business context is constantly shifting, requiring a more
flexible and easier to use and adopt approach.
System Dynamics aims to model complex systems in order
to analyze their general behavior using a top-down modeling
approach based on stocks, flows, feedback loops and time
delays, in order to simulate the complex interactions between
the components of a system. In other words, System Dynamics
aims to capture the ripple effect of changes to these
components throughout the entire system, in order to model
and study the resulting non-linear behavior of the system.
System Dynamics only models the mutual dependencies
between these components. It does not model the elementary
interactions between the individual elements of the system,
which is what Agent-Based Simulation aims to model and
Other approaches have been using Discrete Event and/or
System Dynamics in one model. The resulting models are still
rigid and require a simulation expert to add new equipment or
change route options for an experiment. Each change to a
manifold layout or tank line set up can take days to configure
and more days to test and verify. This does not support the
business objective to facilitate terminal design decisions by
allowing the customer to use the model to quickly check
various design and business rule options.
Agent-Based Simulation
Agent-Based Simulation is an emerging simulation tool
[1], which takes a bottom-up approach to model the individual
behaviors and interactions of a system's elements, referred to as
agents. Therefore, instead of modeling the relationships
between the components in a system, Agent-Based Simulation
captures how the individual elements of a system behave with
respect to their own local environment and state, and how they
interact, communicate, make collective decisions, or influence
each other. The Agent-Based Simulation modeling paradigm
uses theoretical models to capture individual behaviors. [2]
In order to quickly verify the impact of various design
options the customer needed a model and user interface that
represents the physical aspects of the terminal
(“steel component”)
addresses varying flow rates (to balance between
different flow rates of inbound and outbound
takes operating rules into consideration,
allows the users to easily add, change or delete a
physical terminal component
supports the user to set up scenarios and compare
their outputs and
is fast to configure and fast to run (< 1 minute
per run covering 1 year)
Using models with agents allows the deconstruction of the
overall model architecture into smaller independent
components each with their own rules. This makes the model
more flexible, easier to maintain and faster to run. It also
tempers the rigidity of the Discrete Event and System
Dynamics model types.
Specifying a model is not a simple task in itself let alone
making it suitable for predictive analytics [3]. It requires an
analysis of what system elements are essential to the business
question at hand as well as consideration of which simulation
approach to use for each model element. In addition, the
availability of data for verification and validation has an impact
on the model design.
To address all aspects of the model requirements three
simulation techniques were combined in the terminal model:
Discrete-Event, System Dynamics and Agent-Based simulation.
Each method is described below:
Physical Terminal Components
Discrete-Event Simulation
For this particular project the scheduling team was most
interested in the overall terminal throughput, the number of
scheduling conflicts in the terminal and the utilization of
critical components. As a result, the following physical
components and logical elements were included in the model:
Discrete-Event Simulation aims to create simulation
models of queuing-type systems, in which time moves forward
either by equal time increments or from one event to the next.
Events and flows between system components occur according
to known probability distributions specifying processing and
transit times and priority rules.
Copyright © 2016 by ASME
Downloaded From: on 10/25/2017 Terms of Use:
Feeder lines
Transfer lines
Tank lines
Meters & manifolds
Delivery points (pipeline and rail)
Terminal routes
Commodities & commodity groups
These events were combined with monthly nomination
information and typical scheduling rules to build an auto-batch
scheduler within the model. This feature creates an input and
output batch sequence for each run, making it easy for the user
to set up and run different volume cases and avoiding manual
run preparation time building a feasible batch schedule for each
All physical components were built as agents with given
parameters like flow rates, capacity, etc. Statistical parameters
like batch size variation were added to be able to address the
sensitivity of changes to current or future operations.
System Dynamics
In an oil terminal nothing moves until there is volume to
push a batch through the system. This could be a feeder line
pushing a batch through the terminal components to a tank or a
delivery location or enough volume in a tank to push a batch
that sits in a delivery line out to its next delivery location. This
behavior impacts the utilization of terminal components (both
in time used and volume moved) and the quality of the batches.
E.g. a batch could be starting to move into a terminal tank, but
until there is another batch behind it that finishes moving the
landing to the tank the batch landing will not complete.
Components of the terminal like tank lines, meters and transfer
lines could be blocked for other movements creating possible
scheduling conflicts. In addition, the batch moving through the
terminal will pick up some batch elements from previous
batches that used the same route (e.g. the same tank lines). The
latter impacts the landing quality of the batch in the tank. The
same effect takes place on the injection move out of the
terminal. Degradation because of tank line fill in the shared
lines was one of the biggest worries the operation team had
about the proposed terminal design.
Agent-Based models are well suited to be combined with
other simulation techniques like Discrete-Event Simulation that
is required to model the arrival schedule and other events
described below. Another strength is their capability to include
the fluid dynamics needed to address the utilization and quality
aspect of this project. [3]
Figure 1 shows the key physical components of the
terminal modelled.
Figure 1: 3D Representation of the Terminal
In order to address the resulting impact on component
utilization and quality adherence this model required the
addition of a system dynamics element in the form of a fluid
library. Combining fluid like behavior with flow rates and line
fill is required to calculate the elapsed time for each maneuver
in the terminal which in turn allows determination of the time
bound utilization of terminal components.
Event-Driven Components
One of the reasons terminal modelling is complex are due
to the events taking place on a scheduled and unscheduled
basis. Traditional simulation tried to address these events with
decision trees which led to massive and unruly slow models
difficult to set up for assessing various scenarios. Integrating
discrete-event simulation with Agent-Based simulation
overcomes this challenge enabling the user to quickly set up
different batch volume scenarios to analyze future terminal
throughput combinations.
Operating Rules
Each terminal has its unique operating and scheduling
rules that can have a significant impact on the overall terminal
throughput. Defining them appropriately is the key to be able to
predict operations that deviate from current practice.
The events chosen for this model include:
Conflict logs to allow analysis of terminal
Wait lists to support routing management in the
Switches for tank quality allocation switching
Receipt schedules for the feeder lines
Delivery schedules for the delivery points
The rules chosen are based on scheduling and operating
rules described by the subject matter experts of the customer.
The following rules were selected for this particular model:
Copyright © 2016 by ASME
Downloaded From: on 10/25/2017 Terms of Use:
Wait list rule
Routing priorities
Active line management rule
Tank allocation rules
Tank quality switching rules
Tank management rules (landing, injection)
Scheduling conflict rules
Meter allocation priorities
Quality calculation for Sulphur and density
The model was designed with a simple user interface that
provided functionality to manage user inputs, various scenarios
(experiments) and numerous reporting options. The design of
the user input and output interface was driven by the
requirements mentioned in the previous chapter as well as by
anticipated use cases and verification steps.
Figure 4 below shows the input screen supporting the
management of projects and scenarios:
Figure 2 below gives an example of the interaction of the
discrete events (generated individual batches) with key rules.
(available routes, available space in the tank, conflict resolution
and waitlist).
Figure 4: Input Screen to manage projects and scenarios
Figure 2: High Level Model Flow Diagram for Batch
The following list provides some examples of the
anticipated use cases that were guiding the design of the user
input interface and the user output interface:
The combination of the different simulation approaches
provides a very flexible model architecture that supports future
component additions and switching of operating rules for
different scenarios. Figure 3 below shows a requirement
diagram for the tank commodity switching rule. This rule is
activated when the commodity assigned to a tank is changed
either because of a scheduled event or because of another rule.
Figure 3:
Example of a Rule Logic- Switching
Commodities in a tank
Create a new scenario with a different tank line
Create a new scenario with different nomination
volumes including percentage shifts between
commodity groups (like sweets and heavies)
Create a new scenario with increased volumes to
determine maximum throughput threshold
Create a new scenario with different meter
manifold configuration in bound or outbound
Change possible routes for a commodity
Set up a scenario to test how quickly the tanks in
the terminal can be filled to 80% capacity (or
emptied from 80% capacity)
Set up a scenario with the line management rule
Key parameters like terminal throughput, number of
scheduling conflicts, logs of batches moving through a terminal
component, utilization etc. were also incorporated in the model
run time interface to support the verification and validation
process. The model itself can be run at different “speed” levels
allowing the user to observe the simulation in slow motion or
in high speed mode. This interface allowed quick verification
of model changes by the developers and the testers.
Figure 5 below is an example of the model user interface
feature managing feeders and commodities per feeder.
Copyright © 2016 by ASME
Downloaded From: on 10/25/2017 Terms of Use:
Figure 5: Input Data Example - Batch Source Detail
Other charts and views were created to allow the analysis
of a particular model run or to support the comparison between
model scenarios. Figure 7 provides an example of a chart
comparing the number of scheduling conflicts on the receipt
side of the terminal between two scenarios.
Figure 7: Receipt Conflicts Comparison
Tools supporting the analysis of the model results are run
time graphs in the model as well as pivot tables and graphs
based on the run logs. Fig. 6 gives an example of the latter.
Typical data required for the validation of the model and
the comparison of scenarios are:
Total input and output volumes for the terminal,
per feeder and delivery location
Utilization per tank (volume)
Utilization of terminal components like meters
and transfer lines (time)
Quality change in sum and per batch
Number, timestamp and type of scheduling
Drill down capability to batch level, timestamp or
Ability to follow a batch through the terminal to
the delivery destination
Time related views, e.g. to land a batch, feeder
shut downs, batch hold times
This project followed the same verification and validation
process at outlined in an earlier paper [4]. All components were
unit tested in isolation first checking each versus expected
outcome. Once all physical components were verified in
isolation the business rules were added and the model was
verified on a system level. This verification included a
functionality test to prove that the user interface supports
adding, removing or changing terminal components and rules
of the model.
Key verification aspects at this stage focused on checking
the behavior of the:
Figure 6 is an example of a pivot chart used to analyze a
model run and illustrate tank utilization results.
Figure 6: Output Example Tank Utilization
Schedule generator
Wait lists
Tank behavior and flexibility
Line fill behavior
Route selection
Quality change of the batches
This step focused on checking that the rules were triggered
and executed as expected and worked together as described by
the terminal subject matter experts. Each time a new rule was
added, the interaction between all rules was regression tested.
To address the challenge of verifying a terminal not yet in
operation it was decided to model an existing terminal first and
verify and validate it with existing operating data. The
customer provided information about several past nominations
periods (months) and was part of the validation process,
Copyright © 2016 by ASME
Downloaded From: on 10/25/2017 Terms of Use:
comparing the model results with observed outcomes.
Validation determines the accuracy and confidence level of a
without fundamentally disrupting the logic of the other model
Intensive testing of the impact of the shared tank lines
included the detailed review of each volume that contributed to
the batch composition in the tank and at the delivery point.
Several batches were followed through every component of the
terminal including summary checks for weighted average
density, volume and Sulphur balances. One outcome of this
testing was that the batch quality calculation rule had to be
redesigned to incorporate the mini-batches from the shared tank
Key validation criteria were:
Overall terminal throughput
Meter utilization
Tank utilization and tank turns
Batch hold times in the tank
Batch arrival frequency per feeder
Nomination target
Quality impact through the terminal
Number and types of terminal conflicts
The validated model was used to run several business
scenarios. It did confirm that the new terminal design met the
throughput and conflict expectations. None of the utilization of
key components like meters and transfer lines exceeded
feasible operation parameters. The quality changes were within
the allowed range on average, but showed quality violations on
the detailed batch level. The fluid library of the model allowed
to model each batch interaction through the terminal including
the pick-up of high Sulphur level crude by sweet crudes in the
shared tank lines resulting in off spec delivery for some of the
sweet crude batches. This emphasizes the importance of
choosing the right abstraction level when designing a model.
In addition, the model was stress tested with corner cases
like how fast the terminal could be filled, how fast it could be
emptied and run time performance. This also included cases
with mismatched inbound and outbound volumes etc. If the
model started empty (with no line fill and no volumes in the
tanks at the start) the “warm up period” to get the model to a
steady state took about 30 days. This period was excluded from
the data collection used for the output analysis. The model was
able to finish a run covering a year in less than 1 minute
allowing for hundreds of model runs to verify performance and
expected outcome. Some scenarios focused on shorter periods
like specific summer or winter months.
As a result of the first model runs the design of the
terminal was adjusted to address the quality issue and tested
with the updated model. It became an iterative process resulting
in new model components like new meter manifold set ups,
new business rules such as tank line management, the priming
of lines and the expansion of the model boundaries to include
delivery transfer lines. During this process the bottlenecks
shifted. While in the first approach only quality was determined
as a bottleneck, later stages now revealed an overutilization of
certain meters and tank lines. The final design was chosen after
stress testing the terminal design with several volume cases
(variation in overall volume and shift between heavy sour and
light sweet crude).
One challenge faced at this stage of the project was the
availability of consistent operational data to verify and validate
the model. Operational data tends to come from different
source systems that capture different time frames, have
inconsistent meta data or are manually recorded. Hence finding
a period with consistent complete clean data is often
The solution to this challenge lies in using a pattern or
statistical approach. E.g. rather than running a specific batch
schedule, derive the typical batch characteristics such as the
batch size distribution from operational data and test versus this
pattern. The resulting accuracy level of more than 90% tends to
be good enough for future scenarios as the assumed input data
will not be of higher accuracy. This approach assumes that
several simulations are run to provide a high confidence level
of the predicted outcome space.
By varying single input values and assessing the impact to
the output the user was able to determine how sensitive the
terminal design was to operational input changes like volumes
changes or rate changes.
Once the simulation for the existing terminal was verified
and validated the model was then adjusted to reflect the new
terminal. Most components and rules followed the same
principle requiring only basic reverification and revalidation.
The most important new component incorporated was the
principle of shared tank lines. The flexible underlying
architecture of the terminal model allowed this rule to be added
By varying the range of the statistical elements like batch
size or batch frequency distribution the user was able to test the
robustness of the terminal design. Checking the utilization of
key components provided input to further design review by
identifying necessary and underutilized terminal components.
Copyright © 2016 by ASME
Downloaded From: on 10/25/2017 Terms of Use:
The flexible model architecture ensured that model
additions could be incorporated on a tight schedule keeping
pace with the stage gates of the project.
bridge between the engineering design and operational
execution allowing to predict future operations of a green field
or brown field assets. This approach can also deal with the
iterative nature of project developments in pre-FEED or FEED
Incorporating agent based components is the key to
creating faster and more flexible models addressing typical
midstream questions. It opens the opportunity to apply concepts
of gamification that have already proven very successful in
areas like education and training.
As the model grew through the different stages of the
project some components that were fit for purpose for the first
stage had to be rebuilt when new business rules or components
were added. E.g. with the addition of a tank line management
rule the calculation of the quality impact to the batch in the
tank had to be changed. The quality of the delivery batch had to
be adjusted as soon as the priming of a transfer line rule was
added. This rule ensures that a delivery batch has no tank line
fill or transfer line fill element pick up.
[1] Mascal, M. Macal and North, Michael J., Introduction
to agent-based modeling and simulation, MCS LANS Informal
Seminar, November 29, 2006
Another challenge was the representation of the meter
manifolds. These act like an incoming batch sorting agent with
specific rules for which batch can come to this gate and which
route it can take through the terminal. The first design assumed
meters could never be split resulting in a rigid design. This
design made adjustments to other meter set ups difficult and
consequently had to be completely redesigned.
[2] Gil, Alvaro, Gil and Frayret, Jean-Marc, Log
classification in the hardwood timber industry: method and
value analysis, International Journal of Production Research,
[3] Helbing, Dirk and Balietti, Stefano, How to do agentbased simulations in the future: From modeling social
mechanisms to emergent phenomena and interactive systems
design, SFI working paper 2011-06-024
Model changes are part of testing a new model design in
an agile environment. They happen even without project
iterations. Deciding which model approach is the right one for
any given problem is very often trial and error.
[4] Lin, Frank and Chegus, Allan and Cernelev, Dumitru,
Verification and validation of pipeline terminal simulation
models, IPC2014-33350
A simulation model for a terminal with flexible
architecture incorporating several simulation techniques can
Copyright © 2016 by ASME
Downloaded From: on 10/25/2017 Terms of Use:
Без категории
Размер файла
1 579 Кб
ipc2016, 64531
Пожаловаться на содержимое документа