Introduktion til egenskabsdata maj 2012
Indhold 2012 05 16 < Forrige side Næste side > 1. Indhold... 1. Indhold 2. Indledning... 3. Projektet om Egenskabsdata... 4. Begrebs afklaring... 5. Scenarie 1: IKT krav specifikation... 6 6. Scenarie 2: Rumprogram... 8 7. Scenarie 3: Arkitekten opretter vindue i model... 10 8. Scenarie 4: Energi beregning... 12 9. Scenarie 5: Materiale producent... 14 10. Scenarie 6: Digitalt udbud... 16 11. Scenarie 7: Data til drift... 18 12. Det videre arbejde... 20
Indledning 2. Indledning cuneco center for produktivitet i byggeriet udvikler det fælles grundlag for digitaliseret samarbejde i byggeri, anlæg og drift. Målet er øget effektivitet og produktivitet gennem bedre udveksling af informationer i hele byggeprocessen. Introduktionen er en overordnet introduktion, der handler meget om, hvordan egenskabsdata vil blive håndteret i byggeriets processer, og mindre om, hvordan projektet vedr. egenskabsdata teknisk er blevet løst. En del af cunecos udviklingsarbejde går ud på at skabe grundlaget for bedre udveksling af informationer om egenskaber for bygningsdele, rum, ressourcer og processer. Det kan fx være et vindue, som har nogle særlige egenskaber i forhold til type, funktion, materiale, farve, brandklasse mv. Uanset hvem du er i byggeprocessen vil informationer om et byggeris egenskaber på forskellig vis være relevante for dig. Fx hvis du skal lave en energiberegning, vedligeholde 100 vinduer i et byggeri, give tilbud på udskiftning af vinduerne i et byggeri, eller når du skal lave rengøringsudbud i driften mv. Branchen selv har udtrykt behov for en entydig måde at håndtere egenskabsdata på. Det viser resultater af den behovsanalyse, som cuneco har gennemført blandt branchens aktører. Hvis du er interesseret i den mere tekniske beskrivelse, vil vi henvise til den tekniske rapport for projektet, som du vil kunne finde på cunecos hjemmeside. Seks scenarier for brug af egenskabsdata Introduktionen giver dig et kortfattet indblik i cunecos projekt om egenskabsdata. Du finder seks forskellige scenarier, der illustrerer, hvordan forskellige aktører i byggeprocessen kan få gavn af cuneco til at håndtere egenskabsdata. Fx når bygherren skal specificere egenskaber for vinduer, døre mv. i programmeringsfasen. Når arkitekten skal søge og finde de bygningsdele fx vinduer som lever op til de krav, der er beskrevet i programmet. Når ingeniøren skal lave energiberegninger ud fra egenskabsinformationer om arealer og U værdier mv. På den baggrund har cuneco gennemført et projekt, der definerer og strukturerer rammerne for, hvordan egenskabsdata håndteres på en effektiv, ensartet måde gennem hele byggeriets livscyklus. Hvem henvender denne introduktion sig til? Denne introduktion henvender sig til de aktører på tværs af branchen, der til dagligt har behov for informationer om bygningsdeles og objekters egenskaber, og som ønsker viden om, hvordan cunecos projekt om egenskaber er relevant for dem.
Projektet om egenskabsdata 3. Projektet om egenskabsdata Projektets formål Formålet med cunecos projekt om egenskabsdata er at skabe rammerne og en klar struktur for, hvordan egenskabsdata håndteres, så både mennesker og it systemer kan aflæse og tolke egenskaber entydigt. Det handler blandt andet om at lave en struktur for: Projektgruppen Projektet om egenskabsdata er gennemført i efteråret 2011 og foråret 2012 af en gruppe sammensat af repræsentanter fra branchen, som har praktisk erfaring med håndtering af egenskabsdata. Herunder også en repræsentant fra branchens softwareleverandører hvordan egenskabsdata oprettes hvordan egenskaber navngives entydigt hvordan egenskabsdata vedligeholdes hvordan egenskabsdata udveksles digitalt Der eksisterer et uendeligt antal egenskab for alle objekter i byggeriet, og derfor er det ikke cunecos mål at definere alle tænkelige egenskaber. Samtidig vil objekternes egenskaber ændre og udvikle sig, og der tilføjes og fjernes egenskaber over tid. Formålet med cunecos projekt er derfor ikke at identificere og beskrive alle tænkelige egenskaber, men at skabe rammerne for håndteringen af dem. Projektgruppen består af: Bent Dalgaard Larsen, Dalux Gunnar Friborg, bips Michael Blom Søefeldt, ALECTIA A/S Niels Treldal, Rambøll Danmark Søren Spile, cuneco Projektet baserer sig bl.a. på de hidtidige erfaringer med egenskabsdata, og der er undervejs i projektet blevet inddraget en række udenlandske eksperter på området. Online adgang til egenskabsdata De efterfølgende cuneco projekter om egenskabsdata vil fokusere på at identificere og beskrive relevante egenskabsdata og strukturere informationerne og gøre dem tilgængelige på en fælles server. Her kan byggeriets aktører tilgå og hente opdaterede egenskabsdata direkte fra de it programmer, de arbejder i. Tilmeldte brugere til egenskabsdatabasen får mulighed for at komme med nye forslag til egenskabsdata. cuneco nedsætter en redaktionsgruppe, der kvalitetssikrer og redigerer de foreslåede egenskabsdata inden offentliggørelse.
Begrebs afklaring 4. Begrebsafklaring På trods af, at denne introduktion er forsøgt holdt på et ikketeknisk niveau, anvendes der en række begreber, som skal beskrives nærmere, for at indholdet af introduktionen vil fremtræde helt tydeligt. Der er tale om begreberne egenskabsdata og egenskabsdatasæt samt cuneco serveren, der vil blive refereret flittigt til i det følgende. Hvad er egenskabsdata? Ordet egenskab er et velkendt ord i det danske sprog, og de fleste mennesker vil være enige i, at farve, vægt, højde og bredde er eksempler på egenskaber for objekter. Når det drejer sig om objekter i byggeriet kommer der en lang række yderligere egenskaber til som fx isoleringsevne, miljøklasse, leveringstidspunkt etc. Både fysiske og tænkte objekter har egenskaber. Et vindue, der er indbygget i en bygning, har eksempelvis egenskaberne højde, bredde, U værdi og materiale som konkrete egenskaber. Et vindue, der er beskrevet i et projektmateriale kan have de samme egenskaber, men her er det krav i stedet for reelle værdier. I egenskabsdataprojektet skelner vi mellem egenskaber, som alle objekter har uendelig mange af, og egenskabsdata, der er en delmængde af de samme egenskaber men i en form, hvor vi har givet dem navn, enhed og værdi. alle de egenskabsdata, som det vil være relevant at opgive for et vindue i en given sammenhæng. Egenskabsdatasæt vil også kunne være defineret i forhold til specifikke formål. For vinduet kunne der være tale om de egenskabsdata for vinduet, som ville skulle være til rådighed for at vinduet fx kan indgå i en energiberegning. cunecos projekt vedrørende informationsniveauer vil bl.a. handle om at lave et system til entydigt at kunne definere de egenskabsdata, der skal være specificeret i en bygningsinformationsmodel på et givet tidspunkt. Hvad er cuneco serveren? Da de værktøjer, som cuneco udvikler, skal kunne understøtte det digitale samarbejde i byggeriet, er det vigtigt, at værktøjerne kan tilgås på en digital platform. En sådan platform er cuneco serveren, der er beskrevet i de enkelte scenarier i denne introduktion. cuneco serveren vil dels kunne anvendes af slutbrugere, som vil kunne slå op i fx en database med cunecos egenskabsdata og itsystemer, der vil kunne hente data og formater på cunecoserveren, så de vil kunne anvendes af brugerne af de enkelte itsystemer. Egenskabsdatasæt og informationsniveauer I cunecos arbejde anvendes begrebet egenskabsdatasæt om sæt af egenskabsdata, der er defineret i forhold til de enkelte objekter. Det kan fx være egenskabsdatasæt for vinduer, der er
Scenarie 1: Specifikation Introduktion til for egenskabsdata udveksling af data i et projekt 5. Scenarie 1: Specifikation for udveksling af data i et projekt I forbindelse med udarbejdelsen af et byggeprogram vælger bygherren og dennes rådgivere udbudsform samt hvordan det forventes, at rådgivere og entreprenører anvender bygningsmodeller i projektforløbet. Detaljeringen af bygningsmodellerne i de enkelte faser defineres ud fra veldefinerede informationsniveauer, der både beskriver den geometriske detaljering, og hvilke egenskaber bygningsmodellen indeholder i de enkelte faser. Kravene i forbindelse med digital aflevering er en kombination af standard krav og driftsorganisations særlige krav til supplerende egenskaber, der skal være indeholdt i bygningsmodellen med henblik på aflevering af data til D&V. Flow: 1. Bygherre udarbejder sammen med driftsorganisationen data krav til et specifikt projekt. 2. Der tjekkes, om alle ønskede egenskaber er defineret på cuneco serveren. Eventuelt supplerende egenskaber tilføjes på cuneco serveren. 3. Dataudvekslingsaftalen versioneres og gøres tilgængelig for rådgivere og entreprenører. 4. I forbindelse med afleveringer anvendes en modeltjekker for at sikre, at modtagne bygningsmodeller indeholder relevant information. 5. Data fra bygningsmodeller indlæses i driftssystemet. Til udarbejdelsen af IKT kravene til det specifikke projekt anvendes bips IKT konfigurations værktøj, hvor standardinformationsniveauer og egenskaber samt bygherrens egne definerede egenskaber er tilgængelige via link til cunecoserveren. Bygherren udarbejder en aftale for udveksling af data, der versioneres, og giver efterfølgende webadgang til rådgivere og entreprenører. Gennem hele projektforløbet er det muligt for alle parter via en modeltjekker at tjekke indhold af bygningsmodellerne ift. de projektspecifikke datakrav, som er stillet til de enkelte leverancer på det til pågældende projekt.
Scenarie 1: Specifikation Introduktion til for egenskabsdata udveksling af data i et projekt
Scenarie 2: Rumprogram 6. Scenarie 2: Rumprogram En bygherrerådgiver skal udarbejde et rumprogram og har i den forbindelse en dialog med bygherren om bygherrens behov i forhold til byggeriet. I forbindelse med denne dialog beskrives krav til funktioner og arealer og informationerne inddateres i bygherrerådgiverens byggeprogram software. På denne baggrund genereres et rumprogram m.h.t. funktioner, rumantal og indbyrdes sammenhæng mellem rummene. Dette rumprogram uploades nu i digital format til cunecoserveren for at tjekke dels rumprogrammets format, og dels om de anvendte klassifikationskoder er valide. cuneco serveren vil give besked tilbage til bygherrerådgiverens byggeprogramsoftware, så eventuelle justeringer i byggeprogrammet kan gennemføres. Flow: 1. Bygherrerådgiver interviewer bygherre om krav til projektet. 2. Overordnede arealkrav mht. funktioner, m2 og sammenhæng specificeres i bygherrerådgiverens byggeprogramsoftware. 3. Verifikation af programmets areal og rumdefinitioner og struktur foretages via cuneco databasen 4. Areal og rumprogram og/eller kravmodel genereres af byggeherrerådgiverens byggeprogram software. Når byggeprogrammet er ok m.h.t. format og indhold, vil det være klar til eksport med henblik på verifikation af indhold af konkurrenceprojekter.
Scenarie 2: Rumprogram
Scenarie 3: Arkitekten opretter vindue i model 7. Scenarie 3: Arkitekten opretter vindue i model Arkitekten designer bygningen i en bygningsmodel i overensstemmelse med programkrav og indsætter simple vinduesobjekter. Arkitekten søger derefter efter specifikke vinduer blandt flere producenter og produkter, som kan opfylde hendes krav. Hun indsætter de valgte vinduer som 3D objekter i bygningsmodellen. Hvis producenten leverer 3D objekter med egenskabsdata, supplerer arkitekten med data, hvis det er nødvendigt, hvis ikke udfylder arkitekten egenskabsdata ud fra vinduernes produktblade. Arkitektens CAD system trækker direkte på cuneco serveren, så strukturen af egenskabsdata er korrekt. Flow: 1. Arkitekten designer vindue i bygningsmodel i overensstemmelse med programkrav. 2. Der søges på mulige produkter, og hvilke krav der kan opfyldes på markedet for vinduesprodukter. 3. De fundne resultater sammenlignes, og vinduets egenskaber fastlægges. 4. Arkitekten sammenligner med cunecos egenskabsdatabase, for at sikre at alle egenskabsværdier er korrekt angivet at alle egenskaber på vinduesobjektet er med og supplerer evt. med de, der mangler. 1
Scenarie 3: Arkitekten opretter vindue i model 1
Scenarie 4: Energi beregning 1 8. Scenarie 4: Energiberegning En arkitekt udarbejder en bygningsmodel og angiver forventninger til U værdier for anvendte bygningsdele i klimaskærmen. Arkitektens CAD værktøj trækker på cunecos egenskabsdatabase og henter informationer om, hvordan U værdier skal defineres i det konkrete projekt pr. bygningsdel på informationsniveauet "myndighedsprojekt". Ingeniøren modtager arkitektens bygningsmodel inkl. egenskaber og kan automatisk trække arealer og U værdier mv. ud til energiberegning. I dialog med arkitekten tilpasses bygningen, så projektet overholder stillede energikrav. Undervejs udveksler arkitekten og ingeniøren løbende bygningsmodellen, og fordi alle nødvendige egenskaber om klimaskærmen er defineret entydigt, kan ingeniørens beregning automatisk opdateres. Flow: 1. Arkitekten laver et IFC udtræk fra modellen med de egenskabsdata, der skal anvendes i energi beregning. 2. Ingeniøren modtager modellen og udfører en beregning på baggrund af modellen. 3. Fra leverandørens objektbibliotek opdateres modellen med præcise vinduesdata og energiberegning kan opdateres. 4. Når projektet er klart sendes det til myndighedernes godkendelses server. 5. Når modellen er kontrolleret fås myndighedsgodkendelsen. Arkitekten beslutter, hvilke typer vinduer der skal bruges, og går ind på producentens hjemmeside, hvor hun henter vinduerne som 3D objekter. Materialeproducenten har oprettet et objekt bibliotek med sine vinduer og tilknyttet alle nødvendige egenskaber ud fra cunecos standard informationsniveau for "hovedprojekt". Energiberegningen kan igen automatisk opdateres ud fra de konkrete valg af vinduer. Ved myndighedsbehandling af byggeprojektet uploades bygningsmodellen inkl. egenskaber jf. cunecos standard informationsniveau for "myndighedsprojekt" til en server, som analyserer bygningsmodellen og tjekker om denne overholder gældende lovgivning.
Scenarie 4: Energi beregning 1
Scenarie 5: Vindues producent 1 9. Scenarie 5: Vinduesproducent En vinduesproducent har fået forskellige henvendelser om, at kunderne godt kunne tænke sig digitale modeller med egenskaber af vinduesproducentens produkter. Vinduesproducenten vil derfor undersøge, hvilke egenskaber der skal lægges på de digitale modeller. Producenten får adgang til cunecos egenskabsdatabase og finder frem til de produkttyper, som producenten leverer. Der er en lang række egenskaber, som bruges i forskellige sammenhænge (energiberegning, FM, mængdeudtræk mv.). Vinduesproducenten kan se, at det er muligt at levere samtlige af de egenskaber, der står i cunecos egenskabsdatabase. Han tilføjer derfor alle egenskaberne til sine 3D objekter og gør dem tilgængelige for deres kunder. Flow: 1. Vinduesproducenten henter egenskabsdatasæt for vinduer og for alle informationsniveauer fra cuneco serveren. 2. Egenskabsdatasættet tildeles alle producentens vinduesprodukter. 3. Producenten udfylder specifikke egenskabsdata på de enkelte produkter. 4. Producenten gør 3D objekterne med egenskabsdata tilgængelige for sine kunder.
Scenarie 5: Vindues producent 1
Scenarie 6: Digitalt Introduktion udbud til egenskabsdata 1 10. Scenarie 6: Digitalt udbud Entreprenøren skal give priser på levering og isætning af vinduer i et kontorbyggeri. Det er på forhånd i et cuneco projekt blevet defineret, hvilke egenskabsdata tilbudslisten skal grupperes efter, samt hvilke egenskabsdata der skal angives, fordi de i væsentlig grad er udslagsgivende for prisen. Disse egenskabsdata omfatter materiale, montering, støjdæmpning og isoleringsevne for den pågældende type bygningsdel. Disse egenskabsdata er angivet i den digitale tilbudsliste og kan umiddelbart fortolkes af entreprenørens kalkulationssystem, når tilbudslisten indlæses. Derved er det muligt at udpege de poster i entreprenørens kalkulationsdatabase, der matcher de opgivne egenskaber. Flow: 1. Digital tilbudsliste, der er grupperet efter vægkonstruktion, og etage modtages. 2. Tilbudslisten indlæses i kalkulationssystem. 3. Relevante bygningsdele fremfindes i bygningsdelskatalog på baggrund af egenskabsdata. 4. Ønsket bygningsdel udvælges. 5. Prissætning fastlægges på baggrund af materiale, montering, støj og lydisolering. 6. Udfyldt tilbudsliste afleveres til udbyder. Entreprenøren skal nu udvælge det af de mulige vinduer, som han ønsker at anvende samt vurdere prissætningen af de enkelte poster i forhold til de opgivne egenskabsdata vedr. vægkonstruktion og etage. Derefter vil han være klar til at afgive sit tilbud.
Scenarie 6: Digitalt Introduktion udbud til egenskabsdata 17
Scenarie 7: Data Introduktion til drift til egenskabsdata 1 11. Scenarie 7: Data til drift Ved aflevering af et byggeri til driftsherreorganisationen, både gennem udførelse og ved den formelle aflevering, modtager driftsherre driftsdata fra entreprenøren. De modtagne driftsdata tjekkes i driftsherrens modeltjekker ud fra en standard på cuneco serveren for at kontrollere, at den overholder de krav og specifikationer som driftsherren som udgangspunkt har stillet op ved projektets start. Flow: 1. Driftsherre modtager driftsdata i digitalt format fra entreprenøren. 2. De modtagne driftsdata tjekkes i en model tjekker. 3. Hvis data ikke lever op til kravene, gives der besked til entreprenøren om manglerne. I forhold til egenskabsdata er det en kontrol af om eksempelvis objektet vindue har de egenskabsdata, der skal til for at planlægge vedligehold og forvalte bygningen. 4. Når de modtagne data er ok, indlæses de i driftssystemet. Egenskabsdata på objektet vindue kan f.eks. være vinduets varmetab, vinduets forventede levetid, vinduets brandklasse, osv. Driftsherres erfaringer med egenskabsdata opsamles og bruges som grundlag for de krav, der stilles i forbindelse med programmering af nye projekter. Har man f.eks. gennem vedligeholdelsen af en række bygninger fundet ud af, at man typisk mangler egenskabsdata om vinduers hjørnesamlinger, bringes krav om disse egenskabsdata med til programmeringen af næste byggesag.
Scenarie 7: Data Introduktion til drift til egenskabsdata
Det videre arbejde 2 12. Det videre arbejde I andet kvartal af 2012 gennemføres et høringsforløb af den del af egenskabsprojektet, der skal danne grundlag for det videre arbejde med strukturering af egenskaber i byggebranchen. cuneco vil i de følgende projekter bl.a. identificere relevante egenskaber, som udveksles til konkrete formål Der etableres en database på cuneco serveren, som løbende vil blive ajourført med egenskaber. I hele cunecos projektperiode frem til medio 2014 vil der for alle byggeriets parter være gratis adgang til databasen. Internationalt er der flere initiativer omkring standardisering af egenskaber, og i forbindelse med etableringen af egenskabsdatabasen vil der løbende blive koordineret med internationale initiativer og standarder, så det også vil være muligt at udveksle digitale informationer internationalt.
Kolofon 2012 05 16 < Forrige side << Indhold 2 cuneco en del af bips cuneco.dk Denne publikation er udarbejdet i regi af cuneco center for produktivitet i byggeriet. Udgivelsesdato Maj 2012 bips Lautrupvang 1B 2750 Ballerup Telefon 70 23 22 37 Fax 70 23 42 37 bips@bips.dk bips.dk cuneco står for fællesskab. Vi udvikler det fælles grundlag for digitaliseret samarbejde i byggeri, anlæg og drift. Målet er øget effektivitet og produktivitet gennem bedre udveksling af informationer. cuneco er et udviklingsprojekt, der frem til 2014 udvikler, afprøver og implementerer fælles standarder for bedre udveksling af data gennem alle byggeriets processer fra idéfase og projektering over udførelse til drift og vedligehold. Standarderne skal være brugervenlige, it egnede og tilstræbes at være kompatible med både nationale og internationale standarder. cuneco drives under ledelse af foreningen bips i et partnersamarbejde med DTU/Aarhus universitet, Rudersdal kommune, Dansk Standard og FRI, DANSKE ARK, Dansk Byggeri, TEKNIQ, BAT kartellet og Bygherreforeningen. cuneco finansieres med midler fra EU s Regionalfond, Staten, Realdania og byggebranchens egenfinansiering. Sekretariat for cuneco Torben Klitgaard Søren Spile Maja Skovgaard Jonas Lindhardt Mette Øbro Anne Gram