Mikä on ylläpidon tietomalli?

Tämän hetken yksi suurista asioista, mitä maailmalla puhutaan ja kehitetään, on ylläpidon tietomalli.

Tämä asia ymmärretään yhtä monella tavalla kuin on keskustelijoitakin. Alla oleva näkökulma on minun näkemys siitä, mitä sillä tarkoitetaan.

Lähden liikkeelle siitä, että ylläpidon tietomallista pitäisi varmaan olla jotain hyötyäkin kiinteistön omistajalle. Tai ainakin kiinteistöä ylläpitävälle taholle.

Tämä tarkoittaa sitä, että ylläpidon tietomalli on jotain paljon enemmän, kuin graafinen näkymä tietomalliin. Se on paljon enemmän, kuin tietoja seinistä ja ikkunoista.

Ylläpidon tietomalli on helposti ylläpidettävä tietokanta, josta voidaan saada pitkän tähtäimen suunnitelmia, yhteenvetoraportteja, laitetietoja, huoltolistauksia, ennakoivaa huoltoa jne. On pelkkä nyanssi, että pääseekö tietoihin käsiksi klikkaamalla 3D-mallissa olevaa lattiaa (mikä materiaali, mikä siivousväli jne.) tai muuta objektia.

Tämä ominaisuus on kyllä ihan kiva ja varmaan demoaisin sitä erittäin mielelläni seminaareissa / esityksissä, mutta mitä todellista, konkreettista hyötyä sillä saavutetaan verrattuna esimerkiksi siihen, että klikkaan talon 2D-pohjakuvaa, jossa sama huone sisältää samat tietomallitiedot?

Pääsen 2D-kuvan kautta huomattavasti nopeammin tarkastelemaan asioita huone- tai aluetasolla.

Ylläpito tarvitsee pääsääntöisesti avukseen isojen alueiden kokonaistietoja, jotta voidaan tarkastella kiinteistöä kokonaisuutena. Kokonaisuuksien käsittely onnistuu parhaiten 2D-pohjakuvien kautta, taikka sorttaamalla listasta esim. kaikki kiinteistön käytävät, jolloin tiedän niiden kokonaisneliömäärän -> pystyn kilpailuttamaan siivouksen. (ja saan tietenkin pohjakuvat käytävistä värillisenä jne)

On kuitenkin selvää, että ym. asiat tullaan tulevaisuudessa tekemään mahdolliseksi myös 3D-mallin kautta. Aika näyttää, mitä uutta hienoa sen kautta keksitään, mutta liikkeelle päästään yksinkertaisemminkin. Olisihan se ihan hienoa ajella iv-konehuoneeseen ja klikata puhallinta, jolloin saisin sen tiedot esille. Sekä käyntiajat, energiankulutuksen jne.

Mutta kiinteistön omistajana minua ei niin hirveästi kiinnostaisi se yksittäinen puhallin, vaan kaikkien iv-koneiden kokonaisenergiankulutus ja miten sitä pystyisi pienentämään.

Ym. esimerkissä on jo rutkasti vaikeusastetta. Tuossa tapauksessa ollaan puhaltimeen linkitetty sekä valvontajärjestelmän tietoja että ylläpidon huoltokirjatietoja. On selvää, että ensimmäisinä askeleina tulemme näkemään huoltokirjan linkitykset ja sen jälkeen pitkän ajan kuluttua valvontajärjestelmän tietoja ylläpidon tietomallissa, objektikohtaisesti.

Edellisessä kappaleessa on yksi tärkeä sana. Se sana on "linkitetty". Eli kun mennään 3D tietomallitasolle, niin mikään tärkeä tieto ei ole graafisissa objekteissa itsessään sisällä. Objektit ovat mallissa, jotta niiden avulla voidaan luoda linkki tietokantaan oikeaan komponenttiin tai laitteeseen. Kun jotain muutetaan tai päivitetään, tieto päivitetään tai päivittyy tietokantaan. Ei välttämättä 3D-malliin.

3D-mallia ei kannata aina pienten muutosten takia päivittää. Jos tehdään tilamuutoksia, niin niitä kannattaa kerätä muutamia ja tehdä sitten kerralla graafinen päivitys. Tietokantaa sitä vastoin päivitetään jatkuvasti. Laitteita poistuu, ne muuttuvat, niitä huolletaan jne. Tietokanta päivittyy ja muuttuu, kun normaali nykyaikainen ylläpidon huoltokirjaohjelmisto sitä päivittää.

Miten sitten saadaan ensimmäinen versio ylläpidon tietomallista? Tippuuko se automaattisesti loppudokumenttien muodossa projektipankkiin?

Voin kertoa, että ei tipu.

Prosessimielessä se tarkoittaa sitä, että suunnittelijoiden mallit päivitetään vastaamaan rakennettua todellisuutta (as buildt -mallit). Tässä kohtaa joku sanoo, että ei onnistu. Minä sanon, että onnistuu.

Kikka on siinä, että mitä jos meillä onkin tarjota urakoitsijoille sellaiset suunnittelumallit, että niiden mukaan pystytään kiinteistö rakentamaan? Huima ajatus... että suunnittelija tekisi sellaiset suunnitelmat, että niiden kanssa voitaisiin tehdä työt loppuun. Meillä on siis as buildt -kuvat olemassa jo ennen, kuin yhtään putkea / kanavaa on kattoon laitettu. Tämä on täysin mahdollista, jos suunnittelijoille annetaan mahdollisuus suunnitella kohde kunnolla. Miten se tehdään - on oman blogikirjoituksen aihe.

Kun ollaan tehty tietomalli oikein suunnitteluvaiheessa, jää jäljelle tiedon päivittäminen. Koska urakoitsija on saanut esim. jotkut muut kuin suunnitelmien mukaiset säätöpellit 100e halvemmalla, niin suunnittelija vaihtaa ne omaan malliinsa. Sama juttu muiden tuotteiden kanssa. Päivitetään malli vastaamaan tietosisällöltään todellisuutta. (fiksut tekevät tämän ennen säätötöiden aloittamista, eli tilaavat suunnittelijalta säätökuvat).

Näin ollaan saatu suunnittelijoilta alkutilanteen malli. Sen jälkeen homman ottaa haltuun ylläpidon koordinaattori. Hän tekee normaalit huoltokirjaan liittyvät työt ja hoitaa mallin linkitykset kuntoon. Hänen vastuulla on se kertaluontoinen työ, että ylläpidon tietomalli rakentuu linkittyen tietokantoihin.

Esimerkiksi talotekniikkapuolella on paljon komponentteja ja laitteita, joita ei edes ole mallissa. Laiteluettelot tulee siirtää ylläpidon tietokantaan ja komponentit linkittää vähintään sijaintitiedollaan 3d-malliin.

Harvemmin arkkitehdin mallissa on lattiapintojen materiaalia tai seinäpintojen käsittelyä. Mutta ne löytyvät kyllä erillisestä maalaustyöselostuksesta tai muusta asiakirjasta. Jonkun pitää tehdä se työ, että kaikki tärkeä mitä on haluttu laitettavan ylläpidon tietokantaan, päivittyy sinne.

Näin ollaan päästy tilanteeseen, jossa suunnittelijoiden tietomalli on päivittynyt ylläpidon tietomalliksi ja voidaan alkaa keksiä kaikkia uusia kivoja juttuja, mihin sitä voisi käyttää oikeasti hyödyksi.

Toivottavasti tätä ei lue ketään prosessiteollisuuden / teollisuuslaitosten suunnittelijat... he varmaan nauraisivat, koska heillä ylläpito-organisaatio on heti hankkeen alussa vahvasti mukana suunnittelua ohjaamassa. Eli ensiksi tulee se, miten laite huolletaan / korjataan, sen jälkeen mietitään muut asiat.

Meillä talotekniikkapuolella (ja rakennuttajapuolella) olisi paljon oppimista heiltä.

Viikon vinkki:

- Ensimmäinen askel hyvän tietomallin tekemiselle on asennemuutos.

Viikon kuva:

- esimerkki tietomallipohjaisesta 2D-näkymästä kiinteistöön. Kuvassa näkyy kerroskohtainen tuloilmakoneiden palvelualuekartta

Nuoruuden uhoa

Pidin joskus muinaisina aikoina muutaman vuoden pystyssä nettisivua nimeltä "MagiCAD User Group Finland". Nuo sivustot kuolivat parin vuoden jälkeen yllättäen siihen, että huomasin olevani ainoa sisällöntuottaja...

Kaivelin tässä tiedostoarkistojani ja löysin noiden sivustojen varmuuskopiot. Olipa hauska lukea 2000 luvun alun uhoa.

Esimerkkinä ote eräästä sivusta:

--cut---

5. Miten haluaisin homman toimivan

- IFC on jo arkipäivää joillekin käyttäjille. Tuotemallipohjainen suunnittelu LVI-teknisessä mielessä tarkoittaa kahta asiaa: tilojen lämpötilojen / olosuhteiden laskemista simulointiohjelmistoilla sekä raa'an massatiedon tuottamista oikeilla komponenteilla. Tilojen laskemiseen tarvitaan arkkitehdin tilamalli tai sitten se pitää tehdä itse. MagiCAD tuottaa IFC-tiedoston kanavistoista / päätelaitteista käytettäessä "BSPro for IFC -files" ohjelmistoa.

Suunnittelijan näkökulmasta LVI-teknisiä laskelmia tehtäessä suurin työ on laskea pinta-aloja ja kuutioita. Onneksi IFC-tiedoston tilamallissa nämä ovat automaattisesti olemassa, joten tähän työhön ei tarvitse ryhtyä - voidaan käyttää aikaa johonkin mielekkäämpään, esim. vertailujen tekemiseen. Simulointiohjelmistot tekevät laskennat, sinä analysoit tulokset ja esität ne asiakkaalle.

Huomioitava on se, että nykyaikaisessa LVI-suunittelussa lasketaan kaikki rakennuksen tilat, ei vain muutamaa malli- / perustilaa. Laskelmilla tarkoitan lämpöhäviöitä, lämpötilaa, jäähdytystehoa ja energiaa (sähkö/lämpö).

Jos mennään tilamallista hieman pidemmälle, eli haluttaisiin hakea arkkitehdin 3D-malli esim. magicadiin arkkitehtikuvaksi, niin ollaan pienissä ongelmissa. Todellisuus on se, että wireframehässäkkään ei voi putkia piirrellä. AutoCADin kyvyttömyys shadetettujen kuvien käsittelyssä on kaikkien tiedossa, joten sekin voidaan unohtaa. Tarvitaan joko parempi ohjelma-alusta kuin acad tai ohjelmistovalmistajien yhteistyötä.

Tähänkin IFC tuo tällä hetkellä ratkaisunsa, sillä mikä estää laittamasta IFC-tiedostoa nettiin ja sieltä ohjelmistot hakisivat ne objektit, jotka sen hetkistä suunnittelijaa kiinnostavat? ArchiCAD -arkkitehti hakisi IV-päätelaitteet, Tekla Xsteel -rakennesuunnittelija hakisi tason +24.56 lävistävät putket, MagiCAD LVI-suunnittelija hakisi rakennesuunnittelijan palkistot, MagiCAD sähkösuunnittelija hakisi kahvia?

Ym. asia vaatii ainoastaan pientä yhteistyötä ohjelmistovalmistajien kesken. Kokemuksesta tiedän, että tällainen yhteistyö olisi mahdollista. Joskin sähkärille kahvi yleensä tuodaan työpäydälle.

Netissä olevia "modelservereitä" on jo olemassa (21.02.2004), ainakin myyjien powerpoint -kalvoilla. Joskin ihmettelen, miksi jotkut firmat keksivät pyörän uudelleen ja kehittivät oman "standardin" IFC-tiedostojen käsittelyyn. Itseäni on aina ihmetyttänyt se, kun joku kravattikaveri puhuu "tietokannoista" suureen ääneen. Ei se yksinkertianen tietokanta ole Excel -taulukkoa ihmeellisempi asia. Kunhan tietää, mistä kentästä luetaan ja mitkä relaatiot ovat. IFC ei edes ole tietokanta, vaan "Schema". Kertomus objekteista, sisällysluettelo geometriasta / tuotteista.

Käytännössä homma vaatii kuitenkin vain pientä viilausta ohjelmistoissa. Bentley, Progman, Grapfisoft, DDS, Tekla ja Autodesk istumaan saman pöydän ääreen, kaikkiin ohjelmiin samanlainen ikonivalikko ja homma pyörimään. Turha tässä enää on jahkailla.

teroj

---cut---

Hohhoijaa... jepjep. Kaikki vaan saman pöydän ääreen. Niin helppoa se olisi...

http://web.archive.org/web/20040610095309/http://www.mugf.net/

AutoCAD ja Visual Basic

Muistaakseni AutoCAD 2009 version jälkeen Autodesk ilmoitti, että he eivät jatkossa enää tue visual basic rajapintaa ulkopuolisten ohjelmistojen suhteen. 2010 version jälkeen ilmoitettiin, että 2011 versiossa ei enää nähdä VBA rajapintaa.

No, Autodesk teki kuitenkin VBA:n toimivaksi erillisellä asennuspaketilla 2011 versioon. Heidän omien sanojen mukaan suurinpiirtein näin: "Olemme kuunnelleet käyttäjiä, tulemme tukemaan visual basiccia vielä tässä versiossa erillisen asennuspaketin muodossa, mutta sen jälkeen se on loppu"

Katselin juuri autocad 2012beta paketteja ja kas kummaa, VBA palikka on taas asennettavissa.

Ei mene tällaisen pienen BIM Managerin jakeluun, että sanotaan jotain ja tehdään toista. Jos VBA rajapinta ilmoitetaan lopetettavaksi, niin eikö sitä siten lopeteta?

Toisaalta, tähänkin löytyi Autodeskiltä apu. He lupasivat ilmoittaa sivuillansa ohjelmistofirmoja, jotka voivat (maksua vastaan...) muuttaa visual basic koodia muille ohjelmointikielille...

Kuinkahan monta työvuotta on mennyt maailmanlaajuisesti, kun autodeskin softia käyttävät firmat ovat koodanneet tai koodauttaneet toimivia VBA ohjelmanpätkiä dotnettiin, ceesharppiin tai muuhun, autodeskin tällä hetkellä "tukemaan" ympäristöön? Koodauksen lopputuloksena on ollut sama apuohjelma, joka toimii samalla lailla kuin ennenkin. Paitsi että joku koodari on tehnyt muutaman kuukauden töitä koodimuunnoksen kanssa.

Toivottavasti Autodesk tajuaa, että heidän ilmoitustensa perusteella on jouduttu tekemään päätöksiä siitä, miten omien apuohjelmiston käyttöä voidaan jatkaa suunnittelutoimistoissa.

VBA tapauksessa se tarkoittaa koodien muuttamista toiselle ohjelmointikielelle. Ja nyt vaikuttaa siltä, että nämä muutokset ovat olleet kenties turhia?

Kenelle saan lähettää laskun?

Olemme kaikki samalla hiekkalaatikolla

Tietomallintamisessa on ainakin yksi hyvä asia. Tai ainakin tuo asia kannattaa ymmärtää. Onko se hyvä vai ei, se on jokaisen henkilökohtaisesti valittava.

Tämä asia on:
Olemme kaikki samassa veneessä. Teemme yhteistä työtä muiden suunnittelijoiden kanssa. Kaveria ei jätetä., sitä autetaan. Ei riitä, että tehdään oma suoritus ja näytetään keskisormea muille ja ihmetellään, miksei ne ole aikataulussa.

On ymmärrettävä, millä perusteilla ja miten toinen suunnitteluosapuoli suunnittelee. Talotekniikkasuunnittelijan on hahmotettava, mitä rakennesuunnittelija tekee missäkin vaiheessa prosessia ja miksi. Sama asia toisinpäin.

Kunhan tietomallintamisen suunnitteluprosessi saadaan kuntoon, niin ym. asia menee viimeisillekin jäärille jakeluun. Tai siis kun prosessi on kunnossa, niin työtehtävät on määritelty ja ne on osattu laskea mukaan jokaisen eri osa-alueen suunnittelukustannuksiin.

Tulemme "törmäämään" niinkin ihmeelliseen asiaan kuin se, että joku joutuu tekemään työtehtäviä, mistä ei itse hyödy mitenkään mutta se toinen osapuoli hyötyy valtavasti. Tämä on ennenkuulumatonta nykysuunnittelussa, poislukien valveutuneet ja kokonaisuuden näkevät arkkitehdit / pääsuunnittelijat jotka yrittävät epätoivoisesti saada esim. talotekniikkasuunnittelijaa tekemänä tilatut tehtävät - tarjoamalla heille esim. leikkauksia halutuista paikoista (jotka saataisiin kyllä mallista, mutta kun ei vaan osata).

Ehdottomasti suurin hyötyjä hyvistä malleista tulee olemaan urakoitsijat. Sen jälkeen hyödyn saa kiinteistön ylläpito-organisaatio ja sitä kautta omistaja.

Kun urakoitsijat tajuavat (osa on jo hyvin tajunnut...) mitä he tulevat saamaan tiimiltä, joka on tehnyt kohteen tietomallintaen (siis ihan aikuisten oikeesti tietomalli, ei mikään 3d-kuva) niin heidän rakentamisorganisaatio ja -järjestys tulee muuttumaan.

Materiaalimenekit otetaan mallista. Työn suunnittelu tehdään mallin kautta. Asennusalueet käydään mallin kautta läpi ennen kuin yhtään putkea on oikeasti asennettu. Asennusjärjestykset selviävät tässä aluekatselmuksessa.

Aikataulu tietomallin kautta tulee mukaan heti, kun mallit on tehty siten että niiden kautta voidaan aikataulutus tehdä ja rakennusurakoitsijalla on henkilö joka sen pystyy tekemään (sekä tietoteknisesti että ammatillisesti).

Mallin kautta keskustellaan suunnittelijan kanssa, kun löytyy mallinnusvirheitä. Niin, urakoitsijat -  voin sanoa, että ette tule koskaan saamaan 100% täydellistä mallia. Mutta saatte sellaisen, jolla homman pystyy hoitamaan huomattavasti paremmin ja helpommin kuin pelkkien 2d piirustusten kanssa.

Urakoitsija tulisi saada mukaan myös suunnitteluprosessiin. Minulla ei ole mitään käsitystä, että miten se voisi olla mahdollista ennen kuin urakkalaskentasarjoja laitetaan menemään. Mutta joka tapauksessa, ainakin talotekniikkasuunnittelija tarvitsee tarkan mallin tekemiseen välillä urakoitsijan tai huollon näkemyksiä.

Jos ja kun näitä näkemyksiä ei ole, suunnittelija tekee miten parhaaksi näkee. Ne virheet korjataan sitten työmaa-aikana kuntoon.

Kun jollakin osapuolella on projektin päämääränä tilattujen töiden tekemisen välttely, niin se sekoittaa koko suunnittelutiimin pakan. Olemme kaikki riippuvaisia toisten työsuorituksista. Enää ei sprinkleriputkikaan menee suoraan käytävän keskellä, ja siitä lähtevät haarat eivät lähde suunnitelmissa kauniisti suoraan huoneen alakattoon. Nykyisessä sprinkler -suunnittelussa putki osaa väistää muuta tekniikkaa - tarpeen mukaan.

"Maailma on muuttunut", totesi erään eurooppalaisen pääkaupungin keskusta-alueelle rakennettavan musiikki-instituution rakennustöihin osallistunut putkiurakoitsija. Ja voin vakuuttaa, että hänellä riittää tähän lauseeseen kokemusta.

Viikon vinkki
- Yllätä kollega ja tee ajoissa se työ mitä hän on pyytänyt.

Viikon kuva
- kamat ojennuksessa

IFC tiedostot ja energiasimulointi

Niin helpolta kuin se kuulostaakin, on matkalla monta mutkaa edessä.

Rakennetaan softa "yhteen" ifcexport ja sitten softan "kahteen" ifcimport. Ja katso, ihme on tapahtunut - softan "yhden"  objektit näkyvät softa "kahdessa". Kaikki OK.

Paitsi että softa "kolme" sanoi, että ykkösen tuottama ifc on täyttä skeidaa.

Miten se softa kolme voi tuollaista väittää? Softa kaksi pyörittää mallia ruudulla varsin mallikkaasti, sieltä saadaan tietoja irti (esim. listattua ikkunatyypit, väliseinät jne.). Täyttä tietomallia, toteaa softa yksi: "Meidän ifcexport toimii".

Ja softa kolmen kaverit vikisevät. "Ei ne ole lukeneet speksiä. GUIDitkin on väärin luotu. Space boundaryt puuttuu. Tilanimi on kirjoitettu väärään kenttään. Seinässä on reikä ikkunan kohdalla, speksin mukaan seinän pitää olla ehjä. Eihän tässä ole edes tiloja".

Näin kenttämiehen näkökulmasta ym. tekstiä on turha kertoa arkkitehdille, kun tulee kysymys: "Missä vika, miksei mallimme mene energialaskentasoftaan sisälle? Mitä tekisin toisin?".

Ei arkkitehti pysty ym. ongelmiin vaikuttamaan juuri ollenkaan. Ainoa järkevä pyyntö on se, että käyttää ohjelmistoansa oikein, eikä lähde virittelemään mitään erikoisuuksia. Ja jos homma ei tuon jälkeen toimi, ollaan taas keskustelemassa koodaustason ongelmista, joka ei kiinnosta (eikä kuulukaan kiinnostaa) arkkitehtiä ja energialaskijaa  pätkääkään.

Jos olen pieneen päähäni saanut ongelman ytimen selville, niin se on tämä:
- jotta ylipäätänsä laskentoja voidaan suorittaa, pitää mallissa olla tilaobjekteja (eli siis vyöhykkeitä, tiloja)
- Kun tilaobjekti luodaan (klikkaamalla ehjää, ilmatiivistä seinien rajaamaa aluetta) niin se luo relaatiot ympäröiviin objekteihin, eli seiniin, oviin, ikkunoihin.
- Jos ym. relaatiot ovat kunnossa, pystyy ohjelman ifcexport luomaan ns. "Space Boundaryjä". Ne ovat normaali-ihmiselle jotain käsittämätöntä. IFC-ihmiset keksivät tuon muutamia vuosia sitten, kun ilman niitä meni vielä huonommin. SB:stä voi lukea lisää esim. ArchiCADin sivuilta.

Space Boundaryjen olemassaolo on huhujen mukaan äärimmäisen tärkeää toimivassa IFC-mallissa. Niiden avulla voidaan laskea oikeat pinta-alat esim. ulkoseinille. Niin, paitsi jos se tilaobjekti ei satukaan olemaan korkeudeltaan lattiasta kattoon. Jos se on vaikkapa alakattoon asti mallinnettu, niin toimistohuoneen yläosasta jää kaistale seinää laskennoista ulkopuolelle. Puhumattakaan siitä, että oletettavasti energialaskentaohjelmisto joutuu itse parsimaan seinän pinta-alan välilaattojen puoleen väliin, jotta saataisiin rakennusmääräysten mukainen "oikea" pinta-ala laskentoihin.

Olen melkeinpä varma, että kun cad-ohjelmistot saavat implementoitua (toimivan, speksin mukaisen) space boundary -ifcexportin jollain tasolla ohjelmistoihinsa, niin sitten koodarit heittävät meille jonkun toisen, yhtä ihmeellisen ongelmavyyhdin ratkottavaksi ja seliteltäväksi. Kun se SB ei pelastanutkaan maailmaa.

Tässä ollaan siis maanis-depressiivisenä tällä hetkellä depressiivisessä vaiheessa. 10 vuoden ajan olen tämän jutun kanssa taistellut, ja välillä on ihan oikeasti ollut valoa tunnelin päässä. Nyt on taas tilanne se, että näkyy vain kierteiset rihlat piipussa - pieni neulankokoinen valopläntti keskellä. Mitä enemmän arkkitehdit oppivat mallintamaan, sitä sekavampia lopputuloksia on nähty. Malleihin tulee likaa tavaraa liian aikaisessa vaiheessa.

Toisaalta - pitääkö arkkitehdin mallin muka mennä suoraan energialaskentaohjelmistoon? Mitä jos annettaisiin arkkitehdin tehdä luomustaan rauhassa ja alkuvaiheessa projektia energialaskija ottaa "snapshotin" arkkitehdin mallista, mallintaa sen uudelleen tai korjaa sen energialaskentaohjelmistoille sopiviksi?

Olen sitä mieltä, että ajatus yhdestä emomallista on kuolemaan tuomittu. Rakennuksen malleja on useita, eri käyttötarkoitukseen soveltuvia. Arkkitehdin malli on kuitenkin se, joka määrää miten mennään eteenpäin. Sitä käytetään hyödyksi muiden alojen mallien luomiseen.

Energialaskentasoftaan toimivan mallin luominen ei ole mikään iso homma, kun se tehdään sitä varten tehdyllä geometriamallintimella. Se kuulostaa pahemmalta, kuin mitä todellisuudessa onkaan. Jos projektin suunnitteluun menee puoli vuotta ja toimiva laskentamalli tehdään muutamassa päivässä, niin se ei ole kokonaisuudessa aika eikä mikään saatuihin hyötyihin nähden.

Oi jospa eläisimme maailmassa, missä softat toimivat kuten myyjä lupaa.


Viikon vinkki:
- käytä erillistä geometriamallinninta, kun teet energia ja olosuhdesimulointeja. Näin takaat sen, että tunnet kohteen, tiedät kohteen pinta-alat ja tilavuudet sekä pystyt laskemaan sen luotettavasti kokonaisuudessaan.

Viikon kuva:
- niin lähellä mutta niin kaukana

Ilmainen Tekla BIMsight on tutustumisen arvoinen

Tekla julkaisi 14.2 ilmaisen tietomallien tarkasteluohjelmiston, nimeltä Tekla BIMsight, http://www.teklabimsight.com/ .

Softalla voidaan yhdistää mm. IFC-malleja, tuki löytyy myös perustasolla dwg-malleille.

Lahjahevosen suuhun ei saisi katsoa, mutta tällä hevosella on kyllä ihan puhtaat ja kunnossaolevat hampaat. On aika uskomatonta, että ilmaisohjelmassa on mittaustyökalu, tiedon hakutoiminnot, kommentoinnit, törmäystarkastelu (toleranssilla!) ja mikä parasta, Teklan loistava mallin paloittelutyökalu (siis leikkaustyökalu).

Kaikkea muutakin löytyy, malleja voidaan jopa siirrellä, kun joku osapuoli ei vaan osaa laittaa malliaan absoluuttiseen korkoon tai ei usko, että kaikilla pitää olla sama origo.

Ohjelman ulkoasu on edistyksellinen, se laajentaa windows -koneiden totuttua käyttöliittymäkulttuuria omintakeisilla, mutta toimivilla ratkaisuilla. Aluksi tuntuu, että onpa vaikea löytää tietoa mallien sisältä, mutta kun tajuaa käyttölogiikan, ihmettelee miten on aikaisemmin pärjännyt. Navisworksin find häviää 10-0 (no, onhan siellä nyt enemmän oikeasti toimintoja, mutta lahjahevostahan tässä arvostellaan...).

Ohjelma käynnistyy 10 kertaa ilman rekisteröitymistä, mutta sen jälkeen Tekla haluaa Sinut. Eli rekisteröityminen on edessä - sen toisaalta kyllä hyväksyykin.

Ihan kaikkeen ohjelmakaan ei pystynyt, eli parilla testimallilla sain muistin loppumaan (ei varmaan osannut käsitellä 64bit muistiavaruutta), mutta Teklan sivuilla sanotaan tähänkin tulevan kohta päivitys.

Nopea törmäysten tarkastelu onnistuu hienosti, onneksi mitään raporttia ei voida (yhtä helposti) tehdä. Mallintajat alkavat jo kyllästyä Solibrin raportteihin, joissa ammattitaidoton tarkastaja painaa nappia ja tulostaa 1000 sivuisen ongelmaraportin (jossa 10 sivua asiaa).

Softa on nopea, kuten Teklan tyyliin kuuluu. Malli pyörii taidokkaasti ja kuten todettua, leikkaustyökalu kruunaa kaiken.

Koska tämä joululahja tuli pari kuukautta jälkikäteen (tai 10kk etukäteen?) niin yksi toive olisi: kun tekee leikkauksen, niin softa piirtää leikkausrajan mustana. Eli siis "mustaa" leikkauspinnan seinistä, kanavista jne. Saisiko tämän leikauspinnan jotenkin exportattua dwg-kuvaksi? Eli siis ihan 2d-leikkauspintaa tarkoitan. Olisi hienoa saada "normaaleja" leikkauskuvia mallista ilman mitään ihmeellisiä virityksiä. Niin, täällä puhuu siis Autodeskin kurjimuksessa oleva henkilö... oikeilla cad ohjelmistoilla tuo lienee arkipäivää...

DWG-kuvien tuki löytyy, mutta mallit pitää olla AutoCADin perusmokkuloita, esim. MagiCADin ääliötekniikkaa ohjelma ei ymmärtänyt. Proxygrafiikka ei liikkunut 3D:nä Teklaan asti:

Kaiken kaikkiaan paras ilmainen tietomallien tarkasteluun tarkoittu softa, mitä markkinoilla on tällä hetkellä. Ominaisuudet ovat sellaiset, että niistä olisi kenties jopa maksanut jotain. Onnittelut Teklan päättäjille tästä linjasta.

Tähän asti olen suositellut Navisworks Freedomia työmaaolosuhteisiin / mallien tarkasteluun.

Taitaa olla aika tarkastaa tämän suosituksen järkevyys.

Viikon vinkki
- Muista tallettaa projektipankkiin riittävän usein IFC-mallit, jotta työmaa pysyy ajantasalla (tai käytännössä jopa edellä) suunnitelmien päivittyessä. Jos ollaan "kädestä suuhun" tilanteessa, voi olla tarpeen tallettaa päivitetyt mallit esim. viikottain muille hyödynnettäviksi.
Muista, että revisioitujen, virallisten asiakirjaluettelossa olevian  piirustusten kiertoaikataulu voi aivan hyvin olla joku muu, kuin mallien jakeluaikataulu.

Tietomallin tilaamisen ihanuus

Nykymuodossa talotekniikan suunnittelijoilta tilataan vielä silloin tällöin "tietomalli" sen tarkemmin kertomatta, mitä sillä tarkoitetaan. Tämä johtuu aika usein siitä, että tilaajalla ei ole olemassa työkaluja tarkempaan sisältökuvaukseen.

Uudet talotekniikan tehtäväluettelot tuovat pientä apua asiaan, mutta edelleenkin jää monia asioita määrittelemättä esim. tietomallin sisällön ja geometrian tarkkuuden suhteen. Toisaalta, ei näiden määrittely ole tehtäväluetteloiden asia, vaan muiden sitä täydentävien asiakirjojen. Tarkkuustasoon ja tietosisältöön tulen tarttumaan tulevissa kirjoituksissani.

Onneksi on käynnissä muutamia kehityshankkeita, joissa tähänkin asiaan toivottavasti saadaan parannuksia jo tämän vuoden puolella. Talotekniikan suunnittelua ostettaessa tulee olla määriteltynä, mitä mallilta halutaan.
Mitä enemmän halutaan hyötykäyttöjä, sitä enemmän suunnittelija tekee työtä mallin tekemiseksi käyttötarpeen mukaiseksi.

Ensimmäiset skeptikot tässä kohtaa varmaankin ajattelevat, että: "Taas ne suunnittelijat haluavat lisää rahaa".

No, he ovat oikeassa.

Mutta kohteen maksajalle tämä ei tarkoita sitä, että käytössä olevaa kokonaisrahasummaa pitäisi suurentaa, vaan mitä suuremmalla todennäköisyydellä se laskee. Se raha (aika), mitä suunnittelijalla menee enemmän hyvän tietomallin tekemiseen voitetaan moninkertaisesti verkostomallintamisen laadun ja tietomallien hyödynnettävyyden kautta - jos niitä vain osataan käyttää rakennuttajakonsulttien tai työmaan toimesta hyödyksi.

Tässäkin suunnittelija voi ja haluaisi auttaa, mutta sehän tietäisi taas rahanmenoa...

Otetaan esimerkkinä yksi pieni asia, jonka jo jokainen tietää - materiaaliluettelot. Sähkösuunnittelijat ovat jo vuosia toimittaneet nippeliromuista määrälistat laskentaan. Ei tule yhtään kohdetta mieleen, että oltaisiin jälkikäteen tultu sanomaan, että esim. kytkimiä oli liian vähän listoissa - urakka meni sen takia miinukselle.

LVI-puolella massalistojen teko on tietomallinnuksen kautta ollut mahdollista päälle kymmenen vuotta. Edelleenkin on kohtalainen harvinaisuus, että päätetään käyttää massalistoja. Mitä suurempi kohde, sitä varmemmin niitä ei käytetä.

Ja sitten siihen, minkä kaikki tietää: LVI-suunnitelmat lähtevät kahdeksalle urakoitsijalle, joista viisi laskee ne tarkemmin, eli mittaa paperikuvista putkimetrit, laskee patterit ja iv-päätelaitteet, hanat, pesualtaat jne. Nämä laskentakustannukset menevät projektin päälle. Sekä 10 edellistä laskentaa, joita ei olla saatu "kiinni".

Minulla ei ole heittää mitään faktaa, mutta voisin kuvitella, että suunnittelija laskuttaa huomattavasti vähemmän massalistojen teosta kuin urakoitsija voittamalla projektin ja laittamalla siihen 10 ohimenneen projektin kustannukset.

Voittaneella urakoitsijalla on tietokoneellaan tuon jälkeen se matemaattinen minimimäärä rautaa, mitä kohteen tekeminen vaatii. Mukana ei ole hukkaprosentteja, eikä tietoa siitä, minne rauta asennetaan - iv-konehuoneeseen, korkealle kattoon, ahtaaseen putkitunneliin tms. Eli tottakai lopullisen hinnan muodostukseen tarvitaan urakoitsijan oma ammattitaito tulkita massalistaa.

Mutta on se silti eria asia ottaa metrit ja kappalemäärät valmiista listasta kuin lyödä käsi johonkin kohtaan 1:50 kuvaa ja todeta mielessään: "kymppitonni".

1990 luvun puolivälissä luultiin, että kohta aletaan käyttää massalistoja koska ne saadaan cad-kuvista. Täällä ainakin odotellaan edelleen asian tuloa "normaaliksi" toimenpiteeksi lvi-urakkatarjouksia laadittaessa. Asia jää yleensä kiinni siitä, että "tehdään kuten ennenkin". Rakennusalan uudistusmielisyys ja innovatiivisyyshän on kaikkien tiedossa.


Viikon vinkki:
- "Suunnittele ensin, mallinna vasta sitten".
Tarkoittaa suomeksi sitä, että tee luonnosvaiheessa riittävästi leikkauksia, joiden kautta mietit TATE-järjestelmien toimivuuden ja reitit. Vasta sitten, kun päärungot on mietitty, voidaan mallinnus tehdä kunnolla.

Senaatin BIM-ohjeistuksen päivitys alkaa vihdoinkin!

Senaattti-kiinteistöjen vuonna 2007 laaditun tietomalliohjeistuksen päivitysprojekti on alkanut, http://www.rakennustieto.fi/cobim/.

Hienoa, että ohjeistuksen päivitys on saatu liikkeelle, pienillä täsmennyksillä ja uusillakin asioilla saadaan kurottua kiinni muiden maiden ottamaa pientä etumatkaa. Tai ainakin voimme esitellä hienoa ohjeistusta siitä, miten asioita "pitäisi tehdä"...

Tekla tempaisee

Kannattaa käydä katsomassa sivuilla http://www.teklabimsight.com oleva animaationpätkä Teklan tekemästä ilmaisesta yhdistelmämallien tarkasteluohjelmistosta.

Ohjelma sisältää ominaisuuksia, joita ollaan osattu odottaa ainoastaan maksullisissa versioissa.

Julkaisupäivä on kuulemma 14.02.2011. Kunhan saan softan käsiini, kirjoittelen tänne ensifiilikseni softasta.

Oletettavasti tuosta ei kuitenkaan mitääs Solibrin tai Naviksen tappajaa ole tulossa (ainakaan verrattaessa maksullisiin versioihin), mutta tutkitaanpa asia ennenkuin hutkitaan...

Reikäkuvien teko tietomallintaen

Joissakin ohjelmistoissa on mahdollisuus käsitellä reikätietoa tietomallipohjaisesti. Tämä ei oikeastaan tarvitse mitään erityistä sovellustakaan, jos cad-ohjelmistolla pystyy tekemään sylintereitä ja laatikoita, niin asia onnistuu viritysten kautta.

Mm. MagiCADissä on reikäkuvasovellus, jolla voidaan luoda reikävarausobjektit taloteknisestä verkostosta. Reikävarausobjekti tietää, mihin suunnittelualaan se kuuluu, se sijaitsee oikeassa paikassa cad-avaruutta ja se voidaan siirtää IFC:n avulla rakennesuunnitteluohjelmistoon, esim. Teklaan.

Käsittämätöntä kyllä, Teklassa ei voida "porata" seinään reikää reikävarausobjektin avulla, mutta kaiketi tuo ominaisuus on sinne jossain vaiheessa tulossa. Niin ilmeinen sen tarve on.

Tässä purtavaksi uusi reikäkuvien suunnitteluprosessi, jota tullaan soveltamaan eräässä hankkeessa:

- Rakennesuunnittelija toimittaa kerroskohtaisesti perinteiset reikäkuvapohjat, joko 2D:ssä tai 3D:ssä. Jos toimitus tapahtuu 3D:ssä, niin yksinkertaisissa kohteissa voidaan MagiCADillä tehdä rei'itys automaattisestikin. Tämä on kuitenkin aika riskialtista, pitää muistaa, että tietokone on tyhmä kuin saapas ja ei osaa ajatella monimutkaisia asioita, jota reikäkuvien tekeminenkin on.

- Talotekniset suunnittelijat ottavat nämä kuvat omiin reikäkuviinsa ja tekevät näihin kuviin reikävarausobjektit hyödyntäen suunniteltuja verkostoja. Näin reikävarausobjektien korko saadaan juuri oikeaksi - kanavaa, putkea tai kaapelihyllyä voidaan käyttää apuna reikävarauksen luomisessa.
- Talotekninen suunnittelija tarkastaa yhdistelmämallin kautta, että reikävarausobjektit ovat oikeissa paikoissa.
- Talotekninen suunnittelija tekee reikävarausobjekteista IFC:mallin, (absoluuttisessa korossa) ja toimittaa sen rakennesuunnittelijalle. Huomioitavaa on, että yhtään mittaviivaa ei piirretä taloteknisen suunnittelijan toimesta, he tekevät vain reikävarausobjektit oikeaan paikkaan cad-avaruutta.
- Rakennesuunnittelija ottaa iFC:n sisälle omaan ohjelmistoonsa, tarkastaa reikien sijainnit ja kommentoi ne rei'ät, joita ei voi tehdä. Talotekninen suunnittelija siirtää varausobjektit ja verkostot tämän jälkeen oikeisiin paikkoihin ja tekee uuden IFC:n rakennesuunnittelijalle.
- kun rei'ät ovat löytäneet paikkansa, rakennesuunnittelija tekee niistä 2D-reikäkuvat. Rakennesuunnitelija laittaa ne mitat, mitä pitää kuviin laittaa sekä käyttävät reikävarausobjektissa olevaa tietosisältöä hyödyksi esim. siitä, kenelle urakoitsijalle rei'ät kuuluvat.
- nämä kuvat toimitetaan talotekniselle suunnittelijalle joka tarkastaa niiden oikeellisuuden. Tämän jälkeen reikäkuvat lähtevät jakoon.

Tässä proseduurissa siis rakennesuunnittelijalle tulee perinteiseen prosessiin nähden uusia työtehtäviä, mutta hyötyjen saaminen on ilmeistä. Vain rakennesuunnittelija tietää, mitkä ovat "tärkeitä" reikiä rakenteiden kannalta ja mitä eivät. He osaavat ottaa mitoitukset oikeista paikoista valmistavaa teollisuuttakin ajatellen.

Ja mikä parasta, rei'ät näkyvät oikeissa paikoissa myös yhdistelmämalleissa. Jos kanava menee rei'än vierestä, voidaan olla kohtalaisen varmoja siitä, että sitä pitää siirtää - tehdäänkö siirto työmaalla vai IV-suunnittelijan mallissa, riippuu tietomallintamisen geometriatoleranssista. Mallintamisen toleranssi onkin sitten jo uuden blogin asioita.

Viikon vinkki:- tee reikävarausobjektit tyhjään dwg-tiedostoon, jonne otat viitekuviksi rakennemallin sekä talotekniset järjestelmät. Liitä tämä kuva MagiCAD HPV projektiin, jotta voit tehdä IFC-tiedostot oikeilla absoluuttisilla korkotiedoilla
- Reikävarausobjekti kannattaa tehdä hieman seinää tai lattiaa paksummiksi, jotta ne erottuvat yhdistelmämalleissa.
- muista tarkistaa yhdistelmämallin kautta ennen lähetystä rakennesuunnittelijalle, että rei'ät ovat asettuneet oikeisiin paikkoihin / korkoihin.

Viikon toive:- miten arkkitehdit saisi laittamaan wc-istuimet ja lattiakaivot ontelolaattojen ontelon kohdalle, eikä aina kannaksen keskelle...? Pitäisi mielestäni olla mahdollista nykyohjelmistoilla.

Viikon kuva:
Näyttää niin yksinkertaiselta, mutta vaatii todella vaikean prosessin läpikäynnin

Yhdistelmämallien teko talotekniikan näkökulmasta

Normaalissa, oikein organisoidussa tietomalliprojektissa syntyy väkisinkin yhdistelmämalli. Yhdistelmämalli sisältää kaikki tekniikan alat ja sen perusteella voidaan rakennukseen tutustua virtuaalisesti ennen kuin ensimmäistäkään asennustyötä on aloitettu.

Ilman yhdistelmämallia ei voida tuottaa suunnitelmia, jotka ovat keskenään ristiriidattomia. No, enpä ole suunnitelmien osalta ristiriidatonta kohdetta vielä koskaan nähnyt - mutta yhdistelmämallin avulla voidaan varmistua siitä, että päälinjat ovat kunnossa. Aina tulee olemaan pieniä, merkityksettömiä törmäilyjä. Pitää osata nähdä metsä puilta.

Suunnittelussa ja niiden arvioinnissa pitää muistaa, että suunnittelu on muuttamista. Hanke- ja ehdotussuunnitteluvaiheen aikana tehdään isoimmat ratkaisut järjestelmistä, energiankulutuksesta ja rakennuksen ylläpidon aikaisista kuluista. Yleissuunnitteluvaiheessa varmistetaan, että hanke on toteutettavissa valitun ratkaisun mukaisesti. Toteutussuunnittelun yhteydessä nämä asiat konkretisoituvat ja kohteesta tehdään yhdistelmämalli.

Yhdistelmämallin teko ei ole siis todellakaan kertasuoritus. Jos yleissuunnitteluvaiheessa asioita vielä pyöritellään liikaa, tilat muuttuvat, käyttäjältä ei ole osattu kysyä, mitä he haluavat tai käyttäjää ei ole vielä edes tiedossa, niin kaikki tämä sähläys kostautuu toteutussuunnitteluvaiheessa. Kun suunnittelija ei tiedä, mitä hänen pitäisi tehdä, mutta aikataulussa näkyy toteutussuunnittelun loppumispäivä, jolloin mallit ovat "valmiita", niin on selvää, että talotekniset järjestelmät elävät viimeiseen päivään asti suunnittelijoiden ruudulla.

Se aiheuttaa sen, että verkostot ovat ristissä keskenään. Ketään ei pysty hallitsemaan kaaosta, tällainen projekti menee selviytymistaisteluksi. Ratkaisut pitää olla tehtynä siis yleissuunnitteluvaiheen lopussa, jonka jälkeen suunnittelun perusteita ei enää saisi muuttaa.

Yleissuunnitteluvaiheessa taloteknisen suunnittelijan tulee tehdä perinteiset 2D-leikkaukset peruspaikoista (käytävät, kuilujen ulostulot jne.). Näiden avulla voidaan kohde mallintaa. On siis huomioitava perusasiat: suunnitellaan ensin, sitten mallinnetaan. On täysin järjetöntä ajatella, että ei tehdä leikkauksia alkuvaiheessa koska ne voi ottaa sitten valmiista mallista. Miten se malli saadaan tehtyä, kun ei ole tietoa, mihin korkoihin ja paikkoihin verkostot asennetaan?

Tulen palaamaan tässä blogissa vielä useasti yhdistelmämallien tekoon, se on kuitenkin selvästi näkyvin suoritus joka tietomallintamalla saadaan aikaiseksi. Lisäksi työmaakäytössä yhdistelmämalli on osoittautunut ammattilaisten käsissä erinomaiseksi työvälineeksi.

Viikon vinkki:- Kun tehdään 3D-suunnitelmia, ei ole olemassa mitään muuta korkotietoa kuin absoluuttinen korko. Kaikki 3D-informaatio tulee luovuttaa toiselle osapuolelle absoluuttisessa korossa. Tasokuvien korkomerkinnät tulee olla absoluuttisia, ei lattiapinnasta mitattuja. Jos laitetaan mitta esim. lattiapinnasta, niin pahimmassa tapauksessa se mitta otetaan puolalaisen asentajan toimesta ontelolaatan pinnasta - pintavalu puuttuu ja kanavat ovat 10cm liian alhaalla.


Viikon kuva:
Kuka vielä sanoo, etteikö työmaa asentaisi verkostoja siten, kuten yhdistelmämallissa ne ovat...

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