Sludd: hvordan løse et problem som ikke eksisterer

Dette er fortellingen om hvordan vi skulle vinne halve kongeriket innen kraftbransjen med IoT, droner og maskinlæring – men endte med et krasjkurs i innovative prosesser og design thinking.

Øyvind Fredstie

Trykk på taggene for å lese mer om hvor og hvordan vi benytter samme fag og teknologi


Som mange andre historier så startet denne med en god ide, en ide hvor man skulle kombinere IoT, droner og maskinlæring for å skaffe seg det noen kaller for prinsessen og halve kongeriket innen kraftbransjen, nemlig kontinuerlig og ikke minst nøyaktig beregning av hvor mye smeltevann det er i snø, også kalt snøens vannekvivalent.

Ideen oppstod da jeg kom over et bilde i sosiale medier hvor ansatte fra en kraftprodusent var ute i fjellheimen og gjorde snømålinger. Jeg tenkte at det måtte være veldig tidkrevende å gjøre slike målinger på «gamlemåten» og at det måtte være rom for forbedringer.

Gradvis utviklet dette seg til et konsept hvor vi skulle plassere ut et stort antall små IoT-enheter i felt og kombinere data fra disse enhetene med data fra droner, for å kunne gi kontinuerlige beregninger av hvor mye smeltevann det var i nedfallsområdene rundt vannmagasiner.

Jeg ble mer og mer overbevist om at dette var en god ide og bestemte meg for å drøfte ideen med kollegaer. Responsen var god, inntrykket generelt var at dette var en spennende ide som hadde potensiale for å være samfunnsnyttig og involverte design, skyløsninger, maskinlæring og ikke minst IoT.

 

Om forfatteren av innlegget

Øyvind Fredstie har flere års erfaring fra softwareutvikling i ulike industrier. Han har i over fire år jobbet som konsulent ved Bouvet i Rogaland.

 
T024XURJ2-U62T2LA75-86567b1ed42c-512.png

 

 

Visjonen 

Prosjektet startet opp i oktober 2022 og vi endte opp med å gi det navnet Sludd.io, kort og godt fordi sludd er en blanding av snø og regn. Etter å ha snakket med Olavstoppen om prosjektet fikk jeg også hjelp fra designerne Line Due-Olsen og Henrik Dønnestad for å kunne ta konseptet videre.

Vi startet med å formulere en testbar hypotese for hvordan problemet kunne løses og landet på «snøens vannekvivalent kan estimeres ved hjelp av et distribuert nettverk av IoT sensorer og volum-målinger».

I tillegg ønsket vi å konkretisere hva den overordnede visjonen og den mer kortsiktige misjonen for tjenesten skulle være og etter litt diskusjon landet vi på: «Sludd skal estimere snø vann-ekvivalenter» som misjon og «å gi detaljert innsikt for fremtidige muligheter» som visjon.

«Sludd skal estimere snø vann-ekvivalenter» som misjon og «å gi detaljert innsikt for fremtidige muligheter» som visjon.

 

SWOT-analyse

For å få litt innsikt i hva som kunne være styrkene og svakhetene med tjenesten ble det gjennomførte en SWOT analyse i samhandlingsplattformen Miro. Ideer om mulige styrker, svakheter, muligheter og trusler ble notert ned på virtuelle post-it lapper og brukt i det videre arbeidet av tjenesten.

sludd.io - SWOT.jpg

 

 

Vi snakket med flere personer både internt i Bouvet og eksternt, og responsen fra de var generelt positiv over hele linjen. Men vi hadde en ting som skapte en bitte liten vond magefølelse; vi var klare over at ingen av de vi hadde snakket med hadde fagekspertise innen problem-området. Med andre ord manglet vi ett av tre viktige kriterier innen Design Thinking, nærmere bestemt viability; kort og godt personer med innsikt og erfaring innen det problemet en ønsker å løse.

 

modell.png

Men vi så på dette mer på som en utfordring enn en stopper. Vi jobbet derfor målrettet videre med å videreutvikle konseptet, samtidig som vi parallelt brukte nettverket vårt for å forsøke og etablere kontakt med noen som hadde innsikt i fagfeltet. Det ble også ofte diskutert hva vi kunne gjøre for å skape interesse hos de med fagekspertisen slik at man fikk behovsprøvd ideen.

IoT-modulen

Som en del av denne prosessen designet vi en 3D-modell av hvordan denne IoT-modulen muligens kunne sett ut. Denne modulen skulle være lett å montere, den skulle måle avstanden til en overflate av snø, is, vann, stein eller jord, og den måtte ha solskjerming for å kunne måle mest mulig korrekt lufttemperatur. Denne modellen ble igjen brukt til å produsere bildemateriale og animasjoner som viste produktet i sin naturlige omgivelse.

sludd.io - IoT Modulen.jpg

Dronen

I tillegg til data fra mange IoT-moduler, var tanken at vi i samarbeid med Senseloop skulle supplere med data fra droner, nærmere bestemt med droner påmontert Lidar-skanner. 

Ideen her var at vi ved å sammenligne skanninger av områder, før og etter snøen kom, ville vi kunne gjøre ganske nøyaktige beregninger for hvor mange kubikk snø det var i de gitte områdene.  

 

Senseloop_drone.jpeg

 

Skyløsningen

Vi hadde også en rekke tanker og ideer om hvordan skyløsningen kunne se ut i Azure og her gikk vi for C4 Model for å identifisere, navngi og beskrive de nødvendige modulene i arkitekturen. Værdata ville bli hentet fra IoT sensorene og fra Meteorologisk Institutt sitt API, mens Lidar skanninger samt manuelle snømålinger ville bli matet inn via vårt eget API.

sludd.io - C4 model - Level 1.jpg
sludd.io - C4 model - Level 2.jpg

 

Workshop med forskere

Prosjektet var nå i midten av november og litt i frustrasjon av å ikke komme noe videre når det gjaldt fagekspertisen, valgte vi å sende en e-post til noen snøforskere. Responsen var positiv og kort tid etterpå ble avtalt å møtes til en halv-dags workshop. Formålet med denne workshopen var å få en realitetssjekk om utfordringene med beregning av snøens vannekvivalent, i tillegg til om tjenesten var verdt å jobbe videre med. Og en realitetssjekk, det ble det så absolutt.

workshopm forskere.png

 

Så var endelig dagen der da vi skulle få svar på mange av de ubesvarte spørsmålene vi satt med. Forskerne var ikke vanskelig å be, de satte i gang og det ble fort klart at utfordringene med beregning av snøens vannekvivalent ikke var et resultat av at man manglet data eller tilgang på en liten og rimelig IoT-sensor. Vi hadde på forhånd forstått at det var blitt forsket aktivt på det aktuelle fagfeltet i lang tid, men vi fikk nå en langt bedre innsikt for hvorfor det å si noe om snøens indre oppbygning var notorisk vanskelig.

Mange løsninger var blitt utviklet for beregning av snøens vannekvivalent, men den mest pålitelige har hele tiden vært å gjennomføre manuelle kjerneprøver av snølagene med snørør, gjerne i form av snøstrekk over flere hundre meter. Automatiske snøvekter i forskjellige størrelser og utforminger er også populære, men det er mange utfordringer her som påvirker disse målingene. Alt fra småkryp som spiser opp komponenter, til snø som danne seg isbruer som kan spre vekten av snøen over et større område.

En annen stor utfordring med automatiske målinger er at man vanskelig kan sammenligne flere punktmålinger med hverandre, fordi hvor man gjør målingene har så mye å si. To målinger med kun et par meters avstand imellom seg kan ha store variasjoner i både snødybde og vanninnhold, for eksempel hvor en måling er tatt på toppen av en liten nut mens den andre målingen er tatt i en grøft.

 

 

forskerworkshop2.png

Når det gjelder punktmålinger så var det altså ikke pris per sensor som var det kostnadsdrivende, det var timene som gikk med på installasjon, drift og vedlikehold. I tillegg kom indirekte kostnader når utstyr sviktet, som igjen forårsaket i at datamodellene stoppet.

Sist, men ikke minst, hvor mye smeltevann det er i snøen varierer også veldig mye. Nyfallen snø har en vekt vanligvis ned mot 0.1 kg per liter, mens kompakt smelteklar snø har en vekt opp mot 0.5 kg per liter. Man kan også si at snø som har lagt seg før 1. februar vil ha en vekt som trender mot den lavere verdien, mens snø etter denne datoen vil ha en vekt som trender mot den høyere verdien.

 

snø.png

Deling av data

Et annet interessant aspekt, og noe vi ikke hadde forutsett, var at det for store produsenter å dele denne type data med andre aktører, ville være å gi fra seg et stort konkurransefortrinn, siden de ved å ha god innsikt over sine områder ga indirekte innsikt i hvor mye strøm konkurrentene kunne produsere. Vi lærte også at kraftprodusentene er lovpålagt å dele disse dataene med NVE, men at det er tre måneders karantenetid.

Alt i alt ble det en skikkelig realitetsjekk for oss. Her hadde vi brukt mange timer på å utvikle det vi tenkte var et spennende konsept, men når vi endelig fikk muligheten til å snakke med fagekspertisen så ble det veldig tydelig at konseptet ikke ville løse det problemet vi hadde sett for oss.

Så, hva lærte vi og hva kunne vært gjort annerledes?

Vel, den største lærdommen fra møtet med forskerne var at en ny sensor absolutt ikke ville løse noen av utfordringene med beregning av snøens vannekvivalent.

Vi hadde korrekt identifisert en mulig tjeneste som det utvilsomt var knyttet store verdier mot og som involverte tekniske løsninger som man hadde ganske god kontroll over, men vi hadde altså ikke en god forståelse for hva som var de virkelige utfordringene med å beregne snøens vannekvivalent. Av den grunn burde vi aldri ha startet prosjektet før vi hadde dekket alle tre Design Thinking kriteriene og samtidig som vi hadde veldig god innsikt i problemet som skulle løses.

I etterpåklokskapens lys så burde vi selvfølgelig ha gjennomført workshopen med forskerne på den aller første dagen av prosjektet, men kontakten med de skjedde altså som et resultat av det arbeidet som ble lagt ned i oktober og november 2022.  

Vi lærte også at en ide kan virke både spennende og nyttig, men uten en detaljert forståelse av problemet som skal løses så risikerer man fort å løse feil problem. Man kan selvfølgelig være heldig og utvikle en løsning som ingen har tenkt på før, men sjansen for det er nok ganske liten.

Vi havnet i en situasjon hvor vi hadde inntrykk av at ideen var bra og ved å bruke tid på denne nå kunne vi skape interesse hos en mulig samarbeidspartner med den rette erfaringen etter hvert. Men ting tok tid, timer ble fort til dager og uker før man har kom videre i prosjektet.

Hva med veien videre?

Gjennom dialogen med forskerne ble det klart at det er fortsatt store rom for forbedringer når det gjelder beregning av snøens vannekvivalent, men at fokuset muligens bør være på analysering av eksisterende datakilder fremfor nye type sensorer. Bruk av data fra droner og satellitter er også et spennende område som kan ha potensiale for å redusere feilmarginene for beregning av snøens vannekvivalent samtidig som man muligens kan gjøre beregninger over store områder.

Men for Sludd sin del, som et IoT prosjekt, så ble det tydelig at det ikke var liv laget og at det eneste rette valget var å avslutte prosjektet.

Men det ligger fremdeles store verdier i smelteklar snø, noe som igjen betyr at det er betalingsvilje for mer detaljerte og nøyaktige beregninger av snøens vannekvivalenter. Men istedenfor å sette søkelys på å utvikle en ny modul som skal revolusjonere industrien, så kan det nok være fornuftig å fokusere på å videreutvikle løsninger med utgangspunkt i eksisterende teknologi og datakilder.