Modeller som overlever

Transkript

1 Modeller som overlever Hvordan modeller kan forvaltes år etter år I dette notatet ser vi på hvordan modeller kan forvaltes år etter år og fortsatt opprettholde sin verdi og aktualitet. Notatet tar utgangspunkt i hvordan dette er gjennomført i NVDB, Norges nasjonale vegdatabank, som nettopp er en sømløs modell. Videre noen tanker om hvordan dette kan overføres til som-bygget modeller.

2 Modeller som overlever Hvordan modeller kan forvaltes år etter år Bakgrunn På forespørsel fra David Wasström, Tyréns, Sverige, har Vianova Systems utarbeidet dette notatet med tanker om hvordan en modell kan overleve gjennom mange år, og fortsatt være både anvendelig og tilgjengelig. Notatet er overordnet og tar ikke for seg detaljerte tekniske løsninger, men beveger seg på prinsipp-nivå, og prøver å gi et overordnet bilde, med utgangspunkt i erfaringer fra Norge. Dagens situasjon Generelt kan man vel trygt si at bransjen har utfordringer knyttet til å forvalte data for bygde anlegg på en effektiv måte. Mye informasjon går tapt, de dataene som ikke går tapt er ofte vanskelig tilgjengelig for ettertiden. Det normale er at man forvalter en stor mengde enkeltfiler; med andre ord er dataene fragmenterte og som sagt relativt sett utilgjengelige for de som kommer etter. Filene er det viktigste resultatet fra det vi nå kan kalle tradisjonell prosjektering og bygging. Så kommer BIM Arbeidsmetodikken i bransjen vil sakte men sikkert endres til at man samler informasjonen fra alle filene til en (1) samordnet modell. Denne samordningsmodellen vil etter hvert bli like viktig som tegningene (ritningarna). Man må nå forvalte en mengde filer som før men i tillegg også den nye samordningsmodellen. Modellen representerer på en bedre måte det man innenfor NVDB Dagens NVDB ble satt i drift i NVDB er basert på en datamodell som er modellert i hht ISO TC211, med et viktig tillegg; Vegnettet. NVDB som en nasjons vegdatabank, er selvsagt innrettet mot å leve i mange år. Novapoint Novapoint er et prosjekteringssystem som fra og med versjon 19 er basert på modellplattformen ISO TC 211. Vianova Systems Vianova Systems eier og utvikler Novapoint. I tillegg har man vært og er fortsatt en sentral underleverandør til utviklingen av NVDB. Fejl! Brug fanen Startside til at anvende Heading 1 på teksten, der skal vises her. 1 Vianova

3 tradisjonell prosjektering har kalt for modell-filene; presentasjonen av selve løsningen. Nå er alle data i 3D. I tillegg finnes det og vil fortsette å finnes - en rekke andre filer med informasjon som pr nå ikke legges inn i samordningsmodellen. Her kan ting endres over tid. Bransjens forskjellige aktører har i varierende grad tatt innover seg denne omstillingen, og mye synes uklart med hensyn til hvordan ting skal løses «i fremtiden». For at bransjen skal ha noe å omstille seg til, så må noen gå i front og finne veier gjennom jungelen av buzz-words og mer eller mindre begrunnede påstander. Dersom vi skal samle informasjonen fra en rekke filer til én modell, og senere utnytte dette til lettere å finne igjen informasjon (søke, zoome), til lettere å kunne anvende informasjonen (bestille oppgraderingsarbeid, analysere «hva som gikk galt», etc), så faller det ut en sett av spørsmål: Spørsmålene 1. Hvilke type av modell skal man samle informasjonen til? 2. Hvordan skal man lagre modellen? 3. Hvordan skal man oppgradere modellen dersom behov? 4. Hvem skal modellen være tilgjengelig for? 5. På hvilken måte skal den være tilgjengelig? Spørsmålene diskuteres i det videre: Type modell Overordnet kan man tenke seg at det er 2 hovedløsninger å velge mellom: A. Fil-basert forvaltning av modelldata B. Modell-basert forvaltning av modelldata Både A og B involverer en eller annen form for database. I alternativ A benyttes databasen til å holde orden på original-filene, og ved hjelp av metadata pr fil kan man søke etter «den rette filen». I praksis kan dette være et web-hotell, og her finnes det jo svært mange løsninger å velge mellom. Noen av løsningene har mulighet for å søke etter informasjon på tvers av innholdet i filene. Men informasjonen er og blir filer. Og dette skalerer ikke veldig bra dersom man ønsker å slå ett prosjekts datasett sammen med et annet prosjekts datasett. Fejl! Brug fanen Startside til at anvende Heading 1 på teksten, der skal vises her. 2 Vianova

4 I alternativ B benyttes databasen til å lagre en sømløs modell; det betyr at modellen er sammenhengende og uten «fil-grenser». Original-filene blir dermed sekundære i forhold til modellen, selv om filene også kan lagres sammen med modellen, på en eller annen måte (kanskje). I en slik løsning kan data kan hentes ut fra modellen helt uavhengig av hvordan de ble skapt. Det er også lettere å se for seg at data fra ett prosjekt kan «blandes» sammen med data fra et annet prosjekt. INSPIRE EU pålegger nå alle medlemsland å levere forskjellige datasett for sitt land som skal kunne inngå i en samlet fremstilling av f.eks. transportnettet, marktyp (land cover), m.v. fra hver land. INSPIRE er basert på ISO TC 211 og benytter GML som utvekslingsformat. Vi tror at INSPIRE vil være en driver til å forbedre dataflyten i hvert enkelt land i Europa. Novapoint og NVDB I både Novapoint og (norsk) NVDB har man basert seg på ISO TC 211 standarden for modellering av informasjonen. Det betyr at man er innenfor GML-verden, der bl.a. CityGML er et kjent «produkt». Selv om Novapoint og NVDB benytter samme rammeverk for basismodellen, og til og med deler felles program-komponenter for å håndtere denne modellen, så er ikke Novapoint og NVDB 100% like. Her noen viktige forskjeller: 1. NVDB har en annen objekttypekatalog enn Novapoint 2. NVDB benytter kun geometritypene punkt, linje (linestring) og (2D) polygon. 3. Novapoint benytter også linjekonstruksjonsgeometri, 3D polygon (triangulerte eller rutenett), solids ~ objekter med volum-geometri. 4. NVDB har en (1) sentral tjener (server) der alle data lagres (som går på SUN-maskiner) 5. Novapoint tilbyr «prosjekt»-servere eller firma-servere, alt etter hva kunden ønsker, og kan installeres på Windows PC-maskiner Ref. punktet 1 over så ser vi at GML-standarden er fleksibel; at det kan defineres flere produkter for forskjellige formål, alle dekket innenfor GML-standarden. Fejl! Brug fanen Startside til at anvende Heading 1 på teksten, der skal vises her. 3 Vianova

5 Lagring av modellen Uansett om man bestemmer seg for ett eller flere åpne formater man vil utveksle informasjonen i, så er det jo ikke særlig gunstig å forvalte dataene som et sett av filer på en filtjener - eller i et web-hotell. Man ønsker en modell-basert lagring som understøtter sømløse søk og gjenfinning, samt geografisk visning på en enkel måte, uavhengig av fil-grenser. Og man bør kreve at løsningen støtter både import og eksport av en eller flere åpne formater. Innen bygg og IFC-verden finnes det flere såkalte BIM-servere som kan benyttes for å samle informasjonen fra alle IFC-filene til en database. Det finnes både open source baserte alternativer samt kommersielle løsninger. NVDB har en (1) sentral (Oracle) server (som kjører på en SUN-maskin) der hele det nasjonale vegnettet, med alle relevante vegobjekter, er lagret. Rundt 170 millioner objekter fordelt på omlag 450 objekttyper. De fleste av disse objektene er også lokalisert inn på vegnettet med sine ca. 1,8 millioner veglenker. Vianova Systems ønsker å være en aktør på markedet for lagring av modeller som er basert på «GML». Tilgjengelighet Forvaltningsdata krever sikker og fleksibel tilgangskontroll. Vi kjenner slik funksjonalitet f.eks. fra web-hoteller. Vi går ikke nærmere inn på dette her annet enn at ett av poengene må være muligheten for geografisk gjenfinning av dataene, ikke som mapper og filnavn. Fejl! Brug fanen Startside til at anvende Heading 1 på teksten, der skal vises her. 4 Vianova

6 Hvordan hente ut informasjon Man bør kunne søke i alle disse dataene på en rekke måter: Geografisk søk ved hjelp av polygon (eksempelvis kommunegrense) Søke etter objekttyper Søke etter objekttyper med bestemte verdier på sine egenskaper Søke etter objekter langs vegnettet Søke etter historiske objekter ved at objekter har en start og en sluttdato for når de er «i live» I NVDB er mange av de søkene som er mest brukt lagret som «oppgaver» som kan kjøres når som helst. Da ligger utvalget/søket definert i oppgaven, både med hensyn til geografisk område og objekttype, og dataene kan sendes fra server til klient. Man har også muligheter for å generere rapporter/filer på server som så sendes klienten som etterspør den. Det finnes også oppgaver som kjøres hver natt, ala «Send data fra server til ESRI-database». I Novapoint-sammenheng har Vianova Systems tilpasset NVDB-løsningen til våre brukeres verden, som stort sett består av konsulenter, entreprenører og byggherrer. Det betyr at vi kan sette opp en server/modell som så kan driftes enten av kunden selv, eller av Vianova System. I praksis vil det siste bety at vi kjøper denne tjenesten av en 24/7 leverandør som kan garantere for både backup-systemer og andre driftskritiske parametere. Oppgradering av modellen Hvordan skal modellen leve gjennom år etter år, og fortsatt være tilgjengelig og anvendelig? Her kommer vi til kjernen: NVDB har nå vært driftet siden 2005, og har gjennom hele denne tiden vært gjenstand for små og store endringer. NVDB er jo en levende sømløs modell av det norske vegnettet, som er i stadig endring. Objekttypekatalogen Objekttypedefinisjoner har blitt oppdatert jevnlig. Når objekttypekatalogen oppgraderes med nye objekttype-definisjoner, så oppgraderes serveren i en egen prosess. Alle klienter vil automatisk oppgraderes neste gang de kobler seg på serveren. Objektene Objektene på instansnivå endres selvsagt også. Man har her versjonering på hvert objekt, der hver versjon har sin gyldige start- og sluttdato. Evt. åpen sluttdato dersom objektet fortsatt er aktivt. Fejl! Brug fanen Startside til at anvende Heading 1 på teksten, der skal vises her. 5 Vianova

7 Når objekttypekatalogen oppgraderes så vil instansene følge med på dette, og man kan bl.a. legge til nye egenskapstyper på allerede eksisterende objekter. Strukturelle endringer av objektdefinisjoner vil kreve spesielle konverteringsprosesser. Utvidelser av katalogen med nye objekttyper og egenskaper er normalt trivielt. Nettverket Veglenker har også gyldig start- og sluttdato. Når veglenker settes historisk så betyr det at de får sluttdatoen satt, og vil fra og med det tidspunktet kun kunne hentes ut dersom man søker etter vegsystemet på en historisk dato, f.eks. «hent ut vegnett i Oslo kommune for ». NVDB skal for øvrig gjennom en større oppgradering av sitt vegnett i 2013/2014. Dette for å harmonisere vegnettet til INSPIRE-direktivet, som jo legger føringer for hva hvert enkelt land må levere til EU-fellesskapet. Prosjektmodeller Ovenfor har vi henvist mye til hvordan ting fungerer i NVDB, som jo for Norge pr i dag ikke kommer til å ta i mot den komplette prosjekterte og bygde anleggsmodellen; Politikken nå er at man vil gjøre et ekstrakt fra prosjektert/bygd modell og legge dette inn i NVDB. Statens vegvesen, Utbyggingsavdelingen i Vegdirektoratet, ser derfor for seg en løsning der de supplerer den sentrale NVDB-serveren med «prosjektservere» (prosjektmodeller). Disse vil ideelt sett være komplette med hensyn til alle modelldata som ble produsert av konsulent og entreprenør. Ingen tap av informasjon. Siden modellen har samme grunnstruktur som NVDB, så kan Statens vegvesen nå selv hente ut det som skal inn i NVDB. Prosjektmodellene kan også forvaltes videre som detaljerte beskrivelser av anlegget. Hit er vi kommet i Norge i dag. Her står vi, og vet jo ikke helt hvordan dette vil utvikle seg videre. Ønsker man å sy sammen alle prosjektmodeller til en «3D NVDB» for hele Norge? NVDB er en sammenhengende modell som dekker hele landet. Vil «3D NVDB» også inkludere resultatet fra alle utbyggingsprosjekter for hele landet? Dette har vi ikke svar på i dag. En slik løsning må i så fall beslutte hvilke koordinatreferansesystem som skal benyttes. I NVDB lagres alle data til EUREF89 UTM 32. Vi vet at prosjektmodellene vil gjennomføres på ett av de 25 NTMsonene, som har bedre nøyaktighet enn UTM-sonene. Dette betyr at de må koordinat-transformeres dersom de skal samles i en forvaltningsmodell. Fejl! Brug fanen Startside til at anvende Heading 1 på teksten, der skal vises her. 6 Vianova

8 Et hovedkrav fra byggherren bør være at datautvekslingsformat er åpent, det vil si uavhengig av en enkelt-leverandører. Innen anlegg og infrastruktur benyttes i dag LandXML som et ganske avansert stikningsformat for overføring mellom prosjektering og anlegg hovedsakelig, og til dels for utveksling mellom CAD-verktøy. Men LandXML er ikke egnet for de store oppgavene. LandXML har ingen generell objektmodell i bunnen; kodingen av informasjonen er begrenset. Så har vi GML-formatet. Etter det vi vet har man i Norden i liten grad tatt i bruk GML; Vi tror derimot at dette vil endre seg og vi tror at GML er det mest lovende åpne formatet for vår bransje. IFC-formatet skal heller ikke avskrives på noen måte innenfor anlegg og infrastruktur. IFC er laget for å håndtere bygninger i utgangspunktet. Allerede i 2002 var man i gang med å definere bro (!) som en del av IFC; litt spesielt siden man ikke hadde objekter for hverken veger eller jernbaner. Det har man fortsatt ikke. Men man har utviklet bro-modellen noe og man har lagt til en tunnel-modell. Allikevel, etter vår erfaring er dette lite brukt i praksis. Men; det foreligger planer for å utvide IFC med flere objekter innen «utomhus/mark», selv om i alle fall BuildingSMART Norge anerkjenner ISO TC 211 og GML som et alternativ man bør og må forholde seg til; det viktigste er tross alt at det finnes åpne formater som er dekkende. Quadri - historien I det videre har vi tatt med litt historikk knyttet til utviklingen av Quadri-modellen. Vi håper denne historien illustrerer hvor omfattende det er å lage et system for å forvalte modell-data på dette nivået. Det illustrerer også forhåpentligvis noe av de elementene som må være med i løsninger som skal forvalte modell-data over tid. Vianova Systems har jobbet i 25 med det som visjon å samle dataene for 1. Kart 2. Terrengmodell 3. Prosjektering 4. Infrastrukturinformasjon i en og samme modell. Dette har vært et langt løp, og på vegen for å oppnå denne visjonen har Quadri vært utviklet i 4 generasjoner: Fejl! Brug fanen Startside til at anvende Heading 1 på teksten, der skal vises her. 7 Vianova

9 Quadri generasjon 1 (1985-) Ideen med Quadri ble unnfanget av Eivind Stalheim «hjemme på kjøkkenbenken». Eivind Stalheim jobber fortsatt i Vianova Systems, og har vært helt sentral i utviklingen av alle generasjonene av Quadri. Her noen stikkord som karakteriserer den første generasjonen G1: Visjonen: Samle data fra 4 domener (nevnt ovenfor), derav navnet «Quadri», som betyr: Stedet der fire veger møtes Mål: Implementerte en modell basert på den norske SOSI-standarden Vianova Systems benytter Quadri G1 som felles terrengmodell i Novapoint (til og med 18.x) Firmaet Norkart implementerte et kartsystem (i dag heter dette GIS/Line) med utgangspunkt i Quadri G1 Geometri-orientert, dvs. at geometri-«objektet» er i sentrum, og dette objektet kan ha egenskaper Geometrityper støttet: 2/3D Punkt, 2D/3D Linje, 2D arealer Temakodebank: En konfigurasjonsfil som tilknyttes modellen og definerer hvilke temakoder denne modellen har, der temakode er å betrakte som en egenskap til geometrien. Egenskapsstøtte er «hardkodet». Det er med andre ord mulig å håndtere egenskaper, men implementasjonen skalerte ikke når det ble behov for mer og mer egenskaper. Quadri generasjon 2 (2002- ) Ble utviklet gjennom NGIS-prosjektet for Statens kartverk (Norges svar på Lantmäteriet), som en løsning for lagring av nasjonens samlede kartdata. Her noen stikkord som karakteriserer G2: Løsningen er i dag installert hos Statens kartverk og 50 av de store kommunene i Norge Benyttes i Norkart sin løsning Quadri Map Server Introduserte prinsippet om en objektkatalog - som er en tidlig versjon av ISO TC 211-standarden o Men prinsippene for hvordan modellen er bygd opp er fortsatt geometriorientert ikke ulikt hvordan IFC er implementert o Til forskjell fra IFC har Quadri G2 en enkel geometri-modell Introduserte prinsippet om en oppgave-modell som styrer tilgang til dataene Kan etablere mange (separate) modeller Det er etablert over permanente forvaltningsmodeller på denne plattformen i Norge Windows-basert installasjon Fejl! Brug fanen Startside til at anvende Heading 1 på teksten, der skal vises her. 8 Vianova

10 Quadri generasjon 3 (2005- ) Utviklet som basis for NVDB for Statens vegvesen, som en løsning for lagring av nasjonens samlede vegnettsinformasjon. Her noen stikkord som karakteriserer G3: Tok utgangspunkt i G3 Videreutviklet prinsippet om en objektkatalog i hht ISO TC 211 Objektorientert informasjonsmodell - det vil si ikke geometriorientert o Objektene er fenomen som fysiske objekter, hendelser eller liknende. o Objektene er selvstendige enheter for all tid o Geometrien er en egenskap på lik linje med andre egenskaper o Er derfor forskjellig fra G3 (G2, G1) på dette vesentlige punktet o Kan derfor håndtere all type informasjon - også den som ikke har geometri Som grunnlag ligger IT-standarden UML o UML forteller hvordan objekter skal beskrives o ISO TC 211 tar utgangspunkt i UML Er en forvaltningsmodell - som Quadri G3 og har relativt enkel geometri Introduserte en avansert nettverksbasert stedfestingsmodell (node-lenker) Modellen har også omfattende støtte for historikk, både på objektene og nettverket I NVDB er de fysiske applikasjons-serverne SUN og databasemaskinene LINUX Klientene benytter Windows Quadri generasjon 4 (2012- ) Ble utviklet parallelt med G3, med det som formål å utvide konseptet til også å håndtere detaljert prosjekteringsinformasjon, slik at prosjekteringssystemet Novapoint kunne benytte G4 som modellbasis. Her noen stikkord som karakteriserer G4: Quadri G4 er laget for å skalere, både modell og lagring Quadri er laget for å kunne håndtere både en prosjekteringsorientert modell samt en forvaltningsmodell Novapoint 19 DCM bygger hele sitt nye modell-fundament på Quadri G4 Modellen er en objektorientert informasjonsmodell, som G3 Basert på standard UML for modellering av modellen, som G3 Modellen tar utgangspunkt i ISO TC 211, som G3 G4 har i tillegg en omfattende geometri-modell: o Inkluderer geometritypene 3D Surface (TIN eller GRID), Multi-Surface, Multi-Points (point clouds), Solids, Konstruerte linjer, mv. Løsningen bygger på G3 - men tar samtidig med seg G2 sine muligheter for å håndtere mange modeller i en eller flere «skyer» Modellene kan ha kort eller lang levetid For å være en god langtids forvaltningsmodell krever det at modellen er en objektorientert informasjonsmodell o En oppgraderbar datakatalog er nødvendig det støtter både G3 og G4 Laget for å kunne kjøres på flere operativsystem og plattformer Fejl! Brug fanen Startside til at anvende Heading 1 på teksten, der skal vises her. 9 Vianova

11 Løsningen kan også kjøres kryss-plattform (det vil si f.eks. Windows-Unix). Man kan kjøre mange Quadri-modeller på èn fysisk servermaskin Løsningen er tilstandsløs slik at den kan kjøres i et lastbalanseringsmiljø dette er en Quadri Model som kjøres på mange fysiske servermaskiner Med Quadri G4 mener vi å ha et meget godt grunnlag på plass mht. å håndtere kartdata, terrengdata, prosjekterte data samt infrastrukturinformasjon i en og samme sømløse geografiske modell, for svært store datamengder, og svært mange brukere (användare). Med dette som erfaringsgrunnlag deltar vi gjerne i diskusjoner som har med forvaltning av modeller over tid. Vi deler gjerne av våre erfaringer, samtidig som vi håper å lære enda mer om hva kundene ønsker seg innenfor dette spennende området. Vennlig hilsen Idar Kirkhorn Leif Tronstads Plass 4 Postboks 434 N-1302 Sandvika Telefon Direkte Mobil idar.kirkhorn@vianova.no Fejl! Brug fanen Startside til at anvende Heading 1 på teksten, der skal vises her. 10 Vianova