Softverski sloj gradske mreže za monitoring vazduha

Sredinom 2010-ih radio sam na softverskom sloju projekta povezanog sa gradskom infrastrukturom za monitoring atmosferskog vazduha u Sankt Peterburgu. To nije bio običan web razvoj, već deo gradske infrastrukture: automatske stanice po gradskim delovima, gasni analizatori, redovna merenja, slanje podataka u centar za prikupljanje i obradu, čuvanje merenja i objavljivanje informacija.

U praksi, to je bio industrijski sistem sa fizičkim instrumentima i udaljenim prikupljanjem podataka pre nego što je termin "Internet of Things" postao uobičajen. Sistem je imao stvarne uređaje, COM portove, modemsku vezu, međufajlove sa merenjima, centralnu obradu, izveštavanje i zahteve za pouzdanošću. Moj rad se odnosio na jedan softverski sloj već postojeće gradske infrastrukture: ceo sistem nije pravljen od nule, ali je stanični deo trebalo dovesti u stanje koje se lakše održava.

Pošalji brif

Slika 1. Offline mapa sa tačkama stanica za monitoring vazduha. Te fizičke tačke posmatranja bile su glavni izvor podataka za softverski sloj.

Kontekst sistema

Gradski sistem se koristio za ekološki monitoring atmosferskog vazduha. Automatske stanice su kontinuirano merile zagađujuće materije, a rezultati su u redovnim intervalima stizali u centralnu bazu i dalje se koristili za obradu, izveštavanje i informisanje.

U ovakvim sistemima softverski sloj ne radi sa apstraktnim prijavama iz forme, već sa tokom fizičkih merenja. Sa jedne strane su instrumenti, senzori, portovi, modemi, lokalni fajlovi i inženjeri koji dolaze na stanicu. Sa druge strane su centralna obrada, čuvanje, kontrola kvaliteta podataka i objavljivanje rezultata.

Sistem je automatski merio ugljen-monoksid, azot-monoksid, azot-dioksid, suspendovane čestice PM10 i sumpor-dioksid. Neautomatizovano su praćeni benzen, toluen, etilbenzen, ksileni i fenol. Deo takvih merenja mogao je da uključuje poluautomatsko uzorkovanje i naknadnu laboratorijsku analizu.

Početno stanje

U trenutku mog rada glavni problem nije bio samo u kodu, već i u načinu eksploatacije. Softverski deo je već radio u produkciji, ali oko njega skoro da nije postojao normalan inženjerski okvir: dokumentacija, ponovljivo pokretanje, jasna istorija izmena i pažljiv proces isporuke ažuriranja.

Takvo stanje je tipično za dugovečne industrijske sisteme. Kod živi blizu opreme, menja se kada se pojave problemi, deo znanja ostaje kod pojedinaca, a dokumentacija nastaje kasnije od samog sistema. Dok sve radi, to može izgledati prihvatljivo. Ali zamena stanice, odlazak inženjera na objekat, povezivanje novog instrumenta ili ispravka greške postaju ručna operacija sa visokim rizikom.

Šta je trebalo uraditi

• Prebaciti radni kod u repozitorijum i učiniti ga glavnim izvorom.
• Opisati proces izmena: zadaci, grane, commit-i, provera i ulazak izmena u produkciju.
• Pripremiti dokumentaciju za stanični deo: instalacija OS-a, okruženje, konfiguracija instrumenata, pokretanje servisa, backup i ažuriranje koda.
• Pojednostaviti održavanje stanica za inženjere koji dolaze na objekat i treba brzo da razumeju šta i kako ažuriraju.
• Uključiti praktikante i mlađe stručnjake tako da mogu da pomognu sa dokumentacijom, proverama i prenosom znanja bez rizika za produkciju.
• Sačuvati rad postojećeg sistema: ovo je bio infrastrukturni posao, a ne greenfield projekat u kome sve može da se prepiše.

Repozitorijum, dokumentacija i isporuka

Prvi sloj posla bio je organizaciono-inženjerski: dovesti kod i dokumentaciju u stanje sa kojim može da se živi. Za izmene je uveden proces kroz zadatke i posebne grane. Commit-i su se vezivali za zadatke, izmene su se testirale pre spajanja, a grana master se tretirala kao verzija za produkciju koja može da se instalira na radnu stanicu.

To nije bio savremeni cloud CI/CD u smislu kontejnera, staging klastera i automatskog deploy-a na svaku stanicu. Stanice su mogle da imaju ograničenja u vezi, a deo ažuriranja se radio na licu mesta. Ali to je bio važan korak ka kontrolisanoj isporuci: kod je prestao da bude skup fajlova "negde u produkciji", pojavila se istorija izmena, pojavila su se pravila ulaska u produkciju, pojavila se test stanica i jasan način da se radne stanice ažuriraju iz repozitorijuma.

Posebno je pripremljena operativna dokumentacija: kako sve pripremiti, koji radni direktorijumi su potrebni, gde se nalaze konfiguracije, kako se instrumenti vezuju za portove, kako se pokreće monitoring u realnom vremenu, kako se podešava backup merenja i automatsko pokretanje staničnih procesa.

Slika 2. Šema rada softvera stanice za monitoring iz radnih materijala projekta.

Stanični deo

Stanica nije bila apstraktni "API klijent", već računar pored merne opreme. Na njega su bili povezani gasni analizatori, meteorološki senzori, senzori zračenja i servisna oprema. Veliki deo komunikacije išao je preko serijskih portova, pa je dokumentacija posebno opisivala MOXA ploče za proširenje broja COM portova i vezivanje konkretnih instrumenata za konkretne uređaje kao što su /dev/ttyM0, /dev/ttyM3 ili /dev/ttyS0.

U radnim materijalima bili su opisani različiti tipovi instrumenata: ThermoElectron, Environnement, Horiba, Automet, WXT520, DKGRAD, FDS. Za njih su bili zabeleženi mereni parametri i jedinice: NO, NO2, SO2, CO, O3, PM10/PM2.5, temperatura, vlažnost, pritisak, brzina i smer vetra, radijaciona pozadina. To dobro pokazuje prirodu zadatka: softverski sloj je morao da bude pouzdan posrednik između fizičkih instrumenata i dalje obrade podataka.

Podaci se nisu čitali sa lepog interfejsa na ekranu, već sa porta: sirove vrednosti koje je trebalo ispravno pročitati, normalizovati, sačuvati i poslati dalje.

Slika 3. Očitavanja instrumenta na stanici: NO, NO2 i NOx u mg/m³.

Unutar staničnog dela postojali su posebni procesi za prikupljanje i kontrolu podataka. Rezultati merenja su se upisivali u radne direktorijume, a centar je mogao da preuzima pripremljene fajlove. Za inženjera na stanici važne su bile ponovljive komande: šta pokrenuti, gde pogledati živa očitavanja, kako proveriti port i kako ne izgubiti podatke posle restartovanja.

Tiny Core Linux

Poseban deo projekta bio je stanični operativni sistem na Tiny Core Linux-u. To je bio pragmatičan izbor za terenske uslove: sistem se pokretao sa fleš diska, radio iz RAM-a i omogućavao da se potrebna konfiguracija sačuva nazad na nosač. Takav pristup je pojednostavljivao održavanje stanice i smanjivao zavisnost od stanja lokalnog diska.

Radno okruženje stanice uključivalo je Perl, git, minicom, pppd, inetutils, Log::Log4perl, JSON i dodatne pakete za rad sa serijskim portovima. Deo zavisnosti morao je posebno da se kompajlira i pakuje za Tiny Core, na primer Perl moduli za SerialPort i BufferedSelect, MOXA drajveri, mgetty i Vim. To je bio niskonivovski operativni posao: ne samo napisati skriptu, već obezbediti da se ona podigne posle restartovanja stanice i nastavi da radi pored instrumenata.

Rad sa timom

Još jedan deo rezultata bilo je uključivanje ljudi u projekat. Kada sistem postoji samo kao kod u produkciji i usmeno znanje, praktikanta ili mlađeg developera nije moguće bezbedno uključiti. Prvo treba opisati granice: gde je dokumentacija, gde je repozitorijum, kako se otvaraju zadaci, šta sme da se menja, šta se proverava na test stanici i kako izgleda ispravno ažuriranje.

Posle toga praktikanti su mogli da uzimaju ograničene zadatke: sređivanje uputstava, proveru koraka instalacije, beleženje podešavanja, razjašnjavanje konfiguracija i prenos znanja u README fajlove. Za industrijski sistem sa nasleđenim kodom to nije sporedan posao, već način da se smanji zavisnost od jedne osobe i da održavanje postane stabilnije.

Rezultat

• Kod staničnog dela prebačen je u repozitorijum i postao upravljiv artefakt, a ne skup fajlova u produkciji.
• Opisan je proces izmena: zadaci, grane, commit-i, testiranje i ulazak u produkcionu granu.
• Pojavila se operativna dokumentacija za Tiny Core Linux, pakete, automatsko pokretanje, ssh, cron, backup i komunikaciju stanice sa centrom.
• Dokumentovani su konfiguracioni principi za instrumente, portove, isključivanje merenja i pokretanje staničnih procesa.
• Projekat je postalo lakše predati inženjerima i mlađim stručnjacima: deo znanja je prestao da bude usmen.
• Sistem je zadržao praktičan fokus: ne prepisivanje radi prepisivanja, već bolja održivost gradske infrastrukture koja radi.

Ako vam treba sličan rezultat: pomažem da se razumeju nasleđeni sistemi oko podataka, obnovi dokumentacija, postave repozitorijum i proces isporuke, upakuje operativno znanje i smanje rizici održavanja.

Pošalji brif