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.