That is not 100% correct. In addition to RBC files, a Retime User needs to have relevant Vissim files for given signalized network whose signals are to be optimized. These files are *.inpx, *.layx, and all other relevant files that may be needed optionally (but only *.inpx, *.layx, and *.rbc files are ‘hard’ requirements).

However, although Vissim’s files are needed to run the optimization, a Retime User does not have to have its own Vissim license to run Retime optimizations. Such license would be needed to open and edit Vissim files before the optimization starts but not for the optimization itself.

Let us first clarify meaning of ‘what is optimized’. Sometimes we refer to process of optimization as in “objective function is optimized” (e.g. delays, stops, or travel times are minimized or throughput, average speed, etc. is maximized). Other times we may say “cycle times, offsets and splits are optimized” meaning that those parameters are adjusted during the optimization process to minimize or maximize one of the objective functions given above. Let us adopt here, for the sake of clarity, a rule that phrases “minimization” and “maximization” should be used to describe what we try to achieve with an objective function, whereas a phrase “adjustment” is used to describe the process of modifying certain (signal) parameters, during the optimization process.

Then, based on this clarification, we can say that any multimodal performance measure that comes out of Vissim could be used as an objective function in Retime. For example, Retime could minimize pedestrian delay, travel time of transit vehicles, stopped delay of bicyclists, and similar. It is also possible to minimize person delay of all of the people in the system, with equal or biased weights given to users of specific travel modes. As long as the Vissim (on cloud) can output a certain performance measure, the Retime can use such a performance measure (or combination of multiple measures) as an objective function in its optimization process. Of course, to see the benefits of such multimodal optimizations a Retime User would need to properly model multimodal operations in Vissim model and enable relevant evaluations.

Now, when it comes to which (signal) parameters could be adjusted during the optimization process – we are able to modify (right now) only “classical” signal timing parameters: cycle times, offsets, splits, and phase sequences. However, this list can be extended in near future, quite quickly, based on Retime Users’ needs. In the past we have adjusted Transit Signal Priority parameters such as Green Extension and Red Truncation intervals and similar.

The short answer is no, there would not be any issues. We use a type of cloud VMs which are strong enough to run Vissim optimizations quickly and yet affordable enough to minimize the costs of doing optimization for the Retime Users. Sometimes in future we may offer different price brackets for using VMs with various performances (e.g. a stronger and faster VM would cost more but will finish the simulations faster), but right now we offer always the same and stable cloud performance.

We achieve this stability by offering each Retime User a full use of dedicated computers. E.g. once a Retime User commits to use Retime optimization services we dedicate VMs (full time) for exclusive use and we do not let users share their resources with the others. This may not be the most efficient use of cloud computing resources, but it is the highest quality of service for Retime Users, and that is our goal.

Right now, Retime optimizations are based on evolutionary computations known as Genetic Algorithm (GA), without going into details on the exact type of the GA. Such algorithms require several solutions (all solutions together create a population, which is defined by a number of solutions) which are then improved, by doing their recombination in each generation. From signal timing perspective – one solution represents a group of signal timing plans, one for each of the signals/intersections in the optimized network. A population of, let us say, 20 solutions means that we have 20 groups of signal timing plans, where each group represents timing plans for all of the intersections.

While this question is a bit ambiguous the best answer is - when we start a new optimization, the original signal timings (this could be called “previous data”) are used as a seed to generate many new solutions, which are then combined through following generations to find the optimal signal timing plans.

Once the optimization is done, all of the solutions are recorded in the database (usually thousands of them) which a Retime User can analyze, visualize in various charts and tables, and select to deploy in field.

The total delay, as shown in some of the screenshots during the webinar, is the total delay for the entire network and it combines delay of all intersections, or more granularly, all individual movements of all individual intersections.

If needed, an objective function (used in the optimization) can be specified to minimize delays only of specific movements at some/all of the intersections – e.g. minimize delay only for through coordinated movements at all intersections. However, before using such an approach a Retime User should be sure that deploying such a strategy is in their best interest.

The Retime optimization is not intended to be used as a real-time/adaptive tool that will change signal timings based on how traffic conditions change. So, from that perspective it cannot help to introduce phase reservicing dynamically. However, if phase reservicing logic is embedded in Vissim RBC controllers Retime can be enabled to adjust whatever parameters are defined within the RBC controller.

On the other hand, modification of phasing sequence is a normal feature of Retime optimization; regardless of what happens with phase reservicing.

While Retime is not available for broad use in commercial applications yet, the tool could be made available for potential users very soon. If you have any ideas for pilot projects, where we could help you use Retime with a certain amount of supervision, training and guidance, let us know (preferably ahead of time) by sending us an email at support@retime.online and we will do our best to provide required support.

Thank you for your question but we are not PTV Vissim vendor or developer – please contact PTV Group for any such trainings. I believe that they have a good training program with several courses for beginners.

Yes, the Retime optimizations do not have any restrictions on how many signals can be optimized. Obviously, networks with more signals will require longer time for simulation runs and handling of controller files but there are not any limits on number of signals that can be optimized. If they are linked (in the same Vissim file) at the beginning of optimization, they will be linked once the final solution is achieved, as well.

This is a great question. For now, we do not provide results on the number of conflicts or any similar surrogate measures of safety. This would require a post-processing analysis that would increase computation time, which is meaningful only if a specific Retime User has a need for such outputs. However, we have done similar research before and this could be done again in future. If you are interested in this feature for a specific case study, please contact us at support@retime.online and let us discuss the details.

Right now, all of the modifications of the RBC controller parameters occur automatically during the optimization process. If Retime Users want to change signal parameters manually in RBC files, they would need to download such a RBC file, open it in Vissim (for which they need to have their personal license; licenses used in Retime optimizations cannot be used for that purpose) and modify any parameters manually. However, Retime LLC team is working on enabling modifications of RBC files directly through our Retime platform/website. This option will be added soon. Please contact us at support@retime.online if this is a priority for any upcoming case study for which you would like to use Retime.

Yes, total delay is given for the entire network, or all intersections combined. We do have ability to show individual intersection delays. Those data are in our database but not integrated yet in the interface of the website; this will be done soon. The total delay is a measure that is often used as an objective function (e.g., minimize total delay) for the entire system. Individual intersection delays are important to observe operations at each intersection, but they should not be, without extreme caution, used to optimize the entire network.

In this specific example we had 10 generations, each populated with 20 solutions (thus a population size is 20), which gives 200 simulations. The extra 20 simulations are done during the initialization process, before GA iterations, to evaluate the quality of original population of signal timing plans.

Throughput is indeed a metric used for calibration of the Vissim and other models. During the optimization process, every performance metric changes, based on how particular signal solution performs. The throughput is not an exception.

However, those changes of throughput are usually not significant. And if a Retime User is afraid that the final solution may be ‘deceptive’ in the sense that it will report good delay, but it may worsen the throughput – there are two ways to deal with that problem:

• 1. we can enable constrained optimization so that throughput values never fall below certain threshold (acceptable for the User) or

• 2. (if the final solution produces unacceptable throughput, which is not likely to happen) a Retime User can pick and choose a preferred solution just by observing a Pareto Front chart which shows performances of delay versus throughput, for all of the solutions.

This particular model was developed almost a decade ago for an agency in Florida and the preparation process included a very thorough calibration and validation including turning movement counts, multiple probe-vehicle travel time runs, and similar. While the calibration and validation effort are not our focus in the demonstration of Retime, we can share report that documents the calibration and validation of this Vissim model. If you would like to get such a report, please contact us at support@retime.online.

Thank you!

Retime has not been applied anywhere yet but we are working on establishing some pilot studies.

Retime optimizations work regardless of how traffic demands are defined within Vissim files. We usually define traffic demand through traffic inputs at the entrances of the network and routing decisions which define % of turning movement proportions at each intersection. These elements could be defined to be constant during the analysis period (even then some small variations of up to 2% can happen) or they can be dynamically varied by slicing analysis period into shorter intervals with various traffic demand levels. Demand in Vissim files could also be defined through OD counts and similar. None of this stuff impacts Retime optimization – it will always work with whatever Vissim file is given. However, to clarify again – Retime won’t change signals dynamically to accommodate varying traffic demand, it will just find one set of signal timing plans which will be the best for given (varying or constant) traffic conditions.

It is also possible to run simulations with multiple timing plans (for each signal) during the analysis period (e.g., by defining various TOD patterns in RBC files and specifying times when a signal should switch between patterns), but such option is currently not supported in Retime. Enabling optimizations of multiple TOD patterns within the same RBC file is an option which will be possible in future.

The Retime process does not evaluate, right now, scenarios with multiple traffic volumes/demands. This is something that could be done in future, but it is an activity that could significantly slow down the optimization process and convergence towards the final solution. This should be done only if a Retime User is aware of the advantages and disadvantages of doing such optimizations.

Yes, this could be done in two ways: we can restrict Retime optimizations to consider only cycle times in 5-second increments, or a Retime User may decide to increase or decrease the final cycle length to a value divisible by 5. If the first option is preferred, we can add that constraint in the optimization process.

Thank you. Retime optimizations have not been applied officially in any of the existing projects so far. We made only moderate efforts to advertise this product and so far, this has been done almost exclusively through few webinars and conferences (e.g. PTV User Group meetings, TRB conference). We are very interested to work with you on a potential pilot project. If you have anything in mind do not hesitate to contact us at support@retime.online

Yes, that was a simulation period of 900 seconds. We do not have any specific reason to recommend 900 seconds beyond the need to have shorter simulations for the sake of our demonstration during the webinar. 900 seconds is 15 minutes and considering that 15-minute analysis is good for many analytical tools, we dare to say that it may also be long enough to find good signal timing plans for networks experiencing undersaturated traffic conditions. For more congested networks we recommend running optimizations with simulations that last for an entire hour. However, obviously a longer simulation period will mean a longer overall optimization time.

We are not sure that we understand this question but actually all of the signals that are operated during the showcased optimization are actuated signals. Most of them are coordinated too but all of them work with principles of actuated signal timings. If the question were about if the Retime could be used to optimize fully-actuated signals at isolated intersections (when cycle length and offsets are not important factors), the answer is yes. The Retime optimization works with all types of basic control operations: fixed-time (no detection) and actuated (fully or semi), both for coordinated and non-coordinated intersections.

Performance Index (PI) is defined as a linear combination of delays and stops where each stop is given a delay penalty of 10 seconds. We use total delay and total stops from the entire network to derive such a PI. This type of PI is very common in other tools (e.g. Synchro, Vistro, Transyt-7F). Sometimes, we integrate latent delay in total delay, too – this can be done to ensure that the optimization does not produce a solution which creates troubles for the surrounding signals, which are not part of the analyzed network.

We do not process simulation demand (traffic inputs) in Retime at all. Whatever a Retime User defines as relevant input traffic demand, the Retime optimization process will use to find the optimal solution for such conditions.

The candidate signal timing plans are generated during the optimization run time, but they are not modified internally while Vissim simulations run. So, “Yes” for Retime optimization’s run time, but “No” for Vissim’s run time.

Does a Retime User need to pre-specify all of the candidate timing plans? No, only one set of timing plans (one plan for each intersection) is needed and those could be any plans (e.g. from field controllers, optimized by another tool and similar). Obviously, starting from a better set of timing plans will guarantee that the final solution is even better than the original solution. However, even if a Retime User starts the optimization with signal timings that produce poor performance, the optimization process should be able to find good timing plans, providing that enough iterations are done (e.g. a couple hundred).

The original RBC files are uploaded during the initialization process to use them as seeds to create other solutions which are used for GA recombination steps, during each generation. Each time a new signal timing solution is created, an RBC file is modified and sent (with the others from the same batch) to be evaluated in a Vissim run.

The burden of developing reliable OD demand is all on the Vissim user side. The Retime optimization works with whatever demand levels are supplied in Vissim files. For further explanations, please see answers to the questions 16 and 22, above.

Vissim licensing is provided through Retime optimization service, through an agreement between Retime LLC and PTV Group. A Retime User does not have to pay for any extra licensing – it is a single fee that takes care of the optimization process and the licensing for all virtual machines used to run Vissim simulations during the optimization process. There is no limit on how many machines and licenses can be used in the optimization, but the fees are based on price brackets, which are based on number of signals. This should not be a significant concern as most of the signalized networks in Vissim have 50 signals or less. For larger networks, a different price bracket may apply.

This is a tricky question as it all depends on what a user expects to get. Synchro, as any other analytical software is a great user-friendly tool for quick turnaround of the optimization results. The inputs are quick and minimal and thus the outputs are also not comprehensive as they cannot include variety of conditions, considering the limitations of the analytical models. This is not about Synchro – it is the case for any signal optimization tool based on analytical traffic models.

We did compare, in the past, results of such GA-based stochastic optimizations with Synchro results. The findings show that while the GA-based stochastic results always performed better than Synchro in Vissim, Synchro’s results were usually better in Synchro. In other words, every tool is the strongest on its ‘home ground’. However, one can now raise a question – “To which tool do I trust more to replicate my field conditions – Vissim or Synchro? And this is where such stochastic optimization tools bring much higher value – they use high-fidelity microsimulation models (such as Vissim), which can mimic the field conditions much better than the analytical tools; providing that the models are properly prepared, calibrated, and validated. If you would like to get copies of papers which compare Synchro and similar GA-based stochastic optimizations, please contact us at support@retime.online.