Sistema de Seguimiento de Objetos (OTS, teleindicadores)
Sistema de Seguimiento de Objetos (OTS, teleindicadores)
Documentación completa en formato Word: OTS.doc
NOTA: Aquí puedes consultar la documentación antigua
Índice
- 1. Nivel de usuario
- 1.1 Base de datos
- 1.2 Arranque de mind
- 1.3 Arranque del vidi
- 2. Quién habla con quién
- 3. Descripcióin a nivel de programador del sistema
1. Nivel de usuario
A nivel de usuario se tienen las siguietes partes visibles:
- una base de datos (normalmente en .mind/db).
- programas de generación de la base de datos (el mind-db-init)
- el OTS (son los programas que componen el mind, es decir: tetra, mind-balizas2ots, ,mind-tetra2ots, mind-ctc2ots, mind, mind-hub)
- el visualizador del ots (mind-hub, vidi)
- programas de pruebas (test-audio-server).
La relación entre los distintos procesos se puede ver en el siguiente esquema:
El equipo (Servidor de Datos Móviles) en el que se ejecuta el OTS en el metro se llama "datos1_moviles". Se puede acceder a él con sólo ejecutar el script "datos1" desde el equipo "salchicha".
Para ver la ejecución gráfica del MIND hay que exportar el display de datos1_moviles al frontPCI02 con el siguiente comando
export DISPLAY=152.200.169.3:0Después desde nuestro equipo de SICO, nos conectamos por VNC al frontPCI02, que desde la red interna se le conoce como rdsi2 y tiene dirección IP 172.16.1.2
1.1 Generación de la base de datos
La base de datos tiene dos partes, una dinámica, que se crea según van llegando datos de campo, y una estática, que se crea desde unos ficheros de configuración (.CFG).
De la parte dinámica no nos tenemos que preocupar, ya que su creación es totalmente automática.
La parte estática hay que crearla con el mind-db-init. Lo que hace dicho programa es leer los ficheros de configuración del SIV (teleindicadores), en los cuales se definen los circuitos de vía, las estaciones, etc, y meterlas en la base de datos del mind.
Los ficheros que genera son del tipo LNN-static.db
La manera de llamar al programa es la siguiente:
./mind-db-init -z /home/metro/cfg/LinFis01/CfgLinFisica.CFG \ -z /home/metro/cfg/LinFis03/CfgLinFisica.CFG \ -z /home/metro/cfg/LinFis06/CfgLinFisica.CFG \ -z /home/metro/cfg/LinFis07/CfgLinFisica.CFG \ -z /home/metro/cfg/LinFis08/CfgLinFisica.CFG \ -z /home/metro/cfg/LinFis09/CfgLinFisica.CFG \ -z /home/metro/cfg/LinFis10/CfgLinFisica.CFG \ -z /home/metro/cfg/LinFis11/CfgLinFisica.CFG \ -z /home/metro/cfg/LinFis12/CfgLinFisica.CFG |
1.2 Arranque de mind
Está explicado de manera correcta en la documentación para programadores.
Sin embargo, en dicha documentación no se menciona al tetra. Para que el mind-tetra2ots funcione, hay que tener arrancado el tetra, que es un demonio aparte y suministra información al mind-tetra2ots.
./tetra & ./mind-ctc2ots -o 5336 & ./mind-tetra2ots -o 5337 & ./mind-balizas2ots -o 5338 & ./mind-hub -i 5336 -i 5337 -i 5338 |
1.3 Arranque de vidi
El vidi está diseñada para correr en la misma máquina que el mind. Sin embargo esto no es lo habitual, y para ello se usa el mind-hub.
En caso de correr en una máquina diferente del datos1, hay tener arrancado un mind-hub de manera que la base de datos de datos1 esté replicada en la máquina local, y así mantener en dicha máquina una base de datos actualizada y usable.
Hay que tener en cuenta que el vidi abre conexiones tanto con el mind (o mind-hub) como con tetra.
./mind-hub ...params... & ./vidi ...params... |
2. Quién habla con quién
2.1 Balizas
El software de balizas (Mondragón) abre un socket contra el mind-balizas2ots
2.2 CTC
El mind-ctc2ots abre una conexión contra el serv_siv, que a su vez obtiene los datos del CTC.
2.3 SDR-TETRA
El tetra abre una conexión contra el SDR o ShortDataRouter (Amper).
2.4 Servidor de Audio
El software del servidor de audio (AudioServer) abre una conexión contra tetra
2.5 mind-hub
El mind-hub puede abrir una conexión contra tantos elementos que soporten su protocolo como se quieran. En general sólo se usará de dos maneras:
- Centralizar los eventos de mind-*2ots: El mind-hub abre una conexión contra cada uno de los mind-*2ots.
- Replicar la base de datos en otra máquina: El mind-hub abre una conexión contra otro mind-hub que se ejecuta en una máquina diferente.
2.6 vidi
El vidi se conecta con:
- El mind-hub residente en su máquina
- El tetra remoto
3. Descripcióin a nivel de programador del sistema
Mensajes
Los mensajes que se pasan entre los mind-*2ots y el mind-hub o entre el mind-hub y el vidi se llaman "eventos del ots", y están definidos en ots-event.c
La base de datos
El sistema está orientado a mantener una base de datos en tiempo real.
Dicha base de datos está guardada en formato Berkeley-DB v4 (base de datos sin servidor central, sino compartida a nivel de ficheros).
La base de datos es compartida, de manera que varios procesos pueden abrirla y realizar actualizaciones (transacciones) sobre ella, de forma atómica.
Visitantes
Hay un objeto (visitor) que es usado para:
- recorrer la base de datos
- actualzarla
- linealizarla (para guardar un volcado)
- ...
Para poderla recorrer se ayuda de los objetos visitor. Para comprender más o menos como funciona eso, ver linea-db-dump.c
El interfaz de usuario
El vidi es el interfaz del usuario.
Para mostrar las cosas se ayuda de dos visitantes específicos para el vidi: set-glade y get-glade.
A su vez, estos usan los ui-filters, que transforman los resultados de los visitantes por medio de más consultas a la base de datos para que en vez de aparece identificadores aparezcan nombres (p. ej. en vez del identificador numérico de andén, que aparezca el nombre de éste).
Datos en la base de datos dinámica
Guarda la composición de trenes tanto según le llega por
- balizas
- tetra
- CTC
y están jerarquizadas (balizas es más fiable que tetra que a su vez es más fiable que CTC).
Tetra
Es un módulo aparte, que es usado por
- vidi directamente para poder mandar órdenes de tetra (p.ej. cambiar el texto de un teleindicador del tren)
- mind-tetra2ots para obtener la información que necesita para el mind, tanto del SDR como del AudioServer.
La versión utilizada es la 1.4.6, con un parche que hace:
- corrige un memory-leak (faltaba un free())
- para que las notificaciones se puedan tomar como atómicas, encierra cada notificación entre BEGIN...COMMIT, de manera que el mind-tetra2ots sepa el dato completo que tiene que meter en la base de datos en una sola transacción (atómica).
- Define un monitor tetra que manda tanto los eventos SDR como los del servidor de audio (antes sólo mandaba los del SDR, los del servidor de audio no tenían ,monitor específico).
OTS.doc