AALTO-YLIOPISTON INSINÖÖRITIETEIDEN
AALTO-YLIOPISTON INSINÖÖRITIETEIDEN KORKEAKOULU Rakennustekniikan laitos Harri Niemi Tietomallien käyttö elinkaarihankkeiden suunnittelu- ja toteutusvaiheissa Diplomityö, joka on jätetty opinnäytteenä tarkastettavaksi diplomiinsinöörin tutkintoa varten. Helsingissä 29.9.2011 Työn valvoja: Professori Arto Saari Työn ohjaaja: Diplomi-insinööri Annikki Karppinen 2 AALTO-YLIOPISTON INSINÖÖRITIETEIDEN KORKEAKOULU Rakennustekniikan laitos DIPLOMITYÖN TIIVISTELMÄ Tekijä: Harri Niemi Diplomityö: Tietomallien käyttö elinkaarihankkeiden suunnittelu- ja toteutusvaiheissa Päivämäärä: 29.09.11 Sivumäärä: 110+14 Professuuri: Rakentamistalous ja talotekniikka Koodi: Rak-63 Valvoja: Prof. Arto Saari Ohjaaja: DI Annikki Karppinen Avainsanat: Tietomalli, BIM, tietomalliprosessi, IFC, suunnittelunohjaus, määrä- laskenta, yhdistelmämalli, törmäystarkastelu, elinkaarihanke. Tietomalleja käytetään rakennushankkeiden tiedonhallintaan. Eri suunnittelualat tuottavat kolmiulotteiset tietomallit, jotka ovat yhdistettävissä yhdistelmämalliksi. Tietomalleista voidaan ottaa ulos piirustukset, määrätietoa, mittatietoa ja talotekniikan analyysitietoa. Tuotantovaiheessa malleja voi käyttää esimerkiksi aikataulunhallintaan ja työmaasuunnitelman laatimiseen. Julkisen sektorin elinkaarihankkeet ovat yleistymässä Suomessa. Elinkaarihankkeissa palveluntuottajaorganisaatio vastaa pääosin hankkeen suunnittelusta ja toteutuksesta sekä järjestää rakennusten ylläpidosta sovitun sopimusjakson ajan. On palveluntuottajan eduksi valjastaa tietomallipohjaisen suunnittelun ja toteutuksen mahdollisuudet käyttöönsä kokonaistaloudellisen ja tehokkaan lopputuloksen saavuttamiseksi. Tietomallien onnistunut käyttö eri osapuolten välillä edellyttää kuitenkin yhteisiä käytäntöjä ja sujuvaa vuorovaikutusta. Tässä työssä tutkitaan tietomallien käyttömahdollisuuksia ja rajoituksia elinkaarihankkeissa. Työn päätavoitteena on täydentää Lemminkäinen Talo Oy:n aiempaa tietomalliprosessia uusilla ja päivitetyillä toimintakäytännöillä. Työ käsittelee Kuopion Elinkaarhanketta, jossa Lemminkäinen toteuttaa 5 kohdetta ja huolehtii niiden ylläpidosta 25 vuoden ajan. Työ perustuu kirjalliseen aineistoon ja case-tutkimukseen. Case-tutkimus suoritettiin haastattelemalla hankkeeseen osallistuneita osapuolia. Työn tuloksena todettiin, että tietomallipohjainen suunnittelu on toteutettava toimivan suunnitteluaikataulun mukaan. Tietomallintamiseen liittyvät asiat on määritettävä riittävän tarkasti viimeistään yleissuunnitteluvaiheen aikana. Järjestelmällinen ja jatkuva laadunvarmistus on ehdoton edellytys tietomallien hyödyntämiselle. Lisäksi määritettiin toimintaohjeet määrien ja aikataulunhallinnalle. Kuitenkin case-tutkimuksen perusteella on todettava, että talotekniset analyysit, mallinnusohjelmien tiimityöympäristöt, inventointimallin tuottaminen ja ylläpitomallin hyödyntäminen vaativat vielä huomattavasti jatkokehitystä. 3 AALTO UNIVERSITY SCHOOL OF ENGINEERING Department of Civil and Stuctural Engineering ABSTRACT OF THE MASTER’S THESIS Author: Harri Niemi Thesis: BIM-based design and construction in PPP-projects Date: 8.3.2011 Number of pages: 110+14 Professorship: Construction economics and management Code: Rak-63 Supervisor: Prof. Arto Saari Instructor: M.Sc. (tech) Annikki Karppinen Key Words: Building information Model, BIM, BIM-process, IFC, quantity sur- veying, clash detection, Public Private Partnership, PPP. Building Information Models are used to manage information in construction projects. Different engineering fields produce their models, which can be combined. Construction plans, quantities, measuring data and HVAC analysis data can be exported from the BIM. In the construction phase BIM can be used in scheduling and site planning. The Public Private Partnership -projects are becoming more frequent in finnish construction sector. The private party takes the lead in arranging the design, construction and upkeep of the building for agreed duration. It is in the interests of the private party to harness the possibilities of BIM-based design and construction to ensure an economic and efficient outcome of the project. However proper use of BIM between different parties requires mutual procedures and fluent interaction. The applications and restrictions of BIM in PPP-projects are studied in this research. The main objective for this research is to supplement Lemminkäinen Talo Oy:s previous BIMprocess with new and updated BIM-procedures. The study is about case Kuopion elinkaarihanke, in which Lemminkäinen Talo Oy has the responsibility to design, construct and provide maintenance for 25 years for 5 different buildings. The research is based on literature and a case study. Case study was conducted by interview ing parties associated with the case project. As a result of the research it was established that BIM-based design should be carried out according a strict design schedule. BIM-related matters should be defined adequately accurate in the planning phase. Systematic and continuous quality assurance is an essential prerequisite for utilizing BIM. In addition directives for BIM-based quantity surveying and 4D-scheduling were defined in this study. However, according to the case study, quite a lot of additional research is in order in the fields of HVAC analyses, BIM-teamwork environments, inventory modeling and as-built models. 4 Sisällysluettelo Esipuhe..............................................................................................................................7 1.Johdanto..........................................................................................................................8 1.1.Tutkimusongelma...................................................................................................10 1.2.Tutkimuksen tavoitteet ja rajaus............................................................................11 1.3.Tutkimusmenetelmät..............................................................................................12 2.Kirjallinen selvitys ja työn teoreettinen tausta.............................................................13 2.1.Elinkaarihankkeet...................................................................................................13 2.1.1.Elinkaarihankkeiden erityspiirteet...................................................................15 2.1.2.Elinkaarihankkeiden vaiheet............................................................................16 2.2.Case: Kuopion elinkaarihanke...............................................................................17 2.2.1.Case-hankkeen organisaatio................................................................................18 2.2.2.Case-hankkeen eteneminen.................................................................................19 2.3.Tietomallit ja tietomallipohjainen suunnittelu.......................................................20 2.3.1.Arkkitehtimalli.................................................................................................24 2.3.2.Rakennemalli...................................................................................................25 2.3.3.Talotekninen malli...........................................................................................26 2.3.4.Yhdistelmämalli...............................................................................................27 2.4.Tietomallien käyttö hankkeiden aikana ja Lemminkäisen tietomalliprosessi........28 2.4.1.Tietomallit hankevalmistelu- ja tarjousvaiheessa............................................28 2.4.2.Tietomallit suunnitteluvaiheissa......................................................................29 2.4.3.Tietomallit toteutusvaiheessa...........................................................................33 3.Case-tutkimus...............................................................................................................36 3.1.Tietomallien käyttö case-hankkeessa..................................................................37 3.2.Tietomallien käytön erityispiirteet ja edut elinkaarihankkeissa..........................39 3.3.Tietomallintamisen käynnistäminen ja aloituskokous........................................41 3.4.Tietomallintamiseen liittyvät kokouskäytännöt..................................................46 3.5.Mallien päivityskäytännöt ja muutostenhallinta.................................................48 3.6.Mallien tietosisällöt eri vaiheissa........................................................................51 3.7.Mallien mittatarkkuus.........................................................................................53 3.8.Mallien yhdistäminen ja IFC-formaatti..............................................................55 3.9.Yhdistelmämallin käyttö.....................................................................................56 3.10.Mallien laadunvarmistus...................................................................................59 3.11.Mallien työmaakäyttö.......................................................................................64 5 3.12.Määrälaskenta mallia käyttäen..........................................................................67 3.13.Synkronointi- ja tiimityötoiminnot...................................................................70 3.14.Toteumamalli ja ylläpitomallin edellytykset....................................................72 3.15.Inventointimallin luominen ja käyttö................................................................74 3.16.Tietomallien hyödyntäminen elinkaarilaskelmissa, tate-analyyseissä ja suunnitelmien vaihtoehtotarkastelussa......................................................................76 3.17.Muut tietomallimenetelmissä esiintyneet ongelmat..........................................78 4.Tietomalliprosessin kehittäminen.................................................................................80 4.1.1.Tietomallintamisen aloituskokous...................................................................80 4.1.2.Mallinnusohjeiden, aloituspohjien ja tietomalliselosteiden käyttö..................81 4.1.3.Tietomalli-integraattori ja mallin yhdistäminen..............................................82 4.1.4.Suunnitteluaikataulu ja mallien päivitys..........................................................83 4.1.5.Laadunvarmistus ohjelmistoja käyttäen...........................................................85 4.1.6.Yhdistelmämallikokoukset ja suunnittelukokoukset.......................................87 4.1.7.Työmaasuunnitelman laadinta tietomalleja käyttäen.......................................88 4.1.8.Määrienhallinta tietomalleja käyttäen..............................................................90 4.1.9.Aikataulutiedon hallinta tietomalleja käyttäen................................................94 4.1.10.Tietomallien käyttö tate-analyyseissä............................................................96 4.1.11.Kohdistusobjektin käyttö...............................................................................97 5.Tutkimustulosten arviointi............................................................................................98 5.1.Tulosten suhde aikaisempaan tutkimustietoon.......................................................98 5.2.Tulosten luotettavuus.............................................................................................99 5.3.Tulosten yleistettävyys.........................................................................................100 5.4.Jatkotutkimustarpeet.............................................................................................101 5.4.1.IFC-käännön ohjeistaminen...........................................................................101 5.4.2.Tiimityöympäristö ja mallien synkronointitoiminto......................................101 5.4.3.Solibri Model Checker –säännöstöjen kehittäminen.....................................102 5.4.4.Inventointimallin tuottaminen skannaamalla.................................................102 5.4.5.Mallinnustoleranssit ja niiden kertautuminen................................................103 5.4.6.Toteumamallin tuottaminen...........................................................................103 6.Johtopäätökset............................................................................................................105 7.Yhteenveto..................................................................................................................106 Lähdeluettelo.................................................................................................................108 Kirjallisuus.................................................................................................................108 WWW-sivut...............................................................................................................109 6 Julkaisematon aineisto................................................................................................109 Senaatti Kiinteistöjen tietomallivaatimukset:.............................................................110 Haastattelut.................................................................................................................110 Liite 1: Lemminkäinen Talo Oy:n tietomalliprosessi 2007...........................................112 Liite 2: Case Martti Ahtisaaren koulun tietomalliprosessi 2011...................................121 7 Esipuhe Tämä työ tuotettiin osana diplomi-insinööritutkintoani Aalto Yliopiston Teknillisen Korkeakoulun Rakenne- ja Rakennustuotantotekniikan laitoksella. Työn toimeksiantaja oli Lemminkäinen Talo Oy. Haluan lämpimästi kiittää työn ohjaajaani kehityspäällikkö Annikki Karppista jatkuvasta kannustuksesta ja opastuksesta. Samoin minun on annettava suuri tunnustus Lemminkäisen BIM-asiantuntijoille Artur Viritille, Matti Partaselle ja Janne Salinille, jotka antamiensa haastattelujen lisäksi osasivat ohjeistaa minua oikealle polulle työtä tehdessäni. Samoin haluan kiittää muitakin, jotka työkiireistään huolimatta ehtivät haastateltavakseni Helsingissä ja Kuopiossa. Kiitos SimLabille ja etenkin Teemu Lehtiselle ja Matilda Smedsille ajatuksistaan aiheisiin liittyen. Lisäksi haluan kiittää perhettäni ja ystäväpiiriäni tuestaan. Kiitos isälleni Olli Niemelle, joka teki työni oikoluvun. Lisäksi kiitos valvojalleni Arto Saarelle. Tietomallit ovat osoittautuneet hyvin mielenkiintoiseksi aiheeksi tehdessä diplomityötä ja seuratessani alani kehitystä. Mallien käyttömahdollisuudet laajenevat koko ajan. Suunnittelijoilla, minulla ja muilla rakennusalan toimihenkilöillä on edessään jatkuva kiriminen, jotta meidän tietotaitomme kasvaa tietomallien kehityksen tahdissa. Helsingissä 29.9.2011 Harri Niemi 8 1. Johdanto Tämä diplomityö tuotetaan Lemminkäinen Talo Oy:lle. Työ käsittelee tietomallien käyttöä elinkaarihankkeen eri vaiheissa lukuun ottamatta tarveselvitys- sekä käyttö- ja ylläpitovaihetta. Työn piiriin kuuluvat tietomalleihin liittyvät käytännöt ja toimintaohjeet palveluntuottajaorganisaation näkökulmasta. Tietomallintamisen tekninen toteutus jää tutkimuksen ulkopuolelle. Diplomityön pääpaino on suunnittelunohjauksen käytännöissä ja menettelyissä, joilla voidaan toteuttaa kohteen mallinnus onnistuneesti ja luoda valmiudet tietomallien käytölle kohteen tuotantovaiheessa. Lisäksi keskitytään käytäntöihin, jotka ovat tietomallien avulla mahdollisia tuotannonohjauksessa. Työn tuloksista luodaan käyttökelpoiset toimintaohjeet Lemminkäinen-konsernin toimintajärjestelmää varten. Lemminkäinen Talo Oy:n diplomityöntekijä Mikko Mäläskä tekee tämän työn rinnalla diplomityön ylläpitomallin hyödyntämisestä case-hankkeen käyttö- ja ylläpitovaiheessa. Lisäksi samanaikaisesti yhteistyössä projektiorganisaation kanssa järjestetään Aalto Yliopiston SimLab-tutkimuslaitoksen tavaramerkitty AS-IS-simulointi tietomallien käytöstä Martti Ahtisaaren koulun suunnittelussa ja toteutuksessa. Case-hankkeeseen liittyy lisäksi Helsingin Yliopiston CRADLE-tutkimuslaitoksen tutkimus, joka käsittelee tietomallintamista ja sen käyttöönottoa käyttäytymistieteen kannalta. Työ pohjautuu Lemminkäinen-konsernin toimintajärjestelmän aiempiin toimintaohjeisiin sekä Salla Paloksen (os. Kuuselan) konsernille vuonna 2007 tekemään diplomityöhön: Tietomalliprosessi – Tietomallitiedon käyttö suunnittelussa, rakentamisessa ja ylläpidossa. Aiemmassa diplomityössä on muodostettu kaaviot tietomalliprosessista, joihin on linkitetty järjestelmälliset kuvaukset toiminnoista ja alustavat tietosisällöt tietomalleille rakennushankkeen eri vaiheissa. Näiden lisäksi työ tukeutuu ProIT-tietomalliohjeisiin sekä Senaatti Kiinteistöjen luomiin tietomallivaatimuksiin, joista muotoillaan parasta aikaa kehittyneempää ja laajempaa tietomallivaatimusten kokonaisuutta. Siitä pyritään myöhemmin kehittää kansallinen standardi (COBIMprojekti). Tutkimus on osa RYM Oy:n PRE (Built Environment Process Re-Engineering) – hankkeen Model Nova – työpaketin kokonaisuutta, jossa Lemminkäinen Talo Oy ja Kuopion elinkaarihanke – case ovat mukana. Model Nova –työpaketin ryhmän koordinointi- 9 vastuu on Senaatti Kiinteistöillä. Hanketta rahoitti vuonna 2010 osapuolten (ml. Lemminkäinen) lisäksi teknologian ja innovaatioiden kehittämiskeskus Tekes. Elinkaarivastuumallin käyttö on vasta nyt yleistymässä Suomen kiinteistöalalla1. Julkisella sektorilla on mittava, vanheneva kiinteistökanta, jonka kunnostamisessa elinkaaritoteutusmuodot ovat varteenotettava vaihtoehto. Useat kunnat selvittävät elinkaaritoteutusta palvelukiinteistöjen kuten koulujen kuntotason varmistamiseksi. Tähän mennessä elinkaarihankkeita on Suomessa ollut muutamia poikkeuksia lukuun ottamatta pääosin yhdyskuntarakentamisen alalla. Iso-Britanniassa ja Keski-Euroopassa elinkaarimalli on jo yleinen. Elinkaarihankkeessa palveluntuottajalle siirtyy suunnitteluratkaisusta kustannuksia, riskejä ja vastuuta koko hankkeen elinkaaren ajalle. Tällöin palveluntuottajalla on suurempi kiinnostus kehittää kokonaistaloudellinen suunnitteluratkaisu verrattuna perinteisiin hankkeisiin. Diplomityössä tutkitaan Lemminkäinen PPP Oy:n toteuttamaa Kuopion elinkaarihanke –case:a. Kuopion elinkaarihankkeessa Lemminkäinen Konserni ottaa palveluntuottajana koordinointivastuun mittavasta talonrakennusalan elinkaarihankkeiden kokonaisuudesta. Lemminkäinen solmii hankkeessa suunnittelusopimukset, joihin sisältyy kohteiden tietomallinnus. Useamman kohteen elinkaarihankkeet ovat otollisia käytännönläheiselle case-tutkimukselle monesta syystä. Ensinnäkin suurin osa hankkeen eri vaiheiden tehtävistä on yhden palveluntuottajaorganisaation vastuulla, jolloin käytännön kehitystyö ei hidastu eri organisaatioiden välisten rajapintojen takia. Toiseksi elinkaarihanke on laajin mahdollinen toteutusmuoto palveluntuottajan kannalta, jolloin sen käytäntöjä voidaan useimmiten soveltaa myös hankkeissa, joissa palveluntuottajan osuus hankkeessa on pienempi. Lisäksi palveluntuottajaorganisaation elinkaarimalliajattelu tuo lisäarvoa asiakkaalle käyttö- ja ylläpitovaiheeseen hankemuodosta riippumatta. Kolmanneksi hankkeen useat kohteet on ketjutettu peräkkäin, jolloin yhden kohteen kehitystyön tuloksia voidaan soveltaa seuraavan kohteen käytännöissä. Case-hanke on erityisen hyvä tutkimuksen kohteeksi, sillä se sisältää sekä uudisrakennus- että peruskorjauskohteita. 1 Lahdenperä & Rintala (2003): Ajatuksia Elinkaarivastuuhankkeista 10 Tietomallit (Building Information Model, BIM) avaavat palveluntuottajalle useita mahdollisuuksia niin suunnittelunohjauksen, tuotannonohjauksen kuin käyttö- ja ylläpitovaiheen hallintaankin2. Lemminkäinen käyttää tietomalleja hankkeessa useassa eri roolissa. Ensinnäkin rakennuttajan roolissa on osattava vaatia suunnittelijoilta riittävää tietosisällön tasoa ja virheettömyyttä tietomallinnuksessa. Palveluntuottajaehdokkaan on tarjouskilpailuvaiheessa osattava käyttää tietomallia edukseen esimerkiksi kustannuslaskennassa ja suunnitteluratkaisun esittelemisessä Kuopion kaupungille. Kohteiden toteuttajana sen on osattava hyödyntää tietomallin lukuisia mahdollisuuksia tuotannonohjauksessa ja rakennusvaiheen aikaisessa suunnittelunohjauksessa. Kohteen valmistuttua palveluntuottajaorganisaatiolla on vielä ylläpitovelvollisuudet, jolloin tietomallit voidaan mahdollisesti hyödyntää huoltokirjan tavoin tai sen rinnalla apuvälineenä. Tietomallien käytön yleistyessä on olennaista koota yhteen selkeät, yhtenäiset toimintaohjeet niiden käytöstä. Lisäksi on tutkittava, millaisia puuttuvia ohjeita tulisi kehittää olemassa olevien rinnalle. Tämän ohella on tunnistettava puutteet olemassa olevissa menetelmissä. 1.1. Tutkimusongelma Elinkaaritoteutusmuotoisissa hankkeissa ei ole aiemmin dokumentoitu ja jäsennetty selkeitä, keskenään yhteensopivia toimintaohjeita tietomallien käytöstä. Mallien hyödyntämisestä puuttuu järjestelmällisyys, jolloin mallien käyttö ei ole vielä luonteva osa elinkaarihankkeen eri vaiheiden etenemistä. Järjestelmällisten menetelmien kehittymisen myötä saataneen tietomallien käytöstä täysi hyöty. Palveluntuottajaorganisaatioilla on aiheen piiristä tietotaitoa sekä suunnittelijoiden että työmaaorganisaatioiden puolella, mutta yhtenäisten käytäntöjen puuttuessa osapuolten näkemykset mallien käyttötarkoituksista ja – mahdollisuuksista poikkeavat toisistaan. Tällöin myös projektikohtainen tietomallien käytön tietotaito jakautuu organisaatiossa epätasaisesti aiheuttaen merkittäviä ongelmia osapuolten toiminnan yhteensovituksessa. Lisäksi tietomallien kehittyessä yhä pidemmälle törmätään useisiin käytännön ongelmiin. Näiden vaikutusta voidaan minimoida kokoamalla organisaation käytettäväksi yhteiset toimintamenetelmät sekä jalostamalla tietomallien teknistä käyttöä jatkuvasti. 2 Palos, Salla (2010):Tietomalliprosessi – Tietomallitiedon Käyttö Suunnittelussa, Rakentamisessa Ja Ylläpidossa 11 1.2. Tutkimuksen tavoitteet ja rajaus Tavoitteena on koota yrityksen toimintajärjestelmää varten järjestelmälliset menettelyt ja toimintaohjeet tietomallien käytöstä työkaluina elinkaaritoteutuksessa. Nykyisten käytössä olevien prosessien joukosta kerätään ne, jotka ovat aiemmin jääneet dokumentoimatta. Näiden lisäksi arvioidaan, millaisia puuttuvia toimintoja ja menetelmiä on kehitettävä. Nämä työkalut tulevat käyttöön hankkeissa, joissa Lemminkäisen kuuluu palveluntuottajan roolissa tarkastella kohteen elinkaariedullisuutta, tuottaa energia- ja olosuhdesimulointeja sekä tutkia käyttö- ja ylläpitovaiheen tarpeita. Uudet suunnitteluvaiheen sekä tuotantovaiheen toimintaohjeet täydennetään yrityksen toimintajärjestelmään vanhojen tietomallin käyttöön liittyvien ohjeiden rinnalle. Tavoitteena on lisäksi tutkia, mitkä tietomallien käyttömahdollisuudet korostuvat palveluntuottajaosapuolelle elinkaarihankkeissa perinteisiin rakennushankkeisiin verrattuna. Työssä selvitetään myös, mihin käytännön ongelmiin nykyisissä tietomallikäytännöissä on törmätty suunnittelutoimistoissa ja työmaalla case-hankkeen aikana. Menetelmiä tutkiessa pyritään selvittämään selkeät projektin käynnistysohjeet, kokouskäytännöt, osapuolten tehtävänkuvaukset, mallien yhteensovitus- ja päivityskäytännöt, mallien tietosisältöjen minimitasot eri vaiheissa, tuotannonohjauksen menetelmät ja niiden edellytykset sekä muut projektinhallinnan käytännöt. Työn tavoitteet ovat: • Tunnistaa tietomallintamisen erikoisseikat elinkaarihankkeissa. • Olemassa olevien dokumentoimattomien menetelmien tunnistaminen, kokoaminen ja järjestäminen. • Uusien puuttuvien menetelmien kehitystarpeen tunnistaminen ja eritteleminen. • Case-hankkeessa tunnistettujen tietomallien käyttöön liittyvien ongelmien eritteleminen, ja mahdollisten jo kehitettyjen ratkaisukeinojen esittäminen. Työ rajataan käsittelemään elinkaarihankkeiden tarjous-, suunnittelu- ja rakentamisvaiheita. Tarveselvitys- ja hankesuunnitteluvaiheet ovat tilaajan vastuulla, eikä niissä hyödynnetä tietomallintamista, joten ne jäävät työn ulkopuolelle. Käyttö- ja ylläpito- 12 vaihe rajataan myös työn ulkopuolelle ja siitä tuotetaan rinnakkainen diplomityö. Lisäksi työ rajataan käsittelemään ainoastaan Kuopion elinkaarihanke –case:a ja sen sisältämiä kohteita. Työssä voidaan kuitenkin sivuta vastaavia hankkeita ja viitata aikaisemmissa hankkeissa kertyneisiin kokemuksiin. Muiden elinkaarihankkeen toteutusmuotovariaatioiden tietomallintamismahdollisuuksia liittyen esimerkiksi käyttäjäpalveluihin ei tutkita. Työ koskee pääasiassa arkkitehti-, rakenne-, talotekniikka- ja yhdistelmämallien käytäntöjä. Työssä pitäydytään mallien tietosisällössä, tarkistamisessa, suunnittelunohjauksen, projektinhallinnan ja työmaakäytön menettelyissä sekä osapuolien yhteis- koordinoinnissa. Tietomallintamisen tekniset yksityiskohdat itsessään jäävät työn ulkopuolelle. Ohjelmistojen käytössä ilmenevät ongelmat tuodaan työssä esiin, mutta niiden ratkaiseminen rajataan työn ulkopuolelle. 1.3. Tutkimusmenetelmät Diplomityö koostuu teoreettisesta, kirjallisen aineiston osuudesta ja empiirisestä osuudesta. Empiirisessä osuudessa käytetään tutkimusmenetelmänä puolistrukturoituja teemahaastatteluja. Diplomityössä haastatellaan case-hankkeen suunnittelijoita sekä suunnittelunohjauksen ja toteutusorganisaation toimihenkilöitä. 13 2. Kirjallinen selvitys ja työn teoreettinen tausta 2.1. Elinkaarihankkeet Elinkaarihankkeet viittaavat tämän työn piirissä elinkaarivastuuhankkeisiin, joista käytetään myös käsitteitä elinkaarimalli, elinkaaritoteutus, elinkaaripalvelu ja elinkaarihankinta. Englannin kielessä käytetään yleensä termiä public private partnership PPP. Elinkaaritoteutusmuodolla tarkoitetaan hankkeita, joissa palveluntuottajan ja tilaajan väliseen sopimukseen sisältyy palvelun edellyttämä kiinteistö tai infrastruktuuri 3. Rakennusteollisuuden alalla elinkaarihankkeet tarkoittavat pitkäaikaista ylläpitosopimusta, johon sisältyy kohteiden suunnittelu sekä toteutus 4. Talonrakennusalalla on useita elinkaarimallin variaatioita, jotka on esitelty kuvassa 1. Toteutusmuodon variaatiosta riippuen palveluntuottajaosapuolelle kuuluu kohteen rahoitus, omistus, suunnittelu, rakentaminen, kiinteistöpalvelut, käyttäjäpalvelut, pääkäyttäjätoiminnot sekä mahdollinen täydentävä käyttö. Elinkaarisopimukset perustuvat kiinteisiin palvelumaksuihin, joihin vaikuttavat mahdolliset kannustimet ja sakot, jotka määräytyvät palvelutason mukaan. Elinkaarihankkeet ovat osa yleistä palveluyhteiskunnan trendiä, jossa tuotteet ja palvelut yhdistetään kokonaisuuksiksi avaimet käteen – periaatteen mukaisesti. Tällöin asiakkaan ei tarvitse huolehtia ydintoimintojensa ulkopuolisten prosessien yhteensovittamisesta. Palveluntuottajan rahoitusta sisältävissä elinkaarihankkeissa vapautuvat julkisen sektorin resurssit muuhun käyttöön. Elinkaaritoteutusmuoto onkin osoittautumassa käyttökelpoiseksi keinoksi vähentää julkisen sektorin korjausvelkaa, joka etenkin Suomessa on kasvamassa yhä mittavammaksi kiinteistökannan vanhentuessa5. Suomessa elinkaarihankkeita on ollut esimerkiksi E18-valtatien Muurla-Lohja osuuden elinkaarihanke sekä Kuninkaantien Lukion ja Kaivomestarin uimahallin elinkaarihanke. Lisäksi useat kunnat ovat kilpailuttamassa tällä hetkellä useita hankekokonaisuuksia esimerkiksi julkisten palvelukiinteistöjen peruskorjaamiseksi. Ulkomailla elinkaarivastuumallia on käytetty jo 90-luvulta asti. 3 Lahdenperä & Rintala (2003): Ajatuksia Elinkaarivastuuhankkeista 4 Lahdenperä, Nykänen, Rintala (2006): Tilapalveluhankkeiden Vaihtoehtoiset Toimintatavat 5 Lahdenperä & Rintala (2003): Ajatuksia Elinkaarivastuuhankkeista 14 Kuva 1. Elinkaarimallien päätyypit6 6 Lahdenperä, Nykänen, Rintala (2006): Tilapalveluhankkeiden Vaihtoehtoiset Toimintatavat 15 2.1.1. Elinkaarihankkeiden erityspiirteet Kiinteistöt ovat pitkäaikaisia investointeja ja siten elinkaaripalvelusopimusten kesto on yleensä vähintään 15 vuotta, jotta sopimusten palvelumaksut eivät nouse liian korkeiksi, ja jotta elinkaarisopimus olisi tarjouskilpailussa mahdollisimman houkutteleva 7. Lisäksi elinkaarihankkeisiin saatetaan liittää yhteen useampi kohde, jotta ylläpidon järjestäminen olisi palveluntarjoajille mielekkäämpää. Pitkällä sopimuskaudella varmistetaan, että kiinteistön käyttökelpoisuus julkisten palveluiden järjestämistä varten säilyy hyvänä koko arvioidun elinkaaren ajan. Tämä edellyttää tietenkin, että tarjouskilpailussa on onnistuttu valitsemaan vakavarainen ja kyvykäs palveluntuottaja. Lisäksi pitkällä sopimuskaudella voidaan optimoida rakennus-, käyttö- ja ylläpitokustannukset8. Vastaavasti palveluntuottajaorganisaatio saa tasaisen ja varman tulonlähteen sen sitomia resursseja vastaan, sillä julkisen sektorin maksukyky pitkällä aikavälillä on vakaa. Kaiken lisäksi elinkaarimallin mukaisella pitkäaikaisella kumppanuudella voi palveluntuottaja kehittää liiketoimintaa sekä kohteen osalta että yleisellä tasolla. Palveluntuottajan on elinkaarihankkeessa otettava tilaajan ja käyttäjän tarpeet paremmin huomioon kuin perinteisessä kokonaisurakassa. Vastapainoksi palveluntuottaja saa useimmiten suunnittelua sisältävissä elinkaarihankkeissa kehittää suunnitteluratkaisua haluamaansa suuntaan tavoitteena kokonaistaloudellinen ratkaisu. Palveluntuottaja voi myös jakaa ja yhdistää hankkeen tehtävät osapuolten välillä haluamallaan tavalla. Laadukkaalla suunnitteluratkaisulla saavutetaan tarjousvaiheessa kilpailuetu. Suunnitteluratkaisujen huollettavuus sekä etenkin energia- ja kustannustehokkuus vaikuttavat merkittävästi pitkäaikaisen sopimuksen kustannuksiin. Elinkaarisopimuksessa määritetty palvelutaso on ylläpidettävä. Sopimuksessa määritetystä palvelutasosta poikkeaminen johtaa maksuerästä tehtäviin vähennyksiin, jotka perustuvat maksumekanismin laskentakaavoihin9. Vähennykset vaikuttavat vain palvelumaksun muuttuvaan osaan. Hankkeiden sopimuksiin voi sisällyttää myös kannustimia, mutta se ei ole yleistä. 7 Hänninen (2009): Elinkaarimallit Kuntien Palvelutuotannossa 8 Lahdenperä, Nykänen, Rintala (2006): Tilapalveluhankkeiden Vaihtoehtoiset Toimintatavat 9 Hänninen (2009): Elinkaarimallit Kuntien Palvelutuotannossa 16 Elinkaarihankkeissa on hyvä soveltaa integroidun elinkaarisuunnittelun periaatetta. Integroidussa elinkaarisuunnittelulla tarkoitetaan rakennuksen ja sen osien kokonaisvaltaista suunnittelua, jossa otetaan huomioon kaikki oleelliset vaatimusryhmät ja otetaan huomioon kaikilta osin koko suunnitteluelinkaaren ajanjakso10. Integroidun elinkaarisuunnittelun konseptia ei tule sekoittaa Integrated Project Delivery (IPD) –toteutusmuotoon. IPD-konsepti on Yhdysvalloissa 2000-luvulla kehitetty toimintamalli, jossa projektin keskeiset osapuolet muodostavat yhteisen kumppanuussopimuksen11. Sopimuksessa painottuvat keskinäinen luottamus, avoimuus ja tasa- puolinen palkitseminen, jos projektin yhteiset tavoitteet saavutetaan. Samoin projektin riskit jaetaan. Sen sijaan, että eri osapuolet osallistuisivat hankkeeseen ajaen vain omaa etuaan ja noudattaen tarkasti sopimusteknisesti määritettyjä tehtäviään, he pyrkivät maksimoimaan koko organisaation tehokkuuden saumattomalla yhteistyöllä. Tietomallien hyödyntäminen on olennainen osa IPD-konseptia. Elinkaarihankkeen erityispiirteenä on riskien jakautuminen osapuolten kesken. Elinkaarisopimusten tavoitteena on, että riskistä on vastuussa se osapuoli, joka pystyy parhaiten sen hallitsemaan. Case-hankkeessa Kuopion kaupunki kantaa riskin energian yksikköhintojen muutoksesta kun palveluntuottaja vastaa kulutuksen määräriskistä12. Hankkeen palveluntaso ja riskinhallinnan määrittäminen edellyttää, että elinkaarihankkeen tarjouspyynnön ja –sopimuksen muotoileminen on tehtävä todella tarkasti ja selkeästi, jotta hankkeen sisällöstä ei jää epäselvyyttä. Talonrakennusalan elinkaarihankkeet koostuvat tarveselvitys- ja hankesuunnitteluvaiheesta, tarjousvaiheesta, yleisja toteutussuunnitteluvaiheesta, toteutusvaiheesta sekä käyttö- ja ylläpitovaiheesta13. 2.1.2. Elinkaarihankkeiden vaiheet Tarveselvitys- ja hankesuunnitteluvaiheessa tilaaja päättää valitaanko hankemuodoksi elinkaarimalli. Tilaajan velvollisuus viimeistellä hankkeen tarjouskilpailun lähtökohdat korostuu elinkaarihankkeissa. Hankkeen palvelutaso täsmentyy urakkaneuvotteluissa. 10 Sarja et al (2003): Inducon - Rakennuskonsepti 11 Wang, Jilei (2008): Integrated Project Delivery – Achieving Relational Contracting Through Traditional Management Methods 12 Kuopion elinkaarihankkeen elinkaaritoteutuksen tarjouspyyntö: http://lehdet.lehtiyhtyma.fi/kuopio/tarjouspyynto_elinkaaripalvelut.pdf (luettu 21.10.2010) 13 Kankainen & Junnonen (2001): Rakennuttaminen 17 Tarjousvaiheessa potentiaaliset palveluntuottajaosapuolet tuottavat omat suunnitelmansa hankkeen kohteista tarjouspyyntöasiakirjoihin ja hankesuunnitelmaan sekä tilaohjelmaan perustuen14. Tilaaja on saattanut tuottaa myös luonnossuunnitelmat. Etenkin jos hankkeeseen kuuluu useampi kohde, on tarjouslaskenta paljon työläämpää perinteisiin urakkakilpailuihin verrattuna. Tämän vuoksi kirjallisuudessa suositellaan, että tarjouskilpailusta tehdään suljettu kutsukilpailu, jossa suoritetaan esivalinta 15. Kilpailuun kutsutaan vain ne tarjoajat, joilla on valmiudet hankkeen suorittamiseen ja mielenkiintoa tehdä tarkkaan laskettu tarjous. Jos tarjoajia on liikaa, ne tuskin ovat valmiita uhraamaan tarjousvaiheessa suurta määrää resurssejaan tarkan tarjouksen laskemiseksi. Mallintamista voidaan tarjousvaiheessa hyödyntää osana suunnittelua ja laskentaa. Elinkaarihankkeiden suunnittelu- ja toteutusvaiheet etenevät perinteisten urakkamuotojen mukaan. Kuitenkin elinkaarihankkeessa korostuvat suunnittelun ja toteutuksen kaukokatseisuus, sillä palveluntuottajanorganisaation on huolehdittava hankkeen pitkän aikavälin tavoitteista. Palveluntuottajaorganisaatio voi jakaa toteutuksen pienempiin urakoihin ja palvelusopimuksiin parhaiten katsomallaan tavalla. Tietomallintamisen suurimmat hyödyt saavutetaan suunnitteluvaiheessa. Kohteiden toteutuksen jälkeen alkaa käyttö- ja ylläpitovaihe, jolloin palveluntuottajaorganisaatio luovuttaa kohteen käyttäjille. Tässä vaiheessa palveluntuottajaorganisaatio järjestää ylläpidon ja kiinteistöpalvelut, joihin sisältyy yleensä mm. energiakustannukset, siivous ja laitteiden huolto16. Sopimuksesta riippuen järjestetään esimerkiksi vartiointi-, catering- ja aulapalveluita sekä muita käyttäjäpalveluita. Jos palveluntuottajalle kuuluu pääkäyttäjätoiminnot tai täydentävä käyttäjätoiminta, se organisoi omalta osaltaan tilojen käyttöä. 2.2. Case: Kuopion elinkaarihanke Hankekokonaisuuteen kuuluu kaksi peruskorjattavaa koulua, kaksi uutta koulua ja yksi uusi päiväkoti sekä kohteiden ylläpito vuoteen 2036 asti17. Laajuudeltaan tilat ovat lähes 37 000 brm2 ja opetus- ja hoitotilaa on mitoitettu n. 2150 oppilaalle ja 75 päiväkotilapselle. Hankkeen kokonaisarvo palveluntuottajalle on n. 93,5 milj. €, josta käyttö- ja 14 Kuopion elinkaarihankkeen elinkaaritoteutuksen tarjouspyyntö: http://lehdet.lehtiyhtyma.fi/kuopio/tarjouspyynto_elinkaaripalvelut.pdf (luettu 21.10.2010) 15 Lahdenperä, Nykänen, Rintala (2006): Tilapalveluhankkeiden vaihtoehtoiset toimintatavat 16 Hänninen (2009): Elinkaarimallit kuntien palvelutuotannossa 17 Kuopion elinkaarihankkeen elinkaaritoteutuksen tarjouspyyntö: http://lehdet.lehtiyhtyma.fi/kuopio/tarjouspyynto_elinkaaripalvelut.pdf (luettu 21.10.2010) 18 ylläpitovaiheen maksueriä on noin puolet.Hankkeen uudisrakennuskohteet ovat Martti Ahtisaaren koulu, Puijonsarven koulu ja Puijonlaakson päiväkoti. Rajalan koulu ja Pohjantien koulu peruskorjataan. Toteutusmuotona on käyttäjäpalveluita sisältävä elinkaaritoteutus, jossa vain rakennusaikainen rahoitus on palveluntuottajan hoidettavana. Suunnittelusta, rakentamisesta ja teknisestä ylläpidosta vastaa palveluntuottaja. Rahoituksesta rakennusvaiheiden aikana vastaa rakennuttajana toimiva palveluntuottaja ja käyttövaiheessa Kuopion kaupunki vastaa rahoituksesta kohteiden omistuksen siirtyessä Tilakeskuksen omistamille kiinteistöosakeyhtiöille. Hanke sisältää myös osan käyttäjäpalveluista, mutta ne on erotettuna varsinaisesta elinkaaritoteutuksen palvelusopimuksesta. Käyttäjäpalveluista useat on ulkoistettu muille toimitilapalveluyrityksille. Pääkäyttäjätoiminnot eli opetustoimi ja päivähoitotoiminta ovat Kuopion kaupungilta. 2.2.1. Case-hankkeen organisaatio Lemminkäinen PPP Oy toimii palveluntuottajana Kuopion kaupungin toimiessa tilaajana. Projektiorganisaation sisäisesti Lemminkäinen PPP Oy toimii suunnittelurakennus- ja ylläpitosopimusten tilaajana18. Kuopion elinkaarihanke on jaettu viiden eri kohteen projektiin. Samat suunnittelijat vastaavat jokaisen kohteen suunnittelusta. Lemminkäinen Talo Oy toimii projektinjohtorakennuttajakonsulttina. Rakennus- ja saneeraustyöt ovat jaettu osaurakoihin. Lemminkäinen Talo Oy:n Kuopion yksikkö suorittaa rakennustekniset työt ja tuottaa työmaapalvelut. Lemminkäinen Talotekniikka Oy Kuopio tekee talotekniset työt. Käyttö- ja ylläpitovaiheen huoltotyöt kuuluvat Lemminkäinen Kiinteistötekniikka Oy Kaakkois-Suomen yksikölle. Sekä rakennus- että käyttö- ja ylläpitovaiheen aliurakka- ja palvelusopimuksia on luonnollisesti ulkoistutettu myös konsernin ulkopuolelle. Käyttäjien ja rakennuttajan välisestä viestinnästä, yhteistyöstä ja neuvottelusta vastaa Kuopion kaupungin ja rakennuttajaorganisaation edustajien muodostama yhteistyöryhmä. Suunnittelunohjauksesta vastaa projektinjohto-organisaatio, sen suunnittelutyöryhmä ja pääsuunnittelija. Arkkitehtisuunnittelusta vastaa Arkkitehtitoimisto Perko Oy, rakennesuunnittelusta Rakennussuunnittelutoimisto Nylund Oy, taloteknisestä suunnittelusta 18 Kuopion elinkaarihankkeen Laadunvarmistussuunnitelma 24.2.2010 19 Insinööritoimisto Olof Granlund Oy, geosuunnittelusta Pöyry Environment Oy ja elinkaariasiantuntijana toimii Pöyry Building Services Oy. Kuva 2. Kuopion elinkaarihankkeen organisaatiokaavio 2.2.2. Case-hankkeen eteneminen Kuopion kaupunginvaltuusto hyväksyi kesäkuussa 2008 hankesuunnitelman kokonaisuudesta, johon kuuluu neljän koulun ja yhden päiväkodin suunnittelu, peruskorjaus tai rakentaminen sekä ylläpito 25 vuodeksi19. Kuopion kaupunki päätyi elinkaaripalvelutoteutusmuotoon tehtyään selvityksiä vuosina 2007-2008 rakennuttajakonsulttiyritys Inspira Oy:n kanssa yhteistyössä. Hankintailmoitus lisättiin HILMA:an toukokuussa 2008, joka käynnisti kilpailutusprosessin. Tarjouskilpailu suoritettiin kahdessa vaiheessa. Ensimmäisen vaiheen tarjouspyyntö on päivätty 31.3.2009. Lemminkäisen tarjouksessa Puijonsarven koulun kohdetta tarjottiin uudisrakennettuna peruskorjauksen sijaan. Lemminkäisen johtama tarjousryhmä valittiin palveluntuottajaksi 27.7.2009 20. Sopimus allekirjoitettiin 14.12.2009, jonka jälkeen rakennustyöt käynnistyivät 21. 19 Kuopion elinkaarihankkeen elinkaaritoteutuksen tarjouspyyntö: http://lehdet.lehtiyhtyma.fi/kuopio/tarjouspyynto_elinkaaripalvelut.pdf (luettu 21.10.2010) 20 Pörssitiedote 29.7.2009: Lemminkäiselle iso elinkaarihanke Kuopiosta https://newsclient.omxgroup.com/cdsPublic/viewDisclosure.action?disclosureId=335014&messageId=403197 (luettu 21.10.2010) 21 Pörssitiedote 15.12.2009: Lemminkäinen aloittaa Kuopion elinkaarihankkeen rakennustyöt https://newsclient.omxgroup.com/cdsPublic/viewDisclosure.action?disclosureId=377845&messageId=452308 (luettu 21.10.2010) 20 Ensimmäisen kohteen rakennustyöt alkoivat tammikuussa 2010 ja kaikkien kohteiden rakennustyöt saadaan valmiiksi 2013 loppuun mennessä. Diplomityötä kirjoittaessa keväällä 2011 Rajalan koulun ja Puijonlaakson päiväkodin suunnitteleminen on käynnissä. Diplomityön tekohetkellä rakennustyöt olivat käynnissä Martti Ahtisaaren koulun ja Puijonsarven koulun uudiskohteissa, joista molemmat sisäpuolisten töiden osalta luovutettiin onnistuneesti toukokuussa 2011. Seuraavaksi aloitetaan Rajalan koulun peruskorjaus. Ylläpitovaiheen palvelusopimus jatkuu vuoteen 2036 asti. Martti Ahtisaaren ja Puijonsarven koulujen kohteissa päädyttiin projektinjohtomalliin käyttäjämuutosten vuoksi, jolloin suunnittelu- ja toteutusvaiheet limittyvät päällekkäin. 2.3. Tietomallit ja tietomallipohjainen suunnittelu Tietomallit (Building information model, BIM) tarkoittavat digitaalisessa muodossa olevaa rakennuksen tietojen kokonaisuutta, johon useimmiten kuuluu visuaalinen 3D-malli suunnitteluratkaisusta. Malli sisältää ja siitä saadaan otettua suunnitteluasiakirjoja, määrä- ja mittatietoa, visuaalisia näkymiä ja kiinteistönhallinnan lähtötietoa 22. Näitä tietoja hyödynnetään rakennuksen suunnittelu- rakentamis- sekä käyttö- ja ylläpitoprosesseissa. Tietomalleja käytettäessä suunnitteluratkaisut ovat paremmin hahmotettavissa kuin perinteisillä 2-ulotteisilla piirustuksilla. Tietokoneohjelmat pystyvät tulkitsemaan ja käyttämään mallien tietosisältöä monin eri tavoin. Sunnittelun ja toteutuksen ohella mallit ovat keino säilyttää kohteen tietoja myös käyttöönottovaiheessa. Tietomalleja voidaan tuottaa ohjelmisto- ja suunnitteluyritysten tuottamilla ohjelmistoilla. Jokaisella suunnittelualalla on omat tietomallinsa, kuten arkkitehti-, rakennetekninen ja talotekninen malli. Nämä voidaan koota yhteen yhdistelmämalliin. Tietomallit koostuvat objekteista eli olioista. Oliot ovat esimerkiksi rakennusosia tai tiloja. Oliolle annetaan oma yksilökohtainen tunnuskoodi eli GUID ja niihin saadaan tallennettua attribuutteja kuten rakennetyyppi tai pintamateriaali. Tietomallipohjaisen suunnittelun tavoitteena on23: • tehostaa suunnitteluprosessin kokonaisuutta. • tuottaa täsmällisempää tietoa, vähentää suunnitteluvirheitä, parantaa suunnitelmien yhteensopivuutta ja edistää suunnittelualojen välistä yhteistyötä. 22 Penttilä et al. (2006): Tuotemallintaminen rakennushankkeissa 23 Penttilä et al. (2006): Tuotemallintaminen rakennushankkeissa 21 • tuottaa käyttökelpoisempaa tietoa tuotannonsuunnittelua ja kustannus- ja aikataulunhallintaa sekä rakennustuotteiden valmistusta ja hankintaa varten. • tuottaa tietoa käytettäväksi elinkaarikustannusten ja ympäristövaikutusten arviointiin suunnittelussa, toteutuksessa, käytössä ja ylläpidossa. • tuottaa hyödyllistä tietoa päätöksen teon tueksi vaihtoehtotarkasteluiden avulla. Tietomallipohjaisella suunnittelulla tarkoitetaan sitä, että kohteesta tuotetaan ja pidetään ajan tasalla tietomallia, jonka tietosisällön laajuus on riittävä siihen, että kohteen toteutuksessa käytettävät suunnitteludokumentit voidaan pääosin tulostaa ja tulostetaan tietomallista24. Tietomallipohjaisessa suunnittelussa tieto osapuolten kesken siirtyy pääosin mallien välityksellä. Arkkitehtimallia käytetään muun mallintamisen lähtökohtana. Tietomallipohjainen suunnittelu vaatii, että hankkeen osapuolilla on resurssit, osaaminen ja muut edellytykset tietomallien tuottamiseen. Suunnittelijoilta edellytetään aiempaa monipuolisempaa työsisältöä verrattuna esimerkiksi suunnittelijoiden tehtäväluetteloihin. Tietomallien tuottaminen ja niiden laajuus on määritettävä suunnittelusopimuksissa. Tämän ohella suunnitteluaikatauluun on määritettävä mallien julkaisuajankohdat ja laajuus eri vaiheissa. Tietomalleja käytettäessä korostuu järjestelmällisen projektinhallinnan tärkeys sekä suunnittelu- että toteutusvaiheissa. Lisäksi mallien muutostenhallinta on monimutkaisempaa kuin perinteisissä suunnitelmapiirustuksissa. Tietomallit voidaan jaotella hankkeen eri vaiheiden mukaan 25. Tarveselvitysvaiheessa voidaan tuottaa vaatimusmalli, mutta se on harvinaista. Hankesuunnitteluvaiheessa laaditaan karkea arkkitehdin tilamalli tilaohjelmasta. Korjausrakennushankkeessa mallin lähtötiedot saadaan joko skannaamalla tila mittalaitteilla tai olemassa olevista piirustuksista mallintamalla. Tällöin puhutaan inventointimallista, joka vastaa uudiskohteen tilamallia. Yleissuunnitteluvaiheessa tuotetaan alustavat rakennusosa- ja järjestelmämallit, jotka tarkentuvat toteutussuunnitteluvaiheessa rakennusosa- ja järjestelmämalleiksi. Rakentamisvaiheen mallit ovat tuoteosamalleja, jotka täydennetään toteutuksen edetessä toteumamalleiksi. Käyttö- ja ylläpitovaiheen mallia kutsutaan ylläpitomalliksi. 24 Penttilä et al. (2006): Tuotemallintaminen rakennushankkeissa 25 Penttilä, Hannu (2006): Tuotemallintaminen arkkitehtisuunnittelussa 22 Taulukko 1: Tietomallit hankkeen eri vaiheissa Tarveselvitys Hanke- Yleis- Toteutus- suunnittelu suunnittelu suunnittelu Alustava Rakennusosa- Tuoteosa-/ rakennusosa- malli toteumamalli Arkkitehti- Tilaryhmä-/tila-/ suunnittelu Vaatimusmalli inventointimalli Rakentaminen Käyttö- ja ylläpitovaihe Ylläpitomalli malli Rakenne- Tilavaraus-/ Alustava Rakennusosa- Tuoteosa-/ suunnittelu inventointimalli rakennusosa- malli toteumamalli Ylläpitomalli malli Talotekninen Vaatimus-/ Alustava Rakennusosa- Tuoteosa-/ suunnittelu tilavarausmalli rakennusosa- malli toteumamalli Ylläpitomalli malli Yleensä ensimmäinen tietomalli on arkkitehdin tilamalli. Sitä ennen tilaaja etenee tarveselvitys- ja hankevalmisteluvaiheen kuten perinteisessäkin suunnittelussa. Mahdolliseen vaatimusmalliin kerätään kohteen lähtökohdat ja tavoitteet. Hankemuodosta riippuen joko tilaaja tai kohteen toteuttaja tilaa tietomallit suunnittelijoiltaan. Tietomallit tarkentuvat toteutussuunnitteluvaiheen loppua kohden, jonka jälkeen niitä käytetään kohteen toteutuksessa. Toteutusvaiheessa tehdyt suunnitelmamuutokset lisätään toteumamalliin. Vaikka tietomallipohjainen suunnittelu etenee pääpiirteissään aluksi kuten perinteinenkin suunnittelu, erona perinteiseen suunnitteluun on etenkin se, että suunnittelun painopiste on aikaistunut yleissuunnitteluvaiheeseen, koska malleja käyttäen on enemmän tietoa käytössä jo tavallista aiemmin. Tämän seurauksena yleissuunnitteluvaiheen päätöksen teko on valistuneempaa, mikä vaikuttaa kriittisesti suunnitteluratkaisun laadukkuuteen sekä koko elinkaaren kustannuksiin. Tietomallien hyödyntämisen edellytyksenä ovat hyvin järjestetyt mallinnus- ja tiedonsiirtokäytännöt, jotka on sovittava hankkeen alussa. Näitä käytännön asioita ovat esimerkiksi mallinnusperiaatteet sekä käytettävät mallinnusohjelmat. Seuraavat mallinnuksen kannalta tärkeät asiat on täsmennettävä projektitoimintaohjeessa: • osapuolten yhteystiedot • käytettävät osamallit, ohjelmistot ja ohjelmien versiot • tiedonsiirtomenetelmät osapuolten välillä • mallintamistavat ja mallintamistarkkuudet • mallien tarkastustoimenpiteet • muutostenhallinta • aikataulut • mallien ja muiden suunnitelmien yhteensovitus • projektin päätöstoimenpiteet 23 Rakennusosia mallintaessa on käytettävä oikeaa mallinnustyökalua. On myös tärkeää, että rakennusosiin merkitään oikeat attribuuttitiedot oikeisiin kohtiin. Nämä asiat ovat kriittisiä mallin tulkitsemisen ja ohjelmien välisen tiedonsiirron kannalta, joten mallintamisen tueksi ja ohjeistukseksi on olemassa yleisiä ja yrityskohtaisia mallinnusohjeita. Tietomallien siirto eri tietojärjestelmien välillä edellyttää kansainvälisen Industry Foundation Classes (IFC) – tiedonsiirtostandardin käyttöä. IFC-tiedonsiirrossa tietomalli muunnetaan kääntäjäohjelmaa käyttäen alkuperäisessä mallinnusohjelmassa IFCmuotoon. IFC-muodossa tietomallista karsitaan osa tietosisällöstä pois. Toinen ohjelma voi avata IFC-muotoisen mallin, käyttää sitä viitepohjana omassa mallinnuksessa tai jopa kääntää sen ohjelman omaan natiivimuotoon. Natiivimuodoilla tarkoitetaan mallinnusohjelmien alkuperäisiä tiedostomuotoja. BuildingSMART (International Alliance for Interoperability eli IAI) kehittää IFC-standardia jatkuvasti. Tällä hetkellä on käytössä IFC 2X3-versio ja 2X4 on testausvaiheessa 26. Tietomallien siirto osapuolten välillä voidaan toteuttaa projektipankin tai tietomallipalvelimien kautta. Yhä useampi rakennuttaja edellyttää tietomallien käyttöä hankkeissaan27. Isoimmat suunnittelutoimistot käyttävät tietomallipohjaista suunnittelua kaikissa keskeisissä projekteissaan. Tietomallintamisen leviämisen esteenä eivät ole tekniset asiat, vaan suunnittelu- ja rakennusalojen yritysten taloudellisten ja henkilöstöresurssien rajallisuus sekä projektien tiukat aikataulut28. 26 BuildingSMART www-sivut: http://buildingsmart-tech.org/specifications/ifc-releases (viitattu 30.5.2011) 27 Palos, Salla (2010):Tietomalliprosessi – Tietomallitiedon käyttö suunnittelussa, rakentamisessa ja ylläpidossa 28 Penttilä et al. (2006): Tuotemallintaminen rakennushankkeissa 24 2.3.1. Arkkitehtimalli Arkkitehti tuottaa ark-mallin, joka sisältää kohteen arkkitehtisuunnitelmat. Malli sisältää kohteen tilat ja rakennusosat. Arkkitehtimallin tilojen pinta-aloja voidaan käyttää tarkastaessa, vastaako arkkitehtimalli tilaohjelmaa. Lisäksi niiden avulla voidaan suorittaa tilapohjaista kustannuslaskentaa ja monipuolista määrälaskentaa. Arkkitehtimalli toimii usein lähtökohtana muiden suunnittelualojen tietomallintamiselle. Arkkitehtimalliin mallinnetaan ainakin Alapohjat, runko, julkisivut, ulkotasot (parvekkeet, katokset), vesikatot (Talo2000-nimikkeistön mukaisesti)29. Malliin voidaan myös lisätä esimerkiksi rakennuksen sisäpuoliset seinärakenteet, pintarakenteet, valaisimet ja kalusteet30. Malliin voidaan myös mallintaa talotekniikalle tilavaraukset. Rakennusosiin on määritettävä attribuuttitiedoksi rakennetyypit ja pintamateriaalit. Tarkkuudessa voidaan sallia poikkeuksia pienellä toleranssilla31. Kuva 3. Ark-mallia käyttäen voidaan helposti hahmottaa Martti Ahtisaaren koulun ulkomuoto. (Solibri Model Checker –malli, suunnittelutilanne 14.4.2011 29 Senaatti Kiinteistöt (2007): Tietomallivaatimukset osa 3 Arkkitehtisuunnittelu 30 Penttilä, Hannu (2006): Tuotemallintaminen arkkitehtisuunnittelussa 31 Senaatti Kiinteistöt (2007): Tietomallivaatimukset osa 3 Arkkitehtisuunnittelu 25 2.3.2. Rakennemalli Rakennesuunnittelija mallintaa rakennemalliin vähintään kohteen kantavat betoni-, teräs- ja puurakenteet sekä ei-kantavat betonirakenteet 32. Rakennemalliin voidaan määrittää myös muita sekundäärisiä rakenteita ja paikallavalettaviin betoniosiin voidaan mallintaa raudoitteet ja kiinnitykset. Rakenneosille on määritettävä oikea ja tarkka sijainti, nimi ja tyyppi sekä geometria. Rakennemallin rakennusosat on mallinnettava tarkalleen oikeisiin kohtiin liittymisien ja asennusten edellyttämän tarkkuustason vuoksi. Mallinnusohjelmia voidaan käyttää myös elementtien mallintamiseen. Elementtisuunnittelu on ala, jolla tietomallien mahdollisuudet korostuvat. Tietomalleihin saadaan määritettyä elementtien sijainnit, tyypit ja määrät, asennusjärjestys ja ajankohdat valmistukselle, toimitukselle ja asennukselle, liitostyypit ja –detaljit, reiät sekä päällekkäisyydet muiden rakennusosien kanssa. Kuva 4. Puijonsarven koulun Tekla Structures -rakennemalli (suunnittelutilanne 14.4.2011) 32 Senaatti Kiinteistöt (2007): Tietomallivaatimukset osa 5 Rakennesuunnittelu 26 2.3.3. Talotekninen malli Talotekninen malli sisältää kohteen talotekniset järjestelmien tekniikkaosat ja järjestelmien edellyttämät varaukset33. Lisäksi malliin voidaan sisällyttää kanavistojen edellyttämät eristeet ja huoltoluukut sekä muuta taloteknisen toteutuksen kannalta oleellista tietosisältöä. LVISA-suunnittelijat mallintavat omat mallinsa, jotka yhdistetään talotekniseksi malliksi. Mallia yhdistettäessä voidaan suorittaa taloteknisten suunnittelualojen välinen törmäystarkastelu. Tate-mallia käytetään myös järjestelmien mitoittamiseen sekä kohteen tate-analyyseihin. Taloteknistä mallista voidaan ottaa myös lähtötiedot rakennesuunnittelijan reikien mallinnukselle. Kuva 5. Tate-mallista näkyy Martti Ahtisaaren koulun 1. kerroksen talotekniikka. (Solibri Model Checker –malli, suunnittelutilanne 14.4.2011) 33 Senaatti Kiinteistöt (2007): Tietomallivaatimukset osa 4 TATE-suunnittelu 27 2.3.4. Yhdistelmämalli Yhdistelmämalliin tuodaan eri suunnittelualojen osamallit, jolloin niiden tietosisältö muodostaa yhden kokonaisuuden34. Osamalleja yhdistettäessä voidaan niiden tarpeetonta sisältöä karsia pois yhdistelmämallista. Yhdistämiseen käytetään mallinnusohjelmistoa, ja mallit voidaan tuoda joko IFC-muodossa tai muussa mallinnusohjelman sallimassa muodossa. Mallien koordinaatistojen, orientaation, sijainnin ja mallinnusmenetelmien on oltava yhtenevät. Siksi yhdistäminen edellyttää, että suunnittelijat noudattavat annettuja mallinnuskäytäntöjä ja tiedonsiirto-ohjeita. Osamalleja ei voida yhdistelmämallissa muokata, mutta niiden tietosisältöä voidaan ottaa siitä ulos. Yhdistelmämallia käytetään pääasiassa laadunvarmistuksessa, havainnollistamisessa, määrä- ja sijaintitiedon hallinnassa sekä suunnitteluratkaisua koskevassa kommentoinnissa ja viestinnässä. Yhdistelmämallin hyöty korostuu laadunvarmistuksessa, sillä siitä voidaan tarkastaa, ovatko suunnittelualojen ratkaisut yhteensopivia keskenään. Kuva 6. Leikkaus Martti Ahtisaaren koulun yhdistelmämallista, jossa on näkyvissä rakenne- ja tateosamallit. Yhdistelmämallia voidaan käyttää risteilyjen visuaaliseen hahmottamiseen. (Solibri Model Checker –malli, suunnittelutilanne 14.4.2011) 34 Vakkilainen Jussi (2009): Rakennuksen tietomalli rakennushankkeen suunnitteluvälineenä 28 2.4. Tietomallien käyttö hankkeiden aikana ja Lemminkäi- sen tietomalliprosessi Lemminkäisen hankkeissa, joissa käytetään tietomalleja, noudatetaan toimintajärjestelmän mukaista tietomalliprosessia. Salla Palos on diplomityössään kuvannut tietomalliprosessin prosessikarttana, jonka osia on liitetty tämän työn liitteeksi. Tarveselvitystä sekä käyttö- ja ylläpitovaihetta koskevat prosessikartan osat jätettiin tästä työstä pois. Prosessikartoista selviää projektinjohtototeutusmuotoisen hankkeen eteneminen. Vastaavasti tässä luvussa esitetään Lemconin (nykyään osa Lemminkäinen Talo Oy:tä) tietomalliprosessi elinkaarimallin mukaisessa hankkeessa, jossa palveluntuottaja toimii rakennuttajana. Tietomalliprosessia ja tietomallien käyttömahdollisuuksia avataan alla etenkin projektinjohtokonsulttiosapuolen ja toteutusorganisaation näkökulmasta. 2.4.1. Tietomallit hankevalmistelu- ja tarjousvaiheessa Hankkeen alkuperäinen tilaaja saattaa tuotattaa hankevalmisteluvaiheessa hankeohjelman ja muiden lähtötietojen pohjalta tilaryhmä- tai tilamallin 35. Esimerkiksi olemassa olevista kohteista saatetaan tarjouskilpailuun osallistuville antaa käyttöön inventointimallit. Yleensä elinkaarimallihankkeessa palveluntuottajaehdokkaan tehtäviin sisältyy varsinaisen suunnitteluratkaisun muodostaminen tarjousaineiston perusteella, jolloin tarjousryhmän arkkitehdit tuottavat omat tilamallinsa. Palveluntuottajaorganisaatio käyttää tarjousvaiheessa mahdollista tilamallia visualisoimaan suunnitteluratkaisua itselleen tai tilaajalle. Havainnollinen tilamalli toimii päätöksenteon tukena kehitettäessä suunnitteluratkaisuja sekä arvioitaessa, täyttävätkö suunnitelmat annetut tarjouskilpailun kriteerit. Tilamallia voi käyttää myös kohteen elinkaarikustannuksia arviointiin, vaikka mallin tietosisältö on hyvin kevyt. Tilamallista voidaan laskea kohteen tunnuslukuja kuten hyötyneliöiden suhde bruttoneliöihin tai kohteen tilavuus vaipan pinta-alaa kohden 36. Kohteen investointi- ja käyttökustannuksia voidaan laskea tilapohjaisesti, jolloin kustannukset arvioidaan empiirisesti hankittujen keskimääräisten tilakustannusten, korjauskertoimien ja kustannusindeksien avulla. Tunnuslukujen ja tilapohjaisen määrä35 Palos, Salla (2010):Tietomalliprosessi – Tietomallitiedon käyttö suunnittelussa, rakentamisessa ja ylläpidossa 36 Senaatti Kiinteistöt (2007): Tietomallivaatimukset osa 7: Määrälaskenta 29 laskennan edellytys on, että tilaryhmä- tai tilamallin geometria on mallinnettu oikein sekä tilat on mallinnettu oikein. Kun tilat on määritetty, on myös varmistettava, että ne vastaavat tilaohjelmaa. Myös rakennusosapohjaista määrälaskentaa voisi suorittaa, mutta se ei ole tarkoituksenmukaista, koska vain murto-osa rakennusosista on mallinnettu ja niihin todennäköisesti tulee huomattavasti muutoksia. Näiden ohella tilamallia voi myös käyttää pohjana taloteknisissä analyyseissä, joilla voidaan arvioida mm. kohteen energiankulutusta37. Tarjousvaiheessa suunnitteluratkaisun taloudellisuuteen ja tilaratkaisuihin voidaan vaikuttaa todella paljon. Tarjousvaiheessa käytettävissä oleva tiedon määrä on pieni. Hankkeen edetessä informaation määrä kasvaa, mutta vastaavasti vaikutusmahdollisuudet pienenevät. Mitä pidemmälle hankkeessa edetään, sitä kalliimmaksi tulevat muutoskustannukset. Tietoa saadaan varhaisemmassa vaiheessa enemmän käyttöön tuottamalla toimiva tilamalli. Tällöin hanketta voidaan ohjata tehokkaampaan ja taloudellisempaan suuntaan. 2.4.2. Tietomallit suunnitteluvaiheissa Tietomalliprosessin mukaan hankkeen suunnittelu toteutetaan tietomallipohjaisesti 38. Suunnitteluvaiheessa arkkitehti tuottaa ensin alustavan rakennusosamallin, jota käytetään suunnitteluratkaisun muotoilemisessa. Alustava rakennusosamalli tarkentuu toteutussuunnitteluvaiheessa rakennusosamalliksi, kun arkkitehdin suunnitteluratkaisut ovat pääpiirteiltään selvät. Hankkeesta riippuen myös rakenne- ja talotekninen suunnittelija tuottavat arkkitehtisuunnitelmien pohjalta omat tietomallinsa, jotka tarkentuvat ja hioutuvat valmiiksi toteutusvaiheen alkuun. Suunnitteluvaiheita varten on laadittu suunnitteluaikataulu, jonka mukaan mallien julkaiseminen, laadunvarmistus ja yhteensovitus on toteutettava. Mallit saatetaan yhdistää yhdistelmämalliksi. Tietomalleja käytetään myös tässä vaiheessa visualisoimaan suunnitelmia sekä projektiorganisaation sisäisesti että alkuperäiselle tilaajalle. Viranomaisyhteyksissä ja varsinkaan rakennuslupamenettelyssä ei voida nykyhetkellä hyödyntää tietomalleja. Mallin laadunvarmistus on olennainen osa tietomalliprosessia. Keskeisessä roolissa ovat ristiriitatarkastukset eri suunnittelualojen välillä esimerkiksi yhdistelmämallia käyttäen. 37 38 Palos, Salla (2010):Tietomalliprosessi – Tietomallitiedon käyttö suunnittelussa, rakentamisessa ja ylläpidossa Palos, Salla (2010):Tietomalliprosessi – Tietomallitiedon käyttö suunnittelussa, rakentamisessa ja ylläpidossa 30 Törmäystarkastelussa löydetään kalliit suunnitteluvirheet sen sijaan, että ne paljastuisivat vasta toteutusvaiheessa. Mallin laadunvarmistuksesta on tuotettava riittävä dokumentaatio kuten tarkastusraportit39. Suunnittelijat ovat vastuussa omien malliensa virheettömyydestä ja laadusta. Palveluntuottajan projektinjohto- ja toteutusorganisaation on raportoitava havaitsemistaan mallien epäkohdista suunnittelijoille, jotka korjaavat ne. Laadunvarmistuksen menetelmiä ovat tarkastaminen ja analyysit. Tarkastaminen tarkoittaa mallin tietosisällön oikeellisuuden arviointia sellaisenaan tai vertaamalla sitä referenssitietoon kuten tavoitteisiin. Vertaamalla voidaan esimerkiksi todeta, onko suunnittelija käyttänyt oikeita rakennustyyppejä tai vastaavatko mallin tilat tilaohjelmaa. Visuaalisella tarkastuksella tarkoitetaan mallin tutkimista katsellen. Täten huomataan helposti esimerkiksi epäesteettiset ratkaisut, ylimääräiset ja puuttuvat rakennusosat sekä rakennusosien yhteensovitusvirheet. Ohjelmallisella tarkastuksella tarkoitetaan mallinnusohjelmien tarkastustyökaluja, jotka käyvät mallin kaikki rakennusosat läpi etsien virheitä. Analyysillä tarkoitetaan mallista johdettujen tietojen kuten tunnuslukujen arviointia. Tarkastamisella huomataan enemmän varsinaisia mallinnusvirheitä, kun analyysillä taas arvioidaan suunnitteluratkaisun tavoitteenmukaisuutta. Mallin laadunvarmistuksen järjestelmällisyyden ja toimivan suunnitteluaikataulun lisäksi suunnittelun etenemisen kannalta kriittistä on toimiva tiedonsiirto osapuolten kesken. Mallit on julkaistava projektipankkiin oikea-aikaisesti sovitussa muodossa. Lisäksi julkaisun yhteydessä on toimitettava riittävä dokumentointi. Mallien ja piirustusten välille ei saa muodostua ristiriitoja väärästä julkaisutahdista johtuen. Malleja yhdistettäessä kaikkien osamallien on oltava ajan tasalla toistensa kanssa. Alustavaa rakennusosamallia voidaan jo käyttää rakennusosalaskentaan, jossa tietomallista otetaan ulos kohteen rakennusosien määriä 40. Määrien perusteella voidaan arvioida kohteen kustannuksia tarkemmalla tasolla kuin tilapohjaisella kustannuslaskennalla. Alustavaa rakennusosamallia voi kuitenkin vielä käyttää tunnuslukujen laskentaan ja tilapohjaiseen määrälaskentaan kuten tilaryhmä- ja tilamalleja. Rakennusosa39 Senaatti Kiinteistöt (2007): Tietomallivaatimukset osa 6 Laadunvarmistus 40 Senaatti Kiinteistöt (2007): Tietomallivaatimukset osa 7: Määrälaskenta 31 laskennalla voi suunnitteluvaiheessa kustannusten lisäksi tutkia suunnitelmamuutosten aiheuttamia määrämuutoksia. Toteutussuunnitteluvaiheessa on käytössä mahdolliset arkkitehti-, rakenne- ja tate-malli jo rakennusosamallitasoisina, jolloin niiden tietosisältö on riittävän laaja, jotta rakennusosat voidaan luetteloida tyypeittäin. Tällöin laskijan ei tarvitse tehdä yhtä paljon oletuksia ja varauksia kuin yleissuunnitteluvaiheessa. Rakennusosapohjaisen määrälaskennan edellytykset tietomallille ovat41: • Kaikki rakennusosat on mallinnettu sovitulla tavalla eli mallinnusohjeen mukaan. Poikkeukset on kirjattu tietomalliselosteeseen. Tietomalliselosteesta on myös käytävä ilmi mallin tarkkuustaso eri rakennusosaluokkien osalta. • Mallin objekteihin on lisätty kaikki tarvittava tyyppi- ja tunnistetieto jaottelua varten. • Objektien mittatiedot on oltava oikein sovitulla tarkkuudella. Lisäksi mallin käyttäjien on osattava määrälaskennassa noudattaa järjestelmällistä, johdonmukaista laskentatapaa. Laskijoiden on tutustuttava kohteeseen ja sen malleihin, mallinnusohjeisiin, tietomalliselosteisiin, tarkastusraportteihin ja muuhun lähtöaineistoon perusteellisesti ennen laskennan aloittamista. Ennen kaikkea laskijan on muodostettava itselleen kuva siitä, mitä määrätietoa mallista voidaan käyttää luotettavasti. Tämän vuoksi suunnittelijoiden on pidettävä selkeää dokumentaatiota mallinnusperiaatteista ja niiden poikkeuksista. Samoin määrälaskijoiden on laadittava määrälaskentamuistio myöhempiä vaiheita varten. Kun määrälaskija on selvittänyt itselleen lähtöaineiston, hänen on valittava käytettävä mallinkäyttöohjelma ja malli, josta tiedot otetaan, sekä muoto, jossa tieto halutaan ulos. Mallipohjaisessa rakennusosalaskennassa käytetään lähes poikkeuksetta Talo2000-nimikkeistöä. Tietomallipohjainen määrälaskenta edellyttää määrälaskijalta perehtymistä ja kouluttautumista mallin käyttöön. Varsinkin rakennusosalaskennassa on hyvin paljon rakennusosakohtaisia ongelmakohtia, jotka johtuvat ohjelmistojen puutteista. Nämä oppii usein vasta kokemuksen kautta. 41 Senaatti Kiinteistöt (2007): Tietomallivaatimukset osa 7: Määrälaskenta 32 Kuva 7. Määrälaskennan prosessi42. Määrälaskennan tuloksia käytetään aina seuraavan laskentakerran lähtöaineistona. Suunnitteluratkaisun mallin avulla voidaan simuloida kohteen olosuhteita 43. Tällöin voidaan tuottaa vertailutietoa esimerkiksi sisäilmaston laatutasosta, lämmityshäviöistä ja siten energiankulutuksesta. Siten tietomallin avulla voidaan mm. pyrkiä arvioimaan kohteen energiatehokkuutta, jota perinteisesti on arvioitu ainoastaan empiirisen tiedon avulla. Simuloinnilla varmistetaan, että sisäilmastolle asetetut laatuvaatimukset ja viranomaismääräykset täyttyvät. Tämän avulla voidaan tutkia vaihtoehtoisia ratkaisuja ja niiden vaikutusta, jolloin suunnitteluratkaisua voidaan kehittää yhä tehokkaammaksi. Suunnitteluvaiheissa aloitetaan jo rakentamisen valmistelu 44. Valmisteluun kuuluu esimerkiksi kustannuslaskenta, laatusuunnitelman laatiminen, hankintojen tekeminen, aikataulun tuottaminen ja työvaiheiden suunnittelu. Näissä voidaan hyödyntää mallista otettua määrätietoa määrälaskentaprosessin mukaisesti sekä tietomallien havainnollisuutta. Tietomalleihin voi myös lisätä 4D-aikataulutietoa. Tietomallien hyödyntämistä kohteen toteutuksessa käsitellään seuraavassa luvussa tarkemmin. 42 Senaatti Kiinteistöt (2007): Tietomallivaatimukset osa 7: Määrälaskenta 43 Senaatti Kiinteistöt (2007): Tietomallivaatimukset osa 9: Tate-analyysit 44 Palos, Salla (2010):Tietomalliprosessi – Tietomallitiedon käyttö suunnittelussa, rakentamisessa ja ylläpidossa 33 2.4.3. Tietomallit toteutusvaiheessa Toteutusvaiheessa voidaan kaikkia tietomalleja hyödyntää tietomallipohjaisessa toteutuksessa45. Mitä enemmän mallissa on detaljitason tietoa, sitä monipuolisemmin kohde voidaan toteuttaa tietomallin mukaisesti. Kuitenkin myös karkeatasoista mallia voidaan käyttää esimerkiksi tilan hahmottamisessa. Myös mallin virheettömyys on ratkaisevaa. Tietomallipohjaisessa toteutuksessa tietomallista voidaan havainnollistaa suunnitteluratkaisuja joko tulostamalla piirustuksia ja kuvakaappauksia rakentajien käyttöön tai tarkastelemalla niitä tietokoneelta. Kyseessä on tekninen visualisointi, jossa pääosassa ovat rakennusosien tarkka geometria ja oikeat attribuuttitiedot 46. Lisäksi malleihin voi lisätä tai linkittää tarpeellista mallin ulkopuolista tietoa. Myös suunnitelmien laadunvarmistus jatkuu toteutuksen aikana, jolloin toteutusorganisaatio raportoi havaitsemistaan virheistä suunnittelijoille. Tietomallit eivät ole enää pelkästään työmaa- ja hankintainsinöörien työkalu, vaan yhtä lailla niin työnjohtajat, mittamiehet ja aliurakoitsijat voivat tarvittaessa ottaa niistä tietoja. Mallista saadaan tulostettua määrätietoa rakennusosista ja –materiaaleista huomattavasti käsinlaskentaa nopeammin ja tarkemmin myös tuotantovaiheessa47. Määrätietoa voi käyttää tuotannonohjauksessa seuraaviin asioihin: • kustannus- ja tarjouslaskentaan (tuotantovaiheen lisä- ja muutostyötarjoukset) • aikataulunlaadintaan ja –seurantaan • aliurakoiden ja rakennustarvikkeiden hankintaan sekä hankintasuunnitelman laatimiseen • työn suunnitteluun ja –seurantaan Myös tuotantovaiheessa tietomallipohjaisen määrälaskennan on noudatettava prosessia, jossa ensin määrälaskija kartoittaa lähtöaineiston sekä aiemmat määrälaskelmat. Seuraavaksi laskija ottaa tarvitsemansa määrätiedon valitsemastaan tietomallista ja tuottaa määrälaskenta-asiakirjan eli taulukon tai luettelon, johon voi myöhemmin tarvittaessa palata lisälaskennassa tai toteuman seurannassa. Määräluettelo voidaan tuottaa joko malliin itseensä tai tulostaa siitä esimerkiksi Microsoft Excel –tiedostona tai pdftiedostona. Määrälaskennan ohessa on tehtävä muistiinpanoja käytetyistä laskentaperusteista ja –menetelmistä. 45 46 47 Palos, Salla (2010):Tietomalliprosessi – Tietomallitiedon käyttö suunnittelussa, rakentamisessa ja ylläpidossa Senaatti Kiinteistöt (2007): Tietomallivaatimukset osa 8: Havainnollistaminen Senaatti Kiinteistöt (2007): Tietomallivaatimukset osa 7: Määrälaskenta 34 Toteutusvaiheessa on käytettävä rakennusosamallin tasoista mallia määrien hallintaan. Kaikki malliin mallinnetut objektit voidaan listata tunnistetietoineen määräluetteloihin. Näistä objekteista voidaan lisäksi luetteloida myös pituus, pinta-ala ja tilavuus sekä niiden kokonaissummat. Lisäksi etenkin rakennemallin objekteista voidaan johtaa suoritteita kuten esimerkiksi raudoitemassoja siitä huolimatta, että raudoitteita ei ole itsessään mallinnettu. Tuotannonohjauksen kannalta on tärkeää, että mallin rakenneosiin on lisätty attribuuttitietona niiden kerros- ja lohkosijainti. Tarvittaessa määrälaskija voi täydentää malliin sijainti- tai jotain muuta tietoa helpottaakseen ja korjatakseen laskentaa. Kohteen mallin ympärille voi myös laatia havainnollisen 3D-työmaasuunnitelman eli 3D-aluesuunnitelman48. Mallinnettu työmaasuunnitelma edellyttää maastomallia sekä joko arkkitehti- tai rakennemallia. Työmaasuunnitelman voi tuottaa myös 4Dmuodossa, jossa työmaasuunnitelma muuttuu ajallisesti toteutuksen edetessä eri vaiheisiin. Työmaasuunnitelman voi tuottaa usealla eri ohjelmalla. Ohjelmien kirjastoissa on suppea valikoima tuotantoon liittyviä objekteja kuten nostureita ja varastokontteja. Kattavamman valikoiman työmaasuunnitelman GDL-objekteja saa käyttämällä lisäkirjastoja, kuten TurvaBIM-objektikirjastoa, joka on saatavilla eri ohjelmistoihin. TurvaBIM-kirjaston sisältö on jaoteltu seuraavasti: 48 • aidat, kulkuesteet • työmaakopit • tikkaat, rakennustelineet, rakennushissit • turvallisuusobjektit • ajoneuvot, paikoitus, liikennealueet • rakennuskoneet ja nosturit • materiaalien varastointi • muottikalusto • puut, kasvillisuus • sähkö, valaistus • muut objektit VTT (2009): Tietomalli ja työmaan turvallisuus 35 3D-työmaasuunnitelmaa voi ennen kaikkea käyttää hankkeen työturvallisuuden ja logistiikan parantamiseen esimerkiksi riskien hallinnan menetelmillä. Lisäksi mallinnettua työmaasuunnitelmaa tai siitä otettuja näkymiä ja videoita voidaan käyttää havainnollistamaan työmaata ja sen olosuhteita. Käytännössä 3D-/4D-työmaasuunnitelmaa voi käyttää myös turvallisuushavaintojen ja TR-kierrosten tuloksien kirjanpitoon. 36 3. Case-tutkimus Haastattelut tehtiin helmikuun 2011 aikana, jolloin case-hankkeen Martti Ahtisaaren koulu ja Puijonsarven koulu olivat toteutusvaiheessa. Molemmissa kohteissa oli sisävalmistusvaihe meneillään. Samalla ajanhetkellä Rajalan koulun ja Puijonlaakson päiväkodin suunnitteluvaiheet olivat myös käynnissä. Haastattelututkimus suoritettiin puolistrukturoituina teemahaastatteluina, joissa käytettiin jokaiselle vastaajaryhmälle ryhmäkohtaisia, etukäteen valmisteltuja haastattelulomakkeita. Lomakkeet lähetettiin haasteltaville ennen haastatteluja. Haastattelulomakkeet oli jaettu seuraaviin tietomallintamisen osa-alueisiin liittyviin teemoihin: • A: Tehtävänkuvaus ja tausta • B: Tiedonvaihto • C: Kokouskäytännöt • D: Mallinnus • E: Tietosisällöt ja mallintamistarkkuus • F: Tuotannonohjaus Haastattelut olivat avoimia ja niissä käsiteltiin myös kysymyksiä sivuavia aiheita. Lisäksi haastatteluissa sivuttiin muitakin hankkeita Kuopion elinkaarihankkeen lisäksi. Haastateltavat valittiin yhteistyössä diplomityön ohjaajan Annikki Karppisen kanssa. Ohjaaja oli läsnä kahdessa haastattelutilanteessa. Suunnittelijoista haastateltiin Arkkitehtitoimisto Perko Oy:n toimitusjohtajaa Tomi Perkoa, joka toimii case-hankkeen pääsuunnittelijana ja arkkitehtina, sekä case-hankkeen mallintamiseen osallistuvaa arkkitehti Aleksi Räihää. Rakennesuunnittelusta vastaavasta Suunnittelutoimisto Nylund Oy:stä haastateltiin päärakennesuunnittelija Pauli Pehkosta ja suunnittelija Tatu Turusta. LVIS-suunnittelun osalta haastateltiin Insinööritoimisto Granlund Oy Kuopion toimitusjohtajaa Jukka Vasaraa, joka toimii case-hankkeen LVI-pääsuunnittelijana, sähköpääsuunnittelija Timo Oravaista, sähkösuunnittelija Toni Ollikaista sekä LVI-suunnittelija Tuomas Lehikoista. Lisäksi tutkimuksessa haastateltiin Pöyry Finland Oy:n elinkaarikonsultteja Keijo Leppävuorta sekä Pekka Mairinojaa, joka ei osallistunut casehankkeeseen. 37 Haastatteluissa haastateltiin Lemminkäinen Talo Oy:n projektinjohtokonsulttien tehtävissä toimivia projektipäällikkö Matti Varstalaa ja tate-päällikkö Jari Liukkosta. Lemminkäinen Talo Oy:n Kuopion yksikön työmaatoimihenkilöitä edustivat Puijonsarven koulun työmaainsinööri Mikko Koponen ja Martti Ahtisaaren koulun työmaainsinööri Harri Niemi. Kyseessä on eri Harri Niemi kuin diplomityöntekijä. Mallin käyttö työmailla case-hankkeessa oli hyvin pitkälti heidän varassaan. Lisäksi sekä rakennuttajaettä toteutusorganisaatiota edustivat Lemminkäisen tietomalliasiantuntijat Matti Partanen ja Artur Virit. He toimivat case-hankkeessa muiden tehtäviensä ohella mallintamisen tukihenkilöinä. Lisäksi haastateltiin tietomalliasiantuntija Janne Salinia, joka ei osallistunut case-hankkeeseen. Taloteknisen urakoitsijan Lemminkäinen Talotekniikka Oy:n Kuopion yksiköstä haastateltiin LVIS-päällikkö Ari Kakkista, IV-asennuspäällikkö Juha Ronkaista sekä sähköasennuspäällikkö Mika Karhusta. Haastattelut olivat hyvin kattavia sekä case-hankkeen tietomallin tuottamisen ja käytön osalta että yleisesti tietomallinnuskäytäntöjen parantamisen kannalta. Haastattelujen painopiste oli malliin liittyvän tiedonvaihdon järjestämisessä, mallien laadun- varmistuksessa, yhdistelmämallin käytössä ja mallien hyödyntämisessä tuotannonohjauksessa. Case-tutkimuksessa keskityttiin Graphisoftin ArchiCAD –mallinnusohjelmaan, Teklan Structures –mallinnusohjelmaan, Solibri Model Checker ja Model Viewer –ohjelmiin ja MagiCAD-mallinnusohjelmaan. 3.1. Tietomallien käyttö case-hankkeessa Case-hankkeen kohteissa on käytetty tietomallipohjaista suunnittelua. Arkkitehti on tuottanut tai aikoo tuottaa kohteista tila- ja arkkitehtimallit 49. Suunnittelusopimuksissa on sovittu, että kohteista tuotetaan myös rakenne- ja tate-mallit. Lisäksi edellä mainitut mallit yhdistetään IFC-muotoisina Solibri Model Checker –ohjelmalla. Kohteen arkkitehti-, rakenne- ja LVIS-suunnittelutoimistot käyttävät muutenkin kaikissa kohteissaan tietomallipohjaista suunnittelua. Arkkitehti on mallintanut Martti Ahtisaaren koulun ja Puijonsarven koulun suunnitelmat laajemmin kuin missään aiemmassa kohteessaan. Arkkitehtimalliin tuotiin kalusteet 49 Perko, Räihä, arkkitehtisuunnittelu. Haastattelu Helsinki 11.2.2011 38 sekä rakenne- ja tate-mallin osia. Arkkitehtitoimiston tarkoituksena oli yhdistää kaikki osamallit kokonaisina ArchiCAD-ohjelmalla, mutta lopputulos olisi ollut liian raskas käyttöä varten. Arkkitehti kuitenkin totesi, että varsinkin ark-tate-yhdistelmämalli olisi suunnittelun kannalta tarpeellinen esimerkiksi alakattojen ja kalusteiden sijoittamista varten sekä mahdollista toteuttaa, jos käytössä olisi riittävät konetehot. Tällöin saisi käyttöön esimerkiksi seinäprojektioita, jotka helpottaisivat sekä suunnittelua että asennuksia. Arkkitehti tulosti kohteiden suunnitteluasiakirjoja sekä määräluetteloita kuten ovi- ja ikkunaluettelot mallista. Lisäksi arkkitehti tuotti toisen kohteen mallista julkisivulevyjen sahausluettelot, jotka eivät kuuluneet suunnittelusopimuksiin. Tarkoitus oli case-hankkeessa käyttää arkkitehdin tilamallia myös tate-analyysien pohjana tarjousvaiheessa, mutta IFC-muotoisen mallin tuonti simulointiohjelmiin ei onnistunut. Mallista kuitenkin tulostettiin tietoja elinkaarilaskelmien lähtötiedoksi. Myös rakennesuunnittelija tuotti case-hankkeen tähän mennessä tuotetut rakennemallinsa laajemmin kuin muiden hankkeiden mallit50. Varsinkin Martti Ahtisaaren koulun rungon monimuotoisuuden vuoksi rakennemalli oli hyvin tarpeellinen työkalu kohteen elementtisuunnittelussa. Mallista on tulostettu myös määräluetteloita sekä taso- ja leikkauskuvia rakennetoimittajien, työmaatoimihenkilöiden ja mittamiehen käyttöön. Kohteiden LVI- ja S-mallit on viety pidemmälle kuin muissa LVIS-suunnittelutoimiston hankkeissa51. Malleista on tuotu rakennesuunnittelijan käyttöön tietoja rei’istä ja varauksista IFC-muodossa. Malleihin on lisätty laiteobjekteja hyvin laajasti. Esimerkiksi sähkömalliin oli tuotu jopa sähkörasiat ja turvavalaisimet. Suunnittelijat pyrkivät käyttämään laitetoimittajien kirjastojen objekteja kohteen mallintamisessa. Tuotetietoa pyrittiin lisäämään malliin käyttö- ja ylläpitovaiheen mahdollista mallin hyödyntämistä varten. Tietomallipohjaisen suunnittelun lisäksi tietomalleja käytettiin suunnittelunohjauksen työkaluna52. Tietomalleja käytettiin suunnittelun etenemisen seurantaan, ongelmakohtien etsimiseen ja ratkaisemiseen, suunnittelualojen 50 Pehkonen, Turunen, rakennesuunnittelu. Haastattelu Kuopio 18.2.2011. 51 Vasara, Oravainen, Ollikainen, Lehikoinen, LVIS-suunnittelu . Haastattelu Kuopio 17.2.2011. 52 Varstala, Matti, projektipäällikkö . Haastattelu Helsinki 10.2.2011. yhteensovittamiseen, 39 suunnitteluratkaisujen havainnollistamiseen ja arviointiin sekä tunnuslukujen ja määrien laskentaan. Suunnittelijat, tietomalliasiantuntijat ja työmaainsinöörit ovat kaikki käyttäneet yhdistelmämallia jossain määrin suunnitelmien laadunvarmistukseen. Tuotannonohjauksessa lähtökohdaksi ymmärrettiin tietomallipohjainen toteutus 53. Malleista otettiin rakennusosien mitta- määrä- ja sijaintitietoja 54. Elementtiasennuksissa tämä sujui luontevasti ja myös muissa rakennusteknisissä töissä riittävän hyvin, mutta taloteknisissä toteutuksissa esiintyi ongelmia. LVIS-piirustusten ja -tietomallien välillä vallitsi ajoittain ristiriitoja. Hankkeen edetessä todettiin, että asennuksissa noudatetaan piirustuksia, ja tietomallit toimivat suuntaa antavana apuvälineenä. Kohteen työmaainsinöörit havainnollistivat asentajille malleja ja kuvakaappauksia käyttäen, miten suunnittelija oli ajatellut asennukset toteutettavaksi. Työmailla Tekla Structures -malleja käytettiin edellä mainitun ohella runkovaiheen 4Daikataulunhallintaan55. Arkkitehti- ja yhdistelmämalleista otetut määrätiedot toimivat lähtökohtana myös muille aikataulutehtäville, jotka laadittiin määräpohjaisesti. 3.2. Tietomallien käytön erityispiirteet ja edut elinkaari- hankkeissa Elinkaarihankkeiden luonteen ja keston vuoksi voidaan hankekohtaiset tietomallintamiskäytännöt hioa toimiviksi sekä sitouttaa projektiorganisaatio näihin käytäntöihin56. Elinkaarihankkeissa projektiorganisaation muodostaminen ja tehtävien jakaminen ovat palveluntuottajan vastuulla. Koska case-hankkeessa palveluntuottajaorganisaatiolle kuuluu 25 vuoden ylläpito sisältäen kustannusvastuuta, on palveluntuottajan varmistettava kohteen kustannustehokkuus. Tämä mahdollistetaan elinkaarilaskelmilla ja vaihtoehtotarkasteluilla, joissa tietomalleja voidaan käyttää apuna57. Varsinkin ilmanvaihdon ja jäähdytyksen optimointi sekä lämmitystarpeen minimointi ovat avainasemassa. Jos kohteen vaatimuksena on esimerkiksi ympäristöluokitus, voidaan vaatimuksen toteutuminen varmistaa 53 Kakkinen, Karhunen, Ronkainen, LVIS-urakointi . Haastattelu Kuopio 17.2.2011 54 Niemi, Harri, työmaainsinööri. Haastattelu Kuopio 18.2.2011. 55 Koponen, Mikko, työmaainsinööri. Haastattelu Kuopio 16.2.2011. 56 Varstala, Matti, projektipäällikkö . Haastattelu Helsinki 10.2.2011. 57 Leppävuori, Mairinoja, elinkaarilaskelmakonsultointi . Haastattelu Espoo 14.2.2011 40 tietomallin tietosisältöön perustuvilla laskelmilla. Kustannustehokkuuden ohella kohteen laatutaso ja huollettavuus varmistetaan mallintavalla suunnittelulla, jolla vähennetään suunnitelmien ristiriitoja ja virheitä. Elinkaarihankkeiden tarjouskilpailut ovat osoittautuneet äärimmäisen vaativiksi58. Tarjoajien on panostettava mittava määrä resursseja kilpailuun, jonka he saattavat hävitä. Tietomallit helpottavat merkittävästi laskentaa sekä suunnitteluratkaisun muotoilemista ja esittämistä tarjousvaiheessa. Kuitenkaan tietomallintamiseen itseensä ei kannata uhrata liikaa resursseja vielä tässä vaiheessa59. Martti Ahtisaaren koulu ja Puijonsarven koulu päädyttiin vastoin alkuperäistä ajatusta toteuttamaan projektinjohtomallisesti limitetyillä toteutussuunnittelu- ja tuotantovaiheilla, mikä johtui siitä, että kohteissa tuli suuria käyttäjämuutoksia. Esimerkiksi väestönsuojat laajenivat molemmissa kouluissa ja Martti Ahtisaaren koulun keittiön koko suureni kesken hankkeen60. Kun suunnittelu- ja toteutusvaihe limitettiin, kohdistui suunnittelijoihin suuri aikataulupaine, joka on aiheuttanut suunnitteluvirheitä. Toisaalta jos elinkaarihanketoteutusmuotoinen projekti toteutetaan vaiheita limittäen, voidaan kohteiden toteutusorganisaatioiden asiantuntemusta hyödyntää tietomallintamisessa. Tämä tuottaa konkreettisen hyödyn mallinnettujen suunnitteluratkaisujen toteutuskelpoisuuden ja laadun kannalta61. Elinkaarihankkeissa on usein peruskorjattavia kohteita. Näissä kohteissa voidaan suunnittelussa hyödyntää inventointimallia. Inventointimallin avulla on helpompi hahmottaa, kuinka paljon todellinen kohde poikkeaa vanhoista suunnitelmista sekä tutkia, miten uudet rakenteet ja tekniikka saadaan sovitettua olemassa olevaan rakennukseen. Elinkaarihankkeen ylläpitovaiheen aikana voidaan hyödyntää mahdollista toteuma- tai ylläpitomallia. Näihin malleihin voidaan lisätä huollettavuuden kannalta olennaiset yksityiskohdat sekä asennetun tekniikan tuotetiedot. Tätä käsitellään tarkemmin luvussa 3.14. 58 Perko, Räihä, arkkitehtisuunnittelu. Haastattelu Helsinki 11.2.2011 59 Vasara, Oravainen, Ollikainen, Lehikoinen, LVIS-suunnittelu . Haastattelu Kuopio 17.2.2011. 60 Niemi, Harri, työmaainsinööri. Haastattelu Kuopio 18.2.2011. 61 Liukkonen, Jari. Tate-valvoja. Haastattelu Helsinki 8.2.2011. 41 Koska case-hankkeessa loppukäyttäjä on Kuopion kaupungin tilakeskuksen lisäksi koulun opetustoimen henkilökunta ja myös tulevat koululaiset, tietomalleja voidaan hyödyntää visualisoimalla kohde myös heille. Kuopion elinkaarihankkeessa oli mallia käyttäen tehty jopa pieni video Puijonsarven koulun harjannostajaistilaisuuteen, jossa kohde esiteltiin tuleville koululaisille62. 3.3. Tietomallintamisen käynnistäminen ja aloituskokous Päätös tietomallintamisesta tehdään hanketta käynnistettäessä. Jos kohde päätetään mallintaa, on sovittava useasta käytännön asiasta liittyen mallin laajuustasoon sekä käyttötarkoitukseen63. Nämä asiat tulee sopia jo suunnittelua tilatessa, mutta niitä on voitava täsmentää hankkeen alkuvaiheissa. Näihin asioihin on pyrittävä saamaan selvyys jo heti alussa, koska suunnittelukiireiden alkaessa eri osapuolten mallinnusmenetelmien yhteensovittaminen ja korjaaminen on hankalaa ja riskialtista64. Haastatteluissa käsiteltiin järjestelmällistä kokousta, jossa sovittaisiin kaikki kohteen tietomallinnuksen kannalta olennaiset periaatteet. Haastateltavat olivat lähes yksimielisiä siitä, että erillinen tietomallintamisen aloituskokous on järjestettävä, mutta yksi aloituskokous riittänee. Jos asioita ei saada lopullisesti sovittua, on tarvittaessa voitava järjestää useampia aloituskokouksia hankkeen alussa. On ihanteellista, jos suunnittelutoimistojen ja työmaan mallinkäyttäjät voisivat osallistua tietomallintamisen aloituskokoukseen jo näin varhaisessa vaiheessa. Case-hankkeen tietomallintamista koskien järjestettiin pienimuotoinen mallinnuspalaveri elokuussa 2009 palveluntuottajaorganisaation ja pääsuunnittelijan välillä 65. Kokouksessa käytiin läpi, miten arkkitehtimalli on laadittava, jotta se olisi käyttökelpoinen Lemminkäiselle. Tate-mallintamisesta käytiin palaveri Lemminkäisen ja Granlundin Helsingin edustajan välillä. Lisäksi Rajalan koulun ja Puijonlaakson päiväkodin mallintamiseen liittyen pidettiin virallisempi tietomallintamisen aloituskokous helmikuussa 200966. Rajalan koulu on peruskorjauskohde, minkä vuoksi kohteen mallintaminen edellyttää esimerkiksi mallintamistoleransseista sopimista. 62 Virit, Artur, tietomalliasiantuntija. Haastattelu Helsinki 8.2.2011 63 Varstala, Matti, projektipäällikkö . Haastattelu Helsinki 10.2.2011. 64 Vasara, Oravainen, Ollikainen, Lehikoinen, LVIS-suunnittelu . Haastattelu Kuopio 17.2.2011. 65 Mallinnuspalaveri pöytäkirja, Kuopion elinkaarihanke 26.8.2009. 66 Niemi, Harri, työmaainsinööri. Haastattelu Kuopio 18.2.2011. 42 Aloituskokouksessa käsitellyt asiat tulee kirjata pöytäkirjaan. Diplomityön yhteydessä kehitetään Lemminkäisen tietomallintamisen aloituskokouksen asialistapohjaa seuraavia case-hankkeen kohteita ja muita Lemminkäisen hankkeita varten. Aloituskokouksen merkitys korostuu, kun hankkeessa on osapuolia, jotka eivät ole aiemmin olleet mallintamisen kanssa tekemisissä. Aloituskokous toimii tällöin keinona perehdyttää osapuolet mallintamisen käytäntöihin ja mahdollisuuksiin. Tärkein hankkeen alussa täsmennettävä asia on mallien käyttötarkoitukset. Casehankkeessa mallia päätettiin hankkeen edetessä hyödyntää yhä laajemmin ja laajemmin, mikä johti mallin laajuustason muuttamiseen suunnittelun aikana. Sen ohella eri osapuolilla ei ollut yhteistä näkemystä mallin käytöstä, joten suunnittelualat tuottivat mallit omien lähtökohtiensa pohjalta. Mikäli mallin käyttötarkoitukset ovat onnistuneesti sovittu suunnittelusopimuksissa, mallin laajuus- ja tarkkuustasokin voidaan määrittää jo kohteen mallinnuksen käynnistyessä. Lisäksi käyttötarkoitukset vaikuttavat käytettävien ohjelmien, tiedostomuotojen ja mallintamismenetelmien käyttöön 67. Mallin käyttö esimerkiksi määrälaskennassa, simuloinnissa tai ylläpitomallina edellyttää mallin sisällöltä enemmän kuin mallin hyödyntäminen pelkästään suunnittelussa. Kun mallin käyttötarkoitukset ovat tiedossa, tulee täsmentää mallien laajuustasot eri vaiheissa. Tietosisällön laajuustasot eri vaiheissa on sisällytettävä suunnitteluaikatauluun. Mallien laajuustasoja määriteltäessä on hahmotettava, mikä tietosisältö on kaikille osapuolille täysin tarpeetonta ja mikä tekee mallista liian raskaan. Mallien hitaus korostuu natiivi- eli alkuperäismalleja käytettäessä. Varsinkin tietomallin käyttö ylläpitomallina edellyttää laajaa tietosisältöä objektien tuotetiedon osalta. Mallin tietosisältöjen laajuutta hankkeen eri vaiheissa käsitellään lisää kohdassa 3.6. Mallin käyttötarkoituksen kannalta on tärkeää päättää, tuotetaanko kohteesta yhdistelmämalli. Yhdistelmämallin voi toteuttaa usealla eri ohjelmalla. Mallin yhdistämiseen käytetään usein IFC-muotoja, mutta myös 3D-CAD-malleja ja joitakin natiivimuotoja voidaan käyttää mallinnusohjelmista riippuen. Yhdistelmämallin sisältö on täsmennettävä kuten osamallienkin sisällöt. Myös yhdistelmämalli kannattaa pitää tietosisältönsä osalta kevyenä. Varsinkin yhdistelmämallin tarkastaminen säännöstöjä käyt- 67 Salin, Janne, tietomalliasiantuntija. Haastattelu Helsinki 4.2.2011 43 täen on sekä tietokonejärjestelmän että mallin käyttäjän kannalta raskas, jos se sisältää liian laajan ja tarkan tietosisällön. Hankkeen alussa tulee kirjata, mitä ohjelmia ja -versioita hankkeen eri osapuolet aikovat käyttää68. Käytettävät ohjelmistot tulee olla IFC-sertifioituja. Suunnittelussa käytettävät mallinnusohjelmistot vaikuttavat IFC-käännön ja mallinnuksen lähtökohtiin. Olennaista on myös määrittää, mitä mallinkatselu- ja käyttöohjelmia osapuolet käyttävät. Nämä ohjelmistot hyödyntävät mallia joko natiivi- tai IFC-muodossa. Mikäli mallia käytetään IFC-muodossa, on varmistettava, että muunto IFC-muotoon tapahtuu oikeilla parametreilla. Yhteensopivuusongelmia on myös tuottanut uudempaan ohjelmistoversioon vaihtaminen kesken hankkeen. Vaikka usein ei koidu ongelmia, saattaa pahimmassa tapauksessa ohjelmistoversiota vaihdettaessa koko mallintava suunnitteluprosessi rampautua useaksi päiväksi. Lisäksi lisäosien ja –objektikirjastojen käyttö saattaa aiheuttaa yhteensopivuusongelmia esimerkiksi visuaalisesti. On tärkeää sopia, mitä mallinnusohjeita ja aloituspohjia kohteen mallintamisessa on tarkoitus käyttää. Sen ohella tulee mallinnuksen edetessä kirjata ne asiat, joissa mallinnusohjeista on poikettu. Lemminkäinen on laadittanut tiiviit mallinnusohjeet ArchiCAD ja Revit Architechture –ohjelmiin. Ohjeiden tarkoituksena on saada ark-mallista yhteensopiva Lemminkäisen käyttämän Tocomanin TCM Pro-määrälaskentaohjelman kanssa. Mallinnusohjeet ottavat kantaa rakenteiden mallintamiseen kerroksittain, rakennetyyppien koodaukseen ja attribuuttitietojen merkintään 69. Näistä ohjeista voidaan poiketa, mutta poikkeamat tulee kirjata. Suunnittelijoiden omien mallinnusohjeiden käyttö tulee hyväksyttää tietomalliasiantuntijoilla, jos ne eivät ole yhtenevät Lemminkäisen mallinnusohjeiden kanssa. Case-hankkeessa käytettiin kuitenkin mallinnusohjeista poikkeavaa arkkitehtitoimiston mallinnusperiaatetta, joka hyväksytettiin palveluntuottajaorganisaation tietomalliasiantuntijoilla70. Arkkitehdin mallinnustapa oli huomattavasti tarkempi. Se ei tästä syystä ole täysin yhteensopiva verrattuna rakennusliikkeen käyttämiin laskentamenetelmiin, jotka perustuvat tietokonepohjaisiin määrälaskentaohjelmiin. Lisäksi arkkitehtimallin käyttö simuloinneissa ei myöskään onnistunut. Simulointeja käsitellään tarkemmin luvussa 3.16. 68 Partanen, Matti, tietomalliasiantuntija. Haastattelu Helsinki 3.2.2011 69 ArchiCAD14-mallinnusohjeet 4.1.2011, Lemminkäinen Oy:n Toimintajärjestelmä 70 Perko, Räihä, arkkitehtisuunnittelu. Haastattelu Helsinki 11.2.2011 44 Aloituskokouksessa pitää kirjata tietomallintamisen vastuuhenkilöt suunnittelualoittain sekä palveluntuottajaorganisaatiosta. Vastuuhenkilö toimii mallin osalta toimistonsa yhteyshenkilönä ongelmatapauksissa. Hänen tulee osallistua mallin tuottamiseen, käyttämiseen tai tarkistamiseen. Myös mallin yhdistämiselle tulee määrittää vastuuhenkilö, joka oli case-hankkeessa palveluntuottajaorganisaation tietomalliasiantuntija Artur Virit. Lisäksi voidaan määrittää hankekohtaiset tukihenkilöt, jotka osaavat auttaa mallintamiseen liittyvissä seikoissa, mutta eivät välttämättä ole itse kohteen suunnittelussa tai toteutuksessa mukana. Case-hankkeessa tässä tehtävässä toimivat Lemminkäisen tietomalliasiantuntijat. Hankkeen alussa tulee myös sopia päivityskäytännöistä hankkeen eri vaiheissa. Olennaista on, että osapuolet tietävät käytännöt ja pysyvät niissä. Etenkin suunnitelmia päivittäessä on vältettävä ristiriitoja paperipiirustusten ja mallin välillä. Niiden on päivityttävä samaan tahtiin. Case-hankkeessa tämä on koitunut ongelmaksi siitä huolimatta, että piirustukset tulostetaan mallista. Haastatteluissa kävi ilmi, että varsinkaan toteutusvaiheessa ei voida sopia mallin päivitykselle kiinteätä aikaväliä. Kuitenkin yhdistelmämallin päivitykselle tulee määrittää kiinteä aikaväli. Varmuuden vuoksi osapuolille on selvitettävä hankkeen alkaessa, menevätkö piirustukset mallin edelle ristiriitatilanteessa71. Hanketta käynnistettäessä tulee määritellä käytettävät tietomallin laadunvarmistuskäytännöt. Haastatteluissa on korostettu sitä, että mallin tarkistamisen on oltava nykykäytäntöä järjestelmällisempää. Malli on hyvä työkalu tutkittaessa suunnitteluratkaisuiden ongelmakohtia, mutta se edellyttää rutiininomaista mallin läpikäymistä kaikilta keskeisiltä osapuolilta. Laadunvarmistus- sekä päivityskäytäntöjä voidaan kuitenkin tarkentaa hankkeen edetessä. Hankkeen alussa on eri osapuolille selvennettävä, mitä kaikkea dokumentaatiota mallin tuottamisen ja käytön yhteydessä on kirjattava, jotta voidaan hankkeen myöhemmissä vaiheissakin palata mallinnuksen lähtökohtiin, niistä poikkeamiseen sekä suunnitteluratkaisujen muovautumiseen. Mallin tuottamisen osalta dokumentaatioon kuuluvat 71 Kakkinen, Karhunen, Ronkainen, LVIS-urakointi. Haastattelu Kuopio 17.2.2011 45 mallinnusohjeista poikkeaminen ja tietomalliselostukset. Tämä dokumentointiprosessi tulee kuitenkin säilyttää mahdollisimman kevyenä. Malleja tuotettaessa on olennaista määrittää mallinnuksessa käytettävät toleranssit ja tarkkuustaso. Tällä tarkoitetaan sitä, kuinka suuria poikkeamia sallitaan suunnitellun ja todellisen/toteutetun rakenneosien välillä. Toleransseja ei voi kesken suunnittelun enää tarkentaa. Mallinnuksen yhdistämisen kannalta on kriittistä sopia aloituskokouksessa käytettävä koordinaatisto nollapisteineen ja nollakorkoineen. Yleensä arkkitehti valitsee koordinaatiston. Vaikka koordinaatistojen poikkeamisen huomaa helposti, niiden kohdalleen sovittaminen on paljon hankalampaa, kun mallinnus on jo aloitettu. Lisäksi esimerkiksi tate-malli suunnitellaan usein kerroksittain, jolloin niiden sovittamiseen tulee kiinnittää erityishuomiota. Koordinaatistojen sovittamisen avuksi otettiin esille ns. kohdistuskuution käyttö. Tietomalliasiantuntijoiden mukaan kohdistuskuution käytöstä on hyötyä osamallien yhteensovittamisessa. Kohdistuskuutiota tai vastaava objektia, joka voi olla esimerkiksi myös pallon, renkaan tai suorakulmion muotoinen, käytettäisiin sovittamaan eri osamallien koordinaatistot kohdalleen malleja yhdistettäessä. Kohdistusobjekti sijoitettaisiin sovittuun pisteeseen rakennuksen lähelle. Jos osamallien kohdistusobjektit eivät olisi kohdakkain, huomaisi välittömästi, että koordinaatistot eivät ole yhtenevät, jolloin poikkeamat on korjattava. Lisäksi hankkeen alussa tulee asettaa paljon pieniä käytännön toimintasääntöjä varsinkin IFC-tiedonsiirron ja tiedonhallinnan osalta. Näitä asioita ovat esimerkiksi piirustustasojen ja tiedostojen nimeämiskäytännöt. Suunnittelijoiden on käytettävä mallinnusohjeiden ja Talo2000–järjestelmän mukaisesti nimettyjä piirustustasoja tai kirjattava poikkeukset muita osapuolia varten. Tasojen nimeämiskäytännöistä on olemassa suositus Senaatti Kiinteistöjen CAD-ohjeessa72. IFC-tiedostomuuntoa käsitellään luvussa 3.8. Hankkeen alussa on myös käytävä läpi, mitä suunnittelusopimuksessa on sovittu malliin liittyvissä oikeus- ja vastuukysymyksissä esimerkiksi mallin luovutusta koskien. Tämä koskee lähinnä tapauksia, joissa poiketaan KSE:n ehdoista. Käytännössä tärkeää on 72 Senaatti Kiinteistöt (2010): Teknisen Dokumentoinnin Ohjeisto osa 1: Digitaalinen Aineisto 46 ottaa huomioon, että suunnittelijoiden ja rakennusliikkeen liiketoiminnan kannalta luottamuksellista asiantuntemusta ei siirry varsinkaan mallien natiivimuodossa hankkeen ulkopuolisille. 3.4. Tietomallintamiseen liittyvät kokouskäytännöt Case-hankkeen kohteissa on ollut suunnittelu- ja työmaakokoukset 3-4 viikon välein ja niiden lisäksi käyttäjäpalaverit sekä muutama erillinen mallinnuspalaveri 73. Jatkossa case-hankkeen tulevissa kohteissa pyritään järjestämään hankkeen alkaessa mallinnuspalaveri sekä mahdollisia yhteisiä kokouksia, joissa tarkastetaan mallia. Haastateltavat olivat melko yksimielisiä siitä, että malleja tulisi hyödyntää kaikissa kokouksissa, joissa käsitellään suunnitteluratkaisuja. Malli heijastetaan seinälle kaikkien nähtäville videotykkiä käyttäen74. Mallia käsittelisi joko kokouksen puheenjohtaja tai se osapuoli, jonka suunnittelualan asioita kokouksessa eniten käsitellään. Mallia käytettäisiin kokouksissa kuitenkin edelleen rinnakkain paperipiirustusten kanssa, mutta kohteen nopea visualisointi olisi paljon kätevämpää mallin kautta kuin piirustuksia selaamalla. Haastatteluissa suositeltiin, että kokouksissa käytettäisiin kevyttä yhdistelmämallia esimerkiksi Solibri Model Checker –ohjelmalla kuten case-hankkeessa. Mahdollinen yhdistelmämalli pitää antaa osapuolten käytettäväksi hyvissä ajoin ennen suunnittelukokousta. Lisäksi mallista voi ottaa kuvakaappauksia kokouskutsun liitteeksi havainnollistamaan käsiteltäviä suunnitteluasioita. Mallin hyödyntäminen kokouksissa edellyttää videotykkiä liitäntöineen, kangasta, riittävän tehokasta konetta ja harjaantunutta mallin käyttäjää. Mallia on käytetty videotykillä suunnittelukokouksissa75. Case-hankkeen kohteiden työmailla ei ole ollut videotykkivalmiuksia, mutta tarvittaessa mallia on voitu katsoa myös tietokoneen näytöltä. Case-hanketta tutkittaessa tultiin siihen tulokseen, että hankkeissa on järjestettävä erillinen kohteen tietomallintamisen aloituskokous, jossa käydään läpi mallintamiseen liittyvät käytännön asiat sekä tekniset seikat. Aloituskokous käsiteltiin kohdassa 3.3. Haastatteluissa ei oltu täysin yksimielisiä siitä, tarvitaanko aloituskokouksen jälkeen erillisiä mallinnuspalavereja vai tuleeko mallinnusasiat käsitellä suunnittelu- ja työmaa73 Varstala, Matti, projektipäällikkö. Haastattelu Helsinki 10.2.2011. 74 Salin, Janne, tietomalliasiantuntija. Haastattelu Helsinki 4.2.2011 75 Koponen, Mikko, työmaainsinööri. Haastattelu Kuopio 16.2.2011. 47 kokouksissa. Enemmistö kallistui kuitenkin siihen, että mallinnusasiat ovat osa suunnitteluasioita eikä erillisiä mallinnuspalavereja tarvita. Ensinnäkin kokouksiin käytetty aika on aina muusta suunnittelusta pois76. Kokouksissa tulisi mieluummin käsitellä suunnitteluongelmia eikä käydä mallinnusperiaatteita läpi. Toiseksi epäiltiin sitä, tulisiko mallinnuspalavereihin riittävästi osallistujia77. Mallinnuspalaverin puolesta todettiin, että suunnittelukokouksiin osallistuu varsinkin isoissa hankkeissa useita osapuolia, jotka eivät osallistu mallin käyttämiseen 78. Mallinnusasiat saattaisivat jäädä tällöin paljon pienemmälle huomiolle. Lisäksi suunnittelutoimistojen mallintajat voisivat osallistua mallinnuskokouksiin tuoden näkemystään ja tarpeitaan esille79. Suunnittelukokouksissa ei tarvitse välttämättä eriyttää mallinnusasioita erilleen asialistassa, vaan ne voidaan käsitellä eri suunnittelualojen alla. Suunnitteluongelmat käytäisiin läpi seinälle heijastetun mallin avulla. Jos mallin katselua ohjaa kokouksessa kokenut suunnittelija, voi olla mahdollista, että ongelma saadaan mallissa korjattua jo itse ongelmaa käsiteltäessä80. Tämä on haastattelujen mukaan todennäköisesti vaikeinta arkkitehtisuunnittelun osalta. On liian aikaista sanoa, voiko kokoustilanteissa tiimityötoimintoja käyttää tähän tarkoitukseen tulevaisuudessa. Olennaista on, ettei kokouksessa vaan todeta, että suunnittelijat ovat tarkastaneet mallit. Mallien tarkastuksen suorittaminen on voitava todentaa. Haastatteluissa kävi ilmi, että muissa hankkeissa on ollut käytössä yhdistelmämallikokous, jossa yhdistelmämalli tarkastetaan yhteisesti. Yhdistelmämallikokouksia pitää järjestää ainakin yksi toteutussuunnittelun edettyä riittävän pitkälle, mutta mieluummin useampia. Yhdistelmämallikokousta käsitellään laadunvarmistuksen yhteydessä kohdassa 3.10. Haastattelujen mukaan suunnittelijat luonnollisesti käyttävät tietomalleja hyväkseen sisäisissä kokouksissaan suunnitteluratkaisujen tutkimiseen ja risteilytarkasteluihin. Kokouksissa mallia hallitsee se, jonka suunnitteluasioita kokouksessa eniten käsitellään. 76 Perko, Räihä, arkkitehtisuunnittelu. Haastattelu Helsinki 11.2.2011 77 Niemi, Harri, työmaainsinööri. Haastattelu Kuopio 18.2.2011. 78 Kakkinen, Karhunen, Ronkainen, LVIS-urakointi. Haastattelu Kuopio 17.2.2011 79 Vasara, Oravainen, Ollikainen, Lehikoinen, LVIS-suunnittelu. Haastattelu Kuopio 17.2.2011. 80 Virit, Artur, tietomalliasiantuntija. Haastattelu Helsinki 8.2.2011 48 Malleja on hyödynnettävä enemmän käyttäjäpalavereissa suunnitteluratkaisujen havainnollistamiseen ja käyttäjätarpeiden tunnistamiseen. Varsinkin kohteissa, joissa käyttäjät ovat maallikkoja, he osaavat antaa suunnitteluratkaisuista paremmin palautetta mallin avulla jo varhaisessa vaiheessa. Kuitenkin haastatteluissa korostettiin, että yleensä kohteissa esiteltävä malli esimerkiksi markkinointikäytössä on esteettisiltä arvoiltaan erilainen kuin esimerkiksi suunnittelussa käytettävä yhdistelmämalli. Urakoitsijoiden on käytettävä mallia enemmän sisäisissä tai aliurakoitsijoiden kanssa järjestettävissä kokouksissa. Mallin havainnollisuutta voidaan käyttää kohteen ja sen suunnitelmien esittelyyn. Myös työntekijät voidaan perehdyttää kohteeseen esimerkiksi mallinnettua työmaasuunnitelmaa käyttäen. On otettava kuitenkin huomioon, että urakoitsijoiden työntekijät ovat tottuneita paperipiirustusten käyttäjiä. Ne saattavat olla jopa havainnollisempia heille. Mallia voi käyttää esimerkiksi urakkaneuvotteluissa, aloituspalavereissa, tate-palavereissa ja urakoitsijakokouksissa. Mallia esiteltäessä mahdollisimman monelle osapuolelle kannustetaan myös aliurakoitsijoita ottamaan käyttöön esimerkiksi ilmaiset katseluohjelmat. Aliurakoitsijoiden mallin käytön yleistyminen auttaisi saamaan myös heidän panosta mallin laadunvarmistukseen81. Tietomalleja voi käyttää hyväksi luovutukseen liittyvissä kokouksissa. Mallia voi käyttää myös esimerkiksi taloudellisessa loppuselvityksissä määrien vertailuun. 3.5. Mallien päivityskäytännöt ja muutostenhallinta Haastattelututkimuksessa suositeltiin projektipankin käyttöä parhaana tiedonsiirtomenetelmänä. Case-hankkeessa projektipankki otettiin käyttöön pian hankesopimuksen solmimisen jälkeen82. Sitä ennen oli käytössä vain arkkitehdin malli, jota välitettiin muille osapuolille sähköpostilla tai muistitikulla. Ihanteellista olisi, jos mallia voisi päivittää osapuolten välillä reaaliajassa esimerkiksi tiimityö- tai synkronointitoimintoja käyttäen, mutta ne eivät ole toimineet riittävän nopeasti ja virheettömästi 83. Tiimityökaluja käsitellään lisää kohdassa 3.13. Projektipankinkin käyttö vaatii tietyn tason kurinalaisuutta sekä mallin päivittäjiltä että mallin lataajilta84. Viimeisin malli pitää lisätä pankkiin ilman erillistä pyyntöä. Päivitys 81 Partanen, Matti, tietomalliasiantuntija. Haastattelu Helsinki 3.2.2011 82 Perko, Räihä, arkkitehtisuunnittelu. Haastattelu Helsinki 11.2.2011 83 Virit, Artur, tietomalliasiantuntija. Haastattelu Helsinki 8.2.2011 84 Leppävuori, Mairinoja, elinkaarilaskelmakonsultointi. Haastattelu Espoo 14.2.2011 49 on suoritettava suunnitteluvaiheessa sovittuna ajankohtana esimerkiksi maanantaisin parillisilla viikoilla. Projektipankin käyttäjien on osattava tarkistaa itse tai tilata muistutus mallien päivityksistä. Lisäksi tiedostot on laitettava oikeisiin paikkoihin nimettynä järjestelmällisesti. Mikäli hankkeessa käytetään malleja eri suunnittelualojen kesken tai tuotetaan yhdistelmämalli, on projektipankkiin aina lisättävä mallit IFC-muotoisina. Mallien käyttötarkoituksista ja mallien käyttäjien osaamisesta riippuen sinne on lisättävä ark- tai rak-mallit natiivimuodoissa, koska IFC-muodossa ei siirry kaikki tieto. Esimerkiksi case-hankkeessa ainoa keino lisätä aikataulutietoa malliin, oli käyttää Tekla Structures -ohjelman natiivimallia. Haastatteluissa todettiin, että tate-mallin natiivimuodolle tuskin löytyy taloudellisesti kannattavaa käyttöä työmaalla, vaikka se sisältää paljon enemmän tuotetietoa kuin IFC-muotoinen malli85. Samalla haastatteluissa korostettiin, että on ollut jo suuri askel sisäistää IFC-muotoisten mallien käyttö työmaalla, joten on liian korkea kynnys ottaa MagiCAD-ohjelmisto käyttöön urakoitsijapuolella. Päivitystaajuutta käsiteltäessä todettiin, että on hankala sopia mallin päivitystahdille kiinteä aikaväli, koska suunnittelu etenee epälineaarisesti. Välillä suunnitelmat muuttuvat viikossa huomattavasti ja joskus ne sitä vastoin eivät muutu kuukauden aikana ollenkaan. Toisaalta tarjous- tai suunnitteluvaiheen aikana saattaa esimerkiksi arkkitehtimalli päivittyä liiankin nopeasti, jolloin muut osapuolet eivät voi käyttää sitä oman mallinnuksensa, simulointien tai laskennan pohjana. Olennaista päivitystaajuuden kannalta on se, että se noudattaa suunnitteluaikataulua, eikä se ole ristiriidassa paperipiirustusten päivityksen kanssa. Case-hankkeen Martti Ahtisaaren koulun ja Puijonsarven koulun kohteissa on yhdistelmämalli julkaistu 4 viikon välein juuri ennen suunnittelu- tai työmaakokousta. 4 viikon päivitystaajuuden myötä yhdistelmämalli ei ole ollut ajan tasalla. Casehankkeessa ovat osamallitkin päivittyneet aika ajoin viiveellä paperipiirustusten suhteen, jolloin yhdistelmämalli on saattanut olla lähes kuukauden suunnitelmamuutosten jäljessä tai muutoin ristiriitainen osamallien suhteen. Seurauksena päätettiin, että casehankkeen tulevissa kohteissa kuten Rajalan koulussa, jota tällä hetkellä suunnitellaan, päivitetään yhdistelmämallia 2 viikon välein86. Optimaalista olisi, jos yhdistelmämallia 85 Vasara, Oravainen, Ollikainen, Lehikoinen, LVIS-suunnittelu. Haastattelu Kuopio 17.2.2011. 86 Varstala, Matti, projektipäällikkö. Haastattelu Helsinki 10.2.2011. 50 päivitettäisiin aina saman tien osamallien päivityksen jälkeen, mikä voisi olla mahdollista, jos yhdistelmämallin päivittäisi joku suunnittelijoista. Case-hankkeessa on LVI- ja sähkösuunnittelu onneksi saman toimiston käsissä, joten suunnittelijat pystyivät tutkimaan suunnitelmiaan ja malleja ristiin lähes reaaliajassa. Usean suunnittelutoimiston välinen tate-mallinnus olisi edellyttänyt suunnitteluvaiheessa todella tiheää päivitystahtia. Tuotantovaiheessa mallien valmiusasteen on oltava jo lähellä 100% ja päivitysten epäsäännöllisiä. Todettiin kuitenkin, että esimerkiksi tate-mallinnusohjelma MagiCAD:llä pienten muutosten tekeminen on niin työlästä, että jokaista muutosta ei kannata malliin tehdä. Tästäkin tulee sopia yhteiset säännöt etenkin, jos kohteesta tuotetaan toteuma- tai ylläpitomalli. Malleja päivitettäessä on koettu ongelmaksi muutostenhallinta 87. Perinteisten paperipiirustusten revisiomerkintöjen sijaan mallista on aina etsittävä tapahtuneet muutokset joko visuaalisesti tai mallinnusohjelmien muutostenjäljitystoimintojen avulla. Esimerkiksi Solibri Model Checker –ohjelmassa on kätevä muutostenhallintatyökalu, jolla voidaan vertailla päivitettyä ja vanhaa mallia. Tekla Structures –ohjelma tallentaa lokia muutoksista ja siinä on muutostenjäljitystoiminto, mutta se on tällä hetkellä hidas ja epäkäytännöllinen88. Toinen muutostenhallinnan konkreettinen väline on tietomalliselosteiden lisääminen projektipankkiin mallin päivityksen yhteydessä. Tietomalliselostukseen tulee kirjata mallin päivittäjän yhteystiedot, käytetty ohjelmisto ja sen lisäosat sekä olennaisimmat muutokset edelliseen malliin. Tietomallikäytännön pitää kuitenkin olla mahdollisimman kevyt, jotta se ei vaadi suunnittelijoita liikaa työpanosta. Case-hankkeessa tietomalliselostuksia ei ole suunnittelijoilta vaadittu. Tietomalliselosteiden tarpeellisuutta ei osattu aiemmin ottaa huomioon ja jatkossa tietomalliselostuksia aiotaan edellyttää suunnittelijoilta. Kun mallin käyttäjät lataavat päivitetyn mallin, he samalla kadottavat vanhaan malliin lisäämänsä tiedon kuten määräluettelot tai aikataulutiedon89. Tätä ongelmaa pyrittiin 87 Kakkinen, Karhunen, Ronkainen, LVIS-urakointi. Haastattelu Kuopio 17.2.2011 88 Pehkonen, Turunen, rakennesuunnittelu. Haastattelu Kuopio 18.2.2011. 89 Niemi, Harri, työmaainsinööri. Haastattelu Kuopio 18.2.2011. 51 välttämään case-hankkeessa käyttämällä tiimityö- ja synkronointitoimintoja. Nämä työkalut eivät ole toimineet kunnolla. Tässä asiassa nopeammasta mallin päivitystahdista on vain haittaa varsinkin, kun synkronointi ei toimi. Ongelma ei koske suunnittelijoiden tuottamia määräluetteloita, jotka säilyvät muutettavassa mallitiedostossa. 3.6. Mallien tietosisällöt eri vaiheissa Mallien tietosisällöt vaihtelevat luonnollisesti vaiheittain, joten tärkeää on mallintamiseen vaikuttavien seikkojen ottaminen huomioon suunnitteluaikataulussa 90. Mallien laajuustasojen ja valmiusasteiden on oltava riittävät siinä vaiheessa, kun muut suunnittelualat alkavat hyödyntää sitä mallintamisensa pohjana. Toteutusvaiheeseen edettäessä pitää mallin laajuus- ja tarkkuustason olla riittävä, jotta kohde voidaan rakentaa mallin mukaisesti. Jos malleja käytetään simuloinneissa, määrä- ja kustannuslaskennassa sekä tuotannonohjauksessa, on niillä mallin tietosisällölle omat vaatimuksensa. Case-hankkeen tarjousvaiheessa oli olemassa arkkitehdin tilamallit, jotka olivat karkeatasoiset91. Näitä käytettiin onnistuneesti suunnitteluratkaisun hiomiseen, vaihtoehtotarkasteluihin, karkeaan tilapohjaiseen laskentaan ja suunnitelmien havainnollistamiseen. Arkkitehdin mukaan tilamallit olisi voitu pienellä vaivalla mallintaa määrätiedon kannalta laajemmassakin muodossa, mutta tätä määrätietoa tuskin olisi voitu hyödyntää tarjouslaskennassa varsinkaan, kun suunnitteluratkaisut ja siten myös määrät muuttuivat vielä92. Sekä arkkitehdille että palveluntuottajalle olisi ollut käyttöä tonttien malleille, jotka tilaaja olisi voinut tuottaa jokaisesta kohteesta. Tontin mallilla tarkoitetaan mallia rakennuspaikasta ja siitä käytetään myös nimitystä maastomalli. Tonttien mallien lisäksi myös olemassa olevien peruskorjauskohteiden inventointimallit pitää saada tilaajalta. Tilamallien tietosisällöt olivat riittävät energia- ja olosuhdesimulointien pohjaksi, mutta mallin tuominen epäonnistui muista syistä johtuen. Simulointeja käsitellään tarkemmin kohdassa 3.16. Martti Ahtisaaren koulun ja Puijonsarven koulun yleissuunnitteluvaiheissa arkkitehtimallien valmiusasteet eivät olleet riittäviä muiden suunnittelualojen mallintamisen poh90 Vasara, Oravainen, Ollikainen, Lehikoinen, LVIS-suunnittelu. Haastattelu Kuopio 17.2.2011. 91 Varstala, Matti, projektipäällikkö. Haastattelu Helsinki 10.2.2011. 92 Perko, Räihä, arkkitehtisuunnittelu. Haastattelu Helsinki 11.2.2011 52 jaksi. Ensinnäkin muut suunnittelijat olisivat tarvinneet enemmän detaljitason tietosisältöä93. Toiseksi malleja ei pystynyt edelleenkään tuomaan LVIS-suunnittelijoiden simulointiohjelmiin IFC-muodossa. Tällöin LVIS-suunnittelijat joutuivat itse tuottamaan kohteiden tilamallit MagiCAD Room –ohjelmalla, ja vaihtoehtotarkastelu hidastui huomattavasti. Edellä mainittujen kohteiden toteutussuunnitteluvaiheissa arkkitehtimallien valmiusasteet olivat kriittisesti jäljessä suunnitteluaikataulusta. Arkkitehtimalleihin tehtiin paljon muutoksia johtuen osittain käyttäjämuutoksista. Seurauksena tate-mallien korjaaminen osoittautui todella työlääksi, jolloin osa muutoksista jäi mallintamatta. On myös tate-suunnittelioiden velvollisuus varmistaa, että he käyttävät mallinnuksensa pohjana käyttökelpoista mallia94. Tämän seurauksena jäivät rakennemallien reikätiedotkin päivittämättä. Toteutussuunnitteluvaiheessa tietomallien tietosisällön pitää olla niin tarkka, että niitä voidaan käyttää elementtisuunnitteluun ja -tuotantoon. Sen lisäksi arkkitehtimallista puuttui edelleen detaljitietoja kuten nurkkadetaljit. Arkkitehti olisi voinut toteutussuunnitteluvaiheen edetessä tuoda malliin vielä tarkempia attribuuttitietoja tai lisätä esimerkiksi todelliset pintamateriaalien värit näkyviin. Nämä olisivat kuitenkin tehneet malleista vielä raskaammat. Tate-suunnittelijat olisivat tarvinneet toteutussuunnitteluvaiheessa tietoa urakoitsijan laitevalinnoista jo varhaisemmassa vaiheessa, jolloin he olisivat voineet lisätä mallin tuotetiedon kerralla oikein95. Tuotetietojen muuttaminen laitevalintojen mukaan jälkikäteen on työlästä. Case-hankkeessa käytettiin tate-mallissa sähkölaiteobjekteja, jotka eivät sisältäneet laitetoimittajien tuotetietoa, jolloin suurin osa näistä objekteista oli tarpeettomia. Sähkörasioiden, kytkimien, turvavalaisimien ja muiden pienten sähkölaitteiden sijainti kävi hyvin ilmi työselityksestä ja mallikuvasta, eivätkä ne vie tilaa muilta rakennusosilta kuin kalusteilta. Kalusteiden sijoittamisessa sähkörasioiden sijainnin visualisointi on hyödyksi. Tulevaisuudessa myös sähkölaitetoimittajat tuovat tuotekirjastoja mallintajien käyttöön. Toteutussuunnitteluvaiheessa yhdistettiin osamallit yhdistelmämalliksi. Osamallien laajuus oli tähän tarkoitukseen täysin riittävä, mutta niissä oli huomattava määrä virheitä ja 93 Pehkonen, Turunen, rakennesuunnittelu. Haastattelu Kuopio 18.2.2011. 94 Liukkonen, Jari. Tate-valvoja. Haastattelu Helsinki 8.2.2011. 95 Vasara, Oravainen, Ollikainen, Lehikoinen, LVIS-suunnittelu. Haastattelu Kuopio 17.2.2011. 53 ristiriitoja96. Yhdistelmämallin tietosisältö on mietittävä sen käytön ja raskauden mukaan. Haastatteluissa todettiin, että esimerkiksi ark-mallin kalusteet on hyvä tuoda yhdistelmämalliin, jotta nähdään niiden sijoittuminen muiden rakennusosien suhteen 97. Toisaalta betoniteräkset ovat tarpeettomia ja tekevät mallista vain raskaamman. Kohteiden toteutusvaiheessa mallien on oltava jo täydessä laajuudessa ja sovitussa tarkkuustasossa. Case-hankkeessa ei kirjattu riittävän hyvin arkkitehtimallin detaljitarkkuutta, jolloin työmaalla oli epäselvää, mihin mallin detaljitietoon pystyi luottamaan. Esimerkiksi Martti Ahtisaaren koulun ikkunat jouduttiin hankkimaan suunniteltua pienempinä, koska asennusvaroja ei otettu mallissa huomioon. Työmaan määrälaskennan kannalta olisi ollut hyvä, jos rakenneosien attribuuttitietoihin olisi lisätty rakenneosien lohkosijainnit. Kohteiden toteutuksissa rakennemallista olisi voitu käyttää enemmän detaljitietoa, ja esimerkiksi kaikki vähäisemmätkin rakenteet sekä rakenteiden eristeet olisi pitänyt mallintaa määrälaskentaa ja havainnollistamista varten. Talotekniikan eristeiden koko on otettava huomioon siirrettäessä suunnittelutietoa rakennesuunnittelijalle. Talotekniikan asennusvaroihin ja –järjestykseen ei kiinnitetty mallinnuksessa tarpeeksi huomiota. Case-hankkeen kohteet eivät vielä ole edenneet käyttö- ja ylläpitovaiheeseen, joten on liian varhaista ottaa kantaa ylläpitomallin lisättäviin tietosisältöihin. Nämä kuitenkin edellyttävät mahdollisimman tarkkaa tuotetietoa. Toteuma- ja ylläpitomallia käsitellään lisää kohdassa 3.14. 3.7. Mallien mittatarkkuus Mallien mittatarkkuustaso tarkoittaa, kuinka paljon mallinnettu rakennusosa saa poiketa todellisuudesta98. Mallien mittatarkkuus tarkentuu hankkeen edetessä eikä alustavassa rakennusosamallissa tarvitse vielä olla tarkkoja mittoja. Poikkeamien on kuitenkin oltava sovittujen toleranssien sisällä. Toleranssit ovat ratkaisevia, kun mallien rakennusosiin tulee kiireellisiä muutoksia, jotka vaikuttavat myös muihin rakennusosiin, koska tällöin vältytään koko ratkaisun uusimiselta99. Toisaalta toleransseja pienempiä muutoksia ei kannata korjata muutenkaan, koska ne voidaan jättää asentajien ratkaistavaksi 100. 96 Virit, Artur, tietomalliasiantuntija. Haastattelu Helsinki 8.2.2011 97 Niemi, Harri, työmaainsinööri. Haastattelu Kuopio 18.2.2011. 98 Senaatti Kiinteistöt (2007): Tietomallivaatimukset osa 1: Yleinen Osuus 99 Liukkonen, Jari. Tate-valvoja. Haastattelu Helsinki 8.2.2011. Kakkinen, Karhunen, Ronkainen, LVIS-urakointi. Haastattelu Kuopio 17.2.2011 100 54 Case-hankkeen kohteissa on sovittu esimerkiksi, että käyttövesijohdot saavat törmätä. Jos malliin määritetään liian väljät toleranssit, ei malli ole toteutuksen kannalta käyttökelpoinen101. Case-hankkeen käyttäjämuutokset ja peruskorjauskohteiden yllätykset korostavat toleranssien käytön tärkeyttä. Toleranssit on otettava huomioon seuraavissa tietomallin käytön osa-alueissa: • suunnitelmien mallintamisen mittatarkkuudessa: kuinka paljon mallinnettu saa poiketa lopullisesta suunnitteluratkaisusta. • rakenneosien risteilyn hipaisutarkkuuden toleranssina: kuinka läheltä osat saavat risteillä tai toisaalta kuinka paljon osat saavat mennä päällekkäin. Toleransseissa pitää myös huomioida asennusvarat ja varaukset esimerkiksi eristeille ja kiinnityksille. • inventointimallin tuottaminen vanhoista piirustuksista tai sähköisillä mittauksilla eli skannauksilla: kuinka tarkasti malli noudattaa todellista kohdetta tai alkuperäisiä piirustuksia. • toteumamallin mallintamisessa: kuinka paljon toteutettu saa poiketa mallinnetusta ilman, että mallia korjataan. • mallin tarkastamisessa säännöstöjen avulla: kuinka suuri poikkeaman on oltava, jotta tarkastustyökalu luokittelee asian virheeksi. Toleransseja käytettäessä täytyy ottaa huomioon summautuva kerrannaisvaikutus 102. Jos ark-mallissa on rakennusosien mallinnustarkkuus 10 cm Senaatti Kiinteistöjen ohjeistuksen mukaisesti, saa alakatto poiketa toteutetusta 10 cm. Oletetaan, että taloteknisille osille on sallittu vastaava 10 cm:n toleranssi, jolloin alakaton poikkeaman takia joudutaan tekniikkakin asentamaan mallinnustoleranssien äärirajoille tai sen ulkopuolelle. Tate-suunnittelijat eivät osanneet haastattelussa sanoa, kuinka toleranssien kertautumiseen tulisi suhtautua. Kysymys on siitä, onko ark-malliin, jonka toleranssi on 10 cm, pohjautuvan tate-mallin toleranssi myös 10 cm vai enemmän. Tarkempaa toleranssia ei voi vaatia. Esimerkiksi Rajalan koulun mallinnustoleranssi LVI-suunnittelun osalta on sovittu 30 millimetriksi, joka on sama kuin ark-mallin. 101 Virit, Artur, tietomalliasiantuntija. Haastattelu Helsinki 8.2.2011 102 Vasara, Oravainen, Ollikainen, Lehikoinen, LVIS-suunnittelu. Haastattelu Kuopio 17.2.2011. 55 Toteumamallin mittatarkkuuteen liittyvät seikat käydään läpi kohdassa 3.14. Rajalan koulun inventointimallin ja rakennusten skannauksen toleransseja käsitellään tarkemmin kohdassa 3.15. 3.8. Mallien yhdistäminen ja IFC-formaatti Tietomallit voidaan yhdistää useilla eri ohjelmilla. Case-hankkeessa projektin yhteiset yhdistelmämallit tuotettiin Solibri Model Checker –ohjelmaa käyttäen 103. Arkkitehtitoimisto kokeili myös korvata arkkitehtimallissaan rakenteita rakennemallin osilla, mutta lopputulos oli raskas ja epäesteettinen. Tate-mallin tuominen teki mallista todella raskaan. Tarkoituksena oli helpottaa arkkitehdin detaljisuunnittelua muiden suunnittelualojen rakenteiden liittymiskohdissa. Lisäksi LVIS-suunnittelutoimiston sisällä käytettiin NavisWorks-ohjelmaa mallin yhdistämisessä104. Malli yhdistetään lataamalla projektipankista viimeisimmät eri suunnittelijoiden IFCmuotoiset osamallit105. Seuraavaksi tarkistetaan, ovatko ne riittävän toimivat yhdistämistä varten esimerkiksi koordinaatistojen osalta. IFC-muotoiset mallit avataan valitulla ohjelmistolla ja tallennetaan yhdistelmämalliksi, joka lisätään projektipankkiin. Haastatteluissa on esitetty, että mallin yhdistämisen tehtävä kuuluu pääsuunnittelijalle, joka usein on pääarkkitehti kuten case-hankkeessa. Mallien yhdistäminen on haastateltavien mukaan luonnollinen jatke pääsuunnittelijan velvollisuudelle vastata suunnitelmien yhteensopivuudesta106. Case-hankkeessa kuitenkin mallin yhdistämisen suoritti palveluntuottajaosapuolen tietomalliasiantuntija, joka ei ole varsinaisesti osallistunut hankkeen suunnittelunohjaukseen muutoin. Tällöin etuna oli, että rakennusliikkeen asiantuntemus mallintamisesta saatiin hyödynnettyä. Lisäksi tuli esille ajatus tietomalliintegraattori –tahosta, joka hoitaisi mallinnuksen koordinoinnin. Vastuuhenkilölle voisi antaa tehtäväksi yhdistelmämallin tarkistamisen suunnitteluvirheiden osalta. IFC-muotoa käytetään nimenomaan silloin, kun malli halutaan avata sellaisenaan tai viitekehyksenä toisessa mallinnus-, simulointi- tai muussa ohjelmassa. IFC-muotoinen malli on tietosisällöltään rajoittuneempi. Kevyttä IFC-muotoa on siten helpompi käyttää katseluohjelmien kautta107. Lisäksi mallien yhdistäminen kaikilla mallinnusohjelmilla 103 Perko, Räihä, arkkitehtisuunnittelu. Haastattelu Helsinki 11.2.2011 104 Vasara, Oravainen, Ollikainen, Lehikoinen, LVIS-suunnittelu. Haastattelu Kuopio 17.2.2011. 105 Virit, Artur, tietomalliasiantuntija. Haastattelu Helsinki 8.2.2011 106 Varstala, Matti, projektipäällikkö. Haastattelu Helsinki 10.2.2011. Salin, Janne, tietomalliasiantuntija. Haastattelu Helsinki 4.2.2011 107 56 edellyttää vieraiden mallimuotojen muuttamista IFC-muotoon. Vaikka IFC-mallin tietosisältö on vähäisempi kuin natiivimallissa, voi sitäkin osittain käyttää määrätiedon hankkimiseen. IFC-muoto oli myös kriittisessä roolissa mallinnettaessa talotekniikan vaatimia reikiä rakennemalliin. Tällä hetkellä käytössä on IFC 2X3-formaatti. Haastattelututkimuksessa ilmeni, että mallinnusohjelmien natiivimuodosta muuntaminen IFC-formaattiin on tuottanut ongelmia. Kävi ilmi, että IFC-käännön yhteydessä on harvoin teknisiä vaikeuksia, vaan ongelmat johtuvat käyttäjän valitsemista asetuksista. Muunnon yhteydessä on osattava laittaa useita asetuksia oikein, jotta lopputuloksena syntyvää IFC-tiedostoa pystyy käyttämään eri tarkoituksiin. Käytännössä MagiCAD- ja Tekla Structures-mallien objekteista voidaan tuoda kaikki tieto IFC-muotoon objektien propertyset-attribuuttitietoja asettamalla, mutta tämä vaatii suunnittelijalta lisätyötä. Objektit on piirrettävä oikealla työkalulla ja oikealle tasolle. Lemminkäisen tietomalliasiantuntijat ovat käyttäneet ArchiCAD-mallin IFC-käännössä yleiskääntäjää. Mallien yhdistämiseksi IFC-mallit tulee muuntaa oikeilla asetuksilla. MagiCAD:ssa valittava erikseen, käytetäänkö mallia osana yhdistelmämallia. ArchiCAD-ohjelmassa tulee IFC-export valikosta laittaa ’siirrä tilarajat’ ja ’siirrä GUID’ –asetukset päälle. Todettiin, että vaikka oletusasetuksia käyttämällä päästään hyvin lähelle käyttökelpoista IFC-mallia, on laadittava IFC-kääntöohje Lemminkäisen hankkeissa käytettäväksi. Varsinkin onnistunut IFC-muodon käyttö simuloinneissa edellyttää, että IFC-kääntö on toteutettu oikein itse mallinnustavan ja mallin tietosisällön lisäksi 108. Tämän vuoksi varsinkin arkkitehtimallin muunto eri mallinnusohjelmia käyttäen on ohjeistettava. Lemminkäisen organisaatiossa on liian vähän tietoa tate-mallista, jotta tiedettäisiin, onko tate-mallin IFC-käännössä otettava huomioon joitakin erikoisseikkoja. IFC-kääntöohjeet voidaan myös lisätä mallinnusohjeiden yhteyteen. 3.9. Yhdistelmämallin käyttö Haastatteluissa korostettiin, että yhdistelmämalli on todella havainnollinen keino tutkia, miten eri suunnittelualojen rakenneosat sijoittuvat ja risteilevät keskenään 109. Arkkitehti voi käyttää mallia hahmottamaan kohteen esteettisyyttä ja LVIS-suunnittelijat pystyvät selvittämään, kuinka toteutettavissa talotekniikan asennukset ovat. Yhdistelmämallin 108 Leppävuori, Mairinoja, elinkaarilaskelmakonsultointi. Haastattelu Espoo 14.2.2011 109 Vasara, Oravainen, Ollikainen, Lehikoinen, LVIS-suunnittelu. Haastattelu Kuopio 17.2.2011. 57 edut korostuvat suunnitelmien vaihtoehtotarkastelussa110. LVIS-suunnittelijat ovat casehankkeen aikana ryhtyneet käyttämään NavisWorks-yhdistelmämallia rinnakkaisella näytöllä MagiCAD-mallinnuksensa aikana, jolloin he voivat lähes reaaliajassa tutkia työstettävän mallin sovittumista muuhun suunnitteluun. Yhdistelmämalli voidaan tarkistaa joko visuaalisesti käymällä se tila tilalta läpi tai Solibri Model Checker-ohjelman säännöstöjä käyttäen. Myös SMC:n muutostenjäljitystoiminto on hyvä tarkastustyökalu. Yhdistelmämallin tarkastusta suunnitelmien laadunvarmistuksessa käsitellään tarkemmin seuraavassa luvussa 3.10. Tällä ohjelmalla saa myös helposti tehtyä presentaatioita suunnitteluongelmista111. Solibri Model Checkeriä voi käyttää mitta-, korko- ja sijaintitiedon ottamiseen mallista112. Varsinkin taloteknisten osien sijaintitietojen ottaminen yhdistelmämallista osoittautui hyödylliseksi kohteen toteutuksessa. Valitettavasti ilmaisessa Solibri Model Viewer -ohjelmassa ei ole kunnollista mittatyökalua. Lisäksi toivottiin, että Solibrin ohjelmistolla saisi otettua tasokuvia dwg-formaatissa mittamiestä varten. Yhdistelmämallia voi käyttää myös määrätiedon hankintaan kuten sen osamallejakin. On käyttäjäkohtaista, kumpi malli soveltuu paremmin määrätiedon hankintaan 113. Lisäksi talotekniikan osalta määrätieto ei pidä paikkaansa toisin kuin tate-mallissa. Yhdistelmämallissa voi myös linkittää mallin ulkopuolisia tiedostoja mallin osiin Solibri Model Checker-ohjelmaa käyttäen114. Tätä voi käyttää hyväksi kohteen tietojen järjestämisessä. Etuna on se, että linkitetty tietosisältö ei tee yhdistelmämallista raskaampaa. 110 Liukkonen, Jari. Tate-valvoja. Haastattelu Helsinki 8.2.2011 111 Niemi, Harri, työmaainsinööri. Haastattelu Kuopio 18.2.2011 112 Kakkinen, Karhunen, Ronkainen, LVIS-urakointi. Haastattelu Kuopio 17.2.2011 113 Koponen, Mikko, työmaainsinööri. Haastattelu Kuopio 16.2.2011 114 Partanen, Matti, tietomalliasiantuntija. Haastattelu Helsinki 3.2.2011 58 Kuva 8. Martti Ahtisaaren koulun Solibri Model Checker –yhdistelmämalli. Yhdistelmämallia voi käyttää osamallien välisten risteilyjen visuaaliseen hahmottamiseen. Risteilyjä tarkastaessa tulee malli käydä läpi sekä alakatot näkyvissä että alakatot piilotettuina. (Suunnittelutilanne 14.4.2011) Case-hankkeessa käytetyn Solibri Model Checker-ohjelman päätoiminnot115: • Mallien yhdistäminen • Visualisointi ja mallissa navigointi • Säännöstöjen luominen ja mallin tarkastaminen säännöstöjä käyttäen • Mallin virheiden läpi käynti ja raportointi • Informaation talteenotto eli esimerkiksi määräluettelot • Presentaatiot eli esitykset ja kuvakaappaukset Palveluntuottajaorganisaatio pyrkii rohkaisemaan kaikkia case-hankkeen suunnittelussa ja toteutuksessa mukana olevia osapuolia hankkimaan joko Solibri Model Checker – ohjelmiston tai vähintään ilmaisen Solibri Model Viewer -ohjelman. Hankkeen myöhemmissä vaiheissa joku toinen yhdistelmämalliohjelmisto saattaa korvata näiden käytön. 115 Solibri Model Checker –koulutusmateriaali, Solibri Inc. 2010 59 3.10. Mallien laadunvarmistus Case-hankkeen mallinkäytön suurimpia ongelmia olivat mallissa esiintyneet virheet ja puutteet116. Vaikka suunnittelutoimistoilla on hankkeessa käytössään hyvä mallinnusosaaminen, puutteita löytyi varsinkin yhteensovituksen ja tiedonsiirron ongelmien sekä tarkastamisen laiminlyönnin vuoksi. Perimmäisenä syynä mallien puutteellisuudelle oli suunnitteluvaiheen kiire, joka johti suunnitelmamuutoksiin. Muutoksiin reagoiminen muilla suunnittelualoilla oli ajoittain hankalaa 117. Mallien puutteellisuuden seurauksena niistä ei saanut täysimittaista hyötyä kohteen toteutuksessa. Esimerkiksi arkkitehtimallissa muutettiin vielä myöhäisessä vaiheessa alakattojen korkoja ja talotekniikan tilavarauksia useaan kertaan. Tämän seurauksena myös tate-mallia jouduttiin revisoimaan. Päätelaitteiden ja haarakanavien korkeusaseman muuttaminen MagiCAD-mallinnusohjelmassa on hyvin työlästä ohjelman teknisen käyttöliittymän joustamattomuuden vuoksi. Suunnittelun kiireellisyyden vuoksi tate-suunnittelussa jouduttiin oikaisemaan, jolloin malliin syntyi virheitä. Pienempiä muutoksia ei edes tuotu tate-malliin. Tämä aiheutti ongelmia varsinkin, kun seurauksena rakennemallin reikätiedot eivät pysyneet ajan tasalla118. Toinen virheitä aiheuttanut seikka suunnittelupäivitysten yhteydessä oli mallin ja paperipiirustusten julkaiseminen eriaikaisesti. Tällöin taso- ja leikkauskuvien sekä mallin kesken muodostui ristiriitoja. Välillä kävi niin, että esimerkiksi LVIS-suunnittelussa jouduttiin mallintamaan arkkitehdin tasopiirustusten pohjalta arkkitehtimallin sijaan. Case-hankkeen tate-mallissa ei otettu huomioon myöskään talotekniikan putkien, kanavien ja laitteiden sekä niiden eristeiden ja kannakointien vaatimia asennusvaroja ja –järjestystä119. Lisäksi putket kääntyivät mallissa siten, ettei asennuksia voitu toteuttaa täysin mallin mukaisesti. Haastatteluissa syntyi keskustelua kuitenkin siitä, kuinka tarkasti tate-mallinnus on tarkoituksenmukaista toteuttaa. Todettiin, että esimerkiksi käyttövesijohdot on kuitenkin parasta sovittaa työmaalla sen sijaan, että ne mallinnettaisiin tarkasti. 116 Varstala, Matti, projektipäällikkö. Haastattelu Helsinki 10.2.2011 117 Vasara, Oravainen, Ollikainen, Lehikoinen, LVIS-suunnittelu. Haastattelu Kuopio 17.2.2011 118 Niemi, Harri, työmaainsinööri. Haastattelu Kuopio 18.2.2011 119 Liukkonen, Jari. Tate-valvoja. Haastattelu Helsinki 8.2.2011 60 Kuva 9. Esimerkkejä Rajalan koulun mallin puutteista. Talotekniikan reikiä ei ole siirretty malliin. (Solibri Model Checker –malli, suunnittelutilanne 14.4.) Suunnitelmamuutoksista huolimatta kohteiden malleista otetut määräluettelot pitivät riittävissä määrin paikkansa ja niitä pystyi käyttämään hankinnoissa ja tuotannonohjauksessa120. Tavoite on se, että tilaajan ja työmaaorganisaation on voitava luottaa määrätiedon oikeellisuuteen ilman erillistä tarkistamista121. Olennaisinta työmaan kannalta on, että elementtiluettelot pitävät paikkansa. Yleinen määrätiedon ongelma on päällekkäiset rakennusosat ja rakenneosien puutteelliset tyyppitiedot. Määräluetteloiden paikkansapitävyys on myös vastuukysymys 122. Suunnittelutoimistot eivät mielellään ota itse määräluetteloita mallista, koska silloin vastuu luetteloiden oikeellisuudesta kuuluu niille. Toisaalta ne kieltäytyvät ottamasta vastuuta, mikäli mallista muutoin otetussa määräluettelossa on määrävirheitä. Hankkeen alussa on tärkeää tehdä selväksi, että mallia tullaan käyttämään tähän tarkoitukseen. Määrälaskentaa käsitellään tarkemmin luvussa 3.12. 120 Koponen, Mikko, työmaainsinööri. Haastattelu Kuopio 16.2.2011 121 Virit, Artur, tietomalliasiantuntija. Haastattelu Helsinki 8.2.2011 122 Perko, Räihä, arkkitehtisuunnittelu. Haastattelu Helsinki 11.2.2011 61 Case-hankkeessa käytössä ollut Tekla Structures –ohjelman synkronointitoiminnon käyttö on haastattelujen mukaan aiheuttanut muissa hankkeissa ongelmia, sillä sen kautta on siirtynyt suunnittelutoimistolta muille osapuolille vanhentunutta suunnittelutietoa123. Case-hankkeessa synkronointityökalun ongelmat ovat kuitenkin johtuneet palomuureista ja mallinnusohjelman päivityksestä uuteen versioon. Suurin osa mainituista ongelmista olisi voitu välttää, jos sekä suunnittelijat että urakoitsijan edustajat olisivat käyneet mallit hyvissä ajoin etukäteen läpi. Yhdistelmämalli on tähän tarkoitukseen erinomainen työkalu. Case-hankkeessa on sovittu, että Lemminkäisen edustajan yhdistettyä mallin pääsuunnittelija tarkastaa sen. Tämä on toteutunut siten, että pääsuunnittelija on käynyt yhdistelmämallin visuaalisesti läpi. Tästä käytännöstä huolimatta merkittävä määrä virheitä on jäänyt malliin tarkastuksen jälkeen. Ennen mallin yhdistämistä on kuitenkin varmistettava joitakin mallinnustapaan ja IFCkääntöön liittyviä seikkoja, jotta osamallit edes voidaan kunnolla yhdistää. Mallin laadunvarmistuksen kannalta on oleellista määrittää mallin käyttötarkoituksen edellyttämä laatutaso. Laadunvarmistuksen tavoitteeksi tulisi asettaa, että toteutusvaiheen alkaessa malli olisi täysin virheetön asetettujen laatutasojen ja toleranssien mukaisesti. Haastatteluissa todettiin, että toteutusvaiheen muutosten yhteydessä joudutaan joka tapauksessa tekemään kompromisseja, mutta ne tuottavat paljon vähemmän ongelmia, jos malli vastaa muilta osin todellista toteutusta. Helpoin ja yksinkertaisin tapa tarkastaa malli on visuaalinen tarkastus, jonka voi jokainen mallia käyttävä osapuoli tehdä mallinkatseluohjelmaa käyttäen. Varsinkin kohteen esteettisyyttä häiritsevät kohdat havaitaan helposti mallista. Kohteen malli navigoidaan tila kerrallaan läpi joko kävellen tai lentäen. Visuaalinen tarkastus voidaan suorittaa koko kohteesta tai osittain esimerkiksi lohko kerrallaan. Tarkastuskierros on syytä tehdä sekä alakatot näkyvillä että alakatot piilotettuina, jolloin nähdään talotekniikan risteily sekä sijoittuminen alakaton suhteen. Visuaalisen tarkastuksen huono puoli on se, että se vie paljon aikaa isoissa kohteissa. Lisäksi mallia käytäessä useaan kertaan läpi saattaa tulla sokeaksi virheille. Visuaalinen tarkastus edellyttää vakaata järjestelmällisyyttä. Haastattelujen mukaan eri mallinnusohjelmissa on sisäisiä tarkastustyökaluja. Casehankkeessa ark-mallin tuottamiseen käytetyssä ArchiCAD-ohjelmassa on Double Chec123 Pehkonen, Turunen, rakennesuunnittelu. Haastattelu Kuopio 18.2.2011 62 ker –lisäosa, jolla voi tarkistaa, onko mallissa päällekkäisiä rakennusosia. Tätä työkalua ei ole case-hankkeessa kokeiltu. Vastaavasti rakennemallissa käytetyssä Tekla Structures –ohjelmassa on vakiotoimintona Clash Checker –työkalu, jolla voi tarkistaa rakenteiden törmäilyt, mitä ei myöskään ole case-hankkeen kohteissa käytetty. Tatemallinnuksen MagiCAD-ohjelmassa on myös yksinkertainen risteilytarkastustyökalu, jota käytettäessä voi erikseen määrittää hyväksyttävät toleranssit. Ohjelmien sisäiset tarkastustyökalut vaativat jonkin verran perehtymistä ja osaamista, mutta haastatteluissa ei osattu kommentoida niiden tehokkuutta tarkemmin. Yleisesti todettiin, että rakenneosien törmäilyt ark- tai rak-osamallien sisällä ovat vähäinen ongelma mallin laadunvarmistuksessa, mutta osamallit eivät ole keskenään yhteensopivia. Case-hankkeen tietomalliasiantuntijat suosittelivat Solibri Model Checker –ohjelman automaattista tarkastustyökalua mallin laadunvarmistukseen. SMC:n tarkastustyökalu perustuu säännöstöjen käyttämiseen124. Säännöstöt koostuvat useasta säännöstä, joiden toteutumista kohteen rakenneosissa testataan. Sääntö voi esimerkiksi testata pystyvätkö kaikki ovet avautumaan 90 astetta. Säännössä määritellään myös ristiriidan vakavuus. Ohjelma muodostaa raportin kaikista kohdista, jotka eivät läpäisseet säännöstössä määriteltyjä ehtoja. Käyttäjä voi käydä listan läpi ja kuitata virheen käsitellyksi. Tällöin tilanteesta riippuen käyttäjä voi mahdollisesti korjata virheen osamallissa tai lähettää suunnittelijoille tiedoksi esimerkiksi ohjelman presentation-työkalua käyttämällä. Solibri Model Checker –ohjelma on palveluntuottajaorganisaatiossa otettu käyttöön vasta case-hankkeen aikana ja mallin tarkastamista säännöstöjen avulla on vasta kokeiltu. Automaattista tarkastustyökalua ovat case-hankkeessa omalta osaltaan kokeilleet Lemminkäisen tietomalliasiantuntijat ja työmaainsinöörit sekä suunnittelutoimiston LVI-mallintaja. Case-hankkeen tulevissa kohteissa tietomalliasiantuntija Artur Virit tekee yhdistelmämallista puutelistat säännöstöjä käyttäen. Ongelmaksi on osoittautunut se, että ohjelman mukana tulleita säännöstöjä käyttämällä kohteiden yhdistelmämallien virheraporteista on tullut kymmeniä sivuja pitkiä. Tällöin raporttiin hukkuvat sekä pienet että isot asiat. Sen läpikäyminen vaatii valtavasti aikaa. Jos on sovittu, että mallista tehdään epätarkka, ei sitä voi säännöstöjä käyttäen edes tarkastaa. Myös säännöstöjen järjestelmällinen käyttö vaatii koulutusta ja kurinalaisuutta. 124 Solibri Model Checker –koulutusmateriaali, Solibri Inc. 2010 63 Konkreettiseksi laadunvarmistuksen menetelmäksi on ehdotettu yhdistelmämallipalaveria, joita on käytetty muissa hankkeissa. Tarkoitus on, että jokainen osapuoli käy mallinsa etukäteen tahollaan läpi. Mallin yhteensovituksesta vastaava tekee yhdistelmämallin tarkastuksen visuaalisesti tai mieluummin säännöstöjä käyttäen ja kokoaa listan olennaisimmista suunnitteluvirheistä. Yhdistelmämallipalaverissa käydään mallin puutteet läpi yhdessä. Jos kohde on pieni, voidaan se käydä yhdessä visuaalisesti kokonaan läpi kävelemällä mallissa. Ihanteellista olisi, jos rakennus- ja taloteknisten urakoitsijoiden asennuksesta vastaavat henkilöt pääsisivät osallistumaan yhteiseen kokoukseen, jolloin kokouksessa saataisiin myös toteutettavuuden näkökulma125. Tärkeää on, että kaikilla kokoukseen osallistuvilla on edes ilmainen mallinkatseluohjelma käytössään. Yhdistelmämallipalavereita tulisi järjestää ainakin kerran suunnitteluvaiheen aikana, mutta mieluummin useampia. Yhdistelmämallikokous otetaan käyttöön case-hankkeen tulevissa kohteissa. Tavoitteena on tuoda järjestelmällisyyttä laadunvarmistusmenetelmiin, koska käytännössä on todettu, että osapuolten omat laadunvarmistusprosessit ovat olleet puutteellisia. Haastatteluissa korostettiin kuitenkin, että muiden osapuolten suorittama yhdistelmämallin tarkastus ei vähentäisi suunnittelijan vastuuta virheistään. Kuva 10. IV-konehuone Martti Ahtisaaren koulun mallista. Mallia tarkastaessa on tärkeää saada sekä suunnittelijoiden että urakoitsijoiden näkemys mallin toteutettavuudesta varsinkin ahtaissa tiloissa kuten IV-konehuoneessa. (Solibri Model Checker –malli, suunnittelutilanne 14.4.) 125 Kakkinen, Karhunen, Ronkainen, LVIS-urakointi. Haastattelu Kuopio 17.2.2011 64 Tutkimuksessa käsiteltiin myös mallin laadunvarmistusta asenneongelmana. Kiireiset suunnittelijat eivät käytä resurssejaan työnsä tarkastamiseen, vaikka sen seurauksena kaikille osapuolille koituu lisää työtä ja taloudellista vahinkoa. Tämä ongelma toistuu myös muiden osapuolten laadunvarmistuksen osalta. Hankkeen eri osapuolet kuvattiin haastattelussa laadunvarmistustasoina suunnittelijoista asentajiin, jotka seulovat suunnitelmien laatuvirheet. Kuitenkin tämän seulan läpi pääsee isojakin virheitä. Nämä pystyttäisiin välttämään järjestelmällisillä laadunvarmistusmenetelmillä. Kysymys on asenteesta ja siitä toteuttavatko osapuolet laadunvarmistustoimenpiteensä, jos niitä ei erikseen valvo. Yhdistelmämalli on haastattelujen mukaan nähtävä enemmän työkaluna oman ylimääräisen työn ja virheiden vähentämiseen kuin ylimääräisenä työvaiheena. 3.11. Mallien työmaakäyttö Tietomalleja on case-hankkeessa suunnittelun lisäksi käytetty työmaalla tuotannonohjauksessa mm. määrälaskentaan ja aikataulunhallintaan 126. Mallien työmaakäyttö edellyttää työmaatoimihenkilöiden riittävää koulutusta ja jatkuvan tietoteknisen tuen tarjoamista127. Työmaalla on oltava riittävän tehokkaat tietokoneet, joihin on asennettu vähintään mallienkatseluohjelmisto. Case-hankkeen alussa oli 32-bittiset tietokonejärjestelmät, mutta ne päivitettiin mallien raskauden vuoksi 64-bittisiin. Lisäksi käytössä on oltava ark-, rak- tai yhdistelmämalli IFC- tai natiivimuodossa. Mallin on oltava mallinnettu työmaakäytön edellytysten mukaisesti. Yksinkertaisin tapa käyttää mallia on katsella sitä. Kolmiulotteinen tietomalli on kätevä havainnollistamaan kohteen ja sen suunnitelmat. Samalla työmaatoimihenkilöt voivat tarkastaa suunnitelmat mallia tutkimalla. Mallin tutkiminen edellyttää vain mallia IFCformaatissa ja ilmaista katseluohjelmaa kuten esimeriksi Solibri Model Viewer, jota käytettiin case-hankkeessa. Havainnollistamisen hyöty korostuu yhdistelmämallia käytettäessä. Case-hankkeen kohteissa työmaainsinöörit näyttivät mallista aliurakoitsijoiden projektinvetäjille sekä asentajille suunnitteluratkaisuja ja niiden asennusjärjestystä. Jos mallista halutaan tehdä presentaatioita, on käytössä oltava Solibri Model Checkerohjelmisto. Kuvakaappauksia voi tarvittaessa ottaa myös Windowsin Print Screen –toiminnolla. 126 Niemi, Harri, työmaainsinööri. Haastattelu Kuopio 18.2.2011 127 Virit, Artur, tietomalliasiantuntija. Haastattelu Helsinki 8.2.2011 65 Mallista voi ottaa myös mitta-, korko- ja sijaintitietoa. Tämä auttaa varsinkin taloteknisissä asennuksissa, kun voidaan hahmottaa putkien ja kanavien etäisyys muista rakenneosista. Tämä edellyttää sitä, että tate-mallissa on riittävästi otettu huomioon asennusvarat ja –järjestys. Useimmissa mallinnusohjelmistoissa on mittatyökalu. Työmailta toivottiin, että myös niiden ilmaisversioissa olisi toimivia mittatyökaluja. Case-hankkeen kohteissa määrätiedon ottamisesta mallista on ollut suuri apu tuotannonohjaukseen ja hankintoihin. Tehokkaan mallin työmaakäytön edellytyksenä on se, että mallista otettuihin määriin on pystyttävä luottamaan ilman erillisiä tarkastuksia. Martti Ahtisaaren koulun ja Puijonsarven koulun työmaiden mittamies on osoittanut kiinnostusta mallien käyttöön, mutta hänen käyttöään varten ei ole ollut sopivaa ohjelmistoa128. Tulevaisuudessa tämä saatetaan ratkaista esimerkiksi Teklan uudella BIMSight-ohjelmalla129. Lisäksi yhdistelmämallista tai muistakaan mallinkäyttöohjelmien urakoitsijaversioista ei saa tulostettua taso- ja leikkauskuvia dwg-tiedostomuodossa mittamiehen tai muiden osapuolten käyttöön. Tämä on luonnollisesti osapuolten välinen vastuukysymys. Mallinnusohjelmia voi helposti käyttää 3D-työmaasuunnitelman tuottamiseen, mutta Martti Ahtisaaren koulun ja Puijonsarven koulun työmailla näin ei ole tehty. Työmaasuunnitelman tuottamista varten on ArchiCAD- ja Tekla Structures –ohjelmissa objektikirjastot, jotka sisältävät mm. torninosturit, varastokontit, aidat ja työmaakopit 130. Tutustuttuaan mallinnusohjelmiin on case-hankkeen Rajalan koulun kohteeseen siirtyvä työmaainsinööri Harri Niemi todennut, että hän aikoo käyttää ArchiCAD-ohjelmaa kohteen työmaasuunnitelman mallintamiseen. 3D-työmaasuunnitelman edut korostuvat logistisesti ahtaissa ja runkoasennukseltaan hankalissa kohteissa. Työmaainsinöörit totesivat, että mallia pitää myös käyttää enemmän hyväksi työturvallisuussuunnittelussa. Työmaasuunnitelman luominen malliin edellyttää tontin mallia. 128 Koponen, Mikko, työmaainsinööri. Haastattelu Kuopio 16.2.2011 129 Partanen, Matti, tietomalliasiantuntija. Haastattelu Helsinki 3.2.2011 130 Pehkonen, Turunen, rakennesuunnittelu. Haastattelu Kuopio 18.2.2011 66 Kuva 11. Puijonlaakson päiväkodin mallissa on mukana laaja tontin malli. Maastoa sisältävä tontin malli on edellytys työmaasuunnitelman 3D-mallintamiselle. (ArchiCAD –arkkitehtimalli, suunnittelutilanne 14.4.2011) Case-hankkeessa Tekla Structures -rakennemalli toimi 4D-mallina, jota käytettiin runkovaiheen aikataulunhallinnassa. 4D-mallin hyöty korostuu kiireellisessä runkovaiheessa, jossa elementtisuunnittelu tapahtuu osittain limittäin elementtien valmistuksen kanssa. Lemminkäisen tietomalliasiantuntija Matti Partanen lohkotti mallin Teklan Model Organizer –työkalua käyttäen ja lisäsi betonielementeille päivämäärätietoa Task Manager –työkalulla. Malliin laadittiin suunnittelujärjestys, valmistusaikataulu ja asennusajankohdat. Työmaainsinöörit tulostivat elementtien asennusajankohdat mallista taulukkoon ja lähettivät tiedot elementtitehtaalle. Vastaavasti elementtitehdas lähetti takaisin päin palautetta työmaata ja suunnittelijoita varten valmistusajankohdista, jotka työmaainsinöörit tai Matti Partanen lisäsivät malliin. Vaikka päivämäärätietoa päivitettiin ristiin, ei ongelmia syntynyt, koska lisätyt tiedot eivät olleet ristiriidassa. Tietoa pystyisi käytännössä lisäämään malliin suoraan excel-taulukosta, jos se on oikeassa muodossa. Työmaainsinöörit täydensivät 4D-mallia toteutuneilla asennusajankohdilla. Aikataulutieto siirtyi rakennesuunnittelutoimistolle Tekla Structures –synkronointityökalua käyttäen. Tällöin aikataulutieto myös säilyi mallissa rakennesuunnittelijan päivittäessä mallia. Synkronointityökalu lakkasi toimimasta case-hankkeen kohteiden runkovaiheiden kesken. Tällä hetkellä on epäselvää, kuinka on päivitysten suhteen meneteltävä, jotta aikataulunhallintaa voidaan suorittaa malleja käyttäen. Mallien päivittyessä aikataulu- 67 tiedon on säilyttävä. Toisaalta vanhentunutta mallia ei välttämättä kannata käyttää runkovaiheen aikataulun pohjana. Tietomallien hyödyt runkoasennuksen ohjauksen apuna korostuvat kohteissa, joissa on monimutkainen runko, sillä yksinkertaisissa kohteissa ei ole kovin montaa väärää tapaa koota runko131. Kuva 12. Teklan ohjelmistolla voidaan rakennemallia täydentää aikataulutiedolla. Kuvan mukaan sinisellä merkityt Puijonsarven koulun rakenneosat on asennettu aikataulun mukaisesti. Punaisella merkityt ovat aikataulusta jäljessä. Tietomalliasiantuntijat kokeilevat muissa hankkeissa parhaillaan Vico Office –ohjelman betaversiota, jota voi käyttää mm. määrä- ja aikataulutiedon hallintaan. Ohjelmalla voi muodostaa suoraan määräluetteloita ja menekkejä käyttäen aikataulutehtävät ja niiden kestot Vico Control –ohjelmaan. Ohjelmaan pystytään siirtämään määrät suoraan mallista TCM Pro –ohjelmaa käyttäen. Vico Office ei toimi vielä täydellisesti ja se sisältää teknisiä puutteita. Ohjelmalla on todettu olevan kuitenkin suuri potentiaali varsinkin tuotannonohjauksessa. Syksyllä 2011 Lemminkäisen tarkoituksena on tutustua myös TCM Planner –aikataulunhallintaohjelmistoon, jota Tocoman Oy ja PlanMan Oy kehittävät tällä hetkellä 3.12. Määrälaskenta mallia käyttäen Malleja on case-hankkeessa käytetty sekä tilapohjaiseen että rakennusosapohjaiseen määrälaskentaan. Tarkoista arkkitehti- ja rakennemalleista on toteutusvaiheessa voitu 131 Varstala, Matti, projektipäällikkö. Haastattelu Helsinki 10.2.2011 68 ottaa ulos lähes kaikkien rakennusosien määrät. Myös yhdistelmämallia voi käyttää määrätiedon hallintaan. Määrätiedossa ei ole muutamia poikkeuksia lukuun ottamatta ollut kovin pahoja virheitä 132. Esimerkiksi rakennemallin raudoitemäärät olivat todelliseen määrään verrattuna kolminkertaiset133. Syytä tähän ei tiedetä. Tietomalleista löytyneiden virheiden ja mallinkäyttöprosessien jalostamattomuuden vuoksi case-hankkeen kohteissa on kuitenkin jouduttu määriä laskemaan myös käsin, jotta voidaan vertailla mallista otettujen määrien oikeellisuutta. Määrät laskettiin hyvin pitkälle käsin jo tarjousvaiheessa134. Haastatteluissa tehtiin selväksi, että malliin on pystyttävä määrätiedon osalta luottamaan varsinkin toteutusvaiheessa ilman erillistä työmaatoimihenkilöiden suorittamaa tarkastusta. Määrien ottaminen mallista on vastuukysymys. Suunnittelijat harvoin suostuvat vastaamaan mallista otetusta virheellisestä määrätiedosta135. Tärkeää on, että hankkeen suunnittelusopimuksiin kirjataan, jos mallia aiotaan käyttää määrätiedon hankintaan. Case-hankkeessa määrälaskentaan on käytetty ark-, rak- ja yhdistelmämalleja. Palveluntuottajaorganisaation toimihenkilöt ovat suosineet natiivimalleja, joissa on laajempi tietosisältö. Arkkitehtimallia on käytetty seinä- lattia- ja kattorakenteiden sekä niiden pintamateriaalien pinta-alojen laskentaan. Lisäksi ark-mallista on arkkitehti tulostanut ikkuna- ja oviluettelot. Näiden lisäksi arkkitehtitoimisto tuotti mallia käyttäen julkisivulevyistä luettelot tuotantoa varten. Rakennemallista on otettu elementtien sekä paikallavalukohteiden betonointi- ja raudoitemääriä. Lisäksi tarjousvaiheessa elinkaarikonsultit pystyisivät ottamaan elinkaarilaskelmiensa pohjaksi tarvitsemiaan määriä mallista, mutta tätä ei ole tehty case-hankkeessa 136. Myös tarkemmassa tarjouslaskennassa voisi mallista ottaa määriä, mikäli riittävän tarkkatasoinen malli olisi käytössä. Tarkka mallinnus tarjousvaiheessa on kuitenkin harvoin taloudellisesti perusteltua. Tate-tietomallistakin saa määrätietoa, mutta se ei siirry kunnolla IFC-muodossa Solibri Model Checker- yhdistelmämalliin137. MagiCAD-ohjelmaa ei ole käytetty työmaalla 132 Koponen, Mikko, työmaainsinööri. Haastattelu Kuopio 16.2.2011 133 Niemi, Harri, työmaainsinööri. Haastattelu Kuopio 18.2.2011 134 Virit, Artur, tietomalliasiantuntija. Haastattelu Helsinki 8.2.2011 135 Perko, Räihä, arkkitehtisuunnittelu. Haastattelu Helsinki 11.2.2011 136 Leppävuori, Mairinoja, elinkaarilaskelmakonsultointi. Haastattelu Espoo 14.2.2011 137 Vasara, Oravainen, Ollikainen, Lehikoinen, LVIS-suunnittelu. Haastattelu Kuopio 17.2.2011 69 määrälaskentaan. Tate-suunnittelijat kykenevät hakemaan tate-natiivimallista määrätietoa. Tekla Structures –ohjelma pystyy ottamaan kappalemääriä IFC-referenssimalleista, jotka on tehty MagiCAD:llä tai muilla ohjelmilla, mutta edellytyksenä on, että alkuperäisen mallin objektien attribuuttitietojen määritys ja IFC-kääntö on tehty onnistuneesti. Ark-mallin määrätiedon virheitä aiheuttaa se, että malli sisältää päällekkäisiä osia tai vaihtoehtotarkastelun yhteydessä piilotetut rakenneosat jäävät huomaamatta. Suunnittelijoilla ei myöskään usein ole vastaavaa kokemukseen perustuvaa kriittistä arviointikykyä määrien suhteen kuten rakennusliikkeen laskijoilla, jolloin suunnittelijoiden on hankala huomata virheitä määräluettelosta. Case-hankkeessa määräluetteloiden hallinta vaikeutui siksi, että rakenneosien tyyppien koodauksessa oli käytetty epäyhtenäistä logiikkaa. Tämän takia työmaainsinöörit joutuivat varmistamaan, mistä rakenneosasta oli kysymys. Koodien tulisi noudattaa yhtä yhtenäistä logiikkaa. Case-hankkeen työmaainsinöörit toivoivat haastatteluissa, että arkkitehtimallin rakenneosien tietoihin olisi jo etukäteen määritetty niiden lohkosijainti. Tämä yksinkertaistaisi määrälaskentaa huomattavasti, sillä nykyisten mallien tapauksessa joutuvat työmaainsinöörit itse merkitsemään malleihin tai määräluetteloihin rakenneosien lohkosijainnin. Määrienhallinnan ongelmaksi on osoittautunut se, että malleja päivitettäessä työmaatoimihenkilöiden malliin lisäämä tieto häviää. Mallin työmaakäyttäjät ovat joko joutuneet laatimaan määräluettelot uudelleen, tuomaan määräluettelot ja niiden laskentalogiikan uuteen malliin tai luottamaan vanhoihin määräluetteloihin, jos muutokset määrien kannalta ovat olleet olemattomia. Tätä ongelmaa on pyritty korjaamaan synkronointi- ja tiimityökalujen avulla, mutta huonoin tuloksin. Jos malleja ei päivitetä enää tuotantovaiheessa, ei tämä tuota ongelmaa. Lemminkäinen on muissa hankkeissaan käyttänyt mallinnusohjelmien määräluetteloinnin lisäksi TCM Pro –ohjelmaan, jonka pystyy linkittämään arkkitehtimalliin TCM iLink:in avulla138. Ohjelmalla voidaan mallin sisältämän yksinkertaisen määrä138 Partanen, Matti, tietomalliasiantuntija. Haastattelu Helsinki 3.2.2011 70 tiedon lisäksi laskea rakennusosiin liittyvät suoritteet, työajat ja kustannukset. iLink:n käyttö edellyttää, että ark-malli on mallinnettu tietyllä mallinnustavalla, johon Lemminkäisen mallinnusohjeet pohjautuvat139. Rakenneosat on koodattava oikealla tavalla, jotta määrälaskentatyökalu osaa luokitella ne. Esimerkiksi case-hankkeen ark-mallissa käytetty mallintamistapa, jossa rakenteet on mallinnettu rakennekerroksittain sen sijaan, että rakennetyyppi olisi määritetty rakenteen täytteenä, aiheuttaa automaattisisten määrälaskentatyökalujen kanssa ongelmia. 3.13. Synkronointi- ja tiimityötoiminnot Tietomallien yhteiskäyttö on mahdollista joko ArchiCAD:n tiimityöympäristön kautta, tai Tekla Structures –ohjelman synkronointitoiminnon kautta 140. Yhteiskäyttötoiminnot ovat perinteisesti olleet ainoastaan suunnittelutoimistojen sisäisessä käytössä, mutta myös projektin muilla osapuolilla on tarve tehdä malliin merkintöjä ja lisäyksiä, joiden tulee säilyä mallia päivitettäessä. Lisäksi tiimityökaluja käytettäessä mallin päivitys voi tapahtua lähes reaaliajassa. Tiimityökalut voisivatkin olla kätevä keino kommunikoida ongelmallisia suunnittelukohtia suunnittelijoille. ArchiCAD-mallinnusohjelmassa on ollut versiosta 13 lähtien käytettävissä tiimityöympäristö. Tätä toimintoa käyttäen voivat useat eri osapuolet avata verkkopalvelimelta saman mallin joko lähiverkon tai internetin kautta. Projektinvetäjä voi määrittää mallin käyttöoikeudet sekä osapuolet voivat varata mallin osia omaan käyttöönsä, jolloin muut eivät voi muokata niitä. Lisäksi mallia voi muokata yhteydettömässä tilassa, jolloin malli ladataan koneen kovalevylle ja sen voi myöhemmin synkronoida palvelimella olevan mallin kanssa. Tiimityöympäristössä on myös viestintämahdollisuus osapuolten kesken. Case-hankkeessa oli tarkoitus kokeilla ark-mallin yhteiskäyttöä suunnittelutoimiston ja rakennusliikkeen välillä ArchiCAD:n tiimityötoiminnon kautta. Palveluntuottajaorganisaation ja työmaiden toimihenkilöt olisivat voineet katsella mallin kehitystä reaaliajassa. Tiimiympäristössä voi nähdä, ketkä käyttävät mallia ja kommunikoida heidän kanssaan. Malliin voi myös lisätä kommentteja muiden näkyville. Lisäksi malliin tallennetut määräluettelot olisivat säilyneet. Lemminkäisen palomuurit estivät tiimityökalun käytön. Arkkitehtitoimiston ja sisustusarkkitehtitoimiston välisessä käytössä sekä niiden sisäisissä käytöissä tiimityökalu toimi, mutta yhteiskäyttö hidasti mallin 139 Salin, Janne, tietomalliasiantuntija. Haastattelu Helsinki 4.2.2011 140 Virit, Artur, tietomalliasiantuntija. Haastattelu Helsinki 8.2.2011 71 kanssa työskentelyä huomattavasti141. Työskentelyn hidastuessa menetetään yhteiskäyttötoiminnolla saavutettava nopean tiedonvaihdon hyöty. Haastatteluissa arveltiin, että projektin yhteisen tiimityömallin on hyvä olla eri kuin arkkitehtitoimiston sisäinen tiimityömalli, koska näin keskeneräiset suunnitelmat eivät pääse muille osapuolille, ja ulkopuoliset eivät pysty vahingoittamaan mallia142. Martti Ahtisaaren koulun ja Puijonsarven koulun kohteissa käytettiin osittain onnistuneesti Tekla Structures –rakennemallin synkronointia työmaan, Lemminkäisen pääkonttorin ja rakennesuunnittelutoimiston välillä. Synkronointia käytettäessä projektipankkiin päivitetty malli muutoksineen tuotiin edelliseen malliin. Tällöin mallissa säilyi siihen lisätty aikataulutieto. Synkronointi ei tapahdu automaattisesti, vaan päivitetty revisio on tuotava aina erikseen. Synkronointiominaisuuden toimintaan saaminen vaati Martti Ahtisaaren koulun kohteen alussa melko kauan143. Runkovaiheen aikana osa työmaan tuomasta tiedosta ei siirtynyt synkronointimalliin. Tämän uskotaan johtuneen työmaan VPN-yhteyden ja palomuurin ongelmista. Palomuuriongelma saatiin aina tapauskohtaisesti korjattua väliaikaisesti, mutta pysyvää ratkaisua ei ole löydetty. Lopulta Martti Ahtisaaren synkronointimalli meni kokonaan rikki rakennesuunnittelutoimiston vaihdettua Tekla Structures versiosta 16.0 versioon 16.1. Rakennesuunnittelijoiden mukaan Teklan synkronointitoimintoa käytettäessä malliin jää usein vanhentunutta tietoa eikä sitä sen takia kannata tällä hetkellä käyttää144. Lisäksi myös palvelimella ylläpidetty malli hidastaa työntekoa. Tekla on toimittanut keväällä 2011 Lemminkäisen käyttöön yksinkertaisen Site Data Exchange -ohjelman, jolla voidaan tuoda Model Organizer- tai Task Manager –työkaluilla määritettyä tietosisältöä tai muuta rakennusosien attribuuttitietoa vanhasta mallista päivitettyyn malliin. Tämän yksinkertaisen ohjelman on tarkoitus toimia tilapäisenä korvikkeena Tekla Structures:n synkronointityökalun ongelmien jatkuessa. Ohjelmaa on kokeiltu ja se toimi, mutta tällä hetkellä case-hankkeen uusissa kohteissa tai Lemminkäisen muissa kohteissa ei ole synkronoinnin tarvetta. Solibri Model Checker-ohjelmassa ei ole tiimityöympäristöä. Osapuolten kommunikointi yhdistelmämallin kautta parantaisi tiedonvaihdon mahdollisuuksia. 141 Perko, Räihä, arkkitehtisuunnittelu. Haastattelu Helsinki 11.2.2011 142 Niemi, Harri, työmaainsinööri. Haastattelu Kuopio 18.2.2011 143 Koponen, Mikko, työmaainsinööri. Haastattelu Kuopio 16.2.2011 144 Pehkonen, Turunen, rakennesuunnittelu. Haastattelu Kuopio 18.2.2011 72 Revit Architechture –ohjelman käyttäjille on julkaistu uusi kotimainen työkalu CadFaster Collaborate, jolla voi luoda Revit Architechture –mallista kevyen tiedoston. Tätä tiedostoa käyttäen voivat useat käyttäjät tutkia ja tehdä malliin merkintöjä verkon välityksellä ilman varsinaista mallinnusohjelmaa. Ohjelmalla on potentiaalia mallipohjaisen tiedonvälityksen nopeuttamiseksi ja yksinkertaistamiseksi. Ohjelman etuna on se, että myös kokemattomat mallinnusprosessin ulkopuoliset käyttäjät voivat tutkia mallia. Case-hankkessa ei tulla kuitenkaan käyttämään Revit Architechture –malleja eikä siten myöskään CadFaster Collaborate –ohjelmaa. 3.14. Toteumamalli ja ylläpitomallin edellytykset Case-hankkeessa palveluntuottajaorganisaatio pyrkii hyödyntämään ylläpitomallia 25 vuoden huoltovastuun aikana. Ylläpitomalli edellyttää hyvin pitkälti, että kohteesta laaditaan tuotantovaiheen aikana toteumamalli. Lisäksi tähän toteumamalliin tulee kerätä kaikki mahdollinen laitteiden tuotetieto145. Haastatteluissa huomautettiin, että huoltokirjassa tuotetietojen on oltava täysin oikein ja helposti saatavilla, joten tuotetiedon lisääminen malliin ei välttämättä kannata. Ylläpitomallia tulee käyttää nimenomaan yhdessä sähköisen huoltokirjan kanssa sen sijaan, että ne olisivat kaksi erillistä tietokantaa. Muuten ylläpitomallin hyöty jää kyseenalaiseksi. Palveluntuottajaorganisaatiolla ei ole vielä selvää näkemystä siitä, kuinka tämä järjestetään146. Ylläpitomallin ja sähköisen huoltokirjan välille on kehitettävä jonkinlainen linkitys. Kohteen toteumamallia pystyy joka tapauksessa käyttämään käyttö- ja ylläpitovaiheessa kohteen visualisointiin. Mallia voi käyttää kohteen muutos- tai korjaustöiden suunnittelun pohjana. Lisäksi mallin määrä- ja laajuustietoja voi edelleen tulostaa käyttäjän ja omistajan käyttöön. Haastattelututkimuksen mukaan tietomallien käytön mahdollisuudet toteumatiedon keräämisessä toteuma- tai ylläpitomallia varten ovat hyvin rajalliset. Case-hankkeen ensimmäiset kohteet ovat jo pitkällä ilman, että järjestelmällistä toteumamallintamisen prosessia on kehitetty. Arkkitehtisuunnitelmissa ei muutosten kirjaaminen juurikaan tuota ongelmia, sillä muutoksia ei yleensä tehdä ennen kuin muutetut suunnitelmat ovat saatavilla147. Vastaavasti rakennesuunnitelmien osalta mittamies ottaa asennuksista tar145 Vasara, Oravainen, Ollikainen, Lehikoinen, LVIS-suunnittelu. Haastattelu Kuopio 17.2.2011 146 Perko, Räihä, arkkitehtisuunnittelu. Haastattelu Helsinki 11.2.2011 147 Koponen, Mikko, työmaainsinööri. Haastattelu Kuopio 16.2.2011 73 kekuvat dwg-tiedostomuotoon ja lähettää ne rakennesuunnittelijalle 148. Rakennemallin osalta tärkeää on lopullisten reikätietojen mallintaminen. Yhtä mieltä oltiin kuitenkin siitä, että toteumatiedon päivitys tulee tehdä jatkuvana prosessina sen sijaan, että tiedot lisättäisiin malliin suurena kertaeränä luovutusvaiheessa. Onnistuneen toteumamallin osalta kriittisessä roolissa ovat taloteknisten asennusten poikkeamat, jotka on case-hankkeessa kirjattu tate-urakoitsijoiden punakynärevisioihin. Tärkeää on, että punakynärevisiot ovat sen urakoitsijan laatimia, kelle vastuu asennuksesta kuuluu. Punakynärevisiointi on kuitenkin hankalaa, sillä myös todelliset suunnitelmapiirustussarjojen revisioversiot elävät niiden rinnalla. Case-hankkeessa punakynärevisiot ovat kuitenkin olleet melko epätarkkoja ja urakoitsijan on tarvinnut kiertää suunnittelijan kanssa kohde erikseen läpi149. Joka tapauksessa urakoitsijan piirtäessä omat kuvansa tehdään kaksinkertainen työ, kun suunnittelijan on lisättävä tiedot vielä malliin150. Ensinnäkin on oltava selkeä näkemys siitä, mitkä muutokset kannattaa toteumamalliin ylipäänsä tuoda. Avainasemassa ovat muutokset, jotka vaikuttavat kohteen huoltamiseen kuten esimerkiksi huoltoyhteiden sijainnit. Pieniä, merkityksettömiä muutoksia ei kannata mallintaa. Tate-toteumamallia olisi hyvä käyttää myös verkostojen säätöarvojen seurantaan. Malliin syötettäisiin hankkeen edetessä suunnittellut ja toteutuneet arvot sekä verrattava niitä keskenään. Case-hankeessa tate-valvoja on perinteisesti tehnyt vastaavaa seurantaa taulukkolaskentaohjelman avulla. Punakynärevisiointi on lähes ainoa keino kerätä talotekniikan muutoksista toteumatietoa. Kuitenkin apukeinona voi lähettää suunnittelijalle vertailtavaksi yhdistelmämallista otettuja kuvakaappauksia asennuksista otettujen valokuvien rinnalle 151. Haastatteluissa puhuttiin myös tiimityöympäristön käyttämisestä toteumatiedon välittämiseen suunnittelijoille, mutta siihen suhtauduttiin tässä vaiheessa epäilevästi. Ainakaan uuden kohteen laserskannaus ei ole järkevää. Haastatteluista voidaan päätellä, että on laadittava selkeä ohje toteumamallin tuottamisesta ja toteumatiedon keräämisestä suunnittelijoita ja urakoitsijoita varten. 148 Pehkonen, Turunen, rakennesuunnittelu. Haastattelu Kuopio 18.2.2011 149 Liukkonen, Jari. Tate-valvoja. Haastattelu Helsinki 8.2.2011 150 Kakkinen, Karhunen, Ronkainen, LVIS-urakointi. Haastattelu Kuopio 17.2.2011 151 Niemi, Harri, työmaainsinööri. Haastattelu Kuopio 18.2.2011 74 3.15. Inventointimallin luominen ja käyttö Olemassa olevista kohteista tuotetuilla inventointimalleilla voi saavuttaa huomattavan hyödyn kohteen suunnittelussa. Mallia käyttämällä voidaan ratkaista, kuinka uudet rakenteet voidaan sovittaa vanhojen rakenteiden ehdoilla152. Malli on vähintään yhtä havainnollinen apukeino kuin uudisrakennuskohteessa. Ensinnäkin inventointimallista huomaa nopeasti, kuinka olemassa olevat piirustukset poikkeavat todellisesta rakennuksesta, kuten useassa peruskorjaushankkeessa on ollut153. Etenkin jos kohteiden aiemmat korjaustoimenpiteet on suoritettu useassa eri vaiheessa, on inventointimalli varsin kätevä keino hahmottaa kohteen ajankohtainen tila154. Jos inventointimalli on tuotettu piirustuksien pohjalta, huomataan, kuinka paljon malli poikkeaa todellisuudesta. Jos se on tuotettu skannaamalla, huomataan, kuinka paljon malli poikkeaa piirustuksista. Toivottiin, että inventointimallin saisi tarjousvaiheessa elinkaarihankkeen tilaajalta. Inventointimallista saa hankkeen alussa määrätietoa kustannus- ja elinkaarikustannuslaskennan lähtötiedoksi. Samoin inventointimallia voisi mahdollisesti käyttää simuloinneissa, jos malli saadaan siirtymään oikeassa muodossa155. Tämä tuskin onnistuu skannatulla mallilla. Tätä etua ei voi kuitenkaan kovin hyvin hyödyntää hankkeen tarjousvaiheessa, sillä inventointimallin tuottaminen varsinkin skannamalla käy melko kalliiksi. Toisaalta mitä varhaisemmassa vaiheessa voidaan mallista saada tarkkaa lähtötietoa, sitä paremmin voidaan suunnitteluratkaisun kustannuksiin vielä vaikuttaa. Arkkitehti tuotti case-hankkeen Rajalan koulun perussaneerauskohteesta inventointimallin karkealla tasolla vanhojen piirustusten pohjalta156. Ark-inventointimallin sallittiin poikkeavan vanhoista piirustuksista 3 cm toleranssilla. Toleransseja tarvitaan, sillä kohteen rakenteita purettaessa mitat muuttuvat esimerkiksi välipohjien taipumien muuttuessa. Kohteen talotekniikka uusitaan täysin, jolloin sitä ei ole järkevää tuoda inventointimalliin. Vaikka talotekniikka säilytettäisiinkin, jouduttaisiin sen mitoitus kuitenkin laskemaan MagiCAD-ohjelmalla. Sen sijaan inventointimalliin on tarkoitus lisätä rakennesuunnittelutietoja, koska kohteessa tullaan käyttämään olemassa olevien palkki- 152 Liukkonen, Jari. Tate-valvoja. Haastattelu Helsinki 8.2.2011 153 Partanen, Matti, tietomalliasiantuntija. Haastattelu Helsinki 3.2.2011 154 Leppävuori, Mairinoja, elinkaarilaskelmakonsultointi. Haastattelu Espoo 14.2.2011 155 Vasara, Oravainen, Ollikainen, Lehikoinen, LVIS-suunnittelu. Haastattelu Kuopio 17.2.2011 156 Perko, Räihä, arkkitehtisuunnittelu. Haastattelu Helsinki 11.2.2011 75 rakenteiden reikiä talotekniikan reittien toteutuksessa157. Muutenkin olemassa olevista rakenteista on otettava tarkemitat, jos niihin asennetaan liittyviä rakenteita158. Vanhojen piirustuksien lisäksi käytössä olevassa kohteessa suoritettiin koululomien aikana näkyvissä olevien rakenteiden ja tilojen mittaus laserkeilaamalla eli skannaamalla159. Skannaus osoittautui tässä kohteessa epäkäytännölliseksi ja kalliiksi ratkaisuksi. Lisäksi alakatto- ja muita rakenteita avattiin pistokokeina ympäri kohdetta, jotta voitiin selvittää kuvaten ja mitaten vanhojen piirustusten todenmukaisuus sekä talotekniikan ja rakenteiden reikien sijainteja. Kohteessa on järjestetty jo luonnossuunnitteluvaiheen aikana poikkeuksellisen monta kohdevierailua eri alojen suunnittelijoiden ja taloteknisen urakoitsijan kesken. Vierailuista on koitunut paljon hyötyä hankkeelle. Inventointimallia käyttämällä ja vierailuja suorittamalla on suunnittelijoille muodostunut jo käsitys talotekniikan toteutusperiaatteista luokkahuoneiden osalta. Käytävien osalta oli haastattelujen aikaan helmikuussa 2011 suunnittelu käynnissä. Inventointimallin perusteella päädyttiin mm. käyttämään suorakulmaisia IV-kanavia pyöreiden sijaan tilanpuutteen vuoksi. Lähtötietojen puutteiden vuoksi kohteen toteutuksessa joudutaan joka tapauksessa varautumaan yllätyksiin. Skannaus suoritetaan laitteiden mitatessa tilasta laserilla 2-ulotteisia leikkauksia sekä vaaka- että pystysuunnassa. Tiloista voidaan ottaa myös ns. pyörähdyskuva. Laite tuottaa tilan rakenteista pistepilven, jotka eivät sisällä muuta tietoa rakenteista kuin niiden geometrian. Pistepilvi on siirrettävä mallinnusohjelmaan, jolla määritetään, mitkä rakenteet ovat kyseessä, mistä materiaalista ne ovat tehty ja muu tarvittava tietosisältö. Kohteen todellinen geometria on suunnitelmien mallintamisen kannalta ongelmallinen, koska on työläämpää mallintaa uudet rakenteet vinojen rakenneosien mukaan. Suorakulmainen malli on helpommin käsiteltävissä. Siitä huolimatta mallin on kuitenkin oltava riittävän tarkka. Skannauksella voidaan arkkitehdin haastattelun mukaan saavuttaa parhaimmillaan 2,5-3 cm toleranssin tarkkuus. Skannaus inventointimallin tuottamisen keinona on hyvä, jos vanhat piirustukset poikkeavat todellisesta kohteesta huomattavasti tai varsinkin jos vanhoja piirustuksia ei ole ollenkaan. Tämän kaltaisessa tapauksessa piirustusten perusteella mallinnettu inventointimalli täytyy vielä korjata ennen kuin sitä voi käyttää muun suunnittelun pe157 Kakkinen, Karhunen, Ronkainen, LVIS-urakointi. Haastattelu Kuopio 17.2.2011 158 Pehkonen, Turunen, rakennesuunnittelu. Haastattelu Kuopio 18.2.2011. 159 Varstala, Matti, projektipäällikkö. Haastattelu Helsinki 10.2.2011. 76 rustana. Skannausta ei voida kuitenkaan suorittaa piilotettujen rakenteiden osalta ilman, että alakatto-, kotelo- ja muut rakenteet sekä talotekniikka puretaan tieltä. Talotekniikan putkien skannaus tuottaa myös ongelmia, koska ne saadaan skannattua vain tilan puolelta, jolloin ne piirtyvät puolilieriönä. Tämä ongelma korostuu käytössä olevassa kohteessa kuten Rajalan koulussa, jossa rakenteita ei voida purkaa ennen skannausta. 3.16. Tietomallien hyödyntäminen elinkaarilaskelmissa, tate- analyyseissä ja suunnitelmien vaihtoehtotarkastelussa Elinkaarihankemuodossa korostuvat rakennusten energia- ja kustannustehokkuus. Koska palveluntuottajaorganisaatiolla on case-hankkeen kohteissa energiankulutuksesta määrävastuu, tuotettiin kohteista tarjous- ja suunnitteluvaiheissa vaihtoehtotarkasteluja ja niihin pohjautuvia elinkaarilaskelmia160. Tähän suunnitelmien kustannustehokkuuden optimointiprosessiin osallistuivat pääasiassa suunnittelunohjausryhmä, arkkitehtitoimisto, LVIS-suunnittelutoimisto ja Pöyry-konsernin elinkaarilaskentakonsultit. Muissa vastaavissa hankkeissa elinkaarikonsultit ovat tehneet myös hiilidioksidikuormien laskentaa, jossa voi myös käyttää mallin tietoja hyväksi. Case-hankkeen tarjousvaiheessa oli käytössä vain alustava arkkitehdin tilamalli, josta lähinnä otettiin määrätietoja elinkaarilaskelmien pohjaksi. Case-hankkeessa ei tässä vaiheessa käytetty arkkitehtimallia energia-, olosuhde- tai muihin simulointeihin, mutta haastatteluihin osallistuneet konsultit ovat suorittaneet simulointeja muissa elinkaarihankkeiden tarjouskilpailuissa. Haastatteluissa todettiin, että ei välttämättä ole tarkoituksenmukaista optimoida malleja simulointeja käyttäen ellei kohteiden energiatehokkuus ja innovatiivisuus ole virallisia kilpailukriteerejä161. Elinkaarilaskentakonsultit eivät ole osallistuneet case-hankkeen myöhempiin vaiheisiin. Granlundin LVIS-suunnittelutoimisto on suorittanut case-hankkeen ensimmäisten kohteiden suunnitteluvaiheessa mallien avulla suunnitteluratkaisujen vaihtoehtotarkastelua kustannustehokkuuden kannalta kuten lähes kaikissa muissakin hankkeissaan. Vaihtoehtotarkastelut suoritetaan energiankulutusta ja sisäilmaston olosuhteita tarkkaillen. LVIS-suunnittelutoimisto teki myös vertailun ilmamääräiseen säätöön perustuvan ilmanvaihdon elinkaarikustannuksista koulukohteiden suunnittelussa. 160 Leppävuori, Mairinoja, elinkaarilaskelmakonsultointi. Haastattelu Espoo 14.2.2011 161 Vasara, Oravainen, Ollikainen, Lehikoinen, LVIS-suunnittelu. Haastattelu Kuopio 17.2.2011. 77 Energiankulutuslaskelmat tehdään koko kohteesta arvioiden kohteen energiankulutusta vuositasolla. Tämän laskelman lähtötiedot on helppo saada mallista. Lisäksi energiankulutuksen voi suoraan simuloida käyttäen lähtötietona tilamallia, jossa on määriteltynä todellinen geometria, ilmansuunnat, tilojen alat ja käyttötarkoitukset, rakennuksen tilavuus sekä keskeiset rakenteet ja ikkunat materiaalitietoineen. Lisäksi simuloinnin edellytyksenä on paikallinen lämmöntarveluku. Yleensä olosuhdetarkasteluilla tutkitaan, onko mahdollista saavuttaa jokin annettu vaatimus ja miten. Toinen lähtökohta on, että tutkitaan valmiiden vaihtoehtojen ominaisuuksia ja valitaan niistä edullisin. Esimerkiksi case-hankkeessa tutkittiin, voidaanko kohteen länsijulkisivulla sijaitsevan tilan lämpötila pitää kuumana kesäpäivänä sisäilmastoluokan raja-arvojen sisällä ilman jäähdytystä. Tarjousvaiheessa ei ole olennaista hienosäätäen minimoida suunnitteluratkaisun energiantarvetta tiloittain, vaan tutkia, voidaanko esimerkiksi kallis jäähdytysjärjestelmä jättää kokonaan pois. Energia- ja olosuhdesimuloinnit tuotettiin suunnittelutoimisto Granlundin tuottamalla Riuska-ohjelmalla. Riuska pystyy hyödyntämään arkkitehtimallia IFC-muodossa, mutta käytännössä ark-mallin tuonti on ollut äärimmäisen vaikeaa ja se on onnistunut vain harvoin. Suomessa on käytössä myös Ida-simulointiohjelma. Ark-malli tulee mallintaa oikealla tavalla tätä tarkoitusta varten. Edellytyksinä ovat ainakin, että tilojen seinät ja rakenteet liittyvät toisiinsa ja tila tunnistaa ympäröivät rakenteensa, eli tilojen on oltava näiden rakenteiden rajaama. Tämä onnistuu hyvin ArchiCAD:n Space Boundary –ominaisuudella, joka tunnistaa tilan rajat. Ongelma muodostuu esimerkiksi korkeita ja kaarevia seinä- ja ikkunarakenteita tai vinoja kattorakenteita käytettäessä. Joskus rakenteet jäävät yksinkertaisesti siirtymättä simulointiohjelmaan. Myös seinärakenteiden rakennetyypit on määritettävä oikein attribuuttitietoihin, jotta ne siirtyvät. Nämä voidaan kuitenkin lisätä simulointiohjelmalla myöhemminkin. Koska simulointiohjelman käyttäjät eivät voi itse muokata mallinnusohjelmillaan arkkitehtimallia suoraan, heidän on ollut helpompi tuottaa tilamallin yksinkertainen geometria itse MagiCad Room-ohjelman avulla, kuin käydä suunnittelutoimistojen välistä iterointia mallin hiomiseksi tuonnin onnistumiseksi. Haastattelujen mukaan on valmisteilla välikappaleena toimiva ohjelma, jolla simuloiva osapuoli voisi korjata mallin ennen kuin se tuodaan simulointiohjelmaan. MagiCad Room-ohjelmalla mallin tuonti 78 simulointiohjelmaan on toiminut lähes varmasti. Yksiselitteistä ohjetta ongelman ratkaisemiseksi ei ole pystytty laatimaan. Case-hankkeessa LVIS-suunnittelutoimisto suoritti myös valaistussimuloinnit, mutta ne tehtiin DiaLux-ohjelmalla, joka ei pysty hyödyntämään arkkitehtimallia. Valaisimien sijoittelua tosin tutkittiin arkkitehtimallissa valaistussuunnittelun yhteydessä 162. Yllämainittujen lisäksi voidaan mallia käyttää lähtötietona virtaus- eli CFDsimuloinneissa. Case-hankkeen kohteissa ei mallia tähän tosin ole hyödynnetty. 3.17. Muut tietomallimenetelmissä esiintyneet ongelmat Haastatteluissa ilmeni myös muutama erillinen tekninen seikka, joita ei voitu luokitella edellä oleviin kohtiin. Ensinnäkin mallinnusohjelmien laajennusten, korjausten ja lisäkirjastojen käyttö saattaa aiheuttaa yhteensopimattomuusongelmia eri osapuolten avatessa mallin163. Joko mallissa ei näy kaikki rakenneosat tai malli ei siirry ollenkaan IFCmuodossa164. Näiden käytöstä on pidettävä kirjaa ja tiedotettava muille osapuolille tietomalliselostuksessa tai muutoin. Case-hankkeessa käytettiin peruskirjastojen lisäksi kaluste- ja laitetoimittajien tuoteobjektikirjastoja165. Varsinkin mallinnusohjelmien päivittäminen uuteen versioon kesken hankkeen voi aiheuttaa huomattavia ongelmia. Ohjelmistojen päivittäminen on kuitenkin etenkin mallintajien kannalta tarpeellista 166. Ohjelmaversiot on päivitettävä vasta yhteisen harkinnan jälkeen. Lisäksi mallinnusohjelmista saattaa jostain syystä kadota tietoa. Esimerkiksi ArchiCAD:n luodut luettelot ovat saattaneet hävitä. Tämän takia kaikki olennainen tieto on hyvä tallentaa dwg- ja pdf-tiedostoihin ja arkistoida, jos se vain on mahdollista. Haastatteluista keskusteltiin myös siitä, että tietomallintamisen toimivien käytäntöjen käyttöönottoa hankkeissa rajoittaa mallien omaksumiseen vaikuttava asenteellinen muutosvastarinta167. Tämä koskee varsinkin muita kuin suunnittelutoimiston toimihenkilöitä, jotka käyttäisivät tietomalleja aputyökaluina. Mallin laiminlyömisen takia jäävät mallin ongelmat huomaamatta ja suunnitelmista poiketaan asennuksia toteutettaessa. 162 Liukkonen, Jari. Tate-valvoja. Haastattelu Helsinki 8.2.2011 163 Virit, Artur, tietomalliasiantuntija. Haastattelu Helsinki 8.2.2011 164 Salin, Janne, tietomalliasiantuntija. Haastattelu Helsinki 4.2.2011 165 Vasara, Oravainen, Ollikainen, Lehikoinen, LVIS-suunnittelu. Haastattelu Kuopio 17.2.2011 166 Perko, Räihä, arkkitehtisuunnittelu. Haastattelu Helsinki 11.2.2011 167 Varstala, Matti, projektipäällikkö. Haastattelu Helsinki 10.2.2011. 79 Tietomallien käytön yleistyminen on osapuolten asenteesta kiinni. Motivaatio-ongelman takia pitää hankkeissa varata riittävästi aikaa ja resursseja koulutuksiin, itsenäiseen perehtymiseen ja itse mallin käyttöön 168. Lisäksi tulee tarjota mallin käyttöä varten jatkuvaa tukea. Motivaation esteeksi koituvat varsinkin urakoitsijoiden liian hitaat tietokoneet, jotka eivät pysty avaamaan mallia sekä ohjelmalisenssien kalleus. Ongelmat voisi ratkaista ottamalla kaikki mallia käyttävät osapuolet mukaan jo tietomallinnusta käynnistettäessä sekä opettelemalla yhdessä ohjelmien ilmaisversioiden käyttöä169. 168 Niemi, Harri, työmaainsinööri. Haastattelu Kuopio 18.2.2011 169 Kakkinen, Karhunen, Ronkainen, LVIS-urakointi. Haastattelu Kuopio 17.2.2011 80 4. Tietomalliprosessin kehittäminen Tähän lukuun on kerätty käytäntöjä, jotka ovat case-tutkimuksessa osoittautuneet oleellisiksi hankkeen tietomallipohjaisen suunnittelun sekä tietomallien muun käytön kannalta. Nämä käytännöt täydentävät olemassa olevaa Lemminkäisen tietomalliprosessia. 4.1.1. Tietomallintamisen aloituskokous Hankkeissa pitää toteutusmuodosta riippumatta järjestää hankkeen rakennuttajakonsultin, projektinjohtokonsultin tai pääsuunnittelijan johdolla kohdekohtainen tietomallintamisen aloituskokous, jossa täsmennetään tietomallien käytön periaatteet. Aloituskokous on järjestettävä mahdollisimman pian tarjouskilpailun voiton ja suunnittelijoiden valinnan jälkeen. Mallinnuspäätös on tosin tehtävä jo tarjousvaiheessa, mutta silloin on liian aikaista sopia mallinnuksen yksityiskohdista. Kokouksessa on käytävä läpi, mitä suunnittelusopimuksiin on kirjattu tietomallintamisesta, ja tuleeko sovittuja asioita täsmentää. Tietomallintamista käynnistettäessä avainasemassa ovat tiedonsiirron käytännöt, jotka on selvitettävä varsinkin kokemattomille osapuolille. Tarvittaessa on järjestettävä useampia aloituskokouksia. Tietomallintamisen lähtökohdat on kirjattava pöytäkirjaan, johon voidaan palata hankkeen myöhemmissä vaiheissa. Aloituskokouksessa on täsmennettävä ainakin seuraavat asiat: • minkä suunnittelualojen mallit tuotetaan • mihin malleja aiotaan käyttää • tietomallintamisen vastuuhenkilöt, mahdollinen tietomalli-integraattori sekä mahdolliset tukihenkilöt • mitä ohjelmistoja, ohjelmistoversioita, lisäosia ja –kirjastoja käytetään sekä varmistetaan, ovatko nämä IFC –sertifioituja • mitä mallinnusohjeita ja aloituspohjia kohteessa käytetään • suunnitteluaikataulun mukainen mallien valmistuminen ja päivitystahti • mallin julkaisemisen ja päivityksen käytännöt, kuten tietomalliselosteiden laatiminen ja projektipankin käyttö 81 • miten ja millä ohjelmalla malli virallisesti yhdistetään ja miten yhdistelmämallia käytetään esimerkiksi suunnittelukokouksissa ja suunnitelmien yhteen- sovittamisessa • mallin laadunvarmistuksen käytännöt • mallinnustarkkuus ja toleranssit • koordinaatisto ja korkeusasema • koulutuksen ja perehdytyksen lisätarpeet 4.1.2. Mallinnusohjeiden, aloituspohjien ja tietomalli- selosteiden käyttö Lemminkäisen kohteiden arkkitehtimalleissa pitää käyttää konsernin mallinnusohjeita. Jos arkkitehtitoimisto haluaa käyttää kohteessa omaa mallinnusperiaatettaan ja aloituspohjaa, pitää ne hyväksyttää Lemminkäisellä tai muulla suunnittelun tilaajalla. Sen lisäksi tietomalliselostukseen tulee kirjata, kuinka käytetty mallinnustapa poikkeaa Lemminkäisen mallinnusohjeista. Lemminkäisen mallinnusohjeiden päämäärä on saada malleista yhteensopivia Lemminkäisen käyttämien laskenta-, hankinta- ja tuotantomenetelmien kanssa. Mallin julkaisun yhteydessä on projektipankkiin lisättävä tietomalliseloste. Lemminkäisellä on ArchiCAD- ja Revit Architechture –mallinnusohjelmia varten tietomalliselostepohjat. Tietomalliselostukseen on kirjattava seuraavat asiat: • kohteen tiedot • mallin laatijan ja tarkastajan yhteystiedot • julkaisuajankohta • tietomallin vaihe: tilamalli/alustava rakennusosamalli/rakennusosamalli/toteumamalli • käytetty ohjelmistoversio ja sen lisäosat • mallin rakennusosien mallinnuksen valmiusasteet, tunnisteet ja erityishuomiot • mallinnusohjeista poikkeaminen Haastattelujen perusteella tietomalliselosteeseen pitää kirjata myös olennaiset muutokset edelliseen revisioon verrattuna ja mallille suoritetut tarkastukset. Tämä on tarkoituksenmukaista vasta yleissuunnitteluvaiheesta alkaen. Senaatti Kiinteistöjen 82 mallipohjaan on sisällytetty myös yleiskuvaus käytetyistä lähtötiedoista ja mallinnusperiaatteesta. Lemminkäisen tietomalliseloste päivitetään tältä osin. Lemminkäisellä ei ole käytössään mallinnusohjeita tai tietomalliselostuksia muille kuin arkkitehtimalleille, mutta suunnittelutoimistojen on ilmoitettava, mitä mallinnusohjeita he käyttävät. Myös muiden kuin arkkitehdin on lisättävä projektipankkiin tietomalliselostukset. Konsernin hankkeissa voidaan käyttää Senaatti Kiinteistöjen tietomallivaatimuksia yleisinä ohjeina, jos tarkempaa ohjeistusta ei ole tiedossa. Senaatin tietomallivaatimuksia päivitetään ja täydennetään COBIM -projektin tuloksien pohjalta. Projektin tarkoituksena on kehittää ja ottaa käyttöön kansalliset tietomalliohjeet. 4.1.3. Tietomalli-integraattori ja mallin yhdistäminen Kohteelle voidaan nimetä tietomalli-integraattori, joka hallinnoi kohteen tietomallintamisprosessia ja vastaa mallien yhdistämisestä. Integraattorin tehtävät on annettava hankkeen suunnittelun tai toteutuksen osapuolelle. Toimi sopii luonnollisimmin pääsuunnittelijalle, mutta tehtävä voidaan myös antaa muulle suunnittelijalle, rakennuttajakonsultille, projektinjohtokonsultille tai urakoitsijan edustajalle. Tietomalliintegraattori pitää valita ja hänen tehtävät määrittää viimeistään yleissuunnitteluvaiheen alkaessa, mutta mielellään jo aiemmin. Tietomalli-integraattorin mahdollisiin tehtäviin voi mallin yhdistämisen lisäksi kuulua jokin tai kaikki seuraavista: • osamallien/yhdistelmämallin tarkastaminen visuaalisesti tai ohjelmia käyttäen sekä virheistä raportoiminen • suunnitteluaikataulun seuranta/valvonta • projektipankin hallinnointi • mallinnuskokousten johtaminen • tietomallinnuksen tukihenkilönä toimiminen Lemminkäisen hankkeissa on virallinen yhdistelmämalli tuotettava Solibri Model Checker –ohjelmalla. Tietomalli-integraattorin tai muun mallin yhdistämisestä vastaavan henkilön on ladattava kaikki osamallit IFC-muodossa ja varmistettava, että ne ovat keskenään ajan tasalla. Integraattori tarkastaa osamallit pintapuolisesti ennen yhdistämistä. Osamallit tuodaan SMC-ohjelmaa käyttäen ja tallennetaan ohjelman käyttämään tiedostomuotoon. 83 4.1.4. Suunnitteluaikataulu ja mallien päivitys Mallinnuksen eteneminen on huomioitava suunnitteluaikataulussa ja suunnittelusopimuksissa. Niihin on kirjattava selkeä mallien päivitysrytmi. Päivitysrytmi on täsmennettävä viimeistään mallinnusta käynnistettäessä. Päivitysrytmiä varten on sovittava selkeä ajankohta kuten esimerkiksi parillisten viikkojen maanantai, jolloin mallit lisätään projektipankkiin. Toimivan suunnitteluaikataulun määrittäminen korostuu varsinkin hankkeissa, joissa on kiireelliset suunnitteluvaiheet tai jos ne on limitetty toteutusvaiheen kanssa. Näin varmistetaan kitkaton mallinnuksen eteneminen, minimoidaan suunnittelualojen välinen edestakainen iterointi ja vähennetään suunnitteluvirheitä. Haastattelujen perusteella ehdotetaan ratkaisuksi seuraavanlaisia päivitystaajuuksia. • Tarjousvaiheen mallit 1-3 kertaa simuloinnin tai laskennan pohjaksi. • Suunnitteluvaiheissa 1 tai 2 viikon välein. Tarvittaessa rakennemalli elementtituotantoa varten 1 viikon välein. • Tuotantovaiheessa aina olennaisen muutoksen jälkeen. • Yhdistelmämalli osamallien päivitysten jälkeen (Case-hankkeessa jatkossa 2 viikon välein) Kun malli annetaan ensimmäisen kerran toisten osapuolten suunnittelun pohjaksi on noudatettava Senaatti Kiinteistöjen ohjeistuksen mukaista julkaisumenetelmää. Tällä varmistetaan, että malli on siisti, pääosin virheetön ja sen valmiusaste on riittävän korkea. Ohjeistuksen mukaista julkaisumenettelyä ei välttämättä voida käyttää sellaiseen silloin, kun päivitystahti on useammin kuin 2 viikon välein. Tällöin korjaukset on tehtävä seuraavaan julkaisuun ja tilaaja tekee tarkastusraportin sijaan puutelistan yhdistelmämallikokousta varten. 84 >>>>> >>>>> >>>>> Suunnittelu ja mallinnus >>>>> >>>>> >>>>> Tietomalliselostuksen täydentäminen Mallin siistiminen julkaisukuntoon IFC-kääntö Suunnittelijan tarkastus Tarkastusraportin laatiminen J U L K A I S U Mallin yhdistäminen TietomalliIntegraattorin laadunvarmistus Yhdistelmämallipalaveri Kuva 13. Mallin julkaisuperiaate. Periaate poikkeaa Senaatti Kiinteistöjen ohjeistuksesta siten, että tilaajan hyväksyminen on jätetty pois prosessista, sillä se hidastaisi nopeassa suunnitteluprosessissa. Tilaajan hyväksyntää edellytetään kuitenkin ennen ensimmäistä mallin julkaisua. Malliin ei myöskään tule lisätä mitään, mitä tilaaja ei ole etukäteen hyväksynyt. Mallia julkaistaessa on suoritettava perusteellinen laadunvarmistus ja laadittava tietomalliseloste. Mallit on lisättävä projektipankkiin erikseen pyytämättä suunnitteluaikataulun mukaisesti sekä natiivi-, että IFC-muodossa. Jos malleja ei käytetä muuhun kuin katseluun, ei natiivimalleja tarvitse julkaista kuin suunnittelun lopussa tai erikseen sovitusti. Erityistä huomiota on kiinnitettävä mallin IFC-kääntöön. IFC-kääntöä varten ei toistaiseksi ole olemassa kunnon ohjeita. Mallien on oltava nimetty sovitun mukaisesti eli siten, että siitä käy ilmi kohde, suunnitteluala ja mahdollinen rajaus eli esimerkiksi Puijonlaakson päiväkoti_LVI_1.kerros.ifc. Mallinnusohjelmien muutosten- jäljitystoiminnot edellyttävät, että mallirevisiot nimetään aina samalla tiedoston nimellä, jos niitä halutaan vertailla. Tämän vuoksi tiedoston nimeä ei muuteta. Mallin yhteyteen on aina merkittävä revisionumero projektipankin muita toimintoja käyttäen. On kriittistä, että mallien valmiusasteet ovat riittävät ennen kuin ne annetaan muiden suunnittelijoiden mallinnuksen pohjaksi. Malleista on lukittava pysyvästi ne osat, joita 85 muut suunnittelijat käyttävät lähtötietonaan. Tämä korostuu varsinkin arkkitehdin alustavan rakennusosamallin kohdalla. Suunnittelusopimuksia laadittaessa voidaan tulevaisuudessa mahdollisesti hyödyntää Level Of Development- eli LOD-periaatetta, joka on AIA:n (The American Institute of Architechs) tietomallintamista koskevissa suunnittelusopimuspohjissa. LOD on jaettu 5 eri tasoon, jotka karkeasti vastaavat suomalaisia mallin vaiheita vaatimusmallista toteumamalliin. Suunnittelusopimuksiin voidaan LOD-taulukkoa käyttämällä määrittää jokaisen rakennusosaluokan vaadittu tarkkuus eri vaiheissa sekä näiden vastuuhenkilö. Tällä periaatteella vähennettäisiin epäselvyyttä mallin tarkkuusvaatimuksista ja sitoutettaisiin suunnittelijoita toteuttamaan malli vaaditulla tasolla. Lisäsuunnittelutarvetta aiheuttaville muutostyötarjouksille on asetettava selkeä aikaraja, jonka jälkeen tarkentavaa suunnittelua voidaan jatkaa ilman epävarmuutta mahdollisista käyttäjämuutoksista. Eri osapuolten mallintamisen yhteensovittaminen edellyttää yhteisten menetelmien muodostamisen lisäksi riittävästi aikaa, jotta mainitut menetelmät ehditään ottaa käyttöön. Jatkossa on pyrittävä varmistamaan, että suunnitteluaikataulu ei ole liian tiukka, koska suunnittelun laadunvarmistuksen laiminlyönnillä säästetty aika kostautuu moninkertaisena toteutusvaiheessa. 4.1.5. Laadunvarmistus ohjelmistoja käyttäen Koska mallien visuaalinen tarkastus ei itsessään ole riittävän järjestelmällinen ja tehokas keino poistamaan mallien virheitä, on käytettävä ohjelmien sisäisiä tarkastustyökaluja. ArchiCAD-, MagiCAD- ja Tekla Structures –ohjelmistoissa on yksinkertaiset työkalut, joilla voidaan tutkia mallien törmäyksiä. Yksittäisen osamallin rakennusosien törmäykset ovat kuitenkin vain pieni ongelma yhdistelmämallin ristiriitoihin verrattuna. Yhdistelmämalli pitää tarkastaa Solibri Model Checker-ohjelman tarkastustyökaluja käyttäen. Lisäksi suunnittelijat ovat kokeneet hyväksi käytännöksi visualisoida yhdistelmämallia rinnakkaisella näytöllä mallintaessaan, jolloin he voivat tutkia, miten mallinnettu sopii yhteen muiden mallien kanssa. Mallin laadunvarmistukseen on kiinnitettävä erityistä huomiota ensimmäisen julkaisun yhteydessä, sillä muut suunnittelualat alkavat käyttää mallia mallinnuksensa viitepohjana, sekä toteutusvaiheen alkaessa. Lähtökohtaisesti toteutusvaiheen alkaessa malli ei saisi sisältää yhtään virhettä ja sen tarkkuustason on oltava sovittujen toleranssien 86 rajoissa. Mallissa on tällöin oltava myös riittävästi varaa myöhempiä muutoksia varten. Toteutusvaiheen edetessä mahdollisten suunnitelmamuutoksien vuoksi malliin tulee joka tapauksessa yhteensovitusristiriitoja, jotka on yksinkertaisemmin ratkaistavissa, jos malli on alun perin ollut virheetön. Mallin laadunvarmistuksen on suunnitteluvaiheissa edettävä seuraavasti: 1. Suunnittelijat tarkastavat osamallinsa visuaalisesti ja mahdollisia tarkastustyökaluja käyttäen, korjaavat suunnitteluvirheensä sekä lähettävät mallin projektipankin kautta tietomalli-integraattorille. Tarkastuksen yhteydessä täydennetään tietomallin tarkastuslomake. Esimerkiksi Senaatti Kiinteistöjen tarkastuslomakkeita voidaan käyttää tässä yhteydessä. 2. Tietomalli-integraattori tarkastaa, että osamallit noudattavat sovittua mallinnustapaa ja ne voidaan yhdistää. 3. Tietomalli-integraattori lisää yhdistelmämallin projektipankkiin. 4. Tietomalli-integraattori tekee visuaalisen tai ohjelmallisen tarkastuksen säännöstöjä käyttäen ja kokoaa puutelistan olennaisimmista ristiriidoista. 5. Suunnittelijat käyvät yhdistelmämallin ja puutelistan läpi ja suunnittelualojen väliset ristiriidat ratkaistaan yhdistelmämalli- tai suunnittelukokouksessa. 6. Järjestetään yhdistelmämallikokouksia riittävin väliajoin ainakin toteutussuunnitteluvaiheessa. Yhdistelmämalli käydään läpi ja keskitytään puuteraportissa ilmenneisiin ristiriitoihin. 7. Virheet korjataan seuraaviin osamallijulkaisuihin. 8. Muut osapuolet tutkivat mallin läpi muutostenjäljitystyökaluja käyttäen. Tietomalli-integraattorin suorittama tarkastus ei vähennä suunnittelijoiden vastuuta malleistaan. Heidän on sitouduttava omiin ja yhteisiin laadunvarmistusmenetelmiin. Puutelistojen pituuden vuoksi kannattaisi jokaisen osapuolen kehittää omaan käyttöönsä omat säännöstöt, joilla voisi tarkistaa omaa suunnittelualaa tai työskentelyä koskevat asiat. Lemminkäinen aikoo kehityttää säännöstöt, joita käyttämällä vältettäisiin kaikkein kalleimmat ja karkeimmat virheet. Pääsuunnittelijan on käytettävä säännöstöä, jolla tarkastellaan suunnitelmien keskinäistä yhteensopivuutta. Lisäksi säännöstöjen toleranssit on määritettävä tarkoituksenmukaisesti siten, että pienimpiä virheitä ei huomioida. Ihanteellisessa tilanteessa kehitettyjä säännöstöjä julkaistaan koko rakennusalan käytettäväksi, ja tarvittaessa eri toimijat voisivat optimoida niitä omaan käyttöönsä. 87 Taulukko 2: Tietomallien laatuvaatimukset käyttötarkoituksittain Malli Käyttö Laatuvaatimukset Arkkitehdin tilamalli / inventointi- Suunnittelu ja havainnoillistaminen huoneohjelmaa, tilojen alat vastaavat kerroksien bruttoaloja, talotekniikan tilavaraukset tehty malli Tilapohjainen Kaikki tilat mallinnettu ja määritetty kerroksittain, tilojen korkeus määritetty, tilat vastaavat määrä- Ei päällekkäisiä tiloja, tilojen tunnisteet ja numerointi ovat kunnossa, mallissa ei ole yli - laskenta Tate-analyysit Arkkitehti- Suunnittelu ja havain- malli noillistaminen määräisiä tiloja Tilat rajattu siten, että ne tunnistavat ympäröivät rakenteensa, rakenteiden geometria mal linnettu oikein, rakenteet liittyvät toisiinsa, tilat eivät "vuoda", rakennetyypit määritelty Kuten tilamallissa, lisäksi sovitut rakennusosat mallinnettu ja määritetty kerroksittain, rakennusosat mallinnettu oikeilla työkaluilla, rakennetyypit sisällytetty malliin, rakennusosat eivät leikkaa keskenään Rakennusosapohjainen Kuten tilamallissa, lisäksi ei sisäkkäisiä tai ylimääräisiä rakennusosia, rakennusosien lohko- määrälaskenta sijainti määritelty Tate-analyysit Kuten tilamallissa sovitut rakennusosat mallinnettu ja määritetty kerroksittain, rakennusosat mallinnettu oi - Rakenne- Suunnittelu ja havain- keilla työkaluilla, rakennetyypit sisällytetty malliin, rakennusosat eivät leikkaa keskenään, malli noillistaminen kantavat rakenteet vastaavat arkkitehtimallin rakenteita, aukot ja reiät ovat yhteensopivia muiden osamallien kanssa, rakenteet liittyvät toisiinsa Elementtisuunnittelu Rakennusosapohjainen määrälaskenta Aikataulutiedon hallinta elementtien tunnisteet määritelty, raudoitukset, varaukset ja eristeet määritelty Kuten arkkitehtimallissa lohkot ja kerrokset määritelty, elementtien tunnisteet määritelty, päivämäärätiedot syötetty sovitut komponentit mallinnettu ja määritetty kerroksittain, komponentit mallinnettu oikeilla Tate-malli Suunnittelu ja havain- työkaluilla, komponenteille on määritetty järjestelmät, järjestelmät on nimetty ja värjätty noillistaminen johdonmukaisesti, komponentit eivät leikkaa merkittävästi, järjestelmät mahtuvat tilavarauksien sisään, komponentit liittyvät arkkitehtimalliin sallitulla tavalla Rakennusosapohjainen määrälaskenta Tuotetiedon hallinta Yhdistelmämalli Mallin yhdistäminen Kuten arkkitehtimallissa Laiteobjektit sisältävät oikean ja käyttökelpoisen tuotetiedon huollettavuuden ja hankintojen kannalta Osamallit IFC-muotoisia, osamallien koordinaatistot (origo, korkeusasemat) yhteneviä, osamallit ovat keskenään ajan tasalla Suunnittelu ja havain- Talotekniikka mahtuu tilavarauksiin, talotekniikka ei törmää keskenään, aukot ja reiät ovat noillistaminen Rakennusosapohjainen määrälaskenta 4.1.6. kohdakkain, alakatot ja talotekniikka ovat yhteensopivat Kuten arkkitehtimallissa, tunnisteet ja tyyppitiedot siirtyneet kunnolla IFC-tiedonsiirrossa. Yhdistelmämallikokoukset ja suunnittelukokoukset Tietomallien laadunvarmistuksen vuoksi on kohteiden suunnitteluvaiheessa järjestettävä vähintään yksi yhdistelmämallikokous. Kokouksessa käydään yhdistelmämalli huolellisesti yhdessä läpi. Yhdistelmämalli on lähetettävä osapuolille hyvissä ajoin ennen kokousta. 88 Kokoukseen osallistuu kaikkien suunnittelualojen edustajat, rakennuttaja/projektinjohtokonsultti sekä myös toteutusorganisaatioiden edustajia. Olennaista on, että kokoukseen osallistuvat mallintajat ja mallin käyttäjät, eikä pelkästään suunnittelualojen vastuuhenkilöt. Kokouksen tarkoituksena on havaita ja ratkaista kaikki mallin suunnitteluvirheet, sitouttaa osapuolet laadunvarmistusmenetelmiin sekä tuoda toteutusorganisaation näkökulmaa esille jo varhaisessa vaiheessa. Malli käydään läpi joko kokonaisuutena tai osa-alueittain lohkoihin ja kerroksiin jaoteltuna. Tällöin suunnitteluvirheet todetaan liikkumalla malli läpi tila kerrallaan. Visuaalinen tarkastus tehdään siten, että alakatot ovat mallissa näkyvissä ja siten, että alakatot on piilotettu, jolloin voidaan havaita talotekniikan sijoittuminen keskenään. Vaihtoehtona on myös edetä ennalta määritetyn virheraportin mukaan. Pääsuunnittelija, tietomalli-integraattori, urakoitsijan tai rakennuttajan edustaja on ennen kokousta puutelistan joko visuaalisella tai ohjelmallisella tarkastuksella, mistä on karsittu vähäisimmät virheet pois. Puutelista lähetetään osapuolille etukäteen ja se käydään kokouksessa yhdessä läpi. Ongelmat pyritään ratkaisemaan kokouksen aikana. Parhaassa tapauksessa ratkaisuja voidaan jopa mallintaa kokouksen aikana. Yhdistelmämallikokous toimii mahdollisesti vapaamuotoisena ideariihenä kaavamaisten suunnittelukokousten vastapainoksi. Tämänlaisista workshop-mallisista kokouksista on ollut hyviä kokemuksia osana ulkomaista Integrated Project Delivery –toimintamallia, jonka mukaan eri osapuolten toiminnan yhteensovittaminen ja avoin kommunikaatio ovat avainasemassa laadukkaan lopputuloksen aikaansaamisessa. Tämän vuoksi yksittäiselle yhdistelmämallikokoukselle on varattava useita tunteja aikaa. Myös perinteisissä suunnittelu- ja työmaakokouksissa on malleja hyödynnettävä mahdollisimman paljon suunnitteluratkaisujen käsittelemiseen. On varmistettava, että kokoustiloissa kuten työmaan neuvotteluhuoneissa on videotykki ja muut edellytykset mallin esittämiseksi. 4.1.7. Työmaasuunnitelman laadinta tietomalleja käyttäen Tietomallit tarjoavat käytännöllisen tavan tuottaa työmaasuunnitelma 3D/4D-muodossa (BIM-aluesuunnitelma). Työmaasuunnitelma ja sen muutokset voidaan mallintaa rakennusvaiheittain. Mallinnetusta työmaasuunnitelmasta voidaan tietokoneella tarkas- 89 telun lisäksi tulostaa tasokuvia ja havainnollisia 3D-kuvia osapuolten käyttöön. 3Dkuvista voidaan helposti tehdä eri variaatioita, joissa korostuvat eri seikat kuten kulkureitit tai ensiapupisteet. Työmaasuunnitelman pohjana käytetään maasto- ja arkkitehtimallia natiivimuodoissa. Lemminkäisen kohteissa suositellaan käytettäväksi ArchiCAD-ohjelmaa, mutta työmaasuunnitelman voi tuottaa myös esimerkiksi Tekla Structuresin suunnitteluversiolla. Työmaasuunnitelmaa varten tarvitaan maastomalli. Tarvittaessa työmaasuunnitelman laatija voi tuottaa äärimmäisen yksinkertaisen maastomallin ilman korkeuseroja aluesuunnitelmaa varten. Myöhemmin kun Lemminkäinen kehittää oman arkkitehtimallin aloituspohjan, se tulee sisältämään työmaasuunnitelman tuottamista varten omat tasoyhdistelmät. Tällöin on varmistettava, että arkkitehti käyttää Lemminkäisen aloituspohjaa. Ohjelmistoihin on tarjolla kirjastot, joita käyttäen ainakin torninosturi, työmaa-, sosiaalitila- ja varastoparakit sekä kontit ja parkkipaikat voidaan tuoda sellaisenaan malliin. Lisäksi VTT on tutkimushankkeissaan tuottanut TurvaBIM-kirjaston, joka sisältää monipuolisen kokoelman työmaaobjekteja. Tarvittaessa objekteina voi käyttää myös esimerkiksi mallinnusohjelman perustyökaluja kuten laatta- ja seinätyökaluja, joilla voidaan tehdä aluevarauksia johonkin tiettyyn käyttöön. Mallinnetun työmaasuunnitelman hyöty on kyseenalainen, jos siihen ei pystytä lisäämään kaikkea sitä tietoa, mitä perinteiseen 2D-aluesuunnitelmaan pitää sisällyttää. Käytännössä tämän ei pitäisi muodostua ongelmaksi, mutta joskus on käytettävä visuaalisesti huonoja korvikkeita. 3D-Työmaasuunnitelman tuottaminen ArchiCAD-ohjelmalla: • Avataan toteutusvaiheen arkkitehtimalli, joka sisältää maastomallin tai lisätään maastomalli erikseen. Arkkitehtimallista voidaan käyttää riisuttua versioita, jotta sen ylimääräiset objektit eivät hidasta työmaasuunnitelmamallia. • Avataan tarvittavat objektikirjastot. • Piirretään työmaasuunnitelma objekti-työkalua käyttämällä. Jos haluttua objektia ei löydy, voidaan käyttää esimerkiksi laatta- tai seinätyökalua objektin mallintamiseksi. Tarvittaessa lisätään tekstejä selitteiksi. • Tarvittaessa käytetään ArchiCAD:n simulointitoimintoa, jolla lisätään aikaulottuvuus. • Otetaan kuvatulosteita 3D-työmaasuunnitelman näkymistä työmaan käyttöön. 90 Työmaasuunnitelman mallintamisen edut korostuvat kohteissa, jotka ovat logistisesti vaikeita ja ahtaita sekä työturvallisuuden puolesta haasteellisia. 3D-/4D- työmaasuunnitelma mahdollistaa myös tehokkaamman riskien hallinnan, ja työmaasuunnitelmaa mallintaessa on pyrittävä saamaan mahdollisimman monen toteutusorganisaation osapuolen näkökulma tuotannon eri vaiheissa. 4.1.8. Määrienhallinta tietomalleja käyttäen ArchiCAD-, Tekla Structures-, MagiCAD- sekä Solibri Model Checker –ohjelmissa on määrälaskentatyökalut. Näitä voidaan käyttää hyvin paljon kohteiden määrätiedon hallinnassa sekä suunnittelussa, laskennassa että työmaalla sen sijaan, että kaikki määrät laskettaisiin käsin. Työmaainsinöörit ovat suosineet ArchiCAD.iä määrälaskennassa. Tätä käytetään rakennusosien kappalemäärien ja pintojen pinta-alojen selvittämiseen. Tekla Structures –ohjelmasta saadaan elementtiasennuksiin ja paikallavaluitöihin käytettävää määrätietoa. Myös yhdistelmämallia voidaan käyttää määrälaskentaan, mutta siinä on vähäisempi tietosisältö. Tietomallista voidaan rakennushankkeessa ottaa määrätietoa seuraaviin tarkoituksiin: • suunnitteluratkaisun teknistaloudelliseen arviointiin (tunnuslukujen laskenta) • tarjous- ja kustannuslaskentaan (tilapohjainen tai rakennusosapohjainen laskenta) • taloteknisten analyysien lähtötiedoksi • aliurakka- ja materiaalihankintoihin • aikataulun laadintaan ja seurantaan. • aliurakoitsijan laskujen tarkastamiseen määrien kautta • muun tuotannonohjauksen suunnittelun ja seurannan tueksi Elinkaarihankkeessa omistaja, käyttäjä ja ylläpitäjä voivat hyödyntää tietomallista otettua määrätietoa myös myöhemmin kohteen elinkaaren aikana. 91 Rakennusliikkeen määrä- ja kustannuslaskijan on ennen määrälaskentaa varmistuttava lähtöaineiston tasosta ja sen erityispiirteistä. Laskijan on mallipohjaisen määrälaskennan alussa käytävä läpi seuraavat askeleet: 1. Laskijan on selvitettävä, mitä malleja on käytettävissä ja mitkä ovat niiden viimeisimmät versiot. 2. Laskijan on valittava, millä ohjelmalla määrälaskenta tehdään ja mistä mallista määrät otetaan. 3. Laskijan on tutkittava käytettävän mallin tietomalliseloste ja pantava merkille mallin laajuus- ja tarkkuustaso, käytetty mallinnusperiaate ja poikkeukset mallinnuksessa. Lisäksi laskija voi tutustua mahdolliseen tarkastusraporttiin. Tarvittaessa on otettava yhteys suunnittelijaan, tietomalli-integraattoriin tai tukihenkilöihin, jos tietomalliselosteessa on epäselvyyksiä. 4. Laskijan on kokeiltava ja varmistuttava, että malli avautuu ongelmitta, ja mallin rakennusosat vaikuttavat pintapuolisesti olevan kunnossa. Laskijan on varmistettava, että rakennetyyppien tunnukset ovat merkitty objekteihin ennalta määritetyllä tavalla ja muutoin selkeästi. 5. Laskijan on hahmotettava, mitä olennaisia muutoksia mallissa on tapahtunut edellisen laskennan jälkeen. 6. Rakennusosalaskenta suoritetaan Talo2000-nimikkeistön mukaisesti. ArchiCAD-ohjelmassa määrälaskentaa suoritetaan yksinkertaisimmillaan seuraavasti (suomenkielisessä versiossa): 1. Valitaan projekti – sisältö –valikosta joko taulukot tai määräluettelot hakemistosta valmis taulukko/luettelo, jossa valitun tyypin objektit ovat järjestettynä esimerkiksi piirustustasoittain, kerroksittain, täytteittäin tai pintamateriaalien perusteella. 2. Voit luoda tai muokata omia luettelopohjia klikkaamalla oikealla hiirennapilla määräluettelot tai taulukot –hakemistoa ja valitsemalla määräluettelot/asetukset. Valikossa voi luoda uuden luettelon määrittämällä, mitkä objektit lasketaan, mitä tietoja niistä luetteloidaan ja mihin järjestykseen ne asetetaan. 3. Luettelot voi tulostaa pdf-muotoon. 4. Jos käytössäsi on Tocoman iLink, voit viedä määräluettelot Excel-taulukkotiedostoon ja sitä kautta Tocoman Pro –määrälaskentaohjelmaan. 5. Tarvittaessa ArchiCAD-ohjelman monimutkaisemmassa määrälaskennassa voidaan turvautua M.A.D.:n laatimaan määrälaskentaohjeeseen ja -harjoitusvihkoon. 92 Tekla Structures –ohjelman määrälaskenta: 1. Valitaan reports –painikkeen kautta joku TS:n valmiista luettelopohjista. 2. Tarvittaessa käytetään Template editor –toimintoa tekemään uusia luettelopohjia. 3. Määräluettelot voidaan tulostaa Excel –taulukkomuotoon tai lisätä esimerkiksi valmistuskuvien yhteyteen. Tekla Structures-ohjelman määrälaskentatoiminnolla pystyy ottamaan kappalemääriä IFC-muotoisista arkkitehti- rakenne ja tate-malleista, jotka on tuotu ohjelmaan referenssimalleina. Kappalemääristä johdettuja määriä ei pysty referenssimalleista ottamaan. Määrätiedon käyttökelpoisuus riippuu siitä, onko IFC-kääntö tehty oikein. ArchiCAD-, Tekla Structures- ja MagiCAD-ohjelmilla mallinnetut IFC-mallit ovat parhaita tähän tarkoitukseen. Solibri Model Checker –ohjelman määrälaskenta: 1. Valitaan Informaation talteenotto (ITO) –välilehti. 2. Valitse joku valmiista ITO-kuvauksista ja suorita laskenta. 3. Voit luoda tai muokata ITO-kuvauksia Informaation talteenotto –ikkunasta valitsemalla Uusi ITO-kuvaus. 4. Valitsemalla Raportoi, voit tuottaa Excel-taulukoita ITO-kuvauksista. Määrälaskelmien lisäksi on laskijoiden kirjattava laskentamuistiot, joista käy ilmi käytetyt laskenta-asetukset ja –menetelmät. Laskentamuistiot on tallennettava määräluetteloiden yhteyteen, jos se vain on mahdollista. Mallista otetun määrätiedon luotettavuuden ja tehokkuuden parantamiseksi on suoritettava seuraavat askeleet: 1. Tehtävä osapuolille selväksi, että tietomalleja käytetään määrätiedon hallintaan, joka edellyttää oikean mallinnustavan käyttöä ja olennaisten laatuvaatimusten täyttymistä sekä kirjattava käyttäjiä varten, miltä osin mallia ei voida käyttää määrälaskentaan. Sovittava, miltä osin mallia voidaan käyttää tähän tarkoitukseen. 2. Määritettävä rakennusosien tyyppi- ja sijaintitiedot selkeästi. 3. Otettava käyttöön järjestelmälliset laadunvarmistusmenetelmät sekä sitoutettava osapuolet niihin. 93 4. Koulutettava ja perehdytettävä mallinkäyttäjät tietomallien käyttöön ja määrälaskentamenetelmiin. Varmistettava, että he ovat tutustuneet tietomalliin ja suunnittelijoiden huomautuksiin määrälaskennan rajoituksista. Tarjottava heille jatkuva tuki. 5. Vaihtoehtoisesti vaaditaan suunnittelijoita tuottamaan tarvittavat määräluettelot muiden osapuolten käyttöön. Tuottamalla heille riittävä ohjeistus, jotta määräluettelot voidaan laatia rakennusliikkeen vaatimusten mukaisesti. 6. Varmistettava, että määräluettelot pysyvät ajan tasalla malleja päivitettäessä esimerkiksi synkronointia käyttäen. 7. Käytettävä määrälaskentaohjelmia kuten TCM iLink ja määrienhallintaohjelmia kuten TCM Pro. Case-tutkimuksen yhteydessä palveluntuottajaorganisaation edustajat ovat ilmaisseet vaatimuksen, että myös vähemmän keskeiset määräluettelot tulisivat aina suunnittelijoilta, mitä vastaavasti suunnittelijat vastustavat. Tällöin suunnittelijoiden vastuu mallin määrätiedon ja määräluettelon oikeellisuudesta on selkeä, mikä vähentää erimielisyyksiä ja sitouttaa suunnittelijoita mallin laatuun. Seurauksena suunnittelijoiden työmäärä ja suunnittelupalkkiot kasvavat. Etuna saavutetaan luotettavaa määrätietoa. Suunnittelijoille ei ole kuitenkaan harjaantunut yhtä kriittistä arviointikykyä määrien oikeellisuudesta kuin kokeneille laskentatoimihenkilöille. Lisäksi suunnittelijat eivät ole sopimusteknisesti kuitenkaan KSE:n eli konsulttitoiminnan yleisten sopimusehtojen mukaan velvollisia maksamaan suunnittelupalkkion suuruuden ylittävää osuutta korvauksista. Koska kyseessä on tässä tapauksessa määrävirhe, eivät mahdolliset korvaukset todennäköisesti ole samassa suuruusluokassa. Koska tietomallien käyttö ei ole vielä riittävän kehittynyttä, ei suunnittelijoilta voida edellyttää täysimääräistä korvausvastuuta määräluetteloidensa täsmällisyydestä. Suunnittelijat ottavat malleistaan esimerkiksi tila-, elementti-, laite-, ovi- ja ikkunaluettelot. Pienellä vaivalla he pystyisivät tulostamaan myös lisää luetteloita muiden osapuolten käyttöön. Varsinkaan tate-mallin IFC-muodosta muut osapuolet eivät voi edes ottaa yhtä tarkkaa määrätietoa, kuin suunnittelijat saavat MagiCAD-natiivimallistaan. Lemminkäinen pyrkii hankkeissaan hyödyntämään automaattisia määrähallintaohjelmia kuten Tocomanin TCM Pro-ohjelmaa. Tämä ohjelma voidaan iLink:n avulla yhdistää arkkitehtimalliin, josta se ottaa Talo2000-nimikkeistön mukaiset rakennusosamäärät 94 kerros- ja lohkosijainneittain. Ohjelmassa on tietokanta, joka sisältää rakennusosia vastaavat suoritteet ja niiden menekit. Näitä käytetään hyväksi kustannus- ja aikataulunhallinnassa. Ohjelmaa ei voida hyödyntää, jos rakennusosien attribuuttitiedot eivät ole oikealla tavalla määritettyjä ja oikeaa mallinnustapaa ei ole käytetty. Tämänlaiset ohjelmat nopeuttavat määrätiedon hallintaa ja sen hyödyntämistä kustannuslaskentaan ja aikataulun laatimiseen huomattavasti. Kuitenkin ohjelmaa käytettäessä korostuu se, että mallin laatuvaatimukset tältä osin on täytyttyvä ilman erillistä tarkastusta tai muuten suuriakin määrävirheitä voi jäädä huomaamatta. Kun suunnittelijat päivittävät malleja, muiden osapuolten laatimat määräluettelot eivät sisälly päivitettyyn malliin. Tällöin on joko tehtävä määräluettelo uudelleen, tuotava määräluettelot vanhasta mallista synkronointi tai import-toimintoja käyttäen tai luotettava entisen mallirevision määräluetteloihin. Käytännössä varsinkin Tekla-mallissa tarvittavat määräluettelot on tehtävä uudelleen, jos päivityksen yhteydessä on tapahtunut määrien kannalta olennaisia muutoksia, sillä synkronointi ei tällä hetkellä toimi kunnolla. 4.1.9. Aikataulutiedon hallinta tietomalleja käyttäen Aikataulutietoa voi hallita tietomallien avulla tällä hetkellä kahdella tavalla. Ensinnäkin voidaan Tekla Structures –ohjelman toiminnoilla syöttää rakennusosien suunnittelu-, valmistus-, asennus-, ja toteuma-ajankohdat rakennemalliin. Tästä on huomattava etu, jos kyseessä on monimutkainen runko, jonka valmistukselle ja asennukselle on annettu tiukka aikataulu. Toinen tapa on ottaa mallista määrätietoa ja siirtää se joko taulukkolaskentaohjelmia tai Vico Office – tai TCM Planner -ohjelmistoa käyttäen aikataulutusohjelmaan. Tekla Structures –rakennemallin aikataulutiedon hallinta etenee seuraavasti: 1. Suunnittelija tai urakoitsijan edustaja lohkottaa mallin Model Organizer –työkalulla. Lohkotieto ei ole pakollinen. 2. Urakoitsijan edustaja määrittää asennusjärjestyksen. Jos elementtisuunnittelu etenee osittain limittäin elementtien tuotannon kanssa, urakoitsija asettaa rakennemalliin määräajat elementtien asentamiselle ja välittää tiedon tehtaalle synkronoinnin tai muun keinon välityksellä. 3. Tehdas määrittää asennuspäivämäärän mukaan oman valmistusaikataulunsa ja sitä kautta määräajat elementtien suunnitelmien valmistumiselle. Käytännössä 95 tämä tieto on toimitettu suunnittelijoille rakennusliikkeen kautta, mutta tiedon on tulevaisuudessa siirryttävä suoraan esimerkiksi synkronoinnin kautta. 4. Suunnittelijat noudattavat annettuja määräaikoja ja toimittavat elementtisuunnitelmien valmistusajankohdat tehtaalle. 5. Elementtitehdas toimittaa elementtilistauksensa valmistusajankohtineen, joiden avulla urakoitsija määrittää lopulliset asennusajankohdat. 6. Työmaainsinöörit kirjaavat toteutuneet valmistus- ja asennusajankohdat sekä käyttävät näitä tietoja tuotannonohjauksessa Kuva 14. Elementtien aikatauluttaminen 4D-mallissa synkronoinnin toimiessa. Suunnittelijoiden päivittämä rakennemalli pitää synkronoida aikataulunhallintaan käytetyn mallin kanssa, jonka yhteydessä tarkastetaan, että aikataulutiedot pitävät paikkansa. Valitettavasti tällä hetkellä synkronointityökalu ei toimi, mutta on oletettavissa, että seuraavassa Tekla Structures –ohjelmaversiossa synkronointi on käyttökunnossa. Tätä ennen aikataulunhallinnassa on pärjättävä päivittämättömällä mallilla, jos se ei poikkea huomattavasti toteutettavasta mallista tai käytettävä Site Data Exchange –ohjelmaa, jolla voi siirtää Task Manager-ohjelman tietoa mallista toiseen. Elementtituotantoon ja asennusten toteutuksessa on luonnollisesti käytettävä ajan tasalla olevaa mallia. Elementtitehtaat eivät nykyhetkellä hyödynnä aikataulunhallinnassa tietomallia suoraan, joten työmaainsinöörit joutuvat lisäämään valmistusajankohdat siihen. Käytännössä excel-muotoisesta taulukosta voisi siirtää tiedot suoraan malliin, jos taulukkopohja on toimiva ja tehtaan toimihenkilöt perehtyisivät menetelmän käyttöön. Lemminkäinen on tutkinut Vico Office –ohjelmaa, jolla voi aikatauluttaa tehtävien kestot sekä muodostaa jana- tai paikka-aika-aikataulut. Vico Office sisältää työkalut myös määrätiedon hallintaan ja sillä voidaan ottaa tietoa suoraan malleista. Ohjelman tieto- 96 kantoihin voi määrittää määrätietoa vastaavat suoritteet ja niitä vastaavat menekit ja kustannukset. Näitä tietoja käyttäen urakoitsija voi määrittää aikataulutehtävät sekä niiden järjestyksen ja kestot. Tällä hetkellä Vico Office vaikuttaa keskeneräiseltä eikä Vico tarjoa riittävästi tukea sen käytölle. ArchiCAD-ohjelmassa on myös simulointitoiminto, jolla voidaan tuoda malliin neljäs eli aikaulottuvuus. Tätä toimintoa voi käyttää lähinnä visualisointiin tai karkeaan aikataulutukseen. 4.1.10. Tietomallien käyttö tate-analyyseissä Tietomalleja voidaan käyttää tate-analyyseihin ja simulointeihin joko tarjousvaiheessa tai suunnitteluvaiheessa. Tate-analyysejä voidaan parhaiten hyödyntää tarjousvaiheen vaihtoehtotarkastelussa, koska päätöksiin voidaan vielä vaikuttaa. Tarjousvaiheessa ei kuitenkaan ole tarkoituksenmukaista optimoida suunnitteluratkaisuja, vaan tutkia, voidaanko välttyä kalliilta järjestelmäratkaisuilta. Suunnitteluvaiheessa voi vastaavasti tateanalyysejä käyttää sekä vaihtoehtotarkasteluihin että suunnitteluratkaisujen hiomiseen. Taulukko 3: Yhteenvetotaulukko talotekniikan analyyseistä170. Energia-analyysi YLEISSUUNNITTELU energiatavoitteiden toteutumisen arviointi vaihtoehtotarkastelut ja -vertailut Olosuhdeanalyysi yksittäisen ratkaisun vaikutus kokonaistaloudellisuuteen tate-järjestelmien mitoituksen lähtötiedot tate-järjestelmien mitoituksen lähtötiedot yksittäisen ratkaisun vaikutus tietyn tilan olosuhteisiin yksittäisen ratkaisun vaikutusten arviointi Virtaussimuloinnit (CFD) tilan lämmönjakautuminen ja ilmavirrat erikoistapauksissa Ympäristövaikutusanalyysi (LCA) Elinkaarikustannuslaskenta (LCC-laskenta) TOTEUTUSSUUNNITTELU energiatavoitteiden toteutumisen arviointi järjestelmien ja energiankulutuksen ympäristövaikutukset vaihtoehtotarkastelut ja -vertailut suunnitelmien jatkojalostaminen kustannusennustaminen käytön ajalle Valaistussimulointi ja -laskenta valaistusratkaisujen havainnollistaminen ja arviointi Suomessa tuotetaan olosuhde- ja energiasimuloinnit Riuska- tai Ida-ohjelmilla. Näihin voidaan tuoda arkkitehdin tilamalli tai arkkitehtimalli IFC-muodossa. Edellytyksenä on, että malli on tuotettu tietyllä mallinnustavalla. Mallin pitää sisältää seuraava tietosisältö: • 170 kohteen geometria, bruttoala ja tilavuus Senaatti Kiinteistöt (2007): Tietomallivaatimukset osa 9: Tate-analyysit 97 • tilat, niiden alat ja käyttötarkoitukset (tilat pitää olla mallinnettuna siten, että ne tunnistavat ympäröivät rakenteensa) • kohteen vaipan rakenteet tyyppitietoineen, esim. seinät ja ikkunat (rakennetyypit voidaan myös määrittää jälkikäteen) • ilmansuunnat (voidaan myös määrittää jälkikäteen) Arkkitehtimallin tuominen IFC-muodossa simulointiohjelmiin on osoittautunut ongelmaksi, jonka ratkaisemiseksi ei ole osattu määrittää yksikäsitteistä ohjeistusta. Yleensä rakenteet eivät siirry tai tilat eivät tunnista ympäröiviä rakenteita. Arkkitehti harvoin onnistuu korjaamaan ongelmia ilman selkeitä ohjeita ja tate-analyysien tuottajat eivät itse pysty mallinnusohjelmillaan muuttamaan arkkitehtimallia haluamakseen. Käytännössä on todettu, että varmempi keino on mallintaa tilamalli erikseen MagiCAD Room –ohjelmalla, jolloin tuonti simulointiohjelmiin onnistuu lähes poikkeuksetta. MagiCAD Room –ohjelmassa voidaan käyttää arkkitehtimallista tulostettuja tasokuvia referenssipohjina. 4.1.11. Kohdistusobjektin käyttö Suunnittelijoiden on laitettava malliensa rakennuksen lähelle tiettyyn koordinaattipisteeseen sovitunlainen kohdistuskuutio tai muu vastaava objekti. Objektin keski- tai kulmapisteen on sijaittava sovitussa koordinaattipisteessä. Jos kohdistuskuutiot eivät ole kohdakkain mallia yhdistettäessä, niistä näkee suoraan, että koordinaatistot eivät ole yhtenevät. Kohdistuskuutio on helppo ja yksinkertainen tapa eliminoida koordinaatistojen epäonnistuneen yhteensovituksen mahdollisuus. 98 5. Tutkimustulosten arviointi 5.1. Tulosten suhde aikaisempaan tutkimustietoon Case-tutkimuksessa tuloksissa suositellut tietomallintamiseen liittyvät käytännöt ja menetelmät ovat pääosin linjassa Senaatti Kiinteistöjen tuottamien tietomallivaatimusten ja ProIT -projektin tulosten kanssa. Tästä huolimatta myös joitakin poikkeamia löytyi. Lemminkäisen tietomalliprosessi, joka esitettiin Salla Paloksen diplomityössä on osittain vanhentunut, ja sitä täydennetään tämän tutkimuksen tuloksilla. Käytännönläheisessä case-tutkimuksessa korostui, että osapuolten todelliset toimintatavat harvemmin täysin vastaavat kirjallisuudessa edellytettyjä lähtökohtia onnistuneelle tietomallien käytölle. Varsinkin projektinjohtomallisissa hankkeissa mallin laadunvarmistusta laiminlyödään johtuen kiireestä, kokemattomuudesta tai huolimattomuudesta, jolloin malli on vähemmän käyttökelpoinen. Lisäksi esimerkiksi prosessien yhteensovittamisen, mallinnustoleranssien ja tietoteknisten ongelmien vuoksi käytännön toiminnassa on varattava riittävästi aikaa ja resursseja virheiden korjauksille. Case-kohteiden projektit eivät edenneet täysin Salla Paloksen dokumentoiman tietomalliprosessin mukaisesti. Julkisen sektorin kilpailuttama elinkaarihanke poikkeaa tietomalliprosessin pohjana käytetystä yksittäisestä projektinjohtototeutusmuodon hankkeesta. Palveluntuottaja sai itse tuottaa kohteiden suunnitelmat ja kohteiden työmaahenkilöstön olisi pystynyt ottamaan mukaan jo kohteiden alkuvaiheissa. Haastatteluissa käsitellyt käytännöt ja kehitysehdotukset täydentävät hyvin Senaatti Kiinteistöjen ohjeissa ja Salla Paloksen tutkimuksessa esitettyjä toimintaohjeita. Esimerkiksi määrälaskennan osalta käsiteltiin ohjelmien aiheuttamia rajoituksia kuten määräluetteloiden katoamista mallien päivittyessä. Toisaalta kirjallisuudessa oli esitetty järjestelmällinen menetelmä määrälaskentaan liittyen hankkeen eri vaiheissa, jota haastatteluissa käsiteltiin lähinnä vain työmaan määrälaskennan kannalta. Tuloksissa ilmeni myös ristiriitoja Senaatti Kiinteistöjen tietomallivaatimuksien ohjeisiin verrattuna. Ensinnäkin mallin julkaisu- ja yhdistämisrytmin on oltava suunnitteluvaiheen jälkeen tiheämpi kuin ohjeistuksessa. Tietomallivaatimuksissa on myös määri- 99 tetty hyvin jäykkä mallin julkaisuprosessi, jossa rakennuttajan edustajan on joka kerta hyväksyttävä malli ennen julkaisua. Suunnittelijan suorittama laadunvarmistus on oltava riittävä. Tietomalli-integraattorin havaitsemat virheet on kirjattava raporttiin, mutta ne on case-tutkimuksen tulosten mukaan korjattava vasta seuraavaan mallijulkaisuun. Senaatti Kiinteistöjen ohjeistuksessa oli talotekniikan analyysit esitetty selkeämpänä kokonaisuutena kuin haastattelutuloksissa. Tämä johtui siitä, että ohjelmistojen teknisistä puutteista johtuen hankkeen analyysit suoritettiin hyvin monimutkaisella tavalla. Aiemmissa tutkimuksissa ei rakennusvaiheen tietomallipohjaista aikataulunhallintaa ole kovin laajasti käsitelty. Haastatteluissa käytiin kattavasti läpi case-hankkeessa käytetty aikataulunhallintaprosessi Tekla Structures -ohjelmistoa käyttäen ja sen ongelmat. Sen lisäksi case-tutkimuksessa esitettiin muutamia tulevaisuuden mahdollisuuksia rakennusvaiheen aikataulunhallintaan tietomalleja hyödyntäen. Tiimityökalujen käytön mahdollisuuksia ja ongelmia ei ole tutkittu aiemmin. Samoin toteumamallin kokoamisesta ei ole aiempaa materiaalia saatavilla. 5.2. Tulosten luotettavuus Case-tutkimuksen yhteydessä tehdyt haastattelut osoittautuivat kattaviksi. Haastatteluissa selvisi, mitkä olivat case-hankkeen tietomallipohjaisen suunnittelun ja tietomallien käytön kannalta muodostuneet pahimmiksi esteiksi. Case-tutkimuksen tuloksissa saatiin selkeitä ratkaisuehdotuksia esitettyihin ongelmiin. Osapuolten kanssa keskusteltiin uusien ja olemassa olevien käytäntöjen yksityiskohdista. Näillä käytännöillä voidaan ratkoa ongelmakohdat sekä virtaviivaistaa ja tehostaa tietomallintamisprosessia. Case-tutkimusta rajoitti se, että tate-urakoitsijan ja projektinjohto-organisaation edustajat ovat käyttäneet mallinkatseluohjelmia vain vähäisesti. Heille ei ollut muodostunut tarkkaa näkemystä siitä, kuinka ohjelmia voidaan käyttää. Siitä huolimatta he ovat hahmottaneet selvät näkemykset tietomallin käytön mahdollisuuksista projektinhallinnan näkökulmasta ja osasivat kertoa, mikä oli suunnittelutiedon kommunikoinnin kannalta oleellista tietomallikäytännöissä. Lisäksi Lemminkäisen tietomalliasiantuntijoilla on todella hyvä näkemys mallin hyödyntämisestä yleisellä tasolla, mutta heillä on useita projekteja samanaikaisesti, jolloin 100 he eivät osanneet kertoa kaikkea case-hankkeen ongelmakohdista. Näitä tietoja saatiin kuitenkin onnistuneesti haastattelemalla kohteiden työmaainsinöörejä, jotka olivat hyvin perehtyneitä sekä kohteisiin että tietomallien käyttöön. Työmaainsinöörit kuitenkin ovat käyttäneet tietomalleja ensimmäisen kerran vasta case-hankkeen aikana, joten he eivät olleet vielä kokeilleet kaikkia tietomallien mahdollisuuksia tuotannonohjauksessa. Suuri osa hankkeen tietomallien käyttöön osallistuvista henkilöistä ei perehtynyt kohteisiin elinkaariajattelun osalta. Elinkaarihankkeiden mallintamisen erityispiirteitä käsiteltiin riittävästi suunnittelijoiden ja elinkaarikonsulttien haastatteluissa. Kaiken kaikkiaan case-tutkimuksen tiedot ovat varsin riittäviä muodostamaan selkeän kuvan case-hankkeen tietomallintamisprosessista, sen ongelmakohdista, ongelmien ratkaisuista, vanhoista ja uusista käytännöistä sekä tietomallintamisen mahdollisuuksista. 5.3. Tulosten yleistettävyys Tuloksien osittainen hyödyntäminen on jo aloitettu case-hankkeen myöhemmissä rakennuskohteiden suunnittelussa ja toteutuksessa. Käytännöt pyritään ottamaan käyttöön elinkaarihankkeissa, joiden palveluntuottajaksi Lemminkäinen valitaan. Elinkaarihankkeet ovat rakennushankkeita laajimmassa muodossaan, minkä vuoksi Kuopion elinkaarihanke valittiinkin työn tarkastelukohteeksi. Tämän tutkimuksen tuloksina saatuja käytäntöjä voidaan soveltaa sellaisenaan tai riisutussa muodossa myös muissa rakennushankkeissa. Kuitenkin useat esimerkiksi suunnittelunohjauksen käytännöistä edellyttävät, että suunnittelijat ovat sopimussuhteessa rakennusliikkeeseen. Koska projektihenkilöstön tietomalliosaaminen vaihtelee huomattavasti, ei tämän tutkimuksen tuloksia tule soveltaa kaikissa hankkeissa. Jos hankkeessa ei ole aikaa tai resursseja kouluttaa osapuolet tehokkaiksi tietomallin käyttäjiksi, on tietomallin käyttöä rajattava yksinkertaisimpiin käyttötarkoituksiin. Tutkimuksen tulokset nojaavat vahvasti Lemminkäisen toimintajärjestelmään ja tietomalliprosessiin. Tuloksia ei siten pysty hyödyntämään sellaisenaan muiden alan yritysten tietomallitoiminnassa. Tulokset pyritään kuitenkin tuoda esille osana PRE-hankkeen tuloksia, ja työn tulosten pohjalta on arvioitu esimerkiksi PRE-hankkeen COBIM- 101 moduulin raportteja, joiden tarkoituksena on tehdä Senaatti Kiinteistöjen uusisita tietomallivaatimuksista kansalliset ohjeistukset. 5.4. Jatkotutkimustarpeet Seuraavat tietomallien käyttöön liittyvät teemat vaativat lisää tutkimusta ja kehittämistä, sillä diplomityön teon hetkellä aiheista ei ole riittävästi tietoa saatavilla. 5.4.1. IFC-käännön ohjeistaminen Natiivimalleja muunnettaessa IFC-muotoon on määritettävä oikeat asetukset, jotta IFCmallia voidaan hyödyntää eri käyttötarkoituksiin. Ensinnäkin IFC-käännössä on yleinen kääntäjä -moduulin lisäksi vaihtoehtoina eri IFC-tiedonsiirtomoduuleja. Sen lisäksi on malleista rakennusosaluokkakohtaisesti määritettävä, mitkä osat siirretään IFCmuotoon. Näin voidaan esimerkiksi määrittää, siirretäänkö kalusteet IFC-muotoon. Toistaiseksi ei ole olemassa virallista IFC-kääntöohjetta. Ohjeen luomiseksi on ensin määritettävä, mitä IFC-mallin erikoispiirteitä sen eri käyttötarkoitukset edellyttävät. Yhdistelmämallin tietosisällöstä voidaan sopia osapuolten välillä helpostikin, mutta IFC-mallin simulointiohjelmiin tuonnin edellytykset ovat häilyviä. Kun nämä lähtökohdat ovat tiedossa, on mahdollista laatia lyhyet yksinkertaiset suositukset IFCkäännölle. Tietomalli-integraattori voisi käyttää ohjetta myös tarkastaakseen, ovatko IFC-muotoiset osamallit muunnettu oikein ennen niiden yhdistämistä. 5.4.2. Tiimityöympäristö ja mallien synkronointitoiminto Yhteistä, reaaliajassa päivitettävää mallia voisi käyttää muiden kuin suunnittelijoiden tietosisällön säilyttämiseen mallissa ja nopeampaan tiedonvälitykseen. Seuraavat asiat on kuitenkin ensin ratkaistava: • Kuinka tiimityöympäristöstä saadaan nopeampi ja kevyempi? • Missä tiimityömallia säilytetään? Miten mallipalvelin on järjestettävä? • Kuinka tiimityöympäristöä on käytettävä, jotta muiden osapuolten lisäämät määräluettelot ym. pysyvät ajan tasalla? • Miten tehokkaat ovat tiimityöympäristön viestintämahdollisuudet? Voidaanko näitä käyttää virallisena viestintäkanavana? • Voiko muille osapuolille antaa oikeuden muokata mallin osia ja tehdä niihin merkintöjä, jotka hyväksytetään suunnittelijalla tiimityöympäristöä käyttäen? 102 • Mitä varotoimenpiteitä on järjestettävä, että tiimityöympäristön kaaduttua suunnittelu ei esty tai etteivät osapuolet pääse vahingoittamaan tiimityömallia? • Miten tiimityökalut saadaan toimimaan palomuurien yli? • Mitä muita mahdollisuuksia tiimityökalut mahdollistavat? 5.4.3. Solibri Model Checker –säännöstöjen kehittäminen SMC-ohjelman vakiosäännöstöjä ja –toleransseja käytettäessä mallin virheraportista tulee liian suuri. Täten jokaisen osapuolen pitää kehittää tai kehityttää omaan käyttöön säännöstöt, jotka keskittyvät oman alansa olennaisimpiin virheisiin. Tällöin jokainen osapuoli pystyy lisäksi hyödyntämään asiantuntemustaan laadunvarmistuksessa. Useita räätälöityjä säännöstöjä käyttäen mallin laadunvarmistuksesta saadaan monikerroksinen, järjestelmällinen ja aukoton prosessi, jonka seurauksena kalliiden suunnitteluvirheiden toteaminen toteutuksen yhteydessä minimoidaan. Varsinkin pääsuunnittelijan ja rakennusliikkeen tulee kehittää säännöstöt, joilla vältetään pahimmat virheet. Myös mahdolliset rakennus- ja suunnittelualojen yleiset osapuolikohtaiset säännöstöt voisi ottaa käyttöön, jos sellaiset olisi olemassa. 5.4.4. Inventointimallin tuottaminen skannaamalla Inventointimalli voidaan tuottaa joko vanhoista piirustuksista tai laserkeilaamalla eli skannaamalla. Laserkeilauksella on tällä hetkellä seuraavat haittapuolet: • Skannaaminen on tällä hetkellä kallista ja hidasta. • Skannatut rakenneosat eivät sisällä tyyppi-, tuote- tai muuta tietosisältöä. • Piilotettuja rakenneosia ei voi skannata ilman rakenteiden purkamista. • Skannatun mallin osat eivät sijoitu keskenään suorakulmaisesti, jolloin sen käyttö uusien suunnitelmien mallinnuksessa vaikeutuu. Uusia rakennusosia on hankala mallintaa vinojen pintojen ja objektien pohjalta. • Skannaamallakin saadaan parhaimmillaan vain 2,5 cm toleranssin tarkkuus. Skannauksen yleistyessä ja sen menetelmien hioutuessa sen hinta alenee, sen ongelmia saadaan ratkaistua ja siitä saatava taloudellinen hyöty kasvaa. Jatkossa skannaus saattaa olla hyvä vaihtoehto inventointimallin tuottamiseksi. Tämä edellyttää lisätutkimusta. 103 5.4.5. Mallinnustoleranssit ja niiden kertautuminen Case-tutkimuksessa ei saatu selvää näkemystä eri vaiheiden mallien mittatarkkuuksista. Mallintamisen mittatarkkuudeksi suositellaan käyttämään Senaatti Kiinteistöjen ohjeistuksen mukaista mittatarkkuutta: • Arkkitehdin tilamallissa riittää 100-200 mm tarkkuus (poikkeuksena inventointimalli). • Inventointimalli tuotettava siten, ettei pieniä vinouksia ja kaltevuuksia mallinneta. Skannatun inventointimallin tarkkuus on tällä hetkellä parhaimmillaan vain 2,5-3 cm. • Alustavassa rakennusosamallissa on oltava vähintään liittymämitat eli rakennusosien kuten ovien ja ikkunoiden nimellismitat (moduulimitat). • Rakennusosamallissa on oltava rakennusosien, aukkojen ja varausten tarkat mitat tuotantoa varten. • Poikkeaminen sovitusta mittatarkkuudesta on kirjattava tietomalliselosteeseen. Ennen kaikkea case-tutkimuksessa jäi epäselväksi, miten suhtautua toleranssien kertautumiseen. Esimerkiksi jos arkkitehtimallinnuksen toleranssi on luonnossuunnitteluvaiheessa 5 cm, niin onko tate-mallinnuksen toleranssi myös 5 cm vai suurempi. Tatemallinnuksen toleranssi ei voi olla tarkempi kuin lähtötietona käytetty referenssimalli. 5.4.6. Toteumamallin tuottaminen Case-tutkimuksessa ei saatu ratkaistua, kuinka toteumamalli tuotetaan parhaiten ja kuinka tarkasti eri suunnittelualojen mallit pitää korjata toteuman mukaisesti. Tietomalleja voi kuitenkin käyttää aputyökaluna toteumatiedon kommunikointiin työmaan ja suunnittelijan välillä. Lisätutkimuksen kannalta kriittisiä kysymyksiä ovat: • Mitkä muutokset malliin on lisättävä? Kuinka suuret poikkeamat em. muutoksissa sallitaan ilman, että toteumamallia tarvitsee päivittää? • Kuinka punakynärevisioita on käytettävä? Miten ratkaistaan se, että normaalit suunnitelmat päivittyvät punakynärevisioiden rinnalla? • Kuinka tietomalleja voidaan käyttää toteumatiedon keräämisessä? Voiko urakoitsija itse lisätä toteumatietoa jossain määrin malliin, minkä jälkeen suunnitte- 104 lija kävisi muutokset läpi ja hyväksyisi ne? Voiko tiimityöympäristöä käyttää hyväksi em. prosessissa? • Miten voidaan minimoida päällekkäisen työn määrä toteumatiedon kirjaamisessa ja mallintamisessa? • Miten toteumamallia voidaan tulevaisuudessa hyödyntää? Voidaanko toteumamallista kehittää toimiva ylläpitomalli? Kuinka paljon toteumamallia voidaan käyttää jälkilaskennassa? 105 6. Johtopäätökset Tutkimuksen tarkoituksena oli case-tutkimuksen ja kirjallisen tutkimuksen avulla selvittää, mitä hyötyä voidaan tietomallintamisella saavuttaa elinkaarihankkeissa sekä kartoittaa elinkaarihankkeiden tietomallintamiseen liittyviä suunnittelu-, toteutus- ja projektinhallintakäytäntöjä. Tavoitteena oli selvittää, mitä olemassa olevia, toimivia käytäntöjä on jo käytössä sekä mitä käytäntöjä on kehitettävä nykyisten tietomalliprosessien täydentämiseksi. Työssä esiteltiin myös pintapuolisesti Lemminkäisen aiemmin kehittämän tietomalliprosessin sisältö hankevalmistelu-, suunnittelu- ja toteutusvaiheissa. Lisäksi tutkittiin, mitä ongelmia ja ilmiöitä case-hankkeen piirissä on tullut esiin ja miten niihin on voitu reagoida. Case-hanketta koskevat haastattelut osoittautuivat varsin kattaviksi tutkimuksen kannalta. Haastatteluihin osallistui riittävästi hankkeen eri osapuolia, jotka toivat esiin useita eri näkökulmia tietomallintamiseen liittyen. Haastatteluissa käsiteltiin tietomallintamisen mahdollisuuksia ja ongelmia sekä yleisellä että yksityiskohtaisella tasolla. Case-hankkeen jatkokohteissa on tarkoitus hyödyntää tutkimustyön avulla yhdessä kehitettyjä käytäntöjä. Tulevissa kohteissa voidaan todennäköisesti välttää Martti Ahtisaaren koulun ja Puijonsarven koulun pahimmat tietomallintamiseen liittyvät ongelmat tarkemmin sovittujen käytäntöjen avulla. Case-tutkimuksessa ilmeni, että tietomallien hyödyntämisen kannalta on äärimmäisen tärkeää varsinkin kunnollinen ja järjestelmällinen laadunvarmistus, johon kaikki osapuolet sitoutuvat, sekä toimiva osapuolten välinen tiedonsiirto ja kommunikointi. Tietomallin käyttäminen eri tarkoituksiin kuten esimerkiksi tietomallipohjaiseen toteutukseen, määrälaskentaan ja taloteknisiin analyyseihin edellyttää, että mallin tietosisältö on virheetön ja että sitä voidaan käyttää ilman mallin erillistä tarkastusta. Tämän vuoksi suunnittelijoiden on varmistettava, että muiden osapuolten käytössä on virheetön malli. Oma lukunsa on eri suunnittelualojen mallien yhteensovitus, jolloin onnistuneen tiedonsiirron merkitys korostuu varsinkin, jos suunnitteluaikataulu on kireä. Tietomallintamisen käyttömahdollisuuksien kehittyessä myös tiedonsiirto muuttuu monimutkaisemmaksi. Tiedonsiirron ongelmia voidaan välttää sopimalla yhtenäiset tiedonsiirtostandardit ja mallinjulkaisukäytännöt sekä riittävän dokumentaation toimittaminen mallien julkaisun yhteydessä. 106 7. Yhteenveto Tietomallipohjainen suunnittelu ja toteutus ovat merkittäviä keinoja varmistaa kohteiden pitkän aikavälin elinkaaritaloudellisuus, joka on elinkaarivastuumallissa vahvasti sekä tilaajan että palveluntuottajaorganisaation edunmukaista. Tietomalleja voidaan käyttää tähän varhaisessa suunnitteluvaiheessa vaihtoehtotarkasteluissa, joilla pyritään vaikuttamaan kohteen elinkaarikustannuksiin ja energiatehokkuuteen. Suunnitteluvaiheessa tietomallien avulla hiotaan järjestelmäratkaisut mahdollisimman taloudellisiksi ja niitä voidaan käyttää lähtökohtana olosuhde- ja energiasimuloinneissa. Tietomallinnettuja suunnitteluratkaisuja tarkastelemalla voidaan myös varmistua, että kohteen elinkaaritaloudelliset tavoitteet ovat saavutettavissa. Tietomalleja voidaan käyttää kohteen elinkaarikustannusten laskentaan. Energiakustannusten ohella kohteen rakentamis- ja ylläpitokustannuksia voidaan arvioida tilaja rakennusosapohjaisesti. Suunnittelun edetessä voidaan mallin määrätietoa käyttää muutoskustannusten arviointiin. Suunnittelu voidaan tehdä tietomallipohjaisesti merkittävästi tarkemmalla tasolla kuin perinteisesti. Laadukkaampien suunnitelmien seurauksena saavutetaan aika- ja kustannushyötyä, kun muutosten tarve ja laatuvirheiden määrä vähenee. Ennen kaikkea eri alojen suunnitelmat voidaan sovittaa yhteen paremmin tietomalleja hyödyntämällä. Tietomallien mukaan toteutettaessa kohteesta tulee suunnitelmanmukaisempi kuin pelkkiä piirustuksia käyttäen. Tietomalleja voidaan käyttää myös kohteen ylläpidossa, käytössä ja jatkokehittämisessä esimerkiksi PTS- eli pitkän tähtäimen suunnittelussa. Valitettavasti elinkaarihankkeiden tarjousvaiheet ovat haastavia ja työläitä. Tällöin ei ole tarjoajien kannalta tarkoituksenmukaista uhrata resursseja tarkempaan suunnitteluun ja vaihtoehtotarkasteluun eikä ottaa käyttöön raskaita suunnittelunohjauksen ja projektinhallinnan käytäntöjä vielä tarjousvaiheessa. Tämän seurauksena menetetään paljon tietomallipohjaisen suunnittelun luomista vaikutusmahdollisuuksista kohteen tehokkuuteen ja taloudellisuuteen. Lisäksi elinkaarihankkeet kilpailutetaan julkisen sek- 107 torin tarjouskilpailuina, jolloin ei voida soveltaa esimerkiksi kumppanuussuhteiden mahdollistamaa yhteistä hankevalmistelua tilaajan ja palveluntuottajan välillä. Koska projektiorganisaation muodostaminen elinkaarihankkeissa on palveluntuottajaosapuolen vastuulla, voidaan hankkeeseen valita suunnittelijatoimistot, joilla on vahva tietomalliosaaminen. Lisäksi toteutusorganisaatio voidaan ottaa mukaan tietomallintamisprosessiin jo varhaisessa vaiheessa. Elinkaarihankkeissa voidaan kehittää toimintakäytäntöjä toteuttamalla samalla organisaatiolla useita eri kohteita peräkkäin. Tulevaisuudessa kohteen ylläpitovaiheessa toteumamallia voidaan käyttää ylläpitomallina, joka toimii yhdistettynä sähköiseen huoltokirjaan. Nykyhetkellä tämä ei ole mahdollista, vaan tietomallia voidaan käyttää vain huoltokirjan rinnalla. Tietomallien hyödyntämisen parantamiseksi ei riitä pelkästään toimivien käytäntöjen kehittäminen, vaan hankkeiden osapuolet on sitoutettava näihin käytäntöihin. Casehankkeen suunnittelutoimistojen mallinnusosaaminen on osoittautunut riittäväksi, mutta laadunvarmistusta ei ole toteutettu tarpeeksi hyvin. Muut osapuolet ovat kohteiden työmaainsinöörejä lukuun ottamatta käyttäneet malleja valitettavan vähän. Tietomallien käyttöönoton kynnystä voidaan alentaa käyttämällä mallia yhdessä esimerkiksi kokouksissa, käyttämällä mallinnusohjelmien ilmaisversioita, järjestämällä yhteisiä koulutustilaisuuksia, tarjoamalla riittävä käyttötuki sekä ennen kaikkea osoittamalla, että tietomallien avulla voidaan vähentää työn määrää ja saavuttaa taloudellista hyötyä. Vaikka mallien pääkäyttötarkoitus eli tietomallipohjainen suunnittelu ja toteutus voidaan järjestää nykytietämyksellä todella hyvin, on tietomalleilla vielä lukemattomia käyttömahdollisuuksia, jotka vaativat lisätutkimusta. Varsinkin kohteiden inventointimallin tuottaminen skannaten, ylläpitomallin kokoaminen ja hyödyntäminen, tiimityöympäristöjen hyödyntäminen ja tietomallien käyttö taloteknisissä analyyseissä edellyttävät enemmän tai vähemmän jatkokehitystä. Lisäksi myös palvelutuottajaorganisaation kannalta olennaisia tietomallipohjaiseen määrienhallintaan liittyviä käytäntöjä on hiottava parempaan muotoon. Tällä hetkellä myös ohjelmistojen kehitys on nopeaa ja uusia käyttökelpoisia ohjelmistoja julkaistaan jatkuvasti. Näiden ohjelmistojen käyttöönotto edellyttää syvällistä perehtymistä. 108 Lähdeluettelo Kirjallisuus Hänninen Juha. Elinkaarimallit kuntien palvelutuotannossa 2009 Kankainen Jouko, Junnonen Juha-Matti. Rakennuttaminen 2001 Palos Salla. Tietomalliprosessi - Tietomallitiedon käyttö suunnittelussa, rakentamisessa ja ylläpidossa 2010 Kiviniemi Markku, Sulankivi Kristiina, Mäkelä Tarja. Tietomalli ja työmaan turvallisuus 2009. Lahdenperä Pertti. Ajatuksia elinkaarivastuuhankkeista 2003 Lahdenperä Pertti, Nykänen Veijo, Rintala Kai. Elinkaarimallit –Tilapalveluhankkeiden vaihtoehtoiset toimintatavat 2006 Laine Tuomas. Tuotemallintaminen talotekniikkasuunnittelussa 2008 Lehtinen Teemu, Löfgren Jenny, Matala Saara, Moilanen Heikki, Smeds Matilda. Case Martti Ahtisaaren koulu – Tietomalliprosessin kehittäminen elinkaarihankkeessa 2011 Penttilä Hannu, Nissinen Sampsa, Niemioja Seppo. Tuotemallintaminen arkkitehtisuunnittelussa 2006 Penttilä Hannu, Nissinen Sampsa, Niemioja Seppo. Tuotemallintaminen rakennushankkeessa 2006 Sarja Asko, Laine Juhani, Pulakka Sakari, Saari Mikko. Inducon – rakennuskonsepti 2003. Vakkilaine, Jussi. Rakennuksen tietomalli suunnittelun apuvälineenä 2009 109 Valjus Juha, Varis Markus, Penttilä Hannu, Nissinen Sampsa. Tuotemallintaminen rakennesuunnittelussa 2007 Wang Jilei. Integrated Project Delivery - Achieving relational contracting through traditional project management methods 2008. WWW-sivut BuildingSMART www-sivut: http://buildingsmart-tech.org/specifications/ifc-releases (viitattu 30.5.2011) Kuopion elinkaarihankkeen elinkaaritoteutuksen tarjouspyyntö: http://lehdet.lehtiyhtyma.fi/kuopio/tarjouspyynto_elinkaaripalvelut.pdf (viitattu 21.10.2010) M.A.D. www-sivut. http://www.mad.fi/mad/archicad14.html (viitattu 18.5.2011) Pörssitiedote 29.7.2009: Lemminkäiselle iso elinkaarihanke Kuopiosta https://newsclient.omxgroup.com/cdsPublic/viewDisclosure.action? disclosureId=335014&messageId=403197 (viitattu 21.10.2010) Pörssitiedote 15.12.2009: Lemminkäinen aloittaa Kuopion elinkaarihankkeen rakennustyöt https://newsclient.omxgroup.com/cdsPublic/viewDisclosure.action? disclosureId=377845&messageId=452308 (viitattu 21.10.2010) Julkaisematon aineisto Lemminkäinen Oy. tarjousaineisto, Kuopion elinkaarihanke, 6.7. osa A (1) Lemminkäinen Oy. laadunvarmistussuunnitelma, Kuopion elinkaarihanke 24.2.2010 Lemminkäinen Talo Oy, Mallinnuspalaveri pöytäkirja, Kuopion elinkaarihanke 26.8.2009. Solibri Inc. Solibri Model Checker –koulutusmateriaali, 2010. 110 Senaatti Kiinteistöjen tietomallivaatimukset: Senaatti Kiinteistöt: Tietomallivaatimukset osa 1: Yleinen osuus 2007. Senaatti Kiinteistöt: Tietomallivaatimukset osa 3: Arkkitehtisuunnittelu, versio 1.02 2007. Senaatti Kiinteistöt: Tietomallivaatimukset osa 4: TATE-suunnittelu 2007. Senaatti Kiinteistöt: Tietomallivaatimukset osa 5 Rakenne-suunnittelu 2007. Senaatti Kiinteistöt: Tietomallivaatimukset osa 6 Laadunvarmistus, versio 1.02 2007. Senaatti Kiinteistöt: Tietomallivaatimukset osa 7 Määrälaskenta 2007. Senaatti Kiinteistöt: Tietomallivaatimukset osa 8 Havainnollistaminen 2007. Senaatti Kiinteistöt: Tietomallivaatimukset osa 9 TATE-analyysit 2007. Haastattelut Kakkinen Ari, Karhunen Mika, Ronkainen Juha, LVIS-urakointi. Haastattelu Kuopio 17.2.2011 Koponen Mikko, työmaainsinööri. Haastattelu Kuopio 16.2.2011. Leppävuori Keijo, Mairinoja Pekka, elinkaarilaskentakonsultointi. Haastattelu Espoo 14.2.2011 Liukkonen Jari. Tate-valvoja. Haastattelu Helsinki 8.2.2011. Niemi Harri, työmaainsinööri. Haastattelu Kuopio 18.2.2011. Partanen Matti, tietomalliasiantuntija. Haastattelu Helsinki 3.2.2011 Pehkonen Turunen, rakennesuunnittelu. Haastattelu Kuopio 18.2.2011. 111 Perko Tomi, Räihä Aleksi, arkkitehtisuunnittelu. Haastattelu Helsinki 11.2.2011 Salin Janne, tietomalliasiantuntija. Haastattelu Helsinki 4.2.2011 Varstala Matti, projektipäällikkö. Haastattelu Helsinki 10.2.2011. Vasara Jukka, Oravainen Timo, Ollikainen Tomi, Lehikoinen Tuomas, LVISsuunnittelu. Haastattelu Kuopio 17.2.2011. Virit Artur, tietomalliasiantuntija. Haastattelu Helsinki 8.2.2011 112 Liite 1: Lemminkäinen Talo Oy:n tietomalliprosessi 2007 Liite Salla Paloksen diplomityöstä Tietomalliprosessi - Tietomallitiedon käyttö suunnittelussa, rakentamisessa ja ylläpidossa. Prosessikartassa kuvattu Lemcon Oy:n tietomalliprosessi projektinjohtohankkeissa vuonna 2007. Lemcon nykyään osa Lemminkäinen Talo Oy:tä. 113 114 115 116 117 118 119 120 121 Liite 2: Case Martti Ahtisaaren koulun tietomalliprosessi 2011 Liite SimLAB:n tuottaman AS-IS simuloinnin loppuraportista 2011: Case Martti Ahtisaaren koulu – Tietomallin kehittäminen elinkaarihankkeissa. 122 123 124 125
© Copyright 2024