controlador de descargas de datos provenientes de las ...148.206.53.84/tesiuami/uami17173.pdf ·...
Post on 27-Sep-2018
217 Views
Preview:
TRANSCRIPT
Controlador de descargas de datos provenientes de las cajas negras en trenes del STC
Reporte de proyecto terminal.
Alumno: Rubén Darío García González Asesor: Luis Martín Rojas Cárdenas
- 2 -
CONTROLADOR DE DESCARGAS DE DATOS PROVENIENTES DE LAS CAJAS NEGRAS EN TRENES DEL STC
1 Introducción
Hoy en día, la información generada por los diferentes subsistemas de los
trenes del STC no está disponible ni a través de redes de telecomunicaciones, ni
concentrada en bases de datos. Cuando se requiere la información de un determinado
tren, normalmente en caso de un accidente u otra eventualidad, se solicita a un equipo
de ingenieros ir físicamente hasta el tren para extraer los datos. Un software
especialmente diseñado para comunicarse con el subsistema indicado permite
efectuar la extracción. Esta tarea simple se vuelve de proporciones gigantescas si
consideran los aproximadamente 300 trenes que conforman el parque de trenes. En la
práctica esta tarea es difícil de efectuar y la gran mayoría de los datos se pierde ya que
la memoria de estos subsistemas es limitada.
2 Objetivo
En este proyecto terminal se propone crear un sistema que coordine la
descarga de datos provenientes de las cajas negras ubicadas en los trenes del STC y su
inserción en la de base de datos (BDD) central.
En el presente documento se explican los detalles sobre el diseño,
implementación, instalación, configuración y funcionamiento del sistema.
3 Controlador de descargas: arquitectura
El sistema utilizará una arquitectura cliente-servidor. Esta arquitectura consiste
básicamente en un cliente que realiza peticiones a otro programa (el servidor) que le
da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre
una sola computadora es más ventajosa en un sistema operativo multiusuario
distribuido a través de una red de computadoras. En este caso el cliente estará
instalado en una computadora embarcada MOXA modelo W311 embarcada en el tren
y el servidor en la computadora central. A continuación se describen las
funcionalidades de cada programa:
- 3 -
3.1 El cliente
El programa cliente se ejecutará en MOXA y tendrá, en principio, las siguientes
funciones:
1. Sincronizar la fecha y la hora de MOXA con la del servidor central.
2. Verificar si el programa servidor continúa funcionando.
3. Enviar los archivos .DAT al servidor central.
4. Solicitar la verificación de la integridad de los archivos enviados.
5. Solicitar la inserción en la base de datos.
3.2 El servidor
El programa servidor responderá a las peticiones del programa cliente, en un
principio las solicitudes que atenderá el servidor serán las siguientes (más funciones se
podrán agregar posteriormente):
1. Verificar el funcionamiento correcto.
2. Verificar la integridad del archivo enviado.
3. Insertar un archivo enviado en la base de datos MySQL.
4. Dividir el archivo .DAT enviado en tres archivos .A, .B y .C
3.3 Extracción de datos de la caja negra
La caja negra en cada tren almacena diversos datos, estos datos se generan
mientras el tren se encuentra en funcionamiento [1]. Por consiguiente la descarga de
estos datos a la computadora embarcada MOXA se hará durante la noche, mientras el
tren está detenido.
3.4 Almacenamiento temporal en la computadora embarcada
Los datos descargados se almacenaran en una tarjeta SD (Secure Digital) en la
computadora embarcada MOXA. Debido a que este tipo de memorias pueden sufrir
bajas en su rendimiento o daños permanentes si se escriben y/o borran datos
continuamente, se adoptará una estrategia de almacenamiento consistente almacenar
todos los archivos enviados en la memoria hasta que no haya más espacio. Sólo
entonces se precederá a borrar el archivo más antiguo.
- 4 -
Los nombres de los archivos .DAT descargados a la computadora MOXA tienen
el siguiente formato:
L##_T###_AAAAMMDD####.DAT
Donde:
L##: es el número de línea donde se encuentra el tren.
T###: es el número del tren.
AAAAMMDD: es la fecha en ese formato. (AAAA: año, MM: mes, DD: día).
####: es el número de empleado.
Estos datos son los datos que finalmente se almacenarán en la base de datos
del servidor central.
3.5 Transmisión de datos hacia el servidor
La transmisión de datos se llevará a cabo en las estaciones terminales de cada
línea. Mientras el tren se encuentra estacionado en el andén de la terminal, el
programa cliente buscara un access point y, si lo encuentra, hará la transferencia. La
transferencia se hace utilizando el software SCP (Secure CoPy) sobre canales IEEE
802.11 (Wi-Fi).
3.5.1 El autómata de transmisión
El autómata de transmisión con el que funciona el programa cliente consta de
siete estados: NTP, ESTASVIVO, VERIFICA, MD5, SCP, INSERTMYSQL y ESPERA, cada
uno con una función específica que se describirá más adelante. Para realizar su
trabajo, el sistema usa diversos protocolos y herramientas que se describen a
continuación.
3.5.1.1 Ajuste de la hora con NTP
NTP (Network Time Protocol) es un protocolo de la familia TCP/IP usado para la
sincronización de la hora [2]. El cliente NTP (identificado en el sistema operativo como
ntpdate) sincroniza la hora del sistema con la de servidores NTP designados (éste
recibe el nombre de ntpd en el ambiente Linux), generalmente clasificados como de
estrato 1 y estrato 2.
- 5 -
Un servidor de estrato 1 se conecta a un reloj atómico vía GPS para una precisa
sincronización, mientras que un servidor de estrato 2 se conecta a un servidor de
estrato 1 lo que produce una sincronización ligeramente menos precisa. NTP.org es en
general una buena fuente de referencia de servidores NTP de ambos estratos.
3.5.1.2 Verificación de la integridad: Resúmenes MD5
En criptografía, MD5 (abreviatura de Message-Digest Algorithm 5, Algoritmo de
Resumen del Mensaje 5) es un algoritmo de reducción criptográfico de 128 bits
ampliamente usado [3].
Los resúmenes MD5 se utilizan extensamente en el mundo del software para
verificar la integridad de un archivo descargado de Internet. Comparando una suma
MD5 publicada con la suma de comprobación del archivo descargado, un usuario
puede tener la confianza suficiente de que el archivo es igual que el publicado por los
desarrolladores. Esto protege al usuario contra los 'Caballos de Troya' o 'Troyanos' y
virus que algún otro usuario malicioso pudiera incluir en el software. La comprobación
de un archivo descargado contra su suma MD5 no detecta solamente los archivos
alterados de una manera maliciosa, también reconoce una descarga corrupta o
incompleta, precisamente ese es el uso que se le da en nuestro sistema.
3.5.1.3 Control de la confidencialidad: SSH/SCP
Secure Copy o SCP es un medio de transferencia segura de archivos
informáticos entre un host local y otro remoto o entre dos hosts remotos, usando el
protocolo Secure Shell (SSH) [4].
En el protocolo SCP los datos son cifrados durante su transferencia, para evitar
que potenciales packet sniffers extraigan información útil de los paquetes de datos. Sin
embargo, el protocolo mismo no provee autenticación y seguridad; sino que espera
que el protocolo subyacente, SSH, lo asegure.
SSH (Secure SHell, en español: intérprete de órdenes segura) es el nombre de
un protocolo y del programa que lo implementa, y sirve para acceder a máquinas
remotas a través de una red. Permite manejar por completo la computadora mediante
un intérprete de comandos, y también puede redirigir el tráfico de X para ejecutar
programas gráficos si tenemos un Servidor X (en sistemas Unix y Windows) corriendo.
- 6 -
Además de la conexión a otros dispositivos, SSH permite copiar datos de forma
segura (tanto ficheros sueltos como simular sesiones FTP cifradas), gestionar claves
RSA para no escribir claves al conectar a los dispositivos y pasar los datos de cualquier
otra aplicación por un canal seguro tunelizado mediante SSH.
3.5.1.4 Control de acceso a la red: Protocolo RADIUS
La conexión entre el cliente y el servidor se hace vía wi-fi, para garantizar que
sólo los usuarios autorizados tengan acceso a la información se utiliza el protocolo
RADIUS [5].
RADIUS (Remote Authentication Dial In User Service). Es un protocolo AAA
(Autenticación, Autorización y Administración) para aplicaciones como acceso a redes
o movilidad IP.
Muchos ISP (proveedores de acceso a internet por dial up, DSL, cable módem,
ethernet, Wi-Fi, etc) requieren que se ingrese un nombre de usuario y contraseña para
conectarse a la red. Antes de que el acceso a la red sea concedido, los datos de acceso
son pasados por un dispositivo NAS (Network Access Server) sobre un protocolo de
capa de enlace (como PPP, para muchos dial-ups y DSL), luego hacia un servidor
RADIUS sobre un protocolo RADIUS. El servidor RADIUS verifica que esa información
sea correcta usando esquemas de autentificación como PAP, CHAP o EAP. Si es
aceptada, el servidor autorizará el acceso al sistema del ISP y seleccionará una
dirección IP, parámetros L2TP, etc.
3.5.1.5 Base de datos: MySQL
Una vez enviado el archivo y comprobada su integridad se procede a introducir
la información en una base de datos MySQL [6].
MySQL es un sistema de gestión de bases de datos relacional, licenciado bajo la
GPL de la GNU. Su diseño multihilo le permite soportar una gran carga de forma muy
eficiente. MySQL fue creado por la empresa sueca MySQL AB, que mantiene el
copyright del código fuente del servidor SQL, así como también de la marca.
Aunque MySQL es software libre, MySQL AB distribuye una versión comercial
de MySQL, que no se diferencia de la versión libre más que en el soporte técnico que
- 7 -
se ofrece, y la posibilidad de integrar este gestor en un software propietario, ya que de
no ser así, se vulneraría la licencia GPL.
Este gestor de bases de datos es, probablemente, el gestor más usado en el
mundo del software libre, debido a su gran rapidez y facilidad de uso. Esta gran
aceptación es debida, en parte, a que existen infinidad de librerías y otras
herramientas que permiten su uso a través de gran cantidad de lenguajes de
programación, además de su fácil instalación y configuración.
4 Implementación
La computadora MOXA funciona con el sistema operativo Linux bajo el cual se
utilizará lenguaje C para desarrollar los programas antes descritos.
Para el desarrollo de los programas se tomaron en cuenta las siguientes
consideraciones:
MOXA debe de tener la hora y fecha actualizada en todo momento para poder
realizar las operaciones de manera correcta.
La fecha y hora en MOXA serán actualizadas con la hora y fecha del Servidor,
mediante el uso del protocolo NTP (Network Time Protocol).
La transmisión de datos hacia el servidor, se hará mientras el tren se encuentra
en operación, en alguna de las terminales, en donde sea detectado un Access
Point.
Es el Servidor el que se encarga de la inserción de los archivos en la base de
datos y de la separación del archivo .DAT en .A, .B y .C.
La comunicación entre servidor y cliente será mediante el protocolo UDP. El
servidor enviará una trama que constará de una cabecera de 3 bytes y un
campo de 1500 bytes para datos. El primer byte de la cabecera corresponderá
al tipo de mensaje y los 2 bytes restantes indicarán la longitud. El programa
servidor responderá de acuerdo al tipo de solicitud. Las tramas UDP tienen la
siguiente forma:
5.
6.
Tipo longitud Mensaje (si se requiere)
- 8 -
4.1 El cliente
El programa cliente se ejecutará en MOXA y tendrá las funciones ya vistas en el
apartado 2.1. El autómata del programa consta, entonces, de siete estados: NTP,
ESTASVIVO, VERIFICA, NTP, SCP, INSERTMYSQL y ESPERA. A continuación se hace una
descripción de cada estado y las funciones o procedimientos asociados. El estado
inicial es NTP.
En la siguiente figura se muestra un diagrama del autómata de transmisión.
Figura 1. Diagrama del autómata de transmisión
4.1.1 Estado NTP
Al iniciar el programa MOXA intentará establecer una conexión con el servidor,
la manera de verificar esto es con la función NTPdate(), esta función intenta actualizar
la fecha y hora de MOXA a través del protocolo NTP, usando al servidor central como
- 9 -
servidor NTP de estrato 2. La función NTPdate() devuelve uno de dos posibles
resultados:
[0]: si la hora no se pudo actualizar, asumimos entonces que no hay ningún
Access Point cerca y por consiguiente no podemos establecer comunicación con el
servidor. En este caso el programa entrará en un ciclo. Repitiendo el estado NTP hasta
lograr la comunicación.
[1]: si la hora se actualizó correctamente, MOXA tiene comunicación con el
servidor y pasa al siguiente estado ESTASVIVO.
4.1.2 Estado ESTASVIVO
El cliente verificará que el programa servidor siga funcionando. Para esto se
enviará una trama UDP con el tipo de solicitud (1). Como se ve en la siguiente figura:
La respuesta del servidor es una de dos posibles:
Sin respuesta: Asumimos que el programa servidor dejo de funcionar, de momento la
acción a tomar para esto es que el cliente en MOXA se detenga.
[2]: significa que el programa servidor continúa funcionando y entonces el nuevo
estado es VERIFICA.
4.1.3 Estado VERIFICA:
Una vez seguros del correcto funcionamiento del servidor, verificamos que
haya archivos pendientes por enviar. Los archivos descargados de la caja negra se
guardan en la carpeta /mnt/sd/NoEnviados. Hacemos un escaneo de esa carpeta y
obtenemos uno de dos resultados:
Si no hay archivos por enviar, entonces no hay más que hacer y el nuevo estado
es ESPERA.
Si hay archivos pendientes por enviar tomamos el primero en orden alfabético
y el nuevo estado es MD5.
1 longitud
- 10 -
4.1.4 Estado MD5
Este estado cumple con dos funciones, la primera es verificar si el archivo existe
o no en el servidor, y la segunda es para verificar la integridad de los archivos enviados
mediante SCP; para ello hacemos una petición al servidor del MD5 del archivo, si el
servidor nos responde con un MD5 igual a cero, significa que el archivo no existe en el
servidor y por tanto este deberá ser transmitido. El otro caso posible es que el archivo
ya se encuentre en el servidor, y entonces recibiremos el MD5 del archivo calculado en
el servidor y lo podemos comprobar con el MD5 del archivo almacenado en MOXA.
Para esto se enviará una trama UDP solicitando al servidor el resumen MD5 del archivo
seleccionado en el estado anterior. La trama tiene la siguiente forma:
El cliente entonces compara el MD5 recibido con el del archivo local entonces
se tienen uno de dos resultados:
[1]: Si el MD5 de ambos archivos coincide entonces significa que la
transferencia fue exitosa, el archivo en MOXA se mueve a /mnt/ds/Enviados y el nuevo
estados es INSERTMYSQL.
[0]: Si el MD5 de los archivos no coincide entonces se asume que el archivo no
se encuentra presente en el servidor o se dañó al transferirlo, debemos reenviar el
archivo, por lo tanto el estado es de nuevo SCP.
4.1.5 Estado SCP:
MOXA enviará el archivo seleccionado en el estado anterior al servidor central
vía SCP (Secure CoPy) después de realizada la transferencia es necesario verificar la
integridad del archivo enviado, por tanto el nuevo estado es MD5.
4.1.6 Estado INSERTMYSQL:
Una vez que el archivo se transfirió correctamente MOXA pedirá que se inserte
en la base de datos, para esto enviara una trama UDP con la siguiente forma:
3 longitud Nombre del archivo
- 11 -
Obtenemos una de dos respuestas posibles:
Insertado: El archivo se insertó correctamente en la base de datos, el nuevo estado es
VERIFICA para comprobar que no haya más archivos por enviar.
No insertado: El archivo no pudo insertarse en la base de datos el estado es de nuevo
INSERTMYSQL para intentarlo otra vez.
4.1.7 Estado ESPERA
En este estado solo hacemos una pausa de 30 segundos en el programa,
después de eso el estado es nuevamente NTP.
4.2 El servidor
El programa servidor estará instalado en el servidor central y responderá a las
peticiones del programa cliente, en un principio las solicitudes que atenderá el
servidor serán las numeradas en el apartado 2.2 (más funciones se podrán agregar
posteriormente). A continuación se explican más a fondo estas funciones.
4.2.1 Verificación del correcto funcionamiento.
Como respuesta al mensaje ESTASVIVO el servidor responderá con una trama
como la siguiente:
Lo que indicará que el programa servidor continúa funcionando.
4.2.2 Verificar la integridad del archivo enviado.
Cuando el cliente solicite la verificación del MD5 del archivo, el servidor
responderá con una trama igual a la que sigue:
2 longitud
5 longitud Nombre del archivo
- 12 -
El cliente actuará con base en el valor del MD5
4.2.3 Insertar el archivo enviado en la base de datos MySQL.
Una vez verificado el correcto envío del archivo, El cliente solicitara que el
contenido de tal archivo se inserte en la base de datos MySQL. Entonces el servidor
ejecutara las siguientes acciones:
1. Se usará el procedimiento decodifica() que dividirá al archivo .DAT recibido en
los tres archivos .A, .B y .C.
2. La función init_parametros() obtendrá los datos necesarios para la conexión
con la base de datos MySQL del archivo de texto mysql.txt.
3. La función generaDatosMySQL obtendrá toda la información pertinente del
nombre archivo .DAT y los guardará en el archivo datos.txt.
4. La función insert_dat() insertará el contenido de datos.txt en la base de datos.
5. Se borra el archivo .DAT del servidor central.
6. Se envía a MOXA la siguiente trama UDP para informar al cliente del éxito o
fracaso de la inserción:
4.3 Configuración adicional
Para que los programas funcionen correctamente hay que realizar algunas
configuraciones adicionales en la MOXA y en el servidor central.
• Debe habilitarse la comunicación vía SSH/SCP entre MOXA y el servidor
central sin la necesidad de usar contraseñas.
• Debe instalarse el servidor NTP en el servidor central.
• Debe instalarse y configurarse MySQL server en el servidor central,
además debe crearse la base de datos.
4 longitud MD5 del archivo
6 longitud Insertado/No insertado
- 13 -
A continuación se detallan los procedimientos para lograr los puntos anteriores.
4.3.1 SSH/SCP sin contraseña
SSH proporciona varios métodos de acceso sin contraseña; el que
describiremos aquí se basa en el uso de criptografía de llave pública para identificar a
los usuarios.
En los apartados siguientes explicaremos como generar el par de llaves
(identidades) y como instalarlas en los distintos equipos.
1. Generamos un par de llaves, una pública y una privada. Para eso
ejecutamos en la máquina MOXA:
$ ssh-keygen –t rsa
Obtenemos la siguiente serie de salidas:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Debido a que el sistema de la máquina MOXA es de sólo lectura no podemos
usar el directorio que se ofrece por defecto, así que usamos /etc/config/ssh/id_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
En este paso sólo presionamos enter, ya que establecer una contraseña para las
llaves negaría el objetivo de esta explicación.
Your identification has been saved in /etc/config/ssh/id_rsa
Your public key has been saved in /etc/config/ssh/id_rsa.pub
The key fingerprint is:
6f:c3:cb:50:e6:e9:90:f0:0f:68:d2:10:56:eb:1d:91 usuario@host
- 14 -
Esta última salida nos informa de la ubicación de las llaves.
2. Copiamos la llave pública en los servidores que queramos acceder sin
contraseña. Ejecutamos el siguiente comando:
$ ssh-copy-id –i /etc/config/ssh/id_rsa.pub usuario@direccionIP
Este comando copia el contenido de la llave pública en el archivo de llaves
autorizadas home/usuario/.ssh/authorized_keys. Si no se cuenta con este comando
podemos hacerlo manualmente ejecutando el siguiente comando en la máquina
MOXA:
$ scp /etc/config/ssh/id_rsa.pub usuario@direccionIP:/home/usuario/.ssh
Y entonces concatenamos el contenido del archivo id_rsa.pub al del archivo
authorized_keys con el siguiente comando en el servidor:
$ cat /home/usuario/.ssh/id_rsa.pub >> /home/usuario/.ssh/authorized_keys
Adicionalmente deberemos verificar que el directorio y el archivo de claves
autorizadas sólo se pueden acceder por el usuario, ya que SSH puede ignorar el archivo
si no tiene los permisos adecuados:
$ chmod 0700 home/usuario/.ssh/
$ chmod 0600 home/usuario/.ssh/authorized_keys
3. Modificamos, si es necesario, las siguientes entradas del archivo
/etc/ssh/sshd_config en el servidor:
RSAAuthentication yes
- 15 -
PublicKeyAuthentication yes
AuthorizedKeysFile %h .ssh/authorized_keys
PermitEmptyPasswords yes
Opcionalmente podemos modificar la entrada
PasswordAuthentication no
Esto último evita la entrada vía contraseña al servidor, debe usarse con cuidado
ya que afecta a todos los usuarios y aquellos que no cuenten con la llave pública
perderán el acceso al servidor.
4. Por último agregamos la ruta de la llave privada al archivo
/etc/config/ssh/ssh_config en la máquina MOXA:
IdentityFile /etc/config/ssh/id_rsa
Finalmente modificamos la siguiente entrada en el archivo
/etc/config/ssh/ssh_config en la máquina MOXA:
StrictHostKeyChecking no
Para evitar el tener que teclear “yes” cada vez que nos conectamos con el
servidor.
4.3.2 Configuración de NTP
Usaremos el comando ntpdate en el programa cliente como una forma de
verificar que la máquina MOXA ha logrado establecer una conexión con un access
point. El programa cliente ejecutará ntpdate [2] continuamente, en el momento en
que la hora se actualice querrá decir que se ha establecido la conexión con el servidor
y entonces el autómata del cliente comenzara a funcionar.
- 16 -
4.3.2.1 Configuración del servidor
La máquina MOXA cuenta con ntpd client previamente instalado entonces solo
será necesario instalar el ntp server en la máquina donde se va a ejecutar el servidor.
Para instalar el cliente y el servidor ntp ejecutamos el siguiente comando:
$ apt-get install ntp
Para iniciar el servicio ejecutamos
$ /etc/init.d/ntp restart
No es necesaria mayor configuración, pues solo vamos a utilizar el servidor ntp
y no el cliente.
4.3.2.2 Configuración de la máquina MOXA
El comando ntpdate sincroniza la hora del sistema solicitando la hora en
formato UTC (Universal Time Coordinated) y luego hace la corrección según el valor de
la variable de entorno TZ (time zone), esta variable nos dice la zona horaria, el
desplazamiento con respecto a UTC, si el horario de verano está o no en efecto y
cuándo empieza y termina el horario de verano. En caso de que la hora de la máquina
MOXA sea incorrecta será necesario configurar la variable TZ apropiadamente.
La variable TZ se configura siguiendo el siguiente formato:
TZ=<zona horaria><desplazamiento de UTC><zona de horario de verano>
La variable TZ se configura para la ciudad de México con el siguiente comando:
$ export TZ=CST6CDT,M4.1.0/2,M10.5.0/2
- 17 -
Para no tener que usar el comando cada vez que iniciamos la máquina MOXA
añadimos la línea al archivo /etc/profile
4.3.3 Configuración de MySQL y creación de la base de datos
En este apartado se explica lo relativo a la base de datos MySQL [6] utilizada
por el sistema de descarga de datos de las computadoras embarcadas.
Este apartado no pretende ser un curso completo de MySQL, solo se
describirán conceptos básicos y las instrucciones precisas para instalar MySQL en las
computadoras donde se requiera y para crear la base de datos. En caso de requerir
mayor información referirse al manual.
Algunos conceptos básicos:
• SQL, Structure Query Language (Lenguaje de Consulta Estructurado) es
un lenguaje de programación para trabajar con base de datos relacionales como
MySQL, Oracle, etc.
• MySQL es un interpretador de SQL, es un servidor de base de datos.
• MySQL permite crear base de datos y tablas, insertar datos,
modificarlos, eliminarlos, ordenarlos, hacer consultas y realizar muchas operaciones,
etc., resumiendo: administrar bases de datos.
• Ingresando instrucciones en la línea de comandos o embebidas en un
lenguaje como PHP nos comunicamos con el servidor. Cada sentencia debe acabar con
punto y coma (;).
• La sensibilidad a mayúsculas y minúsculas, es decir, si hace diferencia
entre ellas, depende del sistema operativo, Windows no es sensible, pero Linux sí. Por
ejemplo Windows interpreta igualmente las siguientes sentencias:
> CREATE DATABASE administracion;
> Create DataBase administracion;
Pero Linux interpretará como un error la segunda.
Se recomienda usar siempre mayúsculas para las palabras reservadas del
lenguaje.
- 18 -
4.3.3.1 Instalación
Para instalar MySQL en Ubuntu 10.10 ejecutamos los siguientes comandos:
$ apt-get install mysql
$ apt-get install mysql-server
Una vez instalado hay que asignar una contraseña para que nuestras bases de
datos no sean accesibles a cualquier usuario. Ejecutamos el siguiente comando:
$ mysqladmin –u root –p <contraseña>
4.3.3.2 Creación de la base de datos.
La base de datos que se utiliza en este proyecto consta de 4 tablas:
• STC01: contendrá datos relativos a las líneas del STC.
• STC02: contendrá datos relativos a los trenes.
• STC03: contendrá información relativa a los datos descargados de las
cajas negras.
• STC04: contendrá información de los empleados con acceso a la base de
datos.
Nota: Se anexa un diagrama con las estructuras física y lógica de la base de
datos.
A continuación se describen los pasos para la creación de la base de datos.
Primero accedemos al Shell de MySQL, para eso ejecutamos el siguiente
comando:
$mysql –u root –p
- 19 -
Cuando solicite la contraseña, se ingresa la que se asignó anteriormente.
Para crear la nueva base de datos ejecutamos:
Mysql> CREATE DATABASE stcdb;
Después de crear la base de datos ejecutamos el siguiente comando para
utilizarla:
Mysql> USE stcdb;
Para crear cada tabla de la base de datos se ejecutan los siguientes comandos:
CREATE TABLE STC01(
LNIDLN INTEGER PRIMARY KEY,
LNDESC VARCHAR(20) NOT NULL)ENGINE=INNODB;
CREATE TABLE STC02(
TRIDTR INTEGER PRIMARY KEY,
TRDESC VARCHAR(20) NOT NULL)ENGINE=INNODB;
CREATE TABLE STC03(
DBIDDB INTEGER PRIMARY KEY NOT NULL AUTO_INCREMENT,
DBDATE DATE NOT NULL,
DBEMP VARCHAR(20) NOT NULL,
DBPATH VARCHAR(60) NOT NULL,
LNIDLN INTEGER NOT NULL,
TRIDTR INTEGER NOT NULL,
FOREIGN KEY(LNIDLN) REFERENCES STC01(LNIDLN)
ON DELETE CASCADE,
FOREIGN KEY(TRIDTR) REFERENCES STC02(TRIDTR)
ON DELETE CASCADE)ENGINE=INNODB;
- 20 -
CREATE TABLE STC04(
USIDUS INTEGER PRIMARY KEY NOT NULL,
USNOM INTEGER NOT NULL,
USPASS INTEGER NOT NULL)ENGINE=INNODB;
EXIT
Alternativamente pueden escribirse todas las instrucciones en un archivo de
texto y ejecutarse con el siguiente comando:
Desde la línea de comandos Linux:
$ mysql < nombre_del_archivo.sql
Desde el Shell de mysql:
Mysql> SOURCE nombre_del_archivo.sql
Esto ejecutará todas las instrucciones mysql sucesivamente dejando la base de
datos lista para utilizarse.
Nota: Se adjunta el archivo stcdb.sql con las sentencias para crear la base de
datos.
4.3.3.3 Otras consideraciones.
Debido a la forma en que está estructurada la base de datos, la computadora
embarcada no podrá insertar información en la tabla STC03 a menos que las tablas
STC01 y STC02 contengan datos cargados de antemano, esto para evitar que se
introduzcan datos que hagan referencia a trenes o líneas que no existen o no están
registrados. Dado que se está comenzando con una tabla vacía, una forma fácil de
completarla es creando un archivo de texto que contenga los datos de cada línea, en el
- 21 -
caso de la tabla STC01 o de cada tren en el caso de la tabla STC02, y luego insertando
el contenido del archivo en la tabla mediante una sola sentencia.
Para esto, debería crear un archivo de texto conteniendo un registro por línea,
con cada valor separado por un carácter de tabulación, y dispuestos en el orden en el
cual se especificaron las columnas en la sentencia CREATE TABLE. Por ejemplo, el
registro de la línea 1 en la tabla STC01 se vería de la forma siguiente (el espacio en
blanco entre cada valor es un solo carácter de tabulación):
LNIDLN LNDESC
1 Pantitlán - Observatorio
Para introducir los datos del archivo de texto en la tabla ejecutamos el
siguiente comando desde el shell de mysql:
Mysql> LOAD DATA LOCAL INFILE ruta/archivo_de_texto.txt INTO TABLE
nombre_de_la_tabla;
Si ocurre un error al ejecutar la sentencia, probablemente se deba a que la
instalación de MySQL no tiene habilitada por defecto la capacidad de manejar archivos
locales. Se puede consultar la Sección 5.5.4 del manual [1] para obtener información
sobre cómo cambiar esto.
Cuando lo que se desea es agregar nuevos registros de a uno por vez, la
sentencia INSERT resulta de utilidad. De esta sencilla manera, se suministran valores
para cada columna, dispuestos en el orden en el cual se especificaron las columnas en
la sentencia CREATE TABLE. Supóngase que queremos añadir la línea 12 del metro a la
tabla STC01, lo hacemos ejecutando el siguiente comando:
Mysql> INSERT INTO STC01
-> VALUES (‘12’, ‘Tlahuac – Mixcoac’);
- 22 -
5 Pruebas y resultados
Para la realización de las pruebas se montó la maqueta que se ve en la figura 2.
Figura 2. Maqueta de prueba
La maqueta se compone por una computadora MOXA con el programa cliente
instalado previamente, un emulador de caja negra y par de baterías para alimentarlos.
Las pruebas se realizaron en la línea 4 del metro, donde ya están instalados 4
access points. El servidor se instaló en una computadora en las instalaciones del STC en
Zaragoza.
La prueba consistió en echar a andar los sistemas y después subir a un tren para
recorrer la línea, la descarga debería realizarse en cada estación donde hubiera un
Access point.
La transferencia de archivos se realizó exitosamente. En la figura 3 podemos ver
como se guardaron las ubicaciones de los archivos transferidos en la base de datos.
- 23 -
Figura 3.
En la figura 4 se pueden ver los archivos divididos guardados en el servidor:
Figura 4.
Por último, en la figura 5, podemos ver como los archivos .dat, aun guardados
en la computadora MOXA, se movieron a la carpeta enviados.
- 24 -
Figura 5.
Al momento de escribir este reporte, una versión final del sistema se encuentra
instalada y funcionando en un tren de la línea 1 del STC.
6 Conclusiones y trabajo futuro
La implantación de este sistema en el STC traería múltiples beneficios a los
usuarios, pues permitiría la más pronta detección de fallas o irregularidades en los
trenes pues al poder revisar los datos de forma visual se detectarían las anormalidades
del servicio de forma más pronta y óptima, permitiendo así una más pronta
intervención de los responsables. Facilitaría así mismo el trabajo de los encargados
actuales proporcionándoles una interfaz gráfica de fácil uso, y permitiría establecer
una política para prevención de fallas y no sólo de búsqueda de causas.
A futuro podría ampliarse el alcance de este sistema, implementando una
funcionalidad de envío de alarmas a los encargados correspondientes al detectarse un
evento importante. Así como desarrollar algoritmos de búsqueda en los datos que
permitieran detectar eventos de interés para los encargados sin necesidad de
monitorear constantemente todos los datos.
- 25 -
7 Bibliografía
1. Mariano Vargas, “Extracción de datos de las cajas negras de los trenes del Sistema de Transporte Colectivo”, Reporte Técnico TAMDI, mayo 2011
2. BARRIOS Dueñas, Joel. Configuración y uso de NTP [en línea]. Actualizada: 25/09/2012. [Fecha de Consulta: 14/06/2013]. Disponible en: http://www.alcancelibre.org/staticpages/index.php/como-ntp
3. Funciones criptográficas de Hash [en línea]. Actualizada: N/A [Fecha de consulta 14/06/2013]. Disponible en: http://www.segu-info.com.ar/proyectos/p1_hash.htm
4. SSH Login without password [en línea]. Actualizada: N/A. [Fecha de consulta: 14/06/2013]. Disponible en: http://www.linuxproblem.org/art_9.html
5. DIAZ, Oscar, Servidor de autenticación con FreeRadius, MySQL y DaloRadius en Ubuntu [en línea]. Actualizada: 29/07/2010. [Fecha de consulta: 14/06/2013]. Disponible en: http://www.uees.edu.sv/blogs/gti/?p=654
6. MySQL 5.0 Reference Manual [en línea]. Actualizada: N/A. [Fecha de consulta: 14/06/2013]. Disponible en: http://dev.mysql.com/doc/refman/5.0/es/
top related