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:

buildingSMART Finland, tietosisällön vakiointi

buildingSMART Finland Talotekniikan toimialaryhmä on julkaisut tietomallien vakioidun tietosisällön vaatimukset, ladattavissa täältä:
https://buildingsmart.fi/talotekniikan-tietomallien-tietosisallon-vakiointitaulukko-julkaistu/

Tämä taulukko on alkulaukaus sille, että alkaisimme käyttää myös TIETOA suunnittelun aineistoissa.

Teemme edelleen suunnitelmia pelkästään visuaaliseen tarkasteluun.

Meiltä puuttuu ymmärrys siitä, että tietomalli täydentää paperituotetta, emmekä osaa / uskalla käyttää tietomalleja rakentamisen ykköstiedonlähteenä.

Piirustukset eivät tule häviämään mihinkään, ne ovat yksi osa tietomallia. Yksi näkymä moniulotteiseen tietosisältöön.

Räikeimpänä esimerkkinä talotekniikan puolelta voidaan ehkä pitää sähköteknisten kaavioiden ylivaltaa. Asiat esitetään piirustuksen muodossa, jotka ihminen tulkitsee tuotteeksi. Lisäksi muut dokumentit "täydentävät" kaavioiden tietoja.  Näitä kaavioita ei voi poistaa kokonaan, niille on ehdottomasi oma paikkansa. Mutta mutu -arvioni on, että 80% tietosisällöstä voidaan tuottaa koneluettavaksi jotta esim. jakokeskusvalmistaja voi tuottaa hinta-arvion tehokkaammin (muutettuaan tietenkin ensiksi oman tarjoussysteeminsä...).

Ym. ei tarkoita sitä, että tiedot pitäisi olla IFC-malleissa. Ne voivat olla yhtä hyvin tietokannoissa, johon päästään kiinni API rajapinnoin.

Kuten tiedetään, taustani on LVI -suunnittelu, siksi on helppo ottaa silmätikuksi alue, josta en tiedä juuri mitään. Mutta kyllä minuta ihmetyttää, että projektissa voi olla yli 800 (kahdeksansataa) kaaviota eikä yhtään sähköteknistä laiteluetteloa - pois lukien valaisimet.

Vakiointitaulukon tarkoitus

bSF TATE-vakiointitaulukko on tehty, jotta eri suunnittelufirmat voisivat tuottaa tilaajalle tietomalleja samanlaisella tietosisällöllä. Näin suunnittelutoimistojen tuotos näkyy tilaajalle päin samanlaisena tietosisällön suhteen.

Ainakaan minulta, tilaajat eivät ole tällaista koskaan vaatineet. Se johtuu siitä, että tilaajat eivät vielä arvosta tietosisältöä. Kun vakioitu tietosisältö alkaa olla "uusi normaali", tulee ohjelmistoja jotka hyödyntävät tietoa skaalautuvasti. Tämän jälkeen myös tilaajat hahmottavat uuden tilanteen - portfoliotason tiedolla johtaminen on mahdollista, koska tiedot ovat semanttisia - tietosisältö on tiedossa, tiedetään mistä kentästä luetaan mitäkin tietoa ja mitä se tarkoittaa.

Näin siis voidaan tehdä koneluettavia, kolmannen osapuolen ohjelmistoja jotka ymmärtävät heti, mitä suunnittelija on tuottanut.

Kiinteistöjen omistajaorganisaatiot hyötyvät tästä eniten. Rakennusten tekniset tiedot ovat vertailukelpoisia keskenään.

Miten otetaan käytäntöön?

Suomessa, MagiCAD  Group ja Kymdata ovat luvanneet tehdä omiin ohjelmistoihinsa valmiit asetukset, jotka valitsemalla voidaan tuottaa IFC-tiedostot, jotka tukevat bSF speksiä.

Arvio asetusten julkaisemisesta: vuoden 2019 aikana

Tilaajat: kun käyttötapaustaulukot on tehty, voitte viitata niihin tarjouspyynnöissä. Kun nyt vuonna 2019 tilaatte suunnittelun YTV2012 speksin mukaisesti, niin saatte oletettavasti juuri sen, mitä haluatte.

Tämän vakiointitaulukon tietosisällön tuottaminen onnistuu helposti, kun sovellusohjelmistojen IFC-export määrityksiin / asetuksiin pystytään luomaan omia sisältöasetuksia.

Suunnittelu tehdään normaalisti, ja kun tehdään IFC-export, niin valitaan bSF-speksin mukaiset asetukset - ei lisätyötä suunnittelijalle, kun mennään YTV2012 mukaisilla asetuksilla.

Yhteistoiminnallisuus

Taulukossa on paljon tietokenttiä.  Kaikkia ei ole tarkoitettu täytettävän BIM-softan / suunnittelijan toimesta, vaan taulukko varautuu tulevaan, yhteistoiminnalliseen toimintatapaan, jossa rakennusorganisaatiot yhdessä tuottavat tietoa tilaajan tarpeisiin.

Suunnittelija tuottaa tilaajan vaatimaa tietoa, rakennusurakoitsija täydentää sitä esim. hankintojen ja aikataulutuksen näkökulmasta sekä ylläpito-organisaatio hyödyntää sekä rikastuttaa tätä tietoa omiin tarpeisiinsa.

Ym. skenaario ei ole mahdollista tiedostopohjaisessa, IFC-malleihin perustuvassa toimintakulttuurissa. Siksi tarvitaan avointa tietosisällön vakiointimäärittelyä, joka kokoaa usean eri järjestelmän tietosisältömääritykset yhden speksin alaisuuteen.

Tulevaisuus

Taulukko on tehty, jotta softavalmistajat näkevät, minne ala haluaa tietomallinnusta viedä. Taulukossa on asioita, jotka eivät ole vielä mahdollista toteuttaa. Taulukossa otetaan kantaa mm. LoI (Level of Information) ja LoG (Level of Geometry) määrityksiin. Näille ei ole selkeää speksiä vielä olemassa, mutta bimforum.org järjestelmän LOD -systeemi kertoo periaatteet.

Tulevaisuudessa tietomallit tulevat olemaan pilvessä. Myös natiivimallit. Tämä helpottaa tiedon jakamista ja tuottamista usean eri toimittajan kesken. Suunnitelu, urakointi ja ylläpito lähenevät toisiansa.

Salatut erikoiskohteet tulevat kärsimään tästä suuntauksesta, mutta oman pilven rakentaminen on tietyin reunaehdoin mahdollista.

Onko ristissä muiden vastaavien hankkeiden kanssa?

Ei ole, sillä nyt puhutaan ruohonjuuritason vakioinnista. Tämä ei ole nimikkeistö, kuten esim. CoClass tai Cuneco.

Lisäksi tämä on paljon suppeampi näkökulma, kuin esim. CoBIE määrittelee. Olemme pyrkineet ottamaan käyttöön minimimäärän tietoa - jolla kuitenkin pärjätään 80% tapauksista.

Eveliina Vesalainen teki aiheesta myös diplomi-insinöörityön, jossa verrattiin eri nimikkeistöjä:
https://buildingsmart.fi/talotekniikan-bim-nimikkeistojen-parhaat-kaytannot-eveliina-vesalainen-granlund/

Even dippa oli yksi perusta tämän bSF vakiointityön tekemiselle.

Vakiointitaulukon rakenne

Taulukko on nyt julkaistu Excel -formaatissa, mutta laajamittainen käyttö vaatii omaa sivustoa tai ohjelmistoa. Asia on työn alla... ehdotuksia otetaan vastaan.

Taulukko koostuu kahdesta osiosta:

1. Propertylistauksesta, jossa on listattuna propertyt ja propertysetit.
2.  Käyttötapaustaulukoista, jossa kerrotaan mitä propertyjä milläkin talotekniselle komponentille tulee olla ko. käyttötapaukseen liitettynä.

Nyt on siis julkaistu osa 1, eli propertylista. Siihen tulee vielä täydennyksiä, eli tarkoitus on vielä vakioida eri propertyjen arvot, jos property sen mahdollistaa (ei numeerinen).

Esimerkkinä tästä esim. property "Discipline" (tekniikanala). Sen arvot voidaan vakioida, eli vastaukset voisivat olla: "Ilmanvaihto", Sähkötekniikka", Rakennusautomaatio"...

Property? Propertyset?

Mitä nuo ovat?
Property on IFC-tiedostossa oleva Attribuutti. Propertyset on IFC-tiedostossa oleva Ominaisuusjoukko.

Propertysetit sisältävät propertyjä.
Propertyllä on joku arvo/vastaus (Property Value)

Esimerkki:
Propertysettiin "bSF_Technical" on määrätty liitettäväksi property "Material". Property Value tähän voi olla esim. "Cu" tai "Copper". Tästä pääsemme edellisen kappaleen kysymykseen - mikä halutaan vakioiduksi vastaukseksi?

Selection List voi kertoa propertylle "Material" vastaukseksi "Cu" tai "Copper". Tai "Kupari" Millä  mennään eteenpäin? Tähän buildingSMART Finland haluaa vastauksia kentältä. 

Kielivalinta

Meidän oli tehtävä päätös, että mennäänkö suomenkielellä vai kansainvälisellä, ifc-speksin mukaisella vaihtoehdolla. Valinta päätyi kansainvälisyyteen.

Kansainvälisesti tietosisällön vakiointihankkeita on menossa useita, mutta emme löytäneet sieltä suoraan, suomalaiseen suunnittelu- / rakentamiskulttuuriin soveltuvia vaihtoehtoja. Lopputulos oli tehdä speksi englanniksi. Ajatuksena myös se, että ehkä joku toinen maa ottaisi meidän tekemän speksin käyttöön - näin saisimme synergiaa aikaiseksi. Näitä vakiointeja ei ole kuitenkaan julkaistu vielä kovinkaan montaa.

Huomioitavaa siis on, että virallinen bSF vakiointi tarkoittaa vakiointia englanninkielisillä propertyillä ja propertyseteillä. Property value (eli arvot propertyille) voivat olla joko englantia, numeroita, swahilia tai valintoja "Selection List" -listasta. Siis sitä, mitä tilaaja vaatii omalle kohteelle tuotettavaksi.

Käyttötapaustaulukko (=ruksihelvetti)

Ehdottomasti vaikein osuus tämän vakiointitaulukon jalkauttamisesta kentälle tulee olemaan käyttötapaustaulukoiden käyttö.

Käyttötapaustaulukot kertovat, mitä tietosisältöä tilaaja haluaa saada suunnitelmiinsa, rakennusvaiheeseen ja ylläpidon käyttöön.

Käyttötapaustaulukot eivät ole vielä tehtynä tässä ensimmäisessä julkaisussa. Vuoden 2019 aikana tehdään taulukko, joka vastaa Yleisten Tietomallivaatimusten YTV2012 tietosisältövaadetta.

Julkaistussa excelissä on mukana myös tyhjä taulukko käyttötapausmäärittelyjen tekemiseksi. Isoin haaste sen tekemiselle oli erilaisten LVISA laitteiden kategoriointi. Onko meillä käytössä omat sisältövaatimukset komponenteille "Venttiili" ja "Linjasäätöventtiili". Vai menevätkö ne samalla tietosisällöllä?

Käyttötapaustaulukoita tehdään tarpeen mukaisesti lisää. Niitä voi tehdä tilaajat haluamallansa tietosisällössä, mutta ainakin taulukot ylläpidon-, määrälaskennan- , yleissuunnittelun ja toteutussuunnittelun vaatimuksista  tullaan tekemään bSF TATE-ryhmän toimesta.

TATE-komponenttien kategoriat

Henkilökohtaisesti erittäin korkealle arvostamani henkilöt olivat sitä mieltä, että kategorisointi on täysin turhaa. Komponenteille kerrotaan yhdellä propertyllä, mikä se on. Eli esim. "Ultraviolettisterilisaattori" olisi oman kategorian arvoinen. Ajatus oli, että jokaisella komponentilla on "Minä olen" -tyyppinen propertytieto.

Tähän ei menty, vaan tehtiin kaksiportainen komponenttien tunnistusjärjestelmä.
Property "Object Type" kertoo pääkategorian, joka on siis käyttötapaustaulukoiden otsikkona.
Property "Object Subtype" kertoo tarkenteen pääkategorian laitteelle.

Esimerkki:
"Object Type" = "Venttiili"
"Object Subtype" = "Linjasäätöventtiili"

Näin siis saadaan 95% TATE -komponenteista päägategorioiden alle ja kun halutaan kertoa todella tarkka speksi komponentin tyypistä, voidaan kirjoittaa kenttään "Object Subtype" arvo "Ultraviolettisterilisaattori". Tämä kenttä toimii kuten vaatimus "Minä olen" -tiedolle.

Yksiköt (Units)

Taulukon julkaisun jälkeen tuli heti pari kyselyä siitä, että millä yksiköillä arvot kirjoitetaan.

Pääsääntö on se, että käytetään IFC-speksin mukaisia logiikoita - mitä se sitten tarkoittaakaan.

Excelissä sarakkeessa " i " näkyy "plus" merkintä, jonka avaamalla saa näkyville ne yksiköt, joita halutaan ohjelmistoissa näkyvänä.  (excelissä on  siis piilotettuna sarakkeita)

Eli jos on Discipline "Piping" niin olisi kiva, jos olisi kPa arvoja paineen yksikkönä. Jos on "Ventilation", niin "Pa" on paljon parempi arvo näytöllä kun klikkaa komponenttia.

Yksiköiden käyttö IFC speksin sisällä ei vaikuta olevan mitenkään yksinkertaista eri softatoimittajien välillä. Tästä otetaan mielellään kommentteja vastaan - miten tämä tulisi speksata, jotta softat pystyvät yksiselitteisesti toimimaan siten, että käyttäjä näkee yksiköitä, joita haluaa nähdä.

Tilaajat, rakennuttajakonsultit, tarjousten laatijat

Toivon, että ette käytä tätä tietosisällön vakiointitaulukkoa lyömäaseena esim. luovutusmallien tekemisen yhteydessä.

Jos ruksaatte käyttötapaustaulukkoon "Kaikki" tiedot, niin miettikää, mille osapuolelle niiden täyttö tulee osoittaa. Miettikää, mikä tieto on tärkeää ja mikä ei.

Ennen kaikkea miettikää, kuka tulee tietoa käyttämään? Ei ole mitään järkeä pyytää as-built tietoa, jos sitä ei tulla käyttämään missään hyödyksi. Tuleva saneeraus ei riitä vastaukseksi - se tulee vasta 5-10 vuoden päästä. Rakennus (ja softat) on muuttunet jo tuohon mennessä. 

Henkilökohtaisesti en tiedä yhtään kohdetta, joissa olisi ylläpidon aikana ollut CoBIE käytössä, (tai sillä siirretty tietoja) ylläpitojärjestelmään. Se että BIM mallit on kunnossa, ei tarkoita sitä, että ne olisivat käytössä. Ja päivittyisivät rakennuksen elinkaaren aikana.

Suunnittelijalle ja urakoitsijalle jokainen ruksi maksaa rahaa. Se näkyy myös tarjoushinnoissa.

Kun vaaditte tietosisältöä, muistakaa myös varmistaa, että saatte sitä.

On epäreilua, jos joku lipeää siitä, mitä on pyydetty. Kun EIR (https://www.designingbuildings.co.uk/wiki/Employer%27s_information_requirements_EIR ) on tehty, niin BEP (https://www.designingbuildings.co.uk/wiki/BIM_execution_plan_BEP ) vastaa siihen, mitä on vaadittu ja miten se aiotaan toteuttaa.

Varmistakaa, että saatte sitä mitä on tilattu.

On muistettava, että tietosisällön tuottamisesta maksettu raha on pieni asia siitä hyödystä, jotka saavutetaan, kun tietomalleja käytetään rakennuksen elinkaaren aikana.

Tietomallin sisältämä Tieto on tärkeämpää kuin seinän sijainti graafisessa ympäristössä.

Puolen vuoden kuva:

Tästä se lähtee:

Kommnetit bSF taulukkoon, jätä  mieluiten tähän blogiin. Tai Twitteriin / LinkedIniin.

Digitaalinen omaisuus

Tajusin muutama kuukausi sitten erästä esitystä tehdessäni, että toimitilarakentamisen suunnittelukustannukset ovat ~8-10%.

Suunnittelu ei tuota mitään muuta kuin digitaalista aineistoa. Ihmisten aivoista valuu dataa erilaisiin tietoteknisiin järjestelmiin. Yksikään suunnittelija ei ole rakentanut fyysistä seinää tai asentanut kanavaa kattoon.

Tämän lisäksi urakointi ja varsinkin sen alihankinta- ja tavarantoimitusverkosto tuottaa tästä aineistosta omaa näkemystä myös digitaalisesti. Uudelleen ja uudelleen, käyttämättä suunnittelijan aineistoa hyödyksi. En osaa arvioida, kuinka paljon, mutta uskallan väittää, että se on rakentamiskustannuksista luokkaa 5-10%. Täysi mutu.

Kun rakennus on "valmis" (tai siis vastaanotettu), lähestulkoon kaikki tämä aineisto jää suunnittelijoiden, urakoitsijoiden ja tavarantoimittajien servereille.

Tämä tieto ei siirry kiinteistön käyttöön, sen ylläpitovaiheeseen. Tälle asialle ei ole kulttuurista tarvetta olemassa, sopimusmallit eivät tue digitaalisen omaisuuden siirtoa kiinteistön vastaanottovaiheessa. Tulostetaan paperia ja ollaan tyytyväisiä.

Suomessa ei arvosteta rakennetun ympäristön digitaalista omaisuutta.

Tämä digitaalinen omaisuus on siis euromääräisesti ~10% siitä summasta, mitä Suomessa rakennetaan vuosittain.

Statistiikan mukaan (https://www.rakennusteollisuus.fi/globalassets/suhdanteet-ja-tilastot/suhdannekatsaukset/2018/syksy/suhdanne_syksy18_lopullinen.pdf)
rakentamisen arvo vuonna 2017 on ollut 33.6 mrd euroa.

Tuosta summasta 10% lienee lähellä 3,4 mrd euroa. Se on digitaalisen omaisuuden arvo, ilman rakennusurakoitsijan ja sen yhteistyöverkoston tuottamaa digitaalisen tiedon luomista.

Omistaja / rakennuttaja maksaa tämän kaiken.

Omistaja / rakennuttaja maksaa tämän kaiken..

Omistaja / rakennuttaja maksaa tämän kaiken...

Ja tämä omaisuus heitetään menemään, kun rakennus on valmis. Ollaan tyytyväisiä fyysisiin seiniin, kunnes halutaa tehdä peruskorjaus -> aloitetaan digitaalisen omaisuuden luonti uudelleen. Onneksi se on eri organisaation hommia, ei mene hankeporukan budjetista.

Kuvittelisi, että organisaatiot, jotka omistavat kiinteistöjä, ylläpitävät ja saneeraavat niitä olisi kiinnostuneita tästä asiasta.Eipä ole tullut montaa vastaan. Eri organisaatiot, eri budjetit, erilaiset tavoitteet ja strategiat - saman yrityksen sisällä.

Sanotaan, että investori ei ole kiinnostunut rakennuksen kunnosta. Tärkeintä on sijainti, sijainti ja sijainti. Väitän, että jos on samassa sijainnissa kaksi rakennusta, jossa toisessa on tiedossa mitä on tehty viimeisen 20v aikana + mitä korjaustoimenpiteitä tulee tehdä seuraavan 20v aikana, niin se on taloudellisesti arvokkaampi.
Technical Due Diligance on jo melkein tehty, kun taas toisessa juoksee konsultit kolme viikkoa tutkimassa kiinteistön kuntoa saamatta siitä kuitenkaan oikeasti mitään tolkkua.

Minulle rakennuksen Digital Twin on yhtä tärkeä kuin fyysinen rakennus. En pysty hahmottamaan, miten rakennusta pystytään nykyaikana ohjaamaan, jos se ei pyöri pilvessä analysoitavana. Rakennuksen fiilistä tulee pystyä näkemään usean eri asiantuntijan voimin läpi pilvipalveluiden. Sen toimintaa pitää pystyä ennustamaan, sen käyttäjiä tulee pystyä palvelemaan kaikin keinoin.

Tämä onnistuu vain käyttämällä digitaalisia työkaluja. Huoltomies, aulapalvelu, siivous ja hyvä kahvinkeitin ei enää riitä.

Tarvitaan digitaalisen omaisuuden hallintaa - sen johtamista ja strategiaa.


Vuoden kuva:
VR-lobbyssä valitset kiinteistöportfolion rakennuksen / kerroksen / järjestelmän, jota halutaan tarkastella

Tate-mallinnus rinnakkaisen suunnittelun ja toteutuksen hankkeissa

SKOL ry, Talotekniikan toimialaryhmä on julkaissut ehdotuksen toimintamalliksi hankkeissa, joissa aletaan rakentaa ennen kuin on suunniteltu.

Tätä kutsutaan yleisesti projektinjohtourakoinniksi, mutta asia pätee myös muihin urakkamuotoihin, joissa tehdään läheistä yhteistyötä suunnittelijan ja pääurakoitsijan välillä, kuten esim. allianssihankkeet.

Speksi on ladattavissa osoitteessa:
https://skol.teknologiateollisuus.fi/fi/ajankohtaista/tate-mallinnus-rinnakkaisen-suunnittelun-ja-toteutuksen-hankkeissa

Talotekniikan toimialaryhmä on tunnistanut ongelmaksi sen, että toteutustason suunnitelmat joudutaan viemään liian pitkälle ilman selkeää ymmärrystä siitä, mitä tullaan oikeasti rakentamaan. Projektinjohtourakoitsija haluaa kilpailuttaa tate-urakoinnin kiinteällä hinnalla, jolloin he vaativat "täydellisiä" suunnitelmia vaiheessa, jossa ei ole vielä tietoa, mitä tullaan tekemään. TATE tekee siis toteutustason suunnitelmat aivan liian aikaisessa vaiheessa hanketta.

Valitettavasti TATE-suunnittelu on ravintoketjussa niin alhaisessa asemassa, että tähän vaatimukseen yleisesti suostutaan. Sen jälkeen alkaa suunnitelmien korjausrumba, kun muutetaan jo tehtyjä suunnitelmia uuden tilaohjelman / käyttäjän muutosten johdosta. Tarkkuustaso murenee käsiin ja ollaan tilanteessa, jossa suunnitelma ei enää ehkä olekaan asennuskelpoinen.

Yleissuunnitteluvaiheessa on täysin OK muuttaa kaikkea. Yleissuunnittelu on sitä, että haetaan tilannetta, jota halutaan rakentaa. Toteutusvaiheessa tätä ylellisyyttä ei voi olla olemassa.

Tästä syystä projektinjohtourakoissa pitää kunnioittaa erittäin hyvää speksiä kiinteän perusosan ja muuntuvan tilaosan periaateista (Kiiras / Kruus, esim.  SUKE seminaari vuodelta 2006:  https://skol.teknologiateollisuus.fi/sites/skol/files/SUKEseminaari0606.pdf )

Lisäksi SKOL speksissä on ensimmäiset ajatukset esivalmistettavien TATE-komponenttien suunnitteluprosessista. Tästä asiasta kuullaan varmastikin vielä lisää, kunhan ajatukset selkeytyvät asian suhteen ja päästään betoniurakoitsijoiden kanssa yhteisymmärrykseen siitä, mitä tuo tarkoittaa suunnittelu- / rakentamisprosessissa.

Suunnittelijalle tuo voi olla aivan loistava juttu. Voidaan ehkä tehdä yleissuunnitelma hieman täydennetyllä tasolla ja sen jälkeen tate-urakoitsijan / esivalmistusyrityksen kanssa yhdessä toteustason tietomalli.

Tämä on mahdollista, kun urakoitsijalle ja suunnittelijalle annetaan mahdollisuus toimia yhteistyössä.


Kuukauden kuva:

Virtual Reality Models in Cleanroom Design

Tämä on kierrätys numero 2/2, kun ei ole mitään uutta kerrottavaa.

Kävin puhumassa puhdastilasuunnittelun seminaarissa "R3 Nordic Symposium" Virtuaalitodellisuuden käytöstä suunnittelussa.

Tässä abstract.

---

Virtual Reality Models in Cleanroom Design

Tero Järvinen

Granlund Oy, Finland

May 2018

Extended Abstract

The use of Virtual Reality (VR) possibilities has increased in recent years due to technology improvements. The driving force has been the gaming industry. The construction sector has been able to benefit from the technology leaps carried out by other industries.

Building Information Models (BIMs) have been in use by architects and structural and mechanical designers since the early 2000’s. In the Nordic countries, using BIMs is a normal way to design and the construction companies are able to utilize these models quite easily.

By combining BIM processes and current VR technologies we are in the situation that the use of VR glasses can be a common means with which the design in construction projects can be promoted.

When combining the VR glasses with models, the end users can obtain a better understanding of what architects and engineers are designing than based only on combined models on a computer screen. With VR glasses on, the users can walk inside the rooms and see objects in real scale.

When the construction process goes further and we have a real environment built up, we can start using Augmented Reality (AR) possibilities. With AR, you can add objects to the camera view of tablets, phones or smart glasses. AR models can utilize the same BIMs as VR is using. Unfortunately, technology in AR systems and software still needs improvements. VR models are easy to set up but AR models need a lot more preparation to work in real-life use cases.

Examples of possible use cases with VR models in the design and construction phases:

·         Checking process functionalities inside Clean Room, moving things in VR

·         Checking service/maintenance possibilities

·         Checking equipment/device locations in the design phase

·         End user approvals/rejections to design team

·         Visual inspection of different lighting environments

·         Multi-user meetings inside Clean Room (attendance from multiple locations)

·         Training of people (device maintenance or processes etc.)

Examples of possible use cases with AR models:

·         Seeing through walls/ceilings (using BIM)

·         Locating equipment/devices (with indoor location or tags attached to devices)

·         Serving additional information to end user for operating devices/to follow protocols (with preloaded material in the cloud)

·         Seeing additional information on top of gauges etc. (using object recognition)

·         Seeing and operating virtual user interfaces on top of QR code etc.

·         Using voice commands for operating AR software (if you need both hands)

Picture: Examples of functionalities in VR models

Processes

The construction process produces BIMs in multiple different formats. Efficient use of VR needs straightforward processes. Access to BIM information is available through an open BIM format called IFC (Industry Foundation Classes). All native BIM modeling software can export IFC-models and these models can be viewed through numerous other software.

Using IFC models as the basis of a VR environment is the most powerful way to create and update VR information during a construction project. With IFC, different disciplines can combine each other’s models and make their own VR models for other use cases from the same source and content.

If the whole design team is using the same native BIM software, IFC is not needed in the process. But in Finland, that’s not a normal case by any means.

Picture: VR/AR models are created from a single source

Devices

VR/AR devices are developing rapidly nowadays. Oculus Rift and HTC Vive have been the best VR glasses for a couple of years. Microsoft launched its “Windows Mixed Reality” platform at the end of 2017 and the cost of VR headsets decreased dramatically. Now there are multiple hardware manufacturers in the market.

Picture: Examples of Windows Mixed Reality Glasses

In the AR sector, there are many different approaches to utilize models.

The easiest way is to use your phone or tablet but in the Clean Room environment that’s not always possible. There needs to be a technology that brings the AR view to your visor or smart glasses.

One working and tested solution is using smart glasses.

Picture: Example of Smart Glasses, Vuzix M300 with Android operating system

In Granlund, we made prototype software using smart glasses with a virtual dashboard.

With that technology, the user can give a simple command using only hands to operate AR functionalities. Functionalities were made for Facility Management purposes, using cloud FM database information, but can also be made with any cloud information that has an interface to connecting data sources.

The software recognizes the hand of the user and draws a virtual dashboard on top of the hand. The user can push the buttons on the virtual dashboard and see more information about the selected topic. The user can change pages by swiping a hand in the air or give “accepted/rejected” commands with a thumb up/down. [1]

It is also possible to use voice recognition, but that was not tested in the Granlund prototype.

Picture: Screenshots from AR Smart Glasses

Information content

When using VR or AR models, the information inside BIMs is still very important. Therefore, access to BIM information is very important for use cases where the information of models is used. Using an open IFC format, information content is understandable to various software platforms.

With IFC, you can build a BIM environment where you can see multiple discipline models in a single, coordinated model. This kind of environment is ideal for VR purposes.

The downside of using the IFC format is that it contains static information. IFC is exported from designers’ native BIMs and is therefore always “old” information, because designers are making updates to native BIMs. In the design and construction phases this is not a big problem, because these phases are used to having iterative information flow in their processes. The designer is publishing a new IFC model, for example, every week to the construction site.

After the construction project – in the Facility Management phase – this kind of process is not possible. Updates to models must be done instantly when something has been changed. To achieve this, we need a Digital Twin of the building or clean room.

Digital Twin

Digital Twin is a representation of a real building, its components, systems, measurements and functionalities. Digital Twin can act as a user interface for AIM (Asset Information Model) [2].

With static asset information from BIMs and a dynamic IoT-sensor or system information from manufacturers’ environments we can build up a system that can be monitored and updated through cloud services. Information from multiple different systems can be seen and operated through a single interface.

With possibilities in cloud software, there is a possibility to update the information in the IFC model seamlessly, without the need of opening complex native BIM software. Native BIM software is needed only when there is a change in graphical objects – you need to move a wall etc.

Using REST API technology, there is a possibility to connect multiple different systems and gather dynamic information from them.

Picture: Example of Digital Twin user interface to monitor temperature, humidity and performance of spaces. This information is also available to a VR/AR environment through REST API.

Picture: Concept of Digital Twin during facility lifetime

With Digital Twin, there are more VR and AR use cases in the future. The digital model comes alive when the user can see dynamic information of clean room in the visor or smart glasses.

References

1.      Demo of using smart glasses with hand gestures
https://www.youtube.com/watch?v=EixdlYRRvAc&t=1s

2.      PAS 1192-3, AIM; “Asset Information Model”. Defined for guideline of using BIM models in operational phase of construction project by BSI, British Standards Institute. https://www.designingbuildings.co.uk/wiki/Asset_information_model_AIM