Tillämpning av IFC i Sverige etapp 2 Slutrapport Arbetsrapport A15 2000-06-30 AB Svensk Byggtjänst

Tillämpning av IFC i Sverige etapp 2 Slutrapport Arbetsrapport A15 2000-06-30 AB Svensk Byggtjänst Anders Ekholm, Väino Tarandi, Olle Thåström Detta projekt har genomförts med finansiering från IT Bygg och Fastighet 2002 samt Nutek Projekt 98309

Tillämpning av IFC i Sverige - etapp 2 Slutrapport Arbetsrapport A15 2000-06-30 AB Svensk Byggtjänst Branschsystematik 113 87 Stockholm Telefon 08 457 10 00 www.bsab.byggtjanst.se

Tillämpning av IFC i Sverige sid 2

Innehållsförteckning DETTA ÄR SVENSK BYGGTJÄNST...5 SAMMANFATTNING...7 ENGLISH SUMMARY...7 1. INLEDNING...9 BAKGRUND...9 IAI och IFC...9 Andra initiativ...10 SYFTE OCH PROBLEMOMRÅDE...10 2. PROJEKTET...12 ARBETSUPPGIFTER, MÅL...12 GENOMFÖRANDE...12 Aktiviteter...13 Organisation, resurser...14 Ekonomi...14 Resultat...14 Fortsatt arbete...15 3. IFC...17 ÖVERSIKT...17 Bakgrund till datorprogrammens uppbyggnad...17 Hur fungerar IFC...18 Interoperabilitet...19 Versioner...20 TILLÄMPNINGSOMRÅDE...21 Problemområden...21 Objektens egenskaper...22 VAD ÄR BYGGPRODUKTMODELLEN?...22 DAGENS SITUATION...23 BEHOV OCH NYTTA...24 Mekanismer för samverkan...25 STUDIER OM IFC I ANDRA LÄNDER...26 4. ANALYS AV IFC...28 KLASSIFIKATION...28 ISO 12006-2...28 IFC...32 5. PROTOTYPARBETET...41 BAKGRUND...41 Tillämpning av IFC i Sverige sid 3

TESTMILJÖN...41 RESULTAT...45 IFC-FILFORMAT...47 IFC OCH PRODUKTMODELLEN...48 FÖRSLAG TILL VIDARE UTVECKLING AV PROTOTYPEN...49 6. IFC I SVERIGE...50 NATIONELLA FÖRUTSÄTTNINGAR...50 Etablerad systematik...50 PROGRAM FÖR BYGG- OCH FÖRVALTNINGSSEKTORN...50 PROCESSER OCH METODER...51 Användare...52 Erfarenheter...52 TIDSPERSPEKTIV...52 Underlag för projekt...52 ORDLISTA...53 REFERENSER...55 Omslag: Bilden får symbolisera principen om en stegvis utveckling av IFC och tillämpningar med IFC som kan göras i dag men som passar in i den helhetsbild av produktmodellen som kan skönjas i framtiden. Tillämpning av IFC i Sverige sid 4

Detta är Svensk Byggtjänst AB Svensk Byggtjänst är byggsektorns gemensamt ägda informationsföretag. Byggtjänst utvecklar, marknadsför och säljer information för byggande och förvaltning. Företaget verkar för rationellt och ändamålsenligt byggande och förvaltning genom att tillhandahålla informationstjänster och informationsprodukter som är anpassade till användarnas behov liksom genom att vara en plattform för utveckling av branschgemensamma informationsstrukturer såsom BSAB-systemet. Byggtjänst är ett aktiebolag som ägs av ett fyrtiotal rikstäckande branschorganisationer. Dessa företräder byggherrar och fastighetsförvaltare, arkitekter och andra projektörer, entreprenörer, byggnadsarbetare, byggvarutillverkare m fl. Byggtjänsts verksamhet började 1934 med en liten byggvaruutställning i en lokal vid Kungsgatan i Stockholm. Sedan dess har verksamheten successivt utvecklats. Svensk Byggtjänsts viktigaste produktområden är: Varuinformation (varudatabas, miljövarubas, bygg- och VVS-kataloger samt utställning av bygg- och installationsprodukter) AMA (utveckling och underhåll av AMA och produkter i anslutning härtill samt BygginfoBas) Branschsystematik (b l a utveckling och underhåll av BSAB-systemet) Byggbokhandeln (försäljning av bygglitteratur via butiker och Internet) Förlag (utgivning av bygglitteratur) Rådgivning och utbildning (nyhetsinformation, personlig information, kurser, seminarier). Byggtjänst satsar för närvarande starkt på produkt- och tjänsteutveckling inom olika områden, framför allt med inriktning på IT. Inom varuinformationsområdet håller till exempel en miljövarudatabas på att byggas upp hos Byggtjänst. Byggtjänst har ett aktivt samarbete med många svenska och utländska företag, myndigheter och institutioner, varav några kan nämnas: UICB (Internationella byggtjänstunionen), EPIC (samarbetsorganisation för europeisk varuinformation), ICIS (internationell organisation för utgivare av nationella beskrivningssystem, t ex AMA, eller kostnadsinformationssystem), CIB (Internationella rådet för byggforskning och bygginformation), ISO (för närvarande medverkan i TC59/SC13/WG2 för ramstandard för klassifikation). Tillämpning av IFC i Sverige sid 5

Tillämpning av IFC i Sverige sid 6

Sammanfattning Syftet med detta projekt har varit att noggrant studera IFC och testa det med avseende på hur det svenska BSAB-systemet kan tillämpas i IFC. Det har gjorts dels med teoretiska analyser och dels genom att använda en prototyp till ett program som kan visualisera IFC-filer. Resultatet visar att det förefaller möjligt att använda IFC och BSAB tillsammans vid informationsöverföring men att det finns många problem att lösa innan det blir praktiskt användbart. Vi ser många brister i IFC och det finns stora skillnader gentemot BSAB och ramverksstandarden för byggklassifikation, ISO 12006-2. Den väg vi föreslår för att lösa de problem de medför innebär dels ett ökat engagemang i IAIs arbete, dels att ett antal pilotprojekt genomförs med klart utstakade mål inom begränsade områden. Nyckelord: IFC, IAI, BSAB 96, klassifikation, ISO, produktmodell, byggprocess, kommunikation, samverkan English summary The overall purpose of this project has been to study the IFC specification and to examine it according to the possibilities of implementing the Swedish BSAB-system within IFC framework. The work has been carried out partly by means of theoretical analyses, partly by using a prototype program which is capable of visualizing IFC files. The result shows that it seems possible to integrate IFC and BSAB in information exchange, but there are a lot of problems that have to be solved before programs can be brought into market. We have encountered many imperfections in IFC and we have also found that there are great differences compared to BSAB and the framework standard for construction classification, ISO 12006-2. Our suggestions for solving these problems include an increased participation in the work within IAI and a number of pilot studies with delimited goals to cover important use cases. Keywords: IFC, IAI, BSAB 96, classification, ISO, product model, construction process, communication, co-operation Tillämpning av IFC i Sverige sid 7

Tillämpning av IFC i Sverige sid 8

1. Inledning Bakgrund IAI och IFC Tolv företag som är engagerade i AEC/FM industrin initierade IAI, International Alliance for Interoperability [1], vars syfte var att möjliggöra samverkan mellan olika programvaror. Gruppen tog fram en serie av prototypprogram som visades vid A/E/C Systems 95, Atlanta. Prototyperna visade att denna idé kunde realiseras. I september 1995 inbjöds AEC/FM företag i hela världen att delta i samarbetet och organisationen IAI var född. IAI är organiserat med nio chapters som vart och ett samlar företagen i en geografisk region. Antalet medlemmar omfattar nu över 600 företag från mer än 20 länder. Svenska företag deltar genom medlemskap i Svenska IAI Forum, SIAI [2], som i sin tur är medlem i IAI Nordic Chapter, NIAI [3]. SIAI har cirka 40 medlemmar som representerar olika delar av bygg- och förvaltningssektorn. Inom Norden, och även internationellt, är det den finska organisationen som är mest aktiv, något som möjliggjorts genom att VERA-programmet [4] stöder en mängd projekt där IFC används. I den centrala MSG (message developement group) finns bland andra två finska representanter. IAIs vision är att möjliggöra samverkan (interoperabilitet) inom bygg- och fastighetssektorn (AEC/FM). Dess verksamhet går ut på att stödja och publicera en specifikation av hur data om byggprojekt kan delas genom hela livscykeln av olika discipliner och med olika datorprogram. IAI är en ideell organisation öppen för alla företag. Den är handlingsorienterad och arbetar för att få ut resultaten i praktisk användning steg för steg snarare än att arbeta för ett djupgående resultat som tar lång tid att nå. Organisationen startades också som protest mot det långsamma arbete som bedrivs inom de etablerade standardiseringsorganen. Samtidigt arbetar man på likartat sätt med kommittéer och grupper av specialister och beslut tas i konsensus och man syftar till en världsomfattande tillämpning. Även om organisationen IAI är ideell är det knappast någon tvekan om att det är starka affärsintressen bakom mångas medlemskap. Man vill vara med för att påverka och få information för att kunna positionera sina egna produkter. Vad än motiven är och resultatet blir kommer programvarorna att påverkas i sin utformning och vi i Sverige är starkt beroende av den internationella utvecklingen. Det ger oss anledning att delta i denna utveckling och om möjligt påverka den i för oss gynnsam riktning. IAIs produkt är IFC, Industry Foundation Classes, ett ramverk av klasser att användas för överföring av information mellan produktmodeller skapade i olika datorapplikationer. IFC skall alltså användas vid framtagning av datorprogrammen. Tillämpning av IFC i Sverige sid 9

Andra initiativ Specifikationerna skall vara öppna för användning av alla programföretag. IAI tar själv inte fram några program utan skall enbart arbeta med IFC och dess fortlöpande utveckling. IAI har förbundit sig att samarbeta med andra standardiseringsorganisationer och det finns Memorandum of Understanding mellan IAI och ISO TC 184/SC4 (STEP). IAI är inte den enda organisationen som arbetar med denna typ av frågor. Arbete med en standard för överföring av produktinformation inom gas- och oljeindustrin har pågått några år. Det har beteckningen POSC/CAESAR [5] efter ett samarbete mellan Petrotechnical Open Software Corporation och CAESAR Offshore Project. Detta har rapporterats om i etapp 1 av detta projekt. Bentley Systems Inc är en av initiativtagarna till det som kallas aecxml [6]. Man kan nog uppfatta den organisationen som en konkurrent till IAI och dess tillkomst dels som en protest mot Autodesks starka dominans i IAI, dels mot att inte heller IAI har lyckats snabba upp processen med att få fram en operativ version. Själva säger man sig vilja skapa ett komplement till IFC. Läget för närvarande är att ett visst samarbete har påbörjats mellan organisationerna. En rapport från Working Group Meeting lämnades i förra etappens slutrapport. Inget nytt har tillkommit som ger anledning till ökat intresse åt detta håll. Sedan dess har aecxml fått en egen grupp under NA IAI, det vill säga North American IAI Chapter. Fortfarande är uppfattningen delad beträffande relationer mellan XML och IFC behöver XML ha tillgång till en produktstruktur? Syfte och problemområde Från svensk horisont är all utveckling inom den internationellt verksamma programvaruindustrin viktig eftersom vi i stor utsträckning använder produkter från denna både i bygg- och fastighetssektorn liksom naturligtvis inom många andra områden. En påverkan är den programmen har på arbetsmetoderna. En annan är den påverkan som en standardisering av programmens uppbyggnad har. Den senare kan i princip göra det lättare att bygga komplement och tilläggsmoduler och till och med konkurrerande produkter. Om programmens sätt att hantera informationen däremot inte stämmer överens med vårt kan det istället innebära svårigheter att få datorstödet effektivt. Det här projektet syftar till att studera IFC-modellen för att uppnå en djupgående förståelse av den, jämföra den med BSAB-modellen och försöka besvara frågan om de kan fungera tillsammans och i någon mån hur. I en förlängning gäller det även andra modeller som tas fram i IT Bygg och Fastighet 2002. BSAB-systemet har en lång tradition i Sverige men den tredje generationen av det bygger på en helhetssyn på information om byggnadsverk under hela deras livscykel, som inte formulerats så tydligt på denna nivå tidigare. Därför finns också en underliggande mer filosofisk fråga, nämligen om det låter sig göra att fånga in den informationen i datorsystem och hantera den på ett rationellt sätt under lång tid. Tillämpning av IFC i Sverige sid 10

Projektet undersöker om IFC kan bidra positivt till denna informationsbehandling. Ett viktigt förhållande är att BSAB har samma helhetssyn som ramverksstandarden ISO 12006-2 och därför kan jämförelsen med IFC likaväl utgå från denna. Detta gör resultatet av jämförelsen intressant ur internationell synpunkt. IFC innebär genomgripande förändringar dels i sättet att göra datorprogram och dels i sättet att använda dem. Dessutom förändras bygg- och fastighetssektorn av andra skäl. Alla faktorer är inte påverkbara av enskilda parter och därför blir även våra slutsatser och insatser skott mot rörligt mål. I rapporten berörs en del marknadsmässiga och andra förhållanden som kan påverka genomförandet av så stora förändringar som det faktiskt är att få en obruten informationskedja under byggnadsverkets livscykel. Tillämpning av IFC i Sverige sid 11

2. Projektet Projektet Tillämpning av IFC i Sverige har delats upp i två etapper, varav denna rapport omfattar den andra, men den ger även en viss sammanfattning av resultaten från den första etappen. Uppdelningen i etapper har främst betingats av de osäkerheter om fortsättningen som funnits inledningsvis. Redan i ansökan för etapp 1 presenterades förslag till områden att arbeta med både i etapp 2 och även därefter, men då dessa inte vid den tidpunkten kunde kvantifieras avgränsades ansökningarna till att omfatta överblickbara mål. Parallellt med avslutningen av etapp 1 utarbetades en ansökan för en tredje etapp. Den har bearbetats ytterligare och ett kompletterat förslag har lämnats till programstyrelsen på dess begäran. Även denna rapport från etapp 2 bör beaktas vid beslut om fortsatt projekt. Arbetsuppgifter, mål Genomförande I projektbeskrivningen till etapp 1 anges att arbetet inriktas i huvudsak på följande delområden: delta i, bevaka och påverka IAIs utveckling av IFC skapa goda kontakter med ledande systemutvecklare på internationell nivå bygga upp kunskap om IFC och närliggande projekt pröva IFC och BSAB 96 i pilotprojekt informera och utbilda svensk byggsektor om system och tillämpningar De två sistnämnda punkterna avsåg i princip den fortsättning i en tredje etapp som förutsattes. De första punkterna genomfördes i etapp 1 och har rapporterats och dokumenterats grundligt. Målet med etapp 2 avsåg att dels testa IFC för överföring av information klassificerad i enlighet med BSAB 96 dels utarbeta en fördjupad jämförelse mellan IFC och byggklassifikationen i ISO 12006-2 och BSAB 96. De tillämpningar som har prövats avser information i samband med utarbetande av byggnadsbeskrivningar och av kostnadsberäkningar. Avsikten var (underförstått) att konstatera i vilken grad IFC kan överföra en informationsstruktur baserad på BSAB. Arbetet i denna etapp har i huvudsak uppdelats på följande områden: Framtagning av en prototyp till ett program för analys och visualisering av produktmodellen samt användning av denna med ett testmaterial där Väino Tarandi varit huvudansvarig. Teoretisk analys och fördjupad jämförelse mellan IFC och byggklassifikationen i ISO 12006-2 och BSAB 96. För denna del har Anders Ekholm haft huvudansvaret. Deltagande i seminarier om produktmodellering som arrangerats bland annat av IT Bygg och Fastighet 2002. Tillämpning av IFC i Sverige sid 12

Aktiviteter Samarbete med andra projekt inom IT Bygg och Fastighet 2002 samt kontakter med personer och grupper inom IAI, ISO med flera. Författande och sammanställning av rapport. Arbetet har bedrivits till större delen med enskilda aktiviteter som har samordnats vid arbetsmöten och naturligtvis kommunikation via telefon och e-post. Bedömningen av IFC baseras i huvudsak på dokumentationen om version 2.0 som är den senaste utgåvan. Under slutet av projektet har visst material avseende den kommande versionen funnits tillgängligt i betaversion. Detta är fortfarande under arbete och inte komplett och därför har det inte varit möjligt att beakta kommande förändringar i sin helhet. Flertalet förändringar som vi kunnat se är positiva. IAI, Technical Advisory Group, TAG Väino Tarandi har under perioden deltagit vid de telefonkonferenser som den tekniska rådgivande gruppen har hållit. TAG arbetar fram riktlinjer för den tekniska utvecklingen av IFC, bland annat underlag för geometri, måttenheter, överföringsformat, beskrivningsspråk med mera. IAI Nordic Chapter, NIAI Styrelsemöten Ordinarie möte med NIAI i Oslo 1999-10-11. Ordinarie möte med NIAI i Köpenhamn 1999-11-29. Ordinarie möte med NIAI i Oslo 2000-03-16. Deltagare: Väino Tarandi. Styrelsemöte samt workshop juni 2000 Ordinarie möte med NIAI i Stockholm 2000-06-05 06 Deltagare: Anders Ekholm, Lars Häggström, Olle Thåström, Väino Tarandi. Kommentar: Ett syfte med deltagande i detta möte var att informera om resultat och slutsatser i detta projekt, ett annat att utbyta erfarenheter dels med andra projekt i Norden, dels med nyckelpersoner inom IAI. Thomas Liebich och Kari Karstila deltog med utförliga genomgångar av nya delar av IFC. Intelligent information i byggande och förvaltning Anders Ekholm och Väino Tarandi redogjorde vid ett seminarium 2000-05-03 för hur IFC fungerar med avseende på klassifikation och informationsöverföring. Seminariet var mycket välbesökt (nära 200 deltagare) och en utförlig redovisning av det finns på BSABs webbplats. Tillämpning av IFC i Sverige sid 13

IAI/IFC-udvikling og F/U i byggesektoren. Seminar om intelligent dataudveksling og modeludvikling i byggesektoren. 25 januari 2000 på Teknologisk Institut, Taastrup, Bygning 8, lokale 800. Anders Ekholm redogjorde för hur IFC fungerar med avseende på klassifikation och informationsöverföring. Seminariets syfte var att redogöra för IFC för anställda och studerande vid danska högskolor med inriktning mot byggande. Seminariet skulle även ge underlag för bedömning av möjligheter till: Aktivt deltagande i utveckling av IFC Användning av IFC som utväxlingsformat Utveckling av IFC-baserade applikationer. Samverkan med andra projekt Genom att de personer som är engagerade i IFC-projektet också deltar på olika sätt i andra projekt inom IT Bygg och Fastighet 2002 finns det ett naturligt flöde av information mellan projekten. Väino Tarandi har vid flera tillfällen varit ute hos slutanvändare hos de stora företagen och presenterat IFC och det prototypprogram som tagits fram i detta projekt. Organisation, resurser Projektets bemanning har varit den samma i denna etapp som i etapp 1: Projektledare har varit Olle Thåström, AB Svensk Byggtjänst. Huvudutredare för systematik och klassifikation har varit Anders Ekholm, docent vid Projekteringsmetodik, LTH, och för deltagande i IAI och sakkunnig inom STEP teknologie doktor Väino Tarandi, Eurostep. Lars Häggström har deltagit som sakkunnig på BSABsystemet. SIAIs styrelse har inte utnyttjats som styrgrupp formellt eftersom den finns väl representerad i projektorganisationen (Väino Tarandi och Lars Häggström) och flertalet övriga ledamöter i styrelsen deltagit i flera gemensamma aktiviteter. Ekonomi Resultat Projektets ekonomi redovisas separat. Här kan noteras att anslagen för etapp 1 och 2 omfördelats något mellan etapperna. Gränsen mellan etapperna har av naturliga skäl inte heller varit knivskarp. Projektledningen för H1-projektet och programstyrelsen har fortlöpande informerats om läget. Projektets resultat publiceras genom denna slutrapport. Den har sammanställts av projektledaren som författat de allmänna delarna och formulerat den översiktliga beskrivningen av IFC. Respektive huvudutredare har författat sin del av materialet (kapitel 4 Anders Ekholm, kapitel 5 Väino Tarandi). Det är därför naturligt att vissa de- Tillämpning av IFC i Sverige sid 14

Fortsatt arbete lar kan överlappa varandra och att våra olika sätt att uttrycka oss liksom olika åsikter slår igenom i texten. Analysen av IFCs teoretiska grundval är gjord från strikt systemvetenskaplig utgångspunkt och delar av materialet är diskuterat med IAI-representanter. Där har vi märkt en lyhördhet för kritiken. Materialet avses även användas för rapportering i andra sammanhang. Vår gemensamma allmänna slutsats kan formuleras så att det är möjligt att använda IFC och tillämpa BSAB-systemet för informationsöverföring mellan datorprogram. Det finns problem i detta men om man fokuserar arbetet på delområden där behovet av samverkan är stort och nyttan uppenbar finns möjligheter att lyckas. För att komma till den praktiska användningen måste pilottillämpningar göras inom nyckelområden och där måste de svenska programvaruföretagen engageras samtidigt som de teoretiska studierna fokuseras på dessa specifika områden. Programvaruföretagens positiva medverkan är nödvändig för att få igång utvecklingen av testmiljöer som sedan kan bli bas för kommersiella produkter. Erfarenheter från sådana tillämpningar måste återföras till IAI och bidra till att påverka IFC-modellens utveckling. Om detta skall kunna uppnås krävs ett mycket starkare engagemang och deltagande i IAIs arbete centralt. Det är endast möjligt om en eller flera personer kan ägna sig åt sådana uppgifter på heltid. På denna punkt har projektet kommit till ett tydligt ställningstagande. För att slutanvändarna skall acceptera och använda produkterna behöver resultaten från detta och fortsatta projekt spridas både inom och utom Sverige och detta förutsätts kunna ges vissa resurser i kommande etapp. Ett övergripande mål med IT Bygg och Fastighet 2002 är bland annat att samverkan mellan aktörerna i bygg- och fastighetssektorn skall effektiviseras. Detta kan uppnås genom att informationen om byggnadsverket kan delas av alla. En vision är att man skall kunna ha en gemensam projektdatabas eller modell i vilken alla lagrar och hämtar information. Ett sådant arbetssätt ställer stora krav på administration av databasen vad avser behörighet, versionshantering med mera. Det ställer också stora krav på de programvaror som bygger och utnyttjar databasens innehåll. I detta projekt har vi kommit till uppfattningen att vägen till detta mål måste gå via många små förändringar i processer och metoder. Det är inte realistiskt med en snar och övergripande förändring av dagens situation. Byggbranschen beskylls ofta för tröghet och ovilja till förändringar, speciellt vad gäller användning av IT. Det är nog sant att nyheter har svårt att bli accepterade men en förklaring kan ligga i att ingen part egentligen har några incitament till förnyelse. Hittills har ofta någon annan gjort den ekonomiska vinningen av en rationalisering eller produktivitetsförbättring med datorstöd. Detta bottnar i branschens och processens struktur. Tillämpning av IFC i Sverige sid 15

I det följande finns några utgångspunkter för olika praktiska tillämpningar som bör provas för att för att få fram nya programvaror eller utvidgningar av nuvarande. Tanken är att dessa lätt skall få acceptans hos användarna och bidra till lönsamma förbättringssteg i processen. Tillämpning av IFC i Sverige sid 16

3. IFC Översikt I detta avsnitt beskrivs IFC utifrån den dokumentation som finns och annan information som inhämtats i projektet tillsammans med våra kommentarer. Beskrivningen har medvetet förenklats och syftet är att försöka ge förklaringar som inte riktar sig till systemspecialister utan snarare till byggfolk med viss kunskap om IT. Först bör sägas att IFC inte är något magiskt. Det är ett systembygge som utförts av många människor från olika länder och under relativt kort tid. Detta faktum präglar också modellen starkt; den är omfattande och inte konsekvent, med olika detaljeringsgrad i olika delar och skilda lösningar på likartade problem inom olika områden. Inslaget av IT-folk är stort och det är därför inte förvånande att ramverksstandarden för byggklassifikation, ISO 12006-2, inte beaktats ännu. Modellen är svår att överblicka och tar tid att lära sig förstå. I hög grad saknas en enkel grundprincip och pedagogiska beskrivningar relaterade till upplevda behov. Detta är den huvudkritik man kan rikta mot den. Att IFC ser ut som det gör hänger naturligtvis ihop med det sät att arbeta fram modellen som bedrivits inom IAI. Därför har IFC både för- och nackdelar men utvecklingen leds i alla fall framåt. Om detta koncept fortfarande kommer att heta IFC om ett antal år törs knappast någon förutspå. Bakgrund till datorprogrammens uppbyggnad Utvecklingen av datorprogram har gått mot alltmer komplexa produkter med fler och fler funktioner och finesser. Programmen hanterar också mer och mer av den komplexa verkligheten. Därför har det blivit nödvändigt att dels finna metoder för rationell konstruktion av programmen, dels beskriva modeller av verkligheten som gör den hanterbar. Tekniken kallas objektorientering och började tillämpas inom programmeringsområdet. Det är i grunden samma angreppssätt som används i systemvetenskapen och som lagt grunden för den tredje generationen av BSAB-systemet och den internationella ramstandarden för byggklassifikation, ISO 12006-2. Objektorientering innebär i datorsammanhang (förenklat uttryckt) att de objekt programmen opererar på uppdelas i hanterbara enheter med gemensamma egenskaper. Den typ av datorprogram som hittills haft mest påverkan på byggsektorn är utan tvekan CAD-programmen. De CAD-program som utvecklades för persondatorer var från början ganska enkla ritprogram som fungerade med enkla plana geometriska former (entiteter) som avbildade ritningar. Objekten i byggnadsverket kan inte urskiljas i den information som lagras i datafilen på annat sätt än genom att enstaka geometriska objekt eller grupper av dem finns i samma lager i filen eller samlade som block. Dessa geometriska objekt kan också ha andra attribut knutna till sig. När programmen utvecklas vidare blir det naturligt att de kan hantera och avbilda byggnadsverkets objekt, det vill säga fysiska delar av byggnaden. Syftet är dels att Tillämpning av IFC i Sverige sid 17

Hur fungerar IFC göra ritarbetet effektivare, dels att avbildningen kan göras mer realistisk, alltså i andra projektioner och vyer än plan. CAD-programmens behov av att avbilda, i kombination med innehållet på de ritningar som framställs, styr urvalet av byggobjekt som behövs. Ritningarna utformas efter traditionella regler i princip oberoende av framställningssätt (manuellt eller med CAD). Alla delar av byggnaden avbildas inte fullständigt, en del enbart symboliskt eller starkt förenklat och en del inte alls. Ritningen är i sig en symbolisk notation. Det innebär att den modell av byggnadsverket man får genom att avläsa CAD-filerna inte är komplett. Dessutom är modellen a priori baserad på delarnas geometrier. Andra egenskaper för de delar som lagras i CAD-filen har till huvudsakligt syfte att komplettera ritningen med text. Andra specialiserade programvaror inom bygg- och fastighetssektorn såsom kalkylprogram, projektplaneringsprogram, beräkningsprogram och förvaltningsprogram använder sig vart och ett av olika uppsättningar objekt i skilda informationsmodeller, som är mer eller mindre av branschgemensamt eller allmänt accepterat slag. IFC definierar en uppsättning objektklasser och regler för samband (relationer) mellan dem även dessa uttrycks som objektklasser. Objekten kan ges geometriska egenskaper. Många andra egenskaper kan knytas till objekten med property sets. Med dessa objekts hjälp kan man beskriva byggnadsverk. Man kan också säga att IFC är ett ramverk som kan användas för att bygga produktmodeller. Tanken är att objekten skall kunna överföras mellan skilda programvaror och olika typer av applikationer. Förenklad beskrivning av IFC Detta är IAIs egen beskrivning, översatt och något förkortad. IAIs intention är att beskriva hur tingen som finns i ett byggnadsverk (både de fysiska som väggar, dörrar, fönster och sådana som organisation, process) skall representeras i en strukturerad datamodell. Varje specifikation kallas för en klass (class) och omfattar de ting som har vissa egenskaper gemensamma. Exempelvis är specifikationen för en fläkt mer än en samling linjer och andra geometriska grundelement som gör att det ser ut som en fläkt. Varje fläkt som förekommer i ett projekt har de gemensamma egenskaperna för fläktar och dessutom egna specifika egenskaper som tilldelats den. Varje förekomst (instans) i projektet kallas ett objekt och har en egen identitet. Genom att sättet att beskriva objekten är lika för olika datorprogram kan dessa känna igen objekten och på det sättet kan aktörerna i ett projekt dela data elektroniskt utan konverteringar. En arkitekt kan med sitt CAD-program läsa fläktens form även om den är skapad i ett helt annat program av installationsprojektören, men han kan förmodligen inte ändra den och kanske inte läsa alla övriga egenskaper. I ett annat program kan någon annan göra kostnadsberäkningar för produktion eller drift på basis av data som finns för objektet. Tillämpning av IFC i Sverige sid 18

Interoperabilitet Rent praktiskt kan data utväxlas via filer eller genom ett databasgränssnitt. I det första fallet använder IFC ett format standardiserat av STEP (part 21). Det finns ett antal hjälpmedel (toolboxes) som kan användas för att läsa och skriva dessa filer, liksom hjälp för hantering av databaser. Dessutom skall det vara möjligt att via ett API eller liknande mekanism ha en direktkommunikation mellan program. Något sådant är inte utvecklat ännu. Syftet med IFC är att produktmodellen skall kunna användas av många olika typer av programvaror, det vill säga att objekten skall förstås av olika applikationer de skall vara interoperabla. IAI menar att byggprocessen i dag präglas av en splittring genom att aktörerna har skilda informationssystem. Informationen som delas i processen måste kommuniceras på olika sätt mellan de olika systemen, all nödvändig information kan inte överföras direkt mellan systemen utan måste återskapas. Detta är kända problem som hämmar effektiviteten i IT-utvecklingen. IAI kallar detta The Fractured Information System. IAI presenterar en vision där alla datorprogram involverade i bygg- och förvaltningsprocessen kan arbeta mot en och samma gemensamma datamodell. Modellen används för att representera strukturen av informationen och relationen mellan informationsmängder. Figur 1. The fractured information system Figur 2. The shared object model Det är lätt att acceptera de principiella fördelarna i ett sådant resonemang. Informationen lagras och uppdateras på ett samlat ställe och alla kan använda information från samma källa och alla förstår den. Problemen med informationsförluster i övergången mellan olika skeden och parter försvinner eller minskar. Somliga menar att detta snarare är en mera symbolisk bild av informationshanteringen. Projektdatabasen eller modellen kan i själva verket vara distribuerad hos flera olika parter på olika datorer men den kan hållas samman av ett administrativt system. Tillämpning av IFC i Sverige sid 19

Versioner I praktiken är vi långt från visionen. I dag tillhandahåller IFC endast ett gemensamt neutralt filformat som underlättar överföring av information mellan parterna i processen. Även med enbart det sistnämnda alternativet skulle IFC kunna innebära ett mycket stort framsteg vad gäller informationshanteringen i hela processen. Detta är vad många önskar sig och har ett praktiskt behov av. Dagens utväxling av filer mellan olika CAD-program möjliggör i allmänhet inte överföring av information om byggobjektens egenskaper utan enbart de grundläggande geometriska entiteterna. Det tar troligen mycket lång tid innan en gemensam databas kan förverkligas och marknaden är inte heller mogen för så genomgripande förändringar omedelbart. IFC-modellen tillhandahålls som en formell specifikation av krav som kan användas för att skapa IFC-anpassade applikationer. IFC använder både process- och objektmodeller. Varje projekt inom IFC beskriver en objektmodell som specificerar vilka data som behövs i den affärsprocess som man arbetar med. Processmodeller beskrivs i en grafisk notation som kallas IDEF0. Objektmodellerna finns i flera olika representationer. Den vanligaste är tabellformen. För den grafiska notationen används EXPRESS-G och för specifikationer används EXPRESS-L. IFC-filen är specificerad i ISO STEP Part 21-format. Detta är en ASCII-fil som på sikt kommer att ersättas eller finnas parallellt med en XMLbaserad fil, Part 28. Alla dessa filer kommer från ISO STEP-standarden. För dem som utvecklar programvaror håller man på att ta fram ett Interface Definition Language. IFC har hittills släppts i fyra officiella versioner. Den första, version 1.0 omfattade endast en mycket liten del av den totala produktmodellen. Med version 1.5 skapades grunden för implementering i kommersiella programvaror. Erfarenheter och problem vid denna gjorde att man gav ut en uppdatering benämnd version 1.5.1. Det är på denna grund några tillämpningar blivit certifierade. Version 2.0 har utökat täckningen av domänerna och är den senast publicerade versionen och den som vårt projekt studerat. Nästa version har arbetsnamnet 2.x och den fastställs enligt planerna hösten 2000. Den bygger på en något annorlunda strategi än tidigare där det är meningen att skapa en plattform med en stabil kärna som kan förbli oförändrad under en längre tid. Förändringar som behövs för olika tillämpningar och anpassningar skall göras som platform extensions. Sådana kan senare komma att inarbetas i kommande versioner. Version 2.x skall också arbeta mera med tillämpningsfall ( use cases ), vilket skulle passa bra för den fortsatta utvecklingen i Sverige. Tillämpning av IFC i Sverige sid 20

Tillämpningsområde Problemområden IAI har målet att möjliggöra mjukvarusamverkan (software interoperability) inom bygg- och fastighetssektorn. Det innebär att IFC skall kunna användas inom i princip alla datorprogram som behandlar information om byggnadsverken och processerna i alla skeden av deras livscykel. Detta är ett mycket ambitiöst mål och det behövs mycket kraft för att få ett sådant genomslag. Om man uppnår det, eller bara en huvuddel av det, kommer det att få en mycket stor betydelse. IFC definierar objekten annorlunda och har inte heller samma objekt som ISO 12006-2 även om vissa är snarlika. Det betyder att man, om man vill använda BSAB som klassifikation, måste göra det genom en tolkning av IFCs schema. Man använder bara vissa delar av IFC och det är därför nödvändigt att dokumentera hur kopplingen med BSAB görs, så att de som implementerar det gör på samma sätt. Liknande problem kommer naturligtvis att uppstå när man vill använda andra klassifikationssystem tillsammans med IFC. Eftersom det redan finns en stor mängd objekt definierade i IFC (såsom vägg, dörr, fönster) kan man ställa sig frågan om det inte skulle gå att använda dessa vid informationsutbyte i stället för nationella klassifikationssystem. Ett skäl till att det skulle bli svårt är att det helt enkelt inte finns tillräckligt många objekt för att få tillräcklig precision. Definitioner av objekten på den nivå som behövs för praktisk tillämpning i byggprocessen saknas i IFC och man förefaller inte heller ha för avsikt att skapa alla objekt. Ett område som man direkt kan se vissa problem med är de delar som inte ritas, såsom förarbeten, tillfälliga arbeten och liknande. För dessa saknas objekt i IFC. Det betyder till exempel praktiska problem att lagra en kalkyl i en IFC-fil. Vi vet inte heller hur ett programs interna sätt att välja objekt påverkar möjligheterna att kombinera det med en kod ur BSAB-systemet. Hittills har utvecklingen av IFC inriktats på området (domänen) arkitektur. Övriga är projektstyrning (CM), förvaltning (FM) och vvs (HVAC) och inom dessa har mycket litet gjorts ännu. Detta är i sig en mycket stark begränsning eftersom samverkan i byggprocessen till stor del går ut på att överskrida blockgränser. En annan begränsning är att man hittills också bara begränsat sig till en CAD-vy av modellen. Lite förenklat uttryckt kan man säga att IFC på grund av sin flexibilitet kan beskriva vad som helst på hur många sätt som helst. Detta kan tänkas skapa problem om det leder till att olika program tolkar filerna olika. Någon form av validering måste göras vid överföring till eller från en IFC-fil. Ett sätt som man arbetar med är att programmen klassas med avseende på överensstämmelsen med specifikationerna ( conformance class ). Inget enskilt program kommer förmodligen att kunna tillämpa eller ha behov av att använda hela IFC-modellen. Tillämpning av IFC i Sverige sid 21

Objektens egenskaper Grafik Attribut Med IFC kan man beskriva objektens geometriska egenskaper mycket utförligt. Däremot finns inte några regler för hur den grafik som visas på ritningar skapas. Det är möjligt att detta inte utgör ett problem ur tillämpningssynpunkt. Praxis för byggritningar är olika i olika länder vad gäller linjebredder, linjekaraktärer och andra delar av redovisningen. Problemet måste i varje fall lösas i applikationerna. Det som rent praktiskt kan begränsa överföringen av geometriinformation är i dagsläget CAD-programmens möjligheter att representera den. Andra egenskaper än de geometriska kan också beskrivas med IFC. Varje objekt kan ha Properties eller Property Set, alltså en grupp av egenskaper. De finns fördefinierade för varje objekt som finns i IFC. Här behövs helt klart nationella anpassningar till exempel beroende på nationella standarder och praxis. I Sverige används AMA som referensverk för beskrivningar. Det innebär att en stor del av egenskapsredovisningen görs via klassifikationen; en BSAB-kod och rubrik hänvisar till motsvarande ställe i AMA samt enligt pyramidregeln alla överordnade koder och rubriker. Dessa krav skrivs alltså inte explicit in i beskrivningen. Andra kategorier av egenskaper bygger på standarder. Om det finns ett behov och krav att denna dokumentation skall kunna sparas i produktmodellen behövs regler och rekommendationer för detta. Det behövs också på motsvarande sätt praktiskt tillämpbara metoder att på ett entydigt sätt knyta information om inbyggda varor och produkter. Att informationen finns är byggherrens/ägarens ansvar och det kommer att få ökad betydelse i framtiden. Relationer En av svårigheterna med att förstå IFC är dess användning av objektifierade relationer. Objekten pekar inte direkt på varandra utan mellan dem finns ett relationsobjekt och det är detta som pekar på de objekt som är relaterade. Detta gör modellen mycket flexibel men det gör det också svårt att förstå hur modellen avses fungera [7]. Vad är byggproduktmodellen? Det är kanske ett akademiskt problem vad en byggproduktmodell omfattar. Det anses ofta att det är all information om byggnadsverket under dess livscykel. I praktiken är detta ingen realistisk definition. Mycket av informationen berör kanske byggnaden enbart perifert och många processer skapar information som härleds från eller beräknas ur den befintliga. Ibland skapas ny specifik information som inte återanvänds i andra processer. En avgränsning till gemensam information kanske bör göras men inte heller den är entydig. Skall man med gemensam mena den information som är gemensam för alla Tillämpning av IFC i Sverige sid 22

processer eller räcker det om den är gemensam enbart för två processer som delar information eller samverkar på annat sätt? Detta begreppsområde bör klaras ut i det fortsatta arbetet. Produktmodell blandas ibland ihop med projektdatabas. Utan att göra anspråk på fullständighet kan vi här försöka klargöra några principer. Produktmodell är en konceptuell modell av en produkt (byggnad). Informationen om ett visst byggnadsverk eller projekt kan lagras i en eller flera datafiler. Programmen kan använda IFC-filer för detta ändamål. Om varje program kan skapa en egen IFC-fil och läsa andra IFC-filer kan programmen kommunicera, i varje fall på en viss nivå, men det går inte att tala om en gemensam IFC-modell eller att summan av filerna utgör modellen. Ett problem kan vara att programmen tolkar IFC-objekten olika och ett annat att IFC inte på ett entydigt sätt kan lagra all den information som är nödvändig för programmens funktion. För att det skall vara meningsfullt att ha en gemensam IFC-fil som också kan ge en entydig representation av byggnadsverket oberoende av använda program ställs det mycket höga krav på programmen och på att det faktiskt går att göra denna representation med hjälp av IFC, alltså att skapa en gemensam produktmodell med flera olika program. Dagens situation Utvecklingen av datorprogram är probleminriktad, det vill säga att man har gjort ett program som har löst en viss konkret arbetsuppgift. Det innebär att användaren fått mata in data via tangentbord och hämta uppgifter ur ett bibliotek eller skapa dem på annat sätt. Programmet har sedan utfört beräkningar eller annan bearbetning för att sedan presentera resultatet på bildskärm eller som utskrift på papper. Mera sällan har programmen gjorts som en del i en process där utdata från ett kan användas som indata i ett annat utan manuell överföring. Varje program har lagrat data i filer vars struktur och notation (format) är specifika för just detta program. Många program kan naturligtvis läsa och skriva andra filformat men inte alltid till 100 % utan ibland uppkommer informationsförluster eller fel. För bygg- och fastighetssektorn är detta högst påtagligt, speciellt vad gäller CAD. Alla program har sina egna filformat och konverteringar mellan dem skapar alltid informationsförluster. Problemen har faktiskt ökat i och med att programmens funktioner ökar. För att lösa dem behövs inte bara ett neutralt filformat utan ett gemensamt sätt att beskriva (modellera) verkligheten. Detta är vad IFC försöker åstadkomma för bygg- och fastighetssektorn. Verkligheten är inte något entydigt, inte ens om man enbart betraktar byggnadsverk. Byggandet är mycket starkt förknippat med den lagstiftning, den kultur och det klimat som finns i olika länder och våra föreställningar om hus är beroende av detta. Man behöver inte gå så långt som att peka på så skilda byggnadsverk som naturfolkens hyddor och moderna storstäders skyskrapor. Det är helt naturligt mycket svårt att skapa gemensamma modeller för byggandet i olika länder. Tillämpning av IFC i Sverige sid 23

Vi tror därför att det som IAI kan och borde bidra med är ett flexibelt ramverk som tillåter olika nationella anpassningar och vi undersöker i detta projekt en anpassning till BSAB. Det innebär att man generellt kan studera IFC i förhållande till ISO 12006-2. Detta ramverk finns det ju ganska stor enighet kring. Om IFC inriktades mot att följa den modellen skulle i varje fall de nationella klassifikationssystem som överensstämmer med ISO 12006-2 lätt kunna användas i IFC. En del av den kritik man kan rikta mot IFC är just bristen på samstämmighet med ISO 12006-2. Behov och nytta För de flesta vore det nog fullt tillräckligt om IFC kommer att möjliggöra problemfria överföringar mellan CAD-program under projektering och dessutom en framtidssäkrad lagring av information om byggnadsverket. De önskemål och behov man har ses helt naturligt utifrån de problem och svårigheter som man har i dagens läge, men detta kan begränsa tanken. Om vi försöker betrakta byggprocessen mera generellt och formulera de möjligheter som finns inom nära räckhåll, och som kan påskyndas av den utveckling som IFC är en del av, kan man säga att kärnan ligger i produktmodelltänkandet. Precis som det grundläggande konceptet för kontraktshandlingar vid en entreprenad är att de olika dokumenten kompletterar varandra bör det för olika program vara att de kompletterar varandra, det vill säga att de utför olika uppgifter. Det är inte rimligt att tro att man enbart med CAD-programmet helt och hållet specificerar byggnadsverket. Om programmen kan operera på samma produktmodell kan man lättare ta fram olika specialiserade program som kan möta olika användares behov i skilda situationer och kanske göra det bättre än ett stort generellt program. I viss mån förekommer redan denna specialisering inom en del programvaruföretags utbud av produkter. Autodesk och Bentley har exempelvis program specialiserade på GIS, CAD, visualisering, animering. Samverkan mellan programmen fungerar dock bara inom familjen. Helt klart ligger det i företagens affärsidé att på detta sätt få grepp om kunderna, men det är till förfång för användarna generellt. Ett behov i byggprocessen är att få bättre överblick över och samordna de stora informationsmängder som behövs för ett byggprojekt. Detta skulle kunna göras om all information vore inordnad i samma struktur. Då kan man göra en samgranskning oberoende av vilket program som använts för att skapa informationen. På samma sätt som man tidigare lade två ritningsoriginal på ljusbordet eller numera gör motsvarande i CAD-programmet via bildskärmen, skulle all information kunna samgranskas oberoende av program som skapat den. Det skulle med programhjälp rent av vara möjligt att finna bristande överensstämmelser eller dubblerad information i de olika källorna. Ett exempel på sådan kontroll är den som bör göras mellan ritning och beskrivning och det är inte svårt att finna ytterligare områden där en produkt skulle ge stor nytta. Tillämpning av IFC i Sverige sid 24

Granskningen kan ske med hjälp av specialprogram eller via tilläggsmoduler i de befintliga programmen och det skulle ge möjlighet till förändrade arbetsmetoder; granskningen sker parallellt i stället för i efterhand. Den prototyp som utvecklats i projektet ger en fingervisning om det ovan beskrivna sättet att betrakta informationen i produktmodellen. Mekanismer för samverkan Vi skall här också försöka ge en mycket begränsad förklaringsmodell till det sätt som program kan samverka på och diskutera vissa svårigheter som ligger i sakens natur. Det som avbildas av ett hus med hjälp av ett CAD-program är i huvudsak byggdelar och byggdelstyper (enligt BSABs terminologi). Riktigare att säga är att planer, sektioner och fasader är grafiska byggdelsvyer av objekten. Genom att beteckna ( litterera ) objekten detaljerar man dem i byggdelstyper (väggtyp V1, V2 etc), vilket ofta är referenser till detaljritningar som vanligen finns på andra ritningar (i andra filer). Något konkret samband mellan objekten i olika filer etableras inte i de vanligaste programmen. I detaljritningarna redovisas även produktionsresultat, men de anges oftast bara som text. Alla byggdelar och produktionsresultat ritas inte. Om man nu vill ställa samman information ur dessa CAD-filer för en beskrivning kommer man med dagens teknik endast att få en lista av objekt som har CADprogrammets interna benämningar och utan samband sinsemellan. Om CADprogrammet ger möjlighet att sätta BSAB-koder på objekten kan denna lista på sin höjd tjäna som en checklista för beskrivningen. För att kunna få en stomme till en beskrivning behöver CAD-programmet kunna göra en sammanhängande förteckning av objekt för hela byggnadsverket inklusive relationer mellan byggdelar/byggdelstyper och produktionsresultat. I den normala projekteringssituationen finns det två ansvariga parter som skapar skilda och i viss mån överlappande CAD-modeller av huset: arkitekt och konstruktör. Byggdels- och produktionsresultatkoder på objekten liksom typbeteckningar på dem utgör samband mellan CAD-modellen och beskrivningen. Beskrivningen redovisar vissa objekt mera detaljerat och andra mer generellt än ritningarna gör. Dess objektsvy är annorlunda än CAD-filens. Att skapa en process där CAD samverkar med ett program för beskrivning och där detta hämtar data från en CAD-modell som fyller kraven ovan låter sig nog göras ganska lätt om man betraktar en statisk situation där CAD-modellen är klar. I en projekteringssituation inträffar aldrig detta och att följa upp vilka ändringar i respektive del av modellen som får konsekvenser för den andra kan knappast göras med automatik. Fortfarande finns dock mycket att vinna på att finna en bättre integration mellan processer och program. Den saknas helt i dag. En fråga att lösa är alltså hur en beskrivningsvy ser ut i IFC. Beskrivningen är ju ett mycket välstrukturerat dokument och borde vara lämpligt att testa. Ett annat exempel är produktionsplanering där man exempelvis har behov av att göra uppdelningar av objekten för olika arbetsmoment. Ett bjälklag som är ett enda ob- Tillämpning av IFC i Sverige sid 25

jekt i CAD-filen kanske måste gjutas i flera etapper. Formsättning och formrivning finns inte som objekt i CAD-filen liksom vanligen inte heller alla produktionsresultat som ingår i byggdelarna. Dessa förhållanden utgör i varje fall en komplikation i kommunikationen mellan olika program. Envägskommunikation Den modell som i huvudsak hittills prövats med IFC och som förefaller vara lämplig att använda vid pilotprojekt kan man kalla för envägskommunikation, det vill säga att man använder IFC-filer för att föra över information till andra program men inte gör någon återföring av informationen till ursprungsprogrammet. Detta är som nämnts förenat med ytterligare komplikationer som inte säkert tillför något. Genom att på detta sätt begränsa omfattningen av informationen som delas kan mera kontrollerade testförhållanden uppnås. Studier om IFC i andra länder Ett flertal demonstrationer har genomförts i IAIs regi där man visat överföring av filer mellan olika programvaror. De flesta finns dokumenterade och tillgängliga antingen via IAIs medlems-cd eller via IAIs eller lokala chapters webbplatser. En av dessa som kan nämnas var Nordic IAI-Workshop i Helsingfors november 1998. Dessa demonstrationer var en del i Spadex-projektet som ingår i VERA programmet. I IBB-nyt nr 2/2000, [8], refereras en demonstration som genomfördes på Teknik & Data 2000. De slutsatser man kan dra av artikeln är dels att intresset för IFC är stort även i Danmark, dels att IFC kan fungera väl tillsammans med traditionella samarbetsformer inom CAD (lagerteknik). Rent generellt har dessa demonstrationer ett begränsat värde. Materialet har kunnat prepareras i god tid av specialister och man visar naturligtvis bara det som fungerar! Den dokumentation som finns går inte in på teoretiska spörsmål och generella frågor. I många fall sker informationsöverföringen enbart mellan CAD-programvaror och avser enbart husbyggdelar (eftersom det inte finns något inom installation). Vad vi känner till så har mycket få, om ens någon, kritisk analys av IFCs ramverk genomförts. IFC har inte heller satts i relation till det ramverk för byggklassifikation som ISO 12006-2 utgör och inte heller till de fungerande nationella tillämpningar av byggklassifikation. I detta avseende kan arbetet i etapperna 1 och 2 i detta projekt bidra till att fylla en lucka. Dessa brister gör det svårt att bedöma hur IFC skulle fungera i en vardagsmiljö med projektering, kalkylering, produktion och förvaltning. Vi bör emellertid följa alla liknande studier för att se vilka erfarenheter som kan tas till vara utan att vi själva behöver göra om samma saker. Ett projekt som förefaller vara av nytta för oss är BLIS (Building Lifecycle Interoperable Software) som drivs i nära anslutning till VTT i Finland. Där pekar man på att Tillämpning av IFC i Sverige sid 26