Vi har implementert en ny datamodell Datamodellen i dRofus er laget for å kunne kommunisere med BIM underveis i prosjektene, og både kunne høste fra modellene når dat data oppstår, men også fritt kunne berike modellene ved behov i prosjektene. Dette innebærer at vi har introdusert noen nye entiteter og omdefinert de eksisterende (komponent og system). Dette er gjort på en slik måte at vi skal dekke de behov man har prøvd å adressere ved «menneskelig logikk» i løpenummer på system og komponent, men uten at man skal få vesentlige endringer ved numereringnummerering.

Ny datamodell består av følgende entiteter:

(Tekniske) Systemer og «systemkomponenter»

Innenfor tekniske fag defineres et system/anlegg i TFM gjerne ut fra hva som funksjonelt henger sammen. For eksempel er alle komponenter knyttet til et ventilasjonsaggregat et system, alle komponenter knyttet til en kjølemaskin er et system osv. Således kan man derfor si at systemer defineres av en komponent innenfor de tekniske fag.

I vårt arbeid med BIM'ifisering av anleggs ID'er har vi sett behov for å definere- og «særbehandle» slike systemdefinerende komponenter. Vi har kalt dem «systemkomponenter», og det er da komponenter som får systemnummer slik også TFM systemene i dag genereres, samt at alle komponenter som er knyttet til disse systemkomponentene arver dette systemnummeret. Komponenter knyttes til systemkomponentene gjennom systemer. Dvs at en systemkomponent kan ha flere systemer.

Dette er også gjort for å matche datastrukturene i BIM. Det ville være umulig å synkronisere data til og fra systemer mellom databasen og BIM uten at man matchet på entitetsnivå. Dvs en mange til en kobling ville begrenset til enveis kommunikasjon (skrive fra en til mange).
I BIM vil typisk et ventilasjonsaggregat ventilasjons-aggregat ha 4 systemer;

• Tilluft
• Fraluft
• Inntak
• Avkast

De har ulike verdier man gjerne ønsker å se/hente, og det vil også i en driftssituasjon være ønskelig å vite om en komponent var tilknyttet tilluft eller avtrekk. Man ser derfor mange eksempler på at løpenummer på komponent benyttes for å identifisere denne systemtilhørigheten (igjen i mangel på bedre alternativer), så også ved OSL. 

I vår BIM'ifisering av TFM har vi nå altså definert at System (gammel struktur) = systemkomponent (ny struktur). Så system +AA=360.001 = Systemkomponent +AA=360.001. Dette har ingen konsekvens for nummerering, men er viktig for å matche struktur i BIM. Forskjellen består i at:

• System (gammel) = system som kan ha komponenter
• Systemkomponent = komponent som kan knyttes til andre komponenter gjennom systemer

Forskjellene på TFM nummer mellom disse ser vi altså først i «neste ledd» der man har systemer som knytter øvrige komponenter til systemkomponenten, mens komponenter ligger direkte under systemer i dagens struktur.
Anchor_Toc445810173_Toc445810173anchor_Toc447488380_Toc447488380

Systemer

Systemer er nå kun en logiske kobling mellom komponenter uten egen geometri. Et system har kun geometri fra komponentene i systemet. Dette er slik det er definert i BIM, og det er også slik vi har valgt å løse det i vår datamodell for å kunne matche datastrukturene, samt at det gir andre positive effekter. Vi ser mange varianter der man prøver å utrykke systeminformasjon i det spillerommet man har i løpenummer på komponent. Systemene må ikke ha en systemkomponent, så systemene kan fortsatt være en ren gruppering av komponenter.

De «BIM'ifisterte» systemene er som nevnt en kobling mellom komponenter og deres «systemkomponent». Systemets løpenummer kan typisk være kursnummer for elektro, eller at man definerer en gitt nummerstruktur for systemene tilknyttet et aggregat: Tilluft = 1, Fraluft = 2 osv.Vi har foreslått å skille systemenes løpenummer fra løpenummer på systemkomponentene med et kolon slik at den fulle koden for en tilluftsventil (ST007TST001T) vil kunne se ut som dette:

+AA=360.001:101-ST007TST001T/001

Der systemets løpenummer er «1» «01» og systemets fulle nummer er +AA=360.001:101. Systemkomponenten ventilasjonsaggregat har nummer +AA=360.001 og er knyttet til tilluftsventiltypen SF001T gjennom systemet +AA=360.001:1
Image Removed
Figur 4: Systemvisning av tilluftsventil i system «1-Tilluft» tilknyttet aggregat +AA=360.001
Anchor_Toc445810174_Toc445810174 Anchor_Toc447488381_Toc44748838101

Image Added


Artikler/Typer

I BIM består alle objekter av et type objekt og et instansobjekt (200 like stikkontakter har ett felles typeobjekt, men 200 instans objekter). Typeobjektene benyttes også aktivt for å holde og distribuere data i prosjektering, men man får ikke utnyttet typeobjektet i klassifiseringsøyemed med dagens bruk av TFM. I BIM er et typeobjekt definert som et objekt som holder felles data for flere instanser.

Et typeobjekt kan for eksempel holde data om geometri, ytelse og typeklassifikasjon. Et instansobjekt holder typisk unike data om akkurat denne instansen/forekomsten av en type. Dette kan være luftmengde på en ventil, unikt løpenummer (for eksempel dørnummer) eller tilsvarende.

Typekonseptet er ganske kraftig verktøy ved at man kan vedlikeholde data for mange objekter ett sted, og referere dette til alle instanser i et prosjekt og/eller på en eiendom. En typeklassifikasjon vil kunne gi en direkte og unik referanse til det prosjekterte objektet inkludert den prosjekterte ytelsen. I tillegg vil ofte den prosjekterte typen være samsvarende med et gitt produkt. For eksempel ville de 200 stikkontaktene over kunne være et utenpåliggende dobbelt stikk med jord i hvit utførelse. De kan da dokumenteres ett sted – på typen. Alternativet slik det er i dag er at man må finne forekomster av den prosjekterte stikkontakten «gjemt» bak mange ulike koder.

Vi har derfor i BIM'ifisering lagt oss på en linje der komponenttype koden skal bety noe mer enn det gjør i dagens TFM. Nemlig at den gjenspeiler enten en planlagt- eller prosjektert type. Dette innebærer at man ved dette systemet ville satt for eksempel komponenttypekode ST007T ST001T på en gitt type tilluftsventil, og man ville da ut fra kode visst at ST007T ST001T (uavhengig av system) alltid ville vært den samme prosjekterte typen. Slik er det ikke i dag. For å indikere at dette er koden til et typeobjekt (planlagt/prosjektert type) foreslår vi at dagens typeunikt i system, erstattes med «prosjektert type».
Image Removed Figur 5

: Fra TIDA, "JP041T" i et gitt prosjekt kan i TIDA benyttes til ulike objekter. I «nye» dRofus vil JP041T alltid være den samme prosjekterte typen
Typekonseptet vi har lagt oss på har med BIM også fått et solid fotfeste i prosjektene, og vi ser også at komponenttypekoden benyttes slik vi her foreslår i mange prosesser i prosjektene, bla som typeidentifikasjon på arbeidstegninger.
anchor_Toc445810175_Toc445810175 Anchor_Toc447488382_Toc447488382

Komponenter/ forekomster

Komponenter er forekomster av typer. Dvs at når en type tilluftsventil tegnes/modelleres ut i et ventilasjonssystem får vi en forekomst av denne typen tilluftsventil. Når vi nå har «reservert» komponenttypekoden til å uttrykke planlagt- eller prosjektert type vil man ha behov for å kunne sette et unikt nummer på forekomsten (for enkelte komponenttyper). I stor grad vil dette handle om komponenter som krever unik adresse i styringssystemer (SD/BAS osv.). Vårt løsningsforslag er at man skiller komponentens (unike) løpenummer fra komponenttypenummer med «/». Den fulle strengen til en forekomst av tilluftsventil ST007T i «1-tilluftsystem», tilknyttet ventilasjonsaggregat 360.001 vil da se ut som følger:

+AA=360.001:101-ST007TST001T/001