Metode og struktur for informationsniveauer

Transkript

1 November 2012 Metode og struktur for informationsniveauer Foreløbig udgave til offentlig høring

2 cuneco.dk center for produktivitet i byggeriet Rapport Metode og struktur for informationsniveauer Redaktion Kristian Birch Pedersen, Exigo Consult ApS Eigil Nybo Gert Jespersen, NCC Construction Danmark A/S Henrik Lützhøft Madsen, COWI A/S Morten Zimmermann, EKJ rådgivende ingeniører as cuneco en del af bips bips Lyskær Herlev Telefon Fax bips@bips.dk 2 Metode og struktur for informationsniveauer cuneco

3 Indhold Indhold 1 Indledning Formål Målgruppe En kort metodeintroduktion Scenarier for anvendelse Indgåelse af projekteringsaftale Brug af funktionsudbud Bygningsmodellering som produktionsværktøj Definition og kodning af informationsniveauer Egenskabsdata Kodning af informationsniveauer Views Views vs. sæt af egenskabsdata Udvidelsesmuligheder Anvendelse af informationsniveaumetoden Leverancespecifikation Leverancespecifikation i et faseopdelt projekt Eksempler på leverancespecifikation i forskellige projektforløb Skabeloner på cuneco-serveren Leverancespecifikation i et agilt projektforløb eller partnering Processpecifikation baseret på informationsniveauer Informationsniveauer i relation til aftaleforhold Konklusion Litteraturfortegnelse Metode og struktur for informationsniveauer cuneco

4 Bilag A Udviklingsmetode A.1 Indledning A.2 Step 1 - Fastlæg og beskriv gyldighedsområdet A.3 Step 2 - Overvej at genbruge eksisterende klassifikationsstrukturer, metoder og specifikationer A.4 Step 3 - Oplist vigtige termer A.5 Step 4 - Beskriv de overordnede definitioner af informationsniveauer inden for gyldighedsområdet A.6 Step 5 - Definer forekomster af bygningsdelstyper pr. informationsniveau A.7 Step 6 - Definer informationsniveauer for delsystemer eller grupper af komponenter A.8 Step 7 - Definer egenskabsdata for hvert informationsniveau A.9 Step 8 - Definer restriktioner for egenskaber, såsom tilladelige værdier samt relationer og krav på tværs af fagområder A.10 Step 9 - Test ved at skabe konkrete datasæt A.11 Opsummering af udviklingsmetode Bilag B Termer og definitioner Metode og struktur for informationsniveauer cuneco

5 1 Indledning Tegningen har gennem mange år været et af de vigtigste kommunikationsmidler i såvel samarbejdet mellem byggeriets parter, som internt i projektgrupper, i dialogen med bygherren og på byggepladsen. De første tegninger kan dateres helt tilbage til Babylon, omkring 2130 f.kr. Tegneteknikkerne blev videre udviklet af romerne til også at indeholde planer og snit, men har i praksis ikke udviklet sig siden Leonardo da Vinci s tekniske tegninger i det 15. århundrede (Sørensen, 2009). Digitaliseringen af byggebranchen er imidlertid godt i gang med at ændre på dette, så de primære informationsbærere (tegninger) ikke længere er simple manuelt udarbejdede afbildninger, men visuelt realistiske digitale repræsentationer, som afspejler opførelse og egenskaber for bygværket samt dets omgivelser. Det er i dag muligt og fornuftigt i praksis at udarbejde komplette digitale modeller af bygninger eller anlæg inden de udføres i virkeligheden. Mange bygherrer, arkitekter, ingeniører og entreprenører drager allerede nytte af dette, og skaber digitale bygningsmodeller som detaljeret beskriver såvel performance af den færdige bygning som dens opførelsesproces. De digitale arbejdsmetoder giver en betydelig mulighed for optimering og integrering af processer i byggeriet, men medfører også en stigende informationsmængde, og dermed stigende udfordringer med håndteringen af informationerne. I digitale bygningsmodeller implementeres allerede i de første faser af projekteringen informationer og data fra mange kilder såsom interne firmadatabaser, leverandører og producenter. Disse informationer er af vidt forskellig kvalitet og ikke altid lige strukturerede. Som illustreret på Figur 1 udarbejdes i byggeprojekter løbende både foreløbige og specifikke informationer, med en stigende konkretiseringsgrad over tid. Disse informationer anvendes på tværs af organisationer til en række formål såsom grundlag for analyser og beregninger, priskalkulationer, tidsplanlægning, energiberegning, udførelsesgrundlag og visualiseringer mv. Dette giver store udfordringer i forbindelse med kommunikationen af disse informationer, hvor ikke alle informationer er tænkt som valide fra afsenderens side, men som af samarbejdspartneren kan blive opfattet som gældende information, der kan anvendes som grundlag for det videre projektarbejde. Ofte kan en digital model skabe en illusion om færdiggørelse, der reelt ikke til stede. Metode og struktur for informationsniveauer cuneco

6 Figur 1: Illustration af udviklingen af den totale mængde af informationer i projektmateriale for et byggeprojekt sammenholdt med mængden af valid information. Byggebranchen håndterer og kommunikerer som ovenfor illustreret ofte informationer af vidt forskellig validitet, og det er derfor essentielt, at erkende behovet for at kunne stille præcise krav til omfanget, kvaliteten, og definitionen af disse informationer, og dermed opnå fordele af digitaliseringen. Det er ambitionen med informationsmetoden at skabe et værktøj, der muliggør en entydig kommunikation af validiteten af de informationer, der måtte være indeholdt i projektmaterialet såvel digitalt som analogt. Dels så det mere entydigt kan specificeres, hvilken ydelse der skal leveres, men ikke mindst, så det entydigt kan fastslås på hvilket grundlag ydelsen skal leveres. Et værktøj, der kan validere informationer, vurderes ikke blot nyttig for de mere traditionelle parter i en projekteringsproces (bygherre, projekterende og udførende), men også for en mere effektiv inddragelse af leverandører og projekterende leverandører i processen. Værktøjet vil også styrke parternes muligheder for at indgå entydige samarbejdsaftaler, og dermed fremme deres og branchens produktivitet. Håndtering af grænseflader og forventningsafstemning er andre væsentlige udfordringer for mange og et område, der ofte giver anledning til fejl og forsinkelser. De fleste i byggebranchen kan genkende et møde som illustreret på Figur 2, hvor der er opstået tvivl om hvem der skal levere informationer om udsparinger. 6 Metode og struktur for informationsniveauer cuneco

7 Figur 2: Typisk samtale på et projekteringsmøde. Uoverensstemmelsen mellem projektets partner som illustreret i Figur 2 grunder ofte i udfordringer som: Afklaring af grænseflader Forventningsafstemning Projektering fra forskellige lokaliteter/virksomheder Forskellig takt og detaljering på tværs af fag Manglende viden/fokus på efterfølgende processer (f.eks. udførelsen) Det er alle disse indledningsvist beskrevne udfordringer, cuneco skaber et værktøj til at løse med den metode og struktur for anvendelse og udvikling af informationsniveauer i byggebranchen, som beskrives i denne rapport. Kort fortalt anvendes informationsniveaumetoden til at kommunikere hvad der ved en overgang mellem to aktører henholdsvis skal afleveres af informationer, og hvad der modtages af informationer. I denne rapport beskrives resultatet af det første af flere cuneco-projekter omhandlende informationsniveauer. I projektet udvikles den metode og struktur, der skal anvendes i de efterfølgende projekter, hvor indholdet i informationsniveaumetoden skal detaljeres. Desuden gives konkrete principielle eksempler på metodens anvendelse. 1.1 Formål På baggrund af ovenstående eksempel og udfordringer fra hverdagen i byggebranchen er de vigtigste formål med informationsniveaumetoden overordnet at skabe: Et system der er med til at sikre en bedre kommunikation mellem byggeriets parter. Metode og struktur for informationsniveauer cuneco

8 Grundlag for, at det er klart, hvad der ved en overgang mellem to aktører henholdsvis skal afleveres af informationer, og hvad der modtages af informationer. Klarere spilleregler mellem aktører, samtidig med at det bliver lettere at vurdere omfanget af en opgave. Ved informationsoverdragelser og kravstillelse mellem aktører vil det således blive klart, for såvel den der afleverer, som den der modtager, hvilke eksplicitte informationer der er indeholdt, og på hvilket informationsniveau disse befinder sig. Kort sagt: præcise krav giver entydige resultater. Metoden skal understøtte informationshåndteringen gennem hele byggeriets livscyklus, lige fra ide til projektering, gennem udførelse samt til drift og vedligeholdelse. 1.2 Målgruppe Målgruppen for dette projekt og efterfølgende projekter er alle byggeriets parter i hele byggeprocessen. Den videre implementering af informationsniveaubegrebet baseres på dette projekts udviklede metoder og struktur. Det er en vigtig ambition, at informationsniveaumetoden skal være et værktøj for alle parter ikke blot bygherre, projekterende og udførende men også leverandører og driftsfolk etc. Desuden skal informationsmetoden kunne facilitere både de traditionelle hardcore-data i en projekteringsproces i form af materiale- og geometriske data, men også funktionsegenskaber, tidsdata, prisdata, arbejdsmiljø etc., altså principielt alle de informationer, der er aktuelle ved et byggeprojekt. 8 Metode og struktur for informationsniveauer cuneco

9 2 En kort metodeintroduktion Informationsniveaumetoden beskrives i detaljer i de følgende kapitler i rapporten, men som en appetitvækker introduceres metoden her med et lille eksempel. På Figur 3 er illustreret en kendt og simplificeret byggeproces. Skemaet i figuren betegnes en leverancespecifikation, og tallene refererer til aftalte informationsniveauer for de tilhørende bygningsdele og rum. Skemaet viser, at der ved afslutning af idefasen leveres informationer om rum på informationsniveau 2 samt om vægge på informationsniveau 1. Som illustreret er informationsniveauet for de øvrige bygningsdele ikke specificeret i idefasen. Disse bygningsdele kan være indeholdt i ideforslaget, med der er ikke noget krav til deres informationsniveau. Det ses af figuren, at i takt med at projektet skrider frem øges informationsniveauet for de forskellige bygningsdele og rum i projektet. Ikke alle bygningsdele er på samme informationsniveau ved afslutningen af hver fase. Tilsvarende er det også illustreret, at informationsniveauet ved aflevering til drift for nogle bygningsdele er lavere end f.eks. ved afslutning af udførelsesplanlægningen. Metoden er således meget fleksibel og understøtter en lang række forskellige anvendelsesscenarier. Figur 3: Eksempel på anvendelse af informationsniveauer til specifikation af hvilke informationer, der skal afleveres om bygningsdele og rum ved afslutningen faser i en simplificeret byggeproces. Hovedelementerne i informationsniveaumetoden er som illustreret ovenfor leverancespecifikationer samt informationsniveaudefinitioner for objekter som bygningsdele og rum. Desuden understøtter metoden også specifikation af informationsniveauer for processer Struktur og kodning af informationsdefinitionerne samt eksempler på, hvordan leverancespecifikationen anvendes er beskrevet yderligere i de næste kapitler. Metode og struktur for informationsniveauer cuneco

10 3 Scenarier for anvendelse Der er fremkommet mange input til dette projekt fra cunecos behovsanalyser, arbejdsgruppens brainstorming-sessions, workshops med videre. Som et redskab til at formalisere og kommunikere disse behov anvendes scenarier og storytelling. I dette kapitel beskrives ved hjælp af små historier tre scenarier for praktisk brug af cunecos informationsniveaumetode. Scenarierne er fiktive og beskriver nogle mulige eksempler på, hvordan informationsniveauer i fremtiden kan anvendes til at forbedre gennemførelsen af byggeprojekter samt medvirke til at sikre klare og veldefinerede aftaler mellem byggeriets parter. Scenarierne bruges til at inspirere, kommunikere og indsamle viden om branchens behov i relation til udvikling og anvendelse af informationsniveaumetoden. Scenarierne omhandler: 1. Indgåelse af projekteringsaftale 2. Brug af funktionsudbud 3. Bygningsmodellering som produktionsværktøj 3.1 Indgåelse af projekteringsaftale Ole er projekteringsleder på et nyt laboratoriebyggeri på en uddannelsesinstitution i hovedstadsområdet, hvor bygherrens projektleder, Peter, har besluttet at bruge den nye cuneco informationsniveaumetode i forbindelse med aftaleindgåelse. Inden indgåelse af projekteringsaftalen udfører Peter og Ole i samarbejde en projektanalyse, der definerer og beskriver projektets kontekst, kompleksitet, organisation og succeskriterier. På denne baggrund definerer de en hensigtsmæssig fasemodel for laboratorieprojektet. Laboratoriet skal indeholde meget specialudstyr, og de beslutter derfor, at det for inventar og installationer ikke er hensigtsmæssigt at anvende den traditionelle fasemodel, men i stedet at inddrage leverandørerne i en dialogbaseret udbudsform, hvor der opstilles funktionskrav på Informationsniveau 2 til udstyret. Under udfyldelsen af leverancespecifikationen logger Ole og Peter på cunecos server for at sikre, at de har den samme opfattelse af, hvad informationer om vinduer og døre på informationsniveau 3 og 4 betyder i praksis. Til deres store glæde er de lidt tekniske detaljer suppleret med nogle illustrati- 10 Metode og struktur for informationsniveauer cuneco

11 oner, så de hurtigt får fornemmelse af, hvor detaljerede de forskellige bygningsdele skal være på forskellige stadier i projektet. Tilsvarende undersøger de også, hvilke egenskabsdata arkitekten skal levere for rum og facader, for at installationsingeniøren kan udføre en energirammeeftervisning. 3.2 Brug af funktionsudbud I en totalentreprise ønsker totalentreprenøren at benytte et funktionsudbud for et atriumovenlys. Han indbygger derfor i sine rådgiveraftaler, at vinduerne specificeres på informationsniveau 2. Samtidig identificeres grænsefladerne til de øvrige bygningsdele til at være konstruktionssamlingerne, tilslutning for den elektriske styring samt fugerne. Det aftales derfor, at disse grænseflader fastlægges på informationsniveau 3 som grundlag for funktionsudbuddet. Omvendt sikrer totalentreprenøren i sin kontrakt med underentreprenøren, at denne får ansvaret for tidsplanen for bygningsdelene, som indgår i atriumovenlyset. Dermed opnås et optimalt forløb i forhold til projektets rådgivere, både for kontrol af funktionskravenes opfyldelse og geometrisk koordinering med øvrige bygningsdele. 3.3 Bygningsmodellering som produktionsværktøj Entreprenørfirmaet MNP Entreprise har besluttet at anvende cuneco informationsniveaumetoden i forbindelse med indgåelse af aftaler med deres rådgivere på totalentrepriser. Det giver dem klare fordele i forbindelse med produktionsplanlægningen, da de nu har systematiseret den måde, rådgiverne opbygger deres bygningsmodeller på. Herved kan MNP automatisk og løbende udføre successive økonomiske kalkulationer og foretage risikoanalyse af projektets tidsplan. MNP vælger at opgradere de bygningsmodeller, de får fra rådgivere i informationsniveau 4 for konstruktionerne og indvendige vægge til informationsniveau 6, da disse så kan anvendes direkte som input til deres armeringsrobotter og CNC-skæremaskinerne, der skærer og pakker henholdsvis armering og lægter i den takt, de skal bruges på byggepladsen. Metode og struktur for informationsniveauer cuneco

12 4 Definition og kodning af informationsniveauer Informationsniveaumetoden baseres på anvendelsen af informationsniveauer, der entydigt specificerer informationsleverancers omfang samt konkretiserings- og detaljeringsniveau for bygningsdele, rum og processer. Grundlaget for at kunne udfylde leverancespecifikationen illustreret i kapitel 0 er definitioner af informationsniveauer. Definitionerne er faste, statiske og indeholder for hver bygningsdel, rum eller proces en beskrivelse af kravene til informationer for hvert informationsniveau. I modsætning til indholdet i leverancespecifikationen er informationsniveaudefinitionerne faste og det samme for alle aftaler, så eksempelvis produktegenskaber for et vindue på informationsniveau 3 altid har samme indhold uafhængigt af projekttype, fase eller aktør. På et aktuelt projekt skal der således ikke tages stilling til indholdet informationsniveaudefinitionerne, men kun til tidspunktet eller fasen informationen skal leveres i, samt hvem den skal leveres af. Det er fundet hensigtsmæssigt som udgangspunkt at anvende 6 forskellige informationsniveauer. De 6 informationsniveauer benævnes med tal fra 1-6, hvor 1 svarer til det laveste informationsniveau og 6 til det højeste informationsniveau. Informationsniveauer defineres uafhængigt af projekttype, samarbejdsform og faseforløb. Der er således ikke en direkte sammenhæng mellem et specifikt informationsniveau og f.eks. hovedprojekteringsfasen i et byggeprojekt, da det kan aftales forskelligt fra projekt til projekt, hvilket informationsniveau specifikke bygningsdele eller processer skal være på i en bestemt fase. Som illustreret i Tabel 1 og Tabel 2 indeholder informationsniveaudefinitioner for bygningsdele en kombination af omfang, detaljering og konkretisering af specifikke egenskaber for den pågældende bygningsdel. 12 Metode og struktur for informationsniveauer cuneco

13 Illustration Informationsniveau 1 Beskrivelse Søjlen er ikke specificeret på dette informationsniveau. Informationsniveau 2 Funktionskrav Søjle indgår i det bærende system. Produktegenskaber Stålsøjle Formegenskaber ~200x300 mm Placering I modulsystem pr. ~6 m Informationsniveau 3 Funktionskrav Søjle indgår i det bærende system. Produktegenskaber Stålsøjle Formegenskaber I-profil 240 mm Placering I modulsystem pr. 5,4 m Tabel 1: Eksempel på en søjle i informationsniveau 1-3. Beskrivelsen skal ses som en eksemplificering og er ikke en fyldestgørende beskrivelse af tilstrækkelige informationer pr. informationsniveau. Metode og struktur for informationsniveauer cuneco

14 Illustration Informationsniveau 4 Beskrivelse Funktionskrav Søjles bæreevne 124 kn Produktegenskaber Materiale: S355 J2 Formegenskaber HE 240 B Placering I modulsystem pr. 5,4 m Informationsniveau 5 Funktionskrav Søjles bæreevne 124 kn Produktegenskaber Søjle Materiale: S355 J2, varmvalset Bolte i samling: Kvalitet 8.8. A4 Formegenskaber HE 240 B Bolte i samling: M16 Placering I modulsystem pr. 5,4 m Bolte i samling: c-c 120 mm Informationsniveau 6 Datagrundlag for automatisk produktion (pseudo-kode) % O4968 N01 M216 N02 G20 G90 G54 D200 G40 N05 T0300 N06 G96 S854 M42 M03 M08 N07 G41 G00 X1.1 Z1.1 T0303 N08 G01 Z1.0 F.05 N09 G00 Z1.1 N10 X1.0 N11 G01 Z0.0 F.05 % Tabel 2: Eksempel på en søjle i informationsniveau 3-6. Beskrivelsen skal ses som en eksemplificering og er ikke en fyldestgørende beskrivelse af tilstrækkelige informationer pr. informationsniveau. 14 Metode og struktur for informationsniveauer cuneco

15 4.1 Egenskabsdata Informationer om rum, bygningsdele og processer kan beskrives ved hjælp af egenskabsdata. Som beskrevet i cunecos metode og struktur for egenskabsdata, er egenskabsdata data om egenskaber dvs. en repræsentation af egenskaber på et givet objekt. Egenskaber defineres som karaktertræk ved objekter og kan både være generelle egenskaber, der findes på alle objekter, der tilhører en given klasse, eller specifikke egenskaber, der kun findes på de enkelte forekomster af objekterne. For så enkelt som muligt at kunne kommunikere og definere informationsniveauer har udviklingsarbejdet bag denne metodebeskrivelse vist, at det er hensigtsmæssigt at gruppere objekters egenskabsdata. Som vist på Figur 4 foreslås informationer om objekter og dermed deres egenskabsdata overordnet grupperet i minimum 3 områder: Funktionskrav, Resultat og Produktion. Funktionskrav omhandler informationer, der stiller krav til de specifikke løsninger i Resultatområdet. Produktionsområdet omhandler de produktionsrelaterede informationer, der anvendes til at skabe, drifte eller nedbryde resultatet. Hvert område kan videre opdeles i grupper af egenskabsdata, som f.eks. produkt-, placering-, form- og grænsefladeegenskabsdata for resultatområdet, hvormed der menes: Produktegenskaber o Beskriver løsningernes produktegenskabsdata såsom bygningsdelsspecifikationer, materialer og fabrikat. Placeringsegenskaber o Beskriver løsningernes placeringsegenskabsdata såsom modulsystem, lokalisering, orientering og mål. Formegenskaber o Beskriver løsningernes formmæssige egenskabsdata såsom facon, profil og areal. Grænsefladeegenskaber o Beskriver løsningernes referencer til tilstødende objekter, samt deres samlinger, tilslutninger og fuger m.v. Metode og struktur for informationsniveauer cuneco

16 Figur 4: Gruppering af egenskabsdata. Ovenstående opdeling af informationer i 3 områder og herunder grupper af egenskabsdata giver mulighed for entydigt at stille krav, som varierer på tværs af område eller egenskabsdatagruppe. Dette muliggør, at det i en given fase af projektet kan specificeres, at f.eks. søjlernes placering skal være fastlagt, men deres endelige dimension og materialetype først vil være på plads i næste fase af projektet. I praksis betyder det, at der med informationsniveaumetoden kan opstilles entydige specifikationer, hvor f.eks. produktegenskaber for nogle bygningsdele er kendt tidligt i projektforløbet, men deres konkrete placering først specificeres senere. Dette er typisk praksis i mange projektforløb, hvor det relativt tidligt besluttes at opføre et byggeri med betonelementer, mens den konkrete placering af de enkelte vægge først fastlægges senere. Tilsvarende fastlægges bærende vægges placering ofte tidligere end deres specifikke tykkelse (form), eller det er forskellige aktører, som specificerer henholdsvis placering og form. Byggeprojekter er præget af en lang række sådanne delte eller forskudte informationsleverancer, som er svære at håndtere med de gængse aftale former. Med opdeling af informationer i områder og gruppering af egenskabsdata har projektgruppen skabt et stærkt værktøj til at håndtere dette, som det vil blive illustreret yderligere i kapitel Kodning af informationsniveauer Med henblik på at kunne kommunikere entydigt omkring informationsleverancer indføres en kodning af egenskabsområderne og de underliggende grupper. Der anvendes bogstaver ved kodningen og de fastlægges i cunecos projekt omhandlende egenskabsdata samt begrebsmodel for procesdomænet. 16 Metode og struktur for informationsniveauer cuneco

17 Et eksempel på en overordnet kodning af områder og egenskabsdatasæt kunne se ud som herunder. Det skal bemærkes, at listen alene er et eksempel og ikke er gennemarbejdet, hvilket vil ske i senere cuneco-projekter. Metoden understøtter, at koderne kan nedbrydes successivt: A: Funktionskrav AA: Økonomi AB: Energi AC: Miljø AD: Indeklima AE: Akustik B: Resultat BA: Produkt BB: Placering BC: Form BD: Grænseflader C: Produktion CA: Udførelsesmæssige forhold CAA: Fugtstyring CAB: Arbejdsmiljøhensyn CAC: Produktionsplanlægning CB: Projektering CBA: Analyse og simulering CBAA: Bygherrekravsvurdering CBAB: Statisk simulering CBAC: Indeklimasimulering CBAD: Energiforbrugssimulering CBAE: Lyssimulering CBAF: Bæredygtighedsvurdering CBAG: Flugtvejssimulering CBAH: Brandsimulering CBAJ: Analyse af overholdelse af bygningsreglementet CC: Pris CD: Tid CE: Kvalitetssikring CF: Drift- og vedligehold.. Koderne for områder og egenskabsdatasæt anvendes som præfiks ved kommunikation, aftaler og beskrivelse af informationsniveauer eller som kendemærke i tabeller, der indeholder informationsniveaudefinitioner Eksempelvis angiver koden A3, at funktionskrav specificeres på informationsniveau 3. Tilsvarende angiver BA3 B2, at produktegenskaber specificeres på informationsniveau 3 og de øvrige placering-, form-, og grænsefladeegenskaber i resultatområdet på informationsniveau 2. Metode og struktur for informationsniveauer cuneco

18 Det anbefales, at indholdet i informationsniveaudefinitionerne fastlægges successivt det vil sige, at der i den videre udvikling først defineres informationsniveauer for de overordnede sæt af egenskabsdata, inden de fastlægges for mere detaljerede. I de følgende afsnit beskrives anvendelsen og kodningen af informationsniveauer yderligere. 4.3 Views De fleste processer i byggeriet kræver informationer for at kunne gennemføres. Den mængde af information, som er krævet for at gennemføre en given proces betegnes i CCS et view (af information). Det kan være views for information krævet til eksempelvis udførelsesplanlægning, drift, energiberegning mv. Views anvendes således til at udvælge klasser af objekter med udvalgte sæt af egenskaber med henblik på at opfylde specifikke formål som illustreret på Figur 5. Figur 5: Illustration af et view til processen energiberegning. F.eks. kan et view indeholde de klasser af bygningsdele med tilhørende egenskabsdata, som man skal bruge for at lave en energiberegning. Mængden af views vil ligesom mængden af egenskaber være nærmest uendelig, da det er de praktiske behov i konkrete situationer, der vil definere, hvad et view vil indeholde, og hvad det skal bruges til. CCS vil indeholde en række prædefinerede views, som brugerne umiddelbart vil kunne anvende til nærmere specificerede formål. Det vil tillige være muligt for brugerne at lave tilpasninger til disse views eller at oprette egne views til specifikke formål. Nogle processer kan gennemføres med forskelligt omfang, detaljering eller konkretisering. Disse processer defineres på forskellige informationsniveauer med dertil hørende forskellige views. Processen priskalkulation kan som illustreret på Figur 6 gennemføres med forskelligt omfang og nøjagtig- 18 Metode og struktur for informationsniveauer cuneco

19 hed. Ønskes et groft overslag anvendes f.eks. view et på informationsniveau 2. Det giver mulighed for at gennemføre en kalkulation baseret på en simpel gennemsnitlig enhedspris for f.eks. kontorbyggeri multipliceret med det samlede bruttoetageareal. Ønskes en mere nøjagtig kalkulation anvendes view et på informationsniveau 3 eller 4, hvor der inddrages flere egenskabsdata til at fastlægge enhedsprisen. Tilsvarende er mængderne ikke længere alene fastlagt på baggrund af bygningens bruttoareal, men er en opgørelse af de faktiske mængder af bygningsdele. Jo højere informationsniveau des flere egenskabsdata er indeholdt i viewet, hvilket, som illustreret på figuren, giver mulighed for at udføre en kalkulation med en større nøjagtighed. Figur 6: Illustration af anvendelsen af views (af information) på forskellige informationsniveauer til gennemførelse af en priskalkulation med forskellig nøjagtighed. En priskalkulation på informationsniveau 3 stiller krav om, at der er egenskabsdata til rådighed i et tilsvarende informationsniveau. Som illustreret på Figur 6 med de røde pile omfatter dette både egenskabsdata for bygningen som helhed, men også større bygningsdele såsom facaden. Ved priskalkulationen fastlægges desuden yderligere egenskabsdata såsom enhedspriser, der ikke er indeholdt i egenskabsdata fra resultatområdet. 4.4 Views vs. sæt af egenskabsdata Views og sæt af egenskabsdata er beslægtede begreber, men indeholder nogle væsentlige forskelle. Views indeholder en specifikation af hvilke egenskabsdata, der skal være tilgængelige på det givne informationsniveau for at kunne gennemføre en proces. Et view anvender ofte sæt af egenskabsdata fra forskellige områder, hvorimod egenskabsdatasæt ikke kan være indeholdt i hinanden, og således indeholder klart adskilte egenskabsdata. Desuden kan der for hvert view være behov for at specificere supplerende egenskabsdata, som fastlægges i den pågældende proces i det pågældende informationsniveau. På Figur 7 er konceptuelt illustreret, hvordan views gør brug af egenskabsdata på tværs af områder. Metode og struktur for informationsniveauer cuneco

20 Figur 7: Illustration af hvordan views defineres på tværs af egenskabsdatasæt. Ved anvendelse af sæt af egenskabsdata refereres alene til en leverance af information. Views består både af krav til hvilken information, der skal fastlægges, inden processen kan gennemføres, og hvilken information, der leveres, når processen er gennemført. Som illustreret på Figur 6 er formålet med view et priskalkulation, at kunne beregne prisen på et samlet projekt eller bygningsdele med en fastlagt nøjagtighed for hvert informationsniveau. I Figur 8 illustreres, hvordan et view på forskellige informationsniveauer stiller krav til leverance af information fra forskellige sæt af egenskabsdata. Koderne i skemaet er tidligere forklaret i afsnit 4.2, f.eks. betyder B Vægsystem på informationsniveau A2 B3, at Funktionskrav specificere på informationsniveau 2, og informationer i resultatområdet (B) på informationsniveau 3. Figur 8: Eksempel på definering af views for processen drift- og vedligeholdelsesplanlægning på forskellige informationsniveauer baseret på sæt af egenskabsdata. 20 Metode og struktur for informationsniveauer cuneco

21 4.5 Udvidelsesmuligheder Ved den fremtidige definition af views og informationsniveauer for forskellige fagområder kan det vise sig hensigtsmæssigt ikke at definere alle de tidligere beskrevne 6 informationsniveauer. For at skabe let genkendelighed på tværs af fagområder anbefales det ved fremtidige informationsniveaudefinitioner at operere indenfor rammerne af 6 informationsniveauer. Hvis det f.eks. viser sig, at det ved definering af views for energisimulering er tilstrækkeligt med 3 informationsniveauer, nummereres disse 2,3,4. Informationsniveauer 1, 5, 6 kan så være blanke. Hvis der derimod er behov for underinddeling af informationsniveauer, eller der opstår behov for forskellige alternative informationsniveaudefinitioner, anbefaler projektgruppen, at der til disse specialtilfælde anvendes små bogstaver efter tallet for informationsniveauet. Som et eksempel betragtes et underview til produktionsplanlægning (kode: CAC), der kan være Fordeling af projekteringsydelser og ansvar ved leverance og montage af elementer af beton og letklinkerbeton, med koden CACD. Hvis der ved definering af informationsniveau 3 for viewet CACD opstår behov for 2 projektspecifikke alternativer bliver koderne således CACD3a og CACD3b. Nogle processer kan stille krav om særlige egenskabsdata, som er udover det, der normalt og obligatorisk er indeholdt i et view på et bestemt informationsniveau. Dette kodes ikke, men skal fremgå af informationsniveaudefinitioner, som illustreret i Figur 8. Fleksibiliteten i anvendelsesmulighederne af informationsniveaukoderne er illustreret i Figur 9. Figur 9: Eksempel på udvidelsesmulighederne i kodningen af informationsniveauer. Metode og struktur for informationsniveauer cuneco

22 5 Anvendelse af informationsniveaumetoden I sidste kapitel blev det introduceret hvordan informationsniveauer kodes og defineres. I dette kapitel beskrives, hvordan informationsniveaumetoden anvendes som et effektivt værktøj til at specificere informationsleverancer. Informationsniveaumetoden er ikke en ny 3D-arbejdsmetode, projekteringsmetode eller fuldautomatisk proces, der fratager byggebranchens aktører deres faglige dømmekraft og viden. Metoden forudsætter, anerkender og understøtter den nødvendige faglige indsigt, der skal til at gennemføre et byggeprojekt. Informationsniveaumetoden er en ny måde at understøtte aftaler om informationsleverancer og informationsflow samt et redskab til at styre projektforløb i byggeprojekter. Metoden kan anvendes i traditionelt faseopdelte projektforløb samt i andre organiserede forløb såsom funktionsudbud, systemleverancer mv. Desuden understøttes agile samarbejdsmetoder såsom Scrum (se e.g. Metoden sigter mod at understøtte processer i projektbaserede produktioner, samt vilkårlige faseforløb. Desuden er den rettet mod hele forløbet fra projektering til udførelse og drift. Tilsvarende kan metoden anvendes i forbindelse med både digital og analog projektering. Afhængig af det enkelte byggeprojekts størrelse og organisationsform kan der være mange forskellige måder at indgå aftaler på mellem projektets aktører og dermed implementere informationsniveaumetoden. Et generelt eksempel på, hvordan informationsniveaumetoden kan understøtte de øvrige aftaleforhold i projektet, kan følge nedenstående 6 trin: 1. Udfør før indgåelse af en aftale baseret på informationsniveauer en projektanalyse, der definerer og beskriver projektets kontekst, kompleksitet, organisation, aktører og succeskriterier 2. Fastlæg en hensigtsmæssig procesmodel for byggeprojektet (f.eks. fasemodel for projektering og udførelse) 3. Identificer relevante aktører for relevante roller 4. Analyser informationsbehovet i projektets forskellige faser eller anvend en af cunecos skabeloner for f.eks. en traditionel faseopdeling, totalentrepriser eller funktionsudbud 5. Udfyld leverancespecifikationen 6. Følg løbende op på om projektets fremdrift er i overensstemmelse med det aftalte 22 Metode og struktur for informationsniveauer cuneco

23 5.1 Leverancespecifikation Som et vigtigt redskab i informationsniveaumetoden anvendes leverancespecifikationen som grundlag for at aftale, hvem der leverer hvilken information hvornår samt i hvilket detaljerings- og konkretiseringsniveau. Leverancespecifikationen kan udarbejdes successivt eller fastlægges for hele projektet fra starten af samarbejdet. En enkel leverancespecifikation er illustreret i Figur 10 for Fase 1 på et byggeprojekt. Som vist leveres informationer fra resultatområdet (B) for bygningsdele, der indgår i de 7 anførte hovedsystemer på informationsniveau 1-3. Som illustreret struktureres leverancespecifikationen efter CCS og bygningsdelene i hvert hovedsystem er ikke nødvendigvis på samme informationsniveau i fase 1. Antallet af hovedsystemer, delsystemer og komponenter, der indgår i leverancespecifikationen, vil afhænge af det specifikke projekt, og det samme vil detaljeringen af listen - dvs. venstre side i leverancespecifikationen. Figur 10: Eksempel på enkel leverancespecifikation. Leverancespecifikationen kan som illustreret på Figur 11 udvides med en specifikation af aktører på hver leverance. Figur 11: Eksempel på leverancespecifikation med aktører. 5.2 Leverancespecifikation i et faseopdelt projekt For hver fase i et byggeprojekt udvides leverancespecifikationen med flere kolonner som illustreret i Figur 12. Det giver mulighed for at variere infor- Metode og struktur for informationsniveauer cuneco

24 mationsniveau for hver bygningsdelstype, og tilsvarende enkelt tilføje forskellige aktører. Det er væsentligt at bemærke, at der ikke er en fastlåst sammenhæng mellem de traditionelle fasemodeller og informationsniveauer. Leverancespecifikation anvendes til helt fleksibelt at aftale, hvornår en aftalt eksplicit information skal være tilgængelig, og understøtter, at forskellige fagområder ikke nødvendigvis følger den samme takt for detaljering af informationer. Figur 12: Eksempel på leverancespecifikation i faseopdelt projekt. 5.3 Eksempler på leverancespecifikation i forskellige projektforløb En af de store styrker ved informationsniveaumetoden er dens anvendelsesmuligheder til at understøtte entydige aftaleforhold i vilkårlige projektforløb. Det illustreres i det følgende med nogle eksempler. Figur 13 viser først et eksempel på, hvordan de informationer, som skal afleveres i forbindelse med et tidligt udbud af pælefundamenter kan specificeres. Her ses det, at terrænsystemet (A) er opdelt i fire projektspecifikke delsystemer anført med %-tegn. Som anført ud for A Terrænsystem afleveres informationer i resultatområdet (B) generelt i informationsniveau 2, men for delsystem %UF3 af typen Pælefundamenter afleveres informationsniveau B4. System og bygningsdelstypelisten kan nedbrydes successivt, og som følge af systemets fleksible opbygning og struktur er det muligt at udspecificere aftaler om nogle bygningsdele mere end andre. Kriterierne for en yderligere nedbrydning kan være mange, f.eks. brug af flere rådgivere, brug af funktionsudbud, eller at sikre udvalgt information tidligt (f.eks. for myndighedsbehandling eller tidlig produktion). Netop opstillingen af leverancespecifikationen baseret på informationsniveauer sikrer en enklere kommunikation af formål og værdi ved en sådan underopdeling. 24 Metode og struktur for informationsniveauer cuneco

25 Figur 13: Eksempel på leverancespecifikation ved projektforløb med tidligt udbud på fundamenter. På tilsvarende vis er i Figur 14 illustreret, hvordan produktegenskaberne for de indvendige vægge er specificeret på et relativt højt informationsniveau 4 i fase 4, mens deres placerings- og formegenskaber er på det laveste informationsniveau. Det kan f.eks. være i et projekt, hvor det er besluttet, at de indvendige vægge er 120 mm gipsvægge, men deres placering er endnu ikke fastlagt i fase 4. Figur 14: Eksempel på leverancespecifikation, hvor produktegenskaberne for de indvendige vægge er specificeret på et relativt højt informationsniveau 4, men deres placerings- og formegenskaber er på det laveste informationsniveau. I forbindelse med funktionsudbud på vand-, afløbs- og varmesystemer (F+G) er i eksemplet i Figur 15 illustreret, hvordan alene funktionskravene (A2+A4) er specificeret for disse systemer. Som det ses af figuren er de øvrige systemer udbudt på baggrund af detailprojekteret materiale på et informationsniveau hvor både resultatområdet (B) og funktionskravene (A) er fastlagt. Metode og struktur for informationsniveauer cuneco

26 Figur 15: Eksempel på anvendelse af leverancespecifikation til specificering af informationsniveau i forbindelse med et funktionsudbud på vand-, afløbs- og varmesystemer. Det er et velkendt problem, at suboptimering dominerer byggebranchen, og som argumenteret af Kunz og Fischer (2009): Architects, engineers and contractors all have a culture and methods that minimize cost. With notable exceptions, many lack a culture that seeks to maximize value. This culture follows owner preference, but it also represents a culture that some AEC players accept in order to minimize their short-term project risks. giver en sådan tilgang sjældent et overordnet optimalt forløb eller produkt. En leverancespecifikation som konceptuelt illustreret i Figur 16 med tilhørende terminer vil være et godt værktøj til at modvirke dette, men vil forudsætte nogen detaljering. Med et udbygget paradigme for informationsniveauernes indhold vil selv en meget detaljeret aftaleformular være enkel at udfylde. 26 Metode og struktur for informationsniveauer cuneco

27 Fase 1 Fase 2 Fase 3 Fase N Inf. niv Aktør Inf. niv Aktør Inf. niv Aktør Inf. niv Aktør RUM Inf. niv. B2 Inf. niv. B3 TERRÆNSYSTEM Inf. niv. B3 Inf. niv. B4 Inf. niv. B4 Inf. niv. B4 BYGNINGSDELE OG RUM INSTAL. SYSTEM DÆKSYSTEM VÆGSYSTEM Inf. niv. B2 Inf. niv. B2 Inf. niv. B2 Inf. niv. B2 Inf. niv. B3 Inf. niv. B3 Inf. niv. B3 Inf. niv. B5 Inf. niv. B4 Inf. niv. B5 INVENTARSYST. Inf. niv. B4 INFRASTRUKTUR Inf. niv. B3 Inf. niv. B3 Figur 16: Eksempel på fleksibel anvendelse af leverancespecifikationen med forskellige informationsniveauer for forskellige bygningsdele og rum i forskellige faser af et projekt. 5.4 Skabeloner på cuneco-serveren Leverancespecifikationen vist i Figur 10 - Figur 16 kan implementeres i regneark, på en hjemmeside eller som en del af et projektstyringsværktøj, og for hvert hovedsystem, delsystem, komponent eller rum specificeres det aftalte informationsniveau for den pågældende informationsleverance. Metode og struktur for informationsniveauer cuneco

28 Desuden anføres, hvem der er ansvarlig for leverancen, samt om der er andre, som skal bidrage med oplysninger vedrørende den pågældende bygningsdel eller rum. Cuneco-serveren vil kunne indeholde skabeloner svarende til best-practice for forskellige organisationsformer og fasemodeller, så den enkelte projektleder eller bygherre, der er ansvarlig for udarbejdelse af aftaler på et byggeprojekt, kan komme let i gang med anvendelse af metoden. Tilsvarende etableres standarder for indholdet i de enkelte informationsniveauer for delsystemer, rum og udvalgte views. 5.5 Leverancespecifikation i et agilt projektforløb eller partnering Hvis aftaleforholdene på et byggeprojekt baseres på en agil samarbejdsmetode såsom Scrum, kan leverancespecifikationen også anvendes. Her vil der for hvert sprint af 1 uge til 1 måneds varighed blive aftalt, hvilke informationer, der udarbejdes, og af hvilket team. Aftaleformularen udfyldes således ikke for hele projektet ved indgåelse af kontrakt mellem projektets aktører, men derimod løbende ved opstart af hvert sprint. Metoden til indgåelse af aftaler understøtter på tilsvarende vis også effektivt projekter, hvor partnering anvendes som samarbejdsform. Leverancespecifikationen vil i agile projektforløb udvikles dynamisk og som illustreret med grå i Figur 17 udfyldes kun felter for de bygningsdele, som behandles i det pågældende sprint. 28 Metode og struktur for informationsniveauer cuneco

29 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Inf. niv. Master Team Inf. niv. Master Team Inf. niv. Master Team Inf. niv. Master Team BYGNINGSDELE OG RUM INVENTARSYST. INSTAL. SYSTEM DÆKSYSTEM VÆGSYSTEM TERRÆNSYSTEM INFRASTRUKTUR RUM Figur 17: Eksempel på leverancespecifikation for et byggeprojekt baseret på den agile samarbejdsmetode Scrum. På det viste stadie er sprint 1-3 gennemført og denne aftale vedrører sprint 4 I forbindelse med det daglige/regelmæssige Scrum-møde inden for hvert sprint opdateres et informationsniveau statusskema, hvilket giver alle projektets aktører mulighed for at følge fremdriften af projektet som vist på Figur 18. Det kan umiddelbart lyde som ofte at afholde daglige møder, men dette er et vigtig element i Scrum-metoden og med til at sikre fremdrift, fjerne barrierer og mindske risici i projektet. Figur 18: Eksempel på statusoversigt for et projekt styret ved hjælp af samarbejdsmetoden Scrum. Kilde: billede fra Wikipedia. Inden for bl.a. softwareudvikling er agile metoder som Scrum udbredte, og det er hensigten, at informationsniveaumetoden skal give mulighed for også at anvende dem i byggebranchen. Det ligger imidlertid uden for ram- Metode og struktur for informationsniveauer cuneco

30 merne af dette projekt at fastlægge, hvornår agile udviklingsmetoder med fordel kan anvendes samt give yderligere vejledning i implementering af metoderne, se Schwaber and Sutherland (2011). 5.6 Processpecifikation baseret på informationsniveauer En af styrkerne ved informationsniveaumetoden er, at den ikke kun kan anvendes til specifikation af informationsleverancer for bygningsdele og rum men også til specifikation af leverancer fra processer. I dette afsnit gives nogle eksempler på specifikation af processer baseret på informationsniveauer. I Figur 19 er vist hvordan en tidsplanlægningsproces kan gennemføres på 6 informationsniveauer. Figur 19: Eksempel på hvordan leverancer fra en tidsplanlægningsproces kan specificeres på 6 informationsniveauer. Ændringer fra et informationsniveau til det næste er vist med blå skrift. På samme måde kan specifikation af processen mængdeudtræk også baseres på informationsniveaumetoden. Dette er illustreret for bygningsdelen stribefundament i Figur 20. I cunecos projekter omhandlende opmålingsregler bliver dette beskrevet og specificeret yderligere. Det anbefales at starte fastlæggelsen af processen mængdeudtræk med specifikation af opmålingsregler for delsystemer, og derefter for komponenter, hvis dette viser sig nødvendigt. 30 Metode og struktur for informationsniveauer cuneco

31 Figur 20: Eksempel på anvendelse af informationsniveaumetoden til specifikation af opmålingsregler for bygningsdele. Her illustreret for et stribefundament. 5.7 Informationsniveauer i relation til aftaleforhold En byggesags aftaleforhold reguleres typisk af en eller flere kontrakter baseret på AB 92, ABT 93 eller ABR 89, og som bilag til kontrakten beskrives i en ydelsesbeskrivelse den konkrete ydelse eller løsning, som leveres. For rådgivningsydelserne kan ydelsesbeskrivelsen f.eks. baseres på DANSKE ARK/FRI s standarder, og for udførelsen af byggeprojekter kan ydelsesbeskrivelsen være baseret på bips beskrivelsesværktøj B Leverancespecifikationen og informationsniveaudefinitionerne er udviklet med henblik på at udgøre et bilag til disse ydelsesbeskrivelser og skal som tidligere beskrevet danne grundlag for at udarbejde entydige aftaler om leverancer. I projekter, hvor f.eks. bygherre stiller krav til de projekterende om anvendelse af IKT (informations- og kommunikationsteknologi), herunder bygningsmodellering, er dette beskrevet i et selvstændigt bilag til ydelsesbeskrivelsen. I IKT-ydelsesbeskrivelsen kan der med fordel refereres til leverancespecifikationen med henblik på afklaring af informationsniveau i bygningsmodellerne. Metode og struktur for informationsniveauer cuneco

32 6 Konklusion I denne rapport er beskrevet en metode og struktur for anvendelse af informationsniveauer i byggebranchen. Der er søgt skabt et vigtigt grundlag for udarbejdelse af mere entydige aftaler i byggebranchen og klarere grænseflader mellem dens aktører. Dette er gjort med udviklingen af nye leverancespecifikationer understøttet af informationsniveaudefinitioner, der kan anvendes i såvel traditionelle projektforløb som mere agile samarbejdsformer. Projektet har dermed bidraget med en ny metode til at specificere branchens ikke-formaliserede antagelser om, hvem der leverer hvilken information hvornår til hvad og i hvilket omfang. Dette forventes desuden at forbedre byggebranchens muligheder for genbrug af viden på tværs af aktører. Det er endvidere ambitionen, at den udviklede metode vil understøtte systematisk brug af bygningsmodellering både i projekteringen og samarbejdet med leverandører om indholdet i bygningsobjekter samt sikre, at bygningsmodellering kan anvendes som et produktionsværktøj. Selvom metoden givet også med fordel kan benyttes i et traditionelt analogt byggeprojekt, ses den store styrke i understøttelsen af bygningsmodellering og nedbrydning af de traditionelle grænseflader mellem projektering og udførelse. Dette ses som afgørende for at fremme branchens produktivitetsudvikling. Kvaliteten, successen og værdien af informationsniveaumetoden skal nu skabes gennem praktisk afprøvning, implementering i virkelige projekter og videre tilpasning og udvikling baseret på erfaringerne fra den praktiske brug. 32 Metode og struktur for informationsniveauer cuneco

33 7 Litteraturfortegnelse AIA (2008): Document E , Building Information Modelling Protocol Exhibit, The American Institute of Architects. bips (2005): bips Publikation A113 / Fordeling af projekteringsydelser og ansvar ved leverance og montage af elementer af beton og letklinkerbeton, 3. udgave, 1. oplag, Byggecentrum. bips (2006): DBK 2006 Vejledning, Begrebsmodel, klassifikations- og referencesystem, Det Digitale Byggeri, bips. bips (2008a): bips C102, CAD-manual 2008, anvisning. bips (2008b): bips F103, objektstruktur 2008 revision A. Gasevic D., Djuric, D., Devedzic, V. (2006). Model Driven Architecture and Ontology Development, Springer-Verlag Berlin Heidelberg, 311 pp. Gruber, Tom (1993). A translation approach to portable ontology specifications, Knowledge Acquisition 5, pp ISO (2001): ISO :2001(E). Building construction Organisation of information about construction works Part 2: Framework for classification of information. ISO (2009): ISO/FDIS :2009(E). Building information modelling Information delivery manual Part 1: Methodology and format. Kiviniemi, A. (2005): Requirements Management Interface to Building Product Models, CIFE Technical Report #161, Stanford University. Kiviniemi, A. et al. (2007): Senate Properties: BIM Requirements 2007, Volume 1: General part, VTT Technical Research Centre of Finland Kunz, J. and Fischer, M. (2009). Virtual Design and Construction: Themes, Case Studies and Implementation Suggestions, CIFE Working Paper #097, Version 9, Stanford University. Liebich, T., Adachi, Y., Forester, J., Hyvarinen, J., Karstila,K., Wix, J. (2006): International Alliance for Interoperability, Industry Foundation Classes, IFC2x Edition 3 Mindtools (2012): Brainstorming Generating many radical, creative ideas, tilgængelig online: Noy, N. F., McGuinness, D.L. (2001). Ontology Development 101: A Guide to Creating Your First Ontology. Stanford University, 25 pp. OCCS (2006): OmniClass A strategy for Classifying the Built Environment. Table 32 Services. Sandberg, J. (2006): Brainstorming Works Best if People Scramble For Ideas on Their Own, Wall Street Journal, tilgængelig online: Schwaber, K. and Sutherland, J. (2011): The Scrum Guide The Definite Guide to Scrum: The Rules of the Game. Sutton, R. (2006): Eight Tips for Better Brainstorming, Blomber Busines Week, tilgængelig online: _ htm Metode og struktur for informationsniveauer cuneco

34 Sørensen, K.B. (2009): Virtual Models Linked with Physical Components in Construction, DCE Thesis, Aalborg University. Tilgængelig online: al_components_in_construction.pdf Vico Software (2012): Model Progression Specification: On-line artikel på: W3C (2007): Web Ontology Language (OWL), W3C, Semantic Web, tilgængelig online: 34 Metode og struktur for informationsniveauer cuneco

35 Bilag A Udviklingsmetode A.1 Indledning I dette bilag beskrives metoderne, der ligger bag udviklingen af informationsniveaumetoden, der er beskrevet i rapporten, samt det videre arbejde med udvikling af indhold til metoden. Projektet Metode og struktur for informationsniveauer er en del af det samlede Cuneco Classification System (CCS). Målet med CCS er at skabe et fælles sprog, for udveksling af informationer, som øger produktiviteten for alle aktører i byggebranchen. Udviklingen af fælles sprog betegnes også ontologiudvikling, og defineres som eksplicit specifikation af koncepter og relationen i mellem dem (Gruber, 1993). Inspirationen til udviklingsmetoderne benyttet i dette projekt udspringer derfor af litteratur omhandlende ontologiudvikling. Det er afgørende, at der anvendes en fælles udviklingsmetoder, for at sikre et godt udviklingsforløb for dette og fremtidige informationsniveauprojekter på tværs af fagområder, at der anvendes en fælles udviklingsmetode. Udfordringen er imidlertid, at der ikke eksisterer en enkelt bedste metode til sådanne projekter omhandlende formalisering af koncepter og deres relationer, bl.a. fordi, der ikke kun findes én korrekt måde at definere dem på (Gasevic et al., 2006). Noy & McGuinness (2001) beskriver en enkel metode til udvikling af ontologier, hvilket på mange områder omfatter de samme udfordringer og problemstillinger, som udviklingen af informationsniveauer. Metoden udmærker sig ved at være systematisk, velafprøvet og forholdsvis enkel at gå til. På denne baggrund vurderes den som anvendelig til udviklingen af informationsniveauer. Som et led i en iterativ udviklingsproces har metoden været anvendt og er blevet prototypetestet samt tilpasset af projektdeltagerene i forbindelse med udviklingen denne metodebeskrivelse. Udviklingsmetoden består af følgende steps her tilpasset udviklingen af informationsniveauer for byggebranchen: 1. Fastlæg og beskriv gyldighedsområdet samt formålet med hvert informationsniveau 2. Overvej at genbruge eksisterende klassifikationsstrukturer, metoder og specifikationer 3. Oplist vigtige termer, der skal indeholdes i definitionerne 4. Beskriv de overordnede definitioner af informationsniveauer indenfor gyldighedsområdet 5. Definer forekomster af bygningsdelstyper pr. informationsniveau 6. Definer informationsniveauer for delsystemer eller grupper af komponenter Metode og struktur for informationsniveauer cuneco

36 7. Definer egenskabsdata for hvert informationsniveau 8. Definer restriktioner for egenskaber såsom tilladelige værdier samt relationer og krav på tværs af fagområder 9. Test ved at skabe konkrete datasæt I det følgende beskrives metodens anvendelse gennem en række eksempler. Det er afgørende de udviklede informationsniveaudefinitioners succes, at der i efterfølgende projekter sikres en operativ definition af indholdet i de enkelte informationsniveauer. Det er ligeledes vigtigt at forstå, at det stadig kræver viden, kreativitet samt praktisk indsigt at udvikle informationsniveauer, der virker. Den eneste måde at afgøre anvendeligheden af det endelige resultat er ved at evaluere det gennem praktisk brug. Så derfor sikrer metoden alene ikke et godt resultat, men skal ses som en hjælp til at guide processen med udviklingen af informationsniveauer. Inden et tilfredsstillende resultat opnås, kan der være behov for mange iterative gennemløb af de 9 steps i udviklingsmetoden. A.2 Step 1 - Fastlæg og beskriv gyldighedsområdet Det anbefales at starte udviklingen af informationsniveauer med at fastlægge og beskrive det gyldighedsområde, som informationsniveauerne skal være gældende for. Dette omfatter besvarelsen af nogle grundlæggende spørgsmål: Hvilket område skal informationsniveauerne defineres for? Hvad skal de bruges til? Hvilken type problemstillinger skal informationsniveauerne løse? Hvem skal bruge dem? Besvarelsen af disse spørgsmål kan variere i takt med udviklingen af informationsniveauerne, men det vil alligevel være en hjælp til afgrænsning og præcisering af de udviklede definitioner eksplicit at formulere et gyldighedsområde. Eksempel Som et eksempel kan gyldighedsområdet fastlægges til resultatområdets 4 grupper af egenskabsdata: produkt-, placerings-, formegenskaber og grænsefladegenskaber for bygningsobjekter, det vil sige rum og bygningsdele. Formålet og dermed anvendelsen kan fastlægges for de 6 informationsniveauer som herunder: Informationsniveau Formål 1 Anskueliggøre Kommunikere Evaluere Koordinere 2 Anskueliggøre Kommunikere Ideer og løsninger Ideer og løsninger Ideer og løsninger Ideer og løsninger Løsningsforlag projektniveau Løsningsforlag projektniveau 36 Metode og struktur for informationsniveauer cuneco

37 Evaluere Koordinere 3 Anskueliggøre Kommunikere Evaluere Koordinere 4 Anskueliggøre Kommunikere Evaluere Koordinere 5 Anskueliggøre Kommunikere Evaluere Koordinere 6 Anskueliggøre Kommunikere Evaluere Koordinere Løsningsforlag projektniveau Løsningsforlag projektniveau Løsningsforlag systemniveau Løsningsforlag systemniveau Løsningsforlag systemniveau Løsningsforlag systemniveau Bygbare løsninger Montageforslag Bygbare løsninger Montageforslag Bygbare løsninger Montageforslag Grænseflader Tolerancer Bygbare detailløsninger Fremstillingsmetode Bygbare detailløsninger Fremstillingsmetode Bygbare detailløsninger Fremstillingsmetode Grænseflader Tolerancer Bygbare detailløsninger Fremstillingsmetode Datagrundlag for automatisk produktion Datagrundlag for fremstillingsmetode Grænseflader Tolerancer De problemstillinger, som ønskes løst, kunne være udfordringer med afklaring afgrænseflader mellem projektets aktører, og de primære brugere vil være bygherrer, projekterende og udførende i byggeprocessen. En måde at fastlægge gyldighedsområdet er også at fastlægge en række kompetenceafklarende spørgsmål, som skal kunne besvares ud fra anvendelsen af de definerede informationsniveauer. Disse spørgsmål vil være nyttige at anvende i en første evaluering af de udviklede informationsniveauer. Dette kunne være spørgsmål som: Hvilke produktegenskaber for vinduer skal leveres af en arkitekt i informationsniveau 3? Hvem har ansvaret for tegning/modellering af udsparinger? Hvem leverer grundlag for funktionskrav til facaderne og på hvilket informationsniveau? Hvilke bygningsdele er specificeret i informationsniveau 2? Hvilket informationsniveau skal et projektmateriale være på for at kunne anvendes som udbudsgrundlag i et funktionsudbud? Metode og struktur for informationsniveauer cuneco

38 Hvis informationsniveaudefinitionerne efter endt udvikling kan besvare en sådan liste af kompetenceafklarende spørgsmål inden for gyldighedsområdet, indikerer det, at definitionerne er anvendelige, og hvis ikke er informationsniveaudefinitionsarbejdet ikke færdigt. A.3 Step 2 - Overvej at genbruge eksisterende klassifikationsstrukturer, metoder og specifikationer Frem for at udvikle indholdet og systematikken i informationsniveauerne fra bunden vil det næsten altid kunne svare sig at hente inspiration andre steder. Det kan f.eks. være fra klassifikationssystemer, ydelsesbeskrivelser eller internationale standarder. Til dette projekt er der bl.a. hentet inspiration fra en række bips, buildingsmart- og AIA-publikationer og -arbejdsmetoder: bips CAD-manual 2008 (bips, 2008a) AIA E BIM Protocol Document (AIA, 2008) Bips objektstruktur 2008 (bips, 2008b) bips A113 - Fordeling af projekteringsydelser og ansvar ved leverance og montage af elementer af beton og letklinkerbeton (bips, 2005) DBK 2006 (bips, 2006) Building information modelling Information delivery manual Part 1: Methodology and format (ISO, 2009) Specifikationen for IFC2x Edition 3 (Liebich et al., 2006) OmniClass (OCCS, 2006): Desuden er andre relaterede internationale initiativer blevet afdækket og anvendt, såsom det amerikanske Model Progression Specifikation (Vico Software, 2012), Senate Property's BIM specification (Kiviniemi et al., 2007) samt forskningsrapport om kravspecifikation (Kiviniemi, 2005) m.fl. Dette har bidraget til indholdet i metoden såvel som indholdet i informationsniveauerne. I den videre udvikling vil det ligeledes være vigtigt at afdække relevant baggrundsmateriale inden for det gyldighedsområde, som fastlægges i step 1. A.4 Step 3 - Oplist vigtige termer Efter at grundlaget nu er på plads fra step 2, og gyldighedsområdet er fastlagt i step 1, er næste skridt at opliste vigtige termer, der skal være indeholdt og understøttet af informationsniveauerne. Dette er nyttigt for på et tidligt tidspunkt at kunne diskutere eller forklare de emner, som skal kunne indeholdes i informationsniveauerne, hvilke bygningsdele og egenskabsdata, det drejer sig, om samt hvad de skal bruges til. Denne oplistning af termer kan med fordel gennemføres som en brainstorming-session blandt projektdeltagerne i den gruppe, som fastlægger infor- 38 Metode og struktur for informationsniveauer cuneco

39 mationsniveauerne inden for et givent gyldighedsområde. Der findes flere metoder og gode råd vedrørende gennemførelse af en god brainstormingsession, se f.eks. (Mindtools, 2012; Sandberg, 2006; Sutton 2006). Nedenstående Figur 22 viser et kort eksempel på begyndelsen af en brainstorming omkring det overordnede indhold i informationsniveauerne, og kan anvendes som inspiration til at brainstorme videre fra: Figur 21: Eksempel på begyndelsen af brainstorming session om termer relevante for informationsniveauer. Resultatet af brainstormingen vil fungere som en vigtig tjekliste for, om det fra starten ønskede indhold og omfang kan rummes i de informationsniveaudefinitioner, som bliver fastlagt i de efterfølgende step. Dette arbejde må ikke undervurderes. En mulig succes for informationsniveaumetoden kræver en terminologi, der på den ene side er tilstrækkelig omfattende og entydig til, at den kan udnyttes som aftalegrundlag i branchen. Omvendt må termerne ikke fremstå kunstige for branchens aktører. A.5 Step 4 - Beskriv de overordnede definitioner af informationsniveauer inden for gyldighedsområdet Grundlaget for informationsniveaudefinitionerne er nu på plads. Det næste skridt er overordnet at fastlægge indholdet i de 6 informationsniveauer for de fire grupper af egenskabsdata udvalgt som gyldighedsområde i step 1. Dette er afgørende for, at informationsniveauerne for forskellige bygningsobjekter får en fælles referenceramme, så der på tværs af fagområder opnås et afstemt indhold i den efterfølgende mere detaljerede udspecificering af informationsniveauerne. Dette kan gribes an ved at gennemgå listen af termer fra step 3 og fordele dem inden for de 6 informationsniveauer. Før alle kategorier og informationsniveauer er udfyldt, vil der typisk være behov for en række iterationer. Udvikles informationsniveaudefinitioner inden for grupper af egenskabsdata eller processer opstilles på tilsvarende vis 6 informationsniveauer. Det kan f.eks. omhandle afklaring af udførelsesmæssige forhold, tidsplanlægning eller kvalitetssikring m.v. Metode og struktur for informationsniveauer cuneco

40 Det er her værd at bemærke, at både det første og sidste informationsniveau udgør yderpunkter med henholdsvis det lavteste omfang af informationer og det største omfang og detaljeringsniveau, hvorfor det i mange projekter vil være de fire midterste informationsniveauer, som vil være af interesse. I tabellen herunder er illustreret med et eksempel på, hvordab informationsniveauer kan fastlægges på et overordnet niveau for bygningsobjekter generelt. Som eksempel bruges informationsniveau 3. Funktionskrav omhandler, som navnet beskriver, de krav, der stilles til bygningsobjekter, og de øvrige fire områder fastlægger omfang, konkretisering og detaljering af informationer for bygningsobjekters egenskaber. Område Informationsniveau 3 Funktionskrav Funktion Produktegenskaber Placeringsegenskaber Formegenskaber Grænsefladeegenskaber Forsyning Performance Areal & Volumen Eksisterende forhold Kvalitetssikringskrav Udførelsesforhold Kvalitetssikringskrav Sikkerhed Driftskrav Grænseflader Certificering Sikkerhed & sundhed Bygningsdelstype Rumtype Materialer Udstyr Inventar Udførelsesforhold Bygning Rum Bygningsdele Mål Bygning Rum Bygningsdele Sammensatte BD Komplekse tværsnit Armatur og udstyr Fast inventar Samlinger Udsparinger Tolerancer Primære bygningsd. Niv 3 CCS Infrastruktur specifik Hovedsystemniveau Rum Zone Brutto Netto Hovedsystemniveau Hovedsystemniveau Hovedsystemniveau Hovedsystemniveau Hovedsystemniveau Hovedsystemniveau Hovedsystemniveau Hovedsystemniveau Hovedsystemniveau Specifikation Niv 3 CCS Funktion og zone Delsystemniveau Type Armaturer Type Fast inventar Hovedsystemniveau Relation til modulsystem Eksakt lokalisering og orientering Eksakt placering Niv 3 CCS Detailmål Delsystemniveau Specifik ydre geometri Eksakt form Eksakt facon og profil Niv 3 CCS Solid repræsentation Omsluttende tværsnit Symbolsk repræsentation Symbolsk repræsentation Primære bygningsd. Niv 3 CCS For hovedføringsveje Systemniveau 40 Metode og struktur for informationsniveauer cuneco

41 Ambitionen med ovenstående eksempel er ikke, at præsentere et sæt færdigt udviklede informationsniveauer, men derimod at eksemplificere hvordan metoden er tænkt anvendt i efterfølgende projekter. A.6 Step 5 - Definer forekomster af bygningsdelstyper pr. informationsniveau De overordnede informationsniveauer vil ikke i alle tilfælde være tilstrækkelige til at løse de problemstillinger, som blev fastlagt under step 1. Det næste skridt er at fastlægge hvilke bygningsdele, der forekommer på de enkelte informationsniveauer. Dette kan med fordel gøres i et skema som vist på Figur 23. Eksemplet er udarbejdet for VVS bygningsdele og som illustreret anvendes farvekodning til at indikere om en bygningsdel er indeholdt i projektmaterialet på et givent informationsniveau. Nogle bygningsdele vil ikke eksplicit være repræsenteret i informationsniveau 1 og 2, hvor mange informationer hovedsageligt vil være repræsenteret for bygningen som helhed eller på rumniveau. Som illustreret for f.eks. rør i informationsniveau 3 kan der i skemaet også angives, at kun rør over en hvis dimension er indeholdt i det pågældende informationsniveau. Metode og struktur for informationsniveauer cuneco

42 Figur 22: Eksempel på fastlæggelse af forekomster af bygningsdele pr. informationsniveau. A.7 Step 6 - Definer informationsniveauer for delsystemer eller grupper af komponenter Der findes i princippet uendeligt mange bygningsdele, og for ikke at skulle definere informationsniveauer for dem alle og for at undgå at skulle gentage mange ensartede definitioner udarbejdes informationsniveau definitionerne på delsystemer eller grupper af komponenter med sammenfaldende 42 Metode og struktur for informationsniveauer cuneco

43 egenskabsdata. Dette gør arbejdet med specifikation og vedligeholdelse af informationsniveauer overkommeligt og definitionerne overskuelige. Figur 23: Informationsniveaudefinition 1-3 for delsystemet vinduesparti. Figur 24: Informationsniveaudefinition 4-6 for delsystemet vinduesparti. Metode og struktur for informationsniveauer cuneco

44 Fastlæggelse af egenskabsdata, samt hvilke egenskabsdata, der skal indeholdes i informationsniveauerne, kan blive en omfattende opgave at gennemføre. Derfor kan det være hensigtsmæssigt i første omgang at gennemføre informationsniveaudefinitionen til og med step 6 og herfra springe til step 9 Test ved at skabe konkrete datasæt. Informationsniveaudefinitionerne til og med step 6 vil give den danske byggebranche et vigtigt grundlag for afklaring af omfang, konkretisering og detaljering af informationer, der skal indgå i en leverance. Det kan vise sig hensigtsmæssigt at evaluere resultatet af informationsniveaudefinitionerne til step 6 gennem praktisk anvendelse i nogle projekter inden yderligere specificering foretages. Step 7 og 8 er medtaget for at betone og facilitere det store potentiale systematisk brug af CCS giver for en langt mere effektiv produktion i fremtiden. Det er forfatternes forhåbning, at specielt leverandører vil bidrage til at tydeliggøre på hvilken form og med hvilket indhold et projekt skal levere informationer for at muliggøre størst mulig automatisk produktion. De beskrevne step er endvidere udarbejdet med henblik på, at et projekt benytter leverandørdefinerede objekter som input i en bygningsmodel, og dermed bør specificeres, hvilke informationer leverandøren behøver fastlagt for sin produktion af bygningsdelen. A.8 Step 7 - Definer egenskabsdata for hvert informationsniveau Skemaet, der er vist i Figur 26 anvendes til at fastlægge hvilke egenskabsdata, der er indeholdt i hvert informationsniveau. Her anføres i de blå felter om en given egenskab er skitseret eller specificeret på hvert informationsniveau. Egenskabsdata markeret med en * angiver, at de er obligatoriske, de øvrige egenskabsdata er, med mindre anden aftale indgås, valgfrie. Som ved definering af informationsniveauer for delsystemer i step 6 er egenskabsdataene ikke indeholdt i alle informationsniveauer, hvilket indikeres med de grå felter. Det er desuden vigtigt, at der er overensstemmelse mellem skemaerne for egenskabsdata og definitionerne af informationsniveauer for delsystemer. Omfanget af egenskabsdata pr. bygningsdelstype fastlægges af cunecos egenskabsdataprojekt med udgangspunkt i relevant baggrundsmateriale fastlagt under step 2 for det pågældende gyldighedsområde. Egenskabsdatakortet vist i Figur 26 er fastlagt med udgangspunkt i de egenskabsdata, der er indeholdt i specifikationen af et vindue i IFC 2x3. IFC specifikationen vil for mange bygningsdele være tilstrækkelig som udgangspunkt for en egenskabsdataliste, og anbefales brugt som udgangspunkt, ind til cunecos udviklingsprojekt omhandlende egenskabsdata er færdigt. Obligatoriske egenskabsdata markeres i skemaet med en *. 44 Metode og struktur for informationsniveauer cuneco

45 Figur 25: Eksempel på skema til fastlæggelse af egenskabsdata pr. informationsniveau. Egenskabsdata for et vindue er anført i eksemplet. Obligatoriske egenskabsdata er markeret med en *. A.9 Step 8 - Definer restriktioner for egenskaber, såsom tilladelige værdier samt relationer og krav på tværs af fagområder For at kunne automatisere dataanalyse og datahåndteringsprocesser er det væsentligt at få kortlagt sammenhængen mellem individuelle egenskabsdata og deres tilladelige værdier. Dette er som illustreret i Figur 27 en omfattende opgave, der stiger proportionalt med antallet af egenskabsdata. I skemaet er som eksempel med kryds eller beskrivende tekst angivet hvilke egenskabsdata der kræves fastlagt, inden en given egenskab kan specificeres. Tilsvarende angives hvilke egenskaber, der påvirker andre. Et færdigudviklet step 8 er ikke en forudsætning for at komme i gang med at anvende informationsniveaumetoden, men det vil dog som minimum være hensigtsmæssigt at overveje relationerne mellem informationsniveauer ved udviklingen af best practice templates for leverancespecifikationer. Metode og struktur for informationsniveauer cuneco

46 Figur 26: Eksempel på egenskabsdata relationsskema. Skemaet kan med fordel udbygges med beskrivelse af relationen mellem egenskabsdataene samt definition i Web Ontology Language (OWL) eller lignende sprog egnet til videnrepræsentation. For en nærmere introduktion til OWL se W3C (2007). Dette vil bl.a. give mulighed for at gennemføre automatiske ræsonnementer i forbindelse med projektopfølgning eller automatisere kvalitetssikrings- og valideringsprocesser. For hver egenskab bør der også fastlægges relevante intervaller for tilladelige værdier eller tilladelige variationer i informationsniveauer på tværs af egenskabsdata. Dette er ligeledes nyttigt i forbindelse med kvalitetssikring og opfølgning på validiteten af afleverede informationer. Der kan f.eks. opstilles betingelser om, at der for at levere informationer om installationstekniske bygningsdele på informationsniveau 4 skal forefindes funktionskrav minimum på informationsniveau 3. A.10 Step 9 - Test ved at skabe konkrete datasæt Som det sidste og vigtigste step i udviklingen af succesfulde informationsniveaudefinitioner udføres løbende praktiske afprøvninger og evalueringer af de fastlagte informationsniveaudefinitioner. Dette gøres ved at udfylde leverancespecifikationer og tilhørende informationsniveaudefinitioner for konkrete bygningsobjekter og anvende dem i praktiske informationsudvekslinger mellem forskellige aktører i byggebranchen. Desuden tegnes og 3Dmodelleres bygningsobjekterne i de forskellige informationsniveauer. Der evalueres på resultatet af disse informationsudvekslinger, og dette anvendes i efterfølgende iterationer af udviklingen. I Figur 27 herunder er vist et af de tidlige eksempler på arbejdsgruppens skitse af et vindue på fire informationsniveauer. Tilsvarende er tidligere i rapporten i Tabel 1 og Tabel 2 vist en søjle i 6 forskellige informationsniveauer. Beskrivelsen skal ses som en eksemplificering og er ikke en fyldestgørende beskrivelse af tilstrækkelige informationer pr. informationsniveau. 46 Metode og struktur for informationsniveauer cuneco