pilotti: hyväntoivonpuisto, tietomallin laatiminen infra...
TRANSCRIPT
Pilotti: Hyväntoivonpuisto, tietomallin laatiminen
Infra FINBIM
LOPPURAPORTTI
Muutoshistoria:
Versio Pvm Tila (luonnos / ehdotus /
hyväksytty)
Tekijä(t) Huomautukset (määrittely / toteutus / dokumentointi)
0.1 28.6.2013 Luonnos Tuomo Järvenpää raporttiluonnos
0.2 4.10.2013 Luonnos Tuomo Järvenpää
Outi Palosaari
Sami Kaleva
taitorakenteiden ja puiston
raportit yhdistetty
0.3 14.10.2013 Luonnos Kari Kuusela
Tuomo Järvenpää
tarkistus
oikoluku
1.0 9.4.2014 Ehdotus Tuomo Järvenpää Pieniä lisäyksiä ja korjausta
kommenttien perusteella
1.1 16.4.2014 Hyväksytty Tuomo Järvenpää Lisätty prosessikaavio
2 (67)
SISÄLTÖ
1 Johdanto ............................................................................................................................................. 3
1.1 Tausta ....................................................................................................................................... 3
1.2 Organisaatio ............................................................................................................................. 4
1.3 Pilottia tukevan hankkeen kuvaus ............................................................................................ 5
1.4 Pilotin osapuolet ja viestintä .................................................................................................... 6
2 Taitorakenteiden tietomalli ................................................................................................................ 7
2.1 Pilotin tavoitteet ja hankkeessa pilotoitavat asiat ..................................................................... 7
2.1.1 Keskeisimmät kehitysaskeleet ja oletetut riskit ........................................................... 7
2.2 Pilotin dokumentointi ............................................................................................................... 8
2.2.1 Revit Structure ohjelmiston soveltuvuus taidetukimuurien tietomallintamiseen ......... 8
2.2.2 Tekla Structures -tietomallin luominen – Tukimuurit ................................................ 18
2.2.3 Tekla Structures -tietomallin luominen – Portaat....................................................... 28
2.2.4 Tekla Structures -tietomallin luominen – Välimerenkadun silta ................................ 30
2.2.5 Tietotekninen ympäristö ............................................................................................. 37
2.2.6 Prosessikuvaus ........................................................................................................... 39
2.2.7 Nimikkeistöt ja ohjeet ................................................................................................ 39
2.3 Tietomallin ulkopuolinen tarkastus ........................................................................................ 41
2.4 Johtopäätökset ........................................................................................................................ 42
2.4.1 Havaitut hyödyt ja ongelmat, edistysaskeleet ja kehitystarpeet. ................................ 42
2.4.2 Tietomallintamisen haasteellisuuden arviointi /Arviointisabluuna ........................... 43
2.4.3 Jatkotoimenpiteet ....................................................................................................... 43
3 Puiston tietomalli ............................................................................................................................. 44
3.1 Tavoitteet ................................................................................................................................ 44
3.1.1 Pilotoidut asiat ............................................................................................................ 44
3.2 Pilotin dokumentointi ............................................................................................................. 44
3.2.1 Civil 3D -ohjelmiston soveltuvuus puiston tietomallintamiseen ............................... 44
3.2.2 Prosessin kulku ........................................................................................................... 45
3.2.3 Mallin tarkastaminen .................................................................................................. 49
3.2.4 Piirustustarpeen minimointi ....................................................................................... 50
3.2.5 InfraFINBIM -nimikkeistö ......................................................................................... 50
3.3 Johtopäätökset ........................................................................................................................ 50
3.3.1 Hyödyt, haitat, ongelmat, kehitystarpeet .................................................................... 50
3.3.2 Tietomallintamisen haasteellisuuden arviointi ........................................................... 52
3.3.3 Jatkotoimenpiteet ....................................................................................................... 52
4 Yhdistelmämalli ............................................................................................................................... 53
Liite A - Kokonaisyhteenveto pilotista ..................................................................................................... 55
Liite B - Tekla Structures -mallin havainnekuvia ..................................................................................... 57
Liite C - Yhdistelmämallin havainnekuvia ............................................................................................... 61
Liite D - InfraFINBIM arviointisabluunateksti ......................................................................................... 64
Liite E - Arviointisapluunan kategoriat ja valmiustasot ........................................................................... 67
3 (67)
1 Johdanto
1.1 Tausta
Suomessa kiinnostus siltojen ja muiden infrarakenteiden tietomallintamiseen on suurta. Tietomallien
käyttöä ja niiden mahdollisuuksia sillansuunnittelussa ja rakentamisessa on selvitetty mm. Älykäs Silta-,
5DSilta, 5DSilta2 ja 5DSilta3 -kehityshankkeissa. Tietomallien käyttö infrarakenteiden suunnittelussa,
rakentamisessa ja ylläpidossa lisää koko hankeprosessin tehokkuutta ja luotettavuutta. Tietomalli on
myös erittäin havainnollinen apuväline rakennushankkeen kaikissa vaiheissa. Tietomallipohjaisen
suunnittelun kehittäminen ja yhteisten käytäntöjen laatiminen sekä niistä sopiminen ovat koko infra-alan
kehittämisen, tehokkuuden ja laadunvarmistuksen kannalta tärkeitä.
Mallintamisessa on ollut ongelmia monimuotoisen geometrian omaavissa rakenteissa.
Betoniraudoituksen 2D-piirustusten tuottaminen tietomallista on ollut vaikeaa. Vaativan
väylägeometrian siirtäminen sillan tietomalliin vaatii myös kehittämistoimenpiteitä. Mallintamisen
yhdenmukaiset käytännöt eivät ole vielä riittävän hyvällä tasolla koko infra-alan tehokkaan
mallintamisen mahdollistamiseksi. Mallintamisessa käytettyjen ohjelmien määrä on pieni ja tiedonsiirto
eri ohjelmistojen välillä ei toimi ongelmitta, vaan vaatii paljon kehittämistyötä.
Helsingin Jätkäsaaressa sijaitsevan Hyväntoivonpuiston ja siihen liittyvien siltojen, tukimuurien sekä
maanalaisten rakenteiden mallintaminen on sopiva hanke tietomallin laatimisen kehittämistehtäväksi,
koska se on geometrialtaan vaativa ja sisältää monentyyppisiä rakenteita. Hankkeeseen liittyvistä alueen
muista rakenteista (paikoitushalli, maanalaiset huoltokäytävät ja kadut) laaditaan erillisinä hankkeina
myös tietomallit. Mallien laatimisessa käytetään eri ohjelmistoja, joten toimiva tiedonsiirto ja
tiedonsiirron kehittäminen eri ohjelmistojen välillä on hankkeessa hyvin tärkeää. Tietomallien
hyödyntäminen käsittää suunnittelun, rakentamisprosessin, laadunvalvonnan ja ylläpidon rakennusten
käyttöiän aikana.
Tietomallin laatiminen suoritetaan kehityshankkeena, jossa mallintamisen työtapoja kehitetään ja
tutkitaan tietomallien siirtoa eri tietomallinnusohjelmistojen välillä. Kehityshankkeessa syntyvät
mallinnukset ja työtapojen kehittämiseen liittyvät tulokset tullaan myöhemmin hyödyntämään yleisesti
infrahankkeiden mallinnustehtävissä.
Mallinnukseen liittyviä muita kehitystoimenpiteitä ovat taidetukimuurien pintaratkaisujen ja
raudoitteiden mallintamisen kehittäminen siten, että rakenteiden vaativan geometrian hallitseminen
mallinnusohjelmalla nopeuttaa raudoituspiirustusten laadintaa ja suunnitelmien virheettömyyttä.
Kehitystoimenpiteitä ovat myös mallinnuksen hyödyntäminen rakenteiden lujuuslaskennassa.
Puistosta laadittava tietomalli on koko puistosuunnittelualan kannalta merkittävä kehityshanke.
Hyväntoivonpuisto on erinomainen esimerkkikohde: puisto rakennetaan kaikkia rakennekerroksia
myöten ”tyhjälle tontille”, puistoon liittyy runsaasti uusia erityyppisiä rakennusosia, puiston alle
toteutetaan tiloja ja pima-alue (pilaantuneen maan alue), puisto on suuri (5ha) sekä puisto on
paikallisesti ja valtakunnallisesti merkittävä kokonaisuus.
Hanke toteutetaan 5DSILTA-konsortion puitteissa toteutettavana kehittämishankkeena. Tavoitteena on
kehittää silta- ja muiden taitorakenteiden tietomallinnuksen käyttöä rakenteiden suunnittelussa ja
rakentamisessa sekä ylläpitotehtävissä rakenteiden käyttöiän aikana. Hankkeen aikana mallinnuksen
edistymistä ja kehittämistoimenpiteitä esitellään säännöllisin väliajoin 5DSILTA-konsortion
kokouksissa.
4 (67)
1.2 Organisaatio
Konsultin projektiryhmä koostuu Ponvia Oy:n, VSU Oy:n, Geobotnia Oy:n ja Plaana Oy:n henkilöistä.
Pääkonsulttina ja suunnittelutyön koordinoijana toimii Ponvia Oy.
Työtä valvoo ja ohjaa Helsingin kaupungin rakennusvirasto edustajinaan Ville Alajoki ja Petra
Rantalainen. Projekti toimi Infra FINBIM –työpaketin pilottina.
Käytettävien ohjelmistojen kehittämisestä ja työn ohjauksesta ohjelmien käytön osalta toimivat Janne
Virtanen (Virtual Systems Oy) ja Pekka Vähäkainu (Future CAD Oy).
Seuraavassa on esitetty projektin organisaatio.
TILAAJAN ORGANISAATIO
Tilaajan projektin johto (HKR)
DI Ville Alajoki Projektipäällikkö, Sillat ja taitorakenteet
Puistorakenteet (HKR)
Petra Rantalainen Projektipäällikkö, puistosuunnittelu
KONSULTIN ORGANISAATIO
Konsulttiryhmän projektin johto ja vuorovaikutus (Ponvia Oy)
DI Kari Kuusela Projektipäällikkö ja vuorovaikutus
Tukimuurien ja taitorakenteiden rakennussuunnittelu (Ponvia Oy)
Ins. Jouni Ikonen Rakennussuunnittelu, tukimuurit
DI Risto Kallio Yleissuunnittelu, sillat
Ins. Jussi Pinola Rakennussuunnittelu, sillat
Taidetukimuurien ja puiston pääsuunnittelu (VSU Oy)
Arkk. Outi Palosaari Tukimuuri- ja silta-arkkitehtuuri, Tietomallin ohjaus
Arkk. Tommi Heinonen Puiston pääsuunnittelu
Arkk. SAFA Mikko Kämäräinen Tukimuurien ja portaiden arkkitehtuuri
Geotekninen suunnittelu ja esirakentaminen (Geobotnia Oy)
DI Olli Nuutilainen Geotekninen suunnittelu, Tietomallin ohjaus
DI Janne Herva Geotekninen suunnittelu
Väylä- ja kuivatussuunnittelu (Plaana Oy)
Ins. Toivo Kämäräinen Väylä- ja kuivatussuunnittelu, Tietomallin ohjaus
Tietomallinnus, Puistot (VSU Oy)
Maisema-arkk. yo Sami Kaleva Mallinnus, Civil 3D malli
Tietomallinnus, sillat, tukimuurit ja portaat (Ponvia Oy)
DI Tuomo Järvenpää Mallinnus, Revit Structure ja Tekla Structures -malli
Piirt. Sanna Palmroos Mallinnus, Tekla Structures -malli
5 (67)
DI Anssi Mattila Mallinnus, Tekla Structures -malli
YHTEISTYÖTAHOT
Revit Structure -ohjelmisto (Virtual Systems Oy)
Janne Virtanen Ohjelmiston kehittäminen
Civil 3D -ohjelmisto (Future CAD Oy)
Pekka Vähäkainu Ohjelmiston kehittäminen
1.3 Pilottia tukevan hankkeen kuvaus
Hyväntoivonpuisto on Helsingin Jätkäsaareen tuleva koko alueen läpi kulkeva kaarevalinjainen puisto
(kuva 1). Yli kilometrin pituinen puisto muodostaa lähikortteleineen alueella aukottoman vyöhykkeen.
Puistossa kulkee jalankulun ja pyöräilyn pääreitti, joka johtaa alueen muihin puistoihin ja merenrantaan.
Puisto nostetaan täyttömailla nykyistä maanpinnan tasoa korkeammalle, jolloin kevyen liikenteen
yhteydet jatkuvat silloilla pääkatujen yli. Pilottiprojektissa mallinnettiin kuvassa 2 esitetty
Selkämerenpuisto sekä Hyväntoivonpuiston pohjoisosaa.
Kuva 1. Hyväntoivonpuisto sijaitsee Helsingin Jätkäsaaressa. Kuvassa on esitetty projektissa
mallinnettu alue puistosta.
Mallinnusalue
6 (67)
Hankkeessa laaditaan Hyväntoivonpuistosta ja siihen liittyvistä rakenteista (sillat, tukimuurit, portaat)
tietomallit. Projektin 1. vaihe käsittää yhden teräsristikkorakenteisen kevyenliikenteen sillan, noin 380
metriä tukimuuria sekä noin 1,30 hehtaaria puistoa. Tukimuurit ovat ns. taidetukimuureja eli niiden
ulkomuoto poikkeaa huomattavasti perinteistä tukimuureista.
Pilottiprojekti alkoi 31.3.2010 ja malli luovutettiin tilaajan tarkastukseen 30.11.2012. Pilottiprojekti kesti
2v ja 8kk.
Kuva 2. Havainnekuva mallinnetusta alueesta.
1.4 Pilotin osapuolet ja viestintä
Työn tilaajana toimi Helsingin kaupungin rakennusvirasto (HKR). Tilaajan projektipäällikkö Ville
Alajoki (HKR) hoiti pilotin läpiviemisen InfraFINBIM-työpaketissa. Suunnittelutyön aikana järjestettiin
suunnittelukokouksia noin kuukauden välein, jossa käytiin läpi projektin etenemistä ja esille tulleita
asioita. Yhteensä projektin aikana järjestettiin 21 suunnittelukokousta.
Projektin ulkopuolisena tarkastajana toimi WSP Finland Oy.
7 (67)
2 Taitorakenteiden tietomalli
2.1 Pilotin tavoitteet ja hankkeessa pilotoitavat asiat
Tavoitteena on laatia rakenteista yksityiskohtaiset tietomallit, joita hyödynnetään jo suunnitteluvaiheessa
alueelle suunniteltavien muiden rakenteiden yhteensovittamisessa. Tavoitteena on, että tietomalli on
laajennettavissa ja yhdistettävissä alueen muiden tietomallien kanssa. Tietomalleja käytetään
rakennusvaiheessa rakennustyön toteutussuunnitelmina sekä laadunvarmistuksessa ja hankkeen
projektinjohtamisen apuvälineenä. Rakenteiden valmistuttua tietomallia käytetään, sekä tarvittaessa
täydennetään, huollon ja ylläpidon tehtävissä.
Vaihtoehtoisen tietomallinnusohjelmiston soveltuvuus kohteen tietomallintamiseen
Taitorakenteiden suunnittelussa on Suomessa perinteisesti käytetty Tekla Structures -ohjelmistoa.
Hankkeen tilaajalla eli HKR:llä oli ohjelman soveltuvuudesta jo omakohtaista kokemusta ennen
Hyväntoivonpuisto -projektin alkamista. Pilotissa haluttiin saada kokemuksia myös muista
tietomallinnusohjelmistoista, sillä yhden ohjelmiston liian vahva markkina-asema ei ole toivottavaa.
Pilotissa testattavaksi ohjelmistoksi valittiin Autodeskin Revit Structure -ohjelmisto. Pilotissa oli
tarkoitus kartoittaa Revit Structure -ohjelman soveltuvuus taidetukimuurien tietomallin luomiseen.
Yhteistoiminta eri mallinnusohjelmistojen välillä
Hankkeeseen liittyvistä alueen muista rakenteista laaditaan myös tietomalleja eri suunnittelijoiden
toimesta. Mallien laatimisessa käytetään eri ohjelmistoja, joten toimiva tiedonsiirto ja tiedonsiirron
kehittäminen eri ohjelmistojen välillä on hankkeessa hyvin tärkeää.
Yhdistelmämallin luominen
Puistokokonaisuudesta tehdään yhdistelmämalli, jossa on esitetty kaikki puistoon rakennettavat
taitorakenteet, maakerrokset, penkit, puut, suoja-aidat ja muut puiston varusteet ja laitteet.
Yhdistelmämallin avulla hankkeen kokonaisuutta voidaan tarkastella havainnollisesti.
Piirustustarpeen minimointi
Hankkeen tietomalleista on tarkoitus tehdä niin yksityiskohtaiset, että perinteisten piirustusten tarve
voidaan minimoida. Hankkeessa tutkitaan miten piirustuksissa esitetyt asiat voidaan esittää tietomallissa
ja minkälaisia piirustuksia tehdään niistä asioista, joita ei ole järkevää esittää tietomallissa.
Urakkalaskenta mallipohjaisesti
Hanke on tarkoitus laittaa aikanaan urakkalaskentaan tietomallipohjaisesti eli urakoitsijat saavat
käyttöönsä hankkeessa tehdyt tietomallit. Urakoitsijoiden tulee itse suorittaa määrälaskenta suoraan
tietomallista eli suunnittelija ei enää anna valmiita määräluetteloita. Keskeinen asia mallipohjaisessa
määrälaskennassa on se, että malli on oikein rakennettu ja dokumentoitu. Kaikkien määrälaskijoiden
tulisi saada samat määrä ulos mallista.
Urakkalaskentaa pilotoidaan antamalla tietomalli ulkopuolisen konsultin tarkastukseen. Konsultti tekee
mallista oman määrälaskennan ja sitä vertaillaan suunnittelijan itse suorittamaan määrälaskentaan.
2.1.1 Keskeisimmät kehitysaskeleet ja oletetut riskit
Hankkeen keskeisenä kehitystavoitteena on luoda niin tarkka tietomalli, että perinteisten piirustusten
määrää voidaan vähentää. Piirustusten tekeminen tietomallista on osittaista tuplatyötä, sillä
piirustuksissa esitetään tietoa, joka on jo saatavissa mallista. Tavoitteena on, että suunnittelu nopeutuisi,
virheet vähenisivät ja muutosten tekeminen olisi joustavampaa ilman piirustuksia.
8 (67)
Tietomallista suoritettu määrälaskenta on tarkempi kuin piirustuksista tehty määrälaskenta, sillä
tietomallista saadaan kaikkien rakenteiden todelliset määrät erittäin tarkasti lueteltua. Tietomalli on
itsessään erittäin tarkka suunnitelma, jossa mahdolliset yhteentörmäykset ja muut virhekohdat
paljastuvat jo suunnittelun aikana. Laadukkaampi ja tarkempi suunnitelma näkyy alhaisempana
urakkahintana vähentyneen riskin ansiosta.
Tietomallin tekemiseen liittyy suuri aikataulu- ja kustannusriski, sillä suunnittelun alkuvaiheessa voi olla
vaikeaa arvioida mallintamiseen tarvittavaa työmäärää. Mitä haastavampi geometria ja mitä tarkempaa
mallintamistarkkuutta käytetään, sitä enemmän mallintamiseen menee aikaa ja sitä vaikeampaa
työmäärän arviointi on. Riskiä voidaan pienentää realistisella työmääräarvioinnilla ja työn jatkuvalla
seurannalla työmäärän ennustettavuuden varmistamiseksi. Tarkan tietomallin tekemiseen kuluu paljon
kauemmin aikaa kuin saman suunnitelman esittämiseen perinteisesti piirustuksina. Poikkeuksena ovat
geometrialtaan niin haastavat kohteet, että niitä ei olisi voinut suunnitella perinteisillä menetelmillä.
Ohjelmistojen soveltuvuus saattaa edellyttää ohjelmistojen kehittämistyötä tai jopa
suunnitteluohjelmiston vaihtamista kesken suunnittelun. Eri ohjelmistojen välillä saattaa myös ilmetä
tiedonsiirto-ongelmia. Tästä aiheutuu riski työn viivästymisestä ja todennäköisyys arvioitujen
suunnittelukustannusten ylittämisestä suurenee.
2.2 Pilotin dokumentointi
2.2.1 Revit Structure ohjelmiston soveltuvuus taidetukimuurien tietomallintamiseen
Taidetukimuurien mallintaminen aloitettiin Autodesk Revit Structure 2012 -ohjelmistolla, koska
haluttiin kokemuksia uusista tietomallinnusohjelmistoista. Tavoitteena oli mallintaa tukimuurien
betonielementit, paikkavaluosa ja betoniraudoitus.
Geometria
Tukimuurit mallinnettiin Revit Structureen käyttäen referenssimallina arkkitehdilta saatua 3D-
pintamallia. Pintamalli oli tehty AutoCAD -ohjelmistolla. Referenssimallin hyödyntämisessä oli aluksi
hieman ongelmia, sillä ohjelma ei tunnistanut siinä olevia pintoja oikein. Objekti kyllä näkyi mallissa
oikein, mutta siinä oleviin pintoihin ei voinut tarttua kiinni eikä niistä voinut muodostaa
työskentelytasoja. Ongelma saatiin korjattua kun referenssimalli ladattiin Revittiin ns. Mass -objektina.
Tällöin referenssiobjektin muotoa voitiin hyödyntää Revitin omilla mallinnustyökaluilla.
Revit Structure tukee parhaiten 3D Solid tai Region -tyyppiä olevia AutoCAD -objekteja. Joidenkin
objektityyppien, kuten 3D Face, kanssa tuli ongelmia jos DWG -malli päivitettiin Revittiin esimerkiksi
lähtötietomallin muuttumisen seurauksena. Ongelmaksi muodostui se, että lähtötietomallin päivityksen
jälkeen Revit ei enää osannut käyttää kolmiopintoja työskentelytasoina eli referenssimalli ”särkyi”.
Ongelmia aiheutti erityisesti 3D Face tyyppiset AutoCAD -objektit. Vastaavaa ongelmaa ei esiintynyt
3D Solid tai Region -tyyppisillä objekteilla.
Tukimuurien mallintaminen Revitillä onnistui kohtuullisen hyvin (kuva 3). Suurimpia ongelmia
aiheuttivat ohjelman erilaiset virheilmoitukset, jotka ilmenivät erityisesti Void eli
tilavuudenpoistotyökalun yhteydessä. Revit ei aina pystynyt muodostamaan massan poistoa juuri
suunnittelijan haluamaan kohtaan. Ohjelma ilmoitti usein, että geometriaa ei voi luoda tai osien
yhdistäminen särkyy jos geometria luodaan. Virheilmoitukset johtuivat todennäköisesti hyvin
monimutkaisesta tukimuurigeometriasta, joka piti koostaa hyvin monesta päällekkäisestä pursotuksesta.
Virheilmoituksista pääsi usein eroon muokkaamalla esimerkiksi pursotuksen paksuutta millin
ohuemmaksi, jolloin geometriavirheen aiheuttama kohta poistui. Tämä aiheutti hyvin pientä virhettä
lopulliseen muotoon. Mittavirhe on niin pieni että sillä ei ole käytännön merkitystä.
9 (67)
Paikallavalugeometrian mallintamiseen on ohjelmassa erittäin monipuoliset työkalut eikä niihin ole
tämän projektin puitteissa tullut parannustarpeita.
Kuva 3. Revit Structurella mallinnettu tukimuurigeometria.
Varusteet ja laitteet
Tukimuureissa käytetään erilaisia kiinnitysosia valupainetuentaa sekä kuorielementtien nostoa ja
asennusta varten. Kaikki erilaiset kiinnitys- ja nosto-osat täytyi mallintaa ohjelmaan itse, sillä
kiinnitysosavalmistajilla ei ollut valmiina Revit Structureen soveltuvia objekteja. Objektien
mallintaminen on kohtuullisen nopea prosessi eikä se hidastanut kohtuuttomasti mallintamista. Kaikkien
kiinnitysosien mallinnus onnistui hyvin ja niiden lisääminen malliin oli erittäin nopeaa ja kätevää.
Raudoitus
Tukimuurin tietomalliperusteisen suunnitteluprosessin aikana ilmenneistä ongelmista suurin osa liittyi
tavalla tai toisella raudoitukseen. Erityisesti luseeraavien eli lineaarisesti vakioaskelluksin pituuttaan
muuttavien teräsryhmien puute hidastaa raudoitusten mallintamista ja raudoituspiirustusten tekemistä.
Lähes kaikki projektissa mallinnetun tukimuurin teräkset olivat luseeraavia eli tämän ominaisuuden
puute oli merkittävä haittatekijä projektissa.
Paras tapa muodostaa luseeraavat teräkset on mallintaa teräkset ensin täysimittaisina suorakaiteen
muotoiseen objektiin, jolloin teräkset ”tarttuvat” betonin suojapeitteen etäisyydelle ulkopinnasta. Tämän
jälkeen suorakaiteen muotoinen objekti muokataan halutunmuotoiseksi, jolloin siihen mallinnetut
teräkset seuraavat uutta muotoa tietyin rajoituksin. Tätä on havainnollistettu kuvissa 4-6.
10 (67)
Kuva 4. Luseeraavat teräkset on mallinnettu suorakaiteen muotoiseen punaiseen objektiin.
Kuva 5. Objektin muoto muutetaan halutunlaiseksi, jolloin siihen mallinnetut teräkset seuraavat uutta
muotoa.
Kuva 6. Apuna käytetty objekti piilotetaan mallista, jolloin jäljelle jää vain siihen mallinnettu
raudoitus.
11 (67)
Yllä kuvatun raudoituksen mallintaminen aiheutti sen, että tietomalliin täytyi muodostaa paljon
raudotuksen mallintamisen apuna käytettyjä solidiobjekteja. Nämä tilapäiset objektit täytyi poistaa
raudoituksen mallintamisen valmistuttua, jotta ne eivät sotkeneet määräluetteloita.
Revit Structuressa raudoitus mallinnetaan rakenteeseen aina rakenteesta otetun leikkauksen kautta.
Raudoitus lisätään tähän leikkaukseen joko kohtisuoraan leikkausta vastaan tai leikkauksen tasossa. Jos
tukimuurista otetaan kohtisuora leikkaus ja lisätään siihen leikkauksen tasossa oleva raudoitus, niin tämä
raudoitusryhmä kulkee siis aina kohtisuoraan leikkausta vasten. Ohjelma ei vielä versiossa 2012
mahdollista sitä, että raudoitus kulkisi vinossa otettua leikkausta vastaan. Kuvassa 7 ja 8 on esitetty
ongelma. Ainoa keino kiertää tämä ongelma on mallintaa yksi raudoite ja kopioida tätä raudoitusta
Array -komennolla haluttu määrä, kuten kuvassa 9 on tehty. Tämä aiheuttaa sen ongelman että ohjelma
ei osaa laskea näin tehtyjen raudoitustankojen lukumäärää yhteen teräksen positiomerkintää varten, sillä
teräksiä ei ole tehty ryhmitystyökalun avulla.
Kuvassa 8 teräksen positiomerkinnässä lukisi ”30 T12 k200”, missä luku 30 tarkoittaa terästen
lukumäärää ja k200 jakoväliä. Kuvassa 9 mallinnetulla tavalla se olisi ”1 T12 k100”. Ohjelma ei siis
osaa laskea terästen yhteismäärää eikä se tiedä niiden jakoväliä jos ne on kopioitu yksitellen. Ohjelmassa
ei ole työkaluja irtoterästen ryhmittelemiseksi. Array -komennolla kopioitujen teräksen jakoväli on
erittäin vaikea saada oikeaksi, kun teräksiä kopioidaan vinossa pinnassa. Yhden millinkin heitto näkyy
kymmenien kopiointien jälkeen siten, että eri työkaluilla tehty teräkset eivät ole aivan samassa kohdassa
ja mallista tulee sekavan ja epätarkan oloinen.
Kuva 7. Raudoitusryhmä kun leikkaus on otettu pystysuoran tason suhteen.
12 (67)
Kuva 8. Mallinnettua raudoitusryhmää ei saada kulkemaan vinossa tasossa siten, että itse teräkset
olisivat pystysuorassa.
Kuva 9. Ainoa ratkaisu ongelmaan on kopioida yhtä terästä arrray-komennolla haluttu määrää vinoa
viivaa pitkin.
Kaivattuja ominaisuuksia raudoituksen mallintamiseen:
Terästen sijoitteluun pitäisi saada parempia työkaluja. Teräkset pitäisi voida lisätä malliin siten,
että 3D -näkymässä valitaan raudoitettava pinta ja lisätään teräkset sitä kautta malliin.
Leikkausten kautta suoritettava raudoitteiden lisääminen on välillä äärimmäisen hankalaa, jos
geometria ei ole suorakaiteen muotoinen. Kun tukimuurin kolmiopintaan lisätään pinnan
suuntainen teräs, niin leikkauksen, josta teräs lisätään, tulee olla täsmälleen kohtisuora kolmion
pintaa vastaan. Tällaisen leikkauksen tekeminen on monimutkainen operaatio ja se tekee
mallintamisesta työlästä.
Terästen automaattiset jatkospituudet nopeuttaisivat mallintamista merkittävästi.
Irtoteräkset tulisi saada ryhmiteltyä siten, että teräksen positiomerkintä osaa laskea ryhmiteltyjen
terästen yhteislukumäärän sekä ilmoittaa kaikki teräsryhmässä olevien terästen eri jakovälit.
Solideina esitettyjen raudoitustankojen väriä pitäisi voida muuttaa automaattisesti esimerkiksi
teräksen taivutustyypin tai numeron mukaan. Tällöin terästen visuaalinen tarkastelu olisi
havainnollisempaa raudoituksen suunnittelijalle ja muille mallia tarkasteleville tahoille. Tällä
hetkellä ohjelma näyttää kaikki teräkset harmaalla. Soliditeräksen väriä on mahdollista muuttaa
vain muuttamalla teräksen materiaaliomaisuuksia eli materiaalin A500HW väritystä.
Rautalankamallina esitetyn raudoituksen värin vaihtaminen käy helposti, mutta rautalankamalli
ei ole kovinkaan käyttökelpoinen raudoituksen esittämisessä, sillä raudat on kuvattu vain ohuella
viivalla.
Ohjelmaan tulisi saada yhteinen asetus sille, että kaikki teräkset saadaan näkymään 3D-mallissa
solideina. Tällä hetkellä jokaisen teräksen asetuksista täytyy käydä laittamassa solidimalli
erikseen päälle. Tämä on hidasta ja aiheuttaa turhan työvaiheen mallintajalle. Tämä pakottaa
myös hajottamaan kaikki ”Array” -komennolla tehdyt teräsryhmät, sillä muuten niiden asetuksia
ei voi kerralla vaihtaa vaan jokaisen teräksen näkymä pitäisi erikseen muokata.
Terästen tarkasteluun tulisi saada työkalu, joka näyttää suoraan päällekkäin olevat teräspositiot
selkeästi. Ohjelma kyllä varoittaa päällekkäisistä teräksistä niiden luontivaiheessa, mutta jos tätä
ei korjaa saman tien niin päällekkäisiä teräksiä on erittäin vaikea löytää jälkikäteen. Terästen
törmäystarkastelutyökalulla voi nähdä kaikki terästen törmäykset. Tähän työkaluun olisi hyvä
saada erillinen työkalu suoraan päällekkäin olevien terästen löytämiseen.
Solidina esitetyn raudoituksen 3D-mallin näyttäminen on erittäin hidasta kun näytöllä on paljon
raudoitteita. Ohjelman suorituskyky loppuu helposti kesken. Suorituskykyä tulisi parantaa, jotta
13 (67)
ohjelman käyttäminen on mielekästä ja tehokasta. Ongelma ilmenee lähinnä jos käytössä on
”Shaded with Edges” -näyttömoodi.
Betonin suojapeitteeseen päättyvä suora teräs tarttuu välillä liian automaattisesti suojapeitteen
rajaviivaan. Tämä aiheuttaa sen, että teräksen pituutta ei voida käsin pyöristää eli teräspituuksista
tulee välillä liian millimetritarkkoja. Ohjelmaan olisi hyvä saada asetus, jolla voidaan määritellä
terästen pituuden pyöristämistarkkuus halutunlaiseksi.
Raudoituspiirustusten tekeminen
Raudoituspiirustusten tekeminen on Revitillä erittäin työläs ja aikaa vievä tehtävä. Kaikki teräksiä
kuvaavat mittaviivat ja muut merkinnät täytyy tehdä käsin piirustuksiin. Ainoastaan terästen
positiomerkinnän saa tehtyä automatiikalla siten, että ohjelma hakee merkintään teräksen numeron,
halkaisijan, jakovälin yms. Positiomerkinnän toimivuus riippuu teräksen mallintamistavasta. Jos terästä
ei ole tehty ohjelman omalla ryhmitystyökalulla, niin positiomerkinnässä ilmoitettu terästen lukumäärä
ja jakoväli täytyy kirjata käsin teräksen tietoihin, eivätkä ne päivity mallista automaattisesti mallin
muuttuessa. Luseeraavien terästen tietoihin joudutaan siis kirjoittamaan käsin teräksen jakoväli,
lukumäärä, ensimmäisen teräksen pituus, viimeisen teräksen pituus ja teräksen pituuden askelväli eli ns.
delta-arvo (kuva 10). Käsin kirjoitetut merkinnät täytyy muistaa merkitä piirustuksiin hyvin esimerkiksi
erivärisenä tekstinä, jotta suunnittelijan on helpompi havaita käsin tehdyt merkinnät automaattisista
positiomerkinnöistä.
Kuva 10. Suunnittelija joutuu kirjoittamaan käsin luseeraavien teräksen ominaisuuksiin
positiomerkinnässä esitetyt tiedot.
Kuvassa 11 on esitetty luseeraavien terästen ilmoittaminen piirustuksissa. Punaisella tekstillä oleva
merkintä tarkoittaa sitä, että suunnittelija on joutunut itse kirjoittamaan merkinnässä esitetyt tiedot
manuaalisesti teräksen tietoihin. Luseeraavat teräkset joudutaan tekemään irtotangoista. Tästä
mallintamistavasta on nyt hyötyä, sillä osa tangoista voidaan piilottaa näkymästä. Ainakin yksi teräs
täytyy aina näkyä piirustuksessa, jotta positiomerkinnälle voidaan ilmoittaa mistä teräksestä se hakee
näytettävä tiedot.
14 (67)
Kuva 11. Luseeraavien terästen näyttäminen piirustuksissa.
Jos teräkset on tehty ohjelman ryhmitystyökaluilla, niin yksittäisiä teräksiä ei voi piilottaa
raudoituspiirustuksissa sillä teräkset ovat kaikki samaa komponenttia. Tämä vaikeuttaa
raudoituspiirustusten tekemistä sillä piirustuksista tulee helposti epäselviä kun siinä esitettään jokainen
teräs omalla viivallaan. Ongelma on esitetty kuvassa 12.
Kuva 12. Ohjelman raudoitusryhmällä tehdyn raudoituksen esittäminen piirustuksissa.
Terästen ulosvedot täytyy tehdä ohjelmassa täysin manuaalisesti eli suunnittelija joutuu piirtämään käsin
teräksen muodon uudestaan viivatyökalun avulla. Ulosvedossa esitetyt osamitat voidaan kuitenkin
linkittää raudoitukseen siten, että ne tulevat raudoituksesta automaattisesti. Käsin piirretyn ulosvedetyn
teräksen muoto ei kuitenkaan päivity vaikka siinä esitettyjen teräksen osamittojen arvot muuttuisivat
(kuva 13).
15 (67)
Kuva 13. Ulosvedetyn teräksen esittäminen. Ulosveto joudutaan piirtämään käsin.
Revit Structure 2012 versioon tuli terästen taivutustyypin muodostamiseen liittyvä päivitys. Ennen
versiota 2012 ohjelma ei osannut ilmoittaa terästen taivutuksessa käytettyjä kulmaparametria. Tämä oli
erittäin suuri puute, sillä ilman kulmaparametreja terästen oikeaa muotoa ei voida esittää
teräsluetteloissa. Nyt ongelma on kuitenkin korjattu ja teräksen kulmaparametri u on lisätty ohjelmaan.
Ohjelmassa on kuitenkin vakiona sama kulma u myös kulman v paikalla eli käyttäjä joutuu käsin
lisäämään terästyyppien asetuksiin kulman v, jotta ohjelmalla voidaan tehdä sellaisetkin teräkset oikein
missä kulmat u ja v ovat erisuuruisia.
Kuva 14. Muutama esimerkki kulmaparametreja sisältävistä taivutustyypeistä.
Taivutustyypit, joissa on kulmaparametreja v tai u, eivät toimi ongelmitta. Ohjelma ei jostain syystä
anna tehdä teräksiä oikeilla taivutustyypeillä jos kulmat u ja v ovat yli 90°. Teräksen muodon saa kyllä
tehtyä oikeaksi, mutta ohjelmaa muodostaa tällöin uuden taivutustyypin nimeltään esim. ”Rebar shape
1”. Tämä automatiikalla luotu taivutustyyppi ei tunne kulmaparametreja eli niitä ei saa näkymään
myöskään teräsluetteloihin. Kuvassa 15 on esitetty ongelmaa.
Kuva 15. Kuvassa 13 esitetty teräksen tiedot. Ohjelma ei osannut muodostaa terästä oikealla
taivutustyypillä E koska kulma ylitti 90 astetta. Ohjelma muodosti uuden taivutustyypin, joka
ei sisällä kulmaparametreja.
E G
16 (67)
Revittiin on olemassa lisäohjelma jonka avulla raudoituksen numerointi voidaan suorittaa
automaattisesti. Tämä ei kuitenkaan sovellu nyt käytettäväksi, sillä numerointiautomatiikka numeroisi
luseeraavan teräsryhmän jokaisen teräksen omalle positionumerolleen. Numerointi joudutaan siis
suorittamaan käsin.
Raudoitusluettelot
Tukimuurin mallista muodostettu raudoitusluettelo on osittain puutteellinen eikä sitä voida sellaisenaan
käyttää. Luettelossa lukee usean teräksen kohdalla taivutustyyppinä ”Rebar Shape x”. Tämä johtuu siitä,
että ohjelma ei osannut muodostaa oikean muotoista terästä tietyllä taivutustyypillä. Raudoitusluettelo
joudutaan siis tekemään käsin esimerkiksi RL-ohjelmaan.
Kaivattuja ominaisuuksia raudoituspiirusten ja luetteloiden tekemiseen:
Ohjelmaan tarvitaan perustyökalut osoittamaan piirustuksessa olevat raudoitetangot sekä
tekemään automaattiset terästen ulosvedot.
Ohjelma näyttää aina kaikki raudoitusryhmässä olevat teräkset. Tämä tekee raudoituskuvista
sekavia. Parempi tapa olisi näyttää vain yksi teräs ja osoittaa tämän jälkeen mittaviivalla teräksen
jakoalue.
Teräksen positiomerkintään ei saa laitettua luseeraavan teräsryhmän tietoja. Käytännössä
luseeraavan teräsryhmän tiedot täytyy siis kirjoittaa manuaalisesti eikä ne päivity suunnitelmien
muuttuessa.
Terästen taivutustyyppien kanssa on ongelmia. Erityisesti kulmaparametrein varustetut
terästyypit ovat ongelmallisia.
Raudoitusluetteloihin tulisi saada oma merkintä luseeraavalle terästyypille, missä on ilmoitettu
teräsryhmän ensimmäisen ja viimeisen teräksen pituus, terästen lukumäärä ja pituuden
askellusväli. Tällä hetkellä nämä merkinnät täytyy tehdä täysin manuaalisesti, eikä niitä saa siis
päivittymään automaattisesti mallin muuttuessa.
Maaston mallintaminen
Tukimuurien tietomalleihin mallinnettiin nykyinen maanpinta sekä kallionpinta. Nykyinen maanpinta
otettiin suoraan puistosuunnittelijan Civil 3D -mallista ja kallionpinta mallinnettiin käsin käyttäen
hyväksi pohjatutkimuksissa olevia kairaustuloksia. Kairaustulosten avulla jokaisen kairauspisteen
kalliopinnan korko voitiin määritellä ohjelmaan kätevästi. Kallionpinnan korkoa käytettiin hyväksi
erityisesti tukimuurien perustamistasoa määriteltäessä. Myös perustusten vaatimat massanvaihdot
mallinnettiin tietomalliin (kuva 16).
17 (67)
Kuva 16. Revitillä mallinnettuja rakenteita.
Mallin jakelu ja tarkastaminen
Talo- ja teollisuusrakenteiden tietomallit tarkastetaan yleensä IFC-muotoisena. IFC on avoin
tiedonsiirtomuoto ja sen käyttö on järkevää tietomalleja jaettaessa eteenpäin. Revitillä tehtyjä
rakennussuunnitelmatasoisia tietomalleja ei voida kuitenkaan kunnolla tarkastaa IFC-muodossa, sillä
Revit ei vielä tue raudoituksen tallentamista IFC-muotoon.
Revit Structure -mallien tarkastamiseen on olemassa kaksi toimivaa vaihtoehtoa: katselumalli tai
natiivimalli. Katselumallit sisältävät kaiken tietomallin tiedon, mutta ne eivät sisällä sen älykkyyttä.
Katselumallien tiedostomuoto on dwf ja niiden lukemiseen on olemassa ilmainen ohjelma nimeltään
Autodesk Design Review. DWF-tiedosto voi sisältää myös Revitin 2D-piirustuksia. DWF-tiedostomuoto
ei tue erilaisten luetteloiden tekemistä mallista eli sitä ei voi hyödyntää kunnolla työmaalla.
Paras vaihtoehto on käyttää tarkastamiseen ja mallin jakeluun alkuperäisiä Revitin tiedostoja eli malli
avataan Revit Structure -ohjelmalla. Tämä vaatii tietenkin mallin käyttäjältä jonkin verran tietämystä
ohjelman käytöstä, jotta malliin upotettu tieto saadaan esille.
Yhteenveto
Saatujen kokemusten perusteella projektissa päätettiin vaihtaa tietomallinnusohjelmistoa. Revit Structure
ei soveltunut projektin tarpeisiin lähinnä raudoituksessa ilmenneiden ongelmien takia. Projektin
lopullinen rakennussuunnitelma mallinnettiin Tekla Structure -ohjelmistolla.
18 (67)
2.2.2 Tekla Structures -tietomallin luominen – Tukimuurit
Tukimuurien geometrian mallintaminen
Puiston tukimuurit mallinnettiin käyttäen hyväksi useaa eri mallinnusohjelmistoa. Arkkitehti käytti
tukimuurien ulkomuodon suunnitteluun AutoCAD -ohjelmistoa ja suunnitelmat toimitettiin
rakennesuunnittelijalle 3D-DWG-tiedostona. Arkkitehdilta tullut malli sisälsi tukimuurien uloimman
pinnan pintamallin eli elementtien ulkopinnan (kuva 17).
Kuva 17. Arkkitehdin suunnittelema tukimuurin pintamalli ladattuna Revit Structure –ohjelmaan.
Rakennesuunnittelija lähti tämän mallin pohjalta suunnittelemaan tukimuurien muotoa sisälle päin eli
ensin mallinnettiin 150 mm betonielementtiverhoilu ja tämän jälkeen 350 mm paksu varsinaisen
tukimuurien paikallavalu (kuva 18). Rintamuurin ja elementtien väliin jätettiin 120mm ilmarako. Tämä
suunnitteluvaihe mallinnettiin käyttäen joko AutoCAD tai Revit Structure -ohjelmistoa, sillä näissä
ohjelmissa oli paljon monipuolisemmat kolmiulotteisen geometrian mallintamistyökalut kuin Tekla
Structuressa. Lisäksi nämä ohjelmat olivat mallinnustyötä tekeville suunnittelijoille hyvin tuttuja
entuudestaan. AutoCAD ja Revit mahdollistivat muun muassa sen että eri kappaleista muodostetut
objektit voitiin yhdistää samaksi massaksi ilman eri objektien välisiä saumoja. Ohjelmissa oli myös
erittäin monipuoliset pursotustyökalut. Nämä ominaisuudet helpottivat tukimuurien paikallavalun
mallintamista valtavasti. Valmiiksi suunniteltu tukimuuri ladattiin tämän jälkeen Tekla Structures -
ohjelmaan referenssiksi ja se mallinnettiin ohjelmaan uudestaan käyttäen hyväksi valmista 3D-mallia.
Uudelleenmallintaminen oli suhteellisen nopeaa vaikka rakenne olikin monimutkainen. Valmiiksi
suunniteltu muoto mahdollisti sen, että tukimuurien paikallavaluobjekti voitiin mallintaa yhtenä
solidiobjektina ”käänteisesti” eli objektista poistettiin kaikki muu tilavuus paitsi varsinainen rintamuurin
valu. Tukimuuri saatiin tällä tekniikalla mallinnettua yhtenä tilavuusobjektina myös Tekla Structures -
ohjelmaan (kuva 19). Yhtenä tilavuusobjektina mallinnettu kappale näyttää visuaalisesti paremmalta, se
toimii paremmin piirustuspuolella, se on ohjelmalle kevyempi käsitellä ja käyttäjän on helpompi poimia
siitä esim. nurkkapisteiden koordinaatteja. Tukimuurin paikallavaluun mallinnettiin lisäksi kaikki
elementtien kiinnityksessä tarvittavat varauskolot, jälkivalut, kiinnityslevyt ja muurin maanvastaisiin
pintoihin tulevat kosteuseristykset.
19 (67)
Kuva 18. Arkkitehdin pintamallin avulla suunniteltu tukimuuri Revit Structure -ohjelmassa.
Kuva 19. Tekla Structures -ohjelmaan mallinnettu tukimuurin rintamuuri, rivat ja peruslaatta.
Tukimuurin ulkopinnassa olevien betonielementtien välissä on 15 mm ilmarako. Elementtien haastavan
muodon, terävien kulmien ja mittatarkkuusvaatimusten takia elementtien reunoihin suunniteltiin
reunateräs. Reunateräksen tarkoituksena on suojata elementtien teräviä reunoja lohkeamiselta ja taata
elementille konepajatasoinen mittatarkkuus. Reunateräs on käytännössä L-profiilinen teräs, jossa on
harjaterästartunnat rakenteeseen (kuva 20). L-profiilin taivutuskulma vaihtelee sauman sijainnin
mukaisesti välillä 60–130°. Reunateräksen mallintaminen rakenteeseen oli yksi projektin työläimmistä
20 (67)
työvaiheista. Reunateräs tuli mallintaa ja sovittaa jokaiseen reunaan yksitellen riippuen reunan kulmasta.
Lisäksi reunaterästen päät tuli leikata siten, että ne liittyvät toisiinsa jouhevasti ja harjaterästartunnat tuli
taivutella terävissä kulmissa siten, että harjateräkset eivät tule ulos rakenteesta. Reunateräksestä, kuten
monesta muustakin kiinnitysosasta, muodostettiin parametrinen komponentti eli kappaleen mittoja ja
muita ominaisuuksia voitiin helposti muokata erilaisten parametrien avulla (kuvat 21 ja 22).
Kuva 20. Elementtejä kiertävä reunateräs.
21 (67)
Kuva 21. Betonielementtien reunateräksen parametrisoitu komponentti.
22 (67)
Kuva 22. Betonielementtien reunateräksen parametrit.
Ilman parametrisoitua komponenttia reunateräksen mallintaminen olisi ollut monta kertaa hitaampaa ja
vaikeampaa. Erilaisten muutosten tekeminen jälkikäteen, kuten levyn paksuuden tai materiaalin
vaihtaminen, on erittäin nopeaa parametrisoituun komponenttiin. Reunateräksen mallinnuksessa
huomioitiin tulevat valmistustarpeet siten, että mallinnustapa mahdollistaa L-terästen levityskuvien
tekemisen mahdollisiin konepajapiirustuksiin. Kaikkea reunateräksen valmistamisessa tarvittavaa tietoa
ei ollut järkevää mallintaa. Esimerkiksi hitsien mallinnus olisi ollut valtava urakka, kun sama tieto
voidaan esittää yhdessä piirustuksessa. Valmistusta varten tehtiinkin pieni periaatepiirustus, missä on
esitetty reunateräksen valmistuksessa käytettävät hitsit ja muut detaljit. Periaatepiirustus soveltuu koko
projektin kaikkiin reunateräksiin.
Malliin lisättiin myös kaikki elementtien kiinnityksessä tarvittavat kiinnitysosat ja muut varusteet.
Suurin osa kiinnitysosista ja muista varusteista mallinnettiin ohjelmaan itse, sillä vain muutamista
projektissa käytetyistä kiinnitysosista oli saatavissa valmiit TS-komponentit. Kaikki komponentit
mallinnettiin riittävällä tarkkuudella, jotta niiden mahtuminen rakenteeseen ja mahdolliset
yhteentörmäyksen voitin luotettavasti varmistaa mallin avulla (kuva 23).
23 (67)
Elementeissä käytettiin muutamia konepajalla valmistettavia erikoisnosto-osia. Konepajavalmisteisista
nosto-osista tehtiin perinteiset piirustukset, sillä kaikkia nosto-osissa olevia sisäkierteitä, hitsejä yms.
detaljeja ei ollut mahdollista esittää tietomallissa.
Kuva 23. Elementtien reunateräkset ja kiinnitysosat mallinnettuina oikeille paikoilleen.
Betonielementit on pyritty mallintamaan ”BEC2012-Elementtisuunnittelun mallinnusohje” -ohjeen
mukaisesti. Tämä mahdollistaa sen, että elementtitehdas voi hyödyntää tietomallia mahdollisimman
tehokkaasti. Elementeistä voidaan tehdä tarvittaessa piirustukset hyvin nopeasti eli Teklan
betonielementtien piirustuspohjat toimivat hyvin projektin elementeille. Myös erilaisten
määräluetteloiden tekeminen elementeistä onnistuu hyvin käyttäen valmiita Teklasta löytyviä
määräluettelopohjia.
Elementteihin upotettiin paljon valmistuksessa tarvittavaa tietoa. Kaikkea tietoa ei ole kuitenkaan
mahdollista esittää tietomallissa järkevästi. Elementtien asennusdetaljit, nostokaaviot ja työselostus on
tehty perinteisinä dokumentteina. Elementtien varsinainen mittatieto ja käytetyt kiinnitysosat on esitetty
vain tietomallissa. Alla on listattu tietomallin sisältämä betonielementtien tieto:
Elementin geometria (sisältää reikävaraukset)
Kaikki valutarvikkeet (elementin kiinnitys-, ripustus- ja nosto-osat)
o valutarvikkeille on annettu tarkka mallimerkintä ja materiaalitiedot
Elementin pintakäsittelyt (hiottu pinta/pesubetonipinta)
24 (67)
o taustavalun kohdalla oleviin elementteihin on mallinnettu tarvittava bitumisively
elementin takapintaan
Elementin asennusosat (työmaalla asennettavat latta- ja pyöröteräskiinnikkeet)
Elementin betoniteräkset
o Elementistä on helppo tulostaa betoniterästen taivutusluettelo/verkkoluettelo.
Elementin kiinnityksessä tarvittavat jälkivalut
Nostovarausten betonipaikat (sisältää materiaalitiedon, pintakäsittelyt ja tiedon kiinnitystavasta)
Erilaiset valmistuksessa tarvittavat toleranssiluokat, pintakäsittelyt, betonipeitteet,
muotistanostolujuudet yms. (kuva 24)
Elementtien asennusjärjestys
Kuva 24. Betonielementeille annetut attribuuttitiedot.
25 (67)
Kuva 25. Tukimuurin lopullinen tietomalli Tekla Structures -ohjelmassa.
Tukimuurien raudoituksen mallintaminen
Raudoituksen mallintaminen tukimuurien paikallavaluun oli pääsääntöisesti erittäin haastavaa
peruslaattaa ja jäykisteripoja lukuun ottamatta. Haasteet johtuivat rintamuurin vaikeasta geometriasta.
Tukimuurin ulkopinta koostuu pääosin kolmion muotoisista tasoista, joista jokainen on hieman eri
kokoinen ja eri kulmassa toisiinsa nähden. Tukimuurin ulkopinnan kolmiomuodon seurauksena suurin
osa tukimuurin teräksistä on ns. luseeraavia teräsryhmiä. Käytännössä siis lähes jokainen tukimuurin
teräs on erimittainen ja betoniterästen mallintaminen olikin koko projektin suurin yksittäinen
mallinnustyö.
Betoniterästen mallintamisessa käytettiin hyväksi ohjelman mallintamistyökaluja monipuolisesti.
Peruslaatan ja tukimuurin ripojen mallintaminen oli erittäin nopeaa erilaisten raudoitustyökalujen avulla
(kuva 26). Raudoitustyökalut toimivat hyvin laattamaisiin tai palkkimaisiin betonikappaleisiin, joissa on
vakiopaksuus tai poikkileikkaus.
26 (67)
Kuva 26. Peruslaatan ja ripojen raudoitus.
Betoniteräkset voidaan mallintaa Teklaan joko käsin klikkailemalla teräksen muodon taitepisteet ja
jakoväli tai hyödyntämällä erilaisia raudoitusta nopeuttavia aputyökaluja. Betonilaattojen raudoituksen
mallintamiseen tarkoitettu työkalu on tarkoitettu tasapaksujen laattamaisten objektien raudoitukseen eikä
sitä voitu suoraan hyödyntää rintamuurin raudoituksessa, johtuen edellä kuvatusta mallintamistavasta.
Ongelma kierrettiin mallintamalla rintamuurin kolmiopintoihin apulaattoja, joihin voitiin käyttää
raudoitusta nopeuttavia työkaluja. Oikealla apulaattojen mallintamistekniikalla terästys saatiin juuri
oikeaan asentoon eli vaakasuorat teräkset kulkevat täysin vaakasuoraan huolimatta kyseisen pinnan
muodosta tai kaltevuudesta. Apulaattoja hyödyntävä mallintamistekniikka nopeutti raudoituksen
mallintamista huomattavasti, mutta sitä ei voinut hyödyntää kuin tasaisten pintojen luseeraavien
teräsryhmien mallintamisessa. Suurin työ rintamuurien raudoituksen mallintamisessa olikin kaiken muun
paitsi kolmiopintojen teräsryhmien mallintaminen. Rakenne on täynnä erilaisia muodon taiteviivoja ja
geometrialtaan haastavia kohtia, joihin täytyi mallintaa terästen limijatkokset, haat tai pienet teräsryhmät
käsin (kuva 27). Kaiken kaikkiaan tukimuurien paikallavaluihin mallinnettiin noin 2400 eri
teräspositiota. Yhteensä irtoteräksiä on noin 36700 eli keskimäärin teräsryhmän koko on 15 terästä.
27 (67)
Kuva 27. Rintamuurin raudoitusta.
Betonielementtien raudoituksen mallinnus on helppoa verrattuna paikallavalujen raudoituksen
mallinnukseen. Betonielementtien molemmissa pinnoissa käytetään verkkoraudoitusta. Verkot
mallinnettiin elementteihin suoraan koko elementin muotoisena. Suunnittelija ei siis ottanut kantaa
siihen miten suorakaiteen muotoinen verkko kannattaa leikata ja limittää elementissä. Tämä tehtävä
jätettiin betonielementtitehtaalle.
28 (67)
Kuva 28. Raudoitettuja betonielementtejä.
2.2.3 Tekla Structures -tietomallin luominen – Portaat
Projektissa mallinnettiin viisi portaikkoa. Portaiden mallintamisessa käytettiin lähtötietona arkkitehdilta
saatua 3d pintamallia, joka oli tehty AutoCAD:lla. Mallissa oli esitetty porraskivien yläpinta ja
reunapalkin muoto. Malli ladattiin suoraan TS:ään oikeaan koordinaatistoon ja portaiden lopullinen
rakenne saatiin mallinnettua kätevästi referenssimallia hyödyntäen. Portaiden rakenne perustuu HKR:n
tyyppipiirustuksiin. Portaissa on teräsbetonien runko ja graniittiset askelmakivet, joissa kulkee
sulanapitojärjestelmän lämmitysjohto. Portaiden reunalla on reunapalkki, jonka ulkopuolella kulkee
sulanapitojärjestelmän vaatima kaapelikouru.
Kuva 29. Arkkitehdin toimittama portaiden lähtötietomalli ja TS:ään mallinnettu portaiden tietomalli.
Portaat mallinnettiin erittäin tarkasti tietomalliin. Malli sisältää kaiteet, betonivalut, eristelevyt,
betoniraudoituksen, jälkivalut, askelmakivet lämmitysurineen, portaiden vieressä kulkevan
teräsrakenteisen lämmitysjärjestelmän suojakourun, reunapalkin läpi menevät lämmitysjohtojen
varausputket sekä lämmitysjärjestelmän maa-anturin portaissa (kuva 30).
29 (67)
Kuva 30. Portaiden tietomallin detaljiikkaa.
Tietomalli ei sisällä aivan kaikkea portaiden rakentamisessa tarvittavaa tietoa. Tällaista tietoa on
esimerkiksi portaiden valujärjestys, askelmakivien pintakäsittelyohje, kaapelikotelon tiivistyskittaus ja
vaatimus portaiden askelmakaltevuudesta eteenpäin. Portaista tehtiin periaatepiirustus, jossa on selitetty
nämä mallista puuttuvat tiedot (kuva 31). Periaatepiirustuksesta tehtiin tarkoituksella aika
yksityiskohtainen eli siinä on esitetty paljon myös sellaista asiaa, joka ilmenee myös mallista.
Perinteisestä mittapiirustuksesta poiketen periaatepiirustusta ei tarvitse päivittää, vaikka portaiden
muotoa jouduttaisiin muuttamaan. Piirustuksessa on esitetty vain ne asiat, jotka pätevät joka portaalle eli
piirustus on hyvin yleispätevä. Piirustuksessa käy hyvin ilmi kaikki oleellinen rakentamisessa tarvittava
tieto, mitä tietomalli ei sisällä. Jokaisen portaan yksilöllinen mittatieto, betoniterästys ja muu
yksityiskohtainen detaljitieto on saatavissa tietomallista.
Portaiden lämmitysjärjestelmästä on oma suunnitelmansa eikä sitä ole esitetty tietomallissa. Ainoastaan
lämmitysjärjestelmään kuuluva maa-anturi on mallinnettu, sillä se vaatii varauskolon graniittikiveen.
30 (67)
Kuva 31. Ote portaiden periaatepiirustuksesta. Piirustus toimii rakentamisessa mallin tukena.
2.2.4 Tekla Structures -tietomallin luominen – Välimerenkadun silta
Välimerenkadun silta on yksiaukkoinen teräsrakenteinen ristikkosilta, jonka jänneväli on 42 metriä.
Ristikon korkeus ja leveys sekä vastaavasti paarteiden suunnat vaihtelevat murto-viivamaisesti sillan
alueella. Ristikon kaikki sauvat koostuvat putkiprofiileista, joiden nurkkaliitokset muotoillaan
pyöristetyin nurkkalevyin kotelomaisiksi. Ristikon sivu- ja ylätasot ovat tyypillisiä ristikkorakenteita,
alatasossa paarteita yhdistävät vain poikittaispalkit ja niihin liittyvä kansilaatta. Sillassa on
teräsbetoninen päistään haaroittuva kansilaatta.
Lähtötietona mallintamisessa käytettiin sillan pääpiirustusta. Sillan teräsrakenteesta tehtiin ensin
yksinkertainen rautalankamalli. (kuva 32), jonka avulla sillan päämitat voitiin varmistaa luotettavasti.
Rautalankamalli ladattiin tämä jälkeen TS:ään ja sen päälle mallinnettiin varsinainen teräsrakenne (kuva
33).
Kuva 32. Sillan teräsrakenteen rautalankamalli.
31 (67)
Kuva 33. Sillan teräsrakenteen malli TS:ssä.
Sillan teräsrakenteen mallintaminen oli suhteellisen helppoa. Teklassa on ollut jo kauan erittäin
monipuoliset teräsrakenteiden mallintamistyökalut. Haasteellisin mallinnettava rakenne oli
teräsrakenteen nurkissa olevat arkkitehtoniset nurkkapyöristyslevyt. Levyistä tehtiin oma parametrisoitu
komponentti, joka nopeutti mallintamista. Työn aikana nurkkapyöristyslevyjen muotoja jouduttiin
hieman säätämään erinäisistä syistä. Muutosten tekeminen oli kuitenkin nopeaa parametrisoinnin
ansiosta (kuva 34). Myös sillan poikkipalkeista muodostettiin parametrinen komponentti, sillä
poikkipalkin korkeus vaihtelee sillan matkalla.
Kuva 34. Nurkkapyöristyslevyn parametrit.
Teräsrakenteen kokoonpanon muodostamisessa oli hieman ongelmia. Teklassa on monta tapaa
muodostaa teräsrakenteiden kokoonpano riippuen mm. siitä, että halutaanko kokoonpanoon sisällyttää
alikokoonpanoja ja mikä kokoonpano valitaan pääkokoonpanoksi. Kun kokoonpanoa yritettiin
muodostaa tietyllä tavalla, niin TS kaatui joka kerta ilman mitään virhesanomaa. Ohjelma vain sammui
32 (67)
äkillisesti ja viimeisen automaattisen talletuksen jälkeinen työ meni hukkaan. Virheen aiheuttama malli
lähetettiin Teklan kehitystiimille tutkittavaksi ja sieltä ilmeisesti löytyi jonkinlainen virhe. Projektin
myöhemmässä vaiheessa teräsrakenteen kokoonpanoa yritettiin uudestaan muodostaa ja tällä kertaa se
onnistui. Virhe oli joko itsestään lauennut sillan muun muokkauksen yhteydessä tai se oli korjattu
johonkin projektin aikana ohjelmaan asennettuun Service Release päivitykseen.
Sillan teräsrakenteeseen ei mallinnettu hitsejä, sillä TS:ään on vielä erittäin työlästä mallintaa hitsit
oikeaoppisesti, siten että hitsit on esitetty yksiselitteisesti tietomallissa. Sillassa on paljon hitsien
kannalta samanlaisia liitoksia eli ne oli helpointa esittää erillisessä hitsauspiirustuksessa. Kuvassa 35 on
esitetty muutama esimerkkidetalji sillan hitsauspiirustuksesta.
Kuva 35. Esimerkkidetaljeja sillan hitsauspiirustuksesta.
Sillan tietomallista käy ilmi lähes kaikki perinteisissä mittapiirustuksissa esitetyt asiat. Tietomalli
sisältää kaikki kannen eri osien materiaali- ja mittatiedot sekä siltaan kuuluvat varusteet ja laitteet.
Tietomalliin ei ollut kuitenkaan järkevää mallintaa sellaista tietoa, mikä on helpointa esittää
yksinkertaisilla piirustuksilla, mutta mikä olisi erittäin työläs mallintaa. Tietomallin liitteeksi tehtiin
detaljipiirustus, missä on esitetty kaikki ne asiat mitä ei ollut järkevä tai mahdollista esittää tietomallissa
tai mitkä eivät käy mallista hyvin ilmi. Kuvassa 36 on esitetty yksi esimerkki tällaisesta tapauksesta.
Tietomalliin on kyllä mallinnettu sillan päädyn teräspelti ja kermit, mutta esimerkiksi teräspellin
kiinnitystä ei ole mallinnettu eikä objektin sisään ole kirjoitettu kiinnityksessä mitään tietoa. Malliin olisi
voitu mahdollisesti upottaa myös kaikki se tekstitieto, mikä esitetään alla olevassa detaljissa, mutta
asioista ei kannata tehdä tarkoituksella liian vaikeita jos on olemassa helpompikin tapa esittää asia. Jos
tietomalliin haluttaisiin upottaa aivan kaikki rakentamisessa tarvittava tieto, niin ohjelmaan tarvittaisiin
erillinen tätä tarkoitusta varten suunniteltu työkalu. Tällä hetkellä Tekla Structures on suunniteltu
toimimaan lähinnä piirustuspohjaisesti eikä se sovellu vielä pelkän tietomallin avulla rakentamiseen.
33 (67)
Kuva 36. Esimerkkidetaljit sillan päädystä.
Teklan BIMSight tai Autodeskin Navisworks -ohjelmistoissa on mahdollista tallentaa mallin 3D-
näkymiä ja näihin tallennettuihin näkymiin on mahdollista lisätä teksti- ja mittatietoa. Vastaavanlainen
vielä vähän kehittyneempi työkalu olisi erittäin kätevä myös Tekla Structuressa. Tällaisen työkalun
avulla mallin sisään voisi muodostaa näkymiä sellaisista paikoista, joista muuten pitäisi koostaa
detaljipiirustus. Tämäkään työkalu ei varmasti poistaisi kaikkien detaljipiirustusten tarvetta, mutta se
auttaisi mallin hyödyntämistä työmaalla.
Sillan betonikansi mallinnettiin käyttäen hyväksi TS:ään tehtyä ”Beam Extruder” lisäosaa. Lisäosa on
tehty alun perin nimenomaan betonisten sillankansien mallintamiseen. Se käyttää mallintamisessa
lähtötietonaan tien tasausviivan x,y,z –koordinaatteja sekä kannen poikkileikkauksen profiilia. Nämä
tiedot syötetään Excel -taulukkoon, josta ohjelma poimii ne. Ohjelma muodostaa kannen lopulta siten,
että se pursottaa kansiprofiilia suoraviivaisesti kahden annetun pisteen välille. Kannen muoto ei siis
noudata tien tasausviivaa täysin täsmällisesti vaan sen muodostuu käytännössä murtoviivasta. Ero
todelliseen mittaviivaan riippuu siitä, miten tiheästi koordinaatteja on lueteltu Excel -taulukkoon.
Suunnittelijan tulee mallinnettaessa harkita tarkkaan miten tiheällä laattajaolla kansi muodostetaan, jotta
tämä mittavirhe ei ole liian suuri. Jako ei saa myöskään olla liian tiheä sillä mallista tulee muuten liian
raskas ja se vaikeuttaa mallin kanssa työskentelyä.
Mallinnettavan sillan betonikansi muodostuu kahdesta kevyen liikenteen kaistasta, jotka yhtyvät
keskellä ja siltaa ja taas erkanevat (kuva 37). Kumpikin kaista mallinnettiin ensin erikseen ja ne
yhdistettiin lopullisessa rakenteessa yhdeksi valukokoonpanoksi. Mallinnettavan sillan tapauksessa
koordinaatteja annettiin noin metrin välein. Ero teoreettiseen muotoon on tässä tapauksessa
maksimissaan vain muutama millimetri eli sillä ei ole käytännön merkitystä.
34 (67)
Kuva 37. Teklaan mallinnettu betoninen sillankansi.
Tekla on tehnyt paikallavalurakenteiden raudoituksen mallintamiseen erikseen lisäosan nimeltään ”CIP
Reinforcement”. Sen on tarkoitus nopeuttaa esim. sillan betonikannen raudoituksen mallintamista
muodostamalla automaattisesti kannen pituus ja poikkisuuntaisia teräksiä jotka seuraavat kannen
muotoa. Lisäosan avulla voidaan tehdä mm. teräsjonoja määrittelemällä terästen jatkospituuden,
jakovälin ja yhden terästangon maksimipituuden. Normaaleissa silloissa tästä lisäosasta on suuri apu
sillan raudoituksen mallintamisessa. Tätä työkalua ei kuitenkaan voitu käyttää hyödyksi, sillä se toimi
huonosti mallinnettavan sillan tapauksessa johtuen kannen erikoisesta geometriasta. Erityisesti
geometrian jyrkät taitepisteen aiheuttivat ongelmia työkalulle. Kannen raudoitus päätettiinkin mallintaa
käsin käyttäen Teklan perustyökaluja (kuva 38).
Raudoituksen mallintaminen onnistui pääosin hyvin. Suurin työ terästen mallintamisessa on itse
mallinnuksen lisäksi terästen muodon hienosäätö siten, että teräkset saavat juuri oikean taivutustyypin ja
samanlaiset teräkset saavat saman järjestysnumeron. Myös terästen osapituudet ovat usein Teklan
luetteloissa millimetritarkkoja. Tämä aiheuttaa usein pientä hienosäätöä terästen pituuksiin, jos
raudoitusluetteloista halutaan tehdä mahdollisimman selkeitä.
Sillan kansi on hieman pystykaareva koko matkaltaan. Kannen pituussuuntaisia teräksiä ei kuitenkaan
taiteta tähän kaarevuuteen betonitehtaalla vaan ne toimitetaan suorina teräksiä työmaalle. Kaarevat
teräkset mallinnetaan ohjelmaan käytännössä murtoviivoina. Jos murtoviivojen välinen kulma on liian
suuri, niin ohjelma tulkitsee tähän kohteen taitoksen. Tämä ymmärrettävä ominaisuus aiheutti jonkin
verran säätämistä teräksien muodoissa. Lopulta kaikki pituussuuntaiset teräkset saatiin kuitenkin
tunnistautumaan oikein suoriksi terästangoiksi.
Sillan kaarevuus aiheuttaa pientä virhettä Teklan tulostamiin raudoitusluetteloihin. Raudoitusluetteloissa
ilmoitetaan teräksille osapituusmitat ja kokonaispituus L. Suorilla teräksillä osapituusmitan a ja pituuden
L pitäisi olla samoja. Ohjelma laskee kuitenkin osapituusmitan a mitaksi suoran etäisyyden teräksen
alku- ja loppupisteen väliltä. Tästä mittojen erovaisuudesta on maininta tietomalliselostuksessa.
35 (67)
Kuva 38. Raudoitettu betonikansi.
Sillassa käytetään HKR:n kevyenliikenteensillan tyyppikaidetta. Kaiteen tyyppikuvat eivät kuitenkaan
riitä tässä tapauksessa kaiteen valmistamiseen, sillä kaiteessa on kuvan 39 kaltaisia erikoiskohtia. Myös
kaidejako vaihtelee muutamassa kohdassa eli kaiteen verkkoelementit ovat hieman erimittaisia eri
puolilla siltaa. Kaiteesta muodostettiin parametrinen komponentti ja se mallinnettiin täysin mittatarkasti
tietomalliin. Konepaja voi suoraan hyödyntää mallinnettua kaidetta valmistuksessa siten, että
tietomallista katsotaan osien mitat, materiaalit ja pintakäsittelyt, mutta kaiteen tyyppipiirustuksessa on
esitetty kaikki hitsit.
Kuva 39. Mallinnettu HKR:n tyyppipiirustuksen mukainen sillankaide.
36 (67)
Kuvissa 40-42 on esitetty sillan lopullinen tietomalli. Tietomalliin mallinnettiin kaikki sillassa olevat
rakenteet. Malli sisältää myös sillan päällysteen kaikki kerrokset ja asfaltin päälle tulevat
siroitepinnoitteet.
Kuva 40. Sillan liittyminen tukimuuriin.
37 (67)
Kuva 41. Sillan ja tukimuurin rakenteita.
Kuva 42. Sillan liittyminen tukimuuriin tunnelin suuaukon luona.
2.2.5 Tietotekninen ympäristö
Hankkeessa käytettiin seuraavia ohjelmistoja. Tiedonsiirto suunnittelijoiden kesken tehtiin DWG-
tiedostoformaatin avulla. Pääosa suunnittelijoiden välisestä tiedonsiirrosta oli puistosuunnittelijan ja
38 (67)
rakennesuunnittelijan välistä mallien vaihtoa. Malleja vaihdeltiin keskenään, jotta puiston ja kovien
rakenteiden liitoskohdat voitiin tarkastaa.
AutoCAD 2010-2013
AutoCAD -ohjelmistoa käytettiin projektissa jonkin verran perinteisten piirustusten tekemisessä sekä
aputyökaluna erilaisten rakenteiden kolmiulotteisen muodon suunnittelussa. AutoCAD:lla tehdyt 3D-
mallit vietiin DWG-muodossa Tekla Structuresiin.
Autodesk Revit Structure 2012
Revit Structures -tietomalli tehtiin ohjelman versiolla 2012. Revitin mallit tallennettiin DWG-muotoon
kun ne haluttiin ladata referenssiksi Tekla Structureen. Malli olisi voitu siirtää myös IFC-muodossa,
mutta DWG-formaatti oli tässä tapauksessa kevyempi vaihtoehto kun haluttiin siirtää pelkkää 3D-
geometriaa.
Projektin myöhemmässä suunnitteluvaiheessa Revit Structure 2012:lla tehtyä mallia yritettiin avata
myös versiolla 2013, jotta saatiin kokemusta siitä miten malli aukeaa uudemmalla ohjelmistoversiolla.
Uudella versiolla avattaessa mallin geometria särkyi aika pahoin erityisesti elementtien osalta.
Käytännössä version vaihto olisi siis vaatinut aika paljon uudelleenmallintamista.
Tekla Structures 18.0 SR4
Tekla Structures -tietomallin mallintaminen aloitettiin versiolla 17.0, mutta ohjelmistoa vaihdettiin
uudempaan versioon kesken mallintamisen. Ennen ohjelmistonvaihtoa tietomalliin oli ehditty mallintaa
muutaman tukimuurin geometria, mutta raudoituksen mallintaminen oli vasta alkuvaiheessa.
Ohjelmistoversion vaihtaminen onnistui täysin ilman ongelmia sillä tietomalli ei sisältänyt piirustuksia
tai ohjelmiston sisäisiä liitoskomponentteja, jotka eivät välttämättä toimisi uudemmilla versioilla.
Kesken mallinnustyön Tekla Structuresiin asennettiin aina uusin Service Release (SR) päivitys. SR
päivityksen ei pitäisi vaikuttaa mallin toimintaan eli sen asentamisen pitäisi olla turvallista. Kuitenkin
versiossa SR3 oli tullut muutos, joka poisti betonielementtien attribuuttitietoja. Muutokset liittyivät
betonielementtiteollisuuden BEC2012 (lisätietoja www.elementtisuunnittelu.fi) projektiin eli TS:n
suomiympäristöä oli kehitetty toimimaan paremmin betonielementtiteollisuuden tietomalleja ajatellen.
Mallissa olevien betonirakenteiden kannalta keskeinen poistettu ominaisuus oli betonin P-luku. Poistoa
perusteltiin Teklan puolesta sillä, että betonielementtitehdas määrittelee talo-/teollisuurakenteissa aina P-
luvun. Teklalle annettiin asiasta palautetta että siltasuunnittelijat määrittelevät aina itse betonin P-luvun
ja tämä attribuuttieto pitäisi saada takaisin ohjelman suomiympäristöön. Teklalta saatiin ohje, että miten
nämä attribuuttitiedot saadaan takaisin malliin muokkaamalla TS:n objects.inp -tiedostoa.
Projektin urakkalaskenta ja rakentamisvaiheen tarkkaa aikataulua ei ole vielä selvillä, mutta
todennäköisesti rakentaminen aloitetaan aikaisintaan vuonna 2015. Siihen mennessä Tekla Structuresta
on voinut tulla jo pari uudempaa versiota. Tekla ei suosittele ohjelmistoversion vaihtamista kesken
projektin. Tässä projektissa tietomalli saatetaankin kuitenkin tulevaisuudessa päivittää tukemaan
uudempaa ohjelmistoversiota, jos ohjelmaan on tullut niin hyviä uusia työkaluja, että päivittäminen
kannattaa. Version vaihto tapahtuu siten, että malli yksinkertaisesti avataan uudemmalla
ohjelmistoversiolla ja tallennetaan. Jos ohjelmaan ei tule mitään suurempia muutoksia, niin mallin
päivittäminen uudempaan versioon saattaa onnistua. Nykyistä versiolla 18.0 tehtyä mallia on kokeiltu
avata myös versiolla 18.1 ja 19.0. Versiolla 18.1 malli aukeaa, mutta muutaman elementin ja
paikallavaluobjektin geometria on rikki. Nämä virheet johtuvat todennäköisesti päällekkäisistä
leikkaustasoista ja ne on helppo korjata. Versiolla 19.0 malli ei aukea ollenkaan vaan TS kaatuu mallin
39 (67)
avaamisvaiheessa. Tämä ei kuitenkaan välttämättä tarkoita että mallia ei saada auki versiolla 19.0 vaan
asia vaatisi tarkempaa tutkimista.
Autodesk Navisworks Simulate 2013
Autodesk Civil 3D:llä tehty puistomalli ja Tekla Structures -malli yhdistettiin Navisworks Simulate
2013 -ohjelmistolla. Navisworks -ohjelmistoon päädyttiin siitä syystä, että ohjelma tuki monipuolisesti
erilaisia tiedostoformaatteja. Civil 3D -ohjelmasta saatiin suoraan exportattua malli navisworksiin siten,
että malli sisälsi objektien parametritietoja.
Yhdistelmämallia varten Tekla Structures -malli tallennettiin DWG-muotoon, sillä tavoitteena oli saada
vain geometria siirtymään yhdistelmämalliin. DWG-formaatin mukana siirtyy vain geometria eli
objekteilla ei ole nimeä tai materiaalimerkintää. Mallin tarkastajilta tulleiden kommenttien perusteella
päädyttin kuitenkin siirtämään Tekla Structures malli IFC-muodossa yhdistelmämalliin. Tästä on se etu
että IFC-mallin mukana siirtyy suuri määrä erilaista tietoa, josta voi olla hyötyä myös
yhdistelmämallissa. IFC-mallin muodostaminen TS:llä ei ollut aivan ongelmatonta. IFC-malli pitää
muodostaa Teklassa käyttämällä asetusta ”Coordination View”. Kaikilla muilla tavoilla muodostettu
malli ei ollut geometrialtaan ehjä.
2.2.6 Prosessikuvaus
Kuva 43. Hankkeen prosessikaavio.
2.2.7 Nimikkeistöt ja ohjeet
Silloille on olemassa oma Liikenneviraston teettämä ”Siltojen tietomalliohje”, jota käytettiin soveltuvin
osin myös tässä projektissa. Tietomalliohje ei soveltunut projektin tarpeisiin, sillä ohje on tehty
perinteisiä tietomalleja varten, joista tuotetaan piirustukset ja määräluettelot työmaata ja urakkalaskentaa
varten. Tässä projektissa oli tavoitteena tehdä erittäin yksityiskohtainen tietomalli, jotta piirustustarve
voitaisiin minimoida. Tämänkaltaisen tietomallin tekemiseen ei ole vielä saatavilla ohjeistusta.
Tietomallin koostaminen
Ponvia OyRakennesuunnittelu
Tekla Structures
Rakennesuunnittelu
Ponvia OyRakennesuunnittelu
AutoCAD, FEM
Tukimuurien alustava 3d-
mallinnus
Ponvia OyRakennesuunnittelu
AutoCAD, Revit Structure
3D-dwg
Puistosuunnittelu
VSU OyPuistosuunnittelu
AutoCAD
Puiston tietomalli
VSU OyPuistosuunnittelu
AutoCAD Civil 3D
2D-dwg
3D-dwg
Tien, tasausten ja kuivatuksen suunnittelu
Plaana Oy Väyläsuunnittelu
Tekla Civil 3D-dwg
Olevassa olevan maanpinnan mittaus
Maastomittaus
Mittausdata
3D-dwg
Mallien yhdistäminen
Ponvia Oy
Navisworks
Ohjelman sisäinen muunnos
IFC
Tukimuurien ja siltojen arkkitehtuurin suunnittelu
VSU OyArkkitehtisuunnittelu
AutoCAD
3D-dwg
Kalliopinnan tulkinta kairaustuloksista
Geotutkimukset
Mittausdata
2D-dwg
Pohjarakennesuun-nittelu
AutoCAD
Geobotnia OyGeosuunnittelu
3D-dwg
2D-dwg
2D-dwg
2D-dwg
3D-dwg
3D-dwg
40 (67)
Tietomallin mukana toimitetaan tietomalliselostus. Tietomalliselostus toimii käyttöohjeena tietomallin
käyttäjälle. Tietomalliselostuksesta käy hyvin ilmi mitä tietomalli sisältää ja mikä on mallinnettujen
rakenteiden valmiusaste. Siinä on myös selitetty mitkä asiat on jätetty mallintamatta. Ohjeessa on
opastettu malliin tallennettujen näkymäsuodattimien käyttäminen ja muut perustiedot kuten käytetty
koordinaatisto ja korkeusjärjestelmä.
Tietomalliselostuksen liitteenä on toimitettu projektissa käytetty numerointi-/nimeämisohje. Tekla
Structureen ei ollut saatavilla valmista numerointi-/nimeämisohjetta, joka olisi soveltunut projektin
tarpeisiin. Projektissa tehtiin uusi numerointi-/nimeämismenetelmä, joka pohjautui 5DSilta -projektissa
tehtyyn ohjeeseen. Ohjetta täydennettiin ja sitä muokattiin projektin tarpeita vastaavaksi.
Huolellinen mallin jäsentely on ensisijaisen tärkeää ja se tulee pitää mielessä mallintamistyötä tehtäessä.
Mitä enemmän malli sisältää objekteja sen tärkeämmäksi tämä asia tulee. Tietomalli sisältää usein niin
paljon objekteja, että mallin näkymää joudutaan karsimaan, jotta se ei olisi liian sekava. Mallin näkymä-
ja valintasuodattimien sekä luetteloiden ja piirustusten muodostamissa hyödynnetään käytettyä
numerionti-/nimeämisjärjestelmää. Mallia onkin erittäin vaikea hyödyntää jos objekteja ei ole numeroitu
ja nimetty tietyn logiikan mukaisesti. Teklassa mallin nimeäminen perustuu objektin nimeen, class -
numeroon ja prefixiin eli numeroinnin etuliitteeseen. Kuvassa 44 on esitetty esimerkkinä
taidetukimuurien rakenneosien numerointi. Taulukossa on esitetty objektin nimi, class ja prefix (Cast
unit -sarake) sekä taulukon käyttäjälle selvennyksenä rakenneosan koko nimi.
Kuva 44. Esimerkki projektissa käytetystä numerointi-/nimeämisohjeesta.
Tietomalliselostuksen toisena liitteenä on dokumentti nimeltään ”HTP-INFRARYL 2006 litterointi”.
Tämä dokumentti on erittäin hyödyllinen projektin urakkalaskentavaiheessa. Dokumentti kertoo
määrälaskijalle, että mistä tietomallin objektista on saatavissa tietyn InfraRYL -litteran mukainen määrä.
Dokumentissa on kerrottu yksityiskohtaisesti tiettyä litteraa vastaavan objektin tyyppi, nimi, prefix ja
class -numero. Dokumentti toimii samalla myös mallin sisällysluettelona eli siinä on lueteltuna
käytännössä kaikki mallin sisältämät rakenneosat ja komponentit.
Kuvassa 45 on esitetty osa taulukkoa. Kuvasta nähdään, että esimerkiksi tukimuurien peruslaattojen
betonimäärä saadaan litteran ”4407:4” riviltä. Taulukosta nähdään, että haluttu betonikuutiomäärä
saadaan mitattua objektista, jonka nimi on ”PERUSLAATTA” ja Class on 201. Taulukossa on myös
kerrottu objektin tyyppi ja käytetty prefix -tunnus. Näitä tietoja käytetään hyväksi muodostettaessa
näkymäsuodinta, valintasuodatinta tai määrälaskentataulukkoa.
Nimi Class Cast unit Rakenneosa Huom.
PERUSTUKSET JA RUNKORAKENTEET 201-210 x = kyseinen tukimuurin nro (1-9)
PERUSLAATTA 201 xPL Peruslaatta
RINTAMUURI 202 xRM Rintamuuri
JÄYKISTYSRIPA 203 xJR Jäykistysripa
LAAKERIALUSTA 204 xLA Laakerialusta
KALLISTUSVALU 205 xPL Peruslaatan kallistusvalu
LAATTA 206 xL Muu laattarakenne
ELEMENTIT 211-221
pKUORIELEMENTTI 211 xKE-P Kuorielementti, pesubetonipinta
hKUORIELEMENTTI 212 xKE-H Kuorielementti, hiottu+kiillotettu pinta
pTaKUORIELEMENTTI 213 xAKE-P Taittuva kuorielementti, pesubetonipinta
hTaKUORIELEMENTTI 214 xAKE-H Taittuva kuorielementti, hiottu+kiillotettu pinta
KUORIELEMENTTI 215 xKE Kuorielementti, valupinta
MUUT BETONIVALUT 221-279
JUOTOSVALU 254 JV Jälkivalu, juotosvalu
BETONIPAIKKA 255 BP Elementtien reikien paikkaus porakappaleella
TÄYTEVALU 256 TV Elementin ja runkobetonin välinen betonivalu
VARUSTEET JA LAITTEET 280-340
SIIRTYMÄLAATTA 281 VL Siirtymälaatta
MUUT RAKENTEET
KERMIERISTYS 252 KE Kermieristys
KOSTEUSERISTYS 4 Tukimuurin takapinnan kosteuseritys Surface Treatment
BITUMISIVELY 5 Elementtien takapinnan bitumisively Surface Treatment
PINTAKÄSITTELYT
B_HIONTA 6 Hiottu+kiillotettu pinta Surface Treatment
B_PESUBETONI 5 Pesubetonipinta Surface Treatment
Taid
etu
kim
uu
rit
(ph
ase
1-9)
41 (67)
Taulukon muodostaminen mallinnetuista objekteista on työläs operaatio ja siinä menee helposti
muutama päivä aikaa. Projektissa ei kuitenkaan löydetty mitään järkevämpää tapaa linkittää Infraryl –
litteroita mallinnettuihin objekteihin. Toinen vaihtoehto olisi ollut syöttää Infaryl -littera esimerkiksi
jokaisen objektin ns. UDA (User Defined Attributes) kenttään sopivalle riville. Tämä olisi ollut
kuitenkin hieman ongelmallista, sillä eri objekteilla on erilaiset UDA-kentät ja käyttäjä ei pääse
kovinkaan nopeasti selville siitä mitä kaikkea tietoa malli sisältää, jos siitä ei ole tehty valmista listausta.
Perinteinen paperille valmiiksi tehty mallin ”sisällysluettelo” nähtiin tässä projektissa järkevänä
esitystapana.
Kuva 45. Esimerkki projektissa käytetystä InfraRYL 2006 määrälaskentaohjeesta.
2.3 Tietomallin ulkopuolinen tarkastus
Tietomallin valmistuttua se annettiin ulkopuolisen konsultin tarkastettavaksi. Tarkastajana toimi WSP
Finland Oy. Ulkopuolisen tarkastajan tehtävänä oli rakenneteknisen tarkastamisen lisäksi varmistaa, että
urakkalaskenta voidaan suorittaa tietomallipohjaisesti.
Määrälaskenta haluttiin tehdä ulkopuolisella taholla, sillä tällä tavoin voidaan varmistua siitä, että mallit
on rakennettu loogisesti ja mallien mukana toimitettava ohjeistus on riittävän kattavaa määrälaskennan
suorittamiseksi.
Tarkastus suoritettiin käytännössä siten, että suunnittelija ja ulkopuolinen konsultti tekivät toisistaan
riippumattomat määrälaskennat ja näitä verrattiin toisiinsa.
Tekla Structures -tietomallista tehdyt määräluettelot vastasivat hyvin toisiaan. Luetteloissa oli jonkin
verran eroavaisuuksia. Eroavaisuudet johtuivat määrälaskijan inhimillisestä virheestä tai mallissa
olevista virheistä. Kaikki eroavaisuudet käytiin läpi ja lopulta luettelot saatiin vastaamaan toisiaan.
Tarkastuksessa löytyneet mallin virheet korjattiin ja tietomalliselostukseen kirjattiin tarpeellista
lisäohjeistusta.
Civil 3d -mallin tarkastamisessa nousi esiin mm. seuraavat asiat:
- Rakentamisen vaiheistusta ei ole esitetty mallissa
42 (67)
- Mallissa aiheuttaa epäselvyyttä se, että ettei ole tiedossa tarkkaan miten ympäristö ja maanalaiset
tilat tulevat rakentumaan ja miten ne tulevat vaikuttamaan jatkossa suunnitteluratkaisuihin.
- Mallipohjaisen koneohjauksen huomiointi suunnitelmissa jäi vähäiselle huomiolle.
- Mallin kattavuudessa on ristiriitaa sen osalta, että merkitykseltään pienet pintamallit ja
tilavuusobjektit on mallinnettu tarkasti, mutta suuremmat täytöt on osittain mallinnettu
puutteellisesti.
- Civil 3d:ssa on puutteita, jotka voivat olla urakoitsijan näkökulmasta merkittäviä.
o Ohjelman hitaus ja häiriöherkkyys tuli tarkastuksessa esille
o Ohjelma toimii hitaasti jos kaikki osamallit esitetään yhtä aikaa
o Navisworks –katselumallista oli suurta apua, sillä malli pyöri tällä ohjelmalla sulavasti ja
leikkausnäkymien tekeminen, objektien haku- ja valintatoiminnot sekä näkyvyyden
säätely onnistuivat nopeasti.
o Civil 3d:lla ei pysty tekemään kaivokortteja.
- Tietomalliselostuksessa tulisi ilmetä miten suunnitelmamuutokset tulisi esittää.
- Tietomalliselostuksen liittenä olevat Pintamalliat ja nimeämien –taulukko, jossa on esitetty
kaikki mallin osiot on tarpeellinen ”avain ” Civil 3D malliin. Taulukon rakenne on selkä ja
helposti luettava. Käyttäjä pystyi omaksumaan nopeasti alueiden, objektien ja materiaalien
lyhenteet ja numeroinnit, joiden avulla mallin selaaminen onnistui hyvin.
- Määrien vertailussa oli huomattavia eroja. Erot johtuivat lähinnä erilaisista virheistä
maakerrosten mallinnuksessa.
-
Tarkastuksessa löydetyt virheet korjattiin malliin ja malliselostusta täydennettiin puuttuvilta osin.
2.4 Johtopäätökset
2.4.1 Havaitut hyödyt ja ongelmat, edistysaskeleet ja kehitystarpeet.
Projektissa luotiin erittäin kattava tietomalli, joka sisältää rakenteiden geometrian, materiaalitiedon ja
paljon muutakin rakenteelle oleellista tietoa. Projektissa keskeiseksi ongelmaksi muodostui perinteisissä
piirustuksissa esitetyn tiedon upottaminen malliin siten, että se on mallin käyttäjälle helposti saatavilla.
Tähän tarkoitukseen Tekla Structures -ohjelmassa ei ole vielä olemassa sopivia työkaluja. Tietyistä
rakenneosista jouduttiin tekemään tietomallia täydentävät 2D-piirustukset, sillä kaikkea tietoa ei saatu
syötettyä järkevästi tietomalliin. Tällaisia piirustuksia ovat mm. sillasta tehty hitsauspiirustus,
yleispiirustus ja detaljit. Tietyistä rakenteista luotiin myös yleispäteviä periaatepiirustuksia, jotka
toimivat tietomallin tukena. Näissä piirustuksissa on esitetty sellaisia asioita, joita ei voitu helposti
syöttää tietomalliin, kuten erilaiset detaljit ja työtapaohjeet. Tietomalli on ensisijainen tietolähde ja nämä
piirustukset toimivat mallin tukena. Piirustukset on tehty sillä periaatteella, että rakenteen geometrian
muuttaminen ei vaikuta näihin piirustuksin eli ne eivät vaadi päivittämistä yhtä paljon kuin perinteiset
piirustukset. Projektin urakkalaskenta saadaan hyvin todennäköisesti suoritettua pelkästään tietomallin,
työselostusten ja näiden periaatepiirustusten avulla, mutta siitä ei ole vielä kokemuksia miten
rakentaminen onnistuisi pelkästään tietomallin avulla.
Tekla Structures -ohjelma ei tue maamassojen mallintamista eli kaikki tukimuurien massalaskentaan
kuuluvat täytöt ja kaivuut mallinnettiin Autodesk Civil 3D -ohjelmalla tehtyyn puistomalliin. Tämä on
iso puute, sillä olisi loogista, että kaikki rakenteeseen kuuluvat määrät olisi laskettavissa samasta
tietomallista.
Alan yhteisissä käytännöissä ja ohjelmistoissa tarvitaan vielä paljon kehitystyötä, jotta päästää siihen
tavoitteeseen, että projektit voidaan toteuttaa suunnittelusta rakentamiseen pelkän tietomallin avulla.
Ongelmia aiheuttavat tällä hetkellä lähinnä puutteellinen ohjeistus, erilaiset käytännöt ja ohjelmistojen
puutteet.
43 (67)
Mallintamiseen liittyvät ongelmat liittyvät Tekla Structures -ohjelman ominaisuuksiin. Ohjelma ei vielä
täysin sovellu siihen tarkoitukseen, mihin sitä yritettiin käyttää. Ohjelmaan tarvitaan vielä paljon
lisäominaisuuksia, jos kaikki piirustuksissa esitetty tieto haluttaan näyttää vain tietomallissa siten että se
on käyttäjälle helposti ja havainnollisesti saatavilla.
Pilottiprojektin on ollut pitkä ja opettavainen prosessi niin tilaajalle kuin suunnittelijalle. Projektista
saatiin ja saadaan edelleen paljon uutta tietoa vastaavanlaisen tietomalliprojektin toteuttamiseen.
Projektissa havaittiin, että yksityiskohtainen mallintaminen vie paljon aikaa ja erityisesti
mallintamistarkkuuden määrittäminen heti projektin alussa olisi erittäin tärkeää.
2.4.2 Tietomallintamisen haasteellisuuden arviointi /Arviointisabluuna
ks. liite D.
2.4.3 Jatkotoimenpiteet
Projekti jatkuu tulevaisuudessa urakkalaskennalla ja lopulta varsinaisella rakentamisvaiheella.
Urakkalaskenta voidaan näillä näkymin suorittaa suunnitellusti tietomallipohjaisesti, mutta vielä on
epäselvää, että miten mallia tullaan hyödyntämään rakentamisvaiheessa. Todennäköisesti mallista
joudutaan koostamaan erilaisia piirustuksia ainakin elementtitehdasta ja konepajaa varten, mutta
tarkempi esitystapa selviää vasta tulevaisuudessa.
Mallista ei vielä kannata tehdä lopullisia piirustuksia sillä puiston ympäristö elää jatkuvasti ja malliin
joudutaan tekemään pieniä muutoksia jatkuvasti. Muutosten tekeminen on sitä joustavampaa mitä
vähemmän tietomallista on tehty erilaisia piirustuksia ja luetteloita.
3 Puiston tietomalli
3.1 Tavoitteet
Hyväntoivonpuiston tietomallihankkeen 1. vaiheessa on puistosta laadittu kolme erillistä tietomallia:
nk. purkumalli purettaville rakenneosille ja kaivutöille Selkämerenpuiston eteläosaan,
rakentamisen tietomalli Selkämerenpuiston eteläosaan ja
rakentamisen tietomalli Hyväntoivonpuiston pohjoisosaan.
Hankkeen tavoitteena on ollut laatia niin kattava tietomalli puiston rakentamista varten kun se nykyisillä
ohjelmistoilla ja tietotaidolla on mahdollista. Tässä hankkeessa tietomallin avulla pyritään jatkossa
laskemaan myös urakat ja toteuttamaan kohde.
3.1.1 Pilotoidut asiat
Puistosta laadittu tietomalli on laajuudeltaan yksi kattavimmista, ellei kattavin tällä hetkellä tehdyistä
puiston tietomalleista Suomessa. Taitorakenteet on mallinnettu samanaikaisesti puiston kanssa.
Itse puisto on jo sinänsä pilottiasemassa sen monipuolisuuden ja monimuotoisuuden vuoksi. Puisto
rakennetaan suurimmilta osin entiselle satamakentälle. Puiston maanpinta tulee olemaan n. 3-8 m
korkeudella satamakentästä. Puiston alla on runsaasti erilaisia toimintoja: mm. huoltotunneli
maanalaisiin tiloihin, pysäköintilaitos, jäteasema, pilaantuneiden maiden läjitysalue. Maanalaiset tilat
esitetään tietomallissa pintoina. Tukimuurien perustuksia ja sadevesijärjestelmiä varten tehdään
kalliolouhintaa. Puisto rajautuu miltei kaikkialta uudisrakennusten perustuksiin tai kellarikerroksiin,
jotka toteutetaan paikoitellen samanaikaisesti puiston kanssa.
Hankkeessa on luotu uutena
Futurecad Oy
pinnan nosto/pudotus -skripti ohjelmaan lisäksi (ei käytetty)
kaivot ja putket objektien muokkaus tarvetta vastaavaksi (käytetty)
VSU Oy
litterointi infraRYL:n mukaan ja nimeäminen QTO (käytetty)
multiview -blokkeja määrityksineen
materiaalien ilmaisutapa, description -kentän käyttö
näyttötyylit, pinnat näkyvät eri tavoin 3D:ssä ja 2D:ssä
työtapa, pintojen kiinnitys malliin
aineiston jakaminen, kaikki osamallit kiinnitetty koontimalliin
3.2 Pilotin dokumentointi
3.2.1 Civil 3D -ohjelmiston soveltuvuus puiston tietomallintamiseen
Puiston tietomalli on laadittu Autodesk Civil 3D -ohjelmistolla, jonka soveltuvuudesta
viherrakentamisen tietomallintamiseen haluttiin kokemuksia. Tavoitteena oli mallintaa
puistosuunnitelmaan kuuluvat rakenneosat. Näitä ovat eri pinnoitteet ja kasvialueet,
maarakennekerrokset, kalusteet ja varusteet, lähtötilanne purettavine rakenteineen ja nykyisen maan
kaivut. Suunnitelmaan kuuluvat taitorakenteet on tehnyt Ponvia Oy Tekla Structures -ohjelmalla.
45 (67)
Civil 3D -ohjelma soveltuu kohtalaisen hyvin puiston tietomallin laatimiseen. Sen hyviä puolia ovat
seuraavat: tasauksen luominen on luontevaa, tilavuuksien tarkastelu on helppoa ja mallista saatava
määrälaskenta on vaivatonta. Haasteita puolestaan on ollut rakennekerrosten luomisessa (ei ole omaa
työkalua), jos ei pystytä käyttämään väylämallinnustyökalua (soveltuu yksinkertaiselle geometrialle)
sekä mallien tiedostokoon hallinta. Ohjelman käyttölogiikka on suhteellisen monimutkainen sisäistää.
3.2.2 Prosessin kulku
Mittausaineisto
Puistomallissa on käytetty hyväksi mittausaineistoa ja keilausaineistoa. Mittausaineistosta rakennettiin
mallin lähtötilanne. Mallissa on tiedot kaikista purettavista rakenteista. Selkämerenpuiston eteläosan
alue laserkeilattiin projektin aikana ja saatua aineistoa hyödynnettiin mallintamisessa.
Keilausaineisto on hyödyllinen lisä mallintamiseen. Pistepilvi muodostaa havainnollistavan
kokonaisuuden mitatusta alueesta, jota on mahdollista katsoa 3D-tilassa. Värillisestä pistepilvestä
näkyivät maanpinnan korkeusvaihtelujen lisäksi rakennukset, kasvillisuuden paikat ja viitteellisesti
kulkureittien materiaalit.
Keilausaineiston hyödyntämisessä Civil 3D 2012 versiossa oli ongelmia. Ohjelmassa ei ollut mahdollista
suodattaa pisteitä, jolloin mittaustilanteessa olleet ylimääräisten kappaleiden korkotiedot (kuten autot,
ihmiset yms.) vaikeuttivat aineiston käyttöä. Ohjelman myöhemmissä versioissa on tullut
mahdollisuuksia pistepilvien suodattamiseen. Ohjelman käytettävyyttä heikensi pistepilven muodostama
raskas tiedosto ja sen seurauksena ohjelman virheilmoitukset ja työnteon hidastuminen. Mallinteon
sujuvuuden vuoksi on tärkeää työstää valmiiksi hyvin suodatettu laser-aineisto.
Purkumalli
Selkämerenpuiston eteläosan nykyinen tilanne mallinnettiin ja rakentamista varten purettavat osat
koostettiin omaan malliin. Malliin lisättiin kaivut nykyisestä maanpinnasta alaspäin. Näiden rajapinnat
saatiin jo mallinnetuista rakenneosista. Mallin geometrian muodostamista haittasi pisteaineiston käyttö,
sillä kaivualueiden pisteiden poisto vaati tarkkaavaisuutta. Kaivualueille jääneet pistetiedot johtivat
virheelliseen geometriaan.
Purkumallia tehdessä suunnittelualueen raja jouduttiin ylittämään, sillä maanalaiset kaivut ja
rakennekerrokset ylittyvät perinteisiin piirustuksiin asetetut rajat.
Säilytettävät ja purettavat objektit, kuten esimerkiksi puut, valaisimet ja pollarit, on esitetty mallissa
multiview -blokkeina, joiden ominaisuudet on määritetty QTO -määrälaskennalla. Purettavat reunakivet
on tehty väylämallintamisen työkalulla.
Purkumallista kävi ilmi, että osa objekteista oli kadonnut mallin päivittämisen yhteydessä., sillä
viimeiseen tallentamiseen oli käytetty uudempaa ohjelmistoversiota. Myös multiview -blokkien
käyttämät 3D-objektit saattavat olla joko liian pieniä tai ylisuuria kun objekti kopioidaan toiseen
tiedostoon. Blokkien toiminnan korjaaminen vaati ylimääräistä työtä. Tätä ei osattu ennakoida kun
käytettiin uutta ohjelmistoversiota.
Maaston mallintaminen
Puiston tietomalleihin mallinnettiin nykyinen maanpinta sekä kallionpinta lähtötiedoiksi.
Selkämerenpuiston kohdalta mallinnettiin myös purettavat pinta-alueet, puut sekä kalusteet ja varusteet.
Nykyinen maanpinta tehtiin mittausaineiston pohjalta, Selkämerenpuiston kohdalta hyödynnettiin
keilausaineistoa. Kallionpinta mallinnettiin mittausaineiston mukaan maanpäällisiltä alueilta,
maanalaisen kalliopinnan mallintamisessa käytettiin hyväksi kairaustietojen perusteella tehtyä
46 (67)
kolmiopintaa. Kalliopinnan korkoa tarvittiin mallinnettaessa maarakennekerroksien liittymisiä kallion
ollessa lähellä maanpintaa.
Geometrian hallinta
Puistomalli tehtiin jokaiselta rakenneosalta omaan tiedostoon, jotta mallintaminen pysyi selkeänä.
Hankkeessa kehitettiin tähän kohteeseen soveltuva nimeämisjärjestelmä. Mallinosien nimeäminen on
tehty käyttämällä InfraRYL -litterointia, lyhenteitä ja aluetunnusta. Käytetty nimeämiskäytäntö poikkeaa
InfraFINBIM -nimistöstä, sillä työn alkuvaiheessa sovittiin tilaajan kanssa InfraRYL -nimikkeistön
käytöstä. Nimeämisellä on pyritty saamaan samat rakenneosat helposti hahmotettavaan järjestykseen
mallin prospector -listassa.
Puiston osamallit linkitettiin data shortcut -ominaisuudella koontimalliin, jossa osamalleille annettiin
ominaisuustiedot. Luovutettu on tehty siten, että data shortcut -linkit on kiinnitetty tiedostoon. Tällä
varmistetaan, että osamalleja ei jää puuttumaan koontitiedostosta siirrettäessä tiedostokokonaisuuksia
koneelta toiselle. Mallintamisen aikana data shortcut -linkkien toiminnassa ilmeni ongelmia
päivittyvyyden ja häviämisen kanssa. Tietyt osamallit saattoivat jäädä pois koontimallista, vaikka ne
olivat siihen lisättyinä. Linkkien synkronointi ei tuonut puuttuvia tiedostoja takaisin, vaan osamallin
alkuperäistä tiedostoa jouduttiin muokkaamaan ja tallentamaan uudelleen, jotta se palasi takaisin
koontimalliin. Useita osamalleja sisältävän tiedoston kohdalla linkitettyjen mallien pois jääminen on
ongelmallista, sillä niiden puuttuminen tiedostosta voi jäädä huomaamatta. Tämä varmistetaan
malliselosteen kirjoitettavassa ohjeessa.
Koontimallin ongelmana on havaittu sen raskaus ja hidas käsittely. Mallin pyörittely aiheuttaa helposti
ohjelman jumiutumisen. Layer -tasoja sammuttamalla käsittelyä voi jonkin verran parantaa, esimerkiksi
sammuttamalla tason, jossa on tukimuurien geometria.
Puiston tietomalli on laadittu valmiin puistosuunnitelman pohjalta. Mallintaminen aloitettiin tekemällä
tasaus aiemmin tehdyistä korkosuunnitelmista. Tasausta sovitettiin taitorakenteiden mallin kanssa
yhteneväksi.
Mallin alueet tehtiin pintamalleina, joiden pohjana toimi pinnantasauksen malli. Myös pinnoitealueina
olevat kulkureitit tehtiin pintamalleiksi, sillä väylämallintamisen corridor -työkalulla olisi ollut työlästä
toteuttaa aiemmin suunniteltu pinnantasaus sekä alueen rajautuminen muihin alueisiin ja tukimuureihin.
Väylämallin hyödyntämisessä olisi tarvittu useita rakenteen poikkileikkauksia halutun muodon
saavuttamiseen.
Mallissa eri pintamateriaalien alueet on tehty omiksi osamalleiksi. Nämä alueet on tehty rajaamalla ne
pinnantasauksen osamallista. Linkitetyn pinnantasauksen osamallista tehtyjä uusia pinta-alueiden
osamalleja ei voitu linkittää ilman pinnantasauksen kiinnittämistä tiedostoon. Tämä johti siihen, että
pinta-alueiden osamallit joudutaan päivittämään tasauksen muuttuessa uudelleen manuaalisesti
vaihtamalla osamallin rajaukseen uusi geometria. Pinta-alueille on määritetty ominaisuustiedot.
Kaikkien pinta-alueiden mallinnus onnistui hyvin ja niiden lisääminen malliin on nopeaa ja kätevää.
Ohjelman käyttö tosin hidastuu useiden osamallien yhteiskäytössä. Lisäksi ohjelma herkästi antaa
virheilmoituksia, varsinkin raskaissa tiedostoissa.
Puut, kalusteet ja varusteet
Tietomallia varten on karkeasti mallinnettu tarvittavat kalusteet ja varusteet, osalta valmistajilta on saatu
3D-malli tuotteesta. Puissa on käytetty ohjelman kirjastossa olevia puiden 3D-malleja. Pensaat ja
perennat on merkitty pintamallien ominaisuustietoihin eli näitä ei ole esitetty 3D-malleilla.
47 (67)
Mallissa puut, kalusteet ja varusteet ovat ns. multiview -blokkeja, joiden määrityksinä on eri piirtoblokki
ylä- ja 3D-tilassa. Mallintamisen aikana kävi ilmi, että nämä multiview -blokit tulee tehdä vielä
kertaalleen blokeiksi, jotta ne voidaan laskea valitun pinnan tasoon. Blokkien sijainti on kohtisuoraa
pintaa nähden, joten ne osin leikkautuvat pintojen sisään.
Kalusteet ja varusteet saatiin lisättyä malliin nopeasti ja näiden hyödyntäminen esimerkiksi
määrälaskennassa on vaivatonta.
Hulevesiputkistot ja -kaivot
Hulevesiputkisto on mallinnettu hyödyntämällä aikaisemmin laadittua puiston kuivatussuunnitelmaa.
Geometrian luonnissa on hyödynnetty korkotietoja aiempien suunnitelmien 3D-polyline viivoista.
Hulevesikaivojen ja -putkien malleina on käytetty ohjelman kirjaston malleja, joita on hieman muokattu
Futurecad Oy:n toimesta. Tiedostojen käyttäminen vaatii sen, että ko. kirjastot ovat asennettuina
käytettävälle tietokoneelle. Geometrialtaan halutunlaisia kaivo- ja putkityyppejä on ohjelmasta
nykyisellään työlästä saada. Kaivo- ja putkitiedostojen muokkaaminen vaatii perehtyneisyyttä ja
useamman tiedoston muokkaamista.
Hulevesikaivo ja -putkiston mallintaminen on vaivatonta. Käytetyn kohdepinnan hyödynnyksessä ilmeni
ongelmia, mikäli kohdepinnan nimi vaihtui mallin päivitysten aikana. Tällöin esimerkiksi kaivojen korot
saattoivat muuttua vääriksi.
Kaivojen ja putkien ilmoittamisessa käytettyä merkintätapaa ei saatu yleisesti käytetyn tapaiseksi, vaan
korot löytyvät haluttaessa putkien liitoskohdasta. Kaivokortteja ei tehty mallista. Vesipostin kaivoa ei
voitu mallintaa rakennettavalla tarkkuudella, joten sen varusteet ja tarkemmat leikkauskuvat on esitetty
työselosteen liitteenä.
48 (67)
Maarakennekerrokset
Tukimuurin rakennekerrokset tehtiin Civil 3D -ohjelmalla, koska taitorakenteiden mallinnuksessa
käytetty ohjelma ei soveltunut rakennekerrosten luontiin. Tukimuurin taustan monimuotoisuus asetti
haasteita rakennekerroksen geometrian tekemiselle. Muurin taustan ripoja ei voitu huomioida
rakennekerroksia tehtäessä ilman kohtuutonta työmäärää tai mallin koon kasvua. Rakennekerros
toteutettiin useampana osana, joista ylä- ja alapinnan avulla saatiin tilavuudet määriteltyä. Eri
korkeudella, mutta samassa x/y sijainnissa olevia taiteviivoja jouduttiin siirtämään hieman eri kohdalle,
jotta geometria saatiin luotua. Taiteviivojen lisäyksessä käytettiin wall -valintaa suorien pintojen
tekemiseen, mutta kaikissa tapauksissa se ei soveltunut mallintamisen tavaksi.
Puiston rakennekerrokset tehtiin omina tiedostoina. Rakennekerrosten teossa haastavaa oli
rakennekerrosten luiskausten suunnan vaihtelu eripuolelle mallinnettavaa aluetta, josta tuloksena oli
virheellinen geometria. Tämän välttämiseksi rakennekerroksia jouduttiin jakamaan useampaan osaan.
Pinnan muodostamiseen liittyvä rajoitus on ongelmallinen etenkin, kun se rajoittaa myös luiskien
tekemiseen tarkoitettua grading -työkalua.
Rakennekerrokset olisi ihanteellista saada linkittymään toisiinsa, jolloin yhtä kerrosta muokatessa
kyseisen rakennekerroksen ylä- ja alareunaan liittyvät alueet muuttuisivat. Rakennekerrosten
linkittämisen ongelmaksi muodostui, ettei ylemmän kerroksen pystysuorissa kohdissa voi saada taitteen
alareunaa käyttöön, sillä sitä ei muodosteta wall -määritetyillä kohdilla.
Jotta tasauspinnasta saataisiin rakennekerrosten yläpintojen korot automaattisesti, toimitti Futurecad Oy
script -ohjelman pinnan pudottamista varten. Toimintoa ei kuitenkaan käytetty kokeilua pidemmälle,
sillä se teki lähes pystysuorissa kohdissa korkopisteitä väärään z-suuntaan.
Rakennekerrosten tekeminen ohjelmalla on mahdollista. Niiden tekeminen olisi nopeampaa, mikäli
väylämallintamisen rakenteen luontitapaa jalostettaisiin ohjelmaan ja rakennekerroksia olisi mahdollista
lisätä halutuille alueille. Nykyisen väylämallintamisen työkalu vaatii monimutkaisissa pintojen
törmäyksissä ja pinnan korkeussuhteiden vaihtelussa useita tyyppipoikkileikkauksia, joiden sovittaminen
valmiin suunnitelman muotoihin on haastavaa. Suurimmat haasteet rakennekerrosten toteuttamiseen
aiheuttavat kerrosten törmäämiskohdat, joissa pitäisi välttää materiaalien päällekkäisiä sijainteja.
49 (67)
Määrälaskenta
Puiston tietomallin määrälaskennassa on käytetty pintojen reports managerin keräämiä tietoja ja QTO-
managerilla määrityksiä puihin, kalusteisiin ja varusteisiin sekä hulevesikaivoihin ja putkiin.
Tilavuusmallit on määritetty koontimalliin valmiiksi.
Ohjelman heikkoutena on, että siitä puuttuu keskitetty määrälaskentaa varten tehty työkalu, josta kaikki
määrät olisi hallinnoitavissa. Ohjelmassa on osa määrätiedoista saatavana reports managerin alta ja
QTO: sta. Määriä ei nykyisin ole mahdollista saada lajeittain yhteenlaskettuina, vaan ne ilmoitetaan
jokainen tilavuusmalli erikseen. Joitain määrätietoja mallista ei saada määrälaskennan työkaluilla
kerättyä mallista. Esimerkiksi purkumallissa väylätyökalulla tehdyt olevat purettavat reunakivien tiedot
on erikseen tiedettävä hakea mallista, sillä ne eivät tulostu raporteissa muiden mallinosien mukana.
Ohjelmassa on tarvetta kehittää määrälaskennan työkaluja. Yhden keskitetyn määrälaskennan työkalun
etu olisi kiistaton nykyiseen tilanteeseen verrattuna, jossa määriä joudutaan keräämään eri puolilta
listoista. Kerätyt määrätiedot joudutaan nykyisin yhdistämään ja käsittelemään ohjelman ulkopuolella.
Määrälaskentaa hyödyntäisi myös mahdollisuus mallin osien ryhmittelemiseen ja ryhmän määrien
automaattinen yhteenlasku.
Ohjelmaa varten tarvittavan QTO- luettelon tietojen erottelussa käytetyt välimerkit aiheuttavat ongelmia,
sillä ne ovat sidoksissa käyttöjärjestelmän kieliversioon. Laskentatiedoston erottimena toimivat merkit
ovat joko pilkku (,) tai puolipilkku (;). Mallintamisen aikana huomattiin yhtenä QTO:n ongelmana, että
QTO:ta varten tehdyn laskentatiedoston tunnusten muokkaaminen aiheuttaa sen, että muokattavan
tunnuksen aiemmin määritetyt objektit eivät enää tule laskettua kyseiseen kohtaan. Nämä objektit pitää
siis uudelleen määrittää QTO:ssa kuuluvaksi johonkin tunnukseen tai niitä ei huomioida
määrälaskennassa.
Kasvillisuuden määrälaskennassa kokeiltiin QTO:n pinta-alojen rasterointia ja määrälaskentaa. Sitä
käytettiin esimerkiksi pensas- ja perenna-alueiden lajikkeiden kappalemäärien laskemiseen. QTO on
hyödyllinen tässä, sillä siihen voi erikseen kirjoitettavien kaavojen avulla se pystyi ilmoittamaan mm.
taimimäärän. Tätä ei ole kuitenkaan käytetty, sillä QTO ei huomioi 3D-aineistoa. Toimii vain
vaakasuoralla pinnalla.
3.2.3 Mallin tarkastaminen
Civil 3D:llä tehtyjä rakennussuunnitelmatasoisia tietomalleja ei voi tarkastaa IFC-muodossa, sillä
Civilistä ei vielä ole mahdollista tallentaa IFC-muotoon. IFC-muoto on yleinen talo- ja
teollisuusrakenteiden tietomalleissa. Se on myös yleisesti käytetty tietomallien jakelumuoto.
Civil -mallien tarkastamiseen on olemassa kaksi toimivaa vaihtoehtoa: katselumalli tai natiivimalli.
Katselumallit sisältävät kaiken tietomallin tiedon, mutta ne eivät sisällä sen älykkyyttä. Katselumallien
tiedostomuoto on DWF. Niiden lukemiseen on olemassa ilmainen ohjelma nimeltään Autodesk Design
Review. DWF-tiedostomuoto ei tue erilaisten luetteloiden tekemistä mallista eli sitä ei voi hyödyntää
kohteen rakentamisessa. Mallista voidaan tehdä myös Navisworks ohjelmaan tiedosto tarkistamista
varten.
Parempi vaihtoehto on käyttää tarkastamiseen ja mallin jakeluun alkuperäisiä (natiivimalli) Civil-
tiedostoja. Tämä vaatii mallin käyttäjältä jonkin verran tietämystä ohjelman käytöstä malliin upotetun
tiedon esille saamiseksi.
50 (67)
3.2.4 Piirustustarpeen minimointi
Hankkeessa pyrittiin minimoimaan perinteisten 2D-piirustusten käyttö. Osa asioista on kuitenkin
jouduttu kohteen urakkalaskentaa ja rakentamista varten laatimaan perinteisellä tavalla. Todettiin, että
myös työselostus tässä kohteessa tehdään vielä erikseen tekstimuodossa.
3.2.5 InfraFINBIM -nimikkeistö
Puiston tietomallissa ei käytetty InfraFINBIM -nimikkeistöä, sillä hankkeen alussa sovittiin tilaajan
kanssa käytettäväksi infraRYL -litterointia.
3.3 Johtopäätökset
Puiston tietomallin laatiminen on mahdollista tehdä hyvinkin kattavasti ja mallia voidaan hyödyntää
urakkalaskentaan ja rakentamiseen. Tietomalliin liittyy vielä kuitenkin runsaasti riskejä, johtuen
ohjelmiston ominaisuuksista, ohjelmistoversioiden yhteensopimattomuudesta, inhimillisistä virheistä
sekä tietotaidon puutteesta. Nämä riskit tulee tiedostaa ja minimoida. Vuorovaikutus mallin laatijan ja
muiden hankkeen toimijoiden välillä on ensiarvoisen tärkeää, tässä huolellisesti laadittu tietomalliseloste
on avainasemassa.
3.3.1 Hyödyt, haitat, ongelmat, kehitystarpeet
Kaivattuja ominaisuuksia
- Mallin sisällöstä on työlästä ylläpitää käsin sisällysluetteloa (osa voidaan tehdä reports
managerilla, mutta ne eivät sisällä kaikkea mallin sisältöä).
- Ohjelmassa tehdyt leikkaukset näyttävät pääsääntöisesti vain Civil 3D:llä tehdyt kohteet.
Blokkeja on mahdollista projisoida leikkauskohdilta, mutta niitä ei saa leikattuina leikkauksiin.
Leikkauslinjan etu- ja taka-alan projisointia ei voi tehdä.
o Siksi ohjelmassa olisi hyvä olla ns. reaaliaikainen leikkaustoiminto, jolla itse mallista voi
leikata osia ja katsella niitä 3D-tilassa mallia pyöritellen.
- Määrälaskennassa käytettyä QTO:ta ei voitu käyttää pinta-alueiden laskentaan, koska se ei
huomioi pinta-alojen z-korkoja, tällöin saadut tulokset olisivat olleet 2D-aloja. QTO taas olisi
mahdollistanut esimerkiksi taimien kappalemenekkien laskun pinta-aloista kaavojen avulla. Jos
QTO huomioisi listauksissa z-korot, QTO:n rasterointi olisi käyttökelpoinen työväline 2D-
piirustusten luontiin. Sitä voisi käyttää nopeasti mm. pinta-alojen listauksissa ja laskennoissa.
- QTO:n listan välimerkkien riippuvuus tietokoneen käyttöjärjestelmän kieliversiosta tulisi korjata.
Esim. kun englanninkielisessä käyttöjärjestelmässä kirjoitta pilkun, muuttuu se suomenkielisessä
järjestämässä puolipilkuksi, mikä aiheuttaa sen että kaikki sadat välimerkit tulee käydä
muuttamassa käsin. Toinen vaihtoehto on ylläpitää kahta eri listaa.
- Ohjelmassa eri pintamateriaalien alueet joudutaan tekemään omiksi osamalleiksi. Mallissa nämä
alueet on tehty rajaamalla pinnantasauksen osamallista. Tasauksen osamallia ei voitu linkittää
tehtyihin pinta-alueiden osamalleihin, joten tasauksen muuttuessa ne jouduttiin päivittämään
uudelleen manuaalisesti vaihtamalla uusi geometria osamallin rajaukseen. Ohjelmassa tulisi olla
mahdollisuus hyödyntää linkitystä saman osamallin geometrian avulla (malliin linkitetty
osamalli, jota muokataan ja se linkitetään uudeksi osamalliksi). Vaihtoehtoisesti osamallin pinta
voisi olla määriteltävissä useampaan materiaalialueeseen, joilla on omat ominaisuustiedot.
51 (67)
- Rakennekerrosten luonti eri alueille on työlästä ja vaikeasti linkitettävissä toisiinsa, jolloin
muutokset suunnitelmassa ovat hitaita toteuttaa. Lisäksi linkityksestä aiheutuu satunnaisesti
ongelmia, esim. tekemällä grading -työkalulla luiskan tiettyyn pintaan voi kaataa tiedoston, eikä
tiedostoa voi enää avata koneella, jolta löytyy linkki kyseiseen linkitettyyn pintaan.
Rakennekerrosten tekemiseen ohjelmalla tulisi lisätä mahdollisuus tehdä ne määrätylle alalle
väylämallityökalun tavoin.
- Tilavuusobjekteissa tulisi olla mahdollista tehdä tilavuuden laskenta useamman kuin kahden
pintamallin väliltä.
- Näkymätyyleihin kaivataan ohjelmassa joustavuutta ja ns. älykkyyttä. Mallin piirtotyylit pitäisi
olla joustavasti valittavissa ns. 2D-tyylistä realistiseen 3D-tyyliin. Myös alueiden materiaalien
esittäminen värien lisäksi rasterein on kaivattu ominaisuus.
- Tiedoston prospector- lista tarvitsisi mahdollisuuden jäsentämiseen, kuten mallin osien
ryhmittelemiseen kansioihin ja niiden yhtenäiseen hallintaan.
- Mahdollisuus valita useampi mallin osan prospector -listasta. Nykyisin mahdollista valita
vain yksi kerrallaan.
- Usean data shortcutilla linkitetyn mallinosan kiinnittäminen kerrallaan tiedostoon prospector
-listalta promote -käskyllä.
- Näyttötyylin (surface properties näyttötyylit) asettaminen kerralla useaan mallin
osaan/ryhmään
- Ohjelmassa on tarvetta määrälaskennan niputtamiseen yhden työkalun alle, jossa kaikki määrät
saadaan listattua. ohjelman sisällä ja päivittyvä luettelointi
- Mallin sisältämien kaikkien osien luettelointi mahdolliseksi yhden työkalun alta. Nykyisin
listaukset on kerättävä esimerkiksi ohjelman ulkopuolelle tehtäviin Excel- tiedostoihin reports
managerin ja QTO:n listojen perusteella. Nyt tehdyt listaukset lisäävät taulukoiden
muokkaustarvetta mallia päivitettäessä.
- Olisi hyvä voida integroida työselostus malliin.
- Mallia tulisi voida leikata toisella mallilla (joko osa toisesta, toisella croppaaminen tai aukon
tekeminen risteävään kohtaan).
- Civil surfacen leikkaaminen Autocadin työkaluilla luoduilla esim. mesh-malleilla
- Tiedostojen linkittämiseen tarvittaisiin laajempi tuki, kuten IFC- ja Revit-mallin liittämiseen
suora tuki (ei tiedostomuuntoa ennen liittämistä).
- Data shortcut -linkkien synkronoinnissa ohjelma kysyy jokaiselle mallin osalle, että
vaihdetaanko koontimallissa oleva nimi projektimallia vastaavaksi vai säilytetäänkö se ennallaan.
Valinnalle ei ole mahdollista saada jokaista synkronoitavaa linkkiä koskevaa samaa määritystä
kysymykseen, vaan jokaisen nimen päivitystarpeen kohdalla on käyttäjän hyväksyttävä valinta
erikseen. Usean linkitetyn tiedoston koontimalleissa tähän nimien päivittämisen valintaan kuluu
aikaa ja siinä on mahdollisuus painaa väärää valintaa, jolloin mallin osan nimi vaihtuu vääräksi.
Tämä vaihe data shortcutilla kiinnitettyjen mallin osien synkronoinnissa on kierrettävissä
käyttämällä projektitiedostoissa vastaavaa nimeämistä kuin koontimalleissakin.
52 (67)
3.3.2 Tietomallintamisen haasteellisuuden arviointi
Puiston tietomalli pystytään luomaan Civil 3D -ohjelmalla varsin kattavasti. Haasteellisuutta aiheuttaa
mallin jatkokäyttö. Mallin luoja hallitsee mallin ominaisuudet, mutta tämän monimutkaisen prosessin
tieto ja taito tulee pystyä kattavasti siirtämään muille käyttäjille. Tähän tulee erityisesti kiinnittää
huomiota Civil 3D -ohjelmaa käytettäessä.
3.3.3 Jatkotoimenpiteet
Pilotin mielenkiintoisin vaihe on edessä, kun lasketaan urakat mallin avulla sekä toteutetaan kohde.
Malli on tarkastettu ulkopuolisessa tarkastajalla ja jo tästä on saatu hyvää palautetta mallin
kehittämiseen. Lisää palautetta on odotettavissa urakkalaskennan ja toteutuksen aikana. Kun nämä
vaiheet on käyty läpi ja puiston tietomalli päivitetty palautteen perusteella voidaan olettaa, että malli on
niin hyvä kuin se nykyisillä ohjelmilla ja osaamisella kohtuullisella työmäärällä on mahdollista.
53 (67)
4 Yhdistelmämalli
Hankkeen rakennussuunnittelussa käytettiin kahta tietomallinnusohjelmistoa: AutoCAD Civil 3D ja
Tekla Structures. Civil 3D -ohjelmistolla muodostettiin puiston tietomalli. Näistä kahdesta tietomallista
muodostettiin yhdistelmämalli Autodesk Navisworks -ohjelmistolla (kuva 46).
Kuva 46. Yhdistelmämalli.
Yhdistelmämallissa on kuvattu koko hankkeen kaikki rakenteet. Sen on tarkoitus toimia lähinnä
visuaalisena mallina kun hankkeen kokonaisuutta tarkastellaan. Mallissa olevien rakenteiden väritys on
lähempänä todellista tilannetta kuin natiivimalleissa ja malli on oikeassa koordinaatistossa.
Yhdistelmämalli ei sisällä läheskään samaa tietomäärää kuin ohjelmien natiivimallit eli se ei yksistään
riitä rakentamiseen, mutta se toimii hyvänä apuvälineenä rakentamisen aikana. Se toimii suunnittelijoille
mallin tarkastustyökaluna ja urakoitsijalle hankkeen koordinointityökaluna.
Yhdistelmämallin muodostaminen onnistui hyvin. Yhdistelmämalli sisältää tarkalleen ottaen kolme
erillistä tietomallia: puiston purkumalli (Civil 3D), puiston suunnitelmamalli (Civil 3D), kovien
rakenteiden malli (Civil 3D). Purkumallissa on nimensä mukaisesti esitetty nykyisestä tilanteesta
purettavat rakenteet. Purkumalli voidaan helposti piilottaa yhdistelmämallin näkymästä eli se ei vaikeuta
lopullisen tilanteen tietomallin tarkastelua.
Mallin objektit sisältävät jonkin verran tietoa, joka auttaa mallin hyödyntämisessä. Kuvassa 47 on
esitetty yhdistelmämallissa olevan nurmiobjektin sisältämän tiedot.
54 (67)
Kuva 47. Yhdistelmämallissa olevan nurmiobjektin tiedot.
Navisworks sisältää paljon työkaluja mallin hyödyntämiseen. Mallista voidaan ottaa leikkauksia, siihen
voidaan tallentaa valmiita kuvantoja, johon on lisätty esimerkiksi mittoja ja tekstikenttiä. Mallista
voidaan myös renderöidä erittäin korkeatasoisia havainnekuvia tai animaatioita todellisilla valaistuksilla
ja pintamateriaaleilla. Navisworks sisältää myös ”TimeLiner” -työkalun, jota avulla voidaan
havainnollisesti suunnitella vaiheittain rakentamista ja aikataulutusta.
LIITE A
55 (67)
Liite A - Kokonaisyhteenveto pilotista
Pilotin nimi Hyväntoivonpuisto. Puiston, tukimuurien ja siltojen
tietomallin laatiminen.
Pilotin tyyppi Pilottihanke
Pilottihankkeen kuvaus Hankkeessa laaditaan Hyväntoivonpuistosta ja siihen
liittyvistä rakenteista (sillat, tukimuurit, portaat) tietomallit.
Projektin 1. vaihe käsittää yhden teräsristikkorakenteisen
kevyenliikenteen sillan, noin 380 metriä tukimuuria sekä noin
130 aaria puistoa.
Aikataulu 31.3.2010 - 30.11.2012.
Osapuolet ja käytettävät ohjelmistot HKR, Ponvia Oy (Autodesk Revit Structure, AutoCAD, Tekla
Structure, Navisworks, Robot Structural Analysis
Professional), VSU Oy (Autodesk Civil 3D, Navisworks),
A&S Virtual Systems Oy, Future CAD Oy
Pilotoitava(t) asia(t) ja pilotin tavoitteet - Vaihtoehtoisen tietomallinnusohjelmiston (Revit Structure)
soveltuvuus kohteen tietomallintamiseen
- Yhteistoiminta eri mallinnusohjelmistojen välillä.
- Yhdistelmämallin luominen.
- Piirustustarpeen minimointi.
- Urakkalaskenta mallipohjaisesti.
Tietomallin käyttö hankkeessa Koko hanke toteutettiin tietomallipohjaisesti. Suurin osa
perinteisesti piirustuksissa esitetystä tiedosta pyritään
saamaan tietomalliin.
Pilottihankkeen erityispiirteet
suhteessa tietomallinnukseen
Pilotissa tehdään selvästi nykyistä käytäntöä tarkempi
tietomalli, joka asettaa haasteita ohjelmistolle ja nykyiselle
ohjeistukselle.
Keskeisimmät esiin nousseet ongelmat
ja kehitystarpeet
Pilotissa havaittiin, että ohjelmistojen ominaisuudet eivät tällä
hetkellä sovellu pilotin tavoitteisiin eli kaikkia piirustuksissa
esitettyä tietoa ei ole vielä järkevää esittää tietomallissa.
Keskeiseksi asiaksi muodostui mallintamistarkkuus, joka
täytyisi määritellä erittäin yksityiskohtaisesti ennen
mallintamisen suorittamista. Tämä vaikuttaa suuresti
mallintamiseen käytettyyn aikaan. Hankkeessa tuli selkeästi
ilmi, että mallintaminen lisää suunnittelijan työtä ja
suunnitteluun menee mallintamalla enemmän aikaan. Tässä
projektissa mallintamisen ajankäyttöä verrattuna perinteisesti
tehtävään suunnitteluun ei voida helposti vertailla. Projektin
haastavuuden takia rakenteita ei olisi voitu suunnitella muuten
kuin 3d-mallien avulla.
Keskeisenä kehitystarpeena ilmeni tarve koko alalle yhteiselle
numerointi-/nimeämisohjeelle Tekla Structures -ohjelmaan
sisältäen myös InfraRYL litteroinnin liittämisen malliin..
56 (67)
Kaiken kaikkiaan projektin toteuttaminen täysin
tietomallipohjaisesti onnistui hyvin. Projektin aikataulua
pitkittyi moneen otteeseen ja tähän on useita syitä. Suurin syy
on oletettua hitaampi mallintaminen johtuen kohteen
vaikeasta geometriasta ja asetetuista tarkkuusvaatimuksista.
Myös uusien ohjelmistojen ja työkalujen käyttöönotto
hidastaa työtekoa alkuvaiheessa.
LIITE B
57 (67)
Liite B - Tekla Structures -mallin havainnekuvia
LIITE B
58 (67)
LIITE B
59 (67)
LIITE B
60 (67)
LIITE C
61 (67)
Liite C - Yhdistelmämallin havainnekuvia
LIITE C
62 (67)
LIITE C
63 (67)
LIITE D
64 (67)
Liite D - InfraFINBIM arviointisabluunateksti
Arviointisapluuna Pilottiraportti
Tuula Hakkarainen 1
Päivämäärä: 8.4.2013 Pilotit: 19_5DSilta_Varjakanpuisto (suunnittelu: Sito Oy) 20_5DSilta_Melatie (suunnittelu: Sito Oy) 21_5DSilta_Töölönlahti (suunnittelu: Sito Oy) 22_5DSilta_Junatie (suunnittelu: Sito Oy) 23_5DSilta_HTP (suunnittelu: Ponvia Oy) Haastateltavat: Ville Alajoki (Helsingin kaupunki, rakennusvirasto), Tuomo Järvenpää (Ponvia Oy) ja
Ari Kouvalainen (Sito Oy) Tulokset:
A: B: C: D: E: F: G: H: I: J: K: V-1: V-2: V-3:
Procure-ment and
delivery method
BIM skills
Project partici-
pant roles
Process descrip-
tion
Initial data
BIM scope
GIS-BIM integra-
tion
Geo-metric
modell-ing
Open BIM/ Stan-dards
Infor-mation delivery mana-
gement
As-built infor-
mation
Hanke-proses-
sit
Elinkaa-rinäkö-kulma
Liike-toiminta
Helsingin kau-
pungin 5DSilta-
pilotit
1 3 tai 1
2-3 1 2 4 1 4 3 1 – 6 2-3 2
4.2 Tietomallintamisen haasteellisuuden arviointi / Arviointisapluuna
Infra FINBIM –hanketta varten VTT on kehittänyt arviointisapluunan, jonka avulla arvioidaan pilotti-hankkeiden tietomallinnusvalmiuksia. Arviointisapluuna on jaettu 11 kategoriaan ja kussakin kate-goriassa on kuusi valmiustasoa. Arvioitavat kategoriat ovat seuraavat:
A: Procurement and delivery method B: BIM skills C: Project participant roles D: Process description E: Initial data F: BIM scope G: GIS-BIM integration H: Geometric modelling I: OpenBIM/Standards J: Information delivery management K: As-built information
Arviointisapluunaa käytetään eri pilottihankkeiden tietomallinnusvalmiuksien vertailuun ja haasteel-lisuuden arviointiin sekä tavoitteiden asettamisessa ja niiden saavuttamisen todentamisessa. Arvi-ointisapluunan kategoriat ja niiden valmiustasot on esitetty liitteessä X.
Infra FINBIM –hankkeen alussa arviointisapluunan avulla määriteltiin infrarakentamisen tietomal-linnuksen nykytila ja hankkeen jälkeinen tavoitetila. Tulokset on esitetty kuvissa 1 ja 2. Määrittely tehtiin esteidenpoistoryhmässä, johon kuuluivat seuraavat henkilöt:
Kimmo Laatunen VR Track Oy Harri Mäkelä Innogeo Oy Antti Karjalainen WSP Oy Juha Liukas Sito
LIITE D
65 (67)
2 (3)
Tapani Toivanen Lemminkäinen Oyj Rauno Heikkilä Oulun yliopisto Juha Hyvärinen VTT Tarja Mäkeläinen VTT
Kuva 1. Esteidenpoistoryhmän näkemys infrarakentamisen tietomallinnuksen nykytilasta arvioin-tisapluunan kategorioiden perusteella ennen Infra FINBIM –hanketta.
Kuva 2. Esteidenpoistoryhmän näkemys infrarakentamisen tietomallinnuksen tavoitetilasta Infra FINBIM –hankkeen jälkeen.
LIITE D
66 (67)
3 (3)
Arviointisapluunatutkimus on tehty pilottihankkeiden loppuvaiheessa tai hankkeiden päättymisen jälkeen haastattelututkimuksena. Haastattelussa pilottien vastuuhenkilöt ovat arvioineet pilottien tason oman näkemyksensä mukaisesti. Helsingin kaupungin 5DSilta-pilotteja (19_5DSilta_Varjakanpuisto, 20_5DSilta_Melatie, 21_5DSilta_Töölönlahti, 22_5DSilta_Junatie ja 23_5DSilta_HTP) käsiteltiin tässä haastattelussa yhtenä kokonaisuutena. Näiden pilottien arvioinnin tekivät Ville Alajoki Helsingin kaupungin rakennusvirastosta, Tuomo Järvenpää Ponvia Oy:stä ja Ari Kouvalainen Sito Oy:stä. Haastattelun tulokset on esitetty kuvassa 3.
Kuva 3. Helsingin kaupungin 5DSilta-pilottien tulokset.
Tuloksista nähdään, että Helsingin kaupungin 5DSilta-piloteissa saavutettu taso ylittää infra-alan yleisen lähtötason neljässä kategoriassa (B, F, H ja I). Esteidenpoistoryhmän asettama tavoitetila saavutettiin kolmessa kategoriassa (B, F ja H). Kategoria B (BIM skills) arvioitiin suunnittelun osalta tasolle 3, mutta prosessijohtamisen näkökulmasta tasolle 1.
Näissä pilottihankkeissa on siis eräillä tietomallinnuksen osa-alueilla edistytty alan yleistä lähtöti-lannetta paremmalle tasolle, mutta kehityskohteita on vielä useita. Haastavimmilta vaikuttavat ar-viointisapluunan perusteella kategoriat G (GIS-BIM integration) ja J (Information delivery manage-ment), joissa jäätiin infra-alan yleisen lähtötason alapuolelle. Siltojen suunnittelussa käytettävä oh-jelmisto on paikallisen koordinaatiston työkalu, ja vietäessä tietoja paikkatietojärjestelmään tarvi-taan välivaihe. Tiedonsiirron osalta tieto liikkuu tilaajan suuntaan CD:llä, muistitikulla tai sähköpos-tilla, eikä muunlainen tiedonjakaminen ole tällä hetkellä tarpeen. Konsulttiyrityksillä on kuitenkin valmius luoda projektipankki, kun tarvetta ilmenee.
Kategoria K (as-built information) ei ole relevantti näissä pilottihankkeissa, koska ne eivät ole vielä vaiheessa, jossa toteumatietoa olisi käytettävissä. Tämä näkyy kuvassa 3 kategorian K arvona 0.
LIITE E
67 (67)
Liite E - Arviointisapluunan kategoriat ja valmiustasot