Hur samlas data in för att sedan omvandlas till användbar information för stadens beslutsfattare? Vilken väg tar den från den fysiska världen (fältet) till den digitala världen (lagring, AI, verksamhetsapplikationer mm.)? Förklaringar.
Databehandlingssystem via ”smarta” miljöer kan te sig som en riktig labyrint för den oinvigde. I början av kedjan finns sensorer som samlar in all data från fältet och omvandlar den till digital information. På så sätt får man reda på temperaturer, soptunnors fyllnadsgrad eller koldioxidhalter. Förutom dessa fältuppgifter hämtar man även in data från externa system som bl.a. vädret.
På andra änden av denna outgrundliga stig finner man den komplexa applikationsvärlden vars syfte är att ge stöd till beslut om åtgärder. Man talar t.ex. då om verksamhetsapplikationer som används av stadens teknikavdelningar eller om webb- eller mobila applikationer för operativ personal och slutanvändare.
Men det finns ett helt, mer obskyrt segment mellan det uppkopplade objektet och appen. Dess byggstenar berikar rådatan för att ge informationen ett mervärde som gör det möjligt att ta beslut och agera. Den första etappen i denna ”svarta låda” handlar om att samla in data genom alla möjliga typer av sensorer, vilket kräver kapacitet att läsa alla kommunikationsprotokoll sensorerna använder.
Inflöden till ”data lake”
Uppgifter av alla typer, och framför allt av alla format strömmar sedan in till en ”data lake”, som är en samling ”ostrukturerad och oförändrad data”. Det är en lagringszon som måste vara välstrukturerad för att inte dataingenjörerna ska famla i mörkret innan de hittar rätt. De kan ägna 75 procent av sin tid åt att ”tvätta datan” innan de lyckas tolka den” förklarar Gwendal Azous, IoT-konsult hos Axians, som är VINCI Energies IT-varumärke.
En temperaturuppgift kan ömsom anges i Celsiusgrader och ömsom i Fahrenheitgrader. För mer effektivitet krävs det att uppgiften blir enhetlig.
Axians använder därför en mjukvara i början av lagringskedjan för att standardisera datan. Ett temperaturvärde i Fahrenheit omvandlas då automatiskt till Celsius om kunden valt den standarden med sin integrerare. Detsamma gäller datum som skrivs i olika format beroende på land. ”Data lake-strukturen” påpekar Édouard Henry-Biabaud, Business Development Manager Axians, är helt avgörande för systemets effektivitet. ”
När datan väl standardiserats följer den en väg genom olika databaser som utgör ”data lake”. Den har olika lagringsegenskaper kallade ”data persistence” (datans livslängd), tillgångshastighet och lagringskapacitet, beroende på hur den ska behandlas.
Varma, ljumna och kalla databaser
De s.k. ”varma” databaserna, såsom relationsdatabaser (av SQL-typ) gör det möjligt att mycket snabbt få tillgång till datauppgifterna för att närmast behandla dem i realtid. Det är t.ex. där man hittar objektreferensen, bevakningsdata som kräver en omedelbar behandling eller reaktion. Uppgifterna har en begränsad lagringstid, mellan en och fyra veckor.
Efter den tiden förstörs inte datan utan den överförs till en ”kall” databas för arkivering. I en sådan databas är inte tiden för att få tillgång till uppgifterna viktig.
”Från värden såsom fotgängarflödet, vädret och parkeringens fyllnadsgrad kan vi förutse en butiks fyllnadsgrad”
De s.k. ”ljumna” databaserna tillhör big data-världen och har kapacitet för stora volymer och hög bearbetningshastighet av data som sedan används i dataanalysprocesser och ”smarta” algoritmer.
”Den typen av data är tillgänglig i minst ett år (beroende i hög grad på antal användningsområden och datavolym). Den kommer att användas för prognosanalys i syfte att optimera underhållet eller föregripa beteenden och ta beslut innan en händelse inträffar” förklarar Edouard Henry-Biabaud.
En viktig fas i behandlingen av datan handlar om att sätta den i sitt sammanhang. ”Rådatan ”det är 22 grader” säger egentligen inte så mycket. När den väl har samkörts med månads- och platsinformation får den däremot en betydelse. 22° Paris i januari – det är varmt. I augusti är det normalt. När de samkörts av dataanalytiker berikas datauppgifterna för att ge information som behandlas genom AI och leder till kunskap” säger Edouard Henry-Biabaud.
”Från tre värden såsom fotgängarflödet, vädret och parkeringens fyllnadsgrad kan vi förutse butikens fyllnadsgrad” lägger Gwendal Azous till.
Appar för att agera
När datan väl insamlats, standardiserats och lagrats i lämplig databas börjar den fungera som ”bränsle” för slutapplikationerna. Poängen med en sådan arkitektur för en stad eller ett företag är att det blir väldigt enkelt att använda flera olika applikationer som hämtar nödvändig information från de varma, kalla och ljumna databaserna i denna unika ”data lake”.
Det är olika typer av applikationer som får tillgång till databaserna via APIs (gränssnitt som hjälper program att kommunicera med varandra): å ena sidan, verksamhetsprogram som ger en detaljerad bild av ett visst användningsområde, såsom styrningen av gatubelysningen, luftkvalitén eller sophämtningen. Den typen av applikationer hjälper stadens tekniska avdelningar – som ofta är uppdelade i insatsområden – att få tillgång till relevant information för att utföra sina uppgifter.
Och å andra sidan, övergripande applikationer som kopplar samman information från olika användningsområden för att ge en bred bild snarare än ett siloperspektiv över stadens verksamhet. Ett hypervisorprogram kan installeras ovanför systemet för att underlätta visualiseringen och därmed beaktandet av viktig information från de olika applikationerna.
Från datainsamling till behandling genererar stadens IT-struktur rätt kunskap för beslutsfattande – i slutändan är det ju en välinformerad människa som tar besluten, inte algoritmen!
14/11/2019