| Seminario de Computadores II |
3da Presentación |
Sistema de Control de Frecuencia
aplicado al Transporte Metropolitano de Valparaíso
| GENERAL | DISEÑO | DIAGRAMA DE COMPONENTES |
Introducción
En la actualidad el sistema de transporte de la V Región pasó por un período de cambios,
esto significó una modernización y perfeccionamiento de personal. Dentro de estos cambios se incluyó
un sistema de monitoreo apoyado en un GPS conectado a un GPSlogger, del cual al final del recorrido
de las micros, los datos son descargados en un servidor en el terminal, para evaluar que se hayan cumplido
los recorridos y los tiempos establecidos para éstos.
Solución Propuesta
La solución que se propone está basada en el modelo Cliente-Servidor con una topología de red Estrella aplicado a un recorrido fijo de las micros. Esto quiere decir que cada ciertos tramos se encontrará un Servidor esperando que un cliente lo contacte. Los clientes se encuentran dentro de cada micro, la información que se busca obtener son los datos de fecha, hora, minutos y segundos y la posición en ese momento. Esto se logra capturando los datos directamente del GPS.
La herramienta que se usará son redes de sensores inalámbricos, en este caso, los motes telosb, los cuales tienen la característica de comunicarse inalámbricamente, además de tener la posibilidad de integrar distintos tipos de elementos por su puerta de expansión.
En resúmen, el mote cliente captura datos en tramos entre servidores, una vez que ingresa al radio de contacto con un mote servidor. Los datos capturados son descargados sobre el Servidor, para que finalmente éste envíe los datos a un servidor central que procese los datos.
Diseño
En el proceso de diseño se tuvo que tomar en cuenta ciertos datos para el cliente y el servidor. A continuación se muestra en profundidad cada consideración de diseño necesario para lograr el funcionamiento del sistema de monitoreo de buses.
Cliente
El cliente consiste en un mote conectado por el puerto de expanción (USART) con un GPS, los GPS tienen la característica de que por cada segundo que pasa, entregan información de su posición por su puerto serial, esta información se encuentra estandarizada por los mensajes NMEA, por lo tanto no importa qué empresa desarrolle los GPS, los datos siempre serán los mismos.
Para este caso no se usarán los mensajes NMEA, sino la opción de texto plano que entrega el GPS eTrex de la empresa Garmin, por lo que los datos obtenidos son los mismos, sólo que el procesamiento es un poco distinto.
De estos datos sólo nos interesan Date, Time y Position.
| Campo | Largo | Descripción | |
| Sentence start | 1 | Always '@' | |
D |
Year | 2 | Last two digits of UTC year |
| Month | 2 | UTC month, "01".."12" | |
| Day | 2 | UTC day of month, "01".."31" | |
T |
Hour | 2 | UTC hour, "00".."23" |
| Minute | 2 | UTC minute, "00".."59" | |
| Second | 2 | UTC second, "00".."59" | |
P |
Latitude hemisphere | 1 | 'N' or 'S' |
| Latitude position | 7 | WGS84 ddmmmmm, with an implied
decimal after the 4th digit |
|
| Longitude hemishpere | 1 | 'E' or 'W' | |
| Longitude position | 8 | WGS84 dddmmmmm with an implied decimal after the 5th digit |
|
| Position status | 1 |
'd' if current 2D differential GPS position
'D' if current 3D differential GPS position 'g' if current 2D GPS position 'G' if current 3D GPS position 'S' if simulated position '_' if invalid position |
|
| Horizontal posn error | 3 | EPH in meters | |
| Altitude sign | 1 | '+' or '-' | |
| Altitude | 1 | Height above or below mean sea level in meters |
|
V |
East/West velocity direction |
1 | 'E' or 'W' |
| East/West velocity magnitude |
4 | Meters per second in tenths, ("1234" = 123.4 m/s) |
|
| North/South velocity direction |
1 | 'N' or 'S' | |
| North/South velocity magnitude |
4 | Meters per second in tenths, ("1234" = 123.4 m/s) |
|
| Vertical velocity direction |
1 | Meters per second in tenths, ("1234" = 123.4 m/s) |
|
| Vertical velocity magnitude |
4 | Meters per second in tenths, ("1234" = 123.4 m/s) |
|
| Sentence end | 2 | Carriage return, '0x0D', and line feed, '0x0A' |
Estos datos son encapsulados en la siguiente estrutura para luego ser envíados al servidor. Hay que notar que los mensajes enviados tienen un máximo de 29 bytes de datos, en este caso se mandan 12 bytes, por lo que por cada mensaje mandamos una estructura completa.
| Campo | Tipo | Bytes |
| Year | uint8_t | 1 |
| Month | uint8_t | 1 |
| Day | uint8_t | 1 |
| Hour | uint8_t | 1 |
| Minute | uint8_t | 1 |
| Seconds | uint8_t | 1 |
| Latitude (char) | char | 1 |
| Latitude (º '') | uint16_t | 2 |
| Longitude (char) | char | 1 |
| Longitude (º '') | uint16_t | 2 |
| Total: 12 bytes | ||
Servidor
El servidor cumple con la necesidad de tener una estación donde se puedan descargar los datos acumulados del GPS, debido a que por estas estaciones pueden llegar a pasar muchos clientes a la vez, el Servidor consiste en dos módulos, en este caso el mote cumple la función de recibir los datos y enviarlos a otro módulo que tenga una capacidad de procesamiento mayor, para luego mostrar los datos en forma de página web o de forma amigable a la empresa.
Conexión Cliente - Servidor
Para que un sistema como éste pueda ofrecer el mínimo de robustez, es necesario implementar los estados necesarios para lograr un protocolo de comunicación junto con los estados internos de conexión que el cliente y el servidor puedan entender. Es por esto que un factor importante de diseño fue obtener un modelo de estados de la conexión, y del cual está basado la programación de los motes (para la simulación se usará un modelo simplificado).
Descripción del Cliente:
Figura: Diagrama de Estado para Cliente.
Init:
Init corresponde al proceso de inicialización del sistema, esto quiere decir que inicia los contadores timerG y timerB y deja el arreglo con los datos con un valor null. Una vez terminada la inicialización, se pasa inmediatamente al siguiente estado.
Wait_Conection:
Se busca un servidor y se capturan datos del GPS, para pasar al siguiente estado debe esperar el evento recieve("OK SEND"), durante esta transición se detienen los contadores, o sea, se detiene el proceso de captura y busqueda de servidor.
Send_Data:
Se envían los datos que se hayan obtenidos en el tramo de la micro al servidor, una vez que se vacíe el arreglo, se vuelve al estado Init.
Descripción del Servidor:
Figura: Diagrama de Estado para Servidor.
Wait_signal:
Init corresponde al proceso de inicialización del sistema, esto quiere decir que inicia los contadores timerG y timerB y deja el arreglo con los datos con un valor null. Una vez terminada la inicialización, se pasa inmediatamente al siguiente estado.
Rfm_to_pc:
Se busca un servidor y se capturan datos del GPS, para pasar al siguiente estado debe esperar el evento recieve("OK SEND"), durante esta transición se detienen los contadores, o sea, se detiene el proceso de captura y busqueda de servidor.
| Descripción | |
| timerB | Timer de espera para mandar un mensaje broadcast |
| timerG | Cada vez que timerG se dispara, se captura un dato del GPS |
| TimerTout | timer de timeout en caso de que no hayan clientes mandando datos en un período TIME_OUT |
| GPSData | arreglo de datos que guarda los valores capturados del GPS |
| gpsGetData() | función que lee del puerto de expanción |
| send_data_to_PC() | función que representa los datos envíados por el puerto USB hacia el modulo de procesamiento de datos |
Diagrama de Componentes
Diagrama 2: Módulo Servidor..
Códigos
MÓDULO CLIENTE:Componentes
Interfaces Definiciones
MÓDULO SERVIDOR:
Componentes
Interfaces Definiciones
Demostración
Supuestos
El sistema de monitoreo es un gran proyecto, por lo que implementar todo lo que sería necesario para alcanzar el nivel necesario para lograr un producto final es muy difícil, por lo que acontinuación se hará una presentación con el modelo simplificado del sistema. Por lo que la versión actual se podría considerar un BETA.
Por lo tanto a continuación mostramos los supuestos para que la actual versión no tenga problema de
desempeño y robustez.
- Las micros llegan a un servidor antes de hacer un overflow del buffer donde se guardan los datos.
- Los datos no se pierden por colisión o problemas en la transmisión.
- No hay saturación en el servidor por exceso de clientes.
- Una vez que se logran descargar los datos al servidor, la micro logra salir del rango de conexión con el servidor, por lo que si llega a capturar un dato, no se lo envía inmediatamente.
- Los datos del GPS son obtenidos por el puerto de expanción UART desde el GPS, para simplificación del problema se recolectaron datos en un tramo circular: Agua Santa -> Alvarez -> plaza viña -> 15 norte -> San Martin -> Avenida Marina -> reloj de flores -> Alvarez. Estos datos están precargados en el mote Cliente. Ver datos.
Recepción de Datos en PC
La herramienta a utilizar es LISTEN de tinyos-1.x . La línea de comandos necesaria para la recepción desde el PC es:
MOTECOM=serial@COMX:tmote java net.tinyos.tools.Listen
En donde COMX se obtiene de la información que arroja el comando motelist.
Un ejemplo del enviado enviado por el MOTEiv al PC mediante la puerta USB es la siguiente:
| mensaje original | 07 | 05 | 30 | 06 | 09 | 24 | S | 33 | 01512 | W | 071 | 34083 |
| mensaje USB | 07 | 05 | 1E | 06 | 09 | 18 | 53 | 21 | E8 05 | 57 | 47 | 23 85 |
El color rojo indica que los datos hexagesimales estan invertidos.
Descargas
| Descripción | Modicación | Tamaño | |
| Cliente | 14/06/2007 | 13 Kb |  |
| Servidor | 14/06/2007 | 13 Kb | |
Conclusiones
- La idea principal de este proyecto es lograr que en la central puedan obtener los datos para que su procesamiento sea inmediato, por lo que se puede monitorear las acciones del conductor de manera más directa que la solución actual de esperar al fin del día.
- Una concecuencia de obtener los datos durante el recorrido, es que se podría implementar una página web donde se muestren las ultimas posiciones de la micro, entonces se podría estimar un tiempo de llegada al siguiente punto de control, para ayudar a los usuarios a saber que tanto deben esperar antes de ir a un paradero
- Una de nuestras primeras ideas era la de implementar un Display para el cliente, para que pudiese obtener una retroalimentación desde el terminal y establecer un control sobre el recorrido de la micro. Si se lograra implementar un protocolo donde existan mensajes estandarizados, se podría disminuir los mensajes para no saturar el canal de comunicación.
- Un tema importante para la realización de este proyecto fue haber hecho una reunión telefonica con una persona que trabaja en el rubro, puesto que se aclararon las verdaderas necesidades de la empresa, por lo que los esfuerzos en la innovación fueron enfocados a éstas.