Når vi bygger de nye smarte byggene våre er det en ting jeg mener er lite smart:
Vi kabler fortsatt opp alle temperaturfølere, CO2, VAV, ventiler for varme eller ovner. Her går det med kilometer med kabel, og det er lite fleksibelt.
Leiekontrakter endrer seg fra 8-11 år til 3-5 år, det betyr at den tekniske leveransen skal overleve flere leietakere. Da må det være fleksibelt.
– Ville spart kilometervis med kabling
Styring av byggene våre har gjennom tiår blitt veldig god på autonomitet, det vil si at styringen skal virke lokalt, og at informasjonen ikke skal ut av bygget, se eksempel fra et topologiskjema fra Sandnes kommune.
Men ved å gjøre det på denne måten, ser man at det går mye kabling siden alle feltkomponentene skal ha kabel. I tillegg kan man stille spørsmål ved svakhet i systemet dersom PLS (programmerbar logisk styring) går ned.
La oss si at vi hadde her gått for trådløs teknologi isteden, da hadde man spart kilometervis med kabling, men slipper grensesnittet mellom elektro, SD og rør, og man kan enklere ta ansvar for sin egen entreprise. I tillegg kan man enkelt endre på løsningene i ettertid, fordi man slipper å ta høyde for en kommunikasjonskabel.
Stabilitet er ofte et argument for å fortsette med kabel. Den diskusjonen ønsker jeg gjerne å legge død. Vi jobber i dag på trådløst nettverk gjennom hele dagen, det trådløse nettverket er det viktigste for de fleste på en kontorjobb, og dette stoler vi på.
Stabilitet er ofte et argument for å fortsette med kabel. Den diskusjonen ønsker jeg gjerne å legge død.
Tommy Hagenes
En jungel av komponenter
Det samme gjelder når det dreier seg om store datamengder. Sensorikken vår bruker en promille av dette, og en eventuell nedetid på WIFI er kritisk, bare noen sekunder forsinkelse er uakseptabelt. Men om temperaturføleren vår har en forsinkelse på fem minutter, har det noe å si? Forandrer temperaturen seg så mye i et rom? Hva er det verste som skjer? Vi får 21 grader i stedet for 22.
Kostnader og tilgjengelighet er kanskje de viktigste faktorene for at vi ikke kan vente lengre. Utfordringen er at det finnes en jungel av komponenter med ulik batterilevetid og rekkevidde. Det å velge riktige komponenter til riktige prosjekter er veldig viktig.
For ti år siden lanserte Tridium både Zwave og Enocean, med støtte i kanskje den mest brukte SD-anleggbrikken (JACE) men man kom aldri helt i gang. Dette har gjerne ført til at det er mange andre selskaper som har kommet opp på sidelinjen, og som disrupterer dette markedet.
Det å prøve og feile med trådløsteknologi er viktig læring. Vi må tørre å prøve!
Overlever nedetid på nettbank
Sikkerhet er en litt overraskende kritikk mot det trådløse og mot skyløsninger. Særlig når man tenker på at Dagbladet i 2013 hacket 290 tradisjonelle systemer, fordi det er så mye svakheter i dem.
Når man snakker om trådløse protokoller i dag er sikkerhet en selvfølge. Hver dag sender vi millioner av trådløs signaler/data i en sky via nettbankene våre, men her stiller vi ingen spørsmål. Nedetid på nettbank eller BankID skjer innimellom, men vi overlever, og det løses alltid innen rimelig tid.
Når data går igjennom skyen får vi ekstremt mange fordeler med tanke på skalering, bacup, nedetid, hardware-oppgradering og mye, mye mer. Ulempen er selvsagt at data går ut av bygget, og en får nedetid. På samme måte som PLS på topologiskjema til Sandsnes kommune går ned, kan skyen eller gateway som fører til skyen gå ned. Det er viktig å være bevist på dette, slik at man lager en god styringsstrategi.
Styringsstrategien må inneholde en plan for hva skjer dersom skyen går ned. Om vi styrer et ventilasjonsanlegg etter trådløse temperatur- og CO2-følere, blir strategien gjerne å styre på avtrekksføler (som er gjennomsnitt på alle rom) med en minimum/maksimum begrensning på tilluften, egentlig slik vi gjør det i dag. Så det verste som skjer dersom noe går ned er at det er samme styring som i dag.
Ha alltid en god styringstrategi, da er ikke trådløsteknologi med skyer så farlig!
Innlegget ble først publisert på Tommy Hagenes' Linkedin-profil og er gjengitt med tillatelse.
