DEPARTAMENTO DE INGENIERÍA ELECTRÓNICA FACULTAD DE INGENIERÍA
UNIVERSIDAD DE LOS ANDES
Diseño y prototipo de un sistema electrónico de préstamo de bicicletas
auto-servicio Proyecto de Grado
Juan Sebastián Castellanos, David Monroy
Asesor: Antonio García Rozo Co-asesor: Mauricio Guerrero Hurtado
Junio de 2010
Resumen: Dentro del marco del Proyecto de Grado de Ingeniería Electrónica, el presente documento describe el diseño e implementación de un prototipo del “Sistema Electrónico de Préstamo de Bicicletas auto-servicio”. El proyecto busca desarrollar un sistema electrónico de préstamo de bicicletas que pueda usarse en conjunto con el sector privado para incentivar el uso de la bicicleta como medio de transporte alternativo. Asimismo busca contribuir a la solución de los problemas de movilidad que se registran actualmente en la ciudad de Bogotá por diversos factores externos. Por este motivo, se utiliza un enfoque innovador que ataca el problema desde las necesidades locales sin buscar adaptar sistemas ya existentes en otros países que puedan no satisfacer todas las necesidades de la población local con un sistema funcional, escalable y ampliable mediante su conexión en red. El proyecto comprende la definición de operación del sistema, su diseño electrónico top-down, la evaluación y selección de tecnologías, la implementación de un prototipo y las pruebas operacionales y funcionales del mismo.
2
Contenidos
I. Introducción....................................................................................................................................... 4
II. Antecedentes ..................................................................................................................................... 5
A. Vélib’ (Paris, France) ....................................................................................................................... 5
B. Funcionalidad posible ..................................................................................................................... 6
III. Descripción del Clilente y Especificaciones Definidas ...................................................................... 8
IV. Principios de Funcionamiento ........................................................................................................ 9
V. Diseño del Sistema ............................................................................................................................. 9
A. Componentes del sistema .............................................................................................................. 9
B. Funcionamiento del sistema ......................................................................................................... 10
C. Arquitectura de Sistema Seleccionada .......................................................................................... 13
VI. Implementación ........................................................................................................................... 14
A. Ambiente de desarrollo ................................................................................................................ 14
B. Fases de la implementación ......................................................................................................... 15
C. Descripción de Algoritmos Implementados................................................................................... 16
1) Kiosco ....................................................................................................................................... 17
2) Parqueadero ............................................................................................................................ 18
3) Servidor .................................................................................................................................... 20
A. Desarrollo del prototipo ............................................................................................................... 26
1) Regulación ................................................................................................................................ 26
2) Microcontrolador ATMEGA16L: Kiosco y Parqueadero.............................................................. 27
3) Parqueadero ............................................................................................................................ 28
4) Kiosco ....................................................................................................................................... 29
B. Simulaciones y Pruebas ................................................................................................................ 34
VII. Análisis de Robustez ..................................................................................................................... 35
A. Comunicación GPRS ..................................................................................................................... 35
3
B. Bloques y presencia de bicicletas .................................................................................................. 36
C. Cortes eléctricos y otros fallos en el servidor ................................................................................ 37
D. Fallos en estaciones Kiosco y Parqueaderos .................................................................................. 37
VIII. Conclusiones y Perspectivas ......................................................................................................... 38
IX. Bibliografía ................................................................................................................................... 39
X. Anexos ............................................................................................................................................. 40
A. Anexos en CD-ROM ...................................................................................................................... 40
1) Código VB6 Programa Servidor ................................................................................................. 40
2) Código C Programa Kiosco ........................................................................................................ 40
3) Código C Programa Parqueadero .............................................................................................. 40
4) Esquemático y PCB Kiosco ........................................................................................................ 40
5) Esquemático y PCB Parqueadero .............................................................................................. 40
6) Documentación microcontrolador Atmega16 ........................................................................... 40
7) Documentación lector RFID Mikroelektronika RFID Reader ....................................................... 40
8) Documentación I2C ................................................................................................................... 40
9) Documentación módem GPRS Sim340z .................................................................................... 40
B. Evaluación y Selección de Tecnologías .......................................................................................... 41
1) Identificación ............................................................................................................................ 41
2) Comunicación servidor-kiosco .................................................................................................. 43
3) Comunicación Kiosco-Parqueaderos ......................................................................................... 45
4) Kiosco ....................................................................................................................................... 47
4
Estación de alquiler de bicicletas
Kiosco de alquiler de bicicletas
Aditamento mecánico de la bicicleta
Servidor central
1 servidor
15 parq /estación
Parqueadero individual de
bicicleta
Figura 1: Módulos del sistema
N estaciones
I. INTRODUCCIÓN
La movilidad se ha convertido en una de las mayores preocupaciones de los centros urbanos a través del
mundo. El amplio uso y la cultura de la bicicleta en países desarrollados han llevado a la implementación
de sistemas de bicicletas en libre servicio que se pueden ver desplegados en ciudades de países como
Francia, Alemania y Canadá, entre otros. Un sistema diseñado para las necesidades locales no ha sido
hasta ahora desarrollado o implementado exitosamente. Con una extensa red de ciclo-rutas, Bogotá es un
escenario idóneo para la implementación de una solución de este tipo.
El documento presenta el
desarrollo de un sistema
electrónico ampliamente
autónomo de préstamo de
bicicletas en libre servicio
para el sector privado en
Bogotá conectado en red lo
que permite expandir su
cobertura. Se realizó un desarrollo electrónico que suple unas funcionalidades mínimas especificadas por
un cliente a la vez que se definieron las necesidades básicas en cuanto a la gestión del sistema y las
conexiones mecánicas para ser desarrollados posteriormente ya que se salen del perímetro del presente
proyecto.
El sistema ha sido avalado por la empresa Mobi bajo su proyecto “Mejor en Bici” que a su vez cuenta
con el respaldo de la Cámara de Comercio de Bogotá y el Instituto de Políticas de Desarrollo del
Transporte.
Se ha seguido una metodología de diseño e implementación basada en el estándar ANSI/EIA 632.
5
II. ANTECEDENTES
Desde hace varias décadas se han desarrollado programas de bicicletas compartidas en libre servicio. La
mayoría de los proyectos pioneros, que datan de los años 60 en Europa, ponían bicicletas estándar a
disposición del público. Sin embargo estos modelos fueron insostenibles debido al robo y daño excesivo
del material.
La implementación de sistemas informáticos y de electrónica embebida en estaciones y bicicletas
permitió desarrollar el primer modelo exitoso de bicicletas en libre servicio a gran escala. Vélo’v, en
funcionamiento desde 2005 en Lyon (Francia), introdujo un sistema informático de control central,
candados controlados electrónicamente, un sistema de comunicaciones entre las estaciones y bicicletas
con auto-diagnóstico electrónico, entre otros.
Hoy se encuentran sistemas similares en varias ciudades en Europa y Norteamérica incluyendo Paris
(Vélib), Montpellier (Vélomagg’), Barcelona (Bicing), Washington (SmartBike DC) y Montreal (BIXI).
A. Vélib’ (Paris, France)
Vélib’ es una de las implementaciones más grandes y exitosas actualmente de un sistema de bicicletas
en libre servicio. Fue puesto en funcionamiento en julio de 2007 y actualmente cuenta con 206001
bicicletas.
El sistema está compuesto por 3 componentes principales:
1. Las bicicletas.
2. Una terminal de interfaz con el usuario.
3. Puestos de sujeción de las bicicletas.
Las bicicletas fueron diseñadas específicamente para el sistema. Tienen 3 cambios, un sistema de
iluminación permanente delantero y trasero potenciado por un generador y un chip RFID para
identificación. Las bicicletas están empotradas en un molde por seguridad.
1 Dossier de presse en Anglais. Vélib’ website. Recuperado el 8 de Diciembre de 2009 de
http://www.velib.paris.fr/content/download/777/5528/version/1/file/Dossier+de+presse+Anglais.pdf
6
La terminal de interfaz con el usuario tiene como principal objetivo la liberación de una bicicleta. Esta
provee sin embargo otras opciones tales como la consulta del saldo del usuario, información acerca del
sistema e incluso permite contactar a una persona de servicio técnico.
Las estaciones utilizan un procesador Pentium M de 1.75GHz, memoria RAM de 1GB y corren el sistema
operativo Windows XP. La comunicación entre estaciones funciona por la red celular GPRS. La terminal
cuenta también con un lector de chips RFID, un lector de tarjetas de crédito y una impresora.
Los puestos de sujeción tienen un sistema electro-mecánico de sujeción y un lector de chips RFID. La
comunicación entre la terminal y los puestos de sujeción se da a través de una red Ethernet directa.
El sistema es manejado por el distrito y se encuentra por lo tanto subvencionado. Tiene sin embargo un
costo para el usuario que aumenta de forma exponencial para beneficiar el uso de la bicicleta para
trayectos cortos y asegurar la rápida rotación de bicicletas. El usuario debe además suscribir un plan el
cual puede ser de larga duración (1 año = 29 EUR) o planes de corta duración (1 día = 1 EUR, 1 semana = 5
EUR). Una vez inscrito en el sistema, el usuario puede obtener una bicicleta por medio de un código
impreso por la terminal de interfaz, o bien mediante una tarjeta de transportes públicos que cuenta con
un chip RFID.
B. Funcionalidad posible
Las posibilidades para un sistema de alquiler como el que se presenta son virtualmente ilimitadas.
Basándonos en la funcionalidad implementada en algunos sistemas e imaginando lo que podría ofrecer
uno muy completo identificamos las siguientes funciones posibles:
Kiosco
Inscripción al sistema
Recarga de cuenta
Consulta de historial
Alquiler de bicicleta
Consulta de información de otras estaciones
Registro/Identificación de bicicletas dañadas.
Generación/Impresión de tarjetas de usuario.
7
Parqueadero de Bicicletas
Alquiler de bicicletas
Recibe los comandos de Inicio/Fin de alquiler.
Sirve de interfaz entre los módulos de Kiosco y Bicicleta comunicando la información transmitida
por el Módulo de Bicicleta.
Genera la señal de liberar/asegurar mecánicamente la bicicleta.
Identificación de bicicletas dañadas.
Servidor Central
Autorización de alquiler
Registro de alquiler
Adición y supresión de bicicletas y usuarios
Registro de devolución de bicicletas
Registro de bicicletas averiadas
Consulta de históricos de uso
Módulo integrado a la bicicleta
Auto-diagnóstico de la bicicleta
◦ Presión de llantas
◦ Piezas faltantes
Llantas
Sillín
Manubrio
Pedales
Cadena
◦ Integridad del marco.
◦ Sistema de iluminación.
Estadísticas de uso
◦ Distancia recorrida
◦ Histórico de usuarios
◦ Histórico de estaciones donde ha estado
◦ Rutas recorridas (con GPS)
8
III. DESCRIPCIÓN DEL CLILENTE Y ESPECIFICACIONES DEFINIDAS
El sistema ha sido diseñado pensando en un cliente directo y un usuario final. El cliente directo se
refiere a empresas de más de 50 empleados que tengan políticas de salud ocupacional que fomenten el
uso de la bicicleta entre sus empleados como medio de transporte y para bienestar de los mismos. Cada
empresa puede tener varias sedes y n número de estaciones en cada sede. Cada estación tendrá 15
parqueaderos con máximo una bicicleta por parqueadero. La empresa ofrecerá a sus empleados el
sistema de préstamo de bicicletas para su uso profesional o personal, de esta forma, los usuarios pueden
pedir una bicicleta para ir a sus casas o desplazarse entre sedes de la empresa, entre otros usos. Los
usuarios tendrán una forma de identificación que indique que hacen parte del sistema para poder hacer
uso de una bicicleta. Antes de un tiempo determinado por el cliente, el usuario deberá devolver la
bicicleta para que ésta pueda ser utilizada por otros usuarios. Las bicicletas serán genéricas y tendrán un
aditamento metálico específico al sistema que se conectará de manera mecánica al parqueadero y
asegurará la bicicleta a este.
Para el producto final se establecieron los siguientes requerimientos mínimos del sistema:
Parqueadero de bicicleta
◦ Comunicación con un kiosco, distancia máx. 15m
Kiosco
◦ Comunicación con 15 parqueaderos de bicicleta, distancia máx. 15m
◦ Comunicación con un servidor, distancia 15 km o más
Servidor
◦ Almacenamiento de estado de bicicletas, alquileres e históricos
◦ Comunicación con múltiples kioscos (10 o más), distancia 15 km o más
9
Identificar usuario
Tomar bicicleta
Usar bicicleta
Devolver bicicleta
Seleccionar bicicleta
¿Bicicleta averiada?
¿Usuario válido?
Fin
No
Si
No
Inicio
Reportarla como dañada
Si
Identificar usuario
IV. PRINCIPIOS DE FUNCIONAMIENTO
La funcionalidad mínima acordada implica varios pasos.
Una o varias estaciones de bicicletas perteneciente a un
sistema será instalada en el sitio requerido, pudiendo
estar a varios km de otra estación. Esta contará con 15
parqueaderos de bicicleta, donde cada uno puede recibir
una bicicleta. Para el uso de las bicicletas se requiere en
primer lugar un proceso de identificación de un usuario
del sistema. Seguidamente se determina si se trata de un
usuario válido (perteneciente al sistema y sin sanciones
de ningún tipo). Una vez validada esta primera parte,
una bicicleta será automáticamente liberada y el sistema
sabrá a qué usuario le fue prestada. El usuario podrá
usar la bicicleta y contará con un tiempo determinado
para devolverla. Si no es devuelta en ese tiempo, este
incurrirá en una falta y será sancionado. El proceso
visto por un usuario final se muestra en la Figura 2.
Una vez devuelta la bicicleta, el sistema descargará la bicicleta del usuario y el proceso vuelve a su estado
inicial.
V. DISEÑO DEL SISTEMA
El diseño del sistema está descrito en dos partes: una funcional, donde se descomponen las funciones
en módulos y se muestran las interconexiones del sistema; y una dinámica, que describe el
funcionamiento de los bloques.
A. Componentes del sistema
El sistema está compuesto por tres componentes principales que se muestran en la Figura 1: un servidor
central, único para todas las estaciones; kioscos, uno por estación; y parqueaderos de bicicleta, 15 por
estación.
Figura 2: Proceso visto por el usuario final
10
B. Funcionamiento del sistema
El sistema tiene dos tipos principales de usuario: usuario final y administrador del sistema.
La interacción del usuario final con el sistema se
da con cada parqueadero individual de bicicleta.
En él se puede identificar, tomar en préstamo una
bicicleta (una sola a la vez), devolver una bicicleta
y reportar una bicicleta como dañada.
Desde el punto de vista del administrador, este
puede agregar y suprimir usuarios, consultar
estadísticas de usuarios y liberar bicicletas
reportadas como dañadas. Su interacción con el
sistema se da tanto a nivel del servidor como a
nivel de los parqueaderos con un ID maestro,
detallado más adelante.
Todas las decisiones durante el
funcionamiento normal del sistema son
realizadas por el servidor. Cada vez que un
usuario realiza una transacción el
parqueadero utiliza el kiosco para
comunicarse con el servidor, donde se
validan los diferentes parámetros de la
transacción (usuario, transacción, etc.) y se
responde la decisión al parqueadero. Se decidió
este modo de funcionamiento porque uno de los objetivos es que el sistema sea escalable y con varias
estaciones, por lo que la validación central es la más apropiada.
Los procesos en detalle que se ejecutan en el sistema son:
Instalación de nueva estación
Ingreso y supresión de bicicleta
Ingresar nuevo kiosco al servidor
Montaje físico de la estación (sin bicicletas)
¿Comunicación satisfactoria?
No
Si
Inicio
Verificación de comunicación con el kiosco
Proceso validado, parqueaderos de
estación disponibles Fin
Proceso no validado,
estación no integrada al
sistema
Identificar usuario con el ID maestro
Ingresar nueva bicicleta a parqueadero de bicicletas vacío
Inicio
Fin En servidor: si ID maestro,
autorizar devolución aun sin tener asignado un alquiler.
Figura 3: Instalación de una nueva estación
Figura 4: Ingreso de nueva bicicleta
11
Kiosco de préstamo:
o ciclo de préstamo
o ciclo de devolución (incluye
reporte de bicicleta dañada)
o ciclo de bicicleta no tomada
Parqueadero de bicicleta:
o ciclo de préstamo
o ciclo de devolución (incluye
reporte de bicicleta dañada)
o ciclo de bicicleta no tomada
Supresión de reporte de bicicleta
dañada
La Instalación de una nueva estación consiste en el montaje físico de la estación, la adición del kiosco de
las estación al servidor y posteriormente la validación del kiosco y la comunicación con el mismo. Se
puede ver el proceso en la Figura 3.
El ingreso de nuevas
bicicletas y la eliminación de
bicicletas existentes en el
sistema son procesos
independientes del ingreso de
nuevas estaciones. Ambos
hacen uso del ID de usuario
especial mencionado
anteriormente, el ID maestro.
Este ID tiene un tratamiento
especial a nivel del servidor,
con autorizaciones como
poder liberar bicicletas
reportadas como dañadas (que
al ingresar quedan como
buenas), ingresar bicicletas sin
Inicio (Idle)
Recepción ID usuario
¿Hay bicicleta?
No
Si
¿Señal Liberar bicicleta? (de parqueadero)
Liberar bicicleta
No
¿Bicicleta tomada?
Bloquear bicicleta
Si
Si
No
Comunicación ID usuario al kiosco
Comunicación al parqueadero de
bicicleta: Bicicleta no tomada
5 segundos
30 segundos
Inicio
Recepción bicicleta
Comunicación al parqueadero de bicicleta: Señal bicicleta devuelta,
estado bicicleta
Bloqueo de la bicicleta y asignación de parqueadero como ocupado
Identificación usuario
Fin
Figura 6: Parqueadero - ciclo de préstamo
Figura 5: Parqueadero - ciclo de préstamo
12
restricciones (para nuevas
bicicletas) y liberar un número
ilimitado de bicicletas. El proceso
de adición de nueva bicicleta se
detalla en la Figura 4, y el de
supresión corresponde
simplemente a retirarla con el ID
maestro. En este caso este ID no
queda con alquileres asignados en
el servidor.
Entre los procesos más
importantes del sistema
encontramos los ciclos de
préstamo, devolución y bicicleta
no tomada, vistos desde el kiosco.
Las Figura 7, 7 y 9 detallan el
proceso.
Asimismo encontramos los mismos
procesos para el parqueadero de bicicleta,
explicados en la Figura 6 y 8.
El detalle de la implementación de los
algoritmos presentados en esta sección se
presenta en la Sección VI.C. Descripción de
Algoritmos Implementados.
Inicio de comunicación con el servidor
Envío de ID de usuario y ID parqueadero al servidor
Recepción de la respuesta del servidor
¿Usuario válido y parqueadero habilitado?
Recepción ID de usuario desde parqueadero
Mensaje de error a parqueadero
No
Estado Inicial (Idle)
Si
Señal de liberación de bicicleta al parqueadero
Búsqueda de parqueadero de dónde provino la
solicitud
No
Si
¿Hay bicicleta?
Fin
Estado Inicial (Idle)
Recepción señal de devolución por parte del parqueadero
Inicio de comunicación con el servidor
Envío de ID de bicicleta y código de estado de bicicleta
Recepción de señal de bicicleta válida o no válida del servidor (válida si usuario
tenía préstamo registrado)
¿Bicicleta válida?
Envío de señal de liberación al parqueadero
No
Si
Fin
Figura 7: Kiosco - ciclo de préstamo
Figura 8: Kiosco - ciclo de devolución
13
C. Arquitectura de Sistema Seleccionada
Para implementar el prototipo del sistema se realizó una evaluación de tecnologías posibles y se
seleccionaron en función de varios criterios: costo de componente, costos de operación, tamaño y peso,
consumo de potencia, alcance comunicación, velocidad de transmisión, capacidad de procesamiento,
capacidad de almacenamiento, nivel de seguridad, confiabilidad, complejidad de implementación y
funcionalidad final.
En el Anexo X.B. Evaluación y Selección de Tecnologías se presentan las tecnologías consideradas, sus
principales características y la evaluación de las mismas.
Para comunicación de larga distancia se realizó un análisis de costos más detallado para la selección de
tecnologías de larga comunicación. Consultando con expertos, un punto de Ethernet externo incluidas las
obras de ingeniería civil puede tener un costo de 1.5 a 2.5 millones de pesos. Los costos de usar GPRS
serían de aproximadamente 400 000 pesos por año, lo que quiere decir que en el mejor de los casos, un
sistema GPRS puede funcionar durante 4 años por el mismo costo del punto de red. No se justifica
entonces poner un punto de red para la conexión del sistema.
Los resultados de la escogencia de tecnologías se presentan en la Tabla 1: Tecnologías seleccionadas.
Elemento Tecnología seleccionada
Plataforma desarrollo kiosco y parqueaderos
Microcontrolador
Identificación usuario Tag RFID
Comunicación local kiosco - parqueaderos
I2C
Comunicación remota kiosco - servidor
GPRS
Plataforma servidor PC estándar
Tabla 1: Tecnologías seleccionadas
14
VI. IMPLEMENTACIÓN
El sistema descrito está compuesto por las siguientes señales y módulos básicos:
Figura 9: Componentes y señales del sistema
a. Identificación de usuario: RFID
b. Comunicación kiosco-servidor: GPRS
c. Comunicación kiosco-parqueadero: I2C
d. Visualización de parqueadero al usuario final: LEDs
e. Presencia bicicleta
f. Interfaz con servidor central (para Administrador)
A. Ambiente de desarrollo
Una vez efectuada la escogencia de tecnologías, se pasó a la implementación de los algoritmos de
funcionamiento definidos previamente.
15
La implementación de los algoritmos sobre
microcontroladores se hizo bajo el lenguaje C,
utilizando la herramienta MikroC de
Mikroelectrónica. Esto incluyó los algoritmos de
lectura de tarjetas RFID, la comunicación entre
microcontroladores mediante el protocolo I2C y el
envío de información a través el módem GPRS a
través del protocolo TCP-IP: WINSOCK.
En cuanto a la implementación del lado Servidor,
se utilizó el ambiente de programación Visual Basic
6, que permite implementar fácilmente conexiones TCP/IP Winsock e interactuar de manera nativa con
Excel.
Los microcontroladores utilizados fueron los ATMEL Atmega16. El módem GPRS utilizado fue el SIMCOM
Sim340z, y el módulo de lectura RFID utilizado fue el MikroE Easy RFID Reader.
B. Fases de la implementación
El proceso de implementación se realizó de manera modular dividiendo cada módulo en sus sub-
componentes y probándolos por separado.
Para la implementación de los algoritmos en el microcontrolador, se hicieron primero pruebas básicas
de funcionamiento de éste y de sus funciones; UART, puertos I/O, interrupciones, entre otras. Una vez
probadas todas estas funciones por aparte, se procedió a la implementación de los algoritmos. Para
algunos de las funciones se utilizaron ejemplos disponibles en la ayuda del compilador MikroC y en la hoja
de datos del microcontrolador Atmega16 (incluido en anexos).
Se procedió de la misma forma con los otros componentes. Se hicieron pruebas aisladas de la
comunicación I2C utilizando memorias direccionables por este protocolo para la simulación de diferentes
parqueaderos. Se utilizó el bus TWI del microcontrolador y se desarrolló el código en C para elementos
maestros y esclavos.
Figura 10: Interfaz programa servidor en VB6
16
Se desarrolló también un algoritmo para la lectura de las tarjetas RFID, haciendo la decodificación del
código Manchester que es el código utilizado por el lector. Este algoritmo se implemento en el
microcontrolador utilizado en código C y utilizando dos pines que habilitan interrupciones.
Se hicieron pruebas básicas de comunicación a través del módem GPRS. Primero se conectó el módem a
un computador a través del puerto serial de los dos dispositivos y se utilizaron comandos AT para
conectar el módem a la red celular y a internet. Estos comandos fueron luego utilizados dentro de un
programa en C para la implementación en microcontrolador de la comunicación del kiosco con el
servidor. Se utilizó igualmente el puerto UART del microcontrolador para la comunicación entre éste y el
módem.
En cuanto a la plataforma del servidor, inicialmente se probó con el programa “Server” desarrollado por
Simcom que recibe conexiones a través del protocolo TCP-IP: WINSOCK. Posteriormente se desarrolló un
programa en VBA que utiliza el mismo protocolo en el cual se implementaron las funcionalidades
requeridas por la aplicación en cuestión. Recordemos que es el servidor el que contiene la información de
todos los usuarios y el que toma las decisiones del sistema. El programa llena una base de datos en Excel
con toda la información del sistema y le permite al usuario-administrador ejercer sus funciones tales
como el ingreso y eliminación de kioscos y usuarios.
Una vez aprobadas todas las funciones por aparte, se pasó a la conexión y pruebas en bloques más
grandes. En esta parte se comenzaron a desarrollar los algoritmos principales y de control del sistema
como se ve en las figuras 5, 6, 7 y 8. De la misma forma, se realizaron pruebas simulando los fallos y se
modificó la respuesta del sistema hasta que el mismo alcanzó la robustez deseada. Se añadió el sistema
de información al usuario y el sistema de reporte de bicicletas dañadas. Se analizaron los casos de fallo
específicos a la implementación y tecnologías seleccionadas y se propusieron e implementaron soluciones
que se detallan en la Sección VII. Análisis de Robustez.
C. Descripción de Algoritmos Implementados
A continuación se detalla la implementación de los diagramas de flujo presentados en la Sección V.B.
Funcionamiento del sistema con las soluciones tecnológicas escogidas.
17
1) Kiosco
El Kiosco, como se ha descrito anteriormente, actúa como puente entre los parqueaderos (que
gestionan la bicicleta y son el punto de interacción con los usuarios finales) y el servidor (que centraliza la
información y decisiones del sistema). Es una forma de centralizar todas las comunicaciones y disminuir
costos, debido a que se usa un solo módem GPRS (el componente más caro) para 15 parqueaderos.
El Kiosco tiene dos interfaces principales de comunicación: comunicación inalámbrica GPRS con el
servidor (a través del puerto USART del microcontrolador) y comunicación I2C (a través de la
implementación TWI -Two Wire Interface- del microcontrolador) con los 15 parqueaderos que controla.
Lo primero que hace el Kiosco al iniciar es establecer comunicación con el Servidor, para lo que enciende
el módem GPRS con la señal GPRS_Power. Posteriormente se realiza la conexión mediante el envío de
comandos AT de configuración al módem, y se espera la respuesta de conexión o error. Este proceso se
realiza hasta que se realice un enlace satisfactorio con Internet y el Servidor. Con la señal DCD del
módem como trigger de la interrupción externa 1 del microcontrolador, si en cualquier momento se cae
la conexión, se inicia el proceso de re-conexión.
Debido a que el kiosco tiene que operar los 15 parqueaderos de la estación, comunicándose con el
protocolo I2C, se construyó un algoritmo en el que el kiosco recorre los 15 parqueaderos, uno a la vez,
para verificar si el parqueadero tiene una operación por realizar. Para esto se utilizan 6 registros en cada
parqueadero, uno para la transacción y cuatro para identificación del usuario. El 6º registro se utiliza
para escribir la respuesta enviada por el servidor.
Después de la lectura de los 5 registros del parqueadero, se realiza una conversión a una cadena de
bytes (caracteres ANSI) que se envían al servidor con: Código Transacción, ID Usuario, ID Kiosco
(almacenado en el Kiosco) y ID parqueadero (en el Kiosco), de modo que se puedan tratar directamente
en el Servidor.
18
ID Transacción Transacción a realizar
1 Devolución de bicicleta en buen estado
2 Devolución de bicicleta en mal estado
3 Préstamo de bicicleta
4 Retirar bicicleta dañada con ID maestro
5 Caso de error (Parqueadero cerrado sin bicicleta)
6 Pregunta estado de bicicleta al servidor
7 Desbloqueo de caso de error con ID maestro
Tabla 2: Transacciones posibles
El servidor procesa los datos y le envía una respuesta al Kiosco. La respuesta es de transacción Válida o
Inválida, precedida del ID de Kiosco y ID Parqueadero para asegurar la integridad de la información. Esta
información una vez recibida se escribe en el Registro 6 del Parqueadero en cuestión.
Durante la espera de respuesta de datos del servidor se activa un watchdog. Si la respuesta toma más
de 30 segundos se cancela la transacción y se reintenta la misma.
El código con esta implementación se encuentra en el Anexo X.A.2) Código C Programa Kiosco.
2) Parqueadero
El parqueadero es el punto de interacción con el usuario final y con la bicicleta. La Figura 11: Diagrama
estados parqueadero muestra los estados principales del parqueadero.
En la transacción de préstamo (3), cuando el servidor valida la transacción, el usuario tiene 10 segundos
para retirar la bicicleta. En caso de no retirarla se envía la transacción de devolución al servidor y se
bloquea de nuevo la bicicleta.
Adicionalmente existe el estado Error, al que se llega cuando hay bloqueo de la bicicleta y no presencia
de la misma. En este caso se envía al servidor la transacción 5. Si en el servidor no había registro de
bicicleta en dicho parqueadero, se re-habilita para devolución. Si no, se mantiene en error hasta que se
libere con un ID Usuario Maestro.
19
Por otra parte, para salir del estado de indisponibilidad de préstamo (por tener una bicicleta dañada o
un bloqueo sin bicicleta), al pasar un ID de usuario se titila primero el LED Rojo, para mostrar de nuevo la
indisponibilidad, y luego se envía al Servidor la transacción 4 para verificación de ID Maestro.
A nivel de implementación, este diagrama de estados se realiza con el microcontrolador del
parqueadero en modo I2C esclavo. En cada estado en que el parqueadero puede recibir un ID Usuario
para una de las transacciones se activa el módulo RFID, que funciona basado en un código Manchester.
Uno de las salidas de dicho módulo corresponde al reloj y la otra a los datos codificados. Ambas señales
activan interrupciones externas del microcontrolador para realizar la lectura del código.
Una vez se realiza la lectura del ID Usuario, cuando hay una transacción a enviar al servidor se escriben
los 5 primeros registros descritos en la sección anterior, y cuando se recibe la respuesta se escribe cero en
todos los registros para indicar que no hay transacción al kiosco.
Inicio Disponible para devolución.
LEDVerde = 1 LEDRojo = 0
LEDAmarillo = 0 Bloqueo = 0
Envío Transacción 6: Consulta estado bici
Espera respuesta LEDVerde = 0 LEDRojo = 0
LEDAmarillo = titila Bloqueo = 1
Bicicleta presente Bicicleta no presente
Disponible para préstamo.
LEDVerde = 1 LEDRojo = 0
LEDAmarillo = 0 Bloqueo = 1 No disponible
para préstamo. LEDVerde = 0 LEDRojo = 1
LEDAmarillo = 0 Bloqueo = 1
Rta servidor: Bicicleta NOK
Rta servidor: Bicicleta OK
Envío Transacción 1: Devolución bici OK Espera respuesta
LEDVerde = 0 LEDRojo = 0
LEDAmarillo = titila Bloqueo = 1
Envío Transacción 2: Devolución bici NOK
Espera respuesta LEDVerde = 0 LEDRojo = 0
LEDAmarillo = titila Bloqueo = 1
IDUsuario Ingresado, Bici OK
IDUsuario Ingresado, Bici NOK
Envío Transacción 3: Solicitud préstamo Espera respuesta
LEDVerde = 0 LEDRojo = 0
LEDAmarillo = titila Bloqueo = 1
IDUsuario Ingresado
Rta. servidor
Rta. Servidor: usuario inválido
Rta. servidor
Rta. Servidor: Usuario válido
Figura 11: Diagrama estados parqueadero
20
Para determinar si la bicicleta se encuentra en buen o mal estado se utiliza un pulsador que activa una
de las interrupciones externas del microcontrolador para activar la señal de bicicleta dañada. Esta
interrupción solo funciona en el modo de devolución una vez se ha insertado la bicicleta. La señal cuenta
con un temporizador, de modo que si no se identifica el usuario después de 30 segundos de reportarla
como dañada, se desactiva el reporte de daño.
El código de la implementación del Parqueadero se encuentra en el Anexo X.A.3) Código C Programa
Parqueadero.
3) Servidor
En cuanto a la implementación del Servidor, se creó un programa de recepción/envío a través del
protocolo TCP-IP:Winsock. El programa recibe a través del puerto 1337 del computador un arreglo de
bytes que son enviados por el kiosco.
El programa mira que el primer byte enviado corresponda al código de inicio de transmisión y luego se
prosigue con el tratamiento de los datos. En caso positivo, se guarda la cadena de bytes recibidos, un byte
a la vez, en un arreglo de variables que luego son convertidas a variables tipo Long para su utilización
dentro del programa. En caso negativo, puede tratarse de una transmisión incompleta y, hasta que el
programa no vuelva a recibir el byte de inicio, no se procederá con el tratamiento de los datos. Se reciben
entonces 29 bytes que corresponden a:
Descripción Nombre de la variable Tamaño Ubicación
Inicio ByteInicio 1 byte Byte 0
Transacción Transacción 4 bytes Bytes 1 – 4
Usuario UsuarioActual 10 bytes Bytes 5 -14
Kiosco KioscoActual 10 bytes Bytes 15 a 24
Parqueadero ParqueaderoActual 4 bytes Bytes 25 a 28
Tabla 3: Estructuras de datos
Desde su inicialización el programa lee la base de datos que contiene la información del estado de todo
el sistema. Esta base de datos consiste en una hoja de cálculo Excel que contiene, por un lado, la
información de cada usuario y su estado: ID usuario, si el usuario es un usuario maestro, si el usuario tiene
alguna bicicleta en su poder, si el usuario tiene alguna sanción. Por el otro lado, la base de datos contiene
21
la información del estado de las bicicletas y kioscos: ID kiosco, si ese kiosco tiene bicicletas, si las bicicletas
que contiene se encuentran en buen o mal estado. Al iniciarse, el servidor lee esta base de datos y guarda
toda esta información en arreglos de variables internas para su posterior uso en las operaciones del
sistema.
Descripción Nombre de la variable Tamaño
Arreglo de usuarios del sistema Usuarios Número de usuarios
Arreglo que indica si un usuario tiene una bicicleta en su poder
Prestada Número de usuarios
Arreglo que indica si un usuario tiene una sanción
Sanción Número de usuarios
Arreglo que indica si un usuario es usuario maestro
Maestro Número de usuarios
Tabla 4: Almacenamiento de datos en servidor
Descripción Nombre de la variable Tamaño
Kioscos Usuarios Número de kioscos
Presencia de las 15 bicicletas en un kiosco
KioscosConParqueaderos
Número de kioscos x 15
Estado de las 15 bicicletas en un kiosco EstadoBicicleta Número de kioscos x 15
Tabla 5: Tamaño estructuras de datos
Una vez se han guardado todas las variables, se realiza su procesamiento.
El programa evalúa los diferentes casos basándose en los bytes de “Transacción”. Existen 7 tipos de
transacciones diferentes:
Código de Transacción
Explicación
0001 Devolución de bicicleta en buen estado
0002 Devolución de bicicleta en mal estado
0003 Demanda de préstamo de bicicleta
0004 Retirar bicicleta dañada con ID maestro
0005 Modo de error (parqueadero cerrado sin bicicleta)
0006 Pregunta estado de bicicletas del kiosco
0007 Desbloqueo de parqueadero en modo de error con ID maestro
Tabla 6: Transacciones
22
Transacción 0001
El programa recorre el arreglo de usuarios del sistema (Usuarios) y lo compara con el usuario que
solicita la devolución (UsuarioActual). Si encuentra una coincidencia, actualiza el arreglo de préstamo
(Prestada) para quitarle el préstamo a ese usuario.
Si el usuario es válido, el programa ahora recorre los arreglos de kioscos (Kioscos) y los compara con el
kiosco que solicitó la transacción (KioscoActual). Cuando encuentra una coincidencia, en el arreglo de
bicicletas del kiosco actual (KioscosConParqueaderos) y en el parqueadero que solicita la transacción
(ParqueaderoActual) se actualiza la base de datos indicando que de nuevo hay una bicicleta en ese kiosco
y en ese parqueadero.
El servidor, por último, le responde al parqueadero con la siguiente cadena de información:
KiocoActual + ParqueaderoActual + “v” + “delim”
La información de KioscoActual y ParqueaderoActual es una redundancia del sistema para darle mayor
robustez y evitar que haya pérdidas de información. La “v” indica que la transacción es válida y los
caracteres “delim” indican el fin de la transmisión.
En caso contrario, si alguna de las condiciones no se cumple, el servidor envía la siguiente cadena de
información:
KiocoActual + ParqueaderoActual + “i” + “delim”
En este caso, la “i” indica una transacción inválida. Finalmente, la base de datos en Excel es actualizada
con toda esta información
23
Transacción 0002
El programa recorre el arreglo de usuarios del sistema (Usuarios) y lo compara con el usuario que
solicita la devolución (UsuarioActual). Si encuentra una coincidencia, actualiza el arreglo de préstamo
(Prestada) para quitarle el préstamo a ese usuario.
Si el usuario es válido, el programa ahora recorre los arreglos de kioscos (Kioscos) y los compara con el
kiosco que solicitó la transacción (KioscoActual). Cuando encuentra una coincidencia, en el arreglo de
bicicletas del kiosco actual (KioscosConParqueaderos), en el parqueadero que solicita la transacción
(ParqueaderoActual) y en el arreglo de estado de bicicletas de ese kiosco (EstadoBicicleta) se actualiza la
base de datos indicando que de nuevo hay una bicicleta en ese kiosco y en ese parqueadero y que se
encuentra en mal estado.
La respuesta al kiosco es igual que para la transacción 0001. Finalmente, la base de datos en Excel es
actualizada con toda esta información
Transacción 0003
El programa recorre el arreglo de usuarios del sistema (Usuarios) y lo compara con el usuario que
solicita el préstamo (UsuarioActual). Si encuentra una coincidencia, revisa los arreglos de préstamo
(Prestada) y sanción (Sanción) para asegurarse que el usuario sea un usuario válido y esté disponible para
alquilar una bicicleta.
Si el usuario es válido, el programa ahora recorre los arreglos de kioscos (Kioscos) y los compara con el
kiosco que solicitó la transacción (KioscoActual). Cuando encuentra una coincidencia, en el arreglo de
bicicletas del kiosco actual (KioscosConParqueaderos) y en el parqueadero que solicita la transacción
(ParqueaderoActual) se actualiza la base de datos indicando que ya no hay una bicicleta en ese kiosco y
en ese parqueadero.
La respuesta al kiosco es igual que para la transacción 0001. Finalmente, la base de datos en Excel es
actualizada con toda esta información
24
Transacción 0004
El programa recorre el arreglo de usuarios del sistema (Usuarios) y lo compara con el usuario que
solicita el préstamo (UsuarioActual). Si encuentra una coincidencia, revisa el arreglo de usuarios maestros
(Maestro) para asegurarse que el usuario sea un usuario válido y este sea maestro.
Si el usuario es válido y maestro, el programa ahora recorre los arreglos de kioscos (Kioscos) y los
compara con el kiosco que solicitó la transacción (KioscoActual). Cuando encuentra una coincidencia, en
el arreglo de bicicletas del kiosco actual (KioscosConParqueaderos) y en el parqueadero que solicita la
transacción (ParqueaderoActual) se actualiza la base de datos indicando que ya no hay una bicicleta en
ese kiosco y en ese parqueadero. Igualmente, se lleva un contador que indica el número de bicicletas que
ese usuario maestro ha retirado.
La respuesta al kiosco es igual que para la transacción 0001. Finalmente, la base de datos en Excel es
actualizada con toda esta información
Transacción 0005
El programa recorre los arreglos de kioscos (Kioscos) y los compara con el kiosco que solicitó la
transacción (KioscoActual). Cuando encuentra una coincidencia, en el arreglo de bicicletas del kiosco
actual (KioscosConParqueaderos) y en el parqueadero que solicita la transacción (ParqueaderoActual) se
revisa si hay o no una bicicleta. Si el sistema no tenía bicicleta registrada, le envía la siguiente cadena de
datos al kiosco:
KiocoActual + ParqueaderoActual + “v” + “delim”
Esto indica que no debería haber una bicicleta presente y por consiguiente el parqueadero es liberado.
En caso contrario, se envía la siguiente cadena de datos al kiosco:
KiocoActual + ParqueaderoActual + “i” + “delim”
Esto indica que si debería haber una bicicleta en ese parqueadero pero no está. El programa genera una
ventana de error para alertar que hay una anomalía en el sistema.
25
Transacción 0006
El programa recorre los arreglos de kioscos (Kioscos) y los compara con el kiosco que solicitó la
transacción (KioscoActual). Cuando encuentra una coincidencia, en el arreglo de bicicletas del kiosco
actual (KioscosConParqueaderos) y en el arreglo de estado de bicicletas de ese kiosco (EstadoBicicleta) se
revisa el estado de la bicicleta presente en el parqueadero que solicitó la demanda. Si la bicicleta presente
está en buen estado se envía la siguiente cadena de datos al kiosco:
KiocoActual + ParqueaderoActual + “v” + “delim”
De lo contrario se envía la siguiente cadena:
KiocoActual + ParqueaderoActual + “i” + “delim”
Transacción 0007
El programa recorre el arreglo de usuarios del sistema (Usuarios) y lo compara con el usuario que
solicita el préstamo (UsuarioActual). Si encuentra una coincidencia, revisa el arreglo de usuarios maestros
(Maestro) para asegurarse que el usuario sea un usuario válido y este sea maestro.
Si el usuario es válido y maestro, el programa ahora recorre los arreglos de kioscos (Kioscos) y los
compara con el kiosco que solicitó la transacción (KioscoActual). Cuando encuentra una coincidencia, en
el arreglo de bicicletas del kiosco actual (KioscosConParqueaderos) y en el parqueadero que solicita la
transacción (ParqueaderoActual) se actualiza la base de datos indicando que ya no hay una bicicleta en
ese kiosco y en ese parqueadero.
La respuesta al kiosco es igual que para la transacción 0001 y en caso de transacción válida, el
parqueadero es desbloqueado. Finalmente, la base de datos en Excel es actualizada con toda esta
información. El código con el programa implementado en VB6 se encuentra en el Anexo X.A.1) Código
VB6 Programa Servidor.
26
A. Desarrollo del prototipo
Todas las pruebas mencionadas anteriormente fueron desarrolladas a nivel de prototipo básico
implementando los sistemas en protoboard. Una vez el sistema completo, y los casos de fallo
solucionados, se prosiguió a la implementación de la solución a nivel prototipo PCB. Los PCB fueron
diseñados a dos capas siguiendo las reglas estándar de diseño.
1) Regulación
Una buena alimentación DC es importante para el correcto funcionamiento de la mayoría de sistemas
digitales. El módem GPRS es especialmente sensible a la alimentación y requiere una buena regulación
pues llega a consumir 2W.
Para esto si incluyó en cada módulo un circuito de regulación, por lo que es posible alimentarlos entre 6
y 15V DC. Se implementó con un regulador LM317, mostrado en la Figura 12: Circuito de regulación.
Se utilizó la siguiente relación2 para calcular las resistencias que garantizaran un voltaje de salida de
4.2V:
Con menor a 100 uA, el término correspondiente es despreciable.
A partir de lo anterior se seleccionó y
También se incluyeron condensadores para manejar los picos de corriente que requiere el módem
durante conexión, transmisión y recepción de datos.
2 Hoja de datos LM317. Recuperado el 10/02/2010 de http://www.national.com/ds/LM/LM117.pdf
27
Figura 12: Circuito de regulación
2) Microcontrolador ATMEGA16L: Kiosco y Parqueadero
El microcontrolador usado tanto en el Kiosco como en los Parqueaderos es el ATMEGA16L, que opera
entre 2.7V y 5.5V. Para su correcto funcionamiento se polarizaron los pines GND, AREF y AGND a tierra y
AVCC y VCC a 4.2V. Se usó un cristal de 11.0592MHz, que permite una buena precisión para el módulo
USART interno y se polarizó el pin RESET a Vcc con una resistencia de . Finalmente se incluyeron
dos condensadores de desacople de 100nF, uno para el pin VCC y otro para el pin AVCC, para filtrar el
ruido de alimentación. Dicha polarización se presenta en la Figura 13: Polarización microcontrolador
ATMEGA16.
Figura 13: Polarización microcontrolador ATMEGA16
28
3) Parqueadero
El parqueadero, además del circuito de alimentación y la polarización del microcontrolador mostrada en
las secciones anteriores, cuenta con varios conectores y dip-switches. La Figura 17 presenta el diagrama
de bloques del Parqueadero.
0. Circuito de polarización, descrito en la sección 2).
1. Conector RFID de 10 pines, con el reloj y pin de datos de entrada al microcontrolador y 3 pines de
polarización.
2. Conector bloqueo y presencia de bicicleta, con 3 pines: bloqueo bicicleta (out), presencia bicicleta
(in) y GND.
3. Dip-switch simulación presencia bicicleta.
4. Dip-switch dirección parqueadero de 4 bits, para identificación ante Kiosco y Servidor. Permite
seleccionar la dirección del parqueadero (entre 1 y 15) durante la instalación.
5. LEDs de interfaz al usuario: Estado (verde, rojo y amarillo), Reporte bicicleta dañada (azul) e
información bloqueo bicicleta (blanco).
6. Conector USART: permite acceder el puerto USART del microcontrolador. Solo se usa para pruebas,
no tiene uso en el producto final.
uControlador ATMEGA16
1. Conector RFID
0. Circuito polarización
2. Conector bloqueo y presencia bicicleta
7. Conector I2C hacia
Kiosco
8. Conector I2C hacia siguiente parqueadero
6. Conector USART (debug)
5. LEDs interfaz usuario
3. Dip-switch simulación
presencia bicicleta
4. Dip-switch dirección
parqueadero
Figura 14: Diagrama de Bloques Parqueadero
29
7. Conector I2C hacia kiosco: pines SDA, SCL y GND.
8. Conector I2C hacia siguiente parqueadero: pines SDA, SCL y GND.
La Figura 18 presenta la versión final del esquemático del parqueadero.
4) Kiosco
El Kiosco comparte con el parqueadero la alimentación y polarización. Adicionalmente cuenta con el
módem GPRS Sim340z con una polarización muy sencilla: 8 VBAT conectados a Vcc y 6 GND conectados a
tierra. Para ambos grupos de VBAT se utilizan condensadores cerámicos de 100nF de desacople. La
Figura 16: Polarización módem Sim340z muestra dicha polarización.
Figura 15: Esquemático Parqueadero
Alimentación
0.
1.
2.
3.
4.
5.
5.
7.
8.
6.
30
Figura 16: Polarización módem Sim340z
Aparte del módem se encuentran también algunos conectores y dip-switch:
0. Circuito de polarización, descrito en la sección 2).
1. Dip-switch dirección Kiosco de 8 bits, para identificación ante el servidor, configurable durante la
instalación.
2. Dip-switch de numéro máximo de Parqueaderos (4 bits), entre 1 y 15, configurable durante la
instalación.
3. Módem GPRS Sim340z. Se controla con los pines Rx, Tx, PWRKEY (para encender y apagar el
módem), VDD_EXT (para ver el estado ON/OFF del módem) y DCD (para verificar la conexión al
Servidor).
4. Conector pines GPRS (debug): Rx, Tx, PWRKEY, VDD_EXT, DCD y GND.
5. Conector I2C hacia Parqueadero.
6. Conector I2C hacia Parqueadero.
La Figura 17: Diagrama de bloques Kiosco y Figura 18: Esquemático Kiosco presentan el detalle del
Kiosco.
Los PCBs, que se muestran en la Figura 19: PCB Parqueadero y Figura 20: PCB Kiosco, se implementaron
en doble capa y fueron fabricados por el Laboratorio de Fabricación de Circuitos Impresos (LFCI) de la
Universidad de Los Andes. Después de realizado el montaje de componentes se obtuvo el prototipo
implementado mostrado en la Figura 21: Lector RFID, Parqueadero y Kiosco, Figura 22: Kiosco y Figura 23:
Parqueadero.
31
Figura 18: Esquemático Kiosco
Alimentación
0. 1.
2.
4.
6.
5.
3.
uControlador ATMEGA16
0. Circuito polarización
5. Conector 1 I2C hacia
parqueadero
4. Conector pines GPRS
(debug)
3. Módem GPRS
sim340z
1. Dip-switch dirección Kiosco
2. Dip-switch máx parqueaderos
6. Conector 2 I2C hacia
parqueadero
Figura 17: Diagrama de bloques Kiosco
34
B. Simulaciones y Pruebas
Los tres módulos: Kiosco, Parqueadero y Servidor fueron probados a lo largo de la implementación. Por
una parte se realizaron pruebas del código a medida que se implementaba en el compilador. Esto,
aunque no permite una verificación del funcionamiento exacto del código en el microcontrolador,
permite asegurar que el tratamiento y conversión de datos sea el correcto. Posteriormente se realizaron
pruebas del código ejecutado en el microcontrolador, por bloques y del sistema completo.
Con respecto al Servidor, inicialmente se simularon los Kioscos con conexiones TCP/IP Winsock desde
HyperTerminal. Esta simulación es muy adecuada debido a que el estándar es el mismo y no importa que
dispositivo envíe la información. Con esto fue posible simular hasta 30 Kioscos funcionando
simultáneamente en un Servidor.
Finalmente, debido a que solo se contaba con un parqueadero en circuito impreso y uno en protoboard,
se simularon varios de ellos con memorias EEPROM I2C 24C02. Debido a que el Parqueadero está
implementado como un dispositivo I2C esclavo es posible simular varios Parqueaderos con dichas
memorias, que se comportan igual ante el Kiosco.
35
VII. ANÁLISIS DE ROBUSTEZ
Uno de los requerimientos principales de la implementación es la robustez del funcionamiento del
sistema completo. Aunque el sistema está concebido para tener un administrador que interactúa con los
usuarios en operaciones puntuales (adición y eliminación de usuarios, gestión de sanciones, etc.) y
responde a algunos problemas operativos, es fundamental que el sistema tenga un mínimo nivel de
confiabilidad y manejo autónomo de fallos. La Tabla 7: Principales fallos contemplados y manejo de los
mismos presenta un resumen.
A. Comunicación GPRS
El primer fallo contemplado, debido a que su impacto es alto y su probabilidad de ocurrencia es alta, es
pérdida de paquetes de información en la comunicación GPRS (kiosco-servidor). Para solucionar este
posible fallo en caso de ocurrencia se incorporó información redundante y respuestas de confirmación en
los protocolos de comunicación kiosco-servidor-kiosco para garantizar la validez de la información
transmitida, procesada y almacenada.
El segundo fallo contemplado, con impacto alto y probabilidad de ocurrencia media, es la no
comunicación entre kiosco y servidor. El principal inconveniente en este caso, debido a que la
información y decisiones se encuentran centralizadas en el servidor, es que el kiosco queda inhabilitado
para realizar la mayoría de operaciones.
Para este error en la comunicación GPRS se consideró imprescindible la posibilidad de realizar la
devolución de bicicletas; desde el punto de vista del usuario resultaría inaceptable no poder devolver la
bicicleta debido a los inconvenientes que le causaría. Por esto siempre que esté en funcionamiento el
parqueadero sin bicicleta es posible devolverla, y en caso de fallo en comunicación con el servidor se
almacena esta información hasta que sea posible la misma. Otra de las características del programa del
kiosco es que cada vez que se cae la comunicación GPRS se reinicia la secuencia de reconexión
automáticamente.
36
Adicionalmente para el fallo en la comunicación GPRS se utilizó un temporizador watchdog en el kiosco
para evitar que no se terminen transacciones y se bloquee la estación en caso de no obtener una
respuesta del servidor.
El último fallo contemplado para la comunicación GPRS, también con alto impacto y probabilidad de
ocurrencia media, es el cambio en la dirección IP del servidor. Este fallo haría que ninguno de los kioscos
se pueda comunicar con el servidor y necesitaría una reprogramación de los mismos. Para evitar esta
situación se utiliza un servidor DNS, con el que no se configura directamente una dirección IP en los
kioscos sino una dirección DNS que está asociada dinámicamente a la dirección IP del servidor.
Fallo Prob. de
ocurrencia Impacto Relevancia
(P*Impacto) Detección y soluciones
Pérdida de datos vía GPRS 5 5 25 Paquetes con información redundante, respuesta de confirmación
Comunicación GPRS caída 3 5 15 Watchdog en kiosco, almacenamiento de datos de recepción
Cambio IP servidor 3 5 15 Uso de servidor DNS
Señal de bloqueo activa, sin presencia de bicicleta
3 4 12 Verificación continua, notificación en caso de error al servidor
Falla alimentación estación 3 4 12 UPS, consulta de estado de bicicletas al servidor al re-alimentar
Falla alimentación servidor 3 4 12 UPS, reinicio automático de servidor y software
Daño servidor 2 5 10 Verificación por parte del administrador. Intervención: reemplazo
Pérdida datos en servidor 2 5 10 Intervención: carga de información de backup (Backup diario)
Bloqueo software servidor 2 5 10 Verificación por parte del administrador. Intervención: reinicio
Daño sistema de bloqueo bicicleta
2 4 8 Verificación en caso de bloqueo y no bicicleta (notificación del servidor). Intervención: verificación y reemplazo en caso de daño.
Daño sensor de bicicleta 2 4 8 Verificación en caso de bloqueo y no bicicleta (notificación del servidor). Intervención: verificación y reemplazo en caso de daño.
Daño parqueadero 1 5 5 Watchdog en kiosco, notificación al servidor. Intervención: verificación y reemplazo en caso de daño.
Daño módem GPRS 1 5 5 Recepción periódica (30 mins) de información de verificación de kiosco. Si no comunicación en 2 horas, alerta en servidor para verificación. Intervención: reemplazo en caso de daño.
Comunicación I2C caída/bloqueada
1 4 4 Watchdog en kiosco, notificación al servidor. Intervención: verificación y reemplazo en caso de daño.
Daño kiosco 1 4 4 Recepción periódica (30 mins) de información de verificación de kiosco. Si no comunicación en 2 horas, alerta en servidor para verificación. Intervención: reemplazo en caso de daño.
Daño lector RFID 1 4 4 Notificación de usuarios. Intervención: reemplazo en caso de fallo.
Tabla 7: Principales fallos contemplados y manejo de los mismos
B. Bloques y presencia de bicicletas
En la operación normal una de las principales vulnerabilidades del sistema son las bicicletas. Son el
componente del sistema que mayor utilidad tiene para cualquier persona, por lo que pueden ser víctimas
de intento de robos. Con respecto a los usuarios finales se tiene un registro de los mismos e información
37
de uso incluyendo penalizaciones, por lo que esto ya está contemplado. Un componente primario de la
seguridad de las bicicletas es el bloqueo mecánico, que como mencionamos en un principio está fuera del
alcance del proyecto. Sin embargo contemplamos un caso de fallo que puede estar relacionado con un
mal funcionamiento del sistema de bloqueo o del sensor de reconocimiento de la bicicleta.
Continuamente se vigila en cada parqueadero la siguiente situación: bicicleta bloqueada sin bicicleta.
Cuando se produce esta situación se envía una notificación al servidor, que en función de la información
almacenada se re-habilita el parqueadero o se realiza una verificación del parqueadero.
C. Cortes eléctricos y otros fallos en el servidor
Otra de las fallas probables en el sistema, pero con un impacto menor, es una falla de alimentación. En
el servidor bloquearía las transacciones en todos los kioscos mientras no esté alimentado, mientras en las
estaciones sucedería lo mismo localmente.
En ambos casos una UPS es una buena alternativa para limitar el impacto. Sin embargo, si la misma no
es suficiente para la totalidad del corte de electricidad, cada parqueadero verifica con el servidor el
estado de la bicicleta (en caso de haber) antes del corte. El servidor se puede programar para que se
reinicie automáticamente después de una falla eléctrica. Lo mismo aplica para el software del mismo.
El servidor puede presentar otras fallas, como bloqueo del programa o daño físico del mismo. Para
estos casos es necesaria la intervención reemplazándolo o reiniciando el software.
Por otra parte puede haber pérdida de datos, por lo que está programado para realizar una copia de
seguridad diaria. En caso de fallo sería necesario que el administrador restaure la copia disponible.
D. Fallos en estaciones Kiosco y Parqueaderos
Cada estación, con su kiosco y parqueaderos, tiene varios componentes que podrían fallar. Estos
pueden estar relacionados con el parqueadero (fallo en el lector RFID, fallo en comunicación I2C, fallo en
sistema de bloqueo de bicicleta, fallo en sensor de bicicleta) o en el kiosco (fallo en módem GPRS, fallo en
comunicación I2C). Algunos de estos errores son detectables con lo mencionado anteriormente (modo
error con bloqueo sin bicicleta, por ejemplo), pero otros no.
38
El fallo en parqueadero es detectable cuando el kiosco no recibe una respuesta del primero. En este
caso también se envía un reporte de error al servidor.
Por otra parte, los fallos en el kiosco se manifiestan con una no comunicación con el servidor. Para
verificar que la comunicación continúe activa, ésta se verifica desde el servidor, y si no se logra después
de dos horas, se genera una notificación en el servidor.
Finalmente una fuente redundante y muy importante de detección de errores son los usuarios, pues se
pueden comunicar con el administrador para notificarle sus problemas.
VIII. CONCLUSIONES Y PERSPECTIVAS
El resultado principal del proyecto “Diseño de un sistema electrónico de préstamo de bicicletas auto-
servicio”, además de los diseños, códigos y planos eléctricos basados en la metodología top-down, es un
prototipo electrónico funcional con un nivel aceptable de robustez. Asimismo se desarrolló el software
del servidor hasta un nivel operacional.
Para realizar una implementación completa del sistema es necesario desarrollar algunos componentes
adicionales. Desde el inicio se excluyó del perímetro del proyecto el módulo mecánico de bloqueo y
desbloqueo de la bicicleta, por lo que éste es el punto crítico que no permite una implementación
completa del sistema. Por otra parte, aunque el software de servidor en VB6 funciona adecuadamente, es
un programa básico que no guarda los datos en una base de datos estándar de modo que pueda ser
accedida y modificada por otros programas o clientes remotos.
39
IX. BIBLIOGRAFÍA
Philips Semiconductors. THE I 2C-BUS SPECIFICATION. Philips Web site. [Online] [Cited: Feb 20, 2010.]
http://www.nxp.com/acrobat_download2/literature/9398/39340011.pdf.
01Net. La face cachée high-tech des vélos parisiens Velib. [Online] [Cited: 2 10, 2010.]
http://www.01net.com/editorial/354919/la-face-cachee-high-tech-des-velos-parisiens-velib/.
ANSI. ANSI/EIA 632.
Barcelona, Ajuntament de. Bicing. [Online] [Cited: 02 10, 2010.] http://www.bicing.cat/home/home.php.
BENARAMA Raouf, EMERY Jean. 2008. Dispositif et système de verouillage de vélos en libre service. 08
06379 [ed.] TRACETEL SA. France, Nov 14, 2008.
Decaux, J.C. Velov. [Online] [Cited: 02 10, 2010.] http://www.velov.grandlyon.com/.
GAGOSZ Jean Claude, ZEFERINO Manuel. 2006. Système automatique de stockage de cycles, cycle pour
un tel système et dispositif de verouillage pour un tel cycle. B 62 H 3/00 [ed.] JC Decaux. France, 02 21,
2006.
Hayken, Simon. 2001. Communication Systems, 4th edition. s.l. : John Wiley & Sons, 2001.
J.C. Decaux. Velib. [Online] [Cited: 02 10, 2010.] http://www.velib.paris.fr/.
LE GARS Jacques, LAMY Jean Claude, DARRAS Jacques, TAVERNIER Patrick. 2004. Bicyclette equipée d'un
système de contrôle embarqué. B 62 H 5/20 France, 02 10, 2004.
Libération, La. Le vélo vélib'. [Online] [Cited: 2 10, 2010.]
http://www.liberation.fr/evenement/0101107346-le-velo-velib.
Minutes, 20. Paris se place en tête du peloton des villes où le vélo est roi. [Online] [Cited: 2 10, 2010.]
http://www.20minutes.fr/article/170174/Paris-Paris-se-place-en-tete-du-peloton-des-villes-ou-le-velo-
est-roi.php.
Murdocca, Miles. 1999. Principles of Computer Architecture. s.l. : Prentice Hall, 1999.
The bicycle as a feedering mode: experiences from three European countries. MARTENS, Karel. 2004. 4,
July 2004, Transportation Research Part D: Transport and Environment, Vol. 9, pp. 281-294.
The Design and Implementation of Public Bike Information System Based on Google Maps. RONGLIANG
Luo, YUNRU Shen. 2009. Wuhan, China : s.n., 2009. 2009 International Conference on Environmental
Science and Information Application Technology. pp. 156-159.
Zigbee Alliance. Zigbee. Zigbee Alliance website. [Online] [Cited: Feb 12, 2010.]
http://www.zigbee.org/LearnMore/WhitePapers/tabid/257/Default.aspx.
40
X. ANEXOS
A. Anexos en CD-ROM
1) Código VB6 Programa Servidor
2) Código C Programa Kiosco
3) Código C Programa Parqueadero
4) Esquemático y PCB Kiosco
5) Esquemático y PCB Parqueadero
6) Documentación microcontrolador Atmega16
7) Documentación lector RFID Mikroelektronika RFID Reader
8) Documentación I2C
9) Documentación módem GPRS Sim340z
B. Evaluación y Selección de Tecnologías
1) Identificación
Solución Ventajas Desventajas Requerimientos
ID y Clave Bajo Costo El usuario no necesita llevar ningún dispositivo extra Fácil de usar, sistema conocido por los usuarios Fácil de cambiar
Depende del usuario mantenerlo en secreto Costo de soporte alto Susceptible a espías y crackers El usuario no sabe si ha sido robado El usuario siempre tiene que tener el código de barras consigo mismo Pueden ser robados
Lector de código de barras Impresora Generador de códigos
Código de Barras Tecnología estandarizada, bajo costo Los usuarios no tienen que acordarse de claves complejas El usuario sabe si ha sido robado
Costos más elevados El usuario siempre tiene que tener el token consigo mismo Pueden ser robados
Token de seguridad (ejemplo : tarjetas, tokens USB, chips RFID)
Más seguros que el ID y clave Los usuarios no tienen que acordarse de claves complejas Presentan una ventaja en cuanto a imagen de la empresa
Costos más elevados de software costos más elevados de mantenimiento Costos más elevados de despliegue
Lector del token (dependiente de la tecnología) El token
Biometría Muy alto nivel de seguridad Diferentes opciones (huella digital, iris, retina) Difícilmente la seguridad puede ser comprometida (i.e. no se pierde fácilmente)
Display básico Teclado
Lector biométrico Unidad de lectura de características biométricas
42
Criterio Peso ID y clave (teclado y
pantalla)
Código de Barras RFID SmartCard
Costo 14% 9 7 6 6
Tamaño y peso 10% 7 7 6 6
Alcance comunicación 0%
Consumo potencia 8% 8 7 7 7
Costos operación 6% 8 6 6 6
Nivel estandarización 8% 8 6 5 5
Velocidad de
transmisión
0%
Complejidad de
implementación
10% 8 7 7 7
Nivel de seguridad 12% 5 4 8 8
Capacidad de
procesamiento
0%
Confiabilidad 12% 8 7 7 7
Funcionalidad final 20% 3 3 10 4
Memoria 0%
6.68 5.7 7.26 6.06
43
2) Comunicación servidor-kiosco
Nombre Ventajas Desventajas
BLUETOOTH Popular -> costos de implementación bajos
Costos de explotación nulos
Vulnerable a interceptaciones
Distancia máxima 100m
Tasa de transmisión baja
WIFI Popular -> costos de implementación bajos
Puede utilizar las capacidades ya instaladas en la empresa
Alta tasa de transmisión de datos
Vulnerable a interceptaciones
Distancia máxima 100m
ZIGBEE Bajo consumo
Interconexión de red en malla (hasta 65k nodos)
Se pueden implementar nodos fácilmente y con pocos componentes
Muy baja velocidad de transmisión de datos (250kbps)
No es tecnología estándar entonces los costos de implementación pueden llegar a ser más altos
GPRS Disponible en cualquier lugar (en áreas urbanas).
Velocidad suficiente de transmisión.
Sin límite de distancia.
Presenta costos variables de funcionamiento.
Complejidad de la implementación (mayores costos)
44
Criterio Peso Bluetooth Wi-fi Zigbee GPRS
Costo 8% 6 5 5 5
Tamaño y peso 5% 4 4 4 4
Alcance comunicación 15% 2 3 2 9
Consumo potencia 5% 5 4 7 6
Costos operación 10% 8 8 8 3
Nivel estandarización 9% 7 7 6 6
Velocidad de transmisión
9% 5 7 5 5
Complejidad de implementación
9% 3 3 6 6
Nivel de seguridad 15% 6 6 6 8
Capacidad de procesamiento
0%
Confiabilidad 15% 4 4 6 8
4.88 4.98 5.29 6.48
45
3) Comunicación Kiosco-Parqueaderos
Estándar Características Ventajas Desventajas
I2C Alámbrico
Hasta 112 nodos
Vel transmisión entre 10 kbit/s y 3.4 Mbit/s
Bajo costo de implementación
Sencillez de implementación
Necesidad de cableado
Ethernet Alámbrico
Nodos virtualmente ilimitados
Vel transmisión entre 10 y 100 Mbit/s
Número de nodos
Robustez
Costo de implementación
Necesidad de cableado
Complejidad de hardware y software
ZigBee Inalámbrico
Vel transmisión 250 kbit/s
Alcance de 10 a 75 m
No requiere cables
Hardware relativamente simple
Costo de implementación relativamente bajo
Velocidad de transmisión
Corto alcance
Wi-Fi Inalámbrico
Vel transmisión entre 1 y 150 Mbit/s
Alcance hasta 100 m
Velocidad de transmisión
Alcance medio
Complejidad de hardware y software
Costo de implementación alto
46
Criterio Peso I2C Ethernet ZigBee Wi-Fi
Costo 15% 9 5 2 2
Tamaño y peso 11% 4 4 7 6
Alcance comunicación 8% 7 7 9 9
Consumo potencia 6% 9 8 7 6
Costos operación 12% 4 4 7 7
Nivel estandarización 11% 8 8 8 8
Velocidad de transmisión
8% 6 9 7 8
Complejidad de implementación
8% 9 5 6 4
Nivel de seguridad 12% 8 8 4 6
Capacidad de procesamiento
0%
Confiabilidad 9% 8 8 4 6
Memoria 0%
6.81 6.39 6.05 6.30
47
4) Kiosco
Solución Ventajas Desventajas
Microcontrolador Bajo costo
Sencillez de implementación
Interfaz de usuario básica
Comunicación Ethernet adicional
Hardware Reprogramable (FPGA)
Reprogramable
Costo bajo-medio
Interfaz de usuario básica
Comunicación Ethernet adicional
Computador embebido Interfaz de usuario avanzada
Comunicación Ethernet integrada
Costo alto
PC Interfaz de usuario avanzada
Comunicación Ethernet integrada
Tamaño, peso
Costo alto
48
Criterio Peso Microcontrolador FPGA Computador Embebido PC
Costo 18% 9 8 4 2
Tamaño y peso 8% 9 9 7 2
Alcance comunicación 0%
Consumo potencia 12% 9 9 7 2
Costos operación 10% 6 6 2 4
Nivel estandarización 9% 6 4 8 8
Velocidad de transmisión 0%
Complejidad de implementación
9% 7 8 5 4
Nivel de seguridad 7% 6 6 9 9
Capacidad de procesamiento
6% 4 4 6 9
Confiabilidad 12% 8 8 5 7
Memoria 9% 4 4 6 9
7.17 6.90 5.62 5.06