metode og struktur for informati- onsniveauer
Post on 02-Feb-2017
229 Views
Preview:
TRANSCRIPT
2 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
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 1 2730 Herlev Telefon 70 23 22 37 Fax 70 23 42 37 E-mail bips@bips.dk www.bips.dk
3 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Indhold
Indhold Indledning ............................................................................................... 5 1
1.1 Formål ............................................................................................. 7
1.2 Målgruppe ....................................................................................... 8
En kort metodeintroduktion ................................................................... 9 2
Scenarier for anvendelse ...................................................................... 10 3
3.1 Indgåelse af projekteringsaftale ................................................... 10
3.2 Brug af funktionsudbud ................................................................ 11
3.3 Bygningsmodellering som produktionsværktøj ............................ 11
Definition og kodning af informationsniveauer .................................... 12 4
4.1 Egenskabsdata .............................................................................. 15
4.2 Kodning af informationsniveauer ................................................. 16
4.3 Views ............................................................................................. 18
4.4 Views vs. sæt af egenskabsdata .................................................... 19
4.5 Udvidelsesmuligheder .................................................................. 21
Anvendelse af informationsniveaumetoden ........................................ 22 5
5.1 Leverancespecifikation ................................................................. 23
5.2 Leverancespecifikation i et faseopdelt projekt ............................. 23
5.3 Eksempler på leverancespecifikation i forskellige projektforløb .. 24
5.4 Skabeloner på cuneco-serveren ................................................... 27
5.5 Leverancespecifikation i et agilt projektforløb eller partnering ... 28
5.6 Processpecifikation baseret på informationsniveauer ................. 30
5.7 Informationsniveauer i relation til aftaleforhold .......................... 31
Konklusion ............................................................................................. 32 6
Litteraturfortegnelse ............................................................................. 33 7
4 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Bilag A Udviklingsmetode ............................................................................. 35
A.1 Indledning ..................................................................................... 35
A.2 Step 1 - Fastlæg og beskriv gyldighedsområdet ........................... 36
A.3 Step 2 - Overvej at genbruge eksisterende
klassifikationsstrukturer, metoder og specifikationer .................. 38
A.4 Step 3 - Oplist vigtige termer ........................................................ 38
A.5 Step 4 - Beskriv de overordnede definitioner af
informationsniveauer inden for gyldighedsområdet .................... 39
A.6 Step 5 - Definer forekomster af bygningsdelstyper pr.
informationsniveau ....................................................................... 41
A.7 Step 6 - Definer informationsniveauer for delsystemer eller
grupper af komponenter ............................................................... 42
A.8 Step 7 - Definer egenskabsdata for hvert informationsniveau .... 44
A.9 Step 8 - Definer restriktioner for egenskaber, såsom tilladelige
værdier samt relationer og krav på tværs af fagområder ............. 45
A.10 Step 9 - Test ved at skabe konkrete datasæt ................................ 46
A.11 Opsummering af udviklingsmetode .............................................. 47
Bilag B – Termer og definitioner ................................................................... 48
5 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Indledning 1
Tegningen har gennem mange år været et af de vigtigste kommunikations-
midler i såvel samarbejdet mellem byggeriets parter, som internt i projekt-
grupper, 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 udarbej-
de 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 infor-
mationsmæ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, tids-
planlæ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 afsen-
derens side, men som af samarbejdspartneren kan blive opfattet som gæl-
dende information, der kan anvendes som grundlag for det videre projekt-
arbejde. Ofte kan en digital model skabe en illusion om færdiggørelse, der
reelt ikke til stede.
6 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Figur 1: Illustration af udviklingen af den totale mængde af informationer i projektmateria-le 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 er-
kende behovet for at kunne stille præcise krav til omfanget, kvaliteten, og
definitionen af disse informationer, og dermed opnå fordele af digitaliserin-
gen.
Det er ambitionen med informationsmetoden at skabe et værktøj, der mu-
liggø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 par-
ternes 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 illustre-
ret på Figur 2, hvor der er opstået tvivl om hvem der skal levere informatio-
ner om udsparinger.
7 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
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 infor-
mationer, 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 prin-
cipielle eksempler på metodens anvendelse.
1.1 Formål
På baggrund af ovenstående eksempel og udfordringer fra hverdagen i byg-
gebranchen er de vigtigste formål med informationsniveaumetoden over-
ordnet at skabe:
• Et system der er med til at sikre en bedre kommunikation mellem
byggeriets parter.
Figur 2: Typisk samtale på et projekteringsmøde.
8 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
• 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 let-
tere at vurdere omfanget af en opgave.
Ved informationsoverdragelser og kravstillelse mellem aktører vil det såle-
des 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 byggeri-
ets 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 informations-
niveaubegrebet 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 informationsmeto-
den kunne facilitere både de traditionelle ”hardcore-data” i en projekte-
ringsproces i form af materiale- og geometriske data, men også funktions-
egenskaber, tidsdata, prisdata, arbejdsmiljø etc., altså principielt alle de
informationer, der er aktuelle ved et byggeprojekt.
9 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
En kort metodeintroduktion 2
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 vi-
ser, at der ved afslutning af idefasen leveres informationer om rum på in-
formationsniveau 2 samt om vægge på informationsniveau 1. Som illustre-
ret 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 infor-
mationsniveau ved afslutningen af hver fase. Tilsvarende er det også illu-
streret, at informationsniveauet ved aflevering til drift for nogle bygnings-
dele er lavere end f.eks. ved afslutning af udførelsesplanlægningen. Meto-
den er således meget fleksibel og understøtter en lang række forskellige
anvendelsesscenarier.
Hovedelementerne i informationsniveaumetoden er som illustreret ovenfor leverancespecifikationer samt informationsniveaudefinitioner for objekter som bygningsdele og rum. Desuden understøtter metoden også specifikati-on af informationsniveauer for processer
Struktur og kodning af informationsdefinitionerne samt eksempler på,
hvordan leverancespecifikationen anvendes er beskrevet yderligere i de
næste kapitler.
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.
10 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Scenarier for anvendelse 3
Der er fremkommet mange input til dette projekt fra cunecos behovsanaly-
ser, arbejdsgruppens brainstorming-sessions, workshops med videre. Som
et redskab til at formalisere og kommunikere disse behov anvendes scena-
rier og storytelling.
I dette kapitel beskrives ved hjælp af små historier tre scenarier for praktisk
brug af cunecos informationsniveaumetode. Scenarierne er fiktive og be-
skriver nogle mulige eksempler på, hvordan informationsniveauer i fremti-
den kan anvendes til at forbedre gennemførelsen af byggeprojekter samt
medvirke til at sikre klare og veldefinerede aftaler mellem byggeriets par-
ter.
Scenarierne bruges til at inspirere, kommunikere og indsamle viden om
branchens behov i relation til udvikling og anvendelse af informationsni-
veaumetoden.
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 uddannelses-
institution 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, komplek-
sitet, organisation og succeskriterier. På denne baggrund definerer de en
hensigtsmæssig fasemodel for laboratorieprojektet. Laboratoriet skal inde-
holde meget specialudstyr, og de beslutter derfor, at det for inventar og
installationer ikke er hensigtsmæssigt at anvende den traditionelle fasemo-
del, 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å cune-
cos server for at sikre, at de har den samme opfattelse af, hvad informatio-
ner 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-
11 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
oner, så de hurtigt får fornemmelse af, hvor detaljerede de forskellige byg-
ningsdele 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 energiram-
meeftervisning.”
3.2 Brug af funktionsudbud
”I en totalentreprise ønsker totalentreprenøren at benytte et funktionsud-
bud 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 konstruktionssamlin-
gerne, 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 atri-
umovenlyset. Dermed opnås et optimalt forløb i forhold til projektets rådgi-
vere, både for kontrol af funktionskravenes opfyldelse og geometrisk koor-
dinering med øvrige bygningsdele.”
3.3 Bygningsmodellering som produktionsværktøj
”Entreprenørfirmaet MNP Entreprise har besluttet at anvende cuneco in-
formationsniveaumetoden 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ådgi-
verne opbygger deres bygningsmodeller på. Herved kan MNP automatisk og
løbende udføre successive økonomiske kalkulationer og foretage risikoana-
lyse af projektets tidsplan.
MNP vælger at opgradere de bygningsmodeller, de får fra rådgivere i infor-
mationsniveau 4 for konstruktionerne og indvendige vægge til informati-
onsniveau 6, da disse så kan anvendes direkte som input til deres arme-
ringsrobotter og CNC-skæremaskinerne, der skærer og pakker henholdsvis
armering og lægter i den takt, de skal bruges på byggepladsen.”
12 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Definition og kodning af infor-4mationsniveauer
Informationsniveaumetoden baseres på anvendelsen af informationsni-
veauer, der entydigt specificerer informationsleverancers omfang samt
konkretiserings- og detaljeringsniveau for bygningsdele, rum og processer.
Grundlaget for at kunne udfylde leverancespecifikationen illustreret i kapi-
tel 0 er definitioner af informationsniveauer. Definitionerne er faste, stati-
ske 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 ta-
ges stilling til indholdet informationsniveaudefinitionerne, men kun til tids-
punktet 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 in-
formationsniveau.
Informationsniveauer defineres uafhængigt af projekttype, samarbejdsform
og faseforløb. Der er således ikke en direkte sammenhæng mellem et speci-
fikt informationsniveau og f.eks. hovedprojekteringsfasen i et byggeprojekt,
da det kan aftales forskelligt fra projekt til projekt, hvilket informationsni-
veau specifikke bygningsdele eller processer skal være på i en bestemt fase.
Som illustreret i Tabel 1 og Tabel 2 indeholder informationsniveaudefinitio-
ner for bygningsdele en kombination af omfang, detaljering og konkretise-
ring af specifikke egenskaber for den pågældende bygningsdel.
13 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Illustration Beskrivelse
Informationsniveau 1
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 ek-semplificering og er ikke en fyldestgørende beskrivelse af tilstrækkelige informationer pr. informationsniveau.
14 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Illustration Beskrivelse
Informationsniveau 4
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, varmval-
set
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 ek-semplificering og er ikke en fyldestgørende beskrivelse af tilstrækkelige informationer pr. informationsniveau.
15 Metode og struktur for informationsniveauer · cuneco · 2012-11-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 egen-skabsdata, 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 objek-ter, 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 informations-niveauer 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 om-handler 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 byg-
ningsdelsspecifikationer, 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.
16 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
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 bygnings-dele 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 beslut-tes 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 egen-skabsdata har projektgruppen skabt et stærkt værktøj til at håndtere dette, som det vil blive illustreret yderligere i kapitel 5.
4.2 Kodning af informationsniveauer
Med henblik på at kunne kommunikere entydigt omkring informationsleve-rancer 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.
17 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
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 eksem-
pel 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 bygningsregle-
mentet • 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å informa-
tionsniveau 3. Tilsvarende angiver ”BA3 B2”, at produktegenskaber specifi-
ceres på informationsniveau 3 og de øvrige placering-, form-, og grænsefla-
deegenskaber i resultatområdet på informationsniveau 2.
18 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Det anbefales, at indholdet i informationsniveaudefinitionerne fastlægges
successivt – det vil sige, at der i den videre udvikling først defineres infor-
mationsniveauer for de overordnede sæt af egenskabsdata, inden de fast-
lægges for mere detaljerede.
I de følgende afsnit beskrives anvendelsen og kodningen af informationsni-
veauer yderligere.
4.3 Views
De fleste processer i byggeriet kræver informationer for at kunne gennem-
fø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, energi-
beregning 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.
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 define-
re, hvad et view vil indeholde, og hvad det skal bruges til.
CCS vil indeholde en række prædefinerede views, som brugerne umiddel-bart 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 informationsni-
veauer med dertil hørende forskellige views. Processen priskalkulation kan
som illustreret på Figur 6 gennemføres med forskelligt omfang og nøjagtig-
Figur 5: Illustration af et view til processen energiberegning.
19 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
hed. Ønskes et groft overslag anvendes f.eks. view’et på informationsni-
veau 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 anven-
des view’et på informationsniveau 3 eller 4, hvor der inddrages flere egen-
skabsdata 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 informations-
niveau des flere egenskabsdata er indeholdt i viewet, hvilket, som illustre-
ret på figuren, giver mulighed for at udføre en kalkulation med en større
nøjagtighed.
En priskalkulation på informationsniveau 3 stiller krav om, at der er egen-
skabsdata til rådighed i et tilsvarende informationsniveau. Som illustreret
på Figur 6 med de røde pile omfatter dette både egenskabsdata for bygnin-
gen som helhed, men også større bygningsdele såsom facaden. Ved pris-
kalkulationen fastlægges desuden yderligere egenskabsdata såsom en-
hedspriser, 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åle-
des indeholder klart adskilte egenskabsdata. Desuden kan der for hvert
view være behov for at specificere supplerende egenskabsdata, som fast-
læ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 egenskabs-
data på tværs af områder.
Figur 6: Illustration af anvendelsen af views (af information) på forskellige informationsniveauer til gennemførelse af en priskalkulation med forskellig nøjagtighed.
20 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
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 fast-læ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 informationsni-veau. 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æg-system” på informationsniveau ”A2 B3”, at Funktionskrav specificere på informationsniveau 2, og informationer i resultatområdet (B) på informati-onsniveau 3.
Figur 8: Eksempel på definering af views for processen drift- og vedligeholdelsesplanlæg-ning på forskellige informationsniveauer baseret på sæt af egenskabsdata.
Figur 7: Illustration af hvordan views defineres på tværs af egenskabsdatasæt.
21 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
4.5 Udvidelsesmuligheder
Ved den fremtidige definition af views og informationsniveauer for forskel-
lige fagområder kan det vise sig hensigtsmæssigt ikke at definere alle de
tidligere beskrevne 6 informationsniveauer. For at skabe let genkendelig-
hed på tværs af fagområder anbefales det ved fremtidige informationsni-
veaudefinitioner 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. In-
formationsniveauer 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 informationsniveaudefini-
tioner, anbefaler projektgruppen, at der til disse specialtilfælde anvendes
små bogstaver efter tallet for informationsniveauet. Som et eksempel be-
tragtes 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 pro-
jektspecifikke 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 infor-
mationsniveau. Dette kodes ikke, men skal fremgå af informationsniveau-
definitioner, som illustreret i Figur 8.
Fleksibiliteten i anvendelsesmulighederne af informationsniveaukoderne er
illustreret i Figur 9.
Figur 9: Eksempel på udvidelsesmulighederne i kodningen af informationsniveauer.
22 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Anvendelse af informationsni-5veaumetoden
I sidste kapitel blev det introduceret hvordan informationsniveauer kodes
og defineres. I dette kapitel beskrives, hvordan informationsniveaumeto-
den anvendes som et effektivt værktøj til at specificere informationsleve-
rancer.
Informationsniveaumetoden er ikke en ny 3D-arbejdsmetode, projekte-
ringsmetode eller fuldautomatisk proces, der fratager byggebranchens
aktører deres faglige dømmekraft og viden. Metoden forudsætter, aner-
kender og understøtter den nødvendige faglige indsigt, der skal til at gen-
nemfø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.
http://www.scrum.org). 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 an-
vend en af cunecos skabeloner for f.eks. en traditionel faseopde-ling, totalentrepriser eller funktionsudbud
5. Udfyld leverancespecifikationen 6. Følg løbende op på om projektets fremdrift er i overensstemmelse
med det aftalte
23 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
5.1 Leverancespecifikation
Som et vigtigt redskab i informationsniveaumetoden anvendes leverance-
specifikationen som grundlag for at aftale, hvem der leverer hvilken infor-
mation 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 in-
formationer fra resultatområdet (B) for bygningsdele, der indgår i de 7 an-
førte hovedsystemer på informationsniveau 1-3. Som illustreret strukture-
res leverancespecifikationen efter CCS og bygningsdelene i hvert hovedsy-
stem er ikke nødvendigvis på samme informationsniveau i fase 1.
Antallet af hovedsystemer, delsystemer og komponenter, der indgår i leve-
rancespecifikationen, 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-
24 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
mationsniveau for hver bygningsdelstype, og tilsvarende enkelt tilføje for-
skellige aktører. Det er væsentligt at bemærke, at der ikke er en fastlåst
sammenhæng mellem de traditionelle fasemodeller og informationsni-
veauer. 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 detalje-
ring af informationer.
Figur 12: Eksempel på leverancespecifikation i faseopdelt projekt.
5.3 Eksempler på leverancespecifikation i forskellige pro-jektforløb
En af de store styrker ved informationsniveaumetoden er dens anvendel-
sesmuligheder til at understøtte entydige aftaleforhold i vilkårlige projekt-
forlø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 speci-
ficeres. 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 afleve-
res informationer i resultatområdet (B) generelt i informationsniveau 2,
men for delsystem %UF3 af typen Pælefundamenter afleveres informati-
onsniveau 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 funkti-
onsudbud, eller at sikre udvalgt information tidligt (f.eks. for myndigheds-
behandling eller tidlig produktion). Netop opstillingen af leverancespecifika-
tionen baseret på informationsniveauer sikrer en enklere kommunikation af
formål og værdi ved en sådan underopdeling.
25 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Figur 13: Eksempel på leverancespecifikation ved projektforløb med tidligt udbud på fun-damenter.
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 infor-
mationsniveau. 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 indvendi-ge 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 øv-
rige systemer udbudt på baggrund af detailprojekteret materiale på et in-
formationsniveau hvor både resultatområdet (B) og funktionskravene (A) er
fastlagt.
26 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Figur 15: Eksempel på anvendelse af leverancespecifikation til specificering af informati-onsniveau 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 leve-
rancespecifikation 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 informationsniveauer-
nes indhold vil selv en meget detaljeret aftaleformular være enkel at udfyl-
de.
27 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
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, kompo-
nent eller rum specificeres det aftalte informationsniveau for den pågæl-
dende informationsleverance.
Inf. niv Aktør Inf. niv Aktør Inf. niv Aktør Inf. niv Aktør
INST
AL.
SYS
TEM
INV
ENTA
RSY
ST.
INFR
AST
RU
KTU
R
Fase 1 Fase 2 Fase 3 Fase N
BYG
NIN
GSD
ELE
OG
RU
MR
UM
TER
RÆ
NSY
STEM
VÆ
GSY
STEM
DÆ
KSY
STEM
Inf. niv. B2
Inf. niv. B2
Inf. niv. B2
Inf. niv. B2
Inf. niv. B2
Inf. niv. B3
Inf. niv. B3
Inf. niv. B3
Inf. niv. B3
Inf. niv. B3
Inf. niv. B3
Inf. niv. B3
Inf. niv. B4 Inf. niv. B4
Inf. niv. B4
Inf. niv. B4
Inf. niv. B5
Inf. niv. B4
Inf. niv. B5
28 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
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 byg-
ningsdel eller rum.
Cuneco-serveren vil kunne indeholde skabeloner svarende til best-practice
for forskellige organisationsformer og fasemodeller, så den enkelte projekt-
leder eller bygherre, der er ansvarlig for udarbejdelse af aftaler på et byg-
geprojekt, 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 samarbejdsme-
tode 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 udfyl-
des således ikke for hele projektet ved indgåelse af kontrakt mellem projek-
tets 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.
29 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
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 pro-
jektets 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.
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-
Inf. niv. Master Team Inf. niv. Master Team Inf. niv. Master Team Inf. niv. Master Team
Sprint 3 Sprint 4
BYG
NIN
GSD
ELE
OG
RU
MR
UM
TER
RÆ
NSY
STEM
VÆ
GSY
STEM
DÆ
KSY
STEM
INST
AL.
SYS
TEM
INV
ENTA
RSY
ST.
INFR
AST
RU
KTU
R
Sprint 1 Sprint 2
Figur 18: Eksempel på statusoversigt for et projekt styret ved hjælp af samarbejdsmetoden Scrum. Kilde: billede fra Wikipedia.
30 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
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å informati-
onsniveauer.
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å base-
res på informationsniveaumetoden. Dette er illustreret for bygningsdelen
stribefundament i Figur 20. I cunecos projekter omhandlende opmålings-
regler 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.
31 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
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 ba-
seret 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 ydelsesbe-
skrivelsen være baseret på bips’ beskrivelsesværktøj B.1000.
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 anven-
delse af IKT (informations- og kommunikationsteknologi), herunder byg-
ningsmodellering, er dette beskrevet i et selvstændigt bilag til ydelsesbe-
skrivelsen. I IKT-ydelsesbeskrivelsen kan der med fordel refereres til leve-
rancespecifikationen med henblik på afklaring af informationsniveau i byg-
ningsmodellerne.
32 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Konklusion 6
I denne rapport er beskrevet en metode og struktur for anvendelse af in-
formationsniveauer i byggebranchen. Der er søgt skabt et vigtigt grundlag
for udarbejdelse af mere entydige aftaler i byggebranchen og klarere græn-
seflader mellem dens aktører. Dette er gjort med udviklingen af nye leve-
rancespecifikationer understøttet af informationsniveaudefinitioner, der
kan anvendes i såvel traditionelle projektforløb som mere agile samarbejds-
former.
Projektet har dermed bidraget med en ny metode til at specificere bran-
chens ikke-formaliserede antagelser om, hvem der leverer hvilken informa-
tion hvornår til hvad og i hvilket omfang. Dette forventes desuden at for-
bedre byggebranchens muligheder for genbrug af viden på tværs af aktører.
Det er endvidere ambitionen, at den udviklede metode vil understøtte sy-
stematisk brug af bygningsmodellering både i projekteringen og samarbej-
det med leverandører om indholdet i bygningsobjekter samt sikre, at byg-
ningsmodellering kan anvendes som et produktionsværktøj. Selvom meto-
den givet også med fordel kan benyttes i et traditionelt ”analogt” byggepro-
jekt, ses den store styrke i understøttelsen af bygningsmodellering og ned-
brydning 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.
33 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Litteraturfortegnelse 7
AIA (2008): Document E202 – 2008, Building Information Modelling Proto-
col Exhibit, The American Institute of Architects.
bips (2005): bips Publikation A113 / 2005 - Fordeling af projekterings-
ydelser 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 refe-
rencesystem, 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 specifica-
tions, Knowledge Acquisition 5, pp. 199-220.
ISO (2001): ISO 12006-2:2001(E). Building construction – Organisation of
information about construction works – Part 2: Framework for classifi-
cation of information.
ISO (2009): ISO/FDIS 29481-1: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, Vol-
ume 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: http://www.mindtools.com/brainstm.html
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:
http://online.wsj.com/article/SB115015518018078348.html
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:
http://www.businessweek.com/innovate/content/jul2006/id20060726
_517774.htm
34 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Sørensen, K.B. (2009): Virtual Models Linked with Physical Components in
Construction, DCE Thesis, Aalborg University. Tilgængelig online:
http://vbn.aau.dk/files/55290157/Virtual_Models_Linked_with_Physic
al_Components_in_Construction.pdf
Vico Software (2012): Model Progression Specification: On-line artikel på:
http://www.vicosoftware.com/model-progression-specification
W3C (2007): Web Ontology Language (OWL), W3C, Semantic Web,
tilgængelig online: http://www.w3.org/2004/OWL/#papers
35 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Bilag A Udviklingsmetode
A.1 Indledning
I dette bilag beskrives metoderne, der ligger bag udviklingen af informati-
onsniveaumetoden, 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” (Gru-
ber, 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 informationsniveauprojek-
ter 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 me-
tode til udvikling af ontologier, hvilket på mange områder omfatter de
samme udfordringer og problemstillinger, som udviklingen af informations-
niveauer. 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 udviklings-
proces har metoden været anvendt og er blevet prototypetestet samt til-
passet af projektdeltagerene i forbindelse med udviklingen denne metode-
beskrivelse.
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 in-
formationsniveau 2. Overvej at genbruge eksisterende klassifikationsstrukturer, meto-
der og specifikationer 3. Oplist vigtige termer, der skal indeholdes i definitionerne 4. Beskriv de overordnede definitioner af informationsniveauer inden-
for gyldighedsområdet 5. Definer forekomster af bygningsdelstyper pr. informationsniveau 6. Definer informationsniveauer for delsystemer eller grupper af
komponenter
36 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
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 eksem-
pler. 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 re-
sultat, 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 udviklingsmeto-
den.
A.2 Step 1 - Fastlæg og beskriv gyldighedsområdet
Det anbefales at starte udviklingen af informationsniveauer med at fast-
læ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 infor-
mationsniveauerne, men det vil alligevel være en hjælp til afgrænsning og
præcisering af de udviklede definitioner eksplicit at formulere et gyldig-
hedsområde.
Eksempel
Som et eksempel kan gyldighedsområdet fastlægges til resultatområdets 4
grupper af egenskabsdata: produkt-, placerings-, formegenskaber og græn-
sefladegenskaber for bygningsobjekter, det vil sige rum og bygningsdele.
Formålet og dermed anvendelsen kan fastlægges for de 6 informationsni-
veauer som herunder:
Informationsniveau Formål
1 Anskueliggøre
Kommunikere
Evaluere
Koordinere
Ideer og løsninger Ideer og løsninger Ideer og løsninger Ideer og løsninger
2 Anskueliggøre
Kommunikere
Løsningsforlag projektniveau
Løsningsforlag projektniveau
37 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Evaluere
Koordinere
Løsningsforlag projektniveau
Løsningsforlag projektniveau
3 Anskueliggøre
Kommunikere
Evaluere
Koordinere
Løsningsforlag systemniveau
Løsningsforlag systemniveau
Løsningsforlag systemniveau
Løsningsforlag systemniveau
4 Anskueliggøre
Kommunikere
Evaluere
Koordinere
Bygbare løsninger
Montageforslag
Bygbare løsninger
Montageforslag
Bygbare løsninger
Montageforslag
Grænseflader
Tolerancer
5 Anskueliggøre
Kommunikere
Evaluere
Koordinere
Bygbare detailløsninger
Fremstillingsmetode
Bygbare detailløsninger
Fremstillingsmetode
Bygbare detailløsninger
Fremstillingsmetode
Grænseflader
Tolerancer
6 Anskueliggøre
Kommunikere
Evaluere
Koordinere
Bygbare detailløsninger
Fremstillingsmetode
Datagrundlag for automatisk
produktion
Datagrundlag for fremstil-
lingsmetode
Grænseflader
Tolerancer
De problemstillinger, som ønskes løst, kunne være udfordringer med afkla-
ring 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 anven-
delsen af de definerede informationsniveauer. Disse spørgsmål vil være
nyttige at anvende i en første evaluering af de udviklede informationsni-
veauer.
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?
38 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
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 informa-
tionsniveaudefinitionsarbejdet ikke færdigt.
A.3 Step 2 - Overvej at genbruge eksisterende klassifika-tionsstrukturer, 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, buil-
dingSMART- og AIA-publikationer og -arbejdsmetoder:
bips CAD-manual 2008 (bips, 2008a)
AIA E202–2008 – BIM Protocol Document (AIA, 2008)
Bips objektstruktur 2008 (bips, 2008b)
bips A113 - Fordeling af projekteringsydelser og ansvar ved leve-rance 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 informati-
onsniveauerne. I den videre udvikling vil det ligeledes være vigtigt at af-
dæ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 fast-
lagt i step 1, er næste skridt at opliste vigtige termer, der skal være inde-
holdt 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 egenskabsda-
ta, det drejer sig, om samt hvad de skal bruges til.
Denne oplistning af termer kan med fordel gennemføres som en brainstor-
ming-session blandt projektdeltagerne i den gruppe, som fastlægger infor-
39 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
mationsniveauerne inden for et givent gyldighedsområde. Der findes flere
metoder og gode råd vedrørende gennemførelse af en god brainstorming-
session, se f.eks. (Mindtools, 2012; Sandberg, 2006; Sutton 2006).
Nedenstående Figur 22 viser et kort eksempel på begyndelsen af en brain-storming omkring det overordnede indhold i informationsniveauerne, og kan anvendes som inspiration til at brainstorme videre fra:
Resultatet af brainstormingen vil fungere som en vigtig tjekliste for, om det
fra starten ønskede indhold og omfang kan rummes i de informationsni-
veaudefinitioner, som bliver fastlagt i de efterfølgende step.
Dette arbejde må ikke undervurderes. En mulig succes for informationsni-
veaumetoden kræver en terminologi, der på den ene side er tilstrækkelig
omfattende og entydig til, at den kan udnyttes som aftalegrundlag i bran-
chen. Omvendt må termerne ikke fremstå kunstige for branchens aktører.
A.5 Step 4 - Beskriv de overordnede definitioner af in-formationsniveauer 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 bygnings-
objekter får en fælles referenceramme, så der på tværs af fagområder op-
nå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 informati-
onsniveauer er udfyldt, vil der typisk være behov for en række iterationer.
Udvikles informationsniveaudefinitioner inden for grupper af egenskabsda-
ta eller processer opstilles på tilsvarende vis 6 informationsniveauer. Det
kan f.eks. omhandle afklaring af udførelsesmæssige forhold, tidsplanlæg-
ning eller kvalitetssikring m.v.
Figur 21: Eksempel på begyndelsen af brainstorming session om termer relevante for informa-tionsniveauer.
40 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Det er her værd at bemærke, at både det første og sidste informationsni-
veau udgør yderpunkter med henholdsvis det lavteste omfang af informati-
oner og det største omfang og detaljeringsniveau, hvorfor det i mange pro-
jekter vil være de fire midterste informationsniveauer, som vil være af inte-
resse.
I tabellen herunder er illustreret med et eksempel på, hvordab informati-
onsniveauer kan fastlægges på et overordnet niveau for bygningsobjekter
generelt. Som eksempel bruges informationsniveau 3. Funktionskrav om-
handler, 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
Forsyning
Performance
Areal & Volumen
Eksisterende forhold
Kvalitetssikringskrav
Udførelsesforhold
Kvalitetssikringskrav
Sikkerhed
Driftskrav
Grænseflader
Certificering
Sikkerhed & sundhed
Primære bygningsd. | Niv 3
CCS
Infrastruktur | specifik
Hovedsystemniveau
Rum | Zone | Brutto | Netto
Hovedsystemniveau
Hovedsystemniveau
Hovedsystemniveau
Hovedsystemniveau
Hovedsystemniveau
Hovedsystemniveau
Hovedsystemniveau
Hovedsystemniveau
Hovedsystemniveau
Produktegenska-
ber
Bygningsdelstype
Rumtype
Materialer
Udstyr
Inventar
Udførelsesforhold
Specifikation | Niv 3 CCS
Funktion og zone
Delsystemniveau
Type | Armaturer
Type | Fast inventar
Hovedsystemniveau
Placerings-
egenskaber
Bygning
Rum
Bygningsdele
Mål
Relation til modulsystem
Eksakt lokalisering og oriente-
ring
Eksakt placering | Niv 3 CCS
Detailmål | Delsystemniveau Formegenskaber Bygning
Rum
Bygningsdele
Sammensatte BD
Komplekse tværsnit
Armatur og udstyr
Fast inventar
Specifik ydre geometri
Eksakt form
Eksakt facon og profil | Niv 3
CCS
Solid repræsentation
Omsluttende tværsnit
Symbolsk repræsentation
Symbolsk repræsentation
Grænseflade-
egenskaber
Samlinger
Udsparinger
Tolerancer
Primære bygningsd. | Niv 3
CCS For hovedføringsveje
Systemniveau
41 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Ambitionen med ovenstående eksempel er ikke, at præsentere et sæt fær-
digt udviklede informationsniveauer, men derimod at eksemplificere hvor-
dan 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æk-
kelige 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 illu-
streret anvendes farvekodning til at indikere om en bygningsdel er inde-
holdt i projektmaterialet på et givent informationsniveau. Nogle bygnings-
dele 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.
42 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
A.7 Step 6 - Definer informationsniveauer for delsyste-mer 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 genta-
ge mange ensartede definitioner udarbejdes informationsniveau definitio-
nerne på delsystemer eller grupper af komponenter med sammenfaldende
Figur 22: Eksempel på fastlæggelse af forekomster af bygningsdele pr. informationsniveau.
43 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
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.
44 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Fastlæggelse af egenskabsdata, samt hvilke egenskabsdata, der skal inde-
holdes i informationsniveauerne, kan blive en omfattende opgave at gen-
nemføre. Derfor kan det være hensigtsmæssigt i første omgang at gennem-
fø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 byg-
gebranche 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 sy-
stematisk brug af CCS giver for en langt mere effektiv produktion i fremti-
den. 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 be-
skrevne step er endvidere udarbejdet med henblik på, at et projekt benyt-
ter leverandørdefinerede objekter som input i en bygningsmodel, og der-
med bør specificeres, hvilke informationer leverandøren behøver fastlagt
for sin produktion af bygningsdelen.
A.8 Step 7 - Definer egenskabsdata for hvert informati-onsniveau
Skemaet, der er vist i Figur 26 anvendes til at fastlægge hvilke egenskabsda-
ta, der er indeholdt i hvert informationsniveau. Her anføres i de blå felter
om en given egenskab er skitseret eller specificeret på hvert informations-
niveau. 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 indi-
keres med de grå felter. Det er desuden vigtigt, at der er overensstemmelse
mellem skemaerne for egenskabsdata og definitionerne af informationsni-
veauer 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 egen-
skabsdata, der er indeholdt i specifikationen af et vindue i IFC 2x3. IFC spe-
cifikationen vil for mange bygningsdele være tilstrækkelig som udgangs-
punkt for en egenskabsdataliste, og anbefales brugt som udgangspunkt, ind
til cunecos udviklingsprojekt omhandlende egenskabsdata er færdigt. Obli-
gatoriske egenskabsdata markeres i skemaet med en *.
45 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
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 egenskabsda-
ta og deres tilladelige værdier. Dette er som illustreret i Figur 27 en omfat-
tende 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 specifice-
res. 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 informationsni-
veauer ved udviklingen af best practice templates for leverancespecifikati-
oner.
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 *.
46 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
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 au-
tomatiske ræsonnementer i forbindelse med projektopfølgning eller auto-
matisere kvalitetssikrings- og valideringsprocesser.
For hver egenskab bør der også fastlægges relevante intervaller for tillade-
lige 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 forefin-
des 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 informationsni-
veaudefinitioner 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 informationsudveks-
linger mellem forskellige aktører i byggebranchen. Desuden tegnes og 3D-
modelleres 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 informationsni-veauer. Beskrivelsen skal ses som en eksemplificering og er ikke en fyldest-gørende beskrivelse af tilstrækkelige informationer pr. informationsniveau.
Figur 26: Eksempel på egenskabsdata relationsskema.
47 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Figur 27: Tidlig afprøvning af specificering af fire informationsniveauer for et vindue.
A.11 Opsummering af udviklingsmetode
Det er gennem en successiv udviklingsmetode i 9 step beskrevet, hvordan
informationsniveauerne fastlægges, og der er givet en række anbefalinger
til, hvordan der opnås en brugbar metode. Efter at have læst, fulgt og brugt
reglerne og vejledninger beskrevet gennem denne rapport, er der en ting,
det er vigtigt at huske: ”Der findes ikke én enkelt rigtig informationsniveau-
definition for et gyldighedsområde.” At skabe gode informationsniveau-
definitioner er en kreativ proces, og ikke to definitioner fastlagt af forskelli-
ge personer vil give det samme resultat. Derfor er det vigtigt i et fælles pro-
jekt for den danske byggebranche som cuneco, at få fastlagt en de facto
standard, der kan bruges i de fleste projekter og samarbejdsformer.
48 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Bilag B – Termer og definitioner
Agil systemudviklingsmetode: Er en fællesbetegnelse for en række soft-
wareudviklingsmetodikker, hvor vægten ligger på løbende at levere værdi
til kunden gennem iterativ udvikling. Dvs. måder at planlægge og kontrolle-
re softwareudvikling, hvor man hurtigt kan levere en ny version af soft-
waren, når der kommer ændringsønsker fra slutbrugerne. Extreme Pro-
gramming og Scrum er eksempler på agile metodikker, mens vandfaldsmo-
dellen er modsætningen til agile metoder (Wikipedia).
Bygningsobjekt: Objekt relevant for byggebranchen (oversat efter ISO
12006-2), f.eks. et rum, en plads eller en bygningsdel.
Bygningsdel: En fast (dvs. ikke flydende eller på gasform) materiel del af en
bygning, der har en fysisk afgrænsning (oversat efter ISO 12006-2, construc-
tion entity part).
Data: Faktuel information (såsom målbarbare værdier eller statistik) brugt
som grundlag for ræsonnement, diskussion, eller beregning (oversat efter
The Merriam-Webster Dictionary).
Delsystem: Bygningsdel med selvstændig egenfunktion som udgøres af en
samling af indbyrdes tilpassede komponenter og eventuelle andre delsy-
stemer.
Domæne (engelsk domain): En sfære af viden, indflydelse eller aktivitet
(oversat efter The Merriam-Webster Dictionary).
Egenskab: En kvalitet eller et karaktertræk ved en ting (objekt) eller en ind-
virkning et objekt kan have på et andet eller dets betydning (oversat efter
Merriam-Webster Learner’s Dictionary).
Egenskabsdata: Data om egenskaber ved objekter.
Egenskabsdatasæt: Gruppering af egenskabsdata.
Hovedsystem: Bygningsdel med selvstændig egenfunktion betragtet som
en samlet helhed af delsystemer og/eller komponenter.
Information: Fakta eller detaljer om et emne (oversat efter Merriam-
Webster Learner’s Dictionary).
Informationsniveau: Omfang, konkretiserings- og detaljeringsniveau for
informationer om bygningsobjekter.
49 Metode og struktur for informationsniveauer · cuneco · 2012-11-15
Klasse (engelsk: class): En gruppe, sæt, eller slags (objekt) med fælles egen-
skaber (oversat efter The Merriam-Webster Dictionary).
Komponent: Bygningsdel med selvstændig egenfunktion som kan samles til
større helheder.
Ontologi: Eksplicit specifikation af koncepter og relationen i mellem dem
(Gruber, 1993).
Objekt (fysisk). Noget der kan opfattes af en eller flere sanser, specielt
syns- eller følesanser, en materiel genstand (Oversat efter The Free Dicti-
onary by Farlex).
Objekt (digitalt): En datastruktur i objekt-orienteret programmering (eller
bygningsmodellering), som kan indeholde funktioner, data, variable og an-
dre datastrukturer (Oversat efter The Merriam-Webster Dictionary).
System: En gruppe af samvirkende, sammenhørende eller indbyrdes af-
hængige elementer (objekter), der former en kompleks helhed (Oversat
efter The Free Dictonary By Farlex).
top related