ITS – jednostavno je i praktično (6)

Riješiti ITS problem na jednostavan način učinkovitije je od pristupa s "brojnim mogućnostima".

Kao studentu jedan profesor mi je objašnjavao kako je promet složena stvar jer automobil ima par tisuća, a putnički avion par stotina tisuća dijelova. To je njemu bio dokaz složenosti naše struke. Današnji automobil (na fosilna goriva) ima 30-tak tisuća dijelova, a Boeing 747 oko 6 milijuna dijelova. Zašto toliko? To je pitanje za strojarske inženjere, a ne za inženjere iz područja tehnologije prometa. Inženjeri koji promišljaju prostor-vrijeme ne brinu o takvim stvarima i/ili o matematičko/računalnim pitanjima tipa P vs. NP, ali itekako osjećaju i prigovaraju ako se nešto "sporo vrti". U jednoj prethodnoj temi sam opisao sustav AUP Rijeka i činjenicu da je tadašnji video sustav (2003. godine) na bakrenoj žici imao kašnjenje (delay) oko 6 s; što smo putem kamera gledali u prometnom centru stvarno se dogodilo 5 – 6 s ranije. Prvi sustavi na državnim i tadašnjim "polu-autocestama" imali su isto kašnjenje, upravo zbog HW ograničenja. Danas toga nema, procesorska snaga, memorijski kapaciteti i "protočnost" optičkih mreža pružaju nam aktualni podatak/odgovor. Ne baš istovremeno, ali tu smo negdje, vrlo blizu realnosti.

Jednostavnost u IKT (informatičkim i komunikacijskim tehnologijama; ICT – information and communication technologies) danas je gotovo pa obvezna na bespoštednom informatičkom tržištu iz dva razloga: (1) korisnik ne želi plaćati ono što ne mora, (2) isporučitelj usluge ne želi trošiti bespotrebno svoje (skupe) inženjere (i druge resurse), a kasnije vrijeme i sredstva na bespotrebno skuplje održavanje. U već toliko tema sam spominjao Vilfreda Pareta i njegovo načelo: na skali plaćanja i kvalitete od 0 do 100, za cijenu 20 dobivaš kvalitetu 80, a do 100 morat ćeš platiti još 80 (četiri puta više), ako je takva razine kvalitete uopće potrebna. Zato je danas jedno od načela razvoja nekog IKT rješenja keep it simple and practical. U slobodnom prijevodu: neka bude jednostavno i praktično. To je pravi inženjerski ideal. Ako je jednostavno znači da je jeftino, razumljivo, učinkovito, pouzdano, itd.. Ako je praktično, znači da je uporabivo, da se isporučeni sustav/rješenje koristi, a to je, valjda, smisao svakog inženjerskog posla.

Načelo jednostavnosti i praktičnosti polazi od sljedećih (vrlo razumnih) premisa: nudimo i predlažimo (jednostavna) rješenja koja stvaraju (vidljivu) vrijednost nasuprot rješenjima koja su "in" samo zato što su "kompleksna". Neki problemi (izazovi) imaju opravdanje za korištenje složenih (i skupih) pristupa, ali većinom se ITS problem može pojednostaviti bez gubitka primjetne ili imalo kvalitete, ispunjavajući zahtjeve propisanih funkcionalnosti unutar (ili ispod) zadanog proračuna.

Često inženjeri pronađu rješenje koje je puno jednostavnije, učinkovitije, kvalitetnije i ekonomičnije od postojećeg načina rada. I tu se prestraše. Strah leži u činjenici da naručitelj (neopravdano) pomisli da nismo ništa radili ili smo nestručni jer nudimo nešto "banalno" naspram postojećeg "vrhunskog kompleksnog rješenja" kojeg, ili naručitelj očekuje, ili već ponosno posjeduje godinama nesvjestan o kakvom "čudovištu" se radi. ITS rješenje nije Office paket nakrcan opcijama za milijune različitih korisnika koje jedan nadprosječan korisnik primjeni 8 – 10 %, ITS rješenje je učinkovito ako iskorištavamo sve njegove funkcionalnosti uz poneku pričuvu (5 – 10 %).

Četiri su vodilje kod načela jednostavnosti i praktičnosti. Prva kaže da (1) treba izbjegavati ikakvu složenost (kompleksnost) jer to vodi u probleme; u opći informatički (HW/SW) nered koji se plaća danima rada na popravljanju nepotrebnih grešaka. Druga vodilja je (2) funkcionalnost; zašto komplicirati ako jednostavnije rješenje radi ono što treba; to je puno bolje rješenje od nekog složenijeg, kompleksnijeg, višeslojnijeg, … . Treća vodilja nalazi se izvan HW/SW sfere, ali itekako utječe na nju, a to je (3) jednostavno vrednovanje i donošenje odluka. Ako to ne radimo onda će nam i HW/SW rješenja biti komplicirana, neučinkovita i skupa. Četvrta je (4) jednostavnost u promišljanju problema i rješenja.

Ova načela u praksi se provode kroz sljedeće konkretne akcije/procese/postupke/djelovanja:

• ono što radimo treba stremiti osiguranju vrijednosti našeg rješenja,
• ako smo jednostavni onda smo i učinkoviti; analogija iz informatike najbolje opisuje ovaj pristup: program s manje programskog koda izvršava se najbrže (pod pretpostavkom da radi ono to treba),
• ako problem rješavamo u manje koraka, onda ćemo svakom koraku moći posvetiti više vremena, a to predmnijeva potrebnu kvalitetu,
• manje trošenje ljudskih resursa čini cijeli projekt profitabilnijim,
• jednostavno rješenje upućuje i na brže shvaćanje, a time i prihvaćanje od svih onih koji će ga koristiti,
• životna maksima "jednostavno do cilja" ovdje vrijedi u svakom koraku projekta.

Teško je danas u ITS-u promovirati ovakvo načelo, jer bukvalno sve pršti od tehnologije i brojnih međuovisnosti, sve treba biti redundantno s mnogim pričuvnim "rješenjima": od napajanja pa do udvojenih tehnički komponenti ("... ako se jedna pokvari."). Informatičari su nam ovdje od velike pomoći jer prednjače u promociji ovog načela kroz virtualizacije HW i SW segmenata. U prometu je teško nešto virtualizirati (entitete,prostor, vrijeme), ali se mnoge stvari mogu ekonomizirati na način da rade jednako dobro, zanemarivo slabije ili bolje od "kompleksnog" rješenja.

Prije točno 20 godina imao sam čast kao koautor sudjelovati u izradi Studije prometnotehnološkog razvoja sustava za Automatsko upravljanje prometom u Gradu Zagrebu, koju je za Grad Zagreb izradio tadašnji Institut prometa i veza. U to vrijeme Zagreb je imao 304 semaforska uređaja, a rješenje upravljanja svelo se na grupiranje uređaja (raskrižja/dijelova mreže) u: ključna, kritična, sekundarna i prometne točke. Prometnim procesom Grada trebalo je upravljati 54 ključnih raskrižja. Kritična raskrižja bila su zamjenska (redundantna) raskrižja u slučaju gubitka funkcionalnosti na nekom ključnom raskrižju; pouzdanost u 2003. godini glede komunikacija i samog HW još uvijek je bila bitan čimbenik rješenja. Ortogonalna struktura mreže tada je omogućavala da se kroz 54 semaforska uređaja postignu svi zadani ciljevi. Sa 18 % optimiziranih uređaja i s preostalih 82 % uređaja, koji bi vršili lokalnu optimizaciju sukladno parametrima susjednih (važnijih) raskrižja, prometno se mogao optimizirati/uređivati/voditi prometni proces (da je sustav izgrađen) po zahtjevima javnog ili nekog drugog vida prometa. Moglo se ponuditi rješenje sa svih 304 "optimiziranih" semaforskih uređaja, ali to bi bilo bespotrebno (bedasto) rasipanje resursa, jer svaka potrebna optimizacija nekog važnog raskrižja u ortogonalnoj mreži uvjetuje način rada susjednih manje znakovitih i prometno opterećenih raskrižja. Optimizirati neko manje raskrižje i onda zbog opravdanih razloga odbaciti parametre (rješenje) optimizacije jer su uvjeti susjednog znakovitijeg (kritičnog) raskrižja važniji (primarni) zaista je i tada i danas predstavljalo bacanje novca, kao i tehnološko-vremenskih resursa. Na slici su magenta bojom označena ključna raskrižja, žutom kritična i zelenom sekundarna raskrižja, a crnom bojom prometne točke (najniža razina važnosti). Slika pokazuje i (pre)malu prisutnost video opreme, ali to je tada (2003.) bila vrlo skupa "igračka".

Zagreb se "prometno povećao" za još 150-tak semaforskih uređaja, ali bi, primjenom tadašnjih rješenja, i dalje načelo kritičnih raskrižja bilo najučinkovitiji pristup, ako bi raskrižja definirali kao operatere prometne mreže. Danas, kada jeftino i učinkovito pratimo prometne tokove u prostor-vremenu putem dinamičkih matrica putovanja, je izlišno govoriti o lokalnoj optimizacije neke (ključne) točke u prometnoj mreži. Niti u jednoj mreži nije sve idealno pa niti (poglavito) u zagrebačkoj prometnoj mreži. Tu nam u pomoć dolaze isto novi/stari alati; o učinkovitosti analize socijalnih mreža u identifikaciji kritičnih (ključnih, najvažnijih) točaka i/ili dijelova prometne mreže pisao sam u ovoj temi. I to je dokaz koliko je IKT napredovala u posljednjih 20-tak godina da možemo znanstvena prometna postignuća izravno implementirati u konkretna tehnološka rješenja.

Drugi primjer je aktualniji i isto govori o razumnom korištenju raspoloživih resursa. Sustav informiranja prema ITS normi dijeli se u pet skupova/servisa: informacije o prometnom sustavu u realnom vremenu, informiranje u realnom vremenu u vozilima, navigacija u realnom vremenu, multimodalno planiranje putovanja, putne servisne informacije. Za putnike u javnom prijevozu, uvijek se radilo i radi se o dvije vrste informacija: pre-trip information (predputno informiranje: da li ćemo i ako ćemo, na koji način ćemo koristiti javni prijevoz), on-trip information (informacije za one koje se nalaze u sustavu javnog prijevoza). Informiranje putnika na stajalištima je zanimljivo jer se nalazi na presjeku obje vrste informacija: predputna informacija za namjernike u zoni stajališta može ih navesti na korištenje javnog prijevoza (ako brzo dolazi linija u željenom pravcu), a one koji čekaju to je putna informacija koja izvještava o dolasku najbližih vozila pa putnici mogu odlučiti o načinu nastavka putovanja (kojom linijom, kojim itinererom). Ovakvi sustavi mogu pratiti svako vozilo u svakom trenutku, stvoriti zaista sveobuhvatne modele koji mogu stvarati prediktivne scenarije za sljedećih 5, 10, 15 ili više minuta. To je koristan i vrlo vrijedan podatak za prometnog operatera (dispečera), ali putnika na stajalištu to ne zanima. Njega zanima da li će doći prvo linija kojom može stići na svoje odredište ili mu je bolja (brža) kombinacija ući u vozilo neke druge linije koje prije dolazi pa presjedanjem stići na svoje odredište. Ako je informacija koju dobiva točna (vjerodostojna) i ako ima pozitivno iskustvo sa sustavom "koji mu ne laže", onda će putnik i dalje koristiti javni prijevoz i svojim iskustvom biti njegov najbolji promotor. Danas se točna informacija može jednostavno postići. Je li vozilo s početnog stajališta krenulo s pet minuta zakašnjenja to korisnika na stajalištu u mreži ne zanima. Možda će tih pet minuta nadoknaditi i doći na vrijeme, a možda će i povećati kašnjenje. Na konkretnom stajalištu putnika zanima (točno) vrijeme dolaska pojedine linije javnog prijevoza. Nisu potrebne nikakve kompleksne analize i/ili optimalizacije mreže. Kada je vozilo javnog prijevoza krenulo s prethodnog stajališta, obzirom na prethodna vremena putovanja i aktualno stanje prometa (ponešto statistike događanja u mreži prethodnih 5 – 10 minuta), možemo s potrebnom točnosti predvidjeti dolazak vozila i (opet) uvjeriti putnika u točnost predikcije dolaska – kvalitetu sustava informiranja putnika. Fleet management sustav javnog prijevoza daje podatke u zadnjih 5, 10, 15 ili 20 minuta oko čega se može izgraditi vjerodostojna prognoza dolaska na stajalište. Brojni su scenariji, a ovdje se prikazuje nekoliko primjera usporedbe stvarnog vremena putovanja (plavo na slici) i planiranog dolaska po voznom redu (narančasto). U ovom primjeru zaključak se stvara praćenjem dolazaka prethodna četiri vozila; potrebna točnost dobiva se iskustvom u kombinaciji sa složenosti mreže, kao i dijelom dana/ mjeseca/ sezone kada se predviđanja obavljaju.

Sustav prometne mreže radi svoj posao, fleet management sustav ili Public Transport Management javnog prijevoza radi svoj posao, a unutar toga sustav informiranja putnika koristi (potrebne) djeliće tih podatakakako bi radio jedino i isključivo za što je namijenjen – pokazuje korisnicima točno vrijeme dolaska najbližih vozila javnog prijevoza na stajalište. To je pravi primjer keep it simple and practical.

Neki to (neopravdano) nazivaju oportunizmom, možda su (ponekad) u pravu, ali u tehničkim, poglavito danas u informatičkim i komunikacijskim tehnologijama, pristup zasnovan na jednostavnosti i praktičnosti uvijek poluči najbolje (tehnološke i financijske) rezultate. Rješenje dobiveno u manjem broju koraka upućuje na tehničku inteligenciju i eleganciju, a time se postiže najveća kvaliteta i vrijednost usluge ponuđenog ITS rješenja.