mediapulsasVilnius 1355: Smart City platforma, sujungusi vilniečius ir miesto tarnybas.
Savivaldybės įmonei „Grinda", atsakingai už Vilniaus infrastruktūros priežiūrą, sukūrėme pilną incidentų valdymo ekosistemą: native iOS ir Android programėles gyventojams bei vidinę darbų eigos sistemą tarnyboms. Problemos kelias nuo pranešimo iki išsprendimo sutrumpėjo 50 %.
MediaPulsas kuria Smart City, GovTech ir savivaldybių skaitmenizavimo sistemas Lietuvoje - nuo gyventojų programėlių iki tarnybų valdymo platformų.
KlientasApie projektą
Iki projekto vilniečių pranešimai apie duobes, šiukšles ar apgadintą infrastruktūrą keliavo išsibarsčiusiais kanalais - telefonu, el. paštu, socialiniais tinklais. Tarnyboms trūko vienos incidentų valdymo sistemos, kurioje pranešimai būtų registruojami, priskiriami atsakingai brigadai ir sekami iki išsprendimo su pilnu audito žurnalu (angl. audit trail).
„Vilnius 1355" šią komunikaciją sujungė į vieną ekosistemą: gyventojas telefonu užfiksuoja problemą su nuotrauka ir GPS koordinatėmis, sistema per atgalinį geokodavimą (reverse geocoding) nustato adresą, o „Grindos" operatoriai incidentą mato realiu laiku, priskiria komandai ir atnaujina būseną - kurią gyventojas seka programėlėje su stumiamaisiais (push) pranešimais. Skaidrumas veikia abiem kryptimis.
Kaip veikia sistema
Visas incidento gyvavimo ciklas - nuo gyventojo telefono iki išspręstos problemos - automatizuotas be rankinio duomenų perkėlinėjimo:
- Gyventojas
- Geolokacija
- Nuotrauka
- REST API
- Užduočių eilė
- Operatorius
- Priskyrimas brigadai
- Būsenos atnaujinimas
- Push pranešimas
Iššūkis
Sistemos, kuriomis naudojasi ir plati visuomenė, ir profesionalios tarnybos, turi suderinti du pasaulius - paprastumą gyventojui ir darbų eigos funkcionalumą operatoriui:
- Pranešimas turi užtrukti mažiau nei minutę - kitaip gyventojai tiesiog nepraneš
- Tiksli incidento vieta būtina brigadai, net kai pranešėjas nežino adreso
- Pranešimų pikai po audrų negali sulėtinti sistemos ar pamesti duomenų
- Skirtingiems tarnybų skyriams reikia skirtingų darbų eigų ir prieigos teisių
- Mobiliosios programėlės ir vidinė sistema privalo sinchronizuotis realiu laiku
- Kiekvienas veiksmas turi palikti pėdsaką audito žurnale atskaitomybei
Kodėl tai buvo sudėtinga: techniniai iššūkiai
GPS tikslumas mieste
Tankiai užstatytose gatvėse GPS signalas atsispindi nuo pastatų. Suliejome kelis vietos šaltinius (GPS, Wi-Fi, mobiliojo ryšio celės) ir pridėjome žymeklio patikslinimą žemėlapyje - praktinis tikslumas iki 2 m.
Piko apkrovos
Po audros pranešimų srautas išauga dešimtimis kartų. API priima pranešimą akimirksniu, o apdorojimą perduoda asinchroninei užduočių eilei - apdorojimas paskirstomas, niekas nepasimeta.
Dubliuoti pranešimai
Tą pačią duobę praneša dešimtys žmonių. Sistema lygina naujus pranešimus su aktyviais incidentais ~50 m spinduliu toje pačioje kategorijoje ir siūlo operatoriui juos sujungti vienu paspaudimu.
Nuotraukų apdorojimas
Telefonų nuotraukos - po 5-10 MB. Programėlė jas sumažina ir suspaudžia dar įrenginyje (iki ~1600 px ilgosios kraštinės) - įkėlimas greitas net silpnu ryšiu, saugyklos sąnaudos mažesnės.
Skirtingų skyrių darbų eigos
Kelininkai, želdynų priežiūra ir atliekų tvarkymas dirba skirtingai. Vietoj vieno bendro proceso - konfigūruojamos darbų eigos su prieigos valdymu pagal roles: gyventojas, operatorius, brigados vadovas, administratorius.
Realaus laiko sinchronizacija
Gyventojo programėlė, operatoriaus pultas ir brigados įrenginys turi matyti tą pačią būseną. Fono sinchronizacija ir push kanalai (APNs, FCM) ją išlaiko be rankinio atnaujinimo ir be nuolatinio serverio apklausinėjimo.
„Didžiausias iššūkis buvo užtikrinti, kad incidentai pasiektų tinkamą tarnybą be papildomo rankinio darbo - automatinis skirstymas pagal kategoriją ir vietą tapo sistemos stuburu."
- MediaPulsas architektų komanda
Sprendimas
Sukūrėme pilną ekosistemą - nuo gyventojo telefono iki tarnybos dispečerinės:
- Native iOS ir Android programėlės su incidento registravimu per kelis žingsnius
- GIS žemėlapis su automatine geolokacija ir vietos patikslinimu
- Nuotraukų prisegimas su suspaudimu įrenginyje
- Realaus laiko būsenos sekimas ir push pranešimai gyventojui
- Vidinė darbų eigos sistema: priskyrimas, prioritetai, SLA sekimas, audito žurnalas
- Centralizuotas valdymo pultas su incidentų žemėlapiu ir ataskaitomis
Architektūra ir inžineriniai sprendimai
Platformą sudaro trys sluoksniai: native mobiliosios programėlės, REST API su backend servisais ir naršyklėje veikianti valdymo sistema. Pranešimo priėmimas atskirtas nuo apdorojimo: API įrašo incidentą akimirksniu, o dublikatų tikrinimas, kategorizavimas ir skirstymas vyksta asinchroninėje eilėje - todėl net piko metu API atsako vidutiniškai greičiau nei per 500 ms.
Geoerdviniams duomenims naudojamas GIS sluoksnis su GeoJSON formatu: kiekvienas incidentas saugomas su koordinatėmis, o atgalinis geokodavimas jas paverčia adresu operatoriui. Prieiga valdoma pagal keturias roles (gyventojas, operatorius, brigados vadovas, administratorius), kiekvienas veiksmas fiksuojamas audito žurnale, o būsenos pokyčiai gyventojus pasiekia per APNs ir FCM push kanalus - be nuolatinio programėlės apklausinėjimo (polling).
Architektūriniai pasirinkimai: kodėl būtent taip
Kodėl REST, o ne GraphQL?
Viešam, ilgai gyvuosiančiam savivaldybės API svarbiausia paprastumas, kešavimas ir lengva integracija trečiosioms šalims. REST su aiškiais resursais čia laimi prieš GraphQL lankstumą, kurio šiam duomenų modeliui nereikėjo.
Kodėl asinchroninės eilės, o ne sinchroninis apdorojimas?
Pranešimų srautas netolygus: po audros - dešimtys kartų didesnis nei įprastą dieną. Eilė leidžia priimti viską iš karto, o apdoroti pastoviu tempu - sistema nesulėtėja ir nepraranda duomenų.
Kodėl push pranešimai, o ne programėlės apklausinėjimas (polling)?
Polling eikvoja bateriją ir generuoja tuščią apkrovą serveriui. APNs ir FCM kanalai būseną pristato per sekundes tik tada, kai ji realiai pasikeičia.
Kodėl native programėlės, o ne cross-platform?
Projektui kritinės gilios platformų galimybės: tikslus vietos nustatymas, kameros valdymas, fono sinchronizacija ir stabilus push veikimas. Native Swift ir Kotlin čia duoda didžiausią patikimumą.
Kodėl konfigūruojamos darbų eigos, o ne vienas bendras procesas?
Kelininkų, želdynų ir atliekų komandos dirba pagal skirtingas taisykles. Konfigūracija leidžia kiekvienam skyriui turėti savo etapus nekeičiant kodo - ir prijungti naujus skyrius ateityje.
Technologijos
- Swift (iOS)
- Kotlin (Android)
- REST API
- GIS / GeoJSON
- Asinchroninės eilės
- Prieigos valdymas pagal roles
- APNs / FCM push
- Audito žurnalas
- Atgalinis geokodavimas
- Fono sinchronizacija
- Nuotraukų suspaudimas įrenginyje
- SLA sekimas
Rezultatai
Sistema suprojektuota ir apkrovos testais patikrinta realioms viso miesto masto apkrovoms:
Ko išmokome
- GPS mieste nėra idealus - žymeklio patikslinimas naudotojui būtinas, ne pasirinktinas
- Gyventojai dažnai kelia kelias nuotraukas - suspaudimas įrenginyje sutaupo ir laiko, ir saugyklos
- Būsenų modelis turi būti paprastas: per daug statusų klaidina ir operatorius, ir gyventojus
- Push pranešimai apie eigą reikšmingai sumažina pakartotinius kreipimusis tuo pačiu klausimu
Kam tinka panašus sprendimas
- Savivaldybėms ir miestų administracijoms
- Komunalinių paslaugų įmonėms
- Kelių priežiūros organizacijoms
- Energetikos ir šilumos tinklams
- Vandentvarkos įmonėms
- Parkų ir želdynų priežiūrai
- Infrastruktūros valdytojams
- Pastatų administratoriams
Dažniausi klausimai
Kas yra „Vilnius 1355" platforma? +
Kaip veikia problemos pranešimas techniškai? +
Kodėl pasirinkta asinchroninė architektūra? +
Ar panašią sistemą galima pritaikyti kitai savivaldybei ar įmonei? +
Kas Lietuvoje kuria Smart City ir GovTech sistemas? +
Turite idėją? Paverskime ją produktu
Papasakokite, ką norite pasiekti - per 48 valandas gausite apimties ir biudžeto įvertinimą bei mūsų siūlymą, nuo ko pradėti. Nemokamai ir be įsipareigojimų.