9148-15-7311 Final Addendum 1 - Toronto · Q2. Section 3.1 – “Group B Vendor to apply the...

Michael Pacholok Director

Purchasing and Materials Management Division City Hall, 18th Floor, West Tower 100 Queen Street West Toronto, Ontario M5H 2N2

Allison Phillips Manager Professional Services

January 21, 2016 Posted in PDF (14 pages)

ADDENDUM NO. 1

REQUEST FOR PROPOSAL NO. 9148-15-7311 CLOSING: 12:00 NOON (LOCAL TIME), January 28, 2016

For: Consultant Services for Traffic Signal Coordination on:

Group A 1. Lake Shore Blvd W (from Palace Pier Ct to 41st St) 2. Dundas St W (from Royalavon Cr to Keele St) 3. Ellesmere Rd (from Victoria Park Ave to Kingston Rd) 4. Albion Rd (from Codlin Cres to Weston Rd/Walsh Ave) 5. Royal York Rd (from Dixon Rd to Lake Shore Blvd) 6. Martin Grove Rd (from Steeles Ave E to Rathburn Rd) 7. Morningside Ave (from McNicoll Ave/Oasis Blvd to Coronation Dr) Group B 1. Danforth Rd/McCowan Rd (from Danforth Ave to Lawrence Ave E) 2. Keele St (from Rogers Rd to Steeles Ave W) 3. Wilson Ave (from Wendell Ave to Bathurst St) 4. York Mills Rd (from Upper Highland Cres to Victoria Park Ave) 5. Dufferin St (from Wilson Ave to Saskatchewan Rd)

Please refer to the above Request for Proposal (RFP) document in your possession and be advised of the following: I. Attachment 1. Attached is the City's draft Aimsun methodology for this Project. II. Answers to Proponent Questions

Q1. Section 3.3.2 - Please clarify whether any materials will need to be prepared by the consultant

regarding the 2-week public engagement period, outside of the analysis of feedback.

A1. The consultant will be required to create a summary table of the complaints that are received through 311, to be used in consultation with the City to determine which issues warrant being investigated during the after observations. All documentation is to be included in the Final Report.

Q2. Section 3.1 – “Group B Vendor to apply the City’s methodology to analyst Dufferin St using Aimsun

microsimulation software…” Please specify what the City’s methodology is, and whether this methodology is available in electronic format.

A2. Attached is the City's draft Aimsun methodology for this Project.

2

Q3. Section 3.5.5 – Please confirm that the City will be collecting the 24 hour volume data for the Off/AM/PM/Night/Weekend After studies. Assuming the City will be collecting this information, how much time following the implementation of the timing changes should be assumed for the City to be able to provide this data to the consultant?

A3. The City will be collecting the 24 hour volume data and typically requires approximately 6 weeks to provide the data to the consultant.

Q4. What is the allocated budget for this project? A4. Including contingency, the budget for the Group A Project is $650,000.00 to $750,000.00, and for

the Group B Project is $550,000.00 to $650,000.00. Please note that this amount is only an approximation and does not reflect the total amount that will be paid to any Vendor. This amount is for information only and should not form the basis of any submission.

Q5. The RFP asked for the use of Synchro 9/SimTraffic 9 and also states in Appendix F2 that the

City's Synchro 7 guidelines are being updated (assuming to Synchro 9). Can the City share when the updated guidelines will be completed?

A5. The City has a draft version of the guidelines that are suitable for the consultant to use for the

analysis, which will be provided to the Vendor at the kick-off meeting. Q6. In section 3.3.2, a 2-week public engagement period is stipulated for both Group A and Group B.

Will the Vendor be responsible for updating any analysis files (Synchro, Excel, Aimsun) to provide specific recommendations to address concerns?

A7. Yes, and the public engagement period should be documented in the final report. Q8. For queueing review required during the various field observations (Weekday, Weeknight,

Weekend and Gardiner Expressway), is the Vendor expected to collect this information on the same day per study period? Or can the queue observations be staggered in a few days apart?

A8. The queue observations can be staggered a few days apart. Q9. Will queue observations not be considered on the corridors impacted for the Highway 427 and

Highway 401 scenarios? A9. Queue observations are to be considered for normal plans, including corridors scheduled for

development of Hwy 427/401 closure plans, but queue observations are not required for the closure scenarios.

Q10. Is Synchro training only required for Group A as stated in the RFP? A10. Yes, as discussed in Section 3.4.1.3. Q11. The RFP provides instructions for volumes adjustments required to develop 401/427 incident

scenario, however, the base timing plan is not specified. For example, the weekend scenario will be based on the OFF peak model and the Gardiner closure scenario is based on the weekend model. It is understood that the cycles, splits and offsets will be overhauled based on adjusted volumes, however, certain turn restrictions or advanced phases may be different depending on the peak period selected. Can the City please clarify whether a specific peak-hour model will be used?

3

A11. The Vendor will be asked to provide feedback over which analysis period, or combination of, should be used. The City anticipates that the AM and/or PM plan(s) will serve as the basis.

Q13. Keele Street is currently reduced to 1-lane each direction for northbound and southbound. This

will impact speed and delay surveys and optimization results. Will this configuration be held constant throughout the course of the study?

A13. Yes. Q14. Can the City please confirm which version of Synchro 9 should be used for this project (Synchro

9.0 or Synchro 9.1?

A14. Version 9.1 should be used.

Q15. Will the signal at Keele/Finch be optimized to construction conditions or its ultimate conditions?

A15. Keele/Finch shall be optimized to its ultimate conditions. Should you have any questions regarding this addendum contact Vathsala Mariyanayagam at [email protected] or at 416-392-7172. Please attach this addendum to your RFP document and be governed accordingly. Proponents must acknowledge receipt of all addenda in their Proposal in the space provided on the Proposal Submission Form as per Appendix A, Section 4 - Addenda of the RFP document. All other aspects of the RFP remain the same. Allison Phillips, Manager Professional Services

RFP No. 9148-15-7311- Addendum 1

1

City of Toronto's Methodology for Aimsun Modeling

1. Introduction An overview of the proposed workflow is shown in Figure 1. The proposed methodology consists of three major steps:

1. Base Model Development 2. Calibration/Validation 3. Scenario Analysis

Each one of these steps is further outlined next in the following sections.

2. Methodology

2.1 Step 1 - Base Model Development The two main elements that are to be considered during model development stages are supply (transportation network) and demand (traffic demand on the network). In addition, a detail error checking and model validation quality control process are to be carried out. All three of these elements are discussed in the following sections.


2

Figure 1: Overall Aimsun Microsimulation Workflow


3

2.1.1 Transportation Network – Supply The model road network should be developed for the applicable corridor primarily using available GIS mapping and digital aerial photographic. This approach has proven to be most accurate and allows the model results to be spatially correct.

After developing the base geographic layout of the network, the key network attributes that are to be confirmed or coded include (but are not limited to) the following:

Link characteristics Number of lanes Lane width Storage lengths Link and turning speeds Transit Stops Speed profile

Node characteristics / Traffic Control Signals Stop signs Yield signs Turning restrictions Pedestrians Detectors

For each intersection equipped with Transit Signal Priority (TSP), request and cancel detectors are to be modeled to support TSP calls. Key elements with respect to model development are transit and signal timing information. These elements are critical as, unlike other data, there is quite a fair amount of work (pre-processing) that is required before the data can be coded into Aimsun. These are discussed next. Transit Information provided by the City and those available on the TTC websites describing the route information (service rates), are to be used to code all transit lines.

For side street locations, a minimum segment length of 250 metres will be coded as the model limit. Where the signals on the corridor/study area are equipped with TSP for serving side street approaches, the following approach should be used:

One (1) transit stop, plus one (1) signal at locations where a side street signal is within 500m of the main corridor;

Two (2) transit stops within 500 m of the main corridor corridor; or A limit of 500m at locations where 1 or 0 transit stops are located within 500m of the

main corridor; Where a traffic signal (including pedestrian signal) is within 500m, the signal should be

partially coded to include relevant TMC's, timing plans, and geometry, but will not be calibrated any further than that

During field investigations, all transit stops are to be reviewed to ensure they are coded correctly (stop must be confirmed if they have either bus-stops or bus-bays, nearside or farside stops). In addition to the field investigation, transit travel time runs should be completed during both AM and PM peak hours along study corridor. A minimum of six travel time runs should be conducted per direction. During the runs, the following data is to be collected:

Transit travel times/ Delays o The results from the transit travel time surveys should be used to compare the

modeled transit travel times during calibration. The travel times are to be outputted


4

from Aimsun using the Subpaths feature which allows the grouping of sequential elements (segments) and output various measure of effectiveness (MOE's). Between each signalized intersection, the model travel times should be compared to the observed travel time. Before comparing the observed transit travel time, a review of the data should be conducted in terms of a comparison between the runs to ensure they are no outliers. The number of transit travel time runs does not have a large enough sample size where standard deviation will be of value. As such, they should be used as collected.

Transit Vehicle Occupancy o The transit vehicle occupancy should be used to estimate the person delay MOE

required for this study. The person delay should be calculated using the average delay of transit vehicles during the simulation peak hour and occupancy.

Boarding/Alighting at Transit Stops o The boarding and alighting information collected during the transit travel time surveys

are to be used to model dwell times at each stop. This information should be used to develop the required dwell time distribution that will be used in the Aimsun model. For stops where transit vehicles do not stop during the study (due to no passengers), a distribution developed from the boarding and alighting information should be collected. This should be submitted to the City for review before proceeding.

Transit Vehicle Dwell times o Using the information from the boarding and alighting (as previously described), the

required dwell time for each stop should be modeled. These will be coded per stop and per AM and PM peak hour.

For analysis of bus routes, the default bus vehicle type in Aimsun can be used to reflect operation of such transit vehicles. The default bus type in Aimsun does not match the standard bus dimension of the TTC buses, but represents a good approximation. Signal Timing Signal timing plans provided by the City should be reviewed in detail and translated into Aimsun. Based on the structure of the timing cards and Aimsun internal process of coding them, special attention should be provided to ensure they are coded correctly. All required Transit Signal Priority parameters must be accurately reflected in Aimsun. The City has previously developed an application programming interface (API) which should be used to model the required the City's 4 current TSP algorithms. However, as part of a quality control plan, detailed testing should be conducted to test the signal timing plans without TSP being active to ensure all phases/splits/detectors are functioning correctly.

2.1.2 Traffic Volumes – Demand The required traffic volumes should be developed from AM and PM peak hour counts (the same counts as the Synchro model being developed for the corridor). Depending on the nature of the microsimulation network, static demand assignment is acceptable, which is predefined routes based on turn percentages and input flows.

The initial step of coding static routes should be the development of balanced turning movement counts through the corridor for all signalized intersections. The balanced counts developed for the Synchro modeling component should be used as a starting point while further balancing should be carried out. For locations where there are differences of counts between signalized


5

intersections, microsimulation Sinks/Sources should be used. The Sinks/Sources are to be used to reflect trips originating or destined to unsignalized accesses between signalized intersections.

For microsimulation modeling, a balanced count should be used where demand entering the network over the modeling period is equal to the demand leaving the network over the same time period. This should be the threshold used in balancing counts for the Aimsun modeling; however, a volume variance of no greater than 5 vehicles is an acceptable difference between simulated volumes and counts, if needed. The final balance counts that will be modeled in Aimsun should be submitted to the City for review before proceeding with calibration stage.

Both peak hours (AM and PM) should be divided into four 15 minute increments (after they are balanced) to reflect the demand profile observed on the corridor. The demand profile for all 15 minute increments should be developed using 15 minute counts provided by the City at available major/major intersections. In addition, a one (1) hour warm up period should be used for both AM and PM peak hour.

For each signalized intersection, pedestrian demand should be added into the model using traffic states (static routing) similar to vehicular traffic. These are to be the same demand used in the Synchro model for each time period (AM and PM).

2.1.3 Error Check – Quality Control As part of the project team’s internal modeling quality control process, a detail check and review should be carried out of all network elements before the calibration stage is initiated. The intent of this step is to identify and implement corrections prior to the calibration analysis. In addition, a series of diagnostic model runs should be carried out to confirm the models are representing similar field conditions. The diagnostic runs are not meant to produce simulation results but rather to identify issues within the network (static demand routes incorrectly coded, demand profile that is too aggressive, prolonged queuing, unrealistic speed profiles, queuing at the entry point in the model, signal timing plans incorrectly coded, transit signal priority errors, etc.). Typical network elements that are to be reviewed include (but not limited to):

Test STP and confirm TSP API operation Confirm Signal Groups Speed profiles Identification of unrealistic blockages Demand profile

RTOR Turn Restrictions Yellow Boxes Left Turn Yield Points Lost Vehicles/Missed Turns

A proposed quality control process to ensure all model elements are accurate should be submitted for approval to the City.


6

2.2 Step 2 - Calibration and Validation A critical component of the model development is the calibration and validation of the corridor where the objective is to ensure the model matches existing conditions prior to testing any scenarios. A summary of the calibration process is shown in Figure 2.

The calibration and validation should start after the City approves the base model development for both AM and PM peak hours. A methodology for establishing reliable data for the calibration and validation of the model should be developed in collaboration with the City. Typically, the City requires recent data collection such as travel time runs to support the calibration dataset.

It is essential that the models (AM and PM peak hour) be calibrated and validated to a high standard to ensure that the models are defendable and reliable for testing scenarios. The criteria to be used for the calibration and validation for these models are summarized in

Table 1 and are based on microscopic simulation guidelines from FHWA and a United Kingdom publication, the Design Manual for Road and Bridges (DMRB) (Chapter 12).

Figure 2: Aimsun Model Calibration/Validation


7

For all simulation results developed from Aimsun, they are to be averaged over five (5) runs using different random seed. In addition to the average, the standard deviation of the results are to be revised to flag potentially unwanted seed.

Table 1: Calibration and Validation Thresholds

Criteria and Measures Calibration and Validation Acceptance Targets

Individual Link Hourly Flow Rates (including arterials, ramps, and sink/source links)

GEH ≤ 5 for 85% of cases (peak period) GEH ≤ 10 for 95% of cases (peak period)

Sum of All Link Flows Within 5% of sum of all links

Individual Turning Movements Hourly Flow Rates GEH ≤ 5 for 85% of cases (peak period) GEH ≤ 10 for 95 % of cases (peak period)

Screenline Volumes along Corridor between All Signalized Intersections

Within 15% for 100% of cases (peak period)

Link Travel Times Within 15% (or 1 min, if higher) for 90 % of cases (peak period)

Speed Profiles / Bottlenecks/ Queuing Modeler’s Satisfaction

Root Mean Square Error, RMSE RMSE < 30% for all samples

Regression Slope and r2 values > 0.9

Note:

.

where GEH is the GEH statistic, ‘C’ is the observed flow and ‘M’ is the modelled flow

The GEH statistic is a form of the Chi-squared statistic that incorporates both relative and absolute errors and is better at indicating model performance for low volume roads and ramps in the study area (in which the percent difference could be very high). GEH values can either be calculated for individual links or can


8

be calculated for groups of links (e.g. screenlines). GEH is named after a transport planner, Geoffrey E. Havers.

For the regression validation criteria mentioned in

Table 1, a sample from a completed Aimsun simulation project is illustrated in Figure . Regression analysis alone (R2 value only) is not sufficient and the resulting slope of the trend line needs to be compared to the target value line (slope =1).

Figure 3: Sample Peak Hour Calibration Modeled vs. Observed Turning Movement Counts In addition to calibration, the model should be validated to travel time runs (both transit and general vehicles) between every signalized intersections. A sample cumulative plot of travel time is show in Figure 4.


9

Figure 4: Sample Cumulative Travel Time Plot In areas where the model fails to meet the acceptance targets, changes to the model parameters should be performed. Rationale for these changes should be provided. These changes to the parameters may include but are not limited to:

Speed traffic condition limits;

Micro-simulation parameters for vehicle behaviour including turning distances (zone 1, zone 2 parameters), acceleration/deceleration factors, lane changing parameters, car-following parameters, and reaction time parameters;

Yield stop locations for turning movements; and

Red percentages – The amount of time in the All Red phase where vehicles are still using the intersection – in the control plans.

After achieving calibration, the models and all required results should be provided to the City for review and comment before proceeding to the next stage - scenario modeling.

2.3 Step 3 - Scenarios In addition to the existing conditions analysis, there are 2 scenarios that are to be modeled for both AM and PM peak hours with optimized signal timings:

1. With Transit Signal Priority Active 2. With Transit Signal Priority Not-Active.

Both of these scenarios should be developed using the optimized signal timing plans from the Synchro models (AM and PM peak hours). Once the base model is calibrated and the alternative models are generated, a set of MOEs should be used and presented in table format to compare all the models (for each of the peaks). The MOEs reported are to be completed at two levels, major to major intersections (corridor) and overall network. All outputs should be classified by both transit and general vehicles. These


10

MOEs may not be similar to Synchro, but should be in same magnitude and direction of change. Similar to Synchro output, the following MOEs should be generated from Aimsun, and are further discussed below: Total Delay No. of Stops Average Speed Travel Time Emission Fuel Consumption

Total Delay General traffic, transit vehicle and pedestrian delays are to be reported. The below describes the delay MOE:

Vehicle Mean Delay Time – Transit and auto mean delay time are to be reported on a per approach /per intersection basis; Person Delays for transit are to be calculated using the vehicle mean delay time in conjunction with the TTC ridership data collected from the field study (at the survey stop locations). These should be provided on a per approach / per intersection basis. Auto mean delay time should be based on a weighted average of the car and truck delays. Person Delay for general traffic should be calculated, using a default occupancy rate of 1.2 persons per vehicle for general traffic;

Pedestrian Mean Delay Time – This delay should be reported as per approach/per intersection basis; and

Total Network Traffic Delay – This total network delay should be reported for all traffic on the network.

Travel Time General traffic and transit corridor and segment travel times are to be provided. The segment travel times would be on an intersection-intersection basis, where the segments are divided to start and end in between intersections so that the delay from the intersection can be captured. These segments are to be coded using subpaths in Aimsun. The total network travel time, as well as the corridor travel time, are to be reported.

Emissions The MOE's in Aimsun may not be similar to Synchro, but should be in the same magnitude and direction of change. The two in particular are the Fuel Consumption and Emission MOEs as Aimsun uses a more detail algorithm than Synchro when computing those outputs. The default emission parameter in the Panis et al Emission Model, which takes into account acceleration/deceleration rates. The following assumptions should be applied when using the Panis et al approach: The default emission vehicle type: car, HDV, bus are used for the car, truck, and

TTC bus vehicle types respectively. Note that the default values are not calibrated to Toronto vehicles; and

For TTC streetcars, the emission vehicle type: bus will be used with all the factors set to 0 to produce a zero emissions vehicle.


11

Note that these default values are not calibrated for Toronto vehicle conditions and should only be used as a basis of comparison between the different Aimsun scenarios, and not used in comparison with consumption calculations from other programs and models.

The Panis et al emissions model produces emissions for CO2, NOx, PM, and VOC in terms of g/km of modelled network.

Fuel Consumption Similar to the emissions data there is a possibility that the results do not show similar trends as the Synchro fuel consumptions results. The fuel consumption results should be reported on a total network basis for vehicles only as Aimsun provides an example default fuel consumption value. For trucks and TTC buses, the parameters for fuel consumptions are not available from TSS and would require additional research, as such, fuel consumption for trucks and buses are not to be reported. TTC streetcars are assumed to not consume any fuel.

Similar to emissions, the fuel consumption parameters are not calibrated for Toronto vehicle conditions and should only be used as a basis of comparison between the different Aimsun scenarios, and not used in comparison with consumption calculations from other programs and models.

Date post:	03-Oct-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

9148-15-7311 Final Addendum 1 - Toronto · Q2. Section 3.1 – “Group B Vendor to apply the...

Documents