ISAST

Capitolul 1.
Noţiuni introductive
1.1. Definiţie. Clasificare.

Teoria fluxurilor de trafic descrie într-o formă matematică exactă
interacţiunile dintre vehicule şi conducătorii lor (componentele mobile), pe de o
parte, şi infrastructura rutieră (componentele imobile), pe de cealaltă parte. Teoria
fluxurilor de trafic reprezintă o componentă indispensabilă a tuturor modelelor şi
instrumentelor utilizate pentru proiectarea şi managementul arterelor rutiere,
interurbane sau urbane, şi îşi găseşte şi numeroase alte aplicaţii, un exemplu fiind
managementul traficului aerian de pe un aeroport.
Studiul ştiinţific asupra teoriei traficului a început încă din anii 1930, prin
descrierea caracteristicilor traficului rutier, studiul modelelor referitoare la volum şi
viteză şi examinarea comportamentului traficului în intersecţii. În timp, elementele
teoriei traficului au devenit tot mai clar înţelese şi mai uşor de descris prin elemente
matematice şi cu ajutorul tehnologiei computerizate avansate, dar noţiunile
fundamentale sunt la fel de importante astăzi ca şi la începuturile definirii lor. Ele
reprezintă fundaţia pentru toate teoriile, tehnicile şi procedurile aplicate în
proiectarea, funcţionarea şi dezvoltarea sistemelor de transport avansate.
Teoriile şi modelele care vor fi prezentate în continuare sunt dezvoltate pe
baza a numeroase observaţii şi măsurători de trafic executate pe autostrăzi şi alte
segmente rutiere interurbane mari. Există diferenţe între acestea şi drumuri de
ordin mai mic, cum ar fi cele pentru traficul interurban provincial şi pentru străzile
din regiunile urbane. În cazul acestora din urmă, caracteristicile traficului sunt
foarte mult influenţate şi impuse de existenţa intersecţiilor. Fluxul de trafic pentru
intersecţii semnalizate şi nesemnalizate va fi prezentat în capitole separate.
Teoria fluxului de trafic poate fi aplicată la diverse nivele, utilizând parametri
specifici, iar modelele rezultate se pot clasifica în:
- Modele macroscopice: cel mai înalt nivel de integrare, cel mai redus nivel
al detaliilor, au la bază modelele dinamicii fluidelor.
- Modele mezoscopice: nivel înalt de integrare, nivel redus al detaliilor, iau
în considerare comportamentul conducătorilor de vehicule.
- Modele microscopice: nivel redus de integrare, nivel înalt al detaliilor, iau
în considerare detaliile interacţiunilor dintre vehiculele aflate într-un „şir”
de maşini.
1
1.2. Variabile microscopice.
Într-o abordare a traficului la nivel microscopic, fiecare vehicul este examinat
separat, considerându-se că fluxul de trafic este format dintr-un şir de vehicule
individuale. Vehiculele şi conducătorii auto asociaţi acestora au anumite
caracteristici specifice, numite caracteristici microscopice. Cu toate că în această
variantă comportamentul vehiculelor este influenţat într-o foarte măsură de
comportamentul conducătorilor auto, integrarea aspectelor comportamentale
asociate acestora ar conduce la o creştere serioasă a complexităţii problemei. În
cele ce urmează, combinaţia vehicul/conducător de vehicul va fi tratată ca o
entitate.
În Figura 1-1 sunt reprezentate două vehicule consecutive (i şi i+1), care se
deplasează pe aceeaşi bandă de circulaţie, într-o coloană de vehicule.
xi li isi xi+1
(i) (i+1)
dsi
Figura 1-1 – Dispunerea spaţială a două vehicule consecutive, pe aceeaşi bandă
Elementele care se observă pe figură sunt următoarele:

- Poziţia vehiculului (xi), considerată ca fiind poziţia în spaţiu a barei din
spate a vehiculului.
- Intervalul spaţial dintre două vehicule consecutive (isi): distanţa între bara
din faţă a vehiculului antemergător şi bara din spate a vehiculului din faţă.
- Lungimea vehiculului (li).
- Distanţa între cele două vehicule (dsi): distanţa între poziţiile celor două
vehicule.
Se observă că între aceste variabile se pot scrie următoarele relaţii:
𝑑𝑠𝑖 = 𝑙𝑖 + 𝑖𝑠𝑖 (1.1)
2
𝑑𝑠𝑖 = 𝑥𝑖+1 − 𝑥𝑖 (1.2)
Distanţa 𝑑𝑠𝑖 poate fi interpretată şi ca reprezentând spaţiul ocupat de

vehiculul i pe drum, respectiv lungimea vehiculului plus distanţa menţinută de
conducătorul auto faţă de vehiculul din faţă (vezi ecuaţia (1.1)).
Similar cu definiţia de mai sus, un vehicul este caracterizat şi de o distanţă
temporală 𝑑𝑡𝑖 , reprezentând suma dintre intervalul de timp 𝑖𝑡𝑖 şi durata de ocupare
𝜌𝑖 , conform ecuaţiei de mai jos:
𝑑𝑡𝑖 = 𝑖𝑡𝑖 + 𝜌𝑖 (1.3)
Distanţele spaţială şi temporală pot fi vizualizate în Figura 1-2, în care sunt

reprezentate traiectoriile celor două vehicule succesive, traiectoria reprezentând
evoluţia în timp a poziţiei fiecărui vehicul. În partea stângă, pe axa 𝑥 , 𝑥𝑖+1 şi 𝑥𝑖
reprezintă poziţiile în spaţiu ale celor două vehicule, la momentul 𝑡𝑖 . De asemenea,
în figură sunt reprezentate toate elementele menţionate anterior, respectiv
distanţa spaţială 𝑑𝑠𝑖 , distanţa temporală 𝑑𝑡𝑖 , intervalul spaţial 𝑖𝑠𝑖 , respectiv cel
temporal 𝑖𝑡𝑖 şi lungimea vehiculului 𝑙𝑖 , respectiv durata de ocupare 𝜌𝑖 .
spaţiu
xi+1
(i+1) isi
dsi
xi dti
(i)
iti
ti timp
Figura 1-2 – Diagramă spaţio-temporală reprezentând traiectoriile vehiculelor i şi i+1
Pentru o înţelegere mai uşoară a parametrilor prezentaţi, cele două vehicule

au fost reprezentate ca deplasându-se cu aceeaşi viteză, constantă. În acest caz,
3
viteza vehiculului este dată de tangenta unghiului format de traiectorie cu axa
orizontală. Dacă unul dintre vehicule accelerează, traiectoria se va curba ascendent,
iar viteza va fi dată de tangenta la noua traiectorie. Pentru un vehicul care
staţionează, caracteristica sa va fi orizontală, poziţia 𝑥𝑖 rămânând constantă în timp.
1.2.1. Descrierea cu ajutorul mărimilor dependente de

timp
Formulele generale pentru viteza (𝑣𝑖 ) şi acceleraţia (𝑎𝑖 ) ale vehiculului (i) sunt
cele cunoscute, rezultând din prima, respectiv a doua derivată a formulei
traiectoriei. Astfel:
𝑑𝑥𝑖
𝑣𝑖 = (1.4)
𝑑𝑡
𝑑𝑣𝑖 𝑑 2 𝑥𝑖
𝑎𝑖 = = (1.5)
𝑑𝑡 𝑑𝑡 2
Spațiul parcurs de un vehicul individual
Pentru o deplasare cu viteză constantă 𝑣𝑖 , distanţa temporală reprezintă

durata de timp necesară pentru ca vehiculului i să ajungă în poziţia vehiculului
din faţă i+1 (de exemplu, timpul măsurat de un observator fix, între
momentele trecerii a două vehicule consecutive). Similar, durata de ocupare
𝜌𝑖 reprezintă timpul necesar pentru unei distanţe egale cu lungimea proprie a
vehiculului, adică:
𝑙𝑖
𝜌𝑖 = (1.6)
𝑣𝑖
ceea ce corespunde intervalului de timp necesar ca vehiculul să depăşească
poziţia observatorului.
4
În consecinţă, relaţiile (1.1) şi (1.3) pot fi legate de 𝑣𝑖 prin relaţia:
𝑑𝑠𝑖 𝑖𝑠𝑖 𝑙𝑖
𝑣𝑖 = = = (1.7)
𝑑𝑡𝑖 𝑖𝑡𝑖 𝜌𝑖
Formulele şi parametrii definiţi mai sus pot fi extinşi şi pentru circulaţia pe
mai multe benzi, respectiv pentru vehicule care circulă pe benzile învecinate.
În cazul în care se tratează circulaţia pe o singură bandă, vehiculele îşi
păstrează ordinea unul faţă de celălalt, pe principiul numit şi primul intrat/primul
ieşit. În cazul studiului circulaţiei pe mai multe benzi, acest principiu nu se mai poate
aplica, din cauza posibilelor manevre de depăşire. De asemenea, în cazul în care
circulaţia se desfăşoară pe mai multe benzi de circulaţie, dar se studiază numai
vehiculele de pe o bandă, este posibil ca traiectoriile unor vehicule să dispară şi să
reapară, în momentele în care se produc schimbări de bandă.
1.2.2. Descrierea cu ajutorul mărimilor dependente de

spațiu
Se introduce transformarea:
v x  
1
.
dt
dx
Adică:
dx
dt 
v x 
Prin integrare, rezultă:

x
t x   t 0 
dx
 v x  .
xo
Acceleraţia în funcţie de spaţiu se obţine prin derivarea în raport cu timpul a

vitezei vx  :
1 
d  v 2 x 
d v x  d v x  dx d v x 
a x   v x    
2
  
dt dx dt dx dx
Din această relaţie se obţine:
1 
d  v 2 x   ax   dx
2 
deci:
5
x
v 2 x   v 02  2  ax dx ,
x0
x
v x   v 02  2  ax   dx
x0
Diagramele de mişcare ale

autovehiculului funcţie de spaţiu, (a0)
Diagramele de mişcare ale

autovehiculului funcţie de timp, (a0)
Toate variabilele enumerate mai sus pot fi măsurate prin diverse metode,
cum ar fi:
- Măsurarea într-un punct fix.
- Măsurarea pe o secţiune scurtă de drum (mai mică de 10 metri).
- Măsurarea pe o porţiune lungă de drum (cel puţin 500 metri).
- Utilizarea unui observator mobil, care se deplasează în fluxul de trafic.
- Date măsurate pe zone largi, obţinute simultan de la un număr mare de
vehicule, prin intermediul sistemelor inteligente de transport.
6
1.3. Caracteristicile fluxului de trafic la nivel
macroscopic.
1.3.1. Intervale de măsurare

Dacă dorim o abordare a traficului la nivel macroscopic, în loc să discutăm
despre parametrii pentru vehicule individuale, lărgim imaginea la un nivel superior,
în care ne ocupăm de traficul pentru o anumită regiune sau pentru o secţiune mare
de drum. În Figura 1-3, este prezentată evoluţia sistemului, prin intermediul
traiectoriile mai multor vehicule individuale. Diagrama cuprinde toate operaţiunile
de trafic executate de vehicule (accelerări, frânări etc.).
Figura 1-3 – Traiectoriile vehiculelor şi intervalele de măsurare S1 şi S2
Un interval de măsură S este de definit ca o arie cuprinsă în spaţiul t-x.

Definirea variabilelor macroscopice se face întotdeauna pe un astfel de interval. În
Figura 1-3 şi Figura 1-4 sunt prezentate trei tipuri de intervale de măsură: 𝑆1 , 𝑆2 şi 𝑆,
definite mai jos. Aceste intervale sunt limitate în spaţiu de un segment de drum de
lungime X şi de o perioadă de măsurare T.
7
Figura 1-4 – Traiectoriile vehiculelor şi intervalul de măsurare S
- 𝑆1 : un interval de măsură dreptunghiular, care acoperă o secţiune de

drum X, în timpul unui interval de timp care tinde la 0, dt. Practic,
intervalul de măsură corespunde cu o anumită secţiune de drum, la un
moment specific 𝑡1 . Măsurătorile pentru un astfel de interval spaţial pot
fi executate, de exemplu, printr-o fotografie aeriană.
- 𝑆2 : un interval de măsură dreptunghiular care acoperă o secţiune de
drum infinit de mică (tinde la 0) dx, într-un interval de timp T. Practic,
reprezintă măsurătorile executate în intervalul T, într-o anumită locaţie
𝑥2 . Măsurătorile pentru un astfel de interval se pot executa, de exemplu,
cu ajutorul unei bucle inductive.
- 𝑆 este un interval de măsurare de formă aleatorie, în timp şi spaţiu, care
corespunde măsurătorilor generale executate în regiune respectivă (în
intervalul de timp T, pe sectorul de lungime X (de exemplu, printr-o
secvenţă de imagini ale une camere video de supraveghere). Intervalul
este traversat de diverse traiectorii. Distanţa parcursă de un vehicul în
acest interval de măsurare reprezintă proiecţia traiectoriei lui pe axa x.
timpul petrecut de vehicul în intervalul de măsurare este proiecţia
traiectoriei lui pe axa t.
În continuare, pe intervalele descrise mai sus vor fi definite patru
caracteristici macroscopice importante ale fluxului de trafic: densitatea, fluxul,
gradul de ocupare şi viteza medie.
8
1.3.2. Densitatea traficului
Caracteristica macroscopică numită densitate de trafic permite crearea unei
imagini referitoare la nivelul de aglomerare pe o secţiune de drum. Este exprimată
în număr de vehicule pe kilometru. Conceptul de densitate ignoră complet efectele
compoziţiei traficului şi a lungimii vehiculelor, luând în consideraţie numai
cantitatea abstractă denumită „număr de vehicule”.
Densitatea poate fi măsurată numai într-o anumită regiune spaţială (X), ea
trebuie să fie calculată pentru regiunile temporale (T). În cazul în care densitatea
nu poate fi măsurată sau calculată, ea este estimată.
Utilizând intervalul spaţial X, densitatea k pentru traficul pe o bandă de
circulaţie, la momentul 𝑡1 , este definită prin relaţia:
𝑁
𝑘= (1.8)
∆𝑋
unde: k = densitatea traficului (veh/km)
N = numărul de vehicule din intervalul spaţial X (veh)
X = intervalul spaţial (km).
În cazul circulaţiei pe mai multe benzi (L), densitatea totală se obţine prin
însumarea densităţilor 𝑘𝑙 de pe fiecare bandă.
𝐿 𝐿
1
𝑘 = ∑ 𝑘𝑙 = ∑ 𝑁𝑙 (1.9)
∆𝑋
𝑙=1 𝑙=1
unde: 𝑘𝑙 = densitatea traficului pe banda l (veh/km)

𝑁𝑙 = numărul de vehicule din intervalul spaţial X, de pe banda l (veh)
L = numărul de benzi.
La modul general, densitatea poate fi definită ca timpul total petrecut de
toate vehiculele în intervalul de măsurare, împărţit la suprafaţa intervalului:
𝑁 𝑁
∑𝑁
𝑖=1 𝑇𝑖 1 𝑑𝑥 1 1
𝑘= = ∑ = ∑ (1.10)
∆𝑇𝑑𝑥 ∆𝑇𝑑𝑥 𝑣𝑖 ∆𝑇 𝑣𝑖
𝑖=1 𝑖=1
unde: 𝑇𝑖 = timpul de călătorie al vehiculului i.

𝑣𝑖 = viteza vehiculului i.
Extinzând formula (1.10) la traficul pe mai multe benzi de circulaţie (vezi
formula 1.9), rezultă:
9
𝐿 𝑁𝑙
1 1
𝑘= ∑∑ (1.11)
∆𝑇 𝑣𝑖,𝑙
𝑙=1 𝑖=1
unde: 𝑣𝑖,𝑙 = viteza vehiculului i de pe banda l.

După ce am obţinut densitatea atât în intervalul spaţial 𝑆1 , cât şi în cel
temporal 𝑆2 , putem extinde acum formulele, pentru a obţine densitatea pentru
intervalul spaţio-temporal S. Totuşi, pentru a putea face acest lucru, este necesar să
cunoaştem timpii de călătorie 𝑇𝑖 pentru fiecare vehicule individual i. Deoarece
această informaţie nu este valabilă tot timpul, se va calcula o medie temporală a
densităţii. Presupunând că este cunoscută densitatea k(t) pentru regiunile
consecutive ∆𝑋, pentru fiecare pas de timp t dintr-o anumită perioadă ∆𝑇, se
ajunge la următoarele formule de calcul:
∆𝑇
1
∫ 𝑘 (𝑡 )𝑑𝑡 , (𝑐𝑜𝑛𝑡𝑖𝑛𝑢𝑢)
∆𝑇
𝑘= 𝑡=0 (1.12)
∆𝑇
1
∑ 𝑘 (𝑡 ), (𝑑𝑖𝑠𝑐𝑟𝑒𝑡)
{ ∆𝑇 𝑡=1
Pentru traficul pe mai multe benzi de circulaţie, din combinaţia formulelor

(1.9) şi (1.12), rezultă:
∆𝑇 𝐿
1
𝑘= ∑ ∑ 𝑁𝑙 (𝑡) (1.13)
∆𝑇∆𝑋
𝑡=1 𝑙=1
unde: 𝑁𝑙 (𝑡) = numărul de vehicule prezente pe banda 𝑙 la momentul 𝑡.
1.3.3. Fluxul de trafic

În vreme ce densitatea este o caracteristică macroscopică spaţială, fluxul de
trafic este o caracteristică temporală (se defineşte pe intervalul de măsurare 𝑆2 ).
Rata fluxului de trafic (denumită pe scurt flux) reprezintă exprimarea unei rate
orare, adică al numărului de vehicule pe oră.
Fluxul 𝑞 în intervalul 𝑆2 , pentru traficul pe o bandă de circulaţie, este definit
prin următoarea relaţie, bazată pe simpla numărare a vehiculelor:
𝑁
𝑞= (1.14)
∆𝑇
unde: q = fluxul de trafic (veh/oră)
T = intervalul temporar (oră).
10
N = numărul de vehicule care trec prin dreptul detectorului de vehicule în
intervalul T (veh)
În cazul circulaţiei pe mai multe benzi (L), fluxul total se obţine prin
însumarea fluxurilor 𝑞𝑙 de pe fiecare bandă.
𝐿 𝐿
1
𝑞 = ∑ 𝑞𝑙 = ∑ 𝑁𝑙 (1.15)
∆𝑇
𝑙=1 𝑙=1
unde: 𝑞𝑙 = fluxul pe banda l (veh/oră)

𝑁𝑙 = numărul de vehicule din intervalul temporal T, de pe banda l (veh)
L = numărul de benzi.
La modul general, fluxul poate fi definit ca distanţa totală parcursă de toate
vehiculele în intervalul de măsurare, împărţită la suprafaţa intervalului:
𝑁 𝑁
∑𝑁𝑖=1 𝑋𝑖 1 1
𝑞= = ∑ 𝑣𝑖 𝑑𝑡 = ∑ 𝑣𝑖 (1.16)
∆𝑋𝑑𝑡 ∆𝑋𝑑𝑡 ∆𝑋
𝑖=1 𝑖=1
unde: 𝑋𝑖 = distanţa parcursă de vehiculul i.

𝑣𝑖 = viteza vehiculului i.
Extinzând formula (1.16) la traficul pe mai multe benzi de circulaţie, rezultă:
𝐿 𝑁𝑙
1
𝑞= ∑ ∑ 𝑣𝑖,𝑙 (1.17)
∆𝑋
𝑙=1 𝑖=1
unde: 𝑣𝑖,𝑙 = viteza vehiculului i de pe banda l.

Considerând că se execută măsurători de trafic consecutive în intervalul
intervalul spaţio-temporal S, ca şi în cazul densităţii se poate obţine o formulă
corespunzătoare unei medii temporale a fluxului de trafic. Presupunând că este
cunoscut fluxul q(t) pentru regiunile consecutive ∆𝑋, pentru fiecare pas de timp t
dintr-o anumită perioadă ∆𝑇, se ajunge la următoarele formule de calcul:
∆𝑇
1
∫ 𝑞(𝑡 )𝑑𝑡 , (𝑐𝑜𝑛𝑡𝑖𝑛𝑢𝑢)
∆𝑇
𝑞= 𝑡=0 (1.18)
∆𝑇
1
∑ 𝑞 (𝑡 ), (𝑑𝑖𝑠𝑐𝑟𝑒𝑡)
{ ∆𝑇
𝑡=1
Pentru traficul pe mai multe benzi de circulaţie, din combinaţia formulelor

(1.17) şi (1.18), rezultă:
11
∆𝑇 𝐿 𝑁𝑙 (𝑡)
1
𝑞= ∑ ∑ ∑ 𝑣𝑖,𝑙 (𝑡) (1.19)
∆𝑇∆𝑋
𝑡=1 𝑙=1 𝑖=1
unde: 𝑁𝑙 (𝑡) = numărul de vehicule prezente pe banda 𝑙 la momentul 𝑡.
1.3.4. Gradul de ocupare

Majoritatea detectoarelor de trafic pot efectua numai măsurători temporale
(de exemplu, pe intervalul ∆ 𝑇). În cazul utilizării unor bucle inductive duble, de
exemplu, se pot măsura vitezele vehiculelor individuale şi atunci densitatea
traficului poate fi calculată.
Totuşi, în cele mai multe cazuri nu există informaţii referitoare la aceste
viteze. În consecinţă, se apelează la o altă măsură temporală, denumită grad de
ocupare 𝜌, care corespunde fracţiunii de timp în care locaţia de măsurare a fost
ocupată de un vehicul:
𝑁
1
𝜌= ∑ 𝑜𝑖 (1.20)
∆𝑇
𝑖=1
unde: 𝜌 = gradul de ocupare

𝑜𝑖 = durata în care vehiculul i este prezent deasupra detectorului (s)
Se poate spune că 𝑜𝑖 reprezintă lungimea vehiculului, aşa cum a fost această
văzută de detector, împărţită la viteza vehiculului respectiv:
𝑙𝑖 + 𝐿𝑧𝑑
𝑜𝑖 = (1.21)
𝑣𝑖
unde: 𝑙𝑖 = lungimea reală a vehiculului i
𝐿𝑧𝑑 = lungimea finită a zonei de detecţie
Dacă definim o durată de ocupare medie 𝑜𝑖𝑚 , dată de formula:
𝑁
1
𝑜𝑖𝑚 = ∑ 𝑜𝑖 (1.22)
𝑁
𝑖=1
atunci se poate stabili o relaţie între gradul de ocupare şi flux, folosind relaţiile
(1.14), (1.20) şi (1.22):
𝑁 𝑁
1 𝑁 1
𝜌= ∑ 𝑜𝑖 = ( ) ( ∑ 𝑜𝑖 ) = 𝑞𝑜𝑖𝑚 (1.23)
∆𝑇 ∆𝑇 𝑁
𝑖=1 𝑖=1
Înlocuind în relaţia (1.20):
12
𝑁
1
𝜌= ∑ 𝑜𝑖 (1.20)
∆𝑇
𝑖=1
formula lui 𝑜𝑖 dată de relaţia (1.21):

𝑙𝑖 + 𝐿𝑧𝑑
𝑜𝑖 = (1.21)
𝑣𝑖
şi introducând o lungime medie a vehiculelor şi o lungime constantă a zonei de
detecţie), rezultă:
𝑁 𝑁
1 𝐿 1 1
𝜌= ∑ = 𝐿( ∑ ) (1.24)
∆𝑇 𝑣𝑖 ∆𝑇 𝑣𝑖
𝑖=1 𝑖=1
unde: L = suma lungimii medii a vehiculelor şi a lungimii zonei de detecţie

𝑣𝑖 = viteza individuală a vehiculului i.
Din relaţia (1.10), ştim că densitatea traficului este:
𝑁
1 1
𝑘= ∑ (1.10)
∆𝑇 𝑣𝑖
𝑖=1
În consecinţă, între densitatea fluxului de trafic şi gradul de ocupare se poate

scrie următoarea relaţie:
𝜌 = 𝐿𝑘 (1.25)
Înlocuind în această relaţie formula densităţii k pentru întregul interval ∆ 𝑋:
𝑁
𝑘= (1.8)
∆𝑋
rezultă:
𝑁
𝜌=𝐿 (1.26)
∆𝑋
În ecuaţia de mai sus, produsul dintre L (lungimea medie a vehiculelor) şi N
(numărul de vehicule de pe intervalul ∆ 𝑋) poate fi înlocuit cu suma lungimilor
vehiculelor individuale, rezultând:
𝑁
1
𝜌= ∑ 𝑙𝑖 (1.27)
∆𝑋
𝑖=1
Relaţia de mai sus poate fi interpretată prin definiţia: gradul de ocupare

reprezintă „densitatea reală” a drumului, adică spaţiul fizic ocupat efectiv de toate
vehiculele de pe intervalul de măsurare.
13
1.3.5. Viteza medie
Ultima caracteristică macroscopică importantă este viteza medie a fluxului de
trafic. Aceasta se exprimă în kilometri pe oră şi reprezintă o viteză medie spaţială.
Dacă calculăm viteza medie pe baza măsurării directe a vitezelor vehiculelor
individuale, atunci o putem defini ca fiind distanţa totală parcursă de toate
vehiculele din intervalul de măsurare, împărţită la timpul total petrecut de vehicule
în acest interval. Din această definiţie, rezultă următoarele formule de calcul:
𝑁
∑𝑁
𝑖=1 𝑣𝑖 𝑑𝑡 1
= ∑ 𝑣𝑖 , (𝑟𝑒𝑔𝑖𝑢𝑛𝑒𝑎 ∆𝑋)
∑𝑁 𝑁𝑑𝑡 𝑁
𝑖=1 𝑋𝑖 𝑖=1
𝑣𝑚 = 𝑁 = (1.28)
∑𝑖=1 𝑇𝑖 𝑁𝑑𝑥 𝑁𝑑𝑥
= , (𝑟𝑒𝑔𝑖𝑢𝑛𝑒𝑎 ∆𝑇)
𝑑𝑥 1 𝑁 1
∑𝑁 ∑
{ 𝑖=1 𝑣𝑖 𝑁 𝑖=1 𝑣𝑖
unde: 𝑋𝑖 = distanţa parcursă de vehiculul i
𝑇𝑖 = durata parcursă de vehiculul i
N = numărul de vehicule prezent în timpul măsurătorii.
Este interesant de observat că viteza medie pentru intervalul spaţial
reprezintă media aritmetică a vitezelor individuale ale vehiculelor, în timp ce viteza
medie pentru intervalul temporal reprezintă media armonică a acestora.
Pe lângă definiţiile de mai sus, mai putem defini viteza medie temporală 𝑣𝑚𝑡 ,
ca reprezentând media aritmetică a vitezelor vehiculelor individuale într-un interval
de timp, conform formulei de mai jos (pe regiunea ∆ 𝑇):
𝑁
1
𝑣𝑚𝑡 = ∑ 𝑣𝑖 (1.29)
𝑁
𝑖=1
1.3.6. Relaţia fundamentală a teoriei traficului

Între trei dintre caracteristicile macroscopice prezentate mai sus, şi anume:
densitatea k, fluxul q şi viteza medie spaţială, există o relaţie denumită relaţia
fundamentală a teoriei traficului:
𝑞 = 𝑘𝑣𝑚 (1.30)
Cunoscând această relaţie şi două dintre cantităţi, poate fi calculată foarte
uşor a treia. De obicei, cel mai greu de măsurat este densitatea fluxului de trafic,
care însă poate fi calculată sau estimată cu ajutorul relaţiei de mai sus, în urma
măsurătorilor referitoare la fluxul de trafic şi la viteza medie a traficului.
14
1.4. Diagramele fundamentale ale traficului.
Traficul rutier se află în permanenţă într-o stare ce poate fi caracterizată prin
rata fluxului de trafic, densitate şi viteza medie. Toate stările posibile ale traficului
pot fi combinate într-o funcţie ce este descrisă grafic prin trei diagrame, cunoscute
sub numele de diagrame fundamentale ale traficului.
Fiecare dintre aceste diagrame evidenţiază relaţia dintre două dintre cele trei
caracteristici menţionate mai sus, iar a treia variabilă poate fi calculată prin
intermediul relaţiei fundamentale a teoriei traficului:
𝑞 = 𝑘𝑣𝑚 (1.30)
1.4.1. Regimuri de trafic

Înainte de trasa cele trei diagrame fundamentale, este necesară definirea
regimurilor (sau stărilor) de trafic în care se poate găsi un anumit flux de trafic.
Fiecare dintre aceste regimuri este caracterizat de un set unic de proprietăţi, iar
clasificarea lor se poate face fie pe baza gradului de ocupare al autostrăzii, fie
printr-o combinaţie a diferiţi parametri de trafic macroscopici.
Regimul trafic liber

În condiţiile în care traficul este redus, vehiculele pot călători cu viteza dorită,
o viteză maximă ce este notată: 𝑣𝑡𝑙 , adică viteza de trafic liber. În acest caz,
conducătorii auto nu sunt „deranjaţi” de celelalte vehicule şi încearcă să
călătorească la viteza cea mai convenabilă, iar dacă în faţa lor se află vehicule ce
merg mai încet, le pot depăşi fără probleme. În ciuda acestei posibilităţi de a
călători cu viteza dorită, conducătorii auto trebuie să ţină cont, totuşi, de viteza
maximă admisă pe sectorul de drum respectiv (𝑣𝑚𝑎𝑥 ).
Călătoria în regim trafic liber este posibilă, în esenţă, doar în cazul unui trafic
în care nu apar întârzieri din cauza vehiculelor din jur, datorită capacităţii de a
executa manevre de depăşire. Acest regim este caracterizat de densităţi de trafic
reduse, adică de distanţe spaţiale mari între vehicule. În consecinţă, într-un regim
trafic liber micile perturbaţii locale ce pot să apară pot fi considerate ca având
efecte nesemnificative, iar fluxul de trafic este considerat stabil.
Regimul trafic la capacitate

Pe măsură ce densitatea traficului creşte, distanţa între vehicule scade. La un
moment dat, fluxul de trafic va ajunge la o valoare maximă, numită capacitate a
drumului şi notată cu 𝑞𝑐 . Atunci când rata fluxului de trafic atinge această valoare,
15
distanţa temporală medie între vehicule este minimă, aceasta semnificând
formarea de grupuri de vehicule foarte apropiate între ele, care se deplasează cu o
viteză de trafic la capacitate 𝑣𝑐 , mai mică decât viteza de trafic liber. De asemenea,
valorilor de trafic la capacitate ale fluxului şi vitezei le corespunde o valoare de
trafic la capacitate a densităţii, notată cu 𝑘𝑐 . Trebuie specificat că astfel de plutoane
de maşini care se deplasează cu viteză mare sunt foarte instabile, deoarece frânarea
unuia dintre vehicule poate avea un efect în cascadă, producând frânări excesive ale
maşinilor aflate în spate. În consecinţă, în acest moment se poate spune că traficul
devine instabil.
Regimul trafic saturat

În momentul în care densitatea traficului creşte peste valoarea
corespunzătoare traficului la capacitate, se intră în regimul de trafic saturat, în care
rata fluxului şi viteza scad spre zero. Încep să se formeze coloane mari de maşini, iar
valoarea densităţii creşte tot mai mult. Starea traficului în aceste condiţii este
denumită trafic congestionat sau saturat. În condiţiile extreme în care traficul
devine nemişcat, distanţa spaţială între vehicule devine minimă şi maşinile stau
„bară la bară”, traficul se numeşte blocat. Valoarea corespunzătoare a densităţii de
trafic în această situaţie se numeşte densitate de blocare (𝑘𝑏 ) şi reprezintă valoarea
maximă posibilă a acestui parametru de trafic.
1.4.2. Modele matematice pentru diagramele

fundamentale
Modelul Greenshield
Greenshield a fost primul care a trasat diagramele fundamentale, pe baza
unui număr redus de numărători de trafic. În concepţia lui, diagrama k-v este liniară,
ceea ce conduce la relaţii parabolice pentru celelalate diagrame.
Deşi aceste diagrame reprezintă o simplificare destul de brută a traficului
măsurat, ele sunt des folosite încă, datorită simplicităţii lor. Funcţia de echilibru din
diagrama k-v poate fi scrisă sub forma:
𝑣𝑚𝑎𝑥 𝑘
𝑣 (𝑘 ) = (𝑘𝑏 − 𝑘 ) = 𝑣𝑚𝑎𝑥 (1 − ) (1.31)
𝑘𝑏 𝑘𝑏
Aplicând relaţia fundamentală a traficului, rezultă:
𝑣𝑚𝑎𝑥 𝑘
𝑞 (𝑘 ) = 𝑘 × 𝑣 (𝑘 ) = 𝑘 (𝑘𝑏 − 𝑘 ) = 𝑘𝑣𝑚𝑎𝑥 (1 − ) (1.32)
𝑘𝑏 𝑘𝑏
16
v v
v max v max
stabil
stabil
vc vc
instabil
instabil
q kc kb k qc q
qc
stabil instabil
kc kb k
Figura 1-5 – Diagramele fundamentale ale lui Greenshield
În formula de mai sus, vom calcul densitatea pentru care fluxul este maxim.
𝑣𝑚𝑎𝑥 2
𝑑𝑞 𝑑(𝑣𝑚𝑎𝑥 𝑘 − 𝑘 ) 2𝑣𝑚𝑎𝑥
𝑘𝑏 (1.33)
= = 𝑣𝑚𝑎𝑥 − 𝑘
𝑑𝑘 𝑑𝑘 𝑘𝑏
După cum ştim, fluxul maxim se obţine în regimul trafic la capacitate şi este
notat cu 𝑞𝑐 , iar valoarea corespunzătoare a densităţii este 𝑘𝑐 . Din condiţia obţinerii
𝑑𝑞
maximului ( ⁄𝑑𝑘 = 0), rezultă:
2𝑣𝑚𝑎𝑥
𝑣𝑚𝑎𝑥 − 𝑘𝑐 = 0 (1.34)
𝑘𝑏
echivalent cu:
1
𝑘𝑐 = 𝑘 (1.35)
2 𝑏
Înlocuind relaţia (1.35) în formula lui 𝑣 (𝑘 ) (1.31), pentru 𝑘 = 𝑘𝑐 , obţinem:
𝑘𝑐 1 1
𝑣 (𝑘𝑐 ) = 𝑣𝑐 = 𝑣𝑚𝑎𝑥 (1 − ) = 𝑣𝑚𝑎𝑥 (1 − ) = 𝑣𝑚𝑎𝑥 (1.36)
𝑘𝑏 2 2
În concluzie, în diagramele lui Greenshield, viteza de trafic la capacitate 𝑣𝑐
este jumătatea vitezei maxime 𝑣𝑚𝑎𝑥 pentru trafic liber, iar densitatea de trafic la
capacitate 𝑘𝑐 reprezintă jumătate din densitatea de blocare 𝑘𝑏 .
17
Ţinând cont de relaţiile de mai sus, se obţine valoarea fluxului maxim, adică a
fluxului în regim la capacitate (𝑞𝑐 ):
1 1 1
𝑞𝑐 = 𝑘𝑐 × 𝑣𝑐 = 𝑘𝑏 × 𝑣𝑚𝑎𝑥 = 𝑘𝑏 𝑣𝑚𝑎𝑥 (1.37)
2 2 4
De asemenea, înlocuind în relaţia (1.31) densitatea 𝑘 din relaţia
fundamentală a traficului, obţinem:
𝑘 1 𝑞
𝑣 = 𝑣𝑚𝑎𝑥 (1 − ) = 𝑣𝑚𝑎𝑥 (1 − )
𝑘𝑏 𝑘𝑏 𝑣
de unde se extrage 𝑞:
𝑣
𝑞 (𝑣 ) = 𝑘𝑏 𝑣(1 − ) (1.34)
𝑣𝑚𝑎𝑥
Formula de mai sus reprezintă funcţia inversă pentru 𝑣 (𝑞) din Figura 1-5.
Diagrama triunghiulară
O a doua variantă foarte des utilizată a diagramei fundamentale k-q este cea
de formă triunghiulară (Figura 1-6).
v
v
v max v max stabil
stabil
instabil
instabil
q kc kb k qc q
qc
stabil
w
instabil
v max
kc kb k
Figura 1-6 – Diagramele fundamentale în cazul diagramei k-q triunghiulare
18
În această variantă, se consideră că traficul are o viteză constantă, egală cu
𝑣𝑚𝑎𝑥 , pe toată porţiunea dinaintea atingerii densităţii la capacitate 𝑘𝑐 . Viteza
constantă 𝑣𝑚𝑎𝑥 se regăseşte şi ca pantă a primei părţi a caracteristicii triunghiulare,
zonă corespunzătoare traficului liber.
Partea a doua a caracteristicii triunghiulare, cea care leagă starea de trafic la
capacitate de starea de trafic saturat, are o pantă descendentă, egală cu 𝑤.
1.4.3. Diagramele fundamentale asociate ale traficului

În urma unor măsurători empirice extinse şi a eliminării erorilor din modelele
mai vechi, în prezent s-a stabilit că forma cea mai corectă şi mai universală a celor
trei diagrame fundamentale asociate ale traficului este cea reprezentată în Figura
1-7.
v
v
v max v max
stabil vc stabil
vc
instabil
qc
instabil kc
q kc kb k qc q
qc
stabil instabil
vc
kc kb k
Figura 1-7 – Cele trei diagrame fundamentale asociate ale traficului
Se observă că pentru diagramele v-q şi q-k, a treia variabilă este un unghi, în

timp ce pentru diagrama v-k, a treia variabilă este o arie. Ca şi în cazurile anterioare,
pe diagrame au fost reprezentate zonele corespunzătoare traficului stabil (regim
trafic liber) şi instabil (regim trafic peste capacitate).
Concluziile de mai jos sunt valabile pentru toate cele trei tipuri de modele
prezentate:
- La densitate 0, fluxul de trafic este 0 (nu există vehicule pe drum).
19
- Pe măsură ce densitatea creşte, fluxul de trafic creşte până la o valoare
maximă, corespunzătoare regimului de trafic la capacitate.
- O creştere şi mai mare a densităţii va produce o scădere a fluxului de
trafic până la 0, atunci când densitatea ajunge la valoarea denumită
densitate de blocare
20
Capitolul 2. Modelarea traficului rutier
2.1. Calea cea mai scurtă

Problema stabilirii celei mai scurte căi între două noduri, astfel încât suma
valorilor legăturilor sale să fie minimă. În cazul stabilirii distanței cele mai scurte
între două locații pe hartă, nodurile reprezintă locații, iar legăturile reprezintă
segmente de drum. Valorile alocate legăturilor pot reprezenta distanțe, durate de
parcurgere etc.
Problema stabilirii căii celei mai scurte poate fi definită în mai multe moduri,
și anume:
- Calea cea mai scurtă între o pereche de noduri – determinarea căii celei
mai scurte între două noduri ale grafului
- Calea cea mai scurtă cu sursă unică – determinarea căii celei mai scurte
de la un singur nod la toate nodurile din graf
- Calea cea mai scurtă cu destinație unică – determinarea căii celei mai
scurte dintre toate nodurile și un nod destinație. Este identică cu
problema anterioară, dacă se inversează direcția legăturilor din graf
- Calea cea mai scurtă între toate nodurile – determinarea căii celei mai
scurte între oricare două noduri din graf.
Cei mai importanți algoritmi pentru rezolvarea acestor probleme sunt:
- Grafurile valorice
- Algoritmul lui Dijkstra, rezolvă problemele căii celei mai scurte între o
pereche de noduri, cu sursă unică și cu destinație unică
- Algoritmul lui Bellman-Ford, rezolva problema căii celei mai scurte cu
sursă unică, chiar și în cazul în care există legături negative
- Algoritmul lui Floyd – Warshall, rezolvă problema căii celei mai scurte
între toate nodurile.
- Algoritmul lui Johnson, rezolvă problema căii celei mai scurte între toate
nodurile și este mai rapid decât cel anterior.
21 Capitolul 3. Intersecţii semaforizate

2.1.1. Grafurile valorice
Într-un graf valoric, fiecărei legături îi este asociată o valoare numerică.
Această valoare poate reprezenta: distanțe, timp, cost etc.
Pentru un astfel de graf valoric, se dorește calcularea distanței minime între
două noduri u și v. Lungimea căii de parcurs este egală cu suma lungimilor
legăturilor componente.
Proprietăți:
1. O rută formată din legături cu valori minime reprezintă ea însăși cea mai
scurtă cale.
2. De la fiecare nod de start se poate construi un arbore de cele mai scurte

căi către toate celelalte noduri.
Metoda este foarte laborioasă și presupune parcurgerea unui număr mare de

pași. Nu poate fi utilizată în cazul unor rețele complexe.
2.1.2. Algoritmul lui Dijkstra

Rezolvă problema celei mai scurte căi pentru un graf cu legături cu valori
pozitive, producând un arbore al căilor celor mai scurte. Algoritmul este deseori
folosit în stabilirea rutelor de transport, în diverse programe.
Pentru un anumit nod sursă stabilit, algoritmul descoperă calea cu costul cel
mai scurt. Poate fi folosit și pentru stabilirea costurilor pentru cea mai scurtă cale
între un nod sursă și un nod destinație, oprind algorimtul odată ce este determinată
calea cea mai scurtă până la nodul destinație. De exemplu, dacă nodurile grafului
reprezintă orașe, iar costurile legăturilor dintre noduri reprezintă distanțe de
călătorie între perechi de orașe conectate de un drum direct, algoritmul lui Dijkstra
poate fi folosit pentru stabilirea rutei cele mai scurte de la un oraș la toate celelalte
orașe.
Algoritmul
Denumim nodul cu care începem: nod inițial. Valoarea nodului Y reprezintă
distanța între nodul inițial și nodul Y. Algoritmul lui Dijkstra alocă anumite valori
inițiale fiecărui nod și încearcă să le îmbunătățească (minimizeze) pas cu pas.
Presupuneri inițiale:
- Nu există noduri neconectate
- Legăturile dintre noduri sunt nedirecționale
- Valorile legăturilor sunt pozitive.
Pașii algoritmului:
1. Se alocă fiecărui nod o valoare. Aceasta este setată la 0 pentru nodul
inițial și la infinit pentru toate celelalte noduri.
2. Se marchează toate nodurile ca neprocesate.
3. Pentru nodul curent, se iau toți vecinii neprocesați și se calculează
valoarea acestora (față de nodul inițial). De exemplu, dacă nodul curent A
are valoarea 6, iar între el și nodul B există o legătură cu valoare (distanță)
2, atunci valoarea lui B prin A va fi 8. Dacă această valoare este mai mică
decât cea alocată anterior nodului B, acestuia i se realocă noua valoare.
4. Când am terminat cu calcularea valorilor pentru toți vecinii nodului
curent, acest nod este marcat ca procesat. Un nod procesat nu mai este
verificat din nou, iar valoarea alocată lui în acest moment este
considerată finală și minimă.
5. Dacă au fost procesate toate nodurile, algoritmul se încheie. Altfel, se
setează nodul neprocesat cu valoarea cea mai mică față de nodul inițial ca
următorul nod curent și se reia de la pasul 3.
EXEMPLUL 1 – Stabilirea celor mai scurte distanțe între A și toate celelalte noduri

EXEMPLUL 2 – Stabilirea celei mai scurte distanțe între două noduri
Să se calculeze calea cea mai scurtă între intersecțiile a și b.

De ce nu funcționează pentru legături cu valori negative?
Nodul C a fost deja procesat și are valoarea 5, dar după stabilirea nodului F ca nod
curent, ar trebui sa aibă valoarea 1.
2.1.3. Algoritmul lui Bellman – Ford

Calculează calea cea mai scurtă cu sursă unică într-un graf valoric cu legături
orientate, chiar și în cazul valorilor negative. Pentru grafurile care au numai valori
pozitive, algoritmul lui Dijkstra este mai rapid.
Funcționează similar cu algoritmul lui Dijkstra, dar în loc să selecteze nodul
următor ca fiind nodul cu valoarea cea mai mică și care nu a fost încă procesat,
selecteaza toate nodurile, și face acest lucru de n-1 ori, unde n este numărul
nodurilor din graf. Prezintă avantajul de a lucra in cazul cel mai general.

EXEMPLUL 1 – Stabilirea celei mai scurte căi de la sursă (nodul 0) la fiecare nod
destinație
EXEMPLUL 2 – Stabilirea celei mai scurte căi de la sursă (nodul 0) la fiecare nod
destinație

2.1.4. Algoritmul lui Johnson
Reprezintă un mod de a calcula distanța cea mai scurtă dintre toate perechile
de noduri dintr-un graf orientat. Permite ca o parte dintre valorile legăturilor să fie
numere negative. Folosește algoritmul Belmann-Ford ca să transforme graful inițial
prin eliminarea valorilor negative, iar apoi algoritmul Dijkstra pentru graful
transformat.
Algoritm:
1. Se adaugă un nod nou q, conectat cu legături de valoare 0 la celelalte
noduri.
2. Se aplică algoritmul Bellman-Ford, pornind din nodul q, pentru a găsi
pentru fiecare dintre celelalte noduri o valoare minimă h(v) față de nodul
q.
3. Legăturile grafului original sunt recalculate, folosind valorile determinate
prin algoritmul Bellman-Ford, astfel: o legătură de la nodul u, la nodul v,
care avea valoarea w(u,v), primește acum valoarea w(u,v) + h(u) – h(v).
4. Nodul q este eliminat și se utilizează algoritmul lui Dijkstra pentru a găsi
cea mai scurtă cale de la fiecare dintre noduri la celelalte noduri, în graful
nou desenat.

În acest nou graf, pentru toate căile dintre o pereche de noduri s și t s-a
adăugat aceeași valoare h(s) – h(t), așa încât cea mai scurtă cale dintre ele coincide
cu cea mai scurtă cale pentru graful original. De data aceasta însă, în noul graf,
toate valorile legăturilor sunt pozitive, asigurând posibilitatea utilizării algorimtului
lui Dijskstra.
EXEMPLUL 1 – Stabilirea celei mai scurte căi între două noduri
Primul graf este cel inițial și are două legături cu valori negative. În centru
este reprezentat nodul q și sunt recalculate valorile nodurilor față de acest nou nod
(cu algoritmul Bellman-Ford). Apoi sunt recalculate valorile legăturilor, cu formula
dată mai sus, rezultând un graf echivalent cu primul, dar numai cu valori pozitive ale
legăturilor. Cea mai scurtă cale dintre oricare două noduri folosește aceeași
secvență de legături ca și în cazul grafului original. Algoritmul Johnson se încheie
prin aplicarea algoritmului lui Dijkstra pentru fiecare dintre cele patru noduri.
2.2. Instrumente software pentru managementul

traficului
Pachetele de simulare a traficului utilizeaza relatiile fundamentale dintre
fluxul de trafic, viteza si densitate pentru a estima capacitatea unei retele rutiere si
performantele sistemului. Exista doua tipuri principale de modele de simulare:
microsimulare si macrosimulare. Modelele de microsimulare incorporeaza algoritmi
specifici tip „car-following”, performanta vehicul si de schimbare a benzilor de
circulatie, pentru a modela comportamentul vehiculelor individuale. Pe de alta
parte, modelele de macrosimulare nu se concentreaza asupra vehiculelor
individuale din fluxul de trafic, ci asupra fluxului in sine, folosind ecuatii ale
fluxurilor continue. Aceste modele macroscopice necesita mai putine date de

În acest nou graf, pentru toate căile dintre o pereche de noduri s și t s-a
adăugat aceeași valoare h(s) – h(t), așa încât cea mai scurtă cale dintre ele coincide
cu cea mai scurtă cale pentru graful original. De data aceasta însă, în noul graf,
toate valorile legăturilor sunt pozitive, asigurând posibilitatea utilizării algorimtului
lui Dijskstra.
EXEMPLUL 1 – Stabilirea celei mai scurte căi între două noduri
Primul graf este cel inițial și are două legături cu valori negative. În centru
este reprezentat nodul q și sunt recalculate valorile nodurilor față de acest nou nod
(cu algoritmul Bellman-Ford). Apoi sunt recalculate valorile legăturilor, cu formula
dată mai sus, rezultând un graf echivalent cu primul, dar numai cu valori pozitive ale
legăturilor. Cea mai scurtă cale dintre oricare două noduri folosește aceeași
secvență de legături ca și în cazul grafului original. Algoritmul Johnson se încheie
prin aplicarea algoritmului lui Dijkstra pentru fiecare dintre cele patru noduri.
2.2. Instrumente software pentru managementul

traficului
Pachetele de simulare a traficului utilizeaza relatiile fundamentale dintre
fluxul de trafic, viteza si densitate pentru a estima capacitatea unei retele rutiere si
performantele sistemului. Exista doua tipuri principale de modele de simulare:
microsimulare si macrosimulare. Modelele de microsimulare incorporeaza algoritmi
specifici tip „car-following”, performanta vehicul si de schimbare a benzilor de
circulatie, pentru a modela comportamentul vehiculelor individuale. Pe de alta
parte, modelele de macrosimulare nu se concentreaza asupra vehiculelor
individuale din fluxul de trafic, ci asupra fluxului in sine, folosind ecuatii ale
fluxurilor continue. Aceste modele macroscopice necesita mai putine date de

intrare si eforturi de codare mai mici, dar ofera si nivele mai reduse pentru detaliile
de iesire.
La modul general, software-ul pentru modelarea traficului porneste de la o
descriere amănunţită a elementelor studiate (intersecţii/grupuri de intersecţii),
realizând analiza din punct de vedere al capacităţii acestora de a face faţă traficului.
Principalele caracteristici care trebuie cunoscute sunt:
 Reprezentarea grafică a intersecţiilor
 Stabilirea fluxurilor de vehicule
 Stabilirea timpilor initiali de semaforizare si a planurilor de
semaforizare\
 Distanta intre intersectii
 Zonele carora le sunt alocate sau nu intersectiile etc.
Software-ul ofera diverse rapoarte, in functie de calculele efectuate, in care
pot fi cuprinse, de exemplu:
 întârzieri
 LOS (nivelul serviciului)
 lungimea ciclului
 fazele de semaforizare
 timpii de semaforizare
 intarzieri
 coloane de vehicule
 consum de combustibil etc.
2.2.1. Algoritmi microsimulare

Majoritate modelelor de microsimulare utilizeaza diversi algoritmi si modele
de comportament al conducatorilor de vehicule, pentru simularea deplasarii
vehiculelor individuale intr-o retea. Pentru fiecare vehicul care intra in retea se
aloca un anumit tip de vehicul (autoturism, camion, autobuz) si caracteristici
corespunzatoare (acceleratie, franare, viteza, caracteristici de viraj). De asemenea,
se aloca diverse caracteristici pentru soferi (mergand de la agresiv, la prudent).
Pozitia si viteza fiecarui vehicul este actualizata o data pe secunda, in functie
de caracteristicile vehiculului si ale soferului, de actiunile vehiculelor din jur, de

proprietatile drumului si de actiunea dispozitivelor de control al traficului. Se
realizeaza astfel o modelare precisa, pentru fiecare simulare, a interactiunilor
vehicul-vehicul, vehicul-drum si vehicul-dispozitive de control al traficului.
Odata ce pentru un vehicul au fost alocate anumite caracteristici de rulare si
ale conducatorului de vehicul, miscarea acestuia in retea este determinata de trei
algoritmi principali:
 „car-following”
 Schimbare banda de circulatie
 Acceptare goluri
Mai exista si alti algoritmi care influenteaza comportamentul vehiculului,
cum ar fi cele care modeleaza coloanele de vehicule, controlul semnalelo de trafic,
dar cele mentionate mai sus sunt cele mai des intalnite si sunt comune majoritatii
programelor de simulare.
Algoritmul Car Following

Determina modul in care vehiculele interactioneaza intre ele si modul in care
se distribuie acestea in cadrul unui flux de vehicule. Mai specific, determina distant
dintre vehicule. In lumea reala, soferii incearca, in general, sa mentina o distant
sigura fata de vehiculul din fata, pentru a permite un tip de reactive sigur la franari
ale acestora.
In programele de simulare, aceasta distant variaza de la vehicul la vehicul, in
functie de tipul soferului (de exemplu, soferii agresivi mentin o distanta mai mica, in
raport cu cei prudenti), tipul vehiculului si de caracteristicile celor din jur.
Algoritmul de schimbare a benzilor de circulatie

Controleaza modul in care vehiculele intra sau ies din plutonul de vehicule, si
modul in care schimba benzile de circulatie, din diverse motive (schimbari
obligatorii, depasire etc). Odata ce decide sa faca o schimbare de banda, soferul
trebuie sa gaseasca o pauza sufficient de mare in fluxul de traffic adiacent, si sa se
asigure ca nu exista diferente de viteza intre vehicule, care sa faca manevra sa fie
periculoasa (de exemplu, un vehicul mai lent sa intre in fata unui vehicul mai rapid).
Utilizatorul programului poate, de obicei, sa calibreze comportamentul
schimbarii benzilor, in functie de:

 Acceleratia sau franarea maxim permise pentru momentul schimbarii
benzii
 Media timp/distanta necesara pentru manevra
 Pauza minima acceptabila in fluxul de trafic adiacent etc.
2.2.2. EXEMPLE DE PROGAME DE SIMULARE

ARCADY
ARCADY (Assesment of Roundabout Capacity and Delay) este un software
care realizează analize privind capacitatea, lungimile cozilor, întârzierile şi riscul
producerii de accidente în sensurile giratorii. Programul poate evalua intersecţii
giratorii cu până la şapte braţe, pentru care pot fi asociate şi treceri de pietoni.
OSCADY
OSCADY este un program de optimizare a traficului bazat pe fazele de
semaforizare. Are la baza o serie de algoritmi de oprimizare care pot fi utilizaţi
pentru analiza unor intersecţii izolate sau rezultatele pot fi exportate in programul
TRANSYT pentru reţele de drumuri.
Programul prezintă avantajul de a genera automat cea mai buna secvenţa de
semaforizare pentru intersecţia analizată, utilizatorul introducând doar timpii
minimi inter-verde. Pornind de la aceste date programul generează fazele necesare
pentru maximizarea capacităţii şi/sau micşorarea întârzierilor. Se poate face şi o
evaluare a situaţiei existente, în acest caz utilizatorul introducând în program toate
datele despre semaforizare existente.
Caracteristici ale programului:
 intersecţii cu până la 20 de intrări
 optimizare pentru trei obiective: timpul ciclului, capacitatea maximă şi
întârzierea minimă
 evaluarea efectelor geometriei intersecţiei asupra traficului
 posibilitatea de a adăuga constrângeri pentru faze
 evaluarea grupurilor de benzi – programul poate analiza fluxurile de
trafic şi sugera dispunerea optimă a benzilor şi fluxurilor pe acestea

 modul de evaluare a situaţiei existente
 estimarea fluxurilor de saturaţie
 conducere pe partea stângă / conducere pe partea dreaptă
 afişare grafică a intersecţiei
 afişarea diagramei timpilor
 generarea de rapoarte
TRANSYT
TRANSYT este un program utilizat pentru determinarea şi studiul timpilor
optimi, prestabiliţi, de semaforizare pentru o reţea de drumuri pentru care se
cunoaşte fluxul mediu de vehicule.
Programul are integrat un modul pentru evaluarea unui Indice de
Performanţă (IP) şi un modul de optimizare care verifică pentru care timpi de
semaforizare indicele IP are o valoare cât mai bună. Se poate obţine prin acest
program o semaforizare care să permită accesul prioritar în intersecţie pentru
vehiculele transportului public şi a vehiculelor de urgenţă, fără a fi necesară detecţia
individuală a vehiculelor speciale. Analizele pot fi realizate atât pentru situaţiile în
care se conduce pe partea stângă a drumului cât şi pentru situaţiile în care se
conduce pe partea dreaptă.
Programul are toate funcţionalităţile regăsite şi în OSCADY, dar oferă în plus
o interfaţă vizuală mai elaborată şi posibilitatea generării mai multor diagrame-
rezultat.
Synchro (din pachetul SimTraffic)

Programul Synchro permite amplasarea schiţelor drumurilor pe hărţi
existente, datele putând fi editate direct în mod grafic (fără a fi necesare ferestre
suplimentare de introducere a parametrilor, după cum se întâmplă în alte
programe).
 integrarea hărţilor GIS şi SHP

 controlul alinierii benzilor de circulaţie la traversarea intersecţiei
 permite stabilirea parametrilor detectorilor amplasaţi în intersecţie
 amplasarea optimă a informaţiilor pe hartă.
SimTraffic
 Utilizează hărţile generate de Synchro
 Simulează cozi de vehicule, blocaje, incidente
 Gestionează intersecţii semaforizate şi nesemaforizate
 Stabileşte distanţa între vehicule în funcţie de viteză, şofer, geometria
drumului
 Generează informaţii la fiecare 0,1 sec.
 Generarea emisiilor de gaze
 Generarea de rapoarte pentru o singură intersecţie sau pentru o
întreagă zonă
Raport asupra gradului de ocupare şi densitate
AIMSUN
(Advanced Interactive Micro-Simulation for Urban and Non-Urban Networks)
 Realizează modele detaliate ale reţelelor de drumuri
 Semafoare cu timp prestabilit sau adaptive
 Ghidare în timp real
 Animaţii 3D
 Managementul traficului
 Stabilirea rutelor
 Modificarea vitezelor
 Simularea şi gestionarea incidentelor
 Controlul traficului
 Gestionarea transportului public

 Oferă flexibilitate prin posibilitatea scrierii de module suplimentare în
C++ sua Python.
VISSIM
VISSIM este un program de simulare a traficului care poate dezvolta modele
de trafic urban şi operaţii ale mijloacelor de transport public. Analizele de trafic pot
fi supuse unor constrângeri cum ar fi configurarea benzilor de circulaţie,
compunerea traficului, indicatoare de trafic, staţii ale mijloacelor de transport
public.
Principalele caracteristici ale programului sunt:
 Implementarea, evaluarea şi ajustarea unui sistem de semaforizare,
care poate fi cu timp prestabilit sau adaptat la trafic; poate fi
implementat orice sistem de control al semaforizării: SCATS, SCOOT
etc.
 Evaluarea şi optimizarea traficului în reţele complexe, cu intersecţii
corelate şi program de semaforizare adaptat la trafic
 Studii de fezabilitate şi impact asupra traficului a integrării liniilor de
metrou uşor în reţelele urbane de transport.
Pachetul VISSIM constă în două pachete principale: un simulator de trafic şi
un modul pentru controlul semafoarelor.
Pentru modelarea traficului se stabiliesc mai mulţi parametrii cum ar fi:
 acceleraţia maximă, frânarea maximă, viteza medie, distribuţia vitezei,
 distribuţia greutăţii vehiculelor,
 distribuţia puterii motoarelor vehiculelor,
 distribuţia culorii vehiculelor (pentru reprezentarea vizuală a
acestora),
 distribuţia modelelor de vehicule,
 tipul, clasa şi categoria vehiculului
 situaţia locurilor de parcare

 comportamentul soferilor (mai multe modele: fata de vehiculul
antemergator; fata de schimbarea benzilor de circulatie, la depasire;
fata de schimbarea culorilor semaforului)
Rezultatele pot fi exportate în diferite formate şi se pot salva diverse aspecte
rezultate ale procesului de simulare.
Pot fi oferite foarte multe rezultate ale analizelor efectuate. Dintre datele de
ieşire amintim: timpii de călătorie, întârzierile, lungimile cozilor de ieşire, distribuţia
timpilor de verde, informaţii despre vehicule (de exemplu acceleraţia, viteza medie
cu care a mers, numărul de opriri la semafor, emisiile de substanţe – valori
comparate cu valorile medii introduse la configurarea simulării), informaţii despre
intersecţii (cozile de vehicule care se formează, timpii de întârziere, capacitatea,
gradul de poluare etc.).
CORSIM
CORSIM este un program de simulare a traficului care poate dezvolta modele
pentru transport rutier urban, interuruba si retele combinare. Printre elementele
incluse in modelare se numara:
 Retele urbane
 Retele interurbane si treceri urban-interurban
 Semnale cu timpi prestabiliti sau adaptivi
 Intersectii nesemnalizate
 Simulare coloane de vehicule, blocaje etc.
 Tipare ale fluxurilor de trafic functie de origine-destinatie
 Animatie

TRANSYT
TRANSYT este un program utilizat pentru determinarea şi studiul timpilor
optimi, prestabiliţi, de semaforizare pentru o reţea de drumuri pentru care se
cunoaşte fluxul mediu de vehicule.
Programul are integrat un modul pentru evaluarea unui Indice de
Performanţă (IP) şi un modul de optimizare care verifică pentru care timpi de
semaforizare indicele IP are o valoare cât mai bună. Se poate obţine prin acest
program o semaforizare care să permită accesul prioritar în intersecţie pentru
vehiculele transportului public şi a vehiculelor de urgenţă, fără a fi necesară detecţia
individuală a vehiculelor speciale. Analizele pot fi realizate atât pentru situaţiile în
care se conduce pe partea stângă a drumului cât şi pentru situaţiile în care se
conduce pe partea dreaptă.
Programul are toate funcţionalităţile regăsite şi în OSCADY, dar oferă în plus
o interfaţă vizuală mai elaborată şi posibilitatea generării mai multor diagrame-
rezultat.
TRANSYT

TRANSYT is a software suite containing a macroscopic traffic model, a signal optimiser,

and a simulation model for the purpose of designing, evaluating and modelling
everything from single isolated road junctions to large mixed signal-controlled and
priority control traffic networks.
Why use TRANSYT?

Signal timings at road junctions have an important effect on levels of traffic congestion,
both at the junction itself and at surrounding junctions which may be signalised or
priority-controlled. Ensuring traffic signals are timed effectively is one of the most cost-
effective methods for reducing congestion.
Based on decades of research and development, TRANSYT is a now a comprehensive
global product used for optimising traffic signals at single junctions and large traffic
networks of mixed control. It is designed specifically to give quick solutions with
minimal user input, and also more considered solutions when needed.
TRANSYT modelling can feed into many processes – Its signal plans used for fixed time
signals; cableless linking facilities; SCOOT base timings; vehicle actuation maximum
timings and also used to predict the performance of the aforementioned.
Furthermore, through the addition of a simulation model, TRANSYT’s capability is
extended to include the modelling of non-cyclic signalling scenarios.
Who uses TRANSYT?
TRANSYT is used across the globe by traffic engineers, traffic modellers, junction
designers, students and tutors, working for local authorities; municipal, state and
regional authorities; consultancies of all sizes from multi-nationals to the smallest
businesses; universities; other educational establishments.
What can TRANSYT model?

TRANSYT can model mixed networks of signalised and unsignalised
junctions. Furthermore, when used in conjunction with a Junctions licence, it has the
capability to predict the performance of priority junctions using standard ARCADY
PICADY geometric data.

How TRANSYT works?
The core traffic model calculates a baseline Performance Index (an economic cost
based on stops and delays) using manually entered traffic flows. TRANSYT then runs
an optimisation process that adjusts the signal timings with the ultimate aim of reducing
the Performance Index (PI) to a minimum. The TRANSYT optimisers are therefore
seeking to produce multi-directional ‘green waves’ – a task that is impractical to attempt
manually due to the complexity of trying to satisfy multiple objectives from different parts
of the network. Green waves on key routes can be easily favoured by applying
constraints on the optimiser in the form of weightings and penalties.
A number of optimisers are provided and offer a choice between fast and highly-efficient
modelling and slower modelling options which are able to provide better optimised
timings. The optimisation process can be influenced by the application of a variety of
weighting factors and limit penalties, which allows you to ensure the results match your
exact criteria.
The simulation model provides a mechanism to evaluate the performance of a
TRANSYT network for a given set of signal timings, for a wider variety of scenarios,
including intermittent stages (i.e. non cyclic behaviour), blocking back, uneven lane
usage, complex signalled approaches and controller streams on different cycle
times. This is achieved by modelling the random arrival patterns of individual vehicles
over a series of trials, with results collated from the output of all the trials.

Key modelling features
 Evaluate performance of existing layouts and signal timings and investigate future
scenarios
 Producing timings to prioritise specific traffic types, such as buses or trams.
 Model multiple scenarios of peak traffic flows and associated signal strategies within
one file
 Model signalised, partially signalised and priority roundabouts within one file
 Extensive control of flow allocation process
 User Equilibrium Assignment of flows
 Stage-based and phase-based optimisation
 Choice of optimisers to establish multi-directional ‘green waves’
 Comprehensive set of options to control the optimisation process in order to maximise
the performance of corridors
 Simulation model for evaluating the performance of a wider variety of scenarios for a
given set of timings, such as:
 demand-dependant scenarios, such as intermittent stages
 explicit modelling of blocking back issues
 explicit modelling of complex signalled approaches
 uneven lane usage
 controller streams running on different cycles
 Modelling of short bays
 Model repeated greens or multi-cycled streams
 Modelling of time-varying flow conditions
 Unique London-based walk-on-red pedestrian behaviour model
 Cycle time optimisation

Key user interface features
 Interactive diagram / synced data entry screens
 Fast data-entry, including various auto-calculated data items derived from scaled
diagram
 graphical lane-flow overlays for ensuring optimum junction layout and lane designation
 Combined flow/queue animation of vehicular traffic and signalised pedestrian crossings.
 Library files provided to ensure a quick junction setup and to illustrate modelling
opportunities
 Auto-calculation of conflicts and inter-greens
 Auto-calculation of RR67 saturation flows
 Customisable performance analysis graphs
 Network animations shown for the complete modelled time period (Simulation Mode)
 Animation showing the estimated positioning of individual vehicles (Simulation Mode)
 3D visualisation of your network, with savable fly-through of the network
 Automated audit-trail facility
 Bath run facility
 Dynamically link to Excel spreadsheet traffic flow data
 One-click production of publication-ready reports
 Report export to PDF or Word format
 PDF user guide that will guide you through all aspects of the software
 Runs on the latest Windows platforms

Import capabilities
 Files originating from previous versions (TRANSYT 10 onwards), can be imported and
re-analysed
 Import TRANSYT 7 SET and TRANSYT 7F files
 Import TRANED 2 files for more advanced modelling
 SCOOT traffic flow messages can be imported into TRANSYT 14 (and above) to utilise
live and up-to-date traffic flows
 Import SCATS traffic flow data (including from SCATS ‘dump file’ format) to optimise
offsets and signal timings
 Dynamically link to Excel spreadsheet traffic flow data
 The transfer of data from Junctions 9 to TRANSYT is provided via an “Export to
TRANSYT” option within Junctions 9
 controlul alinierii benzilor de circulaţie la traversarea intersecţiei
 permite stabilirea parametrilor detectorilor amplasaţi în intersecţie
 amplasarea optimă a informaţiilor pe hartă.
AIMSUN
(Advanced Interactive Micro-Simulation for Urban and Non-Urban Networks)
 Realizează modele detaliate ale reţelelor de drumuri
 Semafoare cu timp prestabilit sau adaptive
 Ghidare în timp real
 Animaţii 3D
 Managementul traficului
 Stabilirea rutelor
 Modificarea vitezelor
 Simularea şi gestionarea incidentelor
 Controlul traficului
 Gestionarea transportului public

Aimsun Next
Modeling Guidelines
June 2018
Nevada Department of Transportation
1263 S. Stewart Street
Carson City, Nevada 89712
775-888-7000
www.nevadadot.com
Last updated: June 2018 NDOT Aimsun Next Guidelines Page 1 of 55

Disclaimer
This document provides guidance for developing and reviewing Aimsun Next models in
Nevada. These guidelines are only considered as a general framework for model development,
calibration and validation with a focus on the methodology. The parameters suggested in
these guidelines are to be considered as a starting point and the values can be further
adjusted to fit specific site circumstances if justified. It is the responsibility of the modeler to
ensure that the models they develop are fit for their intended purpose. The application of
these guidelines does not guarantee the resulting Aimsun Next model will be fit for the
project purpose.
Aimsun Inc accepts no liability or responsibility for any errors or omissions or for any damage
or loss arising from the application of the information provided.

1 INTRODUCTION 5
1.1 PURPOSE OF GUIDELINES 5

1.2 SCOPE OF GUIDELINES 5
2 AIMSUN NEXT BACKGROUND 7
2.1 WHY AIMSUN NEXT 7

2.2 AIMSUN NEXT MODELING PROCESS 8
3 MULTI-RESOLUTION MODELING WITH AIMSUN NEXT 11
3.1 MACROSCOPIC MODELING 12

3.1.1 STATIC ASSIGNMENT INPUTS 14
3.1.2 STATIC ASSIGNMENT OUTPUTS 14
3.1.3 DEMAND ADJUSTMENT 15
3.1.4 OPTIMIZATION OF DETECTOR LOCATION 15
3.1.5 SUBNETWORKS AND TRAVERSALS 16
3.2 MICROSCOPIC MODELING 16
3.2.1 MICROSCOPIC MODEL INPUTS 17
3.2.2 MICROSCOPIC MODEL OUTPUTS 17
3.3 MESOSCOPIC MODELING 18
3.3.1 NETWORK REPRESENTATION 20
3.3.2 BEHAVIORAL MODELS 20
3.3.3 DYNAMIC TRAFFIC ASSIGNMENT 21
3.3.4 MESOSCOPIC MODEL INPUTS 22
3.3.5 MESOSCOPIC MODEL OUTPUTS 22
3.4 HYBRID MODELING 22
4 MASTER NETWORK 27
4.1 BASE NETWORK 29

4.2 DEMAND 30
4.3 ATTRIBUTES AND ATTRIBUTE OVERRIDES 30
4.4 GEOMETRY CONFIGURATIONS 31
4.5 MASTER CONTROL PLANS 32
4.6 PUBLIC TRANSPORT (TRANSIT) PLANS 32
4.7 MODELED AREA AND SUB-AREAS 33
4.8 MASTER NETWORK CALIBRATION AND VALIDATION 35
5 MANAGING CONCURRENT MODELING TASKS 37
5.1 INTRODUCTION TO AIMSUN NEXT REVISIONS 37

5.2 PREPARING THE NETWORK 39
5.3 CREATING A REVISION 39
5.4 EDITING REVISIONS 41
5.5 MERGING REVISIONS BACK TO MASTER NETWORK 41
5.6 ADDITIONAL REVISION NOTES 42
6 MANAGING SCENARIOS 43
6.1 STATIC SCENARIOS 44

6.1.1 STATIC SCENARIO PARAMETERS 45
6.1.2 STATIC SCENARIO OUTPUTS 46
6.2 DYNAMIC SCENARIOS 46
6.2.1 DYNAMIC SCENARIO PARAMETERS 46
6.2.2 DYNAMIC SCENARIO OUTPUTS 47
6.3 APPLYING SCENARIO MANAGEMENT 47
7 GUIDANCE FOR SOUTHERN NEVADA MASTER NETWORK 51
7.1 NDOT LINK BETWEEN AIMSUN NEXT MASTER NETWORK AND REGIONAL PLANNING MODEL 51
7.2 MANAGEMENT OF MASTER AND PROJECT FILES 52
7.3 PROVIDING THE MASTER NETWORK TO CONSULTANTS 53
7.4 NAMING CONVENTION 54
8 ADDITIONAL GUIDANCE 55
8.1 SOFTWARE MANAGEMENT 55

8.2 CONTINUATION OF GUIDELINES 55

1 Introduction
1.1 Purpose of Guidelines
The Nevada Department of Transportation (NDOT) developed the Aimsun Next Modeling
Guidelines (the Guidelines) to provide consistency across projects when using Aimsun Next.
While these Guidelines were developed in conjunction with the Southern Nevada
Transportation Study (SNTS), the information contained within the Guidelines can be applied
to other areas and regions as well.
The Guidelines should be used by both model developers and model reviewers completing
modeling projects in this region. These Guidelines should allow both users and decision
makers to follow a consistent process, allowing NDOT to efficiently manage projects and
integrate projects into the appropriate regional context, specifically meeting the following
objectives defined by NDOT for the Southern Nevada Region:
• Serve as a guide for the development of Aimsun Next models;

• Provide guidance for NDOT when reviewing Aimsun Next models; and
• Provide recommended techniques for managing projects to fit into NDOT’s overall
vision for regional modeling and evaluation of projects into the concept of Aimsun
Next master files for larger regional areas.
To support these objectives, the Guidelines provide basic information on Aimsun Next key
features and their applications to models. These Guidelines can be supplemented with
information from the Aimsun Next software user manual and Aimsun Next training material. It
is recommended that any user unfamiliar with the Aimsun Next software also seek out
training and technical support, as needed.
1.2 Scope of Guidelines
The Guidelines will address the following:
• Developing and maintaining a master network;

• Managing sub models and versions;
• Passing Aimsun model versions from the master network to consultants for project
work;
• General calibration and validation for various model levels (macro, meso, micro); and
• Integration with the current strategic model.

These Guidelines will not provide specific calibration or validation parameters as these should
be defined and developed for each project based on the project needs and data availability.
The Guidelines will also not address feedback from models developed outside of Aimsun Next.
In addition, these Guidelines will provide guidance on approach and management of models
for NDOT. Specific how-to and step-by-step software use guidance can be found in the Aimsun
Next User’s Manual and the Tutorials provided with the software.
In addition, these Guidelines should be periodically reviewed and updated to remain relevant
and applicable in a dynamic environment. This version of the Guidelines relates to features
available in Aimsun Next Version 8.2 and the objectives identified above. For simplicity, the
software will be referred to in this document as Aimsun Next.

2 Aimsun Next Background
2.1 Why Aimsun Next
NDOT oversees statewide transportation facilities, including the maintenance, improvements,

and expansion of these facilities. To determine the best investment of statewide
transportation investments, NDOT utilizes transportation analysis methods and techniques
through a variety of transportation analysis software. As the systems themselves become
more congested, the improvement alternatives and associated analyses also become more
complex. Not only are individual facilities more difficult to analyze but the regional impact of
any network changes is more critical, leading NDOT to evaluate each facility not only on its
own but in a larger regional context. In addition, many improvements may happen
concurrently or need to be scheduled based on short-term impacts (such as construction
impacts) and long-term impacts.
Based on this, NDOT sought to find a software platform that would allow the agency to
manage projects in a more efficient manner and in a way that would allow them to evaluate
multiple changes and/or combinations of changes concurrently. Aimsun Next was chosen as
this platform for the Southern Nevada Region based on some of the unique features that help
NDOT meet their overall objectives, including:
• overall modeling process that supports the modeling workflow from network building
to analysis;
• multi-resolution and hybrid modeling for evaluating regional and localized impacts of
network changes and traffic conditions without requiring sub-area cuts and multiple
project files;
• single integrated platform for data consistency and efficiency for in-house staff
knowledge transfer;
• revisions for managing multiple concurrent projects with different project teams;
• Scenario Management for evaluation and comparison of alternatives; and
• simulation speed that allows for large-scale modeling support and future live / real-
time traffic predictions.
The following sections describe the modeling process and the single-platform multi-resolution
modeling in Aimsun Next to give the user a foundation for the application of other features
and techniques described later in the Guidelines.

2.2 Aimsun Next Modeling Process
Aimsun Next is unique in that it is a fully integrated, single-platform, multi-level modeling

platform that incorporates macroscopic, mesoscopic, and microscopic modeling into a single
software package, as shown in Figure 1. This means that there is only a single network file
and network data entry is only required one time as all objects and attributes are directly
accessible for each level of modeling, meaning that changes to the network only need to
happen once as all levels of modeling will utilize the same information.
Figure 1 Aimsun Next Multi-resolution Modeling.
Regardless of the level of modeling and platform used, most modeling projects will follow the
same general process:
1. Define Project Scope, including objectives, study area, analysis, scenarios, and
alternatives.
2. Define calibration, validation, and analysis methodologies, including measures of
effectiveness and thresholds.
3. Define Data Needs.
4. Create Base Model.
5. Calibrate and Validate Base Model.
6. Create and Evaluate Scenarios.
7. Provide analysis and final recommendations.
Steps 1-3 occur outside of any modeling platform. Steps 4-7 can be applied to specific
platforms and are applied in Aimsun Next as follows:

4. [Create Base Model] – Develop Master Network;
5. [Calibrate and Validate Base Model] – Refine the network as necessary for the relevant
modeling level (macro, meso, or micro) and calibrate and validate this base model;
6. [Create and Evaluate Scenarios] – using the Scenarios and scenario manager in Aimsun
Next, develop scenarios for each horizon year, time period, and other variations; and
7. [Provide Analysis and Final Recommendations] – analysis can be summarized in Aimsun
Next and stored for future references.
Focusing on the modeling process itself within Aimsun Next, modelers will follow these
general steps:
1. Create New Project.

2. Import Data.
3. Edit Network / Refine Network, including:
a. Geometry (Model, Geographic Information System),
b. Transit Lines / Schedules (General Transit Feed Specification),
c. Demand (Counts, OD Matrices), and
d. Traffic Control (Signal Timing Imports).
4. Edit Vehicle & User Types to Segment Traffic Demand (Cars, Trucks, Pedestrians,
etc.).
5. Run Model to Obtain Outputs.
Aimsun also provides management tools to manage this process across multiple scenarios,
using the Aimsun Architecture in Figure 2 below.

Figure 2 General Architecture for Aimsun Next Modeling Projects
The various components will be described in detail in later sections.

3 Multi-Resolution Modeling with Aimsun Next
As stated above, Aimsun Next is a single integrated platform for macroscopic, mesoscopic,
and microscopic modeling. This integrated nature is natively designed to minimize sources of
inconsistencies across the modeling levels, which is critical for any multi-resolution modeling
study.
It is a unique approach in that a single network file or Master Network can be maintained and
all subarea modeling can be managed within the same file, rather than the legacy approach
of maintaining a macroscopic model and “cutting” subareas to form new networks for
mesoscopic or microscopic modeling, as demonstrated in Figure 3.
Figure 3 Aimsun Next traffic Modeling Software True Integration
Within this integrated platform, data across all levels of modeling are contained in a single
network file and applied to the appropriate and relevant modeling level. For example, the
influence of control plans and traffic signs (Stop or Yield) is an important aspect that the
modeler must maintain: the meso and micro levels explicitly consider the effect on driver
behavior while the macro is sensitive to cost functions. Therefore, at the meso and micro
levels, the modeler will input real signal timings and traffic control for the entire area being
modeled at the meso, micro, or hybrid levels. At the macro level, the modeler will, at
minimum, ensure that the Turn Penalty Functions (TPFs) appropriately reflect the effect of
intersection control on delay. If desired, control plans can be used at the macro level as well,
which will result in better macro paths to then feed into the first dynamic simulations.
Version 8.2 now allows seamless integration of control plans and traffic signs in the TPFs.
The following sections provide additional background on the various modeling levels within
the Aimsun Next platform.

3.1 Macroscopic Modeling
The Aimsun Next solution for Transportation Planning and Demand Analysis has been designed
and implemented to support the analyst in the application of the main stages of the Four Step
Transportation Planning Methodology:
1. Trip Generation,
2. Trip Distribution,
3. Mode Split, and
4. Assignment (Private Vehicle Assignment and Transit Assignment).
The main functions for this in Aimsun Next are
1. Static Traffic Assignment (Single-User and Multi-User);

2. Demand Analysis (including Matrix import and export, Matrix manipulation, Matrix
Balancing, Detector Location Analysis and Demand Adjustment); and
3. Static Traversal Generation.
Aimsun Next utilizes the general process to prepare and adjust the demand, which includes
these tasks:
• Static assignment (Simple or multi-user assignment) is managed by the Macro

Assignment Experiment, which is located inside a Macro Assignment Scenario.
• OD demand adjustment is managed by the Macro Adjustment Experiment, which is
located inside a Macro Adjustment Scenario.
• Traversal demand generation is accessed, once a macro assignment experiment has
been executed and a subnetwork has been defined.
• Optimal location of detectors. The Detector Location analysis tool is located in the
Infrastructure folder in the Project Window.
• The Matrix Balancing feature is accessible via the OD Matrix Editor as one of the
operations that can be applied to a matrix.

Demand Modeling and Demand Forecasting are supported in Aimsun Next with the completion
of the Four-step Model. A Four-step Model Scenario and Experiment collects all the steps and
data interactions in the process in a work-flow diagram Figure 4.
Figure 4 Four Step Experiment
The Aimsun Next travel demand model incorporates objects such as
• Transportation Modes, • Public Transport Sections and

• Time Periods, Stations,
• Vectors, • Distribution + Modal Split,
• Areas, • Public Transport functions, and
• Generation/Attraction and • Others.
Distribution Data Sets,
Static assignment is used to calculate flows in the network, generate static routes and
produce a traffic state.

3.1.1 Static Assignment Inputs
The inputs for static assignment will generally include the following:
• a network (each section/turn should have a correctly defined cost function),

• traffic demand (with OD matrices),
• public transport plan (optional),
• master control plan (optional),
• a real data set with detection data for validation (optional); and
• parameters.
Users have a choice of several Static Assignments Methods for private transportation,
including
• All-or-Nothing,
• Incremental,
• Method of Successive Averages (MSA),
• Equilibrium Assignment (Frank&Wolfe algorithm), and
• Stochastic.
In addition, modelers have three elements in Aimsun Next for calculating path costs for
assignment:
• VDFs (Volume Delay Functions) are related to the sections and connections. They
determine the cost according to parameters such as traffic volume, capacity, speed,
width, etc.
• TPFs (Turn Penalty Functions) are related to the turns. They give a cost according to
attributes such as volume, speed, the turn geometry, the green time proportion, etc.
• JDFs (Junction Delay Functions) are specified at the turns. They show the cost due to
the conflicts of a turn with the rest of the turns in an intersection.
The Default Macro functions in Aimsun give the cost in minutes. In addition, different costs
can be considered for different vehicle types and/or purposes.
3.1.2 Static Assignment Outputs
Upon completion of the traffic assignment, the modeler will be able to obtain outputs such as
• traffic flows,

• densities,
• flow bundles, and
• isochrones.
The output can be summarized by
• totals: Volume [PCUs] and cost [VDF units] for sections and turns, occupation by
section, function components; and/or
• vehicle type: Volume [vehicles] and cost [VDF units] for sections and turns,
occupations by section, percentages of turn by turn, function components.
3.1.3 Demand Adjustment
Demand adjustment is used to refine prior matrices and produce time profile matrices from a
single matrix. This requires the following inputs:
• calibrated macro network (valid cost functions),

• demand with the initial OD matrices,
• public transport (optional),
• master control plan(optional),
• real data set for sections or detectors and/or turn or flow counts, and
• other parameters.
3.1.4 Optimization of Detector Location
Optimization of detector location is used to
• evaluate if available detection data for matrix adjustment covers enough demand; and
• report on optimal positions for installing new detectors and broadening coverage of
the demand.
The input requirements to utilize optimization of detector location are
• calibrated macro experiment,

• set of detectors, and
• definition of parameters.

3.1.5 Subnetworks and Traversals
Traversal calculation is used to evaluate a subnetwork (network and demand) for later
dynamic simulation. It simply requires:
• a calibrated macro experiment,

• a polygon that demarcates the subarea or a list of sections, and
• definition of parameters.
The macro assignment process generates a dataset and path file that will be used to run the
traversals. These supporting files must be in place. If the network is updated or changed, the
assignment must be re-run to generate new database and path files to use for new traversals.
3.2 Microscopic Modeling
The microsimulation approach means that the behavior of each vehicle in the network is
continuously modeled throughout the simulation time period while it travels through the
traffic network, according to several vehicle behavior models (e.g., car following, lane
changing). The Microscopic simulator in Aimsun Next is a combined discrete/continuous
simulator. This means that there are some elements of the system (vehicles, detectors)
whose states change continuously over simulated time, which is split into short fixed time
intervals called simulation cycles or steps. There are other elements (traffic signals, entrance
points) whose states change discretely at specific points in simulation time. The system
provides highly detailed modeling of the traffic network, it distinguishes between different
types of vehicles and drivers, it enables a wide range of network geometries to be dealt with,
and it can also model incidents, conflicting maneuvers, etc. Most traffic equipment present in
a real traffic network is also modeled in the Microsimulator: traffic lights, traffic detectors,
Variable Message Signs, ramp metering devices, etc.
The main components of a traffic microsimulation model are as follows:
• Road network:
o geometric representation of the road traffic network:
▪ road sections,
▪ intersections, and
▪ turning movements; and
o traffic management schemes:
▪ vehicle speeds,
▪ turning movements allowed,
▪ traffic signal control schemes (phasing, timings, offsets), and

▪ associated roadside detectors, traffic signals and variable message
signs.
• Traffic demand:
o input flow patterns at input sections to the road model and turn percentages at
intersections,
o time-sliced OD matrices for each vehicle class, and
o dynamic traffic assignment models which control route choice.
• Individual vehicle behavioral models:

o car-following,
o lane-changing, and
o gap acceptance.
3.2.1 Microscopic Model Inputs
To utilize microscopic simulation, at minimum, the following must be defined:
• Network: Detailed geometrical representation of roads, intersections and traffic

devices;
• Demand: Time dependent OD Matrices or Traffic States. Pedestrians;
• Control: Detailed description of the intersections (traffic lights, give-ways, stops, ...).
Transit priority, actuated control. Emulators for adaptive control;
• Public Transport Plan (optional); and
• Associated parameters.
3.2.2 Microscopic Model Outputs
As stated above, microscopic simulation will provide outputs for individual vehicles in the
network as well as aggregation on various levels. Some examples of outputs available for
microscopic models are summarized below:
• Global and time interval outputs for

o Sections: Count, Flow, Density, Speed, Travel Time, Delay, Queue, Number of
Lane Changes, Number of Stops, Stop Time, Fuel Consumption, Pollution
Emissions, Total Distance Travelled, Total Travel Time;

o Lanes: Flow, Density, Speed, Travel Time, Delay, Queue; and
o Turns: Count, Flow, Speed, Travel Time, Delay, Queue, Total Distance
Travelled, Total Travel Time.
• Detection outputs such as
o Count, Speed, Density, Headway, Occupancy, Presence.
• Time series outputs.
• Network outputs such as
o Delay Time, Density, Flow, Number of Stops, Speed, Travel Time, Vehicles
Waiting to Enter (Network), Waiting Time in Virtual Queue, and others.
• View modes to visualize output on the network.
• Animation to review the actual simulation and movement of each vehicle.
3.3 Mesoscopic Modeling
Mesoscopic simulation is an intermediate mode of simulation between microsimulation of

individual vehicles and macro assignment of traffic flows. Mesoscopic traffic simulation can
take many different forms, some oriented closer to microsimulation, some closer to
macroscopic modeling, each traffic modeling methodology defining mesoscopic differently.
In Aimsun Next, Mesoscopic Simulation refers to a link and lane-based simulation of individual
vehicles where the level of knowledge of vehicle activity is reduced from that used in
microsimulation. In Aimsun Next mesoscopic simulation, a vehicle is considered only as it
enters and as it exits a road section and the intervening movement is not simulated. Figure 5
below summarizes the difference between the three levels of simulation and how mesoscopic
fits in.
Microsimulation (Time-based)
Mesosimulation (Event-based)

Macrosimulation (Flow-based)
Figure 5 Simulation Levels
• In microsimulation; time is incremented by Δt at every time step, every vehicle then

considers its speed and lane choice and is moved by the distance determined for that
time step.
• In mesoscopic simulation, time is moved to the next event where the event is a vehicle
entering or leaving a section or node. In Figure 5, at time t1, the vehicle enters a
section, at t2 it leaves that section at a predicted speed and in a predicted lane and at
t3, it enters the next section. Not all vehicles are updated every time, only those
vehicles that are at the head of the queue are considered, leading to a large reduction
in the computer resources required to run the simulation.
• In macroscopic simulation, there are no individual vehicles; instead vehicles are
aggregated to flows from their OD pairs, which are assigned to the network to balance
load and minimize journey time.
In Aimsun Next, the mesoscopic simulation approach is based on a discrete-event simulation,

where each node works as a queue server for all input sections. The simulation time changes
as the simulation proceeds to the points in time at which an event occurs, where an event is
defined as an instantaneous occurrence that may change the state of the system, in this case
the state of the traffic network. There are different types of events:
• vehicle generation (Vehicle Entrance),

• vehicle system entrance (Virtual Queue),
• vehicle node movement (Vehicle Dynamics),
• change in traffic control state (Control),

• statistics (Outputs), and
• matrix changed (Traffic Demand).
All events in Aimsun Next have a time and a priority. Both are used to sort the events on the
event list. For example, events related to a change a traffic light or a new vehicle arrival will
be treated before events related to statistics or vehicle node movements.
In the mesoscopic approach, the vehicle is modeled as an individual entity, exactly as in the
Microscopic approach but the behavioral models (e.g., car following, lane changing, etc.) are
simplified with a slight loss of realism in order to be simulation event oriented. The following
subsections provide additional detail for mesoscopic modeling and its components.
3.3.1 Network Representation
The Aimsun Next mesoscopic model uses a node/section representation of the network based
on a directed graph. Basically, there are four geometric elements in the mesoscopic network
representation.
1. Nodes: in the mesoscopic representation they are treated as node servers, where
vehicles are transferred from a section to a turning and then to their next section.
2. Turns: the connections that vehicles use in their path. These turns connect some/all
lanes from the origin section to some/all lanes of the destination section. The turning
speed as well as the turning length is used to calculate the turning travel time. All
vehicles are assumed to travel without any restriction, namely at a free flow speed in
turns.
3. Sections: the connectors between nodes. Each section has information about its
geometry: number of lanes, speed limits and jam density.
4. Centroids: the source and sink of vehicles. They are used to generate vehicles.
3.3.2 Behavioral models
The mesoscopic level in Aimsun Next uses a vehicle-based representation of the traffic flow
and include behavior models for:
• sections: car-following and lane-changing, and

• nodes (node model): gap-acceptance and lane selection mode.
The car-following model implemented in the mesoscopic model relies on a simplified version
of the Gipps car-following model used for the microscopic level. In the mesoscopic model,

car-following and lane-changing models are applied to calculate the section travel time. This
is the earliest time a vehicle can reach the end of the section, considering the current status
of the section (that is, the number of vehicles in the section).
The gap-acceptance model used in the mesoscopic approach is a simplification of the gap-
acceptance model used in the microscopic simulator. The model considers the travel time
from both vehicles to the collision point; then it determines how long the vehicles need to
clear the node/intersection and, finally, it produces the decision.
3.3.3 Dynamic Traffic Assignment
For Dynamic Traffic Assignment, the traffic demand is defined in terms of OD matrices, each
one giving the number of trips from every origin centroid to every destination centroid, for a
time slice and for a vehicle type. When a vehicle is generated at its origin, it is assigned to
one of the available paths, connecting this origin to the vehicle’s destination. These paths are
computed as the simulation starts and re-computed at the route choice cycle time interval.
The vehicle will travel along this path to its destination unless it is allowed to dynamically
change it en-route (i.e. it is a guided vehicle) and a better route exists from its current
position to its destination.
General simulation-based approaches explicit or implicitly split the process in two

components: a route choice mechanism determining how the time dependent path flow rates
are assigned onto the available paths at each time step and a method to determine how these
flows propagate in the network.
In Aimsun Next, the mesoscopic simulation approach is based on a discrete-event simulation,

where each node works as a queue server for all input sections. The simulation time changes
at different points in time. These points in time are the ones at which an event occurs, where
an event is defined as an instantaneous occurrence that may change the state of the system,
in this case the state of the traffic network. There are different types of events:
• vehicle generation (Vehicle Entrance),

• vehicle system entrance (Virtual Queue),
• vehicle node movement, (Vehicle dynamics),
• change in traffic light (Control),
• statistics (Outputs), and
• matrix changes (Traffic Demand).
All events in Aimsun Next have a time and a priority. Both are used to sort the event list. For
example, events related to a change at a traffic light or a new vehicle arrival are going to be
treated before events related to statistics or vehicle node movements.

3.3.4 Mesoscopic Model Inputs
The mesoscopic model requires more detail than the macroscopic model and can be
summarized as follows.
• Network: Detailed geometrical representation of roads and intersections. Only

exceptions compared to micro are the solid lines in sections and stop lines in turns.
• Demand: Time dependent OD Matrices or Traffic States.
• Control: Detailed description of the intersections (traffic lights, give-ways, stops, ...)
Actuated with some restrictions.
• Public Transport Plan: Route and schedule information for public transport (optional).
3.3.5 Mesoscopic Model Outputs
As stated above, mesoscopic modeling in Aimsun Next tracks the individual vehicles under
simplified behavior conditions. The analysis then focuses on aggregated outputs such as those
below.
• Global and time interval outputs

o Sections: Count, Flow, Density, Speed, Travel Time, Delay, Queue, Number of
Lane Changes, Total Distance Travelled, Total Travel Time;
o Lanes: Flow, Density, Speed, Travel Time, Delay, Queue; and
o Turns: Count, Flow, Speed, Travel Time, Delay, Queue, Total Distance
Travelled, Total Travel Time.
• Time series outputs.
• Network summaries.
• View modes to visualize output on the network.
• Batch simulation only.
• Animation with view modes and statistical outputs
3.4 Hybrid Modeling
Traffic modeling is often used to model large complex systems that require different
simulation approaches in different areas. The wider area can be modeled with simplified
vehicle dynamics while small sub areas require more detailed simulation.

A hybrid simulation concurrently applies the microscopic model in selected areas and the
mesoscopic in the remainder of the network. The hybrid model is recommended for large-
scale networks with specific areas that require a microscopic level of detail but with a global
network evaluation.
Using the hybrid model is beneficial for networks where changes or strategies that require
precise knowledge of when a vehicle passes over a detector located inside a road section
(such as adaptive control, transit signal priority, or ramp metering) but may have a wider
influence in terms of rerouting on the network. Running the entire network at microscopic
level would increase the computation time, so the use of the mesoscopic model outside of the
areas where micro is strictly needed allows the user to increase the size of the model without
impacting adversely on the runtime.
One example of the need for a hybrid simulation combining a simplified mesoscopic
simulation for much of the area with a more detailed microsimulation in critical areas is
shown here where the study is focused on the congested central area, but vehicles passing
through that area may re-route and avoid it. A full analysis should include the effect of this
route choice.
In Figure 6, the central congested are is modeled with microsimulation while the rest of the
network is modeled with mesoscopic simulation. A vehicle travelling from Origin “i” to
Destination “j” is simulated mesoscopically until it arrives at the simulation mode boundary
when it is moved into a microsimulation model before resuming the rest of the trip in
mesoscopic mode. As the Aimsun Next mesoscopic model is based on individual vehicles, just
as in microsimulation, a particular vehicle-trip may be modeled in both modes and moved
between modes as required. If the vehicle enters the microsimulated area, it is simulated
microscopically, if its route choice avoids that area, then it is simulated in mesoscopic mode
for its entire journey.
The same network representation and the same flow, speed, and delay information is used in
both simulation modes shared in a common database. Route choice decisions for example are
therefore consistent between both modes of simulation.

Figure 6 Combining Meso and Micro Approaches
In the Hybrid simulation process, for a hybrid model to function, the meso model and the
micro models must exchange information about vehicles. There are three classes of
information:
• Vehicles attributes and statistics,

• Vehicle paths, and
• Network conditions at boundaries.
In Aimsun Next this information is exchanged through two general modules:
• The DTA Server, ensures the consistency of vehicle paths through the network and,
• The Hybrid Simulator, ensures consistency at the boundaries. There are two different
types of boundaries:
o Entrance points represented by centroids: Where vehicles are generated using
the specific arrival distribution defined by the user.
o Boundary nodes: In these boundary nodes, the vehicles in the upstream
sections use different dynamic network models from the downstream sections.
For instance, in the upstream section a vehicle is controlled by a mesoscopic
model while in the downstream section the vehicle is controlled by a
microscopic model.

The boundary nodes move vehicles from one model to the other model in a similar way to
that which vehicles are generated by centroids but in these cases the virtual queues
represent modeled road sections rather than the unmodeled areas outside the model
boundary.
Figure 7 below shows that, as the vehicle travels through the network and through time, it
may cross several boundary nodes between micro and meso throughout the simulation. The
same vehicle is tracked through each as it crosses and data evaluated for the appropriate
model level.
Figure 7 Hybrid Meso - Micro Approach
Both models must also be synchronized. As the mesoscopic approach uses an event-oriented
approach and the microscopic approach uses a time discrete simulation approach, a general
clock module is used to generate synchronization events for the mesoscopic model that will
update that part of the network.
Meso to Micro: To transfer vehicles from the mesoscopic to the microscopic area, the Aimsun
Next Hybrid simulator adopts the same approach that is used to decide if a vehicle can enter
the network during a microsimulation.
Micro to Meso: To transfer vehicles from the microscopic to the mesoscopic area, the Aimsun
Next Hybrid simulator uses the time at which a vehicle exits the last microscopic turn as

entrance time of the vehicle in the first mesoscopic section. A vehicle in the microscopic area
is then given a leader in the mesoscopic area so it is able to apply the normal car-following
model and maintain realistic behavior as it approaches the boundary. The hybrid simulator
therefore creates dummy vehicles whose speed and position is calculated based on a
triangular density-flow fundamental diagram.

4 Master Network
As stated previously, Aimsun Next incorporates the macro/meso/micro modeling levels in a
single platform. This allows for the management of an entire regional network in a single
model file or Master Network in Aimsun Next. The Master Network is established and from
there, relevant subareas can be managed and modified for other project purposes. The
Master Network will also contain the revisions, geometric configurations, and attribute
overrides that define alternate (usually future) networks. The Base Model is a subset of this
and the foundation upon which the alteratives are built.
Often, the Master Network will be developed for the macroscopic level. This can be fully
developed in Aimsun Next or can be converted from another platform, as in the case for
Southern Nevada where a Base Model was developed by importing the existing regional model
and then calibrated in Aimsun Next. Once this is done, the model can be refined to add
details for mesoscopic and microscopic modeling for various projects. Subareas can also be
defined without “cutting” and creating new models. Rather, the subareas are maintained
within the overall Master Network and defined on a scenario level in Aimsun Next.
Developing the Master Network in Aimsun Next follows a general procedure that can be
applied to most models and incorporate the Aimsun Next-specific elements shown in Figure 8
below.

Base Network
Demand
Attribute Overrides
Master Control Plans

Developing Master
Network Public Transport
Plans
Geometry
Configurations
Modeled Area /
Sub-areas
Calibration /
Validation
Figure 8 Developing Master Network
It should be noted that the Master Network level of detail and components will depend on the
level of modeling that is desired. Some components are required at all levels and some
components are either required at specific modeling levels or optional altogether. Figure 9
below summarizes this.
Figure 9 Master Network Component Requirements

For work with NDOT, the base network has been developed for the entire Southern Nevada
Region at a macro level. The freeway system was then enhanced for the meso/micro levels
through the Southern Nevada Transportation Study. This was and will be developed into
subareas for further study on a project level.
Each of the components of the Master Network development shown above are described in
the following sub-sections.
4.1 Base Network
There are two mandatory components of a traffic network:
• Base Network and

• Travel Demand.
The Base Network is the road traffic network and the core of the modeling project and upon
which the rest of the model is built. The network holds sections (representing links and
segments) and nodes (representing intersections and junctions). It also contains fundamental
objects, such as Vehicle Types, Trip Purposes, and User Classes that describe the vehicles in
the network.
Base networks can be developed from a variety of sources, including GIS databases, Open
Street Map files, networks developed in third-party software platforms.
Images and vector drawings may be imported into in Aimsun Next as blueprints to create the
network. The accepted formats are:
• Vector formats: CAD files in DXF, DWG and DGN formats, and GIS files in Shapefile
format.
• Raster Images, manual geolocation: JPEG, GIF, PNG, BMP.
• Raster Images, automatic geolocation: JPEG 2000, ECW, MrSID.
Typically, any file to be used as a background will be available in one of these formats or can
be converted to one of them.
The Master Network for the Southern Nevada Region was developed as part of the Southern
Nevada Traffic Study (SNTS) in 2017. The SNTS base model was created by first importing the
2017 base regional model previously developed in TransCAD into Aimsun Next and converting
the model to an Aimsun Next model, using custom scripts to support the importation of the
necessary objects from TransCAD to the Aimsun Next format. This process also used another
script to import the future 2040 network from TransCAD into Aimsun Next as Geometry
Configurations (see below for more details).

The existing TransCAD model data that was transferred includes the
• road network (including all the attributes associated with links and nodes),
• centroids and centroid connectors, and
• OD matrices.
Once the network was in Aimsun Next, it was refined to ensure accuracy and consistency for
attributes such as sections, lane configurations, turns, route types, nodes, and centroids. A
macro assignment in Aimsun Next was then developed, tested, and compared with the
TransCAD model results to ensure consistency.
4.2 Demand
The traffic demand for the base network represents the trips made by people traveling in the
network. For vehicle trips, this is represented in Aimsun Next as Origin-Destination Matrices
(OD Matrices) and Traffic States. Both of these can be used in the same network.
A Traffic Demand object is a collection of OD Matrices or Traffic States, but not a mixture of
both, which can be placed as a single object in different scenarios. A Traffic Demand object
is conveniently intended to simplify the process of managing demand states and facilitate
allocating them consistently across scenarios. It also allows some editing of the demand.
Both the Traffic States and the OD matrices are created for a single vehicle type (plus trip
purpose in the case of OD matrices, that is, for a single user class) and for a single time
interval. Several OD matrices or Traffic States will be grouped into a Traffic Demand which
thus contains traffic data for several vehicles (or several user classes) and time intervals and
are used as input for one or more Aimsun Next Scenarios.
In the SNTS model, the demand was also imported from the TransCAD regional model in the
form of OD matrices and included horizon years, time periods and vehicle classifications.
The OD matrices were based on the zone structure that was established for the TransCAD
regional model and were not changed in Aimsun Next. Maintaining this consistency in zone
structure between the regional model and the Aimsun Next model is important for future
updates and the ability to leverage demand updates from the regional model for future
evolutions of the Aimsun Next model for the Southern Nevada Region. For this version of the
model, this included 1658 zones.
4.3 Attributes and Attribute Overrides
Every object in the model has a set of attributes, some of which are assigned from the
regional model and some that are defined explicitly. These attributes can also be changed

using the Aimsun Next Attribute Overrides, allowing changes to be made without changing the
layout of the network itself.
This can be applied at a scenario level to modify parameters such as speed limits, lane
restrictions, and reaction times on sections; capacity and bus behavior at public transport
stops; turn speeds and yellow box behavior at nodes. Any attribute of any of the network
objects may be overridden but the list of objects remains the same.
For the SNTS model in Aimsun Next, all attributes from the regional TransCAD model and
refined as the Base Network. The attributes imported include:
Object Regional Model Attribute (Imported to) Aimsun Next Attribute
Section ID External ID
Section Length 2D Length
Section DIR
Section STNAME Name
Section AB_LANES, BA_LANES Number of Lanes
Section AB_SPEED, BA_SPEED Speed
Section FTYPE_NUM_ Road Type
Section ALPHA, BETA Volume Delay Function Parameters
Node ID External ID
Centroid Connection FTYPE_NUM_: External Link Centroid Connection
4.4 Geometry Configurations
Geometry Configurations contain the geometric differences between the base network and
the network to be tested in a scenario and extends what can be adjusted using Attribute
Overrides by changing the list of objects. For example, a base network may model a small
town, the project may also include a set of Geometry Configurations based on this network;
one may add a bypass to that model, others may include intersection improvements to
existing roads, one per configuration. Scenarios can then be created that model the town, the
town with different sets of intersection improvements, or the town with a bypass. In each
case, the core network remains the same, only the differences or, with multiple Geometry
Configurations, combinations of differences, are applied in each scenario.

Geometry configurations can be applied individually or in combination with other geometry
configurations, enabling testing of several network changes and combinations of those
changes.
Currently, the SNTS model utilizes geometry configurations to represent the future 2040 Base
Network. Geometry configurations will also be used to analyze potential network change
options.
4.5 Master Control Plans
Master Control Plans specify the control parameters applied to signalized intersections. A
Master Control Plan is a collection of multiple control plans for different areas of the model
and different times of day and a project may contain several Master Control Plans. A
scenario, or an experiment in a scenario, will have a Master Control Plan assigned to it to
provide the signal control options to be included in the model. Extending the example of
different Geometry Configurations above, a scenario with different options of intersection
improvements may now be tested in different experiments using a different Control Plan in
each experiment ranging from fixed time plans to Public Transport pre-emption and active
signal control plans.
For the Southern Nevada Region, a script was developed to import the traffic control plans
directly from the database maintained by the Freeway and Arterial System of Transportation
(FAST) of the Regional Transportation Commission of Southern Nevada (RTC). Any changes to
the existing traffic control plans should be checked against this database. Depending on how
significant these changes are, the traffic control plans may be updated manually or re-
imported from the using the script for the FAST database. The script can be provided based
on approval by NDOT and FAST.
For future traffic control plans, manual entry may be required. In this case, signal timings
should be obtained from the appropriate agency and built directly in Aimsun Next.
4.6 Public Transport (Transit) Plans
A Public Transport Plan (PT Plan) is required by a Scenario when public transport vehicles are
to be included in the simulation. The PT Plan is used to create a combination of routes and
the timetable chosen for each PT route. Multiple Public Transport plans may be generated in
a single Aimsun Next document and included in scenarios as required and as appropriate to
the Traffic Demand, Control Plan, and the road network configurations being tested.
A Public Transport Plan consists of a list of Timetables for the PT lines that will be included in
the plan Figure 10. A Timetable consists of a set of Time Slices, each one describing the
Public Transport Vehicle's Departure Schedule and the Dwell Times (time the vehicle remains
stopped) at each PT stop allocated to the line.

Figure 10 Public Transport Plan Editor
Each Schedule has an Initial Time and a Duration to define the interval when the Public
Transport Vehicles will be generated using that schedule. Multiple schedules allow for
programming a timetable with for example departures every 20 minutes in the off-peak
period and every 10 minutes in the peak period. The PT Vehicle Departures Schedule can be
defined in terms of Departure intervals or by a set of Fixed Departure Times. In all the cases,
the Deviation value will be used as standard deviation to sample the PT vehicles departures
from a Normal Distribution.
As many PT Plans as required can be defined. These are listed in the Project Window in the
Public Transport Plans folder inside the Public Transport main folder. To create a new public
transport plan, select the New/Public Transport Plan option either in the Project Menu, in the
Project Window Public Transport folder’s context menu or in the Project Window Public
Transport Plans folder’s context menu. Once done, the new public transport plan will be
listed in the Public Transport Plans folder in the Project Window.
During the SNTS project, public transport was not considered, however, this should be
considered in the case of future projects that may include transit.
4.7 Modeled Area and Sub-areas
Aimsun Next has two mechanisms for simulating sub-areas in a traffic network. A sub-area
may be small area where microsimulation is used in a hybrid model to model vehicle
interactions while the rest of the simulation is run with mesoscopic simulation, or a sub-area
may be cordoned out of a larger traffic network and scenarios generated to run within that
sub-area only.

With the Aimsun Next integrated platform, models can be developed for a large area and
maintained as a master network, while still allowing for more focused and detailed analysis in
smaller sub-areas. Because everything is maintained in a single network file with a single
software platform, the management of the sub-areas is unique in that no sub-area “cuts”
need to be done in order to focus on specific areas.
A hybrid sub area is created by defining a polygon, or selecting road sections and marking them
as a microsimulation area. The areas that are then to be run in microsimulation are selected
at the hybrid experiment level. More details on this are provided above in the hybrid
modeling discussion.
A cordoned sub-area is created by converting a polygon shape into a sub-area. The sub-area
must have its own Centroid Configuration and Demand Plans but can share Public Transport
Plans, Master Control Plans, Geometry Configurations and Attribute Overrides with the main
network. Scenarios generated within the sub-area are run using the traffic network within
that area only and hence run much faster than the larger model.
Traffic demand in sub-areas can be created automatically using a Static Traversal or a

Dynamic Traversal method which generates a new centroid configuration for the subarea and
a set of OD matrices calculated using either a static assignment experiment or a replication
from a dynamic simulation based on the demand in the whole model area, see Figure 11.
It should be noted that, when generating static travelersals within a subarea, the subarea
static assignment may not always match the original base network static assignment.
Figure 11 Traversal Matrices

4.8 Master Network Calibration and Validation
In traffic systems, the behavior of the actual system is usually defined in terms of the traffic
variables, flows, speeds, occupancies, queue lengths, etc., which can be measured by traffic
detectors at specific locations in the road network. To validate the traffic simulation model,
the simulator should be able to emulate the traffic detection process and produce a series of
simulated observations. A statistical comparison with the actual measurements is then used
to determine whether the desired accuracy in reproducing the system behavior is achieved.
The calibration and validation processes are illustrated in Figure 12.
Figure 12 Calibration vs. Validation
All of these components interact, and none should be taken in isolation to calibrate and
validate a network. As indicated by the red line in the Figure 12, real data must not be used
as input parameters in the model but rather used to compare with the model outputs during
the validation process.
There is also a process in building a model and there are appropriate actions taken to
calibrate it at each step. Table 1 describes the process.

Table 1 Who does Validation and Calibration?
Validation Calibration
– Should be software independent. – Software dependent

– Interest of end user (project client) – Interest of analyst (doing the project)
– Public Guidelines – Product Guidelines
Workflow Comparing with real data
Specific calibration and validation parameters and thresholds should be identified at the
beginning of each project and will be dependent on the level of modeling, project objectives,
and data availability. This is meant to provide general guidance on the calibration and
validation of models and will ensure that the model is built to incorporate the level of detail
and attributes required to obtain the calibration outputs.

5 Managing Concurrent Modeling Tasks
Aimsun Next allows multiple modeling tasks to be completed concurrently, meaning that
multiple projects or subarea modeling tasks can be completed by separate software users
from the same Master Network.
This is done through Revisions in Aimsun Next, as shown in Figure 13 below. The concept
starts with the Master Network and subareas, or project study areas, are defined within the
Master Network. These smaller model areas are then modeled as Revisions. Once the
modeling of the Revision is complete, the Revision is brought back and consolidated with the
Master Network, resulting in an updated Master Network incorporating all project work.
Figure 13 Managing Concurrent Modeling Tasks
The following sub-sections provide additional details on the management of concurrent tasks
using Revisions.
5.1 Introduction to Aimsun Next Revisions
Network Revisions allow making changes in the base network model and applying the edits
automatically to all related future scenarios. Network revisions also allow simultaneously
storing of different edits in individual future scenarios without affecting the base model and
keeping all the scenarios in the same file for easy reference, Figure 14 shows the process for
a simple revision example.

Figure 14 Simple Revision Example
A Revision is a link to a base model which only stores those elements that have been changed.
Initially, a revision is linked to an existing model and contains no objects itself. When a
modeler works on a revision, objects that are edited in the revision are marked as changed,
stored in the revision model file and are used instead of those which are unchanged and
stored in the base model file. This process is invisible to the modeler, apart from the
condition that the base model file must be available to the modeler’s computer across the
network. If the base document is not available, it will not be possible to edit the revision
until the link is modified, either by restoring the network connection or relinking to a
relocated base document.
In this example, a base model is marked with two distinct areas with a small buffer (2 nodes
per section) between them. This buffer is critical to ensure that both areas can be modified
and consolidated back to the base model. In the simple case, two revisions are created, and
two modelers edit them independently. Revision A is first consolidated into the base and at
this point the changes made in A are now visible in revision B. Revision B is then consolidated
into the base to update it with the changes from both revisions. Any changes which access
objects edited in both revisions A and B must be made in the base after both revisions have
been consolidated. If an object appears revised in multiple revisions, the modifications from

the last revision consolidated will be the modifications visible in the base. For example, in
this simple case, if a node is edited in both revisions A and B and the order of revisions is A
then B, only changes made in revision B will be visible in the base after consolidating both.
At appropriate intervals, the project manager can choose to integrate the changes from any
revision model into the base model at which point the changes from that revision will be
available in all other revisions linked to the base model. When dealing with large networks,
particularly when working on tight deadlines or complex projects, it can be useful to have
several people working on the same model at the same time, as shown in Figure 15.
The Revisions tool in Aimsun Next makes collaboration faster and means the whole team can
work in a single file, which reduces errors and duplication of effort.
Figure 15 Areas Defined and Separated by a Buffer Zone
5.2 Preparing the Network
The network should have as many areas as revisions (and modelers in the team). These areas
need to be well defined and separated by a buffer zone; this one helping to avoid changing
objects that are in another area, which is why the buffer zone should include at least two
nodes.
Each user focuses solely on their own working area and must be careful not to delete any
objects outside of their boundaries.
5.3 Creating a Revision
To create a new Revision, under Project tab, select New Revision, as shown in the Figure 16.
In the Create New Revision dialog, locate the Base Network, give the revision a name and for
each revision, set a New Initial ID. The ID of every new object created in the revision will

begin with this number. In our example, the first new object created in Revision 1 (named
“Claudia”) has ID 3,000,000, the second object has ID 3,000,001, and so on. Meanwhile, in
Revision 2 (“Carles”), the new object IDs all start with 5,000,000. As shown in Figure 17.
Figure 16 Create a New Revision, Select Project/New Revision
It is important that every Revision should have a different New Initial ID and that these
numbers should be separated enough to avoid having objects with the same ID in the different
revisions. The same goes for the object’s name: name each one (team members could be
used as shown in the Figure 17, Claudia and Carles – or just Revision 1, Revision 2 etc.) so that
all objects from all the Revision Regions will have different names.
Figure 17 Setting New Initial ID for Revisions. In this case ‘Carles’ (left) and ‘Claudia’ (right)

5.4 Editing Revisions
In each revision, new objects can be edited, deleted and created such as geometry objects
(sections, nodes, roundabouts…), reserved lanes or section objects (detectors, controllers,
stops…). Pay special attention to
• control plans,
• sub-paths,
• public transport lines,
• signal groups,
• traffic demands,
• traffic management,
• scenarios,
• sections belonging to a sub-path or a public transport line, and
• any object that may belong to another object affecting the whole network (and thus,
the other revision regions).
Looking in the Project/Revision Info window after finishing editing the revisions, one may see
all of the changes that were made in Added Objects, Changed Objects and Deleted Objects.
This window will show if there are any accidentally edited or deleted objects outside the
specific working area.
5.5 Consolidating Revisions Back to Master Network
Once all of the editing is done in each revision, the next step is to consolidate all the
revisions to the Base Model. First consolidate one Revision (“Revision 1”) to the Base Model,
and then consolidate another revision (“Revision 2”) with the updated file (Revision 1 + Base
Figure 18 Consolidate All the Revisions to the Base Model

Model), and so on. Revisions do not need to be consolidated in any particular order but must
simply one revision at a time.
Once all Revisions have been consolidated in the Base model, see Figure 18, the Master
Network will be updated with all changes made by each person working on the modeling
team. Once this is completed, assignments for the newly consolidated model will need to be
run again to ensure the assignment incorporates all consolidated changes. This tool can
dramatically reduce the time a modeling team needs to work on a network and particularly
comes into its own for large-scale, complex projects.
5.6 Additional Revision Notes
The key to efficiently editing large models with multiple modelers undertaking a variety of
tasks is to plan the workflow to make best use of the revisions capability.
Note that, it is essential that individual modelers do not edit the common template objects as
this will have an effect on all revisions during the consolidation. In general, the template
objects may be added to during this edit stage, but it would require strong justification to
adjust them from the standard defaults used by that company or client.
In the case of control plans or public transport, there may be many shared objects (i.e. public
transport routes) or a small number of complex objects (i.e. signal control plans) and the
scripting option is the best to adopt. In other cases, the shared objects may be both simple to
edit and few in number and in this case it would be easier to delay that stage until after the
revisions have been consolidated.
And finally, to summarize key points regarding revisions, please note the following:
• Ensure there are no overlapping geographic area for subnetworks. Leave a buffer zone
in between.
• An object must only be modified in one revision.
• Use filters and layers to contain modifications within assigned area.
• Do not edit the base file after revisions have been distributed.
• Pay special attention to control plans and public transport lines.

6 Managing Scenarios
Aimsun Next Revisions allow multiple people to work on simultaneous tasks and combine
those efforts back into a Master Network.
Aimsun Scenarios allow the modeling team to run various scenarios from the same Master
Network, retain the scenarios, analyze the output, and even compare scenarios within the
software interface. For most projects, scenarios will represent different analysis years, time
periods, build scenarios, and any associated data variations for each of those. An example is
shown below in Figure 19.
Figure 19 Scenario Definition Example
A scenario is the container for the input data and experiments to execute one of several
processes: microsimulations, mesoscopic simulations, hybrid simulations, static traffic and
public transport assignments, static demand and public transport adjustments, trip
generation, distribution + modal split and the generic four-step model process.
The scenarios for the microscopic, mesoscopic and hybrid simulators are Dynamic Scenarios,
while the scenario for the static traffic assignment is called Macro Assignment Scenario and
the one for the static demand adjustment is the Macro Adjustment Scenario.
A scenario is composed of several parameters. For the ones mentioned above, the main
parameters
are a traffic demand (a group of OD matrices or traffic states), and optionally, a public
transport plan, and a master control plan (a group of control plans) for micro, meso and
hybrid.

In Aimsun Next Microscopic, Mesoscopic and Hybrid simulators, each dynamic scenario can
have different dynamic experiments and each experiment can have different replications. A
replication will be the object to be simulated.
Each Macro Assignment Scenario can have different macro experiments to calculate a static
traffic assignment. The experiment will be the object to be assigned. The same happens with
Macro Adjustment Scenarios, where the experiment will be used to execute the adjustment.
The Trip Generation Scenario, the Distribution + Modal Split Scenario and Four-step Model
Scenario and corresponding Experiments are additional processes that together with the
Macro Assignment, Public Transport Assignment and respective Adjustment Scenarios and
Experiments offer the complete functionalities for the Travel Demand. In Aimsun Next there
are two types of scenarios, Static and Dynamic.
In a Static Assignment Scenario, flows are assigned to the network using a deterministic
algorithm. A Static Assignment does not use individual vehicles, it is oriented about trip
volumes and about speed and flows on road sections. It is typically used in wide area models
with time periods, used to define the demand in an OD matrix measured in hours, i.e. peak,
off-peak time periods.
A Dynamic Scenario is run using micro, meso or hybrid vehicle-based simulation. It may be run
with paths generated externally by the modeler, by another scenario (Static or a DUE) or it
may use paths based on the transit costs extant in the network as it runs.
6.1 Static Scenarios
A Static Assignment uses one of five methods to distribute traffic in the network:
1. The All or Nothing Assignment calculates a single shortest path for each OD pair in free
flow conditions (empty network) and assigns the whole OD pair demand to its shortest
path. Costs are not updated after assignment, so results will show free-flow costs.
2. The Incremental Assignment adds iterations to the process. The user will specify the
load/unload percentages for each iteration, and costs will be updated always after the
load and before the unload step. A shortest path with updated costs will be calculated
per OD pair at each step.
3. The MSA Assignment is a method based on Frank&Wolfe but simpler and faster because
it skips one calculation, the search for the optimal step lambda, substituting this value
by 1/n (being “n" the iteration number). In general, with a sufficient number of
iterations this method will behave well enough and tend towards an equilibrium
situation, though this is not assured.

4. The Equilibrium Traffic Assignment is based on Wardrop’s user optimal principle: No
user can improve his travel time by changing routes. In Aimsun Next, the Frank&Wolfe
algorithm is used to calculate the flows according to this principle. The algorithm is
based in a Shortest Paths Algorithm and an ad hoc implementation of a Linear
Approximation Algorithm. When using Junction Delay Functions, uniqueness and
convergence of solution are compromised.
5. The Stochastic Assignment calculates the k-shortest paths for each OD pair and splits
the OD pair demand among them, according to a Utility function defined by the user.
The first four are deterministic methods and they are listed in order of complexity. All five
are based on the calculation of shortest paths and path percentage usage. These calculations
use the cost of the different network elements.
6.1.1 Static Scenario Parameters
The parameters of the static scenario, which are the defaults for the experiments in this
scenario, include:
• The name and external ID of the scenario.

• The simulation time and duration. Note the date is for information and not used by the
simulation.
• The Traffic Demand: An OD based Traffic Demand. which can contain one or more OD
matrices for one or more user classes.
• A Public Transport Plan with a set of Public Transport routes and schedules. The PCU’s
corresponding to the volume represented by Public Transport vehicles along their
public transport lines will be automatically taken into account in the total volume for
all the travel time calculations.
• A Path Assignment with a set of routes derived from a prior experiment can be
selected in MSA and Frank&Wolfe Assignments, so that the Assignment calculations
start from this and not from an empty network. How these routes are used is
described in the Path Assignment Section of the OD Matrix Editor. Setting a Path
Assignment and choosing 1 iteration for the experiment would mean applying the apa
file to the demand, with no extra calculation. At least 2 iterations would be needed to
adjust the demand.

• A Validation Data Set: This is data used to compare simulation outputs with observed
data.
• A set of Geometry Configurations: These are the optional variations in the network
applied to this scenario.
6.1.2 Static Scenario Outputs
The outputs in static assignment are limited to:
• The flow and speed data on road sections and at junctions.

• Date for Groupings.
• Path assignments.
• Skim cost matrices.
These may be stored in the project database or in an external database.
6.2 Dynamic Scenarios
The minimum requirement for a Dynamic Scenario is a base transport network and a Traffic
Demand. There are options for a Path Assignment, a Public Transport Plan, a Master Control
Plan and set of Geometry Configurations to be included in the scenario and the Data
Output options, Traffic Management Actions, and Real Data Sets may also be specified for the
scenario.
6.2.1 Dynamic Scenario Parameters
The parameters of the scenario, which will be the defaults for the experiments in this
scenario are:
• The name and external ID of the scenario.

• The simulation time and duration, the date is for information and not used by the
simulation.
• The detection cycles. This is the time interval at which on street detectors update
their data and may differ from the simulation time step.
• The traffic demand:
o A Traffic Demand with either OD matrices or a set of Traffic States. This must
already exist in the Aimsun Next document for the entire model, or if this

scenario is contained within a subnet, the demand plan must also be contained
in the subnet folder for the project.
o A Public Transport Plan with a set of PT routes and schedules.
• A Path Assignment with a set of routes derived from a prior experiment. How these
routes are used is described in the Path Assignment section of the OD Matrix editor.
• A Master Control Plan which sets the signal control systems for the scenario.
• A Detection Pattern. This is a recording of the vehicle detections made by roadside
detectors from a prior simulation. It is prime role is to test adaptive control plans by
bringing in the detection data without necessarily requiring the traffic demand that
produced the data.
• A Validation Data Set: This is data used to compare simulation outputs with observed
data.
• A set of Geometry Configurations: These are the variations in the network applied to
this scenario.
6.2.2 Dynamic Scenario Outputs
The Outputs generated by the experiments in the dynamic scenario are:
• Store Locations: Where to store output data.

• Statistics: What data to collect.
• Paths: The path statistics to collect.
• Relative Gap Matrices: Relative Gap by each OD pair.
• XML Animation: Storing vehicle positions in an xml format suitable for input to Legion.
• Individual Vehicles: The vehicle trajectories are recorded in the database.
• Controllers: Creating Log files for signal controllers
6.3 Applying Scenario Management
In Aimsun Next, the ability to create scenarios and experiments with different options of
network topology, transport demand, simulation method, and sets of calibration variables
provides an efficient method of generating the multiple model variants of a single traffic
network and supporting the model management task.
Aimsun Next holds all options in one document and only brings them together as a model for
each of the variants modeled by an experiment within a scenario. Multiple scenarios may be

created in one document and as there is only one copy of each model component rather than
multiple copies spread around multiple different models, the task of ensuring all model
variants are consistent is greatly reduced. Furthermore, the method of simulation, (micro,
meso, or hybrid), or whether this is to be a macro assignment is determined by the scenario
and the model generated from the same data in the document, as discussed above.
If a scenario is used to describe the conditions of the transport network, an experiment is

then used to describe the actions the transport planners may adopt in mitigation. For
example, one scenario may be based on the premise that residential or commercial
development has been planned and the experiments in that scenario look at the effect of
options to cope with the increased demand. Another scenario in the same network may keep
the network and demand constant and contain a set of experiments which look at the effect
of signal and ITS control options on the existing congestion.
Well-planned use of scenarios and experiments has the ability to save time in the transport
modeling process and reduce the amount of error prone data transfers between modeling
systems.
A scenario is based in the method of running the model; as a macroscopic assignment model,
as a four-stage planning model, or as a micro, meso, or hybrid simulation. Once the method
of running the model is selected, the base network and demand configuration is described for
the scenario and different experiments are created which contain the options to be tested.
Aimsun Next Managing scenarios feature allows to work with several scenarios from the same
project, comparing data from two scenarios, create network attribute overrides, work with
revision networks and use different geometry configurations. For example, the difference in
the scenarios may be in the demand placed on the network, and the signal control plan.
Traffic Demand for the new scenario, is created by making a copy of the existing Traffic
Demand and renaming it. Change the Traffic Demand Factor from instance from 100% to
Figure 20 Demand Adjustment

120%, which will increase the number of trips of all the OD matrices in the Traffic Demand by
20%. Now the project has two Traffic Demand objects, the next step is to create another the
Scenario, by copying the current Scenario to the head of the Scenarios section in the Project
folder. Rename it and assign the new Traffic Demand to it. As the Scenario was copied, the
Experiment and Replication were included too. Demand adjustments between a base and
future scenario as seen in Figure 20 can be also managed.
The differences between Scenarios, Geometry Configurations, and Revisions can be

summarized as below:
• Scenarios reside inside the same model, for instance this could have an AM and PM
scenarios in the same model but multiple people will not be able to work on them at
the same time, instead revisions will allow that. Aimsun Next allows to still have AM
and PM scenarios and simultaneous edits can be made. However, both scenarios and
revisions can be used together. Scenarios are used when Public Transit, Control Plans,
or Demand change.
• In using revisions, the same model can be divided into fragments, that can be assigned
to different teams to work together in parallel at the same time, without creating
different versions of the original model. A Revision is a link to a base model which only
stores those elements that have been changed.
• Geometry Configurations contain the geometric differences between the base network
and the network to be tested in a scenario and extend what can be adjusted using
Attribute Overrides by changing the list of objects. This feature is used to compare
base and future scenarios, for instance, that involve changes in the network geometry.

This can be further described in Figure 21 below. Geometry Configurations are represented by
“GC”, Revisions are numbered “1”, “2”, and “3” and Scenarios are lettered “A”, “B”, and
“C”.
Figure 21. Scenarios, Geometry Configurations, and Revisions

7 Guidance for Southern Nevada Master Network
7.1 NDOT Link between Aimsun Next Master Network and Regional Planning
Model
The RTC completed an update of its regional TransCAD based model in 2017. This was the
version that was imported into Aimsun Next, refined, and static assignments compared to the
TransCAD assignment results to ensure consistency. The future 2040 demand and coding were
also imported and integrated into the same Aimsun Next platform, through scripts, geometry
configurations and attribute overrides.
This base model was then modified and enhanced to include additional micro or mesoscopic
details for specific subareas, as required for the completion of the SNTS. Once this study
completed, the Aimsun Next regional model would retain all of the new enhancements and be
ready to be distributed to other study teams for any additional work, either completing and
extending the micro/meso areas or refining and detailing the ones already in place.
The original strategic planning model will remain in its original format, allowing RTC to
proceed with its own agenda. Whenever that regional model is upgraded, typically on a four-
year cycle, NDOT will always have the possibility of applying these changes to its Aimsun Next
based platform, that will also have been enhanced during the same, through a method similar
to the one used to create the 2040 network. Through network comparisons, geometry
configurations and scripts, the next base and future will be able to reflect the changes, as
long as the other software platform can be imported into Aimsun Next.
Based on discussions with NDOT, as the strategic model is updated in TransCAD, the zone
structure will be updated in the Aimsun Next Master Network. Using this updated zone
structure, new origin-destination (OD) matrices will be brought into the Aimsun Next Master
Network.
Network changes that are developed through the TransCAD modeling efforts will be reflected
in the Aimsun Next Master Network. This may be done through a re-import of portions of the
network or manually, depending on the magnitude of the changes to be incorporated.
Often times, projects will result in an Aimsun Next Master Network that reflects future
updates to the network that should be incorporated at the regional strategic modeling level.
As the strategic model will continue to reside in TransCAD, no direct feedback from Aimsun
Next to TransCAD will be provided at this time. Currently, discussions with RTC resulted in
agreement that any network changes required for strategic modeling will be updated
manually using information from the Aimsun Next Master Network, as required.

7.2 Management of Master and Project Files
Building an Aimsun Next model can be a significant task as models often cover large areas
with many road sections, intersections, signals, public transport stops and lines and
annotations. A large model also requires an often-complex demand zone scheme and its
corresponding centroid configuration and connections. Building the model in a reasonable
time frame will often require input from multiple modelers and their individual contributions
must be efficiently managed and consolidated with each other.
Similarly, once a model is built and calibrated, it will typically be used for multiple sets of
option tests where designs for new road layouts, changes to signal controls, changes to the
demand in the network, or tests to evaluate traffic management strategies are carried out. In
each of these cases, a committed development will be agreed upon and this will need to be
consolidated into the base model to be included in subsequent option tests. Often, a model
will be used to undertake more than one set of tests at the same time, requiring a working
copy of the model for each set of tests but with the ability at the end to integrate the final
design into the base model.
Managing the workflow processes when more than one modeler needs access to the model as
it is being modified, or more than one assessment task is in progress using a completed model
is a complex task. This task is eased by the use of Revisions, which enable a modeling project
manager to employ multiple modelers on a single project, or to simultaneously use a single
base model on multiple projects and to efficiently manage the task of merging changes into a
core base model.
it is recommended that while work is being undertaken in revisions, then the base model is
kept unchanged until the revisions are consolidated. The objects added, changed or deleted
in a Revision may be reviewed from the Project Context Menu Revision Info as shown in the
Figure 22 Revision Context Menu & Review
Figure 22.

As a recommendation, consolidated models should be updated by modelers every week or at
least on a bi-weekly basis. In person meetings are strongly recommended to ensure enough
discussion over what has been done, what else needs to be done and what needs to be fixed
in the model, however these should be decided on a project-by-project basis and done to
enhance consistency throughout the model.
7.3 Providing the Master Network to Consultants
Once the Master Network has been established through SNTS, it will be available for
application to future projects in order to more effectively create Aimsun Next models for
NDOT. The intent is that the Master Network will be used to provide a base model for future
projects and have the project work incorporated back into the Master Network. The
architecture of Aimsun Next allows this to be done for multiple projects concurrently and still
allows NDOT to maintain a single Master Network.
Any modelers performing modeling tasks for NDOT using this Master Network are requested to
comply with these Guidelines unless some prior arrangement with the NDOT has been agreed
upon.
For practicality and efficiency, the Master Network will be divided into subareas and, on a
project basis, the study area for the project may be divided into subareas as well. This
approach allows these subareas to be edited and completed concurrently by multiple parties
rather than a single entity attempting to code and complete the entire area.
The subarea network build includes refinements to the model road hierarchy levels, section
geometry, zone connection coding, intersection coding, and inclusion of the key network
details. It excludes comprehensive signal information collaboration and analysis, Public
Transport (PT) routes, demand data and model calibration/validation.
The subarea models may then be joined to form the original model network and the model
development process can then be continued from the updated and consolidated base model
at this point, either as a whole or by creating a new set of revisions.
For the parallel subarea network build process to work, it is crucial to maintain consistency
between subarea networks; each area needs to be coded to the same level of detail in all
aspects of network coding, and correctly georeferenced.
In order to achieve consistency, the following rules should be agreed upon and followed when
building the subarea networks:
• Model Settings: The parameters set to initially develop the model.

• Network Refinement: Process for importing georeferenced aerials, and for refining and
amending the road hierarchy and section geometry.

• Zone Connections: Instructions and examples on connecting centroids.
• Intersection Coding: Intersection coding principles and instructions for different types
of intersections.
• Other Network Details: Additional operational details that need to be included as part
of the sub area network build such as bus stops, reserved lanes and time-dependent
operations.
• Attributes Overrides: Use of attributes overrides.
The starting point for the subarea network build will always be the updated and consolidated
Aimsun Next Master Network.
7.4 Naming Convention
In addition to providing files, guidance, and rules to follow when working on Aimsun Next
projects, it is also recommended to establish a naming convention for any work being done in
the Southern Nevada region using the Master Network.
A general recommendation would be use the use the first capital letters of the Agency name,
followed by the project name, model category, date and the consulting team who works in
the specific project sub model or revision, as Table 2 below shows.
Table 2 Naming Convention
Agency Project Model Type Date Task Modeler
NDOT ABC Base November27 Revision Aimsun
Example: NDOT_ABC_Base_November27_Revision_Aimsun
As the project grows, new combinations to contain more details can be created to continue to
maintain efficiency and ease of tracking the Master Network and associated projects.

8 Additional Guidance
8.1 Software Management
As stated above, these guidelines were developed for Aimsun Next Version 8.2. There is an R
number under each Aimsun Next version. Some R numbers refer to an interim-version while
others refer to an official version (the version published in the Aimsun website
https://www.aimsun.com/aimsun/download/). Users should make sure the version they use
is an official version. It is also the modelers’ responsibility to ensure the consistency of
software versions between the base models and the future year models.
As software versions are updated, NDOT should adopt the new version as their working or
official version and ensure that all projects from that point forward utilize this version of the
software. This not only ensures consistency across the projects but provides specific guidance
to consultants when completing projects using Aimsun Next.
8.2 Continuation of Guidelines
These Guidelines were developed for NDOT using the Southern Nevada region as the basis for
discussions and decisions. It is recommended that these guidelines be revisited regularly by
NDOT and Aimsun. NDOT and Aimsun should work together to update the guidelines as needed
to reflect current conditions, additional elements of modeling not included in this version,
additional details, and application to other regions within the state.

VISSIM
VISSIM este un program de simulare a traficului care poate dezvolta modele
de trafic urban şi operaţii ale mijloacelor de transport public. Analizele de trafic pot
fi supuse unor constrângeri cum ar fi configurarea benzilor de circulaţie,
compunerea traficului, indicatoare de trafic, staţii ale mijloacelor de transport
public.
Principalele caracteristici ale programului sunt:
 Implementarea, evaluarea şi ajustarea unui sistem de semaforizare,
care poate fi cu timp prestabilit sau adaptat la trafic; poate fi
implementat orice sistem de control al semaforizării: SCATS, SCOOT
etc.
 Evaluarea şi optimizarea traficului în reţele complexe, cu intersecţii
corelate şi program de semaforizare adaptat la trafic
 Studii de fezabilitate şi impact asupra traficului a integrării liniilor de
metrou uşor în reţelele urbane de transport.
Pachetul VISSIM constă în două pachete principale: un simulator de trafic şi
un modul pentru controlul semafoarelor.
Pentru modelarea traficului se stabiliesc mai mulţi parametrii cum ar fi:
 acceleraţia maximă, frânarea maximă, viteza medie, distribuţia vitezei,
 distribuţia greutăţii vehiculelor,
 distribuţia puterii motoarelor vehiculelor,
 distribuţia culorii vehiculelor (pentru reprezentarea vizuală a
acestora),
 distribuţia modelelor de vehicule,
 tipul, clasa şi categoria vehiculului
 situaţia locurilor de parcare

 comportamentul soferilor (mai multe modele: fata de vehiculul
antemergator; fata de schimbarea benzilor de circulatie, la depasire;
fata de schimbarea culorilor semaforului)
Rezultatele pot fi exportate în diferite formate şi se pot salva diverse aspecte
rezultate ale procesului de simulare.
Pot fi oferite foarte multe rezultate ale analizelor efectuate. Dintre datele de
ieşire amintim: timpii de călătorie, întârzierile, lungimile cozilor de ieşire, distribuţia
timpilor de verde, informaţii despre vehicule (de exemplu acceleraţia, viteza medie
cu care a mers, numărul de opriri la semafor, emisiile de substanţe – valori
comparate cu valorile medii introduse la configurarea simulării), informaţii despre
intersecţii (cozile de vehicule care se formează, timpii de întârziere, capacitatea,
gradul de poluare etc.).

• Go to VIEW - BACKGROUND - EDIT..., press LOAD... and select
the name of the desired graphics file in order to import it into
VISSIM
• VIEW - BACKGROUND - EDIT, select the file to be scaled and
press SCALE. The mouse pointer turns into a ruler
• Click and hold the left mouse button and drag the mouse along
the scale distance, enter the real distance of the scale line and
confirm with Ok.
• File: New
• Link: hold down right click, drag
• Edit the link data : # of Lanes, Grade, Opposite direction,…
• Create Spline: Right click on
the segment: Move and
create curves
• Select a single link

• Right-click outside of the
VISSIM network: Data
• Double click on the link
• It is not sufficient to place one link on top of another link in
order for vehicles to continue on the other link.
• A connector needs to connect the two links.
• Connectors model turning movements.
• Links extended to almost the center of the junction
• Right click at the connector´s desired start position inside a link,
drag the mouse in the direction of flow to the destination link.
• represent the mix of vehicle types
• TRAFFIC - VEHICLE COMPOSITIONS
• Relative flow: The relative percentage of this vehicle type.
• VISSIM calculates the
absolute percentages to
be used for each vehicle
type of this composition.
• Select vehicle input
• Click on link
• Select the link/connector
• Right click on the link for the routing decision point (red bar).
• Create routing decision window appears: OK.
• Select the link/connector for the route destination: Right click
• Select the Data collection points mode/ Left click on the link/
Right click on point./Click OK
• EVALUATION/FILES/Data Collection
/CONFIGURATION
• *.MER file
• Select the Stop sign/ Left click on the link/ Right click on
point./Click OK
• RTOR
• To delete:
• Select the stope line/ delete/ ok
• Select the priority rules/ Left click on the connector/ Right click
on point/left click on other link or connector/Right click on
point/Click OK
• Signal control /edit controllers/ right click/new/fixed time/ Edit
signal control/
1. + /Click on signal group/ signal group1(Add signal group
2)/ save
• Signal control /edit controllers/ right click/new/fixed time/ Edit
signal control/
2. Signal program/ + /Click on signal group/ save /ok
• Select link/ right click/ select Sc and Signal group/name it/ ok
• Select Detectors mode/ Left click on the link/ Right click on
point./Click OK
• SC (signal controller): Associates the detector to the controller
• *.LDP file
• Simulation/ parameters
• Errors? Look into Help or manual:

• Page 185 –
• http://www.et.byu.edu/~msaito/CE662MS/Labs/VISSIM_530
_e.pdf
CORSIM
CORSIM este un program de simulare a traficului care poate dezvolta modele
pentru transport rutier urban, interuruba si retele combinare. Printre elementele
incluse in modelare se numara:
 Retele urbane
 Retele interurbane si treceri urban-interurban
 Semnale cu timpi prestabiliti sau adaptivi
 Intersectii nesemnalizate
 Simulare coloane de vehicule, blocaje etc.
 Tipare ale fluxurilor de trafic functie de origine-destinatie
 Animatie

Introduction
1 Introduction
1.1 Overview
This User's Guide describes how to prepare the input, analyze the output, and execute the CORSIM simulation
and modeling program. Detailed information concerning the input records used by CORSIM can be found in
the CORSIM Record Types Reference Manual.
1.2 Simulating Traffic Systems

In traffic engineering, the concept of traffic control is giving way to the broader philosophy of Advanced
Traffic Management Systems (ATMS), whose purpose is not only to move vehicles, but also to optimize the
utilization of transportation resources to improve the movement of people and goods without impairing the
community.
One of the most important analytical tools of traffic engineering is computer simulation. Computer simulation
is more practical than a field experiment for the following reasons:
• It is less costly.
• Results are obtained quickly.
• The data generated by simulation include several measures of effectiveness that cannot be easily
obtained from field studies.
• The disruption of traffic operations, which often accompanies a field experiment, is completely
avoided.
• Many schemes require significant physical changes to the facility, which are not acceptable for
experimental purposes.
• Evaluation of the operational impact of future traffic demand must be conducted by using
simulation or an equivalent analytical tool.
• Many variables can be held constant.
If a traffic system is simulated on a computer by means of a simulation model, it is possible to predict the
effect of traffic control and ATMS strategies on the system's operational performance, as expressed in terms of
measures of effectiveness (MOEs), which include average vehicle speed, vehicle stops, delays, vehicle-hours
of travel, vehicle-miles of travel, fuel consumption, and pollutant emissions. The MOEs provide insight into
the effects of the applied strategy on the traffic stream, and they also provide the basis for optimizing that
strategy.
CORSIM User's Guide 1-1

Introduction
The availability of traffic simulation models greatly expands the opportunity for the development of new and
innovative ATMS concepts and designs. Planners and engineers are no longer restricted by the lack of a
mechanism for testing ideas prior to field demonstration. Furthermore, because these models produce
information that allows the designer to identify the weaknesses in concepts and design, they provide the basis
for identifying the optimal form of the candidate approach. Finally, because the results generated by the model
can form the basis for selecting the most effective candidate among competing concepts and designs, the
eventual field implementation will have a high probability of success.
Many ATMS strategies affect the mode and route choice of trip-makers. To test the effect of ATMS schemes
on trip patterns, it is necessary to analyze an area that contains a substantial portion of the routes that the trip-
makers may follow. There is a need, therefore, for a simulation model that is capable of representing traffic
flow in large urban areas containing surface street networks and freeways and that has reasonable computer
usage requirements. This concept of a single integrated simulation system that can provide the user with
flexibility and ease of use and that can optimize the efficiency of all computations was conceived by the
Federal Highway Administration (FHWA) in the mid-1970s. FHWA has since supported a series of projects to
implement this design and to develop the software for CORSIM.
1.3 CORSIM theory of operation

CORSIM consists of an integrated set of two microscopic simulation models that represent the entire traffic
environment. NETSIM represents traffic on urban streets and FRESIM represents traffic on freeways.
Microscopic simulation models represent movements of individual vehicles, which include the influences of
driver behavior. The effects of very detailed strategies, such as relocating bus stations or changing parking
restrictions, can be studied with such models.
In a multiple-model network, each of the component models of CORSIM simulates a different subnetwork
The interfacing of adjoining subnetworks is accomplished by defining "interface nodes" (as shown in the
following figure), which represent points at which vehicles leave one subnetwork and enter another. Nodes of
this type are assigned special numbers to distinguish them from other nodes in the network. The terms "entry
interface links," which receive traffic from the adjoining subnetworks, and "exit interface links," which carry
traffic exiting the subnetwork to adjoining subnetworks, are used to describe links at the boundaries of the
subnetworks.
The following figure illustrates a multiple-model network in which a city's central business district is bordered
by a freeway. The freeway sections can be modeled with FRESIM, while the urban subnetwork can be
modeled with NETSIM. Once the user identifies the appropriate subnetwork representation, all interfacing
processes are handled internally by the model by the interface logic.
1-2 CORSIM User's Guide

Introduction
FRESIM Subnetwork
56
560
54
510
7054
502
50
53 7061 52
7053 8013 8020 8024 55
51 20 61 7055
57
13 24
8010 8028
10 14 21 25 27 28 34 8034
3
30
2 8011 11 15 115 8015 7
699 8030 333
8 222
749
2026 2029 7033
7022
7088
121
292
122 12 16 22 26 29 7077
7099 291 7066
7011 31 7044 444
666
9 111 17 8031 4
1
NETSIM 6
23
599
70 8017 Subnetwork 5
706
708 8001 8023 8006
8008 8007
LEGEND
8023 Entry/ Exit Node (one or two links attached)
7042 Interface Node (one link attached)
2026 Source/ Sink Node (two links attached)
23 Internal Node (two or more links attached)
Multiple model network
CORSIM applies time step simulation to describe traffic operations. A time step is one second. Each vehicle is
a distinct object that is moved every second. Each variable control device (such as traffic signals) and each
event are updated every second.
CORSIM is a stochastic model, which means that random numbers are assigned to driver and vehicle
characteristics and to decision making processes. The MOEs that are obtained from a simulation are the result
of a specific set of random number seeds. For example, one set of random number seeds may result in three
very conservative drivers driving side by side on a three-lane roadway blocking more aggressive drivers behind
them. The resulting MOE would reflect a lower average speed then has been observed in the real world.
Relying on the MOE generated from a single run of CORSIM may be misleading. To gain a better
understanding of network performance the network should be simulated several times using different sets of
random number seeds. The resulting distribution of MOEs should then be an accurate representation of the
network performance.
Each vehicle is identified by fleet (auto, carpool, truck, or bus) and by type. Up to nine different types of
vehicles (with different operating and performance characteristics) can be specified, thus defining the four
vehicle fleets. Furthermore, a "driver behavioral characteristic" (passive or aggressive) is assigned to each
vehicle. Its kinematic properties (speed and acceleration) as well as its status (queued or moving) are
determined. Turn movements are assigned stochastically, as are free-flow speeds, queue discharge headways,
and other behavioral attributes. As a result, each vehicle's behavior can be simulated in a manner reflecting
real-world processes.

Introduction
Each time a vehicle is moved, its position (both lateral and longitudinal) on the link and its relationship to other
vehicles nearby are recalculated, as are its speed, acceleration, and status. Actuated signal control and
interactions between cars and buses are explicitly modeled.
Vehicles are moved according to car-following logic, in response to traffic control devices, and in response to
other demands. For example, buses must service passengers at bus stops (stations); therefore, their movements
differ from those of private vehicles. Congestion can result in queues that extend throughout the length of a
link and block the upstream intersection, thus impeding traffic flow. In addition, pedestrian traffic can delay
turning vehicles at intersections.
CORSIM accumulates data every time step. At the end of each time period the accumulated data is used to
produce MOEs. These MOEs can then be used in conjunction with the Highway Capacity Manual (HCM) to
estimate the performance of the network.
CORSIM is capable of simulating most of the prevailing freeway geometries, including multiple-lane freeway
mainlines, on/off ramps and connectors to other freeways, variations in grade, radius of curvature and super-
elevation, lane additions and lane drops and auxiliary lanes, which are used by traffic to begin or end the lane-
changing process or to enter or exit the freeway.
1.4 Elements of the Traffic Environment

The traffic environment, which must be specified by the user, consists of the following:
• Topology of the roadway system (in the form of a link-node diagram)
• Geometrics of each roadway component
• Lane channelizations (such as left-turn only and buses only lanes)
• Traffic volumes entering the roadway system
• Turn movements or origin-and-destination data
• Intersection Approach Geometry
• Stop and Yield Signs
• Pre-timed Signal Control
• Actuated Signal Control
• Freeway Ramp Metering Control
• Incidents and Temporary Events
• Traffic Surveillance Systems
• Fleet Components (buses, carpools, cars, and trucks)
• Load Factors (the number of passengers/vehicle)
• Turn Movement Distributions
• Bus Operations (paths, flow volumes, stations, dwell times, and routes)
• HOV Lanes (buses, carpools, or both)
• Queue Discharge Distribution on surface streets
• Lane Changing Parameters
• Variations in Driver Aggressiveness
• Reaction points for upcoming geometric changes on freeways
• Driver behavior that determines the operational performance of vehicles in the system

Introduction
• Fuel consumption and pollutant emission rates

The physical environment is represented as a network comprised of nodes and unidirectional links. The links
generally represent urban streets or freeway sections, and the nodes generally represent urban intersections or
points at which a geometric property changes (such as a change in grade or a major midblock traffic generator).
Another important feature of CORSIM is that characteristics that change over time, such as signal timings and
traffic volumes, can be represented by dividing the simulation into a sequence of user-specified time periods,
during which the traffic flows, the traffic controls, and the geometry are held constant. Therefore, the morning
rush hour might be simulated with one time period representing pre-rush hour, a second representing rush-hour
timing, and a third representing the post-rush-hour flows. These time periods are further divided into time
intervals.
CORSIM also includes a traffic assignment program, which is designed to expand the applicability of traffic
simulation modeling to transportation planners. The program internally translates the origin-and-destination
data - which is readily available to the planning community - into a form suitable for use by the simulation
models.
The traffic assignment model interfaces with the NETSIM component of CORSIM only and uses conventional
static traffic assignment techniques, along with user equilibrium and system optimization capabilities. The
purpose of including a traffic assignment model in CORSIM is to extend the potential user group for this
program to include planners and traffic engineers.
The planner usually has sufficient information available to produce a table of origin-and-destination volumes
that represent traffic demands over an area for a specified period of time. For this information to be useful as
input in the NETSIM model, it must first be transformed into link-specific turn percentages. The mechanism
for performing this transformation is the traffic assignment model.
The interfacing logic is designed to perform data manipulation internally, thus freeing the user to focus
attention on providing the origin-and-destination table. This logic will read and check the data and then
perform the necessary data organization to provide the traffic assignment program with its data requirements.
Subsequently, it will create turn percentages and entry volumes for input into the NETSIM model.
1.5 Calibration Parameters

There are several CORSIM inputs that are known as calibration parameters. These inputs allow users to fine
tune CORSIM to match local real-world traffic conditions. These calibration parameters include driver
behavior parameters and vehicle performance parameters. The driver behavior parameters for Netsim include
queue discharge headway and start-up lost time, distribution of freeflow speed by driver type, mean duration of
parking maneuvers, lane change parameters, maximum left and right turning speeds, probability of joining
spillback, probability of left turn jumpers and laggers, gap acceptance at stop signs, gap acceptance for left and
right turns, pedestrian delays and driver familiarity with their path. The driver behavior parameters for Fresim
include mean start-up delay at ramp meters, distribution of freeflow speed by driver type, incident
rubbernecking factor, car-following sensitivity factor, lane change gap acceptance parameters, and parameters
that affect the number of discretionary lane changes. Vehicle performance calibration parameters for both
Netsim and Fresim include speed and acceleration characteristics, fleet distribution and passenger occupancy.
Fresim also includes maximum deceleration values.
1.6 Creating a Network and Calibrating CORSIM

The following steps define the basic process for using TSIS for analyzing an existing traffic network.
1. Determine the network geometry.

Introduction
2. Obtain traffic and signal data.

3. Build a link-node model of the network using TRAFED, ITRAF or a Text Editor.
4. Run the simulation using CORSIM.
5. View the animation in TRAFVU to verify the inputs and confirm vehicle movement and signal operations.
6. Use the CORSIM tool’s multi-run capability or use the TSIS Multi-Run Same Case script to perform
multiple CORSIM simulations of the network using different random number seeds.
7. Examine the distribution of relevant MOEs and compare with field data.
8. Adjust calibration parameters as needed to match field data as closely as possible.
9. Go back to step 7 and repeat the process until CORSIM results and field data match reasonably well.
After performing these steps CORSIM should be properly calibrated for that specific network and can be used
to perform other analyses with modifications of the existing network, such as determining the impact of
geometry changes. The resulting set of calibration parameters should also be usable for other simulations in
which driver behavior and vehicle performance characteristics would be similar.
1.7 CORSIM Capabilities and Limitations

The following tables list many elements of modern traffic systems. CORSIM can model most of those
elements explicitly. Many of the other features can be approximated using the basic elements of CORSIM,
along with engineering judgement and creativity. The tables are arranged into Freeway and Surface Street
systems and show CORSIM capabilities and the types of input data that CORSIM uses to model those systems.
Freeway Modeling Capabilities
Modeling Capabilities
Bottlenecks Yes
HOV lanes, including ramp meter bypass Yes
Barriers Yes
Lane closures Yes
Interchanges Yes
Weaving sections Yes
Toll booths / weigh stations / draw bridges No*
Oversaturation Yes
Time-varying demand Yes
Trucks biased or restricted to specific lanes Yes
Incidents Yes
Workzones Yes
Surveillance Yes
Fixed-time ramp metering Yes
Time varying fixed-time ramp metering Yes
Traffic-responsive ramp metering Yes
Bus operations Yes

Introduction
* These features are not modeled explicitly by CORSIM, but can be modeled using basic CORSIM elements.
Some of them require using both surface street elements and freeway elements.
Freeway Input Data
Input Data
Node coordinates Yes
Link length Yes
Grade Yes
Number of lanes Yes
Number and type of auxiliary lanes Yes
Capacity No
Freeflow speed Yes
Turn percentages Yes
Turn percentages by vehicle type Yes
Time-varying turn percentages Yes
Traffic composition Yes
Vehicle occupancy Yes
O-D table Yes
Surveillance detectors Yes
Fixed-time metering headway Yes
Traffic-responsive metering inputs Yes
Number of vehicles per green Yes
User-defined driver characteristics Yes
Surface Street Modeling Capabilities
Bottlenecks Yes
Complex intersections Yes
HOV lanes Yes
On-street parking Yes
Two-way left turn lanes No*
Oversaturation Yes
Time-varying demand Yes
Incidents Yes
Pedestrians Yes
Workzones Yes
Unsignalized intersections Yes
All-way stops Yes
Roundabouts No*
Fixed-time signals Yes
Actuated signals Yes

Introduction
Signal coordination Yes
Surveillance Yes
U-turns No*
Transit signal priority No
Bus operations Yes
Light rail No*
* These features are not modeled explicitly by CORSIM, but can be modeled using basic CORSIM elements.
Some of them require using both surface street elements and freeway elements.
Surface Street Input Data
Input Data
Node coordinates Yes
Link length Yes
Grade Yes
Number of lanes Yes
Lane channelization Yes
Turn pockets Yes
Pedestrian traffic Yes
Freeflow speed Yes
Turn percentages Yes
Time-varying turn percentages Yes
Traffic composition Yes
Vehicle occupancy Yes
O-D table Yes
Signal timing plan Yes
Surveillance detectors Yes
Single ring actuated control Yes
Dual ring actuated control Yes
User-defined driver characteristics Yes

Input and Output Details
2 Input and Output Details
2.1 Input Data

Computer simulations use a mathematical representation of the real world. Traffic simulation models are
representations of the time-varying processes in traffic flow, and they require accurate descriptions of the
characteristics of the vehicles, the transportation network, and the traffic control system. These characteristics
vary over the physical network and over time. The structure of the input stream must also reflect the concept of
network partitioning.
The characteristics that vary over time include the following:
• Traffic volumes
• Turn movements
• Traffic regulations
• Signal timing.
The characteristics that vary over space include the following:
• Traffic geometry (location of links and nodes, number of lanes, turning pockets, and auxiliary
lanes)
• Types of links (such as surface streets or freeways)
Links are one-directional segments of surface streets or freeways, and nodes are usually the intersection of two
or more links. Initially, the user must obtain geometric pictures of the network, such as aerial photographs or
maps. A basic drawing of the geometry of a single intersection is shown in the following figure.

25th Avenue
N
Clement Street
8002
Entry
Entry or
or exit
exit node
node has
has
no
no coding
coding of
of control
control Dummy
Dummy node
node is
is
2 always
always green
green
8003 3 1 5 8005
4 Sign
Sign (yield,
(yield, stop,
stop, or
or
uncontrolled)
uncontrolled) approaches
approaches
or
or signal-controlled
signal-controlled node
node
8004
Intersection layout converted to a link-node diagram
The time-varying portion of the simulation analysis is expressed as a sequence of "time periods" specified by
the user; that is, the input data specified by the user for a certain time period remains in force unless changed in
a subsequent time period. The user can specify up to 19 time periods and must specify the conditions that have
changed during each period. Therefore, the input stream consists of a sequence of "blocks" of data records,
with each block defining the conditions that apply to one time period.
Each block of data records for a time period is subdivided into "sections" of data records. Some sections
define conditions of one or more subnetworks, including a NETSIM subnetwork and/or a FRESIM
subnetwork, while others provide inputs for the specifications that must be specified for the "global" network
(such as bus routes).
The input stream of a dataset begins with a basic description of the run being made (run control data), followed
by data that is divided into time periods. Each time period contains model-specific data for each subnetwork
that is being simulated. Each dataset is divided into a series of 80-column records. The first time period is
unique because it contains the data that does not vary from time period to time period. At the end of the model
data for the first time period is global network data that is applied to all subnetwork data. This global data
describes bus operations, and any other data that applies to both subnetworks. For second and subsequent time
periods, only variations in data relative to the previous time periods need to be specified.

Time Period Delimiter 210 – End of Dataset

Enter 1 in Column 4 to indicate final time period.
Time-Period-
Specific Data
Group
If applicable, subsequent time period data groups.
Time Period Delimiter 210 – End of Time Period 1

Global Data above 170
Subnetwork Delimiter 170 – End of NETSIM Data
NETSIM Model Data – Time Period 1
Subnetwork Delimiter 170 – End of FRESIM Data
FRESIM Model Data – Time Period 1
Run Control Data 00 to 05

Enter 8 in Column 52 on Record Type 02 to indicate that the
first model data are for FRESIM.
Record can be copied, modified, and entered Last record

Record type for subsequent time periods, if applicable of dataset
CORSIM data structure
The following tables list the record types that can be used by each model. The run control data is independent
of the model that is being executed and is required for all models. Only one set of run control data records is
permitted, even if more than one model and/or time period will be simulated.
Run control data required to set-up CORSIM simulation runs
RECORD DESCRIPTION NETSIM FRESIM

TYPE
00 Run Title Optional Optional
01 Run Identification Required Required
02 Run Control Required Required
03 Time Period Specification Required Required
04 Time Interval and Time Steps per Time Period Required Required
05 Reports Required Required
The following table indicates whether each of the remaining record types, beyond the Run Control records
identified in the previous section, is required or optional. Blank boxes indicate the specified record type is not
applicable to that subnetwork (FRESIM or NETSIM).

Appendix A
4 Appendix A
4.1 Architecture
The architecture of the CORSIM simulation running in TSIS is shown in the following figure.
RunCORSIM.EXE RTE
EventSink.dll
CORWin
Interface
CORSIM Exported CORSIM Exported

TShell CORSIM Functions DLL Memory
Driver
Server
Tool
TSD / TID
CORSIM
Property
Pages OutProc TSD / TID
Write
Out
Files
Script
XLS TxD
Files Files
4.2 Component Overview

There are many components required to run the CORSIM DLL.
TSIS.exe (TShell): Provides the framework for the architecture.

Capitolul 3. Reglementarea circulației în
intersecții
3.1. Generalități
Capacitatea de circulaţie este o măsură a abilităţii de a pune de acord un flux

de trafic în mişcare. Analiza capacităţii de circulaţie reprezintă un segment
important al aplicaţiilor planificării, care iau în calcul condiţiile de viitor şi
estimările despre fluxurile de trafic de vehicule sau pietoni.
Capacitatea de transport reflectă capacitatea unei artere rutiere de a servi
vehiculele şi oamenii, în anumite condiţii specificate. Reprezintă limita superioară
a numărului de vehicule sau pietoni care pot trece printr-un punct într-o
perioadă de timp specificată şi în anumite condiţii.
Capacitatea de vehicule reprezintă numărul maxim al vehiculelor care pot
trece, în mod fluent şi în condiţii de siguranţă, printr-un punct dat, de-a lungul
unei perioade specificate, cu timpi de aşteptare acceptabili în anumite condiţii de
trafic şi de mediu.
Capacitatea de călători introduce conceptul de ocupare al vehiculelor şi
reprezintă numărul maxim de persoane care pot trece printr-un punct dat, pe o
durată specificată de timp, în anumite condiţii de trafic şi cu aşteptări
acceptabile.
Capacitatea de tranzit reprezintă capacitatea uneia sau mai multor rute care
trec printr-un punct într-o perioadă specificată de timp.
La modul general, capacitatea de circulație depinde de următorii factori:
 caracterul circulaţiei:
-flux discontinuu (intermitent sau pulsatoriu) cu opriri în intersecţii;
-flux continuu, fără opriri la intersecţii când acestea sunt denivelate sau dirijarea
traficului se face în sistem coordonat (undă-verde).
 caracterul traficului:
-intensitatea şi frecvenţa sosirilor de vehicule;
-viteza medie de circulaţie;
-componenţa traficului pe categorii de vehicule, inclusiv caracteristicile lor
constructive şi dinamice.
 structura reţelei principale de străzi:
-elementele geometrice ale străzilor;

-distanţele dintre intersecţii şi treceri intermitente pentru pietoni, amenajarea şi
echiparea acestora.
 caracteristicile suprafeţei de rulare:
-planeitatea;
-rugozitatea.
 organizarea circulaţiei:
-reglementarea acceselor şi a staţionărilor;
-sisteme de semnalizare şi echipare tehnică.
 caracteristicile psihologice şi fiziologice ale conducătorilor de vehicule:
-timpul de percepţie-reacţie;
-timpul limită de aşteptare la intersecţii.
Fluenţa circulaţiei F (conform STAS 10144/5-89), în secţiunea curentă a străzii,
exprimă calitatea funcţională a acesteia şi este dată de relaţia:
v
F  0...1 ,
vB
unde: vB –viteza de proiectare sau de bază, km/h;
v - viteza de circulaţie, km/h.
Densitatea traficului rutier, exprimată în vehicule etalon/km, aşa cum s-a mai
amintit, se obţine prin împărţirea fluxului de trafic la viteza medie de deplasare şi
este considerată cea mai importantă măsură a nivelului serviciului, mai
importantă chiar decât fluxul de trafic. Aceasta reflectă creşterea sau
descreşterea aglomerărilor din trafic. Când se creează o aglomerare, densitatea
este maximă, iar fluxul tinde spre zero.
Practica dispune de trei tipuri de reglementări pentru organizarea şi dirijarea

traficului în intersecţiile urbane:
1. reglementarea bazată pe priorităţi şi indicatoare de prioritate;

De obicei, în acest caz există un flux principal, cu prioritate, deci şi un flux
secundar, care trebuie să se încrucişeze sau să se înfiltreze în cel principal şi
când sunt posibile puncte de conflict.
O intersecţie nesemaforizată va fi controlată cu ajutorul semnelor de circulaţie
(de exemplu stop sau semnale intermitente). Un prim obiectiv, în cazul
acestora, este determinarea capacităţii de circulaţie.

Estimarea capacităţii de-a lungul străzii secundare, ca şi virarea la stânga,
pentru traficul major către fluxul minor al unei intersecţii nesemaforizate,
constă în analizarea intervalelor în timp dintre vehicule.
2. reglementarea cu ajutorul denivelărilor;

În acţiunea de organizare a circulaţiei urbane, apar adeseori cazuri în care, o
reglementare a circulaţiei numai la nivelul solului, oricât de abil ar fi făcută, nu
poate satisface necesităţile de traversare ale traficului de vehicule ce ajunge la
intersecţii. În aceste situaţii este necesară denivelarea căilor.
În cadrul urban soluţia de denivelare totală este mai rar întâlnită, de obicei
aplicându-se soluţii mixte: se păstrează la nivelul solului toate fluxurile de
vehicule pentru care o reglementare pe baza priorităţilor sau a semaforizării
poate asigura capacităţile necesare şi se denivelează numai acele fluxuri
pentru care o reglementare de tipul celor menţionate, nu poate asigura o
capacitate corespunzătoare.
Capacitatea totală a unui nod de circulaţie, în această soluţie, se poate
compune din două capacităţi parţiale:
Qt  Qs  Qd
,
unde:
Qt – capacitatea totală a nodului;
Qs – capacitatea intersecţiei rămase la nivelul solului, în Vt/h;
Qd – capacitatea pe care o pot asigura denivelările, în Vt/h.
Dacă capacitatea intersecţiei rămase la nivelul solului Qs, poate fi calculată pe
baza formulelor corespunzătoare, capacitatea denivelărilor Qd trebuie
calculată separat, în calculul acesteia fiind necesar să se ţină seama şi de
influenţa intersecţiilor adiacente.
Formula aproximativă de calcul pentru Qd este dată de relaţia:
Qd    n  Qv
,
unde:
 - este un coeficient de micşorare a lui Qv, funcţie de poziţia intersecţiei
respective în raport cu cele învecinate;
Qv – capacitatea unei benzi de circulaţie în regim liber corespunzătoare unei
anumite viteze de deplasare v, km/h, în Vt/h;
n – numărul de benzi de circulaţie pe care le poate asigura denivelarea pentru
fluxul considerat.

3. reglementarea prin semaforizare.
Utilizarea unei instalaţii de semaforizare într-o intersecţie stradală este
justificată atunci când circulaţia normală a autovehiculelor este perturbată
prin:
blocarea repetată a circulaţiei pe căile de acces în intersecţii;
formarea repetată a şirurilor de vehicule, cu aşteptări mai mari de două
minute pe străzile secundare, densitatea fluxurilor de trafic pe strada
principală fiind prea mare pentru a permite traficului secundar o încrucişare
sau înfiltrare;
aglomerarea pietonilor şi aşteptarea prelungită, deoarece este foarte dificil de
traversat o stradă pe care circulaţia vehiculelor este densă;
accidente datorate nerespectării regulilor de prioritate în intersecţie.
Alegerea unui anumit tip de automat de dirijare a circulaţiei, cu funcţionare
prestabilită, acţionat sau semiacţionat de vehicule, se face funcţie de anumite
condiţii pe care trebuie să le îndeplinească intersecţia, sub aspectul amplasării
în reţeaua stradală urbană, precum şi al valorilor traficului şi al variaţiilor
acestora.
3.2. Intersecții semaforizate

Intersecţiile semaforizate funcţionează pe principiul separării perioadelor de
timp alocate mişcărilor de trafic conflictuale, aşa încât fiecare dintre acestea să
devină sigure şi să utilizeze eficient spaţiul de carosabil disponibil.
Avantajele utilizării corecte a semafoarelor sunt următoarele:
- Reduc frecvenţa accidentelor vehicule-pietoni şi vehicule-vehicule (pe
direcţii perpendiculare)
- Pot creşte capacitatea de trafic faţă de intersecţiile nesemaforizate
- Pot fi programate să crească şi capacitatea de trecere a persoanelor (prin
prioritate pentru pietoni şi pentru vehiculele de transport public)
- În cazul existenţei unei distanţe corespunzătoare între intersecţii, pot fi
coordonate, aşa încât să asigure o trecere aproape fără opriri a
vehiculelor, prin scheme de control al traficului urban în reţea.
- Pot fi programate să asigure prioritate mişcărilor de pe anumite braţe ale
intersecţiei
- Costurile implicate şi spaţiul ocupat sunt, în general, mai mici faţă de
sensuri giratorii cu capacitate similară.

Printre dezavantajele utilizării semafoarelor se numără:
- În general, conduc la o creştere a coliziunilor faţă-spate
- Pot conduce la creşterea întârzierilor pe anumite direcţii, pentru vehicule,
în special în perioadele cu trafic necongestionat (în afara orelor de vârf)
- Instalaţiile de semaforizare trebuie întreţinute continuu, iar funcţionarea
lor trebuie monitorizată
- Defectarea semafoarelor, poate conduce, rar, la dificultăţi de trafic
serioase şi pe arii largi, în special în orele de vârf
Strategii de control al traficului în intersecţiile semaforizate:
- Control izolat al intersecţiilor, în care deciziile referitoare la duratele
timpilor de semnalizare se iau exclusiv pe baza cererii de trafic pe intrările
din intersecţia respectivă
- Control coordonat al intersecţiilor, care deciziile referitoare la duratele
timpilor de semnalizare se iau ţinându-se cont de semnalele de trafic
adiacente, cu care este conectat controlerul intersecţiei respective, cu
scopul de a asigura un coridor de trecere liberă.
3.2.1. Controlul izolat al intersecţiilor semaforizate

A. Control cu timp fix al semaforizării: Se utilizează un plan de semaforizare
predeterminat, cu durate fixe de semaforizare, calculat astfel încât să
minimizeze întârzierea generală pe intersecţie pentru cererea de trafic,
pe timpul perioadei studiate. Pot fi dezvoltate planuri de semaforizare
diferite pentru perioade diferite ale zilei (ora de vârf de dimineaţă, de
după-amiază, trafic de noapte) sau chiar pentru zile diferite (zile
lucrătoare sau week-end).
B. Control în timp real, în funcţie de cerere: Durate de semnalizare şi timpi
de verde variabili, în funcţie de cererea de trafic detectată pe intrările
semnalizate sau pe grupuri de benzi. Decizia de a extinde sau nu durata
de verde se bazează strict pe condiţiile de pe intrările sau grupurile de
benzi deservite de verdele respectiv.
C. Control în timp real, auto-optimizat: Durate de semnalizare şi timpi de
verde variabili, în funcţie de o optimizare în timp real a comportamentului
traficului, ţinând cont de condiţiile de pe toate intrările semnalizate în
intersecţie.

3.2.2. Terminologie. Definiţii
Braţ – O arteră de trafic ce asigură intrarea sau ieşirea dintr-o intersecţie. Fiecare
braţ conţine unul sau mai multe fluxuri de trafic.
Direcţie de trafic – Traficul ce poate fi privit ca desfăşurându-se pe o singură
direcţie: trafic de vehicule, trafic de pietoni. Fiecare direcţie de trafic conţine una
sau mai multe benzi.
Bandă de circulaţie – O porţiune a drumului pe care se află o singură coloană de
vehicule.
Intrare – Bandă sau grup de benzi prin care traficul intră în intersecţie.
Ciclu – O secvenţă completă de semaforizare (pe toate intrările).
Durata (lungimea) ciclului (C) – Timpul total (sec.) pentru completarea unui ciclu pe
toate intrările.
Indicaţie – Aprinderea unuia sau mai multor focuri de semnal, permiţând sau
interzicând anumite mişcări de trafic.
Fază () – Reprezintă timpul de verde, galben şi „toate roşu” care deservesc o
mişcare sau un set de mişcări concurente. Toate capetele de semafor alocate unei
anumite faze comută în acelaşi timp. O fază poate controla mai multe fluxuri de
trafic, cu condiţia ca acestea să poată primi aceeaşi indicaţie la semnal.
Fază procentuală – Parte a unui ciclu utilizată de o singură fază, exprimată fie în
secunde (durata fazei), fie procentual (durata fazei/durata ciclului).
Interval – Durata de timp în care indicaţiile semafoarelor rămân identice pe toate
intrările.
Interval de verde (G) – Durata de verde pe o intrare.
Interval de galben (interval de schimbare) (Y) – Durata de galben, avertizează
conducătorii auto asupra schimbării indicaţiei de semnal din verde în roşu.
Durata de roşu (R) - Durata de roşu pe o intrare.
„Toate roşu” (AR) – durată în interiorul ciclului de semaforizare, în care pe toate
intrările este aprins focul roşu.
Interval de eliberare (CT) – Intervalul de galben plus timpul „toate roşu” care
asigură eliberarea intersecţiei : CT = Y + AR

Durata ciclului
Faza 1 Faza 2
Interval de Interval de Interval

verde galben „toate roşu”
Timp pierdut (LT) – Durata (sec) în care intersecţia nu este utilizată efectiv de nici
una dintre intrări, incluzând :
- Timpul pierdut la pornire (timpul necesar primelor vehicule din coloană
să răspundă la indicaţia de verde – 3-4 sec/fază) (SLT)
- Timpul pierdut pe galben (cam jumătate din intervalul de galben este
considerat timp pierdut) (YLT)
- Durata „toate roşu”.
LT = SLT + YLT + AR
Verde efectiv (g) – Durata (sec) utilizată efectiv de o intrare, pentru o mişcare de
trafic: g = G + Y + AR - LT
Roşu efectiv (r) – Durata (sec) care nu este efectiv utilizată de o intrare, pentru o
mişcare de trafic: r = C – g
Verde procentual – Raportul dintre timpul de verde efectiv şi lungimea ciclului
Interverde (IG) – Durata dintre finalul duratei de verde de pe o fază şi începutul
duratei de verde de pe faza următoare: IG = Y + AR.
Scopul duratei de interverde dintre două faze consecutive este: să avertizeze
traficul care iese din intersecţie că faza s-a încheiat; să existe siguranţa că
ultimul vehicul intrat în intersecţie în faza de verde are timp suficient să
evacueze zona de conflict, înainte de intrarea în intersecţie a primului vehicul
din faza următoare. Prima dintre funcţii este realizată de „galben”, iar a doua
de „toate roşu”. Prima dintre funcţii este realizată de „galben”, iar a doua de
„toate roşu”.
Duratele de „galben” şi „toate roşu” sunt, de obicei, predeterminate şi
constante pe toată perioada de operare. Dacă şi durata ciclului şi durata de
verde sunt predeterminate, atunci este vorba de un control în modul „timp
fix”.
Mişcare de trafic protejată – O mişcare de trafic ce are drept de trecere, fără a fi
necesară acordarea priorităţii pentru alte mişcări conflictuale, cum ar fi vehicule ce
circulă din direcţii opuse sau pietoni (ex: fază separată pentru viraj stânga).
Mişcare de trafic permisă – O mişcare de trafic cu drept de trecere, dar care este
obligată să acorde prioritate unor mişcări conflictuale sau pietonilor.
Pentru majoritatea intersecţiilor, capacitatea şi nivelul de performanţă

depind în primul rând de condiţiile geometrice şi de cererea de trafic. Totuşi, prin
intermediul semnalelor de trafic se poate realiza o distribuire a capacităţii pe
diferite artere, în funcţie de timpul de verde alocat fiecăreia dintre acestea. Pentru
calcularea capacităţii şi a nivelului de performanţă este necesar, în consecinţă, ca
mai întâi să se determine fazele şi timpii de semaforizare cei mai potriviţi pentru
condiţiile respective.
Semnalizarea prin intermediul celor trei culori luminoase (verde, galben,
roşu) este aplicată pentru separarea în timp a mişcărilor conflictuale de trafic.
Acestea se pot clasifica în conflicte principale (între traficul ce se deplasează pe
intrări ce se intersectează, precum şi între traficul respctiv şi pietonii care
traversează) şi conflicte secundare (între mişcările de viraj şi traficul din direcţie
opusă şi între mişcările de viraj şi pietonii ce traversează).

Conflict primar
Conflict secundar
Flux vehicule
Flux pietoni
Dacă se doreşte doar controlul conflictelor principale, sunt suficiente două
faze, câte una pentru fiecare arteră transversală. Această reprezintă varianta
fundamentală sau de bază în majoritatea analizelor de semnalizare de trafic,
deoarece în cele mai multe cazuri asigură capacitatea cea mai mare. Metoda poate
fi aplicată mai ales în cazurile în care sunt eliminate virajele la stânga.
Strada A
Faza A Faza B
Strada B

Introducerea a mai mult de două faze conduce la creşterea lungimii ciclului
şi, implicit, a timpului pierdut. Deşi poate fi benefică din punct de vedere al
siguranţei, conduce la o scădere a capacităţii totale a intersecţiei.
1. Control în două faze, cu separarea conflictelor principale.
2. Control în trei faze, cu prelungire a timpului de trecere pentru intrarea

nordică, pentru creşterea capacităţii de viraj la stânga pe această intrare.
3. Control în trei faze, cu fază suplimentară pentru intrarea nordică, înaintea

fazei principale, pentru creşterea capacităţii de viraj la stânga pe această
intrare.

4. Control în trei faze, cu viraj separat la stânga pe direcţia N-S.
5. Control în patru faze, cu viraj separat la stânga pe ambele direcţii.
6. Control în patru faze, cu faze separate pentru fiecare intrare.
Durata de trecere (eliberare) a intersecţiei reprezintă intervalul de timp

dintre diferite vehicule ce traversează intersecţia într-un interval de verde. Se
măsoară în momentul în care roţile din spate ale vehiculului trec de linia de
eliberare a intersecţiei.
Dacă considerăm o coloană de N vehicule ce aşteaptă aprinderea focului
verde, durata de trecere pentru primul vehicul este considerată ca fiind intervalul
de timp între iniţierea indicaţiei de verde şi trecerea roţilor din spate ale primului
vehicul peste linia de eliberare a intersecţiei. Pentru vehiculul N, durata de trecere
reprezintă intervalul între momentul trecerii peste linia de eliberare a intersecţiei a
roţilor vehiculului N-1 şi cel al trecerii roţilor din spate al vehiculului N.

Durata de trecere pentru primul vehicul este mai mare, deoarece include
timpul de reacţie al şoferului şi timpul necesar pentru accelerare. Pentru al doilea
vehicul, durata de trecere scade, deoarece timpul de reacţie al şoferului se
suprapune, practic, peste cel al primului şofer. După câteva vehicule, durata de
trecere devine constantă (de obicei la al patrulea sau al cincilea vehicul), iar această
valoare este definită ca fiind durata de trecere la saturaţie, reprezentând durata de
trecere atinsă de un pluton de vehicule ce se deplasează constant prin intersecţie, la
indicaţia de verde. Se notează cu h (sec).
Dacă fiecare vehicul are nevoie de h secunde de timp verde şi semnalul ar fi

tot timpul verde, atunci prin intersecţie ar trece s vehicule/oră, unde s rata fluxului
de saturaţie în vehicule pe oră de timp verde pe bandă.
Prin urmare:
3600
𝑠=
ℎ
După cum se observă în figura de mai sus, diferenţa dintre timpii de trecere
ai primilor vehicule şi h este notată cu: 𝑒𝑖 . Prin însumarea acestor valori se obţine
timpul pierdut la pornire:
𝑁
𝑆𝐿𝑇 = ∑ 𝑒𝑖
𝑖=1
Timpul de verde necesar pentru trecerea celor N vehicule va fi:

𝑇 = 𝑆𝐿𝑇 + ℎ × 𝑁
Timpul efectiv de verde este dat de formula:
𝑔 = 𝐺 + 𝑌 + 𝐴𝑅 − 𝐿𝑇
Unde: g = timpul efectiv de verde
G = intervalul de verde
Y = intervalul de galben
AR = „toate roşu”
LT = timpul total pierdut
Dar:
𝐿𝑇 = 𝑆𝐿𝑇 + 𝑌𝐿𝑇 + 𝐴𝑅
Unde: SLT = timpul pierdut la pornire
YLT = timpul pierdut pe galben
Înlocuind în formula de mai sus, obţinem:
𝑔 = 𝐺 + 𝑌 − 𝑆𝐿𝑇 − 𝑌𝐿𝑇
Elementele menţionate mai sus pot fi observate pe graficul: rată de eliberare
funcţie de timp, prezentat în figura de mai jos:
Timpul efectiv de roşu a fost exprimat prin formula:

𝑟 =𝑐−𝐺
Dar poate fi scris şi sub forma:
𝑅 = 𝑟 + 𝐿𝑇

Calculul capacităţii intersecţiei
Ţinând cont de faptul într-o intersecţie nici o intrare nu primeşte verde
continuu, aşa cum am presupus pentru calcularea ratei fluxului de saturaţie, pentru
obţinerea capacităţii intersecţiei se înmulţeste s cu valoarea lui verde procentual:
𝑔
𝑐=𝑠×
𝐶
𝑔
Unde: = verde procentual
𝐶
C = lungimea ciclului
c = capacitatea (veh/h) = numărul maxim de vehicule ce pot
trece printr-o intersecţie într-o oră, pe o intrare
Determinarea lungimii ciclului
Notăm timpul pierdut la pornire pentru faza i cu: 𝐿𝑇𝑖 . Considerând M faze,
timpul total pierdut la pornire, pe durata unui ciclu, va fi:
𝑀
𝐿𝑇𝐶 = ∑ 𝐿𝑇𝑖
𝑖=1
În cazul în care se consideră că timpii pierduţi la pornire pentru fiecare fază

sunt identici şi egali cu 𝐿𝑇𝑓 , obţinem:
𝐿𝑇𝐶 = 𝑀 × 𝐿𝑇𝑓
Dacă C este exprimat în secunde, numărul de cicluri pe oră va fi:
3600
𝑁𝐶 =
𝐶
Timpul total pierdut pe oră va fi:
3600
𝐿𝑇ℎ = 𝑁𝐶 × 𝐿𝑇𝐶 = × 𝑀 × 𝐿𝑇𝑓
𝐶
Timpul efectiv de verde într-o oră va fi egal cu o oră minus timpul total
pierdut pe oră:
3600 𝑀 × 𝐿𝑇𝑓
𝑔ℎ = 3600 − 𝐿𝑇ℎ = 3600 − × 𝑀 × 𝐿𝑇𝑓 = 3600(1 − )
𝐶 𝐶
Volumul critic pe bandă (𝑉𝑐ℎ ) ce poate trece într-o oră este dat de raportul
dintre 𝑔ℎ şi h. Rezultă:
𝑔ℎ 3600 𝑀 × 𝐿𝑇𝑓
𝑉𝑐ℎ = = (1 − )
ℎ ℎ 𝐶
Dar, din formula ratei fluxului de saturaţie s, rezultă:

3600
ℎ=
𝑠
Deci:
𝑀 × 𝐿𝑇𝑓
𝑉𝑐ℎ = 𝑠(1 − )
𝐶
De unde:
𝑠 × 𝑀 × 𝐿𝑇𝑓
𝑉𝑐ℎ = 𝑠 −
𝐶
𝑠 × 𝑀 × 𝐿𝑇𝑓
= 𝑠 − 𝑉𝑐ℎ
𝐶
𝑠 × 𝑀 × 𝐿𝑇𝑓 𝑀 × 𝐿𝑇𝑓
𝐶= =
𝑠 − 𝑉𝑐ℎ 𝑉
1 − 𝑐ℎ
𝑠
Formula de mai sus mai poate fi rafinată, renunţând la prezumţia că va exista
un flux uniform de trafic în ora respectivă şi introducându-se factori de corecţie, de
genul: factor oră de vârf, calitatea serviciului etc., rezultând formule mai complexe,
dar mai exacte.
3.2.3. Algoritmul de calcul efectiv

Pas 1. Introducerea datelor geometrice, a condiţiilor de mediu şi a fluxurilor de
trafic (total şi pe intrări, calcularea procentelor de viraje).
Proiectarea geometrică a intersecţiilor semaforizate trebuie să ţină seama de
o serie de aspecte de proiectare şi constructive privind, în special, asigurarea
vizibilităţii, a unor raze de curbură corespunzătoare, a canalizării fluxurilor de
circulaţie etc.
Deoarece semafoarele electrice permit mişcarea traficului de vehicule
aferent oricărui acces al unei intersecţii numai o perioadă de timp, respectiv
pe durata semnalului de verde, apare necesar ca în cazul apariţiei cozilor de
aşteptare, intrările în intersecţie să fie lărgite, pentru o corectă alimentare a
acestora şi pentru a fi îndeplinite condiţiile de evacuare ale fluxurilor de
vehicule.
Dacă intersecţia există deja şi amplasarea acesteia nu mai permite
modificarea configuraţiei geometrice, în sensul lărgirii acceselor, programele
de funcţionare ale semafoarelor trebuie alcătuite funcţie de valorile
caracteristice ale traficului, în concordanţă cu utilizarea la maximum a
posibilităţilor pe care le oferă situaţia existentă.

Dacă intersecţia este în stadiul de proiect sau dacă sunt posibile anumite
schimbări în configuraţia existentă, atunci se poate realiza o alegere
corespunzătoare a lăţimii acceselor, în concordanţă cu o ajustare
convenabilă a timpilor de verde, aferenţi acceselor respective, pentru
obţinerea unei capacităţi de circulaţie corespunzătoare.
În cazul unei intersecţii cu o funcţionare normală în două faze, lăţimile

acceselor pot fi considerate ca proporţionale cu rădăcina pătrată a fluxurilor,
timpii de verde şi lungimile secţiunilor lărgite fiind în acelaşi raport cu
lăţimile:
l 1 Tv1 d1 Q1
  
l 2 Tv 2 d 2 Q2
,
unde:
Q1, Q2 sunt fluxurile de trafic maxime ale acceselor corespunzătoare fazelor
de circulaţie 1 şi 2;
Tv1 Tv 2
şi - timpii verzi corespunzători.
Pas 2. Stabilirea tipului de semnalizare:

- Faze: se porneşte de la controlul clasic, în două faze
- Timp de eliberare
- Timp pierdut
Prin fază de funcţionare a unei instalaţii se înţelege o parte din durata unui
ciclu – durata de timp de la începutul unui verde până la începutul timpului
de verde următor – destinată unei singure mişcări sau unei combinaţii de

mişcări a traficului de vehicule sau de pietoni, care nu prezintă puncte de
conflict esenţiale sau dacă prezintă, acestea sunt neesenţiale, caracterizate
prin faptul că au concomitent permisiunea de circulaţie.
Sub aspectul funcţional, faza cuprinde în general, două perioade distincte:
- perioada de admisie în intersecţie, care corespunde aproximativ cu
durata timpului de verde Tv, această corespondenţă aproximativă se
datorează timpului pierdut la demarare şi celui determinat de prelungirea
efectului timpului de verde în domeniul celui galben
- perioada necesară degajării intersecţiei pentru evitarea oricărei
posibilităţi de conflict a vehiculelor şi pietonilor care au intrat şi trebuie să
evacueze intersecţia pe durata fazei respective, cu vehiculele şi pietoni ce
vor primi permisiunea de intrare în intersecţie o dată cu apariţia fazei de
circulaţie următoare
Pas 3. Timpi de semnalizare:
- tipul intrărilor
- lăţimea efectivă a intrărilor
- fluxul de saturaţie
- factori de corecţie (mărimea oraşului, tipul de drum, gradient, parcări,
- raportul flux/flux de saturaţie
- durata ciclului şi timpii de verde
Pas 4. Capacitatea.
Caracteristicile de operare ale intersecţiilor semnalizate pot fi estimate şi
evaluate cu ajutorul analizei capacităţii şi performanţelor.
Un rezultat important al analizei capacităţii este raportul dintre volum şi
capacitate (V/C), numit gradul de saturaţie. Acest raport arată cât din
capacitatea intersecţiei este utilizată de cererea de trafic.
Performanţa unei intersecţii este dată prin estimarea întârzierii medii a
fiecărui vehicul care străbate această intersecţie. întârzierile scurte
caracterizează un nivel bun de serviciu pe când întârzierile mari, un nivel
scăzut (de exemplu, o întârziere de 5 s/veh, caracterizează nivelul A, iar 30
s/veh, nivelul D). Performanţele slabe ale nivelului D, recomandă modificarea
programului de semaforizare, redistribuirea fluxurilor sau chiar modificarea
elementelor geometrice ale intersecţiei.
Nivelul de serviciu are influenţă directă asupra raportului V/C.
Pentru analiza capacităţii de circulaţie în intersecţie, se adoptă pentru
început un flux de saturaţie So, considerat frecvent de 1800 Vt/h pentru o
singura bandă de circulaţie. Aceasta este valoarea ideală căci, aşa cum s-a
mai spus, trebuie luate în considerare şi caracteristicile drumului precum şi
alţi factori. Astfel că, So trebuie ajustat pentru a reflecta realitatea. Această
ajustare ia în considerare şi condiţiile de mediu, astfel:
S  S0  N  C1  C2  C3  C 4  C5  C 6  C7  C8
,
unde, coeficienţii au următoarea semnificaţie:
N - numărul benzilor de circulaţie;
C1-.coeficientul ce ţine cont de lăţimea benzii de circulaţie; lăţimea cea mai
confortabilă (normală) corespunde valorii 1,00 a coeficientului, pentru care
se obţine valoarea maximă a fluxului; coeficientul C1 ia valori între 0,87 -
1,10 pentru lăţimi cuprinse între 2,5 m - 4,5 m;
C2-coeficient ce ţine cont de greutatea vehiculului; autovehiculele grele au
acceleraţie scăzută, deci au tendinţa de a reduce probabilitatea de
descărcare a intersecţiei deoarece se creează intervale de timp mari între
autovehicule şi fluxul scade. Coeficientul C2 ia valori între 1,00 - 0,87 pentru
autovehiculele grele a căror pondere este între 0% şi respectiv, 30%;
C3 -coeficient ce ţine seama de înclinarea drumului; panta produce o scădere
a acceleraţiei, deci intervalele de timp dintre autovehicule cresc şi fluxul
scade; în cazul rampelor situaţia este inversă, C3 este cuprins între 0,97 -1,03
pentru pante cuprinse între +6% şi -6%.
C4-coeficient ce ţine cont de locurile de parcare; parcările alăturate unei
intersecţii au tendinţa de a interfera cu fluxurile de trafic, deci manevrele de
parcare întrerup descărcarea normală; reducerea numărului benzilor de
serviciu măresc impactul parcării; pentru o singură bandă acest coeficient
este de 1,0 - 0,7 pentru parcări cu 0 - 40 parcări/oră; coeficientul are valori
mai mici pentru intrări cu 2 sau mai multe benzi;
C5-coeficient ce ţine cont de autobuzele blocate; transportul în comun care
prezintă staţii apropiate de intersecţii generează scăderea fluxului de
saturaţie; o bandă poate fi temporar blocată pe durata verdelui, sau viteza va
scădea în apropierea mijloacelor de transport oprite, deci valoarea fluxului va
scădea; pentru intrări cu o singura bandă acest coeficient ia valori între 1,00 -
0,83 pentru un număr de 0 - 40 autobuze/h, fiind mai mic pentru mai multe
benzi de circulaţie;

C6 - coeficient ce ţine cont de tipul intersecţiei; se recomandă valori ale
fuxului critic So = 1600 Vt/h pentru oraşe mici, So = 2000 Vt/h pentru
intersecţii foarte mari dar având o proiectare foarte bună;
C7, C8-coeficienţi ce ţin cont de mişcarea de virare (la stânga şi la dreapta);
virarea are adesea conflicte cu traficul de traversare şi/sau pietonii, ca
rezultat fluxul de saturaţie trebuie să fie mai scăzut decât în cazul mişcării
înainte; tipul de mişcare - la dreapta sau la stânga - procesul de servire -
protejare, permisiunile sau combinaţiile celor două - volumele de trafic opus
şi numărul pietonilor trebuie introduse ca elemente de intrare pentru
estimarea acestor coeficienţi; valorile lor sunt cuprinse între 0,95 - 0,25;
analiza virărilor are foarte mult în comun cu mişcările din intersecţii.
Pas 5. Nivelul de performanţă:
- lungimea coloanelor
- număr vehicule oprite
- întârziere
Întârzierea totală a unei călătorii are două componente, una pe parcurs, iar
cealaltă la linia de stop. Întârzierea pe parcurs pentru un vehicul individual
este diferenţa între momentul când a sosit şi momentul când ar fi trebuit să
sosească deplasându-se continuu. Întârzierea la stop pentru un vehicul
singular este perioada de timp pierdută stând, posibil la coadă, într-o
intersecţie semaforizată. O valoare obişnuită se consideră cea de 5
min/h/vehicul
Dacă rezultatele nu sunt corespunzătoare cu cele propuse, se reia ciclul,
schimbându-se fazele, permisiunea de viraj, duratele.
Formulele pentru majoritatea parametrilor ce trebuie calculaţi au fost
prezentate anterior.

3.3. Intersecţii nesemaforizate
În acest capitol sunt tratate intersecţiile nesemaforizate cu 3 sau 4 braţe.
Parametrii care pot fi estimaţi pentru anumite condiţii locale legate de geometrie,
mediu şi trafic sunt următorii:
- Capacitate
- Grad de saturaţie
- Întârziere
- Probabilitatea de formare a coloanelor de vehicule
3.3.1. CAPACITATEA
Capacitatea totală pentru toate braţele intersecţiei este calculată ca produsul
între capacitatea de bază pentru un set de condiţii predeterminate (ideale) şi o serie
de factori de coreţie (F).
Astfel, formula capacităţii este următoarea:
𝐶 = 𝐶0 𝑥𝐹𝑤 𝑥𝐹𝑀 𝑥𝐹𝐶𝑆 𝑥𝐹𝑅𝐹 𝑥𝐹𝐿𝑇 𝑥𝐹𝑅𝑇 𝑥𝐹𝑆𝑃
Unde: C = Capacitatea
C0 = Capacitatea de bază
Fw = Factor de corecţie funcţie de lăţimea arterelor de intrare
FM = Factor de corecţie funcţie de lăţimea medianei drumului principal
(dacă drumul principal poate fi traversat din 2 mişcări sau nu, de exemplu, dacă un
vehicul venit de pe drumul inferior poate sta pe mediană, fără să deranjeze traficul
din jur).
FCS = Factor de corecţie funcţie de mărimea oraşului
FRF = Factor de corecţie funcţie de tipul pavajului şi al factorului de
fricţiune
FLT = Factor de corecţie funcţie de procentul de viraje la stânga
FRT = Factor de corecţie funcţie de procentul de viraje la dreapta
FSP = Factor de corecţie funcţie de procentul de răspândire a
vehiculelor (procentul de trafic pentru drumul inferior, din totalul traficului)
55
3.3.2. GRADUL DE SATURAŢIE (DS)
Gradul de saturaţie pentru întreaga intersecţie se calculează cu formula:
𝑄
𝐷𝑆 = 𝑝⁄𝐶
unde: DS = Gradul de saturaţie

C = Capacitatea
C0 = Capacitatea de bază
Q p = Fluxul total efectiv, dat de formula: Q p = Q V xP
Q V = Fluxul total (veh/h) = fluxul total de vehicule care intră in

intersecţie
P = Factor de conversie al fluxului exprimat in vehicule pe oră in
flux exprimat in pcu/h (pcu = passenger car unit = factor de
conversie pentru diferite tipuri de vehicule in funcţie de
impactul lor asupra capacităţii, în raport cu un vehicul particular)
P = (pcuLV xLV% + pcuHV xHV% + pcuMC xMC% + pcuUM xUM%)/100
pcuLV = valoarea pcu pentru vehicule uşoare
LV% = procentul de vehicule uşoare în raport cu totalul de vehicule
pcuHV = valoarea pcu pentru vehicule grele
HV% = procentul de vehicule grele în raport cu totalul de vehicule
pcuMC = valoarea pcu pentru motociclete
MC% = procentul de motociclete în raport cu totalul de vehicule
pcuUM = valoarea pcu pentru vehicule nemotorizate
UM% = procentul de vehicule nemotorizate în raport cu totalul de
vehicule
3.3.3. ÎNTÂRZIEREA (D)

Întârzierea medie pe întreaga intersecţie (sec/pcu) este estimată dintr-o
curbă întârziere/grad de saturaţie determinată empiric. Întârzierea creşte
semnificativ proporţional cu valoarea fluxului total şi cu gradul de saturaţie.
56
3.3.4. PROBABILITATEA DE FORMARE A COLOANELOR
DE VEHICULE (QP%)
Probabiliatea de formare a coloanelor de vehicule (%) este estimată dintr-o
curbă probabilitate de coloană/grad de saturaţie determinată empiric.
3.3.5. ALGORITMUL DE CALCUL

Pas 1. Se colectează datele de intrare pentru condiţiile geometrice, de trafic şi de
mediu.
- Se trasează o schiţă a intersecţiei, marcându-se drumurile principale şi
secundare
- Se introduc datele geometrice, se calculează lăţimile medii ale intrărilor

pentru drumul principal (WBD) şi secundar (WBD) şi lăţimea medie a intrării
la nivel de intersecţie (WE).
57
WBD= (b + d/2)/2
WAC= (a + c)
WE= (a/2 + b + c/2 + d/2)/4
- Se stabileşte tipul de intersecţie, în funcţie de numărul de braţe şi de
numărul de benzi de pe drumul principal, respectiv secundar.
- Se introduc datele legate de mediu: uz comercial, rezidenţial sau cu acces
restricţionat; clasa oraşului: mic, mediu, mare, foarte mare; existenţa
trecerilor de pietoni sau a opririlor pentru autobuze
- Se introduc datele legate de trafic: situaţia traficului (an, oră), volumele
de trafic
- Se calculează procentajul virajelor pe fiecare intrare:
𝐴𝐿𝑇 + 𝐵𝐿𝑇 + 𝐶𝐿𝑇 + 𝐷𝐿𝑇

𝐿𝑇% = 100 ×
𝐴+𝐵+𝐶+𝐷
58
𝐴𝑅𝑇 + 𝐵𝑅𝑇 + 𝐶𝑅𝑇 + 𝐷𝑅𝑇
𝑅𝑇% = 100 ×
𝐴+𝐵+𝐶+𝐷
𝐴+𝐶
𝑆𝑃% = 100 ×
𝐴+𝐵+𝐶+𝐷
𝑄 =𝐴+𝐵+𝐶+𝐷
(Fluxul de trafic este în veh/oră)
unde: LT% - procentajul de vehicule care virează la stânga
RT% - procentajul de vehicule care virează la dreapta
SP% - procentajul de vehicule care merg înainte
Q – fluxul total de vehicule
Pas 2. Se stabilesc obiectivele de proiectare.

Pas 3. Se calculează capacitatea cu formula descrisă mai sus:
𝐶 = 𝐶0 𝑥𝐹𝑤 𝑥𝐹𝑀 𝑥𝐹𝐶𝑆 𝑥𝐹𝑅𝐹 𝑥𝐹𝐿𝑇 𝑥𝐹𝑅𝑇 𝑥𝐹𝑆𝑃
Pas 4. Se calculează gradul de saturaţie.
𝑄𝑝
𝐷𝑆 = ⁄
𝐶
Pas 5. Se calculează întârzierea şi probabilitatea de formare a coloanelor de

vehicule, cu ajutorul unor grafice experimentale, de genul celor de mai jos:
Grafic întârziere funcţie de grad de saturaţie
59
Grafic probabilitate de formare a coloanelor funcţie de grad de saturaţie
Pas 6. Se compară rezultatele cu obiectivele.
Dacă este OK, se opreşte calculul.
În caz contrar, se reproiectează intersecţia şi se reia algoritmul.
60
TRAFFIC MANAGEMENT CENTRE
INTELLIGENT TRANSPORTATION SYSTEMS (OPERATIONS)
GUIDELINES FOR USING SYNCHRO 9

(INCLUDING SIMTRAFFIC 9)
March 18, 2016
Transportation ITS Operations

Services Division Traffic Management Centre
DOCUMENT CONTROL
Contact Information
For more information related to these Guidelines, please contact:
Manager, ITS Operations

Traffic Management Centre
Transportation Services Division
703 Don Mills Road, 5th Floor
Toronto, M3C 3N3
Phone: 416-392-8826
Amendment History
Revision Date
No. Details Version
(YYYY/MM/DD)
Existing "Guidelines for using Synchro 7 (including
1 Draft 1.0 2015/08/17
SimTraffic 7" updated for Synchro Version 9.0.
Original draft reviewed by Darryl Spencer (Engineer,
2 ITSO), Pierre Vandall (Project Lead, ITSO), and Draft 1.1 2015/09/28
Rajnath Bissessar (Manager, ITSO).
Draft 1.1 reviewed by workshop participants and email
respondents:
District Traffic Planning - Godly Abraham, Geoffrey
Lau, Luigi Nicolucci
District Traffic Operations (DTO) – Farhad Awabin,
Christopher Chahil, Jim Edwards, Muhammad Qamar
Final
3 Infrastructure Planning – Grace Nzainga 2016/03/18
(Version 1)
Cycling Infrastructure – Darryl Olsen
Public Realm – Sheyda Saneinejad
City Planning – Diane Ho, Matthew Davis, Nasim
Norouzi, Satbinder Pabla, Garvin Tom
ITS Operations (ITSO) – Rajnath Bissessar, Irem Khan,
Pierre Vandall
APPROVAL
The version of this document dated March 18, 2016 was approved by the following:
 Safety and Mobility Committee (SMC) of Transportation Services on April 21, 2016.
 Transportation Planning of City Planning on April 26, 2016.
 TPROW Managers of Transportation Services on April 28, 2016.
Traffic Management Centre Guidelines for Using Synchro 9
ITS Operations (including SimTraffic 9)
Table of Contents
ABBREVIATIONS .................................................................................................................... VI
GLOSSARY ............................................................................................................................ VIII
EXECUTIVE SUMMARY ........................................................................................................ XIII
INTRODUCTION ................................................................................................................ 1
1.1. Background ................................................................................................................ 1
1.2. Planning vs. Operational Analysis............................................................................ 1
1.3. General Information on Data Requirements and Synchro Calculated Values ....... 1
MAP SETTINGS ................................................................................................................. 2
LANE SETTINGS ............................................................................................................... 3
3.1. User Inputs ................................................................................................................. 3
3.1.1. Changing the Name of the Approach Direction ..................................................... 3
3.1.2. Lanes and Sharing ................................................................................................ 4
3.1.3. Traffic Volume (vph).............................................................................................. 4
3.1.4. Link Distance (m) .................................................................................................. 6
3.1.5. Link Speed (km/h) ................................................................................................. 6
3.1.6. Travel Time (s)...................................................................................................... 6
3.1.7. Ideal Saturated Flow (vphpl) ................................................................................. 6
3.1.8. Lane Width (m) ..................................................................................................... 7
3.1.9. Grade (%) ............................................................................................................. 7
3.1.10. Area Type ......................................................................................................... 7
3.1.11. Storage Length (m) ........................................................................................... 8
3.1.12. Storage Lanes (#).............................................................................................. 8
3.1.13. Right Turn Channelized ..................................................................................... 8
3.1.14. Curb Radius ...................................................................................................... 8
3.1.15. Add Lanes (#).................................................................................................... 9
3.1.16. Right Turn on Red (RTOR) ................................................................................ 9
3.2. Synchro Calculated Values ....................................................................................... 9
3.2.1. Lane Utilization Factor .......................................................................................... 9
3.2.2. Right Turn Factor .................................................................................................. 9
3.2.3. Left Turn Factor (Prot) .......................................................................................... 9
Transportation i
Services Division
3.2.4. Left Turn Factor (Perm) ........................................................................................ 9

3.2.5. Right Ped Bike Factor ..........................................................................................10
3.2.6. Left Ped Factor ....................................................................................................10
3.2.7. Saturated Flow Rate (Prot) ..................................................................................10
3.2.8. Saturated Flow Rate (Perm) ................................................................................10
3.2.9. Saturated Flow Rate (RTOR) ...............................................................................10
VOLUME SETTINGS .........................................................................................................11
4.1. User Inputs ................................................................................................................11
4.1.1. Peak Hour Factor (PHF) ......................................................................................11
4.1.2. Growth Factor ......................................................................................................12
4.1.3. Heavy Vehicles (%)..............................................................................................12
4.1.4. Bus Blockages (#/hr)............................................................................................12
4.1.5. Adjacent Parking Lane? .......................................................................................12
4.1.6. Parking Maneuvers ..............................................................................................12
4.1.7. Traffic from Mid-block (%) ....................................................................................12
4.1.8. Link OD Volumes .................................................................................................13
4.2. Synchro Calculated Values ......................................................................................13
4.2.1. Adjusted Flow (vph) .............................................................................................13
4.2.2. Traffic in Shared Lane (%) ...................................................................................13
4.2.3. Lane Group Flow (vph) ........................................................................................13
TIMING SETTINGS ...........................................................................................................14
5.1. Node Settings - User Inputs .....................................................................................14
5.1.1. Node# ..................................................................................................................14
5.1.2. Control Type ........................................................................................................14
5.1.3. Cycle Length ........................................................................................................15
5.1.4. Lock Timings........................................................................................................15
5.1.5. Offset ...................................................................................................................16
5.1.6. Referenced to ......................................................................................................16
5.1.7. Reference Phase .................................................................................................16
5.1.8. Master Intersection ..............................................................................................16
5.1.9. Yield Point ...........................................................................................................16
5.1.10. Mandatory Stop On Yellow ...............................................................................16
Transportation ii
Services Division
5.2. Timing Settings - User Inputs ..................................................................................17

5.2.1. Turn Type ............................................................................................................17
5.2.2. Protected & Permitted Phases .............................................................................18
5.2.3. Detector Phases ..................................................................................................18
5.2.4. Switch Phase .......................................................................................................18
5.2.5. Leading Detector and Trailing Detector ................................................................18
5.2.6. Minimum Initial .....................................................................................................18
5.2.7. Minimum Split ......................................................................................................19
5.2.8. Total Split .............................................................................................................19
5.2.9. Yellow Time .........................................................................................................19
5.2.10. All-Red Time ....................................................................................................19
5.2.11. Lost Time Adjust ..............................................................................................20
5.2.12. Lagging Phase .................................................................................................20
5.2.13. Allow Lead/Lag Optimize? ................................................................................20
5.2.14. Recall Mode .....................................................................................................20
5.3. Synchro Calculated Values ......................................................................................21
5.3.1. Volume to Capacity Ratio.....................................................................................21
5.3.2. Queue Length 50th & 95th (m) ...............................................................................21
PHASING SETTINGS ........................................................................................................23
6.1. User Inputs ................................................................................................................23
6.1.1. Vehicle Extensions (Maximum Gap) ....................................................................23
6.1.2. Minimum Gap ......................................................................................................23
6.1.3. Time Before Reduce ............................................................................................24
6.1.4. Time to Reduce ...................................................................................................24
6.1.5. Pedestrian Phase ................................................................................................24
6.1.6. Walk Time............................................................................................................24
6.1.7. Flashing Don’t Walk .............................................................................................24
6.1.8. Pedestrian Calls...................................................................................................24
6.1.9. Fixed Force Off ....................................................................................................25
DETECTOR SETTINGS ....................................................................................................25
7.1. User Inputs ................................................................................................................25
7.1.1. Number of Detectors ............................................................................................25
Transportation iii
Services Division
7.1.2. Switch Phase .......................................................................................................26

7.1.3. Leading Detector .................................................................................................26
7.1.4. Trailing Detector and Detector 1 Position .............................................................27
7.1.5. Detector Size .......................................................................................................28
7.1.6. Detector Type ......................................................................................................28
7.1.7. Detector Extend ...................................................................................................28
7.1.8. Detector Queue ...................................................................................................28
7.1.9. Detector Delay .....................................................................................................28
SIMULATION SETTINGS ..................................................................................................29
8.1. User Inputs ................................................................................................................29
8.1.1. Taper Length .......................................................................................................29
8.1.2. Lane Alignment ....................................................................................................29
8.1.3. Enter Blocked Intersection ...................................................................................30
8.1.4. Link Offset ...........................................................................................................30
8.1.5. Crosswalk Width ..................................................................................................30
8.1.6. Two-Way Left Turn Lane (TWLTL) Median ..........................................................30
8.1.7. Turning Speed (km/h) ..........................................................................................30
HCM 2010 SETTINGS .......................................................................................................31
9.1. Signalized Intersections – Auto Mode .....................................................................31
9.1.1. HCM 2010 Intersection Settings...........................................................................31
9.1.2. HCM 2010 Settings ..............................................................................................35
9.2. Signalized Intersections – Pedestrian Mode ...........................................................39
9.2.1. HCM 2010 Pedestrians Settings ..........................................................................39
9.2.2. HCM 2010 Crosswalk Settings ............................................................................40
9.3. Signalized Intersections – Bicycle Mode.................................................................44
9.3.1. HCM 2010 Bicycle Mode Settings ........................................................................44
9.3.2. HCM Bicycle Settings ..........................................................................................44
9.4. Two-way Stop Control Intersections – Auto Mode .................................................47
9.4.1. HCM 2010 Intersection ........................................................................................47
9.4.2. Movement Settings ..............................................................................................48
9.4.3. HCM 2010 Lane...................................................................................................50
9.5. Two-way Stop Control Intersections – Pedestrian Mode .......................................50
Transportation iv
Services Division
9.5.1. HCM 2010 Pedestrians ........................................................................................50

9.5.2. HCM 2010 Crosswalk ..........................................................................................51
9.6. All-way Stop Control Intersections ..........................................................................53
9.6.1. HCM 2010 Intersection ........................................................................................53
9.6.2. Movement Settings ..............................................................................................53
9.6.3. HCM 2010 Lane Settings .....................................................................................54
SPECIAL CONSIDERATIONS ..........................................................................................55
10.1. Signal Coordination ..................................................................................................55
10.2. Model Calibration ......................................................................................................55
10.3. Volume Balancing .....................................................................................................55
10.4. HOV Lanes.................................................................................................................56
10.5. Streetcars ..................................................................................................................57
10.6. Transit Priority ..........................................................................................................57
10.7. Traffic Adaptive .........................................................................................................57
10.8. Bicycle Lanes ............................................................................................................58
10.9. Offset Intersections ..................................................................................................58
10.10. Roundabouts.............................................................................................................58
SIMTRAFFIC .....................................................................................................................59
REPORTS .........................................................................................................................60
REFERENCES .........................................................................................................................61
Transportation v
Services Division
Abbreviations
APS Accessible Pedestrian Signal
ATCS Adaptive Traffic Control System
AWSC All-way-Stop Control
CBD Central Business District
CCG Canadian Capacity Guide (for Signalized Intersections)
DTO District Traffic Operations
FDW Flashing Don't Walk
HCM 2000 Highway Capacity Manual 2000 (US)
HCM 2010 Highway Capacity Manual 2010 (US)
HOV High Occupancy Vehicles
fLU Lane Utilization Factor
LOS Level of Service
MOC Mode of Control
MOE Measure of Effectiveness
OD Origin-Destination
OTC Ontario Traffic Council
pcphgpl passenger car per hour of green per lane
Ped Pedestrian
PHF Peak Hour Factor
Prot Protected Phase
Perm Permissive Phase
RTOR Right turn on red
Transportation vi
Services Division
SA Semi-actuated
SAP Semi-actuated Pedestrian
SAV Semi-actuated Vehicle
SCOOT Split, Cycle and Offset Optimization Technique
sqrt Square Root
TMC Turning Movement Count
TSU City’s Traffic Safety Unit
TWLTL Two-way Left Turn Lane
TSOG Traffic Signal Operations Group of ITS Operations
TSP Transit Signal Priority
TWSC Two-way-Stop Control
v/c Volume to capacity ratio
vph Vehicles per hour
vphpl Vehicles per hour per lane
v50 50th Percentile Volume
v95 95th Percentile Volume
V15 Peak 15 minute volume
V60 Peak hour volume
Veh Vehicles
Transportation vii
Services Division
Glossary
Accessible Signal devices designed to assist pedestrians who are visually and/or
Pedestrian hearing impaired by providing information that they can interpret to
Signals (APS) understand when they may cross at a signalized intersection.
Adaptive Traffic A traffic control system that automatically adjusts signal timing
Control System parameters in real-time to allow for signal operations that respond to
(ATCS) actual, real-time traffic conditions.
Capacity The maximum rate at which vehicles can pass through a given point in
an hour under prevailing conditions, known as the saturation flow rate,
applied in conjunction with the ratio of time during which vehicles may
enter the intersection.
Controller (Timer) A device that controls traffic at an intersection by alternating the right-
of-way between conflicting streams of vehicular traffic, or vehicular
traffic and pedestrians crossing a roadway.
Coordinated Signal operation in coordination with other signalized intersections,

Actuated and using vehicle, bicycle, and/or pedestrian detection to define signal
timing.
Coordination The ability to coordinate multiple signalized intersections to enhance

the operation of one or more directional movements in a system.
Cycle Length The time required to complete a full sequence of signal indications at a
signalized intersection.
Delay The additional travel time experienced by a driver, passenger, or

pedestrian.
Detector A device used to count and/or determine the presence of a vehicle,

bicycle, or pedestrian.
Double Cycle A cycle length that is half the duration of the cycle length of other
signals in a coordinated system
Effective Green The time during which vehicles in a given traffic movement proceed
Time through the signalized intersection. It is equal to the total phase time
minus the lost time (where the total phase time equals the sum of the
green, amber, and all red interval times).
Feathering A congestion mitigation strategy that spreads out the traffic queue
along a corridor with excessive congestion.
Transportation viii
Services Division
Flashing Don’t The time provided for a pedestrian to clear the crosswalk, equivalent to
Walk (FDW) the time required to cross the entire width of the intersection. It is also
known as the "pedestrian clearance interval".
Free Flow A flow of traffic unaffected by upstream or downstream conditions.
Fully Actuated A signal operation in which vehicle detectors and/or pedestrian

Mode of Control pushbuttons at each approach to the intersection control the
(FA) occurrence and length of every phase.
Fully Signalized A type of operation at offset intersections that incorporate both of the
Offset closely located minor street legs into the traffic signal installation.
Intersections
Fixed Time Mode A signal operation in which the vehicle signal indication changes
of Control (FXT) automatically from the main street to the side street, and back, even if
there are no vehicles/pedestrians wishing to cross the main street.
Gating A congestion mitigation strategy that controls the inflow of traffic into
sensitive areas (i.e. where queue routinely builds up).
Growth Factor This can be used to adjust traffic volumes. Within Synchro, volume
data is multiplied by the Growth Factor when calculating Adjusted
Volumes and Lane Group Volumes.
Hardwire Interconnection using physical cable between two controllers that

Interconnect allows closely spaced signals to maintain a fixed offset relationship at
all times.
Ideal Saturated This is a macroscopic model term used by Synchro which will affect
Flow the Headway Factor and therefore influence headways and Saturated
Flow Rates.
Intersection A control device dedicated primarily to providing traffic gaps for

Pedestrian Signal pedestrian right-of-way at an intersection. Main road traffic is fully
(IPS) signalized while the side road must be controlled with stop signs. They
are also known as "Half Signals".
Lane Utilization This determines how the traffic volumes assigned to a lane group are
distributed across each lane. A value of 1 indicates equal distribution
across all lanes.
Lost Time The time in a signal phase (where the total phase time equals the
green plus amber plus all red interval times) when no vehicles are able
to pass through the signalized intersection. Lost time is comprised of
two parts: start-up lost time and clearance lost time.
Transportation ix
Services Division
Measures of Measurable parameters that demonstrate the benefits, impacts, and

Effectiveness cost-effectiveness of signal timing plan alternatives on road users for
(MOEs) the individual intersection, associated corridor and entire network.
Offset The time relationship between the coordinated phase’s defined

reference point and a defined master reference (i.e. master clock)
point.
Offset A location where two minor streets intersect a major street at “nearly”
Intersections the same location, operating like two T-intersections located very close
to each other on the arterial road.
Offset Transition A state of a controller to resynchronize traffic signals to its coordinated

operations every time a signal timing plan is changed, or after pre-
emption is served.
Partially A type of operation at offset intersections that incorporate only one of

Signalized Offset the minor street legs into the traffic signal installation and effectively
Intersections operate like a signalized T-intersection.
Passage Time A feature that extends the green interval based on the detector status
once the phase is green.
Peak Hour Factor The ratio of the flow rate for the entire hour, to the flow rate for the
peak 15 minutes. It quantifies the uniformity of flow across the peak
hour.
Permissive A movement where vehicles are allowed to proceed if there are

Movement available gaps in the conflicting flow.
Pre-emption Upon actuation of a pre-defined pre-emption, the traffic signal

controller terminates the current phase and serves a pre-defined pre-
emption phase. The most common use of this operation in Toronto is
to manipulate the normal operation of traffic signals to provide
preferential treatment to rail, emergency and transit vehicles.
Protected / A compound movement protection at a signalized intersection that

Permissive displays the protected phase before the permitted phase.
Movement
Saturated Flow The actual maximum flow rate for this lane group after adjusting for all
Rate of the interference factors. The Saturated Flow Rates represent the
number of lanes multiplied by the Ideal Saturated Flow Rate and
interference factors due to heavy vehicles, buses, parking
manoeuvres, lane widths, area type, grade, and turning movements.
Transportation x
Services Division
Semi-actuated A signal operation in which signals will not change to the side street
Mode of Control unless a vehicle or pedestrian has been detected, and in which the
(SA) side street display and display time varies depending on whether a
pedestrian call has been received or not.
Semi-actuated A signal operation in which signals will not change to the side street
Pedestrian Mode unless a vehicle or pedestrian has been detected, and in which the
of Control (SAP) side street will serve the pedestrian "walk" phase regardless of
whether or not a pedestrian call has been received.
Semi-actuated A signal operation in which there is no pedestrian crossing across the

Vehicle Mode of main street and side street display and display time varies depending
Control (SAV) on vehicle call.
Separate Traffic A signal phasing sequence which would have the traffic signals cycle
Signal Phasing from the major street to permit traffic on only one of the minor street
legs to proceed, followed by traffic on the second minor street leg, then
back to the major street.
Split Cycle Offset An adaptive traffic control system that determines its traffic timing
Optimisation plans based on real-time information received from vehicle detectors
Technique located on the approaches to signalized intersections.
(SCOOT)
Split Phase A signal phasing sequence where one approach is given exclusive
right-of-way into the intersection followed by the opposing approach
being provided exclusive right-of-way into the intersection.
Streetcars Transit vehicles used along streetcar routes. Typical streetcar routes
can either operate separated from other modes of traffic, or share the
right-of-way with other users.
Traffic A section within the Transportation Services Division that is comprised

Management of six units: Traffic Safety Unit, ITS Operations, ITS Capital Projects
Centre (TMC) Planning & Delivery, Traffic Plant Installation & Maintenance,
Transportation Business Systems, and Signs & Markings.
Traffic Signals Electronic devices that are designed to assign the right of way to the
various traffic and pedestrian movements at a signalized intersection.
Transit Signal In Toronto, TSP is provided as transit pre-emption. Upon detection of

Priority (TSP) an approaching transit vehicle at a traffic signal, the controller may
invoke timing changes (e.g. early green or green extension), or it may
invoke phasing changes (e.g. servicing an actuated priority phase,
inserting a phase into the cycle, or rotating the phase within the cycle),
in order to reduce delay for an approaching transit vehicle.
Transportation xi
Services Division
Transportation A division within the City that maintains transportation infrastructure

Services Division including roads, bridges, sidewalks, and boulevards within the four city
(TSD) districts. TSD is responsible for all aspects of traffic operations,
roadway regulation, street maintenance, asset management, right of
way occupation and snow removal.
TransSuite Traffic A hybrid traffic control system that relies on second-by-second

Control System communication to monitor signal operations, but relies on field
(TransSuite TCS) equipment to maintain coordination (i.e. the field equipment can
maintain signal coordination for about 24 hours if there is a loss of
communication).
Urban Traffic A traffic control system that operates in tandem with SCOOT. UTC
Control (UTC) provides pre-determined signal timing plans and is used as a stopgap
measure if SCOOT is not available.
Walk Rest A type of operation installed at semi-actuated signalized intersections

Modifier (WRM) to increase operational efficiency by allowing the signals to return to
the main street "walk" display if the side street right-turn vehicle
demand clears prior to the start of the main street amber.
Transportation xii
Services Division
Executive Summary
Toronto is the largest city in Canada and the fourth largest city in North America. It is a global
centre for business, finance, arts and culture, and home to a diverse population of 2.8 million
people. The city is served by a road network consisting of 40 km of expressways and over 5,600
km of roads. There are approximately 2,300 traffic signals on the road network.
The City of Toronto uses capacity analysis software to conduct operational and planning
analyses of its transportation network. The health of the network can be assessed at both the
intersection and network level. Measures of effectiveness (MOEs) are outputted from the
software to provide study-specific quantitative indications at the local and network levels. From
these MOEs, operational and planning strategies can be developed to promote smooth and
efficient traffic movement through the intersection and along the network.
Synchro is the macroscopic analysis and optimization software that the City uses to conduct
these operational and planning analyses. The "Guidelines for Using Synchro 9 (including
SimTraffic 9)" was developed to provide guidance for City staff and consultants working for the
City when developing transportation models and conducting traffic analysis using Synchro
Version 9.0 (or later).
All traffic analyses performed by the analyst using Synchro Version 9.0 (or later), shall conform
to the Guidelines outlined in this document. All assumptions contained within this Report are
consistent with the City of Toronto's Traffic Signal Operations Policies and Strategies (May 7,
2015).
Chapter 1 of this Report provides an overview of the application of Synchro analysis within the
City; Chapters 2 through 9 of this Report provides detail of all relevant input and output
parameters presented within the Synchro interface, and provides details on the following
methodologies:
 Highway Capacity Manual 2000 (HCM 2000);

 Highway Capacity Manual 2010 (HCM 2010):
 Automobile mode;
 Pedestrian mode;
 Bicycle mode; and
 Synchro/ICU methodology.
Chapter 10 of this Report provides additional details on particular conditions which require
in-depth analysis; Chapter 11 provides additional details regarding SimTraffic methodology; and
Chapter 12 discusses the MOEs to be reported to the City.
Working Synchro files must be submitted to the City so that staff can review the network that
was created and all the intersection input parameters. It is the responsibility of the analyst
undertaking the analysis to discuss the scope of work, analysis methodologies to be used, and
Transportation xiii
Services Division
the measures of effectiveness to report with City staff on a case-by-case basis, prior to
proceeding, in order to properly assess the analysis requirements.
Transportation xiv
Services Division
INTRODUCTION
1.1. Background
All traffic analyses performed by analyst using Synchro Version 9.0 (or higher), shall conform to
the Guidelines outlined in this document. The modelling of existing conditions may require
variances to some of the following Guidelines to provide an actual representation of existing
conditions. These variances must be discussed with City staff prior to proceeding.
All assumptions contained within this Report are consistent with the City of Toronto's Traffic
Signal Operations Policies and Strategies (May 7, 2015). If discrepancies between these two
documents exist, the assumptions presented within the Toronto Official Policy hold precedent. It
is the responsibility of the analyst undertaking the analysis to discuss any discrepancies of
assumptions with City staff prior to proceeding.
The working Synchro files must be submitted to the City so that staff can review the network
that was created and all the intersection input parameters. Any analysis not conforming to these
Guidelines (unless agreed otherwise with the City) will be rejected and a complete re-
submission may be required.
1.2. Planning vs. Operational Analysis
Planning techniques are used for longer-range projects and for assisting in the determination of
the type of facility and its basic dimensions. Therefore, planning analysis is limited to existing
and proposed signals analyzed in a transportation impact or environmental assessment study.
For planning purposes, it is possible to obtain an approximate level of service through the
judicious use of assumed values for most of the model inputs. The only site specific data
required are the traffic volumes and number of lanes for each movement together with a
minimal description of the signal design and other operating parameters. In some
circumstances, where the intersection is approaching or is at capacity, the use of more site-
specific parameters may be appropriate. Under such cases, the use of assumed values must
be discussed with City staff. Site-specific data regarding pedestrians, bicycle use and transit use
may also be critical in planning analysis, particularly when dealing with multi-use developments,
higher development densities, and proximity to higher-order infrastructure.
Operational procedures deal with a detailed assessment of operating conditions within a

relatively short time frame when all factors are known or can be reasonably estimated.
Therefore, operational analysis should be performed for existing signals. When Synchro is used
for operational purposes, more site-specific data and other operational parameters must be
considered.
A transportation impact or environmental assessment study could include both types of analysis
– an operational analysis for existing conditions and a planning analysis for proposed
conditions.
1.3. General Information on Data Requirements and Synchro Calculated Values
Generally, the fields that require input (the numeric portions) will be black in colour and will be
discussed further in these Guidelines. Numeric fields that are blue have been calculated by the
Transportation 1
Services Division
software and do not normally require adjustment. For many of the Synchro calculated values,
this document refers the reader to the Synchro Manual for detailed information (by pressing the
“F1”, the user can access a “PDF” copy of the manual). This document discusses the cases in
which the City may accept values that override the software calculated values. Any numeric
fields that are red in colour would have been overwritten by the Synchro user, or indicate a
violation generated by the software, for example, a split that does not protect the minimum
pedestrian clearance times. To cancel overwritten values and restore the Synchro calculated
values to a field, the user should press the “F12” key while in the appropriate field.
MAP SETTINGS
Any City network must be created using metric units. Link distances must be verified by some
independent means such as field measurement, recent aerial photographs (including Google
Earth) or recent scaled maps. Link distances must reflect the distance from the middle of one
intersection to the middle of another, and not from stop bar to stop bar. The map must reflect
the existing geometric layout as accurately as possible, especially features such as road
narrowing, mid-block driveways, two-way left turn lanes (TWTL) and bus bays.
Transportation 2
Services Division
LANE SETTINGS
3.1. User Inputs
3.1.1. Changing the Name of the Approach Direction
The naming convention for each movement and approach is automatically generated by
Synchro based on the network geometry provided, where North is located at the top of Map
View. Where the road network is drawn diagonally along the x and y axes, the automatically
generated directions may not meet the appropriate naming conventions, and Synchro may
mislabel a movement (e.g. labeling a through movement as a left turn) which may impact the
analysis of that movement (e.g. incorporating Left Turn Factor in the calculation). The name of
an approach can be manually inputted, in order to reclassify a diagonal approach into an
orthogonal approach, by right-clicking on the movement images for that approach, and selecting
a new direction. Selecting a direction already in use by another approach will cause the other
approach to automatically select a new direction. The analyst should assign N/S and E/W based
on what the City prescribes on the relevant timing card(s).
Transportation 3
Services Division
Changing the Name of an Approach Direction is not appropriate if the intersection is skewed
such that the approach legs are irregularly spaced. See the example below of the intersection of
Danforth Road and Birchmount Road, where Danforth Road intersects Birchmount Road at an
angle much less than 90 degrees, and therefore should not be renamed, as it will impact the
analysis.
Figure 3-1. Irregular Intersection - Danforth Road and Birchmount Road
3.1.2. Lanes and Sharing
To enter a movement that the lane diagram does not allow, such as at unconventional
intersections, volume data can still be entered and the lane diagram will automatically be
updated in the “Map Window”. For example, for an intersection with an EB approach, a one-way
NB approach and a lane turning SB, the EB right turn volumes can be entered and the software
will generate a new lane.
3.1.3. Traffic Volume (vph)
3.1.3.1. “Supply” Volumes
Existing traffic volumes must be current volumes (not older than two years) obtained from the
City’s Traffic Safety Unit (TSU). If TSU current volumes are not available, then the analyst can
undertake its own traffic counts. Unless otherwise specified, the volumes supplied by the TSU
are intersection volumes that have been counted at the stop lines. These “supply” volumes
cannot exceed the capacity “supplied” by geometric and signal timing considerations. The
volume/capacity (v/c) ratio of movements, based on “supply” volumes, should not be greater
than 1.0. Section 3.1.3.2 provides the City's approach to adjusting traffic volumes to allow the
analysis of truer intersection demand, which can result in v/c's greater than 1.0. Section 5.3.1
discusses the situations in which Synchro may generate v/c ratios greater than 1.0.
Transportation 4
Services Division
If the analyst undertakes its own counts, then such counts must be done under the same
conditions under which the proposed signal is to operate. For example, an analyst should not
undertake counts during the summer vacation for a proposed signal at the entrance to a college
or university campus, because such counts would not be reflective of normal operation.
For illegal movements that may be encountered in the field, for example, right turns on a right
turn on red (RTOR) prohibition, the approach would be to conduct the analysis in three ways:
 Existing conditions, including non-compliance;

 Existing conditions, assuming full compliance; and
 Proposed conditions, assuming full compliance.
For the non-compliance situation, saturation flow must be measured in the field and the value
manually entered into Synchro.
3.1.3.2. “Demand” Volumes
In the event of oversaturation, the number of vehicles arriving at an approach can be

substantially greater than the number of vehicles that can be discharged. Similarly, projected
traffic volumes can exceed approach capacity. The capability of the intersection to discharge
such traffic demand can be evaluated only if approaching volumes are used. In such situations
the v/c ratio may exceed 1.0.
To ensure that major intersections are properly analyzed, regardless of whether for operational
or planning studies, the City has developed an approach to adjust the intersection volumes
using upstream data to reflect approach demand. The approach requires the volumes from a
minimum of one upstream signal to be included in the analysis of any major intersection.
The methodology of "volume balancing", which is conducted to through movements (but not to
turning movements) involves the following steps:
1) Identify locations that have a volume imbalance greater than 10%

2) Determine land uses and presence of accesses within the areas where imbalances are
greater than 10%
3) Based on the land use, accesses and local knowledge, determine if the imbalance is
justified
4) If the imbalance is not justified, then volumes will be balanced using the major/major
intersection as reference for balancing the smaller intersections within 10%, using the
following assumptions:
a) If Major/Major volume is greater than adjacent Major/Minor intersection volume, then
increase the Major/Minor through volume
b) If Major/Major volume is less than consecutive adjacent Major/Minor intersection
volumes, then increase the Major/Major volume
c) If Major/Minor is imbalanced with consecutive adjacent Major/Minors, increase or
decrease accordingly
d) In general, Major/Major volumes should not be lowered to accommodate volume
balancing
Transportation 5
Services Division
Since this approach can lead to the volumes exceeding the available capacity at an intersection,
then it is possible for the v/c ratio to exceed 1.0, and Synchro parameters (such as Saturation
Flow Rate, Lost Time, Peak Hour Factor) should not be adjusted to artificially lower the v/c to
hide any capacity problems.
An acceptable alternative approach involves using the volumes supplied by the TSU, and
supplementing the data by monitoring residual queues. Data on residual queues should be
counted on a cycle by cycle basis and then averaged over the analysis period. Data collection
should be treated similarly to a left-turn study, where the number of vehicles, waiting at the start
of a phase but unable to clear during each cycle, is counted. The number of cycles taken for
back of queue vehicles to clear the intersection should also be recorded. Alternatively,
additional traffic counts should be conducted at upstream locations away from any queuing,
provided that there is no significant sink or source in between.
3.1.4. Link Distance (m)
Link distances must be to scale and must not be overwritten as Synchro uses this data to
calculate travel time. Link distance is measured from centre of intersection to centre of
intersection.
3.1.5. Link Speed (km/h)
The speeds assigned to a link must match on-street regulatory speed limits.
3.1.6. Travel Time (s)
This value represents the free flow travel time from node to node and is calculated by the
software. It must not be overwritten.
3.1.7. Ideal Saturated Flow (vphpl)
The report “Saturation Flow Rates in the City of Toronto” specifies a default ideal saturation flow
of 1900 passenger car per hour of green per lane (pcphgpl). This default saturation flow must be
used for Synchro analysis.
In the absence of field measured saturation flows, a number of adjustment factors must be
considered and, if applicable, applied to adjust the Ideal Saturated Flow values on each
approach lane of the intersection. User judgement must be applied; the goal is to ensure that
saturated flow replicate field conditions as much as possible. These adjustment factors are
shown in the “Lane” and “Volume” Windows.
Saturation flow adjustment factors need not be applied if the saturation flows have been
measured for the particular movement.
Transportation 6
Services Division
The following conditions are applicable for field measured saturation flows:
 A proposed Saturation Flow based on a one day saturation flow study would not be
accepted unless it is factored down by 5 %;
 The “factoring down” would be waived if at least three studies were undertaken for the same
movement on different days of the same week or over three consecutive weekends for
weekend studies; and
 In case of doubt of the veracity of the study, the City could request details of the saturation
flow study.
Although rates above the City’s stipulated values are possible, they are not recommended for
use in planning or operational design. Traffic patterns and characteristics may change over
time so typical or conservative values should be used to account for this possible variability.
Regardless of any field studies, the City will not accept values in excess of the following:
 Through movement: 2005 pcphgpl;

 Left Turn Green Arrow: 2050 pcphgpl;
 Double Left Turn Green Arrow: 2000 pcphgpl; and
 High Occupancy Vehicle (HOV) lane: 1680 pcphgpl.
3.1.8. Lane Width (m)
Actual lane widths should be entered. If lane widths are not available, the following default
values can be applied:
 3.5 metres for through lanes;

 3.0 metres for left-turn lanes; and
 3.0 metres for right-turn lanes.
Any lane width greater than 4.8 metres is entered as two lanes. The City’s “Vehicle Travel Lane
Width Guidelines” is available is on the City’s website.
3.1.9. Grade (%)
A default value of 0 is used if the grade is relatively flat. Where there is a noticeable grade, the
analyst should determine the grade or use a value that is acceptable to the City.
3.1.10. Area Type
There are four operational districts in Toronto – Etobicoke/York, North York, Toronto/East York
and Scarborough. Virtually all signalized intersections in the downtown area of the Toronto/East
York District, and some intersections in outlying high activity areas, are generally classified as
belonging to a Central Business District (CBD) environment. Signalized intersections in areas
other than those noted above are generally classified as belonging to a non-CBD environment.
In uncertain situations, City staff must be consulted, since in these circumstances, the use of the
CBD/non-CBD environment will be assessed on a case by case basis. Synchro conforms to the
Highway Capacity Manual 2000 (HCM 2000) and applies an internal adjustment of 0.9 to the
Ideal Saturated Flow for CBD environments.
Transportation 7
Services Division
CBD characteristics are:
 Narrow street rights-of-way;

 Frequent parking manoeuvres;
 Frequent traffic congestion;
 Vehicle blockages;
 Abundant taxi or bus/streetcar activity or both;
 Small radius turns;
 Shared through/left lanes;
 High pedestrian activity;
 Dense population (high rise apartments, condominiums or offices);
 Mid-block curb cuts;
 Closely spaced intersections (<150 metres); and
 One way streets.
All these characteristics may not necessarily be present for an intersection to be deemed CBD.
City staff must be consulted in uncertain situations.
3.1.11. Storage Length (m)
Actual storage lengths must be entered. The storage length excludes the taper. If the left or right
turn lane goes all the way back to another intersection, enter "0". If two or more storage lanes
are present, enter the average length of the lanes, not the sum. Storage length is used for
analyzing potential blocking problems in SimTraffic such as through traffic blocking left turn
traffic, and left turn traffic blocking through traffic. If "0" is entered, no blocking analysis is
performed.
3.1.12. Storage Lanes (#)
This value only appears when the storage length is greater than 0. By default, the number of
storage lanes is equal to the number of turning lanes. This field can be overwritten so that some
of the turning lanes are full travel lanes, or some of the through lanes can be storage lanes.
3.1.13. Right Turn Channelized
This field is active for the rightmost movement. If there is no right turn channel, the default of
“None” should be used. This field is not used by Synchro for calculating measures of
effectiveness (MOEs); however, it is used by SimTraffic for simulation. If there is a channelized
right turn, the available options are “Yield”, “Free”, “Stop”, and “Signal”.
3.1.14. Curb Radius
This field is only active if a right turn channel is defined. This field controls the graphics and
layout in SimTraffic. It is measured from the back of curb to the center point of the radius. The
software accepts values between the minimum of 4.5 metres and the maximum of 75.0 metres.
The City’s “Curb Radii Guidelines” is available is on the City’s website.
Transportation 8
Services Division
3.1.15. Add Lanes (#)
This field is only active if a right turn channel is defined. This field allows the user to add
receiving lanes (where traffic can move freely) for the right turn channel. If a value of 0 is used,
no receiving lanes are added and traffic in the right turn channel must yield or merge into the
receiving lanes.
3.1.16. Right Turn on Red (RTOR)
A check mark in this field is applied except in a situation where right turns on red are prohibited
by regulation.
3.2. Synchro Calculated Values
3.2.1. Lane Utilization Factor
Traffic lanes are not equally utilized because of vehicles stopping in the curb lane, the absence
of right turn and/or left-turn lanes, the presence of a HOV lane, vehicles wishing to turn right or
left, presence of street cars, road conditions and the presence of unused streetcar tracks. The
lane utilization factor (fLU) adjusts the saturated flow rate to account for the uneven distribution
of traffic between lanes. The default fLU values, calculated by Synchro, correspond with those
specified in Chapter 10 of the HCM 2000 (page 10-26, Exhibit 10-23) and are accepted unless
field studies show otherwise. If field observations confirm traffic is evenly distributed across all
lanes in a lane group, then a fLU of 1.0 can be used. Refer to Section 10.4 for a procedure for
HOV lane analysis or for analysis of situations where vehicles do not use lanes equally (in lane
groups with multi-lanes).
3.2.2. Right Turn Factor
The values calculated by Synchro are accepted unless field studies show otherwise. The right
turn factor represents how much interference from right turn traffic reduces the saturated flow
rate. If there is an exclusive right turn lane and the approach to the right has an exclusive left
turn phase, then right turn traffic can turn right on this phase using the protected right turn
factors.
3.2.3. Left Turn Factor (Prot)
Left Turn Factors for protected phases in Synchro can be overridden; however, these values
must not be changed.
3.2.4. Left Turn Factor (Perm)
Left Turn Factors for permissive phases in Synchro can be overridden; however, these values
must not be changed. Synchro uses a “Permitted Left Turn Factors Report” to calculate the
permissive left turn adjustment factor, and obtain information about the lanes and saturation
flow rates. It is roughly equivalent to the HCM 2000 “Supplemental Permitted Left Turn
Worksheet”.
Transportation 9
Services Division
3.2.5. Right Ped Bike Factor
The Right Ped Bike Ped Factor must not be overwritten unless supported by field studies.
3.2.6. Left Ped Factor
The Left Ped Factor must not be overwritten unless supported by field studies.
3.2.7. Saturated Flow Rate (Prot)
These values must not be overwritten unless supported by field studies. If field measured
saturation flow rate values are available, the sum of the flow rate for each lane in a lane group
should be input in the Saturated Flow Rate (ck). The protected and permissive values are
measured separately.
3.2.8. Saturated Flow Rate (Perm)
These values must not be overwritten unless supported by field studies. If field measured
saturation flow rate values are available, the sum of the flow rate for each lane in a lane group
should be input in the Saturated Flow Rate (perm). The protected and permissive values are
measured separately.
3.2.9. Saturated Flow Rate (RTOR)
Synchro automatically calculates saturation flow rate for RTOR. This flow rate is applied to a
movement whenever it has a red signal. The RTOR should not be manually overwritten unless
substantiated by field studies since overwritten values will not be updated when the volumes or
signal timings change.
Transportation 10
Services Division
VOLUME SETTINGS
4.1. User Inputs
4.1.1. Peak Hour Factor (PHF)
For both operational and planning analysis, to ensure the “worst case” conditions are analyzed
over a peak hour period, one of the following options is used when entering PHF values:
1) The “Peak Hour Factor Calculations Report” can be obtained from the TSU and applied;
2) The average PHF is applied to the whole intersection. If an individual movement or
approach has sharp peaking characteristics, then a PHF should be calculated and applied
for each movement or approach;
3) If a turning movement count was conducted in 15 minute intervals (independent from the
TSU), the highest 15 minute count can be multiplied by four and entered in the “Traffic
Volume” field. A value of 1.00 is entered in the PHF field;
 This is equivalent to calculating the PHF for the highest 15 minute count and using
the peak hour volume, since all variables are part of the PHF formula:
 PHF = V60 / (4 * V15).
4) If hourly volumes are entered and PHF data is unknown, as a default use PHF = 0.90 for the
morning and off-peak periods and 0.95 for the afternoon peak period for through
movements. Use a PHF of 0.90 for all periods for left turn phases; and
5) At signalized intersections near stadiums, arenas, transit facilities and major tourist
attractions, where there may be a heavy surge in traffic volume, the PHF must be reduced to
reflect the traffic flow rate during the peak demand period or use peak 15-minute flow rates
Transportation 11
Services Division
(using the method identified in item 3 above). The same would apply to signalized
intersections near industrial establishments where a shift change can cause a surge in
traffic.
4.1.2. Growth Factor
For operational analysis, no adjustment is necessary and a Growth Factor of 1.00 must be
used. For planning analysis, current volumes can be adjusted to show future volumes with the
Growth Factor. The Growth Factor, if any, is supplied by the City.
4.1.3. Heavy Vehicles (%)
Heavy vehicles are defined as those with more than four tires touching the pavement. The
number of heavy vehicles for each movement is shown on the counts provided the TSU.
Synchro applies a default of 2%, which can be edited to reflect actual field conditions.
4.1.4. Bus Blockages (#/hr)
In cases where there is a shared through/right turn lane, the number of buses that stop and
block traffic at a near-side bus stop must be entered.
In cases where there is an exclusive right turn lane or bus bay, if field observations show that
buses are queued up in the bus bay and the queue is hindering the flow of through traffic, then
the through lane saturation is adjusted accordingly. If buses merging from a right turn lane
hinders the flow of through traffic, then a similar adjustment is made to the through saturation
flow. An alternative technique is to enter the Bus Blockages in the right turn lane and then apply
30% of that value to the adjacent through lane. The Bus Blockage assumes an average
blockage of 14.4 seconds. If 30% of the bus blockages is applied to the through lane, then an
average delay of 4.32 seconds would be applied to the through lane for each occurrence.
4.1.5. Adjacent Parking Lane?
If there is on-street parking, apply a checkmark to the box for that approach. Selecting “No”
parking lane is different from “Yes” parking lane with zero manoeuvres per hour.
4.1.6. Parking Maneuvers
If a check mark was added to the “Adjacent Parking Lane” box, the number of parking
manoeuvres per hour for the affected lane group can be entered. The maximum number of
parking manoeuvres per hour is 100.
4.1.7. Traffic from Mid-block (%)
The default value for this field is zero. A value of zero indicates that 0% of the traffic is from
driveways and unsignalized intersections and all of the traffic came from the upstream signal. A
value of 50 indicates that 50% of the traffic is from driveways and unsignalized intersections.
The optimizer uses this information when calculating delays. If a link has a lot of traffic from mid-
block sources, then coordinating this link will not reduce delays as much as it will for other links.
Transportation 12
Services Division
4.1.8. Link OD Volumes
Link OD volumes are not normally used - no value is typically required for analysis – however,
link OD volumes can be useful in animating weaving lane changes within SimTraffic. This field
can be useful for closely spaced signals and for adjacent signals that are at on/off ramps to a
highway (diamond interchanges). This field allows the user to have control over the origins and
destinations of vehicles at adjacent signals i.e. the user can ensure the software does not
assign traffic exiting a highway at one signal and return to the highway at an adjacent signal.
4.2.1. Adjusted Flow (vph)
This value is equal to the entered volume divided by the Peak Hour Factor and multiplied by the
Growth Factor. The value must not be overwritten.
4.2.2. Traffic in Shared Lane (%)
Synchro will only assign data to this field if there is a combination of a shared through/turning
lane plus an exclusive turning lane. Synchro uses this field to assign a percentage of the turning
traffic to the shared/turning lane since not all turning traffic will use the exclusive turning lane.
The assignment of traffic to the shared lane is between 10% and 90% of the turning traffic. If
field observations show a greater percentage of traffic using the shared lane than is assigned by
the software, it is possible to override the value applied by the software. Changes to this field
will impact Synchro calculated MOEs; changes to this setting will not impact the simulation in
SimTraffic.
4.2.3. Lane Group Flow (vph)
The Lane Group Flow shows how volumes are assigned to lane groups. The value must not be
overwritten.
Transportation 13
Services Division
TIMING SETTINGS
5.1. Node Settings - User Inputs
5.1.1. Node#
A signal’s identification number, known as a PX number, is provided in the signal timing report
issued by the City – it should be entered. Otherwise, the software automatically assigns a node
number.
5.1.2. Control Type
The mode of control (MOC), which is included with the signal timings information provided by
the City’s Traffic Signal Operations Group (TSOG) unit, is used in selecting the appropriate
controller type. The MOC for existing signals in the City must remain the same during
intersection analysis. The “Actuated-Coordinated” option is normally selected from the following
control types:
 “Pre-timed” for fixed timed intersections with no callable movements;

 “Actuated-Uncoordinated” for fully actuated intersections (where all movements are callable)
and no signal coordination is provided;
 “Semi-Actuated Uncoordinated” for signals where the side street is actuated, but no
coordination is provided; and
 “Actuated-Coordinated” for semi-actuated intersections or for pre- timed intersections with
callable left turn phases.
Transportation 14
Services Division
The City does not have fully actuated signals (FA) so the “Actuated-Uncoordinated” is not be
used. The City uses the following modes of control:
1. Fixed Time (FXT) – A signal operation in which the vehicle and pedestrian signal displays
automatically alternate between the main street and the side street, regardless of vehicle
and pedestrian demands.
2. Semi-actuated Pedestrian (SAP) – A signal operation in which signals will not change to
the side street unless a vehicle or pedestrian has been detected, and in which the side
street will serve the pedestrian "walk" phase regardless of whether or not a pedestrian call
has been received.
3. Semi-actuated Type 2(SA2) – A signal operation in which the signal displays will not
change to the side street unless a vehicle or pedestrian has been detected. At SA2
locations, the pedestrian "walk" phase will only be served for the callable side streets if a
pedestrian call has been received.
4. Semi-actuated Vehicle (SAV) – A signal operation in which there are no main street
pedestrian crossings and there are no pushbuttons.
5. Pedestrian Actuated (PED) – A signal operation at Mid-block Pedestrian Signals (MPS)
only, where the mid-block pedestrian crossing is actuated by a pedestrian pushing a button.
5.1.3. Cycle Length
The cycle length may be entered in the “Cycle Length” field; however, Synchro adds the total
splits to calculate the cycle length automatically. If new traffic signals are being included in the
network, existing control area issues must be considered in determining cycle lengths for the
proposed signals (i.e. what cycle lengths are being used by existing adjacent signals? Are
adjacent signals coordinated? Are adjacent signals closely spaced?). If signals are spaced
within 150 metres, providing coordination becomes critical for motorist safety and traffic flow. If
signals are spaced over 800 metres apart, vehicle platoons become more dispersed between
the signals and providing coordination is less important.
In the downtown area, where most intersections have three or four phases, the City maintains
consistent cycle lengths between major and minor intersections with a maximum of 80 seconds
in the morning and afternoon peak periods, and 70 seconds in the off-peak period, except on
arterials where long pedestrian crossing distances dictate the need for longer cycle lengths,
such as University Avenue and Spadina Avenue.
In suburban areas, where intersections with more than four phases are more common, the City
restricts the maximum cycle length at major intersections to the 125 – 135 seconds range,
based on 1.0 m/s walk speed.
Refer to the City's Traffic Signal Operations Policies and Strategies, Section 5.5 (May 7, 2015)
for more detail.
5.1.4. Lock Timings
The “Lock Timings” box should only be checked if the user does not want to allow that specific
intersection’s timings to be changed i.e. if a Synchro network is created and the user intends to
optimize the entire network’s timings.
Transportation 15
Services Division
5.1.5. Offset
The offset should be entered in this field; the offset is included with the signal timings provided
by TSOG. When signals are spaced less than 150 m, then the main street ambers should be
programmed to maintain a fixed offset relationship. City staff often develop offsets to ensure the
adjacent main street signals display their ambers simultaneously to ensure motorists do not
misinterpret the signal displays at adjacent signalized intersections.
Main street through traffic volumes are typically used to determine which direction to favour
when selecting offsets. There are cases where it may be desirable to coordinate one signal’s
turning movement with another signal’s through movement - particularly if signals are closely
spaced. As a general rule, if one direction has greater than 55% of the total through traffic
volume (for through volumes in opposing directions), the direction with the greater volume is
favoured when developing the offset.
Refer to the City's Traffic Signal Operations Policies and Strategies, Section 5.7 (May 7, 2015)
for additional information on signal coordination.
5.1.6. Referenced to
The values below should be used for the following timer types:
 TS2-1st Green: for Epac and Peek ATC1000 timers

 Begin of Green: for Econolite and Peek 3000 timers
5.1.7. Reference Phase
This field refers to the coordinated phases. The main street coordinated phases should typically
correspond with phases “2+6”.
5.1.8. Master Intersection
For most analyses, it is not necessary to designate a Master Intersection. The Master
Intersection is used in Synchro to reference offsets to the cycle counter at that intersection – its
offset will always be zero.
5.1.9. Yield Point
The user can select “Single”, “Flexible” or “By Phase”. The “Single” option is the default in
Synchro and must not be changed.
5.1.10. Mandatory Stop On Yellow
By default, SimTraffic allows at least two vehicles to proceed during a signal phase. By checking
the box, no sneaker vehicles will be allowed during the yellow interval. This parameter does not
impact results within Synchro.
Transportation 16
Services Division
5.2. Timing Settings - User Inputs
Existing signal timings and MOC must be current data obtained from TSOG. The timing
information must not be more than six months old when used in the analysis.
5.2.1. Turn Type
The Left turn types available in Synchro and applicable to the City include:
 Split (left and through traffic share a protected phase);

 Permitted (vehicles must yield to pedestrians and oncoming traffic);
 Protected (movement is made on left turn signal and there are no conflicts with oncoming
traffic and pedestrians) ;
 Protected and Permitted (left turns move on a left turn signal and then on a permitted
phase);
 NA (used where left turns are prohibited); and
 Custom (non-standard phase combination).
Other Left turn types available in Synchro include Dallas Permitted and Dallas Permitted plus
Protected. These are used to represent signals with special left turn signal heads, which display
the same phase information to oncoming traffic. These configurations are used to eliminate the
lagging left turn trap problem. The City does not use these configurations.
The Right turn types available include:
 Permitted (right turns yield to pedestrians during green ball);

 Protected (right turns are unimpeded by vehicles or pedestrians);
 Overlap (right turns go on a compatible left turn phase);
 Permitted plus Overlap;
 Protected plus Overlap;
 Free (used if a right turn channelization and acceleration lane exist; “F” should be coded in
the permitted phase; this should not be used as a substitute for Right Turns on Red – refer
to Section 3.1.15);
 NA (used where right turns are prohibited); and
 Custom (non-standard right turn phases).
Transportation 17
Services Division
5.2.2. Protected & Permitted Phases
The diagram below shows the phase numbers normally assigned to different movements,
depending on the direction of the main street.
5.2.3. Detector Phases
The default values must be retained. If a movement is served by more than one phase, the
“Detector Phases” can be overridden to specify that only one of the phases is connected to the
detector. The Synchro split optimizer assigns green time based on the first listed detector
phase.
5.2.4. Switch Phase
The default value for this field is 0. This “Switch Phase” is a secondary phase that extends the
entered phase when it is green. This setting does not place a call and does not call the primary
Detector Phase when the entered switch phase is green. This setting can be used for the
permitted phase of a permitted plus protected left turn.
5.2.5. Leading Detector and Trailing Detector
Leading and trailing detector data should be entered in the “Detector Settings” screen, as a
correct sequence must be followed for the City’s default values to be accepted in Synchro.
Refer to Sections 7.1.3 and 7.1.4.
5.2.6. Minimum Initial
The Minimum Initial time is the minimum green time for the phase. Absolute minima are:
a) Protected Turn Phases – Minimum of 6.0 seconds

b) Side Street Through Phases – Minimum of 7.0 seconds
c) Main Street Through Phases – Minimum of 12.0 seconds
In addition, when determining minimum vehicular green times, the percentage of heavy vehicles
should also be reviewed on an intersection-by-intersection basis. A high percentage of trucks
may necessitate increasing the minimum green time by time of day.
Transportation 18
Services Division
At Semi-actuated (SA2) or Semi-actuated Vehicle (SAV) intersections with a very wide main
street and high bicycle traffic on the side street, increasing the minimum green time, as per OTC
Bicycle Traffic Signals Guide (2015), should be considered.
5.2.7. Minimum Split
Adequate green times must be provided to satisfy the minimum pedestrian crossing time (Walk
+ Flashing Don’t Walk). Intersection specific Walk and Flashing Don’t Walk durations are
provided by TSOG when signal timing information is requested.
Due the communication lag between field equipment and the controller, an extra second must
be added above the minimum pedestrian crossing time when calculating the minimum split. The
default minimum splits should be calculated as follows:
a) Protected Turn Phases = Minimum Split (6.0 seconds) + Yellow + All-Red + 1

b) Through Phase with Pedestrian Timings = Walk + FDW + Yellow + All-Red + 1
c) Through Phase without Pedestrian Timings = Minimum Split + Yellow + All-Red + 1
Refer to Section 6.1.6 and 6.1.7 for additional information on Walk and Flashing Don’t Walk
times.
5.2.8. Total Split
The total split time is the total phase time including the green, yellow, and all-red time.
5.2.9. Yellow Time
Clearance values for through phases must comply with the Ontario Traffic Manual, Book 12. In
the absence of current speed data, the posted speed shall be used as the design criteria. The
minimum amber interval for a through phase is 3.0 seconds.
The standard amber clearances for left turn phases are:
 Fully Protected Left-Turns – 3.0 seconds;

 Protected/Permissive Left-Turns – 3.0 seconds; and
 T-intersection – 3.0 seconds.
5.2.10. All-Red Time
Clearance values for through phases must comply with the Ontario Traffic Manual, Book 12. In
the absence of current speed data, the posted speed shall be used as the design criteria. The
minimum all-red clearance for a through phase is 2.0 seconds.
For mixed traffic phases with a high proportion of bicycles, the vehicular all-red interval may be
increased by up to 1.0 second to accommodate bicycle traffic.
Transportation 19
Services Division
The standard all-red clearances for left turn phases are:
 Fully Protected Left-Turns – 2.0 seconds (less than 3 lanes), 3.0 seconds (3 or more lanes);
 Protected/Permissive Left-Turns – 1.0 second; and
 T-intersection – 2.0 seconds.
Refer to the City's Traffic Signal Operations Policies and Strategies, Section 5.3.3 (May 7, 2015)
for additional information on all-red time for bicycle traffic. For exclusive bike phase, refer to
OTC Bicycle Traffic Signals Guide (2015) Chapter 3.
5.2.11. Lost Time Adjust
The following Lost Time Adjustment default values are used:
 For off peak analysis, use 0; and

 For peak period analysis, use -1.
The above is based on the formula:
Lost Time Adj. = Start Up Lost Time - Extension of Effective Green, where:
 Start Up Lost Time is two seconds; and
 Extension of Effective Green is two seconds for off peak and three seconds for peak
conditions.
5.2.12. Lagging Phase
In protected/permissive combinations, the protected phase should typically be a “Lead” phase.

For safety reasons, the City of Toronto does not normally use lagging left turn phases. Lagging
phases are only used in the City of Toronto if they are fully protected.
5.2.13. Allow Lead/Lag Optimize?
As a default, no check mark is applied. If a check mark is applied, then the splits are optimized
in Synchro and Synchro will be allowed to designate left turn phases as either leading or
lagging.
5.2.14. Recall Mode
If a signal is operating as fixed/pre-timed, the default for all the phases is “Max”. If a fixed/pre-
timed signal has a callable advance left turn phase, the callable movement is coded as “None”;
this causes the controller type to change automatically to “actuated/coordinated”.
If an intersection is actuated-coordinated, the default for the coordinated phase is “Coord”. The
options for the side-street include: “None”, “Min”, “Ped”, and “Max”. Typically, “None” is selected
for the side streets at semi-actuated intersections. The other options should only be used if an
intersection cycles (and the side-street is served regardless of vehicle and/or pedestrian
demand).
Transportation 20
Services Division
The results shown within the Timing Settings window represent analysis results using Synchro
methodology, and do not necessarily equal to the results using HCM 2000 methodology. It is the
responsibility of the analyst undertaking the analysis to discuss the analysis methodologies to
be used. Please refer to Section 12 for more detail.
5.3.1. Volume to Capacity Ratio
An approach value of v/c greater than 1.0 indicates that the approach is oversaturated. A value
of v/c between 0.90 and 1.00 represent near capacity conditions. When an analysis of actual
volumes at an existing signalized intersection results in v/c values greater than 1.00, it implies
that input parameters may need adjusting. The model must be calibrated to reflect the existing
situation.
Some of the reasons Synchro software may generate a v/c over 1.00 include the following:
 The City's approach for adjusting volumes discussed in Section 3.1.3.2 is applied;
 The turning movement count volumes (TMC) contain errors;
 The TMC is correct, but timing changes were made since the count was done (for example,
the previous phase duration may have permitted 1000 vehicles to clear, but the existing
phase duration may only allow 800 to clear);
 The default values (Ideal sat flow of 1900, start-up lost time, extension of effective green,
etc.) may not be suitable at this location. To find out for certain, it is possible to conduct field
studies and use field measured data to replace the default values in the analysis;
 The Synchro methodology may not be applicable for certain applications, for example,
analysis of SCOOT (traffic adaptive) signals; and
 If demand volume is greater than supply volume i.e. the intersection is operating above
capacity.
If field observations indicate aggressive driving and vehicles encroaching on the subsequent
phases, then the effective green times for the subsequent phases must be reduced accordingly
(by adjusting the Lost Time Adjust field). Adjusting the saturation flow would not be acceptable
under such circumstances since it would imply that conflicting movements could travel through
the intersection simultaneously. Any modifications to the saturation flow must be supported by
surveys of the intersection to confirm that individual movements do not use up green time from
following conflicting phases.
5.3.2. Queue Length 50th & 95th (m)
The “Queue Length 50th (m)” field represents the maximum back of queue with 50th percentile
traffic volume (i.e. during a typical cycle), in metres. The “Queue Length 95th (m)” field
represents the maximum back of queue with 95th percentile traffic volume, in metres. The
calculations for both 50th and 95th percentile queue are the same, where the only difference is
the volume assumed for the analysis. The 50th percentile volume is equal to the Adjusted Flow
for that lane group, and the 95th percentile volume is calculated based on the following
calculation shown within the Synchro 9 Manual, page 17-22:
Transportation 21
Services Division
v95 = v * PHFx * [1 + 1.64 * (sqrt (vc) / vc)], where

- v95 = 95th Percentile Volume
- v = Arrival Flow Rate = 50th Percentile Volume
- PHFx = peak hour factor (assumed min of 0.9)
- vc = vehicles per cycle = v * C / 3600
- C = cycle length
The ‘~’ and ‘#’ footnotes indicate that the volume modeled exceeds capacity. The ~ footnote
indicates that the approach is above capacity and the queue length could be much longer. The
queue length is theoretically infinite and blocking problems may occur. The value shown for the
50th percentile queue is sufficient to hold one cycle of traffic. This will prevent capacity problems
from being compounded by insufficient storage space.
The # footnote indicates that the volume for the 95th percentile cycle exceeds capacity. This
traffic was simulated for two complete cycles of 95th percentile traffic to account for the effects of
spillover between cycles. If the reported v/c <1 for this movement, the methods used represent
a valid method for estimating the 95th percentile queue. In practice, 95th percentile queue shown
will rarely be exceeded and the queues shown with the # footnote are acceptable for the design
of storage bays.
The presence of both the ‘~’ and ‘#’ footnotes suggests that vehicle queuing may extend into
upstream and/or downstream intersections or block access to auxiliary turn lanes, resulting in
gross overestimation of intersection and network capacity. This situation can be prevalent on
streets with closely-spaced signals. Macroscopic intersection capacity analysis methods such
as Synchro do not account for the potential impact of downstream congestion on intersection
operations, nor do they detect and adjust for the impact of turn pocket overflows on through
traffic and intersection operations.
The ‘m’ footnote indicates that volume for the 95th percentile queue is metered by an upstream
signal.
In many cases, the 95th percentile queue will not be experienced due to upstream metering. If
the upstream intersection is at or near capacity, the 50th percentile queue represents the
maximum queue experienced. Similarly, if the upstream intersection has a v/c ratio over 0.8; the
maximum queue is approximately equal to the 50th percentile queue divided by the upstream v/c
ratio. For example, if the 50th percentile queue is 45 metres, and the v/c ratio upstream is 0.90;
the maximum possible queue would therefore be 45 / 0.90 = 50 metres.
If these 95th percentile volumes at an upstream intersection (A) result in that intersection to
operate with a v/c ratio > 1.0 (i.e. if the queue results at intersection A show the # symbol), it is
theoretically impossible for these 95th percentile volumes to proceed to the following
intersection (B).
Therefore, since the 95th percentile volumes at the intersection of interest (B) would not occur,
neither would the 95th percentile queues.
Transportation 22
Services Division
PHASING SETTINGS
6.1. User Inputs
6.1.1. Vehicle Extensions (Maximum Gap)
The minimum vehicle passage time shall be as follows:
(a) Left-turn movements with setback loops – 2.0 seconds;

(b) Left-turn movements with stop bar loops – 2.5 seconds;
(c) Through/left-turn/right-turn movements on side street at semi-actuated intersections – 3.0
seconds; and
(d) Transit signal priority – 1.0 second.
6.1.2. Minimum Gap
The default value of three seconds should be retained if volume-density operation is not used.
Transportation 23
Services Division
6.1.3. Time Before Reduce
The default value of 0 should be retained. When using volume-density operation, this field
represents the amount of time before gap reduction begins.
6.1.4. Time to Reduce
The default value of 0 should be retained. When using volume-density operation, this is the
amount of time to reduce the gap from Vehicle Extension (or maximum gap) to Minimum Gap.
6.1.5. Pedestrian Phase
Set this field to “Yes” if there is a pedestrian phase for this movement. Setting Pedestrian Phase
to “No” will disable the pedestrian phase and the input fields for “Walk Time”, “Flash Don't
Walk”, and “Pedestrian Calls”.
6.1.6. Walk Time
The pedestrian minimum "walk" and clearance intervals shall be determined in accordance to
the modified form of the CCG method. The method is based on the provision of a minimum
"walk" duration of seven seconds.
for additional information on Walk Time.
6.1.7. Flashing Don’t Walk
The pedestrian minimum clearance intervals shall be determined in accordance to the modified
form of the CCG method. The method is based on the provision of a minimum pedestrian
clearance (i.e. Flashing Don't Walk – FDW) duration equal to a 1.2 m/s walk speed across the
entire pedestrian crossing. The total "walk" plus FDW interval should equal to a 1.0 m/s walk
speed across the entire crossing. The FDW does not extend into the amber or all-red interval.
for additional information on Flashing Don’t Walk Time.
6.1.8. Pedestrian Calls
The value entered in this field is the number of pedestrian push button calls per hour for the
phase. Data is required only if the intersection is equipped with pedestrian push buttons and the
phase is actuated/callable, therefore, fixed/pre-timed signals do not require data in this field.
The number of pedestrian calls per hour may not match the pedestrian crossing volumes
entered in the “Conflicting Pedestrians” field in the “Volume” window. In the absence of field
observations, the number of pedestrian calls can be estimated using the procedure on page 11-
7 of the Synchro Manual.
Transportation 24
Services Division
6.1.9. Fixed Force Off
The following default settings are used for the Fixed Force Off:
 For SCOOT signals equipped with interval-based controllers, all phases at fixed and semi-
actuated (SA2-VMG, SAP or SAV) intersections should have a check mark;
 For SCOOT signals equipped with phase-based controllers and for TransSuite signals, all
phases at fixed intersections and main street phases at semi-actuated (SA2-VMG, SAPLO
or SAV) intersections should have a check mark; and
 For SCOOT signals equipped with phase-based controllers and TransSuite signals, the side
street phases at semi-actuated (SA2-VMG, SAP or SAV) intersections should not have a
check mark.
DETECTOR SETTINGS
7.1. User Inputs
7.1.1. Number of Detectors
Detectors are numbered from the stop bar back per approach, with detector one starting at the
stop bar. If there is a fixed movement (i.e. the movements associated with phases 2 & 6), there
will be 0 detectors shown.
Transportation 25
Services Division
7.1.2. Switch Phase
The “Switch Phase” field is discussed in Section 5.2.4.
7.1.3. Leading Detector
The leading detector value is the distance from the leading edge of the most advanced detector
to the stop bar in metres. This allows the user to define where a detection zone begins in a lane
or lane group.
To ensure the City’s default values are accepted in Synchro, a correct sequence must be
followed when entering detector data in the software. Prior to entering the Leading Detector
data, the user should enter data in the Detector 1 Position (refer to Section 7.1.4). After data is
entered in the Detector 1 Position, the following default values should be entered in the Leading
Detector field (to replicate where the City typically installs detectors):
 For side street detection at actuated signals, stop bar loops are used where the leading
detector is normally located 7.5 metres from the stop bar;
 For fully protected left-turns, stop bar loops are used where the leading detector is normally
located 7.5 metres from the stop bar; and
 For protected/permissive left-turns, setback loops are used where the leading detector is
normally located 21.5 metres from the stop bar.
The above is based on the normal 9.0 metres long stop bar and setback loops. For situations
where there are legacy left-turn loops that are 3.0 metres or 5.0 metres long, adjustments need
to be made to the leading detector value.
Trailing Detector Value = –1.5 m Trailing Edge of Detector

STOP BAR
DETECTOR
Leading Edge of Detector

Leading Detector Value = +7.5 m
Direction of Travel
Side Street Detection at Actuated Signals

and Fully Protected Left-Turn Detection (Stop Bar Loop)
Transportation 26
Services Division
STOP BAR
Direction of Travel
Trailing Edge of Detector

Trailing Detector Value = +12.5 m
DETECTOR
Leading Edge of Detector

Leading Detector Value = +21.5 m
Protected/Permissive Left-Turn Detection (Setback Loop)
If there is more than one detector, for example, one setback loop has a leading edge 100
metres from the stop bar and the second loop has a leading edge 7.5 metres from the stop bar,
then the 100 metres value is entered. As discussed in Section 7.1.4, the detector field can be
edited.
Editing the Leading Detector value has no impact on Synchro’s MOEs but does affect the
dimensions of the detector loop that is animated in SimTraffic.
7.1.4. Trailing Detector and Detector 1 Position
This trailing detector value is the distance from the trailing edge of the trailing detector to the
stop bar in metres. This allows the user to define where a detection zone ends at or near the
stop bar in a lane or lane group. A negative value can be entered if the trailing detector extends
past the stop bar.
To ensure the City’s default values are accepted in Synchro, a correct sequence must be
followed when entering detector data in the software. Prior to entering the Leading Detector
data (Section 7.1.3), the user should enter data in the Detector 1 Position (but not in the Trailing
Detector field). After the user enters data in the Detector 1 Position field, the Trailing Detector
field will automatically reflect the correct value. The following default values should be entered in
the Detector 1 Position field:
 For side street detection at actuated signals, stop bar loops are used where the trailing
detector is normally located -1.5 metres from the stop bar;
 For fully protected left-turns, stop bar loops are used where the trailing detector is normally
located -1.5 metres from the stop bar; and
 For protected/permissive left-turns, setback loops are used where the trailing detector is
normally located 12.5 metres from the stop bar in left turn lanes.
Transportation 27
Services Division
If there is more than one detector for example, one setback loop has a trailing edge 95 metres
from the stop bar and the second loop has a leading edge -1.5 metres from the stop bar, then
the -1.5 metres value is entered.
Note that upon entering the Detector 1 Position, if the analyst clicks on the cell for Trailing
Detector the value will return to the Synchro default; by default, the maximum distance that the
trailing edge of the detector can extend past the stop bar is -0.2 metres. To achieve the required
detector size in Synchro with -0.2 metres for the Trailing Detector value, enter 8.8 metres in the
leading edge field.
7.1.5. Detector Size
When the City default detector data is entered (refer to Sections 7.1.3 and 7.1.4), the Detector 1
Size field will automatically be adjusted to replicate typical City detector sizes. Detectors are
generally 9.0 metres long for side street detection at actuated signals and for left turn lanes.
However, the City has legacy left-turn loops that are 3.0 metres or 5.0 metres long. If there is
more than one detector size, only then will the user be required to enter data in the Detector
Size field. Up to five detectors can be entered in the software.
7.1.6. Detector Type
The options for this field are Calling, Extend and Call+Extend. The default value is Call+Extend.
7.1.7. Detector Extend
This field represents how long a call on a detector will be held/extended for. Unless a detector
has an unconventional operation, the default value is three seconds.
7.1.8. Detector Queue
The default value for this field is 0. A value entered in this field will provide an initial extension
value on a phase (when it begins) for the time entered.
7.1.9. Detector Delay
The default value for this field is 0. A value entered in this field will delay placing a call on a
phase (after a vehicle arrives on the detector) until after the time entered has passed.
Transportation 28
Services Division
SIMULATION SETTINGS
8.1. User Inputs
“Lanes and Sharing”, “Traffic Volume”, “Storage Length” and “Storage Lane” data are already
entered in the “Lane Settings” window and do not need to be re-entered. Other values in this
Window do not impact the Synchro calculated MOEs but will be used for SimTraffic.
8.1.1. Taper Length
The value entered in this field affects the taper length displayed on the map in the “Map
Window”. In SimTraffic, the taper length determines when vehicles can enter the storage lane.
Default taper length in Synchro is 2.5 metres, but field measured values should be used.
8.1.2. Lane Alignment
This setting allows the user to specify whether lanes should align to the right or left through an
intersection. The options include; Left, Right, L-NA (left, no add), R-NA (right, no add). The
default is Right for right turns, Left for left turns and through, and Right-NA for U-turns. Refer to
the Synchro Manual for other lane alignment scenarios.
Transportation 29
Services Division
8.1.3. Enter Blocked Intersection
This field controls simulation modeling gridlock avoidance. The four options for modeling
blocked intersections are; “Yes”, “No”, “1 vehicle” and “2 vehicles”. The default value is “No” for
intersections and “Yes” for bends and ramp junctions. Change to “No” for high speed
approaches and movements.
8.1.4. Link Offset
If two legs of an existing intersection are offset by 10 metres or less, the Link Offset setting must
be used. If the two legs are further apart than 10.0 metres, the legs can be coded as separate
links. See Section 10.9 for additional information regarding offset intersections.
8.1.5. Crosswalk Width
Actual crosswalk widths should be entered. This distance is measured from the stop bar to the
far side of the crosswalk. If crosswalk widths are not available, the following default values can
be applied:
 4.6 meters for conventional intersections; and

 9.0 meters for mid-block/pedestrian signals.
8.1.6. Two-Way Left Turn Lane (TWLTL) Median
Adding a check mark to this field draws a TWLTL in the median. The TWLTL is visual only and
will not be used by vehicles in the Synchro model. Storage taper lengths still apply. Checking off
the TWLTL also sets the TWLTL for the reverse link. At the discretion of City staff, part of the
TWLTL can be used for left turn storage at an intersection.
8.1.7. Turning Speed (km/h)
Turning speed are 15 km/h for right turns and 25 km/h for left turns. Synchro does not use this
information. It is only used for SimTraffic.
Transportation 30
Services Division
HCM 2010 SETTINGS

Although some values from the previous settings windows translate over into HCM 2010
settings, it is recommended that data input for HCM 2010 analysis be input directly into the
HCM 2010 settings window and tabs. It is the responsibility of the analyst to ensure proper input
within the HCM 2010 settings window and tabs.
9.1. Signalized Intersections – Auto Mode
9.1.1. HCM 2010 Intersection Settings
9.1.1.1. Equilibrium Cycle (s)
This is the calculated Cycle Length based on the methods described within the HCM 2010. For
coordinated and pre-timed signals, this will be equal to the cycle length.
Synchro calculates this value.
Transportation 31
Services Division
9.1.1.2. HCM Control Delay (s)
This is the calculated control delay (s) for the entire intersection based on the methods
described within the HCM 2010.
9.1.1.3. HCM Intersection LOS
This is the calculated LOS for the entire intersection based on the methods described within the
HCM 2010. Control delay alone is used to characterize LOS for an entire intersection.
9.1.1.4. Saturation Flow Rate (pc/h/ln)
By default, this item will be displayed as an uneditable dash. If the Use Saturation Flow Rate
box is checked (see Section 9.1.1.5) then this value can be used to override the Saturation Flow
Rate for every moment at this intersection. Otherwise, each movement’s “Ideal Satd. Flow” can
be defined separately within the HCM 2010 Settings (Section 9.1.2).
Analyst should use saturation flow rate as defined in Section 3.1.7.
9.1.1.5. Use Saturation Flow Rate
Checking this box will allow the user to override the Saturation Flow Rate for every moment at
this intersection (see Section 9.1.1.4).
Analyst should use saturation flow rate as defined in Section 3.1.7.
9.1.1.6. Sneakers Per Cycle (veh)
This represents the number of vehicles that are served during the clearance intervals (ambers +
all reds) of a cycle. This could be field measured by the analyst preparing the study. The
acceptable range is from 2 to 10 vehicles, where values larger than 2 should be justified with
field studies.
9.1.1.7. Number of Calc. Iterations
The HCM 2010 methodology analyzes actuated signals based on a series of iterative
calculations. The “solution” is based on the difference between two successive iterations. Max
value is 100.
The Synchro default value is 35.
Transportation 32
Services Division
9.1.1.8. Stored Passenger Car Length (m)
The average length of a passenger vehicle, measured from front bumper of first vehicle to front
bumper of second vehicle.
The Synchro default value is 7.6 metres.
9.1.1.9. Stored Heavy Vehicle Length (m)
The average length of a heavy vehicle, measured from front bumper of first vehicle to front
bumper of second vehicle.
9.1.1.10. Probability Peds. Pushing Button
This value represents the Probability of a Pedestrian Pushing the Button during the Don’t Walk
interval. See HCM 2010 page 31-26 for more information.
The Synchro default value is 0.51.
9.1.1.11. Deceleration Rate (m/s2)
This represents the average deceleration rate based on a red and green signal indication,
respectively.
The Synchro default value is 1.22 m/s2.
9.1.1.12. Acceleration Rate (m/s2)
This represents the average acceleration rate based on a red and green signal indication,
respectively.
The Synchro default value is 1.07 m/s2.
9.1.1.13. Distance Between Stored Cars (m)
Average distance to the nearest point of detection for two queued vehicles.
The Synchro default value is 2.44 metres and is referenced in HCM 2010, page 31-16.
9.1.1.14. Queue Length Percentile
The length of queue that will not be exceeded should be entered in the Queue Length Percentile
cell. See HCM 2010, page 31-18 for more information.
Transportation 33
Services Division
9.1.1.15. Left-Turn Equivalency Factor
Equivalent number of through vehicles for each left turn vehicle, given an exclusive lane and no
conflicting movement. See HCM 2010, page 31-17 for more information.
9.1.1.16. Right-Turn Equivalency Factor
Equivalent number of through vehicles for each right-turn vehicle, given an exclusive lane and
no conflicting movement. See HCM 2010, page 31-18 for more information.
9.1.1.17. Heavy Vehicle Equivalency Factor
Equivalent number of passenger vehicles for each heavy vehicle, given an exclusive lane and
no conflicting movement.
9.1.1.18. Critical Gap for Perm. Left Turn (s)
Critical gap for permitted left turn at signalized intersection.
The Synchro default value is 4.5 s and is referenced in HCM 2010, page 31-55.
9.1.1.19. Follow-up Time for Perm. Excl Left Turn (s)
Follow-up time for permitted left turn from an exclusive lane at signalized intersection.
9.1.1.20. Follow-up Time for Shrd Left Turn (s)
Follow-up time for permitted left turn from a shared lane at signalized intersection.
9.1.1.21. Stop Threshold Speed (km/hr)
The speed (when a vehicle first drops below) at which a vehicle will stop.
The Synchro default value is 8.0 km/hr.
9.1.1.22. Critical Merge Gap (s)
The Critical Gap required for a through driver desiring to merge into an adjacent lane.
Transportation 34
Services Division
9.1.2. HCM 2010 Settings
9.1.2.1. Lost Time Adjust (s)
The Lost Time Adjustment is the start-up lost time minus extension of effective green.
The default Lost Time Adjustment is 0s. Maximum Lost Time Adjust is 3s.
9.1.2.2. Start-up Lost Time (s)
Start-up Lost Time is time lost at the start of green as queued drivers react to the green
indication, and increase their speed, such that constant saturation headway is achieved by the
higher queue positions.
The default for start-up lost time is 2.5 seconds. Maximum Start-up Lost Time is 10s.
9.1.2.3. Extension of Effect. Green Time (s)
The Extension of the Effective Green Time is the amount of time vehicles continue to enter after
yellow interval begins.
Within Synchro, Extension of Effect Green Time is auto-calculated to be equal to Start-up Lost
Time minus Lost Time Adjust. The default Extension of Effective Green Time is 2.5 s.
9.1.2.4. HCM Platoon Ratio
The HCM Platoon Ratio describes the quality of progression associated with arrivals to a phase.
For left-turn movements with permitted phasing, the platoon ratio describes arrivals during the
Protected Phase. For right turn movements with a protected operation concurrent with the
complementary left, the platoon ratio describes arrivals during the permitted right-turn operation.
Platoon Ratio is designated using a number from 0 to 2.0 where Synchro auto-calculates this
parameter.
9.1.2.5. HCM Upstream Filtering Factors
The upstream filtering adjustment factor I accounts for the effect of an upstream signal on
vehicle arrivals to the subject movement group. Specifically, this factor reflects the way an
upstream signal changes the variance in the number of arrivals per cycle. The variance
decreases with increasing volume‐to‐capacity ratio, which can reduce cycle failure frequency
and resulting delay.
The filtering adjustment factor varies from 0.09 to 1.0. A value of 1.0 is appropriate for an
isolated intersection (i.e., one that is 1 km or more from the nearest upstream signalized
intersection). A value of less than 1.0 is appropriate for non-isolated intersections.
Transportation 35
Services Division
9.1.2.6. Opposing Right-Turn Lane Influence
This factor is used to adjust the capacity of left turning vehicles due to right turning vehicles from
the opposing approach. Select Yes or No from the pull down menu based on field observations.
The Synchro default value is “Yes”.
9.1.2.7. Initial Queue (veh)
The initial queue represents the queue present at the start of the subject analysis period for the
subject movement group. This queue is created when oversaturation is sustained for an
extended time. The initial queue can be estimated by monitoring queue count continuously
during each of the three consecutive cycles that occur just before the start of the analysis
period. The smallest count observed during each cycle is recorded. The initial queue estimate
equals the average of the three counts. The initial queue estimate should not include vehicles in
the queue due to random, cycle‐by‐cycle fluctuations. The Synchro default value is 0 veh.
9.1.2.8. Receiving Lanes
The number of receiving lanes represents the count of lanes departing the intersection. This
number should be separately determined for each left‐turn and right‐turn movement. Experience
indicates that proper turning cannot be executed at some intersections because a receiving lane
is frequently blocked by double‐parked vehicles. For this reason, the number of receiving lanes
should be determined from field observation when possible. Synchro generates the initial value
based on the downstream lanes programmed into the network. This parameter is determined
based on the coded network geometry and should reflect site conditions.
9.1.2.9. Turn Bay or Segment Length (m)
These are roughly equal to the storage length set within the Lane Settings (see Section 3.1.11)
for all exclusive turn lanes, and the link distance (as drawn within the Map Settings) for all travel
lanes. Synchro makes small adjustments (<5 metres) to take into account tapering.
9.1.2.10. Parking Present?
State whether there are on-street parking manoeuvres located within 75 metres of the stop line
on an intersection leg. Click in order to take parking manoeuvres into account for the analysis.
The Synchro default value is “No”.
9.1.2.11. Parking Maneuvers (#/hr)
This rate represents the count of influential parking manoeuvres that occur on an intersection
leg, as observed during the analysis period. An influential maneuver occurs directly adjacent to
a movement group, within a zone that extends from the stop line to a point 75 metres upstream
of it. A manoeuvre occurs when a vehicles enters or exits a parking stall. If more than 180
manoeuvres/h exist, then a practical limit of 180 should be used. On a two-way leg, manoeuvres
are counted only for the right side of the leg (i.e. approaching the intersection); one a one-way
leg, manoeuvres are separately counted for each side of the leg.
Transportation 36
Services Division
9.1.2.12. Bus Stopping Rate (#/hr)
The bus stopping rates represents the number of local buses that stop and block traffic flow in a
movement group within 75 metres of the stop line (upstream or downstream), as measured
during the analysis period. The stop can be on the near side or far side of the intersection. If
more than 250 buses/h exist, then a practical limit of 250 should be used.
9.1.2.13. Stop line Detector Length (m)
The stop‐line detector length represents the length of the detection zone used to extend the
green indication. This detection zone is typically located near the stop line, and may have a
length of 12.2 metres or more. However, it can be located some distance upstream of the stop
line and may be as short as 1.8 metres. The latter configuration typically requires a long
minimum green, or use of the controller’s variable initial setting.
The Synchro default value is 20 metres and 100 metres for turn lanes and thru lanes,
respectively.
9.1.2.14. HCM 2010 Capacity (veh/h)
This is the calculated capacity of a lane group based on the methods described within the HCM
2010. See page 18-41 and Chapter 31 within HCM 2010 for details regarding the calculation of
capacity for a lane group.
9.1.2.15. HCM Volume/Capacity
The volume-to-capacity ratio quantifies the degree to which a phase’s capacity is used by a lane
group. In general, a volume-to-capacity ratio greater than 1.0 is an indication of actual or
potential breakdown.
9.1.2.16. HCM Lane Group Delays (s/veh)
This is the calculated control delay (s) for a lane group based on the methods described within
the HCM 2010. The delay calculated represents the average control delay experienced by all
vehicles which arrive during the analysis period. The control delay for a given lane group is
computed as the sum of uniform delay, incremental delay and initial queue delay. The
methodology is described in detail starting on page 18-46 of HCM 2010, with additional details
in Chapter 31.
Transportation 37
Services Division
9.1.2.17. HCM Lane Group LOS
This is the calculated LOS for the lane group based on the methods described within the HCM
2010. In general, LOS is an indication of the general acceptability of delay to drivers. Control
delay and volume-to-capacity ratios are used to characterize LOS for a lane group. See Exhibit
18-4 within the HCM 2010 for detailed Automobile LOS criteria.
9.1.2.18. HCM Approach Delay (s/veh)
This is the calculated control delay (s) for an approach based on the methods described within
the HCM 2010 starting on page 18-46.
9.1.2.19. HCM Approach LOS
This is the calculated LOS for the approach based on the methods described within the HCM
2010. In general, LOS is an indication of the general acceptability of delay to drivers. Control
delay alone is used to characterize LOS for an approach. See Exhibit 18-4 within the HCM 2010
for detailed Automobile LOS criteria.
Transportation 38
Services Division
9.2. Signalized Intersections – Pedestrian Mode
9.2.1. HCM 2010 Pedestrians Settings
9.2.1.1. Percentage of Elderly Peds (%)
Enter the average percentage of elderly pedestrians at the study intersection. Unless
demographic information is available for an intersection, a default value of 7 should be used.
The value is derived from 2011 Census data, which shows approximately 13% of the City's
population is over 65 years of age.
9.2.1.2. Percentage of Upgrade Slope (%)
Enter the average percentage of upgrade slope along the study intersection crosswalks.
9.2.1.3. Average Ped Walking Speed (m/s)
An average Walk speed of 1.0 m/s should be used. If demographic data is available, then use
the following values:
 0.9 m/s in cases where at least 20% of pedestrians crossing the signalized intersection are
older pedestrians (65 years of age or older); and
 0.8 m/s in cases where at least 20% of pedestrians crossing the signalized intersection use
assistive devices for mobility.
Transportation 39
Services Division
9.2.2. HCM 2010 Crosswalk Settings
9.2.2.1. Crosswalk Length (m)
Crosswalk length is measured from the outside edge to outside edge of the road pavement, or
curb where present, along the marked pedestrian travel path. The centre of the crosswalk
should be used for the measurement.
This value auto-calculates based on lane width inputs (see Section 3.1.8 or the HCM 2010
Settings within Auto Mode) , but should be overridden where field data available.
9.2.2.2. Crosswalk Width (m)
The cross width represents an effective width, and should reflect the narrowest walking space
along the crosswalk path. If there are no observed constraints which regularly encroach into the
crosswalk area, or obstructions within the median, then the effective width should be equal to
the physical width of the crosswalk.
A default value of 3.0 meters should be used.
9.2.2.3. Numbers of Lanes Crossed (#)
This represents the total number of traffic lanes a pedestrian would have to cross, calculated for
each approach.
Synchro calculates this value and should not be overridden.
9.2.2.4. Number of Right-Turn Islands (#)
This is the number of right-turn islands present on the approach. A value between 0 and 2 can
be entered. The Synchro default value is 0.
9.2.2.5. Type of Control
This is the type of pedestrian signal control for that approach. The options are “none”,
“actuated”, “pre-timed”, “actuated plus rest in walk” or “no signal”. The Synchro default value is
“none”.
9.2.2.6. Corresponding Signal Phase
This is the signal phase associated with the pedestrian movement, correlating to the intersection
signal timing plan. Synchro automatically selects the corresponding movements based on
traditional timing conventions.
9.2.2.7. Effective Walk Time (s)
Research indicates that, at intersections with pedestrian signal heads, pedestrians typically
continue to enter the intersection during the first few seconds of the pedestrian clearance
interval. This behavior effectively increases the effective walk time available to pedestrians. A
conservative estimate of this additional walk time is 4.0 s. A nonzero value for this additional
Transportation 40
Services Division
time implies that some pedestrians are initiating their crossing during the Flashing Don’t Walk
indication. Refer to the HCM 2010 Chapter 18 for details.
9.2.2.8. Right Corner Size A & B (m)
These parameters are the width of the available pedestrian waiting area at the corner of the
intersection. Side A is measured in the direction of the crosswalk crossing the major street. Side
B is measured in the direction of the crosswalk crossing the minor street. Refer to the Synchro 9
manual page 14-10 or HCM 2010 page 18-61 for additional details.
9.2.2.9. Right Corner Curb Radius (m)
This represents the corner radius of the curb of the available pedestrian waiting area. This
parameter could be field measured or taken from design drawings. The City’s “Curb Radii
Guidelines” is available is on the City’s website.
The Synchro default value is 0 metres.
9.2.2.10. Right Corner Total Area (sq.m)
This is the total area of the available pedestrian waiting area. Synchro auto-calculates this value
based on previous user input (Sections 9.2.2.8, 9.2.2.9). HCM 2010 methodology can be used
to verify this area if additional field data is available. Refer to the Synchro 9 manual page 14-10
or HCM 2010 page 18-61 for additional details.
9.2.2.11. Ped Left-Right Flow Rate (p/h)
This is the flow rate of pedestrians from left to right at this approach. Direction is based on the
perspective of vehicles approaching the intersection.
This value needs to be measured in the field.
9.2.2.12. Ped Right-Left Flow Rate (p/h)
This is the flow rate of pedestrians from right to left at this approach. Direction is based on the
perspective of vehicles approaching the intersection.
9.2.2.13. Ped R Sidewalk Flow Rate (p/h)
This is the flow rate of pedestrians on the right sidewalk corner which does not cross a
crosswalk at the intersection being analyzed.
Transportation 41
Services Division
9.2.2.14. Veh Perm L Flow in Ped Ph (v/h)
This is the permitted left-turn demand flow rate, in units of vehicles per hour. This number is not
the total hourly left-turn flow rate, it is only the flow rate of the permitted turns.
9.2.2.15. Veh Perm R Flow in Ped Ph (v/h)
This is the permitted right-turn demand flow rate, in units of vehicles per hour. This number is
assumed to be the total permitted right-turn flow rate, including RTOR's.
9.2.2.16. Veh RTOR Flow (v/h)
This is the right-turn on red flow rate, in units of vehicles per hour. This would be the RTOR
within the right-turning flow rate that could otherwise turn permissively into the crosswalk while
the crosswalk is being used by pedestrians.
9.2.2.17. 85th Percentile Speed (km/h)
This is the 85th percentile speed at a mid-segment location on the major/minor street, in units of
kilometres per hour. Synchro assumes this is equal to the link speed as defined in Section 3.1.5.
9.2.2.18. Right Corner Area per Ped (sq.m)
This is the right corner area per pedestrian in square metres per pedestrian. Synchro
automatically calculates this based on the previous inputs, and must not be overridden.
9.2.2.19. Right Corner Quality of Service
The pedestrian level of service for the subject crosswalk based on the score in HCM 2010
Exhibit 18-5 (page 18-7 from the HCM 2010).
9.2.2.20. Ped Circulation Area (sq.m)
This represents the subject crosswalk circulation area per pedestrian, in units of square-metres
per pedestrian. This is auto calculated by Synchro based on the previous input and should not
be overridden.
Transportation 42
Services Division
9.2.2.21. Crosswalk Circulation Code
Based on the calculated Pedestrian Circulation Area (pedestrian space), Synchro will provide a
number which refers to the qualitative descriptions provided within HCM 2010 Exhibit 18-24
located on HCM 2010, page 18-60.
9.2.2.22. Pedestrian Delay (s/p)
The Pedestrian Delay is calculated by Synchro and is based on the HCM 2010 methods; see
HCM 2010 page 18-68.
9.2.2.23. Pedestrian Compliance Code
The pedestrian compliance code is calculated by Synchro and is based on the HCM 2010
methods. See the dialogue provided within the first three paragraphs shown on HCM 2010 page
18-69.
9.2.2.24. Pedestrian Crosswalk Score
The pedestrian LOS score for the intersection is calculated using the methodology shown within
HCM 2010 page 18-69.
9.2.2.25. Pedestrian Crosswalk LOS
Pedestrian delay represents the average time a pedestrian waits for a legal opportunity to cross
an intersection leg. The LOS score is an indication of the typical pedestrian’s perception of the
overall crossing experience. Pedestrian LOS Score is based on HCM 2010 methodology shown
within HCM 2010 page 18-70, of which pedestrian delay is only one component.
Transportation 43
Services Division
9.3. Signalized Intersections – Bicycle Mode
9.3.1. HCM 2010 Bicycle Mode Settings
9.3.1.1. Bicycle Saturation Flow Rate (bike/h)
The maximum bicycle rate of flow as measured at the stop line during the green indication.
HCM 2010 recommends a saturation flow rate of 2,000 bicycles/h as an average value
achievable at most intersections, and recommends site observations to determine saturation
flow rates otherwise.
The Synchro default value is 2000 bike/hr.
9.3.2. HCM Bicycle Settings
9.3.2.1. Bicycle Flow rate (bike/h)
The bicycle flow rate is based on the count of bicycles whose travel path is crossed by vehicles
turning right from the subject approach during the analysis period. This value needs to be
measured in the field.
9.3.2.2. Cross Street Width (m)
The street width represents the width of the cross street as measured along the outside through
vehicle lane on the subject approach between the extended curb line limits of the cross street.
Transportation 44
Services Division
Synchro auto-calculates based on previous inputs, but this can be updated based on real-world
data.
9.3.2.3. Bicycle Lane Width (m)
This is the bicycle lane adjacent to the outside lane. Synchro accepts values between 0 metres
(i.e. no bicycle lane) and 2.55 metres.
9.3.2.4. Paved Shoulder Width (m)
This is the paved outside shoulder width adjacent to the bicycle lane. Synchro accepts values
between 0 metres (i.e. no bicycle lane) and 2.55 metres.
9.3.2.5. Curb is Present?
Check box if curb is present, leave unchecked if no curb is present. The Synchro default value
is “no”.
9.3.2.6. On Street Parking?
Check box if parking is present, leave unchecked if no parking is present. The Synchro default
value is “no”.
9.3.2.7. Bicycle Lane Capacity (bike/h)
Based on the previous fields, this value is calculated by Synchro based on the HCM 2010
methods. See HCM 2010, page 18-71. This result should not be overridden.
9.3.2.8. Bicycle Delay (s/bike)
Based on the previous fields, this value is calculated by Synchro based on the HCM 2010
methods and represents the delay experienced by each bicycle. See HCM 2010, page 18-72.
This result should not be overridden.
9.3.2.9. Bicycle Compliance
The bicyclist compliance code based on the HCM 2010 methods. See dialogue on HCM 2010,
page 18-72.
Transportation 45
Services Division
9.3.2.10. Bicycle LOS Score
The bicycle LOS score for the intersection is calculated by the methodology described within
HCM 2010, pages 18-72 and 18-73.
9.3.2.11. Bicycle LOS
Bicycle delay represents the average time a bicyclist waits for a legal opportunity to cross an
intersection leg. The LOS score is an indication of the typical bicyclist’s perception of the overall
crossing experience. Bicycle LOS Score is based on HCM 2010 methodology, of which bicycle
delay is only one component. See HCM 2010 page 18-72 for more details.
Transportation 46
Services Division
9.4. Two-way Stop Control Intersections – Auto Mode
9.4.1. HCM 2010 Intersection
9.4.1.1. HCM Control Type
This should be TWSC, indicating that Two-Way-Stop Control methodologies are being applied.
9.4.1.2. HCM Intersection Delay (s)
This is the overall intersection control delay per vehicle. It should be noted that the major street
through traffic is not accounted for in this calculation, since its delay is assumed to be zero.
9.4.1.3. HCM Intersection LOS
The LOS for the intersection is not calculated, since traffic along the major street is considered
free-flowing and thus experiences zero delay.
Transportation 47
Services Division
9.4.1.4. Ped Walking Speed (m/s)
This is the walking speed of pedestrians used in the two-way stop calculations. Pedestrian
walking speed should be the criteria outlined in Section 6.1.7.
The Synchro default value is1.05 m/s.
9.4.1.5. Include Upstream Signal?
Select “No” if you do not wish to have the calculations adjusted due to the presence of an
upstream signal. Select “Yes” if you wish to have the calculations adjusted due to the presence
of an upstream signal. The calculations are adjusted based on the platooning of traffic from the
signalized intersection. Typically “Yes” should be selected.
The Synchro default value is “No”.
9.4.2. Movement Settings
9.4.2.1. Vehicle in Median Storage (#)
If a wide median exists on the main street, and left turns from the side street use the median as
storage to perform the left turn in two stages, enter the number of left turning vehicles (1) or (2)
that can be stored within the median.
9.4.2.2. Major/Minor
Each approach is assigned a label based on whether it is considered the major roadway or
minor roadway. These are assigned automatically by Synchro based on the placement of the
stop signs.
9.4.2.3. Conflicting Flow Rate - All
The total conflicting flow rate based on crossing the major street in either one or two
manoeuvres.
9.4.2.4. Critical Headway (s)
Critical headway is the critical headway of a crossing vehicle completing the designated
movement using only one manoeuvreSynchro default values should be maintained unless
headway parameters have been collected by field observations.
Synchro defaults vary depending on turn type.
Transportation 48
Services Division
9.4.2.5. Critical Headway Stage 1 (s)
Critical Headway Stage 1 is the first of two critical headways associated to a crossing vehicle
completing each of the two designated manoeuvres; also see Section 9.4.2.5. Synchro default
values should be maintained unless headway parameters have been collected by field
observations.
9.4.2.6. Critical Headway Stage 2 (s)
Critical Headway Stage 2 is the second of two critical headways associated to a crossing
vehicle completing each of the two designated manoeuvres; also see Section 9.4.2.4. Synchro
default values should be maintained unless headway parameters have been collected by field
observations.
9.4.2.7. Follow-up Headway
This value is the time between the departure of one vehicle from the minor street, and the
departure of the next vehicle using the same major-street headway, under a condition of
continuous queuing on the minor street.
9.4.2.8. Potential Capacity-1 Maneuver
The Potential Capacity is calculated based on the methodology described within HCM 2010
page 19-16.
9.4.2.9. Time Blocked by Platoon (%)
The Time Blocked by platoon (%) is calculated if there is an upstream or downstream signalized
intersection within 1 km of the study TWSC intersection. This value is determined based the
reference phase and offset of the signalized intersection(s).
9.4.2.10. Movement Capacity – 1 & 2 Maneuvers
These values are the capacity of a crossing vehicle completing the designated movement, using
one and two manoeuvres, respectively. Several capacity adjustment factors that account for the
impeding effects of higher-ranked movements are considered in these calculations.
Synchro calculates these values.
Transportation 49
Services Division
9.4.3. HCM 2010 Lane
9.4.3.1. HCM 95th Percentile Queue
The 95th Percentile Queue is based on the methodology described within HCM 2010 page 19-
30.
9.5. Two-way Stop Control Intersections – Pedestrian Mode
9.5.1. HCM 2010 Pedestrians
9.5.1.1. Ped Walking Speed (m/s)
This is the average pedestrian walking speed at the study intersection.
The Synchro default value is 1.05 m/s, however the City specifies a walking speed of 1.0 m/s.
Transportation 50
Services Division
9.5.1.2. Ped Clearance Time (s)
This value represents the pedestrian start-up time and end clearance time.
9.5.2. HCM 2010 Crosswalk
9.5.2.1. Median Present?
“Yes” or “No” will automatically be selected based on the Median Width coded within the
Simulation Settings screen. “No” indicates that pedestrians cross the entire length of the
roadway at once. “Yes” indicates that pedestrians cross a portion of the roadway, wait in the
median, and then cross the remaindering portion of the roadway. If “Yes” is displayed, a second
crosswalk dialogue box will be displayed.
For the City of Toronto the default should be marked as ‘No’, as regardless of the width of the
crossing, pedestrians will cross the entire length of the roadway.
9.5.2.2. Through Lanes and Vehicular Volume Crossed
The total number of through lanes crossed by the pedestrian, and the total number of through
vehicles that the pedestrian is in conflict will be displayed.
9.5.2.3. Yield Rate (%)
This value represents the average rate that motorist will yield to pedestrians waiting to cross the
roadway. The use of local data should be used if available. Refer to the Synchro 9 manual
Table 14-4 for average yield rates. For additional information see Chapter 19 of the HCM 2010.
9.5.2.4. Pedestrian Platooning
Users should select “Yes” or “No” from the pull down menu to indicate whether Pedestrian
Platooning exists at the intersection. Pedestrian platooning is defined as groups of pedestrians
crossing the roadway as a group.
The Synchro default value is “no”.
9.5.2.5. Critical Headway
The Critical Headway is defined as the time in seconds below which a pedestrian will not
attempt to begin crossing the roadway. The calculated value depends on whether pedestrian
platooning exists at the intersection.
Transportation 51
Services Division
9.5.2.6. Prob Blocked Lane
The probability that a lane is blocked by a vehicle is calculated based on user input.
9.5.2.7. Prob Delays XCrossing
The probability that a pedestrian or group of pedestrians will be delayed is calculated based on
user input. Synchro calculates this value.
9.5.2.8. Delay for Adq Gap
The average delay that a pedestrian or group of pedestrians will experience waiting for an
adequate gap is calculated based on user input.
9.5.2.9. Average Ped Delay
This is the calculated average pedestrian delay based on the HCM 2010 methods for each
individual crosswalk.
9.5.2.10. Approach Delay & Level of Service
The sum of all delays at the analyzed approach is used to determine the Level of Service based
on the HCM 2010 methods for each crosswalk segment.
Transportation 52
Services Division
9.6. All-way Stop Control Intersections
9.6.1. HCM 2010 Intersection
9.6.1.1. HCM Control Type
This should be AWSC, thus indicating All-Way Stop Control methodologies are being applied.
9.6.2. Movement Settings
9.6.2.1. Opposing Approach, & Conflicting Approach Left & Right
The opposing approach, conflicting approach left, and conflicting approach right, are defined by
the HCM 2010 with respect to the subject approach being analyzed.
9.6.2.2. Opposing and Conflicting Lanes
This value is the number of lanes associated with the approaches defined above.
Transportation 53
Services Division
9.6.3. HCM 2010 Lane Settings
9.6.3.1. Volume Left, Thru & Right (%)
These values represent the corresponding volume movement being analyzed within each lane.
9.6.3.2. Geometry Group
Based on the intersection configuration, and the number of lanes along each approach, each
approach is assigned a value based on Exhibit 20-10 of the HCM 2010. This value is then used
to determine the base saturation headways, and headway adjustment factors. See Table 14-2
within the Synchro 9 Manual for the conversion of the geometry group listed within the HCM
2010. See the HCM 2010 for additional details.
9.6.3.3. Degree of Utilization, X
This value represents the probability of finding at least one vehicle on that approach.
9.6.3.4. Departure Headway, Hd
This value represents the average time between departures of successive vehicles on a given
approach.
9.6.3.5. Convergence (Y/N)
A value of Y indicates that the calculated value of departure headway is within 0.1 second of the
initial assumed value of departure headway.
9.6.3.6. Service Time (s)
These values represent the average time spent by a vehicle in the first position (at the stop bar)
waiting to depart.
Transportation 54
Services Division
SPECIAL CONSIDERATIONS
10.1. Signal Coordination
Refer to the City's Traffic Signal Operations Policies and Strategies, Section 5.7 (May 7, 2015).
10.2. Model Calibration
When an operational analysis of a network of signals is undertaken, the model should be

calibrated to ensure that the model reflects the field conditions. Field observations are
substantially more complicated than the estimation of benefits from the Synchro software, but it
is more significant because it is physical “proof” of what's happening in the field. Such field
observations are necessary to calibrate and evaluate the reality of the computer models. Typical
field observations include travel time or delay, number of stops, saturation flow rates, vehicle
queue lengths and general field notes. Field data collection effort can be supplemented by a
photographic log of the project area, videotaping the corridor and conducting conflict studies at
several locations. A sufficient amount of data should be collected to be representative of the
conditions in the study area.
To properly calibrate the simulation model, the conditions simulated should be as identical as
possible to the observed existing conditions. Unrelated design changes such as adding a lane
or a left-turn bay, or traffic management schemes should be avoided for the existing conditions
model. Construction timings and construction activities should also be avoided. These changes
could affect the results obtained in the field, possibly leading to inconclusive statements about
the analysis results.
Field data should be collected at the same periods that were modeled in Synchro. For example,
if models were developed for the weekday morning peak, weekday off-peak and weekday
afternoon peak, then the periods for field data collection should be identical so that the
implemented timing plans correspond to the traffic patterns for those periods. The time required
for data collection varies with the number of signals in the system, the number of timing plans,
available personnel and equipment, and other considerations particular to the specific system.
Ideally, all variables will remain constant during the data collection activities. However,
traffic measurements will generally vary by time of day, day of week, car type, driver, etc.
Effort should be made to minimize this variation by using the same car and driver in each case
and collecting data under similar conditions.
10.3. Volume Balancing
Field-collected traffic volumes almost always contain mathematical inconsistencies and the data
must be adjusted or "balanced" to obtain a mathematically consistent data set. For example, if
we start with the observed volume at a signalized intersection and proceed in the direction of
travel, adding volumes entering the network and subtracting volumes leaving the network, the
running total almost never matches the observed volume at the next signalized intersection.
Transportation 55
Services Division
These inconsistencies arise from the following:

 counting errors
 counting on different days (counts typically vary by 10 percent or more on a daily basis)
primarily from the fact that currently it is not possible to count the entire network
simultaneously
 major traffic sources (or sinks) between locations
 queuing between intersections
 counting with different technologies.
Discrepancies in the counts must be reconciled before proceeding to the model development
task. The analyst must review the counts and determine (based on local knowledge and field
observations) the probable causes of the discrepancies. Counting errors and counts made on
different days are treated differently from counting differences caused by mid-block
sources/sinks or mid-block queuing. The process for balancing counts is to review the data as a
whole and identify directional traffic counts that are not consistent with the surrounding data.
Traffic counts will have to be checked by starting at the beginning or perimeter of the system
and add or subtract entering and exiting traffic. Along the way, count information should match
from one station to the next. If it does not balance, a decision needs to be made on how to best
reconcile the counts.
10.4. HOV Lanes
In general, Synchro is not the ideal option for doing analysis of HOV Lanes. Other
microsimulation software, such as Aimsun should be used.
If it is necessary for the analyst to model an HOV Lane in Synchro, then special attention will be
required when creating the model to ensure the on-street conditions are replicated as closely as
possible. A field study is required to justify using Synchro analysis.
A field study may be required to determine an appropriate lane utilization factor (refer to Section
3.2.1) for HOV lane analysis. Traffic volumes must be counted for each lane of a lane group and
the following formula should be used to calculate the lane utilization factor fLU.
fLU = unadjusted volume for the lane group (in veh per hour) / (number of lanes *
unadjusted volume from the single lane with the highest volume (in veh per hour))
If a field saturation flow study is conducted at an intersection, then the lane utilization factor
used for the specific intersection analysis (along with the other adjustment factors) can be set to
1.0 so that the influence of the adjustment factors are not double counted. In the absence of
individual lane counts, a conservative approach would be to exclude the HOV lane (and its
volume) from the analysis, since, during peak periods, adjacent lanes handle most of the
volume and operate at or near capacity.
In the case where there is non-compliance, the approach would be to conduct the analysis in
three ways:
 Existing conditions, including non-compliance;
 Existing conditions, assuming full compliance; and
 Proposed conditions, assuming full compliance.
Transportation 56
Services Division
10.5. Streetcars
In general, Synchro is not the ideal option for doing analysis of streetcar routes. Other
If it is necessary for City staff to model a streetcar intersection in Synchro, then special attention
will be required when creating the model, to ensure the on-street conditions are replicated as
closely as possible.
If streetcars occupy a mixed traffic lane and the streetcar frequency is more than one every five
minutes in each direction, then the streetcar lane should be excluded from the analysis along
with any left turn movements. The reason for excluding the lane from the analysis is that
streetcars impede the flow of traffic in the streetcar lane and hinder the flow in the curb lane
when passengers board and alight the streetcars. If a left /through shared lane has an
advanced phase, then the streetcar lane should be coded as a left turn lane only (and not as a
shared through/left lane).
10.6. Transit Priority
In general, Synchro is not the ideal option for doing analysis of Transit Priority routes. Other
If it is necessary for City staff to model a Transit Priority intersection in Synchro, then special
attention will be required when creating the model, to ensure the on-street conditions are
replicated as closely as possible.
If an intersection is equipped with transit priority pre-emption, historical traffic signal log data
should be obtained from TSOG to assist in the analysis. The log data can be used to calculate
the average green times and split times for the study period since the timings include for the
adjustments made to the splits whenever a signal goes into “resynch” to recover its offset after a
transit priority pre-emption event. In the absence of available log data, an analysis of the worst
case conditions can be conducted by adding maximum extension values to the splits (if a
movement is to be equipped with extensions or using lowest truncated values (if a movement is
to allow truncations).
If an analysis is conducted for a proposed signal on an existing transit priority route, the average
transit priority extensions from existing adjacent signals can be used if the adjacent signals have
the same mode of control and transit priority parameters.
10.7. Traffic Adaptive
Traffic adaptive systems such as SCOOT (Split Cycle Offset Optimization Technique)
automatically derives and implements the appropriate signal timings in response to
unanticipated variations in traffic conditions consistent with overall signal system objectives.
The volumes of traffic approaching a traffic signal from different directions are continuously
detected and the system automatically adjusts the duration of the green displays to best match
the requirements of the oncoming traffic.
Synchro is not the best software for modelling adaptive control. A micro-simulation software,
such as Aimsun, VISSIM or Paramics, is preferable. If City staff do not have ready access to
Transportation 57
Services Division
micro-simulation software, then Synchro modelling is acceptable. There are two approaches
that can be used.
In the first approach, Synchro analyses must be done for eight 15 minute slices during the
morning and afternoon peak periods. Average cycle length, splits and offsets must be derived
from SCOOT for each 15-minute slice and then matched with 15 minute traffic volumes. While
this approach is theoretically possible, it involves a great deal of data collection and analyses -
the volume data and timings data must be collected on the same day.
The easier alternative would be to use the typical (average) timings for the peak period but also
do field observations for the study period to see if the model matches field conditions, bearing in
mind that timings can vary from cycle to cycle under SCOOT control. The information provided
by TSOG for SCOOT signals is in two parts:
 The range in values allowed by SCOOT by time of day (cycle length and split ranges from
minimum to maximum); and
 The “typical” timings for different critical time periods (i.e. the morning peak, midday off
peak, afternoon peak, night and weekend plans).
A SCOOT intersection analysis should use typical timings for the analysis of existing conditions.
If proposed timings are developed, the minimum and maximum cycle length and split values
must not be violated. If an analysis is conducted for a proposed signal on an existing SCOOT
route, the minimum, maximum and typical cycle length values of the adjacent signals should be
enforced to ensure signal coordination is considered.
10.8. Bicycle Lanes
Signalized intersections which meet HCM 2010 criteria can take into account Bicycle Lane
Width (m) when calculating Bicycle LOS Score and Bicycle LOS. See Section 9.3 for more
details.
If the intersection is not signalized, and does not meet HCM 2010 criteria for analysis, Synchro
does not have special considerations for bicycle lanes. Bicycle lanes should be ignored - only
vehicle lanes should be coded.
10.9. Offset Intersections
Refer to the City's Traffic Signal Operations Policies and Strategies, Section 5.4.5 (May 7,
2015).
10.10. Roundabouts
Synchro is not the best software for modelling Roundabouts. Depending on the scope of the
project, a micro-simulation software, such as Aimsun, VISSIM or Paramics, may be preferable.
Alternatively, software suites such as RODEL, or SIDRA INTERSECTION provides more
accurate results. It is the responsibility of the analyst undertaking the analysis to discuss the
analysis of roundabouts with City staff on a case-by-case basis, prior to proceeding, in order to
properly assess the analysis requirements.
Transportation 58
Services Division
SIMTRAFFIC
SimTraffic is the animation portion of Synchro that simulates the data inputted into Synchro.
Generally, the simulations provide a good representation of existing and future impacts but
could yield results that are contradictory to reports created in Synchro. Network animation
attempts to provide realistic macroscopic scenarios for the entire network by modeling the
performance of individual vehicles using a range of vehicle types and vehicle behaviours.
Individual intersection simulation results may be different from that shown in Synchro due to
network constraints such as gating. Gating involves making signal timing adjustments (offsets,
splits, cycle lengths) to restrict traffic from entering or leaving a critical area.
The following complex situations must be analysed with SimTraffic:
 Closely spaced signals;

 Intersections operating under congested conditions; and
 Ramp signals.
SimTraffic could also be a tool for public consultation / presentation.
Since one simulation may not be representative of typical conditions, data must be collected for
a minimum of five separate simulations and the average values of MOEs then reported. The
following parameters under “Options”, “Intervals and Volumes” and “Intervals” are required:
 The “Recording” start time should be the start of the period being simulated (i.e. 8:00 a.m. if
the am peak/study period starts at 8:00 a.m.);
 The “Seeding” duration must provide enough time for a vehicle to traverse the entire
network between the two most distant points, including all stops. If the travel time is typically
ten minutes during the study period, the “Seeding” duration should be at least ten minutes;
 The “Seeding” start time should be the “Recording” start time less the “Seeding” duration
(i.e. the “Seeding” start time should be 7:50 a.m. if a “Recording” start time is 8:00 a.m., and
the “Seeding” duration is ten minutes.);
 The “Recording” duration should be a minimum of 60 minutes; this duration should allow
sufficient time for any queuing problems to build up and so appear in the simulation;
 The default values for “Record Statistics” (for “Seeding”), the “PHF Adjust”, the “AntiPHF
Adjust”, and the “Percentile Adjust” should be retained (and should be set to “No”);
 The default values for “Record Statistics” (for “Recording”), and the “Growth Factor Adjust”
should be retained (and should be set to “Yes”); and
 At least five separate files must be generated, either using a “Random Number Seed” of “0”
for each file, or using a different Random Number Seed for each run (i.e.: 1 for first run/file, 2
for second, 3 for third, etc.).
The default values for vehicle and driver types under the “Drivers” and “Vehicles” tabs should be
retained.
Transportation 59
Services Division
REPORTS
It is the responsibility of the analyst undertaking the analysis to discuss the analysis
methodologies to be used (e.g. HCM 2000, HCM 2010, Synchro/ICU, etc.) and the measures of
effectiveness to report back to City staff. This should be completed on a case-by-case basis,
prior to proceeding, in order to properly assess the analysis requirements.
In general, the Synchro/ICU methodology is preferred for reporting measures of effectiveness

as the results are typically referenced during the model calibration process (e.g. v/c and travel
times). As there are specific limitations to HCM 2010 analysis, Synchro/ICU or HCM 2000
analysis can still be used in situations where:
1. Intersection configuration is not supported by HCM 2010 methodology;

2. Multi-modal analysis is not necessary for the exercise/decision makers; and
3. Data required for accurate HCM 2010 analysis is not readily available.
When performing analysis within or near areas of significant multi-modal use, HCM 2010
analysis shall be considered through discussion with the City.
Typically, the Synchro/ICU calculated MOEs required by the City include volume/capacity ratio,
approach delay/LOS, intersection delay, queue length, stops, and fuel consumption. The
working Synchro files must be submitted to the City so that staff can review the network (i.e. link
distances, speeds etc.) that was created and all the intersection input parameters (i.e.
geometry, volumes, saturation flows etc.). Prior to submission, the analyst must undertake a
quality control check of the before and after models.
Transportation 60
Services Division
References
1. Ministry of Transportation, Ontario. Ontario Traffic Manual, Book 12 (Traffic Signals), March,
2012.
2. Transportation Research Board. Highway Capacity Manual 2000, National Research

Council, Washington, D.C., 2000.
3. Transportation Research Board. Highway Capacity Manual 2010, National Research

Council, Washington, D.C., 2010.
4. D. Husch, J. Albeck. Synchro Studio 7 – Synchro Plus SimTraffic and 3D Viewer,

Trafficware, 2006.
5. Trafficware, LLC. Synchro Studio 9 – Synchro plus SimTraffic and 3D Viewer, Trafficware,
2014.
6. D. Husch, J. Albeck. Intersection Capacity Utilization – Evaluation Procedures for

Intersections and Interchanges, Trafficware, 2003.
7. Trafficware Corporation website http://www.trafficware.com
8. City of Toronto, Transportation Services Division. Guidelines for Using SYNCHRO 7

(including SIMTRAFFIC 7), April 22, 2010.
9. City of Toronto, Transportation Services Division, Capacity Analysis Working Group.

Saturation Flow Rates for the City of Toronto, December 31, 2001.
10. City of Toronto, Transportation Services Division. Traffic Signal Operations Policies and
Strategies, May 7, 2015.
11. Ontario Traffic Council – OTC Bicycle Traffic Signals Guide, January 2015.
12. Trafficware, LLC. Working White Paper on the Implementation of the 2010 Highway
Capacity Manual within Synchro® Version 9 – 1st Edition, May 9, 2014.
13. City of Toronto. Vehicle Travel Lane Width Guidelines – Road Engineering Design
Guidelines. January 2015.
http://www1.toronto.ca/City%20Of%20Toronto/Engineering%20and%20Construction%20Se
rvices/Standards%20and%20Specifications/Files/pdf/Road%20Design%20Guidelines/Vehicl
e_Travel_Lane_Width_Guidelines_Jan2015.pdf
14. City of Toronto. Curb Radii Guidelines – Road Engineering Design Guidelines. January
2015.
http://www1.toronto.ca/City%20Of%20Toronto/Engineering%20and%20Construction%20Se
rvices/Standards%20and%20Specifications/Files/pdf/Road%20Design%20Guidelines/Curb_
Radii_Guidelines_Jan2015.pdf
Transportation 61
Services Division
15. Zegeer, C., K. Opiela, and M. Cynecki. Pedestrian Signalization Alternatives. Report
FHWA/RD‐83/102. Federal Highway Administration, Washington, D.C., 1983.
16. Synchro vs SimTraffic, July 2, 2014. Blog post from Trafficware website:
http://www.trafficware.com/blog/synchro-vs-simtraffic
Transportation 62
Services Division

ISAST

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

ISAST

Încărcat de

Drepturi de autor:

Formate disponibile

Capitolul 1.

1.1. Definiţie. Clasificare.

Elementele care se observă pe figură sunt următoarele:

𝑑𝑠𝑖 = 𝑙𝑖 + 𝑖𝑠𝑖 (1.1)

Distanţa 𝑑𝑠𝑖 poate fi interpretată şi ca reprezentând spaţiul ocupat de

𝑑𝑡𝑖 = 𝑖𝑡𝑖 + 𝜌𝑖 (1.3)

Distanţele spaţială şi temporală pot fi vizualizate în Figura 1-2, în care sunt

Figura 1-2 – Diagramă spaţio-temporală reprezentând traiectoriile vehiculelor i şi i+1

Pentru o înţelegere mai uşoară a parametrilor prezentaţi, cele două vehicule

1.2.1. Descrierea cu ajutorul mărimilor dependente de

Spațiul parcurs de un vehicul individual

Pentru o deplasare cu viteză constantă 𝑣𝑖 , distanţa temporală reprezintă

1.2.2. Descrierea cu ajutorul mărimilor dependente de

Prin integrare, rezultă:

Acceleraţia în funcţie de spaţiu se obţine prin derivarea în raport cu timpul a

Diagramele de mişcare ale

Diagramele de mişcare ale

1.3.1. Intervale de măsurare

Figura 1-3 – Traiectoriile vehiculelor şi intervalele de măsurare S1 şi S2

Un interval de măsură S este de definit ca o arie cuprinsă în spaţiul t-x.

- 𝑆1 : un interval de măsură dreptunghiular, care acoperă o secţiune de

unde: 𝑘𝑙 = densitatea traficului pe banda l (veh/km)

unde: 𝑇𝑖 = timpul de călătorie al vehiculului i.

unde: 𝑣𝑖,𝑙 = viteza vehiculului i de pe banda l.

Pentru traficul pe mai multe benzi de circulaţie, din combinaţia formulelor

unde: 𝑁𝑙 (𝑡) = numărul de vehicule prezente pe banda 𝑙 la momentul 𝑡.

1.3.3. Fluxul de trafic

unde: 𝑞𝑙 = fluxul pe banda l (veh/oră)

unde: 𝑋𝑖 = distanţa parcursă de vehiculul i.

unde: 𝑣𝑖,𝑙 = viteza vehiculului i de pe banda l.

Pentru traficul pe mai multe benzi de circulaţie, din combinaţia formulelor

unde: 𝑁𝑙 (𝑡) = numărul de vehicule prezente pe banda 𝑙 la momentul 𝑡.

1.3.4. Gradul de ocupare

unde: 𝜌 = gradul de ocupare

Înlocuind în relaţia (1.20):

formula lui 𝑜𝑖 dată de relaţia (1.21):

unde: L = suma lungimii medii a vehiculelor şi a lungimii zonei de detecţie

În consecinţă, între densitatea fluxului de trafic şi gradul de ocupare se poate

Relaţia de mai sus poate fi interpretată prin definiţia: gradul de ocupare

1.3.6. Relaţia fundamentală a teoriei traficului

1.4.1. Regimuri de trafic

Regimul trafic liber

Regimul trafic la capacitate

Regimul trafic saturat

1.4.2. Modele matematice pentru diagramele

Figura 1-6 – Diagramele fundamentale în cazul diagramei k-q triunghiulare

1.4.3. Diagramele fundamentale asociate ale traficului

Figura 1-7 – Cele trei diagrame fundamentale asociate ale traficului

Se observă că pentru diagramele v-q şi q-k, a treia variabilă este un unghi, în

2.1. Calea cea mai scurtă

21 Capitolul 3. Intersecţii semaforizate

2. De la fiecare nod de start se poate construi un arbore de cele mai scurte

Metoda este foarte laborioasă și presupune parcurgerea unui număr mare de

2.1.2. Algoritmul lui Dijkstra

23 Capitolul 3. Intersecţii semaforizate

24 Capitolul 3. Intersecţii semaforizate

2.1.3. Algoritmul lui Bellman – Ford

25 Capitolul 3. Intersecţii semaforizate

26 Capitolul 3. Intersecţii semaforizate

27 Capitolul 3. Intersecţii semaforizate

EXEMPLUL 1 – Stabilirea celei mai scurte căi între două noduri

2.2. Instrumente software pentru managementul

28 Capitolul 3. Intersecţii semaforizate

EXEMPLUL 1 – Stabilirea celei mai scurte căi între două noduri