Multiprotokollos, többsávos IoT-kommunikáció

„A vízcsapból is IoT folyik” – bosszankodhat az Olvasó, de ha az IoT valóban kész arra, hogy a jelen ígéretes próbálkozásaiból a holnap (szó szoros értelmében vett) hétköznapi, elképzelhetetlenül széles körben használható technológiájává váljék, minden információ kevés ahhoz, hogy – akár felhasználóként, akár fejlesztőként – eleget tudhassunk egy sok helyen, sokféle szemlélettel fejlesztett technológia jelenéről és jövőjéről.

Ösztönösen arra törekszünk, hogy kezeljük azt a rengeteg eszközt és rendszert, ami körülvesz minket. Ha belépek egy szobába az otthonomban vagy a munkahelyemen, azt várom, hogy a világítás működését kapcsolókkal irányíthassam. Amikor elmegyek otthonról, élesíteni akarom a biztonsági rendszert és zárni az ajtót. Ezen rendszerek közül jó néhánynak már létezik a jól bevált infrastruktúrája.
Az Internet of Things (IoT) ígérete megváltoztatta az elvárásainkat. Most azt várom, hogy az okostelefonommal, távolról legyek képes felügyelni és vezérelni az otthonomban a hőmérsékletet. Azt várom, hogy a munkahelyem berendezése automatikusan takarékoskodjon az energiával azáltal, hogy egy helyiség világítása kikapcsolódik, ha nem tartózkodik ott senki. Elvárom, hogy az épület „tudja”, hogy hol vagyok, és gondoskodjon arról, hogy a környezetem kényelmes és biztonságos legyen.
Ahhoz, hogy a növekvő mértékben „kommunikatív” világunk működhessen, olyan sok IoT-eszközt és rendszert kell használatba vennünk, hogy azokat még számon tartani is alig vagyunk képesek. A vezetékmentes biztonsági rendszerek, a beléptetőkártyák, a jelenlét- és foglaltság-érzékelők, a hőmérséklet-érzékelő szenzorok és a többi „kapcsolt” eszköz mindenütt jelen van az otthonainkban, a munkahelyeinken, a gyárakban és a városi infrastruktúrában.
A vezetékes és vezetékmentes szenzoroknak azt a hálózatát, ami az IoT alapját képezi, évek-évtizedek óta fejlesztik és használják. Ezeknek a szenzorhálózatoknak a lecserélése igen drága ötlet lenne. Az IoT ígérete emeli a tétet. Az új vezetékmentes szenzor-csomópontok használatba vétele ma sokkal egyszerűbb a többprotokollos technológia miatt (itt például azokra a hardver- és szoftvermegoldásokra gondolunk, amelyek egyetlen rendszer-csippel (System on a Chip – SoC) vagy modullal teszik lehetővé több eltérő protokoll (Bluetooth Low Energy (BLE), Zigbee és Thread) használatát, ráadásul többféle vivőfrekvencián, amelynek tartománya az 1 GHz alatti frekvenciáktól a 2,4 GHz-ig terjed. Viszont, mivel a korai IoT infrastruktúrája a meglevő rendszerekre épül, el kell fogadnunk azt a kihívást, hogy az IoT kezdeteinél felhasznált, régi infrastruktúrát az új, 802.15.4 szabványú vezetékmentes adatátviteli technológiával egészítsük ki. A régi rendszerek támogatásának fenntartása azonban nem az egyetlen kihívás. Ráadásul a hasonló kommunikációs problémák megoldására gyakran használnak versengő protokollszabványokat.

Hardvermegoldás

Az első dolog, amit meg kell értenünk a szenzorok roppant méretű hálózatáról, az, hogy annak csomópontjai mikrovezérlő (MCU) technológián alapulnak, olyan érzékelőelemekhez csatlakozva, amelyek az analóg környezet adatait digitális adatcsomagokká alakítják át. Ha az adat már digitalizálva van, azt gyakran a felhőbe kell küldeni további feldolgozásra. Az e célra választott átviteli módszer rendszerint vezetékmentes. Az ezen a módon továbbított szenzor-adatcsomagok rendszerint kicsinyek, a vezetékmentes csomópontok pedig nagyon hatékonyak a méret, az ár és a teljesítményfelvétel szempontjából.
Ennek a kommunikációs feladatnak a megvalósítására a múltban sok megoldásszolgáltató GHz alatti („szubgigahertzes”) rádiófrekvenciákat, valamint az elem élettartamára optimalizált, „pehelykönnyű” protokollokat alkalmazott. Arra voltak kényszerítve ugyanis, hogy saját protokollokat definiáljanak, mivel a létező protokollok használata vagy túlságosan sok energiafogyasztással járt, vagy nem érte el a szükséges hatótávolságot. Most viszont már sok robusztus, energiatakarékos és szabványos protokoll-lehetőség áll rendelkezésre, mint például a Zigbee, a Thread vagy a Bluetooth Low Energy (BLE).
Az IoT-tervezőknek egy dilemmával kell szembenézniük: hogyan tervezzenek meg egyetlen terméket úgy, hogy az képes legyen mindegyik vezetékmentes szabvány szerint működni, miközben minimális az anyagköltség és a bonyolultság? Nagyon kevés eszközgyártónak van elegendő erőforrása vagy elszántsága ahhoz, hogy önálló terveket készítsen az ioT rendszerekben használt összes lehetséges vezetékmentes szabvány támogatására. A multi-protokollos, többsávos rendszercsipek (System on a Chip – SoC) azáltal szabadítják meg a tervezőket ettől a tervezési dilemmától, hogy a szubgigahertzes frekvencián futtatott egyedi fejlesztésű protokollokat éppúgy támogatják, mint a 2,4 GHz-es sáv szabványos protokolljait – és mindehhez egyetlen, nagy integráltságú félvezetőeszközt felhasználva. Ideális esetben egy multiprotokollos, többsávos SoC két rádiósávhoz tartalmaz vezetékmentes adóvevőt: egyet a szubgigahertzes, egyet pedig a 2,4 GHz-es frekvenciasávhoz. Ez az integrált rádióarchitektúra az IoT fejlesztők számos egyedi alkalmazási elgondolásának megvalósítását teszi lehetővé.
Az 1. ábrán egy tipikus, SoC-be integrált többsávos adóvevő jelfeldolgozási lánca látható. Vegyük észre, hogy a részegységek egy része mindkét frekvenciasávú működésnél használatban van, míg más részei a frekvenciasáv szerint szétválasztva vannak megvalósítva. Az RF-egység például szétválasztott, mivel a két frekvenciasávnak eltérőek az áramkörtechnikai igényei. A „modemegységet” viszont (amely a modulátort, a demodulátort és bizonyos titkosítási hardveregységeket tartalmaz) megosztottan használja mindkét rádió frontend.

1. ábra Példa egy multiprotokollos, többsávos, integrált, vezetékmentes SoC formájában megvalósított adóvevő tömbvázlatára

Ez a rádióarchitektúra a multiprotokollos, többsávos SoC felépítés nagy mértékben optimalizált, kiegyensúlyozott és költséghatékony megközelítése. A modem erőforrásait megosztottan használják a különféle protokollvermek a különböző kommunikációs szabványok megvalósítására. A modem maga is multi-plexelve működik az RF egység vezetékmentes vételi és adási folyamatainak végrehajtásakor. Az architektúra jól illeszkedik a szoftverfejlesztéshez is, mivel egy közös interfészt kínál a rádiókommunikációs felület felé, és lehetőséget ad a fejlesztőnek egy rádiókonfigurációs szoftverréteg kidolgozására, amelyet a különböző protokollvermek megosztottan használhatnak.

A szükséges szoftver

Az a szoftver, amikre egy multiprotokollos, többsávos megoldáshoz szükség van, meglehetősen bonyolult. Az IoT fejlesztők nagyon hatékony vezetékmentes protokollvermeket igényelnek, amelyek a hardvertermékek széles skáláján alkalmazhatók, ráadásul egy valós idejű operációs rendszer (Real Time Operating System – RTOS) többszálas programvégrehajtási rendszerében is használhatók. Egy többprotokollos alkalmazásban a protokollvermeknek problémamentesen kell együtt vagy egymásól függetlenül működniük. Amikor két protokollverem fut ugyanazon a rendszer-csipen a hardver bizonyos elemeinek megosztásával, ezt olyan módon kell végrehajtani, amely a hálózat integritását nem veszélyezteti. A protokollvermeknek olyan módon kell optimalizálva lenniük, hogy egyformán jól működjenek együtt, mint egymástól elkülönítve, anélkül, hogy adattorlódást vagy rossz hatékonyságú működést okoznának. Ez meglehetősen bonyolult feladat.
A többprotokollos megoldások használata jelentős gazdasági előnyöket kínál a rendszerszállítóknak azáltal, hogy optimalizálhatják az eszközbeszerzést, egyszerűsítik a rendszerek telepítését, és járulékos hardverköltség-növekedés nélkül kínálhatnak további értékeket végfelhasználóiknak. Az 1. táblázat négyféle multiprotokollos alkalmazástípust mutat be a jelenkor IoT-alkalmazásaiból.

1. táblázat Multiprotokollos alkalmazástípusok

(A Bluetooth Low Energy (BLE) beacon egy olyan adókészülék (A BLE készülékosztályok egyike), amely kisugározza az azonosítóját a közeli hordozható elektronikus készülékeknek (tablet, okostelefon stb.). Ezáltal ezek – amennyiben a beacon közelében tartózkodnak – képessé válnak különféle adatcsere-műveletek végrehajtására. Néhány tipikus alkalmazása: érdekes helyek (Point Of Interest – POI) közelében lehetőséget ad helyfüggő információk továbbítására, zárt térben történő helymeghatározásra, mobilkereskedelmi alkalmazásokra stb. – A Szerk megj.)

A programozható multiprotokollos kommunikáció a legegyszerűbben elmagyarázható és megvalósítható alkalmazástípus. A folyamatoptimalizálásra és a készpénz-forgalomra fókuszáló beszerzési szakemberek ösztönösen érzik, hogy egyfajta, sok funkcióra használható eszközt jobb készletezni, mint többféle egyfunkciósat, különösen, ha a flexibilisebb termék ártöbblete elhanyagolható. A műszaki tervezésért felelős vezető felismeri, hogy a jókora szoftverkód-mennyiség újrahasznosítható, és a hatékonyságnövekedés abból adódik, hogy egyetlen részegységet sokféle végtermékben lehet felhasználni. Ebben a forgatókönyvben a mérnök egyetlen SoC típust specifikálhat, amely egyaránt alkalmas a Zigbee, a Thread vagy a BLE, sőt, egyedi protokollok futtatására is. Amikor ezt a vásárló cég gyártási folyamata keretében a végtermékbe építik, a vásárlónak a végtermék gyártási folyamata során is elegendő eldöntenie, hogy a Bluetooth vagy szub-gigahertzes protokollt kívánja-e rajta futtatni. Ez a programozható alkalmazástípus tehát lehetővé teszi, hogy a gyártó minimális pénzügyi kockázattal legyen képes maximális flexibilitást adni a gyártott termékeinek.
A kapcsolt multiprotokollos alkalmazástípus jelentős használatiérték-növekedést ad a végfelhasználó kezébe. Ez a technológia például lehetővé teszi egy telepítő vállalat munkatársának, hogy egyetlen terméket szállítson a helyszínre, amelyet például egy okostelefon-alkalmazással tud a végfelhasználó igényének megfelelően konfigurálni. Ez a képesség különösen hasznos például egy csomópont telepítésénél, amelyről a helyszínen, a telepítéssel egy időben lehet eldönteni, hogy Zigbee vagy Thread csomópontként működjön-e. Ha többféle protokollt használó hálózathoz kell eszközt készletezni, az eszközigény előrejelzése nehéz feladat lehet. A kapcsolt multiprotokollos technológia azáltal egyszerűsíti le ezt a feladatot, hogy például az eszköz az életciklusát BLE protokollos készülékként kezdi, és az igények változásával átkapcsolható Zigbee protokollra, ha egy rácstopológiás hálózatra tér át az üzemeltető. A dinamikus multiprotokollos megközelítéssel szemben a kapcsolt multiprotokollos alkalmazásnak az az előnye, hogy kevesebb eszköz-erőforrással valósítható meg, mivel nincs szükség a különféle vezetékmentes eszközök fizikai tárolására és futtatására (2. ábra).

2. ábra A kapcsolt multiprotokollos alkalmazástípus vázlata

A dinamikus multiprotokollos alkalmazástípusban lehetséges, hogy két vagy több protokollon keresztül „beszélgethessen” egy készülék egyetlen SoC fizikai erőforrásainak időbeli megosztásával. A dinamikus multiprotokollhoz általában több erőforrást (például flashmemóriát) kell felhasználni, és bonyolultabb a szoftver architektúrája is. Ez a rádió-alrendszer gondos tervezését is igényli, mivel dinamikusan kell megosztani a rádiórendszer erőforrásait az eltérő protokollok között. A növekvő hardver-erőforrásigénye ellenére ezek a bonyolultság kicsi és kezelhető növekedését jelentik – összehasonlítva azzal a többletértékkel, amivel a dinamikus multiprotokollos kommunikáció járul hozzá annak a rendszernek a használati értékéhez, amelyben alkalmazzák. Sok esetben ez a megközelítés legalább 50%-kal csökkenti a terv bonyolultságát és költségét. Ezek az előnyök abból származnak, hogy egy SoC eszközt kell kettő vagy több IC helyett alkalmazni, amelyeknek ráadásul még eltérő lehet az alkalmazástechnikájuk és a protokollverem-felépítésük. Ha egyetlen, multiprotokollos SoC eszközt használunk egy robusztus RTOS támogatásával, a jól tervezett vezetékmentes protokollvermek és helyi alkalmazás segítségével könnyen megvalósítható egy többféle kommunikációs eljárást használó IoT eszköz.
A 3. ábrán példát láthatunk arra, hogyan működik a dinamikus multiprotokollos kommunikáció, ha háromféle protokollverem fut egyetlen rádióegységen. Az értéknövelő tulajdonságok kézzelfogható előnyökkel és megtakarításokkal teszik értékesebbé az IoT terméket, amelyek a végfelhasználónál is jelentkeznek – például a könnyebb használhatóság formájában.

3. ábra Példa egy dinamikus többprotokollos rendszer időzítésére

A konkurens multiprotokollt különösen a gateway-tervezésben lehet kihasználni, például Zigbee és Thread hálózatok között. Ebben az alkalmazástípusban sok hardver és szoftver erőforrást lehet többszörösen kihasználni a protokollok és a rádiókonfigurációk közötti hasonlóságok miatt. Például a PHY és a MAC rétegek a Thread és a Zigbee között megoszthatók, amely minimalizálja az adóvevő átkonfigurálási igényét. Ezen kívül a Thread és a Zigbee több közös elemet is megoszthat a protokollverem magasabb szintjein is, amellyel az erőforrásmegosztás hatékonyabbá és közvetlenebben menedzselhetővé válik. Ebben az esetben tehát kisebb memóriakapacitású eszközök használata is elegendő, amely segít a végtermék anyagköltségének csökkentésében.

Összefoglalás

Csupán egy maroknyi SoC-gyártó létezik, akik jelenleg multi-protokollos megoldásokat ajánlanak nagy integráltságú SoC eszközökkel és optimalizált szoftverrel megvalósítva, ráadásul úgy, hogy már ma elérhetők azok a fejlesztőeszközök, amelyekkel egyszerűbbé tehető a multiprotokollos vezetékmentes fejlesztés folyamata. Fontos kihívás, hogy megértsük, mely vezetékmentes protokollvermeket nem kell egyedileg, a többiektől függetlenül figyelembe venni, hanem elegendő, ha egy egységes, átfogó rendszer elemeként, egymással problémamentesen együttműködve valósítjuk meg őket. Ez könnyűnek hangzik, de a gyakorlatban egyáltalán nem az. Néha a vezetékmentes tervezőcsapatok a világban szétszórtan dolgoznak, eltérőek a fejlesztési céljaik, és más-más üzleti csoport érdekeit szolgálják. Ez a szétforgácsolódás akadályt gördít a robusztus, problémamentesen együttműködő többprotokollos rendszerek megvalósítása elé. Ha megpróbáljuk a különféle cégek és érdekcsoportok által definiált sokféle protokollvermet együtt működtetni – ráadásul megbízhatóan és a teljesítményigényt és a memóriát észszerű határok közé szorítva – ez majdnem lehetetlen feladat.
Egy memória- és fogyasztáskorlátozott rendszerben fontos a hatékony hozzáférés a hardvereszközökhöz, és ezért el kell kerülni a processzor-óraciklusok és a memória pazarló felhasználását, és ugyanezért szükséges a protokollvermet is a korlátozott hardveradottságokhoz igazítani. A protokollvermet egységes módon kell a hardverhez illeszteni, hogy egyszerű legyen a váltás az eltérő protokollvermek között. Máskülönben konfliktushelyzetekkel szembesülünk, és energiapazarlás is történik. A feleslegesen elhasznált processzorciklusok pedig jelentősen csökkentik az elem élettartamát. A protokollvermek nem hatékony megvalósítása növeli a memóriafelhasználást, ami pedig felhajtja a rendszer anyagköltségét. Hogy sikeresek lehessünk a problémamentes integráció terén, a megoldásszállítónak gondosan mérlegelnie kell a rendszer minden elemét: a hardvert (SoC vagy modul), a rádiókommunikáció ütemezőjét, a protokollvermeket és a valós idejű operációs rendszert ahhoz, hogy a kommunikációs képességekkel felruházott hardver támogathassa a multiprotokollos kommunikációt.
A multiprotokollos világ már itt van, és a multiprotokollos, többsávos megoldások folyamatos terjedése várható, mivel nincs egyetlen olyan vezetékmentes protokoll sem, amely minden IoT alkalmazáshoz egyformán megfelelő megoldást jelentene.
Ahogy a világunkban egyre általánosabbá válik a kommunikáció, folytatnunk kell a kommunikáló készülékek és a beágyazott szoftver fejlesztését annak érdekében, hogy az IoT szerteágazó igényeihez is képesek legyenek megoldást kínálni.

Tom Pannell, igazgató – Silicon Labs, IoT Marketing

www.silabs.com

Még több Silicon Labs