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



код для вставкиСкачать
Model Design for Agent-based Simulation
H.P.M. Veeke
J.A. Ottjes
Delft University of Technology
Dep. 3mE
Mekelweg 2
2628 CD Delft
+31 15 278 2706
Delft University of Technology
Dep. 3mE
Mekelweg 2
2628 CD Delft
+31 15 278 3418
This paper describes the complete modelling process for
simulation, starting with the identification of agents and
ending with a clear and unambiguous description of their
behaviour that can be easily translated into each processoriented simulation platform. It focuses on the definition of
agents, a subject which is described rarely. Agents usually
“are there”, emerging from the things one can see. Defining
agents however, determines completely the range and
content of a simulation and is not a trivial case. After a
deliberate definition of the agents, a natural way to describe
their behaviour is presented. These behaviour descriptions
match the real process interaction approach. The described
method is developed for educational reasons in order to teach
discrete event simulation in a non-mathematical way, but is
rather complete, coherent and well-defined.
CCS Concepts
• Computing methodologies~Simulation types and
In this paper the approach is illustrated with the design of an
automated container terminal in Rotterdam([8]).
Process Oriented;
At Delft University of Technology two independent
developments occurred during the last 40 years. In the field
of Industrial Organisation a systems approach has been
developed which is unique in its consistency and coherence.
It defines an abstract representation of any entity with a
purpose (which can be approached as a “system”) and is
currently known as the Delft Systems Approach (DSA)
([1],[2]). Parallel to this in the Mathematical Department, the
real process-interaction simulation approach ([3]) was
implemented in several general programming platforms (like
PL/1, APL, Pascal and Delphi) ([4],[5],[6]), and even had its
own compiler (Prosim)([7]). Nowadays both approaches have
been combined which resulted in the Delft Systems and
Simulation Approach (DSSA). It combines the structuring of
industrial/logistic problems and describes the behaviour of
these structures (systems). The elements in the structures can
be completely represented by the “agent-concept”. DSSA
covers the design of any discrete event simulation model
according the real process-interaction method.
Systems Approach;
Event Simulation
G. Lodewijks
Delft University of Technology
Dep. 3mE
Mekelweg 2
2628 CD Delft
+31 15 278 8793
Agent; Discrete
DSSA is based on a number of paradigms that come from
literature on systems theory. The first and far most important
paradigm states that “each system can be completely
described by its structure and its behavior” ([9]). This
paradigm has been the base for combining DSA with
process-interaction simulation, where DSA describes the
structure and Process-Interaction describes the behavior .
Traditionally discrete event simulation has been developed
and taught as an addition to Operations Research. Whenever
analytic calculations were not sufficient or even impossible
to apply to a problem, simulation appeared to be the last
resort. Nowadays simulation has become a quantification
method on its own, and is applied in almost any part of
industry and science. Courses in Simulation are taught
independently of Operations Research courses, and by this
the relation between mathematical modelling and simulation
modelling has disappeared. The focus of simulation courses
(and literature) is mainly concerned with the definition of
stochastic input and the validity of the results. The quality of
the model itself representing a real problem is rarely
The next important paradigm is from de Leeuw([10]): “Every
system with a purpose consists of an operational and a
control part”. This distinction is a principle in DSA, where
the material flow (aggregated or detailed) should be
controlled by control echelons explicitly. For the behavioral
description, the operational part of a real-life industrial or
logistic system can be observed physically, the control part
often cannot, but is essential for a correct behavior.
The first step in the design of a simulation model for
complex situations is defining the “system” and then discover
the structure in order to unravel the complexity.
Permission to make digital or hard copies of all or part of this work
for personal or classroom use is granted without fee provided that
copies are not made or distributed for profit or commercial advantage
and that copies bear this notice and the full citation on the first page.
Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee. Request permissions
ICCMS’17, January 20-23, 2017, Canberra, Australia.
© 2017 ACM. ISBN 978-1-4503-4816-4/17/01…$15.00
Every model according DSA starts with a single “black box”,
representing the borders, product flow, requirements and
kpi’s of the “system under consideration”. The black box as
a whole represents the “function”, which addresses the
contribution/role of the system in its environment. For a
container terminal to be designed this black box looks like
terms of functions that we will call “agents” from now on.
So there is a Service Agent, a Transfer Agent and a Use
Agent, each with its own kpi’s. At this level a simple
simulation model could highlight the sensitivities and
dependencies between these kpi’s, but we will zoom into the
Agents one step further now to show the agent- process
Structure decomposition in order to deal with the complex
situation was done along the line of the different viewpoints
involved so far. Now we focus on the ‘Transfer’ aspect and
investigate the actions in the container flow further (in terms
of DSA we zoom in, to see the subsystems). On a container
terminal there are two main sides: seaside (for ships) and
landside (for trucks and trains); the input side and output side
are decoupled by a stack. Showing both sides + stack and
adding the projected equipment for each part of the Transfer
(in the lower right corner of the rectangle) results in Fig. 3.
Fig. 1. Black box of a container terminal
Depending on the problem-owner, a different viewpoint may
be appropriate for describing the system. In practice three
viewpoints are very common:
the product flow as shown in fig. 1
the order flow (sales and daily orders), without
which nothing would happen
Figure 3 shows the ideas of the design team for the
Storing/Retrieving activities were planned to be automated.
We could define agents, one for Seaside, one for Landside
and one for the Stack, and this also reflects the management
teams that were actually formed during the design project
(and in actual operation). These agents take “only” decisions
and are mostly modeled in a way that taking a decision takes
no time.
the resource flow (machines, employees), without
which nothing could happen.
For design purposes all three (interrelated) viewpoints or socalled “aspects” are important. This is shown in figure 2.
Modal split
Dwell times
Port times
Service times
Net oper. Hours
Terminal Control
We can describe their functionality in one sentence as:
Seaside: Decide which containers to (Un)Load
to unload
Stack: Decide how to store containers
LandSide: Decide which containers to (Un)Load.
Decisions are made according the standards being formulated
in Fig. 3. At this level one should not start with optimization,
but with determining the results to be achieved (in other
words: set the required kpi-values). Here a decision is already
made about the equipment to be used, and the main question
is to use this equipment in an efficient way.
Fig. 2. Container terminal with 3 interrelated viewpoints
Looking at the equipment mentioned in the lower right corner
we can describe their functionality again with one sentence
each. Restricting ourselves to the seaside unloading process it
would be like:
Every aspect is represented as a black box according Fig.1,
with one major difference: There is an overarching control
required to coordinate the requirements and kpi’s of each
aspect; In fig.2 this is called Terminal Control. For the order
(Service) aspect the kpi’s will usually reflect the quality of
service to the customer, for the operation aspect (Transfer)
they will focus on productivity, while for the resource (Use)
aspect the main interest will be cost, reliability and
Quay Crane: Unload containers from a ship
AGV: Transport containers on seaside
ASC: Store containers into stack
By this we introduced 3 “new” Agents within the SeaSideAgent. In order to provide these Agents with standards for
their operations, simulation can be used at this aggregation
It is important to notice that a global image of the terminal as
fig. 2. already raises a number of questions that designers
should take into account, related to each other with one and
the same goal: design a terminal that fulfills the requirements
as stated in fig.1 (with the addition that it should be
automated as far as possible). The questions can be stated in
QC = Quay Crane
AGV = Automated Guided vehicle ASC = Automated Stacking Crane
SC = Straddle Carrier
Fig.3 Container Transfer
It is mainly focused on dimensioning the equipment types.
Under certain assumptions like number of quay cranes per
ship and their cycle times, one could derive the relation
between the cycle time and the number of AGV’s and decide
on their required cycle time (speed, acceleration, distance).
Analogously simulation could be used on the relation
between cycle time and number of ASC’s and decide on their
required cycle time (speed, distance, pile height). These
requirements could be completed by the required response
time of ASC’s to the AGV’s. So simulation can be very well
used here already to refine the technical and logistical
Cycle = sample of ASC cycle time
Select AGV
Move to AGV in 0.5 * Cycle*)
Unload AGV in y seconds
Resume AGV
Store container in 0.5 * Cycle*)
Taking into account a limited number of vehicles and cranes
we describe the behavior in a more detailed paragraph-like
way as in the table below.
From the table it becomes immediately clear why we use
simulation: the cycle times vary and depending on this
variation, the number of vehicles and cranes, the response
time and area provisions depend. In the table, it is assumed
the cycle times are split in two equal parts to drive to and
drive from a loading/unloading position. However, in order
to understand the synchronization between the different types,
we have to be more specific on how an ASC or Quay Crane
signals that there is no AGV waiting etc.
Table 1. Rough description of behavior
Work sample of QC’s cycle time
Wait while no AGV’s waiting
Load first AGV in x seconds
Resume first AGV
Select QC
Cycle is ‘sample of AGV’s cycletime’
Drive 0.5 * Cycle *)
Wait for QC
Select ASC
Drive 0.5 * Cycle *)
Wait for ASC
Wait while no AGVs waiting
We will now investigate the different time-consuming
activities, in order to describe the behavior in more detail. So
we investigate the Agents (“subsystems”) one level deeper,
and arrive at the technical equipment. When we restrict our
therefore be aware of all time consuming activities and
decision making of a random individual AGV and describe it
as one behavior..
modeling again to the import at seaside and zoom in one step
further, we get Fig. 4.
The functional view of DSA leads to an overview of the
functionalities that are required for the Transfer as a whole.
In this case not only Unload-, Transport- and Store-functions
are required but also two transfer-functions, between Quay
Crane and AGV and between AGV and ASC, because the
design had already decided to split the three main functions
over different types of equipment (during the start of this
millennium the authors were involved in a European project
where all three functions were combined in one type of
equipment [11]). It is here up to the design team to which
equipment these functions are assigned. In this case it was
decided to let Quay Crane and Automated Stacking Crane do
the transfer.
Each Agent can be in three states: Active, Suspended or
Scheduled (see Fig. 6). As long as there are no state changes,
the so-called Sequential Mechanism (SQM) skips (simulation)
time. The sequential mechanism is nothing more than a list of
Agents, sorted on time and condition. Whenever an Agent is
active it can communicate to SQM that nothing will change
until some moment in time is reached or a condition becomes
true. SQM merges the Agent into the time list and the Agent
which is in front is made Active and the clock is set
accordingly. When an Agent proceeds without any indication
of the time it will need to become active again, it is “parked”
aside, its state becomes Suspended and some other Agent has
to start or resume this Agent again. All state changes are
shown in fig. 6.
Fig.4. Container Transfer on import seaside
Equipment should be “assigned” to the Operation and it is
collected in an “Assigned” set. Zooming into the AGV
‘Transport and Assigned’-functionality, we finally get fig.
5.From fig. 5, one can easily describe the “behavior” of an
AGV. The upper part represents the physical operation of the
AGV as a part of the total Transfer-function of Fig.2, or more
particularly the Transport function of Fig.4. The lower part is
part of the Use-function and represents the triangle
“Assigned” of Fig.4.
SQM =Sequential Mechanism
Fig.6 Sequencing Mechanism for Agents
The behavior of the Agents Quay Crane, AGV and ASC will
now finally be described including detailed synchronization.
In table 2 ‘Proceed” has still been replaced by more
expressive terms like Wait, Lift, Drive. Doing this improves
the readability of the Agent behavior, and enables true
involvement and discussion over the behavior descriptions
with laymen in simulation. It benefits the credibility of the
Fig.5 AGV-Agent functionality
Each AGV-Agent will start at the lower right function “wait
for job”. As soon as it has a job assigned (in this case a job
like: “get a container from Quay Crane-Agent x and deliver it
at ASC-Agent y”) it drives to the Quay Crane- Agent and
waits there. After it has received a container from the Quay
Crane-Agent it transports the container to the ASC-Agent y
and waits there until the ASC-Agent has picked up the
container. From that moment the AGV-Agent is available for
a next job.
We explicitly use AGV-Agent, Quay Crane-Agent and ASCAgent to denote that every Agent of e.g. type AGV follows
the same behavior-description, only on different moments
and different variable values. So Agent is more a type
indication than an object indication. The modeler should
making on the structure of the systems is supported. The
same possibilities arise at the simulation field for behavior
design. Tactical decision making is supported by tangible
agents representing equipment, but also by intangible agents
like Seaside, Stack and LandSide, functions that were readily
available from the Delft Systems Approach. So not only
(technical) equipment can be simulated, also functions that
represent decision making show a behavior that can be
modelled and simulated, even if they are not “timeconsuming”. The real process interaction approach supports a
natural way of modelling which closely matches structure
modelling, and allows a reliable verification of the modelled
structure and dynamics.
Table 2. Detailed description of behaviour
Wait Until Moored_Set is empty
Remove First Ship from Moored_Set
While there are ContainerJobs in Ship_Jobs
Remove first Job from Ship_Jobs
Unload Container of Job from Ship
Wait While AGVQC_Set is empty
myAGV  First AGV in AGVQC_Set
Remove myAGV from AGVQC_Set
Put Container on myAGV
Resume AGV Now
[1] in ‘t Veld, Prof. J., “ Analysis of organisation problems”,
Wolters-Noordhoff bv, Groningen, 8th edition, ISBN
90-207-3065-7, 2002
Enter Assigned_Set
Wait for NextJob
Drive to QuayCrane x
Leave Assigned_Set
Enter AGVQC_Set
Drive to ASC y
Enter AGVASC_Set
[2] Veeke, HPM, Ottjes, JA, Lodewijks, G, The Delft
Systems Approach, Springer, ISBN 978-1-84800-176-3,
[3] Zeigler, B.P., H. Praehofer, and T.G. Kim.“Theory of
Modeling and Simulation”, Academic Press, San Diego,
2000, ISBN 0-12-778455-1
[4] Sierenberg, R.W., de Gans, O.B., “PROSIM text book”,
lecture notes Delft University of technology, Delft, 1982
[5] Ham, R.Th. van der, “ Must: Simulation Software User
and Reference Manual”, version 5.50, Upward Systems,
Rijswijk, The Netherlands, 1992
Wait While AGVASC_Set is empty
myAGV  first AGV from AGVASC_Set
Remove myAGV from AGVASC_Set
Lift Container from myAGV
Resume AGV
Drive to Stack_Position
Put Container on Stack_Position
Drive to SeaSide of Stack
[6] Veeke, H.P.M., Ottjes, J.A., “TOMAS: Tool for Object
oriented Modelling And Simulation”, Proc. Of
Business and Industry Simulation Symposium,
Washington, Ed. Maurice Ades, pp. 76 – 81, 2000
[7] Prosim B.V., Prosim Modelling Language
Tutorial, ,Zoetermeer, The Netherlands, 2005
[8] ECT, “Project programma MSS, ECT-Sea-Land Deltat
Terminal”, internal report MSS 115, Europe Combined
Terminals, 1988,l
A Quay Crane has to wait for a ship to arrive and moor. Once
moored the ship enters the Moored_Set and this is signaled
by the Quay Crane because the Moored_Set is not empty
anymore. As long as there are Container_Jobs in the
Ship_jobs-set, it continues to unload containers. After each
unloaded container it waits eventually for AGV’s to arrive in
the AGVQC_Set. The first AGV in the set (myAGV) is the
one to receive the container. It is removed from the set and
“kicked” (Resume) to continue its own process etc.
[9] Bishop, P.C., Hines, A., “Teaching about the Future”,
Springer, ISBN 978-0-230-36349-6, 2012
[10] Leeuw A.C.J. de, “Bedrijfskundig management
(Business management)”, Van Gorcum, 2000
[11] Pedersen, J.T., Ottjes, J.A., Veeke, H.P.M., “A
revolutionary concept for intermodal transport, Research
Report, research funded by the European Commission
under the Transport RTD programme, sub area
“Transport”, Contract No WA-95-SC-140,1999
The three Agent processes can be easily translated into each
simulation tool that is based on the real process-interaction
method. The only thing left for the modeler is to obey the
syntax of the programming tool of his/her choice.
In this paper we started with a widely accepted way of
modeling industrial/logistical operations by considering them
as part of a system, that consists of “functions”. This
“function”-concept, which is typical for the Delft Systems
Approach, appeared to coincide with the Agent-concept,
which is common for simulation approaches.
Moreover, DSA details its models by using the property of
recursion. By this, strategic, tactical and operational decision
Без категории
Размер файла
363 Кб
3036331, 3036335
Пожаловаться на содержимое документа