magyar elektronika

E-mail cím:*

Név:

enb l475e iot01aA cikk előző részében bemutattunk egy olyan demonstrációs eszközt (STM32 Discovery kit IoT node), amelynek – a hardvergyártók szokásos demókitjein messze túlmutatva – nem csak egy alkatrész (az STMicroelectronics 32 bites szóhosszúságú ARM Cortex–M4 magos mikrovezérlője) használhatóságának bemutatása a célja, hanem az IoT-alkalmazások teljes „vertikumáról” segít fogalmat alkotni az érdeklődőnek a hardvertől a szoftveren át a felhőszolgáltatásig. 

A cikk jelen második része ez utóbbi sajátosságaira világít rá.

 

 

 

Vegyen részt az EBV szakmai napján!

 

EBV Budapest Tech Day 2018

Rendezvény neve: 

Xilinx and surroundings

Helyszíne:

Courtyard Budapest City Center, 1088 Budapest, József krt. 5.

Időpontja:  

2018. április 10. 8:30-17:30

 

A rendezvény ingyenes, de regisztrációhoz kötött.

A regisztrációért kattintson erre a linkre

 

  

A felhőszolgáltatás

Számos IoT-alkalmazás az internetet csupán kommunikációs médiumként használja a végpont és valamilyen, a felhasználó birtokában levő adatgyűjtő és -feldolgozóberendezés között. Ennél ígéretesebb és a XXI. századi trendeknek jobban megfelel az a szemlélet, amely az adatot „nyílt felhasználású”, tetszés szerinti helyről és időpontban elérhető erőforrásnak tekinti, amelyhez – kellő jogosultság birtokában – bárki hozzáférhet. 

Az utóbbi évtized alapvető szemléletváltozásának eredménye a „Big Data” fogalmának megjelenése. A „zárt” szemlélet szerint az adatgyűjtés technikai megvalósítására akkor kerül sor, ha erre közvetlen, „fizetőképes” igény merül fel. Az egységnyi információmennyiség fajlagos továbbítási és tárolási költségeinek drasztikus csökkenése azonban lehetővé teszi, hogy ne csak egy konkrét felhasználási igény kielégítésére gyűjtsünk adatokat, hanem – kis túlzással – akár még amolyan „valamire csak jó lesz”-alapon is. Az előbbi megoldást ahhoz hasonlíthatnám, amikor megveszek egy tankönyvet, de akkor és csakis akkor, ha a tanulmányaim folytatásához nélkülözhetetlen. Az utóbbi pedig egy könyvtárra hasonlít, amelyben – valamilyen előzetes igénybecslés alapján, de akár adományok befogadása révén is – köteteket helyeznek el, amelyekhez a könyvtárjeggyel rendelkezők közül bárki (ingyen vagy térítés ellenében) hozzáférhet. Ám csak a gyakorlat mutatja meg utólag, mely könyvek azok, amelyeket „ronggyá olvastak”, és melyek azok, amelyeket le sem vettek a polcról. Az ilyen „könyvtári könyvállomány” informatikai analógiája a „Big Data”, a könyvtáré pedig az internetből és az abban működő globális szolgáltatásokból álló erőforrásrendszer, amely az átlagfelhasználó számára át sem tekinthető méretű és komplexitású, és amelyet épp ezért szokás „felhőnek” nevezni.

 

Az MQTT-protokoll

Még két évtizedes sincs a gépek közti (emberi közreműködés nélküli, Machine-To-Machine – M2M) kommunikáció fogalma. Ez a kezdeteknél rendszerint egyedi tervezésű, zárt kommunikációs eljárásokkal valósult meg még akkor is, ha kommunikációs médiumként az információ továbbítására az esetek nagy többségében a nyilvános szolgáltatást nyújtó hálózatot – eleinte vezetékes és mobiltelefonhálózatot, ma egyre inkább az internetet – alkalmazzák. Ez utóbbi a jelenkor egyik legtöbbet emlegetett fogalma, az IoT. Az IoT-koncepciónak nem feltétele az egységes protokoll, de vegyük figyelembe, hogy az IoT olyan mennyiségi robbanás előtt áll, amely várhatóan a háztartási gépektől az épületautomatizálási berendezésekig, a környezetmonitoringtól az ipari berendezések állapotfelügyeletéig, az okosjárművektől az elektromedikai berendezésekig, a közművek fogyasztásmérőitől a vagyonbiztonság-technikáig az élet minden területén megjelenik. Amíg a XIX. sz. második felében egy városban csupán néhány telefon létezett, mindegyiket össze lehetett kötni azzal, amellyel „kizárólagosan” kívánt kommunikálni a tulajdonosa. Az ötlet azonnal használhatatlanná vált, amint a telefonok száma megnövekedett és felmerült az igény, hogy a telefontulajdonosok mindegyike mindegyik másikkal telefonálhasson. Ehhez hasonlóan a „zárt kommunikációs csatorna” is csak az M2M-technikák szórványos, „ad hoc” alkalmazásait, tudta kiszolgálni, de amint az IoT végpontok száma megnövekszik, és vele megjelenik az adatok nyilvános felhasználásának igénye, elkerülhetetlenné válik az egységesítés, a nyílt M2M-kommunikációs szabvány bevezetése.
Több megoldási javaslat közt ma a legígéretesebbnek az MQTT-protokollt tekinti a szakma. A betűszó eredete a Message Queue Telemetry Transport (az üzenetek sorbaállításán alapuló távmérési adattovábbítás) kifejezés. (Itt jegyezzük meg, hogy a protokoll általánosításával az üzenetek sorbaállásos kezelése – a Message Queue – időközben „kikopott” annak nélkülözhetetlen elemei közül, az MQTT betűszót azonban „hagyománytiszteletből” megtartották. Ezért a betűszó helyes feloldásának ma az „MQ Telemetry Transport” kifejezést tekintik.) Az MQTT nem „újdonság”, az első verzió még 1999-ben megjelent, de az IBM csak 2013-ban javasolta a 3.1-es változatot szabványosításra. Az MQTT alapvető célkitűzése a kezdetektől fogva változatlan: kis programkód-területet és kis kommunikáció kis sávszélességet vegyen csak igénybe.

 

A Publish/Subscribe-modell

Az MQTT protokoll működési modellje az adatok közzétételén (publish) és azok „előfizetéses” (subscribe) alapú „fogyasztásán” alapul (Publish/Subscribe, Pub/Sub modell). Ezt az IoT-alkalmazások fogalomrendszerére leképezve az Iot-végpont (IoT node), mint „publisher” teszi közzé az általa gyűjtött adatokat, amelyet tőle és a hozzá kapcsolt többi végponttól összegyűjt, és azokat tartalom szerinti szűréssel „topikokba” kategorizálva tárol az „MQTT-bróker”. A brókerhez „előfizetők” (subscriberek – az adatok felhasználói) csatlakoznak, amelyeknek – aszerint, hogy melyik topikra vannak előfizetve – a bróker juttatja el a topikban tárolt adatokat. A brókerhez kapcsolódó „ügyfeleket” (publisher, subscriber) együttes néven klienseknek is szokás nevezni. A jelen ismertetés szempontjából lényegtelen az az üzleti modell, amely alapján a rendszer működik, ezért az „előfizetés” kifejezést ezúttal nem feltétlenül kell pénzügyi értelemben is szó szerint venni. A rendszer működése során ez csupán annyit jelent, hogy a „subscriber” valamilyen módon jogosultságot szerez („feliratkozik”) egy vagy több topik adatainak igénybevételére. A működési modell előnyei:

  • a publisher és a subscriber nem kell, hogy ismerje egymást (az adatfelhasználónak nem kell ismernie annak az IoT végpont IP-címét, portját, földrajzi elhelyezkedését, amelyben az adat keletkezett),
  • a publishernek és a subscribernek nem kell azonos időben működnie,
  • a publisher és a subscriber működési állapota semmilyen módon nem befolyásolja egymást,
  • a bróker „eseményvezérelt” jellege miatt a működése nagy mértékben párhuzamosítható, könnyű a szolgáltatónak kapacitásbővítéssel reagálnia a hozzáférési igényeknek, publisher és subscriber kapcsolatok számának növekedésére.

Fontos fogalom továbbá annak meghatározása, hogy milyen biztonsággal jutnak el sikeresen az adatok a publisher(ek)től a subscriberekig. Ezt „a szolgáltatás garantált minősége”, a QoS (Quality of Service) fejezi ki. Ennek három szintje valósul meg az MQTT-protokollban:

  • QoS 0 – „tipikusan egyszer”: A subscriber nem igazolja vissza az üzenet vételét, ezért az üzenet a végponttól nem biztosan jut el az adat felhasználójához. Ezt hívják a szakmai szlengben „fire and forget”-nek (lőj és ne törődj azzal, hogy eltaláltad-e). A találat valószínűsége az alapjául szolgáló TCP-protokoll „szállítási biztonságától” függ. (Itt jegyezzük meg, hogy az MQTT-protokoll az internetes kommunikáció jelentős részéhez hasonlóan a TCP/IP protokollhierarchiára épül).

  • QoS 1 – „legalább egyszer”: ezen a szinten az üzenet feltétlenül eljut a felhasználóhoz, de arra nincs garancia, hogy pontosan egyszer.

  • QoS 2 – „pontosan egyszer”: az üzenet biztosan eljut a felhasználóhoz, és az is garantált, hogy pontosan egyszer.

Az MQTT-protokoll részletei – dióhéjban

A protokoll futtatását a kliensoldal felől küldött, meghatározott tartalmú és formátumú CONNECT üzenettel lehet kezdeményezni, amelyre a bróker egy CONNACK (Connection Acknowledge – csatlakozás elismerése) üzenettel válaszol. Ezt követően a publisher üzeneteket továbbíthat a brókernek. Mivel a bróker topik-alapon szűri az üzeneteket, minden üzenetnek tartalmaznia kell a topik azonosítóját. Maga az MQTT-protokoll teljesen érzéketlen az üzenet „hasznos tartalmának” a formátumára, az üzenet tartalma lehet bináris, szöveges, XML vagy JSON stb. formátumú. A subscriber brókerhez történő kapcsolódásának módja azonos a publisherével, de ezt itt a SUBSCRIBE üzenet követi, amellyel a kliens feliratkozik („előfizet”) egy általa választott topikra. Erre a bróker a SUBACK üzenettel válaszol. A leiratkozás az előzőhöz hasonlóan egy UNSUBSCRIBE – UNSUBACK üzenetpárral történik. A kliens „lecsatlakozása”, a kapcsolat „rendes” megszakítása a DISCONNECT üzenettel történik. Mivel azonban sem a kliensek, sem a kommunikációs csatorna hibátlan működését nem lehet garantálni, az MQTT-protokoll „nyitva hagy” egy lehetőséget a partner(ek) tájékoztatására a kapcsolat „nem rendes” megszakítása esetén. Ez – anélkül, hogy a részletekbe bonyolódnánk – a „Last Will and Testament” képesség (LWT – végakarat és rendelkezés a „váratlan halál” esetére), amelyet a CONNECT üzenetben lehet specifikálni.
A bróker és az adott topikra feliratkozott subscriber közötti adatkommunikáció két módon történhet:

  • állandó kapcsolat (persistent session): a subscriber minden – a topikban található – üzenetet megkap, függetlenül attól, hogy vannak-e közben offline periódusai és mikor. Ebben az üzemmódban a brókernek nyilván kell tartania, hogy az adott subscriber mikor került offline állapotba, és „sorba kell állítania” az ettől kezdve érkező üzeneteket, hogy azokat érkezési sorrendben továbbíthassa, ha a subcriber elérhetővé válik a következő online periódusában. (Eredetileg ez volt a protokoll egyetlen üzemmódja, innen ered az MQ – a „Message Queue” rövidítés a protokoll nevében. – A szerk. megj.)

  • „tiszta” kapcsolat (clean session): a bróker kizárólag azokat az üzeneteket továbbítja, amelyek a subscriber online periódusában érkeznek a topikba.

 

Remélem, az olvasó nem adta fel végleg az MQTT-protokoll fenti ismertetésének követését, de legalább ennyit szükségesnek tartottam megemlíteni ahhoz, hogy az IoT várható „robbanása” során vélhetően egyre nagyobb szerephez jutó kommunikációs technológiáról fogalmat alkothasson.
Annyit még meg kell jegyeznünk, hogy az IoT-alkalmazások, és ezen belül különösen a végpontok szoftverének fejlesztői részére számos nyílt forráskódú programkönyvtár áll rendelkezésre.
A teljesség igénye nélkül: létezik Android és Arduino platformokhoz, C, C#, Java, Javascript, PHP, Python és számos más szoftverkönyezethez használható kész, illetve könnyen „testre szabható” megoldás. Léteznek nyílt forráskódú bróker-szoftverek is, amelyekkel „zárt felhasználású”, MQTT-alapú IoT-megoldások hozhatók létre, de erre van egy másik alternatíva is, amelyben a szerver funkcióit nyilvános felhőszolgáltató cégek szolgáltatásai valósítják meg. Ezek egyike az Amazon Web Services (AWS), amelynek szolgáltatásaira az „STM32 Discovery Kit IoT node” elnevezésű demonstrációs készlet működése épül.

 

Az AWS IoT szolgálat

Már említettük, hogy az „STM32 Discovery Kit IoT node” demonstrációs készlet messze túllép azon a határon, amely – a félvezetőgyártók szokásos megközelítése szerint – jellemzően a népszerűsíteni kívánt alkatrészben rejlő lehetőségeket szemlélteti valamilyen egyszerű alkalmazáson keresztül. A saját szubjektív megítélésem szerint a gyártó „központi” termékének jelentősége a vizsgált esetben szinte el is halványul, hiszen a központi mikrovezérlő köré épített számos – részben más forrásból származó – különféle kommunikációs és érzékelőmodul kissé elvonja a figyelmet az egyébként sokoldalú és nagy teljesítményű mikrovezérlőről. A készlet valódi célja egy olyan IoT-alkalmazás bemutatása, amely a végpont hardverelemei helyett annak – túlzás nélkül – globális rendszerben való alkalmazhatóságát helyezi a figyelem fókuszába. Ez utóbbi fő eszköze az Amazon Web Services-nél (AWS) a készlet felhasználói részére nyitott lehetőség, amellyel az általuk üzembe helyezett végpontot az AWS-nél nyitott felhasználói fiókon keresztül az egyik világszerte ismert felhőszolgáltató IoT-re optimalizált szolgáltatásához kapcsolhatja a korábban ismertetett MQTT-protokoll segítségével.
A kapcsolatfelvételt egy új IoT-végpont legelső csatlakoztatása előtt egy, a demonstráció céljára létrehozott felhasználói fiókkal – a fióknév és a jelszó megadásával – egyetlen alkalommal végrehajtandó regisztrációs folyamattal kell kezdeményezni. (Megjegyzés: a demonstráció „levezénylésére” az STM által kiadott „sorvezető”[1] előírja ugyan az AWS Ohio (USA) állambeli szerverére kapcsolódást, azonban a saját tapasztalat szerint bármelyik európai szerveren át is végrehajtható az IoT-végpont regisztrációja. Az érdeklődő az AWS-IoT-kapcsolat felépítéséhez követheti a „Getting started with AWS IoT” webes útmutatóját[2] is.)

  • Az AWS services menüpontból az AWS IoT almenü választásával lehet a felhőszolgáltatáshoz való első kapcsolódást végrehajtani. A Registry almenüben választhatunk a már regisztrált „dolgok” közül, vagy a Create gombbal új eszköz létrehozását kezdeményezhetjük. Ehhez a Things menüpontban az IoT-végpontnak nevet kell adnunk, majd a Create Thing gombbal az új eszköz is felvehető az elérhető eszközök jegyzékébe.
  • Ezt követően az AWS új ablakot nyit, amelyben létrehozhatjuk az újonnan regisztrált eszköz biztonsági tanúsítványát (certificate), amelynek feladata, hogy az eszköz a további kapcsolódásai során részt vehessen a közte és az AWS IoT bróker közötti biztonsági autentikációban, amely a jelen ismereteink szerint nagy biztonsággal akadályozza meg, hogy idegen adatforrás küldhessen adatokat a brókernek a végpontunk nevében. A biztonsági tanúsítvány létrehozása az alábbi négy lépésben történik:
    • Kattintsunk az ablak „interact” menüpontjára. Ezzel egy egyedi név jelenik meg az ablakban, amelyet az AWS IoT állít elő az általunk létrehozott IoT-eszköz azonosítására. Mentsük el ezt a nevet egy szövegfájlba, később szükségünk lesz rá. 
    • Ezután a Security menüpontban válasszuk a Create Certificates opciót.
    • Az AWS ekkor generál egy (hexadecimális) azonosítószámot annak az internetes „dolognak”, amit éppen regisztrálunk. Az xxxx.cert.pem formátumban megjelenő azonosítót is mentsük el az előbbi szövegfájlba. Mentsük el ugyanide a „private key” cím alatt megjelenő adatot is.
    • Ezután az Activate gombra kattintva aktiváljuk a biztonsági tanúsítványt.
  • A következő lépés egy „policy” előállítása és hozzákapcsolása a végpont leíró adataihoz. Ez a folyamat az Attach a policy gombra való kattintással kezdeményezhető. 
    • A következő oldalon választhatunk a kész policy-k közül, illetve újat generálhatunk a Create new policy gombra kattintva. Válasszuk az utóbbi lehetőséget.
    • Adjunk neki először is nevet a Name mezőben.
    • Az Action mezőbe írjuk be az iot:* karaktersorozatot, a Resource ARN mezőbe pedig egy  * karaktert, kattintsunk az Allow, majd a Create gombokra. 
    • Válasszuk ki a Security menü Certificates menüpontját, és a legördülő menüben az Attach policy funkciót. Ezzel az eszköz biztonsági tanúsítványát sikeresen kiegészítettük a policy-vel, egyben az AWS szempontjából befejeződött az eszközünk (thing) konfiguráló adatainak létrehozása.
  • A következő teendő az eszköz firmware-jének konfigurálása. Ehhez az eszközön kívül egy PC-jellegű számítógépre és egy egyik végén A-típusú, a másikon mikro-B típusú USB-kábelre, valamint helyi WiFi-hálózatra lesz szükségünk.
    •  Az első lépésben a PC-nken elindítunk egy soros (UART) terminálemulátor programot annak érdekében, hogy ezen kommunikáljunk az IoT-eszközzel. Erre a célra valamilyen terminálfunkciót kell indítani. A Windows-felhasználók számára a TeraTerm-alkalmazás is megfelelő lehet, jómagam – Linux-felhasználóként – a legközismertebb putty alkalmazást használtam, minden probléma nélkül. A lényeg az, hogy a terminált a következő módon konfiguráljuk: bitfrekvencia: 115200 baud, adat-szóhosszúság: 8 bit, paritás: nincs, stop bit:1, flow control: nincs, New Line receive: auto, New Line transmit: Line Feed. A konfigurációt mentsük el a későbbi felhasználás érdekében.
    • Az eszközön végezzük el az alábbi beállításokat: JP8 nyitott, JP5, JP6, JP7 zárt, JP4 az 5V_ST_LINK állásban.
    • Csatlakoztassuk az USB kábellel a PC egyik USB-portját az IoT-eszköz CN7 (USB STLINK) csatlakozójához (1. ábra). (Itt jegyzem meg, hogy a sorrend nem közömbös: célszerű a csatlakoztatást akkor elvégezni, amikor a terminálemulátor program már fut. Velem előfordult, hogy amikor a gépet kikapcsoltam, az USB-kábelt elfelejtettem lecsatlakoztatni, és a következő bekapcsoláskor – rejtélyes okból – a PC a rendszerbetöltés alatt azzal a meglepő üzenettel állt le, hogy „egynél több ujjnyomatolvasó van csatlakoztatva” – pedig valójában egy sem volt. A kábelt lecsatlakoztatva és a bootolást megismételve a hiba megszűnt. A jelenség valószínűleg „gépfüggő”, de mindenképpen érdemes betartani az említett sorrendet.)  A csatlakoztatás után az IoT eszköz LD6 (STLINK_COM) vörös és LD5 (5V power) zöld ledje világít. (megjegyzem, az általam vizsgált IoT-végpont példányon a Bluetooth modul aktivitását jelző kék LD4 led világított a WiFi aktivitását jelző sárga LD3 helyett, de ez a kísérlet kimenetelét nem befolyásolta. A kapcsolási rajzot megvizsgálva látható, hogy a két led állapotát az MCU egyetlen portkivezetése határozza meg, tehát a hibát valószínűleg a firmware egyetlen kis hibája okozza, amely a forrásszöveg birtokában bizonyára könnyen javítható is ). 
    • Ezután nyomja meg az eszköz Reset (fekete) nyomógombját. A terminál képernyőjén megjelenik az IoT-eszköz firmware-jének bejelentkező szövege. Az itt látható utasítás szerint 5 másodpecen belül nyomja meg a User (kék) nyomógombot is.
    • Ezután az IoT-eszköz firmware-jét (az SSID és a jelszó megadásával) úgy kell konfigurálni, hogy fel tudjon kapcsolódni a helyi WiFi-hálózatra: be kell állítani a helyi WiFi-hálózathoz az SSID-t, az adatvédelem üzemmódját [válassza itt a 3. (WPA2) opciót] és a jelszót.
    • A korábban elmentett certificate-adatot másolja be a terminálablakba, majd kattintson az OK gombra. 
    • Másolja be a szervercímet a szövegfájlból a terminálba és nyomjon Enter-t. 
    • Adja meg az eszköz nevét.
    • Ha az olvasó a bonyolult regisztrációs procedúra láttán csüggedni kezdene, ne tegye: elérkezett a pillanat, amikor „hátradőlhetünk”, mert nincs más dolgunk, mint követni az aktivitást a terminálablakban: a képernyőn megjelenik a $aws/things/SENSORS_1/shadow/update topikba publikált adatsor [hőmérséklet, légnedvesség, légnyomás, az optikai közelségérzékelő, valamint a gyorsulás, a giroszkóppozíció és a mágneses térerősség három-három térbeli irány szerinti (X, Y és Z)] adata. Ezt az IoT-eszköz – amely „adatfogyasztó” subscriberként is regisztrálva van ugyanerre a topikra – azonnal meg is kapja az AWS brókertől. A mérés ciklikusan, 10 másodpercenként ismétlődik 10 percen át (az időbeli korlátozást azért építették be a demonstrációs firmware-be, hogy a felhőszolgáltatás igénybevétele az „ingyenes zónában” maradjon). 
    • Amennyiben a felhasználó – azonos paraméterezéssel – meg kívánja ismételni a mérési ciklust, nem szükséges többé „keresztülverekednie” magát a valóban hosszadalmas regisztrációs folyamaton. Ha az eszközt egyszerűen csak csatlakoztatjuk a futó soros terminál USB-portjára, vagy a Reset és az User gomb megnyomása után a változtatási igényekre rákérdezésnél nemmel válaszolunk, a folyamat az eredeti paraméterekkel kezd futni. Az alábbi szemelvényeket a kommunikációból a putty terminálemulátor naplófájljából emeltem át ide.

EBV 1 abra

 

Az utolsó két blokk már az első mért adattömb publikálását és a subscriber részére történő visszaküldését szemlélteti. Ez a két blokk ismétlődik (természetesen a mérési eredmények pillanatértékét tükrözve) 10 másodpercenként a 10 perces mérési ciklus végéig, ha kezelői beavatkozás nem történik.
Ha az eszköz egyszerűen csak tápfeszültséget kap, mindenféle felhasználói beavatkozás nélkül (ami igen csak életszerű egy felügyelet nélkül működő IoT-eszköznél), a folyamat sokkal egyszerűbben lezajik – gyakorlatilag azonnal elkezdődik a mérési eredmények továbbítása:

 

  EBV 2 abra

 

Még egy folyamatot érdemes kipróbálni az eszközzel: azt az esetet, amikor a bróker felől az IoT-készülék állapotának megváltoztatására irányuló utasítás érkezik. Az utasításokat magából az IoT-eszközből küldjük el, a terminálba írt JSON-formátumú üzenetekkel. Erről annyit érdemes tudni, hogy egységes dokumentumformátum, amely halványan a C-nyelv szintaxisára emlékeztet. Egy példa:

 

EBV 3 abra

 

Ilyenszerű üzenetekkel az IoT-eszköz „user led”-jének állapotát változtathatjuk meg, kapcsolhatjuk ki és be. Az alábbi üzenet az előző példánál kevésbé csinosan formattált:

 

EBV 4 abra

 

de hatásos, mert hamarosan megérkezik az alábbi, a bróker által publikált üzenet:

 

EBV 5 abra

 

ami nem csak üres beszéd, mert az LD2 „user led” valóban kigyullad.
Ha a topik nevét megváltoztatjuk egy másik, hasonló készülékére, a beavatkozás hatását azon figyelhetjük meg, de mivel a kísérleteimet magam végeztem, ennek kipróbálására nem volt módom.

 

Összefoglalás

Az „STM32 Discovery kit IoT node” demonstrációs eszköz egy nagy teljesítményű, de aránylag kis fogyasztású 32 bites mikrovezérlőre épül, amelyet számos mérőátalakító és kommunikációs modul vesz körül. Ez önmagában is számos hardverlehetőség kipróbálására ad lehetőséget. Ezenkívül azonban a demonstrációs készlet hátterében olyan lehetőség is áll, amely valós feltételekkel teszi lehetővé egy IoT-re optimalizált felhőszolgáltatás igénybevételével kapcsolatos feladatok kipróbálását a demonstrációs eszköz, mint IoT-végpont csatlakoztatásán keresztül. A regisztrációs folyamat – elsősorban a kapcsolat biztonságának fokozása érdekében – meglehetősen hosszadalmas, azonban az általa létrehozott konfigurációval gyakorlatilag felügyelet nélkül futtatható és ismételhető. Az eszköz mindazoknak ajánlható, akik kézzelfogható tapasztalatokat kívánnak szerezni az IoT-alkalmazások gyakorlati felhasználása előtt.

 

Hivatkozások

[1]en.STM32L4_Discovery_Kit_IoT_Node_Hands_on.pdf
[2]https://docs.aws.amazon.com/iot/latest/developerguide/iot-gs.html

 

Szerző: Tóth Ferenc


Az „STM32 Discovery kit IoT-node” demonstrációs eszközt az EBV Elektronik Kft., az STMicroelectronics hivatalos magyarországi disztribútora bocsátotta rendelkezésemre.

 

EBV Elektronik Kft.
1117 Budapest, Budafoki út 91-93.
Tel.: +36 1 436 7220
E-mail: krisztian.nagy@ebv.com

www.ebv.com

 

Még több EBV Elektronik