Klik her for at hente i pdf. - BygningsInformatiker.dk
Klik her for at hente i pdf. - BygningsInformatiker.dk
Klik her for at hente i pdf. - BygningsInformatiker.dk
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
20. december<br />
2011<br />
2<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Forord<br />
Dette semesterprojekt – ”Hvordan skaber man en optimal udvekslingsproces i et modelbaseret<br />
miljø”, er udarbejdet på Aalborg Universitet i perioden 2. september 2011 til den 20. december<br />
2011, svarende til 15 ECTS point.<br />
Baggrunden <strong>for</strong> semesterprojektet tilblivelse, kommer af en undren over byggebranchens manglende<br />
vilje/evne til <strong>at</strong> omstille sig til de nye teknologier. Det gælder både de nye tekniske muligheder,<br />
men også de nye processer.<br />
Semesterprojektet er skrevet på dansk. De engelske betegnelser er i så bredt et omfang, som<br />
muligt, blevet beholdt <strong>for</strong> <strong>at</strong> undgå <strong>at</strong> skabe <strong>for</strong>virring omkring de tekniske begreber.<br />
Det har været et meget lærerigt projekt, og vi vil gerne takke Associ<strong>at</strong>e Prof. Kjeld Svidt <strong>for</strong> sit<br />
store engagement, vejledning og in<strong>for</strong>m<strong>at</strong>ive diskussioner. Udover kyndig vejledning fra Associ<strong>at</strong>e<br />
Prof. Kjeld Svidt, har vi også fået inspir<strong>at</strong>ion og hjælp fra Tekn. Dr. Per Christiansson Ing. Byrå<br />
HB (tidligere Associ<strong>at</strong>e Professor <strong>for</strong> Lund Universitet og Aalborg Universitet) .<br />
Derudover vil vi gerne takke Niras A/S, Rambøll A/S og Friis & Moltke <strong>for</strong> <strong>at</strong> stille et projekt samt<br />
vidensdeling til rådighed <strong>for</strong>, <strong>at</strong> vi har kunnet undersøge udvekslingsprocesserne i et modelbaseret<br />
miljø omkring Musikkens Hus. Samt University College, programmerings studerende Ronni<br />
Hansen, <strong>for</strong> bistand under udvikling af vores løsnings<strong>for</strong>slag.<br />
Rapporten henvender sig til folk inden <strong>for</strong> byggebranchen, med en byggeteknisk viden og som har<br />
interesse i <strong>at</strong> optimere byggeprocessen, ved hjælp af digitalisering i byggeriet.<br />
Rapporten er udarbejdet af gruppe 2, bestående af Lasse Bønnerup, Jacob Wassard Andersen,<br />
Thomas Dragsbæk, Ole Breiner Siig og Peter Gade.<br />
Lasse Bønnerup<br />
Thomas Dragsbæk<br />
Ole Breiner Siig<br />
Peter Gade<br />
Jacob Wassard Andersen
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
Resume<br />
Dette semesterprojekt er udarbejdet i <strong>for</strong>bindelse med 2. semester på Aalborg Universitets uddannelse<br />
i Bygningsin<strong>for</strong>m<strong>at</strong>ik, kaldet Cand. Scient. Techn. i byggeri og anlæg med speciale i bygningsin<strong>for</strong>m<strong>at</strong>ik.<br />
Semesterprojektet har til <strong>for</strong>mål <strong>at</strong> gøre læseren opmærksom på de problemstillinger der er i<br />
byggeriet omkring en mere effektiv udveksling af in<strong>for</strong>m<strong>at</strong>ioner.<br />
Grundlaget <strong>for</strong> <strong>at</strong> arbejde med emnet – ”Hvordan man skaber en optimal udvekslingsproces i et<br />
modelbaseret miljø” - har været organis<strong>at</strong>ionen BuildingSMARTs arbejde med åbne standarder.<br />
Deres standarder som Industry Found<strong>at</strong>ion Classes (IFC), In<strong>for</strong>m<strong>at</strong>ion Delivery Manual (IDM) og<br />
Intern<strong>at</strong>ional Framework <strong>for</strong> Dictonaries (IFD), har vi <strong>for</strong>søgt <strong>at</strong> gøre mere håndgribelig, ved <strong>at</strong><br />
beskrive værktøjerne i en sammenhæng med resten af byggeprocessen og de danske <strong>for</strong>hold.<br />
For <strong>at</strong> få en mere realistisk reference, har vi fået udleveret casen, Musikkens Hus i Aalborg. Vi har<br />
taget udgangspunkt i Musikkens Hus, når vi har draget rel<strong>at</strong>ioner til virkeligheden.<br />
Vi har opdelt semesterprojektet i tre generelle hovedafsnit. Første afsnit omhandler Musikkens<br />
Hus, og de involverede parter. Anden del omhandler teori bag en effektiv udveksling af in<strong>for</strong>m<strong>at</strong>ioner<br />
i et modelbaseret miljø. Tredje afsnit omhandler det praktiske aspekt, hvilket omhandler<br />
udvekslings<strong>for</strong>søg og et løsnings<strong>for</strong>slag. Løsnings<strong>for</strong>slaget indeholder en konceptuel model over<br />
hvordan nogle af de koncepter organis<strong>at</strong>ionen BuildingSMART har frems<strong>at</strong> i et nutidigt miljø.<br />
Afslutningsvis <strong>for</strong>mulerer vi en konklusion og perspektivering, hvor vi prøver <strong>at</strong> svare på vores<br />
problem<strong>for</strong>mulering.<br />
3
20. december<br />
2011<br />
4<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Abstract<br />
This semester report has been made in connection with the second semester <strong>at</strong> Aalborg Universitys<br />
educ<strong>at</strong>ion in Building In<strong>for</strong>m<strong>at</strong>ics, called Civil Engineering with specializ<strong>at</strong>ion in Building in<strong>for</strong>m<strong>at</strong>ics.<br />
The reports aim, was to draw the readers <strong>at</strong>tention to the inefficiency of exchange of in<strong>for</strong>m<strong>at</strong>ion,<br />
in a building process.<br />
Our basis <strong>for</strong> work on the topic, “To cre<strong>at</strong>e an optimal exchange process in a model-based environment”<br />
- has been the work of the organiz<strong>at</strong>ion BuildingSMARTs open standards. Standards<br />
such as Industry Found<strong>at</strong>ion Classes (IFC), In<strong>for</strong>m<strong>at</strong>ion Delivery Manual (IDM) and Intern<strong>at</strong>ional<br />
Framework <strong>for</strong> Dictonaries (IFD). We have tried to make the somewh<strong>at</strong> complex standards more<br />
palpable, by describing the tools in a context with rest of the building processes and the Danish<br />
conditions.<br />
To get a more realistic reference, we have been given the case, House of Music in Aalborg. We<br />
have taken House of Music as a point of reference, when we have been referenced to the real<br />
world.<br />
We have divided the report into three general main sections. Initially, we focus about the House<br />
of Music, and the involved parties. The second part is about the theory behind an effective exchange<br />
of in<strong>for</strong>m<strong>at</strong>ion in a model-based environment. The third section deals with the practical<br />
aspect, which focuses about exchange experiments and solution proposals. The solution proposal<br />
includes a conceptual model of how some of the concepts presented by the organiz<strong>at</strong>ion BuildingSMART<br />
in a contemporary environment.<br />
Finally, we write a perspective and a conclusion w<strong>her</strong>e we try to answer our problem <strong>for</strong>mul<strong>at</strong>ion<br />
and perspective.
Titelblad<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Titel Udveksling af in<strong>for</strong>m<strong>at</strong>ioner i et modelbaseret miljø<br />
Forsidebillede Billeder er taget fra http://www.coop-himmelblau.<strong>at</strong>/<br />
Uddannelsesinstitution Aalborg Universitet<br />
Uddannelse Cand. Scient. Techn. i Byggeri og Anlæg, Bygningsin<strong>for</strong>m<strong>at</strong>ik<br />
Opgave 2. Semester opgave, E2011<br />
Forf<strong>at</strong>tere Jacob Wassard Andersen<br />
Ole Breiner Siig<br />
Peter Gade<br />
Thomas Dragsbæk<br />
Lasse Bønnerup<br />
Vejledere Associ<strong>at</strong>e Prof. Kjeld Svidt<br />
Institut <strong>for</strong> Byggeri og Anlæg,<br />
Sektionen <strong>for</strong> Architectural Engineering<br />
Bygningsin<strong>for</strong>m<strong>at</strong>ik<br />
Oplæg Digital publicering<br />
Udgivelsesd<strong>at</strong>o 20. December 2011<br />
Sprog Dansk<br />
Anslag 143.289 Total<br />
Sidetal 95 Sider<br />
20. december<br />
2011<br />
5
20. december<br />
2011<br />
6<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
1 Indledning .................................................................................................................................... 8<br />
1.1 Baggrund ............................................................................................................................... 8<br />
1.2 Problem<strong>for</strong>mulering ........................................................................................................... 10<br />
1.3 Metode ............................................................................................................................... 10<br />
1.4 Afgrænsning ........................................................................................................................ 11<br />
1.4.1 Implicerede parter ....................................................................................................... 11<br />
1.4.2 Teoretiske <strong>for</strong>hold ........................................................................................................ 11<br />
1.4.3 Praktiske <strong>for</strong>hold .......................................................................................................... 11<br />
2 Case ”Musikkens Hus” i Aalborg ................................................................................................ 12<br />
2.1 Musikkens Hus .................................................................................................................... 12<br />
2.2 Historien bag Musikkens hus .............................................................................................. 12<br />
2.3 Coop Himmelb(l)au og Friis & Moltke................................................................................. 14<br />
2.4 Niras .................................................................................................................................... 15<br />
2.5 Rambøll. .............................................................................................................................. 15<br />
2.6 Fonden Musikkens Hus ....................................................................................................... 15<br />
3 Teoretiske <strong>for</strong>udsætninger ....................................................................................................... 16<br />
3.1 Analyse og kortlægning ...................................................................................................... 16<br />
3.1.1 BPMN - Business Process Model and Not<strong>at</strong>ion ........................................................... 16<br />
3.1.2 IDEF (ICAM Definition) metoder .................................................................................. 21<br />
3.1.3 IDEF1x ............................................................................................................................ 24<br />
3.1.4 Unified Modeling Language (UML) .............................................................................. 25<br />
3.1.5 Entity-Rel<strong>at</strong>ionship model (E-R) ................................................................................... 27<br />
3.2 BuildingSMART.................................................................................................................... 31<br />
3.2.2 Industry Found<strong>at</strong>ion Classes (IFC) ................................................................................ 33<br />
3.2.3 In<strong>for</strong>m<strong>at</strong>ion Delivery ManuaI (IDM) ............................................................................ 40<br />
3.2.4 Model View Definition (MVD) ...................................................................................... 53<br />
3.2.5 Intern<strong>at</strong>ional Framework <strong>for</strong> Dictionaries (IFD) ........................................................... 58<br />
3.3 Klassifik<strong>at</strong>ion og udveksling ................................................................................................ 63<br />
4 Praktiske <strong>for</strong>hold ........................................................................................................................ 65<br />
4.1 Hvordan <strong>for</strong>egår in<strong>for</strong>m<strong>at</strong>ionsudveksling i dag? ................................................................ 65<br />
4.2 Møde med parterne ........................................................................................................... 65<br />
4.2.1 In<strong>for</strong>m<strong>at</strong>ionsudveksling. .............................................................................................. 65
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
4.2.2 Cad-manual .................................................................................................................. 65<br />
4.2.3 BuildingSMART ............................................................................................................. 65<br />
4.2.4 Sammenf<strong>at</strong>ning ............................................................................................................ 66<br />
5 Eksport eksperimentet............................................................................................................... 67<br />
6 Hvordan bliver vi bedre ............................................................................................................. 72<br />
6.1 Problemstilling .................................................................................................................... 72<br />
6.2 Analyse ................................................................................................................................ 72<br />
6.2.1 Koncept ........................................................................................................................ 72<br />
6.2.2 Opbygning .................................................................................................................... 73<br />
6.2.3 D<strong>at</strong>abasen .................................................................................................................... 76<br />
6.2.4 Navig<strong>at</strong>ionsdiagrammet .............................................................................................. 77<br />
6.2.5 Grafisk brugerflade (GUI) ............................................................................................. 78<br />
6.2.6 Dialogboksen: Bruger ................................................................................................... 79<br />
6.2.7 Dialogboksen: In<strong>for</strong>m<strong>at</strong>ionskravsoversigt ................................................................... 80<br />
6.3 Sammenf<strong>at</strong>ning................................................................................................................... 80<br />
7 Konklusion .................................................................................................................................. 81<br />
8 Perspektivering .......................................................................................................................... 82<br />
Kortsigtet (1-5 år) ......................................................................................................................... 82<br />
Langsigtet (5+ år) .......................................................................................................................... 82<br />
9 Kildeliste ..................................................................................................................................... 83<br />
9.1 Billedhenvisninger .............................................................................................................. 86<br />
10 Ord<strong>for</strong>klaring ............................................................................................................................ 89<br />
Bilag 1: Kontrol beregninger. ....................................................................................................... 91<br />
7
20. december<br />
2011<br />
1 Indledning<br />
8<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
1.1 Baggrund<br />
Building In<strong>for</strong>m<strong>at</strong>ion Modeling (BIM) betegner bla. den proces som omf<strong>at</strong>ter generering og administr<strong>at</strong>ion<br />
af digitale bygningsd<strong>at</strong>a. Salgsargumentet <strong>for</strong> anvendelse af BIM, er bl.a. muligheden<br />
<strong>for</strong> <strong>at</strong> samle alle d<strong>at</strong>a i en og samme bygningsmodel samt muligheden <strong>for</strong> <strong>at</strong> udføre simuleringer.<br />
Parterne i et projektteam undgår desuden <strong>at</strong> genere redundante d<strong>at</strong>a og får samtidig et struktureret<br />
og omf<strong>at</strong>tende beslutningsgrundlag fra de resterende parter, såfremt in<strong>for</strong>m<strong>at</strong>ionsudvekslingen<br />
er udførlig og <strong>for</strong>egår rettidigt. BIM kan, hvis det bliver implementeret og styret rigtigt,<br />
resultere i en mere integreret design- og konstruktionsproces.<br />
Succeskriteriet <strong>for</strong> en effektiv arbejdsgang blandt mange samarbejdende aktører, er kommunik<strong>at</strong>ion<br />
og et altid opd<strong>at</strong>eret beslutningsgrundlag. Udvekslingsprocessen er ofte mere kompliceret<br />
end man først antager. Det handler om <strong>at</strong> etablere konsensus omkring <strong>for</strong>løbet og kræver disciplin<br />
fra alle parter. Som bekendt er ingen kæde stærkere end det svageste led. Dette gælder også<br />
<strong>for</strong> anvendelsen af BIM i et dynamisk projektteam, hvor alle parter er afhængige af hinandens<br />
kompetencer og samarbejdsvillighed.<br />
Oplysningen omkring BIM <strong>for</strong>egår i vid udstrækning på et teoretisk niveau og mangler ofte <strong>at</strong> blive<br />
kædet sammen med ”den gode historie”. Mange virksomheder bryster sig med store lovende ord<br />
og imponerende salgsm<strong>at</strong>eriale, men konkrete eksempler i fuld skala glimter ved sit fravær.<br />
Dog ser udviklingen ikke ud til <strong>at</strong> stoppe <strong>her</strong> – specielt ikke på globalt plan, hvor lande som f.eks.<br />
Norge befinder sig på et helt andet og højere niveau. Flere og flere virksomheder indser nødvendigheden<br />
<strong>for</strong> et gener<strong>at</strong>ionsskifte i IT værktøjerne og opf<strong>at</strong>ter i stigende grad BIM som et konkurrenceparameter<br />
på det fremtidige marked.<br />
Vi har i vores <strong>for</strong>arbejde identificeret udvekslingsprocessen mellem parter som en flaskehals vi vil<br />
fokusere på. I nærværende rapport inddrages praktisk erfaring fra projektteamet omkring ”Musikkens<br />
Hus” i Nordjylland samt observ<strong>at</strong>ioner <strong>for</strong>etaget af rapportens <strong>for</strong>f<strong>at</strong>tere. Også <strong>her</strong> er<br />
ambitionerne <strong>for</strong> anvendelse af BIM høje, og fremstilles på bl.a. Niras’ hjemmeside således;<br />
”På Kunstens Hus i Herning og Musikkens Hus i Nordjylland har vi gjort os mange<br />
erfaringer med brugen af buildingSMART’s værktøjer og anvendelsen af BIM i projekterne.”<br />
(Niras, 2011)<br />
Niras er install<strong>at</strong>ionsingeniør på projektet og Cowi er byg<strong>her</strong>rerådgiver:<br />
”COWI bruger bygningsin<strong>for</strong>m<strong>at</strong>ionsmodellering i relevante byggeprojekter, <strong>for</strong>di<br />
det giver en mere koordineret byggeproces.” (Cowi, 2011)<br />
På sidste semester lærte vi <strong>at</strong> der kan være langt imellem intention og handling når det gælder<br />
BIM i byggebranchen. Ovenstående udsagn vil være genstand <strong>for</strong> vores undersøgelse af såvel de<br />
reelle <strong>for</strong>hold på byggesagen samt parternes egen opf<strong>at</strong>telse. Vi vil, som før nævnt, fokusere på
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
aspektet omkring udveksling og håndtering af d<strong>at</strong>a mellem faggrupper. Hertil inddrages værktøjer<br />
og metoder til <strong>at</strong> effektivisere og kvalitetssikre processen.<br />
Nedenstående cit<strong>at</strong> fra Ingeniøren underbygger vores påstand omkring udvekslingsprocessen;<br />
”It-systemer, der ikke kan tale sammen, er årsag til fejl, <strong>for</strong>sinkelser og dobbeltarbejde<br />
<strong>for</strong> milliarder i byggebranchen hvert år.<br />
Masser af byggein<strong>for</strong>m<strong>at</strong>ioner går nemlig tabt, når digitale 3D-tegninger sendes<br />
rundt mellem parterne, og det betyder f.eks., <strong>at</strong> de rådgivende ingeniørers it-system<br />
ikke kan <strong>for</strong>stå arkitekternes tegninger og der<strong>for</strong> må tegne <strong>for</strong>fra.” (Ingeniøren,<br />
2008)<br />
9
20. december<br />
2011<br />
10<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
1.2 Problem<strong>for</strong>mulering<br />
Projektet har til <strong>for</strong>mål <strong>at</strong> undersøge, om der findes metoder til <strong>at</strong> effektivisere og simplificere<br />
udvekslingen af in<strong>for</strong>m<strong>at</strong>ioner mellem parter i et byggeprojekt.<br />
Undersøgelser viser <strong>at</strong> der ligger et stort potentiale i brugen af BIM i byggebranchen, såfremt<br />
metoderne bliver implementeret i alle dele af byggeriet, og de tekniske værktøjer optimeres til <strong>at</strong><br />
håndtere BIM-modeller – men hvilke værktøjer er der tale om og hvordan anvendes disse?<br />
Vores hovedspørgsmål lyder der<strong>for</strong> således;<br />
Hvordan skaber man en optimal udvekslingsproces i et modelbaseret miljø?<br />
1.3 Metode<br />
Til <strong>at</strong> undersøge og besvare problemstillingen i problem<strong>for</strong>muleringen, vil vi gøre brug af følgende<br />
metoder:<br />
Litter<strong>at</strong>ursøgning<br />
Vi vil gennem litter<strong>at</strong>ursøgning finde relevante in<strong>for</strong>m<strong>at</strong>ioner, som beskriver BIM og BuildingSMARTs<br />
værktøjer i byggeriet, samt hvilke erfaringer der er gjort. Vi vil anvende litter<strong>at</strong>ur<br />
i <strong>for</strong>m af videnskabelige artikler, bøger samt udgivelser fra interesseorganis<strong>at</strong>ioner og virksomheder<br />
med seriøs erfaring inden<strong>for</strong> emnet. Derudover vil vi finde inspir<strong>at</strong>ion i tidligere<br />
specialer og afhandlinger.<br />
Interviews<br />
Vi ønsker <strong>at</strong> kombinere den faglitterære tilgang med interviews fra nøglepersoner i såvel<br />
branchen som helhed samt interessenter fra nærværende case, Musikkens Hus.<br />
Praktisk afprøvning af BIM-modellering<br />
”Hands-on approach”, eller praktisk erfaring.<br />
Til <strong>at</strong> afprøve hvordan IFC <strong>for</strong>m<strong>at</strong>et kan bruges til <strong>at</strong> udveksle modeller i dag, er der <strong>for</strong>etaget<br />
praktiske afprøvninger med udveksling af BIM-modeller mellem modellerings værktøjer.
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
1.4 Afgrænsning<br />
Denne rapport har til <strong>for</strong>mål <strong>at</strong> give læseren et indblik i BuildingSMARTs standarder og værktøjer<br />
som søger den optimale udveksling af in<strong>for</strong>m<strong>at</strong>ioner i byggebranchen.<br />
For <strong>at</strong> kunne gøre dette, har det været nødvendigt <strong>at</strong> afgrænse til flg. 3 hovedområder:<br />
1. Musikkens Hus, og de Implicerede parter.<br />
2. Teoretiske <strong>for</strong>udsætninger.<br />
3. Praktiske <strong>for</strong>hold.<br />
1.4.1 Implicerede parter<br />
Grundet omfanget af implicerende parter i projektet, Musikkens Hus, har vi valgt et udsnit af aktørerne<br />
på byggesagen. Rapporten vil overordnet beskrive udvalgte aktører som Fonden Musikkens<br />
Hus, Coop Himmelb(l)au, Friis og Moltke, Niras og Rambøll.<br />
1.4.2 Teoretiske <strong>for</strong>hold<br />
Analyseværktøjer<br />
Til grov-analysen er der beskrevet og valgt UML, E-R, og IDEF0. Desuden vil BPMN blive belyst og<br />
anvendt flere steder i rapporten.<br />
BuildingSMART<br />
Rapporten vil på overordnet vis beskrive organis<strong>at</strong>ionen og efterfølgende give en grundig gennemgang<br />
af udvalgte standarder og værktøjer som understøtter udvekslingsprocessen, <strong>her</strong>under:<br />
IFC<br />
Generel beskrivelse samt opbygning. Efterfølgende vil der blive opsummeret med en st<strong>at</strong>us<br />
iht. byggesagen samt den gernerelle anvendelse.<br />
IDM<br />
Generel beskrivelse samt opbygning. Herunder beskrivelse af Process Maps, Exchange Requirements<br />
og Functional Parts. Afsnittet vil blive opsummeret med en st<strong>at</strong>us iht. byggesagen<br />
samt den gernerelle anvendelse.<br />
- MVD<br />
Generel beskrivelse samt opbygning. Efterfølgende vil der blive opsummeret med en st<strong>at</strong>us<br />
iht. byggesagen samt den gernerelle anvendelse.<br />
IFD<br />
Generel beskrivelse samt opbygning. Efterfølgende vil der blive opsummeret med en st<strong>at</strong>us<br />
iht. byggesagen samt den gernerelle anvendelse.<br />
1.4.3 Praktiske <strong>for</strong>hold<br />
Semesterrapporten tager udgangspunkt i BuildingSMART, og der<strong>for</strong> er udvekslings<strong>for</strong>m<strong>at</strong>et IFC<br />
valgt.<br />
Det praktiske <strong>for</strong>søg er afgrænset til 4 udvalgte projekteringsværktøjer, hvorpå der er lavet eksport/import<br />
–<strong>for</strong>søg.<br />
11
20. december<br />
2011<br />
12<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
2 Case ”Musikkens Hus” i Aalborg<br />
Følgende afsnit beskriver Musikkens Hus, samt udvalgte parter i projektet. I den teoretiske gennemgang<br />
vil der drages paralleller til den konkrete byggesag. Dette suppleres med interviews<br />
blandt parterne.<br />
2.1 Musikkens Hus<br />
Når Musikkens Hus står færdigt i Aalborg<br />
er det beliggende lige ud til Limfjorden<br />
som en del af et dynamisk byrum, der<br />
<strong>for</strong>binder byens centrum med Limfjorden.<br />
Byggeriet har et bruttoareal på 20.257 m 2<br />
og et udnyttet nettoareal på 17.637 m 2 .<br />
Musikkens Hus har 5 etager over terræn<br />
og 3 etager under som er inddelt i <strong>for</strong>skellige<br />
bygningsafsnit, centreret omkring<br />
koncertsalen med plads til ca. 1300 personer.<br />
Der er 3 mindre sale placeret i<br />
Billede 1 - Viser rendering af Musikkens Hus. Kilde: Coop Himmelb(l)au.<br />
kælderniveau: Intimsalen (300 personer), Klassisk Sal (150 personer) og Rytmisk Sal (150 personer).<br />
Formålet med Musikkens Hus er <strong>at</strong> kombinere den offentlige oplevelsesscene, med store<br />
koncertoplevelser, med den kunstneriske udvikling og med uddannelse på flere faglige niveauer.<br />
Såsom unikke uddannelses- og øvemiljøer <strong>for</strong> Aalborg Symfoniorkester, det Jyske Musikkonserv<strong>at</strong>orium<br />
og Aalborg Universitet, Institut <strong>for</strong> Musik. (Det Digitale Byggeri)<br />
2.2 Historien bag Musikkens hus<br />
Lokale kræfter stiftede i 1986 <strong>for</strong>eningen ”Musikhusets Venner” med det <strong>for</strong>mål <strong>at</strong> etablere et<br />
hus i Aalborg der kunne dække det lokale musiklivs behov <strong>for</strong> udfoldelse, samt danne rammerne<br />
om større gæsteoptrædener. I år 2000 blev der fra politisk side, besluttet <strong>at</strong> projektet omkring<br />
Musikkens Hus kunne opføres på havnefronten i Aalborg. Musikhusets Venner fik indsamlet 50<br />
mio. kr. som var kravet fra Aalborg kommune og det daværende Nordjyllands Amt. RealDania,<br />
dengang Realdanmark Fonden, gik ind i projektet med 60 mio. kr.<br />
I 2002 blev arkitektkonkurrencen udskrevet og i 2003 vandt Østrigske Coop Himmelb(l)au projektet<br />
hvorefter projekteringen hurtigt påbegyndte.<br />
I begyndelsen af 2006 blev Musikkens Hus udbudt i licit<strong>at</strong>ion, men det viste sig <strong>at</strong> projektet ikke<br />
kunne opføres inden<strong>for</strong> den økonomiske ramme. De daværende byg<strong>her</strong>rer, Fonden Musikkens<br />
Hus i Nordjylland og St<strong>at</strong>ens Forsknings- og Uddannelsesbygninger, valgte <strong>at</strong> skrinlægge projektet.<br />
I slutningen af 2006 indgik Aalborg kommune nye <strong>for</strong>handlinger med partnere i projektet og på<br />
den baggrund meddelte RealDania, <strong>at</strong> de ville indgå med yderligere økonomisk støtte samt en<br />
stærkere organis<strong>at</strong>ion. I 2007 blev udpeget der en ny bestyrelse <strong>for</strong> Fonden Musikkens Hus i<br />
Nordjylland og der blev samtidigt etableret en driftsgruppe til <strong>at</strong> <strong>for</strong>berede den fremtidige drift.
Backstage<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Educ<strong>at</strong>ional-U<br />
Figur 1 - Viser snit i Musikkens Hus<br />
Educ<strong>at</strong>ional-U<br />
Trompet<br />
Cone<br />
20. december<br />
2011<br />
Sådan opføres huset<br />
Musikkens Hus opføres med bærende<br />
konstruktioner i præfabrikerede betonelementer<br />
(søjler, bjælker dæk,<br />
tagdæk og vægge). Omkring koncertsalen<br />
er vægge udført dels i bærende<br />
insitu beton og dels i præfabrikerede<br />
betonelementer. Den ydre klimaskærm<br />
på Koncertsalen udføres med bærende<br />
konstruktioner i beton, tag med stålgitterdragere<br />
og betondæk med udvendig<br />
tagisolering og membran. Den ydre<br />
facadebeklædning er udført i præfabrikerede<br />
betonelementer. Facader i Billede 2 - Viser Rambølls Teklamodel.<br />
backstage-området er udført som alufacader med termoglas / sikkerhedsglas. Facader i uddannelsesdelen<br />
(Educ<strong>at</strong>ional-U) er betonsandwichelementer med amøbe relieffer og runde vinduer.<br />
Facader på Trompet og Conen er metalfacader med alu-glasfacader indbygget. På sydfacaden af<br />
Educ<strong>at</strong>ional-U er der opbygget en solcelle facade. Ovennævnte områder kan ses på Figur 1.<br />
Byggeriet kompletteres med skillevægge, gulve, trapper, elev<strong>at</strong>orer, fast inventar, køkkener og<br />
malerarbejde. Der udføres VVS-arbejder, <strong>her</strong>under ventil<strong>at</strong>ion, køling og vandinstall<strong>at</strong>ioner. Der<br />
udføres stærk- /svagstrømsarbejder, CTS og adgangskontrol. Arbejder i terræn omf<strong>at</strong>ter terrænreguleringer<br />
og afsluttende belægning. ( FRIIS & MOLTKE, 2011) / (musikkenshus, 2011)<br />
13
20. december<br />
2011<br />
14<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
2.3 Coop Himmelb(l)au og Friis & Moltke<br />
Hovedarkitekten på Musikkens Hus er østrigske Coop Himmelb(l)au som vandt den intern<strong>at</strong>ionale<br />
arkitektkonkurrence. Efterfølgende er Friis og Moltke blevet involveret i opgaven som Coop Himmelb(l)aus<br />
lokale samarbejdspartner. Coop Himmelb(l)au har haft den samlede projekteringsledelse<br />
og ansvaret <strong>for</strong> de arkitektoniske udtryk på byggeriet, ligesom de indtil nu har produceret<br />
størstedelen af tegningsm<strong>at</strong>erialet. Friis og Moltke varetager bl.a. de daglige lokale kontakter,<br />
udarbejder budgetter og bidrager til projekteringen med dele af tegningsm<strong>at</strong>erialet og især beskrivelserne.<br />
Samarbejdet fungerer i praksis som om der var tale om to afdelinger af samme virksomhed.<br />
Coop Himmelb(l)au<br />
Coop Himmelb(l)au blev grundlagt i Wien af tre arkitekter, østrigske Wolf D. Prix og Michael Holzer<br />
samt polske Helmut Swiczinsky i 1968. Arkitekterne har siden da fokuseret på arkitektur, byplanlægning,<br />
design og kunst og vundet utallige intern<strong>at</strong>ionale priser <strong>for</strong> sit arbejde.<br />
Blandt større projekter der er tegnet af Coop Himmelb(l)au er:<br />
Musée des Confluences (Kundskabens Museum) i Lyon, Frankrig.<br />
Busan Cinema Center i Sy<strong>dk</strong>orea.<br />
den Europæiske Centralbank i Frankfurt am Main.<br />
Dalian Intern<strong>at</strong>ionale Konferencecenter i Kina.<br />
boligbyggeriet ”Liesing Brewery” i Wien.<br />
Firmaet har hove<strong>dk</strong>ontor i Wien og beskæftiger 126 medarbejdere, <strong>her</strong>af 89 arkitekter og 20 tekniske<br />
designere.<br />
Friis & Moltke<br />
Friis & Moltke er en dansk arkitekt virksomhed, som blev grundlagt af henholdsvis Knud Friis og<br />
Elmar Moltke tilbage i 1954. De startede i Århus, men er i dag også placeret i Aalborg og Køge.<br />
Tegnestuen bliver ledet af 5 partnere, hhv. Palle Hurwitz, Niels Erik Thomsen, Martin Wienberg,<br />
Mikkel Wienberg og Mogens Husted Kristensen, sammen med associeret partner Mikkel Bahr. Der<br />
er i dag ans<strong>at</strong> omkring 60 medarbejdere, hvor størstedelen arbejder i Århus.<br />
Virksomheden arbejder inden<strong>for</strong> alle aspekterne af arkitekturvirksomhed, lige fra enfamilieshuse,<br />
støttet boligbyggeri til store eksklusive boligbyggerier med mere. Tegnestuen arbejder med BIMapplik<strong>at</strong>ioner<br />
på flere projekter, hovedsagligt med Autodesk Revit. ( FRIIS & MOLTKE, 2011)
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
2.4 Niras<br />
Niras blev grundlagt i 1956 af civilingeniørerne Jørgen Kristian Nielsen og Konrad Rauschenberger,<br />
og er i dag en af landets førende virksomheder inden<strong>for</strong> ingeniørrådgivning. Derudover har Niras<br />
s<strong>at</strong>set intern<strong>at</strong>ionalt og har i dag kontorer i mere end 35 lande. På verdensplan har Niras over<br />
1200 ans<strong>at</strong>te.<br />
NIRAS har arbejdet med BIM gennem mange år, hvor de har gjort sig en del erfaringer med brugen<br />
af BuildingSMART´s værktøjer og anvendelse af BIM.<br />
”På Kunstens Hus i Herning og Musikkens Hus i Nordjylland har vi gjort os mange<br />
erfaringer med brugen af buildingSMART’s værktøjer og anvendelsen af BIM i projekterne.”<br />
(Niras, 2011)<br />
Hos Niras ser de sig selv, som en potentielle samarbejdspartner til avancerede BIM projekter.<br />
Niras leverer ydelser inden<strong>for</strong>: analyse & str<strong>at</strong>egi, byggeri, energi, <strong>for</strong>syning, industri, in<strong>for</strong>m<strong>at</strong>ik,<br />
infrastruktur, miljø, planlægning og udviklingsbistand. (www.niras.<strong>dk</strong>)<br />
2.5 Rambøll.<br />
Rambøll blev grundlagt i 1945, af de to unge ingeniører Børge Johannes Rambøll og Johan Georg<br />
Hannemann, efter en periode som medarbejdere på Anker Engelunds tegnestue.<br />
Rambøll Danmark er en del af Rambøll Gruppen. Rambøll Gruppen beskæftiger pt. omkring<br />
10.000 mennesker på verdensplan. Rambøll gruppen har ca. 200 kontorer, og er repræsenteret i<br />
23 lande. Fortrinsvis i Nordeuropa, Indien, Rusland og Mellemøsten.<br />
Rambøll levere ydelser inden<strong>for</strong>; Byggeri & design, infrastruktur & Transport, energi & klima, industri<br />
& olie/gas, it & telekommunik<strong>at</strong>ion, management & samfund og miljø & n<strong>at</strong>ur.<br />
(http://www.ramboll.<strong>dk</strong>/services)<br />
Rambøll er konstruktionsingeniør på ”Musikkens Hus”, hvilket har givet dem store ud<strong>for</strong>dringer,<br />
grundet den ud<strong>for</strong>drende arkitektur. Der<strong>for</strong> har Rambøll udarbejdet en bygningsmodel. Modellen<br />
er modelleret i Tekla, hvorefter stålleverandøren har arbejdet videre på den.<br />
2.6 Fonden Musikkens Hus<br />
Byggeriet Musikkens Hus styres af Fonden Musikkens Hus i Nordjylland. Fonden er stiftet af Det<br />
Obelske Familiefond og Spar Nord Fonden, som en erhvervsdrivende fond, med ansvaret <strong>for</strong> opførelsen<br />
af det fysiske byggeri samt ansættelse af en byggeledelse. Bestyrelsen tæller, under byggeriets<br />
opførelse, repræsentanter fra henholdsvis Aalborg kommune, RealDania, Spar Nord Fonden<br />
og Det Obelske Familiefond, som støtter <strong>for</strong>skning, uddannelse og kultur i Nordjylland. Når byggeriet<br />
står færdigt, og senest 6 mdr. efter overtagelse af det færdige byggeri, opløses bestyrelsen og<br />
genopstår i en ny <strong>for</strong>m, som <strong>her</strong>efter tager udgangspunkt i driften af byggeriet Musikkens Hus,<br />
som kulturinstitution. Her vil fondens <strong>for</strong>mål desuden bestå i <strong>at</strong> fremme den musikkulturelle aktivitet<br />
i Nordjylland. (musikkenshus, 2011)<br />
15
20. december<br />
2011<br />
16<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
3 Teoretiske <strong>for</strong>udsætninger<br />
Det teoretiske grundlag <strong>for</strong> en vellykket udvekslingsproces bygger på standardiserede løsninger<br />
med intern<strong>at</strong>ionalt udbredelse. BuildingSMART er i dag branchens de-facto standard og tilbyder<br />
løsninger til planlægning og d<strong>at</strong>audveksling. Dette afsnit omhandler BuildingSMARTs værktøjer og<br />
standarder, hvilke gennemgås med en teoretisk tilgang. Alle eksempler er baseret på ønskescenariet.<br />
Udover BuildingSMART, vil afsnittet omhandle analyse og procesmetodologier der kan hjælpe til<br />
med <strong>at</strong> skabe det optimale grundlag <strong>for</strong> en optimal arbejdsproces, samt nogle af de procesfilosofier,<br />
som ligger til grund <strong>for</strong> BuildingSMART.<br />
Efter hvert hovedafsnit, sammenholder vi emnet med situ<strong>at</strong>ionen i dag/case Musikkens Hus, og<br />
giver et bud på potentialet <strong>for</strong> fremtiden.<br />
3.1 Analyse og kortlægning<br />
Den optimale d<strong>at</strong>audvekslingsproces afhænger i høj grad af planlægning. Hvem skal have hvad,<br />
hvornår og i hvilken <strong>for</strong>m? Klarer aftaler om <strong>for</strong>ventninger skal være afstemt inden påbegyndelse<br />
af et projekt, ellers opstår der hurtigt <strong>for</strong>sinkelser i hele værdikæden. Det er vigtigt med koordinering<br />
og afstemning af <strong>for</strong>ventninger, således alle parter har en klar prioriteringsliste <strong>for</strong> de arbejdsopgaver<br />
som skal færdiggøres, <strong>for</strong> <strong>at</strong> sikre den optimale udvekslingsproces.<br />
Til organisering af processer kan anvendes metoder som f.eks. IDEF0, BPMN, UML og ER, hvilket er<br />
beskrevet i det følgende afsnit. Metoderne besidder grundlæggende de samme egenskaber, men<br />
valget af metode bør alligevel overvejes i henhold til opgavens udstrækning og det ønskede result<strong>at</strong>.<br />
Ved hver metode er beskrevet de primære <strong>for</strong>dele <strong>for</strong> hver enkelt og dets rel<strong>at</strong>ion til BIM og<br />
processtyring.<br />
3.1.1 BPMN - Business Process Model and Not<strong>at</strong>ion<br />
BPMN er en not<strong>at</strong>ions<strong>for</strong>m, som bruges til <strong>at</strong> illustrere <strong>for</strong>retningsprocesser. Kommunik<strong>at</strong>ions<strong>for</strong>men<br />
baseres på et grafisk layout og er opstillet som et diagram. BPMN er en intern<strong>at</strong>ional de<br />
facto standard, til <strong>at</strong> modellere og dokumentere processer i. Metoden er der<strong>for</strong> altid den samme,<br />
uanset hvilket værktøj man anvender, hvilket underbygges af, <strong>at</strong> 72 softwarevirksomheder i dag<br />
har optaget BPMN i deres programpakker. Formålet med en intern<strong>at</strong>ional standard, er <strong>at</strong> <strong>for</strong>retningsprocesser<br />
kan illustreres og læses på en fælles pl<strong>at</strong><strong>for</strong>m - i et fælles sprog. Dermed kan <strong>for</strong>skellige<br />
virksomheder og organis<strong>at</strong>ioner hurtigt udvikle en proces <strong>for</strong> et samarbejde, på et sprog<br />
som alle parter kender og <strong>for</strong>står. Offentliggjorte arbejdsprocesser kan desuden genbruges og<br />
modificeres til brug i andre sammenhænge.<br />
Der findes mange metoder til <strong>at</strong> opstille procesmodeller. Udviklingen startede <strong>for</strong> omkring 40 år<br />
siden og omf<strong>at</strong>ter, udover BPMN, standarder som IDEF, Petri og UML. UML som i dag er den mest<br />
udbredte. BPMN adskiller sig fra de øvrige ved <strong>at</strong> være procesorienteret, hvor de andre er objektorienteret.<br />
BPMN egner sig der<strong>for</strong> specielt til udvikling af IT-systemer til <strong>for</strong>retningsprocesser.<br />
(www.version2.<strong>dk</strong>, 2011)<br />
Motiv<strong>at</strong>ionen bag BPMN opstod i første omgang, da man ville udvikle et værktøj til dokument<strong>at</strong>ion<br />
af <strong>for</strong>retningsprocesser. Institutionen The Business Process Management Institut (BPMI), som i<br />
dag er en del af Object Management Group (OMG), udviklede først BPML – et metasprog ligesom<br />
XML er. I udviklings<strong>for</strong>løbet blev man klar over <strong>at</strong> det ligeledes var nødvendigt med en grafisk
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
repræsent<strong>at</strong>ion processerne – deraf BPMN. Gruppen Not<strong>at</strong>ion Working Group, bestående af repræsentanter<br />
fra 35 <strong>for</strong>skellige virksomheder, organis<strong>at</strong>ioner og enkeltpersoner blev dannet i<br />
2001, <strong>for</strong> <strong>at</strong> varetage denne opgave i fællesskab. I 2004 kom så den første officielle udgivelse –<br />
BPMN 1.0, og denne er netop fulgt op af udgivelsen BPMN 2.0 i 2010. Da BPMI fusionerede med<br />
OMG i 2005, blev BPML sproget erst<strong>at</strong>tet af BPEL, som ligeledes er et procesudførelsessprog, men<br />
baseret på metasproget XML i stedet. Formålet med BPMN er et not<strong>at</strong>ionsværktøj som kan anvendes<br />
af <strong>for</strong>retningsfolk såvel som programmører. BPEL er en <strong>for</strong>kortelse <strong>for</strong> Web Services Business<br />
Process Execution Language, og omtales også WS-BPEL. (www.bpmn.org, 2011) /<br />
(www.en.wikipedia.org, 2011)<br />
Med BPMN kan den samme proces illustreres på mange <strong>for</strong>skellige måder, alt efter behov. Skal<br />
processen kun illustreres grafisk, er det en <strong>for</strong>del <strong>at</strong> anvende et enkelt og intuitivt layout som<br />
giver en hurtig <strong>for</strong>ståelse. Skal processen derimod anvendes til <strong>at</strong> understøtte et it-system, bør<br />
modelleringen tage udgangspunkt <strong>her</strong>i. Illustr<strong>at</strong>ionen vil i denne sammenhæng ofte få et mere<br />
komplekst layout, idet alle led i processer skal dokumenters, så BPMN’en ligger så tæt op af processerne<br />
i det færdige it-system som muligt. I Diagram 1 og 2 neden<strong>for</strong>, vises en BPMN designet<br />
til henholdsvis visuel illustr<strong>at</strong>ion og en til baggrund <strong>for</strong> et IT-system. Den rent visuelle tager kun<br />
f<strong>at</strong> i de overordnede hovedpunkter <strong>for</strong> <strong>at</strong> lette implementeringen hos mennesker, hvorimod pro-<br />
Diagram 2 - Viser BPMN til ren illustr<strong>at</strong>ion<br />
Diagram 1 - Viser BPMN til IT-system.<br />
17
20. december<br />
2011<br />
18<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
cessen til et IT-system skal være mere detaljeret, idet computere ikke selv kan udfylde ”missing<br />
links”, som den menneskelige hjerne kan det.<br />
3.1.1.1 Objekter og symboler i BPMN<br />
BPMN består af en række symboler der har <strong>for</strong>skellige betydninger og <strong>for</strong>skellige regler <strong>for</strong> hvordan<br />
de kan og må anvendes i en sammenhæng med andre symboler. Det er ikke alle symboler<br />
som kan kombineres, hvilket modelleringsværktøjerne ofte gør opmærksom på. Processer illustreres<br />
desuden altid fra start til slut.<br />
Grundlæggende grupperes der efter 4 <strong>for</strong>skellige objektk<strong>at</strong>egorier i BPMN standarden, henholdsvis<br />
Events, Activities, G<strong>at</strong>eways og Connections. Til <strong>at</strong> organisere layoutet anvendes desuden<br />
Pools og Lanes. I det følgende beskrives de mest anvendte modelleringsobjekter.<br />
Events / Begivenheder<br />
Events eller begivenheder vises altid med en cirkel og et symbol i midten.<br />
En event viser noget som skal til <strong>at</strong> ske eller er i gang med <strong>at</strong> ske (mods<strong>at</strong><br />
en aktivitet, som allerede er sket). Symbolet i midten viser funktionen. Et<br />
brev kan <strong>for</strong> eksempel illustrere en besked, ligesom et ur kan beskrive et<br />
tidspunkt. Events fungerer ved <strong>at</strong> reagere på et input. For eksempel kan<br />
et bestemt tidspunkt eller modtagelsen af en besked igangsætte en aktivitet.<br />
På samme måde kan afslutningen på en aktivitet kvitteres med en<br />
besked fra en event.<br />
De mest anvendte er start og slut eventen, som beskriver henholdsvis<br />
Figur 2 - Viser 3 <strong>for</strong>skellige typer af<br />
Events.<br />
starten og slutningen på en proces. Slut-eventen kan ikke igangsætte andre aktiviteter. Indimellem<br />
disse, anvendes intermedi<strong>at</strong>e events, og beskriver alle andre tænkelige begivenheder.<br />
Activity / Aktivitet<br />
En aktivitet vises som en firkant med afrundede hjørner. En aktivitet<br />
beskriver en arbejdsopgave som skal være gennemført, <strong>for</strong> <strong>at</strong> den efterfølgende<br />
proces kan <strong>for</strong>tsætte. For <strong>at</strong> bevare overblikket, beskrives arbejdsopgaver<br />
rel<strong>at</strong>ivt overordnet, såsom ”send en mail”. Trinene indimellem<br />
– tænd computer, åbn mailprogram, <strong>for</strong>muler mail, et. – beskrives<br />
ikke. Aktiviteter kan, ligesom events, opdeles i flere undergrupper.<br />
Den første er Task, som repræsenterer en enkelt arbejdsgang, og som<br />
ikke kan eller må nedbrydes til yderligere arbejdsgange.<br />
Dernæst findes sub-process eller delopgave, som bruges til <strong>at</strong> linke til<br />
andre delprocesser og markeres med et plus-tegn. Delprocesser anvendes til <strong>at</strong> simplificere opsætningen<br />
i procesdiagrammet, ved <strong>at</strong> vise/skjule delprocesser efter behov. Delprocesser fungerer<br />
selvstændigt med et start- og slutevent, og der må ikke laves rel<strong>at</strong>ioner til resten af processen<br />
indimellem disse. Delprocesser er også måden hvorpå man effektivt kan genbruge tidligere udviklede<br />
processer. Disse indsættes da som en delproces i den overordnede proces. Disse klassificeres<br />
henholdsvis priv<strong>at</strong>e (intern), abstract (offentlig) og collabor<strong>at</strong>ion (global), og beskriver hvorledes<br />
delprocessen kan optræde flere steder i diagrammet og i andre diagrammer.<br />
Figur 3 - Viser 2 <strong>for</strong>skellige Activity.
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
G<strong>at</strong>eway / Samlingspunkt<br />
En g<strong>at</strong>eway illustreres med en diamant<strong>for</strong>m og anvendes til <strong>at</strong> samle og sprede<br />
<strong>for</strong>bindelser på baggrund af bestemte konditioner. En slags universalt vejkryds,<br />
hvor stier. Udfaldet af g<strong>at</strong>eways bestemmes af typen; Exclusive g<strong>at</strong>eway tillader<br />
kun et enkelt output, Inclusive g<strong>at</strong>eway tillader mere end 1 og Parallel g<strong>at</strong>eway<br />
tillader alle input <strong>at</strong> passere til output.<br />
Connection / Forbindelse<br />
Connections skaber linket mellem begivenheder og aktiviteter, og illustreres med<br />
en stiplet eller en gennemgående streg. Forbindelser som kun fører en ene vej,<br />
illustreres med en pil i in<strong>for</strong>m<strong>at</strong>ionsretningen.<br />
Sequence Flow / Rækkefølge<br />
Et Sequence Flow vises med en gennemgående streg og en pil og angiver i hvilken<br />
rækkefælge aktiviteter må udføres. Særlige <strong>for</strong>hold angives med en lille diamant<strong>for</strong>m<br />
i starten af pilen. I Diamanten angives et nummer, som viser en af en række<br />
betingede strømme fra en aktivitet, mens en diagonal skråstreg angiver standard<br />
flow fra en afgørelse eller en aktivitet med betingede strømme.<br />
20. december<br />
2011<br />
Message Flow / Besked<br />
Message Flow illustreres ved en stiplet linie og en åben cirkel I starten og en åben pil I slutningen.<br />
Denne type anvendes til <strong>at</strong> vise beskeder som udveksles på tværs af pools, dvs. beskeder mellem<br />
to domæner, eksempelvis to virksomheder, organis<strong>at</strong>ioner eller afdelinger. Message flow anvendes<br />
aldrig inden<strong>for</strong> samme pool.<br />
Associ<strong>at</strong>ion / Rel<strong>at</strong>ion<br />
Denne anvendes til <strong>at</strong> associere noget abstrakt, som en tekst eller et billede, til et objekt. En retning<br />
kan illustreres med en åben pil mod objektet <strong>for</strong> <strong>at</strong> repræsentere et input. Vendes pilen<br />
mods<strong>at</strong>, altså væk fra objektet, illustreres et result<strong>at</strong>.<br />
Pools og Lanes<br />
Ved anvendelse af <strong>for</strong>retningsprocesser, er der ofte flere parter involveret.<br />
Det kunne være en virksomhed og en kunde, eller inden<strong>for</strong> byggeriet<br />
– arkitekt, ingeniør, entreprenør, etc., som optræder inden<strong>for</strong> hver deres<br />
domæne. Interaktion mellem proceselementer i <strong>for</strong>skellige domæner<br />
anskueliggøres ved <strong>at</strong> placere delprocesserne i såkaldte ”Pools”. Disse<br />
pools kan yderligere opdeles i ”lanes” <strong>for</strong> eksempelvis <strong>at</strong> illustrere hvordan<br />
<strong>for</strong>skellige processer kan tilhøre en bestemt afdeling, en fase el.lign.<br />
(www.bpmn.org, 2011)<br />
Figur 4 - Viser Illustr<strong>at</strong>ion af<br />
"G<strong>at</strong>eways".<br />
Figur 5 – Viser illustr<strong>at</strong>ion af<br />
"Connections".<br />
Figur 6 - Viser illustr<strong>at</strong>ion af<br />
"Pool" opdelt i "Lanes".<br />
3.1.1.2 Nyt i BPMN 2.0<br />
I den nye version kan der oprettes links mellem <strong>for</strong>tløbende processer. I stedet <strong>for</strong> <strong>at</strong> illustrere<br />
processer i et langt kontinuert diagram, kan en arbejdsproces deles op i delprocesser, <strong>for</strong> på den<br />
19
20. december<br />
2011<br />
20<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
måde <strong>at</strong> give læseren mulighed <strong>for</strong> <strong>at</strong> skabe sig et hurtigt overblik og en bedre <strong>for</strong>ståelse. Slutningen<br />
af en delproces vil da være illustreret med et link som fører til starten af den næste delproces.<br />
Linket vil udelukkende betyde en grafisk opdeling af den fulde proces – ikke en fysisk. Delprocesser<br />
vil altså opf<strong>at</strong>tes som en samlet proces hvis den overføres til et IT-system.<br />
For <strong>at</strong> understøtte intentionen om <strong>at</strong> dele og genbruge processer, er der nu mulighed <strong>for</strong> <strong>at</strong> specificere<br />
om BPMN’en beskriver en offentlig eller priv<strong>at</strong> <strong>for</strong>retningsproces. Offentlige processer deles<br />
over en d<strong>at</strong>abase, hvorimod priv<strong>at</strong>e ikke vil blive udgivet.<br />
3.1.1.3 Værktøjer<br />
Da BPMN er en åben standard, kan metoden findes i mange <strong>for</strong>skellige applik<strong>at</strong>ioner. Diagrammerne<br />
har alle samme layout, men modelleringsproces og brugervenlighed varierer meget. Deciderede<br />
programmeringsprogrammer, såsom Eclipse eller Aris, giver mange muligheder <strong>for</strong> videre<br />
anvendelse d<strong>at</strong>a i diagrammerne til udvikling af IT-systemer, men har også et mere teknisk og<br />
kompliceret tilgang i interfacet. Skal diagrammet udelukkende give en menneskelig <strong>for</strong>ståelse af<br />
en proces, kan programmer med fokus på layout og hurtig modellering være bedre <strong>at</strong> anvende.<br />
Onlineværktøjet Iyopro 1 tillader flere <strong>at</strong> arbejde sammen i samme diagram, og giver samtidig en<br />
grundig vejledning til funktioner og anvendelse af alle objekter igennem hele modelleringsprocessen.<br />
3.1.1.4 BPMN og BIM / Case<br />
Inden<strong>for</strong> byggeriet bruges BPMN ofte til <strong>at</strong> illustrere bygge-, arbejds- og udvekslingsprocesser. Det<br />
kunne være interne arbejdsprocesser, eksterne arbejdsprocesser eller metode <strong>for</strong> udveksling af<br />
d<strong>at</strong>a med samarbejdspartnere. Her er det en stor <strong>for</strong>del <strong>at</strong> anvende standardiserede løsninger<br />
som BPMN, så alle aktører kan bruge den samme løsning. Derved undgås en fragmentering af<br />
processen og denne kan følges fra start til slut.<br />
En IDM Process Map fra BuildingSMART, er eksempelvis altid baseret på BPMN. Det underliggende<br />
BPEL metasprog gør, <strong>at</strong> man ud fra sine Exchange Requirements (ER) kan genere en MVD, idet<br />
BuildingSMART har valgt denne som standard (ER/MVD uddybes senere i rapporten).<br />
På baggrund af de tilgængelige oplysninger i nærværende case, er BPMN ikke blevet anvendt –<br />
hverken i projektering eller planlægning af udførsel.<br />
1 http://www.iyopro.com/?lang=EN
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
3.1.2 IDEF (ICAM Definition) metoder<br />
IDEF metoden (Integr<strong>at</strong>ion DEFinition) er udviklet af det amerikanske US Air Force M<strong>at</strong>erials labor<strong>at</strong>ory.<br />
I 1976 grundlagde militærbasen Wright-P<strong>at</strong>terson ICAM projektet (Integr<strong>at</strong>ed Computer-<br />
Aided Manufacturing) i <strong>for</strong>søget på <strong>at</strong> modernisere de teknologiske faciliteter til fremstilling af<br />
m<strong>at</strong>eriel. Projektet eksisterer stadig og har i dag brugt over 100 mio. dollars på udviklingen af<br />
teknikker, processer og værktøjer til optimering af produktionsteknikker.<br />
IDEF er et objektorienteret modelleringssprog, som anvendes til <strong>at</strong> visualisere produktions- og<br />
softwaresystemer på en let anskuelig måde gennem diagrammer og symboler. IDEF er en familie<br />
bestående af ca. 10 værktøjer, hvor de mest anvendte er IDEF0 og IDEF1x. IDEF0 anvendes til <strong>at</strong><br />
modellere funktioner i en organis<strong>at</strong>ion eller et system, såsom beslutninger, handlinger og aktiviteter.<br />
IDEF1x er beregnet til modellering af in<strong>for</strong>m<strong>at</strong>ioner med særligt fokus på rel<strong>at</strong>ionelle d<strong>at</strong>abaser.<br />
I det følgende beskrives først IDEF0 og dets anvendelsesmuligheder inden<strong>for</strong> BIM projektering<br />
og dernæst IDEF1x.<br />
3.1.2.1 IDEF0<br />
IDEF0 er det mest simple modelleringssystem af de to - både grafisk og funktionsmæssigt, hvilket<br />
gør det meget anvendeligt som kommunik<strong>at</strong>ionsværktøj. Det giver en overskuelig måde <strong>at</strong> visualisere<br />
et <strong>her</strong>-og-nu billede af virkeligheden. Formålet med <strong>at</strong> anvende metoden IDEF0, er <strong>at</strong> kommunikere<br />
en eksisterende eller en fremtidig proces. Dette gøres vha. et diagram, med en fast<br />
fremgangsmåde og syntaks <strong>for</strong> opbygningen. IDEF0 har sin styrke i <strong>at</strong> kunne anskueliggøre processor<br />
<strong>for</strong> alle involverede parter. Effektive IDEF0 modeller bidrager til <strong>at</strong> organisere en analyse af et<br />
system og fremmer god kommunik<strong>at</strong>ion af teknisk karakter mellem analytiker og kunde/bruger.<br />
IDEF0 er desuden nyttigt til <strong>at</strong> fastslå omfanget af et projekt.<br />
Som et analyseværktøj, hjælper IDEF0 modeller med til <strong>at</strong> identificere hvilke funktioner der udføres<br />
i en proces, og hvilke inputs der er nødvendige <strong>for</strong> <strong>at</strong> udføre denne funktion. Ud fra diagrammet<br />
kan man hurtigt få et overblik over hvad et nuværende system gør rigtigt, og hvad systemet<br />
gør <strong>for</strong>kert. Der<strong>for</strong> er IDEF0 modeller ofte skabt som en af de første opgaver <strong>for</strong> en systemudviklingsinds<strong>at</strong>s.<br />
IDEF0 metoden er god, hvis man f.eks. skal opfylde flg. Scenarier:<br />
”Analysere eksisterende produktionssystemers funktionelle sammenhænge.<br />
Konstruere den funktionelle opbygning af nye systemer.<br />
Diskutere og kommunikere sammenhænge mellem funktioner i et system.<br />
Dokumentere og specificere systemer”.<br />
(Rasmussen, 1996)<br />
Grundlæggende består IDEF0 af inputs, outputs, controls og mechanisms. Kassen i midten kan<br />
være en aktivitet, handling, proces eller en oper<strong>at</strong>ion. På Diagram 3 og 4 ses et eksempel på opsætningen<br />
af en IDEF0 funktion i et diagram. Første eksempel er en skabelon <strong>for</strong> opsætningen og<br />
andet eksempel viser IDEF0 anvendt på byggesagen Musikkens Hus. (www.idef.com)<br />
21
20. december<br />
2011<br />
22<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Diagram 3 - Viser grundelementerne i IDEF0 diagrammer<br />
Diagram 4 - Eksempel på IDEF0 diagram på A-0 niveau <strong>for</strong><br />
Musikkens Hus.<br />
Inputs ”Inputs” angives med pile der tilgår funktionen fra venstre og angiver d<strong>at</strong>a /<br />
objekter som funktionen ændrer. På Diagram 3 er inputtet en konkurrence<br />
som bruges til <strong>at</strong> lave de færdige tegninger ud fra. En <strong>for</strong>m <strong>for</strong> råm<strong>at</strong>eriale<br />
som bearbejdes gennem funktionen.<br />
Mechanisms ”Mechanisms” angives med pile der tilgår funktionen fra neden og angiver<br />
den mekanisme der skal bruges af funktionen <strong>for</strong> <strong>at</strong> udføre processen. I Diagram<br />
3 er mekanismen ”software/værktøjer” og ”medarbejdere”, som funktionen<br />
skal bruge til <strong>at</strong> manipulere inputtet.<br />
Controls ”Controls” er angivet med pile der tilgår funktionen fra oven og angiver kontroller,<br />
betingelser og <strong>for</strong>hold der styrer / begrænser funktionen. I Diagram 3<br />
er betingelserne tid, ”Økonomi og krav/lovgivning” som stiller begrænsninger<br />
<strong>for</strong> den pågældende situ<strong>at</strong>ion.<br />
Outputs ”Outputs” er angivet med pile der udgår fra funktionen til højre og angiver<br />
d<strong>at</strong>a / objekter som funktionen resulterer i. I Diagram 3 er outputtet ”Færdige<br />
tegninger”.
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
3.1.2.2 Decomposing<br />
For overskuelighedens skyld er IDEF diagrammer<br />
sammens<strong>at</strong> af underfunktioner i et hierarkisk system.<br />
Figur 7 viser strukturen i IDEF0. Øverst vises det generelle<br />
diagram, som kaldes <strong>for</strong> en ”parant” -altså en<br />
<strong>for</strong>ældre til de mere detaljerede diagrammer som<br />
kommer efterfølgende. Øverste niveau af diagrammerne<br />
navngives Context eller A-0 diagrammer, og<br />
opsummerer den overordnede funktion af det valgte<br />
system og vises ved en enkelt kasse. Et A0 Diagram<br />
repræsenterer første nedbrydning af systemet. A0<br />
diagrammet og alle efterfølgende diagrammer indeholder<br />
typisk 3 til 6 nummererede bokse. Numrene<br />
hjælper med <strong>at</strong> binde diagrammerne sammen. Dette<br />
fremgår af figur xx, hvor boks 2 i diagram A0 er nedbrudt<br />
på diagram A2 og boks 3 på diagram A2 er nedbrudt<br />
på diagram A23. (William D. Waltman, 1993)<br />
Diagram 5 - Viser eksempel på et IDEF0 diagram på Context niveau <strong>for</strong> projektet Musikkens Hus<br />
20. december<br />
2011<br />
Figur 7- Viser en dekompositionen af IDEF0 metoden.<br />
23
20. december<br />
2011<br />
24<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
3.1.2.4 IDEF0 og BIM / Case<br />
Ved projektering i byggeri anvendes IDEF0 ofte som et værktøj til de indledende procesanalyser.<br />
Metoden er meget enkel og kan der<strong>for</strong> være hurtigere <strong>at</strong> sætte sig ind i end f.eks. BPMN. IDEF0 er<br />
ikke anvendt på Musikkens Hus, selvom der er fundet flere eksempler fra specielt Niras, som har<br />
eksperimenteret med IDEF0 i flere <strong>for</strong>skellige byggesager - bl.a. i samarbejde med BIPS. Ved BIPS<br />
projektmanual til 3D arbejdsmetode anbefales desuden IDEF0 som analyseværktøj, hvor også Bips<br />
egne illustr<strong>at</strong>ioner er vist efter IDEF0 metoden.<br />
3.1.3 IDEF1x<br />
IDEF1X er specielt egnet til udvikling af rel<strong>at</strong>ionelle d<strong>at</strong>abaser. Metoden er <strong>for</strong>holdsvis kompliceret<br />
og indeholder mange regler <strong>for</strong> korrekt opsætning. Der<strong>for</strong> vil vi i stedet fokusere på anvendelsesmulighederne<br />
inden<strong>for</strong> en BIM organis<strong>at</strong>ion. Der henvises til www.idef.com/idef1x.htm <strong>for</strong> mere<br />
in<strong>for</strong>m<strong>at</strong>ion omkring symboler, syntaks, etc.<br />
3.1.3.1 IDEF1x og BIM / Case<br />
IDEF1X fungerer på samme måde som E-R diagrammer. Rel<strong>at</strong>ionelle d<strong>at</strong>abaser visualiseres inden<br />
den funktionelle d<strong>at</strong>abase opbygges i et servermiljø.<br />
Ulempen ved IDEF1x, og alle andre metoder til modellering af rel<strong>at</strong>ionelle d<strong>at</strong>abaser, er <strong>at</strong> det<br />
kræver en del erfaring <strong>at</strong> lave gode diagrammer. Det handler om <strong>at</strong> gøre diagrammerne så simple<br />
så muligt, uden <strong>at</strong> gå på kompromis med funktionaliteten.
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
3.1.4 Unified Modeling Language (UML)<br />
UML er en de-facto standard <strong>for</strong> udseende af diagrammer til beskrivelse af strukturer og <strong>for</strong>løb i<br />
objekt-orienterede softwaresystemer. UML anvendes hovedsageligt til visualisering af funktioner<br />
og interface, inden en egentlig kodning af programmet påbegyndes. Det handler om <strong>at</strong> anskueliggøre<br />
funktioner og tilgangen til disse i softwaren, med særligt fokus på brugerens oplevelse. Af<br />
samme årsag er UML bygget op omkring et simpelt udtryk, som kan aflæses af folk uden en baggrund<br />
inden<strong>for</strong> IT, og agere samtalepl<strong>at</strong><strong>for</strong>m mellem programmører og brugere. Result<strong>at</strong>et lader<br />
programmøren arbejde ud fra et solidt grundlag <strong>for</strong> softwarens arkitektur, hvor alle <strong>for</strong>ventninger<br />
er afstemte og et klart mål med produktet er fastlagt.<br />
UML er, ligesom BPMN og IDEF0, administreret af OMG organis<strong>at</strong>ionen, som optog standarden i<br />
1997. UML startede som 3 næsten identiske systemer, udviklet af henholdsvis Grady Booch, Ivar<br />
Jacobsen og James Rumbaugh. I starten af halvfemserne blev alle tre ans<strong>at</strong> ved firmaet R<strong>at</strong>ional<br />
Software, og derfra blev deres systemer smeltet sammen til <strong>at</strong> danne UML. Den specielle tilblivelse<br />
medførte samtidig en rel<strong>at</strong>ivt upræcis definition af standarden og gav anledning til opd<strong>at</strong>eringen,<br />
UML 2.0. lanceringen kom i 2005, under ledelse af OMG, som så behovet <strong>for</strong> en skarpere<br />
definition af UML – <strong>for</strong>anlediget af den fragmentering af standarden, som et stigende antal softwareproducenter<br />
med hver sin <strong>for</strong>tolkning af specifik<strong>at</strong>ionen, havde bevirket. Fil<strong>for</strong>m<strong>at</strong>et er struktureret<br />
efter XML protokollen under navnet XMI og har opnået st<strong>at</strong>us som branche-standard.<br />
(http://da.wikipedia.org/wiki/UML).<br />
Det grafiske udtryk i et UML diagram bestemmes<br />
af diagramtypen. Det mest anvendte<br />
diagram, illustreret på Diagram 6, er klassediagrammet,<br />
som ofte bruges til systemdokument<strong>at</strong>ion<br />
og <strong>for</strong> <strong>at</strong> skabe et hurtigt overblik<br />
over sammenhængen i et system. I eksemplet<br />
til højre er vist illustr<strong>at</strong>ionen af et<br />
program, som <strong>for</strong>ener kundekartotek, projekthåndtering<br />
og økonomisystem.<br />
Formålet med UML-analysen og projektets Diagram 6 – Viser et eksempel på et Klassediagram.<br />
omfang dikterer valget af diagramtype.<br />
Der findes i dag 13 <strong>for</strong>skellige diagramtyper, under to <strong>for</strong>skellige hovedgrupper - henholdsvis UML<br />
1 fra UML 1.x udgivelsen og UML 2 fra UML 2.x. Alle typer er vist på OMG’s hjemmeside – se link:<br />
http://www.uml.org/.<br />
3.1.4.1 Værktøjer<br />
Ved UML er der metodefrihed, dvs. frit valg af værktøj/software. Dog skal man sammenholde<br />
projektets størrelse, med det værktøj man vælger <strong>at</strong> bruge. Mange <strong>for</strong>etrækker det dynamiske i<br />
en simpel skitsering på en tavle eller papir. Dette er selvfølgelig <strong>for</strong>beholdt mindre projekter<br />
25
20. december<br />
2011<br />
26<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
3.1.4.2 UML og BIM / Case<br />
Filosofien omkring BIM arbejdsprocessen beror i høj grad på interoperabilitet mellem softwareapplik<strong>at</strong>ioner,<br />
hvor d<strong>at</strong>a genanvendes gennem hele arbejdsprocessen og redundante d<strong>at</strong>a elimineres.<br />
Større projekteringsvirksomheder arbejder ofte med programmer designet specifikt til<br />
egne behov og virke, <strong>her</strong>iblandt økonomisystemer, planlægningsværktøjer, kundekartoteker, projekthåndteringssystemer,<br />
etc. Typisk er de ikke komp<strong>at</strong>ible og <strong>for</strong>står ikke <strong>at</strong> udnytte d<strong>at</strong>a på<br />
tværs. Her kan simple applik<strong>at</strong>ioner anvendes til <strong>at</strong> strømline in<strong>for</strong>m<strong>at</strong>ionshåndteringen i en organis<strong>at</strong>ions<br />
it-systemer og dermed lette arbejdsgang og ressourcer. UML bruges som indledende<br />
værktøj til udviklingen af de systemer som skaber linket mellem <strong>for</strong>skellige programmiljøer.<br />
3.1.4.3 UML og BIM / Case<br />
Ud<strong>for</strong>dringerne ved fuld implementering af BIM i små og mellemstore virksomheder ligger ofte i<br />
fragmenteringen af IT systemer. Ofte anvender virksomheder software fra mange <strong>for</strong>skellige producenter,<br />
til <strong>for</strong>skellige <strong>for</strong>mål hvilket kan resultere i lukkede softwaremiljøer som ikke taler<br />
sammen. Grundet begrænsede ressourcer samt igangværende projekter, er det ofte ikke muligt <strong>at</strong><br />
indføre alle BIM redskaber i en samlet proces.<br />
I rel<strong>at</strong>ion til BIM og optimering af egne systemer i et modelbaseret miljø, kan UML bruges som<br />
indledende værktøj til udvikling af systemer som skaber linket mellem programmiljøer, således<br />
programmerne kan anvendes effektivt i en samlet proces.
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
3.1.5 Entity-Rel<strong>at</strong>ionship model (E-R)<br />
E-R Modeller benyttes til <strong>at</strong> udvikle konceptuelle designs <strong>for</strong> d<strong>at</strong>abaser. Når en d<strong>at</strong>abase skal designes,<br />
er første skridt oprettelsen af E-R diagrammer. Disse hjælper designeren til en bedre <strong>for</strong>ståelse<br />
og specificerer ønskede dele af d<strong>at</strong>abasen og rel<strong>at</strong>ionerne imellem disse. En E-R model er<br />
et diagram, som indeholder entiteter (Entities), rel<strong>at</strong>ioner (Rel<strong>at</strong>ions), og <strong>at</strong>tributter (Attributes)<br />
på entiteterne og rel<strong>at</strong>ionerne. Gennem E-R modellen, får man illustreret en virkelig hændelse i<br />
en d<strong>at</strong>abase. I dag fungerer E-R modeller som fundament <strong>for</strong> mange system-analyse/design metoder.<br />
Ideologien bag E-R så <strong>for</strong> første gang dagens lys i A. P. G. Browns artikel “Modelling a Real-World<br />
System and Designing a Schema to Represent It” I 1975, hvorefter Peter Chen hurtigt så potentialet<br />
og introducerede E-R modellen i skriftet "The Entity-Rel<strong>at</strong>ionship Model - Toward a Unified<br />
View of D<strong>at</strong>a", som vist i cit<strong>at</strong>et <strong>her</strong>under. (wikipedia.org, 2011)<br />
“A d<strong>at</strong>a model, called the entity-rel<strong>at</strong>ionship model, is proposed. This model incorpor<strong>at</strong>es<br />
some of the important semantic in<strong>for</strong>m<strong>at</strong>ion about the real world. A special<br />
diagramm<strong>at</strong>ic technique is introduced as a tool <strong>for</strong> d<strong>at</strong>abase design” (Chen, 1976)<br />
Peter Chen erklærede E-R modellen <strong>for</strong> en konceptuel d<strong>at</strong>amodel, som ser den virkelige verden<br />
som enheder (entities) og rel<strong>at</strong>ioner (rel<strong>at</strong>ions), hvor den grundlæggende del af modellen er diagrammet,<br />
der bruges visuelt <strong>for</strong> <strong>at</strong> repræsentere d<strong>at</strong>aobjekterne i d<strong>at</strong>abasen. Et typisk eksempel<br />
ses på Diagram 7.<br />
Diagram 7 - Viser en typisk E-R Model.<br />
3.1.5.1 Peter Chens not<strong>at</strong>ioner <strong>for</strong> E-R modeller<br />
Ovenstående E-R diagram består af 3 typer objekter. Disse 3 typer er Entiteter, Rel<strong>at</strong>ioner og Attributter.<br />
De repræsenterer hver især et fænomen fra virkeligheden. Definitionen på de 3 objekttyper<br />
er som flg.:<br />
Entitet (Entity)<br />
”En entitet er en genstand, person, sted eller hændelse, som kan identificeres, og<br />
som har en sådan relevans <strong>for</strong> organis<strong>at</strong>ionen (in<strong>for</strong>m<strong>at</strong>ionssystemet), <strong>at</strong> der er behov<br />
<strong>for</strong> <strong>at</strong> registrere d<strong>at</strong>a om den/det”.<br />
Rel<strong>at</strong>ion (Rel<strong>at</strong>ion)<br />
27
20. december<br />
2011<br />
28<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
”en rel<strong>at</strong>ion repræsenterer en sammenhæng mellem entiteter i 2 eller flere <strong>for</strong>skellige<br />
entitetsklasser. Endelig kan en rel<strong>at</strong>ion også repræsentere en sammenhæng<br />
mellem entiteter inden<strong>for</strong> én og samme entitetsklasse”.<br />
Attribut (egenskab)<br />
”Attributter er beskrivende d<strong>at</strong>a, som angiver egenskaber ved entiteter eller rel<strong>at</strong>ioner”<br />
(Arbov) / (Pagh).<br />
Rel<strong>at</strong>ionsgrader (kardinaliteten)<br />
Rel<strong>at</strong>ionsgrader viser hvordan entiteterne og rel<strong>at</strong>ionerne kan associeres med hinanden. Dette<br />
sker via rel<strong>at</strong>ionsgrader eller kardinaliteten og <strong>for</strong>klares som følgende:<br />
1:1 (en til en) definition:<br />
En entitet kan kun rel<strong>at</strong>eres til en anden entitet.<br />
1:N (en til mange) definition<br />
En entitet kan rel<strong>at</strong>eres til flere andre entiteter, men ikke omvendt!<br />
N:N (mange til mange) definition:<br />
Flere entiteter kan rel<strong>at</strong>eres til flere andre entiteter. (In<strong>for</strong>m<strong>at</strong>ionsteknologi).<br />
Nedenstående Figur 8 viser de tre anvendte rel<strong>at</strong>ionsgrader.<br />
Figur 8 - Viser de <strong>for</strong>skellige rel<strong>at</strong>ionsgrader.<br />
Nøgler<br />
Formålet med nøgler er entydig identifik<strong>at</strong>ion. Attributterne bruges til <strong>at</strong> navngive/identificere<br />
rækker i tabellen. Disse kaldes ”nøgle<strong>at</strong>tributter” eller ”nøgler”. Der findes 5 slags nøgler:<br />
”En kandid<strong>at</strong>nøgle er en eller flere <strong>at</strong>tributter, som entydigt kan udpege række<strong>for</strong>ekomster i<br />
deres tabel. Der må ikke være flere <strong>at</strong>tributter med end nødvendigt.”<br />
”En primærnøgle er den kandid<strong>at</strong>nøgle, der er blevet valgt som den vigtigste identifik<strong>at</strong>ion af<br />
tabelens rækker. Den markeres med én understregning i tabelskitsen.”<br />
”En altern<strong>at</strong>ivnøgle er en kandid<strong>at</strong>nøgle der ikke er blevet valgt som primærnøgle.”<br />
”En sammens<strong>at</strong> nøgle, er en nøgle, der er s<strong>at</strong> sammen af flere <strong>at</strong>tributter.”
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
”En fremmednøgle, er en eller flere <strong>at</strong>tributter, der indeholder en værdi, der står som primærnøgle<br />
i en anden tabel, eller i en anden række i samme tabel” (Gustafson, 2007).<br />
Normal<strong>for</strong>mer<br />
Normal<strong>for</strong>mer omhandler en måde <strong>at</strong> <strong>for</strong>ædle sine d<strong>at</strong>a på, hvilket vil sige <strong>at</strong> gøre dem bedre. Der<br />
findes 9 normaliserings<strong>for</strong>mer, hvoraf denne semesterrapport kun vil beskæftige sig med de 3<br />
første. Dette skyldes <strong>at</strong> man utrolig sjældent kommer op og bruger de resterende normal<strong>for</strong>mer.<br />
Normal<strong>for</strong>mernes <strong>for</strong>mål er <strong>at</strong> lave så godt et d<strong>at</strong>abase design som overhovedet muligt, samt<br />
"ensrette" måden man udvikler en d<strong>at</strong>abase på. Ved <strong>at</strong> have en normaliseret d<strong>at</strong>abase sikrer man<br />
samtidig <strong>at</strong> der ikke er redundante d<strong>at</strong>a i tabellerne, hvilket ville resultere i et <strong>for</strong>kert d<strong>at</strong>agrundlag.<br />
Man sikrer også <strong>at</strong> d<strong>at</strong>abasen bliver overskuelig og nem <strong>at</strong> arbejde med. De første tre normal<strong>for</strong>mer<br />
beskrives typisk 1NF., 2NF. og 3NF.<br />
1. Normal<strong>for</strong>m (1NF).<br />
”En rel<strong>at</strong>ion er på første normal<strong>for</strong>m, hvis ingen af dens domæner har elementer, der i sig selv<br />
er mængder” (Andersen, 2008).<br />
2. Normal<strong>for</strong>m (2NF).<br />
”En rel<strong>at</strong>ion R er på anden normal<strong>for</strong>m, hvis den er på første normal<strong>for</strong>m, og hvis enhver ikkenøgle-<strong>at</strong>tribut<br />
er fuldt funktionelt afhængig af enhver kandid<strong>at</strong>nøgle i R.” (Andersen, 2008)<br />
3. Normal<strong>for</strong>m (3NF).<br />
”En rel<strong>at</strong>ion R er på tredje normal<strong>for</strong>m, hvis den er på anden normal<strong>for</strong>m og det gælder, <strong>at</strong> ingen<br />
ikke-nøgle-<strong>at</strong>tribut er transitivt afhængig af nogen kandid<strong>at</strong>nøgle i R.” (Andersen, 2008)<br />
Ovennævnte punkter er de vigtigste, når vi snakker E-R. Der er som skrevet flere, men disse vil<br />
ikke blive gennemgået i denne semesterrapport.<br />
3.1.5.2 Værktøjer<br />
Ligesom ved UML er der metodefrihed <strong>for</strong> modelleringsværktøj - man skal dog sammenholde<br />
projektets størrelse, med det værktøj man vælger <strong>at</strong> bruge. Mange <strong>for</strong>etrækker E-R Modelprogrammer<br />
som hjælper med <strong>at</strong> designe og redigere d<strong>at</strong>abaseskemaer, hvilket medfører <strong>at</strong> de<br />
abstrakte d<strong>at</strong>abaseobjekter og processer kan vises i et sammenhængende diagram.<br />
3.1.5.3 E-R og BIM / Case<br />
Nutidens byggeprojekter indeholder store mængder af in<strong>for</strong>m<strong>at</strong>ion og uden d<strong>at</strong>abaserne var det<br />
svært <strong>at</strong> bevare overblikket og navigere rundt i de store mængder d<strong>at</strong>a. En E-R Model definerer<br />
hvad der skal opbevares i selve d<strong>at</strong>abasen. Dette beskrives i termer som ”entities”, ”rel<strong>at</strong>ions” og<br />
”<strong>at</strong>tributes”, hvilket giver overblik over d<strong>at</strong>abasens opbygning. I dag bliver d<strong>at</strong>abaserne brugt til <strong>at</strong><br />
gemme virksomhedens d<strong>at</strong>a, websider, tegninger, dokumenter, etc.<br />
29
20. december<br />
2011<br />
30<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Musikkens Hus er af en vis størrelse og kompleksitet og skulle man printe alle dokumenter og<br />
tegninger, ville de involverede parter både have pladsproblemer og svært ved <strong>at</strong> begå sig i dokumenterne.<br />
Cit<strong>at</strong>et <strong>her</strong>under, af Birger Nürnberg, Friis og Moltke, beskriver problemstillingen:<br />
”Traditionelt ville man vise typeoversigter til de bydende i 1:200, men <strong>for</strong> et projekt af en kaliber<br />
som Musikkens Hus, vil 200dels-planerne hver fylde 1 m x 1½ m og samlet fylde adskillige<br />
hyldemeter, som alle har vanskeligt ved <strong>at</strong> finde rundt i.” (Bipsnyt, 2005)
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
3.2 BuildingSMART<br />
Til sammenligning med tidligere beskrevet analyse- og kortlægningsmetoder, har BuildingSMART<br />
udviklet et intern<strong>at</strong>ionalt standardsæt, som skal give alle byggeriets parter en ensartet proces, og<br />
derved effektivisere <strong>for</strong>løbet. Vi vil i dette afsnit starte med et historisk perspektiv og dernæst<br />
beskrive BuildingSMART’s væsentligste værktøjer, deres anvendelsesområde samt hvilken rolle de<br />
har spillet på byggesagen Musikkens Hus. BuildingSMARTs hovedområder er:<br />
Industry Found<strong>at</strong>ion Classes (IFC)<br />
Er udviklet som et fælles <strong>for</strong>m<strong>at</strong> der skal effektivisere udvekslingen af in<strong>for</strong>m<strong>at</strong>ioner.<br />
In<strong>for</strong>m<strong>at</strong>ion Delivery Manual (IDM)<br />
Er udviklet <strong>for</strong> <strong>at</strong> styre processen, med fokus på tidligger benævnte BPMN kortlægning.<br />
- Model View Definition (MVD)<br />
Anvendes til <strong>at</strong> definere i teknisk sprog hvilke in<strong>for</strong>m<strong>at</strong>ioner som er nødvendige i en given<br />
udveksling. MVD laves på baggrund af Exchange Requirements (ER).<br />
Intern<strong>at</strong>ional Framework <strong>for</strong> Dictionaries (IFD)<br />
Er udviklet som en intern<strong>at</strong>ional ordbog der kan referere til n<strong>at</strong>ionale standarder og lign.<br />
Gennem afsnittet vil ovenstående punkter blive uddybet.<br />
3.2.1.1 Historie<br />
I 1994 iværks<strong>at</strong>te Autodesk, under navnet Alliance For Interoprability, et industrielt konsortium<br />
som skulle rådgive virksomheder i udviklingen af et sæt C++ klasser (multiparadigm<strong>at</strong>isk programmeringssprog).<br />
Udover Autodesk tilsluttede der sig tolv andre amerikanske virksomheder til<br />
konsortiet. I 1995 åbnede konsortiet sig op <strong>for</strong> alle intern<strong>at</strong>ionale parter og skiftede navn til Intern<strong>at</strong>ional<br />
Alliance <strong>for</strong> Interoperability (IAI). Efterfølgende omdannede IAI sig til en nonprofit organis<strong>at</strong>ion,<br />
og skiftede i 2005 igen navn til BuildingSMART. I dag er BuildingSMART repræsenteret i<br />
35 lande, og har til <strong>for</strong>mål <strong>at</strong> skabe fælles standarder inden<strong>for</strong> IKT i byggeriet. Visionen bag <strong>for</strong>eningen<br />
er <strong>at</strong> skabe åbne intern<strong>at</strong>ionale standarter og neutral teknologi <strong>for</strong> <strong>at</strong> fremme en effektiv<br />
in<strong>for</strong>m<strong>at</strong>ionsflow gennem et byggeris livscyklus. Dette skal imødekommes gennem IFC, IFD og<br />
IDM, som er BuildingSMARTs hovedområder. Igennem dette kapitel vil disse tre standarder blive<br />
uddybet.<br />
3.2.1.2 Model Support Group (MSG)<br />
MSG er en gruppe af eksperter, der udvikler, tester og vedligeholder buildingSMART d<strong>at</strong>amodelstandarder.<br />
Hoved<strong>for</strong>målet med MSG er en løbende udvikling, <strong>for</strong>bedring og vedligeholdelse af<br />
IFC specifik<strong>at</strong>ionen samt støtte implementering i IFC-komp<strong>at</strong>ibel software. Hertil kommer, <strong>at</strong> MSG<br />
har ansvaret <strong>for</strong> <strong>at</strong> koordinere MVD, som er beskrevet i afsnittet IDM. Rel<strong>at</strong>erede specifik<strong>at</strong>ioner,<br />
såsom IDM, og IFD, er også understøttet af MSG i samarbejde med andre teams.<br />
MSG arbejdsopgaver:<br />
Udvikling af teknisk køreplan <strong>for</strong> IFC specifik<strong>at</strong>ion, <strong>her</strong>under indstilling af str<strong>at</strong>egiske og tekniske<br />
mål <strong>for</strong> IFC specifik<strong>at</strong>ionens arkitektur.<br />
Konsolidere og integrere nye model specifikke krav, frems<strong>at</strong> af IFC pioneer projekter.<br />
31
20. december<br />
2011<br />
32<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Løbende arbejde <strong>for</strong> <strong>at</strong> opretholde IFC-modellens specifik<strong>at</strong>ion, <strong>for</strong>bedre dens dokument<strong>at</strong>ion<br />
og indholdet af dens properties.<br />
Vedligeholde en ERFA-d<strong>at</strong>abase, korrigere fejl til kommende IFC frigivelser.<br />
Publicere, koordinere og harmonisere buildingSMART Intern<strong>at</strong>ionale Model View Definitions.<br />
Arbejde med implementerings guider, model guider, tutorials, læsevejledninger, og andre<br />
ledsage dokumenter.<br />
Støtte arbejdet i ISG og hjælpe med udgivelsen af implementeringsaftaler.<br />
Samarbejde med andre buildingSMART komiteer og støtte udviklingen af andre buildingS-<br />
MART standarder som IFD og IDM-aktiviteter.<br />
Samarbejde med eksterne standardiserings grupper <strong>for</strong> <strong>at</strong> harmonisere IFC-definitioner med<br />
andre ISO-standarder.<br />
General MSG koordineringsaktiviteter, <strong>her</strong>under regelmæssige møder og web-konferencer.<br />
(Liebich, 2011)<br />
3.2.1.3 Implement<strong>at</strong>ion Support Group (ISG)<br />
ISG er oprettet <strong>for</strong> <strong>at</strong> støtte implementeringen af buildingSMARTs standarder hos softwareudbyderne<br />
<strong>for</strong> derefter <strong>at</strong> certificere dem. Arbejdet ligger hovedsageligt omkring IFC import/eksport<br />
funktionen. Alle medlemmer af buildingSMART har mulighed <strong>for</strong> <strong>at</strong> benytte ISG.<br />
Formålet med ISG er:<br />
At støtte og koordinere brugen af IFC import / eksport funktionen hos de implementerende<br />
softwarevirksomheder.<br />
At administrere et <strong>for</strong>um <strong>for</strong> erfaringer med udveksling og implementeringen af IFC import /<br />
eksport funktionen, samt varetagelse af tekniske problemer.<br />
At promovere <strong>for</strong>dele ved IFC implementering. F.eks. ved demonstr<strong>at</strong>ion og deltagelse i <strong>for</strong>skellige<br />
messer <strong>for</strong> derved <strong>at</strong> kommunikere <strong>for</strong>delene ud til slutbrugeren.<br />
At varetage certifik<strong>at</strong>ionsprocessen, i samarbejde med MSG, <strong>for</strong> IFC import / eksport funktionen<br />
hos softwarevirksomheder.<br />
At overvåge implementeringen af IFC import / eksport funktionen hos softwarevirksomhederne<br />
og rapportere videre til andre grupper i buildingSMART organis<strong>at</strong>ionen.<br />
At repræsentere implementerende virksomheder og deres interesser i buildingSMART organis<strong>at</strong>ionen.<br />
(Liebich, 2011)
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
3.2.2 Industry Found<strong>at</strong>ion Classes (IFC)<br />
IFC er udviklet som et åbent fælles d<strong>at</strong>a<strong>for</strong>m<strong>at</strong>, der gør det muligt <strong>at</strong> udveksle og dele d<strong>at</strong>a mellem<br />
<strong>for</strong>skellige applik<strong>at</strong>ioner, af <strong>for</strong>skellige producenter inden<strong>for</strong> BIM. IFC er specifikt udviklet som<br />
et værktøj til <strong>at</strong> udveksle modelbaseret d<strong>at</strong>a imellem modelbaserede applik<strong>at</strong>ioner i byggebranchen.<br />
I dag er <strong>for</strong>m<strong>at</strong>et delvist understøttet af langt de fleste større udbydere af BIM applik<strong>at</strong>ioner<br />
til byggebranchen.<br />
Formålet med IFC er:<br />
At sikre, <strong>at</strong> d<strong>at</strong>a bliver globalt tilgængelige.<br />
At overføre geometrisk d<strong>at</strong>a mellem de projekterende.<br />
At overføre produktd<strong>at</strong>a til projekterende, udførende og bygningsejere.<br />
At overføre d<strong>at</strong>a fra bygningsmodel til analyseprogram.<br />
At anvende IFC d<strong>at</strong>a i produktionen hos de udførende.<br />
At langtidsopbevare bygningsmodeller.<br />
At kombinere egne d<strong>at</strong>a med et fælles accepteret <strong>for</strong>m<strong>at</strong> (Bips, 2004).<br />
3.2.2.1 EXPRESS<br />
IFC <strong>for</strong>m<strong>at</strong>et er baseret på EXPRESS metasproget samt en E-R model, hvilket desuden giver mulighed<br />
<strong>for</strong> <strong>at</strong> udvide koden med nye entities efter behov. EXPRESS sproget er <strong>for</strong>maliseret i ISO standarden<br />
STEP, hvilket er en intern<strong>at</strong>ional standard <strong>for</strong> repræsent<strong>at</strong>ion og udveksling af produktd<strong>at</strong>a,<br />
der kan <strong>for</strong>tolkes af en computer. STEP blev påbegyndt af ISO tilbage i 1984 <strong>for</strong> <strong>at</strong> centrere<br />
dele af deres arbejde på standarder omhandlende repræsent<strong>at</strong>ionen og udvekslingen af produktin<strong>for</strong>m<strong>at</strong>ioner<br />
generelt. Mange af de involverede aktører i STEP indså, <strong>at</strong> byggebranchen havde<br />
brug <strong>for</strong> et mere branchespecifikt <strong>for</strong>m<strong>at</strong>, som kunne repræsentere bygningsmodeller.<br />
3.2.2.2 IFC arkitekturen<br />
IFCs D<strong>at</strong>amodel er en kompleks størrelse. Den er skabt som et redskab til byggesektoren, men<br />
repræsenterer ikke kun fysiske elementer som f.eks. vægge, døre, bjælker osv., men også mere<br />
komplekse størrelser som f.eks. aktiviteter, områder, organis<strong>at</strong>ion og priser. Begge <strong>for</strong>mer <strong>for</strong><br />
elementer kaldes ”entities”. Den implementerede og anvendte udgave, IFC 2x3, har i alt 653 entities,<br />
hvilket betyder, <strong>at</strong> den repræsenterer 653 <strong>for</strong>skellige typer af komponenter eller koncepter.<br />
Med regelmæssige udgivelser af nye versioner, senest 2x3 og 2x4, har udviklingsarbejdet været<br />
undervejs i flere år. Den første version af IFC, version 1.0, blev udgivet i 1997. Den nyeste version,<br />
IFC 2x4 Candid<strong>at</strong>e 3, er netop frigivet til test, oktober 2011. For hver udgivelse tilføjes nye funktioner<br />
i <strong>for</strong>m af flere ”entities” og flere ”rel<strong>at</strong>ionships” rel<strong>at</strong>eret til en bygnings livscyklus. Udviklingen<br />
af IFC-modellen varetages af buildingSMARTs Model Support Group (MSG), som i dag ledes af<br />
Thomas Liebich. (Liebich, 2011)<br />
Arkitekturen i IFC-modellen er groft illustreret på Figur 9, som viser hvordan modellen er konstrueret<br />
og opdelt. I bredeste perspektiv kan IFC-modellen adskilles i fire lag (Domain Layer, Interoperability<br />
Layer, Core Layer og Ressource Layer) som hver især repræsenterer et <strong>for</strong>skelligt niveau i<br />
modellen. Hvert niveau består af flere <strong>for</strong>skellige koncepter og i hver koncept-k<strong>at</strong>egori er flere<br />
33
20. december<br />
2011<br />
34<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
entities defineret. De grønne viser koncepter som er certificeret efter ISO-standarden, og de<br />
orange er udvidelser som ikke er certificeret.<br />
Domain Layer:<br />
Domain Layer er det højeste<br />
niveau i IFC-modellen, og består<br />
af entity definitioner <strong>for</strong><br />
koncepter som er specifikke<br />
iht. individuelle domæner,<br />
såsom arkitektur, st<strong>at</strong>ik, facility<br />
management, etc. Eksempler<br />
på dette kunne være et<br />
rumskema til arkitekten; sokler,<br />
vægge og dæk til ingeniøren<br />
eller kedler, rør og radi<strong>at</strong>orer<br />
til VVS osv.<br />
Interoperability Layer:<br />
Interoperability Layer består af<br />
entities i flere koncepter, som<br />
er almindeligt brugt og delt<br />
imellem parterne i hele byggeprojektets<br />
livscyklus. ”Shared<br />
Building Elements”skemaet<br />
har entity definitioner<br />
<strong>for</strong> bjælker, søjler, vægge<br />
osv. ”Shared Building Services Elements”-skemaet har entity definitioner som flowkontrol, lydegenskaber<br />
osv.<br />
“Shared Facilities Elements”-skemaet indeholder entities <strong>for</strong> driftegenskaber omkring bygningen.<br />
Figur 9 - Viser et diagram over IFC2x3s arkitektur.<br />
Core Layer:<br />
Core Layer indeholder entities som repræsenterer abstrakte begreber, som bliver brugt til <strong>at</strong> definere<br />
entities i de højere lag. ”Kernel” skemaet repræsenterer f.eks. aktører, grupper, processer,<br />
produkter, <strong>for</strong>hold, etc. ”Product Extension” skemaet definerer abstrakte byggekomponenter som<br />
rum, grund, bygning, bygningselement, annot<strong>at</strong>ioner osv. De andre to skemaer definerer processer<br />
og kontrol, som er rel<strong>at</strong>erede koncepter, som procedurer, arbejdsplaner, arbejdsgo<strong>dk</strong>endelse,<br />
etc.<br />
Resource Layer:<br />
Dette lag indeholder k<strong>at</strong>egorier af entities som repræsenterer basale egenskaber, såsom geometri,<br />
m<strong>at</strong>eriale, kvalitet, mål, d<strong>at</strong>a, tid, pris osv. Grunden til <strong>at</strong> disse entities ligger i dette lag er <strong>at</strong> de<br />
er generiske og de ikke er specifikt til brug i byggebranchen. De fungerer som en ressource som<br />
bruges til <strong>at</strong> definere egenskaber i entities i højere lag.
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
IFC-modellens modulære design 2 har til <strong>for</strong>mål <strong>at</strong> gøre modellen lettere <strong>at</strong> vedligeholde samt <strong>at</strong><br />
videreudvikle. IFC-modellens lagstruktur er ud<strong>for</strong>met på en sådan måde, <strong>at</strong> en ”entity” på et givet<br />
niveau kun kan rel<strong>at</strong>ere til, eller være reference til en enhed, på samme niveau eller på et lavere<br />
niveau, men aldrig en enhed på et højere niveau. Eksempelvis indgår en vægenhed (kaldet<br />
IFCWall) i ”Shared Building Elements” som igen tilhører ”Interoperability Layer”.<br />
Diagrammet er yderligere opdelt i farverne orange og grøn. Den grønne del markerer ISO/PAS<br />
16739, som betyder <strong>at</strong> områderne er blevet certificeret af Intern<strong>at</strong>ional Standards Organis<strong>at</strong>ion<br />
(ISO). For <strong>at</strong> opnå denne certificering, skal modeldefinitionerne opnå bestemte og fasts<strong>at</strong>te kriterier.<br />
ISO Certifik<strong>at</strong>ionen blev tildelt i 2002, hvilket var kritisk <strong>for</strong> IFC, da det indebærer en bestemt<br />
kvalitet og niveau af stabilitet, hvilket gør det nemmere <strong>for</strong> priv<strong>at</strong>e som offentlige virksomheder,<br />
<strong>at</strong> indfører det som en standard. (Khemlani, 2011)<br />
Entity definitions<br />
Som tidligere beskrevet består arkitekturen af en EXPRESS-baseret E-R metode, der består af<br />
mange hundrede entities der er organiseret i et objektbaseret ”in<strong>her</strong>itance hierarchy”. Dette hierarki<br />
hjælper med <strong>at</strong> minimerer redundans og skaber rammerne og rel<strong>at</strong>ioner imellem de <strong>for</strong>skellige<br />
entities.<br />
Hvis vi f.eks. følger en ”wall entity” og en ”space entity”, hvilke er to af de mest benyttede basis<br />
komponenter i et hvert byggeri. Er det vigtigt <strong>at</strong> se hvordan de er repræsenteret, dels individuelt,<br />
dels med hinanden. Ydermere er det kritisk <strong>at</strong> man ser hvordan de rel<strong>at</strong>erer til hinanden, altså<br />
hvilke wall entities er <strong>for</strong>bundet til hvilke space entities. Når en wall entity er <strong>for</strong>bundet med andre<br />
entities som f.eks. en ”roof entity”, en ”slab entity”, en ”column entity”, en ”beam entity” osv.<br />
defineres den ved et ”entity hierarchy”, som vist i Figur 9.<br />
Dette betyder <strong>at</strong> ”wall entity” (IFCWall) definers som en undertype af ”Building Element entity”<br />
(IFCBuildingElement) som igen er en undertype af ”Element entity” (IFCElement) og så videre hele<br />
vejen op til Root entity (IFCRoot).<br />
Wall entity<br />
IFCWall arver sine ”<strong>at</strong>tributes” fra den ovenstående entity i hierarkiet, i dette tilfælde fra IFCBuildingElement<br />
Det kaldes Supertypes. I eksemplet er IFCWalls ovenstående niveauer abstrakte,<br />
hvilket betyder <strong>at</strong> de ikke kan ses visuelt i bygningsmodellen. Disse entities er lokaliseret i IFC’s<br />
Core Layer, se Figur 9. Som man kan se af Figur 10, er IFCWall ikke abstrakt og dermed repræsenteret.<br />
IFCWalls <strong>at</strong>tributter er defineret af den supertype (den har altså arvet; type, <strong>for</strong>m, placering,<br />
mængde, tilslutninger, åbninger, osv.)<br />
2 Modulært design er en tilgang som opdeler et system i mindre dele (moduler), der selvstændigt kan udvikles og anvendes i <strong>for</strong>skelli-<br />
ge systemer.<br />
35
20. december<br />
2011<br />
36<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Figur 10 - Viser definitionen på en wall entity og en space entity og rel<strong>at</strong>ionen<br />
imellem dem.<br />
Space entity<br />
IFCSpace er ligeledes defineret af<br />
”entity hierarchy” som det ses på<br />
Figur 10. IFCSpace er en ”subtype”<br />
af IFCSp<strong>at</strong>ialStructureElement<br />
som igen er en “subtype” af<br />
IFCProduct. Ligesom ved IFCWall<br />
eksemplet er IFCSpace ovenstående<br />
entities abstrakte. Forskellen<br />
til IFCWall er <strong>at</strong> IFCSpace har<br />
<strong>for</strong>uddefinerede <strong>at</strong>trubutes, men<br />
modtager sine properties fra<br />
ovenstående entity. Dette er<br />
gældende idet et space (rum)<br />
altid er defineret ud fra givne<br />
rammer i <strong>for</strong>m af vægge, lofter,<br />
dæk osv.<br />
Der findes <strong>for</strong>skellige typer af<br />
”rel<strong>at</strong>ionships” til <strong>at</strong> lave rel<strong>at</strong>ioner<br />
mellem de <strong>for</strong>skellige entities.<br />
F.eks. kan en “aggreg<strong>at</strong>ion<br />
rel<strong>at</strong>ionship” rel<strong>at</strong>er flere “space<br />
entities” sammen til en etage og et ”containment rel<strong>at</strong>ionship” kan rel<strong>at</strong>ere et møbels placering<br />
til et rum. Hvis der er krævet <strong>at</strong> en væg skal rel<strong>at</strong>eres til et rum, kræver den det specifikke ”containment<br />
rel<strong>at</strong>ionship” IFCRelContainedInSp<strong>at</strong>ialStructure. Som det ses på Figur 10 opererer dette<br />
”rel<strong>at</strong>ionship” på samme niveau som IFCElement og IFCSp<strong>at</strong>ialStructureElement, som betyder <strong>at</strong><br />
hvilket som helst element (væg, bjælke, søjle, dør, osv.) kan blive rel<strong>at</strong>eret til hvilket som helst<br />
sted i bygningen eller dens omgivelser (grund, bygning, etage, rum).<br />
Ansvaret <strong>for</strong> <strong>at</strong> disse rel<strong>at</strong>ioner er lavet ordentligt og fungerer på rigtig vis, ligger ifølge branche<strong>for</strong>eningerne<br />
udelukkende ved softwareudbyderne af programmerne som rummer en IFC eksport/import<br />
-funktion. Det giver IFC-modellen større fleksibilitet, hvis man undlader kravet om <strong>at</strong><br />
f.eks. en væg skal være rel<strong>at</strong>eret til et specifikt rum, men i stedet til en etage, bygning eller grund.<br />
Dette giver på samme tid en problemstilling. Fleksibiliteten er begrænset af, hvad der er tilladt<br />
inden<strong>for</strong> IFC specifik<strong>at</strong>ionen. Dette vil altid være afvejning af fleksibilitet, kontra driftssikkerhed.<br />
Driftssikkerheden vil variere, afhængig af muligheden <strong>for</strong> <strong>at</strong> ændre i tingene.<br />
Hvis en anden BIM-applik<strong>at</strong>ion senere i processen skal tolke IFC-filen og <strong>for</strong>venter netop ”rel<strong>at</strong>ion<br />
med et rum” og denne rel<strong>at</strong>ion ikke på <strong>for</strong>hånd er skabt i filen, sker der mis<strong>for</strong>tolkninger og man<br />
opnår ikke en korrekt udveksling. Der<strong>for</strong> er det meget vigtigt <strong>at</strong> hver enkelt applik<strong>at</strong>ion eksporterer/importerer<br />
IFC-filen efter samme <strong>for</strong>skrift. Dette er en bestemmende faktor <strong>for</strong> hvor succesfuld<br />
IFC udvekslinger bliver. (Khemlani, 2011)
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
Entity definitioner i IFC<br />
På det abstrakte niveau, inddeler IFC alle entities i ”rooted” og ”non-rooted” entities. Rooted entities<br />
stammer fra ”IFCRoot” og har identitet konceptet, hvilket betyder <strong>at</strong> en entity har en ”GUID”<br />
(Globally Unique IDentifier) sammen med ”<strong>at</strong>tributes” <strong>for</strong> et navn, beskrivelse og revisionskontrol.<br />
”Non-rooted” entities har derimod ikke nogen identitet og eksisterer kun hvis de bliver refereret<br />
til fra en intity eller flere entities. IFCRoot (hele IFC skemaet) er underopdelt i tre abstrakte koncepter:<br />
IFCObjectDefinition definerer m<strong>at</strong>erielle objekt<strong>for</strong>ekomster og typer. ”IFCObject” definerer objekt<strong>for</strong>ekomster<br />
som f.eks. ved en produktinstall<strong>at</strong>ion som har et serienummer og en fysisk placering.<br />
”IFCTypeObject” definerer typedefinitioner (eller skabeloner), som f.eks. en produkttype der<br />
har et modelnummer og en generel <strong>for</strong>m. Forekomster og typer er yderligere underopdelt i 6<br />
fundamentale koncepter:<br />
actors (”who”)<br />
Repræsenterer personer og organis<strong>at</strong>ioner.<br />
controls (”why”)<br />
Repræsenterer regler som kontrollerer tid, udgifter eller omfang.<br />
groups (”wh<strong>at</strong>”)<br />
Repræsenterer samlinger af objekter til et specielt <strong>for</strong>mal så som elektriske kredsløb<br />
products (”w<strong>her</strong>e”)<br />
Repræsenterer <strong>for</strong>ekomster i rum, så som fysiske byggeelementer og rumlok<strong>at</strong>ioner.<br />
processes (”when”)<br />
Repræsenterer <strong>for</strong>ekomster I tid, så som opgaver, begivenhed og procedurer.<br />
resources (”how”)<br />
Repræsenterer brug af noget der har begrænset rådighed, så som m<strong>at</strong>erialer, mandskab og<br />
maskiner.<br />
IFCRel<strong>at</strong>ionship definerer rel<strong>at</strong>ioner mellem objekterne. Der er 5 fundamentale rel<strong>at</strong>ionstyper<br />
mellem objekter:<br />
IFCRelDecomposes<br />
Indikerer <strong>at</strong> en entitet består af en eller flere dele af andre entiteter.<br />
IFCRelAssigns<br />
Fanger <strong>for</strong>holdet hvor et objekt omslutter en service af et andet objekt, så som en mandskabs<br />
ressource der er s<strong>at</strong> på en opgave der er sammenflettet med et bygnings element.<br />
IFCRelConnects<br />
Indikerer sammenslutningen imellem objekter såsom betondæk der ligger af på en stålbjælke,<br />
eller et rør der er s<strong>at</strong> sammen med en håndvask.<br />
IFCRelAssoci<strong>at</strong>es<br />
Indikerer en ekstern reference <strong>for</strong> et objekt så som et eksternt IFC biblioteks film hvor et<br />
object er defineret.<br />
IFCRelDefines<br />
37
20. december<br />
2011<br />
38<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Definerer en instance, af et <strong>for</strong>hold, så som et rør segment af en speciel type.<br />
IFCPropertyDefinition difinerer dynamiske ”properties” i objekterne. Et ”property set” indeholder<br />
et eller flere ”properties” som kan være en enkelt værdi (f.eks. string, nummer eller måle enhed),<br />
en bunden værdi (Som har et maksimum og et minimum), en tabel med værdier eller d<strong>at</strong>a struktur.<br />
Mens en IFC definerer flere hundrede ”property sets” <strong>for</strong> specifikke typer, må brugerdefinerede<br />
”property set” blive defineret af applik<strong>at</strong>ionsudbyderne eller slutbrugeren.<br />
IFCPropertySet<br />
Repræsenterer et sæt af egenskaber der er s<strong>at</strong> sammen med en <strong>for</strong>ekomst eller en objekt type.<br />
IFCPropertySetTempl<strong>at</strong>e<br />
[IFC2x4] fanger defin<strong>at</strong>ioner af egenskaber og deres d<strong>at</strong><strong>at</strong>yper. (Wikipedia, 2011)<br />
3.2.2.3 Certificering IFC-applik<strong>at</strong>ioner<br />
Indtil til nu har certificeringen af IFC import/eksport <strong>for</strong>egået gennem flere workshops, hvor de<br />
<strong>for</strong>skellige softwareudviklere skulle gennemgå to trin.<br />
Trin 1.<br />
Skulle hver enkelt softwareudvikler vise <strong>at</strong> deres applik<strong>at</strong>ion kunne håndtere et specifik Model<br />
View gennem en eller flere workshops.<br />
Trin 2.<br />
Skulle softwareudviklerne teste deres applik<strong>at</strong>ioner, gennem selvvalgte brugere. Dette skulle<br />
gøre det muligt <strong>at</strong> korrigere evt. fejl og derved give slutbrugeren et bedre produkt.<br />
IFC Certificering 2.0<br />
BuildingSMART udviklede i 2010 en ny certificeringsmetode til <strong>at</strong> <strong>for</strong>bedre kvaliteten og servicen<br />
<strong>for</strong> deltagende softwareudviklere. Certificeringsmetoden er skabt til <strong>at</strong> fremme en mere konsekvent<br />
og pålidelig implementering af IFC import / eksport funktionen hos softwareudviklere. Dette<br />
sker gennem en række kvalitetssikringsværktøjer, testcases i eksport / import med <strong>for</strong>skellig<br />
kompleksitet og adgang til et team af eksperter (ISG / MSG).<br />
IFC certificering 2.0 ”online certific<strong>at</strong>ion server” giver softwareudviklerne svar på følgende<br />
spørgsmål:<br />
Virker IFC i den anvendte softwareapplik<strong>at</strong>ion.<br />
Virker IFC i den anvendte proces.<br />
Hver enkelt certificering er styret af certificeringsmetode 2.0 og gælder <strong>for</strong> en bestemt delmængde<br />
af IFC skemaet (MVD som beskrives i et senere afsnit).
Diagram 8 - Viser et BPMN over en certifik<strong>at</strong>ion.<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
”The Coordin<strong>at</strong>ion View Version 2.0” er BuildingSMART<br />
Intern<strong>at</strong>ional først udviklede ”View definition” og den<br />
mest benyttede view af IFC skemaet. Formålet med<br />
”Coordin<strong>at</strong>ion View” er <strong>at</strong> muliggøre in<strong>for</strong>m<strong>at</strong>ionsudveksling<br />
mellem de <strong>for</strong>skellige discipliner (Arkitekt,<br />
Ingeniør og Facility Management). Det skal være muligt<br />
<strong>at</strong> tilføje og ændre i de importerede in<strong>for</strong>m<strong>at</strong>ioner<br />
gennem applik<strong>at</strong>ionen.<br />
”Coordin<strong>at</strong>ion View Version 2.0” er valgt som den første<br />
MVD der skal certificeres under den nye certificeringsmetode<br />
”Certific<strong>at</strong>ion 2.0”.<br />
20. december<br />
2011<br />
Model 1 - Viser ideologien bag Coordin<strong>at</strong>ion View Version<br />
2.0.<br />
39
20. december<br />
2011<br />
40<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
3.2.2.4 IFC og BIM / Case<br />
IFC fra BuildingSMART er uden tvivl det mest seriøse bud på et fælles fil<strong>for</strong>m<strong>at</strong>. Niels Treldal fra<br />
Rambøll udtaler til ingeniøren, <strong>at</strong>;<br />
“IFC ser ud til <strong>at</strong> være det eneste rigtige <strong>at</strong> bruge. Jeg opdagede, <strong>at</strong> <strong>for</strong>m<strong>at</strong>et i dag kan<br />
håndtere langt over halvdelen af de in<strong>for</strong>m<strong>at</strong>ioner om bygningen, som der er behov <strong>for</strong> …,<br />
… der sker ikke en videreudvikling af IFC, så det bliver mere <strong>at</strong>traktivt <strong>for</strong> byggebranchen,<br />
hvis der ikke er en efterspørgsel. Der<strong>for</strong> må branchen frem i skoene.” (ingeniøren, 2008)<br />
Nødvendigheden <strong>for</strong> en <strong>for</strong>ts<strong>at</strong> udvikling af <strong>for</strong>m<strong>at</strong>et <strong>for</strong>klares ved den begrænsede anvendelse i<br />
det daglige. Ofte bruges IFC kun til kollisionstest, hvor der ikke er behov <strong>for</strong> <strong>at</strong> sende d<strong>at</strong>a retur til<br />
modellen.<br />
På Musikkens Hus er der, ifølge Per J. Andersen Thorsager (økonomiansvarlig på byggepladsen),<br />
ikke anvendt IFC til udveksling og parternes bygningsmodeller. Dels <strong>for</strong>di IFC ikke var udviklet da<br />
cadmanualen til projektet blev udarbejdet, og dels <strong>for</strong>di der, ifølge Per J. A., er <strong>for</strong> mange komplik<strong>at</strong>ioner<br />
og mangler rel<strong>at</strong>eret til <strong>for</strong>m<strong>at</strong>et. (Niras F. &., 2011)<br />
3.2.3 In<strong>for</strong>m<strong>at</strong>ion Delivery ManuaI (IDM)<br />
IDM har til <strong>for</strong>mål <strong>at</strong> afdække hvem aktørerne er, og hvilke in<strong>for</strong>m<strong>at</strong>ioner der skal udveksles mellem<br />
parterne i en byggeproces. Ydermere beskriver IDM hvor i faserne den nødvendige in<strong>for</strong>m<strong>at</strong>ion<br />
skal udveksles. BIPS tegner i nedenstående cit<strong>at</strong>, et billede af hvor mange aktører / aktiviteter<br />
der er i en byggeproces.<br />
”I løbet af en byggeproces skifter et væld af in<strong>for</strong>m<strong>at</strong>ioner hænder. Der arbejdes<br />
med arealer, priser, tidsplaner, tegninger og meget andet, og disse udveksles mellem<br />
arkitekt, ingeniører, entreprenører og byg<strong>her</strong>re. Men der er behov <strong>for</strong>, <strong>at</strong> alle<br />
d<strong>at</strong>aleverancer sker på en system<strong>at</strong>isk og standardiseret måde, så den enkelte aktør<br />
ved, både hvad han/hun skal aflevere og kan <strong>for</strong>vente <strong>at</strong> modtage på et givent<br />
tidspunkt.” (BIPS)<br />
IDM kan bidrage til <strong>at</strong> optimere BIM, således den nødvendige in<strong>for</strong>m<strong>at</strong>ion og kvalitet <strong>for</strong>eligger på<br />
det rigtige tidspunkt. For <strong>at</strong> illustrerer en IDM proces benyttes Figur 11 og 12 fra ISO 29481. Figur<br />
11 illustrerer et ”In<strong>for</strong>m<strong>at</strong>ions skema” som dækker hele projektets fulde livscyklus, og dermed alle<br />
in<strong>for</strong>m<strong>at</strong>ionerne i et byggeprojekt. Måden IDM fungere på er <strong>at</strong> definere relevante in<strong>for</strong>m<strong>at</strong>ioner<br />
på rette tidspunkter som er illustreret i Figur 12. Her ses <strong>at</strong> in<strong>for</strong>m<strong>at</strong>ionerne bliver udvekslet gennem<br />
ER som er en række krav der beskriver hvad hver enkelt virksomhed skal bruge <strong>for</strong> <strong>at</strong> udføre<br />
deres rolle i projektet på et givent tidspunkt i byggeprocessen.
En IDM indeholder 3 bærende elementer:<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
Process Maps<br />
Process Maps har til <strong>for</strong>mål <strong>at</strong> beskrive aktiviteterne inden<strong>for</strong> de enkelte områder i projektet.<br />
Området beskrives i det efterfølgende afsnit.<br />
Exchange Requirements (ER)<br />
Er en beskrivelse af hvad der skal udveksles mellem aktørerne gennem projektets faser. Området<br />
beskrives senere i rapporten.<br />
Functional parts<br />
Er dele af in<strong>for</strong>m<strong>at</strong>ioner der tilsammen eller enkeltvis udgør en ER.<br />
3.2.3.1 Process Maps.<br />
Formålet med Process Maps er, <strong>at</strong> beskrive flowet af in<strong>for</strong>m<strong>at</strong>ioner og aktiviteter inden<strong>for</strong> et defineret<br />
projekt. Det er der<strong>for</strong> vigtigt, <strong>at</strong> alle aktører i fællesskab har fastlagt hvilke in<strong>for</strong>m<strong>at</strong>ioner<br />
de skal bruge gennem projektet og ikke mindst hvornår. Dette kræver en høj disciplin, i det hver<br />
enkelt aktør skal arbejde efter en overordnet struktur. Process Map indeholder:<br />
Mål<br />
Specifikke input (typisk krav fra andre udvekslingsprogrammer og d<strong>at</strong>akilder).<br />
Særlige result<strong>at</strong>er (typisk krav til andre udvekslingsprogrammer).<br />
Brugerressourcer.<br />
Figur 11 - Viser et projekts fulde livscyklus. Figur 12 - ´Viser en IDM proces.<br />
En række aktiviteter, der udføres i en vis orden.<br />
Påvirke mere end én organis<strong>at</strong>orisk enhed.<br />
Skaber værdi <strong>for</strong> kundernes behov.<br />
Det er vigtigt, <strong>at</strong> alle aktiviteter i processen bliver etableret i logisk rækkefølge, og alle ER identificeres<br />
<strong>for</strong> <strong>at</strong> skabe en effektiv proces. IDM Process Map kan med <strong>for</strong>del udarbejdes som et traditionelt<br />
BPMN. Grundene til, <strong>at</strong> dette kan være <strong>for</strong>delagtigt er:<br />
Det støttes af organis<strong>at</strong>ionen OMG, som er et konsortium inden<strong>for</strong> objektorienteret programmering.<br />
41
20. december<br />
2011<br />
42<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Det bliver brugt i stigende grad inden<strong>for</strong> specifik<strong>at</strong>ioner og inden<strong>for</strong> <strong>for</strong>retningsprocesser i<br />
større projekter.<br />
Der findes utallige simple og gr<strong>at</strong>is softwareløsninger på internettet.<br />
Not<strong>at</strong>ionen har en omregningsmetode til BPEL, som er en standard inden<strong>for</strong> <strong>for</strong>retningsprocesser<br />
med webservice.<br />
I dette kapitel er der anvendt softwaren, BiZagi, til <strong>at</strong> udføre diagrammerne, dette er et af de<br />
mange freewareprogrammer der kan <strong>hente</strong>s på internettet. (http://www.iai.no).<br />
Eksempel på Process Maps<br />
I dette afsnit vises der eksempler på hvordan Process Maps kan se ud og hvilke in<strong>for</strong>m<strong>at</strong>ioner de<br />
kan indeholde. Nedenstående Diagram 9 er lavet <strong>for</strong> install<strong>at</strong>ionsingeniørens proces.<br />
Diagram 9 - Viser install<strong>at</strong>ionsingeniørens overordnet Process Map.<br />
I Process Map, Diagram 9, kan man se de overordnet procestrin inden<strong>for</strong> install<strong>at</strong>ionslivscyklussen.<br />
1. Planlægning af install<strong>at</strong>ionssystem.<br />
2. Design af install<strong>at</strong>ionssystem.<br />
3. Install<strong>at</strong>ion af install<strong>at</strong>ionssystem.<br />
4. Test af install<strong>at</strong>ionssystem.<br />
5. Drift af install<strong>at</strong>ionssystem.<br />
6. Vedligehold.<br />
Mellem opgaverne indføres handlinger eller krav, som skal være <strong>for</strong>taget inden in<strong>for</strong>m<strong>at</strong>ionerne<br />
kan overgå til næste opgave. Man kan se i designfasen, <strong>at</strong> der er indtegnet handlinger mellem de
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
<strong>for</strong>skellige arbejdsgange. I dette eksempel beskriver handlingerne, koordineringen af result<strong>at</strong>erne,<br />
som enten kan resulterer i en go<strong>dk</strong>endelse eller kassering. Pilene der går tilbage til den <strong>for</strong>rige<br />
arbejdsgang viser, <strong>at</strong> result<strong>at</strong>erne evt. også kan sendes tilbage og blot ændres.<br />
I Process Map Diagram 10 som viser ”2.0 Design af install<strong>at</strong>ions system”, går vi dybere ind i processen.<br />
Her er flowet <strong>for</strong> udarbejdelsen af designet specificeret, dette giver de projekterende et<br />
overblik over arbejdsprocessen og fastlægger hvornår designet skal koordineres.<br />
Diagram 10 – Viser Process Map <strong>for</strong> ”Design af install<strong>at</strong>ion system”.<br />
Der hvor Process Maps virkelig kan hjælpe de projekterende, er i det projekterings <strong>for</strong>løbet, som<br />
er vist <strong>for</strong> ”2.1 Planlægning af design <strong>for</strong>løb” i Process Map, Diagram 10. Her kan man se hvilke<br />
krav og regler der stilles til udvekslings<strong>for</strong>løbet, dette skal være med til <strong>at</strong> effektivisere og mindske<br />
fejl.<br />
43
20. december<br />
2011<br />
44<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Diagram 11 - Viser install<strong>at</strong>ionsingeniørens analyse periode.<br />
Herunder er der beskrevet hver enkelt opgave:<br />
Projekt analyse:<br />
Opgave 2.1.1 viser hvilke in<strong>for</strong>m<strong>at</strong>ioner der skal til <strong>for</strong> opstart af denne fase. Som der er vist, er<br />
der vurderet, <strong>at</strong> der skal bruges in<strong>for</strong>m<strong>at</strong>ioner fra BIM modellen samt virksomhedens projekt<br />
guide. Projektguiden skal <strong>her</strong> <strong>for</strong>stås, som en guide hvor der er samlet oplysninger fra tidligere<br />
projekter. In<strong>for</strong>m<strong>at</strong>ioner fra BIM modellen, er de in<strong>for</strong>m<strong>at</strong>ioner der er tildelt netop dette område i<br />
tidligere faser.<br />
Overslag af pladskrav og tekniske områder:<br />
Opgave 2.1.2 viser hvilke in<strong>for</strong>m<strong>at</strong>ioner/krav der skal bruges <strong>for</strong>, <strong>at</strong> udarbejde et overslag af<br />
pladskrav og tekniske områder. In<strong>for</strong>m<strong>at</strong>ioner og krav er i dette tilfælde byg<strong>her</strong>rekrav, BR10 og de<br />
tekniske d<strong>at</strong>a der er vurderet, <strong>at</strong> skulle anvendes på dette tidspunkt i <strong>for</strong>løbet.<br />
Definer speciale områder:<br />
Opgave 2.1.3 viser <strong>at</strong> evt. specialområder i processen bliver udarbejdet ud fra byggeprogrammet.<br />
Aftal tekniske områder <strong>for</strong> videre projektering:<br />
Opgave 2.1.4 viser hvilke in<strong>for</strong>m<strong>at</strong>ioner der skal bruges <strong>for</strong>, <strong>at</strong> fastlægge hvor og hvordan den<br />
fremtidige projektering skal <strong>for</strong>løbe, dette kunne f.eks. være en større virksomhed der har <strong>for</strong>skellige<br />
afdelinger med <strong>for</strong>skellige speciale områder. Dette skal i dette tilfælde som vist udarbejdes ud<br />
fra firmaets struktur og opbygning.
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
Prisoverslag:<br />
Opgave 2.1.5 viser hvilke in<strong>for</strong>m<strong>at</strong>ioner der skal bruges <strong>for</strong>, lave et prisoverslag <strong>for</strong> projektet. I<br />
dette tilfælde bliver overslaget udarbejdet ud fra V&S og tidligere erfaringer der er gjort i lignende<br />
projekter. Forinden denne opgave er der lavet en koordinering <strong>for</strong> hvilke in<strong>for</strong>m<strong>at</strong>ioner fra <strong>for</strong>gående<br />
opgaver der skulle ligge til grundlag <strong>for</strong> beregningen. (Wix)<br />
Sammenf<strong>at</strong>ning<br />
Process Maps skal bruges som et værktøj til <strong>at</strong> effektivisere og fastlægge, proces -og in<strong>for</strong>m<strong>at</strong>ionsflow<br />
igennem et projekt. For <strong>at</strong> dette skal kunne lade sig gøre, skal der fra start laves grundige<br />
analyser af alle implicerede parters behov og processer. Udover dette skal de implicerede parter<br />
arbejde disciplineret, <strong>for</strong> <strong>at</strong> skabe det optimale result<strong>at</strong>.<br />
Eksemplerne i kapitlet har givet indblik i hvordan Process Maps kan være ud<strong>for</strong>met. Dette er selvfølgelig<br />
ikke et facit, da ingen projekter er ens. Der vil dog altid være nogenlunde samme str<strong>at</strong>egi,<br />
<strong>for</strong> hvert enkelt firmas interne arbejdsprocesser, som f.eks. ”2.1 Planlægning af design <strong>for</strong>løb”.<br />
3.2.3.2 Exchange Requirements (ER)<br />
ER repræsenterer <strong>for</strong>bindelsen mellem<br />
proces og d<strong>at</strong>a (In<strong>for</strong>m<strong>at</strong>ions model). Relevante<br />
oplysninger defineres i in<strong>for</strong>m<strong>at</strong>ionsmodellen<br />
til <strong>at</strong> opfylde kravene i en<br />
in<strong>for</strong>m<strong>at</strong>ionsudveksling mellem to <strong>for</strong>retningsprocesser<br />
på et bestemt tidspunkt i<br />
projektet.<br />
ER er en klar beskrivelse af de bestemte<br />
oplysninger, der skal udveksles på et givent Figur 13 - Illustrerer processen med ER.<br />
tidspunkt i et projekt. Det er hensigtsmæssigt <strong>at</strong> beskrive ER i ikke-tekniske termer. Den primære<br />
målgruppe <strong>for</strong> ER, er de implicerede aktører (arkitekt, ingeniør, konstruktør, osv.). Dog bør de<br />
også bruges af softwareudbyderne, eftersom de er nøglen til udvikling.<br />
ER indeholder følgende oplysninger:<br />
Fase / faser <strong>for</strong>, hvor et ER bliver brugt i processen.<br />
En oversigt der angiver indholdet og målet med udvekslingskravet, skrevet i en ikke-teknisk<br />
terminologi. Brugeren skal være klar over hvad udvekslingskravet dækker over og hvordan<br />
man akkvirerer den rigtige in<strong>for</strong>m<strong>at</strong>ion, men han behøver ikke <strong>at</strong> kende konkrete tekniske detaljer<br />
i kravet.<br />
ER kan være enkle, som f.eks. en ordre, der medfører <strong>at</strong><br />
en købsproces gør det muligt <strong>for</strong> en leverandør, <strong>at</strong> levere<br />
de nødvendige komponenter. Altern<strong>at</strong>ivt kan det<br />
være komplekst som f.eks. <strong>at</strong> en arkitekt skal give en<br />
grundlæggende bygningsmodel til en VVS-konsulent <strong>for</strong><br />
Figur 14 - illustrerer processen med ER.<br />
45
20. december<br />
2011<br />
46<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
<strong>at</strong> muliggøre en termisk analyse og dertilhørende beregninger. Figur 14 illustrerer et ER i et Process<br />
Map.<br />
ER kan opdeles i følgende:<br />
Header section indeholder administr<strong>at</strong>ive oplysninger omkring udvekslingskravet, dette omf<strong>at</strong>ter:<br />
Navn<br />
Et navn eller en titel til ER. Dette bør være i overensstemmelse med IDMs navngivnings regler.<br />
Identifier<br />
En ”unique identifier” bliver tildelt til et udvekslingskrav.<br />
Change log<br />
”Change log” eller ændringslogbog bruges til <strong>at</strong> markere oprettelsen af ER og har til <strong>for</strong>mål <strong>at</strong><br />
registrere <strong>for</strong>etagede ændringer over tid. D<strong>at</strong>oen <strong>for</strong> oprettelse / ændring bør indgå sammen<br />
med et id <strong>for</strong> den ansvarlige person og en kort beskrivelse af hvilke ændringer der er <strong>for</strong>taget.<br />
Project stage<br />
”Project stage” identificerer projektets fase/faser hvor ER anvendes. ER kan gælde <strong>for</strong> et eller<br />
flere af projektets faser. Der bør tages hensyn til tildelingen af ER til projektfaser, da disse oplysninger<br />
kan være af betydning <strong>for</strong> proces udbydere og vil være vigtigt <strong>for</strong> den fremtidige udvikling<br />
af proces-standarder ved hjælp af udvekslingskrav.<br />
Projektfaser bør anvendes konsekvent på alle udvekslingskrav. IDM bruger en liste over de faser<br />
baseret på udvikling af Generic Process Protocol.<br />
Herunder ses et eksempel på en header section:<br />
Tabel 1 - Viser et eksempel på Header Section.<br />
Overview section angiver mål og indhold af et ER som er kendt af aktøren. Målet er <strong>at</strong> aktøren<br />
skal være klar over, hvad der opnås med et ER, men ikke behøver <strong>at</strong> kende de tekniske detaljerne
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
<strong>for</strong>, hvordan det opnås. Den resterende del af ”overview section” bør udvide diskussionen og gøre<br />
<strong>for</strong>målet med et Process Map klart. Et eksempel på en overview section findes <strong>her</strong>under:<br />
Uddrag 1 – af en Overview section.<br />
47
20. december<br />
2011<br />
48<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
In<strong>for</strong>m<strong>at</strong>ion section opdeler de tekniske oplysninger der kræves af et ER. Det er teknisk i den<br />
<strong>for</strong>stand, <strong>at</strong> det giver de nødvendige oplysninger omkring tekniske aktioner inden<strong>for</strong> projektet og<br />
ikke i den <strong>for</strong>stand, <strong>at</strong> det giver en detaljeret oversigt over in<strong>for</strong>m<strong>at</strong>ionsstrukturen der kræves af<br />
en softwareløsning.<br />
Oplysningerne leveres i et sæt In<strong>for</strong>m<strong>at</strong>ion units hvilke der er nødvendige <strong>for</strong> <strong>at</strong> opfylde et ER. En<br />
In<strong>for</strong>m<strong>at</strong>ion unit beskæftiger sig typisk med en bestemt type af oplysninger eller begreber såsom;<br />
det samlede projekt, vægge, vinduer m.v. Herunder i Tabel 2, vises et udsnit af en In<strong>for</strong>m<strong>at</strong>ion<br />
Section:<br />
Tabel 2 :- Uddrag af In<strong>for</strong>m<strong>at</strong>ion Section.
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
3.2.3.3 Functional Parts<br />
Functional Parts er en detaljeret beskrivelse af de in<strong>for</strong>m<strong>at</strong>ioner, der bruges til <strong>at</strong> understøtter ER.<br />
Functional Parts beskriver således handlingerne der udføres gennem et ER. Hver enkelt Functional<br />
Part, kan stå alene som en fuld beskrevet in<strong>for</strong>m<strong>at</strong>ionsmodel, ligesom den også kan være en del<br />
af en samlet in<strong>for</strong>m<strong>at</strong>ionsmodel.<br />
Figur 15 viser sammenhængen mellem Exchange Requirements og Functional Parts.<br />
Functional Parts udgør de processer og handlinger, som udføres af hver enkelt aktør. En handling<br />
indeholder en del af eller alle in<strong>for</strong>m<strong>at</strong>ioner der udgør et Exchange Requirement. Dette vises på<br />
Figur 15, hvor Exchange Requirement, exchange_building_model, indeholder model_wall, model_window,<br />
model_door, model_slab og model_roof.<br />
Herunder kan hver enkelt Functional Part brydes op i flere Functional Parts. Som det fremgår af<br />
Figur 15, består model_door af flere Functional Parts. Functional Parts kan benyttes af flere ER.<br />
En Functional Part kan opdeles i følgende sektioner:<br />
Header section.<br />
Overview section.<br />
Result section.<br />
Technical section.<br />
Lists section.<br />
Schema section.<br />
Examples section.<br />
Software guidance.<br />
49
20. december<br />
2011<br />
50<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Header section beskriver den administr<strong>at</strong>ive in<strong>for</strong>m<strong>at</strong>ion:<br />
Tabel 3 - Viser en Header section<br />
Overview section beskriver målet i ikke-teknisk terminologi. Selvom en Functional Part er skabt til<br />
softwareudviklere, skal brugerne stadig kunne tyde indholdet.<br />
This functional part is aimed <strong>at</strong> identific<strong>at</strong>ion of the load bearing system(s), i.e. existing architectural in<strong>for</strong>m<strong>at</strong>ion must<br />
be appropri<strong>at</strong>ely re-structured to specify all load-bearing elements. Typically it is done in early design stages and helps<br />
to derive structural analysis models <strong>for</strong> calcul<strong>at</strong>ion and dimensioning. Since t<strong>her</strong>e is no specific class within IFC to capture<br />
load bearing systems, the generic class IFCSystem is used instead. For the definition of a load bearing system, which<br />
typically fulfills a specific task such as bearing of l<strong>at</strong>eral loads, all building elements needed to carry this type of loads<br />
shall be contained in the system.<br />
Note: IFCSystem in<strong>her</strong>its a couple of kernel concepts such as unique identific<strong>at</strong>ion, owner history, name and ot<strong>her</strong>s.<br />
Consequently, the functional part is to some extend similar to ot<strong>her</strong> functional parts.<br />
Uddrag 2 - Load Bearing Systems (FP)<br />
Result section beskriver result<strong>at</strong>et af målet<br />
A system defining a load bearing structure, which contains (via grouping) all load-bearing elements needed to fulfill this<br />
function.<br />
Uddrag 3 - Load Bearing System (FP)<br />
Technical section giver en detaljeret teknisk beskrivelse ved hjælp af udvalgte standarder<br />
Tabel 4 - Viser en Header section<br />
Beskrivelse og krav af de nødvendige<br />
in<strong>for</strong>m<strong>at</strong>ioner, specifik<strong>at</strong>ioner<br />
og værdier.<br />
Navn på den entity/<strong>at</strong>tribute<br />
eller<br />
set/property der skal bruges<br />
i IFC skemaet<br />
In<strong>for</strong>m<strong>at</strong>ionen skal være<br />
Oblig<strong>at</strong>orisk (mand<strong>at</strong>ory),<br />
Anbefalet (recomended)<br />
eller valfri (optional)
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Lists section beskriver hvilke Entities, d<strong>at</strong><strong>at</strong>ypes, functions and property der er brugt.<br />
Tabel 5 - Lists Section<br />
20. december<br />
2011<br />
Schema section presentere Functional Parts som skemaer. En Functional Part kan indeholde flere<br />
skemaer. Med IFC bliver tre skemaer typisk præsenteret; EXPRESS-G, EXPRESS og IFCXML.<br />
EXPRESS og EXPRESS-G<br />
EXPRESS er <strong>for</strong>maliseret i STEP (Standard <strong>for</strong> the Exchange of Product Model D<strong>at</strong>a), hvilket er en<br />
intern<strong>at</strong>ional standard <strong>for</strong> repræsent<strong>at</strong>ion og udveksling af produktd<strong>at</strong>a, der kan <strong>for</strong>tolkes af en<br />
computer. Se Diagram 12, hvor configure load bering system er vist som EXPRESS. Hvorimod EX-<br />
PRESS-G er den grafiske not<strong>at</strong>ion i EXPRESS (<strong>for</strong>mal in<strong>for</strong>m<strong>at</strong>ion requirements specific<strong>at</strong>ion language),<br />
som er beskrevet i ISO-standarden 10303-11. Se Diagram 12, hvor configure load bearing<br />
system er vist som EXPRESS-G. EXPRESS-G rummer figurer <strong>for</strong> alle ikoner og symboler, der benyttes<br />
i EXPRESS-G-not<strong>at</strong>ion til oprettelse af diagrammer på enhedsniveau og skemaniveau.<br />
(http://office.microsoft.com)<br />
Diagram 12 viser et Express-G skema.<br />
51
20. december<br />
2011<br />
Skema 1 - Express skema<br />
52<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Examples section giver eksempler på hvordan Functional Part er brugt <strong>for</strong> dermed <strong>at</strong> vejlede implementeringen.<br />
Software guidance beskriver hvordan softwareapplik<strong>at</strong>ioner understøtter Functional Parts.<br />
3.2.3.4 IDM og BIM / Case<br />
IDM har i dag en meget begrænset anvendelse i Danmark, ligesom i resten af verden. Motiv<strong>at</strong>ionen<br />
til <strong>at</strong> udnytte IDM, kommer først når man anvender IFC, hvilket stadig lader vente på sig.<br />
På Musikkens Hus har der af samme grund ikke været anvendt IDM, og kendskabet til metoden er<br />
i det hele taget meget begrænset hos de projekterende. (Niras F. &., 2011)
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
3.2.4 Model View Definition (MVD)<br />
Udviklingen af MVD begyndte i 1999, af IAI og var inspireret af BLIS projektet, som er en metode<br />
udviklet til <strong>at</strong> konvertere EXPRESS d<strong>at</strong>a til XML. MVD er udviklet <strong>for</strong> <strong>at</strong> supportere og styrke IFCspecifik<strong>at</strong>ionen<br />
og fungerer sammen med IFD og IDM. MVD er det tekniske link imellem IDM og<br />
IFC-integr<strong>at</strong>ionen i softwareapplik<strong>at</strong>ioner. I 2005 blev MVD officielt optaget af BuildingSMART og<br />
go<strong>dk</strong>endt til anvendelse med IFC og IDM. BuildingSMART står således <strong>for</strong> certificering og administr<strong>at</strong>ion<br />
af alle MVDer udviklet af BuildingSMART og andre uafhængige organis<strong>at</strong>ioner, som ønsker<br />
en officiel anvendelse af deres MVD.<br />
IFC <strong>for</strong>m<strong>at</strong>et dækker et kæmpe område og det er sjældent <strong>at</strong> én applik<strong>at</strong>ion anvender hele specifik<strong>at</strong>ionen<br />
- dels <strong>for</strong>di de samme ting ofte kan beskrives på flere <strong>for</strong>skellige måder og dels <strong>for</strong>di<br />
ikke alle funktioner er relevante. Der<strong>for</strong> er der ofte kun implementeret de elementer af IFCspecifik<strong>at</strong>ionen,<br />
som er nødvendige <strong>for</strong>, <strong>at</strong> det pågældende program kan udføre den funktion det<br />
er designet til. Eksempelvis har programmer til st<strong>at</strong>isk analyse ikke de samme behov som programmer<br />
til tidsstyring eller drift og vedligehold.<br />
En MVD kan betragtes som en delmængde af den samlede IFC specifik<strong>at</strong>ion - et ”View”/udsnit.<br />
For <strong>at</strong> sikre en konsekvent og ensartet IFC implementering, lader man softwareprogrammer blive<br />
certificeret efter MVDer, som er udviklet til et specifikt anvendelsesområde, f.eks. til energianalyse.<br />
View’et beskriver, iht. en specifik IFC-udgivelse, krav til udvalgte d<strong>at</strong>aentiteter, som er nødvendige<br />
i en given IFC udveksling. Der kan bl.a. stilles krav til classes, <strong>at</strong>tributes, rel<strong>at</strong>ionships,<br />
property sets eller quantity definitions, som alle er elementer/entiteter i IFC-specifik<strong>at</strong>ionen. (BIM<br />
Handbook)<br />
MVD laves på baggrund af ER fra IDM-skemaet. Kravene oversættes til tekniske begreber og bindes<br />
til en specifik IFC-udgivelse (eks. IFC2x3). En specifik udgivelse er nødvendig, da der bliver<br />
<strong>for</strong>etaget ændringer i IFC specifik<strong>at</strong>ionen <strong>for</strong> hver udgivelse, hvilket kan have indflydelse på de<br />
elementer som indgår i MVDen. ER er, mods<strong>at</strong> MVD, ikke afhængig af en specifik IFC udgivelse. På<br />
Uddrag 4 ses et eksempel på en MVD beskrivelse. (buildingsmart_tech.org, 2011)<br />
Uddrag 4- Officiel IAI beskrivelse af MVD <strong>for</strong> Architectural Programming to Architectural<br />
Design.<br />
53
20. december<br />
2011<br />
54<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
3.2.4.1 Udvikling af MVD:<br />
MVD er i dag baseret på EXPRESS-sproget, men der arbejdes <strong>for</strong> øjeblikket på udviklingen af en<br />
XML-definition kaldet mvdXML. I fremtiden er det der<strong>for</strong> hensigten, <strong>at</strong> alle officielt go<strong>dk</strong>endte<br />
MVD’er skal udgives i XML-<strong>for</strong>m<strong>at</strong>et, <strong>for</strong> <strong>at</strong> fremme udviklingen og udbredelsen af MVDer gennem<br />
et <strong>for</strong>m<strong>at</strong> med større interoperabilitet.<br />
MVD’er udvikles altid på baggrund af ER fra IDM manualen. På den måde motiveres udviklingen af<br />
MVD’er af konkrete behov fra brugerne, og der spildes ikke kræfter på unødvendig udvikling. Udviklingen<br />
af MVD’er <strong>for</strong>egår der<strong>for</strong> på to niveauer – det tekniske og det ikke tekniske, hvor det<br />
ikke tekniske omhandler ER modeller, og det tekniske oversættelsen til computersprog.<br />
En MVD samles af små ”byggeklodser”, kaldet functional parts eller concepts. Disse er små pakker<br />
af in<strong>for</strong>m<strong>at</strong>ion, som repræsenterer en eller flere funktioner i IFC specifik<strong>at</strong>ionen. Koncepter kan<br />
anvendes enkeltvis eller kombineres i mere komplekse sammenhænge, hvor flere sub-concepts<br />
tilsammen danner et Concept.<br />
Forskellige politiske og geografiske <strong>for</strong>hold gør, <strong>at</strong> nogle funktioner i en MVD kan være <strong>for</strong>skellige<br />
fra region til region. For <strong>at</strong> MVD’er kan anvendes over hele verden, op<strong>for</strong>drer IAI der<strong>for</strong> udviklere<br />
til, <strong>at</strong> funktioner knyttet til regionale betingelser, laves som såkaldte extension concepts. Extension<br />
Concepts anvendes altid i <strong>for</strong>bindelse med andre koncepter. Dermed kan brugere gøre generelle<br />
Model Views specifikke <strong>for</strong> deres område, samtidig med <strong>at</strong> den generelle MVD kan anvendes<br />
til certificering af software. (blis-project.org, 2011)<br />
MVD Diagrammer<br />
Et MVD diagram er en visuel illustr<strong>at</strong>ion af udvekslingskravene <strong>for</strong> d<strong>at</strong>a og d<strong>at</strong>astruktur i en specifik<br />
d<strong>at</strong>audveksling baseret på IFC. Der kan laves diagrammer <strong>for</strong> alle entiteter i IFC specifik<strong>at</strong>ionen,<br />
såsom doors, spaces, MEP, systems, building, etc.<br />
Der findes flere <strong>for</strong>skellige programmer til <strong>at</strong> udvikle diagrammer <strong>for</strong> disse. Diagrammerne laves<br />
efter metoden BPMN, som er en not<strong>at</strong>ions<strong>for</strong>m, der anvendes til <strong>at</strong> illustrere <strong>for</strong>retningsprocesser.<br />
Der findes BPMN plug-ins til de mest populære udviklingsværktøjer, såsom Eclipse, Netbeans<br />
og Aris EXPRESS, som alle er skrevet på Java pl<strong>at</strong><strong>for</strong>men. Diagrammerne bruges derefter til, <strong>at</strong><br />
genere en MVD baseret på en specifik IFC specifik<strong>at</strong>ion. (openifctools.org, 2011)<br />
Figur 16 – Viser struktur i IFC specifik<strong>at</strong>ionen.
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
3.2.4.2 Certificering af Model Views<br />
For <strong>at</strong> bruge en MVD skal den ikke nødvendigvis være officielt certificeret af BuildingSMART, selvom<br />
en certificeret MVD bliver hurtigere udbredt. Ønsker man <strong>at</strong> få sin MVD go<strong>dk</strong>endt officielt af<br />
BuildingSMART, indsendes MVD’en, hvorefter 4 (+1, Deprec<strong>at</strong>ed) <strong>for</strong>skellige stadier gennemgås.<br />
Alle MVD starter som drafts.<br />
Draft<br />
Alle personer, organis<strong>at</strong>ioner og virksomheder har ret til <strong>at</strong> oprette Model Views, uden restriktioner<br />
og <strong>for</strong>behold, så længe MVDen er tydeligt markeret med ”draft”. Så længe en MVD<br />
er i ”draft” har den ingen rel<strong>at</strong>ion til IAI.<br />
Proposal<br />
Ønsker man <strong>at</strong> få sin MVD go<strong>dk</strong>endt af IAI, markeres den med ”Proposal”, hvorefter der vil<br />
blive indsamlet erfaringer og <strong>for</strong>etaget små justeringer.<br />
Candid<strong>at</strong>e<br />
Når en MVD markeres med ”Candid<strong>at</strong>e” er den i gang med <strong>at</strong> gennemgå en validering hos IAI.<br />
IAI kigger på følgende kriterier:<br />
o Er MVDen skrevet i henhold til det officielle <strong>for</strong>m<strong>at</strong>?.<br />
o Anvendes IFC ?.<br />
Official<br />
Officiel st<strong>at</strong>us kan kun opnås <strong>for</strong> MVDer med Candid<strong>at</strong>e st<strong>at</strong>us. Når mere end en softwareapplik<strong>at</strong>ion<br />
er blevet certificeret imod en MVD, med Candid<strong>at</strong>e st<strong>at</strong>us, opnår MVDen Official st<strong>at</strong>us.<br />
Deprec<strong>at</strong>ed<br />
Når en MVD udgår efter <strong>at</strong> være blevet opd<strong>at</strong>eret eller <strong>for</strong>ældet, får den st<strong>at</strong>us som Deprec<strong>at</strong>ed.<br />
55
20. december<br />
2011<br />
56<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
3.2.4.3 Anvendelse af MVD<br />
Softwareudviklere<br />
Da IFC er en meget kompleks specifik<strong>at</strong>ion er<br />
der stor vari<strong>at</strong>ion i hvor godt IFC-integr<strong>at</strong>ion<br />
fungerer fra producent til producent i de <strong>for</strong>skellige<br />
BIM-pl<strong>at</strong><strong>for</strong>me. Problem<strong>at</strong>ikken ligger<br />
i in<strong>for</strong>m<strong>at</strong>ionstabet under udveksling og risikoen<br />
<strong>for</strong> fejl<strong>for</strong>tolkning af d<strong>at</strong>a-entiteter under<br />
import af IFC. Formålet med MVD er der<strong>for</strong><br />
<strong>at</strong> <strong>for</strong>bedre og dermed fremskynde implementeringen<br />
og brugen af IFC-integr<strong>at</strong>ion i<br />
BIM-applik<strong>at</strong>ioner. Det er meningen, <strong>at</strong> soft-<br />
Figur 17 – Viser hvordan sammenhængen i mellem MVD og IDM<br />
er.<br />
wareproducenter skal kunne optimere deres egen IFC-integr<strong>at</strong>ion, ved <strong>at</strong> kontrollere IFCeksporten,<br />
imod centrale Model Views, hvorefter producenter kan få certificeret deres IFC integr<strong>at</strong>ion<br />
ved BuildingSMART, imod enhver MVD med Candid<strong>at</strong>e eller Official st<strong>at</strong>us.<br />
Brugere<br />
MVDer kan være udviklet til generelle anvendelsesområder, eller rettet mod et mere specifikt<br />
udvekslingsbehov.<br />
For slutbrugere anvendes Model Views til <strong>at</strong> kontrollere og stille krav om kvaliteten af den in<strong>for</strong>m<strong>at</strong>ion<br />
der ønskes udvekslet mellem eksempelvis arkitekt og ingeniør, på et givent tidspunkt.<br />
Metoden kan anvendes af både afsender og modtager, som henholdsvis afsender- og modtagekontrol.<br />
Som eksempel kan nævnes en MVD <strong>for</strong> ”structural analysis”. For <strong>at</strong> softwaren kan kontrollere<br />
om alle nødvendige in<strong>for</strong>m<strong>at</strong>ioner fra IDMen er til stede og repræsenteret korrekt i IFC<br />
filen, skal softwaren med IFC integr<strong>at</strong>ion vide hvilke in<strong>for</strong>m<strong>at</strong>ioner der <strong>for</strong>ventes <strong>at</strong> være indeholdt<br />
i IFC filen. Således skal alle in<strong>for</strong>m<strong>at</strong>ioner, som er nødvendige <strong>for</strong> <strong>at</strong> lave en st<strong>at</strong>isk analyse,<br />
være til stede <strong>for</strong> <strong>at</strong> arbejdsprocessen kan <strong>for</strong>tsætte. Alle in<strong>for</strong>m<strong>at</strong>ioner som ikke er direkte rel<strong>at</strong>eret<br />
til den pågældende opgave kan samtidig udelades, så modellen bliver lettere <strong>at</strong> arbejde i.<br />
Dette gøres i programmer som Solibri eller IFC model checker, hvor MVDen indlæses sammen<br />
med modellen. Cuneco, center <strong>for</strong> produktivitet i byggeriet, arbejder desuden på en internetbaseret<br />
model-checker med samme funktioner.<br />
På Model 2 og 3 illustreres en arkitektmodel og<br />
et udtræk med Structural Analysis viewet. Det<br />
ses <strong>at</strong> arkitektmodellen er <strong>for</strong>holdsvis detaljeret,<br />
hvorimod ingeniørmodellen kun indeholder elementer<br />
som indgår i det st<strong>at</strong>iske system. Viewet<br />
har desuden en call-back funktion, hvilket betyder<br />
<strong>at</strong> nye in<strong>for</strong>m<strong>at</strong>ioner oprettet i ingeniørmodellen<br />
kan føres tilbage i arkitektmodellen.<br />
Den første officielle MVD, som blev udviklet af<br />
BuildingSMART, hed Coordin<strong>at</strong>ion View. Hoved<strong>for</strong>målet<br />
med dette View, er <strong>at</strong> koordinere og muliggøre<br />
d<strong>at</strong>audveksling mellem arkitekt, ingeniør og udfø-<br />
Model 3 - Viser Structural Analysis.<br />
Model 2 - Viser arkitektmodel.
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
rende. Viewet indeholder definitioner <strong>for</strong> rumlige <strong>for</strong>hold, bygningselementer og rå-d<strong>at</strong>a omkring<br />
bygningen, som er nødvendig <strong>for</strong> <strong>at</strong> koordinere byggeriet.<br />
Coordin<strong>at</strong>ion viewet er meget generelt defineret, og kaldes også en base definition. For <strong>at</strong> tilpasse<br />
views til projekter, er det muligt <strong>at</strong> udvide disse med extension koncepter. Det kan være nye koncepter<br />
eller allerede udviklede koncepter. Man tilføjer små ”dele” af andre MVD, <strong>for</strong> <strong>at</strong> gøre<br />
viewet specifikt <strong>for</strong> den aktuelle opgave.<br />
Det er intentionen <strong>at</strong> alle BIM software applik<strong>at</strong>ioner med IFC integr<strong>at</strong>ion skal indeholde et eller<br />
flere MVDer, selvom der i dag ikke er særlig mange eksempler på dette.<br />
Ser man på MVD i et fremtidsperspektiv, er det sandsynligt <strong>at</strong> eksempelvis myndighederne laver<br />
en MVD, som beskriver alle nødvendige oplysninger I <strong>for</strong>bindelse med en myndighedsgo<strong>dk</strong>endelse.<br />
(buildingsmart_tech.org, 2011)<br />
57
20. december<br />
2011<br />
58<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
3.2.5 Intern<strong>at</strong>ional Framework <strong>for</strong> Dictionaries (IFD)<br />
Til et ISO møde, i 1999, mødtes et bredt udvalg af organis<strong>at</strong>ioner, som udviklede standarder til<br />
byggesektoren. Dette møde fandt sted i Vancouver. Der var enighed om <strong>at</strong> lave nogle fælles standarder<br />
<strong>for</strong> byggesektoren. Disse nye standarder skulle også kunne <strong>for</strong>stås af computere, således<br />
det var muligt <strong>at</strong> overføre d<strong>at</strong>a fra én PC til en anden, på tværs af landegrænser og sprog. Det<br />
førte til oprettelsen af komiteen TC59/SC13/WG6. Dette samarbejde resulterede i standarden ISO<br />
12006-3 (Framework <strong>for</strong> Object-oriented In<strong>for</strong>m<strong>at</strong>ion Exchange).<br />
Efterfølgende indledte BARBi (projekt i Norge) og LexiCon (projekt i Holland) et arbejde, der skulle<br />
resultere i nogle standarder til byggesektoren. Begge projekter blev udviklet på baggrund af ISO<br />
12006-3 standarden.<br />
Januar 2006 blev der ud<strong>for</strong>met en samarbejdsaftale i mellem BARBi, LexiCon og TC59/SC13/WG6.<br />
Denne aftale lagde grunden til IFD. Målet med denne organis<strong>at</strong>ion, var <strong>at</strong> lave en fælles ontologi<br />
<strong>for</strong> byggesektoren (Grant & Mehus, IFD Library Business Plan - Version 1.0, 2009).<br />
I 2008 blev dette samarbejde optaget i buildingSMART Intern<strong>at</strong>ional organis<strong>at</strong>ionen. Denne gruppe<br />
kaldes i dag <strong>for</strong> IFD Library Group.<br />
Som det ses på Figur 18 ligger de brugerorienterede aktiviteter, under Intern<strong>at</strong>ional User Group<br />
(IUG). Det er i dette <strong>for</strong>um brugernes behov og input bliver oms<strong>at</strong> til brugbare løsninger. Den tekniske<br />
del er placeret under ITM.<br />
Figur 18 - Viser hvor og hvordan IFD er placeret i buildingSMART organis<strong>at</strong>ionen.
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
3.2.5.1 IFD Library<br />
IFD Library (buildingSMART ordbog) er en flersproget ordbog og/eller ontologi. I ordbogen er der<br />
en …<br />
… oppbygging av referansebibliotek som inneholder begreper med tilhørende definisjoner<br />
og relasjoner til andre begreper (BuildingSmart).<br />
Det betyder f.eks. <strong>at</strong> der er en norsk definition/beskrivelse af ”en dør”. Denne beskrivelse kan, via<br />
IFD API’en, oversættes til en amerikaner (et menneske) eller en amerikansk IFC fil. Dette sikre, <strong>at</strong><br />
man kan kommunikere på tværs af landegrænser og definitioner. På den måde optimerer man<br />
in<strong>for</strong>m<strong>at</strong>ionsudveksling, både digitalt og analogt.<br />
Via IFD’en, er der en mulighed <strong>for</strong> <strong>at</strong> øge in<strong>for</strong>m<strong>at</strong>ionsmængden, i <strong>for</strong>hold til en standard IFC-fil.<br />
IFC-filen rummer ikke nødvendigvis alle de ønskede in<strong>for</strong>m<strong>at</strong>ioner, som modtagerne måtte have<br />
brug <strong>for</strong>. På Figur ?? ses det, hvor IFD Library kan få sine in<strong>for</strong>m<strong>at</strong>ioner fra.<br />
Figur 19 - Viser hvor IFD Library kan få sine in<strong>for</strong>m<strong>at</strong>ioner fra.<br />
Disse in<strong>for</strong>m<strong>at</strong>ioner kan tilmed blive leveret på modtagerens eget sprog.<br />
På Figur 19 ses et eksempel på, hvordan man kan tilføre properties/in<strong>for</strong>m<strong>at</strong>ioner. I venstre kolonne<br />
ses produktet. I dette tilfælde en ”Gypsum plaster board”. I kolonnen th. ses alle de properties<br />
der er mulighed <strong>for</strong> <strong>at</strong> tilknytte dette produkt. Kolonnen i midten viser alle de properties der<br />
er til valgt. Dette gøres i en ”Propertylizer”.<br />
59
20. december<br />
2011<br />
60<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Figur 20 - Viser hvordan man tilføjer properties/oplysninger.<br />
IDF Library har flere anvendelsesmuligheder. Afhængig af opgaven, kan den bruges …<br />
… som ”alm. Ordbog”. Dvs. <strong>at</strong> mennesker kan slå op i den, læse og <strong>for</strong>stå, det der står.<br />
… som ”PC-ordbog”. Dvs. <strong>at</strong> én tysk IFC export-fil, kan oversættes til en amerikansk IFC import-fil,<br />
i mellem 2 <strong>for</strong>skellige stykker software.<br />
… til hele tiden <strong>at</strong> opd<strong>at</strong>erer IFD Library<br />
(Bell & Bjørkhaug, http://dev.ifdlibrary.org/index.php/Ifd:IFD_<strong>for</strong>_Innov<strong>at</strong>ive_Sustainable_Housing).<br />
IFD er IKKE …<br />
... et klassifik<strong>at</strong>ionssystem. IFD kan dog indeholde flere <strong>for</strong>skellige typer af klassifik<strong>at</strong>ionssystemer.<br />
… en ontologi. IFD kan indeholde mange <strong>for</strong>skellige ontologier.<br />
… et altern<strong>at</strong>iv til IFC. IFD er et supplement til IFC.<br />
(Juha Hyvärinen, 2007)<br />
Globel Unique Identifier/Universal Unique Identifier (GUID/UUID)<br />
Alle Entity’s får, via IFD’en, en Global Unique Identifier (GUID) eller Universal Unique Identifier<br />
(UUID).<br />
Det man har gjort er, <strong>at</strong> man har fjernet betydningen/in<strong>for</strong>m<strong>at</strong>ionen fra ”ordet”, og i stedet koblet<br />
en GUID op på ”ordet”. På den måde får man en GUID <strong>for</strong> alle koncepter, på alle sprog. Det der<br />
styre hvordan de <strong>for</strong>skellige koncepter rel<strong>at</strong>ere til hinanden, er defineret i ISO standarden<br />
(Bjørkhaug, 2010 ) / (Grant & Mehus, IFD Library Business Plan - Version 1.0, 2009)
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Figur 21 viser hvordan dette unikke nummer bliver skabt/sammens<strong>at</strong>.<br />
Figur 21 - Viser hvordan en GUID/UUID bliver til, via en IFD.<br />
20. december<br />
2011<br />
3.2.5.2 IFD applic<strong>at</strong>ion (API - Applic<strong>at</strong>ion Programming Interface)<br />
I 2010 kom 2. version af IFD API’en. Den hedder v. 3.0. (første version hed 2.0.5). IFD API’en er<br />
lavet som en Web Services Description Language (WDSL), på EXPRESS sproget.<br />
I dag rummer IFD API’en 20 sprog, 15500 concepts, 67700 names, 4100 rel<strong>at</strong>ions (Bell &<br />
Bjørkhaug, http://dev.ifd-library.org/images/2/23/IfcIfd1.png).<br />
IFD og klassifik<strong>at</strong>ion – DBK<br />
Der <strong>for</strong>egår pt. et arbejde, der skal få implementeret DBK i IFD. Dette er der et stort perspektiv i,<br />
da DBK så ville kunne anvendes på intern<strong>at</strong>ionale projekter også.<br />
Ud<strong>for</strong>dringen pt., er <strong>at</strong> få tilpasset DBK til ISO 12006- standarden (konvergens, Udviklingsplan <strong>for</strong><br />
Dansk Bygge, 2010).<br />
Sammenf<strong>at</strong>ning<br />
Vi ser IFD som én af løsningerne (i samarbejde med IDM og IFC) på mange af de ud<strong>for</strong>dringer byggebranchen<br />
står over<strong>for</strong>, både n<strong>at</strong>ionalt og ikke mindst intern<strong>at</strong>ionalt. Det er dog meget svært <strong>at</strong><br />
se, hvor langt man er i arbejdet, og hvor langt væk man er, fra noget der ville kunne bruges. Desværre<br />
er vores <strong>for</strong>nemmelse, <strong>at</strong> vi er et stykke vej, fra noget der kan bruges i den virkelige verden.<br />
61
20. december<br />
2011<br />
62<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
3.2.5.3 IFD og BIM / Case<br />
Projektet Musikken Hus, er et intern<strong>at</strong>ionalt projekt. I dette <strong>for</strong>um ville en IFD være ideel, da der<br />
er nogle sproglige ud<strong>for</strong>dringer, der skal løses (en engelsk akustiker, en Østrigsk arkitekt og danske<br />
entreprenører).<br />
Via IFD, løser man f.eks. problemet med <strong>for</strong>skellige definitioner / ontologier i byggebranchen.<br />
IFD blev ikke anvendt i projektet.
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
3.3 Klassifik<strong>at</strong>ion og udveksling<br />
Brugen og omfanget af in<strong>for</strong>m<strong>at</strong>ion, er eksploderet de seneste år. Det gælder både generelt i folks<br />
hverdag, men så sandelig også inden<strong>for</strong> byggeriet. Mængden af in<strong>for</strong>m<strong>at</strong>ioner kan <strong>for</strong>ekomme<br />
uoverskuelig, og meget svær <strong>at</strong> sortere i. Der<strong>for</strong> er det nødvendigt <strong>at</strong> få s<strong>at</strong> in<strong>for</strong>m<strong>at</strong>ionerne i<br />
nogle ”kasser” og systemer. Derved bliver in<strong>for</strong>m<strong>at</strong>ionerne lettere <strong>at</strong> overskue, og dermed nemmere<br />
<strong>at</strong> anvende de relevante steder. Det er <strong>her</strong> klassifik<strong>at</strong>ion kommer ind i billedet.<br />
Klassifik<strong>at</strong>ion er vigtigt, <strong>for</strong>di det sikrer, <strong>at</strong> vi taler ”samme sprog”, og <strong>at</strong> vi bruger de samme termer,<br />
om de samme ting.<br />
… ”Taxonomier og klassifik<strong>at</strong>ion anvendes overalt, hvor vi færdes i dagligdagen: i<br />
supermarkedet, i aviser, på biblioteket, i arkiver etc..<br />
Ved klassifik<strong>at</strong>ion opdeles in<strong>for</strong>m<strong>at</strong>ion ved hjælp af emneord efter emne, egenskab<br />
eller aktivitet. Disse emner grupperes i et hierarkisk system, en taxonomi, så de udgør<br />
en samlet struktur. Strukturen i taxonomien giver så samtidig udtryk <strong>for</strong> rel<strong>at</strong>ionerne<br />
mellem grupperne.” (http://www.taxon.<strong>dk</strong>/artikler/taxonomi.htm, 2008)<br />
Klassifik<strong>at</strong>ion<br />
Bruger man <strong>for</strong>skellige termer og begreber, i kommunik<strong>at</strong>ionen, kan der meget let opstå mis<strong>for</strong>ståelser,<br />
som kan medføre fejl i vores projekt. Fejl er tit lig med ekstra omkostninger. Ekstra omkostning<br />
i <strong>for</strong>m af tid, resurser og økonomi. Bla. der<strong>for</strong> er klassifik<strong>at</strong>ion også vigtig, når vi snakker<br />
udveksling af in<strong>for</strong>m<strong>at</strong>ioner. Det kan være udveksling internt og eksternt, både n<strong>at</strong>ionalt og intern<strong>at</strong>ionalt.<br />
Når vi snakker udveksling med intern<strong>at</strong>ionale samarbejdspartnere, er det <strong>her</strong> samarbejdet<br />
i mellem IFD og klassifik<strong>at</strong>ion, kommer os til god nytte. klassifik<strong>at</strong>ionen sørger <strong>for</strong> <strong>at</strong> få<br />
ordnet og ”strømlinet” vores in<strong>for</strong>m<strong>at</strong>ioner, og IFD’en sørger <strong>for</strong> <strong>at</strong> få overs<strong>at</strong> in<strong>for</strong>m<strong>at</strong>ionerne til<br />
et sprog modtageren <strong>for</strong>står.<br />
I byggeriet findes der flere n<strong>at</strong>ionale klassifik<strong>at</strong>ionssystemer, desværre ikke noget intern<strong>at</strong>ionalt<br />
fælles anerkendt system … endnu. De nuværende systemer omf<strong>at</strong>ter bla. BSAB (Sverige), DBK<br />
(Danmark), Uniclass (England), Omniclass (canadisk/amerikansk) og JCCS (japansk).<br />
Klassifik<strong>at</strong>ion og IFD. Det samme?<br />
Nej, det er det ikke. IFD er ikke et klassifik<strong>at</strong>ionssystem. Men IFD kan indeholde klassifik<strong>at</strong>ionssystemer.<br />
På samme måde, som IFD kan oversætte termer og koncepter fra et sprog, til et andet,<br />
kan IFD også oversætte fra ét klassifik<strong>at</strong>ionssystem, til et andet klassifik<strong>at</strong>ionssystem. Eks. fra DBK<br />
til Omniclass (DBK er ikke en del af IFD endnu, men der arbejdes på, <strong>at</strong> det bliver).<br />
Seneste initi<strong>at</strong>iv<br />
September 2011, tog en dansk deleg<strong>at</strong>ion til møde i den intern<strong>at</strong>ionale standardiseringsorganis<strong>at</strong>ion.<br />
Målet med denne deleg<strong>at</strong>ion var, <strong>at</strong> få revideret den intern<strong>at</strong>ionale standard <strong>for</strong> byggeklassifik<strong>at</strong>ion,<br />
ISO 12006-2. Deleg<strong>at</strong>ionen bestod af repræsentanter fra Dansk Standard (Jan Fuglsig<br />
Lambrecht), <strong>for</strong>eningen Bips (Gunnar Friborg) og Cuneco. Initi<strong>at</strong>ivet blev godt modtaget, og der<br />
var bred intern<strong>at</strong>ional opbakning til <strong>for</strong>slaget.<br />
63
20. december<br />
2011<br />
64<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
”Forslaget fra den danske deleg<strong>at</strong>ion går blandt andet ud på <strong>at</strong> udvikle nye tabeller<br />
og tydeliggøre eller omarbejde standarden, så den også giver mulighed <strong>for</strong> <strong>at</strong> klassificere<br />
byggeobjekter i en ”del-af”-struktur. Dvs. en struktur, hvor man kan vise,<br />
hvordan en given bygningsdel indgår i den mere komplekse struktur den er en del<br />
af. ”Del-af”-strukturen har gode anvendelsesmuligheder, når man <strong>for</strong> eksempel arbejder<br />
med BIM, bygningsin<strong>for</strong>m<strong>at</strong>ionsmodellering” (Skovgaard, 2011).<br />
Arbejdet skal ledes af Dansk Standard, og den tilhørende projektgruppe skal sammensættes af<br />
intern<strong>at</strong>ionale deltagere. Fra dansk side, har man <strong>for</strong>eslået Henrik Balslev 3 (fra Balslev & Jacobsen<br />
ApS), som <strong>for</strong>mand <strong>for</strong> denne arbejdsgruppe<br />
Sideløbende med disse aktiviteter, skal Cuneco <strong>for</strong>tsætte deres udviklingsarbejde med DBK. Dette<br />
omf<strong>at</strong>ter bl.a. flere prøveprojekter (Skovgaard, 2011).<br />
3 ”Henrik Balslev er <strong>for</strong>mand <strong>for</strong> S-503 – et dansk udvalg <strong>for</strong> bl.a. in<strong>for</strong>m<strong>at</strong>ionsstrukturering og dokument<strong>at</strong>ion – i Dansk Standard, der<br />
er den danske såkaldte spejlkomite til ISO SC13” (Skovgaard, 2011) .
4 Praktiske <strong>for</strong>hold<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
4.1 Hvordan <strong>for</strong>egår in<strong>for</strong>m<strong>at</strong>ionsudveksling i dag?<br />
Dette kapitel omhandler in<strong>for</strong>m<strong>at</strong>ionsudvekslingen på byggeprojekter, Musikkens Hus i Nordjylland.<br />
I denne sammenhæng er vi blevet s<strong>at</strong> i <strong>for</strong>bindelsen med Rambøll, Niras, og Friis og Moltke,<br />
som er projekterende på projektet. Friis og Moltke er Coop Himmelb(l)au´s danske <strong>for</strong>bindelse,<br />
<strong>for</strong> <strong>at</strong> skabe et projekt, der lever op til danske standarder og behov.<br />
4.2 Møde med parterne<br />
Den 24. oktober blev der afholdt et møde med Friis og Moltke, Niras og Rambøll, angående deres<br />
erfaringer med in<strong>for</strong>m<strong>at</strong>ionsudveksling på Musikkens Hus. Grundet den lange proces projektet<br />
har været igennem, har udviklingen af in<strong>for</strong>m<strong>at</strong>ionsflowet udviklet sig fra det traditionelle til et<br />
objektbaseret miljø. Hovedsageligt har ændringen bestået i, <strong>at</strong> parterne har udskiftet deres gamle<br />
2D applik<strong>at</strong>ioner med avancerede 3D applik<strong>at</strong>ioner. Denne ændring mener alle implicerede parter<br />
har været nødvendig, <strong>for</strong> <strong>at</strong> projekterer et så kompleks byggeri som Musikkens Hus.<br />
4.2.1 In<strong>for</strong>m<strong>at</strong>ionsudveksling.<br />
Der er ikke stillet krav om IFC, som fælles udvekslings<strong>for</strong>m<strong>at</strong> i <strong>for</strong>bindelse med projekteringen,<br />
hvilket alle parter også ser som umuligt. Flere af parterne har erfaret, fra tidligere projekter, <strong>at</strong><br />
brugen af IFC, ikke har været tilstrækkelig præcis, grundet applik<strong>at</strong>ionernes fejlbehæftede IFC<br />
integr<strong>at</strong>ion.<br />
Projektet har været en del år undervejs. Der<strong>for</strong> er cad-manualen ikke helt tidssvarende. Var den<br />
blevet lavet i 2011, var der givet andre <strong>for</strong>hold der gjorde sig gældende. DWG-<strong>for</strong>m<strong>at</strong>et er det<br />
officielle udvekslings<strong>for</strong>m<strong>at</strong> i projekt Musikkens Hus.<br />
Rambøll har i samarbejde med stålleverandøren J. Langkjær Stålbyg A/S, skabt sagens mest effektive<br />
udvekslingsproces, idet de begge benytter Tekla Software.<br />
Dette gør <strong>at</strong> J. Langkjær Stålbyg A/S kan, med få rettelser, benytte Rambølls fagmodel direkte i<br />
deres produktion.<br />
4.2.2 Cad-manual<br />
Selvom der har været store ændringer i processen, har der ikke været grundlag <strong>for</strong> <strong>at</strong> lave store<br />
ændringer i CAD-manualen, da det gennem hele projektet har været 2D CAD tegninger, og dermed<br />
.dwg som udvekslings<strong>for</strong>m<strong>at</strong>.<br />
Parterne ser nærmere fremtidens CAD-manualen, som en IKT-manual, da in<strong>for</strong>m<strong>at</strong>ioner er mere<br />
end 2D og 3D udveksling. Rambøll har et ønske om <strong>at</strong> manualen skal indeholde krav og specifik<strong>at</strong>ioner<br />
om hvilke in<strong>for</strong>m<strong>at</strong>ioner der skal <strong>for</strong>eligge gennem de <strong>for</strong>skellige faser.<br />
4.2.3 BuildingSMART<br />
Parterne mener ikke det er muligt <strong>at</strong> benytte BuildingSMART´s værktøjer i dag, da IFCén stadig<br />
skaber fejl og tab ved in<strong>for</strong>m<strong>at</strong>ionsudveksling. Der er dog enighed om <strong>at</strong> ideologien bag BuildingSMART<br />
er noget man kan arbejde videre på, dog er man nød til <strong>at</strong> anvende det med de muligheder<br />
man har i dag.<br />
65
20. december<br />
2011<br />
66<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
4.2.4 Sammenf<strong>at</strong>ning<br />
Konklusionen på afsnittet er, <strong>at</strong> alle parter er enige om <strong>at</strong> der skal <strong>for</strong>eligge en mere struktureret<br />
proces, <strong>for</strong> <strong>at</strong> effektivisere anvendelsen af BIM. Før opstart skal der <strong>for</strong>eligge krav om in<strong>for</strong>m<strong>at</strong>ionsniveauer<br />
og standarder, ud fra parternes interne processer.<br />
Der er ikke anvendt IFC på trods af <strong>at</strong> både Niras og Rambøll har erfaringer fra lignende projekter,<br />
hvor de har kunnet benytte enkelte aspekter fra IFCén.
5 Eksport eksperimentet<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
Efter mødet med sagens parter (Niras, Rambøll og Friis & Moltke), stod det klart, <strong>at</strong> de hver især<br />
tidligere har oplevet ud<strong>for</strong>dringer, i <strong>for</strong>hold til IFC- modellernes troværdighed. Der<strong>for</strong> s<strong>at</strong>te vi os<br />
<strong>for</strong>, <strong>at</strong> prøve og lave nogle tests af eksportfunktionen i <strong>for</strong>skellige typer software. Forsøgene skal<br />
vise de <strong>for</strong>skellige programmers evne til <strong>at</strong> eksportere en IFC – fil (IFC version 2x3). Forsøgene er<br />
interessante, <strong>for</strong>di IFC er ´det fil<strong>for</strong>m<strong>at</strong>, som alle er enige om, skal være fremtidens udvekslings<strong>for</strong>m<strong>at</strong>.<br />
Testmiljø og <strong>for</strong>udsætninger<br />
Til <strong>for</strong>søgene er der valgt programmerne Revit v. 2012 (Autodesk), Archicad 14 (Graphisoft ) og<br />
Vico Constructor 8 (Vico software). De 3 softwarepl<strong>at</strong><strong>for</strong>me har samme målgruppe mht. brugere,<br />
da de alle primært henvender sig til arkitektfaget/projektering. Programmerne har <strong>for</strong>skellige<br />
opbygninger, det gælder bl.a. måden de håndterer d<strong>at</strong>a på og deres brugerflade. For <strong>at</strong> sammenligne<br />
applik<strong>at</strong>ionernes eksportfunktion, er der benyttet Solibri Model Viewer. Premissen <strong>her</strong> er, <strong>at</strong><br />
Solibri er en neutral aktør på markedet, og kan der<strong>for</strong> bruges som en fælles reference.<br />
Forsøget er bygget op omkring en model, som indeholder nedennævnte geometri. Proceduren er<br />
derefter, <strong>at</strong> modellen eksporteres fra hver af de 3 pl<strong>at</strong><strong>for</strong>me, og ind i Solibri. I Solibri ses result<strong>at</strong><br />
af eksporten, og eventuelle afvigelser vil kunne ses der.<br />
Modellen som skal eksporteres har følgende d<strong>at</strong>a:<br />
Generisk vægge (sort):<br />
- Bredde: 300 mm.<br />
- Højde: 3000 mm.<br />
Generisk gulv (grøn):<br />
- Top niveau: 0 mm.<br />
- Bund niveau: -300 mm.<br />
Vindue (brun):<br />
- Højde: 912 mm.<br />
- Bredde: 1112 mm.<br />
- Placering i højde: 900 mm.<br />
Dør (pink):<br />
- Højde: 2112 mm.<br />
- Bredde: 912 mm.<br />
- Placering i højde: 0 mm.<br />
Cirkulær søjle (grå):<br />
- Radius: 150 mm.<br />
Figur 22 - Viser geometrien på <strong>for</strong>søgsmodel.<br />
Placering af vindue og dør, er s<strong>at</strong> i centermidtpunkt af objekt i midten af den generiske væg. På<br />
samme måde er generisk gulv afs<strong>at</strong> iht. Midtpunkt i væggene.<br />
67
20. december<br />
2011<br />
68<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Fremgangsmåde<br />
Først bliver d<strong>at</strong>aene, som er indtastet i de anvendte applik<strong>at</strong>ioner, kontrolleret, ved <strong>at</strong> se om de<br />
stemmer overens med d<strong>at</strong>aene som er eksporteret fra applik<strong>at</strong>ionen. Disse findes i Solibri.<br />
D<strong>at</strong>aene bliver sammenlignet og der <strong>for</strong>etages en udregning på afvigelserne, som er defineret i<br />
kontrolmodellen i <strong>for</strong>hold til eksportmodellen. Afvigelsen er opgivet i %. D<strong>at</strong>aene som bliver <strong>hente</strong>t<br />
ud fra IFC modellen, som er listet op i d<strong>at</strong>abladet, bliver sammenholdt med beregnet kontrold<strong>at</strong>a.<br />
Udregninger ses i Bilag 1.<br />
Gennem <strong>for</strong>søget ses, hvordan geometrien bliver <strong>for</strong>tolket af de 3 anvendte pl<strong>at</strong><strong>for</strong>me. Forsøget<br />
gennemgår tre steps:<br />
Step 1.<br />
… er <strong>at</strong> modellere modellen, i hver enkelt applik<strong>at</strong>ion, efter ovenstående in<strong>for</strong>m<strong>at</strong>ioner.<br />
Step 2<br />
… er <strong>at</strong> eksportere modellen til IFC <strong>for</strong>m<strong>at</strong>et.<br />
Step 3<br />
… er bearbejdelsen af result<strong>at</strong>et.
Result<strong>at</strong> af <strong>for</strong>søgene – visuelt:<br />
Revit Architecture<br />
2012<br />
Graphisoft<br />
Archicad 14<br />
Vico Constructor<br />
8<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
D<strong>at</strong>amodellen i oprindeligt miljø D<strong>at</strong>amodellen eksporteret til IFC<br />
Figur 23 - Viser det grafiske result<strong>at</strong>, før og efter eksporten til IFC.<br />
69
20. december<br />
2011<br />
70<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
D<strong>at</strong>ablad <strong>for</strong> result<strong>at</strong>er ved <strong>for</strong>søg:<br />
Generisk væg. (sort):<br />
- Top Elev<strong>at</strong>ion:<br />
- Bottom Elev<strong>at</strong>ion:<br />
- Geometry:<br />
- Area:<br />
- Area windows:<br />
- Height:<br />
- Thickness:<br />
- Volume:<br />
Generisk gulv (grøn):<br />
- Top Elev<strong>at</strong>ion:<br />
- Bottom Elev<strong>at</strong>ion:<br />
- Area:<br />
- Thickness:<br />
Vindue (brun):<br />
- Top Elev<strong>at</strong>ion:<br />
- Bottom Elev<strong>at</strong>ion:<br />
- Area:<br />
- Height:<br />
- Width:<br />
Dør (pink):<br />
- Top Elev<strong>at</strong>ion:<br />
- Bottom Elev<strong>at</strong>ion:<br />
- Area:<br />
- Height:<br />
- Width:<br />
Cirkulær søjle (grå):<br />
- Type:<br />
- Radius:<br />
- Length:<br />
- Skin area:<br />
- Volume:<br />
- Geometry:<br />
Revit 2012 Archicad 14 Vico Constructor 8 Kontrol<br />
3000 mm.<br />
0 mm.<br />
Extrusion<br />
143,45 m2<br />
1.01 m2<br />
3000 mm.<br />
300 mm<br />
43,03 m3<br />
300 mm.<br />
0 mm.<br />
67.68 m2<br />
300 mm.<br />
1810 mm.<br />
900 mm.<br />
1.01 m2<br />
912 mm.<br />
1110 mm.<br />
2112 mm.<br />
0 mm.<br />
1,93 m2<br />
2112 mm.<br />
912 mm.<br />
Circle Profile<br />
150 mm.<br />
3000 mm.<br />
2.83 m2<br />
0,21 m3<br />
Extrusion<br />
Tabel 6 – Viser result<strong>at</strong>erne af <strong>for</strong>søgene.<br />
+ / ÷<br />
0 %<br />
0 %<br />
3,5 %<br />
0 %<br />
0 %<br />
0 %<br />
0,02 %<br />
100 %<br />
100 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
3000 mm.<br />
0 mm.<br />
Extrusion<br />
147,05 m2<br />
1,01 m2<br />
3000 mm.<br />
300 mm<br />
43,03 m3<br />
0 mm.<br />
-300 mm.<br />
67,68 m2<br />
300 mm.<br />
1810 mm.<br />
900 mm.<br />
1,01 m2<br />
912 mm.<br />
1110 mm.<br />
2150 mm.<br />
0 mm.<br />
1,96 m2<br />
2150 mm.<br />
912 mm.<br />
Circle Prof.<br />
150 mm.<br />
3000 mm.<br />
2,83 m2<br />
0,21 m3<br />
Extrusion<br />
+ / ÷<br />
0 %<br />
0 %<br />
0,001 %<br />
0 %<br />
0 %<br />
0 %<br />
0,02 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
1,8 %<br />
0 %<br />
1,54 %<br />
1,77 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
3000 mm.<br />
0 mm.<br />
Extrusion<br />
147,05 m2<br />
1,01 m2<br />
3000 mm.<br />
300 mm<br />
43,57 m3<br />
0 mm.<br />
-300 mm.<br />
69,09 m2<br />
300 mm.<br />
1810 mm.<br />
900 mm.<br />
1,01 m2<br />
912 mm.<br />
1110 mm.<br />
2110 mm.<br />
0 mm.<br />
1,93 m2<br />
2110 mm.<br />
912 mm.<br />
Circle Prof.<br />
150 mm.<br />
3000 mm.<br />
2,83 m2<br />
0,21 m3<br />
Extrusion<br />
+ / ÷<br />
0 %<br />
0 %<br />
0,001<br />
0%<br />
0 %<br />
0 %<br />
1,23 %<br />
0 %<br />
0 %<br />
2,08%<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
0 %<br />
3000 mm.<br />
0 mm.<br />
147,06 m2<br />
1,01 m2<br />
3000 mm.<br />
300 mm<br />
43,04 m3<br />
0 mm.<br />
-300 mm.<br />
67,68 m2<br />
300 mm.<br />
1810 mm.<br />
900 mm.<br />
1,01 m2<br />
912 mm.<br />
1110 mm.<br />
2112 mm.<br />
0 mm.<br />
1,93 m2<br />
2112 mm.<br />
912 mm.<br />
150 mm.<br />
3000 mm.<br />
2,83 m2<br />
0,21 m3
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
Result<strong>at</strong>er<br />
Revit v. 12 (Autodesk)<br />
Visuelt er det tydligt, <strong>at</strong> der er sket en ændring fra vores Revit model, til IFC eksporten. Dækket er<br />
blevet flyttet i både X, Y og Z retningen. Geometrien på dækket, ses som uændret. Derudover ses<br />
det, <strong>at</strong> vægelementerne ikke har den korrekte ”Area”. Der er en afvigelse på 3,5%.<br />
Archicad v. 14 (Graphisoft)<br />
Visuelt er den eneste <strong>for</strong>skel, <strong>at</strong> der mangler en dør på IFC eksporten. Enkelte af de øvrige geometrier<br />
er ændret.<br />
D<strong>at</strong>abladet viser en afvigelse i <strong>for</strong>hold til d<strong>at</strong>aene på døren. Her er det parametrene Area og<br />
Height, der afviger. Derimod ses der næsten ingen afvigelse på vægarealet.<br />
En af <strong>for</strong>delene ved Archicads IFC eksport er, <strong>at</strong> man kan eksportere d<strong>at</strong>aene til en specifik modtagersoftware,<br />
som f.eks. Revit. Denne mulighed kan minimere fejl ved eksport til andre applik<strong>at</strong>ioner.<br />
Vico Constructor 8<br />
Med Vico Constructor 8, er der meget få fejl ved eksporten. Det eneste Vico Constructor har problemer<br />
med, er udregningen af væggenes volumen og arealet på gulvene.<br />
Sammenf<strong>at</strong>ning<br />
Både ud fra d<strong>at</strong>ene, og det visuelle, kan man se <strong>at</strong> selv en rel<strong>at</strong>iv simpel model, som skal eksporteres<br />
til IFC, kan give problemer.<br />
Programmernes præst<strong>at</strong>ioner varierede, der var afvigelser ved alle programmerne.<br />
Værst var Autodesk Revit, hvor dækelementet flyttede sig fra sin oprindelige placering, til uden<strong>for</strong><br />
modellen.<br />
Sådanne fejl får brugeren til <strong>at</strong> miste tilliden til IFC. Hvilket er meget uhensigtsmæssigt da det er<br />
softwareudviklerne der har ansvaret <strong>for</strong> <strong>at</strong> implementere IFC import/eksport korrekt.<br />
Dette bliver <strong>for</strong>håbentlig løst gennem den nye certificering ” IFC Certific<strong>at</strong>ion 2.0”.<br />
71
20. december<br />
2011<br />
72<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
6 Hvordan bliver vi bedre<br />
6.1 Problemstilling<br />
I dette afsnit vil vi <strong>for</strong>søge <strong>at</strong> give et bud på hvor<strong>for</strong> BuildingSMARTs værktøjer – og anvendelsen<br />
af BIM i det hele taget - ikke er mere udbredt end tilfældet er i dag. Vi vil <strong>for</strong>søge <strong>at</strong> identificere de<br />
ud<strong>for</strong>dringer som knytter sig <strong>her</strong>til, samt mulige løsninger.<br />
6.2 Analyse<br />
BuildingSMART har, som tidligere beskrevet, udviklet standarder og værktøjer til <strong>at</strong> effektivisere<br />
udvekslingsprocesser og samarbejdet mellem byggeriets parter. Det er en klar holdning i branchen<br />
<strong>at</strong> der ligger et stort u<strong>for</strong>løst potentiale i anvendelsen af disse værktøjer, om end den praktiske<br />
erfaring hos byggeriets parter er meget begrænset. Vi har <strong>for</strong>søgt <strong>at</strong> identificere årsagen til<br />
problemet og mener <strong>at</strong> det bunder i kompleksiteten og den manglende fælles <strong>for</strong>ståelse <strong>for</strong> brugen<br />
af værktøjerne. En mulig løsning kunne være <strong>at</strong> udvikle en applik<strong>at</strong>ion som kan strukturere og<br />
effektivisere dele af den nuværende arbejdsproces omkring brugen af værtøjer som IDM, ER og<br />
Process Maps.<br />
6.2.1 Koncept<br />
Konceptet <strong>for</strong> vores applik<strong>at</strong>ion er udviklet på baggrund af nedenstående Brianstorm, Figur 24.<br />
Intentionen er <strong>at</strong> inddrage så mange værktøjer som muligt, uden <strong>at</strong> gå på kompromis med brugervenligheden,<br />
således applik<strong>at</strong>ionen altid hjælper brugeren med <strong>at</strong> bevare overblikket.<br />
Opbygningen i templ<strong>at</strong>es <strong>for</strong> ER og Process Maps er ikke videre intuitiv. Ved <strong>at</strong> strukturere inputs i<br />
drop-down menuer o.lign. kan mulighederne anskueliggøres samtidig med <strong>at</strong> fejlmarginen reduceres.<br />
Applik<strong>at</strong>ionens GUI tilpasser sig omstændighederne <strong>for</strong> det pågældende arbejde og beder<br />
således kun om oplysninger som er relevante. Desuden er det meningen <strong>at</strong> samme oplysninger<br />
kan blive anvendt af applik<strong>at</strong>ionen til <strong>at</strong> genere flere <strong>for</strong>skellige outputs, såsom ER og Process<br />
Maps, så processen effektiviseres og man undgår dobbeltindtastninger.<br />
Figur 24 - Viser en brainstorm over processen.
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
Applik<strong>at</strong>ionen er bygget op omkring en rel<strong>at</strong>ionel d<strong>at</strong>abase, som udvides efter behov. Da branchen<br />
befinder sig på vidt <strong>for</strong>skellige niveauer i <strong>for</strong>hold til implementering af BIM i virksomheden,<br />
<strong>for</strong>søger vi ikke <strong>at</strong> låse os fast på BuildingSMARTs værktøjer, som det endegyldige svar. Derimod<br />
er applik<strong>at</strong>ionen bygget op omkring ideologien fra IDM, som anvendes på et generelt niveau. Vi<br />
har brugt iai.no’s arbejde med IDM. De har lavet skabeloner som vi har brugt som udgangspunkt<br />
over hvilke in<strong>for</strong>m<strong>at</strong>ioner vores applik<strong>at</strong>ion indeholder (se bilag 2).<br />
Forløbet fremgår af Figur 25.<br />
Figur 25 - Viser process flow.<br />
6.2.2 Opbygning<br />
Konceptet <strong>for</strong> vores applik<strong>at</strong>ion er udviklet gennem et usecase-diagram og et aktivitets-diagram,<br />
som viser funktionalitet og struktur i applik<strong>at</strong>ionen. Derudover indeholder løsningen en rel<strong>at</strong>ionel<br />
d<strong>at</strong>abasestruktur lavet i Microsoft Access. Dette kan videreføres til et navig<strong>at</strong>ionsdiagram.<br />
I navig<strong>at</strong>ionsdiagrammet ses navig<strong>at</strong>ionsstrukturen, som er lavet <strong>for</strong> <strong>at</strong> give et overblik over brugerens<br />
mulige bevægerum i applik<strong>at</strong>ionen, altså de områder brugeren interagerer med.<br />
BPMN – Process Map<br />
En område som ikke beskrives med vores diagrammer, er ønsket om <strong>at</strong> implementerer en delvist<br />
autogenereret Process Map. Process Mapen skulle genereres ud fra de in<strong>for</strong>m<strong>at</strong>ioner som er indtastet<br />
i applik<strong>at</strong>ionen. Det er f.eks. in<strong>for</strong>m<strong>at</strong>ioner omkring udbuds<strong>for</strong>m, tidspunkter og faser som<br />
påvirker hvor selve udvekslingskravene (ER) skal ligge, virksomhederne imellem. Det er så meningen<br />
<strong>at</strong> koordin<strong>at</strong>orfunktion skal tilpasse de autogenerede Process Maps, så de kan sendes ud til<br />
de pågældende virksomheder. Selve ideen bag denne funktion, har vi ikke fokuseret på i denne<br />
rapport.<br />
73
20. december<br />
2011<br />
74<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
6.2.2.1 UML usecase-diagram<br />
Usecase-diagrammet illustrerer de oplysninger visuelt, som skal være tilgængelig <strong>for</strong> brugerne<br />
(supportaktør) og koordin<strong>at</strong>oren (primæraktør). Usecases beskriver funktionen der finder sted<br />
mellem aktørerne og applik<strong>at</strong>ionen. Rel<strong>at</strong>ionerne mellem en given aktør og applik<strong>at</strong>ionen repræsenteres<br />
med streger. I figur 13 ser vi <strong>at</strong> koordin<strong>at</strong>oren har flere rel<strong>at</strong>ioner end brugeren, såsom<br />
<strong>at</strong> varetage applik<strong>at</strong>ionernes fejlmeldinger og lign..<br />
Diagram 13 - Viser Usecase-diagram<br />
Bruger og systemkoordin<strong>at</strong>orrollen<br />
Vi har valgt, iht. vores use-case, <strong>at</strong> have en koordin<strong>at</strong>orrolle som skal varetage brugerens adfærd i<br />
applik<strong>at</strong>ionen. Koordin<strong>at</strong>orens hovedopgave er <strong>at</strong> vedligeholde systemet og dets d<strong>at</strong>a, <strong>for</strong> <strong>at</strong> sikre<br />
konsistens og præcision. Koordin<strong>at</strong>oren vil også have den funktion, <strong>at</strong> tilpasse det autogenerede<br />
m<strong>at</strong>eriale som kan eksporteres, hvis applik<strong>at</strong>ionen ikke selv er i stand til <strong>at</strong> gøre det. Dette kunne<br />
f.eks. være et Process Map.
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
6.2.2.2 UML aktivitets-diagram<br />
Aktivitets-diagrammet, viser brugerens vej og muligheder gennem systemet. Diagrammet består<br />
af startpunkt, aktiviteter, rel<strong>at</strong>ionerne mellem disse og et slutpunkt. Gennem <strong>for</strong>løbet, bliver der<br />
s<strong>at</strong> parametre op <strong>for</strong> altern<strong>at</strong>ive veje.<br />
En bruger skal oprette et udvekslingskrav.<br />
Dette gøres ved <strong>at</strong> logge<br />
ind på den udviklede GUI.<br />
Virksomhedsd<strong>at</strong>a indtastes (hvis<br />
de ikke allerede ligger i d<strong>at</strong>abasen).<br />
Brugeroplysninger indtastes. (hvis<br />
de ikke allerede ligger i d<strong>at</strong>abasen).<br />
Fase <strong>for</strong> in<strong>for</strong>m<strong>at</strong>ionsudveksling<br />
vælges.<br />
Proces tjekkes af koordin<strong>at</strong>or og<br />
skabelon udvælges eller tilpasses.<br />
In<strong>for</strong>m<strong>at</strong>ionskrav (udvekslingskrav)<br />
indtastes i GUI.<br />
In<strong>for</strong>m<strong>at</strong>ionskrav (udvekslingskrav)<br />
gemmes.<br />
Alle in<strong>for</strong>m<strong>at</strong>ioner gemmes.<br />
Der uploades til server.<br />
Output type vælges.<br />
Diagram 14 - Viser Usecase-diagrammet<br />
75
20. december<br />
2011<br />
76<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
6.2.3 D<strong>at</strong>abasen<br />
D<strong>at</strong>abasestrukturen er lavet på baggrund af førnævnte analyser, og viser hvordan vi har valgt <strong>at</strong><br />
lagre in<strong>for</strong>m<strong>at</strong>ionerne i et projekt. Alle indtastede in<strong>for</strong>m<strong>at</strong>ioner overføres til d<strong>at</strong>abasen og er<br />
der<strong>for</strong> omdrejningspunktet <strong>for</strong> vores applik<strong>at</strong>ion. Reglerne <strong>for</strong> udvekslingskrav (ER) i d<strong>at</strong>abasen, er<br />
opbygget på baggrund af IAI Norges ER. Kravene er dog ikke udelukkende hængt op på IFC.<br />
Figur 26 - Viser d<strong>at</strong>abaseopbygning til applik<strong>at</strong>ion.
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
6.2.4 Navig<strong>at</strong>ionsdiagrammet<br />
På baggrund af vores tidligere analyser, har vi valgt <strong>at</strong> kortlægge vores applik<strong>at</strong>ion med en oversigt<br />
over brugerens berøringsflader. Vores navig<strong>at</strong>ionsdiagram viser de <strong>for</strong>skellige vinduer, hvori<br />
der ligger nogle muligheder <strong>for</strong> brugeren, <strong>for</strong> <strong>at</strong> kunne indtaste in<strong>for</strong>m<strong>at</strong>ioner. Et eksempel på<br />
dette kunne være i vinduet ”Bruger”. I dette vindue skal brugeren have mulighed <strong>for</strong> <strong>at</strong> indtaste<br />
<strong>for</strong>navn, efternavn og vælge hvilken virksomhed han/hun tilhører. Udover det kan han/hun indtaste<br />
mobil og/eller telefonnummer samt mail.<br />
Alle områder er baseret på den d<strong>at</strong>abasestruktur som vi tidligere skabte med MS Access, hvori<br />
d<strong>at</strong>astrukturen vises. Vi har ikke beskrevet skabelondelen, men den er ment som en del, hvori<br />
virksomhederne kan vælge en skabelon til udveksling af in<strong>for</strong>m<strong>at</strong>ioner, til en anden virksomhed.<br />
Et eksempel på dette kunne være, <strong>at</strong> en arkitektvirksomhed ofte arbejder sammen med en entreprenørvirksomhed<br />
som vil have sine in<strong>for</strong>m<strong>at</strong>ioner på en bestemt måde. Når der så vælges skabelon<br />
<strong>for</strong> et samarbejde mellem virksomhederne, er der på <strong>for</strong>hånd lavet nogle ”standard” udvekslingskrav.<br />
Men da to byggesager aldrig er ens, vil man blive nød til <strong>at</strong> ændre områder i skabelonen.<br />
Dette afhjælper og minimere gentagelser i arbejdsprocessen.<br />
Diagram 15 viser navig<strong>at</strong>ionsdiagram<br />
77
20. december<br />
2011<br />
78<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
6.2.5 Grafisk brugerflade (GUI)<br />
Måden brugerne interagerer med brugerfladen, har stor betydning <strong>for</strong> <strong>at</strong> skabe det rette flow i<br />
hverdagen. I denne fase af udviklingen er der primært fokuseret på en enkelt og ukompliceret<br />
brugerflade. Des mere overskuelig en brugerflade er, jo lavere er læringskurven <strong>for</strong> brugeren.<br />
Brugeren vil også have lettere og større lyst til <strong>at</strong> bruge applik<strong>at</strong>ionen fremover. Til udarbejdelse<br />
af brugerfladen har vi benyttet Netbeans, som er et anerkendt softwareudviklingsprogram.<br />
Dialogboksen: In<strong>for</strong>m<strong>at</strong>ionskrav<br />
Det nedenstående billede viser dialogboksen med in<strong>for</strong>m<strong>at</strong>ionskrav. Dette er en væsentlig dialogboks<br />
hvor man kan oprette og ændre i de in<strong>for</strong>m<strong>at</strong>ionskrav som fremsættes af brugeren.<br />
Titel<br />
I feltet Titel indtaster man in<strong>for</strong>m<strong>at</strong>ionskravets<br />
titel.<br />
Brugerflade 1 - viser GUI over in<strong>for</strong>m<strong>at</strong>ionskrav<br />
Form<strong>at</strong> / Form<strong>at</strong> version<br />
I feltet Form<strong>at</strong> og <strong>for</strong>m<strong>at</strong> version<br />
definerer man det <strong>for</strong>m<strong>at</strong><br />
som man vil have sit in<strong>for</strong>m<strong>at</strong>ionskrav<br />
i.<br />
Oblig<strong>at</strong>orisk, Anbefalet og Valgfri<br />
Feltet angiver in<strong>for</strong>m<strong>at</strong>ionskravets<br />
vigtighed.<br />
Ansvarlig virksomhed / afsender og In<strong>for</strong>m<strong>at</strong>ionskravsmodtager<br />
samt den ansvarshavende modtager er felter som viser afsender og<br />
modtager af in<strong>for</strong>m<strong>at</strong>ionskravet.<br />
Type af in<strong>for</strong>m<strong>at</strong>ion<br />
Feltet <strong>for</strong>tæller om det er et byg<strong>her</strong>rekrav<br />
iht. placeringen eller lign. beskrivelse<br />
af in<strong>for</strong>m<strong>at</strong>ion <strong>for</strong>tæller om<br />
selve in<strong>for</strong>m<strong>at</strong>ionen.<br />
Kalenderfunktioner<br />
Kalenderne angiver d<strong>at</strong>oer <strong>for</strong><br />
aflevering af in<strong>for</strong>m<strong>at</strong>ionen, og<br />
påmindelse. Det bliver der gjort<br />
opmærksom på via. sine afkrydsninger<br />
iht. Mail eller SMS notifik<strong>at</strong>ion.
6.2.6 Dialogboksen: Bruger<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
Dialogboksen ”Bruger” benyttes af alle (udvalgte) aktører på projektet og skal udfyldes <strong>for</strong> <strong>at</strong> tilgå<br />
applik<strong>at</strong>ionens øvrige funktioner. Brugerinterfacet er opbygget som følgende:<br />
Brugerflade 2 - viser GUI over bruger<br />
Bruger feltet<br />
Henvender sig til eksisterende brugere. Har<br />
man indtastet sine brugeroplysninger tidligere<br />
i <strong>for</strong>løbet, kan de findes under dropdown<br />
menuen. Hvorefter felterne udfyldes<br />
autom<strong>at</strong>isk.<br />
Oplysningsfelterne<br />
Fornavn, Efternavn, mobilnummer, telefonnummer<br />
og mail skal manuelt udfyldes med<br />
persond<strong>at</strong>a (medmindre d<strong>at</strong>aene kan findes<br />
i førnævnte ”Bruger felt”)<br />
79
20. december<br />
2011<br />
80<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
6.2.7 Dialogboksen: In<strong>for</strong>m<strong>at</strong>ionskravsoversigt<br />
Dialogboksen ”In<strong>for</strong>m<strong>at</strong>ionskravsoversigt” kan give en oversigt af projektets skabeloner, virksomheder,<br />
brugere, faser og sager.<br />
Brugerflade 3 - viser GUI over in<strong>for</strong>m<strong>at</strong>ionskravsoversigt<br />
Liste over in<strong>for</strong>m<strong>at</strong>ionskrav<br />
Via knappen tilgås en liste over projektets in<strong>for</strong>m<strong>at</strong>ionskrav.<br />
Indtast in<strong>for</strong>m<strong>at</strong>ionskrav<br />
Via knappen kan oprette nye in<strong>for</strong>m<strong>at</strong>ionskrav. Se GUI<br />
In<strong>for</strong>m<strong>at</strong>ionskrav.<br />
Eksport<br />
Via knappen kan valgte in<strong>for</strong>m<strong>at</strong>ioner eksporteres<br />
Ny sag<br />
Via knappen kan man vælge <strong>at</strong> oprette en ny projektsag.<br />
Gem sag<br />
Via knappen kan man gemme sin projektsag.<br />
6.3 Sammenf<strong>at</strong>ning<br />
Upload til server<br />
Via knappen kan man uploade til serveren.<br />
Vælg skabelon<br />
Eksisterende skabeloner findes i drop-down<br />
menuen. Valgte skabeloner kan tilgås via ”Rediger”<br />
knappen <strong>for</strong> tilføjelser / ændringer.<br />
Virksomheder<br />
Eksisterende virksomheder findes i drop-down<br />
menuen. Valgte virksomheder kan tilgås via<br />
”Rediger” knappen <strong>for</strong> tilføjelser / ændringer.<br />
Brugere<br />
Eksisterende brugere findes i drop-down menuen.<br />
Valgte brugere kan tilgås via ”Rediger” knappen<br />
<strong>for</strong> tilføjelser / ændringer.<br />
Faser<br />
Eksisterende faser findes i drop-down menuen.<br />
Valgte faser kan tilgås via ”Rediger” knappen <strong>for</strong><br />
tilføjelser / ændringer.<br />
Sag<br />
Eksisterende sager findes i drop-down menuen.<br />
Valgte sager kan tilgås via ”Rediger” knappen <strong>for</strong><br />
tilføjelser / ændringer.<br />
Brug af GUIer<br />
Disse prototyper af brugergrænsefladen, skal bruges som et redskab til tests og evaluering, til<br />
videre udvikling af programmet. Disse giver testpersonerne mulighed <strong>for</strong> <strong>at</strong> kunne interagere med<br />
programmet på en fiktiv måde, som kan give nyttig feedback til <strong>at</strong> <strong>for</strong>bedre programmet.<br />
Vi stopper udviklingen <strong>her</strong>, og lader det <strong>for</strong>blive en konceptuel model.
7 Konklusion<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
Result<strong>at</strong>et af nutidens mange softwareværktøjer, <strong>for</strong>m<strong>at</strong>er, processer osv., samt det faktum <strong>at</strong> to<br />
projekter aldrig er ens, skaber kaos, <strong>for</strong>virring og frustr<strong>at</strong>ioner i branchen, når in<strong>for</strong>m<strong>at</strong>ioner skal<br />
udveksles. Udviklingen af digitale værktøjer er gået hurtigt de seneste år og har måske overhalet<br />
mange virksomheder indenom. Mange virksomheder har i dag flere <strong>for</strong>skellige BIM-værktøjer i<br />
brug under et projekt<strong>for</strong>løb, som ikke er komp<strong>at</strong>ible på et tilfredsstillende niveau.<br />
”It-systemer, der ikke kan tale sammen, er årsag til fejl, <strong>for</strong>sinkelser og dobbeltarbejde<br />
<strong>for</strong> milliarder af kroner i byggebranchen hvert år” (Ingeniøren, 2008)<br />
Dette leder os hen til vores initierende problemstilling; ”Hvordan skaber man en optimal udvekslingsproces<br />
i et modelbaseret miljø?”<br />
Efter vores overbevisning er der to <strong>for</strong>skellige måder <strong>at</strong> anskue dette spørgsmål på. Den første<br />
tager udgangspunkt i verden som den ser ud i dag, <strong>her</strong>under de teknologiske <strong>for</strong>hold, samarbejds<strong>for</strong>mer<br />
og ikke mindst motiv<strong>at</strong>ion og handlekraft – eller mangel på samme. Det fulde udbytte ved<br />
implementering af BIM opnås først når alle parter er involveret på samme høje niveau, og så længe<br />
der ikke findes en åbenlys gevinst <strong>for</strong> hver enkelt part, vil det være svært <strong>at</strong> gennemføre.<br />
Gennem interviews med diverse interessenter, samt praktiske erfaringer opnået i gruppen, er det<br />
blevet tydeliggjort hvordan udvekslinger i IFC <strong>for</strong>m<strong>at</strong>et mellem BIM applik<strong>at</strong>ioner, ofte medfører<br />
fejl og geometriske unøjagtigheder. Netop <strong>for</strong>holdet <strong>at</strong> kunne stole fuldt ud på d<strong>at</strong>amodellen er af<br />
afgørende betydning <strong>for</strong> en gnidningsfri udveksling og i den <strong>for</strong>bindelse ligger problemet hos<br />
softwarebranchen.<br />
Den anden anskuelse er, <strong>at</strong> der faktisk findes nogle værktøjer, som tillader parterne <strong>at</strong> planlægge<br />
og kommunikere sig til et bedre udgangspunkt <strong>for</strong> udveksling af in<strong>for</strong>m<strong>at</strong>ion. Her tænkes først og<br />
fremmest på BuildingSMARTs IFD og IDM metoder. IFC <strong>for</strong>m<strong>at</strong>et og de tilhørende værtøjer fra<br />
BuildingSMART er måske ikke den optimale løsning i alle situ<strong>at</strong>ioner, men vi ser kvaliteter i hver<br />
enkelt del, og mener der<strong>for</strong> også <strong>at</strong> der kan være gevinster i bare <strong>at</strong> anvende dele af værktøjerne,<br />
og dermed starte en gradvis implementering af ideologien bag BuildingSMART.<br />
For <strong>at</strong> illustrere mulighederne i disse værktøjer, har vi udviklet en konceptuel applik<strong>at</strong>ion som<br />
tager det bedste fra IDM og udvider værktøjerne til en generel anvendelse, som samtidig ikke er<br />
låst til IFC <strong>for</strong>m<strong>at</strong>et.<br />
81
20. december<br />
2011<br />
8 Perspektivering<br />
82<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Kortsigtet (1-5 år)<br />
På kort sigt vurderer vi, <strong>at</strong> man vil løse komp<strong>at</strong>ibilitetsproblemerne mellem applik<strong>at</strong>ioner gennem<br />
udvikling af API’er til udveksling af d<strong>at</strong>a. Autodesk har eksempelvis netop frigivet kildekoden til<br />
deres IFC-exporter, hvilket tillader tredjepartsudviklere <strong>at</strong> anvende koden i skræddersyede API’er<br />
til d<strong>at</strong>audveksling med et specifikt <strong>for</strong>mål <strong>for</strong> øje. På den måde trækker man d<strong>at</strong>a ud efter samme<br />
princip som MVD, hvor kun in<strong>for</strong>m<strong>at</strong>ioner som er relevante i den pågældende udveksling berøres.<br />
Papir<strong>for</strong>m<strong>at</strong>et som in<strong>for</strong>m<strong>at</strong>ionsudveksling er under alle omstændigheder på vej tilbage. I det hele<br />
taget er en st<strong>at</strong>isk d<strong>at</strong>arepræsent<strong>at</strong>ion ikke egnet til de store in<strong>for</strong>m<strong>at</strong>ionsmængder en bygningsmodel<br />
indeholder i dag. Et godt eksempel på det er Pihl & søns jernbane broprojekt i Göteborg,<br />
hvor de har eksporteret deres armering direkte fra programmet Tekla til stålproducenten.<br />
”Armeringen eksporteres dermed direkte til Celsa, som kan <strong>for</strong>dele in<strong>for</strong>m<strong>at</strong>ioner vedrørende armeringen<br />
til virksomhedens robotter, som så klipper og bukker armeringen. Den klassiske klippebukke<br />
er <strong>for</strong>tid, og armeringen produceres nu med millimeters nøjagtighed.”<br />
(http://www.byggeteknik.<strong>dk</strong>/artikel?id=66412)<br />
Langsigtet (5+ år)<br />
På lang sigt <strong>for</strong>udser vi en markant større udbredelse af IFC som bærende in<strong>for</strong>m<strong>at</strong>ionsudvekslings<strong>for</strong>m<strong>at</strong>,<br />
sammen med resten af værktøjerne fra BuildingSMART. Håndtering af IFC imellem<br />
applik<strong>at</strong>ioner kan nemt blive en større konkurrenceparameter i fremtiden, og dermed tvinge<br />
softwareleverandørerne til <strong>at</strong> udvise større engagement over<strong>for</strong> udnyttelsen af IFC som fælles<br />
standard. Den konstante eskalering i udviklingen af ny teknologi giver desuden anledning til nye<br />
og mere dynamiske samarbejds<strong>for</strong>mer, hvor adgangen til in<strong>for</strong>m<strong>at</strong>ioner tillader et tættere samarbejde<br />
mellem sagens parter.<br />
Udvekslingen af tegninger og d<strong>at</strong>a sker i dag ofte gennem projektweb eller andre serverløsninger.<br />
Fordelene ved altid <strong>at</strong> have opd<strong>at</strong>erede in<strong>for</strong>m<strong>at</strong>ioner vil sandsynligvis blive mere udnyttet i fremtidens<br />
BIM applik<strong>at</strong>ioner, hvilket også udnyttes bedre i mere dynamiske samarbejds<strong>for</strong>mer.<br />
På byggepladsen skal de udførende desuden vende sig til <strong>at</strong> anvende in<strong>for</strong>m<strong>at</strong>ionerne i bygningsmodellen<br />
på en helt ny måde, som bl.a. inkluderer 3d visualisering samt sporing af byggem<strong>at</strong>erialer<br />
og m<strong>at</strong>eriel. I den optimale proces, vil der også være feedback til modellen fra de udførende<br />
på pladsen. Modellen vil altså i endnu højere grad være centrum <strong>for</strong> kommunik<strong>at</strong>ionen mellem<br />
sagens parter.
9 Kildeliste<br />
Internet kilder:<br />
www.niras.<strong>dk</strong><br />
Hentet den 3. Oktober 2011<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
http://buildingsmart-tech.org/specific<strong>at</strong>ions/IFC-view-definition/coordin<strong>at</strong>ion-view-v2.0/summary<br />
Hentet den 6. November 2011<br />
http://www.friis-moltke.<strong>dk</strong>/siteFM/projectdetail.asp?x=&detail=2540<br />
Hentet den 5. November 2011<br />
http://www.taxon.<strong>dk</strong>/artikler/taxonomi.htm<br />
Hentet den 15. november 2011<br />
http://www.blis-project.org/IAI-MVD<br />
Hentet den 18. November 2011<br />
http://buildingsmart-tech.org/specific<strong>at</strong>ions/ifc-view-definition/summary<br />
Hentet den 18. November 2011<br />
http://buildingsmart.com/standards/mvd/mvd-process<br />
Hentet den 18. November 2011<br />
http://www.openifctools.org<br />
Hentet den 18. November 2011<br />
http://en.wikipedia.org/wiki/Entity-rel<strong>at</strong>ionship_model<br />
Hentet den 23. November 2011<br />
http://www.bpmn.org/<br />
Hentet den 18. November 2011<br />
http://www.bs.<strong>dk</strong>/publik<strong>at</strong>ioner/rapporter/webservice/html/chapter04.htm<br />
Hentet den 18. November 2011<br />
http://da.wikipedia.org/wiki/Serviceorienteret_arkitektur<br />
Hentet den 18. November 2011<br />
http://en.wikipedia.org/wiki/Business_Process_Model_and_Not<strong>at</strong>ion<br />
Hentet den 18. November 2011<br />
http://en.wikipedia.org/wiki/Business_Process_Execution_Language<br />
Hentet den 18. November 2011<br />
http://www.version2.<strong>dk</strong>/leksikon/BPMN<br />
Hentet den 18. November 2011<br />
http://www.kim-andersen.<strong>dk</strong>/d<strong>at</strong>abase normalisering/normalisering d<strong>at</strong>abase sql foerste normal<strong>for</strong>m.htm<br />
Hentet den 13. November 2011<br />
http://jesarbov.<strong>dk</strong>/mdu/semester3_09k/iau3_lekt02.html<br />
Hentede 26. oktober 2011<br />
www.asciitable.com<br />
Hentet den. 26. oktober 2011<br />
http://dev.ifd-library.org/images/2/23/IfcIfd1.png<br />
Hentet den 2. november 2011<br />
http://dev.ifd-library.org/index.php/Ifd:IFD_<strong>for</strong>_Innov<strong>at</strong>ive_Sustainable_Housing<br />
Hentet den 2. november 2011<br />
http://bips.<strong>dk</strong>/v%C3%A6rkt%C3%B8jsemne/buildingsmart-proces-idm<br />
Hentet den 24. oktober 2011<br />
83
20. december<br />
2011<br />
84<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
http://c<strong>at</strong>enda.no/index.php/2010/09/13/wh<strong>at</strong>-on-earth-is-ifd/<br />
Hentet den 6. november 2011<br />
http://buildingsmart-tech.org/specific<strong>at</strong>ions/ifc-overview<br />
Hentet den 24. oktober 2011<br />
http://www.buildingsmart.no/article126.html<br />
Hentet den 31. oktober 2011<br />
http://buildingsmart-tech.org/specific<strong>at</strong>ions/ifc-releases/ifc2x4-release<br />
Hentet den 31. oktober 2011<br />
http://www.cowi.<strong>dk</strong>/MENU/SERVICE/BYGGERI/BYGNINGSPROJEKTERING/BIM/Pages/BIMbygningsin<strong>for</strong>m<strong>at</strong>ionsmodellering.aspx<br />
Hentet den 04. november 2011<br />
http://www.detdigitalebyggeri.<strong>dk</strong>/sites/default/files/<strong>at</strong>tachments/Musikkens_hus_In<strong>for</strong>m<strong>at</strong>ionsfolder.p<br />
df<br />
Hentet den 04. november 2011<br />
http://projects.buildingsmartalliance.org/files/?artifact<br />
Hentet den 6. november 2011<br />
http://www.grontmij.<strong>dk</strong>/<strong>dk</strong>/ydelser/byggeri/design/bygnings%20in<strong>for</strong>m<strong>at</strong>ions%20Modellering/Pages/B<br />
ygningsIn<strong>for</strong>m<strong>at</strong>ionsModellering.aspx<br />
Hentet den 4. november 2011<br />
http://dtu20.be/ERdiagram.<strong>pdf</strong><br />
Hentet den 20. oktober 2011<br />
http://staff.iha.<strong>dk</strong>/foh/Foredrag/UML-Light-slides.<strong>pdf</strong><br />
Hentet den 13. november 2011<br />
http://docs.kde.org/<br />
Hentet den 17. oktober 2011<br />
http://da.wikipedia.org/wiki/UML<br />
Hentet den 14. november 2011 fra<br />
http://docs.kde.org/stable/da/kdes<strong>dk</strong>/umbrello/uml-basics.html<br />
Hentet den 31. oktober 2011<br />
http://office.microsoft.com/da-<strong>dk</strong>/visio-help/om-express-g-diagrammer-pa-enheds-og-skemaniveau-<br />
HP089600001.aspx?CTT=1<br />
Hentet den 31. oktober 2011<br />
http://www.omg.org/gettingstarted/wh<strong>at</strong>_is_uml.htm#12DiagramTypes<br />
Hentet den 31. november 2011<br />
http://www.oreas.com/shared_img/example_big_tree.gif<br />
Hentet den 13. november 2011<br />
http://www.emu.<strong>dk</strong>/gym/fag/dl/inspir<strong>at</strong>ion/temaer.html<br />
Hentet den 26. oktober 2011<br />
http://laerer.rhs.<strong>dk</strong>/psl/rhs/HHX.../Del%204%20-%20ER-diagrammer.ppt<br />
Hentet den 14. oktober 2011<br />
http://ing.<strong>dk</strong>/artikel/84747-byggeriet-spilder-milliarder-paa-elendig-udveksling-af-d<strong>at</strong>a<br />
Hentet den 4. november 2011<br />
http://ing.<strong>dk</strong>/artikel/84748-it-standard-til-byggeriet-skal-vaere-tvang<br />
Hentet den 4. november 2011<br />
http://standards.eu-innova.org/Files/Report/STAND-<br />
INN_D15_IFC_and_IFD_feasibility_<strong>for</strong>_innov<strong>at</strong>ive_sustainable_housing.<strong>pdf</strong><br />
Hentet den 04. november 2011
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
http://www.aecbytes.com/fe<strong>at</strong>ure/2004/IFCmodel.html<br />
Hentet den 1. november 2011<br />
http://www.ebst.<strong>dk</strong>/file/96241/Plan_<strong>for</strong>_videreudvikling_af_DBK_fra_DiKon.<strong>pdf</strong><br />
Hentet den 6. november 2011<br />
http://buildingsmart-tech.org/about-us/msg<br />
Hentet den 1. november 2011<br />
http://www.musikkenshus.<strong>dk</strong>/Pages/default.aspx<br />
Hentet den 5. november 2011<br />
www.niras.<strong>dk</strong>/Forretningsomraader/Byggeri/buildingSMART.aspx<br />
Hentet den 4. november 2011<br />
http://ing.<strong>dk</strong>/artikel/113967-et-vaerktoej-er-ikke-nok-til-<strong>at</strong>-bygge-med<br />
Hentet den 4. november 2011<br />
20. december<br />
2011<br />
http://cuneco.<strong>dk</strong>/nyhed/danmark-i-spidsen-revision-af-intern<strong>at</strong>ional-standard-byggeklassifik<strong>at</strong>ion-0<br />
Hentet den 18. november 2011<br />
http://st<strong>at</strong>sbygg.no/FoUprosjekter/BIM-Bygningsin<strong>for</strong>masjonsmodell/BIM-En-kortf<strong>at</strong>tetinn<strong>for</strong>ing/Forretningsprosesser/<br />
Hentet den 24. oktober 2011<br />
http://en.wikipedia.org/wiki/Industry_Found<strong>at</strong>ion_Classes<br />
Hentet den 11. november 2011<br />
www.idef.com<br />
Hentet den 29. oktober 2011<br />
Bøger, rapporter og tidsskrifter<br />
Bips. 2005, Bips nyt.<br />
Bips. 2004, 3 / 2004. Bips nyt, 15-16.<br />
2007, N<strong>at</strong>ional Builing In<strong>for</strong>m<strong>at</strong>ion Modeling Standard. N<strong>at</strong>ional Institute of Building Science.<br />
Chen, P. P.-S. 1976, The Entity-Rel<strong>at</strong>ionship Model - Toward a Unified View of D<strong>at</strong>a. Massachusetts<br />
Institute of Technology: ACM Transactions on D<strong>at</strong>abase Systems. Vol. 1,No. I,.<br />
Grant, R., & Mehus, J. 2009, IFD Library Business Plan - Version 1.0.<br />
Hansen, F. O. 2005, System<strong>at</strong>isk programudvikling med UML. System<strong>at</strong>isk programudvikling med UML.<br />
2010, Udviklingsplan <strong>for</strong> Dansk Bygge. Digital konvergens.<br />
Rasmussen, A. 1996, Introduktion til IDEF0. Institut <strong>for</strong> Anvendt Konstruktion og Produktion.<br />
Chuck Eastman. 2011, BIM Handbook<br />
85
20. december<br />
2011<br />
86<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
9.1 Billedhenvisninger<br />
Billeder Kilde:<br />
Billede 1: http://www.coop-himmelblau.<strong>at</strong>/<br />
Billede 2: http://www.nordjyske.<strong>dk</strong>/erhverv/<strong>for</strong>side.aspx?ctrl=10&d<strong>at</strong>a=4%2C3606284%2C2805%2C3<br />
Figure: Kilde:<br />
Figur 1: http://www.topboxdesign.com/tag/fonden-musikkens-hus/7<br />
Figur 2: http://en.wikipedia.org/wiki/Business_Process_Model_and_Not<strong>at</strong>ion<br />
Figur 3: http://en.wikipedia.org/wiki/Business_Process_Model_and_Not<strong>at</strong>ion<br />
Figur 4: http://en.wikipedia.org/wiki/Business_Process_Model_and_Not<strong>at</strong>ion<br />
Figur 5: http://en.wikipedia.org/wiki/Business_Process_Model_and_Not<strong>at</strong>ion<br />
Figur 6: Egen<br />
Figur 7: www.webs.twsu.edu/enteng/papers/howidef0.<strong>pdf</strong><br />
Figur 8: http://www.slideshare.net/koolkampus/ch02<br />
Figur 9: http://www.aecbytes.com/fe<strong>at</strong>ure/2004/IFC-images/fig2.html<br />
Figur 10: http://www.aecbytes.com/fe<strong>at</strong>ure/2004/IFCmodel.html<br />
Figur 11: ISO29481-1, 2010<br />
Figur 12: ISO29481-1, 2010<br />
Figur 13: ttp://www.iai.no/idm/idm_resources/idm_methods_guides/IDM2_Methodology_2007102<br />
2.<strong>pdf</strong><br />
Figur 14: ttp://www.iai.no/idm/idm_resources/idm_methods_guides/IDM2_Methodology_2007102<br />
2.<strong>pdf</strong><br />
Figur 15: http://it.civil.aau.<strong>dk</strong>/it/educ<strong>at</strong>ion/reports/building_smart/WS6_IDM_FunctionalParts.<strong>pdf</strong><br />
.<strong>pdf</strong><br />
Figur 16: http://ontolog.cim3.net/cgi-bin/wiki.pl?FloorplanMarkupLanguage<br />
Figur 17: http://buildingsmart.com/standards/mvd/mvd-process<br />
Figur 18: http://www.buildingsmart.no/intern<strong>at</strong>ional<br />
Figur 19: http://dev.ifd-library.org/index.php/Ifd:IFD_in_a_Nutshell<br />
Figur 20: http://www.google.<strong>dk</strong>/url?sa=t&rct=j&q=roger%20grant%20ifd&source=web&cd=1&ved=0<br />
CCkQFjAA&url=http%3A%2F%2Fprojects.buildingsmartalliance.org%2Ffiles%2F%3Fartifact_i<br />
d%3D1537&ei=fxrqTrT_L4r44QSamOnjCA&usg=AFQjCNEdzXynrcf310OD-<br />
0Z3dlxiS5netw&cad=rja<br />
Figur 21: http://www.google.<strong>dk</strong>/url?sa=t&rct=j&q=roger%20grant%20ifd&source=web&cd=1&ved=0<br />
CCkQFjAA&url=http%3A%2F%2Fprojects.buildingsmartalliance.org%2Ffiles%2F%3Fartifact_i<br />
d%3D1537&ei=fxrqTrT_L4r44QSamOnjCA&usg=AFQjCNEdzXynrcf310OD-<br />
0Z3dlxiS5netw&cad=rja<br />
Figur 22: Egen<br />
Figur 23: Egen<br />
Figur 24: Egen<br />
Figur 25: Egen<br />
Figur 26: Egen (d<strong>at</strong>abaseopbygning)<br />
Diagram: Kilde:<br />
Diagram 1: Egen<br />
Diagram 2: Egen
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
Diagram 3: Egen (E-Draw)<br />
Diagram 4: www.webs.twsu.edu/enteng/papers/howidef0.<strong>pdf</strong><br />
Diagram 5: Egen kilde (E-Draw)<br />
Diagram 6: http://www.jot.fm/issues/issue_2004_01/article3/images/fig2.gif<br />
Diagram 7: http://explainextended.com/2009/10/18/wh<strong>at</strong>-is-entity-rel<strong>at</strong>ionship-model/<br />
Diagram 8: http://buildingsmart-tech.org/certific<strong>at</strong>ion/IFC-certific<strong>at</strong>ion-2.0/IFC2x3-cv-v2.0-<br />
certific<strong>at</strong>ion/bSI_IFC_Certific<strong>at</strong>ion_2-0_Workflow.png/view<br />
Diagram 9: Egen<br />
Diagram 10: Egen<br />
Diagram 11: Egen<br />
Diagram 12: http://www.iai.no/idm/idm_resources/idm_methods_guides/IDM2_Methodology_200710<br />
22.<strong>pdf</strong><br />
Diagram 13: Egen<br />
Diagram 14: Egen<br />
Diagram 15: Egen (Navig<strong>at</strong>ionsdiagram)<br />
Model: Kilde:<br />
Model 1: http://buildingsmart-tech.org/specific<strong>at</strong>ions/IFC-view-definition/coordin<strong>at</strong>ion-view-<br />
v2.0/summary<br />
Model 2: Bimbyen<br />
Model 3: Bimbyen<br />
Tabel: Kilde:<br />
Tabel 1: http://www.blis-project.org/IAI-MVD/IDM/GSA-002/ER_GSA-002.<strong>pdf</strong><br />
Tabel 2: http://www.blis-project.org/IAI-MVD/IDM/GSA-002/ER_GSA-002.<strong>pdf</strong><br />
Tabel 3:<br />
http://idm.buildingsmart.no/confluence/display/IDM/Configure+Load+Bearing+System+%2<br />
8FP%29<br />
Tabel 4:<br />
http://idm.buildingsmart.no/confluence/display/IDM/Configure+Load+Bearing+System+%2<br />
8FP%29<br />
Tabel 5: http://idm.buildingsmart.no/confluence/display/IDM/Configure+Load+Bearing+System+%2<br />
8FP%29<br />
Tabel 6: egen<br />
Uddrag: Kilde:<br />
Uddrag 1: http://www.blis-project.org/IAI-MVD/IDM/GSA-002/ER_GSA-002.<strong>pdf</strong><br />
Uddrag 2: http://idm.buildingsmart.no/confluence/display/IDM/Configure+Load+Bearing+System+%2<br />
8FP%29<br />
Uddrag 3: http://idm.buildingsmart.no/confluence/display/IDM/Configure+Load+Bearing+System+%2<br />
8FP%29<br />
Uddrag 4 http://buildingsmart-tech.org/specific<strong>at</strong>ions/ifc-view-definition/summary<br />
Skemaer: Kilde:<br />
Skema 1: http://idm.buildingsmart.no/confluence/display/IDM/Configure+Load+Bearing+System+%2<br />
8FP%29<br />
87
20. december<br />
2011<br />
88<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Skemaer: Kilde:<br />
Brugerflade 1: Egen (GUI over in<strong>for</strong>m<strong>at</strong>ionskrav)<br />
Brugerflade 2: Egen (GUI over bruger)<br />
Brugerflade 3: Egen (GUI over in<strong>for</strong>m<strong>at</strong>ionskravsoversigt)
10 Ord<strong>for</strong>klaring<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
ORD FORKLARING<br />
Applic<strong>at</strong>ion Programming<br />
Interface (API)<br />
Softwaregrænseflade der tillader et stykke software <strong>at</strong> interagere<br />
med andet software.<br />
BLIS Building Lifecycle Interoperable Software<br />
BPEL SE AFSNIT 3.1.1<br />
BPMI Business Process Management Initi<strong>at</strong>ive, er en gruppe som<br />
varetager udviklingen og arbejdet med BPMN, blandt andet.<br />
BPML Business Process Markup Language, noterings sprog.<br />
C++ Programmeringssprog<br />
E-R Entity-Rel<strong>at</strong>ionship<br />
Entity / Entitet D<strong>at</strong>aset som indeholder <strong>at</strong>tributter<br />
ER Exchange Requirements<br />
EXPRESS Programmeringssprog<br />
Facility Management (FM) Drift og vedligehold<br />
Functional Parts SE AFSNIT 2.4.2<br />
IAI Intern<strong>at</strong>ional Alliance of Interoperability<br />
IDM In<strong>for</strong>m<strong>at</strong>ion Delivery Manual<br />
IFC Model Specific<strong>at</strong>ion<br />
IFC Binding IFC Binding indeholder ”agreements” <strong>for</strong> individuelle ”functional<br />
parts”/”concepts”<br />
IFC integr<strong>at</strong>ion Når et program indeholder IFC eksport/import<br />
IFD Intern<strong>at</strong>ional Framework <strong>for</strong> Dictionaries<br />
Koncepter (IFC) SE AFSNIT 3.2.2<br />
Metasprog Det underliggende sprog eller symboler som bruges til <strong>at</strong> beskrive<br />
et andet sprog<br />
Multiparadigm<strong>at</strong>isk programmeringssprog<br />
Process Maps SE AFSNIT 3.2.3.1<br />
ProIT<br />
20. december<br />
2011<br />
Renundant d<strong>at</strong>a Samme d<strong>at</strong>a optræder mere end et sted I en d<strong>at</strong>abase eller I et<br />
d<strong>at</strong>aset<br />
89
20. december<br />
2011<br />
90<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Schema/skema In<strong>for</strong>m<strong>at</strong>ionshåndtering i computersprog?<br />
STEP ISO 10303 standard. D<strong>at</strong>asprog til repræsent<strong>at</strong>ion og udvekling<br />
af produktin<strong>for</strong>m<strong>at</strong>ioner.<br />
WSBPEL SE AFSNIT 3.1.1<br />
Interoperabilitet Forskelligartede systemer eller organis<strong>at</strong>ioner er i stand til <strong>at</strong><br />
arbejde sammen. (inter-operere)<br />
In<strong>her</strong>itance Hierarchy Entiteter arver proporties fra entiteter højere i hierarkiet.<br />
Super Types Entiteter arver proporties fra entiteter højere i hierarkiet.<br />
DWG Binært fil<strong>for</strong>m<strong>at</strong> brugt af udviklet af Auto<br />
Ontologi ”En ontologi er en netbaseret og <strong>for</strong>maliseret beskrivelse af et<br />
emneområde. Den <strong>for</strong>melle beskrivelse gør, <strong>at</strong> computere kan<br />
håndtere betydningen af ord, og netværket af ord afgrænser<br />
ordenes betydningen bedre end almindelige ordbøger. Konkret<br />
er en ontologi et dokument eller fil der <strong>for</strong>melt definerer<br />
sammenhængene mellem ord”<br />
(http://buildingsmart.com/standards/mvd/mvd-process, 2011)<br />
WDSL ”WSDL står <strong>for</strong> Web Service Definition Language. Det er et<br />
XML-dokument, der beskriver en webtjeneste i detaljer. I<br />
WSDLen til en webtjeneste kan man se webtjenestens URL -<br />
den adresse, hvor webtjenesten udbydes, hvilke metoder<br />
webtjenesten stiller til rådighed, hvilke parametre, somwebtjenestens<br />
metoder tager i en <strong>for</strong>espørgsel og hvilke parametre<br />
webtjeneste svarer tilbage med på en <strong>for</strong>espørgsel”<br />
DBK ”DBK:2007 er en <strong>for</strong>kortelse <strong>for</strong> Dansk Bygge Klassifik<strong>at</strong>ion, og<br />
er frigivet den 1. januar 2007 som en del af Det Digitale Byggeri.<br />
Formålet med DBK er <strong>at</strong> bl.a. <strong>at</strong> skabe entydige koder der<br />
kan anvendes gennem hele byggeriets livscyklus. De entydige<br />
koder binder byggeriet sammen og medvirker til et fælles<br />
sprog mellem de <strong>for</strong>skellige parter i byggeriet”.<br />
Taxonomi ”En taxonomi er et system, som grupperer emner i en struktur.<br />
En taxonomi består som oftest af et hierarki af klasser, hvor<br />
hver klasse har én <strong>for</strong>ælder”<br />
(http://www.taxon.<strong>dk</strong>/artikler/taxdef.htm)<br />
De-facto standard En alment anerkendt fremgangsmåde eller specifik<strong>at</strong>ion, der i<br />
kraft af sin udbredelse eller dominerende markedsposition har<br />
opnået branchestandard
Bilag 1: Kontrol beregninger.<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Væg:<br />
Væg 1-3:<br />
Volumen: ( 15 m x 3 m x 0,3 m = 13,5 m3 ) x 2 = 27 m3<br />
Overflade: ( 15 m x 3 m = 45 m2 ) x 2 = 90 m2<br />
Væg 2-4:<br />
Volumen: ( (10 m-(0,3m -0,3m) x 3 m x 0,3 m = 8,46 m3 ) x 2 = 16,92 m3<br />
Overflade: ( 10 m x 3 m = 30 m2 ) x 2 = 60 m2<br />
Vindueshul: 1,01 m2<br />
Dørhul: 1,93 m2<br />
Samlet hulstørrelse areal: 2,94<br />
2,94 x 0,3 = 0,882<br />
Samlet hulstørrelse volumen: 0,882<br />
Samlet:<br />
Volumen: 43,92 m3 – 0,882 = 43,038<br />
Overflade: 150 m2 – 2,94 = 147,06<br />
Vindue:<br />
Areal: 1,112m x 0,912 = 1,01 m2<br />
Dør:<br />
Areal: 2,112m x 0,912 = 1,93 m2<br />
Cirkulær søjle:<br />
Skin area:<br />
A = 2 x π x r x h<br />
A = 2 x π x 0,150 x 3 = 2,83 m2<br />
Volume:<br />
V = π·r² x h<br />
V = π·0,150² x 3 = 0,21 m3<br />
Filerne brugt til dette <strong>for</strong>søg er vedhæftet denne rapport.<br />
20. december<br />
2011<br />
91
20. december<br />
2011<br />
92<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
Bilag 2: Program, Exchange Requirement<br />
NAME EXCHANGE STRUCTURAL DESIGN (OUTLINE CONCEPTUAL)<br />
IDENTIFIER<br />
CHANGE LOG<br />
CREATED JENSHANSEN@MEGAJERN.DK<br />
PROJECT STAGE 0 PORTFOLIO REQUIREMENTS<br />
1 CONCEPTION OF NEED<br />
2 OUTLINE FEASIBILITY<br />
3 SUBSTANTIVE FEASIBILITY <br />
4 OUTLINE CONCEPTUAL DESIGN <br />
5 FULL CONCEPTUAL DESIGN <br />
6 COORDINATED DESIGN AND PROCUREMENT<br />
7 PRODUCTION INFORMATION<br />
8 CONSTRUCTION<br />
9 OPERATION AND MAINTENANCE<br />
10 DISPOSAL<br />
AN EXCHANGE REQUIREMENT REPRESENTS THE CONNECTION BETWEEN PROCESS AND DATA. IT APPLIES THE<br />
RELEVANT INFORMATION DEFINED WITHIN AN INFORMATION MODEL TO FULFIL THE REQUIREMENTS OF AN<br />
INFORMATION EXCHANGE BETWEEN TWO BUSINESS PROCESSES AT A particular stage of the project.<br />
An exchange requirement describes a set of in<strong>for</strong>m<strong>at</strong>ion from a process th<strong>at</strong> has been per<strong>for</strong>med<br />
by an actor to enable a downstream process to be per<strong>for</strong>med by anot<strong>her</strong> actor.<br />
With reference to the Process Map, an exchange requirement is the set of in<strong>for</strong>m<strong>at</strong>ion associ<strong>at</strong>ed<br />
with a d<strong>at</strong>a flow arrow on the BPMN diagram. Thus, ERs are identified from the inputs and outputs<br />
of the Process Map.<br />
Processes<br />
2.1.1 Consider Client’s Requirements & Restrictions<br />
2.1.2 Consider Site Conditions and Constraints<br />
2.1.3 Develop Forms of Construction<br />
2.1.4 Review Construction Solutions<br />
2.1.5 Finalize Concept Design<br />
Results<br />
Model: Outline Structural Design
In<strong>for</strong>m<strong>at</strong>ion Requirements<br />
Type of In<strong>for</strong>m<strong>at</strong>ion<br />
Precursor<br />
Structural Specific<strong>at</strong>ions<br />
Outline Structural Design<br />
Client’s Requirements<br />
(Outline)<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
In<strong>for</strong>m<strong>at</strong>ion Needed MAN REC OPT Actor Supplying Form<strong>at</strong><br />
The provisions of the exchange requirements which includes<br />
appropri<strong>at</strong>es extracts from and references to:<br />
St<strong>at</strong>utory Regul<strong>at</strong>ions<br />
Codes<br />
Standards<br />
Technical Specific<strong>at</strong>ions<br />
Client Brief<br />
A <strong>for</strong>malized set of descriptions <strong>for</strong>ming part of the project<br />
brief, which specify the requirements and restrictions arising<br />
from the client. Based on an extended version of the<br />
client’s brief, this in<strong>for</strong>m<strong>at</strong>ion will have taken into consider<strong>at</strong>ion<br />
(from a structural engineering point of view) the<br />
implic<strong>at</strong>ions of:<br />
Overall Layout<br />
Building Size & Height Limits<br />
Floor to Floor Dimensions<br />
Column Spacing<br />
Construction Speed<br />
The clients requirements and restrictions will have an impact<br />
on the choice of:<br />
found<strong>at</strong>ions,<br />
structural <strong>for</strong>m,<br />
stability provision,<br />
√ External Bodies<br />
Planners<br />
Client<br />
√ Structural Designer<br />
93
20. december<br />
2011<br />
Type of In<strong>for</strong>m<strong>at</strong>ion<br />
Site Constraints<br />
(Outline)<br />
Construction<br />
Solutions (Outline)<br />
Preliminary Concept<br />
Design<br />
94<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
In<strong>for</strong>m<strong>at</strong>ion Needed MAN REC OPT Actor Supplying Form<strong>at</strong><br />
m<strong>at</strong>erials<br />
A <strong>for</strong>malized set of descriptions <strong>for</strong>ming part of the project<br />
brief, which specify the condition and constraints arising<br />
from the site. This in<strong>for</strong>m<strong>at</strong>ion will have taken into consider<strong>at</strong>ion<br />
(from a structural engineering point of view) the<br />
implic<strong>at</strong>ions of:<br />
Ground Conditions<br />
Ground W<strong>at</strong>er<br />
Loc<strong>at</strong>ion<br />
Site Access<br />
Adjacent Structures<br />
Environmental Conditions (such as wind, snow and ice)<br />
A draft set of in<strong>for</strong>mal descriptions and specific<strong>at</strong>ions of a<br />
planned building (or building complex) and its structure. In<br />
the <strong>for</strong>m of graphical and text in<strong>for</strong>m<strong>at</strong>ion, it serves as the<br />
basis of a preliminary concept design and describes:<br />
Structural Form<br />
Stability Provision<br />
M<strong>at</strong>erial<br />
Member sizes<br />
A draft set of in<strong>for</strong>mal descriptions and specific<strong>at</strong>ions of a<br />
planned building (or building complex) and its structure. In<br />
the <strong>for</strong>m of graphical and text in<strong>for</strong>m<strong>at</strong>ion, it serves as the<br />
basis of a final outline concept (sketch) design. This in<strong>for</strong>m<strong>at</strong>ion<br />
will have taken into consider<strong>at</strong>ion (from a structural<br />
√ Structural Designer<br />
√ Structural Designer<br />
√ Structural Designer
Type of In<strong>for</strong>m<strong>at</strong>ion<br />
Results<br />
Result type<br />
(FP/ ER/ Document/<br />
PSet/ Specific<strong>at</strong>ion etc.)<br />
UDVEKSLING AF INFORMATIONER I ET MODELBASERET MILJØ<br />
20. december<br />
2011<br />
In<strong>for</strong>m<strong>at</strong>ion Needed MAN REC OPT Actor Supplying Form<strong>at</strong><br />
engineering point of view) the appraisal of the:<br />
Stability provision<br />
Ease, speed, and cost of construction<br />
Structural per<strong>for</strong>mance<br />
functional per<strong>for</strong>mance<br />
In service per<strong>for</strong>mance<br />
Aesthetic impact<br />
In<strong>for</strong>m<strong>at</strong>ion Provided<br />
Model Outline Structural Design √ Geotechnical Engineer<br />
MAN<br />
OPT<br />
Actor Receiving Result Identifier<br />
Structural Engineer<br />
Mechanical Engineer<br />
Electrical Engineer<br />
Communic<strong>at</strong>ions Engineer<br />
Architect<br />
95