A késleltetés rejtett költsége: Miért számít{0}}a valós idejű válasz a csoportvezérlésben

A jelenség: Amikor egy függönyfalból „cipzár hiányzik a fogak”

Az üzembe helyező csapat először a motorokra gyanakodott.

A projekt éppen a végső tesztelésbe lépett. Minden hétköznap reggel 8:30-kor az épületfelügyeleti rendszer leengedte a keleti homlokzati redőnyöket, hogy csökkentse a napsugárzást, mielőtt a lakók megérkeznének. A parancs egyszerű volt: több száz motor, ugyanaz az előre beállított pozíció, ugyanaz az idő.

A homlokzat soha nem mozdult össze.

Az első sor szinte azonnal válaszolt. Mások a másodperc töredékével később követték. Néhányan megálltak, majd utolértek. Mire az utolsó szakasz elindult, az első szakasz már leállt.

Az épület belsejéből alig vetted észre. Az utcáról a függönyfal úgy nézett ki, mint egy cipzár, hiányzó fogakkal.

Nincs riasztás. Minden motor egyéni funkcionális tesztelésen esett át. A hálózat egész nap fent volt.

Miért ne tudna több száz egyedileg működő motor egyetlen szinkronizált mozgást végrehajtani?

Ez a kérdés gyakrabban merül fel, mint azt a legtöbb projektspecifikáció feltételezi. Ahogy az árnyékolási telepítések mérete meghaladja az 50 vagy 100 motort épületenként, a különbség aközött, amit egy motor képes egyedül és a rendszer együtt, a teljesítmény mérőszámává válik.

A tévhit: A motor szinte soha nem az igazi probléma

Íme egy minta, amelyet több projektben is láttam: először a motorokat hibáztatják, másodszor cserélik, és harmadszor igazolják.

Az egyedi funkcionális tesztelés minden egységen tiszta. A nyomatékgörbék a specifikáción belül vannak. A menetsebesség megegyezik az adatlappal. A zajszint rendben van. De amikor mind a kétszáz motor csoportos parancsot kap, a homlokzat kaszkádba megy, ahelyett, hogy egyetlen felületként pattanna a helyére.

Ezen a ponton a motorok cseréje a legdrágább módja annak, hogy megtanuljuk, hogy soha nem a motorokkal volt a probléma.

A vizsgálat szinte mindig a kommunikációs lánc felé tolódik el: BMS-től átjáróig, átjárótól hálózatig, hálózattól motorvezérlőig. Válasszon le egy tucat motort a csoportról, és{1}}tesztelje újra. Ha a késleltetés alig mozog, a szűk keresztmetszet felfelé van.

A milliszekundumok terjedése: hogyan válnak láthatóvá az apró késések

A matematika méretarányosan megbocsáthatatlan.

Egy motor 100 ezredmásodperces késéssel indul - senki sem látja. De ugyanazt a 100 ms-ot oszd szét háromszáz motoron tizenöt emeleten, és a késleltetés továbbterjed. A parancsok különböző pillanatokban érik el a különböző hálózati szegmenseket. Ami csomag szinten a másodperc töredéke volt, az a homlokzaton átgördülő hullám lesz.

Az üzembe helyező mérnököknek van egy informális neve is: cipzár-effektus. A név ragad, mert pontosan leírja, amit látsz.

Meg kell érteni, hogy a cipzár hatás tünet, nem diagnózis. Amikor meglátja, valahol a vezérlő és a motorok között, a parancsok időzítése inkonzisztens. Megtalálni, hol van a tényleges munka.

Miért veszik ezt komolyan a fejlesztők?

Az automatizált homlokzatú, szinkronból kilépő prémium irodai toronynak olyan problémája van, amely túlmutat a tervezésen. A homlokzat az épület vizuális arculatának része. Amikor működik, az automatizálás láthatatlan. Ha nem, minden bérlő a 15. emeleten észreveszi az első kávé előtt.

Ugyanazt a panaszt hallottam két teljesen különböző módon megfogalmazva. A mérnökök szerint "látenciát látunk a multicast csoportban". A létesítményvezetők szerint "a redőnyök már nem mozognak együtt". Ugyanaz a probléma, más nyelv. Mindkettő ugyanabba a gyökérre vezet vissza.

A fejlesztők számára a költség a hitelesség. A lakók számára ez az épület technológiájába vetett bizalom. Az üzembe helyező csapat számára kiszámlázhatatlan órák egy szellem üldözése.

Az energiaköltség: Minden késői másodperc összeadódik

A nappali fényérzékelő egy előre beállított besugárzási küszöbértéknél aktiválódik. A redőnyöknek azonnal ki kell nyílniuk. De ha a csoportparancs 800 ezredmásodpercig terjed, - nem szokatlan egy nagy unicast hálózatban -, minden ezredmásodperc lehetővé teszi, hogy a napsugárzás teljes intenzitással elérje a belső üveget.

Egy másodperces késleltetés önmagában semmi értelmeset nem ad hozzá a hűtési terheléshez. De megszorozzuk ezt a másodpercet a napi kiváltó események számával, a hűtési szezonban eltöltött napok számával, az üvegezés négyzetméterével, és a szám már nem triviális. Nyáron a nyugati-homlokzat árnyékolást válthat ki naponta több tucatszor, ahogy a nap szöge eltolódik és a felhőzet elhalad. Minden késői üzembe helyezés hőt jelent, amelyet a HVAC-rendszernek most el kell távolítania.

A New York Times Building LBNL{0}}utáni kihasználtsági tanulmánya dokumentálta, hogy a nappali fény-sötétítési vezérléssel integrált automatikus árnyékolás 56%-kal csökkentette az éves világítási energiafelhasználást a kerületi zónákban. Ez az eredmény időben történő telepítést feltételezett. A késői vakok aláássa az aritmetikát, amely az árnyékoló befektetést megtérülővé tette.

Magán a hálózaton belül van egy másodlagos költség is. Ha a parancsok későn érkeznek, a vezérlők újraküldik. Az újraküldések adásidőt fogyasztanak, amelynek a következő parancsciklushoz rendelkezésre kell állnia. Egy kis újrapróbálkozási gyakoriság normális - minden vezeték nélküli protokoll figyelembe veszi. De újrapróbálja az összetettet. Egy olyan csoport, amely 50 motornál 2%-os újrapróbálkozást lát, 200 motornál 8%-ot láthat, és a forgalmi görbe nem lineáris. Minden újrapróbálkozás több forgalmat generál, ami több ütközést, ami több újrapróbálkozást generál. Azok a mérnökök, akik az idő múlásával mérik a késleltetést, gyakran felfedezik, hogy a hálózat lassan telítődik.

A motorok hozzáadása nem növeli a késleltetést lineárisan

A projektmegbeszélések során az egyik leggyakrabban előforduló tévhit az, hogy a motorszám megkétszerezése megduplázza a késleltetést.

Láttam, hogy egy 100 motoros hálózat jobban teljesít, mint egy 60 motoros hálózat ugyanazon a protokollveremen. Azt is láttam, hogy egy 250 motoros hálózat évek óta stabilan működik, miközben egy másik épületben lévő 120 motoros hálózatot félévente újra kellett üzembe helyezni.

A változó nem eszközszám. A változó a kommunikációs rendszer felépítése: csoportosítási logika, vezérlő átviteli sebessége, protokoll kiválasztása, topológia, állapotfrissítés gyakorisága, a lekérdezés engedélyezve van-e. Két épület azonos motorral, ugyanazzal az átjáróval és ugyanazzal a firmware-rel teljesen eltérő üzembe helyezési eredményeket produkálhat, ha az egyik az összes redőnyt egyetlen zónába csoportosítja, a másik pedig a homlokzati tájolás szerint particionálja.

Ez az oka annak, hogy a tapasztalt integrátorok ellenőrzik a hálózati konfigurációt, mielőtt hozzányúlnának a hardverhez.

A rönkök más történetet meséltek el

Az egyik projektnél, ahol a cipzárhatás súlyos volt, a csapat kommunikációs naplókat húzott ki egy hét automatizált reggeli ciklusból.

A minta azonnali volt. A 001-es motor 12 ezredmásodpercen belül megkapta a parancsot. A 200-as motor ugyanazt a parancsot kapta 940 ezredmásodperc után. A motorok nem reagáltak lassan - különböző időpontokban kapták a parancsot.

 

Ez a megállapítás megváltoztatta az egész nyomozást. Ez nem motoros reakcióprobléma volt. Parancselosztási probléma volt. A vezérlő egyenként iterált az eszközökön keresztül unicast, és minden képkocka várt az előző nyugtára, mielőtt a következőt elküldték volna.

200 motor × nagyjából 4,7 ezredmásodperc képkockánként (beleszámítva a műsoridőt, a CSMA/CA visszalépést és az ACK átfutási idejét)=940 ezredmásodperc. A matematika szinte pontosan megegyezett a megfigyelt késéssel.

A kommunikációs választás: egy parancs a kétszáz egyéni hívás ellen

Az analógia, amely általában a projektben érdekelt felekkel találkozik, a következő: 200 embernek kell szólnia egy épületben, hogy részt vegyen egy értekezleten. Mindegyiket külön-külön felhívhatja, vagy bejelentést tehet a PA rendszeren keresztül. Ugyanaz az eredmény. Gyökeresen eltérő befejezési idő.

A csoportos kommunikáció ugyanúgy működik. Az unicast hálózat minden motorhoz egyedi csomagokat generál, és szekvenciálisan küldi el. Minden csomag az előző törlésére vár. A késleltetés aritmetikailag összeáll a csoport méretével.

A csoportos küldés egy keretet generál egy logikai csoportnak címezve. A csoport minden motorja ugyanazon az átviteli ablakon belül kapja meg. A késleltetés állandó, függetlenül a csoport méretétől - egy képkockaidő, nem pedig N képkockaidő.

A Connectivity Standards Alliance által fenntartott Matter protokoll a Csoportok fürtjén keresztül határozza meg a csoportos kommunikációt. A csoportazonosító leképez egy csomópont-készletet, és egyetlen csoportos küldés egyszerre éri el az összes csoporttagot. Ez nem szabadalmaztatott technika -, a protokoll specifikációjába van beépítve. A gyakorlati különbség egy 200 motoros telepítésnél az egy képkocka és a 200 képkocka közötti különbség.

A hálózati topológia: Miért a fizikai réteg dönti el az eredményt

A másik változó, amely meghatározza, hogy a multicast valóban nagy méretekben működik-e, a fizikai hálózati réteg.

Egy csillag-topológiában -, amely leírja a legtöbb WiFi-t és számos régi Zigbee-telepítést, - minden motor közvetlenül csatlakozik egy központi hozzáférési ponthoz vagy koordinátorhoz. Ha az egyik motor betonnyírófal vagy HVAC-felszálló mögött ül, a kapcsolat minősége minden más motortól függetlenül romlik. A hálózat az adott útvonal újraküldésével vagy adatsebességének csökkentésével kompenzálja, ami a csoportparancsokhoz rendelkezésre álló műsoridőt fogyasztja.

A szál más modellt használ. Hálózatot épít fel: a hálózatról{1}} működő eszközök útválasztóként működnek, és továbbítják a forgalmat olyan akkumulátoros-eszközökhöz, amelyek nem tudnak mindig-tartani a rádiókon. Ha a 47 motorhoz vezető közvetlen út blokkolva van, a keret a 32 motoron és a 18 motoron halad keresztül. A háló folyamatosan újraszámolja az útvonalakat a valós időben frissített kapcsolatminőségi mérőszámok alapján. Nincs egyetlen kudarcpont. Nincs elakadt parancsfolyam, amely újraküldésre vár egy problémás csomóponthoz.

A Silicon Labs mesh hálózati benchmark, amelyet egy elfoglalt kereskedelmi irodában hajtanak végre, aktív WiFi és Zigbee hálózatokkal, független referenciaként szolgál. Mérsékelt terheléssel rendelkező nagy hálózatokban: A szál késleltetése nagyjából 100 ms alatt volt, a Zigbee nagyjából 130 ms-ra terjedt, a Bluetooth mesh pedig 250 ms-nál leromlott. A szakadék a hálózat méretével és hasznos terhelésével növekszik, pontosan azok a feltételek, amelyek a kereskedelmi árnyékolás szempontjából fontosak.

A Thread a frekvencia agilitását is megvalósítja: ha egy 2,4 GHz-es csatorna telítődik, a hálózat egy tisztább csatornára ugrik az adások között. A motoros alkalmazási réteg soha nem látja az ugrást. Nincs újrapróbálkozás. Nincs késleltetési csúcs. Ez az IEEE 802.15.4 MAC rétegben meghatározott szabványos szál szolgáltatás.

Mindez nem jelenti azt, hogy a szál mindig a megfelelő válasz. Továbbra is az épületszerkezet, a készüléksűrűség és az üzembe helyezési minőség dominál. A Thread változásai az, hogy a hálózat hogyan romlik terhelés alatt -, és nagy árnyékolási telepítések esetén a kecses degradáció az egyetlen, ami számít.

Amikor a homlokzat lassúnak tűnik, a motorok az utolsó, amit ellenőrizni kell

Egy vezető üzembe helyező mérnök mondta ezt nekem egyszer, és ez minden alkalommal igaz volt, amikor cipzárhatást láttam a terepen.

Nem az volt a célja, hogy a motorok soha nem hibáznak. Úgy volt, hogy a motorhiba bináris - egy motor elindul, vagy nem. A kommunikáció romlása folyamatos -, rosszabbodik a forgalom növekedésével, ahogy megtelik az épület, ahogy más rendszerek kapcsolódnak online. A gyári átvételi vizsgálat észleli a motorhibákat. Ritkán észleli a kommunikációs problémákat, mert a tesztkörnyezetben nincs olyan RF komplexitás, mint egy kész épület 200 eszközzel, 50 WiFi hozzáférési ponttal és két emelettel odébb szélessávú EMI-t generáló lift motorterekkel.

Ez az oka annak, hogy a szinkronizálási problémák gyakran a használat során merülnek fel, nem pedig az üzembe helyezéskor. A hálózat rendben volt, amikor csak ez működött.

Mérje meg a jobb végpontot

A késleltetésről szóló beszélgetések szinte mindig azzal kezdődnek, hogy "milyen gyors a motor?" Jó kérdésnek tűnik, de leszűkíti a vizsgálatot a jellánc rossz 1%-ára.

A motor 8 ezredmásodperc alatt tud reagálni a parancs fogadása után. Ha a parancs megérkezése 900 ezredmásodpercbe telt, a motor válaszidejének 8 ms-ról 6 ms-ra csökkentése semmit sem jelent.

A mérés a végétől-végig-végig számít: a vezérlő csoportparancs kiadásától az egyes motorok fizikai mozgásának megkezdéséig eltelt idő. Ez a szám rögzíti a vezérlőt, a hálózati veremet, a rádiót, a motor MCU-ját és a teljesítményfokozatot - mindent, ami a BMS utasítás és a mechanikus kimenet között helyezkedik el.

A végétől-végéig-végig követve a kép megváltozik. Két rendszer, amelyek azonos motorválaszidőt határoznak meg, 800 ms-kal eltérhet a végétől-végéig-, attól függően, hogy a hálózat hogyan osztja el a parancsokat. A specifikációs lap összehasonlítása soha nem találja meg.

Az átlagos késleltetés zavaró

Itt van egy csapda, amibe a mérnökök beleesnek: összehasonlítják az átlagos késleltetési számokat, és azt hiszik, hogy megválaszolták a kérdést.

Két rendszer, mindkettő 18 ms átlagot jelez. Papíron egyforma. Üzembe helyezéskor az ember egy szűk sávon belül egységes választ ad. A másik esetenként 80 vagy 100 ms-ig ugrik nagy forgalom esetén -, és ezeket a tüskéket látják, nem az átlagot, amikor a homlokzat elmozdul.

A szem nem érzékeli az átlagokat. Kiugró értékeket észlel. Egyetlen 100 ms-os tüske egy 300 motorból álló csoportban látható habozást kelt a homlokzat egyik szakaszán, és erre emlékszik az épület tulajdonosa. Ez az oka annak, hogy az üzembe helyező mérnökök jobban odafigyelnek a 99. percentilisre - vagy még jobb, a maximális megfigyelt késleltetésre -, mint az átlagra. A kiszámíthatóság minden alkalommal felülmúlja a csúcsteljesítményt.

 

A valódi-világ mérése: amit a saját platformunkon mértünk

A jelenlegi vezérlőplatform kiadása előtt mérnöki csapatunk belső ellenőrzést végzett, hogy megértse, hogyan skálázódik a válaszidő a csoport méretével.

A beállítás: csőmotorok egy ügyben-over-szálhálózaton, stabil beltéri körülmények, ismétlődő csoportparancsok növekvő számú eszközön keresztül. A cél nem az volt, hogy elérjük a lenyűgöző minimumot -, hanem annak ellenőrzése, hogy a várakozási idő kiszámítható maradjon a csoport növekedésével.

A 100 motorral végzett több tesztciklus során a legtöbb egység a csoportparancstól számított 20 ezredmásodpercen belül elindult. A leglassabb olvasás nagyjából 22 ms volt. A csomagok újraküldése mindvégig 0,5% alatt maradt.

A növekedés zökkenőmentes volt - nincs szikla, nincs olyan pont, ahol a teljesítmény hirtelen összeomlott volna. Ez többet számít, mint az abszolút számok. A terhelés hatására fokozatosan lebomló rendszer bármilyen léptékben biztonsággal telepíthető. Az a rendszer, amely 40 motornál jól működik, és 80-nál szétesik, üzembe helyezési katasztrófa, amely megtörténik.

Ezek ellenőrzött{0}}környezeti számok. A valódi épületek acélvázzal, alacsony-E üveggel, versengő WiFi-hálózatokkal rendelkeznek, és a lakók mobileszközökkel sétálnak. A terepi eredmények eltérőek lesznek. Az ellenőrzés egyszerűen megerősítette, hogy a - multicast over mesh - architektúra a matematikai előrejelzések szerint skálázódik.

A mechanikai oldal: még a tökéletes kommunikáció sem képes elfedni a tűréseket

A kommunikáció felkelti a figyelmet, mert itt él a legtöbb csoport késleltetése. De még tökéletes parancskiadás esetén is - minden motor, amely ugyanabban a pillanatban kapja meg ugyanazt a keretet -, a szinkronizálás mechanikai szinten is megszakadhat.

A sebességváltó szerelvény tűrése, a csapágy előfeszítésének változása, a fék kioldásának időzítése, a kimenő tengely koncentrikussága - ezek mind befolyásolják, hogy a motor milyen gyorsan vált át álló helyzetből forgásba, miután megkapta az elektromos parancsot. Egyénileg a különbségek néhány milliszekundum, láthatatlanok. Egy homlokzaton több száz motoron felhalmozódnak észrevehető lépcsőzetessé.

Ez az oka annak, hogy a gyártási következetesség nem különíthető el a kommunikációs teljesítménytől. A két vegyület. Gyártási folyamatunk során a kulcsfontosságú erőátviteli alkatrészeket ±0,05 mm-re rögzítjük a csapágyüléseken és a fogaskerekek profiljain. Ez a tűrés közvetlenül befolyásolja azt a mechanikai ismételhetőséget, amelytől a firmware vezérlőkör függ.

A szigorúbb tűréshatárok azt jelentik, hogy a jeladó helyzet-visszacsatolása valójában ott érkezik, ahol a motor elvárja. A lazább tűréshatárok azt jelentik, hogy a vezérlőhurok folyamatosan korrigálja a - túllövést, visszahúzódást, mikro-oszcillációt -, ami energiát éget, és csendes irodában hallhatóvá válik, ahogy a vadászat zaja leáll a határnál. A kommunikációs pontosság és a mechanikai precizitás ugyanazon probléma két fele.

A zóna kialakítása az első vezeték kihúzása előtt történik

A legtöbb szinkronizálási hibát a beszerzés megkezdése előtt tervezik be a projektbe.

A leggyakoribb hiba az emeletek szerinti csoportosítás, mert így vannak rendszerezve az építészeti rajzok. Természetesnek tűnik. De a nap nem tartja tiszteletben a padló határait. A keleti homlokzat reggeli terhelést kap; egy nyugati homlokzat délutáni terhelést kap. Ha egy emeleten minden redőny megkap minden parancsot, függetlenül attól, hogy a nap eléri-e az épület oldalát, a hálózati forgalom funkcionális okok nélkül megnövekszik.

Az egyszerűbb megközelítés: először homlokzati tájolás szerint csoportosítson, majd minden tájoláson belül emeletenként osztson fel. Keleti zóna. Nyugati zóna. Északi zóna. Déli zóna. Minden multicast csoport csak olyan motorokat tartalmaz, amelyek mindig együtt mozognak - ugyanaz a napsugárzás, ugyanaz a parancslogika. Csökken a csoportforgalom. A sornyomás csökken. A késleltetés csökken.

A léptékküszöb: amikor a vezeték nélküli hálózathoz vezetékes partnerre van szüksége

Van egy pont, ahol a tisztán vezeték nélküli kommunikációnak szüksége van a vezetékes redundanciáról szóló beszélgetésre, és tapasztalataink szerint ez a pont valahol 500 motoron túl van egyetlen épület hálózatán.

300 alatt egy jól-megtervezett Thread háló dráma nélkül kezeli a csoportvezérlést. 300 és 500 között a hálósűrűségre figyelni kell: 15-20 végpontonként legalább egy útválasztó{5}}képes eszközt tervezzen, hogy az útválasztási útvonalak sokfélesége fennmaradjon, ha akadályok vannak.

500 felett a műveleti összetettség eltolódik. Az ilyen léptékű firmware-frissítések telítik a vezeték nélküli hálózatot, ha nem vigyáz. A készülék üzembe helyezése tovább tart. Egy olyan mesh-partíciós esemény statisztikai valószínűsége -, ahol az eszközök egy része átmenetileg elveszíti a kapcsolatot a határútválasztóval -, a csomópontok számának növekedésével növekszik, még akkor is, ha az átlagos kapcsolatminőség kiváló.

Ezen a küszöbértéken az RS-485 vezetékes gerinchálózat párhuzamos útvonalként történő hozzáadása a firmware-elosztáshoz és a feladatátvételhez nem jelenti azt, hogy a vezeték nélküli kapcsolat megbízhatatlan. Elismerés, hogy egy 500 motoros épületben a tűzriasztás integrációs szekvenciája során bekövetkező partíciós eseményt nem kell elmagyarázni az AHJ-nek. A vezetékes út biztosítás.

A kórházak, repülőterek és kormányzati épületek a motorszámtól függetlenül általában hibrid architektúrát határoznak meg, mivel az ilyen környezetekben a leállások költsége a vezetékes biztonsági mentést kerekítési hibává teszi a projekt teljes költségvetésében. Az Építőipari Intézet dokumentálta, hogy az utómunkálati költségek -, beleértve a rendszer újra üzembe helyezését is, - átlagosan a telepített projekt költségének 12,4%-át teszik ki. A redundáns kommunikációs gerinchálózat 500 motor újbóli üzembe helyezése töredékébe kerül, miután egy látens hálózati probléma felszínre kerül -a kihasználtság után.

Az öt fontos kérdés a kijelentkezés előtt

Elegendő üzembe helyezési ciklus után továbbra is ugyanazok a kérdések jelennek meg. Ezek soha nem a nyomatékról vagy a fordulatszámról szólnak.

"Minden motor átment az egyéni tesztelésen. Miért tűnik lassúnak a csoport?"

Parancselosztási problémát keres, nem motoros problémát. Ellenőrizze, hogy a vezérlő egyenként küld-e ki parancsokat. Ellenőrizze az állapotfrissítés gyakoriságát. Ellenőrizze, hogy az összes motor egyetlen túlméretezett csoportba tartozik-e. A legtöbb esetben a csoportos küldési csoportcímzésre váltás megoldja a látható késleltetést egyetlen motor érintése nélkül.

"Ha az egyik motor meghibásodik, leveszi a csoportot?"

Nem szabadna. Mindegyik motor függetlenül reagál ugyanarra a multicast keretre. Egyetlen halott motor - MCU hiba, kondenzátor rövidzárlat, mechanikus elakadás - önmagában halott marad. A többi 199 normál módon hajtja végre a parancsot. Ha egy motor teljesen kiesik a hálózatból, a felügyeleti irányítópultnak meg kell jelölnie, hogy nem reagál, és automatikusan újra csatlakoznia kell a csoporthoz, amikor a kapcsolat helyreáll. Ez az elkülönítés szigorú követelmény minden éles -szintű vezérlőplatformnál.

"Valóban megbízható a vezeték nélküli acél{0}}és-üvegtoronyban?"

Igen, ha a protokollt és a topológiát az adott környezethez választották. A szál hálóarchitektúrája inkább az akadályok körüli útvonalakat vezeti be, nem pedig egy hozzáférési ponttól függ, amely átüti őket. A frekvencia mozgékonysága az alkalmazási réteg bevonása nélkül távolodik a telített csatornáktól. A Silicon Labs korábban idézett benchmarkja egy aktív irodában futott, ahol a WiFi és a Zigbee versengett a műsoridőért - nem árnyékolt labor -, és a Thread tartotta a legalacsonyabb késleltetést minden tesztkörülmény között.

Ennek ellenére egyetlen protokoll sem szünteti meg a telepítés előtti-léptékű rádiófrekvenciás felmérés szükségességét. A fémezett Low-E ablakbevonattal ellátott épületek másképpen viselkednek, mint az átlátszó üvegűek. A gipszkarton-a-csapon lévő szerkezet másként viselkedik, mint az öntött beton és a betonacél. A háló jobban kezeli az akadályokat, mint a csillag. Ez nem teszi választhatóvá a fizikát.

"Az alacsonyabb késleltetés mindig jobb?"

Csak ha az is következetes. A minden alkalommal 18 ms-ot leadó rendszer láthatóan egységes homlokzatot hoz létre. Egy olyan rendszer, amely ideális körülmények között 10 ms-t képes elérni, de a forgalom növekedésével 80 ms-ra ugrik, idegesnek tűnő homlokzatot eredményez. Az épülettulajdonosok számára a kiszámíthatóság az, amit a lakók észrevesznek. A specifikációs lap minimum az, amiről az értékesítési mérnök beszél az ajánlattételi értekezleten. Ritkán ugyanazok.

Mielőtt a következő projekt elkezdődik

A nagy árnyékolási projektek során megismétlődő lecke egyszerű: a szinkronizálási problémák szinte soha nem kezdődnek a motornál.

Mire a cipzárhatás láthatóvá válik az utcáról, a kiváltó ok már hetek-hónapok óta halkan halmozódik a kommunikációs rendszerben. A tapasztalt üzembe helyező csapatok tudják ezt. A cserehardver megrendelése előtt ellenőrzik a hálózati konfigurációt.

Az öt fontos kérdés:

A parancsokat multicast vagy unicast terjesztik?

Hány eszköz osztozik az egyes kommunikációs útvonalakon?

Mennyi szükségtelen állapotlekérdezés van engedélyezve?

Megjósolható marad a késleltetés az eszközök számának növekedésével?

Elszigetelhető egyetlen kommunikációs hiba?

Ennek az öt kérdésnek a helyes megválaszolása nagyobb hatással lesz a homlokzati teljesítményre, mint bármely motorspecifikáció az adatlapon.

A válaszidő valójában nem motoros mérőszám. Ez egy rendszermérő. Ahogy a kereskedelmi épületek az árnyékolás, a világítás és a HVAC közötti szorosabb integráció felé törekszenek, az időzített parancs végrehajtásának képessége több száz végponton válik azzá a teljesítményszámmá, amely meghatározza, hogy megérte-e az automatizálási beruházást végrehajtani. A motorok ritkán jelentik a szűk keresztmetszetet. A köztük lévő architektúra szinte mindig az.