• No results found

Kartläggning

In document Nyttan av ICT för byggbranschen (Page 109-119)

Inledning

Denna kartläggning ger en bakgrund till avsnitten längre fram i rapporten, där objekt och relationer mellan objekt behandlas. Nedan visas ett antal olika grupperingar av dokument i ett byggprojekt, hur dokumenten skapas och i vilket syfte. Avsnittet därefter hanterar olika överföringsformat och deras relation till dokumenttyperna.

Alla typer av dokument Fristående dok. Kalkyl, Presentation Fristående dok. Struktur. dok. CAD, Beräkn. Lägenhets Köpare/Brukare Bestäl Produ lare ktutveckl. Arkitekt Konsult Totalentreprenör Ma Undere teriallev. ntrepr. Fristående dok. Struktur. Dok. Grovt definiera förutsättningar Fristående dok. Struktur. dok.

CAD, Beräkn. Definiera produktions förutsättningar Sälja / Köpa Bestämma utformning Alla typer av dokument Ställa krav Producera Alla typer av dokument Fristående dok. Kalkyl, Presentation Fristående dok. Struktur. dok. CAD, Beräkn. Lägenhets Köpare/Brukare Bestäl Produ lare ktutveckl. Arkitekt Konsult Totalentreprenör Ma Undere teriallev. ntrepr. Fristående dok. Struktur. Dok. Grovt definiera förutsättningar Fristående dok. Struktur. dok.

CAD, Beräkn. Definiera produktions förutsättningar Sälja / Köpa Bestämma utformning Alla typer av dokument Ställa krav Producera

Figur 1 Förekommande dokumenttyper i projektet, i vilka processer dokumenten produceras och vem som gör det.

Behovet av att hantera informationen i projekten som objekt och relationer mellan objekt tydliggörs om man sätter projektets dokument i relation till objekten. Kartläggningen avslutas med en lista över de mest aktuella nor- diska initiativen för ökat informationsutbyte inom byggprojekt.

Förekommande dokumenttyper

Fristående dokument

Avtal (utom de som omfattas av e-handel) och korta dokument av alla slag som inte bygger på en gemensam klassifikation, produceras i dag i ordbe- handlingsprogram (Word), kalkylark (Excel), presentation (Word och Po- werPoint) etc. Dessa och liknande dokument utgör normalt kittet i projek- tet, de finns och behöver finnas men innehåller sällan något av relevans för informationsmodellen annat än att dokumentet i sig är refererat.

Strukturerade dokument (med eller utan legal status)

Strukturerade dokument är dokument som bygger på en generell klassifika- tion. Exempel på sådana dokument är tekniska beskrivningar, byggbeskriv- ningar, rumsbeskrivningar m.fl. Innehållet i dessa dokument är i allmänhet starkt knutet till de ritade objekten i CAD-systemen. Dokumenten inne-

108 Nyttan av ICT för byggbranschen

10 Informationsstrukturer för samverkan i byggprojekt

håller information som bestämmer utförande och i en del fall specifika pro- dukter. De beskriver ett antal vyer av samma informationsmängd och har relationer till varandra och till ev 3D-modeller. Dokumenten är av olika typer och har vanligen sin utgångspunkt i klassifikationen, i de definierade utrymmena eller i definierade system av utrymmen eller tekniska system. Ett genomgående problem är att samma uppgifter ofta presenteras på olika sätt i olika dokument. Detta är en av de största felkällorna i informations- flödet i den svenska byggprocessen. Felen bygger på att dokumenten ofta är producerade i ordbehandlingsprogram där det inte är praktiskt möjligt att skapa referenser till den bakomliggande informationsmodellen. Därigenom förstörs möjligheten att använda klassifikation och ingående datamängder på ett rationellt sätt i det fortsatta projektarbetet.

Bristen på definierade informationsstrukturer för dessa dokument har in- neburit att utvecklingen har försvårats och att applikationer som kan hante- ra dokumentens informationsstrukturer därmed ej utvecklats. Med det per- spektivet är det naturligt att det också saknas format för överföring av dessa informationsstrukturer. I arbetet med bygghandlingar 90, del 8, har ett del- avsnitt ägnats åt att se på informationsstrukturer i dokumenten.

CAD – Computer Aided Design

På senare år har 3D-modellering fått ett allt större insteg i CAD-använd- ningen i byggsektorn. Ur de tredimensionella objektmodellerna genereras traditionella ritningar.

Dwg-formatet från Autodesk är det absolut vanligaste formatet för att flytta information mellan olika CAD-applikationer. Överföringarna förut- sätter ofta att dwg-filen enbart innehåller enkla grafiska objekt såsom punk- ter, linjer, texter m.m. När branschen nu i allt högre utsträckning använder sig av objektorienterade modeller kan inte dwg-formatet användas på sam- ma sätt. Vill man flytta en objektsmodell från en CAD-applikation till en annan och behålla modellen intakt med objekt, egenskaper och relationer hänvisas man till format av typen IFC. Inte ens inom samma applikations- familj är modellerna kompatibla. Inom VVS området finns t.ex. applikatio- nerna MagiCAD och ABS (Autodesk Building Systems) för projektering av ventilations- och röranläggningar. Båda har AutoCAD som grundsy- stem, men de objekt som skapas i MagiCAD kan inte samverka med objek- ten som skapas i ABS eftersom objektsmodellerna inte är kompatibla.

Den senaste trenden bland CAD-användarna tyder på att man blickar mot 3D-CAD. Detta är tydligast bland teknikdisciplinerna (Vent, VS, El) som har ett behov att tydliggöra sina delsystem i tre dimensioner, dels för att redovisa de apparater, don m.m. som används, dels för att kunna använda CAD i mängdning, produktionsplanering mm. 3D-tekniken möjliggör ock- så automatisk beräkning av flöden, kollisionskontroller, hantering av instal- lationer i undertak samt installationssamordning.

Inom arkitektbranschen har framförallt de större företagen påbörjat resan mot 3D-CAD. Det som styr är att inom den ram man arbetar, försöka att höja kvaliteten på de ingående delarna samt att försöka uppnå skalfördelar genom att nyttja informationen i modellen till mängdberäkningar och till- lämpningar kring kalkyl och mängd. Ett av de oftast anförda argumenten för 3D-CAD är att man i relativt tidiga skeden kan ta fram en helhetsbild på utseende, funktion och kostnader. En förutsättning för detta är att mängd-

109 Bilaga 

Kartläggning 11

ning av ingående detaljer sker mer eller mindre automatiskt samt att relatio- ner mellan ritade element och ingående material och aktiviteter finns repre- senterat, antingen i CAD-systemet eller i en relaterad kalkylapplikation. Ett initiativ för att underlätta kopplingen har tagits av företaget TOCOMAN som har utvecklat en tilläggskomponent där 3D-modeller från ArchiCAD (GraphiSoft) eller ADT (Autodesk) kan kopplas till kalkylapplikationer som MAP (Skandinaviska Kalkyldata) eller BIDCon (Consultec).

Försök görs även för att öka samverkan mellan arkitektens och konstruk- törens modeller, detta för att undvika fel vid hanteringen av geometri- och konstruktionsändringar.

I olika projekt har det gjorts försök med att i en och samma databas samla ett byggnadsverks samtliga objekt och egenskaper som kan beskriva hela livscykeln. Denna typ av modeller kallas oftast för BIM-modeller (Building Information Model). Svårigheten ligger i att antalet objekt, egenskaper och relationer blir mycket stort om samtliga byggdelar i t.ex. ett bostadshus skall ingå. En mer framkomlig väg är troligtvis att hantera flera olika data- baser med goda möjligheter till överföring av information mellan dessa. Som komplement kan man även tänka sig modellservrar där förutbestämd information sparas i ett neutralt format, som kan granskas via s.k. model- viewers. Här kan man tänka sig modeller för installationssamordning, han- tering av undertak, håltagningsmodeller samt samordning av A och K.

Om man vill överföra objektsdata eller 3D-information på ett standardi- serat sätt är det idag möjligt att, antingen direkt eller via någon komponent, spara modellen i IFC-format, så att den kan tolkas av andra 3D-CAD appli- kationer som kan hantera IFC. I Norge och Danmark pågår projekt som skall leda till någon form av nationell standard för BIM.

CAM – Computer Aided Manufacturing

Datorstödd tillverkning har funnits i många år inom tillverkningsindustrin och innefattar styrning av NC-maskiner, robotar, traverser, transportband m.m. Inom byggbranschen är tekniken väl utbredd hos byggmaterialprodu- centerna. När det gäller tillverkning av större byggnadselement är tekniken mer sällsynt. Enstaka exempel finns inom småhusindustrin där datorstödd tillverkning av bjälklag och ytterväggar förekommer. Även inom prefab- industrin finns exempel på datorstödd tillverkning. Här kan nämnas Peabs elementfabrik i Katrineholm, en av de mest avancerade elementfabrikerna i Sverige.

När man går från projektering/design till tillverkning följer CAM- applikationen som ett naturligt steg efter CAD-applikationen. Från CAD- modellen hämtas oftast enbart geometrin medan man i CAM-applikationen tillför (bereder) den information som behövs vid tillverkningen. Exempel på sådan information är styrdata, materialval, litterering, val av bearbet- ningsverktyg och bearbetningshastighet. CAD- och CAM-modulerna kan vara mer eller mindre integrerade med varandra. För att en avancerad fabrik ska fungera krävs förutom CAM-systemen även MPS-system (Material- och produktionsstyrning). Dessa system används för att planera att logisti- ken avseende resurser – maskiner och arbetskraft – och råmaterial fungerar vid tillverkningen.

Som ett exempel från byggbranschen kan vi beskriva hur processen ser ut vid användandet av Impact från Strusoft för konstruktion av prefabelement.

110 Nyttan av ICT för byggbranschen

12 Informationsstrukturer för samverkan i byggprojekt

Impact är en tilläggsapplikation till ADT. Själva produktmodellen avseende betongelementet lagras i en relationsdatabas. Arkitektens modell läses in i ADT/Impact och den geometriska informationen används för att skapa betongelementets produktmodell. När modellen är klar väljer man sedan vilken fabrik som ska tillverka elementen och styrfiler genereras för pro- duktionen. Vill man även ha traditionella tillverkningsritningar fås dessa som projektioner ur databasen.

Mängd – Kalkyl – Livscykel

Mängdberäkningsprogram och de mer utvecklade kalkylprogrammen var de första applikationer inom byggprocessen som på ett samordnat sätt han- terade överföringar och överföringsformat. SBEF-formatet var ett initiativ under tidigt 80-tal mellan mängdberäkningsföretagen (främst Bygganalys och Mängda) och de olika entreprenörerna, för att reducera tiden som åt- gick för att lämna anbud. En neutral part räknade mängder, med större nog- grannhet än tidigare, och ett antal köpare tid- och prissatte de köpta mäng- derna. Formatet som togs fram var direkt knutet till de applikationer som entreprenörerna använde, dvs. informationsmängderna passade perfekt till kalkylprogrammen. Detta innebar att källan som genererat informationen var känd och verifieringen av mängderna kunde göras genom stickprovs- kontroll. Antalet mottagande applikationer var begränsat och att kunna hantera formatet var ett säljargument för applikationstillverkarna. I mitten av 90-talet ökade kraven på kalkylapplikationernas informationsinnehåll och SBEF-formatet tappade fart. Materialets tillförlitlighet ansågs inte läng- re lika bra. För att åtgärda detta skapades formatet sbXML som nu är im- plementerat och kan distribuera de informationselement som behövts eller bedömts kunna komma att behövas. Trovärdigheten i den överlämnade informationen har dock långt kvar till de nivåer som fanns i början av 90- talet.

Mängd och kalkylprogram används mycket frekvent inom bygg. I de di- scipliner som använder 3D-CAD och i hög grad är komponentbaserade, t.ex. ventilation, sker den mesta mängdningen och kalkyleringen i, eller i direkt anslutning till, CAD-verktyget.

Information från mängd- och/eller kalkylprogrammen kan användas som indata till olika former av livscykelberäkningar, både LCC, livscykelkost- nad och LCA, livscykelanalys (i Sverige beräknas miljöpåverkan enligt de svenska miljömålen).

Dessa ”kalkylprogram” tar hänsyn till hela objektets livslängd och till både drift och underhåll. Om man skall arbeta med drift och underhåll re- dan i projekterings- och byggfaserna krävs att egenskaper redovisas i vä- sentligt högre grad för de ingående byggdelarna, systemen och varorna.

Produktionsplanering

Planeringsprogram har funnits en lång tid. Under de senaste tio åren har dessa applikationer kommit att integreras i hög utsträckning med kostnads- kalkylprogrammen. Denna nära koppling kommer sig av att planerings- applikationen har fått kalkylens sammanställningar av resurser och resurs- åtgång som indata, det är också i stort sett ”samma” projektroller som an- vänder både kalkyl och planeringsprogram. Vid en ökad industrialisering av processen kommer behovet av att kommunicera med externa parter att

111 Bilaga 

Kartläggning 1

öka. I kostnadskalkylen är elementtillverkningen en enkel kostnadspost medan för tidplaneringen så måste ett flöde av information gå mellan par- terna för att få kontroll på alla ingående aktiviteter.

Beräkningsprogram

Med beräkningsprogram menas applikationer som används i byggprocessen för att utföra beräkningar av t.ex. energiåtgång. För att dessa program skall kunna köras krävs att ett antal parametrar skall registreras. I allmänhet är dessa parametrar egenskaper eller funktioner av egenskaper hos element (byggdelar) och varor.

Gb-xml och ifc-modellen ger möjlighet att definiera förutsättningar för att stärka sambanden mellan beräkningsprogrammen och applikationer som innehåller den data som behövs för beräkningarna. I dag är de flesta beräk- ningsprogram mer eller mindre fristående.

I casestudien användes förenklade beräkningsprogram för att bl.a. beräk- na energiåtgång (e-norm) och ljudegenskaper.

e-Handel

E-handel berörs endast perifert. Det används främst i produktionsskedet och bygger på att vissa av de varor som behövs i entreprenaden beställs, avise- ras och faktureras via standardiserade gränssnitt (format). Det som för detta uppdrag kan anses vara viktigt är hur byggdelar och resurser under proces- sen kläs på med klassifikationer och identifikationer för att underlätta e- handeln. E-handel inom byggbranschen i Sverige definieras främst av BEAST (Bygg- och Fastighetssektorns Elektroniska Affärsstandard,

http://www.beast.se/)

Presentation

Delresultat, sammanställningar och annat presenteras i ett flertal olika ap- plikationer. För presentation inför publik används ofta PowerPoint, för annan typ av presentation används de olika MS-office programmen och resultaten distribueras ofta som pdf-filer (Adobe Acrobat). I övrigt gäller att material för presentation hanteras på samma sätt som resultat från fristående program.

Överlämning

I projektnätverk utväxlas dokument mellan projektdeltagarna, s.k. ”Colla- boration Support”. Projektnätverken hanterar dokumenten och i vissa fall dokumentens metadata. Problematiken i utväxlingen är inte informationsö- verlämnandet i sig utan hanteringen av informationens kvalitet och kvanti- tet och att upprätta ”guidelines” och olika verifieringssteg för att säkerställa kvaliteten.

112 Nyttan av ICT för byggbranschen

1 Informationsstrukturer för samverkan i byggprojekt

a-

Överföringsformat

Fi2XML

Framtaget av Föreningen för förvaltningsinformation (startade under ITBOF:s regi). För närvarande gäller version 1.2.1

Formatet är framtaget för att hantera överföringar av informationsmängder från produktionsskedet till förvaltningsskedet, samt att hantera informationsöverföring inom för- valtningsskedet. Formatet bygger i stort på att gemensamma inform tionsmängder är definierade samt att generella modeller för hur informa- tionsmängdernas inbördes relationer i specifika situationer är definierade. Formatet har åtminstone till en början endast få definierade dokument, så- dana skall skapas och dokumenteras i samband med implementering. Posi- tivt kan sägas vara friheten att skapa dokumentrelationer baserade enbart på behovet, en av de största nackdelarna är att många meddelanden kan defini- eras med i princip samma syfte och detta kan i sin tur leda till att det skapas ”dialekter” av fi2xml beroende på vilka applikationsleverantörer som har skapat dokumentet. Formatet är främst avsett för att hantera mer eller mind- re operatörslösa meddelandeflöden.

sbXML

Framtaget i sin första form som en del av ITBOF. Nuvarande version i produktion är 1.9.2

Formatet används för att skicka mängdinformation och/eller kalkylinformation inom och mellan mängdavtagningsapplika- tioner och kalkylapplikationer. De flesta kalkylapplikationerna (bla MAP, BidCon, SPIK och Wikells byggberäkningar) hanterar sbXML både i ex- porter och importer. Det finns också applikationer som läser sbXML-filer som indata, bl.a. livscykelanalysapplikationen ANAVITOR.

sbXML-formatet hanterar informationsstrukturen inom avsedd doku- mentfamilj på ett strukturerat sätt (följer klassifikationen) samt refererar fördefinierade kodlistor för att verifiera informationens kodning. Formatet är i drift sedan ett par år tillbaka och fungerar relativt bra för de syften som det tagits i bruk för. För mängd- och kalkylapplikationer har det tagits fram ett regelverk för hur informationsmängderna skall hanteras. Vid framtag- ningen av sbXML togs stor hänsyn till att befintliga informationsmängder skulle kunna hanteras utan större ändringar för de applikationer som fanns på marknaden. Ambitionerna med överföringsformatet var långt större än det utfall som användningen fått.

Fördelar med formatet är att dokumentstrukturen är styrd men att inne- hållet blir verifierbart med hjälp av kodlistor. En nackdel är att formatet behöver tilläggsdefinitioner för att hantera nya användningsområden. For- matet hanterar i stort sett endast de informationsmängder som de tilltänkta applikationerna behöver.

IFC

IFC (Industry Foundation Classes) är ett format med vars hjälp man kan beskriva byggnadsverk under hela dess livscykel.3 IFC:s ramverk består av 1http://www.fi2.se/

2 Dokumentation om formatet kan hittas på www.akej.se/sbxml

11 Bilaga 

Kartläggning 1

ett antal objektklasser som har inbördes relationer. Till objekten knyts olika egenskaper (property sets). Egenskaperna kan geometriska eller icke geo- metriska. IFC innehåller även ett format för överföring av information mel- lan produktmodeller skapade i olika IT-applikationer. Detta innebär att IFC-objekten måste kunna tolkas av de olika applikationerna. De ska vara s.k. interoperabla.

Uppbyggnaden av IFC i form av objektsmodeller gör att formatet (oavsett typ av presentation) blir extremt flexibelt men också i samma mening näs- tan omöjligt att uttolka, utan ett mycket väl definierat regelverk. Svagheten i tillämpningen av IFC ligger bl.a. i modellernas komplexitet och ambitio- nen att greppa över samtliga objekt som kan förekomma inom ett bygg- nadsverks hela livscykel.

Många anser idag att IFC:s definitioner och format bör vara grunden för det som man benämner BIM (Building Information Model), som man kan se exempel på i det danska initiativet ”Det digitale byggeri”.

Det bör särskilt påpekas att IFC inte utgår från någon av dagens etablera- de klassifikationer. IFC har i någon mån istället integrerat objekten i en egen klassifikation.

IFC kan representeras i två format, dels det ursprungliga textbaserade (”native”), dels ifcXML som är IFC-formatet uttryckt i XML-form. I ver- sion 2x av IFC specificerades ifcXML. Denna standard definierar IFC- modellen i form av ett XML-schema och är ett alternativ till hur IFC-data kan flyttas mellan olika applikationer.

gbXML

gbXML (green building eXtensible Markup Language), är ett standardiserat format som tillhör IFC-familjen och som hanterar information om miljöre- laterade egenskaper för byggnadsverk.4 gbXML medger en detaljerad be-

skrivning av byggnadsverk för att möjliggöra avancerade energi- och re- sursanalyser. Analyserna kan bidra till bestämningen av byggnadens ”mil- jöindex”, förvaltningskostnader, energibehov, miljöpåverkan samt påver- kan på människors hälsa. Formatet medger avancerat informationsutbyte mellan t.ex. applikationer för energianalyser och objektorienterade CAD- applikationer.

Tocomans iLink

Tocomans iLink är ett tilläggsprogram för 3D-CAD.5 iLink används för att

koppla 3D-CAD systemet till ett kalkylsystem och därigenom få fram mate- rial, tider och priser för det projekt man ritat. iLink kan nu användas med t.ex. ADT (Autodesk Architectural Desktop), ArchiCad och sedan skicka mängdinformation till BidCon, MAP eller något annat kalkylsystem.

Informationsutbyte

Regelverk

Även om det finns format att hantera informationen i, så behövs en ganska kraftig styrning av informationsinnehållet för att minimera, helst utesluta,

4www.gbxml.org 5www.tocoman.se

11 Nyttan av ICT för byggbranschen

16 Informationsstrukturer för samverkan i byggprojekt

manuell inblandning i transformeringen av data från en applikation till en annan via det använda formatet.

I vissa definierade format kan samma informationsmängd representeras på olika sätt. Sådana tvetydigheter kan orsaka tolkningsproblem. Ju mer komplext ett format är desto större är risken för fel. För att styra upp an- vändningen krävs att aktörerna samlas kring ett regelverk för uttolkning.

Erfarenheter visar att ju fler aktörer, applikationer etc. som är inblandade, desto mindre del av informationen kan uttolkas och därmed användas.

Över tiden har olika typer av överföringsregler/avtal hanterats. I den tidi- ga e-handeln under 80-90-talen användes EDI-formatet. För att över- huvudtaget skapa en relation skrevs det ett överföringsavtal som i detalj beskrev vad som skulle sändas och hur detta var representerat i informa- tionsmodellen. Detta fungerar bra i en ”en till en” relation, och tillräckligt bra i en ”en till många” relation. I byggbranschen existerar ofta en ”många till många” relation. Här kan det finnas olika uttolkningar beroende på vem som kommunicerar med vem samt vilken part som är starkast i förhand- lingarna. För ”många till många” relationer krävs istället att regelverket (”collaboration support”) förs upp till en central roll. Detta upplevs vara hörnstenen i det danska ”Det digitale byggeri”. Balansgången mellan regel- verket och informationsmodellens flexibilitet är en av nyckelparametrarna för att uppnå högre interoperabilitet.

Nordiska initiativ

Det Digitale byggeri

”Det digitale byggeri” är ett danskt initiativ som består av en samling for- mat och regler för hur formatens innehåll skall hanteras i olika situationer.

Det Digitale Fundament: Et fælles fundament af standarder og metoder, så alle parterne i byggeriets værdikæde taler samme digitale sprog, er en nødvendig forudsætning for at digitalisere informationsstrømmene. Det Digitale

In document Nyttan av ICT för byggbranschen (Page 109-119)