Academia.eduAcademia.edu

Figure 10 – uploaded by João Jacob

See full PDFdownloadDownload figure
Table 11-4: The equally split OD matrix This is the simplest method for seed generation. As the name suggests, an equal proportion is assigned to all destinations. In the Test case (Figure 11-6) with 3 destinations, the method concludes that D1, D2 and D3 are equally likely for trips from origin O1 and O2, so the proportion will be 1/3 (33.3%). 1) The Equally Split OD matrix

Table 11 -4: The equally split OD matrix This is the simplest method for seed generation. As the name suggests, an equal proportion is assigned to all destinations. In the Test case (Figure 11-6) with 3 destinations, the method concludes that D1, D2 and D3 are equally likely for trips from origin O1 and O2, so the proportion will be 1/3 (33.3%). 1) The Equally Split OD matrix

Related Figures (126)

Figure 1-1: Illustration of available BSF system components These informal requirements have lead to the creation of a distributed environment called the ‘Bath Sensor Framework’ (BSF) [18], whose primary features are: (i) a bus-like communications system based on the eXtended Messaging and Presence Protocol (XMPP) [27], and (ii) a publish/subscribe interface that can be implemented for a variety of programming languages (we currently use Java, C# and Python). Similar XMPP-based approaches have been demonstrated in other distributed applications [24, 26]. A notable additional aspect of our framework is the adoption of two de-facto standard messaging formats: (i) Resource Description Framework (RDF), allowing the association of semantics with messages by reference to common ontologies, and (ii) JSON, allowing the low-overhead communication of structured data. Simulation components interact via publish-subscribe, where each component provides a ‘Sensor’ (output) and ‘Sensor Client’ (input), that connect to topic nodes in an XMPP server.
Figure 1-1: Illustration of available BSF system components These informal requirements have lead to the creation of a distributed environment called the ‘Bath Sensor Framework’ (BSF) [18], whose primary features are: (i) a bus-like communications system based on the eXtended Messaging and Presence Protocol (XMPP) [27], and (ii) a publish/subscribe interface that can be implemented for a variety of programming languages (we currently use Java, C# and Python). Similar XMPP-based approaches have been demonstrated in other distributed applications [24, 26]. A notable additional aspect of our framework is the adoption of two de-facto standard messaging formats: (i) Resource Description Framework (RDF), allowing the association of semantics with messages by reference to common ontologies, and (ii) JSON, allowing the low-overhead communication of structured data. Simulation components interact via publish-subscribe, where each component provides a ‘Sensor’ (output) and ‘Sensor Client’ (input), that connect to topic nodes in an XMPP server.
Figure 1-2: rdfMonitor Tool Most improvements in BSF reliability have been found in improving the XMPP server, both in terms of software and hardware configuration. Issues such as poorly configured WiFi cards and lossy networks, combined with poor out of the box configuration in some XMPP server software, led to the development of some basic ‘RDF Utilities’ being included in the BSF. The criticality of having such reliability has led to a number of network tests being included as part of the build process (and reported back to a Jenkins' build server) as otherwise any simulation may appear to work but have totally unreliable results.
Figure 1-2: rdfMonitor Tool Most improvements in BSF reliability have been found in improving the XMPP server, both in terms of software and hardware configuration. Issues such as poorly configured WiFi cards and lossy networks, combined with poor out of the box configuration in some XMPP server software, led to the development of some basic ‘RDF Utilities’ being included in the BSF. The criticality of having such reliability has led to a number of network tests being included as part of the build process (and reported back to a Jenkins' build server) as otherwise any simulation may appear to work but have totally unreliable results.
Figure 1-4: M25 Scenario in 3D viewer
Figure 1-4: M25 Scenario in 3D viewer
Figure 1-5: City Scenario in 3D viewer
Figure 1-5: City Scenario in 3D viewer
In this scenario, the desire is to measure effect of the institution in managing vehicle arrival times at traffic lights. The key metric being used is the measurement of fuel consumption, as the premise is that by modifying the vehicle speed such that it arrives at the traffic lights when they are green, it will result in less wasted fuel sat idling, and less fuel consumed in accelerating from stationary. In Figure 1-7 the results of two experiments are shown, showing the contrast between running the scenarios with and without institution involvement. In the case of no institution, the vehicle progresses along its route, until it is held up by a red light at a junction. This results in fuel expended while sat idling, and also in fuel required to accelerate from rest after 47s
In this scenario, the desire is to measure effect of the institution in managing vehicle arrival times at traffic lights. The key metric being used is the measurement of fuel consumption, as the premise is that by modifying the vehicle speed such that it arrives at the traffic lights when they are green, it will result in less wasted fuel sat idling, and less fuel consumed in accelerating from stationary. In Figure 1-7 the results of two experiments are shown, showing the contrast between running the scenarios with and without institution involvement. In the case of no institution, the vehicle progresses along its route, until it is held up by a red light at a junction. This results in fuel expended while sat idling, and also in fuel required to accelerate from rest after 47s
Javing demonstrated potential benefits in the combination of the SA approach anc nstitutional governance in the two scenarios presented, future work is planned to extenc hese into a larger, multiple institution scenario. One such example under consideration i: shown in Figure 1-8, where a stationary vehicle is causing disruption. This particular example s an extension to the existing flash-lights scenario, where the following vehicle did not reduce ts speed for some reason and collided with the vehicle ahead. There is now some post: accident traffic flow management required, with a potential dynamically instantiatec nstitutional agreements indicated numerically. Institution number 1 allows the first vehicle tc nove one lane right but requires the approaching vehicle to slow down. Similarly institutior vumber 2 allows the second queued vehicle to move one lane left, but requires the oncoming lorry to slow down, and finally institution number 3 allows the last stationan vehicle to move one lane right.
Javing demonstrated potential benefits in the combination of the SA approach anc nstitutional governance in the two scenarios presented, future work is planned to extenc hese into a larger, multiple institution scenario. One such example under consideration i: shown in Figure 1-8, where a stationary vehicle is causing disruption. This particular example s an extension to the existing flash-lights scenario, where the following vehicle did not reduce ts speed for some reason and collided with the vehicle ahead. There is now some post: accident traffic flow management required, with a potential dynamically instantiatec nstitutional agreements indicated numerically. Institution number 1 allows the first vehicle tc nove one lane right but requires the approaching vehicle to slow down. Similarly institutior vumber 2 allows the second queued vehicle to move one lane left, but requires the oncoming lorry to slow down, and finally institution number 3 allows the last stationan vehicle to move one lane right.
The given data included representations of the areas around the “Andrea Costa” and the “Pasubio” roads, as input files for the commercial microscopic traffic simulation Vissim, product of PTV AG. Each of the scenarios included the demand for Bologna’s peak hou (8:00am — 9:00am). Additional data sets supported by the municipality of Bologna includec positions of traffic lights, traffic light plans, inductive loop positions and measures and man\ others. A further scenario, “joined”, was implemented within iTETRIS by merging both Vissirr scenarios.
The given data included representations of the areas around the “Andrea Costa” and the “Pasubio” roads, as input files for the commercial microscopic traffic simulation Vissim, product of PTV AG. Each of the scenarios included the demand for Bologna’s peak hou (8:00am — 9:00am). Additional data sets supported by the municipality of Bologna includec positions of traffic lights, traffic light plans, inductive loop positions and measures and man\ others. A further scenario, “joined”, was implemented within iTETRIS by merging both Vissirr scenarios.
Table 2-1: Selected views on the A. Costa scenario from iTETRIS
Table 2-1: Selected views on the A. Costa scenario from iTETRIS
Table 2-2: Selected views on the Pasubio scenario from iTETRIS
Table 2-2: Selected views on the Pasubio scenario from iTETRIS
Table 2-3: Selected views on the "joined" scenario from iTETRIS
Table 2-3: Selected views on the "joined" scenario from iTETRIS
Figure 2-2: Example traffic flow of three days; blue: 11.11., red 12.11., green: 13.11.
Figure 2-2: Example traffic flow of three days; blue: 11.11., red 12.11., green: 13.11.
Table 2-4: Comparison of the simulated traffic flow compare to the measured traffic flow from the detecto
Table 2-4: Comparison of the simulated traffic flow compare to the measured traffic flow from the detecto
Table 2-4 shows the comparison of the average values of real measures from all detectors within the according area for the time between 8:00 and 9:00 against the ones obtained from the simulation using the demands imported from VISSIM. Two comparisons are given for each scenario: the left one shows the comparison between the real flow and the simulation results for the vehicles which passed the simulated detectors within the same time. Within the right comparison, the real world measures are put against all simulated vehicles (until the simulation ends). For both, the optimal results would be a bisectrix.
Table 2-4 shows the comparison of the average values of real measures from all detectors within the according area for the time between 8:00 and 9:00 against the ones obtained from the simulation using the demands imported from VISSIM. Two comparisons are given for each scenario: the left one shows the comparison between the real flow and the simulation results for the vehicles which passed the simulated detectors within the same time. Within the right comparison, the real world measures are put against all simulated vehicles (until the simulation ends). For both, the optimal results would be a bisectrix.
The TLC (Traffic Light Controller) blocks in the diagram are the real-world traffic light control executables. They accept either detection cards and lamp control units or SimInterface to work properly. The Siminterface is a C++ dynamic link a connection to the ibrary (dll) that can maintain connection to multiple TLCs at once. On the other side it can connect to any external application that supports the dll. This has been used to connec simulators Vissim, Paramics and Aimsun. For SUMO an intermediate block has been created in Java that supports both the dll and can talk to TraC t to the commercial the Sumolnterface, to get information < from SUMO. The flow of information consists of 2 main flows, detection information going from SUMO to the TLCs and signal group status from the TLCs to SUMO. The architecture of the interface and all involved components is described in the picture below.
The TLC (Traffic Light Controller) blocks in the diagram are the real-world traffic light control executables. They accept either detection cards and lamp control units or SimInterface to work properly. The Siminterface is a C++ dynamic link a connection to the ibrary (dll) that can maintain connection to multiple TLCs at once. On the other side it can connect to any external application that supports the dll. This has been used to connec simulators Vissim, Paramics and Aimsun. For SUMO an intermediate block has been created in Java that supports both the dll and can talk to TraC t to the commercial the Sumolnterface, to get information < from SUMO. The flow of information consists of 2 main flows, detection information going from SUMO to the TLCs and signal group status from the TLCs to SUMO. The architecture of the interface and all involved components is described in the picture below.
Figure 3-2 shows a loop c that has a length of 20 meters. Whe maximally 12 meters behi make the vehicle stop, sin ose to thes nd the stop! utilize part of the amber Oe topline and a longer loop at around 15 meters behind it na vehicle leaves this loop, the front of the vehicle is ine. Turning the light to amber at this moment will not ce the distance Is less than 1 second. This enables the controller to time by letti ng the last vehicle of the platoon pass through during amber. This technique of detecting the end of the platoon would also work at the stopline, out then the amber time cannot be utilized. The reason for using a long loop of 20 meters is to deal with small gaps in platoons due to different acceleration rates. If the loop would be shorter, a threshold gap time would have to be introduced that would make usage of the amber time impossible. The most usable alternative would be a small loop at 15+20 = 35 meters from the stopline, but its working would be based on a presumed fixed vehicle speed, which is inaccurate close to an intersection. Additionally, this work focusses on simulating real world controllers and the original controllers expect long area loops. Connecting different oops in the simulator will give different behavior unless parameters inside the controllers are changed. Detection is a key element for a controller, because without it only fixed ti possible. Therefore, having proper detection functionality is vital for accura SUMO supports 3 different kinds of detectors, inductive loop, lane area and mu exit detectors. Current traffic control is mostly based on detectors that cover an this can be an inductive loop, but also a marked area in a video detector. original inductive loop detector of SUMO is actually not sufficient for simulation, since it’s an infinitely small detector that doesn’t cover an area in a lane, but just point on the lane. Even real world inductive loops cover larger areas, so a real inductive loop cannot be modelled accurately with a SUMO inductive loop. Many vehicle actuated strategi me contro ti-entry mu Therefore, traffic con is te simulation. ti- area in a lane, the trol a es use long area detectors of up to 30 meters to cut off the green phase at an efficient moment.
Figure 3-2 shows a loop c that has a length of 20 meters. Whe maximally 12 meters behi make the vehicle stop, sin ose to thes nd the stop! utilize part of the amber Oe topline and a longer loop at around 15 meters behind it na vehicle leaves this loop, the front of the vehicle is ine. Turning the light to amber at this moment will not ce the distance Is less than 1 second. This enables the controller to time by letti ng the last vehicle of the platoon pass through during amber. This technique of detecting the end of the platoon would also work at the stopline, out then the amber time cannot be utilized. The reason for using a long loop of 20 meters is to deal with small gaps in platoons due to different acceleration rates. If the loop would be shorter, a threshold gap time would have to be introduced that would make usage of the amber time impossible. The most usable alternative would be a small loop at 15+20 = 35 meters from the stopline, but its working would be based on a presumed fixed vehicle speed, which is inaccurate close to an intersection. Additionally, this work focusses on simulating real world controllers and the original controllers expect long area loops. Connecting different oops in the simulator will give different behavior unless parameters inside the controllers are changed. Detection is a key element for a controller, because without it only fixed ti possible. Therefore, having proper detection functionality is vital for accura SUMO supports 3 different kinds of detectors, inductive loop, lane area and mu exit detectors. Current traffic control is mostly based on detectors that cover an this can be an inductive loop, but also a marked area in a video detector. original inductive loop detector of SUMO is actually not sufficient for simulation, since it’s an infinitely small detector that doesn’t cover an area in a lane, but just point on the lane. Even real world inductive loops cover larger areas, so a real inductive loop cannot be modelled accurately with a SUMO inductive loop. Many vehicle actuated strategi me contro ti-entry mu Therefore, traffic con is te simulation. ti- area in a lane, the trol a es use long area detectors of up to 30 meters to cut off the green phase at an efficient moment.
Figure 3- 3: Problem with detector location and stopping distance As described in the architecture section, the update time for detectors is 100ms. This is done in order to never miss any detection. Motorcyc es can be as short as 2 meters and on the highway, the speed can be over 30 meters per second. This means they occupy a detector for only 100 milliseconds. When vehicles are shorte be required. In urban environments with longer speeds are lower by checking the detectors less only required to check every 300ms. r and drive faster, a shorter update time will vehicles the simulation may speed up when frequent. For 4 meter vehicles at 15 mm/s, it is
Figure 3- 3: Problem with detector location and stopping distance As described in the architecture section, the update time for detectors is 100ms. This is done in order to never miss any detection. Motorcyc es can be as short as 2 meters and on the highway, the speed can be over 30 meters per second. This means they occupy a detector for only 100 milliseconds. When vehicles are shorte be required. In urban environments with longer speeds are lower by checking the detectors less only required to check every 300ms. r and drive faster, a shorter update time will vehicles the simulation may speed up when frequent. For 4 meter vehicles at 15 mm/s, it is
This is done for the scenario of Assen-Noord, a small network in the north of the Dutch city Assen. The network only has pedestrian and bicycle crossings at the middle left intersection. All other intersections have just vehicles. The larger traffic streams (up to 1500 vehicles per hour) are going north-south on both sides of the network and the major bottleneck is the bottom intersection where the two north-south streams come together. When watching the simulations in both Vissim and SUMO, no clear differences could be noted, except the uniformity of SUMOs vehicle injection and that all vehicles have the same acceleration at the stopline. SUMO was used in a standard way creating the routes with a trip file that would inject vehicles with a constant time period in the resulting .rou.xml. Evaluation in Vissim was done by putting a travel time section for each signal group and in SUMO a multi-entry multi-exit detector.
This is done for the scenario of Assen-Noord, a small network in the north of the Dutch city Assen. The network only has pedestrian and bicycle crossings at the middle left intersection. All other intersections have just vehicles. The larger traffic streams (up to 1500 vehicles per hour) are going north-south on both sides of the network and the major bottleneck is the bottom intersection where the two north-south streams come together. When watching the simulations in both Vissim and SUMO, no clear differences could be noted, except the uniformity of SUMOs vehicle injection and that all vehicles have the same acceleration at the stopline. SUMO was used in a standard way creating the routes with a trip file that would inject vehicles with a constant time period in the resulting .rou.xml. Evaluation in Vissim was done by putting a travel time section for each signal group and in SUMO a multi-entry multi-exit detector.
Figure 4-2: Edge movement by netconvert (left) and corrected version (right)
Figure 4-2: Edge movement by netconvert (left) and corrected version (right)
The conversion process builds on the information acquired for converting the regular streets and connectors to nodes and edges. A distinction is made between controlled and non- controlled intersections. The latter are regular junctions in SUMO that should be made as small as possible to resemble the original network topology the best. They need small corrections for the same reason as the edges. The main goal of these small junctions is to make the network look better and prevent situations like these:
The conversion process builds on the information acquired for converting the regular streets and connectors to nodes and edges. A distinction is made between controlled and non- controlled intersections. The latter are regular junctions in SUMO that should be made as small as possible to resemble the original network topology the best. They need small corrections for the same reason as the edges. The main goal of these small junctions is to make the network look better and prevent situations like these:
he yeTWw ecta figure shows a number of segments of an edge in a corner, there are openings i een them on the outer side of the curvature because they are displayed as pur ngles. Between two edges this can be prevented by defining the junction as a triangl hat fills this gap. Similar effects occur when multiple lanes are connected and the junctio hou d form a shape that fills the gap between the lanes smoothly.
he yeTWw ecta figure shows a number of segments of an edge in a corner, there are openings i een them on the outer side of the curvature because they are displayed as pur ngles. Between two edges this can be prevented by defining the junction as a triangl hat fills this gap. Similar effects occur when multiple lanes are connected and the junctio hou d form a shape that fills the gap between the lanes smoothly.
tigure below: Figure 4-5: Ordering of incoming and outgoing lanes of an intersection The intersection polygon shape is then defined by first taking the two points of end of th incoming edge marked with 1 in the figure. This process is shown by the green line in th figu link beg resu 1 and the first of | It can be seen in COO re and continues the same way for the 2™ lane, drawing a line between the last point ¢ ink 2. For link 3 it is a bit different because the two points are th inning of the outgoing edge. The last line is drawn between edge 11 and edge 1 t complete the polygon. 1 [he same procedure is followed for each intersection and an exampl Figure 4-3. In the .net.xml file this results in a long series of 2 rdinates for the shape variable of the junction.
tigure below: Figure 4-5: Ordering of incoming and outgoing lanes of an intersection The intersection polygon shape is then defined by first taking the two points of end of th incoming edge marked with 1 in the figure. This process is shown by the green line in th figu link beg resu 1 and the first of | It can be seen in COO re and continues the same way for the 2™ lane, drawing a line between the last point ¢ ink 2. For link 3 it is a bit different because the two points are th inning of the outgoing edge. The last line is drawn between edge 11 and edge 1 t complete the polygon. 1 [he same procedure is followed for each intersection and an exampl Figure 4-3. In the .net.xml file this results in a long series of 2 rdinates for the shape variable of the junction.
Figure 4-6: Complicated intersections for conversion Signal groups are by definition in the end of an edge in SUMO and cannot be in the middle. In the previous section the signal groups in SUMO were already defined in the form of the connection entries per junction. This may be a problem when an intersection has a more complicated shape, with signal groups in the middle of the rectangular intersection area, like shown in the figure below:
Figure 4-6: Complicated intersections for conversion Signal groups are by definition in the end of an edge in SUMO and cannot be in the middle. In the previous section the signal groups in SUMO were already defined in the form of the connection entries per junction. This may be a problem when an intersection has a more complicated shape, with signal groups in the middle of the rectangular intersection area, like shown in the figure below:
The loops close to the stopline are just 1 meter long and can still be modeled with a SUMO inductionloop, but the second loop is often longer than 25 meters and cannot be modelled with an inductionloop that has a length of 0. This would significantly change the behavior of the traffic light controller and therefore lane area detectors have been used as output of the convertor. More details on the importance of accurate detection can be found in [5]. For the rest the conversion is very straightforward, in Imflow and Vissim format the detectors are specified on which street or connector they are, at which distance from the beginning and their length. Those variables can simply be copied into the format of the .det.xml file for SUMO. Adding the file to the .sumo.cfg will then make the detectors available for the Se pal 1 RELAR
The loops close to the stopline are just 1 meter long and can still be modeled with a SUMO inductionloop, but the second loop is often longer than 25 meters and cannot be modelled with an inductionloop that has a length of 0. This would significantly change the behavior of the traffic light controller and therefore lane area detectors have been used as output of the convertor. More details on the importance of accurate detection can be found in [5]. For the rest the conversion is very straightforward, in Imflow and Vissim format the detectors are specified on which street or connector they are, at which distance from the beginning and their length. Those variables can simply be copied into the format of the .det.xml file for SUMO. Adding the file to the .sumo.cfg will then make the detectors available for the Se pal 1 RELAR
Smart Quadtrees, also referred as grid based partitioning, are an extension to Quadtrees where the map is initially divided into small, independent grids. These grids are then merged together according to some heuristic, based on the value of an individual region. This differs to Quadtrees as Quadtree divides a map into 4 similar regions, while Smart Quadtrees divides a map into small grids and merges them until all grids are merged. Figure 5-1: Output of the modified Quadtree algorithm (left) and unmodified Quadtree (right) with ten partitions or three divisions.
Smart Quadtrees, also referred as grid based partitioning, are an extension to Quadtrees where the map is initially divided into small, independent grids. These grids are then merged together according to some heuristic, based on the value of an individual region. This differs to Quadtrees as Quadtree divides a map into 4 similar regions, while Smart Quadtrees divides a map into small grids and merges them until all grids are merged. Figure 5-1: Output of the modified Quadtree algorithm (left) and unmodified Quadtree (right) with ten partitions or three divisions.
Figure 5-2: Output of the modified Smart Quadtree algorithm (left) and unmodified Smart Quadtree (right) with eight partitions.
Figure 5-2: Output of the modified Smart Quadtree algorithm (left) and unmodified Smart Quadtree (right) with eight partitions.
Figure 5-3: Output of the modified SParTSim algorithm (left) and unmodified SParTSim (right) with eight partitions. In this section, we evaluate the use of traffic volume data for Quadtrees, Smart Quadtrees and SParTSim. We divide the city for both Smart Quadtrees and SParTSim into four and eight partitions while we use for Quadtrees four and ten partitions. The visual partitioning outputs for Quadtrees with 10 partitions is shown in Figure 5-1, with the outputs for Smart Quadtrees with eight partitions is shown in Figure 5-2 and those for SParTSim are shown in Figure 5-3.
Figure 5-3: Output of the modified SParTSim algorithm (left) and unmodified SParTSim (right) with eight partitions. In this section, we evaluate the use of traffic volume data for Quadtrees, Smart Quadtrees and SParTSim. We divide the city for both Smart Quadtrees and SParTSim into four and eight partitions while we use for Quadtrees four and ten partitions. The visual partitioning outputs for Quadtrees with 10 partitions is shown in Figure 5-1, with the outputs for Smart Quadtrees with eight partitions is shown in Figure 5-2 and those for SParTSim are shown in Figure 5-3.
Figure 5-4: Number of messages sent per simulation step for Quadtrees (left) and Smart Quadtrees (right). Modified and unmodified versions are both shown.
Figure 5-4: Number of messages sent per simulation step for Quadtrees (left) and Smart Quadtrees (right). Modified and unmodified versions are both shown.
Figure 5-5: Number of messages sent per simulation step for SParTSim, both modified and unmodified for 4 and 8 partitions
Figure 5-5: Number of messages sent per simulation step for SParTSim, both modified and unmodified for 4 and 8 partitions
Comparing the different algorithms to each other shows that our modified Smart Quadtree produces more even partitions than the other partitioning algorithm. Our modified version of the Quadtree took 1h13min to compute 10 partitions, Smart Quadtree took 1h22min to compute eight partitions while SParTSim took 5h14min for eight partitions on a 4 Core I7- 2600 with 16GB of memory. As shown in [27, 28] load balanced simulations are a required to optimize the overall computation time. Table 5-1: Simpson diversity index for the different partitioning algorithms over the simulation.
Comparing the different algorithms to each other shows that our modified Smart Quadtree produces more even partitions than the other partitioning algorithm. Our modified version of the Quadtree took 1h13min to compute 10 partitions, Smart Quadtree took 1h22min to compute eight partitions while SParTSim took 5h14min for eight partitions on a 4 Core I7- 2600 with 16GB of memory. As shown in [27, 28] load balanced simulations are a required to optimize the overall computation time. Table 5-1: Simpson diversity index for the different partitioning algorithms over the simulation.
Table 6-1: Vehicle parameters and driver behaviors
Table 6-1: Vehicle parameters and driver behaviors
and Impatience). The table also contains data about the parameters used Tor the EV. of the traffic census. Straight arrows and the corresponding nu whereas angled arrows and percentage share of trucks trucks (Truck2) in a ratio of three groups in a ratio of maximal speeds, reaction ti comparable to the vehicles mbers indicate straight traffic corresponding numbers indicate turning traffic (left or right). The is 3% with a distribution of semi-trailer trucks (1 1: 1. The remaining road users are passenger Truck1) and shor cars divided intc > 2: 1 (Carl : Car2 : Car3). They differ in ve of the AOO segment. Type Car2 represents the Car3 equals the B segmen t, type Truck1 comprises of semitrailer trucks, hicle dimensions me of the driver, and driver attention. Values for type Car1 are A segment, type type Truck2 is < smaller truck, and type EV a fire truck. Values for the maximal acceleration and maxima deceleration consider a comfortable acceleration and are not equal to the maximal physica values. Table 6-1 shows vehicle related parameters and used driver models (minGap, Sigmé and Impatience). The table also contains data about the parameters used for the EV.
and Impatience). The table also contains data about the parameters used Tor the EV. of the traffic census. Straight arrows and the corresponding nu whereas angled arrows and percentage share of trucks trucks (Truck2) in a ratio of three groups in a ratio of maximal speeds, reaction ti comparable to the vehicles mbers indicate straight traffic corresponding numbers indicate turning traffic (left or right). The is 3% with a distribution of semi-trailer trucks (1 1: 1. The remaining road users are passenger Truck1) and shor cars divided intc > 2: 1 (Carl : Car2 : Car3). They differ in ve of the AOO segment. Type Car2 represents the Car3 equals the B segmen t, type Truck1 comprises of semitrailer trucks, hicle dimensions me of the driver, and driver attention. Values for type Car1 are A segment, type type Truck2 is < smaller truck, and type EV a fire truck. Values for the maximal acceleration and maxima deceleration consider a comfortable acceleration and are not equal to the maximal physica values. Table 6-1 shows vehicle related parameters and used driver models (minGap, Sigmé and Impatience). The table also contains data about the parameters used for the EV.
Figure 6-2: Collected data of a traffic census at the relevant intersections during the peak hour Figure 6-1: The simulated traffic system
Figure 6-2: Collected data of a traffic census at the relevant intersections during the peak hour Figure 6-1: The simulated traffic system
Figure 6-5: Flowchart showing the model “IV behavior”
Figure 6-5: Flowchart showing the model “IV behavior”
Figure 6-6: Flowchart to calibrate the IV behavior model (SetReactingDistance)
Figure 6-6: Flowchart to calibrate the IV behavior model (SetReactingDistance)
Table 6-2: Setup of the different tests
Table 6-2: Setup of the different tests
method is activated as this can be modeled by S over the introduction second. This variance is eads to direct interference (e.g. changing the that the EV is slowed down so that it does not a ight). At small introduction seconds, the first t introduction second 43, a green wave is establ caused by randomized behavior of IVs rrive within the green phase at the next raffic light is red and switches to green eads to a delay of the EV due to waiting vehicles and causes a travelling time around These vehicles have more time to start with increasing introduction time of the EV. Around ished with a travelling time of around UMO itself. The travelling time is not constant . This ane very late) and indirect interference (e.g. traffic . This 90 s. 65s. After that introduction second, the travelling time is increasing and has its maximum value (about 200s) around introduction second 78. Considering the data scope, noticeable differences around introduction second 50, 60, and 70 can be observed. These introduction seconds are mainly affected by waiting vehicles as the green wave breaks down and the EV has to wait for one complete cycle to cross at least one of the intersections. Figure 6-9 shows the simulation M2 with all three models activated. It shows that the travelling time depends on the introduction second. Moreover, there are different values for one introduction second. This distribution of values is also caused by randomized behavior of Vs. The trendline reveals four distinct areas that can be interpreted as follows. At introduction second 8 and travelling time around 100s, the EV approaches the first intersection while having a green light. The vehicles in line are already moving and are slowly clearing the path. n comparison with introduction seconds smaller than 8, the EV is approaching in an advantageous moment, because the waiting vehicles have some time to start. The second y ae |
method is activated as this can be modeled by S over the introduction second. This variance is eads to direct interference (e.g. changing the that the EV is slowed down so that it does not a ight). At small introduction seconds, the first t introduction second 43, a green wave is establ caused by randomized behavior of IVs rrive within the green phase at the next raffic light is red and switches to green eads to a delay of the EV due to waiting vehicles and causes a travelling time around These vehicles have more time to start with increasing introduction time of the EV. Around ished with a travelling time of around UMO itself. The travelling time is not constant . This ane very late) and indirect interference (e.g. traffic . This 90 s. 65s. After that introduction second, the travelling time is increasing and has its maximum value (about 200s) around introduction second 78. Considering the data scope, noticeable differences around introduction second 50, 60, and 70 can be observed. These introduction seconds are mainly affected by waiting vehicles as the green wave breaks down and the EV has to wait for one complete cycle to cross at least one of the intersections. Figure 6-9 shows the simulation M2 with all three models activated. It shows that the travelling time depends on the introduction second. Moreover, there are different values for one introduction second. This distribution of values is also caused by randomized behavior of Vs. The trendline reveals four distinct areas that can be interpreted as follows. At introduction second 8 and travelling time around 100s, the EV approaches the first intersection while having a green light. The vehicles in line are already moving and are slowly clearing the path. n comparison with introduction seconds smaller than 8, the EV is approaching in an advantageous moment, because the waiting vehicles have some time to start. The second y ae |
‘he travelling time of test A2 is represented by the graph in Figure 6-11. The gray area ery distinct as the IV behavior and the drive through red lights models are deactivated. is not Thus, t is comparable to the simulation M1 with the difference that the preemption system is ictivated. The course of the trendline starts at a travelling time of about 95 seconds, then Jeclines to a minimum around 80 seconds at introduction second 36 and eventually rises to a naximum of 105 seconds around introduction second 75. [he dropping course of the rendline can be explainable by the EV encountering delays due to waiting vehicles at the ntersections. The preemption allows vehicles to clear the intersection earlier. For ntroduction seconds, the preemption gets more efficient by holding the green phases. 4 minimum around introduction second 35, the EV reaches the first traffic light w later After hile it hanges to red. The preemption takes some time and does not switch to green fast enough vhich causes the EV to slow down. As none of the two models IV reaction and drive th ed light is active, IVs do not clear the lane while waiting at a red traffic light to let t Irive through. Additionally, they stay in the EV’s lane and obstruct its mission unti rough he EV they oluntary change the lane. The maxima at introduction second 64 and 68-79 are caused by his effect at different or multiple intersections.
‘he travelling time of test A2 is represented by the graph in Figure 6-11. The gray area ery distinct as the IV behavior and the drive through red lights models are deactivated. is not Thus, t is comparable to the simulation M1 with the difference that the preemption system is ictivated. The course of the trendline starts at a travelling time of about 95 seconds, then Jeclines to a minimum around 80 seconds at introduction second 36 and eventually rises to a naximum of 105 seconds around introduction second 75. [he dropping course of the rendline can be explainable by the EV encountering delays due to waiting vehicles at the ntersections. The preemption allows vehicles to clear the intersection earlier. For ntroduction seconds, the preemption gets more efficient by holding the green phases. 4 minimum around introduction second 35, the EV reaches the first traffic light w later After hile it hanges to red. The preemption takes some time and does not switch to green fast enough vhich causes the EV to slow down. As none of the two models IV reaction and drive th ed light is active, IVs do not clear the lane while waiting at a red traffic light to let t Irive through. Additionally, they stay in the EV’s lane and obstruct its mission unti rough he EV they oluntary change the lane. The maxima at introduction second 64 and 68-79 are caused by his effect at different or multiple intersections.
Table 7-1 Performance metrics for old and new lane-changing model and different scenarios.
Table 7-1 Performance metrics for old and new lane-changing model and different scenarios.
Figure 7-5 Evolution of lane usage over space for a 3-lane motorway section Current measurements are promising but indicate room for improvement. Figure 7-5 and Figure 7- show the evolution of simulated traffic measurements with the leftmost data points being taken directly from traffic measurements on the German motorway A3 whereas data points to the right are measured at successive points on an otherwise featureless 3 lane road. It can be seen that vehicles more or less maintain the lane distribution and speeds which were measured in reality. Numbers are averaged over a simulated period of 24 hours.
Figure 7-5 Evolution of lane usage over space for a 3-lane motorway section Current measurements are promising but indicate room for improvement. Figure 7-5 and Figure 7- show the evolution of simulated traffic measurements with the leftmost data points being taken directly from traffic measurements on the German motorway A3 whereas data points to the right are measured at successive points on an otherwise featureless 3 lane road. It can be seen that vehicles more or less maintain the lane distribution and speeds which were measured in reality. Numbers are averaged over a simulated period of 24 hours.
Emission Model”) [15, 16] which derivate was included in SUMO, see section 8.5.2, is one of such models. Its sub modules and their inter-dependencies are shown in Figure 8-1. Figure 8-1: Schematic representation of the PHEM emission model [18].
Emission Model”) [15, 16] which derivate was included in SUMO, see section 8.5.2, is one of such models. Its sub modules and their inter-dependencies are shown in Figure 8-1. Figure 8-1: Schematic representation of the PHEM emission model [18].
PHEMlight uses characteristic emission curves which define the emission amount [g/h] as function of the actual engine power of the vehicle. These characteristic curves were computed using PHEM with representative dynamic real word driving cycles. The amounts o° amissions produced by a vehicle (as well as the amount of consumed fuel) during a simulatior step is determined by computing the power needed by the vehicle as shown in the followinc “igure 8-2, first. Then, this value is used to look up the characteristic emission curves.
PHEMlight uses characteristic emission curves which define the emission amount [g/h] as function of the actual engine power of the vehicle. These characteristic curves were computed using PHEM with representative dynamic real word driving cycles. The amounts o° amissions produced by a vehicle (as well as the amount of consumed fuel) during a simulatior step is determined by computing the power needed by the vehicle as shown in the followinc “igure 8-2, first. Then, this value is used to look up the characteristic emission curves.
Table 8-1: A comparison of features for the three implemented models.
Table 8-1: A comparison of features for the three implemented models.
Figure 8-3: Examples of emissions visualization in SUMO; left: CO2 emitted in the last time step by individual vehicles, right: lanes colored by the amount of fuel consumed in the last step by vehicles that were on the respective lane [12].
Figure 8-3: Examples of emissions visualization in SUMO; left: CO2 emitted in the last time step by individual vehicles, right: lanes colored by the amount of fuel consumed in the last step by vehicles that were on the respective lane [12].
a I a A a a aa mar: ‘ili The German Aerospace Center (DLR) developed a traffic monitoring approach, called DYNAMIC [1, 7], which combines the advantages of Floating Car Data (FCD) and Floating Observer Data (FOD) principles. DYNAMIC is based on detections which are made by floating traffic observers using wireless radio-based technologies such as Bluetooth while passing other traffic objects (vehicles, cyclists, pedestrians). For the evaluation of the performance of DYNAMIC it is crucial to know how likely it is that a detectable traffic object (i.e. with Bluetooth device on board) within the detection range will be monitored. The major point to answer this question is the inquiry process which sets up the connection between Bluetooth devices and which can take up to several seconds. Given the possibly high speed of the vehicles and the relatively small detection range this poses a major problem to this detection mechanism. This paper focusses on a simple model for the inquiry process, describes its outcomings and the implementation of the process in the Bluetooth model of SUMO [2, 6] and compares it to real world measurements. The first section will focus on the analytical part, the second will describe the implementation in SUMO and the scenario used for evaluation and finally we will compare the theoretical and the simulative results with real world measurements.
a I a A a a aa mar: ‘ili The German Aerospace Center (DLR) developed a traffic monitoring approach, called DYNAMIC [1, 7], which combines the advantages of Floating Car Data (FCD) and Floating Observer Data (FOD) principles. DYNAMIC is based on detections which are made by floating traffic observers using wireless radio-based technologies such as Bluetooth while passing other traffic objects (vehicles, cyclists, pedestrians). For the evaluation of the performance of DYNAMIC it is crucial to know how likely it is that a detectable traffic object (i.e. with Bluetooth device on board) within the detection range will be monitored. The major point to answer this question is the inquiry process which sets up the connection between Bluetooth devices and which can take up to several seconds. Given the possibly high speed of the vehicles and the relatively small detection range this poses a major problem to this detection mechanism. This paper focusses on a simple model for the inquiry process, describes its outcomings and the implementation of the process in the Bluetooth model of SUMO [2, 6] and compares it to real world measurements. The first section will focus on the analytical part, the second will describe the implementation in SUMO and the scenario used for evaluation and finally we will compare the theoretical and the simulative results with real world measurements.
Figure 9-2: Model of the inquiry process with two scanning intervals of length 1 Assuming a length of the scanning interval of I then the target frequency is one point in each of the successive intervals. The task is now to calculate the probability that another interval of length t (modelling the travel time in the detection range) contains at least one of the points.
Figure 9-2: Model of the inquiry process with two scanning intervals of length 1 Assuming a length of the scanning interval of I then the target frequency is one point in each of the successive intervals. The task is now to calculate the probability that another interval of length t (modelling the travel time in the detection range) contains at least one of the points.
A comparison of the three function shows the picture below
A comparison of the three function shows the picture below
Figure 9-4: Test track scenario in the final SUMO simulation (green points denote the bluetooth detectors)
Figure 9-4: Test track scenario in the final SUMO simulation (green points denote the bluetooth detectors)
SS BOO eee ae see, =e SS za ee ‘Se OL See ee ee ee SS lS Selo timestamp, BTsender-ID and signal strength value was stored to a log file. Figure 9-5 illustrates the results from the laboratory test. For the varying number of BIr eceivers and/or BTsenders the probability density is given. There you can see that more than 80% of all detections are realised within a time interval of 1 second (1000 milliseconds). For the probability density we looked at the intertimes. The intertimes are the time differences between a detection of a BTsender and the starting time of the inquiry mode of the BIr eceiver respectively a previous detection time of that specific BTsender. That means the intertimes are exactly that times it took a BTreceiver to detect a BTsender provided it is in the de tection range. In the laboratory test nearly 100% of all detectable devices were detected after 3 seconds independent of the number of BTreceivers and BTsenders. In the laboratory test almost perfect conditions were given for the BTreceiver to detect BTsenders. The reality looks somewhat different — besides several error sources (e.g. Bluetooth signal reflections or shading effects) the to be detected BTsenders are moving objects which makes detection less likely since the BTsenders are not permanently within detection range. Furthermore, the speed factor reduces the time the BTsender is within detection range additionally.
SS BOO eee ae see, =e SS za ee ‘Se OL See ee ee ee SS lS Selo timestamp, BTsender-ID and signal strength value was stored to a log file. Figure 9-5 illustrates the results from the laboratory test. For the varying number of BIr eceivers and/or BTsenders the probability density is given. There you can see that more than 80% of all detections are realised within a time interval of 1 second (1000 milliseconds). For the probability density we looked at the intertimes. The intertimes are the time differences between a detection of a BTsender and the starting time of the inquiry mode of the BIr eceiver respectively a previous detection time of that specific BTsender. That means the intertimes are exactly that times it took a BTreceiver to detect a BTsender provided it is in the de tection range. In the laboratory test nearly 100% of all detectable devices were detected after 3 seconds independent of the number of BTreceivers and BTsenders. In the laboratory test almost perfect conditions were given for the BTreceiver to detect BTsenders. The reality looks somewhat different — besides several error sources (e.g. Bluetooth signal reflections or shading effects) the to be detected BTsenders are moving objects which makes detection less likely since the BTsenders are not permanently within detection range. Furthermore, the speed factor reduces the time the BTsender is within detection range additionally.
their desired speed respectively to local feasibility and under consideration of the Germar Road Traffic Act (StVO).
their desired speed respectively to local feasibility and under consideration of the Germar Road Traffic Act (StVO).
Figure 9-7: Probability density for field test results on Ernst-Ruska-Ufer (left: two-hour test on August 20" 2013; right: permanent stationary Bluetooth detection) ee =e The results of the stationary Bluetooth measurements are given in Figure 9-7. The left figure shows the results from the specific field test day (August 20th 2013). For higher reliability we permanently installed our BluBs at two points of the Ernst-Ruska-Ufer for several months so that we could benefit from long-term measurements. The right figure shows the results from the long-term measurements. It is obvious that the probability density is quite similar. Due to still undefined explicit error values the increase is less sharp in comparison to the laboratory data. Especially between 1 and 6 seconds the course of the function is smoother than that under laboratory conditions. Still unclear are effects where no inclination is observable within longer time slots (e.g. from 1500ms to 5000ms in the left figure and from 2000ms to nearly 4000ms in the right figure). It would mean that there were no inquiry times which are that long. Since there are even longer time periods in the data it might have a methodical reason.
Figure 9-7: Probability density for field test results on Ernst-Ruska-Ufer (left: two-hour test on August 20" 2013; right: permanent stationary Bluetooth detection) ee =e The results of the stationary Bluetooth measurements are given in Figure 9-7. The left figure shows the results from the specific field test day (August 20th 2013). For higher reliability we permanently installed our BluBs at two points of the Ernst-Ruska-Ufer for several months so that we could benefit from long-term measurements. The right figure shows the results from the long-term measurements. It is obvious that the probability density is quite similar. Due to still undefined explicit error values the increase is less sharp in comparison to the laboratory data. Especially between 1 and 6 seconds the course of the function is smoother than that under laboratory conditions. Still unclear are effects where no inclination is observable within longer time slots (e.g. from 1500ms to 5000ms in the left figure and from 2000ms to nearly 4000ms in the right figure). It would mean that there were no inquiry times which are that long. Since there are even longer time periods in the data it might have a methodical reason.
Figure 9-8: Probability density for field test results on Ernst-Ruska-Ufer using moving observer (cars) The results collected from moving Bluetooth observer vehicles are illustrated in Figure 9-8. The course of the functions is similar to that of the stationary Bluetooth measurements for all four observers even if that of observer car 1 seems to be more consistent. A reason might be the amount of collected data which was the biggest from car 1. Interesting is that the same effect of time slots without inclination is observable in that case as well. It seems to occur always between approximately 2000ms and 7000ms.
Figure 9-8: Probability density for field test results on Ernst-Ruska-Ufer using moving observer (cars) The results collected from moving Bluetooth observer vehicles are illustrated in Figure 9-8. The course of the functions is similar to that of the stationary Bluetooth measurements for all four observers even if that of observer car 1 seems to be more consistent. A reason might be the amount of collected data which was the biggest from car 1. Interesting is that the same effect of time slots without inclination is observable in that case as well. It seems to occur always between approximately 2000ms and 7000ms.
Figure 9-9: Probability density for additional field test results on WISTA area using cars and cyclists as moving observers In addition to the field test on Ernst-Ruska-Ufer, several test runs with 8 moving observers using multimodal BTreceiver objects (i.e. cars and cyclists) were conducted on other routes on the WISTA area (Figure 6) to see whether the results affirm our conclusion. These additiona field tests took even place on August 20th 2013, but from 9 a.m. to 10 a.m. and 1 p.m. to 3 p.m. Note that in these field tests observer car 3 (red line) had some major problems in collecting data. Nevertheless the results from these area wide measurements show better accordance with the results derived from laboratory tests.
Figure 9-9: Probability density for additional field test results on WISTA area using cars and cyclists as moving observers In addition to the field test on Ernst-Ruska-Ufer, several test runs with 8 moving observers using multimodal BTreceiver objects (i.e. cars and cyclists) were conducted on other routes on the WISTA area (Figure 6) to see whether the results affirm our conclusion. These additiona field tests took even place on August 20th 2013, but from 9 a.m. to 10 a.m. and 1 p.m. to 3 p.m. Note that in these field tests observer car 3 (red line) had some major problems in collecting data. Nevertheless the results from these area wide measurements show better accordance with the results derived from laboratory tests.
What we learn from this comparison is that the probability density seems to be best fitted by a exponential distribution which makes sense since the number of detections based on Bluetooth is a sequence of n independent seen/not seen trials each of which occurs with probability p. This follows from the assumption that the number of vehicles equipped with Bluetooth devices and the number of observer vehicles within the network is small, so that the chances to encounter are statistically independent events. Therefore, the existences of those encounter respectively detection events can be described using a exponential distribution.
What we learn from this comparison is that the probability density seems to be best fitted by a exponential distribution which makes sense since the number of detections based on Bluetooth is a sequence of n independent seen/not seen trials each of which occurs with probability p. This follows from the assumption that the number of vehicles equipped with Bluetooth devices and the number of observer vehicles within the network is small, so that the chances to encounter are statistically independent events. Therefore, the existences of those encounter respectively detection events can be described using a exponential distribution.
Figure 10-2: Computational engine to optimize signal parameters.
Figure 10-2: Computational engine to optimize signal parameters.
Figure 10-3: Scalability of parallel traffic simulations in the shared memory architecture. 10.4 Parallel traffic simulation
Figure 10-3: Scalability of parallel traffic simulations in the shared memory architecture. 10.4 Parallel traffic simulation
Figure 10-4: Layout of study intersections and its simulation model in SUMO out that the computational time is largely reduced by parallelized simulation in comparison to the execution time of the similar stochastic optimization process done early [17]. However, the speedup is still limited by the number of available processing units in machine when the value of p increases. For example, considering the case that 25 simulation runs are carried out, the speedup performance meets its threshold when the number of processes is larger than 14.
Figure 10-4: Layout of study intersections and its simulation model in SUMO out that the computational time is largely reduced by parallelized simulation in comparison to the execution time of the similar stochastic optimization process done early [17]. However, the speedup is still limited by the number of available processing units in machine when the value of p increases. For example, considering the case that 25 simulation runs are carried out, the speedup performance meets its threshold when the number of processes is larger than 14.
Figure 10-5: The phase rings for signal controls at the intersections in Stockholm.
Figure 10-5: The phase rings for signal controls at the intersections in Stockholm.
Table 10-2: Notation for the mathematical formulation in signal optimization.
Table 10-2: Notation for the mathematical formulation in signal optimization.
Figure 10-6: Optimization results of average delay. 10.5.1 Optimization problems
Figure 10-6: Optimization results of average delay. 10.5.1 Optimization problems
Table 10-3: Results of optimal signal plans without coordination. Table 10-3: Results of optimal signal plans with one-way coordination (offset 25 seconds).
Table 10-3: Results of optimal signal plans without coordination. Table 10-3: Results of optimal signal plans with one-way coordination (offset 25 seconds).
Table 10-4: Impacts of offset on signal optimization.
Table 10-4: Impacts of offset on signal optimization.
Figure 11-1: Sample highway segment Table 11-1: Possible OD matrices Where: bj = proportion of trip from i to j; Qi = on-ramp counts (origin flows); O; = off-ramp counts (destination flows).
Figure 11-1: Sample highway segment Table 11-1: Possible OD matrices Where: bj = proportion of trip from i to j; Qi = on-ramp counts (origin flows); O; = off-ramp counts (destination flows).
In this step, changes to the algorithm will be proposed and implemented. The adjustment is expected to produce better results compared to the current DFROUTER.
In this step, changes to the algorithm will be proposed and implemented. The adjustment is expected to produce better results compared to the current DFROUTER.
Table 11-2: Detector data on Test case
Table 11-2: Detector data on Test case
Table 11-8: Turning percentage OD matrix
Table 11-8: Turning percentage OD matrix
Table 11-9: Cases to consider in the recursion algorithm
Table 11-9: Cases to consider in the recursion algorithm
Table 11-10: Comparison of the destination probabilities of the original and the improved algorithm 3) Application in a larger network
Table 11-10: Comparison of the destination probabilities of the original and the improved algorithm 3) Application in a larger network
Calculated results and their comparisons are shown below regarding both probabilities at destinations (all “ends”) and the original input as well. The differences are evident anc significant as the original DFROUTER does not consider missing data at destinations. The probabilities generated by the improved DFROUTER are approximate to the destinatior probabilities and also more accurate compared to that of the original DFROUTER.
Calculated results and their comparisons are shown below regarding both probabilities at destinations (all “ends”) and the original input as well. The differences are evident anc significant as the original DFROUTER does not consider missing data at destinations. The probabilities generated by the improved DFROUTER are approximate to the destinatior probabilities and also more accurate compared to that of the original DFROUTER.
For this complicated scenario, it takes around 5 minutes for the tool to run and perform recursion (on a laptop with an 2GHz CPU and 4.00GB of RAM). The flow probabilities produced by the improved DFROUTER are different from those computed by the original DFROUTER as shown in the Table 77-77. More reliable and accurate results from the improved DFROUTER are achieved as expected.
For this complicated scenario, it takes around 5 minutes for the tool to run and perform recursion (on a laptop with an 2GHz CPU and 4.00GB of RAM). The flow probabilities produced by the improved DFROUTER are different from those computed by the original DFROUTER as shown in the Table 77-77. More reliable and accurate results from the improved DFROUTER are achieved as expected.
Table 11-11: Comparison of DFROUTER and improved DFROUTER results with input probabilities
Table 11-11: Comparison of DFROUTER and improved DFROUTER results with input probabilities
Re-engineering is part of the software's lifecycle maintenance phase.Re-engineering improve the software to adapt it to the increasingly changing environment and to satisfy nev requirements. Thus, software maintenance is one of the most important phases of th software lifecycle. It has been estimated that represents around 70% of the total softwar lifecycle cost[7]. In the case of the TraCl-Python API, the new requirement consists o! adaptina it to Matlab while trving to maintain the same syntax. As stated by Chikofsky and Cross[5], frequently, software maintainers are not its developers. herefore, the subject software should be initially understood through reverse engineering rocess to modify it properly. Furthermore, Demeyer et. al. [8] argued that a specific reason to se re-engineering was to “extract the design as a first step to a new implementation". They so defined a catalog of re-engineering patterns, grouped in clusters according to the re- ngineering cycle. These design patterns are understood as best practices to address common roblems found in a re-engineering process. Some of these patterns will be related to the ctivities carried out in the re-engineering process of TraCl-Python. YO OACTO HH
Re-engineering is part of the software's lifecycle maintenance phase.Re-engineering improve the software to adapt it to the increasingly changing environment and to satisfy nev requirements. Thus, software maintenance is one of the most important phases of th software lifecycle. It has been estimated that represents around 70% of the total softwar lifecycle cost[7]. In the case of the TraCl-Python API, the new requirement consists o! adaptina it to Matlab while trving to maintain the same syntax. As stated by Chikofsky and Cross[5], frequently, software maintainers are not its developers. herefore, the subject software should be initially understood through reverse engineering rocess to modify it properly. Furthermore, Demeyer et. al. [8] argued that a specific reason to se re-engineering was to “extract the design as a first step to a new implementation". They so defined a catalog of re-engineering patterns, grouped in clusters according to the re- ngineering cycle. These design patterns are understood as best practices to address common roblems found in a re-engineering process. Some of these patterns will be related to the ctivities carried out in the re-engineering process of TraCl-Python. YO OACTO HH
Figure 12-4: UML sequence diagram for the get process in the TraCl-Python API
Figure 12-4: UML sequence diagram for the get process in the TraCl-Python API
the sumo_object module, which in turn calls the proper TraCl function to build the outgoing message, read the response from the SUMO server and check it for errors. Figure 12-5 shows the class diagram corresponding to the abstract class sumo_object. It is worth to notice, that this abstract class was not physically implemented, but serves as a way to explain the packages corresponding to the SUMO objects and their attributes and methods in common. Additionally, the simulation module is the only one that does not contain the getIDList method. Figure 12-5: Abstract package sumo_object which represents the packages corresponding to the SUMO objects.
the sumo_object module, which in turn calls the proper TraCl function to build the outgoing message, read the response from the SUMO server and check it for errors. Figure 12-5 shows the class diagram corresponding to the abstract class sumo_object. It is worth to notice, that this abstract class was not physically implemented, but serves as a way to explain the packages corresponding to the SUMO objects and their attributes and methods in common. Additionally, the simulation module is the only one that does not contain the getIDList method. Figure 12-5: Abstract package sumo_object which represents the packages corresponding to the SUMO objects.
Figure 12-6: The TraCl4Matlab API components: (a) Deployment, (b) Dependency relationships. Figure 12-7 shows the global variables used in the TraCl4Matlab implementation. Note that there are 14 global instances of the class SubscriptionResults, namely edgeSubscriptionResults, guiSubscriptionResults and so on (including the areal detector introduced in the version 7 of TraCl). If no subscription was made to a particular sumo object, Matlab sets the corresponding global variable to a null object by default. Recall that the rest of the attributes associated to namespaces are defined in the methods that use them, e.g. the RESULTS and modules atributes of the TraCl package.
Figure 12-6: The TraCl4Matlab API components: (a) Deployment, (b) Dependency relationships. Figure 12-7 shows the global variables used in the TraCl4Matlab implementation. Note that there are 14 global instances of the class SubscriptionResults, namely edgeSubscriptionResults, guiSubscriptionResults and so on (including the areal detector introduced in the version 7 of TraCl). If no subscription was made to a particular sumo object, Matlab sets the corresponding global variable to a null object by default. Recall that the rest of the attributes associated to namespaces are defined in the methods that use them, e.g. the RESULTS and modules atributes of the TraCl package.
Figure 12-8: The single intersection scenario used in the MOYCOT project to obtain parameters needed for MPC traffic lights controller.
Figure 12-8: The single intersection scenario used in the MOYCOT project to obtain parameters needed for MPC traffic lights controller.
In this paper, the re-engineering process of the TraCl-Python API used to develop a Matlab implementation was presented. Static and dynamic models related to the architectural and component design were obtained. The authors consider that those models can be used to implement TraCl in any object-oriented programming language.
In this paper, the re-engineering process of the TraCl-Python API used to develop a Matlab implementation was presented. Static and dynamic models related to the architectural and component design were obtained. The authors consider that those models can be used to implement TraCl in any object-oriented programming language.
Figure 13-1 contains the system architecture of ITS Austria West.
Figure 13-1 contains the system architecture of ITS Austria West.
Figure 13-2: The whole road network The extracted road segments are used to generate two files, containing “nodes” and “edges”, in SUMO-specific XML format. These two files are given as input to the program NETCONVERT, the component of SUMO which generates a road network file. The network can be generated in either SUMO or MATSim format. Figure 13-3: Part of an urban area (Linz).
Figure 13-2: The whole road network The extracted road segments are used to generate two files, containing “nodes” and “edges”, in SUMO-specific XML format. These two files are given as input to the program NETCONVERT, the component of SUMO which generates a road network file. The network can be generated in either SUMO or MATSim format. Figure 13-3: Part of an urban area (Linz).
Figure 13-4: Locations of vehicle counters (Upper Austria) 13.6.2 Floating car data In the online system, the latest measurements from VDLs are aggregated and used to compute average traffic velocities on their corresponding road segments. These measurements also provide the number of passed vehicles, information which is used for the online calibration of the simulation: If the observed traffic is heavier (or lighter) than the simulated traffic, new vehicles are inserted into the simulation, with randomly chosen routes (or are removed from the simulation).
Figure 13-4: Locations of vehicle counters (Upper Austria) 13.6.2 Floating car data In the online system, the latest measurements from VDLs are aggregated and used to compute average traffic velocities on their corresponding road segments. These measurements also provide the number of passed vehicles, information which is used for the online calibration of the simulation: If the observed traffic is heavier (or lighter) than the simulated traffic, new vehicles are inserted into the simulation, with randomly chosen routes (or are removed from the simulation).
Figure 133-5 The two main loops in which TOMS collects traffic information.
Figure 133-5 The two main loops in which TOMS collects traffic information.
Figure 14-1: The train driver’s cab simulation laboratory RailSET®.
Figure 14-1: The train driver’s cab simulation laboratory RailSET®.
Figure 14-2: The tool chain for using spatial data of the railway track network as stored in the OSM data base fo! various railway applications. RailIML® is a data exchange format based on the Extensible Markup Language (XML) focussing on railway applications (cp. [7]). At the same time, railML.org is an open source initiative working constantly at the development of this data exchange format for railway applications, which currently exists in version 2.2. The XML schema files and corresponding documentation can be downloaded for free from the organisation’s website [16]. From the three existing railML® sub-schemas, infrastructure, timetable and rollingstock (cf. [17]), only the first one is used for the geo data export from the RailDriVE® data base.
Figure 14-2: The tool chain for using spatial data of the railway track network as stored in the OSM data base fo! various railway applications. RailIML® is a data exchange format based on the Extensible Markup Language (XML) focussing on railway applications (cp. [7]). At the same time, railML.org is an open source initiative working constantly at the development of this data exchange format for railway applications, which currently exists in version 2.2. The XML schema files and corresponding documentation can be downloaded for free from the organisation’s website [16]. From the three existing railML® sub-schemas, infrastructure, timetable and rollingstock (cf. [17]), only the first one is used for the geo data export from the RailDriVE® data base.
Figure 14-4: Structure of the tool chain for simulation-based landscape generation in the RailSET®
Figure 14-4: Structure of the tool chain for simulation-based landscape generation in the RailSET®
Figure 14-5: Generating railway track network from OSM: The first picture shows the rendered OSM geo data for the railway line between Braunschweig and Gifhorn (left). The geo data for this area are then extracted from the OSM data base and visualized in JOSM (middle). After processing the OSM-4-Railways tool chain, the corrected and enhanced railway line infrastructure remains (right) [14].
Figure 14-5: Generating railway track network from OSM: The first picture shows the rendered OSM geo data for the railway line between Braunschweig and Gifhorn (left). The geo data for this area are then extracted from the OSM data base and visualized in JOSM (middle). After processing the OSM-4-Railways tool chain, the corrected and enhanced railway line infrastructure remains (right) [14].
Figure 15-1 Satellite View of Complex Intersection oday, there exists no concept in OpenStreetMap, which can be used to represent detailec affic light information. There are proposed features that try to model more advanced signal: formation at intersections’ with focus on optimized information for navigation systems, bu’ yese cannot be used to include signal information nor are they optimized for simulatior urnoses.
Figure 15-1 Satellite View of Complex Intersection oday, there exists no concept in OpenStreetMap, which can be used to represent detailec affic light information. There are proposed features that try to model more advanced signal: formation at intersections’ with focus on optimized information for navigation systems, bu’ yese cannot be used to include signal information nor are they optimized for simulatior urnoses.
Table 15-1 Comparison of different Traffic Light Tagging Methods The area traffic light tagging models the whole intersection as one OSM-area, where each lane connects to the intersection.
Table 15-1 Comparison of different Traffic Light Tagging Methods The area traffic light tagging models the whole intersection as one OSM-area, where each lane connects to the intersection.
Figure 15-3 Classic, Lane, Star and Area Traffic Light Tagging To find a suitable solution, we analyzed different traffic light (TL) tagging ideas.
Figure 15-3 Classic, Lane, Star and Area Traffic Light Tagging To find a suitable solution, we analyzed different traffic light (TL) tagging ideas.
Table 15-2 Requirements Matrix for Different Tagging Alternatives
Table 15-2 Requirements Matrix for Different Tagging Alternatives
One can see that the alternative tagging methods don’t do better than the classic tagginc method at least with regard to the defined requirements. Therefore we came to thi conclusion to introduce an extension of the current relation-model by adding a "traffi signal" relation, which enables lane precise traffic signal modeling (right, left, straight o combinations of all directions). This offers a high flexibility but also keeps the classic taggin¢ system. Table 15- shows the necessary extensions. By using the common concept of referencinc already existing attributes (lanes) and extending them with new options (from, via, to) existinc information can easily be reused. Phase and timing information is described in a similar way to SUMOs way of representing traffic signal information (| - separated values for phases anc timings).
One can see that the alternative tagging methods don’t do better than the classic tagginc method at least with regard to the defined requirements. Therefore we came to thi conclusion to introduce an extension of the current relation-model by adding a "traffi signal" relation, which enables lane precise traffic signal modeling (right, left, straight o combinations of all directions). This offers a high flexibility but also keeps the classic taggin¢ system. Table 15- shows the necessary extensions. By using the common concept of referencinc already existing attributes (lanes) and extending them with new options (from, via, to) existinc information can easily be reused. Phase and timing information is described in a similar way to SUMOs way of representing traffic signal information (| - separated values for phases anc timings).
Table 15-3 Fields of the new traffic_signal relation 15.4 Conversion of OSM Files In this paper, we show the conversion process from the raw OSM file to the SUMO traffic network. Some OSM features can be translated direct to the corresponding parts in the SUMO files (see Figure 15-) , while in other parts a more complex transition is needed (e.g. intersection lane modeling)
Table 15-3 Fields of the new traffic_signal relation 15.4 Conversion of OSM Files In this paper, we show the conversion process from the raw OSM file to the SUMO traffic network. Some OSM features can be translated direct to the corresponding parts in the SUMO files (see Figure 15-) , while in other parts a more complex transition is needed (e.g. intersection lane modeling)
VSimRTI is developed by Fraunhofer FOKUS is a framework for simulation of Vehicle-2-x scenarios by coupling different simulators (e.g., traffic simulator, network simulator, application simulator...). The framework is based on the High Level Architecture (6) which offers mechanisms to connect and synchronize different simulators using a common runtime infrastructure. Figure 15-6 SUMO Traffic Simulation with junction connections shown
VSimRTI is developed by Fraunhofer FOKUS is a framework for simulation of Vehicle-2-x scenarios by coupling different simulators (e.g., traffic simulator, network simulator, application simulator...). The framework is based on the High Level Architecture (6) which offers mechanisms to connect and synchronize different simulators using a common runtime infrastructure. Figure 15-6 SUMO Traffic Simulation with junction connections shown
Both of the driving simulators have a local representation of the whole MAS and are capable of controlling any driving agent. The simulators are also able to connect to an Android device and pass along all the information deemed necessary, such as the GPS coordinates of the current driving agent being controlled. The Android device is running a service that receives the incoming connections from the simulator and also the ADAS being tested. The dotted area in Figure 16-1 corresponds to the developed components as of the writing of this paper. Figure 16-1: Overview of the system’s architecture
Both of the driving simulators have a local representation of the whole MAS and are capable of controlling any driving agent. The simulators are also able to connect to an Android device and pass along all the information deemed necessary, such as the GPS coordinates of the current driving agent being controlled. The Android device is running a service that receives the incoming connections from the simulator and also the ADAS being tested. The dotted area in Figure 16-1 corresponds to the developed components as of the writing of this paper. Figure 16-1: Overview of the system’s architecture
Figure 16-2: Standalone mobile application (left) and mobile application with included library (right) The new GPS coordinates are sent from the simulator every second; however, this value is a parameter of the simulator and so can be adjusted to the specific needs of each scenario. The developed service can be run as a standalone application, and thus testing the ADAS mobile applications independently, as shown in the left side of Figure 16-2. There is also the option to use the service as a library in any Android application, as long as it matches API level 19, as shown in the right side of Figure 16-2. 16.4.3 Interaction of Driving Simulators and Android
Figure 16-2: Standalone mobile application (left) and mobile application with included library (right) The new GPS coordinates are sent from the simulator every second; however, this value is a parameter of the simulator and so can be adjusted to the specific needs of each scenario. The developed service can be run as a standalone application, and thus testing the ADAS mobile applications independently, as shown in the left side of Figure 16-2. There is also the option to use the service as a library in any Android application, as long as it matches API level 19, as shown in the right side of Figure 16-2. 16.4.3 Interaction of Driving Simulators and Android
Figure 16-4: Generated 3D Scene ortographic view The preliminary verification to assess the proof of concept and also the efficiency of th developed architecture focused on the modules in the dotted area of Figure 16-1, th remainder of the system will be developed later on, as mentioned in the next chapter. W have divided the verification into two independent tests. Both of the tests were performed i the same geographical location, which was Porto's downtown, on Avenida dos Aliados, 4 seen in Figure 16-4.
Figure 16-4: Generated 3D Scene ortographic view The preliminary verification to assess the proof of concept and also the efficiency of th developed architecture focused on the modules in the dotted area of Figure 16-1, th remainder of the system will be developed later on, as mentioned in the next chapter. W have divided the verification into two independent tests. Both of the tests were performed i the same geographical location, which was Porto's downtown, on Avenida dos Aliados, 4 seen in Figure 16-4.
Figure 166-3: Typical interaction between IC-DEEP simulator and an ADAS
Figure 166-3: Typical interaction between IC-DEEP simulator and an ADAS
To test the simulator accuracy we have collected multiple GPS trace logs while driving a real car in the selected geographical location. We have then overlayered a visual representation of the obtained traces on the simulator and on Google Earth both, the results can be seen in Figure 166-5. The results show that the generated 3D scene is highly representative of the real world location. In one of the trace logs we have noticed an error and highlighted it in Figure 166-5, this error happens due to the data being collected as raw, untreated GPS, where the road matching algorithm [18] has not been applied. This is also an interesting result, as the error can been seen in both the simulator and Google Earth alike.
To test the simulator accuracy we have collected multiple GPS trace logs while driving a real car in the selected geographical location. We have then overlayered a visual representation of the obtained traces on the simulator and on Google Earth both, the results can be seen in Figure 166-5. The results show that the generated 3D scene is highly representative of the real world location. In one of the trace logs we have noticed an error and highlighted it in Figure 166-5, this error happens due to the data being collected as raw, untreated GPS, where the road matching algorithm [18] has not been applied. This is also an interesting result, as the error can been seen in both the simulator and Google Earth alike.
Figure 16-6: Satellite image of Av. dos Aliados
Figure 16-6: Satellite image of Av. dos Aliados
Figure 17-1: Exemplification of the map matching algorithm. (a) Road network in blue and bikeways in green (on the left part bidirectional, on the right part split to two unidirectional) . The GPS points are the yellow dots, representing a bicycle movement from left to right. (b) Same street network, but with 30m wide buffers around edge in blue — buffers are partially overlapping (darker blue). The yellow line with circles represents again the recorded GPS points, whereas the bold yellow line indicates the identified road and bikeway edges. Note that the matched route crosses the road in the middle as to use the bikeway in the correct direction.
Figure 17-1: Exemplification of the map matching algorithm. (a) Road network in blue and bikeways in green (on the left part bidirectional, on the right part split to two unidirectional) . The GPS points are the yellow dots, representing a bicycle movement from left to right. (b) Same street network, but with 30m wide buffers around edge in blue — buffers are partially overlapping (darker blue). The yellow line with circles represents again the recorded GPS points, whereas the bold yellow line indicates the identified road and bikeway edges. Note that the matched route crosses the road in the middle as to use the bikeway in the correct direction.
Figure 17-2: (a) Road network (blue) and bikeway network (green) of central Bologna. (b) All GPS points (each is a black dot) of Endomondo mapped on the above road network. Note that the GPS points concentrate on the roads and appear as plain black.
Figure 17-2: (a) Road network (blue) and bikeway network (green) of central Bologna. (b) All GPS points (each is a black dot) of Endomondo mapped on the above road network. Note that the GPS points concentrate on the roads and appear as plain black.
The free-flow speed V, has been determined by taking the maximum encountered speed in each GPS trace, assuming that the trace has been recorded by the same person. Surely this is not always the maximum speed of a cyclist, but the best possible indicator retrievable from the available GPS traces.
The free-flow speed V, has been determined by taking the maximum encountered speed in each GPS trace, assuming that the trace has been recorded by the same person. Surely this is not always the maximum speed of a cyclist, but the best possible indicator retrievable from the available GPS traces.
18 Authors Index
18 Authors Index
Related topics:
Computer Science
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved