torstai 28. kesäkuuta 2018

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

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

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.

1.      Demo of using smart glasses with hand gestures

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.

Virtual Property – Using BIM in Facility Management

Koska uusien ajatusten löytyminen on ollut viime aikoina hankalaa, ajattelin täyttää blogiani vanhoilla jutuilla. Tässä on kierrätys numero 1/2

Alla abstract, jonka jouduin tekemäään erääseen kansainväliseen seminaariin. (Sveitsi, SIA "BIM im Praxis-Check",


Virtual Property – Using BIM in Facility Management
Tero Järvinen, Technology Director, Granlund Oy, Finland

In the Nordic countries, the first BIM models in real construction projects were in use circa 2000. Construction sites took designers’ models into use circa 2005. Subsequently, not many new breakthroughs have been made. The process has been evolving and new requirements on using BIM have been established. The contract methods nowadays support the collaboration between the client, design and general contractor (Alliance- and Integrated Project Delivery –projects).

BIM researcher and developers have also been pushing models to the Facility Management-phase. The work has been more or less “pushing with rope”. Building owner organisations have not been very interested in that topic. However, it seems like developers’ efforts are now succeeding and building owners have an interest in knowing how BIM can help their business.

Using BIM models in Facilities Management is the next logical step after their use for design and construction sites.

Now we are about to take BIM models in use at FM. The task is not so easy. Facilities Management means more than as-built models. Those in the construction business too often do not understand those in the FM business and vice versa. Construction sites are delivering as-built data and FM operators are asking why we need this and how to use it.

BIM from construction sites
Construction sites offer a huge amount of BIM information for different locations in Excel, Word, PDF, etc. Native Revit models or an Open IFC model does not mean that BIM models are in use at FM. These models need information enrichment to be suitable in technical operations. Information has to be available via cloud services and inside databases to make data updating easy. Information sharing within other software also has to be possible.

We also need to remember that 3D-models are nice to have, but the information content is more important. Revit/IFC-models do not have all the information connected to graphical objects. For example, the information on HVAC central units (Air Handling Units, Chillers…) is missing in 3D-models. This information is in Device Schedule and, unfortunately, the most common case is that the schedule is made with Excel without standardised content. FM operations also need MEP diagrams, Service Area Zones, etc. This information can be created during the design/construction phase, if it is ordered from the designer.

If information content is standardised, everything is much easier to Facility Management software. When IFC-models or information in cloud services are in machine readable format, importing the information is easy and the software business could also be more scalable. However, on the other hand, who believes in the global level standardisation of information in the construction industry?

Sharing information is the new Black
Information sharing with other software is the new black in the building sector. Building owners do not want to stick with one gigantic software solution. Earlier, software developers wanted all the data in their databases. To own information was important. Nowadays, sharing information is more important. Sharing data means you can create new information from data founded from multiple sources.

If you have a temperature of a room coming from the Building Automation system and a CO2 level from an IoT sensor, you can create an algorithm which shows you with good accuracy the number of people in the room and with a timeline. With this new information, you can create a new use case which is sellable to your client.

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

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

With the possibilities provided by cloud software, there is a possibility to update the information in the IFC model seamlessly, without the need for opening complex native BIM software. Native BIM software is needed only when there is a change in the 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.

City Digital Twin
The next step after BIM in FM will be the city level adaptation of models. Many cities have already an open platform to connect CityGML models. In the City of Helsinki, all the buildings have unique identifiers allowing for a BIM model connected to the city level view. With one click, you can open your building from an intelligent city model.

The technology for answering these questions is ready. Now, we need software developers who have the courage to make software now for future clients. PowerPoint presentations do not thrill anyone – we need a running prototype of ideology on how BIM models are in use at facility management.
Thereafter, we will move towards FLM – Facility Life Cycle Management.

lauantai 28. huhtikuuta 2018

TATE-määrälistoja ei urakoitsija tule näkemään

Viime vuoden lopulla saatiin päätökseen KIRA-digihanke "Talotekniset määräluettelot urakkalaskentaan".

Toimin buildingSMART Finlandin TATE-työryhmän vetäjänä, joka oli tätä KIRA-digihanketta hakenut.

Loppuraportti on ladattavissa täältä:

Hanke oli kohtalainen tuskien taival. Onneksi se oli "kokeiluhanke", jossa yhtenä aspektina on aina epäonnistumisen mahdollisuus.

Epäonnistuimmeko tässä hankkeessa?

Jos katsoo projektisuunnitelmaa, niin vastaus on selkeästi "Kyllä".

Emme löytäneet todellisia urakkalaskentaprojekteja tähän hankkeeseen, jotta olisimme voineet testauttaa bSF:n laatimaa ohjeistusta määräluetteloiden käyttämiseksi:

Jos asiaa katsoo jatkuvan parantamisen periaatteilla, niin vastaus on "Ei".

Voidaan todeta, että meillä on vielä paljon parannettavaa - koko rakennusalan laajuudessa. On mielestäni piristävää nostaa esiin fiksuja kehitysehdotuksia, jotka eivät kuitenkaan syystä tai toisesta tule käytäntöön.

Välillä tuntuu, että ratkaisut rakennusalan tai sen tuottavuuden kehittämiseen ovat liian yksinkertaisia. Ongelma on siinä, että usean ihmisen tai organisaation tulee tehdä samanaikaisesti tätä kehitystä. Tästä syystä allianssihankkeissa kehittäminen on mahdollista. Kaikilla osapuolilla on lupa toimia toisin / innovatiivisesti.

Toisin sanoen, "bottom-up" malli ei toimi rakennusalan kehittämisessä.

Tarvitsemme Kekkosen, joka sanoo miten toimitaan - ja sen jälkeen alkaa suorittavassa portaassa tapahtua.

Tässä copy/paste loppuraportista, eli analysointia siitä, miksei pilottikohteita löytynyt:
Miksi projekteja ei löytynyt? 
Suureksi pettymykseksi emme pystyneet vakuuttamaan todellisten hankkeiden vetäjiä siitä, että määrätietojen antaminen TATE-urakoitsijoiden käyttöön olisi kokonaisuuden kannalta hyvä ratkaisu.

Syitä projektien löytymättömyyteen ovat ainakin seuraavat aiheet:

BuildingSMART Finlandin sisäiset asiat:
- Ryhmässä olevat jäsenet kuuluvat pääsääntöisesti yritysten kehitysorganisaatioihin. Heillä ei ole henkilöinä suuriakaan mahdollisuuksia vaikuttaa yritysten liiketoiminnallisten projektien vetämiseen.
- BuildingSMART toimii ”harrastajapohjalta” ja jokaisella jäsenellä on selkeästi päätyö ensimmäisenä prioriteettina. Projekteja olisi voinut hankkia tarmokkaamminkin, mutta ajankäytöllisistä syistä siihen ei ollut mahdollisuuksia. Ydinjoukko hankkeen organisoinnissa oli kohtalaisen pieni, noin viisi henkeä.
- Jotta projekteja olisi löytynyt, olisi tullut panostaa enemmän yritysten johdon vakuuttamiseen asian kokonaistaloudellisesta tärkeydestä. Nyt keskustelimme projektinvetäjätasolla, jolloin helposti taloudellisessa vastuussa oleva projektipäällikkö ei halua ”ylimääräisiä” tehtäviä mukaan projektiinsa – varsinkin kun rakennusprojekti on alkuvaiheessa ja muita järjestettäviä asioita on paljon avoimena.

Ulkopuoliset asiat: 
- Projekteja ei löytynyt oletettavasti siitäkään syystä, että kenenkään hankkeiden käynnistämisessä mukana olevien henkilöiden intressissä ei ole luovuttaa määrätietoja urakoitsijoille. Ajatellaan ehkä vain käynnistettävää, yhtä hanketta, näkemättä kokonaiskuvaa Suomen mittakaavassa.
- Projektien löytymiseen vaikutti myös aikataulu, sillä tieto määräluetteloiden käyttämisestä hankkeessa olisi pitänyt saada mukaan jo suunnittelijoiden tarjouspyyntöihin. Tämä tarkoittaa sitä, että olisi tarvittu hankesuunnitteluvaiheessa oleva projekti, jossa tilaajan edustus olisi ollut avarakatseinen hankkeen päämääriä kohtaan.
- Koska rakennusalan kehitystä ei pystytä toteuttamaan ruohonjuuritasolta, tulisi yritysten johdon sekä rakennushankkeita tilaavien osapuolten nousta vaatimaan uusien, toimivaksi osoitettujen toimintatapojen käyttöönottoa

Eräänä syynä projektien löytymättömyyteen pidän henkilökohtaisesti sitä, että rakennusalalla puuttuu halu kehittää omaa osaamistaan. On helpompi tehdä kuten ennenkin, vaikka pystytään osoittamaan uusien prosessien hyödyllisyys hankkeelle.
Yleisesti rakennushankkeen eri osapuolten keskuudessa on todettu, että määrälistojen käyttö hankkeissa olisi ehdottomasti järkevää. Siitä hyötyisivät kaikki osapuolet, se toisi urakoitsijoiden tarjoushintoja lähemmäksi toisiaan jolloin voitaisiin tehdä vertailukelpoisia urakoitsijavalintoja.
Lisäksi suunnitelmien laatu nousisi pienen pykälän, sillä kun suunnittelijalla on tiedossa, että kohteesta otetaan määrälistat, aletaan kiinnittää enemmän huomiota tietomallien tietosisällön oikeellisuuteen.


Henkilökohtaisesti tämä oli minulle viimeinen taisto määrälistojen puolesta puhumisessa. Nyt pitää vaihtaa henkilöitä, sillä 20v olen tästä puhunut / yrittänyt ja tuloksia ei ole tullut. Vedän siis "omat johtopäätökset".

Viikon kuva:

lauantai 2. joulukuuta 2017

API nana ko?

Nyt alkaa rakennusalallakin näkyä sana "API" siellä sun täällä.

Huom! tämän blogin alaosassa on kaksi haastetta rakennusalalle (tiedän, että suurin osa ei jaksa lukea tätä loppuun asti...)


Open API ja REST API. Documented API. JSON.... jne. Näitä viljelevät ne kaverit, jotka eivät tajua mitä tuo tarkoittaa - kuten minäkin.

Olen yrittänyt opiskella APIen mahdollisuukisa tämän vuosikymmenen alusta lähtien, kun meidän firman softa-arkkitehti sellaiset minulle esitteli. Käsittääkseni / toivottavasti tämä on nyt meidän firman viimeisintä hottia:

Ihan turha kysyä minulta mitä nuo tarkoittavat, mutta tiedän sen, että kun niitä lukee joku toisen firman devaaja ja hän haluaisi saada meiltä jonkun kiinteistön pumpun tiedot, niin me saadaan se hänelle toimitettua ilman yhtään ylimääräsitä työtä. Kunhan me luotetaan hänen softaan, kunhan meillä on kiinteistöomistajan oikeus jakaa se tieto.

Nyt päästään moneen herkulliseen asiaan kiinni. Saako tietoa jakaa ilman, että olemme sopineet tiedon antajan kanssa asiasta?

Mitä kun (ei jos) haemme tietoa monesta eri lähteestä ja muodostamme näistä tiedoista sellaista tietoa, jota ei ole olemassa? Onko tuo tieto meidän tietoa vai pitääkö meidän kysyä joltakin, että "Teidän tietoa on käytetty tämän tiedon tuottamiseen arviolta 12% verran. Saatte meiltä 1% alennuksen Saas -palvelustanne" ?

Haen lämpötiloja kiinteistöstä A1 olevilta toimistohuoneilta. Samalla haen ilmatieteenlaitokselta avoimen datan kautta ulkoilman lämpötiloja. Teen näiden kahden eri arvon kanssa trendikäyrän vuoden ajalta.
Sitten teen saman kiinteistölle A2 ja sen toimistohuoneille.
ja A3:selle. Ja neloselle jne.

Tiedän kaikien kohteiden pinta-alan avoimen kaupunkimallin kautta. Tiedän näiden kiinteistöjen nykyarvon. Tiedän näiden kiinteistöjen aurinkoenergiapotentiaalin avoimen datan kautta. Tiedän energiankulutuksen koska mittaamme sitä. Ja sen saan myös energialaitokselta. Tiedän sairaspoissaolot. Tiedän henkilöstön vaihtuvuuden.

Ym. tiedoista pystymme muodostamaan todella paljon uutta tietoja, joka palvelee kiinteistömassojen omistajaa. Mutta voisiko sitä tietoa jakaa myös muille? Edes anonyyminä, neliöpohjaisena tunnuslukutietona?

Jotta ym. skenaario on mahdollinen, niin tiedon pitää olla käytettävissä valituille softatoimittajille / yhteistyökumppaneille. Kukaan ei tee softaa, jos lopputuloksista pitää maksaa ensimmäisen tiedon tuottajalle. Vai maksaako?

Ensimmäisen tiedon tuottaja on triggeri, joka laukaisee koko analyysin eteenpäin. Tuosta triggeristä pitäisi olla hyötyä kaikille, jotka samaan kelkkaan lähtevät.

Ja sitten asian pihvi businessporukoille; miten tästä tehdään rahaa?
Vastaus: Lohkoketjuilla.

lämpötila / aikayksikkö = rahan arvoinen tieto.

Kun lähetän (siis joku kysyy sitä) APIn kautta lämpötilatiedon softa b:eelle, tienaan lohkoketjun kautta siitä 0,01 senttiä. Jos tämän minulta tulleen alkuperäisen lämpötilan lähettää softa  b eteenpäin soft c:lle, niin saan siitä 0,01+0,01 senttiä. jne. jne.... jne^2.
Rahantuloa ei voi estää...

Blockchainin kautta originaalin tiedon tuottaja tienaa, transaktio on jäljitettävissä ja todistettavissa automaattisesti, ilman ihmisen työtä.

Kun softa b rikastaa omalla softalla minulta saatua tietoa, ja tämä rikastettu tieto on sellaista, jota itsekin tarvitsen niin ollaan nollasummapelissä. Saan siis ilmaiseksi tietoa, jota tarvitsen jonkun toiminnallisuuden toteuttamiseksi.

Tämä tarkoittaa sitä, että kannattaa tehdä itsensä niin tarpeelliseksi, että sinun tietoja hyödyntävä softa ei pysty toimimaan jollet pysty tarjoamaan tietoa heille.

Pitää olla kaikkien kilpailijoiden paras kaveri.
Tiedon jakaminen on uusi Musta.
Tiedon jakaminen laajentaa muut softat myyntiyksiköiksi.

Haaste 1
Haastan kiinteistöomistajat jakamaan omien kiinteistöjen tietoja avoimeen rajapintaan.

Esim. €/m2 , kWh/m2 tai muilla "anonyymisillä" arvoilla. Tai jos olette todella edistyneitä, juuri niillä mittaustuloksilla, jotka olette tehneet kiinteisössä. Eli yksittäisen tilan lämpötila, kosteus, äänitaso, viihtyvyys, ilman laatu rakennuksen sisällä ja ulkopuolella...

Näin voisimme rakentaa Suomessa tietokannan, josta oikeasti tiedämme  miten eri tyyppisillä kiinteistöilä menee. Ja en tarkoita pelkkää energiaa, koska se on jo arkipäivää. Tarkoitan esim. todellisia siivouskustannuksia, käyttäjätyytyväisyyttä, vuokralaisten vaihtuvuutta, kahvinkeittimen täyttöastetta...

Ongelma 1: minne sitä tietoa talletetaan? Mikä avoin rajapinta? Missä?

Haaste 2:
Kaikki puhuu "Väylästä" jonne tieto laitetaan ja sitten se on jotenkin simbsalabBIM kaikkien käytettävissä.

Haastan rakennusalan tekemään "Väylän" vaatiman API speksit.

En haasta siis tekemään mitään "väylää", vaan haastan tekemään speksin (esim. wordilla) siitä, mitä tietoa halutaan linkittää väylän kautta.

Veikkaan, että tässä keskustelussa ongelma on se, että meillä rakennusalalla ei vain tajuta tietotekniikkaa. Tai ne kuka tajuaa, ei osaa sitä kertoa päättäjille.

Kiinteistöjen omistaja luulisi olevan erittäin kiinnostuneita tästä, sillä he säästävät puhdasta rahaa, kun speksi on tehty ja sitä tukevat softat ovat toimintakunnossa.

En jaksa nyt piirtää powerpointtia, katsotaan riittääkö ASCII kuvataideteos, joka oli 80 luvulla kuuminta hottia.

----Softa A----
---API Softa A----



  Portaali, kuvaus, sisältäen
      user authentication
      company authentication
    Speksi mitkä objektit tunnistetaan
      (=IFC vakioidulla tietosisällöllä)
    Ei mitään muuta, ei tietoa, ei tietomalleja


--- API VÄYLÄ---

---API Softa B---
--- Softa B---

Ym. ei ole rakettitiedettä. Enkä osannut tehdä grafiikkaa...

Meidän pitää sopia yhteisesti API VÄYLÄ. Ei muuta. Ei tarvitse sopia, kuka ylläpitää sitä. Ei tarvitse hypätä ylimmälle portaalle yhdellä hypyllä.

Kun API väylä on speksattu, voi softafirmat alkaa tehdä omia APEja siihen yhteensopiviksi. Vasta sen jälkeen, kun rakennusala pystyy osoittamaan yhteisen suunnana tiedon jakamisesta, voivat useat eri softatoimittajat alkaa tehdä siihen rajapintaan soveltuvia ohjelmistoja.

Tarkoitus ei ole tallettaa mitään API väylään (poislukien käyttäjien / firmojen tunnistautuminen). Tiedon tallennuksen hoitaa softat, jotka tukevat speksattua API väylää.

Käytännösäsä koko Väylä on turha, jos softat (useampi kuin kaksi) päättävät toimia keskenään samalla, speksatulla API rajapinnalla. Ainoa asia, joka pitää hoitaa on käyttäjähallinta jossain softassa (single sign-on, SSO)

Kiinteistön omistaja voi valita itsellensä sopivat palveluntuottajan. Ja vaihtaa sitä toiseen, jos homma ei toimi. Uusi palveluntuottaja saadaan leivottua helposti olemassa olevaan systeemiin, sillä rajapinnat ovat tehty yhteisellä speksillä.

Rakennusalan pitää ensiksi sopia, minkälaisia API rakenteita tehdään. Siis näin yksinkertaisia speksejä koodareiden mietittäksi:
- Anna minulle kiinteistön nimi
- Anna minulle kiinteistön osoite
- Anaa minulle kiinteistön ikkunat
- Anna minulle kiinteistön ikkunat ja sen propertyt
- Anna minulle kiinteistön ikkunoiden propertyistä U-arvo
- Jaa kiinteistön ikkunat
- Jaa kiinteistöin ikkunann U-arvo
- Jaa ihan mitä vaan mitä ollaan löydetty

Ym. tarkoittaa sitä, että ei pidä määritellä, missä tieto on, vaan pitää määritellä rajapinnat.
Sen jälkeen kun olemme tehneet rajapinnat, softavalmistajat pystyvät tekemään softaa sen päälle.

Use-caset tulevat sen jälkeen, kun tiedetään, mitä tietoa on tarjolla.

Näin pääsemme avoimeen rajapintamäärittelyyn Suomen kiinteistöjen osalta. Näin saadaan softaa joka pystyy luottamaan avoimiin rajapintoihin.

Kun määrittelemme esim. buildingSMARTin kautta APIen tietosisältövaatimukset, pääsemme tasolle, jota ei muualla ole.

Ym. tekstistä päästään hienosti semanttiseen webiin, jota on tutkittu Drumbeat hankkeessa:

BIM Level 3 UK:ssa ei ole mitään meille Suomalaisille, me ollaan sentään jo 100 vuotiaita! Siis teinejä verrattuna britteihin, virtaa riittää.

Viikon kuva:
Suomi 100
Tosi mukavaa olla Suomalainen

perjantai 3. marraskuuta 2017

Allianssien kilpailuasetelmat tarjousvaiheessa

Lensin tänään pihalle erään allianssihankkeen valmennustilaisuudesta, jossa tähdätään hyvään lopputulokseen kehitystyöpaissa ja tietenkin hankkeen voittamiseen.

Olen mukana ryhmittymässä A, joka tarjoaa kohdetta B.
Muutaman kuukauden päästä minut kutsuttiin ryhmään C joka tarjoaa kohdetta D.

Olin ryhmän C valmennustilaisuudessa, jossa tajusin että tämän hankkeen pääurakoitsija on tarjoamassa myös hankkeen B kohdetta eri suunnittelijatiimillä.

Minulla on tässä ilmeisestikin selvä eturistiriitaongelma.

Ensimmäisen tauon jälkeen ilmoitin kaikille tästä tilanteesta. Pienen sekavuuden ja yleisen kommentoinnin jälkeen minulle tultiin kertomaan, että eturistiriita on selvä, kohteen B asioita aiotaan hyödyntää kohteen C pääurakoitsijan toimesta. Näitä suuria salaisuuksia ei voi minulle paljastaa.

Voin sanoa, että ryhmän C pääurakoitsijan ideat eivät ole välttämättä minulle ihan suuria yllätyksiä, koska olen ollut heidän kehittäjien kanssa tekemisissä viimeiset 10 vuotta, samoissa kehityshankkeissa, samoilla ajatuksilla. Olen myös ollut heitä kouluttamassa tietomallipohjaisen suunnittelun prosesseista.

Ihan looginen valinta on, että minulle ilmoitettiin olevani vapaa poistumaan valmennustilaisuudesta / ryhmän C allianssiprojektista (siis pääurakoitsijan päätöksellä, ei allianssin).

Siitä ei ollut mitään juttua, että edustamassani toimistossa on ~850 henkeä töissä. Olen lähes varma, että joku meistä on aina jossain allianssissa mukana ilman että muu firma / toisen osapulen yritys siitä tietää. Sen kyllä tiedän, että osassa projekteja allekirjoitetaan NDA -julistuksia, joita ei oltu tässä tehty - joskin se olisi ollut loppupeleissä kuitenkin aikamoista hurskastelua.

Ym. tilanne kuvaa asiaa, joka minulle ei ole tullut aikaisemmin mieleen. Kun allianssihankkeet leviävät Suomessa, niin miten niiden tekijät lukumäärällisesti riittävät? Nyt kysytään projekteihin henkilöitä nimillä, tarjouksissa. Joissakin hankkeista on aivan käsittämätön suuri rahallinen sakko sille, jos projektihenkilökuntaa vaihdetaan kesken hankkeen. Suurin piirtein pitää kuolla tai vaihtaa alaa, jos haluaa päästä eroon projektista.

Tällä hetkellä allianssit muodostetaan yleensä isoihin projekteihin. Nämä hankeet kestävät 1-5 vuotta (tai 20v, sekin on jo koettu...).

Kysymykseni on:
Miten yritykset voivat sitoa firman SKOL01-02 kaverit hankkeisiin niissä vaadituilla spekseillä viiden vuoden projektiin ilman eturistiriitoja?

Oma vastaukseni on: Ei mitenkään.

Nykyiset vaatimukset tarkoittavat sitä, että Suomessa voi olla käynnissä vain 4-8 talonrakennuksen allianssihanketta projekteissa, joiden suuruus on yli ~50M€ (täysin hatusta heitetyt numerot). Pätevyydet täyttäviä ammattilaisia ei löydy ja yritykset alkavat fiksata henkilöitä useisiin projekteihin. Tämä ei voi olla Allianssin tarkoitus. Pitää hyväksyä, että on olemassa ykkös- ja kakkosketjuja. Kukaan ei halua kolmosketjua, vaikka se voi olla "nälkäinen" ja ylittää ykkösketjun tuotokset.

Itse valitsisin kolmosketjun. Siellä on henkilöt, jotka haluavat muutosta - jota uudet toimintamallit edellyttävät. Heillä on halu näyttää, että "täältä tullaan". He ovat irti vanhoillisista metodeista, osaavat oikeasti ryhmätyön filosofian ja pitävät sitä normaalina tapana toimia hankkeissa. Kun nämä henkilöt hommataan eri firmoista niin löydetään yhteiseen hiileen puhaltava, nälkäinen nuorisojoukko - jotka ovat täysin oman alansa ammattilaisia.

Kenellekään ei pitäisi opettaa yhteistyötä, se pitää tulla sydämestä.

Sanon tämän lauseen siksi, että ryhmässä C (josta lensin pihalle) ei oltu (vielä) pääurakoitsijan toimesta ymmäretty Allianssin syvintä merkitystä - me teemme tämän yhdessä!

Pääurakoitsija tietää, mitä pitää tehdä kehitystyöpajassa mutta väitän, että he eivät ymmärrä, mitä pitää tehdä kehitystyöpajassa.

Me olemme Allianssi. Siihen kuuluu myös käyttäjä ja tilaaja.

Viitaten edellisiin kirjoittamaani blogeihin:
Rakennusala, Yhteistyötä!

Ymmärtäkää kokonaisuus.

Viikon mietelause:

Mukavinta oli, että ym. kakkoshankkeen (C) uloskävelyn jälkeen minulle tuli kahdesta eri firmasta viesti, jonkan sisältö oli yhteenvedettynä: "Olisi tuon teron tietoja / ymmärrystä voinut tässä kyllä käyttää hyväksikin..."

perjantai 5. toukokuuta 2017

Autodesk on Ystävä

Toukokuussa 2016 kirjoittelin Autodeskin lisensseistä:

Autodesk muutti lisenssikäytäntöä radikaalisti viime vuonna. Tämän perusteella firmat tekivät Autodeskin edustajien ehdottamia ratkaisuja, ja päivittivät softiansa Autodeskin ilmoituksen perusteella -> ostivat lisenssejä "tulevaisuutta varten". Muuttivat olemassa olevia lisenssejä säästääkseen "tulevaisuudessa". Pääsääntöisesti siksi, että pääsevät subscripton asiakkaaksi (joka käsittääkseni on ao. viestissä sama kuin "ylläpitosuunnitelma".)

Tulevaisuus näyttää loppuneen maaliskuussa 2017 kun Autodeskiltä tuli uudet lisenssimääritykset.

Viesti (en ota kantaa Suomen kielioppiin):

Tärkeä ilmoitus
Haluamme kertoa lyhyesti Autodeskin nykyisestä suunnasta sekä tietyistä tulevista muutoksista, jotka vaikuttavat ylläpitosuunnitelmaasi. Lisäksi esittelemme tilaukseen siirtymistä koskevan erikoistarjouksen, johon sinun kannattaa tutustua.
Uskomme, että tilaus on paras tapa nauttia työkaluistamme ja teknologioistamme. Tilaus muuttaa merkittävällä tavalla sitä, kuinka toimitamme laajennettuja ominaisuuksia ja uusia toimintoja yhdistettyjen palveluiden kautta. Siksi olemme yrityksenä siirtymässä pelkästään tilauspohjaisiin malleihin. Investoimme jatkossakin erittäin voimakkaasti tilaustarjontaamme, jotta pystymme tarjoamaan sinulle enemmän lisäarvoa seuraavien etujen kautta:
Uusimmat tuoteominaisuudet – hyödynnä Autodeskin uusia innovaatioita, päivityksiä keskeisiin tuotteisiin, työpöytätuotteiden pilvipalveluita ja lisätoimintoja heti, kun ne ovat saatavilla, ja ilman lisämaksuja.
Uusien toimialakokoelmien käyttö – saatavilla vain tilauksena. Säästät huomattavan summan, jos tarvitset kahta tai useampaa Autodeskin ohjelmistoa.
Uusi parannettu tuki – nopeampi vasteaika ja mahdollisuus puhelinajan varaukseen Autodeskin teknisten tukiasiantuntijoiden kanssa.
Yksinkertaistettu hallinta – käytä työkaluja, jotka virtaviivaistavat kehitystä ja ohjelmistohallintaa, kun standardoit kaikki Autodesk-tuotteesi tilauksen alle.
Tilauspohjaisiin malleihin siirryttyämme olemme selvästi havainneet erään asian: kahden liiketoimintamallin ylläpitäminen (tilaukset ja ylläpitosuunnitelmat) on hyvin kallista. Jotta voimme jatkaa ylläpitosuunnitelmien tarjoamista, 7. toukokuuta 2017 alkaen tilausten uusintahinnat nousevat 5 % (2017), 10 % (2018) ja 20 % (2019). Huomaa myös, että ylläpitosuunnitelman voi tästä lähtien uusia vain vuodeksi kerrallaan.
Nyt kun olemme kertoneet Autodeskin suunnasta yrityksenä, haluamme kertoa erikoistarjouksesta, joka voi auttaa sinua harkitsemaan tilausvaihtoehtoa. Sen myötä haluamme antaa tunnustusta asiakasuskollisuudellesi sekä aiemmille investoinneillesi. Kesäkuusta 2017 alkaen voit siirtää ylläpitosuunnitelmaan kuuluvat tuotteesi tilauspohjaisiksi alennettuun hintaan. Tämä alennusprosentti laskee 5 % vuonna 2018 ja toiset 5 % vuonna 2019, eli mitä nopeammin vaihdat tilauspohjaiseen malliin, sitä vähemmän maksat – ja sitä enemmän säästät verrattuna niihin asiakkaisiin, jotka siirtyvät tilaukseen myöhemmin tai jatkavat ylläpitosuunnitelmassa. Kun teet tämän vaihdon, voit myös lukita alennetun hinnan jopa kolmeksi vuodeksi. Olet oikeutettu alennushintaan niin kauan kuin uusit tilauksesi.
Tiedämme, että sinulla on luultavasti kysymyksiä. Nämä ovat suuria muutoksia, ja olemme valmistautuneet auttamaan sinua niissä. Lisätietoja saat usein kysytyistä kysymyksistä. Voit myös ottaa yhteyttä Autodesk-myyntiedustajaan tai jälleenmyyjään, mikäli haluat keskustella vaihtoehdoista, jotka sopivat parhaiten omiin teknisiin vaatimuksiisi ja omaan liiketoimintaasi.
Valitsitpa tilaukseen siirtymisen tai ylläpitosuunnitelmasi uusimisen, lupaamme jatkossakin toimittaa sinulle alan parhaat ohjelmistot, palvelut ja tukipalvelut.
Ystävällisin terveisin,
(tämän editoin, tuskin "Teresa" tästä viestistä on vastuussa...)

Hienoa! Hyvä Autodesk! Kiitos yli 30v kumppanuudesta. Näin sitä asiakassuhdetta ylläpidetään!

Mielenkiintoista on kappale:
"Tilauspohjaisiin malleihin siirryttyämme olemme selvästi havainneet erään asian: kahden liiketoimintamallin ylläpitäminen (tilaukset ja ylläpitosuunnitelmat) on hyvin kallista. Jotta voimme jatkaa ylläpitosuunnitelmien tarjoamista, 7. toukokuuta 2017 alkaen tilausten uusintahinnat nousevat 5 % (2017), 10 % (2018) ja 20 % (2019). Huomaa myös, että ylläpitosuunnitelman voi tästä lähtien uusia vain vuodeksi kerrallaan."

Hienoa, että Autodesk on todennut meille "edullisen" (heidän määritelmä edustamalleni firmalle vuonna 2015) ja viime vuonna erittäin kalliilla hinnalla  päivitetyn sopimusmallin meille sopimattomaksi. Viime vuonna Autodeskin edustajien mukaan se oli kyllä "ehdottomasti järkevä tehdä".

Kun teimme viimevuoden päivitystä, meille vakuutettiin "lisenssikäytäntö ei muutu lähiaikoina"

Lisäksi kappale:
"Uskomme, että tilaus on paras tapa nauttia työkaluistamme ja teknologioistamme. Tilaus muuttaa merkittävällä tavalla sitä, kuinka toimitamme laajennettuja ominaisuuksia ja uusia toimintoja yhdistettyjen palveluiden kautta"

on mielestäni sopimusehtojemme vastainen, sillä olemassa oleva suppari tarjoaa meille uusimmat tuotteet ja teknologiat. Tällainen paketti me ollaan ostettu kun suppari on tehty. Miten sen voi muuttaa erilaiseksi toisen osapuolen ilmoituksella?

Ja tämä:
"Uusien toimialakokoelmien käyttö – saatavilla vain tilauksena. Säästät huomattavan summan, jos tarvitset kahta tai useampaa Autodeskin ohjelmistoa."
Mitä mitä mitä? Me päivitettiin AutoCAD Architecturet -> Suite paketeiksi -> ihan varmaan meillä pitää olla supparillakin käytössä jatkossa kaikki Suitessa määritellyt tuotteet.

Uusi parannettu tuki – nopeampi vasteaika ja mahdollisuus puhelinajan varaukseen Autodeskin teknisten tukiasiantuntijoiden kanssa."

Onko joku oikeasti saanut Autodeskiltä teknistä tukea? Siis suomeksi, yrityksen henkilökunnalle? Tuki tulee jälleenmyyjältä, jotka Suomessa ovat loistavia ammattilaisia. Autodeskin tuki on vitsi, google on parempi.

Lisenssioinnin lopputulos: muutamme omaa lisenssikäytäntöämme. Olemme Autodeskin narun perässä. Aloitan uudestaan korvaavien ohjelmistojen kartoituksen.


PS. tämä on minun omissa nimissä kirjoitettu teksti, ei edustamani yrityksen.

Viikon kuva:

Autodeskin viestissä on myös disclaimer, joka kertoo että:
Autodesk, Inc. • 111 McInnis Parkway • San Rafael, CA 94903
© 2017 Autodesk, Inc. All rights reserved. Oikeudelliset huomautukset ja tavaramerkit. Yksityisyyden suoja
Tämä on operatiiviseen toimintaamme liittyvä sähköpostiviesti.
Älä vastaa tähän sähköpostiviestiin. Vastauksia tähän sähköpostiin ei lueta eikä niihin vastata.
Autodesk, the Autodesk logo are registered trademarks or trademarks of Autodesk, Inc., and/or its subsidiaries and/or affiliates in the USA and/or other countries. All other brand names, product names, or trademarks belong to their respective holders. Autodesk reserves the right to alter product and services offerings, and specifications and pricing at any time without notice, and is not responsible for typographical or graphical errors that may appear in this document.

Itse tulkitsen ym. tekstin, että viestiä saa jakaa sellaisenaan eteenpäin.

sunnuntai 16. huhtikuuta 2017

Digitaalinen kaksonen

Termi ”Digital Twin” on näkynyt viime aikoina silloin tällöin ulkomaisissa kirjoituksissa, joissa teemana on ollut tietomallien käyttö ylläpidossa.

Termi on mielestäni hyvä, koska se luo ajatustasolla ympäristön rakennusten analysoinnille ja havainnollistamiselle. Termi sinänsä ei ole uusi, se on ollut jo vuosia käytössä mm. mekaniikkateollisuudessa;

Tarvitsemme rakennuksen digitalisen kaksosen, jos aiomme hallita sensoreiden synnyttämää valtavaa tietomäärää ihmiselle ymmärrettävässä muodossa.

Kun keräämme informaatiota rakennuksesta ja sitä analysoimalla luomme uutta tietoa, tarvitsemme tavan visualisoida sitä käyttäjälle. Yksinkertaisin visualisointitapa on esim. värjätä tiloja riippuen mitatusta lämpötilasta. Ihminen ymmärtää, että mitä punaisempi tila, sitä kuumempi se on.

Digitaalinen kaksonen synnytetään API –rajapinnoilla sekä alusta –ajattelulla
Jotta pystymme luomaan digitaalisen kaksosen, tarvitsemme reseptiksi vähintään:
1. Rakennuksen graafisen tietomallin, standardisoidulla tai tiedossa olevalla tietosisällöllä
2. Alustan, joka yhdistää graafisen näkymän pilvipalveluiden tietosisältöihin.
3. Dokumentoidut (tai avoimet) rajapinnat, joilla eri järjestelmät kommunikoivat keskenänsä

Kuva 1: Periaatekaavio dokumentoitujen API:en (esim. avulla rakennettuun kehitysympäristöön.

Yksi tärkeä asia on ymmärtää staattinen ja dynaamisen tiedon ero. Staattisesta tiedon esimerkkinä toimii mm. Ilmanvaihdon palvelualue. Se ei muutu, jollei rakennukseen tehdä konkreettisia muutostöitä. Dynaamisen tiedon esimerkkinä toimikoon tilan lämpötila. Sitä mitataan jatkuvasti ja mittaustuloksen perusteella voidaan analysoida, onko tilassa kaikki OK. Jos ei ole, niin staattisen IV-palvelualuetiedon perusteella voidaan päästä käsiksi lisätietoon, esim. IV-koneen ulospuhalluslämpötilaan ja analysoida, onko se kunnossa.

Yksittäisen tilan tai tiloista koostuvan palvelualueen välille muodostetaan siis yhteys, jonka kautta voidaan lähteä automaattisesti selvittämään mahdollisia ongelmakohtia kysymykseen: ”Miksi tilassa on kuuma?”

Analysoinnin perusteella järjestelmän tulee pystyä esittämään käyttäjälle mahdollisia vaihtoehtoja ongelman syyksi. Tietoa kerätään myös ohi rakennusautomaatiojärjestelmän, mm. API rajapinnoilla varustetuista IoT antureista, joista saatujen lisätietojen perusteella digitaalinen kaksonen muodostaa kokonaiskuvan.

Kuva 2: Esimerkki Granlund Manager Metrix –prototyypistä, jossa kiinteistöautomaatiojärjestelmä 
syöttää lämpötiloja pilvipohjaiseen tietomalliin.

Visiona ”Virtuaalinen kiinteistö, jossa käyttäjä ja rakennus kommunikoivat keskenään”

Granlund on julkaissut Innovaatiostrategian vuosille 2017-2021.

Innovaatiostrategian visiona on saavuttaa ”Virtuaalinen kiinteistö, jossa käyttäjä ja rakennus kommunikoivat keskenään”

Kun pystymme yhdistämään virtuaalisen rakennuksen käytettävissä olevaan staattiseen ja dynaamiseen tietoon, pystymme niiden avulla luomaan uutta informaatiota. Kuljemme analysointien avulla kohti raportoivaa kiinteistöä.

Seuraava askel analysoinnista on kiinteistön käyttäytymisen ennustaminen. Tässä vaiheessa pystymme simuloimaan automaattisesti esim. kiinteistön energiankulutuksen ja sisäympäristön olosuhteet seuraavalle päivälle sääennustuksen sekä tulevan ihmiskuorman ja sen aikataulujen perusteella. Tällä tiedolla pystymme ohjaamaan järjestelmää ennakoivasti, ilman manuaalisäätöjä.

Näin olemme matkalla kohta oppivaa kiinteistöä. Kiinteistö kehittää itsellensä vuosien saatossa omaa tekoälyä oppien tekemistään virheistä mm. silloin, kun tehty ennustus ei vastannutkaan kiinteistön todellista, mitattua tilannetta.

Oppiva kiinteistö tarvitsee käyttäjäpalautetta, jonka avulla tuotetaan tilojen käyttäjille optimaalisinta olosuhdetta. Vain käyttäjä voi tietää, mitä hän haluaa – siihen ei edes tekoäly auta. Tämän lisäksi kiinteistön käyttöä anonyymisti seuraamalla ja analysoimalla pystymme muodostamaan kuvan miten käyttäjäjoukko vaikuttaa kiinteistön toimintaan. Jo pelkkä oppiminen siitä, mikä on kiinteistön käyttöaste eri ajankohtina kertoo paljon talotekniselle ohjausjärjestelmälle – puhumattakaan, mitä se kertoo yrityksen johdolle kiinteistön soveltuvuudesta oman liiketoiminnan harjoittamiseksi.

Emme voi kuitenkaan unohtaa kiinteistön fysikaalisia ominaisuuksia, kiinteistön on toimittava kuten se on suunniteltu toimivan. Granlund –konsernin 2020 Strategian missiona on ”Hyvinvointia rakennetussa ympäristössä”.

Tätä tavoitetta toteutamme Innovaatiostrategiassa, kun muistamme että: ”Käyttö ohjaa kaikkea tekemistämme”

Viikon kuva:
Mun duuni seuraavien vuosien aikana: