Eszközkommunikáció és IoT-fejlesztés

Miért merül fel ez a feladat

Az eszközoldal a termék egyik rétege

Ha a megoldáshoz fizikai eszköz is tartozik, a feladat a szoftver és az eszköz közötti kommunikációval bővül. A szoftvernek fel kell vennie a kapcsolatot a hozzá tartozó hardverrel, kezelnie kell annak állapotát, válaszait és hibáit, a felhasználó felé viszont egyetlen összefüggő folyamatnak kell látszania. Az eszközoldal ezért nem külön technológiai kiegészítés, hanem a termék működésének egyik rétege.

Az IoT ebben a megközelítésben elsősorban nem szenzorhálózatot jelent, hanem azt a réteget, ahol a szoftver a hozzá tartozó fizikai eszközökkel kommunikál. Leolvasók, terminálok, vezérlők, mérőeszközök, nyomtatók és kijelzők: mindegyik saját protokollal, saját állapottal és saját hibamódokkal rendelkezik, a felhasználó felé viszont egyetlen, megszakítás nélküli folyamatnak kell látszania.

A tervezés során először azt tisztázzuk, milyen eszközök vesznek részt a folyamatban, ezek milyen interfészen érhetők el, ki kezdeményezi a párbeszédet, mennyire kritikus a válaszidő, és mi történjen akkor, ha az eszköz nem válaszol. Ezekből vezethető le az eszközoldali logika, a kommunikációs réteg és a szerveroldali feldolgozás megfelelő felosztása.

01

Eszközintegráció és protokollok

Csatlakozási módok

Az eszközök közvetlenül, helyi átjárón vagy hálózaton keresztül kapcsolódhatnak a szoftverhez. A választást a fizikai környezet, a távolság, az eszközök darabszáma, az elérhető hálózat és az üzemeltetési hozzáférés együtt határozza meg. Egy helyben, egyetlen munkaállomás mellett működő eszköz más felépítést kíván, mint a több telephelyen szétszórt, távolról követett eszközpark.

Az interfész a kiindulópont

Az integráció kiindulópontja mindig az adott eszköz dokumentált interfésze: a támogatott parancsok, a válaszformátum, az időzítési korlátok és a gyártói SDK lehetőségei. Ahol a leírás hiányos vagy eltér a tapasztalt viselkedéstől, a tényleges működést méréssel kell tisztázni, mert a katalógusadat nem mindig mutatja meg, hogyan viselkedik az eszköz élesben.

Eszközazonosítás és verziókezelés

Az azonos típusú eszközök sem feltétlenül azonos módon viselkednek: eltérhet a firmware-verzió, a gyári beállítás, a karakterkészlet vagy egy parancs válaszideje. A rendszernek ezért ismernie kell, melyik eszközzel beszél, és képesnek kell lennie a verziók közötti eltérések kezelésére. Ehhez tartozik az eszköz azonosítása, a hitelesítés módja és annak eldöntése, hogy egy ismeretlen vagy nem várt válasz esetén a művelet megszakad-e.

02

Állapotkezelés és hibatűrés

Az eszköz nem mindig van készen

A fizikai eszköz foglalt lehet, kifogyhat, elveszítheti a kapcsolatot, vagy félbehagyott műveletet hagyhat maga után. A szoftvernek ismernie kell az eszköz aktuális állapotát, biztonságosan újra kell próbálkoznia, és egyértelmű visszajelzést kell adnia arról, hogy a művelet megtörtént-e.

Ismételhetőség és kettős végrehajtás

Egy megszakadt kapcsolat után az eszköz felől nem mindig állapítható meg, hogy a művelet lefutott-e. A műveleteket ezért egyedi azonosítóval, előzetes állapotellenőrzéssel és az adott eszköz lehetőségeihez igazított ismétlésvédelemmel tervezzük. Ahol az eszköz nem támogat ilyen ellenőrzést, előre meg kell határozni, hogy az újrapróbálkozás megengedett-e, vagy emberi visszaigazolás szükséges.

Mit lát a felhasználó, amíg az eszköz nem válaszol

A fizikai művelet ideje nem igazodik automatikusan a felület elvárásaihoz. Meg kell határozni, meddig várunk válaszra, mit mutatunk közben, mikor tekintjük a műveletet sikertelennek, és mi történjen a késve megérkező válasszal. A bizonytalan állapotot érdemes annak nevezni: a „nem sikerült” és a „nem tudjuk, sikerült-e” a felhasználó számára is két különböző helyzet, mert más következő lépést kíván.

03

Architektúra: eszköz, helyi réteg, backend

Hol fusson a logika?

A feladat felosztható az eszköz, a helyi átjáró vagy munkaállomás és a szerveroldal között. A döntést a szükséges válaszidő, a hálózati környezet, a helyben is elvárt működés, a frissíthetőség és az üzemeltetési hozzáférés befolyásolja. Ha egy műveletnek hálózat nélkül is le kell futnia, a logika nem kerülhet teljes egészében a backendre; ha viszont több helyszín adatait kell összefogni, a helyi megoldás önmagában nem elég.

Helyi működés és pufferelés

A kapcsolat megszakadására előre kell dönteni: az eszköz vagy a helyi komponens tárolhat adatot, korlátozott önálló működésre válthat, vagy biztonságos állapotba kerülhet. A helyben tárolt adat későbbi továbbításánál a sorrend, az időbélyegek értelmezése és a duplikáció elkerülése külön tervezési kérdés. A helyi tároló kapacitása is véges: meg kell határozni, mi történik, ha megtelik.

Időzítés és válaszidő

Egy eszköz válaszideje függhet a művelettől, az eszköz állapotától és a hálózattól. A rendszerben ezért nem egyetlen általános időkorlát működik, hanem műveletenként meghatározott várakozási idő, újrapróbálkozási szabály és lezárási feltétel. Ezeket a valós eszközön mért viselkedés alapján érdemes beállítani, nem becslésből.

04

Adatfeldolgozás és események

A nyers jeltől az eseményig

A nyers eszközadat ritkán hasznos önmagában. Szükség lehet szűrésre, kalibrációs összefüggésekre, aggregálásra, határértékekre, eseménydetektálásra és az adatok más üzleti információkkal való összekapcsolására. Az eseményből értesítés, feladat, automatizált rendszerhívás vagy emberi ellenőrzést igénylő jelzés indulhat.

Hiányzó és nem várt válasz

A hiányzó adat nem ugyanaz, mint a nulla érték. A néma eszköz, az érvénytelen válasz és a nem várt formátum külön kezelést igényel, különben a belőlük készült összesítés téves képet mutat. Ezért már a tervezéskor rögzítjük, mi számít érvényes válasznak, mi történik az érvénytelennel, és hol jelenik meg az, hogy egy adat nem áll rendelkezésre.

05

Dashboardok és működési kép

Nem minden adat való egy képernyőre

A felületnek nem minden rendelkezésre álló adatot kell egyszerre megmutatnia. Az operátornak az aktuális állapot, az eltérés és a szükséges következő lépés a fontos; az elemzőnek trendekre és összehasonlításra; az üzemeltetőnek pedig eszközkapcsolati és adatminőségi információkra lehet szüksége. Ezeket külön nézetek és szerepkörök szerint rendezzük.

A működési kép része az eszköz állapota is

Az adat mellett arról is látni kell valamit, hogy az eszköz elérhető-e, mikor jelentkezett utoljára, és megbízható-e, amit küld. Enélkül egy néma eszköz csendben ugyanúgy néz ki, mint egy olyan, amelynek éppen nincs jelentenivalója.

06

Eszközéletciklus és biztonság

Az eszközök hosszabb ideig maradnak, mint a köréjük épített szoftver

Az eszközök éveken át használatban maradhatnak, miközben a hálózat, a backend és a biztonsági elvárások változnak. A megoldás része az eszközök nyilvántartása, konfigurálása, állapotkövetése és – ahol lehetséges – biztonságos frissítése.

Hozzáférés, kulcsok és eszközazonosság

A hozzáférési kulcsok, az eszközazonosság, a kommunikáció védelme és a kompromittált eszköz elkülöníthetősége már a tervezéskor figyelmet igényel. Ezek utólagos beépítése lényegesen nehezebb, mint az első kialakításnál végiggondolni őket.

Frissítés és verziókövetés

A frissítés lehetőségét és menetét a gyártói támogatás korlátai között kell megtervezni. Nagyobb eszközparknál a fokozatos, visszafordítható bevezetés a biztonságosabb, mert egy hibás frissítés egyszerre több, fizikailag nehezen elérhető eszközt érinthet.

07

Távoli eszközflotta üzemeltetése

Egy eszközből több lesz

Amíg egyetlen eszközről van szó, a hibát észre lehet venni. Több tucat vagy több száz, egymástól távol működő eszköznél ez már nem áll: a rendszernek magának kell megmondania, melyik eszköz hol van, milyen konfigurációval fut, mikor jelentkezett utoljára, és melyikkel van baj. Ez a nyilvántartás nem melléktermék, hanem az üzemeltetés alapja.

Állapotkövetés és riasztás

A flotta működési képéhez az eszközök küldte adat mellett az eszközök elérhetősége is hozzátartozik. Meg kell határozni, mennyi ideig tekinthető egy eszköz némának normál működés mellett, mikortól számít kiesésnek, és ki kap erről értesítést. A riasztási küszöböket a mért viselkedés alapján érdemes beállítani; a túl érzékeny riasztást előbb-utóbb figyelmen kívül hagyják.

Kiszállás nélkül elvégezhető beavatkozások

Minél több művelet oldható meg távolról – konfiguráció módosítása, állapot lekérdezése, naplók begyűjtése, ahol a gyártó engedi, frissítés –, annál kevesebb kiszállásra van szükség. Ennek a határait az eszköz tudása és a gyártói támogatás szabja meg; azt is előre tisztázni kell, mi az, amihez mindenképpen helyszíni jelenlét kell, és ki végzi el.

Amit ma megoldunk

Konkrétan a mobileszköz-menedzsment (MDM) és a számítógépek távoli üzemeltetése az, ami megoldott: eszközök nyilvántartása, konfigurálása, állapotkövetése és távoli beavatkozás ott, ahol az eszköz és a gyártói támogatás ezt engedi.

Ami nem oldható meg szoftverből

A terepi eszköz fizikai állapota – tápellátás, rögzítés, szennyeződés, sérülés, lopás – szoftverből nem javítható, csak észlelhető. A flottaüzemeltetés ezért mindig két rétegű: a technikai megfigyelés mellé emberi karbantartási folyamat is kell, felelőssel, ütemezéssel és tartalék eszközökkel.

Lépésről lépésre

Megvalósítási folyamat

Felmérés: eszközök és folyamat

Összeírjuk, mely eszközök vesznek részt a folyamatban, ki használja őket, hol helyezkednek el, és mi az az eredmény, amelyet a felhasználó a művelet végén vár. A jelenlegi kézi lépéseket és a mai hibalehetőségeket is rögzítjük.
Interfészek és dokumentáció ellenőrzése

Áttekintjük a gyártói dokumentációt, a támogatott parancsokat, a válaszformátumot, az időzítési korlátokat és az elérhető SDK-kat. Ahol a leírás hiányos vagy eltér a tapasztalt viselkedéstől, a tényleges működést méréssel kell tisztázni.
Kommunikációs próba valós eszközön

A legnagyobb bizonytalanságot célzott technikai próbával vizsgáljuk: felépíthető-e a kapcsolat, mit válaszol az eszköz normál és hibás esetben, és mennyi idő alatt. Ez a lépés a teljes megvalósítás előtt láthatóvá teszi, ha egy eszköz nem alkalmas a tervezett használatra.
Architektúra és felelősségi felosztás

Eldöntjük, mi fut az eszközön vagy a helyi komponensen, mi a szerveroldalon, és hogyan viselkedik a rendszer kapcsolat nélkül. Meghatározzuk az állapotokat, az eszközazonosítást, a hozzáféréseket és a naplózás tartalmát.
Fejlesztés a hibaágakkal együtt

A normál lefutás mellett a foglalt, néma, hibás és félbehagyott műveleteket is megvalósítjuk. Az ismétlésvédelem és a felhasználói visszajelzés nem utólag illesztett kiegészítés, hanem a megoldás része.
Tesztelés valós eszközön

A vizsgálat nem alapozható teljes egészében szimulációra. A valós eszközön és a tényleges használati környezetben végzett próba olyan viselkedést mutathat meg – hálózati kiesés, egyszerre használt eszközök, eltérő válaszidők –, amely szimulált körülmények között nem jelentkezik.
Bevezetés, üzemeltetés és eszköznyilvántartás

Rendezzük az eszközök nyilvántartását, konfigurációját, a hozzáférési kulcsok kezelését, a frissítés menetét és a hibabejelentés útját. Tisztázzuk, ki reagál egy eszközhibára, és milyen kézi működés lehetséges addig, amíg az eszköz nem elérhető. Az eszközoldali rendszereknél különösen fontos a hozzáférések, az eszköznyilvántartás, a frissítések és a megfigyelés hosszú távú felelősségének tisztázása.

Mikor kerülünk képbe

Tipikus felhasználási helyzetek

Egy szoftvernek a hozzá tartozó eszközökkel kell együttműködnie

A csatlakoztatott eszközök parancsai, válaszai és állapotai egységes folyamattá szervezhetők, az adatok pedig központilag ellenőrizhetők és szerepkör szerint megjeleníthetők. A megoldás tervezésekor a kapcsolatvesztés, az eszközazonosság, az ismételt végrehajtás elkerülése és a terepi karbantartás is része a feladatnak.

Távoli eszközök állapotát kell követni

A szenzoradatok központi rendszerbe továbbíthatók, ott ellenőrizhetők, eseményekké alakíthatók és szerepkör szerint megjeleníthetők. A megoldás tervezésekor a kapcsolatvesztés, az eszközazonosság, az adatminőség és a terepi karbantartás is része a feladatnak.

Kézi leolvasásból és átgépelésből származik a hiba

Ha egy érték ma egy eszköz kijelzőjéről kerül papírra, onnan pedig egy rendszerbe, a hiba és a késleltetés a másolási lépéseknél keletkezik. Az eszköz és a szoftver közvetlen kapcsolata ezeket a lépéseket kiválthatja, az ellenőrzést pedig a rögzítés pillanatába helyezheti.

Egy régebbi gép vagy műszer még évekig használatban marad

A csere nem mindig indokolt vagy lehetséges. Ilyenkor azt vizsgáljuk, milyen jel, port vagy kimenet érhető el az eszközön, és beépíthető-e olyan köztes réteg, amely a meglévő működés megzavarása nélkül olvassa vagy továbbítja az adatot. Az utólagos módosítás garanciális és biztonsági következményeit előre tisztázni kell.

Egy eszközhöz saját ház, tartó vagy rögzítő kell

Ha az eszköz beépítéséhez, rögzítéséhez vagy védelméhez fizikai váz szükséges, a mechanikai rész tervezése és gyártása a 3D-tervezés és prototípusgyártás területéhez tartozik. Az eszközoldali fejlesztés és a váz így ugyanannak a megoldásnak a két rétege, de két külön szakmai munka.

Mielőtt megkérdeznéd

Gyakori kérdések

Bármilyen eszköz integrálható?

Nem. Az integrálhatóság az eszköz interfészétől, dokumentációjától és a gyártó által engedélyezett hozzáféréstől függ. Zárt vagy dokumentálatlan eszköznél előfordulhat, hogy csak korlátozott megoldás építhető, vagy hogy megbízható kapcsolat nem alakítható ki. Ezt előzetes felméréssel, lehetőleg a tényleges eszközön végzett próbával tisztázzuk.

Egy meglévő gép vagy eszköz utólag is bekapcsolható a szoftverbe?

Sok esetben igen, de előzetes felmérés szükséges. Vizsgálni kell a rendelkezésre álló jeleket, kommunikációs interfészeket, beépítési lehetőséget, hálózati környezetet, energiaellátást és azt, hogy az utólagos módosítás milyen garanciális vagy biztonsági következményekkel járhat.

Ki választja ki az eszközt?

A választás közös döntés. A használati környezet, a darabszám, a szervizelhetőség és a beszerzési szempontok az üzemeltető oldalán dőlnek el; az interfész, a dokumentáltság és az integrálhatóság vizsgálata a fejlesztés része. Érdemes a végleges típusválasztás előtt kommunikációs próbát végezni, mert a katalógusadat nem mindig mutatja meg a tényleges viselkedést.

Mi történik, ha az eszköz elveszíti a kapcsolatot?

Ezt a rendszer viselkedésében előre meg kell tervezni. Az eszköz tárolhat adatot helyben, újrapróbálhatja a továbbítást, korlátozott önálló működésre válthat, vagy biztonságos állapotba kerülhet. A megfelelő stratégia a vezérelt folyamat kockázatától függ.

Szükség van felhőszolgáltatásra az eszközoldali működéshez?

Nem minden esetben. Egy folyamat futhat helyi hálózaton vagy akár egyetlen munkaállomáson is. Központi backend akkor indokolt, ha több helyszín adatait kell összefogni, távolról kell követni az eszközök állapotát, vagy a feldolgozás meghaladja a helyi kapacitást. A döntés az adatok érzékenységét, a hálózati környezetet és az üzemeltetési modellt is érinti.

Hogyan kezelhetők az eltérő firmware- és szoftververziók?

Az azonos típusú eszközök is eltérő verzióval futhatnak, és eltérően viselkedhetnek. A rendszernek fel kell ismernie a verziót és kezelnie kell a különbségeket. A frissítés lehetőségét és menetét a gyártói támogatás korlátai között kell megtervezni, a nagyobb eszközparknál pedig a fokozatos, visszafordítható bevezetés a biztonságosabb.

Van olyan folyamat, amelyben a szoftvernek a hozzá tartozó eszközökkel kell szót értenie?

Indulhatunk a meglévő eszköz típusából, a gyártói dokumentációból vagy abból a folyamatból, amelyben ma használják. Az első lépés annak tisztázása, milyen interfész érhető el, ki kezdeményezi a párbeszédet, és mi történjen akkor, ha az eszköz nem válaszol.

Az eszköz típusa, a gyártói leírás vagy egy fénykép a csatlakozókról is jó kiindulópont lehet.

Nézzük meg az eszközoldalt

Kapcsolódó szolgáltatások

Az eszközök külön nyelvet beszélnek. A szoftver dolga, hogy értsék egymást.

Amit ez a terület lefed