1/55 TUOTEMALLINNUS RAKENNESUUNNITTELUSSA

Transkriptio

1 1/55 TUOTEMALLINNUS RAKENNESUUNNITTELUSSA Perusteet ja ohjeita I Finnmap Consulting Oy Rakennusteollisuus RT ry

2 2/55 Esipuhe Rakennusten suunnittelu on nopeasti muuttumassa kohti tuotemallintamiseen perustuvia toiminta- ja menettelytapoja. Tuotemallintamisen keskeisiä etuja ja lisäarvoja ovat mm. suunnitelmien havainnollisuus, eri mallien yhteensovittamis- ja tarkastusmahdollisuus, tarkempi ja monipuolisempi suunnittelulopputulos ja tietosisältö ja mallin sisältämän tiedon jatkohyödyntäminen rakennuttajan päätöksenteossa, muissa suunnittelulajeissa, tuoteosien valmistuksessa ja rakentamisessa sekä käyttö- ja ylläpitovaiheessa. Tuotemallintamista ja siihen liittyviä menettelyjä on kehitetty ja yhdenmukaistettu Pro IT Tuotemallitieto rakennusprosessissa -kehitysprojektissa, jossa on jo aiemmin laadittu Arkkitehdin tuotemallisuunnittelu ohje. Tuotemallipohjainen rakennesuunnittelu ohje on myös syntynyt osana Pro IT projektia. Ohje on tehty Arkkitehdin tuotemallinnussuunnittelu ohjeen, Pro IT pilot-hankkeiden sekä muun mallintamisesta kertyneet kokemuksen perusteella yhteistyössä mallien hyödyntäjien, rakennesuunnittelutoimistojen sekä mallinnusohjelmistojen edustajien kanssa. Ohjeen keskeisenä tavoitteena on antaa perustiedot ja ohjeet rakennesuunnittelijan tuotemallipohjaiselle suunnittelulle sekä vaikuttaa ohjelmistokohtaisten sovellutusten ja kansallisten rakennusosa-, detalji- ja liitoskirjastojen tekemiseen tuotemalliperiaatteiden mukaan. Tämä ohje voi myös toimia runkona laadittaessa tuotemalliperusteista projektikohtaista ohjetta niin rakennesuunnittelijan käyttöön kuin koko suunnitteluryhmänkin käyttöön. Rakennesuunnittelun kannalta ohjeen tavoitteena on lisäksi yhtenäistää ja standardisoida terminologiaa, toimintatapoja ja työmenetelmiä, sekä rakennesuunnitteluprosessin sisällä että osana muuta suunnitteluprosessia ja koko hanketta. Tavoitteena on myös toimia oppaana ja best practise kuvauksena ohjelmistotoimittajille ja kehittäjille sekä yksittäisten ohjelmistojen sisällä, että eri ohjelmistojen välisen yhteensopivuuden parantamiseksi. Tiedonsiirron osa-alueelta ohje kuvaa tämän vuoksi nykyistä käytäntöä, toivottavaa kehityssuuntaa ja tulevaisuuden tavoitetilaa. Toivomme ohjeen leviävän mahdollisimman laajaan käyttöön suunnittelutoimistoissa ja toivomme saavamme myös palautetta ohjeesta sen edelleen kehittämiseksi. Pro IT projekti tulee myöhemmin julkaisemaan ohjeen kehitysversion saatavan palautteen ja uusien pilothankkeiden kokemusten perusteella. Jatkossa tullaan myös voimakkaammin kytkemään ohjeistuksia yhteen eri suunnittelusektoreiden osalta sujuvan ja yhteensopivan suunnittelumenettelyn kehittämiseksi. Parhaat kiitokset kaikille ohjeen valmisteluun osallistuneille! Syyskuussa 2004 Ilkka Romo Rakennusteollisuus RT ry Markku Varis Finnmap Consulting oy

3 i/55 SISÄLLYSLUETTELO 1 JOHDANTO Ohjeen tavoitteet Välilliset tavoitteet Terminologia ja käsitteet tuotemallintamisessa EDELLYTYKSET TUOTEMALLISUUNNITTELUN TARJOAMAT MAHDOLLISUUDET JA LISÄARVOT RAKENNESUUNNITTELUN TEHTÄVÄT VASTUUT JA OIKEUDET TUOTEMALLIPOHJAISESSA SUUNNITTELUSSA TUOTEMALLINNUKSEN PERIAATTEET Yleistä Visio tuotemallipohjaisesta suunnittelusta Rakennesuunnittelun prosessimalli Rakennesuunnittelun lähtötiedot tuotemallinnuksessa Tilaajan toimittamat lähtötiedot Käyttäjän toimittamat lähtötiedot Muiden suunnittelijoiden toimittamat lähtötiedot Muiden osapuolien toimittamat lähtötiedot Tuotemallinnuksen vaiheet, tuotemallin rakenne Mallinnuksen vaiheet suunnittelussa Mallintamistapa Reikämerkinnät Mallintamistarkkuuden mukainen tiedonsiirto, rakenneosakirjastot Mallintamistarkkuus ja mallin tietosisältö Tuoterakenteet Liitokset Liitteenä ohjelmistotoimittajien sovellusesimerkit Tuotemallin tunnistetiedot TUOTEMALLIN YLLÄPITO JA KÄYTTÖ Nykytilanne Tuotemallipalvelin... 32

4 ii/ Yhteinen tuotemalli Hajautettu tuotemalli Älykäs projektipankki OHJELMISTOJEN JA RAKENNESUUNNITTELUN NYKYTILANNE Rakennesuunnittelun toimintamallit tänään Tuotemallinnusohjelmia Eräiden rakennesuunnittelussa käytettyjen ohjelmistojen kuvauksia Mitoitusohjelmat ja niiden liityntä tuotemalliin TIEDONSIIRTO TUOTEMALLINTAMISESSA (SÄHKÖINEN) Tiedonsiirto, yleistä Tiedonsiirtoformaatit IFC Ohjelmistojen omat formaatit Esimerkkejä attribuutti muotoisen tiedon siirrosta Tiedonsiirto eri suunnitteluosapuolien välillä Yleistä RAK ARK ja RAK LVIS, RAK GEO jne Elementtisuunnittelija / tuoteosasuunnittelija Tiedonsiirto/ muut hankeosapuolet Tiedonsiirron turvallisuus Referenssimallien kontrollointi TUOTETTAVAT ASIAKIRJAT D suunnitteludokumentit Sähköiset asiakirjat MUUTOSTEN HALLINTA Muutosten hallinta dokumenttipohjaisilla suunnittelumenettelyillä Muutosten hallinnan periaatteet tuotemallintamisessa Tuotemallinnuksen antamat mahdollisuudet muutosten hallinnalle PILOTTIKOHTEEN RAPORTOINTI...48

5 iii/ Pilottikohde Pilotointitavoitteet Tilanne per OHJEIDEN JATKOKEHITTÄMINEN...50

6 1/55 1 JOHDANTO 1.1 Ohjeen tavoitteet ProIT-projektin yleiset tavoitteet löytyvät osoitteesta Tämä ohje tukeutuu ProIT:n yleisiin tavoitteisiin sekä tuotemallisuunnittelun ja tuotemallipohjaisen tiedonhallinnan tavoitteisiin mm. seuraavilta osin: o Lisäarvoa asiakaspalveluun - tuottamalla hyödyllistä tietoa päätöksenteon tueksi ja visualisoimalla sekä vertailemalla vaihtoehtoja toiminnallisesti ja kustannuksiltaan. o Kokonaisuuden kannalta tehokas suunnitteluprosessi - tuottamalla täsmällisempää tietoa ja vähentämällä suunnitteluvirheitä, parantamalla suunnitelmien yhteensopivuutta ja edistämällä eri suunnittelijoiden välistä yhteistyötä o Rakentamisen laadun ja tuottavuuden parantaminen - tuottamalla käyttökelpoisempaa tietoa hyödynnettäväksi tuotannonsuunnittelussa, kustannus- ja aikatauluhallinnassa sekä rakennustuotteiden valmistuksessa ja hankinnassa o Työkaluja elinkaaren hallintaan - tuottamalla rakennuksen koko elinkaarta käsittelevää tietoa, jonka avulla elinkaarikustannukset ja ympäristövaikutukset voidaan ottaa paremmin huomioon suunnittelussa ja jota voidaan monin tavoin käyttää hyväksi rakennusten käytössä ja ylläpidossa Ohjeen keskeisenä tavoitteena on antaa perustiedot ja ohjeet rakennesuunnittelijan tuotemallipohjaiselle suunnittelulle ja vaikuttaa ohjelmistokohtaisten sovellutusten tekemiseen tuotemalliperiaatteiden mukaan. Rakennuksen tuotemallin avulla siirretään suunnitelmatietoa rakennushankkeen eri osapuolille elektronisessa muodossa siten, että tieto on hyödynnettävissä ilman manuaalisia välivaiheita. Tuotemallista on tarkoitus tuottaa mm: o Suunnitelmadokumentit o Mitta- ja määrätiedot o Visuaaliset kuvaukset hankkeesta o Kiinteistönhallinnan lähtötiedot o Säilyttää tuotettu tieto rakennuksen elinkaaren ajan Tämä ohje on myös runkona laadittaessa tuotemalliperusteista projektikohtaista ohjetta, jossa on määriteltävä myös projektin osapuolten vastuut ja velvoitteet. Rakennesuunnittelun kannalta ohjeen tavoitteena on lisäksi yhtenäistää ja standardisoida terminologiaa, toimintatapoja ja työmenetelmiä sekä rakennesuunnitteluprosessin sisällä että osana muuta suunnitteluprosessia ja koko hanketta. Tavoitteena on myös toimia oppaana ja toiminnallisen määrittelytyön tapaisena best practise -kuvauksena ohjelmistotoimittajille ja kehittäjille sekä yksittäisten rakennesuunnittelun tuo-

7 2/55 temallisuunnitteluohjelmistojen sisällä että eri ohjelmistojen välillä nimenomaan ohjelmistojen välisen yhteensopivuuden lisäämiseksi. Tämä rakennesuunnitteluohje pyrkii olemaan luonnollinen jatkumo arkkitehtisuunnitteluohjeelle, joka on aikaisemmin julkaistu ProIT-projektin toimesta. ProIT-projektissa on tarkoitus myös ohjeistaa tuotemallipohjaista talotekniikka-suunnittelua. Yhdessä nämä muodostavat ohjeiston, jolla on tarkoitus aikaansaada sellainen suunnitteluryhmän huippusuoritus, joka on enemmän kuin yksittäisten suoritusten summa. 1.2 Välilliset tavoitteet Tällä ohjeella on myös välillisiä tavoitteita, jotka liittyvät yleisimmällä tasolla tuotemallipohjaiseen suunnitteluun ja rakennesuunnittelijan rooliin rakennushankkeessa. Ko. välilliset tavoitteet on peilattu siitä näkökulmasta, että tuotemallipohjainen suunnittelu parhaimmillaan vaatii yhtäältä erinomaista luovuutta, mutta toisaalta perusteellista järjestelmällisyyttä, jotka molemmat ovat hyvän rakennesuunnittelijan ominaisuuksia. Näitä välillisiä tavoitteita ovat mm. seuraavat: o Sen ymmärryksen ja kulttuurin muodostaminen, että paras tapa ja ainoa syy tuotemallipohjaisen suunnittelun käyttöönotolle ja lisäämiselle on se, että tuotemallisuunnittelun tulee tuottaa lisäarvoa koko prosessille nimenomaan kokonaisuuksien hallinnan kautta korostaen vanhaa sanontaa hyvin suunniteltu on puoliksi tehty. o Vastaavan rakennesuunnittelijan roolin (ja arvostuksen) kasvattaminen tuotemallipohjaisen kokonaisuuden hallinnan kautta; tämä haaste rakennesuunnittelijoiden tulee ottaa vastaan ja ansaita ko. laajempi rooli mm. rakennusten turvallisuusnäkökohtien perusteella. o Edellisestä johtuvana välillisenä tavoitteena on myös sen viestin eteenpäin vieminen ohjelmistokehittäjille, että toimivien statiikka- ja mitoitusohjelmien integroiminen osaksi rakennesuunnittelun tuotemallia on todella tärkeä asia. 1.3 Terminologia ja käsitteet tuotemallintamisessa Tuotemallintamisen terminologiasta ja käsitteistä on olemassa Tuotemallintamisen termit raportti osoitteessa Liitteessä 10 on esitetty rakennesuunnitteluun liittyviä keskeisiä termejä ja käsitteitä ko. julkaisusta. 2 EDELLYTYKSET Tarkasteltaessa tuotemallipohjaisen suunnittelun edellytyksiä, voidaan niitä lähestyä seuraavista näkökulmista: o Mallintajien (= suunnittelijoiden) koulutus, tietotekniikan osaaminen, pätevyys, kokemus on luonnollisesti perusedellytys; oleellinen asia tässä on ymmärtää oma roolinsa koko prosessissa eli vaatimukset omalle suoritukselle muiden kannalta ja toisaalta mallintavan suunnittelun luomat mahdollisuudet koko hankkeen kannalta. o Edellytys tuotemallipohjaisen suunnittelun laajentamiselle on tarjonnan (suunnittelijat, ohjelmistot) ja kysynnän (tilaajat) tasapainoinen kasvu. o Tuotemallipohjainen suunnittelu hyödyllisimmällään edellyttää hankkeen eri osapuolilta yhteensopivien tietojärjestelmien ja tiedonsiirtoformaattien käyttöä; tiedonsiirtoa on käsitelty tämän ohjeen kappaleessa 9.0.

8 3/55 o Kansallinen standardisointi luo pohjaa yhteensopivaan tuote- ja tietomallien rakentamiseen; ko. asiaa on käsitelty tämän ohjeen kappaleessa 12, arkkitehtisuunnitteluohjeissa sekä mm. ProIT-tuoterakenne-osaprojektissa ( o Projektikohtaisesti onnistuneen tuotemallisuunnittelun edellytyksenä on kattavat projekti- (ja ohjelmisto-) kohtaiset ohjeet niin eri suunnitteluosapuolille kuin koko suunnitteluryhmälle; tämän ohjeen liitteinä (liitteet 1, 3) on sisällysluettelomallit ko. ohjeille. o Edellytyksenä on luonnollisesti myös vaatimukset käytettäville työasemille, ohjelmistoille, tiedonsiirtoyhteyksille jne., joita on käsitelty tämän ohjeen liitteessä 2. 3 TUOTEMALLISUUNNITTELUN TARJOAMAT MAHDOLLISUU- DET JA LISÄARVOT Rakennushankkeen kustannukset sekä rakennuksen ja siinä harjoitettavan toiminnan elinkaarikustannukset määräytyvät pääosin suunnitteluvaiheessa. Tuotemallipohjainen suunnittelu oikein käytettynä luo todella hyvän pohjan koko elinkaaren huomioonottavalle kokonaisvaltaiselle optimoinnille ja päätöksenteolle niin suunnittelijan, tilaajan, käyttäjän ja rakentajan kannalta. Kun puhutaan tuotemallintamisen hyödyistä kannattaa nimenomaan keskittyä lisäarvoihin, joita tuotemallilla voidaan hankkeen eri osapuolille tuottaa ja varsinkin lisäarvojen yhteisvaikutusta koko prosessille. Se, että ko. lisäarvot saadaan parhaiten hyödynnettyä, voi tarkoittaa nykyisiin toimintatapoihin verrattuna esim. tehtävien uudelleen järjestelyä mm. niin, että rakennesuunnittelijan tehtävät tulevat lisääntymään. Esimerkiksi määrä-, elinkaari- ja aikataulutiedon jne. hallinta siirtynee osittain rakennesuunnittelijan tehtäväksi. Suunnittelujärjestelmä ja tietokoneohjelma ovat vain välineitä haluttuun lopputulokseen pääsemiseksi. Tämän vuoksi tuotemallisuunnittelua tulisi aina lähestyä niin suunnittelijan kuin tilaajan näkökulmasta sen tarjoamilla mahdollisuuksilla ja lisäarvoilla. Tuotemallipohjaisen rakennesuunnittelun tarjoamia uusia mahdollisuuksia ja lisäarvoja on mm. seuraavat: o Mallinnus tulevaisuudessa tulee tapahtumaan yhteen yhteiseen malliin tai tuotemallipalvelimeen tai tietokantaan (Building Information Model, BIM), mikä lisää kaikkien alla mainittujen lisäarvojen vaikutusta. o Suunnitelmien yhteensovitus helpottuu ja ristiriidat vähenevät. o Kokonaissuunnitteluaika tehostuu yhtäältä eri alojen suunnittelun yhtä aikaistumisen ansiosta ja toisaalta sen vuoksi, että tieto on tuotettu paremmin huomioonottaen eri tiedontarvitsijoiden tarpeet. o Suunnitelmien muunneltavuus paranee (muutostieto kirjataan periaatteessa vain yhteen paikkaan) ja dokumentit päivittyvät automaattisesti. o Suunnitteluvirheet havaitaan ja korjataan nopeasti suunnitteluvaiheessa (eri suunnittelijoiden risteilytarkastelut, pääsuunnittelijan yhteensovitus, model check). o Havainnollisuus ja ymmärrettävyys helpottuu oleellisesti monimutkaisten ja teknisesti vaativien rakenteiden suunnittelussa ja toteutuksessa. o Voidaan varmistua esim., että suunnitellut raudoitukset mahtuvat niille kuuluville paikoilleen rakenteisiin, tarvittaessa voidaan tutkia niiden asennettavuuttakin. o Taataan rakenteiden ja LVIS-/ laitostekniikan yhteensopivuus.

9 4/55 o Mallista voidaan antaa xyz-koordinaatiopohjaista tietoa esim. työmaalle sekä digitaalista tietoa tuoteosa- ja elementtivalmistajan tarpeisiin. o Rakennuksen/ laitoksen ylläpito ja muutostehtävissä voidaan hyödyntää tuotemallia. o Tiedonkulku osapuolten välillä paranee o Rakennesuunnittelijan kustannustietous paranee Rakennuksen tuotemallia voidaan oivallisesti käyttää myös kohteen projektin hallinnan työkaluna mm. yksittäisen suunnittelijan, koko suunnitteluryhmän,pääsuunnittelija, kuin projektin johdon kannalta. Tämä vaatii luonnollisesti sen, että kyseiset projektin hallintaan liittyvät tiedot syötetään jossain muodossa tuotemalliin ja että on olemassa työkalu jolla ohjaustoimet ja seuranta saadaan tehtyä ja raportoitua. Seuraavassa on esitetty projektin hallintaan liittyviä mahdollisuuksia ja lisäarvoja, joita tuotemallipohjaisella ohjelmistolla voidaan tuottaa: o Aikataulutus 4D - voidaan hyödyntää mm. kokonaisvaltaisessa aikatauluttamisessa, työn eteneminen seurannassa (valmiusaste), tuotannon ja työmaan johtamiseen. o Määrälaskenta korvaa perinteisen dokumenteista tapahtuvan määrälaskennan? Suunnittelijoiden tuottaman tuotetiedon perusteella saadaan varhaisessa suunnitteluvaiheessa tuoteosa- ja määrätietoa. Alustavan rakennusosamallin teko, josta saadaan määrät ja rakenteet on nopeaa. o Kustannukset - kustannustieto eri hankevaiheissa on liitettävissä tiloihin, rakennusosiin jne o Elinkaaritiedon hallinta (LCA, LCC, LCI), mahdollistaa vaihtoehtotarkastelut kustannusmielessä: - elinkaaritiedon syöttäminen tehdään järjestelmällisesti ja välittömästi aina, kun ominaisuustieto täsmentyy - hyödyntäminen FM:ssä - hyödyntäminen korjaus- ja ylläpitotoiminnassa o Suunnittelutyön seuranta, suunnittelun ohjaus o Suunnitelmien tarkastus ja hyväksyminen; suunnitelmakatselmukset o Suunnitelmien kommentointi - punakynätoiminto o Suunnitelmien yhteensovitus, risteilytarkastelut RakMK A2, päärakennesuunnittelijan tehtäväluettelo o Havainnollistaminen, visualisointi, simulointi o Viranomaismenettelyt - esim. statiikan tarkastaminen - visualisointi Mikäli em. lisäarvojen tuottaminen vaatii suunnittelijalta lisäsuunnittelua normaaliin tehtävämäärittelyyn (RAK 95 Rakennesuunnittelun tehtäväluettelo) verrattuna, tulee lisätehtävistä projektikohtaisesti sopia. Uusien mahdollisuuksien ja lisäarvojen hyödyntäminen ei ole pikavoittojen lunastamista vaan pitkäjänteistä, kehityspanostusta vaativaa toimintaa, jossa korostuu järkevä tuotteistaminen verkostoituminen ja luottamukselliset yhteistyökumppanuudet eri hankeosapuolten kesken.

10 5/55 4 RAKENNESUUNNITTELUN TEHTÄVÄT Tämän päivän rakennesuunnittelutoimeksiannoissa rakennesuunnittelutehtävät määritetään yleisten tehtäväluetteloiden perusteella; tällaisia tehtäväluetteloita ovat mm: o Rakennesuunnittelun tehtäväluettelo RAK 95, RT o Asuntosuunnittelun tehtäväluettelo RT Ko. tehtäväluettelot on rakennettu noudattaen perinteistä hankevaihejaottelua, jossa vaiheet ovat: o Tarveselvitysvaihe o Hankepäätös o Hankesuunnitteluvaihe o Investointipäätös o Luonnossuunnitteluvaihe o Toteutussuunnitteluvaihe o Rakentamispäätös o Rakentamisvaihe o Vastaanottopäätös o Käyttöönottovaihe o Takuiden vapauttaminen Edellä mainittu jaottelu sopii huonosti jo nyt käytössä oleviin suunnittelun ja rakentamisen prosesseihin. Käytännössä ollaan menossa lineaarisesta toimintamallista arvoverkottuneeseen toimintotapaan, jossa suunnittelun ja rakentamisen prosessit lomittuvat keskenään eri tavoin riippuen toteutustavasta. Kun mietitään sitä, miten tuotemallipohjainen suunnittelu vaikuttaa suunnittelun aikataulutukseen, tehtäviin, niiden painotuksiin ja mahdollisiin lisätehtäviin kannattaa palauttaa mieliin vanha kaavio kustannusten määräytymisestä rakennushankkeessa. Kuva 4.1 Kustannusten muodostuminen rakennushankkeessa

11 6/55 Varsinkin kun vielä otetaan huomioon koko rakennuksen elinkaari myös rakennuksessa harjoitettavassa toiminnasta aiheutuvine kustannuksineen (Kuva 4.2) havaitaan ne suunnittelutoiminnot, joihin tuotemallipohjaisessa suunnittelussa tulee keskittyä ja havaitaan ne erot, jotka tuotemallipohjaisella suunnittelulla on perinteiseen toimintatapaan verrattuna. Kuva 4.2 Rakennuksen elinkaarikustannusten muodostuminen Keskeiset erot ovat seuraavat: o Rakennesuunnittelija tulee kytkeä mukaan hankkeeseen nykyistä aikaisemmassa vaiheessa, jotta mallista saadaan alusta lähtien 100% hyöty irti. o Tehtävämäärittely ja tavoitteet suunnittelulle tulee sopia mahdollisimman varhaisessa vaiheessa ja ottaen huomioon tuotemallin avulla saavutettavat lisäarvot. o Lähtötiedot tehtävät ketju tulee sopia koko suunnitteluryhmän kesken projektikohtaisesti entistä huolellisemmin, jotta malli saadaan tuotettua mahdollisimman tehokkaasti ja parhaiten hyödynnettävästi. o Hanke- ja luonnossuunnitteluvaiheessa mallintaminen tulee tehdä mahdollisimman kevyesti (vrt. lukuisat vaihtoehtotarkastelut) ottaen huomioon ko.. vaiheessa mallista vaadittavat tietotarpeet (simulointi, visualisointi, toiminnalliset tarkastelut, kustannusvertailut, elinkaarikustannukset, rakennettavuus jne.) o Toisaalta suunnittelun painopistettä tulee siirtää enemmän luonnossuunnitteluvaiheeseen, jotta tuotemallipohjaisen suunnittelun mahdollistamat tarkastelut saadaan tehtyä ja hyödyt saavutettua. o Toteutus- ja tuotantosuunnitteluvaiheessa mallintavan suunnittelun alkuvaiheeseen tulee varata enemmän resursseja (aikaa) johtuen kaiken toteutuksen vaatiman tiedon syöttämisestä malliin. Tulosteiden tekeminen mallin rakentamisen jälkeen on vastaavasti perinteistä nopeampaa. Aikasäästöt perinteiseen suunnittelumenetelmiin verrattuna syntyvät mm. koko suunnitteluryhmän tiedon siirron nopeutumisesta (vaiheistus lyhenee) ja tehostumisesta sekä rutiinien automatisoitumisesta. o Mallintamistarkkuus hankkeen eri vaiheissa tulee sopia suunnittelijakohtaisesti. o Tuotemallin käyttö luo paremmat edellytykset vastaavalta rakennesuunnittelijale laatia koko rakennuksesta (rakenteesta) staattinen malli kaikkine oleellisine rakennusosineen, liitoksineen ja kuormituksineen; ko. mallia voidaan käyttää lähtötietona ja referenssinä mikäli rakennesuunnittelu on jaettu eri osapuolille (tuoteosasuunnittelu jne.) sekä myös hyväksyttämisaineistona mahdollisessa suunnittelun erillistarkastustoiminnassa. Suunnittelijan ja suunnittelun tilaajan tulee yhdessä sopia ja sisäistää tuotemallisuunnittelun mahdollistamat lisäarvot projektille ja sitä kautta arvottaa tuotemallisuunnittelun hinta.

12 7/55 5 VASTUUT JA OIKEUDET TUOTEMALLIPOHJAISESSA SUUN- NITTELUSSA Rakennesuunnittelijan tehtävät ja vastuut on määritelty maankäyttö- ja rakennuslaissa sekä mm. työturvallisuuslaissa ja asetuksissa, Rakentamismääräyskokoelmassa (A2) sekä mm. Rakennesuunnittelijan tehtäväluettelossa (RAK 95, RT 10025); oikeuksia on määritetty mm. Tekijänoikeuslainsäädännössä. Rakennesuunnittelusopimuksissa konsultin ja tilaajan asema ja vastuut sekä tekijän oikeudet määritetään yleensä Konsulttitoiminnan yleisten sopimusehtojen (KSE 95) mukaisesti. Tuotemallipohjaisessa suunnittelussa tulee vastuu- ja oikeuskysymyksiin uusia näkökulmia mm. seuraavista syistä: o tehtäväjaot ja määrittelyt vaihtelevat, koska ollaan siirtymävaiheessa uuteen toimintamalliin o tuotettua tietoa käytetään uusiin tarkoituksiin (määrätieto, kustannustieto, elinkaaritieto, FM-tieto, ominaisuustieto jne.) o käytettäessä mallintavassa suunnittelussa ns. yhteistä tuotemallia (ks. kuva 8.3.1) korostuvat vastuu- ja oikeuskysymykset, koska eri alojen suunnittelijat käyttävät reaaliaikaisesti samaa mallia ja tietokantaa. o ProIT-projektissa on nimetty erillinen työryhmä, joka miettii vastuu- ja oikeuskysymyksiä nimenomaan tuotemallipohjaisen suunnittelun kannalta. o Suunnittelijan näkökulmasta voidaan todeta, että tuotemallipohjaisen suunnittelun sopimustilanteessa tulisi käyttää nykyisiä Konsulttitoiminnan yleisiä sopimusehtoja (KSE 95) vastuu ja oikeuskysymysten määrittelemiseen ja RAK 95-tehtäväluetteloita tehtävien määrittelemiseen niin kauan kuin em. ehdot ja luettelot tulevat päivitetyiksi koskemaan tarkemmin tuotemallipohjaista suunnittelua. Tarve ko. päivittämiselle on varmasti olemassa. Tuotemalliin toteutetusta tiedosta on aina vastuussa tiedon tuottaja. Mikäli kohteessa on useita eri rakennesuunnittelijoita, tulee päärakennesuunnittelijan koordinoida tietojen siirto yhteiseen rakennemalliin sekä edelleen yhteiseen tuoteosamalliin. Mikäli yhteisellä tuotemallilla on erikseen suunnitteluohjeessa määrätty hallinnoija, rajoittuu hänen vastuunsa vain tiedon keräämiseen tiedon tuottajilta. Hallinnoijalla voi edelleen suunnitteluohjeessa määritetyllä tavalla olla oikeus antaa uusia attribuutteja eri suunnittelijoiden yhteiseen malliin tuottamalle tiedolle. Pääsuunnittelijan vastuut tuotemallista tulee määritellä suunnitteluohjeessa. Pääsuunnittelijan vastuu rajoittuu tuotemallisuunnittelussa lähinnä vastuuseen siitä, että eri suunnitteluosapuolet ovat tuottaneet yhteiseen tuotemalliin sovitut tiedot ja rakennusosat. Pääsuunnittelijan tulee myös huolehtia eri suunnittelualojen suunnitelmien yhteensopivuus, mutta vastuu suunnitelmien yhteensopivuudesta tulee olla vastaava kuin perinteisesti tapahtuvassa suunnittelussa.

13 8/55 6 TUOTEMALLINNUKSEN PERIAATTEET 6.1 Yleistä Tuotemalliin pohjautuvaan suunnittelussa voi suunnittelijoiden työnjako muuttua. Päärakennesuunnittelijalle voi siirtyä enemmän aiemmin tuoteosasuunnittelijoille kuuluneita tehtäviä. Erillisen tuoteosasuunnittelijan työmäärä vähentynee nykyisestä, koska nykyinen ohjelmistokehitys tukee kehitystä, jossa kaikki suunnittelutyö tehdään samalla ohjelmalla yhdessä paikasssa. Eri ohjelmistovalmistajien tulisi tehdä ohjelmistonsa tuotemallinnusohje, joka on suunnattu nimenomaan suunnittelijoille, pohjautuen Suomessa käytössä oleviin suunnittelutapoihin. Näiden ohjelmistokohtaisten tuotemallinnusohjeiden perusteella pääsuunnittelija laatii projektin yhteisen tuotemallinnusohjeen yhteistyössä muiden suunnittelijoiden kanssa. Mikäli projektiin osallistuu useita rakennesuunnittelijoita (vaikka vain yhdestä toimistosta), tulee laatia rakennesuunnittelijan tuotemallinnusohje, joka minimissään sisältää: suunnittelurajat ja oikeudet eri suunnittelijoiden välillä ohjeet rakenneosien numeroinnista ohjeet tasojen ja luokkien (phases, layers ja classes) käytöstä rajapintojen mallinnuksen ohjeet Suositeltavaa olisi sisällyttää ohjeeseen lisäksi eri suunnittelijoiden oikeudet mallissa (esim. valvonta-, muokkaus-, luku-, kirjoitus-, poisto- ja erikoiskäyttöoikeus). Mikäli hankkeessa on useita eri rakennesuunnittelijoita, jotka käyttävät samaa yhteistä rakennemallia, tulee ohjeessa lisäksi määritellä käytettävät tiedonsiirtomuodot. Edut suunnittelijalle Tuotemallinnus oikein käytettynä parantaa suunnitelmien laatua ja virheiden määrää voidaan eliminoida tehokkaiden tarkistustyökalujen avulla. Suunnittelutyön laatu / työaika-suhde paranee mallintavan 3D-suunnittelutyön avulla. Saadaan uusia tietoja ja tulostuksia. Suunnittelutyön tuloksena saadaan piirustuksia (ks. Kuva 6.1.1), raportteja, tarvikeluetteloita ja valmistustietoa (ks. Kuva 6.1.2).

14 9/55 Kuva Teräsbetonipilarin valmistuspiirustus. Teräsrakennesuunnittelun kokemusten mukaan mallintava suunnittelu on poistanut suunnittelun mittavirheet. Mallintavan suunnittelun tarkastusvälineet, suunnitteluvälineet ja visuaalinen näkymä antavat suunnittelijalle useampia mahdollisuuksia havaita mahdollisesti syntyvät virheet. Tulostetut suunnitelmat ovat täsmälleen 3D-mallin mukaisia. Inhimillisien virheiden mahdollisuus on kuitenkin aina olemassa. Esimerkiksi rakenne on mallinnettu väärin lähtötiedoista tai valittu rakennemalli ei vastaa todellisuutta. Mallintava 3D-ohjelmisto on vain yksi suunnittelun apuväline. Kuva Rakennusosamallin tuoteosatiedosta tehty valmistajakohtainen ontelolaattaluettelo. Vaatimukset suunnittelijoille

15 10/55 Ohjelmistot ovat suunnittelun apuvälineitä, joiden käyttö usein vaatii suurempaa ammattitaitoa, kuin perinteiset CAD-ohjelmistot. Suunnittelutoimistolle aiheutuu kustannuksia ohjelmiston hankinnasta, suunnittelijoiden koulutuksesta sekä tuotemallinnuksen mahdollisesti tuomista uusista tehtävistä (esim. 4Dsuunnittelu), sekä tuotemallinnuksen yhteydessä syntyvistä eri luetteloiden ja listojen laatimisesta. Ensimmäisten suunnittelutoteutusten yhtäjaksoinen läpivienti mallintavalla 3D-ohjelmistolla edellyttää ohjelmiston hyvää käyttötaitoa ja useimmiten voidaan vaatimuksena pitää, että projektiryhmässä on vähintään yksi henkilö, jolla on aiempaa kokemusta ohjelmasta. Tällöin jokainen työvaihe voidaan todennäköisesti toteuttaa loppuun asti tuotemallintamisella.

16 11/55 Projektinhallinta Nykyiset ohjelmat eivät mahdollista eri suunnittelualojen toimimista täydellisesti samassa tuotemallissa, elleivät eri suunnittelualat käytä samaa ohjelmistoa. Toistaiseksi joudutaan tyytymään siihen, että eri suunnittelualojen tuotemalleista yhdistetään yhteinen tuotemalli eri tarkastuksia sekä visualisointia varten. Suunnitteluohjeessa tulee olla määrittely siitä, mitä eri suunnittelualat siirtävät yhteiseen malliin ja millä tarkkuudella siirto tapahtuu. Usean suunnittelijan projekteissa projektihallintaan tarvitaan yhteistä toimintaa tukeva ja mallin hallinnointia helpottava projektinhallintatyökalu. Projektinhallintatyökalun käyttömahdollisuuksia: o käyttöoikeuksien jakaminen ja hallinnointi (esim. luonti, muokkaus tai täysi oikeus rakenneosaan) o suunnittelijakohtaisten mallintamisrajojen luominen (esim. ARK/RAK) o työn visuaalinen tarkistus o oikeuksien määrittäminen eri suunnittelijoille (esim. rakenneosakohtaiset oikeudet) Suunnitteluohjelmistoja tulee kehittää siten, että eri käyttötarpeen omaavat käyttäjät voivat määritellä eri attribuutteja kuitenkaan pystymättä vaikuttamaan muihin kuin niihin attribuutteihin, joihin määrittelyoikeus on annettu. 6.2 Visio tuotemallipohjaisesta suunnittelusta Kaikki rakennuksen elinkaaren aikana tarvittava tieto löytyy yhdestä paikasta (esim. linkitetyt tietokannat) ja tieto on helposti ohjelmistoriippumattomasti haettavissa. Tietoa käsitellään vain kulloisenkin tarpeen mukaan, eikä ko. tarpeeseen turhaa tietoa käsitellä (vrt. tietokonepelit). Ohjelmisto tuottaa avoimen mallitietokannan, joka on perustana ohjelmiston tuottamalle valmistustiedolle. Tiedon siirtäminen valmistajien käytössä oleviin tai kehitettäviin tuotannonhallinta- ja tuotannonohjausjärjestelmiin tulee mahdollistaa tästä mallitietokannasta. Avoin mallitietokanta mahdollistaa sovelluskehityksen ohjelmointirajapinnan avulla. Tällä hetkellä konepajateollisuuden järjestelmät saavat tarvittavat syöttötiedot jo suoraan ohjelmistojen mallitietokannasta erilaisten tiedonsiirtoformaattien avulla. Tietoliikenteen ja Internetin tarjoamat palvelut tiedon ja kommunikoinnin välittämiseen voitaisiin ottaa ohjelmistoon integroidusti mukaan. Projektipalaverin voi tietoliikenneyhteyksien avulla suorittaa työn ääressä. Tämä toimii jo joissain ohjelmistoissa. Tietoliikenneyhteyksien kehittyminen mahdollistaa myös uusien osapuolten liittymisen tuotemalliin ja uusien lisäarvoa tuottavien ominaisuuksien käyttöönoton. Esimerkiksi tehdas voi päivittää valmistustiedot malliin ja työmaa on reaaliaikaisesti selvillä valmistustilanteesta ym.

17 12/ Rakennesuunnittelun prosessimalli Rakentamisen eri prosessimalleja on käsitelty Pro It hankkeen osaprojekteissa (esim. VTT ja K. Karstila). Kuva Päärakennesuunnittelijan prosessikuvaus, jossa on esitetty vain päärakennesuunnittelijan tietovaihto, eri hanketahojen kanssa. Malli asuntosuunnittelun prosessista sekä rakennesuunnittelijan roolista ja tehtävistä siinä on kehitetty Suunnittelun laatu projektiin pilottikohteessa As.Oy Sorsavuori. Ko. aikataulutettu prosessikaavio havainnollistaa tietovirtoja suunnitteluryhmän sisällä ja valottaa tapaa miten myös tuotemallisuunnittelua tulee purkaa osatehtäviin ja aikataulutetuiksi tietovirroiksi niin, että mallintamisen edut saadaan maksimoitua (ks. liite 4).

18 13/55 Kuva Elementtisuunnittelijan prosessikuvaus. Elementtisuunnittelijan lähtötietoluettelo on liitteenä (ks.liite 5). Elementtisuunnittelun tiedonhallinnasta on tarkempi kuvaus RT-kortistossa (ks. RT ). 6.4 Rakennesuunnittelun lähtötiedot tuotemallinnuksessa Lähtötietojen varmistettu siirtyminen suunnittelun pohjaksi ja oikeellisuus on perusta koko suunnitteluketjun työn onnistumiselle. Lähtötietojen määrittämiseksi tulee käyttää yhteistä tiedonsiirtoformaattia ja ohjelmistokehityksen tulee tukea yhteisen tuotemallin määrittelyyn perustuvaa tallennusformaattia.ohjelmistojen väliseen tiedonsiirtoon on käytettävä tarvittaessa omaa muunto-ohjelmistoa, joka kykenee muuttamaan ohjelmistomäärittelyn mukaisen tiedon yhteistä tuotemallia varten. Pääsuunnittelijan velvollisuuksiin kuuluu myös tuotemallipohjaisessa suunnittelussa varmistaa, että eri suunnitteluosapuolet ovat siirtäneet tuotemallinnusohjeessa määritellyt toisten suunnittelijoiden tarvitsevat tiedot yhteiseen tuoteosamalliin tai välittäneet ne yhteisesti sovitulla tavalla. Lisäksi pääsuunnittelijan velvollisuuksiin kuuluu valvoa, että yhteisen tuotemallin tiedot eivät ole keskenään ristiriitaiset. Vaatimuksia kaikille lähtötiedoille: o oikea-aikaisuus o riittävä tarkkuus o oikeellisuus (kukin suunnittelija vastaa omien suunnitelmiensa oikeellisuudesta) o varmistettava tarvittaessa lähtötietojen oikeellisuus käyttämällä myös vaihtoehtoista lähtötietoformaattia (esim. CAD piirustus, paperituloste tms) o toimitaan projektin tuotemallisuunnittelun ohjeen mukaisesti

19 14/55 o toimitaan aina samassa globaalissa koordinaatistossa o kohdekohtaisesti sovitaan käytettävät tiedonsiirtoformaatit o toimitaan sovitussa kordinaatistossa Lähtötietojen muodolla on suuri merkitys ja voidaan esimerkiksi selvästi osoittaa, että prosessilaitoksen putkiston todellinen 3D-malli lähtötietona on ratkaisevasti parempi kuin 2Dpiirustukset. Rakennesuunnittelija vastaa, rakenteet eivät törmää putkistoon tms. ja tarpeellisin kohdin rakenteisiin tehdään varauksia. Tällainen tarkastelu suuressa kohteessa on paljon työtä ja tarkkuutta vaativaa lähtötietojen ollessa 2D-piirustuksia tai sähköisiä tasokuvia. Tällaista tiedonsiirtymistä kaivataan myös arkkitehdin käyttämästä ohjelmistosta rakenne- ja elementtisuunnittelijan työympäristöön. Tällä hetkellä ongelmana on usein arkkitehdin / LVIS / rakennesuunnittelijan käyttämien järjestelmien yhteensopimattomuus. Tähän tuo lähiaikoina selkeää parannusta esim. IFC- standardin mukainen tiedonsiirto. Mallin koordinaatiston on oltava globaalissa koordinaatistossa. Mallissa olevia rakenneosia ja elementtejä on pystyttävä kokoonpano- tai elementtikohtaisesti luomaan paikalliseen koordinaatistoon, mutta näiden sijainti globaalissa koordinaatistossa on hallittava. Liitteenä on rakennesuunnittelijan yksityiskohtainen lähtötietokaavake. (Liite 6) Tilaajan toimittamat lähtötiedot Tilaajan vastuulla on tuotemallisuunnitteluohjeen laadinnan varmistaminen. Tuotemallisuunnitteluohjeen laadinta tulee olla myös määritelty selvästi suunnittelusopimuksessa niin kauan kun yhteisesti sovittua uutta tehtäväluetteloa ei ole käytettävissä. Tilaajan tulisi kantaa vastuuta, että eri osapuolet rakennushankkeessa saavat tarvitsemansa tiedon oikea-aikaisesti ja tarkkaan määritellyssä tiedonsiirtoformaatissa. Eri suunnittelijaosapuolet tarvitsevat oman suunnittelunsa pohjaksi hyvin erilaisia suunnittelutietoja. Suunnittelutiedon siirtämiseksi eri ohjelmistojen välillä pitää tilaajan sopia yhteiset tiedonsiirto- ja tiedonhallintaohjeet Käyttäjän toimittamat lähtötiedot Pääsuunnittelijan ja tilaajan on varmistettava, että käyttäjän lähtötiedot ja muutokset siirtyvät suunnitteluketjussa eteenpäin. Muutoksesta on ilmoitettava eri suunnittelijaosapuolille ja on varmistuttava siitä, että muutostieto kulkee suunnitelmatuloksiin Muiden suunnittelijoiden toimittamat lähtötiedot Suunnittelijoiden tuottamat suunnitelmatulokset ovat yleisesti toisen osapuolen lähtötietoja kyseistä työvaihetta varten. Suunnittelijoiden on kyettävä esittämään suunnitelmien tulosteet tuotemallin määrittelyjen mukaisesti. Suunnittelijoiden tulee yhteiseen malliin siirtäessä omia tietojaan varmistua siitä, että määritykset on tehty suunnitteluohjeen mukaisesti. Pääsuunnittelijan velvollisuus on ylläpitää yhteistä tuotemallia ja varmistua siitä, että kaikki hankkeeseen kiinnitetyt suunnittelijat tuovat suunnitteluohjeessa määritellyt tiedot sovittuna aikana yhteiseen malliin.

20 15/ Muiden osapuolien toimittamat lähtötiedot Eri osapuolien on kyettävä vastaanottamaan, hyödyntämään ja kirjoittamaan tuotteistettua rakennusosatietoa. Tarkasti määritelty rakennusosatieto on saatava tarvittavassa laajuudessa eri osapuolilta tuoteosamallista. Kuva Esimerkkikohteen lähtötietoluettelo. 6.5 Tuotemallinnuksen vaiheet, tuotemallin rakenne Mallinnuksen vaiheet suunnittelussa Rakennushankkeiden läpivienti perustuu useimmiten tänä päivänä RT - kortistossa esitettyyn hankevaiheistukseen, jota on kuvassa verrattu tuotemallisuunnittelun tyypilliseen tapaukseen. Huomionarvoista on tiedon katkeamaton lisääntyminen mallissa ja suunnittelun painopisteen siirtyminen aikaisemmaksi.

21 16/55 Kuva Esimerkki hankevaiheistuksesta Kuten jo todettua nykyinen hankevaiheistus ei suoraan sovellu nykyaikaiseen projektin toteutusmalleihin ja tuotemallipohjaiseen suunnittelukäytäntöön (BIM = Building Information Model). Seuraavissa kappaleissa ja kuvassa on peilattu tuotemallipohjaista suunnittelua em. hankevaiheisiin ja yleisesti käytössä olevia mallinnusvaiheita (vrt. Arkkitehdin tuotemallisuunnittelu ohje Kuva 4.1-1) rakennesuunnittelijan tuotemallipohjaisen suunnittelun vaiheisiin. Jäljempänä on kuvattu arkkitehdin kaikkia mallityyppejä rakennesuunnittelijan näkökulmasta. Kaikkia mallivaiheita ei yleensä tarvita rakennesuunnittelussa. Tuotemallinnuksen mallivaiheet Vaatimusmalli ja tilamalli Arkkitehti tekee vaatimusmallin tarveselvitysvaiheessa. Vaatimusmalli on hyvin karkea tilamallin luonnos. Rakennesuunnittelija osallistuu vaatimusmallin luomiseen oman tehtäväkuvauksensa mukaisilta osin. Vaatimusmalli on lähtötietona jatkossa seuraaville tarkemmille malleille. Myöhemmissä vaiheissa mallin tietoa täydennettäessä sitä tulee aina verrata vaatimusmallin vaatimuksiin. Nykykäytännön mukaiset hankevaiheet ja tehtävät eri vaiheissa Tarveselvitys Vrt. RT , kohta 1. Tarveselvitysvaiheen tehtävät eivät nykykäytännössä kuulu rakennesuunnittelijan perustehtäviin. Tarveselvitysvaiheessa voidaan rakenteellisten selvitysten avuksi luoda vaatimusmalli tai alustava rakennusosamalli. Mallin avuksi voidaan ottaa arkkitehdin luoma vaatimusmalli tai tilamalli.

22 17/55 Hankesuunnittelu Vrt. RT , kohta 2. Hankesuunnitteluvaiheen tehtävät eivät nykykäytännössä kuulu rakennesuunnittelijan perustehtäviin. Hankesuunnitteluvaiheen aikaisia tehtäviä varten voidaan mahdollisesti tehdä alustava rakennusosamalli. Hankesuunnitteluvaiheessa on rakennesuunnittelijan tarvittaessa luotava alustavia rakennusosamalleja eri runkovaihtoehdoista. Alustavan rakennusosamallin merkitystä myöhemmissä suunnitteluvaiheissa tulisi korostaa. Alustava rakennusosamalli Rakennesuunnittelija voi hyödyntää arkkitehdin luomaa alustavaa rakennusosamallia. Malleja voi olla useampia eri ratkaisuvaihtoehtoja varten. Mallia voisi rakennesuunnittelussa kutsua luonnosmalliksi Luonnossuunnittelu Vrt. RT , kohta 3. Luonnosvaihe pitää sisällään ratkaisuvaihtoehtojen laatimisen, ehdotuksen laatimisen ja luonnosten laatimisen. Luonnossuunnitteluvaiheessa rakennesuunnittelija luo luonnosmallin (ks. Kuva 6.5.1). Yleensä luonnos- ( ja urakkasuunnittelun) malli on eri kun varsinaisen toteutussuunnittelun malli, mutta tiedonsiirron varmistamiseksi eri vaihtoehdoissa myös luonnossuunnittelu tulee määritellä projektin suunnitteluohjeessa. Malleja voi olla useampia eri ratkaisuvaihtoehtojen luonnossuunnittelua varten. Yleensä on edullisinta laatia eri vaihtoehdot omiin malleihinsa, mutta noudattaen kuitenkin suunnitteluohjeen määrittelyjä tasojen ja luokkien käytöstä, jotta tarvittaessa vaihtoehdot voidaan koota samaan malliin Mallia tarkennetaan tuoteosavalintojen mukaan. Rakennusosamallin avulla pitää pystyä tuottamaan vaiheen suunnitteludokumentit. Arkkitehdin luonnossuunnitteluvaiheen alustava rakennusosamalli toimii rakennesuunnittelijan lähtötietona. Tuotemallipohjainen suunnittelu mahdollistaa jo varhaisemmassa suunnitteluvaiheessa määrä- ja rakennusosatietojen hyödyntämisen; ko. tiedot voivat tässä vaiheessa olla ominaisuustietoa (esim. raudoitus 80 kg/m³

23 18/55 jne). Tieto tarkentuu suunnitelmien edetessä yksityiskohtaisempien detaljien suunnitteluun. Tuotemallipohjaisen suunnittelun myötä saadaan suunnitelmatuloksia hyödynnettyä tehokkaammin.. Valmisosatoimittajille on mahdollista luoda valmisosakohtaisia määrätietoja alustavaa valmisosasuunnittelua varten jo luonnossuunnitteluvaiheessa. Rakennusosamalli Arkkitehdin rakennusosamallin pohjalta rakennesuunnittelija voi luoda oman rakennusosa- eli rakennemallin. Rakennusosamalli luodaan toteutussuunnitteluvaiheessa. Rakennusosamallin hyödynnettävyys on merkityksellinen rakennesuunnittelun kannalta. o Rakennemalli = päärakennesuunnittelijan kokonaisuuden hallintamalli (staattinen malli, kuormitukset, oleelliset vaatimukset jne.) Rakennesuunnittelija luo toteutussuunnittelua varten rakennemallin. Rakennemallissa tuoteja rakennusosat on määritelty valmistus- ja tuotantosuunnittelua varten riittävän tarkasti. Rakennemallista rakennesuunnittelija luo toteutus- ja tuotantosuunnitelmat. Rakennemallia voivat hyödyntää myös muut suunnittelijat. Valmisosasuunnittelun lähtötietoina on olennaisen tärkeää hyödyntää rakennemallia. Tuoteosamalli Tuoteosamalli on täydennetty rakennusosamalli. Tuoteosamalliin on arkkitehti/rakenne- /tuoteosasuunnittelija tehnyt rakennusosakohtaisesti tarkennuksia toteutussuunnittelua varten. Tuoteosamallin runkorakenteiden tuotetiedon tulee siirtyä myös rakennesuunnittelijan rakennemalliin tarpeellisilta osin. Tuoteosamallin tuoteosatieto on merkittynä usein rakenneosille erillisenä ominaisuutena. Toteutussuunnittelu Vrt. RT Rakennesuunnittelun tehtäväluettelo, kohta 4 Toteutussuunnittelu. Toteutussuunnittelu pitää sisällään Toteutussuunnitelman laatimisen (ns. urakkalaskentasuunnitelmat) ja Tuotantosuunnitelmien laatimisen (suunnitelmat tuotantoa ja rakentamista varten sisältäen valmisosasuunnitelmat). Toteutussuunnitelman laatiminen Toteutussuunnittelun pohjana rakennesuunnittelijalla on eri suunnittelijoiden hyväksytyt luonnokset (alustavat rakennusosamallit), kuormitustiedot, toteutustapa ja aikataulu. Toteutussuunnitelmien laatimisvaiheessa rakennesuunnittelija täydentää oman alustavan rakennusosamallinsa rakennusosamalliksi (=Rakennemalli). Lähtötietojen siirtyminen tulee onnistua yhteisestä tai erillisistä rakennusosamalleista rakennesuunnittelijan lähtötiedoksi. Tämä edellyttää, että eri suunnittelijat luovat omia tuotemallisuunnitelmiansa yhteisesti sovittujen määrittelyjen mukaisesti. Mikäli toteutussuunnitteluvaiheessa hankkeeseen kiinnitetään esim. tuoteosasuunnittelija tulee mallinnusvastuiden olla määritelty jo suunnittelusopimusta määriteltäessä. Toteutussuunnitteluvaiheessa on oleellista, että vastaava rakennesuunnittelija saa rakenteiden kokonaisuuden hallinnan kannalta kaikki tiedot rakennemalliinsa muilta hankkeessa mahdollisesti olevilta tuoteosasuunnittelijoilta. Tuoteosasuunnittelijalle voidaan siirtää tietoa esim. objektien attribuuteilla päärakennesuunnittelijan tuoteosamallista tuoteosasuunnittelijan malliin.

24 19/55 Toteutussuunnitteluvaiheen tulostustapa on perinteisten paperitulosteiden lisäksi sähköiset suunnitelmat ja dokumentit. Tuotantosuunnitelmien laatiminen Tuotantosuunnitelmien laatiminen sisältää suunnitelmien tarkistamista, jo laadittujen rakennesuunnitelmien täydentämistä ja täydentävien suunnitelmien laatimista sekä valmisosien suunnittelua. Lähtötietoina rakennesuunnittelija tarvitsee RAK95 kohdan 4.2 mukaiset lähtötiedot. Tuotantosuunnitelmien laadintavaiheessa rakennusosamalli (Rakennemalli) täydentyy tuoteosamalliksi joko siten, että rakennesuunnittelija tekee itse malliinsa ko. täydentämisen tai erillisten tuoteosasuunnittelijoiden tekemistä tuoteosamallista kokonaisuuden kannalta oleellinen tieto siirretään rakennemalliin (ks. kuva 6.5.1). Tuoteosamallissa on rakenneosat määritelty rakennusosakohtaisesti sen tuotanto huomioiden. Rakenteiden suunnittelussa käytetään tässä vaiheessa todellisia rakenne- ja tuoteosia. Tuotemallipohjaisten suunnittelutyökalujen tulee käsittää myös liitos- ja kerrosrakennetyökalut, joilla on mahdollista tehdä toteutussuunnittelua varten riittävän tarkka tuoteosamalli. Tuoteosamallin määrittely ja sen tarkkuus riippuu valmistusta varten tarvittavan tiedon laajuudesta ja tasosta. Vakioitua tuoteosavalmistusta varten ei tarvita kaikkia suunnitteludimensioita, koska niiden valmistusta edeltää erillinen tuoteosasuunnittelu. Tuoteosamallin tarkkuuden määrää rakennesuunnittelijan (tuoteosasuunnittelijan) tehtävän laajuus. Tuoteosasuunnitelmaa tehtäessä erillisen tuoteosasuunnittelijan olisi syytä saada rakennesuunnittelijan rakennemalli tuoteosasuunnittelun lähtötiedoksi oleellisilta osiltaan. Tuoteosasuunnittelijoiden tulee noudattaa vastaavan rakennesuunnittelijan laatimaa projektin tuotemallinnusohjetta. Heidän tuottamansa tieto palautetaan vastaavalle rakennesuunnittelijalle, joka kontrolloi kaikkien suunnittelijoiden yhteiseen malliin vietyä ra-

25 20/55 kennesuunnittelua. Tuoteosasuunnittelijoiden malli tulee aina olla vastaavan rakennesuunnittelijan käytettävissä. Voidaan olettaa, että siirtyminen tuotemallipohjaiseen suunnitteluun lisää vastaavan rakennesuunnittelijan tehtäviä ja toisaalta vähentää vastaavan tuoteosasuunnittelijoiden tehtäviä Tuotemallipohjainen suunnittelu tuo mukanaan erilaisia suunnitelmien tarkistamistyökaluja, esim. mahdollisuudet liitosten ja raudoitteiden törmäystarkasteluun. Visuaaliset tarkistusmenetelmät ovat tuotemallintamisen myötä suunnittelijoiden käytössä. Tuotantosuunnitelmia varten rakennesuunnittelija ohjaa ja valvoo varaustiedon kokoamista. Helpoin tapa hoitaa varausten teko tuotemallipohjaisessa suunnittelussa on seuraava: Eri suunnittelijat (Sähkö, LVI, prosessi ja muut) tuovat omat objektinsa yhteiseen malliin, joidenka perusteella rakennesuunnittelija suunnittelee varaukset rakenteisiin sopiviin sijanteihin. Varausten tekemiseen tuotemalliin edellyttää, että reiät luodaan reikäobjekteina kyseisille rakenneosille. Rakennesuunnittelija on aina vastuussa reikien tms. varausten tekemisestä eri osiin. Liitteenä (Liite 7) on erillinen varausmerkintäohje. Tuotemallipohjainen suunnittelu mahdollistaa myös raudoite- ja määräluetteloiden laatimisen. Runko-, seinä- ja kattorakenteiden tarkentuessa määritellään rakennusosille pintamateriaalit ja pintakäsittelyt. Valmisosien (betoni, teräs, puu) suunnittelu on tuotemallipohjaisen suunnittelun myötä lähempänä valmisosien tuotantoa. Suunnittelun alkuvaiheessa voidaan valmisosien tuotannolle laatia määrä- ja tarvikeluetteloita. Luetteloita voidaan käyttää tuotannonsuunnittelussa ja komponenttien tilauksessa komponenttien toimittajalta. Valmisosien suunnittelussa on olennaisen tärkeää, että valmistustieto on virheettömästi ja oikea-aikaisesti sitä tarvitsevalla osapuolella. Valmisosasuunnittelu saadaan tehokkaammin tuotettua, jos lähtötietona on saatavilla ra-

26 21/55 kennesuunnittelijan tuoteosamalli. Valmisosasuunnittelija voi täydentää esim. betonielementtien osalta tätä tuoteosamallia. Elementtien ja valmisosien liitosten ja raudoitteiden siirtyminen yhteiseen tuoteosamalliin tulee mahdollistaa tarkalla tietomäärittelyllä. Tuotemallipohjainen suunnittelu tuo mahdollisuuden valmisosatuotannon kehittämiseen esim. siten, että valmisosatuotannon ohjauksessa ja hallinnassa voidaan hyödyntää tuoteosamallin mallitietokannan tuoteosatietoa. Asennussuunnitelmia sekä aikatauluja voi myös laatia mallitietokannasta saatavan tiedon avulla. Toteumamalli, ylläpitomalli Toteumamalliin päivitetään ja muutetaan alkuperäisistä suunnitelmista poikkeavasti toteutetut rakenteet ja rakenneosat. Toteumamallia päivitetään rakennuksen rakentamisen aikana. Tarkoituksena on hallita toteuma- ja ylläpitomallin avulla rakennuksen elinkaarta. Rakentamis- ja käyttöönottovaiheen suunnittelu Rakentamis- ja käyttöönottovaiheen suunnittelutehtävät. Kuva Alustava rakennemalli.

27 22/55 Kuva Mallinnusohjelmalla luotu kaaviokuva Mallintamistapa Yleistä o tulisi noudattaa yleisiä 2D-suunnitteluohjeita sovellettuna 3D-maailmaan, esim. kuvatasot, värit millä rakenteet esitetään. o tulisi huomioida eri ohjelmistojen erityisvaatimukset ja niiden keskinäinen yhteensopivuus o projekteissa tulee tehdä projektikohtainen mallinnusohje, jossa selvitetään kaikki projektin kululle ja mallinnuksen onnistumiselle tärkeät seikat (tasot, koordinaatistot, tiedonsiirto, ohjelmat ym.) Mallinnuksessa on tärkeätä, että käytetään yleisiä nimekkeitä rakenneosille, eli mallinnetaan esim. pilari pilariobjektilla eikä palkilla. Perustuksia voi mallintaa esim. antura-, seinä- ja pilarityökaluilla, jolloin ohjelmiston tulisi tunnistaa rakennusosat jollakin luokkatunnuksella. Tällöin ei ole suurta merkitystä millä työkalulla eri rakennusosia on mallinnettu. Pääsääntöisesti jokainen rakennusosa tulee mallintaa sille tarkoitetulla työkalulla. Malli tulee jakaa tarpeeksi pieniin osakokonaisuuksiin, tiedonsiirron ja sen jatkokäsiteltävyyden kannalta. Näin referenssien koko ei kasva liian suureksi. Rakennemallin tekemiseen on tänä päivänä Suomessa yleisessä käytössä muutamia mallintavia 3D-ohjelmistoja. Mallintamistapa ja -tarkkuus ovat ohjelmistokohtaisia. Rakennus pyritään mallintamaan samaan malliin. Tässä on myös ohjelmistokohtaisia eroavaisuuksia. Jokin ohjelmisto voi käsitellä eri lohkoja tai kerroksia omina tiedostoina. Tärkeintä on hallita osamallien koordinaatisto ja osien numerointi koko rakennusta kattavasti. Suuren rakennuksen jakaminen pienempiin osakokonaisuuksiin on joskus tarpeellista. Ohjelmistojen tulee tukea yleisimpien rakennusosien lisäksi tuoteosia ja objekteja. Tämän avulla voidaan luoda valmistajakohtaisia erikseen määriteltyjä tuoteosia. Tuoteosien mallintamistarkkuus riippuu rakennusosan käyttötarpeesta rakennemallissa. Rakennus- ja tuoteosien geometria tulee mallintaa pääpiirteissään oikealla tarkkuudella, jotta liittyviä rakenteita voidaan suunnitella riittävän tarkoilla lähtötiedoilla.

28 23/55 Ohjelmistokohtaisista eroavaisuuksista riippuen esim. Sandwich-elementti voidaan joutua mallintamaan useista eri objekteista käyttäen eri työkaluja. Ohjelmistojen tulisi tukea rakennusosakokonaisuuksien luomista. Rakennusosakokonaisuus vastaa tällöin esim. Sandwichelementtiä. Pintarakenteiden ja -käsittelyjen mallintamistarkkuus riippuu ohjelmistokohtaisista ratkaisuista. Rakennusosien pintarakenteita voidaan jossakin ohjelmistossa mallintaa yksityiskohtaisemmin tai ne esitetään vain tietyissä näkymissä omina täyttömerkintöinä ja -kuvioina kuten myös pintakäsittelyt. Mallinnuksessa tulee miettiä kuinka esim. kuvatasoja sekä rakennusosaluokkia voidaan hyödyntää. Kuvatasojen käyttö mallintamisen apuna on perusteltua. Kuvatasojen avulla voidaan hallita eri kerrosten ja lohkojen rakennusosia ja rakennusosakokonaisuuksia. Tasojen avulla voidaan myös tehdä määrä- ja tarvikeluetteloita valmisosatoimittajille. On päätettävä ennen mallinnusta rakenneosien mallintamistapa (käytetäänkö esim. offset toimintaa tms). Esimerkiksi päätetään, tehdäänkö kulmapilari niin, että sen kokoa voidaan muuttaa, ilman että tarvitsee siirtää pilari fyysisesti vai tavalla kaksi, jossa pilarin keskipiste on sidottu ja koon muutoksen seurauksena myös keskipistettä joudutaan siirtämään. Liitoksissa on tarpeen, että liitos on objekti eikä koostu vain yksittäisistä osista. Näin mallista saadaan tuotettua erilaisten liitosten määrät. Tällainen objekti voisi näkyä yhteisessä tuotemallissa esim.viitetietona. Liitoksia varten tulee luoda yleisiä liitosdetaljikirjasto (ohjelmistotoimittajat, materiaalijärjestöt ym.). Toistaiseksi Suomassa on tuoteosavalmistajat tuottaneet liitoskirjastoja vain muutamalle ohjelmistolle ja liitoskirjastot eivät toistaiseksi ole riittävän kattavia. Raudoitukset tulee tehdä ryhmänä, jolloin niiden muuttaminen on käytännöllisempää. Mallinnuksessa voi käyttää jonkun valmistajan kirjastoja tai universaaleja ratkaisuja alkuvaiheessa. Jos näin toimitaan, joudutaan tekemään muutoksia valmiiseen malliin tuoteosatoimittajan valinnan jälkeen. Tämä vaikuttaa suunnitteluun siten, että tuoteosat joudutaan korvaamaan toisella tuoteosalla, jos tuoteosa ei ole riittävän yleinen ja jos sen valmistaja-ominaisuutta ei voi muuttaa. Muiden suunnittelijoiden mallit on pystyttävä lukemaan lähtötiedoksi mallintamiselle. Mallinnustarkkuus ja mallien sisältö on määritettävä kussakin projektissa tuotemallinnusohjeeseen. Liitteenä on rakennesuunnittelun ohjelmistokohtainen tuotemallinnusohjeen sisällysluettelon esimerkki. (Liite 1)

29 24/55 Kuva Tuotemallinnusta varten tehty projektikohtainen rakennusosien numerointi ohje Reikämerkinnät Rei itykset ja muut varaukset tulee mallintaa siten että, muut osapuolet voivat hyödyntää tietoja. Reikä on objekti tai vain reikä riippuen tuotemallin tietomäärittelystä. Reikäobjektista tulee ilmetä kenen varaama se on. Tuotemallin tieto- ja tiedonsiirtomäärittelystä riippuu saadaanko esim. pelkät reiät siirrettyä tuotemallista toiseen. Rei itysohjeet tulee luoda erikseen tuotemallipohjaista suunnittelua käytettäessä. Rei itykset tulisi luoda yhteiseen tuoteosamalliin, josta rakennesuunnittelija voi siirtää ne omaan rakennemalliinsa. Varausten suunnittelussa on oleellista, että seuraavat asiat on otettu huomioon: o yhteensovituksen tulee olla tehty (Model check/ pääsuunnittelija) o varauksesta tulee selvitä miksi varaus on tehty vastuu ko. suunnittelijalla o varaustieto siirretään rakennemalliin ja tarkastetaan varausten soveltuvuus rakennukseen vastuu rakennesuunnittelijalla Liitteenä on tuotemallipohjaisen suunnittelun varausmerkintäohje (Liite 7) Mallintamistarkkuuden mukainen tiedonsiirto, rakenneosakirjastot Tuotemallien luomista varten eri suunnittelijat voivat saada lähtötiedoksi rakennusosien geometrian, tunnukset ja sijainnin tiedonsiirtomäärittelyiden avulla. Kaikkea tuotetietoa ei ole tarpeen siirtää erillisiin tuotemalleihin. Tuotemallipohjaisessa suunnittelussa tulisi pyrkiä käyttämään tuoteosia ja vakioituja rakenneosakirjastoja. Rakenneosa- ja liitosdetaljikirjastot edesauttavat tuotemallipohjaista suunnittelua.

30 25/55 Mallinnuksessa tulee ottaa huomioon muiden osapuolten mallinnussovellutukset, jos mallin tiedosto- tai tiedonsiirtomääritelmä ei ole yhtenevä sovellusten välillä. IFC-standardi ei ole tällä hetkellä ratkaisu kaikkeen tiedonsiirtotarpeeseen Mallintamistarkkuus ja mallin tietosisältö Yleistä Tuoteosamallin geometrinen tarkkuuden täytyy olla alustavasta rakenneosamallista lähtien ehdoton, sillä kunkin suunnittelijan tuoteosamalli toimii muiden suunnittelijoiden lähtötietona. Mallin tietosisältö vaihtelee eri mallinnusvaiheissa ja on luonteeltaan kumuloituvaa. Eri mallinnusvaiheiden välillä ei aina ole selvää rajapintaa vaan esim. alustava rakennusosamalli täydentyy rakennusosamalliksi suunnittelun edetessä. Seuraavassa esitetään karkeasti yksi mahdollinen rakennesuunnittelijan mallin tietosisältö eri vaiheissa. Mallinnusvaihe (ARK/RAK) Luonnosmalli(RAK) / Alustava rakennusosamalli(ark) Rakennemalli (RAK) / Rakennusosamalli (ARK) Tuoteosamalli (RAK) Toteumamalli (RAK) Rakennesuunnittelijan mallin tietosisältö Kantavat rakenneosat ilman liitoksia ja tuotetietoa. Mahdollisesti integroitu mitoitusmalli. Kantavat rakenneosat liitoksineen ja tuotetieto täydentyy. Paikallavalurakenteiden raudoitteet. Osien atribuuttitiedot Mahdollisesti integroitu laskentamalli. Kaikki osien valmistamiseen tarvittavat tiedot. Yhdistetty tuoteosa- ja rakennemallit sekä As Built-toteumatieto Tuotemallipalvelimen tietosisältö rakennemallista Rakennusosien geometriatieto Rakennusosien geometriatieto ja linkit detaljirakenteisiin. Atribuuttitietona liittyvät rakenteet (esim. pellitykset). Tuoteosien geometriatieto ja atribuuttitietoa. Tuoteosilla ja geometriatiedolla täydennetty rakennusosamalli. Tuotemallisuunnittelun käyttöä helpottaa jos on luotu yhteiset kirjastot, joista kaikki suunnittelijat saavat tarvitsemansa tiedon määrätyistä rakennusosista. Kirjastojen tiedon täytyy olla tarkasti määrätyllä formaatilla muodostettuja, jotta niitä pystytään hyödyntämään mahdollisimman monella ohjelmistolla. Esimerkkejä osista, joiden yhteinen tietopankki/kirjasto hyödyttäisi suunnittelua: o rakennetyypit o yleisesti käytetyt kiinnitysosat o eri tuottajien valuosat o yleisimmin käytetyt ja testatut liitokset (teräs/betoni/puu/liittorakenteet) o yleisimmin käytetyt ja testatut rakennusosat (perustukset, pilarit, palkit, laatat jne) Yhteisen mallin koko ja käytettävyys Rakennesuunnittelijan mallissa on paljon yksityiskohtaista tietoa, jonka tallentaminen yhteiseen malliin tai tuotemallipalvelimelle ei aina ole järkevää. Tallennettaessa kaikki tieto yhteiseen tuotemalliin voi mallin koko kasvaa liian suureksi ja käytettävyys kärsii merkittävästi. Pääsääntöisesti yhteiseen malliin tulisi viedä ainoastaan geometriatietoa ja tuoteosiin linkitet-

31 26/55 tyä attribuuttitietoa. Tiedonsiirtoformaattina voi toimia esim. IFC tai jokin muu yhteisesti sovittu tiedonsiirtoformaatti. Tuotemallin käytettävyyden parantamiseksi voi olla järkevää liittää osa tiedosta rakennusosaan attribuuttitietona, eikä mallintaa sitä tuotemalliin. Esimerkiksi ikkunadetaljin tai peltiseinän peltilistat ja kiinnikkeet voidaan esittää linkitettynä attribuuttitietona. Tuotetiedon jako rakennesuunnittelijan malli / yhteinen malli Tyypillisiä asioita, jotka yleensä esitetään ainoastaan rakennesuunnittelijan / tuoteosasuunnittelijan mallissa: o betonirakenteiden raudoitukset o betonirakenteiden liitososat o puurakenteiden liitososat o metallirakenteiden liitososat ja mutterit o jännebetonirakenteiden punostiedot o nostoelimet ym. o rakenneosien mitoitusmalli Osa yhteiseen tuotemalliin siirrettävästä tiedosta voi olla siirrettävään osaan liitettävä attribuuttitieto, joka esim. kertoo linkitetyn detaljin sijainnin ym.: o detaljipiirustuksen linkki o osan pintakäsittely o liitososan linkki tuotekirjastoon o rakennetyypin linkki tuoteosakirjastoon o tuoteosan aikataulu- / logistiikkatieto o linkki tuoteosapiirustukseen (klikkaamalla avautuu tuoteosapiirustus) o rakennusosan varusteluosat esim. Paroc seinän pellitykset, kiinnikkeet ja listat Projektikohtaiset mallintamistarkkuudesta sovittavat asiat: o Yleinen mallintamistarkkuus eri suunnitteluvaiheissa o Esitetäänkö betonirakenteiden raudoitukset ainoastaan rakennesuunnittelijan mallissa o Paikallavalurakenteisiin tulevat liitososat. Miten ja missä esitetään elementtien kiinnitykseen tarvittavat osat esim. kiinnityslevyt ja peruspultit (rakennesuunnittelijan malli ja / tai yhteinen malli) o Esitetäänkö betonirakenteiden liitososat yhteisessä mallissa o Esitetäänkö puurakenteiden liitososat yhteisessä mallissa o Esitetäänkö metallirakenteiden liitososat ja mutterit yhteisessä mallissa o Jännebetonirakenteiden punostietojen esittäminen o Nostoelimien esittäminen o Detaljipiirustuksen linkkimäärittelyt o Rakennusosan pintakäsittely määrittely o Liitososan linkki tuotekirjastoon, miten toteutetaan o Rakennetyypin linkki tuoteosakirjastoon, miten toteutetaan o Esitetäänkö tuoteosan aikataulu- / logistiikkatieto ja missä mallissa o Linkitys tuoteosapiirustukseen (klikkaamalla avautuu tuoteosapiirustus) o Rakennusosan varusteluosat esim. Paroc seinän pellitykset, kiinnikkeet ja listat. Osien esitystapa ja paikka.

32 27/55 Kuva Esimerkki rakennusosaan liitetystä attribuuttitiedosta Tuoterakenteet o materiaalikohtaiset tuoterakennekirjastot o materiaalia on tehty Pro IT- projektissa, ks. Pro IT- Tuoterakennekirjasto (L.Melvasalo) Ohjelmistoissa voi olla oma materiaalikirjasto tai mallista voi olla viittaukset esimerkiksi PRO- IT:n tuoterakennekirjastoon. Rakenteita mallinnettaessa tarvitaan rakennetyyppejä, joiden tarkempi kuvaus voidaan tehdä tarkasti PRO-IT:n rakennetyyppikirjastossa ja mallissa on tämä tieto vain attribuuttiviittauksena. Ohjelmistojen tulee tukea rakenneosakokonaisuuksien muodostamista eri osakokonaisuuksista.. Esim. monikerrosrakenteinen Sandwich-elementti voidaan joutua luomaan useista eri rakennusosista ja eri työkaluilla. Tällainen kappale on mahdollista mallintaa eri kerroksina ja kerrokset tulee pystyä sitomaan yhdeksi elementiksi. Elementistä luodaan oma rakenneosakokonaisuus eli Sandwich-elementti, joka sisältää erilliset rakennekerrokset ja tätä kokonaisuutta on pystyttävä käsittelemään kuten yhtenäistä rakenneosaa.

33 28/55 Kuva Ohjelmallisesti luotu parametrinen Sandwich-elementtien nurkkaliitos Liitokset Tämän kappaleen kuvaukset liitosten toiminnallisuuksista liittyy pääosiltaan ohjelmistokohtaiseen toiminnallisuuksiin. Rakennemallin luomisessa tulisi hyödyntää parametrisia liitoksia, detaljeita, saumaliitoksia ja osia. Työkalu loisi graafisia käyttöliittymiä hyödyntäen tarvittavan ohjelmakoodin. Ohjelmakoodia voisi täydentää avaamalla tämä editorilla ja lisäämällä sinne ehtorakenteita, komentoja ja funktioita. Liitososiolla (ks. Kuva 6.5.7) pyritään mahdollistamaan käyttäjän tarvitsemat liitokset, joita voi käyttää eri rakenneosien välillä. Detalji-osiolla on tarkoitus pystyä luomaan rakenneosaan jokin yksityiskohta eli detalji. Saumaliitos-osiolla pyritään tekemään elementtien väliset pitkittäissaumat, esim. väliseinien välinen pystysauma. Part-osiolla on tarkoitus luoda esim. parametrisoituja valuosia. Kuva Raudoitustyökaluilla tehty pilarin, palkin ja konsolin raudoitus.

34 29/55 Detalji-osiolla tulisi olla mahdollista luoda adaptiivisia raudoituksia, jotka kiinnittyvät elementteihin. Näitä raudoitteita olisivat esimerkiksi pilarin, palkin ja seinän pääraudat ja haat. Jos detaljin luomiseen tarvitaan enemmän älyllisyyttä, tulee se luoda ohjelmointirajapinnan avulla. Tällainen toiminto voisi esimerkiksi olla nostoelimet paikoilleen laskeva ja sijoittava toiminto. Liitos-osiolla on tarkoitus toteuttaa käyttäjän itsensä luomat liitokset, kuten palkin ja pilarin välinen liitos. Liitokset tulevat pääsääntöisesti kahden osan välille. Osiota tulee tarkastella ja kehittää siten, että on myös mahdollista luoda liitososia ja tehdä muutoksia useille osille. Tämän liitoksen parametreilla pitäisi pystyä muuttamaan myös liitososien ja liitoksen sisäisten objektien parametreja. Liitos-osioon tulisi olla mahdollista luoda sellainen liitosobjekti, jonka sisällä olevia osia voi myös muokata. Esimerkkinä on pilarin liitos perustuksiin. Liitoksen kiinnittyminen liitososiin lienee selvä, mutta liitoksessa olevien pilarikenkien parametrit tulisi olla mahdollista muuttaa. Liitos pitäisi kiinnittyä myös siten, että se tunnistaa oman sijaintinsa ja esimerkiksi pilarin poikkileikkauksen, jolloin liitoksessa olevat pilarikengät ja perustuksiin tulevat peruspultit muodostuvat oikein myös suorakaidepoikkileikkauksen omaaviin pilareihin. Saumaliitos-osiolla tulisi pystyä tekemään esimerkiksi ontelolaattojen saumavalut raudoituksineen sekä elementtien vaakasaumat. Näiden parametristen saumaliitosten tulisi mahdollistaa myös objekteille tulevat geometriamuutokset tai lisäosat, lisäobjektit sekä objektin lisäteräkset. Lisäksi tulisi olla mahdollista tehdä jokin poikkileikkaus eli reunamuoto jotakin ääriviiva myöten, kuten jokin kouru, jossa ääriviiva voisi olla myös kaareva tai jonkin määrätyn funktion mukainen. Tällaisesta käyttäjälle tarkoitetusta yksinkertaisesta rajapinnasta puuttuu ns. Macro-osio, jolla pystyisi hoitamaan kaikki mahdollinen mielikuvituksen tuottama ohjelmatoiminto. Makron tulisi sisältää ohjelmiston työkalut, ohjelmakäskyjä, -funktioita, -muuttujia ja käyttäjän itsensä luomia funktioita. Tietokoneen voisi laittaa töihin vaikka joka yöksi, esimerkiksi päivittämään ja tulostamaan piirustuksia, kloonaamaan kuvia ja muuttamaan useiden objektien tai piirustusten ominaisuuksia ja lisäksi mahdollistaen kaikki muokkaus- ja kopiointitehtävät. Tämän makro-osion toiminto voisi perustua nauhoittavaan toimintojen toistoon. Tämä makro-osio ei tietenkään rakennu samalla tavalla graafisesti kuin muut komponentit, mutta makron ohjelmarakenne tulisi olla avoin ja tällaisten makrojen käyttö pystyisi hyödyntämään lähes kaiken ohjelman kapasiteetin. Kehitteillä olevalla ohjelmointirajapinnalla voi luoda esim. elementti- ja rakennesovelluksia tai erikoisrakennesuunnittelun työkaluja. Tällaisella sovelluksella voisi luoda esimerkiksi julkisivukasetteja tai kevytrankaseiniä ohjelmiston työkaluja, objekteja, liitoksia ja detaljeja sisältäen ja hyödyntäen. Ohjelmointirajapinnalla voisi luoda myös muutostenhallintatyökalun, jolla voisi piirustusten muutostyön aiheuttamat merkinnät hallita. Ohjelmiston uusi työkalu mahdollistaisi nykyisellään parametristen liitosten, raudoitteiden ja valuosien luonnin. Työkalulla voisi luoda liitoksia elementtien välille. Liitokset, raudoitteet ja valuosat parametrisoidaan siten, että osien geometriapisteiden etäisyydet sidotaan toisistaan riippuviksi. Valuosien ja raudoitteiden luonti työkalulla sujuu kehitetyn rajapinnan avulla odotusten mukaisesti. Elementtiliitosten monimuotoisuus edellyttää työkalulta toimivien ominaisuuksien lisäksi uusien toimintojen kehitystä. Liitoksen sisällä olevien valuosien lukumäärää tulisi pystyä määräämään ja niitä tulisi myös pystyä vaihtamaan toiseksi valuosaksi.

35 30/55 Määrittelemättömien liitosten vientiin mallista ulos saattaa liittyä suuri määrä kehitystyötä Liitteenä ohjelmistotoimittajien sovellusesimerkit Tuotemallipohjaisten rakennusosien toteutustavat ovat erilaisia eri sovelluksilla. Tässä on kuvaus Tekla Structures - ohjelmistolla tehdystä tuotemallipohjaisesta rakennusosasta. Ontelolaatta on vakioitu valmistajakohtainen jännitetty betonielementtirakenne. Ontelolaatasta ilmoitetaan valmistajalle punostiedot, tulppatiedot, betonin lujuus ja paloluokka. Näiden tietojen välittäminen elementtitehtaalle mahdollistaa tuotannonsuunnittelua tehtaan tarpeiden mukaisesti. Sähköisen tiedon lisäksi ontelolaatoista luodaan erilliset mittapiirustukset varausten ja syvennysten tekemistä varten tuotantolinjalla. o Kuva Ontelolaatan punostiedot, päätytulpat, lujuus, paloluokka ja muut tuotetiedot. Rakenneosakohtaisesti on mahdollista luoda erilaisia sähköisiä taulukoita tai tietokannan osia, joita voidaan käyttää rakennusosan tuotannonsuunnittelussa, -ohjauksessa ja -hallinnassa. Tuotetietoa on mahdollista hyödyntää myös työmaalla sen edellyttämien tarpeiden täyttämiseksi. Tuoteosavalmistaja voi toimittaa suunnittelijalle sähköisesti ajantasalla olevaa valmistustietoa aikataulusuunnittelua ja toteumamallia varten Tuotemallin tunnistetiedot Jokaisella tuoteosalla tulee olla oma tunnistetieto. Tällainen tunnistetieto on ohjelmiston antama ID. Ohjelmistojen on kyettävä käsittelemään IFC-tiedonsiirrossa tulevia lähtötietoja säilyttäen objektin alkuperäisen ID:n. Tämä on mahdollista käyttäen uniikkia ID:tä mallinnettaville osille GUID (Global Unique ID). Ohjelmistojen on kyettävä myös hallitsemaan rakenneosien muutoksia muokkaamalla olemassaolevaa rakennusosaa säilyttäen GUID:n. Lisäksi ohjelmis-

36 31/55 tojen tulisi hallita muutostietojen lisäksi suunnittelijakohtaisen osahistorian. Jokainen osa tulee olla korvamerkittävä jollekin suunnittelijalle. o Kuva Objektikohtaiset geometria-, attribuutti-, ID ja GUID-tiedot. Osien muutos-, tunnus- ja käyttöhistoriaa tulee pystyä seuraamaan. Näin voidaan varmistaa suunnitelmien oikeellisuus suunnittelijalta suunnitelmien käyttäjälle virheettömästi.

37 32/55 7 TUOTEMALLIN YLLÄPITO JA KÄYTTÖ 7.1 Nykytilanne Nykyisin useat eri suunnittelijat suunnittelevat käyttäen oman alansa tuotemalliohjelmistoja, mutta vain harvoissa tapauksissa on käytetty yhteistä tuotemallipalvelinta tai tieto on koottu yhteen yhteiseen palvelimeen. Tiedonsiirto eri suunnittelijoiden välillä tapahtuu pääsääntöisesti dokumentteja välittämällä (digitaalisessa- tai paperimuodossa) joko suoraan suunnittelijoiden välillä tai projektipankin kautta (vrt. kohta 3.1). Siirrettävä tieto on vielä usein 2D muotoista. Tuotemallin siirtäminen toiselle osapuolelle on nykyisin vielä harvinaista johtuen ongelmista tiedonsiirrossa ja käytettävien mallinnustekniikoiden kirjavuudesta. 7.2 Tuotemallipalvelin Internetin yli toimiva tuotemallipalvelin kokoaa eri suunnittelijoiden mallit yhdeksi malliksi. Tiedon välittämiseen tuotemallipalvelimeen käytetään sovittua tiedonsiirtoformaattia ja tieto voi välittyä automaattisesti tai manuaalisesti. Tuotemallipalvelin voi sijaita esim. jonkin suunnittelijan serverillä, nykyisiä projektipankkeja vastaavasti esim. kopiolaitoksella tai erillisellä tuotemallipalvelimen hallinnoijalla. Lisäkustannuksia muodostuu mallin hallinnoimisesta, mutta kustannukset lienevät suuruusluokaltaan samoja kuin nykyiset projektipankkikustannukset. Etuna on mahdollisuus käyttää mallitarkistinta mallin oikeellisuuden tarkistukseen (esim. päällekkäiset osat). Kuva Tuotemallipalvelin Yhteisen tuotemallin (kohta 8.3) ja tuotemallipalvelimen raja on häilyvä. Esimerkiksi osa suunnittelijoista voi toimia yhteisessä mallissa käyttäen samaa ohjelmistoa ja kolmas osapuoli on malliin yhteydessä jollain muulla yleistä tiedonsiirtoformaattia tallentavalla mallinnusohjelmalla.

38 33/55 IFC pohjainen tuotemalliserveri Kehitteillä on IFC-pohjaisia tuotemalliservereitä, jotka mahdollistavat liittymisen IFCtiedonsiirtoa hyväksikäyttäen. 7.3 Yhteinen tuotemalli Eri suunnittelualat käyttävät yhtä yhteistä mallia. Tämä tapa edellyttää yleensä, että suunnittelijat käyttävät samaa ohjelmistoa. Voi aiheuttaa vaikeuksia oikeuksien antamisessa (kuka hallinnoi mitäkin rakennusosaa). Etuna on mallin päivittyminen reaaliajassa. ja mallitarkistimen käyttömahdollisuus. Edellyttää eri suunnittelualojen melko yhtäaikaista etenemistä ja esim. rakennesuunnittelijan on mallinnettava runkorakenteet samanaikaisesti arkkitehdin työskentelyn edetessä päällekkäisen työn välttämiseksi. Kuva Yhteinen tuotemalli 7.4 Hajautettu tuotemalli Tuotemalli voi olla hajautettuna useilla eri suunnittelijoilla ja tiedonvaihto suunnittelijoiden välillä tapahtuu sovitulla tavalla tiedonsiirtoformaattia käyttäen. Kullakin suunnittelijalla on tällöin oma tuotemallinsa, johon muiden suunnittelijoiden mallit tuodaan sovitulla formaatilla referenssiksi. Vaarana on muiden suunnittelijoiden tekemien muutosten ja täydennysten jääminen pois jonkun suunnittelijan mallista jos mallien päivitys tapahtuu harvoin. Sovittava esim. automaattipäivityksestä suunnittelijoiden kesken. Tämä toimintamalli ei edellytä tuotemallille yhtä hallinnoijaa, vaan kukin huolehtii itse omasta mallistaan. Hajautettu tuotemalli ei aseta yhtä suuria vaatimuksia datayhteyksille kuin keskitetty malli reaaliajassa, koska päivitykset tapahtuvat vain määrävälein ja mahdollistaa lisäksi offline käytön ja esimerkiksi mallintamisen kannettavalla tietokoneella työmaalla. Toimintamallissa ei muodostu yhtä yhteistä tuotemallia, ellei joku kokoa kaikkien suunnittelijoiden tuotemalleja yhteen.

39 34/55 Kuva Tietojen ristiinsiirto 7.5 Älykäs projektipankki Nykyisen projektipankin kehittyneempi muoto, jossa otetaan paremmin huomioon mallintamisen vaatimukset ja mahdollistetaan parempi tietojensiirto.

40 35/55 8 OHJELMISTOJEN JA RAKENNESUUNNITTELUN NYKYTILANNE 8.1 Rakennesuunnittelun toimintamallit tänään Nykyisin pääosa rakennesuunnitelmista tehdään edelleen 2D-CAD ohjelmilla ja vaikka useat ohjelmat tarjoavat tuotemallinnusominaisuuksia, niitä ei useinkaan suunnittelussa hyödynnetä. Tämä johtuu pääosin siitä, että em. tuotemallinnusominaisuudet ja -työkalut niiden tuottamiseen ovat rakennesuunnittelijan näkökulmasta liian yleisellä tasolla. Ristiin tapahtuva tiedonsiirto o Kuva Tiedonsiirto ristiin eri osapuolten välillä Ristiin tapahtuvassa tiedonsiirrossa jokainen vastaanottaa ja lähettää tietoa useille eri osapuolille ja tietokatkosten mahdollisuus on ilmeinen. Projektipankki Projektipankki lienee yleisin käytössä oleva kehittyneempi suunnittelutiedon kokoamistapa dokumenttien tallentamiseen. Etuna projektipankissa on viimeisimmän suunnittelutiedon löytyminen samasta paikasta ja kunkin eri osapuolille välitettävän tiedon määrän väheneminen. Varsinaista tuotemallitietoa ei yleensä projektipankista löydy kuin jonkun osa-alan suunnitteludokumenteista. Tiedonsiirto eri suunnittelijoiden välillä tapahtuu pääsääntöisesti edelleen 2D dokumentteja välittämällä (digitaalisessa- tai paperimuodossa). o Kuva Tiedonsiirto eri osapuolten välillä projektipankkia käytettäessä

41 36/ Tuotemallinnusohjelmia Käytössä olevat rakennesuunnittelun tuotemallinnusohjelmat ovat hyvin monipuolisia ja niiden käyttöä rajoittaa usein vain mielikuvitus. Pisimmällä tuotemallipohjaiseen suunnitteluun siirtymisessä ollaan metallirakenteiden suunnittelussa, jossa pääosa rakennesuunnittelusta tehdään tuotemallinnukseen kehitetyillä ohjelmilla.ohjelmat tukevat hyvin erilaisia käyttötarkoituksia ja toimintoja on painotettu eri tavoin. Ohessa on kerätty muutamia ominaisuuksia (ohjelmistotuottajien ilmoittamia). Ohjelma Allplan Engineering Tuetut tiedonsiirron formaatit DWG, DXF, DWT, DGN, IFC2x, IFC2x2 luku Muutosten hallinta Assosiatiiviset päivittyvät luettelot Enterprixe IFC, DWG Osien muutoshistorian avulla Tekla Structures Import : DWG, DXF, ASCII, FEM (DSTV, IFC, S- Frame, Monorail, Staad, Stan-3D,Bus), CAD (SDNF, Calma, HLI, Plantview, XML) Referenssi import: DWG, DGN, XML, IFC 2x2(tulossa) Export : 3D DXF, 3D DGN, IFC 2x, IFC 2x2 (tulossa), ASCII, FEM (DSTV, MicroSAS, Staad), IFC, CAD (SDNF, Calma, HLI, Plantview, XML) Osien muutoshistorian avulla Tuetut rakenteet Metalli-, betoni- ja puurakenteet Metalli-, betoni- ja puurakenteet Metalli-, betoni- ja puurakenteet Dokumenttituotanto Puoliautomaattinen Puoliautomaattinen Automaattinen / puoliautomaattinen Integroitu mitoitusohjelma Allplus ( Friedrich & Lochner) Ei Kehitetään tiedonsiirtotoimintoja mm. Robot, Staad Staad 4D Voi käyttää lähtötietona On On Kaikki CIS/2 ja DSTV yhteensopivat Bentley Structural IFC 2.x, 2x2 tulossa DGN,AutoCAD, DWG, SDNF, CIS 2.0, EXPORT/IMPORT Staad, GTStrudl Osien muutoshistorian avulla Metalli-, betoni- ja puurakenteet Puoliautomaattisesti / automaattisesti MIDAS integroituna, Staad tiedonsiirtona Käyttö linkittämällä aikatauluohjelmaan Taulukko 8.1 Eräiden rakennesuunnittelussa käytettyjen ohjelmistojen ominaisuuksia ohjelmistotuottajien mukaan

42 37/ Eräiden rakennesuunnittelussa käytettyjen ohjelmistojen kuvauksia Allplan Engineering Rakenteiden ja raudoitusten älykäs suunnittelu 3D:ssä, tarvittaessa myös 2D:ssä, muotintunnistava raudoitus Määräluettelot tanko- ja verkkoluettelot sekä taivutuskaaviot, luetteloiden päivitys ohjelmallisesti, tuki raudoitustehtaiden taivutuskoneille Raudoitusten törmäystarkastelu BAMTEC, optio Allplan Precast Concrete elementtisuunnittelu, erillinen Nemetschek ohjelmisto Allplus statiikka (Friedrich + Lochner), optio linkitys Allplaniin on Parametriset palkit, pilarit, porrassyöksyt yms. 3D-Component Modelerin avulla Siltasuunnittelu, optio / LaserLaskenta Oy, Juha Laitinen/ Tekla Structures Tekla Structures is an intelligent and flexible tool for steel and concrete detailing and engineering. It also provides project collaboration and information management in structural design with completely new, innovative opportunities. Tekla Structures is the first totally integrated 3D solution in the field with which all structural design tasks can be carried out in a single environment and product model. The new product enables creating real-time 3D structure models of any material or complexity. /Tekla Oyj, Lassi Lifländer/ Enterprixe Enterprixe on Internet-pohjainen, kolmiulotteinen, mallinnus, suunnittelu ja informaatiojärjestelmä rakennuksen elinkaarenaikaiseen tiedonhallintaan. Enterprixen ydin on Internetissä toimiva 3D tuotemallipalvelin. Se mahdollistaa reaaliaikaisen, interaktiivisen, yhteen, yhteiseen malliin perustuvan, kaikkien osapuolien välisen suunnitteluyhteistyön. Auktorisoitu käyttäjä voi kytkeytyä malliin Internetin välityksellä milloin vain, mistä vain. Malliin voidaan tallentaa kaikki relevantti tieto, jota eri osapuolet rakennuksen elinkaaren aikana tarvitsevat. Malliin voidaan kytkeytyä käyttäen monia yleisesti käytössä olevia ohjelmia kuten esim. Auto- CAD, ADT ja Excel. Enterprixen käyttäjiä ovat mm. arkkitehdit, jotka voivat mallintaa arkkitehdin vaatimusmallin ADT komponenteilla tuotemallipalvelimelle. Tämä jaettu tieto toimii rakennesuunnittelijan lähtökohtana tarkemmin detaljoitujen yksityiskohtien mallintamisessa. Enterprixen toinen keskeinen osa-alue on rakennesuunnittelijoiden käyttöön kehitetty 3D rakenteiden mallinnusympäristö. Tämä osuus ohjelmaa asentuu käyttäjän omalle koneelle ja sen avulla voidaan tuottaa rakennemallin 3D detaljeja ja niistä puoliautomaattisesti tarvittavia raportteja, kuten piirustuksia ja luetteloita. Enterprixe tuotemallitietoa käytetään betonielementtitehtaan ja rakennustyömaan toimintojen suunnittelussa ja mahdollisten aikatauluongelmien analysoinnissa ennen varsinaisten ongelmien ilmaantumista. Rakennuksen valmistuttua samaa tuotemallitietoa hyödynnetään raken-

43 38/55 nuksen ylläpidossa, vuokralaisen toimintojen optimoinnissa ja mm. markkinoinnissa. Enterprixe Software Ltd, Petri Kokko/ Bentley Structural Teräs, betoni, ja puurakenteiden mallintamiseen tarkoitettu ohjelmisto. Ohjelmalla voidaan mallinntaa rakenteiden 3d mallin lisäksi myös analyyttinen malli (voimat, tuennat ja erilaiset kuormat) ja siirtää tietoa analyysiohjelmistojen kanssa. Piirustukset tuotetaan 3d mallista sääntöpohjaisen piirustustuotannon kautta. Bentley Geopak Rebar Betonirakenteiden raudoitusohjelma. /Bentley Finland Oy, Ari Rantasalo/ 8.4 Mitoitusohjelmat ja niiden liityntä tuotemalliin Useissa tuotemallinnusohjelmissa on integroituna mahdollisuus käyttää jotain rakenteiden mitoitusohjelmaa esim. Tekla Structures/Staad tai niissä on tietyille mitoitusohjelmille kehitetyt tiedonsiirto-ominaisuudet esim. Enterprixe/Staad ja Robot. Useat mitoitusohjelmat pystyvät minimissään lukemaan yleisimpiä CAD formaatteja ja luomaan niistä laskentamallin melko vähällä työllä. Statiikka- ja mitoitusosion integrointi tuotemallinnusohjelmistoon on erittäin tärkeä ominaisuus ajatellen rakennesuunnittelun kokonaisuuden hallintaa (vastaava rakennesuunnittelija). Varsinkin sellaisissa tapauksissa, että rakennesuunnittelua tekee kohteessa useampi toimija. Kuva Tuotemallinnusohjelman ja mitoitusohjelman vuorovaikutus

44 39/55 9 TIEDONSIIRTO TUOTEMALLINTAMISESSA (SÄHKÖINEN) 9.1 Tiedonsiirto, yleistä Sähköisen tiedonsiirron etuina on rakennushankkeen eri osapuolien saama virheetön ja ajan tasalla oleva suunnittelutieto, joka minimoi tiedonkulussa aiheutuvat virheet. Tiedonsiirron tuomat mahdollisuudet on myös toteutettava rakenne- ja elementtisuunnittelualalla laajentamalla suunnittelijan työkalut tiedonsiirron edellytyksien vaatimalle tasolle. Tiedonhallintaa tulee kehittää myös rakenne- ja elementtisuunnittelualalle sopivaksi ja niiden tarpeet täyttäväksi. Tiedonhallintatyökaluja on kehitettävä ohjelmointityökaluilla, joilla suunnitteluohjelmistot on luotu. Kun tiedonsiirtomäärittelyt, tiedonhallinta- ja tiedonsiirtotyökalut luodaan kehitysnäkemysten pohjalta, se aikaansaa tehokkaan elementtisuunnittelusovelluksen ohjelmistoista. Elementtitehtaan tuotannonhallinta- ja tuotannonohjaustyökalujen luonnin jälkeen elementtien valmistustietoa voidaan hallita tehokkaammin suunnittelijalta valmistusyksikköihin. Perusvaatimus käytettävälle mallinnusohjelmalle on IFC-tiedonsiirtoformaattin luku- ja kirjoitustyökalut. Tiedonsiirtomuotoa voidaan käyttää ohjelmistojen välisessä tuotetiedonsiirrossa. 9.2 Tiedonsiirtoformaatit IFC IFC-tiedonsiirto ja rakennesuunnittelu IAI ja IFC International Alliance for Interoperability (lyh. IAI) on kansainvälinen, avoin yhteenliittymä, jonka tavoitteena on tarjota yhteinen perusta rakentamisen ja kiinteistönpidon prosessien kehittämiseen ja erityisesti tiedon siirtoon ja tiedon yhteiskäyttöön läpi rakennusprosessin. IAI:n keskeisenä tehtävänä on Industry Foundation Classes (lyh. IFC) tiedonsiirron spesifikaation, so. standardin, kehittäminen ja julkaisu sekä edistää IFC:n toteutusten kehittämistä kaupallisissa tietokonesovelluksissa. IFC:n ydinosa on myös julkaistu kansainvälisen standardointijärjestön ISOn ISO (Publicly Available Specification, PAS) -dokumenttina. Tiedonsiirron standardina IFC määrittelee tietokonesovelluksista riippumattoman tavan siirtää digitaalista tuotetietoa sovellusten kesken. IFC:n käytännön hyödyntäminen edellyttää IFC:hen perustuvien tiedonsiirron rajapintojen toteuttamista rakennusalan tietokonesovelluksissa./ Kari Karstila/ IFC ja sen kattavuus IFC:tä on kehitetty vaiheittain, sen rajausta aina uusille alueilla laajentaen. IFC viimeisin version IFC 2x2 (IFC 2x Second Edition) on julkaistu keväällä IFC pyrkii kattamaan rakennushankkeiden ja rakennuksen koko elinkaaren ja eri osapuolien näkökulmat. IFC 2x2:n kattamia (joskaan ei täydellisesti) rakentamisen ja kiinteistönpidon alueita ovat: o Rakennussuunnittelu (arkkitehtisuunnittelu) o Rakennesuunnittelu o Talotekninen suunnittelu

45 40/55 o Rakentamisen valmistelu (tuotannonsuunnittelu) ja rakentaminen o Kiinteistönpito. Siten IFC-spesifikaatio mahdollistaa useiden erilaisten tiedonsiirron käyttötapausten toteuttamisen alustavasta rakennussuunnittelusta aina kiinteistön pitoon. / Kari Karstila/ IFC ja rakennesuunnittelu Rakennesuunnittelun osalta IFC kattamia alueita ovat: o Rakenneanalyysi, kattaen staattisen rakenneanalyysin, rakennemallin, kuormitukset sekä keskeiset analyysitulokset. o Teräsrakenteet, kattaen teräsrakenneosat sekä teräsrakenteiden yleisimmät materiaaliominaisuudet. Teräsrakenteiden liitosten detaljien osalta on IFC-määrittelytyö vielä kesken. o Teräsbetonirakenteet, kattaen teräsbetonirakenneosat (niin paikallavalu- kuin betonielementtirakenteet), niiden raudoitukset, jänteet ja varusteet sekä yleisimmät betonin ja betoniterästen ja jänteiden materiaaliominaisuudet. o Puurakenteiden osalta on IFC:n laajennuksen määrittelytyö meneillään, ja se valmistuu vuoden 2004 aikana. Laajennus tulee kattamaan puurakenneosat, niiden liitosten detaljit sekä puun yleisimmät materiaaliominaisuudet. / Kari Karstila/ IFC:n toteutuksia varten ohjelmistokehittäjät määrittelevät yhdessä IFC osajoukkoja (ns. Näkymiä, engl. View), jotka sitten toteutetaan tiettyjä tiedonsiirron käyttötapauksia tukevina sovellusten IFC-rajapintoina. Rakennesuunnittelun alueella ollaan parhaillaan määrittelemässä seuraavia Näkymiä: o Architectural design Structural system model: Rakennussuunnittelun ja alustavan rakennesuunnittelun ja rakennemallinnuksen välinen tiedonsiirto. o Structural system model Structural analysis: Rakennemallinnuksen ja rakenneanalyysin välinen tiedonsiirto. o Structural analysis Structural design: Rakenneanalyysin ja rakennesuunnittelun ja rakenteiden mitoituksen välinen tiedonsiirto. o Structural design Structural design: Rakennesuunnittelun sovellusten välinen tiedonsiirto. / Kari Karstila/ Yhteenveto IFC:n tuesta rakennesuunnittelun tiedonsiirrolle Yhteenvetona IFC:n tuesta rakennesuunnittelun tiedonsiirrolle voidaan todeta, että nykyinen IFC 2x2 ja sen tulossa oleva puurakentamisen laajennus kattaa kohtuullisesti rakenneanalyysin ja rakennesuunnittelun (teräs-, betoni- ja puurakenteet) tiedonsiirtoa. Työ rakennesuunnittelun tiedonsiirron käyttötapausten tarkentamiseksi on meneillään, joka on perustana IFCtiedonsiirron toteutuksille rakennesuunnittelun kaupallisissa sovelluksissa. Ensimmäisiä pilottiversioita rakennesuunnittelun sovellusten IFC-toteutuksista voitaneen odottaa syntyvän vuoden 2004 lopun ja vuoden 2005 aikana. Paremmin testattuja ja IAI sertifioituja rakennesuunnittelun sovellusten IFC-toteutuksia voitaneen odottaa aikaisintaan vuoden 2005 jälkimmäisellä puoliskolla. / Kari Karstila/ Joissakin rakennesuunnittelijoiden käyttämissä ohjelmistoissa on käytössä jo jonkinasteinen IFC tuki (ks. taulukko 8.1).

46 41/ Ohjelmistojen omat formaatit o Tiedonsiirtoformaateista tehdään tarvittaessa testaus yhteistyössä ohjelmistotoimittajien kanssa, jolloin varmistetaan tiedon virheetön siirtyminen eri suunnitteluohjelmistojen välillä. o Tuotemallin organisoinnin kannalta olisi selkeintä keskittää tiedonsiirto muutamaan keskeiseen ja yleisesti tuettuun formaattiin DXF, DWG, SDNF ja DGN suunnittelun lähtötietona Useat mallintavat ohjelmistot sisältävät rajapinnan tyypillisimpiin graafisiin formaatteihin. Tuoteosamalliin on mahdollista lukea sisään referenssimalleja esim. DXF, DWG ja DGN formaateissa. Käytettäessä SDNF (Steel Detailing Neutral File), joka on maailmanlaajuinen standardi (AS- CII) on mahdollista siirtää palkkeja, levyjä ja rakennusosia tuoteosamalliin ja siitä muihin suunnitteluohjelmistoihin. Viimeisin SDNF-formaatti käsittää myös kaarevia alkioita. SDNF:ää käytettäessä voi luoda ohjelmistoon automaattisen muutostenhallinnan. Esimerkiksi on mahdollista nähdä mitä on muutettu, poistettu tai lisätty edelliseen sisään lukemisen jälkeen. SDNF:ää on onnistuneesti käytetty monissa suunnitteluprojekteissa sekä suomessa että maailmanlaajuisesti. Paikallisia muunnoksia on myös mahdollista tehdä. Käytettäessä usein laitossuunnittelussa käytettyä Microstation DGN-formaattia on mahdollista tuoda malliin laitossuunnitteluohjelmilla mallinnettuja malleja ja päinvastoin. Referenssimalli on kytketty dynaamisesti malliin ja on helppoa kytkeä se näkyviin tai sulkea käyttäjäkohtaisesti työn aikana. DGN mallien geometriaan voidaan kiinnittyä (esimerkiksi mitata geometriapisteiden etäisyys) ja hyödyntää tätä varausten tekemisessä lävistyksille. Useat mallipohjaiset ohjelmistot tukevat myös tiedonsiirtoa ulkoisiin järjestelmiin (esim. CNC, SAP). Ohjelmistoissa jo tällä hetkellä olevia tiedonsiirtomuotoja voidaan käyttää moniin eri tarkoituksiin. Esimerkiksi teräsrakenneteollisuus hyödyntää tuotannossaan valmistustiedostoja, jotka sisältävät CNC-koneen tarvitseman syöttötiedon, jolloin erillistä käsin tehtävää tiedonsyöttöä koneeseen ei tarvitse tehdä. Tätä tiedonsiirtoa olisi mahdollista hyödyntää myös betonielementtiteollisuudessa, jos valmistajalla on käytössään jokin kyseistä tiedonsiirtomuotoa ymmärtävä tuotannonohjausjärjestelmä Esimerkkejä attribuutti muotoisen tiedon siirrosta Attribuutimuotoista dataa käyttäen on mahdollista helposti siirtää useista ohjelmistoista erilaista tieto muihin ohjelmiin. Seuraavassa on muutamaasiaa valaiseva esimerkki. Rakenteiden tietojen vieminen tuotemalliin

47 42/55 Kuva Ontelolaatan punostiedot attribuutteina. Tiedonsiirrossa kulkee eri osapuolien välillä esimerkiksi betonielementtien suunnittelutieto. Suunnittelutiedosta tulee siirtäää laskelmat, elementin yleistiedot, mittatiedot, materiaali- ja pintatiedot, sekä varaus- että tarviketieto. Elementin yleistiedoissa ilmenee elementin sijainti, lukumäärä, luokkavaatimukset, toleranssit ja elementin käsittelyohje. Elementtien muototiedoissa kuvataan elementin rakennetyyppi, reunamuodot, aukkotiedot ja teoreettiset määrätiedot. Rakennetyypistä tulee ilmi elementtirakenteesta esim. taso- tai seinäelementtien rakenne. Elementin reunamuodosta kuvataan reunamuototyyppi, sijainti ja viiste. Aukkotiedoista tulee käydä ilmi aukon muoto, mitat, sijainti ja reunamuodot. Materiaalitiedoista esitetään materiaaleittain niille ominaiset tiedot, kuten esim. tyyppi, koko, laatu, luokka, ominaisuudet ja määrätiedot. Pintatiedoissa ilmoitetaan elementin pintakäsittely- ja pintatiedot. Varaus- ja tarviketiedoista esitetään varaus- ja tarvikekohtaisesti niille tyypilliset tiedot, kuten esim. muoto, mitat, koko, tyyppi, laatu, sijainti ja määrätiedot.

48 43/55 Elinkaaritiedon vieminen tuotemalliin Elinkaaritieto on myös usein tietoa, joka voidaan liittää attribuuttitietona. Elinkaari- ja käyttöikäsuunnitteluun liittyvää määrittelytyötä on tehty RT:n koordinoimissa EKA-projektissa ja VTT:n koordinoimassa LifePlan-projektissa. Em. määrittelytyö on sovellettavissa elinkaaritiedon hallintaan tuotemallipohjaisessa suunnittelussa. Elinkaarituotetietoja voi liittää tuotemalliin attribuuttitietona esimerkiksi erilaisten viittausten avulla. Tuotemallista tulee löytyä viitteet tuotetietojen, rakennetyyppien ja työohjeiden määrittelyyn. Tuotetietojen tarkempi kuvaus voidaan tehdä esim. Life Plan projektissa tehdyn mukaisesti. Kestävän kehityksen mukaisesti elinkaarisuunnittelun rooli on kasvamassa, mutta tällä hetkellä elinkaarisuunnittelun tehtävämäärittelyt ja toimintatavat miten elinkaaritietoa hyödynnetään tuotemallin avulla ovat vielä kehitysvaiheessa. RIL:n elinkaarijaosto on laatimassa rakennesuunnittelijan elinkaarisuunnittelun tehtäväluetteloa, joka julkaistaan vielä kuluvan vuoden aikana. Kuva Harkon elinkaaritiedot tietokantakortissa /Life Plan/.

49 44/ Tiedonsiirto eri suunnitteluosapuolien välillä Yleistä o tulee varmistaa, että kaikki osapuolet käyttävät samaa versiota esim. IFCtiedonsiirtoformaatista Suunnittelijaosapuolien välinen toimiva tiedonsiirto tehostaa suunnittelua, jolloin säästyy aikaa ja tuottavuus paranee. Suunnitteluprojektia on mahdollista tehdä eri puolilla maailmaa tietoliikenneyhteyksien avulla. Projektissa voi olla mukana useita suunnittelijoita, jotka käyttävät samaa mallitietokantaa. Suunnittelijaosapuolilla on käytössään samat ajan tasalla olevat ja yhdenmukaiset suunnitelmatiedot. Rakennemallin, raporttien, piirustusten ja analyysimallin tiedot luetaan yhdestä tietokannasta. Suunnittelijaosapuolien tekemä työ voidaan pitää eri osapuolien nähtävänä, jolloin virhemahdollisuudet pienenevät RAK ARK ja RAK LVIS, RAK GEO jne o tiedonsiirto on useimmiten kaksisuuntaista tarkentuen kunkin siirron yhteydessä (esim. ristikon ulkomitat ARK mallista ja RAK mallista takaisin ristikon tarkat geometriatiedot) o huolehdittava, ettei tuotemallipalvelimelle jää päällekkäistä tietoa rakennusosista Eri suunnittelijoiden on kyettävä hyödyntämään toisen suunnittelijan tekemä työ käyttäen sitä lähtötietona omalle suunnittelulle. Rakennesuunnittelija voi tehdä muutoksia arkkitehdin runkoon dokumentoimalla siitä arkkitehdille. Rakennesuunnittelijalla on oikeus tehdä muutoksia vain omille rakennusosille. Tällä tavoin voidaan hallita eri suunnittelijoiden välistä tiedonsiirtymistä ja rakenneosien muutoksia. Suunnittelijaosapuolien välinen suunnittelutiedon vaihtaminen tulisi hallita, jotta esim. laskennan määrittämät rakenneosien geometriamuutokset voidaan päivittää eri suunnittelijoiden suunnitelmatietoihin Elementtisuunnittelija / tuoteosasuunnittelija Elementtisuunnittelun alkaessa suunnittelija tarvitsee työtänsä varten lähtötietoja. Nykyisiä suunnittelumenetelmiä käytettäessä elementtisuunnittelija saa tavallisesti lähtötietonsa 2D dwg -tiedostoformaatissa arkkitehdilta ja rakennesuunnittelijalta. Lisäksi lähtötietoina ovat lukuisat kirjalliset dokumentit ja asiakirjat. Elementtisuunnittelijan käyttäessä mallipohjaista suunnitteluohjelmistoa, jolloin lähtötiedot ovat tasossa olevia rakenneviivoja, joutuu suunnittelija vastuuseen tuottamansa rakennemallin oikeellisuudesta. Elementtisuunnittelija joutuu tekemään mallinnustyön, jos rakennesuunnittelija ei ole tehnyt työtänsä samalla ohjelmistolla. Tällainen tiedonhallinta tuo mahdollisuuden inhimillisten virheiden syntymiselle. Edistyksenä tässä on kuitenkin, verrattuna tavanomaisia suunnittelumenetelmiä käytettäessä, jolloin elementtisuunnittelija luo suunnitelmien tulokset tasopiirustuksiksi, missä on olemassa myös sama virheen mahdollisuus, että työssä syntyvät mahdolliset virheet ja ongelmakohdat voidaan tarkastella kolmiulotteisesti. Tällainen työkalu antaa myös mahdollisuudet toisen suunnittelijan tekemään tarkastustyöhön, jolloin suunnitelmat hahmottuvat helpommin myös toiselle suunnittelijalle.

50 45/ Tiedonsiirto/ muut hankeosapuolet Tiedonsiirto eri hankeosapuolien välillä on nykyisellään sähköistä tiedonsiirtoa. Eri hankeosapuolilta voi tulla dokumentaatiotietoa muille osapuolille. Tämä tulee toteuttaa samalla tavoin kuin suunnittelijaosapuolien välinen tiedonsiirto (vrt. kohta 9.3). Hankeosapuolilla voi olla suunnitteluun liittyvä muutostarve tai suunnittelutiedon täydentämistarve. Tämä voidaan toteuttaa tiedonsiirron avulla internetin välityksellä. 9.5 Tiedonsiirron turvallisuus Suunnittelijaosapuolien välinen tiedonsiirto on nykyisellään vaativampaa, jolloin eri osapuolien välinen sähköinen tieto tulisi siirtyä virheettömästi ja ajantasalla. Turvattu tiedonsiirto perustuu luotettavaan tiedon salaukseen. Varmistus tiedonsiirtymisestä voitaisiin hoitaa myös ohjelmallisesti käyttäen erilaisia salaus- ja hallinnointimenetelmiä. Ajantasalla olevan tiedon jakaminen osapuolien välillä tulee myös hallita. Projektipankin avulla voidaan taata ehyt ajanmukaisen tiedon jakaminen projektin osapuolien välillä. 9.6 Referenssimallien kontrollointi Referenssimalleja voi olla useampia, jolloin jokainen suunnittelija on vastuussa oman mallin oikeellisuudesta. Suunnittelijoiden on tarkistettava suunnitelmiensa soveltuvuus eri suunnitelmatietoihin. Suunnittelijoiden on kyettävä tutkimaan oman mallin oikeellisuus ja virheettömyys ettei tule esim. rakenteellisia päällekkäisyyksiä. Näitä on kyettävä hoitamaan ohjelmallisesti. Tällöin jokainen suunnittelija tarkastaa oman mallin tietosisällön oikeellisuuden. Suunnittelijoiden on kyettävä omalla ohjelmistollaan lukemaan mallin sisälle eri referenssimalleja ja tarvittaessa kopioimaan malleista rakenneosia omaan malliin. Suunnittelijalla voi olla tarve myös päivittää toisen suunnittelijan tekemä esim. geometriamuutos. Jos suunnittelija on tehnyt täydentävää suunnittelua kyseiselle rakennusosalle tulee muutostiedon korvata vain muuttunut tietoa säilyttäen suunnittelijan tekemät muutokset. at asiakirjat 10 TUOTETTAVAT ASIAKIRJAT Tuotettavia dokumentteja on kattavasti esitetty BY 38 kirjassa ja käynnissä olevasssa RIL:n alkuvuonna 2005 julkaistavassa projektissa Rakennesuunnittelun asiakirjaohjeistus. Tuotemallinnuksella voidaan tuottamaan nykyiset suunnittelussa käytettävät dokumentit. Dokumenttien ulkoasu poikkeaa usein totutusta ollen yleensä pelkistetympi. Tuotemallinnuksella pystytään paremmin tuottamaan tarkasti kuhunkin käyttötarkoitukseen sopivat dokumentit, jolloin nykyistenkaltaisten suunnitteludokumenttien merkitys vähenee D suunnitteludokumentit Useilla mallinnusohjelmilla voidaan tuottaa logistiikkaa palvelevaa tuoteosiin liittyvää aikataulutietoa. Tulosteena voi olla esim. havainnollinen animaatio toteutuneesta/suunnitellusta asennusaikataulusta tai vastaavasti suunnittelusta. Menettelyllä pystytään entistä helpommin havaitsemaan ja torjumaan aikataulukarikot ennalta ja selvittämään, mitä jonkin yksittäisen osan asennuksen viivästyminen vaikuttaa.

51 46/ Sähköiset asiakirjat o sähköinen tiedonsiirto ks. liite2. 11 MUUTOSTEN HALLINTA Suunnittelun muutosten hallinta edellyttää aukotonta ja etukäteen sovittua tiedonsiirron tapaa ja muutoksista tiedottamisen periaatetta. Normaalin suunnittelun eteneminen ja vaiheittainen tarkentuminen kullakin suunnittelualueella aiheuttaa muutoksia vastaavan tiedonsiirron tarpeen, vaikka varsinaisista suunnittelun muutoksista ei olekaan kyse. Tiedonsiirron tarve rakennesuunnittelijan ja muiden suunnittelijoiden välillä muodostuu entistä suuremmaksi kun suunnitteluaikatauluissa eri suunnittelualojen suunnittelua yhtäaikaistetaan Muutosten hallinta dokumenttipohjaisilla suunnittelumenettelyillä Nykykäytännössä muutosten tekeminen perustuu kunkin suunnittelijan omien dokumenttien (pääsääntöisesti 2D-muotoisten) muuttamiseen ja muutettujen dokumenttien lähettämiseen muille suunnittelijoille, jotka taas muuttavat omat dokumenttinsa muutosten osalta. Parhaimmillaankin muutosten hallinta perustuu projektin alussa tehtyyn Muutostenhallinta ja dokumentointi ohjeeseen, jossa kuvataan muutosten dokumentointi ja informointi muille osapuolille. Käytännössä informoimisen muille osapuolille tekee kohteen suunnittelija ja riskinä on, ettei tieto muutoksesta saavuta kaikkia osapuolia, joiden suunnitelmiin muutoksella on merkitystä. Muutosmenettely on hidasta johtuen useista peräkkäin tapahtuvista tiedon eteenpäin välityksistä. Dokumentteihin perustuvalla suunnittelutavalla sama muutettava tieto voi esiintyä useissa eri dokumenteissa ja vaarana on väärän tiedon jääminen johonkin dokumenttiin Muutosten hallinnan periaatteet tuotemallintamisessa Tuotemallintamiseen perustuvassa suunnittelussa on erotettava muutosten hallinnan kannalta ainakin kolme toisistaan hiukan poikkeavaa tapausta: 1. Jokaisella eri alojen suunnittelijalla on oma mallinsa ja tieto välitetään esim. IFC standardin mukaisesti. 2. Eri suunnittelualat käyttävät samaa mallia ja hallinnoivat omaa osaansa mallista. Tällöin useimmiten eri suunnittelijat käyttävät samaa ohjelmistoa. 3. Internetin yli toimiva tuotemallipalvelin, johon eri osamallit päivittyvät automaattisesti tai manuaalisesti. Kaikissa tapauksissa on muutokset tehtävä tuotemalliin, jotta tieto välittyy muille projektin osapuolille. Muutoksista jotka eivät näy tuotemallissa, kuten esim. liitosdetaljipiirustuksen muuttaminen, on tiedotettava sovitun käytännön mukaisesti. Muutoksista on tiedotettava muille osapuolille, vaikka muutos näkyisikin tuotemallissa. Vastuu muiden informoimisesta on muutoksen tekijällä.

52 47/ tapauksessa muutoksista informoiminen tapahtuu käytännössä nykykäytännön mukaisesti, vaikka tieto välitetäänkin tuotemallimuodossa tapauksessa muutokset näkyvät yhteisessä mallissa. On sovittava mitä muutoksia kukin suunnittelija saa tehdä tai jaettava malli eri suunnittelijoiden hallinnoimiin osiin. Tällöin voidaan ohjelmallisesti rajoittaa oikeuksia tehdä muutoksia. 3. Tuotemalli päivittyy sovitun käytännön mukaisesti ja muutokset näkyvät tuotemallipalvelimella. Tuotemallipalvelimella voi olla ristiriitaista tietoa muutoksen jälkeen, jos muut suunnittelijat eivät päivitä omaa malliaan muutoksen edellyttämällä tavalla. Useimmat tuotemallinnusohjelmat tallentavat jonkinlaisen historiatiedon objekteille, jolloin tarvittaessa voidaan jäljittää muutokset ja eri suunnitteluvaiheet Tuotemallinnuksen antamat mahdollisuudet muutosten hallinnalle Tuotemallinnuksella voidaan saavuttaa ainakin seuraavia etuja: o Muutostenhallinta helpottuu ja suunnittelu nopeutuu edellyttäen, että muutosten hallintaan on järjestelmä (projektikohtainen ohje) jota systemaattisesti noudatetaan. o Virheiden määrä muutossuunnittelussa vähenee, koska muutettava tieto sijaitsee vain yhdessä paikassa ja dokumentit päivittyvät automaattisesti tai ainakin ohjelmisto informoi suunnittelijaa, missä kaikissa dokumenteissa kyseinen tieto löytyy. o Suunnittelijan tuotemalliin tekemät muutokset välittyvät automaattisesti tuotemallipalvelimelta tiedotuksena muille suunnittelijoille, jotka kuittaavat vastaanottaneensa tiedon ja hyväksyvät/hylkäävät muutoksen. o Muutokset tehdään vain kertaalleen yhteen paikkaan (tuotemalliin) ja mallista tuotetut dokumentit päivittyvät, mikäli kukin suunnittelija hyväksyy muutoksen. o Mikäli eri suunnittelijoiden mallit yhdistetään voidaan yhteisen mallin oikeellisuuden tarkistamiseen käyttää mallintarkistusohjelmia. Muutosten vaikutus esim. aikatauluihin voidaan esittää havainnollisesti. Tuotemallinnus antaa parhaimmillaan mahdollisuuden hallita paremmin muutoksia, mutta edelleen on tärkeää projektin alkuvaiheessa sopia yhteisistä pelisäännöistä.

53 48/55 12 PILOTTIKOHTEEN RAPORTOINTI 12.1 Pilottikohde As.Oy Vantaan Mamselli. o 2 pienkerrostaloa ja 1 rivitalo yhteensä 1540 kem² o Rakennuttaja/ KVR-toteuttaja: Skanska Talonrakennus Oy o Arkkitehti: Arkkitehtitoimisto Larkas & Laine Oy o Rakennesuunnittelija: Finnmap Consulting Oy o Elementtitoimittaja: Parma Oy Rakennejärjestelmä: o Paaluperustukset o Kantava, tuuletettu alapohja o Kantavat väliseinäelementit ja sisäkuoripäätyelementit o Ontelolaattavälipohjat o Kevytrakenteiset yläpohjat o Ei-kantavat sisäkuorielementit (kerrostalot) / puuelementit (rivitalot) 12.2 Pilotointitavoitteet Tuotemallipohjaisen rakennesuunnittelun tavoitteet o Testataan ProIT-suunnitteluohje ja suunnitteluprosessin kulku o Perustukset, runko, ulkovaipan geometria mallinnetaan - ARK <-> RAK (molempiin suuntiin) - ARK/RAK <-> LVI - oleelliset varaustiedot mallinnetaan o Rakennuttaja / toteutuksen mahdolliset lisäarvot - 4D, määrä- ja mittatiedot jne o Raportointi - Palaute, kommentit, saavutettu lisäarvo, kehitysehdotukset, jatkotutkimukset 12.3 Tilanne per Pilotointi As.Oy Vantaan Mamselli/ Tilannekatsaus o Kohde on mallinnettu Tekla Structures 10.0:lla. o Lähtötiedot arkkitehdin ArchiCad-mallista 2D-dwg:nä, 3D-dwg vain katselumuodossa. Uusimmassa Tekla Structures versiossa 10.2 voidaan 3D-dwg:täkin käyttää täysipainoisena referenssinä. o Lähtötietojen perusteella oma malli. o Mallinnetut paalut pohjatutkimusten mukaisiin syvyyksiin paaluluettelot. o Anturat mallinnettu raudoituksilla ja tartunnoilla anturaluettelot, raudoiteluettelot, valuosa- ja tartuntaluettelot. o Sokkelielementit (sandwich) mallinnettu tarkoilla mitoilla saumoineen, yksi sokkeli raudoitettu malliksi elementtiluettelot, 4D-projektihallinta. o Ontelolaattatasot mallinnettu käyttäen valmistajan kirjastoa, saumavalut mallinnettu raudoituksineen elementtiluettelot, raudoiteluettelot. o Seinäelementit (sisäkuoria) mallinnettu mittatarkasti vaarnoineen ja aukkoineen, aukkotarkastus tehty viemällä arkkitehdin malli rakennemallin päälle.

54 49/55 o Luhtitasojen elementtilaatat mallinnettu leukoineen. o Kattotuolit mallinnettu mittatarkasti, kuvat suoraan mallista valmistajalle kaaviot ja luettelot. o Salaojitus mallinnettu todellisiin korkoihin kaivoineen. o Varaustiedot 2D-dwg:nä malliin, tullaan kokeilemaan LVI-mallin toiminta 3D:nä rakennemalliin. o Urakoitsijalle toimitettu mallista saatavat listat paaluista, rakenneosista, valumääristä ja raudoituksista ja tartuntaosista rakenneosakohtaisesti. o PILOTOINTI VIELÄ KESKEN, suunnitteluohje laadinnassa ja VTT / Sulankiveltä tulossa raportti. o testattu IFC mallin siirtämistä malliin ja mallista

55 50/55 13 OHJEIDEN JATKOKEHITTÄMINEN Visio tuotemallipohjaisen rakennesuunnittelun tulevaisuudesta voisi pitää sisällään seuraavia elementtejä: o Suunnittelu tehdään yhteiseen malliin siten, että päällekkäisyys eri suunnittelualojen kesken on minimoitu. o Rakennesuunnittelun eri osa-alueisiin sekä suunnitteluvaiheisiin on käyttöliittymältään nopeat ja joustavat työkalut. o Elinkaarisuunnittelu tehdään muun suunnittelun yhteydessä tuotemallipohjaisesti. o Hankkeiden toteutukseen muodostuu verkostoja, jotka tuntevat toistensa toimintatavat, mikä edesauttaa tuotemallisuunnittelun hyötyjen maksimoimista aidolla win-winperiaatteella. Edellä mainittuihin tulevaisuuden kuviin peilattuna jatkokehitettävää mallintavan rakennesuunnittelun alueella löytyy mm. seuraavilta sektoreilta: o suunnittelutyökaluissa on kehitettävää o keskitetysti hallinnoitu rakenneosa-/liittymäkirjastopankki tarvitaan o muutosten hallintaan tarvitaan toimiva järjestelmä (ohje, joka hyödyntää tuotemallintamisen edut) o suunnitteluryhmän keskinäiseen tiedonsiirtoon ja yhteisiin suunnitteluasioihin tulee laatia toimivat ohjeistukset (mm. projektikohtainen tuotemallisuunnitteluohje, varausmerkintäohje) o kattava statiikka moottori linkitettynä tuotemalliohjelmistoon on rakennesuunnittelijalle tärkeä. o tehtäväluettelot tulee päivittää tuotemallisuunnittelun näkökulmasta o Ohjeen saattaminen laajaan käyttöön tapahtuu parhaiten niin, että ohjeen kehittämisessä mukana olleet rakennesuunnittelutoimistot ottavat sen välittömästi käyttöön käytännön projekteissa ja keräävät säännöllisesti palautetta kirjallisesti. ProIT-projekti organisoi dokumentointi- ja palautejärjestelmän, joilla varmistetaan, että todellinen palaute käytännön projekteista saadaan vietyä ohjeeseen. LIITTEET Liite 1 Liite 2 Liite 3 Liite 4 Liite 5 Liite 6 Liite 7 Liite 8 Liite 9 Liite 10 Tuotemallinnusohjeen sisällysluettelo Sähköinen tiedonsiirto Projektiohjelmisto-ohje Lähtötietoaikataulu As.Oy Sorsavuori Elementtisuunnittelun lähtötietoluettelo Rakennesuunnittelijan lähtötietokaavake Varauspiirustusohje Teräsrakennesuunnittelun tulosteet runkorakenteista Tuotemallipohjaisen suunnittelun yleisiä määrityksiä Tuotemallinnuksen käsitteitä ja sanastoa rakennesuunnittelussa

56 TUOTEMALLINNUS 1 RAKENNESUUNNITTELUSSA LIITE 1 Tehtävälista Tekla Strures:n käytöstä ja ympäristöstä Uusi malli Mallinpohjan tekeminen, missä perusasetukset valmiina Mallien tallettaminen ja fyysinen sijainti Raporttipohjat ja niiden päätteet Tulostaminen, pdf, word ja excel Valmiiden wizardien tekeminen: Single-kuvat Tietokantojen täydentäminen standien mukaiseksi Profiilitietokanta Pulttitietokanta Materiaalitietokanta Tulostimet: DWG- ja PLT-tiedostojen tekeminen Näkymät Automaattinen luonti Nimeäminen ja niiden muuttaminen Detailing Liitosten ja detaljien luominen Periaatteet niiden luomiseen AutoConnection erilaiset valmiit rakenteet Kuvien luonti Valmiit kuvapohjat Tarvittavat muutettavat kohdat Kuvalista Eri merkintöjen käyttö: I, F, L, rev ja Name Kloonaus Beam attributes Prefiksit Nimeäminen Class User devined attributes Position, mallinnus periaatteet Project Täyttöohjeet object.inp (attribuutit) Phase number Käyttöperiaatteet Konepajan huomioiminen Layout Template pohjat ja asemointi GA-kuvat, omat pohjat seuraaville; urakka, 3D-havainnekuva, tasokuva peruspulteista, tasokuva, cast unit kuvat multidrawing; Det-pohjat liitos 2D ja 3D kuvia kun tehdään niin yksi kuva, jossa mittakaava ja cutti määritellään, sen jälkeen vasta joukko tulostus

57 TUOTEMALLINNUS 2 RAKENNESUUNNITTELUSSA Setup Numerointiperiaatteet FMC liitoskirjaston luonti TS-tiedostojen sisältö ja rakenne tiedostopuu, minkälainen C:llä että S:llä ja W:llä eri battien sisältö layoutit ja valmiit kuvapohjat ja batti semmonen että hakee sieltä user-joint kirjasto Tunnusnumerointi TS:llä Mallin sisäinen tarkistus Viewerin käyttö web viewer lista mitä tarkistetaan tarkastaja tekijän lisäksi Liitokset nimeäminen Tulostaminen Paperille viivapaksuudet kansilehdet numerointi ja koodaus-järjestelmä kuville (lukuavain) kuvien hallinta, revisiointi ARKISTOINTI TS ASETUKSET Sekalaista class-värisävyt-vaikutus listauksiin ja templateihin bat korvattavien tiedostojen asentamiseen uusi templatepohja yleistiedoille ja lähtötietojen antaminen kuvakohtaisesti user attributeilla laskentapohjat liitoksille ja niiden pohjalta asetukset user defaulttiin Phasen käyttö keyplanien käyttö jakelutaulukon muuttaminen siten, että rivimäärä on vakio ja kenelle menee on attribuuteissa donglejen käyttösäännöt import - export ohjeet, mallin lähettämisen periaatteet tarvittavat listaukset ja niiden tulostaminen kuvien lähettäminen, niihin liittyvät liitteet ja listaukset, sekä piirustusluettelon ylläpitäminen (xe oma ja excel) valmis filteroinnit

58 TUOTEMALLINNUS 3 RAKENNESUUNNITTELUSSA Liite2 SÄHKÖINEN TIEDONSIIRTO YLEISTÄ Teräsrakenneala on ollut edelläkävijä tuotetietojen siirron kehittämisessä. Organisaatioiden välinen sähköinen tiedonsiirto on jo osin rutiinia ja yleistyy jatkuvasti. CIMSTEEL-projektissa on kehitetty Step-pohjainen tuotemalli teräsrakenteiden tuotetietojen siirtämiseen. SteelBase-projektissa on kehitetty sähköistä tiedonsiirtoa, jolla voidaan hallita tietojärjestelmiä hyödyntämällä teräsrakennetoimituksen kaikki vaiheet: suunnittelu, materiaalin hankinta, valmistus, kuljetus ja asennus. CIS/2 on Eureka-projektissa (EU130) sovittu tapa esittää teräsrunkoja koskevaa tietoa tietokoneohjattua valmistusta varten. Tämän standardin mukaisella tuotetietomallimäärittelyllä mahdollistetaan teräsrakenneprojekteissa vain yhden Tiedonsiirtoformaatin käyttö. Tämän pohjalta on ohjelmoitu StBrowser- tuotemalliselain ja standardiversion päivityksen yhteydessä StBConventer- formaattitranslaattori. Perusperiaate on se, että SteelBase-tiedosto liittyvine määrityksineen on SteelBase-projektin varsinainen tulos eli neutraali tiedonsiirtotapa, jota käyttäen rakennushankkeen eri osapuolet voivat siirtää hankkeen teräsrungon materiaaleihin liittyvää tietoa ohjelmista ja laitteistoista riippumatta osapuolelta toiselle. /1./ SteelBase-tiedostosta kukin rakennushankkeen osapuoli voi hakea tarvitsemiansa tietoja. Esimerkiksi arkkitehdit, LVIS-suunnittelijat, rakennuksen loppukäyttäjät, laitesuunnittelijat, muut urakoitsijat jne voivat tutkia hyvinki tarkasti, millainen teräsrunko rakennukseen tulee. Periaatteessa SteelBase-tiedostoa voidaan käyttää lähes kaikkiin sovellutuksiin, joissa tarvitaan teräsrungon ja sen osien geometrian ja materiaalihallinnan tietoja. SteelBase-tiedoston sisältö kattaa hyvin konepajojen tarpeet. Tiedonsiirron laajuus riippuu siitä, mitä projektin osapuolten välillä on sovittu työnjaosta. Siirrettävien tietojen määrän kasvattaminen tai kaikkien sovelluksessa tarvittavien tietojen siirtäminen ei sinänsä ole itseisarvo. Idea sovitun, neutraalin tiedonsiirron käytössä on se, että esimerkiksi kunkin suunnittelijan ei tarvitsisi ohjelmoida uutta tiedoston tuottamisohjelmaa valmistajan hankkiessa uuden laitteen tai suunnittelijan alkaessa suunnitella uudelle valmistajalle. Samoin valmistaja voi neutraalia tiedonsiirtotapaa käytettäessä lähteä aina samasta tiedostosta ohjelmoidessaan konversioohjelmaa materiaalihallintoon, työstökoneelle tai hitsausrobotille. Valmistaja tuntee paremmin koneensa kuin suunnittelija, joten on luonnollista, että valmistaja tekee itse konversion laitteisiinsa. Neutraalin tiedonsiirron käyttö mahdollistaa sen, että kukin voi tehdä sitä työtä, mitä parhaiten osaa: Suunnittelijat suunnittelevat ja valmistajat valmistavat. Tekla Structures luo tiedostot koko mallista siten, että se kääntää osan pituuden, reikien sijainnin, viisteet, lovet (notch) ja leikkaukset numeeriseen muotoon, jotta profiilin sahaus, poraus ja polttaminen voidaan tehdä konepajassa. Tiedonsiirrot tulisi ajoittaa niin, että siirrettävä tieto olisi pääosin lopullista. Näin vältytään turhalta päivitystyöltä kun alkutiedot vielä muuttuvat. Tämä asettaa haasteen työnsuunnittelulle ja suunnittelu-aktiviteettien järkevälle jaolle projektiosapuolten kesken. DSTV (Deutcher Stahlbau-Verband) on saksalainen standardi, josta löytyvät sopimukset mm. lujuusanalyysitietojen välittämiseksi CAD-järjestelmiin ja edelleen CAD-järjestelmästä NC-ohjattuun (Numerical Control) työstökoneeseen. Työstökoneen tarvitsema tieto on parametrisoitua paikkatietoa työstettävästä kappaleesta ja siihen tulevista työstöistä (features = reiät, viisteet, katkaisut jne). Koneistaja voi tarvittaessa tehdä NCohjelmiin muutoksia tai korjauksia. /1./

59 TUOTEMALLINNUS 4 RAKENNESUUNNITTELUSSA Seuraavana lyhyt yhteenveto eri osapuolille koituvista hyödyistä ja velvotteista. Konepaja: säästää aikaa, yhden DSTV-koodin syöttäminen vie n.5min ja yhden osakokoonpanon syöttäminen n.10-15min. Yksi PPTH SAP-tiedoston rivi sisältää 14 syöttökenttää, sisältäen mm. profiilit, profiilien laadut, osakokoonpanoon liittyvät osat määrineen. virheiden määrä vähenee sähköisessä tiedonsiirrossa (käytännössä menee nollaa) teräsrakennetoimituksen läpimenoajan lyhentyminen projektiaikaisten muutosten parempi hallinta Suunnittelija: SAP-raporttien tekeminen ja niiden päivittäminen DSTV-tiedostojen tekeminen yksittäiselle osalle joudutaan mallinnusvaiheessa syöttämään lisää tietoa mallisnusohjelman tietokantaan (esim. yksikköhintaryhmä) osakuvia ei tarvitse revisioida kappale muutosten takia (varusteluosia ei valmisteta osakuvassa olevan määrän mukaisesti vaan SAP-tietokannasta saatujen määrien mukaisesti) Sähköinen tiedonsiirto vaatii sekä suunnittelutoimistolle että konepajalle investointeja ohjelmistoihin ja käyttäjien koulutukseen, jotta järjestelmä toimii toivotulla tavalla. TULEVAISUUS Tiedostoja voidaan käyttää paitsi osapuolten väliseen tiedonsiirtoon, niin myös tulevaisuudessa erilaisten työstökoneiden ohjaustietojen tuottamiseen, kokoonpanorobottien ohjaustiedon generoimiseen, erilaisten teräsrunkojen kustannusarvioiden tekemiseen, asennus- ja kuljetussuunnitelmien tekemiseen, pakkausluetteloiden automaattiseen tuottamiseen, työnsuunnitteluun konepajalla, maalaus- ja pintakäsittelyn suunnitteluun ja hinnoitteluun jne. Sähköisestä tiedonsiirrosta on tullut jo yleinen käytäntö teräsrakenneprojekteissa, mutta pelisäännöistä tarvittaisiin yhtenäiset ohjeet kuinka toimia, esim; Kenen kuuluu varmistaa esim. DSTV-tiedoston oikeellisuus, suunnittelijan vai konepajan edustajan? Onko suunnittelija velvollinen luovuttamaan tuotemallin (esim. Xsteel-mallin) tilaajalle suunnittelutyön valmistuttua ja missä muodossa? Mitä sähköisiä tietoja suunnittelijan tulee luovuttaa esim. konepajalle veloituksetta (esim. DSTV)? Lähteet:/1./SteelBase-Teräsrakenneprojektin oliopohjainen tiedonhallinta- ja tiedonsiirtojärjestelmä, Projektiraportti TRY, 1997

60 LIITE Kuva 1. Yleisohje ohjelmiston käytöstä.

61 LIITE 3 Kuva 2. Projektikohtainen numerointiohje Kuva 3. Kerrostasokohtainen numerointiohje. Kuva 4. Kuvatasojen nimeämisohje.

62 LIITE Kuva 5. Projektin liitostiedot. Kuva 6. Projektin detaljiluettelo.

63 LIITE Kuva 7. Projektin raudoitetiedot. Kuva 8. Piirustusten nimeämisohje.

64 LIITE Kuva 9. Piirustusten jakeluohje. Kuva 10. Kuvatasojen nimeämisohje (TALO 2000).