Інтеграція RFID та IoT: як теги, зчитувачі, Edge Logic і хмарні системи працюють разом

RFID та Інтернет речей часто порівнюють так, ніби проект повинен вибрати один або інший. У багатьох промислових системах це неправильне питання архітектури.

RFID – це технологія автоматичної ідентифікації-і збору даних. IoT описує підключені пристрої та системи, які обмінюються даними через мережі. Тому розгортання RFID може стати одним-рівнем захоплення даних у більшій архітектурі IoT: теги ідентифікують фізичні об’єкти, зчитувачі спостерігають за ними, периферійне програмне забезпечення перетворює необроблені зчитування на корисні події, а мережеві програми діляться цими подіями з хмарними або корпоративними системами.

У цьому посібнику пояснюється межа інтеграції для команд з активів, складів, виробництва та роздрібної торгівлі, яким потрібно з’єднати обладнання RFID із сучасними підключеними програмами, не розглядаючи кожен пасивний тег як пристрій, під’єднаний до Інтернету-.

 

RFID та IoT вирішують різні рівні однієї фізичної---цифрової проблеми

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

Читач або шлюз часто є мостом.

Для перегляду-на рівні компонентів самого RFID, SyntekПосібник з архітектури системи RFIDпояснює теги, антени, зчитувачі, проміжне програмне забезпечення та прикладне програмне забезпечення. Ця сторінка присвячена інтеграції між цим стеком RFID і середовищем IoT.

 

Пасивний тег RFID зазвичай не є кінцевою точкою Інтернету речей

Одним із найкорисніших обмежень дизайну є припинення називання кожного позначеного об’єкта пристроєм,-підключеним до Інтернету.

Пасивна УВЧ-мітка може містити EPC і відповідати запитувачу. Зазвичай тег не відкриває з’єднання TCP/IP, не виконує автентифікацію в хмарному посереднику чи не публікує власні повідомлення через Wi-Fi. Інфраструктура зчитувача виконує радіочастотну транзакцію, а потім передає дані в мережеве програмне забезпечення.

Ця різниця впливає на безпеку, керування пристроєм і усунення несправностей. Помилка читання тегу- є проблемою РЧ, доки не буде доведено протилежне. Збій хмарного API є проблемою мережі/програми. Об’єднання обох під фразою «проблема IoT» ускладнює-аналіз першопричини.

 

Reader перетворює фізичні спостереження на цифрові дані

Зчитувач контролює зв’язок із мітками RFID у своїй зоні зчитування. Залежно від системи він може інвентаризувати EPC, читати іншу пам’ять, записувати дані, повідомляти інформацію про антену та показувати стан пристрою через SDK, LLRP, API або інтерфейс постачальника.

На цьому етапі результат все ще ближче до сенсорного спостереження, ніж до бізнес-події:

тег EPC X спостерігався читачем Y на антені Z у момент часу T

Це спостереження можна повторити багато разів, поки тег залишається в полі. Надсилання кожного необробленого спостереження безпосередньо до хмарної програми може створити непотрібний мережевий трафік і неоднозначну бізнес-логіку.

 

Edge Logic має очищати дані RFID перед тим, як їх використовуватиме хмара

Програмне забезпечення або проміжне програмне забезпечення RFID зазвичай виконує перший рівень обробки подій.

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

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

Важливим принципом проектування є те, що хмара повинна отримувати корисні події, а не неконтрольований потік радіочастотних спостережень.

 

Використовуйте модель подій, щоб зберегти значення в системах

Після того, як рівень RFID ідентифікує об’єкт, виникає наступне питання, що сталося з цим об’єктом.

GS1Стандарт EPCISнадає корисну модель для подій видимості, виражаючищо, коли, де, чому і якпродуктів і активів. EPCIS 2.0 також підтримує дані датчиків, що робить його актуальним, коли ідентифікація RFID поєднується з температурою, станом або іншими спостереженнями IoT.

Проект не повинен використовувати EPCIS, щоб навчатися з цієї структури. Принаймні подія RFID-to-IoT зазвичай має містити достатній контекст для відповіді:

• який об'єкт або об'єкти були задіяні;
• коли відбулася подія;
• куди відноситься спостереження;
• який бізнес-крок відбувся;
• який пристрій або процес викликав подію;
• чи є подія нормальною чи винятковою.

 

RFID-ідентифікація та IoT Sensing можуть спільно використовувати ту саму подію

RFID часто відповідає "який це об'єкт?" а датчики відповідають "в якому стані?"

Підключена система холодового ланцюга, наприклад, може використовувати RFID або ідентифікатор штрих-коду для відправлення та мережевий датчик температури для вимірювань навколишнього середовища. Виробнича система може ідентифікувати інструмент або деталь за допомогою RFID і поєднувати цю ідентичність із даними-стану чи вібрації машини з окремих датчиків.

Архітектура повинна зберігати джерела даних різними, навіть коли програма пізніше приєднується до них.

 

Вирішіть, що має залишатися на межі

Підключення до хмари є корисним для-бачення кількох сайтів, аналітики та централізованого керування, але не кожне рішення RFID має чекати повернення до хмари.

Зберігайте логіку локально, коли процес має продовжуватися під час збоїв у мережі або потребує низького -фізичного контролю, наприклад:

• відкриття або зупинка воріт конвеєра;
• спрацьовування індикатора стека або зумера;
• відхилення неочікуваного позначеного елемента;
• буферизація читань під час втрати з'єднання з WAN;
• дедуплікація великих{0}}обсягів читання;
• керування живленням зчитувача або послідовністю антени.

Надсилайте події вищого рівня-до хмари, коли цінність надходить від видимості-сайтів, історичного аналізу, інформаційних панелей, віддаленого адміністрування чи інтеграції з корпоративними програмами.

 

Використовуйте мережевий рівень для подій, а не для того, щоб приховувати проблеми проектування РЧ

Підключений зчитувач не виправляє зону поганого зчитування.

Якщо теги пропущені через те, що вони встановлені неправильно, захищені металом або рідиною, погано орієнтовані або знаходяться за межами призначеного поля антени, швидші хмарні API не зможуть відновити втрачену ідентифікацію. Подібним чином портал, який читає сусідні теги, просто ефективніше надсилатиме помилкові спостереження.

Спочатку потрібно перевірити апаратний рівень RFID. СинтекКерівництво по технології RFIDнадає довідкову інформацію про частоту, теги, зчитувачі та антени перед кроком мережевої інтеграції.

 

Виберіть інтерфейс інтеграції зі шкали розгортання

GS1 зазначає, що архітектури IoT залежать від ідентифікації, автоматичного збору даних і сумісного обміну даними. ЙогоОгляд стандартів IoTчітко позиціонує EPC/RFID як одну з технологій, що зв’язує фізичні об’єкти з цифровою інформацією.

 

Відокремте безпеку RFID від безпеки мережі IoT

RFID та IoT додають різні поверхні безпеки.

Рівень-зчитувача тегів може включати загальнодоступні ідентифікатори,-керовану паролем пам’ять, автентифікацію тегів або взагалі без автентифікації, залежно від технології. Рівень зчитувач/мережа може включати облікові дані пристрою, ключі API, TLS, сегментацію мережі, керування вбудованим програмним забезпеченням і дозволи хмари.

Надійна хмарна безпека не перетворює просту фіксовану-мітку RFID на ідентифікаційні дані з криптографічною автентифікацією. Подібним чином захищена мітка RFID не захищає автоматично операційну систему або мережеве підключення зчитувача.

Керівництво NIST IoT визначає безпеку-підключених до мережі пристроїв як власну проблему життєвого циклу. Розглядайте повітряний інтерфейс RFID, пристрій зчитування/граничний пристрій і хмарну програму як окремі межі довіри.

 

Плануйте роботу в автономному режимі, перш ніж вона вам знадобиться

Промислові системи повинні визначати, що відбувається, коли хмарне або глобальне підключення недоступне.

Питання для пілота включають:

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

Хмарне підключення має розширювати систему, а не ставати незапланованою єдиною точкою збою.

 

Пілотуйте повну транзакцію з фізичної-до-хмари

Корисна пілотна програма RFID/IoT перевіряє весь ланцюжок:

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

Таким чином, успішне зчитування тегу є лише першою контрольною точкою.

 

Що додати до специфікації інтеграції RFID-to-IoT

Якщо проект все ще вибирає обладнання RFID, SyntekКатегорія зчитувача RFIDє наступним комерційним кроком після визначення події читання та межі інтеграції.

 

Правило інтеграції

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

фізичний об’єкт → RFID-ідентифікація → зона зчитування → спостереження за зчитувачем → гранична фільтрація → бізнес-подія → мережевий транспорт → IoT/хмарна платформа → корпоративна дія

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