… ali uvijek u timu jer jedino takav pristup, osim dobrog društva, jamči uspjeh. Unutar tima svatko ima svoju solo dionicu, ali samo u određenim koracima (zadaćama) projekta.

Sportaši bi rekli puno rada i ponešto talenta. Kod inženjera je malo (ili puno) drugačije: puno pozitivne tvrdoglavosti (upornosti), jednako specijalističkog znanja i (po)dosta općih inženjerska znanja. Prometno inženjerstvo, poglavito u području cestovnog (gradskog) prometa, prepuno je besplatnih (!?) ili (pre)jeftinih aplikacija i na tisuće gotovih “recepata” rješenja svakog problema (gradskog) prometa; sve je dostupno u svakom zakutku Interneta. Tablični kalkulatori imaju brojne funkcije i mogućnosti kroz dodatke (add-ins) kojima se brzo i relativno jednostavno mogu postići i dostići željena rješenja. Zašto gubiti vrijeme kada se može brzo naći neki opći model, dovoljno dobar za neki problem (pardon, izazov). Upravo ta” mala” razlika između “dovoljno dobar” i cjelovit/kompletan/potpun čini ogromnu razliku između prosječnog (prihvatljivog) i najboljeg (mogućeg) rješenja. Zato se vrijedi uvijek (pre)više pomučiti kako bi se kreirao najbolji mogući alat, kako bi se stvorili najbolji mogući uvjeti, kako bi se za izabranu metodologiju ustrojila najbolja metoda (jedna ili više) za rješavanje zadaće.

Sveprisutne informatičke tehnologije ulijenile su nas glede metodologije, a kad je plan površan, uniforman, oportun, …, pogrešan je izbor i metode, a sve to završi pilatovskim pristupom izbora nekog SW alata dojmljivijih mogućnosti prezentacije (vizualizacije) koji sakrije svu prethodnu površnost. Kada se poslože potrebna inženjerska znanja predmeta istraživanja, opća inženjerska znanja i nešto (površnog) informatičkog znanja, može se postići puno bolji rezultat za ne toliko (pre)više vremena. Kako nas je naučio gospodin Vilfredo Pareto: u 20 % vremena možemo postići 80 % rezultata, a onda moramo potrošiti jako puno vremena za nešto bolji učinak. Zato moramo jako dobro iskoristiti raspoloživo kratko vrijeme određeno projektnim zadatkom, uvjetima javnog nadmetanja ili odlukom investitora.

Imao sam zadaću: (1) uspostaviti dvosmjernu sinkronizaciju semaforiziranih raskrižja unutar koje se odvija i (2) tramvajski promet, (3) zato je na svakom raskrižju moguć drugačiji slijed i raspored faza u cilju veće širine zelenih valova pa (4) treba uzeti u obzir prostor i repove čekanja na raskrižju.

Budući da stalno jasno i (pre)glasno definiram inženjera iz područja tehničkih znanosti (u koje u Republici Hrvatskoj spada Tehnologija prometa i transport) kao osobu koja vlada s tri znanja (što je i stožerna postavka ovog bloga), kod ovakvih zadaća moram opravdati svoj stav ili ću morati priznati da nisam ništa bolji od “prometnih stručnjaka za sve i svašta”:

• uže područje struke; sinkronizacija semafora predmnijeva usklađivanje odnosa količine prometa i raspoloživog prometnog prostora sa duljinom ciklusa i zelenih vremena obzirom na međusobne udaljenosti između raskrižja, rasporeda i redoslijeda faza, položaja jednog ili više kritičnih raskrižja,
• matematika (metodologija, metoda); prometni inženjeri su upoznati s operacijskim istraživanjima i mogu prepoznati kakav model treba primijeniti, u ovom slučaju mješovito cjelobrojno linearno programiranje (mixed-integer linear programming),
• računarstvo; primijeniti gotovi programski proizvod, univerzalni alat (tablični kalkulator) ili napisati kod u izabranom programskom jeziku.

Imao sam na raspolaganju programske pakete: PTV i Synchro. Njihove mogućnosti su suštinski usmjerene na druga (puno šira) područja pa sam odustao. Netko će (opravdano) prigovoriti zašto nisam koristio Synchro, ali radi se o paketu koji radi analitiku na makrorazini, a ispituje (simulira) rješenje na mikrorazini što nije dostatno za cjelovito ispunjenje moje zadaće. S tabličnim kalkulatorom imam iskustva jer sam prije 20-tak godina razvio macro skriptu u Excelu. To je bila transkripcija prastarog programčića napisanog u Turbo Pascalu (računalna era prije Windowsa). Rješenje je bilo, ili uporaba tabličnog kalkulatora ili napisati vlastiti programski kod.

Svakom inženjeru nešto odredi profesionalni put, meni je uvelike odredio Maxband algoritam. Kao student uspio sam u biblioteci Ekonomskog fakulteta u Zagrebu pronaći brojeve časopisa Operational Reserach iz 1964. i 1966. godine u kojima su objavljeni radovi John T. Morgan-a i John D. C. Little-a o algoritmu za sinkronizaciju semaforiziranih raskrižja, kasnije nazvanom Maxband. Oba rada su me naučila što znači razmišljati “izvan okvira” (out of the box), odnosno kako razmišljaju vrhunski (pravi) inženjeri. Već tada sam, na moju veliku (ne)sreću dovoljno rano, shvatio da inženjer bez šireg permanentnog samoobrazovanja predstavlja (pristojno rečeno) “šarmera bez pokrića” ili (grublje rečeno) osobu sa zgodnim natpisom na posjetnici.

Sinkronizacija semaforiziranih raskrižja na koridoru predstavlja otvorenu petlju; na jednom kraju se ulazi, a na drugom izlazi; ulasci i izlasci se mogu dogoditi i unutar koridora. Jednostavno, a opet: treba sinkronizirati oba pravca kretanja, na dionicama su različite dopuštene brzine, različite količine prometa pa treba pripaziti na širinu zelenog vala i brzinu sinkronizacije, na nekim privozima raskrižja treba osigurati ranije paljenje zelenog (negativni offset) kako bi se ispraznio povećani rep čekanja i sve to treba napraviti za nekoliko signalnih programa (duljina ciklusa). Ponekad u sve to treba ubaciti još i podsustav javnog prijevoza koji se kreće drugačije i drugačijom brzinom obzirom na stajališta. Stajališta su uvijek na “pogrešnoj” strani raskrižja (Murphy’s law). Što je to toliko genijalno u Maxband algoritmu da je i danas neizostavan algoritam usklađivanja semafora u otvorenim (ponegdje i u zatvorenim – mrežama) petljama? Odgovor je jednostavan i glasi upravo to: jednostavnost? Jednostavnost u matematičkom modelu znači: razumljivost, lakoća shvaćanja i uporabe te jednostavno kodiranje u računalo, a to znači i brzo izvršenje. Danas je Internet prepun stručnih članaka o Maxband algoritmu koji je evaluirao do mnogobrojnih inačica (mogućnosti). Još jedna (vrlo važna) napomena. Ova tema govori o off-line optimizaciji sinkroniziranog poteza. Da li off-line rješenje uopće može (prihvatljivo) funkcionirati bez on-line podrške pitanje je za neku drugu temu.

U algoritmu iz 1964. godine sve mjere su svedene na duljinu ciklusa pa procesuiramo jednu veličinu u cijelom modelu: od vremena plana izmjene signala do udaljenosti između raskrižja koje se mjere vremenom putovanja obzirom na dopuštenu brzinu. Primjerice, imamo dva raskrižja međusobno udaljena 450 m s dopuštenom brzinom vožnje između njih od 50 km/h, ciklus je duljine 80 s i zeleno svjetlo na prvom raskrižju 34 s. Tada su neki parametri modela: na prvom raskrižju duljina zelenog je 0,43 ciklusa, a crvenog 0,57 ciklusa, udaljenost između raskrižja je 0,41 ciklusa. Algoritam iz 1964. se zasniva na min-max odnosima zelenih valova između raskrižja; da li zeleni valovi svojim počecima/krajevima dodiruju početke/krajeve zelenih vremena na raskrižjima. Prvotni kod za ovaj algoritam sam napisao davno u Turbo Pascalu. Kasnije sam, dolaskom Windowsa, prebacio u macro skriptu u Excel. Macro je ogroman jer nisam baš neki programer. Algoritamski dio ima 77 linija koda koje se svode na otkrivanje minimalnih i maksimalnih uvjeta zelenih valova između raskrižja . Preostalih 273 su za obradu ulaznih veličina, pretvaranje izlaznih veličina u konkretne parametre sinkronizacije i crtanje dijagrama (iskoristio sam bogatu podršku različitih tipova grafova u Excelu). Prikazani dio koda pokazuje da algoritam stalno pretražuje min-max odnose valova između raskrižja pokušavajući naći najbolje rješenje (najveću širinu valova) koje prolaze kroz sva zelena vremena na svim raskrižjima.

Iskoristio sam grafičke mogućnosti Excela za automatsko crtanje dijagrama sinkronizacije. Prikazani dijagram pokazuje što znači kritično raskrižje, odnosno što min-max odnosi pretražuju u najboljem rješenju – maksimalnim širinama zelenih valova. Ovdje su dva raskrižja kritična, prvo i treće gledano s lijeva, jer im počeci/završeci zelenih valova prolaze počecima/završecima zelenih vremena. Za veću širinu zelenih valova treba povećati zelena vremena na tim raskrižjima ili promijeniti (povećati ili smanjiti) dopuštene brzine između raskrižja. 

Prvi algoritam naziva Maxband iz 1966. godine je matematički program koji predstavlja program mješovitog cjelobrojnog linearnog programiranja (mixed-integer linear programming). Genijalnost ovog algoritma je u tome da se sinkronizacija između dva raskrižja postiže usklađivanjem sredine crvenih svjetala!? Zašto se ne sinkroniziraju počeci zelenih vremena – offseti, kako je logično, očekivano i kako bi svatko pristupio problemu, pokazano je na sljedećoj slici i to otkriva jednostavnost (genijalnost) modela. Krenemo od sredine crvenog svjetla na raskrižju “i” i kada zbrojimo sva vremena između raskrižja “i” i “j” vratimo se opet na sredinu crvenog svjetla na raskrižju “i” i to “putovanje” traje jedan, dva, nekoliko ciklusa, a ciklus je jednak jedinici pa “putovanje” predstavlja cijeli broj (integer). Niti jedan model nije savršen. Osnovni Maxband model ima nekoliko ograničenja, a opisat ću samo dva: (1) raskrižja su bezdimenzionalna, predstavljena sredinom raskrižja pa nije vidljiv početak i kraj putovanja kroz prostor raskrižja i (2) duljina zelenog svjetla u svakom smjeru je jednaka. Današnja proširenja algoritma rade sve što prometni inženjer može zamisliti: različite širine valova u svakom smjeru i na svakoj (pod)dionici prema količini prometa, uključuju prostor (dimenziju) raskrižja, može se dodati komponenta pretpaljenja zelenog (negativni offset) za raščišćavanje produljenog repa čekanja, optimiziraju raspored i slijed faza, mogu računati kretanje vozila javnog prijevoza sa zaustavljanjem na stajalištima i dr.. Budući je algoritam poznat i otvoren, ako nečega nema lako se ugradi u neku varijantu modela. 

Osnovni model (prema gornjoj slici) je:

(1) tražimo (maksimalne) širine zelenih valova “b_iz” i “b_ul” koje se moraju uklopiti u zelena vremena na raskrižjima: zbroj širine vala izlaznog/ulaznog i vremena od početka/kraja vala do početka/kraja zelenog “w_iz” ili “w_ul” mora biti unutar duljine zelenog vremena; sinkronizaciju osigurava zadovoljenje cjelobrojnosti “m” zbroja svih vremenskih jedinica,

(2) funkcija cilja je maksimizirati izlazni i ulazni zeleni val,

(3) i (4) su uvjeti koji osiguravaju da se zeleni valovi nađu unutar zelenog svjetla na svakom raskrižju,

(5) uvjet sinkronizacije,

(6) glavni (najvažniji) uvjet modela jer je jedinica mjere jedan ciklus (cijeli broj – integer),

(7) potrebni uvjeti nenegativnosti za veličine koje tražimo.

Solver (u hrvatskim verzijama Rješavač) u Excelu omogućuje rješenje ovakvih problema, ali nisam ga primijenio jer ima ograničenje na 200 veličina koje se mogu mijenjati i 100 ćelija u koji je upisan model. Moj model za 12 raskrižja ima 122 uvjeta i 83 veličine (49 realnih, 11 cjelobrojnih i 23 binarne). Raspisivanje modela u Excelu zauzelo bi (vrlo vjerojatno) više od 100 ćelija pa nisam htio eksperimentirati. Osim toga, svaka izmjena ili dopuna algoritma tražila bi razvoj modela iz početka. Kao ilustraciju kako je jednostavno aplicirati u Solver model za manji broj raskrižja pokazujem problem za pet raskrižja gdje sam iskoristio i automatsko crtanje dijagrama.

Uvodno sam već opisao svoju zadaću: (1) dvosmjerna sinkronizacija, (2) tramvajski promet, (3) zato je na svakom raskrižju moguć drugačiji slijed i raspored faza u cilju veće širine zelenih valova pa (4) treba uzeti u obzir i prostor raskrižja.

Kakav je moguć slijed faza na sinkroniziranom pravcu pokazuje sljedeća slika. Moguća su četiri slučaja i oni se u Maxband algoritmu mogu modelirati (kodirati) binarnim (0-1) veličinama. Naravno, program sam bira najbolji slijed faza.

Prostor raskrižja se može jednostavno opisati i uklopiti u Maxband algoritam. Slika pokazuje rješenje. Vrijeme putovanja od zaustavne crte do sredine raskrižja je u modelu označeno malim grčkim slovom “tau” i to vrijeme (naravno, izraženo dijelom ciklusa) pridodaje se izračunima. Može se koristiti i za druge potrebe, a najčešća je (već prije opisana) osiguranje ranijeg paljenja zelenog (negativni offset) kako bi se ispraznio povećani rep čekanja prije dolaska početka zelenog vala.

Moje znanje o Pythonu je na razini Tarzan English, ali ipak sam se okuražio, nešto manje zbog osobne taštine, a puno više zbog iskustva u funkcijskom (proceduralnom) pristupu programiranju, iako koristim objektno orijentirani programski jezik. Osim toga, Python ima brdo biblioteka (library); koristio sam PuLP koja ima logičnu sintaksu – inženjerski intuitivnu.

Puno je ulaznih podataka: stacionaže sredina raskrižja (s), duljina ciklusa (C), mogući minimalni (T1) i maksimalni (T2) ciklus (fiksirao sam duljinu ciklusa), duljine izlaznih i ulaznih zelenih vremena (G_iz, G_ul), duljine faza za lijeva skretanja (L_iz, L_ul), vrijednosti “tau” koja opisuju prostor raskrižja te izlazne i ulazne brzine (VV_iz, VV_ul).

Nakon manipulacije podatcima i pretvaranja svega i svačega jedinicu mjere [ciklus], sam model je vrlo jednostavan i kratak (opet naglašavam genijalnost autora za sinkronizaciju sredine crvenih svjetala). Cijeli model, koji uz sve nabrojano omogućuje i male tolerancije brzina zelenih valova, ima 24 retka.

Nisam ponosan na ispis rješenja, ali model “nije za izložbu”. Isporuka je ionako obvezna u formi AutoCad zapisa (dwg) jer se isporučuje izvedbeni projekt.

Rješenje sinkronizacije se predstavlja uvijek dijagramom sinkronizacije (koordinacije). Svi brojevi oživotvoruju se u dijagramu koji pokazuje: kada, gdje i kako. Projektant (inženjer) na kraju “s par završnih poteza” usklađuje realnost prostora i prometa sa krutim (hladnim) matematičkim rješenjem.  

Moja zadaća u projektu je bila razviti rješenje sinkroniziranog poteza. Taj dio potvrđuje naslov teme: u se i u svoje kljuse. Na projektu nas je radilo četvero. Prvi kolega je obrađivao ulazne podatke, a ja kao drugi u lancu temeljem tih podataka sam odlučio što mogu i znam primijeniti u modelu. U međuvremenu je treći kolega pripremao podloge dijagrama sinkronizacije i prometna rješenja te istraživao lokacijske i prometne specifičnosti koridora. Nakon završetka programiranja sam zajedno s trećim kolegom provjerio logiku i sintaksu koda i, naravno, našli smo 10-tak (ne)malih sintaksnih i logičkih grešaka. Zajedno s njim sam i izvrtio sve modele; za različita prometna opterećenja (doba dana) i zahtjeve javnog prijevoza. Dok smo se mi “igrali”, četvrti kolega je aplicirao prometna rješenja (znakovi, signalizacija i oprema) sukladno rješenjima sinkronizacije, a onda je treći kolega oživotvorio dijagrame sinkronizacije u AutoCad-u. Svi smo mi u ovom poslu bili: use i u svoje kljuse, svaki od nas autonoman i odgovoran za svoj dio posla, ali na kraju i ovaj projekt je, kao i svi drugi kvalitetni projekti, proizvod tima (grupe) stručnjaka.