ACADEMIA POLITÉCNICA MILITAR
El Boletín Científico Tecnológico es una publicación oficial de la Academia Politécnica Militar, de periodicidad anual, cuyo sistema de arbitraje es de doble ciego.
Es una instancia de reflexión académica que ofrece su estructura a profesionales, mun-do académico, estudiantes, investigamun-dores, mun-docentes y, en general, a tomun-dos los lectores y personas interesadas en el conocimiento científico tecnológico de aplicación militar.
Estas páginas les insta a compartir con el solo espíritu de conocer los distintos logros académicos alcanzados en pos de la investigación y la ciencia.
Su MISIÓN es constituir un espacio académico para la difusión de investigaciones, tanto civiles como militares, que versan sobre el desarrollo tecnológico y la investigación científica en el ámbito de la defensa.
Como VISIÓN, el Boletín Científico Tecnológico busca ser un referente nacional en las áreas de las tecnologías de la defensa y de la reflexión académica al cumplirse el centenario de la Academia Politécnica Militar.
Dirección web: www.boletincientifico.cl
Dirección postal: Avda. Valenzuela Llanos 623, La Reina, Santiago, Chile. Teléfono (562) 226683654.
Todos los artículos son responsabilidad de sus autores y no reflejan ni comprometen la opinión de la Academia Politécnica Militar ni del Ejército de Chile.
El Consejo Editorial se reserva el derecho de publicar o rechazar los artículos que no observen las normas editoriales del Boletín. Diseño e impresión: Ediciones e Impresiones IGM.
Corrección de texto e imágenes: Academia Politécnica Militar. Impreso en Chile/Printed en Chile.
Nº 22, JULIO 2018 ISSN 0718-1191
Director
Coronel Sergio Nazar Martínez
Oficial de Ejército del arma de Infantería. Ingeniero Politécnico Militar en Sistemas de Armas mención Química de la Academia Politécnica Militar. Magíster en Ciencias Militares con mención en Prepara-ción, Evaluación y Gestión de Proyectos Privados Sociales y de Defensa de la Academia Politécnica
Militar. Magíster en Sistemas de Armas y Vehículos Militares Academia Politécnica Militar. Actual-mente se desempeña como Director de la Academia Politécnica Militar del Ejército de Chile.
Editor y Secretario
Teniente Coronel Héctor Inostroza Montero
Oficial de Ejército del arma de Infantería. Ingeniero Politécnico Militar en Sistemas mención Me-cánica de la Academia Politécnica Militar. Magíster en Gestión de Activos y Mantenimien-to de la Universidad Técnica Federico Santa María. Actualmente se desempeña como Jefe
del Centro de Estudios en Ciencia y Tecnología de la Academia Politécnica Militar.
CONSEJO EDITORIAL Presidente
Coronel Sergio Nazar Martínez
Director de la Academia Politécnica Militar
Consejeros
José Manuel Llanos Acevedo Teniente Coronel
Ingeniero Politécnico Militar, mención comunicaciones. Magíster en Ciencias de la Ingeniería, mención en Tecnologías de
Sis-temas de Mando y Control, Academia Politécnica Militar.
Magíster en Ciencias de la Ingeniería, mención en Sistemas de Ar-mas y Vehículos Militares, Academia Politécnica Militar.
Leonardo Albornoz Salinas Teniente Coronel
Ingeniero Politécnico Militar, mención Química.
Magíster en Ingeniería de Sistemas Logísticos, Academia Politécnica Militar. Carlos Düring Kunstmann
Teniente Coronel
Ingeniero Politécnico Militar en Sistemas de Armas, mención Mecánica. Álvaro Jofré Elorza
Teniente Coronel
Ingeniero Politécnico Militar en Sistemas de Armas, mención Mecánica. Magíster en Ciencias de la Ingeniería, mención Sistemas de
Ar-mas y Vehículos Militares, Academia Politécnica Militar. Francisco Villalobos Sepúlveda
Mayor
Ingeniero Politécnico Militar en Sistemas de Armas, mención Mecánica. Magíster en Ciencias de la Ingeniería, mención Sistemas de
Ar-mas y Vehículos Militares, Academia Politécnica Militar.
Magíster en Ingeniería de Sistemas Logísticos, Academia Politécnica Militar. Verónica Caselli Benavente
Mayor
Ingeniero Politécnico Militar en Administración de Recursos de Defensa. Óscar Rodríguez Undurraga
Mayor
Ingeniero Politécnico Militar en Sistemas de Armas, mención Vehículos Militares. Juan Pablo Palacios Cergna
Mayor
Ingeniero Politécnico Militar en Sistemas, mención Geoinformática. Yorma Sepúlveda Paredes
Profesor Civil
Químico, Universidad de Santiago de Chile.
Magíster en Ciencias de los Materiales, Universidad de Santiago de Chile. Cinthya Lepin Rueda
Profesor Civil
Licenciada en Letras, mención Lingüística y Literatura Hispánicas, Pontificia Universidad Católica de Chile. Magíster en Letras mención Lingüística, Pontificia Universidad Católica de Chile.
Con profunda estima, el presente número está dedicado al Brigadier Víctor Aguilera Acevedo (1941-2018), oficial que ingresó al Ejército de Chile en 1957 y que dedicó gran parte de su vida al servicio de la institución.
Resulta imposible pasar por alto el aporte que el Brigadier Aguilera sig-nificó en cada una de las unidades en donde se desempeñó como oficial de excelencia, en especial, en la Academia Politécnica Militar, lugar del que egresó en 1974 y que tuvo el privilegio de contar con su experiencia en el área de investigación durante los años 2009 y 2016.
Entre todo el importante legado que generosamente compartió con nosotros, se destaca su asesoría a los alumnos memoristas de pre y pos-grado, sus conocimientos para la ejecución de proyectos de investigación y desarrollo, y sus publicaciones, tanto de textos militares, de educación y científicos, como el Libro de la Academia Politécnica Militar “pasado,
pre-sente y futuro” (2016); Libro de Oratoria y Elocuencia Militar (1985); Libro de Poder Militar y Energía Atómica (1981); y varios artículos para el Boletín
Científico Tecnológico, a saber, “El Líder Adaptativo y las Organizaciones Complejas”, “Las cinco fuerzas que impactan en la educación de La So-ciedad del Conocimiento” y “Energías Renovables”.
Todos aquellos que tuvieron la suerte de conocerlo y trabajar con él reconocen no solo su dimensión profesional como un oficial de excelencia, digno integrante del parche negro y un brillante Ingeniero Politécnico Militar, sino que también lo identifican por haber sido un excelente profesor y, sin duda, un líder innato.
Estimado Brigadier, que las investigaciones plasmadas en estas páginas logren estar a su altura. Q.E.P.D.
Editorial ... 11 Mejora en las técnicas de simulación para el entrenamiento militar para la toma
de decisiones a través de una aplicación nativa integrada en un software de simulación constructiva
MAY. Danilo Contador Rojas, Sr. Ricardo Pino Videla, Sr. Claudio Miranda
Sepúlveda. ... 15
Mantenimiento predictivo utilizando Matlab
Sr. José Pereda Barrales. ... 35
Obtención del coeficiente de arrastre de los proyectiles, mediante la dinámica de fluidos computacional
MAY. Marcelo Grandón Díaz. ... 55
Estimación de la vida útil remanente de un vehículo especial de ingenieros del cuerpo militar del trabajo
TCL. Pablo de la Maza Aguayo. ... 69
Infraestructura de datos espaciales aplicada a catastro en la República Argentina
TCL. Gustavo Ariel Silistria. ... 93
Innovación en la educación y la industria militar, una gran oportunidad
MAY Alberto Villarroel Rivera. ... 111
Diseño de un plan de vigilancia para el fusil GALIL ACE 22 NC, para ser aplicado en la etapa de operación y mantenimiento del ciclo de vida
MAY. Felipe Torres Arias... 137
Propuesta de aplicación informática para apoyar el sistema de organización del Ejército
MAY. Carlos Herrera García. ... 179
EDITORIAL
BOLETÍN CIENTÍFICO TECNOLÓGICO
En el marco del proceso de modernización del Ejército de Chile, se determinó que este debe contar con un sistema de investigación y desarrollo que abarque las diferen-tes áreas del quehacer institucional, cuyos productos contribuyan a los procesos de gestación de la resolución en aquellos aspectos relativos al desarrollo de la capacidad militar y se orienten a la búsqueda de soluciones que coadyuven a la Fuerza Terrestre.
A este respecto, en la Academia Politécnica Militar (ACAPOMIL) se establece el Centro de Estudios en Ciencia y Tecnología (CECTAP), el que surge como respuesta a la nece-sidad de organización y establecimiento del lineamiento en la actividad de investigación y desarrollo en la institución, lo que da lugar a la generación de capacidades y fortalezas en aquellos campos fundamentales para el desarrollo tecnológico.
Con el objeto de coordinar esfuerzos, administrar de la mejor forma los recursos exis-tentes para realizar investigación y desarrollo y aprovechar las capacidades generadas,
SERGIO NAZAR MARTÍNEZ Coronel
la institución, estableciendo claramente los ámbitos de acción abarcados, la estructura, las tareas fundamentales y los procesos.
A través de este centro, la ACAPOMIL busca cooperar con diversas tareas, tales como: desarrollar las capacidades institucionales, por medio de la gestión y ejecución de actividades de investigación y desarrollo, en temas relativos a la seguridad y defensa; generar investigación para el combate, generación de doctrina y docencia; investigar sobre ciencia y tecnología y salud u otros aspectos que el devenir institucional y tec-nológico determinen como necesarios, procurando que sus resultados contribuyan al mantenimiento y desarrollo de la capacidad militar, diferenciándose de aquellos estudios e investigaciones que efectúan otros organismos institucionales como parte de sus procesos internos.
Con la finalidad de contribuir con las tareas fundamentales dispuestas por la institu-ción, la ACAPOMIL lanza un nuevo número más de su Boletín Científico Tecnológico, el que, al igual que los últimos dos números, no solo busca reflejar la actividad de I+D realizada en el instituto, sino que también organizar y difundir los conocimientos gene-rados por la investigación de colaboradores externos, tanto civiles como militares. De esta forma, esta publicación busca ampliar la perspectiva de la aplicación de la Ciencia y Tecnología en la institución.
En esta edición mostramos con orgullo las contribuciones tanto de investigadores avezados, cuyos años de experiencia ponen en cuestionamiento la necesidad de la ciencia, la tecnología y la innovación en el contexto actual, así como también damos cabida a investigadores incipientes, los que a través de análisis aplicados buscan en-tregar luces para mejorar las herramientas logísticas con las que cuenta la Institución.
ARTÍCULOS
BOLETÍN CIENTÍFICO TECNOLÓGICO
ACADEMIA POLITÉCNICA MILITAR
MEJORA EN LAS TÉCNICAS DE SIMULACIÓN
PARA EL ENTRENAMIENTO MILITAR PARA
LA TOMA DE DECISIONES A TRAVÉS DE UNA
APLICACIÓN NATIVA INTEGRADA EN UN
SOFTWARE DE SIMULACIÓN CONSTRUCTIVA
MAY. DANILO CONTADOR ROJAS / SR. RICARDO PINO VIDELA / SR. CLAUDIO MIRANDA SEPÚLVEDA
SIMULACIÓN PARA EL ENTRENAMIENTO
MILITAR PARA LA TOMA DE DECISIONES
A TRAVÉS DE UNA APLICACIÓN
NATIVA INTEGRADA EN UN SOFTWARE
DE SIMULACIÓN CONSTRUCTIVA
MAY. Danilo Contador Rojas.1
Sr. Ricardo Pino Videla.2
Sr. Claudio Miranda Sepúlveda.3
Resumen: Este artículo presenta la incorporación de entidades reales en un software de simulación constructiva y virtual, por medio de la integración LVC.4 Este concepto es utilizado para ejercicios de
com-probación, de planificación y entrenamiento en distintos niveles de la conducción. Lo anterior ha sido desarrollado a través de una aplicación móvil basada en Android, como respuesta al acceso masivo a teléfonos inteligentes y a la gran cobertura de redes celulares. El modelo propuesto entregará la posibilidad de conocer en tiempo real cómo se desplazan las unidades en terreno, además de brindar la capacidad de traducir la cadena de datos de GPS en lenguaje de simulación, lo que hace posible crear un ambiente sintético de integración LVC, abriendo la puerta al desarrollo de aplicaciones orientadas a la gestión de recursos, durante un entrenamiento de combate o entrenamiento ante emergencias y/o catástrofes con apoyo de la simulación.
Palabras clave: Simulación constructiva, aplicación, c++, data GPS, protocolo de redes, LVC.
Abstract: this article presents the incorporation of real entities in a virtual and constructive simulation software, through LVC integration,
1 Ingeniero Politécnico Militar en Sistemas TICs.
2 Cartógrafo. Centro de Modelación y Simulación del Ejército. 3 Ingeniero Informático. Centro de Modelación y Simulación del Ejército. 4 LVC: Live, Virtual and Constructive simulation.
normally used for planning and training checking exercises at different levels of driving. This has been developed through a mobile application based on Android, in response to massive access to smartphones, and the large coverage of cellular networks. The proposed model will provide the possibility to see in real time how the units move on the ground, and it will provide the ability to translate the GPS data chain into simulation language, which makes it possible to create a synthetic LVC integration environment, leads the development of applications oriented to the management of resources, during a combat training or emergency and/or catastrophes training with support of simulation.
Keywords: Constructive simulation, application, C++, GPS data, net-work protocol, LVC.
1. INTRODUCCIÓN
Las tecnologías utilizadas para el entrenamiento por medio de la simulación pueden ser implementadas tanto para operaciones militares de guerra como en procedimientos de otro tipo. Además, tienen como finalidad buscar una herramienta complementaria para el entrenamiento y la toma de decisiones.
El Ejército de Chile cuenta con distintos tipos de simuladores, los que se cla-sifican en: simulación virtual, constructiva y en vivo. Sin embargo, no considera la integración de estos recursos para potenciar sus capacidades y obtener resultados en escenarios comunes para la evaluación de la maniobra.
Hasta entonces, para el entrenamiento de los cuarteles generales y su Estado Mayor, se utiliza la simulación constructiva; en tanto, para el entrenamiento de las tripulaciones de plataformas aéreas o terrestres, se utiliza la simulación virtual; y, para el entrenamiento de unidades de niveles de escuadra, sección o unidades fundamentales, se puede utilizar principalmente la simulación en vivo.
No obstante a lo anterior, estas tres herramientas se pueden integrar para entregar un mayor realismo a la planificación y ejecución de la maniobra. Esto gracias a que existen protocolos de comunicación que permiten integrar las distintas plataformas y presentarlas en un panorama común, lo que incrementa el nivel de inmersión de la simulación, debido a la capacidad de poder visualizar la interacción en un mismo escenario de entidades reales y virtuales lo que aumenta la capacidad de resolución de los comandantes.
El conjunto de herramientas que permiten generar un entorno LVC normalmente es de difícil acceso y de valores elevados. La implementación de una solución de bajo costo que permita seguir unidades en terreno en una interfaz de simulación aparece entonces como propuesta interesante.
En los últimos años, el Centro de Modelación y Simulación del Ejército (CEMSE) ha explorado una serie de tecnologías en el marco de la simulación. Esta experiencia basada en la experimentación, desarrollo y explotación de herramientas permite evi-denciar el vasto conocimiento acumulado en estas materias. Es por lo anterior que la búsqueda de nuevas tecnologías de bajo costo y fácil acceso se ha transformado en un eje de acción de este centro.
Los procesos de experimentación con simulación virtual y los procesos de comprobación de planificación y capacidades de TOEs mediante herramientas de simulación han permitido visualizar que la construcción de una herramienta para comprobación de planificaciones sea una realidad cercana y posible. Dado lo
ante-rior, nace la pregunta ¿es posible utilizar un software robusto como VR-FORCES5
(VRF) como la interfaz de un sistema de entrenamiento de emergencia y, por qué no decirlo, como sistema de mando y control alternativo? La respuesta pareciera ser positiva, pero los costos de licenciamiento para ser implementados en toda la fuerza terrestre (FT) hace que sea restrictivo el uso de este software a nivel masivo.
2. DESARROLLO
Es así donde nace la idea de buscar una alternativa por medio del desarrollo de una aplicación nativa, propia y colaborativa que aparece entonces como solución. La experiencia indica que, independiente de la plataforma, lo importante es la ges-tión de los datos, como los entregados por un GPS (coordenadas) y la cartografía digital (catastrales). A este respecto, lo vital es conocer y entender los estándares de cada uno de ellos de manera tal que sea posible su conversión, exportación y visualización de forma dinámica y en tiempo real.
Términos como SISO,6 DIS7 o HLA8 son poco familiares, pero, tomando en
con-sideración las necesidades institucionales, se vuelven fundamentales a la hora de generar un sistema integrado de simulación LVC que, en un futuro, pudiera ser parte
5 VR-Forces, software de simulación constructiva adquirido por el Ejército de Chile por medio del Proyecto Rapel el año 2011. 6 SISO: Simulation Interoperability Standards Organization.
7 DIS: Distributed Interactive Simulation. 8 HLA: High Level Arquitecture.
de un sistema de gestión, entrenamiento y de comprobación de planificación para
operaciones militares de guerra y MOOTW.9
Por medio del software de simulación constructiva VRF, que es una plataforma de generación de fuerzas por computador (Computer Generated Forces, CGF), y el
software de simulación virtual “Virtual Battlespace 3” (VBS3), que es una solución de
entrenamiento virtual flexible, se pueden realizar ejercicios de entrenamiento, los que se integran a través de protocolos de comunicación HLA o DIS, permitiendo utilizar los mismos escenarios, visualizar las mismas entidades y compartir los datos que se generan en ambos entornos de simulación. Esto también aplica para cualquier
software de simulación que considere protocolos de comunicación DIS o HLA.
El desafío del estudio realizado fue poder incorporar el tercer factor de la simu-lación para el entrenamiento, a saber, la simusimu-lación en vivo. Para ello se definió como alcance la necesidad de contar con un prototipo que demuestre el desarrollo realizado con la tecnología disponible. Se definió como requerimiento contar con un dispositivo de transmisión de datos de posicionamiento y redes de telecomuni-caciones, para lo cual solo era necesario establecer la ubicación georreferenciada de la entidad real en el escenario de simulación constructivo y virtual a través del protocolo de comunicaciones DIS que permita la interacción entre el simulador constructivo y un dispositivo geolocalizador, con el objetivo de que actúe como canal de transmisión de datos asociado a la ubicación de entidades militares (baja transmisión de datos).
Para lo anterior se realizó un análisis de distintos dispositivos de posicionamiento considerando las siguientes variables:
1. movilidad,
2. cantidad restringida de datos, 3. localización,
4. conexión permanente, y
5. envío de señales sostenidas en el tiempo, con intervalos menores a cinco segun-dos.
El análisis de las tecnologías de geolocalización se puede visualizar en la tabla Nº 1 en la que se presentan las ventajas (+) y desventajas (-) de su implementación.
Tabla 1. Características positivas y negativas de tecnologías de geolocalización analizadas
TECNOLOGÍA ANÁLISIS DE TECNOLOGÍA
GSM/GPRS (+) Protocolo generalizado(+) Alto alcance (-) Baja precisión
GPS
(+) Alta precisión
(+) Alta compatibilidad con otros dispositivos (+) Confiabilidad
(+) Económico
(+) Disponibilidad a nivel global (+) Bajo consumo energético
3G
(+) Mayor velocidad de transmisión de datos que GSM (+) Transmisión a través de Internet
(-) Mayor consumo energético (+) Disponibilidad a nivel global (-) Baja precisión
4G
(+) Mayor velocidad de transmisión de datos que 3G (+) Transmisión a través de internet
(-) Mayor consumo energético (+) Disponibilidad a nivel global (-) Baja precisión
Intel Stick + GLONASS
(+) Mayor disponibilidad de satélites para geolocalización (+) Mayor cobertura
(-) Mayor consumo de energía, dependencia de alimentación eléctrica externa
(+) Uso de satélites GPS y GLONASS Dispositivo Android (+) Uso de aplicaciones personalizadas(-) Baja optimización de baterías
(+) Amplia disponibilidad de tecnología Fuente: elaboración propia.
Primero, se definió como la tecnología más adecuada para el prototipo esperado el uso de GPS, debido a que puede ser implementado en variadas presentaciones. Luego se definió el desarrollo de una aplicación en la plataforma Android, utilizada como Front-End del software del prototipo. Lo anterior se debió principalmente por las siguientes razones:
• desarrollo de software de código abierto,
• existe una alta disponibilidad de equipos compatibles, • un menor costo futuro de implementación para ejercicios,
• la portabilidad, y
• baterías de alto rendimiento.
A continuación, en la tabla Nº 2 se presentan las características de los protocolos de comunicación analizados:
Tabla 2 (a). Comparación de tecnologías de redes de transmisión de datos PROTOCOLO DE
COMUNICACIONES GSM/GPRS BAM WIFI LORAWAN
Banda de frecuencia 850/900; 1800/1900 Mhz 225-3700 MHz 868 MHz Máx. transmisión de señal 168 Kb/s 3-42 Kb/s 0.3 - 50 Kb/s Rango nominal 2 - 35 km - 100 - 1000 km Nº de bandas de fre-cuencias 124 - 10 - 64 Máx. Nº de nodos 1000 10 -Ventajas comparativas
Alto rango de alcance Bajo costo
Muy disponible donde hay cobertura celular
Portabilidad, velocidad, alta capacidad de
trans-misión Alto rango de alcance
Aplicaciones InternetMonitorización Control Internet móvil Transmisión de video Comunicación en redes locales Transmisión de datos de bajo nivel Sensorización Comunicación M2M Fuente: elaboración propia.
Tabla 2 (b). Comparación de tecnologías de redes de transmisión de datos PROTOCOLO DE
COMUNICACIONES BLE SIGFOX SUB-BANDA Z-WAVE ZIBBEE
Banda de frecuen-cia 2.4 GHz 868 GHz 900 MHz 868/915 MHz; 2.4 GHz Máx. transmisión de señal 720 Kb/s 100 bps 9,6 - 40 - 100 Kb/s 250 Kb/s Rango nominal 10 m 30 - 50 km 30 m 10 - 1000 m Nº de bandas de frecuencias 79 - - 16 Máx. Nº de nodos 8 - 232 >65000
PROTOCOLO DE
COMUNICACIONES BLE SIGFOX SUB-BANDA Z-WAVE ZIBBEE
Ventajas compa-rativas Bajo costo Bajo consumo de potencia Confiabilidad y ve-locidad Bajo costo Bajo consumo energético Confiabilidad Anti-jamming Transmisión de pe-queños paquetes de datos Optimización de re-cursos energéticos Confiabilidad Potencia Costo Aplicaciones Transmisión de da-tos a nivel local Reemplazo de sis-temas cableados en redes locales Transmisión de pa-quetes de datos pequeños en largas distancias Sensorización Monitorización Control Internet of Things (IoT) Sensorización Comunicación ina-lámbrica de corto alcance Monitorización Control
Fuente: elaboración propia.
Una red de tipo celular (GSM/GPRS, 3G) resultó ser la que mejor se ajustaba, de-bido a su extenso desarrollo y disponibilidad, su fácil implementación y el bajo costo considerando un sistema basado en redes.
Una vez seleccionada la tecnología de geolocalización y de transmisión de da-tos, se definió el tipo de desarrollo de software, para lo que se utilizó el lenguaje de programación C++, con la finalidad de integrar las coordenadas de posicionamiento GPS a la red a través de protocolo DIS conectada al simulador constructivo VRF, considerando latitud, longitud y altura de las entidades reales.
De esta forma, el diseño conceptual del prototipo (figura Nº 1), consideró personas reales (entidades) que representan la simulación en vivo, las que se desplazan en un escenario real controlado, debiendo transmitir su ubicación obtenida por GPS a través del servidor WEB para la app LVC con la tecnología GSM/GPRS. Las coordenadas se reciben en un servidor, ubicado en un lugar predeterminado, en el cual, a través de una API desarrollada en lenguaje C++, se traduce la información de geolocalización al protocolo DIS, la que se transmite a la red DIS, donde se encuentra físicamente el servidor. Esta información en la red DIS es recibida por el simulador constructivo VRF, el que crea entidades virtuales, representando las dos personas reales que se desplazan en un terreno controlado. Simultáneamente, el simulador constructivo, muestra entidades virtuales del software VBS3, además de las entidades propias de VRF, creando así un ambiente sintético.
Figura Nº 1: “Diseño conceptual”. Fuente: elaboración propia.
2.1. PROTOCOLO DE PRUEBAS DE LA APLICACIÓN
El protocolo para realizar la prueba de la aplicación con la finalidad de visualizar en-tidades en vivo en el simulador constructivo consta de dos partes, como se presenta a continuación:
1) Front-End: corresponde a la interfaz gráfica de la aplicación Android, en la que
se carga la aplicación LVC-CEMSE, que captura y transmite la información de geolocalización de la entidad en vivo. Esta información la recepciona el software
Back-End y lo asigna a la entidad previamente definida según código SISO.
El número de Front-End es limitado solo por los dispositivos Android que se tengan disponibles.
2) Back-End: software de lectura y emisión de posición de las entidades a integrar
en el simulador constructivo, desarrollado mediante un script en lenguaje C++. Este funciona independiente del Front-End y no tiene límite de ejecuciones si-multáneas.
Figura Nº 2: “Diagrama de funcionamiento de Back-End y Front-End”. Fuente: CEMSE, DIVDOC, 2016.
Para la configuración de entidades en vivo, se compilaron cuatro ejecutables con un Script en lenguaje C++ que cumplieron la función de Back-End, cada uno con una configuración de características iniciales. Los ejecutables obtienen la información de ubicación almacenada en un archivo asociado, los que fueron previamente configurados mediante la aplicación Front-End en el equipo Android. Luego, según el código SISO que se ingresa al momento de la ejecución, empaquetan la información en un PDU y lo emiten a la red.
La mayoría de los receptores GPS soportan el protocolo de comunicaciones estándar NMEA. A partir de este protocolo, el GPS envía un flujo constante de datos al computador. La aplicación LVC captura estos datos y los convierte a un formato estándar denomina-do PDU. Esta estructura permite incorporar la posición en coordenadas XYZ, además del código SISO asociado a la entidad que está siendo monitoreada. Posteriormente, se transmite a una red de simulación con protocolo DIS en forma de entidades que se representa en tiempo real sobre el escenario. El código SISO, anteriormente mencionado, es el que permite que la unidad monitoreada no solamente se pueda visualizar, sino que, además, permite que esta interactúe con las entidades generadas en el computador, lo que, a su vez, posibilita la visualización de las entidades de manera independiente en el simulador constructivo VRF.
A continuación se presenta un extracto del código que hace referencia al proceso explicado anteriormente: Inicio Fin Front-end (Equipo android) Black-end Visualización entidad en VR-Forces Envía Información de
localización. Black-end descarga información
Emite PDU’s a la Red local Servidor
Tabla 3. Líneas de comando que entregan la información que caracteriza a la entidad que se envía a la red #include <iostream> #include <fstream> #include “KDIS/PDU/Entity_Info_Interaction/Entity_Sta-te_PDU.h”
#include “KDIS/Network/Connection.h” // A cross platform connection class.
#include <wininet.h>
// Lets declare all namespaces to keep the code small. using namespace std;
using namespace KDIS; using namespace DATA_TYPE; using namespace PDU; using namespace ENUMS; using namespace UTILS; using namespace NETWORK; int main()
{
// First create the PDU we are going to send, for this example I will use a
// Entity_State_PDU, When this PDU is sent most DIS applications should then show a new entity
EntityIdentifier EntID( 1, 3001, 3 ); ForceID EntForceID( Friendly );
//EntityType EntType( 3, 1, 225, 3, 0, 1, 0 ); // A Civilian male EntityType EntType( 3, 1, 225, 1, 41, 1, 0 ); Vector EntityLinearVelocity( 0, 0, 0 ); ifstream fin(“gps-position-team1.txt”); double latitud; double longitud;
fin >> latitud >> longitud; // Convert local coordinate systems to DIS
//KFLOAT64 Lat = -34.58648, Lon = -71.69347, Alt = 385; // West coast of USA
//KFLOAT64 Lat = latitud, Lon = longitud, Alt = 17;
KFLOAT64 Lat = 36.000894, Lon = -122.992339, Alt = 17;
KFLOAT64 GeoX = 0.0, GeoY = 0.0, GeoZ = 0.0; KFLOAT64 Heading = 0.0, Pitch = 0.0, Roll = 0.0; KFLOAT64 Psi = 0.0, Theta = 0.0, Phi = 0.0; KDIS::UTILS::GeodeticToGeocentric( Lat, Lon, Alt, GeoX, GeoY, GeoZ, WGS_1984 );
KDIS::UTILS::HeadingPitchRollToEuler( DegToRad( Hea-ding ), DegToRad( Pitch ), DegToRad( Roll ), DegToRad( Lat ), DegToRad( Lon ), Psi, Theta, Phi );
WorldCoordinates EntityLocation( GeoX, GeoY, GeoZ ); EulerAngles EntityOrientation( Psi, Theta , Phi ); EntityAppearance EntEA;
DeadReckoningParameter DRP( Static, Vector( 0, 0, 0 ), Vector( 0, 0, 0 ) );
EntityMarking EntMarking( ASCII, soldado», 5 ); EntityCapabilities EntEC( false, false, false, false ); // Create the PDU
Entity_State_PDU Entity( EntID, EntForceID, EntType, EntType, EntityLinearVelocity, EntityLocation, EntityOrientation, EntEA, DRP, EntMarking, EntEC ); // Set the PDU Header values
Entity.SetExerciseID( 1 );
// Set the time stamp to automatically calculate each time encode is called.
Entity.SetTimeStamp( TimeStamp( RelativeTime, 0, true ) );
try {
// Note: This address will probably be different for your network.
Connection myConnection( “192.168.0.255” ); // Encode the PDU contents into network data
EntityIdentifier Ent(1, 3000, 4); //Ingreso de parámetros de la entidad(Número de ejercicio, puerto de comunicación, número de entidad)
ForceID EntForceID(Friendly); // Amigo, enemigo o neutral
EntityType EntType(3, 1, 225, 32,
1, 40); //Tipo de entidad según código SISO
Vector EntityLinearVelocity(0, 0, 0); // Velocidad de la entidad
A continuación, se presenta un ejemplo de las PDU`s configuradas asociadas a un archivo TXT en el servidor web www.cemse-lvc.cl y que, a su vez, se pueden configurar independientemente con diferentes entidades, de acuerdo con el código SISO que se ingresa:
• Example-Entity_State_PDU1.exe→www.cemse-lvc.cl/gps.txt - Fuerza/Equipo de la entidad: Azul
• Example-Entity_State_PDU2.exe→www.cemse-lvc.cl/gps2.txt - Fuerza/Equipo de la entidad: Rojo
• Example-Entity_State_PDU3.exe→www.cemse-lvc.cl/gps3.txt - Fuerza/Equipo de la entidad: Azul
• Example-Entity_State_PDU4.exe→www.cemse-lvc.cl/gps4.txt - Fuerza/Equipo de la entidad: Rojo
Para lo anterior, se presenta el protocolo de ejecución del Back-End y Front-End a través del siguiente diagrama de la figura Nº 3:
Figura Nº 3: “Diagrama de flujo ejecución Back-End y Front-End”. Fuente: CEMSE, DIVODC, 2016.
ENVÍO DE PDU`S A LA
RED INICIAR SEGUIMIENTO DE APLICACIÓN INICIAR FRONT-END INGRESE DIRECCIÓN DE PHP SEGÚN Nº DE ENTIDAD INGRESE SISO INICIO FIN INICIAR BLACK-END Visualización de entidades en vivo en VRF
2.2. PROTOCOLO DE INTEGRACIÓN DE LA PLATAFORMA LVC
El protocolo de prueba se llevó a cabo siguiendo el siguiente procedimiento:
1) Configuración de simulador en vivo: se define en el Back-End cada entidad en vivo que participa en la simulación utilizando un código SISO, el que le da una característica de entidad tal como soldado, vehículo, sistema de arma o cualquier otro que se le quiera asociar. Como en el Back-End se encuentran los ejecutables desarrollados que procesan la información de posicionamiento GPS (latitud, longitud y altura), estos son almacenados en el sitio web www. cemse-lvc.cl. Se debe cargar un ejecutable por cada entidad en vivo, el que tiene un tamaño de 750 kb aproximadamente. No existe un límite del número de ejecutables a cargar.
Por otro lado, el Front-End corresponde a los equipos móviles con Android que tienen cargada la aplicación “CEMSE-LVC”. Por cada ejecutable car-gado en el Back-End se debe iniciar la aplicación CEMSE-LVC y asignar a cada equipo móvil el número de entidad correspondiente. Una vez que se sincroniza la recepción de la señal GPS se comienza a transmitir su posición a la red GPRS.
2) Configuración del simulador virtual VBS3: se inicia el simulador virtual y se co-necta al simulador constructivo a través de la red DIS, para lo cual se utiliza el mismo parámetro “Host”, así como también un terreno correspondiente a las mismas coordenadas geográficas donde se encontrarán las entidades virtuales y entidades en vivo.
3) Configuración del simulador constructivo VRF: se comienza cargando un terreno correspondiente a las coordenadas geográficas de la simulación definida, para lo que se debe utilizar el mismo “Host” del simulador virtual y del terreno. 4) Puesta en marcha de simulación LVC: con la configuración inicial correcta de
los simuladores anteriores, se podrá visualizar de inmediato en la GUI de VRF todas las entidades vivas, virtuales y constructivas.
Una vez cargadas y visualizadas todas las entidades LVC, las entidades vivas deben comenzar a desplazarse en el área geográfica definida para la prueba. El seguimiento de las entidades en vivo se visualizará en el GUI de VRF mientras exista la cobertura GPRS y recepción de GPS enviando su última localización cada 5 segundos.
Figura Nº 4: “Diagrama de flujo de protocolo de extracción de datos”. Fuente: CEMSE, DIVDOC, 2016.
Figura Nº 5: “Diseño conceptual de prototipo funcional”. Fuente: elaboración propia.
INICIO FIN Iniciar VRF Configuración de comunicación Configuración de comunicación Diagrama Flujo Entidad en vivo Cargar escenario Cargar escenario Iniciar VBS3 Integrar con VBS3 Integrar con Entidad envivo LVC SI NO NO SI
En el diagrama anterior (figura Nº 5) se aprecia cómo el simulador virtual se comunica en forma bidireccional con el simulador constructivo a través de la red DIS. Esto implica que las entidades virtuales del Simulador Virtual se podrán ver y podrán interactuar con las entidades virtuales del simulador constructivo.
La plataforma VRF recibe datos de entidades externas provenientes de la red local, codificadas en protocolo DIS. El software escucha los paquetes de datos interpretables en protocolo DIS y carga las entidades que se encuentran en la red. Finalmente, estas se visualizan en el escenario del simulador constructivo, VRF.
3. PRUEBAS DE CAMPO
Se realizaron dos pruebas de campo para validar la herramienta desarrollada por medio de los protocolos presentados anteriormente. La primera, en la ciudad de San-tiago, por medio de una plataforma terrestre, y la segunda, en la ciudad de Rancagua, por medio de una plataforma aérea.
Ambas pruebas fueron realizadas con éxito, debido a que, durante todo el recorrido (figura Nº 6), se visualizó la posición y desplazamiento de la entidad viva en el simulador constructivo. En la primera de ellas se verificó al contrastar la ubicación real por vía radial
lo que valida la herramienta desarrollada en un área de 30 km2 y permite seguir una ruta
de 40 km monitoreados y visualizados en el software.
Figura Nº 6: “Prueba del seguimiento de una entidad terrestre en la ciudad de Santiago”. Fuente: Google Earth.
La segunda prueba se llevó a cabo en la ciudad de Rancagua para lo cual se utilizó una plataforma aérea, por medio de un helicóptero MD-530. Esta prueba consistió en realizar un vuelo desde baja altura y a corta distancia del servidor. Al constatar que la entidad era visualizada en el software, el helicóptero se fue desplazando en una trayectoria ascendente y se alejó cada vez más hasta llegar a los 4.500 pies y 40 km de distancia de la torre de control, lugar en el que estaba el puesto de monitoreo, y por una ruta de 90 km de desplazamiento por 30 minutos de vuelo.
3.1. IMÁGENES DE LA PRUEBA DE VUELO E INTEGRACIÓN CON EL SIMULADOR
CONSTRUCTIVO
Figuras Nº 7 y Nº 8: “Aplicación LVC (izquierda) e imagen de los datos recibidos (derecha) en el servidor”. Fuente: elaboración propia.
Figura Nº 9: “Imagen del seguimiento en vivo desde la torre de control del MD-530 sobre el software VRF”. Fuente: software VRF.
Figura Nº 10: “Equipo del CEMSE, pilotos y personal de apoyo de la BAVE”. Fuente: archivo de los autores.
4. CONCLUSIONES
El desarrollo de aplicaciones y herramientas para ser utilizadas por la Fuerza Terrestre es una capacidad que nuestra institución requiere cada vez más, debido al crecimiento exponencial de las TICs y de la demanda de los integrantes que cada vez son más na-tivos de las tecnologías, lo que les facilita el proceso de instrucción y entrenamiento en los distintos niveles de la conducción. Es así como la simulación cobra vital importancia a la hora de pensar y analizar las alternativas para mantener una fuerza preparada para operar en cualquier situación y en cualquier escenario, lo importante será contar con personal y medios preparados para ofrecer a nuestra fuerza las herramientas necesarias para que, cuando sea la oportunidad de emplearse, exista una mínima brecha entre lo preparado y lo que deberán enfrentar en un eventual conflicto armado o un desastre natural.
Es así como el desafío de realizar desarrollos que puedan tener un impacto en las capacidades de nuestra FT se hace presente por medio de potenciar herramientas simples, pero que demandan una alta preparación profesional, lo que, a su vez, tendrá un fuerte impacto en el mejor uso de las tecnologías, tanto las adquiridas como las desarrolladas, tal como se ha presentado en el presente artículo.
Esta herramienta tiene un alto valor, debido a que su desarrollo es innovador y van-guardista en Latinoamérica, por cuanto se ha integrado en un software de simulación adquirido por el Ejército la capacidad de visualizar en tiempo real señales de unidades desplegadas en el terreno.
Su utilidad es infinita, dependiendo de las necesidades y alcances que se consi-deren para ello, entre los que cuentan: ejercicios militares; entrenamiento de cuarteles generales; operaciones militares distintas a la guerra; entrenamiento en emergencias como panorama operacional común; seguimiento de unidades logísticas; monitoreo de unidades aerotransportadas; búsqueda y rescate de civiles y unidades militares; reporte de accidentes en campaña para la toma de decisiones; columnas logísticas; identifica-ción de unidades; revista después de la acidentifica-ción; comprobaidentifica-ción de planificaidentifica-ción; entre otras. Ahora solo queda buscar todas las posibilidades para que esta herramienta sea implementada y continuar con su desarrollo con la finalidad de hacer de la aplicación un sistema más robusto tecnológicamente y que no se limite a un solo tipo de dispositivo, debido a que existen otras tecnologías que podrían incrementar su potencial.
Continuar con la investigación aplicada como se ha presentado es fundamental para nuestra institución, debido al avance progresivo de las TICs y a que el desarrollo del
software dejó de ser una caja negra para nuestro país. Hoy se cuenta con personas
capacitadas y especializadas que tienen las herramientas para innovar en pos de la mejora continua de nuestros recursos para tener una Fuerza Terrestre más preparada y entrenada.
BIBLIOGRAFÍA
[1] BUXBAUM, Peter (2015). LVC for Integrated Training. Forest Hill: Military Training International.
[2] CHILE. Centro de Modelación y Simulación del Ejército. Definición de la metodología
de incorporación de simulación en vivo y virtual en sistema de simulación construc-tivo de comprobación de planificación. Santiago: CEMSE, DIVDOC, 2016.
[3] KELLY, M. J. (1997). The Application of Live, Virtual and Constructive Simulation to training
for Operations Other Than War.Adeldde: Simulation Industry Association of Australia.
[4] HILL, Raymond y HODSON, Douglas.The art and science of live, virtual, and
cons-tructive simulation for test and analysis. Dayton: The Journal of Defense Modeling and Simulation, 2014.
[5] SOKOLOWSKI, John A. (2012). Handbook of Real-World Applications in Modeling
and Simulation. Hoboken: Wiley.
[6] TOLK, Andreas (2012). Engineering Principles of Combat Modeling and Distributed
ARTÍCULOS
BOLETÍN CIENTÍFICO TECNOLÓGICO
ACADEMIA POLITÉCNICA MILITAR
MANTENIMIENTO PREDICTIVO
UTILIZANDO MATLAB
UTILIZANDO MATLAB
Sr. José Pereda Barrales.1
Resumen: El mantenimiento predictivo hace referencia a la supervisión inteligente del equipamiento a fin de evitar fallos futuros. Al contrario que el mantenimiento preventivo convencional, el programa de mantenimiento no está determinado por un cronograma prescrito; en su lugar, se esta-blece mediante algoritmos analíticos que utilizan los datos recopilados por los sensores de los equipos. Los algoritmos son cruciales para el éxito del mantenimiento predictivo. El procesamiento previo de los datos de sensores se realiza mediante técnicas estadísticas y de procesamiento de señales avanzadas. En el presente caso, se emplean técnicas de aprendizaje automático (Machine Learning) para calcular el estado del equipamiento. Mediante el uso del software Matlab, se analiza el caso del censado de variables de un motor de avión Turbofan, que fue expuesto en el seminario de mantenimiento predictivo dictado por el ingeniero Gerardo Hernández Correa (Ingeniero de aplicación de Mathworks) el día 15 de noviembre de 2017, en el Hotel Marriot.
Palabras claves: Mantenimiento predictivo, aprendizaje automatizado, matlab, inteligencia artificial, análisis de componentes principales. Abstract: Predictive maintenance refers to the intelligent supervision of the equipment in order to avoid future failures. Unlike conventional preventive maintenance, the maintenance program is not determined by a prescribed schedule; instead, it is established by analytical algorithms that use the data collected by the equipment sensors.
Algorithms are crucial to the success of predictive maintenance. The pre-processing of the sensor data is made by statistical techniques and advanced signal processing. In the present case, automatic lear-ning techniques (Machine Learlear-ning) are used to calculate the state of the equipment. By using Matlab software, the measured variables of a Turbofan engine’s case is analyzed, which was exposed in a predictive maintenance seminar, by the engineer Gerardo Hernández Correa
(Ma-1 Ingeniero Civil en Electrónica, Universidad Iberoamericana de Ciencias y Tecnoloía. Magíster en Currìculum y Evaluación, Universidad de Aconcagua.
nager application engineer) on November 15th, 2017, at Marriot Hotel. Keywords: Predictive maintenance,machine learning, matlab, artificial intelligence, principal component analisis.
1. INTRODUCCIÓN
Existen diversos tipos de mantenimiento, los que se dividen en prefalla y posfalla entre ellos el preventivo, el programado y el predictivo. El primero es aquel que se enfoca en la reparación de averías, roturas, fallas o cualquier inconveniente que afecte el desempeño o las funciones de una cosa u objeto, suele realizarse en casos en los que se descompo-nen herramientas y aparatos, por ejemplo; en las fábricas en las que la maquinaria sufre alguna avería o desperfecto, que impide su funcionamiento normal e, incluso, dejan de funcionar por completo, entonces se realizan las reparaciones, reposiciones de piezas y demás movimientos necesarios para que la máquina u objeto, vuelva a desempeñar su trabajo correctamente. El mantenimiento preventivo programado está enfocado en la pre-vención de daños. Este tipo suele estar programado, para realizarse cada cierto tiempo, independientemente de que existan o no muestras de deterioro en equipos y objetos. Por otro lado, el predictivo es un tipo de mantenimiento preventivo a partir del que se realizan las intervenciones para realizar arreglos, se atienen a un seguimiento y vigilancia del fun-cionamiento y del rendimiento, se determina su evolución, con lo que se anticipa, de esta manera, en qué momento deben realizarse las reparaciones y ajustes correspondientes.
El mantenimiento predictivo ofrece las siguientes ventajas para los clientes y los fabri-cantes de equipamiento: reducción del tiempo de inactividad de los equipos gracias a la identificación de los problemas antes de que se produzcan fallos, lo que permite una planificación idónea de las tareas de revisión y el aumento de la vida útil del equipamiento; determinación automática de la causa raíz del fallo, lo que permite la realización de las reparaciones apropiadas sin necesidad de destinar recursos a establecer un diagnóstico; ahorro de costos por tareas de mantenimiento innecesarias.
Una alternativa para realizar este seguimiento del estado de la maquinaria es me-diante sensores dispuestos en puntos claves para poder medir variables relevantes del estado de funcionamiento de la máquina. Una vez tomados los datos, se procesan con un computador y, así se detectan anomalías de forma prematura. La técnica de proce-samiento de datos que se analiza es el Machine Learning o aprendizaje automatizado. Una manera fácil de procesar los algoritmos de Machine Learning es con el software
Matlab, el que tiene incluido dentro de sus herramientas específicas algoritmos
estadís-ticos y de regresión que son fácilmente ejecutados mediante opciones preestablecidas para este tipo de cálculos. Además, se pueden procesar grandes cantidades de datos.
2. DESARROLLO. MACHINE LEARNING
La herramienta de inteligencia artificial, Machine Learning, ocupa datos con los que produce un programa y, de esa manera, realiza una tarea específica. Esta técnica ocupa una serie de algoritmos para identificar patrones en los datos y, así, poder apoyar en la toma de decisiones.
Existen dos tipos de aprendizaje automatizado: el aprendizaje supervisado y el no supervisado. El primero necesita datos de entrada y de salida para poder desarrollar un modelo predictivo y, con esto, desarrollar algoritmos de clasificación o de regresión. Por otro lado, el aprendizaje no supervisado, utiliza únicamente datos de entrada, con lo que crea algoritmos de clasificación o agrupamiento de datos (Clustering) (Del Pozo, 2016).
En general, la forma de trabajo del Machine Learning se organiza en dos grandes etapas, independientemente de su forma de aprendizaje. La primera es de entrenamiento, la que tiene, a su vez, diferentes subetapas, que considera en primera instancia la carga de los datos; luego, el ajuste de los datos para que estos puedan ser procesados por el computador; posteriormente, se aplican los algoritmos internos de aprendizaje para finalizar con la creación de un modelo, el que se aplicará en la segunda etapa.
La segunda etapa es llamada de predicción, la que tiene las siguientes subetapas: primero, se entran nuevos datos para poder aplicar lo aprendido y poder aplicar el modelo creado en la etapa anterior; luego, se aplica la misma etapa de ajuste de datos, para después aplicarlos al modelo creado y, finalmente, obtener una predicción.
Figura Nº 1:“Etapas de trabajo del Machine Learning”. Fuente: Mathworks Inc., Hernández (2017).
El método de aprendizaje se basa en la utilización de algoritmos estadísticos que son capaces de generalizar comportamientos y reconocer patrones a partir de una información suministrada anteriormente en forma de ejemplos. El objetivo es predecir
Carga de datos Ajuste de datosFiltros, PCA, estadísticas
Algoritmo de aprendizaje Supervisado o no supervisado
Obtención modelo
Carga de datos Ajuste de datosFiltros, PCA, estadísticas Aplicación modelo Predicción
Etapa de predicción Etapa de entrenamiento
las posibles situaciones futuras habiendo aprendido anteriormente de las situaciones pasadas, es decir, aprender de la experiencia.
2.1. Dificultades y características del Machine Learning
El Machine Learning se utiliza comúnmente cuando hay muchas variables a analizar y el sistema es muy complejo para poder determinar una ecuación o plantear una hipótesis o simplemente identificar alguna tendencia o dependencia. Por tanto, el computador utiliza algoritmos de aprendizaje basados en funciones de costo, como la de mínimos cuadrados, por ejemplo:
Donde:
m, es el número de datos de entrenamiento.
h , es la salida de cada ensayo que predice nuestra función de hipótesis.
y es la salida exacta de cada ensayo .
El objetivo es minimizar la función de costos J( ), para que después se pueda aplicar los valores de ajustados de para aplicar el modelo de salida h( ).
Un tipo de modelo de salida o función de hipótesis es el modelo de regresión lineal que tiene la siguiente expresión:
Donde el valor n es el número de características de entrada.
Las dificultades que presentan el modelo anteriormente descrito suelen ser las si-guientes:
• La diversidad de los datos, ya que muchos se presentan en diversos formatos y magnitudes, los cuales deben ser ajustados y normalizados, para que los algo-ritmos los puedan procesar.
• El procesamiento de los datos previo al entrenamiento implica el filtrado, selección y transformación de los datos de variables más influyentes en el sistema, ya que un modelo muy complejo es muy difícil que pueda aprender.
• El entrenamiento o aprendizaje del modelo suele ser un proceso iterativo y de prueba y error hasta que se obtenga el modelo que cumpla con los requerimientos establecidos.
• Calidad o rendimiento del modelo. Existe un compromiso entre velocidad, preci-sión y complejidad del modelo. No es posible obtener un modelo con todas esas características óptimas.
3. EL SOFTWARE MATLAB
Matlab es un entorno de cálculo técnico de altas prestaciones para cálculo numérico
y visualización. Integra: análisis numérico, cálculo matricial, procesamiento de señales, gráficos, entre otros. Es un entorno fácil de usar, donde los problemas y las soluciones son expresados como se escriben matemáticamente, sin la programación tradicional. El nombre Matlab proviene de “MATrix LABoratory’” (Laboratorio de Matrices). Matlab fue escrito originalmente para proporcionar un acceso sencillo al software matricial
desarrollado por los proyectos LINPACK2 y EISPACK,3 que juntos representan lo más
avanzado en programas de cálculo matricial. Matlab es un sistema interactivo cuyo ele-mento básico de datos es una matriz que no requiere dimensionamiento. Esto permite resolver muchos problemas numéricos en una fracción del tiempo que llevaría hacerlo en lenguajes como C, BASIC o FORTRAN. Matlab ha evolucionado en los últimos años a partir de la colaboración de muchos usuarios. En entornos universitarios se ha convertido en la herramienta de enseñanza estándar para cursos de introducción en álgebra lineal aplicada, así como cursos avanzados en otras áreas. En la industria, Matlab se utiliza para investigación y para resolver problemas prácticos de ingeniería y matemáticas, con un gran énfasis en aplicaciones de control y procesamiento de señales. Matlab también proporciona una serie de soluciones específicas denominadas TOOLBOXES.
4. APLICACIÓN DE UN CASO DE USO: MOTOR DE AVIÓN TURBOFAN
La explicación del caso de uso es de un motor de avión Turbofan que se expuso en el seminario en Santiago de Chile el día 15 de noviembre, llamado “Mantenimiento predictivo usando Matlab”. En este se realizó un análisis de los datos de 14 sensores correspondientes a 100 motores de avión Turbofan, los que fueron entregados a los asistentes, más el material de presentación, el que, complementado con información recabada en el sitio web de Matlab, se explica la metodología de Machine Learning aplicada al mantenimiento predictivo.
2 Software desarrollado por Argone National Laboratory, para cálculos científicos.
3 Conjunto de subrutinas en fortran, para el cálculo de autovalores y autovectores, desarrollado por Argone National Laboratory.
Figura Nº 2: “Motor Turbofan”. Fuente: Mathworks Inc., Hernández (2017).
4.1. Antecedentes del monitoreo de datos
Los datos de los sensores son temperatura, velocidades de rotación, presiones, entre otras, que completan 14 sensores, de 100 motores del mismo tipo Turbofan, a lo largo de 125 vuelos.
Figura Nº 2: “Motor Turbofan”. Fuente: Mathworks Inc., Hernández (2017).
Con los datos provenientes de los sensores se requiere realizar un mantenimiento predictivo, el que pretende lo siguiente:
• Detectar fallas.
• Predecir el tiempo para el mantenimiento. • Identificar componentes defectuosos. • Incrementar la disponibilidad.
• Reducir los costos de mantenimiento.
El procedimiento general para realizar este mantenimiento es el siguiente: • Entrenar un modelo para predecir cuándo las fallas ocurrirán.
• Desplegar información de los sensores. • Predecir fallas en tiempo real.
• Importar y analizar datos históricos de los sensores.
4.2 Importar y analizar datos históricos de los sensores
Los datos de los sensores se pueden originar de dos formas o dos escenarios po-sibles, lo que incide en la estrategia de aprendizaje.
4.2.1 Escenario 1: no existen datos de fallas
En este escenario únicamente existen datos de los sensores, pero no están dispo-nibles los datos de falla, los que son en definitiva los datos de salida. Lo anterior implica que, al contar con únicamente datos de entrada, solo se puede optar un aprendizaje no supervisado y que el modelo que se obtenga no serviría para realizar predicciones, únicamente agrupaciones de datos o clustering. Este es el esquema de datos que se trabajará en el presente trabajo.
4.2.2 Escenario 2: existen datos de fallas
En este escenario existen datos de sensores y, además, datos de fallas ocurridas, por tanto, hay datos de entrada y de salida. Con tal información se puede ejecutar un aprendizaje supervisado, en el cual es posible obtener un modelo que sea capaz de realizar predicciones y clasificaciones.
Figura Nº 3: “Tipos de aprendizaje del Machine Learning”. Fuente: Mathworks Inc., Hernández (2017).
En la figura anterior se indica que se aplica para el aprendizaje una técnica de apren-dizaje no supervisada, debido a que no hay datos de fallas disponibles (datos de salida) y solamente se tienen los datos de los sensores, que corresponden a datos de entrada. Por lo tanto, el modelo podrá generar agrupación de datos o Clustering.
4.3. Procedimiento de Machine Learning para el modelo de mantenimiento
predic-tivo
En esta parte se realizarán todos los pasos para poder obtener el modelo de man-tenimiento predictivo, hasta llegar al modelo final y las pruebas con el modelo obtenido.
4.3.1 Paso 1: lectura de datos de los sensores
Lo primero es leer los datos de los sensores, para lo cual se ejecuta el siguiente comando:
Machine
Learning
Aprendizaje Supervisado Desarrollo de modelo predictivo basado en datos de entrada y de salidaAprendizaje no Supervisado
Agrupa e interpreta datos basados solo en datos de entrada
Figura Nº 4: “Vista parcial de los datos de los sensores”. Fuente: Mathworks Inc., Hernández (2017). 4.3.2. Paso 2: visualización de los datos
Una vez cargados los datos, se procede a hacer una selección de los 14 sensores y mostrar una visualización gráfica de los datos obtenidos. Para realizar lo anterior, se ejecutan los siguientes comandos:
Al ejecutar las líneas anteriores, resulta el siguiente gráfico que es una muestra de 9 sensores:
Figura Nº 5: Gráfico de los nueve sensores seleccionados Fuente: Mathworks Inc., Hernández (2017).
Como se puede apreciar, no es posible identificar ninguna tendencia o adelantar alguna conclusión con respecto al mantenimiento.
4.3.3. Filtrado de datos
Como generalmente los datos de los sensores vienen con ruido, es conveniente y necesario aplicarles filtros digitales para poder obtener información más pura de los sensores. Para ello, se aplica el siguiente código:
El anterior es un filtro de media móvil que sirve para suavizar los datos de los sensores más importantes, que difieren de los sensores de la figura 5, por tratarse de sensores filtrados.
Figura N° 6: “Gráfico de los datos filtrados”. Fuente: Mathworks Inc., Hernández (2017).
Dentro de este mismo punto de visualización, se puede obtener otro tipo de gráfico que el de control, en donde se puede observar la variación de los datos y si algún dato se sale del rango de desviación estándar. Lo anterior se materializa con el siguiente comando:
Figura Nº 7: “Gráfico de control de un sensor”. Fuente: Mathworks Inc., Hernández (2017).
El gráfico muestra una línea del centro que corresponde a la media y la línea de los extremos es la desviación típica, los puntos que sobrepasan los límites de la línea roja, podrían estar representando un problema.
Dado que el anterior es solo el gráfico de un solo sensor, esta información podría ser suficiente para poder tomar una decisión, pero como son muchos sensores, el proble-ma debe ser tratado con una herramienta más poderosa como el Machine Learning y procesar la información de todos los sensores a la vez.
4.3.4. Análisis de componentes principales
El análisis de componentes principales (PCA) es una técnica estadística para poder determinar en cuántos componentes se puede representar la mayor variabilidad de los datos y, de esa forma, trabajar con menos gráficos, pero con toda la información pro-yectada (la más relevante), en los ejes de los componentes principales.
Figura Nº 8: “Ejemplo de los componentes principales”. Fuente: Mathworks Inc., Hernández (2017).
En la figura 8 se busca representar en pocas dimensiones la mayor cantidad de infor-mación, en ejes ortogonales llamados componentes principales, los cuales representan la mayor desviación de los valores en el espacio.
Para poder realizar el análisis de componentes principales se deben estandari-zar los datos para que estos tengan media cero y varianza 1, ya que si se mezclan cantidades tales como rpm, temperaturas, no se podrían trabajar apropiadamente
dada las diferentes magnitudes que poseen. Para lo anterior se utiliza el siguiente procedimiento, en cuya parte final hay un comando que ejecuta el análisis de com-ponentes principales.
El siguiente gráfico representa el resultado del análisis PCA:
Figura Nº 9: “Gráfico de varianza por componente principal”. Fuente: Mathworks Inc., Hernández (2017).
Se puede apreciar en el gráfico anterior que bastan solo 2 componentes principales, la primera representa el 76% de la varianza y la segunda representa más del 10% de variación de los datos. A partir del tercer componente principal ya la variación baja a menos del 2%. Por lo que se toman solo 2 componentes principales para trabajar con
toda la información de los sensores. En otras palabras, de un espacio de 14 dimensio-nes (una por sensor) se lleva la información a un espacio de solo 2 dimensiodimensio-nes que representan la proyección de las 14.
Figura Nº 10: “Gráfico de los dos componentes principales”. Fuente: Mathworks Inc., Hernández (2017).
En la figura N° 10 se logra apreciar la dispersión de los valores proyectados en los dos componentes principales, en donde se puede apreciar la mayor varianza de los datos. De esa forma, es más fácil procesar un algoritmo de aprendizaje, ya que se tienen solo dos variables.
4.3.5. Visualización de información más detallada de los componentes principales
Es muy útil para comenzar los análisis del gráfico de la figura N° 10 la visualización de todos los datos. Así, se analizan los centroides y cómo evolucionan los datos desde la primera muestra hasta la última. Para esto se ejecuta el siguiente código:
Figura Nº 11: “Gráfico de los dos componentes principales antes y después del vuelo 100”. Fuente: Mathworks Inc., Hernández (2017).
Se logra apreciar los valores antes y después del vuelo 100; en azul (punto más os-curo) es antes del vuelo 100 y en verde están los datos después del vuelo 100, lo que indica que los valores tienden a alejarse del centro y refleja que los motores se alejan de la parte central del dibujo, que serían las condiciones normales. A medida que los puntos se alejan del centro (en rojo o punto menos oscuro), tienden a salirse del rango de normalidad y a necesitar mantenimiento.
Figura Nº 12: “Evolución de un motor tras las diversas tomas de datos”. Fuente: Mathworks Inc., Hernández (2017).
En el gráfico anterior, se puede observar cómo un motor se va alejando de la condición de “normalidad” a medida que se van realizando las diversas medidas.
4.3.6. Resultado Final: los rangos para el mantenimiento
Finalmente, después de correr el algoritmo de Machine Learning se logran determinar los rangos para clasificar los motores en el grado de urgencia para realizar el manteni-miento. Para lo cual, se ejecutó el siguiente código:
De esta forma, se definieron tres zonas representadas con tres colores: • Color verde: zona normal, requiere mantenimiento a largo plazo.
• Color amarillo: zona de advertencia, requiere mantenimiento en un mediano plazo. • Color rojo: zona de alarma, requiere mantenimiento de inmediato.
Figura Nº 13: “Zonas para el mantenimiento”. Fuente: Mathworks Inc., Hernández (2017).
El software indica, además, que el 90% de los datos están en régimen normal.
Al realizar un gráfico de la evaluación de los vuelos, en la medida que van fallando, se tienen los siguientes resultados:
Figura Nº 14: Gráfico de porcentaje de motores, según la clasificación de mantenimiento. Fuente: Mathworks Inc., Hernández (2017).
En el gráfico se muestra la evolución de los motores, según las cantidades de vuelos hasta que fallen. Se puede apreciar que, de la totalidad de motores en condición normal (verde) a partir de los 160 vuelos aproximadamente, comienzan a reducir su cantidad y a desplazarse a la condición de alerta (naranja) y, a medida que aumentan los vuelos, siguen decreciendo hasta comenzar a estar en estado de alarma (rojo). Si aumenta aún más la cantidad de vuelos, el 100% de los motores falla y no hay motores ni en condición normal o de alerta.
5 CONCLUSIONES
El software Matlab permite, mediante varias opciones, graficar datos de diferentes formas para apoyar la toma de decisiones. En otro sentido, facilita el procesamiento de grandes cantidades de datos de forma muy fácil y amigable para el usuario.
Es mejor contar con datos de salida para el Machine Learning, dado que esto per-mite realizar predicciones de cuando fallarían los motores, lo que no se puede lograr solamente con los datos de entrada.
La técnica no supervisada de aprendizaje no permite realizar predicciones, solamente determinar qué equipos o partes requieren mantenimiento de manera urgente, media-namente urgente o si no se necesita mantener por el momento, ya que la técnica no supervisada permite monitorear el estado del equipo o de algún componente a lo largo de su uso, lo cual solo da indicios de la variación de su estado.
Por tanto, sería posible, al perfeccionar las técnicas de mantenimiento por Matlab, progra-mar indicadores de mantenimiento como por ejemplo, confiabilidad, disponibilidad, etcétera.
6. BIBLIOGRAFÍA
[1] DEL POZO GALLEGO, Carlos. “Aplicación de técnicas de Machine Learning con regularización al diagnóstico de fallos en motores de inducción”. Director: Óscar Duque Pérez [Trabajo de fin de grado]. Universidad de Valladolid, España,2016. [2] HERNÁNDEZ CORREA,Gerardo. Seminario de mantenimiento predictivo usando
Matlab. Santiago de Chile: Hotel Marriot. 15 de noviembre de 2017.
[3] MATHWORKS INC.[en línea] [Fecha de consulta: 15 de noviembre de 2017]. Disponible en: https://www.mathworks.com/
[4] PASCUAL, Rodrigo (2005). El arte de mantener. Santiago de Chile: Ediciones Universidad de Chile.
ARTÍCULOS
BOLETÍN CIENTÍFICO TECNOLÓGICO
ACADEMIA POLITÉCNICA MILITAR
OBTENCIÓN DEL COEFICIENTE DE ARRASTRE
DE LOS PROYECTILES, MEDIANTE LA
DINÁMICA DE FLUIDOS COMPUTACIONAL
ARRASTRE DE LOS PROYECTILES,
MEDIANTE LA DINÁMICA DE
FLUIDOS COMPUTACIONAL
MAY. Marcelo Grandón Díaz1
Resumen: El siguiente estudio plantea la utilización de la dinámica de fluidos computacional para la obtención del coeficiente de arrastre de los proyectiles, específicamente del proyectil de artillería de 155 mm. Este estudio busca utilizar la simulación como una herramienta más que permita obtener el coeficiente de arrastre de los proyectiles y, así, poder realizar evaluaciones de la munición e, incluso, modificaciones en su geometría, con una herramienta computacional que utilice modelos matemáticos que permitan predecir el comportamiento del proyectil en vuelo, balística exterior y, además, aportar antecedentes para la creación de las tablas de tiro. Palabras claves: Coeficiente de arrastre, simulación, dinámica de fluidos computacional, balística exterior, evaluación, tablas de tiro.
Abstract: The following study proposes the use of computational fluid dynamics to obtain the drag coefficient of the projectiles, specifically the 155 mm artillery one. This study seeks to use simulation as a tool among many others used to obtain projectiles`s drag coefficient and, therefore, to be able to perform ammunition evaluations and even modifications in its geometry, using a computational tool that uses mathematical model stop redict the behavior of the projectile in flight, external ballistics and, also,to provide background for the creation of shooting tables.
Keywords: Drag coefficient, simulation, computational fluid dynamics, external balistics, evaluation, shootingtables.
1. INTRODUCCIÓN
Uno de los factores que más influye en la trayectoria de un proyectil es la fuerza de arrastre. Debido a esta fuerza, según la balística exterior, el alcance de los proyectiles
