RFID en IoT-integrasie: hoe etikette, lesers, Edge Logic en wolkstelsels saamwerk

RFID en die Internet van Dinge word dikwels vergelyk asof 'n projek die een of die ander moet kies. In baie industriële stelsels is dit die verkeerde argitektuurvraag.

RFID is 'n outomatiese identifikasie en data-vasvangtegnologie. IoT beskryf gekoppelde toestelle en stelsels wat data deur netwerke uitruil. 'n RFID-ontplooiing kan dus een data--vastleggingslaag binne 'n groter IoT-argitektuur word: merkers identifiseer fisiese voorwerpe, lesers neem dit waar, randsagteware omskep rou leeswerk in nuttige gebeurtenisse, en netwerktoepassings deel daardie gebeurtenisse met wolk- of ondernemingstelsels.

Hierdie gids verduidelik daardie integrasiegrens vir bate-, pakhuis-, vervaardigings- en kleinhandelspanne wat RFID-hardeware met moderne gekoppelde toepassings moet koppel sonder om elke passiewe merker as 'n internet--gekoppelde toestel te hanteer.

 

RFID en IoT los verskillende lae van dieselfde fisiese-tot-digitale probleem op

NIST definieer 'n IoT-toestel as toerusting met ten minste een transducer vir interaksie met die fisiese wêreld en ten minste een netwerk koppelvlak vir interaksie met die digitale wêreld. 'n Passiewe RFID-etiket voldoen gewoonlik nie aan daardie model op sigself nie: dit het geen Ethernet-, Wi--Fi- of sellulêre netwerkverbinding nie en kommunikeer gewoonlik net wanneer dit deur 'n versoenbare leser aangedryf word.

Die leser of poort is dikwels die brug.

Vir 'n komponent-vlakaansig van RFID self, Syntek s'nRFID stelsel argitektuur gidsverduidelik etikette, antennas, lesers, middelware en toepassingsagteware. Hierdie bladsy fokus op die integrasie tussen daardie RFID-stapel en 'n IoT-omgewing.

 

'n Passiewe RFID-etiket is gewoonlik nie 'n IoT-eindpunt nie

Een van die nuttigste ontwerpgrense is om op te hou om elke gemerkte voorwerp 'n internet-gekoppelde toestel te noem.

'n Passiewe UHF-etiket kan 'n EPC hou en op 'n ondervraer reageer. Die merker maak gewoonlik nie 'n TCP/IP-verbinding oop, staaf aan 'n wolkmakelaar of publiseer nie sy eie boodskappe oor Wi-Fi nie. Die leserinfrastruktuur voer die RF-transaksie uit en gee dan data deur na netwerksagteware.

Hierdie onderskeid raak sekuriteit, toestelbestuur en probleemoplossing. 'n Merker-leesmislukking is 'n RF-probleem totdat anders bewys word. 'n Wolk API-fout is 'n netwerk-/toepassingsprobleem. Om beide onder die frase "IoT-kwessie" te kombineer, maak worteloorsaak-analise moeiliker.

 

Die leser verander fisiese waarnemings in digitale invoer

Die leser beheer kommunikasie met die RFID-etikette in sy leessone. Afhangende van die stelsel, kan dit EPC's inventaris maak, ander geheue lees, data skryf, antenna-inligting rapporteer en toestelstatus blootstel deur 'n SDK, LLRP, API of verskaffer-koppelvlak.

Op hierdie stadium is die uitset steeds nader aan 'n sensorwaarneming as 'n besigheidsgebeurtenis:

merker EPC X is waargeneem deur leser Y op antenna Z op tyd T

Daardie waarneming kan baie keer herhaal word terwyl die merker in die veld bly. Om elke rou waarneming direk na 'n wolktoepassing te stuur, kan onnodige netwerkverkeer en dubbelsinnige besigheidslogika skep.

 

Edge Logic moet RFID-data skoonmaak voordat die wolk dit gebruik

RFID-randsagteware of middelware voer gewoonlik die eerste laag van gebeurtenisverwerking uit.

• verwyder duplikaatlesings binne 'n gedefinieerde tydvenster;
• filtreer identifiseerders wat nie aan die werkvloei behoort nie;
• assosieer 'n leesstuk met 'n leser, antenna, deur, werkstasie of sone;
• pas rigting- of snellerlogika toe waar die installasie dit ondersteun;
• bufferwaarnemings tydens netwerkonderbrekings;
• omskep merker identifiseerders in toepassing identifiseerders;
• maak uitsonderings vir onbekende, duplikaat of onverwagte etikette;
• publiseer 'n kompakte gebeurtenis na die volgende stelsel.

GS1 se stelselargitektuur plaas RFID-lesers en filter-/versamelsagteware op die data-vasvangpad voor toepassing-vlak gebeurtenisdata. Sy RFID-standaardfamilie sluit koppelvlakke soos LLRP en Application Level Events vir hierdie grens in.

Die belangrike ontwerpbeginsel is dat die wolk nuttige gebeurtenisse moet ontvang, nie 'n onbeheerde vloed van RF-waarnemings nie.

 

Gebruik 'n gebeurtenismodel om betekenis oor stelsels te behou

Sodra die RFID-laag 'n voorwerp geïdentifiseer het, is die volgende vraag wat met daardie voorwerp gebeur het.

GS1'sEPCIS standaardbied 'n nuttige model vir sigbaarheidsgebeurtenisse deur die uitdrukking van diewat, wanneer, waar, hoekom en hoevan produkte en bates. EPCIS 2.0 ondersteun ook sensordata, wat dit relevant maak wanneer RFID-identiteit gekombineer word met temperatuur, toestand of ander IoT-waarnemings.

'n Projek hoef nie EPCIS te gebruik om uit hierdie struktuur te leer nie. Ten minste behoort 'n RFID-tot-IoT-gebeurtenis gewoonlik genoeg konteks te dra om te antwoord:

• watter voorwerp of voorwerpe betrokke was;
• wanneer die gebeurtenis plaasgevind het;
• waar die waarneming hoort;
• watter besigheidstap plaasgevind het;
• watter toestel of proses die gebeurtenis veroorsaak het;
• of die gebeurtenis normaal of uitsonderlik is.

 

RFID-identifikasie en IoT-waarneming kan dieselfde gebeurtenis deel

RFID antwoord dikwels "watter voorwerp is dit?" terwyl sensors antwoord "in watter toestand is dit?"

'n Gekoppelde koue-kettingstelsel kan byvoorbeeld 'n RFID- of strepieskode-identifiseerder vir die versending en 'n netwerktemperatuursensor vir omgewingsmetings gebruik. 'n Vervaardigingstelsel kan 'n gereedskap of werkstuk deur RFID identifiseer en daardie identiteit kombineer met masjien-toestand- of vibrasiedata vanaf aparte sensors.

Die argitektuur behoort die databronne te onderskei, selfs wanneer die toepassing later by hulle aansluit.

 

Besluit wat aan die rand moet bly

Wolkverbinding is nuttig vir multi-werfsigbaarheid, ontleding en gesentraliseerde bestuur, maar nie elke RFID-besluit moet wag vir 'n heen-en-weer reis na die wolk nie.

Hou logika plaaslik wanneer die proses tydens netwerkontwrigting moet voortgaan of fisiese beheer met 'n lae-latentie benodig, soos:

• die oopmaak of stop van 'n vervoerhek;
• aktiveer 'n stapellig of gonser;
• verwerping van 'n onverwagse gemerkte item;
• bufferlees tydens verlies van WAN-verbinding;
• deduplisering van hoë-volume leeswerk;
• leeskrag of antenna-volgorde te beheer.

Stuur gebeurtenisse op hoër-vlak na die wolk wanneer die waarde van kruis-werfsigbaarheid, historiese ontleding, kontroleskerms, afstandadministrasie of integrasie met ondernemingstoepassings kom.

 

Gebruik die netwerklaag vir gebeurtenisse, om nie RF-ontwerpprobleme te verberg nie

'n Gekoppelde leser maak nie 'n slegte leessone reg nie.

As etikette gemis word omdat hulle verkeerd gemonteer is, deur metaal of vloeistof geskerm, swak georiënteerd of buite die beoogde antennaveld is, kan vinniger wolk-API's nie die ontbrekende identiteit herwin nie. Net so sal 'n portaal wat naburige etikette lees eenvoudig slegte waarnemings meer doeltreffend stuur.

Die RFID-hardewarelaag moet eers bekragtig word. Syntek s'nRFID tegnologie gidsverskaf agtergrond oor frekwensie, etikette, lesers en antennas voor die netwerkintegrasiestap.

 

Kies die integrasie-koppelvlak vanaf die ontplooiingskaal

GS1 merk op dat IoT-argitekture afhang van identifikasie, outomatiese datavaslegging en interoperabele datadeling. SyIoT-standaarde oorsigposisioneer EPC/RFID uitdruklik as een van die tegnologieë wat fisiese voorwerpe aan digitale inligting koppel.

 

Skei RFID-sekuriteit van IoT-netwerksekuriteit

RFID en IoT voeg verskillende sekuriteitsoppervlaktes by.

Die merker-leserlaag kan publieke identifiseerders, wagwoord-beheerde geheue, merkerstawing of hoegenaamd geen stawing behels nie, afhangende van die tegnologie. Die leser/netwerklaag kan toestelbewyse, API-sleutels, TLS, netwerksegmentering, fermwarebestuur en wolktoestemmings behels.

'n Sterk wolksekuriteitshouding verander nie 'n eenvoudige vaste-ID RFID-merker in 'n kriptografies geverifieerde eiebewys nie. Net so beveilig 'n veilige RFID-etiket nie outomaties die leser se bedryfstelsel of netwerkverbinding nie.

NIST se IoT-leiding definieer netwerk-gekoppelde toestelsekuriteit as sy eie lewensiklusprobleem. Behandel die RFID-lugkoppelvlak, leser/randtoestel en wolktoepassing as aparte trustgrense.

 

Beplan vir vanlyn werking voordat jy dit nodig het

Industriële stelsels moet definieer wat gebeur wanneer die wolk- of WAN-verbinding nie beskikbaar is nie.

Vrae vir die vlieënier sluit in:

• gaan die leser voort om plaaslik te werk;
• watter gebeure gebuffer word en vir hoe lank;
• hoe word duplikaatgebufferde gebeurtenisse voorkom na heraansluiting;
• watter plaaslike besluite nog geneem kan word;
• hoe merk die stelsel gebeurtenisse wat geskep is terwyl jy vanlyn is;
• wat gebeur as toesteltyd dryf;
• hoe word konfigurasieveranderinge gesinchroniseer na herstel.

Wolkverbinding moet die stelsel uitbrei, nie 'n onbeplande enkele punt van mislukking word nie.

 

Begin die volle Fisiese-na-wolktransaksie

'n Nuttige RFID/IoT-vlieënier toets die volledige ketting:

1. merk die verteenwoordigende fisiese item;
2. die beoogde leessone te bekragtig;
3. vang die rou identifiseerder vas;
4. randfiltrering en konteks toe te pas;
5. skep die beoogde besigheidsgeleentheid;
6. stuur die geleentheid oor die netwerk;
7. bevestig dat die wolk of ondernemingsplatform die korrekte item, ligging en tyd stoor;
8. die verwagte stroomaf-aksie te aktiveer;
9. toets duplikaatlesings, onbekende etikette, netwerkonderbreking en toestel herbegin;
10. verifieer versoening na herstel.

'n Suksesvolle merkerlees is dus slegs die eerste kontrolepunt.

 

Wat om in 'n RFID-tot-IoT-integrasiespesifikasie te plaas

As die projek steeds RFID-hardeware kies, Syntek'sRFID leser kategorieis die kommersiële volgende stap nadat die leesgebeurtenis en integrasiegrens gedefinieer is.

 

Die integrasiereël

Die praktiese volgorde is:

fisiese voorwerp → RFID-identiteit → leessone → leserwaarneming → randfiltrering → besigheidsgebeurtenis → netwerkvervoer → IoT/wolkplatform → ondernemingsaksie

RFID en IoT is nie mededingende antwoorde op dieselfde vraag nie. RFID kan betroubare fisiese identiteit en gebeurtenis waarnemings verskaf; IoT-infrastruktuur kan daardie gebeurtenisse verbind, kombineer en versprei. Die argitektuur werk wanneer elke laag 'n duidelike verantwoordelikheid het en die projek valideer die volledige ketting in plaas daarvan om te aanvaar dat konnektiwiteit alleen nuttige data skep.