Praktiske erfaringer med digital tvilling

Du har kanskje hørt om digital tvilling før, men har du noen gang tenkt på hvor kompleks en slik sak kan være å stable på beina? Dette er en gjenfortelling fra et nylig ferdigstilt oppdrag, en såkalt Proof-of-Concept test (heretter forkortet ‘PoC’) av digital tvilling som visuell informasjonskilde. Oppdraget ble utført på vegne av og sammen med Kartverket. Vi har fått deres godkjenning for å dele dette blogginnlegget.

Kartverket er en institusjon med røtter tilbake til 1700-tallet. De ivaretar flere samfunnsoppdrag, sentralt i dette står kartlegging, koordinering og tilgjengeliggjøring av stedfestet informasjon. En sentral tjeneste de tilbyr på vegne av mange samarbeidende parter er Geonorge. Dette er en portal som gir tilgang til både kart og åpne data om veldig mye; ‘alt’ fra arealer og eiendommer til bunn­sediment i havet og jordsmonn på land. Kartverket ønsker å forbedre seg, og i den sammenheng anses digital tvilling som en relevant del av målbildet.

Hvorfor digitale tvillinger? 

Hvilke målsetninger eventuelle adoptører har vil variere. Men man kan genera­lisere og si at digitale tvillinger eksisterer stort sett for å gi brukerne informasjon, den viktigste forutsetningen for kvalifi­serte beslutninger. Primært i form av oversikt, even­tuelt også innsikt. Den klart viktigste egenskapen til digitale tvillinger er (gitt at de er bra bygget) at de gir mulighet til å belyse sammenhengene mellom forskjellige forhold, presentert på en visuelt lettfattelig måte, tett opp imot virkeligheten. Skulle man eksempelvis vurdere å kjøpe en eiendom og bygge på den, kan det å kikke på den i kom­mu­nal sammenheng avdekke mulige inn­virk­ende forhold, slik som til­knyt­ning til vann og kloakk, elektrisk og eventuelt fiber­op­tisk infrastruktur, ytterligere reguleringsplaner, mm. Og hvis man så skulle ønske å bygge bolighus på tomten kan man sjekke utsikt og solforhold – i ulike himmel­retninger, fra ulike etasjeplan – før man bestemmer seg. Og hvis mange aktører tar i bruk den samme digitale tvillingen (underforstått: legge inn deres egne data) kan man kjøre hva-hvis-analyser om svært mange forhold – alle det måtte finnes data­grunn­lag for.

Da vi fikk oppdraget merket vi oss ved primærhensikten: Å teste ut programvaren Terria for å la folk flest få tilgang til en velfungerende digital tvilling, slik som Australia faktisk har tilbudt befolkningen gjennom de siste par årene (her finner du en tre minutters video om «NSW Spatial Digital Twin». Den er vel verdt å se). Senere i oppdraget ble vi mer bevisste på en formulering i forespørselen som gikk på det at kunden ønsket seg et team med to juniorutviklere (fulltid) og en prosjektleder (deltid). Inn­led­ningsvis forsto vi ikke helt rasjonalet bak dette, og antok bare at det måtte være for å spare kostnader. Men etter hvert ble det klart for oss at hensikten var å finne ut hvor lett eller vanskelig det er å jobbe med GIS (Geografisk Informa­sjons-Systemer) og geodata når man kommer inn i feltet utenifra; dvs. uten å tilhøre ‘stammen’ av profe­sjonelle som driver med slikt til daglig. Kartverket ønsket å få bedre innsikt i hvilke barrierer og utfordringer et utviklermiljø kan støte på når de vil implementere en digital tvilling med bruk av data og tjenester fra Geonorge - og lærekurven viste seg å være bratt, men mulig – og spennende!

Over ser vi New South Wales-demonstratoren (ref. teksten i avsnittet over) som på mange måter startet forfatterens beundrings- og forundringsreise – en reise som fortsatt pågår.  

Opplegg og deltakere

Sammen med FoU-direktør Reidun Kittelsrud hadde Kartverket satt sammen et eget innsatsteam, bredt repre­sentert fra forskjellige fagområder. I tillegg deltok Knowit sitt leveranseteam (to nyansatte utviklere og under­tegnede), den resterende Kartverket-organisasjonen (‘linjen’) samt representanter fra den australske forsknings­organisasjonen CSIRO Data61, mao. utviklerne bak TerriaJS (mer om dette senere). Vi fikk en oversikt over hva som skulle gjøres og satte i gang. For å holde kunden orientert og eventuelt justere kurs underveis ble det avholdt ukentlige statusmøter. Ut over dette jobbet vi mest på egenhånd, kun avbrutt av fokusmøter med folk fra linjen.

Hva er en digital tvilling, egentlig?

Selv om både ISO og andre har kommet på banen med referanse­arki­tek­turer og annet er nok svaret at ‘det kommer an på hvem du spør’. Vi liker å si at det er en slags virtuell skygge eller representasjon av virkeligheten. Hvor presis og/eller oppdatert den er, ja det er sånt som ‘det kommer an på’. Det er ikke uvanlig at virksomheter nærmest setter likhetstegn mellom digital tvilling og 3D-modeller. Men slike modeller viser gjerne frittstående kopier av et produkt (som bil, møbler eller klær) eller en gitt fysisk installasjon (som et bygg og/eller veistrekning, gjerne komplettert med slikt som hageanlegg, gangveier og av-/­på­kjøringer).

Den forståelsen av digital tvilling som legges til grunn her er en stedfestet (eller geospatial) avbildning av «hele» den fysiske virkeligheten der ute. Når «hele» står i anførselstegn er det fordi vi her begrenset oss til elementer som kunne falle innenfor rammene av Norge, og nærmere bestemt knyttet til to byregioner; Stavanger og Oslo.

Over ser vi ISO referansearkitektur for digitale tvillinger (et såkalt PWI eller Preliminary Work Item fra JTC1 SC41 AG11, dvs. deres Joint Technical Committee 1, Sub-Committee 41, Digital Twin Advisory Group 11). Dette er høyst overordnet, men viser hvordan ISO mener en slik tjeneste bør realiseres, i form av et separat lag som bør være tilgjengelig på tvers av brukerkategorier og tekniske komponenter.

La oss se på noen mer konkrete brukstilfeller:

Innenfor bygg­/­an­legg/­eiendoms­bransjen blir det stadig vanligere å bruke BIM – Building Information Model – som en felles prosess for å først designe byggverk virtuelt, og så realisere de fysisk. Innenfor BIM er det vanligste i dag såkalt nivå 1 eller 2, dvs. at man benytter CAD/DAK (dataassisterte/digitale konstruk­sjonstegninger) i 2D/3D, med eller uten såkalte felles data­om­givelser (på engelsk Common Data Environment eller CDE).

BIM-modeller kan gjerne kombineres med måler-/tilstands­data (hvor endring over tid representerer den fjerde dimensjonen; 4D), men dette forekommer sjeldnere. Mens på BIM nivå 3 søker man komplett integrasjon av ‘alle’ innvirkende forhold. Altså ikke begrenset til tidsaksen (4D), men gjerne også kostnader (5D) og tilstøtende forhold som eiendom/eierskap. Vi vil påstå at det er først hvis man ‘går hele veien’ at man kan oppnå en rimelig komplett kopi av virkeligheten; altså en digital tvilling. Basert på et slikt resonnement kan man si at BIM nivå 3 representerer digital tvilling, i det minste én type digital tvilling. For ordens skyld: BIM innebærer mer enn modeller, og de delte arbeidsprosessene er det klart viktigste (men faller likevel utenfor hva denne artikkelen er ment å dekke).

Over ser vi hvordan Civil Engineer blog forklarer koblingen mellom BIM-nivåer og dimensjoner.

Et vesentlig skille går mellom når digitale tvillinger er geospatiale eller ikke. Bak dette vanske­lige ordet skjuler det seg ikke noe annet enn stedfestet i vårt globale rom. I noen sammenhenger er stedfesting kritisk viktig: Hvis man f.eks. skal bygge en tunnel og begynner utgravingen fra begge sider, da blir betydningen av at begge løpene treffer hver­andre avgjørende for om alt det andre arbeidet blir en suksess eller ikke. Men om det å bruke mobil­telefon eller GPS til å avlese en posisjon er enkelt, kan de underliggende beregningene for å bestemme stedfesting (koordinat) en gitt geo-posisjon være langt mer krevende. Det er heller ikke en selvfølge at ulike typer data har de same forutsetninger for koordinatbestemmelse. For Kartverket sin del var det også et poeng at den digitale tvillingen ikke skulle ses som et frittstående element, men være representert i riktig geografisk kontekst – dvs. at data må være koordinatfestet og sammensatt med andre data, slik at gjengivelsen faktisk stemmer med virkeligheten.  

Den digitale tvillingen som Kartverket ba oss om å teste ut var derfor naturligvis ikke basert på frittstående elementer, men geospatial/stedfestet. I tillegg skulle vi kombinere 2D-kart med 3D (terreng, inkl. høyder/dybder, mao. meter over/under hav­nivå, samt bygg og andre menneskeskapte fysiske installasjoner) og tom. såkalt 4D, hvor tid utgjør den 4. dimensjonen; i form av endringer over tid.

Eksempler på digitale tvillinger 

Den overnevnte australske digitale tvillingen viser hvor langt man har kommet i New South Wales-regionen, i det sør-østlige hjørnet av landet. Denne er tilgjengelig via https://nsw.digitaltwin.terria.io/ (og kjører på samme programvare som vi PoC’et).

I Finland har man valgt en annen tilnærming, der blir utvalgte deler av Helsinki vist med en fotorealistisk gjen­givelse, altså så nær virkeligheten at det blir vanskelig å oppdage at den digitale tvillingen faktisk bare er en forestilt modell. Denne er også tilgjengelig, da via https://virtualhelsinki.fi/ og kjører på kommersiell program­vare fra Bentley. Samme tekniske plattform ligger til grunn for en større modell av Singapore. På mange måter minner sistnevnte mer om den australske tilnærmingen, men her har de valgt å ikke eksponere alt for omver­denen. Et annet eksempel er mer nærliggende – men som vi ikke kjenner så godt til – Virtual Gothenburg. Noe av det vi finner spennende er deres bruk av CityGML, en teknologibase som vi så langt ikke har praktisk erfaring med.  

Hos Norsk institutt for bioøkonomi (NBIO) har man valgt å vise et utvalg nasjonale datasett, basert på en kom­bi­nasjon av 2D-kart og 3D terreng. Denne er tilgjengelig via Kilden. Løsningen kjører på gratis pro­gramvare, henholds­vis CesiumJS samt et egenutviklet prosjekt fra sveitsiske myndigheter. Her skylder vi å nevne at Australia og dermed vår PoC også benyttet Cesium (mer om dette lengre ned).

Data, data og data

Uten innhold (data) blir egentlig enhver IT-løsning verdiløs. Det avgjørende blir mao. hvordan en løsning forholder seg til eller klarer å representere data. Noe som trolig er unikt med digital tvilling er at selv om alle digitalt registrerte data forteller om ‘noe som skjer’ er den vanlige oppfatningen at veldig mye data ikke er relevant utenfor sitt definerte bruksområde. Opplysninger om en konkret bruktbil eller person er liksom ikke så interes­sant med mindre man er opptatt av akkurat disse. Men i forbindelse med geospatiale digitale tvillinger kan plutselig nærmest ALLE data være relevante, bare de har tilknytning til et gitt område. Så hvis overnevnte bruktbil- eller person-eksempel faktisk har ferdes på sted som omfattes av en digital tvilling, ja da vil plutselig også opplysningene om disse være veldig interessante. Når var de der-og-der? Hvor ofte? Hvilken vei kom de? Kom de før eller etter personbil <X> eller person <Y>? Og-så-videre.

Resultatet blir gjerne at selv om digitale tvillinger opprinnelig kan ligne på andre systemer (de oppsto fordi noen har et gitt fokus-/bruksområde) vil digitale tvillinger fort kunne bli trukket inn i nesten alt mulig. Noen av de som har fått oppleve dette er digital tvilling-leverandøren AugmentCity med Bodø som bruker. For selv om begge begynte med hvert deres definerte bruksområde har det siden bare bredd om seg.

Konsekvensen er at infrastrukturen under en digital tvilling bør kunne ‘svelge unna’ mye data uten dermed å ‘gå i metning’. Dersom man designer for stordata IoT (Internet-of-Things) trenger man ikke å bli overrasket, mens i motsatt fall er det sannsynlig at systemet vil kunne ‘revne i sømmen’.

Datasett og -kilder

I tillegg til et antall datasett som fikk utgjøre fundamentet (Norgeskart, havbunn grunnkart og sjøkartraster, SeHavnivå, Høydedata, FKB-Bygning, Matrikkel Adresse, alle disse fra Kartverket og Geonorge), supplerte vi med opplysninger om slikt som ‘Europa forenklet’ og europeiske grunnkart, samt tidsrekker fra SSB, værdata fra Yr, byg­ninger fra Open Street Map (OSM) og EUs INSPIRE, BIM-modeller for utvalgte bygg (som Operaen), samt trafikkdata fra Veivesenet og EnTur.

Uten å berike modellen med slike data blir det ikke mulig å lage en tilstrekkelig gjengivelse av virkeligheten der ute. Men en faktor som kan komplisere løsningsbildet er hvilke konsekvenser bruk av tidsserier kan ha å si på litt lengre sikt. For hvis man velger å implementer slike velger man implisitt også å stole på kilden (fra nå av og fremover i tid), selv når man vet at dataene vil forandre seg.

Dataformater og -transformasjon

Ved å eventuelt hente opplysningene fra ulike kilder kommer de også i diverse formater. De mest utbredte eksemplene er nok WMS (Web Map Service), OGC API, og tjenestegrensesnittet til Cesium Ion.

Det å ta hånd om BIM-modellene på en god måte fremsto som noe av det mest innviklede konverterings­arbeidet. Siden BIM sitt IFCutvekslingsformat ikke støttes direkte i programvaren måtte kildefilene konverteres til noe som lot seg importere. Første runde gikk fra original (IFC) til glTF (GL Transmission Format), løst via gratisverktøyet Blender. Deretter ble skytjenesten Cesium Ion brukt for å konvertere fra glTF til Cesium 3D-tiles.

Ellers var det å transformere frem-og-tilbake mellom ulike geomatiske referanse­sys­t­emer (se avsnitt om «Pro­gram­vare spesialisert for å håndtere geospatial informasjon» litt lengre ned) en utfordring. Da PoC’en ble gjennomført måtte vi gjøre dette selv. I ettertid har imidlertid lansert en API-tjeneste som avlaster brukere for mye av jobben.   

Vi mener at noe av aller viktigste man gjør er å lage et slags ‘fabrikkoppsett’ eller en ‘data pipeline’ hvor alle operasjoner som kan automatiseres settes opp som et selvgående samlebånd. Dermed blir innhenting av opp­daterte data noe som bare skjer i bakgrunnen. Dette er oppgaver som enhver tilbyder av en digital tvilling trenger å ha et bevist forhold til, uavhengig av hvem tilbyder måtte være (offentlig eller privat).

Programvare og kjøremiljø

TerriaJS og CesiumJS

Mye av hensikten med piloten var å finne ut hvor egnet TerriaJS evt. kan være som ‘bunnpanne’ for en even­tuell fremtidig felles-nasjonal digital tvilling. Hvorfor? Mye fordi en betydelig del av Australia (som sagt) allerede har brukt det gjennom omtrent to år, og etter hvert kastet også Japan seg med. Og – dette er sentralt – fordi pro­gramvaren er basert på åpen kildekode. Finner man en løsning som virker bra trenger man ikke å sette av betydelige midler til løpende lisensfornyelser, men heller investere i kunnskap og egenstyrt videreutvikling.

Her kommer en forklaring som man ikke trenger å lese for å få utbytte av resten av artikkelen. TerriaJS baserer seg på CesiumJS, en annen åpen kildekodekomponent som gjør det mulig å benytte kartdata fra kommersielle Cesium Ion (en av verdens mest utbredte plattformer for kartdata; benyttes bl.a. av Unreal Engine for å rendre/­gjengi naturtro landskapsomgivelser, f.eks. i flere av de mest velrennomerte dataspill-titlene på markedet) uten å dermed måtte lisensiere tjenesten. I dette tilfellet satte vi opp et kjøremiljø i den offentlige skyen til Amazon; AWS.

Programvare spesialisert for å håndtere geospatial informasjon

Det å skulle forholde seg til jordens planetære forhold på matematisk korrekt vis er ikke trivielt. Til dette kreves en viss innsikt i geografiske informasjonssystemer (GIS), samt at man har programvare som avhjelper opp­ga­vene. I dette fagområdet finnes det også en rekke hjelpemidler som er åpne og gratis, som eksem­pel­vis den rimelig kjente kartapplikasjonen QGIS. Her kommer vi imidlertid ikke til å fokusere på verktøy som er direkte tilrettelagt for sluttbrukere, men for verktøy som strengt tatt er usynlige for den vanlige bruker, men som gjør at løsninger som en digital tvilling kan fungere – uten geografiske kortslutninger.

Konkret snakker vi om et par kodebibliotek, PROJ og GDAL. Mens PROJ oversetter mellom koordinat­systemer er GDAL en støtte som oversetter mellom en rekke ulike formater (herunder både raster/punktgrafikk og mate­matisk skalérbar vektorgrafikk; sistnevnte strengt tatt vha. OGR). Siden det er en god del konverteringsjobber som stadig utføres laget vi en samling av tidligere omtalte fabrikklignende samlebånd – eller data pipeline – som kunne gjenta disse operasjonene, hurtig og med stadig lik kvalitet. For å ha bra fleksibilitet og spare tid satte vi opp data pipeline’n ved hjelp av Python (hvilket innebærer at man benytter Python-utgaven av de samme biblio­tekene; PyPROJ og GDAL Python API). Utfordringen kunne ha vært løst på flere måter, men siden vi var så heldige å ha system­utviklere som behersker flere språk, brukte vi det som opplevdes som beste for hver enkelt oppgave. Dersom tvillingen skulle blitt produksjonssatt ville vi nok gått over og forbedret oppsettet, men det fungerte bra for en PoC.

 Øvrige plattform-alternativer

Der finnes et antall aktører som tilbyr programvareløsninger for digitale tvillinger. Noen av disse er basert på fri programvare (som førnevnte GeoAdmin MapViewer fra sveitsiske myndigheter), men de fleste er likevel kommersielle (slike som de fra Autodesk, Bentley, Cityzenith, Dassault og Esri …samt andre aktører med navn som begynner på andre bokstaver i alfabetet. :-D)

Åpen eller kommersiell?

Dette er vel verdt en alvorlig vurdering. Kommersiell programvare betyr at man har tilgang på opplæring og support, at man kan henvende seg til leverandøren for å ivareta utvikling av nyttige utvidelser, osv. Men det innebærer også at man ‘gifter’ seg med en leverandør som lever av lisenspenger, og lisensavgiften ligger ofte på ca. 20% årlig av anskaffelsesbeløpet. Hvilket vil si at man kjøper plattformen igjen og igjen, sånn omtrent hvert femte år. Hvis man i tillegg legger til grunn at en stor digital tvilling helst bør være en arena som mange bruker og legger inn deres respektive eiendeler/ansvar, blir resultatet fort at mange må betale mye – gjennom hele prosjektets levetid. Hvis man i tillegg sier at man gjerne har et (eller gjerne flere) tiårs perspektiv begynner kostnadsbildet å bli ganske alvorlig. Og det paradoksale er at lisens faktisk dreier seg om en betalt rettighet til å kunne fortsette å benytte sine egne data – på en leid plattform.

Her gjør vi en antagelse som kanskje kan vise seg å være gal?: Det norske markedet for såkalt fullverdig digital tvilling basert på kommersiell programvare er sannsynligvis begrenset. Spesielt siden det allerede finnes flere aktører som ønsker å tilby en ferdig opererbar tjeneste. Bare i Norge har vi i hvert fall tre aktører som tilbyr digital tvilling som sky­levert tjenesteplattform. Disse er Aize (en del av Aker, dekker primært energi­bransjen), førnevnte AugmentCity (dekker primært kommuner, med Ålesund og Bodø som to gode eksempler) og Kongsberg (også primært for energi­bransjen). Men for de som ønsker seg bedre forståelse har DNV utarbeidet en kjøpeguide.

Oppsummering av funn

I tillegg til de a-ha-opplevelsene som du kanskje kan ha fått ved å lese denne artikkelen er det flere konklu­sjoner som kan trekkes:

• Det å komme i gang med geografiske informasjonssystemer er ikke nødvendigvis «helt rett frem». Investeringer i prøving og læring er uansett ikke bortkastet, og for de som vil beherske det helt nødvendig.
• Det å blande 2D (kart) med høyder/dybder til et landskap med kupert terreng, 3D-objekter (bygninger og andre fysiske installasjoner) og variasjon/bevegelse 4D (tidsserier; for å reflekter endring over tid) krever en gjennomtenkt tilnærming. Fra begynnelsen kan det være lurt å være forberedt på at alt (spesielt høyder) ikke vil stemme uten justering
• Vær også forberedt på at BIM-modeller av reelle objekter så godt som bestandig er knyttet til en eier. Retningslinjer må overholdes.
• Sett dette opp som en tjeneste som kan aksesseres fra hvor-som-helst, av hvem-som-helst. Få ting er mer frustrerende enn å ha suksess – for så å oppdage at nye potensielle brukere ikke får tilgang, bare fordi en datamaskin ikke er på nettverket
• En kort introduksjonsvideo gir en smakebit på hvordan to geografisk uerfarne, men dyktige karer (Kristian Stamland og Håkon Carlsen) overkom den tildelte byggejobben på fire måneder.

Klikker du på bildet får du en kort (2 min.) introduksjon hvor Håkon og Kristian forklarer hvordan de gikk frem.

Veien fremover

Tematikken over arter seg nødvendigvis annerledes for det offentlige Norge enn hva det kan gjøre for smalere målrettede forretningsforetak. Dersom hele eller deler av landets forvaltning drar i gang et felles­prosjekt som ivaretar det platt­form­messige så vil kanskje du og jeg – og våre respektive arbeids­givere – kanskje komme i gang med å legge inn våre fysiske aktiva (assets; bygg, osv.) – og så begynne å simulere eller realisere virksom­hetsmessig samvirke med andre. Så vidt jeg kjenner til foreligger det ikke konkrete planer for slikt. Og i motsatt fall, dersom det ikke blir noen fellesoffentlig plattform med det første, får vi enten smøre oss med tålmodighet eller bygge noe selv.

Knowit har allerede en instans oppe, og vi er åpne for samarbeid. Og hvis du som privat­person ikke kan vente på smakebiter kan du kanskje prøve slikt som å gå via Datalandsbyen, selv opprette noen KML-filer (Keyhole Markup Language, typisk via SketchUp) og plassere de inn i Google Earth, eller kanskje noe helt annet? Vær så snill og fortell oss hvilke idéer du syns man burde forfølge!

Metaverses

Stadig mer av vår teknologiske oppmerksomhet knyttes til det å forstå hvordan virtuelle verdener eller såkalte metaverses eller kvasi-realistiske verdener (som Decentraland, Fortnite Concerts, Horizon Worlds, Sandbox og kanskje til og med Minecraft?) vil kunne prege hverdagene våre fremover. Det finnes spennende skjæringspunkter mellom metaverses og digitale tvillinger. Undertegnede vil påstå at et metaverse kan være en mulig anvendelse av en digital tvilling, men som artikkelen har forsøkt å belyse finnes der langt flere.

Noen ledetråder til mer relevant stoff

• Fritt tilgjengelig mikrokurs i regi av Digital Norway: Digitale tvillinger forklart på fem minutter.
• Digital tvilling av byen: En Kartverket-artikkel om honorering for god nytteverdi av geodata, basert på det som har blitt gjort av Ålesund og AugmentCity.
• Mer om tilfellet over, men her fortalt av Ålesund kommune, og med fokus på SMART PLAN-prosjektet.
• Et eksempel fra Bodø kommun