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