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/