Integrace RFID a IoT: Jak společně fungují štítky, čtečky, logika Edge a cloudové systémy

RFID a internet věcí jsou často srovnávány, jako by si projekt musel vybrat jedno nebo druhé. V mnoha průmyslových systémech je to špatná otázka architektury.

RFID je technologie automatické identifikace a{0}}zachycování dat. IoT popisuje připojená zařízení a systémy, které si vyměňují data prostřednictvím sítí. Nasazení RFID se proto může stát jednou vrstvou{3}}zachycující data uvnitř větší architektury internetu věcí: značky identifikují fyzické objekty, čtenáři je pozorují, software edge převádí nezpracovaná čtení na užitečné události a síťové aplikace tyto události sdílejí s cloudovými nebo podnikovými systémy.

Tato příručka vysvětluje hranice integrace pro týmy aktiv, skladů, výroby a maloobchodu, které potřebují propojit hardware RFID s moderními připojenými aplikacemi, aniž by každý pasivní štítek považoval za zařízení-připojené k internetu.

 

RFID a IoT řeší různé vrstvy stejného fyzického-pro-digitálního problému

NIST definuje IoT zařízení jako zařízení s alespoň jedním převodníkem pro interakci s fyzickým světem a alespoň jedním síťovým rozhraním pro interakci s digitálním světem. Pasivní štítek RFID obvykle tento model sám o sobě nesplňuje: nemá připojení k síti Ethernet, Wi-Fi ani mobilní síti a obvykle komunikuje pouze tehdy, je-li napájen kompatibilní čtečkou.

Čtečka nebo brána je často most.

Pro zobrazení-na úrovni komponent samotného RFID, Syntek'sPrůvodce architekturou systému RFIDvysvětluje tagy, antény, čtečky, middleware a aplikační software. Tato stránka se zaměřuje na integraci mezi tímto stackem RFID a prostředím IoT.

 

Pasivní RFID tag obvykle není koncovým bodem IoT

Jednou z nejužitečnějších hranic návrhu je přestat nazývat každý označený objekt zařízením připojeným k internetu-.

Pasivní UHF tag může obsahovat EPC a reagovat na dotazovač. Značka běžně neotevírá připojení TCP/IP, neověřuje se u cloudového zprostředkovatele ani nepublikuje vlastní zprávy přes Wi-Fi. Infrastruktura čtečky provede RF transakci a poté předá data do síťového softwaru.

Toto rozlišení ovlivňuje zabezpečení, správu zařízení a odstraňování problémů. Selhání čtení tagu-je problém RF, dokud se neprokáže opak. Selhání cloudového API je problém sítě/aplikace. Kombinace obojího pod frází „problém IoT“ ztěžuje-analýzu kořenových příčin.

 

Čtečka převádí fyzické pozorování na digitální vstup

Čtečka řídí komunikaci s RFID štítky ve své čtecí zóně. V závislosti na systému může inventarizovat EPC, číst další paměť, zapisovat data, hlásit informace o anténě a vystavovat stav zařízení prostřednictvím SDK, LLRP, API nebo rozhraní dodavatele.

V této fázi je výstup stále blíže senzorovému pozorování než obchodní události:

tag EPC X byl pozorován čtečkou Y na anténě Z v čase T

Toto pozorování lze mnohokrát opakovat, zatímco značka zůstává v poli. Odesílání každého nezpracovaného pozorování přímo do cloudové aplikace může způsobit zbytečný síťový provoz a nejednoznačnou obchodní logiku.

 

Edge Logic by měla vyčistit RFID data, než je cloud použije

Software nebo middleware RFID edge běžně provádí první vrstvu zpracování událostí.

• odstranit duplicitní čtení v rámci definovaného časového okna;
• odfiltrovat identifikátory, které nepatří do pracovního postupu;
• přidružit čtení ke čtečce, anténě, dveřím, pracovní stanici nebo zóně;
• použít logiku směru nebo spouštění tam, kde to instalace podporuje;
• pozorování vyrovnávací paměti během přerušení sítě;
• převádět identifikátory značek na identifikátory aplikací;
• vyvolat výjimky pro neznámé, duplicitní nebo neočekávané značky;
• publikovat kompaktní událost do dalšího systému.

Architektura systému GS1 umisťuje čtečky RFID a software pro filtrování/shromažďování dat na -cestu sběru dat před daty událostí na úrovni aplikace-. Jeho rodina standardů RFID zahrnuje rozhraní, jako je LLRP a události na aplikační úrovni pro tuto hranici.

Důležitým principem návrhu je, že cloud by měl přijímat užitečné události, nikoli nekontrolovanou záplavu RF pozorování.

 

Použijte model událostí k zachování významu napříč systémy

Jakmile RFID vrstva identifikuje objekt, další otázkou je, co se s tímto objektem stalo.

GS1standard EPCISposkytuje užitečný model pro události viditelnosti vyjádřenímco, kdy, kde, proč a jakproduktů a aktiv. EPCIS 2.0 také podporuje data ze senzorů, díky čemuž je relevantní, když je identita RFID kombinována s teplotou, stavem nebo jinými pozorováními IoT.

Projekt nemusí používat EPCIS, aby se mohl učit z této struktury. Událost RFID-to{2}}IoT by měla mít minimálně dostatek kontextu k zodpovězení:

• o jaký předmět nebo předměty šlo;
• kdy k události došlo;
• kam patří pozorování;
• jaký obchodní krok nastal;
• které zařízení nebo proces vyvolalo událost;
• zda je událost běžná nebo výjimečná.

 

Identifikace RFID a snímání IoT mohou sdílet stejnou událost

RFID často odpovídá "co je to za objekt?" zatímco senzory odpovídají "v jakém je stavu?"

Propojený systém chladicího-řetězce může například používat RFID nebo identifikátor čárového kódu pro zásilku a síťový snímač teploty pro měření prostředí. Výrobní systém může identifikovat nástroj nebo obrobek pomocí RFID a zkombinovat tuto identitu s údaji o -stavu stroje nebo vibracích ze samostatných senzorů.

Architektura by měla udržovat zdroje dat oddělené, i když se k nim aplikace později připojí.

 

Rozhodněte se, co musí zůstat na hraně

Cloudové připojení je užitečné pro viditelnost více{0}}míst, analýzy a centralizovanou správu, ale ne každé rozhodnutí o RFID by mělo čekat na zpáteční cestu do cloudu.

Udržujte logiku místní, když proces musí pokračovat během narušení sítě nebo když potřebuje fyzické řízení s nízkou{0}}latenční dobou, například:

• otevření nebo zastavení dopravníkové brány;
• spuštění zásobníku světla nebo bzučáku;
• odmítnutí neočekávané označené položky;
• ukládání čtení do vyrovnávací paměti při ztrátě připojení WAN;
• deduplikace velkého{0}}čtení;
• ovládání napájení čtečky nebo sekvenování antény.

Odesílejte -události vyšší úrovně do cloudu, když jejich hodnota vychází z viditelnosti mezi-weby, historické analýzy, řídicích panelů, vzdálené správy nebo integrace s podnikovými aplikacemi.

 

Použijte síťovou vrstvu pro události, nikoli pro skrytí problémů s návrhem RF

Připojená čtečka neopraví zónu špatného čtení.

Pokud štítky chybějí, protože jsou namontovány nesprávně, stíněné kovem nebo kapalinou, špatně orientované nebo mimo zamýšlené pole antény, rychlejší cloudová API nedokážou obnovit chybějící identitu. Podobně portál, který čte sousední značky, bude jednoduše odesílat špatná pozorování efektivněji.

Nejprve musí být ověřena hardwarová vrstva RFID. Syntek'sPrůvodce technologií RFIDposkytuje informace o frekvenci, značkách, čtečkách a anténách před krokem síťové integrace.

 

Vyberte integrační rozhraní ze škály nasazení

GS1 poznamenává, že architektury internetu věcí závisí na identifikaci, automatickém sběru dat a interoperabilním sdílení dat. JehoPřehled standardů IoTexplicitně staví EPC/RFID jako jednu z technologií spojujících fyzické objekty s digitálními informacemi.

 

Oddělte zabezpečení RFID od zabezpečení sítě IoT

RFID a IoT přidávají různé bezpečnostní povrchy.

Vrstva pro čtení-značek může v závislosti na technologii zahrnovat veřejné identifikátory, paměť řízenou heslem{1}}, ověřování značek nebo vůbec žádné ověřování. Čtečka/síťová vrstva může zahrnovat přihlašovací údaje zařízení, klíče API, TLS, segmentaci sítě, správu firmwaru a cloudová oprávnění.

Silné cloudové zabezpečení nemění jednoduchý pevný{0}}ID RFID tag na kryptograficky ověřené přihlašovací údaje. Stejně tak zabezpečený RFID štítek automaticky nezabezpečuje operační systém čtečky ani síťové připojení.

Pokyny NIST IoT definují zabezpečení-propojených zařízení jako svůj vlastní problém životního cyklu. Zacházejte se vzduchovým rozhraním RFID, čtecím/edge zařízením a cloudovou aplikací jako se samostatnými hranicemi důvěry.

 

Naplánujte si provoz offline, než to budete potřebovat

Průmyslové systémy by měly definovat, co se stane, když je cloud nebo připojení WAN nedostupné.

Otázky pro pilota zahrnují:

• pokračuje čtečka v místním provozu;
• které události jsou ukládány do vyrovnávací paměti a na jak dlouho;
• jak se zabrání duplicitním událostem ve vyrovnávací paměti po opětovném připojení;
• o kterých lze ještě přijímat místní rozhodnutí;
• jak systém označuje události vytvořené v režimu offline;
• co se stane, když se čas zařízení posune;
• jak se synchronizují změny konfigurace po obnovení.

Cloudová konektivita by měla rozšířit systém, ne se stát neplánovaným jediným bodem selhání.

 

Pilotujte transakci Full Physical-to{1}}Cloud

Užitečný pilot RFID/IoT testuje celý řetězec:

1. označte reprezentativní fyzickou položku;
2. ověřit zamýšlenou oblast čtení;
3. zachytit nezpracovaný identifikátor;
4. použít filtrování hran a kontext;
5. vytvořit zamýšlenou obchodní událost;
6. odeslat událost přes síť;
7. potvrdit, že cloudová nebo podniková platforma ukládá správnou položku, místo a čas;
8. spustit očekávanou následnou akci;
9. otestovat duplicitní čtení, neznámé značky, přerušení sítě a restart zařízení;
10. ověřit usmíření po zotavení.

Úspěšné načtení značky je tedy pouze prvním kontrolním bodem.

 

Co vložit do specifikace RFID-do{1}}integrace IoT

Pokud projekt stále vybírá hardware RFID, Syntek'sKategorie RFID čtečkyje komerčním dalším krokem po definování události čtení a integrační hranice.

 

Integrační pravidlo

Praktické pořadí je:

fyzický objekt → RFID identita → zóna čtení → pozorování čtenářů → filtrování hran → obchodní událost → síťový přenos → platforma IoT/cloud → podniková akce

RFID a IoT nejsou konkurenčními odpověďmi na stejnou otázku. RFID může poskytnout spolehlivou fyzickou identitu a pozorování událostí; Infrastruktura IoT může tyto události propojovat, kombinovat a distribuovat. Architektura funguje, když má každá vrstva jasnou odpovědnost a projekt ověřuje celý řetězec místo toho, aby předpokládal, že samotná konektivita vytváří užitečná data.