Zrno po zrno … do cjelovitog ITS-a (3)

Brzo je sporo, ali kontinuirano bez prekida. (japanska tradicionalna)

Svaki složeni sustav razvija se kroz određene korake (podskupove, podsustave) kako bi se na kraju sve to spojilo u neku smislenu cjelinu. Za ITS je to zadano i propisano, bolje rečeno sistematizirano, argumentirano i obrazloženo kroz normu ISO 14813-1 (Referentni model arhitekture ITS sektora – 1. dio: Područja primjene ITS-a, skupine usluga i usluge). Aktualna verzija norme iz 2015. godine ima 13 osnovnih ITS skupova. Unutar toga nabrojao sam 179 ITS usluga (services). Zlobnici, uključujući i mene, bi rekli da je razlog norme puno prizemniji; više skupina i usluga – više novaca. Norme postoje i treba ih poštovati i koristiti, ako zbog ničeg drugog, onda zbog činjenice da norme iz područja tehničkih znanosti, uz sve mane i pristranosti, u svojoj srži predstavljaju sublimat najboljih praksi – dobrih iskustva.

Ovaj ciklus tekstova (vidi prethodne dvije teme o vrijednosti ITS-a i kako započeti realizaciju ITS-a) promatra ITS s motrišta informatičko komunikacijskih tehnologija (IKT, eng. ICT). Za svako imalo složenije IKT rješenje preporučuje se implementacija kroz podsustave koji se putem nekog interoperabilnog rješenje (API, mreža s normiranim protokolima i sučeljima, i dr.) povezuje u konačnu isporučevinu. Ovakav pristup daje mogućnost:

(1) veće fleksibilnosti u razvoju i realizaciji rješenja,

(2) brzog prilagođavanje svim poslovnim i korisničkih zahtjevima investitora i korisnika (ako su uključeni u proces realizacije),

(3) mogućnost ranijeg (trenutnog) otkrivanja i saniranja poremećaja/grešaka i

(4) sveukupnog povećanja kvalitete izgrađenog ITS rješenja; gledajući kroz prethodne tri točke.

Takav pristup se operativno provodi kroz tri koraka: (1) rješenje gledati kao cjelinu koja se razvija kroz podskupove/ podsustave/ komponente/ elemente cjeline, (2) ključan korak u razvoju rješenja je razvoj uz povratnu svezu (feedback) jer je IKT rješenje podložno promjenama/ dopunama / nadogradnjama /poboljšanjima i (3) ovakav pristup omogućuje brzu realizaciju. Zato se operacionalizacija IKT rješenja provodi progresivno s iteracijama uz povratnu svezu (progress iteratively with feedback). Treći korak je najinteresantniji jer upućuje na brzinu, a opet, brzina u razvoju IKT-a upućuje na brzopletost kao sinonim za greške i nekompletnost rješenja. Kada se kombiniraju prva dva koraka s japanskom izrekom u uvodu dobiva se dobitna kombinacija za (vrlo) brzo rješenje koje ispunjava (sve) zahtjeve investitora i budućih korisnika.

Zašto je iterativni postupak najbolji za IKT, odnosno ITS? Sagledavanje (razvoj) komponente sustava omogućuje istovremeni razvoj svih njezinih dijelova (ako su raspoloživi) ili razvoj u koracima kako dolaze saznanja, informacije, dijelovi opreme i sl.. Manji dio (komponentu) je moguće cjelovito (funkcionalno) sagledati što (najčešće) odmah ukazuje na moguća poboljšanja, rizike, izmjene, nadogradnje ili je takve akcije moguće provesti kasnije; zbog zahtjeva drugih (pod)sustava ili pronalaženja boljeg rješenja. Dovoljno mala, a opet autonomna komponenta, koja ima definiranu funkciju, može se razvijati sa stalnim fokusom na vrijednost (value); što znači vrijednost (value) i koliko je važna opisano je u prvoj temi ove serije.

Tijekom projektiranja (dizajna) povratna sveza (feedback) je nešto što najčešće izlazi iz inženjerskih okvira. Radi se o izlaznim informacijama koje stvaraju ljudi (recenzenti, investitor, korisnici) i prosljeđuju ljudima (projektanti, izvođači). Ne volimo kritiku, ali volimo (jako) kritizirati. U idealnoj situaciji radi se o vjerodostojnoj (neiskrivljenoj) informaciji – stručnom objektivnom mišljenju koju projektant prima na isti način: čista srca i objektivno. Osobno se držim načela da inženjer treba moći dati i prihvatiti kritiku pa, bez obzira na poneku (ne)opravdanu tešku riječ, uvijek u projektu startam s motrišta da u svima leži iskrena želja za najboljim rješenjem. Tko je koliko puta doživio pozitivno, a koliko negativno iskustvo – svatko ima svoju priču.

Kao ilustraciju teme uzmimo primjer video tehnologije u (cestovnom) prometu. Što možemo? Isporučitelj (vendor) će uvijek reći sve, a mi inženjeri ćemo biti malo oprezniji: jako puno, moguće i cjelovito rješenje u nekom konkretnom problemu, naravno, ako je to netko spreman platiti. Bolje rečeno, ako je pametan platiti jer je vrijednost IKT rješenja (value) višestruko veća od investicije. Video tehnologiju možemo koristiti kao opće senzore za sve sudionike u prometu (od pješaka/biciklista do posebnih vrsta vozila; svega što se kreće i zatekne u prometnom prostoru), za senzoriku (praćenje) pojedinih sudionika kroz video processing (od razloga sigurnosti pa do anonimnog praćenja za potrebe Dynamic Traffic Assignment aplikacija/rješenja), za opći nadzor prometa (fisheye kamere) pa do klasičnih nadzora tipa CCTV (Closed-circuit-television) – stara dobra televizija zatvorenog kruga. Ovo se može proširiti i na druga područja vezana za cestovni promet, recimo na vozila (autobuse) javnog prijevoza: od brojanja putnika do općeg nadzora sigurnosti vozača i putnika u vozilu i/ili na stajalištima. Sve to strpati u jednu ITS uslugu, u jedno SW/HW rješenje!? Moguće, ali nitko na svijetu nije još ispao "toliko pametan".

Zato se rješenja ITS-a kroz IKT arhitekturu podijele u logične/ zasebne/ funkcionalne cjeline koje mogu: (a) autonomno ispuniti svoju zadaću i/ili (b) biti dio spektra planiranih usluga ITS rješenja. Ako nešto zapne (od inženjerskih pa do financijskih problema) jedna li čak kritična cjelina za rad sustava može se završiti, a ostalo kada bude prilike (nekad ili nikad).

Zašto je važan iterativni postupak svakom je jasno tko radi s IKT rješenjima. Sve u IKT-u mijenja se na sezonskoj razini pa svako iščitavanje projekta starijeg od 6 -12 mjeseci upućuje na usklađivanje s novih rješenjima; (puno) boljim s istom ili čak nižom cijenom. Može i bez toga, ali onda se radi o vrlo neinformiranima ili lijenim konzultantima/ dobavljačima/ izvođačima (jedan od smrtnih grijeha). Uglavnom, investitor će na kraju projekta znati da je grdno pogriješio u odabiru partnera u području IKT usluga ako tijekom projekta nije dobio niti jedan prijedlog nečeg novog, (puno) boljeg za istu ili nižu cijenu od planiranog/ugovorenog.

Slično se može opisati atribut povratne sveze; gomila utjecaja u IKT projektima ne može se razriješiti bez (samo)prilagođavanja različitih komponenti; izlazna veličina (output) služi za samokontrolu ili samopodešavanje, a često služi i kao ulazna veličina za drugu komponentu. Taj ogromni tehnološki puzzle jedino se može razriješiti (dobiti cjelovita slika) kroz brojne međusobne sveze i informacije od kojih su neke konačni izlazi (ishodi), a većina njih vlastita korektivna ulazna veličina – feedback.

Posljednje dvije godine dionik sam implementacije ITS rješenja u jednom lijepom jadranskom gradu. Pet osnovnih cjelina (prometni centar, upravljanje semaforima, video sustav, info-displayi, komunikacija) vrlo brzo se razbije u "sliku s 1000 puzzlea". Ako pogledamo samo prometni centar, imamo elektroenergetiku i ostale komunalne instalacije, lokalnu mrežu s brojnim preklopnicima različitih namjena i tehnologija, klimatizacijski sustav, namještaj, nosače monitora i video zida, monitore i video zid, poslužiteljska (server) i korisnička (client) računala, ostalu informatičku opremu (komunikacija, pisači), sustav tehničke zaštite. Sve to treba međusobno spariti i ukomponirati s udaljenim lokacijama (raskrižjima, cestovnim stanicama, komunikacijskim koridorima i revizijskim oknima, …). Ako se samo grubo osvrnem na programsku podršku i aplikacije: glavno sučelje (front-end), integracijska aplikacija, nadzorna aplikacija, aplikacija prometno-analitičkih podataka, upravljanje video informacijama (video management service), praćenje stanja (ispravnosti) opreme na udaljenim lokacijama, integracija s vanjskim IKT servisima (javni prijevoznik, parkiranje, žurne službe, informiranje, ...) pa sve do virtualizacijske aplikacije (software-defined data center) koja omogućuje sa se sve to "vrti" brzo i učinkovito na minimalno potrebnoj količini HW opreme. Isto tako, svaka druga cjelina ovog sustava ima 10 – 15 sastavnica koje (ne)izravno korespondiraju međusobno ili s ostalim cjelinama. Jedini recept za uspješno isporučiti takav projekt je: polako, smireno, kontinuirano, iterativno s provjerama. Ponavljam, nisam ljubitelj prevelikih (i zamagljenih) kompliciranja, ali neka "kompliciranja" omogućuju brzu (trenutnu) prilagodbu novim (opravdanim) zahtjevima naručitelja ili korisnika. To je sukus citirane japanske izreke koja govori da složene poslove treba rješavati po načelu efikasnosti rješenja, a ne brzine implementacije.

Jedna od prednosti ovog pristupa je i postizanje jednostavnosti rješenja (ovome ću posvetiti posebnu temu), a jednostavno znači učinkovito i praktično. Uzmimo opet primjer video sustava. Pokušavajući riješiti sve "odmah i u jednom koraku" nemoguće je izbjeći ponavljanje, udvajanje, neželjenu redundanciju (i u funkcionalnom i u fizičkom smislu). Takva rješenja su pogrešna, neefikasna i/ili neekonomična i svim dionicima je to jasno osim kreatoru (konzultantu) jer je ostao zarobljen "iza drveta zbog kojeg ne vidi cijelu šumu". Najpopularniji primjer jednostavnosti kod video sustava je korištenje jedne kamere za više funkcija. Na primjer, na prethodnoj slici položaj kamere za funkciju senzorike omogućuje i funkciju općeg nadzora.

Živimo u vremenu Industrije 4.0, u kojem više nema mjesta za njemačku tradicionalnu langsam, aber sicher, ali, isto tako, brzopletosti se jako skupo plaćaju u svakom smislu: financijskom, medijskom, sociološkom, tržišnom, tehnološkom, političkom, …, u odnosu na iste/slične greške iz preddigitalnog doba. Da bi greške bile rijetke (zanemarive), a posljedice u svakom smislu podnošljive, ITS rješenje treba razvijati u koracima (elementima, komponentama, etapama, fazama) uz kontinuiranu (samo)kontrolu, odnosno progresivno s iteracijama uz povratnu svezu (progress iteratively with feedback).