10v vanhaa tekstiä Graniselta, CAD 1980-2010

Vuonna 2010 julkaistiin hieno Olof Granlund Oy:n 50v historiakirja:
"Suomalaista talotekniikan suunnittelua ja konsultointia vuodesta 1960"

Minulle annettin tehtäväksi kirjoittaa CAD-kehityksestä, vaikka olin ollut tuolloin vasta 10v firmassa hommissa. Haastattelin 1980 - 2000 -luvulla työskennelleitä henkilöitä ja yritin ymmärtää sen ajan tapahtumia.

Alla oleva kirjoitus on alkuperäinen tekstini, joka ei mennyt läpi laaduntarkkailusta. Kirjassa stoori on erilainen, mutta asiasisältö suurin piirtein sama.

10v sitten otti hieman päähän, että mielestäni hyvä ja aikaavievä duuni ei sellaisenaan kelvannut, mutta nyt olen jo sinut sen kanssa...



---

CAD 1982 - 2010

Alkutaipaleet 1982-1989

Alkutaipaleet cad-järjestelmän hankinnassa olivat kokeellista, linjaa hakevaa toimintaa. Tietokoneita yhtiössä jo oli, mutta mitään niistä ei käytetty tasokuvien tai kaavioiden piirtämiseen.

Ensikosketus CAD järjestelmiin saatiin vuonna 1982, kun yhtiöön hankittiin Sirius S1–tietokone ¹, CP/M käyttöjärjestelmällä. Ohjelmistona oli juuri taivaltaan aloittelevan firman Autodesk inc. lippulaivatuote AutoCAD 1.0. Koneen hankinnassa mukana oli vahvasti sähköosaston panostusta ja sähköpiirtoon sitä lähinnä käytettiinkin.

Toimitusjohtaja Olof Granlund pyysi tutkimaan, että säästetäänkö AutoCADillä mitään. Koneella tehtiin muutama sarjatuotantoprojekti Venäjälle, jonka jälkeen sitä enää käytetty – säästötavotteita ei varmaankaan siis saavutettu.

Niin yllättävältä kuin se voi kuulostaakin, tarjontaa cad-ympäristöistä oli jo tuohon aikaan olemassa aika paljon. Muun muossa Tekninen laskenta Oy, eli nykymuodossa Tekla tarjosi jo mahdollisuuksia cad-suunnitteluun omalla ALVISR –integroidulla rakennussuunnitteluohjelmistollaan.

Seuraava cad-valinta ei kuitenkaan kohdistunut Teklan tuotteisiin, vaan luotettiin Wärtsilän sekä Arkkitehtiryhmä Erik Kråkström Ky:n kokemuksiin  Prime Medusasta² minikonejärjestelmästä. PC koneisiin ei enää CADiä asennettu, vaan luotettiin minikoneisiin, siis usean käyttäjän järjestelmiin jossa laskentateho oli keskuskoneella.

Ensimmäinen Prime Medusa kone maksoi vuonna 1985 arviolta kolmen-neljän saksalaisen hyvän auton verran - satoja tuhansia markkoja. Olof Granlund oli todennut, että tästä kehityksestä ei voi jäädä jälkeen ja löytänyt yhtiön kassasta rahoituksen ensimmäisen cad-järjestelmän hankinnalle.

Medusan myyntiedustajalla oli Wärtsilästä tullut, vähän käytetty koneikko, jota he tarjosivat Granlundille. Kun kaupat oli tehty, Primen myyntipäällikkö (nykyinen FutureCADin toimitusjohtaja) sanoi, että: ”Eiköhän juoda kahvit, vaikka tämä oli varmaan Primen historian pienin kauppa”. Olof kuulemma puri hammasta, joi kahvit ja sanoi ulkona: ”Tuosta talosta ei kyllä enää osteta yhtään mitään”.

Eikä paketti ollut ihan täydellinenkään, vaan siihen piti ostaa lisäksi kuvaruutueditori, EMACS. Käytännössä siis tekstieditori. Hintalappu tälle oli 5.000mk.

Medusa tuli ilman mitään erikoista sovellusohjelmaa. Erinäisiä ohjelmistoja löydettiin Ruotsista mutta myös itse rakennettiin mm. Haltonin päätelaitesymboleja ja muita LVI-teknisiä symboleja.

Myös LVI-kaavioiden tekoa alettiin siirtää Medusalle, symboleiden käsittelyssä cad-tekniikka näytti mahdollisuudet tuottavassa käytössä.

Vuonna 1986 alkoi ensimmäinen suomalainen jokaisen suunnittelualan kattava CAD-projekti, Jyväskylän VTT:n kotimaisten polttoaineiden laboratorio – haastava kohde jo suunnittelumielessä. Erikoislaboratorioita ja muita haastavia LVIS-teknisiä ratkaisuja. CAD suunnittelussa oli mukana niin arkkitehti-, rakenne- kuin LVI -suunnittelu.

Kohde oli Rakennushallituksen koehanke, jossa sovittiin mm. tasojaot eri suunnittelijoiden kesken. Rakennushallitus (nyk. Senaatti kiinteistöt) oli siis jo tuolloin edelläkävijä hankkeiden suunnitteluttamisessa ajankohdan uusimmin menetelmin.

Arkkitehtiryhmä Erik Kråkström Ky oli suunniteluut mm. Loviisan ydinvoimalan arkkitehtuurin sekä lukuisia muita teollisuuden kohteita. Heillä oli käytössä myös Medusa, joten tiedonsiirto onnistui ilman konversioita. Tiedonsiirto hoidettiin modeemien välityksellä suoraan suunnittelijoiden kesken, eli projektipankkeja ei ollut vielä sekoittamassa projekteja.

Käytössä ei ollut viitekuvia, vaan, arkkitehtipohjien päivitykset tehtiin tasojaon kautta. Oli siis erittäin tärkeää piirtää oikeille tasolle, koska kuvien päivitys tapahtui deletoimalla vanhat tasot ja tuomalla uudet sisään.

Kun Medusan käyttö siirtyi tuotantotyökaluksi, huomattiin myös pieniä puutteita. Kun piirtäjä zoomasi johonkin kulmaan rakennusta, vei se lähes kokonaan minikoneen tehot. Muut cad-työskentelijät tuskastuivat, kun oman päätteet tehot katosivat hetkessä.

Parannusideoiden toivossa käytiin myös tutustumassa muihin yrityksiin, mm. Imatran Voimaan jolla oli vähän alle miljoona markkaa maksanut työasema tuplanäytöllä. Työaseman erikoisuus oli ”rautazoom” ja panorointi, jolloin minikoneen tehoja ei zoomailuun käytetty. Jostain syystä tällaista työasemaversiota ei kuitenkaan Granlundille hankittu.

Ensimmäisten projektien perusteella voitiin todeta että cadin käyttö ei ainakaan nopeuta suunnittelua. Käsin tehden syntyi kustannustehokkaammin tasopiirustuksia. Mutta firman johto oli nähnyt selvästi tulevaisuuden – tämä oli se tie, jota tulee kulkea ollakseen taloteknisen suunnittelun kärjessä. Tuohon aikaan suunnittelijoiden piirissä oli myös eriäviä näkemyksiä – joidenkin mielestä cad-piirtämiseen tuhlataan turhaan firman resursseja ja rahaa.

Mutta yhdellä alalla Medusa oli ylivoimainen – suurkeittiösuunnittelussa. Granlundilla oli myös suurkeittiösuunnittelutoimeksiantoja, joissa oli riittävää toistuvuutta koskien keittiölaitteita. Samalla saatiin tehtyä seinäprojektiot, joiden teko nopeutui  huomattavasti verrattuna käsinpiirtoon. Oma, laaja laitekirjasto rakennettiin suunnittelukohteiden yhteydessä.

Samoin RAU suunnittelu käytti vahvasti Medusaa apuna. Toistuvien symbolien käsittey sekä helpohko ohjelmoitavuus olivat Medusan valtteja.

Medusaa eivät käyttäneet vain Granlundin piirtäjät, vaan se oli myös suunnittelijan eli nuorien vastavalmistuneiden teekkarien työkalu. Heillä oli siis käytännössä kaksinkertainen työpanos kohteiden suunnittelussa. Piti rakentaa LVI-tekniset järjestelmät sekä vielä piirtää kohteet ”puhtaaksi” cadillä.

CAD suunnitelmien muoville saattaminen oli vielä eksoottisempaa kuin nykyaikoina. Rapido kynäplotterit repivät alussa muoveja sekä transparentteja ja tulostuksen sai aina aloittaa alusta – kunnes löydettiin toimiva kokonaisuus välillä mustekynä – muovikalvo. Huopatussien tullessa markkinoille tulostus helpottui hieman. Piirturi oli mukana alusta asti, eli vuodesta 1985 lähtien.

Medusan käytöstä eräs veteraanimme totesi: ”Medusassa oli se hyvä puoli, että siihen sai tosi helposti itsekin tehtyä ohjelmia, paljon helpommin kuin Autocadiin, mutta muuten piirtäminen oli aika onnetonta, sillä se oli suunniteltu kolmikätisille ihmisille. Yksi käsi ohjasi kursoria, toinen antoi komentoja ja kolmas näpytteli näppäimistöä. Eli ei mikään ergonomian riemuvoitto.”

Medusalla tehdyt suunnitelmat ajoittuvat vuosiin 1986-1989. Parhaimmillaan Medusan minikoneessa oli 4 työasemaa kiinni.

1: http://en.wikipedia.org/wiki/Sirius_S1

2: http://en.wikipedia.org/wiki/Prime_Computer

  

PC- koneet tulevat, 1990-

1990 alussa sähköosasto hankki PC koneeseen AutoCADin uusimman version, jolloin entiset minikoneiden käyttäjätkin totesivat, että vähemmällä rahalla voi saada vastaavan cad-suunnitteluympäristön.

1990 tehtiin yhtiössä selvitys siitä, mihin suuntaan maailma oli menossa cad-rintamalla.

Ansiokkaan selvityksen loppuyhteenveto oli:

1.     CAD suunnittelu tulee tapahtumaan PC työasemissa jotka on kytkettynä verkkoon

2.     LVI-CAD –laitteiden hankintaa ohjaa projektien vaatimukset ja sovellusohjelmien kehitys.

3.     Säätösuunnittelu tulee laajentumaan kaavioiden piirrosta suunnittelutietokannan hallintaan

Tämä oli viimeinen isku minikoneiden käytössä cad-suunnitteluun. Aluekonttoreissa oli jo hankittuna pc koneita jotka olivat varustettuja AutoCADillä ja ARK tuoteperheen ohjelmistoilla ja pääkonttorilla sähköosasto oli siirtynyt AutoCADiin.

Tulevat koneet olivat PC työasemia ja ne varustettiin LVI-ARK / Sähäkkä sovelluksin. Rakennusautomaatiokaavioiden piirtoon tehtiin oma sovellus, jonka kehittyneempää, vuonna 1997 tehtyä versiota käytetään konsernissa edelleen, ajanmukaisin muutoksin varustettuna.

Pääkaavioiden piirtoon Granlund kehitti vuonna 1991 AutoCADin päälle oman ohjelmiston nimeltä GOSÄPI. GOSÄPI oli todellinen menestys, ja olisi varmaan käytössä vieläkin vuonna 2010 jos se käyttöä ei olisi erikseen kielletty 2000 luvun puolivälissä. Kieltoon ei ollut syynä se, että kerrankin oli tehty toimiva ohjelmisto, vaan sen kehitys uusille AutoCAD versioille vaati liikaa resursseja ja halu siirtyä ohjelmistoperheissä yhtenäisiin tuotteisiin. Silti, CAD ylläpidolle kantautuu silloin tällöin tukipyyntöjä erään pääkaaviosovelluksen tiimoilta…

Vuonna 1991 cad työasemalle oli hintalappuna 131.000mk. Hinta sisälsi keskuskoneen 386 prosessorilla sekä erillisen 387 matematiikkaprosessorin, jonka AutoCAD 11 vaati toimiakseen. Monitori oli 21” Salora varustettuna Rasterexin näytönohjaimella. Niiden osuus kokonaishinnasta oli enemmän kuin keskusyksikön.

Koska oli todennettu, että CAD ei nopeuta työskentelyä ja suunnittelijan resursseja siihen ei kannata aina hukata, päädyttiin loogiseen vaihtoehtoon – piirtäjistä alettiin kouluttaa cad-piirtäjiä.

Kuitenkin osaa suunnittelijoista kiehtoi cad-maailma sen verran, että myös he halusivat olla kehityksen kärjessä tällä saralla. Niinpä cad osaaminen ei ollut vain yhden ammattiryhmän hallinnassa, vaan osa suunnittelijoista piirsi kohteensa puhtaaksi, käyttäen cad-järjestelmää myös suunnittelutyökaluna.

Vuonna 1991 suunniteltiin AutoCADillä Inarin Sähkölaitos käyttäen kaikkia suunnittelualoja mukana, tasopiirustuksista kaavioihin. CAD säännöissä pidettiin tärkeänä, että jokainen ilmoittaa käyttämänsä tasot sekä niiden värit ja tulostuspaksuudet. Välillä tuntuu, että tämä käytäntö on valitettavasti jäänyt historiallisena kuriositeettina voimaan vielä näihinkin päiviin.

Tietokoneiden määrä kasvoi konsernissa 1993 jälkeen nopeaa tahtia, 40-70 koneen vuosihankintatahtia. Voidaan todeta, että Granliund siirtyi käsinpiirrosta CAD suunnitteluun vuosien 1994-1999 aikana.

Informaation siirto CAD-kuvista tietokantoihin on aina ollut Granlundin vahvuus. Valaisimia, hanaluetteloita, RAU-automaatiopisteitä jne. tietoja on siirretty joko cad-järjestelmästä tietokantaan tai toisinpäin.

LVI–ARK ja Sähäkkä vakiinnuttivat paikkansa PC koneiden piirtotyökaluna 1990 luvun ajaksi. Autodeskin cad-alusta on käytössä konsernissa edelleenkin.

IFC

Yhtion johto oli 1990 luvun alusta lähtien solminut suhteita kansainvälisen ohjelmistokehityksen tiimoilta. Eräs kulmakivi oli Suomen delegaation saapuminen San Rafaeliin 1996, jossa Autodeskin ehdotuksesta perustettiin IAI:n Nordic Chapter. IAI tunnetaan nykyisin BuildingSMART organisaationa, jonka tarkoitus on levittää tietomallinnuksen ideaa ja tukea / organisoida IFC:n kehitystä.

Mielenkiintoista tässä kuviossa on se, että IFC:kehitys on Autodeskin alkuunlaittama hanke ja kun se todella saatiin käyntiin, alkoi Autodesk vetäytyä syrjempään sen toiminnallisuuksista. Näin ollen IFC:n tämän hetken kehitys nojaa BuildingSMARTin organisaatioon – jossa Granlund on ollut mukana  organisaation perustamisesta lähtien, vuodesta 1995.

Huomionarvoista on myös Suomessa tuohon aikaan ollut valveutuneisuus tietomallinnuksen kehittämisessä.  Tekesin vetämä Vera –teknologiaprojekti mahdollisti monen uraa-uurtavan ohjelmistojen  ja prosessien käyttönoton. Eräistä lisäpotkua saaneista ohjelmistoista / yhtiöistä voidaan todeta Solibri, MagiCAD ja Tekla – Granlundia unohtamatta.

Vera -projektin ajankohta osui juuri oikeaan hetkeen, kun verrataan mitä maailmalla tapahtui. IAI oli perustettu, oli yhteinen ymmärrys siitä, että CAD ei voi olla vain kynän jatke - piirtotyökalu. Vera mahdollisti osarahoituksen uusien menetelmien kehittämiselle.

1990 luvun puolivälissä kansainvälistymisen aikana tuli idea toteuttaa energia- ja olosuhdesimuloinnit rakennuksen 3D-malliin perustuvina. Koska ARK 3D malleja ei ollut tuohon aikaan projekteissa olemassa, kehitettiin oma ohjelmisto; SMOG, Space Modeller of Olof Granlund. Kuten arvata saattaa, nimi herätti mielenkiintoa Kalifornian alueella erinäisissä esittelytilaisuuksissa.

SMOGilla mallinnettiin seinät arkkitehdin 2D pohjan päälle, lisättiin tilat, ikkunat ja ovet ja ajettiin kohteesta IFC tiedosto ulos.

IFC tiedoston geometriatiedot luki sisällensä Granlundin tekemä Energia ja Olosuhdeohjelmisto ”Riuska”, käyttäen omatekemää väliohjelmaa nimeltä BSPro.  Enää ei tarvittu pinta-alojen ja tilavuuksien manuaalista näpyttelyä, vaan geometria- ja tilatieto oli valmiina mallissa. Voitiin keskittyä olennaisempaan, eli tietosisällön kasvattamiseen (materiaalit, aikataulut, iv-konepalvelualueet jne.).

SMOGin kehitys lopetettiin 2000 luvun alussa ja siinä tehdyt tekniikat siirrettiin Progman Oy:n MagiCAD Room ohjelmistoon, jota käytetään tänäkin päivänä vastaavaan tarkoitukseen. Granlundin tekemä BSPro elää edelleen väliohjelmana mm. MagiCADin ja Riuskan IFC-siirtorajapintana.

  

Valaistussimuloinnit

Sähköosasto laski jo 1980 luvulla omatekemillään ohjelmistoilla valaistuskäyriä (GOLUX) jotka piirtyivät huoneen pohjakuvaan ”korkeuskäyrinä”. Välillä suunnittelija joutui selittelemään asiakkaalleen, että miten nämä ”korkeuskäyrät” liittyvät huoneen valaistustasoon.

Seuraava askel siihen, miten saadaan asiakas hahmottamaan tilojen valaistutasot olivat valaistussimuloinnit. Tarjotaan asiakkaalle siis fotorealistinen tietokonemallinnus tilasta.

On edelleenkin tärkeää, että puhutaan valaistussimuloinneista, eikä visualisoinneista. Visualisointi on kiva kuva, mutta simulointi pitää sisällään oikeiden valaisinten valaistustiedot sekä kohdetilan materiaalien heijastuskertoimet niin huolellisesti säädettynä todellisuutta vastaaviksi kuin voidaan – riippuen tietenkin käytetyn ohjelmiston mahdollisuuksista ja mallintajan ammattitaidosta..

Valaistukseen ja CAD-maailmaan erikoistuneet suunnittelijamme seurasivat kateellisena vieressä, kun valaisinvalmistaja Fagerhultilta löytyi Silicon Graphicsin raudan päällä toimiva Lightscape –ohjelmisto. Oli yleisesti maailmalla tunnustettu, että se oli paras softa valaistuksen simulointiin – ohjelmasta saatiiin esim. tekniset valaistusarvot numeroina suoraan simuloidun kuvan päälle ja materiaalien sekä valojen hienosäätöön oli riittävästi mahdollisuuksia. Granlund teki muutamaan kohteeseen tilojen geometrian ja Fagerhult tarjosi palveluna siihen heidän valaisimillaan tehdyn simuloinnin.

Käytiin myös neuvotteluja erillisen yhteystyökumppanin kanssa oman valaistussimulointiohjelmiston tekemisestä. Kesken näiden neuvottelujen kuultiin, että Lightscape tullaan saamaan myös PC alustalle. Sen seurauksena neuvottelut loppuivat ja Granlundille hankittiin Suomen ensimmäinen Lightscapen PC lisenssi, joulukuussa 1996.

Tämän jälkeen voitiin asiakkaalle tarjota fotorealistisia mallinnoksia suunnittelukohteista, jotka erotti valokuvasta vain se, että valokuva oli ”likaisempi” ja mallinnos hieman laboratoriomainen.

Aina asiakasta tai muita suunnittelijoita eivät valaistustasot näissä kuvissa kiinnostaneet – eräässä kohteessa esiteltiin kohdetta arkkitehdille, joka alkoi ihmetellä teräsrakenteita. Kävi ilmi, että mallintajamme oli tehnyt rakennesuunnittelijan 2d piirustusten perusteella teräsrakenteet malliin. Teräsrakenteiden massiivisuus tuli arkkitehdille yllätyksenä, ja hän ilmoitti rakennesuunnittelijalle, että niin asia ei voi olla - rakenteet on muutettava. Rakennesuunnittelija muisti kiittää sähkösuunnittelijaa heidän työnsä uudelleensuunnitteluttamisesta…

Lisäksi auditorioista on poistunut mm. ensimmäisiä penkkirivejä valaistussimulointien tuloksena, kun ollaan istuttu virtuaalisesti ensimmäisellä rivillä ja todettu, että siitä ei näe juuri mitään. Useiden kohteiden tuolien väritys on muuttunut ja muita pienempiä asioita. Tarkoituksena on siis ollut tehdä tutkielma, miten valaistus riittää kohteessa mutta ne kääntyvät nopeasti sisustussuunnittelijan työkaluksi.

Nykyään ollaan oltu hieman viisaampia ja tarjottu teknisiä visualisointeja valaistussimulointien tilalle, jos halutaan tutkia tilan geometriaa tai huonekalujen sijoitusta. ”Kivan kuvan” tekemiseen menee murto-osa siitä ajasta joka valaistussimulointiin käytetään mutta informatiivinen sisältö tilan käytön ja tavaroiden käytettävyyden suhteen on riittävä

Valaistussimulointien veteraanimme muistelee: ”Koneiden suorituskyky on aina ollut lujilla valaistussimulointien kanssa. Yleensä vielä nykyäänkin koneet laitetaan laskemaan yöksi ja aamulla katsotaan mitä syntyi. Aiemmin se oli yleensä niin, että perjantai-iltana saatiin malli laskentakuntoon, ja maanantai-aamuna nähtiin, kuinka pitkälle laskenta oli edistynyt; joskus valmiiksi, joskus ei. Pahinta oli, kun laskenta keskeytyi johonkin virheeseen ja parin vuorokauden laskenta oli siinä.”

Kannettavat tietokoneetkin olivat yleistyneet 1990 luvulla: ”Siihen aikaan, kun läppärit olivat tehottomia, minulla oli visualisointeihin käytössä ihan oma ”kannettava” PC. Eli sellainen normaalia tuplaten korkeampikoteloinen tehomylly, johon väsäsin kantohihnat. On jäänyt mieleen yksi kerta, kun menimme palaveriin Nokian johonkin neukkariin, ja sinne kuljettiin sellaisen katetun sisäpihan läpi, jossa ihmisiä istui syömässä ja kahvilla. Tuntui, että kaikki seurasivat hymyillen kulkuamme, kun raahasin toisessa kädessä sitä hienoa ”kannettavaani” (siihen oli muuten hienosti hihnoilla kiinnitetty näppiskin mukaan) ja toisessa kädessä melkein yhtä isoa videotykin kantolaatikkoa (joka oli siis sellainen metallivahvisteinen sininen oikein kunnon aski). Hiki tuli aina päähän neuvottelukeikoilla… Toista on nykyään.”

Lightscapen kehitys valitettavasti lopetettiin vuosituhannen vaihteessa ja ominaisuudet siirrettiin Autodesk 3DS MAXiin – joskin mallintajat ovat sanoneet, että vasta viimeaikoina 3DS MAX on päässyt lähelle sitä tasoa, mitä Lightscape oli.

  

ELVIS ja todelliset tuotetiedot

LVI-ARK oli vain piirto-ohjelma. Se oli tiedossa jo 1980 –luvun lopulla ja pyrkimys oli saada seuraavan sukupolven ohjelmisto, jolla voitaisiin suorittaa verkostojen tasapainotus suoraan cad-suunnitelmasta. 1990 luvun alussa verkostot mallinnettiin ”solmupisteitä” käyttäen erilliseen laskentaohjelmistoon (Putkiplus) suunnittelijan skissien tai valmiin suunnitelman avulla.

Tähän tuli muutos, kun Progman Oy julkaisi ensiversion ELVIS Designer ohjelmistosta. AutoCADin päälle rakennettu ohjelmisto näytti uhkaavasti hieman perinteisiltä piirto-ohjelmilta, mutta hienoudet paljastuivat aika nopeasti. Valmistajien tuotekirjastosta voitiin esimerkiksi valita Oraksen tai Danfossin linjasäätöventtiilit ja käyttää niiden esisäätöarvoja suoraan cad-kuvassa. Ihmetys oli suuri, kun patteritehoja muutettaessa esisäätöarvot muuttuivat suoraan mittaviivaan, eikä niitä pitänyt käydä Putkiplussalla tarkistuttamassa.

Verkostojen automaattinen mitoitus oli yksi ohjelmiston myyntiargumenteista. Kohtalaisen nopeasti tuli todennettua, että matematiikka verkostojen mitoituksessa on yksinkertaista, mutta sitä ei voi jättää pelkästään tietokoneohjelman laskettavaksi. Pilke silmäkulmassa olleet puheet siitä, että ”insinööriä ei enää tarvita” realisoituivat aika nopeasti, kun nuoret suunnittelijat mitoittelivat Elviksellä verkostoja ja ihmettelivät, että miksei radiaattoriverkoston painehäviö voisi olla 450kPa?

Kantapään kautta opittiin interpoloinnin metodi – antaa ohjelmiston mitoittaa verkosto, sen jälkeen käydään se käsin korjaamassa halutun kokoiseksi ja tämän jälkeen tasapainotetaan kokonaisuus. Analysoidaan lopputulos ja tehdään tarvittavat muutokset. Metodi, joka pätee vielä tänäkin päivänä.

Verkoston automaattisen mitoituksen ja olemassa olevan verkoston tasapainotuksen ero paljastui eräässä projektissa aika nopeasti. Muutoskuviin oltiin lisätty varauksia muutamille laitteille ja piirtäjä oli käskyttänyt ohjelmistoa mitoittamaan verkosto uudelleen, kun olisi pitänyt vain tasapainottaa verkosto olemassa olevalla putkistolla. Muutoskuvat lähtivät matkaan  ja aika nopeasti tuli urakoitsijalta varmistuspyyntö siihen, että puretaanko todellakin kaikki asennetut runkoputkistot ja suurennetaan dimensiolla? Jälleen tuli todistetuksi, että suunnittelijaa tarvitaan ja uloslähtevät kuvat on tarkistettava suunnittelijan toimesta.

Elvis ja ARK sovellukset olivat toiminnassa rinta-rinnan arviolta vuoteen 1999 asti. Todettakoon sekin, että entiset Elvis –käyttäjät siirtyivät erittäin mielellään seuraavan sukupolven ohjelmistoihin – ohjelman käyttö ei ollut aina ruusuilla tanssimista.

MagiCAD ja tietomallit

Progman Oy:n kehittämän MagiCAD ohjelmiston käyttöönotto kaikissa uusissa LVI-projekteissa kävi erittäin helposti. Eräänä kauniina, aurinkoisena päivänä yhtiön johto ilmoitti, että: ”Tästä hetkestä eteenpäin kaikki LVI-suunnittelukohteet mallinnetaan MagiCADillä”. Tämä tapahtui vuonna 2001.

Sitä ennen MagiCADin ilmanvaihtosovellusta oli vuonna 1997 alkaneiden testausten jälkeen käytetty menestyksellisesti muutamissa isoissa suunnittelukohteissa vuosina 1998-2000. Usko uuteen putkipuolen sovelluksenkin oli vahva ja tiedossa oli, että sähköpuollellekin tulee vastaava tuote sillä ohjelmiston kehitys oli aloitettu yhteistyössä Progmanin kanssa vuonna 2000.

Sähkösovelluksen kehittämisestä veteraanimme toteaa: ” Useamman kerran jouduttiin Susilahden Maurin (Progman Oy:n toimitusjohtaja) kanssa palaveria pitämään ja kättä vääntämään, hänelle kun sähkömaailma oli ihan uusi aluevaltaus. Ensin piti hänet saada vakuuttuneeksi, että jotkin asiat sähkösuunnittelussa todellakin tehdään tietyllä tavalla. Ja tietysti meidänkin täytyi tuulettaa vähän ajattelumaailmaa, cad kun oli siihen asti ollut pääasiassa pelkkä tussin ja sapluunan korvannut väline. Sama tuuletus puolin ja toisin jatkuu edelleen.”

Tietomallipohjainen verkostojen suunnittelu oli tullut talotekniikkaan jäädäkseen. Todellinen, objektipohjainen 3D oli kiva lisä, mutta äänilaskelmat, painetasolaskelmat ja ohjelmiston nopeus edeltäjäänsä verrattuna edesauttoivat riskivapaata valintaa seuraaviin projekteihin.

Vuonna 2000 aloitettiin Senaatti –kiinteistöjen pääkonttorin saneeraus (Lintulahdekuja, Helsinki). Kohteen kaikki LVI verkostot mallinnettiin 3D:nä ja laskettiin matemaattisesti toimiviksi. Yhdistelmämalliakin yritettiin rakentaa, mutta tietokoneiden tehot riittivät vain IV-verkoston 3D-kuvan ulosottamiseen. IV-konehuoneesta tehtiin animaatioita sekä Still –kuvia. Kohde osoitti, että valittu tie tietomallinnuksessa oli ehdottomasti oikea.

Ulkomaan kohteista, jossa ohjelmistoa käytettiin suunnittelussa oli Hampuriin rakennettava ”Color Line Arena” - nykyaikainen monitoimihalli, jossa jääkiekko vain häiritsee bisnestä. Mallinnus valmistui vuonna 2001. Saksalaiseen tyyliin urakoitsijat yleensä piirtävät kohteen asennuspiirustukset. Projektivetäjämme tarjosivat heille useaan otteeseen tekemiämme suunnitelmia sillä perusteella, että kohde on mallinnettu kolmedimensioisena sekä sisältää laskelmat tasapainotustietoineen. Lisäksi verkostot ovat riittävällä tarkkuudella oikeissa paikoissa

Kohde rakennettiin suunnitelmillamme ilman suuria ihmeellisyyksiä. Vastaanottovaiheessa todettiin eräässä iv-koneverkostossa ääniongelmaa, jonka lähteenä urakoitsija ilmoitti olevan raskaat palopellit. Omissa laskennoissa totesimme äänilähteen olevan perinteisesti IV-kone ja sillä liian pienet äänenvaimentimet.

Pystyimme todistamaan tämän äänikaistakohtaisella laskelmalla, jossa MagiCAD siis laskee jokaisen komponentin verkoston varrelta ja antaa niille kaistakohtaiset desibeliarvot. Tuloste on isoissa verkostoissa tietenkin aika pitkä, joten editoimme sen lukukelpoiseen muotoon, jossa jätimme vain merkittävät komponentit listalle.

Saksalaiset tyrmäsivät laskelman todeten, että se ei voi pitää paikkaansa. Päätimme siis laittaa koko laskelman menemään (tulostettuna arviolta 50kpl A4 sivua pelkkää numeroa). Lopputuloksena saimme vastauksen: ”OK, äänilähde on IV-kone”.

Kun sähkösovelluskin saatiin vuonna 2002 virallisesti käyttöön, voitiin omin silmin nähdä, että myös kaapelihyllyyn voidaan tehdä 45 asteen mutkia. Aina ei tarvitse iv-kanavalla niitä väistää.

MagiCADin huomattavasti edistyksellisempi käyttölogiikka ja laskentojen nopeus olivat ammattilaisen käsissä loistava työpari.

Kun harjoittelukohteet oli tehty heräsivät muutamat rakennuttajatkin osaten kysyä jo suunnittelupyynnössä tuotemallipohjaisen suunnittelun lisähintaa (”tietomalli” –sanaa ei oltu vielä tuolloin keksitty). Käytännössä lisähintaa ei ollut, tuotemallipohjaisuus ja 3D kuuluivat normaaliin suunnittelukäytäntöön.

Valitettavasti nykyäänkään ei käytetä vielä kaikkia MagiCADin mahdollistamia asioita hyödyksi työmaaolosuhteissa. Suunnittelijalla olisi mahdollisuus tehdä säätöpiirustukset todellisilla tuotetiedoilla, jos vain saisimme kaikkien komponenttien mitoitustekniset tiedot urakoitsijalta. Tai mikä estäisi urakoitsijaa itse tekemästä ko. malleja, eli jatkaa suunnitelmamallista työmaan toteutusmallin tekemiseen?

Vuonna 2010 kaikki osastot käyttävät tietomallipohjaisia suunnittelutyökaluja normaalissa cad-työskentelyssä. LVI, sprinkler, sähkö, rakennusautomaatio ja kiinteiden sairaalalaitteiden objektit voidaan siirtää IFC tiedostojen kautta järjestelmistä toisiin.

Yhdistelmämallit

3D suunnittelun yleistyessä tuli nopeasti selvä tarve saada verkostot visuaalista tarkastelua varten saman tiedoston sisälle. 3D-pelit olivat valloittaneet maailman ja jo vuodesta 1993 oltiin nähty uusien pelimoottorien tulo esim. peleissä Doom ja Quake. Vuoden 2003 aikoihin pelimaailma oli valovuoden rakennusteollisuuden CAD-maailmaa edellä – ainakin arkkitehtuurin ja talotekniikan puolella.

Suomalaisen menestyksekkään - kannuksensa jo hankkineen -  pelitalon edustaja sanoi eräässä seminaarissa 2000 luvun alussa suurin piirtein näin: ”Te rakennusalalla käytätte ohjelmistoja jotka ovat 1980 luvulta. Ne ovat hitaita ja epästabiileja. Jos me tehtäisiin CAD softa, se olisi sata… TUHAT kertaa nopeampi kun nykyiset”.

Ketään seminaariyleisöstä ei naureskellut uholle – oletettavasti kaikki tiesivät kaverin puheen pitävän paikkansa.

Erilaisia ohjelmistoja ja formaatteja tutkittiin, mutta mitään täysin sopivaa ei löytynyt. Maailmaa ei vielä 1990 luvun lopussa kiinnostanut rakennusteollisuuden kapean sektorin 3D-mallinnusta tekevät yhtiöt. Kuului jopa puhetta, että 3D tulee kuolemaan nopeasti – sitä ei tarvita.

Solibri oli julkaissut jo aiemmin IFC tiedostojen tarkastukseen soveltuvan ohjelmiston, jolla voitiin yhdistää IFC-mallit toisiinsa. Ohjelmisto ei ollut kuitenkaan vielä sovelias normaalin mallintajan työkaluksi.

Laboratorio-olosuhteissa voitiin rakennella virtuaalimalleja joita tutkittiin mm. Cave –ympäristöissä 3D-lasit päässä, mutta wow –efekti kesti lähinnä yhden kohteen tarkastelun, toisen ja kolmannen kohteen edessä tuli tunne, että tämä on jo nähty. Suoranaiseen verkostojen suunnitteluun, normaalin suunnittelun avustukseen näistä työkaluista ei vielä ollut.

Noin vuonna 2004 T&K osasto löysi kontaktiensa avulla firman nimeltä ”Navisworks” ja heidän tuotettansa testailtiin oman aikansa. Ohjelma oli lähellä sitä, mitä haettiin, mutta jotain kuitenkin puuttui. Meni vielä vuoden verran, kunnes Navisworks julkaisi uuden version ohjelmasta ja sitä testattiin mm. Helsinkiin Eläinsairaalan ja Aurora 2 -projekteissa menestyksellisesti. Näissä malleissa oli yhdistettynä ensimmäistä kertaa LVIS-tekniikka, näimme itsekin rakennusmallimme kokonaisuudessaan 3D:nä

Toinen samoihin aikoihin Navisworksia vahvasti käyttänyt projekti oli Malmö Arena - jälleen yksi monitoimiarena  tällä kertaa tehtynä Ruotsiin. Tässäkin kohteessa oli LVIS -tekniikka mallinnettuna kokonaisuudessaan. Betoniset katsomorakenteet saatiin Ruotsista rakennusurakoitsijalta ja teräksiset kattorakenteet saatiin Ruukilta Teklalla mallinnettuna.

Yllämainittujen ja muutamien muiden kohteiden perusteella tehtiin strateginen valinta. Navisworks tulee olemaan MagiCADin rinnalla toimiva työkalu, josta mallinnuksen yhteydessä tarkastellaan jatkuvasti kokonaisuuden rakentumista.

Tuota asiaa voisi joku Teklaa käyttävä rakennesuunnittelija pitää itsestään selvyytenä (eli että kokonaisuus on näkyvillä CAD-suunnittelussa), mutta meille, AutoCAD alustoilla työskenteleville se oli uutta. Sellaista tietokonetta ei saa edes rahalla, joka pyörittäisi AutoCADin päällä monitoimiarenan kaikkia suunnittelualoja.

Kun oltiin tehty päätös Navisworksin hankinnasta ja laitettu lisälisenssit tilaukseen (ohjelmaa teki silloin itsenäinen, pieni englantilainen ohjelmistotalo) kuultiin muutaman viikon päästä maailman CAD-markkinoilta uutisia. Autodesk oli ostanut Navisworksin. Asian kuuleminen ei tuonut välttämättä positiivisia reaktioita käyttäjien keskuudessa.

Vuonna 2010 käytössä on täydessä sovussa keskenään toimivat Solibri Model Checker ja Navisworks Review. Molemmille on löytynyt selvä paikka tietomallipohjaisessa suunnittelussa.

CAD suunnittelun tulevaisuus

Tulevaisuuteen on vaikea katsoa. Lienee kuitenkin selviö, että suunnitelmista tullaan saamaan entistä enemmän informaatiota rakentamista ja ylläpitoa ajatellen. Nykysysteemeinkin informaation ulosotto on mahdollista, mutta ei vielä sillä tasolla että se olisi arkipäivää ja jokaisen käyttäjän hallittavissa.

Suunnittelija tulee tarjoamaan entistä tarkempia ja täydellisempiä tietokantoja työmaan käyttöön, esim. laitehyväksyntiin ja vastaanottoihin. Urakoitsijat ovat suorassa yhteydessä rakennuksen laiteluettelokantaan ja keräävät sieltä itse informaatiota kilpailuttaakseen tuotteita.

Urakoitsijoiden ja rakennuttajakonsulttien ammattitaito kasvaa tietomallien tullessa yksinkertaisemmin hyödynnettäviksi.

Työmaalle tulee syntymään uusi ammattiryhmä, tietomalliasiantuntijat. Urakoitsijat tulevat huomaamaan, että malleissa on paljon sellaista informaatiota joka helpottaa heitän työtään. He alkavat itse kaivaa tätä informaatiota tietomalleista. He alkavat myös päivittää mallia omia tarpeita varten, esimerkiksi suorakaidekanavien asennuskuvien ja kannakointien tekemiseksi.

Virtuaalimaailmat tulevat takaisin kunhan tekniikka kehittyy vielä hieman pidemmälle. Nyt surffaillaan yhdistelmämallissa monitorin ruudulla, jatkossa lasien kanssa. Ei ketään jaksa vaivautua mihinkään erikoisvarusteltuun koppiin – virtuaalilasit päähän ja olet omalta työpisteeltäsi mallin sisällä.

Tietomallin editointi onnistunee tässä virtuaaliympäristössä paremmin kuin nykyisin. Ja voihan siellä nähdä toisenkin suunnittelijan tekemässä omia töitään… toivottavasti he eivät tuota paljoa melua, sillä IV-suunnittelija voi olla tarkastuskierroksella mittamaassa äänitasoja eri tiloissa.

Valmiit 3D verkostomallit heijastettaneen työmaalla esim. käytäväalueelle hologrammeiksi. Tämän perusteella verkostojen asennus luulisi helpottuvan – tai ainakin näkee heti, jos on asentamassa toisen suunnittelualan verkostojen eteen omia putkiaan.

Suunnitteluympäristöjen kehityksessä on edessä mielenkiintoinen käänne menneisyyteen. Keskusjärjestelmät tulevat takaisin. Jokaiselle mallintajalle ei enää hankita tehotyöasemia, vaan koneiden laskentatehot keskitetään ja hallinnoidaan kootusti serverihuoneen sisällä. Kapasiteettiä on tällöin tarjolla enemmän kuin yhtäaikaisten käyttäjien työasemissa yhteensä. Mallintajalla on käytössä kevyempi PC, joka vastaa ominaisuuksiltaan normaalin nettisurfailun vaatimia tarpeita.

On aivan sama, mitä tulevaisuudessa keksitään. Granlund tulee olemaan sen kehityksen kärjessä sillä olemme tottuneet tekemään itse oman tulevaisuutemme.

---

Mistä löysin tämän kirjoituksen...? Ajattelimme "Innovaatiot ja Kehitys" osastolla tehdä 

historiikki siitä, mitä ollaan tehty vuosien saatossa. Olin jo unohtanut ym. tekstin, mutta kun kaivelin arkistojani, sieltähän se esiin putkahti ... ajattelin, että julkaisemisen arvoinen kirjoitus, joka ei ole aiemmin päivänvaloa nähnyt.

---
Vuoden kuva

30v  sitten tehty CAD strategia, á la Eino Kukkonen:

Matkaraportti, Sveitsi 2016

Kävin kääntymässä talotekniikkasuunnittelun yhteistyökumppanin luona Sveitsissä, jälleen kerran.

Sveitsissä tapahtuu BIMin osalta todella paljon ja nopeasti. Heidän Bauen Digital (http://www.bauen-digital.ch/de) -organisaatio (joka perustettiin about vuosi sitten) kattaa suurinpiirtein kaikki alan ammattilaiset suunnittelijoista urakoitsijoihin. Osa tilaajistakin on erehtynyt mukaan.

Bauen Digitalissa memberinä on mm. buildingSMART Switzerland

«BIM Evolution oder Revolution?» kyselee sivusto. Sanoisin, että Sveitsissä se on on Revolution.

Omalla työpaikalla on ravannut sveitsi-professoreja delegaatioineen kohtalaisen usein. Tiedonjano on valtava, imuohjaus taitaa toimia.

Sveitsissäkin Revit=BIM. Heillä on ollut käytössä muita softia MEP puolella (Plancal) mutta nyt ne kuulemma päivittyvät "uuteen maailmaan". Arkkitehdeiltä on kuulemma vaihtumassa piirtosoftat Revittiin. Jotenkin jää huono maku suuhun, kun IFC:n edut häviävät markkinakoneiston rattaisiin. Toisaalta, Sveitsi elää BIM huumassa, he eivät ole vielä hahmottaneet "todellisen" bim-yhteistyön merkitystä.

Rakennesuunnittelusta en saanut tartuntapintaa. MEP toimisto sanoo, että he näkevät vain arkkitehtimalleja. Jossain ne rakennemallitkin on oltava, eli en tiedä, onko siellä käytössä Tekla vai ei?

Sveitsiläiset panostavat vahvasti alkupään suunnitteluun. Heille luonnosvaihe on todella tärkeä. Yhteistyökumppanimme tekee tilapohjaista mep-mitoitusta / vaatimusmäärittelyä kuten isossa maailmassa tehdään. Energiasimuloinnit tehdään itse mallinnetulla geometriamallilla.

Suunnitteluryhmä on tottunut integroitumaan - oma käsitys on, että he integroituvat "normaalin" suunnittelumetodiikan kautta, eivät bim-tiedonvaihdon kautta. Sveitsissä suunnittelu suunnitellaan suunnitteluorganisaation sisällä, post-it lappuja seinät täynnä. Mitä tietoa tarvitsen, mitä tietoa toimitan eteenpäin? Mikä vaihe pitää olla tehtynä ennen kuin voin aloittaa seuraavan?

Suunnittelun ohjausorganisaatio ei häiritse ammattilaisten työtä, ainakaan "hyvissä" kohteissa - ei kaikissa. Olen kateellinen, sillä suomalainen suunnitteluorganisaatio ei osaa enää itseorganisoitua ilman rakennuttajakonsultin pakotusta. Vielä 1990 luvun alussa arkkitehti veti projektit ja yhteistyö oli saumatonta. Laman seurauksena tilaajaorganisaation henkilöstö väheni radikaalisti. Tämä ammattilaisten kaventaminen synnytti rakennuttajakonsulttien ammattiryhmän ja yhteistyö sekä rakennuttamisen kustannukset vähenivät Windows. 3.0 Excelissä (jota juuri ja juuri osattiin käyttää...)..

Yleistäminen lienee minulla pieni ongelma - eivät he Sveitsissä aina toimi yhteistyössä, kuten ei se aina ole Suomessakaan työtapana..

Sveitsissä suunnittelijat mallintavat, urakoitsijat eivät vielä käytä malleja. Suunnittelijat tekevät omia mallejaan, integroituvat hieman alkeellisemmin kuin pohjoismaissa. Kun tuo integroituminen tuollakin alkaa tapahtua, alkaa IFC:nkin merkitys nousta. Tai toisaalta, jos kaikila on Revit, niin mitäs siitä IFC:stä sitten...

MEP suunnittelija toimii melkein kuten Saksassa, tekee mm. käsittämättömän nivaskan paperia (Deviauszug) jossa jokaisen komponentin perässä on tieto määrästä + tyhjä viiva, jonne urakoitsija antaa sen osan hinnan. Viimeisellä sivulla sitten on yhteenvedossa tyhjä rivi, jonne urakoitsija voi laittaa kokonaishinnan. (jotenkin tulee mieleen Berliinin lentokenttä ja "paras hinta on alin hinta" logiikka...)

Jos hinta on oikealla planeetalla, niin urakoitsija voi saada jopa piirustukset nähtäväksi. Ei pysty skandinaavi ymmärtämään logiikkaa...

Yleisesti:
Sveitsissä on käynnissä sama hype kuin oli Englannissa ~4 vuotta sitten. Jos he menevät samalla nopeudella eteenpäin, niin kohta heistä tulee uusi bim-tähti maailmankartalle.

Osaamista, rahaa, kunnianhimoa ja pikkutarkkuutta heiltä löytyy.

Viikon kuva:

Slides about MEP BIM Design

My first upload to Slideshare:

http://www.slideshare.net/TeroJrvinen/mep-bim-design

Slides are from seminar, where I was speaking about MEP Design and processes

Picture of the Week:

BIM vuonna 2013

Minua haastateltiin NSS:n toimesta Plaani -lehteen muutamia viikoja sitten.

Taustana on projekti:
http://www.skolry.fi/tiedotteet/skol-kehitt%C3%A4%C3%A4-talotekniikkasuunnittelun-tietomalliprosesseja

Kun prosessikuvaukset ovat virallisesti julkaisu- / kommentointikelpoisia, laitan linkkiä tänne blogiin.

Lopputulos varmaankin ilmestyy Plaani 2013/4 lehdessä, lisätietoa täältä:
http://nssoy.fi/index.php/plaani

Omalta osalta homma lähti lapasesta, eli kirjoittelin ummet ja lammet toimittajalle. Koko juttu ei voi millään mahtua itse lehteen, mutta tänne blogiinhan se mahtuu... eli alla vastaukseni toimittajan kysymyksiin:

---

                                                                                                                                                            14.10.13                                                                                                                                                  Plaani 4/13

SKOL:n talotekniikkasuunnittelun tietomalliprosessien kehityshanke

Tietomallipäällikkö Tero Järvinen, Granlund Oy

Hankkeen tausta ja tavoitteet?  

• Vuosina 2011-12 päivitettiin Senaatin vuonna 2007 julkaisut tietomallisuunnittelun   vaatimukset ja julkaistiin Yleiset tietomallivaatimukset 2012. SKOL suunnitteli jo tuolloin suunnitteluprosessien kehittämistä edistävää projektia.  Miten nyt valmistuva hanke eroaa  YTV:n ohjeista ja siinä kuvatusta tietomallintamisen suunnitteluprosessista?

Nyt tehtävät ohjeet menevät tarkemmalle, tekniselle tasolle kuin YTV:ssä pystytään menemään. Koska SKOLin prosessikuvauksissa voidaan valita muutamia haasteellisiksi havaittuja prosesseja, niin pystymme rajaamaan näkökulmaa paremmin

• Miten hanke on edennyt ja keitä mukana?

Hanke etenee alkuvuonna asetetussa aikataulussa. Toimimme siten, että minä teen alustavan rungon prosessikuvauksesta ja sitten käymme sen työpajatyyppisesti läpi muiden suunnittelutoimistojen edustajien kanssa. Näin mahdollistamme sen, että näkemys ei jää yhden osapuolen toimintatavoista riippuvaiseksi.

Mukana työpajoissa on ollut henkilöitä suurimmista suomalaisista taloteknisistä suunnittelutoimistoista, mm. Pöyryltä, Wise Groupilta, AX-Suunnittelusta, Hepaconilta, Lausamolta, Maaskolalta, Äyräväiseltä ja Talokeskukselta. Ja tietenkin meiltä, eli Granlundilta.

• Millaisia käytännön ongelmia projektin tavoitteissa mainituista perinteisestä               suunnitteluprosessista ja tiedonvaihtoaikataulusta on aiheutunut?

Tietomallipohjainen suunnittelu on siinä mielessä hieno juttu, että se laittaa suunnittelijat oikeasti ajattelemaan. Jotta asioita voidaan mallintaa fiksusti, tulee asioita ensiksi suunnitella ja aikatauluttaa. Tietomallipohjainen suunnittelu palauttaa siis meidän suunnittelijat ajassa taaksepäin ja tuo yhteistyön ja suunnitelmallisuuden takaisin.

Liian usein ”perinteiset” suunnittelumetodit ajavat siihen, että suunnittelijoiden välillä ei saada käyttää omaa kaupunkilaisjärkeä vaan tehdään sitä mitä on tilattu – vain omasta näkökulmasta katsoen. Valitettavasti perinteiset sopimusmallit ohjaavat tähän tilanteeseen, sillä vaikka esim. sähkösuunnittelijan olisi järkevää mallintaa reikävaraukset mallipohjaisesti jotta rakennesuunnittelijan päässä olisi reikävaraushallinta yksinkertaisempaa, niin sitä ei tehdä koska sitä ei ole tilattu. Ei pystytä eikä haluta katsoa kokonaisuutta, koska osaoptimoidaan omaa suoritusta .

• Mitä tarkoittaa se, että suunnitteluprosessi muutetaan ”Lean Construction” -periaatteita   noudattavaksi?

Olen puolileikilläni sanonut, että Lean Construction tarkoittaa puiden halailemista. Käytännössä Lean Construction minun ajatuksissani tarkoittaa yhteistoiminnallista suunnittelutapaa, niiden töiden tekemistä, joista asiakas on valmis maksamaan ja josta he hyötyvät. Helpoin vastaus Lean –ajatteluun on ”hukan minimointi”, mutta tuo on mielestäni lähinnä seuraus siitä, kun toimitaan siten että kunnioitetaan toisen ihmisen työntekoa ja tehdään itse se, mitä on luvattu tehdä.

Tavoite?
Tarkoituksena luoda:

• Ohjeellinen kaikkia suunnittelualoja koskeva suunnitteluprosessin kuvaus
• Kaikkien suunnittelualojen välinen tiedonvaihtoaikataulu

• Projekti on loppusuoralla, toteutuvatko tavoitteet?

Asiasisältö saadaan kerättyä ja kirjoitettua, mutta olisin toivonut enemmän visuaalisempaa lopputulosta. Nythän prosessikuvaus on insinöörimäisen jämäkästi tehty numeroituna työlistana joka on raskasta luettavaa.

Toivon, että ohjeistus saataisiin sellaiseen muotoon, että nopealla silmäyksellä saataisiin kokonaiskuva siitä, mitä ollaan tekemässä ja sitten sen jälkeen tarvittaessa siirrytään lukemaan tekstiosuutta. Kateellisena katselen esim. arkkitehtien kykyä tehdä graafisia ”sarjakuvia” vaikeistakin asioista.

• Tässä kehitetään TATE-lähtöisesti, ovatko muut (esim. ARK ja RAK) suunnittelualat   tunnistaneet samat ongelmakohdat kuin tässä esitetyt?

Alakattosuunnittelun osuus on alustavasti tarkastettu muutamien arkkitehtien toimesta ja kokonaispalaute on ollut hyvää. Toisaalta, palautetta tuli laidasta laitaan tyyliin: ”Kokemuksesta tiedän, että tämä kuvaus ei tule yleistymään” ja ” Kaikki mitä kirjoitat on täyttä asiaa. 2d-leikkauksella on lähdettävä.”

Kun ollaan muuttamassa nykyistä käytäntöä – tai tuomassa vanhaa tapaa takaisin – niin mielipiteet jakautuvat puolesta ja vastaan. Suurin osa kuitenkin oli sitä mieltä, että ohjeet ovat hyvät ja niitä voidaan noudattaa.

Rakennesuunnittelijoiden kanssa kävin myös reikäkuvaprosessin läpi (Finnmap, Rambol, A-Insinöörit). Ohje oli lähes sellaisenaan toimiva, olimme jo aikaisemmin eri kehityshankkeissa ja projekteissa rakennesuunnittelijoiden kanssa asiaa hioneet. Elementtisuunnittelun haasteet nousivat nyt konkreettisemmin esille ja ne jouduimme ohittamaan tässä hankkeessa.

Rakennesuunnittelijoilla on ymmärrettävä vaatimus – he haluavat kaiken reikävaraustiedon mallipohjaisena. Valitettavasti talotekniikan ohjelmistot eivät tähän vielä taivu ja ei voi olettaa, että talotekninen suunnittelija ottaisi normaalitapauksessa  käyttöön esim. Tekla Structures –ohjelmiston jolla tämä työ olisi mahdollista teknisesti suorittaa.

• Pitäisikö kartoittaa myös toisten suunnittelualojen omat kipupisteet, jotka puolestaan           voisivat vaikuttaa koko rakentamisprosessiin?

Kyllä, se olisi erinomainen asia. Nyt on pintapuolisesti kyselty valmiin materiaalin kanssa arkkitehdeiltä ja rakennesuunnittelijoilta siitä, että soveltuuko tämä ohje heidän mielestä suunnitteluun. Ohjeessa on kuitenkin vaatimuksia kaikille osapuolille, eli jotta ohjeen vaatimukset voidaan toteuttaa, jokaisen osapuolen on sitä noudateltava.             

• Prosessikuvaukset on tehty origon asettamisesta, alakattosuunnittelusta ja -mallinnuksesta   sekä TATE-reikävarausten tekemisestä. Miksi juuri nämä valittiin?

Nämä aiheet tulivat hankkeeseen perustetun työryhmän kautta. Valitsimme yhteisesti noin kymmenen eri aihetta, jotka ovat aiheuttaneet ylimääräistä, turhaa työtä hankkeissamme ja sieltä äänestettiin nämä kolme vaihtoehtoa ensimmäiseksi askeleeksi tässä prosessikehityshankkeessa.

• Mitkä ovat oleellisimmat prosessinkulun muutokset TATE-suunnittelijan kannalta?

Oleellisin asia on yhteistyön korostaminen. TATE on riippuvainen muiden suunnittelualojen etenemisestä. Näillä prosessiohjeilla tuodaan takaisin myös töiden vaiheistus Jotta voidaan tehdä jokin asia, tulee ympäristö työn tekemiseksi olla jo suunniteltu riittävällä tasolla.

Lisäksi ohjeet toimivat muistilistana TATE-suunnittelijalle. Liian usein TATE ei tee jotain työosuutta, vaan odottaa ”täydellistä” ympäristöä tai lähtötietoa muilta suunnittleijoilta. Suunnittelu on iteratiivinen prosessi, kaikkien tulee tehdä iteraatioita oikeassa järjestyksessä ja vaiheessa.

• Eikö origon asettamiselle ole ollut ohjeita aikaisemmin? Miten mallit voidaan yleensä           sovittaa yhteen ilman yhteistä origoa? 

Tämä on yksi surkuhupaisimmista asioista mitä tiedän. Origon sijoitus on ollut liian monessa projektissa hukassa jo 1990 luvulta lähtien. Yli kaksikymmentä vuotta sitten on keksitty, miten tämä asia tulee hoitaa, mutta jostain käsittämättömästä syystä edelleenkin lähes kuukausittain meille tulee projekteja, joissa origon asettamisessa ollaan epäonnistuttu.

Asian ratkaisu on erittäin yksinkertainen mutta vaatii toisen osapuolen mallintamisen ymmärrystä ja aivan normaalia keskustelua mallintajien kanssa. Ehkäpä tässä ollaan epäonnistuttu siksi, että ei tehdä suunnittelutiimin kanssa yhteistyötä riittävällä tasolla?

• Alakattojen osalta yleissuunnitteluvaiheessa arkkitehti ja TATE-suunnittelija tekee 2D-leikkauksia valituista paikoista? Miksi ei tehdä heti mallintamalla, eikö 2D ole paluuta vanhaan suunnittelutapaan?

Tämä on yksi asia, jota yritän korostaa. Ensiksi suunnitellaan, sitten mallinnetaan.

TATE-puolella esim. käytäväleikkauksessa kulkee useiden eri suunnittelualojen verkostoja. Jotenkin nämä verkostot on koordinoitava siten, että ne pystytään mallintamaan 3-6 eri henkilön toimesta graafiseen tietomalliin. Tämän ajatustyön apuna on perinteinen 2D-leikkaus. Kun siinä on asia suunniteltu, niin voidaan siirtyä seuraavaan vaiheeseen, esim. saman asian mallintamiseen. Nämä eivät ole toisiansa poissulkevia työtehtäviä. Pitää hyväksyä se tosiasia, että ei ole olemassa tietomallipohjaista suunnittelua – on vain suunnittelua.

• Reikävaraukset: Kuinka yleistä on, että esim. urakoitsija muuttaa rakennuksen runkoratkaisun

Ei se kokemukseni mukaan mikään normaali tilanne ole, mutta kun tuo tapahtuu, niin TATE-verkostojen graafinen mallinnus voidaan heittää roskikseen. Tai painaa deleteä tiedostoille.

Tätä asiaa ei mielestäni ymmärretä riittävästi, kun tehdään valinta euron halvemmasta runkoratkaisusta. Tuo tilanne on katastrofi TATE-suunnittelijalle ja yleensä rakennesuunnittelijallekin. Tilaajan pitäisi heti näin toimittaessa selvittä aikatauluvaikutus sekä kokonaiskustannusten nousuvaikutus.

Tosiasia on se, että jo valmiiksi mallinnettuja TATE-verkostoja ei tuosta vaan soviteta uuteen rakennusrunkoon, vaan yleensä fiksuinta on mallintaa verkostot uudelleen. Eli ei ole hyvää vaihtoehtoa tarjolla, kun runko muutetaan.

• Miksi valittiin reikien kooksi tuo 150 mm, kun kuitenkin todetaan, että olisi                           kokonaistaloudellisempaa tehdä myös pienempien reikien mallinnukset suunnittelijan             toimesta?   

Tuossa on historian havinaa mukana. Joku koko pitää olla sanottuna, jotta voidaan tarjota järkevällä työmäärällä kiinteähintaisia suunnittelutarjouksia.

On monia asioita, joissa voitaisiin toteuttaa kokonaistaloudellisempaa suunnittelua, eli suunnittelija pystyisi tuottamaan lisätyöllä sellaista tietoa / materiaalia, joka helpottaa urakoitsijan työtä. Tätä ei kuitenkaan tehdä, koska tästä lisätyöstä ei olla valmiita maksamaan  - siis suunnittelijalle. Kokonaiskustannushan laskisi.

• Prosessikuvauksessa erikseen mainitaan, että reikävaraussuunnittelun 2D-piirustusten           tekovelvollisuus on rakennesuunnittelijalla, onko tästä ollut epäselvyyttä?

On, sillä perinteisesti 2D-piirustukset on tehnyt TATE-suunnittelija. Tuo on puhdasta työtä, eli tuolle pitää olla varattuna suunnittelijan toimesta joku työmäärä, eli rahasumma. Rakennesuunnittelijalla on parempi ammattitaito ja tietämys siitä, mistä kohtaa rakennusta vedetään mittaviiva, mitä tietoja tarvitaan jne. 

Työmäärähän ei kokonaisuutta ajatellen kasva, vaan se siirtyy eri suunnittelualalta toiselle, joka osaa tehdä työn paremmin. Ja tämä siirtynyt työ tulee pystyä hinnoittelemaan tarjousvaiheessa.

• Reikävarausten kohdalla on otettu esiin peruskorjauskohteet. Onko joku                           peruskorjauskohteiden työtapavaihtoehdoista (1-4) erityisen tyypillinen?

Oman näkemyksen mukaan tilanne 3 on tyypillisin, eli on käytössä arkkitehtimalli, mutta ei koko rakennuksen kattavaa rakennemallia. Mutta kaikkia vaihtoehtoja on olemassa ja se aiheuttaa haasteen peruskorjauskohteiden suunnittelussa.

Mielestäni vaihtoehto 1 olisi TATE:lle paras, eli rakennemalli mallinnettu vanhojen piirustusten mukaisesti ja sen lisäksi kaikilla osapuolilla ymmärrys siitä, että aivan varmasti matkan varrella tulee yllätyksiä niistä asioista, joita ei ole vanhoista piirustuksista löytynyt.

Kun toimitaan tämän mukaisesti, kannattaa pistokoemaisesti tarkistaa todellisen rakennuksen ja vanhojen rakennepiirustusten yhteensopivuus ennen mallinnuksen aloittamista.

• Kuinka hyvin tietomallinnus yleisesti sopii mielestäsi peruskorjauskohteisiin?

Sopii aivan hyvin, kun ymmärretään se tosiasia, että täydellistä, virtuaalista mallia rakennuksesta on nykytekniikalla lähestulkoon mahdoton tehdä suunnittelijan käyttöön. Pitää hyväksyä todellisuuden ja virtuaalitodellisuuden rajat.

Nyt joku sanoo, että skannaamalla saadaan pistepilvet käyttöön ja siten parin millin tarkkuuteen. Heille sanoisin, että tervetuloa hommiin, kun käytetään pistepilviä TATE-mallinnuksen lähtökohtana koko rakennuksen alueella. Mallihuoneet tms. pikkualueet tai maanalaiset luolat ovat eri juttu pistepilvien suhteen.

Projektin valmistuminen

• Aikataulu ja mistä löytää?

Vuoden 2013 lopulla pitäisi olla julkaistuna. Se mistä löytää, ei ole ihan vielä käsittääkseni sovittu, mutta ainakin nyt taustatietoa löytyy SKOL Ry:n sivuilta :
http://www.skolry.fi/tiedotteet/skol-kehitt%C3%A4%C3%A4-talotekniikkasuunnittelun-tietomalliprosesseja

• Miten hankkeen tulokset saadaan eri suunnittelualoilla käyttöön (muillekin kuin SKOL:n       jäsentoimistoille)?
• Viettekö ohjeet myös aktiivisesti tilaajien tietoon, vaikuttaa kuitenkin koko projektin             aikatauluun ja läpivientiin?

Toivon, että ohjeet ovat netistä vapaasti ladattavissa kaikkien käyttöön. Asiasta ei ole tehty tarkkaa suunnitelmaa, ainakaan minun toimesta. Tilaajille toivon tiedon kulkevan ensi alkuun lehdistön ja TATE-suunnittelutoimistojen kautta.

Lisäksi on ollut puhetta BuildingSMART Finlandin kanssa, että ohjeet voisivat tulla myös heidän kautta levitykseen.

Asian ratkaiseminen on vielä kesken, mutta tuskin nämä miksikään salaseuran sisäiseksi ohjeeksi jäävät – ne ovat tarkoitettu käyttöön jo silloin, kun annetaan suunnittelutarjousta kohteesta. Tilaaja voi viitata prosessikuvauksiin ja vaatia niiden noudattamista jos toteaa ne kohteeseensa sopiviksi. Näin kaikki tarjoajat ovat samalla viivalla ja tietävät, mitä heiltä odotetaan.

• Prosessinkuvauksissa oli mainittu paljon tapaamisia eri suunnittelualojen suunnittelijoiden   kesken. Suunnittelijat sanovat, että erilaisia palavereja on nykyisin todella paljon. Jos           noudatetaan näitä ohjeita, onko vaikutusta suunnittelukokouksien määrään?

Sana ”Suunnittleukokous” tulisi määritellä tarkemmin. On liian paljon suunnittelukokouksia, joissa TATE-suunnittelija istuu kaksi tuntia ja pääsee kerran ääneen, kun kysytään suunnitteluasioita. Vastaus on yleensä, ”Ei kokousasioita”. Tuossa ei ole mitään järkeä – byrokratiaa tuntuu olevan liikaa.

Välillä on tuntunut, että suunnittelukokouksissa ei saa puhua suunnitteluasioista ja työmaakokouksissa ei saa puhua työmaan asioista.

Prosessikuvauksissa esitetyt kokoukset voivat olla myös etäpalavereja. Ajatus on kuitenkin se, että pidetään työpaja teknisistä asioista. Ei ole tarkoitus katsoa ”suurta kuvaa”, vaan keskitytään pienemmän mittakaavan asioihin, joiden me tiedämme aiheuttavan isoja ongelmia, jos niitä ei yhteistoiminnallisesti ratkaista. Esim. alakattosuunnittelua ei voi tehdä vain yksi osapuoli projektissa. Se vaatii usean ammattilaisen panostusta, jotta se voidaan suorittaa teknisesti toimivana

Yleisesti tietomallintamisesta

• Jossain vaiheessa sanottiin, että Suomi on kärjessä tietomallintamisen käytössä. Mikä on       tilanne mielestäsi nyt?

Oma tuntuma on se, että meillä tietomallinnus on konkretisoitunut normaaliksi tavaksi tehdä suunnitelmia. Minun näkemyksen mukaan Norjalaiset ovat meitä edellä, siellä on paljon kehityshankkeita ja eteenpäin vievää voimaa. Englantilaiset ovat kuulemma edenneet todella nopeasti, kun hallitus määräsi mallinnuksen käyttöönotettavaksi. Kiinassa tapahtuu vaikka mitä, sitä aluetta en tunne mutta ilmiselvästi siellä on kuhinaa asian ympärillä. Lähellä Suomalaista tapaa tehdä asioita on ehkä Hollanti.

Mielestäni olemme kuitenkin edelleen kärkikolmikossa kun katsotaan kokonaiskuvaa. Olemme ohittaneet hype –vaiheen ja tilanne on normalisoitunut siinä määrin, että kaikki – sekä suunnittelijat, tilaajat ja urakoitsijat – ovat jo omat karikkonsa käyneet lävitse ja nyt osataan ottaa oppia vanhoista virheistä.

Me emme usko asioita, ennen kuin olemme tehneet ne pari kertaa väärin. Väittäisin, että muut eivät ole kaikkialla vielä samalla tasolla kokemuksen suhteen.

• Onko ohjelmistokehitys pysynyt tietomalliprosessin kehittämishankkeiden mukana?

On pysynyt, välillä he ovat joillakin alueilla edellä ja jollakin toisella alueella jäljessä. Ohjelmistokehittäjäthän katsovat markkinatilannetta. Jos softaa myydään Kiinaan, niin tehdään sinne soveltuvia ominaisuuksia. Skandinavia on niin pieni markkina-alue jenkkien isoille firmoille, että lienee ihan sama, mitä me täällä huudamme. Esim. IFC ei ole heille ollenkaan tärkeä asia, kaikillahan voi olla saman softafirman tuotteet.

Onneksi meillä Suomessa tilanne on toinen – OpenBIM lyö itseään läpi ja tietomallisuunnittelussa toimivimmat ohjelmistot tehdään Suomessa.

• Onko yhteensopivuus eri suunnittelualojen ohjelmistojen kesken parantunut (joskus               sanottiin, että oli ongelmia)?

Aina tilanne parantuu, kunnes tulee joku toinen asia mikä ei toimi. Omaa elämääni helpotti sen ymmärtäminen, että softa ei ole koskaan valmis. Se on aina puutteellinen käyttäjän mielestä.

Mikään softa ei ole täydellinen, koska käyttäjä kehittyy jatkuvasti vaativammaksi. Tietomallisoftia on pystyttävä käyttämään niiden äärirajoilla, jotta niistä saadaan kaikki teho irti. Tämä aiheuttaa sen, että käyttäjä asettaa koko ajan vaativampia ja vaativampia tavoitteita työnsä tekemiselle.

Tuolla on suora vaikutus softan toimintaan. Kun softafirma implementoi jonkun uuden ominaisuuden, voi olla, että sitä ei käytetä ensimmäiseen kahteen vuoteen, koska sen käyttö toisi uusia suunnitteluprosesseja. Mutta sitten kun uutta ominaisuutta käytetään, niin käyttäjä löytää siitä heti 10 ongelmaa – ja syynä on vain se, että softan tekijä ei ole suunnittelun ammattilainen. Palautteen merkitys on erittäin suuri.

• Onko Tehtäväluettelo 2012 TATE-osuuden julkaisun viivästymisellä ollut vaikutusta esim     tietomallintamisen prosessien kehittämiseen? Ja toisinpäin, onko julkaistava TATE 12  edelleen ajan tasalla tietomallinnuksen suhteen?

Mielestäni viivästymisellä on ollut vaikutusta tietomallinnuksen kehittymiselle. Jotta me suunnittelijat voimme tehdä asioita mallipohjaisesti, niitä töitä pitää pystyä meiltä tilaamaan. Kun annamme kiinteähintaisia tarjoushintoja, niin tilaajan on pystyttävä kertomaan, mitä he haluavat.

Se onnistuu hyvin TATE12 tehtäväluettelolla ja se on mielestäni hyvin ajan tasalla nykyisyyden kanssa. TATE12 talotekniikan osaltahan oli lähes valmis, kun teimme YTV2012 vaatimuksia. Ehdimme lisäämään tehtäväluetteloon muutaman kohdan, jotka tarkensivat tietomallisuunnittelun tehtäviä.

Tietenkin, neuvottelumenettely on paras ratkaisu, jos todella halutaan laatua ja elinkaarikustannusten vähenemistä -  eikä vain investointikustannusten minimoimista.

• Puhuit Plaanissa 2/12 uusista sopimusmalleista ja mainitsit IPD:n (Integrated Projec Delivery), jonka suuntaan toivoit mentävän. Nyt uusia malleja noussut, esim. Yliopisto-   kiinteistöjen ”yhteistyömallit”. Mitä mieltä nyt?

IPD tai Allianssi, se on yksi tapa tehdä asioita fiksummin. Nämä ovat sopimusteknisiä asioita, joissa pyritään sopimustekniikalla mahdollistamaan suunnittelijoiden, tilaajan ja urakoitsijan mahdollisimman järkevä yhteistyö. Normaalit, perinteiset sopimusmallit estävät järkevän yhteistyön, koska aina välillä joukossa on joku osapuoli, joka ei halua nähdä kokonaisuutta.

Se, että pitääkö näin pitkälle mennä, ei ole aina pakollista. Tilaaja voi aivan hyvin koota tiimin, jonka yhteistyön tietää toimivan ja jonka kanssa he osaavat toimia. Juridisia mahdollisuuksia on olemassa, neuvottelumenettelyt jne.

Kun Yhteistoimintamalliseen projektiin lisätään Lean Construction filosofia ja prosessina käytetään tietomallipohjaista etenemistä, niin uskon että homekouluilta vältytään ja tilaaja saa sitä, mitä on tilannut.

Viikon kuva:

Systems Engineering

Täytyy myöntää, että olen aika kovapäinen tyyppi.

Minun piti käydä pari seminaaria ja yksi baari-ilta asiaa tekevän henkilön kanssa ennen kuin tajusin, että on olemassa tekniikanhaara nimeltä Systems engineering.

Tajusin vasta kun pari kertaa toistettiin, että: "Tuo tietomallinnus vaikuttaa aika samanlaiselta hommalta kuin mitä minä teen.". Ehkä ympäristössä oli hieman liikaa melua, kun en heti tajunnut.

Jonkuntyyppisen googleselvittelyn jälkeen huomaan, että BIM onkin Systems engineeringiä.

Eli jos BIM on prosessi, niin prosessin toimiminen tarvitsee tavoitteita, vaatimuksia ja niiden todentamista.

Ja mitäpä sanotaan sivuilla http://www.finse.org/systemsengineering.php :
"Systems Engineeringillä tarkoitetaan järjestelmällistä toimintatapaa, jolla pyritään varmistumaan siitä, että järjestelmä tai yleisesti ottaen palvelu, jota ollaan tuottamassa vastaa sille asetettuja vaatimuksia. "

Keski-Euroopan reissujeni perusteella olen ymmärtänyt, että Alankomaissa tämä taiteenlaji on kohtalaisen normaalissa käytössä myös rakennuspuolella. Tai ainakin isommissa kohteissa, joita paikalliset firmat tekevät globaalisti.

Nyt tiedän, mitä aihealuetta selvittelen seuraavat pari vuotta jotta pääsen syvällisempään ymmärrykseen tietomallinnuksen mahdollisuuksista.

Näiden kavereiden termistössä ovat 'kaikki' oikeat sanat: "Integrated Teams, Life Cycle, Requirements, Coordination, Risk Management... jne."

Tästä se lähtee:
http://en.wikipedia.org/wiki/Systems_engineering

Viikon kuva:
Aika tutunnäköisiä ympyröitä

Israelkin mukana Lean/BIM haasteessa (ja varmaan IPD:ssäkin...)

Aarni Heiskanen on kirjoittanut AEC business -julkaisuun pienen jutun, jossa kannustetaan tutkimustulosten valossa jatkamaan Lean / BIM työkalujen käyttöönottoa:

http://aec-business.com/making-construction-efficient-again-with-lean-and-bim/

Mielestäni olemme nyt selvästi siirtymässä teknologiavoittoisesta tietomallimaailmasta lähelle sitä, mitä meidän pitäisi rakennusteollisuuden suunnittelussa ja urakoinmnissa tehdä. Eli ymmärtää, että kaikkia osapuolia tarvitaan ja pitää osata kommunikoida muiden kanssa.

Teknologia (BIM) yhdessä filosofian (LEAN) ja sopimustekniikan (IPD / Allianssi) kanssa mahdollistaa tavoitteen mukaisen lopputuloksen.

Kirjoituksessa  "Associate Professor Rafael Sacks of Technion, the Israel Institute of Technology" sanoo:
"One practical idea for increasing cohesion is to create social networks among the subcontractors"

Huh huh... kuinkahan lähellä tai kaukana tuosta aliurakoitsijat ovat keskenään.... Edelleenkin jopa minulla on ongelmia nykyprojektien valossa ajatella, että "urakoitsija on ystävä".

Sitten kun tuohon tilanteeseen todella päästään, ollaan pitkällä.

Lue lisää hyviä kirjoituksia osoitteesta http://aec-business.com/

Tekla Global BIM Awards 2012

Tämä viesti on kirjoitettu tänne vain siitä syystä, että hakukoneet ohjaisivat tänne lisää lukijoita.

http://www.tekla.com/international/solutions/building-construction/Documents/Tekla-global-BIM-awards-2012/index.html

Olen huomannut, että kun kirjoittaa johonkin blogikirjoitukseen "Tekla", niin sillä on neljä kertaa enemmän lukijoita kuin muilla teksteillä.

Kenties rakennesuunnittelijat ovat todella kiinnostuneita Teklasta tai sitten firmalla on kohtalaisen hyvä markinointi- / hakukonenäkyvyys...

No, onhan tuo oikeasti hieno juttu että Teklalla tehdyt kohteet saavat näkyvyyttä ja samalla tietomallinnusmaailma saa lisää näkyvyyttä.

Tulisipa MEP -puolellekin vastaavia kisoja... pitäisiköhän alkaa järjestellä sellaista?

No, Teklan kisaan:
Siellä on kolme kategoriaa, BIM -Projects ja muut. Jäävään itseni heti noista muista, ei kiinnosta siltatekniikka ja rakennukset, joissa on vaan väännetty rautaa / betonia ajattelematta kokonaisuutta.

Ajattelin, että jäävään itseni myös tuosta suomalaisesta BIM awards voittajasta, Derby Business Parkista, mutta kun luen ym. linkin tekstejä ja katson kuvia, niin eihän tuolla ole muuta varteenotettavaa kilpailijaa kuin Qatarin museo

Siellä näkyy yhdessä kuvassa IV-koneita ja kanttikanavaa. Tuon yhden kuvan perusteella valitsen sen voittajaksi.

Harmi homma, tiedän sattuneesta syystä, että Derbyssä mentiin MEP-mallinnuksessa ja energialaskennoissa erinomaisen pitkälle, mutta niitä juttuja on kerrottu vain tekstiosuudessa - ei kuvissa joiden perusteella suurin osa päätöksistä tehdään.

Ja toisaalta, Derby on "vain" toimistotalo. Tuo Qatarin kohde näyttä aikamoiselta hässäkältä ja voin kuvitella, mitä haasteita siiinä on ollut "BIM-projects" -kohteeksi.

Jos Teklan sivuilla kirjoitettu teksti pitää paikkaansa siitä, että rakennusurakoitsija on jatkanut suunnittelijan mallia tarjouskisan jälkeen esivalmistusasteelle, niin se on aikamoinen saavutus.

Sillä minulle kerrotun mukaisesti; "lähi-idässä ei mallinnuksella ole rakentamisessa merkitystä. Työmaalla on 5.000 pakistanilaista, jotka hoitavat homman 2d-piirustusten mukaisesti". Tämä lause ei ole minun suustani, enkä ole rasisti. Tuon on lausunut eräs belgialainen, joka on ollut tekemässä Burj Kalifaa.

Eli voittaja on National Museum of Qatar

Ymmärrän, että kyseessä on rakennesuunnitteluohjelman kisa, jossa tsekataan, miten sitä on käytetty rakentamisessa. Toivon jatkossa kuitenkin, että jos kategoria on BIM projects, niin ei keskitytä pelkkään betoniin ja teräkseen.

Onkohan Teklan kaverit koskaan kuulleet sitä, että rakennusten omistajaa ja käyttäjää ei voisi vähempää kiinnostaa rakentaminen? (joo, tässä kisattiinkin mallintamisessa / rakentamisessa, ei rakennuttamisessa)

Mutta heitä kiinnostaa erinomaisen paljon saada toiminnalleen toimivia tiloja. Ja nykyaikana jopa energiatehokkuutta. Jatkossa varmaankin hyviä sisäilmaolosuhteita sekä lämmön, ilmanlaadun että akustiikan suhteen.

Muutamia vuosikymmeniä eteenpäin - ja elinkaarikustannuksetkin alkavat kiinnostaa.

Ym. juttujen todentamiseen suunnitteluvaiheessa tarvitaan "BIM Projects" tyyppistä yhteistyötä jollon seinä, palkki tai pilari ei ole olemassa pelkästään sitä varten, että ne pitävät ylempää kerrosta ylhäällä.


Viikon kuva:

Jos suoraan sanotaan, niin aika aneemisen ja vajavaisen näköinen kuva iv-tekniikasta... eikä nuo painekammiotkaan oikeasti voi tuollaisia olla. Puhumattakaan 90 asteen käyristä, joissa ei ole ilmanohjausta otettu huomioon -> isot painehäviöt - iso energiankulutus - mutta qatarissa varmaan ylläpitorahaa riittää...

COBIM lontooksi / YTV2012

Finally,

http://www.en.buildingsmart.kotisivukone.com/3

English versions of Finnish National BIM Requirements.

With these requirements, world will be a better place to be.... :)

Tietomalliblogin ensimmäinen versio

Olen yrittänyt olla kirjoittamatta tätä blogia monta vuotta, mutta nyt se on pakko tehdä. Suomessa tietomallintaminen on lyönyt itsensä läpi, ja muu maailma tulee hieman perässä vaikka joistain uutisista voisi kuvitella toisin.

Olemme Suomessa tietomallintamisen eturintamassa, Norjalaiset tulevat lähellä takana, Tanskalaiset  yrittävät saavuttaa ja jenkit keskittyvät suuriin puheisiin. Ruotsalaisista ei ole tässäkään asiassa mihinkään...

Mistä minä tiedän tämän?

Vastaus on yksinkertainen ja helppo: kokemuksesta. Vuosien pään hakkaamisesta seinään. Tietomallintamisen hyödyistä puhumisesta kuuroille korville.

Koska olen useimmille lukijoille (toivottavasti) outo lintu, tässä hieman taustaa:
Ikää +40, cadin kanssa tekemisissä ~1988 lähtien, työelämässä 1995 lähtien. Tittelinä BIM Manager, työpaikkana Insinööritoimisto Olof Granlund, Helsinki. (http://www.granlund.fi/)

Työnkuvana taistella päivittäin tietomallintamisen haasteiden kanssa. Lauseesta voidaan päätellä se, että toimenkuvani lähenee markkinamiestä ja erkanee teknisestä asiantuntijasta. Haasteet voivat olla joskus ongelmakin...

Palatakseni alkuperäiseen lähtökohtaan: tietomallintamisen tila suomessa ja muualla. Kymmenen vuotta sitten oli harvinaista löytää arkkitehti, joka teki projektin mallintaen. Jos löytyi, niin heillä oli käytössä ArchiCAD ja yleensä asennekin kohdallaan (olemme parhaita, olemme tehneet tätä jo 80-luvun lopulta jne.). Realiteetti tuli esiin projektin aikana kohtalaisen nopeasti - graafista 3d-mallia ei saatu erikoissuunnittelijoille asti tietosisällöstä nyt puhumattakaan.

Nykytilanne on jo hyvä, on enemminkin harvinaisuus löytää "2D-suunnittelija", mallit liikkuvat hienosti projekteissa, usein jopa rakennuttajan / tilaajan tietämättä asiasta.
Jenkeistä kunnioitus menee tällä kertaa tänne: http://www.dpr.com/, ja  Atul Khanzoden työ virtuaalisen mallinnuksen ponnistuksiin. Atulin työ myös CIFEssä (http://cife.stanford.edu/sites/default/files/TR187.pdf) on huomioitu.

Miksi tietomallintaminen on rakennusten suunnittelussa lyönyt itsensä läpi? Onko se hypeä vai jotain mitä pitäisi kaikkien tehdä?

Kaikki, jotka tekevät suunnittelun tietomallintaen, tietävät vastauksen. Se on nopeampaa, kun ajatellaan kokonaisuutta. Se on kustannustehokkaampaa, kun ajatellaan kokonaisuutta. Se on kaikkia näitä silloin, kun hallitaan ohjelmistot ja suunnittelu. Jos jompaa kumpaa ei hallitse, asia kaatuu.

Ensimmäisenä pitää osata suunnitella, sitten mallintaa. Mallinnus ei takaa sitä, että suunnitelma olisi kunnossa. Hävettää olla mukana projekteissa, joissa joku osapuoli ilmoittaa, että he eivät mallinna, koska se ei ole kustannustehokasta. Se tarkoittaa sitä, että en ole ammattilaisten kanssa töissä. Näistä kohteista on vain selviydyttävä.

Olen LVI-suunnittelija, jos se ei vielä tullut ilmi. Tai ainakin ex-sellainen. Siksi tämä uho. LVI-suunnittelija yleensä luulee tietävänsä kaikesta kaiken.

Meillä on pieni ego-ongelma.

Mutta se ei estä minua jatkamasta kirjoittamista.
Tulen kirjoittamaan suunnittelusta, kiinteistöjen ylläpidosta ja rakentamisesta tietomallintamisen näkökulmasta. Kirjoitan nämä asiat omiin nimiini eli työnantajaani ei kannata sisällöstä soimata.

Viikon vinkki:
- Sopikaa origon sijainti heti projektin alussa.
Arkkitehti määrää sen sijainnin World -koordinaatistossa ja muut seuraavat sitä.
Origoa ei siirretä projektin aikana.
Asemakuva on eri origossa kun rakennuksen kerrospohjat, vrt. Senaatti kiinteistöjen ohjeistus. Asemakuvaan merkitään kerrospohjien origon sijainti sekä positiivinen x-akseli, kääntökulma, UCS-koordinaatisto tai moduliverkko. Tai kaikki nämä.
Kerroskuvissa origo sijoitetaan lähelle rakennusta.

Viikon kuva:
Salon kaupungintalo, LVIS-tekniikka