lauantai 16. toukokuuta 2015

Bigroom vs. Knotworking

Hävettää myöntää, mutta luin vasta nyt tämän Cradlen paperin:

https://helda.helsinki.fi/bitstream/handle/10138/42897/ICCEPM_2013_KNOTWORKING_re_submitted.pdf?sequence=2

Olin mukana ko. kohteen tiimissä nro 1, ja Helsingin Yliopiston tutkijoiden havainnot ovat kyllä ihan paikkaansapitäviä.

Vahvistan sen havainnon, että pikkuprojekteihin sopii paremmin Solmu ja Bigroom on isoihin kohteisiin, luokkaa 300M€ tai suuremmat.

Jos tehdään Bigroom, siellä on oltava todellakin paikalla. Ei riitä, että ollaan pari päivää viikossa hengessä mukana. Silloin pitää miettiä hankkeen henkilörakenne / vaiheistus huomattavasti tarkemmin. Solmussa pystyy yleensä löytämään oikeat henkilöt paremmin paikalle.

Solmutyöskentely tyhjentää takin totaalisesti parin päivän jälkeen, sinusta on täysin imetty mehut. Pitää skarpata koko ajan ja olla aktiivinen. Ei sovi kaikille persoonallisuuksille.

Mutta, kun on oikea porukka, tehdään parissa päivässä kuukauden duuni.

Vielä kun saisi tilaajan ja rakennuttajan mukaan solmuun. Lopputulos olisi paljon parempi.


Viikon kuva:


lauantai 18. huhtikuuta 2015

Historiaa: MagiCADin painetasolaskelmat

Tasaisin väliajoin minulta kysellään, miten painehäviölaskelmat tehdään MagiCADissä. Jotenkin on aistittavissa, että paineen käyttäytyminen suljetussa verkostossa on mysteeri heille.

Rippasin tähän blogiin viestin vuodelta ~2001 tjsp. Hauska lukea sen aikaisen MUGF -sivuston kirjoituksia (MagiCAD User Group Finland).

Tietosisältö on suurinpiirtein OK vielä  ~14 vuoden tietomallinnuksen jälkeenkin.

Samaa juttua on myös täällä:
http://tietomalli.blogspot.fi/2011/02/nuoruuden-uhoa.html

Alkuperäinen viesti:
http://web.archive.org/web/20040610095309/http://www.mugf.net/

---
/MUGF Start

12. Miten löydän painetasollisesti virheellisen komponentin verkostosta?


Tehtäessä tasapainotus verkostoon, voi painetaso joskus olla järjettömän korkea. Vielä en ole törmännyt yhteenkään projektiin, jossa magi olisi laskenut painetason liian suureksi ohjelmavirheen vuoksi. Aina on verkostosta löytynyt jokin mallinnusvirhe, joka aiheuttaa painetason nousun liian suureksi.
Kaikki me ammattilaisethan tiedämme, että jos lämmitysverkostossa vaikeimman linjan linjasäätöventtiilille tulee ~60kPa painehäviö, niin se ei ole sen venttiilin vika, vaan jossakin muualla verkostossa on jokin komponentti, joka aiheuttaa suuren painehäviön. Linjasäätöventtiili vain tasapainottaa verkoston tähän olosuhteeseen. Magi ei siis osaa ajatella, se tekee työtä tyhmänä laskukoneena.

"Flow Route Examination" on loistava käsky verkostojen tarkistuksessa. Sarakkeesta "dpconn" nähdään liitoksen painehäviö. Lisäksi systeemivalikossa voidaan asettaa hälytysrajat liian suurille komponenttien painehäviöille.
Tasapainottamalla verkosto ja laittamalla ruksi kohtaan "Show the most significant route" saadaan magi piirtämään ruudulle reitti vaikeimmalle haaralle. Tätä kannattaa käyttää kun tarkistetaan verkosto. Jos verkostossa on joku liian ahdas paikka, niin se saadaan selville tämän reitin varrelta "Flow Route Examination" käskyllä. Huomaa, että käyttövesipuolella magi piirtää omat reitit kylmälle ja lämpimälle vedelle.
Tässä eräitä tarkastuskohteita, jonka avulla voi löytyä verkoston mallinnusvirhe:

1.  Patteriventtiilien käyrästöt
Jos nestevirta on liian suuri patteriventtiilille, niin käyrästö menee "tappiin" ja aiheuttaa venttiilillä liian suuren painehäviön. Esim. porrashuoneiden patterit mitoitetaan välillä erittäin suurelle teholle, jolloin yksi DN20 venttiili ei aina riitä.
Suosittelen kaikille vertailemaan eri valmistajien patteriventtiilien käyrästöjä - niissä on todellakin eroja. Varsinkin erittäin pienten nestevirtojen käyrät voivat tuottaa yllätyksiä. Jos pikkupatterit eivät mene tasapainoon, kannattaa kokeilla Danfossin RA-N tai T&A:n TRV-1S venttiilejä.

2.  Vääränkokoiset linja- ja sulkuventtiilit
Varsinkin IV-verkoissa kun piirtelee putkistoa esim DN40 putkella (siis ennen mitoitusta) ja tekee IV-koneiden kytkennät valmiiksi - eli laittaa venttiilit putkistoon kiinni - voi tapahtua virheitä.

Kun tekee putkistomitoituksen niin vaikka putki suurenee, venttiili ei välttämättä suurenekaan. Tämä johtuu siitä, että jos on käyttänyt esim. T&A:n STAD -linjasäätöventtiiliä; venttiilin suurin koko on DN50, jonka jälkeen pitää käyttää STAFfia. Magi ei tätä tietenkään tajua, vaan jos putki suurenee DN40 -> DN100, niin tässä DN100 putkessa on DN50 kokoinen venttiili kiinni. Se on siis suurin koko, jonka ohjelma löytää tietokannastaan.
Sama juttu pätee sulkuventtiilille, eli jos on käyttänyt alussa väärän mallista venttiiliä, niin se tasapainotettaessa aiheuttaa verkostoon suuren painehäviön

3.  Kanttikanavien äänenvaimentimet
Kanttikanavien äänenvaimentimissa pitää olla tarkkana, sillä jos äänenvaimennin on liian pieni, niin se aiheuttaa suuren painehäviön verkostoon. Magi tekee aina kanavan kokoisen vaimentimen. Varsinkin Swegonin PLG -vaimentimen kanssa pitää olla tarkkana. Vaikka vaimennin onkin ominaisuuksiltaan hyvä, pitää LVI-suunnittelijan tietää, minkä kokoinen vaimennin verkostoon pitää laittaa - ohjelma ei sitä osaa valita. Eli kanttikanava pitää suurentaa ennen vaimentimen laittoa, jotta kanavanopeus saadaan "oikealle" tasolle.

4. Komponentit, joille on mallinnettu käyrästö 
Magin putkistokomponenttien takana on tuskastuttavan usein esimallinenttu käyrästö, joka siis seuraa nestevirtaa ja laskee itse painehäviön. LVI-suunnittelijalle tämä aiheuttaa harmaita hiuksia, sillä suunnitteluvaiheessa emme tiedä, minkä valmistajan tuotteen urakoitsija kiinteistöön valitsee. Siksi pitäisi olla mahdollisuus antaa aina itse komponentin painehäviö virtaamasta riippumatta (Lock dp, kuten linjasäätöventtiileissä)
Nyt se ei siis ole vielä mahdollista (magiversio 2001.6). Erikoiskomponentit, kuten mutataskut, 1-, 2- ja 3-tieventtiilit pitää käydä katsomassa mitoituksen jälkeen, että mille arvolle magi ne mitoitti. Jos lopputulos ei miellytä, pitää komponentin kokoa muuttaa ja toivoa, että päästään sellaiselle tasolle, kun halutaan. Tietenkin voi mallintaa itse juuri sopivan komponentin, mutta se vie yleensä liikaa aikaa eikä siihen "viitsi" ryhtyä.

5. Open ends
Avoimet päät löytää helposti ottamalla "Part Property Line" ja aktivoimalla kohta "Open ends". Tekstikoko kannattaa laittaa kohtalaisen suureksi, esim 400. Lisäksi kikka nro 13 auttaa huomattavasti.

6. Huono LVI-suunnittelu
Ammattilaista tarvitaan edelleen. Huonosti suunniteltua verkostoa ei pystytä pelastamaan edes magilla...

---
/MUGF end



Nuoriso, nouskaa omalle tasollenne. Tehkää maailma, jossa haluatte olla 20v päästä.



Viikon kuva.

Muistaakseni Swegon Gold v.2000 jotain + ahdas paikka



torstai 2. huhtikuuta 2015

Big Room

Sana Big Room on löytynyt kiitettävällä frekvenssillä niissä tarjouspyynnöissä, joissa on panostettu yhteistyön mahdollistamiseen suunnittelu- / rakentamisprosessin aikana.

Mielestäni on havaittavissa, että tuo sana tarkoittaa eri asiaa eri henkilöillä. Sama juttu, kun puhutaan tietomallintamisesta ja "tietomallintamisesta". Kaksi henkilöä voi puhua tunnin keskenänsä huomatakseen, että tarkoittavat aivan eri asiaa, puhe etenee kuitenkin samoilla termeillä.

Tässä oma mielipiteeni siitä, mitä Big Room tarkoittaa.

Big Room on avokonttori, jossa työskentelee virtuaalinen yritys.

Big Roomiin tullaan aamulla töihin ja sieltä lähdetään kotiin työpäivän loputtua.

Big Roomissa on useiden eri firmojen henkilöitä työssä.

Big Roomin vieressä on rakennettava kohde.

Big Room ei ole työpaja. Big Room ei ole Solmutyöskentelyä ( [c] HY Cradle)

Big Roomissa voi olla työpajoja. Big Roomissa voi olla Solmutyöskentelyä

Big Room ei ole iso neukkari.

Tuon tämän asian esille, sillä vaikuttaa siltä, että normaaleja työpajoja aletaan sekoittaa Big Room työskentelyyn. Pidetään työpajat työpajoina ja yhteisissä tiloissa tehtävä työnteko erillään toisistaan.

Ym. asian sekavuuteen vaikuttanee myös se, että rakennusalalla on kokemusta vielä vähän todellisesta Big Roomista, siis siitä, missä mukana on myös urakoitsija eikä pelkästään tilaaja ja suunnittelijat. Infralla tämäkin asian on jo koeponnistettu sekä hyväksi havaittu.

Allianssin kehitysvaihe vaikuttaa olevan selvästikin työpajatoimintaa - ja hyvä niin. Parin päivän pyrähdyksiä jossa on firmojen ykkösketju tekemässä suuret linjat kuntoon. Sitten mennään omalle toimistolle ja tehdään sovitut asiat + valmistellaan seuraavan työpajan agenda.

Kun projektissa päästään eteenpäin ja aletaan tehdä toteutussuunnittelua, vaihtuu porukka ja yhteistyö muuttuu aktiivisemmaksi - läsnäoloa tarvitaan enemmän.

Talotekniikalle on erittäin tärkeää, että Big Roomissa on mahdollista tehdä myös muiden kohteiden suunnittelua. Vaatii erittäin ison kohteen, että projektinvetäjä olisi 100% siinä kiinni. Mallintavalle suunnittelijalle se ei kuitenkaan ole ongelma, ajankäyttö kohdistuu aktiivisesti kohteeseen.

Big Roomin kokoukset / työt tulee aikatauluttaa. Pitää sopia vakiokokousajat ja kuka on paikalla minäkin päivänä. Mitä ylemmälle hierarkiassa mennään, sitä vähemmän he ovat läsnä. Kun ylätason kaverien kokoustarve kartoitetaan, niin heidän työpanos saadaan osumaan täsmäiskuna aktiiviselle kohteelle.

Big Roomin tekninen varustus ja laajuus tulee aiheuttamaan alussa varmasti keskustelua. Jotta työskentely on mahdollista erikseen rakennetussa uudisrakennuksessa (malli: työmaatoimisto + vähän enemmän) tai lähistöltä löydettävissä olevassa tyhjässä kiinteistössä, sinne pitää rakentaa tietotekninen ympäristö.

On huomioitavaa, että projektipankkia ei Big Roomissa tarvita. Työskentely-ympäristö on yhteinen, tiedostot ovat hallinnassa kuten firmojen omilla servereillä on totuttu työskentelemään. Tarvitaan oikea dokumenttienhallintajärjestelmä tai ainakin yhteisesti sovittu logiikka tiedostojen tallentamiselle.

Tietotekniset asiat ovat kuitenkin helpoin asia, sillä vaikein on sosiaalisen aspektin huomioiminen. Miten yhdistää toisilleen tuntemattomat henkilöt toisiinsa - firmarajojen yli? Tiimihengen luominen vaatii monta illallista,  jääkiekko-ottelua ja museossa käyntiä.

Tietoteknisen ympäristöön liittyviä asioita ovat ainakin:
- Sisäverkko Wifillä on välttämättömyys
- Verkkotulostimet, NFC:llä, pilvitulostuksella
- Sisäinen tiedostopalvelin. Onko NAS purkki vai jotain ammattimaisempaa
- Pilvipolitiikka. Onko Google Drive/Dropbox/OneDrive/Box mahdollista käyttää? Tietoturva? Vai luodaanko esim. OwnCloud?
- Mallien jakaminen, tiimityöskentely (Tekla, Revit, ArchiCAD) (onneksi tämä ei ole edes mahdollista MagiCADillä tai CADSsillä...)
- Missä mallit fyysisesti ovat? Missä ovat natiivit "äitimallit"?
- Virallisen yhdistelmämallin sijainti Big Roomin serverillä?
- Dokumenttienhallinta? Projektipankit?
- Etätyöskentelyn mahdollistaminen. VPN vai Citrix?
- VPN: helppo
- Citrix: tietoturvallinen, personoitu, skaalautuva, paras ja kallein
- Videoneuvottelujärjestelmä, Lync vai jotain muuta?
- Smartboardeista plussaa. Ja varsinkin, jos niitä osaa käyttää muunakin kuin videotykkinä.
- Screenejä seinillä, jossa pyörii kohteen mittarointitietoja; ollaanko taloudellisessa tavoitteessa, mitä kokouksia on tulossa, mihin asiaan tulee keskittyä erityisesti, koska on seuraava sauna-ilta...
- Screeni, jossa kerrotaan kohteessa työskentelevistä ihmisistä, nimi, kuva, toimenkuva jne.
- Screeni, jossa pyörii kohteen virallinen yhdistelmämalli
- Palautescreeni, jonne voi nimettömänä tai nimellä antaa kommentteja kohteen etenemisestä, parannusehdotuksia jne.
- Kohteen www-sivut, infokanava, intra, blogi, wiki tms.


Lisäksi tulee huomioida:
- Vartiointi, hälytykset
- Tietoturvallisuus
- Tilantarve, osa porukasta on paikalla 1 pvä / vko, osa 3 ja joku aina.
- Kaikki neukkarivarustus pyörillä (isoilla). Pöydät / tuolit liikuteltavia.
- Big Roomin layout tulee muuttumaan pari kertaa työn edetessä. Alussa on hyvä sekoittaa eri suunnittelualoja, lopussa on hyvä ryhmittää samanhenkinen porukka yhteen kasaan.
- Neukkareita, hiljaisia huoneita jne. tarvitaan aina
- Min. yksi oikeasti iso neukkari.
- WC + keittiö olisi kiva
- Last Plannerille iso seinä
- Käyttäjien osallistuttaminen
- Käyttäjille tila, jossa he voivat käydä tutustumassa kohteeseen. "Showroom".


Kun kaikki ym. jutut laskee euroiksi, ollaan helposti kuusinumeroisessa luvussa, eikä ensimmäinen numero ole välillä 1-3.

Se ei tunnu missään, jos kohteen hintalappu on miljardi.

Viikon kuva:

Mittarointia ameriikan malliin


keskiviikko 25. maaliskuuta 2015

BuildingSMART Spain julkaisi BIM vaatimukset

Täytyy sanoa, että pari kertaa hieraisin silmiä, kun sain vinkin näistä sivuista:
http://www.buildingsmart.es/index.php/ubim/documentos-ubim
(edit 27.3.2015: taitaa löytyä nyt täältä: http://www.buildingsmart.es/bim/gu%C3%ADas-ubim/ )

Kohtalaisen tutun näköistä tekstiä, sana COBIM löytyy myös sisällössä mainittuna.

Sekin on hienoa soveltamista, että Espanjalaiset levittävät vaatimuksia GNU-lisenssin alaisuudessa... ja ovat samalla copyrightanneet bim-vaatimuksensa:
"Derecho de Autor © 2014 BuildingSMART Spanish Chapter"

En olisi koskaan uskonut, että suomalaisten tapa toimia rakennushankkeissa kelpaa myös Espanjan rakennusmarkkinoille... pitänee käydä tutustumassa uuteen markkina-alueeseen.

Kohtalaisen iso projekti tämä on pitänyt olla, sillä co-authoreita löytyy yli 80 henkeä



perjantai 6. helmikuuta 2015

Materiaalilistat urakkalaskentaan

Olen vetänyt vuoden verran buildingSMART Finlandin alaista TATE-toimialaryhmää. Aloitimme viime vuonna ja katsoimme, alkaako toiminta lentää.

Vielä ollaan remmissä, porukkaakin alkaa ilmaantua ympärille lisää ja lisää.

Viime vuonna teimme mm. www-kyselyn TATE-toimialan tietomallintamisesta. Kyselyyn osallistui 193 henkilöä, kiitos siitä. Tämä kysely tullaan tekemään uudelleen toivottavasti  syksyllä 2015. Toivon vahvempaa osallistumista urakoitsijoilta ja tilaajilta.

Tämän vuoden tehtävälistalla ykkösenä on ikuisuusaihe:
Materiaalilistat urakkalaskennan käyttöön.

Yli 20 vuotta on ollut mahdollista tuottaa TATE-suunnitelmista massalistat, mutta niiden käyttö todellisuudessa on lapsen kengissä.

BuildingSMARTin piirissä on hieno tilanne; mukana on myös tilaajien toimialaryhmä. Uskon tämän ryhmän ratkaisevan sopimustekniset ja juridiset asiat. Ne eivät ole ongelmia, ne eivät ole haasteita. Ne ovat asioita, jotka on ratkaistava ja selvitettävä pelisäännöt eri osapuolille. Ei rakettitiedettä, pelkkää asioiden sopimista.

Materiaalilistojen käyttöä urakkalaskennassa on yritetty monesti, ja tämä on yksi yritys muiden joukossa. Toivon todella, että eri intressiryhmät löytävät yhteisen sävelen ja me suunnittelijat saamme toimittaa urakointiin tietoa, jota he tarvitsevat ja joka syntyy meillä suunnitelmien sivutuotteena - ilman mitään sen ihmeellisempää lisätyötä. Vaade on vain se, että YTV2012 Osa 4:sta noudatetaan. Peruskauraa.

En missään nimessä halua uskoa kuulemaani kommenttia, että: "Paras tilanne on, kun joku on laskenut väärin". Ei voi olla nykymaailmassa näin (tuostakin on kyllä jo 10v aikaa). Kukaan täysijärkinen ei voi luulla, että vinguttamalla urakoitsijoita saa sen lopputuloksen, jota on halunnut / omat esimiehet ovat vaatineet käyttäjien toiveiden perusteella.

En minä, eikä mielestäni kukaan, joiden kanssa olen asiaa ihmetellyt pysty ymmärtämään sitä, että urakoitsija mittaa rullalla / mittatikulla metrejä piirustuksista kun antaa tarjousta. Toivon todella, että tuo ei ole totta vuonna 2015, mutta taidan tietää, että se on totta... rakennuttaja maksaa tämänkin työn. Jos yksi kymmenestä lasketusta kohteesta jää urakoitsijan haaviin, niin ne 9 muuta laskentaa näkyy voittaneen kohteen hinnassa.

Kuten todettua, massalistojen tuottaminen ei ole ollenkaan tekninen haaste. Kunhan sovitaan, mitä tietoa tuotetaan, mikä on sen tarkkuustaso eri suunnitteluvaiheissa ja millä alkutiedolla se on tuotettu.

Ratkaistavat asiat liittyvät juridiikkaan. Mitä YSE sanoo vastuista, miten toimitaan, kun materiaalilistat eivät pidäkään 100% paikkaansa (eivät pidä muuten koskaan). Kuka vastaa mistäkin? Missä menee vastuurajat? Minkälainen sopimustekniikka tarvitaan? Miten tehdään plus/miinuslistat, miten kompensoidaan muutokset?

Pääkysymys on, miten vastuut jaetaan? (Arvatkaa, antaako Allianssi / IPD tähän vastauksen...)

Tiedän, että näistäkin asioista on jo olemassa ratkaisuja.

Nyt ne pitää vain kirjoittaa auki.

Viikon vinkki:
Osallistu buildingSMART Finlandin toimintaan:
http://buildingsmart.fi/jaseneksi-hakeminen


Viikon kuva:
Rullaa'ti rullaa rallallallallei









perjantai 23. tammikuuta 2015

Talotekninen suunnittelija + Arkkitehti

Välillä tuntuu, että me talotekniset suunnittelijat olemme arkkitehdin pahimpia vihollisia.

Oikeasti me haluaisimme olla heidän parhaita kavereita ja auttaa heitä tekemään parasta mahdollista arkkitehtuuria parhaimmalla mahdollisella elinkaarikustannuksella, käyttäjien viihtyvyydellä sekä sisäympäristöolosuhteilla.

Ehdotussuunnitteluvaiheessa kerromme TATE-tilavarausten vaatimat tilantarpeet perustuen käyttäjän/tilaajan/arkkitehdin hyväksymään tilaohjelmaan.

Ja sitten ne tilatarpeet muodostuvat arkkitehtisuunnitelmiin iv-konehuoneina, iv-kuiluina, hormistoina jne.

Nämä tarpeet me tarkastamme ark-mallipäivityksen yhteydessä ja kuinka ollakkaan - yleensä sovitut konehuoneet ja kuilut ovat pienentyneet siitä, mitä ollaan sovittu keskinäisessä palaverissa.

Nyt tuli esille hieno kohde. Tämä asia kerrottiin meille selvästi etukäteen.

Lainaus pitkähköstä sähköpostiviestistä:
"HUOM!
- Olemme hieman pienenetäneet pääsuunnittelijan pyynnöstä IV-kuiluja, jotta ne mahtuvat paremmin 3.kerrokseen."

Toivottavasti eteen tulee lisää vastaavaa toimintaa.

Nyt pystymme reagoimaan asiaan ennen kuin mitään on rakennettu - tätäkään asiaa ei tarvitse ihmetellä työmaalla kun kamat ei mahdu liian pieneen kuiluun. Voimme reagoida asiaan jo suunnitteluvaiheessa (toistamiseen/kolmanteen/neljänteen kertaa.).

Rakennusala: Yhteistyötä!