Hvor mye strøm kan vindturbiner produsere på et gitt sted i verden? Og kan vi være sikker på at antagelsen vår er riktig? Dette er en lang artikkel om hvordan designprosessen fra ide til flere ferdige produkter i Equinor har foregått over flere år. Hent deg noe å drikke, for dette er et dypdykk.

Hvordan det hele begynte i 2022

These Ways fikk en forespørsel om designoppdrag for havvind: Hvordan kan de ansatte i fornybar-satsingen hos Equinor raskere finne og bruke data som viser hvor mye vinden blåser hvor som helst på kloden?

La oss begynne i 2022, og se for deg at du sitter i møte med en av Norges største bedrifter. Det er en liten uke siden oppstart og din jobb er å designe produkter for å bedre arbeidshverdagen til de som planlegger havvindsprosjekter. Du lytter, tar notater fra ingeniørene som snakker og virkelig har peiling. I et forsøk på å sikre din egen forståelse og vise at du fremdeles henger med, stiller du et oppfølgingsspørsmål:

– “Hvor langt fra land er det gunstig at disse vindmøllene plasseres?”, spør du.
– “OK, vi må bare avklare med en gang. Det er ikke vindmøller, vi lager ikke mel. Det er vindturbiner”, sier ingeniøren.
– “Notert 😬. Vindturbiner heretter.”
– “Alt i orden. Jo, turbinene bør monteres et stykke fra kysten..”, fortsetter ingeniøren. Du noterer og lærer.

Heldigvis kan designere tre inn i rollen som den dummeste i rommet, uten skam. Det må vi for å forstå et problem godt nok til å forsøke å løse det.

Hvordan alt endte opp 4 år senere mens verden endret seg rundt oss, er fortellingen du har foran deg. Det er en historie om design hvor brukeropplevelse omfavner tjenestedesign og ender opp i en arbeidshverdag hvor ting som tok uker er er gjort på timer.

Flere siloer med filtre

Møtet hvor jeg lærte å si vindturbiner, var bare et av mange hvor vi fra These Ways gravde for å finne hva som hindret ingeniører i arbeidet deres.

De vi snakket med beskrev en frustrerende arbeidsdag pga. uoversiktlig data, personavhengige tilganger, lang ventetid og varierende kvalitet på dataen som skulle brukes.

Det førte til usikkerhet om dataen burde brukes, når den først var funnet. Mye tid forsvant i å dobbelsjekke at man hadde det rette settet med data og siste versjon.

Metadata og taksonomi var en del av problemet, men vi besluttet å håndtere den enkleste biten først: La oss katalogisere hvor dataen er og lenke til den fra et sentralt sted, og siden denne dataen var geografisk, ønsket vi legge den på et kart.

Vi laget den minst levedyktige prototypen vi kunne og presenterte den til brukerne, som fort kunne laste ned den værdataen de trengte, ut fra et verdenskart.

En del verdi var levert: Vi beviste verdien av å gjøre dataen lettere å finne og laste ned. Men: vi hadde satt strøm på papir, og dataen var ikke søkbar selv om den lå på fellesdisker. Vi var nødt å løfte værdataen opp i et system som kunne katalogisere og pålegge struktur på dataen. Hele prosessen burde digitaliseres om det skulle gjøres ordentlig.

Design, digitalisering og dataløft

Selv om sankingen av værdata hadde gitt verdi var det fremdeles sovende data, som vi kalte det. Den kan brukes om du klarer å finne den og vekke den. Ingeniører kunne heller ikke enkelt bruke værdata programmatisk via APIer eller lignende.

Et stort dataløft måtte planlegges. Men samtidig måtte vi forstå hvordan dataen ble til og hvem som trengte den. Teamlederen vår hadde et stort nettverk i Equinor og åpnet dører for oss, og vi kom inn i MetOcean avdelingen og begynte en design prosess sammen med dem. Vi måtte lære enda mer 😅, men det er bare gøy! Det er det som gjør design bra!

En kjapp innføring i værdata
Data er også hentet fra ulike leverandører og et av de største datasettene for vær er Copernicus. Det er timesbasert data, for hele verden, fritt tilgjengelig for alle, registrert helt tilbake til 1940. Dataen er inndelt i veldig store regioner. Hvert datapunkt dekker en kvart grads utstrekning for atmosfærisk data, og en halv grad for bølgedata. For enkelhets skyld kan vi si den er geografisk lavoppløst, siden hvert datapunkt dekker et område på omtrent 600 kvadratkilometer. Et punkt dekker altså et område som er større enn Bergen kommune.

---

Denne utstrekningen er et godt utgangspunkt for å identifisere gode områder for havvind (eller for å anslå sjansen for regn i Bergen), men om du skal gjøre noe mer, må du ha mer detaljer. Da må vi lære et nytt ord; Hindcast

---

En beregnet, simulert tidsserie av data, basert på målinger i samme området og utregnet med væskesimuleringer. Alle de resulterende tidsseriene blir sjekket opp mot faktiske målinger, og at dataene er statistisk korrekte mot ekte data. Som oftest blir det laget høyoppløste hindcasts for områder der det skal utvikles vindparker.

Ok la oss fortsette.

Hindcast data er gigantisk; skal vi ha denne dataen søkbar i en nettleser må vi gjøre minst to ting.

1. Designe en løsning hvor dataen kan finnes
2. Ha en dokumentert prosess som lar oss katalogisere og presentere dataen i løsningen etterhvert som mer data blir lagt til.

MetOcean avdelingen i Equinor produserer hindcasts og validerer værdata. De gjør alt som trengs for å at dataen er brukbar, og setter korrekt metadata på den. Ulempen er at metadataen gjerne ikke alltid følger med gjennom siloene.

Sammen med Metocean kartla vi arbeidsprosessen som førte frem til ferdig værdata. Det var ikke realistisk å endre deres avanserte metoder for å produsere dataen, så vi valgte å fokusere på å løfte den ferdige dataen opp i tjenesten vi nå hadde kalt ATMOS.

Samtidig undersøkte vi hva som trengtes for å gjøre denne gigantiske dataen søkbar i ATMOS. Formatet for denne dataen er 4 dimensjonal, siden den har lokasjon (x, y), verdi og tid. Hvert punkt i datasettet kan altså identifiseres på et kart og i tid.

Se for eksempel vindhastigheten i Nordsjøen:

x: 59.993876, y: 2.907281, ws: 8.77, t: 2008-12-12-13:00

x, y, ws, t er fire dimensjoner med data på et spesifikt tidspunkt

I tillegg er dataen lagret med høyder over havet som standard på 10, 100, 150 og 200 meter. Dette er bare for vindhastighet. Det er identisk også for vindretning, lyfttrykk og bølgehøyde. Denne dataen er tilgjengelig for hver 25. kilometer over hele kloden, hver tredje time for alle mulige parametre.

• For å lage ATMOS som et ekte dataprodukt, måtte vi vite hva folk trengte fra dataene, så vi hadde dybdeintervjuer med våre fremtidige brukere. Vi oppdaget flere bruksmønstre, blant annet
• – jevnlig kopi av data til bruk programmatisk
• – ulik typer værdata er nyttig for ulike fagområder
• – tidsperioden for dataen varierte fra fagområde til fagområde

Intervjuene hjalp oss å designe en tjeneste som dekket både brukergrensesnitt og API for programmatisk tilgang.

Datasettene ble også kategorisert som rådata, analysert, modent eller utdatert. Og alt var søkbart og presentert i kart som før. Man kunne laste ned data for spesifikke parametre som bølgehøyde, vindhastighet, lufttrykk etc.

Nå kom forespørslene for alvor. Kan dere legge vindhastigheten oppå kartet så vi kan søke etter potensielle steder i verden? Kan dere legge til produksjonskapasitet for ulike turbiner, kan dere legge til flere kart-lag og mer. Vi var offer for egen suksess. Det var på tide å bygge noe større.

En oase av data og et rikt kart

Vindingeniørene brukte allerede tjenester fra 4C Offshore, en leverandør med et globalt datasett som omfatter alle eksisterende og kommende vindparker. De leverer også innsikt om kommende auksjoner.

Samtidig med arbeidet vårt fantes allerede Global Wind Atlas. Der fins vinddata og du kan gjøre enkle antagelser om produksjon, og det er et begrenset sett med turbiner å velge mellom. Hvorfor kunne vi ikke basere arbeidet på Global Wind Atlas og tjenesten fra 4C Offshore? Equinor ønsker å holde sine prosjektdata hos seg og ikke hos en tredjepart. Derfor ble det planlagt å bygge et nytt produkt som kunne benytte seg av værdataen og turbindata som ligger hos Equinor.

Løsningen som ble brukt for å holde turbindata tilgjengelig var som alle andre steder Excel. Det var et ordentlig rigg rundt tilgang og kontroll, men fremdeles en fare for at data kunne komme på avveie, siden filer ble lastet ned og delt i Teams eller epost.

Produktlinjen for turbiner var eier og ansvarlig for å vedlikeholde turbindataene. Her var det god struktur allerede og et godt utgangspunkt for å digitalisere dataen og gjøre den tilgjengelig på et API.

Designarbeidet hadde flere utfordringer å løse. Ikke bare skal det nye produktet, som da hadde fått navnet Oasis, være enkel å lete i, men det skal også håndtere alt av revisjoner og oppdateringer. Oasis skal ha tilgangskontroll på all data, og en flyt for å lage ny data, revidere og godkjenne. Og grensesnittet skal klare å vise et hvilket som helst dataprodukt i fremtiden. Og alt må serveres på et raskt API.

Samtidig pågikk arbeidet med ATMOS, og søsterapplikasjonen vi kalte Ventus (latin for vind). Mye design og utvikling hendte samtidig, men artikkelen følger produktenes løp for å forhåpentligvis gjøre det enklere å følge. Som designansvarlig for alle tre var det travelt. 😅

Ventus ble den direkte etterfølgeren av ATMOS og brukte mye av det vi lærte mens vi bygget ATMOS. Disse to produktene skilte lag rent teknisk slik at Ventus kunne hente værdata fra ATMOS, men samtidig gi det rike kartet som våre kunder etterspurte. Slik skilte vi data fra bruken og kunne rendyrke to produkter, selv om vi var samme team.

La oss ta en titt på Ventus før vi går tilbake til OASIS, som blir den nye datasentralen til fornybar avdelingen i Equinor.

Ventus blåser inn i tidlig fase

ATMOS hadde mye værdata, men for vindprosjekter i tidlig fase er vind kun en liten del av bildet. Slik vi var heldig med Metocean, fikk vi også innpass i pågående prosjekter i Sør-Korea.

I tidlig fase av et havvindsprosjekt er det mer interessant med informasjon for å planlegge plassering. Kartlag som viste liv i havet, militære øvingsområder, vrak, og havbunnstopologi, var interessant.

På denne tiden var Equinor sine kart-tjenester i en ombyggingsfase fra lokale servere til skybasert, så da kunne vi bistå tidlig fase havvind med kompetansen vår og samtidig lære hvordan kart og havvind kunne finne sammen i Equinor.

Vi brukte mye tid på kartskisser sammen med prosjektene i Sør-Korea. En del av designarbeidet var å lage gode kartlag med visualiseringer og ikoner og farger, men som alt annet på web er det brukeren som styrer hva og hvordan informasjon presenteres. For å unngå at et informasjonslag skjulte et annet, lagde vi en enkel regel. Lagene plasseres i rekkefølge fra havbunnen og opp.

1. Havbunnens sammensetning
2. Ledningsnett på havbunnen
3. Vanndybde
4. Turbinkoordinater
5. Vinddata

Listen over er et eksempel på hvordan vi da har en designregel som gjør at flest mulig lag kan stables uten at feks havbunnen dekker alle de andre.

Om du kommer bort i liknende kartarbeid, er tippecanoe fra Mapbox og kartprogrammet QGIS en gylden kombo, selv om Mapbox har gått videre til Mapbox Tiling Service.

Datalagene i Ventus var mange flere og vi kom opp mot Mapbox sin grense på hvor mange datalag man kan laste inn (15), men vi slo sammen mange lag på forhånd og lagde tiles, som ble lagret hos Mapbox.

Dette skjermbildet har mye nyttig informasjon som vi ikke har diskutert enda. Det mest synlige er selvsagt havbunnssedimentene, men en viktig detalj er turbindataen som er vist i høyre kolonne. Vi la denne turbindataen inn i Ventus basert på samtalene med de som ledet prosjektene i Sør-Korea. De ønsket å vite mulige tall for produksjon og da la vi inn en generell turbin som kunne gi en pekepinn. Denne pekepinnen var god nok i så tidlig fase men den fører oss tilbake til Oasis.

Nå hopper jeg over hele historien om Ventus fordi det var modent nok til å slippe fokus og begynne på Oasis fulltid. Ventus kunne brukes til det Sør-Korea hadde bruk for, men andre prosjekter begynte også å bruke det. Så vi lærte hele tiden av Ventus mens vi bygget Oasis.

Tilbake til oasen

Vi forlot historien om Oasis etter at designkravene var listet ut. Min oppgave som designer var å lage et grensesnitt som kunne tåle alle slags dataprodukter. Sammen med et glimrende team fra Bouvet som stod for utvikling begynte vi å jobbe sammen.

For å lage et grensesnitt som kunne tåle fremtidige datakataloger og støtte arbeidsflyten med revisjoner og godkjenninger var jeg helt nødt å forstå store deler av det tekniske. Vi hadde flere workshops sammen i teamet for å finne ut hvordan tjenesten skulle virke. En av de mest effektive var en tilpasset Event Storming, hvor vi gikk gjennom alle funksjonene og så hvilke systemer og brukere som gjorde hva, steg for steg.

Videre var det å forstå hvordan datamodellene var bygget opp. Siden det skulle tåle fremtidige kataloger måtte grensesnittet være automatisk bygget basert på innholdet i datakatalogen. Mye skisser men tilslutt endte vi opp med å dele inn katalogen i et enkelt liste og detalj-visning som speilet arkitekturen, men innad på et enkelt element, feks en turbin, var de ulike kategoriene av data, sine egne grupperinger.

Det var også noen spesielle grafer som måtte designes, som hvordan en turbin yter i ulike vindhastigheter.

Oasis kjører med mange kataloger og har blitt standard dataplattform for mange prosjekter innen fornybar i Equinor.

OK nå har vi digitalisert mye. La oss returnere til å regne ut hvor mye strøm vi kan lage på et hvilket som helst sted. Det blir en kortere avslutning fordi det siste produktet, Appraise, spiser data fra alle de tjenestene vi har snakket om før.

Inn for landing på sjøen

At all dataen er tilgjengelig betyr ikke at oppgaven er lettere å designe for. Vi har god hjelp i grensesnittet med Equinors Design System, så det fjerner en del av diskusjonene, men brukeropplevelsen må fremdeles tenkes grundig gjennom. Vi har lært mye om hvordan en vindingeniør jobber i løpet av prosjekttiden, men arbeidsmetodene har selvsagt endret seg etter at de ulike datakildene er blitt ordentlig digitalisert.

Værdata er lett å finne, turbindata kan enklere brukes og mnens vi bygget alt det, var også Appraise i utvikling parallellt. Derfor har opplevelsen der også blitt gradvis enklere og enklere.

I starten var det mye input og lite kontroll av at data var rett lagt inn.

Turbiner ble valgt fra en nedtrekksliste og det ble lagt vekt på mye manuelt arbeid. Dette var også en modningsprosess ettersom tilliten til verktøyet måtte fortjenes. Brukerne måtte føle at de hadde kontroll.

Med tiden utviklet vi en rikere applikasjon basert på arbeidsflyten til vindingeniørene. Nå var programmet bygget opp til å følge den logiske progresjonen av en site, hvor man begynte med et område, valgte turbin, og deretter laget en layout.

Dette fungerte en god stund, men brukertesting over tid viste også at vi kunne forenkle enda mer og vi måtte ha flere verktøy, mens vi kunne fjerne andre.

En stor ting vi måtte løse var hvordan omkringliggende parker (vi kaller dem eksterne) påvirker den parken som planlegges å bygge. Slik du skjuler deg for vinden ved å stille deg bak et hushjørne, dekker også andre vindparker for vinden som treffer dine turbiner. Denne effekten kalles et vaketap og må minimeres for best mulig strømproduksjon.

Vi har allerede informasjon om hvilke parker som allerede fins, og som blir planlagt, takket være 4C Offshore datasettet. Det må bare tegnes inn i planen for parken. Men det er enklere sagt enn gjort. Noen eksterne parker forsvinner i løpet av hovedparkens levetid og slutter dermed å skygge for vinden. Det må taes med i beregningene også. Alt dette må pakkes inn i et grensesnitt som skal være raskt, enkelt og oversiktlig. Samtidig ønsker brukerne mer plass til kart og mindre bruk av skjermen til å legge inn data.

Etter mange år innen havvind vet vi at produktet vårt er modent og leverer gode svar på hvor mye det blåser og strøm kan vi produsere hvor som helst i verden.

Appraise kan i dag levere det svaret, med hjelp av gode tjenester, designet sammen med brukere og forretningen, samlet i et oversiktlig grensesnitt med rik kartdata og kraftige verktøy. Nå viser Appraise deg kun kontekst av det som er med i en utregning og som standard er det ingenting. Skroll videre ned for å se eksempler på hvordan et havvinds design kan se ut under planlegging.

Litt skjermbilder

Merk at alle lokasjoner er helt vilkårlig og stemmer ikke med Equinors planer for det området.