Integrarea RFID și IoT: cum funcționează împreună etichetele, cititorii, logica Edge și sistemele cloud

RFID și Internetul lucrurilor sunt adesea comparate ca și cum un proiect trebuie să aleagă unul sau altul. În multe sisteme industriale, aceasta este întrebarea greșită de arhitectură.

RFID este o tehnologie automată de identificare și{0}}captură de date. IoT descrie dispozitivele și sistemele conectate care fac schimb de date prin rețele. Prin urmare, o implementare RFID poate deveni un singur strat de-captură de date în interiorul unei arhitecturi IoT mai ample: etichetele identifică obiectele fizice, cititorii le observă, software-ul edge convertește citirile brute în evenimente utile, iar aplicațiile în rețea partajează aceste evenimente cu sistemele cloud sau de întreprindere.

Acest ghid explică limita de integrare pentru echipele de bunuri, depozite, producție și vânzare cu amănuntul care trebuie să conecteze hardware-ul RFID la aplicații moderne conectate fără a trata fiecare etichetă pasivă ca pe un dispozitiv-conectat la internet.

 

RFID și IoT rezolvă straturi diferite ale aceleiași probleme fizice-la-digitale

NIST definește un dispozitiv IoT ca un echipament cu cel puțin un traductor pentru interacțiunea cu lumea fizică și cel puțin o interfață de rețea pentru interacțiunea cu lumea digitală. În mod normal, o etichetă RFID pasivă nu corespunde modelului de la sine: nu are conexiune Ethernet, Wi-Fi sau rețea celulară și comunică de obicei numai atunci când este alimentată de un cititor compatibil.

Cititorul sau poarta de acces este adesea puntea.

Pentru o vizualizare-la nivel de componentă a RFID în sine, Syntek'sGhid de arhitectură a sistemului RFIDexplică etichete, antene, cititoare, middleware și aplicații software. Această pagină se concentrează pe integrarea dintre acea stivă RFID și un mediu IoT.

 

O etichetă RFID pasivă nu este de obicei un punct final IoT

Una dintre cele mai utile limite de design este de a nu mai apela la fiecare obiect etichetat un dispozitiv conectat la internet-.

O etichetă UHF pasivă poate deține un EPC și poate răspunde unui interogator. În mod normal, eticheta nu deschide o conexiune TCP/IP, nu se autentifică la un broker cloud sau nu își publică propriile mesaje prin Wi-Fi. Infrastructura cititorului realizează tranzacția RF și apoi trece datele în software-ul în rețea.

Această distincție afectează securitatea, gestionarea dispozitivelor și depanarea. O eroare de citire a etichetei-este o problemă RF până când se dovedește contrariul. O defecțiune a API-ului cloud este o problemă de rețea/aplicație. Combinarea ambelor sub expresia „Problemă IoT” face analiza cauzei rădăcină-mai dificilă.

 

Cititorul transformă observațiile fizice în intrare digitală

Cititorul controlează comunicarea cu etichetele RFID din zona sa de citire. În funcție de sistem, poate inventaria EPC-uri, poate citi alte memorie, poate scrie date, poate raporta informații despre antenă și poate expune starea dispozitivului printr-o interfață SDK, LLRP, API sau furnizor.

În această etapă, rezultatul este încă mai aproape de o observație de senzor decât de un eveniment de afaceri:

eticheta EPC X a fost observată de cititorul Y pe antena Z la momentul T

Această observație poate fi repetată de mai multe ori în timp ce eticheta rămâne în câmp. Trimiterea fiecărei observații brute direct către o aplicație cloud poate crea trafic de rețea inutil și o logică de afaceri ambiguă.

 

Edge Logic ar trebui să curețe datele RFID înainte ca cloud-ul să le folosească

Software-ul de margine RFID sau middleware-ul realizează de obicei primul strat de procesare a evenimentelor.

• eliminați citirile duplicate într-o fereastră de timp definită;
• filtrați identificatorii care nu aparțin fluxului de lucru;
• asociați o citire cu un cititor, antenă, ușă, stație de lucru sau zonă;
• aplicați direcția sau logica de declanșare acolo unde instalația o suportă;
• observații tampon în timpul întreruperilor rețelei;
• convertiți identificatorii de etichete în identificatori de aplicații;
• ridicați excepții pentru etichetele necunoscute, duplicate sau neașteptate;
• publicați un eveniment compact pentru următorul sistem.

Arhitectura sistemului GS1 plasează cititoarele RFID și software-ul de filtrare/colectare pe calea de-captură a datelor înainte de datele despre evenimente-la nivel de aplicație. Familia sa de standarde RFID include interfețe precum LLRP și Evenimente la nivel de aplicație pentru această limită.

Principiul important de proiectare este că norul ar trebui să primească evenimente utile, nu un flux necontrolat de observații RF.

 

Utilizați un model de evenimente pentru a păstra semnificația între sisteme

Odată ce stratul RFID a identificat un obiect, următoarea întrebare este ce sa întâmplat cu acel obiect.

GS1Standardul EPCISoferă un model util pentru evenimentele de vizibilitate prin exprimareace, când, unde, de ce și cumde produse și active. EPCIS 2.0 acceptă, de asemenea, datele senzorilor, ceea ce le face relevante atunci când identitatea RFID este combinată cu temperatura, starea sau alte observații IoT.

Un proiect nu trebuie să folosească EPCIS pentru a învăța din această structură. Cel puțin, un eveniment RFID-la-IoT ar trebui să aibă, de obicei, suficient context pentru a răspunde:

• ce obiect sau obiecte au fost implicate;
• când a avut loc evenimentul;
• unde aparține observația;
• ce pas de afaceri a avut loc;
• ce dispozitiv sau proces a produs evenimentul;
• indiferent dacă evenimentul este normal sau excepțional.

 

Identificarea RFID și detectarea IoT pot împărtăși același eveniment

RFID răspunde adesea „ce obiect este acesta?” în timp ce senzorii răspund „în ce stare este?”

Un sistem-de lanț de frig conectat, de exemplu, poate utiliza un identificator RFID sau cod de bare pentru expediere și un senzor de temperatură în rețea pentru măsurătorile de mediu. Un sistem de producție poate identifica o unealtă sau o piesă de prelucrat prin RFID și poate combina acea identitate cu datele de stare-mașinii sau de vibrații de la senzori separați.

Arhitectura ar trebui să mențină sursele de date distincte chiar și atunci când aplicația le se alătură ulterior.

 

Decideți ce trebuie să rămână la margine

Conectivitatea în cloud este utilă pentru vizibilitatea pe mai multe-site, analize și management centralizat, dar nu orice decizie RFID ar trebui să aștepte o călătorie dus-întors în cloud.

Păstrați logica locală atunci când procesul trebuie să continue în timpul întreruperii rețelei sau necesită control fizic cu latență redusă-, cum ar fi:

• deschiderea sau oprirea unei porti transportoare;
• declanșarea unei lumini de stivă sau a soneriei;
• respingerea unui articol etichetat neașteptat;
• citiri în tampon în timpul pierderii conectivității WAN;
• deduplicarea citirilor-de volum mare;
• controlând puterea cititorului sau secvențierea antenei.

Trimiteți evenimente de nivel-mai înalt în cloud atunci când valoarea provine din vizibilitatea peste-site-uri, analize istorice, tablouri de bord, administrare de la distanță sau integrare cu aplicații de întreprindere.

 

Utilizați stratul de rețea pentru evenimente, nu pentru a ascunde problemele de proiectare RF

Un cititor conectat nu remediază o zonă de citire proastă.

Dacă etichetele sunt omise, deoarece sunt montate incorect, ecranate cu metal sau lichid, prost orientate sau în afara câmpului de antenă prevăzut, API-urile cloud mai rapide nu pot recupera identitatea lipsă. În mod similar, un portal care citește etichetele învecinate va trimite pur și simplu observații proaste mai eficient.

Stratul hardware RFID trebuie mai întâi validat. de la SyntekGhid de tehnologie RFIDoferă fundal despre frecvență, etichete, cititoare și antene înainte de etapa de integrare a rețelei.

 

Alegeți interfața de integrare din scara de implementare

GS1 observă că arhitecturile IoT depind de identificare, captarea automată a datelor și partajarea interoperabilă a datelor. SalePrezentare generală a standardelor IoTpoziționează în mod explicit EPC/RFID ca una dintre tehnologiile care leagă obiectele fizice de informațiile digitale.

 

Separați securitatea RFID de securitatea rețelei IoT

RFID și IoT adaugă diferite suprafețe de securitate.

Stratul de cititor de etichete-poate implica identificatori publici, memorie controlată de parolă-, autentificare de etichetă sau deloc autentificare, în funcție de tehnologie. Stratul cititor/rețea poate implica acreditări ale dispozitivului, chei API, TLS, segmentare a rețelei, gestionare a firmware-ului și permisiuni cloud.

O poziție puternică de securitate în cloud nu transformă o simplă etichetă ID RFID fixă-într-o autentificare criptografică. De asemenea, o etichetă RFID securizată nu securizează automat sistemul de operare sau conexiunea la rețea a cititorului.

Ghidul IoT al NIST definește securitatea-dispozitivelor conectate la rețea ca fiind propria problemă a ciclului de viață. Tratați interfața de aer RFID, dispozitivul de citire/edge și aplicația cloud ca limite separate de încredere.

 

Planificați funcționarea offline înainte de a avea nevoie

Sistemele industriale ar trebui să definească ce se întâmplă atunci când conexiunea cloud sau WAN nu este disponibilă.

Întrebările pentru pilot includ:

• cititorul continuă să opereze la nivel local;
• ce evenimente sunt stocate în tampon și pentru cât timp;
• cum sunt prevenite evenimentele tamponate duplicat după reconectare;
• ce decizii locale mai pot fi luate;
• cum marchează sistemul evenimentele create în timp ce sunt offline;
• ce se întâmplă dacă timpul dispozitivului variază;
• cum sunt sincronizate modificările de configurare după recuperare.

Conectivitatea în cloud ar trebui să extindă sistemul, nu să devină un singur punct de eșec neplanificat.

 

Pilotează tranzacția completă fizică-în-în cloud

Un pilot util RFID/IoT testează întregul lanț:

1. etichetați elementul fizic reprezentativ;
2. validați zona de citire prevăzută;
3. captura identificatorul brut;
4. aplicați filtrarea marginilor și contextul;
5. crearea evenimentului de afaceri dorit;
6. trimite evenimentul prin rețea;
7. confirmați că platforma cloud sau enterprise stochează articolul, locația și ora corecte;
8. declanșează acțiunea așteptată în aval;
9. testați citirile duplicate, etichetele necunoscute, întreruperea rețelei și repornirea dispozitivului;
10. verifica reconcilierea după recuperare.

O citire cu succes a etichetei este, prin urmare, doar primul punct de control.

 

Ce să introduceți într-o specificație de integrare RFID-la-IoT

Dacă proiectul încă selectează hardware RFID, Syntek'sCategoria cititoare RFIDeste următorul pas comercial după ce evenimentul citit și limita de integrare sunt definite.

 

Regula de integrare

Secvența practică este:

obiect fizic → identitate RFID → zonă de citire → observare cititor → filtrare margine → eveniment de afaceri → transport în rețea → platformă IoT/cloud → acțiune întreprindere

RFID și IoT nu sunt răspunsuri concurente la aceeași întrebare. RFID poate furniza identitate fizică fiabilă și observații ale evenimentelor; Infrastructura IoT poate conecta, combina și distribui aceste evenimente. Arhitectura funcționează atunci când fiecare strat are o responsabilitate clară și proiectul validează întregul lanț în loc să presupună că conectivitatea singură creează date utile.