Guide til EPC Reader Protocol 1.1-standarden

Download  EPC Reader Protocol-standarden

Overblik over EPC Reader Protocol 1.1

EPC Reader Protocol 1.1 er en EPCglobal-standard, der definerer, hvordan hostsoftware kommunikerer med en taglæser. En læser er ikke begrænset til ét bestemt radiodesign. Det kan være en fast RFID-læser, en håndholdt læser eller en enhed, der aflæser ikke-RF-bærere som eksempelvis stregkoder. Protokollen fokuserer på grænsefladen mellem Reader og Host og ikke på luftgrænsefladen mellem læseren og tagget. Denne adskillelse gør det muligt for lagersystemer, eventplatforme, detailløsninger og servere til aktivsporing at anmode om data, konfigurere læseadfærd og modtage rapporter uden at skulle håndtere alle RF-detaljer på lavt niveau.

Standarden er udviklet til leverandører af EPC-middleware, producenter af læsere, applikationsudviklere og systemintegratorer. Det praktiske formål er at skabe en fælles model for styring og rapportering på tværs af læsere fra forskellige producenter. For virksomheder, der implementerer faste UHF-læsere, portallæsere, desktoplæsere eller mobile scanningsenheder, kan en standardiseret læserprotokol reducere integrationsomkostningerne og gøre applikationslogikken lettere at genbruge på tværs af hardwareplatforme. Samtidig giver den tekniske teams et struktureret begrebsapparat til kommandoer, Sources, ReadPoints, Triggers, selectors, events, NotificationChannels og datarapporter.

Hvad protokollen omfatter

EPC Reader Protocol 1.1 specificerer samspillet mellem to parter: Reader og Host. Reader er den enhed eller enhedsfunktion, der indsamler tagdata og i visse tilfælde også kan skrive data. Host er typisk middleware, en EPC-kompatibel applikation eller et andet softwaresystem, der styrer læseren og behandler de indsamlede oplysninger. Protokollen skjuler detaljerne i kommunikationen mellem læseren og tags. En læser kan understøtte forskellige RF-protokoller eller andre sensorteknologier, mens hostsystemet fortsat kan anvende de samme grundlæggende begreber til at anmode om operationer og modtage resultater.

Protokollen beskriver også krav til overensstemmelse gennem obligatorisk og valgfri funktionalitet. Kommandoer udtrykkes som operationer i en objektmodel for læseren. En kompatibel læser behøver ikke at anvende den samme interne softwarearkitektur som andre produkter, men den skal fortolke kommandobeskeder korrekt, opretholde den krævede funktionalitet og generere de forventede notifikationer. Det gør standarden relevant ved softwaredesign, produktdokumentation, interoperabilitetstest og fastlæggelse af acceptkriterier i RFID-projekter.

Protokollens arkitektur

Reader Layer

Reader Layer definerer indholdet og den abstrakte syntaks for de beskeder, der udveksles mellem Reader og Host. Det er protokollens centrale lag, fordi det beskriver betydningen af de enkelte operationer. Det omfatter blandt andet, hvordan en host finder en læser, refererer til Sources, opretter TagSelectors, konfigurerer læsetriggere, starter læsning, skriver tagdata, henter data fra køer og administrerer NotificationChannels. I Reader Layer omsættes kravene fra forretningsapplikationen til standardiserede handlinger på enheden.

Messaging Layer og Transport Layer

Messaging Layer definerer, hvordan beskeder fra Reader Layer formateres, indrammes, transformeres og repræsenteres. EPC Reader Protocol 1.1 omfatter både tekst- og XML-formatering af beskeder, så implementeringer kan omsætte de samme abstrakte kommandoer til konkret beskedsyntaks. Transport Layer svarer til det netværk eller kommunikationsmedie, der anvendes til at overføre beskederne, eksempelvis TCP, HTTP eller seriel kommunikation. En bestemt kombination af beskedformat og transportmetode kaldes en Messaging/Transport Binding, forkortet MTB. Denne lagdelte arkitektur gør det muligt at anvende forskellige kommunikationsmetoder og samtidig bevare en ensartet model for styring af læseren.

Message Channels og styring af RFID-læsere

Protokollen definerer to vigtige typer kommunikationskanaler. Control Channel overfører anmodninger fra Host til Reader og svar fra Reader tilbage til Host. Det er den normale request-response-kanal til konfiguration og udførelse af kommandoer. Notification Channel overfører asynkrone beskeder fra Reader til Host. Det er især relevant, når taglæsninger skal leveres uden konstant polling. Læseren kan sende information om events eller rapporter, efterhånden som data bliver tilgængelige, hvilket er værdifuldt i RFID-installationer med høj gennemstrømning.

Denne kanalstruktur understøtter fleksible systemarkitekturer. Én host kan stå for konfigurationen af læseren, mens en anden host modtager notifikationer. I enklere installationer kan den samme host varetage begge roller via den samme forbindelse. Modellen passer også til blandede miljøer, eksempelvis læsning ved læsseramper med faste antenner, arbejdsstationer med desktop-enheder og operatører, der benytter håndholdte læsere til håndtering af undtagelser. Standarden kræver ikke, at alle læsere understøtter samtlige funktioner, men den definerer, hvordan de funktioner, der understøttes, skal eksponeres.

Objektmodel, læsepipeline og events

Objektmodellen giver protokollen en tydelig struktur. ReaderDevice er hovedobjektet og repræsenterer selve læseren. Sources repræsenterer logiske kilder til dataindsamling, eksempelvis antenner eller scannerindgange. ReadPoints repræsenterer fysiske registreringspunkter. Triggers definerer de betingelser, der starter operationer. TagSelectors gør det muligt at filtrere tagdata, så hostsystemet kun modtager information, der er relevant for applikationen. DataSelectors bestemmer, hvilke felter der medtages i rapporterne. NotificationChannels forbinder Sources og udvalgte data med asynkron rapportering til hostsystemet.

Læsepipelinen kan betragtes som en sekvens bestående af dataindsamling, filtrering, generering af events, dataudvælgelse, buffering og notifikation. En read cycle er det mindste indsamlingsinterval, hvor data registreres fra én eller flere Sources. Filtre reducerer antallet af irrelevante aflæsninger, hvilket er afgørende, når mange tags befinder sig i læserens felt. Eventgenerering reducerer yderligere datastøj ved at omsætte gentagne observationer til meningsfulde tilstandsændringer, eksempelvis når et tag først registreres, fortsat observeres eller ikke længere kan ses. Denne udjævning hjælper applikationer med at undgå at reagere på hvert enkelt midlertidigt manglende read.

Hvorfor EPC Reader Protocol 1.1 stadig er relevant

Selvom moderne RFID-projekter kan anvende andre reader-API'er eller protokoller på et lavere niveau, er EPC Reader Protocol 1.1 fortsat en værdifuld reference til forståelse af middleware-siden i en RFID-arkitektur. Standarden illustrerer, hvorfor læsere ikke kun bør betragtes som enheder, der udsender rå data. De kan stille konfigurerbare Sources, Triggers, filtre, rapportbuffere og eventlogik til rådighed. Det er relevant for teknikere, der planlægger adgangskontrol, lagersynlighed, logistikautomatisering, dokumentsporing, bibliotekssystemer, vaskeridrift og sporbarhed i produktionen.

For indkøbere og systemdesignere tydeliggør standarden desuden, hvilke spørgsmål der bør afklares før valg af hardware. Kan læseren håndtere flere Sources? Understøtter den asynkrone notifikationer? Kan hostsystemet konfigurere read cycles, duty cycle-adfærd og filtrering? Dokumenterer leverandøren de understøttede beskedformater og transportbindings? Disse spørgsmål reducerer risikoen for integrationsproblemer og gør det lettere at matche læserhardware, middleware og RFID-medier med de faktiske driftsforhold.

FAQ

Hvad bruges EPC Reader Protocol 1.1 til?

EPC Reader Protocol 1.1 bruges til at definere grænsefladen mellem en taglæser og hostsoftware. Protokollen gør det muligt for middleware eller applikationer at styre læserens funktioner, anmode om tagoperationer, konfigurere læseparametre og modtage datarapporter. Den er især relevant i systemer, hvor læsere fra forskellige producenter skal integreres i en ensartet model for kommandoer og rapportering.

Definerer EPC Reader Protocol 1.1, hvordan RFID-tags kommunikerer via radio?

Nej. Protokollen definerer ikke RF-luftgrænsefladen mellem et tag og en læser. Denne del hører under RF-protokoller for tags, eksempelvis specifikationer relateret til EPCglobal Class 1 eller Gen2. EPC Reader Protocol 1.1 fokuserer på softwareinteraktionen mellem Reader og Host og afskærmer dermed applikationen fra detaljerne i tagkommunikationen på lavt niveau.

Hvad er forskellen på en Control Channel og en Notification Channel?

En Control Channel overfører anmodninger fra hostsystemet og svar fra læseren og følger derfor et request-response-mønster. En Notification Channel overfører asynkrone beskeder, som initieres af læseren. I praksis anvendes kontrolkanalen til konfiguration og kommandoer, mens notifikationskanalen bruges, når læseren rapporterer tagaflæsninger eller events uden at afvente polling fra hostsystemet.

Hvorfor anvender protokollen en objektmodel?

Objektmodellen giver en ensartet måde at beskrive læserens funktioner på. Objekter som ReaderDevice, Source, Trigger, TagSelector, DataSelector og NotificationChannel gør det muligt for hostsystemer at adressere funktioner på en struktureret måde. En producent behøver ikke at opbygge den interne firmware efter præcis samme model, men den eksterne adfærd skal svare til protokollen, hvis produktet angives som kompatibelt.

Hvordan forbedrer TagSelectors og DataSelectors håndteringen af RFID-data?

TagSelectors reducerer unødvendige data ved at filtrere, hvilke tagobservationer der er relevante for hostapplikationen. DataSelectors bestemmer, hvilke felter der vises i rapporterne. Tilsammen kan de reducere netværkstrafik, rapportstørrelse og den behandling, der kræves i applikationen. Det er særligt nyttigt i tætte læsezoner, hvor mange tags kan være synlige, mens kun en del af dem har operationel betydning.

Hvad bør systemintegratorer kontrollere, før protokollen anvendes i et projekt?

Systemintegratorer bør kontrollere, hvilke kommandoer, beskedformater, transportmetoder, notifikationsmuligheder, Triggers og filtreringsfunktioner den valgte læser faktisk understøtter. Specifikationen indeholder både obligatoriske og valgfrie elementer, og derfor er den konkrete implementering vigtig. En god projektplan bør sammenholde læserens dokumentation med hostapplikationens krav til dataflow, latenstid og rapportering.