GMB-Gestión de Usuarios Del Metro de Bilbao

Sistema de Gestión de Usuarios
del Metro de Bilbao
3º Grupo
Ion B. Padilla
Liher Granado
Daniel García
Igor Ordóñez
Endika Montejo
2 Gestión de usuarios del Metro de Bilbao
Índice
1 ABSTRACT............................................................................................................................................ 4
2 EL PROBLEMA...................................................................................................................................... 4
3 OBJETIVOS DEL PROYECTO .................................................................................................................. 4

3.1 MÍNIMOS ....................................................................................................................................... 5
3.2 LÍMITES .......................................................................................................................................... 5
4 ANÁLISIS.............................................................................................................................................. 5
4.1 ANÁLISIS CONCEPTUAL ....................................................................................................................... 5

4.1.1 Metro de Bilbao ....................................................................................................................... 5
4.1.2 Gestión .................................................................................................................................... 6
4.1.3 Usuarios .................................................................................................................................. 6
4.1.4 Hardware ................................................................................................................................ 7
4.1.5 Software.................................................................................................................................. 8
4.1.6 Esquema conceptual ................................................................................................................ 9
4.2 ANÁLISIS TÉCNICO ........................................................................................................................... 10
4.2.1 Gestión .................................................................................................................................. 10
4.2.2 Hardware .............................................................................................................................. 10
4.2.3 Software................................................................................................................................ 15
4.2.4 Esquema general para 2 paradas ........................................................................................... 15
5 DESARROLLO ..................................................................................................................................... 16
5.1 MODELIZACIÓN.............................................................................................................................. 16
5.1.1 Base de Datos ........................................................................................................................ 16
5.1.2 Software................................................................................................................................ 16
5.1.3 Hardware .............................................................................................................................. 17
5.2 IMPLEMENTACIÓN .......................................................................................................................... 18
5.2.1 Base de Datos ........................................................................................................................ 18
5.2.2 Software................................................................................................................................ 18
5.2.3 Hardware .............................................................................................................................. 19
5.3 ACOMETIDA DE MEJORAS ................................................................................................................. 19
5.3.1 Base de datos ........................................................................................................................ 19
5.3.2 Software................................................................................................................................ 19
6 RESULTADOS ..................................................................................................................................... 20
6.1 CAPACIDADES ................................................................................................................................ 20
6.2 LIMITACIONES................................................................................................................................ 21
6.2.1 Lector de tarjetas................................................................................................................... 21
6.2.2 Latencia en la comunicación PIC-PC ....................................................................................... 21
6.3 CONCLUSIONES .............................................................................................................................. 21
7 LÍNEAS DE EXPANSIÓN ...................................................................................................................... 22
7.1 PROGRAMA DE GESTIÓN ................................................................................................................... 22

7.2 TERMINAL TÁCTIL ........................................................................................................................... 22

8 ANEXOS ............................................................................................................................................. 23
8.1 OBJETIVOS DE APRENDIZAJE .............................................................................................................. 23
8.1.1 Tecnología de computadores ................................................................................................. 23
8.1.2 Bases de datos....................................................................................................................... 23
8.1.3 Tecnología orientada a objeto................................................................................................ 23
8.2 PLANIFICACIÓN .............................................................................................................................. 24
8.3 LATENCIA ..................................................................................................................................... 25
8.3.1 Primera estimación ................................................................................................................ 25
8.3.2 Segunda estimación ............................................................................................................... 25
8.4 TÉCNICAS DE 2 Y 4 HILOS RS-485....................................................................................................... 26
8.5 DISEÑO DE LA BASE DE DATOS ............................................................................................................ 28
8.6 DISEÑO DEL SOFTWARE .................................................................................................................... 29
8.6.1 Terminal ................................................................................................................................ 29
8.6.2 Tornos ................................................................................................................................... 30
8.6.3 Tornos PIC ............................................................................................................................. 31
8.7 PROTOCOLO RS-485 ...................................................................................................................... 32
8.8 PROBLEMAS .................................................................................................................................. 33
8.8.1 Creación de billetes ................................................................................................................ 33
8.8.2 Comunicación RS232.............................................................................................................. 33
8.8.3 Programación del PIC............................................................................................................. 34
8.8.4 Lectura de bandas magnéticas ............................................................................................... 34
8.8.5 Conflicto entre interrupciones ................................................................................................ 34
8.8.6 Sincronización de la comunicación PC-PIC .............................................................................. 34
8.8.7 Implementación RS-485 en PIC16F873 ................................................................................... 35
8.9 HERRAMIENTAS ............................................................................................................................. 35
8.9.1 MySQL Workbench ................................................................................................................ 35
8.9.2 CircuitMaker.......................................................................................................................... 35
8.9.3 Oracle JDeveloper y diagramas UML ...................................................................................... 35
8.9.4 Eclipse ................................................................................................................................... 36
8.9.5 Subclipse SVN ........................................................................................................................ 36
8.9.6 PCW ...................................................................................................................................... 36
8.9.7 IC-Prog .................................................................................................................................. 36
8.9.8 SmartDraw ............................................................................................................................ 36
8.9.9 Blog ....................................................................................................................................... 36
8.10 TECNOLOGÍA RFID EN EL TRANSPORTE PÚBLICO ..................................................................................... 37
9 BIBLIOGRAFÍA.................................................................................................................................... 38
1 Abstract
As one of the main problems nowadays is the increase and the inconvenience of the use of
private transports, the use of public transports is being fomented. This is one of the reasons why
our project consists on the management of the users of Bilbao’s underground.
To reach this goal, we have divided the project into two parts.
The first one will establish a connection between a program in JAVA language and the
MySQL database. This part’s objective will be the one of recharging cards to habitual users and
expend tickets to sporadic ones.
The second part will connect the access devices to the database hosted by a central PC via
RS-485 BUS and a JAVA program; with this last program acting as a gatekeeper, which will allow or
not the petitions of entry of users into the underground and register their accesses.
In conclusion, an application to manage the access of users of Bilbao’s underground which

will give us the possibility to make it quicker, more efficient and easier to understand for the users
while we offer a tool to manage and monitor the entire underground system.
2 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.
3 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 MGEP 1 obtengamos
ciertas cualificaciones y conocimientos. A esta metodología se la denomina como aprendizaje
basado en problemas o PBL (Anexos: Objetivos de aprendizaje).
1
Mondragon Goi Eskola Politeknikoa, Escuela Politécnica Superior de Mondragón.
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 (Anexos: Planificación).
3.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.
3.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.
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.
4 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.
4.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.
4.1.1 Metro 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.
Ilustración 1, Red actual de Metro de Bilbao
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.
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 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 (1).
4.1.2 Gestió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.
4.1.3 Usuarios
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.
2
Radio Frequency Identification, sistema de identificación por radiofrecuencia.
4.1.4 Hardware
En este apartado se analizarán los soportes físicos que serían necesarios para el sistema.
4.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.
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.
4.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.
4.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.
4.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.
4.1.5 Software
Definiremos conceptualmente de qué partes de software precisa el sistema hasta ahora
definido.
4.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 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.
4.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.
4.1.6 Esquema 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.

4.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.
4.2.1 Gestió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.
4.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 Oracle
Open Source, sin ningún coste. 8,800 USD versión empresarial.
Sencillez en la creación de las bases de datos. Alta dificultad en la creación de las bases de datos.
Se recomiendan 128MB RAM y 1GB de disco duro 7 veces más de espacio en disco duro y 16 veces
para servidores. más de RAM que MySQL aproximadamente.
Menor seguridad que Oracle. Alta seguridad.
Buena velocidad. Mayor velocidad que MySQL.
Para las características avanzadas, hay que usar el Implementa prácticamente todas las características
motor InnoDB. 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 (2).
4.2.2 Hardware
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á
3
Structured Query Language.
4
Data Definition Language.
5
Data Modification Language.
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.
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.
4.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 hecho de ponerlas cerca Son fáciles de piratear o copiar, sin que se entere el
del lector es suficiente. Por lo tanto no se usuario.
desgastan.
Existen tarjetas de lectura y escritura, y además no

Alto coste de los lectores. Unos 200 € las unidades
necesitan de alimentación, les es inducida por el
comerciales.
lector en el momento 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.
6
Sistema de Gestión de Bases de Datos.
TARJETAS MAGNÉTICAS
Desgaste producido al pasarla por los

Bajo coste.
lectores.
Tecnología muy conocida y utilizada. Son fáciles de piratear o copiar.
Lentitud en los accesos.
Tabla 3, ventajas y desventajas de las tarjetas con banda magnética.
TARJETAS INTELIGENTES
Procesador criptográfico seguro, sistema de

archivos seguro, características legibles por Alto coste de lectores y tarjetas.
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.
4.2.2.2 BUS
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
7
Identification Number, número de identificación.
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 aceptable.
Cumple con todas las necesidades del sistema, y es por esto que lo hemos seleccionado.
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 RS-485).
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.
8
Operación de consulta constante hacia, generalmente, uno o varios dispositivos de hardware para crear
una actividad sincrónica.
Monomaster Multimaster
Mayor velocidad. Menor velocidad.
Rendimiento FULL Los dispositivos no tienen que Se debe pedir permiso al árbitro y
enviar ninguna petición a ningún además, establecer la
árbitro antes de la comunicación. comunicación.
Menor velocidad. Mayor velocidad.
Rendimiento IDLE El sistema puede que pierda el Los dispositivos afectados piden
tiempo preguntando a los permiso al árbitro y sólo ellos
dispositivos que no estén en uso. establecen comunicación.
Tabla 5, rendimiento de las disposiciones multimaster y monomaster del BUS Tornos<->Servidor.
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 UART9 integrada, ya sea por software o hardware, para la
comunicación por línea RS.
4.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.
4.2.2.4 PROTOCOLO
Al elegir el sistema monomaster, para facilitar la comunicación entre los diferentes
microcontroladores de los tornos y el PC, se debe diseñar un protocolo específico que cumplirán
todos los paquetes que viajen por el bus. Se debe definir 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 evitará conflictos en el BUS, como el que la
transmisión por parte de un PIC pueda ser malinterpretada por otro PIC.
9
Universal Asynchronous Receiver Transmitter.
10
Programable Intelligent Computer, Computador Inteligente Programable.
4.2.3 Software
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 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.
4.2.4 Esquema general para 2 paradas
Ilustración 3, esquema general de conexiones para 2 estaciones.
11
Graphical User Interface, Interfaz Gráfica de Usuario.
12
Abstract Window Toolkit.
5 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.
5.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.
5.1.1 Base de Datos

La base de datos fue diseñada en primer lugar, usando diagramas de entidad-relación y
relacionales. Las tablas que contiene son las básicas para lograr un registro de los accesos al Metro
que ofrezca información de interés fundamental para la gestión del mismo. El diagrama relacional
de la BD puede encontrarse en (Anexos: Diseño de la base de datos).
Se utilizó MySQL Workbench para crear este diagrama (Anexos: MySQL Workbench).
5.1.2 Software
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 (Anexos: Terminal).
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 (Anexos: Tornos).
Para la realización de estos dos últimos diagramas de clases, se utilizó Oracle JDeveloper,
el cual facilitó enormemente el diseño de estos programas (Anexos: Oracle JDeveloper y
diagramas UML).
En el caso del programa a grabar en los microcontroladores de los tornos, fue suficiente
con crear diagramas de secuencia que definieran el proceso por completo. El programa se dividirá
en dos partes, ComunicacionPC y LecturaTarjeta, siendo este último el programa principal (Anexos:
Tornos PIC).
5.1.3 Hardware
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 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 convertidor 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 4, diseño de un módulo para un torno con lector de tarjetas.
Seguidamente pasamos al diseño del protocolo del bus RS-485 que deberían cumplir las
comunicaciones entre los PIC y el PC controlador de los mismos (Anexos: Protocolo RS-485).
13
Transistor-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).
5.2 Implementación
Tras la modelización de cada parte, procedimos a su implementación. En esta sección se
irá describiendo este proceso.
5.2.1 Base 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.
Una vez finalizado el proceso de creación de la base de datos, se crearon los usuarios que
usarán los diferentes dispositivos para conectarse a ella. En nuestro sistema, tanto la terminal
como el PC controlador de los tornos tendrán un usuario individual para conectarse a la base de
datos. A estos usuarios se les otorgaran los privilegios indispensables para que puedan realizar las
operaciones necesarias.
La base de datos fue sufriendo cambios a medida que se desarrollaron los programas
‘Terminal’ y ‘Tornos’, ya que fueron encontrados errores en el diseño y mejoras para las tablas ya
existentes.
5.2.2 Software
La segunda parte que pasamos a implementar fueron los programas ‘Terminal’, ‘Tornos’ y
el programa a grabar en los microcontroladores. Para los dos primeros, y valiéndonos de los
diagramas de clases, dividimos el trabajo en clases o grupos de clases por cada miembro del
grupo. Para el segundo, dividimos el trabajo en subrutinas y nos ayudamos del diseño establecido
en los diagramas de secuencia. Paralelamente al desarrollo se testeó cada parte de los programas:
conexión con la base de datos, conexión vía puerto de serie, lectura de tarjetas, etc.
Surgieron múltiples problemas al implementar estas tres partes de software. Primero, con
el proceso de creación de nuevos billetes; después, con la configuración de la librería que permite
la comunicación a través del puerto de serie. Además, aparecieron también problemas en el
programa a grabar en los microcontroladores y, por último, con la sincronización entre el
programa controlador de tornos ‘Tornos’ y ellos mismos (Anexos: Problemas).
Los programas ‘Terminal’ y ‘Tornos’, fueron implementados usando Eclipse como

plataforma de desarrollo. Gracias a Subclipse, pudimos desarrollar de forma cooperativa y
dinámica todas las partes de los mismos. Por otro lado, el programa a grabar en los
microcontroladores fue grabado con el programa IC-Prog utilizando una placa MicroPIC Trainer.
Usamos la última versión del programa PCW de CCS para crear el programa de los
microcontroladores, el cual fue escrito en lenguaje C (Anexos: Subclipse SVN, IC-Prog, PCW).
En general, puede afirmarse que esta sección resultó ser la más problemática y
voluminosa; pero gracias al diseño preliminar, claro y conciso, el desarrollo pudo ser lo
suficientemente rápido como para dejar tiempo extra que dedicar a los problemas que surgieron.
5.2.3 Hardware
Comenzamos a implementar esta parte justo después de acabar el diseño conceptual y
disponer de todos los materiales necesarios. Tras un sencillo montaje de una placa electrónica
provista de un lector de bandas magnéticas y puerto de serie RS-232, pudimos empezar a realizar
pruebas con ella.
La creación de esta placa no supuso ningún problema, ya que todos los componentes
estaban bien documentados y se nos proveyó de la información necesaria sobre el lector de
tarjetas Dorlet, el único componente totalmente nuevo y desconocido.
5.3 Acometida de mejoras

Tras la finalización de la etapa de desarrollo del proyecto en base a los objetivos
preestablecidos, se tomó la decisión de dar comienzo al desarrollo e implementación de
funcionalidades que mejorarían el sistema.
5.3.1 Base de datos

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. 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.
Se programó un trigger14 para hacer posible y automática la creación de esta tabla

histórica. De esta forma, y transparentemente, la tabla es rellenada instantáneamente después del
borrado de cada registro de la tabla Acceso.
Además, para facilitar la obtención de datos acerca de la cantidad y media de accesos al

Metro, fueron creadas cuatro vistas las cuales contienen los siguientes datos: cantidad de accesos
por fecha, hora y estación; la media de accesos por hora y por estación; la cantidad de accesos por
hora y por fecha y, por último, la media de accesos por hora.
5.3.2 Software
Se revisó el diseño de los programas ‘Terminal’ y ‘Tornos’, reorganizando la arquitectura
del mismo en una organización por capas. De esta forma se consigue que cada capa sea
independiente de las demás y una mejor distribución del programa, dando la posibilidad de dividir
14
Un trigger de una base de datos es un código procedimental el cual se ejecuta automáticamente en
respuesta a ciertos eventos surgidos en cierta tabla de una base de datos.
el trabajo más efectivamente, ya que cada grupo puede abstraerse completamente con sólo
conocer las API-s 15 (interfaces) de las capas externas necesarias.
Además, fue implementada una nueva forma de inicialización en ‘Terminal’ y ‘Tornos’

mediante el uso de ficheros. Este nuevo modo difería del que primeramente se usó en el cual la
información no se guardaba tras cerrar los programas. De esta forma, las configuraciones
necesarias son introducidas únicamente la primera vez que se ejecutan. Posteriormente, es
posible cambiarlas manualmente editando estos ficheros.
También se buscó la forma de proveer a las ventanas del programa ‘Terminal’ de imágenes
de fondo. Fueron encontrados varios métodos creados por usuarios anónimos en Internet que se
añadieron al mismo.
6 Resultados
En la siguiente sección hablaremos sobre los resultados obtenidos. Trataremos de explicar
de lo que es capaz el sistema desarrollado y expondremos también las limitaciones del mismo.
6.1 Capacidades
El sistema creado es capaz de controlar hasta un máximo de 32 tornos, registrando
automáticamente todos los accesos válidos producidos en los mismos en una base de datos
ubicada dentro de una red de área local. Además, nuestro sistema es válido para la expensa de
billetes de acceso y la recarga de tarjetas monedero de usuarios habituales que estén dados de
alta como tales. Esto se consigue gracias a una interfaz gráfica de usuario intuitiva, sencilla y
eficaz.
El usuario, al introducir su pase en el torno, no percibe ningún retraso o lentitud en el

sistema, ya sea 1 o 32 los tornos conectados al BUS de datos. Además, recibe una confirmación
visual y sonora de la validación del pase.
Por la parte de la instalación del sistema, este sólo precisa de los datos almacenados en
una base de datos central, imprescindible para el funcionamiento del mismo. Las configuraciones
de conexión a esta base de datos son introducidas en la primera inicialización de los dos
programas que se ofrecen: ‘Terminal’ y ‘Tornos’.
Por otro lado, el mantenimiento se centra en la base de datos, el cual debe realizarse
manualmente. En el caso en el que alguno de estos tornos se averiase o apagase, todo seguiría
funcionando de forma completamente normal.
15
Una API (del inglés Application Programming Interface - Interfaz de Programación de Aplicaciones) es el
conjunto de funciones y procedimientos (o métodos si se refiere a programación orientada a objetos) que
ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción.
6.2 Limitaciones
En el siguiente apartado se resumirán las limitaciones del sistema de gestión desarrollado.
6.2.1 Lector de tarjetas

El lector de bandas magnéticas, al tratarse de un modelo basado en el paso de tarjeta
manual, puede dar pie a fallos. Por ejemplo, si se pasase la tarjeta en el sentido contrario de
lectura predeterminado, o a una velocidad no adecuada.
La solución más correcta para este problema sería utilizar un lector automático (utilizado
habitualmente en los metros) en el que se introduzca la tarjeta y este la deslice a través del
cabezal lector. De esta manera, el sistema evitaría los errores y la tarjeta siempre sería pasada
correctamente.
6.2.2 Latencia en la comunicación PIC-PC

Debido a la diferencia de velocidades de procesamiento entre los PIC y el PC, este último
se ve obligado a esperar ciertos milisegundos antes de recoger el paquete de información
esperado del dispositivo con el que se comunique.
En consecuencia, la latencia se ve afectada por esta diferencia, reducible mediante el

incremento de la frecuencia del oscilador empleado en los dispositivos, los cuales son de 4 MHz,
suponiendo una gran diferencia de velocidad con respecto al PC.
Por lo tanto, si se desease reducir esta latencia, se deberían modificar los parámetros
anteriormente citados (Anexos: Latencia).
6.3 Conclusiones
A partir del resultado obtenido, podemos extraer varias conclusiones acerca de su validez
y usabilidad.
La base de datos contiene todos los datos para el funcionamiento del sistema, siendo
posible, gracias a su diseño, la obtención y manipulación de datos de gran interés para la
monitorización del Metro y de los servicios que este ofrece.
En la parte referente al sistema de tornos de acceso, la elección de implementar un

sistema basado en la técnica polling ha resultado satisfactoria, ya que el sistema es útil y responde
en un tiempo aceptable hasta en el más extremo de los casos.
Por lo que respecta a los programas ‘Terminal’ y ‘Tornos’, gracias también a su diseño, es
posible la realización de grandes cambios sin que suponga un gran esfuerzo. Los dos ofrecen una
configuración sencilla y una interfaz intuitiva, la cual posibilita la fácil comprensión del uso de los
mismos.
Por todo lo anterior, puede afirmarse que el sistema desarrollado es totalmente válido
para la gestión básica de un metro.
7 Líneas de expansión
En esta sección se irán describiendo diferentes funcionalidades extras que se podrían
implementar en el sistema.
7.1 Programa de gestión

Este programa le permitiría 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. Podría ofrecernos, además, 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.
7.2 Terminal táctil

Se nos ofreció la oportunidad de implementar una terminal con pantalla táctil. El usuario,
gracias a este dispositivo, podría disfrutar de todas las ventajas ofrecidas por el programa de la
terminal, con el aliciente de poder elegir entre los diferentes menús tocando la pantalla.
La implementación de la pantalla táctil nos presentaba una serie de problemas, los cuales
implicaban una serie de cambios. Se debían modificar las librerías usadas en el programa de la
terminal. Se tenía que lograr compatibilidad con JDK 1.3, ya que actualmente la versión usada es la
JDK 1.6, la cual no es compatible con este sistema. Tampoco goza de compatibilidad con las
librerías Swing, obligando de esta forma a adaptar el programa a la librería AWT. Aun así, se trata
de una mejora muy atractiva visualmente, por lo que el esfuerzo podría merecer la pena.
8 Anexos
8.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.
8.1.1 Tecnologí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.
8.1.2 Bases de datos

 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.
8.1.3 Tecnología orientada a objeto

 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.
8.2 Planificación
Ilustración 11, diagrama de Gantt donde se muestra la implementación llevada a cabo para la ejecución del proyecto.
En el diagrama de Gantt mostrado en la página anterior se puede seguir la sucesión de

actividades y sus respectivas duraciones, de las cuales se compuso el desarrollo de este proyecto.
En base a este diagrama establecimos el ritmo necesario para intentar cumplir los plazos
establecidos lo mejor posible.
En las etapas de diseño todos los miembros del grupo debían participar, ya que se trata de
una fase clave en todas las partes del sistema, imprescindible para conocer y saber cómo se
construirán. En cambio, para el desarrollo, fue fundamental la división de tareas entre los
miembros.
8.3 Latencia
La comunicación entre los dispositivos de acceso y el PC requieren de un tiempo para
completarse llamado latencia. Se trata de un factor muy importante, ya que una latencia muy alta
supondría un mayor retraso en la validación de los pases, pudiendo resultar en un sistema lento
para el usuario. Se realizaron dos estimaciones: la primera durante el análisis técnico y la segunda
tras la finalización del desarrollo del sistema.
8.3.1 Primera estimación

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 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, 1 paquete de permiso de envío de ID, 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: 10 paquetes.
A 1248 microsegundos el paquete, nos salen a 12680 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.
8.3.2 Segunda estimación

Tras el desarrollo y la implementación se pudo comprobar cómo la primera estimación de
la latencia era errónea. El PC debe esperar a que el PIC compruebe los paquetes que a éste se le
envían y realice las tareas necesarias, teniendo que esperar ciertos milisegundos: 8 milisegundos
para recibir una respuesta, 15 milisegundos para enviar el paquete de permiso de envío de ID, 15
milisegundos para recibir los 6 paquetes de ID. Todo esto se debe a la diferencia en la velocidad de
procesamiento entre el PC y los PIC.
Añadiendo este factor al primer cálculo, se estima que la comunicación entre el PC y un

PIC, en caso de que este contenga tarjeta y por lo tanto se llegue a enviar todos los paquetes
especificados en el protocolo, lleva un tiempo de 50.48 milisegundos. Por lo tanto, el tiempo
máximo que tendría que esperar un usuario en un sistema de 32 tornos donde todos contienen la
ID leída de una tarjeta, en el caso de que el usuario sea el del último torno en establecer la
comunicación con el PC, es de 1.61536 segundos aproximadamente.
Dada la complejidad con la que se daría este caso, y teniendo en cuenta el tiempo de
espera que le supondría al usuario, consideramos que el sistema sigue respondiendo en un tiempo
aceptable.
8.4 Técnicas de 2 y 4 hilos RS-485

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 multimaster16, 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úplex17. 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.
Ilustración 5, red RS-485 de doble hilo.
La técnica de 4 hilos sólo puede ser usada por aplicaciones Máster/Slave monomaster18, 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
16
Un BUS multimaster permite que en cualquier momento el rol de máster cambie a otro dispositivo
conectado.
17
Se 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.
18
Un 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.
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 (5).
Ilustración 6, red RS-485 de 4 hilos.

8.5 Diseño de la base de datos
Ilustración 7, diagrama relacional de la base de datos.

8.6 Diseño del software

8.6.1 Terminal
Ilustración 8, diagrama de clases UML para el programa ‘Terminales’.

8.6.2 Tornos
Ilustración 9, diagrama de clases UML para el programa ‘GestionTornos’.

8.6.3 Tornos PIC
Ilustración 10, diagramas de secuencia del programa de los microcontroladores. Se muestran programa principal que se
encargará de leer tarjetas y la rutina de la interrupción usada; información entrante en puerto de serie.
8.7 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 0 0 0 0 1 0 0
Tabla 6, en este caso el PC haría la pregunta al torno numero 1.
Seguidamente, el PIC correspondiente mandará un paquete de respuesta al PC, que estará

compuesto de la siguiente manera: el bit numero 7, define que el paquete va dirigido al PC, el bit
numero 6, define la respuesta (1: afirmativa, 0: negativa).
1 1 0 0 0 0 0 0
Tabla 7, en este caso el PIC responde diciendo que se ha pasado una tarjeta.
En caso de que no se haya pasado ninguna tarjeta, el PC automáticamente seguirá

preguntando al siguiente torno. En cambio, si la respuesta ha sido afirmativa, el PC enviará un
paquete de pedido de ID para que el PIC le envíe la correspondiente ID, que será igual que el
paquete de pregunta exceptuando que en el bit numero 0 habrá un “0” y en el numero 1 un “1”.
Este byte por lo tanto avisa al PIC de que el PC está preparado para recibir la ID.
0 0 0 0 0 1 1 0
Tabla 8, en este caso el PC haría la pregunta al torno numero 1 y pedirá la ID de la tarjeta.
El PIC, al recibir este último paquete, enviará 6 paquetes adicionales al PC, en los que se
contiene la ID de la tarjeta y un bit que indica si se trata de un usuario habitual o esporádico
(tarjeta o ticket). En cada paquete se enviará un digito de dicha ID, en los bits del 6 al 3. Los bits
del 2 al 1 serán siempre 0 y el 0 definirá si el usuario es esporádico o habitual.
1 0 0 0 0 1 0 1
Tabla 9, 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.
0 0 0 0 0 1 1 0
Tabla 10, en este caso el PC permite al usuario del torno 1 acceder al metro.
8.8 Problemas
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.
8.8.1 Creación de billetes

El programa ‘Terminal’, para la creación de billetes para los usuarios esporádicos, debía
crear un nuevo billete en la respectiva tabla de la base de datos. Este debe tener 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 que le
ha sido asignado a 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.
8.8.2 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.
8.8.3 Programación del PIC

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.
8.8.4 Lectura de bandas magnéticas

Empezaron a aparecer nuevos problemas cuando se tuvo que programar la función que
lee la información de la tarjeta. Para verificar que leíamos correctamente, decidimos enviar al PC
cada bit leído en el mismo momento que se leía. Debido a esto, se perdían bits de la tarjeta
mientras se enviaba cada bit leído al PC. La solución consistió en esperar a leer el contenido
completo de la tarjeta para enviar lo leído al PC.
8.8.5 Conflicto entre interrupciones

Tras una primera simulación de comunicación completa entre el PIC y el PC, se descubrió
que la mayoría de las veces que un usuario pasa la tarjeta, el funcionamiento era incorrecto. Esto
se debía a que el PIC usado no permite que salten interrupciones cuando se está dentro de una de
ellas, y no ofrece bits de control de prioridades entre interrupciones. Ya que tanto la lectura de la
tarjeta como la comunicación estaban implementadas mediante dos interrupciones individuales,
se tuvo que eliminar una de ellas, implementándola en el programa principal.
8.8.6 Sincronización de la comunicación PC-PIC

Al comenzar las pruebas de funcionamiento del sistema en su totalidad, aparecieron
multitud de fallos en un principio totalmente desconcertantes. Todo indicaba a fallos de
comunicación entre los PIC y el PC. Se analizó el problema y se hicieron diferentes pruebas hasta
con dar con la solución. Esta consistía en hacer que el PC ‘cortase’ la comunicación con un torno
que no respondiese en un tiempo determinado, y además, hacer que éste espere varios
milisegundos antes del envío y la recepción de los paquetes. Estos milisegundos varían según el
paquete en cuestión y el estado de la comunicación. Mediante pruebas, se halló el ajuste óptimo
para el caso más extremo (un solo torno en el BUS).
Todo esto se debe a la diferencia de velocidad de procesamiento del PC y los PIC, la cual es
mucho menor en los últimos. Además, durante el paso de cualquier tarjeta o ticket por un torno,
este deshabilita la comunicación con el PC, retrasando al sistema si este no saltase a comunicarse
con el siguiente torno. Gracias a esto, además, se cubre el caso en el que algún torno se
estropease, ya que el sistema no se bloquearía.
8.8.7 Implementación RS-485 en PIC16F873

Al adaptar el programa de los tornos físicos, previamente creado para RS-232, a RS-485,
surgió un nuevo problema. Se debía implementar un control basado en un pin del PIC, el cual
habilita el envío y deshabilita el recibo, o viceversa, dependiendo de su estado lógico. Por lo tanto,
este debía modificarse para poder establecer una comunicación correcta. El problema radica en la
velocidad con la que el valor lógico del pin de control se estabiliza desde el momento en el que se
ejecuta la operación; y también en el tiempo que pasa desde que se ejecuta la operación de envío
del último bit de un byte hasta que realmente ha salido. Cuando tras una operación de envío se
deshabilitaba el envío, el último byte enviado llegaba corrupto al PC (ocurriendo lo mismo para
una operación de recibo, pero justo al contrario: el byte corrupto sería el primero recibido) Esto se
solucionó insertando 2 milisegundos de retraso entre estas dos operaciones.
8.9 Herramientas
Se describirán a continuación las herramientas usadas a lo largo del proyecto, las cuales
ayudaron en el desarrollo del mismo.
8.9.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.
8.9.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.
8.9.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 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.
8.9.4 Eclipse
El entorno de desarrollo escogido fue Eclipse, el cual ofrece características las cuales
facilitan enormemente la programación en Java. Existen además infinidad de plugins que
extienden y añaden funcionalidades a este IDE19.
8.9.5 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.
8.9.6 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.
8.9.7 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.
8.9.8 SmartDraw
Programa utilizado para crear los diferentes diagramas de flujo e imágenes mostradas en
este documento. Gracias a él es posible realizar esquemas técnicos de todo tipo rápidamente.
8.9.9 Blog
Nuestro trabajo a lo largo de la ejecución del proyecto se ha visto reflejado en nuestro
blog (http://proiektutaldea.wordpress.com). Este blog ha sido usado para ir informando sobre los
avances, cambios en los programas, problemas y demás información. En definitiva, una bitácora
que recoge los pasos que fuimos dando.
19
Del inglés Integrated Development Environment: Entorno de Desarrollo Integrado, programa compuesto
por un conjunto de herramientas para la programación.
8.10 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 CTB20 (3) (4).
20
Consorcio de Transportes de Bizkaia.
9 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. 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.

GMB-Gestión de Usuarios Del Metro de Bilbao

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GMB-Gestión de Usuarios Del Metro de Bilbao

Uploaded by

Copyright:

Available Formats

Sistema de Gestión de Usuarios

del Metro de Bilbao

3 OBJETIVOS DEL PROYECTO .................................................................................................................. 4

4.1 ANÁLISIS CONCEPTUAL ....................................................................................................................... 5

7.1 PROGRAMA DE GESTIÓN ................................................................................................................... 22

7.2 TERMINAL TÁCTIL ........................................................................................................................... 22

In conclusion, an application to manage the access of users of Bilbao’s underground which

3 Objetivos del proyecto

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

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

Por consiguiente, todo lo que se escape a estos tres conceptos y a la implementación de

4.1 Análisis conceptual

4.1.1 Metro de Bilbao

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

Ilustración 1, Red actual de Metro de Bilbao

4.1.4.2 Obtención de pases

4.1.4.3 Validación de pases

4.1.5.2 Interfaces de usuario

4.1.6 Esquema conceptual

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

4.2 Análisis técnico

4.2.1.1 Comparación entre MySQL y Oracle

Open Source, sin ningún coste. 8,800 USD versión empresarial.

Menor seguridad que Oracle. Alta seguridad.

Buena velocidad. Mayor velocidad que MySQL.

Tabla 1, Comparación entre MySQL y Oracle.

Se puede plantear un esquema en el que los dispositivos se comuniquen con la base de

Muy duraderas ya que no hay que pasarlas por

Existen tarjetas de lectura y escritura, y además no

Lecturas más rápidas y más precisas que en otro

Dinamizaría mucho más las colas, reduciendo el

Bajo coste de las tarjetas. En fecha de 2004, las

Tabla 2, ventajas y desventajas de la tecnología RFID.

Desgaste producido al pasarla por los

Tecnología muy conocida y utilizada. Son fáciles de piratear o copiar.

Lentitud en los accesos.

Tabla 3, ventajas y desventajas de las tarjetas con banda magnética.

Procesador criptográfico seguro, sistema de

Es capaz de proveer servicios de seguridad.

Tabla 4, ventajas y desventajas de las tarjetas inteligentes.

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

información. Cada terminal de acceso dispondrá de un PIC, que se encargará de la comunicación y

Otra de las características del BUS a analizar es el carácter monomaster o multimaster.

Mayor velocidad. Menor velocidad.

Menor velocidad. Mayor velocidad.

Tabla 5, rendimiento de las disposiciones multimaster y monomaster del BUS Tornos<->Servidor.

Ya que lo que queremos potenciar es la respuesta en horas punta del Metro,

4.2.4 Esquema general para 2 paradas

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

5.1.1 Base de Datos

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

En el programa dedicado al puente de comunicación entre la base de datos y los tornos,

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

5.2.1 Base de Datos

Los programas ‘Terminal’ y ‘Tornos’, fueron implementados usando Eclipse como

5.3 Acometida de mejoras

5.3.1 Base de datos

Se programó un trigger14 para hacer posible y automática la creación de esta tabla

Además, para facilitar la obtención de datos acerca de la cantidad y media de accesos al

Además, fue implementada una nueva forma de inicialización en ‘Terminal’ y ‘Tornos’

El usuario, al introducir su pase en el torno, no percibe ningún retraso o lentitud en el

6.2.1 Lector de tarjetas

6.2.2 Latencia en la comunicación PIC-PC