������������������������������������������������������������������������������������������������������������������������������������������������������������

���������������������������������������������������������������������������������

 

Diagn�stico de Fallas con Fuzzy Logic del Veh�culo en Labview

 

Fault Diagnosis with Fuzzy Logic of� Vehicle in Labview

 

Resolu��o de problemas com Vehicle Fuzzy Logic no Labview

�

�

 

 

 

 

 

Correspondencia: cristian.santiana@espoch.edu.ec

Ciencias T�cnicas y Aplicadas

Art�culo de investigaci�n

��������������������������������������� ���������������������������������������������

*Recibido: 30 de enero de 2021 *Aceptado: 15 de febrero de 2021 * Publicado: 11 de marzo de 2021

       I.            Magister en Sistemas de Control y Automatizacion Industrial, Magister en Formulacion, Evaluacion y Gerencia de Proyectos para el Desarrollo, Ingeniero en Electronica Control y Redes Industriales, Escuela Superior Polit�cnica de Chimborazo, Facultad de Ciencias Pecuarias, Chimborazo, Ecuador.

    II.            Magister en Sistemas Automotrices, Ingeniero Automotriz,� Escuela Superior Polit�cnica de Chimborazo, Facultad de Mec�nica, Chimborazo, Ecuador.

�III.            Magister en Ingenieria en Vialidad y Transportes, Ingeniero Civil, Prevenci�n en Riesgos Laborales, Escuela Superior Polit�cnica de Chimborazo, Facultad de Ciencias Pecuarias, Chimborazo, Ecuador.

�IV.            Magister en Ciencias de la Ingenieria Mencion Ingenieria Mecanica, Ingeniero Mecanico, Investigador Independiente, Chimborazo, Ecuador.

Resumen

Con el fin de aportar al diagn�stico automotriz se pretende facilitar un sistema experto de detecci�n de fallas en veh�culos comunicados con el protocolo CAN, que permita identificar fallas por medio del an�lisis con l�gica difusa de las se�ales que entregan los sensores ubicados en el veh�culo, utilizando una tarjeta de adquisici�n de datos DAQ dedicada a este protocolo con� la aplicaci�n de Automotive Diagnostic del software LabView� para tomar los par�metros de identificaci�n PID�s que poseen los veh�culo se realiz� un monitoreo en tiempo real del auto, luego estos datos se utiliza como se�ales de entrada del modelo Fuzzy Logic, en este modelo toma decisiones por medio de combinaciones programadas en reglas seg�n la experticia del t�cnico automotriz y un manual de taller, estas fallas fueron registradas en pruebas est�tica y din�mica definiendo secuencias de aceleraci�n y ruta din�mica para la prueba. De esta manera el sistema por medio de an�lisis inteligente y la formaci�n de histogramas internos es �til para la detecci�n de fallas y el monitoreo en tiempo real del comportamiento de los sensores del veh�culo, es importante continuar el estudio de detecci�n de fallas con otros modelos de inteligencia artificial y realizar pruebas en diferentes marcas de veh�culos.

Palabras clave: Diagn�stico Automotriz; Detecci�n de Fallas; L�gica Difusa; Tarjeta de Adquisici�n DAQ; Comunicaci�n CAN.

 

Abstract

In order to contribute to the automotive diagnosis, it is intended to provide an expert system for detecting faults in vehicles communicated with the CAN protocol, which allows identifying faults through fuzzy logic analysis of the signals delivered by the sensors located in the vehicle, using A DAQ data acquisition card dedicated to this protocol with the Automotive Diagnostic application of the LabView software to take the PID's identification parameters that the vehicles have, a real-time monitoring of the car was carried out, then these data are used as signals From the input of the Fuzzy Logic model, in this model it makes decisions through combinations programmed in rules according to the expertise of the automotive technician and a workshop manual, these faults were registered in static and dynamic tests defining acceleration sequences and dynamic route for the test . In this way, the system by means of intelligent analysis and the formation of internal histograms is useful for the detection of faults and the real-time monitoring of the behavior of the vehicle's sensors, it is important to continue the fault detection study with other models of artificial intelligence and carry out tests on different makes of vehicles.

Keywords: Automotive Diagnostic; Fault Detection; Fuzzy Logic; Data Acquisition Card; CAN Comunication

 

Resumo

A fim de contribuir para o diagn�stico automotivo, pretende-se fornecer um sistema especialista para detec��o de falhas em ve�culos comunicados com o protocolo CAN, que permita identificar falhas atrav�s da an�lise de l�gica fuzzy dos sinais emitidos pelos sensores localizados no ve�culo, utilizando A Cart�o de aquisi��o de dados DAQ dedicado a este protocolo com a aplica��o Automotive Diagnostic do software LabView para tirar os par�metros de identifica��o do PID que os ve�culos possuem, foi realizado um monitoramento em tempo real do carro, ent�o esses dados s�o usados ​​como sinais da entrada do modelo Fuzzy Logic, neste modelo toma decis�es atrav�s de combina��es programadas em regras de acordo com a expertise do t�cnico automotivo e um manual de oficina, essas falhas foram registradas em testes est�ticos e din�micos definindo sequ�ncias de acelera��o e rota din�mica para o teste. Desta forma, o sistema por meio de an�lise inteligente e forma��o de histogramas internos � �til para a detec��o de falhas e o monitoramento em tempo real do comportamento dos sensores do ve�culo, � importante continuar o estudo de detec��o de falhas com outros modelos de intelig�ncia artificial e realizar testes em diferentes marcas de ve�culos.

Palavras-chave: Diagn�stico Automotivo; Detec��o de falha; L�gica difusa; Cart�o de aquisi��o DAQ; Comunica��o CAN.

 

Introducci�n

Scott, 2000) menciona que es muy importante la relaci�n entre el conductor con el interior del veh�culo, entre la mejor herramienta de diagn�stico menciona a electr�nica y la electromec�nica, dando paso a que la ciencia desarrolle muchos equipos de diagn�stico y la creaci�n de una gran variedad de tecnolog�a para esta interrelaci�n humano m�quina. Desde entonces entre las innovaciones m�s importantes se encuentra la inclusi�n de los sistemas OBD-II, inicialmente orientado a monitorear los componentes del autom�vil, y que ahora permite monitorear que el funcionamiento y rendimiento del autom�vil sea el �ptimo.

Como es conocido, en la actualidad todos los equipos tienen comunicaci�n, no puede ser la excepci�n de los veh�culos que cada vas van siendo m�s inteligentes con el uso de la electr�nica, para eso se cuenta con m�ltiples herramientas de adquisici�n de datos (Ukil, 2015; Velazquez-Aguilar et al., 2017). Toda la gesti�n se realiza en la computadora del autom�vil, a la que llega las se�ales de los sensores por medio de cableado ya san estas en se�ales anal�gicas o digitales, de la misma manera emite se�ales de control hacia los diferentes actuadores, esta comunicaci�n puede ser por medio de la red interna del veh�culo o por las se�ales antes mencionadas (Simonik� et al,2014).

 

�Elementos del sistema OBD-II

Los elementos que intervienen en el sistema OBD-II son: la ECU (Engine Control Unit) conocida como la computadora del autom�vil, los transductores encargados de enviar los datos hacia la ECU, la luz piloto de fallas (MIL, Malfunction Indicator Light) ubicado en el tablero, y el conector de diagn�stico (DLC, Data Link Connector) que sirve de interfaz entre la ECU y los equipos de diagn�stico automotriz.

La ECU es la computadora del autom�vil y su funci�n principal es obtener y manejar los datos provenientes de todos los transductores del motor del autom�vil. Es un dispositivo que se encuentra generalmente debajo del tablero en la parte del conductor (Cervantes & Sol�s, 2010)

Los transductores o sensores son dispositivos encargados de monitorear de forma continua el funcionamiento y operaci�n de los par�metros que intervienen en el trabajo del motor del autom�vil. Entre las medidas que pueden obtener los transductores del motor est�n: revoluciones por minuto del motor, temperatura del l�quido refrigerante del motor, presi�n absoluta del colector de admisi�n, presi�n barom�trica, temperatura de aire de admisi�n, posici�n del acelerador, velocidad del autom�vil, emisi�n de CO2 entre otras.

En la Tabla 1 se presentan transductores generales que intervienen en el motor del autom�vil que permiten obtener las medidas antes mencionadas y que hacen que la ECU pueda determinar la cantidad de combustible, el punto de ignici�n y otras regulaciones necesarios que permiten evaluar las condiciones del autom�vil (Zabler, 2002)

 

Tabla 1: PID Primarios del Autom�vil

 

La luz MIL es utilizada por el sistema OBD-II y se enciende cuando los transductores del motor detectan un problema en el autom�vil; su prop�sito es alertar al conductor de la necesidad de realizar un mantenimiento del mismo, esta luz del mil es un indicio a que el t�cnico tenga que conectar el esc�ner automotriz para su diagn�stico.

El conector DLC es una interfaz como se muestra en la figura 1, con forma trapezoidal de 16 pines basado en el est�ndar SAE J1962, que se ubica bajo el tablero generalmente en el lado del conductor o junto a la caja de fusibles del veh�culo con el nombre de Diagnosis. El conector DLC sirve como interfaz de acceso y recuperaci�n de datos desde la ECU hacia un equipo de diagn�stico (esc�ner automotriz).

El sistema OBD-II utiliza diferentes modos de medici�n, donde cada uno de los modos permite el acceso a los datos de la ECU del autom�vil. Para solicitar datos de un autom�vil es necesaria la utilizaci�n de c�digos PID (Parameter Identification) (Georgiev, 2018). Cada c�digo PID est� relacionado con una medida espec�fica. Por ejemplo, si se desea solicitar el dato en tiempo real de la velocidad del autom�vil, se debe utilizar el PID 0D y de esa manera acceder a los diferentes par�metros. Como se muestra a continuaci�n en la tabla entre los PID primarios, cada uno con sus rangos de funcionamiento

�

Figura 1: DLC con la distribuci�n de pines

 

Entre los protocolos que m�s destacan en la actualidad en el campo automotriz es el CAN - Bus (Comunication Area Network) entregando ventajas de ser o formar un nodo de comunicaci�n multi- master, de arquitectura abierta con detecci�n de errores en la comunicaci�n y recuperaci�n autom�tica es as� que varias marcas reconocidas en el campo automotriz de pa�ses como Alemania, China entre otros cada vez se encuentran mejorando al protocolo de comunicaci�n. (Ye, 2010)

 

Figura 2: Modelo de comunicaci�n externa

 

(Simba�a et al, 2016 ) en su investigaci�n realiza la interfaz con ELM327, posteriormente enlaza por medio de un arduino mega y el m�dulo GPRS para elevar los datos a la nube y poder manipular desde ah� la informaci�n ya sea desde un computador o desde un dispositivo m�vil.

En nuestro caso se propone la adquisici�n de datos y el registro en una base de datos para luego poder analizar estos datos y poder ver el comportamiento de cada uno de los PIDs que se encuentran en el veh�culo. Es importante mencionar que no todos los veh�culos van a tener todos los PID como dice la norma SAE J1979, esto variar� de acuerdo a la marca o modelo del auto que este en an�lisis.

 

Diagn�stico de Fallas

Los modelos anal�ticos de los sistemas son a menudo desconocidos, y el conocimiento sobre el sistema diagnosticado es inexacto. Es formulado por expertos y tiene la forma de reglas if-then que contienen la evaluaci�n ling��stica de las variables del proceso. En tales casos, los modelos difusos se pueden aplicar con �xito al diagn�stico de fallas. Estos modelos se basan en los denominados conjuntos difusos definidos de la siguiente manera:

 

������������������� ����������������������������������� (1)

Donde μA (x) es una funci�n de membres�a del conjunto difuso A, mientras que μA (x) ∈ [0, 1]. La funci�n de membres�a realiza la asignaci�n del espacio num�rico X de una variable al rango [0, 1]. Una estructura de modelo difuso contiene tres bloques: el bloque de fuzzyfication, el bloque de inferencia y el bloque defuzzyfication.

Figura 3: Aplicaci�n de Fuzzy Logic

 

Los valores de las se�ales de entrada se introducen en el bloque de fuzzyfication. Este bloque define el grado de pertenencia de la se�al de entrada a un conjunto difuso particular de la siguiente manera:

Los conjuntos difusos se asignan a cada entrada y salida, y los valores ling��sticos, por ejemplo, peque�os, medianos, grandes, se atribuyen a un determinado conjunto difuso. Dentro del bloque de interferencia, el conocimiento sobre el sistema se describe en forma de reglas que pueden tener la forma.

Donde xn es la entrada n-�sima, and es el k-�simo conjunto difuso de la entrada n-�sima, y representa la salida, y Bl denota el l-�simo conjunto difuso de la salida. El conjunto de todas las reglas difusas constituye la base de decisiones. Sobre la base de la funci�n de membres�a resultante de la salida, se calcula un valor preciso (n�tido) de la salida en el bloque de defuzzyfication. El conocimiento del experto se puede utilizar para dise�ar el modelo. Desafortunadamente, el enfoque directo a las construcciones modelo tiene serias desventajas. Si el conocimiento del experto es incompleto o defectuoso, se puede obtener un modelo incorrecto. Al dise�ar un modelo uno tambi�n debe utilizar los datos de medici�n. Por lo tanto, es aconsejable combinar el conocimiento del experto con los datos disponibles al dise�ar un modelo difuso. El conocimiento del experto es �til para definir la estructura y los par�metros iniciales del modelo, mientras que los datos son �tiles para el ajuste del modelo. Tal concepci�n se ha aplicado a las llamadas redes neuronales difusas. Son herramientas de modelado convenientes para la generaci�n residual ya que permiten combinar la t�cnica de modelado difuso con algoritmos de entrenamiento neural. (Sobhani-Tehrani, E. & Khorasani, K., 2009)

Por la l�gica difusa se puede detectar fallas en los procesos de producci�n, por lo tanto, se aplica al diagn�stico de fallas en los veh�culos por l�gica difusa. (Hernandez et al, 2015)

 

Metodolog�a

Para la adquisici�n de datos se utiliz� el m�todo de medici�n directa de las magnitudes que entregan los sensores que se encuentran en el sistema del veh�culo. Para luego poder realizar una interfaz gr�fica que explique detalladamente el comportamiento de las se�ales del autom�vil, se utiliz� una interfaz que permita extraer la informaci�n de la ECU del veh�culo, estos datos se procesaron en valores decimales es decir para luego mostrar en indicadores y gr�ficos ilustrativos en un HMI (interfaz hombre maquina).

 

Interfaz f�sica entre el veh�culo y el PC

Para poder extraer los datos de las se�ales de todos los sensores que se encuentran en el veh�culo se utiliz� la tarjeta de National Instruments NI 9862 y el adaptador para USB cDAQ-9171, bajo el protocolo de comunicaci�n CAN, que es llevado a un archivo de datos organizados por su variable de medici�n de cada sensor en datos interpretados. Esta tarjeta es la que se encarga de extraer todos los PID existentes en el veh�culo en este caso estos PID se obtiene en formato HEX (hexadecimal).

�

Figura 3: Tarjeta y Adaptador USB utilizado para la adquisici�n de Datos

 

Esta tarjeta es la encargada de obtener los datos de las se�ales, los mismos que deben ser interpretados o convertidos a valores hexadecimales, Para establecer comunicaci�n mediante la tarjeta con LabView se utiliz� el m�dulo Automotive Diagnostic, que es una aplicaci�n adicional que se instala dentro del paquete de LabView.

Figura 4: Herramienta de Automotive Diagnostic

 

De estos bloques se utiliz� las funciones de General Function, en donde se tiene bloques para abrir y cerrar comunicaci�n y bloques para interpretar los datos.

�

Figura 5: Bloques de Funciones Generales

 

Algoritmo de programaci�n para la adquisici�n de datos

Previo a la adquisici�n de datos del veh�culo es importante conocer cu�les son los PID que posee cada uno de los veh�culos, por lo que fue necesario realizar un algoritmo para identificar cu�les de los PID es posible a leer de la ECU del autom�vil en estudio, en vista que no todos los veh�culos poseen todos los PID que indica la norma SAE J1939.

�

 

 

Figura 6: Flujograma de Lectura de Datos

 

Luego de leer los datos es necesario continuar con la interpretaci�n de las se�ales para eso sustentados en la tabla general de la norma SAE J1939, en donde muestra que cada PID puede contener uno o dos datos que para pasar a valores decimales es necesario el uso de una formula.

Entonces si por ejemplo deseo conocer las RPM del motor, el PID que corresponde es el 0C que nos va a entregar 2 bytes o lo que ser�a dos datos el A y el B, con un rango de 0 a 16383,75 en unidades rpm, la formula a programar es (256A+B) /4. De esta forma como resultado nos va a entregar el valor de las RPM a la que se encuentra funcionando el motor del veh�culo.

Luego de la adquisici�n de datos y la interpretaci�n lo que continua es la presentaci�n de los datos obtenidos con indicadores que muestren el funcionamiento en tiempo real del veh�culo, con indicadores similares a los que existe en el tablero de auto, otra presentaci�n es por medio de curvas que describan el funcionamiento de los par�metros, estas gr�ficas se realizaron tomando como referencia el tiempo de puesta en marcha del motor y la se�al que va entregando.

�El registro de datos es importante para an�lisis posteriores y verificaci�n de comportamientos de las se�ales en modo offline, sin necesidad de que el equipo se mantenga conectado al veh�culo. Entre una de las aplicaciones que se relaciona muy bien con LabView y conocido por todos es el Excel, en donde una vez que se tenga todos los datos almacenados se puede graficar o realizar estad�stica con ellos.

Tabla 2: PID con sus rangos, unidades y f�rmulas para la interpretaci�n de datos.

 

Definici�n del modelo de detecci�n de fallas del veh�culo

Luego de haber obtenido los datos del veh�culo, se utiliz� los datos obtenidos para ver el comportamiento de las variables en dos estados de adquisici�n, la primera estando el veh�culo est�tico (ralent�) y la segunda definiendo un ciclo de conducci�n normal y otro en carretera, para esto es necesario realizar las gr�ficas de los datos adquiridos.

Esta prueba ayud� a definir posteriormente los umbrales m�nimos y m�ximos de las se�ales. Adem�s, las funciones de membres�a para cada una de las se�ales. Para esto se busc� las funciones necesarias en LabView para organizar esta programaci�n en primera instancia se prob� con la funci�n de comparaci�n, que permite comparar si lo que estamos midiendo es igual al dato patr�n.

Luego de haber definido el m�nimo y m�ximo de cada una de las variables, se procede a dar una ponderaci�n a todo el rango de la se�al, definiendo los valores ling��sticos de cada variable y para no hacer muy tedioso queda se�alado de la siguiente manera.

 

Tabla 3: Valores Ling��sticos para las Variables

 

Luego de haber definido los valores ling��sticos para la fuzzificaci�n, los mismos que servir�n para definir las funciones de membres�a de las se�ales de entrada le�das por la tarjeta de adquisici�n de datos, de la misma manera se debe definir valores a la salida para la defuzzificaci�n de igual manera se define los valores ling��sticos y se deja detallados como numero de fallas por cada sistema interno del veh�culo, en el sistema cada falla tendr� una correspondencia a un sensor o a un componente del veh�culo seg�n la experticia del t�cnico automotriz.

Para ello se debe ingresar las funciones de membres�a tanto de las entradas y salidas del Sistema Fuzzy MIMO (M�ltiples Entradas y M�ltiples Salidas), en la aplicaci�n Fuzzy System Designer de LabView, como se indica en la figura.

 

Figura 7: Pantalla de las funciones de membres�a de las entradas y salidas

 

Definici�n de las condiciones de pruebas

Para proceder a detectar el comportamiento en estado �ptimo del veh�culo se define las condiciones de diagn�stico para detectar a obtener datos del veh�culo en buen estado con el fin de definir par�metros de funcionamiento normales y posteriormente a comprender que sucede si no tenemos estos par�metros a las condiciones de diagn�stico.

Para esto definimos en un estado est�tico las siguientes condiciones de diagn�stico relacionando el Tiempo de Marcha del Motor vs. RPM del veh�culo.

 

Figura 8: Condiciones para la prueba en estado est�tico

De la misma manera se defini� condiciones de prueba para un diagnostico din�mico de veh�culo en este caso puede ser entre tempo de marcha del motor vs. la velocidad del veh�culo, como se muestra a continuaci�n.

�

Figura 9: Condiciones de Prueba en estado Din�mico

 

Esto nos servir� para poder ingresar las reglas del sistema fuzzy para la detecci�n de fallas, sin embargo, sustentamos estas reglas con el estado de detecci�n de fallas DTC del manual de taller. (Hiunday, 2005). De acuerdo a las reglas ingresadas se realiza posteriormente el test que permite el toolkit de Fuzzy System Designer de Labview. Para posteriormente probar las reglas ingresada definiendo a cada c�digo de falla, una falla especifica en cada sistema, como se muestra a continuaci�n.

 

Tabla 4: Fallas comunes del veh�culo

C�digo de Falla	Sistema de Enfriamiento	Sistema de Admisi�n de Aire	Sistema de Escape de Gases	Sistema de Ignici�n	Sistema de Combusti�n
F1	Radiador Tapado	Filtro de Aire Colapsado	Escape Tapado	Inyector defectuoso	Inyectores Abiertos
F2	Remordimiento del Termostato	Falla del Vac�o del Motor	Catalizador Colapsado	Sistema Demasiado Pobre	Bobinas Defectuosa
F3	Resistencia Inadecuada del Sensor	Falla del Sincronizaci�n del Sistema de Distribuci�n.	Inyectores Abiertos	Sistema Demasiado Rico	TPS defectuoso
F4	Sin Refrigerante	Falla en las v�lvulas de admisi�n	Falla del MAP	No Enciende los cilindros	Buj�as Defectuosas
F5	Ca�er�a Tapada	Falla del Sensor TPS	Buj�as Defectuosas	Falla del PCM	Bomba Defectuoso
F6	Empaque del Cabezote da�ado.	Fuga o taponamiento en la admisi�n de aire	Cables de Alta Tensi�n defectuosos	Sistema de Carga de Energ�a	CMO Defectuoso
F7	Tapa del Radiador Averiada.		Falla del sensor CMP		Sin Combustible
F8		Falla del Sensor IATS	Falla del Sensor de Oxigeno 1		Presi�n de combustible baja
F9	Falla del sensor de temperatura del Refrigerante	Falla del Sensor MAP	Falla del Sensor de Oxigeno 2
F10	Trabajo Normal	Trabajo Normal	Trabajo Normal	Trabajo Normal	Trabajo Normal

 

Dise�o de la interfaz

Para el dise�o de la interfaz fue analizar todas las necesidades de diagn�stico con el t�cnico automotriz, con el fin de satisfacer necesidades de monitoreo en tiempo real, diagnostico en tiempo real y r�pido, de igual manera un diagn�stico cuando el veh�culo se encuentra en modo est�tico y tambi�n en estado din�mico, para finalmente emitir un reporte de resultados, con las fallas que com�nmente se encuentra en el veh�culo por cada sistema.

De ah� se propone el siguiente men� para realizar el monitoreo, diagn�stico, an�lisis y reportes con una pantalla de presentaci�n.

 

Figura 10: Men� del sistema de detecci�n de fallas

 

Resultados

En lo que corresponde a la adquisici�n de datos la Tarjeta NI 9862 y el adaptador para USB cDAQ - 9171 son los encargados en extraer los datos en tiempo real desde la ECU del autom�vil y traducir a un lenguaje decimal, la informaci�n que los sensores entregan por medio de la comunicaci�n CAN, permitiendo realizar un monitoreo de lo que sucede en funcionamiento del veh�culo.

En este caso de estudio realizado en un autom�vil KIA Sportage Active, modelo 2013 se evidencia que no se puede leer todos los PID que menciona SAE en su norma J1939, entre ellos los PID de aceleraci�n electr�nica, mientras que en otros modelos de veh�culos si lo tienen, por lo tanto, se ha programado para adquirir la mayor�a de datos que nos entregue la red con la discriminaci�n para el caso que no encuentra el PID este sea deshabilitado su lectura.

En la figura se indica la ubicaci�n de un check junto al indicador con el fin evitar que nuestro sistema se ponga lento en la adquisici�n de datos, dado que el bloque OBD Diagnostic tarda en buscar la se�al redundando y generando error en la lectura, error que es monitoreado cuando el indicador booleano (led) se pinta de color rojo. Este error desaparece al deshabilitar la lectura, para evadir la b�squeda.

�

Figura 11: Lectura de los PID

 

Luego de la identificaci�n de los PID�s que existe en cada veh�culo, en nuestra interfaz podemos monitorear el comportamiento de las se�ales y el comportamiento con indicadores seg�n el tipo de par�metro f�sico que se est� midiendo, entre ellos term�metros, veloc�metros, etc. Con el fin de tener un comportamiento real de cada una de las se�ales.

�

Figura 12: Monitoreo por Tendencias

 

Como se puede observar el monitoreo de las se�ales se realiza en tiempo real, evidenciando que el comportamiento se da de acuerdo a los cambios que se de en el veh�culo, por ejemplo, tomando la se�al del ox�geno, se puede ver que se tiene el cambio entre combusti�n rica a combusti�n pobre, esta se�al hace que la ECU de autom�vil realice variaciones en el sistema de inyecci�n.

Adicional se tiene una pantalla con indicadores amigables servir�n para validar la adquisici�n de datos y que el an�lisis pueda ser asertivo en la detecci�n de fallas, o para la identificaci�n r�pida si el sensor falla o est� entregando datos err�neos.

 

Figura 13: Monitoreo por indicadores amigables.

 

Una vez obtenido los datos y procesados los mismos de acuerdo a las f�rmulas que indica la norma SAE, se puede evidenciar el comportamiento de cada una de las se�ales. Permitiendo definir a cada una de las variables las relaciones ling��sticas planteadas que indique el comportamiento de la variable, las mismas que luego servir� para determinar las reglas que identificar�n las fallas en uno o varios sistemas dependiendo de la combinaci�n de se�ales obtenidas.

Luego de procesar los datos con las funciones de membres�a, se defini� las reglas para la detecci�n de fallas de acuerdo al comportamiento de las se�ales y el cumplimiento de las reglas ingresadas en la herramienta de Labview, en esta parte de la investigaci�n es muy importante el aporte del experto para definir los comportamientos, en este caso nos hemos ayudado del manual de taller en donde muestra las fallas que se presentan de acuerdo al comportamiento de una o varias se�ales.

Como demostraci�n del procesamiento que realiza Labview en su toolkit Fuzzy Designer muestro a continuaci�n una simulaci�n de una regla y el cumplimiento de la defuzzificaci�n por el m�todo del centroide. Para lo cual validamos la regla que se encuentra ingresada con el test para verificar el cumplimiento.

 

Figura 14: Simulaci�n de una de las Reglas Programadas

 

Interpretando las condiciones de la regla venos que cuando se la variable de enfriamiento COOL tenga valores normales, la admisi�n del aire IAT es bajo, la posici�n del acelerador TP es normal, la purga autom�tica PEC es normal, la carga del motor CM en normal y las revoluciones del motor RPM sean muy bajas. Entonces el sistema de Admisi�n tendr� la falla 6, el sistema de Combustible tendr� la falla 8 (presi�n de combustible baja) y el sistema de Ignici�n tendr� la falla 3 (sistema demasiado rico).

 

 

Figura 15: Validaci�n de la Regla.

 

A continuaci�n, se presenta la validaci�n de una regla de dos variables de entrada y una de salida de forma gr�fica.

Figura 16: Test de una regla en la forma grafica

 

Se puede observar que de acuerdo a los par�metros que tengan las variables de entrada se posicionara en un valor especifico de la variable de salida en este caso, cuando la variable de temperatura del refrigerante COOL y si el tiempo de marcha del motor TMM es muy bajo, entonces se tiene la falla 5 en el sistema de enfriamiento que quiere decir que la ca�er�a se encuentra tapada. Como se puede ver en el grafico tridimensional y los cursores de y en la leyenda que relaciona la regla.

Para poder cumplir con el objetivo principal del trabajo que es la detecci�n de fallas, tenemos pantallas de diagn�stico general para realizar la detecci�n de fallas, de igual manera se tiene pantallas para el diagn�stico del veh�culo en estado est�tico y en estado din�mico, en estas pantallas se registra las fallas que se vayan presentando en cada uno de los diagn�sticos.

 

Figura 17: Pantalla de detecci�n de fallas.

 

Por �ltimo, se cuenta con una pantalla en donde llamamos a los archivos guardados en las pantallas anteriores de diagn�stico est�tico y din�mico, para sacar un reporte o resumen del comportamiento del veh�culo durante las pruebas, por medio de histogramas, de estos se extrae las fallas que se presenten en mayor cantidad durante el diagn�stico.

 

Figura 18: Reporte de fallas del veh�culo.

 

Luego de un an�lisis en el tiempo arroja varias fallas de los diferentes sistemas del veh�culo bajo las condiciones establecidas en un recorrido en carretera con las condiciones meteorol�gicas de la ciudad de Riobamba, provincia de Chimborazo del Ecuador que se encuentra a 2750 msnm, con una temperatura que oscila entre los 9 ~ 20 �C.

Bajo estas condiciones, durante la prueba se ha presentado eventualmente varias fallas en el sistema que, al ser validados, con el especialista automotriz demuestra que son fallas falsas durante el proceso de validaci�n del sistema. Para solucionar este inconveniente ha sido necesario realizar un proceso estad�stico para la toma decisiones de las fallas que se presentan.

En la pantalla de reporte se puede conseguir una validaci�n estad�stica de la presencia de fallas en cada sistema, esto lo realizo sacando un histograma de las fallas presentadas durante el an�lisis, siendo las fallas que debemos dar mayor importancia a las que se presenten en mayor cantidad, en vista que existen fallas que se presentan una o muy pocas veces durante el tiempo que se realice el diagn�stico, es decir que de acuerdo al n�mero de muestras tomadas en el an�lisis.

Luego de extraer el archivo y sacar el histograma, se toma la falla que tiene el mayor n�mero de eventualidades durante el an�lisis y muestra la falla que se debe dar un tratamiento o verificar las condiciones por la cual se presenta esta falla.

 

Conclusiones

Con respecto a la adquisici�n de datos se evidencia que no todos los autos poseen las mismas se�ales, mucho varia en cuanto a la cantidad de datos que se puede extraer por comunicaci�n CAN, para eso se debe hacer una comprobaci�n o validaci�n de PID�s que tiene el veh�culo previo al an�lisis.

Luego de la adquisici�n de datos se procede a dar los rangos respectivos para formar las funciones de membres�a, en este espacio se puede indicar que en muchos casos las se�ales que entrega son muy amplios con respecto al rango que usualmente se puede utilizar, como es el caso de las RPM presenta un rango de 0 � 16 383.75 cuando en realidad y en el mejor de los casos el m�ximo que alcanzar� es de 0-7500 RPM.

Los rangos permiten a establecer los umbrales de funcionamiento apegados a la realidad de los par�metros o se�ales de medici�n del autom�vil, porque si nos remitimos a los valores que se encuentran normados por la SAE J1939 est�n fuera de la realidad del veh�culo, esto ayuda a definir las fallas en los sensores por detecci�n de umbrales; es decir si se encuentra al m�nimo o al m�ximo del rango establecido detectara como falla del sensor.

En la definici�n de reglas para la detecci�n de fallas por fuzzy logic, es necesario la ayuda de un experto en el �rea automotriz, pero un repositorio de la manual de taller ayud� mucho para establecer las reglas de reconocimiento de las fallas que se presenta en el autom�vil, seg�n los par�metros que se pueda medir.

Para detectar fallas es necesario establecer rutas o condiciones en las cuales puedan presentarse en su mayor�a las condiciones de funcionamiento del veh�culo, para eso se realiz� estrategias de diagn�stico en estado est�tico relacionando las RPM con el tiempo de marcha del Motor y un estado din�mico relacionando la velocidad del veh�culo con el tiempo de marcha del motor.

La toma de registros de fallas se realiza en tiempo real tanto para el modo est�tico y din�mico, mientras que para el procesamiento y reporte de las fallas es necesario realizar algo de estad�stica descriptiva para identificar la frecuencia que se presenta las fallas por medio de histogramas, en cada uno de los sistemas para presentar como fallas representativa a la que mayor veces se present� durante el an�lisis, en vista puede presentarse alguna falla eventualmente por alguna maniobra o condici�n que se present� en el diagn�stico.

�����������

Referencias

1.               Cervantes, E., Alonso, S., 2010. Escaner Automotriz de Pantalla T�cti.

2.               Dimitar � Georgiev, V, Dimitar � Georgiev, T., Automotive Diagnostic Trouble Code (DTC) Handling over the Internet. IX National Conference with International Participation "Electronica 2018". DOI: 10.1109/ELECTRONICA.2018.8439702

3.               Hernandez-Cely, M., Sandoval-Estupi�an, A., Valencia-Rivera, F., 2015. Sistema difuso para la detecci�n y diagn�stico de falla en la generaci�n a vapor. Scientia et Technica A�o XX. DOI: http://dx.doi.org/10.22517/23447214.8063

4.               Scott K, 2000. The importance of automotive diagnostics in the search of excellence. DOI: 10.1109/AUTEST.1992.270138

5.               Simba�a, W., Caiza, J., Chavez, D., Lopez, G., 2016. Dise�o e Implementaci�n de un Sistema de Monitoreo Remoto del Motor de un Veh�culo basado en Obd-II y la plataforma. Revista Polit�cnica 37.

6.               Simonik, P.,� Mrovee, T., Takae, J., 2014. Principles and Techniques for Analysis of Automotive Communication Lines and Buses. 978-1-4799-3721-9/14/$31.00 mOl41EEE, 500-503. DOI: 10.1109/ELEKTRO.2014.6848945

7.               Sobhani � Tehrani, E., Khorasani, K., 2009. Fault Diagnosis of Nonlinear Systems Using a Hybrid Approach. Lecture Notes in Control and Information Sciences 383. DOI: 10.1007/978-0-387-92907-1 2

8.               Velasquez-Aguilar, J. G., Aquino Roblero, F., Limon-Mendoza, M., Cisneros-Villalobos, L., 2017. Multi-channel data acquisition and wireless communication FPGA-based system, to real-time remote monitoring. International Conference on Mechatronics, Electronics and Automotive Engineering. DOI: 10.1109/ICMEAE.2017.39

9.               Ukil A., 2015. Condition Monitoring and Diagnostics for Automotive Applications. IEEE 2nd International Conference on Recent Trends in Information Systems (ReTIS), 310�313. DOI: 10.1109/ReTIS.2015.7232896

10.           Ye Q., 2010. Research and Application of CAN and LIN Bus in Automobile Network System. 3rd International Conference on Advanced Computer Theory and Engineering(ICACTE) 6, 150-154. DOI: 10.1109/ICACTE.2010.5579409

 

 

 

 

 

 

� 2020 por los autores. Este art�culo es de acceso abierto y distribuido seg�n los t�rminos y condiciones de la licencia Creative Commons Atribuci�n-NoComercial-CompartirIgual 4.0 Internacional (CC BY-NC-SA 4.0)

(https://creativecommons.org/licenses/by-nc-sa/4.0/).