Sistema de Gestión de Usuarios

del Metro de Bilbao

19 de Mayo de 2008
Borrador

3º Grupo
Ion B.
Padilla

Liher Granado

Daniel García

Igor Ordóñez

Endika Montejo

Índic
e
1 EL PROBLEMA.......................................................................................4
2 OBJETIVOS DEL PROYECTO.....................................................................4
2.1 MÍNIMOS............................................................................................................... .4
 2.2 LÍMITES.............................................................................................. ...................4
3 ANÁLISIS..............................................................................................5
3.1 ANÁLISIS CONCEPTUAL.......................................................................................... .......5
3.1.1 Metro de Bilbao.................................................................. ...........................5
3.1.2 Gestión......................................................................................... .................6
3.1.3 Usuarios......................................................................... ...............................6
3.1.4 Hardware.............................................................................................. .........6
3.1.5 Software..................................................................................... ...................7
3.1.6 Esquema conceptual........................................................... ..........................9
3.2 ANÁLISIS TÉCNICO..................................................................... ..............................10
3.2.1 Gestión....................................................................................... .................10
3.2.2 Hardware............................................................................................ .........11
3.2.3 Software................................................................................... ...................15
3.2.4 Esquema general para 2 paradas................................................ ................15
4 DESARROLLO.......................................................................................16
4.1 MODELIZACIÓN............................................................................................... ........16
4.1.1 Base de Datos................................................................ .............................16
4.1.2 Software................................................................................... ...................17
4.1.3 Hardware............................................................................................ .........19
4.2 IMPLEMENTACIÓN.................................................................................... .................20
4.2.1 Base de Datos................................................................ .............................20
4.2.2 Software................................................................................... ...................21
4.2.3 Hardware............................................................................................ .........22
5 POSIBLES MEJORAS.............................................................................22
5.1 PROGRAMA DE GESTIÓN.......................................................................... ...................22
5.2 TERMINAL TÁCTIL................................................................................................ .....22
6 ANEXOS..............................................................................................23
6.1 OBJETIVOS DE APRENDIZAJE......................................................................... ................23
6.1.1 Tecnología de computadores....................................................... ................23
6.1.2 Bases de datos...................................................................... ......................23
6.1.3 Tecnología orientada a objeto................................................................. .....23
6.2 PLANIFICACIÓN Y HERRAMIENTAS........................................................................ ............24
6.2.1 Herramientas.......................................................................................... .....24
6.2.2 Tests.......................................................................................... ..................25
6.3 LATENCIA........................................................................................ .....................26
6.4 PROTOCOLO RS-485................................................................................. .............26
6.5 TECNOLOGÍA RFID EN EL TRANSPORTE PÚBLICO.................................. ...............................27
6.6 TÉCNICAS DE 2 Y 4 HILOS RS485.................................................. ............................27
7 BIBLIOGRAFÍA.....................................................................................29

2
3
1 El problema
Las carreteras de las ciudades están cada día más congestionadas. Es
por ello que existen medios de transporte públicos como el Metro. Para que
este transporte sea eficaz, la forma de acceder a él debe ser tan rápida y
efectiva como el propio viaje. Además debemos ser capaces de recoger
información básica desde el sistema sobre el uso de este transporte. De esta
forma podríamos adaptarlo a las necesidades de la ciudad, responder a las
necesidades del cliente y proponer mejoras. Debido a esto, se precisan
herramientas que permitan automatizar y facilitar estas tareas tanto al usuario
que accede al Metro como al equipo que lo gestiona y trata de mejorarlo cada
día, ya que otras formas no automatizadas son menos eficaces y más lentas.

Resumiendo: debemos facilitar información al usuario para poder

prestarle una forma fácil, rápida y cómoda de acceder a este medio de
transporte; y también al equipo que gestiona el Metro, para que puedan
extraer información y estadísticas exactas de la forma más rápida posible que
ayuden a mejorar el servicio sin tener que realizar sondeos ni observaciones.

2 Objetivos del proyecto

Una vez concretado el problema, debemos proponer una solución y
demostrar su funcionamiento. Este proyecto está planteado para que como
alumnos de MGEP1 obtengamos ciertas cualificaciones y conocimientos. A esta
metodología se la denomina como aprendizaje basado en problemas o PBL
(Anexos: Objetivos de aprendizaje).

En base a ello, y al tiempo disponible para su realización (Fecha límite: 16

de Junio de 2008), definiremos los objetivos mínimos y los límites fijados en
torno a ellos.

2.1 Mínimos
Este sistema deberá permitir lo siguiente:

• Acceder al Metro en dos modalidades básicas: esporádica o habitual.

• Almacenar toda la información relacionada con los accesos al Metro.

2.2 Límites
Nos centraremos en:

• Los usuarios del Metro, habituales o esporádicos.

• Los accesos al Metro por parte de los usuarios.
• La gestión básica de estos dos últimos conceptos.

1Mondragon Goi Eskola Politeknikoa, Escuela Politécnica Superior de Mondragón.

4
 Por consiguiente, todo lo que se escape a estos tres conceptos y a la
implementación de un sistema básico para el acceso y gestión del Metro
estaría fuera de lo que serían los límites fijados para este proyecto.

3 Análisis
En el análisis, estudiaremos las diferentes posibilidades y vías técnicas
para poder prestar una solución al problema antes citado.

3.1 Análisis conceptual

Concretaremos el proyecto desde una perspectiva conceptual, sin entrar
en cuestiones técnicas. Definiremos totalmente lo que se desarrollará, teniendo
en cuenta los servicios que debe prestar y los objetivos del proyecto.

3.1.1Metro de Bilbao
El Metro es un sistema de transporte público de masas, que pretende dar
rapidez y fluidez al transporte en las ciudades.

En 2007 86 millones de viajeros utilizaron la red de metro de Bilbao, lo

que convierte a esta infraestructura en la tercera más utilizada de España, por
detrás del Metro de Madrid y del de Barcelona, y por delante del de Valencia y
Palma de Mallorca.

Por lo tanto, de media, el Metro de Bilbao soporta mensualmente 7,2

millones de viajeros, unos 240.000 diarios, con excepciones como el día de
mayor afluencia, el de Santo Tomás, con un millón de usuarios en sólo 24
horas. Este tráfico se divide en 2 líneas de Metro: L1 Plentzia/Etxebarri y L2
Portugalete/Etxebarri. La primera cuenta actualmente con 28 estaciones a lo
largo de 31 kilómetros, mientras que la segunda se reduce a 20 estaciones y
20 kilómetros de extensión.

Ilustración 1, Red actual de Metro de Bilbao

La tarificación del Metro está hecha en base a las líneas, siendo
obligatorio el paso del ticket o pase tanto a la entrada como a la salida. Existen
infinidad de billetes (Billete ocasional, Ida y vuelta, Billete día, Billete mensual,
Ticket joven…), pero el más usado es el Creditrans, el cual cuenta con un saldo
5
inicial al que se le va descontando los sucesivos importes de los viajes. Se
estudia la implantación de la tarjeta BARIK, la cual se basa en la tecnología
RFID2, pudiendo prescindir del contacto físico entre el lector y la tarjeta para su
validación, haciendo mucho más rápido el acceso al Metro ().

3.1.2Gestión
Necesitamos darle al equipo de gestión la posibilidad de extraer
información sobre el uso del Metro, aquélla que nos ayude a mejorar el sistema
y adaptarlo a su uso, y además permita realizar las operaciones más comunes:
crear un nuevo usuario habitual, dar de baja a un usuario habitual, conocer la
cantidad de accesos diarios... La razón está bien clara: evitar la realización de
inexactos sondeos sino lograr unas estadísticas totalmente exactas, que
ayuden a prever saturaciones del Metro y responder a las necesidades de los
usuarios. Esta función la cumplirá un sistema de información común para todo
el Metro.

3.1.3Usuarios
Hay que facilitarle al usuario el acceso al Metro. Primero hay que pasar a
ser usuario del metro de Bilbao. Así que, ¿Quién es usuario del Metro?
¿Cómo se pasa a ser usuario del Metro? ¿Qué formas hay de ser
usuario?

Usuario del Metro es aquel que lo usa: ya sea una, dos o cien veces; al
día, a la semana o una vez en su vida. Por ello podemos distinguir entre
usuarios habituales y esporádicos.

3.1.4Hardware
En este apartado se analizarán los soportes físicos que serían necesarios
para el sistema.

3.1.4.1 Pases
Los usuarios deben recibir un soporte físico en el que albergar su
derecho a entrada, el cual demuestre que se ha pagado por el acceso.

Para los usuarios esporádicos, el uso del típico ticket es lo más fácil e
intuitivo, y más barato que expedir tarjetas sólidas las cuales podrían ser
extraviadas o desechadas. Pensamos en otras posibilidades para los usuarios
habituales, como son las tarjetas con banda magnética o tarjetas de
radiofrecuencia, además de la posibilidad de emplear el número DNI o alguna
contraseña personal para introducirla en los tornos de acceso. Estas dos
últimas opciones no tienen coste de soporte físico (papel, plástico), pero puede
ser engorrosa para los usuarios.

2Radio Frequency Identification, sistema de identificación por radiofrecuencia.

6
 Las formas de pago que se les puede ofrecer a los usuarios esporádicos
no van más allá del pago en efectivo en las estaciones; pero para los usuarios
habituales y la recarga de sus bonos pensamos en varias opciones, como la
recarga a través del móvil, Internet o automáticamente al agotar el saldo, por
medio de la asociación de una cuenta bancaria a la cuenta de usuario. Aun así,
la opción más usual para estos sería la de recargar su tarjeta en las terminales
instaladas en las propias estaciones.

3.1.4.2 Obtención de pases

Debe existir un dispositivo físico que automáticamente y de la forma
más veloz posible expenda pases a los usuarios: las terminales de acceso.
Además, se puede integrar en ellos la funcionalidad de recargar pases de
usuarios habituales. No debería ofrecer muchas posibilidades complementarias
para evitar colas. Por esta razón se ha pensado que las operaciones
complementarias como por ejemplo darse de alta como usuario habitual sean
realizadas en otros dispositivos físicos o personales.

3.1.4.3 Validación de pases

Para validar estos pases los usuarios deberán pasar a través de algún
soporte físico automático que compruebe si el susodicho usuario puede
acceder al Metro, es decir, si ha pagado o tiene saldo para acceder. La
implementación de la validación de pases a través de trabajadores del Metro
originaría colas y un gasto innecesario de dinero, por lo que una solución
automática es mucho más deseable. Nos referiremos a estos dispositivos como
los típicos ‘Tornos’ de acceso.

3.1.4.4 Interconexiones
Para hacer posible que este sistema funcione y sea capaz de proveer
estadísticas de uso y herramientas para la manipulación de datos, los
dispositivos deben grabar información referente a las operaciones realizadas
por parte de usuarios como la expedición de billetes. Es por esto que deben
estar conectados al sistema de gestión de información.

3.1.5Software
Definiremos conceptualmente de qué partes de software precisa el
sistema hasta ahora definido.

3.1.5.1 Programas
Necesitamos dos programas básicos: el instalado en las terminales de
obtención de pases, el cual se encargará de todo lo referente a esta
funcionalidad, y el empleado por el personal de gestión del Metro para la
obtención y manipulación de datos y estadísticas.

Además de estos dos programas, hace falta uno más que ejerza de
interlocutor entre los tornos de acceso y la base de datos. Estos tornos deben
7
validar las peticiones que reciban, y para ello deben comunicarse con la base
de datos para cotejar la información. La inteligencia no residirá en estos
dispositivos, no dispondrán de la posibilidad de comunicarse directamente con
la base de datos. Simplemente enviarán los datos que lean de las tarjetas o
tickets de los usuarios a otro dispositivo, centralizando la gestión y la
comunicación con la base de datos en un solo dispositivo. Este será el que
contenga el programa mencionado.

3.1.5.2 Interfaces de usuario

Existen una o varias interfaces, las cuales son la cara digital del Metro
hacia el usuario. Dentro de estas interfaces podríamos encontrar una web en
Internet, la interface de las terminales del propio Metro… etc. El usuario
las usará para interactuar con el Metro. Estos interfaces son los encargados de
guiar al usuario a través de todas las tareas que puede ser capaz de realizar
con respecto al Metro y el acceso a él. Además, facilitarán la tarea de gestionar
el Metro al personal de gestión. Podemos distinguir entre dos programas
básicos para el control y el acceso al Metro.

El primero de ellos se trataría del interface integrado en el programa de

las terminales del Metro. El segundo sería el implementado en el programa
para la gestión del Metro. No es necesario implementar un interface de usuario
en el programa interlocutor entre los tornos y el sistema de información, ya
que no ofrece la posibilidad de realizar ninguna tarea, sólo monitoriza eventos.

8
3.1.6Esquema conceptual
Tras este análisis hemos podido diseñar un boceto conceptual del sistema
para una estación. Gracias a él, podremos afianzar lo analizado y proseguir con
el análisis técnico sobre las tecnologías que nos permitirán implementar este
sistema. Es necesario aclarar que la base de datos estará centralizada y todos
los dispositivos de todas las estaciones se conectarán a ella.

Ilustración 2, esquema conceptual del sistema de gestión de una estación de Metro.

9
3.2 Análisis técnico
En este apartado nos centraremos en analizar las diferentes tecnologías
que podríamos emplear para la construcción del sistema ideado en el análisis
conceptual.

3.2.1Gestión
Toda la información que genere este sistema debe ser almacenada. Para
ello, usaremos una base de datos, la cual nos permite gracias a los lenguajes
SQL3, DDL4 y DML5 una completa gestión y manutención de los mismos.

3.2.1.1 Comparación entre MySQL y Oracle

Para la creación de la base de datos disponemos de múltiples opciones
como MySQL, Oracle y PostgreSQL. Es difícil decantarse por una de ellas.
Realizaremos una comparación simple, la cual nos ayudará a elegir y
comprender los pros y contras de cada opción.

MySQL
Open Source, sin ningún coste.
Sencillez en la creación de las bases de
datos.
Se recomiendan 128MB RAM y 1GB de
disco duro para servidores.
Menor seguridad que Oracle.
Buena velocidad.
Para las características avanzadas, hay
que usar el motor InnoDB.
Oracle
8,800 USD versión empresarial.
Alta dificultad en la creación de las bases
de datos.
7 veces más de espacio en disco duro y
16 veces más de RAM que MySQL
aproximadamente.
Alta seguridad.
Mayor velocidad que MySQL.
Implementa prácticamente todas las
características de las bases de datos.
Tabla 1, Comparación entre MySQL y Oracle.

Usaremos MySQL para la simulación del sistema, por su sencillez, por ser
de código libre y por el bajo consumo de recursos. Aun así, prevemos que en la
aplicación real del proyecto debería ser usada una base de datos comercial
como Oracle, ya que necesitaría ser más potente para soportar el continuo fluir
de datos, agilizando y permitiendo de esta manera más consultas ().

3.2.2Hardware
Debe existir un ordenador que se encargue de recibir la información de
las diferentes terminales y dispositivos que deseen escribir o leer datos de la
base de datos. El servidor será aquel que albergue la base de datos. Deberá
estar continuamente ejecutando un programa que se encargará del recibo y
envío de datos a través del puerto de serie, USB, Ethernet o cualquiera que sea
el BUS de datos escogido.

3Structured Query Language.

4Data Definition Language.

5Data Modification Language.

10
 Se puede plantear un esquema en el que los dispositivos se comuniquen
con la base de datos central por Ethernet y Fibra Óptica. Esto haría que
prescindiéramos de crear un programa capaz de leer consultas de las
terminales de la estación, ya que el SGBD6 de MySQL se encarga
automáticamente de las peticiones recibidas por Ethernet. Debido a la falta de
tiempo y los objetivos de aprendizaje de este proyecto, sólo implementaremos
esta comunicación entre ordenadores con tarjeta de red pre-instalada y
valiéndonos de routers comerciales. Pasaremos a analizar la comunicación con
el hardware de los tornos de acceso.

3.2.2.1 Tarjetas
El soporte físico seleccionado para otorgar el derecho a acceder al Metro
a los usuarios habituales son las tarjetas. Nos centraremos en tres tipos, las
tarjetas basadas en RFID, las tarjetas magnéticas y las tarjetas inteligentes.

RFID
VENTAJAS DESVENTAJAS
Muy duraderas ya que no hay que
pasarlas por ningún sitio. Con el simple Son fáciles de piratear o copiar, sin que se
hecho de ponerlas cerca del lector es entere el usuario.
suficiente. Por lo tanto no se desgastan.
Existen tarjetas de lectura y escritura, y
además no necesitan de alimentación, les Alto coste de los lectores. Unos 200 € las
es inducida por el lector en el momento unidades comerciales.
de la lectura.
Lecturas más rápidas y más precisas que
en otro tipo de tecnologías.
Dinamizaría mucho más las colas,
reduciendo el tiempo de espera para
acceder.
Bajo coste de las tarjetas. En fecha de
2004, las etiquetas tienen un precio
desde 0,40$.
Tabla 2, ventajas y desventajas de la tecnología RFID.

TARJETAS MAGNÉTICAS
VENTAJAS DESVENTAJAS
Desgaste producido al pasarla por
Bajo coste.
los lectores.
Tecnología muy conocida y
Son fáciles de piratear o copiar.
utilizada.
Lentitud en los accesos.
Tabla 3, ventajas y desventajas de las tarjetas con banda magnética.

TARJETAS INTELIGENTES
VENTAJAS DESVENTAJAS
Procesador criptográfico seguro, sistema Alto coste de lectores y tarjetas.

6Sistema de Gestión de Bases de Datos.

11
 de archivos seguro, características
legibles por humanos.
Es capaz de proveer servicios de
seguridad.
Tabla 4, ventajas y desventajas de las tarjetas inteligentes.

Guiándonos por estas características, las tarjetas más convenientes para

este sistema serían las de tecnología RFID. Últimamente todos los servicios de
transporte públicos tratan de implementar sistemas RFID, que frente a la cada
vez más anticuada tecnología de bandas magnéticas presenta muchas más
ventajas. Han sido implantadas en diferentes metros con un éxito rotundo, por
ello creemos que un sistema en el cual el usuario se sentirá más cómodo.
(Anexos, Tecnología RFID en el transporte público).

La implantación de cualquiera de los tres tipos de tarjetas sería igual de

sencilla. El dispositivo lector sería conectado al microcontrolador individual de
cada terminal de acceso. Este lector, al detectar una tarjeta, ya sea magnética,
por radio frecuencias o inteligente, nos dará la ID7 de la tarjeta, la cual
usaremos para llevar a cabo las acciones necesarias.

Al no poder adquirir la tecnología RFID, ya que los lectores disponibles

en MGEP eran autónomos y sin conexión externa, nos hemos decantado por el
uso de tarjetas magnéticas.

3.2.2.2BUS
Nuestros tornos o terminales de acceso leerán la tarjeta, y deberán
enviar su información al servidor, para que sea comprobada en la base de
datos y devolver un sí o un no. Además, el servidor realizará las operaciones
necesarias sobre la base de datos, como descontar el dinero y agregar un
acceso. Por lo tanto todos los dispositivos conectados al BUS envían y reciben
información. Cada terminal de acceso dispondrá de un PIC, que se encargará
de la comunicación y de las diferentes tareas necesarias. Como podemos ver,
tenemos múltiples PIC que deben enviar información a un único punto, el
servidor, mientras que éste es el único que responde a todos ellos. Nuestro
sistema se identifica, por lo tanto, con una aplicación Máster/Slave.

El BUS RS-485 es el único BUS RS que permite que haya más de un

transmisor, hasta un máximo de 32. Este BUS ofrece una longitud máxima de
1200 metros a 100Kbps, y hasta 35Mbps a 10 metros. Por lo tanto es una
velocidad rápida para nuestro sistema, y una distancia bastante aceptable.
Cumple con todas las necesidades del sistema, y es por esto que lo hemos
seleccionado.

7Identification Number, número de identificación.

12
 Existen dos posibilidades para el BUS RS-485: 2 hilos y 4 hilos. En
nuestro caso usaremos la técnica de dos hilos, ya que frente a la de cuatro
hilos, simplifica el sistema y abarata los costes.La única ventaja que aporta
esta última configuración es la de poder establecer una conversación en la
comunicación, pudiendo enviar y recibir paralelamente la información; dado
que nuestro sistema se caracteriza por una comunicación secuencial, se trata
de una característica prescindible (Anexos, Técnicas de 2 y 4 hilos RS485).

Otra de las características del BUS a analizar es el carácter

monomaster o multimaster. En una disposición monomaster, es necesaria la
utilización de la técnica denominada polling8, que sería llevada a cabo por el
máster del BUS. En el caso de utilizar la opción multimaster, es necesario un
árbitro que determine quién será el que transmita información, es decir, si
hubiera dos dispositivos queriendo asumir el rol de máster, sería necesario un
protocolo a seguir para determinar quien realmente lo hará.

Se deben analizar las desventajas y ventajas de cada una de las

opciones con respecto a la aplicación y la repercusión en el usuario para poder
decantarse por una de ellas. Esta repercusión se limita a la velocidad de
respuesta del dispositivo, lo único perceptible por el usuario. En la siguiente
tabla se mide la velocidad de respuesta del sistema en dos situaciones
diferentes. Las dos se basan en el uso simultáneo de varios dispositivos,
representando FULL todos los dispositivos (máxima carga de trabajo) e IDLE
una carga baja para el BUS, 2 o 3 dispositivos.

Monomaster Multimaster
Mayor velocidad. Menor velocidad.

Los dispositivos no tienen Se debe pedir permiso al

Rendimiento FULL que enviar ninguna árbitro y además,
petición a ningún árbitro establecer la
antes de la comunicación. comunicación.
Menor velocidad.
Mayor velocidad.
El sistema puede que
Los dispositivos afectados
Rendimiento IDLE pierda el tiempo
piden permiso al árbitro y
preguntando a los
sólo ellos establecen
dispositivos que no estén
comunicación.
en uso.
Tabla 5, rendimiento de las disposiciones multimaster y monomaster del BUS Tornos<-
>Servidor.

8Operación de consulta constante hacia, generalmente, uno o varios dispositivos de

hardware para crear una actividad sincrónica.
13
 Ya que lo que queremos potenciar es la respuesta en horas punta del
Metro, escogeremos la configuración monomaster. Este máster será un
ordenador, que actuará de servidor como se describe al comienzo de esta
misma sección. Se puede encontrar un cálculo aproximado de la latencia del
sistema en (Anexos, Latencia).

Para poder conectar este BUS a un ordenador, debemos disponer de

un puente entre RS-232 y RS-485, que realice la conversión entre los niveles
de tensión de estos dos estándares. Además los PIC deberán tener una UART 9
integrada, ya sea por software o hardware, para la comunicación por línea RS.

3.2.2.3 MICROCONTROLADORES
Los tornos necesitan de capacidad de procesamiento para leer las
tarjetas y comunicarse con el máster del BUS. Para otorgarles esta capacidad,
estarán gobernados por PICs10 que serán, en principio, de la serie PIC16F87X,
los cuales incorporan una unidad UART para la comunicación por puerto de
serie, ideal para nuestro planteamiento. Específicamente para esta aplicación,
seleccionaremos un PIC de esta gama sin puerto paralelo, el PIC16F873.

3.2.2.4 PROTOCOLO
Al elegir el sistema monomaster, para facilitar la comunicación entre
los diferentes microcontroladores de los tornos y el PC, hemos creado un
protocolo específico que cumplirán todos los paquetes que viajen por el bus. Se
define con total concreción cual es el número de paquetes necesario, cuales
son los distintos tipos de paquetes, de que bits se componen, y en qué orden
se realiza esta comunicación. Este protocolo evita conflictos en el BUS, como el
que la transmisión por parte de un PIC pueda ser malinterpretada por otro PIC,
ambos esclavos (Anexos: Protocolo RS-485).

3.2.3Software
Los programas son construidos con lenguajes de programación como
Java, PHP y un largo etc. En este caso concreto todos los programas serán
desarrollados en Java, ya que es un lenguaje orientado a objeto con una gran
cantidad de librerías, al cual le caracteriza una gran portabilidad en diferentes
maquinas. Además, al ser orientado a objeto, nos facilitaría la realización de
cambios y la identificación de errores.

Los programas dirigidos a la gestión y el acceso por parte de los usuarios

o los trabajadores deberán implementar una GUI11, para aumentar la

9Universal Asynchronous Receiver Transmitter.

10Programable Intelligent Computer, Computador Inteligente Programable.

11Graphical User Interface, Interfaz Gráfica de Usuario.

14
usabilidad. Java nos da varias opciones como AWT12 y Swing. Por la mayor
portabilidad y mayor nivel de sofisticación en comparación con AWT, en
nuestro caso Swing es la mejor opción.

3.2.4Esquema general para 2 paradas

Ilustración 3, esquema general de conexiones para 2 estaciones.

4 Desarrollo
En esta sección se describirá el proceso de desarrollo del proyecto,
explicando de una forma cronológica los diferentes sucesos a lo largo de la
implementación. Se describirán los recursos empleados, la organización y
división de tareas, los problemas encontrados y la resolución de los mismos.

4.1 Modelización
El primer paso en el desarrollo consiste en la creación de un modelo para
cada una de las partes del mismo. Valiéndonos de diferentes diagramas,
diseñamos el software y hardware que toman parte en el sistema. Nos
aseguramos de que todos los miembros del grupo tomasen parte en esta fase,
crucial para el proyecto.

4.1.1Base de Datos
La base de datos fue diseñada en primer lugar, usando diagramas de
entidad-relación y relacionales.

Uno de los problemas que surgió fue el siguiente: en una aplicación real,
debería existir algún sistema parar borrar las entradas que generasen los
usuarios esporádicos, teniendo en cuenta que al cabo de un año el volumen de
información sería de unos 7 millones de registros. Pero por otro lado, también
queremos seguir almacenando estos datos. Aunque no será implementada,
una de las soluciones posibles sería la creación de una tabla que guardase un
historial de accesos por mes, trimestre o año, comprimiendo las estadísticas de
todo ese período de tiempo a un registro. Paralelamente con la creación de
este registro, se borraría por completo el contenido de las tablas Acceso y
Billete (Anexos: MySQL Workbench).

12Abstract Window Toolkit.

15
 Ilustración 4, diagrama relacional de la base de datos para el proyecto.

4.1.2Software
Una vez diseñada la base de datos y el hardware, comenzamos con la
modelización del Software. En esta parte se diferencian 3 programas distintos:
el programa que proveerá a los usuarios de tickets y billetes, el programa que
se grabará en cada torno de acceso y el que actuará de puente entre la base
de datos y los tornos.

En el diseño del programa dedicado a la expedición de billetes, se ha

tratado de crear un modelo que permita sin dificultades el cambio de interfaz
de usuario y de base de datos mediante interfaces. Además, se ha facilitado la
adición de nuevos tipos de billetes y recargas, incluyendo estos mediante
herencia desde sendas clases abstractas. De esta forma, si el programa
debiera ser modificado, al estar contempladas las modificaciones más
comunes, no costaría demasiado esfuerzo. En este programa sólo incluiremos
un tipo de billete.

16
 Ilustración 5, diagrama de clases UML para el programa ‘Terminales’.

En el programa dedicado al puente de comunicación entre la base de

datos y los tornos, además de incluir un interface que permita el fácil cambio
de base de datos, se ha incluido otra más que lo hace con la vía a usar para la
comunicación con los tornos, llamada IOTornos. Por tanto, si cambiásemos la
comunicación con estos de RS232 a por ejemplo, Ethernet, el programa sería
fácil de adaptar.

Ilustración 6, diagrama de clases UML para el programa ‘GestionTornos’.

17
 En el caso del programa a grabar en los microcontroladores de los
tornos, fue suficiente con crear un diagrama de secuencia que definiera el
proceso por completo. El programa se dividirá en dos subrutinas
(SubrutinaPreguntaPC y SubrutinaTarjeta) y un programa principal, como se
puede observar a continuación. (Anexos: Oracle JDeveloper y diagramas UML).

Ilustración 7, diagramas de secuencia del programa de los microcontroladores.

4.1.3Hardware
Tras la base de datos, pasamos a diseñar los circuitos electrónicos de los
tornos que se encargan de la lectura de las tarjetas y tickets, otorgando acceso
o no a los usuarios. Analizamos las características del microchip PIC16F873 y
del lector de tarjetas Dorlet, elementos fundamentales del circuito. Para la
integración con el BUS RS-485, buscamos algún tipo de chip similar al MAX232

18
que realizase la conversión de la tensión a niveles TTL13. Encontramos el chip
MAX485 de Maxim. Tras la lectura de su correspondiente Datasheet, pudimos
definir la forma de integrarlo en el circuito. Nos faltaba un componente que
permitiese realizar el puente entre los buses RS232 y RS485. Por rapidez y
comodidad, decidimos adquirir un conversor comercial por nuestra cuenta. En
este momento disponíamos de toda la información necesaria para comenzar a
dibujar el esquema de los dispositivos (Anexos: CircuitMaker).

Ilustración 8, diseño de un módulo para un torno con lector de tarjetas.

4.2 Implementación
Tras la modelización de cada parte, procedimos a su implementación. En
esta sección se irá describiendo este proceso, junto a todos los problemas que
van surgiendo.

4.2.1Base de Datos
La base de datos fue implementada mediante un script autogenerado
por el programa MySQL Workbench (Anexos: MySQL Workbench). Se insertaron
varios valores imaginarios en ella para poder hacer posible una demostración.

13Transistor-Transistor Logic, 0,2-0,8V para nivel bajo (0) y de 2,4V a Vcc (de 4,75 a
5,25V) para nivel alto (1).
19
 Una vez finalizado el proceso de creación de la base de datos, se crearon
los usuarios que dispondrán los diferentes dispositivos que se conectarán a
ella. En nuestro sistema, tanto la terminal como los tornos tendrán un usuario
especial para la conexión con la base de datos. A estos usuarios se les
otorgaran los privilegios indispensables para que su respectivo dispositivo
pueda realizar las operaciones necesarias.

La base de datos fue sufriendo cambios a medida que se desarrollaron

los programas ‘Terminales’ y ‘Tornos’, ya que fueron encontrados errores en el
diseño y mejoras para las tablas ya existentes.

4.2.2Software
La segunda parte que pasamos a implementar fueron los diferentes
programas necesarios: ‘Terminales’, ‘Tornos’ y el programa a grabar en los
microcontroladores. Para esto, y valiéndonos de los diagramas de clases para
los dos primeros programas, dividimos el trabajo en clases o grupos de clases
por cada miembro del grupo. Paralelamente al desarrollo se testeó cada parte
del programa: conexión con la base de datos, conexión vía puerto de serie, etc.

El problema principal que se nos presentó consistía en la creación de

billetes para los usuarios esporádicos. El programa debía crear un nuevo billete
en la respectiva tabla de la base de datos, con un número identificador
diferente a todos los demás, que asignamos simplemente sumando uno al
último número almacenado. Además, tras esto, el programa debe recoger el
número identificador de este nuevo billete. Entre estas dos acciones es posible
que otras terminales creen otros billetes, por lo tanto no existiría garantía de
conseguir leer el número previamente escrito correctamente. La solución
escogida consiste en gestionar este posible error a través de excepciones, ya
que saltará una de ellas si se intenta grabar un registro con un número
identificador ya existente, y será entonces cuando obliguemos al programa a
repetir de nuevo el proceso hasta que consiga grabar el registro con éxito.

Además de esto, tuvimos problemas con la configuración de la librería

que permite la comunicación a través del puerto de serie; los cuales fueron
solucionados tras encontrar la forma correcta de instalación de esta librería
(Anexos: Tests de comunicación RS232).

Tras su finalización, fue implementada una inicialización de los

programas mediante ficheros. De esta forma, las configuraciones necesarias
son introducidas únicamente la primera vez que se ejecuta el programa.
Posteriormente, es posible cambiarlas manualmente editando estos ficheros.

Se buscó la forma de proveer a las ventanas de los programas de

imágenes de fondo. Fueron encontrados varios métodos creados por usuarios
anónimos en Internet que se añadieron al programa ‘Terminales’.

Gracias a Subclipse, pudimos desarrollar de forma cooperativa y

dinámica todas las partes de los mismos (Anexos: Subclipse SVN).

20
4.2.3Hardware
Comenzamos a implementar esta parte justo después de acabar el
diseño conceptual y disponer de todos los materiales para la creación del
dispositivo lector de tarjetas y tickets que nos permitiría realizar la
demostración del sistema.

Tras un sencillo montaje de una placa electrónica provista de un lector

de bandas magnéticas y puerto de serie, comenzamos a realizar pruebas con
diferentes programas que grabamos en el PIC. De estas pruebas surgieron
múltiples problemas, los cuales, tras su resolución, ayudaron a comprender
mejor el funcionamiento de los diferentes elementos implicados en el
dispositivo (Anexos: Tests de funcionamiento de Hardware).

Estos programas fueron grabados con el programa IC-Prog y utilizando

una placa MicroPIC Trainer. Usamos el programa PCW de CCS para compilar
código para el PIC escrito en lenguaje C para microcontroladores (Anexos: IC-
Prog, PCW).

5 Posibles mejoras
En esta sección se irán describiendo los diferentes extras que se pueden
llegar aplicar en el proyecto del metro de Bilbao.

5.1 Programa de gestión

Le permitirá al personal de gestión la obtención de información y
estadísticas sobre el acceso al Metro y sobre sus usuarios habituales o
abonados, para poder realizar una gestión básica. Este sistema podría
ofrecernos los siguientes datos: cantidad media de usuarios en diferentes
intervalos de tiempo, cantidad de usuarios acotada por diferentes intervalos de
tiempo, horas de máximo y mínimo uso de cada día, estaciones y trayectos con
más uso, gestión de frecuencia de trenes en hora punta, previsión de
acontecimientos ferias BEC, partidos futbol, fiestas, cantidad de usuarios
abonados.

5.2 Terminal táctil

Le permitirá al usuario disponer de un una terminal táctil. Este disfrutará
de todas las ventajas ofrecidas por el programa de la terminal, con el aliciente
de poder usar su propio dedo para elegir entre los diferentes menús.

La implementación de la pantalla táctil nos ofrece una serie de problemas, que

debemos afrontar con una serie de cambios. Se deberá modificar las librerías
usadas en el programa de la terminal. Se tendrá que lograr compatibilidad con
JDK 1.3, ya que disponemos es la versión JDK 1.6 que no es compatible con
este sistema. Tampoco dispone de compatibilidad con las librerías Swing y
estas se tendrán que transformar a AWT. Por otra parte no tendríamos ningún

21
problema con las conexiones en red, ya que dicha pantalla táctil dispone de
conexión a la red.

6 Anexos
6.1 Objetivos de aprendizaje
Para aprobar este proyecto se definen los conocimientos que deberían
lograr cada miembro del grupo en cada una de las asignaturas que toman
parte en él.

6.1.1Tecnología de computadores
El alumno debe ser capaz de lo siguiente con respecto a esta asignatura:

• Elegir y utilizar procesadores, memorias y líneas de serie según la

aplicación.
• Implementar el control de dispositivos mediante técnicas de polling e
interrupciones.
• Implementar, evaluar, diseñar y simular una aplicación basada en varios
procesadores.
• Diseñar, evaluar e implementar sistemas electrónicos.
• Dominar las herramientas usadas para encontrar problemas en sistemas
electrónicos.

6.1.2Bases de datos
El alumno debe ser capaz de lo siguiente con respecto a esta asignatura:

• Saber usar la documentación de un SGBD.

• Diseñar una base de datos usando diagramas de entidad-relación y
modelos relacionales.
• Instalar un SGBD.
• Crear una base de datos usando el lenguaje DDL.
• Gestionar las reglas de integridad de una BD.
• Consultar una BD usando el lenguaje SQL.
• Mantener una base de datos usando el lenguaje DML.
• Conocer el funcionamiento de las vistas y saber crearlas.
• Conocer el funcionamiento de los Trigger y saber usarlos.
• Saber gestionar y crear copias de seguridad de una BD.
• Saber gestionar la seguridad de una BD.
• Saber consultar el diccionario de datos para consultar información.
• Saber realizar todas las operaciones citadas mediante comandos.

22
6.1.3Tecnología orientada a objeto
El alumno debe ser capaz de lo siguiente con respecto a esta asignatura:

• Saber realizar un diseño Orientado a Objeto de una aplicación

informática, en el que se optimice la adaptabilidad, la fiabilidad y la
manutención del software.
• Saber utilizar un lenguaje de programación Orientado a Objeto como
Java en el desarrollo de una aplicación, aprovechando todas sus
prestaciones como: encapsulación, herencia, polimorfismo y gestión de
excepciones.
• Saber utilizar un conjunto de componentes de Java, Swing, específicos
para el desarrollo de interfaces gráficos.
• Saber utilizar componentes de Java para el acceso a sistemas de gestión
de bases de datos.

6.2 Planificación y herramientas

En esta sección describiremos la planificación mediante la cual se ha
organizado el trabajo y el grupo para el logro de los objetivos, además de las
herramientas empleadas para ello.

6.2.1Herramientas
Se describirán a continuación las herramientas usadas a lo largo del
proyecto, las cuales ayudaron en el desarrollo del mismo.

6.2.1.1 MySQL Workbench

Usando el modelo relacional y el programa MySQL Workbench, creamos
un esquema de tablas y relaciones que fuese capaz de proveer al sistema de la
información básica necesaria para cubrir los objetivos especificados. Gracias a
esta herramienta, ahorramos tiempo de desarrollo, ya que ofrece la posibilidad
de exportar el modelo en formato SQL directamente desde el diagrama creado.

6.2.1.2 CircuitMaker
Decidimos crear los esquemas electrónicos mediante una herramienta
informática, la cual nos permitiese obtener un esquema limpio y claro. Tras una
búsqueda en Internet, encontramos el programa CircuitMaker, el cual cubrió
con nuestras necesidades.

6.2.1.3 Oracle JDeveloper y diagramas UML

Para el diseño de los programas implementados en Java, decidimos
emplear los diagramas de clases UML. Estos diagramas debían poder crearse
informáticamente, y tras varias búsquedas, se encontró el programa de
desarrollo Oracle JDeveloper. Este programa provee de herramientas para crear
diagramas de clases, los cuales crean el código fuente paralelamente a su
construcción. También ofrece la opción inversa: generar diagramas de clases
23
desde un proyecto previamente creado. Esto nos ayudó mucho con el diseño
de los programas, ofreciéndonos una forma clara y eficaz de diseñar software
orientado a objetos.

6.2.1.4 Subclipse SVN

Este plugin para el entorno de desarrollo Eclipse, permite la integración
de Subversion dentro del mismo. Subversion da la posibilidad de centralizar el
código fuente de un programa en un servidor exterior accesible desde Internet.
Los desarrolladores pueden realizar cambios en sus respectivas copias de
trabajo para luego subirlos y aplicarlos a la del servidor, para que los demás los
reciban al actualizar su copia. Subclipse además ofrece una perspectiva de
sincronización la cual, con un solo vistazo, permite distinguir claramente los
cambios a recibir y a aplicar con respecto al código fuente del servidor. Es sin
duda una gran herramienta para conseguir terminar con todos los problemas
relacionados con la división del trabajo de programación.

6.2.1.5 PCW
Se decidió programar el PIC en lenguaje C, por las facilidades que da a la
hora de encontrar cualquier error y el tiempo de programación que ahorra con
respecto al lenguaje ensamblador. Se utilizó un compilador de C orientado a
microcontroladores llamado PCW. Este programa, además, asiste en la creación
de nuevos proyectos dando la opción de seleccionar previamente todas las
configuraciones del PIC; generando, tras esto, todo el código necesario,
ahorrando una parte de la programación. La versión utilizada fue la 4.017.

6.2.1.6 IC-Prog
Para la grabación de los microcontroladores, al tratarse de un programa
ya conocido por todos los miembros del grupo, se utilizó IC-prog. Este
programa permite realizar esta tarea rápidamente tras una sencilla
configuración.

6.2.1.7 SmartDraw
Programa utilizado para crear los diferentes diagramas de flujos y
imágenes mostradas en este documento.

6.2.1.8 Blog
Nuestro estilo de trabajo en la ejecución del proyecto se ha visto
reflejado en nuestro blog. El blog ha sido usado para ir informado de los
avances, cambios en los programas, problemas… durante el proyecto.

6.2.2Tests
A medida que se fueron acabando las diferentes partes de las cuales se
componen nuestro sistema, se fueron creado diferentes programas de testeo
para comprobar si lo hecho hasta ese momento funcionaba satisfactoriamente.

24
6.2.2.1 Tests de comunicación RS232
Para poder confirmar el correcto funcionamiento de las partes
relacionadas con la línea de serie, se creó un pequeño programa en JAVA que
estableciera una comunicación por este puerto.

Se efectuó una primera prueba de comunicación entre dos ordenadores,

y se descubrió que la instalación de la librería javax.comm no era correcta. Una
vez encontrada la forma correcta de instalar esta librería, pudimos proseguir
con más pruebas. Se verificó el funcionamiento de las diferentes clases
creadas en el programa Torno que dependían de la comunicación por el puerto
de serie, usando dos ordenadores. Este programa se pudo usar, además, para
pruebas sencillas de envío y recibo de datos entre el PIC y el PC.

6.2.2.2 Tests de funcionamiento de Hardware

Para la familiarización con el PIC y su programación en C, se realizaron
varios programas de prueba, empezando desde lo más simple hasta lo más
complicado. El primer programa de testeo que se hizo consistía en encender
los leds del PIC Trainer según la disposición de sus palancas. La creación del
programa no dio ningún problema, salvo por el hecho de tener que leer y
aprender la forma de programar en lenguaje C para microcontroladores. La
grabación del PIC, en cambio, sí que fue un obstáculo, ya que la configuración
de los fuses correcta no se conocía. Una vez averiguada la función de cada uno
de estos fuses (WDT, WRT, PWRT, BODEN,…), se pudo proseguir.

Empezaron aparecer nuevos problemas cuando se tuvo que programar la

función que nos leía la información de la tarjeta. Los problemas empezaron a
surgir una vez que se leía la información que poseía la tarjeta. El error venia al
mostrar en pantalla el dato que se iba leyendo. La solución que se dio fue el
guardar todos los datos leídos y después mostrarlos en pantalla para así no
perder ninguno.

(Falta por rellenar)

6.3 Latencia
Nos situaremos en el caso de que tenemos el máximo número de tornos
posibles (32). A velocidad de 9600 baudios:Paquete: 1 bit de inicio + 8 bits de
datos + 1 bit de paridad + 2 bits de stop= 12 bits en total. 12*104
microsegundos = 1248 microsegundos cada paquete.

Suponiendo que haya 32 tornos (el número máximo), y que sea el ultimo
torno, el ordenador tendría que preguntar antes a 31 tornos, y suponiendo que
en todos se pasen tarjetas, tendría que hacerse 31 veces la comunicación
25
completa entre PIC y PC y entre PC y servidor (aunque esta lo vamos a
despreciar porque debería de ser casi instantánea). Esta comunicación
completa se compone de 9 paquetes: 1 paquete de pregunta del ordenador, 1
paquete de respuesta, 6 paquetes para el envío de la Id de la tarjeta, luego
sería la conexión del PC con el servidor (despreciada) y después 1 paquete de
respuesta final del PC al PIC. Total: 9 paquetes. A 1248 microsegundos el
paquete, nos salen a 11232 microsegundos cada torno, y por 31 tornos a
348,192 milisegundos, es decir, 0,35 segundos. Por lo tanto, elegimos el
sistema mono-máster ya que es tiempo suficiente para dejar paso sin crear
atasco.

6.4 Protocolo RS-485

Este protocolo lo hemos creado para permitir la comunicación entre los
diferentes microcontroladores de los tornos y el PC que actúa de máster. Este
protocolo está compuesto por diferente número de paquetes dependiendo de si
la respuesta del PIC es afirmativa (que se ha pasado una tarjeta) o negativa
(que no se ha pasado ninguna tarjeta). Aun así, el inicio de la comunicación es
igual para uno u otro caso. Para que los microcontroladores puedan distinguir si
un paquete va dirigido a ellos o va dirigido al PC, lo primero que establece el
protocolo es que el primer bit de todos los paquetes será un 1 si el paquete va
dirigido al PC y un 0 si el paquete va dirigido a los PIC-s.

La comunicación comienza con un paquete de pregunta que manda el PC

al PIC de un torno, que estará dividido en las siguientes tres partes: el bit
numero 7, define que el paquete va a un PIC, los bits del 6 al 2, definen el
numero del torno, para que solo procese la petición el torno correspondiente, y
los bits 1 y 0 serán siempre 0.

BIT 7 BIT 6 BIT 5 BIT 4 BIT 3 BIT 2 BIT 1 BIT 0

0 1 1 1 1 1 0 0
Tabla 6, en este caso el PC haría la pregunta al torno numero 32.

Seguidamente, el PIC correspondiente mandara un paquete de respuesta

al PC, que estará compuesto por los siguientes datos: el bit numero 7, define
que el paquete va dirigido al PC, el bit numero 6, define la respuesta (1:
afirmativa, 0: negativa), el bit numero 5, en caso de que la respuesta sea
afirmativa, definirá si se trata de un usuario habitual (1) o esporádico (0). Los
bits del 4 al 0 serán siempre 0.

BIT 7 BIT 6 BIT 5 BIT 4 BIT 3 BIT 2 BIT 1 BIT 0

1 1 1 0 0 0 0 0
Tabla 7, en este caso el PIC responde diciendo que se ha pasado una tarjeta, y que corresponde
a un usuario habitual.

En caso de que no se haya pasado ninguna tarjeta, el PC

automáticamente seguirá preguntando al siguiente torno, pero si la respuesta
26
ha sido afirmativa, el PIC enviará 6 paquetes adicionales al PC, en los que se
contiene la ID de la tarjeta. En cada paquete se enviará un digito de dicha ID,
en los bits del 6 al 3. Los bits del 2 al 0 serán siempre 0.

BIT 7 BIT 6 BIT 5 BIT 4 BIT 3 BIT 2 BIT 1 BIT 0

1 0 0 0 1 0 0 0
Tabla 8, en este caso el primer digito de la ID será un 1.

Por último, el PC enviará un último paquete validando o no la ID que ha

recibido. Este último paquete se compondrá de lo siguiente: el bit 7 envío al
PIC, el bit 1 respuesta afirmativa (1) o negativa (0), los bits del 6 al 2 la
dirección física del torno y el último bit será 0.

BIT 7 BIT 6 BIT 5 BIT 4 BIT 3 BIT 2 BIT 1 BIT 0

0 0 0 0 0 1 1 0
Tabla 9, en este caso el PC permite al usuario del torno 1 acceder al metro.

6.5 Tecnología RFID en el transporte público

Varios Metros han implantado ya la tecnología RFID, como por ejemplo el
de Londres, con su tarjeta Oyster Card; en el Transantiago de Santiago de
Chile; en los autobuses de Transportes PESA…etc. Otros están estudiando esta
tecnología, como el Metro de Madrid y el propio Metro de Bilbao; recientemente
concluyó con éxito la prueba de utilización de la tarjeta sin contacto BARIK,
impulsada por el CTB14 ()().

6.6 Técnicas de 2 y 4 hilos RS485

El Bus de 2 hilos RS485 se compone según el bosquejo inferior. La
ventaja de la técnica de 2 hilos reside esencialmente en la capacidad
multimaster15, en donde cualquier participante puede cambiar datos en
principio con cualquier otro. El Bus de 2 hilos es básicamente apto sólo para
sistemas semidúplex16. Es decir, puesto que sólo hay a disposición una vía de
transmisión, solo un participante es capaz de enviar datos. Sólo después de
finalizar el envío, pueden responder o transmitir otros participantes.

14Consorcio de Transportes de Bizkaia.

15Un BUS multimaster permite que en cualquier momento el rol de máster cambie a
otro dispositivo conectado.

16Se denomina semidúplex a un modo de intercambio de datos entre dos terminales,

en la que la transmisión se lleva a cabo de manera alternativa. Esto es, mientras un
terminal está transmitiendo el otro solo puede recibir y viceversa.
27
 Ilustración 9, red RS-485 de doble hilo.

La técnica de 4 hilos sólo puede ser usada por aplicaciones Máster/Slave

monomaster17, o multimáster por 2 grupos, y no es posible la comunicación
entre todos y cada uno de los dispositivos, sólo entre los grupos. Las salidas de
datos de los esclavos están concebidas conjuntamente en la entrada de datos
del maestro o maestros. Esta configuración permite la transmisión y recepción
simultánea por parte del grupo de maestros y el de los esclavos().

Ilustración 10, red RS-485 de 4 hilos.

7 Bibliografía
1. Wikipedia. Metro de Bilbao. Wikipedia. [En línea] 1 de Abril de 2008. [Citado
el: 8 de Abril de 2008.]
http://es.wikipedia.org/w/index.php?title=Metro_de_Bilbao.

2. CERN. Comparison of Oracle, MySQL and Postgres DBMS. ALICE DCDB. [En
línea] 7 de Mayo de 2007.

17Un BUS monomaster contiene un solo máster, dispositivo que controla

unidireccionalmente todos los demás dispositivos, los esclavos, además de determinar
cuál de ellos enviará información.
28
http://dcdbappl1.cern.ch:8080/dcdb/archive/ttraczyk/db_compare/db_compare.
html.

3. COTRABI. Guia de la Tarjeta BARIK. Consorcio de transportes de Bizkaia. [En

línea] [Citado el: 7 de Abril de 2008.] http://www.cotrabi.com/pdfs/manual.pdf.

4. Wikipedia. Oyster card. Wikipedia. [En línea] Marzo de 2008. [Citado el: 7
de Abril de 2008.] http://es.wikipedia.org/wiki/Oyster_card.

5. Wiesemann & Theis GmbH. Sistemas de bus RS485. WuT. [En línea]
[Citado el: 7 de Abril de 2008.] http://www.wut.de/e-6wwww-11-apes-000.php.

29