Как да настроите RFID портал да игнорира случайни тагове върху мотокари

RFID порталът може да изглежда идеално при чист тест, но да започне да създава проблеми веднага щом около него започнат да се движат мотокари. Един палет минава през портала, четецът улавя правилните тагове и всички са спокойни. След това наблизо преминава мотокар с несвързан оборотен контейнер, маркирана чанта с инструменти, RFID бадж на служител или полупразен палет от друга поръчка. Изведнъж порталът отчита допълнителни EPC кодове, грешни количества за експедиция, фалшиви събития при приемане и складови записи без логика. Това не означава непременно, че хардуерът е повреден. Порталът просто „слуша“ по-голяма част от склада, отколкото трябва.

Това е един от най-често срещаните проблеми при внедряване на UHF RFID портали. Четецът е мощен. Антените са достатъчно широки, за да покрият отвора. Мотокарът е метален, отразяващ и постоянно в движение. Складът е пълен с маркирани палети, кашони, каси, облекла, оборотни контейнери, връщаеми съдове и оборудване. Ако порталът е конфигуриран да приема всеки таг, който чуе, рано или късно ще отчете тагове, преминали само близо до зоната на четене, а не през самия процес. Така случайните тагове върху мотокар се превръщат в лоши бизнес данни.

Целта не е RFID порталът да чете по-малко. Целта е да чете дисциплинирано. Добре настроеният RFID портал трябва да разпознава таговете, които принадлежат на конкретното събитие: палет, влизащ в зона за приемане, пратка, напускаща рампата, контейнер, преминаващ през производствен портал, или количка, влизаща в чиста зона. Той трябва да игнорира тагове, които се движат наблизо върху мотокар, стоят на стелаж за подготовка, паркирани са до вратата или минават зад антените. За това е необходима комбинация от RF настройка, физически дизайн, логика на тригерите, междинен софтуер филтриране, сравнение с очаквани списъци и дисциплина на операторите.

Логистичен 3PL склад в Chicago откри това по време на проект за RFID контрол на изходящи пратки. Док порталът беше монтиран между две товарни линии. По време на пилота той четеше правилно маркираните кашони върху изходящите палети. При реална работа обаче мотокари често преминаваха зад портала с входящи върнати стоки. Четецът улавяше тези тагове и ги добавяше към изходящите пратки. Първоначално складът обвини RFID етикети, после WMS системата, после водачите на мотокари. Истинското решение беше да се стесни зоната на четене, да се намали мощността на антените, да се добави фотоелектричен тригер при входа на портала и да се приемат четения само в активния времеви прозорец на преминаване на палета. Порталът спря да се държи като скенер за целия склад и започна да работи като контролна точка на дока.

Първо контролирайте физическата зона на четене

Започнете с физическо разделяне. Ако мотокари с несвързани маркирани товари могат да преминават близо до портала, системата винаги ще бъде изложена на риск. RF настройката помага, но не може напълно да компенсира лошо оформление. Разположете зоните за подготовка далеч от антените на портала. Не паркирайте маркирани палети до входа. Не позволявайте на мотокари да чакат с маркирани товари в антенния обхват. Обозначете ясна лента за преминаване и зона без съхранение около портала. В много складове няколко боядисани линии на пода и по-добри правила за движение решават половината проблем още преди да се пипне софтуерът.

Дистрибутор на храни в Rotterdam имаше RFID портал за приемане, който постоянно четеше маркирани пластмасови каси, паркирани до входящата врата. Касите не преминаваха през портала, но стояха достатъчно близо, за да бъдат улавяни всеки път, когато четецът се активираше. Интеграторът настройваше четеца няколко пъти, но успехът беше само частичен. Накрая складът премести зоната за каси на три метра разстояние и добави жълта зона без съхранение на RFID тагове до портала. Фалшивите четения спаднаха веднага. Изводът беше прост: порталът не може вечно да игнорира куп тагове, които стоят буквално „в ушите“ му.

Оформете покритието на антените около траекторията на преминаване

Следва позиционирането на UHF RFID антени. Много екипи монтират антените твърде широко, защото се страхуват от пропуснати четения. Четири антени „обстрелват“ отвора, всички на висока мощност, и системата започва да чете тагове от ъгли, които никой не е планирал. По-добрата конфигурация оформя полето на четене около реалната траектория на преминаване. Страничните антени трябва да гледат към пътя на палета, а не към целия док. Горни антени трябва да се използват само ако помагат за тагове, обърнати нагоре. Антените е добре да бъдат леко насочени навътре и при нужда екранирани. Зоната на четене трябва да бъде достатъчно стегната, така че мотокар, преминаващ наблизо, да не стане част от транзакцията.

Дистрибуционен център за облекло в Milan имаше портал, който четеше кашони с висящи дрехи върху колички. Четците улавяха правилните колички, но също така „чуваха“ тагове на дрехи, които се движеха върху мотокари в съседната алея. Първоначалният ъгъл на антените беше твърде отворен. Екипът завъртя страничните антени към центъра на портала, намали мощността на горната антена и добави RF абсорбиращи панели от страната, откъдето най-често идваха случайните тагове. Порталът продължи да чете пълните колички, но апетитът му стана много по-контролиран. Точността на броенето се подобри, защото антените спряха да се опитват да „виждат зад ъгъла“.

Настройвайте мощността на четеца от най-ниското надеждно ниво

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

Склад за потребителска електроника в Shenzhen използваше UHF RFID портали за проверка на изходящи кашони с аксесоари. Порталът беше настроен на максимална мощност, защото част от таговете бяха скрити зад термосвиваемо фолио. Системата обаче четеше и маркирани контейнери за връщане върху мотокари, преминаващи зад дока. Доставчикът подобри позиционирането на етикетите върху кашоните, което позволи мощността на четеца да бъде намалена. След като етикетите започнаха по-постоянно да гледат към портала, четецът вече нямаше нужда да „крещи“. По-ниската мощност и по-добрата ориентация на таговете решиха проблем, който първоначално изглеждаше софтуерен.

Използвайте тригери и логика за посока, за да дефинирате събитието

Използвайте тригери, за да определите кога едно събитие на четене започва и кога завършва. Портал, който чете непрекъснато, ще събира случайни тагове през целия ден. Фотоелектричен датчик, светлинна завеса, подов контур, сензор за присъствие на мотокар, статус на док врата, конвейерен сензор или PLC сигнал могат да кажат на четеца кога действително се случва легитимно преминаване. Четецът трябва да слуша в този кратък прозорец, да улови таговете, да обработи събитието и след това да изчисти буфера. Тригерът поставя времеви граници около зоната на четене.

Хладилен склад в Toronto проследяваше изолирани контейнери, преминаващи през врати към фризерни помещения. Мотокари с несвързани маркирани контейнери често минаваха близо до вратата. Първоначално порталът сканираше непрекъснато, за да не пропуска бързи движения. Това създаваше хаотични данни. Новата конфигурация използва фотоелектричен датчик от страната на вратата и двусекунден прозорец за четене след влизането на количката с контейнери в портала. Четенията преди или след този прозорец се игнорираха. Екипът във фризерната зона продължи да работи бързо, но софтуерът най-после разбираше кои тагове принадлежат на конкретното преминаване.

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

Завод за автомобилни части в Ohio използваше RFID портал между зоната за механична обработка и супермаркета за монтаж. Мотокари понякога се движеха успоредно на портала, носейки маркирани метални контейнери. Четецът улавяше тези тагове и системата смяташе, че контейнерите са преместени към монтажа. Заводът добави два фотоелектрични датчика и изискваше валидна входна последователност: сензор A, след това сензор B, след това улавяне на тагове. Мотокари, преминаващи странично, не създаваха тази сензорна последователност, затова техните тагове се игнорираха. Порталът стана по-интелигентен, защото посоката на движение стана част от събитието.

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

Middleware филтрирането е мястото, където много RFID портали или стават надеждни, или създават хаос. Суровите четения не са бизнес събития. Четецът може да види един и същ таг 50 пъти за една секунда. Може за миг да чуе случаен таг. Може да улови таг от близък мотокар при слаб сигнал. Middleware системата трябва да използва правила като минимален брой четения, продължителност на четене, източник на антената, RSSI праг, тригерен прозорец, очаквана локация и посока на събитието. Таг, видян веднъж и слабо извън тригерния прозорец, не трябва да се третира като таг, прочетен многократно от двете антени на портала по време на валидно преминаване.

Оператор на оборотни контейнери в Hamburg имаше портал, който улавяше твърде много случайни ID номера от контейнери върху мотокари. Първоначално интеграторът използваше просто правило: всеки таг, видян по време на сканирането, се приема. Това правило беше твърде щедро. Обновената междинен софтуер логика изискваше тагът на контейнера да бъде прочетен поне три пъти, от очакваната двойка антени, в рамките на активния прозорец на преминаване. Слабите единични четения от близки мотокари се класифицираха като фонов шум. Системата не се нуждаеше от идеална тишина. Нуждаеше се от по-умно определение за доказателство.

Използвайте RSSI като един сигнал, а не като цялото правило

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

Фармацевтичен обект за опаковане в Singapore използваше RFID портал за проследяване на запечатани контейнери за клинични изпитвания. Екипът забеляза периодични случайни четения от маркирани колички, преминаващи извън портала. Middleware екипът добави минимален RSSI праг, но той по грешка филтрираше и някои легитимни контейнери, чиито тагове бяха обърнати настрани от антената. Финалното правило използваше RSSI плюс брой четения и сензорно време. Слаб таг все пак можеше да бъде приет, ако беше прочетен многократно по време на валидно преминаване. Силен, но извънпрозоречен таг се отхвърляше. Порталът стана надежден, защото правилата бяха балансирани.

Сравнявайте сканираните тагове с очаквани списъци

Филтрирането по очакван списък е един от най-силните инструменти за проверка на пратки и производство. Ако WMS знае кой палет, кашон, контейнер или каса трябва да премине през конкретен портал, RFID системата може да сравни сканираните тагове с този списък. Тагове, които не са в очакваната пратка, могат да бъдат маркирани като случайни, неочаквани или изключения, вместо автоматично да се приемат. Това е особено полезно, когато мотокари движат няколко маркирани товара близо до един и същ док.

Дистрибутор на напитки в Madrid използваше RFID портал за проверка на изходящи палети. Мотокари често пренасяха връщаеми кегове покрай товарната лента, докато изходящите палети се зареждаха. Порталът понякога виждаше таговете върху яките на кеговете. WMS вече имаше очакваните EPC кодове на кашоните за всяка пратка, затова интеграторът промени логиката: само очаквани EPC кодове можеха да потвърдят пратката. Неочакваните четения се записваха отделно и не замърсяваха изходящата поръчка. Бизнес събитието стана чисто, защото порталът вече не третираше всяко четене като равностойно.

Разделяйте класовете тагове, преди да замърсят данните за пратки

Дизайнът на популацията от тагове също има значение. Ако всеки обект в сградата използва един и същ формат на таг без метаданни, филтрирането става по-трудно. Обмислете използване на префикси, EPC схеми, кодове за клас на артикула или базови категории, които разграничават палети, контейнери, мотокарни активи, служебни баджове, инструменти, облекла, връщаеми съдове и кашони за пратки. Така порталът може да игнорира цели класове тагове, които никога не трябва да участват в този процес. Док порталът не трябва да третира таг за поддръжка на мотокар или служебен бадж като изходящ кашон.

Склад в Dallas имаше RFID портал, който понякога улавяше тагове на инструменти от колички за поддръжка, движещи се близо до дока. Тези тагове влизаха в списъка с изключения и дразнеха супервайзорите. Компанията обнови EPC структурата и междинен софтуер класификацията. Таговете за инструменти, мотокари, служебни баджове и пратки бяха разделени по категории. Док порталът продължи да записва случайните класове за диагностика, но само тагове на кашони за пратка можеха да станат част от изходящо събитие. По-чистите данни за таговете направиха филтрирането много по-лесно.

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

Екип за складова автоматизация в Melbourne маркира всеки мотокар с устойчиви UHF RFID тагове за проследяване на поддръжката. След това няколко портала започнаха да отчитат едни и същи ID номера на мотокари по време на движения на палети. Данните бяха технически правилни, но оперативно безполезни в записите за пратки. Middleware системата беше актуализирана така, че таговете на мотокари да се разпознават като активи на оборудване и да се изключват от събитията за проверка на палети. ID номерата на мотокарите останаха полезни за одити на поддръжката, но вече не се появяваха като фантомно експедирани артикули.

Направете движението на мотокарите по-повторяемо

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

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

Стеснявайте лентата на портала, когато е възможно

Ширината на портала е още един практически фактор. Широкият отвор изисква широко RF покритие, а широкото RF покритие привлича случайни четения. Ако процесът позволява, стеснете лентата за четене с боларди, направляващи релси, завеси или странични панели. Контролираната лента помага на портала да се фокусира върху един товар в даден момент. В операции с голям обем това може да изглежда ограничително, но често предотвратява по-скъпия проблем с лоши складови данни. Бързото грешно четене не е по-добро от малко по-бавно, но чисто четене.

Дистрибутор на строителни материали в Phoenix използваше широка док врата за смесени палети и обемисти стоки. RFID порталът улавяше тагове от мотокари, преминаващи по ръба на отвора, докато друг палет се сканираше. Компанията добави физически водачи за лентата и въведе правило за еднократно преминаване на един мотокар при маркирани пратки. Точността на портала се подобри достатъчно, за да намалеят споровете по пратки. Мениджърът на обекта каза, че най-добрият RFID филтър се оказали два стоманени боларда и малко търпение.

Използвайте екраниране и тежест на антените при трудни оформления

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

Склад за медицински изделия в Switzerland имаше два RFID портала гръб в гръб: един за приемане на стерилни продукти и един за върнати стоки. Случайни четения се прехвърляха между двете зони всеки път, когато мотокари минаваха зад порталите. Нямаше място за преместване на порталите. Интеграторът монтира странично екраниране и коригира ъглите на антените, за да намали видимостта между лентите. Middleware филтрирането остана активно, но RF средата стана много по-тиха. Физическото екраниране даде на софтуера по-малко шум за борба.

Не всички антени в конфигурация с няколко антени трябва да се третират еднакво. Ако даден таг е прочетен само от задна антена или само от антена, за която е известно, че улавя случаен трафик от мотокари, това четене може да заслужава по-ниска увереност. Ако същият таг е прочетен от лявата и дясната антена на портала в правилната последователност, увереността трябва да е по-висока. Данните за източника на антената помагат на междинен софтуер системата да реши дали тагът наистина е бил вътре в пътя на портала.

Център за дистрибуция на хранителни стоки в Atlanta използваше четири антени около палетен портал. Таговете, прочетени от вътрешните странични антени, обикновено бяха легитимни. Таговете, прочетени само от горната задна антена, често идваха от мотокари, движещи се зад портала. Middleware логиката беше обновена с тежест на антените. Събития с висока увереност изискваха четения от страничните антени по време на тригерния прозорец. Четения само от задната антена се третираха като фон, освен ако не бъдат потвърдени от други антени. Хардуерът остана същият, но системата научи на кои антени да се доверява за всяко събитие.

Изчиствайте буферите между събитията на четене

Не забравяйте изчистването на буфера. Някои портали изглеждат така, сякаш четат случайни тагове, защото буферът на четеца или паметта на приложението все още съдържат тагове от предишно събитие. След всяка транзакция системата трябва да изчиства временните списъци с тагове, преди да започне следващия прозорец за четене. Старите EPC кодове не трябва да „пътуват“ към следващото събитие на пратка. Това е особено важно в натоварени док линии, където мотокарите се движат бързо.

Склад в Toronto имаше портал, който понякога добавяше един допълнителен кашон към следващото палетно събитие. Допълнителният таг не се четеше по време на новото преминаване. Той беше останал във временен буфер от предишното преминаване, защото командата за нулиране понякога се проваляше. Интеграторът добави по-силен handshake: изчисти буфера, потвърди изчистването, започни четене, спри четенето, публикувай събитието, изчисти отново. Фантомните тагове изчезнаха. Мотокарът беше обвиняван, но реалният проблем беше небрежно управление на жизнения цикъл на събитието.

Тествайте с реални мотокари и сценарии със случайни тагове

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

3PL оператор в New Jersey създаде стрес тест, преди да приеме нов док портал. Екипът премести правилната пратка през входа, докато друг мотокар преминаваше покрай него с несвързани маркирани кашони. Те паркираха маркирани контейнери отстрани. Тестваха бавно и бързо преминаване. Тестваха водач, който спира по средата. Първата конфигурация се провали сериозно. След настройка на мощността, промени в тригерите, филтриране по очакван списък и зона без съхранение, порталът премина теста. Интеграторът по-късно призна, че този „грозен“ тест е бил по-полезен от всяка чиста демонстрация в шоурум.

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

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

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

Финален извод: прочитът на таг не е процесно събитие

Причината това да работи е проста: прочитът на таг не е същото като процесно събитие. Четецът може да чуе много тагове. За бизнеса имат значение само таговете, които са преминали през правилното място, в правилното време и по правилната причина. След като изградите портала около тази идея, случайните тагове върху мотокари престават да бъдат загадка. Те се превръщат във фонови сигнали, които системата знае как да игнорира.

Добре конфигурираният RFID портал работи спокойно. Мотокар докарва правилния палет през лентата. Тригерът стартира прозореца за четене. Антените улавят таговете вътре в портала. Middleware системата ги сравнява с очакваната пратка. Случайните тагове от мотокар, който преминава наблизо, се записват отделно или се игнорират. Записът на пратката се обновява чисто. Никой не трябва да трие фантомни EPC кодове от WMS. Никой не спори дали четецът е твърде чувствителен. Порталът се държи като контролирана проверочна точка, а не като радиомрежа, хвърлена върху цялата сграда.

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