Embed Size (px)
Citation preview
SISTEMA DELFOS
AUTOR: Ruben Casas García PROFESOR: Carles Aliagas Dirección de correo: [email protected]
ÍNDICE
0. DESCRIPCIÓN DE LA EMPRESA............................................................................................4 1. UBICACIÓN DEL PROYECTANTE DENTRO DE LA EMPRESA.........................5 2. INTRODUCCIÓN .............................................................................................................................5 3. ARQUITECTURA ..............................................................................................................................6
3.1 Diagrama general ..........................................................................................................................6 3.2 Análisis y diseño funcional ........................................................................................................8
3.2.1 Recogida de requerimientos.............................................................................................9 3.2.2 Diagrama de actividad .......................................................................................................9 3.2.3 Diagrama de secuencia ................................................................................................... 10 3.2.4 Diagrama de bases de datos .......................................................................................... 11
3.3 Dispositivo Delfos .................................................................................................................... 12 3.3.1 Diagrama general del dispositivo ................................................................................ 13
3.4 Servidor de procesamiento de datos.................................................................................... 15 3.4.1 Arquitectura del servidor ............................................................................................... 15 3.4.2 Gestor de Base de datos................................................................................................. 15 3.4.3 Instalación y configuración de la base de dato........................................................ 16 3.4.4 Tuneado de la base de datos ......................................................................................... 17 3.4.5 Estructura de la base de datos ...................................................................................... 20
3.5 Servidor web ............................................................................................................................... 25 4. COMUNICACIÓN entre el dispositivo y el servidor de datos.......................................... 26
4.1 Protocolo UDP .......................................................................................................................... 26 4.2 Formato de los frames ............................................................................................................. 27
4.2.1 Tramas de datos................................................................................................................ 28 4.3 Proceso de recepción de datos: LISTENER .................................................................... 29
4.3.1 Inicialización ...................................................................................................................... 29 4.3.2 Tratamiento inicial de la trama de datos ................................................................... 32 4.3.3 Procesado de la trama. .................................................................................................... 34 4.3.4 Tipos de datos enviados................................................................................................. 39 4.3.5 Variables.............................................................................................................................. 39
4.4 Envío de parámetros: RequestProcesor ............................................................................. 41 5. PROCESADO DE DATOS ......................................................................................................... 43
5.1 Procesado de la información a tiempo real (DECCX) .................................................. 44 5.1.1 Decodificación de Alarmas ........................................................................................... 46 5.1.2 Alarmas de control de flotas ......................................................................................... 47 5.1.3 Decodificación de variables .......................................................................................... 48 5.1.4 Decodificación de histogramas .................................................................................... 53
6. PROCESOS BACKGROUND.................................................................................................... 56 En el sistema existen una serie de procesos involucrados en el tratamiento de los datos del sistema, o para tareas de monitorización y registro de logs. En el siguiente esquema podemos ver los procesos implicados: .................................................................................................. 56
6.1 Parametrización de los dispositivos ..................................................................................... 57 6.1.1 Proceso de Parametrización.......................................................................................... 59 6.1.2 Proceso de Borrado ......................................................................................................... 61
6.2 Resolución de nombres ........................................................................................................... 62 6.3 Calibración ................................................................................................................................... 63
7. WEB DELFOS .................................................................................................................................. 66
7.1 Resumen general del aplicativo ............................................................................................. 66 7.2 Seguridad ...................................................................................................................................... 67 7.3 Descripción Funcional ............................................................................................................. 67
7.3.1 Comunes ............................................................................................................................. 67 7.3.2 Principal............................................................................................................................... 70 7.3.3 Administración.................................................................................................................. 71 7.3.4 ObjectManager.................................................................................................................. 74 7.3.5 Control de Flotas.............................................................................................................. 76 7.3.6 Análisis de rendimiento .................................................................................................. 80 7.3.7 Diagnosis............................................................................................................................. 82
7.4 Plataforma.................................................................................................................................... 84 7.4.1 Utilidades de terceros...................................................................................................... 84 7.4.2 Frameworks ....................................................................................................................... 84 7.4.3 Desarrollo y construcción de herramientas.............................................................. 84
8. MANUALES ...................................................................................................................................... 85 9. RECURSOS UTILIZADOS ......................................................................................................... 86 10. APORTACIONES DEL PROYECTO A LOS CONOCIMIENTOS DEL ALUMNO...................................................................................................................................................... 87
10.1 Conocimientos técnicos .......................................................................................................... 87 10.2 Planificación y fases de desarrollo ........................................................................................ 88
11. APORTACIONES DE LOS ESTUDIOS REALIZADOS AL PROYECTO........ 90 12. CONCLUSIÓN ............................................................................................................................. 91
0. DESCRIPCIÓN DE LA EMPRESA
Divas Technology es una empresa de servicios energéticos española concebida para dar soluciones al sector del transporte con el objetivo de disminuir el consumo de gasoil y mejorar la seguridad de las personas.
Todo esto se consigue mediante la combinación de dos factores.
1. Tecnología utilizada
La empresa dispone de un dispositivo desarrollado que se conecta a la electrónica de un vehículo pesado y obtiene toda la información del ordenador a bordo, enviándola a un servidor de datos donde se procesa y almacena. Una vez procesada los usuarios pueden revisar toda esta información a través de un entorno web.
2. Un plan de auditoría en la empresa para optimizar el consumo de carburante.
Con los datos obtenidos a partir del dispositivo se elabora un plan de seguimiento y formación a los conductores de la empresa con el único objetivo de mejorar la conducción y en consecuencia reducir los costes de la empresa.
1. UBICACIÓN DEL PROYECTANTE DENTRO DE LA EMPRESA
Inicialmente fui contratado como programador encargado de desarrollar toda la interfaz web utilizada por los clientes.
Debido a que durante mi etapa inicial el proyecto estaba en fases de desarrollo he podido participar en numerosos cambios, tanto estructurales, como cambios de especificaciones del producto, llegando a tener un profundo conocimiento del sistema.
Finalmente ocupé el cargo de Ingeniero de sistemas, realizando tareas de analista en las nuevas mejoras del producto. Todo esto comporta el estudio de los requisitos, diseño y análisis de estas nuevas aplicaciones o funcionalidades.
2. INTRODUCCIÓN
El producto Delfos se define como un sistema para monitorizar los datos de vehículos pesados (camiones o autobuses), con el objetivo de controlar, evaluar y gestionar la flota de dichos vehículos.
Esta información se obtiene mayoritariamente de la lectura del bus CAN del vehículo y módulos externos a éste (como el GPS integrado o el tacó grafo del vehículo). Esta lectura se realizada por un dispositivo desarrollado enteramente por la propia empresa.
Una vez instalado el dispositivo Delfos en el vehículo, los datos son enviados a un servidor, donde son procesados y accesibles para el cliente desde una aplicación Web alojada en un servidor propio.
El objetivo principal del proyecto consiste en mejorar el principal coste para las empresas que utilizan este tipo de transporte, el consumo de gasoil. Para conseguirlo el sistema en si no produce ningún beneficio instantáneo. Para obtenerlo Divas technology dispone de una herramienta de administración y un proceso de auditoría definido que consiste en monitorizar los datos de una forma más exhaustiva, una evaluación y en consecuencia formaciones a los conductores, todo ello aplicado a la flota de forma continuada.
3. ARQUITECTURA
3.1 Diagrama general
A grandes rasgos, el sistema se compone de tres partes bien diferenciadas:
1. Dispositivo Delfos 2. Servidor de procesamiento de datos 3. Servidor Web
En el siguiente gráfico podemos apreciar la arquitectura general del sistema y los
componentes que la constituyen:
Servidor de datos
Red Interna
Servidor UI
Internet
InternetLaptop
El objetivo o funciones principales de cada una de las partes del sistema es el siguiente:
Dispositivo
Lectura de la información del can y dispositivos externos del vehículo. Pre-procesado de la información obtenida y almacenaje interno. Envío de datos.
Servidor de datos:
Recepción de la información e inserción de los datos en una base de datos auxiliar
(proceso Listener) Procesamiento y guardado en la base de datos de producción (proceso Deccx) Post-procesado de la información (proceso per_variables_diarias y procesos nocturnos)
para facilitar la visualización de ésta a través de las aplicaciones web. Servidor de aplicación de usuario
Aplicaciones web para visualizar y gestionar la información de los vehículos. Procesos de control de datos, parametrización y servicios web.
En el siguiente diagrama podemos ver que procesos forman cada una de las partes
anteriormente mostradas.
Listener
Producción Test_com
Decxx
Aplicación de usuarioAplicación de Administración
Request
Process
Wireless
Update
Parametriza
ción
Resolución
de nombres
Servicios
Web
Procesos
nocturnos
Dispositivo
Servidor de procesamiento de datos
Servidor Web
3.2 Análisis y diseño funcional
Debido a la complejidad del sistema y al haber interactuadas tantas partes de diferente tecnología, se tuvo que trabajar en el diseño de un procedimiento para realizar las especificaciones, análisis y diseño de las mejoras implementadas en el producto.
Para realizar el análisis se decidió crear un documento con un diagrama de caso de Uso acompañado de un documento descriptivo.
A partir del diagrama anterior, que básicamente describe el entorno, las posibilidades que tiene el usuario de interactuar con nuestro sistema, y los resultados obtenidos, se comenzará el análisis de la siguiente manera:
1. Creación de un diagrama de Estados (diagrama de actividad o de estados), de forma global para ver a primera vista el trabajo a realizar.
2. Una vez separado el trabajo se creará un diagrama de secuencia para ver cómo
interactúan los diferentes entornos de nuestro sistema. 3. Definido esto se creará otro diagrama de actividades que describa de forma más
detallada el funcionamiento, estados y traspaso de información de un sistema a otro definido en el diagrama anterior. Esto nos dará una idea bastante clara de que y de cómo se relacionan todas las partes.
4. Para aclarar mas el punto anterior de puede definir un diagrama estático para definir
restricciones entre las diferentes partes.
Acabada esta parte el trabajo a realizar por cada parte quedará bastante claro. Para cada una de las partes se tendría que definir lo siguiente: 1. Diagrama de estados del trabajo a realizar.
2. Diagrama de clases
3. Diagrama de la base de datos (esté será compartido entre la parte del UI y la de
procesamiento de datos).
4. Para la parte del UI es interesante hacer un pequeño boceto con la parte grafica si se necesita, ya que casi todos los informes de nuestro sistema funcionan de forma similar.
3.2.1 Recogida de requerimientos
Para la recogida de requerimientos realizaremos dos documentos principales. Un diagrama de casos de uso acompañado de un fichero descriptivo indicando las funcionalidades.
Este es el patrón usado para el caso de uso:
Interacción usuario hacia
UI
Informacion
Notas
Opciones del
usuario
Devolución de información
de UI hacia usuario
Notas
Valores resultantes
Titulo
{ Nota1}
Usuario
Funcionalidad
Notas
3.2.2 Diagrama de actividad
Este diagrama muestra el flujo de trabajo desde el punto de inicio hasta el punto final detallando muchas de las rutas de decisiones que existen en el progreso de eventos contenidos en la actividad. Estos también pueden usarse para detallar situaciones donde el proceso paralelo puede ocurrir en la ejecución de algunas actividades. Los Diagramas de Actividades son útiles para el Modelado de Negocios donde se usan para detallar el proceso involucrado en las actividades de negocio.
Obtener variables dispositivo
Envio Información
Recibir Informacion
Procesado Informacion
Guardar Info en la BD fieldtest
3.2.3 Diagrama de secuencia
Este diagrama muestra los objetos como líneas de vida a lo largo de la página y con sus interacciones en el tiempo representadas como mensajes dibujados como flechas desde la línea de vida origen hasta la línea de vida destino. Los diagramas de secuencia son buenos para mostrar qué objetos se comunican con qué otros objetos y qué mensajes disparan esas comunicaciones. Este diagrama no está pensado para mostrar lógica de procedimientos complejos.
La línea de vida representa un participante individual en un diagrama de secuencia y los mensajes se muestran como flechas. Los mensajes pueden ser completos, perdidos o encontrados; síncronos o asíncronos: llamadas o señales.
Para nuestro sistema este tipo de diagramas son útiles debido a las diferentes partes que forman nuestro sistema. De esta forma podemos observar de una forma global el funcionamiento del procedimiento.
TranScan Delfos ServidorUI
NOTA
NOTA
INTERACCIÓN
NOTA
Pedir info BD
Devolver Info BD
{}
3.2.4 Diagrama de bases de datos
El Diagrama de Clase presenta un mecanismo de implementación neutral para modelar los aspectos de almacenado de datos del sistema. Las clases persistentes, sus atributos y relaciones pueden ser implementados directamente en una base de datos orientada a objetos. Aun así, en el entorno de desarrollo actual, la base de datos relacional es el método más usado para el almacenamiento de datos.
Este diagrama de clase se usa para modelar la estructura lógica de la base de datos, independientemente de si es orientada a objetos o relacional, con clases representando tablas, y atributos de clase representando columnas. Si una base de datos relacional es el método de implementación escogido, entonces el diagrama de clase puede ser referenciado a un diagrama de relación de entidad lógico. Las clases persistentes y sus atributos hacen referencia directamente a las entidades lógicas y a sus atributos; el modelador dispone de varias opciones sobre cómo inferir asociaciones en relaciones entre entidades. Las relaciones de herencia son referenciadas directamente a súper-sub relaciones entre entidades en un diagrama de relación de entidad (ER diagrama).
comHistograms
PK hsid
delfos_code
datetime
parameters
utc
codigo_dallas
HistCond
PK,FK1 hist_con_id
dimension
na
his_code
con_id
veh_id
datime
fecha
hist_cond_id
HistVeh
PK,FK1 hist_veh_id
dimension
na
his_code
con_id
veh_id
datime
fecha
hist_cond_id
HistCondValores
PK hist_cond_id
PK posx
PK posy
valor
HistVehValores
PK hist_cond_id
PK posx
PK posy
valor
DecDefHistogramas
PK,FK1,FK2 hist_code
descripcion
dim_x
dim_y
rangos_x
rangos_y
tipo_formula
pun_disponible_una_fila
escala
explicacion
eje_x
eje_y
id_tra
id_idioma
3.3 Dispositivo Delfos
El cometido del dispositivo Delfos es monitorear toda la información del estado y comportamiento del vehículo a través del bus can y dispositivos externos, y mandar estos datos por telemetría a un servidor, para que posteriormente puedan ser procesados y obtener conclusiones referentes al consumo de combustible, posicionamiento, y gestión de la flota.
Para conseguir este objetivo, el dispositivo Delfos tiene las siguientes fuentes de
información:
1. Conexión al Bus CAN del motor. 2. Posicionamiento GPS. 3. Conexión RS-232 al tacó grafo. 4. Lector de tarjetas de conductor (sistema identificación conductor). 5. Lector de botones Dallas (sistema identificación conductor). 6. Señal de encendido del motor.
Mediante el procesado de los datos procedentes de las anteriores fuentes, el dispositivo
manda (mediante una conexión GSM-GPRS) los siguientes datos al servidor:
Identificación del conductor. La identificación de un conductor puede ser de 3 tipos:
o Conductor estático o Tacó grafo digital o Botón dallas
Fecha y hora. Histogramas de conductor.
Información del tiempo desglosada en estados de una variable separada en rangos.
Histogramas de vehículo. Lo mismo pero para variables relativas al vehículo.
Alarmas. Variables. Una muestra de las más importantes:
o Posición geográfica (latitud, longitud altura y dirección). o Señales de encendido y apagado del motor. o Tiempos de conducción, movimiento y ralentí. o Consumos de combustible (total y al ralentí). o Odómetro. o Velocidad.
3.3.1 Diagrama general del dispositivo
El siguiente diagrama muestra de forma general todos los componentes (tanto externos como internos) que forman el dispositivo Delfos:
[GPRSFrame]
[Fra
mes
]
DIAGNOSTIC
GPS MODULE
CONTINUOUS VALUES
MONITORING
POIPUNTO-PASO
ALARMS
TABLE INPUT VARIABLES
TABLE STATES
BLACK BOX
SENDING MANAGEMENT
TRANSMITTER AND RECEIVER
1G
PR
SSMS
Software Normal Flowchart in device
J1939 HISTOGRAM PROCESSING AND
STORAGE
CALCULATED HISTOGRAMS
INSTANT LOCATION AND
STORAGE
ALARMS
GRAPHICAL ANALYSIS
EVENT COUNTERS
INTERNAL DATA
ALARM GENERATION
VARIABLE ESTIMATION
ALARM DEFINITIONG
PS
dat
a, U
TC SINGLE VARIABLES MODULE
SINGLE VARIABLES
HISTOGRAM STORAGE AND
SENDING
HISTOGRAMS STORED PERMANENTLY
TACHOGRAPH
CAN BUS
HISTOGRAMS
GSM/GPRS
CARD DRIVER READER
DALLAS CODE READER
Instant location and storage:
Calcula la posición actual cada segundo y la guarda en las tablas dataGPS y tableInputVariables. Compara la posición actual con una tabla con diferentes áreas geográficas para generar las alarmas de POI (si se ha pasado por un área geográfica de interés).
Continuous values monitoring:
Almacena los datos que entran al dispositivo en el array table_input_variables, en el que cada elemento (de 16 bits) representa una variable. El estado en el que se encuentra el vehículo, se memoriza mediante la tabla table_states, en el que cada elemento (de 8 bits) representa un estado.
Single variables module:
Su función es el cálculo de variables y a los 5 minutos preparar la tabla de variables para ser mandadas al servidor.
Alarm generation:
Las variables se evalúan según una prioridad prefijada. Las que han superado un v alor umbral son guardadas en la tabla de alarmas.
Black Box:
El blackBoxData se trata de una tabla que almacena un máximo de 50 elementos por cada una de las variables. Estas son empleadas para cálculos de integración con el tiempo.
Graphical analysis:
Máquina de estados necesaria para el cálculo de algunas variables e histogramas. Histogram processing and storage:
Cada 5 milisegundos se actualizan los valores guardados en los histogramas que se encuentran en la RAM (histogramas de tiempo e histogramas de distancia).
Histogram storage and sending:
Si hay un cambio de día, si se produce un cambio de conductor o si ha pasado más de tres horas, los histogramas se escalan y graban de la memoria RAM a la memoria flash externa para ser mandados posteriormente.
Sending management:
Envía las variables, las alarmas y los histogramas en tramas que van en paquetes UDP.
3.4 Servidor de procesamiento de datos
El servidor de procesamiento de datos es un servidor con un sistema operativo Linux instalado, que aloja una base de datos y una serie de procesos (en constante ejecución y periódicos).
Estos procesos son los encargados tanto de recibir y controlar toda la información enviada por los dispositivos, como la de su control, procesado, y envío de parámetros y actualizaciones del firmware. Toda esta información se obtiene o inserta a partir de la base de datos.
Cuando finalmente la información es totalmente procesada se deja a disposición de las aplicaciones web para su visualización y gestión.
3.4.1 Arquitectura del servidor
Este servidor funciona bajo un sistema operativo Red Hat v5. En él hay instalado un gestor de base de datos PostgreSql 8.0. La configuración del mismo sigue la instalación para modo desarrollador proporcionada por el asistente del sistema operativo.
El cometido de este servidor, tal como hemos dicho antes, es recibir toda la información de
los dispositivos, procesarla y almacenarla. Para ello consta de dos bases de datos, una auxiliar, en la que se van guardando todos los registros que van entrando a modo de Log, y otra de producción, en la que solo se encuentra la información procesada.
3.4.2 Gestor de Base de datos
PostGreSQL es un sistema de gestión de bases de datos objeto-relacional (ORDBMS)
basado en el proyecto POSTGRES, de la universidad de Berkeley. El director de este proyecto es el profesor Michael Stonebraker, y fue patrocinado por Defense Advanced Research Projects Agency (DARPA), el Army Research Office (ARO), el National Science Foundation (NSF), y ESL, Inc.
PostGreSQL es una derivación libre (OpenSource) de este proyecto, y utiliza el lenguaje SQL92/SQL99, así como otras características que comentaremos más adelante.
Fue el pionero en muchos de los conceptos existentes en el sistema objeto-relacional
actual, incluido, más tarde en otros sistemas de gestión comerciales. PostGreSQL es un sistema objeto-relacional, ya que incluye características de la orientación a objetos, como puede ser la herencia, tipos de datos, funciones, restricciones, disparadores, reglas e integridad transaccional. A pesar de esto, PostGreSQL no es un sistema de gestión de bases de datos puramente orientado a objetos.
Las características de este gestor son las siguientes:
1. Implementación del estándar SQL92/SQL99. 2. Soporta distintos tipos de datos: además del soporte para los tipos base, también soporta
datos de tipo fecha, monetarios, elementos gráficos, datos sobre redes (MAC, IP...), cadenas de bits, etc. También permite la creación de tipos propios.
3. Incorpora una estructura de datos array.
4. Incorpora funciones de diversa índole: manejo de fechas, geométricas, orientadas a operaciones con redes, etc.
5. Permite la declaración de funciones propias, así como la definición de disparadores. 6. Soporta el uso de índices, reglas y vistas. 7. Incluye herencia entre tablas (aunque no entre objetos, ya que no existen), por lo que a
este gestor de bases de datos se le incluye entre los gestores objeto-relacionales. 8. Permite la gestión de diferentes usuarios, como también los permisos asignados a cada
uno de ellos.
3.4.3 Instalación y configuración de la base de dato
El software puede descargarse desde la siguiente URL: http://www.postgresql.org/ftp En la misma página podremos seleccionar la versión que queramos. Para la instalación descomprimiremos el fichero descargado, y en el mismo directorio ejecutaremos los siguientes comandos:
bz2 archive: tar –xvjf postgresql-8.2.4.tar.bz2 ./configure –prefix /inst-directory/ Gmake Gmake install ‘crearemos los directories que alojen la base de datos
mkdir /inst_directory/db mkdir /inst_directory/db/pgsql mkdir /inst_directory/db/pgsql/data cd /inst_directory/db/pgsql chown postgres:postgres data
Una vez realizados estos pasos procedemos a la creación del gestor de la base de datos:
‘Nos logeamos con el usuario postgres
# su postgres ‘creamos la base de datos cd /inst_directory/bin ./initdb –D /inst_directory/db/pgsql/data ‘inicializamos y arrancamos la base de datos ./postmaster –D /inst_directory/db/pgsql/data & /etc/init.d/postgresql8 start
Y seguidamente creamos los usuarios y las bases de datos a utilizar: ‘creamos el usuario cd /inst_directory/bin
su –c “./createuser –P xavi” postgres ‘creamos la base de datos con la condificación UTF -8 cd /inst_directory/bin
su –c “./createdb –E UTF8 fieldtest” postgres
Una vez realizados estos pasos agregamos la funcionalidad dblink para copiar registros entre dos o más bases de datos. ‘Creamos el fichero dblink.sql:
cd /postgresql-8.2.4-source/contrib/dblink gmake all gmake install ‘Instalación dblink cd /inst_directory/bin su –c “./psql fieldtest < /postgresql-8.2.4-source/contrib/dblink/dblink.sql” postgres
3.4.4 Tuneado de la base de datos Para tunear la base de datos tenemos que ir al siguiente fichero de configuración: /inst_directory/db/pgsql/data/posrgresql.conf En este fichero podremos configurar temas de memoria, logs, conexiones, etc. Cada uno de los parámetros contiene un pequeña descripción que indica la funcionalidad. En nuestro caso el contenido del fichero es el siguiente:
# -------------------------------------------------------------------------- # PostgreSQL configuration file # -------------------------------------------------------------------------- # #--------------------------------------------------------------------------- # FILE LOCATIONS #--------------------------------------------------------------------------- listen_addresses = '*' # what IP address(es) to listen on; # comma-separated list of addresses; # defaults to ' localhost', ' *' = all # (change requires restart) port = 5432 # (change requires restart) max_connections = 1500 # (change requires restart) #--------------------------------------------------------------------------- # RESOURCE USAGE (except WAL) #--------------------------------------------------------------------------- # - Memory - shared_buffers = 256MB # min 128kB or max_connections*16kB # Note: increasing max_prepared_transactions costs ~600 bytes of shared memory # per transaction slot, plus lock space (see max_locks_per_transaction). work_mem = 2MB # min 64kB maintenance_work_mem = 128MB # min 1MB # Note: increasing max_prepared_transactions costs ~600 bytes of shared memory # per transaction slot, plus lock space (see max_locks_per_transaction). work_mem = 2MB # min 64kB maintenance_work_mem = 128MB # min 1MB
max_stack_depth = 4MB # min 100kB # - Free Space Map - max_fsm_pages = 600000 # min max_fsm_relations*16, 6 bytes each # (change requires restart) # - Cost-Based Vacuum Delay - vacuum_cost_delay = 100 # 0-1000 milliseconds vacuum_cost_limit = 500 # 0-10000 credits #--------------------------------------------------------------------------- # WRITE AHEAD LOG #--------------------------------------------------------------------------- # - Settings - fsync = on # turns forced synchronization on or off commit_delay = 500 # range 0-100000, in microseconds # - Checkpoints - checkpoint_segments = 20 # in logfile segments, min 1, 16MB each checkpoint_warning = 60s # 0 is off #--------------------------------------------------------------------------- # QUERY TUNING #--------------------------------------------------------------------------- # - Planner Cost Constants - random_page_cost = 2.5 # same scale as above effective_cache_size = 512MB # - Other Planner Options - default_statistics_target = 200 # range 1-1000 #--------------------------------------------------------------------------- # ERROR REPORTING AND LOGGING #--------------------------------------------------------------------------- # This is used when logging to stderr: redirect_stderr = on # Enable capturing of stderr into log # files # (change requires restart) # These are only used if redirect_stderr is on: log_directory = ' /var/log/postgres8/' # Directory where log files are written # Can be absolute or relative to PGDATA log_filename = 'postgresql8_%a.log' # Log file name pattern. # Can include strftime() escapes log_truncate_on_rotation = on log_rotation_age = 1440 # Automatic rotation of logfiles will # happen after that time. 0 to # disable. log_rotation_size = 10MB # Automatic rotation of logfiles will # happen after that much log # output. 0 to disable.
# - When to Log - log_min_messages = error # Values, in order of decreasing detail: log_error_verbosity = verbose # terse, default, or verbose messages log_line_prefix = '%t' # %t = timestamp (no milliseconds) #--------------------------------------------------------------------------- # RUNTIME STATISTICS #--------------------------------------------------------------------------- stats_start_collector = on # needed for block or row stats stats_row_level = on #--------------------------------------------------------------------------- # AUTOVACUUM PARAMETERS #--------------------------------------------------------------------------- autovacuum = on # enable autovacuum subprocess? # 'on' requires stats_start_collector # and stats_row_level to also be on autovacuum_naptime = 5min # time between autovacuum runs autovacuum_vacuum_threshold = 1000 # min # of tuple updates before # vacuum autovacuum_analyze_threshold = 500 # min # of tuple updates before #--------------------------------------------------------------------------- # CLIENT CONNECTION DEFAULTS #--------------------------------------------------------------------------- # - Locale and Formatting - datestyle = ' iso, mdy' client_encoding = LATIN1 # actually, defaults to database # encoding # These settings are initialized by initdb -- they might be changed lc_messages = 'es_ES.UTF-8' # locale for system error message lc_monetary = 'es_ES.UTF-8' # locale for monetary formatting lc_numeric = 'es_ES.UTF-8' # locale for number formatting lc_time = 'es_ES.UTF-8' # locale for time formatting #--------------------------------------------------------------------------- # LOCK MANAGEMENT #---------------------------------------------------------- ----------------- deadlock_timeout = 5s
Cuando cambiamos la configuración de memoria del postgreSql debemos cambiar el valor shmmax del servidor. Para determinar el máximo tamaño del segmento de memoria hay que realizar las siguientes acciones: # cat /proc/sys/kernel/shmmax El límite del valor de memoria compartida para SHMMAX puede ser cambiado en el fichero de sistema sin reiniciar, mediante la siguiente instrucción: # echo 536870912 > /proc/sys/kernel/shmmax Pero también se puede usar sysctl(8) para cambiarlo: # sysctl -w kernel.shmmax=536870912 Para que el cambio sea permanente, añadimos la siguiente linea en el fichero “/etc/sysctl.conf”. Este fichero es usado durante la carga del proceso. # echo "kernel.shmmax=536870912 " >> /etc/sysctl.conf
3.4.5 Estructura de la base de datos
Disponemos de dos bases de datos:
1. Base de datos de Producción FiedProd Es la base de datos principal, en esta se guardan los datos que van llegando de los dispositivos y los datos tratados por los procesos.
2. Base de datos TestCom Esta base de datos guarda únicamente los datos que envían los dispositivos sin procesar por el servidor. Estos datos se guardan semanalmente para posibles diagnósticos.
3.4.5.1 Base de datos de producción
La estructura de la base de datos podemos dividirla en secciones, cada una destinada a una parte del sistema.
1. Tablas de recepción de datos y control
2. Tablas de administración
3. Tablas de datos control de flotas y análisis de rendimiento
4. Tablas de diagnóstico (histogramas)
5. Tablas de mantenimiento
3.4.5.1.1 Tablas de recepción de datos y tablas de control
Las tablas de recepción de datos y las tablas de control tienen la siguiente estructura:
comAlarm
IdAlarma
Delfos
Fecha
parameter[]
comHistogram
IdHist
Delfos
Fecha
parameter[]
UTC
CodigoDallas
comVariable
IdAlarma
Delfos
Fecha
parameter
utc
comVersiones
Delfos
UltimaFecha
VersionFirmware
OldVersionFirmware
Fecha
comAttach
Delfos
UltimaFecha
VersionFirmware
OldVersionFirmware
Fecha
EstateBoard
IpAddres
Vehículos
PK Delfos
Matricula
Empresa
Las tablas coloreadas en verde corresponden a tablas de recepción de datos de las variables, histogramas y alarmas que vamos recibiendo de los dispositivos.
Las de color naranja son tablas de control utilizadas por el proceso listener para establecer la comunicación con los dispositivos, controlar la versión del software que almacenan, etc.…
En las tablas de recepción de datos (tablas de color verde), cuando se procesa un registro se
elimina de esta tabla, realizando una copia en una base de datos auxiliar.
Esta base de datos auxiliar se borra semanalmente, guardando un backup para posibles análisis posteriores.
3.4.5.1.2 Tablas de administración
Las siguientes tablas sirven para el tratamiento de toda la información relativa a las empresas, vehículos y conductores. Estas son gestionadas y administradas por las aplicaciones web.
Vehículos
PK veh_id
Delfos
matricula
Id_empresa
carga
tara
fecha_compra
precio
cv
disponibilidad
id_trans
cilindros
id_tipo_transmision
id_tipo_suspension
pma
dimension
tipo_compra
observaciones
delfos
id_tipo_motor
pto
id_marca
id_modelo
total_gross_weitgh
nivel_tanque
limite_velocidad
par
param
coef_consumo
km_ini
tipo_modificacion
longitud
id_segmento
Empresas
PK,FK1,FK2 id_empresa
nombre_empresa
id_pais
idioma
calle
cp
numero_telefono
tipo_cliente_transporte
tipo_rango_transporte
identificacion_tarjeta
id_codigo_dallas_eventos
FK1 veh_id
FK2 con_id
Conductores
PK con_id
numero_tarjeta
id_empresa
codigo_dallas
tipo_identificacion
AdmTrabajadores
FK1 tra_id
nombre
apelllido1
apellido2
id_empresa
mobil
observacion
id_pais
id_tipo
con_id
cc_ranges
PK cc_range_id
cc_range_desc
FK1 veh_id
cv_ranges
PK cv_range_id
cv_range_desc
FK1 veh_id
marcas
PK id_marca
descripcion
codigo
FK1 veh_id
modelos
PK id_modelo
codigo
id_marca
FK1 veh_id
motores
PK mot_id
desc
FK1 veh_id
normas_emision
PK id_norma
desc
FK1 veh_id
rango_transporte_empresas
PK id_tipo_rango_transporte
descripcion
lim_min_radio_punto_paso
lim_max_radio_punto_paso
FK1 veh_id
suspensiones
PK sus_id
descripcion
FK1 veh_id
tipo_carga
PK tipocarga_id
desc
codigo
FK1 veh_id
transportes
PK trans_id
desc
FK1 veh_id
3.4.5.1.3 Tablas de datos para el control de flotas
Las siguientes tablas son rellenadas por los procesos deccx y perVariablesDiarias. Son consultadas por la aplicación web para la parte del control de flotas y el análisis de rendimiento.
cfPosiciones
PK id_pos
FK1 veh_id
hora
fecha
longitud
latitud
FK2 con_id
detenido
parado
datetime
visible
inicio
toneladas
direccion
estado
odometro
odo_distancia
geo_distancia
litros
litros_parcial
cfTiempos
PK id_cf_tiempos
FK1 veh_id
FK2 con_id
fecha
inicio
fin
movimiento
ralenti
kilometros
tnkms
hora_dia
odometro
kms_productivos
kickdown
cfTrayectos
PK id_tra
id_pos
FK1 veh_id
FK2 con_id
id_punto_interes
nombre_lugar
toneladas
dia_inicio
hora_inicio
dia_fin
duracion
consumo
deposito
id_punto_interes_ini
nombre_lugar_ini
estado
estado_ini
ralenti
cfRepostajes
PK id_repostaje
fecha
hora
id_punto_interes
FK1 veh_id
FK2 con_id
litros_repostados
litros_consumidos
kms_recorridos
odometro
CfTacografo
PK id_cf_tacografo
flow_control
FK1 veh_id
FK2 con_id
id_tipo_tiempo
tiempo_total
fecha_inicio
fecha_fin
numero_tarjeta
per_variables_diarias
PK,FK1 veh_id
PK con_id
PK fecha
kilometros
litros
metros_ascendidos_desnivel
tiempo_pto
distancia_ascendida_desnivel
tiempo_velocidad_baja
tiempo_velocidad_alta
tiempo_velocidad_total
numero_cambios
tiempo_zona_verde
tiempo_total_verde
potencia_media_motor
total_potencia
carga_motor_media
total_carga_motor
litros_ralenti
grade_potencia_real
grade_potencia_teorica
grade_potencia_total
engine_on_time
consumo_ideal
rpm_inc
ralentizadores
freno_servicio
vel_lim
ralenti_inc
tns_netas_transportadas
aceleracion_inc
contador_cambios_marcha
Vehículos1
PK,FK4 veh_id
Matricula
Empresa
FK1 id_cf_tacografo
FK2 id_repostaje
Conductores1
PK,FK1 con_id
numero_tarjeta
id_empresa
codigo_dallas
tipo_identificacion
Las tablas anteriores son utilizadas para los diferentes informes de la aplicación del
cliente. Las que empiezan por “Cf” son para el control de flotas y son rellenadas prácticamente por el proceso Deccx.
La tabla per_variables_diarias es rellenada por el proceso PerVariablesDiarias. Este proceso hace un resumen diario de todas las variables más importantes para ser utilizado de cara al análisis del vehículo. En definitiva, es un resumen de la información de todas las demás.
3.4.5.1.4 Tablas de datos para los histogramas
Las siguientes tablas se usan para los datos de histogramas. La tabla comHistograms es rellenada por el proceso Listener. Mientras el proceso deccx es el encargado de su tratamiento y vaciado. Usa la tabla DecDefHistogramas para su decodificado, y las demás para almacenar los datos procesados.
comHistograms
PK hsid
delfos_code
datetime
parameters
utc
codigo_dallas
HistCond
PK,FK1 hist_con_id
dimension
na
his_code
con_id
veh_id
datime
fecha
hist_cond_id
HistVeh
PK,FK1 hist_veh_id
dimension
na
his_code
con_id
veh_id
datime
fecha
hist_cond_id
HistCondValores
PK hist_cond_id
PK posx
PK posy
valor
HistVehValores
PK hist_cond_id
PK posx
PK posy
valor
DecDefHistogramas
PK,FK1,FK2 hist_code
descripcion
dim_x
dim_y
rangos_x
rangos_y
tipo_formula
pun_disponible_una_fila
escala
explicacion
eje_x
eje_y
id_tra
id_idioma
3.4.5.1.5 Tablas de datos para las variables
Las tablas son las siguientes:
comVariables
PK delfos_code
PK datetime
varcode
utc
parameter
DecDefVariables
PK varCode
descripcion
tipo_variable
ofset
pendiente
code_pareja
procesar_desc
dec_var_posiciones
PK pos_id
PK var_id
valor
La primera tabla (comVariables) es una tabla temporal donde el Listener almacena las variables que va recibiendo. En la segundo se guarda la configuración de cada variable, para saber cómo procesarla. Y la última guarda las variables procesadas asociadas a cada posición enviada por el vehículo.
3.5 Servidor web
Este servidor dispone de un sistema operativo Windows 2003 server Standard Edition. Es una maquina Dell Server a 2,80GHz con 1,50 Gb de memoria RAM.
Actualmente queda un poco desfasada pero su único cometido es funcionar como servidor Web (para esto tiene configurado el IIS versión 6.0) y varios procesos para actualizar información de la base de datos Aplicaciones Web
1. Aplicación de Usuario www.delfos.divastec.com Esta aplicación es accesible para los clientes que contratan el sistema Delfos . Su cometido es el ofrecer un entorno web sencillo para poder gestionar la información que envían los dispositivos conectados a los vehículos.
2. Aplicación de Administración www.admindelfos.divastec.com Esta aplicación web es accesible solo para los miembros de la empresa. Su cometido es controlar y administrar datos de configuración y control de los dispositivos, tales como cambiar parámetros, actualizar la versión del firmware y herramientas para el control de incidencias y demás.
Procesos
1. Resolución de nombres Proceso ejecutado diariamente para realizar un reverse geocoding a partir de las latitudes y longitudes de los inicios y finales de los trayectos. De esta forma el cliente puede saber la dirección física de donde se encuentra el vehículo en las paradas de éste.
2. Parametrización Proceso ejecutado diariamente para enviar parámetros a los dispositivos, tales como la matricula, el nivel de tanque, puntos de interés, etc.
3. Calibración Proceso ejecutado diariamente para calibrar los datos de consumos de los vehículos. Este proceso actualiza un coeficiente guardado en la base de datos para cada vehículo, el cual se usa para multiplicar los datos de consumo. A más, recalibra todos los datos de consumo anteriores a la fecha de la calibración.
4. COMUNICACIÓN entre el dispositivo y el ser vidor de datos
Todos los dispositivos transmiten a través de la red GPRS usando el protocolo de comunicaciones UDP, el control del envío de tramas se detallará en el punto 5.3.
Una conexión GPRS está establecida por la referencia a su nombre del punto de acceso (APN). Con GPRS se pueden utilizar servicios como Wireless Application Protocol (WAP), servicio de mensajes cortos (SMS), servicio de mensajería multimedia (MMS), Internet y para los servicios de comunicación, como el correo electrónico y la World Wide Web (WWW).
Para fijar una conexión de GPRS para un módem inalámbrico, se debe especificar un APN (en nuestro caso usamos el de Orange en un 90% de nuestros dispositivos, incluso cuando estos funcionan en Roaming (la única razón es el precio)), opcionalmente un nombre y contraseña de usuario, una dirección IP, todo proporcionado por el operador de red.
En mi última etapa en la empresa tuvimos problemas en la asignación de direcciones Ip, y estuvimos estudiando la posibilidad de establecer una red interna con Orange. De esta forma las Ips serían privadas y únicamente podrían comunicarse con el servidor, evitando intrusión de información de terceros y aislando los datos con el exterior.
La transferencia de datos de GPRS se cobra por volumen de información transmitida (en kilo o Mbyte), este es un factor importante a controlar, debido a su coste, y más aun cuando los dispositivos se encuentran en el extranjero.
Todos los dispositivos llevan incorporados un modem (del tipo Júpiter 31 en adelante) y una tarjeta sim para realizar las conexiones a la red.
4.1 Protocolo UDP
El protocolo UDP (Protocolo de datagrama de usuario) es un protocolo no orientado a conexión de la capa de transporte del modelo TCP/IP. Este protocolo es muy simple ya que no proporciona detección de errores (no es un protocolo orientado a conexión).
Por lo tanto, el encabezado del segmento UDP es muy simple (cada campo es de 16 bits):
Puerto de origen Puerto de destino
Longitud total Suma de comprobación del encabezado
Datos (longitud variable).
Puerto de origen: es el número de puerto relacionado con la aplicación del remitente del segmento UDP. Este campo representa una dirección de respuesta para el destinatario. Por lo tanto, este campo es opcional. Esto significa que si el puerto de origen no está especificado, los 16 bits de este campo se pondrán en cero. En este caso, el destinatario no podrá responder (lo cual no es estrictamente necesario, en particular para mensajes unidireccionales).
Puerto de destino: este campo contiene el puerto correspondiente a la aplicación del equipo receptor al que se envía.
Longitud: este campo especifica la longitud total del segmento, con el encabezado incluido. Sin embargo, el encabezado tiene una longitud de 4 x 16 bits (que es 8 x 8 bits), por lo tanto la longitud del campo es necesariamente superior o igual a 8 bytes.
Suma de comprobación: es una suma de comprobación realizada de manera tal que permita controlar la integridad del segmento.
4.2 Formato de los frames
Todos los dispositivos envían la información empaquetándola en un frame. Éste contiene un campo para realizar tareas de comprobación de los paquetes recibidos, varios identificadores que nos indican el vehículo que envía los paquetes, y el tipo de paquete que se envía para su correcto procesamiento.
Dentro del paquete principal encontramos sub estructuras para diferenciar el tipo de datos enviados en el mismo frame.
La estructura principal es la siguiente:
Flow-control counter
IDENT_VEH
Id … Long N-1
El campo FlowControlCounter identifica el tipo de trama, definidos de la siguiente forma:
0x00 Alarm notification
0x01 Upload data
El sub campo id identifica el tipo de trama “upload”, este tipo de trama es la más relevante ya que es la más habitual y la que contiene los datos del vehículo enviados
o 0x00 Alarmas. o 0x01 Histogramas.
o 0x03 Variables o 0x04 Identificación
0x02 Identificación de vehículo.
0x84 Generic Error frame (Respuesta enviada del dispositivo al servidor cuando el servidor ha inicializado la comunicación)
El campo IDENT_VEH es el delfos_code del vehículo. Un identificador único para cada
dispositivo.
4.2.1 Tramas de datos Como hemos descrito en el punto anterior, dentro de un frame vienen contenidos distintas
tramas, cada una de ellas dispone de un id que identifica el tipo, y una estructura parecida, pero no idéntica en todos los tipos de sub trama.
La estructura de todos los tipos es la siguiente:
4.2.1.1 Frame vehicle identification Attach Trama de datos enviada por el dispositivo para iniciar la comunicación con el servidor.
Flow-control counter
0x02 Version H
Version L
Not relevant
Not relevant
Digit 0 Digit 1 Digit 2 Digit 3
4.2.1.2 Trama de datos (upload data) Distinguimos los siguientes casos:
Alarm segment
0x00 Length Alarm code H Alarm code L Param 1 H Param. 1 L Param 2 H Param. 2 L …
Esta trama envía información relativa a alarmas, tales como detección de puntos de interés definidos por el usuario, como alarmas relativas al mantenimiento del vehículo. Histogram segment
0x01 Length Data
Width Time Stamp H
Time Stamp L
4 bytes Driver ID MSB first
Histogram identifier
Value 1
Value 2
…
La anterior trama se utiliza para la obtención de los histogramas. Estos son contadores temporales en diferentes estados. Single variable value
0x03 Variable identifier H Variable identifier L Value H Value L Time Stamp H Time Stamp L Información de variables asociadas a las posiciones que recorre el vehículo.
Identification
0x04 Delfos 3 Delfos 2 Delfos 1 Delfos 0
Esta sub trama contiene un identificador único para cada vehículo. Y viene insertada en
cada paquete de datos que envía el dispositivo para identificarlo. Anteriormente solo enviábamos el identificador del dispositivo en el frame de attach y
utilizábamos la IP de éste para relacionar sus datos con él internamente en la base de datos. Pero por problemas de duplicidad de IP por parte del proveedor (Orange) tuvimos que modificar el protocolo de los frames para prevenir este problema. Actualmente esta sub trama se envía en todos los paquetes de datos.
4.3 Proceso de recepción de datos: LISTENER
El programa encargado de recibir y validar la comunicación los datos de los dispositivos es el proceso llamado Listener. Éste recibe los datos por un socket, los decodifica y almacena en unas tablas temporales. Controla el estado de los dispositivos y una vez conectados con ellos controla su localización IP.
4.3.1 Inicialización
El proceso comienza inicializando las estructuras de recepción de datos, abriendo el socket con el puerto indicado, realiza la conexión a la bases de datos y abre los archivos destinados a guardar los log de errores. Todo ello a través de los datos de un archivo de configuración llamado SysteInformation.txt. Una vez está todo inicializado pasamos a un bucle infinito a la espera de recepción de tramas.
El esquema de inicialización es el siguiente:
Leer archivo configuraciónSystemInformation.txt
Crear Socket()
Bind()
PQconnectdb()
Bucle Principal tratamiento de datos
Inicializacion Estructuras
El procedimiento detallado se describe a continuación:
1. Leer archivo de configuración
De este archivo obtenemos el puerto de conexión, y la IP del servidor que procesa la información.
2. Crear socket y asignar puerto
El puerto utilizado es el 12012, y la Ip del servidor 217.116.28.164.
Creamos el socket para recibir los datagramas
recvSocket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
Y enlazamos el socket con el puerto y la Ip. recvAddr.sin_family = AF_INET; recvAddr.sin_port = htons(serverPort); recvAddr.sin_addr.s_addr = htonl(INADDR_ANY); bind(recvSocket, (struct sockaddr *) &recvAddr, sizeof(recvAddr));
3. Conexión a la base de datos Inicializamos la conexión a la base de datos.
4. Inicialización de estructuras
Las estructuras que usamos son las siguientes:
typedef struct { uint16 reqID;
uint8 reqcode; uint8 param3,param2, param1, param0; uint8 data[300];
//usada para establecer parámetros o subversiones al actualizar el software. uint8 numberOfLongWords; uint32 vehicleID; uint8 detected; } req_fields;
//Estructura para guardar el identificador del vehículo y su dirección IP. typedef struct { uint8 vehicleID[12]; uint32 IPAddr; } vehicle; typedef struct { uint8 time_active; } *req_timer;
//Estructura para controlar las peticiones de parámetros. struct tableRequest{
uint16 request[MAX_NUMBER_OF_REQUEST_UNDER_PROCESS]; uint16 index;
};
//Estructura para guarder el ultimo frame recivido struct flowControlStructure { uint32 vehID; uint8 frame[MSG_LENGTH]; };
//Estructura para relacionar la información con los histogramas struct histControlStructDataType { uint16 utc; uint16 date; uint64 dallasCode; };
//Estructura para guardar el último frame recibido dividido en 3 partes para variables, histogramas y alarmas. struct lastFramesStructure { uint32 vehID;
uint16 frameLength; //total length uint8 flowControlByte;
//RecvBuf[0] sirve para reconocer frames repetidos, 0x0-0xFE; FF->comunicación iniciada por el servidor.
uint8 varFrame[MSG_LENGTH]; //variables uint16 varLength;
uint8 histFrame[MSG_LENGTH]; //histogramas uint16 histLength;
uint8 alarmFrame[MSG_LENGTH]; //alarmas uint16 alarmLength;
};
4.3.2 Tratamiento inicial de la trama de datos
Una vez inicializado el proceso, se pasa a la recepción y tratamiento de la trama. Después de recibirla, se reserva memoria dinámica para almacenarla, se busca el vehículo que la envía, y una vez insertada en un log, y ver que no es una trama repetida, el proceso determina quien ha iniciado la comunicación. Esta apreciación es importante, si la comunicación ha sido iniciada por el dispositivo estaremos en un modo normal de funcionamiento, es decir, el vehículo simplemente nos envía la información almacenada. En caso contrario (el servidor ha iniciado la comunicación) estaremos en un proceso de actualización del firmware, o una consulta de parámetros por parte del usuario, y por lo tanto, el tratamiento será muy diferente. Una vez hemos comprobado que la trama es correcta, se almacena en un buffer temporal para tratarla y se libera el de recepción.
El esquema es el siguiente:
Iniciada por el dispositivo
No ENCRYPTION=1
Si
Si
Recibir trama de datos()
Reservar Mem dinámica
Insertar Frame en FramesFile.txt
getVehicleId()
checkFrameReceived()
Chequea quien ha iniciado la comunicacion
Decrypt()
Almacena datos en la tablaDecompFrame
Tratar Frame
free (recvtempbuff)
El procedimiento detallado es el siguiente:
1. Recepción de la trama
Recibimos los datos mediante la siguiente instrucción: BufLenRec = recvfrom(recvSocket, RecvBuf, BufLen,0, (struct sockaddr *)&SenderAddr, (socklen_t*)&SenderAddrSize);
2. Reservar memoria dinámica
Vamos a usar dos buffers de memoria para el tratamiento de la trama: recvtempbuff = (uint8*)malloc(BufLenRec);
DecompFrame =(uint8*)malloc(BufLenRec);
3. GetVehiculeId() Almacenamos el Id del vehículo a partir de la Ip de la trama que hemos recibido en la variable ipAddressString. Guardamos en el log FramesFile.txt información sobre la trama y el vehículo.
4. Comprobación del frame
Mediante la función checkFrameReceived revisamos si el frame está repetido. Para esto consultamos la estructura de los frames del vehículo ( flowControlStruct) que lo ha enviado. Si todo es correcto insertamos el frame en la estructura Estas son las posibles respuestas:
-1 --> Frame repetido -2 --> El vehículo no había realizado el attach 1 --> Nuevo frame repetido .
5. Comprobar quien ha iniciado la comunicación y decodificación inicial
En la mayoría de los casos la comunicación es iniciada por el dispositivo. Aunque también es posible que el servidor la realice por tareas de parametrización del dispositivo o actualización del firmware de éste. Si el primer byte del frame es igual a 0xFF indica que el servidor ha iniciado la comunicación (InitByDevice=0). En este caso se recompone el frame obviando ese byte y se almacena en la array de bytes “DecomFrame”. En el caso en que la comunicación la inicia el dispositivo (InitByDevice=1), el frame se copia de forma entera en la array de bytes “DecomFrame”. Guardando en estas variables la siguiente información: Flow_control_byte = RecvBuf[0]; El flowcontrol de verdad se almacena en la última posición del frame.
idFlowControl = RecvBuf[BufLenRec];
6. Liberar memoria del buffer de recepción de datos. Con la instrucción free liberamos la memoria asignada al buffer de recepción de datos.
4.3.3 Procesado de la trama.
Una vez comprobado que la comunicación ha sido iniciada por el dispositivo, buscamos el primer byte de la trama para ver el tipo que recibimos (alarma, variable, o histograma). En función del tipo procederemos a la decodificación de los datos y a su inserción en la base de datos.
El siguiente esquema muestra el procesado de las tramas:
Chequear valor resultFlowControl
Enviar FlowControl al dispositivo
Liberar memoria Buffers
Sin tratamiento, el frame se descarta
Chequear quien ha iniciado la comunicación
Chequear DecompFrame[0]
Alarmnotification
Send 0x00Send 0x80(ERROR)
Vehicle Attachment
Send 0x02+
Datetime
Send 0x82(ERROR)
Uploaddata
Send 0x01Send 0x81(ERROR)
Liberar Recursos
Procesado SERVIDOR-DISPOSITIVO
Result==-1
Si
Result==1 Result==-1No
Si
No
Si
initByDecvice==1
Comunicación iniciada por el dispositivo
Si No
Comunicación iniciada por el servidor
(initByDevice=0)
FlowControlCounter==0x00
FlowControlCounter==0x01
FlowControlCounter==0x02Si
SiSi
No
No
Result==OK Result==OK Result==OK
Si Si SiNo No No
1. Chequear valor resultFlowControl Chequeamos el valor de esta variable para saber el estado del frame:
Frame repetido (-1) Enviamos el identificador del frame al dispositivo para que sepa que ya se ha recibido
Frame incorrecto (-2) No hay tratamiento
Frame correcto (1) 2. Chequear quien ha iniciado la comunicación Para saber quien ha iniciado la comunicación chequeamos la variable InitByDevice, si es 1 la ha iniciado el dispositivo, en caso contrario el servidor. 3. Comunicación iniciada por el dispositivo. Chequeamos el valor del frame tratado, la primera posición de memoria nos indicará el tipo de trama recibida:
Alarma (0x00)
Attach (0x02) Este siempre será el primer paquete enviado por el dispositivo.
Datos (0x01)
4. Alarm Notification
Decodifica la trama e inserta la alarma en la tabla com_alarms para su posterior procesado. 5. Vehicle Attachment
El frame recibido es el siguiente:
0x02 VersionH VersionL X X VehID 3 VehID 2 VehID 1 VehID 0
A partir de esta información obtenemos el identificador del vehículo y lo relacionamos con
la IP del frame recibido en la tabla com_veh_attach
6. Upload Data Esta función decodifica los sub frames dentro de la trama. Como hemos definido anteriormente existe la posibilidad de recibir 4 tipos de sub frames. Identificación (0x04)
0x04 Delfos 3 Delfos 2 Delfos 1 Delfos 0
Recibimos el identificador del vehículo para poder relacionar los demás datos del paquete con el vehículo.
Alarmas (0x00)
0x00 Length Alarm code H Alarm code L Param 1 H Param. 1 L Param 2 H Param. 2 L …
Se llama a la función alarm_upload, la cual decodifica el sub frame y lo guarda en la tabla com_alarms.
Histogramas (0x01)
0x01 Length Data Width
Time Stamp H
Time Stamp L
4 bytes Driver ID MSB first
Histogram identifier
Value 1
Value 2
…
Se llama a la función histograms_upload, la cual decodifica el sub frame y lo guarda en la tabla com_histograms.
Variables (0x03)
0x03 Variable identifier H Variable identifier L Value H Value L Time Stamp H Time Stamp L
Se llama a la función SigleDataVariable, la cual decodifica el frame y guarda todas las variables en la tabla com_variables.
4.3.3.1 Procesado de la trama cuando el servidor inicia la comunicación
En la siguiente figura mostramos el procesado de las tramas cuando el servidor ha iniciado la comunicación con los dispositivos. Esta comunicación sólo es iniciada cuando queremos actualizar algún parámetro del dispositivo o queremos realizar una actualización del firmware de éste.
Esta parte del procedimiento evalúa el tipo de petición, y como resultado envía al dispositivo los datos correspondientes. En el caso de los parámetros va actualizando la tabla com_requests para anotar el estado de envío del parámetro.
readRequestProcessing
SendUNATTACHED ERROR 0x02
SendDATA BASE ERROR
0x03 Chequear DecompFrame[0]
setReplyListener
Set_reply=2REPLY_OK Set_reply=
DecompFrame[1]setReplyFirmware
SendFRAME TYPE ERROR
0x03
Liberar Recursos
Result>0
Result==-1
Result==-2
SiSi
Si
NoNo
FlowControlCounter==0x0A,0x0B,0x0D,0x0F,0x10
FlowControlCounter==0x8A,0x8B,0x8D,0x8F,0x90
FlowControlCounter==0x0C,0x8C
FlowControlCounter==OTROS
Si
SiSi
Si
No
No
No
1. ReadRequestProcessing
Esta función devuelve el Id de la petición en curso, registrada en la tabla com_requests. Estos son los posibles resultados: 0 --> Es una respuesta a una actualización del firmware. -3 --> El vehículo no ha realizado ningún attach. Le envía el código 0x03 al dispositivo. -1 --> la base de datos no responde. Le envía el código 0x01 al dispositivo. >0 --> Devuelve el ID de la petición en curso
2. SetReplyListener Esta función actualiza el campo reply (pasado como parámetro a la función) de la tabla com_requests. En el caso en el que el primer valor del frame de datos es 0x0B decodifica el valor enviado en el frame por el dispositivo y también actualiza el campo data de la tabla com_requests. Este valor siempre será de 4 bytes separados por el carácter “;”. 3. SetReplyFirmware Esta función actualiza el campo reply de la tabla com_firmwareUpdate, así como el flowcontrol indicando el frame enviado. 4. Liberar recursos
Con la instrucción free liberamos la memoria asignada al buffer de recepción de datos.
4.3.4 Tipos de datos enviados
Los datos que envía el dispositivo los podemos dividir en tres tipos:
Variables Histogramas Alarmas
4.3.5 Variables
Este tipo de dato representa la información a tiempo real. Contiene desde información a eventos relativos a la conducción del vehículo. Todas estas variables se encuentran definidas en la tabla dec_def_variables, y cabe reseñar, que si el tamaño de la variable supera los dos bytes ésta se guarda en dos registros, separando su parte alta y baja.
Un ejemplo de tipos de variables enviadas son los siguientes:
Código Descripción
1 Kilómetros
2 Kilómetros H 3 Nivel del tanque
4 Distancia ascendida en ascensos
5 Distancia descendida en descensos 6 Toneladas
Existen más de 200 variables definidas.
4.3.5.1 Histogramas
Información para contabilizar el tiempo que se encuentra el vehículo en diferentes rangos o estados, para una serie de variables relativas a la seguridad, estado del vehículo, o forma de conducción. Esta información se va procesando de forma continua y se envía cuando sucede uno de estos casos:
Apagado del vehículo Cambio de conductor Cambio de día
A continuación muestro varios ejemplos de tipos de histogramas enviados, son los
siguientes:
Código Descripción
1 2.1.1.1. Curva porcentual de par motor 2 2.1.1.2. Potencia calculada general
3 2.1.1.4. Potencia calculada a velocidad máxima
4 2.1.1.5. Rendimiento en ascensos 5 2.1.1.3. Par motor calculado general
4.3.5.2 Alarmas
Las alarmas se producen como eventos asíncronos en el comportamiento del vehículo. Actualmente podemos diferenciar en varios tipos de alarmas: Alarmas de mantenimiento
Son alarmas que controlan el buen funcionamiento técnico del vehículo
Existen números tipos de estas alarmas, las siguientes son un pequeño ejemplo:
Código Descripción 11 Exceso de RPM
13 Exceso de RPM
31 Elevada temperatura del refrigerante 33 Elevada temperatura del refrigerante
43 Baja temperatura del refrigerante
51 Elevada presión de aceite motor 53 Elevada presión de aceite motor
61 Baja presión de aceite motor 63 Baja presión de aceite motor
Alarmas de detección de puntos de interés
Alarmas generadas al detectar un punto (por posicionamiento GPS) definido por el usuario.
Código Descripción 16.384 Llegada a cliente
16.385 Paso por lugar prohibido
16.386 Llegada a punto de repostaje 16.387 Llegada a proveedor
16.388 Llegada a centro de trabajo
Alarmas de identificación
Alarmas enviadas cuando se detecta un cambio de conductor.
Código Descripción
17.013 DriverID1. Taco grafo 17.014 DriverID2. Taco grafo
4.4 Envío de parámetros: RequestProcesor
Este proceso es el encargado de controlar y enviar los parámetros a los dispositivos. Se ejecuta de forma constante en el servidor de procesamiento de datos.
Estos parámetros son insertados por un proceso ejecutado en el servidor web llamado parametrización. Éste inserta los parámetros en la tabla com_requests y una vez ahí son gestionados por el RequestProcesor.
El proceso presenta las siguientes peculiaridades:
Envía un único parámetro por vehículo. Solo envía la información, no controla la respuesta del dispositivo, esta respuesta es
procesada por el proceso Listener, el cual actualiza el estado del registro de la tabla com_requests.
A medida que trata los parámetros actualiza los estados, el número de reintentos, y la fecha en los campos de la tabla.
El diagrama general de funcionamiento es el siguiente:
ReadNewRequest() == TRUE
No
Existen peticiones con TimeOut
ReadNewRequest()(detected=0 and reply=0)
ProcessRequest() - read, set or delete param - send_data()
RequestTimeOut()
Init socketConnect To DataBase
setReplyRequestProcessor()Reply=1
Si
Si
La explicación del diagrama es la siguiente:
1. Inicialización Se inicializan las estructuras para el socket, puerto y conexión a la base de datos.
2. ReadNewrequest Obtiene la primera solicitud pendiente de la tabla com_requests, cuyo vehículo no esté procesando ningún parámetro (detected=0 and reply=0) En caso de que lo encuentre, realiza la conversión al formato correcto del parámetro.
3. ProcessRequest Determina la acción a realizar con el parámetro (lectura, escritura o borrado). Envía el parámetro al dispositivo mediante la función send_data utilizada en el proceso Listener.
4. RequestTimeOut Busca los registros de la tabla com_requests con los campos detected=1 and reply=0 cuyo tiempo de envío al dispositivo haya sobrepasado un umbral determinado.
5. SetReplyRequestProcessor Actualiza el estado del campo reply, en el caso del diagrama lo actualiza a 1.
5. PROCESADO DE DATOS
Una vez los datos han sido almacenados en las tablas temporales por el proceso listener, estos datos necesitan un procesado para rellenar las estructuras finales, las cuales serán consultadas por la aplicación web para mostrar los datos por el usuario.
De cara al usuario, existen datos a tiempo real y otros calculados posteriormente. Mediante esta diferenciación podemos distinguir dos grupos de procesos en nuestro sistema para calcular los datos.
1. Datos en tiempo Real
Para realizar la obtención y procesado de información a tiempo real hay un proceso que se
ejecutan de forma ininterrumpida llamado Deccx. Este proceso se encarga de procesar y guardar la información que va almacenando en las tablas temporales el proceso listener. Cuando las tramas llegan completas, decodifica los datos y los almacena en tablas que son consultadas por las aplicaciones web. Este procesado ininterrumpido asegura una sensación de tiempo real para los usuarios.
2. Datos posteriores procesados
Una vez procesada toda la información a tiempo real, cada noche se ejecutan varios procesos
que examinan los datos, los tratan y depositan en diferentes tablas con el fin de facilitar la obtención de datos por parte de las aplicaciones web. En este apartado revisaremos el siguiente proceso:
PerVariablesDiarias
Este proceso se encarga mayoritariamente de calcular variables obtenidas a partir de los
datos de los histogramas y variables asociadas a las posiciones. A causa de que estos siempre llegan una vez apagados los dispositivos, se procesa la información de forma nocturna, así nos aseguramos que una parte importante de los datos diarios esté ya en la base de datos.
5.1 Procesado de la información a tiempo real (DECCX)
Como hemos introducido antes, este proceso es el encargado de procesar toda la información recibida por los dispositivos. Esta información ha sido previamente almacenada en la base de datos por el proceso listener, en las siguientes tres tablas en función del tipo de datos. Esta distinción de datos es importante, ya que a partir de ella podemos separar el cometido final de los datos.
1. Variables, en la tabla com_variables. 2. Alarmas, en la tabla com_alarms. 3. Histogramas, en la tabla com_histograms.
El cometido final es procesar esta información a tiempo real para ir depositando los datos
rende rizados en las tablas que son consultadas por parte del usuario a través de la aplicación web. Esta información podemos separarla de la siguiente forma:
1. Posiciones y variables asociadas 2. Trayectos 3. Tiempos (conducción, tacó grafo, etc.) 4. Alarmas 5. Histogramas
La estructura de las tablas en el origen de datos a procesar es la siguiente:
com_variables
delfos_code
datetime
FK1 varcode
utc
parameter
FK2 veh_id
com_alarms
alcode
fecha
parameters
delfos_code
parameter
com_histograms
delfos_code
datetime
parameters
hisid
utc
codigo_dallas
dec_def_variables
PK varcode
descripcion
tipo_variable
ofset
pendiente
code_pareja
procesar_deccx
Vehiculos
PK veh_id
delfos_code
...
Divas
PK divas_id
codigo_dallas_id_eventos
Las tablas de destino son las descritas en el punto 3.3.3.1.3
El diagrama general siguiente muestra procesado que realiza el proceso deccx
Control de prioridades
Protocolo TCP/IPSGBDPostgresSQL
Descodificador de variables
Descodificador de histogramas
Descodificador de alarmas
Descodificador de puntos de interés
Procesa arramque
Procesa tramo
Procesa posiciones
Identifica conductor
Salva inicio del tramo
Repostajes
Procesa tiempos
Borra variables procesadas
Procesa histogramas de conductor
Procesa histogramas de vehiculo
Borra histogramas procesados
Procesa alarmas de control de flotas
Procesa alarmas de mantenimineto
Borra histogramas alarmas
Puntos de interes
Alarmas de tacógrafo
Otras alarmas de control de flotas
Procesa puntos de interés
Borra puntos de interés procesados
Con arranque
Sin arranque
Procesa Dallas/Conductor
Como podemos ver en el gráfico el sistema está dividido en 4 partes generales:
1. Decodificación de alarmas 2. Decodificación de variables 3. Decodificación de histogramas 4. Decodificación de puntos de interés
El orden de ejecución de cada parte sigue la numeración anterior.
5.1.1 Decodificación de Alarmas
El funcionamiento del deccx tiene como prioridad decodificar las alarmas antes que las variables. El motivo es por las identificaciones de los conductores. Al ser enviadas como alarmas es prioritario que se procesen antes para así poder relacionar bien las variables con su conductor correspondiente. En caso contrario, podríamos relacionar los datos a un conductor equivocado.
La lectura de alarmas pendientes se realiza con la siguiente consulta: Query="SELECT com_alarms.delfos_code,alcode,veh_id,\
parameters, fecha , com_alarms.oid FROM com_alarms inner \ join vehiculos on com_alarms.delfos_code= vehiculos.delfos_code \ order by oid";
Y seguidamente se pasa al procesado de los datos. Las alarmas se separan en dos grupos:
Alarmas de control de flotas Alarmas de mantenimiento
Para distinguirlas se aplica una máscara al código de la alarma.
Control de flotas MASK_CF La máscara está definida en el fichero Codigos.h y el valor es 0x4000
Mantenimiento si no pasa la anterior mascara El diagrama es el siguiente:
Lectura de alarmas(LeeAlarmaCom)
&& MASK_CF
Procesado alarmas CF(ProcesaAlarmaCF)
Procesado alarmas MANTENIMIENTO
(ProcesaAlarmaMan)
Borrado Alarmas(BorraAlarmasCom)
SiNo
5.1.2 Alarmas de control de flotas
Dentro de todos los tipos de alarmas generadas por el dispositivo, las más relevantes son las generadas para la parte del control de flotas. Este tipo de alarmas incluyen tanto detecciones de puntos de interés definidos inicialmente por el usuario, y datos del tacó grafo.
Para procesar este tipo de alarmas se llama a la función ProcesaAlarmaCF(), dentro del
fichero alarmasCflotas.cc
El esquema de la función es el siguiente:
Obtener alarma para procesar
Comprobar si hay variables de identificacion (varCode=23)
EXIT
Poner Tipo Alarma
CargaFreezeFrame
Procesa Alarma Tacografo
ProcesaPuntoInteres
Busca Conductor
GuardaAlarma()
GuardaValoresAsociadosCf
Busca Conductor
No
Comprueba si es alarma de Identificación
Alarma ok (veh y tiempo)
Si
SiNo
5.1.3 Decodificación de variables
El objetivo de esta parte de procesado es la de obtener una trama de variables completa por vehículo en la tabla temporal com_variables, y realizar su procesado. Las tramas de variables inacabadas se siguen manteniendo en la tabla temporal hasta que el proceso listener las complete. Una vez esté la trama completa (esto lo sabemos mediante varias variables que indican su inicio y fin), se evalúa el tipo de trama, y se rellenan las tablas en función de los datos enviados (posiciones y variables asociadas, trayectos, repostajes, etc.)
Observando el siguiente esquema podemos ver el funcionamiento de esta parte del Deccx.
Tramo inacabado
es POSICIONES es ARRANQUE es INICIO_MOV OTRA
hayIDENTIFICACIONES
Si
Si No
ProcesaArranque=True
SiNo
engineShutdownLost()
Lectura de variables (LeeVariableCom())
Analizar tipo de trama(AnalizaTipoTrama)
Búsqueda trama a procesar
ProcesaTramo(PARO_MOTOR)
ProcesaPosiciones(TIPOTRAMA)
ControlDriver()
ProcesaArranque(TIPOTRAMA)
ControlDriver()
PROCESA DATOS TACOGRAFO
ProcesaTramo(TIPOTRAMA)
CONTROL IDENTIFICACIÓN
El procedimiento del procesado de variables es el siguiente:
1. lectura de variables.
La lectura de variables ejecuta la siguiente consulta:
Query="DELETE FROM com_variables \ WHERE not exists (select * from dec_def_variables \ WHERE com_variables.varcode=dec_def_variables.varcode \ AND dec_def_variables.procesar_decxx = 'true'); \ SELECT com_variables.delfos_code,veh_id,com_variables.varcode,datetime,\ utc, parameter, com_variables.oid, tipo_variable,ofset,pendiente,code_pareja \ from com_variables inner join dec_def_variables \ on com_variables.varcode=dec_def_variables.varcode \ inner join vehiculos on com_variables.delfos_code = vehiculos.delfos_code \ where (select count(*) from com_alarms where delfos_code = com_variables.delfos_code) = 0 \ or (select count(*) from com_variables where varcode = 23 and delfos_code = com_variables.delfos_code) > 0 \ order by veh_id,oid";
Esta consulta adquiere los registros ordenados por vehículo y por llegada de inserción (antes
de obtener los registros, se borran las variables no definidas en la tabla dec_Def_variables). La consulta sólo obtiene registros cuyos vehículos hayan mandado una identificación
(varcode 23) o no tengan alarmas para procesar, ya que en las alarmas se podría haber recibido una identificación. Este hecho es importante recalcarlo, es prioritario saber antes de nada que conductor va relacionado con el vehículo para ligar bien sus datos (tabla com_drivers_entry).
2. Búsqueda trama para procesar. Las tramas llegan ordenadas por vehículo, y se realizan las siguientes acciones:
1. Busca la trama de un vehículo que acabe en 33 para poder procesarla. Si no es este el caso omite este vehículo y sigue con el siguiente.
2. Evalúa si se ha recibido un código de identificación C_DRIVERS_ENTRY0 23 C_ACTIVE_CARD_DRIVER_1_ID_0_1 194
3. Monta la utc en segundos si se recibe la variable UTC_L_TACHOGRAPH y UTC_H_TACHOGRAPH 4. Procesado variables tacó grafo (estas variables aun no están disponibles)
3. Trayecto en curso inacabado (función engineShutdownLost())
La función principal de esta parte del código es la de cerrar el trayecto a causa de un apagado del dispositivo, imposibilitando la recepción de la variable de apagado. Este apagado normalmente es ocasionado por una desconexión inesperada de la fuente de alimentación, originada por un relé en la batería del vehículo.
Se llama a la función engineShutdownLost(). Esta función busca un arranque en la trama a procesar, seguidamente busca si hay un trayecto en curso que no se haya cerrado. La consulta utilizada para saber si hay un trayecto en curso es la siguiente:
Query="SELECT veh_id FROM dec_cf_inicio_tramos \
WHERE veh_id =" + ToString(veh_id);
Si hay un registro en esta tabla indica que hay un tramo sin acabar, si además hemos recibido un arranque indica que no hemos recibido el apagado, y la siguiente acción por lo tanto es la de cerrar ese trayecto.
4. Tipos de tramas
Función AnalizaTipoTrama(). Evalúa todas las variables del vehículo cuya trama acaba en
33, en función de estas 4 variables de control del estado del vehículo:
a. C_ARRANQUE b. C_DETENCION_RALENTI c. C_PARO_MOTOR d. C_INICIO_MOV
En función de estas 4 retorna los siguientes tipos de trama:
Si Arranque y ParoRalenti TRAMO_ENTERO_ARR_DET Si Arranque y ParoMotor TRAMO_ENTERO_ARR_MOTOR
Si InicioMov y ParoMotor TRAMO_ENTERO_MOV_MOTOR Si InicioMov y ParoRalenti TRAMO_ENTERO_MOV_DET Si Arranque ARRANQUE
Si ParoRalenti PARADA_RALENTI Si ParoMotor PARO_MOTOR Si InicioMov INICIO_MOV
Sino por defecto POSICIONES En función de estos casos evaluaremos las tramas de 4 maneras distintas:
1. POSICIONES 2. ARRANQUE 3. INICIO_MOV 4. Todas los demás casos
5. Función ProcesaTramo(TRAMO_INACABADO); Esta función o clase llama a la función RecomponerTramo() del fichero varTramos.cc
1. Obtiene “fecha, hora, odómetro, litros” de la última posición obtenida. 2. Calcula Duración (la hora final es la de la última posición obtenida) 3. Actualiza esa posición con el campo parado=TRUE 4. DecPosiciones()
Esta función asocia todas las variables a su posición. 6. Trama de Posición
En este tipo de trama se realiza lo siguiente: Si hay identificación en la trama:
ProcesaTramo(PARO_MOTOR) ControlDriver() ProcesaArranque(ARRANQUE)
Sino ProcesaPosiciones(POSICION)
6.1 ProcesaTramo Indirectamente llama a la función RecomponerTramo(tipo_trama). Obtiene las variables y si el tipo de trama es (PARADA_RALENTI o PARO_MOTOR o TRAMO_INACABADO), busca lo litros y kilómetros de la última posición recibida, calcula la duración del trayecto, y actualiza la última posición al estado de parado mediant e la siguiente consulta:
"UPDATE cf_posiciones SET parado = TRUE WHERE pos_id = (SELECT pos_id FROM cf_posiciones WHERE veh_id ="+ ToString(vehid) +" ORDER BY pos_id DESC LIMIT 1)"
En el caso de otro tipo de trama, obtiene esos datos llamando a la función GetInicioconArranque(). Seguidamente calcula la diferencia de kilómetros y litros entre las dos últimas posiciones (esta diferencia será posteriormente utilizada por el proceso perVariablesDiarias) y las guarda en la tabla cf_posiciones. Para finalizar, asigna las siguientes variables (longitud, latitud, toneladas, deposito, pos_id, tiempo_pto) al tramo, calcula el tiempo a ralentí y guarda el trayecto (tabla cf_trayectos).
6.2 Control Driver
Si el estado anterior devuelto es ARRANQUE o TRAMO_ENTERO_ARR_DET y se ha
recibido una variable de identificación procederemos a llamar al método ControlDriver() del fichero varDriver.cc.
Esta función comprueba si en la trama ha llegado una variable de identificación,
actualizando la tabla drivers_com_entry. Además contempla el caso de que se hayan recibido más de una de estas alarmas (alta y baja).
Funciona de la siguiente forma:
Localiza las variables de identificación Agrupa el Dallas o el número de tarjeta en función de la variable que llega. Si es una baja llamamos a InsertDriver() con conductor Nulo. Si es o una baja o el código Dallas es correcto llama a InsertDriver() con el Dallas Al acabar estamos en el alta, y llama a la función InsertDriver()
Función InsertDriver():
Esta función sirve tanto para identificar como para diferenciar estados según el Dallas. Esta diferenciación viene establecida por el campo codigo_dallas_id_eventos de la tabla divas.
Caso identificación:
o Alta de conductor Monta la select del conductor por Dallas o por número de tarjeta. Actualiza la tabla vehículos con el campo numero_tarjeta=NULL
para los registros con el número de tarjeta detectado. Actualiza el registro del vehículo en cuestión con el campo
numero_tarjeta en la tabla vehículos. Actualiza la tabla com_drivers_entry poniendo driverId= NULL
para el vehículo y el conductor recibido. o Baja de conductor
Actualiza la tabla vehículos con el campo numero_tarjeta=NULL para los registros con el delfos_code igual al Delfos tratado.
o Inserta en la tabla com_drivers_entry el conductor (si es baja NULL), el vehículo y la fecha.
Identificación estados
o Actualiza el campo estado de la tabla vehículos.
7. Procesa arranque Si la conexión con la base de datos es correcta (hace 3 intentos) ejecuta la función DecArranque(), en caso contrario borra la trama y guarda el error en un log. 7.1 Función Desarranque (tipo de trama)
Llama a DecPosiciones(). Esta función guarda la posición con todas sus variables y devuelve el conductor asociado. Si el tipo de trama es ARRANQUE 0 INICIO_MOV recupera el ralentí del comienzo del tramo y lo añade al tramo anterior si es necesario. Finalmente calcula los datos necesarios para los reportajes (kilómetros entre reportajes)
5.1.4 Decodificación de histogramas
Los histogramas se decodifican en último lugar (después de las alarmas y variables). Se comienza con la obtención del histograma a través de la tabla com_histogram, su decodificación y el guardado final en sus tablas correspondientes en función del tipo de histograma (de conductor o vehículo).
En el siguiente diagrama vemos su funcionamiento.
Hay histograma
Si
No
exit
LeerHistogramaCom()
ProcesaHistograma()
BorraHistogramasCom()
1. LeerHistogramaCom Esta función obtiene todos los histogramas disponibles de la tabla com_histograms
mediante la siguiente selección:
2. ProcesaHistograma El siguiente diagrama muestra el funcionamiento de esta parte:
Si driverId <> -1Si
No
If histograma is OKSi
No
exit
Obtener datos histograma
Buscar tipo identificación conductor
Busca driverId
driverId = NULL
ParametrosHist()
SalvaHistograma()
SELECT com_histograms.delfos_code, vehiculos.veh_id,hisid, datetime, parameters ,utc, conductores.con_id,com_histograms.oid FROM com_histograms inner join vehiculos on com_histograms.delfos_code= vehiculos.delfos_code left join conductores on com_histograms.codigo_dallas = coalesce(conductores.codigo_dallas, CASE WHEN char_length(conductores.numero_tarjeta)=16 then to_number(substr(conductores.numero_tarjeta,2,8),'99999999') else NULL END) order by com_histograms.oid
El funcionamiento es bastante simple, una vez obtenidos los valores del histograma, se recupera el conductor asociado al histograma, y si vemos que todos los valores y dimensiones del histograma son correctos, se procede al guardado de este. En caso contrario se borra.
3. SalvarHistograma
Esta función guarda los datos principales del histograma en la tabla hist_cond o hist_veh (en función si es para vehículo o conductor) y los valores asociados a este en la tabla hist_cond_valores o hist_veh_valores.
6. PROCESOS BACKGROUND
En el sistema existen una serie de procesos involucrados en el tratamiento de los datos del sistema, o para tareas de monitorización y registro de logs. En el siguiente esquema podemos ver los procesos implicados:
Parametrización
User Interface Web
Resolución de
Nombres
BD
producción
Calibración
Dispositivo DELFOS
Request
Procesor
Resolución de Nombres Actualiza los nombres de lugares de los trayectos a partir de su localización geográfica.
Parametrización Proceso que revisa que parámetros han cambiado y los envía al dispositivo.
Calibración Actualiza todos los datos de consumo en función de un parámetro calculado.
6.1 Parametrización de los dispositivos
La parametrización consiste en enviar o consultar ciertos parámetros usados en el dispositivo para realizar cálculos, calibraciones o detecciones de puntos de interés.
En el conjunto global de esta funcionalidad intervienen los siguientes procesos: En el servidor web:
Web de los clientes Los usuarios pueden cambiar parámetros como los puntos de interés definidos, valores como la matricula, peso, etc.
Web de administración Los usuarios pueden modificar los mismos parámetros que en el caso anterior, añadiendo ciertos parámetros de uso interno. Y dando la posibilidad de poder consultarlo para revisar posibles errores.
Proceso de parametrización Es el proceso que revisa si los usuarios han realizado algún cambio. Se ejecuta dos veces diariamente y en caso de cambios en algún parámetro la almacena en la tabla com_requests.
Proceso de borrado Este proceso se encarga de borrar los registros obsoletos de la tabla com_requests.
En el servidor de procesamiento de datos:
Request Procesor Revisa la tabla com_requests periódicamente por si hay parámetros a enviar a los dispositivos. Este es su único cometido.
Listener El proceso listener se encarga de recibir las respuestas de los dispositivos cuando han recibido una orden de parametrización. En función de estas actualiza la tabla com_requests actualizando el estado del registro.
En el siguiente diagrama podemos ver la trazabilidad de los procesos descritos
anteriormente. El usuario puede manipular ciertos parámetros de importancia general en los vehículos. El proceso de parametrización busca estos parámetros, los trata y los deja en una tabla temporal donde el proceso requestProcesor los recoge, y los envía a los dispositivos (en esta parte de la comunicación, el responsable de controlar las respuestas de los dispositivos es el listener).
RequestProcess
Web clientes Delfos
Listener
Web admin Delfos
Producción
Parametrizacion
Com_requests
Borrado
6.1.1 Proceso de Parametrización
Este proceso se encarga de buscar parámetros modificados a través de la interface web por los usuarios que son necesarios para ciertos cálculos que se realizan en el dispositivo Delfos. Los parámetros son los siguientes:
Matrícula del vehículo
Utilizada para el envío de sms. Nivel de tanque del deposito
Utilizado para el cálculo de variables asociadas al consumo. Coeficiente squarell
Éste coeficiente se utiliza para calibrar los datos de distancia recorrida que proporciona un dispositivo intermedio (no se usa en todos los modelos de vehículos) entre el can y nuestro dispositivo.
Límite de velocidad Es el límite de velocidad permitido por el usuario para cada vehículo. Si este valor es sobrepasado se envía una alarma de exceso de velocidad.
Puntos de interés Estos puntos son definidos por el usuario en la aplicación web. Sirven para marcar rutas o puntos prohibidos. Todos ellos generan una alarma asociada al punto enviado por el dispositivo.
El proceso se ejecuta dos veces de forma diaria. Su objetivo es buscar un booleano que indique si el parámetro ha sido modificado. Estas variables se renderizan con el formato adecuado y se guardan en la tabla com_requests para que el proceso RequestsProcess las envíe al dispositivo Delfos.
Todos estos registros insertados en la tabla com_requests, no son borrados después de enviarse al dispositivo. El motivo (explicado en el siguiente punto), es que los desarrolladores usábamos esta tabla para poder consultar ciertos parámetros en el dispositivo (a través de una herramienta web de la aplicación de administración), ya que aparte de enviar parámetros, el proceso RequestProcesor también envía peticiones de consulta y el proceso listener actualiza la respuesta. Si estas peticiones se borraran directamente perderíamos la información. Este funcionamiento es algo errático. Para subsanarlo de forma sencilla se creó un proceso periódico llamado Borrado, para eliminar estos registros.
Una mejor solución hubiera sido crear un disparador en la base de datos que únicamente guardara los registros usados en las consultas en otra tabla para su posterior consulta, pero por el escaso número de incidencias, no se llegó a realizar.
El código del proceso de Parametrización se encuentra en el módulo Parametriza.vb, es el
siguiente:
En la clase Parametrizacion encontramos la implementación de todo el proceso, se define un constructor por defecto, y se llama al método principal AnalizaParametros
Module Parametriza
Sub Main()
Dim param As New Parametrizacion
param.AnalizaParametros()
End Sub
End Module
'Constructor de la clase, no hace nada.
Public Sub New()
End Sub ‘Función Principal de parametrización, llama por separado a la
parametrización de cada parámetro
Public Function AnalizaParametros()
Me.ParamTipoVehiculo()
Me.ParamSquarell()
Me.ParamNivelTanque()
Me.ParamLimiteVelocidad()
Me.ParamParMotor()
Me.ParamPuntosInteres()
End Function
6.1.2 Proceso de Borrado
El proceso de borrado tiene la funcionalidad de limpiar la tabla com_requests de forma periódica para eliminar todos los registros en desuso. El motivo de esta demora a la hora de borrarlos es que esta tabla, aparte de servir para enviar información, también se usa para consultarla mediante la parte web. Si cada vez que se procesara un registro por el RequestProcesor y fuera borrado, perderíamos la información para mostrarla en la web. De esta forma guardamos esta información un máximo de un día. La periodicidad de este proceso es cada 30 minutos, ininterrumpidamente.
El código se encuentra en el modulo en el archivo Borra.vb, pero las clases utilizadas se encuentran en la misma clase que el proceso de parametrización. Desde ahí únicamente llamamos a la función Borrar dentro de la clase Parametrización Este proceso realiza las siguientes tareas:
Inserta en un log todos los registros que se van a borrar. Borramos los registros enviados a los dispositivos correctamente (reply=2)
Module Borra
Sub Main()
Dim param As New Parametrizacion
param.BorraParametros()
End Sub
End Module
'Función que borra los parametros con REPLY = 2 y vuelve a poner
operativos los que tengan reply=1 or reply=3
Public Function BorraParametros()
Borrar()
End Function
6.2 Resolución de nombres
Este proceso se utiliza para rellenar los nombres de los puntos de inicio y final de un trayecto realizado por un vehículo a partir de la latitud y longitud de la posición obtenida a través del GPS.
Para realizar esta actualización el proceso usa un servicio web de un proveedor llamado Mapsulote. El proceso actualiza cada trayecto generado que no haya sido procesado. Este proceso se ejecuta dos veces diariamente, una a las 11 am y otra a las 17h.
El servicio web que se utiliza es el siguiente: http://maptp39.map24.com/map24/webservices1.5?soap=Map24ReverseGeocoder
El código realiza las siguientes acciones:
Obtenemos los trayectos generados pendientes de resolver (de la tabla cf_trayectos y cf_repostajes) y los almacenamos en una lista junto al id que identifica el registro de la tabla.
Rellenamos las clases del servicio web, dándole la localización geográfica para resolver.
Con los resultados obtenidos actualizamos la base de datos (exactamente la misma tabla de la que consultamos)
El código lo podemos encontrar en el proyecto ActualizarDatos. El modulo Actualizar.vb
contiene el main principal, pero las funciones primarias se encuentran en la clase Trayecto.vb.
6.3 Calibración
El cometido de este proceso es el de ajustar los datos históricos de consumo de un vehículo. La causa de este desequilibrio viene data por el desajuste que presentan los datos internos relativos al consumo con el combustible real consumido.
Para resolver esta diferencia existe una herramienta web que calcula esta diferencia, comparando los datos reales consumidos (la empresa anota los litros repostados y el odómetro del vehículo) y se comparan con los obtenidos por el dispositivo. Mediante esta diferencia se obtiene un coeficiente. Este coeficiente lo usamos para aplicarlo a todos los datos de consumo. La aplicación es la siguiente:
Una vez se ha calculado este coeficiente, este se guarda en una tabla temporal para un procesado posterior (tabla adm_calibracion). El motivo de esta demora es que para actualizar todos los datos históricos se necesita un alto rendimiento de la base de datos, y por esta razón este procesado se realiza en horario nocturno. El proceso únicamente busca los vehículos pendientes de calibración, y ejecuta un script SQL que actualiza todos los diferentes campos de consumo de las siguientes tablas:
Cf_trayectos Cf_respostages Cf_tiempos Per_variables_diarias Dec_var_posiciones
El script es el siguiente:
/* $1 = coeficienteMultiplicado $2 = Me.veh.Text $3 = Scoef $4 = data $5 = id_calibracion */ DECLARE sqlerror varchar := ''; sqlerror_others varchar := ''; BEGIN sqlerror := 'update calibraciones set estado=2 where id_calibracion=' || $1; sqlerror_others := 'update calibraciones set estado=3 where id_calibracion=' || $1; update vehiculos set coef_consumo=$1 where veh_id=$2; update dec_var_posiciones set valor = valor * $3 where(var_id = 27) and pos_id in (select pos_id from cf_posiciones where veh_id=$2 and datetime<$4); update cf_trayectos set consumo=consumo*$3 where veh_id=$2 and dia_inicio<$4; update cf_repostajes set litros_consumidos=litros_consumidos*$3 where veh_id=$2 and fecha<$4; update cf_rutas set consumo=consumo*$3 where veh_id=$2 and fecha_inicio<$4; update per_variables_diarias set litros=litros*$3 where veh_id=$2 and fecha<$4; update per_variables_diarias set litros_ralenti=litros_ralenti*$3 where veh_id=$2 and fecha<$4; update per_variables_semanales set litros=litros*$3 where veh_id=$2 and fecha<$4; update per_variables_semanales set litros_ralenti=litros_ralenti*$3 where veh_id=$2 and fecha<$4; update calibraciones set estado=1 where id_calibracion=$5; return 1; EXCEPTION WHEN CONNECTION_EXCEPTION THEN execute sqlerror; RETURN 0; WHEN SQL_STATEMENT_NOT_YET_COMPLETE THEN execute sqlerror; RETURN 0; WHEN DIVISION_BY_ZERO THEN execute sqlerror; RETURN 0; WHEN INVALID_SQL_STATEMENT_NAME THEN execute sqlerror; RETURN 0; WHEN DATA_EXCEPTION THEN execute sqlerror; RETURN 0; WHEN DATETIME_FIELD_OVERFLOW THEN execute sqlerror; RETURN 0; WHEN ERROR_IN_ASSIGNMENT THEN execute sqlerror; RETURN 0; WHEN INVALID_DATETIME_FORMAT THEN execute sqlerror; RETURN 0; WHEN INVALID_REGULAR_EXPRESSION THEN execute sqlerror; RETURN 0; WHEN NUMERIC_VALUE_OUT_OF_RANGE THEN execute sqlerror; RETURN 0; WHEN INVALID_TEXT_REPRESENTATION THEN execute sqlerror; RETURN 0; WHEN INVALID_TRANSACTION_STATE THEN execute sqlerror; RETURN 0; WHEN INVALID_TRANSACTION_TERMINATION THEN execute sqlerror; RETURN 0;
WHEN SQL_ROUTINE_EXCEPTION THEN execute sqlerror; RETURN 0; WHEN MODIFYING_SQL_DATA_NOT_PERMITTED THEN execute sqlerror; RETURN 0; WHEN PROHIBITED_SQL_STATEMENT_ATTEMPTED THEN execute sqlerror; RETURN 0; WHEN MODIFYING_SQL_DATA_NOT_PERMITTED THEN execute sqlerror; RETURN 0; WHEN EXTERNAL_ROUTINE_INVOCATION_EXCEPTION THEN execute sqlerror; RETURN 0; WHEN SYNTAX_ERROR_OR_ACCESS_RULE_VIOLATION THEN execute sqlerror; RETURN 0; WHEN TOO_MANY_CONNECTIONS THEN execute sqlerror; RETURN 0; WHEN OUT_OF_MEMORY THEN execute sqlerror; RETURN 0; WHEN OTHERS THEN execute sqlerror_others; RETURN 0;
7. WEB DELFOS
7.1 Resumen general del aplicativo
El objetivo de esta web es la de proveer una herramienta accesible mediante la cual los clientes pueden acceder tanto a la información a tiempo real enviada por sus vehículos, como a la información histórica, usándola para comparar y medir rendimientos y optimizaciones de la flota.
Esta web está dividida en varios sub apartados, son los siguientes:
Comunes Este proyecto incluye todas las clases necesarias para cargar combos, listas, y provee las funciones para acceder a la base de datos. Se incluye como una DLL dentro del proyecto
Administración
En esta parte gestionamos la información relativa a la empresa, usuarios, grupos, vehículos y conductores.
Control de Flotas Esta parte consta de toda la parte relativa al control de la flota, de sub divide de la siguiente forma:
o Informes (de jornada, rendimiento por vehículo y conductor, etc.) o Puntos de interés o Mapa interactivo o Planificador o Informes de tacó grafo
Diagnóstico
Herramienta para poder ver las puntuaciones calculadas en un árbol de variables definido para vehículos y conductores. A medida que nos adentramos en la rama, podemos llegar a una hoja donde vemos un histograma. Donde obtenemos una medida precisa del tiempo donde se ha encontrado el vehículo en un estado determinado.
Análisis de rendimiento Esta herramienta sirve para obtener informes de las variables más importantes para la gestión, control y organización de la flota. Podemos realizar 4 tipos de informes para comparar vehículos o conductores, grupos o de forma individual, y diferentes formatos temporales (total, desglosado, evoluciones)
Object Manager Se podría definir como un control global de la aplicación. Su cometido es la de poder seleccionar elementos de conductor o vehículo, tanto de forma individual o agrupada.
7.2 Seguridad
Una vez se desarrolló la aplicación y se instaló correctamente en el servidor web. Se decidió implantar el protocolo HTTPS (protocolo seguro de transferencia de hipertexto) para el cifrado de datos enviados a través del servidor. Se creó el certificado correspondiente y se configuró el servidor IIS. El motivo era evidente, ofrecer a los clientes un protocolo seguro para mantener la confidencialidad de sus datos. Para mayor seguridad se cambió incluso el puerto utilizado, pasando del estándar 443, al 10443. Pero debido al tipo de clientes que usaban la aplicación, en su mayor parte empresas pequeñas de transporte con pocos conocimientos técnicos. Esta solución les provocó números problemas de acceso. A parte, en el 99% de los casos, a las empresas no les suponía ningún problema la seguridad de los datos enviados por los vehículos. Y después de aproximadamente un año, se decidió prescindir de este protocolo pasando al estándar HTTP.
7.3 Descripción Funcional
7.3.1 Comunes
Este proyecto está formado de varias clases utilizadas para la búsqueda, manipulación de datos, recarga de controles y la traducción multiidioma de la aplicación. El 95% de las conexiones a la base de datos se realiza con los métodos de estas clases
El proyecto consta de las siguientes clases:
Standard Parametrización Translation Log
Standard Dispone de métodos para conectarse a la base de datos, y métodos para recargar datos
en los diversos tipos de controles usados en la aplicación (listbox, drowdownlist, grid, etc.). La clase contiene estos únicos elementos:
Private CadenaConexionHera As String
Private CadenaConexionIris As String
Private CadenaConexionTestComHera As String
Private CadenaConexionTestComIris As String Public modo As Integer
Lo métodos son los siguientes:
Public Function Conectar() As PgSqlConnection
Crea la conexión a la base de datos
Public Function ExecuteReader() As PgSqlDataReader
Devuelve un objeto DataReader con los datos de la consulta solicitada.
Public Function ExecuteDataset() As DataSet
Devuelve un objeto DataSet con los datos de la consulta solicitada.
Public Function ExecuteNonQuery() As Integer
Ejecuta una consulta de modificaciones de registros, devolviendo el numero afectado.
Public Function Desconectar()As Integer
Libera la conexión a la base de datos.
Public Function CargaGrid() As Integer
Carga un grid de datos a partir de la consulta solicitada tipo (id, descripción) .
Public Function CargaLista() As Integer
Carga un grid de datos a partir de la consulta solicitada tipo (id, descripción) .
Public sub EjecutaAdapterFill()
Cada método dispone de una sobrecarga de parámetros de entrada, para poder operar con los distintos tipos de controles.
Translation Clase utilizada para traducir todos los textos de la aplicación a los idiomas castellano,
inglés y alemán. Cada proyecto dispone de un fichero XML ubicado en el mismo path llamado
traducción.xml. Éste archivo sigue esta estructura: <I id="es" lang="Castellano">
<D1>Trabajo</D1>
</I> <I id="en" lang="Inglés">
<D1>Job</D1>
</I>
<I id="de" lang="German">
<D1>Mitarbeiterverwaltung</D1> </I>
La clase se encarga de buscar el ítem x en el idioma correspondiente, para ello se usa el
método siguiente:
Log Clase utilizada para guardar información de acceso del usuario.
Controla las veces que entra un usuario a la aplicación y que partes de ella visita. Para ello se utilizan los siguientes métodos:
Public Sub CreaLog(ByVal IdUser As String) As Integer
Public Sub LogPuntuaciones(ByVal IdLog As String)
Public Sub LogInformes(ByVal IdLog As String)
Public Sub LogExcel(ByVal IdLog As String)
Public Sub LogImpresiones(ByVal IdLog As String)
Public Sub LogGrupos(ByVal IdLog As String)
Parametrización Clase utilizada para insertar parámetros en la tabla com_requests. Es una copia exacta del proceso de parametrización.
Public Function translate(ByVal value As String) As String
Try
Dim node As XmlNode
'select the string for the current language
node = xmlDoc.SelectSingleNode("//I[@id='" & curLanguage & "']/D" & value)
If Not node Is Nothing Then
'if a string is found, return it
Return node.InnerXml
Else
'if no string for the current language was found, try the default language
node = xmlDoc.SelectSingleNode("//I[@id='" & DEFLANGUAGE & "']/D" & value)
If Not node Is Nothing Then
'return the string for the default language
Return node.InnerXml
Else
'if no string for the current or the default language was found,
'try to find any string for the given value
node = xmlDoc.SelectSingleNode("//D" & value)
If Not node Is Nothing Then
Return node.InnerXml
Else
'if no string can be found in any language
Throw New Exception
End If
End If
End If
Catch ex As Exception
Return "Translation Error"
End Try
End Function
7.3.2 Principal
Como hemos explicado en el apartado anterior, la aplicación está dividida en varios sub proyectos, todos estos están contenidos en un proyecto Principal. Este proyecto se encarga de las siguientes acciones:
Estructura
Controla el acceso a la aplicación o ./login.aspx o ./global.asax
Contiene el archivo de configuración global o ./web.config
Contiene el control del menú de la aplicación o /usersControl/menú.ascx o ./ImgMenu o /ChartImages
Imágenes de la aplicación o ./Img
Autenticación La configuración está definida en el archivo web.config de la siguiente manera: Esto obliga al usuario a pasar siempre por la pantalla de login de la aplicación. La cual valida al usuario contra la base de datos. Roles de usuario
Existen 2 tipos de usuarios para acceder a la aplicación: User standard
Tiene acceso a todas las funcionalidades de la aplicación. User Temporal
Solo tiene acceso al mapa, y al informe de jornada.
<authentication mode="Forms">
<form- name="login"
loginUrl="login.aspx" protection="All" timeout="60"
/>
</authentication>
<authorization>
<deny user-="?" />
</authorization>
Menú de la aplicación
El menú esta implementado a través de una librería externa llamada Infragistics, la cual nos provee varios controles web con mayores funcionalidades.
Los elementos del menú están cargados estáticamente, pero dependiendo del tipo de usuario validado, se mostrarán o no los componentes.
7.3.3 Administración
Es la parte más sencilla de la web. Su cometido es la de administrar las tablas m aestras de la aplicación, son los siguientes:
Configuración de la empresa Empleados: conductores Vehículos Grupos: de vehículos, conductores y puntos de interés. Usuarios temporales: Usuarios con limitación temporal y de los recursos
que pueden consultar.
Todas las pantallas siguen este formato: Pantalla maestra Pantalla de edición
La pantalla maestra es la siguiente:
De la cual podemos observar un buscador, y un grid de datos con la opción de editar el registro. Si lo hacemos vemos la siguiente pantalla:
Toda la información relativa a esta parte se obtiene de las siguientes tablas de datos:
Estas son relativas al vehículo y sus componentes:
Vehículos Adm_costes Adm_marcas Adm_modelos Adm_motores Adm_normas_emision Adm_rango_transportes Adm_suspensiones Adm_tipos Adm_tipos_pto Adm_tipos_traccion Adm_transmisiones Adm_tranportes
Estas a los conductores y grupos
Adm_trabjadores Grp_conductores Grp2con Grp_vehiculos Grp2veh
Estas a la empresa y su configuración
Empresas Adm_config
7.3.4 ObjectManager
Como hemos dicho antes el objetivo de este sub proyecto es la de ofrecer un control para poder seleccionar vehículos o conductores, agrupados o no.
Para ello se ha definido una clase llamada OMRet.vb con la siguiente estructura: Esta clase, una vez creada, se almacena en sesión para poder ser utilizada desde
cualquier punto de la aplicación. Mediante las funciones definidas en el archivo funcions.js podemos llamar a este control.
Las funciones utilizadas son las siguientes:
Public Class OMRet
Public ListadoUnid As ArrayList
Public ListadoGrup As ArrayList
Public Sub New()
Me.ListadoGrup = New ArrayList
Me.ListadoUnid = New ArrayList
End Sub
End Class
function CargaObjectModal(modo, ruta, submodo, maxUni, maxGrp){
var variable= window.showModalDialog(ruta+ "?ModoCarga=" +
modo +"&Submodo="+ submodo + "&MaximUni="+ maxUni+ "&MaximGrp="+
maxGrp,"Modificar","dialogHeight: 510px; dialogWidth: 750px; edge:
Raised; center: Yes; help: No; resizable: Yes; status: No;
scrollbars:Yes");
}
function CargaObjectModalR(modo, ruta, submodo, maxUni, maxGrp,
remolque){
var variable= window.showModalDialog(ruta+ "?ModoCarga=" +
modo +"&Submodo="+ submodo + "&MaximUni="+ maxUni + "&MaximGrp="+
maxGrp + "&Remolque="+ remolque,"Modificar","dialogHeight: 510px;
dialogWidth: 750px; edge: Raised; center: Yes; help: No;
resizable: Yes; status: No; scrollbars:Yes");
}
function CargaObjectModal(modo, ruta, submodo, maxUni,
maxGrp,SelectedGrups,SelectedVehicles){
var variable= window.showModalDialog(ruta+ "?ModoCarga=" +
modo +"&Submodo="+ submodo + "&MaximUni="+ maxUni+ "&MaximGrp="+
maxGrp+"&SelectedGrups=" + SelectedGrups + "&SelectedVehicles=" +
SelectedVehicles,"Modificar","dialogHeight: 510px; dialogWidth:
750px; edge: Raised; center: Yes; help: No; resizable: Yes;
status: No; scrollbars:Yes");
}
Para llamar a estas funciones se les pasa los siguientes parámetros:
Modo: vehículo o conductor. Ruta: Ruta de la pagina del objectManger. Submodo: 0 (individual) 1 (grupos). MaxUni: máximo de unidades seleccionables. MaxGrp: máximo de grupos seleccionables. SelectedGrups: elementos de grupos seleccionados anteriormente. SelectedUnid: elementos de unidades seleccionados anteriormente.
El resultado de llamar al object manager es el siguiente:
7.3.5 Control de Flotas
El objetivo de este proyecto es la de ofrecer información a tiempo real (mapa interactivo) y ofrecer toda la información relativa al control directo de la flota. Las opciones son las siguientes:
o Informes (de jornada, rendimiento por vehículo y conductor, etc.) o Puntos de interés o Mapa interactivo o Planificador o Informes de tacó grafo
Informes
Los informes disponibles son los siguientes:
Informes de Alarma de seguridad Muestra las alarmas de seguridad de los vehículos
Productividad de conductores Informe de Jornada
Muestra información sobre los trayectos, tales como el combustible consumido, tiempos, etc.
Productividad de vehículos Repostajes
Información de los repostajes producidos en el vehículo, muestra variables asociadas a este hecho.
Informe de tacó grafo Información acerca de los tiempos enviados por el dispositivo, consultando al taco grafo del vehículo.
Identificaciones
Todos los informes siguen la misma estructura y mantienen las funcionalidades
Filtrado Todas las páginas disponen de los siguientes filtros:
o Selección de vehículos o conductores (ObjectManager) o Intervalo temporal o Otras
En la siguiente imagen vemos un ejemplo:
Opciones de salida
o Formato web: resultados en un grid.
o Pdf: mediante el componente Crystal Report
o Excel
Puntos de interés Los puntos de interés son zonas donde el usuario quiere detectar si el vehículo pasa cerca
de un radio. Estos puntos se pueden definir de dos formas:
Indicando de forma manual su localización
Para obtener la latitud y longitud del punto que vamos a crear usamos un servicio web del proveedor Mapsolute. Similar al ya especificado en el proceso de Resolución de nombres
Seleccionándolo desde el mapa haciendo un doble clic.
Para realizar esta mejora, al realizar el doble clic en el mapa, el proveedor llama a un web externa a la aplicación pasándole el ID del mapa, y la latitud y longitud del punto seleccionado. La pagina, a partir de estos datos, obtiene el usuario que ha realizado la demanda, insertando el punto con los datos proporcionados. Mapa interactivo Esta página ofrece la posibilidad de consultar las posiciones y rutas de los vehículos de los últimos 3 meses en curso. También ofrece la posibilidad de crear y consultar puntos de interés. A parte de disponer de un pequeño localizados geográfico.
La página está formada por dos partes, contenidas en un Iframe de la siguiente forma:
Menú, situada a la izquierda. Con esta parte controlamos las acciones a realizar en el mapa interactivo. Este menú está construido a partir de un web control del paquete Infragistics, en ese caso un UltraWebTree.
Mapa interactivo, consiste en un applet el cual controlamos a través de servicios web.
La imagen del mapa es la siguiente:
Los servicios web usados para el control y pintado del mapa son los siguientes:
http://maptp39.map24.com/map24/webservices1.5?soap=Map24Routing http://maptp39.map24.com/map24/webservices1.5?soap=Map24ReverseGeocoder http://maptp39.map24.com/map24/webservices1.5?soap=Map24MapletRemoteControl http://maptp39.map24.com/map24/webservices1.4?soap=Map24Geomatcher http://maptp39.map24.com/map24/webservices1.5?soap=Map24RenderEngine
7.3.6 Análisis de rendimiento
Esta parte de la aplicación se usa para sacar informes en 4 tipos de formatos:
Comparación de Vehículos/Conductores Comparación de variables Evolución temporal de Vehículos/Conductores Evolución temporal de variables
Se pueden guardar, modificar y ejecutar, y tenemos las siguientes opciones a la hora de
realizarlos:
Selección fechas Selección vehículos y conductores (por unidades o agrupados) Selección de variables
Existen 6 tipos de variables o Datos de consumo o Datos de productividad y condiciones de ruta o Datos de mantenimiento o Datos de seguridad del conductor o Datos de rendimiento de vehículo o Datos de rendimiento de conductor
Esta es la parte de los filtros del informe:
Y esta la selección de variables:
Cada variable se calcula directamente a través una tabla definida llamada an_variables. Esta tabla contiene una estructura donde se define las tablas donde buscar los datos, as í como los joins necesarios para realizarla. De esta forma podemos añadir variables de forma dinámica desde la base de datos. Los resultados se ven de la siguiente manera:
Grid de datos Salida Excel Grafico comparativo
7.3.7 Diagnosis
Puntuaciones El apartado de diagnosis nos ofrece un entorno en el que podemos ver las puntuaciones
tanto de los conductores y vehículos. Estas puntuaciones se realizan en un árbol que detalla las partes más fundamentales de la conducción y el comportamiento del vehículo.
Podemos verlo en el siguiente ejemplo:
La aplicación permite ir adentrándose en estas ramas viendo la puntuación de los
individuos seleccionados, llegando a una de las hojas, donde en este nivel podemos ver el detalle de tiempos en el histograma asociado.
Toda esta información se calcula en un proceso nocturno y sale de las siguientes tablas:
Pun_diarias_con Pun_semanales_con Pun_diarias_veh Pun_semanales_veh Pun_def_zonas Pun_def_zonas_hist
Histogramas
Una vez hemos analizado toda la rama del árbol, llegamos a un punto donde no podemos
adentrarnos más, es aquí donde podemos ver el histograma asociado.
En los histogramas, cada valor de la celda representa el tiempo que ha estado en los dos rangos representados en el eje X y en el eje Y. Cada rango tiene un color asociado que va del verde al rojo. Este último representa la zona límite de la variable, es decir, es la peor situación posible, al contrario que el color verde. Toda la información relativa a los histogramas se encuentra en las siguientes tablas:
Dec_def_histograma Contiene la definición de los histogramas enviados por el dispositivo.
Hist_cond Contiene la información estándar de los histogramas que envía un dispositivo para conductor (fecha, vehículo, conductor, tipo de histograma, etc.)
Hist_cond_valores Valores de las celdas para cada rango del histograma en cuestión.
Hist_cond_semanales Resumen semanal de los histogramas
Hist_veh Contiene la información estándar de los histogramas que envía un dispositivo
para vehículo (fecha, vehículo, conductor, tipo de histograma, etc.) Hist_veh_valores
Valores de las celdas para cada rango del histograma en cuestión. Hist_veh_semanales
Resumen semanal de los histogramas.
7.4 Plataforma
7.4.1 Utilidades de terceros
Software Compañía Observaciones
Corelab.posgresql.dll Corelab Driver de acceso a la BD
ExcelXmlWriter.dll Creación de XML’s Infragistics.WebUI.Shared.v5.3.dll Infragistics Controles web avanzados
wccapturateclasespeciales.dll
DivasControls.dll
7.4.2 Frameworks
Framework & Información de la Versión Descripción Referencias
Microsoft Framework .NET 1.1 Versión antigua Microsoft Framework .NET 2.0 Nueva versión de la web
7.4.3 Desarrollo y construcción de herramientas
IDE / Utilidad Versión service pack / parche Observaciones
Microsoft Visual
Studio 2003
Con plugins para poder
realizar integraciones.
Necesario para las librerías de
antigua web. Microsoft Visual Studio 2005
Nueva web
8. MANUALES
Durante el transcurso de todo el proyecto se fueron creando ciertos documentos de interés, los cuales detallan como instalar y configurar los servidores de testeo y producción.
Para el servidor de desarrollo de datos se encuentran los siguientes:
Instalación Argeada desde 0.doc Documento para la configuración del servidor de test de procesamiento de datos. Este documento fue creado a partir de toda la documentación de RedHat, incluyendo únicamente los aspectos prioritarios en nuestro tipo de instalación. La cual es típica de un servidor de desarrollo.
Installation NewLinuxServer.doc Ídem pero para el servidor de producción.
Installation PostgreSQL.doc Documentación para configurar el gestor de la base de datos PostgreSql. Toda la documentación fue obtenida de la página oficial de PosgreSql. http://www.postgresql.org.es
Procedimiento en caso de fallo de Hera.doc Procedimiento definido a seguir en caso de fallo de uno de los servidores de producción.
Procedimiento en caso de fallo de Iris.doc Ídem que el caso anterior, pero para el segundo servidor de procesamiento de datos.
Administración Servidor Linux.doc Aspectos fundamentales para la gestión del servidor, funcionamiento del cron, etc.
Para el servidor web disponemos de la siguiente documentación:
Instalación Delfos desde 0.doc Procedimiento para la instalación del servidor web y de todos los componentes necesarios para su buen funcionamiento.
Administración servidor Windows Delfos.doc Guía para administrar los aspectos más fundamentales del servidor.
Procedimiento en caso de fallo de Delfos.doc Procedimiento a seguir en caso de fallo del servidor.
9. RECURSOS UTILIZADOS
www.infragistics.com Controles avanzados web. En la página podemos encontrar documentación para el funcionamiento de los controles, características, etc.
www.map24.es Documentación de los servicios web usados para usar el mapa en la aplicación web, así como el uso del applet usado en el mapa del control de flotas.
http://www.postgresql.org.es Pagina web oficial para el uso de una base de datos PostgreSql. En esta página podemos encontrar desde el ejecutable para el gestor, como toda la documentación para el uso y la gestión de la base de datos.
http://es.redhat.com/ Pagina web oficial de la distribución Linux usada en los servidores de producción.
http://msdn.microsoft.com
Documentación entorno .Net.
10. APORTACIONES DEL PROYECTO A LOS CONOCIMIENTOS DEL ALUMNO
Como he mencionado anteriormente, entré en una fase inicial del proyecto, y debido a que la empresa es una ingeniería pequeña con recursos limitados (tanto a nivel humano como técnico) esto supuso un constante reciclaje en el aprendizaje de la tecnología usada para cada parte del producto. A parte, a causa de la dificultad para evolucionar cada parte del producto de una forma estable, tuvimos desarrollar un plan de evaluación y corrección para gestionar los errores y mejoras, y un procedimiento para el análisis y diseño de nuevas funcionalidades .
En los siguientes puntos describiremos las aportaciones recibidas durante todo el transcurso del proyecto.
10.1 Conocimientos técnicos
A nivel técnico estos son los conocimientos adquiridos:
Administración sistemas operativos Windows 2003 Server Instalación y configuración del servidor. Administración de un portal Share Point para gestionar errores y tareas del
grupo. Gestión de los usuarios. Administración del servidor web. Gestión de los servicios y tareas programadas. Administración del servidor FTP.
Linux Red Hat Instalación y configuración de todos los servicios. Instalación y configuración del gestor de la base de datos PostgreSql Configuración de los procesos y su ejecución (cron, etc.) Mantenimiento
Entornos y lenguajes de programación Visual basic .Net y C# en la plataforma Visual Studio 2003 (framework 1,1) y
Visual Studio 2005. Para el desarrollo de aplicaciones web, dispositivos móviles y procesos de consola.
C y C++, para procesos de tratamiento de datos ejecutados en los servidores Linux.
Administración y gestión de bases de datos PosgreSql SqlServer SqlCE Acces
10.2 Planificación y fases de desarrollo
Para la planificación y desarrollo se siguen las siguientes directrices:
1. Evaluar la carga de trabajo. Para evaluar la carga de trabajo la empresa dispone de un portal SharePoint con un listado de errores y mejoras pendientes. En el siguiente punto de organización detallamos las características de este portal.
2. Planificar los errores y mejoras a realizar en el nuevo ciclo. En función de las necesidades de la empresa y de los clientes, en cada ciclo se priorizan las mejoras o errores pendientes a realizar. En ciertos casos, muchas de estas mejoras (o errores) se han de desglosar y planificar en varios ciclos diferentes.
3. Planificar la ejecución de las fases. o Fase de corrección o desarrollo.
Periodo para la corrección de los errores. o Fase de evoluciones
Periodo para el desarrollo de mejoras de producto o Fase de testeo modular
Testeo de forma modular de o Test de integración
Fase de testeo global. Se realiza un testeo ya definido a la globalidad del sistema viendo cómo responde el sistema en cada una de la interacciones
o Actualización del release. Subida de todo el software (dispositivos, servidor de procesamiento de datos y aplicaciones web.
o Test final. Test similar al de integración, pero evaluando únicamente la parte final del producto.
El siguiente diagrama en V muestra todo el proceso de desarrollo de todas las mejoras o
errores a desarrollar.
Organización Para la gestión de errores y mejoras elegimos usar un portal Share Point, mediante el cual
se gestionan y controlan todos los estados de los siguientes elementos tratados en cada ciclo.
Errores de release Errores detectados tanto por los usuarios y programadores. Estos errores son detectados, pero no son corregidos hasta el comienzo del siguiente ciclo. Esta elección se realiza en función de las necesidades prioritarias y el nivel de prioridad
Mejoras de producto Mejoras a realizar, estas pueden ser tanto de la parte web, o posibles datos nuevos a enviar y procesar por el sistema.
Mejoras de proceso Mejoras internas para la empresa para facilitar tareas de gestión, log y control de los procesos.
Errores en las mejoras Errores detectados en las mejoras no subidas a producción.
Todas estas listas se gestionan a través de la figura del Ingeniero de sistemas. Una vez comenzado el periodo, todos los ítems seleccionados para ese ciclo son actualizados, y una vez se van desarrollando los programadores y testeadores actualizan el estado del error para su
revisión y aprobación.
11. APORTACIONES DE LOS ESTUDIOS REALIZADOS AL PROYECTO
Como aportaciones más relevantes durante el transcurso del proyecto destacaré las asignaturas descritas más abajo. Pero debido a que este producto engloba entornos tan diferentes, he realizado una separación en función de la parte del producto donde intervienen.
He de matizar que las asignaturas no incluidas, no significa que no hayan aportado nada, simplemente a nivel técnico no han influenciado directamente en el desarrollo del proyecto.
En términos generales, estas son las asignaturas más reseñables, ya que participan en cada una de las partes del producto donde he intervenido.
Programación I y II, Estructura de datos
Para el desarrollo de la programación de todas las partes del software del producto.
Estadística Esta parte interviene en el cálculo de parámetros estadísticos en ciertos informes realizados para las auditorias de las empresas clientes.
Administración y gestión de redes de computadores Administración de sistemas operativos.
Debido al poco personal disponible en la empresa, era el encargado de administrar los servidores de test y producción. Realizando tareas de administración y mantenimiento del servidor.
Aunque no haya participado en la programación directa del firmware del dispositivo, si tuve que intervenir para entender, analizar y diseñar cambios. Por ese motivo estas son las asignaturas más destacadas en esta parte:
Introducción a los circuitos electrónicos Como ejemplo, en ciertas ocasiones, teníamos que manipular el hardware del dispositivo, soldando conectores o resistencias necesarias para diferentes tipos de modelos de vehículos.
Estructura de computadores Sistemas con microprocesadores Sistemas y señales Periféricos
Para esta parte era indispensable entender tanto las entras externas de información del dispositivo, su diseño (memorias, micro controlador, etc.) y su programación en tiempo real. Todas estas asignaturas han ayudado en esta tarea.
De cara a la programación del servidor web y a los procesos alojados en el servidor de
procesamiento de datos la más importante (aparte de las otras asignaturas de carácter general descritas al inicio de este apartado) es la siguiente:
Introducción a las bases de datos y Bases de datos En esta parte era fundamental conocer la estructura de la base de datos, ya que constantemente los procesos leen y actualizan esta información.
Para finalizar, he de destacar que debido a la rama de Ingeniera que estudié (Sistemas) he
echado a faltar conocimientos generales sobre ingeniería del software, sobre todo en aspectos de análisis y diseño para el tipo de aplicaciones a alto nivel en las que intervine como analista. Esta carencia la subsané gracias a cursos, y a la metodología usada durante la carrera.
12. CONCLUSIÓN
Durante el transcurso de este proyecto, no solo he aumentado mis conocimientos técnicos en las diferentes áreas en las que he participado, sino que también me ha dado la oportunidad de participar en decisiones importantes de cara al futuro de la propia empresa, en cuestión de mejoras y ampliaciones del producto, o en mejoras relacionadas con la productividad y el trabajo interno. Además, he tenido la oportunidad de conocer, aprender, y dirigir un grupo de desarrolladores con el objetivo del buen funcionamiento del producto, su mantenimiento y evolución.
