Skrita cena zakasnitve: zakaj je-odziv v realnem času pomemben pri nadzoru skupine

Fenomen: ko zavesa postane "zadrga z manjkajočimi zobmi"

Sprva je ekipa za zagon posumila na motorje.

Projekt je bil ravnokar v končnem testiranju. Vsak delavnik ob 8.30 zjutraj je sistem za upravljanje stavbe spustil žaluzije na vzhodni fasadi, da bi zmanjšal sončno energijo, preden so prispeli stanovalci. Ukaz je bil preprost: več sto motorjev, isti prednastavljeni položaj, isti čas.

Fasada se nikoli ni selila skupaj.

Prva vrsta se je odzvala skoraj takoj. Drugi so sledili delček sekunde kasneje. Nekaj ​​jih je obstalo, nato pa dohitelo. Ko se je zadnji del začel premikati, se je prvi že ustavil.

Znotraj stavbe ste komaj opazili. Z ulice je bila zavesa videti kot zadrga z manjkajočimi zobmi.

Brez alarmov. Vsak motor je opravil individualno funkcionalno testiranje. Omrežje je delovalo ves dan.

Zakaj torej na stotine individualno funkcionalnih motorjev ne bi moglo izvesti enega sinhroniziranega giba?

To vprašanje se pojavlja pogosteje, kot večina projektnih specifikacij predvideva. Ker uvedbe senčenja presegajo 50 ali 100 motorjev na zgradbo, postane razlika med tem, kar lahko naredi motor sam, in tem, kar lahko naredi sistem skupaj, odločilna metrika uspešnosti.

Napačno prepričanje: motor skoraj nikoli ni pravi problem

Tukaj je vzorec, ki sem ga videl ponoviti v več projektih: motorji so najprej obtoženi, drugič zamenjani in tretjič upravičeni.

Individualno funkcionalno testiranje je čisto za vsako enoto. Krivulje navora so znotraj spec. Hitrosti potovanja se ujemajo s podatkovnim listom. Raven hrupa je v redu. Toda ko vseh dvesto motorjev prejme skupinski ukaz, se fasada zlije v kaskade, namesto da bi se zaskočila v položaj kot ena površina.

Na tej točki je zamenjava motorjev najdražji način, da ugotovite, da motorji nikoli niso bili problem.

Preiskava se skoraj vedno premakne proti komunikacijski verigi: BMS do prehoda, prehod do omrežja, omrežja do motornega krmilnika. Odklopite ducat motorjev iz skupine in znova-testirajte. Če se zamuda komaj premakne, je ozko grlo navzgor.

Širjenje milisekund: kako majhne zamude postanejo vidne

Matematika je na lestvici neprizanesljiva.

En motor se zažene s 100 milisekundami zamude - nihče ga ne vidi. Toda razširite teh istih 100 ms na tristo motorjev v petnajstih nadstropjih in zakasnitev se širi. Ukazi zadenejo različne segmente omrežja v različnih trenutkih. Kar je bil delček sekunde na ravni paketa, postane val, ki se vali po fasadi.

Inženirji za zagon imajo za to neformalno ime: učinek zadrge. Ime se drži, ker natančno opisuje, kaj vidite.

Razumeti je treba, da je učinek zadrge simptom in ne diagnoza. Ko ga vidite, nekje med krmilnikom in motorji, je čas ukaza postal nedosleden. Iskanje kje je dejansko delo.

Zakaj razvijalci to jemljejo resno

Vrhunska pisarniška stolpnica z avtomatizirano fasado, ki se ne sinhronizira, ima težavo, ki presega inženiring. Fasada je del vizualne podobe stavbe. Ko deluje, je avtomatizacija nevidna. Ko pa ne, to opazi vsak najemnik v 15. nadstropju pred prvo kavo.

Slišal sem, da je ista pritožba izražena na dva povsem različna načina. Inženirji pravijo, da "vidimo zakasnitev v skupini za multicast." Upravljavci objektov pravijo, da se "žaluzije ne premikajo več skupaj." Ista težava, drugačen jezik. Oba sledita istemu korenu.

Za razvijalce je cena verodostojnost. Za stanovalce je to zaupanje v tehnologijo stavbe. Za ekipo za naročanje so neplačljive ure lovljenja duha.

Stroški energije: vsaka pozna sekunda se poveča

Senzor dnevne svetlobe se sproži pri vnaprej nastavljenem pragu obsevanosti. Žaluzije se morajo takoj odpreti. Če pa ukaz skupine potrebuje 800 milisekund za širjenje - ni nenavadno v velikem enoposteljnem omrežju - vsaka od teh milisekund omogoči, da sončno sevanje s polno intenzivnostjo zadene notranje steklo.

Ena sekunda zakasnitve sama po sebi ne doda nič pomembnega k hladilni obremenitvi. Toda to sekundo pomnožite s številom sprožilnih dogodkov na dan, s številom dni v hladilni sezoni, s kvadratnimi metri zasteklitve in številka ne bo več nepomembna. Fasada,-obrnjena proti zahodu, poleti lahko sproži senčenje več desetkrat na dan, ko se kot sonca premakne in oblaki preidejo. Vsaka pozna uvedba je toplota, ki jo mora sistem HVAC zdaj odstraniti.

Študija LBNL o-zasedenosti zgradbe New York Times je dokumentirala, da je samodejno senčenje, integrirano z nadzorom-zatemnitve dnevne svetlobe, zmanjšalo letno porabo energije za razsvetljavo za 56 % v območjih. Ta rezultat je predvideval pravočasno uvedbo. Pozne zaslepitve spodkopavajo aritmetiko, zaradi katere se je naložba v senčenje povrnila.

V samem omrežju so tudi sekundarni stroški. Ko ukazi prispejo z zamudo, krmilniki ponovno oddajo. Ponovni prenosi porabijo čas, ki bi moral biti na voljo za naslednji ukazni cikel. Majhna stopnja ponovnih poskusov je običajna - to upošteva vsak brezžični protokol. Toda znova poskusi spojino. Skupina, ki opazi 2 % ponovnih poskusov pri 50 motorjih, bi lahko videla 8 % pri 200 in krivulja prometa ni linearna. Vsak ponovni poskus ustvari več prometa, kar povzroči več kolizij, kar povzroči več ponovnih poskusov. Inženirji, ki merijo zakasnitev skozi čas, pogosto odkrijejo, da se omrežje počasi nasičuje.

Dodajanje motorjev ne doda linearne zakasnitve

Ena od bolj vztrajnih napačnih predstav v projektnih razpravah je, da podvojitev števila motorjev podvoji zamudo.

Videl sem, da omrežje s 100 motorji deluje bolje kot omrežje s 60 motorji na istem skladu protokolov. Videl sem tudi, da je omrežje s 250 motorji ostalo stabilno več let, medtem ko je bilo omrežje s 120 motorji v drugi stavbi potrebno ponovno zagnati vsakih šest mesecev.

Spremenljivka ni število naprav. Spremenljivka je, kako je komunikacijski sistem zasnovan: logika združevanja, prepustnost krmilnika, izbira protokola, topologija, pogostost posodabljanja stanja, ali je anketiranje omogočeno. Dve zgradbi z istimi motorji, istim prehodom in isto strojno programsko opremo lahko povzročita popolnoma različne rezultate zagona, če ena od njiju združi vse žaluzije v eno cono, druga pa razdeli glede na orientacijo fasade.

Zato izkušeni integratorji preverijo konfiguracijo omrežja, preden se dotaknejo strojne opreme.

Dnevniki so povedali drugačno zgodbo

Pri enem projektu, pri katerem je bil učinek zadrge resen, je ekipa črpala komunikacijske dnevnike iz tedenskih avtomatiziranih jutranjih ciklov.

Vzorec je bil takojšen. Motor 001 je ukaz prejel v 12 milisekundah. Motor 200 je prejel isti ukaz po 940 milisekundah. Motorji se niso odzivali počasi - ukaze so prejemali ob različnih časih.

 

Ta ugotovitev je spremenila celotno preiskavo. Ni šlo za težavo z motoričnim odzivom. Šlo je za problem distribucije ukazov. Krmilnik je ponavljal po napravah eno za drugo prek enoposteljne storitve in vsak okvir je čakal, da je bil prejšnji potrjen, preden je bil poslan naslednji.

200 motorjev × približno 4,7 milisekunde na okvir (ob upoštevanju časa predvajanja, odmika CSMA/CA in obračanja ACK)=940 milisekund. Matematika se skoraj natančno ujema z opaženo zamudo.

Izbira komunikacije: en ukaz v primerjavi z dvesto posameznimi klici

Analogija, ki običajno pristane pri zainteresiranih straneh projekta, je naslednja: 200 ljudem v stavbi morate povedati, naj se udeležijo sestanka. Lahko pokličete vsakega posebej ali pa naredite eno najavo preko ozvočenja. Isti rezultat. Radikalno drugačen čas do dokončanja.

Skupinska komunikacija deluje na enak način. Unicast omrežje ustvari posamezne pakete za vsak motor in jih pošilja zaporedno. Vsak paket čaka, da se prejšnji počisti. Zakasnitev se aritmetično poveže z velikostjo skupine.

Multicast ustvari en okvir, naslovljen na logično skupino. Vsak motor v tej skupini ga prejme znotraj istega prenosnega okna. Zakasnitev je konstantna ne glede na velikost skupine - en čas slike, ne N časov slike.

Protokol Matter, ki ga vzdržuje Connectivity Standards Alliance, določa skupinsko komunikacijo prek skupine Groups Cluster. ID skupine se preslika v nabor vozlišč tkanine in en sam multicast prenos doseže vse člane skupine hkrati. To ni lastniška tehnika - je vgrajena v specifikacijo protokola. Praktična razlika za namestitev z 200 motorji je razlika med enim in 200 okvirji.

Topologija omrežja: zakaj fizična plast odloča o izidu

Druga spremenljivka, ki določa, ali multicast dejansko deluje v obsegu, je fizična omrežna plast.

V zvezdasti topologiji -, ki opisuje večino WiFi in številne podedovane uvedbe Zigbee -, se vsak motor poveže neposredno z osrednjo dostopno točko ali koordinatorjem. Ko en motor stoji za betonsko strižno steno ali dvižnim vodom HVAC, se kakovost njegove povezave poslabša neodvisno od vsakega drugega motorja. Omrežje kompenzira s ponovnim oddajanjem ali zmanjšanjem hitrosti prenosa podatkov za to pot, kar porabi čas, ki bi moral biti na voljo za skupinske ukaze.

Nit uporablja drug model. Gradi mrežo: naprave, ki se-napajajo iz električnega omrežja, delujejo kot usmerjevalniki in posredujejo promet napravam,-napajanim z baterijami, ki ne morejo vedno-vzdrževati radia. Če je neposredna pot do motorja 47 blokirana, okvir poteka skozi motor 32 in motor 18. Mreža neprekinjeno preračunava poti na podlagi meritev kakovosti povezave, posodobljenih v realnem času. Ni ene točke napake. Brez zastalega ukaznega toka, ki čaka na ponovni prenos v eno vozlišče v težavah.

Primerjava mrežnega omrežja Silicon Labs, izvedena v zasedeni komercialni pisarni z aktivnimi omrežji WiFi in Zigbee, zagotavlja neodvisno referenco. V velikih omrežjih z zmernimi koristnimi obremenitvami: zakasnitev niti je bila pod približno 100 ms, Zigbee se je razširil na približno 130 ms, mreža Bluetooth pa se je poslabšala nad 250 ms. Vrzel raste z velikostjo omrežja in obremenitvijo, kar so natanko pogoji, ki so pomembni za komercialno senčenje.

Thread izvaja tudi frekvenčno agilnost: če en kanal 2,4 GHz postane nasičen, omrežje med prenosi preskoči na čistejši kanal. Motorna aplikacijska plast nikoli ne vidi skoka. Brez ponovnega poskusa. Brez zakasnitve. To je standardna funkcija Thread, določena na ravni MAC IEEE 802.15.4.

Nič od tega ne pomeni, da je Thread vedno pravi odgovor. Še vedno prevladujejo konstrukcija, gostota naprav in kakovost zagona. Kaj spremeni Thread, je, kako se omrežje poslabša pod obremenitvijo - in za velike uvedbe senčenja je edina pomembna vrsta elegantne degradacije.

Ko je fasada videti počasna, so motorji zadnja stvar, ki jo preverim

Višji inženir za zagon mi je to enkrat rekel in to je držalo vsakič, ko sem videl učinek zadrge na terenu.

Njegov namen ni bil, da motorji nikoli ne odpovejo. Bilo je, da je okvara motorja binarna - motor se zažene ali pa ne. Poslabšanje komunikacije je nenehno - poslabša se, ko se promet povečuje, ko se zgradba polni, ko se drugi sistemi povežejo. Tovarniško sprejemno testiranje odkrije okvare motorja. Redko odkrije težave s komunikacijo, ker testno okolje nima RF kompleksnosti dokončane zgradbe z 200 napravami, 50 dostopnimi točkami WiFi in motornimi sobami dvigal, ki ustvarjajo širokopasovne EMI dve nadstropji stran.

Zato se težave s sinhronizacijo pogosto pojavijo med zasedenostjo, ne med zagonom. Omrežje je bilo v redu, ko je delovalo edino.

Izmerite desno končno točko

Pogovori o zakasnitvi se skoraj vedno začnejo s "kako hiter je motor?" Zdi se kot pravo vprašanje, vendar zoži preiskavo na napačen 1 % signalne verige.

Motor se lahko odzove v 8 milisekundah od prejema ukaza. Če je trajalo 900 milisekund, da je ukaz prispel, vam skrajšanje odzivnega časa motorja z 8 ms na 6 ms ne prinese ničesar.

Meritev, ki je pomembna, je od-do-konca: interval od tega, ko krmilnik izda skupinski ukaz vsakemu motorju, ki začne fizično gibanje. Ta številka zajema krmilnik, omrežni sklad, radio, MCU motorja in napajalno stopnjo - vse, kar se nahaja med navodili BMS in mehanskim izhodom.

Ko sledite od-do-konca, se slika spremeni. Dva sistema, ki določata enake odzivne čase motorja, se lahko razlikujeta za 800 ms od konca-do-konca zaradi tega, kako omrežje razdeljuje ukaze. Primerjava tehničnih listov ga nikoli ne ujame.

Povprečna zakasnitev je moteča

Vidim, da se inženirji ujamejo v past: primerjajo povprečne zakasnitve in mislijo, da so odgovorili na vprašanje.

Dva sistema, oba poročata o povprečju 18 ms. Na papirju identična. Pri uvajanju zagotavlja dosleden odziv v tesnem pasu. Drugi občasno naraste na 80 ali 100 ms med gostim prometom - in ti skoki, ne povprečje, so tisto, kar ljudje vidijo, ko se fasada premakne.

Oko ne zaznava povprečij. Zaznava izstopajoče vrednosti. Ena sama konica 100 ms v skupini 300 motorjev ustvari vidno obotavljanje v enem delu fasade in to je tisto, kar si lastnik stavbe zapomni. Zato so inženirji za zagon bolj pozorni na 99. percentil - ali še bolje, največjo opaženo zakasnitev - kot na povprečje. Predvidljivost vsakič premaga vrhunsko zmogljivost.

 

Merjenje v-resničnem svetu: kaj smo izmerili na lastni platformi

Pred izdajo trenutne nadzorne platforme je naša ekipa inženirjev izvedla interno preverjanje, da bi razumela, kako se odzivni čas spreminja glede na velikost skupine.

Nastavitev: cevni motorji v omrežju Matter{0}}over-Thread, stabilni pogoji v zaprtih prostorih, ponavljajoči se skupinski ukazi v vse večjem številu naprav. Cilj ni bil doseči impresivnega minimuma -, temveč je bilo preveriti, ali je zakasnitev ostala predvidljiva, ko je skupina rasla.

V več preskusnih ciklih s 100 motorji se je večina enot začela premikati v 20 milisekundah po skupinskem ukazu. Najpočasnejši odčitek je bil približno 22 ms. Ponovni prenos paketov je ves čas ostal pod 0,5 %.

Povečanje je bilo gladko - brez padca, brez točke, kjer bi se zmogljivost nenadoma zrušila. To je pomembnejše od absolutnih številk. Sistem, ki se pod obremenitvijo postopoma poslabša, je mogoče z zaupanjem uvesti v katerem koli obsegu. Sistem, ki dobro deluje pri 40 motorjih in razpade pri 80, je katastrofa ob zagonu, ki čaka, da se zgodi.

To so številke nadzorovanega{0}}okolja. Prave zgradbe imajo jeklene okvirje, nizko-E steklo, konkurenčna omrežja WiFi in stanovalce, ki hodijo naokrog z mobilnimi napravami. Rezultati na terenu bodo različni. Preverjanje je preprosto potrdilo, da se arhitektura - multicast over mesh - spreminja tako, kot predvideva matematika.

Mehanska stran: Tudi popolna komunikacija ne more prikriti toleranc

Komunikacija pritegne pozornost, ker je v njej največ skupinskih zamud. Toda tudi s popolnim podajanjem ukazov - lahko vsak motor, ki prejme isti okvir v istem trenutku -, sinhronizacija še vedno prekine na mehanski ravni.

Tolerance sklopa menjalnika, variacija prednapetosti ležaja, čas sprostitve zavore, koncentričnost izhodne gredi - vse to vpliva na to, kako hitro motor preide iz mirovanja v vrtenje po prejemu električnega ukaza. Posamezne razlike so nekaj milisekund, nevidne. Čez več sto motorjev na eni fasadi se nakopičijo v opazno opotekanje.

Zato doslednost proizvodnje ni ločen pogovor od komunikacijske uspešnosti. Dva spojina. Naš proizvodni proces ohranja ključne komponente prenosa na ±0,05 mm na sedežih ležajev in profilih zobnikov. Ta toleranca neposredno vpliva na mehansko ponovljivost, od katere je odvisna krmilna zanka vdelane programske opreme.

Ostrejše tolerance pomenijo, da povratna informacija o položaju kodirnika dejansko pristane tam, kjer motor pričakuje. Manjše tolerance pomenijo, da krmilna zanka nenehno popravlja - prekoračitve, umike nazaj, mikro-oscilacije -, ki porabijo energijo in v tihi pisarni postanejo slišni kot lovski hrup na mejnih postankih. Natančnost komunikacije in mehanska natančnost sta dve polovici istega problema.

Zasnova cone se zgodi, preden se potegne prva žica

Večina napak pri sinhronizaciji je načrtovana v projektu, preden se začne nabava.

Najpogostejša napaka je združevanje po nadstropju, ker so tako organizirane arhitekturne risbe. Počuti se naravno. Toda sonce ne spoštuje talnih meja. Vzhodna fasada dobi jutranjo obremenitev; zahodna fasada dobi popoldansko obremenitev. Če vsaka žaluzija v nadstropju prejme vsak ukaz ne glede na to, ali sonce sije na njeno stran stavbe, se omrežni promet poveča brez funkcionalnega razloga.

Enostavnejši pristop: najprej združite po orientaciji fasade, nato razdelite po nadstropju znotraj vsake orientacije. Vzhodno območje. Zahodna cona. Severna cona. Južno območje. Vsaka multicast skupina vsebuje samo motorje, ki se vedno premikajo skupaj - ista izpostavljenost soncu, ista ukazna logika. Skupinski promet pade. Tlak v čakalni vrsti pade. Zakasnitev se zmanjša.

Prag lestvice: ko brezžična omrežja potrebujejo žičnega partnerja

Obstaja točka, ko čisto brezžično omrežje potrebuje pogovor o žični redundanci in po naših izkušnjah je ta točka nekje čez 500 motorjev v omrežju ene zgradbe.

Pod 300 dobro{1}}zasnovana nitna mreža upravlja skupinski nadzor brez drame. Med 300 in 500 je treba posvetiti pozornost gostoti mreže: načrtujte vsaj eno napravo, ki podpira-usmerjevalnik, na 15 do 20 končnih točk, tako da bo raznolikost poti usmerjanja vztrajala, ko so v igri ovire.

Nad 500 se operativna kompleksnost spremeni. Posodobitve vdelane programske opreme v tem obsegu nasičijo brezžično omrežje, če niste previdni. Zagon naprave traja dlje. Statistična verjetnost dogodka mrežne particije -, kjer podnabor naprav začasno izgubi povezljivost z mejnim usmerjevalnikom -, se poveča s številom vozlišč, tudi če je povprečna kakovost povezave odlična.

Pri tem pragu dodajanje žične hrbtenice RS-485 kot vzporedne poti za distribucijo vdelane programske opreme in samodejni preklop ni priznanje, da je brezžična povezava nezanesljiva. To je priznanje, da v stavbi s 500 motorji pregradni dogodek med zaporedjem integracije požarnega alarma ni nekaj, kar bi želeli razložiti AHJ. Žična pot je zavarovanje.

Bolnišnice, letališča in vladne zgradbe ponavadi določajo hibridno arhitekturo ne glede na število motorjev, ker zaradi stroškov izpadov v teh okoljih žična varnostna kopija povzroči napako pri zaokroževanju celotnega proračuna projekta. Inštitut za gradbeno industrijo je dokumentiral, da stroški predelave - vključno s ponovnim zagonom sistema - v povprečju znašajo 12,4 % stroškov vgrajenega projekta. Odvečna komunikacijska hrbtenica stane delček ponovnega zagona 500 motorjev, potem ko se po-zasedenosti pojavi skrita težava z omrežjem.

Pet vprašanj, ki so pomembna pred odjavo

Po dovolj ciklih zagona se vedno znova pojavljajo ista vprašanja. Nikoli ne gre za navor ali vrtljaje.

"Vsak motor je opravil individualno testiranje. Zakaj je skupina videti počasna?"

Gledate problem distribucije ukazov, ne problem motorja. Preverite, ali krmilnik enoposteljno pošilja ukaze enega za drugim. Preverite pogostost posodabljanja stanja. Preverite, ali so vsi motorji v eni preveliki skupini. V večini primerov preklop na skupinsko naslavljanje multicast odpravi vidno zakasnitev brez dotika enega samega motorja.

"Če en motor odpove, ali to uniči skupino?"

Ne bi smelo. Vsak motor se neodvisno odzove na isti multicast okvir. En sam mrtev motor - Okvara MCU, kratek kondenzator, mehanski zastoj - ostane sam mrtev. Ostalih 199 izvede ukaz normalno. Če motor v celoti izpade iz omrežja, ga mora nadzorna plošča za upravljanje označiti kot ne-odzivnega in samodejno se ponovno pridružiti skupini, ko je povezljivost ponovno vzpostavljena. Ta izolacija je težka zahteva za katero koli proizvodno{9}}platformo za nadzor.

»Ali je brezžična povezava dejansko zanesljiva v jeklenem-in-steklenem stolpu?«

Da, če sta protokol in topologija izbrana za to okolje. Mrežasta arhitektura Thread se usmeri okoli ovir, namesto da bi bila odvisna od ene dostopne točke, ki prebija skozi njih. Frekvenčna agilnost skoči stran od nasičenih kanalov, ne da bi bila vključena aplikacijska plast. Prej omenjeni primerjalni preizkus Silicon Labs je potekal v aktivni pisarni z WiFi in Zigbee, ki sta tekmovala za čas predvajanja - ne v zaščitenem laboratoriju -, Thread pa je imel najnižjo zakasnitev v vseh testnih pogojih.

Kljub temu noben protokol ne odpravlja potrebe po RF raziskavi pred-namestitvijo v velikem obsegu. Stavba z metaliziranimi okenskimi prevlekami Low-E se obnaša drugače kot stavba s prozornim steklom. Suhomontažna-na-konstrukcija s stebri se obnaša drugače kot liti beton in armatura. Mreža bolje obvlada ovire kot zvezda. Zaradi tega fizika ni neobvezna.

"Je manjša zakasnitev vedno boljša?"

Le če je tudi dosleden. Sistem, ki vsakič odda 18 ms, ustvari vidno enotno fasado. Sistem, ki lahko doseže 10 ms v idealnih pogojih, vendar se poveča na 80 ms, ko se promet poveča, ustvari fasado, ki je videti nervozna. Za lastnike stavb je predvidljivost tisto, kar stanovalci opazijo. Najmanjša specifikacija je tisto, o čemer prodajni inženir govori na ponudbenem sestanku. Redko so enake stvari.

Pred začetkom naslednjega projekta

Lekcija, ki se ponavlja pri velikih projektih senčenja, je preprosta: težave s sinhronizacijo se skoraj nikoli ne začnejo pri motorju.

Do trenutka, ko je učinek zadrge viden z ulice, se glavni vzrok tedne ali mesece tiho kopiči v komunikacijskem sistemu. Izkušene ekipe za zagon to vedo. Preden naročijo nadomestno strojno opremo, preverijo konfiguracijo omrežja.

Pet pomembnih vprašanj:

Ali se ukazi distribuirajo z multicast ali unicast?

Koliko naprav si deli vsako komunikacijsko pot?

Koliko nepotrebnega preverjanja stanja je omogočenega?

Ali zakasnitev ostane predvidljiva, ko se število naprav poveča?

Ali je mogoče osamiti eno komunikacijsko napako?

Pravilen odgovor na teh pet vprašanj bo bolj vplival na delovanje fasade kot katera koli specifikacija motorja na podatkovnem listu.

Odzivni čas v resnici ni motorična metrika. Je sistemska metrika. Ko si komercialne zgradbe prizadevajo za tesnejšo integracijo med senčenjem, razsvetljavo in HVAC, zmožnost izvajanja časovno razporejenega ukaza na stotinah končnih točk postaja številka uspešnosti, ki določa, ali je bila naložba v avtomatizacijo vredna. Motorji so redko ozko grlo. Arhitektura med njimi je skoraj vedno.