Интегриране на RFID и IoT: Как етикетите, четците, Edge Logic и облачните системи работят заедно

RFID и Интернет на нещата често се сравняват, сякаш проектът трябва да избере едното или другото. В много индустриални системи това е грешен въпрос за архитектурата.

RFID е технология за автоматично идентифициране и{0}}улавяне на данни. IoT описва свързани устройства и системи, които обменят данни чрез мрежи. Следователно внедряването на RFID може да се превърне в един-слой за улавяне на данни в по-голяма IoT архитектура: таговете идентифицират физически обекти, четците ги наблюдават, крайният софтуер преобразува необработените четения в полезни събития и мрежовите приложения споделят тези събития с облачни или корпоративни системи.

Това ръководство обяснява тази граница на интеграция за екипи за активи, складове, производство и търговия на дребно, които трябва да свържат RFID хардуер с модерни свързани приложения, без да третират всеки пасивен етикет като устройство, -свързано с интернет.

 

RFID и IoT решават различни слоеве от един и същ физически-до-цифров проблем

NIST дефинира IoT устройство като оборудване с поне един преобразувател за взаимодействие с физическия свят и поне един мрежов интерфейс за взаимодействие с цифровия свят. Пасивният RFID таг обикновено не отговаря на този модел сам по себе си: той няма Ethernet, Wi-Fi или клетъчна мрежова връзка и обикновено комуникира само когато се захранва от съвместим четец.

Четецът или шлюзът често е мостът.

За изглед-на ниво компонент на самата RFID, Syntek'sРъководство за архитектура на RFID системаобяснява тагове, антени, четци, мидълуер и приложен софтуер. Тази страница се фокусира върху интеграцията между този RFID стек и IoT среда.

 

Пасивният RFID етикет обикновено не е крайна точка на IoT

Една от най-полезните граници на дизайна е да спрете да наричате всеки маркиран обект устройство,-свързано с интернет.

Пасивен UHF етикет може да съдържа EPC и да отговаря на запитващо устройство. Етикетът обикновено не отваря TCP/IP връзка, не удостоверява пред облачен брокер или публикува собствени съобщения през Wi-Fi. Инфраструктурата на четеца извършва RF транзакцията и след това предава данни в мрежов софтуер.

Това разграничение засяга сигурността, управлението на устройството и отстраняването на неизправности. Неуспешното четене на маркер-е RF проблем, докато не се докаже противното. Неуспехът на облачен API е проблем с мрежа/приложение. Комбинирането на двете под фразата „проблем с IoT“ прави анализа на първопричината-по-труден.

 

Четецът превръща физическите наблюдения в цифров вход

Четецът контролира комуникацията с RFID таговете в неговата зона за четене. В зависимост от системата, той може да инвентаризира EPC, да чете друга памет, да записва данни, да докладва информация за антената и да излага състоянието на устройството чрез SDK, LLRP, API или интерфейс на доставчика.

На този етап резултатът все още е по-близък до сензорно наблюдение, отколкото до бизнес събитие:

етикет EPC X е наблюдаван от четец Y на антена Z в момент T

Това наблюдение може да се повтори много пъти, докато етикетът остава в полето. Изпращането на всяко необработено наблюдение директно към облачно приложение може да създаде ненужен мрежов трафик и двусмислена бизнес логика.

 

Edge Logic трябва да почиства RFID данните, преди облакът да ги използва

Крайният RFID софтуер или мидълуер обикновено изпълнява първия слой на обработка на събития.

• премахване на дублирани четения в рамките на определен времеви прозорец;
• филтрирайте идентификатори, които не принадлежат към работния процес;
• асоциирайте четене с четец, антена, врата, работна станция или зона;
• прилагане на посока или логика на задействане, където инсталацията го поддържа;
• буферни наблюдения по време на прекъсване на мрежата;
• преобразувайте идентификатори на етикети в идентификатори на приложения;
• повдига изключения за неизвестни, дублирани или неочаквани тагове;
• публикувайте компактно събитие в следващата система.

Системната архитектура на GS1 поставя RFID четците и софтуера за филтриране/събиране на пътя за-улавяне на данни преди данните за събития-на ниво приложение. Семейството от стандарти за RFID включва интерфейси като LLRP и събития на ниво приложение за тази граница.

Важният принцип на проектиране е облакът да получава полезни събития, а не неконтролирано наводнение от радиочестотни наблюдения.

 

Използвайте модел на събитие, за да запазите значението в системите

След като RFID слоят идентифицира обект, следващият въпрос е какво се е случило с този обект.

GS1EPCIS стандартосигурява полезен модел за видими събития чрез изразяване накакво, кога, къде, защо и какна продукти и активи. EPCIS 2.0 също поддържа данни от сензори, което го прави подходящ, когато RFID идентичността се комбинира с температура, състояние или други IoT наблюдения.

Един проект не трябва да използва EPCIS, за да се учи от тази структура. Най-малко събитие от RFID-към-IoT обикновено трябва да съдържа достатъчно контекст, за да отговори:

• кой обект или обекти са включени;
• кога е настъпило събитието;
• къде е мястото на наблюдението;
• каква бизнес стъпка е настъпила;
• кое устройство или процес е довел до събитието;
• дали събитието е нормално или извънредно.

 

RFID идентификацията и IoT Sensing могат да споделят едно и също събитие

RFID често отговаря "кой обект е това?" докато сензорите отговарят "в какво състояние е?"

Свързана система със студена{0}}верига, например, може да използва RFID или баркод идентификатор за пратката и мрежов температурен сензор за измервания на околната среда. Производствена система може да идентифицира инструмент или детайл чрез RFID и да комбинира тази идентичност с данните за-състоянието или вибрациите на машината от отделни сензори.

Архитектурата трябва да поддържа източниците на данни различни дори когато приложението по-късно се присъедини към тях.

 

Решете какво трябва да остане на ръба

Облачната свързаност е полезна за много{0}}видимост на сайтове, анализи и централизирано управление, но не всяко решение за RFID трябва да чака двупосочно пътуване до облака.

Поддържайте логиката локална, когато процесът трябва да продължи по време на прекъсване на мрежата или се нуждае от физически контрол с ниска{0}}закъснение, като например:

• отваряне или спиране на конвейерна врата;
• задействане на стекова светлина или зумер;
• отхвърляне на неочакван маркиран елемент;
• буфериране на четения при загуба на WAN свързаност;
• премахване на дублиране на големи{0}}обемни четения;
• контролиране на мощността на четеца или последователността на антената.

Изпращайте събития от по-високо-ниво до облака, когато стойността идва от-видимост на сайтове, исторически анализ, табла за управление, отдалечено администриране или интеграция с корпоративни приложения.

 

Използвайте мрежовия слой за събития, а не за скриване на проблеми с RF дизайна

Свързаният четец не коригира зона за лошо четене.

Ако маркерите са пропуснати, защото са монтирани неправилно, екранирани с метал или течност, лошо ориентирани или извън предвиденото поле на антената, по-бързите облачни API не могат да възстановят липсващата самоличност. По същия начин, портал, който чете съседни тагове, просто ще изпраща лоши наблюдения по-ефективно.

RFID хардуерният слой трябва първо да бъде валидиран. на СинтекРъководство за RFID технологияпредоставя информация за честотата, етикетите, четците и антените преди стъпката на мрежова интеграция.

 

Изберете интерфейса за интегриране от мащаба за внедряване

GS1 отбелязва, че IoT архитектурите зависят от идентификация, автоматично улавяне на данни и оперативно съвместимо споделяне на данни. Това еПреглед на IoT стандартитеизрично позиционира EPC/RFID като една от технологиите, свързващи физически обекти с цифрова информация.

 

Отделете RFID сигурността от IoT мрежовата сигурност

RFID и IoT добавят различни повърхности за сигурност.

Слоят-четец на етикети може да включва публични идентификатори,-контролирана с парола памет, удостоверяване на маркери или никакво удостоверяване в зависимост от технологията. Слоят четец/мрежа може да включва идентификационни данни на устройство, API ключове, TLS, мрежово сегментиране, управление на фърмуера и разрешения в облака.

Силната позиция за сигурност в облака не трансформира прост RFID етикет с фиксиран{0}}ID в криптографски удостоверени идентификационни данни. По същия начин защитеният RFID етикет не защитава автоматично операционната система на четеца или мрежовата връзка.

Ръководството на NIST за IoT определя сигурността на -мрежово свързаното устройство като собствен проблем на жизнения цикъл. Отнасяйте се към въздушния интерфейс на RFID, четеца/крайното устройство и облачното приложение като отделни граници на доверие.

 

Планирайте офлайн работа, преди да имате нужда от нея

Индустриалните системи трябва да определят какво се случва, когато облачната или WAN връзката е недостъпна.

Въпросите към пилота включват:

• четецът продължава ли да работи локално;
• кои събития се буферират и за колко време;
• как се предотвратяват дублиращи се буферирани събития след повторно свързване;
• кои местни решения все още могат да бъдат взети;
• как системата маркира събития, създадени в офлайн режим;
• какво се случва, ако времето на устройството се отклони;
• как се синхронизират промените в конфигурацията след възстановяване.

Облачната свързаност трябва да разшири системата, а не да се превърне в непланирана единична точка на повреда.

 

Пилотирайте пълната транзакция-към-облак

Полезен RFID/IoT пилот тества цялата верига:

1. маркирайте представителния физически артикул;
2. валидиране на предвидената зона за четене;
3. улавяне на необработения идентификатор;
4. прилагане на филтриране по ръбове и контекст;
5. създаване на предвиденото бизнес събитие;
6. изпращане на събитието през мрежата;
7. потвърдете, че облакът или корпоративната платформа съхранява правилния елемент, местоположение и час;
8. задействат очакваното действие надолу по веригата;
9. тествайте дублирани четения, неизвестни тагове, прекъсване на мрежата и рестартиране на устройството;
10. проверете съгласуването след възстановяване.

Следователно успешното четене на етикет е само първата контролна точка.

 

Какво да поставите в спецификация за интегриране на RFID-към-IoT

Ако проектът все още избира RFID хардуер, този на SyntekКатегория RFID четеце следващата търговска стъпка, след като събитието за четене и границата на интеграция са дефинирани.

 

Правилото за интегриране

Практическата последователност е следната:

физически обект → RFID идентичност → зона за четене → наблюдение на четец → филтриране по граници → бизнес събитие → мрежов транспорт → IoT/облачна платформа → корпоративно действие

RFID и IoT не са конкуриращи се отговори на един и същи въпрос. RFID може да предостави надеждна физическа идентичност и наблюдения на събития; IoT инфраструктурата може да свързва, комбинира и разпространява тези събития. Архитектурата работи, когато всеки слой има ясна отговорност и проектът валидира цялата верига, вместо да приеме, че само свързаността създава полезни данни.