Giver import fra EPD-databaser overhovedet mening?

Alle der arbejder med LCA-beregning ønsker sig at kunne suge data direkte fra store, internationale databaser som f.eks. ÖKOBAUDAT. – Men giver det overhovedet mening?

LCA-beregning for bygninger kræver viden om materialernes beskaffenhed, for at regnemaskiner som f.eks. DesignLCA fungerer. Dette er gælder i endnu højere grad for LCA-beregninger, som føler bygningsreglementlementets (BR18) krav. Nogle af disse informationer kan man finde i Environmental Product Declaration – såkaldte EPD’er – men EPD’er har ikke alle de nødvendige informationer til brug for LCA-beregningen, og det samme gælder de fleste offentlige EPD-databaser som f.eks. ÖKOBAUDAT.

Hvilke data har man brug for?

De materiale-informationer man skal bruge for at lave en LCA-beregning, er i første omgang CO2-værdier for de faser man vil medregne på hvert materiale. I forhold til bygningsreglementets LCA-krav er det fase A1-A3, C3, C4 og D. Vil man i fremtiden også medregne transport til byggepladsen, skal fase A4 også indgå. Man skal altid vurdere om værdierne er retvisende, og her kan især fase A4 f.eks. dokumentere transporten fra producentens fabrik til hovedstaden i det land materialet fremstilles og ikke nødvendigvis til Danmark. Man skal vide hvilken enhed CO2-værdierne er opgjort i – f.eks. pr. m2, m3 eller kg – og hvad materialets massefylde (vægt pr. volumen) er.

Angivelse af de LCA-faser, der stilles krav til i BR18. Fase D indgår ikke ved dokumentation af at udledningerne er under grænseværdien, men skal stadig dokumenteres.

Udover CO2-værdierne, skal man i følge bygningsreglementet medregne materialer og bygningsdeles antal udskiftninger (fase B4) gennem beregningsperioden på 50 år. Det kræver at man kender materialets levetid, hvilket ofte ikke fremgår af EPD’er eller bæredygtigheds databaser. I bygningsreglementet har man løst dette ved at vedlægge en generisk levetidstabel, som man kan trække på, når man mangler produktspecifikke data.

Før man er i mål, skal man også beregne energiforbruget (fase B6) til bygningens drift, f.esk. opvarmning, ventilation, køling og lys – og så modregnet energiproduktion fra indbyggede solceller. For at kunne beregne dette, skal man have termiske data på bygningsmaterialerne, som f.eks. U-værdi og angivelse af hvor meget varme materialet lagrer og dermed frigiver når bygningen bliver køligere. Disse informationer indgår ofte ikke i EPD’er, bæredygtighedsdatabaser, i bygningsreglementet eller andre steder, og kan derfor være yderst besværlige at få fat i.

Arbejder man med BIM, under skitsering og projektering, hvor 2D-tegninger, 3D-model, visualiseringer og mængdeudtræk hænger sammen, så skal materialerne også have en retvisende skravering på planer og snit, samt et fotorealistisk “image map” til visualiseringer.

Hvor kommer data fra?

Hvordan gør man så dette? I DesignLCA har vi taget udgangspunkt i bygningsreglementets liste over generiske byggematerialer med tilknyttede CO2-værdier, massefylde og enhed for opgørelsen. Så har vi tilknyttet levetider fra bygningsreglementets tabel og termiske data fra materialelisten fra energiberegnings-softwaren EcoDesigner STAR. Vi har koblet med skraveringer fra Molios tegningsstandarder og så har vi kopieret “image maps” fra andre materialer fra den danske og internationale Template til Archicad. Det er ikke et uoverkommeligt arbejde.

DesignLCA og EcoDesigner STAR i Archicad

Skal du selv oprette nye materialer i DesignLCA – f.eks. på baggrund af produktspecifikke EPD’er, er det en god idé at kopiere et tilsvarende generisk materiale og så ændre de specifikke værdier fra EPD’en. På denne måde får man automatisk kopieret (formentlig retvisende) informationer fra det generiske materiale, som f.eks. levetid, termiske egenskaber, skraveringer og “image map”. Det er nemt, hurtigt og med en lav risiko for fejl eller misvisende materiale-værdier.

Import fra EPD-databaser

Et stort ønske fra almindelige brugere, der arbejder med LCA-beregninger er, at kunne importere EPD-data fra regneark (f.eks. CSV eller Excel) eller endnu bedre, at kunne søge direkte i bæredygtigheds-databaser (f.eks. ÖKOBAUDAT), og så automatisk kunne importere disse data til BIM-projektets bygningsmaterialer. Det kunne være så fantastisk, hvis man kunne dette, men denne metode vil have uoverskuelige udfordringer.

Hvis man importere EPD-data fra f.eks. ÖKOBAUDAT eller Eco Platform, så kan man være ude for, at der er data-felter på nogle materialer, der ikke er udfyldt. Det kan f.eks. være en eller flere faser, der ikke er data for, som producenten har ladet stå tom. Hvis man importerer et sådan materiale med tomme felter på nogle af de faser man skal medregne, medfører det en LCA-beregninger, som er forkert og ubrugelig. Importerer man ikke information om materialets levetid – der ofte ikke indgår i EPD’er – kan man ikke bruge LCA-beregningen før man har fundet disse data andetsteds. Det samme gælder for termiske data til energiberegningen. Nogle EPD-data i databaserne er ikke retvisende på danske projekter, hvilket man også skal være opmærksom på.

Det er næsten umuligt at finde alle disse data samme sted. Derfor er det næsten umuligt at forestille sig, at man bare kan koble sig på en database og så bare importere de informationer man har brug for. Jeg tror ikke, at jeg nogen sinde har set ét materiale, hvor man fra ét sted har kunne finde alle de nødvendige data for at kunne udføre en LCA-beregning som krævet i BR18. Dertil kommer de BIM-tekniske som skraveringer og “Image maps”.

Problemerne er kendt fra LCAbyg

Det samme problem bliver tydeligt, når man læser om udfordringerne ved import fra regneark eller databaser til LCAbyg. I deres FAQ står bl.a.: “

Det er muligt at importere EPDer i LCAbyg via ILCD+EPD formatet (XML). Dette skal ses som en hjælp til at indtaste EPDer i programmet. LCAbyg "læser" de informationer der er i tilgængelige i det digitale XML format og LCAbyg er derfor ikke ansvarlig for, hvis data mangler. Derfor er det brugernes ansvar at sikre sig at den importerede data er korrekt og evt. tilføje manglende data. Der er dog implementeret flere features til at hjælpe med at identificere tomme datafelter. De mest almindelige problemer man kan støde på ved import af EPDer er nævnt nedenfor. […]

Brugerne kan komme ud for at EPDer fra en ellers tilgængelig programoperatør ikke kan indlæses. Dette skyldes manglende data i det digitale format. Desværre betyder dette at brugerne bliver nødt til manuelt at indtaste EPDen ved at oprette de nødvendige faser […]. Mangler der data betyder det at beregningen vil blive forkert, hvis denne data ikke bliver fundet. Derfor skal brugeren finde den data og udfylde eventuelle tomme felter, og derfor vil byggevarer og faser være redigerbare. […] Massefaktoren mangler nogle gange i de digitaliserede EPDer, hvilket ikke er kompatibelt med LCAbyg. Massefaktoren er nødvendig for at LCAbyg kan beregne den korrekte vægt af byggevaren og for at brugeren har mulighed for at opgøre byggevaren i enheden kg. Ofte vil massefaktoren dog være at finde i pdf versionen af EPDen og derfor kan brugeren selv udfylde massefaktoren. Nogle EPDer er kun blevet udført for faserne A1-A3 og har ikke data for EoL tilgængelige. Disse EPDer kan importeres, men vil være oprettet med kilden "Bruger" og der vil være en advarsel om at en byggevare mangler EoL faser. Ønsker man at benytte denne EPD i sin beregning må man oprette generiske EoL faser, der passer til typen af materiale. Disse kan findes i det generiske datagrundlag i BR. […]

Alle de forskellige programoperatører bruger forskellige kategoriseringer og nogle EPDer har ingen kategorisering. Dette er ikke kompatibelt med LCAbygs fase kategorisering. I stedet for ikke at tillade import af disse bliver de tildelt default kategorier. Derfor vil man komme ud for faser, der ikke har retvisende kategorier. Det anbefales at brugeren selv vælger kategorisering for disse EPD, så det er nemmere at finde dem i fremtiden.

Det er altså tydeligt, at import fra XML eller direkte fra opslag i EPD-databaser til LCAbyg kræver ekspertviden, medfører ekstrem høj risiko for fejl og efterfølgende kræver manuelt tastearbejde før man kan lave en LCA-beregning uden fejl. Og LCAbyg indeholder ikke energiberegning eller BIM-modellering, så disse data vil man skulle importere/indtaste udover hvad der er angiet ovenfor. – Det er ikke for sarte sjæle!

Et BIM-baseret LCA-workflow

Hvis man arbejder med BIM og importere et materiale fra f.eks ÖKOBAUDAT, så skal man efterfølgende tilføje skraveringer og “image maps”, samt sikre sig navngivning og måske klassifikation er retvisende. Har man travlt, og skal både have 2D-tegninger, 3D-model, visualiseringer, mængdeudtræk og LCA-beregning til at gå op, kan det være mere tidskrævende at importere data fra regneark eller databaser, end at benytte de indbyggede materialer fra DesignLCA og så erstatte dem – én for én – i takt med man finder nye produktspecifikke materialer op opretter dem på baggrund af EPD-data.

Når man først har oprettet nye materialer, kan de gemmes i ens Template, så de er tilgængelige ved opstart af nye projekter.

Derfor kan man ikke importere EPD-data i DesignLCA

Vi har derfor valgt – indtil videre – ikke at gøre det muligt, at importere EPD-data fra regneark, XML eller databaser til DesignLCA, da vi ikke kan se, at det er godt workflow på rigtige projekter. Det vil måske ændre sig i fremtiden, hvis der kommer databaser, der i højere grad inkluderer alle de nødvendige informationer for at kunne arbejde med LCA-beregning i BIM.

Sidsel Maria Vincents Jansen og Thomas Graabæk står bag DesignLCA, som er udviklet i samarbejde med Lendager arkitekter.

I dag er der ikke mange LCA-beregnere, som beregner direkte på BIM-projektet og vist ikke andre end DesignLCA, som også kan udføre energiberegningen, som jo er et krav i BR18. Så længe, at de fleste der arbejder med LCA-beregning, laver BIM-projektet i ét program, overfører mængderne fra BIM til et andet program (f.eks. LCAbyg, OneClick LCA eller RealtimeLCA) og til sidst udfører en energiberegning/energirammeberegning i et 3. program (f.eks. Be18), så er der måske ikke den store efterspørgsel for at have alle informationer tilgængelige ét sted. Når vi så inkluderer forskellige LCA-faser i forskellige lande, så bliver efterspørgslen efter de nødvendige data til danske projekter i stor nok, til at det kan betale sig for f.eks. ÖKOBAUDAT at stille krav til de EPD-data, de gør tilgængelige i deres database.

Hos GRAPHISOFT Center Danmark har vi helt klart den holdning, at man skal kunne lave en LCA-beregning på sit BIM-projekt uden at gå død i manglende data, der resulterer i et væld af fejlmeddelelser eller forkerte LCA-beregninger. Derfor inkluderer DesignLCA de generiske materialer fra BR18, med CO2-værdier, enheder, termiske data, levetid, skraveringer og “image maps”, så man ikke skal gøre noget særligt, andet end koncentrere sig om at designe sit projekt.

Det virker uden problemer allerede i dag, og så krydser vi fingre for, at der en dag findes et sted, hvor vi kan hente alle de samme data på alverdens generiske og produktspecifikke byggematerialer for både bygning, indretning og landskab. – Den dag står vi klar til at indbygge data-import i DesignLCA!