Back to Search Start Over

TransAID Deliverable 4.3 (second iteration): Translation of traffic management measures to iCS, scale-up, and wider deployment

Authors :
Maerivoet, Sven
Carlier, Kristof
Pápics, Péter
Alms, Robert
Flötteröd, Yun-Pang
Lücken, Leonhard
Mintsis, Evangelos
Karagounis, Vasilios
Koutras, Dimitrios
Wijbenga, Anton
Vreeswijk, Jaap
Correa, Alejandro
Zhang, Xiaoyun
Blokpoel, Robbin
Schindler, Julian
Publication Year :
2020

Abstract

This deliverable explains how simulations of both the baseline (WP3) and the traffic management schemes (WP4) can be ported from the SUMO simulation environment (with the help of the TraCI interface and Python scripts) to the iCS environment (using the C++ language).We first gave an explanation on how to set up the creation of a traffic management application in the context of the iCS. Details were given on how to prepare the development of an application, based on the source code in the repository. We also explained the interactions between the iCS, SUMO, ns-3, and the various applications, using subscriptions and the exchange of messages.To this end, the TransAID version of the iTETRIS platform defined in WP6 includes a basic application known as baseAppthat manages the exchange of information between the applications and the iCS modules. The application developed for the different services of the TransAID project will inherit form this baseAppand extend the functionality with the traffic management procedures defined in WP4. In order to develop these applications,a new branch (transaid-apps) is added to the git repository. Note that all TransAID applications developed share the same baseApp. Hence, commits to the baseApp should be strictly separated from thecommits to the TransAID applications in development. Changes to the baseApp as well as other iTETRIS modules like iCS or ns-3 should be integrated into the transaid-dev branch. When porting the traffic management code from the WP4 to the WP6 environments, we need to make sure that the same logic is preserved. In order to guarantee this, all applications implemented in the use cases should create test suites, similarly as described in Deliverable D6.1. We use the same testing framework, called TextTest. Tests are created in the transaid-apps branch of the repository, separated for each use case individually. All tests are stored in the transaid/TransAIDScenarios/tests/scenariosfolder. All relevant data pertaining to a specific use case (i.e. SUMO networks, configuration files, ...) are copied to the relevant scenario in the tests folder. Just as before, the testing concept employed by TextTest is to compare expected output of an entire program run with actual output (output files or stdout and stderr). However, here we need to be a bit more careful and considerate of the complexity involved with comparing the various iCS traffic management applications to their previously created SUMO counterparts.We explain this via a method of aggregate quantities, rather than explicitly comparing time-space diagrams.A more detailed comparison of simulation outputs would be to use detector measurements and/or explicit vehicle trajectories, create time-space diagrams from these (of average speeds or flows), and then compare these with each other and define whether or not the deviation is significant. However, even though this type of analysis would certainly allow us to detect deviations in the time-space plane (e.g.,congested areas that may appear/disappear as artefacts, ...), it would be out of scope. In addition, such analyses have not been done widespread before, as they are also difficult to interpret, and still require some aggregation in order to test these 'automatically'.

Details

Language :
English
Database :
OpenAIRE
Accession number :
edsair.od......1640..0d18920bf62bbd9befdc2256f556bad0