Categoría: ARGOS MONITORING

En esta pantalla veremos un resumen de todas las alarmas que tenemos en nuestra flota. Si somos usuarios nivel coterena veremos todos los barcos de nuestra aplicación.

En la primera columna vemos el nombre de los barcos, con un enlace directo al informe del centro para ver su estado actual.

En la segunda columna vemos el estado del barco, si está online o no y de hace cuanto es su última conexión

En la tercera columna vemos un resumen del bloque de telemetrias del barco. Vemos como primer elemento el bloque de telemetrias que ha llegado mas recientemente. El segundo elemento son las telemetrias que tendrían que llegar de forma continua. El tercer elemento es el numero total de telemetrias programadas para ese centro. Hay una leyenda abajo en colores azules para esta columna.

La cuarta columna solo la ven los usuario de nivel coterena, y nos dice cuantas alarmas programadas tiene. Si pinchamos ahi iremos al sistema de gestion de alarmas programadas.

La quinta columna nos indica cuantas alarmas programadas tiene activas el centro en cuestión. Dependiendo de la importancia de la alarma tendra un color u otro. Estos colores se ven reflejados en la leyenda inferior izquierda.

La sexta columna nos da la informacion de cuantas alarmas onboard que tiene el barco. Las alarmas onboard son aquellas que ven en el barco. También vemos ahi cuantas variaciones han habido las ultimas 24 horas. Si hacemos click entraremos en un informe de alarmas onboard para este barco concreto.

Esta pantalla puede variar en funcion a si hay alarmas activas nuevas. Si las hay, nos saldrán solo aquellos barcos con las alarmas nuevas y las alarmas que hay saltado nuevas saldrán parpadeando.
Si muteamos las alarmas aceptamos que estas alarmas ya las hemos visto, entonces volveremos a ver la pantalla normal con el listado de todos los barcos sin sonido ni parpadeos.

Al lado del boton de mutear alarmas podemos acceder a la pantalla de alarmas onboard pero para toda nuestra flota en vez de solo para un barco.

Para una mejor explicación y de forma gráfica ver el siguiente video: https://www.youtube.com/watch?v=vLGpy3Yi4bk

Esta pantalla muestra todos los barcos de nuestra flota. Si somos usuario coterena veremos todos los barcos de la aplicación.

Veremos el barco como una flecha con orientación del barco en ese momento. Si no tenemos la telemetria de direccion entonces se vera un pin de posición en vez de la flecha.

Vemos que los barcos tienen un color, rojo, amarillo, verde o gris:
Rojo – Tiene activas alarmas programadas de estado crítico
Amarillo – Tiene activas alarmas programadas no criticas
Verde – Está en conexión y no tiene alarmas activas programadas
Gris – El barco se encuentra sin conexión
Al hacer click en los botones de leyenda podremos ver una tabla con todos los barcos de nuestra flota que se encuentran en ese estado.

Los botones de abajo derecha son los controles de pantalla. Aqui podemos pausar y reanudar el progreso para cambio automatico de pantalla, el cual vemos como una barra debajo del mapa, y botones para avanzar a la siguiente pantalla de control de alarmas de forma manual.

Para una guia mas completa con ejemplos prácticos ver el siguiente video: https://www.youtube.com/watch?v=LeynGDfY-5s

Mejorados los envios a Lloys, DNV, ahora se muestran correctamente los consumos de los auxiliares y motor principal.

Se ha añadido un nuevo tipo de control, TIMELINE.
Este tipo de control lo usamos para mostrar en una escala de tiempo los eventos que hayamos filtrado por una fecha inicio y final.
Si clickamos encima del evento que queramos abriremos una pestaña nueva con la pantalla de acumulados filtrada ya por las fechas del evento. El control admite zoom y avanzar manualmente en la escala de tiempo.

Cambios a la pantalla MRV
Ahora la pantalla MRV separa en dos colores las rutas y puertos en funcion a su papel en el MRV.
Las RUTAS y PUERTOS que aparezcan en rojo no contarán para el sumatorio de MRV. Las RUTAS que aparezcan en amarillo sumarán un 50% del valor al cálculo MRV. Lo que aparezca en negro contará el 100%.
Abajo en la tabla ahora habra una separación entre el valor calculado y el real(el que suma todo sin tener en cuenta si vale para mrv o no)

Nuevo formato pantalla CII
Ahora la pantalla muestra por defecto solo las rutas y si queremos los calculos mensuales entonces deberemos seleccionarlo.
Hemos cambiado el formato de las cajas y el gráfico que posicionaba el CII ATT del barco de una forma mas visual en la que podemos ver mejor de forma visual la distancia de donde esta el barco a cada punto de referencia del gráfico.
Abajo se ha incorporado un timeline con los eventos de ruta y puerto que también redirigen a acumulados

Nuevo informe de Análisis refrigerante
Se ha creado un nuevo informe que hemos nombrado como Análisis refrigerante/Cooling analysis. Mostramos tres gráficas donde analizamos estos tres campos brass,iron,copper junto con sus variables. Cada uno en un gráfico junto con el nivel de ph en la escala secundaria.

Nuevo evento DATA_GAP
A partir de ahora se generará un evento DATA_GAP el cual marcará la falta de telemetrias durante mas de x tiempo. Estos datos los estamos reflejando por ejemplo en el timeline de la pantalla de acumulados.

Mejoras a la hora de calcular las tablas de medias _TEM
Ahora se tienen en cuenta los datos de las tablas de historicos para generar las lineas de la tabla de medias. Antes solo se tenian en cuenta las tablas en la conexion por defecto y ahora se tiene en ceunta la conexión por defecto y a demás la conexión de historicos del barco.

Se han cambiado los formatos de todas las fechas de la aplicación al formato AAAA-MM-DD HH:MM incluidos los gráficos.

Solucionado un error por el cual la carga no se mostraba correctamente en los eventos de ruta y puerto. Ahora ya se pueden visualizar en pantallas como por ejemplo en MRV

Se ha optimizado el cálculo de eventos para que a la hora de cargar acumulados o cii con rutas las pantallas cargen instantaneamente.

Cambios en funciones muy específicas como por ejemplo selINS() la cual afecta a calculos en algunas pantallas.

Solución sobre la marcha de errores varios que suceden a la hora de ir desarrollando la aplicación.

Añadida la conexión con el sistema LLOYS para envío de datos DNV.

Rework del sistema se zoom y marcadores de los mapas de google, ahora tienen autozoom en función a la linea que mostremos y las longitudes.

Cambio de la pantalla de detalles de evento:
-Mapas con lo anteriormente mencionado, mejora visual del tipo de evento que estamos consultando.
-Los acumulados y las diferencias ahora se calculan dentro del mismo dia, antes mostraba la difrencia entre el ultimo valor del dia anterior y el ultimo valor del dia en curso de esta forma no se visualizaban datos correctos para el primer y último dia del evento.
-Se ha arreglado el sistema de cálculos en la pantalla de evento que muestra dia a dia, ya que los valores mostrados eran los de la tabla de medias y el dato correspondiente al final del dia era el de las 18:00, ahora se obtienen los datos en maxima resolución y se ha optimizado la consulta para que solo obtenegamos el primer y último valor diario para que la consulta sea rápida.
-Mostramos también la la fecha inicial la hora donde empieza el evento y la hora a la que acaba en el último dia.

Varios cambios también en la pantalla de detalle de cada día muy similares a los anteriormente mencionados. Añadimos lo siguiente:
– Colores y la latra (P),(R) en función a si la telemetria es correspondiente a un evento de ruta o puerto

Cambios en la pantalla de acumulados:
Hemos decidido cambiar la pantalla de acumulados porque tardaba mucho en calcularse todo, asique vamosa simplificarla, cambiar su diseño y a la vez separar los acumulados de rutas de los acumulados generales. De momento esta por acabar, el nuevo formato será:
Mapa, descripción, tabla cumulados y si la pantalla es de un rango fechas que no es evento, mostraremos un timeline donde seleccionarlos para consultarlos.

Corregidos algunos errores a la hora de definir inicios y finales de ruta.

También se han realizado varias correcciónes de tickets…

Se ha modificado el recolector para que ahora se autolimpien y reseteen las tablas de ram_modbus y tememetrias para que nunca se puedan llegar al límite en la columna id de ambas tablas

Kpi_cfg Lenguaje del ‘path’ o ruta para obtener los equipos/variables

El sistema se basa en los tipos de equipo que queramos obtener.
Lo primero que debemos seleccionar es un tipo de equipo principal que queramos analizar, para ello usamos la letra ‘t’seguido del numero de tipo de equipo que queramos obtener. Por ejemplo un motor principal sería t1.
Si tenemos mas de un equipo asociado a ese tipo podemos seleccionarlo mediante su índice añadiendo la letra i y el numero de índice. Recordar que los índices empiezan en 0. Así pues si queremos obtener el motor auxiliar 3 sería t2i2.
Una vez obtenemos el equipo principal puede que queramos ir hacia uno o mas subequipos, para ello añadimos el separador para indicar que acabamos con el equipo padre y añadimos ‘-‘ seguido de esto de la misma forma que antes le indicamos
el subequipo esta vez con la letra ‘s’ en vez de la ‘t’, por ejemplo queremos acceder al caudalímetro del motor auxiliar 4 sería ‘t2i3-s14’ (equipo de tipo 2 índice 3 subequipo de tipo 14). Podemos seguir añadiendo subequipos de forma ilimitada uno tras
otro mediante la misma formula. Tenemos un sistema para detectar dentro de los subequipos uno muy en concreto cuando tenemos varios del mismo tipo dentro del equipo padre, y sería luego del número de tipo de subequipo añadir entre » en mayúsculas
un fragmento del nombre del equipo al que queremos acceder, por ejemplo, queremos el enfriador del motor principal 1 ER -> ‘t1i0-s13-s13’DESPUES DE’-s13’ESTRIBOR’ y si queremos el enfriador del motor principal 1 BR -> t1i0-s13-s13’DESPUES DE’-s13’BABOR’
Para obtener la variable, una vez acabamos con el equipo, añadimos el separador ‘|’ para indicar que empezamos con la variable y simplemente añadimos el id de la variable que queramos de ese equipo. Así pues pdemos obtener los m3 del caudalímetro del motor auxiliar 4 -> ‘t2i3-s14|421’,
otros ejemplos con los anteriores equipos: presión enfriador del motor principal 1 BR t1i0-s13-s13’DESPUES DE’-s13’BABOR’|402

En cuanto a las CACHE de los kpi funcionan de la siguiente manera:

-Hay dos tipo de CACHE en este sistema, uno mediante COOKIES de sesion y otro mediante BBDD.

Se pueden dar estos tres casos una vez llamamos a un kpi:

1- El kpi para ese barco no se habia llamado nunca antes. Entonces el sistema detecta cual es el equipo/variable asociado a ese kpi y lo almacena en la tabla de cache de kpi en BBDD (kpi_cfg_cache) Una vez esto se inserta tambien se añade este kpi a una COOKIE de sesión para no tener que recalcularla ni buscarla en todo el rato que estemos logeados.

2- El kpi se habia llamado antes pero acabamos de iniciar sesión: Aquí ya tenemos el equipo/variable en la tabla BBDD que almacena esos datos para ese centro, pero no tenemos la COOKIE de sesión, pero lo que el sistema irá a la BBDD a la tabla de cache (kpi_cfg_cache) y recupera los valores del kpi. Una vez los obtenemos los metemos en la COOKIE de sesión para el resto de nuestras consultas.

3- El kpi se habia llamado antes y ya lo habiamos consultado en la sesión actual: En este caso el kpi está almacenado en una COOKIE de sesión y ya no gasta tiempo en consultarlo a la BBDD ni mucho menos recalcular nada.

Dicho esto, si el path de un kpi es incorrecto ó añadimos un kpi específico para un barco cuando anteriormente ya habia consultado el por defecto, esos datos ya estan cacheados en la BBDD, por lo tanto para que los cambios en el path o los nuevos kpi especificos surjan efecto hay que borrar de la BBDD (kpi_cfg_cache) esos kpi asociados al centro en cuestión. Una vez lo hagamos ya se regenerarán con los nuevos valores.
También es recomendable reiniciar sesión, porque sinó la COOKIE de sesión nos devolverá el valor antes de recalcular nada.

El orden sería así:
Si existe COOKIE de sesión ya no va a la BBDD a obtener nada, si la COOKIE no existe irá a buscar los valores a la tabla de cache (kpi_cfg_cache). Si no existen datos en la tabla de cache, el sistema usará una función apra obtener los valores e insertarlos tanto en BBDD como en COOKIE.
Las COOKIES se renuevan una vez reiniciamos la sesión pero la cache de BBDD es permanente por lo que si se hacen cambios la forma de renovar esto es borrar el registro asociado a la tabla (kpi_cfg_cache)

Ahora el recolector avisará si alguna opcion del cfg.ini se ha introducido con un texto no reconocible por el recolector.
Aparecerá un mensaje de error en la pantalla indicando el codigo erroneo y la informacion asociada a el y se parará la ejecución del recolector.

-Creacion pantalla apikeys ubicado en la opcion de menú sistema
-Cracion pantalla infdnv ubicado en la opcion de menú sistema
-Correccion error acumulados cuando no existen tablas para fi y ff
-Bloques mas grandes de telemetrias enviados por el recolector para agilizar llegada de datos antiguos. Hasta ahora habia una limitación del envio de estos paquetes y los barcos podian tardar mucho en actualizarse porque a veces generaban mas telemetrias de las que enviaban. Ahora en el cfg.ini se puede ampliar ese numero de paquete de envio para agilizar estes casos.
-Script php para leer csv del barco en funcion a los gaps generados por el recolector e incorporarlos a la tabla telemetrias que luego sera enviada a la nube mediante el recolector. De esta forma complementamos vacios de datos a causa de algun fallo en el pc o recolector durante ese tiempo.
-Cambios en api/puttelemetria para incorporar telemetrias en bloques mas grandes y también se ha agilizado mas la función y los inserts en grupo a la base de datos para que cada centro ahora tarde mucho menos en insertar telemetrias.
-Cambio en la funcion _nomequ para que se le pueda pasar el parametro isDemo y sustituir el nombre del centro de los equipos a DEMO.
-Corrección a la hora de generar rutas en ciertos barcos con nombres de puertos que contenian la coma
-Se ha añadido una tabla en la pantalla del centro (panCEN) y pestaña APLICACIÓN en la cual podremos ver y editar las opciones de configuración que determinan varios de los procesos que el barco puede realizar como por ejemplo eventos de zona horaria, rutas cortas,…
-Se ha creado un conjunto de scripts que generan y actualizan una nueva base de datos Timescale (postgre) en la cual estamos haciendo pruebas de rendimiento con el fin de agilizar consultas demasiado grandes ahora mismo y poder almacenar mas datos ocupando menos espacio.
-Se ha creado un api de consulta para peticiones DNV con las funciones vessels y log_abstract que actualmente esta última se encuentra en fase de mejora
-Se ha creado un sistema de scripts que controla la zona horaria de un barco. Este sistema inserta en la bbdd los cambios de estas franjas horarias para saber en que momentos el barco ha cambiado.
Esto se utilizará en varios sitios como en la pantalla principal del centro donde ahora se muestra la hora local del barco.
También se usará en los calculos de las horas a las que el barco genera las lineas del fichero DNV
-Corrección de errores menores tal como; Consultas sql, logs que faltaban por incluir, nombres incorrectos de logs, tipicos errores menores de código que no necesitan abrir ticket.

-Se ha implementado un sistema de reordenacion de variables, lo cual permite meter direcciones desordenadas dentro del mismo equipo con saltos incluso. El programa reordena estas direcciones y analiza en que tamaño de bloque debe leer tomado como minimo 1 y como maximo el tamaño que nosotros iniquemos en el cfg.ini
Aqui dejo un ejemplo:
; EQUIPO 50850 MOTOR PRINCIPAL
IDEQ=50850
VAR=5000;394;RECOLECTOR_FO_Consumo_Instant_LitrosMilla_ME1; AUT
VAR=5006;411;RECOLECTOR_Consumption_ME1_FO_Type; AUT
VAR=5002;414;ECDIS_SPEED_LOG_VLW_Total_Distancia; AUT
VAR=5004;406;RECOLECTOR_ME1_Horas_Funcionamiento; AUT

; EQUIPO 50851 CAUDALIMETRO MP
IDEQ=50851
VAR=5008;395;RECOLECTOR_FO_Consumo_Instant_LitresHour_ME1; AUT
VAR=5510;403;RECOLECTOR_FO_Consumo_Diesel_Acumulado_ME1_ton; AUT
VAR=5012;618;RECOLECTOR_FO_Consumo_Fuel_Acumulado_ME1_ton; AUT

-Se han realizado mas pruebas sobre la deteccion de gaps para el futuro sistema de importacion de csv

-Se ha creado mediante codigo en el propio recolector un servidor modbus al cual se puede acceder mediante la ip de la maquina donde esta el recolector y el puerto que indiquemos en el cfg.ini
Este servidor devolverá en las direcciones que nosotros indiquemos el estado de los hilos del recolector. Los valores serán 1 para cuando todo va bien (OK) y 0 para cuando va mal (KO)
Las nuevas opciones de configuracion son las siguientes:
; Define las direcciones de memoria y variables que se exponen para su consulta en MODBUS
; MODBUS-SERVER
; Puerto por defecto usado para el servidor
mb_srv_port = 502

; estado de comunicación entre el recolector .net y el PLC
mb_srv_mb = 100

; estado de inserción de valores en la tabla RAM ram_modbus
mb_srv_ramdb = 101

; estado de inserción de valores en la tabla DISCO telemetrias
mb_srv_diskdb = 102

; estado de comunicación con central/nube vía API ej.cfg servidor = https://argos-coterena.com
mb_srv_web = 103

-Correccion al sql para calcular rutas actuales y otros errores a la hora de calcular rutas de las que no se conocia el puerto.
-Correccion a la hora de calcular puertos los cuales en el sql vienen con la misma hora el inicio y final (mov:0, ini:1, fin:1), ahora estos si cumplen el tiempo seran añadido tambien al array como puerto.
-Correccion menor para el touza con una traduccion que impedia añadir turbo b a las variables especificas
-Correccion a la hora de eliminar las coordenadas (0,0) sin tener en cuanta la distancia al punto correcto, evitando asi pequeños desajustes.
-Correccion menor a ocultar elementos del menú eliminado la cache para estos y incorporamos a las excepciones el informe frio
-Se ha añadido al informe frio la posibilidad de que los equipos de frio tuneles, bodegas, etc.. puedan tener subequipos y estos sean los que mostramos en las gráficas
-Moficacion al bloque B1 en la creacion de estructuras de centro para mostrar el CONSUMO ACUMULADO de los MM.AA. en caso de no tener caudalimetro los auxiliares. Se habilitaria asi tambien cambios en el informe de consumo
-Correccion en los containers de las tablas en informe de consumo y propulsion que bloqueaban la vista a las gráficas
Optimización tabla equipos la cual tardaba de forma exagerada en cargar
-Sistema de importacion y exportacion de estructuras de centros csv
-Correccion en algunas funciones que tienen que ver con obtener el arbol de equipos
-Reordenacion de variables en recolector
-Recoleccion dinamica en funcion al numero de direcciones consecutivas por bloque determinadas tambien por el tamaño del paquete
-Correccion de problema que hacia que se duplicaran lances u otros eventos comprobando si el evento ya existia
-Centrado verticalmente el contenido de las celdas de las tablas
Se ha limitado el numero maximo de variables a la hora de guardar un plan de tendecias
-Se ha arreglado el problema en la funcion que leia los elementos seleccionados por defecto en los combos multiples
-Se ha cambiado en la respuesta del csv AÑADIDA por CREADA para evitar la Ñ que producia un error al leer el csv
-Se ha modificado la tabla de app_paises para que ahora podamos marcar que paises perteneces a la UE
-Se ha corregido el error del filtro de la tabla de puertos
-Se han eliminado las tablas paises, provincias y se ha renombrado poblaciones a app_poblaciones

Se han añadido varios controles de funcionamiento de los hilos del recolector para que a simple vista se pueda ver tanto los tiempos como si ha sucedido algun error en ese hilo que debe ser revisado en los logs o habilitar el modo dbug para estudiarlo.

El formato que veremos es el siguiente:
MB2DB v24.01.08: 17:53:23.480 Running MB(OK):62ms / RAMDB(OK):5ms / DISKDB(OK):0ms / WEB(OK):0ms…

MB2DB v24.01.08 -> Esta parte hace referencia a la versión del programa a simple vista. La version contiene el año, mes y dia en el que se compiló la versión.

17:53:23.480 -> Hora:minuto:segundo.milisegundo en el que esta el programa ejecutandose

MB(OK):62ms -> Funcionamiento del hilo de lectura modbus, en el podemos ver un OK o KO dependiendo de si algo ha sucedido en el proceso de lectura de datos. Se acompaña del tiempo que ha tardado en completar una vuelta a la funcion del hilo modbus.

RAMDB(OK):5ms -> Funcionamiento del hilo de escritura modbus en la tabla ram de la base de datos, en el podemos ver un OK o KO dependiendo de si algo ha sucedido en el proceso de escritura de datos. Se acompaña del tiempo que ha tardado en completar una vuelta a la funcion del hilo database ram.

DISKDB(OK):0ms -> Funcionamiento del hilo de escritura en la tabla de disco de la base de datos, en el podemos ver un OK o KO dependiendo de si algo ha sucedido en el proceso de escritura de datos. Se acompaña del tiempo que ha tardado en completar una vuelta a la funcion del hilo database disk.

WEB(OK):0ms -> Funcionamiento del hilo de comunicacion con la nube(web-api), en el podemos ver un OK o KO dependiendo de si algo ha sucedido en el proceso de comunicacion-recepcion-emision de datos a la nube. Se acompaña del tiempo que ha tardado en completar una vuelta a la funcion del hilo cloud(web).