Skrytá cena latencie: Prečo je odozva v reálnom{0}}čase dôležitá pri skupinovej kontrole

Fenomén: Keď sa zo závesovej steny stane „zips s chýbajúcimi zubami“

Tím uvádzajúci do prevádzky mal najprv podozrenie na motory.

Projekt práve vstúpil do záverečného testovania. Každý pracovný deň o 8:30 riadiaci systém budovy stiahol žalúzie na východnej fasáde, aby znížil solárny zisk pred príchodom obyvateľov. Príkaz bol jednoduchý: niekoľko stoviek motorov, rovnaká prednastavená poloha, rovnaký čas.

Fasáda sa nikdy nepohla spolu.

Prvý rad odpovedal takmer okamžite. Ďalší ho nasledovali o zlomok sekundy neskôr. Niekoľkí sa odmlčali a potom sa chytili. V čase, keď sa posledná sekcia začala pohybovať, prvá sekcia sa už zastavila.

Z vnútra budovy ste si to sotva všimli. Z ulice vyzerala závesná stena ako zips s chýbajúcimi zubami.

Žiadne budíky. Každý motor prešiel individuálnym funkčným testovaním. Sieť zostala zapnutá celý deň.

Prečo by teda stovky samostatne funkčných motorov nemohli vykonávať jeden synchronizovaný pohyb?

Táto otázka sa objavuje častejšie, ako väčšina projektových špecifikácií predpokladá. Keďže nasadenie tienenia presiahne 50 alebo 100 motorov na budovu, rozdiel medzi tým, čo dokáže motor sám, a tým, čo dokáže systém robiť spoločne, sa stáva určujúcou metrikou výkonu.

Mylná predstava: Motor nie je takmer nikdy skutočný problém

Tu je vzor, ​​ktorý som videl opakovane vo viacerých projektoch: motory sú obviňované ako prvé, nahradené ako druhé a potvrdené ako tretie.

Individuálne funkčné testovanie je čisté na každej jednotke. Krivky krútiaceho momentu sú v rámci špec. Cestovné rýchlosti zodpovedajú údajovému listu. Hladiny hluku sú v poriadku. Ale keď všetkých dvesto motorov dostane skupinový príkaz, fasáda namiesto toho, aby zapadla do polohy ako jeden povrch, padá do kaskády.

V tomto bode je výmena motorov najdrahším spôsobom, ako zistiť, že s motormi nikdy nebol problém.

Vyšetrovanie sa takmer vždy posúva smerom ku komunikačnému reťazcu: BMS k bráne, bráne k sieti, sieť k ovládaču motora. Odpojte tucet motorov od skupiny a znova{1}}otestujte. Ak sa oneskorenie sotva pohne, úzke miesto je proti prúdu.

Šírenie milisekúnd: Ako sa stávajú viditeľné drobné oneskorenia

Matematika je nemilosrdná v mierke.

Jeden motor štartujúci s oneskorením 100 milisekúnd - nikto ho nevidí. Ale rozložte tých istých 100 ms cez tristo motorov na pätnásť poschodí a oneskorenie sa rozšíri. Príkazy zasahujú do rôznych segmentov siete v rôznych okamihoch. To, čo bol zlomok sekundy na úrovni paketov, sa stáva vlnou valiacou sa cez fasádu.

Inžinieri uvedení do prevádzky majú pre to neformálny názov: zipsový efekt. Názov sa drží, pretože presne vystihuje to, čo vidíte.

Treba pochopiť, že efekt zipsu je symptóm, nie diagnóza. Keď to vidíte, niekde medzi ovládačom a motormi je načasovanie príkazov nekonzistentné. Zistenie, kde je skutočná práca.

Prečo to vývojári berú vážne

Prémiová kancelárska veža s automatizovanou fasádou, ktorá sa nesynchronizuje, má problém, ktorý presahuje rámec inžinierstva. Fasáda je súčasťou vizuálnej identity budovy. Keď funguje, automatika je neviditeľná. Keď nie, každý nájomník na 15. poschodí pred prvou kávou spozornie.

Počul som tú istú sťažnosť formulovanú dvoma úplne odlišnými spôsobmi. Inžinieri hovoria, že „v skupine multicast vidíme latenciu“. Facility manažéri hovoria, že "žalúzie sa už spolu nepohybujú." Rovnaký problém, iný jazyk. Obe smerujú späť k rovnakému koreňu.

Pre vývojárov sú náklady na dôveryhodnosť. Pre obyvateľov je to dôvera v technológiu budovy. Pre realizačný tím sú to nevyúčtovateľné hodiny naháňania ducha.

Náklady na energiu: Každá neskorá sekunda sa sčítava

Senzor denného svetla sa spustí pri vopred nastavenom prahu ožiarenia. Žalúzie by sa mali okamžite spustiť. Ak sa však skupinovému príkazu šíri 800 milisekúnd - nie je to nezvyčajné vo veľkej sieti typu unicast -, každá z týchto milisekúnd umožní slnečnému žiareniu dopadnúť na vnútorné sklo v plnej intenzite.

Jedna sekunda oneskorenia sama o sebe nepridáva nič zmysluplné k chladiacej záťaži. Ale vynásobte túto sekundu počtom spúšťacích udalostí za deň, počtom dní v chladiacej sezóne, štvorcovými metrami zasklenia a toto číslo prestane byť triviálne. Západná-fasáda v lete môže spustiť nasadenie tienenia desiatky krát za deň, keď sa uhol slnka posúva a oblačnosť prechádza. Každé neskoré nasadenie je teplo, ktoré teraz musí HVAC systém odstrániť.

LBNL po{0}}štúdii obsadenosti budovy New York Times Building zdokumentovala, že automatizované tienenie integrované s reguláciou stmievania denného svetla{1}} znížilo ročnú spotrebu energie na osvetlenie o 56 % v obvodových zónach. Tento výsledok predpokladal včasné nasadenie. Neskoré žalúzie podkopávajú aritmetiku, vďaka ktorej sa investícia do tienenia vrátila.

Vo vnútri samotnej siete sú tiež sekundárne náklady. Keď príkazy dorazia neskoro, radič ich odošle znova. Opakované prenosy spotrebúvajú vysielací čas, ktorý by mal byť dostupný pre nasledujúci príkazový cyklus. Malá frekvencia opakovania je normálna - každý bezdrôtový protokol to berie do úvahy. Ale pokusy zložené. Skupina, ktorá vidí 2 % opakovaní pri 50 motoroch, môže vidieť 8 % pri 200 a krivka prevádzky nie je lineárna. Každý opakovaný pokus generuje väčšiu návštevnosť, čo generuje viac kolízií, čo generuje viac opakovaní. Inžinieri, ktorí merajú latenciu v priebehu času, často zistia, že sieť sa pomaly saturuje.

Pridanie motorov lineárne nepridáva latenciu

Jednou z pretrvávajúcich mylných predstáv v diskusiách o projekte je, že zdvojnásobenie počtu motorov zdvojnásobí oneskorenie.

Videl som, že sieť so 100 motormi funguje lepšie ako sieť so 60 motormi na rovnakom zásobníku protokolov. Videl som tiež, že sieť s 250 motormi bola roky stabilná, zatiaľ čo sieť so 120 motormi v inej budove potrebovala každých šesť mesiacov opätovné uvedenie do prevádzky.

Premenná nie je počet zariadení. Premenná je spôsob, akým je komunikačný systém navrhnutý: logika zoskupenia, priepustnosť ovládača, výber protokolu, topológia, frekvencia aktualizácie stavu, či je povolený dopyt. Dve budovy s rovnakými motormi, rovnakou bránou a rovnakým firmvérom môžu produkovať úplne odlišné výsledky uvedenia do prevádzky, ak jedna z nich zoskupí všetky žalúzie do jednej zóny a druhá je rozdelená podľa orientácie fasády.

Preto skúsení integrátori skontrolujú konfiguráciu siete skôr, ako sa dotknú hardvéru.

Denníky rozprávali iný príbeh

Na jednom projekte, kde bol efekt zipsu závažný, tím stiahol komunikačné protokoly z týždňa automatických ranných cyklov.

Vzor bol okamžitý. Motor 001 dostal príkaz do 12 milisekúnd. Motor 200 dostal rovnaký príkaz po 940 milisekúndách. Motory nereagovali pomaly - príkazy dostávali v rôznych časoch.

 

Toto zistenie zmenilo celé vyšetrovanie. Nebol to problém s motorickou odozvou. Bol to problém s distribúciou príkazov. Kontrolér prechádzal zariadeniami jedno po druhom cez jednosmerové vysielanie a každý rámec čakal na potvrdenie predchádzajúceho, kým sa odoslal ďalší.

200 motorov × približne 4,7 milisekúnd na snímku (počítajúc čas vysielania, CSMA/CA backoff a ACK obrat)=940 milisekúnd. Matematika sa takmer presne zhodovala s pozorovaným oneskorením.

Komunikačná voľba: Jeden príkaz verzus dvesto individuálnych hovorov

Analógia, ktorá zvyčajne pristane zainteresovaným stranám projektu, je takáto: musíte povedať 200 ľuďom v budove, aby sa zúčastnili stretnutia. Môžete zavolať každému jednotlivo alebo môžete urobiť jedno oznámenie cez systém PA. Rovnaký výsledok. Radikálne odlišný čas na dokončenie.

Skupinová komunikácia funguje rovnako. Unicast sieť generuje jednotlivé pakety pre každý motor a odosiela ich postupne. Každý paket čaká na vymazanie predchádzajúceho. Oneskorenie sa aritmeticky spája s veľkosťou skupiny.

Multicast generuje jeden rámec adresovaný logickej skupine. Každý motor v tejto skupine ho prijíma v rámci rovnakého prenosového okna. Oneskorenie je konštantné bez ohľadu na veľkosť skupiny - čas jednej snímky, nie čas N snímok.

Protokol Matter, spravovaný združením Connectivity Standards Alliance, špecifikuje skupinovú komunikáciu prostredníctvom svojho Groups Cluster. ID skupiny sa mapuje na množinu uzlov tkaniva a jeden prenos multicast dosiahne všetkých členov skupiny súčasne. Toto nie je vlastná technika -, je zabudovaná do špecifikácie protokolu. Praktický rozdiel pre 200-motorové nasadenie je rozdiel medzi jedným rámom a 200 rámami.

Topológia siete: Prečo fyzická vrstva rozhoduje o výsledku

Ďalšou premennou, ktorá určuje, či multicast skutočne funguje vo veľkom rozsahu, je fyzická sieťová vrstva.

V hviezdicovej topológii -, ktorá popisuje väčšinu WiFi a mnohé staršie nasadenia Zigbee - sa každý motor pripája priamo k centrálnemu prístupovému bodu alebo koordinátorovi. Keď jeden motor sedí za betónovou strižnou stenou alebo stúpačkou HVAC, kvalita jeho spojenia klesá nezávisle od každého iného motora. Sieť to kompenzuje opakovaným prenosom alebo znížením rýchlosti prenosu dát pre túto jednu cestu, čo spotrebúva vysielací čas, ktorý by mal byť dostupný pre skupinové príkazy.

Vlákno používa iný model. Vytvára sieť: zariadenia, ktoré sú napájané zo siete-fungujú ako smerovače, ktoré preposielajú prevádzku pre zariadenia napájané z batérie-, ktoré nemôžu byť vždy-na rádiách. Ak je priama cesta k motoru 47 zablokovaná, rám smeruje cez motor 32 a motor 18. Sieť neustále prepočítava cesty na základe metrík kvality spojenia aktualizovaných v reálnom čase. Žiadny jediný bod zlyhania. Žiadny zastavený tok príkazov čakajúci na opätovné odoslanie do jedného uzla, ktorý má problémy.

Sieťový benchmark Silicon Labs, uskutočnený v obsadenej komerčnej kancelárii s aktívnymi sieťami WiFi a Zigbee, poskytuje nezávislú referenciu. Vo veľkých sieťach s miernym užitočným zaťažením: latencia vlákna udržiavaná pod približne 100 ms, Zigbee sa rozšírila na približne 130 ms a sieť Bluetooth sa znížila za 250 ms. Rozdiel narastá s veľkosťou siete a užitočným zaťažením, čo sú presne podmienky, na ktorých záleží pri komerčnom tienení.

Vlákno tiež implementuje frekvenčnú agilitu: ak sa jeden 2,4 GHz kanál nasýti, sieť medzi prenosmi preskočí na čistejší kanál. Aplikačná vrstva motora nikdy nevidí skok. Žiadny opakovaný pokus. Žiadna špička latencie. Toto je štandardná funkcia vlákna špecifikovaná na vrstve MAC IEEE 802.15.4.

Nič z toho neznamená, že vlákno je vždy správna odpoveď. Stále dominuje konštrukcia budovy, hustota zariadení a kvalita uvádzania do prevádzky. Vlákno sa mení v spôsobe degradácie siete pri zaťažení - a pri veľkých nasadeniach tieňovania je ladná degradácia jediným druhom, na ktorom záleží.

Keď fasáda vyzerá pomaly, motory sú posledná vec, ktorú kontrolujem

Jeden starší inžinier mi to raz povedal a platilo to vždy, keď som v teréne videl efekt zipsu.

Jeho pointou nebolo, že motory nikdy nezlyhajú. Bolo to tak, že porucha motora je binárna - motor sa spustí, alebo nie. Degradácia komunikácie je nepretržitá -, zhoršuje sa so zvyšujúcou sa návštevnosťou, ako sa budova zapĺňa, ako sa ostatné systémy pripájajú online. Továrenské akceptačné testy zachytávajú poruchy motora. Málokedy má problémy s komunikáciou, pretože testovacie prostredie nemá takú RF zložitosť ako hotová budova s ​​200 zariadeniami, 50 WiFi prístupovými bodmi a výťahovými motorárňami, ktoré generujú širokopásmové EMI o dve poschodia ďalej.

To je dôvod, prečo sa problémy so synchronizáciou často objavujú počas obsadenia, nie počas uvádzania do prevádzky. Sieť bola v poriadku, keď to bolo jediné, čo bežalo.

Zmerajte pravý koncový bod

Rozhovory o latencii takmer vždy začínajú slovami „aký rýchly je motor?“. Zdá sa mi to ako správna otázka, no zužuje to vyšetrovanie na nesprávne 1 % signálneho reťazca.

Motor môže reagovať do 8 milisekúnd od prijatia príkazu. Ak príchod príkazu trval 900 milisekúnd, skrátenie času odozvy motora z 8 ms na 6 ms vám nič nerobí.

Meranie, na ktorom záleží, je koniec-do{1}}konca: interval od vydania skupinového príkazu ovládačom ku každému motoru, ktorý začína fyzický pohyb. Toto číslo zachytáva ovládač, sieťový zásobník, rádio, MCU motora a výkonový stupeň - všetko, čo je medzi inštrukciou BMS a mechanickým výstupom.

Keď sledujete koniec-do{1}}konca, obraz sa zmení. Dva systémy, ktoré špecifikujú identické časy odozvy motora, sa môžu líšiť o 800 ms-do{5}}v dôsledku toho, ako sieť distribuuje príkazy. Porovnanie so špecifikáciami to nikdy nezachytí.

Priemerná latencia je rozptýlenie

Tu je pasca, do ktorej spadajú inžinieri: porovnávajú priemerné čísla latencie a myslia si, že na otázku odpovedali.

Dva systémy, oba hlásia priemer 18 ms. Na papieri identické. Pri nasadzovaní poskytuje konzistentnú odozvu v úzkom pásme. Druhý občas stúpne na 80 alebo 100 ms počas hustej premávky - a tieto špičky, nie priemer, ľudia vidia, keď sa fasáda pohne.

Oko nevníma priemery. Vníma odľahlé hodnoty. Jediný 100 ms hrot v skupine 300 motorov vytvára viditeľné zaváhanie v jednej časti fasády, a to si majiteľ budovy pamätá. To je dôvod, prečo inžinieri uvedení do prevádzky venujú väčšiu pozornosť 99. percentilu - alebo ešte lepšie maximálne pozorovanej latencii - než priemeru. Predvídateľnosť zakaždým prekoná špičkový výkon.

 

Skutočné{0}}meranie sveta: Čo sme zmerali na našej vlastnej platforme

Pred vydaním aktuálnej riadiacej platformy náš inžiniersky tím vykonal internú validáciu, aby pochopil, ako sa čas odozvy mení s veľkosťou skupiny.

Nastavenie: Rúrkové motory na veci-nad{1}}závitovou sieťou, stabilné vnútorné podmienky, opakované skupinové príkazy pri zvyšujúcom sa počte zariadení. Cieľom nebolo dosiahnuť pôsobivé minimum -, ale overiť, či je latencia pri raste skupiny predvídateľná.

Počas niekoľkých testovacích cyklov so 100 motormi sa väčšina jednotiek začala pohybovať do 20 milisekúnd od skupinového príkazu. Najpomalšie čítanie bolo zhruba 22 ms. Opakované prenosy paketov zostali počas celého obdobia pod 0,5 %.

Nárast bol plynulý - žiadny útes, žiadny bod, kde by sa výkon náhle zrútil. To je dôležitejšie ako absolútne čísla. Systém, ktorý sa pri zaťažení postupne degraduje, možno s istotou nasadiť v akomkoľvek rozsahu. Systém, ktorý funguje dobre pri 40 motoroch a rozpadá sa pri 80, je katastrofa pri uvádzaní do prevádzky, ktorá len čaká.

Toto sú kontrolované-čísla prostredia. Skutočné budovy majú oceľové rámy, sklo Low{2}}E, konkurenčné siete Wi-Fi a obyvatelia chodia s mobilnými zariadeniami. Výsledky v teréne sa budú líšiť. Overenie jednoducho potvrdilo, že architektúra - multicast cez sieť - sa škáluje tak, ako by mala podľa matematiky.

Mechanická stránka: Ani dokonalá komunikácia nedokáže zamaskovať tolerancie

Komunikácia priťahuje pozornosť, pretože v nej žije väčšina skupinovej latencie. Ale aj pri perfektnom dodaní príkazov - môže každý motor, ktorý dostane rovnaký rámec v rovnakom momente, - synchronizácia na mechanickej úrovni prerušiť.

Tolerancie zostavy prevodovky, kolísanie predpätia ložísk, časovanie uvoľnenia bŕzd, sústrednosť výstupného hriadeľa - to všetko ovplyvňuje, ako rýchlo sa motor po prijatí elektrického príkazu prepne zo zastavenia do otáčania. Jednotlivé rozdiely sú niekoľko milisekúnd, neviditeľné. Naprieč niekoľkými stovkami motorov na jednej fasáde sa hromadia do znateľného striedania.

To je dôvod, prečo konzistentnosť výroby nie je oddelenou konverzáciou od komunikačného výkonu. Dve zlúčeniny. Náš výrobný proces drží kľúčové komponenty prevodovky na ±0,05 mm na ložiskových sedlách a profiloch prevodov. Táto tolerancia priamo ovplyvňuje mechanickú opakovateľnosť, od ktorej závisí riadiaca slučka firmvéru.

Prísnejšie tolerancie znamenajú, že spätná väzba polohy kódovača skutočne pristane tam, kde to motor očakáva. Voľnejšie tolerancie znamenajú, že riadiaca slučka neustále koriguje - prekmity, sťahuje sa späť, mikro-osciluje -, čo spaľuje energiu a v tichej kancelárii sa stáva počuteľným, keď sa hluk pri love na hranici zastaví. Presnosť komunikácie a mechanická presnosť sú dve polovice toho istého problému.

Návrh zóny sa uskutoční pred vytiahnutím prvého drôtu

Väčšina zlyhaní synchronizácie je navrhnutá v projekte pred začatím obstarávania.

Najčastejšou chybou je zoskupovanie podľa poschodí, pretože tak sú usporiadané architektonické výkresy. Je to prirodzené. Slnko však nerešpektuje hranice podlahy. Východná fasáda je ráno zaťažená; západná fasáda je zaťažená popoludní. Ak každá roleta na poschodí dostane každý príkaz bez ohľadu na to, či slnko dopadá na jej stranu budovy, sieťová prevádzka sa nafúkne bez funkčného dôvodu.

Jednoduchší prístup: najprv zoskupiť podľa orientácie fasády, ako druhé rozdeliť podľa poschodí v rámci každej orientácie. Východná zóna. Západná zóna. Severná zóna. Južná zóna. Každá skupina multicast obsahuje iba motory, ktoré sa vždy pohybujú spolu - rovnaké slnečné žiarenie, rovnaká logika príkazov. Skupinová návštevnosť klesá. Tlak v rade klesá. Pokles latencie.

Hranica škály: Keď bezdrôtová sieť potrebuje káblového partnera

Existuje bod, kedy čisté bezdrôtové pripojenie začína potrebovať rozhovor o káblovej redundancii a podľa našich skúseností je tento bod niekde za hranicou 500 motorov v jednej sieti budovy.

Pod 300, dobre-navrhnutá sieť vlákien zvláda skupinové ovládanie bez drámy. Hustota siete medzi 300 a 500 si vyžaduje pozornosť: naplánujte si aspoň jedno zariadenie s podporou smerovača-na 15 až 20 koncových bodov, aby sa rozmanitosť smerovacích ciest udržala, keď sú v hre prekážky.

Nad 500 sa náročnosť prevádzky posúva. Aktualizácie firmvéru v tomto rozsahu nasýtia bezdrôtovú sieť, ak si nedáte pozor. Uvedenie zariadenia do prevádzky trvá dlhšie. Štatistická pravdepodobnosť udalosti sieťovej oblasti -, pri ktorej podskupina zariadení dočasne stratí pripojenie k hraničnému smerovaču -, sa zvyšuje s počtom uzlov, aj keď je priemerná kvalita spojenia vynikajúca.

Pri tomto prahu pridanie káblovej chrbticovej siete RS-485 ako paralelnej cesty pre distribúciu firmvéru a núdzové prepnutie neznamená priznanie, že bezdrôtové pripojenie je nespoľahlivé. Je to uznanie, že v budove s 500 motormi nie je udalosť predelenia počas sekvencie integrácie požiarneho poplachu niečo, čo by ste chceli vysvetliť AHJ. Drôtová cesta je poistenie.

Nemocnice, letiská a vládne budovy majú tendenciu špecifikovať hybridnú architektúru bez ohľadu na počet motorov, pretože náklady na prestoje v týchto prostrediach spôsobujú, že káblové zálohovanie predstavuje chybu zaokrúhľovania celkového rozpočtu projektu. Inštitút stavebného priemyslu zdokumentoval, že náklady na prepracovanie - vrátane opätovného uvedenia systému do prevádzky - v priemere predstavujú 12,4 % nákladov na inštalovaný projekt. Redundantná komunikačná chrbtica stojí zlomok opätovného uvedenia 500 motorov do prevádzky po tom, ako sa po obsadení objaví latentný problém so sieťou.

Päť otázok, ktoré sú dôležité pred odhlásením

Po dostatočnom počte cyklov uvádzania do prevádzky sa stále objavujú rovnaké otázky. Nikdy im nejde o krútiaci moment alebo otáčky.

"Každý motor prešiel individuálnym testovaním. Prečo skupina vyzerá pomaly?"

Pozeráte sa na problém s distribúciou príkazov, nie na problém s motorom. Skontrolujte, či ovládač odosiela príkazy jeden po druhom. Skontrolujte frekvenciu aktualizácie stavu. Skontrolujte, či sú všetky motory v jednej predimenzovanej skupine. Vo väčšine prípadov prepnutie na skupinové adresovanie multicast vyrieši viditeľné oneskorenie bez toho, aby ste sa dotkli jediného motora.

"Ak zlyhá jeden motor, zničí to skupinu?"

Nemalo by. Každý motor reaguje nezávisle na rovnaký rámec multicast. Jediný mŕtvy motor - Porucha MCU, skrat kondenzátora, mechanické zaseknutie - zostane sám od seba mŕtvy. Ďalších 199 vykoná príkaz normálne. Ak motor úplne vypadne zo siete, riadiaci panel by ho mal označiť ako nereagujúci- a po obnovení pripojenia by sa mal automaticky znova pripojiť k skupine. Táto izolácia je tvrdou požiadavkou pre akúkoľvek riadiacu platformu produkčnej-triedy.

"Je bezdrôtové pripojenie skutočne spoľahlivé v oceľovej-a{1}}sklenenej veži?"

Áno, ak sú protokol a topológia zvolené pre toto prostredie. Sieťová architektúra vlákna vedie okolo prekážok a nie je závislá od jedného prístupového bodu, ktorý ich prerazí. Frekvenčná agilita odskakuje od nasýtených kanálov bez zapojenia aplikačnej vrstvy. Referenčný test Silicon Labs, ktorý sme citovali vyššie, prebiehal v aktívnej kancelárii s WiFi a Zigbee, ktoré súťažili o vysielací čas -, nie v tienenom laboratóriu - a vlákno malo najnižšiu latenciu vo všetkých testovacích podmienkach.

To znamená, že žiadny protokol nevylučuje potrebu predinštalačného prieskumu RF vo veľkom rozsahu. Budova s ​​metalizovanými vrstvami okien Low{2}}E sa správa inak ako budova s ​​čírym sklom. Sadrokartónové-konštrukcie{5}}svorníkov sa správajú inak ako liate betóny a výstuže. Sieťka zvláda prekážky lepšie ako hviezda. Nerobí fyziku voliteľnou.

"Je nižšia latencia vždy lepšia?"

Len ak je to aj konzistentné. Systém, ktorý vždy dodáva 18 ms, vytvára viditeľne jednotnú fasádu. Systém, ktorý za ideálnych podmienok dokáže zasiahnuť 10 ms, ale pri zvýšenej premávke sa zvýši na 80 ms, vytvára fasádu, ktorá vyzerá nervózne. Pre majiteľov budov je predvídateľnosť to, čo si užívatelia všimnú. Minimálne množstvo špecifikácií je to, o čom hovorí obchodný inžinier na ponukovom stretnutí. Málokedy sú to isté.

Pred spustením ďalšieho projektu

Lekcia, ktorá sa opakuje pri veľkých projektoch tienenia, je jednoduchá: problémy so synchronizáciou takmer nikdy nezačínajú pri motore.

V čase, keď je efekt zipsu viditeľný z ulice, hlavná príčina sa potichu hromadí v komunikačnom systéme niekoľko týždňov alebo mesiacov. Skúsené tímy pri uvádzaní do prevádzky to vedia. Pred objednaním náhradného hardvéru skontrolujú konfiguráciu siete.

Päť dôležitých otázok:

Sú príkazy distribuované multicast alebo unicast?

Koľko zariadení zdieľa každú komunikačnú cestu?

Do akej miery je povolený nepotrebný prieskum stavu?

Zostáva latencia predvídateľná, keď sa počet zariadení zvyšuje?

Dá sa izolovať jediné zlyhanie komunikácie?

Správne zodpovedanie týchto piatich otázok bude mať väčší vplyv na výkon fasády ako ktorákoľvek špecifikácia motora v technickom liste.

Čas odozvy v skutočnosti nie je motorickou metrikou. Je to systémová metrika. Keďže komerčné budovy smerujú k užšej integrácii medzi tienením, osvetlením a HVAC, schopnosť vykonávať načasovaný príkaz naprieč stovkami koncových bodov sa stáva výkonnostným číslom, ktoré definuje, či sa investícia do automatizácie oplatila. Motory sú zriedka prekážkou. Architektúra medzi nimi takmer vždy je.