Download Method Summary - Cátedra Orange - Universidad Politécnica de

Universidad Politécnica de Madrid
ETSI de Telecomunicación
Departamento de Ingeniería de Sistemas Telemáticos
INFORME DE PROYECTO
ANÁLISIS DE SERVICIOS DE
IDENTIFICACIÓN-LOCALIZACIÓN BASADOS
EN RFID
Responsable:
JUAN CARLOS DUEÑAS LÓPEZ
Madrid, Marzo de 2004
Análisis de servicios de identificación-localización basados en RFID
ESCUELA TÉCNICA SUPERIOR DE INGENIEROS DE
TELECOMUNICACIÓN
INFORME DE PROYECTO
Caracterización del proyecto
ANÁLISIS DE SERVICIOS DE IDENTIFICACIÓNTítulo:
LOCALIZACIÓN BASADOS EN RFID
Departamento: Dpto. de Ingeniería de Sistemas Telemáticos
Juan C. Dueñas
Responsable:
Pablo Pancardo
Autores:
José Vicente Espinosa
José L. Ruiz
José L. Arciniegas
Rodrigo Cerón
Historial de versiones:
1 de enero de 2004.
Versión 0.1
Primer borrador.
1 de marzo de 2004.
Versión 0.8
Segundo borrador.
8 de marzo de 2004.
Versión 1.0
Versión final.
2
Análisis de servicios de identificación-localización basados en RFID
Índice de contenidos
1. Enfoque del trabajo ................................................................................................................ 5
2. Introducción a la tecnología RFID y la identificación ........................................................... 7
2.1. La historia de los sistemas RFID................................................................................... 11
2.2. Actores en la estandarización de RFID ......................................................................... 16
2.3. Despliegues de RFID en curso ...................................................................................... 19
2.3.1. La cadena de venta Wal-Mart ................................................................................ 19
2.3.2. El Departamento de Defensa de los EE.UU........................................................... 20
2.3.3. El Banco Central Europeo...................................................................................... 21
2.3.4. La “Web de las cosas” de SUN.............................................................................. 22
2.3.5. Otras iniciativas...................................................................................................... 27
3. Elementos de nivel físico ..................................................................................................... 29
3.1. Etiquetas RFID.............................................................................................................. 29
3.2. Muestra de mercado de etiquetas RFID ........................................................................ 33
3.3. Lectores RFID ............................................................................................................... 35
3.4. Muestra de mercado de lectores RFID.......................................................................... 39
4. Arquitectura de estandarización de identificación RFID ..................................................... 46
4.1. Escenario de referencia Auto-ID................................................................................... 46
4.2. Arquitectura de referencia Auto-ID .............................................................................. 48
5. Códigos EPC ........................................................................................................................ 52
5.1. Elementos generales del código EPC............................................................................ 52
5.2. Elementos del código EPC............................................................................................ 53
5.3. Actualizaciones a la norma ........................................................................................... 55
6. Arquitectura de los lectores (Reader)................................................................................... 57
6.1. Estructura general del nivel de lector (Reader)............................................................. 57
6.2. Visión operativa de la capa de lectura........................................................................... 60
6.3. Subsistemas de la capa de lectura (Readers)................................................................. 61
7. Arquitectura de Savant ......................................................................................................... 64
7.1. Módulos de proceso estándar de Savant ....................................................................... 67
7.1.1. MPE autoid.core..................................................................................................... 67
7.1.2. MPE autoid.readerproxy ........................................................................................ 70
7.2. Implementación de referencia de Savant Auto-ID........................................................ 72
7.2.1. Sistema de gestión de eventos (EMS) .................................................................... 74
7.2.2. Base de datos en memoria de eventos en tiempo real (RIED) ............................... 76
7.2.3. Sistema de gestión de tareas (TMS)....................................................................... 80
8. Object Name Server (ONS).................................................................................................. 82
8.1. Arquitectura del ONS.................................................................................................... 82
8.2. Operación del ONS ....................................................................................................... 84
9. Servidor de información EPC y Physical Mark-up Language (PML) ................................. 88
10. Evaluación de la tecnología................................................................................................ 93
10.1. Coste............................................................................................................................ 93
10.2. Escalabilidad y rendimiento ........................................................................................ 94
10.3. Viabilidad del uso........................................................................................................ 95
10.4. Privacidad y propiedad de la información................................................................... 96
10.5. Riesgos para la salud ................................................................................................... 97
3
Análisis de servicios de identificación-localización basados en RFID
10.6. Evolución previsible de la tecnología ......................................................................... 98
11. Conclusiones .................................................................................................................... 100
12. Bibliografía....................................................................................................................... 104
Apéndice 1: Un prototipo de Savant ...................................................................................... 107
Apéndice 2: Diseño detallado del prototipo de Savant .......................................................... 111
Package reader.................................................................................................................... 112
Package reader.autoid......................................................................................................... 116
Package reader.ess.............................................................................................................. 124
Package reader.mtb ............................................................................................................ 132
Package reader.rss .............................................................................................................. 137
4
Análisis de servicios de identificación-localización basados en RFID
1. Enfoque del trabajo
En Julio de 2003, el grupo de trabajo que ha llevado a cabo esta investigación, presentó una
propuesta de trabajo de prospección a la Cátedra AMENA en la Escuela Técnica Superior de
Ingenieros de Telecomunicación de la Universidad Politécnica de Madrid. Dicha propuesta de
trabajo fue aceptada y se ha ejecutado en los plazos previstos. El resultado de la investigación
se refleja en este documento.
Nuestro interés en el tema de investigación propuesto “servicios de identificación y
localización basados en RFID” comienza en la primera mitad del año 2003, cuando tenemos
noticia de que existe una tecnología radio de coste relativamente reducido, sobre la cual es
posible plantear el desarrollo de servicios de localización en interiores. Tras un primer análisis
de las posibilidades de esta tecnología, estimamos que mientras que el desarrollo tecnológico
de la parte radio va a continuar en el futuro cercano, abaratando las antenas, es preciso dotar a
los usuarios de mecanismos de obtención de datos e integración de éstos en el sistema de
información general, ya sea de la empresa, privado-doméstico, o de cualquier otra condición.
Durante la realización del estudio cuyos resultados ahora presentamos, el interés por esta
tecnología y sus posibles aplicaciones ha aumentado grandemente. No se trata, como se verá
en el estudio, de una tecnología de laboratorio (existen multitud de productos comerciales),
sino que el problema de su despliegue masivo topa con dificultades de gestión y de modelo de
negocio. Se trata, en fin, de un problema típico de los abordados por la Ingeniería Telemática
en el que la tecnología básica cede protagonismo a las dificultades de gestión, integración,
despliegue y mantenimiento de los sistemas, considerados éstos como un conjunto agregado
de elementos hardware, software, datos estandarizados, bases de datos, protocolos de
diferentes niveles… en suma, que la dificultad mayor que debe abordarse en este dominio de
actividad es el de encontrar una arquitectura del sistema capaz de satisfacer las demandas de
un gran número de potenciales usuarios, integrando los aspectos tecnológicos con los
operativos, e incluso –como se observará a lo largo del presente estudio- los legales.
El estudio está dividido en varias secciones, como se expone a continuación:
5
Análisis de servicios de identificación-localización basados en RFID
1. descripción de la historia previa de los sistemas de identificación automática, y actores
fundamentales del dominio;
2. análisis de mercado de terminales;
3. previsiones de implantación en casos de estudio de dominios específicos;
4. descripción de los estándares de arquitectura de los sistemas de identificación
(fundamentalmente los emitidos por la entidad Auto-ID);
5. análisis arquitectónico con respecto a diferentes características de calidad;
6. descripción de un prototipo de sistema de recogida de datos RFID.
En la elaboración del presente estudio han participado el responsable (Juan C. Dueñas), cuatro
estudiantes de doctorado del Departamento de Ingeniería de Sistemas Telemáticos (Pablo
Pancardo, José L. Arciniegas, José L. Ruiz, Rodrigo Cerón), y un estudiante de proyecto fin
de carrera del mismo departamento (José Vicente Espinosa).
6
Análisis de servicios de identificación-localización basados en RFID
2. Introducción a la tecnología RFID y la identificación
La identificación automática, o Auto-ID en inglés, es el término dado a un conjunto de
tecnologías que se usan para ayudar a las máquinas a identificar objetos. Muy a menudo,
auto-identificación y captura automática de datos se utilizan como sinónimos. Esto es, las
empresas que quieren identificar artículos, capturan la información acerca de los mismos sin
tener personal que realice la introducción de los datos en los ordenadores. Así, el objetivo de
la mayoría de los sistemas Auto-ID es incrementar la eficiencia, reducir los errores de entrada
de datos y liberar al personal para que éste se ocupe de funciones de mayor valor agregado.
Hay un conjunto de tecnologías que caen dentro del ámbito de Auto-ID: códigos de barras,
tarjetas inteligentes, reconocimiento de voz, algunas tecnologías biométricas (por ejemplo,
muestreo de la retina), reconocimiento de caracteres ópticos, identificación por radio
frecuencia (RFID) y otras.
RFID es un término genérico para las tecnologías que usan ondas de radio para identificar de
forma automática artículos individuales. Hay varios métodos para la identificación de objetos
utilizando RFID, pero el más común es almacenar un número de serie que identifica un
producto, y tal vez otros datos, en un microchip con una antena (el conjunto formado por el
chip y la antena se llama “transponder” RFID o etiqueta RFID). La antena habilita al chip
para transmitir la información de identificación a un lector. El lector convierte las ondas de
radio devueltas por la etiqueta RFID a una forma que pueda ser utilizada por un ordenador o
una red de ellos a los que se conecta el lector.
Los códigos de barra han sido los elementos predominantes para la identificación de
productos durante los últimos 25 años. Durante este tiempo, estos han servido muy bien a su
propósito, pero tienen una gran limitación: el escáner y la etiqueta deben de poder tener visión
directa. Esto es, un escáner tiene que “ver” el código de barra para leerlo, lo cual implica que
las personas normalmente tienen que orientar el código de barras hacia un escáner para que
éste lo pueda leer.
La identificación por radio frecuencia, por contraste, no requiere de visión directa. Las
etiquetas RFID puedan ser leídas mientras se encuentren dentro del rango de un lector. Los
7
Análisis de servicios de identificación-localización basados en RFID
códigos de barra tienen otra desventaja: si una etiqueta se rompe, ensucia, borra o desprende
no hay manera de identificar el artículo. Además, un código de barras estándar identifica
sólamente al fabricante y el tipo de producto. El código de barras en un cartón de leche es el
mismo que cualquier otro de las mismas características, haciéndose imposible identificar, por
ejemplo, cual de ellos podría alcanzar su fecha de caducidad primero. Con etiquetas RFID
suficientemente baratas, será posible identificar cada producto individualmente, con una
mejora del control sobre éstos.
La existencia de una tecnología barata, capaz de identificar cada producto de forma individual
y sin necesidad de visión directa, permitiría una mejora sustancial de la gestión de los
productos. La conexión de dicha tecnología a redes de datos proporcionaría el potencial de dar
a las empresas una visibilidad muy cercana y perfecta a la cadena de valor. Esto es, las
organizaciones serán capaces de conocer de modo exacto donde se encuentra en cada
momento en el tiempo un artículo en sus cadenas de valor.
En una situación para la industrial mundial en la que la globalización y virtualización son
necesarias y cada vez más reales, se cree que la habilidad de poder dar seguimiento individual
a los artículos cuando estos se muevan desde las fábricas hasta las tiendas hará a las empresas
más eficientes. Las empresas, de hecho, se han dado cuenta que capturar los datos acerca de
sus bienes de forma automática y exacta podría ser una gran mejora en su negocio.
Muchas empresas se encuentran ya invirtiendo en sistemas RFID para obtener las ventajas
que estos ofrecen. Estas inversiones se aplican normalmente en sistemas de ciclo cerrado –
esto es, una empresa da seguimiento a sus bienes de los cuales nunca pierde el control. De
esta forma, no hay posibilidad de que éstas sean leídas por otra empresa. Pero la mayoría de
las empresas no tiene sistemas de ciclo cerrado. Puesto que la mayoría de la tecnología RFID
desarrollada hasta mediados de los años 90 del siglo pasado es propietaria (no hay
estándares), si una empresa A etiqueta un producto y lo envía a la empresa B, la empresa B no
puede identificar el producto a menos que haya invertido en la misma tecnología
proporcionada por el mismo proveedor que se la suministró a la empresa A.
8
Análisis de servicios de identificación-localización basados en RFID
Respecto a la idea de que las etiquetas RFID puedan tratarse como terminales de las redes de
datos (Internet), hay que indicar que la mayor necesidad en este sentido es desarrollar un
conjunto ampliamente aceptado de estándares sobre los protocolos, tipos de datos e
integración de sistemas para que todos los sitios con capacidad de identificación y
localización RFID puedan integrarse a las redes. Existen iniciativas recientes en este sentido
que llaman a esta idea “la Internet de las cosas”. La gran disparidad de aplicaciones (y de
tipos de cosas que identificar), a la vez que los intereses de los diferentes fabricantes de
equipamiento en este ámbito, sin embargo, pueden suponer una barrera para la creación de
esta red de cosas; frente a ello, el uso de estándares abiertos (e incluso de implementaciones
abiertas) puede suponer una garantía de que el proceso de despliegue se realiza de forma
consensuada, sin actores dominantes. Por otra parte, también hay que reseñar otro de los
problemas de la “Internet de las cosas”, cada vez más real: la existencia de etiquetas RFID,
más una infraestructura de red capaz de identificar y localizar éstas, sin control de la
privacidad y la información que se genera, puede convertir en realidad –una vez más- la idea
del “Gran Hermano”. No se trata de una presunción baladí: múltiples organizaciones de
usuarios y defensores de los derechos civiles en EE.UU. se han agrupado y enviado cartas al
Congreso y Senado pidiendo la ilegalización de esta tecnología por el riesgo que supone para
la privacidad individual (empresas como Benetton que inicialmente desplegaron etiquetas
RFID en sus tiendas, tuvieron que retirarlas ante la presión del público; esta situación data de
noviembre de 2003).
Otro gran problema de la implantación de este tipo de sistemas es el coste. Los lectores RFID
típicamente cuestan 1000$1 o más. Las empresas necesitarían miles de lectores para cubrir
todas sus fábricas, bodegas y tiendas. Los lectores de modo común operan en una frecuencia
de radio, si las etiquetas de tres productores diferentes usan tres diferentes frecuencias, una
tienda puede tener que contar con tres diferentes lectores en la misma localización,
incrementándose el coste. Las etiquetas RFID también son un tanto caras – 50 centavos de
dólar o más – lo cual las hace imprácticas para identificar millones de artículos que cuestan
sólo unos pocos dólares. En virtud de lo anterior, uno de los objetivos para que esta tecnología
sea ampliamente aceptada es que los costes en etiquetado disminuyan drásticamente. Otra no
1
Utilizaremos indistintamente precios en Euros y dólares americanos en el estudio.
9
Análisis de servicios de identificación-localización basados en RFID
menos importante es el establecimiento de estándares que permitan que los lectores y
etiquetas de distintos fabricantes puedan ser compatibles entre sí.
10
Análisis de servicios de identificación-localización basados en RFID
2.1. La historia de los sistemas RFID
En la historia de los sistemas de identificación-localización basados en RFID (Identificación
por radio-frecuencia) se pueden diferenciar siete etapas que dan lugar a la actual:
1. Invención de RFID (1940 – 1950). Durante la segunda guerra mundial, se inventan,
usan y refinan los sistemas de radar. Se atribuye la invención de este tipo de sistemas
(o al menos su exploración inicial) a Harry Stockman, que publica el artículo
"Communication by Means of Reflected Power", Proceedings of the IRE, pp11961204, Octubre de 1948. En dicho artículo, se establece que "…evidentemente, se
tienen que efectuar trabajos de investigación y desarrollo considerables antes de que
los problemas básicos relacionados con la comunicación por poder reflectante se
puedan resolver, y antes de que pueda explorarse el campo de las aplicaciones útiles."
2. Primeras exploraciones y experimentos sobre RFID (1950-1960). Los años 50 fueron
una era de exploración de las técnicas RFID siguiendo los desarrollos técnicos en
radio y radar de los años 30 y 40. Se exploraron varias tecnologías relacionadas con
RFID como, por ejemplo, los sistemas de “transponder” (transmition/responder) de
rango amplio para “identificación, amigo o enemigo” de aviones. Los desarrollos de
los años 50’s incluyen trabajos tales como "Application of the microwave homodyne"
de F. L. Vernon y "Radio transmission systems with modulatable passive responder"
de D.B. Harris. En dichos trabajos se establecen las bases para el desarrollo básico de
la tecnología radio de RFID.
3. Desarrollo de la teoría y primeras pruebas de aplicaciones (1960-1970). Los años 60
fueron el preludio de la explosión de RFID en los 70. R. F. Harrington estudió la
teoría electromagnética relativa a RFID en sus artículos "Field measurements using
active scatterers" y "Theory of loaded scatterers" en 1963-1964. Se realizaron notables
trabajos de investigación como por ejemplo el artículo "Remotely activated radio
frequency powered devices" de Robert Richardson en 1963, Otto Rittenback con
"Communication by radar beams" en 1969, J. H. Vogelman con "Passive data
transmission techniques utilizing radar beams" en 1968 y J. P. Vinding con
"Interrogator-responder identification system" en 1967. Comienzan igualmente las
actividades comerciales, que se suelen significar con la fundación de las empresas
“Sensormatic” y “Checkpoint”, a finales de los años 60s. Estas compañías junto con
11
Análisis de servicios de identificación-localización basados en RFID
otras como Knogo, desarrollaron equipos para vigilancia electrónica de artículos
(EAS, por sus siglas en inglés) frente a robos. Estos sistemas se usan con etiquetas de
“1-bit” –sólo se puede detectar la presencia o ausencia de una etiqueta, aunque la
fabricación de estas etiquetas es muy barata y proporcionan medidas antirrobo muy
efectivas; la tecnología radio es de microondas o inductiva. La vigilancia electrónica
de artículos sigue siendo el dominio de aplicación más importante en el que se puede
aplicar la tecnología RFID actual.
4. Explosión del desarrollo de RFID (1970-1980). En los años setenta del siglo pasado, y
con la teoría básica ya creada y los primeros éxitos en las aplicaciones, surgen nuevas
implementaciones, pruebas, compañías, instituciones académicas y laboratorios de
investigación pública que elaboran activamente la parte tecnológica de RFID y que
realizan avances notables. Por ejemplo, Los Alamos Scientific Laboratory de la
Northwestern University y la Microwave Institute Foundation en Suecia entre otros.
Un desarrollo importante y pionero fue el trabajo en Los Alamos que fue presentado
por Alfred Koelle, Steven Depp y Robert Freyman, titulado: "Short-range radiotelemetry for electronic identification using modulated backscatter" en 1975. Las
grandes empresas estaban desarrollando también la tecnología RFID, tal como
"Raytag" de Raytheon en 1973. RCA y Fairchild desarrollaron varios prototipos junto
con Richard Klensch de RCA para el desarrollo de un "Sistema de Identificación
Electrónica" en 1975 y F. Sterzer de RCA con el desarrollo de "Electronic license
plate for motor vehicles" en 1977. Thomas Meyers y Ashley Leigh de Fairchild
desarrollaron también un "Passive encoding microwave transponder" en 1978. La
autoridad del puerto de New York y New Jersey estuvo evaluando sistemas
construidos por General Electric, Westinghouse, Philips y Glenayre. Los resultados
fueron favorables, pero el primer éxito comercial de una aplicación RFID, el cobro de
peaje electrónico, no estaba listo para esos primeros tiempos. Los años setenta
estuvieron caracterizados principalmente por trabajos de desarrollo. Las aplicaciones
que se intentaron fueron el rastreo de animales, rastreo de vehículos y automatización
de la fabricación. Los sistemas de microondas en Los Alamos y los sistemas
inductivos en Europa son ejemplos de esfuerzos de etiquetas para animales. El interés
del etiquetado de animales era alto en Europa. Alfa Laval, Nedap y otras empresas
también desarrollaron sistemas RFID. Los esfuerzos en el área del Transporte incluyen
12
Análisis de servicios de identificación-localización basados en RFID
los trabajos en Los Alamos, la International Bridge Turnpike and Tunnel Association
(IBTTA) y la the United States Federal Highway Administration.
5. Las primeras aplicaciones comerciales RFID (1980-1990). Los años ochenta llegaron
a ser la década de la implementación total de la tecnología RFID, aunque el interés de
desarrollo era diferente en varias partes del mundo. Los intereses más grandes en los
Estados Unidos eran el transporte, acceso del personal y aunque no muy extendido, el
de los animales. En Europa, los intereses más importantes eran sistemas de corto
alcance para animales, aplicaciones industriales y de negocios, y de hecho, en Italia,
Francia, España, Portugal y Noruega algunas autopistas de peaje fueron equipadas con
RFID. Las evaluaciones de RFID para cobro de peaje estuvieron presentes por muchos
años y la primera aplicación comercial se inició en Europa en 1987, en Noruega y fue
seguido rápidamente en los Estados Unidos por el Dallas North Turnpike en 1989.
También durante este tiempo, las autoridades del puerto de Nueva York y New Jersey
iniciaron la operación comercial de RFID para autobuses que se movían a través del
Tunel Lincoln. RFID estaba encontrando cabida con el cobro de peaje electrónico y
tenía nuevos seguidores cada día.
6. Estándares y despliegue masivo (1990-2000). Los noventa fueron una década
significativa para RFID puesto que se observó un amplio despliegue del cobro de
peaje electrónico en los Estados Unidos, a la vez que la integración de las
innovaciones en pago electrónico. La primera autopista en el mundo con sistema de
cobro electrónico fue abierta en Oklahoma en 1991, donde los vehículos podían pasar
por los puntos de cobro de peaje a altas velocidades sin impedimentos de plazas o
barreras y con vídeo cámaras como refuerzo de seguridad. El primer sistema de
gestión de tráfico y cobro de peaje combinados en el mundo fue instalado en el área de
Houston por las autoridades del condado de Harris en 1992. También se instaló un
primer sistema en la autopista de Kansas usando un sistema basado en el estándar
Título 21 con lectores que podían operar también con las etiquetas de sus vecinos del
sur, Oklahoma. El Georgia 400 seguiría actualizando sus equipos con lectores que
pudiesen comunicarse con las nuevas etiquetas Título 21 así como con las etiquetas
existentes. De hecho, estas dos instalaciones fueron las primeras en implementar una
capacidad de multiprotocolo en las aplicaciones de cobro de peaje electrónico. En
1990 en el noreste de los Estados Unidos, siete agencias de peaje regional formaron el
13
Análisis de servicios de identificación-localización basados en RFID
Grupo de Interagencias de Paso E-Z para desarrollar un sistema de cobro de peaje
electrónico regional. Este sistema es el modelo para usar una sola etiqueta y una sola
cuenta de pago por vehículo para acceder a varias autopistas con diferentes
autoridades. También existió gran interés por las aplicaciones RFID en Europa durante
los años 90. Tanto la tecnología inductiva como la de microondas se estudiaron para
usarlas en el cobro de peaje, control de acceso y una amplia variedad de aplicaciones
para comercio. Un esfuerzo nuevo fue el desarrollo del sistema TIRIS por Texas
Instruments, usado en muchos automóviles para el control del encendido del motor del
vehículo. El sistema Tiris (y otros de Mikron, ahora parte de Philips) desarrollaron
nuevas aplicaciones para repostar gasolina, chips de juegos, pases de esquí, accesos de
vehículos, etc. Adicionalmente, las empresas en Europa llegaron a participar de forma
activa en la carrera de RFID con desarrollos, algunas de éstas son Microdesign, CGA,
Alcatel, Bosch y Philips. Era necesario un estándar europeo para las aplicaciones de
cobro y muchas de estas y otras empresas estuvieron trabajando en el estándar CEN
para pago electrónico. Las aplicaciones de pago fueron apareciendo también en
muchos países como Australia, China, Hong Kong, Filipinas, Argentina, Brasil,
México, Canadá, Japón, Malasia, Singapur, Tailandia, Corea del Sur y Sudáfrica. Con
el éxito del cobro de peaje electrónico otros avances siguieron como es el uso de
etiquetas a través de diferentes segmentos del negocio. Ahora, una sola etiqueta podría
ser usada para pago de peaje electrónico, acceso a un parking, acceso a un campus,
etc.
7. La integración de sistemas RFID con las redes (actualidad). La investigación y el
desarrollo no se detuvo durante los 90’s puesto que nuevos desarrollos tecnológicos
expandieron la funcionalidad de RFID. En un primer tiempo, se fabricaron diodos
Schottky para microondas sobre un circuito integrado CMOS regular. Este desarrollo
permitió la construcción de etiquetas RFID de microondas que contienen sólamente un
circuito simple integrado, una capacidad antes limitada a los “transponders” RFID
acoplados inductivamente. Las empresas participantes en esta actividad fueron IBM
(la tecnología fue adquirida después por Intermec), Micron y Single Chip Systems
(SCS). Con el crecimiento del interés en RFID para la gestión de los artículos y la
oportunidad de RFID de trabajar junto con el código de barras, es difícil determinar el
número de empresas que se encuentran interesadas, aunque es grande. En España, y
14
Análisis de servicios de identificación-localización basados en RFID
con información obtenida de contactos informales, la empresa El Corte Inglés parece
haber desarrollado un sistema RFID, aunque desconocemos el alcance de sus
implantaciones (el sistema de vigilancia de 1 bit está implantado hace muchos años en
el comercio de gran superficie). Se esperan multitud de innovaciones en la aplicación
de RFID, con un impacto en el mundo de la empresa que se estima muy alto y con la
integración de las facilidades de identificación y localización con la “inteligencia
ambiental” o “inteligencia ubicua”, o la “red de las cosas” (todos estos términos
forman parte de descripciones de proyectos de innovación en marcha), en todos los
ámbitos de la vida social y productiva. Recientemente, la Comisión Federal de
Comunicaciones ha asignado el espectro de banda de los 5.9 GHz propuesta para la
expansión de los sistemas de transportación inteligentes con muchas aplicaciones y
servicios nuevos. El equipamiento requerido para colocar estas aplicaciones y
servicios nuevos necesitará más avances en RFID y en la integración de la
información que se obtenga de éste tipo de sistemas.
15
Análisis de servicios de identificación-localización basados en RFID
2.2. Actores en la estandarización de RFID
En 1998, David Brock y Sanjay Sarma del MIT (Massachusetts Institute of Technology)
propusieron un desarrollo de un sistema para la identificación automática de objetos capaz de
ser aplicable en la cadena de valor empresarial. En ese momento, la tecnología RFID era
relativamente cara, por lo que no había penetrado en el flujo de aplicaciones en masa. Brock,
Sarma y varios otros colegas del MIT, incluyendo a Sunny Siu, Daniel Engels, Joe Foley y
Eric Nygren se dieron cuenta que la clave para reducir el coste de RFID era reducir la
funcionalidad en el chip. Por ese motivo, propusieron varios pasos para solucionar este
problema:
1. Un esquema de numeración automática que actuara como un puntero a los datos en la
red,
2. una estrategia para acondicionar la red para almacenar y transportar grandes
cantidades de datos, y
3. la idea de que, a chips más pequeños, el coste de fabricación podría reducirse lo
suficiente.
Ellos también reconocieron de modo temprano que los estándares abiertos, con piezas
significativas de código abierto serían muy importantes para la aceptación de la solución
propuesta. En 1999, Brock y Sarma se reunieron con Kevin Ashton, entonces en
Procter&Gamble, que había desarrollado estrategias para colocar chips inteligentes en todos
los productos. Ashton había llegado a varias conclusiones importantes –incluyendo el hecho
de que si las etiquetas eran lo suficientemente baratas, estas llegarían a revolucionar la gestión
del almacenaje y las operaciones de la cadena de distribución. Pudo darse cuenta de que las
ideas propuestas por el equipo del MIT, combinadas con otras ideas tecnológicas en marcha y
las actividades de estandarización, llevarían al objetivo de reducir los costes hasta el nivel de
etiquetado de artículos. Entonces, Brock, Sarma y Ashton propusieron esta idea a Al
Haberman, miembro de la directiva del Uniform Code Council (UCC), ampliamente
considerado como el padre del código de barras. Haberman, con el respaldo de la directiva del
UCC, había estado buscando una universidad se interesara en un programa de investigación
para llevar al consejo a nuevas tecnologías de identificación para mejorar los 25 años de
16
Análisis de servicios de identificación-localización basados en RFID
existencia del código de barras. Haberman vió entonces el potencial de la idea, y junto con
Sarma crearon el marco para un nuevo centro en el MIT: el Auto-ID Center.
El 1 de octubre de 1999 el Auto-ID Center inició oficialmente su existencia en el
Departamento de Ingeniería Mecánica del MIT. El Centro fue presentado en sociedad la
noche previa a la celebración del 25º aniversario del Uniform Code Council. Tres entidades,
junto con el MIT, contribuyeron a la fundación inicial del Centro: el Uniform Code Council
junto con EAN (su contraparte internacional), la compañía Guillette y Procter&Gamble. El
jefe del Departamento de Ingeniería Mecánica del MIT, Nam Suh, también reconoció la
importancia de la conexión del mundo físico y de red, y contribuyó con 100.000$ para el
establecimiento del Centro en su departamento en el MIT. El profesor Sunny Siu ejerció
como el primer Director de Investigación. Kevin Ashton se unió como Director Ejecutivo.
Alan Haberman fue elegido como Presidente del comité de jefes.
En el año 2000, Sanjay Sarma llegó a ser el Director de Investigación. Más tarde, durante ese
año, los patrocinadores del centro reconocieron que con el exitoso crecimiento de la
organización, era necesario expandir tanto el alcance tecnológico como la diversidad
geográfica de las actividades del Centro. Entonces, el Centro evolucionó de su situación
centralizada en el MIT a una entidad de cobertura mundial con oficina central en el MIT. Ese
año, se abrió un Auto-ID Center en la Universidad de Cambridge en Inglaterra con Duncan
McFarlane como Director de Investigación. Más tarde en 2001, Richard Cantwell de Gillette
tomó el control como Presidente del Comité. A principios de 2002, se abrió un Auto-ID
Center en la Universidad de Adelaide en Australia, con el profesor Peter Cole como Director
de Investigación. Dirk Heyman de Sun se hizo cargo de la presidencia del comité de
tecnología. Más tarde, en 2002, se abrió un Centro en la Universidad de St. Gallen en Suiza,
con el profesor Elgar Fleisch a la cabeza. En 2003, se abrieron centros en la Universidad de
Keio, Japón y la Universidad Fudan en Shanghai con los profesores Jun Murai y Hao Min
como directores de investigación, respectivamente.
Para 2003, el Centro tenía más de 100 patrocinadores de los cuatro continentes. Los
investigadores del Centro y de las empresas patrocinadoras obtienen logros significativos. Se
han implementado y demostrado importantes componentes de software, incluyendo el ONS
17
Análisis de servicios de identificación-localización basados en RFID
(Object Name Server) y el Savant (un concepto desarrollado por Jim Waldrop en su tesis con
Sarma). Los comités en el Centro han desarrollado protocolos RFID ligeros para UHF y HF,
así como estándares para el software. Se han establecido alianzas y tecnologías para manejar
pequeños IC’s y se han entregado paquetes de bajo coste. Se proponen nuevas metodologías
de diagnóstico y control. Se llevan a cabo estudios para asegurar el impacto de estas
tecnologías en la cadena de valor, y se realizan gran cantidad de pruebas, en las que llegan a
participar 40 empresas distribuidas en 10 ciudades del mundo (fundamentalmente en los
Estados Unidos).
El Centro oficialmente cerró, tal como se había planificado, el 26 de octubre de 2003 con su
reunión directiva final en Tokio, Japón. En dicha reunión se hizo público el anuncio de que el
Auto-ID Center había completado sus trabajos y que transfería toda su tecnología al EPC
global, asimismo el Auto-ID Center se convertía en laboratorios de Universidad y pasaba a
formar los Auto-ID Labs. El anuncio de prensa oficial cita:
The Auto-ID Center officially closed on October 26th, 2003. The final board meeting was
held in Tokyo, Japan. The Center has completed its work and transferred its technology to
EPC Global (www.epcglobalinc.org), which will administer and develop EPC standards
going forward. The university labs of the former Auto-ID Center will now be referred to as
Auto-ID Labs (www.autoidlabs.org). Professor Elgar Fleisch of the University of St. Gallen
and Professor Jun Murai of Keio University will co-chair the Research Council. Dr. Dan
Engels will take over as Director of the MIT Auto-ID Lab. The leadership of the other labs
will remain the same. Professor Sanjay Sarma has stepped aside as Chairman of Research.
Mr. Kevin Ashton's term as Executive Director of the Auto-ID Center also draws to a close.
"Kevin has been an extraordinary partner in this endeavor," Professor Sarma said. "We wish
him all the very best. It has been a long and tiring run for Kevin and me, but a very rewarding
one. It is time for new leadership."
EPC Global ha prometido continuar las investigaciones en el Auto-ID Center dentro de
nuevas facetas de la tecnología y las aplicaciones. Independientemente, hay gran interés tanto
por los proveedores de tecnologías y las empresas usuarias en patrocinar las investigaciones
en todas las áreas que avancen sus intereses individuales como en aquellas de la industria de
18
Análisis de servicios de identificación-localización basados en RFID
RFID. La meta de RFID a bajo coste está más cerca que nunca. Un grupo comprometido de
empresas patrocinadoras, tanto corporaciones usuarias finales como proveedores de
tecnología, se encuentran unidas para lograr este objetivo. Una nueva organización de
estándares, soportada por un amplio grupo de empresas y por investigadores dedicados en
todo el mundo, están llevando la visión EPC hacia esa idea.
EPC Global es una actividad conjunta de EAN International y el Uniform Code Council
(UCC). Es una organización no lucrativa avalada por la industria para establecer y dar soporte
a la Red EPC (Electronic Product Code) como el estándar global para la identificación
inmediata, automática y exacta de cualquier artículo en la cadena de valor de una empresa, en
cualquier industria y en cualquier parte del mundo. Su objetivo es dirigir la adopción global
de la red. EPC Global, toma la misión de trabajar con usuarios finales y proveedores de
hardware, software y soluciones integradoras para construir la infraestructura de la red EPC,
así como la implementación de soporte.
2.3. Despliegues de RFID en curso
Comentamos a continuación tres casos concretos de aplicación y despliegue de tecnología
RFID que están actualmente en curso (o en vías de serlo en breve). Existe gran cantidad de
material publicado sobre estos tres casos de aplicación aunque debido a su naturaleza de
despliegues exploratorios (de cuyo éxito dependerá la introducción de la tecnología) resulta
difícil separar la información de la propaganda.
2.3.1. La cadena de venta Wal-Mart
En la aplicación de tecnologías en la venta al detalle hay pocos distribuidores lo
suficientemente grandes como para forzar a parte de la industria a adoptar una nueva
tecnología en un período reducido de tiempo. Wal-Mart es uno de ellos, con cierta experiencia
en esta situación, porque en 1984 –tras estar disponible durante más de 10 años sin éxito–
obligó a sus proveedores a usar códigos de barras en el etiquetado de productos; tres años más
tarde prácticamente todos cumplían el requisito. Esta cadena de distribución ha establecido la
fecha de Enero de 2005 como límite para que sus 100 mayores proveedores comiencen a usar
las etiquetas RFID en cajas y “pallets”, y el año 2008 para completar el proceso de adopción.
También han definido las acciones contra los suministradores que no cumplan con estas
19
Análisis de servicios de identificación-localización basados en RFID
expectativas: penalizaciones económicas al principio y rechazo a distribuir los productos en
una segunda instancia. Según sus gestores, con esta iniciativa pretenden disminuir costes,
prevenir los robos, liderar el desarrollo de la tecnología y dirigir la creación de una masa
crítica de usuarios.
En cualquier caso, se reconoce en esta iniciativa que la transformación o la adopción de la
tecnología es un proceso lento que sólo culminará después de años. La estimación que se
maneja en el sector es que, empezando de cero y para una empresa grande de
comercialización al detalle, la realización de proyectos piloto y el despliegue llevan al menos
dos años.
La secuencia de adopción de la tecnología comenzará con el uso de etiquetas RFID en
contenedores y pallets preparados para el almacenaje, conteniendo las etiquetas información
por categorías de productos. Las etiquetas deben de ser proporcionadas por los
suministradores de los productos y se leerán en los muelles de operación y distribución para, a
partir de ahí, realizar el seguimiento de los productos mientras se mantengan bajo el control
de la empresa de distribución.
La actitud de la mayoría de los actores en el dominio de la distribución es, todavía, de espera
y análisis de la tecnología; en general, se considera que la tecnología RFID es aún muy cara y
poco eficiente en términos de negocio (es necesario hacer compras de millones de tarjetas
como para que el coste por unidad sea competitivo). Una encuesta realizada por la firma de
consultoría BearingPoint a los distribuidores al detalle de los EE.UU. con ingresos superiores
a los 200 millones de dólares encontró que sólo el 23% consideraba el estudio e implantación
de RFID como una prioridad para 2004.
2.3.2. El Departamento de Defensa de los EE.UU.
Aunque la Armada de los EE.UU. ha usado etiquetas para identificación por RFID durante
una década, fue la guerra del Golfo la que impulsó la decisión del Departamento de Defensa
(DoD) para adoptar la tecnología a mayor escala. La fecha de adopción es también Enero de
2005. El año 2004 está dedicado a la realización de proyectos piloto para ayudar a cuantificar
los gastos de implantación y valorar sus beneficios.
20
Análisis de servicios de identificación-localización basados en RFID
Por ahora, el DoD ha realizado estudios internos para determinar cómo proceder con la
implementación de etiquetas RFID, y el próximo paso será ampliar los estudios con los
proveedores de la tecnología y los propios proveedores del Departamento para establecer
acuerdos y planear un calendario. Inicialmente se exigirá el etiquetado de contenedores
(“pallets”). Adicionalmente, los bienes valiosos recibirán etiquetas para la realización del
inventario físico.
El Departamento de la Defensa usará tanto etiquetas activas como pasivas. Las etiquetas
pasivas son a menudo alimentadas por micro-ondas de baja potencia; convierten la energía
transmitida en potencia y responden con una señal de radio.
Inicialmente, cada etiqueta activa costará cerca de 100$, aunque el DoD está trabajando con
sus proveedores en reducir los costes. Las etiquetas pasivas costarán a la agencia menos de
1$. Según un portavoz del Departamento: “Cuando se está dando seguimiento a vehículos en
movimiento o a contenedores de productos desde 100 metros de distancia, con pérdida de
datos en la etiqueta, el coste de la etiqueta activa es razonable para muchas aplicaciones. Las
etiquetas pasivas que se pueden leer de 2 a 10 metros de distancia con datos limitados en la
etiqueta, tienen una aplicación diferente y darán valor agregado por un dólar americano o
menos, e incluso existirán más aplicaciones cuando los costes disminuyan. El trabajo del DoD
es encontrar el equilibrio en una época de madurez y cambios constantes en la tecnología
RFID”.
Inicialmente las etiquetas activas se usarán para identificar los artículos más grandes o
valiosos, o en cargamentos compactos (contenedores oceánicos o “pallets” aéreos). La
implementación inicial de las etiquetas RFID pasivas será en contenedores de arsenal donde
las etiquetas facilitarán los procesos de distribución y tal vez proporcionen granularidad
adicional a nivel de visibilidad de los artículos en algunos casos.
2.3.3. El Banco Central Europeo
21
Análisis de servicios de identificación-localización basados en RFID
Existen informaciones que no hemos podido confirmar completamente acerca de las
conversaciones del Banco Central Europeo con la empresa Hitachi, cuyo objetivo sería la
implantación de etiquetas RFID de tamaño mínimo en los billetes de Euros.
El Banco Central Europeo intentaría de esta forma reducir las falsificaciones y el lavado de
dinero; las noticias mencionan la situación de las autoridades griegas, que en el año 2003
tuvieron que hacer frente a 2411 casos de falsificaciones y 4776 billetes falsificados, también
que las autoridades en Polonia capturaron a una banda sospechosa de elaborar más de un
millón de Euros falsos y ponerlos en circulación.
Con la adopción de la tecnología RFID en el papel moneda el principal objetivo es determinar
la autenticidad de la moneda y detener las falsificaciones. Las etiquetas RFID tienen también
la habilidad de registrar información como los detalles de las transacciones en que ha estado
involucrado el billete. Esto podría prevenir el lavado de dinero, dar seguimiento a
transacciones ilegales y prevenir que los secuestradores demanden billetes sin marcar.
Aparte de actuar como una marca de agua digital, el uso de RFID podría acelerar la rutina de
los procesos bancarios como los recuentos. Con tales etiquetas, se puede pasar una pila de
billetes a través de un lector y obtener la suma en menos de un segundo, de modo similar a
como se manipula el inventario con un sistema basado en RFID.
En un billete de euro, la antena RFID podría contener un código de serie, así como detalles
del lugar de origen y denominación. De acuerdo a Hitachi, los datos sólo podrían ser escritos
durante la producción, y no después durante la circulación. Se están haciendo pruebas
preliminares en el diseño de los billetes de admisión en la Exposición Internacional de Japón
con vistas al año 2005.
2.3.4. La “Web de las cosas” de SUN
La iniciativa que ha iniciado SUN Microsystems (gran empresa norteamericana del mundo
del equipamiento hardware, software y servicios) alrededor de la tecnología RFID, y que
demuestra el interés de los fabricantes e integradores por esta tecnología, parece estar basada
en la asimilación de los trabajos del Auto-ID Center, y posterior incorporación al inventario
22
Análisis de servicios de identificación-localización basados en RFID
de productos y servicios ofrecidos por la empresa. Recientemente ha abierto un pequeño
centro de investigación en Escocia, UK alrededor de RFID. La forma en la cual la empresa
presenta la tecnología merece especial atención, porque encuadran a RFID en un marco
conceptual complejo, a más largo plazo, y que continúa la “tradición” para esta empresa de
profundizar en la integración entre cómputo y comunicaciones. La siguiente figura muestra el
esquema tecnológico general en el que se encuadra la visión del tema por SUN.
Hay que entender que a este nivel de desarrollo de la tecnología, y ante la previsión de que
antes o después dará lugar a un gran segmento de negocio sobre el cual el primero de los
puntos de influencia tiene que ver con la velocidad de adopción, los canales de la empresa
para dar visibilidad de sus desarrollos e innovaciones no son los científicos, sino los canales
de difusión de ingeniería y de mercado. Por decirlo claramente: apenas hay trabajos
publicados en el circuito científico, pero hay multitud de presentaciones en ferias de negocios,
impartidas por “evangelistas” del tema.
Según estas presentaciones, las bases de la innovación en la “web de las cosas” (lema que
SUN da a esta iniciativa) son las leyes: de Moore, que indica que la potencia de cómputo se
duplica cada 18 meses; ley de Gilder, menos conocida que la anterior y que indica que la
capacidad de ancho de banda de red se duplica cada 12 meses2; y la ley de Metcalfe o efectored, que dice que el valor de la red se incrementa exponencialmente con el número de
2
En la participación de los autores de este informe en los foros de planificación de la investigación en Europa
(concretamente, en la revisión del “ITEA Roadmap” de la oficina ITEA/EUREKA) se comenta que la situación
actual en Europa puede no haber seguido esta ley en los últimos dos años.
23
Análisis de servicios de identificación-localización basados en RFID
integrantes-nodos. Fruto de este análisis es la previsión de evolución que se muestra en la
siguiente figura. Como se puede observar, indican la presencia futura de la tecnología que
permita integrar la “red de las cosas”, predicen su punto álgido para los años 2004/2007, pero
no proporcionan más información sobre si será necesario añadir tipos nuevos de protocolos,
tipos de directorios, mecanismos de sesión… en cualquier caso, y como veremos en breve
SUN parece haberse comprometido a utilizar y desarrollar los estándares de Auto-ID Center.
La iniciativa EPC de SUN tiene como características principales:
• Ir más allá de lectores y etiquetas para realizar la integración con los sistemas de
información corporativos.
• La arquitectura se diseña alrededor de los estándares de Auto-ID como EPC, la interfaz del
sistema Savant, Object Name Service (ONS) y PML.
• Ofrece soluciones de fiabilidad, disponibilidad, escalabilidad y manejabilidad.
• Proporciona una arquitectura abierta que permite la integración de soluciones de terceros.
• Ofrece servicios empaquetados incluyendo arquitectura, implementación, soporte y
formación.
La arquitectura que proponen, y que se encuentra basada en los trabajos del Auto-ID Center
es la que se muestra en la siguiente figura.
24
Análisis de servicios de identificación-localización basados en RFID
En la capa más baja se encuentra el lector que será responsable de leer los artículos
etiquetados que pueden estar situados fijos o en movimiento a través de un marco de una
puerta como un muelle de carga. Normalmente, el lector estará leyendo muchos artículos de
forma continua y enviando los datos al servidor Savant para su procesamiento. Típicamente la
capacidad efectiva (“throughput”) sería de 100 lecturas por segundo.
La próxima capa en la arquitectura es el servidor Savant, tal como viene definido por los
estándares Auto-ID, y basado en tecnología Java. El rol del servidor Savant es procesar
rápidamente todos los datos de las etiquetas que provienen de uno o más lectores. Éste
almacena en memoria las lecturas y, por medio de filtros, conserva las lecturas pertinentes.
Por ejemplo, en el caso de un lector de estantes, la mayoría de las lecturas son de artículos que
no se han movido. Puesto que el artículo habría sido almacenado en una base de datos
previamente, las lecturas redundantes necesitan ser eliminadas. Una vez filtrados se necesita
almacenar los datos de forma persistente para que puedan ser usados por otras capas de la
arquitectura.
Típicamente, una empresa tendrá numerosos servidores Savant ubicados dentro de su cadena
de valor para tener controlado el tráfico de los lectores. Una tienda típica tendrá numerosos
lectores en los distintos estantes. Dada la cantidad de tráfico de red de los lectores, es
importante determinar los datos teniendo los servidores Savant filtrando los datos de las
etiquetas en cada sitio en vez de estar enviando datos de etiquetas sobre la Internet. Por otra
parte, es una buena práctica aislar los lectores de Internet por razones de seguridad.
25
Análisis de servicios de identificación-localización basados en RFID
El Savant de SUN implementa una arquitectura de servicio federado que permite la carga
dinámica de componentes software durante la ejecución; es además un sistema escalable,
distribuido, flexible y tolerante a fallos. Si un lector u otro recurso de cómputo está
físicamente dañado o deshabilitado, el software Savant continuará trabajando mediante la
provisión dinámica y relocalización de cualquier servicio de software perteneciente al recurso
de cómputo deshabilitado hacia otro recurso de cómputo sobre la red. Esta funcionalidad es
llamada auto-reparación y la tecnología para ofrecer esta facilidad en el nivel de software
intermediario (“middleware”) y con propósito general forma parte del esfuerzo de
investigación europeo actual.
La tercera capa en la arquitectura es la capa de integración SUN Open Net Environment (SUN
ONE). Se propone usar tecnologías de integración para conectar la capa Savant con los
sistemas de información corporativos, como sistemas “legacy”, ERP (“Enterprise Resource
Planning”), gestión de la cadena de valor, gestión de las relaciones con el cliente, y otras
aplicaciones. En el soporte a estas piezas de la arquitectura, SUN introduce todo su arsenal de
tecnologías software (Java Message Service JMS, Java 2 Enterprise Edition J2EE, Java
Management Extensions JMX y muchas otras).
El traslado de los datos y la gestión de procesos de negocio son necesarios para que los
sistemas de información corporativos reciban la información en tiempo real de la cadena de
valor que está contenida en el Savant. Los sistemas de información corporativos se encuentran
en la cima de la arquitectura.
Como ya hemos comentado, esta empresa también ofrece paquetes de servicios, implantación,
consultoría, etc. Indican que el procedimiento que debería de seguirse para implementar la
tecnología RFID en una empresa son:
1. Crear un equipo multidisciplinar con alta dedicación a la implantación del sistema.
2. Definir los requisitos de negocio simples y medibles (mediante métricas si fuera
posible).
3. Determinar de forma cuidadosa los datos y procesos del negocio.
4. Seleccionar las empresas externas colaboradoras definiendo sus roles.
5. Definir la arquitectura de red y la integración del negocio.
26
Análisis de servicios de identificación-localización basados en RFID
6. Seleccionar del mercado los lectores y etiquetas más adecuados.
7. Realizar un prototipo y evaluarlo.
8. Efectuar la implementación real.
2.3.5. Otras iniciativas
Una vez presentadas las iniciativas que nos han parecido más relevantes, queremos aquí
reflejar algunos otros proyectos cuyos resultados o seguimiento pudieran ser de interés en una
eventual continuación del trabajo de análisis de la tecnología. Por una parte, mencionaremos
los proyectos IST del 5º programa marco (ya finalizados) que dieron cobertura a los temas
relacionados con RFID:
• FLEX-SI (Ultra-thin packaging solutions using thin silicon, IST-1999-10205). Este
proyecto trataba de desarrollar chips de silicio ultra finos (empaquetados en menos de 50
micras de grosor). Se evaluaron tres tecnologías: integración de varios chips con
componentes activos en sustratos flexibles para telecomunicaciones, chip-on-chip para
aparatos de ayuda a la audición, y chip sobre papel para identificación. La repercusión de
este proyecto sobre el escenario tecnológico tiene que ver con el abaratamiento de las
etiquetas RFID y su uso generalizado sobre diferentes productos.
• PALOMAR (Passive long distance multiple access high radio frequency identification
system, IST-1999-10339). Este proyecto ha desarrollado tecnología de fabricación de
tarjetas RFID pasivas y baratas, funcionando en la frecuencia 2,45 GHz para aplicaciones
de “larga distancia-4metros” con comunicación bidireccional, capacidades de lectura y
escritura y algoritmos eficientes anticolisión para poder leer hasta 100 tarjetas a la vez.
• LAUREL (Laundry application using RFID tags for enhance logistics, IST-2000-26199).
El objetivo del proyecto es el desarrollo de un sistema RFID con capacidad de multilectura sobre un conjunto de etiquetas de lectura-escritura muy pequeñas. Intenta mejorar
los niveles de coste/rendimiento, por medio de simulaciones en el diseño del sistema de
radiofrecuencia, predicción del rendimiento de lectura, comprobaciones de conformidad
con las regulaciones de radiofrecuencia, etc. La idea es producir una etiqueta
suficientemente barata como para poderse utilizar en productos muy baratos, como por
ejemplo los elementos que se mueven en el dominio de lavandería industrial.
• TRITON (Trial on intelligent tag on industrial environment, IST-1999-20814) ha
implementado un sistema de flujos de tarjetas en un entorno real de producción
27
Análisis de servicios de identificación-localización basados en RFID
(fabricación de productos de limpieza), incluyendo varios subsistemas, desde las etiquetas
hasta los protocolos.
• PARCELCALL (An open architecture for intelligent tracing solutions in transport and
logistics, IST-1999-10700). Este proyecto ha desarrollado una arquitectura abierta para el
seguimiento y trazado inteligente en el transporte y la logística, integrando desde los
sensores avanzados hasta la ingeniería de servicios y redes GPRS y UMTS. El resultado es
una plataforma genérica de servicio, capaz de adaptarse a otras áreas como la atención
hospitalaria, servicios de emergencia, etc. Los socios principales fueron los europeos
Siemens y Philips.
Por otra parte, también indicaremos que existen en la actualidad varias iniciativas en las
comunidades de código abierto. El grado de madurez y soporte en estos proyectos es muy
variable. En dos de ellos hemos encontrado código fuente para los elementos software del
sistema RFID:
• Java RFID Project, desarrollado por Chiara Oriani, Etnoteam S.p.A. Labs (Milano - Italy)
como proyecto de Universidad. El proyecto consiste en librerías y aplicaciones Java para la
comunicación con lectores RFID. El sistema ejecuta sobre Linux Suse 8.1.
• rfid library, de Loic Dachary, INRIA, que consiste en un conjunto de librerías C para
conexión con lectores RFID, bajo licencia GPL. Siendo unas bibliotecas amplias y
probadas, el objetivo para el que se han construido es el de proteger la privacidad de los
individuos.
28
Análisis de servicios de identificación-localización basados en RFID
3. Elementos de nivel físico
La tecnología RFID se basa en la obtención de datos a partir del nivel físico, y el
almacenamiento, filtrado y tratamiento de éstos en el nivel de aplicación. En esta sección se
describen brevemente los elementos del nivel físico necesarios para la recogida de datos.
Un sistema RFID básico está formado por tres componentes fundamentales:
• una antena,
• un transceptor (“transceiver”) con codificador capaz de excitar la antena; al
conjunto formado por ambos se le llama “lector”.
• un transponedor (“transponder”) programado electrónicamente con información
única, base para la identificación. Recibe el nombre común de “etiqueta de radio
frecuencia” o “etiqueta”. Obviamente, también contiene una antena.
3.1. Etiquetas RFID
Una etiqueta RFID está compuesta de un microchip asociado a una antena. La drástica
reducción en tamaño y potencia consumida distingue a estos sistemas de los sistemas radio
convencionales. A su vez, existen diferentes segmentos en tamaño, coste, potencia y función
cada uno de los cuales puede ser de mayor utilidad en un tipo distinto de aplicaciones. Es
importante recordar que sólo se podrá llegar a la identificación individual cuando el coste de
las etiquetas (una etiqueta por ítem) sea suficientemente reducido.
Las etiquetas RFID se encuentran en una amplia variedad de formas y tamaños. Por ejemplo,
las etiquetas para rastreo de animales insertadas en la piel pueden llegar a medir 0,2x0,8 mm.
También se construyen de forma que puedan insertarse en casi cualquier medio (madera,
cuerpo de animal, plástico de una tarjeta de crédito, etc). Las etiquetas pueden ser adaptadas
para identificar árboles o artículos de madera. Las etiquetas de alto rendimiento rectangulares
de 8x6x1 cm pueden usarse para seguir la traza de contenedores o maquinaria pesada,
camiones y vagones de tren.
Existen varios criterios de clasificación de las etiquetas, aunque como veremos más adelante
no son clasificaciones perfectas y ortogonales:
• con respecto a su gestión de la energía: activas / pasivas,
29
Análisis de servicios de identificación-localización basados en RFID
• con respecto a las capacidades de comunicación: inductivas / back-scatter (de
reflejo) / bidireccionales,
• con respecto a la capacidad de almacenamiento: lectura-escritura / sólo lectura.
Con respecto a la gestión de la energía:
• Las etiquetas activas tienen una batería interna, que se usa para alimentar los
circuitos del microchip y enviar una señal al lector. La batería suele estar
integrada en el propio paquete de la etiqueta (no se puede extraer y sustituir) por
lo que la vida de la batería determina la vida útil de la etiqueta (10 años en el
mejor de los casos). Proporcionan funcionalidades de “gama alta”: lecturaescritura, gran capacidad de almacenamiento (sobrepasando 1 Mega Byte),
distancia mayor de lectura con respecto al lector, bidireccionalidad de la
comunicación. Entre sus inconvenientes a la hora de elegirlas para una
aplicación concreta, mencionar su coste mayor, su tamaño también mayor.
• Las etiquetas pasivas no disponen de fuente interna de energía, lo que hace que
sean más baratas y su vida media no viene determinada por la de la batería; a
cambio poseen menores capacidades de comunicación y almacenamiento.
Convierten la energía del campo electromagnético del lector en corriente para
excitar la antena de la etiqueta mediante inducción. La capacidad de transmisión
y la distancia que alcanzan es, por tanto, mucho menor que en el caso de las
etiquetas activas. Sin embargo, el menor tamaño, abaratamiento y su tiempo de
vida ilimitado hace que se hayan convertido en la opción más adecuada para la
identificación y localización a gran escala.
• Existen también etiquetas semi-pasivas, que usan una batería para alimentar los
circuitos del chip, pero se comunican utilizando energía del lector.
Con respecto a la capacidad de almacenamiento de datos:
• Las etiquetas de sólo lectura: suele tratarse de etiquetas pasivas en las que
durante el proceso de fabricación de la propia etiqueta, se proporciona un
número (o identificador) único, que no se puede modificar. El rango de datos
con el que se trabaja en la actualidad va desde los 32 a los 128 bits. Las etiquetas
de sólo lectura en su mayoría operan como una clave en una base de datos, de la
30
Análisis de servicios de identificación-localización basados en RFID
misma manera que un código de barras actúa como clave de búsqueda sobre una
base de datos de productos. La asignación de identificadores se convierte en un
problema de numeración (en el sentido de redes de comunicación), en el que es
preciso establecer normas rigurosas y aceptadas por todos los agentes para que
no aparezcan duplicaciones de identificación, y se gestione eficazmente el
espacio de direcciones (identificadores). Este problema puede hacerse más grave
ante la aparición en el mercado de “impresoras de antenas”, capaces de crear
etiquetas pasivas con un equipamiento muy barato al alcance de cualquier
agente, que puede seguir un plan de numeración propio (o ningún plan). Otro
gran problema de la tecnología RFID, que se plantea desde el nivel físico, es el
de la privacidad. Si las etiquetas pasivas no llevan ningún sistema de inhibición,
estarían proporcionando información donde quiera que fueran, mientras hubiera
lectores compatibles. En la actualidad se está trabajando en dotar incluso a estas
tarjetas de medios de inhibición que permitan la destrucción del código o la
inhibición definitiva de la tarjeta una vez que sale fuera del ámbito
administrativo adecuado. El problema todavía no planteado, pero claramente
previsible, es que se inhiba la tarjeta fraudulentamente.
• Las etiquetas de lectura/escritura. Con los sistemas de lectura/escritura se puede
adicionar o sobrescribir información a la etiqueta cuando ésta se encuentra
dentro del rango del lector. Las etiquetas de lectura/escritura son útiles en
algunas aplicaciones especializadas, pero puesto que son más caras que las
etiquetas de sólo lectura, resultan poco prácticas para dar seguimiento a
productos baratos. Tienen un claro potencial de uso en aplicaciones complejas
en las que la propia etiqueta almacene información histórica. Este uso y tipo de
etiquetas ha derivado al dominio denominado “tarjeta inteligente” en el que se
han realizado investigaciones activas en los últimos años y ha dado paso a un
floreciente mercado de aplicaciones actualmente en despliegue (la tarjeta
asistencial o historial médico que algunas administraciones están implantando).
Con respecto a las capacidades de comunicación:
• Las etiquetas inductivas. Se “cargan” al pasar a través de un campo
electromagnético generado por el lector. La etiqueta resuena en la frecuencia del
31
Análisis de servicios de identificación-localización basados en RFID
campo causando una disrupción del campo. Normalmente se construyen de esta
forma para poder funcionar como etiquetas pasivas y por lo tanto, son etiquetas
de sólo lectura. Al no llevar batería ni procesador (o ser éste mínimo), su coste
es muy reducido. Las etiquetas inductivas de 1 bit (etiquetas de presencia) son
las que se encuentran habitualmente en los sistemas de vigilancia electrónica de
artículos (Electronic Article Surveillance, EAS) y pueden costar menos de un
céntimo de Euro por etiqueta, mientras que las de mayor capacidad pueden
llegar a costar 6 Euros. Los rangos de lectura típicos son menores de 3 metros.
Aún a pesar de sus limitaciones, se han descrito aplicaciones de estas etiquetas
en los ámbitos de: EAS, sistemas antirrobo, controles de acceso, identificación
personal, gestión de animales salvajes, identificación de mascotas, identificación
de productos, acceso y seguridad para vehículos. La siguiente figura muestra el
esquema de funcionamiento básico de las etiquetas inductivas.
• Las etiquetas de reflejo (back-scatter): estas etiquetas operan bajo el principio de
difusión, en el que el lector crea un campo electromagnético que es reflejado por
la etiqueta tras ser modulada o codificada su señal con una señal de reloj y la
información interna de la etiqueta. Pueden ser etiquetas activas o pasivas, y su
coste varía entre los 3 y los 30 Euros. Existen en el mercado etiquetas de reflejo
de lectura y escritura y de sólo lectura. Se han descrito aplicaciones de este tipo
de etiquetas en: cobros de peajes, sistemas de gestión de tráfico, gestión de
contenedores en puertos y estaciones, trazabilidad de productos, identificación
de automóviles y sistemas de control ferroviario, entre otros. La siguiente figura
representa el funcionamiento de la etiqueta de reflejo.
32
Análisis de servicios de identificación-localización basados en RFID
•
Las etiquetas bidireccionales. Son etiquetas con dos sentidos de comunicación,
activas y casi siempre con capacidades de lectura y escritura. Incorporan un
transmisor y/o receptor miniaturizado. La etiqueta puede ser interrogada o
transmitir libremente. Los datos pueden ser leídos o programados solamente por el
interrogador. El coste medio puede variar entre los 69 y los 140 Euros. Entre las
aplicaciones más relevantes en las que se han utilizado, se pueden mencionar:
cobros de peajes, control de procesos de fabricación, gestión de basuras, control de
productos de alto valor. La figura muestra el esquema de funcionamiento de este
tipo de etiquetas.
3.2. Muestra de mercado de etiquetas RFID
A continuación se incluye una muestra de mercado de etiquetas RFID, obtenida en un
mercado especializado en Internet para este tipo de productos (www.buyrfid.com). Se trata de
material ilustrativo con respecto a capacidades, costes. Suponemos que para un despliegue
masivo, el coste por unidad (0,7 $ en el primer caso, por ejemplo), podría reducirse
dirigiéndose al fabricante de forma directa.
33
Análisis de servicios de identificación-localización basados en RFID
Cant
100
Descripción
Alien Technology “D”
Tags. These adhesive
backed tags are ideal for
general purpose RFID
applications, sacrificing
read range for smaller tag
size than the "U" formfactor tags.
100
100
100
Custom conversion to
labels, badges, and other
forms available. Price
includes 100 inlays.
Discounts applied for
orders of 10,000 or more.
Alien Technology “I” tags.
These Alien Technology "I"
tags are adhesive backed,
and have excellent
performace for their size.
They are orientation
sensitive, and read best
when they can be aligned
properly during reading
(as in assembly line
applications).
Custom conversion to
labels, badges, and other
forms available. Price
includes 100 inlays.
Discounts applied for
orders of 10,000 or more.
Alien Technology
“Squiggle” tags. ALSQUIG.
Taking it's name from the
antenna shape, this EPC
Class 1 compliant
pressure-sensitiveadhesive tag is the perfect
size for many smaller
items. Measuring 3 7/8" by
1/2", they fit on nearly any
product packaging.
Alien Technology “U” tags.
ALIEN-UL. Alien
Technology Smart Labels
in 'U' form factor. Works
with Alien Technology,
Mercury 3, other ePC Class
1 compliant readers.
Custom conversion to
labels, badges, and other
forms available. Price
includes 100 inlays.
Discounts applied for
orders of 10,000 or more.
Especificaciones
•
•
•
•
•
•
•
•
•
•
•
Tag Type: ePC class 1 compliant
Operating frequency: 915 MHz (902-928 MHz)
Read Range: up to 4 meters
Simultaneous Identification of Tags: Up to 200
tags per second (reader/antenna dependent)
Tag Power: RF Beam Powered (Passive)
Tag to Reader Communication: Backscatter
Memory Capacity: 96 bits
Memory Type: Write Once, Read Many
Antenna Dimensions: 44x99mm
Orientation Sensitivity: Best of ePC Class 1
Tags.
Aplicaciones: Propósito general.
• Tag Type: ePC class 1 compliant
• Operating frequency: 915 MHz (902-928 MHz
Precio
US74.99
US74.99
)
• Read Range: up to 5 meters
• Simultaneous Identification of Tags: Up to 200
•
•
•
•
•
•
•
tags per second (reader/antenna dependent)
Tag Power: RF Beam Powered (Passive)
Tag to Reader Communication: Backscatter
Memory Capacity: 96 bits
Memory Type: Write Once, Read Many
Antenna Dimensions: 13x134mm
Orientation Sensitivity: Good
Applications: General Purpose
•
•
•
•
•
•
3 7/8" by 1/2"
EPC Class 1 compliant
Walmart mandate compliant
915 MHz operating frequency
Strong adhesive
Tamper evident
• Tag Type: ePC class 1 compliant
• Operating frequency: 915 MHz (902-928 MHz
)
• Read Range: up to 5 meters
• Simultaneous Identification of Tags: Up to 200
•
•
•
•
•
•
•
tags per second (reader/antenna dependent)
Tag Power: RF Beam Powered (Passive)
Tag to Reader Communication: Backscatter
Memory Capacity: 96 bits
Memory Type: Write Once, Read Many
Antenna Dimensions: 13x134mm
Orientation Sensitivity: Good
Applications: General Purpose
34
US74.99
US74.99
Análisis de servicios de identificación-localización basados en RFID
250
915 MHz Matrics adhesivebacked tags in 2"x2" form
factor. Works with Matrics
reader.
Price includes 250 tags.
Discounts applied for
orders of 10,000 or more.
•
•
•
•
•
•
•
•
•
•
•
•
250
915 MHz Matrics smart
labels in 4"x4" form factor
an be attached to
products, boxes, pallets,
trays and/or totes to
produce a wireless system
that uniquely identifies and
tracks items as they travel
through the supply chain.
Works with Matrics reader.
Price includes 250 tags.
Discounts applied for
orders of 10,000 or more.
•
Tag Type: Matrics proprietary (Auto ID class
'0' pending)
Operating frequency: 915 MHz (902-928 MHz)
Read Range: up to 3 meters
Simultaneous Identification of Tags: Up to 800
tags per second
Tag Power: RF Beam Powered (Passive)
Tag to Reader Communication: Backscatter
Memory Capacity: 80 bits; 16 bits CRC
Memory Type: Read Only
Antenna Dimensions: 2"x2"
Orientation Sensitivity: N/A
Temperature: Operating: -20° to +70° C (-4°
to +158° F)
Applications: General Purpose.
US271.99
• Tag Type: Matrics proprietary (Auto ID class
'0' pending)
• Operating frequency: 915 MHz (902-928
MHz)
• Read Range: up to 5 meters
• Simultaneous Identification of Tags: Up to
800 tags per second
• Tag Power: RF Beam Powered (Passive)
• Tag to Reader Communication: Backscatter
• Memory Capacity: 80 bits; 16 bits CRC
• Memory Type: Read Only
• Antenna Dimensions: 4"x4"
• Orientation Sensitivity: N/A
• Temperature: Operating: -20° to +70° C (4° to +158° F)
• Applications: General Purpose
US271.99
3.3. Lectores RFID
Los lectores son los dispositivos responsables de detectar la existencia de etiquetas RFID en
su rango de lectura, y de interrogar a los sensores que pudieran encontrarse acoplados o
embebidos en las etiquetas. Como ya se ha mencionado, los lectores constan de una antena y
un “transceiver”.
La antena emite señales de radio para activar la etiqueta y leer (y escribir datos en ésta en el
caso de que sea activa). Las antenas son los conductos entre la etiqueta y el transceptor, el
cual controla la adquisición de los datos y la comunicación. Las antenas se encuentran
disponibles en una gran variedad de formas y tamaños, pueden colocarse en el marco de una
puerta para recibir datos de la etiqueta acerca de las personas o cosas que pasen a través de la
puerta, o bien pueden ser colocadas sobre una caseta de peaje para monitorizar el tráfico de
una autopista. El campo electromagnético producido por una antena puede estar presente
35
Análisis de servicios de identificación-localización basados en RFID
constantemente cuando se esperan múltiples etiquetas de forma incesante. Si no se requiere
interrogación constante, el campo puede ser activado por un dispositivo sensor (así funcionan
algunas antenas en marcos de puertas, por ejemplo).
A menudo, la antena se encuentra asociada al transceptor y al decodificador, que de esta
manera conforman un lector (interrogador), el cual, a su vez, puede ser configurado como un
dispositivo móvil o fijo. El lector emite ondas de radio en rangos que van desde una 2 cm
hasta 3 metros o más, dependiendo de la potencia de la antena y la frecuencia de radio que
use. Cuando una etiqueta RFID pasa a través de la zona electromagnética, ésta detecta la señal
de activación del lector. El lector decodifica los datos codificados en el circuito integrado de
la etiqueta y los datos se pasan al ordenador para su procesamiento.
El Auto-ID Reader Protocol Specification 1.0 define un protocolo estándar por medio del cual
los lectores se comunican con los sistemas de adquisición de datos (Savants) y otros
ordenadores. La especificación de los sistemas de adquisición de datos tiene también previsto
un “adaptador” para lograr una interfaz con lectores antiguos que no implementan el Auto-ID
Reader Protocol.
Los sistemas de baja frecuencia (30 KHz a 500 KHz) tienen rangos de lectura cortos y costes
bajos. Son los más usados en aplicaciones de seguridad en el acceso, rastreo e identificación
de animales. Los sistemas de alta frecuencia (850 Mhz a 950 MHz y de 2.4 GHz a 2.5 GHz)
ofrecen rangos de lectura amplios (mayores de 3 m) y velocidades de lectura altas y son
usados para aplicaciones como seguimiento de vagones de tren y cobro de peaje automático.
Como ya se ha mencionado en este estudio, la gran ventaja significativa de todos los tipos de
sistemas RFID es la ausencia de contacto y la naturaleza de la tecnología en cuanto a que no
es necesaria la visión directa. Las etiquetas pueden leerse a través de una gran variedad de
sustancias como nieve, niebla, hielo, pintura, suciedad incrustada y otras condiciones
ambientales y visuales adversas en donde los códigos de barra y otras tecnologías de lectura
óptica no serían útiles. Las etiquetas RFID también pueden ser leídas en circunstancias
adversas a altas velocidades, en la mayoría de los casos respondiendo en menos de 100
milisegundos. La capacidad de lectura/escritura de un sistema RFID activo es también una
36
Análisis de servicios de identificación-localización basados en RFID
ventaja significativa en aplicaciones interactivas tales como trabajo-en-proceso y seguimiento
del mantenimiento. Aunque es una tecnología costosa (comparada con código de barras),
RFID ha llegado a ser indispensable para un amplio rango de captura de datos automatizada y
aplicaciones de identificación que no serían posibles de otra manera.
Los desarrollos en la tecnología RFID continúan en campos para incrementar las capacidades
de memoria, rangos de lectura más amplios y procesamientos más rápidos. Es altamente
improbable que la tecnología remplace a los códigos de barra –incluso con la inevitable
reducción de los materiales en conjunción con las economías de escala, el circuito integrado
de una etiqueta RFID nunca tendrá una mejor relación coste-beneficio que la etiqueta de
código de barras. Sin embargo, RFID continuará creciendo en algunos dominios donde el
código de barras u otras tecnologías ópticas no son efectivas. Si los intentos de
estandarización de etiquetas, lectores, protocolos entre ambos e interfaces de los lectores
llegan a buen puerto, se espera un gran crecimiento del mercado.
Algunas características de los lectores RFID que puede ser interesante observar, aparte del
precio de compra, tienen que ver con los rangos de frecuencia que se usan, la compatibilidad
con las tarjetas, los mecanismos anticolisiones y el rango de lectura.
En primer lugar, comentemos que es posible que, desde el punto de vista del lector, aparezcan
dos tipos de colisiones:
1. colisión de lectores, por solapamiento de la zona de cobertura de dos o más lectores.
Así, el Auto-ID Center ha emitido recomendaciones acerca de la sincronización de
lectores, basadas en el uso de TDMA (acceso múltiple al medio por división en el
tiempo). Los lectores deberán de coordinarse para realizar un reparto del tiempo
disponible de forma que no emitan a la vez si pudieran colisionar. En cualquier caso,
las etiquetas situadas en la zona de solapamiento responderán con el mismo código a
todos los lectores en cuya cobertura se encuentren, en momentos diferentes. La
detección de las etiquetas identificadas simultáneamente por varios lectores al estar en
la zona de colisión es una función que queda fuera del alcance de los lectores: el
sistema de recogida de datos (denominado Savant en la terminología Auto-ID Center).
37
Análisis de servicios de identificación-localización basados en RFID
2. colisión de etiquetas que se produce cuando en la zona de cobertura de un lector se
encuentran simultáneamente varias etiquetas que responden a la vez a la excitación del
lector, enmascarando la señal de vuelta. De entre los múltiples métodos que se han
investigado e informado en la literatura del tema, el Auto-ID Center ha seleccionado y
estandarizado un método de sondeo selectivo: cuando el lector recibe una señal que le
indica que hay colisión de etiquetas, comienza un procedimiento de búsqueda binaria
de etiquetas (básicamente, usa prefijos crecientes binarios de código para pedir
respuesta a un subconjunto de las etiquetas posibles en la zona de cobertura), hasta
que recibe respuesta de una única etiqueta. Según las implementaciones de referencia
documentadas por el Auto-ID Center, han sido capaces de obtener una velocidad neta
de lectura de 50 etiquetas por segundo incluyendo la sobrecarga que impone este
mecanismo de selección de etiquetas.
Por otra parte, el rango (la distancia) de lectura de un lector, depende de la potencia de
emisión de su antena y de la frecuencia que usen la tarjeta y la antena para comunicarse; en
general las etiquetas de más alta frecuencia ofrecen mayores rangos de lectura, pero necesitan
también mayor potencia del lector. Un caso típico es el de las etiquetas de HF, cuyos lectores
tienen un rango de lectura medio de 30 cm, o el caso de los lectores UHF que pueden leerse
hasta los 6 metros. En la situación actual, en la que la localización de un ítem se basa
únicamente en el conocimiento de la posición del lector que lo identifica, existe un punto de
equilibrio entre el número de lectores, el rango de lectura de éstos, y la precisión de la
localización, en virtud del cual puede ser mejor usar más lectores de menor rango, por
ejemplo. Este punto de equilibrio depende de la aplicación para la que se utilicen los lectores,
y de la topología de red de éstos, y se trata de un problema todavía en estudio. La realización
del cálculo de este punto de equilibrio en un contexto concreto es hoy día objeto de
consultoría; conseguir un método general, automatizado y barato para el cálculo del punto de
equilibrio es, en nuestra opinión, uno de los requisitos determinantes para que la tecnología se
adopte masivamente, y podría ser un perfecto motivo de estudios posteriores a este trabajo.
38
Análisis de servicios de identificación-localización basados en RFID
3.4. Muestra de mercado de lectores RFID
Lectores de proximidad (12 cms.)
IMAGEN DEL PRODUCTO
NOMBRE DEL PRODUCTO
FEIG 13.56 Handheld Reader Kit
COSTE
US499.99
FEIG 13.56MHz Proximity
Development Kit
US499.99
FEIG M02 Reader Module
US199.99
Open Tag Systems SR-Series
Handheld Scanner
US369.99
SkyeRead H1 (LCD Screen)
US474.99
Lectores de rango medio (46 cms.)
IMAGEN DEL PRODUCTO
NOMBRE DEL PRODUCTO
FEIG 13.56MHz Mid-Range
Development Kit
COSTE
US699.99
Mercury3 Dual Frequency Reader
from ThingMagic
US2,799.99
Mercury3 Dual Frequency Reader
from ThingMagic Development Kit
US3,999.99
MPR-1510 915MHz Hand-held
Reader
US2,199.99
39
Análisis de servicios de identificación-localización basados en RFID
Lectores de rango largo (3.3 metros)
IMAGEN DEL PRODUCTO
NOMBRE DEL PRODUCTO
Alien Technology 915 MHz
RFID Reader w/Antenna
COSTE
US3,999.99
Dock Door RFID Kit - EPC
Class 1 Compliant
US4,999.99
Matrics 915 MHz
Development Kit
US3,549.99
Matrics 915 MHz Stationary
Reader
US2,999.99
Mercury3 Dual Frequency
Reader from ThingMagic
US2,799.99
Mercury3 Dual Frequency
Reader from ThingMagic
Development Kit
US3,999.99
TEXAS INSTRUMENTS
ANTENAS DE BAJA FRECUENCIA
IMAGEN DEL PRODUCTO
NOMBRE DEL PRODUCTO
RI-ANT-G04E (Series 2000 Gate Antenna
Large)
The Large Series 2000 Gate Antenna is a fullypackaged antenna for applications like vehicle
access to parking lots in an outdoor
environment. It can be mounted on a pole or a
wall. The antenna is optimized for cable
lengths between 0.5 and 4 meters.
Recommended connecting cable type: 2.5 mm
2 (14 AWG) flexible conductor.
40
COSTE
US 220.32
Análisis de servicios de identificación-localización basados en RFID
RI-ANT-G01E (Series 2000 Gate Antenna
Medium)
US 156.67
The gate antenna is designed for use in
doorways, entrances and corridors, beside
conveyers, or in any location where the reading
field coverage needs to be maximized.
RI-ANT-GO2E (Series 2000 Gate Antenna
Small)
The small gate antenna is designed for use
beside conveyers, or in any small defined
location.
US 139.05
RI-ANT-S02C (Series 2000 Stick Antenna)
The ferrite rod antenna is a short cylindrical
device used in stationary applications where
space is limited. An additional benefit of the
stick antenna is that it allows a precise
discrimination between RFID tags in close
proximity to one another through a highly
directed field.
RI-ANT-P02A-00 (Series 2000 Stick Antenna
for Series 2000 Mini RFM)
This stick antenna is specially designed for use
with the Mini-RFM. The ferrite rod antenna is a
short cylindrical device used in stationary
applications where space is limited. An
additional benefit of the stick antenna is that it
allows a precise discrimination between RFID
tags in close proximity to one another through
a highly directed field.
US 90.09
Antena de alta frecuencia.
41
US 84.21
Análisis de servicios de identificación-localización basados en RFID
RI-ANT-T01A-00 (Gate Antenna for High
Frequency Readers )
US 425.00
The Antenna RI-ANT-T01A is a High
Frequency (13.56MHz) antenna optimized for
the High Frequency Long Range Readers
S6500/S6550 Readers. The antenna is a
300mmx300mm single-loop antenna that can
be used with other readers having a transmitter
frequency of 13.56 MHz and an output
impedance of 50 Ohm.
LECTORES DE BAJA FRECUENCIA
IMAGEN DEL PRODUCTO
NOMBRE DEL PRODUCTO
RI-STU-MRD1 (Series 2000 Micro Reader)
The Micro-reader is an intelligent module
which provides the RF and Control functions to
communicate with TI-RFID Transponders. It is
equipped with a serial communications
interface which may be directly connected to
commonly used system controllers. The use of
low-Q antennas eliminates the need to tune
the system to resonance.
RI-STU-251B (Series 2000 Reader S251B)
The Series 2000 Reader S251B provides all
the RF and control functions to communicate
with TI*RFID LF Transponders. It includes a
Dynamic Auto Tuning (DAT) function that
automatically tunes a standard antenna to
resonance and keeps it tuned during
operation. The reader performs all the tasks
necessary according to the commands from
the host to send signals to and receive data
from a TI RFID Transponder. It decodes the
received RF signals into the transponder’s
identification number, checks the validity and
handles the conversion to a standard serial
interface protocol.
RI-STU-MB6A (Series 2000 Standard
Reader RS422/485 Interface)
The Series 2000 Control Module (CTL) is the
interface between a TI RFID Radio Frequency
Module and a controlling host. The CTL
controls the transmitting and receiving
functions of the RFM according to the
commands from the host to send signals to
and receive data from a TI-RFid transponder.
It decodes the received RF signals into the
transponder’s identification number, checks
the validity and handles the conversion to a
standard serial interface protocol.
42
COSTE
US 63.97
US 748.54
US 511.36
Análisis de servicios de identificación-localización basados en RFID
RI-STU-MB2A (Series 2000 Standard
Reader with RS 232 Interface)
The Series 2000 Standard Reader provides
RF and Control Functions to communicate
with TI-RFid LF Transponders. It sends an
energizing signal to the transponder,
modulates the RF signal to send data to the
transponder, decodes and checks the received
transponder data and transmits it via a
standard serial interface. This is the same
reader included in the LF Evaluation Kit.
US 511.36
Lectores de alta frecuencia
IMAGEN DEL PRODUCTO
NOMBRE DEL PRODUCTO
RI-STU-TRDC-02 (S6350 Midrange Reader
Module)
The S6350 HF reader is a low profile, low
power device that is designed to be easily
integrated or imbedded into almost any system.
Operating at a frequency of 13.56 MHz and
compatible with ISO/IEC 15693 inlays and
tags, the S6350 Reader allows for the
interoperability of inlays and tags from multiple
manufacturers.
RI-STU-650A-00 (S6500 Long Range Reader
Module)
The S6500 Long Range Reader Module
handles all RF and digital functions required in
order to communicate with Tag-it HF, Tag-it
HF-I (ISO 15693 compliant) and all other ISO
15693 compliant transponder from various
suppliers. The module has two digital inputs,
two digital outputs, a relay output and an
asynchronous interface which can be
configured as RS232 or RS485. The
configurability of the interfaces also allows the
module to be operated on an RS485 data bus.
The address can be assigned either through
software or hardware (3 DIP switches).
Software Available Through Free Downloads
on TI-RFid Product Page.
43
COSTE
US 178.50
US 2,082.50
Análisis de servicios de identificación-localización basados en RFID
RI-STU-655A-00 (S6550 Long Range Reader
(Housed including Power Supply))
The S6550 Long Range Reader (Housed)
handles all RF and digital functions required in
order to communicate with Tag-it HF, Tag-it
HF-I (ISO 15693 compliant) and all other ISO
15693 compliant transponders from various
suppliers. The Reader Module is encased in a
powder coated sheet steel box (IP54 protection
level). This means that the housed reader can
be mounted either inside or outside. The
reader has two digital inputs, two digital
outputs, a relay output and an asynchronous
interface which can be configured as RS232 or
RS485. The configurability of the interfaces
also allows the reader to be operated on an
RS485 data bus. The address can be assigned
either through software or hardware (3 DIP
switches).
US 2,550.00
Transponders de baja frecuencia
RI-TRP-R9TD (120mm Cylindrical
Transponder R/O)
The durable tag features enhanced read range.
Specially packaged to withstand harsh
environments to allow it to be attached by
means of non-metallic posts to trucks and
containers. The Read Only functionality means
the transponder cannot be reprogrammed and
has a factory programmed unique 64-bit
number.
RI-TRP-W9TD (120mm Cylindrical
Transponder R/W)
The durable tag features enhanced read range.
Specially packaged to withstand harsh
environments to allow it to be attached by
means of non-metallic posts to trucks and
containers. Read/Write capability allows the
user to reprogram the transponder as often as
required.
RI-TRP-R9WK (12mm Wedge Transponder
R/O)
The wedge transponder is encapsulated within
a plastic mold compound. It has a compact and
robust construction with a built-in notch for
precise fixturing in secondary packages. The
wedge shape enables automatic orientation.
The Read Only functionality means the
transponder cannot be reprogrammed and has
a factory programmed unique 64-bit number.
44
US 10.86
US 9.65
US 3.38
Análisis de servicios de identificación-localización basados en RFID
RI-TRP-W9WK (12mm Wedge Transponder
R/W)
The wedge transponder is encapsulated within
a plastic mold compound. It has a compact and
robust construction with a built-in notch for
precise fixturing in secondary packages. The
wedge shape enables automatic orientation.
The read/write functionality allows this
transponder to be programmed according to
the needs of the application.
45
US 3.63
Análisis de servicios de identificación-localización basados en RFID
4. Arquitectura de estandarización de identificación RFID
4.1. Escenario de referencia Auto-ID
La figura que se muestra a continuación indica el funcionamiento general de un sistema de
identificación-localización basado en RFID en un contexto corporativo (industrial). Muestra
tanto el flujo de información como los elementos fundamentales de la arquitectura de
referencia propuesta por el Auto-ID Center, que comentaremos con detalle más adelante.
Etiquetas RFID
(Las hay activas y
pasivas. De
lectura/escritura y
de sólo lectura)
1
Lector RFID
2
Servicio de Información EPC. Se
encarga que de todos los datos
sean presentados en formato PML
Middleware Savant. Filtrado,
agregación y contabilidad de los
datos de lectura de las etiquetas
3
6
Aplicaciones
empresariales
Caché ONS local. Se mantiene un
registro de las consultas hechas de
modo frecuente o últimamente
realizadas.
5
4
PML Server
Servidor ONS (Servicio de
nombres de objetos). El servicio
puede ser estático o dinámico.
Aunque mencionaremos otras propuestas de arquitectura de aplicaciones de identificaciónestandarización RFID, hemos encontrado una alineación muy clara de todas las propuestas
con la arquitectura de referencia Auto-ID, por lo que ceñiremos el estudio al análisis de dicha
arquitectura de referencia.
46
Análisis de servicios de identificación-localización basados en RFID
El escenario de uso de la tecnología RFID para la identificación:
1. Los lectores detectan cuando una etiqueta entra en su rango de lectura y obtienen el
código EPC (código electrónico del producto).
2. El lector envía la lectura (EPC) a un ordenador que ejecuta el sistema de recogida de
información, denominado Savant, encargado de filtrar, agregar y contabilizar los datos
obtenidos de los lectores.
3. Savant consulta su base de datos local en la cual se asocia un código EPC del producto
a una URL donde se encontrará la información descriptiva del producto. La base de
datos se denomina ONS (Object Name Server) y es una base de datos jerárquica
distribuida al estilo del DNS (Domain Name Server) de Internet.
4. Si los datos del URL no se encuentran en la base de datos local, entonces se utiliza un
servicio de ONS global. Esta base de datos ONS global permitirá obtener la URL en la
cual obtener la descripción del producto al cual va asociada la etiqueta con el EPC
leído, tomando la información del producto del fabricante de éste (el que le incorporó
la etiqueta).
5. De acuerdo al URL obtenido (ya sea local o global), se puede acceder a la base de
datos del servidor que contiene la información descriptiva del producto, expresada en
el lenguaje PML (product markup language, un dialecto derivado de XML) que
contiene la información del producto.
6. Las aplicaciones empresariales y corporativas utilizan una interfaz proporcionada por
Savant para acceder a la información que éste puede proporcionar, incluyendo
identificación, localización y medidas de otros tipos.
Aun siendo un escenario específico, centrado fundamentalmente en la función de
identificación de producto, y que deja al margen la problemática de asociación de códigos a
productos, descripción de productos, ciclo de vida de etiquetas, seguridad, etc. tomaremos el
escenario como básico para la descripción de la arquitectura. En una situación de operación
estable, este escenario es el más común y el absolutamente crucial para observar las ventajas
de la introducción de la tecnología.
47
Análisis de servicios de identificación-localización basados en RFID
4.2. Arquitectura de referencia Auto-ID
La figura muestra en más detalle la arquitectura de referencia propuesta por el Auto-ID Center
para el desarrollo y despliegue de sistemas de identificación-localización basados en RFID.
En dicho gráfico se muestran las entidades fundamentales en el despliegue de la tecnología
RFID en el ámbito interno de la empresa. Los elementos del sistema de identificaciónlocalización son los marcados en amarillo (Etiquetas, sensores, EPC, Reader, Savant, EPC
information servcie, ONS (caché). La integración del sistema hacia el exterior se produce:
• Por la conexión entre subsistemas ONS,
• Por la integración entre el sistema Auto-ID y las aplicaciones de la empresa (Enterprise
Applications), e indirectamente en este punto por las transacciones de negocio, que
deberán ser controladas por las aplicaciones de la empresa.
48
Análisis de servicios de identificación-localización basados en RFID
En esta primera aproximación a la arquitectura de referencia propuesta por el Auto-ID Center,
que vamos a seguir a lo largo de este estudio, aparecen algunos conceptos sobre los que
profundizaremos más adelante y cuyo estudio constituirá el núcleo de este trabajo. Merece la
pena dar una breve descripción de todos ellos de forma que sea entendible el esquema general
de funcionamiento de los sistemas de identificación-localización basados en RFID:
• Tarjeta: se refiere a las tarjetas RFID ya comentadas en la sección correspondiente a
elementos de nivel físico. En el caso del trabajo de Auto-ID Center, las tarjetas serán,
fundamentalmente, tarjetas pasivas, de sólo lectura, y capaces de proporcionar bajo la
excitación del lector un código electrónico de producto (EPC) según los estándares (64
o 96 bits).
• Lector (Reader): el lector debe ser capaz de consultar o sondear su zona de cobertura y
de obtener información correspondiente a los códigos EPC de las tarjetas que se
encuentren en este rango. Para ello, el lector implementa un mecanismo de resolución
de la colisión de las etiquetas. El lector (o mejor los lectores) estarán asociados a uno o
varios ordenadores a través de una red de área local o inalámbrica, de forma que los
lectores puedan recibir las órdenes de estos ordenadores para guiar su ejecución, y los
lectores dar información del “inventario” o conjunto de identificadores EPC de las
tarjetas en el rango.
• Código electrónico EPC: se trata de un conjunto de bits organizados de acuerdo a
diferentes patrones o máscaras. Una tarjeta debe ser capaz de devolver un código al
lector que le ha sondeado. Los estándares propuestos por Auto-ID Center y en uso
actualmente permiten identificar de forma unívoca a un ítem (producto) en una
organización según un esquema jerárquico; Auto-ID Center propone conjuntos de 64 y
96 bits.
49
Análisis de servicios de identificación-localización basados en RFID
• Savant: es el subsistema de recogida de datos a partir de los lectores a su cargo, y
efectuar operaciones básicas de tratamiento de los datos obtenidos (eliminación de
EPC duplicados en varios lectores por colisión de lectores, por ejemplo). Igualmente,
este subsistema debe mantener una base de datos de tiempo real de forma que los
datos se recojan, filtren, y envíen eficientemente. Savant pueden entenderse también
como un sistema jerárquico de recogida y almacenamiento temporal de datos en el que
las hojas de la jerarquía recogen los datos de campo y éstos son agregados en la
jerarquía dentro de los servidores de la empresa.
• Product Markup Language (PML): la descripción de un producto debe de realizarse de
manera estandarizada. El PML usa esquemas XML para describir los productos que
típicamente serán puestos bajo el control del sistema RFID. Al utilizarse estos
esquemas comunes, se fomenta la interoperabilidad de sistemas RFID entre empresas,
a la vez que se agrupa al mercado.
• Servidor de información de producto (EPC information service): es cualquier servidor
que contiene descripciones en lenguaje PML al que atacar proporcionando un código
EPC para obtener una descripción del producto asociado al código EPC en este
lenguaje, capaz de ser procesada o leída por humanos.
• Object Name Server: se trata de un subsistema que introduce un nivel de indirección
entre el código EPC que es capaz de recoger el Savant a partir de los lectores –que los
obtienen de las tarjetas en su rango de lectura-, al lugar de Internet (descrito con un
Universal Resource Locator o URL) en el que se podrá encontrar una descripción del
producto al que el código EPC ha sido asociado. La estructura de ONS es una réplica
de la estructura del Domain Name Server DNS de Internet; parece que se ha elegido
ésta por la capacidad de crecimiento, normalización, nivel de replicación y esquema de
cachés, y por aprovechar la experiencia que ya existe en el uso de DNS para almacenar
información fuera del uso convencional dominio Internet-direccíón IP (por ejemplo,
los estándares ENUM utilizan igualmente el DNS como base de datos de información
de usuarios a partir de un dato de entrada que en este caso resulta ser un número de
teléfono).
50
Análisis de servicios de identificación-localización basados en RFID
El siguiente gráfico muestra un esquema muy similar, en el cual la descripción de los
productos se mantiene fuera del control de la empresa o del dominio administrativo en el que
se encontrará una determinada etiqueta.
En las siguientes secciones de este trabajo, detallaremos los resultados de nuestras
investigaciones acerca de cada uno de los elementos de la arquitectura. Describiremos sus
funciones, normas estandarizadas e implementaciones de las que hemos tenido información.
Seguiremos en cada uno de ellos el estándar correspondiente emitido o recomendado por
Auto-ID center.
51
Análisis de servicios de identificación-localización basados en RFID
5. Códigos EPC
La descripción que se incluye hace referencia al estándar “EPC Tag Data Specification 1.0”
de Auto-ID Center.
5.1. Elementos generales del código EPC
El Código Electrónico de Producto (Electronic Product Code, EPC) es un esquema de
numeración diseñado para identificar todos los objetos de forma única. El EPC fue creado
para enumerar todos los objetos, usando de forma coordinada todos los métodos de
numeración actuales y futuros. La norma describe la especificación de codificación del EPC
en representación binaria, esto es, una secuencia de bits que codifica el EPC de una manera
bien definida.
El EPC es un número único diseñado para identificar objetos. El EPC tiene una forma y
estructura particulares que facilitan la unicidad, gestión del número y referencias a la
información. La representación binaria del EPC consiste de una secuencia particular de
particiones y bits.
El EPC fue previsto en un principio para acomodar los estándares de codificado existentes
mientras se mantiene la generalidad, unicidad, simplicidad y eficiencia del direccionamiento
de redes. Dadas estas restricciones, la especificación del EPC incluye un número de
Identificación Universal Genérico, así como un conjunto de códigos de Identificación de
Dominios que acomodan los sistemas de numeración existentes.
La estructura general del EPC consiste de un encabezado de longitud fija seguido de una serie
de números cuya estructura y función están determinadas completamente por el valor del
encabezado. La especificación del EPC distingue entre un número de Identificación Universal
Genérico y una serie de códigos de Identificación del Dominio. En la versión 1.0 del EPC se
especifica el número de Identificación Universal y un solo código de Identificación de
Dominio.
52
Análisis de servicios de identificación-localización basados en RFID
5.2. Elementos del código EPC
Para distinguir entre tipos y versiones del EPC, todos los números de EPC consisten de un
encabezado de longitud fija seguido de una serie de números cuya longitud, organización y
estructura están determinadas completamente por el valor del encabezado, como se ilustra en
la siguiente figura. En este sentido, el número de encabezado puede ser considerado un metacódigo, esto es porque determina la estructura y formato de los números restantes.
Header
Numbers
Específicamente el encabezado EPC:
1. determina la estructura para la identificación única de un objeto,
2. establece el número y formato del número de particiones, incluyendo la longitud total
y la longitud de cada partición,
3. indica las particiones adicionales para contenido o datos asociados con un EPC (si es
necesario).
La longitud de bits totales y la longitud de bits de cada partición están establecidas por un
valor de encabezado dado, como se refleja en la siguiente tabla.
Binary Value
96-bit Universal Identifier
0000 0001
96-bit Domain Identifier (EAN.UCC System)
0000 0010
64-bit Universal Identifier
01
64-bit Domain Identifier (EAN.UCC System)
10
53
Análisis de servicios de identificación-localización basados en RFID
De modo adicional a un encabezado, los Identificadores Universales están compuestos de
particiones de tres bits: el número de Gestor de Dominio, el número de Clase de Objeto y el
Número de Serie. Las asignaciones de bits para los tipos de 96 y 64 bits se muestran en la
siguiente tabla.
Bit Allocations Per Partition
Header
96-bit
Domain
Object
Serial
Manager
Class
Number
8
28
24
36
2
21
17
24
Universal
Identifier
64-bit
Universal
Identifier
El componente Gestor de Dominio identifica el Gestor EPC; esto es, la compañía o entidad
responsable del mantenimiento de los números en las particiones subsecuentes (Clase Objeto
y Número de Serie). Un número de Gestor de Dominio representa la misma entidad en todas
las versiones. El número de Gestor de Dominio es asignado por EPCglobal a una compañía y
asegura que cada número de Gestor de Dominio es único.
El tercer componente es la clase de objeto, y es usada por el Gestor EPC para identificar una
clase de objetos. La clase objeto representa un grupo o clase de objetos. La entidad o
compañía que se encuentra administrando el número de Gestor de Dominio asigna los
números de clase de objetos de modo que cada clase de objetos dentro de un número de
Gestor de Dominio sea única.
El cuarto componente, el Número de Serie, codifica la identificación única de la instancia. La
entidad o compañía administrando el número de Gestor de Dominio asigna el número de serie
de modo que cada instancia dentro de un número de clase de objeto tenga un número de serie
distinto. Este número necesita ser único para identificar a una instancia del objeto.
54
Análisis de servicios de identificación-localización basados en RFID
El tipo de Identificación de Dominio definido soporta el EAN.UCC Global Trade Item
Number (GTIN®). En adición al encabezado, los identificadores están compuestos de
particiones de cuatro bits: el tipo de objeto, un prefijo de compañía, una referencia al artículo
y un número de serie. El tipo de 96 bits contiene también una quinta partición para establecer
la división entre prefijo de compañía y referencia al artículo.
El prefijo de la compañía y las particiones de referencia de artículo varían en relación a cada
otro y la partición sirve para establecer la división exacta en cada caso. La partición existe
solamente en la versión de 96 bits. Los valores de la partición se describen en la tabla
siguiente.
Partition
Company Prefix
Item Reference
Bits
Digits
Address
Bits
Digit
Address
1
37
11
128 Billion
7
2
128
2
34
10
16 Billion
10
3
1024
3
30
9
1 Billion
14
4
16,384
4
27
8
128 Million
17
5
131,072
5
24
7
16 Million
20
6
1 Million
6
20
6
1 Million
24
7
16 Million
5.3. Actualizaciones a la norma
La versión 1.1.es la primera versión especificada formalmente, sirve como base para la
asignación y uso de números EPC en aplicaciones de sistemas abiertos y estándares. Las
versiones previas, consisten de reportes técnicos y borradores de trabajo, recomendaciones de
ciertos encabezados, longitudes de etiqueta y estructuras de datos EPC. Muchas de estas
construcciones han sido modificadas en el desarrollo de la versión 1.1 y no se mantienen para
un uso estándar. Específicamente, la versión 1.1 remplaza todas las definiciones previas de los
estándares de datos de etiquetas EPC.
55
Análisis de servicios de identificación-localización basados en RFID
Más allá del contenido nuevo de la versión 1.1 (tal como la adición de nuevos formatos de
codificación) los cambios más significativos a las versiones anteriores son:
1. Redefinición y clarificación de las reglas para la asignación de los valores de
encabezado: (i) permitir varias longitudes de encabezado para una etiqueta de una
longitud dada para soportar más opciones de codificación en una etiqueta específica, y
(ii) indicar la longitud de la etiqueta vía la parte izquierda más significativa del
encabezado; esto es para soportar una eficiencia de lectura máxima.
2. Retiro de los identificadores universales de 64 bits en los formatos tipos I y III,
previamente identificados por encabezados de 2 bits. El encabezado asignado al
Identificador Universal tipo II es ahora asignado a la codificación SGTIN de 64 bits.
Los encabezados tipo I y III no han sido reasignados a otras codificaciones, y están
simplemente designados como “reservados”. Los encabezados asociados con los tipos
I y III se mantendrán como re-reservados por un periodo de tiempo aún no
determinado para poder soportar las etiquetas que los han usado previamente. A
menos que aparezca una clara necesidad (como fue el caso con el SGTIN) en donde
estos pueden ser considerados para ser reasignados.
3. Renumeración de los encabezados de los Identificadores Universales de 96 bits para
encajarlos dentro de las reglas de encabezados revisadas y renombrar este código
“Identificador General” para evitar confusión con el identificador único (UID) que
será introducido por el Departamento de la Defensa de los Estados Unidos y sus
proveedores.
56
Análisis de servicios de identificación-localización basados en RFID
6. Arquitectura de los lectores (Reader)
La descripción que se incluye hace referencia al estándar “Reader Protocol Specification 1.0”
de Auto-ID Center.
6.1. Estructura general del nivel de lector (Reader)
El Auto-ID Reader Protocol 1.0 define el protocolo por medio del cual los lectores de
etiquetas interactúan con las aplicaciones de software compatibles con las especificaciones
Auto-ID; en estas normas, las aplicaciones reciben en nombre genérico de “host” o aplicación
“host”, siendo un ejemplo de aplicación “host” el Savant especificado por las normas AutoID. La aplicación “host” puede interactuar con el o los lectores de forma local (reside en el
mismo ordenador al que está físicamente conectado el o los lectores), o por otro medio de
comunicación-conexión.
El término “lector de etiqueta” incluye lectores de etiquetas RFID, soportando cualquier
combinación de protocolos RF, fijos o manipulados manualmente, etc. También incluye
lectores de otros tipos de etiquetas, como los códigos de barras. Los lectores de tarjetas, a
pesar de su nombre, pueden tener la capacidad de escribir datos en las etiquetas.
La interacción entre el lector y las etiquetas RFID se encuentran fuera del alcance de esta
especificación. Tales interacciones se describen en las especificaciones HF1, UHF0 y UHF1.
Una ventaja del protocolo de lectura es aislar a la aplicación “host” de la necesidad de
conocer aspectos relacionados con la interacción entre el lector y las etiquetas. Así pues, los
lectores son los dispositivos responsables de detectar cuándo entran en su rango de lectura las
etiquetas RFID. También pueden interrogar a los sensores que se encuentren acoplados a las
etiquetas, si existen.
La especificación del lector define tres capas en la construcción de éste, correspondientes a las
funciones de los protocolos de lectura que aparecen en la siguiente figura.
57
Análisis de servicios de identificación-localización basados en RFID
Capa de lectura. Se encarga de arbitrar el intercambio entre
contenidos entre el host y el lector.
Capa de Mensajes. Realiza las tareas de estructurar el
mensaje, los servicios de seguridad y el establecimiento de
la conexión.
A cada par se le llama Binding de
mensaje/transporte
Capa de transporte. Proporciona capacidades de red, tal
como un sistema operativo.
• Capa de lectura: Esta capa especifica el contenido y formato del intercambio de mensajes
entre el lector y la aplicación “host”. Esta capa es el corazón del protocolo de lectura,
definiendo las operaciones que pueden efectuar los lectores y lo que éstas significan.
• Capa de mensajes: Especifica cómo se estructuran, transforman y transportan los mensajes
definidos en la capa de lectura, sobre un transporte de red específico. Si existen servicios
de seguridad, estos son proporcionados por esta capa (los servicios de seguridad incluyen
autenticación, autorización, confidencialidad de mensajes e integridad de mensajes). Para
cada mensaje, la capa de mensajes especifica cómo se establece una conexión de red
subyacente, cómo debe ser cualquier mensaje de inicialización requerido para establecer la
sincronización o para inicializar los servicios de seguridad y, además, cualquier otro tipo
de proceso efectuado (por ejemplo, encriptación).
• Capa de transporte. Esta capa corresponde a la especificación de las facilidades de red
proporcionadas por el sistema operativo o equivalente.
La especificación del protocolo de lectura proporciona múltiples alternativas de
implementación de la capa de mensajes. Cada implementación se llama “binding” de
mensaje/transporte, y hay varios tipos de transporte, por ejemplo, TCP-IP, Bluetooth o línea
serie. Cada uno de ellos proporciona diferentes tipos de servicios de seguridad, formas de
establecimiento de las conexiones (inicio por el lector o por la aplicación “host”) y formas de
ofrecer la información de configuración. Al margen del MTB (message transport binding) que
se use en una sesión, un lector sólo se puede enlazar a una aplicación “host” simultáneamente.
58
Análisis de servicios de identificación-localización basados en RFID
La interfaz entre la capa de lectura y la capa de mensajes se define en términos de canales de
mensajes, cada uno representando una comunicación independiente entre el lector y la
aplicación “host”. En particular, se definen:
• El canal de control. El canal de control transporta las solicitudes de la aplicación “host” al
lector, y las respuestas de éste, en modo síncrono (solicitud-respuesta). La mayoría de las
interacciones lector-“host” usan este canal.
• El canal de notificación. El canal de notificación transporta los mensajes producidos por el
lector hacia la aplicación “host”, de forma asíncrona. Este canal se usa para soportar un
modo de operación en el cual el lector entrega lecturas de etiquetas a la aplicación “host”
sin necesidad de que esta realice ninguna consulta, de forma asíncrona.
El uso de estos dos canales de comunicación separados soporta el siguiente escenario de
operación:
1. La aplicación “host” produce una petición (en el canal de control) al lector para que entre
en el modo de lectura automática.
2. El lector responde con un asentimiento (acknowledgement) sobre el canal de control.
3. Posteriormente, el lector produce mensajes sobre el canal de notificación de forma
asíncrona, por ejemplo, sobre un temporizador o una respuesta a eventos externos.
4. En algún momento después, la aplicación “host” produce una nueva petición (sobre el
canal de control) para terminar con la lectura automática.
5. El lector responde (usando el canal de control) con un asentimiento.
Corresponde a la capa de mensajes determinar cómo se implementan los dos canales. En la
práctica, la mayoría de los MTB no crean dos conexiones independientes en la capa de
transporte, sino que la capa de mensajes puede usar una sola conexión a la capa de transporte
y etiquetar cada mensaje con un identificador de canal.
La razón para introducir la noción de canales de mensajes es dar más libertad a la capa de
mensajes para tratar la asincronía de diferentes maneras. Por ejemplo, si un MTB usa HTTP
como la capa de transporte, éste tendrá que tratar con la semántica estricta de
petición/respuesta de HTTP. Los pares petición/respuesta del canal de control encajan de
modo natural en HTTP pero hay que hacer algo más complicado para manejar los mensajes
59
Análisis de servicios de identificación-localización basados en RFID
del canal de notificación del lector hacia la aplicación “host”. En este caso, el MTB no deberá
usar una sola conexión HTTP para transportar tanto el tráfico de los dos canales (control y
notificación), sino que el de notificación deberá implementarse de otra forma.
6.2. Visión operativa de la capa de lectura
El protocolo de lectura proporciona un modo uniforme para que las aplicaciones “host”
accedan y controlen a los lectores, independientemente de su fabricante. Los diferentes
modelos de lectores pueden variar en funcionalidad desde los lectores más simples, capaces
sólo de proporcionar información sobre las etiquetas que se encuentran dentro del alcance del
lector, hasta los lectores “inteligentes” que proporcionan funciones de filtros avanzados,
eliminación de errores (“smoothing”), estadísticas y otras funcionalidades complejas.
Así pues, el protocolo de lectura define una colección posible de funciones y proporciona un
mecanismo estandarizado para acceder a ellas y controlarlas. El protocolo de lectura no
requiere que todos los lectores implementen todas las funciones, pero para las que están
presentes, se estandariza su acceso. Las funciones posibles se muestran en el siguiente
diagrama conceptual que representa el flujo de datos y proceso de un lector ideal.
Raw Tag Reads
Tag Event State
Data
Acquisition
Read
Filter
Sources
Smoothing/
Event
Generation
Event
Filter
Report
Buffer
Add/Remove
ReportFilter
Trigger
Hostsettable
parameters
Event
Report
Trigger
ReadCyclesPerTrigger
ReadTimeout
ReadDutyCycle
Add/Remove
ReadFilter
SoftReadExpireTime
FirmReadCount
FirmReadExpireTime
PurgeTime
Read Subsystem
Event Subsystem
Internal Data Flow
Reader-to-Host Communication of Tag Data
Host-settable Parameter
60
Análisis de servicios de identificación-localización basados en RFID
Este diagrama modela las funciones de lectura de etiqueta de un lector mediante la definición
de varios estados de procesamiento distintos (fuentes de datos, adquisición de datos, filtro de
lectura, eliminación de errores y generación de eventos, filtro de eventos, almacén de
informes). Existirán otras funciones, como las de escritura y gestión de etiquetas se
encuentran fuera del alcance de este diagrama. La información leída de la etiqueta fluye de
izquierda a derecha y en algunos de los estados puede ser visible para la aplicación “host”. En
algunos casos, esta información está disponible para la aplicación “host” como una respuesta
a una orden sobre el canal de órdenes (entrega de información síncrona); en otros casos, la
información se envía de forma asíncrona desde el lector a la aplicación “host” utilizando el
canal de notificación. Cada estado tiene parámetros que controlan sus operaciones y que
pueden ser consultados y configurados por la aplicación “host” a través del canal de órdenes.
Un ejemplo de parámetro que puede ser conocido y manejado por la aplicación “host” y que
controla la operación del lector es el número de filtros (ilimitado, único, ninguno). Los
lectores deben de proporcionar mecanismos para que las aplicaciones “host” puedan conocer
estos parámetros.
De los seis estados en el diagrama, sólo la funcionalidad de los tres primeros es obligatoria y
por lo tanto deben ser implementados por un lector compatible, mientras que la funcionalidad
de los otros estados no es obligatoria para la conformidad con la norma.
6.3. Subsistemas de la capa de lectura (Readers)
Los seis estados del diagrama están divididos en dos subsistemas de tres estados cada uno: el
subsistema de lectura y el subsistema de eventos. El primer subsistema es obligatorio para la
conformidad con la norma y el segundo opcional.
El subsistema de lectura adquiere datos de las fuentes de información (etiquetas) y les aplica
algunos filtros para descartar datos dependiendo del contenido de la etiqueta. Este subsistema
produce una lista filtrada de identificadores de etiquetas cada vez que se completa un ciclo de
adquisición. El subsistema de eventos reduce este volumen de datos generando eventos por
cada etiqueta sólamente cuando el estado de una etiqueta particular cambia de forma
61
Análisis de servicios de identificación-localización basados en RFID
significativa. Por ejemplo, el subsistema de eventos puede ser configurado para producir
resultados sólo cuando una etiqueta no vista previamente entra al campo de lectura o cuando
una etiqueta ya vista con anterioridad no ha sido detectada durante un intervalo de tiempo
específico. Conceptualmente, el subsistema de lectura no tiene estados, mientras que el
subsistema de eventos debe mantener un estado por cada etiqueta.
El subsistema de lectura se divide en los tres estados siguientes:
1. Fuentes. Una fuente lee etiquetas y presenta sus datos al lector. Una sola antena de un
lector de etiqueta RFID es un ejemplo simple de una fuente. Sin embargo, existen
otros tipos de fuentes: por ejemplo, una pistola para leer códigos de barras, o una
agregación de antenas (podrían verse grupos de antenas como si fueran una sola
fuente). El protocolo de lectura proporciona órdenes para descubrir la cantidad y
nombres de las fuentes disponibles, de forma que el nombre de la fuente se pueda
incluir en el resultado de la lectura de la etiqueta. Los diferentes lectores pueden variar
ampliamente en cuanto a las fuentes que tienen disponibles.
2. Adquisición de los datos. El estado adquisición de datos es responsable de tomar datos
de etiquetas desde fuentes en un punto específico en el tiempo. El protocolo de lectura
proporciona parámetros por medio de los cuales las aplicaciones “host” pueden
especificar la frecuencia de adquisición de datos, cuántos intentos se deben realizar,
condiciones de activación, etc. Cada intervalo atómico en el cual el estado de
adquisición de datos toma datos de una o más etiquetas de una sola fuente se llama
“ciclo de lectura”.
3. Filtrado de lecturas. El estado de filtrado de lecturas mantiene una lista de patrones
configurados por la aplicación “host”, y usa esos patrones para eliminar los datos de
ciertas lecturas de etiquetas en el estado de adquisición de datos. El propósito de este
estado es reducir el volumen de datos al incluir solamente etiquetas de interés para la
aplicación. Los filtros se construyen usando los campos del tipo de código electrónico
EPC descritos en secciones anteriores de este documento.
Por su parte, el subsistema de eventos conceptualmente consiste de tres estados:
1. Generación de eventos y “smoothing”. Este estado reduce el volumen de datos en el
tiempo. Cuando una etiqueta se encuentra presente en el campo de una fuente
62
Análisis de servicios de identificación-localización basados en RFID
particular, el subsistema de lectura incluye información sobre dicha etiqueta a su
salida cada vez que se completa un ciclo de lectura. Así que cuando una etiqueta se
encuentra dentro del rango de una fuente particular durante muchos ciclos de lectura,
se generan muchos datos. El estado de generación de eventos reduce este volumen de
datos al producir un evento sólo cuando sucede algo de interés: por ejemplo, cuando la
etiqueta aparece por primera vez, y más tarde cuando la etiqueta desaparece. Algunas
fuentes, especialmente las RFID, no son completamente fiables, significando que una
etiqueta que está dentro del campo de lectura de una fuente puede no ser detectada en
todos y cada uno de los ciclos de lectura. El protocolo de lectura define un filtro de
“smoothing” (la traducción al castellano es “aplanamiento”, aunque usaremos el
término en inglés) de propósito general, que puede ser controlado por la aplicación
“host” a través de la configuración de parámetros. Por ejemplo, la aplicación “host”
puede requerir que una etiqueta se encuentre presente durante un cierto número de
ciclos de lectura dentro de un cierto intervalo de tiempo antes de generar un evento de
presencia. El estado que describimos debe mantener información por cada
combinación fuente-etiqueta, y esta información puede ser la entrada al siguiente
estado, o ser leída por la aplicación “host”
2. Filtro de eventos. El estado de generación de eventos y “smoothing” genera un evento
cada vez que una etiqueta particular efectúa una transición de estado, por ejemplo, de
estar presente a no estar presente. El estado de filtro de eventos permite que las
aplicaciones “host” especifiquen los eventos en los que están interesadas; por ejemplo,
una aplicación que sólo desea saber cuándo desaparece una etiqueta del campo de
lectura.
3. Almacén de informes. Los eventos generados por el estado anterior se van
almacenando en este almacén de informes. La aplicación “host” puede solicitar de
forma asíncrona la entrega de todos los eventos almacenados durante un intervalo de
tiempo (y borrar posteriormente el almacén); también puede ocurrir que los eventos se
pueden ir entregando en forma asíncrona en respuesta a varias activaciones.
63
Análisis de servicios de identificación-localización basados en RFID
7. Arquitectura de Savant
A lo largo del desarrollo del estudio se ha identificado el “Savant” como elemento más
importante de la arquitectura de referencia Auto-ID. Las razones para considerarlo como el
elemento fundamental son dos:
1. realiza y oculta todos los elementos de filtrado de la información sobre las EPC de
forma que esta pieza de la arquitectura es la última y más alta en la cadena de
ejecución que determina si una determinada tarjeta RFID está o no presente en un área
y durante un cierto tiempo,
2. implementa las conexiones con los servidores ONS y con el resto de sistemas de
información en la empresa.
El “Savant” es un sistema de software intermediario (“middleware”) que se ubica entre los
lectores de etiquetas y las aplicaciones empresariales. Pretende cubrir los requisitos especiales
que presentan las aplicaciones de las EPC. Muchos de estos requisitos especiales derivan de la
gran cantidad de datos finamente granulados que se originan de los lectores de etiquetas,
comparados con la granularidad de los datos que las aplicaciones empresariales consumen o
necesitan. Así, se puede considerar el Savant como un adaptador entre ambos tipos de
sistemas, que realiza funciones de reducción de datos tales como filtrado, agregación y
contabilidad. La especificación “Auto-ID Savant Specification 1.0” define el funcionamiento
de este elemento y la interfaz para las aplicaciones empresariales.
Algunas características relevantes del Savant son:
• Arquitectura distribuida. Savant es diferente de la mayoría de los sistemas de software
corporativo en el sentido de que no es una aplicación centralizada. En vez de ello, usa una
arquitectura distribuida y está organizado en una jerarquía que maneja los flujos de datos.
Así, podrá haber Savants ejecutándose en tiendas, centros de distribución, oficinas
regionales, fábricas, incluso quizás en camiones y aviones de carga. En cada nivel,
obtendrá, almacenará y actuará sobre la información, en interacción con otros Savants. Por
ejemplo, un Savant en un tienda podría informar a un centro de distribución que se necesita
más de un producto. Un Savant en el centro de distribución podría informar al Savant en
una tienda que un envío fue despachado en un tiempo específico.
64
Análisis de servicios de identificación-localización basados en RFID
• Corrección de los datos. Los Savants en los extremos de la red –aquellos adjuntos a los
lectores- corregirán los datos. No siempre las etiquetas son leídas correctamente. La
corrección de las lecturas de las etiquetas es una de las funciones de los Savant.
• Coordinación de los lectores. Si las señales de dos lectores se solapan (la situación de
colisión de lectores descrita con anterioridad), éstos pueden leer la misma etiqueta,
produciéndose una duplicidad en los EPC leídos. Una de las funciones de Savant es
analizar las lecturas y eliminar los códigos duplicados.
• Envío de los datos. En cada nivel, el Savant tiene que decidir qué información se envía
hacia arriba o abajo en la cadena. Por ejemplo, un Savant en un almacén para productos en
frío podría enviar datos sólo si se producen cambios en la temperatura de los artículos
almacenados.
• Almacenamiento de los datos. Las bases de datos existentes no pueden manipular más de
unos pocos de cientos de transacciones por segundo, de modo que otro de los objetivos de
los Savants es mantener en memoria una base de datos de eventos en tiempo real (RIED).
En esencia, el sistema tomará los datos EPC que se generan en tiempo real y los
almacenará inteligentemente, de forma que otras aplicaciones empresariales tengan acceso
a la información, pero las bases de datos no se encuentren sobrecargadas.
• Gestión de tareas. Todos los Savants, sin importar su nivel de jerarquía, poseen un sistema
de gestión de tareas (TMS), que los habilita para efectuar la gestión y monitorización de
datos utilizando tareas establecidas. Por ejemplo, un Savant ejecutándose en una tienda
podría ser programado para alertar al gestor del almacén cuando las existencias de un
producto bajen de cierto nivel establecido.
La siguientes figuras muestran la característica de distribución de la red de Savant, siendo la
primera la imagen de distribución física: habrá una jerarquía de Savant distribuidos conforme
la estructura de la empresa en la que se usan, y estando los de más abajo en los lugares físicos
de recolección de los datos EPC, y agrupando datos hacia los Savant de niveles superiores. La
figura de la derecha muestra además esa característica con respecto al tiempo o a la
volatilidad de los datos: los datos se recogen en tiempo real y se mantienen un tiempo corto (3
horas), y van fluyendo en la jerarquía hacia el almacén de datos de más alto nivel que
mantiene datos sobre los ítems durante 2 meses. Recordemos que se trata simplemente de
propuestas en la implementación de referencia y no son normativas.
65
Análisis de servicios de identificación-localización basados en RFID
En lo que sigue, y habiendo identificado la comunidad de desarrollo como prioritario el
avanzar en los Savant de recogida de datos, haremos referencia fundamentalmente a éstos.
ONS
EPC Info
Service
Another
Savant
Other Services
Used by Specific
Processing
Modules
Other
Service
Savant
Reader
Reader
Reader
Interface
User-defined Processing Modules
Processing
Module
Processing
Module
Application
Interface
Enterprise
Application
Enterprise
Application
Standard Processing Modules
Processing
Module
Processing
Module
Processing Module Container
Inter-module interaction
through APIs defined by
specific processing
modules
El Savant está definido en términos de módulos de procesamiento o servicios, cada uno de los
cuales proporciona un conjunto específico de características, que pueden ser combinados por
los usuarios para cubrir las necesidades de su aplicación. La estructura modular está diseñada
para promover la innovación de grupos de desarrollo independientes, evitando de esta forma
la creación de una especificación monolítica que intente satisfacer las necesidades de todos.
66
Análisis de servicios de identificación-localización basados en RFID
Savant puede considerarse también como un contenedor para los módulos de procesamiento.
La figura anterior ilustra los módulos contenidos en Savant.
Los módulos de procesamiento vienen definidos por los estándares de Auto-ID, aunque puede
haber más definidos por los usuarios u otras terceras partes. Los definidos por Auto-ID son
los módulos de procesamiento estándares, de obligatorio cumplimiento por las
implementaciones de Savant.
Existe una implementación de referencia del Savant 1.0, realizada por Auto-ID (pero que no
es pública), que proporciona los módulos obligatorios por la especificación y otros módulos
opcionales. En particular, proporciona un sistema de gestión de eventos (Event Management
System, EMS), un sistema de gestión de tareas (Task Management System, TMS), una base
de datos de eventos en memoria en tiempo real (Real-time In-memory Event Database,
RIED), un mecanismo para la definición de módulos externos (“plug-ins”) para asociar al
EMS y TMS, y un sistema de configuración para especificar la configuración e interconexión
de estos módulos al EMS y TMS.
7.1. Módulos de proceso estándar de Savant
Los módulos de procesamiento estándar tienen comportamientos e interfaces que se
especifican completamente y que deben estar presentes siempre en todas las
implementaciones de Savant.
7.1.1. MPE autoid.core
El MPE autoid.core proporciona un conjunto mínimo de órdenes (mensajes) para la interfaz
de aplicaciones que permite a estas obtener información sobre la identidad de un Savant. Es
un conjunto mínimo que todas las implementaciones de Savant deben soportar.
Mensaje GetSavantID
Una aplicación externa envía un mensaje autoid.core.GetSavantID para pedir a un Savant
su identificador numérico único (con toda probabilidad un código EPC). Los sistemas
compatibles deben obligatoriamente implementar esta orden. Se devuelve una respuesta error
si Savant es incapaz de devolver un código EPC válido.
67
Análisis de servicios de identificación-localización basados en RFID
Orden GetSavantID
Field
Type
-
Descripción
Esta función no toma parámetros
Respuesta normal GetSavantID
Field
Type
Descripción
SavantID
String
Cadena de identificación única del Savant (puede ser un
EPC)
Respuesta error GetSavantID
Field
Type
Descripción
ErrorCode
int
Código de error
ErrorString
String
Descripción del error
Mensaje GetCapabilities
Una aplicación envía un mensaje autoid.core.GetCapabilities para pedir a un Savant la lista
de todos los módulos de procesamiento configurados que gestiona. Los sistemas compatibles
deben implementar esta orden. En la versión actual del estándar, no se exige que la respuesta
contenga la lista de órdenes que soporta un módulo; pero en versiones siguientes el valor que
devuelve esta orden será una estructura que contenga el nombre del módulo, el nombre de la
orden y la versión. Si el Savant no es capaz de devolver un array válido, devuelve el error.
Orden GetCapabilities
Field
Type
None
Descripción
Esta función no toma parámetros.
Respuesta normal GetCapabilities
Field
Type
Descripción
Capabilities
String
Un array de cadenas representando los nombres de los
array
módulos de proceso configurados (como mínimo, los obligados
por el estándar)
Respuesta error GetCapabilities
Field
Type
Descripción
ErrorCode
Int
Código del error
ErrorString
String
Descripción del error
Mensaje Shutdown
68
Análisis de servicios de identificación-localización basados en RFID
Una aplicación externa envía un mensaje autoid.core.Shutdown para informar al Savant que
notifique a todos los subsistemas que finalicen y entonces el módulo de procesamiento
principal también acabará su operación. Los sistemas compatibles deben implementar esta
orden. Se devuelve un error si el Savant es incapaz de informar a todos sus subsistemas que
acaben la operación.
Orden Shutdown
Field
Type
-
Descripción
Esta función no toma parámetros
Respuesta normal Shutdown
Field
Type
Descripción
Shutdown
boolean
Se obtiene valor verdadero si todos los subsistemas fueron
notificados y falso en caso contrario
Respuesta error Shutdown
Field
Type
Descripción
ErrorCode
Int
Error code
ErrorString
String
Descripción del error
Mensaje ResetAll
Una aplicación externa envía un mensaje autoid.core.ResetAll para informar al Savant que
notifique a todos sus subsistemas que se reinicen con sus últimas configuraciones conocidas y
entonces el módulo de procesamiento principal también se reiniciará. Esta orden iniciará un
proceso similar al de arranque en caliente. Los sistemas compatibles deben implementar esta
orden. Se devuelve error si Savant es incapaz de informar a todos los subsistemas que se
reinicien.
Orden ResetAll
Field
Type
-
Descripción
Esta función no toma parámetros
Respuesta normal ResetAll
Field
Type
Descripción
ResetAll
boolean
Verdadero si todos los subsistemas fueron notificados o
69
Análisis de servicios de identificación-localización basados en RFID
Orden ResetAll
Field
Type
Descripción
falso en caso contrario
Respuesta error ResetAll
Field
Type
Descripción
ErrorCode
Int
Error code
ErrorString
String
Descripción del error
7.1.2. MPE autoid.readerproxy
El modulo de procesamiento estándar autoid.readerproxy proporciona un conjunto mínimo
de órdenes para la interfaz de aplicación que permite a las aplicaciones externas obtener la
lista de lectores conectados y configurados para interactuar con Savant y proporcionar un
mecanismo estándar para el paso de órdenes directamente a los lectores individuales. Es un
conjunto mínimo que todas las implementaciones de Savant deben soportar. El modulo de
procesamiento estándar autoid.readerproxy es un modulo de procesamiento estándar
obligatorio.
Mensaje GetReaders
Una aplicación externa envía un mensaje autoid.readerproxy.GetReaders para preguntar al
Savant la identidad de todos los lectores con los que está configurado para comunicarse.
Savant debe obtener todos los lectores que están configurados siguiendo la especificación
ReaderProtocol (versión 1.0 o 1.1). Savant puede devolver la lista de los lectores que se
encuentran conectados con él a través de una forma no estándar, aunque esta forma de
funcionar no es obligatoria. Los sistemas compatibles deben implementar esta orden. Se
devuelve error si Savant es incapaz de devuelver un array de cadenas de identificadores.
Orden GetReaders
Field
Type
-
Descripción
Esta función no toma parámetros
Respuesta normal GetReaders
70
Análisis de servicios de identificación-localización basados en RFID
Orden GetReaders
Field
Type
Descripción
Field
Type
Descripción
Readers
String
Array de cadenas con las identificaciones de los lectores
array
que están configurados para comunicarse con Savant.
Respuesta error GetReaders
Field
Type
Descripción
ErrorCode
int
Error code
ErrorString
String
Description of the error
Mensaje RunCommand
Una aplicación externa envía un mensaje autoid.readerproxy.RunCommand a Savant
como un mecanismo de paso estándar por medio del cual las aplicaciones pueden hacer uso
de todas las órdenes que cualquier lector RFID puede hacer públicos. Los sistemas
compatibles deben implementar esta orden. Se devuelve error si Savant no puede comunicarse
con el lector.
Orden RunCommand
Field
Type
Descripción
ReaderID
String
El ID del lector a quien se destina la orden
Command
String
El nombre de la orden
Arguments
String
El conjunto de argumentos necesarios para ejecutar la
orden en el lector. Podría ser una cadena de longitud
variable separada con comas y con un carácter UTF8 nulo
como
terminación.
La
estructura
detallada
de
los
argumentos se encuentra definida en el “binding” de
Mensaje/Transporte y la especificación Reader Protocol 1.0.
Respuesta normal RunCommand
Field
Type
Descripción
RunCommand
String
La salida del lector con base en la ejecución de la orden. La
respuesta puede ser vacía indicando que no hay respuesta
del lector
Respuesta error RunCommand
Field
Type
Descripción
ErrorCode
int
Error code
71
Análisis de servicios de identificación-localización basados en RFID
Orden RunCommand
Field
Type
ErrorString
String
Descripción
Descripción del error
7.2. Implementación de referencia de Savant Auto-ID
El Auto-ID center ha realizado una implementación de referencia cuya estructura y datos más
relevantes incluimos a continuación, a modo de ilustración sobre las capacidades operativas
básicas de un Savant. Entendemos que esta descripción puede ser de utilidad a la hora de
diseñar sistemas compatibles con la especificación. Por otra parte, es necesario mencionar que
no hemos tenido acceso a esta implementación de referencia (suponemos que sólo los socios
institucionales del Auto-ID han tenido acceso completo a ella), razón por la que la
información incluida en las siguientes secciones se ha recopilado a través de otras fuentes.
La implementación de referencia construida por algunos miembros del Auto-ID Center consta
de cuatro módulos principales, como se puede observar en la siguiente figura, extraída de una
presentación sobre la estructura y experimentos sobre la implementación de referencia.
72
Análisis de servicios de identificación-localización basados en RFID
Se puede observar que en dicha implementación, Savant está compuesto por cuatro módulos
principales:
• Sistema de gestión de eventos (event management system EMS).
• Base de datos en memoria de eventos en tiempo real (real-time in-memory
database RIED).
• Sistema de gestión de tareas (task management system TMS).
• Base de datos relacional.
En posteriores documentos acerca de la implementación de referencia, sin embargo, no se
hace mención explícita de la base de datos relacional, por lo que no detallaremos esta pieza de
la arquitectura.
El sistema de gestión de eventos (EMS) permite a Savant reaccionar ante eventos de tiempo
real como por ejemplo una lectura de un EPC, mediciones de un sensor, lectura de un código
de barras, etc. Tan pronto como se recibe un evento, se procesa por el sistema de gestión de
eventos, y se puede almacenar en la base de datos en memoria de tiempo real (RIED) del
Savant. Esta puede dar acceso a los datos basándose en SQL soportado por un esquema
relacional. Por lo tanto, este almacén de datos se actualiza con cada evento gestionado por el
sistema. De acuerdo a la información obtenida por el sistema de gestión de eventos se pueden
configurar operaciones “por lotes” utilizando el sistema de gestión de tareas (TMS). Por
ejemplo, se pueden configurar como tareas del TMS las operaciones de búsquedas periódicas
de datos PML o el intercambio de datos con sistemas corporativos (ERP Enterprise Resource
Planning).
La siguiente figura muestra una forma de configuración de un servidor Savant que utiliza los
módulos EMS, RIED y TMS. Como se ilustra, los eventos capturados desde un lector son
procesados por colas, filtros y registros de eventos. Después, los eventos se registran por el
sistema de almacenamiento en memoria RIED. Mientras tanto, las tareas gestionadas por el
TMS monitorizan los datos EPC.
73
Análisis de servicios de identificación-localización basados en RFID
7.2.1. Sistema de gestión de eventos (EMS)
El sistema de gestión de eventos (EMS) captura, filtra, distribuye y registra datos EPC. El
EMS debe estar implementado en los Savants que actúan como extremos finales “hojas”
puesto que los datos EPC sólamente entran a la red Savant a través de los nodos inferiores de
una estructura jerárquica. El EMS está compuesto por varias piezas o componentes cuya
operación se muestra en la figura de la siguiente página:
•
Interfaz de lectura. La interfaz de lectura permite que los adaptadores de lectura puedan
comunicar los eventos detectados por los lectores. Los adaptadores de lectura se
comunican directa o indirectamente con los lectores y obtienen información acerca de los
eventos detectados por éstos. El adaptador de lectura, entonces, pasa estos eventos a la
interfaz de lectura.
•
Adaptadores de lectura. Los adaptadores de lectura se comunican con los lectores para
capturar los eventos EPC. Un adaptador de lectura es un productor de eventos que pone a
disposición del cualquier “consumidor de eventos” los eventos leídos.
•
Registro de eventos. Varias implementaciones de la interfaz de lectura, llamadas registros
de eventos (“event loggers”) permiten el procesamiento variado de los eventos. Por
ejemplo, una implementación de la interfaz de lectura puede almacenar la información en
74
Análisis de servicios de identificación-localización basados en RFID
una base de datos, otra almacena los eventos en una estructura de datos en memoria y otra
más, puede distribuir los eventos a servidores remotos sobre protocolos HTTP, JMS o
SOAP. Los registros de eventos pueden llamarse también consumidores de eventos,
puesto que estos consumen el flujo de eventos.
•
Colas de eventos. La cola de eventos es un sistema de colas asíncrono que maneja
múltiples registros de eventos de lectura con implementaciones síncronas. El sistema de
colas captura los eventos leídos por varios adaptadores de lectura y los distribuye a todos
las entidades de registro de eventos de lectura registrados en el sistema. Las entidades de
registro de eventos pueden registrar y eliminar registros de la cola de eventos en tiempo
real. El sistema de colas incrementará la capacidad del sistema usando procesamiento
múltiple. Por ejemplo, una entidad de registros de eventos en una base de datos, que
podría consumir la mayoría de su tiempo en lecturas y escrituras a disco, no reducirá la
velocidad de una entidad de registros de red que envía eventos para lectura a un servidor
remoto. Puesto que las colas de eventos no son productoras ni consumidoras de eventos,
también se les llama “reenviadoras de eventos”.
•
Filtros de eventos. Obtienen los datos de uno o varios flujos de entrada de eventos y
después del filtrado los envían a múltiples flujos de salida. Los filtros de eventos son
usualmente implementaciones síncronas. Pueden añadirse filtros de eventos de forma
intermedia entre los productores de eventos y los consumidores, para efectuar tareas de
75
Análisis de servicios de identificación-localización basados en RFID
eliminación de errores, coordinación y reenvío. La figura 11 esquematiza un filtro de
eventos.
Respecto al rendimiento de la implementación de referencia, es preciso indicar que la
sobrecarga del adaptador de lectura, los filtros de eventos y los entes de registro de eventos
depende fuertemente de sus implementaciones. Por ejemplo, el rendimiento de la base de
datos de una entidad de registro de eventos dependerá del esquema de la base de datos, el
sistema de gestión de bases de datos relacionales usado y de las operaciones realizadas para
registrar cada evento. El manual técnico de Savant se describe el siguiente escenario de
prueba para la prueba de rendimiento realizada sobre el sistema de gestión de eventos:
Servidor DELL PowerEdge 2500 con un procesador Intel Pentium III a 1133 MHz, 512 KB
de memoria caché, 512 MB de RAM y ejecutando Blackdown release Java 1.3.1
(http://www.blackdown.org). La prueba involucraba enviar un millón de eventos por medio
de la cola de eventos con eventos de 100K de tamaño. El ente de registro de eventos
simplemente mantuvo el número de eventos recibidos. La media de ejecución fue de 10.3
microsegundos por evento procesado.
7.2.2. Base de datos en memoria de eventos en tiempo real (RIED)
RIED es una especificación para un sistema de base de datos relacional en memoria en tiempo
real. Los Savant de los extremos inferiores mantienen y organizan los eventos enviados por
los lectores. El EMS proporciona una estructura de soporte para filtrar y registrar los eventos.
Las entidades de registro pueden registrar los eventos en una base de datos. Sin embargo, las
bases de datos no pueden manipular más de unos pocos de cientos de transacciones por
segundo.
76
Análisis de servicios de identificación-localización basados en RFID
Los requisitos que debe satisfacer RIED son:
1. Ser una base de datos en memoria de alta velocidad.
2. Ser una base de datos multi-versión, por ejemplo, ser capaz de mantener múltiples
vistas.
RIED proporciona la misma interfaz que una base de datos pero ofrece mucho mejor
rendimiento (velocidad). RIED mantiene una o más vistas de la base de datos. La última vista
es la imagen actualizada de la base de datos. Otras vistas son imágenes de sólo-lectura de la
base de datos. El mantenimiento de vistas anteriores puede ser útil en aplicaciones tales como
la realización de inventarios. Estas aplicaciones pueden ejecutarse con vista de sólo-lectura
sin afectar al rendimiento de las actualizaciones de los eventos.
En la implementación de referencia se ha hecho uso de la interfaz Java Data Base
Connectivity (JDBC) para presentar información contenida en la RIED con el aspecto de ser
una base de datos relacional. Esta interfaz estándar permite a una máquina remota acceder a
una base de datos utilizando consultas SQL estándar y localizar la base de datos utilizando
URL estándares. La implementación de referencia de RIED soporta operaciones SQL tales
como SELECT, UPDATE, INSERT y DELETE. La implementación de referencia de RIED
soporta un subconjunto de operaciones de manipulación de datos definido en SQL92. Sin
embargo, y debido al requisito de velocidad que debe de cumplir el RIED, se han realizado
algunas simplificaciones:
1. Reducción de la complejidad del lenguaje de manipulación de datos. Los sistemas de
gestión de bases de datos basados en disco cargan una cantidad significativa de lógica
para proporcionar compatibilidad con versiones previas de SQL. El modelo RIED no
implementa estas características obsoletas.
2. Reducción de la complejidad del lenguaje de definición de datos. Los sistemas de
gestión de bases de datos relacionales típicos permiten cambios a la base de datos
durante la ejecución. Para simplificar el diseño, RIED no permite operaciones ALTER
sobre la base de datos durante su ejecución. Las estructuras de las tablas se cargan de
de un fichero DDL (Data Definition Language) durante su arranque.
77
Análisis de servicios de identificación-localización basados en RFID
3. Soporte eficiente sólo para uniones simples. Los índices basados en árboles B
soportan la búsqueda y operaciones de unión basados en operaciones “<” y “>”. RIED
sólo efectúa de forma eficiente las búsquedas “=” y las uniones simples.
4. Optimización de consulta simple. Las bases de datos típicas tienen rutinas
complicadas de optimización de consultas. Determinar el orden en el cual las uniones
tienen que efectuarse es el problema más difícil en la optimización de consultas.
Algunas bases de datos, como PostgreSQL, usan algoritmos genéricos para optimizar
las consultas. RIED espera que el usuario determine el orden de unión explícitamente
en la cláusula FROM de las consultas, y no realiza optimizaciones.
5. No se mantienen las restricciones. Las restricciones, como por ejemplo la verificación
de claves foráneas, deben ser evaluadas para cada operación de actualización. RIED
no soporta el mantenimiento de las restricciones por encontrarse un mecanismo que
impone una gran sobrecarga en ejecución.
RIED mantiene varias copias de los datos recibidos de los lectores; cada operación de
actualización a la base de datos (INSERT, DELETE, UPDATE) incrementa el número de
secuencia y crea una nueva copia de los datos en la base de datos.
Respecto al rendimiento de la implementación de referencia, de nuevo hay que recordar que la
sobrecarga del modelo de memoria RIED depende del tipo de esquema y las operaciones
efectuadas para registrar cada evento. Se han documentado pruebas con el mismo escenario
mencionado en el caso del EMS, más una base de datos persistente PostgreSQL 7.0.2. La
prueba a la base de datos involucraba el envío de eventos de 100K al ente de registro de la
base de datos, con ésta previamente cargara con eventos de 200K. El sistema tomó 10.0
milisegundos para registrar cada evento. Todos los eventos fueron registrados en la tabla de
observaciones. Como guía en la construcción de las tablas de la base de datos, se incluyen los
esquemas utilizados en dicha prueba.
78
Análisis de servicios de identificación-localización basados en RFID
CREATE TABLE object (
epc VARCHAR(500),
last_observation_id NUMERIC(10),
PRIMARY KEY (epc)
);
CREATE TABLE observation (
observation_id NUMERIC(10),
reader_epc VARCHAR(500),
timestamp NUMERIC(20),
epc VARCHAR(500),
PRIMARY KEY (observation_id),
FOREIGN KEY (epc) REFERENCES object(epc)
);
Una segunda prueba de la base de datos en memoria se realizó con el envío de un millón de
eventos a un ente de registro de base de datos en memoria. El sistema tomó 66.5
microsegundos para registrar cada evento. Todos los eventos fueron registrados en la tabla
latest_epc_observation. Este ente de registro funciona “eliminando errores” por medio de la
asociación de cada objeto EPC a exactamente un lector EPC. Cualquier lectura de un lector
diferente se registra sólamente si la última entrada de tiempo para ese EPC difiere en más de 2
segundos. El esquema para la base de datos RIED se lista a continuación:
CREATE TABLE latest_epc_observation (
epc VARCHAR(100) PRIMARY KEY,
reader_epc VARCHAR(100) INDEX,
timestamp NUMERIC(20)
);
La base de datos en memoria mejora el rendimiento de Savant en un orden de 2 a 3 incluso
después de la eliminación de errores de las lecturas recibidas.
79
Análisis de servicios de identificación-localización basados en RFID
7.2.3. Sistema de gestión de tareas (TMS)
Savant efectúa la gestión y monitorización de datos utilizando tareas configurables. El sistema
de gestión de tareas (Task Management System TMS) maneja las tareas de igual forma que el
sistema operativo maneja los procesos.
La arquitectura del TMS contenida en la implementación de referencia se basa en estándares y
tecnologías abiertas tales como Java, XML y SOAP. La siguiente figura representa la
arquitectura TMS.
Las principales componentes del sistema son:
1. Gestor de tareas. El gestor de tareas es el responsable de ejecutar y mantener
ejecutándose las tareas de un Savant. Cada tarea dada al sistema consiste de un
controlador de programa, que determina el patrón de ejecución de la tarea.
Dependiendo del programa, el gestor de tareas intenta determinar cual tarea ejecutar
en cada momento. Conforme a los requisitos del gestor de tareas y basándose en el
tipo y programa asociado con la tarea, el gestor se comporta como sigue:
1. Tarea de una sola vez, en las que el gestor de tareas inicia la tarea de consulta y
devuelve el resultado.
2. Tarea recurrente, en la que el gestor de tareas envía el programa a almacenamiento
persistente y entonces ejecuta la tarea de acuerdo al programa.
3. Tarea permanente. Es una tarea que debe estar ejecutándose continuamente, bajo
monitorización periódica del gestor de tareas. Si ocurre un fallo, el gestor de tareas
simplemente reinicia la tarea.
2. Interfaz SOAP. La función del servidor SOAP es hacer pública la funcionalidad e
interfaz del gestor de tareas como un servicio SOAP que puede ser accedido
80
Análisis de servicios de identificación-localización basados en RFID
uniformemente por todos los sistemas externos, basándose en un descriptor de
despliegue público que detalla los métodos a los que se puede acceder externamente.
3. Servidor de clases. Para habilitar la carga dinámica de tareas al sistema, el gestor de
tareas apunta a un servidor de clases para cargar nuevas clases bajo demanda en
cuanto se encuentran disponibles. Esto permite una fácil actualización y modificación
de las tareas del sistema sin necesidad de reiniciar. En este punto, indicar que
tecnologías en reciente desarrollo y normalización como OSGi pueden proporcionar
un buen soporte al proceso de carga dinámica y evolución del sistema durante su
ejecución.
4. Base de datos. Esta base de datos especializada proporciona un almacenamiento
persistente al gestor de tareas, en la cual se almacenan los detalles acerca de las tareas
iniciadas y sus respectivos programas. En caso de fallo del gestor, es posible reiniciar
el sistema en una situación muy parecida a la que tenía cuando falló y continuar su
operación. En cada ciclo, el gestor de tareas consulta la base de datos acerca de las
tareas y actualiza los registros asociados que correspondan. Indicar de nuevo que este
tipo de problemas se vería resuelto con entornos de operación como los mencionados
anteriormente (OSGi).
El sistema de gestión de tareas proporciona dos interfaces:
• la interfaz administrativa. Se trata de un conjunto de páginas que permiten la
administración y monitorización remota del gestor. Usando esta interfaz, un
administrador puede iniciar o detener el gestor, y añadir, borrar u observar las tareas
existentes.
• la interfaz del sistema. Esta interfaz permite que terceras partes interactúen con el
sistema vía mensajes SOAP. Toda entidad externa que desee comunicarse con el
sistema debe registrar un adaptador (o servidor) que procese las peticiones que vengan
de la entidad y los envíe al gestor de tareas. De nuevo, la comunicación se realiza vía
mensajes SOAP.
81
Análisis de servicios de identificación-localización basados en RFID
8. Object Name Server (ONS)
La visión del Auto-ID Center de una red global y abierta para la identificación y localización
requiere de una arquitectura de red especial. Puesto que en la etiqueta sólo se almacena el
código EPC, los ordenadores necesitan alguna manera de establecer la correspondencia del
EPC con la información del artículo asociado. Éste es el rol del servicio de nombres de
objetos (ONS, Object Name Service), un servicio de red automatizado similar al servicio de
nombres de dominio (DNS), que mantiene la correspondencia entre los nombres de dominio
de Internet y las direcciones IP, dirigiendo a los ordenadores hacia los sitios correspondientes
en la World Wide Web, por ejemplo. Cuando un lector lee una etiqueta RFID, pasa el EPC a
un Savant. El Savant puede a su vez, ir a un ONS en la red local o Internet para encontrar
donde está almacenada la información del producto al que está asociado el EPC de la etiqueta.
ONS dirige a Savant hacia el servidor donde se almacena un fichero acerca del producto. Ese
fichero puede ser recuperado por el Savant y la información acerca del producto en el fichero
puede ser enviada al inventario de la empresa o a las aplicaciones de la cadena de valor.
En caso de hacerse realidad el escenario de uso masivo de la tecnología RFID, el servicio de
nombres de objetos llegará a manejar muchas más peticiones que el DNS. Las empresas
necesitarán mantener servidores ONS locales para almacenar información de recuperación
rápida. El sistema también debe ser capaz de funcionar ante caídas mediante la redundancia
de datos. Por ejemplo, si un servidor con información de un cierto producto se cae o falla, el
ONS deberá ser capaz de dirigir al Savant a otro servidor donde se encuentre almacenada la
misma información. Así, la especificación de referencia del ONS ayuda a los lectores a
localizar los servicios de red capaces de proporcionar información descriptiva sobre los
objetos asociados a las tarjetas RFID cuyos EPC son recibidos por el lector.
8.1. Arquitectura del ONS
En la actualidad el servicio ONS se usa para localizar servidores PML asociados con un EPC.
Un servidor PML es un servidor Web simple que ofrece información acerca de un objeto o
producto en lenguaje PML. El proceso típico de localización se muestra en la siguiente figura.
82
Análisis de servicios de identificación-localización basados en RFID
El espacio de nombres EPC se asigna jerárquicamente para una fácil gestión, como ya se ha
descrito en la sección correspondiente. En general, un EPC contiene campos para el número
de versión, identificación del fabricante, identificación del producto (éste código lo asigna el
fabricante) e identificación de la serie (número de serie del producto, también asignado por el
fabricante). Cada versión de EPC define las longitudes en bits del identificador del fabricante,
identificador del producto y número de serie.
La autoridad del espacio de nombres (posiblemente una organización de soporte de estándares
como el Auto-ID Center) asignará a los fabricantes un identificador único. Los fabricantes
pueden, de forma independiente, asignar identificador únicos a sus productos para que luego
los departamentos relacionados con aspectos específicos de los productos asignen números de
serie únicos a los objetos-productos.
La información de correspondencia código EPC-dirección del servidor de descripción en el
ONS debe de organizarse también de forma jerárquica involucrando a las autoridades de
espacio de nombres, los fabricantes y los departamentos específicos de los productos. Así se
obtienen los siguientes requisitos:
1. La estructura de referencia ONS debe permitir la gestión jerárquica de la información
de correspondencia.
2. La estructura de referencia ONS debe permitir que se mantenga en “caché” la
información de correspondencia que guardan los servidores ONS.
3. Se debe permitir la existencia de servidores ONS redundantes que almacenen
información de correspondencia.
83
Análisis de servicios de identificación-localización basados en RFID
4. Se debe permitir que los EPCs sean asociados a servidores PML redundantes.
5. La estructura de referencia ONS debe permitir la adición de versiones nuevas de EPC
sin cambios a sus componentes software o hardware.
La arquitectura del ONS es una estructura distribuida sobre Internet, que consta de:
• Información de correspondencia. Esta información está distribuida jerárquicamente a
través de los servidores ONS. La información está almacenada en registros que
expresan la correspondencia entre un rango de EPCs y un servidor PML.
• Servidores ONS. Estos son los servidores que responden a las consultas que piden la
dirección IP de los servidores PML asociados con un EPC. Cada servidor mantiene su
información de correspondencia completa para rangos de EPCs, e información en
caché que pertenece a otros EPCs.
• Resolutor o “resolver” ONS. Un resolutor envía peticiones a los servidores ONS para
obtener la localización de red de los servidores PML.
8.2. Operación del ONS
La siguiente figura representa los pasos involucrados en una consulta típica al ONS.
Dado el supuesto de que la arquitectura puede hacer uso de los estándares e infraestructura
existente en Internet, el ONS usa el Sistema de Nombres de Dominio (DNS) para la búsqueda
(resolución) de información acerca de un EPC. Esto significa que los formatos de consulta y
respuesta deben adherirse a los estándares del DNS, significando esto que el EPC debe ser
convertido en un nombre de dominio y que los resultados deben de poderse almacenar en
algún registro DNS válido. La secuencia de operaciones de uso del ONS puede observarse en
el siguiente ejemplo:
1. Se lee una secuencia de bits conteniendo un EPC de una etiqueta RFID
84
Análisis de servicios de identificación-localización basados en RFID
01 000000000000000000010 00000000000011000 000000000000000110010000
2. El lector de etiquetas envía la secuencia de bits a un servidor local
01 000000000000000000010 00000000000011000 000000000000000110010000
3. Dicho servidor local convierte la secuencia de bits en la forma URI y la envía al
resolutor “resolver” ONS local
urn:epc:1.2.24.400
4. El resolver convierte el URI a un nombre de dominio e inicia una consulta DNS para
los registros NAPTR para ese dominio
24.2.1.onsroot.org
5. La infraestructura DNS devuelve una serie de respuestas que contienen URLs que
apuntan a uno o más servicios. El resolver local elige el URL del registro DNS y lo
presenta de retorno al servidor local
http://pml.example.com/pml-wsdl.xml
6. El servidor local contacta con el servidor PML encontrado en el URL conforme al
EPC.
El ONS, tal como se especifica en este ejemplo, toma un EPC como entrada. Se asume que el
EPC está en formato URI (por ejemplo, urn:epc:1.2.24.400), que es el utilizado por casi todo
los elementos de la arquitectura del Auto-ID Center.
Para consultar al DNS con un EPC, la forma del URI especificado debe convertirse a la forma
nombre de dominio, lo que se consigue mediante estos pasos:
1. Eliminar el encabezado 'urn:epc:' (quedando 1.2.24.400).
2. Eliminar el campo número de serie (quedando 1.2.24).
3. Invertir el orden de los campos resultantes (quedando 24.2.1).
4. Añadir '.onsroot.org' (finalizando como 24.2.1.onsroot.org)
El resolver DNS de la aplicación cliente consulta los registros DNS tipo código 35 (NAPTR).
No hay un API “resolver” DNS estándar, así que el método exacto para esta consulta depende
de la biblioteca de resolución DNS que se use.
85
Análisis de servicios de identificación-localización basados en RFID
Los resultados de la consulta vendrán en forma de uno o más registros NAPTR. Los
contenidos actuales de los registros DNS tienen el siguiente formato:
El campo orden se usa para asegurar que los registros NAPTR se interpretan en el orden
correcto puesto que el DNS no garantiza el orden de los resultados si hay varios. Puesto que
todos los registros de un conjunto de resultados son válidos para el EPC en cuestión, el único
efecto que tiene un valor de orden es indicar la equivalencia de algunos subgrupos de los
registros, de forma que la aplicación puede elegir el que desee; se logra así un mecanismo
primitivo de equilibrado de carga.
Por ejemplo, si hay 4 registros y los tres primeros registros tienen un orden de “0” mientras el
último tiene un orden de “1”, entonces los tres primeros son considerados equivalentes. Si
aquellos tres registros tienen también los mismos valores de “pref” y “Service” entonces es
válido escoger al azar entre los tres. Si los valores “pref” son diferentes pero los “Services”
son los mismos, entonces el valor “pref” se usa para indicar preferencia. Los registros con un
número menor deben ser procesados antes que aquellos con números mayores. El campo
“Services” es importante en este proceso puesto que las aplicaciones necesitarán considerar
sólamente aquellos registros que tengan servicios en los que estén interesados.
El campo “flags” contiene un valor “u” para indicar que el campo “regexp” contiene un URI.
El campo “service” contiene un indicador del tipo de servicio que se encontrará en el URI en
cuestión. Esta característica permite al servicio ONS indicar múltiples puntos de servicio para
múltiples clases de servicio. El campo “replacement” no se usa por el Auto-ID pero ya que es
un campo DNS especial su valor es “.”.
”Services” es particularmente importante ya que se usa para crear “clases” de servidores,
registrados ante alguna autoridad. Pueden utilizarse para especificar servicios muy ligeros tal
como un “obtener información elemental acerca de este producto”, o servicios mucho más
86
Análisis de servicios de identificación-localización basados en RFID
complejos. En el ejemplo, la parte “EPC” se usa para diferenciar este registro de otros
posibles registros NAPTR. La porción “pml” se usa para designar la clase de servicio.
El campo “regexp” es una Expresión Regular Extendida Posix. Esta forma establece que el
primer carácter encontrado es el delimitador de campo entre la expresión regular y la porción
de reemplazo de la expresión entera re-escrita. En el ejemplo de arriba el delimitador es “!”.
La porción de expresión regular es '^.*$' que corresponde a “cualquier cosa”. La porción de
reemplazo es 'http://company.com/cgi-bin/pmlservice'. La elección de '!' como el delimitador
en lugar de uno más tradicional como '/' hace que la línea entera sea mucho más fácil de leer y
menos propensa a errores.
El campo ”regexp” se usa para especificar un URI para el servicio. En los primeros prototipos
del ONS se realizaron experiencias con direcciones IP directas, pero pronto se mostró
insuficiente debido a las necesidades de protocolos como SOAP, que se despliegan sobre
HTTP. La razón por la cual el campo está en forma de una expresión regular es que los
registros NAPTR
también
los usan
otras
aplicaciones
que
necesitan
reescribir
condicionalmente el URI para incluir otra información. El ejemplo no hace uso de esta
característica, pero no está claro si siempre va a ser así. En el futuro podría ser necesario
permitir expresiones regulares completas y funciones de sustitución dentro de este campo.
Es importante notar que la versión 1.0 de la especificación ONS no consulta el EPC por
completo: la consulta se detiene al nivel de producto. Se deben resolver posteriormente las
consultas acerca de un número de serie, utilizando para ello el servidor de aplicaciones
designado por los resultados del ONS. La capacidad para realizar consultas al ONS con el
número de serie, así como la arquitectura y el impacto económico de esa capacidad es un
aspecto abierto que debe solucionarse en las siguientes versiones, por ahora, queda fuera de la
especificación y ser resolverá de forma particular en cada caso y por cada fabricante.
87
Análisis de servicios de identificación-localización basados en RFID
9. Servidor de información EPC y Physical Mark-up
Language (PML)
La “Auto-ID EPC Information Service Specification 1.0” define el protocolo para acceder al
servicio de información EPC. Este servicio permite que los datos relacionados con los
elementos a los que se asocia un EPC (una etiqueta RFID) se encuentren disponibles en un
formato especial (Physical Mark-up Language o lenguaje de marcado físico, PML) para los
servicios que así lo requieran. El servicio de información es el punto de consulta para las
aplicaciones externas que necesitan consultar información sobre las EPC.
Los datos disponibles a través del servicio de información EPC pueden incluir: los datos
leídos de las etiquetas y recolectados por Savant (por ejemplo, para permitir el seguimiento de
un objeto en su recorrido en la cadena de valor), incluyendo los datos proporcionados por
etiquetas “avanzadas” con sensores asociados; datos del objeto como la fecha de fabricación,
fecha de caducidad, etc; y datos del tipo de objeto, como la información de catálogo de
producto. El servicio de información EPC puede usar una gran variedad de fuentes de datos
que existen dentro de una empresa, y trasladar esos datos al formato PML. Es posible incluso
crear un registro de formas de acceder (interfaces de acceso) al servicio de información EPC,
como se puede observar en la siguiente figura.
El lenguaje de marcado físico (PML) es una colección de vocabularios XML estandarizados
para representar y distribuir información relacionada con los objetos en la red EPC. PML
proporciona un formato estandarizado para el intercambio de los datos capturados por los
88
Análisis de servicios de identificación-localización basados en RFID
sensores en la infraestructura Auto-ID (los lectores RFID), y también formato para el
contenido de los demás mensajes intercambiados dentro de la red. La “Auto-ID PML Core
Specification 1.0” define la sintaxis y semántica fundamental del PML. Existen varios
trabajos de extensión de PML para alinearse con otros estándares conocidos, como el Buró
Internacional de Pesos y Medidas (Le Sistème International d’Unités – SI) y el Instituto
Nacional de Estándares y Tecnología en los Estados Unidos.
El núcleo del PML PML-core consiste en un conjunto de esquemas que definen el formato de
intercambio para la transmisión de los valores de los datos capturados. Estas entidades de
datos pueden ser accedidas directamente desde el sensor o desde el Savant o el servicio de
información EPC que distribuye los datos capturados. PML-core permite manejar propiedades
físicas y entidades que son capaces de ser observadas o medidas por un sensor.
Además de la información invariable del producto (como el material de composición), PML
permite incluir datos que cambian constantemente (datos dinámicos) y datos que cambian en
el tiempo (datos temporales). Ejemplos de datos dinámicos PML pueden ser la temperatura de
un envío de frutas, o los niveles de vibración de una máquina. Los datos temporales cambian
discretamente e intermitentemente durante la vida de un objeto; un ejemplo es la localización
de un objeto. Al estar disponible toda esta información en una descripción PML de formato
estándar y abierto, es posible pensar en nuevas formas de utilizar la información; por ejemplo,
bajar automáticamente el precio de un producto según se acerque la fecha de caducidad; o
terceras partes, como proveedores de logística, podrían ofrecer contratos a nivel de servicio
indicando que los bienes serán almacenados a cierta temperatura en el transporte.
El vocabulario PML-Core proporciona los tipos de datos para las comunicaciones entre:
• Un Savant o un servidor (o servicio) de información EPC y una aplicación externa.
• Savants de recogida de información de lectores y Savants de agregación.
• Un sensor (como los lectores RFID) y un Savant.
Como PML-core es un subconjunto de PML, sus esquemas siguen la metodología de diseño
de PML. Las especificaciones proporcionan la nomenclatura, los principios de diseño y las
buenas prácticas para el desarrollo del esquema PML-core. PML usa el lenguaje de esquemas
89
Análisis de servicios de identificación-localización basados en RFID
W3C XML (XSD) como meta lenguaje para la definición de su esquema. En vez de
reinventar una nueva metodología de diseño XML propia, PML hace uso para su diseño de
una metodología de diseño existente y bien definida por RosettaNet y definida en las
siguientes especificaciones:
1. Estructuras Universales (UST).
2. Guía de diseño XML (XMLDG).
3. Gestión y especificación de espacio de nombres (NSSM).
El diseño de PML-Core ha seguido varias líneas de trabajo que merece la pena mencionar:
• Reutilización de estándares ya emitidos para entidades individuales como fechas y tiempo,
y también para la elección de nombres y reglas de diseño. Con ello se intenta aumentar la
velocidad de adopción, fomentar la interoperabilidad y facilitar el mantenimiento a largo
plazo.
• Formalidad de manera que el lenguaje esté definido y pueda ser comprobado y validado.
• Simplicidad para facilitar la introducción del lenguaje, rehuyendo de características
complicadas y que resuelven pocos casos.
• Independencia del protocolo de transporte.
• Legibilidad por humanos para mejorar la curva de aprendizaje y simplificar los procesos de
depuración.
• Disponibilidad de herramientas para validación frente al esquema y facilidades de autor.
Una parte del PML-Core es el PML-Core-modelo de datos de sensores, que describimos con
más detalle a continuación. Los componentes básicos de PML-Core-modelo de datos son: los
sensores, capaces de tomar medidas de entidades y propiedades físicas (un lector RFID es un
ejemplo de sensor); las observaciones que representan las medidas de los sensores; y las
propiedades observables, que son las propiedades físicas y entidades capaces de ser
observadas.
90
Análisis de servicios de identificación-localización basados en RFID
La figura anterior muestra las entidades fundamentales, que mencionamos brevemente a
continuación:
• Sensor: contiene un identificador y uno o más elementos Observación. Este elemento
representa un dispositivo que captura información. El tipo de identificador por defecto es el
EPC.
• Observación: contiene datos resultado de una medida por un sensor particular. Cada
observación debe venir etiquetada con su fecha y hora, pudiendo además llevar un
identificador único y una referencia al tipo de orden que se envió para realizar la
observación. Cada observación consta de: un elemento identificador opcional, un elemento
orden opcional, fecha y hora, cero o más elementos de datos, y cero o más elementos
etiqueta.
• Dato: representa la medida de un sensor sobre una propiedad o entidad, excepto que pueda
ser representada como etiqueta. Permite representar datos no estructurados o datos con
estructura XML. Es una elección entre elementos de texto, binario o XML.
91
Análisis de servicios de identificación-localización basados en RFID
• Etiqueta: es un valor de observación especial, cualquier dispositivo capaz de ser detectado
por un sensor (una etiqueta RFID, por ejemplo). Contiene un valor identificador, un
elemento opcional de datos, y cero o más sensores.
• Identificador: contiene un identificador de esquema (EPC por defecto) opcional, un
identificador de la agencia del esquema opcional, identificador de versión del esquema
opcional, y opcional esquema URI.
El siguente ejemplo muestra el fichero PML correspondiente al caso de varias etiquetas leídas
por un lector RFID.
<?xml version="1.0" encoding="UTF-8"?>
<pmlcore:Sensor xmlns:pmlcore="urn:autoid:specification:interchange:PMLCore:xml:schema:1"
xmlns:pmluid="urn:autoid:specification:universal:Identifier:xml:schema:1"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation="urn:autoid:specification:interchange:PMLCore:xml:schema:1
../SchemaFiles/Interchange/PMLCore.xsd">
<pmluid:ID>urn:epc:1:4.16.36</pmluid:ID>
<pmlcore:Observation>
<pmluid:ID>00000001</pmluid:ID>
<pmlcore:DateTime>2002-11-06T13:04:34-06:00</pmlcore:DateTime>
<pmlcore:Command>READ_PALLET_TAGS_ONLY</pmlcore:Command>
<pmlcore:Tag>
<pmluid:ID>urn:epc:1:2.24.400</pmluid:ID>
</pmlcore:Tag>
<pmlcore:Tag>
<pmluid:ID>urn:epc:1:2.24.401</pmluid:ID>
</pmlcore:Tag>
<pmlcore:Tag>
<pmluid:ID>urn:epc:1:2.24.402</pmluid:ID>
</pmlcore:Tag>
</pmlcore:Observation>
</pmlcore:Sensor>
92
Análisis de servicios de identificación-localización basados en RFID
10. Evaluación de la tecnología
A continuación realizamos un breve análisis de la tecnología y sistemas disponibles, desde
varios puntos de vista; en algunos casos se trata de recopilación de material bibliográfico, en
otros se trata de una valoración del grupo de trabajo.
10.1. Coste
La estimación de costes es una pieza fundamental para la adopción de la tecnología. En
principio podríamos distinguir dos tipos de costes: los de despliegue de las instalaciones y los
de operación. Dado que los primeros parecen ser muy superiores a los segundos, y que
obviamente sólo se incurre en costes de operación una vez desplegada la tecnología, la
atención de los analistas va en la primera dirección.
Para tener una idea del coste que representa desplegar una red global EPC se puede tomar
como referencia el análisis hecho en el artículo “El retorno de la inversión de la invasión de la
privacidad” de la AIM global Network en donde se hacen las siguientes deducciones sobre un
escenario hipotético (basado en la seguridad, y en escenarios de ventas, fundamentalmente):
Conforme al censo del año 2000 en los EE.UU. había 45,115 plazas y centros comerciales,
bajo el supuesto de que cada plaza o centro comercial tiene 6 entradas con cuatro puertas
dobles por entrada, hay un total de 24 puertas por plaza o centro comercial. Suponiendo que
se colocan lectores sólo en las entradas los costes serían:
• Antenas: 2 por cada puerta doble, 1,500$ por antena implica 3,000$ por puerta.
• Lectores: Estos tendrían que leer múltiples frecuencias incluso con altos volúmenes de
etiquetas, 400$ cada lector, con 4 antenas por lector, pero corregido por las posiciones de
las puertas da como resultado un coste de 200$ por puerta.
La estimación por puerta es de 3,200$. El cálculo final es: 45,115 lugares, donde cada lugar
tiene 24 puertas y cada puerta tiene un coste de 3,200$ es igual a 3,464,832,000$, un coste
exhorbitado para tan solo colocar lectores en todas las entradas de las plazas y centros
93
Análisis de servicios de identificación-localización basados en RFID
comerciales. No se incluyen los costes de red, ordenadores, bases de datos, hardware de red
inalámbrica, comunicaciones, costes de instalación ni programación.
Los autores del estudio añaden que, tratándose de una red global, se tendrían que cablear los
aeropuertos, estaciones de trenes y autobuses, oficinas gubernamentales, oficinas postales,
bibliotecas, escuelas, centros de recreación, parques, tiendas, bares, iglesias, etc. Los autores
indican que “el coste de crear una red de espionaje nacional junto con sus costes asociados
podría ser un número que ni siquiera Carl Sagan podría pronunciar, pero sólo por poner un
número, podría ser más de 1,000,000,000,000$”.
Con dicho estudio en la mano, la conclusión con respecto a la implantación de RFID sería
claramente negativa. El estudio es incompleto: no menciona los costes de las etiquetas,
aunque da una buena indicación de que para que la tecnología sea implantable no sólo éstas
deben de mejorarse y abaratarse, también las antenas. Por otra parte, la implantación no tiene
por qué producirse instantáneamente, y se prevé la aparición de “islas” RFID para los
artículos o elementos en los que su coste sea aceptable frente al coste del producto.
10.2. Escalabilidad y rendimiento
Los fabricantes de RFID ofrecen productos con un rendimiento inmejorable; pero no suelen
ser los productos de gama media (y de coste razonable, por tanto). Dentro de los factores que
determinan el rendimiento se encuentran:
• La sensibilidad de la etiqueta. La habilidad de una etiqueta para tomar la energía y
maximizar el poder de la señal para enviar de retorno sus identificadores al lector. A mayor
sensibilidad una etiqueta, mayor rango de lectura.
• Tamaño de la etiqueta. Una etiqueta más grande por lo general significa un rango más
grande.
• Forma de la etiqueta. Las diferentes formas de las antenas de las etiquetas proporcionan
marcadas diferencias en los niveles de rendimiento.
• Número de antenas de etiqueta adjuntas al chip. Dos antenas en distintos polos adjuntas a
un solo chip resulta en un rendimiento de la etiqueta que es menos sensible a la
orientación, lo cual es importante para ambientes de lecturas aleatorias.
94
Análisis de servicios de identificación-localización basados en RFID
• Velocidad. La tasa a la cual un lector captura los identificadores de las etiquetas. Las tasas
de lectura rápidas (1) incrementan la confianza en las lecturas de etiquetas, y (2) se espera
que den menos problemas a los procesos del negocio. Las etiquetas RFID disponibles hoy
en día tienen tasas de lectura que van desde 20 etiquetas por segundo hasta 1000 etiquetas
por segundo.
• Apilado de las etiquetas. Cuando la densidad de etiquetas es muy alta, pueden interferir
unas con otras. Hay una variación muy amplia en el rendimiento de las etiquetas en
ambientes muy densos. La mejor efectividad de las etiquetas a la fecha es cuando se
encuentran alejadas al menos un centímetro una de otra.
• Interferencia. Los lectores y las etiquetas bien diseñadas funcionan efectivamente en
ambientes de radio frecuencia ruidosos.
• Empaquetado. La forma en que las etiquetas se empaquetan y unen a los productos tiene
influencia sobre los rangos de lectura y durabilidad. Ejemplos de empaquetado de etiquetas
incluyen: envolturas de plástico, formas delgadas y alargadas, superficies metalizadas, etc.
10.3. Viabilidad del uso
Los materiales de metal y acuosos son hostiles a RFID, por ejemplo los productos basados en
agua como el champú o las bebidas pueden comprometer el rendimiento de la etiqueta
reduciendo los rangos de lectura cerca del 50%. Con todo, es un problema que puede tener
solución, añadiendo material intermedio entre la etiqueta y el producto, lo cual mejora
bastante el rendimiento. Los materiales más “amistosos” son las tarjetas, la ropa y el plástico
(lo que explica que algunos de los primeros proyectos piloto se hayan realizado en el ámbito
textil).
Debido a los efectos negativos de los ambientes severos y los materiales sobre la tecnología
RFID es importante que el sistema se diseñe con márgenes de maniobra con respecto al rango
de lectura y la velocidad de recolección.
95
Análisis de servicios de identificación-localización basados en RFID
10.4. Privacidad y propiedad de la información
Ha surgido un movimiento fuerte y creciente opuesto al etiquetado RFID basado en el miedo
al supuesto de que se puedan capturar las trazas de todas las compras y todos los movimientos
por medio de etiquetas RFID en los zapatos o en la ropa. Mientras que estos miedos pueden
ser infundados (por ejemplo, los ladrones que son capaces de circular cerca de una casa y leer
todas las etiquetas EPC en los artículos, el gobierno capaz de tener la traza de todos los
movimientos de una persona o el informe del frigorífico para conocer los hábitos de compra
del propietario), hay algunos aspectos legítimos expresados por los oponentes al etiquetado
RFID.
El grupo CASPIAN -- Consumers Against Supermarket Privacy Invasion And Numbering -ha enviado escritos al Congreso y Senado de los EE.UU. para convertir en ley una orden que
para hacer públicos los productos que contengan chips RFID. La propuesta de legislación para
regular el etiquetado de los productos con RFID y para proteger la privacidad del consumidor,
tiene como finalidad proteger a los consumidores en contra de la compra de productos con
dispositivos de vigilancia empotrados. El grupo se encuentra actualmente buscando un
patrocinador.
A menos que los datos de los clientes se encuentren encriptados y disponibles sólo para la
tienda que ha escrito la etiqueta, el número de cliente en varios establecimientos puede estar
disponible para espías casuales. Una recomendación es que no exista ligadura entre los datos
de identificación de un cliente y cualquier otro dato escrito en la etiqueta, a menos que exista
consentimiento. Aunque se piensa que estas medidas no serán suficientes para aplacar a los
grupos opositores al etiquetado RFID.
Otro de los aspectos por los que los opositores no aceptan el etiquetado es que no logran
percibir los beneficios que tendrá el cliente. Según ellos quien realmente se beneficia es la
parte vendedora. Dentro de las propuestas para mejorar las etiquetas RFID hay una orden
“kill” que deshabilitará permanentemente la etiqueta de modo que ya no pueda ser leída. Los
grupos de defensa de la privacidad desean que todas las etiquetas sean deshabilitadas por
defecto en el momento de la compra a menos de que el cliente esté de acuerdo en dejarla
activa.
96
Análisis de servicios de identificación-localización basados en RFID
Mientras esto pueda ser visto como una concesión a la defensa de la privacidad, también
puede ser una necesidad en los estados actuales de la implementación. Más adelante, con
tecnología más madura, las etiquetas podrían dejarse activas en los productos donde se espere
se perciba un beneficio no sólo para el fabricante o vendedor sino también para el
consumidor.
10.5. Riesgos para la salud
Hay varios estudios iniciados ante la preocupación por los efectos del RFID y tecnologías
afines en la salud. Aunque no se han encontrado resultados concluyentes por ahora (la
experimentación indica que no parecen existir efectos adversos en la salud), merece la pena
revisar brevemente la situación en este aspecto, porque podría influir en el despliegue de la
tecnología. En la región de frecuencias bajas (hasta los 300 Hz), los efectos de estimulación
producidos por cargas eléctricas de superficie debido a los campos eléctricos de baja
frecuencia pueden ser percibidos por las personas. Las células excitables eléctricamente en la
retina pueden ser afectadas por densidades de 10mA m-2 o más, inducidas por campos
electromagnéticos de baja frecuencia o directamente aplicado por corriente eléctrica, pero sin
conocimiento de efectos adversos en la salud.
La guía internacional sobre la limitación de la exposición humana (ICNIRP, 1998) busca
limitar los efectos perjudiciales de las cargas de superficie y evitar los efectos adversos de la
corriente inducida en los circuitos neuronales de la retina y otras partes del sistema nervioso.
Generalmente, bajo estos niveles de exposición, no se han encontrado efectos consistentes ya
sea en animales o estudios a voluntarios. En particular, no hay evidencia convincente de algún
efecto sobre la reproducción y el desarrollo, sobre hematología o el sistema inmune o sobre
causas de cáncer.
En la región de frecuencia de 300 Hz a 10 MHz, a menudo referida como región de frecuencia
intermedia, el comienzo de los efectos de la corriente inducida sobre células excitables
eléctricamente en el sistema nervioso central sólo predominará sobre posibles efectos de
calentamiento a frecuencias bajas (hasta cerca de 100 kHz). En tanto las frecuencias se
incrementen de cerca de 100 kHz a cerca de 10 MHz, los efectos de calentamiento llegan a
97
Análisis de servicios de identificación-localización basados en RFID
ser más importantes, dependiendo de otras condiciones de exposición (por ejemplo,
modalidad de pulso). La guía internacional (ICNIRP, 1998) en esta región está basada en la
extrapolación de células neuronales identificadas en la región de baja frecuencia y de acuerdo
a las respuestas de las células nerviosas en esa frecuencuia conocida y a los efectos de
calentamiento identificados a frecuencias mayores a 10 MHz.
En la región de altas frecuencias (10 MHz – 300 GHz), los efectos de calentamiento se
encuentran bien establecidos en experimentos a voluntarios y animales. La guía internacional
sobre la limitación de exposición a campos electromagnéticos (ICNIRP, 1998), busca
prevenir efectos adversos de calentamiento localizado y del cuerpo entero excesivos. Además,
la guía previene de evitar la percepción auditiva de frecuencias electromagnéticas de pulso.
No hay efectos de salud adversos establecidos bajo estos niveles de exposición, aunque la
posibilidad ha sido considerada en conexión con la radiación del teléfono móvil que puede
tener efectos transitorios importantes en la función del sistema nervioso y el comportamiento.
10.6. Evolución previsible de la tecnología
El artículo “Location-Aware Computing Comes of Age“, de reciente aparición, indica el
amplio despliegue de las tecnologías de sensores que se está llevando a cabo, que hará que las
aplicaciones de localización sean parte de la vida corriente. No menciona cuándo ocurrirá,
pero dadas las indicaciones, un plazo de dos o tres años puede ser todavía necesario para que
estas tecnologías se abaraten y adopten de forma generalizada.
En este contexto y aunque RFID fue concebido inicialmente como una tecnología de
identificación, ya se ha reconocido su potencialidad en el área de la localización, como se
recoge en la siguiente figura. Cada caja que se expande horizontalmente muestra el rango de
exactitud que la tecnología cubre, los límites inferiores representan el despliegue actual
mientras que los límites superiores predicen el despliegue en los próximos años. Como se
puede observar, el despliegue masivo para una exactitud de entre centímetros a pocos metros
es el área de dominio de RFID.
98
Despliegue de las tecnologías de localización-sensado
Bajo
Medio
Alto
Labs.Invest.
A medida
Uusuarios finales
Análisis de servicios de identificación-localización basados en RFID
GPS
Teléfonos
móviles
TV
RFID
Bluetooth
Wi-Fi
Infrarojo
Ultrasónico
1cm
Banda de
radio ultra
amplia
10cm
Visión
1m
10m
Exactitud de localización
100m
En la evaluación que los autores del trabajo mencionado hacen, se mencionan los siguientes
aspectos de mejora de la tecnología RFID en los próximos años:
• El perfeccionamiento de las tareas que realiza Savant.
• La integración de la información producida por la red EPC con las otras aplicaciones de la
organización.
• El manejo de grandes volúmenes de información generados por la nueva tecnología.
• La creación de “middleware” reflectivo para la red EPC ya que el manejo y generación de
la información es en tiempo real.
99
Análisis de servicios de identificación-localización basados en RFID
11. Conclusiones
Según se enunciaba en la propuesta de este proyecto exploratorio, el objetivo general del
proyecto ha sido el análisis de los servicios de localización e identificación basados en RFID.
Radio Frequency IDentification (RFID) es una tecnología de detección automática,
inalámbrica, de corto alcance, que opera en la banda de UHF, y para la que existen etiquetas y
lectores en el mercado a coste razonable. Las etiquetas almacenan y proporcionan a los
lectores un identificador único que permite la identificación unívoca del objeto (o persona)
que la porta.
El análisis de la arquitectura de red y servicios basados en RFID se puede realizar desde
varios puntos de vista, la mayoría de los cuales se han tenido en cuenta a la hora de revisar el
marco tecnológico:
ƒ
posibilidades de implantación y seguimiento de la tecnología: coste, fabricantes.
ƒ
exigencias de interconexión e interoperación: cómo asociar RFID a otras redes de
forma que se explote su potencial económico.
ƒ
necesidades de comunicaciones: el impacto que el uso de RFID puede provocar en el
tráfico soportado por una operadora de telecomunicación.
ƒ
arquitectura general de servidores: la estructura de despliegue, los nodos de servicio,
los protocolos entre elementos de red.
Los objetivos específicos propuestos en su día para el proyecto han sido:
• realizar una evaluación del estado del arte sobre servicios de localización-identificación
basados en RFID (capítulo 2 de este documento) ,
• estudiar las propuestas existentes y definir una arquitectura de red válida para los
propósitos de un operador (capítulos 4, 5, 6,7, 8 y 9 de este documento),
• analizarla frente a varios aspectos: viabilidad, escalabilidad, rendimiento, coste, tráfico,
etc, (capítulos 3 y 10 de este documento),
• evaluar varios escenarios de aplicación (capítulos 2 y 10 de este documento).
Otro resultado importante de este proyecto exploratorio, ha sido la recogida y elaboración de
la información que se encuentra actualmente dispersa acerca de fabricantes, estándares,
100
Análisis de servicios de identificación-localización basados en RFID
propuestas de arquitectura, escenarios de servicio, etcétera. La bibliografía que aparece en
este documento incluye numerosos puntos de información, no sólo publicaciones, sino
también de sitios Web, donde se puede encontrar información con la cual profundizar en los
diferentes aspectos de la tecnología.
Con el presente, se cubre el primero de los documentos de entrega del proyecto, descrito en la
propuesta de proyecto como: memoria del trabajo, conteniendo estado del arte, revisión de
estándares, bibliografía, proyectos y productos, descripción de la arquitectura propuesta del
sistema, análisis y evaluación sobre el prototipo cuyo código se entregará en el proyecto;
escenarios de aplicación e impacto en la arquitectura; conclusiones y propuesta de trabajo
futuro.
También se ha considerado de interés, de cara a futuros trabajos, contar con una plataforma
software mínima sobre la que realizar experimentos y mejoras (la que hemos denominado
prototipo). Los apéndices de este documento contienen la información textual correspondiente
a este prototipo que hemos realizado durante la ejecución del proyecto. Pretendemos
continuar el desarrollo de dicho prototipo para dotarle de mayores capacidades.
Respecto a las conclusiones del trabajo con respecto a la tecnología RFID para el soporte de
los servicios de identificación-localización, nuestra visión puede resumirse en los siguientes
puntos:
• se trata de una tecnología que es todavía hoy cara para su despliegue masivo. En las
publicaciones sobre RFID se habla de la “etiqueta de 5 céntimos” como un objetivo
a partir del cual las condiciones de economía de escala hacen posible el despliegue
masivo. Como hemos señalado a lo largo del estudio, existen otros costes
determinantes para el éxito y que normalmente no se tienen en cuenta, como son los
costes de las antenas, de la instalación del sistema, y los costes de operación.
Mientras no exista un modelo de costes y un modelo de negocio asociado claros no
va a ser posible que la tecnología llegue al gran público y por lo tanto emergerán
“islas RFID” normalmente asociadas a una instalación física o como mucho a un
ámbito corporativo. Este es el escenario más probable para los próximos 3 años.
101
Análisis de servicios de identificación-localización basados en RFID
• los aspectos tecnológicos en cuanto a la captura y gestión de los datos parecen por
el momento bien resueltos con la arquitectura propuesta por Auto-ID Center, al
menos en lo relativo a los Savant y su jerarquía. El mayor éxito de la propuesta,
desde nuestro punto de vista, es el de proporcionar un modelo claro y fácilmente
entendible, capaz de sacar partido de la tecnología software existente (plataformas
de componentes para clientes, servidores y sistemas empotrados, basadas en la
tecnología Java), y que refleja las características específicas de este tipo de sistemas
(necesidad de manejar cantidades masivas de datos, establecimiento de filtros para
la selección de los datos más apropiados, almacenamiento rápido y temporal en
memoria, uso del patrón observador para reducir la carga del sistema, etc.). La
mayor dificultad para el despliegue de la tecnología, desde el punto de vista de la
tecnología de tratamiento de datos, puede ser que existan pocas implementaciones y
cerradas, lo que otorgaría un gran poder a los fabricantes de software para dirigir el
despliegue, sin forzarles a mayores mejoras en este aspecto. La existencia de
estándares abiertos y aún más, de implementaciones abiertas es una garantía de que
esta situación no ocurrirá. En este sentido, el trabajo que hemos comenzado tendrá
continuación en la mejora del rendimiento del prototipo de implementación de
Savant. Entendemos que estos problemas tendrán en cualquier caso un plazo de
resolución corto, de entre uno y dos años.
• en los aspectos de inter-operación de la “red EPC” o red de aplicaciones alrededor
de la identificación y localización usando RFID (y otros métodos) es donde
aparecerán en el futuro cercano mayores problemas. Las propuestas realizadas por
Auto-ID Center tratan de dirigir la implantación de la tecnología y su integración
con las aplicaciones corporativas, y en este punto encontramos las propuestas
factibles de ser llevadas a cabo con éxito. En cuanto a la creación de una red de
aplicaciones fuera del ámbito corporativo, e incluyendo éstas, nos encontramos con
un problema similar al de otras tecnologías del ámbito de las telecomunicaciones y
la telemática: exigen una infraestructura pública o de acuerdos, que se plasmaría en
la existencia y operación de los nodos raíz de la jerarquía ONS. Siendo este punto
de crucial importancia para el despliegue masivo, aparecen de forma clara los
aspectos administrativos y políticos del problema: ¿ quién proveerá y mantendrá
estos nodos raíz ¿ Se trata de un problema que apenas alcanza a vislumbrarse y para
102
Análisis de servicios de identificación-localización basados en RFID
el que existen varias posibles soluciones: infraestructura pública, operadores de
telecomunicación, asociaciones empresariales, etc. No prevemos solución clara en
los próximos tres años, lo que refuerza la visión de las “islas RFID” sin conexión.
• en otro ámbito, es preciso mencionar que con los elementos tecnológicos resueltos,
la atención de los agentes de este ámbito se enfoca a cuestiones extra-funcionales.
Entre ellas, los aspectos de privacidad de la información, seguridad de ésta, y
efectos sobre los seres vivos. Estos aspectos quedan fuera del ámbito de nuestra
exploración, pero van a resultar determinantes para que la tecnología se acepte por
el gran público (y por lo tanto pueda ser desplegada con éxito en lugares de
afluencia masiva como supermercados, campos de deporte, escuelas y campus).
Comentar en este sentido que con la disponibilidad de etiquetas, lectores y Savants
es posible la realización de proyectos piloto en los cuales comprobar el impacto de
las medidas de seguridad en la información.
• otra visión de la ingeniería de servicios de telecomunicación o telemáticos y que
tiene gran influencia y seguirá teniéndola en la implantación de la tecnología RFID
y otras, tiene que ver con los aspectos de provisión del diseño; básicamente cómo
entender el desarrollo y explotación de servicios de forma integrada (tanto la parte
de red como la de aplicación). La pregunta es si las empresas que podrían implantar
la tecnología están preparadas para hacerlo en términos de personal disponible y
potencialmente productivo. Nuestra visión particular de esta parte del problema es
que el conocimiento de la ingeniería de servicios que tiene un profesional técnico
en el ámbito de las empresas operadoras de red (en el ámbito nacional), o el
conocimiento que obtiene un ingeniero recién graduado, no son suficientes para
abordar los problemas técnicos-administrativos que plantea la tecnología. En este
punto, y a riesgo de que parezca que se mezclan los problemas, es preciso
mencionar que la mejora de la formación de postgrado y universitaria será
determinante en los próximos cinco años.
103
Análisis de servicios de identificación-localización basados en RFID
12. Bibliografía
Las fuentes de información para el desarrollo de este estudio han sido múltiples y cambiantes,
lo que refleja el estado actual de la tecnología. A continuación, y sin ánimo de ser
exhaustivos, se mencionan algunas de las fuentes utilizadas.
Especificaciones Auto-ID Center:
• Auto-ID Reader Protocol Specification 1.0. Auto-ID Center.
• Auto-ID Savant Specification 1.0. Auto-ID Center.
• Auto-ID EPC Information Service Specification 1.0. Auto-ID Center.
• Auto-ID Electronic Product Code Data Specification 1.0. Auto-ID Center.
• EPC Tag Data Standards version 1.1 rev. 1.23. Auto-ID Center.
• Technical Report, 13.56 MHz ISM Band Class1 Radio Frequency Identification
Tag Interface Specification. 2003. Auto-ID Center.
• Draft protocol specification for a 900 MHz class 0 radio frequency identification
tag, 2003. Auto-ID Center.
• Technical Report, 860MHz-930MHz Class1 Radio Frequency Identification Tag
Radio Frequency and logical Communication Interface Specification, candidate
recommendation. 2002. Auto-ID Center.
• Auto-ID Object Name Service (ONS) 1.0, 2003. Auto-ID Center.
Documentos generales y presentaciones:
• Java Everywhere, Simon Ritter, Sun Microsystems, Inc.
• Auto-ID Center Software Framework, Auto-ID Center.
• White paper, multiband, low cost EPC tag reader, M. Reinolds, Auto-ID Center,
2002.
• White paper, multiband, PML server developments, M. Harrison, Auto-ID
Center, 2003.
• White paper, Sun’s Auto-ID Architecture, SUN, 2003.
• The SUN Electronic Product Code (EPC) Inititative, SUN, 2003.
104
Análisis de servicios de identificación-localización basados en RFID
• EC Projects on Smart Cards, IST Projects Compendium. Fifth Framework
Programme, Information Society Technology Programme. 2002.
• Possible Health Risks to the General Public from the Use of Security and Similar
Devices. Concerted Action QLK4-1999-01214 “Development of advice to the
European Commission on the risk to health of the general public from the use of
security and similar devices employing pulsed and continuous electromagnetic
fields”. Fifth Framework Programme of the European Commission, Quality of
Life, Key Action 4: “Environment and Health, Health impact of electromagnetic
fields“.
• Location-Aware Computing Comes of Age, Mike Hazas, James Scout, John
Krumm, IEEE Computer IEEE Computer Society, febrero de 2004.
Noticias y sitios web:
• Shrouds
of
Time.
Jeremy
Landt.
http://www.aimglobal.org/technologies/rfid/what_is_rfid.htm
• http://home.att.net/~randall.j.jackson/rfid-overview.html
• Auto-ID Center. http://www.autoidlabs.org/
• “U.S. retailers give Wal-Mart a head start on RFID”. Emily Kaiser, Reuters.
http://www.usatoday.com/tech/news/techinnovations/2004-01-27-walmartpioneers-rfid_x.htm
• “Wal-Mart Pulls RFID Trigger: The Race Is On”. John Fontanella, Junio 2003,
http://www.amrresearch.com/Content/printversion.asp?pmillid=16268&historyi
d=1820539&print=1
• “DOD
Details
its
RFID
Plans”.
Mark
Hachman,
Octubre,
2003.
http://www.eweek.com/print_article/0,3048,a=110899,00.asp
• “Radio ID chips may track banknotes”.
Winston Chai. Mayo 2003.
http://news.com.com/2100-1017-1009155.html
• RFID and the Mainstream Supply Chain, Tom Coyle, Septiembre 2003.
http://developer.net.au/features/articles/rfid+for+the+supply+chain.asp
• http://www.aimglobal.org/technologies/rfid/resources/articles/jan04/0401roispy.htm
105
Análisis de servicios de identificación-localización basados en RFID
• http://www.aimglobal.org/technologies/rfid/resources/articles/july03/rfidandpriv
acy.htm
• CASPIAN -- Consumers Against Supermarket Privacy Invasion And Numbering
-- (http://www.nocards.org)
• www.buyrfid.com
106
Análisis de servicios de identificación-localización basados en RFID
Apéndice 1: Un prototipo de Savant
En las actividades del proyecto exploratorio se ha desarrollado un prototipo de las funciones
básicas de Savant. El objetivo de la construcción de este prototipo es el de comprobar el grado
de comprensión de las especificaciones manejadas y descritas en este documento. Una
segunda intención con la construcción de este prototipo es la de realizar un núcleo de sistema
que pudiera ser extendida en proyectos posteriores (entre ellos el Proyecto Fin de Carrera del
alumno José Vicente Espinosa, que aplica las tecnologías RFID de identificación y
localización a la gestión de elementos paleo-arqueológicos). El prototipo contiene un Savant
básico, un prototipo de lector y un emulador gráfico capaz de permitir la simulación de
etiquetas en un área de cobertura.
Las clases fundamentales del diseño de este prototipo de Savant (centrado fundamentalmente
en las funciones de inventario de etiquetas RFID) son las que se muestran en la siguiente
figura. Se observará que el prototipo incluye clases e interfaces correspondientes a funciones
de Lector, EPC, Savant según las especificaciones de Auto-ID Center. El prototipo se ha
implementado en lenguaje Java en el que sacrificamos el rendimiento del sistema final frente
a la rapidez del desarrollo.
Timer
ReadQueue
(from rss)
(from rss)
AutoIDAntenna
DataAcquisition
ReadFilter
EventGeneration
TagStatusAutomation
(from rss)
(from rss)
(from rss)
(from ess)
(from ess)
DataAcquisitionInterface
ReadFilterInterface
(from autoid)
(from autoid)
Reader
SavantAdapter
(from reader)
(from mtb)
ReaderInterface
SavantAdapterInterface
(from autoid)
(from mtb)
Las clases se han organizado en los siguientes paquetes, cuya descripción completa se incluirá
más adelante en este documento.
107
Análisis de servicios de identificación-localización basados en RFID
autoid
ess
mtb
rss
Las dos siguientes figuras muestran el flujo de operación normal en la lectura de las etiquetas
RFID por un lector e información al Savant, de forma que se realice el inventario (listado de
etiquetas en el área de cobertura en un momento del tiempo).
7: filter()
3: tag reading
AutoIDAnt
enna
DataAcqu
isition
ReadFilt
er
1: inventary()
2: read()
6: tag reading
4: push(tag reading)
5: pull()
8: push(filtered tag reading)
13: updat...
9: pull()
TagStatusAut
omation
EventGen
eration
11: new()
12: notifyInField()
ReadQu
eue
10: filtered tag reading
14: notifyEPCEvent(eve...
SavantAdapte
rInterface
Como se puede observar, la clase que inicia la adquisición de datos indica el comienzo de la
simulación a la antena, va recogiendo las lecturas de etiquetas con los EPC y las va
almacenando en una cola de lectura. De ahí son leídas por un filtro, que tras seleccionar las
lecturas las pasa a una segunda cola de lectura. El generador de eventos, y la interfaz de
adaptación a Savant recogen diferentes situaciones de la ejecución. TagStatusAutomation
representa el autómata de identificación de etiquetas.
108
Análisis de servicios de identificación-localización basados en RFID
AutoIDAntenna
DataAcquisition
ReadQueue
ReadFilter
ReadQueue
EventGeneration
SavantAdapterIn
terface
TagStatusAuto
mation
inventary()
read()
tag reading
push(tag reading)
pull()
tag reading
filter()
push(filtered tag reading)
pull()
filtered tag reading
new()
notifyInField()
update()
notifyEPCEvent(event)
La siguiente figura es un volcado de pantalla del simulador, mostrando información sobre una
de las tarjetas encontradas en el radio de acción simulado de un lector. Las órdenes que
aparecen en la esquina superior izquierda son: creación de una tarjeta, movimiento en el área
de simulación, y eliminación de la tarjeta. Hemos realizado este simulador para obtener una
primera realimentación sobre el comportamiento de las tarjetas, el lector y el Savant asociado.
No se ha optimizado para el rendimiento, pero puede dar lugar a futuras mejoras que permitan
la utilización de este simulador para el cálculo de coberturas con conjuntos de antenas y
lectores RFID en espacios cerrados.
109
Análisis de servicios de identificación-localización basados en RFID
110
Análisis de servicios de identificación-localización basados en RFID
Apéndice 2: Diseño detallado del prototipo de Savant
A continuación se incluye la documentación de diseño del prototipo de Savant realizado
durante la ejecución de este proyecto exploratorio, descrito en secciones anteriores.
Hierarchy For All Packages
Package Hierarchies:
reader, reader.autoid, reader.ess, reader.mtb, reader.rss
Class Hierarchy
o
class java.lang.Object
o class reader.rss.AutoIDAntenna
o class java.util.Observable
o class reader.ess.TagStatusAutomation (implements
java.lang.Runnable)
o class reader.Reader (implements reader.autoid.ReaderInterface)
o class reader.rss.ReadQueue
o class java.lang.Thread (implements java.lang.Runnable)
o class reader.rss.DataAcquisition (implements
reader.autoid.DataAcquisitionInterface)
o class reader.ess.EventGeneration (implements java.util.Observer)
o class reader.rss.ReadFilter (implements
reader.autoid.ReadFilterInterface)
o class reader.mtb.SavantAdapter (implements
reader.mtb.SavantAdapterInterface)
o class reader.rss.Timer
Interface Hierarchy
o
o
o
o
interface reader.autoid.DataAcquisitionInterface
interface reader.autoid.ReaderInterface
interface reader.autoid.ReadFilterInterface
interface reader.mtb.SavantAdapterInterface
111
Análisis de servicios de identificación-localización basados en RFID
Package reader
Class Summary
Reader
Reader class represents an Auto ID Reader device.
Hierarchy For Package reader
Package Hierarchies:
All Packages
Class Hierarchy
o
class java.lang.Object
o class reader.Reader (implements reader.autoid.ReaderInterface)
112
Análisis de servicios de identificación-localización basados en RFID
reader
Class Reader
java.lang.Object
|
+--reader.Reader
All Implemented Interfaces:
ReaderInterface
public class Reader
extends java.lang.Object
implements ReaderInterface
Reader class represents an Auto ID Reader device. A Reader is a device capable of detecting
when tags enter their read range. Its funtion is to provide information of what tags in their
read range are. To do this, a Reader has two subsystems. On the one hand, a read subsystem
allows to do tag readings and to establish a first read filter. On the other, a event subsystem
allows to try these tag readings and to communicate to Savant events that occurs with tags in
its read range.
Since:
1.4
See Also:
ReaderInterface
Constructor Summary
Reader()
Creates a Reader device with default configuration.
Method Summary
java.lang.String GetMfrDescription()
Returns Reader manufacturer description.
java.lang.String GetReaderConfiguration()
Returns a complete description of Reader configuration.
java.lang.String GetReaderID()
Returns Reader identificator.
java.lang.String GetReaderName()
Returns Reader name.
static void main(java.lang.String[] args)
boolean SetReaderName(java.lang.String ReaderName)
Sets Reader name.
113
Análisis de servicios de identificación-localización basados en RFID
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString,
wait, wait, wait
Constructor Detail
Reader
public Reader()
Creates a Reader device with default configuration.
Method Detail
GetReaderID
public java.lang.String GetReaderID()
Returns Reader identificator.
Specified by:
GetReaderID in interface ReaderInterface
Returns:
Reader identificator.
See Also:
ReaderInterface.GetReaderID()
GetReaderName
public java.lang.String GetReaderName()
Returns Reader name.
Specified by:
GetReaderName in interface ReaderInterface
Returns:
Reader name.
See Also:
SetReaderName(String), ReaderInterface.GetReaderName()
SetReaderName
public boolean SetReaderName(java.lang.String ReaderName)
Sets Reader name.
Specified by:
SetReaderName in interface ReaderInterface
Parameters:
ReaderName - Reader name
Returns:
114
Análisis de servicios de identificación-localización basados en RFID
true if operation has been successful; false otherwise.
See Also:
GetReaderName(), ReaderInterface.SetReaderName(String)
GetMfrDescription
public java.lang.String GetMfrDescription()
Returns Reader manufacturer description.
Specified by:
GetMfrDescription in interface ReaderInterface
Returns:
Reader manufacturer description.
See Also:
ReaderInterface.GetMfrDescription()
GetReaderConfiguration
public java.lang.String GetReaderConfiguration()
Returns a complete description of Reader configuration. It is a summary of the
configuration of each modules of the Reader device.
Specified by:
GetReaderConfiguration in interface ReaderInterface
Returns:
Reader configuration.
See Also:
ReaderInterface.GetReaderConfiguration()
main
public static void main(java.lang.String[] args)
115
Análisis de servicios de identificación-localización basados en RFID
Package reader.autoid
Interface Summary
DataAcquisitionInterface interface represents the Reader layer
DataAcquisitionInterface operations over Data Acquisition module of the Reader read
subsystem.
ReaderInterface
ReaderInterface interface represents the Reader layer operations
over Reader device.
ReadFilterInterface
ReadFilterInterface interface represents the Reader layer
operations over Read Filter module of the Reader read subsystem.
Hierarchy For Package reader.autoid
Package Hierarchies:
All Packages
Interface Hierarchy
o
o
o
interface reader.autoid.DataAcquisitionInterface
interface reader.autoid.ReaderInterface
interface reader.autoid.ReadFilterInterface
116
Análisis de servicios de identificación-localización basados en RFID
reader.autoid
Interface DataAcquisitionInterface
All Known Implementing Classes:
DataAcquisition
public interface DataAcquisitionInterface
DataAcquisitionInterface interface represents the Reader layer operations over Data
Acquisition module of the Reader read subsystem. The operations are basically based on
getting/setting parameters. Defined parameters on Data Acquisition module are:
•
•
•
•
•
ReaderReadTrigger
ReaderReadCycle
ReaderReadDutyCycle
ReaderReadTime
ReaderReadTimeInterval
Since:
1.4
See Also:
DataAcquisition
Method Summary
int GetReadTime()
Returns current read time.
int GetReadTimerInterval()
Returns current read timer interval.
java.lang.String GetReadTrigger()
Returns current read trigger.
boolean ReadTags()
Force a reading of the Data Acquisition subsystem when current
read trigger is ON_REQUEST.
boolean SetReadTime(int ReadTime)
Sets a new read time.
boolean SetReadTimerInterval(int ReadTimerInterval)
Sets read timer interval.
boolean SetReadTrigger(java.lang.String ReadTrigger)
Sets a new read trigger.
Method Detail
117
Análisis de servicios de identificación-localización basados en RFID
GetReadTrigger
public java.lang.String GetReadTrigger()
Returns current read trigger.
Returns:
current read trigger.
See Also:
SetReadTrigger(String)
SetReadTrigger
public boolean SetReadTrigger(java.lang.String ReadTrigger)
Sets a new read trigger.
Returns:
true if operation has been successful; false otherwise.
See Also:
GetReadTrigger()
GetReadTimerInterval
public int GetReadTimerInterval()
Returns current read timer interval.
Returns:
current read timer interval.
See Also:
SetReadTimerInterval(int)
SetReadTimerInterval
public boolean SetReadTimerInterval(int ReadTimerInterval)
Sets read timer interval.
Returns:
true if operation has been successful; false otherwise.
See Also:
GetReadTimerInterval()
GetReadTime
public int GetReadTime()
Returns current read time.
Returns:
current read time.
See Also:
SetReadTime(int)
SetReadTime
public boolean SetReadTime(int ReadTime)
Sets a new read time.
118
Análisis de servicios de identificación-localización basados en RFID
Returns:
true if operation has been successful; false otherwise.
See Also:
GetReadTime()
ReadTags
public boolean ReadTags()
Force a reading of the Data Acquisition subsystem when current read trigger is
ON_REQUEST.
Returns:
true if operation has been successful; false otherwise.
119
Análisis de servicios de identificación-localización basados en RFID
reader.autoid
Interface ReaderInterface
All Known Implementing Classes:
Reader
public interface ReaderInterface
ReaderInterface interface represents the Reader layer operations over Reader device. The
operations are basically based on getting parameters. Defined parameters on Reader are:
•
•
•
ReaderID
ReaderName
ReaderMfrDescription
Since:
1.4
See Also:
Reader
Method Summary
java.lang.String GetMfrDescription()
Returns Reader manufacturer description.
java.lang.String GetReaderConfiguration()
Returns current Reader configuration.
java.lang.String GetReaderID()
Returns Reader identificator.
java.lang.String GetReaderName()
Returns Reader name.
boolean SetReaderName(java.lang.String ReaderName)
Sets Reader name.
Method Detail
GetReaderID
public java.lang.String GetReaderID()
Returns Reader identificator.
Returns:
Reader identificator.
GetReaderName
public java.lang.String GetReaderName()
120
Análisis de servicios de identificación-localización basados en RFID
Returns Reader name.
Returns:
Reader name.
See Also:
SetReaderName(String)
SetReaderName
public boolean SetReaderName(java.lang.String ReaderName)
Sets Reader name.
Parameters:
ReaderName - Reader name.
Returns:
true if operation has been successful; false otherwise.
See Also:
GetReaderName()
GetMfrDescription
public java.lang.String GetMfrDescription()
Returns Reader manufacturer description.
Returns:
Reader manufacturer description.
GetReaderConfiguration
public java.lang.String GetReaderConfiguration()
Returns current Reader configuration.
Returns:
Reader configuration.
121
Análisis de servicios de identificación-localización basados en RFID
reader.autoid
Interface ReadFilterInterface
All Known Implementing Classes:
ReadFilter
public interface ReadFilterInterface
ReadFilterInterface interface represents the Reader layer operations over Read Filter module
of the Reader read subsystem. The operations are basically based on getting/setting
parameters. Defined parameters on Read Filter module are:
•
ReaderMaxReadFilters
Since:
1.4
See Also:
ReadFilter
Method Summary
int GetMaxReadFilters()
Returns maximun number of read filters supported.
java.lang.String[] GetReadFilters()
Returns current read filters.
boolean SetReadFilters(java.lang.String ReadFilter)
Sets a new read filter.
Method Detail
GetMaxReadFilters
public int GetMaxReadFilters()
Returns maximun number of read filters supported.
Returns:
maximun number of read filters supported.
GetReadFilters
public java.lang.String[] GetReadFilters()
Returns current read filters.
Returns:
a list containing current read filters.
See Also:
SetReadFilters(String)
122
Análisis de servicios de identificación-localización basados en RFID
SetReadFilters
public boolean SetReadFilters(java.lang.String ReadFilter)
Sets a new read filter.
Parameters:
ReadFilter - a new read filter
Returns:
true if the operation has been successful; false otherwise.
See Also:
GetReadFilters()
123
Análisis de servicios de identificación-localización basados en RFID
Package reader.ess
Class Summary
EventGeneration
EventGeneration class represents the first step of the Reader event
subsystem.
TagStatusAutomation
TagStatusAutomation class represents a per-tag automation that
maintains tag status information.
Hierarchy For Package reader.ess
Package Hierarchies:
All Packages
Class Hierarchy
o
class java.lang.Object
o class java.util.Observable
o class reader.ess.TagStatusAutomation (implements
java.lang.Runnable)
o class java.lang.Thread (implements java.lang.Runnable)
o class reader.ess.EventGeneration (implements java.util.Observer)
124
Análisis de servicios de identificación-localización basados en RFID
reader.ess
Class TagStatusAutomation
java.lang.Object
|
+--java.util.Observable
|
+--reader.ess.TagStatusAutomation
All Implemented Interfaces:
java.lang.Runnable
public class TagStatusAutomation
extends java.util.Observable
implements java.lang.Runnable
TagStatusAutomation class represents a per-tag automation that maintains tag status
information. The lifecycle of a tag is defining with an undefined set of status transitions. The
possible status and their transitions are:
•
•
•
•
UNKNOWN status
o Tag situation: tag has never been seen or during a large time.
o Status transitions: to SOFTREAD status if it is received a tag reading of its.
SOFTREAD status
o Tag situation: tag has only been seen one time.
o Status transitions: to UNKNOWN status if there is a time interval longer than
ReaderSoftReadExpireTimeout without receiving a tag reading of its or to
FIRMREAD status if it is seen for at least ReaderFirmReadCount times
without existing a time interval longer than ReaderSoftReadExpireTimeout
between two readings.
FIRMREAD status
o Tag situation: tag is continuously seen.
o Status transitions: to EXPIRED status if there is a time interval longer than
ReaderFirmReadExpireTimeout without receiving a tag reading of its
EXPIRED status
o Tag situation: tag has not been seen for a time.
o Status transitions: to UNKNOWN status if there is a time interval longer than
ReaderPurgeTime without receiving a tag reading of its or to SOFTREAD
status if it is received a tag reading of its.
Since:
1.4
See Also:
Runnable, Observable
Field Summary
static int EXPIRED_STATUS
A constant represents the EXPIRED status
static int FIRMREAD_STATUS
125
Análisis de servicios de identificación-localización basados en RFID
A constant represents the FIRMREAD status
static int SOFTREAD_STATUS
A constant represents the SOFTREAD status
Constructor Summary
TagStatusAutomation(java.lang.String tag_epc)
Creates a Tag Status Automation for tag with identificator tag_epc.
Method Summary
void notifyInField()
This method is called by Event Generation module to notify a new tag reading.
void run()
Runs the lifecycle automation according to defined status and the possible
transitions.
void setCurrentStatus(int status)
Sets new status to status parameter.
Methods inherited from class java.util.Observable
addObserver, clearChanged, countObservers, deleteObserver, deleteObservers,
hasChanged, notifyObservers, notifyObservers, setChanged
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString,
wait, wait, wait
Field Detail
SOFTREAD_STATUS
public static final int SOFTREAD_STATUS
A constant represents the SOFTREAD status
See Also:
Constant Field Values
126
Análisis de servicios de identificación-localización basados en RFID
FIRMREAD_STATUS
public static final int FIRMREAD_STATUS
A constant represents the FIRMREAD status
See Also:
Constant Field Values
EXPIRED_STATUS
public static final int EXPIRED_STATUS
A constant represents the EXPIRED status
See Also:
Constant Field Values
Constructor Detail
TagStatusAutomation
public TagStatusAutomation(java.lang.String tag_epc)
Creates a Tag Status Automation for tag with identificator tag_epc.
Method Detail
run
public void run()
Runs the lifecycle automation according to defined status and the possible transitions.
Specified by:
run in interface java.lang.Runnable
See Also:
Thread.run()
notifyInField
public void notifyInField()
This method is called by Event Generation module to notify a new tag reading.
setCurrentStatus
public void setCurrentStatus(int status)
Sets new status to status parameter.
127
Análisis de servicios de identificación-localización basados en RFID
reader.ess
Class EventGeneration
java.lang.Object
|
+--java.lang.Thread
|
+--reader.ess.EventGeneration
All Implemented Interfaces:
java.util.Observer, java.lang.Runnable
public class EventGeneration
extends java.lang.Thread
implements java.util.Observer
EventGeneration class represents the first step of the Reader event subsystem. Despite it
receives filtered readings from Read Filter module and because it is condidered not necessary
and not efficient to report all tag readings to Savant, this module is reponsible for reducing
this volume of data by generating "events" when the status of each tag changes and
communicates them to Savant. The possible tag status are:
•
•
•
•
UNKNOWN
SOFTREAD
FIRMREAD
EXPIRED
Although for more information about them and status changes, see TagStatusAutomation
class.
It is clear that to do event generation, Event Generation module must maintain status
information on a per-tag basis. So, each time a tag is firstly seen this module registries it and
runs a Tag Status Automation to which reports of each new tag reading received and from
which receives status changes that it converts into events. When a tag pass to UNKNOWN
status it is unregistered. The possible generated events are:
•
•
NEW, when status changes from SOFTREAD to FIRMREAD.
DELETE, when status changes from FIRMREAD to EXPIRED.
Parameters specified into reader_config.txt for default configuration of Tag Status
Automation are:
•
•
•
ReaderSoftReadExpireTimeout, time in milliseconds without receiving a new tag
reading to change from SOFTREAD to UNKNOWN status.
ReaderFirmReadCount, number of tag reading being into SOFTREAD status to pass
to FIRMREAD status.
ReaderFirmReadExpireTimeout, time in milliseconds without receiving a new tag
reading to change from FIRMREAD to EXPIRED status.
128
Análisis de servicios de identificación-localización basados en RFID
•
ReaderPurgeTime, time in milliseconds without receiving a new tag reading to change
from EXPIRED to SOFTREAD status.
Since:
1.4
See Also:
TagStatusAutomation, ReadFilter, Thread, Observer
Field Summary
Fields inherited from class java.lang.Thread
MAX_PRIORITY, MIN_PRIORITY, NORM_PRIORITY
Constructor Summary
EventGeneration(reader.rss.ReadQueue input)
Creates a Event Generation module which the specified ReadQueue from which reads
tag readings coming from Read Filter mudule with default configuration.
Method Summary
java.lang.String getConfiguration()
Returns Event Generation module configuration.
static int getFirmReadCount()
Returns the ReaderFirmReadCount parameter.
static long getFirmReadExpireTimeout()
Returns the ReaderFirmReadExpiredTimeout parameter.
static long getPurgeTime()
Returns the ReaderPurgeTime parameter.
static long getSoftReadExpireTimeout()
Returns the ReaderSoftReadExpiredTimeout parameter.
void run()
Waits for tag readings to registry it and runs its automation.
void setListener(reader.mtb.SavantAdapterInterface savant_adapter_interface
Sets the interface that allow to notify events to Savant.
void update(java.util.Observable o, java.lang.Object arg)
This method is called whenever an automation wants to notify a status change.
129
Análisis de servicios de identificación-localización basados en RFID
Methods inherited from class java.lang.Thread
activeCount, checkAccess, countStackFrames, currentThread, destroy,
dumpStack, enumerate, getContextClassLoader, getName, getPriority,
getThreadGroup, holdsLock, interrupt, interrupted, isAlive, isDaemon,
isInterrupted, join, join, join, resume, setContextClassLoader, setDaemon,
setName, setPriority, sleep, sleep, start, stop, stop, suspend, toString,
yield
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait,
wait
Constructor Detail
EventGeneration
public EventGeneration(reader.rss.ReadQueue input)
Creates a Event Generation module which the specified ReadQueue from which reads
tag readings coming from Read Filter mudule with default configuration. This
ReadQueue is the Read Filter output queue.
See Also:
ReadQueue, ReadFilter
Method Detail
run
public void run()
Waits for tag readings to registry it and runs its automation.
Specified by:
run in interface java.lang.Runnable
Overrides:
run in class java.lang.Thread
See Also:
Thread.run()
update
public void update(java.util.Observable o,
java.lang.Object arg)
This method is called whenever an automation wants to notify a status change.
Specified by:
130
Análisis de servicios de identificación-localización basados en RFID
update in interface java.util.Observer
See Also:
Observer.update(Observable, Object), Observable
setListener
public void
setListener(reader.mtb.SavantAdapterInterface savant_adapter_interface)
Sets the interface that allow to notify events to Savant.
See Also:
SavantAdapterInterface
getSoftReadExpireTimeout
public static long getSoftReadExpireTimeout()
Returns the ReaderSoftReadExpiredTimeout parameter.
getFirmReadExpireTimeout
public static long getFirmReadExpireTimeout()
Returns the ReaderFirmReadExpiredTimeout parameter.
getPurgeTime
public static long getPurgeTime()
Returns the ReaderPurgeTime parameter.
getFirmReadCount
public static int getFirmReadCount()
Returns the ReaderFirmReadCount parameter.
getConfiguration
public java.lang.String getConfiguration()
Returns Event Generation module configuration.
Returns:
Event Generation module configuration.
131
Análisis de servicios de identificación-localización basados en RFID
Package reader.mtb
Interface Summary
SavantAdapterInterface
SavantAdapterInterface interface represents the connection with the
Savant that allows to notify the generated events.
Class Summary
SavantAdapter class represents the Reader-Savant communication support to
SavantAdapter interact with Reader layer that specifies the operations that Reader performs
and what they mean.
Hierarchy For Package reader.mtb
Package Hierarchies:
All Packages
Class Hierarchy
o
class java.lang.Object
o class java.lang.Thread (implements java.lang.Runnable)
o class reader.mtb.SavantAdapter (implements
reader.mtb.SavantAdapterInterface)
Interface Hierarchy
o
interface reader.mtb.SavantAdapterInterface
132
Análisis de servicios de identificación-localización basados en RFID
reader.mtb
Class SavantAdapter
java.lang.Object
|
+--java.lang.Thread
|
+--reader.mtb.SavantAdapter
All Implemented Interfaces:
java.lang.Runnable, SavantAdapterInterface
public class SavantAdapter
extends java.lang.Thread
implements SavantAdapterInterface
SavantAdapter class represents the Reader-Savant communication support to interact with
Reader layer that specifies the operations that Reader performs and what they mean. This
support consists of a Messaging layer that defines the format of the requests and responses
and how Reader layer information is carried and a Transport layer that corresponds to the
networking facilities provided by the operating system or equivalent. A concrete
implementation is called Messaging/Transport Biding (MTB). This implementation defines a
HTTP/1.1 based Messaging layer and a TCP/IP based Transport layer.
On the one hand, this MTB supports a control channel that allows Savant to request Reader
layer operations defined by autoid package interfaces and, on the other, a notify channel that
allows Reader to notify events to Savant. Parameters specified into reader_config.txt for its
default configuration are:
•
•
•
SavantAddress, the IP address of Host on which Savant is running.
SavantListenPort, the TCP port on which Savant is listening.
ReaderListenPort, the TCP port on which Reader is listening.
Since:
1.4
See Also:
SavantAdapterInterface, DataAcquisitionInterface, ReadFilterInterface,
ReaderInterface, Thread
Field Summary
Fields inherited from class java.lang.Thread
MAX_PRIORITY, MIN_PRIORITY, NORM_PRIORITY
133
Análisis de servicios de identificación-localización basados en RFID
Constructor Summary
SavantAdapter(reader.autoid.ReadFilterInterface read_filter_interface,
reader.autoid.ReaderInterface reader_interface,
reader.autoid.DataAcquisitionInterface data_acquisition_interface)
Creates a Savant Adapter with the Reader layer specified by read_filter_interface,
reader_interface and data_acquisition_interface with the default configuration.
Method Summary
java.lang.String getConfiguration()
Returns Savant Adapter configuration.
void notifyEPCEvent(java.lang.String event)
Notify an EPC event to Savant using the adapter defined.
void run()
Listens on control channel to the Savant requests.
Methods inherited from class java.lang.Thread
activeCount, checkAccess, countStackFrames, currentThread, destroy,
dumpStack, enumerate, getContextClassLoader, getName, getPriority,
getThreadGroup, holdsLock, interrupt, interrupted, isAlive, isDaemon,
isInterrupted, join, join, join, resume, setContextClassLoader, setDaemon,
setName, setPriority, sleep, sleep, start, stop, stop, suspend, toString,
yield
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait,
wait
Constructor Detail
SavantAdapter
public
SavantAdapter(reader.autoid.ReadFilterInterface read_filter_interface,
reader.autoid.ReaderInterface reader_interface,
reader.autoid.DataAcquisitionInterface data_acquisition_interface)
Creates a Savant Adapter with the Reader layer specified by read_filter_interface,
reader_interface and data_acquisition_interface with the default configuration.
134
Análisis de servicios de identificación-localización basados en RFID
See Also:
ReaderInterface, ReadFilterInterface, DataAcquisitionInterface
Method Detail
run
public void run()
Listens on control channel to the Savant requests.
Specified by:
run in interface java.lang.Runnable
Overrides:
run in class java.lang.Thread
See Also:
Thread.run()
notifyEPCEvent
public void notifyEPCEvent(java.lang.String event)
Notify an EPC event to Savant using the adapter defined.
Specified by:
notifyEPCEvent in interface SavantAdapterInterface
See Also:
SavantAdapterInterface.notifyEPCEvent(String)
getConfiguration
public java.lang.String getConfiguration()
Returns Savant Adapter configuration.
Returns:
Savant Adapter configuration.
135
Análisis de servicios de identificación-localización basados en RFID
reader.mtb
Interface SavantAdapterInterface
All Known Implementing Classes:
SavantAdapter
public interface SavantAdapterInterface
SavantAdapterInterface interface represents the connection with the Savant that allows to
notify the generated events.
Since:
1.4
See Also:
SavantAdapter
Method Summary
void notifyEPCEvent(java.lang.String event)
Notify the EPC event to Savant by mean of the corresponding adapter.
Method Detail
notifyEPCEvent
public void notifyEPCEvent(java.lang.String event)
Notify the EPC event to Savant by mean of the corresponding adapter.
136
Análisis de servicios de identificación-localización basados en RFID
Package reader.rss
Class Summary
AutoIDAntenna AutoIDAntenna class represents the first step of the Reader read subsystem.
DataAcquisition
DataAcquisition class represents the second step of the Reader read
subsystem after Auto ID Antenna module.
ReadFilter
ReadFilter class represents the third step on the Reader read subsystem
after Data Acquisition module and inmediatly before Event Generation
module.
ReadQueue
ReadQueue class represents a simple fifo data buffer.
Timer
Timer class represents a timer that allow to notify timeouts.
Hierarchy For Package reader.rss
Package Hierarchies:
All Packages
Class Hierarchy
o
class java.lang.Object
o class reader.rss.AutoIDAntenna
o class reader.rss.ReadQueue
o class java.lang.Thread (implements java.lang.Runnable)
o class reader.rss.DataAcquisition (implements
reader.autoid.DataAcquisitionInterface)
o class reader.rss.ReadFilter (implements
reader.autoid.ReadFilterInterface)
o class reader.rss.Timer
137
Análisis de servicios de identificación-localización basados en RFID
reader.rss
Class AutoIDAntenna
java.lang.Object
|
+--reader.rss.AutoIDAntenna
public class AutoIDAntenna
extends java.lang.Object
AutoIDAntenna class represents the first step of the Reader read subsystem. It must allow
Data Acquisition module to communicate with auto ID tags. Because it simulates a radio
frecuency antenna by mean of a multisending through a multicast channel in which may be
listening auto ID tags, its configuration is specified into reader_config.txt with an unique
parameter:
•
ReaderRadioFrecuencyChannelID, a multicast class D IP address.
Althougth ISO15693 standard specified a large set of commands to interact with auto ID tags,
this implementation only allow to send inventary requests.
Since:
1.4
See Also:
DataAcquisition, MulticastSocket
Constructor Summary
AutoIDAntenna()
Creates an Auto ID Antenna module with default configuration.
Method Summary
java.lang.String getConfiguration()
Returns AutoIDAntenna configuration.
void inventary()
Multisend an inventary request to all auto ID tags that are
listening on the same RadioFrecuencyChannelID.
java.lang.String read()
Returns a response from auto ID tags in its covering area to a
previous request.
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString,
wait, wait, wait
138
Análisis de servicios de identificación-localización basados en RFID
Constructor Detail
AutoIDAntenna
public AutoIDAntenna()
Creates an Auto ID Antenna module with default configuration.
Method Detail
inventary
public void inventary()
Multisend an inventary request to all auto ID tags that are listening on the same
RadioFrecuencyChannelID.
read
public java.lang.String read()
Returns a response from auto ID tags in its covering area to a previous request.
Returns:
a response which consists of tag identificator; null if there isn't an available reponse.
getConfiguration
public java.lang.String getConfiguration()
Returns AutoIDAntenna configuration.
Returns:
AutoIDAntenna configuration.
139
Análisis de servicios de identificación-localización basados en RFID
reader.rss
Class DataAcquisition
java.lang.Object
|
+--java.lang.Thread
|
+--reader.rss.DataAcquisition
All Implemented Interfaces:
DataAcquisitionInterface, java.lang.Runnable
public class DataAcquisition
extends java.lang.Thread
implements DataAcquisitionInterface
DataAcquisition class represents the second step of the Reader read subsystem after Auto ID
Antenna module. It is in charge of controlling reading activity. This activity includes a
periodic inventary request to auto ID tags and to deliver responses to the next module. The
start of the read activity is marked by a read trigger specified by ReaderReadTrigger
parameter. There are three types of read triggers:
•
•
•
CONTINUOUS, read activity is periodic and constant.
INTERVAL, read activity is periodic but not constant, there is a quiet interval on each
period.
ON_REQUEST, read activity is over demand.
Parameters specified into reader_config.txt file for its default configuration are:
•
•
•
•
•
ReaderReadTrigger, one of CONTINUOUS, INTERVAL and ON_REQUEST.
ReaderReadCycle, in millisecond.
ReaderReadDutyCycle, in multiples of ReaderReadCycle
ReaderReadTime, in multiples of ReaderReadCycle
ReaderReadTimerInterval, only with INTERVAL read trigger, in multiples of
ReaderReadCycle
Each time a read trigger occurs, a new read activity is initiated during ReaderReadTime *
ReaderReadCycl milliseconds. Read activity consists of a read cycle, that is
ReaderReadCyclee milliseconds long, followed by a read duty cycle with a duration of
ReaderReadDutyCycle * ReaderReadCycle milliseconds, time interval between the end of
one read cycle and the start of the next one. Because some operations could be temporally
blocking, in each read activity exists a timer that fixs a timeout count. In the case of
INTERVAL read trigger, ReaderReadTimerInterval * ReaderReadCycle marks, in
milliseconds, how long quiet interval on read activity is.
Since:
1.4
See Also:
AutoIDAntenna, DataAcquisitionInterface, Timer, Thread
140
Análisis de servicios de identificación-localización basados en RFID
Field Summary
Fields inherited from class java.lang.Thread
MAX_PRIORITY, MIN_PRIORITY, NORM_PRIORITY
Constructor Summary
DataAcquisition(reader.rss.AutoIDAntenna antenna,
reader.rss.ReadQueue output)
Creates a Data Acquisition module with the specified AutoIDAntenna and a
ReadQueue that acts as data buffer with Read Filter module.
Method Summary
java.lang.String getConfiguration()
Returns Data Acquisition module configuration.
int GetReadTime()
Returns current read time.
int GetReadTimerInterval()
Returns current read timer interval.
java.lang.String GetReadTrigger()
Returns current read trigger.
boolean ReadTags()
Forces a new read activity when read trigger is ON_REQUEST.
void run()
Runs read activity depends on the read trigger selected.
boolean SetReadTime(int ReadTime)
Sets read time.
boolean SetReadTimerInterval(int ReadTimerInterval)
Sets read timer interval.
boolean SetReadTrigger(java.lang.String ReadTrigger)
Sets read trigger.
Methods inherited from class java.lang.Thread
activeCount, checkAccess, countStackFrames, currentThread, destroy,
dumpStack, enumerate, getContextClassLoader, getName, getPriority,
141
Análisis de servicios de identificación-localización basados en RFID
getThreadGroup, holdsLock, interrupt, interrupted, isAlive, isDaemon,
isInterrupted, join, join, join, resume, setContextClassLoader, setDaemon,
setName, setPriority, sleep, sleep, start, stop, stop, suspend, toString,
yield
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait,
wait
Constructor Detail
DataAcquisition
public DataAcquisition(reader.rss.AutoIDAntenna antenna,
reader.rss.ReadQueue output)
Creates a Data Acquisition module with the specified AutoIDAntenna and a
ReadQueue that acts as data buffer with Read Filter module.
Parameters:
antenna - Auto ID Antenna module.
output - data buffer with the following module.
See Also:
AutoIDAntenna, ReadQueue, ReadFilter
Method Detail
run
public void run()
Runs read activity depends on the read trigger selected.
Specified by:
run in interface java.lang.Runnable
Overrides:
run in class java.lang.Thread
See Also:
Thread.run()
GetReadTrigger
public java.lang.String GetReadTrigger()
Returns current read trigger.
Specified by:
GetReadTrigger in interface DataAcquisitionInterface
Returns:
current read trigger.
142
Análisis de servicios de identificación-localización basados en RFID
See Also:
SetReadTrigger(String), DataAcquisitionInterface.GetReadTrigger()
SetReadTrigger
public boolean SetReadTrigger(java.lang.String ReadTrigger)
Sets read trigger.
Specified by:
SetReadTrigger in interface DataAcquisitionInterface
Parameters:
ReadTrigger - one of the possible values of read trigger.
Returns:
true if the operation has been successful; false otherwise.
See Also:
GetReadTrigger(), DataAcquisitionInterface.SetReadTrigger(String)
GetReadTimerInterval
public int GetReadTimerInterval()
Returns current read timer interval.
Specified by:
GetReadTimerInterval in interface DataAcquisitionInterface
Returns:
a number expressing the current read timer interval in multiples of ReadCycle.
See Also:
SetReadTimerInterval(int),
DataAcquisitionInterface.GetReadTimerInterval()
SetReadTimerInterval
public boolean SetReadTimerInterval(int ReadTimerInterval)
Sets read timer interval.
Specified by:
SetReadTimerInterval in interface DataAcquisitionInterface
Parameters:
ReadTimerInterval - the read timer interval expressed in multiples of ReadCycles.
Returns:
true if the operation has been successful; false otherwise.
See Also:
GetReadTimerInterval(),
DataAcquisitionInterface.SetReadTimerInterval(int)
GetReadTime
public int GetReadTime()
Returns current read time.
Specified by:
GetReadTime in interface DataAcquisitionInterface
143
Análisis de servicios de identificación-localización basados en RFID
Returns:
a number expressing the current read time in multiples of ReadCycle.
See Also:
SetReadTime(int), DataAcquisitionInterface.GetReadTime()
SetReadTime
public boolean SetReadTime(int ReadTime)
Sets read time.
Specified by:
SetReadTime in interface DataAcquisitionInterface
Parameters:
ReadTime - the read time expressed in multiples of ReadCycle.
Returns:
true if the operation has been successful; false otherwise.
See Also:
GetReadTime(), DataAcquisitionInterface.SetReadTime(int)
ReadTags
public boolean ReadTags()
Forces a new read activity when read trigger is ON_REQUEST.
Specified by:
ReadTags in interface DataAcquisitionInterface
Returns:
true if the operation has been successful; false otherwise.
See Also:
DataAcquisitionInterface.ReadTags()
getConfiguration
public java.lang.String getConfiguration()
Returns Data Acquisition module configuration.
Returns:
Data Acquisition module configuration.
144
Análisis de servicios de identificación-localización basados en RFID
reader.rss
Class ReadFilter
java.lang.Object
|
+--java.lang.Thread
|
+--reader.rss.ReadFilter
All Implemented Interfaces:
ReadFilterInterface, java.lang.Runnable
public class ReadFilter
extends java.lang.Thread
implements ReadFilterInterface
ReadFilter class represents the third step on the Reader read subsystem after Data Acquisition
module and inmediatly before Event Generation module. It corresponds to logic that removes
certain tag reads, coming from Data Acquisition module, according to their identificator
called epc. The logic provides a way to describe a simple filtering scheme based on bitwise
patterns called read filters.
This implementation works with 64-bit identificators so a read filter is a string of 0, 1, and X
characters like this:
000111000XX11X00...
A tag epc is said to match a read filter if:
•
•
The tag epc's bit string and the read filter are of equal length.
For every bit position in which read filter contains a 0/1, the tag identificator's bit
string contains a 0/1.
Note that those read filter's bit position that contains a X character are ignored. So a tag read
pass Read Filter module when matchs at least one of the read filters. Parameter specified into
reader_config.txt file for its default configuration is:
•
ReaderMaxReadFilters, the maximun number of read filters supported.
Initially, there isn't any read filter established.
Since:
1.4
See Also:
ReadFilterInterface, Thread
Field Summary
145
Análisis de servicios de identificación-localización basados en RFID
Fields inherited from class java.lang.Thread
MAX_PRIORITY, MIN_PRIORITY, NORM_PRIORITY
Constructor Summary
ReadFilter(reader.rss.ReadQueue input, reader.rss.ReadQueue output)
Creates a Read Filter module that gets tag reads from input queue and puts those
successfully filtered to output queue with default configuration.
Method Summary
java.lang.String EPCBinaryString(java.lang.String epc)
Returns a 64-bit string representation of the tag identificator.
boolean filter(java.lang.String epc)
Check if tag identificator matchs at least one of the established
read filters.
java.lang.String getBits(int value, int nbits)
Returns a nbits-bit string representation of the number value.
java.lang.String getConfiguration()
Returns Read Filter module configuration.
int GetMaxReadFilters()
Returns the maximun number of read filters supported.
java.lang.String[] GetReadFilters()
Returns a list of the read filters supported in its bit string
representation.
void run()
Filters continuously tag reads.
boolean SetReadFilters(java.lang.String ReadFilter)
Sets a new read filter.
Methods inherited from class java.lang.Thread
activeCount, checkAccess, countStackFrames, currentThread, destroy,
dumpStack, enumerate, getContextClassLoader, getName, getPriority,
getThreadGroup, holdsLock, interrupt, interrupted, isAlive, isDaemon,
isInterrupted, join, join, join, resume, setContextClassLoader, setDaemon,
setName, setPriority, sleep, sleep, start, stop, stop, suspend, toString,
yield
146
Análisis de servicios de identificación-localización basados en RFID
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait,
wait
Constructor Detail
ReadFilter
public ReadFilter(reader.rss.ReadQueue input,
reader.rss.ReadQueue output)
Creates a Read Filter module that gets tag reads from input queue and puts those
successfully filtered to output queue with default configuration.
See Also:
ReadQueue
Method Detail
run
public void run()
Filters continuously tag reads.
Specified by:
run in interface java.lang.Runnable
Overrides:
run in class java.lang.Thread
See Also:
Thread.run()
filter
public boolean filter(java.lang.String epc)
Check if tag identificator matchs at least one of the established read filters.
Parameters:
epc - the tag identificator.
Returns:
true if it matchs at least one of the established read filters.
EPCBinaryString
public java.lang.String EPCBinaryString(java.lang.String epc)
Returns a 64-bit string representation of the tag identificator.
Parameters:
epc - the tag identificator.
Returns:
a 64-bit string representation of the tag identificator.
147
Análisis de servicios de identificación-localización basados en RFID
getBits
public java.lang.String getBits(int value,
int nbits)
Returns a nbits-bit string representation of the number value.
Parameters:
value - the numeric value in base 10.
nbits - the number of bit string representation.
Returns:
the bit string representation.
GetMaxReadFilters
public int GetMaxReadFilters()
Returns the maximun number of read filters supported.
Specified by:
GetMaxReadFilters in interface ReadFilterInterface
Returns:
the maximun number of read filters supported.
See Also:
ReadFilterInterface.GetMaxReadFilters()
GetReadFilters
public java.lang.String[] GetReadFilters()
Returns a list of the read filters supported in its bit string representation.
Specified by:
GetReadFilters in interface ReadFilterInterface
Returns:
a list with the read filters supported.
See Also:
SetReadFilters(String), ReadFilterInterface.GetReadFilters()
SetReadFilters
public boolean SetReadFilters(java.lang.String ReadFilter)
Sets a new read filter.
Specified by:
SetReadFilters in interface ReadFilterInterface
Parameters:
ReadFilter - a read filter's bit string representation.
Returns:
true if there are less than maximun read filters established; false otherwise.
See Also:
GetReadFilters(), ReadFilterInterface.SetReadFilters(String)
getConfiguration
public java.lang.String getConfiguration()
148
Análisis de servicios de identificación-localización basados en RFID
Returns Read Filter module configuration.
Returns:
Read Filter module configuration.
149
Análisis de servicios de identificación-localización basados en RFID
reader.rss
Class ReadQueue
java.lang.Object
|
+--reader.rss.ReadQueue
public class ReadQueue
extends java.lang.Object
ReadQueue class represents a simple fifo data buffer. In the Reader read subsystem is used to
buffer the output of one module with the input of following one. This system allow to
establish an asychronous communication channel between two modules avoiding blocking
calls.
Since:
1.4
Constructor Summary
ReadQueue()
Creates a Read Queue with the default capacity.
ReadQueue(int initial_size)
Creates a Read Queue with initial_size capacity.
Method Summary
boolean available()
Test if this Read Queue has read elements.
java.lang.String pull()
Returns the first read elements of this Read Queue, decreasing its
size by one.
void push(java.lang.String read)
Adds the specified read element to the end of this Read Queue,
increasing its size by one.
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString,
wait, wait, wait
150
Análisis de servicios de identificación-localización basados en RFID
Constructor Detail
ReadQueue
public ReadQueue()
Creates a Read Queue with the default capacity.
ReadQueue
public ReadQueue(int initial_size)
Creates a Read Queue with initial_size capacity.
Method Detail
push
public void push(java.lang.String read)
Adds the specified read element to the end of this Read Queue, increasing its size by
one.
Parameters:
read - the read element to add.
pull
public java.lang.String pull()
Returns the first read elements of this Read Queue, decreasing its size by one.
Returns:
the first read element.
available
public boolean available()
Test if this Read Queue has read elements.
Returns:
true if there is at least a read element; false otherwise.
151
Análisis de servicios de identificación-localización basados en RFID
reader.rss
Class Timer
java.lang.Object
|
+--java.lang.Thread
|
+--reader.rss.Timer
All Implemented Interfaces:
java.lang.Runnable
public class Timer
extends java.lang.Thread
Timer class represents a timer that allow to notify timeouts.
Since:
1.4
See Also:
Thread
Field Summary
Fields inherited from class java.lang.Thread
MAX_PRIORITY, MIN_PRIORITY, NORM_PRIORITY
Constructor Summary
Timer(long time, java.lang.Boolean trigger)
Creates a Timer that establishs a timeout of time milliseconds and notify timeout by
mean of trigger boolean variable.
Method Summary
void run()
Runs the timer up to the timeout.
Methods inherited from class java.lang.Thread
152
Análisis de servicios de identificación-localización basados en RFID
activeCount, checkAccess, countStackFrames, currentThread, destroy,
dumpStack, enumerate, getContextClassLoader, getName, getPriority,
getThreadGroup, holdsLock, interrupt, interrupted, isAlive, isDaemon,
isInterrupted, join, join, join, resume, setContextClassLoader, setDaemon,
setName, setPriority, sleep, sleep, start, stop, stop, suspend, toString,
yield
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait,
wait
Constructor Detail
Timer
public Timer(long time,
java.lang.Boolean trigger)
Creates a Timer that establishs a timeout of time milliseconds and notify timeout by
mean of trigger boolean variable.
See Also:
Boolean
Method Detail
run
public void run()
Runs the timer up to the timeout.
Specified by:
run in interface java.lang.Runnable
Overrides:
run in class java.lang.Thread
See Also:
Thread.run()
153