projekt.
Förutsättningar
När upphandlingsformer och entreprenadformer förändras blir det allt vik- tigare att skapa förutsättningar för att underlätta informationsutbytet i byggprojekt. I och med att fler parter blir ansvariga för projektets ledning, och därmed också för den bakomliggande upparbetade informationen, mås- te informationen göras tillgänglig på så sätt att varje part kan arbeta med de verktyg som passar organisationen bäst. För att nå ett smidigare informa- tionsflöde krävs att fokus flyttas från specifika överföringsformat till hur informationen skall betraktas och tolkas. Generellt kan sägas att formaten är tillräckliga för sitt syfte, det som krävs är att fastställa ett antal kriterier för hur informationen skall betraktas. Genom samstämmighet erhålls en för- bättrad tillit till informationen, som därmed kan användas som ingångsma- terial i nästa process. På detta sätt minskas antalet ”informationsomstarter”.
De punkter som anses nödvändiga för att hanteringen av informationen i en gemensam informationsmodell behandlas görs tillgänglig för merparten av branschens företag.
Dokument och informationsmodell
Allmänt
Informationens relation till dokumenten behöver fastställas. Att ett doku- ment kan vara en ”vy av informationsmängder ur en informationsmodell skapat för ett visst syfte vid en viss tidpunkt” är idag ett relativt accepterat synsätt.
I revideringsarbetet med Bygghandlingar 90, del 8, finns ett försök till att definiera dokumentens relationer till informationsmodellen, med följande delar.
x Dokument genereras ur modeller med hjälp av dokumentdefinitioner, som i sig kan lagras som egna dokument eller utgöra delar av modellen.
x Modeller refererar till statiska dokument för att förmedla information som har relation till modellen utan att vara lagrad som en del av den.
x Modeller refererar till varandra för att ge åtkomst till den samlade in- formationen. Modeller som enbart innehåller en viss typ av informa- tion, t ex ett tekniskt system, brukar kallas för aspektmodeller. Olika aspektmodeller sammanställs med varandra för att visa byggnaden i sin helhet med dess stomme, stomkompletteringar, utrymmen, installatio- ner och omgivande mark.
x Dokument refererar till varandra för att ge åtkomst till den samlade redovisningen. Även referenser utanför den aktuella dokumentationen är vanliga, t ex till föreskrifter, standarder, typlösningar eller produktin- formation.
122 Nyttan av ICT för byggbranschen
2 Informationsstrukturer för samverkan i byggprojekt
För att integrera modellens informationsmängder krävs att de statiska do- kumentens roll minskas och att dessa dokument bryts ner i informations- mängder som kan relateras i modellen. För att kunna bryta ner statiska do- kument i informationsmängder krävs att det finns någon form av mall- dokument. Om man definierar sådana mallar som xml-mallar (.xsd) så kan dokumenten sparas som xml-dokument och via t.ex. xsl-fo omformas till ett icke editeringsbart dokument (t.ex pdf).
För att säkerställa informationsmodellen i projektet måste modellen få motsvarande ”juridiska” ställning som de dokument som skapats ur dem.
Om informationsmodellen inte behandlas som en dokumentation av pro- jektet kommer den inte heller av projektdeltagarna att betraktas som en säker källa att hämta informationsmängder från. En direkt konsekvens av detta resonemang är att antalet informationsomstarter kan sägas vara om- vänt relaterat till informationsmodellens juridiska status i projektet. Tilliten till projektets samlade information styrs av projektledning och de föreskrif- ter som styr projektet. Att öka informationsmodellens status kan och borde hanteras i projektets allmänna föreskrifter.
Ett förslag som borde vara genomförbart är att på motsvarande sätt som när kretsloppsrådet rekommendationer för avfallshantering fördes in i AF, genomföra ett tillägg till AF om informationsmodellens ställning i projek- tet.
De olika styrdokument (CAD-manual m.m.) som finns för hur informa- tion skall behandlas i projektet utgår i allmänhet från vilka applikationer som skall användas. När styrningen är definierad på detta sätt tvingas pro- jektdeltagarna att använda de verktyg som specificerats, snarare än att till- föra informationsmodellen data. För att nå ökad interoperabilitet måste all styrning ske mot modellen och dess informationsmängder. Vad som skapar informationsmängderna är irrelevant.
BIM
Att fastställa ett ramverk för informationsmodeller för byggandet i Sverige måste vara en prioriterad åtgärd. Detta ramverk skall inte vara baserad på en applikation eller ett format utan beskriva de informationsmängder och objekt som hanteras och deras inbördes relationer.
I det danska ”Det digitale byggeri” har man nått halvvägs i dessa ambi- tioner. I princip så är styrningen fri från kopplingar till applikationer men i delar av objektstrukturen har man använt strukturer och egenskaper direkt från IFC-formatet.
För att skapa kontroll över interoperabiliteten i processen måste bran- schen kontrollera informationsflödet. Detta nås genom att informations- modellen till skillnad från t.ex. ”Det digitale byggeri” definieras fristående från format och applikationer och att definitionerna istället relateras till befintliga format för att på så sätt skapa tolknings- och appliceringsregler.
Efter att definitionerna fastställts så skall de olika överföringsformatens anvisningar relateras till den fastställda modellen.
Informationsinnehållet
Att använda information som man saknar känslan av att ha kontroll över stoppar i många fall informationsutbytet. När information distribueras från
12 Bilaga
Casestudiens dokument och CAD-information. 2
en part till nästa så spelar trovärdigheten en betydande roll för i vilken mån denna kommer att användas. Information som varit central för den som skapat den, betraktas alltid som mer trovärdig än information som skeppats med för illustration eller för att exemplifiera resultatet av ett ställt krav. Om en arkitekt ritar in en vägg av en viss typ i en modell för att tydliggöra ett krav på isolering, är kravet på isoleringen det bärande, inte hur väggen är uppbyggd i detalj. I processen måste kraven få en tydligare roll så att det går att särskilja den centrala informationen. På motsvarande sätt skall inte fler egenskaper hanteras, för ett element eller en vara, än de som är styrda av krav som uppkommit i processen. Informationens tillförlitlighet kräver att det går att verifiera och komplettera det som är mottaget. Verifieringen kräver att källan till informationen är tillgänglig. Det har gjorts många för- sök med varudatabaser som beskriver en vara och dess egenskaper. Som dessa fungerar nu är de i det närmaste värdelösa för komplettering och veri- fikation. Först och främst samlas informationen i externa databaser där informationsägaren har begränsade möjligheter att underhålla informatio- nen. Det saknas en definierad klassifikation för egenskaper och varor i Sve- rige. Möjligheterna att i realtid (utan manuellt arbete) verifiera och komplettera varuinformation är därför mycket begränsade.
Objekt
Utvecklingen av ett projekt beskrivs i ett antal skeden som vart och ett har sin samling definierade objekt. Objekt utvecklas och förfinas eller delas upp allteftersom projektet löper.
En förutsättning för att informationsutbytet mellan de olika stadierna skall fungera är att sambanden mellan skedenas objekt är väl definierade.
Förenklat kan man säga att objekt som byggnad, utrymme och storbygg- delar dominerar i tidiga skeden, medan byggdel, produktionsresultat och material tar över i senare skeden.
Varje objekt har sin samling av egenskaper (vanligen benämnda som property-sets).
I det danska initiativet ”Det digitale byggeri” upptar definitioner av ob- jekten och deras egenskaper och relationer en framskjuten plats. Objektens olika utvecklingstadier har man här kallat informationsnivåer där den lägsta nivån 0 är situation och byggnader. Nivåerna innehåller vidare följande information i stort.
1. Hanterar byggnad och rum
2. Större byggdelar
3. Motsvarigheten till BSAB-byggdelar
4. Rumskompletteringar mm med en detaljeringsgrad som är tillräcklig
för kalkyl och anbud.
5. Produktionsobjekt och varor
6. Detaljeringsgrad baserad på byggherrens dokumentationskrav vid över-
12 Nyttan av ICT för byggbranschen
26 Informationsstrukturer för samverkan i byggprojekt
Figur 2. Informationsnivåer med relationer till objekt och dokument
Varje objekt har i varje nivå definierade egenskapssamlingar med rekom- mendationer vad som skall dokumenteras och på vilket sätt. När objekten är definierade så kommer de, förutom att de kan redovisa objektets egenska- per, också användas för att i processen ställa krav.
Objektets klassifikation
Objekten skall oberoende av om de är fysiska eller inte knytas till klassifi- kationer. För att kunna strukturera information från modellen till dokument är det oftast objektets klassificeringar som styr sammanställningen. Att fastställa hur olika objekt kan och skall klassificeras är nödvändigt för att nå en hög interoperabilitet mellan olika applikationer i projektet. Klassifika- tionen kan inte enbart vara de klasser som är uppenbara såsom BSAB:PR, BSAB:BD eller BSAB:UTR utan måste också omfatta objekt i de tidiga skedena samt alla typer av material och egenskaper.
Objektets egenskaper
Till objekt finns en samling egenskaper (property-set). På samma sätt som man måste bestämma vilka objekt som skall hanteras så måste man också bestämma vilka egenskaper som skall och kan ingå i ett objekt. I ”Det digi- tale byggeri” har ett stort arbete lagts på att definiera samlingar av egenska- per till de definierade objekten. Detta arbete borde kunna ligga till grund för motsvarande arbete i Sverige.
Byggnad Utrymmen Stor- byggdelar Byggdelar Produktions resultat Material Klassifikation Beskrivning Föreskrift Program 1 2 3 4 5
12 Bilaga
Casestudiens dokument och CAD-information. 27
Figur .
Generiska objekt
För ett antal av de definierade fysiska objekten behöver det skapas någon form av generisk representation. Detta skapar mallar för hur objekten skall hanteras i informationsmodellen, både för hur krav skall ställas samt för redovisningen av ett fysiskt objekts egenskaper. Objekt som får en generisk representation är fysiska objekt ur klasserna 1–5.
Objektdeklaration utifrån generiska objekt
För att öka tillgången på strukturerad information om objekt i byggbran- schen måste det tas fram koncept på hur dessa deklareras. För närvarande pågår arbeten med att skapa deklarationer för byggmaterial. Varje deklara- tionsprojekt har sitt syfte. Olika deklarationer av material- eller objektin- formation med olika syften men med delvis samma information kommer att tynga leverantörerna och leda till att lämnad information blir minimal för varje deklaration. Det är därför viktigt att arbetet samordnas, motiveras och förenklas. Finfo samlar in sådan materialinformation i ett projekt som heter Vilma.11
De enskilda leverantörerna måste själva ansvara för publiceringen av de deklarerade objekten. För att informationen lättare ska nå effekt bör det skapas någon form av forum (länktorg) där de generiska objekten presente- ras och där de generiska objektens kopplade objekt finns inlänkade.
Informationsutbyte
Att överta och vidareförädla information från en part i processen för att sedan leverera den vidare krävs att parterna inte bara har tillit till innehållet utan också till det format som informationen fördes över med, och till till- lämpningen av formatet. Informationsinnehållets trovärdighet ökar om det går att verifiera delar av informationen mot en extern källa, ett informa- tionsforum.
Transformering
Informationsutbyte bygger ofta på att information transformeras från en vy till en annan. Genom att använda informationstransformering mellan redan fastställda format underlättas genomförandet av informationsutbytet. Ap- plikationstillverkaren fokuserar på de funktioner som applikationen är av- sett för och importerar och exporterar information med de format som till-
11www.finfo.se Objektsdefinition Samling av Samling av Klasser Samling av Klasser Egenskaper Generiskt objekt Deklarerat objekt
126 Nyttan av ICT för byggbranschen
28 Informationsstrukturer för samverkan i byggprojekt
t ätt
er- erade.
lämpningen behöver. Transformeringen mellan olika format kan sedan göras från t.ex olika web-platser. Om applikationer som hanterar Fi2 har behov av information från produktionen kan omvandlingen från sbXML eller IFC-xml till Fi2xml hanteras från Fi2:s horisont.
Transformeringen kräver att båda ledens informationsstrukturer är så noggrant definierade att informationen kan omformas utan manuella in- grepp. I Fi2xml och sbXML har man definierat informationsstrukturerna var för sig, vart och ett med sitt syfte för användningen. Om information skapat för produktionen i produktionsskedet skall transformeras till för- valtningsskedet krävs att alla egenskaper som efterfrågas i förvaltnings- skedet finns definierade och att strukturen på informationen i det över- förande systemet har åtminstone den finhetsgrad som mottagande sy- stem/format behöver.
Praktiskt kan detta bestå i att information från sbXML-formatet transfor- meras till ett eller flera dokument under Fi2xml. För att göra en sådan trans- formering generell så måste:
1.Fi2xmls dokument vara till fullo definierade i struktur,
2.SbXML-strukturen måste vara beskriven och definierad i detalj så att
inga varianter i användning eller tolkning förekommer.
3.Relationen mellan de båda strukturerna vara utredd, dokumenterad och
fastställd.
Applikationsoberoende transformering
Genom att skapa ett forum (plats) för att applikationsoberoende transformera information från ett format till ett annat skapar man möjligheter att verifiera och ev. certifiera en applicering av ett format mot de fastställda definitioner- na på formatets objekt.12 Dessutom kan transformeringar utföras automatiskt
med bibehållen trovärdighet. En applikation som är utvecklad för ett visst syfte använder det eller de format som applikationen har primär nytta av. Transformeringar till andra format och tillämpningar sker genom att ett av de primära formaten exporteras och omformas genom att format och tillämp- ning av formatet verifieras på forumet samt att efter godkännande transfor- meras till rätt format. En biprodukt av ett sådant transformeringsforum är at man utifrån två format skulle kunna komplettera det ena formatet med in- formation från det andra formatet; t.ex. så skulle en IFC-modell på detta s kunna kompletteras med kalkylinformation utan att de ursprungliga applika- tionerna har kännedom om varandras information. Kompletteringar m.m. kräver att informationsmodellens objekt är definierade och att applikation na och tillämpningen på något sätt är certifi
Under ett antal år så har branschen arbetat med produktmodellservrar, of- tast baserade på IFC-formatet. Produktmodellen var en av hörnstenarna i ITBOF 2002 och kan sägas vara ett slags eller möjligtvis en special- tillämpning av informationstransformering.
Med fokus på oberoende transformering så kommer appliceringen av standardiserade tillämpningar på formaten att genomföras inom ett kortare tidsperspektiv, då en av de största bromsande faktorerna för informations- utbyte är applikatörernas brist på kunskap om de sekundära formaten.
12
Ett exempel finns inom LCA (Livscykelberäkningsapplikationer) där olika fastställda
127 Bilaga
Casestudiens dokument och CAD-information. 29
Projektnätverken
Processen skapar och förädlar information i varje länk av projektets kedja, och det är endast delar av informationen som normalt skall levereras till förvaltaren. Med andra ord kan det vara svårt för förvaltaren att sortera ut intressant information ur hela informationsmodellen.
I projektnätverken sker det mesta informationsutbytet. Det är därför av yttersta vikt att dessa nätverk nära samarbetar med transformeringsforumen, för att styra utbytet i nätverken till forumets verifieringsverktyg, regelverk och informationsstrukturer.
För att öka tillförlitligheten i informationen i nätverket så bör det finnas möjligheter att verifiera den i forumet för generiska och kopplade objekt
Rekommendationer
Råd för digitalt byggande
Att öka interoperabiliteten i byggprocessen kräver samordning och att bran- schen i sin helhet tar på sig ansvaret. Genom att titta noga på ”Det digitale byggeri” i Danmark och det egna Kretsloppsrådet på miljösidan och utreda vilka funktioner och befogenheter dessa har, kan vi tydliggöra behovet av ett svenskt ”Råd för digitalt byggande”. Rådets främsta uppgifter är att möjliggöra en branschgemensam planerad övergång till ett digitalt byggan- de med bl.a. klart definierade förutsättningar för etablerande av objektbase- rad informationshantering och dess samverkan med dokumentbaserad in- formationshantering.
Implementering
Övergången till digital informationshantering i byggandet kräver insatser inom tre huvudområden:
A) Informationsdokumentens legala status
B) Standardisering av informationsstrukturer och gränssnitt
C) Metoder och processer för projektsamverkan och ICT-användning. För att möjliggöra och samordna insatser inom dessa områden bör som ett inledande första steg ett branschgemensamt råd för digitalt byggande bil- das. Rådet bör ansvara för och initiera arbete inom dessa områden enligt följande:
A) Informationsdokumentens legala status
x Klarläggande av relationen mellan dagens legala dokument och in- formationsmodellen
x Klarläggande av ansvaret för informationen i byggprojekten B) Standardisering av informationsstrukturer och gränssnitt
x Definition av informationsnivåer för modellen och hur dessa nivåer relateras till varandra
x Definition av struktur och informationsmängder för strukturerade legala dokument som beskrivningar och protokoll
x Definition av nivåernas objekt, både fysiska och virtuella, samt fastställande av objektens inbördes relationer i ett ramverk x Definition av klassifikations- och egenskapssamlingar för objekten
128 Nyttan av ICT för byggbranschen
0 Informationsstrukturer för samverkan i byggprojekt
x Utarbetande av generiska objekt för ett urval av objekten, med mal- lar för hur material och komponenter kan kopplas och dokumente- ras relativt generiska objekt
C) Metoder och processer för projektsamverkan och ICT-användning x Skapandet av en plats där objektens definitioner visas, deras gene-
riska representation hanteras och där länkar till kopplade objekt kan finnas
x Relatera existerande informationsformat till det fastställda ramver- ket
x Skapandet av en plats för transformering av projektinformation utan fysisk koppling till genererande applikation. Platsen bör också verifiera exporter från applikationer och ev. också kunna certifiera en applikations export av fastsällt externt format
x Ge möjlighet för projektnätverken att på ett okomplicerat sätt kommunicera med transformerings- och objektsplatserna
Figur 4.
Implementeringsförslag på kort sikt i projekt
Omedelbar implementering förutsätter inte att alla definitioner och objekt skall hanteras innan transformeringar och utbyte kan ske. Istället förordas att arbetet planeras så att delar av flödet kan implementeras snabbt, och att arbetet utvärderas parallellt.
Stegen kan tyckas många och stora om arbetet görs från början. Men ge- nom att utgå från och anpassa ”Det digitale byggeri” till svenska förhållan- den så är stora delar av arbetet redan gjort. Tidigare projekt med produkt- modellservrar bör också beaktas då de i princip har arbetat med objektdefi- nitioner, informationstransformeringar och informationskompletteringar.
Objekt Transformering INFO STRUKTUR Generiskt objekt Format: IFC sbXML fi2XML Projekt- dokumen t Deklarerade objekt
129 Bilaga
Casestudiens dokument och CAD-information. 1
Att fokusera arbetet på definitionerna är viktigt, då allt efterföljande arbete skall passa de övergripande definitionerna i ramverket. Det är också viktigt att inte delar av modelldefinitionen baseras på befintliga format eller appli- kationer, som kontrolleras av och kan påverkas utomstående organisationer.
Genom att beskriva en process och processens relationer till modellen går det att identifiera de objekt som processen hanterar och därmed beskriva hur dessa objekt utvecklas, transformeras till andra objekt och utväxlas genom projektets skeden. Figur 5 visar den principiella arbetsgången i detta arbete där de olika stegen kan genomföras överlappande.
Figur 5 Steg för att definiera objekt i en process i modellen.
Innan objektens egenskaper och relationer definieras utreds vilken infor- mation som behöver utbytas, genom att undersöka det informationsbehov som mottagaren behöver för att med automatik kunna hantera övertagandet. På motsvarande sätt undersöks vilken information som informationsleve- rantörerna kan leverera med hög kvalitet och hur väl denna information överensstämmer med mottagarnas behov. Ur detta definieras objekten i processen. Där behov uppstår så skall det i samband med definitionen av objekten också skapas generiska objekt för att erhålla en kvalitativt bättre kommunikation av krav och resultat. Vid det praktiska genomförandet ut- reds de format, som leverantör och mottagare förfogar över, och rutiner för ev. informationstransformering dokumenteras.
Parallellt med genomförandet utvärderas resultaten och eventuella kom- pletteringar görs i redan framtagna definitioner och transformeringar. När ett definitionsprojekt är utvärderat och godkänt skall resultatet i form av definitioner, transformationer och eventuella generiska objekt fastställas och inlemmas i informationsramverket.
Praktisk implementering i projekt
För att exemplifiera och trimma in arbetet med informationsmodellen är det lämpligt att starta med några processer som redan har vissa delar definiera- de. Detta kan vara arbetet med prefab-konstruktioner, t.ex. plattbärlag, och inredning, t.ex. skåpsinredningar i lägenheter.
Beskriv process
Beskriv objektens stadier
Info leverantör - möjligheter Info mottagare - behov
Genomför praktiskt Utvärdera definition Bestäm processobjekt
10 Nyttan av ICT för byggbranschen
2 Informationsstrukturer för samverkan i byggprojekt
1. I projektet skall man bestämma vilka objekt som skall specialstuderas.
Väljer man att arbeta med skåpsinredningar så skall alla parter som har relationer till inredningar inlemmas i arbetet. Genom att beskriva vad varje enskild part, och dennes it-stöd, har för relation till informationen, både den del som man lämnar från sig och den del som man får från le- det innan, kan arbetet med inredning beskrivas som en process.
2. När processen är känd skall man ur beskrivningen bryta ut de olika detaljeringsgrader som inredningen har genom processen och identifie-