RFID Kaj IoT-Integriĝo: Kiel Etikedoj, Legantoj, Edge-Logiko kaj Nubaj Sistemoj Kune Laboras

RFID kaj la Interreto de Aĵoj ofte estas komparitaj kvazaŭ projekto devas elekti unu aŭ la alian. En multaj industriaj sistemoj, tio estas la malĝusta arkitektura demando.

RFID estas aŭtomata identiga kaj kaptada teknologio-. IoT priskribas konektitajn aparatojn kaj sistemojn, kiuj interŝanĝas datumojn per retoj. RFID-deplojo povas do fariĝi unu datuma-kapta tavolo ene de pli granda IoT-arkitekturo: etikedoj identigas fizikajn objektojn, legantoj observas ilin, randa softvaro konvertas krudajn legaĵojn en utilajn eventojn, kaj interretaj aplikaĵoj dividas tiujn eventojn kun nubo aŭ entreprenaj sistemoj.

Ĉi tiu gvidilo klarigas tiun integrigan limon por valoraĵo, magazeno, fabrikado kaj podetala teamoj kiuj bezonas konekti RFID-aparaton kun modernaj konektitaj aplikaĵoj sen trakti ĉiun pasivan etikedon kiel interretan-konektan aparaton.

 

RFID kaj IoT Solvas Malsamajn Tavolojn de la Sama Fizika-al-Cifereca Problemo

NIST difinas IoT-aparaton kiel ekipaĵon kun almenaŭ unu transduktilo por interagado kun la fizika mondo kaj almenaŭ unu retinterfaco por interagado kun la cifereca mondo. Pasiva RFID-etikedo normale ne renkontas tiun modelon per si mem: ĝi havas neniun Eterreton, Wi-Fi aŭ ĉelan retkonekton kaj tipe komunikas nur kiam energiigita fare de kongrua leganto.

La leganto aŭ enirejo ofte estas la ponto.

Por komponent-nivela vido de RFID mem, tiu de SyntekRFID-sistema arkitekturo-gvidiloklarigas etikedojn, antenojn, legantojn, mezvaraĵojn kaj aplikajn programojn. Ĉi tiu paĝo temigas la integriĝon inter tiu RFID-stako kaj IoT-medio.

 

Pasiva RFID-Etikedo Kutime Ne Estas Finpunkto de IoT

Unu el la plej utilaj dezajnaj limoj estas ĉesi nomi ĉiun etikeditan objekton interreta-konektita aparato.

Pasiva UHF-etikedo povas teni EPC kaj respondi al pridemandisto. La etikedo kutime ne malfermas TCP/IP-konekton, aŭtentikiĝas ĉe nuba makleristo aŭ publikigas siajn proprajn mesaĝojn per Wi-Fi. La leganto-infrastrukturo elfaras la RF-transakcion kaj tiam pasas datumojn en interkonektitan programaron.

Ĉi tiu distingo influas sekurecon, aparato-administradon kaj solvi problemojn. Etikedo-legmalsukceso estas RF-problemo ĝis pruvo alie. Fiasko de nuba API estas problemo pri reto/aplikaĵo. Kombini ambaŭ sub la frazo "IoT-afero" malfaciligas analizon de radiko-kaŭzo.

 

La Leganto Turnas Fizikan Observojn En Ciferecan Enigaĵon

La leganto kontrolas komunikadon kun la RFID-etikedoj en sia legozono. Depende de la sistemo, ĝi povas inventari EPCojn, legi alian memoron, skribi datumojn, raporti informojn pri anteno kaj elmontri aparatan staton per SDK, LLRP, API aŭ vendisto-interfaco.

En ĉi tiu etapo, la eligo ankoraŭ estas pli proksima al sensila observo ol komerca evento:

etikedo EPC X estis observita fare de leganto Y sur anteno Z en tempo T

Tiu observado povas esti ripetita multajn fojojn dum la etikedo restas en la kampo. Sendi ĉiun krudan observon rekte al nuba aplikaĵo povas krei nenecesan retan trafikon kaj ambiguan komercan logikon.

 

Edge-Logiko Devus Purigi RFID-Datumojn Antaŭ ol la Nubo Uzu ĝin

RFID-randa softvaro aŭ mezvaro ofte elfaras la unuan tavolon de okazaĵprilaborado.

• forigi duplikatajn legaĵojn ene de difinita tempofenestro;
• filtri identigilojn kiuj ne apartenas al la laborfluo;
• asocii legadon kun leganto, anteno, pordo, laborstacio aŭ zono;
• apliki direkton aŭ ellasilon logikon kie la instalado subtenas ĝin;
• bufro-observoj dum retaj interrompoj;
• konverti etikedidentigilojn en aplikaĵidentigilojn;
• levi esceptojn por nekonataj, duobligitaj aŭ neatenditaj etikedoj;
• publikigi kompaktan eventon al la sekva sistemo.

La sistema arkitekturo de GS1 metas RFID-legilojn kaj filtran/kolektan programaron sur la datuma-kapta vojo antaŭ aplikaj-nivelaj eventodatenoj. Ĝia RFID-normfamilio inkludas interfacojn kiel ekzemple LLRP kaj Application Level Events por tiu limo.

La grava dezajnoprincipo estas ke la nubo devus ricevi utilajn okazaĵojn, ne senbridan inundo de RF-observaĵoj.

 

Uzu Eventa Modelo por Konservi Signifon Inter Sistemoj

Post kiam la RFID-tavolo identigis objekton, la sekva demando estas kio okazis al tiu objekto.

GS1-ojEPCIS-normoprovizas utilan modelon por videblecaj eventoj esprimante lakio, kiam, kie, kial kaj kielde produktoj kaj aktivoj. EPCIS 2.0 ankaŭ subtenas sensilajn datumojn, kio igas ĝin grava kiam RFID-identeco estas kombinita kun temperaturo, kondiĉo aŭ aliaj IoT-observoj.

Projekto ne devas uzi EPCIS por lerni de ĉi tiu strukturo. Minimume, evento de RFID-al-IoT devus kutime porti sufiĉe da kunteksto por respondi:

• kiu objekto aŭ objektoj estis implikitaj;
• kiam la evento okazis;
• kie apartenas la observado;
• kia komerca paŝo okazis;
• kiu aparato aŭ procezo produktis la eventon;
• ĉu la evento estas normala aŭ escepta.

 

RFID-Identigo kaj IoT-Sentado Povas Kunhavi la Saman Eventon

RFID ofte respondas "kiu objekto estas ĉi tio?" dum sensiloj respondas "en kia kondiĉo ĝi estas?"

Koneksa malvarma-sistemo, ekzemple, povas uzi RFID aŭ strekkodan identigilon por la sendo kaj interkonektan temperatursensilon por mediaj mezuradoj. Produktsistemo povas identigi ilon aŭ laborpecon per RFID kaj kombini tiun identecon kun maŝin-stato aŭ vibradatumoj de apartaj sensiloj.

La arkitekturo devus konservi la datumfontojn klaraj eĉ kiam la aplikaĵo poste kunigas ilin.

 

Decidi Kio Devas Resti ĉe la Rando

Nuba konektebleco estas utila por plur-eja videbleco, analizo kaj centralizita administrado, sed ne ĉiu RFID-decido devas atendi rondveturon al la nubo.

Konservu logikon loka kiam la procezo devas daŭri dum reto-interrompo aŭ bezonas malaltan-latentecan fizikan kontrolon, kiel ekzemple:

• malfermi aŭ haltigi transportpordegon;
• ekigante stakan lumon aŭ zumilon;
• malakcepti neatenditan etikeditan objekton;
• bufrolegadoj dum perdo de WAN-konektebleco;
• malduplikigi alt-volumajn legadojn;
• kontrolante legan potencon aŭ antenan sekvencon.

Sendu pli alta-nivelajn eventojn al la nubo kiam la valoro venas de trans-reteja videbleco, historia analizo, paneloj, fora administrado aŭ integriĝo kun entreprenaj aplikaĵoj.

 

Uzu la Retan Tavolon por Eventoj, Ne Kaŝi RF-Problemojn

Konektita leganto ne riparas malbonan legan zonon.

Se etikedoj estas maltrafitaj ĉar ili estas muntitaj malĝuste, ekzamenitaj per metalo aŭ likvaĵo, nebone orientitaj, aŭ ekster la celita antenkampo, pli rapidaj nubaj API ne povas reakiri la mankantan identecon. Simile, portalo, kiu legas najbarajn etikedojn, simple sendos malbonajn observojn pli efike.

La RFID aparatara tavolo devas esti validigita unue. tiu de SyntekRFID-teknologia gvidiloprovizas fonon pri frekvenco, etikedoj, legantoj kaj antenoj antaŭ la reto-integra paŝo.

 

Elektu la Integrigan Interfacon De la Deploja Skalo

GS1 notas, ke IoT-arkitekturoj dependas de identigo, aŭtomata datumkaptado kaj kunfunkciebla datumdividado. ĜiaIoT-normoj superrigardoeksplicite poziciigas EPC/RFID kiel unu el la teknologioj ligantaj fizikajn objektojn al ciferecaj informoj.

 

Apartigu RFID-Sekurecon De IoT Reta Sekureco

RFID kaj IoT aldonas malsamajn sekurecajn surfacojn.

La etikedo-leganto-tavolo povas impliki publikajn identigilojn, pasvortan-kontrolitan memoron, etikedaŭtentigon aŭ tute neniun aŭtentikigon, depende de la teknologio. La leganto/rettavolo povas impliki aparatajn akreditaĵojn, API-ŝlosilojn, TLS, retsegmentadon, firmvaradministradon kaj nubpermesojn.

Forta nuba sekureca sinteno ne transformas simplan fiksan-ID RFID-etikedon en ĉifrike aŭtentikigitan akreditaĵon. Same, sekura RFID-etikedo ne aŭtomate sekurigas la operaciumon aŭ retan konekton de la leganto.

La IoT-gvidilo de NIST difinas retan-konektan aparaton sekurecon kiel sian propran vivcikloproblemon. Traktu la RFID-aerinterfacon, leganton/randan aparaton kaj nuban aplikaĵon kiel apartajn fidajn limojn.

 

Planu por eksterreta operacio antaŭ ol vi bezonas ĝin

Industriaj sistemoj devus difini kio okazas kiam la nubo aŭ WAN-konekto estas neatingebla.

Demandoj por la piloto inkluzivas:

• ĉu la leganto daŭre funkcias loke;
• kiuj eventoj estas bufritaj kaj kiom longe;
• kiel estas duplikataj bufritaj eventoj malhelpitaj post rekonekto;
• kiuj lokaj decidoj ankoraŭ povas esti faritaj;
• kiel la sistemo markas eventojn kreitajn dum eksterrete;
• kio okazas se aparato tempo drivas;
• kiel estas sinkronigitaj agordaj ŝanĝoj post reakiro.

Nuba konektebleco devus etendi la sistemon, ne iĝi neplanita ununura punkto de fiasko.

 

Pilotu la Plenan Fizikan-al-Nuban Transakcion

Utila RFID/IoT-piloto testas la kompletan ĉenon:

1. etikedu la reprezentan fizikan objekton;
2. validigi la celitan legan zonon;
3. kapti la krudan identigilon;
4. apliki randan filtradon kaj kuntekston;
5. krei la celitan komercan eventon;
6. sendu la eventon tra la reto;
7. konfirmu, ke la nubo aŭ entreprena platformo stokas la ĝustan objekton, lokon kaj tempon;
8. deĉenigi la atendatan laŭfluan agon;
9. provu duplikatajn legadojn, nekonatajn etikedojn, retan interrompon kaj rekomencon de aparato;
10. kontroli repaciĝon post reakiro.

Sukcesa etikedo legita estas do nur la unua kontrolpunkto.

 

Kion Enmeti RFID-al-IoT-Integriga Specifo

Se la projekto ankoraŭ elektas RFID-aparaton, tiu de SyntekKategorio de RFID-legilojestas la komerca sekva paŝo post kiam la legita evento kaj integriga limo estas difinitaj.

 

La Integriga Regulo

La praktika sinsekvo estas:

fizika objekto → RFID-identeco → legozono → leganto-observado → randa filtrado → komerca evento → rettransporto → IoT/nuba platformo → entreprena ago

RFID kaj IoT ne estas konkurantaj respondoj al la sama demando. RFID povas provizi fidindajn fizikajn identecon kaj okazaĵobservaĵojn; IoT-infrastrukturo povas konekti, kombini kaj distribui tiujn eventojn. La arkitekturo funkcias kiam ĉiu tavolo havas klaran respondecon kaj la projekto validas la kompletan ĉenon anstataŭ supozi ke konektebleco sole kreas utilajn datumojn.