| | Chapter 6. Performing the SimulationHaving the network description and the routes you have everything to
perform a simulation. The fastest way to get results - their different
types will be described within the following sub-chapters - is to use the
SUMO - command line simulation. This command line tool does not generate
any graphical output as the SUMO-GUI does, but is much faster in
execution. To start a simulation, you have to supply the following
information: - The file that contains the network
Use the --net-file (or --net
or -n)
<FILE> option to
pass the simulation the name of the network to use. The network must
be one build using NETCONVERT or
NETGEN.
- The routes to use
Use the --route-files (or
--routes or -r)
<FILE>[;<FILE>]*
option to specify which files shall be used to read routes from. In
this case, the name is not ambigous - multiple files can be
used.
- The simulation time the simulation begins at
This is the first time step the simulation has to perform. Be
aware, that this time should fit to the time your routes start. Pass
it to SUMO using --begin
(or -b)
<INT> where
<INT> is the time
step in seconds.
- The simulation time the simulation ends at
This is the last step of the simulation. When this time step is
reached, the simulation will end. Pass it to
SUMO using --end (or
-e)
<INT> where
<INT> is the time
step in seconds.
All these values must be given in order to perform a simulation.
Still, no output is generated. Generating output is described in the next
chapter. Besides this, there are also some other additional structures
which may be applied to the simulation scenario and of course there are
some more questions to answer about inserting vehicles into the
net. Due to its scientific purpose, SUMO tasks lie beyond simple
visualisation of traffic. The results of a simulation must be available
and one must be able to process them and furthermore possibilities to
influence the simulation are necessary to make it more variable in use.
Detectors, artifacts used to gain more or less processed results from
the simulation and some further structures used are described in the
next subchapters. To supply the definitions of these structures to the simulation,
we use an additional file normally and pass it to "SUMO" using the
--additional-files (-a) - option. Each
of these files may contain all the definitions about additional
structures such as detectors, emitters etc. in random order. The results are obtained from the simulation using simulated
detectors. You will find detectors one knows from the real world such
as induct loops, but also some virtual ones that allow gaining values
one can work with more easily. Basically, the main distinction between detectors SUMO offers is
their dimension. The next list shows all available detector types,
some of which are still under development. The type names "E*" have
their origin in the German word "Erfassungsbereich" meaning "detection
area". - E1: Induct loops
Induct loops have a position only and no dimensions. They
are meant to be a slice plane through a single lane and measure
only the vehicles passing them.
- E2: Areal, lane-based detectors
These detectors describe a part of a lane or alternatively a
part of the network made up of consecutive lanes (a begin lane and
his predecessors). The measured values are derived from the
movements over the whole part of the network the detector is lying
at.
- E23: Route-dependent Origin/Destination detectors
... not yet implemented ...
- E3: Multi-Origin/Multi-Destination detectors
E3-detectors measure vehicles passing a set of entry and an
according set of exit points. Each of these points is a position
on a lane. Measured are values that may be derived from the
movements of vehicles between any of the entry and any of the exit
points.
- E41: Destination based detectors
... not yet implemented ...
- E42: Edgebased detectors
... not yet implemented ...
We will not replicate the exact computation of the detector's
values. A document describing this should be found on our pages within
the documentation
part. The next subchapters hold the information about how to set
detectors onto a network only. To ease the usage and for backward compatibility, all detectors
may be defined in two ways. The first one is by using the following
notation: <detector
id="<ID>"
type="<TYPE>" ...further
attributes.../>. Herein, the detector type is determined
by the type-attribute which is "induct_loop" as default. The second
possibility is: : <XX-detector
id="<ID>" ...further
attributes.../> where the tag name already defines the
detector to build. Possible values for XX
within the tag name and attributes needed to
describe each detector are described in the following
subchapters. 6.1.1.1. E1-Detectors (Induct Loops)An induct loop is defined either this way: <detector id="<ID>" type="(induct_loop|E1)" lane="<LANE_ID>" pos="<POSITION_ON_LANE>"
freq="<AGGREGATION_TIME>" [style="xml"] file="<OUTPUT_FILE>" [friendly_pos="x"]/>
or this way: <e1-detector id="<ID>" lane="<LANE_ID>" pos="<POSITION_ON_LANE>"
freq="<AGGREGATION_TIME>" [style="xml"] file="<OUTPUT_FILE>" [friendly_pos="x"]/>
The id is any string that let's you know which detector is
meant. The type indicates that a induct loop shall be build, here.
The attributes "lane" and
"pos" describe on which lane and at which
position on him the detector shall lay. As induct loop detectors may
aggregate the values they collect, the freq-attribute describes this
period. The style-parameter is obsolete by now as the earlier
possibility to use either "xml" or "cvs"-output is now not
supported, the values are stored in xml-files only. The file
attribute tells the simulation to which file the detector shall
write his results into. The file will be generated, does not have to
exist earlier and will be overwritten if existing without any
warning. ![[Caution]](images/caution.png) | Caution |
|---|
The folder the output file shall be generated in must
exist.
|
Let's review the attributes: id: A string holding the id of the
detector
type: Always "induct_loop" or "E1" for
this type of detectors ("induct_loop" is the default
value)
lane: The id of the lane the detector
shall be laid on. The lane must be a part of the network
used.
pos: The position on the lane the
detector shall be laid on in meters. The position must be a
value between -1*lane's length and the lane's length. In the
case of a negative value, the position will be computed backward
from the lane's end (the position the vehicles drive
towards).
freq: The aggregation period the values
the detector collects shall be summed up.
style: Obsolete/deprecated; Always
"xml" by now
file: The path to the output file. The
path may be relative.
friendly_pos: If set, no error will be
reported if the detector is placed behind the lane. Instead, the
detector will be place 0.1 meters from the lane's end.
Recent changes: - The attribute
friendly_pos is available
since version 0.9.4
6.1.1.2. E2-Detectors (Areal, lane-based Detectors)An induct loop is defined the following way: <detector id="<ID>" type="(areal|lane_based|E2)" lane="<LANE_ID>"
pos="<POSITION_ON_LANE>" length="<DETECTOR_LENGTH>" freq="<AGGREGATION_TIME>"
[style="xml"] file="<OUTPUT_FILE>" [measures="<MEASURES>"] [time_treshold="<FLOAT>"]
[speed_treshold="<FLOAT>"] [jam_treshold="<FLOAT>"] [keep_for="<FLOAT>"]/>
or: <e2-detector id="<ID>" lane="<LANE_ID>" pos="<POSITION_ON_LANE>"
length="<DETECTOR_LENGTH>" freq="<AGGREGATION_TIME>" [style="xml"]
file="<OUTPUT_FILE>" [measures="<MEASURES>"] [time_treshold="<FLOAT>"]
[speed_treshold="<FLOAT>"] [jam_treshold="<FLOAT>"] [keep_for="<FLOAT>"]/>
Most of the attributes have the same meaning as for induct
loops. As an areal detector has a certain length, this length must
be supplied as a further parameter. It may also be a negative number
which lets the detector be extended upstream to the given beginning
position. The type must be set to either "areal",
"lane_based" or "E2" to let
the simulation know what's desired to build. The optional parameter
"cont" let's the detector continue over the current lane onto this
lane's predecessors when the detector's length plus his position is
larger than the place available on the lane. The attribute
"measures" describes which values the detector
shall compute. The optional values are described below. ![[Caution]](images/caution.png) | Caution |
|---|
The folder the output file shall be generated in must
exist.
|
![[Caution]](images/caution.png) | Caution |
|---|
For detectors that span over more than a single edge, only
the attribute QUEUE_LENGTH_AHEAD_OF_TRAFFIC_LIGHTS_IN_VEHICLES
is defined all other may return strange values.
|
But there is also a further possibility to use E2-detectors.
If you place them in front of a traffic light, you can use the
traffic light to describe the intervals (aggregation) time instead
of giving a fixed aggregation time. In this case, output will be
generated every time the traffic light switches. To use this
feature, simply replace the freq-attribute within the description of
your detector by the id of the traffic light that should steer it
(use the attribute "tl" to specify the id)
: <detector id="<ID>" type="[(areal|lane_based|E2)" lane="<LANE_ID>" \
pos="<POSITION_ON_LANE>" length="<DETECTOR_LENGTH>" tl="<TL-ID>"
freq="<AGGREGATION_TIME>" [style="xml"] file="<OUTPUT_FILE>"
[measures="<MEASURES>"] [time_treshold="<FLOAT>"]
[speed_treshold="<FLOAT>"] [jam_treshold="<FLOAT>"] [keep_for="<FLOAT>"]/>
or: <e2-detector id="<ID>" lane="<LANE_ID>" pos="<POSITION_ON_LANE>"
length="<DETECTOR_LENGTH>" tl="<TL-ID>" freq="<AGGREGATION_TIME>" [style="xml"]
file="<OUTPUT_FILE>" [measures="<MEASURES>"] [time_treshold="<FLOAT>"]
[speed_treshold="<FLOAT>"] [jam_treshold="<FLOAT>"] [keep_for="<FLOAT>"]/>
A further feature allows you to output values not for all
switches of the traffic light the detector is attached to, but only
when the light turns red for the assigned link (connection between
the incoming and the outgoing lane). This should allow you to
measure the maximum jam length in front of a red traffic light for
this link. To switch on this feature, you have to add the name of
the following lane:
to="<LANE_ID>". The
incoming lane is already given by the
"lane"-attribute. E2-detectors may compute many different measures and the user
has the possibility to describe which measures he actually wants to
be generated. The "measures"-attribute must contain the measures
divided by a ' ' (blank) in the case he does not want to compute all
parameters. Computing all parameters is the default case but may
also be set using 'measures="ALL"' . The
available measures are: - DENSITY: The density on the detector in vehicles/hour
averaged over the requested interval.
- MAX_JAM_LENGTH_IN_VEHICLES: Every timestep, the maximum
number of consecutivly jamming vehicles is detected. These
values are averaged over the requested interval.
- MAX_JAM_LENGTH_IN_METERS: Every timestep, the maximum
length demand of consecutivly jamming vehicles in meters is
detected. These values are averaged over the requested
interval.
- JAM_LENGTH_SUM_IN_VEHICLES: Every timestep, the sum of the
lengths of all jams on the detector is measured (in vehicles).
These values are averaged over the requested interval.
- JAM_LENGTH_SUM_IN_METERS: Every timestep, the sum of the
lengths of all jams on the detector is measured (in meters).
These values are averaged over the requested interval.
- QUEUE_LENGTH_AHEAD_OF_TRAFFIC_LIGHTS_IN_VEHICLES: This
detector uses a MAX_JAM_LENGTH_IN_VEHICLES one as a helper.
Every timestep, the "maximum-jam-length" (in vehicles) from
MAX_JAM_LENGTH_IN_VEHICLES will be compared to the maximum of
"maximum-jam-lengths" that occured since the last reset. If the
new value is larger, the maximum of "maximum-jam-lengths" is
updated. Between two resets, this detector records a monoton
growing set of "maximum-jam-lengths". These values are averaged
over the requested interval. The reset is performed by a traffic
light.
- QUEUE_LENGTH_AHEAD_OF_TRAFFIC_LIGHTS_IN_METERS: As
QUEUE_LENGTH_AHEAD_OF_TRAFFIC_LIGHTS_IN_VEHICLES, but in meters,
not in vehicles.
- N_VEHICLES: Every timestep, the number of vehicles that
populate the detector is recorded. These values are averaged
over the requested interval.
- OCCUPANCY_DEGREE: Every timestep the length of the
vehicles populating the detector is summed up. We divide this
length by the detectorlength to get a value out of [0,1]. These
values are averaged over the requested interval.
- SPACE_MEAN_SPEED: Every timestep, the mean-speed of the
vehicles on the detector is calculated. These values are
averaged over the requested interval.
- CURRENT_HALTING_DURATION_SUM_PER_VEHICLE: Every timestep,
the halting-time of the vehicles on the detector is summed up
and then averaged over the number of vehicles. These values are
averaged over the requested interval.
- N_STARTED_HALTS: A vehicle on the detector that just
started halting, will report the time when this event took place
to the detector. All events during the requested interval are
summed up.
- HALTING_DURATION_SUM: A vehicle that starts moving after a
halt will report it's halting-duration (in seconds) and the time
when this event took place to the detector. The
halting-durations of all events during the requested interval
are summed up.
- HALTING_DURATION_MEAN: Every vehicle sums up it's
halting-durations (in seconds) during it's stay on the detector.
When a vehicle leaves the detector, it's halting-duration-sum is
stored by the detector. These values are averaged over the
requested interval.Only vehicles that moved through the entire
detector contribute.
- APPROACHING_VEHICLES_STATES: This detector is a special
kind of E2 detector. It doesn't return a single value but a
container of vehicle states. Here, a vehicle state is a tuple
consisting of the distance from the vehicle front to the
detector end and the vehicle's speed. There is no averaging or
summing up but current output is provided. This detector is
intended for internal use, e.g. as input to
traffic-light-controls.
Again, the explicit list of available attributes: id: A string holding the id of the
detector
type: Always "lane_based" or "E2" for
this type of detectors ("induct_loop" is the default
value)
lane: The id of the lane the detector
shall be laid on. The lane must be a part of the network
used.
pos: The position on the lane the
detector shall be laid on in meters. See information about the
same attribute within the detector loop description for further
information.
length: The length of the detector in
meters. If the detector grows over the lane's end (begin in
fact), it is either cut off at the lane's length if the
"cont"-attribute is false or not given or is
continued on the predeceding lanes in the case the
"cont"-attribute is set to true.
freq: The aggregation period the values
the detector collects shall be summed up.
file: The path to the output file. The
path may be relative.
measures: Should contain the list of
measures to compute (see above) or "ALL" to compute all
measures.
And the optional ones: style: Obsolete/deprecated; Always xml
by now
- cont: Holds the information whether detectors longer than
a lane shall be cut off or continued (set it to true for the
second case) default: false (detector lies on one lane
only).
time_treshold: The time-based threshold
that describes how much time has to pass until a vehicle is
recognized as halting (in s, default: 1s).
speed_treshold: The speed-based
threshold that describes how slow a vehicle has to be to be
recognized as halting (in m/s, default: 5/3.6m/s).
jam_treshold: The minimum distance to
the next standing vehicle in order to make this vehicle count as
a participant to the jam (in m, default: 10m).
keep_for: Information for how long the
memory of the detector has to be (in s, default: 1800s).
measures: Should contain the list of
measures to compute (see above) or "ALL" to compute all measures
(default: ALL).
6.1.1.3. E3-Detectors (Multi-Origin/Multi-Destination
Detectors)The descriptions of E3-detectors have to include the set of
entry- and the set of exit-cross-sections. Due to this, it is not
possible to use a single tag to specify a detector. Instead, the
description consists of the following parts: A beginning tag that describes some global attributes of
the detector just as the descriptions of e1- and e2-detectors
do. The format is either: <detector id="<ID>" type="(multi_od|E3)" file="<OUTPUT_FILE>"
freq="<AGGREGATION_TIME>" [measures="<MEASURES>"] [time_treshold="<FLOAT>"]
[speed_treshold="<FLOAT>"] [keep_for="<FLOAT>"]>
or: <e3-detector id="<ID>" file="<OUTPUT_FILE>" freq="<AGGREGATION_TIME>"
[measures="<MEASURES>"] [time_treshold="<FLOAT>"] [speed_treshold="<FLOAT>"]
[keep_for="<FLOAT>"]>
As one can see, no information about the detector's
position is stored herein. They are stored in embedded tags
instead (2. and 3.) A set of tags that describe the detector's entry points in
the form: <det_entry
lane="<LANE_ID>"
pos="<POSITION_ON_LANE>"/>
A set of tags that describe the detector's exit points in
the form: <det_exit
lane="<LANE_ID>"
pos="<POSITION_ON_LANE>"/>
A closing tag that must match the opening tag (1.): a) </detector> or b) </e3-detector>
The definition <e3-detector id="e3_1" freq="300" file="./output/e3_1.xml">
<det_entry lane="myEdge0_0" pos="0"/>
<det_entry lane="myEdge0_1" pos="0"/>
<det_exit lane="myEdge2_0" pos="0"/>
<det_exit lane="myEdge2_1" pos="0"/>
</e3-detector>
will build an e3-detector starting at either lane 0 or 1 of
the edge called "myEdge0" and end at the same lane of "myEdge2". All
values will be computed as the default-value for measures is used
and aggregated over a time of 300s. They will be written into the
file "e3_1.xml" lying in the subfolder of the
folder the configuration was read in/the program has been started
within. Most of the values have been discussed in the previous
subchapters. The only thing that differs from e1/e2-detectors are
the measures e3-detectors are able to compute. Possible values
are: - MEAN_TRAVELTIME: A vehicle that entered the detector
through an entry-cross-section and leaves it through a
leave-cross-section will store it's traveltime (in seconds) and
the leaving-time into the detector. These traveltimes of the
vehicles that left during the requested interval are
averaged.
- MEAN_NUMBER_OF_HALTINGS_PER_VEHICLE: A vehicle that
entered the detector through an entry-cross-section and leaves
it through a leave-cross-section will store it's number of
haltings and the leaving-time into the detector. The
halting-values of the vehicles that left during the requested
interval are averaged.
- NUMBER_OF_VEHICLES: A vehicle that entered the detector
through an entry-cross-section and leaves it through a
leave-cross-section will store it's leaving-time into the
detector. The vehicles that left the detector during the
requested interval will be summed up.
As for e2-detectors, you can use the value "ALL" for the
attribute measures to compute all values. This is also this
attributes default value. 6.1.2. Network State DumpIn the hope that every user wants to know different things and
is able to write a tool that parses this information from a not
aggregated output, the network dump was the first output capability
we've implemented. To force SUMO to build a file that contains the
network dump, extend your command line (or configuration) parameter by
--netstate-dump (or --ndump or
--netstate)
<FILE>.
<FILE> is hereby the
name of the file the output will be written to. Any other file with
this name will be overwritten, the destination folder must
exist. The network dump is a xml-file containing for each time step
every edge of the network with every lane of this edge with all
vehicles on this lane. For each vehicle, his name, speed and position
on his lane are written. A network dump-file looks like this: <sumo-netstate>
<timestep time="<TIME_STEP>">
<edge id="<EDGE_ID>">
<lane id="<LANE_ID>">
<vehicle id="<VEHICLE_ID>" pos="<VEH_POSITION>" speed="<VEH_SPEED>"/>
... more vehicles if any on this lane ...
</lane>
... more lanes if the edge possesses more ...
</edge>
... more edges ....
</timestep>
... the next timestep ...
</sumo-netstate>
The values have the following meaning: time: The time step described by the
values within this timestep-element
id: The id of the
edge/lane/vehicle
pos: The position of the vehicle at the
lane within the described time step
speed: The speed of the vehicle within
the described time step
As you may imagine, this output is very verbose. His main
disadvantage is the size of the generated file. It's very easy to
generate files that are several GB large within some minutes. It is of
course possible to write some nice tools that parse the file (using a
SAX-parser) and generate some meaningful information, but we do not
know anyone who has made this. Another problem is that the
simulation's execution speed of course breaks down when such an amount
of data must be written. Normally, all lanes are written, even if there is no vehicle on
them. You can change this behaviour using the boolean switch
--dump-empty-edges. In this case, only those edges
and lanes will be written that contain vehicles. Examples: <SUMO_DIST>/data/examples/output_tests/cross3ltl_rawdump/
shows how the raw output is used. The output is written into the
subfolder "output".
Recent changes: - Please notice that this options has been earlier falsely
named
--output (-o)
6.1.3. Aggregated Lane/Edge States (Edge/Lane-Dumps)This output is far more feasible than the network dump. There
are two different types of these files, one is edge-based, the other
lane-based. Both describe the situation on all of the network's
edges/lanes in terms of traffic science by giving macroscopic values
such as the mean vehicle speed, the mean density, etc. In the following, it is described how both outputs are generated
and which values they contain. Then, the meanings of the values are
given as well as a description of intervals. At last, some additional
possibilities to constraint the outputs are given. ![[Note]](images/note.png) | Note |
|---|
Please remark that "aggregated lane/edge states" are also
called "meandata" or "edge/lane-dumps". |
![[Note]](images/note.png) | Note |
|---|
Some people find the number of information within the
lane/edge states quite minimalist. This is because this output is
used as input for the DUAROUTER during
the computation of a dynamic user assignment (see "Dynamic User Assignment and Alternative
Routes") and due to this is meant to be fast. That's why it
only contains values that are fast to compute. |
Recent changes: - The documentation has been updated to fit the real output
when being rechecked for version 0.9.3
- The (even invalid) documentation of the file printed
previously at the begin of the file was removed in version
0.9.3
- This documentation text was rewritten for version 0.9.5,
because the previous text said that only those vehicles are
regarded which have left the lane. The edge-dumps/lane-dumps
contain instead the values of all vehicles that were on the
edges/lanes within the interval.
- Furthermore, computation of the density and the occupancy
has been debugged for version 0.9.5.
6.1.3.1. Edge-Based Network StatesTo force SUMO to generate edge-based state dumps, you have to
use two command line options: a) --dump-basename
<PATH_AND_FILE_PREFIX>
describes where to write the dumps to and how the begin of the file
name is, b) --dump-intervals
<INTERVAL>[;<INTERVAL>]*
describes over what time the values shall be collected and
aggregated ("interval length"). Each aggregation interval is written
into an own, single file. The file name is made up from the base
name and the aggregation interval:
<FILENAME> =
<PATH_AND_FILE_PREFIX>_<INTERVAL>.xml.
An example: --dump-basename=./output/lanedump
--dump-intervals=300;600 will build two files:
./output/lanedump_300.xml and
./output/lanedump_600.xml. For edge-based state
dumps, the output file will look like the following: <netstats>
<interval begin="<INTERVAL_BEGIN>" end="<INTERVAL_END>">
<edge id="<EDGE_ID>" traveltime="<MEAN_TRAVEL_TIME>" \
nSamples="<VEHICLE_NUMBER>" \
density="<MEAN_DENSITY>" occupancy="<MEAN_OCCUPANCY>" \
noStops="<NUMBER_OF_HALTS>" speed="<MEAN_SPEED>"/>
... more edges ...
</interval>
... further intervals ...
</netstats>
Please remark, that in contrary to the example above, for each
edge, all values are reported in one line. Examples: <SUMO_DIST>/data/examples/output_tests/cross3ltl_meandata_edges/
shows how to generate an edge-based aggregated state output.
Herein, four outputs are written into the subfolder
"output", one for each of the intervals
15s, 60s, 300s, and 900s.
6.1.3.2. Lane-Based Network StatesLane-dumps are generated analogous to edge-dumps using the
options --lanedump-basename
<PATH_AND_FILE_PREFIX> and
--lanedump-intervals
<INTERVAL>[;<INTERVAL>]*.
The generated output looks like the following: <netstats>
<interval begin="<INTERVAL_BEGIN>" end="<INTERVAL_END>">
<edge id="<EDGE_ID>">
<lane id="<LANE_ID>" traveltime="<MEAN_TRAVEL_TIME>" \
nSamples="<VEHICLE_NUMBER>" \
density="<MEAN_DENSITY>" occupancy="<MEAN_OCCUPANCY>" \
noStops="<NUMBER_OF_HALTS>" speed="<MEAN_SPEED>"/>
... more lanes
</edge>
... more edges ...
</interval>
... further intervals ...
</netstats>
Please remark, that in contrary to the example above, for each
edge, all values are reported in one line. Examples: <SUMO_DIST>/data/examples/output_tests/cross3ltl_meandata_lanes/
shows how to generate a lane-based aggregated state output.
Herein, four outputs are written into the subfolder
"output", one for each of the intervals
15s, 60s, 300s, and 900s.
6.1.3.3. Value DescriptionsBoth the edge-dump and the lane-dump are computing the values
the same way: every vehicle move - even those with v=0 - is recorded
and saved during the interval. After the interval has passed, these
values are written into the file after being normalised. In the case
of the edge-dump the values are not only normalized by the number of
the collected vehicle moves and the length of the lane, but also by
the number of lanes of the edge. The meanings of the written values are: traveltime: The mean travel time is
computed from the collected vehicle velocities. If no vehicle
has passed the edge, length/maximum_allowed_velocity is used;
Measure: s
speed: The mean of the collected
vehicle velocities. If no vehicle has passed the edge, the
maximum allowed velocity is used; Measure: m/s
density: The mean vehicle density on
the edge in veh/km.
occupancy: The occupancy of the edge
(in range of 0-1)
noStops: The number of recognized
stops
nSamples: The number of collected
samples - the number of vehicle steps done on this edge during
the interval.
The interval end is the interval begin + aggregation time - 1,
meaning that values were collected within these steps. If the
simulation ends before the last interval is over, the interval will
be prunned. 6.1.3.4. Constraining the State OutputsIf you need only information about the network states during
certain time periods, you may constraint generation of the dumps
using the options --dump-begins
<TIME>[;<TIME>]+ and
--dump-ends
<TIME>[;<TIME>]+.
When at least one combination is given, dumps will be written only
if an according begin/end-pair exists for the current time. This
means, only those intervals will be saved for which
dump-begins[x]<=INTERVAL_END and
dump-ends[x]>=INTERVAL_BEGIN. Of course, all dumps will cover the complete simulation if the
options --dump-begins and
--dump-ends are not set. Examples: <SUMO_DIST>/data/examples/output_tests/cross3ltl_meandata_constrained/
shows how to generate a restrained state output. Herein, eight
outputs are written into the subfolder
"output", four edge- and four lane-based,
and for each of the intervals 15s, 60s, 300s, and 900s.
6.1.4. Net-Wide Vehicle Emission States & Travel TimesThis output contains the simulation-wide number of vehicles that
are loaded, emitted, running, waiting to be emitted, have reached
their destination and how long they needed to finish the route. The
last value is normalised over all vehicles that have reached their
destination so far. The information containing all those values is
computed for each time step and the output file looks like
following: <emissions>
<emission-state time="<SIMULATION_TIME>"
loaded="<LOADED_VEHICLE_NUMBER>" \
emitted="<EMITTED_VEHICLE_NUMBER>" \
running="<RUNNING_VEHICLE_NUMBER>" \
waiting="<NUMBER_OF_VEHICLES_WAITING_FOR_EMISSION>" \
ended="<ENDED_VEHICLE_NUMBER>" \
meanWaitingTime="<MEAN_WAITING_TIME>" \
meanTravelTime="<MEAN_TRAVEL_TIME>"/>
... further time steps ...
</emissions>
Please remark, that in contrary to the example above, for each
time step, all those values are reported in one line. The meanings of the written values are: time: the time step the entry
describes
loaded: the number of vehicles that were
loaded into the simulation until the reported time step
emitted: the number of vehicles already
emitted until the reported time step
running: the number of vehicles that were
running within the reported time step
ended: the number of vehicles that have
reached their destination within the reported and the prior time
step
meanWaitingTime: the mean time all
vehicles up to and within the reported time step had to wait for
being emitted;-1 if no vehicle has been emitted, yet
meanTravelTime: the mean travel time of
all vehicles that have left the simulation within the previous and
the reported time;-1 if no vehicle has been removed from the
simulation, yet
You can force the simulation to generate this output using
--emissions-output
<FILENAME> or
--emissions
<FILENAME>. Examples: <SUMO_DIST>/data/examples/output_tests/cross3ltl_emissions/
shows how the emissions output is used. The output is written into
the subfolder "output".
Recent changes: - In versions prior to 0.9.3, the attribute
"
time" was named "id"
6.1.5. Vehicle-Oriented Trip InformationThis output contains the information about each vehicle's
departure time, the time the vehicle wanted to start at (which may be
lower than the real departure time) and the time the vehicle has
arrived. Such an information is generated for each vehicle as soon as
the vehicle has arrived its destination and is removed from the
network. The format is as following: <tripinfos>
<tripinfo vehicle_id="<VEHICLE_ID>" start="<DEPARTURE_TIME>" \
wished="<WISHED_DEPARTURE_TIME>" \
end="<ARRIVAL_TIME>" \
duration="<TRAVEL_TIME>" \
waited="<WAITING_TIME>" \
reroutes="<REROUTE_NUMBER>" \
devices="<DEVICE_LIST>" \
vtype="<VEHICLE_TYPE>"/>
... information about further vehicles ...
</tripinfos>
Please remark, that in contrary to the example above, for each
time step, all those values are reported in one line. An entry is
written each time a vehicle has arrived at his destination. In prior
to this, the written values would not be known. The meanings of the written values are: vehicle_id: the id of the vehicle this
entry describes
start: The real departure time (the time
the vehicle was emitted into the network)
wished: The departure time the vehicles
wanted to be emitted into the network
end: The time the vehicle was removed
from the simulation (due to arriving at the route end)
duration: The time the vehicle needed to
accomplish the route (in s)
waited: The time the vehicle has waited
until being emitted
reroutes: The number the vehicle has been
rerouted
devices: List of devices the vehicle had.
Each device is separated from the others by a ';'. If a vehicle
may contain several devices (CPhones, f.e.) the number will be
printed (example: cphones=1)
vtype: The type of the vehicle
The simulation is forced to generate this output using:
--tripinfo-output
<FILENAME> or
--tripinfo
<FILENAME>. Examples: <SUMO_DIST>/data/examples/output_tests/cross3ltl_tripinfo/
shows how the tripinfo output is used. The output is written into
the subfolder "output".
Recent changes: - In versions prior to 0.9.3, the attribute
"
vehicle_id" was named
"id"
- The documentation has been updated before releasing version
0.9.3
- The number of reroutes attribute was added for version
0.9.6
- The devices list attribute was added for version
0.9.6
- The vehicle type attribute was added for version
0.9.6
The vehicle routes output contains information about which route
a vehicle took and if his route was replaced at any time by a new one,
each of the previous routes together with the edge at the time their
replacement took place is reported. Furthermore, the vehicle emission
and ending time is stored herein. The generated file look like this: <vehicleroutes>
<vehicle id="<VEHICLE_ID>" emitedAt="<EMISSION_TIME>" endedAt="<ARRIVAL_TIME>">
<route replacedOnEdge="<EDGE_ID>" replacedAtTime="<TIME>"><PREVIOUS_ROUTE></route>
... further replaced routes ...
<route><LAST_ROUTE></route>
</vehicle>
... information about further vehicles ...
</tripinfos>
The values have the following meanings: id: the id of the vehicle this entry
describes
emitedAt: The time the vehicle was
emitted into the network)
endedAt: The time the vehicle was removed
from the simulation (due to arriving at the route end)
replacedOnEdge: The edge the vehicle was
on when the described route was replaced
replacedAtTime: The time step of this
replacement
<PREVIOUS_ROUTE>:
The replaced route
<LAST_ROUTE>:
The final vehicle route
Both the previous and the final routes are complete, that means
that they contain all the edges the vehicle was meant to pass as long
as the route was not replaced, yet. The information
replacedOnEdge and
replacedAtTime are available only for routes which
were replaced. In normal conditions, when all vehicles use predefined routes,
the output does not contain any information that could not be
retrieved from the routes and the tripinfo output. But as soon as you
reroute your vehicles within the simulation, f.e. using rerouters (see
"Rerouter"), it
will contain new information. The simulation is forced to generate this output using:
--vehroutes-output
<FILENAME> or
--vehroutes
<FILENAME>. Examples: <SUMO_DIST>/data/examples/output_tests/cross3ltl_vehroutes/
shows how the vehicle routes output is used. The output is written
into the subfolder "output". This is just a
basic example that the output is generated. Better take a look at
<SUMO_DIST>/data/examples/extended/rerouter/.
<SUMO_DIST>/data/examples/extended/rerouter/
uses rerouters to change the vehicles' routes. A vehicle routes
output into the output-subfolder.
Recent changes: - This output was finally finished and validated for version
0.9.3
6.1.7. Output coupled to Traffic LightsSUMO offers some possibilities to save states of traffic lights
during the simulation, a feature mainly used to evaluate adaptive
traffic light algorithms. We will now describe these outputs. To enable writing tls state information you have to add the
following definition into one of your additional files:
<timed_event type="SaveTLSStates"
source="<TLS_ID>"
dest="<OUTPUT_FILE>"/>.
The attributes have herein the following meanings: type: type of the event trigger; always
"SaveTLSStates" herein
source: The id of the traffic light
which state shall be written
dest: The file to save the state
into
The output looks like this: <tls-states>
<tlsstate time="<SIM_STEP>" id="<TLS_ID>" subid="<TLS_SUBID>"><STATE></tlsstate>
... further states ...
</tls-states>
The state is saved in each simulation second. The state itself
is coded as a list of the characters 'G', 'Y', and 'R', standing for
"green", "yellow", and "red", respectively. Each character describes
a link controlled by the traffic light. Only the state of the
current program is saved (see also "Adding
new Programs"). The attributes have the following
meaning: time: The simulation time this entry
was generated for
id: The id of the tls that is
responsible for the link
subid: The sub-id of the tls that is
(currently) responsible for the link
Missing: - An easy mapping from positions within the state to
links.
Recent changes: - Changes in version 0.9.5
- This output is available since a long time, still
several issues may made him unworking before version
0.9.5
- Changes in version 0.9.6
- Since version 0.9.6 only the state of the current
program is saved
This output contains information about the green light phases
of links (lane-to-lane connections). Each green light phase is
describes by its begin, end and duration. An entry is written into
the file as soon a green phase of a link ends. To enable writing tls
switch information you have to add the following definition into one
of your additional files: <timed_event
type="SaveTLSSwitchTimes"
source="<TLS_ID>"
dest="<OUTPUT_FILE>"/>.
The attributes have herein the following meanings: type: type of the event trigger; always
"SaveTLSSwitches" herein
source: The id of the traffic light
which state shall be written
dest: The file to save the state
into
The output looks like this: <tls-switches>
<tlsswitch tls="<JUNCTION_ID>" subid="<JUNCTION_SUB_ID>" \
fromLane="<LINKS_SOURCE_LANE>" toLane="<LINK_DESTINATION_LANE>" \
begin="<BEGIN_OF_GREEN_PHASE>" end="<END_OF_GREEN_PHASE>" \
duration="<DURATION_OF_GREEN_PHASE>"/>
... further switch points ...
</tls-switches>
Each entry is written into a single line. The values have the
following meanings: junction: The id of the tls that is
responsible for the link
subid: The sub-id of the tls that is
(currently) responsible for the link
fromLane: The id of the lane the link
starts at
toLane: The id of the lane the link
ends at
begin: Begin of this link's last green
phase
end: End of this link's last green
phase
duration: Duration of this link's last
green phase
Recent changes: - Changes in version 0.9.5
- This output is available since version 0.9.5
- Changes in version 0.9.6
- The element "switch" was renamed to "tlsswitch" in
version 0.9.6
6.1.7.3. TLS Switch StatesThis output saves tls-states as the TLS States - output does
but not every second but only at times the phases or the program
(see also "Adding
new Programs") change. The output is instantiated by adding
the following definition into one of your additional files:
<timed_event type="SaveTLSSwitchStates"
source="<TLS_ID>"
dest="<OUTPUT_FILE>"/>.
The attributes have herein the following meanings: type: type of the event trigger; always
"SaveTLSSwitches" herein
source: The id of the traffic light
which state shall be written
dest: The file to save the state
into
The output looks like this: <tls-switch-states>
<tlsstate time="<SIM_STEP>" id="<TLS_ID>" subid="<TLS_SUBID>"><STATE></tlsstate>
... further states ...
</tls-switch-states>
Each entry is written into a single line. The values have the
following meanings: time: The simulation time this entry
was generated for
id: The id of the tls that is
responsible for the link
subid: The sub-id of the tls that is
(currently) responsible for the link
Recent changes: - Changes in version 0.9.6
- This output is available since version 0.9.6
6.2. Vehicles Handling RevisitedIn the normal case, SUMO is meant to simulate urban areas where
vehicles may start their trips from any edge. Still, there also some
other approaches to feed a simulation with a demand and some of them
where implemented in SUMO. You have the following possibilities to add
vehicles into your network: - Insert vehicles on any edge
In this case, a vehicle from the list will be inserted at the
given time into the edge his route starts at. The position of the
insertion is random (by now), the rightmost lane will be
used.
- Insert vehicles on feeding edges
This is approach is often used in conjunction with
od-matrices; each of the districts described in such od-matrices
contains a list of "feeding" or "source" edges. If you use feeding
edges, your vehicles will be inserted similar to insertion on normal
edges as described above, but they will be always inserted at the
end of the edge and all lanes of the feeding edge will be
used.
- Using emitter
Emitter are used to insert vehicles into the network at a well
defined position. An emitter may be placed on a certain lane and
gets a list of vehicles (or a flow amount) to emit. We use this
approach often to insert vehicles into the network at places where
induct loops have measured the flows.
We will now describe the emitters more deeply. Emitters may be used to define flows using induction loops as
input data. For such modelling attempt, you should place emitters at
those positions on the network where the induction loops are located
and convert the values retrieved from the induction loops to the
format emitters may read. The
format is described below, together with some additional methods to
ease generation of emitter files. If you are working with such inputs
extensively, you may be also interested in what the
DFROUTER does (see "Using Detectors and DFROUTER" for
a further documentation). Recent changes: - Although emitters are available for a long time already,
their description has been added while working on version
0.9.5
6.2.1.1. Basic DefinitionYou can place an emitter onto a lane by adding the following
declaration to one of your additional-files: <trigger id="<ID>" objecttype="emitter" pos="<POS>" objectid="<LANE_ID>" \
[friendly_pos="x"] file="<DEFINITION_FILE>"/>
The fields have the following meanings: id: A string holding the id of the
emitter.
objecttype: Always
"emitter"; indicates this trigger is an
emitter
pos: Position on the lane in meters; if
positive, then the following must be ensured:
0<=<POS><<LANE_LENGTH>,
if negative:
0><POS>>-<LANE_LENGTH>;
in this case the position will be counted from the lane's
end.
objectid: The id of the lane the
emitter shall be placed on
friendly_pos: optional; if this is set
and the position (pos) is not valid, the
detector will be placed at the lane's end (0.1meter away from
it).
file: The file the emitter shall read
the definition of what/how/when to emit from
An emitter needs further information to know when, how many
and what kind of vehicles shall be emitted. All this information
must be written into
<DEFINITION_FILE>. The easiest way
to describe vehicle emissions herein is to list all of them
explicitely: <triggeredsource>
<emit id="veh1" time="0" vehtype="my_type" route="my_route" speed="13.9"/>
<emit id="veh2" time="4" vehtype="my_type" route="my_route" speed="13.9"/>
<emit id="veh3" time="8" vehtype="my_type" route="my_route" speed="13.9"/>
</triggeredsource>
Using such a definition only would raise error because we have
named the vehicle types and the routes but did not define them. We
can either define them within another additional file or within a
route file but we have to ensure that they're loaded before the
emission definition is (see "Using the Files in a correct
Way" on loading order). Let's assume we have done it. In this
case, using such a definition we would emit three vehicles, having
the names "veh1", "veh2", and "veh3" as given within the id-field,
all being of type "my_type". All vehicles use the same route,
"my_route", and will start with a velocity of 0 at the simulation
seconds 0, 4, and 8. To summarize, a vehicle emission within an
Emitter definition is described as following: <emit
[id="<VEHICLE_ID>"]
[vehtype="<VEHICLE_TYPE>"]
time="<EMISSION_TIME>"
[route="<VEHICLE_ROUTE>"]
[speed="<INITIAL_SPEED>"]/>.
The meanings of these values are: id: The id of the vehicle to
emit
vehtype: Name of the vehicle type the
vehicle to emit shall have
time: The time at which the vehicle
shall be emitted (in simulation seconds)
route: Name of the route the vehicle
shall use
speed: The speed the vehicle shall be
emitted with in m/s
As you can see, several of the fields are marked as optional.
If no id is given, the id will be constructed automatically. The
vehicle will then have a name made up from the emitter's id followed
by the time step the vehicle shall be emitted at and a running
number, all divided by a '_'
("<EMITTER_ID>_<DEPART>_<RUNNING>").
Also, the emission speed is optional. If not given, the minimum of
the maximum speed allowed on the lane and the vehicle's maximum
velocity is used. If the emission time lies before the simulation
begin, the vehicle will be discarded. The following sections
describe how one can omit explicite attributes for vehicle type and
route. 6.2.1.2. Describing Route DistributionsTo avoid computing and assigning a vehicle type and a route to
each vehicle emission definition explicitely, you can define a
probability distribution by which routes/types are chosen from a
set. For the routes, you can do this as shown in the next
example: <triggeredsource>
<routedistelem id="my_route1" probability=".2"/>
<routedistelem id="my_route2" probability=".8"/>
<emit id="veh1" time="0" vehtype="my_type" speed="13.9"/>
<emit id="veh2" time="4" vehtype="my_type" speed="13.9"/>
</triggeredsource>
Now, a random route is assigned to a vehicle, "my_route1" with
a probability of .2, "my_route2" with a probability of .8. The
probabilities are normed automatically, that means that you can also
use numbers that do not sum to 1. Each occuring
routedistelem will be added to the distribution
(see also "Resetting
the Distributions"). The meanings of the attributes of a
routedistelem-element are: id: The name of the route to use (the
route must have been loaded in prior to the occurence of the
routedistelem-element)
probability: The probability (value/sum
of probabilities) of choosing the route
6.2.1.3. Describing Vehicle Type DistributionsVehicle types may be assigned to vehicles from distributions,
too: <triggeredsource>
<vtypedistelem id="my_type1" probability=".8"/>
<vtypedistelem id="my_type2" probability=".8"/>
<emit id="veh1" time="0" route="my_route" speed="13.9"/>
<emit id="veh2" time="4" route="my_route" speed="13.9"/>
</triggeredsource>
In this example the probabilities for using one of the types
are equal. The probabilities are normed automatically, that means
that you can also use numbers that do not sum to 1. Each occuring
vtypedistelem will be added to the distribution
(see also "Resetting
the Distributions"). The meanings of the attributes of a
vtypedistelem-element are: id: The name of the vehicle type to use
(the vehicle type must have been loaded in prior to the
occurence of the
vtypedistelem-element)
probability: The probability (value/sum
of probabilities) of choosing the vehicle type
6.2.1.4. Resetting the DistributionsAs said before, all occurences of
vtypedistelem are stored into the same
distribution. This also holds for the occurences of
routedistelem. Now, one maybe wants to model
different distributions over time. To allow this, you can add a
"reset"-element to your description: <triggeredsource>
<vtypedistelem id="my_type1" probability=".5"/>
<vtypedistelem id="my_type2" probability=".5"/>
<routedistelem id="my_route1" probability=".2"/>
<routedistelem id="my_route2" probability=".8"/>
<emit time="10" speed="13.9"/>
... further vehicle emits ...
<emit time="20" speed="13.9"/>
<reset/>
<vtypedistelem id="my_type3" probability=".5"/>
<vtypedistelem id="my_type4" probability=".5"/>
<routedistelem id="my_route3" probability=".2"/>
<routedistelem id="my_route4" probability=".8"/>
<emit time="30" speed="13.9"/>
... further vehicle emits ...
<emit time="40" speed="13.9"/>
</triggeredsource>
This would force the emitter to reset all distributions after
emitting the vehicle at time 20. While vehicles emitted within the
times 10 and 20 would use the vehicle types "my_type1" and
"my_type2" and routes "my_route1" and "my_route2", the vehicles
emitted between time 30 and 40 - after the
reset-element - would use the vehicle types
"my_type3" and "my_type4" and the routes "my_route3" and
"my_route4". Instead of describing each vehicle emission explicitely, you
can specify a flow to emit. In this case, vehicle type and routes
distributions must be given: <triggeredsource>
<vtypedistelem id="my_type1" probability=".5"/>
<vtypedistelem id="my_type2" probability=".5"/>
<routedistelem id="my_route1" probability=".2"/>
<routedistelem id="my_route2" probability=".8"/>
<flow no="1800" end="10"/>
<flow no="900" end="20"/>
</triggeredsource>
The meaning of the attributes of a
flow-element are: no: The flow to use in veh/h.
end: The end of the interval for which
this flow shall be emitted. If <0 (default) the flow will be
used until the simulation's end.
6.3. Traffic Management and Other StructuresSUMO holds several additional structures to model speed limits,
public transport etc. The structures are normally defined within
additional files. Normally, NETCONVERT will generate
traffic lights and programs for junctions during the computation of
the networks. Still, these computed programs differ quite often from
those found in reality. To feed the simulation with traffic light
programs from the reality, it is possible to load additional programs
since version 0.9.4. Furthermore, one can describe when and how a set
of traffic lights can switch from one program to another. Both will be
discussed in the following subchapters. Handling of traffic lights is not yet very user friendly.
Besides the following descriptions, a further document, "SUMO
- More on... Traffic Lights", exists which describes the usage
of traffic lights more deeply. 6.3.1.1. Adding new TLS-ProgramsSince version 0.9.4 you may attach a new program to a tls
after the network has been loaded. Defining a tls program is not
that straightforward, yet. If you are definitely interested in this,
we advice you to read the "SUMO
- More on... Traffic Lights" document where the format is
described. Basically, a tls program definition looks like
this: <tl-logic type="static">
<key>0</key>
<subkey>0</subkey>
<phaseno>8</phaseno>
<offset>0</offset>
<phase duration="20" phase="0000111100001111" brake="1111110011111100" \
yellow="0000000000000000"/>
<phase duration="4" phase="0000110000001100" brake="1111111111111111" \
yellow="0000001100000011"/>
<phase duration="3" phase="0000110000001100" brake="1111001111110011" \
yellow="0000000000000000"/>
<phase duration="4" phase="0000000000000000" brake="1111111111111111" \
yellow="0000110000001100"/>
<phase duration="20" phase="1111000011110000" brake="1100111111001111" \
yellow="0000000000000000"/>
<phase duration="4" phase="1100000011000000" brake="1111111111111111" \
yellow="0011000000110000"/>
<phase duration="3" phase="1100000011000000" brake="0011111100111111" \
yellow="0000000000000000"/>
<phase duration="4" phase="0000000000000000" brake="1111111111111111" \
yellow="1100000011000000"/>
</tl-logic>
After you have defined a tls program, you can add it to one of
your additional files. You may load several programs for a single
tls into the simulation. The program loaded as last will be used
(unless not defined using a WAUT description, see below). Please
remark, that all subkeys of your programs must differ if they
describe the same tls. Recent changes: - Loading of additional tls programs is implemented since
version 0.9.4
- The
inclanes tag has been removed from
the network description since version 0.9.4
- The tag
keyno has been renamed to
subkey since version 0.9.4
![[Caution]](images/caution.png) | Caution |
|---|
Please keep in mind that this feature is quite new and that
du to this some things may not work as suspected and may get
changed in the near future.
|
6.3.1.2. Defining the switch Times and ProcedureIn the reality, a tls often uses different programs during a
day and maybe also for weekdays and for the weekend days. Since
version 0.9.4 you can define switch times between the programs using
a WAUT (I am very sorry, but I do not know the English word for WAUT
- this may be a matter of change). Let's assume we would have a tls which knows four programs -
two for weekdays and two for weekend days where from 22.00 till 6.00
the night plan shall be used and from 6.00 till 22.00 the day plan.
We'll give these programs the names "weekday_night", "weekday_day",
"weekend_night", "weekend_day". To describe the switch process, we
have to describe the switch at first, assuming our simulation runs
from monday 0.00 (second 0) to monday 0.00 (second 604800): <WAUT refTime="0" id="myWAUT" startProg="weekday_night">
<wautSwitch time="21600" to="weekday_day"/> <!-- monday, 6.00 -->
<wautSwitch time="79200" to="weekday_night"/> <!-- monday, 22.00 -->
<wautSwitch time="108000" to="weekday_day"/> <!-- tuesday, 6.00 -->
... further weekdays ...
<wautSwitch time="453600" to="weekend_day"/> <!-- saturday, 6.00 -->
... the weekend days ...
</WAUT>
The fields in WAUT have the following
meanings: refTime: A reference time which is used
as offset to the switch times given later (in simulation
seconds)
id: The name of the defined WAUT
startProg: The program that will be
used at the simulation's begin
and the fields in wautSwitch: time: The time the switch will take
place
to: The name of the program the
assigned tls shall switch to
Of course, programs with the used names must be defined before
this definition is read. Also, the time must be sorted. Additionally, we have to define which tls shall be switched by
the WAUT. This is done as following: <wautJunction wautID="myWAUT" junctionID="RCAS" [procedure="Stretch"] [synchron="t"]/>
Here, the attributes have the following meaning: wautID: The id of the WAUT the tls
shall be switched by
junctionID: The name of the tls to
assign to the WAUT
procedure: The switching algorithm to
use; If none is given, the programs will switch immediately
(default)
synchron: Additional information
whether the switch shall be done synchron (default:
false)
You may assign several tls to a single WAUT. YOu may also
assign several WAUTs to a single junction in theory, but this is not
done in reality. The switching procedures are currently under
development. Recent changes: - WAUTs are implemented since version 0.9.4
![[Caution]](images/caution.png) | Caution |
|---|
Please keep in mind that this feature is quite new and that
du to this some things may not work as suspected and may get
changed in the near future.
|
Possibilities to simulate public transport were firstly added in
version 0.9.3. By now you may define positions of bus stops and let
vehicles ("busses") stop at these positions for a pre-given time.
Definitions of bus stop locations in SUMO have the following format:
<trigger
id="<BUS_STOP_ID>"
objecttype="bus_stop"
objectid="<LANE_ID>"
from="<STARTING_POSITION>"
to="<ENDING_POSITION>"
[line="<LINE_ID>[;<LINE_ID>]*"]/>.
That means that a bus stop is an area on a lane. The parameters have
the following meanings: id: id of the bus stop; must be
unique
objecttype: always "bus_stop"
herein
objectid: the id of the lane the busstop
shall be located at
from: the begin position on the lane (the
lower position on the lane) in meters
to: the end position on the lane (the
higher position on the lane) in meters
line: A list of names separated by a
semicolon (';') meant to be the names of the bus lines that stop
at this bus stop. This is only used for visualisation
purposes.
Vehicles must be informed that they must stop at a bus stop. The
following example shows how this should be done (taken from
<SUMO_DIST>/data/examples/extended/busses1): <vtype id="BUS" accel="2.6" decel="4.5" sigma="0.5" length="15" maxspeed="70"
color="1,1,0"/>
<vehicle id="0" type="BUS" depart="0" color="1,1,0">
<route>2/0to2/1 2/1to1/1 1/1to1/2 1/2to0/2 0/2to0/1 0/1to0/0 0/0to1/0 1/0to2/0
2/0to2/1</route>
<stop bus_stop="busstop1" duration="20"/>
<stop bus_stop="busstop2" duration="20"/>
<stop bus_stop="busstop3" duration="20"/>
<stop bus_stop="busstop4" duration="20"/>
</vehicle>
What we have here is a vehicle named "0" being a "BUS". "BUS" is
a referenced type declared earlier. The vehicle has an embedded route
(written by hand in this case) and a list of stop places. Each stop
place is described by two attributes, "bus_stop"
and "duration" where "bus_stop"
is the name of the bus stop the vehicle shall halt at and
"duration" is the time the vehicle shall wait at
the bus stop in seconds. Please remark that the order of bus stops the
vehicle shall halt at must be correct. You may also let a vehicle stop at another position than a bus
stop. The complete definition of a vehicle's stop is:
<stop (
bus_stop="<BUS_STOP_ID>" |
lane="<LANE_ID>"
pos="<POSITION_AT_LANE>" )
duration="<HALTING_DURATION>"/>.
This means you can either use a bus stop
or a lane position to define where a vehicle has
to stop. Again the list of attributes for the
"stop"-element of a vehicle: - Either:
bus_stop: id of the bus stop the
vehicle shall halt at; the bus stop must be previously
declared
- or:
lane: id of the lane the vehicle
shall stop at; the lane must be within the network
- pos: Position on the lane the vehicle shall stop at;
double
duration: the time the vehicle shall halt
at the bus stop in seconds; int, mandatory
Examples: <SUMO_DIST>/data/examples/extended/busses1
shows a small example for defining bus stops and letting a bus
halt at them
<SUMO_DIST>/data/examples/extended/3busses1
is almost the same as
<SUMO_DIST>/data/examples/extended/busses1
but three busses are driving here and the first bus stop is longer
than the others. This example shows how the length of bus stops
determines how many busses actually can stop here.
<SUMO_DIST>/data/examples/extended/vehicle_stops
shows a small example where a vehicle halts
Some extensions still to be done: - Definition of public transport lines instead of giving a
list of stops for each vehicle?
- Halting times dependent to the number of passengers within
the vehicle
- Optionally do not let vehicles halt if no person wants to
leave/enter
6.3.3. Variable Speed Signs (VSS)One of the trigger objects that may be specified within an
additional file allows the simulation of variable speed signs. The
syntax for such an object is: <trigger
id="<VSS_ID>" objecttype="lane"
objectid="<LANE_ID>" attr="speed"
file="<DEF_FILE>"/>.
This trigger is typed to be a vss by the combination of the values of
the attributes objecttype="lane" and
attr="speed". Although no other combinations are
implemented so far, this combination forces the simulation to change
the attribute "speed" of a "lane"-object, exactly what vss do. Of
course, the vehicles themselves do not override this maximum velocity
what does not exactly represent the reality. You may have noticed that a file name must be supplied, called
<DEF_FILE> within
the schema above. This file must contain the information about when a
certain speed shall be set onto the lane. This file has the following
format: <vss>
<step time="<TIME>" speed="<SPEED>"/>
<step time="<TIME>" speed="<SPEED>"/>
... further entries ...
<step time="<TIME>" speed="<SPEED>"/>
</vss>
Each step is a combination of the
time the next new speed shall be set and the
speed to set itself. A small example for usage of vss' within SUMO may be found in
"data/examples/extended/variable_speed_signs". Rerouter change the route of vehicles as soon as a vehicle moves
on a specified edge. Although implemented earlier, were firstly
described and tested within version 0.9.5. A rerouter is set into the simulated by adding the following
line to an "additional file": <trigger
id="<REROUTER_ID>"
objecttype="rerouter"
objectid="<EDGE_ID>[;<EDGE_ID>]"
file="<DEFINITION_FILE>"
[probability="<PROBABILITY>"]/>.
As you may see, rerouter may be placed on several edges, at least one
edge is necessary. Furthermore, you may already give within this
definition how many vehicles shall be rerouted by giving a number
between 0 (none) and 1 (all). In addition to this definition a
description file
(<DEFINITION_FILE>)
must be given which describes the behaviour of the rerouter over time.
The definition values are id: the id of of the rerouter
objecttype: always
"rerouter"
objectid: an edge id or a list of edge
ids where vehicles shall be rerouted
file: path to the definition file
probability: the probability for vehicle
rerouting (0-1)
Each definition of what a rerouter shall do is embedded in an
interval definition which describes within which time period the
rerouter shall work. This is set up as following: <rerouter>
<interval begin="<BEGIN_TIME>" end="<END_TIME>"/>
... action description ...
</interval>
... further intervals ...
</rerouter>
A rerouter may work in several different ways. Within a time
period you may close an edge, or assign new destinations or pregiven
routes to vehicles. The next subchapters will describe these
possibilities and how to describe them in detail. Examples: Recent changes: - A complete description of rerouters was added in version
0.9.5; in accordace, definitions of rerouters have changed
6.3.4.1. Closing a StreetA "closing_reroute" forces the rerouter to
close the edge
<EDGE_ID>.
Vehicles which normally would pass this edge will get a new route as
soon as they reach one of the edges given in the
objectid-attribute of the rerouter's declaration.
A definition may look like this: <rerouter>
<interval begin="<BEGIN_TIME>" end="<END_TIME>"/>
<closing_reroute id="<EDGE_ID>"/>
</interval>
... further intervals ...
</rerouter>
The attributes used within such definitions are: id: the id of the closed edge;
mandatory string, the id must be the id of an edge within the
network
6.3.4.2. Assigning a new DestinationA "dest_prob_reroute" forces the rerouter
to assign a new route to vehicles which pass one of the edges
defined in the objectid-attribute of the
rerouter's declaration. A new route destination is used, defined by
the name of a new destination in the according element: <rerouter>
<interval begin="<BEGIN_TIME>" end="<END_TIME>"/>
<dest_prob_reroute id="<EDGE_ID1>" probability="<PROBABILITY1>"/>
<dest_prob_reroute id="<EDGE_ID2>" probability="<PROBABILITY2>"/>
</interval>
... further intervals ...
</rerouter>
The route is computed automatically using the
Dijkstra-algorithm and starting at the edge the vehicle is located
at and ending at the new destination. The attributes used within such definitions are: id: the id of the new destination;
mandatory string, the id must be the id of an edge within the
network
probability: the probability with which
a vehicle will use the given edge as destination; mandatory
float, should be between 0 and 1; the sum of the probabilities
should be 1
6.3.4.3. Assigning a new RouteA "route_prob_reroute" forces the rerouter
to assign a new route to vehicles which pass one of the edges
defined in the objectid-attribute of the
rerouter's declaration. In this case, the id of a complete route
shall be supplied instead of a new destination: <rerouter>
<interval begin="<BEGIN_TIME>" end="<END_TIME>"/>
<route_prob_reroute id="<ROUTE_ID1>" probability="<PROBABILITY1>"/>
<route_prob_reroute id="<ROUTE_ID2>" probability="<PROBABILITY2>"/>
</interval>
... further intervals ...
</rerouter>
The attributes used within such definitions are: id: the id of a new route to assign;
mandatory string, the id must be the id of a previously loaded
route
probability: the probability with which
a vehicle will use the given edge as destination; mandatory
float, should be between 0 and 1; the sum of the probabilities
should be 1
Since version 0.9.5 SUMO is capable to handle vehicle classes.
One can close a road or a lane for certain vehicle classes or
explicitely allow certain vehicle classes on a road/lane. This is done
by a combination of assigning allowed/disallowed vehicle classes to
roads/lanes and additionally giving vehicles a further class
attributes. Available vehicle classes as well as using them is
described within the next subchapters. ![[Caution]](images/caution.png) | Caution |
|---|
Please keep in mind that this feature is quite new and that du
to this some things may not work as suspected and may get changed in
the near future. We want to ask you to supply us any comments on this topic -
it is not completely designed, yet.
|
Recent changes: - A first support for vehicle classes was added in version
0.9.5
6.3.5.1. Available Vehicle ClassesA vehicle class is made up of two parts. The first part
describes to what kind of an authority the vehicle belongs. The next
table shows what kind of authorities are defined currently: Table 6.1. Allowed vehicle class authority descriptions | Table Name | Description |
|---|
| private | The vehicle belongs to a private person | | public_transport | The vehicle is a public transport vehicle | | public_emergency | The vehicle is an emergency vehicle | | public_authority | The vehicle belongs to a public authority
(police) | | public_army | The vehicle is an army vehicle | | vip | The vehicle is used to transport a vip (very
important person) |
The second part describes the kind of the vehicle. Currently
possible values are shown within the next table: Table 6.2. Allowed vehicle class vehicle kind descriptions | Table Name | Description |
|---|
| passenger | A plain passenger car | | hov | A heavy occupied vehicle | | taxi | A taxi | | bus | A bus | | delivery | A small delivery vehicle | | transport | A truck | | lightrail | A lightrail | | cityrail | A cityrail | | rail_slow | A slow transport rail | | rail_fast | A fast passenger rail | | motorcycle | A motorcycle | | bicycle | A bicycle | | pedestrian | A pedestrian |
Please remark that both the authority descriptions and kind
descriptions are only names, no model is stored behind them. By
defining a vehicle type as "pedestrian" you will not get a person
walking within the simulation - currently pedestrian are not modeled
anyway. These values simply name possible types of vehicles found on
a network to allow closing/opening lanes or edges for them
currently. 6.3.5.2. Closing/Opening Roads/Lanes for certain Vehicle
ClassesRoads/lanes are normally marked to allow/disallow a certain
vehicle class while building the network using NETCONVERT. This
process is described in chapter "Defining
allowed Vehicle Types". 6.3.5.3. Assigning a Type to a VehicleYou can assign a vehicle class to a vehicle by extending this
vehicle's vehicle type. Assume you want to set a vehicle as being of
the class "bus". A vehicle type definition could look like
this: <vtype id="BUS" accel="2.6" decel="4.5" sigma="0.5" length="15" maxspeed="70"
color="1,1,0" vclass="public_bus"/> |