RFID og IoT-integration: Hvordan tags, læsere, Edge Logic og cloud-systemer arbejder sammen

RFID og Internet of Things sammenlignes ofte, som om et projekt skal vælge det ene eller det andet. I mange industrielle systemer er det det forkerte arkitekturspørgsmål.

RFID er en teknologi til automatisk identifikation og-datafangst. IoT beskriver tilsluttede enheder og systemer, der udveksler data gennem netværk. En RFID-implementering kan derfor blive ét datafangstlag i en større IoT-arkitektur: tags identificerer fysiske objekter, læsere observerer dem, edge-software konverterer rå læsninger til nyttige hændelser, og netværksapplikationer deler disse hændelser med cloud- eller virksomhedssystemer.

Denne vejledning forklarer denne integrationsgrænse for aktiv-, lager-, produktions- og detailteams, der skal forbinde RFID-hardware med moderne tilsluttede applikationer uden at behandle alle passive tags som en internet-tilsluttet enhed.

 

RFID og IoT løser forskellige lag af det samme fysiske-til-digitale problem

NIST definerer en IoT-enhed som udstyr med mindst én transducer til interaktion med den fysiske verden og mindst én netværksgrænseflade til interaktion med den digitale verden. Et passivt RFID-tag opfylder normalt ikke denne model i sig selv: det har ingen Ethernet-, Wi--Fi- eller mobilnetværksforbindelse og kommunikerer typisk kun, når det strømforsynes af en kompatibel læser.

Læseren eller gatewayen er ofte broen.

For et komponent-niveau af selve RFID, SynteksRFID-systemarkitekturguideforklarer tags, antenner, læsere, middleware og applikationssoftware. Denne side fokuserer på integrationen mellem den RFID-stak og et IoT-miljø.

 

Et passivt RFID-tag er normalt ikke et IoT-endepunkt

En af de mest nyttige designgrænser er at stoppe med at kalde hvert tagget objekt for en internet{0}}forbundet enhed.

Et passivt UHF-mærke kan indeholde en EPC og svare på en interrogator. Tagget åbner normalt ikke en TCP/IP-forbindelse, godkender ikke til en cloud-mægler eller udgiver sine egne beskeder via Wi-Fi. Læserinfrastrukturen udfører RF-transaktionen og sender derefter data til netværkssoftware.

Denne sondring påvirker sikkerhed, enhedsadministration og fejlfinding. En tag-læsefejl er et RF-problem, indtil det modsatte er bevist. En cloud API-fejl er et netværks-/applikationsproblem. Kombination af begge under udtrykket "IoT-problem" gør root-årsagsanalyse sværere.

 

Læseren forvandler fysiske observationer til digital input

Læseren styrer kommunikationen med RFID-tags i sin læsezone. Afhængigt af systemet kan det inventar EPC'er, læse anden hukommelse, skrive data, rapportere antenneoplysninger og afsløre enhedsstatus gennem en SDK, LLRP, API eller leverandørgrænseflade.

På dette stadium er output stadig tættere på en sensorobservation end en forretningsbegivenhed:

tag EPC X blev observeret af læseren Y på antennen Z på tidspunktet T

Denne observation kan gentages mange gange, mens mærket forbliver i feltet. At sende enhver rå observation direkte til en cloud-applikation kan skabe unødvendig netværkstrafik og tvetydig forretningslogik.

 

Edge Logic bør rense RFID-data, før skyen bruger dem

RFID edge-software eller middleware udfører almindeligvis det første lag af hændelsesbehandling.

• fjern dobbeltlæsninger inden for et defineret tidsvindue;
• filtrere identifikatorer fra, der ikke hører til arbejdsgangen;
• forbinde en læsning med en læser, antenne, dør, arbejdsstation eller zone;
• anvende retnings- eller triggerlogik, hvor installationen understøtter det;
• bufferobservationer under netværksafbrydelser;
• konvertere tag-id'er til applikations-id'er;
• rejse undtagelser for ukendte, duplikerede eller uventede tags;
• udgive en kompakt begivenhed til det næste system.

GS1's systemarkitektur placerer RFID-læsere og filtrerings-/indsamlingssoftware på data-opsamlingsstien før begivenhedsdata på applikations-niveau. Dens RFID-standardfamilie inkluderer grænseflader såsom LLRP og Application Level Events for denne grænse.

Det vigtige designprincip er, at skyen skal modtage nyttige hændelser, ikke en ukontrolleret strøm af RF-observationer.

 

Brug en hændelsesmodel til at bevare mening på tværs af systemer

Når RFID-laget har identificeret et objekt, er det næste spørgsmål, hvad der skete med det objekt.

GS1'erEPCIS standardgiver en nyttig model for synlighedsbegivenheder ved at udtrykkehvad, hvornår, hvor, hvorfor og hvordanaf produkter og aktiver. EPCIS 2.0 understøtter også sensordata, hvilket gør det relevant, når RFID-identitet kombineres med temperatur, tilstand eller andre IoT-observationer.

Et projekt behøver ikke bruge EPCIS for at lære af denne struktur. Som minimum bør en RFID-til-IoT-hændelse normalt have tilstrækkelig kontekst til at svare:

• hvilken eller hvilke genstande der var involveret;
• hvornår begivenheden fandt sted;
• hvor observationen hører hjemme;
• hvilket forretningstrin der er sket;
• hvilken enhed eller proces, der producerede begivenheden;
• om begivenheden er normal eller ekstraordinær.

 

RFID-identifikation og IoT-sensing kan dele den samme begivenhed

RFID svarer ofte "hvilket objekt er dette?" mens sensorer svarer "hvilken tilstand er den i?"

Et tilsluttet kold-kædesystem kan for eksempel bruge et RFID- eller stregkode-id til forsendelsen og en netværksforbundet temperatursensor til miljømålinger. Et produktionssystem kan identificere et værktøj eller emne gennem RFID og kombinere denne identitet med maskin-tilstand eller vibrationsdata fra separate sensorer.

Arkitekturen bør holde datakilderne adskilte, selv når applikationen senere slutter sig til dem.

 

Beslut hvad der skal blive ved kanten

Cloud-forbindelse er nyttig til synlighed på flere-websteder, analyser og centraliseret administration, men ikke enhver RFID-beslutning bør vente på en rundrejse til skyen.

Hold logikken lokal, når processen skal fortsætte under netværksafbrydelser eller har behov for fysisk kontrol med lav-latens, såsom:

• åbning eller stop af en transportørport;
• udløser et staklys eller summer;
• afvisning af et uventet mærket element;
• bufferlæsning under tab af WAN-forbindelse;
• deduplikering af højt-volumenlæsninger;
• styring af læsereffekt eller antennesekvensering.

Send hændelser på-højere niveau til skyen, når værdien kommer fra synlighed på tværs af-websteder, historisk analyse, dashboards, fjernadministration eller integration med virksomhedsapplikationer.

 

Brug netværkslaget til begivenheder, ikke for at skjule RF-designproblemer

En tilsluttet læser retter ikke en dårlig læsezone.

Hvis tags savnes, fordi de er monteret forkert, afskærmet af metal eller væske, dårligt orienteret eller uden for det tilsigtede antennefelt, kan hurtigere cloud-API'er ikke genskabe den manglende identitet. På samme måde vil en portal, der læser nabomærker, simpelthen sende dårlige observationer mere effektivt.

RFID-hardwarelaget skal valideres først. SynteksRFID teknologi guidegiver baggrund om frekvens, tags, læsere og antenner før netværksintegrationstrinnet.

 

Vælg integrationsgrænsefladen fra implementeringsskalaen

GS1 bemærker, at IoT-arkitekturer afhænger af identifikation, automatisk datafangst og interoperabel datadeling. DensOversigt over IoT-standardereksplicit placerer EPC/RFID som en af ​​de teknologier, der forbinder fysiske objekter med digital information.

 

Adskil RFID-sikkerhed fra IoT-netværkssikkerhed

RFID og IoT tilføjer forskellige sikkerhedsoverflader.

Tag--læserlaget kan involvere offentlige identifikatorer, adgangskode-kontrolleret hukommelse, tag-godkendelse eller slet ingen godkendelse, afhængigt af teknologien. Læser-/netværkslaget kan involvere enhedslegitimationsoplysninger, API-nøgler, TLS, netværkssegmentering, firmwareadministration og cloud-tilladelser.

En stærk sikkerhedsposition i skyen forvandler ikke et simpelt fast-ID RFID-tag til et kryptografisk autentificeret legitimationsoplysninger. Ligeledes sikrer et sikkert RFID-tag ikke automatisk læserens styresystem eller netværksforbindelse.

NIST's IoT-vejledning definerer netværks-tilsluttet enhedssikkerhed som sit eget livscyklusproblem. Behandl RFID-luftgrænsefladen, læseren/edge-enheden og cloud-applikationen som separate tillidsgrænser.

 

Planlæg for offlinedrift, før du har brug for det

Industrielle systemer bør definere, hvad der sker, når cloud- eller WAN-forbindelsen ikke er tilgængelig.

Spørgsmål til piloten omfatter:

• fortsætter læseren med at arbejde lokalt;
• hvilke hændelser er bufferet og hvor længe;
• hvordan forhindres duplikerede bufferbegivenheder efter genforbindelse;
• hvilke lokale beslutninger der stadig kan træffes;
• hvordan markerer systemet begivenheder oprettet, mens du er offline;
• hvad sker der, hvis enhedens tid glider;
• hvordan synkroniseres konfigurationsændringer efter gendannelse.

Cloud-forbindelse bør udvide systemet, ikke blive et uplanlagt enkelt fejlpunkt.

 

Pilot den fulde fysiske-til-sky-transaktion

En nyttig RFID/IoT-pilot tester hele kæden:

1. tag den repræsentative fysiske vare;
2. validere den påtænkte læsezone;
3. fange den rå identifikator;
4. anvende kantfiltrering og kontekst;
5. skabe den påtænkte forretningsbegivenhed;
6. sende begivenheden på tværs af netværket;
7. bekræfte, at cloud- eller virksomhedsplatformen gemmer den korrekte vare, lokation og tidspunkt;
8. udløse den forventede nedstrømshandling;
9. test duplikatlæsninger, ukendte tags, netværksafbrydelse og genstart af enheden;
10. verificere afstemning efter gendannelse.

En vellykket taglæsning er derfor kun det første kontrolpunkt.

 

Hvad skal du sætte i en RFID-til-IoT-integrationsspecifikation

Hvis projektet stadig vælger RFID-hardware, er SynteksRFID-læserkategorier det kommercielle næste trin, efter at læsehændelsen og integrationsgrænsen er defineret.

 

Integrationsreglen

Den praktiske rækkefølge er:

fysisk objekt → RFID-identitet → læsezone → læserobservation → kantfiltrering → forretningsbegivenhed → netværkstransport → IoT/cloud platform → virksomhedshandling

RFID og IoT er ikke konkurrerende svar på det samme spørgsmål. RFID kan levere pålidelige fysiske identitets- og begivenhedsobservationer; IoT-infrastruktur kan forbinde, kombinere og distribuere disse begivenheder. Arkitekturen fungerer, når hvert lag har et klart ansvar, og projektet validerer hele kæden i stedet for at antage, at forbindelsen alene skaber nyttige data.