Proyecto Fin de Carrera - GSyC

Transcripción

u
Universidad
Rey Juan Carlos
Escuela Técnica Superior
de Ingeniería de Telecomunicación
Ingeniería de Telecomunicación
Licenciatura en Administración y Dirección
de Empresas
Proyecto Fin de Carrera
Implementación de Frame Slotted Aloha para un
sistema experimental de RFID
Autor: Jesús Pérez Comendador
Tutor: Dr. Christoph Ruland
Cotutor: Dr. Carlos Figuera Pozuelo
Curso Académico 2012/2013
Implementación de Frame Slotted Aloha para un
sistema experimental de RFID
Autor
Jesús Pérez Comendador
Tutor
Dr. Christoph Ruland
Cotutor
Dr. Carlos Figuera Pozuelo
La defensa del presente Proyecto Fin de Carrera se realizó el día 11 de enero
de 2013, siendo evaluada por el siguiente tribunal:
Presidente:
Vocal:
Secretario:
y habiendo obtenido la siguiente Calificación:
Fuenlabrada, a 11 de enero de 2013
A mis padres, que pudieron y quisieron
darme el privilegio de estudiar esta carrera,
y a Carina por estar siempre a mi lado,
apoyándome además en los momentos
difíciles durante el proyecto.
Agradecimientos
Sin duda es una de las páginas más difíciles de esta memoria. En el campo
académico quiero agradecer profundamente a mi tutor, Christoph Ruland, a mi
cotutor, Carlos Figuera, y a Andreas Schantin. A mi tutor por hacer posible
disfrutar de una estancia de prácticas en Alemania, aprendiendo no sólo el idioma,
aspecto no menos importante hoy en día, sino también el funcionamiento del
país. A mi cotutor por la gran labor de apoyo y corrección que ha desarrollado
para que esta memoria saliera adelante, además de por ser uno de los mejores
profesores que he tenido a lo largo de mis estudios, desde que empecé a trabajar
con él en el proyecto Wireless4x4. A Andreas por prestarme la ayuda necesaria durante mi estancia para poder avanzar. Ha sido un gran placer trabajar con él.
También a la Universidad Rey Juan Carlos, por haberme ofrecido estudiar
esta doble titulación que facilitará mi futura carrera profesional. Además, por
haber hecho posible las dos estancias de intercambio realizadas, una en Suecia y
otra la que ha servido para elaborar este PFC en Alemania, que han conseguido
enriquecerme como persona y proporcionarme diferentes enfoques sobre los que
se pueden ver las cosas.
En otro plano quiero agradecer, por los grandes momentos en clase y fuera
de ella, a mis compañeros de carrera y amigos Mario, Mochilo, Ibra, Pacheco,
María, Cristina, Carolina, Fran y, en especial, a Bea, porque estos años nos han
convertido en buenos amigos y, con nuestros más y nuestros menos hemos estado
juntos desde los primeros meses de la carrera.
Por último y no por ello menos importante a mi padre, por haberme enseñado
a dar siempre lo mejor de mí; a mi madre por saber siempre poner calma en
los momentos difíciles; a mis hermanos Gonzalo y Alicia por obligarme a ir a la
biblioteca a estudiar; a Carina por ser una parte muy importante de mi vida; a
mis amigos (Adri, Manu, Isra, Jote, Hermo y Yepes) y a mis amigos Erasmus
(Coré, Javi, Virgilio y Mikel) porque sin todos ellos no sería como soy ahora.
A todos vosotros, gracias.
Contenido
Índice de figuras
xi
Índice de tablas
xiii
Resumen
xv
Abreviaciones
1. Introducción
1.1. Contexto y justificación .
1.2. Descripción del problema .
1.3. Objetivos . . . . . . . . .
1.4. Estructura de la memoria
xvii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2. Materiales y Métodos
2.1. RFID . . . . . . . . . . . . . . . . . . . .
2.1.1. Introducción. . . . . . . . . . . . .
2.1.2. Control de acceso al medio (MAC)
2.1.3. El Protocolo EPC . . . . . . . . . .
2.2. El lenguaje de programación Python . . .
2.2.1. Utilidad para el proyecto. . . . . .
2.3. GNU Radio . . . . . . . . . . . . . . . . .
2.3.1. Qué es GNU Radio . . . . . . . . .
2.3.2. Los bloques de procesado de señal .
2.3.3. Grafos de flujo . . . . . . . . . . .
2.3.4. GNU Radio Companion . . . . . .
2.3.5. GrExtras . . . . . . . . . . . . . .
2.4. NumPy . . . . . . . . . . . . . . . . . . .
2.4.1. El array en NumPy . . . . . . . . .
2.4.2. Funciones en NumPy . . . . . . . .
2.4.3. Utilidad para el proyecto . . . . . .
2.5. El entorno de desarollo Eclipse . . . . . . .
2.6. Metodología . . . . . . . . . . . . . . . . .
ix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
3
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
10
13
26
27
28
28
29
30
30
31
33
34
34
34
35
35
x / CONTENIDO
3. Resultados
3.1. Proceso de implementación del sistema . . . . . . . . . .
3.1.1. Características del sistema . . . . . . . . . . . . .
3.1.2. Máquina de estados de la etiqueta . . . . . . . . .
3.1.3. Máquina de estados del lector . . . . . . . . . . .
3.1.4. Modelo inicial de clases del sistema . . . . . . . .
3.1.5. Implementación de la clase Tag . . . . . . . . . .
3.1.6. Primera versión . . . . . . . . . . . . . . . . . . .
3.1.7. Implementación de la clase Reader . . . . . . . .
3.1.8. Conexión de etiqueta y lector . . . . . . . . . . .
3.1.9. Versión final . . . . . . . . . . . . . . . . . . . . .
3.2. Modelo de clases del sistema final . . . . . . . . . . . . .
3.3. Características del código Python implementado . . . . .
3.4. Pruebas realizadas . . . . . . . . . . . . . . . . . . . . .
3.4.1. Primer estudio. Influencia del número de etiquetas
3.4.2. Segundo estudio. Influencia de Q . . . . . . . . .
4. Conclusiones
4.1. Logros . . . . . . . . . . . . . . . . . . . . . . . .
4.2. Posibles mejoras . . . . . . . . . . . . . . . . . . .
4.2.1. Despliegue en entorno real . . . . . . . . .
4.2.2. Implementación de la operación de acceso
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
39
40
43
46
46
49
52
54
57
62
62
64
65
66
.
.
.
.
71
71
73
73
73
Apéndices
A. Descripción de los atributos y métodos de las clases construidas 77
Bibliografía
84
Índice de figuras
2.1. Backscattering en etiquetas pasivas. . . . . . . . . . . . . . . . . .
2.2. Máquina de estados de las etiquetas EPC. . . . . . . . . . . . . .
2.3. Ejemplo de algoritmo para escoger Q. . . . . . . . . . . . . . . . .
16
18
25
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
3.7.
41
44
47
60
63
67
69
Máquina de estados de la etiqueta a implementar. . .
Diagrama de estados UML del lector a implementar.
Diagrama inicial de clases UML del sistema. . . . . .
Grafo de conexión de los bloques. . . . . . . . . . . .
Diagrama de clases UML final. . . . . . . . . . . . . .
Número de tramas frente a N para Q fijo. . . . . . . .
Número de slots frente a Q para N fijo. . . . . . . . .
xi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Índice de tablas
2.1. Comandos genéricos Slotted ALOHA . . . . . . . . . . . . . . . .
2.2. Acciones tras un Select . . . . . . . . . . . . . . . . . . . . . . . .
2.3. Selección de Q para lectores con Q fija . . . . . . . . . . . . . . .
13
20
26
3.1.
3.2.
3.3.
3.4.
66
66
68
68
Resultados
Resultados
Resultados
Resultados
para
para
para
para
el
el
el
el
primer estudio con Q=4 . .
primer estudio con Q=5 . .
segundo estudio con N=10
segundo estudio con N=45
xiii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Resumen
En el transcurso de la investigación en el campo de los sistemas RFID de largo
alcance (UHF) en la Universidad de Siegen (Alemania), se ha desarrollado un
sistema experimental de RFID que debe permitir evaluar una serie de mejoras
en los estándares RFID actuales (ISO 18000-6, EPC). El sistema, basado en una
radio definida por software (SDR), puede emular la funcionalidad del lector y de
las etiquetas. Está construido sobre el entorno de procesado digital de señal GNU
Radio y se utiliza en combinación con hardware de propósito general.
El protocolo EPC Class-1 Generation-2 (comúnmente llamado estándar EPC)
es un estándar reconocido por el ISO 18000-6C. En él se definen los requisitos,
tanto físicos como lógicos, de un sistema RFID que opera en la banda UHF.
Mientras que el estándar incluye una gran variedad de procedimientos para
la comunicación entre lector y etiquetas, la mayor atención se centra sobre la
correcta implementación del esquema de acceso al medio Frame Slotted ALOHA
(FSA), utilizado por parte del lector durante el inventariado de las etiquetas para
seleccionar una de ellas dentro de una población de tamaño desconocido.
Este Proyecto Fin de Carrera se enmarca dentro del sistema anteriormente
descrito y tiene como objetivo la implementación de los procedimientos recogidos
en el estándar EPC que reflejan el funcionamiento de FSA, tanto para el lector
RFID como para las etiquetas, y la integración de la misma en GNU Radio.
La implementación mantiene compatibilidad con el estándar en la medida de lo
posible, pero no necesita incorporar elementos que no están relacionados con los
procedimientos de acceso compartido al medio.
Durante el transcurso del proyecto se ha desarrollado el sistema utilizando el
lenguaje de programación Python y las librerías de GNU Radio, con vistas a su
uso en simulación. Tras el proceso de desarrollo se han llevado a cabo pruebas para
comprobar que el mismo sigue el funcionamiento de FSA, comparando el sistema
con resultados teóricos. Estas pruebas han verificado que el sistema se comporta
conforme al estándar y a FSA.
xv
Abreviaciones
ACK
API
CDMA
CRC
EAN
EPC
FDMA
FFT
FSA
GNU
GRC
IDE
IP
ISO
MAC
MATLAB
NAK
NumPy
OCR
PC
PMT
RADAR
RFID
RN16
SciPy
SDMA
SDR
SL
SNR
SRCID
TCP
Acknowledge - Asentimiento
Application Programming Interface - Interfaz de programación de aplicaciones
Code Division Multiple Access - Acceso múltiple por división en código
Código de redundancia cíclica
European Article Number - Códigos de barras en artículos (en Europa)
Electronic Product Code - Código electrónico de producto
Frequency Division Multiple Access - Acceso múltiple por división en frecuencia
Fast Fourier Transform - Transformada rápida de Fourier
Frame Slotted ALOHA
Gnu’s Not Unix
GNU Radio Companion - Interfaz gráfica de GNU Radio
Integrated Development Environment - Entorno de desarrollo integrado
Internet Protocol - Protocolo de Internet
Organización internacional de Normalización
Medium Access Control - Control de Acceso al Medio
MATrix LABoratory - Software matemático de Mathworks
Not AcKnowledge - No asentimiento
Numerical Python
Optical Character Recognition - Reconocimiento óptico de caracteres
Protocol Control word - Palabra de control del protocolo
PolyMorphic Type, en GNU Radio
Radio Detecting and Ranging - Detección y medición de distancias por radio
Radio Frequency Identification - Identificación por radiofrecuencia
Número aleatorio de 16 bits
Librería de algoritmos y herramientas matemáticas (diferente a ScientificPython)
Space Division Multiple Access - Acceso múltiple por división en espacio
Software Defined Radios - Radios definidas por software
Indicador Selected
Serial Number - Número serie
Source IDentificator - Identificador de fuente
Transmission Control Protocol - Protocolo de control de transmisión
xvii
xviii / Abreviaciones
TDMA Time Division Multiple Access - Acceso múltiple por división en tiempo
TID
Tag IDentification memory - Memoria de identificación de etiqueta
UDP
User Datagram Protocol - Protocolo de datagramas de usuario
UHF
Ultra-High Frequency: Banda de frecuencias de 300MHz a 3GHz
UML
Unified Modelling Language - Lenguaje Unificado de Modelado
USRP Universal Software Radio Peripheral - Periférico universal de radio por software
VIP
Very Important People
XML
eXtensible Markup Language - Lenguaje de marcas extensible
Capítulo
1
Introducción
En este primer capítulo se presenta una breve introducción al presente Proyecto
Fin de Carrera. En primer lugar se describe el contexto en el que se ha desarrollado
el mismo. En segundo lugar se presenta la descripción del problema abordado. A
continuación se expondrán los objetivos y, por último, se describe la estuctura del
resto de la memoria.
1.1.
Contexto y justificación
El presente proyecto ha sido resultado de una estancia de prácticas en la Universidad de Siegen, Alemania, en concreto en la Cátedra de Sistemas Digitales de
Comunicación de la Facultad de Ciencia y Tecnología. Esta cátedra está dirigida
por el Profesor Christoph Ruland, doctor en Telecomunicación por la Universidad
de Bonn.
La investigación de la cátedra está centrada en:
• Aplicación conjunta de codificación de canal y criptografía para canales ruidosos.
• Aplicación de métodos formales en el diseño de protocolos seguros para
medida.
• Seguridad en sistemas de identificación por radiofrecuencia (RFID, por sus
siglas en inglés).
• Codificación de canal en sistemas RFID.
• Servicios de seguimiento de documentos.
Específicamente, el presente proyecto consiste en el diseño e implementación
un sistema RFID con la mayoría de características recogidas en el protocolo EPC
(Electronic Product Code) uno de los grandes estándares utilizados en el entorno
1
2 / Introducción (C. 1)
de la identificación por radiofrecuencia. Este estándar, promulgado por EPCglobal
Inc. [1] y reconocido por ISO (Organización Internacional de Normalización) [2],
se basa en la funcionalidad que proporciona RFID para la identificación de productos de manera única (mediante el llamado código de identificación electrónico),
proporcionando numerosas ventajas fundamentalmente en el campo de la industria logística, como es el seguimiento de productos en tiempo real. El proyecto ha
sido útil para conocer en profundidad dicho estándar.
1.2.
Descripción del problema
El principal problema que aborda este Proyecto Fin de Carrera es la implementación, conforme a los estándares ya existentes, de un sistema para las
comunicaciones de los distintos elementos del sistema RFID.
Tal y como se expone en la Sección 2.1, RFID es un sistema de identificación
de dispositivos remotos desde otros dispositivos, con la utilización del aire como
único canal transmisor, gracias a la radiofrecuencia. Consta de tres elementos, el
lector, la etiqueta y el middleware. El lector es el dispositivo local desde el cual se
accede a los dispositivos remotos, las etiquetas, que por lo general contienen un
identificador único del objeto al que acompaña. El middleware permite gestionar
la información que se extrae de las etiquetas, como por ejemplo la identificación
del objeto a partir del identificador único contenido en la misma.
Frame Slotted ALOHA (FSA por sus siglas), tal y como está descrito en el
Capítulo 2, es un esquema para acceder al medio de transmisión cuando existen
múltiples interesados en hacerlo. Este esquema es utilizado por los diferentes
agentes participantes en la ronda de identificación en el sistema RFID.
Dichos agentes, que son las etiquetas y el lector, deberán comportarse
según las especificaciones del protocolo EPC Class-1 Gen.-2 [1], que regula las
comunicaciones RFID en la banda de frecuencias UHF, tal y como está recogido
en el estándar ISO/IEC 18000-6C [2].
El sistema RFID implementado deberá poder ser usado tanto para simulación
como para emular las funcionalidades de los diferentes participantes en una transmisión real y, por tanto, poder evaluar las prestaciones en situaciones reales. El
diseño abierto utilizado permitirá posteriormente añadir nuevos elementos al sistema RFID para su evaluación y se llevará a cabo mediante el uso de GNU Radio [3].
El framework de código abierto GNU Radio (ver Sección 2.3) es una
herramienta utilizada en el campo del procesado de señal para emular una
transmisión real con hardware de propósito general, o incluso para simulación.
Objetivos / 3
La utilización de GNU Radio implica que la implementación se realice utilizando
Python (ver Sección 2.2), o bien Python y C++, como lenguajes de programación.
Con todo, el problema que se ha solventado en el presente Proyecto Fin de
Carrera es el desarrollo de un sistema RFID que implemente el funcionamiento de
FSA y se base en el estándar EPC, con posibilidad de desplegarlo en un entorno
real en posteriores trabajos. Para ello se ha diseñado utilizando el lenguaje de
programación Python en el marco del conjunto de librerías de GNU Radio.
1.3.
Objetivos
Tras lo relatado anteriormente se puede concluir que el principal objetivo del
Proyecto Fin de Carrera es diseñar un sistema RFID abierto que utilice
FSA como esquema de acceso al medio y base su funcionamiento en el
estándar EPC.
Este objetivo general se compone de los siguentes objetivos específicos:
1. Diseñar un sistema bajo una plataforma de código abierto gratuita que,
si bien se utilizará con propósitos de simulación, permita en el futuro el
despliegue en un entorno real.
2. Realizar un diseño del sistema centrado en mostrar el funcionamiento de
FSA.
3. Implementar dos unidades separadas, el lector y la etiqueta, que serán los
participantes del sistema.
4. Realizar una implementación clara y legible en un lenguaje sencillo de interpretar por otros programadores.
5. Implementar un esquema modular que permita la inclusión posterior de otras
funcionalidades extra de forma sencilla.
6. Seguir una metodología de desarrollo que permita evaluar paso a paso el
cumplimiento parcial de objetivos.
1.4.
Estructura de la memoria
El resto de la memoria consta de un total de tres capítulos y un apéndice. Los
capítulos más importantes son el de Materiales y Métodos (Capítulo 2) —donde
se exponen las tecnologías empleadas para acometer el problema, así como la metodología empleada— y el de Resultados (Capítulo 3) —donde se exponen los
resultados del trabajo realizado. El Capítulo 4, Conclusiones, resume los logros
4 / Introducción (C. 1)
conseguidos y las posibles mejoras que se puedan llevar a cabo en la implementación. Por último, en el Apéndice A se describen los atributos y los métodos de
todas las clases construidas.
Capítulo
2
Materiales y Métodos
En este segundo capítulo se describen tanto las tecnologías implicadas en la realización del proyecto como las necesidades materiales para realizar el proyecto y
la metodología empleada para realizarlo. Muchas de las herramientas son muy
conocidas, si bien otras, bien por su novedad o por su especificidad, no lo son
tanto.
2.1.
RFID
Se comenzará con una introducción donde se definirá a grandes rasgos la tecnología
RFID, incluyendo una breve historia y unas referencias al campo de la identificación automática, así como ejemplos de uso de la identificación por radiofrecuencia
en la vida diaria. Posteriormente se hablará del problema del acceso al medio de
transmisión cuando éste es compartido por más de un participante. Para finalizar
la sección se describirá a fondo el protocolo EPC Clase 1 Generación 2, estándar
de facto para las comunicaciones RFID.
2.1.1.
2.1.1.1.
Introducción.
¿Qué es RFID?
En el capítulo de Introducción se ofreció una corta definición de RFID. En
este apartado se recordará y ampliará la definición del término. RFID es la
abreviatura de Radio Frequency IDentification. Se trata de un sistema de
acceso a dispositivos remotos llamados etiquetas RFID, mediante el uso de radio
frecuencia, desde otros dispositivos, llamados lectores RFID [4]. Las etiquetas
contienen, por lo general, un identificador único, de tal forma que, al acceder al
mismo, se proporciona una forma de identificar al objeto al que acompaña. De
hecho, RFID tiene como principal propósito la identificación de objetos por radio
frecuencia, sin necesidad de estar en contacto con el mismo, sino simplemente de
estar en el radio de cobertura del lector.
5
6 / Materiales y Métodos (C. 2)
Un sistema RFID consta de tres elementos:
• Etiqueta RFID
• Lector RFID
• Middleware RFID
Las etiquetas RFID, también llamadas tarjetas, transpondedores RFID o tags
en inglés, son dispositivos activos o pasivos que contienen información sobre el
objeto al que acompañan.
Existen dos tipos de etiquetas, las etiquetas activas y las pasivas. Las activas
se acompañan de una batería para el funcionamiento de la circuitería y la
transmisión de la respuesta, mientras que las pasivas aprovechan el acoplamiento
inductivo para conseguir la energía necesaria desde el lector RFID. Actualmente
las etiquetas pasivas son las más utilizadas por su bajo coste —se puede conseguir
una etiqueta pasiva conforme con el estándar EPC (ver Sección 2.1.3) por unos
$0, 07 [5]— además de ser más pequeñas. Sin embargo las etiquetas activas
permiten rangos de acceso mayores, memorias más grandes, e incluso poder
almacenar información adicional que envíe el lector, aunque su coste suele ser
muchísimo mayor -unos $25 por etiqueta, dependiendo de la funcionalidad
deseada. En general el precio de las etiquetas depende de factores como la
cantidad de memoria, el empaquetado, si es activa o pasiva y su frecuencia de
funcionamiento, entre otros.
El lector RFID es un elemento que entra en interacción con las etiquetas
cuando éstas se adentran en su área de cobertura. Se encarga de leer los datos
necesarios de las etiquetas y transmitírselos al nivel superior, el Middleware RFID.
El Middleware RFID es todo aquel software encargado de procesar la información que el lector RFID recopila de las etiquetas. Podrá, por tanto, identificar cada
uno de los objetos a los que está asociada cada etiqueta gracias al identificador
único que éstas llevan.
2.1.1.2.
La identificación automática
Los sistemas o procedimientos de identificación automática son ampliamente
utilizados en la vida diaria, no sólo en la industria. Por ejemplo, cada vez que
se compra en un supermercado las cajas identifican de forma más o menos
automática el producto que se pretende comprar y, a raíz de ahí, se pueden
extraer numerosas características, como nombre del producto o su precio.
La identificación mediante códigos de barras es el procedimiento de identificación automática más extendido durante las últimas décadas. Los códigos
RFID / 7
de barras EAN (European Article Number ) son los más conocidos, pues
fueron diseñados por la industria alimentaria y están presentes en la práctica totalidad de los productos manufacturados disponibles en cualquier establecimiento.
Sin embargo la identificación automática ha avanzado mucho en los últimos
años, y tenemos sistemas de identificación automática por Reconocimiento Óptico
de Caracteres (OCR), mediante medidas biométricas (como por ejemplo la
identificación por huellas dactilares o por voz), por medio de tarjetas inteligentes
(smart-cards), o incluso por radiofrecuencia —sistema que nos atañe a nosotros—
usando RFID [6].
Las smart-cards son dispositivos electrónicos de almacenamiento que en
la mayoría de los casos poseen una pequeña capacidad computacional. Para
comodidad son fabricadas en plástico y con tamaño estandarizado, como las
tarjetas de crédito. Típicamente contienen uno o varios bancos de memoria
que pueden ser encriptados fácilmente, y en algunos casos pueden contener
microprocesadores para realizar operaciones concretas.
Los sistemas que utilizan smart-cards y los que utilizan RFID están cada vez
más relacionados. Esto es debido a que se ha conseguido integrar en las tarjetas
inteligentes un transpondedor que es el encargado de recibir y transmitir datos y
energía de funcionamiento. Mientras que las smart-cards tradicionales funcionan
por contactos, estas nuevas tarjetas reciben el nombre de contactless puesto que
no necesitan contacto alguno con el lector, es decir, funcionan por ondas de radio.
Dadas las grandes ventajas que el sistema RFID proporciona, y gracias a las
tarjetas inteligentes sin contacto, dicho sistema se está implantando en muchos
aspectos de la vida cotidiana. Un ejemplo de ello es la aplicación de RFID a
la identificación de trabajadores en una empresa utilizando tarjetas inteligentes
contactless.
2.1.1.3.
Historia de RFID
El origen de RFID no es bien conocido, si bien el primer trabajo científico
sobre RFID data de 1948, expuesto en un artículo de Harry Stockman titulado
Communication by Means of Reflected Power [7]. En dicho documento se explora
la comunicación a través de la reflexión de la energía que llega al dispositivo (lo
que conocemos como etiquetas pasivas actualmente). Sin embargo postuló que
todavía era necesario un considerable trabajo de investigación antes de poder
solucionar los problemas que afectaban a este tipo de comunicaciones de potencia
reflejada.
Antes de la investigación de Stockman, en la Segunda Guerra Mundial,
investigadores británicos diseñaron un sistema capaz de identificar sus aviones
para evitar el llamado “fuego amigo”. Dicho sistema consistía en devolver una
respuesta a una señal recibida. En función de si la señal recibida era correcta o
no, el avión era identificado como amigo o enemigo. Los aparatos instalados en las
aeronaves recibían el nombre de transpondedores y eran dispositivos capaces de
recibir señales en una frecuencia y transmitir en otras. Sin embargo otros autores
señalan que fue la Unión Soviética, también en la Segunda Guerra Mundial,
la que diseñó las primeras etiquetas pasivas, pero en realidad eran dispositivos
de escucha secretos, con lo que la finalidad de identificación no estaba demostrada.
El desarrollo del radar y de RFID ha ido muy de la mano, ya que el fin
del segundo es la identificación mediante ondas de radiofrecuencia. La diferencia
fundamental radica en que RFID intercambia información entre el lector y el
objeto a identificar, mientras que el radar posiciona elementos en el espacio sin
que el objeto detectado realice ninguna acción.
2.1.1.4.
Aplicaciones prácticas
Por la descripción teórica que se ha facilitado se puede pensar que RFID es un sistema que sólo se encuentra en entornos industriales y no tiene ninguna aplicación
en otros sectores. Nada más lejos de la realidad, pues RFID está muy presente en
varios aspectos de la vida diaria. A continuación se ofrecerá una enumeración de
ejemplos de situaciones en las que RFID está presente.
Pasaporte biométrico o electrónico. A partir de 2006 en los países de la
Unión Europea se fue generalizando la expedición del conocido como pasaporte
electrónico. Estos nuevos pasaportes, aparte de su aspecto tradicional, incluyen un
chip RFID que contiene, además de los datos personales, otros datos biométricos,
como huellas dactilares e incluso la fotografía de la persona [8]. El objetivo de
este nuevo pasaporte es combatir las falsificaciones, tanto del documento como
de la personalidad, pues este chip en general está equipado con un mecanismo
de claves asimétricas que hace que la falsificación sea prácticamente imposible.
En la actualidad este tipo de pasaportes es requerido si se pretende viajar a la
mayoría de los países del mundo (aquellos que están incluidos en la Organización
de Aviación Civil Internacional, unos 185).
Medios de pago. Desde hace varios años se viene utilizando tecnología RFID
para realizar pagos sin necesidad de contacto. Esto sucede, por ejemplo, en las
carreteras de peaje, tanto españolas como de otros países. Este sistema requiere
de un transpondedor colocado en el coche que responderá al lector o lectores
colocados sobre pórticos en las estaciones de peaje.
RFID / 9
También merece especial atención el uso de transpondedores RFID implantados bajo la piel, que son utilizados en bares y parques de atracciones como medio
de pago para sus clientes más exclusivos. En España esta tecnología es utilizada,
por ejemplo, en el Baja Beach Club de Barcelona, donde se implantan transpondedores de la marca Verichip debajo de la piel de la mano para que los clientes
VIP puedan ser identificados y puedan pagar sus consumiciones (esto se consigue
asociando el identificador con los datos del cliente en una base de datos y con una
cuenta de débito donde se van adeudando las mismas) [4].
Identificación de mascotas. El llamado chip. El conocido microchip es también un sistema RFID que está destinado a la identificación electrónica de animales. Las mascotas, según la legislación española, están obligadas a estar identificadas, incluso aquellas que no salen de casa. La identificación de la mascota con un
transpondedor RFID es la manera más eficaz, pues las placas colocadas en el collar
pueden desprenderse o ser retiradas con facilidad. El transpondedor se implanta
en los animales, normalmente a la altura de la nuca, y al ser identificado por un
lector, éste envía un identificador único que, introducido en una base de datos, nos
dará la información del propietario. En la Comunidad de Madrid la implantación
del chip es obligatoria en perros y gatos y está regulado por la Orden 11/1993 de
12 de Enero.
Tarjetas inteligentes sin contacto. Las tarjetas contactless cada vez están
ganando más protagonismo en la vida diaria. Introducidas recientemente en el
transporte público en la ciudad de Madrid, estas tarjetas se vienen utilizando
de manera especial en este sector desde hace algunos años, bien como tarjetas
monedero o como tarjetas que contienen abonos temporales. Otros usos de estas
tarjetas son la identificación de los trabajadores (en las tarjetas de empleado).
RFID en logística. El uso de RFID en el campo industrial para identificación
de mercancías es la aplicación más importante actualmente. Mediante este
sistema una empresa puede tener constantemente localizados todos los artículos
existentes en su almacén, o incluso en la cadena de producción cuando están
siendo fabricados. El estándar EPC (ver Sección 2.1.3) define un sistema cuyo
principal propósito es la identificación de elementos mediante su identificador
único (identificador EPC, de 96 bits), de tal forma que se pueda mantener un
control continuo de la ubicación del objeto. EPC es el estándar más ampliamente
utilizado en logística [4].
Los nuevos retos que se le plantean a los sistemas RFID en el campo de la
logística son:
• Grandes distancias de lectura (sistemas RFID de largo alcance).
• Gran número de etiquetas (por ejemplo para manejar palets con cientos de
elementos provistos con etiquetas).
• Alta velocidad de lectura (por ejemplo cuando un toro mecánico cargado
pasa por un arco lector en un almacén).
2.1.2.
Control de acceso al medio (MAC)
El Control de acceso al medio (MAC de sus siglas en inglés) es un mecanismo
por el cual dos o más interlocutores se ponen de acuerdo para transmitir en
un medio de transmisión compartido, de tal forma que todos los mensajes
puedan ser entendidos en recepción. Esto no implica necesariamente que sólo un
interlocutor transmita en cada instante, como veremos a lo largo de este apartado.
RFID es un sistema que funciona con un único medio de transmisión. Por ello
RFID debe utilizar un MAC, ya que tendremos una o más etiquetas que quieren
comunicar su respuesta al lector, utilizando para ello el aire como medio de
transmisión. El aire es compartido por todos ellos y, si se diera el caso en el que
todos actuaran sin mecanismo de control, la comunicación sería prácticamente
imposible.
Todos los mecanismos de acceso al medio se pueden clasificar en cuatro grandes
grupos. Estos son:
• Acceso múltiple por división en espacio (SDMA)
• Acceso múltiple por división en frecuencia (FDMA)
• Acceso múltiple por división en tiempo (TDMA)
• Acceso múltiple por división en código (CDMA)
En la identificación por radiofrecuencia son frecuentes los tres primeros grupos.
Pasamos a analizar cada uno de estos tres relacionándolos con RFID. Para finalizar
explicaremos en detalle el control de acceso al medio que nuestro sistema RFID
(conforme al protocolo EPC) utiliza.
2.1.2.1.
Acceso múltiple por división en espacio (SDMA)
En este esquema se trata de aprovechar la directividad de las antenas para hacer
que sólo le llegue la señal a uno de los transpondedores a la vez y, por tanto, sólo
conteste uno de ellos, es decir, dirigir el rayo a cada uno de los elementos por
separado.
También existen sistemas con SDMA que se componen de arrays de antenas
cubriendo una determinada zona, cada una de las antenas con una cobertura
mucho menor que en un sistema tradicional [9].
RFID / 11
Este tipo de control de acceso es muy costoso por la complejidad de las antenas
que se deben construir, y se utiliza en aplicaciones muy específicas. Más frecuente
es encontrar SDMA en combinación con los demás sistemas.
2.1.2.2.
Acceso múltiple por división en frecuencia (FDMA)
En este caso el canal se divide en diferentes subcanales en frecuencia, uno
para cada uno de los participantes, de tal forma que es posible transmitir
simultáneamente por todos ellos.
El lector transmite en una frecuencia determinada y cada etiqueta responde
en el subcanal que se le ha asignado, o bien si la comunicación va destinada a
una en concreto, el lector transmitirá en la banda asignada a dicha etiqueta. La
complejidad del lector es más que notable, ya que en realidad deberá existir un
transceptor de radio para cada canal. Debido a esto y al hecho de que las comunicaciones lector-etiqueta-lector ocurren durante un período de tiempo (una vez que
la etiqueta se ha identificado no hay más interacción), este tipo de procedimientos
de acceso al medio son utilizados para aplicaciones concretas o, como en SDMA,
combinados con otros métodos.
2.1.2.3.
Acceso múltiple por división en tiempo (TDMA)
Este conjunto de técnicas consigue la comunicación de todas las etiquetas con el
lector a través de la asignación total del canal a cada uno de ellas secuencialmente
en el tiempo. La asignación de los tiempos de acceso al canal la realiza un
agente único de forma centralizada o bien se realiza automáticamente y de
forma distribuida por todas las etiquetas. TDMA es el grupo al que pertenecen
la mayoría de los esquemas de acceso al medio utilizados en RFID en la actualidad.
Los procedimientos de acceso en los que las etiquetas deciden son procedimientos asíncronos, pues no es el lector el que controla la transferencia de datos.
Se denominan procedimientos de acceso al medio síncronos cuando el lector es
quien asume el control del medio. Por tanto, todas las etiquetas necesitan seguir
las órdenes del mismo en todo momento. Estos mecanismos cumplen su función
de la siguiente forma:
1. Se selecciona un transpondedor siguiendo un cierto algoritmo.
2. La comunicación tiene lugar exclusivamente entre ese transpondedor y el
lector.
3. Una vez terminada la comunicación se repite el proceso seleccionando otro
transpondedor.
La forma de seleccionar un transpondedor puede ser: por polling o encuesta, o
por búsqueda binaria. Ambos métodos requieren que los transpondedores utilicen
algún tipo de numeración única. El esquema de Polling requiere conocer una
lista de identificadores de todas las etiquetas a su alcance. Sin embargo mediante
búsqueda binaria el lector es capaz de determinar qué etiquetas están a su alcance
provocando que todas las etiquetas transmitan a la vez su identificador único y
viendo en qué bits se ha producido colisión.
2.1.2.4.
La familia ALOHA, Frame Slotted Aloha y RFID
ALOHA es el procedimiento de acceso al medio más sencillo. Es asíncrono y
consiste en transmtir en el instante en el que se necesite, sin tener en cuenta
que otra etiqueta lo esté haciendo, por lo que el acceso al medio de produce de
manera aleatoria. Pertenece a la familia TDMA. Este procedimiento es bastante
ineficiente, pues se ha demostrado que puede obtenerse un máximo de un 18,4 %
de rendimiento, es decir, en caso de saturación, aproximadamente sólo 1 de cada
5 veces que se transmite se consigue hacerlo correctamente.
ALOHA se inventó para la red ALOHAnet, una red creada en 1970 por la
Universidad de Hawaii para conectar sus centros entre sí, de una manera similar
a ARPANET [6]. La diferencia es que ALOHAnet estaba basada en radioenlaces,
pues los centros estaban repartidos por las diferentes islas. Por tanto ALOHA no
es un sistema utilizado exclusivamente para RFID.
Para conseguir ampliar el rendimiento del sistema se inventó ALOHA ranurado, o en inglés Slotted ALOHA. Este sistema introduce una serie de divisiones en
tiempo o slots, de tal forma que cada etiqueta sólo puede emitir en el inicio del
mismo. Con ello se consigue elevar el rendimiento al 36,8 %, pero se requiere un
esfuerzo grande en sincronización.
En concordancia con ALOHA ranurado se desarrolló un sistema para tratar
las colisiones que puedan ocurrir cuando existe más de un transpondedor en la
zona de cobertura. Para ello los transpondedores están dotados de un número de
identificación único, y además se definen una serie de comandos para sincronizar
y controlar el funcionamiento de los transpondedores en el radio de acción del
lector. Un breve resumen de los comandos genéricos se puede encontrar en la
Tabla 2.1.
Posteriormente nació FSA. Este sistema, que es el utilizdo para RFID en el
estándar EPC (ver Sección 2.1.3), funciona como ALOHA ranurado pero con
algunos matices: los slots se agrupan ahora en tramas (en inglés frames), que no
tienen longitud prefijada (se fijan por el lector). Todas las comunicaciones deben
establecerse en una trama, cuyo tamaño es conocido por las etiquetas cuando el
RFID / 13
Tabla 2.1. Comandos de Slotted ALOHA para evitar colisiones.
Fuente: [6]
REQU EST
Sincroniza todos los transpondedores en la zona de cobertura del lector para empezar a transmitir sus números serie al lector (SNR). Los transpondedores decidirán
transmitir en uno de los siguientes L slots (L es fijo o
bien se establece por medio del REQUEST.
SELECT (SN R) Se selecciona un transpondedor en concreto que ha respondido correctamente al REQUEST, reemitiendo su
número serie. Las etiquetas que no tienen como número
serie SNR ignoran el comando.
READ_DAT A
El transpondedor que ha sido correctamente identificado
envía datos al lector mediante este comando
lector inicia la misma (comando genérico Request). Entonces cada etiqueta escoge
aleatoriamente uno de los slots y llegado el mismo transmitirá un identificador
(el inicio de cada uno de estos slots es indicado por el lector). Si dos etiquetas
han elegido el mismo slot para transmitir se producirá una colisión, y provocará
que la identificación falle (si el lector no puede o no sabe recuperar alguno de los
identificadores). En este caso las etiquetas que han provocado la colisión se silenciarán y deberán esperarse a la siguiente trama para ser identificadas por el lector.
Cuando se selecciona una etiqueta determinada, el lector pausa la ronda y
efectúa las operaciones que debe realizar antes de continuar con la misma. La
etiqueta identificada se silencia —bien de manera explícita mediante un comando
del lector o bien implícitamente tras la finalización de las operaciones— y no
actúa más en esa identificación.
Por tanto, con FSA el lector RFID será el responsable de iniciar y controlar
las comunicaciones que se produzcan en el sistema. Este procedimiento de acceso
al medio sigue el mismo procedimiento anticolisiones que ALOHA ranurado.
2.1.3.
2.1.3.1.
El Protocolo EPC
Introducción
El protocolo EPC Class-1 Generation-2 para RFID es un estándar publicado
por la EPCglobal Inc. [1], y posteriormente reconocido por la Organización
Internacional de Estandarización mediante el ISO 18000-6C [2]. En él se definen los requisitos, tanto físicos como lógicos, de un caso concreto de sistema RFID.
Las particularidades de este sistema son:
• Consta de etiquetas pasivas.
• El primero en establecer la comunicación es el lector RFID (Interrogatortalks-first).
• Opera en el rango de frecuencias de 860MHz a 960 MHz (dentro de la banda
UHF).
El lector transmite información a las etiquetas a través de una señal modulada
en el rango descrito. Las etiquetas (que son pasivas y, por ello, no tienen fuente
de alimentación) reciben la energía que requieren para funcionar de esta onda de
radio, además de procesar la información que ésta transporta y respondiendo con
una señal de vuelta al lector. Las comunicaciónes entre lectores y etiquetas son
half-duplex, es decir, cuando los lectores transmiten, las etiquetas sólo reciben y
viceversa.
Por tanto, de todos los posibles sistemas que RFID permite construir, el
presente proyecto se centrará en el sistema que el protocolo EPC define.
A continuación se detallarán todos los aspectos del protocolo que se necesitan para el presente proyecto. Esto incluye cómo funciona, los comandos que se
definen (algunos son obligatorios y otros opcionales), los dos entes principales (la
etiqueta y el lector), cómo transcurre el proceso de inventariado y, por último,
una recomendación acerca de la elección del tamaño de trama.
2.1.3.2.
Funcionamiento: la capa de identificación de etiquetas
El Protocolo EPC crea un modelo de dos capas: la capa física y la capa de
identificación de etiquetas. Como el objeto de este proyecto es implementar
etiquetas y lectores en el entorno GNU Radio, no nos debemos ocupar de las
especificaciones de la capa física. Explicamos ahora el funcionamiento de la
segunda capa, que podríamos decir que es la lógica del protocolo.
El lector RFID, como ya se ha expuesto, es el primero en establecer comunicación con las etiquetas que se encuentran en su radio de acción. Por tanto será
el encargado de dirigir la transmisión. El funcionamiento del lector se basa en
tres operaciones básicas: Selección, Inventariado y Acceso.
En la selección, el lector escoge un conjunto de etiquetas de toda la población
que se encuentra en su radio de acción. El comando que utilizará es Select, y
provocará que en las etiquetas se cambien determinados indicadores, en inglés
flags (ver Sección 2.1.3.3). De esta forma podemos seleccionar para su posterior
RFID / 15
identificación ninguna, una o varias etiquetas disponibles dependiendo de si éstas
cumplen las condiciones impuestas por el usuario.
En el inventariado se utilizan varios comandos. El comando que inicia esta
operación es Query, y mediante este procedimiento se pretende identificar una
a una las etiquetas en cobertura, siempre y cuando cumplan los parámetros
que acompañan al comando (como se estudiará en la Sección 2.1.3.5). Esas
condiciones se evalúan sobre el estado de los indicadores de la etiqueta.
En la Tabla 2.1 se definieron los comandos genéricos anticolisiones de ALOHA
ranurado. La operación de inventariado en el estándar EPC es, en definitiva, una
adaptación de estos comandos a FSA y a dicho estándar.
Por último, la operación de acceso consiste en leer y/o escribir datos de/en
una etiqueta. Para ello se utilizan varios comandos, y requiere que se haya
identificado correctamente a la etiqueta en el momento justo anterior.
Las etiquetas pueden funcionar en un escenario con un máximo de cuatro
lectores. Esta es una limitación necesaria ya que las etiquetas necesitan saber si
ya han sido identificadas por cada lector y, a tal efecto, mantienen un indicador
para cada uno, como se describe en el siguiente subapartado. Esto se articula a
través de un mecanismo de cuatro sesiones en el que los lectores pueden realizar
las operaciones de selección, inventariado y acceso de manera secuencial (es decir,
no pueden funcionar a la vez pero sí uno a continuación del otro), asignándose a
cada uno una sesión distinta.
2.1.3.3.
Las etiquetas EPC
Las etiquetas EPC son transpondedores RFID que utilizan la llamada backscattermodulation [6]. Esto convierte al sistema RFID en un sistema similar al de radar,
en el cual el lector proporciona la señal de RF que se utiliza en ambos sentidos
de la comunicación (de lector a etiqueta y viceversa). Las etiquetas responden a
los comandos del lector modulando la potencia incidente y reflejando esta señal
“al vuelo” de vuelta al lector.
Este sistema permite además que la circuitería de las etiquetas EPC pueda ser
alimentada por el campo eléctrico incidente que llega desde el lector (etiquetas
pasivas), separando la componente continua de dicha señal incidente. También
tienen cabida las llamadas etiquetas semi-pasivas o pasivas asistidas, que
incorporan una batería para alimentar el circuito, de tal forma que no dependen
de la potencia proporcionada por el lector para funcionar, pero se comunican
mediante la energía que llega desde el lector. Esto proporciona una respuesta
más rápida y aumenta la distancia desde la que se puede identificar respecto a
las etiquetas pasivas. En cualquier caso el estándar EPC no contempla aquellos
transpondedores que contienen fuente generadora de potencia para transmitir, lo
que comúnmente se conoce como etiquetas activas.
Figura 2.1. Backscattering en etiquetas pasivas.
Fuente [4]
La Figura 2.1 representa precisamente un sistema que implementa
backscattering. El lector envía una señal con un comando, la etiqueta (pasiva) extrae la componente continua de la misma para la alimentación de la
circuitería y envía una respuesta de vuelta al lector a través la señal que viene
del mismo.
El protocolo define los requisitos de memoria, así como todas las posibles
respuestas a los comandos obligatorios y opcionales (ver Sección 2.1.3.5), y una
máquina de estados que proporciona una buena vista general del funcionamiento
de las etiquetas.
La memoria de las etiquetas EPC está dividida lógicamente en cuatro bancos,
que pueden contener cero o más elementos. Estos son: Reserved, EPC, TID y
User. Cada uno de ellos empieza en la dirección 0x00 y contienen cero o más
palabras de 16 bits. Los comandos que acceden a memoria deben especificar a
qué banco y a qué dirección de ese banco desean acceder (esto último conforme
al estándar EBV especificado en el Anexo A de [1]).
Para llevar a cabo el funcionamiento del protocolo las etiquetas necesitan una
serie de indicadores, almacenados de manera especial y que deben ser persistentes
en el tiempo conforme a las especificaciones del protocolo. Esto quiere decir que
deberán almacenar su estado previendo cortes de corriente y que éstos valores
estén disponibles tras el restablecimiento de la alimentación en la manera en que
el protocolo lo requiere (ver Tabla 6.16 de [1]). Dichos indicadores son de dos
tipos y los definimos a continuación:
1. Indicadores de inventariado o indicadores de sesión. Las etiquetas
pueden ser inventariadas en cuatro sesiones diferentes. Estas sesiones posibilitan que se pueda utilizar más de un lector para inventariar la población
RFID / 17
de etiquetas, pero nunca una única etiqueta participará en varias rondas de
inventariado a la vez. Para cada una de las sesiones (S0, S1, S2, S3) la etiqueta mantendrá un indicador, que podrá tomar el valor A o B. Al principio
de cada ronda el lector decidirá qué sesión utiliza y qué objetivo tiene (si las
etiquetas ‘A’ o las etiquetas ‘B’). Cuando una etiqueta está correctamente
identificada ésta invierte de forma automática el valor de su indicador de
inventariado, silenciándose implícitamente. Este es el único recurso que no
comparten las sesiones en las etiquetas. Todo lo demás es compartido entre
las sesiones.
2. Indicador SL. Es un único indicador cuyo valor puede cambiar a través
del comando Select (ver Sección 2.1.3.5). Los lectores podrán configurar la
ronda de identificación para que las etiquetas participen o no en la misma
dependiendo del valor de dicho indicador: de esta forma participarán sólo
las etiquetas cuyo valor de SL coincida con el especificado y su indicador de
inventariado para la sesión deseada se encuentre en la posición adecuada.
Sin embargo también puede hacerse caso omiso de este indicador y, por
consiguiente, sólo se haga caso al valor del indicador de inventariado para la
sesión en concreto.
Como se ha comentado ya, en el estándar podemos encontrar una forma de
implementación de las etiquetas, basada en una máquina de estados con siete
estados. En la Figura 2.2 podemos encontrar el diagrama de la misma, formada
por los siguientes estados: Ready, Arbitrate, Reply, Acknowledged, Open, Secured y
Killed. Cada uno de ellos se relaciona con una operación diferente. Así, en el estado
Ready, la etiqueta se encuentra en reposo y no participa en ninguna ronda de
inventariado, en los estados Arbitrate, Reply y Acknowledged la etiqueta participa
en la operación de inventariado y en los estados Open y Secured, una vez que el
lector dirige los comandos hacia ella en exclusiva, se participa en una operación
de acceso. Por último el estado Killed significa que la etiqueta está deshabilitada
total y permanentemente. La operación de selección puede producirse en cualquier
estado y acarreará siempre la vuelta al estado Ready.
2.1.3.4.
El lector EPC
EPC proporciona un alto grado de libertad en la implementación del lector,
aunque establece algunos requisitos para el mismo. El lector debe implementar
los comandos obligatorios y debe implementar toda la señalización necesaria
descrita en el protocolo, respetando el funcionamiento que ya se ha explicado
en la Sección 2.1.3.2. Además se puede deducir de la especificación que el lector
deberá alimentar con potencia suficiente su radio de acción, para que así las
etiquetas puedan operar.
Figura 2.2. Máquina de estados de las etiquetas EPC.
Fuente [1]
Puesto que el estándar no proporciona una implementación cerrada del lector,
en el mercado es posible encontrar una gran variedad de tipos de funcionamiento
entre los lectores conformes al estándar EPC. Entre las diferencias de funcionamiento se puede destacar, por ejemplo, la selección del tamaño de la trama:
mientras que unos lectores tienen un tamaño fijo, otros implementan un algoritmo
para variarlo en función de las etiquetas que les rodeen.
2.1.3.5.
RFID / 19
Comandos
Los comandos son los mensajes emitidos por el lector para poder llevar a cabo
las operaciones de selección, inventariado y acceso. Son recibidos por todas las
etiquetas presentes en la zona de cobertura, aunque dependiendo de una serie de
factores pueden ser ignorados por las mismas. Existen cuatro tipos diferentes de
comandos:
1. Comandos obligatorios. Estos comandos están incluidos en el protocolo y
deben ser implementados para que el dispositivo sea conforme con el estándar.
2. Comandos opcionales. También están incluidos en el protocolo pero no es
necesario implementarlos. Sin embargo si en el lector se implementa un comando opcional, las etiquetas deben ser capaces de interpretarlo y responder
conforme al protocolo.
3. Comandos propietarios. Este tipo de comandos no están incluidos en el
estándar, al ser definidos por cada fabricante. Sin embargo estos comandos
no deben ser utilizados en entornos finales, únicamente con propósitos de
fabricación.
4. Comandos personalizados. Por último, este grupo de comandos es el que
añade funcionalidad añadida a las etiquetas de un determinado fabricante. No deben ser utilizados antes de identificar a una etiqueta en concreto
y saber que dicha etiqueta está elaborada por ese fabricante (mediante el
identificador de fabricante contenido en la memoria de la etiqueta, que es
transmitida total o parcialmente al lector en la identificación, como ya se
verá más adelante). De esta forma se sabrá con certeza que una etiqueta
soporta los comandos personalizados. Los comandos personalizados no podrán duplicar la funcionalidad que ya ofrecen los comandos obligatorios y
opcionales.
Vamos a proceder al análisis de cada uno de los comandos obligatorios que
el protocolo describe, centrando nuestra atención en aquellos que están ligados
a las operaciones de selección e inventariado, ya que son éstos con los que se ha
trabajado en este proyecto.
Operación de selección: comando Select. Como ya se ha señalado anteriormente, el comando Select selecciona un conjunto de etiquetas para su posterior
identificación. El efecto que produce en las mismas es la variación de uno de cinco
posibles indicadores: cuatro de sesión (cada una de las sesiones tiene un indicador en la etiqueta) o el indicador SL (Selected ). Este último es común a todas
las sesiones, y su valor puede ser determinante para responder a una ronda de
identificación o no.
Si bien el conjunto de cambios en los indicadores está restringido a las acciones
explicadas en la Tabla 2.2, transmitiendo sucesivos comandos Select se puede
configurar totalmente el conjunto de etiquetas que el usuario desee identificar.
Los parámetros de este comando son:
• Target. Determina cuál es el indicador que va a cambiar el comando, si
procede
• Action. Especifica la acción a realizar tras comprobar si se cumple la condición. La Tabla 2.2 expone las posibles acciones.
Tabla 2.2. Acciones tras un Select. Fuente: [1]
Action
000
001
010
011
100
101
110
111
Coincidente
SL a ‘1’ o ind. sesión a ‘A’
No hacer nada
Negar SL o cambiar ind. sesión
SL a ‘0’ o ind. sesión a ‘B’
No hacer nada
No hacer nada
No coincidente
No hacer nada
No hacer nada
No hacer nada
Negar SL o cambiar ind. sesión
• MemBank, Pointer, Length y Mask. Son parámetros que se encargan de
localizar el segmento de memoria que va a ser sometido a comparación,
así como el patrón con el que hay que comparar. La operación de Select
tendrá como resultado coincidente o no coincidente dependiendo de si el
parámetro Mask es igual al contenido de la memoria de la etiqueta en las
Length posiciones después de la dirección señalada por Pointer, en el banco
de memoria que indica MemBank.
• Truncate. Es un indicador que muestra a la etiqueta si la respuesta que debe
dar tras un comando ACK debe ser truncada (sólo se transmite una parte de
la misma) o no. Sin embargo no sólo con activar este indicador es suficiente
para que se produzca este cambio de comportamiento. Para que una etiqueta
responda de manera truncada se debe dar que: el indicador Truncate haya
sido activado en el último Select antes de empezar la ronda, que el destino de
ese Select sea el indicador SL y que la máscara esté definida en el rango del
banco de memoria EPC. La respuesta truncada puede obtenerse con detalle
en [1].
RFID / 21
Aparte de todo ello, el comando lleva un código de redundancia cíclica de 16 bits,
que permite comprobar que el comando se ha recibido sin errores, tal y como
lo creó el lector. Si el comando tuviera errores, las etiquetas están obligadas a
desecharlo.
Inicio de la Operación de Inventariado: comando Query. Este comando
inicia y configura una trama de FSA (ver Sección 2.1.2.4). En EPC una trama
corresponde a una Ronda de inventariado. En esta ronda participarán únicamente
aquellas etiquetas que cumplan los requisitos que dentro de este comando se especifican. Los campos que incluye este comando van dirigidos tanto al nivel físico
como al de identificación. Los campos del nivel físico son:
• DR. Indica la frecuencia de funcionamiento de la comunicación etiquetaslector.
• M. Indica el tipo de modulación que se utilizará.
• TRext. Indica si las comunicaciones etiqueta-lector requieren un tono piloto.
En algunos comandos se emitirá un tono piloto independientemente del valor
de este campo.
Para la capa de identificación tenemos los campos que hacen relación a la
configuración de la trama FSA. Estos son:
• Sel. Este campo determina qué etiquetas responden al inventariado en lo
que respecta al indicador SL. Se puede elegir que no se tenga en cuenta este
indicador o que participen sólo los que lo tengan activado (o desactivado).
• Session. Se elige una de las cuatro sesiones disponibles para la ronda de
inventariado.
• Target. Indica qué etiquetas participan en la ronda, atendiendo al estado de
su indicador de sesión. Se puede ordenar una ronda de inventariado sobre
las etiquetas cuyo indicador esté en la posición A o sobre las que tengan el
mismo en la posición B. No se puede empezar una ronda de inventariado
sobre ambos valores del indicador.
• Q. Q configura el tamaño de trama (número de slots de cada trama). Es un
número de 0 a 15. Las etiquetas tendrán disponibles 2Q slots para responder
al lector con un entero (este funcionamiento se explicará más adelante).
Continuación de la ronda: comando QueryRep. Este comando indica a las
etiquetas el inicio de cada slot de la trama para que éstas respondan. Sólo contiene
un campo, la sesión en la que el lector está trabajando (S0, S1, S2 ó S3). En cada
ronda de inventariado se utilizarán tantos QueryRep como slots haya definido el
lector.
Modificación de la ronda: comando QueryAdjust. Mediante este comando
el lector puede interrumpir la ronda de identificación actual e iniciar una nueva
con las mismas características pero modificando el tamaño del mismo. Tras la
recepción de este comando las etiquetas que participaban en la ronda y no están
aún identificadas modifican el valor de Q (o lo dejan intacto, según el campo
UpDn) y vuelven a empezar. Aquellas etiquetas ya identificadas no responden ni
participan puesto que están silenciadas. Ningún otro parámetro de la ronda se ve
alterado.
Los campos que contiene un QueryAdjust son:
• Session.
• UpDn. Establece si el valor de Q debe ser incrementado en una unidad,
decrementado en una unidad o, por el contrario debe ser mantenido, con
respecto a Q de la trama anterior.
Asentimiento de recepción del entero: comando ACK. El lector envía el
comando ACK a las etiquetas para asentir a una determinada etiqueta. Lo único
que contiene ACK es un identificador temporal de la etiqueta.
Error: comando NAK. Cuando el lector no ha podido extraer correctamente
la respuesta de una etiqueta (o bien ha habido colisiones) el lector envía un NAK.
Ninguna etiqueta responderá a este comando, únicamente las que enviaron su
respuesta constatarán que la identificación no ha tenido éxito y deberán esperar a
una nueva ronda para ser identificadas. Al no haberse producido la comunicación
con éxito no modificarán su indicador de sesión.
Comandos de acceso. Estos comandos sólo pueden ser enviados por el lector
una vez que una etiqueta ha sido identificada correctamente. Los comandos están
dirigidos a dicha etiqueta y todas las demás deberán ignorarlos. A continuación
se expone una breve descripción de los mismos.
Solicitud de un nuevo entero: comando Req_RN. Este comando solicita a la etiqueta un nuevo número entero para proceder a la lectura de los datos
que contiene.
Lectura: comando Read. Mediante este comando el lector puede leer parte
o todos los datos de uno de los bancos de memoria de los que la etiqueta está
formada.
Escritura: comando Write. Este comando permite escribir datos en la
etiqueta.
RFID / 23
Deshabilitación de la etiqueta: comando Kill. Con este comando obligatorio se consigue desactivar una etiqueta para que no pueda volver a responder
a ninguna ronda de inventariado. Las etiquetas contienen en su interior una contraseña de Kill, de 32 bits. Para poder desactivar una etiqueta se necesita esta
contraseña en el lector y enviarlo hacia la etiqueta de la siguiente forma: El lector
deberá enviar dos comandos Kill para que sea ejecutado con éxito, en el primero
enviará los primeros 16 bits de la misma aplicando XOR con un número aleatorio (solicitado a la etiqueta previamente) y en el segundo enviará los últimos 16
bits, también aplicando XOR con otro número aleatorio (solicitado entre el primer
comando Kill y el segundo).
Bloqueo de memoria: comando Lock. Mediante este comando se permite
al lector bloquear tanto la contraseña de Kill para que no se pueda leer o cambiar,
como un banco de memoria completo para que no se pueda escribir en él. La acción
puede ser temporal o permanente.
2.1.3.6.
La ronda de inventariado
Una vez se conocen los detalles del protocolo, en esta sección se describe cuál es
el procedimiento normal de funcionamiento del sistema. La ronda de inventariado
como tal no utiliza los comandos de acceso, pues su único objetivo es detectar las
etiquetas e identificarlas.
La ronda de inventariado necesita previamente de una o varias operaciones de
selección para seleccionar un subgrupo de etiquetas de todas las que están dentro
del alcance del lector. Esto se lleva a cabo por parte del lector enviando uno o
varios comandos Select con las opciones deseadas. El efecto de esta operación es
modificar los indicadores de las etiquetas de tal forma que, mediante el comando
Query posterior, participen sólo aquellas que deseemos que participen. Si no se
efectúa esta operación no sabremos cuáles de ellas participarán en la ronda de
inventariado.
Una vez que tenemos las etiquetas seleccionadas se puede empezar la operación de inventariado, lo que se conoce como Ronda de Inventariado o, en
términos de FSA, trama. Para ello el lector envía un comando Query en una de
las cuatro sesiones, especificando si la ronda pretende identificar a las etiquetas
cuyo indicador de sesión está en A o en B y, además, si todas las etiquetas participarán o sólo lo harán las que tengan el indicador SL en una posición determinada.
En este momento las etiquetas disponen de 2Q slots para responder al lector.
Esto se efectúa de la siguiente manera: las etiquetas eligen cada una un número
entero aleatoriamente (contador de slots) de 0 a 2Q − 1 siguiendo una distribución
uniforme. Si el número elegido es 0 las etiquetas responderán inmediatamente al
lector, si no cargarán el valor en memoria e irán decrementando dicho valor cada
vez que llegue un QueryRep.
Cuando el valor del contador es 0 las etiquetas responderán al lector con un
número aleatorio de 16 bits. Este número recibe el nombre de RN16. Entonces
el lector, tras la recepción de dicho número, envía un comando ACK asintiendo
el RN16 recibido. A continuación la etiqueta responde (en el caso normal) con
una palabra de control, el contenido del banco de memoria EPC más un CRC de
16 bits. En ese momento la etiqueta se considera inventariada, pues la memoria
EPC contiene el identificador único de la misma. Tras la identificación correcta
de una etiqueta ésta invierte su indicador de sesión de A a B o de B a A. Además
queda silenciada para la ronda actual.
Si dos etiquetas eligen el mismo contador de slots y, por tanto, responden a
la vez en un slot determinado, se producirá una colisión. Si el lector detecta
la colisión y no es capaz de extraer al menos uno de los RN16 de una de las
etiquetas, envía un comando NAK. Estas etiquetas no podrán ser identificadas
en esta ronda y tendrán que esperar a la siguiente, siguiendo el funcionamiento
de FSA. EPC articula dicho funcionamiento obligando a las etiquetas a cargar
un valor en el contador de slots tan alto que por más que lo decrementen el fin
de la ronda llegará antes de que las etiquetas consigan tener 0 en dicho contador.
El valor mínimo que asegura esto es 0x8000, puesto que el valor máximo de Q es
15, con lo que el número máximo de slots será K = 215 = 3276810 = 0x8000.
Si una etiqueta está esperando a recibir un ACK y lo recibe pero contiene
un RN16 que no se corresponde con el suyo, actuará de la misma forma que si
recibiera un NAK.
2.1.3.7.
Elección de Q por parte del lector
Los lectores EPC deberán presumiblemente efectuar varias rondas de inventariado para identificar correctamente todas las etiquetas que están a su alcance,
dependiendo de cuántas sean. Un parámetro que influye directamente en ello es
el parámetro Q, que establece el número de slots de la trama, es decir, el número
máximo de etiquetas que se podrían identificar (si no hubiera ningún tipo de
colisión), en una ronda.
Q es un parámetro que se escoge por el lector al inicio de cada ronda y de
una ronda a otra puede ser variado a discrección. Mientras que algunos lectores
comerciales implementan la longitud de la trama variable, la mayoría opta por
escoger un valor al inicio y mantenerlo para todas las rondas siguientes hasta que
se han identificado todas las etiquetas alrededor.
RFID / 25
En [10] se demuestra que FSA alcanza su máximo rendimiento cuando el
número de etiquetas (N ) y el número de slots (K = 2Q : Q = 0, ..., 15) es el
mismo, obteniendo en ese caso un rendimiento del 36 % aproximadamente.
Saber el número de etiquetas que están en la zona de cobertura del lector
no es posible, pues no existe un mecanismo que permita conocer dicho número
antes de identificarlas. Sin embargo a través de las respuestas que se obtienen
sí se puede estimar la población de etiquetas que el lector debe identificar. Es
por ello que existen algoritmos que tratan de estimar el número de etiquetas y
modifican Q para la siguiente ronda. Estos algoritmos establecen un Q inicial
para la primera ronda y empiezan a funcionar a partir de la segunda ronda.
El protocolo EPC contiene en uno de sus anexos un algoritmo para que los lectores puedan variar la longitud de la trama. No es obligatorio implementarlo, sino
que se propone como una posible solución. La Figura 2.3 muestra dicho algoritmo.
Figura 2.3. Ejemplo de algoritmo para escoger Q.
Fuente [1]
Las variables en el diagrama son:
• Qf p es un número real que representa a Q. Se redondeará para obtener el
valor de Q que se utilizará.
• C es un parámetro que controlará el algoritmo dependiendo del valor de
Q. Típicamente 0,1 < C < 0,5, cuanto más grande sea Q menor será C y
viceversa.
Primeramente se elige Q=4. Al final de la ronda pueden ocurrir tres escenarios:
1. Si no responde ninguna etiqueta se decrementará Q. Si el resultado es negativo se selecciona Q=0 (Es decir, K=1).
2. Si responde exactamente 1 etiqueta el valor de Q no varía.
3. Si responden más de una etiqueta se incrementa Q, sin sobrepasar el valor
máximo de Q, que es 15.
Bueno-Delgado y Vales-Alonso en [10] analizan el rendimiento de la identificación en los sistemas EPC a través del uso de Cadenas de Markov discretas. En
el caso en el que Q es igual para todas las rondas, como resultado de este análisis proponen que, para obtener el máximo rendimiento en todo el proceso (no
individualmente en cada trama), se debe seleccionar Q acorde a la Tabla 2.3.
Tabla 2.3. Selección de Q para lectores con Q fija. Fuente: [10]
N
N =1
1<N ≤4
4<N ≤8
8 < N ≤ 19
19 < N ≤ 38
38 < N ≤ 85
85 < N ≤ 165
165 < N ≤ 340
2.2.
Q
0
1
2
3
4
5
6
7
N
340 < N ≤ 720
720 < N ≤ 1260
1260 < N ≤ 2855
2855 < N ≤ 5955
5955 < N ≤ 12124
12124 < N ≤ 25225
25225 < N ≤ 57432
57432 < N
Q
8
9
10
11
12
13
14
15
El lenguaje de programación Python
Una vez que se ha explicado detenidamente qué es RFID y cómo funciona el
estándar EPC, se describe qué herramientas se utilizan para llevar a cabo este
proyecto. Empezamos con el lenguaje de programación Python.
Python es un lenguaje de programación de alto nivel y de código abierto creado
por Guido van Rossum y publicado en 1991 [4]. Es un lenguaje interpretado, es decir, el código se ejecuta por un intérprete. Por ello los archivos de código fuente en
El lenguaje de programación Python / 27
Python suelen ser llamados comúnmente scripts, si bien estos archivos reciben oficialmente el nombre de módulos. Los módulos pueden ir agrupados en paquetes.
Está diseñado para que sea legible y limpio. Además permite programar en
varios paradigmas de programación: programación orientada a objetos, funcional,
imperativa, etc.
Frente a otros lenguajes interpretados, Python destaca por ser fuertemente
tipado y de tipado dinámico. Es decir, en Python existen tipos aunque el tipo de
dato se decide cuando se crea la variable o cuando se le asigna un nuevo valor.
Por tanto podemos tener una variable con un string y asignarle un número entero
en la siguiente línea.
Según la página web de Python [11] los principios diferenciadores de este
lenguaje son:
• Sintaxis clara y legible.
• Fuerte capacidad de introspección en el funcionamiento del mismo.
• Orientación a objetos intuitiva.
• Expresión natural de código procedimental.
• Modularidad total, soportando jerarquía de paquetes.
• Tratamiento de errores mediante excepciones.
• Tipos de datos dinámicos de muy alto nivel.
• Librerías estándar completas y módulos de terceros para prácticamente cualquier tarea.
• Fácilmente extensible mediante código en C/C++ u otros lenguajes.
• Empotrable en aplicaciones como una interfaz de scripting.
2.2.1.
Utilidad para el proyecto.
Python es el lenguaje de programación que se ha utilizado para implementar el
sistema experimental de RFID desarrollado en el presente proyecto.
La utilización de Python en este proyecto presenta dos ventajas:
• La integración de módulos Python en el entorno GNU Radio (ver Sección
2.3) es sencilla mediante el uso del proyecto GrExtras (ver Subsección 2.3.5).
• Existen gran cantidad de librerías desarrolladas para este lenguaje de programación.
La principal desventaja de Python es que la ejecución del código suele ser
más lenta que en los lenguajes de programación compilados. Sin embargo para el
sistema desarrollado Python no representa ningún inconveniente, pues el tiempo no
es un aspecto crítico. Aporta, por tanto, muchas más ventajas que inconvenientes
trabajar con dicho lenguaje.
2.3.
2.3.1.
GNU Radio
Qué es GNU Radio
GNU Radio es un conjunto de librerías open-source que proveen diferentes
funcionalidades para desarrollar los llamados radios definidos por software (SDR,
de sus siglas en inglés) [3]. Se puede utilizar en combinación con hardware o
simplemente para simulación en el ordenador.
Según [4] “Un sistema de Radio Definido por Software (Software Defined
Radio, SDR) es un sistema de radiocomunicaciones donde los componentes
típicamente implementados en hardware (mezcladores, filtros, amplificadores,
moduladores/demoduladores, detectores, etc) son implementados en software,
utilizando una computadora personal (PC) u otros dispositivos de computación
embebida”.
Los sistemas de radiofrecuencia tradicionales llevan a cabo su función a
través de hardware especializado construido ad hoc 1 . Sin embargo GNU Radio
permite que, utilizando hardware de propósito general, se puedan llevar a cabo
multitud de implementaciones diferentes, adaptando dicho hardware a nuestras
necesidades. Dado que los SDR contienen software que funciona en un ordenador,
el procesamiento que se realiza es de tipo digital. El harware se encargará de
la recepción/emisión de señal, de la conversión A/D y D/A, etc. El software se
encargará de los procesos de modulación y demodulación, procesado de la señal
digital, etc.
El hardware de propósito general que GNU Radio utiliza es el llamado USRP
(Universal Software Radio Peripheral ), diseñado y producido por Ettus Research,
LLC., filial de National Instruments. Se conectan al ordenador mediante USB o alguna otra conexión de alta velocidad, e incluso hay algunos modelos que contienen
un microprocesador que les permite actuar en modo autónomo (programándolo).
1
Últimamente también se está desarrollando hardware específico que funciona con SDR, como
algunos lectores RFID, que contienen la mayor parte del procesado de señal en dispositivos
programables.
GNU Radio / 29
GNU Radio funciona a través de bloques, que procesan ininterrumpidamente
señales de entrada y elaboran señales de salida. Estos bloques se escriben normalmente en C++ por cuestiones de velocidad, aunque como se explicará más
adelante existen mecanismos que permiten programarlos en Python. GNU Radio
proporciona numerosos bloques ya escritos y listos para utilizar. Sin embargo, para
nuestra aplicación se necesitan crear todos los bloques utilizados, pues no existen
por defecto en GNU Radio.
2.3.2.
Los bloques de procesado de señal
Empecemos explicando el funcionamiento de los bloques de GNU Radio. Estos
bloques hacen procesamiento de señal en un entorno digital, con lo que su unidad
de trabajo temporal serán muestras. Estas muestras, que llegarán al bloque con
una frecuencia de muestreo determinada, serán procesadas y elaboradas y darán
lugar a una muestra de salida.
Dentro del bloque puede utilizarse prácticamente cualquier algoritmo deseado,
siempre que pueda implementarse en C++ o Python, lenguajes que soporta GNU
Radio. Podrán tener memoria, realizar integración, derivación, etc. Gracias a
librerías matemáticas especializadas (ver Sección 2.4) los lenguajes de programación pueden ser extendidos fácilmente.
Existen diferentes tipos de bloques dependiendo de sus entradas y salidas. Los
exponemos a continuación.
1. Bloques con uno o varios puertos de entrada y uno o varios puertos
de salida. Este es el tipo más común de bloques, y realizan el procesado intermedio. Reciben muestras de otros bloques, las procesan y generan nuevas
muestras que irán a otros bloques.
2. Fuentes. Bloques con ningún puerto de entrada y uno o varios de
salida. Este tipo de bloque se coloca al principio de la cadena de procesado
de señal y provee de muestras de señal a los demás bloques. Estos bloques
son en su mayoría generadores de pulsos, tonos, etc. o incluso bloques que
captan la señal del exterior y la introducen en GNU Radio (por ejemplo
de la entrada de micrófono de la tarjeta de sonido o de alguna entrada del
USRP).
3. Sumideros. Bloques con uno o varios puertos de entrada y ningún
puerto de salida. Estos bloques consumen muestras pero no generan ninguna nueva. Sirven para exportar datos fuera de GNU Radio, por ejemplo
para escuchar las muestras procesadas por los altavoces o para transmitirlas
(con ayuda del USRP) por radiofrecuencia a un receptor.
Aparte de configurar en un bloque el número de puertos de entrada y salida,
deberemos establecer además el tipo de dato que intercabiará ese puerto. Así, los
tipos de datos inicialmente soportados por GNU Radio son cualquiera que pueda
ser implementado en C++. Los más comunes son complex, float, int y short,
entre otros.
Si se quiere crear un nuevo bloque, GNU Radio dispone de una clase llamada
Block de la que debe heredarse. En el constructor de la clase que representa al
nuevo bloque se deberá especificar todas las características del mismo: número de
puertos de entrada, número de puertos de salida, tamaño de cada puerto (o relación entre entrada y salida) u, opcionalmente, si el bloque utiliza otro mecanismo
diferente de intercambio de datos (como veremos más adelante en la Sección 2.3.5).
Además se debe sobreescribir el método work() de la clase madre. El planificador de GNU Radio llamará a work() de cada bloque cuando necesite obtener
datos de él. Esta función debe tener como parámetros dos vectores de arrays, uno
como entrada y otro como salida de datos, y debe devolver el número de elementos
que se han producido.
2.3.3.
Grafos de flujo
En GNU Radio los sistemas de radio son construidos mediante los conocidos
como Grafos de Flujo (flow graphs en inglés). Éstos no son más que grafos en los
que los nodos son los bloques que forman parte del sistema y las aristas son las
conexiones que existen entre los diferentes bloques.
Los grafos de flujo se programan en Python y son, en sí mismos, un tipo
especial de bloque de GNU Radio llamado Top Block. Este bloque será lo que se
ejecute cuando se desee iniciar el sistema que se ha construido.
En los mismos cabe cualquier tipo de implementación de bloques, ya sea en
C++ o Python, siempre que hayan sido expresamente diseñados para GNU Radio,
o bien se pueden incluir alguno de los bloques que la librería ofrece. Para que un
grafo funcione correctamente es necesario que exista, al menos, un bloque fuente
y un bloque sumidero.
2.3.4.
GNU Radio Companion
GNU Radio Companion (GRC) es la interfaz gráfica de GNU Radio. Genera automáticamente el código necesario para interconectar los diferentes bloques que
tengamos que utilizar, es decir, el grafo de flujo. Es una interfaz muy parecida
a Simulink de Mathworks [12] que funciona mediante drag and drop, con lo que
permite generar grafos de manera sencilla y da acceso a todo el potencial que
GNU Radio posee.
GNU Radio / 31
Todos los bloques que incluye GNU Radio están disponibles para utilizar en
GRC. Los bloques creados por el usuario también pueden incluirse escribiendo un
archivo XML con la descripción del bloque. Debido a la escasa documentación que
existe sobre GRC, incluso en el propio sitio web de GNU Radio [3], este proceso es
complicado. Es por esta razón por la que no se ha utilizado GRC en este proyecto,
pues la única ventaja que aporta es la creación de grafos de flujo de manera gráfica.
2.3.5.
GrExtras: extendiendo GNU Radio
El proyecto GrExtras [13] añade características adicionales a GNU Radio. Analizaremos ahora una a una las características que complementan la librería de la
que trata esta sección.
2.3.5.1.
Escribir bloques en Python
GNU Radio está diseñado para ser escrito en C++ y Python. El primero se
utiliza para codificar el procesamiento de señal, ya que es más rápido, mientras
que el segundo es más sencillo de programar y se utiliza para conectar todas las
“piezas” del sistema.
Desde este proyecto se propone la idea de escribir todo en Python, pues es un
lenguaje cuya programación resulta más rápida e incluye muy buenas librerías
con las que trabajar.
Si se quiere crear un nuevo bloque utilizando el lenguaje de programación
Python, GrExtras dispone de la clase Block de la que debe heredarse. El resto
del funcionamiento es igual que para el caso general de GNU Radio. Los arrays
que utiliza GrExtras pertenecen a la librería NumPy (ver Sección 2.4).
Por supuesto para conseguir el fin deseado el bloque puede utilizar toda la funcionalidad de las librerías oficiales de Python y también aquellas proporcionadas
por terceros.
2.3.5.2.
PMT. Serialización de objetos
PMT, PolyMorphic Type, es, a la vez, un tipo de dato y una librería de serialización incluida en GNU Radio [3]. GrExtras proporciona acceso a la misma y
convierte el tipo PMT al objeto PMT en Python. Dicho objeto debe ser utilizado
para paso de mensajes de GrExtras, funcionalidad que se explicará en el siguiente
apartado.
El objeto PMT es un contenedor donde se puede almacenar cualquier variable
serializada, sin importar el tipo de dato, pero por defecto se incluyen métodos
de serialización sólo para los tipos de dato más comunes. Precisamente GrExtras
proporciona para Python dicha funcionalidad, existiendo métodos para la mayoría
de tipos de dato básicos en Python y para el objeto ndarray de NumPy (que se
explicará en la Sección 2.4). Además GrExtras abstrae al usuario del tipo de dato,
pues para serializar y deserializar únicamente se deberá llamar a sendos métodos,
con independencia del tipo de dato.
2.3.5.3.
Paso de mensajes
GNU Radio utiliza como unidad temporal las muestras. En su funcionamiento
normal, el planificador de GNU Radio ejecuta el método work() del bloque
cuando necesita alguna muestra (ver Subsección 2.3.2). Sin embargo para algunas
aplicaciones puede resultar muy complicado trabajar con muestras, como en el
caso de este proyecto. En este aspecto GrExtras incorpora una nueva funcionalidad: el paso de mensajes.
La implementación del paso de mensajes consigue abstraer al usuario del flujo
de datos, y lo que los bloques reciben o envían son mensajes, utilizando instancias
del objeto PMT. El uso de dicho objeto simplifica el proceso, pues los mensajes
que se intercambian contienen únicamente un tipo de dato, el objeto PMT. La
información contenida en el mensaje deberá, por tanto, ser deserializada antes de
poder utilizarse.
Este nuevo mecanismo de intercambio de información utiliza unos puertos
diferentes a los utilizados para el intercambio de muestras, por lo que deberán
ser declarados aparte. Además si se utilizan exclusivamente mensajes para
el intercambio de datos, el método work() sólo será llamado una vez por el
planificador.
Los mensajes intercambiados son instancias de un objeto definido por GNU
Radio y sus tres atributos más importantes son: key, value y srcid (opcional).
Los tres campos deben ser objetos PMT que contengan datos serializados con la
librería.
• El campo key es un identificador único del tipo de contenido.
• value es el mensaje en sí que se desea intercambiar.
• Opcionalmente se puede indicar un campo srcid que identifica de manera
única al emisor del mensaje.
Para leer y escribir mensajes existen sendos métodos que el bloque hereda
de Block. El de recepción es bloqueante hasta que llega un mensaje, y no tiene
en cuenta el puerto de llegada, mientras que el método de envío no detiene la
NumPy / 33
ejecución del hilo. Este último recibe como parámetros los atributos descritos
anteriormente y el puerto por el que se envía.
Este mecanismo de paso de mensajes permite que la implementación del protocolo EPC pueda transmitir los comandos del lector a las etiquetas de una vez y
recibir las respuestas de las etiquetas en el lector también de una vez, y de forma
similar en las etiquetas.
2.3.5.4.
Bloques y API
Todas las características anteriores de GrExtras se sustentan sobre su propia
interfaz de bloques para GNU Radio. Esta interfaz provee APIs para varios tipos
de bloques, para aquellos programadores que no tienen pensado utilizar ninguna
de las otras características de GrExtras pero sin embargo quieren implementar en
C++ diferentes tipos de funcionamiento en cuanto a generación y consumición
de flujos de muestras. Se puede obtener más información sobre los modos de
funcionamiento en [13].
Simplemente se debe heredar de uno de estos bloques “plantilla”, especificar
qué modo de funcionamiento se desea, especificar el procesado en el método
work() y la API será capaz de llevarlo a cabo con el modo de funcionamiento
deseado.
Aparte de esto, GrExtras proporciona bloques ya construidos para diferentes
aplicaciones, la mayoría centrados en explotar el mecanismo de paso de mensajes que esta extensión aporta. Como ejemplo, GrExtras proporciona bloques que
permiten crear sockets TCP/UDP y transmitir o recibir paquetes (o datagramas
UDP), utilizando el mecanismo de paso de mensajes, con lo que podremos utilizar
comunicaciones IP en nuestro procesamiento.
2.4.
El paquete NumPy para Python
Numerical Python, conocido normalmente mediante su abrebiatura, NumPy, es
una extensión de código abierto para Python que proporciona la posibilidad
de trabajar con arrays y matrices [14]. Su principal aporte es el tipo de dato
ndarray, un array multidimensional. Además proporciona funciones matemáticas
para trabajar con dichos arrays.
Fue creado en 2005, a partir de los predecesores Numarray y Numeric, por
Travis Oliphant y está integrado en SciPy, aunque se puede descargar e instalar
por separado. SciPy es un conjunto de librerías que convierten a Python en una
herramienta matemática comparable al software MATLAB de Mathworks, con
módulos para optimización, álgebra lineal, integración, interpolación, funciones
especiales (como la de Bessel), FFT, procesado de señal e imágenes, ecuaciones
diferenciales ordinarias, entre otros.
2.4.1.
El array en NumPy
El tipo de dato que NumPy introduce es un array multidimensional con posibilidad de albergar una gran cantidad de elementos. Al ser un array todos los datos
que contiene son del mismo tipo. Los elementos se localizan mediante una tupla
de enteros positivos empezando en 0.
Los arrays contienen, entre otros, los siguientes atributos:
• ndarray.ndim - Número de ejes (dimensiones) del array.
• ndarray.shape - Dimensiones del array. Por ejemplo (n,m) para una matriz
de n x m elementos.
• ndarray.size - Número de elementos totales del array.
• ndarray.dtype - Tipo de dato de los elementos, bien estándares de Python
o de NumPy. Por defecto el array contendrá datos del tipo numpy.float64
(es decir un número de coma flotante de 64 bits de precisión). Sin embargo
a la hora de crear el array se puede definir el tipo deseado.
Para crear un array de NumPy simplemente debemos instanciar un array que
contenga como parámetro una lista. Esta lista contendrá los elementos del array.
Si queremos crear un ndarray con más dimensiones la lista contendrá listas, una
por cada fila. Opcionalmente, como ya se ha comentado, podremos especificar el
tipo de dato en el momento de la creación.
2.4.2.
Funciones en NumPy
El paquete NumPy contiene, además del tipo de dato ndarray, un conjunto de
funciones para poder trabajar con dichos arrays, y un conjunto de funciones
matemáticas para álgebra lineal, transformada de Fourier y números aleatorios,
para utilizar bien sobre ndarrays o sobre variables escalares.
En cuanto a las funciones para trabajar con arrays podemos destacar funciones
para reorientar los elementos, operaciones aritméticas, operaciones de comparación
entre arrays, o incluso álgebra de matrices.
2.4.3.
Utilidad para el proyecto
El principal aporte de este paquete es la facilidad con la que se puede trabajar
con arrays. Los comandos EPC no son más que colecciones de bits que son empaquetados juntos y se transmiten del lector a las etiquetas. GNU Radio y GrExtras
proporcionan soporte para los arrays de NumPy, con especial atención en el uso
El entorno de desarollo Eclipse / 35
para el paso de mensajes. Por tanto en este proyecto se utiliza NumPy para representar los comandos EPC y las respuestas de las etiquetas, de tal forma que se
pueda utilizar la característica de paso de mensajes que GrExtras proporciona.
2.5.
El entorno de desarollo Eclipse
Eclipse es un entorno de desarrollo integrado de código abierto. Un entorno de
desarrollo integrado, o IDE por sus siglas en inglés, hace referencia a un programa que está compuesto por varias herramientas de programación. Su misión por
tanto es proveer de todo lo que necesita el programador para desarrollar nuevos
programas. Típicamente se componen de [4]:
• “Un editor de texto
• Un compilador
• Un intérprete
• Un depurador
• Un cliente
• Posibilidad de ofrecer un sistema de control de versiones.
• Factibilidad para ayuda en la construcción de interfaces gráficas de usuario.”
El entorno de desarrollo puede ser específico para trabajar con un lenguaje
de programación o puede contener varios. En el caso de Eclipse se incluye principalmente Java, aunque existen extensiones que permiten trabajar con muchos
otros lenguajes. Instalando la extensión PyDev, Eclipse se convierte en un IDE
que provee herramientas útiles para trabajar con Python.
2.6.
Metodología
Antes de finalizar con el presente capítulo se describe la metodología de trabajo
que se ha seguido para implementar el sistema experimental de RFID sobre el
que el proyecto trata.
Como el lector ha podido comprobar a lo largo del capítulo se deberán implementar dos tipos de entidades, el lector EPC y la etiqueta EPC. Entre ellas existe
un intercambio de información, con lo que se tendrá que posibilitar un medio por
el cual ambos sistemas se puedan comunicar. Todo ello enmarcado en GNU Radio.
En el presente Proyecto Fin de Carrera se ha optado por la Metodología de
Desarrollo Incremental [4]. Esta metodología propone que el desarrollo se divida
en varios subproblemas de creciente complejidad, abordando cada uno de los
problemas de manera secuencial. Inicialmente se construye un sistema básico que
cumpla los objetivos más sencillos. En cada paso siguente se toma el sistema
construido en la fase anterior y se actualiza con nuevos requisitos, consiguiendo
finalmente cumplir los objetivos totales.
En concreto la división que se ha efectuado ha sido:
1. Definición de requisitos y características del sistema.
2. Elaboración de las máquinas de estado de lector y etiquetas.
Tras la definición de requisitos, se deberá modificar la máquina de estados de
la Figura 2.2 para adaptarla a los mismos. Para el caso del lector se deberá
elaborar desde cero la misma, puesto que no existe en el estándar.
3. Elaboración del modelo inicial de clases del sistema.
Debido a la envergadura del proyecto, antes de proceder a la implementación
del mismo, se debe elaborar un primer modelo de clases que permita cumplir
los objetivos de claridad y modularidad establecidos en el Capítulo 1.
4. Implementación de la etiqueta en Python.
Con este paso empieza la labor de codificación. Por el momento no se utilizará GNU Radio, simplemente se programará en el lenguaje Python la
máquina de estados elaborada en el punto 2 para la etiqueta.
5. Desarrollo de una primera versión del paso de mensajes y comunicación
manual con las etiquetas.
Para evaluar la implementación de la etiqueta se elaborará una primera versión del programa en la que el usuario puede elaborar y enviar los comandos,
así como comprobar la respuesta que se recibe de las mismas.
6. Implementación del lector en Python.
El siguiente paso es programar el lector usando el lenguaje Python. De la
misma forma que para las etiquetas, la máquina de estados elaborada en el
punto 2 se codificará en dicho lenguaje de programación.
7. Conexión de ambas entidades y mejora del paso de mensajes. Funcionamiento en modo automático.
Este es el paso necesario para verificar el funcionamiento correcto del lector.
Se elaborará una nueva versión del programa en la que se conectarán ambas
entidades y podrá ordenarse la realización de rondas de inventariado por
parte del usuario, sin tener que elaborar y escribir los comandos manualmente.
Metodología / 37
8. Encapsulación de lector y etiqueta en bloques de GNU Radio y desarrollo
del nuevo paso de mensajes.
Este es el último paso para conseguir el sistema completo. Se introducirá
el entorno GNU Radio en este momento, encapsulando ambas entidades
en bloques, además de implementar otra funcionalidad necesaria para que
el sistema funcione en dicho entorno. El paso de mensajes se hará ahora
utilizando las características explicadas en la Sección 2.3.5.
Terminado el proceso de implementación se han realizado pruebas y evaluado
las prestaciones del sistema construido. El sistema conseguido al final del proceso,
tal y como se definió en la Sección 1.3, es una implementación que representa el
comportamiento de FSA en el estándar EPC.
Como se puede observar la complejidad de los problemas es creciente y cada
uno de ellos se apoya sobre el anterior, consiguiendo finalmente el sistema deseado.
Capítulo
3
Resultados
En este capítulo se encontrará la descripción detallada del proceso de elaboración,
siguiendo el guión presentado en la Sección 2.6 del capítulo anterior. Además de
la descripción del proceso se recogerán una serie de medidas que se han recogido
del sistema para comprobar su funcionamiento. Estas medidas serán comparadas
con resultados teóricos y simulaciones del sistema. Por tanto en este capítulo
se ofrece una amplia visión de cómo está construida la implementación, de su
funcionamiento y de los resultados que aporta. Los diagramas mostrados a lo
largo del capítulo complementan la explicación.
3.1.
3.1.1.
Proceso de implementación del sistema
Características del sistema
Como hemos podido comprobar en la Sección 2.1, RFID se compone de tres
elementos: lector, etiqueta y middleware RFID. Desde el punto de vista de este
proyecto, lo más importante es la implementación particular de FSA en las
comunicaciones entre el lector y las etiquetas. Por este motivo no es necesario
elaborar el middleware que cualquier sistema RFID posee, pero sí es necesario
implementar las otras dos partes de RFID, lector y etiquetas.
De toda la funcionalidad que propone EPC, aquella que está estrictamente
relacionada con el acceso de múltiples usuarios al medio es la relacionada con
la operación de inventariado (ver Sección 2.1.3.2), ya que en la operación de
selección únicamente “habla” el lector y en la operación de acceso la comunicación
se produce entre el lector y una etiqueta en particular, después de haber tenido
éxito una identificación. Por tanto de todo el conjunto de comandos que EPC
regula, sólo deberemos implementar aquellos relacionados con la operación de
inventariado (en concreto los comandos Query, QueryRep, QueryAdjust, ACK y
NAK ). El comando Select escoge una muestra de toda la población de etiquetas
al alcance del lector. Aunque no se apoya estrictamente en FSA, se ha creído
39
40 / Resultados (C. 3)
oportuno implementarlo ya que el sistema será objeto de mejoras en posteriores
trabajos en la Universidad de Siegen.
A modo de resumen de lo descrito hasta ahora, las características de nuestro
sistema son:
• Implementación de Etiqueta EPC.
• Implementación de Lector EPC.
• Funcionalidad de lector y etiqueta centrada en la operación de inventariado, si bien se implementa tambien la operación de selección.
• Utilización de la librería GNU Radio.
• Uso del lenguaje de programación Python.
3.1.2.
Máquina de estados de la etiqueta
En el Capítulo 2 se ha presentado el diagrama de la máquina de estados que
se propone por parte del estándar (Figura 2.2). Sin embargo, esta máquina de
estados contiene más funcionalidad de la necesaria, por lo que debe ser adaptada
a nuestras necesidades.
Utilizando las características definidas en la Sección 3.1.1 y el diagrama de
estados de la Figura 2.2 construimos el diagrama de estados de nuestra etiqueta.
En la Figura 3.1 se representa su diagrama UML (de las siglas en inglés de
Lenguaje Unificado de Modelado).
Como se puede observar el diagrama propuesto posee cuatro estados: Ready,
Arbitrate, Reply y Acknowledged, que se corresponden con los estados del mismo
nombre del diagrama del estándar. A continuación se detalla su funcionamiento.
Estado Ready. Después de crear (encender en términos prácticos) la etiqueta,
ésta va al estado Ready. Este es el estado inicial y en el que estará cuando esté
en reposo y no esté participando en una ronda de inventariado. También será
el estado en el que la etiqueta entrará cuando se reciba un comando Select. Las
transiciones posibles, con sus correspondientes respuestas, son:
• Al estado Arbitrate. Se producirá esta transición cuando se reciba el comando Query con parámetros que coincidan con los de la etiqueta, la etiqueta escoja aleatoriamente el contador de slots y éste sea distinto de 0. Esto
significa que no es este el slot que la etiqueta ha elegido para responder. No
se produce ninguna respuesta.
Proceso de implementación del sistema / 41
[Select]
[Query, with not
correct SL |
inventoried]
[others]
[power up]
Ready
[QueryRep,
QueryAdjust with
same session]
invert session flag
[Select]
Acknowledged
[Query, with correct
SL &
not inventoried &
slot counter<>0]
[Query, with
correct SL &
not inventoried &
slot counter==0]
Generate &
send RN16
[QueryRep &
(slot counter--)<>0]
[others]
Arbitrate
[QueryRep &
(slot counter--) == 0]
[QueryAdjust
(same session) &
slot counter==0]
Generate &
send RN16
[Select]
[ACK
matching RN16]
Reply with EPC
unique id
[others]
slot counter =
0x8000
[ACK not
matching
RN16 |
NAK | others]
slot counter =
0x8000
[QueryAdjust
(same session)
&
(slot counter <> 0]
Reply
[QueryAdjust
(same session)
& slot counter==0]
Generate & send RN16
Nota 1: En todos los estados se podrá recibir un Query, y su funcionamiento será Ir
a Arbitrate si slot counter<>0 o a Reply si slot counter==0, o bien a Ready si el
Query no va dirigido a la tag (SL ó flag de sesión no en la posición exigida).
Nota 2: Si se recibe un QueryRep o QueryAdjust que no son de la misma sesión se
entenderá que es un comando no válido y se ignorará.
Figura 3.1. Máquina de estados de la etiqueta a implementar.
• Al estado Reply, cuando se reciba un Query para ella (es decir que los
parámetros coincidan con los valores actuales de los indicadores), la etiqueta
escoja un contador de slots y éste sea 0, es decir, la etiqueta ha elegido
este slot para responder. En este caso se produce una respuesta. Ésta será
devolver al lector un número aleatorio de 16 bits, llamado RN16 (ver Sección
2.1.3.6 del capítulo 2).
• Quedarse en Ready. La etiqueta permanecerá en este estado cuando reciba
un Query que no se dirija hacia ella, o cuando se recibe un Select para cambiar sus indicadores en vistas a una ronda de inventariado, u otros comandos.
No se producirá respuesta.
Estado Arbitrate. Este estado es el de espera. La etiqueta permanece en este
estado hasta que llegue el slot que ha elegido aleatoriamente para responder.
Mientras tanto, la etiqueta decrementará en una unidad el contador de slots cada
vez que llegue un QueryRep de la sesión en la que está trabajando. Las transiciones
en este estado son:
• Al estado Reply, cuando, tras llegar un QueryRep correcto y decrementar
el contador de slots, el valor del mismo sea cero. También se produce cuando
se recibe un QueryAdjust y el slot elegido para responder es el actual. En
ambos casos se responderá al lector con un RN16.
• Quedarse en Arbitrate, cuando, tras llegar un QueryRep con sesión correcta
y decrementar el contador de slots, este sea aún distinto de cero. No se
producirá respuesta. También ocurre cuando se recibe un QueryAdjust y,
tras elegir aleatoriamente un slot, éste no es el actual.
• Al estado Ready cuando se reciba un comando Select. No se produce respuesta.
Estado Reply. Este estado recibe este nombre por ser cuando se responde al
lector. Al conmutar a este estado ya se ha enviado al lector un RN16. Es ahora
cuando se espera que el lector asienta la recepción. Pueden ocurrir varias transiciones desde este estado:
• Al estado Acknowledged. Si el lector envía un comando ACK asintiendo
la recepción del RN16 que la etiqueta envió, la etiqueta conmutará a dicho estado, produciéndose una respuesta. Esta respuesta está basada en el
estándar y contiene lo siguiente:
— Palabra de control del protocolo (PC). Es fija y está almacenada en la
memoria EPC de la etiqueta. Contiene características de la memoria
EPC, como la longitud. En nuestro caso es un valor fijo para todas las
etiquetas y contiene: 0b0011000000000000.
— Contenido de la memoria EPC. Ésta contiene el identificador único de
la etiqueta. En nuestro caso está formado por 96 bits, 6 palabras de
16 bits, tal y como indica la palabra de control del protocolo en los
primeros cinco bits. El valor de este campo dependerá de la etiqueta.
— CRC-16. Es un CRC almacenado en la memoria EPC y está calculado
sobre el resto de los campos del mensaje.
• Al estado Arbitrate. Si el lector no envía un ACK con el RN16 que la
etiqueta ha generado, significa que la etiqueta no ha podido ser seleccionada
correctamente y, por tanto, deberá esperar a la siguiente ronda para poder
ser identificada. En este caso el contador de slots se cargará con el valor
0x8000 y no contestará más en esta trama. También puede pasar que el
lector ejecute un QueryAdjust, y en este caso, tras escoger aleatoriamente
el nuevo slot donde la etiqueta quiere responder (y no es el slot actual),
la etiqueta volverá al estado Arbitrate con el valor de contador de slots
generado. En ambos casos no se produce respuesta.
• Quedarse en Reply, si el lector envía un QueryAdjust y el valor del contador
de slots generado indica que se debe contestar en este slot. La respuesta al
lector será un RN16 generado por la etiqueta.
Estado Acknowledged. Tras enviar la respuesta única descrita en el estado
Reply, la etiqueta pasa al estado Acknowledged. Ahora espera a que se confirme
la recepción de la respuesta anterior para considerar que está correctamente identificada. La etiqueta se considera correctamente identificada si se ejecuta alguno
de los comandos que implica la continuación de la trama FSA (o una nueva),
es decir, es una confirmación implícita. La etiqueta puede tener alguna de estas
transiciones:
• Al estado Ready. Cuando se recibe un comando QueryRep, o Query o
QueryAdjust con la misma sesión en la que está trabajando la etiqueta. En
este caso la etiqueta asume que ya está identificada y cambia su indicador
de sesión al valor contrario (a B si estaba en A y viceversa). No se produce
respuesta al lector.
• Quedarse en Acknowledged si se recibe un comando ACK con el mismo
RN16 anterior. Esto puede ser debido a que el lector no ha podido recibir
correctamente (sin errores) la respuesta. En este caso se repetirá la respuesta
que se realizó en la transición de Reply a Acknowledged.
• Al estado Arbitrate. En otros casos. El proceso de inventariado para esta
etiqueta ha fallado y ella no responderá más en esta ronda. Por ello carga su
contador de slots con el valor 0x8000. El funcionamiento normal del lector
no propiciará esta transición, pues procurará identificar al mayor número
de etiquetas posibles y, tras un error, el lector preferiblemente repetirá el
comando ACK enviado.
3.1.3.
Máquina de estados del lector
Al contrario que en el caso de las etiquetas EPC, el estándar no proporciona una
máquina de estados que se pueda utilizar. Únicamente señala que el lector podría
dividir su funcionamiento en tres operaciones, tal y como se explicó en la Sección
2.1.3.2. Como en el caso de la etiqueta, el lector no debe implementar toda la
funcionalidad que el estándar desarrolla. Teniendo en cuenta las especificaciones
de la Sección 3.1.1 se ha elaborado una máquina de estados para el lector cuyo
diagrama puede encontrarse en la Figura 3.2.
[collision]
NAK + QueryRep
slot counter --
[no order received]
(no reply)
[no reply]
QueryRep
slot counter --
[power up]
[order: start inventory round]
Query + slot counter=2^Q
Ready
Running
[order: send Select]
Select
[slot counter==0]
(no reply)
[response
from tag &
(slot counter--)==0]
tagsIdentified++
(no reply)
[unique response
from a tag with RN16]
ACK with RN16 from tag
[response
from tag &
(slot counter --)<>0]
tagsIdentified++
QueryRep
ACK
Nota: En EPC las tags no pueden emitir un mensaje si antes el lector no ha emitido
un comando.
Figura 3.2. Diagrama de estados UML del lector a implementar.
Como se observa en la figura, se ha construido una máquina de estados
con tres estados (sin incluir el inicial y final). Está máquina implementa la
funcionalidad de una única ronda de inventariado. Estos estados son: Ready,
Running y ACK. En breve se analizará cada uno de los estados, incluidas sus
transiciones.
Se ha decidido elaborar una máquina de estados con tres estados para ser
coherente con la máquina de estados de la etiqueta. La operación más importante
que la máquina ha de implementar es la de inventariado, con lo que todos
los estados están relacionados con la misma. Tal y como se vio en la Sección
2.1.3.6, la correcta identificación de una etiqueta se produce en dos pasos, con lo
que el lector EPC que se implemente deberá también tener en cuenta este aspecto.
FSA se desarrolla por completo en la transición de Ready a Running y en este
último estado. La demás funcionalidad es requerida por el protocolo EPC por el
motivo expuesto en el párrafo anterior.
Estado Ready. El lector se inicializa en este estado. Espera entonces órdenes
por parte del usuario para llevar a cabo una de las operaciones, bien de selección
o bien de inventariado. Las transiciones que pueden ocurrir son:
• Al estado Running, cuando se recibe por parte del usuario la orden de
empezar una trama FSA. En este momento se enviará a las etiquetas un
comando Query con las características que el usuario determine, además de
inicializar el contador de slots a 2Q .
• Quedarse en Ready, cuando se recibe la orden de emitir un comando Select,
es decir, una operación de selección. El lector conformará y enviará dicho
comando con las opciones especificadas por el usuario. Además del caso
anterior, el lector permanecerá en este estado cuando no se reciba orden
alguna por parte del usuario y no producirá comando alguno.
Estado Running. Este es el estado fundamental en el que transcurre la operación de inventariado. Será en este estado en el que se permanezca mientras no
responda ninguna etiqueta y se abandonará por dos motivos: cuando responda
una etiqueta o cuando la trama se acabe. Esto provocará sendas transiciones que
se explican a continuación, junto con la permanencia en el mismo:
• Al estado ACK. Cuando se produce una única respuesta por parte de una
etiqueta exclusivamente, el lector deberá identificarla y, para ello, deberá
conmutar a este estado y emitir un comando ACK para asentir la respuesta
de la misma.
• Quedarse en Running, si se produce una colisión (dos o más etiquetas
respondiendo a la vez) o no contesta ninguna etiqueta. En el segundo caso
el lector enviará un comando QueryRep para continuar la identificación,
aparte de decrementar en una unidad el contador de slots. En el primer caso
se enviará un comando NAK para indicar el error y a continuación el mismo
funcionamiento que en el segundo caso. La ronda, por tanto, continuará.
• Al estado final. Cuando el contador de slots vale cero la trama se ha acabado,
con lo cual el lector debe terminar su funcionamiento. En esta transición no
se producirá respuesta.
Estado ACK. Cuando se accede a este estado es porque una etiqueta ha decidido (aleatoriamente) utilizar este slot para responder al lector. En este caso ya
ha sido devuelto el RN16 que la etiqueta creó y ahora se espera (como funcionamiento normal) que la etiqueta envíe su identificación única al lector. Una vez que
se recibe la misma el lector deberá anotar que ha identificado una etiqueta más y
posteriormente decrementar el contador de slots. Al hacer esta operación pueden
ocurrir dos cosas:
• Contador de slots distinto de cero. Aún no ha terminado la trama y, por tanto, la ronda deberá continuar. Por tanto se debe volver al estado Running,
enviando con ello un comando QueryRep para indicar el inicio de un nuevo
slot.
• Contador de slots igual a cero. En este caso ha llegado el fin de la trama tras
identificar a la etiqueta y el lector terminará su funcionamiento, dirigiéndose
al estado final.
3.1.4.
Modelo inicial de clases del sistema
Hemos de implementar dos entes básicos: la etiqueta y el lector. Debido a que
Python soporta el paradigma de la programación orientada a objetos, lector
y etiqueta se pueden implementar como sendas clases con sus respectivos atributos.
Inicialmente el modelo de clases estará formado por dos clases: Reader y Tag.
En la implementación del sistema completo este modelo irá cambiando para adaptarse a los requisitos que se van exigiendo en cada fase. Nuestro modelo de clases
inicial se puede encontrar en la Figura 3.3.
3.1.5.
Implementación de la clase Tag
Tras definir los requisitos del sistema y la máquina de estados que desarrollará
la funcionalidad de la etiqueta, es hora de implementar dicha máquina en el
lenguaje de programación Python.
Esta primera implementación será la base sobre la que se trabaje en una
posterior encapsulación en los bloques de GNU Radio. Es por ello que la misma
deberá respetar los requisitos para trabajar con dicha librería.
Las comunicaciones entre etiquetas y lector deben utilizar alguno de los tipos
soportados por GNU Radio para el mecanismo de paso de mensajes. Dado que el
lector elabora y envía comandos, que no son más que un conjunto de bits, y la
etiqueta responde con el identificador temporal (RN16) o su memoria EPC, que
también son un conjunto de bits, el tipo de dato que mejor se adapta de todos ellos
es el ndarray de NumPy (ver Sección 2.4) cuyo contenido son números enteros de
8 bits, cada uno de ellos representando un bit.
La etiqueta debe ser capaz de interpretar y reaccionar ante los comandos
del lector correspondientes a las operaciones de selección e inventariado. Por
tanto los comandos que la etiqueta entenderá serán: Select, Query, QueryRep,
QueryAdjust, ACK y NAK.
Reader
Tag
+S: bool[]
+SL: bool
+state: int
+name: str
+Q: int
+slotCounter: int
+session: int
+selected: bool
+RN16: int[]
+EPCbank: int[]
+truncate: bool
+pointer: int
+ACTION:function[]
+noAction(int[]):None
+select(int[]): None
+query(int[]): int[]
+newRound(): int[]
+acknQuery(int[]):int[]
+replyQuery():int[]
+queryRep(int[]):int[]
+toReady(int[]): None
+qAdjToReady(int[]):None
+returnArbitrate(int[]):None
+queryAdjust(int[]): int[]
+ack(int[]):int[]
+nak(int[]):int[]
+receive(int[]):int[]
+Q: int
+session: int
+slotCounter: int
+state: int
+select: int[]
+target: bool
tagsIdentified: int
ACTION: function[]
+getTagsIdentified(): int
+selectCommand
(int,int[],int[],int[],int,int[],bool): int[]
+query(): int[]
+queryRep(): int[]
+queryAdjust(int,int,int): int[]
+ack(int[]):int[]
+nak(): int[]
+noAction()
+state_Ack(int[]): int[]
+continueRound(): int[]
+start(int[]): int[]
+receive(int[]): int[]
Figura 3.3. Diagrama inicial de clases UML del sistema.
Para llevar a cabo su funcionamiento, la etiqueta necesita una serie de atributos
que guarden algún dato importante entre interacciones, así como datos de la ronda
en la que se está participando. Estos son:
• Nombre de la etiqueta. Dato importante para el mecanismo de paso de mensajes de GNU Radio, como identificador del mensaje.
• Indicadores de sesión. Descrito en el estándar.
• Indicadores SL. También descrito en el estándar.
• Participación o no en esta ronda. Mediante este indicador la etiqueta recordará si cumple las condiciones impuestas por el lector para participar en
esta ronda.
• Sesión actual. Si se está participando en una ronda de inventariado, la etiqueta necesita saber en todo momento en qué sesión está trabajando, para
así comprobar el indicador de la sesión correspondiente.
• Q. El parámetro que configura el tamaño de la trama FSA debe ser guardado
por si se recibe un comando QueryAdjust y se necesita modificarlo.
• Contador de slots. Contiene el número de slots restantes para que la etiqueta
responda.
• RN16. Cada vez que se genera un RN16 y se envía debemos guardarlo para
compararlo con el asentimiento por parte del lector.
• Memoria EPC. Contiene el identificador único de la etiqueta, según indica
el estándar.
• Mecanismo de truncado de la respuesta. Si se ha activado el truncado de la
respuesta por parte del lector hará falta recordar que así ha sido, además de
la dirección a partir de la cual se enviará el contenido de la memoria EPC.
• Estado actual de la etiqueta. Como en toda máquina de estados la respuesta
dependerá, entre otros, del estado en el que se encuentra.
Según puede observarse en la Figura 3.3 las etiquetas disponen de un método
receive, que requiere como parámetro un ndarray de enteros y devuelve otro
ndarray de enteros. Este método es el único encargado de procesar los comandos
que llegan a la etiqueta y realizar la acción necesaria tras comprobar, entre
otras cosas, el estado en que se encuentra y qué comando ha llegado, así como
devolver una respuesta si procede. Por tanto podríamos decir que es el método
más importante porque dirige el funcionamiento de toda la etiqueta. El método
devuelve un ndarray con la respuesta que deberá ser redirigida al lector, o bien
None para indicar que no se quiere comunicar nada al lector (es decir, no ha
llegado el slot elegido para responder).
El funcionamiento del método es el siguiente. En primer lugar se identifica
y valida (comprobando el CRC, si procede) el comando recibido. En el caso de
haber podido identificar y validar correctamente el comando se llama al método
específico que procesa ese comando en el estado en el que la etiqueta se encuentra.
Los métodos encargados de cada uno de los casos están listados en un atributo
de la clase, una matriz NumPy llamada ACTION, de tal forma que cada fila
representa un estado y cada columna un comando (ACTION es una matriz con
punteros a funciones, mecanismo ampliamente utilizado en Python). Para hacer
este mecanismo posible a cada uno de los estados se le asigna un identificador
numérico correlativo de manera que puedan servir de índices de las filas (de la
misma forma se procede con los comandos para las columnas). Por último se
recoge la respuesta que se ha obtenido del método y se devuelve al llamante de
receive.
3.1.6.
Desarrollo de una primera versión del paso de mensajes y comunicación manual con las etiquetas
En este quinto punto del proceso de implementación ya se tiene una etiqueta
programada siguiendo el estándar y las características descritas en la Sección
3.1.1. Sin embargo, sus funciones no pueden ser ejecutadas en solitario. Esto es así
por dos motivos: primeramente porque están programadas en una clase Python
que no es posible ejecutar; segundo, por especificación del estándar, las etiquetas
esperan continuamente a recibir comandos desde el lector, con lo que no efectuarán ninguna operación a no ser que sea precedida por la recepción de un comando.
Llegados a este punto, para probar el funcionamiento de las etiquetas es
necesario construir un programa en el que se desarrolle un primer paso de
mensajes a todas las etiquetas que se creen. Los comandos serán creados por el
usuario mediante la línea de comandos y enviados tal cual hacia las etiquetas,
que responderán (si procede) y este sistema devolverá por pantalla la respuesta
al comando.
En concreto esta primera versión del programa tendrá el siguiente funcionamiento:
1. Creación de las etiquetas. Se pregunta al usuario por el número de etiquetas
que desean ser creadas y son instanciados los objetos Tag.
2. Se entra en un bucle infinito en el que se solicitará un comando.
3. Cuando el usuario introduzca un comando, éste se enviará secuencialmente
a cada Tag para que sea procesado y devuelva una respuesta (si procede).
4. Cuando se termina de enviar el comando y recibir las respuestas, se analizan
las mismas. Si ha habido una respuesta única, ésta se muestra por pantalla. Si
ha habido colisión se le hace saber al usuario que así ha ocurrido, mediante un
comando genérico indicador de colisión. Si no ha habido ninguna respuesta
también se mostrará por pantalla.
5. Se vuelve al punto 3.
Como se puede observar en el esquema de funcionamiento anterior no
utilizamos ningún tipo de mecanismo de paralelización, sino que las etiquetas son
objetos residentes en memoria y el hilo de ejecución entra en cada una de ellas,
efectúa las operaciones necesarias y se dirige a otra etiqueta. Esto será una de las
diferencias básicas de funcionamiento interno cuando se encapsule en bloques de
la librería GNU Radio.
A continuación se presenta un ejemplo de uso de esta primera versión del
programa.
Type the number of tags: 3
Tags ready
Please input a command (Ctrl+C to end): 1000000000000000111001
Tag 0 received QUERY
Tag 0 participates now in session S0 with slotCounter=0
Tag 0 slotCounter==0!! Entering reply state. RN16
Response from: Tag 0 [1 1 0 0 1 0 1 1 1 0 0 0 1 0 0 1]
Tag 1 slotCounter==1
Response from: Tag 1 None
Response to command ->> [1 1 0 0 1 0 1 1 1 0 0 0 1 0 0 1]
Tag 0 received ACK
Tag 0 sending EPC memory...
Response from: Tag 0 [0 0 1 1 0 0 0 (...)
0 0 1 1 1 1 1 0 0 1 1 0 1 1 1 0 1]
Tag 1 received ACK
Tag 1 ignoring ACK...
Tag 2 received ACK
Response to command ->> [0 0 1 1 0 0 0 (...)
0 0 1 1 1 1 1 0 0 1 1 0 1 1 1 0 1]
Tag 0 received QUERYREP
Tag 0 returning to ready
[1]
[2]
[3]
[4]
Response to command ->> [1 1 1 1 1 1 1 1]
Tag 0 does not participate
(...)
Please input a command (Ctrl+C to end): ^CEnding program...
[5]
[9]
Las interacciones con el usuario están marcadas con un número entre corchetes a la derecha. Este ejemplo reproduce una identificación satisfactoria de tres
etiquetas en dos tramas (como se ordena en la primera interacción), hecha de
forma manual, pues el usuario es el encargado de la creación y conformación de
los comandos.
Una vez creadas las 3 etiquetas, el programa pide un comando. El primer
comando emitido por el usuario (en la interacción 2) es un comando Query, con
estos parámetros:
Sel
Session
No importa SL
S0
Target
A
Q
1
Con lo que las etiquetas habrán recibido la orden de empezar una ronda de
inventariado con un tamaño 2Q = 21 = 2 slots, en la que participarán todas
aquellas cuyo indicador de sesión S0 esté en la posición ‘A’. La Tag 0 ha decidido
contestar en este mismo slot (puesto que su contador de slots es igual a 0), mientras
que las otras dos han elegido el otro slot. El usuario recibe como respuesta un RN16
de la Tag 0.
A continuación el programa pide otro comando en la interacción 3. Para
seguir el funcionamiento del estándar el usuario ha decidido asentir el RN16 que
le ha llegado. En este caso la Tag 0 responde con el contenido de su memoria
EPC, mientras que las demás ignoran el comando. Esta etiqueta se silenciará y
no participará más en la ronda.
En la interacción cuarta con el usuario, éste decide enviar un comando
QueryRep en la sesión S0. La etiqueta 0 no responderá, pues está correctamente
inventariada, pero sí que internamente cambiará su indicador de sesión a ‘B’. Las
etiquetas 1 y 2 aún están sin inventariar, con lo que decrementarán el contador
de slot y responderán a este comando. Como lo hacen a la vez se produce una
colisión, con lo que el usuario no puede recibir nada coherente. En este momento
la trama se ha acabado. Si el usuario desea puede volver a empezar una nueva.
Es esto precisamente lo que hace el usuario en la interacción quinta. Se
vuelve a lanzar un comando Query con los mismos parámetros. Podemos
observar que la etiqueta 0 no participa en la nueva ronda, pues su indicador de
inventariado está en la posición ‘B’y el comando se dirige a las que lo tienen en ‘A’.
El programa termina a petición del usuario en la interacción 9. Por sencillez
se ha decidido cortar los mensajes hasta esta interacción, pues sólo se pretende
dar una visión general del programa. El proceso que tiene lugar entre medias es la
correcta identificación de ambas etiquetas, de manera análoga a la identificación
de la Tag 0.
3.1.7.
Implementación de la clase Reader
La interacción manual con las etiquetas no es suficiente para cumplir los requisitos
del sistema, pero es una buena aproximación del usuario al funcionamiento del
estándar EPC. Según la metodología del presente proyecto, el siguiente paso es
implementar el lector EPC, de manera que el sistema pueda funcionar sin la
acción del usuario.
El diagrama de estados que se diseñó para el lector EPC (Fig. 3.2) sólo es
capaz de implementar una ronda de inventariado. Es misión del control de la
aplicación empezar las rondas de inventariado según se considere oportuno.
Como se puede observar en el diagrama de clases de la Figura 3.3, el lector
contiene también atributos, ya que debe guardar algunos datos necesarios entre
interacciones, dentro de la misma ronda. Estos atributos consiguen guardar información tan importante como:
• Parámetros de la trama FSA, como Q, la sesión en la que el lector actuará,
la posición del indicador de sesión al que se dirige, o cómo se tiene en cuenta
el indicador SL. Todos ellos servirán para crear el comando Query que empezará la trama. Además Q se guarda por un posible QueryAdjust (además
de para poder inicializar el contador de slots) y la sesión para marcar el
inicio de cada slot con QueryRep.
• Contador de slots. La trama tiene un tamaño de 2Q slots. El lector deberá
saber cuándo ésta se acaba para no seguir mandando QueryRep.
• Estado actual. Se debe recordar el estado en el que el lector está porque el
comando que se ejecute y el procesado de las respuestas que llegan dependen
de dicho estado.
• Número de etiquetas identificadas. Con el propósito de informar al usuario
de cuántas etiquetas han sido identificadas en la ronda, el lector mantendrá un contador que incrementará en una unidad cada vez que se reciba el
identificador único de una etiqueta.
Como en el caso de la etiqueta, el lector EPC debe utilizar para los mensajes
alguno de los tipos de dato que GNU Radio soporta para el paso de mensajes.
Para respetar la implementación que se ha hecho de la etiqueta, el lector utilizará también ndarrays para contener los bits del comando que se desee enviar.
Del mismo modo también esperará respuestas basadas en este mismo tipo de array.
El lector debe ser capaz de construir y enviar los comandos Select, Query,
QueryRep, QueryAdjust, ACK y NAK, correspondientes a las operaciones de
selección e inventariado del estándar EPC —como se definió en la Sección 3.1.1—
así como saber procesar las respuestas que recibirá de las etiquetas.
El funcionamiento del lector sigue un esquema muy parecido al de las etiquetas. Como se puede ver en la Figura 3.3 también dispone de un método receive.
Cada vez que el control tenga un mensaje que entregar al lector invocará este
método. Dependiendo del estado en el que el lector se encuentre procesará la
respuesta (el comando que corresponda) y la devolverá a través de dicha función.
Cuando no se ha recibido ninguna respuesta de las etiquetas, o bien es el inicio
de la ronda, el control llamará a la función receive con el mensaje igual a None.
El control de la acción que debe ejecutar el lector cuando recibe una respuesta (o None) dependiendo del estado en que se encuentre reside en el atributo
ACTION , un vector NumPy cuyo contenido son punteros a funciones, de manera
análoga al caso de la etiqueta.
3.1.8.
Conexión de etiqueta y lector. Funcionamiento en modo automático
El lector, en teoría, puede funcionar aunque no existan etiquetas, pues lanzará sus
comandos pero no recibirá respuestas. Sin embargo la implementación realizada
en este proyecto precisa de un control externo que le indique al lector cuándo
empezar y le entregue las respuestas de las etiquetas.
En este paso se creará dicho control y además se unirá el sistema para tener
un lector y un número variable de etiquetas con posibilidad de comunicación entre
ellos. Podríamos decir que una vez implementado dicho control, se obtiene un
sistema completamente funcional y totalmente conforme con los requerimientos
(salvo en un aspecto, ya que no utiliza la librería de GNU Radio).
A continuación se describe el funcionamiento del control de la aplicación. En
la anterior versión del programa no se habló de control pero existía uno, al menos
implícitamente, dentro del programa principal. Se encargaba de la creación de las
etiquetas, así como de “enviar” el mensaje que el usuario escribía a las etiquetas
de forma secuencial.
En esta versión se añade el lector, que permite identificar las etiquetas de
forma automática (el usuario sólo tendrá que ejecutar el programa principal y
elegir el número de etiquetas). El control incorporará una nueva característica:
será el encargado de decidir cuándo acabar el proceso, pues será el encargado de
iniciar el lector cada vez que se necesite una ronda de inventariado.
El control no guardará información sobre el número de etiquetas que existen,
implementará un algoritmo de parada que consiste en evaluar las colisiones
producidas en cada ronda. Si se produce una o varias colisiones, mandará iniciar
otra ronda, puesto que existen etiquetas que quieren responder y no han podido.
Sin embargo, si no se produce ninguna, significa que todas las etiquetas presentes
han contestado ya satisfactoriamente y están silenciadas.
Adicionalmente en esta versión se da la posibilidad al usuario de desactivar
este algoritmo, de tal forma que él sea quien ejecute el control del inventariado
de las etiquetas. Esta opción recibe el nombre de semiautomática, pues el usuario
no tiene que elaborar los comandos, pero decidirá cuándo se empieza una nueva
trama y cuándo se interrumpe el proceso.
A continuación se ofrece un ejemplo de uso del programa en su modo automático.
Type the number of tags: 3
Tags ready
Select one option
1.-Manual
2.-Semi-Automatic
3.-Full Automatic
4.-Select
---> 3
Reader ready for new round
------------------------>Reader is in state: 0
Loop with command: [1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 0 1]
Response to command ->> [1 1 1 1 1 1 1 1]
Loop with command: [1 1 0 0 0 0 0 0]
Tag 0 received NAK
Tag 0 ignoring command...
Tag 1 received NAK
Tag 1 ACK not received. Returning to arbitrate...
Tag 2 received NAK
Tag 2 ACK not received. Returning to arbitrate...
Response to command ->> None
Loop with command: [0 0 0 0]
Loop with command: [0 1 0 1 0 0 1 0 0 1 0 0 0 0 0 0 0 1]
Tag 0 received ACK
Response from: Tag 0 [0 0 1 1 0 0 0 (...)
1 0 0 0 1 1 0 1 0 0 1 0 0 1 1 1 1]
Tag 1 received ACK
Tag 2 received ACK
Response to command ->> [0 0 1 1 0 0 0 (...)
1 0 0 0 1 1 0 1 0 0 1 0 0 1 1 1 1]
------------------------>1 more tag identified
------------------------>1 tags identified this round
Reader ready for new round
(...)
------------------------>2 tags identified this round
Control ending process... No collisions occured
3 TAGS IDENTIFIED IN 2 ROUNDS.
Se puede comparar la ejecución de esta versión con la mostrada en la Sección
3.1.6. También se trata del proceso de identificación de 3 etiquetas con los mismos
parámetros de la trama que en la ejecución pasada (Sesión 0, no importa el
valor de SL, Q=1 y estado del indicador de sesión ‘A’), pero esta vez de forma
automática, es decir, sin intervención del usuario en la ronda.
Si se observa esta ejecución se comprobará que las etiquetas se comportan de
la misma forma (puesto que ya estaban implementadas anteriormente) pero ahora
el usuario no teclea los comandos, sino que la nueva clase Reader se encarga de
ello. Además el control se encarga de la ejecución del algoritmo de parada. En la
primera trama se producen colisiones, con lo que el control decide llevar a cabo
otra ronda. Sin embargo al terminar la segunda el control ha decidido finalizar el
proceso, ya que no se ha producido niguna colisión.
3.1.9.
Versión final: encapsulación en GNU Radio y nuevo paso de
mensajes
La versión del programa propuesta en la Sección 3.1.8 consigue mostrar el
funcionamiento de la capa de identificación de las etiquetas descrito en el
protocolo EPC, sin la operación de acceso (pues no es relevante para demostrar el
funcionamiento de FSA). El lector es capaz de empezar una trama y desarrollarla
emitiendo los inicios de slots correspondientes. Podemos decir que la lógica del
programa está concluida. El trabajo llevado a cabo en este paso consiste en
adaptar la lógica desarrollada a GNU Radio, con vistas a futuras ampliaciones,
según se explica en el capítulo de Conclusiones.
Para convertir el programa en una aplicación que utilice las ventajas de la
librería de GNU Radio debemos cambiar la estructura del mismo, al menos en
lo que respecta al diagrama de clases. Además supondrá un cambio en la forma
de ejecución, pues antes existía un único hilo que se encargaba de todo, mientras
que ahora las entidades se ejecutarán en hilos separados.
La unidad básica de GNU Radio es el bloque. Para poder utilizar la librería
el lector y las etiquetas deberán ser, por tanto, bloques de GNU Radio. El sistema
en su conjunto deberá representar un grafo de flujo, indicando a GNU Radio los
bloques que existirán y las conexiones entre ellos (ver Sección 2.3.3).
Existen una serie de problemas a los que nos tenemos que enfrentar en esta
fase del desarrollo:
• Encapsular lector y etiqueta en sendos bloques de GNU Radio.
• Adaptar ambos a un nuevo mecanismo de paso de mensajes.
• GNU Radio no permite la conexión de múltiples salidas a una única entrada.
• Elaboración del grafo.
En la primera tarea debemos cambiar la definición de cada una de las clases.
Para que lector y etiqueta se conviertan en un bloque de GNU Radio cada una
éstas deberán heredar de Block, la clase que proporciona GrExtras para poder
escribir bloques en Python.
Además de heredar de Block, lector y etiqueta deberán llamar al constructor
de la clase madre con los siguientes parámetros:
• Nombre del bloque. Servirá como identificador de la instancia del bloque.
• Número de entradas y salidas tradicionales. Para comunicación mediante
muestras, a la manera tradicional de GNU Radio.
• Número de puertos de entrada y de salida para mensajes. Para la comunicación mediante mensajes, tal y como introduce GrExtras.
El último requisito es que el bloque sobreescriba el método work() de la clase
madre. Este método work() deberá ser el “método principal”, es decir, quien
controle el funcionamiento del bloque.
Tal y como explicamos en la Sección 2.3.5.3, el mecanismo de paso de mensajes
que GrExtras proporciona permite comunicaciones entre dos bloques abstrayendo
al usuario del flujo de datos, pudiendo enviar objetos completos entre bloques y
no sólo muestras (el funcionamiento tradicional de GNU Radio).
Los mensajes contienen estos campos:
• El campo key es un identificador único del tipo de contenido.
• value es el mensaje en sí que se desea intercambiar.
• Opcionalmente se puede indicar un campo srcid que identifica de manera
única al emisor del mensaje.
El bloque dispone de dos métodos (heredados de la clase madre) que son
pop_msg_queue() y post_msg(). El primero recibirá un mensaje y el segundo lo
enviará. En GrExtras la acción de recibir es bloqueante, no así la de envío.
Englobando las dos tareas, el incluir GNU Radio influirá en el funcionamiento
de los bloques en buena medida. Actualmente el control era el encargado de
entregar los mensajes a cada entidad, si bien ahora los bloques deberán recoger
los mensajes por sí mismos, procesarlos y enviarlos también por sus propios
medios.
Se ha decidido que el método work() de cada bloque incluya la funcionalidad
que antes se reservaba al control del programa. De esta forma el método work de
la etiqueta tendrá el siguiente funcionamiento dentro de un bucle infinito:
1. Se recibe un mensaje. Hasta que no se reciba un mensaje la etiqueta se queda
bloqueada.
2. Se deserializa el mensaje y se llama al método receive con el comando.
3. La respuesta obtenida de dicho método se mete en un mensaje.
4. El mensaje se envía de vuelta.
El proceso se repite hasta que se reciba desde el lector un mensaje de
finalización, simulando la pérdida de corriente que ocurriría cuando el lector se
desconectara en el sistema real (y por consiguiente dejara sin alimentación a las
etiquetas).
Para el caso del lector, el método work incluirá la funcionalidad siguiente en
un bucle:
1. Si está en el estado Ready, iniciar la ronda sin recibir mensaje.
2. Si está en otro estado menos End, recibir mensaje.
3. Llamar al método receive con la respuesta, o bien con None si se está
empezando la ronda.
4. La respuesta obtenida de receive se mete en un mensaje.
5. El mensaje se envía a las etiquetas.
Cuando el estado es End, se saldrá del bucle y se enviará a las etiquetas el
mensaje de finalización. La ronda se considerará entonces terminada.
El tercer aspecto que se debe resolver es que GNU Radio no soporta que
múltiples salidas se conecten a una misma entrada (una salida en varias entradas
de varios bloques sí es posible). Este problema ocurre cuando se tiene que conectar
el puerto de salida de todas las etiquetas al puerto de entrada del lector. Para
resolver esta situación se ha optado por implementar un bloque llamado Control
que combine las respuestas de todas las etiquetas y envíe al lector por un único
puerto la respuesta apropiada a cada comando. La solución se ha planteado de
esta forma para que el lector no dependa del número de etiquetas que se hayan
creado.
Dicho bloque tendrá tantas entradas como etiquetas más una para recibir los
comandos del lector. El bloque estará sincronizado con el lector, de tal forma que
conozca el inicio de cada slot. En cada slot dicho bloque esperará la recepción de
las respuestas por parte de las etiquetas: si se ha producido más de una avisará
con el mensaje de colisión al lector; si sólo ha habido una respuesta se la enviará
al lector sin cambios.
El último detalle que se debe resolver es elaborar el grafo de flujo de GNU
Radio, es decir, el grafo de conexión de los bloques entre sí. En la Figura
3.4 se representa cómo debe ser la conexión para que el sistema funcione.
En dicho grafo existen N bloques representando a N etiquetas, un bloque de
control y un bloque que representa al lector. Los puertos de salida de todas
Control
Reader
.
.
.
Tag 0
.
.
.
Tag 1
.
.
.
Tag N-1
Figura 3.4. Grafo de conexión de los bloques.
las etiquetas están conectados al bloque de control. El bloque de control se
conectará al puerto de entrada del lector. La salida del lector debe conectarse
con las entradas de las N etiquetas y con una de las entradas del bloque de control.
El grafo de GNU Radio debe estar escrito en Python. Para que incluya la
funcionalidad de la librería debe heredar de una clase llamada top_block, una
especie de bloque superior que englobará los bloques que se deseen instanciar
en el diseño. Dentro del constructor de la subclase se deberán instanciar los
diferentes bloques y se deberán conectar mediante el método connect las
diferentes instancias creadas, de la manera deseada.
El grafo creado es la unidad ejecutable de GNU Radio. La ejecución puede
ser controlada por el programa principal en todo momento, mediante llamadas
bloqueantes o no bloqueantes. El programa principal implementará la lógica de
parada del sistema siguiendo el algoritmo expresado en la Sección 3.1.8.
Además se ha hecho uso de la librería estándar de Python para que el usuario
pueda pasar las opciones por línea de comandos, directamente en la llamada al
programa. Las opciones que puede elegir son: número de etiquetas, Q, sesión,
Target y si se debe tener en cuenta el indicador SL (y cómo) o no. En definitiva
puede configurar la ronda de inventariado según sus necesidades. También
puede elegir si el programa debe mostrar por pantalla más información (opción
--verbose) o no (opción --quiet). La opción --help muestra un mensaje de
ayuda sobre cómo utilizar el programa.
A continuación reproducimos un ejemplo de uso del programa en esta versión
final. Como en los ejemplos de las versiones anteriores, se trata de un sistema
formado por tres etiquetas y un lector en el que se pretenden identificar todas
ellas utilizando tramas de tamaño 2. Se incluye también la línea del intérprete
de comandos donde se llama al programa para que se pueda comprobar la
funcionalidad explicada en el párrafo anterior.
jesuspc@jesuspc-linux:~$ ./main.py -Q1 -n3
linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.002-128-g12f7a5c9
++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Proyecto Fin de Carrera - Jesús Pérez Comendador +
+ Ing. Telecomunicación-LADE
+
+ Universidad Rey Juan Carlos - Universität Siegen +
+ Welcome to the program
+
++++++++++++++++++++++++++++++++++++++++++++++++++++
Top block: Starting inventory rounds
1 tags identified this round.
Top block: Starting new round
2 tags identified this round.
No collisions... Ending...
Summary:
-------------------------------Tags identified: 3 in 2 rounds
Number of slots: 4
En el resumen del final podemos ver que se han identificado las tres etiquetas
en dos rondas, cada una de dos slots, lo que hacen cuatro slots en total. La primera
línea es mostrada por la librería GNU Radio en el momento de importarla. Los
mensajes en el medio muestran la evolución de cada ronda, cuántas etiquetas se
han identificado en cada una. Si se desea se puede activar la opción --verbose y
se mostrarán los mensajes que se mostraban en las anteriores versiones.
Tras un largo proceso de implementación se puede concluir que la funcionalidad deseada está ya implementada. En las próximas secciones de este capítulo se
describirá el modelo de clases final resultante, la estructura del código Python, así
como los resultados de las pruebas realizadas para comprobar el funcionamiento
de FSA.
3.2.
Modelo de clases del sistema final
Con respecto al diagrama de clases inicial (expuesto en la Figura 3.3) se han producido numerosas diferencias, provocadas en mayor medida por la introducción
de GNU Radio en la última fase de la implementación. El nuevo diagrama de
clases se puede encontrar en la Figura 3.5.
El programa lleva a cabo su funcionamiento mediante cinco clases. Estas
clases son: Tag, Reader, ControlBlock, TopBlock y MyProject. La ejecución del
programa empieza por instanciar la última de ellas, MyProject, con los parámetros
que configurarán las tramas FSA, así como el número de etiquetas que se desean
crear. Su método main() se encargará de desarrollar el algoritmo de control
que regulará las rondas de inventariado, actuando sobre el funcionamiento de
TopBlock.
La clase TopBlock representa el grafo de GNU Radio. Contiene métodos
heredados que posibilitan el control de la ejecución del mismo, como puede ser
arrancar el grafo, pararlo, esperar a que todos los bloques estén listos, etc.
Las clases Tag, Reader y ControlBlock representan los tres tipos de bloques
que se encuentran en nuestro programa. Serán instanciados por TopBlock y conectados según marca el grafo de la Figura 3.4. Las tres clases están relacionadas
entre sí puesto que todas envían y reciben clases de las demás, como explicamos
en la sección anterior.
En el Apéndice A se puede encontrar una descripción detallada de cada atributo y método de todas las clases.
3.3.
Características del código Python implementado
Al describir el lenguaje de programación Python en el Capítulo 2, una de las
características que se describió es que es multiparadigma, permitiendo al programador utilizar varios estilos. En este proyecto la mayoría de la implementación se
lleva a cabo mediante objetos, si bien alguna otra característica se ha programado
utilizando programación imperativa.
Características del código Python implementado / 63
gr.top_block
TopBlock
MyProject
+Q: int
+SESSION_READER:int
+SEL: int[]
+target: bool
+ntags: int
+verbose: bool
+lock: Lock
+reader_instance: Reader
+controlModule: ControlBlock
+tags: Tag[]
+main()
gr.block
ControlBlock
Reader
Tag
+Q: int
+session: int
+slotCounter: int
+state: int
+select: int[]
+target: bool
+tagsIdentified: int
+collisions: bool
+lock: Lock
+verbose: bool
ACTION: function[]
+S: bool[]
+SL: bool
+state: int
+name: str
+Q: int
+slotCounter: int
+session: int
+selected: bool
+RN16: int[]
+EPCbank: int[]
+truncate: bool
+pointer: int
+lock: Lock
+verbose: bool
+ACTION:function[]
+noAction(int[]):None
+select(int[]): None
+query(int[]): int[]
+newRound(): int[]
+acknQuery(int[]):int[]
+replyQuery():int[]
+queryRep(int[]):int[]
+toReady(int[]): None
+qAdjToReady(int[]):None
+returnArbitrate(int[]):None
+queryAdjust(int[]): int[]
+ack(int[]):int[]
+nak(int[]):int[]
+receive(int[]):int[]
+work(int[],int[]):int
+n: bool[]
+lock: Lock
+verbose: boolean
+messages: dict
+isUniqueResponse(): bool
+reset_control()
+isReaderFinished(): bool
+wereCollisions(): bool
+getTagsIdentified(): int
+getStateReader(): int
+selectCommand
(int,int[],int[],int[],int,int[],bool): int[]
+query(): int[]
+queryRep(): int[]
+queryAdjust(int,int,int): int[]
+ack(int[]):int[]
+nak(): int[]
+noAction()
+state_Ack(int[]): int[]
+continueRound(): int[]
+start_inventory(int[]): int[]
+receive(int[]): int[]
+reset_reader()
Figura 3.5. Diagrama de clases UML final.
(La explicación del mismo se puede encontrar en el Apéndice A).
El código Python resultante está estructurado en seis módulos:
1. main. Contiene las clases TopBlock y MyProject, además del código necesario para incorporar los argumentos que se indican por línea de comandos.
2. tag. Contiene la clase Tag, la etiqueta.
3. reader. Contiene la clase Reader, el lector.
4. control. Contiene la clase ControlBlock.
5. utils. Contiene funciones auxiliares que aportan funcionalidad necesaria para Tag y Reader, relacionadas con el CRC (cálculo y chequeo del CRC de
los comandos) y la conversión de enteros a arrays de NumPy (y viceversa).
6. constants. Contiene constantes utilizadas por todos los módulos y clases.
La implementación necesita adicionalmente de la librería estándar de Python,
así como de las librerías NumPy, GNU Radio y GrExtras para su funcionamiento.
3.4.
Pruebas realizadas
Para concluir con este capítulo de Resultados, procedemos a analizar precisamente los resultados de la implementación. Según se describe en la Sección 3.1.9,
la versión final del programa muestra por pantalla datos sobre el proceso de
identificación de las etiquetas, como son el número de etiquetas identificadas y el
número de rondas completadas, incluso el número de slots marcados.
Estos datos son de interés para evaluar el comportamiento de FSA en el
transcurso de la operación de inventariado. La medida de los resultados de la
implementación supondrá contrastar el funcionamiento de la misma con el modelo
teórico de este esquema de acceso al medio.
Tal y como se describió en el Capítulo 2, FSA establece que las etiquetas
no respondan inmediatamente al lector, sino que se escoge aleatoriamente un
slot para emitir la respuesta. Para evaluar nuestra implementación del estándar
EPC en términos de cumplimiento del esquema FSA debemos simular este
comportamiento mediante algún software matemático, como MATLAB.
La simulación realiza un procedimiento muy sencillo: dado un determinado
número de etiquetas (N) y un determinado Q, tal que el tamaño de la trama
es 2Q , el script deberá generar tantos números aleatorios como etiquetas haya.
Posteriormente deberá contar los números que hayan aparecido una única vez
(es decir, respuestas únicas) y restar el resultado a N (sería como silenciar las
etiquetas que hayan sido correctamente identificadas). Se repetirá el proceso
Pruebas realizadas / 65
hasta que N sea igual a cero, puesto que se ha llegado al final del proceso y
no hay más etiquetas pendientes de identificación. De este proceso se obtendrá
el número de iteraciones que se han debido realizar hasta que no han quedado más etiquetas por identificar, es decir, el número de tramas en términos de FSA.
El resultado del sistema, y también de la simulación, depende de dos parámetros: cuántos participantes haya (es decir, número de etiquetas) y cómo de
grande sea el intervalo para responder (es decir, tamaño de la trama). Cabe
esperar que con un tamaño de trama fijo, a más etiquetas mayor número de
colisiones, pues más etiquetas se reparten el mismo número de slots, con lo que el
número de tramas necesarias aumentará. Por otro lado si mantenemos el número
de etiquetas constante, a mayor tamaño de trama esperaremos menor número de
colisiones, pues las etiquetas tendrán más slots para elegir, con lo que el número
de ellas disminuirá.
Para comprobar ambos comportamientos se ha estudiado la dependencia del
resultado para cada una de las variables. Es decir, se han llevado a cabo dos
estudios independientes cuyos fines son:
1. Estudio de la influencia del número de etiquetas en el número de tramas
para un tamaño de trama constante.
2. Estudio de la influencia del tamaño de la trama en el número de tramas
para identificar una población de etiquetas fija.
3.4.1.
Primer estudio. Influencia del número de etiquetas
En el primer estudio se analizará la evolución del número de tramas variando
el número de etiquetas existentes, con un valor fijo del tamaño de la misma.
Se han recogido resultados para dos valores de Q, 4 y 5. En las Tablas 3.1 y
3.2 se pueden observar los resultados obtenidos. En ambas tablas se muestran
los valores de la simulación con MATLAB y los obtenidos con el programa implementado. Se ofrece una representación gráfica de ambas tablas en la Figura 3.6.
En la figura se puede observar que ambos resultados son similares. Esto implica que la implementación desarrollada en este proyecto describe el
comportamiento de FSA. Las diferencias entre ambas gráficas responden a la
aleatoriedad de ocurrencia de las respuestas en las etiquetas. Las colisiones, que
ocurren aleatoriamente porque las etiquetas escogieron el mismo slot para responder, supondrán el uso de tramas adicionales para identificar todas las etiquetas.
También se puede analizar la dependencia de tramas y número de etiquetas
en la figura. En ambas representaciones se puede observar una dependencia
Tabla 3.1. Resultados para el primer estudio con Q=4
Valores expresados en tramas.
Número de etiquetas
Simulación
Implementación
1
1
1
5
2
1
10
2
2
15
4
3
20
4
3
25
4
5
30
6
6
35
8
7
40
10
9
45
11
11
50
14
14
55
17
16
60
21
17
65
29
26
70
30
28
55
6
6
60
6
7
65
7
7
70
7
7
Tabla 3.2. Resultados para el primer estudio con Q=5
Número de etiquetas
Simulación
Implementación
1
1
1
5
1
1
10
2
2
15
2
2
20
3
3
25
4
4
30
4
4
35
4
4
40
5
4
45
5
5
50
6
5
directa entre ambos parámetros. Es decir, a mayor número de etiquetas el lector
necesitará más tramas para identificar todas ellas. Este es el comportamiento que
se predijo al inicio de esta sección.
3.4.2.
Segundo estudio. Influencia de Q
En este segundo estudio se analizará la influencia de Q sobre el número de tramas
necesarias para identificar las etiquetas, suponiendo un número de etiquetas fijo.
De cada sistema se obtendrá el número de tramas que se han necesitado para
identificar todas las etiquetas. Se han efectuado dos recogidas de resultados, una
para el caso de 10 etiquetas y otra para el caso de 45 etiquetas. Los valores se
encuentran en las Tablas 3.3 y 3.4.
Los guiones en los primeros resultados de las tablas representan la imposibilidad de identificar tantas etiquetas con un tamaño de trama tan pequeño. Por
ejemplo, para el caso de Q=0, existiría únicamente un slot para identificar 10 (ó
45) etiquetas, con lo que todas las etiquetas escogerán un número aleatorio entre
0 y 20 − 1 = 0, es decir, todas escogerán 0, haciendo imposible la identificación
de más de una etiqueta con un tamaño de trama tan pequeño.
Se puede observar en ambas tablas la tendencia descendente del número de
tramas cuando se aumenta Q. El número de slots, es decir el número de posibilidades de responder para las etiquetas, se multiplica por dos si se aumenta Q
en una unidad, puesto que K (el número de slots) se calcula como K = 2Q . Se
confirma pues la suposición del principio de la sección de la dependencia inversa
del número de tramas con respecto a Q.
(a) Q=4
(b) Q=5
Figura 3.6. Número de tramas frente a N para Q fijo.
Tabla 3.3. Resultados para el segundo estudio con N=10
Q
Simulación
Implementación
0
-
1
117
108
2
8
7
3
3
3
4
2
2
5
2
2
6
1
1
7
1
1
8
1
2
9
2
1
10
1
1
11
1
1
12
1
1
13
1
1
14
1
1
15
1
1
Tabla 3.4. Resultados para el segundo estudio con N=45
Q
Simulación
Implementación
0
-
1
-
2
43316
-
3
106
83
4
11
12
5
5
4
6
4
4
7
2
2
8
2
2
9
2
2
10
2
1
11
1
1
12
1
1
13
1
1
14
1
1
15
1
1
Si bien se ha confirmado la suposición al principio de esta sección, los
resultados de cada ejecución no son comparables entre sí, pues trabajan con
tamaños de trama diferentes. Para dibujar un gráfico como en la sección anterior
se deben representar los slots necesarios, en lugar de las tramas. Así, la Figura
3.7 representa los slots necesarios para identificar todas las etiquetas en cada
ejecución. Además se representarán únicamente los valores centrales, pues son los
que nos aportan resultados más interesantes.
En ambas gráficas de la Figura 3.7 se puede comprobar que el comportamiento
de la simulación en MATLAB y del programa implementado es similar, las únicas
diferencias se deben a la aleatoriedad de las respuestas. Además se pueden ver
sendos mínimos en cada gráfica, por lo que se puede concluir que ambos valores
de Q son los óptimos para 10 y 45 etiquetas, puesto que minimizan el número de
slots utilizados.
Llegados a este punto se deben contrastar los resultados con los postulados
teóricos de Bueno-Delgado y Vales-Alonso [10]. En su artículo exponían la Tabla
2.3, conclusión de su estudio sobre el tamaño de trama óptimo en función de las
etiquetas que se encuentran al alcance del lector. Si se acude a esta tabla se tiene
que, para 10 etiquetas, el valor óptimo de Q es 3, exactamente el valor en el que
se produce el mínimo en la Figura 3.7.a. De la misma forma, para 45 etiquetas el
valor óptimo es 5, coincidiendo con el valor de Q en donde se produce el mínimo
en la Figura 3.7.b.
(a) N=10
(b) N=45
Figura 3.7. Número de slots frente a Q para N fijo.
Bueno-Delgado y Vales-Alonso buscan la optimización del valor de Q con respecto al número de slots utilizados. Los resultados de las Tablas 3.3 y 3.4 podrían
hacer pensar que es indiferente utilizar un valor de Q=13 ó Q=15, o incluso cabe
pensar que es mejor siempre un valor alto, ya que se necesitan menos tramas.
Pero no es así, puesto que ejecutar una trama con 215 slots es mucho más lento
que ejecutar varias de 23 slots. Se deberá buscar, por tanto, el valor óptimo que
minimice el tiempo de identificación de las etiquetas.
Capítulo
4
Conclusiones
Este último capítulo presenta, a modo de conclusión, los logros alcanzados en el
transcurso del proyecto, así como los posibles trabajos futuros y mejoras que se
pueden llevar a cabo.
4.1.
Logros
Al principio de esta memoria, en el capítulo de Introducción, se establecieron los
objetivos que se deberían llevar a cabo en el Proyecto Fin de Carrera. A partir de
lo expuesto en el capítulo de Resultados se pueden extraer cómo y en qué medida
se han cumplido cada uno de los objetivos.
El objetivo principal era diseñar un sistema RFID abierto que utilice FSA
como esquema de acceso al medio y base su funcionamiento en el estándar EPC
en lo que respecta al acceso al medio. Como puede comprobarse, este sistema se
ha construido a lo largo del proceso de implementación descrito en la Sección 3.1.
Incluso se ha conseguido medir su eficacia comparándolo con una simulación del
comportamiento de FSA en la Sección 3.4.
El grado de cumplimiento de los objetivos específicos se expone a continuación:
1. Diseñar un sistema bajo una plataforma de código abierto gratuita que, si
bien se utilizará con propósitos de simulación, permita en el futuro el despliegue en un entorno real.
El sistema se ha desarrollado en el marco de GNU Radio. El código implementado está dirigido a simulación, pero añadiendo nuevos bloques de
procesado permite que se despliegue en un entorno real (ver Sección 4.2).
Además, este framework es una plataforma de código abierto y gratuita. Se
puede concluir, por tanto, que este objetivo se ha cumplido en su totalidad.
71
72 / Conclusiones (C. 4)
2. Realizar un diseño del sistema centrado en mostrar el funcionamiento de
Frame-Slotted ALOHA.
De todas las posibles características del estándar EPC se ha decidido implementar las operaciones de inventariado y selección, prestando un especial
interés en la primera de ellas. Como ya se analizó en el capítulo de Materiales y Métodos, la operación de inventariado se corresponde con un frame de
FSA, en el que las múltiples etiquetas acceden al medio para responder al
lector en la ronda de inventariado. Este objetivo también se puede dar por
cumplido.
3. Implementar dos unidades separadas, el lector y la etiqueta, que serán los
participantes del sistema.
El lector y las etiquetas funcionan totalmente por separado, habiéndose elaborado e implementado sendas máquinas de estado independientes. La única
restricción (impuesta por el estándar EPC) es que las etiquetas no responden
si antes no han recibido un comando por parte del lector, pero su funcionamiento no está controlado por ningún otro ente, más que por los comandos
que el lector envía. Este diseño hace cumplir el objetivo en su totalidad.
4. Realizar una implementación clara y legible en un lenguaje sencillo de interpretar por otros programadores.
El lenguaje de programación Python ha sido el elegido para realizar la implementación. La decisión responde al cumplimiento de este objetivo, ya que
como se expone en la página web de Python [11] y en la Sección 2.2, éste es
un lenguaje de sintaxis clara y legible. Una ventaja añadida de este lenguaje
es que es soportado por GNU Radio, con lo que no se debe portar el código
una vez implementado a un lenguaje que entienda este framework.
5. Implementar un esquema modular que permita la inclusión posterior de otras
funcionalidades extra de forma sencilla.
La estructura modular viene impuesta por GNU Radio, al ser los bloques la
unidad básica de procesado de señal en el mismo. Internamente los bloques
también presentan una estructura modular, tal y como se puede observar
en el Apéndice A. Este esquema facilita la inclusión de nueva funcionalidad,
pues sólo es necesario añadir nuevos métodos y modificar el atributo que
apunta a las acciones a realizar en cada caso. Además, también facilita la
corrección de errores. Por tanto también se puede dar como cumplido este
objetivo.
6. Seguir una metodología de desarrollo que permita evaluar paso a paso el
cumplimiento parcial de objetivos.
Posibles mejoras / 73
La metodología seguida está relatada en la Sección 2.6, y corresponde con
una metodología incremental divida en ocho fases. En cada una de las fases
se controla que lo implementado cumple los objetivos, además de realizar
el trabajo deseado. Dicha metodología posibilita el cumplimiento de este
último objetivo específico.
Con todo ello, se puede concluir que el sistema creado cumple en su totalidad
con lo que se pretendía obtener de él, una simulación del comportamiento de FSA
enmarcado en un estándar RFID importante como es el estándar de EPCglobal.
Los resultados medidos en el Capítulo 3 así lo corroboran. Todo ello sin perjuicio
de las posibles ampliaciones y mejoras que se analizarán en la siguiente sección.
4.2.
Posibles mejoras
Según los objetivos establecidos para este proyecto, el sistema permite la inclusión
de funcionalidad de forma sencilla, destinado a que se produzcan mejoras sobre
el mismo. A continuación se exponen algunas de las posibles mejoras que pueden
ser llevadas a cabo en trabajos posteriores.
4.2.1.
Despliegue en entorno real
Una de las posibles mejoras que se pueden efectuar es la del despliegue en un
entorno real mediante hardware de propósito general. En el presente sistema
sólo se contempla la simulación utilizando GNU Radio, aunque con vistas a
esta posible mejora. En este sentido, GNU Radio proporciona la funcionalidad
necesaria para trabajar con el hardware USRP de Ettus Research.
El entorno real corresponderá a la emisión y recepción de comandos
y respuestas utilizando el aire como canal de transmisión. Trabajo adicional
necesario será la implementación de la capa física según establece el estándar EPC.
De esta forma, bien mediante el uso de un único ordenador y un único USRP,
o bien una implementación descentralizada del sistema, se podrá comprobar el
funcionamiento del estándar en condiciones reales. Su uso en condiciones reales
podrá comprobar, por ejemplo, la robustez del sistema a los errores de transmisión
que pudieran ocurrir.
4.2.2.
Implementación de la operación de acceso
Los objetivos del presente proyecto concedían el protagonismo a la operación
de inventariado, puesto que es aquella que desarrolla FSA. Sin embargo las
demás operaciones son interesantes desde el punto de vista del funcionamiento del
estándar EPC. La operación de selección ha sido implementada, no así la de acceso.
74 / Conclusiones (C. 4)
Como se explicó en la Sección 2.1.3, la operación de acceso consigue acciones
como escribir datos en la etiqueta, leerlos o incluso desactivar permanentemente
la misma. En concreto, los comandos que el lector deberá implementar serán
Req_RN, Read, Write, Kill y Lock, y los mismos deberán ser entendidos y
procesados por las etiquetas.
La implementación de dicha operación permitirá tener un sistema totalmente
compatible con el estándar EPC, pues todos los comandos obligatorios estarán
implementados, ya que el sistema actual cumple los demás requisitos impuestos
por el mismo.
Apéndices
75
Apéndice
A
Descripción de los atributos y
métodos de las clases construidas
Clase Tag
Atributos
S Array de booleanos que representan los indicadores de sesión según el estándar.
SL Booleano que representa el indicador SL.
state Estado actual de la etiqueta (representado por un entero).
name Nombre de la etiqueta, definido en el momento de instanciarla.
Q Parámetro que configura la longitud de la trama FSA.
slotCounter Contador de slots restantes para que la etiqueta responda al lector.
session Sesión actual de la ronda de inventariado a la que se está respondiendo.
selected Valor booleano que indica si la etiqueta participa o no en la ronda.
RN16 Registro del número aleatorio generado y enviado al lector para contrastarlo con el ACK que proviene de éste.
EPCbank Memoria EPC de la etiqueta.
truncate Valor booleano que indica si la respuesta única de la etiqueta debe ser
truncada o no.
pointer En caso de que la respuesta sea truncada, posición de memoria desde la
que se transmitirá
lock Objeto Lock que hace la función de sincronización para poder imprimir por
pantalla información sin solaparse con los demás agentes.
77
78/ Apéndices
verbose Valor booleano que indica si debe mostrar más mensajes por pantalla de
los normales.
ACTION Matriz de punteros a métodos de la clase. Esta matriz indicará qué
método debe ejecutarse teniendo en cuenta el estado actual y el tipo de
comando recibido.
Métodos
noAction(message) Este método no realiza ninguna acción. Es necesario para
cumplir el propósito del atributo ACTION.
select(message) Ejecuta el procesamiento del comando Select que se incluye en
message, sea cual sea el estado en el que se encuentre la etiqueta.
query(message) Ejecuta el procesamiento del comando Query, en cualquiera de
los estados excepto en Acknowledged.
newRound() Prepara una nueva ronda de inventariado tras comprobarse que la
etiqueta puede participar en la misma. Es llamado por el método anterior.
acknQuery(message) Procesa el comando Query recibido si la etiqueta está en
el estado Acknowledged, pues si la sesión es la misma que la sesión en la
que la etiqueta participaba se debe invertir el indicador de sesión antes de
participar en la nueva ronda.
replyQuery() Responde al lector con un RN16 (y lo almacena en el atributo del
mismo nombre) cuando llega el slot elegido para responder.
queryRep(message) Procesa el QueryRep recibido en el estado Arbitrate.
toReady(message) Cambia el estado de la etiqueta a Ready después de una
identificación satisfactoria si se ha recibido un QueryRep
qAdjToReady(message) Cambia el estado de la etiqueta a Ready después de
una identificación satisfactoria si se ha recibido un QueryAdjust
returnArbitrate(message) Cuando la identificación no ha tenido éxito este
método hace volver la etiqueta al estado Arbitrate.
queryAdjust(message) Realiza el procesamiento del comando QueryAdjust en
los estados Arbitrate y Reply.
ack(message) Procesa el comando ACK y responde al lector si procede.
nak(message) Ejecuta el procesamiento del comando NAK, o lo ignora si no es
para esta etiqueta.
Apéndices/ 79
receive(message) Recibe el comando, se encarga de identificar de qué tipo es y
de ejecutar el método especializado en el mismo en cada estado. También se
encarga de devolver la respuesta al comando si procede.
work(input_items,output_items) El método que el planificador GNU Radio
ejecuta en cada bloque. Se encarga de recibir el comando, llamar a receive
y enviar la respuesta, hasta que llega la señal de apagado.
Clase Reader
Atributos
Q El parámetro del estándar que define la duración de la trama.
session Sesión en la que se efectúa el inventariado
slotCounter Contador de slots para marcar el fin de trama.
state Estado del lector, expresado por un número entero.
select Parámetro del comando Query que está relacionado con el indicador SL
de las etiquetas.
target Estado del indicador de sesión en las etiquetas al que se dirige la ronda.
tagsIdentified Número de etiquetas identificadas.
lock Mismo funcionamiento que en Tag.
collisions Indicador de colisión
verbose Mismo funcionamiento que en Tag.
ACTION Array de punteros a métodos de la clase que se encargan de dirigir el
funcionamiento del lector en cada estado.
Métodos
isReaderFinished() Devuelve True si el lector se encuentra en el estado final.
wereCollisions() Devuelve True si ha habido colisiones en la trama.
getTagsIdentified() Devuelve el número de etiquetas correctamente identificadas en la ronda.
80/ Apéndices
getStateReader() Devuelve el estado en el que se encuentra el lector (expresado
como un número entero).
selectCommand(target,action,membank,pointer,length,mask,truncate)
Elabora y envía un comando Select a las etiquetas con los parámetros
indicados.
query() Elabora y envía un Query a las etiquetas para empezar la ronda. Los
parámetros del comando son los atributos del lector.
queryRep() Elabora y envía un QueryRep con la sesión que indica el atributo
session.
queryAdjust(session,increment,decrement) Elabora y envía un comando
QueryAdjust con los parámetros indicados.
ack(rn16) Elabora y envía un ACK con el RN16 indicado.
nak() Elabora y envía un NAK.
noAction() Este método no realiza ninguna acción. Es necesario para cumplir el
propósito del atributo ACTION.
state_Ack(message) Método encargado del funcionamiento del lector en el estado ACK.
state_running(message) Método encargado del funcionamiento del lector en
el estado Running.
continueRound() Método que continúa la ronda de inventariado, encargándose
del control sobre el atributo slotCounter y ordenando el fin de la ronda o
bien la llamada al método que envía el comando QueryRep.
start_inventory(message) Método encargado del comienzo de la ronda, llamando al método query() y cambiando el estado a Running.
receive(message) Este método se encarga de llamar al método apropiado dependiendo del estado en el que esté el lector, con la ayuda del atributo
ACTION.
reset_reader() El método es el encargado de preparar el lector para una nueva
ronda, colocando el lector en el estado inicial y reseteando sus atributos.
work(input_items,output_items) El método que el planificador GNU Radio
ejecuta en cada bloque. Se encarga de recibir respuesta del bloque de control
(ControlBlock), llamar a receive y enviar el comando generado, hasta
que el lector transiciona al estado final, que envía la señal de apagado a las
etiquetas.
Apéndices/ 81
Clase ControlBlock
Atributos
n Número de etiquetas que se han creado. Este bloque contendrá n + 1 puertos
de entrada, uno más para sincronizarse con los comandos del lector.
messages Diccionario que almacena temporalmente las respuestas de las etiquetas hasta que todas contestan, para así deducir si ha habido colisión o no.
Métodos
isUniqueResponse() Deduce si ha habido una única respuesta. Devuelve un
booleano.
reset_control() Vacía el diccionario messages.
work(input_items,output_items) El método ejecutado por el planificador de
GNU Radio. Este método realiza el procesamiento del bloque, devolviendo
alguna respuesta (o no) al lector cuando éste envía un comando.
Clase TopBlock
Atributos
reader_instance Instancia del bloque del lector (Clase Reader).
controlModule Instancia del bloque de control (Clase ControlBlock).
tags Lista con instancias de las etiquetas creadas (Clase Tag).
Métodos
Esta clase no contiene más métodos que los heredados. El constructor elabora el
grafo de GNU Radio necesario para que la librería funcione.
82/ Apéndices
Clase MyProject
Atributos
Q El parámetro del estándar que define la duración de la trama FSA.
SESSION_READER Sesión en la que se efectuará el inventariado.
SEL Parámetro del comando Query del mismo nombre.
TARGET Parámetro del comando Query del mismo nombre.
ntags Número de etiquetas que intervienen en la ronda.
Métodos
main() Método principal que ejecuta el algoritmo explicado en el Capítulo 3. Se
encarga además de instanciar el grafo de GNU Radio (clase TopBlock) con
los parámetros deseados.
Bibliografía
[1] EPC Radio-Frequency Identity Protocols Class-1 Generation-2 UHF RFID
Protocol for Communications at 860MHz-960MHz, EPCglobal Inc., Oct.
2008.
[2] ISO 18000-6C: Radio Frequency Identification for item management - Part
6: Parameters for air interface communications at 860MHz to 960MHz, ISO,
2010.
[3] Página web de GNU Radio. [Online]. Available: http://www.gnuradio.org
[4] Wikipedia. [Online]. Available: http://www.wikipedia.org/
[5] (2012) Sitio web de la revista The RFID Journal. [Online]. Available:
http://www.rfidjournal.com/
[6] K. Finkenzeller, RFID Handbook, 2nd ed. John Wiley and Sons, 2003.
[7] H. Stockman, “Communication by means of reflected power,” Proceedings of
the IRE, pp. 1196–1204, Oct. 1948.
[8] (2012) Página web de la Fábrica Nacional de Moneda y Timbre. [Online].
Available: http://www.fnmt.es
[9] J. Yu, K. Liu, y G. Yan, “A Novel RFID Anti-Collision Algorithm Based on
SDMA,” IEEE WiCOM ’08, pp. 1–4, Oct. 2008.
[10] M. V. Bueno-Delgado y J. Vales-Alonso, “On the optimal frame-length configuration on real passive RFID systems,” Journal of Network and Computer
Applications, vol. 34, pp. 864–876, Jun. 2010.
[11] Página web de Python. [Online]. Available: http://www.python.org
[12] (2012) Sitio web de Mathworks. [Online]. Available: http://www.mathworks.
com/
[13] Wiki de GrExtras. [Online]. Available: http://github.com/guruofquality/
grextras/wiki
83
84/ Apéndices
[14] Página web de Numpy. [Online]. Available: http://numpy.scipy.org/
[15] J. Landt, “Shrouds of time: The history of RFID,” AIM, Association for
Automatic Identification and Data Capture Technologies, Oct. 2001.
[16] L. Zhu y T.-S. P. Yum, “A Critical Survey and Analysis of RFID AntiCollision Mechanisms,” IEEE Communications Magazine, vol. 49, no. 5, pp.
214–221, May 2011.
[17] J. Park, M. Y. Chung, y T.-J. Lee, “Identification of RFID Tags in FrameSlotted Aloha with Tag Estimation and Binary Splitting,” IEEE, 2006.
[18] A. Schantin, “Forward Error Correction in Long-Range RFID Systems.”
[19] C. Turner, “Backscatter modulation of Impedance Modulated RFID tags.”
Feb. 2003.
[20] Cátedra de Sistemas Digitales de Comunicación. Universidad de Siegen.
[Online]. Available: http://www.dcs.uni-siegen.de
[21] J. A. Chávez Reyes, “Software Radio y el USRP,” Tesis doctoral, Universidad
de las Américas - Puebla, Oct. 2005.

Proyecto Fin de Carrera - GSyC

Transcripción

Documentos relacionados

Etiquetas Indicadoras de Temperatura